Data-Driven Intranet

State Transition User Interface

Back to Welcome Page

Summary

 

Simplified

State-Aware Design?

The entire application can consist of objects. But the user interface is more "state-sensitive" than the non-visual objects. The enabling and disabling of controls and command buttons provide an important visual clue to the user indicating what the available options.

But making it easier and more intuitive for the user usually translates into more complex programming and longer debugging time.

Using state transition analysis can eliminate some of the complexity of handling different combinations of events and states.

State-aware design aims for a close correspondance between the structure of the state transition analysis document and the structure of the program.

 

What is State Transition Analysis?

Identify states, events, procedures and changes to state and show the relationships between them.

What is state?

For each state:

Elements of a State Transition Diagram

There are four elements that usually appear on a State Transition Diagram

States

Events

Transitions

Procedures

 

Escape from diagramming

Diagramming can be very tedious. Diagrams can get very big. MEGO effect. Time spent getting the boxes and lines arranged aesthetically.

But the analysis can be very worthwhile. Impatient people may settle for an alternate way to show the necessary relationships

Text document with three sections

List of States

List of Events

List and description of procedures

State-Event combinations and their associated procedures (including any change of state)

 

Phase 1 - Design

Identify states

Identify the set of events that each state is sensitive to

For each state-event combination, identify the procedure(s) that will be executed. Also identify the change to a new state if applicable.

 

Phase 2 - Code

The structure of the form (or other user-interface) program will be different in the following ways:

  1. States and Events should be clearly identified and distinguished from one another with enumerated constants.
  2. There will be a Central Dispatcher procedure consisting of a nested case statement. The outer case statement will identify the current state of the interface. The second level case statements will identify all the events that that state is sensitive to.
  3. Form event procedures ('Change', 'Click', etc) will do nothing except transfer control to the Central Dispatcher, indicating with a parameter which event took place.
  4. The Central Dispatcher do nothing except transfer control to the proper state-event procedure.
  5. There will be a separate procedure for every state-event combination. These procedure names can include both the state and the event (defined in the enums) for maximum clarity.
  6. The state-event procedures will do all the real work

What you have done is structure your user interface program so that there is a separate procedure for each line (transition) on your state transistion chart. The separate procedures give you maximum flexibility to control exactly what happens during each transition.

1