State machine model and code generators features:

Here is an example of state machine model:

  • Hierarchical state machine allows to group states together
  • States can be represented as a tree.
  • Each state can have any number of child states.
  • Transitions can then be shared among states.
  • Transition duplication can be eliminated.
  • Avoid the "state explosion" problem.

Below is a simplified version of the pelican crossing hierarchical state machine

HierarchicalStateMachine
  • State machine can hold parallel states also known as regions.
  • Multiple sub state machine react to the same set of events.
  • Each sub state machine evolves on its own.
  • Upon entering a parallel state, the sub state machines enter in their initial state.
  • When every states have reached their final state, the parallel state is left.
  • The parallel state is also left when a transition goes to a state outside the parallel state.

Below is a simplified version of the XMPP login scenario

ConcurrentStateMachine
  • State machines can be either synchronous or asynchronous.
  • Asynchrounous state machine have a queue where events are stored, so that feeding the state machine never blocks the calling thread.
  • Events are processed later, by the calling thread or another thread.
  • A clear separation exists between feeding the events and processing the events.
  • Allow interconnected state machines, the action of a state machine becomes an event for the other state machine and vice-versa.
  • Timers are used for asynchrounous state machine.
  • Each timer have an identifier in order to start and stop it.
  • An event is fired when the timer has expired.
  • Events are sent to state machines through methods of the context generated class.
  • The events method can have any kind and any number of parameters.
  • Every existing class can be an event parameter.
  • Parameters does NOT need to inherit from an "EventBase" class.
  • Observers can be attached to the state machine to report what is happening.
  • Find out when a state is entered and left.
  • Find out when a transition begins and ends.
  • Debugging becomes much easier through logging.
  • Use the provided observers such as ObserverConsole or ObserverTrace.
  • User defined observers can be implemented to accomodate existing logging facility.
  • States eventually have an OnEntry and OnExit method.
  • OnEntry is executed when entering the state.
  • OnExit is executed when leaving the state.
  • Special handling is done during a transition between states in different postion in the state hierarchy.
  • History states allows to remember the current child state.
  • Upon entering back to its parent state, the previously saved state is entered.
  • Visual Studio and Msbuild integration for StateBuilderDotNet.
  • Maven plugin and Ant task integration for StateBuilderJava.
  • Visual Studio, Xcode, CMake and Makefile integration for StateBuilderCpp.
  • Incremental compilation, do not waste time by rebuilding state machine if not necessary.
  • Create new state machine from templates inside Visual Studio