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:

1. Signal read

2. Signal write

3. Message send

4. 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.

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) 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 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.

Related Topics

• Describe System Behavior Using Sequence Diagrams
• Implement Component Behavior Using Simulink
• Implement Component Behavior Using Stateflow Charts
• Implement Component Behavior Using Simscape
• Define Port Interfaces Between Components

×

Open Example

You have a modified version of this example. Do you want to open this example with your edits?

No, overwrite the modified version Yes