State Machines

What a State Machine Is

Every diagram you have met so far shows behaviour only partly. A domain model or a design class diagram is static: it shows structure and says nothing about time. A system sequence diagram or a design sequence diagram does show time, but only one scenario, one particular run. A state machine fills the gap: it shows every legal ordering of events for one object (or one whole system) in a single picture. It is the course's model of dynamic behaviour over time.

The six core terms exam

Six words come up in every state machine question. They are best learnt on one small example, Larman's telephone, which is either Idle (receiver on the hook) or Active (receiver lifted).

1. State: a rounded rectangle; the object rests here between events.
2. Event: what happened (off hook). It triggers the transition.
3. Guard: in square brackets; checked when the event arrives. If it is false, nothing happens.
4. Action: after a slash; done instantly as the transition fires.
5. Transition: the arrow itself, from the source state to the target state. This one carries only an event.
6. Initial pseudostate: the filled dot that says where the life begins.

What the diagram does not have to show

Put together, a state machine shows an object's lifecycle: which events it reacts to, which transitions they cause, and which states it rests in between events. It does not have to show every possible event, because an event that is not drawn for the current state is ignored (Larman 29.1). That is why you can model at any level of detail, and why you never draw "do nothing" loops for irrelevant events.

The Workshop 6 sheet adds two points. First, a state can stand for a range of values: the colour of a traffic light is a state, but so is "fund > 0". Second, the diagram should cover the full lifecycle of the object, at a level of detail that matches the model it supports (the use case, SSD or class it explains).

When to Draw One, and at Which Level

A state machine takes effort, so the first question is whether an object deserves one. The answer depends on one property: does the object's response to an event depend on its current state? This section gives Larman's two guidelines, the two broad kinds of use, the three levels a machine can be drawn at, and the kinds of event you can put on an arrow.

State-dependent and state-independent objects exam

An object is state-independent (modeless) with respect to an event if it always responds to that event in the same way. If it reacts the same way to every event of interest, it is a state-independent object, and a state machine adds nothing: it would be one state with self-loops. A state-dependent object, on the other hand, reacts differently to the same event depending on its current state or mode. Pressing a phone button, for example, means different things when the phone is on-hook, off-hook or in a menu.

Guideline 2 explains the exam: both past questions are control systems, a CO₂ filter and a garage door.

The two broad applications (Larman 29.3)

Larman groups the uses of state machines into two families. The first is objects that react to events in complex ways; the second is protocols and legal sequences, where the machine says which operations are allowed when. The second is really a special case of the first, in which the "object" is a protocol, a language or a process.

Three levels: domain, use case, design exam

The Unified Process has no separate "state model". Instead, any element in any model can have a state machine attached: a domain concept, a use case or a design class (Larman 29.7). A machine for the Sale design class, for example, belongs to the Design Model. The level decides what is modelled and how the events and actions are written, and the exam always asks for the domain level.

Kinds of events

Before you can label an arrow you need to recognise the event. Events can be classified in two ways. The Workshop 6 worksheet classifies them by source:

1. External event: caused by something outside the system, such as a user touch, a button press or a sensor reading.
2. Internal event: caused by something inside the system, such as an Observer notification or the system detecting a fault.
3. Temporal event: caused by a date or time, usually checked against a system clock. Examples are "6 months without a transaction" and "no complaint after 1 hour".

UML also classifies events by form, and each form has its own notation on the arrow.

Guard or change event?

These two are easy to confuse. A guard [x > 5] is evaluated only when its trigger event occurs; it never fires anything on its own. A change event when(x > 5) is the trigger, and fires as soon as the condition becomes true. That is why a requirement such as "if the elapsed time ≥ minimum" needs a trigger of its own: a time event, a change event, or a periodic event such as tick with a guard.

Core Notation: States, Transitions, Start and End exam

Markers in this course read your diagram literally: the revision workshop warns that diagrams "must use correct notation… we will not be guessing or inferring". So the shapes and the label syntax have to be exact. This section covers the everyday symbols; 5.4 and 5.5 add the richer ones.

A word on sources. Larman ch. 29 covers only the basics: states, transitions, events, guards, actions and nested states. The lecture adds the choice pseudostate, and the course notation sheet adds composite states with their own initial states, and initial transitions that carry an action. Internal activities (entry/exit/do), time events, history states and concurrent regions are standard UML 2 notation not in Larman ch. 29. They are included here because exam wording such as "continue running as before the fault" calls for them.

