UML-Sequenzdiagramm: Visualisierung von Zeit und Interaktion

Das UML-Sequenzdiagramm ist ein wesentliches Werkzeug zur Verständnis der dynamischen Verhaltensweise eines Systems. Es modelliert, wie Objekte miteinander interagieren und in welcher Reihenfolge diese Interaktionen stattfinden, wobei der zeitlich geordnete Nachrichtenfluss. Es ist entscheidend für die Definition von Anwendungsfällen, die Dokumentation von API-Aufrufen und die Verfolgung komplexer Transaktionsflüsse.

Dieser Tutorial führt Sie durch die grundlegenden Elemente und Modellierungstechniken des Sequenzdiagramms.

Kernstruktur und Zweck

Ein Sequenzdiagramm ist entlang zweier Achsen organisiert:

1. Horizontale Achse: Zeigt die beteiligten Objekte (oder Akteure, Klassen und Komponenten).
2. Vertikale Achse (Zeitachse): Stellt den Zeitverlauf dar, der nach unten verläuft. Nachrichten, die weiter unten im Diagramm gesendet werden, erfolgen später in der Reihenfolge.

Der Zweck besteht darin, die Frage zu beantworten: „In diesem spezifischen Szenario (Anwendungsfall), in welcher Reihenfolge tauschen diese Objekte Informationen aus, um das gewünschte Ergebnis zu erzielen?“

Grundlegende Elemente eines Sequenzdiagramms

Um eine Sequenz zu modellieren, benötigen Sie drei zentrale Elemente: Lebenslinien, Nachrichten und Aktivitätsbalken.

A. Lebenslinien (Beteiligte)

Eine Lebenslinie stellt einen einzelnen Beteiligten – ein Objekt, eine Instanz oder eine Klasse – in der Interaktion dar.

• Notation: Ein rechteckiger Kasten oben im Diagramm, der den Objektnamen enthält, mit einer senkrechten gestrichelten Linie, die nach unten verläuft.
• Syntax:
  • BeteiligterName (falls das Objekt eine Instanz ist, z. B. Benutzer)
  • InstanzName: KlassenName (z. B. authService: AuthenticationService)
• Zweck: Die gestrichelte Linie zeigt die Existenz des Teilnehmers über die Zeit innerhalb des Bereichs der Sequenz an.

B. Nachrichten (Interaktion)

Nachrichten sind die horizontalen Pfeile, die zwischen Lebenslinien gezeichnet werden. Sie stellen die Kommunikation zwischen Objekten dar, beispielsweise Methodenaufrufe, Signale oder API-Anfragen.

Arten von Nachrichten:

Nachrichtentyp	Notation	Beschreibung
Synchroner Aufruf	Solide Linie mit einem gefüllten Pfeilspitze	Der Absender wartet auf eine Antwort, bevor er fortfährt. Dies initiiert eine Aktivitätsleiste auf der Lebenslinie des Empfängers.
Antwort/Rückgabe	Gestrichelte Linie mit einer offenen Pfeilspitze	Die Antwort auf einen synchronen Aufruf, die die Rückgabe der Kontrolle an den Absender anzeigt. Dies schließt in der Regel die Aktivitätsleiste.
Asynchroner Nachricht	Solide Linie mit einer offenen Pfeilspitze	Der Absender wartet nicht auf eine Antwort und setzt seine eigene Ausführung sofort fort. Häufig in ereignisgesteuerten Architekturen.
Selbstaufruf	Pfeil, der sich zurück auf die gleiche Lebenslinie schließt	Ein Objekt ruft eine seiner eigenen Methoden auf.
Fundene Nachricht	Pfeil, der von einem Endpunkt ausgeht und eine Lebenslinie trifft	Der Absender der Nachricht ist unbekannt oder liegt außerhalb des Diagrammbereichs (z. B. ein externer Auslöser).

C. Aktivitätsleisten (Ausführungsbeschreibung)

Die Aktivitätsleiste (auch Kontrollfokus genannt) ist ein dünnes vertikales Rechteck, das oberhalb einer Lebenslinie gezeichnet wird.

• Notation: Ein solides vertikales Rechteck auf einer Lebenslinie.
• Zweck: Es bezeichnet den Zeitraum, in dem ein Objekt aktiv eine Operation ausführt (d. h. seine Methode ausgeführt wird) oder auf eine synchrone Rückgabe wartet. Es beginnt, wenn eine synchrone Nachricht empfangen wird, und endet, wenn die Antwortnachricht gesendet wird.

Modellierung von Logik und Steuerfluss

Um komplexe Geschäftslogik zu modellieren, verwenden Sie Fragmente (oder Felder), um Abschnitte des Diagramms zu umgeben.

A. Kombinierte Fragmente

Kombinierte Fragmente ermöglichen es Ihnen, bedingte Logik, Wiederholung und optionale Schritte zu modellieren. Zu den häufigsten Fragmenten gehören:

1. Alternativ (alt): Wird verwendet für if-else Logik. Das Fragment wird durch eine gestrichelte Linie geteilt, und jeder Abschnitt enthält eine Bedingung (einen „Wächter“) in eckigen Klammern. Es kann nur ein Pfad eingeschlagen werden.
   • Beispiel: [wenn Benutzeranmeldeinformationen gültig sind] und [sonst / ungültige Anmeldeinformationen].
2. Option (opt): Wird verwendet für eine ifAnweisung. Die Interaktion innerhalb des Fragments ist optional und wird nur ausgeführt, wenn die Bedingung (Wächter) wahr ist.
   • Beispiel: [wenn der Benutzer Artikel im Warenkorb hat].
3. Schleife (loop): Wird für Wiederholung verwendet. Der Wächter gibt die Bedingung für die Iteration an (z. B. [für jedes Element] oder [während (Wiederholungen < 3)]).
4. Referenz (ref): Wird verwendet, um das Diagramm zu modularisieren, indem auf eine Interaktionssequenz verwiesen wird, die in einem anderen, separaten Sequenzdiagramm definiert ist. Dies verhindert, dass Diagramme zu unübersichtlich werden.
5. Kritisch (crit): Wird verwendet, um einen Abschnitt anzugeben, der nicht unterbrochen werden darf, häufig verwendet, um gleichzeitige Prozesse zu modellieren.

Schritt-für-Schritt-Modellierungsbeispiel

Lassen Sie uns ein vereinfachtes Benutzer-Checkout-Prozess unter Verwendung der Kernelemente:

Schritt	Aktion	Nachrichtentyp
1.	Der Benutzer klickt auf „Zur Kasse“.	Synchroner Aufruf
2.	Das Frontend überprüft den Warenkorb.	Selbstaufruf (im Frontend)
3.	Das Frontend fordert die Zahlungsabwicklung an.	Synchroner Aufruf
4.	Das Zahlungsgateway prüft das Guthaben.	Synchroner Aufruf
5.	Das Zahlungsgateway gibt „Erfolg“ zurück.	Rückmeldung
6.	Das Frontend sendet eine asynchrone Nachricht an den Bestandsdienst, um den Bestand zu reduzieren.	Asynchrone Nachricht
7.	Das Frontend sendet eine synchrone Nachricht an den Bestelldienst, um die Bestellung abzuschließen.	Synchroner Aufruf
8.	Der Bestellservice gibt „Bestell-ID“ zurück.	Rückmeldung
9.	Die Frontend-Anwendung zeigt eine Bestätigungsseite an.	Rückmeldung (an Benutzer)

Modellierung der Logik (Alternativfragment)

Um einen Fehler zu behandeln, verwenden wir ein Alternativ Fragment:

1. Stellen Sie das Prüfung des Zahlungsgateways (Schritt 4 & 5) innerhalb eines alt Fragments.
2. Der erste Abschnitt wird durch [Erfolg]. Dieser Abschnitt enthält die Schritte 6, 7, 8 und 9.
3. Der zweite Abschnitt, getrennt durch eine gestrichelte Linie, wird durch [Fehler]. Dieser Abschnitt enthält eine neue synchrone Nachricht: paymentService -> frontend: Rückgabe „Zahlung fehlgeschlagen“ und die Frontend-Anwendung zeigt eine Fehlerseite an.

Zusammenfassung der Best Practices für Sequenzdiagramme

• Bleiben Sie fokussiert: Ein einzelnes Sequenzdiagramm sollte typischerweise einen einzelnen Anwendungsfall oder eine einzelne atomare Operation modellieren (z. B. „Anmelden“, „Artikel zum Warenkorb hinzufügen“). Verwenden Sie Referenzfragmente für Unterprozesse.
• Beschriften Sie Nachrichten eindeutig: Verwenden Sie Verbalphrasen für Nachrichten, die Methodennamen oder API-Endpunkte widerspiegeln (z. B. processPayment(Betrag, Token)).
• Beteiligte korrekt identifizieren: Unterscheiden Sie zwischen dem Aktionspartner (externes Element) und dem Objekt (interner Systemkomponente oder Instanz).
• Die Zeit fließt nach unten: Stellen Sie sicher, dass Nachrichten konsistent von oben nach unten angeordnet sind.
• Verwenden Sie Fragmente zur Steuerung: Vermeiden Sie das Zeichnen komplexer Entscheidungsknoten oder Schleifen innerhalb des Nachrichtenflusses selbst; verwenden Sie alt, opt, und loop Fragmente.

Um weitere Details zu UML und seinen künstlichen-intelligenz-gestützten Visualisierungsmethoden zu erhalten, besuchen Sie unsere UML-Ressourcen-Portal.

Der Artikel ist auch in English, Español, فارسی, Français, Bahasa Indonesia, 日本語, Polski, Portuguese, Ру́сский, Việt Nam, 简体中文 and 繁體中文 verfügbar.