Key Principle
Each case study demonstrates the same design discipline applied to a different domain: identify states from requirements (not from visual layout), refine the statechart iteratively, and let the structure enforce correctness rather than relying on exhaustive runtime checks. The calculator proves that iterative refinement absorbs new requirements without restructuring. The fault reporter proves that mode discovery collapses combinatorial role-status complexity. The student database proves that decomposition into per-screen statecharts enables parallel development. Together they establish that statechart design is a repeatable, scalable process -- not a one-off technique.
Why This Matters
These case studies convert abstract statechart principles into concrete, auditable design decisions. The calculator redesign eliminates ten catalogued bugs from its bottom-up predecessor by making invalid actions structurally impossible. The fault reporter tames a multi-role workflow with dozens of UI elements by collapsing per-element rules into six discrete screen modes. The student database shows how to partition a multi-screen CRUD application so that developers can work on separate screens simultaneously. The transferable lesson across all three: the statechart is not documentation written after coding -- it is the primary design artifact that prevents bugs before code exists.
Good Examples
Iterative refinement (calculator): Starting from a four-state happy path, the calculator statechart grows to nine states across five iterations, each adding a localized extension (negative numbers, chained operations, division-by-zero, cancel, cancel-entry) without restructuring prior states. "The aim will be to create an application that is easy to understand, easy to enhance and does not contain errors such as those listed in Appendix A" (Chapter 10).
Semantic overloading resolved by state context (calculator): The minus button means "negative sign" before an operand but "subtraction" after one. Dedicated Negative Number states resolve this structurally: "if the minus button is selected in state 4 then this indicates that a negative number is about to be entered and not that the operator has been changed" (Chapter 10). No conditional logic in button handlers is needed.
Hierarchy for global behaviors (calculator): Cancel is a single transition on the outermost state boundary, active from every sub-state. "An arrow attached to the outermost state will model this behaviour" (Chapter 10). Any future state added inside the boundary inherits Cancel automatically -- a structural guarantee, not a convention.
Mode discovery (fault reporter): Role-plus-status combinations partition all field-level rules into five productive modes and one Read Only catch-all, collapsing dozens of individual enable/disable rules into six statechart states. "It is important to identify modes because they often act as the high-level states in a design" (Chapter 11).
Transient state routing (fault reporter): A transient state centralizes mode selection with prioritized guard conditions, ensuring Read Only is entered only as a last resort. "The event arrows leaving the transient state are prioritized to ensure that the Read Only state is only entered as a last resort" (Chapter 11).
Creation joins viewing (fault reporter): After creating a fault report, the screen behaves identically to viewing one with status Raised. The Create path leads into the View superstate, eliminating duplicate mode states. "After a user clicks the Create button, the screen behaves as if the user has just selected an existing FR in the main screen and clicked the View button" (Chapter 11).
Per-screen decomposition (student database): Each screen gets its own statechart; a high-level statechart defines only inter-screen navigation. "This is an important part of the technique because it allows a number of developers to work simultaneously on different parts of the same user interface" (Chapter 12).
Close-with-unsaved-changes archetype (student database): Three explicit states -- No Changes Made, Changes Made, and Alert -- cover all Close paths. Save commits then closes; Don't Save rolls back then closes; Cancel returns to editing. An orthogonal region tracks change status independently of the main editing workflow (Chapter 12).
Counterpoints
Visual similarity does not imply behavioral similarity: A screen in the student database resembles one from the fault reporter, yet "the behaviour of the screen and the design of the underlying statechart are considerably different" (Chapter 12). Always derive statechart structure from requirements, never from the appearance of another screen.
Scope boundary -- exclude default widget behavior: Standard UI behaviors (tab switching, list scrolling) are excluded from the statechart. "The statechart that will be designed to control the Details screen does not have to control the behaviour of the tab-card object" (Chapter 12). Model only application-specific behavior; including framework defaults bloats the chart without adding correctness.
Keep volatile business rules outside the code: The GCSE entry standard for enrolment is deliberately not enforced by software: "Currently five grade C's including Maths and English - but this should not be imposed by the software" (Chapter 12). Threshold rules subject to policy changes belong in configuration, not in statechart transitions.
Key Quotes
"The application will be made easier to use because it will only allow a user to perform valid events at any given time." -- Chapter 10
"It is important to identify modes because they often act as the high-level states in a design." -- Chapter 11
"The starting point with any statechart design is to identify the top-level states. In most cases, these correspond to the main screens in the application." -- Chapter 12
"Despite the similarity of the screen layout, the behaviour of the screen and the design of the underlying statechart are considerably different." -- Chapter 12
"Any changes made to the student records using the Edit, New or Delete buttons are not permanent changes to the underlying database until they have been explicitly saved." -- Chapter 12
Rules of Thumb
- When a single UI control has different meanings depending on context, create distinct states for each meaning rather than adding conditional logic to the handler
- When behavior varies by user role and entity status, look for mode groupings that collapse the role-status matrix into a small number of discrete states
- When multiple entry paths converge on identical post-entry behavior, merge them into a single superstate rather than duplicating state clusters
- When designing a multi-screen application, define inter-screen navigation first, then design each screen's statechart independently
- When a screen supports deferred commits, add an orthogonal region to track the changes-pending dimension -- the Close button's behavior depends on it
- When classifying UI elements for statechart modeling, separate constant-behavior items (set once at initialization) from varying-behavior items (state-dependent); only the latter enter the statechart
- When validation rules are mandatory, document the business purpose behind each one so future maintainers can evaluate whether the constraint still applies
Related References
core-framework.md-- The event-state-action paradigm underlying all three case studiesstandard-patterns.md-- Transient states, history connectors, and parameterized alerts applied extensively in the fault reporter and student databasestatechart-notation.md-- Guard conditions, priority annotations, and hierarchy notation used across all three case studiesthree-artifact-specification.md-- Screen rules and event-action tables that each case study produces as design artifactsdesign-heuristics.md-- Mode discovery and iterative refinement as general design methods