Finite State Machine Patters by yaofenjin

VIEWS: 5 PAGES: 33

									Finite State Machine Patters

       Martti Kuparinen
     martti.kuparinen@iki.fi
                  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!

								
To top