Real-Time Embedded Framework
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 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:
No single State Machine Implementation Strategy can be optimal for all circumstances, and therefore QP Framework shall support multiple and interchangeable strategies (see RQP102).
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:
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.
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.
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: 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.