UML-Sequenzdiagramme

Ein Sequenzdiagramm beantwortet genau eine Frage: was passiert, in welcher Reihenfolge, zwischen wem. Es ist das Diagramm, das man zeichnet, wenn zwei Leute uneins sind, welcher Service welchen aufruft, oder wenn ein Ablauf vier Systeme durchquert und niemand den ganzen Pfad im Kopf hat.

Das Layout erledigt die ganze Arbeit. Die Teilnehmer stehen oben nebeneinander. Die Zeit läuft nach unten - nicht von links nach rechts und nicht maßstäblich. Eine Nachricht weiter unten passiert nach einer weiter oben, und das ist die vollständige Leseregel.

Drei Möbelstücke, und alles andere ist eine Variation davon.

Eine Lebenslinie ist der Kopf oben plus die gestrichelte Senkrechte, die von ihm herabläuft. Der Kopf benennt den Teilnehmer. Das kann ein Klassenname sein, ein Objekt (: Checkout), ein als Strichmännchen gezeichneter Akteur oder eine Rolle mit einem Stereotyp wie «boundary» oder «control». Was immer Sie wählen, bleiben Sie im ganzen Diagramm konsistent.

Ein Aktivierungsbalken - manchmal Ausführungsvorkommen genannt - ist das schmale Rechteck auf der Lebenslinie. Es markiert die Spanne, in der dieser Teilnehmer etwas tut. Verschachtelte Balken heißen, dass ein Teilnehmer sich selbst aufgerufen hat. Aktivierungen sind in UML optional, und sie lohnen sich: sie machen sichtbar, dass Checkout noch wartet, während das Gateway arbeitet.

Eine Nachricht ist der waagerechte Pfeil. Sein Stil sagt, welche Art von Aufruf es ist, und das ist der Teil, den man sich merken sollte.

Die Unterscheidung gefüllte gegen offene Pfeilspitze ist die mit echtem Gewicht. Sie ist der Unterschied zwischen „der Aufrufer ist jetzt blockiert“ und „der Aufrufer ist weitergegangen“, und sie ist das Nützlichste, was ein Sequenzdiagramm einem Leser über ein verteiltes System sagt.

Echte Abläufe haben Bedingungen und Wiederholungen. UML behandelt beides mit einem kombinierten Fragment: einem Kasten um eine Folge von Nachrichten, mit einem Operator im Etikett oben links.

• alt - Alternativen. Durch eine gestrichelte Linie in Abschnitte geteilt, jeder mit einer Wächterbedingung in eckigen Klammern. Genau einer läuft. Das ist ein If/Else.
• opt - optional. Ein Abschnitt mit Wächter; er läuft oder nicht. Das ist ein If ohne Else.
• loop - Wiederholung. Der Wächter gibt Bedingung oder Grenzen an, etwa loop [1..*] oder loop [solange weitere Seiten].
• par - parallel. Die Abschnitte laufen nebenläufig, ohne garantierte Reihenfolge.
• ref - ein Verweis auf eine Interaktion, die auf einem anderen Diagramm definiert ist. So verhindert man, dass ein Sequenzdiagramm auf drei Seiten anwächst.
• critical - ein Bereich, der mit nichts anderem verschränkt werden darf.

Alles oben sitzt in einem Kasten, den die meisten Diagramme zeichnen und wenige Leser bemerken: dem Interaktionsrahmen, einem Rechteck um das ganze Diagramm mit einem Etikett oben links, auf dem sd und der Name der Interaktion steht. Es sieht nach Dekoration aus und ist keine - es gibt der Interaktion einen Namen, und genau der macht ref möglich. Ohne ihn lässt sich ein langer Ablauf nicht zerschneiden, und dann muss jeder Ablauf auf eine Seite passen.

