Zustandsdiagramm-Beispiele

Hat eine Tabelle in Ihrer Datenbank eine status-Spalte, steckt dieses Diagramm bereits implizit im Code - es ist nur über ein Dutzend Wächterklauseln verteilt, statt einmal gezeichnet. Es explizit zu machen ist die billigste Fehlersuche, die ein Zustandsautomat bietet.

Lesen Sie die Übergänge statt der Kästen. Jeder trägt den Auslöser, der ihn verursacht - checkout, pay, dispatch, deliver - und einer trägt hinter einem Schrägstrich eine Wirkung: dispatch / print label. Diese Beschriftungen sind der Inhalt. Ein Diagramm aus sechs abgerundeten Kästen mit unbeschrifteten Pfeilen sagt nur, dass sich Dinge ändern, und das wusste jeder schon.

Die zwei Endzustände sind Absicht. Storniert und Zugestellt sind beide endgültig und nicht dasselbe Ergebnis, und für beide eine umringte Scheibe zu zeichnen würde sagen, die Bestellung sei zu Ende, ohne zu sagen, wie. Nichts in UML begrenzt Sie auf einen.

Echte Abläufe laufen selten in eine Richtung. Etwas wird abgelehnt, geht zurück und kommt erneut - und im Rückwärtsübergang wohnen meist die interessanten Regeln.

Der Übergang revise von Abgelehnt nach Entwurfist es, was daraus einen Zustandsautomaten statt einer Checkliste macht. Er sagt, dass ein abgelehnter Artikel nicht fertig ist - er tritt wieder in denselben Zyklus ein, und jeder Zähler wie „zweimal abgelehnt heißt eskalieren“ hängt an diesem Pfeil und nicht an einem Zustand.

Beachten Sie, dass Abgelehnt einen Ausgang hat und Veröffentlicht nicht. Ein Zustand ohne ausgehenden Übergang und ohne Endzustand dahinter behauptet, das Objekt bleibe für immer dort - gelegentlich wahr und häufiger eine Auslassung. Jeden Blattzustand daraufhin zu prüfen ist ein Zwei-Minuten-Review, das echte Lücken findet.

Die Auslösernamen sind Ereignisse aus dem Vokabular der Domäne - submit, approve, reject, revise - keine Methodennamen. Das hält das Diagramm für die Redakteure lesbar, denen der Prozess gehört, und das ist das Publikum, das Ihnen sagen kann, dass es falsch ist.

Die häufigste Verwirrung beim Wechsel von Aktivitätsdiagrammen zu Zustandsautomaten ist, was zwei Pfeile aus einem Kasten bedeuten.

Das sind zwei Auslöser, nicht zwei Zweige einer Entscheidung. Die Bestellung sitzt unbegrenzt in Zahlung ausstehend; wohin sie geht, entscheidet das Ereignis, das zuerst eintrifft - pay oder das Zeitereignis timeout(72h). Nichts muss erschöpfend sein und es gibt kein [else], weil Warten ein legitimer Ausgang ist.

Das ist das Gegenteil eines Aktivitätsdiagramms, wo ein Token, das eine Entscheidung ohne freigeschalteten Wächter erreicht, ein stehengebliebener Prozess ist. Gleich aussehende Geometrie, entgegengesetzte Semantik - weshalb die Wahl zwischen beiden Notationen bewusst statt aus Gewohnheit getroffen werden sollte.

Ein Zustandsautomat ist billig zu zeichnen und teuer zu pflegen, also lohnt sich die Frage, ob das Objekt überhaupt einen Lebenszyklus hat, vor dem ersten Kasten.

Spannt der Prozess mehrere Beteiligte auf statt des Lebens eines Objekts, wollen Sie ein Aktivitätsdiagramm oder, für ein Fachpublikum, BPMN. Der Test ist einfach: können Sie das eine Ding nicht benennen, dessen Zustände das sind, ist es kein Zustandsautomat.