UML-Sequenzdiagramm-Beispiele

Lesen Sie das Diagramm oben als zwei Geschichten mit gemeinsamem Anfang. Alles oberhalb des alt-Rahmens geschieht so oder so; darin läuft genau ein Abschnitt, und die Wächter in eckigen Klammern sagen welcher. Das ist das, was ein Sequenzdiagramm kann und eine nummerierte Schrittliste nicht, und deshalb ist dieser Ablauf das übliche erste Beispiel.

Das nachahmenswerte Detail steckt im Fehlerzweig. Er gibt nicht einfach einen Fehler zurück: er feuert zuerst record(failure)an das Versuchsprotokoll, mit offener Pfeilspitze gezeichnet, weil nichts darauf wartet. Ein Diagramm, dessen Fehlerpfad ein einzelner mit "Fehler" beschrifteter Pfeil ist, hat über den Fehlerpfad nicht nachgedacht - und die Drosselungsanforderung, die alle drei Wochen später entdecken, wohnt genau in diesem Zweig.

Zwei Dinge hier stehen auf keinem ersten Sequenzdiagramm. Der Wächter des loop-Fragments nennt sowohl eine Schranke als auch eine Bedingung - [3 times, while transient] -, denn eine Schleife ohne Schranke ist ein Diagramm, das einen Ausfall verspricht, und eine ohne Bedingung sagt nicht, was sie vorzeitig beendet.

Das andere ist backoff(), eine Nachricht von Checkout an sich selbst, als Pfeil gezeichnet, der eine Lebenslinie verlässt und zu ihr zurückkehrt. Selbstaufrufe lohnt sich genau dann zu zeichnen, wenn die Verzögerung oder die Entscheidung Teil der Geschichte ist - hier ist sie der ganze Grund, warum der zweite Versuch gelingt - und wegzulassen, wenn sie gewöhnliche interne Arbeit sind.

Beachten Sie auch, was nicht da ist: keine gestrichelte Antwort nach markPaid(orderId). Der Bestellspeicher antwortet natürlich, aber die Antwort trägt nichts, worüber dieser Ablauf nachdenkt, und jede Antwort zu zeichnen ist der Weg, auf dem aus einem Diagramm mit sechs interessanten Nachrichten eines mit zwölf wird.

Das ist das Beispiel, das fast niemand zeichnet, und das, welches sich am meisten lohnt. Jeder Pfeil ist asynchron - durchgezogene Linie, offene Spitze - und es gibt nicht einen einzigen gestrichelten Rücklauf. Der Bestelldienst publiziert und macht weiter; Lager und E-Mail-Dienst empfangen das Ereignis jeweils, und nichts auf diesem Diagramm sagt, wer von beiden zuerst fertig ist, weil auch nichts im System es sagt.

Diesen Ablauf mit gefüllten Pfeilspitzen und Antworten zu zeichnen wäre ein anderes System: eines, in dem das Publizieren blockiert, bis beide Konsumenten gelaufen sind - genau die Eigenschaft, die ein Broker beseitigen soll. Die Notation unterscheidet sie, und die Unterscheidung ist hier mehr wert als irgendwo sonst in UML.

Für die Methode statt der Beispiele lesen Sie wie man ein Sequenzdiagramm zeichnet; für die volle Notation den Artikel zum Sequenzdiagramm.