Chapter 25 UML State Machine Diagrams and Modeling by undul855

VIEWS: 0 PAGES: 14

									Chapter 25: UML State Machine Diagrams and Modeling
25.1 Introduction
• UML State Machine Diagrams represent Finite State Machines
   (FSM). FSMs have long been used in software development and
   are not a OO technology.
• They can be used in all projects.
• Many notations for FSMs exist: we mostly use UML notation.
• We will only seen basic FSMs here: more complex ones (e.g.
   non-deterministic FSMs) are needed for AI.
• FSMs are good as modeling/documenting tools and map
   relatively easily to code;




                                                             1
25.2 FSM example
• Here is a basic (non-UML) FSM:
                           Monster In Sight


                     Gather
                                              Flee
                    Treasure

                               No Monster



            Monster Dead         Fight               Cornered



• Character AI can be modeled as a sequence of mental states.
• World events can force a change in state.
• The mental model is easy to grasp, even for non-programmers.




                                                                 2
• Another one (non UML):
                                             • States
                                                –   Attack
                                                –   Chase
               Attack
                                                –   Spawn
          ~E
                                                –   Wander
                                 E
           E
                   D                         • Events
                             S                  – E: see an enemy
 Wander                              Chase      – S: hear a sound
               E        ~S                      – D: die
                                 D
          ~E
               Spawn             S
    D




                                                                    3
• UML Notation:




• A state machine diagram shows the lifecycle of an object: what
  events it experiences, its transitions, and the states it is in
  between these events. It need not illustrate every possible event;
  if an event arises that is not represented in the diagram, the event
  is ignored as far as the state machine diagram is concerned.      4
25.3 Definitions
• An event is a significant or noteworthy occurrence. Examples
   …
• A state is the condition of an object at a moment in time.
   Examples …
• A transition is a relationship between two states that indicates
   that when an event occurs, the object moves from the prior state
   to the subsequent state. Examples …

• When the event "off hook" occurs, transition the telephone from
  the "idle" to "active" state.




                                                                  5
25.4 State Machine Diagrams Usages
• Most objects are state independent : their behaviour is not
   dependent on their particular current state. These objects are
   stateless, the notion of state does not make sense for these : no
   need for FSMs for these.
• Some other objects on the other hand behave differently
   depending on some internal state (usually influenced by
   previous events) : consider modeling this behaviour using
   FSMs.
• Guideline : use FSMs illustrated in a UML State Machine
   Diagram for state-dependent objects with complex or undecided
   behaviour.




                                                                   6
• Areas of usages:
   – Complex Reactive Objects:
      • Physical Devices : phones, gamepads(?);
      • Transactions : How does a business object (a sale, order, payment)
         react to an event? For example, what should happen to an Order if a
         cancel event occurs? How does a shopping cart on an e-commerce
         web site reacts to events it receives (add/remove item, change
         quantity etc.), ?
      • AI;
   – Protocols and Legal Sequences:
      • Communication Protocols : TCP, and new protocols, can be easily
         and clearly understood with a state machine diagram. The diagram
         illustrates when operations are legal.
      • GUIs : valid sequences of events can be modelled by FSMs (e.g. in
         view to simplify interactions).
      • Use Case System Operations: e.g. in the Pos case study endSale
         should only come after one or more enterItem operations. Usually,
         the order is trivially obvious, but if complex, a state machine can
         model this, treating the use case itself as an object.
                                                                           7
25.5 Notation
• Transition Actions and Guards
   – A transition can cause an action to fire. In a software implementation, this
     may represent the invocation of a method of the class of the state
     machine diagram.
   – A transition may also have a conditional guard or Boolean test. The
     transition only occurs if the test passes.




                                                                               8
• Nested States
   – A state allows nesting to contain substates; a substate inherits the
     transitions of its superstate (the enclosing state).




                                                                            9
25.6 More Examples




                     10
11
25.7 Implementation Matters
• Simplest Method:
• After an action, the state might   void RunLogic( int *state ) {
  change.                               switch( *state ) {
                                           case 0: //Wander
• Requires a recompile for changes            Wander();
• No pluggable AI                             if( SeeEnemy() )
                                                 *state = 1;
• Not accessible to non-                      if( Dead() )
  programmers                                    *state = 2;
                                              break;
                                           case 1: //Attack
                                              Attack();
                                              *state = 0;
                                              if( Dead() )
                                                 *state = 2;
                                              break;
                                           case 3: //Dead
                                               SlowlyRot()
                                               break;
                                        }


                                                                     12
• Another solution is to implement a State Transition Tables that
  can be queried by an agent at regular intervals, enabling it to
  make any necessary state transitions based on the stimulus it
  receives from the game environment:
     Current State       Event                   State Transition

     Runaway             Safe                    Patrol

     Attack              WeakerThanEnemy         Runaway

     Patrol              Threatened AND          Attack
                         StrongerThanEnemy
     Patrol              Threatened AND          Runaway
                         WeakerThanEnemy

• This can be hardcoded or better, …

                                                                    13
• More Advanced:
   – Data Driven : requires a specific scripting language (e.g. Lua), or basic
     file that is read in at run time.
   – An FSM can be described in text quite easily.
   – Much better flexibility but more work obviously.




                                                                                 14

								
To top