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
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 sd
or interaction
. A lifeline (dashed) goes out from each communication partner. Two synchronous operation calls are shown , recognizable by the arrows with a filled arrowhead.
![](https://upload.wikimedia.org/wikipedia/commons/thumb/c/c8/UmlSequenzdiagramm-3.svg/250px-UmlSequenzdiagramm-3.svg.png)
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.
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 ).
The figure on the left shows a sequence diagram with two synchronous operation calls. The four event appearances are circled in blue. S1
and E1
stand for the send and receive message events for the message m1
, S2
and E2
for 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:
-
E1
occurs afterS1
because the receive event always occurs after the send message event. Analog occursE2
afterS2
. -
S2
occurs afterS1
because itS2
isS1
drawn 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>
.
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 E1
to S1
and E2
after S2
occurs because the reception always occurs after the send message event. Because this is asynchronous communication, it could E1
not only occur before, but also after S2
or 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>
.
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 S2
always 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.
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. |
See also
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]).