imported>Itti: Änderungen von 24.134.126.29 (Diskussion) auf die letzte Version von Serols zurückgesetzt

2024-02-09T09:26:56Z

Änderungen von 24.134.126.29 (Diskussion) auf die letzte Version von Serols zurückgesetzt

Neue Seite

{{UML Diagrammtypen}}

Ein '''Sequenzdiagramm''' ({{enS|''sequence diagram''}}) ist ein Verhaltensdiagramm, welches eine [[Interaktion (UML)|Interaktion]] im Sinne der [[Unified Modeling Language]] (UML) grafisch darstellt. Im Rahmen der UML, einer Modellierungssprache für Software und andere Systeme, ist das Sequenzdiagramm eine der vier Arten von Interaktionsdiagrammen.

Sequenzdiagramme beschreiben den Austausch von [[Interaktion (UML)|Nachrichten]] zwischen [[Objekt (Programmierung)|Objekten]] mittels [[Interaktion (UML)#Lebenslinien|Lebenslinien]].

Sequenzdiagramme der UML2 sind nahe verwandt mit [[Message Sequence Chart]]s (MSC), einem Standard der [[Internationale Fernmeldeunion|ITU]]-T (International Telecommunication Union – Telecommunication Standardization Sector).

Ein Sequenzdiagramm stellt in der Regel ''einen'' Weg durch einen [[Entscheidungsbaum]] innerhalb eines Systemablaufes dar. Sollen Übersichten mit allen Entscheidungsmöglichkeiten entwickelt werden, so müsste hierzu für jeden möglichen Ablauf ein eigenständiges Sequenzdiagramm modelliert werden; deshalb eignet sich hierfür eher das [[Aktivitätsdiagramm]] oder [[Zustandsdiagramm (UML)|Zustandsdiagramm]].

== Notation von Lebenslinien und Nachrichten ==
[[Datei:UmlSequenzdiagramm-2.svg|mini|links|Beispiel eines Sequenzdiagramms]]

Die Abbildung links zeigt ein Beispiel eines Sequenzdiagramms mit einem Kopf- und einem Inhaltsbereich. Das Schlüsselwort im Kopfbereich ist bei einem Sequenzdiagramm '''<code>sd</code>''' oder '''<code>interaction</code>'''. Im Inhaltsbereich sind oben zwei beschriftete Rechtecke, sie stellen zwei Kommunikationspartner dar. Von jedem Kommunikationspartner geht eine gestrichelte Linie abwärts, sie stellt die Lebenslinie dar. Zwischen den Lebenslinien gibt es zwei Pfeile von links nach rechts, mit durchgehender Linie und gefüllter Pfeilspitze, sie stellen [[Interaktion (UML)|synchrone Operationsaufrufe]] dar. Ein Operationsaufruf ist eine spezielle Art von Nachricht.

[[Datei:UmlSequenzdiagramm-3.svg|mini|250px|Notationsvarianten für synchrone und asynchrone [[Interaktion (UML)|Nachrichten]]]]

Eine Nachricht wird in einem Sequenzdiagramm durch einen Pfeil dargestellt, wobei der Name der Nachricht über den Pfeil geschrieben wird.
[[Synchrone Kommunikation|Synchrone Nachrichten]] werden mit einer gefüllten Pfeilspitze, [[Asynchrone Kommunikation|asynchrone Nachrichten]] mit einer offenen Pfeilspitze gezeichnet. Nachrichten, die asynchronen Signalen entsprechen, werden gleich dargestellt wie asynchrone Operationsaufrufe. Der wesentliche Unterschied zwischen einer asynchronen und einer synchronen Nachricht ist, dass die synchrone Nachricht die ausgehende Lebenslinie für weitere Nachrichten „blockiert“, bis diese eine Antwort erhalten hat. Dies ist bei asynchronen Nachrichten nicht der Fall.

Die schmalen Rechtecke, die auf den Lebenslinien liegen, sind ''Aktivierungsbalken'', die den ''Focus of Control'' anzeigen, also jenen Bereich, in dem ein Objekt über den Kontrollfluss verfügt, und aktiv an Interaktionen beteiligt ist.
<div style="clear:left;"></div>

[[Datei:UmlSequenzdiagramm-4.svg|mini|links|Weitere Notationsvarianten für Nachrichten]]

Die Abbildung links zeigt vier weitere Notationsvarianten für [[Interaktion (UML)#Nachrichten|verlorene]] und [[Interaktion (UML)#Nachrichten|gefundene Nachrichten]], sowie für Nachrichten von und an einen [[Interaktion (UML)|Verknüpfungspunkt]]. Dass es sich um eine Nachricht von einem oder an einen Verknüpfungspunkt handelt, erkennt man daran, dass der entsprechende Pfeil auf dem Rand des Sequenzdiagramms beginnt bzw. endet. Der Verknüpfungspunkt ist einfach der Schnittpunkt des Pfeils mit dem Rand, ein deutlicheres graphisches Symbol ist dafür nicht vorgesehen.
<div style="clear:left;"></div>

== Zeitliche Ordnung der Ereignisse ==
Ein Sequenzdiagramm beschreibt das [[Verhalten (UML)|Verhalten]] eines Systems, indem es die zeitliche Ordnung von [[Ereignis (UML)|Ereignisauftritten]] spezifiziert. Nicht der präzise Zeitpunkt, wann ein Ereignis auftritt, ist dabei ausschlaggebend, sondern welche Ereignisse vor und welche nach einem bestimmten Ereignisauftritt auftreten müssen (Siehe dazu [[Sequentialisierung]] und [[Nebenläufigkeit]]).

[[Datei:UmlSequenzdiagramm-5.svg|mini|250px|links|Sequenzdiagramm mit zwei synchronen Operationsaufrufen, das vier Ereignisauftritte modelliert]]

Die Abbildung links zeigt ein Sequenzdiagramm mit zwei synchronen Operationsaufrufen. Blau eingekreist sind die vier Ereignisauftritte. <code>S1</code> und <code>E1</code> stehen für das Sende- und das Empfangs-Nachricht-Ereignis für die Nachricht <code>m1</code>, <code>S2</code> und <code>E2</code> für die entsprechenden Ereignisse, die mit <code>m2</code> in Verbindung stehen. Die Zeitachse läuft in einem Sequenzdiagramm von oben nach unten, sollte aber nicht als absolute Zeit verstanden werden.

Zu den Ereignisauftritten in diesem Sequenzdiagramm lassen sich folgende Aussagen machen:
* <code>E1</code> tritt nach <code>S1</code> auf, weil das Empfangs- immer nach dem Sende-Nachricht-Ereignis vorkommt. Analog tritt <code>E2</code> nach <code>S2</code> auf.
* <code>S2</code> tritt nach <code>S1</code> auf, weil <code>S2</code> unter <code>S1</code> gezeichnet ist. (Genauer gesagt, tritt S2 nach E1 auf, da m1 eine synchrone Nachricht darstellt.)

Alles in allem modelliert dieses Sequenzdiagramm also eine Interaktion, die durch genau eine Folge von Ereignisauftritten spezifiziert ist: <code><S1, E1, S2, E2></code>.
<div style="clear:left;"></div>

[[Datei:UmlSequenzdiagramm-6.svg|mini|250px|links|Sequenzdiagramm mit zwei asynchronen Operationsaufrufen, die Folge der Ereignisauftritte E1 und E2 ist nur durch die Lebenslinie von B eingeschränkt]]

Das Sequenzdiagramm in der Abbildung links unterscheidet sich nur geringfügig vom vorangehenden Sequenzdiagramm. Der einzige Unterschied besteht darin, dass statt zwei ''synchronen'' zwei ''asynchrone'' Nachrichten dargestellt sind. Hier gilt weiterhin, dass <code>E1</code> nach <code>S1</code> und <code>E2</code> nach <code>S2</code> auftritt, weil das Empfangs- immer nach dem Sende-Nachricht-Ereignis vorkommt. Weil es sich um asynchrone Kommunikation handelt, könnte <code>E1</code> hier jedoch nicht nur vor, sondern auch erst nach <code>S2</code> vorkommen. Es ist allerdings nicht möglich, dass das Empfangsereignis <code>E1</code> nach <code>E2</code> vorkommt, da die Ereignisse auf einer Lebenslinie von oben nach unten geordnet sind<ref>{{Internetquelle |url=https://www.omg.org/spec/UML/2.5/About-UML/ |titel=About the Unified Modeling Language Specification Version 2.5 |hrsg=Object Management Group® (OMG®) |seiten=570 |abruf=2021-03-07}}</ref>.

Das Sequenzdiagramm spezifiziert also eine Interaktion, in der zwei Folgen von Ereignisauftritten zulässig sind: <code><S1, E1, S2, E2></code> und <code><S1, S2, E1, E2></code> .
<div style="clear:left;"></div>

[[Datei:UmlSequenzdiagramm-7.svg|mini|250px|links|Sequenzdiagramm mit zwei asynchronen Operationsaufrufen und einer ''Ordnungsbeziehung'']]

Falls nötig, kann man die zulässigen Abfolgen von Ereignisauftritten mit zusätzlichen ''Ordnungsbeziehungen'' einschränken. Eine Ordnungsbeziehung spezifiziert nicht eine Nachricht, die zwischen zwei Lebenslinien ausgetauscht wird, sondern die Tatsache, dass ein Ereignisauftritt nach einem anderen Ereignisauftritt vorkommen muss. Im Beispiel modelliert die Ordnungsbeziehung, dass <code>S2</code> immer nach <code>E1</code> erfolgt.

Mit dieser zusätzlichen Einschränkung stellt dieses Sequenzdiagramm erneut eine Interaktion mit genau einer zulässigen Folge dar: <code><S1, E1, S2, E2></code>.
<div style="clear:left;"></div>

== Kombinierte Fragmente ==
Interaktionen können je nach modelliertem System sehr komplex werden. Wenn es keine Möglichkeit gäbe, Sequenzdiagramme zu modularisieren, wären die entsprechenden graphischen Darstellungen unübersichtlich und schwer verständlich.

Die UML2 hat deshalb aus den [[Message Sequence Chart]] deren Konzept der ''inline expressions'' unter dem Namen ''kombinierte Fragmente'' übernommen. Ein kombiniertes Fragment ist die Kombination eines ''Interaktionsoperators'' und eines oder mehrerer ''Interaktionsoperanden''. Der Interaktionsoperator spezifiziert die Art des kombinierten Fragments, während die Interaktionsoperanden für die Interaktionsfragmente in diesem kombinierten Fragment stehen.

Ein ''Optionales Fragment'' besteht zum Beispiel aus dem Interaktionsoperanden '''<code>opt</code>''', einer Bedingung und einem Interaktionsfragment. Ist ein optionales Fragment in eine Interaktion eingebunden, wird das zugehörige Interaktionsfragment nur durchlaufen, wenn die Bedingung wahr ist.

{| class="wikitable"
|+ Tabelle der kombinierten Fragmente ([[#Literatur|Lit.]] : Jeckle 2004, Kapitel 12)
!Schlüsselwort
!Deutsche Bezeichnung
!Englische Bezeichnung
!Einsatzzweck: Modellierung von …
!Erläuterung
|-
| <code>alt</code>
|Alternatives Fragment
|Alternative
|alternativen Ablaufmöglichkeiten
|Durch einen alt-Operator können alternative Abläufe, die durch Bedingungen versehen sind, zusammengefasst werden.
|-
|<code>assert</code>
|Zusicherung
|Assertion
|unabdingbaren Interaktionen
|Für eine Nachrichtenmenge kann mit Hilfe dieses Operators eine zwingend notwendige Ablaufreihenfolge angegeben werden.
|-
|<code>break</code>
|Abbruchfragment
|Break
|Ausnahmefällen
|Der normale Ablauf wird unterbrochen, falls eine vorherige Bedingung erfüllt, bzw. verletzt wurde.
|-
|<code>consider</code>
|Relevante Nachrichten
|Consider
|Filtern für wichtige Nachrichten
|Mit Hilfe dieses Operators werden nur die angegebenen Aktionen ausgeführt, der Rest wird ignoriert.
|-
|<code>critical</code>
|Kritischer Bereich
|Critical Region
|nicht unterbrechbaren Interaktionen
|Falls diese Region betreten wird, so werden alle Aktionen ohne jegliche Unterbrechung ausgeführt. Multithreading ist in diesem Abschnitt unmöglich.
|-
|<code>ignore</code>
|Irrelevante Nachrichten
|Ignore
|Filtern für unwichtige Nachrichten
|Bestimmte Aktionen können mit Hilfe dieses Operators an der Ausführung gehindert werden.
|-
|<code>loop</code>
|Schleife
|Loop
|Iterationen in Interaktionen
|Mit Hilfe des loop-Operators können Schleifen definiert werden. Zur Vereinfachung findet man manchmal auch ''loop while'' oder ''loop until''.
|-
|<code>neg</code>
|Negation
|Negative
|ungültigen Interaktionen
|Dieser Operator kapselt unzulässige Abläufe. Kann als Platzhalter für spätere Abläufe verwendet werden.
|-
|<code>opt</code>
|Optionales Fragment
|Option
|optionalen Teilen einer Interaktion
|Die einfachste Form der Operatoren ist der opt-Operator, der optionale Teilabläufe umfasst.
|-
|<code>par</code>
|Paralleles Fragment
|Parallel
|nebenläufigen Teilen einer Interaktion
|Der par-Operator dient der Darstellung von parallelen Abläufen.
|-
|<code>ref</code>
|Verweis
|Link
|Verweisen auf Teilabläufe anderer Sequenzdiagramme
|Mit Hilfe dieses Operators wird durch eine Referenz auf ein anderes Sequenzdiagramm verwiesen, das einen Teilablauf beschreibt.
|-
|<code>seq</code>
|Lose Ordnung
|Weak Sequencing
|Abläufen, die von Lebenslinien und Operanden abhängen
|Legt eine Reihenfolge für die Abfolge von Aktionen einer Lebenslinie vor.
|-
|<code>strict</code>
|Strenge Ordnung
|Strict Sequencing
|Abläufen, die ''nicht'' von Lebenslinien und Operanden abhängen
|Ähnelt dem Aufbau des seq-Operators. Hier betrifft jedoch die Reihenfolge nicht nur eine Lebenslinie, sondern gleich alle Lebenslinien.
|}

== Siehe auch ==
* [[Interprozesskommunikation]]
* [[Prozesssynchronisation]]
* [[Unified Modeling Language|UML (Unified Modeling Language)]]

== Literatur ==
* {{Literatur |Autor=Christoph Kecher |Titel=UML 2.0 – Das umfassende Handbuch |Auflage=2. |Verlag=Galileo Press |Ort=Bonn |Datum=2006 |ISBN=978-3-89842-738-8 }}
* {{Literatur |Autor=Heide Balzert |Titel=Lehrbuch der Objektmodellierung – Analyse und Entwurf mit der UML 2 |Auflage=2. |Verlag=Elsevier Spektrum Akademischer Verlag |Ort=Heidelberg, München |Datum=2005 |ISBN=3-8274-1162-9 }}
* {{Literatur |Autor=[[Mario Jeckle|M. Jeckle]], [[Chris Rupp]], J. Hahn, B. Zengler, S. Queins |Titel=UML 2 glasklar |Kapitel=Kapitel 12 – Sequenzdiagramm |Verlag=Hanser |Ort=München, Wien |Datum=2004 |ISBN=3-446-22575-7 }}
* {{Literatur |Hrsg=ITU-T Recommendation |Titel=Message Sequence Chart (MSC) |Nummer=Z.120 |Sammelwerk=Languages and general Software Aspects for Telecommunication Systems |Datum=1999-11 |Online=[https://www.itu.int/ITU-T/studygroups/com10/languages/Z.120_1199.pdf online] |Format=PDF |Abruf=2009-04-30 }}

== Weblinks ==
{{Commonscat|Sequence diagrams|Sequenzdiagramme}}
* [https://sourceforge.net/projects/sdedit Ein einfacher Editor für Sequenzdiagramme] (Java)
* [https://www.websequencediagrams.com/ Ein einfacher Online-Editor für Sequenzdiagramme]
* [https://app.diagrams.net/ Online-Editor für verschiedene Diagrammarten]
* [https://creately.com/de/lp/sequenzdiagramm-online/ Online-Sequenzdiagramm-Editor mit vollständiger Formenbibliothek]

== Einzelnachweise ==
<references />

[[Kategorie:Unified Modeling Language]]
[[Kategorie:Diagramm]]

Sequenzdiagramm - Versionsgeschichte

imported>Itti: Änderungen von 24.134.126.29 (Diskussion) auf die letzte Version von Serols zurückgesetzt