Sequenzdiagramme: Den Nachrichtenaustausch in einem System mit UML darstellen

Das Sequenzdiagramm ist ein Diagrammtyp der Unified Modeling Language (UML). UML wiederum ist eine objektorientierte Modellierungssprache. Solch eine Sprache besteht aus grafischen Elementen. UML modelliert Systeme und Prozesse der objektorientierten Programmierung sowie Geschäftsprozesse. Ziel ist es, komplexe Sachverhalte übersichtlich darzustellen. UML legt zu diesem Zweck eine standardisierte Notation fest. Eine Form steht stets für einen bestimmten Bestandteil oder eine bestimmte Verhaltensweise. Die sogenannte Metamodellierung legt Spracheinheiten und deren Bedeutung innerhalb der UML fest. Dazu gehört auch die Festlegung, wie bestimmte Elemente miteinander interagieren können und welche Hierarchien zwischen den jeweiligen Spracheinheiten bestehen.

Elemente und Beziehungen stellt UML in Form von Diagrammen dar. UML2 unterscheidet 14 unterschiedliche Diagrammtypen. Diese ordnet es einer von drei verschiedenen Kategorien zu: Strukturdiagrammen, Verhaltensdiagrammen und Interaktionsdiagrammen.

• Strukturdiagramme (Englisch: structure diagrams) stellen ein System und dessen Bestandteile in einem statischen Zustand dar. Sie verdeutlichen, welche Beziehungen zwischen einzelnen Elementen oder zwischen Elementen und übergeordneten Konzepten bestehen. Ein Beispiel dafür ist das Klassendiagramm.
• Verhaltensdiagramme (Englisch: behavior diagrams) stellen Prozesse und das Verhalten eines Systems dynamisch dar. Anders als bei den Strukturdiagrammen spielt auch die Reihenfolge von Prozessen und somit Zeit eine Rolle bei der Darstellung. Ein Beispiel hierfür ist das Aktivitätsdiagramm.
• Interaktionsdiagramme (Englisch: interaction diagrams) gehören zu den Verhaltensdiagrammen. Sie werden gesondert aufgeführt, weil sie ein spezifisches Verhalten modellieren – nämlich Interaktionen zwischen Systemelementen. Die Grundbausteine von Interaktionen sind die sogenannten Lebenslinien. Das sind Objekte (also die kleinsten eigenständigen Bausteine der objektorientierten Programmierung), die individuelle Teilnehmer einer Interaktion darstellen. Das meist genutzte Interaktionsdiagramm ist das Sequenzdiagramm.

Das UML-Sequenzdiagramm stellt Ereignisauftritte chronologisch geordnet dar. Deshalb wird es manchmal auch als Ereignisdiagramm oder Ereignisszenario bezeichnet. Die Ordnung (also die genaue Reihenfolge) ist dabei wichtiger als spezifische Zeitpunkte. Sie können jedoch Beschränkungen in Ihr Modell einbauen. Zum Beispiel kann eine Zeitbeschränkung für einen bestimmten Prozess (beispielsweise die PIN-Eingabe am Bankautomaten) ein Ereignis bedingen (Kartenausgabe, falls nach einer bestimmten Zeit keine Eingabe erfolgt).

Das Sequenzdiagramm beschreibt im Grunde, wie Objekte (und Instanzen) Nachrichten in einer bestimmten Reihenfolge austauschen. Objekte sind der Grundbaustein von UML-Diagrammen. Je nach Diagrammtyp stellen sie bestimmte Ausprägungen eines Systemelements dar. Bei Interaktionen sind die Objekte Lebenslinien.

In einem System werden ständig Anfragen gestellt und Antworten versandt. Der Empfänger trifft dann aufgrund der speziellen Anfrage und seiner eigenen vorher festgelegten Regeln eine Entscheidung. Ein solches Geflecht möglicher Entscheidungen und Interaktionen stellt man meist durch ein Aktivitätsdiagramm dar. Stellen Sie sich sämtliche möglichen Entscheidungen (ja/nein) als Baumdiagramm vor, entsteht wahrscheinlich das Bild eines stark verzweigten Netzes. Das Sequenzdiagramm zeigt nur einen bestimmten Pfad innerhalb dieses Netzes.

