skip to content

State Machine Diagrams

3 roadmaps5 questions

States, transitions, events, and guards, extended with entry and exit actions, composite states, history pseudo-states, and orthogonal regions. Interviewers reach for it whenever a domain object has a lifecycle worth modelling explicitly.

on this pageshow

explore

questions

5

In a UML state machine diagram, what do a state, an event and a transition each represent?

level: juniorimportance: must knowfreq 78%

answer

  1. A lifecycle drawn as boxes and arrows
  2. Conditions have duration, occurrences do not
  3. The arrow label has three parts
  4. Event, bracketed guard, slash effect
  5. Guards are checked only after an event

basics

~20 s

A state is a named condition the object waits in over time. An event is a discrete occurrence the object perceives. A transition is the arc that fires when that event arrives and moves the object from one state to another.

solid answer

~50 s

A **state** is a named condition in which a modelled object waits; it has duration, and while in it the object accepts some events and ignores the rest. An **event** is a discrete occurrence the object can perceive — a signal, a call on the object, a watched condition becoming true, or a timer elapsing. A **transition** is the directed arc that fires when its event arrives and moves the object from a source state to a target state; taking it is instantaneous, so the object is never *on* an arc. The full label reads `event [guard] / effect`. The **guard** is a boolean checked once, after the event arrives, that decides whether the arc may fire — it never fires anything by itself. A filled dot, the initial pseudo-state, marks where a new object starts.

code

pseudocode · 7 lines
pseudocode
Booking lifecycle (states in CAPS, transitions as arrows)

  (initial)  -> DRAFT
  DRAFT      -> SUBMITTED  on submit
  SUBMITTED  -> CONFIRMED  on carrierAccepted [capacityAvailable] / reserveSlot
  SUBMITTED  -> DRAFT      on carrierRejected / recordReason
  CONFIRMED  -> (final)    on shipmentDelivered

go deeper

for a junior

Be ready to name the three elements and sketch a five-state lifecycle on a whiteboard. Know that a state has duration and that a transition is taken instantly once its event arrives.

for a middle

Explain the transition label part by part — trigger, guard in square brackets, effect after the slash — and say exactly what happens when the event arrives while the guard is false.

for a senior

An interviewer at this level expects you to catch an ambiguous diagram: two arcs on the same event with overlapping guards, or boxes named after data values instead of behavioural conditions.

for a principal

Own the question of what the model is for. Say whether the diagram is a throwaway design aid or the reference the transition rules are derived from, and who is accountable for keeping it honest.

