Locking Model ItemsWorking with Statecharts

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.

Hierarchical State Machines in QM

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.

Remarks: The Quantum Leaps Application Note A Crash Course in UML State Machines introduces the main state machine concepts backed up by examples.

Application Note: A Crash Course in UML State Machines; The section Working with Diagrams in the Basic Modeling part describes generic operations applicable to any diagram type, such as opening, closing, scrolling, panning, and zooming a diagram. The section Working with Statecharts describes specific operations applicable to statecharts (UML state diagrams).

State Machine Base Classes

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.

State Machine Classes in QP/C and QP/C++

The QHsm base class 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 QHsm base class and its subclasses, such as QActive, QMsm, and QMActive, determine the state machine implementation strategy that QM™ will apply to generate code.

Remarks: QM™ supports classes and inheritance regardless of the target programming language, which currently can be either C or C++. Key Concept: Object-Oriented Programming in C describes how the QP/C framework as well as the QM™ code generator implement classes and inheritance in portable ISO C.

QHsm-Based State Machines

The QHsm and QActive 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:

Selecting QHsm/QActive base class (superclass)

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.

Remarks: You should consider 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).

QMsm/QMActive-Based State Machines

The QMsm and QMActive classes from the class diagram above re-implement the state machine interface and thus provide an alternative ce_qmsm_strategy 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:

Selecting QMsm/QMActive base class (superclass)

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).

Remarks: You should consider QMsm/QMActive-based state machines to get the highest performance at slightly less readable generated code.

Changing State Machine Implementation

To change state machine implementation strategy, you need to:

Select the superclass in the Property Sheet of your state machine class
Call the right constructor of your state machine class to call the matching base-class constructor, as illustrated in the screen shots below:

Calling the QActive_ctor() in the subclass' constructor in C

Calling the QMActive_ctor() in the subclass' constructor in C++

Attention: The two state machine implementation strategies have been designed to be interchangeable. Specifically, both strategies use the same state machine elements and the same syntax of actions (entry/exit actions to states and actions on transitions), as described in the next section.

State Machine Toolbox

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.

Note: The State Diagram Toolbox is enabled only when a state diagram is the active MDI window and the model is unlocked (). If the Toolbox is invisible, you need to show it in the View->Draw Toolbar menu.

The usage of the tools in the State Diagram Toolbox is explained in the sections pertaining to the corresponding state machine elements:

Locking Model ItemsWorking with Statecharts