Element by element

The transition string: event [guard] / action exam

The label on an arrow is a tiny sentence with a fixed grammar. The lecture reads it as: when the object is in State A, if the trigger event occurs and the guard is true, then perform the action and move the object to State B.

Four rules apply to the string:

• The order is fixed: event, then [guard], then / action.
• If the guard is false, the transition does not fire. If no other transition from that state accepts the event, the event is ignored and the object stays put.
• Several transitions with the same event leaving one state must have mutually exclusive guards. Otherwise the model is non-deterministic, which is a common mistake.
• An action is instantaneous and cannot be interrupted. Anything that takes time and can be interrupted by an event is a state (possibly with a do/ activity), not an action.

Starting and ending

The initial pseudostate answers "where does the life begin?". Because the object is not yet in any state, nothing can "happen to it" there, so the initial arrow carries no event; the notation sheet allows only an action such as / initialiseATM(). The final state answers "can the life end?". If it can end in more than one way, draw more than one; if the system runs for ever (most controllers), draw none.

Worked example: the pedestrian crossing light

The lecture's crossing light shows how an English sentence splits into the three parts of the string. The light starts at Red Standing. If the button is pressed when the traffic light is red, it goes to Green Walking and a timer starts. When the timer reaches 30 s it goes to Flashing Red Standing, and at 60 s it returns to Red Standing.

Completion transitions

Sometimes a state ends by itself: a printer finishes printing, a reset completes. A transition with no event leaving a state is a completion transition, and it fires as soon as the state's work is done. For a simple state, that is when its entry actions and do/ activity have finished (immediately, if there are none); for a composite state, it is when its nested final state is reached.

A completion transition may have a guard, but if the guard is false at the moment of completion it is not re-evaluated later, so the object stays in the state (the bottom row of the timeline in 5.2). To mean "leave as soon as X becomes true", use when(X) or a periodic event with a guard. The only other unlabelled arrows are the initial transition and transitions out of a choice (which carry only guards). Any other arrow with no event label is a mistake.

Inside a State: entry, exit, do and Internal Transitions

Sometimes the same action belongs on every arrow into a state, or the object keeps doing something for as long as it is in a state. Writing it on every arrow is repetitive and easy to get wrong. UML 2 lets a state carry a second compartment that lists behaviour belonging to the state itself (this is not in Larman ch. 29).

• entry / a runs on every entry, whichever transition entered the state. Use it when every incoming transition would otherwise carry the same action.
• exit / a runs on every exit. Use it when every outgoing transition would otherwise carry the same action.
• do / activity is an ongoing activity that starts after entry. It stops either when an outgoing transition fires or when it finishes on its own, in which case it produces a completion event. Gerund-named states such as FilteringOut often have a do/ activity.
• An internal transition e [g] / a handles event e without leaving the state, so no exit or entry actions run.

Self-transition or internal transition? exam-useful

In both, the object handles an event and ends up in the same state, so they look alike. The difference is whether it actually leaves. A self-transition is a real arrow that goes out of the state and back in; an internal transition is a line inside the state, and the object never leaves. Everything else follows from that.

Here is the worked contrast. Suppose a phone in Dialing has entry / start digit timer and after(10 s) / play error tone leading to Idle. If digit / append digit is a self-transition, each digit re-enters Dialing and restarts the timer, so you get an inter-digit timeout. If it is an internal transition, the 10 s counts from the first entry, so you get a total dialling timeout.

This is why the garage-door answer (5.10) sets its timer on the incoming transition rather than as an entry action: a "keep waiting" self-loop then does not reset it.

Choices, Composite States, History and Regions exam

Real requirements branch ("if the PIN is correct… otherwise…"), and they contain sweeping phrases like "at any stage" and "continue as before". Drawn with only plain states and arrows, those turn into a tangle of duplicated arrows. This section gives the four structuring tools that keep a diagram small: the choice pseudostate, composite states, history, and (rarely) concurrent regions. It ends with the exact rule for what happens when an event arrives.

The choice pseudostate exam

A choice pseudostate "realizes a dynamic conditional branch". It evaluates the guards of its outgoing transitions and takes exactly one of them. It is useful when one event can lead to different outcomes: you write the event once, then branch. The two halves of the figure below are equivalent (lecture slide 19).

