Exemples de diagrammes d'états-transitions

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.

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.

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.

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.

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.