OCUP2F 08 State Machine Diagram

Module 8. State Machine Diagram⌘

State Machine Diagram⌘

• State machine diagram is a behavior diagram which shows discrete event-driven behavior of a part of designed system through finite state transitions.
• State machine diagrams can also be used to express the valid interaction sequences (protocols) for parts of a system.
• Two kinds of state machines:
  • behavior state machine,
  • protocol state machine.

Behavior State Machine⌘

Vertex⌘

• Vertex is named element which is an abstraction of a node (State or Pseudostate) in a state machine graph.
• It can be the source or destination of any number of transitions.

State⌘

• State models a situation during which some invariant condition holds.
• In most cases this condition is not explicitly defined.
• Kinds of States:
  • Simple State (has no internal vertices or transitions)
  • Composite State (contains at least one region)
  • Submachine State (refers to an entire State Machine)

Transition⌘

• Directed relationship between a source vertex and a target vertex.
• Syntax: [<trigger> [‘,’ <trigger>]* [‘[‘ <guard>’]’] [‘/’ <behavior-expression>]]
  • trigger specifies events that may cause state transition,
    • SignalEvent triggers and CallEvent triggers are not distinguishable by syntax
  • guard is a boolean expression,
  • optional behavior-expression is an expression specifying the effect (is executed when the transition fires)

Transition Kind⌘

The semantics of a Transition depend on its relationship to its source Vertex:

• external - transition exits its source vertex (executes exit action of source state)
• local - transition does not exit its containing State (exit action of the containing state will not be executed)
  • Target vertex may be different from its source Vertex.
  • Local transition can only exist within a composite State.
• internal is a special case of a local transition with the same source and target states,
  • the state is never exited (and not re-entered)
  • no exit or entry actions are executed

Internal Transition example⌘

source: wikipedia.org

Internal Behaviors⌘

• syntax: <behavior-type-label> ['/' <behavior-expression>]
• entry - a Behavior which is performed upon entry to the State (entry Behavior).
• do - starts execution when the State is entered, (but only after the State entry Behavior has completed) and executes concurrently with any other Behaviors that may be associated with the State, until:
  • it completes (in which case a completion event is generated) or
  • the State is exited, in which case execution of the doActivity Behavior is aborted.
• exit - a Behavior that is performed upon exit from the State (exit Behavior).

Completion Transitions, completion events⌘

• Completion transition has an implicit trigger (may have a guard).
• Completion event enables this trigger if all actions associated with the source state have completed execution:
  • In simple states: a completion event is generated when the associated entry and doActivity actions have completed executing.
  • In composite or submachine states: a completion event is generated when:
    • all internal activities have completed execution, and
    • if the state is a composite state, all its orthogonal regions have reached a final state, or
    • if the State is a submachine State, the submachine State Machine execution has reached a final state.

Pseudo State⌘

• Pseudostate is an abstract vertex that describes different types of transient vertices in the state machine graph.
• Pseudostates are transitive - a compound transition execution simply passes through them, arriving on an incoming Transition and leaving on an outgoing Transition without pause.

Initial ⌘

• Initial Pseudostate represents a starting point for a Region.
• It is the source for at most one Transition, which may have an associated effect Behavior, but not an associated trigger or guard.
• There can be at most one initial Vertex in a Region.

Choice⌘

• Choice is used to realize a dynamic conditional branch.
• It allows splitting of compound transitions into multiple alternative paths.
• The decision on which path to take may depend on the results of Behavior executions performed in the same compound transition prior to reaching the choice point.
• If more than one guard evaluates to true, one of the corresponding Transitions is selected.
• If none of the guards evaluates to true, then the model is considered ill formed

Junction ⌘

• Junction can be used to merge multiple incoming Transitions into a single outgoing Transition or,
• it can be used to split an incoming Transition into multiple outgoing Transition segments with different guard Constraints.
• Such guard Constraints are evaluated before any compound transition containing this Pseudostate is executed, which is why this is referred to as a static conditional branch.

Static Conditional Branch⌘

Final State⌘

• Final State is a special kind of State (not Pseudo State) signifying that the enclosing Region has completed.
• Transition to a Final State represents the completion of the behaviors of the Region containing the Final State.

Event Processing for State Machines⌘

The run-to-completion paradigm (in general)

• State Machine will perform its initialization during which it executes an initial transition, after which it enters a wait point.
• A wait point is represented by a stable state configuration. It remains thus until an Event stored in its event pool is dispatched.
• This Event is evaluated and a single State Machine step is executed.
• A step involves executing a transition and terminating on a stable state configuration (i.e., the next wait point).
• This cycle then repeats until the State Machine completes its Behavior.
• Event occurrences are detected, dispatched, and processed by the State Machine execution, one at a time.

Transition Execution Algorithm⌘