The rules for a choice are these:

• The event goes on the incoming segment only. Each outgoing segment carries a guard and, optionally, an action.
• There can be two or more outgoing transitions, for example [bal < 0], [0 <= bal < min] and [min <= bal].
• [else] is predefined and is taken if no other guard is true. Use it to make the branch exhaustive, because if no guard is true at a choice, the model is ill-formed.
• The guards should be mutually exclusive.
• A choice can lead back to the same state it started from. In the notation-sheet ATM, enterPin(pin) leads to a choice whose [Invalid] branch goes back to Waiting for Pin.

UML also has a junction, drawn as a small filled dot, which is a static branch. It is not used in this course, so always use the diamond.

Composite states (superstates) exam

A state may contain substates, and each substate inherits the transitions of its superstate (the enclosing state) (Larman 29.4; lecture slide 18). The idea comes from Harel statecharts, and it is the main tool for keeping diagrams small. The telephone from the lecture and Larman shows it: while the phone is Active it moves through several sub-phases, but hanging up ends the call from any of them.

Entering and leaving a composite has precise rules. The figure below shows the four kinds of arrow, and the list underneath explains them, together with priority, completion and the order of entry and exit actions.

1. Entering via the boundary. An arrow to the composite's edge (p, or off hook to Active) enters through the nested initial pseudostate, here into A. That is why a composite entered through its boundary must have a nested initial state; as the case study puts it, "even in these sub-states, there always needs to be a sub-state assigned".
2. Entering a substate directly. An arrow may cross the boundary to a specific substate (q to B), bypassing the nested initial state.
3. Leaving from the boundary (inherited transition). An arrow from the composite's edge (r, or on hook) applies whichever substate is current. This is how to model "at any stage / at any point / at any time, X happens": one arrow from the superstate instead of one arrow from every state.
4. Leaving from a specific substate. An arrow from a substate's own edge (u) fires only from that substate. In Tony's Pizza, Delivered → Completed applies to the Delivered substate only, and the case study stresses being particular about which state such an arrow leaves from.

• Priority. If a substate and its superstate both handle the same event, the substate's (inner) transition wins.
• Completion of a composite. If a region reaches its nested final state, an unlabelled arrow from the composite's boundary (a completion transition) fires.
• Entry and exit order. Entering from outside runs the superstate's entry and then the substate's; leaving runs the substate's exit and then the superstate's.
• Conceptual grouping. Besides saving arrows, a composite groups related states. In the case study the delivery states form a Delivery superstate, because they are really the states of the Delivery concept nested inside Order.

The course notation sheet: the Simple ATM

The notation sheet brings several features together: an initial transition with an action, a composite with its own initial state, design-level events with parameters, two choice pseudostates and a final state. Two of its sentences are worth tracing. Sentence 2 says the ATM "can be disconnected at any time" in standby, which becomes disconnectATM() from Standby to the final state. Sentence 8 says card removal returns the ATM "from being active to being on standby", which becomes releaseCard(card) from the Waiting for Card Removal substate (not the boundary) back to Standby, because removal is only legal at that point.

History pseudostates: H and H* exam

History states are not in Larman ch. 29 or the lecture, but they are the exact UML answer to wording such as "once the reset is complete, the filter will immediately continue running as before the fault" (2021 S1 Q5).

The problem is memory. An arrow to a composite's boundary always restarts at the initial substate, which forgets where the object was. A shallow history (H) pseudostate, a circle containing H drawn inside a composite, fixes that: a transition into H re-enters the composite at the direct substate that was active when the composite was last exited. If that substate is itself composite, it is entered through its own initial state.

Deep history (H*), drawn as a circle containing H*, goes further and restores the last active configuration at every nesting level. If the composite has never been active, there is nothing to remember. For that case you can add a default history transition, an unlabelled arrow from H to a substate; without one, entry falls back to the composite's initial state.

Concurrent (orthogonal) regions

Sometimes an object has two independent aspects at once. A composite state can be split by dashed lines into regions, and the object is then in one substate of each region simultaneously. Each region has its own initial state, and an event can trigger transitions in several regions at once. Fork and join bars (thick lines) split one transition into several regions or merge them back. This is UML 2 and not taught in the course; use it only if the text clearly describes independent, simultaneous aspects, such as "the alarm sounds while the camera records".

