Fork visualization correct?

[pjljvandelaar]

Dear Developers,

When I visualize the following sysml code,

package ForkVisualization1 {
    action Example {
        // actions
        action A;
        action B;

        // synchronization points
        fork fork1;
        join join1;

        // order
        first start then fork1;

        first fork1 then A;
        first fork1 then B;

        first A then join1;
        first B then join1;

        first join1 then done;  
    }   
}

I get

This visualization is as expected.

However, when I visualize the following sysml code [which imho is equivalent to the earlier code]

package ForkVisualization2 {
    action Example {    
        // actions
        action A;
        action B;

        // synchronization points
        fork fork1;
        join join1;

        // order
        first start then fork1;

        first fork1;
            then A;
            then B;

        first A then join1;
        first B then join1;

        first join1 then done;
    }   
}

I get

I get an additional and unexpected extra synchronization bar. Is this a bug in the visualization? If not, could the documentation better explain why this is ok?

Thanks in advance,

Pierre

[himi]

It's an interesting issue. The direct cause of this problem was an excess membership to fork1, which exists only in the second example. So the visualizer got confused and rendered it as well. Rather, it should be treated as an alias but the action view of the visualizer cannot handle such aliases. I think the visualizer should deal with such alias memberships in interconnection, action and state views as well as tree views. However, I hope the parser should not add such unexpected memberships. Ed, what do you think?

With regards,

-- Hisashi

On Tue, May 23, 2023 at 5:11 AM pjljvandelaar @.***> wrote:

Dear Developers,

When I visualize the following sysml code,

package ForkVisualization1 { action Example { // actions action A; action B;

  // synchronization points
  fork fork1;
  join join1;

  // order
  first start then fork1;

  first fork1 then A;
  first fork1 then B;

  first A then join1;
  first B then join1;

  first join1 then done;

}
}

I get [image: image] https://user-images.githubusercontent.com/18348654/240205156-ef156e6f-14b5-46f6-8b28-de0929614572.png

This visualization is as expected.

However, when I visualize the following sysml code [which imho is equivalent to the earlier code]

package ForkVisualization2 { action Example {
// actions action A; action B;

  // synchronization points
  fork fork1;
  join join1;

  // order
  first start then fork1;

  first fork1;
      then A;
      then B;

  first A then join1;
  first B then join1;

  first join1 then done;

}
}

I get [image: image] https://user-images.githubusercontent.com/18348654/240205588-0b3246bb-92fd-46d5-be25-eea731d2bfca.png

I get an additional and unexpected extra synchronization bar. Is this a bug in the visualization? If not, could the documentation better explain why this is ok?

Thanks in advance,

Pierre

— Reply to this email directly, view it on GitHub https://github.com/Systems-Modeling/SysML-v2-Pilot-Implementation/issues/482, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAACSKNF273AUJCKABXPH5TXHR5L3ANCNFSM6AAAAAAYLSO4YQ . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[E-genin]

@pjljvandelaar , sorry for the non related question, but have you found any problems setting up the envionment ? If so how did you resolve them ? I am not able to see the diagrams in the PlantUML window even if I can't see any error messages !

[pjljvandelaar]

@E-genin Everything installed smoothly at my side, so I can't help you...

[seidewitz]

The notation first fork1; parses to an alias membership to fork1, per the specification. This is necessary in order to provide a "placeholder" to be used as the source for subsequent successions declared using the then shorthand notation. That is, the notation

first fork1;
    then A;
    then B;

is essentially equivalent to

alias _source_ for fork1;
first _source_ then A;
first _source_ then B;

(except that the alias is unnamed in the first snippet).

@pjljvandelaar If you would like to discussion this further, I suggest you post to the SysML v2 Release Google Group.

@himi This should probably be treated as a visualization bug.

[pjljvandelaar]

@seidewitz Since you label it as a visualization bug, no further discussion is needed.

[himi]

I think quickly dealing with this issue would not be difficult. Possibly just let the visualizer ignore unnamed memberships. However, we need to be cautious about how they are parsed.

For example, if we write

first fork1 then A;

it does not make a membership placeholder while

first fork1;
then A;

would make a placeholder for fork1.

Anyway, I'll make a JIRA issue for this.

[himi]

See PR https://github.com/Systems-Modeling/SysML-v2-Pilot-Implementation/pull/516

[seidewitz]

This was fixed in Release 2023-11.