Visual walkthrough — UML — use case, class, sequence, activity, state machine, component diagrams
Step 1 — What is an "object with memory"?
WHAT. Pick one thing that remembers something about itself. A turnstile (the metal gate at a train station) remembers whether it is locked or unlocked. That "memory" is the whole reason a diagram is needed.
WHY. If an object had no memory — if it did the same thing no matter what happened before — we would need no diagram at all; a single rule would describe it. A state machine only earns its keep when the past changes the future. The turnstile is perfect: push it and it sometimes opens, sometimes doesn't — and the difference is entirely its remembered condition.
PICTURE. Two snapshots of the same physical gate, differing only in one hidden fact.
Step 2 — Marking the two resting places
WHAT. Draw the two states as two boxes. Nothing connects them yet — this is just the "vocabulary" of conditions the object can be in.
WHY. Before we describe change, we must nail down what can be true. Every arrow we draw later must start in one of these boxes and end in one of these boxes — there is nowhere else to go. Listing states first stops us inventing illegal in-between conditions ("half-locked"?) that don't really exist.
PICTURE. The two states as labelled boxes, floating, not yet linked.
Step 3 — What makes it move? Events.
WHAT. Ask: what real-world happenings could change the gate? Two: someone drops a coin, someone pushes the gate. Each of these is an event.
WHY. States don't change themselves — a turnstile sitting Locked stays Locked forever unless something arrives from outside. That "something" is the trigger. We must name every trigger, because an unlabelled arrow would leave the reader asking "what made it move?".
PICTURE. The two events shown as incoming triggers hitting the states.
Step 4 — Drawing the first transition, symbol by symbol
WHAT. Connect Locked to Unlocked with an arrow, and label it. When a coin arrives while Locked, the gate should unlock.
WHY. This is the heart of the machine: cause (event) → effect (new state) → side-effect (the physical unlocking). We write all three on one arrow so the reader never has to guess.
PICTURE. One transition, with each piece of its label called out.
Step 5 — The return trip
WHAT. Add the arrow going back: from Unlocked, a push sends us to Locked, re-latching the gate.
WHY. A machine with only one arrow can never return — the gate would unlock once and stay open forever, which is wrong. Every real object must be able to cycle. Adding the reverse transition closes the loop so the gate can be used again and again.
PICTURE. Both boxes, now joined by a two-arrow cycle.
The label push / lock mirrors Step 4: event push, no guard (a push always re-locks after passage), action lock.
Step 6 — The degenerate case: pushing a locked gate
WHAT. What happens if you push while the gate is still Locked? Physically: nothing — you thump a solid bar. We must draw this, or the reader hits a scenario we never showed.
WHY. Every event must be accounted for in every state. We have covered coin-while-Locked (Step 4) and push-while-Unlocked (Step 5). But push-while-Locked and coin-while-Unlocked are still undefined. Leaving them blank silently means "ignore the event" — but silence is a bug magnet. We make the "nothing happens" case explicit with a self-transition: an arrow that leaves a state and returns to the same state.
PICTURE. The self-loop on Locked for a fruitless push.
Step 7 — Where does it all begin? Pseudostates.
WHAT. Add the initial pseudostate — a small filled dot ● — with an arrow into Locked. A brand-new turnstile powers on locked (you must pay first).
WHY. A diagram of only real states doesn't say which one you start in. If we skipped this, a reader could reasonably assume the gate boots up Unlocked — free rides for everyone. The initial dot removes that ambiguity in one stroke. (A final pseudostate ◉ marks where an object's life ends; a turnstile never "dies", so we leave it off — and that omission is itself a decision, not an oversight.)
PICTURE. The initial dot wired to Locked.
Step 8 — A guard in action (the coin-return edge case)
WHAT. Suppose a fancier turnstile rejects worn coins. Now coin while Locked should unlock only if the coin is valid; otherwise it spits the coin back and stays locked. This is where the [guard] from Step 4 finally earns its brackets.
WHY. Sometimes the same event must do different things depending on a condition. Without guards we'd need a new event name for "valid coin" vs "bad coin" — but the sensor only knows "a coin arrived". The guard lets one event branch cleanly on a yes/no test, keeping every arrow honest about when it fires.
PICTURE. Two arrows out of Locked, both triggered by coin, separated by their guards.
The one-picture summary
Everything above, compressed into the finished machine: two states, the initial dot, the coin/push cycle, the self-transition for the futile push, and the guarded coin branch.
Recall Feynman retelling — say it in plain words
Imagine explaining the turnstile to a friend with no jargon.
"The gate only ever feels one of two ways: locked or unlocked — those are the two boxes. It just sits in whichever box it's in; it never changes on its own. The only way it moves is if the world does something to it — a coin drops, or someone shoves it. I draw each of those as an arrow, and I write on the arrow three things: what happened (coin), an optional only-if in square brackets (only if the coin's good), and after a slash what it physically does on the way (release the latch). A coin unlocks it; a push locks it back. If you shove it while it's already locked, I still draw a little loop that goes nowhere — that's me promising I thought about it and the answer is 'nothing happens', not me forgetting. A tiny black dot with an arrow shows it boots up locked, so nobody rides free. And when one event can go two ways — good coin versus bad coin — I split the arrow with two brackets that can never both be true at once. That's the whole trick: rest in boxes, change on labelled arrows, and never leave any event-in-any-state unanswered."
Recall Quick self-test
What are the three parts of a transition label, in order? ::: event [guard] / action — trigger, condition-to-fire, side-effect done while crossing.
Why draw a self-transition instead of leaving the event out? ::: To make "nothing happens" an explicit, deliberate decision rather than an ambiguous omission.
What does the filled dot ● mean, and why is it essential? ::: The initial pseudostate; it names the starting state so the reader never has to guess where the object boots up.
When must you use a guard [...]? ::: When the same event should behave differently depending on a yes/no condition; the guards must cover all cases with no overlap.