The one place the course material comes close is the Workshop 11 partial solution. Its Zone_Unit frame contains two separate machines, each with its own initial state: one tracks whether the zone is armed (Inactive, Countdown/Beeping, Active), the other whether it is switched On or Off. That is two orthogonal regions in effect, although the solution leaves out the dashed separator. If you ever need the idea, draw the dashed line.

What happens when an event arrives

Putting the notation together, these are the firing rules. They are what you are applying, in your head, whenever you trace a scenario through a diagram.

1. At any moment the object is in exactly one state (one per region), and through nesting it is also "in" every enclosing superstate.
2. When an event arrives, look for transitions triggered by it, starting from the innermost current state and moving outwards through the superstates.
3. Evaluate their guards. At most one should be true. If none is true, or no transition handles the event, the event is ignored.
4. Fire the transition: run the exit actions (innermost outwards), then the transition action (and any choice branch), then the entry actions (outermost inwards), and then start the do/ activity.
5. Events are processed one at a time, which is called run-to-completion: the next event is handled only after the current step finishes.

Modelling Guidelines

Knowing the symbols is half the job. The other half is reading ordinary English requirements and deciding which words become states, which become events, and which become guards or actions. This section collects the course's rules of thumb for that translation, the naming conventions, and the mistakes that cost marks.

Reading requirements: which words become what exam

Exam questions describe behaviour in everyday language, so the first skill is recognising cues. Step 2 of the exam procedure (5.9) is exactly this table applied sentence by sentence.

State or not? The tests

A state is a condition the object can sit in while an event arrives. Most modelling errors come from turning the wrong things into states, so apply these tests to every candidate:

• Does the object wait here for something? The case study's rule is that whenever the object must wait for a period, it gets a state. AssigningDeliveryStaff is a state because no driver may be free for ten minutes.
• Does it change what happens next? Adding and editing items in a draft order "doesn't really feel like it's changed the state of the order", so the order stays in Draft, and the edits become a self-transition or internal transition rather than a new state.
• Instantaneous work is an action, not a state. "Charge $20", "notify the customer", "issue a new card" and "check the PIN" all happen on a transition. A state called CheckingPIN followed by an unlabelled arrow is usually a choice pseudostate in disguise.
• Something that sounds like a state may be a transition. In the case study, "rejected" first looked like a state. But the text then says the customer edits and resubmits, so rejection is really the transition staff rejects order / add note back to Draft.
• Split a state if the legal events differ. The case study considered a single ReadyForPickup state for both pickup and delivery orders, but split it, because "customer collects order" is only legal for pickup orders and a shared state would need guards on everything.
• Name implicit states. The text may never name the period between two events, such as between "starts a new order" and "submits". Invent a sensible domain name (Draft, Collecting), but prefer the requirement's own words when they exist (Submitted, Collected).

Naming conventions

The course is consistent in how it names states but mixes styles for events. Whatever style you use, do not give a state an event-like name (Submit), or an event a state-like name (Submitted used as a trigger). Nouns and adjectives on one side and verbs on the other is what keeps the two apart.

Common mistakes and what markers look for exam

The Workshop 6 review slides only present an example, so this list is assembled from the notation-sheet rules, the case-study reasoning, Larman, and the revision workshop's warning that diagrams "must use correct notation… we will not be guessing or inferring" (Workshop 11). The numbers match the badges in the "spot the mistakes" diagram below.

