Chapter 5 Sequence diagrams In the previous chapters, we have seen different diagrams. Use case diagrams describe tasks that a system is supposed to perform. It gives high-level information about how a user should interact with the system. Class diagrams specify the structure and the operations related to the data used by the system. A sequence diagram can help specifying the link between a use case and the methods and classes defined in class diagrams. It is therefore important to ensure consistency between these three kinds of diagrams. 5.1 Learning objectives of this chapter The 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 diagrams. 5.2 Sequence diagram 5.2.1 Overview and some definitions A sequence diagrams basically shows how actors and objects interact to realise a use case scenario. Figure 5.1 shows a simple sequence diagram. It focuses on the message exchange between a number of lifelines. Lifeline A lifeline represent the lifetime of a participant in the interaction. A lifeline can be an actor, a class, or any object involved in the use case. In a lifeline time starts at 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 for actors; 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 diagram, an actor first sends a message msg 1 to an instance of class A. After that, class A sends a message msg 2 to an instance of class B. Finally, B sends a response to A, that sends a response to the actor.
5.2. SEQUENCE DIAGRAM 37 The intuition behind sending a message is that sending a message means calling a given method of a class. In Figure 5.2, this means that the actor is calling method named msg 1 from class A. This also means that class A must have a method named msg 1. A similar remark holds for method msg 2 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 shown with 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 interactions 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 send event and a receive event. A trace is a possibility infinite sequence of events. The semantics 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 this chapter). 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 it is 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 sent and received, message msg2 is then sent and received, message response is sent and received, an un-named message is sent and received.
38 CHAPTER 5. SEQUENCE DIAGRAMS 5.2.3 Synchronous vs. Asynchronous communications If there is no concurrency, exactly one object is active or computing at any given instant. In that case, activation computations behave like a stack. Figure 5.4: Asynchrony and concurrency. Figure 5.4 shows asynchronous communications and introduces concurrency, that is, two lifelines are active at the same instant. As emphasised in the picture, you should notice the difference in the arrow-head of the arrow labelled msg2. This type of arrow indicates an asynchronous communication. The lifeline emitting the message or calling a particular method remains active after sending the message. In this example, once msg2 is sent, both class A and class B are active. 5.3 Object creation and destruction It is possible to indicate creation and destruction of objects. Figure 5.5 shows an example. A creation action is done using an asynchronous arrow as the creator is still active after creation. The creator should not have to wait that the created object terminates to resume execution. Notice that by convention destruction of objects uses synchronous messages. 5.4 Operators The UML standard defines several operators than can be used to further specify lifelines and their interactions. In this course, we cover a subset only of all the possible operators.
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 the picture, an operator has zero or more conditions, and one or more operands. An operator defines a combined fragments composed of the different operands. Each operand defines 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 alternatives over the lifelines. The alt operator has one or more conditions and one operand per condition plus an default operand in the case that all conditions are false. The intuition is similar to case- or if-statements in programming languages. If a condition holds, execute the corresponding operand; else, execute the second fragment. Figure 5.7 shows an example. If the balance is enough then the transaction can be processed, else the transaction is cancelled. The semantics is defined as adding the union of 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: opt Operator opt introduces an optional fragment. It is equivalent to an alt operator where 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 break Figure 5.9 shows the syntax for loop and break operators. A loop operator allows you to model iteration. When the break condition is true, the break operand executes and the loop terminates. There are different loop types summarised in Figure 5.10. 5.4.4 Combining operators: par, seq, strict Figure 5.11 shows different ways of combining operators. par: the par operator expresses the parallel execution of its operands. Each operand is executed in parallel to the others. Within an operand, the order of execution of this operand is preserved. The semantics is therefore the set of all possible 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 searching with Yahoo. strict: the strict operator defines sequential execution. Here the order of execution 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 illustrated in Figure 5.12. This sequence diagram is equivalent to the most left diagram in Figure 5.11. 5.4.5 Negation: neg The neg operator defines invalid behaviours, that is, behaviours that should not happen. The semantics is that traces of the neg operands are added to the set of invalid traces. Figure 5.13 shows a simple example. The intuition is that the system should never 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 Invariants It is possible to state invariants on lifelines. Invariants are evaluated prior to the next activation 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 the activation specification. Invariants can also be stated on a lifeline. It has the same meaning. Traces of the lifelines 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 Conclusion This chapter has introduced Sequence Diagrams as means to specify interactions between structural elements of a system and the environment of a system. Sequence diagrams 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 consistent with both use case diagrams and class diagrams. 5.7 Exercises Exercise 5.7.1. Consider the specification of the UML-Bookshop in Exercise 3.7.1 and Exercise 4.5.1. 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.2. Consider the specification of the transport company in Exercise 3.7.2 and 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 controller in Exercise 3.7.3 and Exercise 4.5.3. 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.4. Consider your preferred webshop. Draw a sequence diagram representing the interaction sequence you need to execute to order an item.
46 CHAPTER 5. SEQUENCE DIAGRAMS