Designing from State Transition Models

1
Designing from State Transition Models

• Quick Review of Behavior Models
• Variations on a Theme
• An Example Behavior Model
• A Suggested Strategy
• Designing the Basic Structure
• Designing Event and Transition Logic
• Designing Responses to Invalid Events
• Designing Transition Actions
• Designing State Actions

2
Quick Review of Behavior Models

• Recall from UML state modeling

• Remember that actions may be on transitions
  and/or actions may be on states
• Initial state identifies the state of the model
  when it is created or started and Final state
  identifies the state(s) of the model when it stops

3
Variations on a Theme

• Are instances of the model created and deleted
  or do they always exist?
• Is the model designed as a single module or as
  an information cluster (a set of modules)?
• Is the models module a client of, or a server
  to, the event recognizer module(s)?
• Is the model designed as a hard-coded algorithm
  or as a table-driven interpreter?
• How should the model handle invalid events?-
• - Ignore them and wait for valid events?
• - Stop where it is?
• - Go to an error state and stop?

4
An Example Behavior Model
5
A Suggested Strategy

• 1) Design the basic structure
• 2) Design event and transition logic
• 3) Design responses to invalid events
• 4) Design transition actions
• 5) Design state actions, if any
• 6) Optimize
• reduce to equivalent, but simpler logic
  (hard-coded)

6
Designing the Basic Structure

• Representing states and events
• - enumerate the states
• - enumerate the events
• - define a CurrentState variable
• Representing initial and final states
• - set the initial state on entry
• - identify final state(s), if any for exit
• Abstract example of basic structure
• module ExampleOfBasicStructure
• type
• States ( State1, State2, , StateN )
• Events ( Event1, Event2, , EventM )
• var
• CurrentState States

7
Example of Basic Structure

• Use the Cruise Controller as a single,
  hard-coded client module (other versions will be
  shown later)

module SingleModuleAsClientVersion type
States ( DriverControl, Cruising, Accelerating
) Events ( Engage, Resume, Accelerate,
EndAccelerate, Brake) var CurrentState
States begin CurrentState DriverControl
repeat Handling events and transitions
goes here until NationalDebt 0 end
8
Designing Event and Transition Logic

• Handling events
• - Call function NextEvent to obtain the next
  event
• for now, NextEvent blocks
• - Use CASE logic to dispatch the next event
• Begin
• CurrentState InitialState
• repeat
• case NextEvent of
• Event1 handle transitions for event
  based on state
• Event2 handle transitions for event
  based on state
• EventN handle transitions for event
  based on state
• until CurrentState FinalState
• end
• Handling transitions based on state
• Use CASE logic to decide when to transition based
  on event and current state
• identify invalid state/event combinations

9
Event and Transition Logic, Example

• module SingleModuleAsClientVersion
• type
• States ( DriverControl, Cruising, Accelerating
  )
• Events ( Engage, Resume, Accelerate,
  EndAccelerate, Brake )
• var
• CurrentState States
• begin
• CurrentState DriverControl
• repeat
• case NextEvent of
• Engage
• case CurrentState of
• DriverControl do transition actions
  
• CurrentState
  Cruising
• Cruising invalid
• Accelerating invalid

10
Designing Responses to Invalid Events

• Decide how the module should handle invalid
  events
• - Ignore and wait for valid events
• - Stop where you are
• - Go to an error state and stop
• - Report as errors
• We will just continue to ignore invalid events
  for the Cruise Control example

11
Designing Transition Actions

• Insert procedure calls to modules handling
  transition actions (or, in-line the code) where
  appropriate, e.g.,
• module SingleModuleAsClientVersion
• type
• States ( DriverControl, Cruising, Accelerating
  )
• Events ( Engage, Resume, Accelerate,
  EndAccelerate, Brake )
• var
• CurrentState States
• DesiredSpeed integer
• begin
• CurrentState DriverControl
• repeat
• case NextEvent of
• Engage
• case CurrentState of
• DriverControl DesiredSpeed
  SpeedFromSpeedometer
• CurrentState Cruising

12
Designing State Actions

• Do this step only when required by the behavior
  model
• otherwise it adds unnecessary complexity
• Function NextEvent must become non-blocking,
  returning immediately if no next event is present
• Type Events needs a new possibility None to
  allow for the immediate return from NextEvent
  without a valid event (only for strongly-typed
  languages)
• Events ( Event1, Event2, , EventN, None )
• Add a no valid next event alternative to the
  event dispatch logic (if required by the
  language) and add in a section to handle state
  actions
• begin
• CurrentState InitialState
• repeat
• case NextEvent of
• Event1 handle transitions for event
  based on state
• Event2 handle transitions for event
  based on state
• EventN handle transitions for event
  based on state
• None Do Nothing
• case CurrentState of
• State1 Do state actions for this state

13
Example of State Actions

• module SingleModuleAsClientVersion
• type
• States ( DriverControl, Cruising, Accelerating
  )
• Events ( Engage, Resume, Accelerate,
  EndAccelerate, Brake, None )
