Describe System Behavior Using Sequence Diagrams

A sequence diagram is a behavior diagram that represents the interaction between structural elements of an architecture as a sequence of message exchanges. You can use sequence diagrams to describe how the parts of a static system interact.

You can use sequence diagrams in System Composer™ by accessing the Architecture Views Gallery. Sequence diagrams are integrated with architecture models. For more information on how to create and use sequence diagrams with an architectural model, see Use Sequence Diagrams with Architecture Models.

In this example, you will learn about the basic terminology and functions of a sequence diagram in two stages.

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.

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.

Note

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

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

Open the Model

This example uses:

Open Model

This example shows a traffic light example that contains sequence diagrams to describe pedestrians crossing an intersection. Use this example to construct your own sequence diagrams.

Add Lifelines and Messages

Open the Architecture Views Gallery by navigating to Modeling > Architecture Views.
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 Element 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, and a constraint determines whether the message is valid. For signal messages, the trigger is called an edge.
You can enter a condition that specifies a triggering edge with a direction and an expression. You can also optionally add a constraint in square brackets to the message. Constraints consist of a MATLAB^® Boolean expression acting on the inputs of the destination lifeline.
direction(signalPort(+|-)positiveReal)[booleanExpression]
There are three directions for edges:
- crossing — The edge expression is either rising or falling past zero.
- 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 below zero to a value equal to or less than zero.
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 events, sequence diagrams also support 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 switchEvent is received and its value is 1, the message has occurred and is valid.

Add Fragments and Operands

You can use fragments to describe more complex sequences such as alternatives. Fragments have one or more operands depending on the kind of fragment. Operands can contain messages and additional fragments. You can express the precondition of an operand as a MATLAB Boolean expression using the inputs of any 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 composite fragments appears:
- Alt Fragment
- Opt Fragment
- Loop Fragment
- Seq Fragment
- Strict Fragment
- Par Fragment
Select Alt 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
```
The 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 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 condition 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 alternative operand, since the inhibit flag is set to 0, the first message to the controller lifeline is recognized when the pedRequest message is activated. Then, when the switchPed message value is 1, the lampController lifeline will make the pedestrian lamp turn green.
For the second alternative operand, since the inhibit flag is set to 1, the switch bypasses the controller, and the message switchPed with a value of 2 goes directly to the lampcontroller. The switchPed message value of 2 does not affect the traffic signal.

Traffic Light Example for Sequence Diagrams

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 yellow to green.
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)

The sequence diagrams in this example represent operative scenarios in the architecture model.

1. PressDetection sequence diagram: The pedestrian presses the pedestrian crossing button and the signal sw rises to 1. The poller lifeline is activated, and a switchEvent message occurs on the switch lifeline to change the traffic signals to allow the pedestrian to cross.

2. SignalSequence sequence diagram: The pedestrian presses the pedestrian crossing button, and the signal sw rises to 1. After some intermediary events, the lampController lifeline transmits a trigger signal to the ped lamp lifeline to change pedestrian lamp traffic colors from RED (stop) to GREEN (go), allowing pedestrians to cross.

3. PedestrianCross sequence diagram: First, the traffic value is 3, which indicates that the traffic light color is green. The traffic light loops from yellow (2) to red (1) to green (3) and again. When the pedestrian crossing button is pressed and the controller lifeline recognizes a valid pedRequest message, the traffic lamp changes from yellow (2) to red (1), which allows the pedestrians to cross. Then, the main loop continues.

4. Inhibit sequence diagram: The inhibit flag determines whether a pedestrian crossing button is set up for pedestrians to press to control the traffic lamp signal on an intersection and cross. When inhibit is set to 0, the crossing button exists. When inhibit is set to 1, the crossing button does not exist. The switchEvent value is 1, which indicates that the pedestrians would like to cross. Once the switchEvent value is set to 1, if inhibit is 0, the controller lifeline recognizes the pedRequest message to initiate a change in the pedestrian lamp color. Additionally, the switchPed value is 1, so the traffic lamp will change from yellow to red. Otherwise, if inhibit is 1, the switchPed value is 2, so the traffic lamp will continue normal operation and not change to red to specifically allow the pedestrians to cross.

Simulate Architecture Model

You can execute the model after setting these variables.

createWorkSpaceVar("SwitchInputs",[0 11 18],[-1 1 -1]);
createWorkSpaceVar("inhibitFlag",1,0);