Sequence Diagram

 

The sequence diagram captures the interaction between collaborating parts of a system. Part of the behavioral (logical architecture) representation set, the sequence diagram enables you to focus on triggering data and the resultant flow of control between components. This partial representation is particularly useful in understanding and confirming interactions early at each level of the system definition effort.

 

The sequence diagram is available for entities in the Function class (as well as any other subclasses of ProcessingUnit).

The sequence diagram displays the children in a function's decomposition along vertical lifelines. The individual child functions are identified by traversing the parent function's structure (best represented graphically by an activity diagram or an EFFBD). The allocation of these functions (the allocated to relationship) determines the collection of components displayed along the top of the diagram. Individual function nodes are then placed along the corresponding vertical lifeline with unallocated functions displayed on a special "unallocated" lifeline on the right side of the diagram.

 

The arrows on a sequence diagram represent control data, triggers that serve to synchronize interactions. An arrow entering the node triggers that function. An arrow exiting the node is an output that triggers another function. Arrows entering from the left edge of the diagram are external triggers that originate outside of this decomposition. Arrows that exit the right edge of the diagram are outputs that trigger functions elsewhere in the system model. Basic inputs (data stores) are not shown on the sequence diagram since the focus is on interactions.

 

GENESYS determines the order of functions on the sequence diagram by doing a static "execution" of the logic. In essence, the function's structure is traversed from start to finish. During this traversal, if the needed trigger for a function is already available, the function is placed in the next vertical position on the appropriate lifeline. If the trigger is not available, the function "waits" until it is available. This static "execution" does not have the dynamic rigor of executing the full model using the integrated simulator engine, but it does ensure integrity and consistency between the sequence diagram and the underlying system model. The bottom line is that ordering of nodes on a sequence diagram cannot be manipulated directly via the sequence diagram (the representation is too ambiguous from this perspective, and changing the order would change the underlying model in unanticipated ways). The ordering is best managed by manipulating the activity diagram or EFFBD.

 

While the order is computed and you cannot position nodes out of order, you have great flexibility within those computational boundaries to lay the diagram out in a way that better communicates the interactions within your system.

 

 

The net result is a diagram that both represents the engineering truth of your system design and the visualization necessary to understand, analyze, and communicate.

 

   

 NOTE:

A good reference for further information on sequence diagrams is chapter 10 of A Practical Guide to SysML: The Systems Modeling Language by Sanford Friedenthal, Alan Moore, and Rick Steiner (2012).

Diagram Options

In addition to the classic diagram options, the sequence diagram settings include:

Diagram Toolbox

The constructs and key entities tabs allow you to quickly develop your interaction diagram, while the all entities tab enables you to relate your sequence diagram entities to the remainder of your system definition.

 

Constructs

Utilities

Key Entities

All Entities - all classes and entities in the system model, allowing you to drag any entity on top of a diagram node to establish relationships with the balance of your system model

Context Menu Commands

Tips and Tricks