Chapter 5

Sequence diagrams

In the previous chapters, we have seen different diagrams. Use case diagrams describetasks that a system is supposed to perform. It gives high-level information about how auser should interact with the system. Class diagrams specify the structure and the oper-ations related to the data used by the system. A sequence diagram can help specifyingthe link between a use case and the methods and classes defined in class diagrams. Itis therefore important to ensure consistency between these three kinds of diagrams.

5.1 Learning objectives of this chapterThe learning objectives of this chapter are the followings. At the end of this chapter,you shall

• know what is a UML sequence diagram;

• be capable of creating detailed UML sequence diagrams;

• be capable to ensure consistency between sequence, class, and use case dia-grams.

5.2 Sequence diagram

5.2.1 Overview and some definitionsA sequence diagrams basically shows how actors and objects interact to realise a usecase scenario. Figure 5.1 shows a simple sequence diagram. It focuses on the messageexchange between a number of lifelines.

Lifeline A lifeline represent the lifetime of a participant in the interaction. A lifelinecan be an actor, a class, or any object involved in the use case. In a lifeline time startsat the top and increases as we go down the lifeline. Regarding notation:

35

36 CHAPTER 5. SEQUENCE DIAGRAMS

Figure 5.1: A simple sequence diagram.

• actors will be denoted by their name or using the usual UML pictogram foractors;

• a class A will be denoted by a rectangle named :A;

• an object anObject of class A will be denoted by a rectangle named anObject:A.

Figure 5.2: A short sequence diagram.

Figure 5.2 shows an example of a simple sequence diagram. In this sequence dia-gram, an actor first sends a message msg1 to an instance of class A. After that, class Asends a message msg2 to an instance of class B. Finally, B sends a response to A, thatsends a response to the actor.

5.2. SEQUENCE DIAGRAM 37

The intuition behind ”sending a message” is that sending a message means callinga given method of a class. In Figure 5.2, this means that the actor is calling methodnamed msg1 from class A. This also means that class A must have a method namedmsg1. A similar remark holds for method msg2 of class B.

There is an implicit rule that a message is sent before it is received.The rectangles are called activations. An activation specifies that a lifeline is active.

Figure 5.3: Self activation.

As shown in Figure 5.3, a lifeline can activate itself. The activation is then shownwith a slight offset. This is used to represent computations executed by the lifeline.

Note that only actors can send messages ”out-of-the-blue”. Actors initiate interac-tions with the system. The system – and its objects – only react to actors’ stimuli.

5.2.2 Semantics

The UML standard sketches the semantics of sequence diagrams using event traces.Every time a message is sent and received, this creates two events, namely, a sendevent and a receive event. A trace is a – possibility infinite – sequence of events. Thesemantics of a diagram is defined by two sets of traces:

1. A set of valid traces, that is, the traces representing valid behaviours;

2. a set of invalid traces, that is, the traces representing invalid behaviours.

The invalid behaviours are used to define some operators (like neg, see later in thischapter). Most of the times, the semantics are defined by the valid behaviours.

We will not attempt to formalise the semantics any further. We intentionally – as itis done in the UML standard – remain at the level of natural language and intuition.

Intuitively, the semantics of the diagram in Figure 5.2 is ”message msg1 is sentand received, message msg2 is then sent and received, message response is sent andreceived, an un-named message is sent and received”.

38 CHAPTER 5. SEQUENCE DIAGRAMS

5.2.3 Synchronous vs. Asynchronous communicationsIf there is no concurrency, exactly one object is active – or computing – at any giveninstant. In that case, activation computations behave like a stack.

Figure 5.4: Asynchrony and concurrency.

Figure 5.4 shows asynchronous communications and introduces concurrency, thatis, two lifelines are active at the same instant. As emphasised in the picture, you shouldnotice the difference in the arrow-head of the arrow labelled ”msg2”. This type ofarrow indicates an asynchronous communication. The lifeline emitting the message– or calling a particular method – remains active after sending the message. In thisexample, once ”msg2” is sent, both class A and class B are active.

5.3 Object creation and destructionIt is possible to indicate creation and destruction of objects. Figure 5.5 shows an exam-ple. A creation action is done using an asynchronous arrow as the creator is still activeafter creation. The creator should not have to wait that the created object terminates toresume execution. Notice that by convention destruction of objects uses synchronousmessages.

5.4 OperatorsThe UML standard defines several operators than can be used to further specify life-lines and their interactions. In this course, we cover a subset only of all the possibleoperators.

5.4. OPERATORS 39

Figure 5.5: Creation and destruction.

Figure 5.6: Overview operator syntax.

40 CHAPTER 5. SEQUENCE DIAGRAMS

Figure 5.6 shows an overview of the operator syntax. As it can be seen in thepicture, an operator has zero or more conditions, and one or more operands. An oper-ator defines a combined fragments composed of the different operands. Each operanddefines an area with a different behaviour.

