Sequence diagram

Structure diagrams of the UML
Class diagram
Component diagram
Composition structure diagram
Object diagram
Package diagram
Profile diagram
Distribution diagram
UML behavioral diagrams
Activity diagram
Use case diagram
Interaction overview diagram
Communication diagram
Sequence diagram
Timing diagram
State diagram

A sequence diagram ( English sequence diagram ) is a behavior diagram showing an interaction in accordance with the Unified Modeling Language represents (UML) graphically. In the context of UML, a modeling language for software and other systems, the sequence diagram is one of four types of interaction diagrams.

Sequence diagrams describe the exchange of messages between objects using lifelines .

UML2 sequence diagrams are closely related to Message Sequence Charts (MSC), a standard of the ITU -T (International Telecommunication Union - Telecommunication Standardization Sector).

A sequence diagram usually represents a path through a decision tree within a system flow. If overviews with all decision options are to be developed, an independent sequence diagram would have to be modeled for each possible process; therefore the activity diagram or state diagram is more suitable for this .

Notation of lifelines and messages

Example of a sequence diagram

The figure on the left shows an example of a sequence diagram with a header and a content area. In the case of a sequence diagram, the keyword in the header is sdor interaction. A lifeline (dashed) goes out from each communication partner. Two synchronous operation calls are shown , recognizable by the arrows with a filled arrowhead.

Notation variants for synchronous and asynchronous messages

A message is represented on a sequence diagram by an arrow, with the name of the message written above the arrow. Synchronous messages are shown with a filled arrowhead, asynchronous messages with an open arrowhead. Messages that correspond to asynchronous signals are represented in the same way as asynchronous operation calls. The main difference between asynchronous and synchronous messages is that the synchronous messages “block” the outgoing lifeline for further messages until it has received a response. This is not the case with asynchronous messages. The narrow rectangles on the lifelines are activation bars that indicate the focus of control , i.e. the area in which an object has control flow and is actively involved in interactions.

Further notation variants for messages

The figure on the left shows four further notation variants for lost and found messages , as well as for messages from and to a connection point . You can tell that it is a message from or to a connection point by the fact that the corresponding arrow starts or ends on the edge of the sequence diagram. The connection point is simply the intersection of the arrow with the edge, a clearer graphic symbol is not provided for this.

Temporal order of events

A sequence diagram describes the behavior of a system by specifying the chronological order of event occurrences . It is not the precise point in time when an event occurs that is decisive, but rather which events must occur before and which after a certain occurrence of the event (see sequencing and concurrency ).

Sequence diagram with two synchronous operation calls that models four event occurrences

The figure on the left shows a sequence diagram with two synchronous operation calls. The four event appearances are circled in blue. S1and E1stand for the send and receive message events for the message m1, S2and E2for the corresponding events that are associated with m2. The time axis runs from top to bottom in a sequence diagram, but should not be understood as absolute time.

The following statements can be made about the occurrences of events in this sequence diagram:

E1occurs after S1because the receive event always occurs after the send message event. Analog occurs E2after S2.
S2occurs after S1because it S2is S1drawn below

All in all modeled this sequence diagram therefore an interaction that is specified by exactly a sequence of event appearances: <S1, E1, S2, E2>.

Sequence diagram with two asynchronous operation calls, the sequence of event occurrences E1 and E2 is not restricted

The sequence diagram in the figure on the left differs only slightly from the previous sequence diagram. The only difference is that instead of two synchronous messages , two asynchronous messages are shown. Here still applies that E1to S1and E2after S2occurs because the reception always occurs after the send message event. Because this is asynchronous communication, it could E1not only occur before, but also after S2or E2.

So the sequence diagram specifies an interaction, are allowed in the three series of event performances: <S1, E1, S2, E2>, <S1, S2, E1, E2>and <S1, S2, E2, E1>.

Sequence diagram with two asynchronous operation calls and an order relationship

