Constructing the User Interface with Statecharts

Design before code: Create a statechart specification for every screen before writing event handlers
Event-state-action, not event-action: The correct action depends on both the event AND the current state
UCM architecture: Separate UI objects (presentation), Control objects (statechart behavior), Model objects (domain logic)
Three-artifact specification: Every screen needs a statechart diagram + event-action table + state-item table
No conditionals in state procedures: If you need an if-statement, your statechart is incomplete

Situation	Do This	Avoid This
Same button does different things in different contexts	Model each context as a distinct state	Nest conditionals in the event handler
N independent concerns on one screen	Use N orthogonal regions (N+M states)	Flat state machine (NxM state explosion)
Cancel/undo needs to restore previous state	Use history connector (H or H*)	Enumerate every possible return path
Screen config depends on database values	Use transient states for routing	Procedural if/else outside the statechart
Multiple guards could fire on same event	Add event priorities [1], [2]	Hope guards are mutually exclusive
Alert dialog needed from many states	Use parameterized alert state	Duplicate the alert in every source state
Fields enable/disable based on parent selection	Cascading enablement with orthogonal regions	Scattered boolean flags in event handlers
Unsure if design is complete	Run 4 design tests before coding	Discover gaps during testing or production

"There is no design phase... UI code is patched and tweaked from initial implementation to final delivery." — Ian Horrocks, Chapter 1

Overview