Difficulty Visualizing Succession Flow

[DavidHetherington]

Having difficulty visualizing a succession flow. The text syntax editor shows “no problems”. Tom Sawyer visualizes the expected dashed arrow with solid arrow head, but the rest of the diagram is bizarre. VIZ makes a pretty diagram but is missing the action parameters (in item and out item) and the succession flow. I have noticed that the VIZ documentation does only advertise “general view”. I tried both “general view” and “action flow view” with the same results.

Note, one thing that does not help is that the standard is a rather muddled on what to expect. The Weilkiens and Molnár Book is better.

One thing that took awhile to understand is that although the SysML V2 community took pains to harmonize activity diagram pins and object flows with ibd ports and item flows, actually examining the examples in the standard carefully, the community is still apparently thinking in SysML V1 mode. In the case of actions “what” is conveyed is indicating by typing the parameters (pins in SysML V1) while flows between parts show examples of specifying the payload of the flow (item flow in SysML V1).

At any rate, examining all of the above carefully, we produced our own expected graphic and two other tools ingested the SysML text syntax file and produced exactly the expected graphic. See attached files for details.

Test-3310-Action-Succession-Flow.docx (170.0 KB)

Test-3310-Action-Succession-Flow.sysml (1.6 KB)

[DavidHetherington]

Test-3310-Action-Succession-Flow.docx (239.6 KB)

(File was not fully saved. Sorry.)

[KestutisJankevicius]

Hello, David,

Thanks for your feedback! In terms of your test, you need to expose all child elements using recursive import (suffixed by “::**” expose <namespace>::**;) in the view. With just namespace import of single level child elements (suffixed by “::*”), you are not exposing the inner features of prepareSandwich, eatSandwich, so succession flow ends have nothing to connect to.

        view 'Show Succession Flow' : StandardViewDefinitions::GeneralView {
            expose enjoyLunch::**;
		}

Using recursive import Syside Modeler CLI “visualize view” command generates the following diagram (note, custom colours are set with syside.toml config file):

This matches the expected output almost exactly, except for the missing dashed arrows of successions between nodes start / prepareSandwich and eatSandwich / end. This is communicated to the development team and will be addressed in the future.

I have one off-topic suggestion, related to the use of package-level usages in your test specification. Semantically, usages are relationships and require context defined in which they are relevant. By not providing it (i.e. specifying usage in a package), it means that all definitions will feature these usages, which is rarely the intention. They should only be used in a few specific situations, such as semantic metadata, units definition. Therefore, I encourage you to update the test cases so that all usages are specified in appropriate context definition. For example:

      package <MySysV2> 'My System V2' {
        item def Sandwich;
        action def EnjoyLunch {
            action prepareSandwich {
                out item sandwich : Sandwich;
            }
            action eatSandwich {
                in item sandwich : Sandwich;
            }
            first start then prepareSandwich;
            succession flow of Sandwich from prepareSandwich.sandwich to eatSandwich.sandwich;
            first eatSandwich then done;
        }
        occurrence def Diagrams {
            view 'Show Succession Flow V2' {
                expose EnjoyLunch::**;
            }
        }
    } 

Visualization of the view will result in a very similar diagram - definition element corners are right-angled instead of rounded as it was for usage. Also, the specialization to GeneralView is optional because it is implied. Finally, you can also define the exchange item as “item def” and type the action in/out parameters by it (defined by) and indicate that flow is of it .

Kind regards,
Kestutis

[DavidHetherington]

(The website is not allowing me to post a reply)

[DavidHetherington]

Hmmm…

I was not able to replicate the first fix. Simply removing the first “expose enjoyLunch;” statement produced the same results. Notice in the diagram at the lower right corner, the same single recursive expose statement. However, the result got worse - start and done disappeared.

As for the second fix, I was able to duplicate this. By adding a payload to the succession flow, the diagram now renders nicely. However, if we look at section “7.16.2 Flow Definitions and Usages” of the standard, we will see this example:Notice that this succession flow statement does not include a payload. (And other tools render the succession flow correctly without a payload)

???

David Hetherington

[DavidHetherington]

Sorry for the multiple replies.

[DavidHetherington]

For some reason, the website blocked my reply including a block comment from the standard…without an explanation…I was forced to binary isolate what the website was objecting to. Let’s try a screenshot from the standard:

Notice: No payload on the succession flow statement.

[DavidHetherington]