Die Fragmentliste im vorigen Abschnitt ist der Arbeitssatz, nicht der ganze. Vier weitere Operatoren existieren, und drei verdienen gelegentlich ihren Platz: break bricht den Rest des umgebenden Fragments ab, wenn sein Wächter gilt - die natürliche Form eines frühen Fehlerrücksprungs; strict erzwingt die Reihenfolge seiner Abschnitte, wo einfaches seq sie offen lässt; neg markiert eine Interaktion, die nicht passieren darf, also einen negativen Test als Bild. assert, ignore und consider gehören zur formalen Spezifikation und können getrost übersprungen werden, bis etwas sie erzwingt.

Das Wertvollste an einem Sequenzdiagramm ist nicht die Dokumentation des Erfolgspfads. Es ist, dass die Fehler zählbar werden, sobald der Erfolgspfad auf dem Papier steht - und ein Ablauf über vier Systeme hat weit mehr davon, als irgendwer aus dem Gedächtnis schätzt.

Gehen Sie das Diagramm nach unten durch und stellen Sie zu jeder Nachricht drei Fragen, in dieser Reihenfolge. Die Antworten sind Ihre Erweiterungspfade, und jede ist entweder ein Fragment, das Sie zeichnen sollten, oder eine Entscheidung, die jemand treffen muss.

1. Was, wenn keine Antwort kommt? Jede synchrone Nachricht ist eine Stelle, an der der Aufrufer ewig blockieren kann. Irgendwo gibt es einen Timeout-Wert; kennt ihn niemand im Raum, ist das der Befund. Zeichnen Sie es als alt mit einem [timeout]-Wächter, und die Zahl landet auf dem Diagramm, wo man über sie streiten kann.
2. Was, wenn die Antwort ein Fehler ist? Verschieden von „keine Antwort“ und von erschreckend viel Produktionscode gleich behandelt. Eine abgelehnte Autorisierung und ein toter Acquirer brauchen unterschiedliche Behandlung, und auf dem Diagramm wird dieser Unterschied sichtbar.
3. Was, wenn das zweimal zugestellt wird? Fragen Sie das bei jeder asynchronen Nachricht, denn Queues stellen erneut zu und Clients wiederholen. Lautet die Antwort „der Kunde wird zweimal belastet“, haben Sie die Idempotenz-Anforderung gefunden, die nicht im Ticket stand.

Lesen Sie das Diagramm dann noch einmal rückwärts, wegen der Frage, die der Vorwärtslauf nie erwischt: was ist bereits passiert und muss jetzt rückgängig gemacht werden? Ein Fehler bei der vierten Nachricht lässt die Wirkungen der ersten drei bestehen. Das ist die Kompensationslogik, und ein Sequenzdiagramm ist der billigste Ort der Welt, um festzustellen, dass man welche braucht.

Ein Sequenzdiagramm ist außerdem das wirksamste UML-Artefakt, um einen Entwurf vor dem Bau zu prüfen, weil es die unbequemen Fragen ans Licht zwingt. Was passiert, wenn das Gateway in einen Timeout läuft? Wer wiederholt? Ist dieser Aufruf blockierend? Das Diagramm lässt sich nicht zeichnen, ohne sie zu beantworten.

1. Jeder Pfeil durchgezogen und gefüllt. Sieht alles synchron aus, hat das Diagramm seine nützlichste Unterscheidung weggeworfen. Offene Spitzen für Fire-and-forget.
2. Antwortpfeile für alles. Die Antwort auf einen synchronen Aufruf ist oft impliziert und kann entfallen. Zeichnen Sie sie, wenn der Rückgabewert zählt.
3. Abstraktionsebenen mischen. Eine Lebenslinie für eine ganze Zahlungsplattform neben einer für eine einzelne Hilfsklasse. Wählen Sie eine Flughöhe.
4. Kein Fehlerpfad. Der Erfolgspfad allein ist die uninteressantere Hälfte. Ein alt mit dem Timeout-Zweig macht das Diagramm prüfenswert.
5. Zwanzig Lebenslinien. Ab etwa sieben passt das Diagramm nicht mehr auf einen Bildschirm und wird gescrollt statt gelesen. Teilen Sie es und nutzen Sie ref.