Sequenzdiagramme: Den Nachrichtenaustausch in einem System mit UML darstellen
IONOS Redaktion
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.
Sequenzdiagramme: Nutzen und Besonderheiten
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.
Sequenzdiagramme unterstützen logische Analysen für Teilbereiche von Systemen. Spielt der zeitliche Ablauf von Prozessen eine wichtige Rolle, ist dieser Diagrammtyp dafür hervorragend geeignet. Aber es ist nicht sinnvoll, ein ganzes System damit darzustellen. Verweisen Sie stattdessen lieber an günstiger Stelle auf ein passendes Verhaltensdiagramm wie das Anwendungsfalldiagramm, das Zustandsdiagramm oder das Aktivitätsdiagramm. Diese illustrieren auch größere Zusammenhänge übersichtlich und leicht verständlich.
UML-Sequenzdiagramme: Notation und Beispiele
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.
Lebenslinien
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.
Ein Operand in der Computertechnik ist ein Objekt, das durch einen Operator beeinflusst wird. Operanden können konstant oder variabel sein. Ein simpler Operand ist beispielsweise die Variable X. Operatoren können simple arithmetische Operatoren wie „+“ und „-“ sein. In der Programmierung nutzt man diese Bestandteile für simple Funktionen wie „x = t * 4“ bis hin zu ausgefeilten Algorithmen.
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.
Nachrichten
Die Nachricht ist ein grundlegendes Element des Sequenzdiagramms. In der objektorientierten Programmierung besteht ein System aus Objekten. UML stellt diese Objekte als Knoten dar, die über sogenannte Kanten verbunden sind. In UML verrichten solche Kanten verschiedene Aufgaben. Im UML-Sequenzdiagramm modellieren sie die Metaklasse Nachrichten. Die Notation schreibt als Grundform der Kante eine Linie vor. Pfeile sind eine spezielle Form von Kanten, die eine gerichtete Beziehung oder einen Informationsfluss darstellen. Im Sequenzdiagramm symbolisieren sie Nachrichten. Unterschiedliche Nachrichtentypen werden also unterschiedlich dargestellt, wie im untenstehenden Bild zu sehen ist.
Versehen Sie die Nachricht mit einem Label, das ihren Inhalt aufzeigt. Für simple Nachrichten nutzen Sie folgende Form:
[Nachrichtenname] : [attribute "="] Signalname oder Operationsname [Argumente] [":" Rückgabewert]
Valide Argumente für Nachrichten sind:
- Konstanten
- Wildcard-Werte (symbolische Werte, die einen im Diagramm legalen Wert X darstellen)
- Attribute des Senders
- Parameter der umschließenden Interaktion
- Attribute der übergeordneten Klasse
Nachrichten haben eine Signatur. Diese spezifiziert den Inhalt der Nachricht. Die Signatur bezieht sich entweder auf ein Signal oder eine Operation und muss jeweils danach benannt sein. Das heißt, dass der Inhalt der Nachricht entweder eine Operation (also eine Aktivität) beim Empfänger anstößt oder ein Signal verschickt – also nur Informationen austauscht. Außerdem unterscheiden sich Nachrichten dahingehend, ob sie synchron oder asynchron sind. Bei asynchronen Nachrichten wartet der Sender nicht auf Antwort, sondern nimmt sofort sein Verhalten wieder auf. Synchrone Nachrichten warten auf eine Antwort und blockieren solange den Kanal, auf dem sie senden.
Das sind die standardisierten Nachrichtentypen im UML-Sequenzdiagramm:
- Asynchrone Nachrichten des Typs (MessageSort) asynchCall rufen eine Operation auf und stoßen ihre Ausführung an. Bei asynchronen Nachrichten wartet das System nicht auf eine Antwort des Empfängers, sondern setzt seine Prozesse ohne Unterbrechung fort. Operationsparameter und Nachrichtenattribute müssen zusammenpassen.
- Der Typ asynchSignal wird für Signalinstanzen genutzt. Er repräsentiert Versand und Empfang asynchroner Nachrichten. Solch eine Nachricht entsteht durch eine asynchrone Sendeaktion des Signals. Hier bestimmen die Signalattribute die Nachrichtenargumente.
- Notation: Asynchrone Nachrichten modellieren Sie als Pfeil mit durchgehender Linie und offener Pfeilspitze.
- Synchrone Nachrichten rufen nur Operationen auf, keine Signale. Der Nachrichtentyp heißt synchCall. Synchrone Nachrichten warten auf eine Antwort der Operation, bevor sie ihr Verhalten wieder aufnehmen. Synchrone Nachrichten stellen Sie als Pfeil mit einer gefüllten Pfeilspitze dar.
- Antworten sendet der Empfänger einer Nachricht zurück an den Absender, nachdem die Operation zu einem Ergebnis gekommen ist. Das Symbol dafür hat eine offene oder eine gefüllte Pfeilspitze. Die entsprechende Linie ist gestrichelt.
- Die createMessage ist ein Nachrichtentyp, der eine neue Instanz einer Lebenslinie signalisiert. Damit erschafft das System ein neues Objekt im Sequenzdiagramm. Dieser Nachrichtentyp ist der einzige, der direkt auf den Kopf der Lebenslinie verweist. Andere Nachrichten müssen auf die gestrichelte Lebensdauer-Linie zeigen. createMessage hat einen Pfeil mit offener Spitze und gestrichelter Linie wie die Antwort, sie zeigt aber in die entgegengesetzte Richtung.
- Die deleteMessage signalisiert den Punkt Laufzeit, an dem eine Lebenslinien-Instanz zerstört wird. Die Löschnachricht zeichnen Sie frei als Pfeil, optional mit dem Titel <<destroy>>. Sie muss immer auf eine Destruction Occurrence Specification zeigen. Auch Zerstörungsereignis genannt, markiert diese Ereignisauftrittsspezifikation die Zerstörung eines Objekts auf der Laufzeit-Linie mit einem X.
Nachrichten jeden Typs können Absender oder Empfänger fehlen – oder er ist unbekannt. Der UML-Standard geht dann davon aus, dass die jeweilige Instanz außerhalb des beschriebenen Diagramms liegt. Kennen Sie den Empfänger, aber nicht den Absender, handelt es sich um eine gefundene Nachricht. Dort, wo Sie sonst den Absender modellieren würden, signalisiert ein kleiner, gefüllter Kreis dessen Abwesenheit. Genau andersherum verhält es sich mit der verlorenen Nachricht. Kennen Sie den Empfänger nicht, modellieren Sie einen gefüllten Kreis an die Pfeilspitze.
Eine Sonderform bilden solche Nachrichten, die auf ihre eigene Lebenslinie geschickt werden. Die Lebenslinie sendet dann die Rekursion von einem Aktivitätsbalken ab. Noch während die Aktivierung läuft, setzt auf derselben Lebenslinie eine neue Aktivierung ein. Deren Startpunkt nimmt die gesendete Nachricht an. Diese Art der Nachricht nutzen Sie beispielsweise, wenn eine Operation mehrmals durchgeführt wird und das Objekt deshalb auf sich selber verweisen muss. Nachrichten zwischen zwei Lebenslinien können ebenfalls überlappende Aktivierungen hervorrufen. Weiter unten gehen wir genauer auf die Spezifikationen von Aktivierungen ein.
Ein weiterer wichtiger Bestandteil der Nachricht ist ihr Parameter. Parameter sind Wertspezifikationen. Das System wertet diese Größe aus, wenn es eine Nachricht mit Signatur verschickt. Das passiert an der Auftrittsspezifikation, also an dem Punkt, an dem die Nachricht abgesendet wird. Das Ergebnis gibt die Werte für Signalattribute oder Operations-Input-Parameter vor – je nachdem, wer der Empfänger ist. Die Operation verarbeitet dann den Wert weiter und produziert einen Output-Parameter.
Eine Besonderheit ist der Wildcard-Parameter. Fehlen der Nachricht sämtliche Parameter, erfordert die Syntax einen leeren String. Dieses Symbol signalisiert, dass der Parameterwert nicht festgelegt ist. Trotzdem ist er im Sinne der Parameter oder Attribute des Empfängers valide. Er verhält sich also wie ein Joker. Wildcard-Zeichen sind Platzhalter für einzelne Buchstaben oder ganze Zeichenketten. Viele kennen den Asterisk (*) als Platzhalter. In UML steht der Bindestrich („-“) für den Wildcard-Parameter.
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.
Die Parameter IN, OUT und INOUT geben an, ob eine Instanz Werte annimmt oder abgibt. Der IN-Parameter signalisiert, dass eine Instanz Werte empfängt und verarbeitet, aber nicht versendet. Der OUT-Parameter legt fest, dass sie keine Werte annimmt, sondern nur ausgibt. Der INOUT-Parameter lässt sowohl eingehende als auch ausgehende Werte zu. Definieren Sie keinen dieser Werte, nimmt das System IN als Standard an.
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.
Guards
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.
Interaktionsfragmente in Sequenzdiagrammen
Wenn Sie ein Sequenzdiagramm erstellen, sind Lebenslinien und Nachrichten die wichtigsten Bestandteile. UML2 empfiehlt einen Rahmen für diesen Diagrammtypen. Er ist aber keine Pflicht. Der Rahmen begrenzt einen Teilprozess, das sogenannte Interaktionsfragment. Alle dafür nötigen Lebenslinien und Nachrichten befinden sich innerhalb des Rahmens. Er besteht aus einem Rechteck mit einem Label in der oberen linken Ecke. Das Kennzeichen für ein Sequenzdiagramm ist die Abkürzung sd, das meist gefettet wird. Daneben trägt man den Namen der Interaktion ein, wie unten im Bild zu sehen.
Außer der optischen Begrenzung dient der Rahmen auch funktionalen Aspekten. Erstellen Sie mehrere Sequenzdiagramme (oder andere Interaktionen), grenzt der Rahmen diese Darstellungen voneinander ab. Wollen Sie zeigen, dass die verschiedenen Interaktionsfragmente miteinander kommunizieren, modellieren Sie eine Nachricht (gefüllter Pfeil) an die Rahmenlinie. Oben im Bild sendet das System Nachricht 5 nach außen. Den Punkt, an dem Pfeil auf Rahmen trifft, nennt man Gate. Dieses Element hat eine Funktion innerhalb des Diagramms, verfügt aber über keine eigene Notation.
Interaktionsfragmente gehören in UML zu den Knoten. Dieser Oberbegriff ist sehr allgemein gefasst. Die Eigenschaften und Aufgaben von Knoten spezifiziert UML in Abhängigkeit von dem jeweiligen Diagrammtypen, in dem ein bestimmter Knoten vorkommt. Generell kann man sagen: Knoten sind Modellelemente innerhalb eines Systems oder Prozesses, auf denen ein Artefakt installiert werden kann. Knoten verbindet UML durch Kanten. Kanten stellen den Informationsaustausch grafisch durch Pfeile oder einfache Linien dar.
In UML können Sie Sequenzdiagramme erstellen, die verschachtelte Teilsegmente beinhalten. Rahmen helfen, die einzelnen Fragmente geordnet darzustellen.
Sequenzdiagramme können die Interaktionsfragmente Interaktionsnutzen, Zustandsinvarianten, Ereignisauftrittsspezifikation, Ausführungsspezifikation und kombinierte Fragmente beinhalten.
Interaktionsnutzen
Interaktionsnutzen bilden eine Unterklasse, die Notation, Aufbau und Verhalten zweier Metaklassen festschreibt. Diese Metaklassen sind Interaktionsnutzen und Teil-Dekomposition.
Der Interaktionsnutzen als Metaklasse ist ein Interaktionsfragment, das eine andere Interaktion aufruft oder nutzt. Wenn Ihr Sequenzdiagramm zu komplex wird, sorgen Sie mit diesem Verweis für mehr Übersichtlichkeit. Denn die Interaktion, auf die der Interaktionsnutzen verweist, sehen Sie im aktuellen Diagramm in einer Black-Box-Ansicht. Um die aufgerufene Interaktion eindeutig identifizieren zu können, geben Sie folgende Syntax im Körper an (Feld, in dem Instanzen Operationen durchführen):
- Attributname (Attribut einer Lebenslinie im Interaktionsnutzen, die den Rückgabewert erhält)
- Kollaborationsname (identifizierte Kollaborationsnutzen, die Interaktionen und Kollaborationen aneinanderknüpfen)
- Interaktionsname des aufgerufenen Elements
- io-Argument: In/Out-Argumente der Interaktion
- Rückgabewert (Antwort der aufgerufenen Interaktion)
Den Interaktionsnutzen modellieren Sie als Rechteck mit einem fünfeckigen Label in der linken, oberen Ecke. Darin tragen Sie das Kürzel „ref“ ein (von Englisch: „referral“).
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.
Aktivitätsbalken/Ausführungsspezifikation
Der Aktivitätsbalken, im Englischen Execution Specification (umgangssprachlich schlicht: Aktivierung), steht für die Zeit auf einer Lebenslinie, in der ein Objekt ein Verhalten ausführt oder eine Aktion durchläuft. Außerdem modellieren Sie damit die Zeit, in der ein involviertes Objekt entweder eine Nachricht sendet oder auf eine Antwort wartet. Denn der Aktivitätsbalken steht für einen abstrakten Zeitabschnitt während der Laufzeit. Wie es ohnehin für das ganze Diagramm gilt, ist Zeit dabei keine absolute Größe, sondern relativ. Passives Verhalten wie das Warten auf eine Antwort muss ebenfalls als Aktivierung in das Sequenzdiagramm eingetragen werden.
Die Spurensemantik einer Ausführungsspezifikation stellt UML durch die simple Struktur <start,ende> dar. Die Notation für die Exectution Specification lässt zwei Formen zu. Modellieren Sie ein langes, schmales Viereck mit grauer Füllung auf die Lebenslinie. Normalerweise beinhaltet die Aktivierung in dieser Form kein Label im Körper. Alternativ zeichnen Sie ein etwas breiteres, weiß gefülltes Rechteck auf die Lebenslinie. Dort haben Sie Platz, um dem Aktivitätsbalken ein Label zu geben. Führt ein Objekt eine Aktion während der Laufzeit durch, geben Sie dort den Aktionsnamen an.
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.
Eine atomare Aktion erscheint wie eine Blackbox. Es ist eine nicht teilbare Sequenz mehrerer simpler Operationen, die man nicht beobachten kann, weil sie extrem schnell ausgeführt werden. Eine atomare Aktion erscheint daher unmittelbar abgeschlossen.
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.
Zustandsinvariante
Die Zustandsinvariante ist eine Laufzeit-Einschränkung. Die Lebenslinie repräsentiert ein Objekt. Während der Laufzeit ändert dieses Objekt durch die Ausführungsspezifikation seinen Zustand. Die Zustandsinvariante untersucht das Objekt hinsichtlich seiner Zustandsänderung in der Ausführungsspezifikation – und zwar direkt bevor es die nächste Auftrittsspezifikation ausführt. Alle vorhergehenden, impliziten Aktionen innerhalb der Ausführungsspezifikation gelten dann als ausgeführt.
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
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.
Interaktionsoperatoren
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.
Nichtdeterminismus ist in der theoretischen Informatik ein Konzept, das Modellierung vereinfachen soll. Dabei hat ein System bei einem gleichen Ausgangswert mehr als eine Möglichkeit, zu einem Ergebnis zu kommen. In der Praxis verwendet man hauptsächlich deterministische Algorithmen mit nur einem Berechnungsweg. Ein nichtdeterministischer Algorithmus geht hingegen einen nicht vorhersehbaren Weg bei der Berechnung, auch wenn Sie das System mit den gleichen Angaben starten. Da der Algorithmus im Vergleich meist zu deutlich mehr unterschiedlichen Ergebnissen kommt als ein deterministischer Algorithmus, sollte die gestellte Aufgabe weniger komplex sein. Abstrakte Modelle vereinfachen komplexe Systeme. Daher eignen sie sich dafür, unterschiedliche Berechnungen mit dem nichtdeterministischen Algorithmus durchzuspielen.
Die Schleife:
Ein kombiniertes Fragment mit dem Interaktionsoperator „loop“ wiederholt seinen Operanden. Die genaue Anzahl der Durchläufe bestimmt der Guard. Dieser Wächter kann Wiederholungsschranken und boolesche Variablen umfassen. Die Wiederholungsschranken notieren Sie im Rahmen-Label folgendermaßen: loop (X,Y). Die Variablen X und Y stehen jeweils für eine natürliche Zahl. X ist die minimale Wiederholungszahl („min-int“). Y ist die maximale Wiederholungszahl („max-int“). X muss dabei eine nicht-negative Zahl sein, Y eine nicht-negative Zahl, die gleich groß oder größer ist als die minimale (also > 0).
Die boolesche Variable notieren Sie optional im Rahmenkörper neben dem Label. Sie schränkt die Wiederholung weiter ein. Wird die Bedingung der booleschen Variable nicht mehr erfüllt und die minimale Wiederholungszahl ist erreicht, stoppt der Loop. Notieren Sie die Einschränkung in eckigen Klammern. Diese Einschränkung bezieht sich auf externe Faktoren wie Eingaben eines Akteurs.
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.
Geben Sie keine Wiederholungsschranken an, ist das Minimum 0 und das Maximum unendlich. Geben Sie nur eine Schranke an, haben Minimum und Maximum den gleichen Wert.
Parallel:
Normalerweise schreibt die Position eines Pfeils auf der Lebenslinie im Sequenzdiagramm immer eine chronologische Ordnung vor. In einem kombinierten Fragment mit dem Interaktionsoperator Parallel dürfen dessen Operanden ihre Prozesse gleichzeitig ausführen. Potenziell verflechten die Operanden ihre Prozessordnung. Die vorgegebene Ordnung innerhalb der Operanden wird dabei aber immer beibehalten. Im UML-Sequenzdiagramm modellieren Sie dieses kombinierte Fragment mit einem durchgehenden Rahmen. Die verschiedenen Operanden trennen Sie optisch durch gestrichelte Linien, ähnlich wie bei der Alternative. Im Label tragen Sie das Kürzel „par“ ein (siehe Abbildung unter Critical Region). Sollen Operanden auf einer einzigen Lebenslinie parallel arbeiten, erlaubt UML eine Abkürzung: Die Co-Region erfüllt genau diese Aufgabe. Dafür fassen Sie einfach die betroffenen Ereigniseintritte mit einer eckigen Klammer zusammen.
Kritischer Abschnitt:
Mithilfe eines kritischen Abschnitts vermeidet das System Fehler, die auftreten können, wenn sich mehrere Prozesse Ressourcen teilen. Innerhalb dieses Systembereichs nutzt immer nur ein Prozess zu einem bestimmten Zeitpunkt die Ressource. Zudem priorisiert das System den jeweiligen Prozess. Mit dem Label „critical“ definieren Sie einen kritischen Abschnitt (Englisch: Critical Region). Dieser verhindert, dass möglicherweise andere Interaktionsoperatoren in einem übergeordneten Fragment Einfluss nehmen. Zum Beispiel blockiert es im Sequenzdiagramm verschachtelte Spuren eines parallelen, kombinierten Fragments.
Eine Gasanbieter-Hotline nimmt in der oberen Grafik mehrere Anrufe parallel an und leitet diese gleichzeitig an Hotline-Mitarbeiter weiter. Handelt es sich aber um einen Notfall mit Verdacht auf Gasgeruch, priorisiert das System die Nachricht und leitet den Anruf über den kritischen Abschnitt an den Notfalldienst. Der kritische Abschnitt hindert Informationsströme aus dem übergeordneten Fragment, parallel mit der Nachricht aus dem kritischen Abschnitt bearbeitet zu werden. Nur Lebenslinien im kritischen Abschnitt verhalten sich so.
Assertion:
Der Interaktionsoperator „assertion“ (auch Zusicherung oder Sicherstellung) legt den Zustand von Fortsetzungen fest. Sequenzen innerhalb eines Operanden mit dem Label assert gelten als valide Fortsetzungen. Die Zusicherung behauptet, dass alle Sequenzen außerhalb des Fragments in ungültigen Spuren enden.
Ignorieren/Berücksichtigen:
Ein UML-Sequenzdiagramm stellt einen Systemteil detailliert dar. Manche Nachrichten benötigen Sie für die Ansicht nicht. Andere wollen Sie berücksichtigen. Mit dem Interaktionsoperator „ignore“ klammern Sie bestimmte Nachrichten aus. Diese Informationen tauchen im System auf einer Spur auf, aber nicht im ignore-Fragment. Die Notation schreibt ein Label in dieser Form vor: ignore {Nachricht1,Nachricht2}.
Kombinierte Fragmente mit dem Interaktionsoperator „consider“ hingegen berücksichtigen bestimmte Nachrichten in einem Fragment. Alle anderen Nachrichten, die durch das Fragment laufen, ignoriert das System. Zu berücksichtigende Nachrichten setzen Sie ebenfalls in geschwungene Klammern: consider {Nachricht3,Nachricht4}.
Diese beiden Operatoren haben gegensätzliche Aufgaben. Beide kommen aber häufig in verschachtelten Fragmenten vor. Zum Beispiel kombinieren Modellierer häufig assert mit ignore (in dieser Form: assert ignore {Msg1, Msg2}) oder assert und consider (in dieser Form: assert consider {Msg3, Msg4}).
Negativ:
Um einen Systemfehler zu kennzeichnen, nutzt man den Interaktionsoperator „negativ“. Das kombinierte Fragment umfasst also ungültige Spuren. Der Operator kommt beispielsweise zum Einsatz, wenn Sie ein Log-in-Verfahren über ein Sequenzdiagramm darstellen. Modellieren Sie die Lebenslinie eines Akteurs auf dem Weg zum Time-out, umrahmen Sie diese Fehlernachricht mit dem Negativ-Fragment. Das Label dafür ist neg. Durch die explizite Modellierung ungültiger Spuren im negativen kombinierten Fragment gelten alle anderen Fragmente als positiv. Ihre Spuren sind valide.
Strikte Sequenzierung:
Innerhalb eines kombinierten Fragments kann es wichtig sein, eine strikte Ordnung einzuhalten. Das Label strict erlegt seinen Operanden eine strikte Sequenzierung auf. Dies gilt für das erste Level des Fragments. Operanden in weiter verschachtelten Fragmenten unterliegen ihrer eigenen Ordnung.
Schwache Sequenzierung:
Kombinierte Fragmente mit dem Interaktionsoperator „sequence“ stehen für eine schwache Ordnung. Das Verhalten zwischen den Operanden im Fragment beeinflusst Spureneigenschaften statt den Interaktionsoperatoren. So kann eine schwache Sequenzierung wie ein parallel-Fragment agieren. Das passiert, wenn Operanden auf unterschiedlichen Lebenslinien teilnehmen. Im Gegenzug verwandelt sich die schwache Sequenzierung in eine strikte Ordnung, wenn ihre Operanden auf derselben Lebenslinie auftreten. Das Label ist seq.
Spuren mit den folgenden Eigenschaften definieren die schwache Sequenzierung:
- Ereignisspezifizierungen innerhalb eines Operanden behalten ihre Ordnung.
- Ereignisspezifizierungen, die auf unterschiedlichen Lebenslinien agieren und nicht innerhalb desselben Operanden auftreten, treten in beliebiger Ordnung auf.
- Agieren die Ereignisspezifikationen auf derselben Lebenslinie, aber in unterschiedlichen Operanden, schreibt ihre Stelle auf der Lebenslinie ihre Ordnung vor. Der erste Operand kommt also vor dem zweiten Operanden.
Fortsetzung:
Die Fortsetzung (Englisch: Continuation) ist kaum ein eigenständiges Fragment. Nur in den kombinierten Fragmenten Alternative und schwache Sequenz erhält sie eine eigene Semantik. Diese schreibt für die Fortsetzung die gleiche Form wie für Zustände vor: Ein Rechteck mit abgerundeten Ecken. Im Gegensatz zum Zustand deckt eine Fortsetzung optional mehrere Lebenslinien ab.
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.
Wollen Sie Anwendungsbeispiele detailliert darstellen oder ein System auf seine Logik prüfen, erstellen Sie ein Sequenzdiagramm. Die Notation erlaubt Ihnen, den Nachrichtenfluss über die ganze Lebenszeit eines Objekts zu modellieren. Selbst komplexe Operationen stellen Sie mithilfe verschachtelter Interaktionsfragmente übersichtlich dar. Das Sequenzdiagramm ist nicht zu Unrecht eines der meist genutzten UML-Verhaltensdiagramme.
