Standard Design Patterns

Key Principle

Statechart complexity grows along two independent axes -- too many states and too many arrows -- and each axis has a distinct family of design patterns that collapses the growth. Concurrency converts multiplicative state combinations into additive regions. Depth with history eliminates duplicates and their cascading copies. Transient states, parameterized alerts, clustering, and role-gated guards reduce arrow counts from quadratic to linear. These patterns compose: a single well-designed chart typically applies several simultaneously.

Why This Matters

Without these patterns, a statechart for a real UI degenerates into the same unmanageable complexity it was meant to tame. N independent binary controls produce 2^N flat states. A single duplicate state that interacts with two others forces duplication of all three, producing six states instead of three -- and "it is easy to think that having an extra state will not cause too many problems. However, a duplicate state can lead to a rapid increase in the number of states" (Chapter 8). On the arrow side, N source states routing to M destinations based on conditions produce N x M arrows without a transient state hub, or N redundant return arrows without the history mechanism. These patterns are not optimizations applied after the fact; they are the difference between a statechart that functions as a design tool and one that is "massive and yet offer little benefit" over procedural code (Chapter 8).

Good Examples

• Parameterized alert state: Rather than creating one alert state per validation field, a single parameterized alert state accepts message text and dialog position as incoming transition parameters while keeping button count and labels static. This collapses N identical alert states into one without losing formal completeness (Chapter 8).

• History-based cancel/undo: "Moving forwards through an application is usually easier than backtracking... This is achieved using the history mechanism" (Chapter 8). A Print Window reachable from both Summary and Details uses H* to return to whichever screen invoked it, requiring zero modification to the subwindow when new calling screens are added.

• Transient state routing: When a user progresses a fault report, a transient state evaluates guard conditions on [Status, Role] pairs and routes to the correct destination. "State 1 is a transient state. It does not enable or disable any screen items. It is used to switch to the next state after an FR has been progressed" (Chapter 11). This reduces O(n^2) arrows to O(n).

• Cascading field enablement: Project -> Sub-system -> Module form a dependency chain where changing an upstream value resets all downstream values. "When a different project is selected in the Project field, the value in the Sub-system field is set to because the range of available sub-systems is determined by the project selected" (Chapter 11). Concurrent regions model each field's enable/disable behavior independently.

• Role-gated state entry: Transitions annotated with authorized roles serve as both workflow definition and access control. "If a user has been granted an Originator role and a fault is displayed with a status of Evaluated, then that user will not be able to progress the fault or edit its details" (Chapter 11). The statechart becomes the single source of truth for authorization, preventing drift between workflow logic and access control.

• History + concurrency for modal interruption: When a Close button triggers an alert mid-creation, history connectors on each concurrent region independently restore their last sub-state on Cancel. "If the user clicks the Cancel button then the history mechanism is used to return to the last states in state 6" (Chapter 11). Without this, the designer must either lose user progress or manually encode every combination of concurrent sub-states.

Counterpoints

• Partial formalization: Even when a pattern like parameterized alerts offers marginal benefit over a simple if/elsif chain, omitting it from the statechart breaks consistency. "It is bad practice to define only part of the syntax, on the grounds that the rest of it is easy to code directly" (Chapter 8). If some behavior lives in the statechart and some in event handlers, the statechart ceases to be a trustworthy single source of truth for review and testing.

• False independence in concurrency: Concurrent regions require genuinely independent controls. The CD player from Chapter 7 had tightly coupled controls and offered "no opportunity to use concurrent parts" (Chapter 8). Independence is a precondition, not a default assumption.

• UI equivalence vs. domain equivalence: Two domain-distinct states that produce identical widget configurations should be merged in the UI statechart. "When faults with a status of Raised or Not Fixed are displayed in the screen, the user interface objects behave in exactly the same way... Thus the two states can be combined into a single state" (Chapter 11).

Key Quotes

"Having duplicate states in a statechart is something to be avoided at all costs." -- Chapter 8

"The event triggers the transition but it is the condition associated with the event that determines the next state." -- Chapter 8

"When a modal alert message is displayed, the user cannot use any other function within the application until the alert window is closed." -- Chapter 8

"It provides an abstract view of the software which is useful for both reviewing the design and testing the code." -- Chapter 8

"At the point when the user performs the event that causes the above three actions, the next state cannot be determined until the first two actions have been performed." -- Chapter 8

"It is not possible for a user to clear the Project field, it is only possible to select a different project." -- Chapter 11

Rules of Thumb

• If N independent binary controls produce more than N states, apply concurrency (orthogonal regions) to convert 2^N back to N
• If the same state appears twice in a diagram, consolidate immediately using depth + history; the duplicate will force cascading duplication of everything it touches
• If multiple source states share the same event transition, cluster them in a superstate and replace N arrows with one
• If the next state depends on data rather than user action, introduce a transient state with condition-only outgoing arrows
• If a modal dialog can interrupt a concurrent composite state, add history connectors to every orthogonal region to enable clean cancel/resume
• If a hierarchical selection changes upstream, explicitly reset all downstream fields; asymmetric cascades are where bugs hide because developers assume uniform reset behavior
• If two domain states produce identical enabled/disabled widget sets, merge them in the UI statechart regardless of their domain-level distinction

Related References

• core-framework.md -- The event-state-action paradigm and UCM architecture that these patterns operate within
• statechart-notation.md -- Notation for history connectors, orthogonal regions, transient states, and guard conditions used by these patterns
• three-artifact-specification.md -- The screen rules and event-action tables that these patterns generate