## What a state machine diagram models A UML state machine diagram describes the life of a **single object** — one booking, one document, one session — as a finite set of named conditions and the legal moves between them. It is a behavioural diagram: it answers *what can happen to this thing next, and what does it do when that happens*, not *what does this thing contain*. Three elements carry nearly all of the meaning. **A state** is a named condition in which the object waits. It has duration: the object may sit in `Awaiting Confirmation` for minutes or for days, and while it sits there it accepts some events and ignores the rest. A state is a *behavioural* condition, not a data value. `Cancelled` is a state because the object behaves differently there; `Weight Over 500kg` is a predicate about data and belongs in a guard, not in a box on the diagram. **An event** is a discrete occurrence the object can perceive. UML recognises four kinds: - a **signal event** — an asynchronous message arrives; - a **call event** — an operation on the object is invoked; - a **change event** — a watched condition becomes true, written `when(...)`; - a **time event** — a duration elapses or an instant is reached, written `after(...)` or `at(...)`. **A transition** is the directed arc from a source state to a target state that is taken in response to an event. In the model it is instantaneous: the object is in the source state or in the target state, never resting on the arc between them. ## Reading a transition label The full label has three parts, and only the arc itself is mandatory. | Part | Written as | Meaning | If omitted | | --- | --- | --- | --- | | Trigger | the event name | the occurrence that may fire the arc | the arc is a **completion transition** and fires when the source state's internal activity finishes | | Guard | `[condition]` in square brackets | a boolean checked once, after the trigger arrives | the arc fires whenever the trigger arrives | | Effect | `/ behaviour` after a slash | behaviour that runs while the arc is taken | nothing extra runs | So `carrierAccepted [capacityAvailable] / reserveSlot` reads: *when the carrier-accepted event arrives, and capacity is available, take this arc and reserve the slot.* The distinction interviewers press hardest is **guard versus event**. An event is something that happens; a guard is a question asked about the world at the moment it happens. A guard fires nothing on its own — the machine does not poll it. If `capacityAvailable` becomes true an hour after the carrier accepted, nothing moves: the event has been and gone. To make the machine react to the condition itself you need a change event, which *is* a trigger. ## Rules that keep the diagram unambiguous 1. **Run to completion.** One event is processed fully — exit behaviour, effect, entry behaviour — before the next is dispatched. That is what lets a reader follow the diagram without reasoning about interleaving. 2. **Determinism.** If two arcs leave the same state on the same event, their guards must be mutually exclusive; otherwise the diagram does not say what happens. 3. **Events are consumed.** An occurrence that no enabled arc handles is discarded, not queued for later. 4. **One starting point per region.** A filled dot — the **initial pseudo-state** — marks where a newly created object begins. Its outgoing arc may carry an effect but never a trigger and never a guard. A pseudo-state is transient: the object never rests there. 5. **Ending is optional.** A final state, drawn as a bullseye, means this object's life is over. A machine that models something perpetual may have none. ## Where candidates go wrong - Naming boxes after data rather than behaviour, which produces thirty states and no rules. - Treating the guard as the trigger, and so expecting a transition to fire the moment its condition becomes true. - Drawing unlabelled arcs by accident. An unlabelled arc is a completion transition with a precise meaning, so an author who meant *and then, later* has written something else. - Confusing these states with the columns a work item moves through on a team's board. A board column is a place people park a task; a state here is a condition of the modelled object that events move it between. ## A small worked lifecycle On a freight-booking portal, a booking sits in `Draft` while a clerk fills it in, moves to `Submitted` on the `submit` event, and reaches `Confirmed` on `carrierAccepted [capacityAvailable] / reserveSlot`. A `carrierRejected` event returns it to `Draft`. Bookings on that portal take a median of nine days to reach `Confirmed`, and the diagram is the only artefact that states plainly that there are exactly two ways out of `Submitted` — which is why an interviewer asks you to draw it rather than describe it.

  • If the event arrives but the transition's guard evaluates to false, what happens?
    Nothing on that arc — it does not fire. The event is consumed and discarded unless another transition out of the same state is enabled by it, or an enclosing state offers one. A guard is evaluated once, at the moment the trigger arrives; the machine does not watch it. A guard that becomes true later moves nothing until the event occurs again.
  • What kinds of occurrence can a UML event be?
    Four kinds. A signal event is an asynchronous message arriving. A call event is an operation being invoked on the object. A change event fires when a watched condition becomes true, written `when(...)`. A time event fires after a duration or at an instant, written `after(...)` or `at(...)`. Change and time events matter because they let the machine react without an external sender.
  • What does an arc leaving a state with no event label mean?
    It is a completion transition: it fires when the source state finishes its internal activity, with no external occurrence needed. If the state has a do activity, that means when the activity ends; if it has none, the arc fires as soon as the entry action completes. It is a precise construct, not a placeholder for *and then, later*.

A turnstile is a state machine: it rests in one condition, and only a specific occurrence — a coin, a push — moves it, and only if the condition written beside the arrow holds at that moment.

saying these in an interview costs you the question

  • Names states after data values rather than behavioural conditions
  • Treats a guard as a trigger that fires the transition on its own
  • Says the object sits on a transition while it is being taken
  • Draws arcs with no label and no idea what fires them
  • Confuses modelled lifecycle states with the columns on a team's board
open as a page

In a UML state machine, when does behaviour belong on a state's entry action rather than on each incoming transition?

level: middleimportance: must knowfreq 58%

basics

~20 s

Behaviour belongs on the entry action whenever every way into the state must run it. A transition effect covers one path only, so work duplicated across several incoming arcs is exactly what an entry action replaces.

open as a page

In a UML state machine diagram, what does a transition out of a composite state do to its active substates?

level: middleimportance: should knowfreq 50%

basics

~20 s

It exits them. Leaving a composite state first exits whichever substate is currently active, running that substate's exit action, then runs the composite's own exit action — so one arc drawn on the boundary covers every substate inside it.

open as a page

When is a UML state machine the right way to model an object's lifecycle instead of a status field?

level: seniorimportance: should knowfreq 44%

basics

~20 s

Model explicitly when an object has several named conditions, when the legal moves between them matter, and when the same rules are being re-checked in scattered places. Two or three values with no ordering rules need no diagram at all.

open as a page

In a UML state machine, what is the difference between a shallow and a deep history pseudo-state?

level: middleimportance: nice to knowfreq 18%

basics

~20 s

Shallow history remembers only which substate of its own region was last active. Deep history remembers the active configuration all the way down through every level of nesting. Both restore that memory when the composite state is re-entered.

open as a page