5.4.1 Alternatives: alt

Figure 5.7: Illustration of the ’alt’ operator.

Operator ’alt’ introduces a combined fragment expressing possible alternativesover the lifelines. The ’alt’ operator has one or more conditions and one operand percondition plus an ”default” operand in the case that all conditions are false. The in-tuition is similar to case- or if-statements in programming languages. If a conditionholds, execute the corresponding operand; else, execute the second fragment. Fig-ure 5.7 shows an example. If the balance is enough then the transaction can be pro-cessed, else the transaction is cancelled. The semantics is defined as adding the unionof the traces of the operands to the set of valid traces.

Note that if more than one condition is true, the first one (most top in the lifeline)is executed.

5.4.2 Option: optOperator ’opt’ introduces an optional fragment. It is equivalent to an ’alt’ operatorwhere the else-operand is empty. The intuition is that if the condition holds, the frag-

5.4. OPERATORS 41

ment is executed; else, simply skip the fragment and continue.

Figure 5.8: Alt and Opt operators.

Figure 5.8 summarises the differences between operators ’alt’ and ’opt’.

5.4.3 Loop and breakFigure 5.9 shows the syntax for loop and break operators. A loop operator allows youto model iteration. When the break condition is true, the break operand executes andthe loop terminates.

There are different loop types summarised in Figure 5.10.

5.4.4 Combining operators: par, seq, strictFigure 5.11 shows different ways of combining operators.

• par: the ’par’ operator expresses the parallel execution of its operands. Eachoperand is executed in parallel to the others. Within an operand, the order ofexecution of this operand is preserved. The semantics is therefore the set of allpossible inter-leavings between the operands.

• seq: the ’seq’ operator defines a ”weak” sequential execution between its operands.The order of execution within an operand is maintained. The difference with the’par’ operator is that the execution order is also maintained within a lifeline. As

42 CHAPTER 5. SEQUENCE DIAGRAMS

Figure 5.9: Loop and Break operators.

Figure 5.10: Summary of the different types of loops.

5.4. OPERATORS 43

Figure 5.11: Summary of the different types of sequencing operators.

shown in Figure 5.11, searching with ”Bing” is always performed before search-ing with ”Yahoo”.

• strict: the ’strict’ operator defines sequential execution. Here the order of exe-cution is maintained within operands, lifelines and also over different lifelines.

Figure 5.12: Definition of a co-region..

An simpler notation – equivalent to ’par’ – is to define a co-region as illustratedin Figure 5.12. This sequence diagram is equivalent to the most left diagram in Fig-ure 5.11.

5.4.5 Negation: negThe ”neg” operator defines invalid behaviours, that is, behaviours that should not hap-pen. The semantics is that traces of the neg operands are added to the set of invalidtraces. Figure 5.13 shows a simple example. The intuition is that the system shouldnever produce a timeout message.

44 CHAPTER 5. SEQUENCE DIAGRAMS

Figure 5.13: Simple ’neg’ operator example.

5.5 Invariants and duration constraint

5.5.1 InvariantsIt is possible to state invariants on lifelines. Invariants are evaluated prior to the nextactivation specification. All traces for which the invariants hold are valid. Otherwise,traces are invalid.

Figure 5.14: A simple invariant.

Figure 5.14 shows an example. The invariant will be checked at the end of theactivation specification.

Invariants can also be stated on a lifeline. It has the same meaning. Traces of thelifelines are valid if and only if the invariant holds. Figure 5.15 shows an example.Only traces with a positive balance are valid.

5.6 ConclusionThis chapter has introduced Sequence Diagrams as means to specify interactions be-tween structural elements of a system and the environment of a system. Sequence di-agrams therefore support the specification of sequences of events required to achieved

5.7. EXERCISES 45

Figure 5.15: A lifeline with an invariant.

user goals and post-condition of use cases. Sequence diagrams must be kept consistentwith both use case diagrams and class diagrams.

5.7 ExercisesExercise 5.7.1. Consider the specification of the UML-Bookshop in Exercise 3.7.1 andExercise 4.5.1. Using the class diagram and the use case diagram you produced, drawa sequence diagram based on one of the use cases.

Exercise 5.7.2. Consider the specification of the transport company in Exercise 3.7.2and Exercise 4.5.2. Using the class diagram and the use case diagram you produced,draw a sequence diagram based on one of the use cases.

Exercise 5.7.3. Consider the specification of the embedded system of the railway con-troller in Exercise 3.7.3 and Exercise 4.5.3. Using the class diagram and the use casediagram you produced, draw a sequence diagram based on one of the use cases.

Exercise 5.7.4. Consider your preferred webshop. Draw a sequence diagram repre-senting the interaction sequence you need to execute to order an item.

46 CHAPTER 5. SEQUENCE DIAGRAMS