Das Sequenzdiagramm unterscheidet sich vom UML-Anwendungsfalldiagramm insbesondere durch seine detaillierte Ordnung. Soll ein Geschäftsprozess neu eingeführt werden, verschafft der Anwendungsfall einen guten Überblick über die Anforderungen. Geht es hingegen darum, konkrete Fälle samt Zeitplan festzulegen, erstellen Sie ein Sequenzdiagramm. In diesem können Sie einzelne Teilbereiche genauer darstellen. Mit diesem sogenannten Anwendungsszenario prüfen Sie logische Zusammenhänge Ihres Anwendungsfalls auf Herz und Nieren.

UML-Sequenzdiagramme sind außerdem nützlich, wenn Sie komplizierte Vorgänge zum besseren Verständnis grafisch darstellen wollen. Durch die übersichtliche Modellierung erkennen Sie schnell, welche Stationen eine einzelne Aufgabe durchlaufen muss, um erfolgreich abgeschlossen zu werden. So können Sie Ihre Methoden planen und testen, noch bevor Sie sie im Geschäftsalltag oder in einem Computersystem implementieren.

Um die Kontrollstrukturen einer höheren Programmiersprache darzustellen, verbinden Sie mehrere Sequenzdiagramme miteinander in einem kombinierten Fragment.

Ein UML-Diagramm soll dazu beitragen, dass alle involvierten Parteien komplexe Systeme besser verstehen. Dazu nutzt die Modellierungssprache visuelle Symbole. Für Ausnahmefälle und bestimmte Anwendungsgruppen lässt sich UML anpassen. Es ist jedoch sinnvoll, überwiegend den von der OMG (Object Management Group) festgelegten Standard zu nutzen. Andernfalls kann es leicht zu Verständnisproblemen kommen. Die folgenden Spezifikationen entsprechen dem UML-Standard in der Version UML 2.5.

Die Lebenslinie repräsentiert den Zeitverlauf eines Prozesses. Ihr Kopf besteht aus einem Rechteck. Dieser beinhaltet im Regelfall den Objektnamen und den Klassennamen. Fehlt der Objektname, steht die Lebenslinie für eine namenslose Instanz des Objekts. In diesem Fall kann man davon ausgehen, dass alle Objekte derselben Klasse in dieser Sequenz gleich agieren. Die Lebenslinie steht immer nur für einen einzelnen Operanden. Verfügt der Operand über mehrere Ausprägungen, muss eine davon gewählt sein. Alternativ lässt sich auch sagen: Die Multiplizität ist nie >1.

Vom rechteckigen Kopf geht eine gestrichelte Linie nach unten ab. Diese Linie steht für den Zeitverlauf. Nach unten hin entwickelt sich die Zeit linear. Entlang der Zeitschiene werden Nachrichten gesendet und Antworten gegeben. Eine Nachricht, die zeitlich nach einer anderen Nachricht verschickt werden soll, steht weiter unten auf der Zeitschiene. Bei der Notation geht es nie um eindeutige Zeitpunkte, sondern stets um die Reihenfolge. Nachrichten werden immer untereinander angeordnet, außer sie existieren in parallel kombinierten Fragmenten.

Lebenslinien zeigen an, wie lange ein Objekt aktiv an einem Prozess beteiligt ist. Das sieht man daran, wie lang eine Lebenslinie im Vergleich zu den anderen ist. Manche Objekte werden zerstört, bevor der Prozess zu Ende ist. Nicht mehr benötigte Objekte markieren Sie auf deren Lebenslinie mit einem X an der Stelle, an der Sie zerstört werden sollen.

