Finite State Machine Patters Martti Kuparinen firstname.lastname@example.org Source Finite State Machine Patterns – Written by Sherif M. Yacoub & Hany H. Ammar – Published in EuroPLoP ’98 Content • Introduction to FSMs • State transitions • Design organization • Output actions • Information hiding • State instantiation Introduction to FSMs • Finite State Machine a.k.a FSM • Used in reactive systems to describe the dynamic behavior of an entity • A limited (=finite) set of states define the complete behavior of the system • Events cause state transitions • Common terms: State, Event, Entity FSM Example (1/2) FSM Example (2/2) Coin Unlocked Failed Coin Pass Pass Failed Broken Locked Fixed Basic FSM (1/4) Context Problem • Entity’s behavior • How to implement the depends on its state system? • State changes according to events • State transitions are determined from entity’s specification Basic FSM (2/4) Forces Solution • Understandability of • Separate the states, the design events, state • Traceability from transitions and actions specification to • Default implementation implementation of • Flexibility and events in the base extensibility class Basic FSM (3/4) State Alarm() CoinMachine Coin() currentState Failed() currentState : State Fixed() Lock() Pass() Thanks() Broken Locked Unlocked Fixed() Coin() Coin() Failed() Failed() Pass() Pass() Basic FSM (4/4) Consequences Related Patterns • Design is • Owner-Driven understandable Transition • Design becomes • State-Driven complex as the Transition number of states increases State Transitions • Two contradicting mechanisms – State-Driven Transition – Owner-Driven Transition State-Driven Transitions (1/4) Context Problem • Need to specify state • How to keep the entity transition mechanism class simple? State-Driven Transitions (2/4) Forces • Reusability of state • Concatenating the classes vs. complexity event processing of entities – Delegate the state – Simple entity transition logic to the implementation current state – Delegate event – One unified event processing to the active processing mechanism state class State-Driven Transitions (3/4) Solution Consequences • Make each state know • Simple CoinMachine its next state implementation • States should initiate • Complex state classes the transition from Related Patterns itself to the next state • Conflicts with Owner- Driven Transition • Factory Method State-Driven Transitions (4/4) State ref : CoinMachine numOfStates : int nextStates : State CoinMachine nextStates currentState setState (n : State) currentState : State setEntity (n : CoinMachine) ref updateState (n : State) * Alarm() Lock() Coin() Pass() Failed() Thanks() Fixed() Broken Locked Unlocked Fixed() Coin() Coin() Failed() Failed() Pass() Pass() Interface Organization (1/3) Problem Forces • How can other • Interface-centric application entities • Simple interfaces vs. communicate with an delegation and state entity? class complexity – Delegate all processing to the state classes – Interface will dispatch events to the states Interface Organization (2/3) Solution Consequences • Use state-driven • Separates interface transition to hide the and implementation actual logic Related Patterns • Distinguish the interface that receives • Motivates to use State- an event Driven Transition • Maintain correct current state Interface Organization (3/3) State ref : CoinMachine numOfStates : int nextStates : State CoinMachine nextStates currentState setState (n : State) currentState : State ref Alarm() Lock() eventHandler (: Event) * Coin() Pass() updateState (n : State) Failed() Thanks() Fixed() Broken Locked Unlocked Fixed() Coin() Coin() Failed() Failed() Pass() Pass() Layered Organization (1/3) Problem Forces • How to make design • Understandability of maintainable, readable design and reusable? • Maintainability – Separate events and actions in different layers Layered Organization (2/3) Structure • Three different layers – Behavior • actions and events • usually an abstract class – Interface – States • describe concrete states Layered Organization (3/3) Actions Events Alarm() Unlock() InOrder() OutOfOrder() Coin() Fixed() Lock() Thanks() Failed() Pass() State CoinMachine nextStates ref : CoinMachine currentState numOfStates : int currentState : State ref nextStates : State eventHandler (: Event) * updateState (n : State) setState (n : State) Broken Locked Unlocked Fixed() Coin() Coin() Failed() Failed() Pass() Pass() Output Actions and FSM Types • When to produce output? • Three different FSM types: – Meally – Moore – Hybrib Meally (1/2) Context Solution • Describe output • States produce the actions and when to output in response to produce them events • Output produced only • Event-State pairs in response to certain events in a particular state Meally (2/2) Coin / ”Thanks” Unlocked Pass / ”” Failed ”Out Of Order” Pass / ”Alarm” Coin / ”” Failed Broken ”Out Of Order” Locked Fixed / ”In Order” Moore (1/3) Context Forces • Output depends only • Avoid code replication on the current state • Maintainability of the design Moore (2/3) Coin Unlocked Lamp OFF Failed Coin Pass Pass Broken Failed Locked Lamp ON Lamp OFF Fixed Moore (3/3) Actions Events Alarm() Unlock() InOrder() OutOfOrder() Coin() Fixed() Lock() Thanks() Failed() Pass() State CoinMachine nextStates ref : CoinMachine currentState numOfStates : int currentState : State ref nextStates : State eventHandler (: Event) * updateState (n : State) setState (n : State) Broken Locked Unlocked locked : State broken : State broken : State unlocked : State locked : State Fixed() Output() Coin() Pass() Coin() Pass() Failed() Output() Failed() Output() Hybrid Context Forces • Some output produced • FSMs can be a in response to events combination of the • Some output produced Meally and Moore in certain states patterns – Meally: state and event – Moore: state only Encapsulation and Exposure • It’s about information hiding vs. direct access to the object • Encapsulated State – Deny direct access • Exposed State – Permit direct access – Not described in this presentation Encapsulated State Problem Solution • How to ensure that no • Keep the state state changes are reference as a private forced on the entity? attribute Forces Related Patterns • State transition should • Conflicts with not be forgeable Exposed State Dynamic State Instantiation (1/2) Context Solution • Large system with • Load the next state, many states unload the current Problem state and update the • How to instantiate the entity’s state upon states? state transition Forces • Limited resources vs. performance Dynamic State Instantiation (2/2) Consequences Related Patterns • Saves resources • Static State • Slower state transition Instantiation • Not applicable for real-time systems! Almost The End • Where do we need state machines? – For example in TCP • The End: It’s time to WAKE UP!
Pages to are hidden for
"Finite State Machine Patters"Please download to view full document