Learning Objectives
By the end of this lesson you will be able to:
- Read a UML state diagram using standard notation
- Draw a state diagram from a written specification
- Identify the initial and terminal states in any diagram
Standard State Diagram Notation
State diagrams use a simple visual language:
States — drawn as rounded rectangles (or ovals). The state name is inside.
[Active] [Suspended] [Closed]
Initial state — a filled black circle with an arrow pointing to the starting state. Every diagram has exactly one.
● → [Pending]
Terminal state — a filled black circle inside a larger circle (bullseye). Represents a final state from which no further transitions are expected. Optional.
[Closed] → ⊙
Transitions — arrows from one state to another, labeled with the event (and optionally a guard and action).
[Active] --"Suspend"--→ [Suspended]
[Suspended] --"Restore"--→ [Active]
Guard conditions — written in square brackets after the event:
[Active] --"Cancel [balance = 0]"--→ [Closed]
Self-transitions — an arrow that loops back to the same state (the event occurs but the state doesn't change):
[Active] --"Login"--→ [Active]
Reading a Diagram: Subscription Lifecycle
● → [Trial]
[Trial] --"Subscribe"--→ [Active]
[Trial] --"Trial expires"--→ [Expired]
[Active] --"Cancel"--→ [Cancelled]
[Active] --"Payment fails"--→ [Suspended]
[Suspended] --"Payment succeeds"--→ [Active]
[Suspended] --"30 days pass"--→ [Cancelled]
[Cancelled] --"Reactivate"--→ [Active]
[Expired] → ⊙
Reading this diagram: a Trial user who doesn't subscribe moves to Expired (terminal). An Active user who cancels can reactivate. A Suspended user has 30 days to resolve the payment.
Drawing From a Specification
Specification: "An item in the inventory starts as Available. When a customer places an order, it becomes Reserved. If the order is confirmed, it moves to Sold. If the reservation times out after 30 minutes, it returns to Available. Once Sold, the item cannot be returned to any previous state."
Steps:
- Identify states: Available, Reserved, Sold
- Identify events: "Customer orders," "Order confirmed," "Reservation times out"
- Draw transitions for each event + from/to state pair
- Add terminal annotation to Sold (no transitions out)
● → [Available]
[Available] --"Customer orders"--→ [Reserved]
[Reserved] --"Order confirmed"--→ [Sold]
[Reserved] --"Timeout (30 min)"--→ [Available]
[Sold] → ⊙
Pro Tip: Before testing, always ask: "Does the diagram show what happens to Sold items if a refund is requested?" If the specification doesn't address it and the diagram doesn't show it — that's a gap. File the question before writing the test.
Connecting the Diagram to the Table
Once you have the diagram, convert it to a transition table (Lesson 4.2). The diagram gives you the big picture; the table gives you the test cases. Together they're more powerful than either alone.
Summary
State diagrams are a shared language between developers, testers, and business analysts. Being fluent in reading and drawing them lets you extract test cases from any system with a lifecycle — even systems you've never seen documented. This lesson completes the state transition module. In the practice challenge ahead, you'll apply these skills to an RPG inventory with real bugs to find.