Um die Robustheit Ihres Systems zu prüfen, eignet sich das Sequenzdiagramm mit seinen detaillierten Ansichten sehr gut. Es lassen sich drei Klassen-Stereotype der Lebenslinie nutzen:

• Entität
• Grenze
• Kontrollelement

Oben im Bild sehen Sie die drei Lebenslinien samt Notation: Die Entität hat einen runden Kopf, der auf einer horizontalen Linie liegt. Bei der Grenze geht eine Linie mittig vom Kreis ab und verbindet sich mit einer vertikalen Linie – wie ein umgekipptes T, das seitlich vom Kopf abgeht. Der Kopf der Kontrolle besteht aus einem Pfeil, der sich im Kreis dreht. Von allen diesen Klassen-Stereotypen geht die gestrichelte Lebensdauer-Linie vertikal nach unten ab.

Haben Sie bereits anhand eines Anwendungsfalldiagramms ein Konzept ausgearbeitet, kann Ihnen das Sequenzdiagramm zum Beispiel dabei helfen, die einzelnen Schritte unter Berücksichtigung der denkbaren Akteure und Objekte auszuarbeiten.

Dabei stehen Grenzen (Englisch: Boundaries) für Schnittstellen, die mit externen Akteuren interagieren. Diese Objekte können beispielsweise Nutzeroberflächen sein – wobei dann der Akteur eine Person wäre. Entitäten (Englisch: Entities) hingegen stehen für Daten-Container beziehungsweise Objekte, die Systemdaten beinhalten. Damit Grenzen und Entitäten kommunizieren können, benötigen Sie ein Kontrollelement. Die Kontrolle muss nicht unbedingt ein Objekt sein. Eine Methode, die einer der beiden anderen Elemente zugeschrieben wird, funktioniert ebenso. Das Kontrollelement verbindet Entität und Grenze als Vermittler. Es überwacht die Signale der beiden Elemente und prüft sie hinsichtlich der Logik.

Die drei Stereotype kommunizieren nach vier Regeln:

• GrenzObjekte sind als Schnittstelle für die Kommunikation mit Akteuren zuständig. Somit kommunizieren Akteure ausschließlich mit Grenzen.
• Im Gegensatz dazu verständigen sich KontrollObjekte sowohl mit anderen Kontroll-Objekten als auch mit Entitäten und Grenzen. Dafür interagieren sie nicht mit Akteuren.
• Grenzen kommunizieren also mit KontrollObjekten und mit Akteuren.
• Entitäten sind als Datenträger am tiefsten im System verwurzelt. Sie tauschen nur Daten mit KontrollObjekten aus.

Antwortnachrichten dürfen pro Parameter nur einen Ausdruck mit höchstens einem Operanden haben. Wenn der Absender einer Antwort keine Werte ausgibt, hat auch die Nachricht keine spezifischen Werte, die sie verschickt. Normalerweise modelliert die Nachricht die Output-Parameter eines Absenders (also Werte, die durch eine Operation entstehen) als Operanden. Ohne Output-Parameter muss der Operand leer bleiben. In diesem Fall modellieren Sie einfach keinen Rücklaufwert, sondern den Wildcard-Platzhalter. Gibt es einen Operanden, wertet das System diesen wieder an der Auftrittsspezifikation aus. Das Ergebnis der Auswertung gibt die Werte für die Parameter „out“, „inout“ und „return“ vor.

UML spezifiziert drei Symbole, die als Parameterausdruck den Empfänger der Nachricht angeben. Der Empfänger ist das sogenannte Auftragsziel (Englisch: Assignment Target) der Nachricht. Die Antwortnachricht weist ihm den Rücklaufwert aus dem ausgegebenen Parameter des Absenders zu. Das sind die standardisierten Symbole:

• Unknown
• Interaction Parameter
• Attribute

