UML-Zustandsdiagramme

Ein Zustandsdiagramm beschreibt das Leben einer Sache. Keinen Prozess, keine Interaktion - ein Objekt oder eine Komponente und die Zustände, die es von der Entstehung bis zur Entsorgung durchläuft.

Seine Kraft liegt im Negativraum. Das Diagramm oben zeichnet sechs Übergänge. Alles andere ist damit verboten: eine Zahlung in Refunded kann nicht zurück nach Captured, eine in Failed kann nicht eingezogen werden, und eine in Pending kann nicht erstattet werden. In einem Klassendiagramm leben diese Einschränkungen in Fliesstext oder in niemandes Kopf. Hier sind sie das Bild.

Verhalten kann an einem Übergang oder an einem Zustand hängen, und die richtige Wahl beseitigt eine Menge Doppelung.

• Effekt an einem Übergang - nach dem Schrägstrich geschrieben. Läuft einmal, bei genau diesem Wechsel. Nehmen Sie ihn, wenn das Verhalten zu diesem Pfad gehört.
• entry / … - läuft bei jedem Eintritt in den Zustand, über jeden Übergang. Müssen drei Pfeile nach Captured alle einen Buchungssatz schreiben, ist das eine entry-Aktion, nicht drei Effekte.
• exit / … - läuft bei jedem Verlassen des Zustands, über jeden Übergang.
• do / … - läuft durchgehend, solange der Zustand aktiv ist, und wird beim Verlassen abgebrochen. Das ist die für lang laufende Arbeit.

Faustregel: geht es beim Verhalten um das Sein im Zustand, nehmen Sie entry/do/exit. Geht es um die bestimmte Reise zwischen zwei Zuständen, setzen Sie es an den Übergang.

Echte Lebenszyklen entwickeln einen häufigen Fall: mehrere Zustände, die auf ein Ereignis identisch reagieren. Eine Zahlung in Pending, Authorized oder Captured kann jeweils storniert werden, und drei getrennte cancel-Pfeile nach Cancelled zu zeichnen ist Rauschen.

Ein zusammengesetzter Zustand löst das. Fassen Sie die drei in einem umschliessenden Zustand namens Active zusammen und zeichnen Sie einen cancel-Übergang aus Active heraus. Er gilt für den jeweils aktuellen Unterzustand. Aus drei Pfeilen wird einer, und ein vierter Unterzustand später kostet nichts.

Ein Historien-Pseudozustand - ein eingekreistes H - regelt die Wiederaufnahme. Ohne ihn beginnt der Wiedereintritt beim initialen Unterzustand. Mit ihm kehrt die Maschine in den Unterzustand zurück, in dem sie beim Verlassen war. Flache Historie (H) merkt sich eine Ebene, tiefe Historie (H*) die ganze Verschachtelung. Das wollen Sie für alles Unterbrechbare.

Ein Zustandsdiagramm bildet sich fast direkt auf Code ab, was für UML ungewöhnlich ist. Die Zustände werden ein Enum, die Übergänge eine Tabelle und die Wächter die Bedingungen an jedem Eintrag. Es zuerst zu zeichnen und daraus zu implementieren ist eine der wenigen Stellen, an denen Modellierung schlicht Zeit spart, statt nur zu dokumentieren.

1. Zustände als Tätigkeiten benannt. Authorizing legt laufende Arbeit nahe; wartet das Objekt dort, benennen Sie die Bedingung - Authorized, Awaiting capture.
2. Einen Prozess modelliert, kein Objekt.Sind Ihre „Zustände“ Schritte, die verschiedene Leute ausführen, wollen Sie ein Aktivitätsdiagramm.
3. Übergänge ohne Auslöser. Zulässig - er feuert, wenn die do-Aktivität des Zustands endet - aber meist ein Zeichen, dass ein Ereignis fehlt.
4. Kein Endzustand und keine Erklärung. Entweder lebt das Objekt tatsächlich ewig, oder ein Endzustand wurde vergessen. Beides kommt vor; nur eines ist beabsichtigt.
5. Denselben Übergang aus jedem Zustand wiederholt. Genau dafür gibt es zusammengesetzte Zustände.