Model Complex Interactions Using Fragments in Sequence Diagrams
You can use sequence diagrams integrated with System Composer™ to describe system behaviors as the interaction between components in a sequence of message exchanges.
An interaction imposes an order for message activation. To specify message activation and ordering, you can use fragments and operands. A fragment encloses a group of lifelines and messages within an interaction to allow for the specification of more complex patterns of interaction. The type of fragment defines message activation and ordering such as looping, optional, and alternative sequences. An operand is a region in a fragment, or group of messages. The condition of an operand specifies whether the messages inside the operand execute.
This topic shows you how to use fragments and operands to describe the interactions between components of a control system at a traffic intersection.
Intersection Control System Example
This intersection control system example contains sequence diagrams with fragments to describe light sequencing at a traffic intersection. The model describes various scenarios shows how to use combined fragments to specify message activation and ordering.
Open the architecture model that contains the sequence diagrams.
model = systemcomposer.openModel("IntersectionControlSystemS");
To view the sequence diagrams, open the Architecture Views Gallery.
interaction = model.getInteraction('SimpleSequence');
open(interaction)
Describe Interactions within Control System
You can represent each component from your architecture model in a sequence diagram with a lifeline.
The lifelines of the sequence diagrams of the
IntersectionControlSystemS
architecture model represent instances
of architecture components.
LightSequencer
– Processes signals from the main and side street controllers and changes the traffic light colorsMainStreetController
– Determines which color the pedestrian lamp and traffic light should display on the main streetMainHWInterface
– Detects when pedestrian crossing button has been pressed on the main streetSideStreetController
– Determines which color the pedestrian lamp and traffic light should display on the side streetSideHWInterface
– Detects when pedestrian crossing button has been pressed on the side street
Add Messages
Components of your architecture are connected through ports and connectors that represent an exchange of information. Similarly, in sequence diagrams, lifelines are connected through message ends and messages. Each message describes a pair of events. A signal-based message describes signal write and signal read events. A message-based message describes message send and message receive events.
For more information about lifelines and messages, see Describe Interactions with Lifelines and Messages.
Specify Message Execution Logic with Fragments
Use fragments to add conditional behavior to a group of messages within an interaction.
To add a fragment to a sequence diagram, click and drag around a group of messages or other fragments. A blue box appears. To select from a list of possible fragments, pause on the ellipsis (…) that appears.
Select the type of fragment to add to the sequence diagram. The type of fragment specifies the order that messages execute within your sequence diagram. These fragments are supported:
Alternative (Alt Fragment)
Optional (Opt Fragment)
Loop (Loop Fragment)
Weak sequencing (Seq Fragment)
Strict sequencing (Strict Fragment)
Parallel (Par Fragment)
Seq
Fragment
A Seq
fragment contains one operand and represents weak
sequencing, which 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.
Although Seq
fragments have no visual representation, the
SimpleSequence
sequence diagram is an example of a
Seq
fragment. The SimpleSequence
interaction specifies this sequence of message events.
When the
sensor
signal rises from below1
to a value of1
or above, the signal is received by theMainStreetController
lifeline.The
MainStreetController
lifeline sends aPedButtonMain
Simulink® message to theLightSequencer
lifeline, which controls the lights at the intersection.When the
LightSequencer
lifeline receives the message, theLightSequencer
lifeline then sends a message to theMainHWInterace
lifeline to turn the pedestrian lamp red, indicating that pedestrians should wait.
Strict
Fragment
A 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 how
far down the lifeline each message is sent. Messages are received in the order on
the operand regardless of which lifeline receives the messages.
The Strict
fragment in the StrictExample
interaction specifies that 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
An Opt
fragment may contain one or more operands and indicates
that the described message events might occur. Each operand has a constraint to
determine whether the group of messages are valid.
The events in an Opt
fragment occur if 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 the intersection control system, the state
signal indicates
the state of the main and side street controllers. The
LightSequencer
lifeline issues a Stop
command to a controller if the controller is in the flowing
(Green
) state, which is indicated by the value
2
.
The Opt
fragment in the OptExample
specifies
the following scenario.
When traffic is flowing (Green
), indicated by the
LightSequencer/mainState==2
condition:
The
LightSequencer
lifeline sends aStop
command to theMainStreetController
lifeline.The
mainState
signal falls to1
, indicating a stopping (Yellow
) state.
Loop
Fragment
A Loop
fragment contains one operand with an expression
describing the minimum (lower bound) and maximum (upper bound) number of times that
the operand repeats. The upper bound can be *
, indicating 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 events in the Loop
fragment repeat if 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.
You can also define a constraint on a Loop
fragment operand
that determines whether the loop executes. When the Boolean expression is
false
, the software skips the loop.
The Loop
fragment in the LoopExample
interaction describes the default light sequence of the main street traffic lights.
The
LightSequencer
lifeline issues aGo
command.The
MainStreetController
lifeline sends a message to theMainHWInterface
lifeline to change the traffic light to green.In the loop, the
MainStreetController
lifeline sends messages to theMainHWInterface
lifeline to cycle through changing the traffic light from yellow to red to green.
The lower and upper bounds of the loop fragment are the default values
of 0
and *
, respectively, indicating that the
loop fragment allows any number of iterations.
Alt
Fragment
An Alt
fragment is like an Opt Fragment except
an Alt
fragment has two or more operands, each describing a
different message order.
The events for each operand in an Alt
fragment occur if 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 Alt
fragment in the AltExample
interaction represents the alternative scenarios for a pedestrian requesting to
cross wither the main street or the side street. For a description of the first
operand, see Seq Fragment.
Par
Fragment
A Par
, or parallel, fragment contains two or more operands and
indicates that events can occur in parallel. In a Par
fragment,
the order of operands is enforced, but the order of messages within each operand
follows weak sequencing.
The Par
fragment in the ParExample
interaction represents the scenario of a pedestrian requesting to cross a street and
all traffic at the intersection stopping.
The
Alt
fragment indicates that the walk signal on the main street and side street are red.The
Par
fragment indicates that the walk signal on the main street and side street are green, but the order of these messages does not matter.
Messages with Ambiguous Order
Due to the nature of signal semantics in diagrams, predicting the ordering between signal
edges and other events that occur in the same simulation step can be difficult. A signal
edge is where a signal value passes through a threshold indicated by the rising,
falling, or crossing keywords. Changes to your 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
corresponding 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.
See Also
Tools
Functions
Objects
systemcomposer.arch.Model
|systemcomposer.interaction.Interaction
|systemcomposer.interaction.Fragment