State transition diagram, decision table and event–action table
Lifecycles, rules for every combination, and responses to events.
What it explains and when it is useful
A state transition diagram shows the states something can be in and the events that move it between them, with guards and actions. A decision table lists every combination of conditions and the action for each. An event–action table lists each event an event-driven program handles and its response.
When to use it: State diagrams: anything with modes or a lifecycle (bookings, orders, game states, a level). Decision tables: rule-heavy logic. Event–action tables: games and GUI programs driven by clicks, keys and timers.
Worked example
Illustrative: PracticePal is a fictional project used throughout this guide.
Scroll sideways to see the whole diagram.
Scroll sideways to see the whole diagram.
Decision table: may this booking be saved?
| Condition / action | R1 | R2 | R3 | R4 | R5 | R6 |
|---|---|---|---|---|---|---|
| Slot valid? | N | Y | Y | Y | Y | Y |
| Room blocked? | – | Y | N | N | N | N |
| Overlaps a booking? | – | – | Y | N | N | N |
| 3 bookings already this week? | – | – | – | Y | N | N |
| Loud and neighbour has loud overlap? | – | – | – | – | Y | N |
| Action | Invalid time | Room blocked | Slot taken + offer queue | Weekly limit | Noise clash | Save booking |
“–” means the condition is not checked (an earlier rule already decided). Six rules cover every case, and the table becomes six abnormal or extreme tests.
Event–action table: week grid page
| Event | Condition | Action |
|---|---|---|
| Page loads | logged in | GET /api/week; draw grid; show weekly counter |
| Tap a free cell | – | Select it; fill booking panel; enable Confirm |
| Tap a booked cell | – | Show “Taken”; show Join waiting list |
| Tap Confirm | counter < 3 | POST /api/book; disable button until reply |
| Reply 201 | – | Mark cell “You”; counter + 1; show confirmation |
| Reply 409 | – | Show reason in error area; refresh grid |
| Timer every 60 s | page visible | Refresh grid (others may have booked) |
| Press ◀ / ▶ | within current and next week | Load that week |
Notation and legend
| Symbol or part | Meaning |
|---|---|
| ● / ◉ | Start / end |
| Rounded box | State; a second line can say what is true in it |
| Arrow label | event [guard] / action |
| Guard | Condition that must be true for the transition |
| tick | The scheduler's 5-minute job |
Design decisions it communicates
A diagram earns marks when you explain the decisions it shows. In PracticePal's documentation these would each be one sentence:
- Cancelled and no-show both free the slot by calling offer_next, so SC7 and SC8 share one mechanism.
- Check-in is only possible inside a window, written as a guard.
- Every status in the data dictionary appears as a state.
Common mistakes
- States named as actions (“Cancelling”).
- Transitions with no event.
- Missing states that the database allows.
- Decision tables with impossible or missing combinations.
Checklist for your own version
Ticks are saved in this browser only, so you can use the list while you draft.