Sequenz- vs Kommunikationsdiagramm

Beide Diagramme unten beschreiben denselben Checkout: eine Kundin gibt eine Bestellung auf, der Controller reserviert Bestand, belastet eine Karte, speichert die Bestellung und antwortet. Am System unterscheidet sich nichts. Nur die Achse, auf die die Notation ihren Platz verwendet.

Lesen Sie danach die Titelabbildung noch einmal. Das Kommunikationsdiagramm macht offensichtlich, was das Sequenzdiagramm vergräbt: jede Nachricht läuft über OrderController. Vier Links gehen von einem Knoten aus und keiner verbindet die anderen untereinander - das ist die Form des Entwurfs, nicht die Form des Laufs. Auf dem Sequenzdiagramm ist diese Tatsache über sieben Zeilen verteilt und man muss sie suchen.

Und die Umkehrung gilt genauso. Auf dem Sequenzdiagramm sehen Sie auf einen Blick, dass die Karte nach der Bestandsreservierung belastet wird und dass die Reservierungsantwort zurückkommt, bevor die Belastung hinausgeht. Auf dem Kommunikationsdiagramm ist diese Reihenfolge der Unterschied zwischen den Ziffern 2 und 3.

Beide Notationen sind in UML über derselben zugrunde liegenden Interaktion definiert, es ist also eine Darstellungs- und keine Modellierungsentscheidung. Was aus dieser Entscheidung folgt, ist konsistent genug, um es zu tabellieren.

Die Entscheidung fällt leichter, wenn Sie den Satz aufschreiben, den das Diagramm jemanden sagen lassen soll. Steht eine Reihenfolge darin, wollen Sie Lebenslinien. Steht eine Form darin, wollen Sie Links.

In der Praxis zeichnen die meisten Teams Sequenzdiagramme und lesen gelegentlich ein Kommunikationsdiagramm, was ein vernünftiges Gleichgewicht ist: Reihenfolge ist meist das, was Leute erklären wollen. Der eine Ort, an dem das Kommunikationsdiagramm sich klar bezahlt macht, ist ein Entwurfsreview über Kopplung, wo vier auf einen Knoten zulaufende Links das Argument schneller machen als jede Liste von Aufrufstellen.