Unknown (Unbekannt) ist ein leerer Parameter und steht für die Wildcard. Der Interaktionsparameter (Interaction Parameter) ist ein ownedParameter der Interaktion, der er innewohnt. Das heißt, die Interaktion besitzt den Parameter. Dieser verfügt über einen Namen. Operationsparameter und Interaktionsparameter haben den gleichen Typ. Attribute können uneingeschränkt benannt werden. Sie stellen den Namen eines Kontext-Verhaltens dar. Dieses Verhalten bestimmt entweder die Lebenslinie, zu der die Nachricht zurückkehrt, oder die umgebende Interaktion. Legt die Interaktion kein Verhalten fest, agiert sie selber als Kontext.

Gates, beziehungsweise Tore, sind einfach Punkte am Ende einer Nachricht. Sie gehören zum Typ MessageEnd (Nachrichtenende). Durch sie werden Sender und Empfänger einer Nachricht markiert. Gates verdeutlichen den Informationsfluss und zeigen auf, wie Nachrichten zwischen zwei Interaktionsfragmenten wandern. Genauer gesagt stellen sie Verbindungspunkte für Nachrichten zwischen Interaktionsnutzen und Interaktionen dar – sowie zwischen Interaktionsoperanden innerhalb und außerhalb eines kombinierten Fragments. Man setzt sie auf den Rahmen des Diagramms.

Das UML-Sequenzdiagramm kennt vier Arten von Gates. Sie unterscheiden sich durch die Interaktionsfragmente, mit denen sie assoziiert werden:

• Das faktische Tor: Interaktionsnutzen verweisen von einem Diagramm auf ein anderes. Das faktische Tor öffnet die Verbindung am äußeren Rand des Interaktionsnutzens für Nachrichten aus der Interaktion, auf die der Interaktionsnutzen verweist. Das Tor hat also eine Assoziation zum Interaktionsnutzen und akzeptiert eingehende und ausgehende Nachrichten. (Englisch: Actual Gate)
• Das formale Tor: Damit eine Interaktion Nachrichten mit einem Interaktionsnutzen austauschen kann, braucht es ein formales Tor. Das Tor befindet sich auf der Innenseite des Rahmens. (Englisch: Formal Gate)
• Das innere Tor für kombinierte Fragmente: Innerhalb eines kombinierten Fragments sitzt ein Gate am Rahmen. Nachrichten mit Nachrichtenenden aus dem kombinierten Fragment tauscht es mit Nachrichten mit Nachrichtenenden außerhalb des kombinierten Fragments aus. (Englisch: Inner CombinedFragment Gate)
• Das äußere Tor für kombinierte Fragmente: Dieses Tor sitzt auf dem äußeren Rand eines kombinierten Fragments. Es bildet den Gegenpol zum inneren Tor. (Englisch: Outer CombinedFragment Gate)

Gates haben explizite oder implizite Namen, die paarweise übereinstimmen müssen. Faktische und formale Tore müssen übereinstimmen, genauso wie innere und äußere Tore für kombinierte Fragmente. Außerdem müssen die Nachrichten in die gleiche Richtung gehen und die gleichen unverkennbaren Eigenschaftswerte sowie dieselbe MessageSort haben.

Eine besondere Rolle spielen Nachrichten in Kommunikationsdiagrammen. Dieser Diagrammtyp ist eine simple Form des Sequenzdiagramms. Kommunikationsdiagramme modellieren, wie Lebenslinien interagieren. Anders als Sequenzdiagramme konzentrieren sie sich auf die Systemarchitektur und darauf, wie diese den Nachrichtenfluss bedingt. Zwar können Sie eine detaillierte Architektur aufzeigen, Interaktionsfragmente wie kombinierte Fragmente nutzen sie aber nicht. Dadurch fehlt ein Strukturelement. Stattdessen nummerieren Sie die Nachrichten. Manchmal können Nachrichten andere überholen. Die Reihenfolge der ausgehenden Nachrichten weicht dann ab von der Reihenfolge der eingehenden Nachrichten. Der UML-Standard rät aber von solchen nicht-sequenziellen Nachrichten im Kommunikationsdiagramm ab.

