Sequenzdiagramme

Ziel

Das Sequenzdiagramm spezifiziert das Verhalten eines Szenarios: wer welche Nachricht an wen sendet, in welcher Reihenfolge, und was zurückkommt. Es nimmt einen einzelnen Pfad durch einen Anwendungsfall und rollt ihn Teilnehmer für Teilnehmer ab, von oben nach unten in chronologischer Reihenfolge. Sein Wert beruht auf zwei Einsätzen. Es macht eine Interaktion lesbar genug, um mit den Stakeholdern validiert zu werden, die der Chronologie folgen, ohne die Notation vertieft zu beherrschen. Und es spezifiziert sie präzise genug, damit ein Team dagegen bauen kann, jeder Aufruf benannt, jedes Warten explizit, jeder Zweig durch seine Bedingung geschützt. Das Ergebnis ist eine Verhaltensspezifikation eines Szenarios, zurückverfolgt auf den Anwendungsfall, den es verfeinert. Es zeigt, wie Teilnehmer über die Zeit interagieren; wie sie strukturell verbunden sind, gehört zum UML-Klassendiagramm.

Einsatz

Wann einzusetzen

• Einen Anwendungsfall verfeinern: die Schritte eines Szenarios in konkrete Nachrichten zwischen Teilnehmern überführen.
• Eine Austauschlogik mit Nicht-Technikern validieren: die chronologische Form lässt sich ohne besonderes Rüstzeug verfolgen.
• Reihenfolge und Richtung der Aufrufe einer komplexen Abfolge festlegen: ein Authentifizierungs-Handshake, eine systemübergreifende Transaktion, eine Rückrufbenachrichtigung.
• Die Zusammenarbeit zwischen Komponenten oder Schnittstellenelementen spezifizieren: zeigen, wer wen aufruft, und was zurückkommt.

Wann nicht einzusetzen

• Struktur gefragt, nicht Verhalten: für die Beziehungen zwischen Entitäten das UML-Klassendiagramm nehmen.
• Ein einzelner linearer Fluss, ohne Zweig oder Drittsystem: der Formalismus lohnt sich nicht, ein Anwendungsfall in Prosa genügt.
• Ein Geschäftsfluss für ein nicht-technisches Publikum über Rollen hinweg: hier zu technisch, die Prozessmodellierung nehmen.

Beschreibung

Ein Sequenzdiagramm ist ein Interaktionsdiagramm: Es modelliert die Logik eines Szenarios über die Nachrichten, die zwischen einer Menge von Teilnehmern ausgetauscht werden, zeitlich geordnet. Es beantwortet eine Frage des Verhaltens, wer mit wem spricht und in welcher Reihenfolge, dort wo das UML-Aktivitätsdiagramm den Kontrollfluss innerhalb eines einzelnen Systems beschreibt und das Klassendiagramm die Struktur. BABOK reiht es unter die Techniken, die einen Anwendungsfall in Interaktionsdetail verfeinern, und nennt es mitunter Ereignisdiagramm.

Teilnehmer, Lebenslinien und Ausführungsbalken

Ein Teilnehmer ist ein Kasten oben im Diagramm, beschriftet mit Name:Klasse, wobei der eine oder andere Teil entfallen kann; ein anonymer Teilnehmer wird :Klasse geschrieben. Ein Teilnehmer, der eine menschliche Rolle oder ein externes System darstellt, der Akteur, kann die Strichfigur tragen. Jeder Kasten besitzt eine Spalte. Von seinem Fuss hängt die Lebenslinie herab, eine senkrechte gestrichelte Linie, die über die ganze Dauer der Existenz des Teilnehmers im Szenario verläuft; die Zeit läuft nach unten. Auf dieser Linie markiert der Ausführungsbalken, ein schmales Rechteck, den Zeitraum, in dem der Teilnehmer eine Operation abwickelt; verschachtelte Balken zeigen einen Aufruf innerhalb eines Aufrufs. Eine Lebenslinie kann in einem grossen Kreuz enden, im Augenblick, in dem der Teilnehmer zerstört wird und aufhört zu existieren.

Die Nachrichten tragen die Bedeutung

Die Bedeutung liest sich in der Form des Pfeils. Eine synchrone Nachricht, ein Aufruf, wird als durchgezogene Linie mit ausgefülltem Kopf gezeichnet: Der Sender blockiert, er kann nichts tun, solange die Antwort nicht zurück ist. Eine asynchrone Nachricht wird als durchgezogene Linie mit offenem Kopf gezeichnet, einer feinen Spitze: Der Sender setzt seine eigene Verarbeitung fort, ohne zu warten. Die Rücknachricht, die Antwort, wird als gestrichelte Linie mit offenem Kopf gezeichnet, die zum Aufrufer zurückkehrt; sie liest sich im Paar mit dem synchronen Aufruf, der sie ausgelöst hat. Die teuerste Verwechslung hängt an einem Detail: Eine Rückgabe, als durchgezogene Linie gezeichnet, wird zu einer asynchronen Nachricht und umgekehrt. Die asynchrone Nachricht und die Rückgabe teilen sich den offenen Kopf; nur die Linie, durchgezogen oder gestrichelt, trennt sie.

