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.
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.
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.
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
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 lifeline detects when the pedestrian presses the crossing
button. Add four more lifelines using the down arrow named
poller lifeline checks if
the pedestrian crossing button has been pressed,
switch processes the
controller determines which color the pedestrian lamp and
traffic light should display, and
lampController changes the traffic
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
switchout port and
sw port are
connected in the model, a message is created from 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.
There are three directions for edges:
crossing — The edge expression is either rising or falling
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.
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.
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
sw in the Symbols pane.
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
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
Since there is an existing connection in the architecture model, a message is
created from source port
Click the message and double-click the empty message label that appears. Enter this condition representing the port and constraint.
When the message
switchEvent is received and its value is
1, the message has occurred and is valid.
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 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.
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
condition for which the message will be executed.
This condition represents when the
inhibit flag is set to
1. Thus, pedestrian crossing is not controlled by a walk signal on
Create a message with a message label inside the second operand.
For the first alternative operand, since the
inhibit flag is set
0, the first message to the
is recognized when the
pedRequest message is activated. Then, when
switchPed message value is
lampController lifeline will make the pedestrian lamp turn
For the second alternative operand, since the
inhibit flag is set
switch bypasses the
controller, and the message
switchPed with a
2 goes directly to the
switchPed message value of
2 does not affect
the traffic signal.
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.
The sequence diagrams in this example represent operative scenarios in the architecture model.
PressDetection sequence diagram: The pedestrian presses the pedestrian crossing button and the signal
sw rises to
poller lifeline is activated, and a
switchEvent message occurs on the
switch lifeline to change the traffic signals to allow the pedestrian to cross.
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.
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.
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
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
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);