Finite State Machines

• State
• Extended States
• Guards
• Events
• Actions and Transitions
• Mealy and Moore Automata, Flowcharts
• State Transition Diagrams
• State Transition Tables

State

• Describes a period of time during the life of an object
• Can be characterized in three complimentary ways:
1. As a set of object values that are qualitatively similar in some respect;
2. As a period of time during which an object waits for some event to occur; or
3. As a period of time during which an object performs some ongoing activity.
[UML, p.70]
• Captures history of machine
• Example: Keyboard
  default, capsLocked

Extended States

• Quantitative supplement to machine as extended state variables
• Extended State Machine: Machine with memory
• Example: Keyboard serviceRequired state
1. Entered after 100,000 keystrokes
2. Without extended state variables, model requires 100,000+ states
3. One extended state remembers keystroke count
• Henceforth, assume state machines have extended state variables when needed

Guards

• State Machine reacts to events based on:
• Current (qualitative) state
• Current extended state as represented by values of extended state variables
• A guard is a boolean expression such that state changes or other actions are taken only when evaluates to true
• Guards use extended state variables and possible event_instance parameter values
• Guards should have no side effects
• Design tradeoff: states v guards and extended states
• All ESVs and guards, no states: VB Calculator
• All states, no ESV and guards: 100,000+ state keyboard
• Balance required for good design

Events

• Event = type
  E.g. keystroke is an event (type); pressing the "B" key is an instance of this event.
• Event may have parameters:
  event instance has specific parameter values
  parameter values available to all actions initiated by event
• Event instance life cycle:
  1. Received (queued for processing)
  2. Dispatched (becomes the current event-instance)
  3. Consumed (no longer available)
• Event (instances) trigger actions and transitions

Actions and Transitions

• Actions
1. State Transition (possibly guarded)
2. State Entry Actions (Moore Model)
3. State Exit Actions (Moore Model)
4. State Transition Actions (Mealy Model)
• Mealy and Moore Automata, Flowcharts
1. Mealy: associates actions with state transitions
2. Moore: associates actions with states
3. Activity graph aka flowchart: no triggers, just an unstoppable computational flow

• Execution Model
1. Moore Model - Transition is RTC
2. Concurrency is at the state level, not the substate level

State Transition Specification

• State Transition Diagrams
1. UML Statecharts = graphical language
2. UML Statecharts require text with graphics
• State Transition Tables
1. HSM = textual language
2. Table of actions (State x Event)
3. Usually clearer with accompanying diagram

FSM Example: Nagging Keyboard

States	Pseudostates	Events
default capsLocked serviceRequired	keystroke_count	ANY_KEY CAPS_LOCK
Actions ANY_KEY triggers actions by default: increment keystroke_count; if (keystroke_count > 100000) then transition to serviceRequired; ANY_KEY triggers actions by capsLocked: increment keystroke_count; if (keystroke_count > 100000) then transition to serviceRequired; ANY_KEY triggers actions by serviceRequired: increment keystroke_count CAPS_LOCK triggers action by default: transition to capsLocked CAPS_LOCK triggers action by capsLocked: transition to default

Nagging Keyboard State Transition Table (FSM Model)

	Events
States	ANY_KEY	CAPS_LOCK
default	increment keystroke_count; if (keystroke_count > 100000) then transition to serviceRequired;	transition to capsLocked
capsLocked	increment keystroke_count; if (keystroke_count > 100000) then transition to serviceRequired;	transition to default
serviceRequired	increment keystroke_count; send message to user

Hierarchical State Machines

FSM, plus:

• Hierarchical States
• Behavioral inheritance
• Orthogonal Regions
• Entry and Exit Actions
• Transition Execution Sequence
• Internal Transitions
• Self Transitions
• Pseudostates - graphical notations
• Event Base Types
• Discuss HSM again in context of OMG UML Specification

Hierarchical States

• Top state
• Superstate/Substate
• is_in relationship
• Behavioral inheritance
• Re-use of behavior
• Programming by difference

Orthogonal Regions