Kombinierte Fragmente: verzweigen, wiederholen, parallelisieren

Die Steuerung des Flusses innerhalb einer Interaktion wird als kombiniertes Fragment gezeichnet, ein Rahmen um eine Region des Diagramms, mit einem Operator in der oberen linken Ecke. Vier genügen auf der konzeptuellen Ebene. alt stellt Alternativen auf: zwei geschützte Operanden, durch eine gestrichelte waagrechte Linie getrennt, die Wahl zwischen zwei Zweigen des Diagramms, etwa eine geglückte gegen eine fehlgeschlagene Authentifizierung. opt stellt ein optionales Fragment auf, das nur ausgeführt wird, wenn seine Bedingung wahr ist. loop stellt eine Wiederholung auf, allenfalls begrenzt durch loop(min,max) oder durch eine Bedingung. par stellt nebenläufige Operanden auf, parallel ausgeführt. Die Bedingung, ein boolescher Ausdruck in eckigen Klammern, nennt die Bedingung, unter der eine Nachricht oder ein Operand ausgelöst wird. Ein alt ohne Bedingungen ist der klassische Fallstrick: Es zeigt, dass es zwei Ausgänge gibt, ohne zu sagen, welcher wann eintritt.

Das Diagramm bauen

Das Diagramm wird Szenario für Szenario gebaut. Zuerst ein Szenario wählen, einen einzelnen Pfad durch den Anwendungsfall, den Hauptpfad oder einen bestimmten Alternativfall; ein Diagramm modelliert ein Szenario. Dann die Teilnehmer bestimmen, die auf diesem Pfad Nachrichten austauschen, Akteure, Schnittstellenkomponenten, Dienste und Systeme, Schlüsselobjekte, von links nach rechts in der Reihenfolge ihres ersten Auftretens angeordnet, der Initiator links. Die Köpfe und die Lebenslinien zeichnen. Dann das Szenario der Reihe nach durchgehen, jede Interaktion wird zu einem Pfeil vom Sender zum Empfänger, nach unten; den Pfeiltyp bewusst wählen, synchron für einen blockierenden Aufruf, asynchron für einen Versand ohne Warten, gestrichelt für eine Rückgabe. Die Ausführungsbalken auf den Empfängern hinzufügen, verschachtelt für verschachtelte Aufrufe. Zweige in ein alt oder ein opt hüllen, die Wiederholung in ein loop, die Nebenläufigkeit in ein par und die Bedingungen schreiben. Die nützlichen Lebenszyklus-Ereignisse markieren, Erzeugung und Zerstörung. Schliesslich das Ergebnis mit den Stakeholdern validieren, dann mit dem ursprünglichen Anwendungsfall abgleichen.

Eine erste Übertreibung ist, zu viel zu modellieren: einen vollständigen Satz Diagramme für jeden Anwendungsfall eines Systems zu bauen, kostet viel und bringt nichts, wo die Reihenfolge der Austausche kein Risiko birgt. Man modelliert die Szenarien, in denen die Abfolge selbst die Schwierigkeit ist, ein Authentifizierungs-Handshake, eine Transaktion, die mehrere Systeme durchquert, ein Rückruffluss. Die zweite ist, alles in ein einziges Diagramm zu häufen, jeden Alternativpfad einbegriffen, bis zu einem unlesbaren Gewirr von Fragmenten; ein Szenario pro Diagramm, die bedeutsamen Alternativen in ihrem eigenen alt oder ihrem eigenen Diagramm. Ein tieferer Fallstrick bleibt: vom Diagramm zu erwarten, dass es zeigt, wie die Teilnehmer verbunden sind. Es zeigt die Interaktion über die Zeit; die Beziehungen leben in einem Klassen- oder Datenmodell, die Entwicklung eines Objekts über alle seine Szenarien hinweg in der Zustandsmodellierung und die Bewegung der Daten in einem Datenflussdiagramm.

KI-Überlegungen

Zwei Einsätze halten fest. Der erste ist der Entwurf aus einer Erzählung: Ein Sprachmodell überführt die geschriebene Beschreibung eines Anwendungsfalls, der Kunde übermittelt eine Zahlung, das System authentifiziert, dann belastet es, in eine erste Teilnehmerliste und eine erste Nachrichtenfolge. Die natürliche Schnittstelle ist Text-zu-Diagramm, das Modell schreibt PlantUML oder Mermaid, eine Engine rendert es, und das Diff lässt sich prüfen. Der zweite ist das Reverse Engineering: ein Kandidatendiagramm aus Ausführungsprotokollen, einem verteilten Trace oder einem Codepfad erzeugen, um zu dokumentieren, was das System tatsächlich tut, statt was spezifiziert war. Hinzu kommen die Konsistenzarbeiten: einen Teilnehmer über einen ganzen Satz Diagramme umbenennen, prüfen, dass jeder synchrone Aufruf seine Rückgabe hat, Fragmente ohne Bedingung melden.

