State machine model and code generators features:
- State machines are described in a human readable/writable XML format.
- The state machine description must follow the W3C schema file StateMachineDotNet-v1.xsd, StateMachineCpp-v1.xsd or StateMachineJava-v1.xsd
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

- 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

- 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