• var
• CurrentState States
• DesiredSpeed integer
• begin
• CurrentState DriverControl
• repeat
• case NextEvent of
• Engage
• case CurrentState of
• DriverControl DesiredSpeed
  SpeedFromSpeedometer
• CurrentState Cruising
• Cruising invalid

14
Optimizing

• Reduce event/transition logic down to simpler
  if-then-else constructs as appropriate
• module SingleModuleAsClientVersion
• type
• States ( DriverControl, Cruising, Accelerating
  )
• Events ( Engage, Resume, Accelerate,
  EndAccelerate, Brake, None )
• var
• CurrentState States
• DesiredSpeed integer
• begin
• CurrentState DriverControl
• repeat
• case NextEvent of
• Engage
• if CurrentState DriverControl
• then DesiredSpeed SpeedFromSpeedometer
  

15
Designing as an Information Cluster

• The module becomes a server
• - Client determines and dispatches the next event
  by calling separate event-responder modules
• Break the module into sections
• - An initializing procedure to set the initial
  state
• - One procedure to handle each event
• - A procedure (or task) to perform the state
  actions
• only if required by the original model
• if using a task, start it in the
  initializer

16
Example Information Cluster

• module InfoClusterVersion
• type
• States ( DriverControl, Cruising, Accelerating
  )
• Events ( Engage, Resume, Accelerate,
  EndAccelerate, Brake )
• var
• CurrentState States
• DesiredSpeed integer
• procedure Initialize
• begin
• CurrentState DriverControl
• end
• procedure Engage
• begin
• if CurrentState DriverControl
• the DesiredSpeed SpeedFromSpeedometer
• CurrentState Cruising

17
Designing as a Table Driven Interpreter

• Initial assumptions
• - The language offers a procedure pointer
  mechanism to allow table references to procedures
  implementing the different actions
• - Issues about passing parameters to/from the
  action procedures can be solved
• Some mechanism exists to initialize the table
• Basic skeleton
• module TableDrivenDesign
• type
• States ( list valid states here, None )
• Events ( list valid events here, None )
• ActionList some magic references to action
  modules
• TransitionEntry record
• NextState States
• TransitionActionListActionL
  ist
• var
• CurrentState States
• NextEvent Events

18
Table Driven Design (cont)

• Handling transitions
• begin
• CurrentState Initial State
• repeat
• GetNextEvent (NextEvent)
• if NextEvent ltgt None
• then if TransitionsCurrentState,NextEvent.
  NextState
• 
  ltgt None
• then make the transition
• Perform one pass of the state-action
  processing
• until CurrentState is a final state
• end
• Making transitions
• begin
• CurrentState Initial State
• repeat
• GetNextEvent (NextEvent)
• if NextEvent ltgt None
• then if TransitionsCurrentState,NextEvent.
  NextState ltgt None

19
Example of Table-Driven Design

• Transitions table for the Cruise Controller
• - State dimension down- Event dimension across
• - TransitionActionList in parens ()
• StateActionTable for the Cruise Controller
• Note that the interpreter code is virtually
  identical for all behavior models, regardless of
  size and complexity

20
Lex and YACC

• Lex and YACC are compiler tools available on
  Unix and some other platforms
• Finite Automata and Regular Languages are
  equivalent
• - Regular languages are usually expressed in BNF
• - State-transition models can be
  expressed in BNF
• DriverControl Cruising Brake
• DriverControl Accelerating Brake
• Cruising DriverControl Cruise
• Cruising DriverControl Resume
• Accelerating Cruising Accelerate
• Cruising Accelerating EndAccelerate
• Lex (lexical analyzer) uses BNF as input and
  generates a module that converts incoming
  character streams into language tokens
• - The Lex-generated module plays the role of
  GetNextEvent in our discussion
• YACC (Yet Another Compiler Compiler) uses BNF
  as input and 1) generates a transition table as
  we discussed and 2) appends the interpreter to
  the transition table (does not allow state
  actions)
• So what???

21
References for More Information

• W. A. Wulf M. Shaw P. N. Hilfinger L. Flon,
  Fundamental Structures of Computer Science,
  Addison-Wesley, 1981
• Alan Cline, Building Applications Faster with
  State Transition Automatons, The C Users
  Journal, December, 1992
• Many Finite Automata books discuss how to
  implement state-transition models
• Daniel A. Cohen, Introduction to Computer Theory,
  Revised Edition, Wiley, 1991 has a discussion of
  regular languages, finite automata theory, and
  their equivalence
• Many compiler design books discuss Lex and
  YACC-like approaches
• Any documentation on Lex and YACC or Lex- and
  YACC-like systems

22
Summary of Designing from Behavior

• Quick Review of Behavior Models
• Variations on a Theme
• An Example Behavior Model
• A Suggested Strategy
• Designing the Basic Structure
• Designing Event and Transition Logic
• Designing Responses to Invalid Events
• Designing Transition Actions
• Designing State Actions
• Optimizing