Was sich nicht delegieren lässt, hängt an Bedeutung und Risiko. Ob ein Aufruf synchron oder asynchron sein soll, ist eine Entwurfsentscheidung mit realen Folgen, Blockade, Zeitüberschreitungen, Kopplung; das Modell rät nach der Formulierung und irrt mit Selbstsicherheit. Die Wahl des Pfeils gehört dem Analysten. Dann die Datensensibilität: Ein Diagramm einer Authentifizierung oder Zahlung kodiert, wo Geheimnisse, Token und persönliche Daten zirkulieren; einem externen Modell echte Protokolle zu übergeben, kann genau das offenlegen, und das Modell wird nicht melden, dass ein Schritt eine Kennung preisgibt. Der Analyst beurteilt, was modelliert werden darf und wo. Schliesslich die Granularität: Ein aus Traces rekonstruiertes Diagramm ist erschöpfend und unlesbar, ein Validierungsdiagramm mit den Stakeholdern ist mit Absicht grob; zu wissen, für welchen Leser man zeichnet, ist keine Frage, die das Werkzeug zu stellen weiss.

Beispiele

Ein Kunde begleicht eine Rechnung von CHF 1'250.00 in seinem E-Banking; die Zahlung verlangt eine starke Kundenauthentifizierung, bevor das Kernbankensystem sie ausführt. Vier Teilnehmer genügen, um das Szenario zu tragen: der Kunde, das E-Banking-Frontend, das Kernbankensystem und der Authentifizierungsdienst.

Was das Diagramm sichtbar macht, ist die Reihenfolge und der synchrone oder asynchrone Charakter des Austauschs, auf einer Seite zusammengeführt. Die Sache, die ein Leser ohne die Zeichnung übersähe, hängt an einer einzigen Nachricht: die Herausforderung an den Kunden, die Push-Benachrichtigung oder der SMS-Code, ist asynchron. Das System blockiert nicht den ganzen Fluss, während es auf diesem Ausser-Band-Kanal darauf wartet, während die Aufrufe zwischen den Systemen der Bank synchron und blockierend sind. Das alt-Fragment trägt die Verzweigung des Ausgangs: bei geglückter Authentifizierung kommt das validierte Token zurück und die Zahlung wird bis zum Kunden bestätigt; bei Fehlschlag kommt die Ablehnung denselben Pfad zurück und löst dabei jeden blockierenden Aufruf auf.

Visualisierungen

Die Geometrie ist der Inhalt. Der Typ einer Nachricht liest sich in der Form ihres Pfeils: ausgefüllter Kopf auf durchgezogener Linie für den synchronen Aufruf, der blockiert, offener Kopf auf durchgezogener Linie für den asynchronen Versand, offener Kopf auf gestrichelter Linie für die Rückgabe. Die gestrichelte Lebenslinie markiert die Existenz über die Zeit, der Ausführungsbalken den Zeitraum der Aktivität, und der alt-Rahmen mit seinen Bedingungen teilt die Ausgänge auf. Diese Unterscheidungen leben in der Linie und der Position; die Abbildung muss daher eine Zeichnung sein, in der jede Form der Notation treu bleibt.

Kosten

Werkzeuge

Ein Whiteboard genügt für einen ersten Entwurf: vier Teilnehmer und ein Dutzend Nachrichten passen auf ein Blatt. Die allgemeinen Zeichenwerkzeuge, diagrams.net, Lucidchart oder Visio, tragen brauchbare Sequenzschablonen, mit Lebenslinien und Pfeilköpfen zur Hand, aber ihr Beitrag endet bei der Zeichnung. Text-zu-Diagramm, PlantUML oder Mermaid, beschreibt die Abfolge in ein paar Zeilen Text, die eine Engine ins Bild setzt: Das Diagramm wird in einem Diff geprüft und wie Code versioniert, was passt, wenn es sich über die Lieferungen hinweg entwickelt. Die UML-Modellierungswerkbänke, Enterprise Architect oder Visual Paradigm, halten das Diagramm als ein Objekt des Modells, zurückverfolgt auf den Anwendungsfall, den es verfeinert, und das Werkzeug meldet einen synchronen Aufruf ohne Rückgabe oder ein Fragment ohne Bedingung.

Quellen

• IIBA, A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3, §10.42 Sequence Diagrams: was ein Sequenzdiagramm modelliert, die Verfeinerung eines Anwendungsfalls in ein oder mehrere Diagramme, die Stärken und Grenzen und die Liste der Elemente auf konzeptueller Ebene.
• OMG, Unified Modeling Language (UML), Version 2.5.1, die Klausel Interactions: die normative Notation, gestrichelte Lebenslinie, Ausführungsspezifikation, synchrone Nachricht mit ausgefülltem Kopf, asynchron mit offenem Kopf, gestrichelte Rückgabe und die kombinierten Fragmente alt, opt, loop und par mit ihren Bedingungen.