Offline diagram generation

SysML v2 Discussion
4

Hi Manuel,

I’ll try to answer some of your questions one-by-one:

Am I modeling the views in the wrong way?

I would not say you are modeling them the “wrong” way, but there are some issues with how you define what you would like to be shown in the view.

To better communicate, let’s consider the following simplistic model:

package PackageA {
    part def a {
        part b;
        part c {
            part d;
            part e;
        }
    }
}

package View {
    view exposeExample {
        expose PackageA::a;
    }
}

Now, let’s talk about expose and different options you have:

  • If expose is PackageA::a; , then exposed elements would be the element itself:
    • PackageA::a
  • If expose is PackageA::a::*; , then exposed elements would be only the direct children:
    • PackageA::a::b
    • PackageA::a::c
  • If expose is PackageA::a::**; , then exposed elements would be the element itself, direct children, and children-of-children recursively:
    • PackageA::a
    • PackageA::a::b
    • PackageA::a::c
    • PackageA::a::c::d
    • PackageA::a::c::e
  • If expose is PackageA::a::*::**; , then exposed elements would be direct children, and children-of-children recursively:
    • PackageA::a::b
    • PackageA::a::c
    • PackageA::a::c::d
    • PackageA::a::c::e

Now, the reason why in Tom Sawyer you see more elements than what “pure” expose would give you is because our current implementation has a depth attribute that is set to -1 by default. This means, that the visualizer takes the exposed element, and traverses its sub-tree up to the value set by depth (-1 means infinite) and visualizes all the traversed elements. This is one of the reasons why in the use case diagrams you see more details than you’d like.

Are there recommended patterns for getting more recognizable use case, sequence, and state diagrams out of Syside today?

Sequence views

When Tom Sawyer visualizer encounters an occurrence with parts and message flows inside, it will try to visualize it as the sequence view automatically. In your case, this would mean translating your TurnLampOnSequence from a use case to an occurrence def:

    occurrence def TurnLampOnSequence_occurrence {
        part lamp : Lamp {
            event occurrence commandReceived;
            then event occurrence lampTurnedOn;
        }
        part user : User {
            event occurrence pressesButton;
            then event occurrence observesLampOn;
        }

        message from user.pressesButton to lamp.commandReceived;
        then message from lamp.lampTurnedOn to user.observesLampOn;
    }

This would produce a diagram like so. There is currently a bug in the Tom Sawyer visualizer that makes the arrow directions to randomly not correspond with what is defined in the model. We have raised this issue with them and they are looking into it.

diagram-turnLampOnSequenceView
diagram-turnLampOnSequenceView346×198 7.46 KB

Use case

As described in the answer to your first question, this is an issue of depth and expose. I recommend changing the view to the following:

    view operateLampUseCaseView {
        doc
        /* Expected result:
         * A use case view centered on 'operate lamp'.
         * User is shown as an actor.
         * The child use cases 'turn lamp on' and 'turn lamp off' are visible beneath it.
         *
         * Tree rendering is used here to make the view deterministic.
         */
        expose ExampleModel::'operate lamp'; // Exposes the use case itself
        expose ExampleModel::'operate lamp'::*; // Exposes direct children
        render asTreeDiagram;

        // Hide the documentation node as it is already in the use case
        // as a compartment
        filter not @SysML::Documentation;

        // Shows the relationships between the use case and its children.
        // Set to 0 if you do not want to see the relations.
        attribute depth = 1; 
    }

This produces the following diagram, which seems to be what you are looking for according to the doc.

Diagram
Diagram1020×460 27.3 KB

State machine

The solution to this is a combination of the above two answers:

  1. Tom Sawyer visualizer auto-detects that the diagram is a state machine view when the element being visualized is a state def (which you already discovered).
  2. The fix of removing superfluous data is, again, fixing the exposes and setting depth:
    view lampStatesView {
        doc
        /* Expected result:
         * A state-oriented rendering with the states off and on.
         * It shows the transitions triggered by TurnOn and TurnOff.
         *
         * This view is used to check whether tools provide a recognizable state-diagram rendering.
         * It also checks whether they only provide a generic model view.
         */
        expose ExampleModel::lampStates;
        expose ExampleModel::lampStates::*;

        attribute depth = 1;
    }

The above <<action>> should be the “entry” state circle. It is not rendering as such due to a bug at the moment. This also loses the transition names at the moment. We are working to address this.

Diagram
Diagram530×680 16.7 KB

Should I be using specific standard view definitions such as SequenceView or StateTransitionView instead of plain view with expose?

At the moment, Tom Sawyer visualizer does not have a separate “sequence view” or “state transition view”, only the “tree” and “nested” views (which are very generic views). As seen above, Tom Sawyer instead looks into what is being visualized and if it finds an occurrence def or state def in the model, and visualizes it in that specific way.

Thus, at the moment, there is no need to use those view definitions as they will not have any effect.

Do you have examples of how you are generating more polished diagrams from Syside in practice?

This is essentially what we do: we play around with expose and depth to see what looks the best. We are also working on improvements some of which are coming in 0.9.0 and some of them were teased in another forum post: Customizing Diagrams - #6 by Simonas

2 Likes