Sequence Diagrams with Lifelines, Constraints and other Specifications

Sequence diagrams (sd) = used to express information about system’s dynamic behavior, by using elements called lifelines to model participants in the system behavior and use messages between lifelines to model the interactions. This view expresses sequences of behaviors and events over time. This is an ideal diagram when wanting to display how blocks interacts via operation calls and asynchronous signals called interactions. These diagrams can be create at any level of system hierarchy, though useful early in the system life cycle during ConOps development.

Reminder – there are 3 kinds of behavior diagrams:

– Sequence

– Activity

– State machine

Sequence diagrams are precise specifications of behavior and therefore detailed design artifact that can be an input into development. Some modeling tools can take sequence diagrams and auto-generate code. There are 3 requisites to automate a transformation of diagram to source code:

– The order in which behaviors are performed

– Which structure performs each behavior

– Which structure invokes each behavior

An interaction itself is a model element, like an activity, and is a kind of behavior. It is like a namespace, containing set of named elements (lifelines, event occurrences, messages).

The example above is the main success scenario for the Execute Hohmann Transfer use case.

Lifelines

Lifeline = is an element that represents a participant in the interaction, a single instance that interacts with other lifelines via messages. It is noted with a rectangle (the head) with dashed line attached to it. Time goes from top to bottom, though the linear distance between two event occurrences on a lifeline means nothing, other than the fact that one occurs before the other. The head is in this format:

The <selector expression> is optional and specifies a particular instance the lifeline represents. Though a single part property may represent a collection of instances (based on its multiplicity), the <selector expression> specifies a particular instance in that collection (single). In the example below, the ssdd lifeline has <selector expression> [x axis] to distinguish it from one of the 3 instances defined in the BDD (xaxis, yaxis, zaxis). So in this example, the Star Sensor lifeline is specific to the xaxis – however – if the <selector expression> was omitted, it would represent an arbitrary instance. So only use the <selector expression> if that instance specification is needed.

Event Occurrences

There are six kinds of event occurrences that can appear on lifelines:

– Message send occurrences

– Message receive occurrences

– Lifeline creation occurrences

– Lifeline destruction occurrences

– Behavior execution start occurrences

– Behavior execution termination occurrences

Messages

Message = communication between sending lifeline and receiving lifeline, which could be an invocation of a behavior or start/stop of a lifeline. Noted by a line (solid or dashed with open or filled arrowhead depending on message type) with arrowhead pointing from sender lifeline to receiver lifeline. Message can be sent and received in the same lifeline (point to self). Messages may or may not contain data, it should clearly stated if message contains data.

Message occurrence = refers to a message send occurrence, which exists on a lifeline at the point where the tail end of message; or refers to the message receive occurrence, which exists on a lifeline at the point where arrowhead end of message.

There are 4 message types:

– Asynchronous messages = sender immediately proceeds with own execution after sending message (does not wait for response). Noted by solid line with open arrowhead.

<message name> ( <input argument list> )

– Synchronous messages = sender waits for receiver to finish executing the invoked behavior and give response before continuing its own execution. Noted by solid line with filled arrowhead.

<message name> ( <input argument list> )

– Reply messages = communication that marks the end of a synchronously invoked behavior; noted by dashed line and open arrowhead. This message is optional (does not need to show on diagrams – Figure 7.6 == 7.7 below) Notation:

The assignment target is optional; conveys the name of property that catches the return value (owned by lifeline that invoked the operation/one receiving the reply message). The message name matches thecorresponding synchronous message. Output argument list is optional but if include its noted as comma-separated list. Value specification is the return value of the behavior that just finished execution.

– Create messages = communication that creates a new instance within a system, an instance that participates in the interation. Noted by dashed line with open arrowhead pointed to head. A lifeline creation occurrence exists on a lifeline at the point where first arrowhead of a create message meets the lifeline.

– Found messages (rare)

– Lost messages (rare)

Destruction Occurrences

Example of instance creation occurrences (by a create message):

Destruction occurrence is termination of a lifeline; though SysML does not define what “destruction” means, it could be program objects freed up for memory or actual hardware parts removed (fuel, launch vehicle). These are noted with an X. Destruction can also be triggered by a delete message, as shown below by solid line with filled arrow.

Execution Specifications

Behavior execution start occurrence = implicit at the point where a lifeline receives a syn/asyn message

Behavior execution termination occurrence = implicit at the point where a lifeline sends a reply message

These execution specifications can be noted with a thin vertical rectangle from the start occurrence point to the end occurrence point.

Constraints

Constraint is a Boolean expression displayed between pair of curly brackets {}; there are 3 types of constraints for sequence diagrams:

– Time Constraints = specifies the required time interval for a single event occurrence – valid execution only if that event currence happens within the time interval; in Figure 7.11 this is the currentCommand.executionTime on fc lifeline.

– Duration Constraints = specifies a required time interval for a pair of event occurrences – valid execution only if completed in the specified time frame (no less than 2 mins and no more than 5 mins); in figure 7.11 this is the {2min..5min}

– State Invariants = condition applied to specific lifeline at a point preceding a particular event occurrence. That condition must hold true before continuing down that lifeline. In figure 7.11, this is the

{currentOrbitRadius == currentCommand.orderedOrbitRadius}; This notation can be text or a round-cornered rectangle as shown below. If rectangle used, there is no Boolean expression but instead a reference to a state machine behavior. That state machine behavior must exist on the system model.

Combined Fragments

Combined Fragments = mechanism to allow you to add control logic (conditions, loops, parallel behaviors) to an interaction. It is noted by a rectangle placed over one or more lifelines.

Interaction Operators = control logic text (opt, alt, loop, par)

Operands = regions within a combined fragment containing one or more messages that may occur based on the control logic; noted by dashed lines running horizontally.

Opt operator = optional set of event occurrences that could happen during an execution if condition evaluates to true (the guard). The guard must be directly above first event occurrence in the combined fragment. (figure 7.13 the guard is isCommandValid == true);

Altoperator = represents two or more alternative sets of event occurrences that could happen during execution; an Alt combined fragment must have two or more operands (regions) that contain alternative event occurrences. Each operand in Alt combined fragment has its own guard. Will execute the region that passes the guard.

Loopoperator = combined fragment with set of event occurrences that could happen multiple times during execution; has exactly one operand (region). Can define min/max values for number of iterations. If min == max, that is the exact number of iterations that are to occur, otherwise, can set to (0, *) for infinite.

The guard is re-evaluated after the min number of loops completes (then re-evaluated after each loop). After that, the loop breaks either after the Guard stops or max loops reached.

Par operator = represents two or more sets of event occurrences that can execute in parallel. Like the alt operator, par has two or more operands (regions) that execute in parallel. Though the events in each region can execute in parallel, the events within one region occur in top – down order of the lifeline. Each region can also have guards, that can terminate the process of that region.

Interaction Uses

Interaction use = to factor out a subset of event occurrences (perhaps a lower level view) and/or to decompose a complex set of event occurrences into a more readable diagram. Noted with a rectangle with pentagon on top left saying ref. The interaction use block must overlap the associated lifelines.

Actual gate = messages that enters / leaves an interaction use

Formal gate = messages that enters / leaves the referenced interaction

solidfish