Programming State Machines
Click or drag to resize
StaMaProgramming State Machines

Explains the functionality provided through the StaMa State Machine Controller Library

The main conceptual reference for StaMa is the state chart formalism as described by David Harel. The OMG UML Specification adopted these concepts and is the reference for the terminology used within StaMa.

StaMa provides a subset of the state chart features that seemed both essential and implementable with reasonable effort and complexity.

This section explains how to use StaMa to implement basic state machines and state machines that use the advanced concepts of the state chart formalism.

Basically a state machine is composed of states and transitions between them. Transitions are triggered through events sent to the state machine. Whenever a transition executes, it will leave the current state and enter the target state of the transition, thereby executing (if present) an exit action of the state that is left, a transition specific action and an entry action of the state that is entered.

The following block diagram tries to visualize this.

State Machine Algorithm
Figure 1: The state machine algorithm

One of the fundamental achievements of the state chart formalism is, that it provides a visual notation for many aspects of a state machine that would otherwise only be part of the implementation code.

If the state machine behavior is defined through a state diagram, the first step for implementing the state machine is usually to transform the state diagram structure into code. StaMa supports this by providing a set of methods that bridge the semantic gap between state diagram and implementation code.

The state diagram structure is an immutable description of the behavior of the state machine. The main changing entity of a state machine is the current active state. StaMa separates the immutable state machine structure from the current active active state through the state machine instance concept. Events are delivered to the state machine instance and the state machine algorithm evaluates which actions are to be executed depending on the state machine structure and the current active state.

When an event is delivered to the state machine, the algorithm considers the current active state, checks the transitions outgoing from this state and eventually selects a transition that shall be executed. For this transition the system invokes the exit actions, invokes the transition action, changes the current state to the target state of the transition and invokes the entry action. This algorithm is the fundamental behavior of the state machine and is refined through concepts like composite states, orthogonal regions and fork and join transitions.

Even the simplest useful state machine has multiple states. States are always aggregated within a container named region which also defines the initial state. Regions are also used to convey the concept of nesting states within composite states and the concept of orthogonal sub-regions as defined in the state chart formalism.

The following sub-sections explain the usage of the classes and methods of the StaMa namespace in detail.

Basic Concepts

Understanding the following StaMa concepts is necessary to implement a flat state machine.

Advanced Concepts

The following StaMa concepts are needed to implement a state machine that utilizes composite states and/or orthogonal regions.

Other Hopefully Useful Stuff
References

Below publications explain the general concepts of state machines.

Comparison to the state design pattern

StaMa is not based on the state design pattern. The original state design pattern provides a solution to modify the behavior of methods of an object. It does this by providing a rich interface at the "context" object and all polymorphic subclasses of the state class. The original state design pattern is often reduced to provide a single method that accepts an event and the state subclasses handle the event specific for the current state. The implementation spreads the structural information of the state diagram onto multiple classes which might be less maintainable and readable compared to a condensed code representation through a domain specific language. The state pattern doesn't provide a proposal how to provide the state chart formalism functionality.

See also State Pattern, as described in Erich Gamma; Richard Helm, Ralph Johnson, John M. Vlissides Design Patterns: Elements of Reusable Object-Oriented Software