• xor normally applies to states: system is in exactly one state
• When and is needed, use orthogonal regions, essentially like two HSMs that exist simultaneously

Entry and Exit Actions

• Use Moore model
• Actions that are executed on entering/exiting the state
• toaster::heating state exit action: turn off burners

Transition Execution Sequence

• Least Common Ancester (LCA) of two states S1 and S2 is lowest state in the hierarchy that is a superstate of both S1 and S2
• Action sequence for transition from S1 to S2:
1. Starting with S1, peform exit actions for states along the ascending path to state LCA(S1,S2);
   includes S1 but excludes LCA(S1,S2)
2. Starting with LCA(S1,S2), perform entry actions for states along the path to state S2;
   excludes LCA(S1,S2) but includes S2
• Note that the state LCA(S1,S2) is neither exited nor entered during the transition S1 -> S2

Internal and Self Transitions

• Internal Transitions
• Actions triggered by an event with no state change
• Distinct from exit/entry actions
• E.g. increment keystroke_count
• Self Transitions
• State is exited and entered
• Triggers exit and entry actions of state

Pseudostates - graphical notations

• initial (pseudo)state
• terminal (pseudo)state
• shallow history (pseudo)state: most recent active child state of its containing state
• deep history (pseudo)state: most recently active descendant state of its containing state
• join: merges transitions emanating from orthogonal regions
• fork: splits an incoming transition into orthogonal regions
• junction: semantics-free vertex chaining together multiple transitions (used to merge or split). When used to split, implies static conditional branching using guards.
• choice: dynamic conditional branching of state transitions

Event Base Types

• SignalEvent: represents reception of a particular (asynchronous) signal
  SIGNAL_NAME ( parameter list )
• TimeEvent: models expiration of a deadline
  after [expression specifying amount of time]
• CallEvent: request to synchronously invoke a specified operation
  OPERATION_NAME( parameter list )
• ChangeEvent: models an event that occures when a specied boolean expression becomes true
  when [boolean expression]
• Polymorphic event triggering

Discuss HSM again in context of OMG UML Specification

HSM Example: Keyboard

State Hierarchy	Pseudostates	Events	Actions
keyboard   default   capsLocked   serviceRequired	keystroke_count	ANY_KEY CAPS_LOCK	ANY_KEY triggers action by keyboard: increment keystroke_count if (keystroke_count > 100000) then transition to serviceRequired CAPS_LOCK triggers action by default: transition to capsLocked CAPS_LOCK triggers action by capsLocked: transition to default

Nagging Keyborad Statechart

Nagging Keyboard State Transition Table

		Events
State	Parent	ANY_KEY	CAPS_LOCK
keyboard		increment keystroke_count; if (keystroke_count > 100000) then transition to serviceRequired;
default	keyboard		transition to capsLocked
capsLocked	keyboard		transition to default
serviceRequired	keyboard	send message to user (could be entry action)

HSM Example: Toaster Oven

State Hierarchy	Events	Actions
heating   toasting   baking doorOpen	OPEN_DOOR	OPEN_DOOR triggers action by heating: transition to doorOpen state heating exit action: turn heating elements off

HSM Example: C Comment Parser

As FSM:	As HSM:

HSM Example: Quantum Calculator

Primary Use Case

Oops: Need to display result

Add State result

EQUALS triggers transition to state result (Entry action displays result on screen) CLEAR triggers transition to operand1 (Entry action resets all pseudostate.) 0..9,POINT triggers transition to operand1 (use event paremeter to initialize operand1 pseudostate) OPER triggers transition to opEntered (use result as operand1 pseudostate)

Add CANCEL transition to other states

Naively to each state Using behavioral inheritance

Internal submachines for operand1,2

state zero ignores multiple entries of 0 state int parses integral (pre-decimal point) part of entry state frac parses fractional (post-decimal point) part of entry

Handling negation (unary MINUS)
Only two cases where MINUS represents negation:

From state opEntered: new state negated2 entered conditionally from opEntered From the beginning of a computation: new state begin representing a new computation without prior input Integrate new states into previous version