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 colors

• MainStreetController – Determines which color the pedestrian lamp and traffic light should display on the main street

• MainHWInterface – Detects when pedestrian crossing button has been pressed on the main street

• SideStreetController – Determines which color the pedestrian lamp and traffic light should display on the side street

• SideHWInterface – 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.

1. When the sensor signal rises from below 1 to a value of 1 or above, the signal is received by the MainStreetController lifeline.

2. The MainStreetController lifeline sends a PedButtonMain Simulink^® message to the LightSequencer lifeline, which controls the lights at the intersection.

3. When the LightSequencer lifeline receives the message, the LightSequencer lifeline then sends a message to the MainHWInterace 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:

1. The LightSequencer lifeline sends a Stop command to the MainStreetController lifeline.

2. The mainState signal falls to 1, 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.

1. The LightSequencer lifeline issues a Go command.

2. The MainStreetController lifeline sends a message to the MainHWInterface lifeline to change the traffic light to green.

3. In the loop, the MainStreetController lifeline sends messages to the MainHWInterface 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.

1. The Alt fragment indicates that the walk signal on the main street and side street are red.

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