1. No initial pseudostate. Every machine needs one, and so does every composite entered via its boundary.
2. A trigger on the initial transition. Only / action is allowed there. (The Workshop 6 partial solution labels it "Onboarded", but prefer the notation-sheet rule.)
3. States that are really actions or activities, such as Charge Fee, Check PIN or Notify Customer. Make them / actions or choice branches instead.
4. Unlabelled arrows between ordinary states. Every non-completion transition needs an event.
5. Missing guards where the text says "if…". In particular, the same event leaving a state twice without exclusive guards is non-deterministic.
6. Guards written informally, as "Yes/No" with a question in the diamond (as in the Workshop 6 partial solution). In the exam, write proper [condition] guards.
7. Ignoring "at any stage", or drawing ten separate arrows instead of one superstate transition. Both are weaker than a superstate. Also check that the superstate contains exactly the states the text names: in Tony's Pizza, cancel is legal during preparation and delivery but not in ReadyForPickup.
8. Using the boundary when the text says "resume as before". That calls for H, or for a separate reset state per mode that returns to that mode, which is what the official 2021 S1 Q5 answer draws. Conversely, using H when the text says "go back to normal monitoring" is wrong.
9. Dead ends and unreachable states. Every non-final state needs a way out, and every state must be reachable from the initial state.
10. Drawing a flowchart or activity diagram. States are not process steps, so do not join "states" with unlabelled sequence arrows or use diamonds without guards.
11. Wrong shapes. States are rounded rectangles, a choice is a diamond, the initial pseudostate is a filled dot and the final state is a bullseye.
12. Wrong level. The question asks for domain level, so use domain events (obstruction detected) rather than invented method signatures, although names the question gives are fine. The Workshop 11 partial solution shows the design level: its events are the design classes' methods (activate(), switch_zone(true)) and its actions are attribute assignments (/is_active = true). Both official 2021 answers stay at the domain level (fault detected, open button pressed).
13. Inconsistent names between the text and the diagram. Reuse the question's vocabulary, and state any assumptions in a note.

Worked Example: Tony's Pizza Order Lifecycle

The course case study models one business object, a pizza Order, at domain level. It is a perfect rehearsal for the exam because it uses nearly every feature: choices, a superstate, a time event and two final states. Read the requirements first, then step through the diagram as it is built.

Decisions worth copying

• Choice pseudostates for "if card / if cash". The event is the same in both cases and only the action differs, so the event sits before the diamond and the guards after it.
• The Delivery superstate groups the delivery sub-lifecycle, so one staff cancels order arrow from its boundary covers "at any point during delivery". The arrows to Completed and ProcessingComplaint, by contrast, leave from the Delivered substate only.
• after(1 hour) is a temporal event, measured from entering Delivered. No [no complaint] guard is needed, because a complaint makes the order leave Delivered, which cancels the timer.
• Two final states, because the lifecycle can end in two ways.
• Cancel is not drawn from ReadyForPickup, because the text limits cancellation to preparation and delivery.

From State Machine to Design Model and Code exam-useful

A domain-level machine explains behaviour; at some point it has to become a class that enforces it. The case study's next step does exactly that: states are mapped to enum values, events become methods, and guards are implemented in the logic of each method. Workshop 6 Part 2 and its review slides do the same. Once you know the mapping, you can move between diagram and code in either direction.

The mapping rules

