Author Sequence Diagrams Interactively

You can create, edit, and simulate sequence diagrams in System Composer™ by accessing the Architecture Views Gallery. Sequence diagrams describe operational system behavior. Use a sequence diagram to validate an expected sequence of events as system design proceeds. You will learn about the basic terminology and functions of a sequence diagram:

Add lifelines and messages with message labels including triggers and constraints to represent interactions.
Include fragments and operands with constraints to further specify the behavior of the interaction.

A lifeline in a sequence diagram represents a component in the architecture. A message represents a communication across a path between the source lifeline and destination lifeline. The path for a message must consist of at least two ports and one connector from the architecture model. With nested messages, the path is more complex due to the hierarchy to be navigated.

For a roadmap of the sequence diagram topics, see Describe System Behavior Using Sequence Diagrams.

Traffic Light Architecture Model and Sequence Diagram

This figure shows a traffic light architecture model and a corresponding sequence diagram that describes one operative scenario. The traffic light model describes a cycling traffic light, the pedestrian crossing button being pressed, and the lights changing so pedestrians can cross.

An architectural model and a sequence diagram with a lifeline, operand, message, and fragment.

To learn how to execute this sequence diagram to simulate the model, see Simulate Sequence Diagrams for Traffic Light Example.

Note

This example uses Stateflow^® blocks. If you do not have a Stateflow license, you can open and simulate the model but can only make basic changes, such as modifying block parameters.

To access the example files, open the example below.

Traffic Light Example

This example uses:

Open Live Script

This traffic light example contains sequence diagrams to describe pedestrians crossing an intersection. The model describes these steps:

The traffic signal cycles from red to green to yellow.
When the pedestrian crossing button is pressed, if the traffic signal is green, the traffic signal transitions from yellow to red for a limited time.
The pedestrians cross while the walk signal is active.

Open the System Composer model that contains the sequence diagrams.

model = systemcomposer.openModel('TLExample');

Open the Architecture Views Gallery to view the sequence diagrams.

openViews(model)

Add Lifelines and Messages

A lifeline is represented by a head and a timeline that proceeds down a vertical dotted line.

The head of a lifeline represents a component in an architecture model.

A message sends information from one lifeline to another. Messages are specified with a message label.

Navigate to Modeling > Sequence Diagram to open sequence diagrams in the Architecture Views Gallery.
To create a new sequence diagram, click New > Sequence Diagram.
A new sequence diagram called SequenceDiagram1 is created in the View Browser, and the Sequence Diagram tab becomes active. Under Sequence Diagram Properties, rename the sequence diagram Inhibit.
Select Component > Add Lifeline to add a lifeline. A new lifeline with no name is created and is indicated by a dotted line.
Click the down arrow and select source. The source lifeline detects when the pedestrian presses the crossing button. Add four more lifelines using the down arrow named poller, switch, controller, and lampController. The poller lifeline checks if the pedestrian crossing button has been pressed, switch processes the signal, controller determines which color the pedestrian lamp and traffic light should display, and lampController changes the traffic light colors.
Draw a line from the source lifeline to the poller lifeline. Start to type sw in the To box, which will automatically fill in as you type. Once the text has filled in, select sw.
Since the switchout port and sw port are connected in the model, a message is created from the switchout port to the sw port in the sequence diagram.
A message label has a trigger and a constraint. A trigger determines whether the message occurs. A constraint determines whether the message is valid.
An informal message label is written in natural language. A formal message label is in the form of trigger[constraint] where trigger represents the identifying event for this message, and constraint represents additional expressions that are expected to be true when this message occurs.
- For signal-based communication, a trigger is also called an edge and can described in the format direction(signal [+|-] value). You can enter a condition that specifies a triggering edge with a direction and an expression. The direction can be:
  - rising — The edge expression is rising from strictly below zero to a value equal to or greater than zero.
  - falling — The edge expression is falling from strictly above zero.
  - crossing — The edge expression is either rising or falling past zero.
