This section focuses primarily on working with state machine diagrams, while Section Generating Code for State Machines will cover generating code from state machines. Of course, these two aspects are related, so even while "simply drawing" state machine diagrams, you will need to take code generation into account.
QM™ provides extensive support for modern Hierarchical State Machines (HSMs)↑ (UML Statecharts), which are perhaps the most effective and elegant technique of structuring event-driven systems. In fact, QM™ has been specifically designed for ease of diagramming HSMs and for generating efficient, production-quality code from them.
The most important innovation of HSMs over classical finite state machines (FSMs) is the hierarchical state nesting. The value of state nesting lies in avoiding repetitions, which are inevitable in the traditional "flat" FSM formalism and are the main reason for the "state-transition explosion" in FSMs. The semantics of state nesting allow substates to define only the differences of behavior from the superstates, thus promoting sharing and reusing behavior.
In QM™ a State Machine can be associated only with a class that is a direct or indirect subclass of the QP Framework base class QHsm, shown at the top of the class diagram below.
The QAsm base class ([1]
in the class diagram above) provides the basic interface init()
and dispatch()
for initializing a state machine and for dispatching events to it, respectively. The specific implementations of the state machine interface in the QAsm base class and its subclasses, such as QHsm [2]
, QMsm [3]
, QActive [12]
, and QMActive [13]
, determine the state machine implementation strategy that QM™ will apply to generate code.
The QHsm [2]
and QActive [12]
classes from the class diagram above implement the QHsm-based state machines that were originally designed for manual coding of HSMs, but now can also benefit from automatic code generation by QM™ modeling tool.
The screen shot below shows how to select the superclass property of your state-machine/active-object class in the Class Property Sheet, so that it uses the QHsm/QActive
-based state machine implementation strategy:
The main advantage of QHsm-based state machine implementation is that the code is highly readable and human-maintainable, but it requires discovering the transition-sequences (sequences of exit/entry/initial actions) at run-time as opposed to code-generation time. Also, the state nesting in QHsm-based state machines is limited to 5 levels of nesting.
QHsm/QActive
-based state machines to get the highest readability of the generated code at some efficiency cost (compared to the QMsm/QMActive
-based state machines).The QMsm [3]
and QMActive [13]
classes from the class diagram above re-implement the state machine interface and thus provide an alternative QMsm/QMActive-Based State Machines that is more efficient than the QHsm-based strategy, but requires the assistance of the QM™ tool (as an advanced "state machine compiler") to generate the complete transition-sequences at code-generation time. The resulting code is still human-readable, but is not suitable for manual coding or maintaining.
The screen shot below shows how to select the superclass property of your state-machine/active-object class in the Class Property Sheet, so that it uses the QMsm/QMActive-based state machine implementation strategy:
The lab tests indicate that the QMsm/QMActive
-based state machines can be about twice as fast as the QHsm
-based state machines. (This pertains only to the boilerplate structural code for taking state transitions, but does not include application-specific action code, which typically dominates the execution time.) Additionally, the QMsm/QMActive
-based state machines require less runtime support (smaller event processor) and use a bit less stack space for the dispatch()
operation than QHsm/QActive
-based state machines. Also, the state nesting in QMsm-based state machines is no longer limited (nesting levels as high as 10 levels have been tested).
QMsm/QMActive
-based state machines to get the highest performance at slightly less readable generated code.To change state machine implementation strategy, you need to:
When a State Machine diagram is active, the State Machine Toolbox displays a specific collection of tools for adding new shapes to the active State Machine.
The usage of the tools in the State Diagram Toolbox is explained in the sections pertaining to the corresponding state machine elements: