Author Sequence Diagram Fragments
A sequence diagram describes an expected order of the events logged during execution of a Simulink® model. There are four event types:
Signal read
Signal write
Message send
Message receive
These four events cover the two interaction styles described by sequence diagrams: signals and messages. You can specify events using messages between lifelines. Each message describes a pair of events. For signals, the pair of events is write followed by read. For messages, the pair of events is send followed by receive.
To learn more about simulating sequence diagrams, see Simulate Sequence Diagrams for Traffic Light Example.
A fragment indicates how a group of messages within it execute or interact.
A fragment is used to model complex sequences, such as alternatives, in a sequence diagram.
To add a fragment to a sequence diagram, click and drag around a group of messages or other fragments. A blue box appears. Pause on the ellipsis (…) menu to select from a list of possible fragments.
The fragment you select is added in the sequence diagram. For more information, see Add Fragments and Operands.
For a roadmap of the sequence diagram topics, see Describe System Behavior Using Sequence Diagrams.
Sequence Diagram Fragments
This example shows an intersection control system to demonstrate how composite fragments are used in sequence diagrams.
Open the System Composer model that contains the sequence diagrams.
model = systemcomposer.openModel("IntersectionControlSystemS");
Open the Architecture Views Gallery to view the sequence diagrams.
openViews(model)
Fragment Semantics
Fragments in a sequence diagram execute messages in a specific order based on the kind of fragment. The following fragments are supported:
Alternative (
Alt
) fragmentOptional (
Opt
) fragmentLoop (
Loop
) fragmentWeak sequencing (
Seq
) fragmentStrict sequencing (
Strict
) fragmentParallel (
Par
) fragment
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 any lifeline.
Seq
Fragment
The Seq
fragment contains one operand and represents weak
sequencing. The Seq
fragment specifies the same ordering
constraints as a sequence of messages with no fragment.
Weak sequencing means that the sequence of events on each lifeline is respected, but the sequencing of events between lifelines can differ from the order shown in the operand.
On any given lifeline, any event must occur after the event immediately above it on the lifeline. If a message send or write event occurs from the same lifeline, the order is determined by from how far down the lifeline the event occurs.
The send or write event for a message must occur before the corresponding receive or read event.
If two different message send and receive events or write and read events occur on the same lifeline, then the first message can be received before or after the second message is sent.
This sequence diagram specifies that after the sensor
signal from its hardware interface rises through 1
, the
MainStreetController
sends a
PedButtonMain
message to
LightSequencer
, which controls the intersection.
LightSequencer
then tells the hardware interface to turn
the pedestrian lamp red, indicating that pedestrians should wait.
Strict
Fragment
The Strict
fragment contains one operand and represents
strict sequencing.
Strict sequencing follows the weak sequencing found in a Seq Fragment with the additional constraint that the order of the events in the operand be followed exactly. If messages are sent from the same lifeline, the order is determined by from how far down the lifeline they are sent. Messages are received in the order on the operand regardless of which lifeline receives them.
This sequence diagram is an example of strict sequencing for an intersection controller. The traffic lights on the side street should be set to red before the traffic lights on the main street are set to green. Without strict sequencing, the order in which the street controllers perform their tasks would be undefined.
You can use the Seq Fragment for
a subset of the messages in a Strict
fragment if all the
messages do not require strict ordering.
Opt
Fragment
The Opt
fragment includes a single operand and indicates
that the events described might occur or not. A constraint determines whether
the group of messages are valid. If the group of messages are valid, they can
execute, otherwise, this fragment is skipped. If no constraint is specified, the
messages in the Opt
fragment are executed only if the
messages become valid.
The events in an Opt
fragment occur if all of these
conditions are met:
The current event is a valid first event for the operand.
The condition expressed by the operand constraint evaluates to
true
.
In this sequence diagram, the LightSequencer
knows the
state of each controller due to the state
signal. The
LightSequencer
issues a Stop
command
to a controller if it is in the flowing (Green
) state, which
is indicated by the value 2
. The operand in the
Opt
fragment is executed only if a
Stop
command is present and its
mainState
signal has the value 2
.
After the Stop
command, the mainState
signal falls to 1, indicating a stopping (Yellow
)
state.
Loop
Fragment
A Loop
fragment has a single operand with a constraint and
an expression describing the minimum (lower bound) and maximum (upper bound)
number of times that the operand repeats. The upper bound can be
*
, indicating that there is no maximum. The lower bound
can be 0
, indicating that the operand is optional. The
default is a lower bound of 0
and an upper bound of
*
. With the default lower and upper bounds, the
Loop
fragment repeats a certain number of times according
to the simulation time or the lower and upper bounds of the architecture
model.
The single operand in the Loop
fragment repeats if all of
these conditions are met:
The current event is a valid first event for the operand.
The condition expressed by the operand constraint evaluates to
true
.The number of iterations is less than or equal to the upper bound.
The lower bound (1
) is the minimum number of iterations of
the loop. The upper bound (3
) is the maximum. You can also
define a constraint on a Loop
fragment operand that
determines whether the loop executes. When the Boolean expression is
false
, the loop is skipped.
This sequence diagram describes the default cycle of the main street traffic
lamps. The LightSequencer
issues a Go
command so that the MainStreetController
tells the
MainHWInterface
to turn the green lamps on. The
controller then cycles the lights repeatedly through yellow, red, and green
lamps, as indicated by the Loop
fragment. The lower and upper
bounds of the loop fragment are the default values of 0
and
*
, respectively, indicating that it allows any number of
iterations.
Alt
Fragment
The Alt
fragment is like an Opt Fragment
except that it has two or more operands, each describing a different message
order.
The events for each operand in an Alt
fragment occur if all
of these conditions are met:
The current event is a valid first event for the operand.
The condition expressed by the operand constraint evaluates to
true
.
This sequence diagram shows that there are crossing buttons on the main street and the side street and either may be pressed. For a description of the first operand, see the sequence diagram for the Seq Fragment.
Par
Fragment
Par
stands for parallel. A Par
fragment
can have two or more operands. In a Par
fragment, the order
of events in each operand is enforced, but there is no constraint on the order
of events in different operands. You should use Par
fragments
wherever order between messages is not important because this fragment imposes
few constraints on system design.
No matter which crossing button the pedestrian presses, the controller stops
traffic on both streets. This sequence diagram specifies this state using an
Alt
fragment for the red lamp color. The green light that
indicates safety in crossing, is shown on both streets. The
Par
fragment indicates that both the main and side
streets show the green color, but order does not matter.
Messages with Ambiguous Order
Due to the nature of signal semantics in block diagrams, predicting the ordering
between signal edges and other events that occur in the same simulation step can be
difficult. Signal edges are where a signal value passes through a threshold
indicated by the rising, falling, or crossing keywords. Small changes to the
architecture model can change the order of signal events represented by sequence
diagrams. When a signal edge occurs in the same simulation step as another event,
both messages are marked with an symbol . You can examine both the sequence
diagram and underlying architecture model for potential ambiguity.
To specify that these messages may occur in any order within the same time step, place each message in separate operands of a Par Fragment. The simulation interprets these messages to occur in any order. Alternatively, change the behavior of the underlying system so these events happen on different time steps.