Die UML-Notation für Kommunikationsdiagramme schreibt einen einfachen Sequenzdiagramm-Rahmen vor: Ein Rechteck mit fünfeckigen Label im Kopf. Im Label markiert die Bezeichnung „sd“ diesen Diagrammtyp. Daneben notieren Sie den Interaktionsnamen. Nachrichten erhalten hier eine andere Form: Sie verbinden die rechteckigen Lebenslinien (UML: Objektknoten) als einfache Geraden (UML: Kanten).

Darüber notieren Sie die Sequenzbezeichnung (Englisch: Sequence Expression) zusammen mit einem Pfeil, der in Richtung Empfänger zeigt. Die Sequenzbezeichnung hat folgende Form: [Integer|Name] [Wiederholung]. Der Integer gibt die Hierarchie für verschachtelte Elemente an. Weicht bei zwei Nachrichten einer der Integer ab (zum Beispiel 1.2.2 und 1.2.3), sendet sie das System nacheinander. Der Name hingegen steht für gleichzeitige Sendungen. Zwei Nachrichten mit der Sequenzbezeichnung 1.2.3a und 1.2.3b sendet das System aufgrund des gleichlautenden Integers gleichzeitig ab. Die Wiederholung beinhaltet entweder eine Einschränkung, die bestimmt, wann die Nachricht versandt wird, oder einen Wert, der festlegt, wie oft die Nachricht wiederholt wird.

In UML bewacht der Guard für das Verhalten eines Elements. Das Element muss entweder:

• eine bestimmte Voraussetzung erfüllen,
• einen bestimmten Wert nicht über- oder unterschreiten oder
• eine Behauptung bestätigen

Ein Guard ist somit eine Einschränkung. Nur wenn die Einschränkung erfüllt wird, kann das beeinflusste Element ein bestimmtes Verhalten ausüben. Es gibt viele unterschiedliche Elemente, die solch einen Guard aufweisen können: Aktionen, Attribute, Verhalten und andere. UML schreibt keine strikte Sprache vor, bietet aber OCL, die Object Constraint Language, als native Option. Boolesche Variablen kommen auch oft zum Einsatz.

Eine Interaktionseinschränkung besteht aus so einem booleschen Ausdruck. Die Einschränkung dient als Wächter für den Operanden innerhalb eines kombinierten Fragments. Nur wenn der Wert der Einschränkung wahr ist, startet das umschließende Interaktionsfragment sein Verhalten. Die Einschränkung notieren Sie in eckigen Klammern auf der Lebenslinie über einer Ausführungsspezifikation. Die Standardisierung lässt kombinierte Fragmente ohne Interaktionseinschränkung zu. In diesem Fall geht das System davon aus, dass eingehende Nachrichten wahr sind.

Da Interaktionsnutzen auf andere Diagramme verweisen, bestimmen diese äußeren Faktoren ihr Verhalten. Während die verlinkte Interaktion formale Tore (Englisch: Gates) aufweist, verfügt die verweisende Interaktion über das tatsächliche Tor.

Die Teil-Dekomposition (Englisch: Part-Decomposition) ist die teilweise, sequentielle Zerlegung einer Lebenslinie innerhalb einer Interaktion durch eine andere Interaktion. Mithilfe solch einer Zerlegung können Sie Details voneinander trennen und so einzelne Teilfunktionen genauer betrachten. Gehen Nachrichten von der zerlegten Lebenslinie ein oder aus, gelten sie als tatsächliche Gates. Diese stehen mit den formalen Gates der Dekompositionsaktion in Verbindung. Gates und Parameter beider Elemente müssen übereinstimmen. Als Interaktionsnutzen erhält die Teil-Dekomposition auch das Label „ref“ und wird durch die verbundene Interaktion definiert.

