Zustandsdiagramm-Beispiele
Drei Zustandsautomaten, die Sie sofort übernehmen können - ein Bestell-Lebenszyklus, ein Redaktions-Workflow mit Rücksprung und das Fragment, das zeigt, warum ein wartender Zustand kein hängender ist.
8 Min. LesezeitUML 2.5.116 von 35
01Example 1: an order lifecycle
If a table in your database has a status column, this diagram is already implicit in the codebase - it is just written across a dozen guard clauses instead of drawn once. Making it explicit is the cheapest defect-finding exercise a state machine offers.
Read the transitions rather than the boxes. Each is labelled with the trigger that causes it - checkout, pay, dispatch, deliver - and one carries an effect after a slash: dispatch / print label. Those labels are the content. A diagram of six rounded boxes with unlabelled arrows says only that things change, which everybody already knew.
The two final states are deliberate. Cancelled and delivered are both terminal and they are not the same outcome, and drawing one ringed disc for both would say the order ended without saying how. Nothing in UML limits you to one.
02Example 2: a workflow that loops backwards
Real workflows rarely run in one direction. Something gets rejected, goes back, and comes round again - and the backwards transition is usually where the interesting rules live.
The revise transition from Rejected to Draftis what makes this a state machine rather than a checklist. It says a rejected article is not finished - it re-enters the same cycle, and any counter such as “rejected twice means escalate” hangs off that arrow rather than off a state.
Note that Rejected has an exit and Published does not. A state with no outgoing transition and no final state after it is a claim that the object stays there forever, which is occasionally true and more often an omission. Checking every leaf state for that is a two-minute review that finds real gaps.
The trigger names are events in the domain vocabulary - submit, approve, reject, revise - not method names. That keeps the diagram readable by the editors who own the process, which is the audience that can tell you it is wrong.
03Example 3: two exits that are not a decision
The most common confusion when someone moves from activity diagrams to state machines is what two arrows out of one box mean.
These are two triggers, not two branches of a decision. The order sits in Awaiting payment indefinitely; whichever event arrives first - pay or the time event timeout(72h) - decides where it goes. Nothing has to be exhaustive and there is no [else], because waiting is a legitimate outcome.
That is the opposite of an activity diagram, where a token arriving at a decision with no enabled guard is a stalled process. Same-looking geometry, opposite semantics - which is why the choice between the two notations is worth making on purpose rather than by habit.
04When to draw one at all
A state machine is cheap to draw and expensive to keep, so the question of whether the object has a lifecycle is worth asking before the first box.
Reach for it when
- The object has a status field with more than two values and rules about legal changes.
- Some transitions are forbidden and the prohibition matters - refunds, cancellations, approvals.
- The same object is touched by several services and they disagree about what it can do next.
- Timeouts or expiries change the object without anybody acting on it.
Reach for something else when
- A process crossing several objects and roles - that is an activity diagram.
- A class whose status is derived from other fields rather than stored.
- A workflow engine's own configuration, which is already a state machine written down.
- One diagram covering two objects. Draw one machine per lifecycle.
If the process spans several participants rather than one object's life, you want an activity diagram or, for a business audience, BPMN. The test is simple: if you cannot name the single thing whose states these are, it is not a state machine.
05What to remember
In one line each
- 01The transition labels are the content. Unlabelled arrows between states say nothing.
- 02Several final states are normal - cancelled and delivered are both terminal and not the same.
- 03The missing arrows are where the bugs are. Check every pair you did not draw.
- 04Two arrows out of a state are two triggers, not two branches. Nothing needs an [else].
- 05One state machine per object with a real lifecycle. A process spanning roles is an activity diagram.
06Häufige Fragen
Was ist ein gutes Beispiel für ein Zustandsdiagramm?
Ein Bestell-Lebenszyklus: Warenkorb, aufgegeben, bezahlt, versandt, zugestellt, mit einem Storniert-Zweig ab aufgegeben. Sechs Zustände, ein Auslöser je Übergang und zwei verschiedene Enden decken alles ab, was die Notation üblicherweise leisten muss.
Darf ein Zustandsdiagramm mehrere Endzustände haben?
Ja, und meistens sollte es das. Eine stornierte und eine zugestellte Bestellung sind beide abgeschlossen, aber nicht dasselbe Ergebnis, und beide in eine umringte Scheibe zu führen verwischt den Unterschied. UML begrenzt die Zahl der Endzustände nicht.
Wie modelliert man ein Timeout in einem Zustandsdiagramm?
Als Übergang, dessen Auslöser ein Zeitereignis ist, geschrieben etwa timeout(72h) oder after(72 Stunden). Er verlässt den Zustand, in dem das Objekt wartet, und zeigt auf das Ergebnis des Ablaufs. Ein Wächter ist unnötig - der Zeitablauf selbst ist der Auslöser.
Was passiert, wenn kein Übergang aus einem Zustand aktiviert ist?
Nichts, und das ist richtig. Ein Zustandsautomat wartet in seinem Zustand, bis ein Auslöser eintrifft; ein Zustand ohne aktivierten Übergang ist untätig, nicht defekt. Das ist das Gegenteil eines Aktivitätsdiagramms, wo ein Token ohne Ausgang einen blockierten Prozess bedeutet.
Braucht jede Klasse einen eigenen Zustandsautomaten?
Höchstens einen, und nur für Klassen mit echtem Lebenszyklus. Hat eine Klasse eine Statusspalte mit mehr als zwei Werten und Regeln, welcher Wechsel erlaubt ist, zeichnen Sie ihn. Ist der Status abgeleitet oder wird er nur einmal gesetzt, bringt ein Automat nichts.
Passend dazu