State Machine Diagram

The UML picture of one object over its lifetime: the states it can be in, the events that move it, and the guards that decide whether a move is allowed.

Overview

A state machine diagram describes one object, not a process or a conversation. It lists the states the object can be in, the events that move it from one state to another, and the conditions under which each move is allowed. An order is Created, then Paid, then Shipped, then Delivered; it cannot go from Created to Shipped, and it can be Canceled only before it ships. Those sentences are a state machine, and the diagram is the exact way to write them down.

The notation is in clause 14 of UML 2.5.1. A state is a rectangle with rounded corners. The initial pseudostate is a small solid circle; the final state is a small solid circle inside a larger circle. A transition is an arrow labeled trigger [guard] / effect: the event that fires it, a condition in square brackets that must be true, and an action that runs during the move. A state may also name behavior that runs on entry, on exit, or while it is active (entry, exit and do).

In LLD interviews, state machines are the tool for anything with a lifecycle: orders, payments, elevators, vending machines, connections, documents under review. Drawing the machine first makes the invalid transitions explicit, and those are exactly the bugs an interviewer will probe for.

The parts

  • State — rounded rectangle with the name — the object's condition between events
  • Initial pseudostate — small solid circle — where the machine starts
  • Final state — solid circle inside a circle — the object's life is over
  • Transition — arrow labeled trigger [guard] / effect — the event, the condition, the action
  • Entry, exit, do — lines inside the state: entry / action, exit / action, do / activity — behavior tied to the state rather than to a transition
  • Composite state — a state containing its own smaller machine — a group of states that share transitions
  • Choice — diamond — branch on a condition evaluated during the transition
  • Fork and join — short heavy bars — enter or leave parallel regions together
  • History — small circle with H (shallow) or H* (deep) — re-enter a composite state where you left it
  • Terminate — a cross — the machine stops without a final state

Reading a transition label

The label is the rule. All three parts are optional, but the guard and the effect have fixed places.

  • trigger — an event name, or after(time) / at(time) — pay, after(15 min) — what fires the transition
  • guard — [condition] — [balance >= amount] — must be true, or the transition does not fire
  • effect — / action — / charge card — runs during the move, before the new state's entry behavior

Entry, exit and do behavior

Behavior attached to a state runs no matter which transition brought you there. That is the point: if every path into Canceled must send an email, put it in the state's entry behavior rather than on every transition that leads into it.

  • a transition (effect) — only for that event from that state — / charge card on pay
  • state entry — every time the state is entered, after the transition's effect — entry / email cancellation notice
  • state exit — every time the state is left, before the next transition's effect — exit / release the reserved courier
  • do — while the state is active; aborted if the state is left — do / poll for courier position

UML fixes the order: the transition's effect runs first, then the target state's entry behavior, and the do activity starts after the entry behavior finishes. If the state is left before the do activity ends, the do activity is aborted before the exit behavior runs.

From the diagram to code

A drawn machine becomes code in one of three shapes. All three make the invalid transition an explicit error instead of a silent bug.

  • Transition table — a dict from (state, event) to the next state — many states, simple effects, easy to test
  • Enum plus a switch — one method with a case per state — small machines in one class
  • State pattern — one class per state; the context delegates events to the current state object — states with different behavior and effects

State, activity and sequence: which to draw

  • the states one object can be in and what moves it — state machine diagram
  • the steps and decisions of a process, with parallel work — activity diagram
  • which objects exchange which messages, in order — sequence diagram

What you will be able to do

  • Draw a state machine with correct symbols for start, states, transitions, guards, effects and end.
  • Read and write a transition label as trigger [guard] / effect.
  • Decide when behavior belongs on a transition and when it belongs to a state's entry or exit.
  • Turn a drawn machine into code that rejects invalid transitions, and test every arrow.

Interview questions

  • What are composite states, and when do you use them?
  • Design the state machine for an order, including cancellation and refunds.
  • How do you implement a state machine in code?
  • How do timeouts and other time-based events fit a state machine?
  • How does a state machine diagram help with testing?

Sign up free to read the full topic

More Low-Level Design topics

Start free on Cariara · Coding problems · System design studio