Sequence diagrams

 

Definition

Sequence diagrams show how different objects cooperate.  Objects (roles or class instances) are defined, and cooperation between objects is represented by a sequence of messages between objects.

 

Objects can be connected to existing classes or created independently from any class.  If objects are connected to classes, you can then connect messages to operations.

 

Sequence diagrams (an example is shown below) are created in interactions.

 

An example of a sequence diagram

 

 

Lifelines

A lifeline represents an object in the interaction. It can be a representation of an instance.

 

There are several ways to create a lifeline in a sequence diagram.  The classic way is to click on the  "Create a lifeline" icon and then in the diagram background.  A new lifeline is then inserted and given a default name that you can edit.  This new lifeline doesn’t yet represent a model element, but you can then drag an element from the explorer view and drop it on the lifeline header to make this lifeline represent the element. If necessary (for example, the element dropped is a class), an instance of the dropped element is automatically created in the "Local" collaboration under the interaction and the lifeline will represent this instance.

 

The other way to create a lifeline in the diagram is to drag an element from the explorer view and to drop it directly on the diagram background. A new lifeline is created and will represent the element dropped. If necessary (for example, if the element dropped is a class), an instance of the dropped element is automatically created in the "Local" collaboration under the interaction and the lifeline will then represent this instance.

 

 

Execution specifications

An execution specification represents a period of activation on a lifeline.

 

Although they can be created in the usual way (by clicking on the  "Create an execution specification" icon and then drawing a rectangle on a lifeline), this is seldom necessary, as they will be automatically created when a message is created.

 

 

Messages

Messages are used in sequence diagrams to express the flow of communication between the different elements of the diagram.

 

There are several types of message:

·         Synchronous messages

·         Return messages

·         Asynchronous messages

·         Creation messages

·         Destruction messages

 

When creating a synchronous message, the corresponding execution specification and return message are also created when possible (in other words, always except if the message is lost).

 

When creating an asynchronous message, the corresponding execution specification is also created when possible (in other words. always except if the message is lost).

 

Synchronous and asynchronous messages can be found or lost.

 

To create a found message, simply click on the  "Create a synchronous message" icon or on the  "Create an asynchronous message" icon, and then click in the diagram background and on an element.

 

To create a lost message, click on the  "Create a synchronous message" icon or the  "Create an asynchronous message" icon, and then click on an element and in the diagram background.

 

If a synchronous or asynchronous message is destroyed, the corresponding return message will also be destroyed, if this exists.  In the same way, if a return message is destroyed, the corresponding synchronous or asynchronous message is also destroyed.  In both cases, the corresponding execution specification is destroyed, if this exists.

 

If a message is moved, all the elements underneath it are also moved.

 

Note:      A message created from one sequence object to another is graphically represented by an arrow.

 

 

Gates

Gates represent the syntactical interface between interactions, interaction uses and combined fragments and their surroundings.

 

Formal gates on an interaction are linked to actual gates on every interaction use referring to this interaction.

 

Gates on combined fragments are mostly used to represent the input and output points of the fragment.

 

 

Combined fragments

Combined fragments represent specific expressions in the sequence.  Their meaning depends heavily on the interaction operator used (which can be modified in the edition dialog box).

 

A combined fragment can be used to express parallel executions (through the "par" operator), conditional branching (through the "alt" operator) and many other things.  For a complete list of available operators and their meaning, see the "Interaction operators" paragraph below.

 

Combined fragments contain at least one interaction operand. Depending on the interaction operator, they may contain one or several.

 

Combined fragments must cover at least one lifeline at any time in order to have a meaning. Movements and resizing that might make the combined fragment not cover any lifeline are not allowed by Objecteering. On the other hand, moving the last lifeline out of a combined fragment will cause the said combined fragment to be automatically destroyed.

 

 

Interaction operands

An interaction operand represents one operand of the expression defined by the enclosing combined fragment.

 

An interaction operand can be added to a combined fragment by clicking first on the  "Create an interaction operand" button in the diagram tool bar, and then clicking anywhere on the combined fragment. The newly created interaction operand is always placed at the end of the combined fragment and separated from the previous interaction operand by a dotted line.

 

 

Interaction operators

An interaction operator defines the type of a combined fragment.   

 

The interaction operator for a combined fragment can be changed through the combined fragment dialog box.

 

The following interaction operators are available:

·         Alt: Alternative. This operator designates that the combined fragment represents a choice in behaviour. At most one of the interaction operands will be chosen. The chosen operand must have an implicit or explicit guard expression that evaluates to true at this point of the interaction. An implicit "true" guard is implied if the operand has no explicit guard. If none of the guards evaluates to true, none of the operands are executed and the rest of the enclosing interaction is executed.

·         Opt: Option. This operator designates that the combined fragment represents a choice of behaviour where either the (sole) operand happens or nothing happens. An option is semantically equivalent to an alternative where there is one operand with non-empty content and the second operand is empty.