• The object whose lifecycle is modelled becomes a class, called the context: for example Account, Door, Order or Vending_Machine.
• The set of states becomes an «enumeration» (such as State) plus a private attribute state : State.
• Each event becomes a public method, such as overduePayment() or movementDetected().
• A guard becomes an if condition inside that method, using attributes or parameters.
• A transition action becomes a call to a (usually private) method inside the branch, made before or after changing state.
• An entry or exit action becomes a call made in a private setState() / enterX() helper whenever that state is entered or left.
• The initial pseudostate becomes the constructor, which sets the initial state and runs the initial action.
• An event that is not legal in the current state can either be ignored (Larman's semantics) or throw an exception. The Workshop 8 JetstarSearch classes "throw an exception… if the method is called in the invalid state".
• A composite state becomes a check on the superstate, which covers all its substates. Optionally the substates get a separate class or enum: Workshop 6 uses class InDefault with «enumeration» SubState {GracePeriod, PaymentPlanOffered, HealthyDebt, BadDebt}.
• A time event is raised by a timer or scheduler that calls the event method (for example timeout()).

Worked example: the sliding door (Workshop 6 review)

The review slides' sliding door has five states: doors closed (the initial state, with /initialiseDoor()), doors open, doors closing, maintenance and doors locked. movementDetected takes it from closed or closing to open; timeout (after 15 s) from open to closing; doorFullyClosed from closing to closed; keyOverride from closed to maintenance and reset() back; and lock doors / unlock doors move it between closed and locked.

Implementation 1: enum plus conditional logic (the course's approach)

public enum State { OPEN, CLOSING, CLOSED, LOCKED, MAINTENANCE }

public class Door {
    private State state;

    public Door() {                         // initial pseudostate: / initialiseDoor()
        initialiseDoor();
        state = State.CLOSED;
    }

    /** Event. Legal in CLOSED and CLOSING; ignored elsewhere. Returns true if a transition fired. */
    public boolean movementDetected() {
        switch (state) {
            case CLOSED:
            case CLOSING:
                openDoors();                // transition action
                setState(State.OPEN);
                return true;
            default:
                return false;               // event ignored in OPEN, LOCKED, MAINTENANCE
        }
    }

    public void timeout() {                 // time event after(15 s), raised by a timer
        if (state == State.OPEN) setState(State.CLOSING);
    }

    public boolean doorFullyClosed() {
        if (state != State.CLOSING) return false;
        setState(State.CLOSED);
        return true;
    }

    public void keyOverride() { if (state == State.CLOSED) setState(State.MAINTENANCE); }
    public void reset()       { if (state == State.MAINTENANCE) setState(State.CLOSED); }
    public void lockDoors()   { if (state == State.CLOSED) setState(State.LOCKED); }
    public void unlockDoors() {
        if (state != State.LOCKED)          // strict alternative: reject illegal events
            throw new IllegalStateException("unlockDoors() not allowed in " + state);
        setState(State.CLOSED);
    }

    private void setState(State next) {     // one place for exit/entry actions and tracing
        System.out.println(state + " -> " + next);
        state = next;
    }
    private void initialiseDoor() { /* ... */ }
    private void openDoors()      { /* ... */ }
}

Guards and nested states: the Workshop 6 credit-card account

Guards and composite states follow the same pattern. In this fragment of the Workshop 6 account, the guard [available fund > 0] becomes part of an if; the In default composite is one enum value with its own sub-state object; its nested initial state plus choice becomes an enter() method; and the inherited transition from its boundary is a single check that covers every substate.

public void availableFundsChanged(double funds) {          // event with parameter
    if (state == State.SUSPENDED && funds > 0) {           // guard [available fund > 0]
        state = State.ACTIVE;
    }
}

public void overduePayment() {                              // Active -> In default
    if (state != State.ACTIVE) return;
    state = State.IN_DEFAULT;
    inDefault.enter(customer.hasMissedPaymentHistory());   // nested initial + choice
}

public void outstandingPaid() {                             // drawn from the In default boundary:
    if (state == State.IN_DEFAULT) {                        // one check covers EVERY substate
        state = State.ACTIVE;                               // (= inherited superstate transition)
    }
}

// in class InDefault
void enter(boolean missedBefore) {
    if (missedBefore) { chargeFee(20); subState = SubState.PAYMENT_PLAN_OFFERED; } // [yes] / charge $20
    else              { subState = SubState.GRACE_PERIOD; }                          // [no]
}

Implementation 2: the GoF State pattern (Larman ch. 37)

When several methods repeat the same switch (state) structure, Larman offers the State pattern as an alternative. It is not part of this course's GoF lectures, but it is the natural object-oriented answer to the same problem.

public boolean movementDetected() {
    switch (state) {
        case CLOSED:
        case CLOSING: openDoors(); setState(State.OPEN); return true;
        default:      return false;
    }
}
public void timeout() {
    if (state == State.OPEN) setState(State.CLOSING);
}

abstract class DoorState {                       // default = event ignored in this state
    void movementDetected(Door d) { }
    void timeout(Door d) { }
}
class ClosedState extends DoorState {
    @Override void movementDetected(Door d) { d.openDoors(); d.setState(new OpenState()); }
}
class OpenState extends DoorState {
    @Override void timeout(Door d) { d.setState(new ClosingState()); }
}
class ClosingState extends DoorState {
    @Override void movementDetected(Door d) { d.openDoors(); d.setState(new OpenState()); }
}
public class Door {                              // context
    private DoorState state = new ClosedState();
    public void movementDetected() { state.movementDetected(this); }
    public void timeout()          { state.timeout(this); }
    void setState(DoorState s)     { state = s; }
    void openDoors()               { /* ... */ }
}

Larman notes that the state objects have no attributes, so a single shared instance of each (a Singleton) is enough; there is no need to create a new state object on every transition as the sketch above does.

Use-case (system-operation) state machines in design

A machine at the use-case level shows the legal order of system operations. Larman's Process Sale machine is the standard example.

In design, the controller (see Part IV) or a session object can enforce this order, for example by rejecting makePayment before endSale. This is the "session object… to disallow out-of-order operations" alternative that Larman mentions in ch. 11. A system state machine also works as a consistency check for SSDs (Part II), because every SSD scenario must be a path through it; the vending machine in 5.10 shows this.

public void insert(Coin c) {
    if (state == State.WAITING_FOR_COIN && value(c) >= price(selected)) {
        dispense(selected);                 // action
        state = State.DISPENSING_PRODUCT;   // target
    }
}

The Exam Procedure: a Domain-Level Machine from Numbered Sentences exam

The exam question gives you about six or seven numbered sentences describing a device or system, and asks for a domain-level state machine diagram worth 15 marks. Without a method it is easy to miss a sentence or to draw a flowchart. Budget about 15 minutes and work through these ten steps in order.

1. Identify the subject. Find the one object or system whose lifecycle is described ("the CO2 filter system", "the garage door"), and write it as the diagram title.
2. Annotate each sentence using the cue table (5.6). Circle the states (waiting, ongoing activity, conditions), underline the events (often italic in the question), bracket the guards ("if…") and mark the actions ("will set / notify / charge"). Flag the special phrases: "at any stage" means a superstate, "as before / resume" means H, "until" means an event out of a waiting state, "go back to step N" means a transition to that state, and time phrases mean time events.
3. Draw the initial pseudostate and the first state described ("when turned on, it will wait for…"). No event on the initial arrow, although an / action is allowed.
4. Lay out the main flow sentence by sentence. Add each new state, then its outgoing transitions with event [guard] / action, reusing the names given in the question.
5. Handle branches. For one event with several outcomes, use a choice diamond or several arrows with mutually exclusive, exhaustive guards ([else] helps).
6. Handle timing. Use after(t), or, when the text says the system "monitors" elapsed time, a periodic event (timer tick) with guards.
7. Handle "at any stage" events. Draw a superstate around exactly the states where the event can occur, give it a nested initial state, and draw one transition from its boundary to the exceptional state (Fault, Shutdown, Out of Order). For the way back, "go back to normal operation" means an arrow to the boundary, while "continue as before" means an arrow to an H inside it.
8. Add the final state only if the lifecycle can end ("closed", "disconnected", "cancelled"). Control systems usually have none.
9. Check the diagram. Every sentence covered (write sentence numbers next to elements: markers like traceability); every state reachable and with a way out unless final; no unlabelled arrows except the initial one, choice branches and deliberate completion transitions; correct shapes; no states that are really actions.
10. Write assumptions in a note, such as "assumed the door starts Closed" or "assumed the door reports fully closed". The course explicitly allows assumptions that are consistent, reasonable and listed.

Here is the procedure applied to 2021 S2 Q8, the garage door, one sentence at a time. The sentences are:

1. The system safely operates a door on a home garage.
2. If the open button is pressed, the door starts opening.
3. While opening, if an obstruction is detected the door halts until the obstruction is removed.
4. Once fully open, a timer is set and the door waits.
5. The door monitors the elapsed time since it opened. If the elapsed time is less than the
   minimum open time, it keeps waiting while open. If it is greater than or equal, the door
   starts closing.
6. While closing, it may detect a vehicle, in which case it starts opening again (back to step 3).
7. At any stage, if a fault is detected, the door stops and enters a fault state until the
   system is restored, then goes back to normal operation.

Worked Past-Exam Answers exam

Two past questions asked for a domain-level state machine: 2021 S1 Q5 (the Mars CO2 filter) and 2021 S2 Q8 (the garage door). For each, you get the guide's model answer, why it earns the marks, and the official answer (released 26/27 Oct) redrawn and compared. A third question, 2021 S1 Q3, hides a state machine inside a class and links it to an SSD.

2021 S1 Q5: the Mars CO2 filtering system (15 marks)

1. The system safely maintains the CO2 level in a Mars dwelling.
2. It monitors regular updates on the current level: current(co2).
3. If the level rises above max_co2, the filter starts filtering CO2 out until the level
   reaches max_co2 – upper_threshold.
4. If the level drops below min_co2, the filter starts adding CO2 in until the level
   reaches min_co2 + lower_threshold.
5. While running, the filter may detect a fault. It then resets, and once the reset is
   complete it immediately continues running as before the fault.
6. At any stage, if an emergency is detected, the system performs an emergency shutdown.
   It stays shut down until the safe_restart signal, then goes back to normal monitoring.

Notes and acceptable variations

• Readings inside the normal band (min_co2 <= co2 <= max_co2) while in Monitoring, or above the stop threshold while in FilteringOut, need no arrow, because undrawn events are ignored.
• You may name domain events instead, such as CO2 too high, but using the given current(co2) with guards is closer to the text.
• The filter starting and stopping can be shown as actions instead of do/ activities: current(co2) [co2 > max_co2] / start filter and … / stop filter.
• Without H, a flat alternative is two reset states (ResettingFromFilteringOut → FilteringOut, ResettingFromAddingIn → AddingIn). This is exactly what the official answer draws (below), so it is fully acceptable; H is the more compact way to say the same thing. A single Resetting state that returns to Monitoring or to the Running boundary, however, is wrong for sentence 5.

The official answer (released 26/27 Oct)

The official answer reaches the same behaviour by a flatter route. Everything except the shutdown sits in a superstate Normal Operation. Inside it, monitoring takes current(co2) into a choice diamond with two guarded branches that carry start actions. The two filtering states return to monitoring with stop actions, and each filtering state has its own reset state that leads back to the state it came from. Here it is redrawn.

Compared with the guide's diagram, the official answer agrees on the states, the guards, the superstate for "at any stage", and the return to normal operation (not history) after a safe restart. Its differences are all acceptable variations listed above: a choice pseudostate instead of two guarded arrows, actions on the transitions (start filtering out, stop adding) instead of do/ activities, and two reset states instead of H. What it shows markers reward is the guarded current(co2) event with the exact threshold expressions, a return path to the right mode after a fault, and actions that say what the system does.

2021 S2 Q8: the garage door system (15 marks)

The full model answer is the final picture of the 5.9 stepper (press Show all). In summary: initial state Closed (an assumption); open button pressed → Opening; obstruction detected / stop door → Halted and obstruction removed back; door fully open / set timer → Open; a periodic timer tick with guards for sentence 5; vehicle detected → Opening and the assumed door fully closed → Closed; and a superstate NormalOperation with fault detected / stop door → Fault and system restored back to the boundary (no history: "back to normal operation", not "as before").

The official answer (released 26/27 Oct)

Three points stand out. First, the official answer uses the choice-diamond variant for sentence 5, one of the compact alternatives above. Second, it also assumes the unstated door fully closed event, so that assumption is expected, not a risk. Third, it draws both initial pseudostates, the outer one and the one inside the superstate, which is the complete form. The guide's version is just as good, and in one respect clearer: door fully open / set timer names the event and the action separately.

2021 S1 Q3: the vending machine (a machine hidden in a class)

Q3 itself asks for an SSD, but the given class Vending_Machine defines exactly the states a state machine needs, and its operations supply everything else. This one is at the system/design level: events are the class's methods.

• Its attribute is state : {waitingForSelection, waitingForCoin, refundingCoin, dispensingProduct, outOfOrder}.
• Its public operations, which become the events, are select(Product), insert(Coin), cancel(), refundingComplete(), dispensingComplete() and reset().
• Its private helpers, which supply the guards and actions, are available(Product): boolean, price(Product): int, value(Coin): int, display(Product), refundCoin(), dispense(Product) and error().

1. When turned on, it waits for a selection.
2. It displays the selected product and waits for a coin.
3. Low-valued coins are returned; high-valued coins are accepted (no change).
4. Once paid, it dispenses.
5. While waiting for payment the customer may cancel, and the machine is ready for another purchase.
6. At any stage an error puts it Out of Order until a technician fixes it and presses reset.

• error() is private, which makes it an internal event that the machine detects itself.
• No cancel() refund action is needed, because a coin is only accepted when it pays for the product.
• select(p) [not available(p)] is ignored. Optionally, show it as an internal transition with a "sold out" display.

The SSD link

The Q3 scenario is "error after selecting chips, technician fixes it, purchase completes with a $2 coin". On this machine reset() returns to waitingForSelection (via inService's initial state), so after the reset the customer must call select(chips) again before insert($2). In other words, the state machine tells you which messages the SSD must contain. The official answer to Q3 confirms that re-selection; since that answer is an SSD only, the state machine above remains the guide's own derivation.

One-Page Summary for Your Notes Sheet

You may bring two double-sided A4 pages into the exam. This is the state machine page, condensed from the whole Part; each card links back to where it is explained.