Skip to content
Software Architecture Guide

State and Event

Explanation

Section titled “Explanation”

A state machine models a system as a set of explicit states, with transitions between them. An event is what moves the machine along. The machine detects an event occurrence, dispatches it, and then processes it.

One event at a time. The machine handles event occurrences one after another. This is called run-to-completion. No other event is dispatched until the current one is fully processed.

Stable configuration. Before each processing step, the machine is in a stable configuration. All entry, exit and internal activities are finished. Do activities (work that runs while the machine sits in a state) may still be running. The article State Entry, Exit and Do Behavior covers these in detail.

Do activities. A do activity starts once the state is entered and its entry behavior is done. It then runs independently of the state machine. The machine always aborts it before the exit behavior of that state runs.

Triggers. A trigger names the event that can cause a transition. Signal triggers and call triggers come from the receptions and operations of the class that owns the state machine. See Transition Syntax (Trigger, Guard, Behavior).

Guards. A guard is a condition on a transition. When an event occurs, guards decide which transition fires. If two transitions react to the same event and both guards are true, only one fires.

Nested states. A simple state becomes a composite state when you add one or more regions. See Composite State and Concurrent Region.

The same word in other places. In BPMN, a catch event is something the process passively waits for from outside. In domain-driven design, Fowler’s event notification means a system sends event messages to tell other systems about a change in its domain. These are related uses of the word “event”, not the same construct. See BPMN Event and Domain Event.

Example

Section titled “Example”

A door controller has the states Closed and Open. The event “open requested” arrives while the controller is in Closed. A guard checks that the door is unlocked. If the guard is true, the transition to Open fires. If another event arrives during that step, the controller finishes the current one first.

Trade-offs

Section titled “Trade-offs”

Run-to-completion keeps each step simple: only one event is processed at a time, so no event is cut off by a newer one. The cost is that a new event waits until the current one is fully processed. Do activities are the exception, since they run independently of the state machine and the machine may abort them.

Two states joined by transitions. An event triggers each transition, and a guard in square brackets limits the first one.

Diagram source 
@startuml
[*] --> Closed
Closed --> Open : openRequested [unlocked]
Open --> Closed : closeRequested
@enduml

Checks

Section titled “Checks”
  • The document states that each event is processed completely before the next one is dispatched.
  • Where several transitions react to the same event, guard conditions are given so it is clear which one fires.
  • Signal and call triggers match the receptions and operations of the owning class.
  • Long-running do activities are stated to be aborted before the exit behavior of their state.
Section titled “Related”

Sources

Section titled “Sources”