If necessary, the permissible sequences of event occurrences can be restricted with additional relationships . An order relationship does not specify a message that is exchanged between two lifelines, but the fact that one event occurrence must occur after another event occurrence. In the example, the order relationship is modeled as S2always following E1.

With this additional limitation is this sequence diagram again an interaction with exactly one acceptable result is: <S1, E1, S2, E2>.

Combined Fragments

Interactions can become very complex, depending on the system being modeled. If there was no way to modularize sequence diagrams, the corresponding graphical representations would be confusing and difficult to understand.

UML2 has therefore adopted the concept of inline expressions under the name of combined fragments from the Message Sequence Chart . A combined fragment is the combination of an interaction operator and one or more interaction operands . The interaction operator specifies the type of the combined fragment, while the interaction operands stand for the interaction fragments in this combined fragment.

An optional fragment consists, for example, of the interaction operand opt, a condition and an interaction fragment . If an optional fragment is included in an interaction, the associated interaction fragment is only run through if the condition is true.

Table of the combined fragments ( Lit .: Jeckle 2004, Chapter 12)
keyword	German name	English name	Intended use	Explanation
`alt`	Alternative fragment	alternative	Modeling of alternative process options	Alternative processes, which are provided with conditions, can be combined with an alt operator.
`assert`	Assurance	Assertion	Modeling essential interactions	This operator can be used to specify a mandatory sequence for a set of messages.
`break`	Termination fragment	Break	Modeling of exceptional cases	The normal process is interrupted if a previous condition is met or violated.
`consider`	Relevant news	Consider	Modeling filters for important messages	With the help of this operator, only the specified actions are carried out, the rest are ignored.
`critical`	Critical area	Critical Region	Modeling of non-interruptible interactions	If this region is entered, all actions are carried out without any interruption. Multithreading is impossible in this section.
`ignore`	Irrelevant news	Ignore	Modeling filters for unimportant messages	Certain actions can be prevented from being carried out with the help of this operator.
`loop`	loop	Loop	Modeling iterations in interactions	With the help of the loop operator loops can be defined. To simplify things, you can sometimes find loop while or loop until .
`neg`	negation	Negatives	Modeling invalid interactions	This operator encapsulates illegal processes. Can be used as a placeholder for later processes.
`opt`	Optional fragment	option	Modeling of optional parts of an interaction	The simplest form of the operator is the opt operator, which includes optional sub-processes.
`par`	Parallel fragment	Parallel	Modeling of concurrent parts of an interaction	The par operator is used to represent parallel processes.
`ref`	reference	link	Modeling of references to partial processes of other sequence diagrams	With the help of this operator, a reference is made to another sequence diagram that describes a partial process.
`seq`	Loose order	Weak sequencing	Modeling of processes that depend on lifelines and operands	Provides a sequence for the sequence of actions of a lifeline.
`strict`	Strict order	Strict sequencing	Modeling of processes that do not depend on lifelines and operands	Similar to the structure of the seq operator. Here, however, the order does not only affect one life line, but all life lines.

literature

Christoph Kecher: UML 2.0 - The comprehensive manual . 2nd Edition. Galileo Press, Bonn 2006, ISBN 978-3-89842-738-8 .
Heide Balzert: Textbook of Object Modeling - Analysis and Design with UML 2 . 2nd Edition. Elsevier Spektrum Akademischer Verlag, Heidelberg, Munich 2005, ISBN 3-8274-1162-9 .
M. Jeckle , Chris Rupp , J. Hahn, B. Zengler, S. Queins: UML 2 crystal clear . Hanser, Munich, Vienna 2004, ISBN 3-446-22575-7 , Chapter 12 - Sequence diagram.
Message Sequence Chart (MSC) . In: ITU-T Recommendation (Ed.): Languages and general Software Aspects for Telecommunication Systems . Z.120, November 1999 ( online [PDF; accessed April 30, 2009]).

Web links

Commons : Sequence diagrams - collection of images, videos, and audio files