Regarding the suggestion of modeling always with definitions first. see the attached excellent presentation from IS 2026. Notice slide 11. The definition first approach may be semantically more precise, but it explodes the size of the model. We are working on “Simple SysML V2 for Beginners” books. For this audience, reduced example complexity is more helpful than increased semantic precision. Wherever possible, we will be using the very simplest constructions possible.

Thanks!

David Hetherington

Liddy and Wylie - 2026 - A usage-first modelling methodology in SysML v2 - Presentation.pdf (812.0 KB)

[DavidHetherington]

In order to eliminate a variable, here is the PowerShell command I am using to visualize the model. Note that I had to append “.txt” so that the Forum would allow me to upload.

Thanks!

David Hetherington

vizModelViews.ps1.txt (114 Bytes)

[Adam_Layne]

David,

The payload isn’t required. Your reading of 7.16.2 is right, and succession flow prepareSandwich.sandwich to eatSandwich.sandwich; with untyped parameters renders correctly on its own. The only change needed is the expose.

Looking at the diagram in your reply, the legend in the lower right reads expose enjoyLunch::* with one asterisk. Two are needed:

view 'Show Succession Flow' : StandardViewDefinitions::GeneralView {
    expose enjoyLunch::**;
}

One asterisk exposes only the direct children of enjoyLunch, so prepareSandwich and eatSandwich come through but their sandwich parameters do not. The flow ends then have nothing to attach to, and dropping the separate expose enjoyLunch; line removes the owner that start and done were hanging from, which is why those disappeared too. With ::** and nothing else changed, your original file produces the pins, the direction arrows, and the dashed succession flow.

So the two things you tested were tangled together. Adding the payload also worked, but only because it happened to be tested against the single-asterisk view. Either change alone is enough, and you do not need the payload if the parameter typing is carrying the meaning.

What is still missing is the dashed rendering on the plain successions from start to prepareSandwich and from eatSandwich to done. Those come out solid. That one is a known bug and is being worked on; thanks for identifying this for us!

Finally, usages in packages are a fraught topic, and are tripping a lot of folks up. I created a dedicated topic about what a package-level usage means in Megathread: Package-level usages, with the spec text and the OMG issues.

Adam Layne, PhD

[DavidHetherington]

Adam,

Thanks for pointing out the double asterisk. I had missed that. Good. Something I need to be sure to point out in the beginner book. With that fixed, I get the correct (or almost correct) output from VIZ.

After thinking about what we want to explain for beginners, I decided to follow-up on the input from Kestutis and provide an item def to type the action parameters. Basically, the guidance will be:

• Action Flow - Type the parameters. No payload. This is consistent with SysML V1 object flows…and of course needs a proper “Type” (ie: item def) to do correctly.
• Flow Between Parts - Add a payload to the flow. This is roughly consistent with SysML V1 item flows… not exactly, but close. Ports get names, typing the port is optional.

With those two changes, my VIZ output now matches and looks nice:

Unfortunately, these changes sent Tom Sawyer into outer space. First, visualizing the view:

Next, visualizing the entire model looks a little better…but still not wonderful:

At this point, however, Tom Sawyer is not high on my priority list for a Sensmetry book at the moment.

Thanks for the pointer to the meta article on package level usages. Of course, I understand the ontology and syntax reasoning completely. However, the need to wrap every usage in a dummy part def is a language design failure and not what the community was promised at the outset of the SysML V2 design effort.

The initial promise was something along the lines of: “It is going to be really simple. People who like concrete first approaches can just start out modeling with parts.” This promise seems to have fallen through the cracks along the way.

This sort of problem matters because in front-line, in-the-trenches MBSE, models are almost never fully complete. They are partial models made fairly quickly to illustrate a concept or help a team make a decision. The fully complete model suitable for formal logic processing is a rarity. Almost no real company will pay for this level of modeling. In the “Quick, partial model to help the humans communicate” world extra semantic noise that does not actually help the team understand stuff is a real problem.

At any rate, our readers are the guys standing in the mud at the railway construction site holding shovels and wrenches. Our goal is to show them a path through the semantic and ontology complexity to make some simple stuff that helps them get the job done.

I will think about it. We might have a footnote or a sidebar, but we are not going to write an entire book showing every single part usage wrapped in a definition just to make the semantics work. That would just convince readers that the technology is overly theoretical and not a match to their daily lives.

At any rate, thanks for the explanation of the double **. Now, I understand the point.

David Hetherington

Test-3310-Action-Succession-Flow.sysml (1.6 KB)