- For message-based communication, a trigger can be described simply by using the name of the input message port, and represents the arrival of a message.
- For both signal and message-based communication, a constraint expression in square brackets on the message label is an optional MATLAB^® Boolean expression involving the names of the inputs to the destination lifeline.
Click on the message and double-click on the empty message label that appears. Enter this condition and constraint.
```
rising(sw-1)[sw==1]
```
The message will be triggered when the sw signal rises from below 1 to a value of 1 or above. The constraint in square brackets indicates that if sw is not equal to 1, the message is invalid.
Note
Only destination elements are supported for message labels. In this example, switchout is a source element and cannot be included.
The signal name sw is valid input data on the port for a Stateflow chart behavior. The poller component with state chart behavior has sw in the Symbols pane.
Note
The signal name can also be a data element on a data interface on a port. Enter Tab to autocomplete the port and data element names. For more information, see Represent System Interaction Using Sequence Diagrams.
In this example, when the sw signal becomes 1, the pedestrian crossing button has been pressed, and a message to the poller lifeline is recognized.
In addition to signal-based communication, sequence diagrams also support message-based communication, or message events. Create a message by drawing a line from the poller lifeline to the switch lifeline. Start typing switchEvent in the To box until switchEvent is available to select.
Since there is an existing connection in the architecture model, a message is created from source port switchEvent.
Click the message and double-click the empty message label that appears. Enter this condition representing the port and constraint.
```
switchEvent[switchEvent==1]
```
When the message event switchEvent is received and its value is 1, the message has occurred in the corresponding architecture model and validates the architectural design.

Add Fragments and Operands

A fragment indicates how a group of messages specified within execute or interact.

A fragment is used to model complex sequences, such as alternatives, in a sequence diagram.

An operand is a region in a fragment. Fragments have one or more operands depending on the kind of fragment. Operands can contain messages and additional fragments.

Each operand can include a constraint to specify whether the messages inside the operand execute. You can express the precondition of an operand as a MATLAB Boolean expression using the input signal of a lifeline.

To access the menu of fragments:

Click and drag to select two messages.
Pause on the ellipsis (...) that appears to access the action bar.
A list of fragments appears:
- Alternative (Alt Fragment)
- Optional (Opt Fragment)
- Loop (Loop Fragment)
- Weak sequencing (Seq Fragment)
- Strict sequencing (Strict Fragment)
- Parallel (Par Fragment)
For more information, see Author Sequence Diagram Fragments.
Select the Alt Fragment fragment.
The Alt Fragment fragment is added to the sequence diagram with a single operand that contains the selected messages.
Select the fragment to enter an operand condition. Choose a fully qualified name for input data and use a constraint condition relation.
```
switch/inhibit==0
```
This constraint is a precondition that determines when the operand is active. This constraint specifies that the inhibit flag is set to 0. Thus, pedestrian crossing is allowed at this intersection using a pedestrian lamp.
The messages inside an operand can only be executed if the constraint condition is true.
Highlight the first operand under the Alt Fragment fragment and select from the toolstrip Fragment > Add Operand > Insert After. A second operand is added.
Add a constraint condition relation to the second operand. The second operand in an Alt Fragment fragment represents an elseif condition for which the message will be executed.
```
switch/inhibit==1
```
This constraint represents when the inhibit flag is set to 1. Thus, pedestrian crossing is not controlled by a walk signal on that intersection.
Create a message with a message label inside the second operand.
For the first operand in the Alt Fragment fragment, since the inhibit flag is set to 0, the first message to the controller lifeline is recognized and validates the pedRequest message. Then, when the switchPed message value is 1, the lampController component behavior allows pedestrians to cross.
For the second operand in the Alt Fragment fragment, since the inhibit flag is set to 1, the switch bypasses the controller. The message switchPed with a value of 2 goes directly to the lampcontroller which does not affect the traffic signal. Pedestrian crossing is not specifically supported in this traffic intersection.