Requirements
Analysis andDesign
Engineering
Southern Methodist UniversityCSE 7313
Module 15 – Modeling techniques – Finite
state machines
Finite state machines
Finite State Machines(FSMs)
• Widely used specification technique• Used to specify system behavior in
response to events• Both output and next state can be
determined solely on the basis of understanding the current state and the event that caused the transition
• H/W engineers have been using FSM for years
Can I interest you in our new long distance service?
Can I interest you in our new long distance service?
No thanks.
Can I interest you in our new long distance service?
Can I interest you in our new long distance service?
Get Lost!!
Can I interest you in our new long distance service?
Get Lost!!
Same stimulus event
Different response
State Machines
• Models how a system responds differently to events over time
State Machines
• Models how a system responds differently to events over time
button switch
States
ON OFF
States
ON OFF
Press
Press
Finite State Machines
• State– the memory of previous events
• Events– inputs to a system
• Actions– output in some form
•mechanical, electrical or software event
Finite State Machines
• State– the memory of previous events
• Events– inputs to a system
• Actions– output in some form
•mechanical, electrical or software event
Coke Machine• Events
– coin insertion• Actions
– coke delivery– coins returned
• State– the memory of how much money
has been deposited
FSM Diagram
State 1 State 2Event-1
Action-k
FSM
State 1 State 2Event-1
Action-k
Event-1
Not all state transitions have actions associated with them
ScenarioQuarters Only, 75 cents• Customer
– enter quarter• Customer
– enter quarter• Customer
– enter quarter• Coke Machine
– deliver coke
Enumerate Events & Actions
Events:E1: Deposit 25 cents
Actions:A1: Deliver coke
Define States
A B
C
Start State
E1
E1E1/A1
States:A: No moneyB: 25 cents enteredC: 50 cents entered
Events:E1: Deposit 25 cents
Actions:A1: Deliver coke
State Transition Table
CurrentState
EventE1
A B
B C
C A/deliver coke
Coke Machine Scenario 2Coin Return
• Customer– enter quarter
• Customer– enter quarter
• Customer– press coin return (CR)
• Coke Machine– return coins
Enumerate Events & Actions
Events:E1: Deposit 25 centsE2: Coin Return (CR)Actions:A1: Deliver cokeA2: Return coins
Define States
A B
C
Start State
E1
E1E1/A1
States:A: No moneyB: 25 cents enteredC: 50 cents entered
Events:E1: Deposit 25 centsE2: Coin Return (CR)Actions:A1: Deliver cokeA2: Return coins
E2/A2
Define States
A B
C
Start State
E1
E1E1/A1
States:A: No moneyB: 25 cents enteredC: 50 cents entered
Events:E1: Deposit 25 centsE2: Coin Return (CR)Actions:A1: Deliver cokeA2: Return coins
E2/A2
E2/A2
Transition Table
• State E1 E2• A B• B C A/coin
return• C A/coke A/coin
return
Transition TableTransition Table
State E1 E2 A B B C A/coin return C A/coke A/coin return
No BlanksAllowed !!
Transition Table
• State E1 E2
• A B A
• B C A/coin return
• C A/coke A/coin return
Telephone System FSMLocal 4-digit exchange
Eventsd: digit dialedh: hang up
Actionsc1: connect to caller
Telephone System FSMLocal 4-digit exchange
A B C D Ed d d d/c1
StatesA: startB: 1 digit dialedC: 2 digits dialedD: 3 digits dialedE: call in progress
Eventsd: digit dialedh: hang up
Actionsc1: connect to caller
Telephone System FSMLocal 4-digit exchange
A B C D Ed d d d/c1
h
StatesA: startB: 1 digit dialedC: 2 digits dialedD: 3 digits dialedE: call in progress
Eventsd: digit dialedh: hang up
Actionsc1: connect to caller
Telephone System FSMLocal 4-digit exchange
A B C D Ed d d d/c1
h
StatesA: startB: 1 digit dialedC: 2 digits dialedD: 3 digits dialedE: call in progress
Eventsd: digit dialedh: hang up
Actionsc1: connect to caller
Problems with FSMs• The state explosion problem• Confusing when too many states• Requirements:
– “in all airborne states, when the yellow handle is pulled, the seat will be ejected”•maps event to large collection of states
– “when the selection button is pressed, enter the selected mode”• implies a clustering or grouping of states
Harel’s State Charts
• Allows grouping or clustering of states
a
b
c
b
c
A
C
B
a
b
c
c
A
C
B
D
Clustering into new superstate D - reallyan abstraction. To be in D really means to be ineither A or C
Coke Machine
E
D F10
A
B
5
10C
5
5
10/coke
5/coke5
Coke Machine
A
B E
D F5
10C
5
10 5
10/coke
5/coke5
CR
CR
CR ouch!
No Money
(A)
Money Entered
No Money
(A)
Money Entered
5
10
CR
No Money
(A)
Money Entered
5
10
CR
B
5 10
C5
First an Example
• Safe with a combination• positions 1, 2, 3• movements L(eft), R(ight)• combinations 1L, 2L, 3L, 1R, 2R,
3R• Combo is 1L, 3R, 2L
– any other combo will set off alarm
Finite State Machine representation of combination safe
Transition Table for FSM
sin(x)
Simple behavior
simple behavior does not depend onthe state or history of the object
State driven behavior can bedivided into several disjoint sets
A television can be in one of manydifferent states (channels)
State machines in software design
• Ease of developmentEase of development; by decomposing the system into a finite number of states the problem is also decomposed.
• Ease of testingEase of testing; state machine representation of software systems allows testing to be done at the state level or at the system level by expanding the state machine concept.
• Simple to understandSimple to understand; the behavior is easily decomposed into non-overlapping behavior.
• Predictable behaviorPredictable behavior; each state is easier to understand than the whole system or object.
Definition of a state
“A state is a distinguishable, disjoint, orthogonal,ontological condition that persists for a significantperiod of time”
- Bruce Powell Douglass, I-Logix
* distinguishable; a state accepts its own set of inputs and has its own set of actions* disjoint; object can only be in one state at a time* orthogonal; states cannot overlap with one another* ontological; condition of existence
Mealy model - outputs associated with transitions
Moore model - outputs associated with states
Meely and Moore Models
input x/output y
input x output y
FSM in summary
• FSM consists of– set of states, J– set of inputs, K– transition function, T
•specifies next state given the current state and the current input
– initial state, S– set of final states, F
Back to the Safe example
• Set of states J is {Safe Locked, A, B, Safe Unlocked, Sound Alarm}
• Set of inputs K {1L, 1R, 2L, 2R, 3L, 3R}
• Transition function T is the transition function
• Initial state S is “Safe Locked”• Set of final states F {Safe
Unlocked, Sound Alarm}
More formally..
• A FSM is a 5-tuple (J, K, T, S, F)– J is a finite, nonempty set of state– K is a finite, nonempty set of
inputs– T is a function from (J ~ F) X K into
J called the transition function– S J in the initial state– F is the set of final states F J
Transitions for a User Interface
current state[menu] and event[option selected] ==> next state
Add a 6th component; set of predicates, P, where each predicateAdd a 6th component; set of predicates, P, where each predicateis a function of the global state of the productis a function of the global state of the product
current state and event and predicate ==> next state
Elevator Example
• Review elevator example in the Schach book (p 346-351)
• EB(e,f) represents the button in elevator e that is pressed to request floor, f
• Two states possible ON or OFF– EBON(e,f): Elevator Button (e,f) ON– EBOFF(e,f): Elevator Button (e,f) OFF
Elevator Example
• Two events involved– EBP(e,f): Elevator Button (e,f)
Pressed– EBF(e,f): Elevator e arrives at
Floor f
STD for Elevator Button
State Transition Rules
• V(e,f): Elevator e is visiting (stopped at) floor f
• No the rule becomes• EBOFF(e,f) and EBP(e,f) and not
V(e,f) => EBON(e,f)• “If the elevator button is off
(current state) and the button is pressed (event) and the elevator e is not visiting the floor (predicate), then the button is turned on”
Floor Buttons • d=direction, f=floor• FBON(d,f): Floor Button(d,f) ON• FBOFF(d,f): Floor Button(d,f) OFF• FBP(d,f):Floor Button(d,f) Pressed• EAF(1..n,f): Elevator 1 or .. or n
Arrives at Floor f– 1..n notes disjunction– P(a, 1..n, b) = P(a,1,b) or P(a,2,b) ..or
P(a,n,b)
Floor Button Predicate
• S(d,e,f): Elevator e is visiting floor f and the direction in which it is about to move is either up (d = U), down (D = D), or no requests are pending (d = N)– this predicate is actually a state– events and states can both be
represented as predicates
Floor Button Transition Rules
• FBOFF(d,f) and FBP(d,f) and not S(D, 1..n, f) => FBON(d,f)
• FBON(d,f) and EAF(1..n, f) and S(d, 1..n, f) => FBOFF(d,f), d = U or D
• “If the floor button at floor f for motion in direction d is off and the button is pushed and none of the elevators are currently visiting floor f about to move in direction d, then the floor button is turned on”
Floor Button Transition Rules
• Conversely,
• “If the button is on and at least one of the elevators arrives at floor f, and the elevator is about to move in direction d, then the button is turned off”
STD for floor button
States for the Elevator
• More complicated behavior• Consists of many sub-states
– elevator slowing and stopping– door opening– door open with timer running– door closing after timeout
States for the Elevator• States to consider• M(d,e,f): Elevator e is moving in
direction d (floor f is next)• S(d,e,f): Elevator e is stopped (at
floor f• W(e,f): Elevator e is waiting at
door f (door closed)• Three stop states (S(U,e,f),
S(N,e,f), S(D,e,f) grouped into one large state
States that trigger transitions
• DC(e,f): Door Closed for elevator e at floor f
• ST(e,f): Sensor Triggered as elevator e nears floor f (controller must decide whether to stop or not at that floor)
• RL: Request Logged (button pressed)
State Transition Rules• Used to make the STD deterministic• Elevator moves up, down, or enters a
wait state, depending on the current state
• S(U,e,f) and DC(e,f) => M(U,e,f+1)– “If the elevator e is stopped at floor f about to go up,
and the doors close, then the elevator will move up toward the next floor”
• S(D,e,f) and DC(e,f) => M(D,e,f-1)– same going down
• S(N,e,f) and DC(e,f) => W(e,f)– same with no requests pending
STD for Elevator
Specification of timing constraint models
• Finite state machines– response-stimulus timing
constraints where the stimulus immediately following the response (with no intervening stimuli or response) are the easiest to represent
– state transition diagram can be used (see next page)
Response time timing constraint in a FSM
Specification of timing constraint models
• Timers (alarms) used when response and stimulus are separated by other responses and stimuli– turn on at specific points and
transition later based on time elapsed in the timer
– works for response-stimulus and stimulus-stimulus constraints
Another response-stimulus timing
constraint in a FSM
Specification of timing constraint models
• Stimulus-response timing constraints with no other intervening stimuli or responses are straightforward
• If more than one timer is needed give them names
Stimulus-Response timing constraint in a
FSM
Another response-stimulus timing
constraint in a FSM
Specification of timing constraint models
• A special type of event called a timeout can be used to model timing constraints– timeout(event,number of time units)– occurs when the given number of time
units has transpired since the event
Response-stimulus timing constraint in Finite State
Machine
End of module 15