·         Break. This operator designates that the combined fragment represents a breaking scenario in the sense that the operand is a scenario that is performed instead of the remainder of the enclosing interaction fragment. Such an operator with a guard is chosen when the guard is true and the rest of the enclosing interaction fragment is ignored. When the guard is false then the break operand is ignored and the rest of the enclosing interaction fragment is chosen. The choice between a break operator without  a guard and the rest of the enclosing interaction fragment is made non-deterministically. A combined fragment with a break interaction operator should cover all the lifelines of the enclosing interaction fragment.

·         Par: Parallel. This operator designates that the combined fragment represents a parallel merge between the behaviours of the operands. The elements of the different operands can be interleaved in any way as long as the ordering imposed by each operand as such is preserved.

·         Loop. This operator designates that the combined fragment represents a loop. The loop operand will be repeated a number of times. The guard may include a lower and an upper bound of the iterations of the loop, as well as a boolean expression.

·         Critical. This operator designates that the combined fragment represents a critical region. A critical region means that the elements of the operand cannot be interleaved with other elements (on those lifelines covered by the combined fragment). The region is handled atomically by the enclosing interaction fragment even though the enclosing interaction fragment may imply valid interleaving (such as with the "par" operator).

·         Neg: Negative. This operator designates that the combined fragment represents a sequence that is invalid. All interaction fragments that are different from the negative’s (sole) operand are considered positive, meaning that they describe valid sequences and should be possible.

·         Assert: Assertion. This operator designates that the combined fragment represents an assertion. The sequences of the operand of the assertion are the only valid continuations. All other continuations result in an invalid sequence.

·         Strict: Strict Sequencing. This operator designates that the combined fragment represents a strict sequencing between the behaviours of the operands. This defines a strict ordering of the operands on the first level within the combined fragment with the "strict" operator. Therefore the elements within the operands will not be directly compared with other elements of the enclosing combined fragment.

·         Seq: Weak Sequencing. This operator designates that the combined fragment represents a weak sequencing between the behaviours of the operands. A weak sequencing is defined by the sequences with the following properties:

o        The ordering of the elements within each of the operands is maintained in the result.

o        The elements on different lifelines from different operands may come in any order.

o        The elements on the same lifeline from different operands are ordered such that an element from the first operand comes after that of the second operand.

Thus weak sequencing reduces to a parallel merge when the operands are on disjunct sets of participants. Weak sequencing reduces to strict sequencing when the operands work on only one participant.

·         Ignore. This operator designates that there are some message types that are not shown within the combined fragment. These messages are considered insignificant and are implicitly ignored if they appear in a corresponding execution. Alternatively, one can understand "ignore" to mean that the messages types that are ignored can appear anywhere in the sequence.

·         Consider. This operator designates which messages should be considered within this combined fragment. This is equivalent to defining every other message to be "ignored".

 

 

State invariants

A state invariant is a runtime constraint on a participant of the interaction. It can be used to specify a variety of different kinds of constraints, such as values of attributes or variables, internal or external states, and so on.

 

 

Interaction uses

An interaction use refers to an interaction. It is a shorthand for copying the contents of the referred interaction where the interaction use is.

 

Formal gates of the referenced interaction are connected to the actual gates of the interaction use.

 

Interaction uses must cover at least one lifeline at any time to have a meaning.  Movements and resizing that might make the interaction use not cover a lifeline are not allowed by Objecteering. On the other hand, moving the last lifeline out of an interaction use will cause the said interaction use to be automatically destroyed.

 

 

Part decompositions

A part decomposition is a description of the internal interaction(s) of one lifeline relative to the current interaction.

 

The part decomposition in an interaction describes the behavior of the internal structure of the lifeline it is associated to, in relation to the interaction where the part decomposition is referenced.

 

 

Migrating UML 1.4 sequence diagrams to UML 2 sequence diagrams

If your model contains sequence diagrams created using an earlier version of Objecteering, these UML 1.4 sequence diagrams are automatically migrated to UML 2 through the automatic creation of a UML 2 sequence diagram when the UML 1.4 sequence diagram is opened.  This UML 2 diagram has the same name as the earlier diagram, belongs to the same model element and is directly displayed.

 

The new diagram retains the following information from the migration of the earlier diagram:

 

Association labels are positioned using the new intelligent positioning system implemented in UML 2 diagrams.

 

Fork messages are migrated as separate messages, and their layouting is then incorrect.

 

Elements not managed by diagram migration are as follows:

 

Since the earlier UML 1.4 sequence diagram is conserved, it can still be opened after migration in the usual way (either by double-clicking on it in the Objecteering explorer, or through the "Edit" command in the context menu).  The diagram is then opened in read-only mode, meaning that only the zoom and grab functions are active.

 

We recommend that the UML 1.4 sequence diagram be deleted once it has been migrated.  If the new UML 2 sequence diagram is renamed, the migration procedure will once again be run the next time the UML 1.4 sequence diagram is opened.