Anfang und Ende markieren die Ereignisauftrittsspezifikationen, kurz Auftrittsspezifikation (Englisch: Event Occurrence Specification). Am Anfang einer Aktivierung steht das Startereignis, am Ende das Abschlussereignis. Diese Fragmente repräsentieren jeweils einen einzelnen Moment und existieren auf einer einzigen Lebenslinie. Die Ereignisauftrittsspezifikation steht für den Anstoß oder das Ende einer Aktion. Die Nachrichtenauftrittsspezifikation (Message Occurrence Specification) gibt das Signal zum Senden und Empfangen einer Nachricht. Somit hängt deren Wert immer von der Nachricht oder Aktion ab.

Die Aktivierung hat keine gesonderte Notation. Sie existiert implizit an den äußeren Rändern des Rechtecks der Ausführungsspezifikation. Durchläuft die Ausführungsspezifikation eine atomare Aktion, verweisen Anfangs- und End-Assoziationen auf dieselbe Auftrittsspezifikation. Das können Sie mit einer Verbindungslinie zwischen Aktion und eingehender Auftrittsspezifikation hervorheben.

Während andere Auftrittsspezifikationen keine Notation erfordern, kennzeichnen Sie die Nachrichten-Auftrittsspezifikation Zerstörung mit einem großen X. Sie markiert die Auflösung einer Objektinstanz an einem bestimmten Punkt auf der Lebenslinie. Die Lebenslinie endet damit. Untergeordnete Instanzen oder Auftrittsspezifikationen an späteren Punkten der Timeline sind dann invalide. Denn nach der Zerstörung des Objekts existieren auch sie nicht mehr.

Manchmal überlappen sich Ausführungsspezifikationen. Wenn ein Objekt beispielsweise eine Nachricht an sich selbst schickt, sendet eine Execution Specification eine Nachricht an eine andere Instanz dieser Klasse. Beide Spezifikationen liegen teilweise zeitgleich auf derselben Lebenslinie. Im UML-Sequenzdiagramm stellen Sie diesen Umstand mit überlappenden Rechtecken dar.

Die Zustandsinvariante gibt einen einschränkenden Wert vor. Ist dieser Wert gleich dem Objektzustand, gilt die Spur als valide. Erfüllt das Objekt die Einschränkung nicht, ist seine Spur ungültig.

Laut der UML-Sequenzdiagramm-Notation steht die Zustandsinvariante entweder in geschweiften Klammern auf der Ausführungsspezifikation oder Sie nutzen das abgerundete Rechteck der Klasse Zustand.

Kombinierte Fragmente gehören zu den Interaktionsfragmenten. Diese Fragmente sind abstrakte Elemente des Systems. Sie stehen für Interaktionseinheiten. Das heißt, dass sie zum einen Teil einer Interaktion sind. Zum anderen sind sie aber auch selbst kleine Interaktionen. Kombinierte Fragmente in einem Sequenzdiagramm legen das Verhalten mehrerer Interaktionsfragmente fest. Sie selbst bilden aber nur den Rahmen. Denn sie werden von Interaktionsoperatoren und Interaktionsoperanden definiert. Operanden beinhalten eine oder mehrere Nachrichten. Auf der Lebenslinie vor einem kombinierten Fragment wacht dann eine Einschränkung, auch Guard genannt, über den beinhalteten Operanden.

Wie bereits beschrieben, sind Operanden konstante oder variable Größen, die einen Prozess durchlaufen. Operatoren beeinflussen das Verhalten der Operanden. Zum Beispiel kann der boolesche Operator „OR“ vorschreiben, dass Operand A oder Operand B ausgeführt wird (oder beide ausgeführt werden). Innerhalb eines kombinierten Fragments legt ein Operand fest, dass unter bestimmten Voraussetzungen eine bestimmte Nachricht gesendet wird. Der Operator legt fest, welche Beziehungen Operanden innerhalb eines Fragments zueinander haben und welche Beziehung sie zum übergeordneten Fragment haben.

UML definiert 12 Interaktionsoperatoren.

Alternative:

Im Rahmen des kombinierten Fragments mit dem Interaktionsoperator „Alternative“ kann ein untergeordnetes Fragment nur eine Nachricht senden, wenn eine bestimmte Bedingung erfüllt wird. Andernfalls sendet ein konkurrierendes Fragment innerhalb des Rahmens seine Nachricht. Im oberen Bild sehen Sie ein Beispiel für ein kombiniertes Fragment mit dem Operator „Alternative“. Für das Label nutzen Sie das Kürzel „alt“. Den rechteckigen Rahmen teilen Sie durch eine horizontale, gestrichelte Linie auf. Der obere Bereich stellt eine Bedingung.

Guard:

Der Guard (Wächter) untersucht, ob die Bedingung des Operanden erfüllt wird. Falls ja, sendet das System eine Nachricht im Bereich der Bedingung. Falls nicht, sendet es eine Nachricht im Bereich der Alternative. Ein Operand innerhalb dieses kombinierten Fragments braucht immer einen Guard, der als wahr („true“) beurteilt wird, um ausgeführt zu werden. Hat der Bedingungsoperand keinen expliziten Guard, wird ein impliziter Guard vorausgesetzt. Dieses Fragment stellt also immer eine Entweder-oder-Entscheidung dar.

Option:

Dieses kombinierte Fragment modelliert man im Sequenzdiagramm wie die Alternative. Denn die Option steht auch für eine Entscheidung. Es gibt jedoch nur einen Operanden. Die Entscheidung besteht also darin, ob der Operand ausgeführt wird oder nicht. Der Operand mit einer Bedingung darf nicht leer sein. Seine Alternative hingegen ist leer. Ein Fragment mit dem Interaktionsoperator „Option“ markieren Sie mit dem Label „opt“.

Unterbrechung:

Ein kombiniertes Fragment mit dem Interaktionsoperator „break“ unterbricht das übergeordnete Fragment. Erfüllt eine Lebenslinie die Bedingung des Operanden, führt das System das kombinierte Fragment aus. Dafür ignoriert es den Rest des übergeordneten Fragments. Damit alle Lebenslinien ihre Lebensdauer ausschöpfen können, sollten Sie jede Lebenslinie im kombinierten Fragment einbinden. Andernfalls stoppt womöglich eine Lebenslinie mitten im Prozess, ohne ordentlich zerstört zu werden. Fehlt dem Break-Fragment ein Guard, ist die Entscheidung nichtdeterministisch. Wir empfehlen daher, einen Guard zu verwenden.

An einem Geldautomaten hat man beispielsweise dreimal die Möglichkeit, die richtige PIN-Nummer einzugeben. Ist der PIN falsch, wird man aufgefordert die Eingabe zu wiederholen. Im UML-Sequenzdiagramm notieren Sie die Nachricht „PIN-Eingabe“ und deren Antwort „Falscher PIN. Versuchen Sie es erneut.“ mit den entsprechenden Pfeilen. Das Label hat die Form Loop (0,2). Die boolesche Variable ist [falscher PIN]. Solange der PIN falsch ist, widerholt sich der Loop zweimal. Ist der PIN richtig, löst das System den Loop auf. Wird die maximale Wiederholungszahl überschritten, löst sich der Loop ebenso, aber der Vorgang wird als ungültig abgebrochen.

Abhängig davon, wie Sie die Fortsetzung im Sequenzdiagramm anordnen, ändert sich auch ihre Aufgabe. Steht die Fortsetzung am Anfang Ihres Interaktionsdiagramms, modellieren Sie damit das Verhalten der Fortsetzung. Steht die Fortsetzung am Ende Ihres Interaktionsfragments, leitet sie den Prozess weiter. Benennen Sie Ihre Fortsetzung (wie im Beispiel: nichtOK), muss das nächste Fragment auf der Lebenslinie eine Fortsetzung mit gleichem Namen (nichtOK) aufweisen oder es darf keine Fortsetzung modellieren. Steht die Fortsetzung alleine im Fragment, entspricht das einer Fortsetzung am Ende des Fragments.