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: signal-based and Simulink message-based. You can specify events in a sequence diagram using messages between lifelines. Each sequence diagram message describes a pair of events. For signal-based communication, the pair of events is write followed by read. For message-based communication, 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 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 (…) that appears 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 uses:

Open Live Script

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");

To view the sequence diagrams, open the Architecture Views Gallery.

openViews(model)

Fragment Semantics

Fragments in a sequence diagram execute messages in a specific order based on the kind of fragment. These fragments are supported:

Alternative (Alt Fragment)
Optional (Opt Fragment)
Loop (Loop Fragment)
Weak sequencing (Seq Fragment)
Strict sequencing (Strict Fragment)
Parallel (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 a 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.

Weak sequencing fragment for pedestrian crossing in a sequence diagram

This sequence diagram specifies that after the sensor signal from its hardware interface rises through 1, the MainStreetController sends a PedButtonMain Simulink 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 how far down the lifeline they are sent. Messages are received in the order on the operand regardless of which lifeline receives them.

Strict sequencing fragment for pedestrian crossing in a sequence diagram

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 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 Opt Fragment operand runs optionally

In this sequence diagram, LightSequencer knows the state of each controller due to the state signal. 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 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 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.

Loop fragment with lower and upper bounds

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.

Loop fragment for traffic light color changes

This sequence diagram describes the default cycle of the main street traffic lamps. LightSequencer issues a Go command so that MainStreetController tells 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 the loop fragment 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 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.

Traffic light example with alt fragment

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 the order of events in different operands has no constraints. You should use Par fragments wherever order between messages is not important because this fragment imposes few constraints on system design.

Par fragment for pedestrian crossing in a sequence diagram

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.

Ambiguous order symbols in a sequence diagram.

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.