The behavior of event-driven components (Active Objects, as well as passive event-driven objects) is specified in QP Applications through Hierarchical State Machines (a.k.a. UML statecharts). The main effort of QP Application developers typically goes into elaborating the internal state machines of the various objects in the QP Application. Therefore the description of state machine features and associated requirements is provided early in this SRS document.

State Machine Implementation Strategies

State Machines, and Hierarchical State Machines, in particular, can be implemented in many different ways. A specific way of implementing a state machine will be called here a State Machine Implementation Strategy, and it can be characterized by the following properties:

efficiency in time (CPU cycles)
efficiency in data space (RAM footprint)
efficiency in code space (ROM footprint)
monolithic vs. partitioned with various levels of granularity
maintainability (with manual coding)
maintainability (via automatic code generation)
traceability from design (e.g., state diagram) to code
traceability from code back to design
other, quality attributes (non-functional requirements)

No single State Machine Implementation Strategy can be optimal for all circumstances, and therefore QP Framework shall support multiple and interchangeable strategies (see RQP102).

Dispatching Events to a State Machine in QP Framework

The event processing inside a state machine is called dispatching an event to the state machine, and it requires interaction between the QP Framework and the QP Application:

Event Dispatching to a State Machine in QP Framework

State Machine Specification

The "State Machine Specification" is provided inside the QP Application and is prepared according to the rules defined by the chosen State Machine Implementation Strategy in QP Framework. Typically an implementation strategy represents a state machine as several elements, such as states, transitions, etc.

The "State Machine Specification" can mean state machine code (when the state machine is coded manually) or a state machine model (when the state machine is specified in a modeling tool, like "QM"). Either way, it is highly recommended to think of the state machine implementation as the specification of state machine elements, not merely code. This notion of "specifying" a state machine rather than coding it can be reinforced by selecting an expressive and fully traceable state machine implementation strategy, see RQP103. The advantage of a traceable implementation is that each artifact at all levels of abstraction (design to code) unambiguously represents an element of a state machine.

State Machine Processor

A state machine is executed in QP Framework by the "State Machine Processor" that decides which elements of the "State Machine Specification" to call (see also Inversion of Control). Once called, the chosen part of the "State Machine Specification" executes some actions and returns back to the "State Machine Processor" (QP Framework) with the status information as to what has happened. For example, the returned status might inform the "State Machine Processor" that a state transition needs to be taken, or that the event needs to be propagated to the superstate in the hierarchical state machine.

Run To Completion (RTC) Processing

The "State Machine Processor" is a passive software component that needs to be explicitly called from some control thread to dispatch each event to the given state machine object. The most important restriction is that the dispatch operation must necessarily run to completion (Run-to-Completion processing) before another event can be dispatched to the same state machine object.

Note: RTC event processing does NOT mean that a state machine has to monopolize the CPU until the RTC step is complete. In a multithreading environment, other threads or interrupts (not related to the thread context of the busy state machine) can be running, possibly preempting the currently executing state machine. But after every preemption, the preempted state machine picks up where it left off and continues processing the current event, eventually completing its RTC step.

RTC event processing also means that a state machine should NOT make blocking calls (e.g., a time-delay or semaphore-wait), because every blocking call represents waiting for an event, which will be delivered after the call unblocks. The problem is that such a "backdoor" event is delivered before the original RTC step completes, thus violating the RTC semantics. Blocking inside a state machine also extends the RTC processing and makes the state machine unresponsive to new events.

Requirements

NOTE: This is just a preview of the QP Certification Pack. The list of requirements is provided in the complete document, which can be requested from Quantum Leaps.

EventsActive Objects