QP/C  7.4.0-rc.2
Real-Time Embedded Framework
Loading...
Searching...
No Matches
Static View: Main Classes

Static View: Layers & InterfacesDynamic View: Startup Sequence

The UML class diagram shown in Figure SAS-CLS (static view) depicts core classes comprising QP Framework and their relation to classes in the QP Application shown at the bottom of Figure SAS-CLS. Because the class diagram is drawn in a traditional way (with base classes on top and derived classes below), the layering in this class diagram is reversed compared to the package diagram in Figure SAS-PKG.

Attention
The UML class diagram shown in Figure SAS-CLS together with the Software-Architecture-Specifications provide the most important view and explanations for understanding the architecture of QP Framework and QP Applications.

Figure SAS-CLS: Core classes in QP Framework and their relation to QP Application.

Architecture Specifications

The following traceable Software-Architecture-Specifications explain the main layers, classes, their responsibilities, and relationships:

SAS-QP-QEP

SAS-QP-QEP
QEP Event Processor layer
Description
The QEP Event Processor layer (Figure SAS-CLS [10]) is a sub-package of QP Framework, which implements Events and State Machines. QEP Event Processor is intentionally separated out to allow QP Applications to directly use just the passive state machines (without Active Objects). QP Applications that use just the QEP Event Processor can still benefit from the QM modeling tool , which can generate code that requires only passive state machines.
Use Cases
For example, QP Application can subclass only the QHsm base class (or QMsm) to implement custom hierarchical state machines. In that case, QP Application might not need the rest of the QP Framework (but instead must execute the passive state machines according to the RTC semantics.) Another use case is for QP Application to subclass QHsm base class (or QMsm) directly to create a passive state machine managed by an Active Objects ("Orthogonal Component").
Responsibilities and Traceability
• provide modular architecture (SRS-QP-NF_03)
• provide layered architecture (SRS-QP-NF_04)

SAS-QP-QEvt

SAS-QP-QEvt
QEvt class
Description
The QEvt class (Figure SAS-CLS [11]) represents events in QP Framework. It can be instantiated directly (concrete class), in which case it represents events without parameters. QP Applications can also inherit and extend QEvt to add custom event parameters. Finally, QEvt is the base class inherited by the QP Time Events (Figure SAS-CLS [10]).
Constraints
To allow QP Framework manage events safely and efficiently, all event instances must be self-contained and must not reference any external memory. Specifically, subclasses of QEvt are not allowed to contain pointers or references to any other objects either directly or indirectly. For example, in C, QEvt subclasses are structs without any pointers (or members with pointers). In modern C++, QEvt subclasses must have "standard layout" with the following constraints:
  • no references or pointers
  • no virtual functions
  • no virtual base classes
  • no non-static data members
  • have the same access control for all members
Use Cases
For example, application-level events EventA and EventB (Figure SAS-CLS [01]) inherit QEvt and add to it the shown event parameters. Another use case is for QP Application to instantiate QEvt class directly to create events without parameters. Such events can often be immutable.
Responsibilities and Traceability
• provide the Event abstraction (SRS-QP-EVT_00)
• provide base class for deriving events with parameters (SRS-QP-EVT_30)
• provide the event signal (attribute sig, SRS-QP-EVT_20)
• provide the data elements for internal event management in QP (attributes refCtr_ and evtTag_, SRS-QP-EVT_31)
• provide base class for Time Events (SRS-QP-TM_00)

SAS-QP-QAsm

SAS-QP-QAsm
QAsm purely abstract base class
Description
The QAsm class (Figure SAS-CLS [12]) is the abstract base class (ABC) for all state machines in QP Framework. The QAsm class specifies the abstract state machine interface.
Interface
  • pure virtual init() operation to initialize a state machine by taking the the top-most initial transition
  • pure virtual dispatch() operation to dispatch events (one at a time) to the state machine (see also Run-to-Completion event processing in a state machine)
Use Case
As a purely abstract class, QAsm is only used inside QP Framework as the base class for:
  • QHsm hierarchical state machine abstract base class
  • QMsm hierarchical state machine abstract base class
  • QActive Active Object abstract base class
Responsibilities and Traceability
• provide state machine abstraction (SRS-QP-SM_00)
• maintain the current state in the state attribute (SRS-QP-SM_01)
• provide generic interface that allows interchangeable state machine implementation strategies (SRS-QP-SM_10)
• provide state machine interface that allows easy access to instance variables (SRS-QP-SM_24)

SAS-QP-QHsm

SAS-QP-QHsm
QHsm abstract base class
Description
The abstract QHsm class (Figure SAS-CLS [13]) derived from QAsm implements the state machine interface init() and dispatch() according to the State Machine Implementation Strategy optimized for manual coding. QHsm provides support for hierarchical nesting of states, entry/exit actions, initial transitions, and transitions to history in any composite state. This class is designed for ease of manual coding, but it is also supported by the QM modeling and code-generation tool .

Use Cases
The QActive class (Figure SAS-CLS [23]) delegates to the QMsm implementation of the state machine interface init() and dispatch() and therefore subclasses of QActive operate according to the State Machine Implementation Strategy optimized for manual coding.

Another use case is for the QP Application to subclass QHsm and create customized, passive state machines (e.g., as "Orthogonal Components" of Active Objects).

Responsibilities and Traceability
• provide State Machine Implementation Strategy optimized for manual coding (SRS-QP-SM_20)
• provide support for hierarchical state machine features specified in SRS-QP-SM_30
→ composite states capable of holding hierarchically nested substates (SRS-QP-SM_31)
→ entry actions to states (SRS-QP-SM_32)
→ exit actions from states (SRS-QP-SM_33)
→ nested initial transitions in composite states (SRS-QP-SM_34)
→ transitions between states at any level of nesting (SRS-QP-SM_35)
→ internal transitions in states (SRS-QP-SM_36)
→ guard conditions to be attached to regular and internal transitions (SRS-QP-SM_37)
→ top-most initial transition (SRS-QP-SM_38)
→ transitions to history (SRS-QP-SM_39)
→ top-state (SRS-QP-SM_40)

SAS-QP-QMsm

SAS-QP-QMsm
QMsm abstract base class
Description
The abstract QMsm class (Figure SAS-CLS [14]) derived from QAsm implements the state machine interface init() and dispatch() according to the State Machine Implementation Strategy optimized for automatic code generation. QMsm provides support for all hierarchical state machine features listed in SRS-QP-SM_20 and sub-requirements plus submachines and submachine states. This class is designed for automatic code generation, and requires the QM modeling and code-generation tool .

Use Cases
The QMActive class (Figure SAS-CLS [24]) delegates to the QMsm implementation of the state machine interface init() and dispatch() and therefore subclasses of QMActive operate according to the State Machine Implementation Strategy optimized for automatic code generation.

Another use case is for the QP Application to subclass QMsm and create customized, passive state machines (e.g., as "Orthogonal Components" of Active Objects).

Responsibilities and Traceability
• provide State Machine Implementation Strategy optimized for automatic code generation (SRS-QP-SM_21)
• provide support for hierarchical state machine features specified in SRS-QP-SM_30
→ composite states capable of holding hierarchically nested substates (SRS-QP-SM_31)
→ entry actions to states (SRS-QP-SM_32)
→ exit actions from states (SRS-QP-SM_33)
→ nested initial transitions in composite states (SRS-QP-SM_34)
→ transitions between states at any level of nesting (SRS-QP-SM_35)
→ internal transitions in states (SRS-QP-SM_36)
→ guard conditions to be attached to regular and internal transitions (SRS-QP-SM_37)
→ top-most initial transition (SRS-QP-SM_38)
→ transitions to shallow and deep histories (SRS-QP-SM_39)
→ top-state (SRS-QP-SM_40)

• provide support for submachines specified in SRS-QP-SM_50
→ multiple submachines (SRS-QP-SM_51)
→ entry points in submachines (SRS-QP-SM_52)
→ exit points in submachines (SRS-QP-SM_53)
→ shallow and deep histories in submachines (SRS-QP-SM_54)
→ submachine states in state machines (SRS-QP-SM_55)
→ exit segments in state machines (SRS-QP-SM_56)

SAS-QP-QF

SAS-QP-QF
QF Active Object Framework layer
Description
The QF Active Object Framework layer (Figure SAS-CLS [20]) is a sub-package of QP Framework, which implements Active Objects and Time Events.
Use Cases
Typical use is for QP Application to subclass Active Object classes from the QF Active Object Framework and specialize them. For example, Active Object Table (Figure SAS-0[03]) inherits QActive, while the Active Object Philo (Figure SAS-0[04]) inherits QMActive. The choice of the superclass corresponds to the choice of the State Machine Implementation strategy. Also, QP Application uses the QTimeEvt class from the QF Active Object Framework to provide timing services to the Philo Active Object.
Responsibilities and Traceability
• provide modular architecture (SRS-QP-NF_03)
• provide layered architecture (SRS-QP-NF_04)

SAS-QP-QTimeEvt

SAS-QP-QTimeEvt
QTimeEvt class
Description
The QTimeEvt class (Figure SAS-CLS [21]) derived from QEvt represents Time Events in QP (sometimes called timers). QTimeEvt can be instantiated directly (concrete class). Upon instantiation QTimeEvt gets associated with a given event signal, clock tick rate, and Active Object instance (owner). A QTimeEvt can be then armed to time out only once (one-shot) or periodically. Several QTimeEvt can time out simultaneously in parallel.
Interface
  • constructor that associates the Time Event with a given event signal, clock tick rate, and Active Object instance (owner). These attributes cannot be changed later.
  • armX() operation to arm the Time Event for one-shot timeout and periodic timeouts.
  • disarm() operation to disarm the Time Event
  • rearm() operation to change the value of one-shot timeout or phasing of periodic timeout.
  • static tick() operation to process one clock tick in all Time Events at a given tick rate.
Use Cases
For example, the application-level Active Object ActiveB owns a QTimeEvt instance to provide timeout events.
Responsibilities and Traceability
• provide support for time events (SRS-QP-TM_00)

SAS-QP-QActive

SAS-QP-QActive
QActive abstract base class
Description
The abstract QActive class (Figure SAS-CLS [23]) is a base class for derivation of concrete Active Objects in the QP Application. QActive encapsulates the unique priority, event-queue, execution context, and state machine for the Active Object. QActive inherits QAsm, which means that an Active Object in QP can be treated as a state machine with the standard interface. QActive implements this interface by delegating to the QHsm state machine implementation.
Interface
  • instantiation
  • start() operation
  • post() operation
  • postLIFO() operation
  • static publish() operation
Use Cases
For example, the application-level Active Object class ActiveA (Figure SAS-CLS [03]) inherits QActive and thus use the QHsm-based state machine implementation strategy.
Responsibilities and Traceability
• provide Active Object abstraction (SRS-QP-AO_00)
• provide the unique priority for each Active Object instance (SRS-QP-AO_10)
• provide second "auxiliary priority" for each Active Object instance (SRS-QP-AO_11)
• provide an event queue for each Active Object instance (SRS-QP-AO_20)
• provide an optional execution context for each Active Object instance (SRS-QP-AO_30)
• encapsulate Active Object internals (SRS-QP-AO_50)
• easily access the internal attributes from inside the Active Object (SRS-QP-AO_51)
• support run-to-completion event processing (SRS-QP-AO_60)
• support for state machines (SRS-QP-AO_70)

SAS-QP-QMActive

SAS-QP-QMActive
QMActive abstract base class
Description
The abstract QMActive class (Figure SAS-CLS [24]) derives from QActive base class, so it inherits all its properties. The only difference is that, QMActive implements the state machine interface by delegating to the QMsm state machine implementation.
Interface
  • instantiation
  • start() operation
  • post() operation
  • postLIFO() operation
  • static publish() operation
Use Cases
For example, the application-level Active Object class ActiveB (Figure SAS-CLS [04]) inherits QMActive and thus use the QMsm-based state machine implementation strategy.
Responsibilities and Traceability
• provide Active Object abstraction (SRS-QP-AO_00)
• provide the unique priority for each Active Object instance (SRS-QP-AO_10)
• provide second "auxiliary priority" for each Active Object instance (SRS-QP-AO_11)
• provide an event queue for each Active Object instance (SRS-QP-AO_20)
• provide an optional execution context for each Active Object instance (SRS-QP-AO_30)
• encapsulate Active Object internals (SRS-QP-AO_50)
• easily access the internal attributes from inside the Active Object (SRS-QP-AO_51)
• support run-to-completion event processing (SRS-QP-AO_60)
• support for state machines (SRS-QP-AO_70)

Static View: Layers & InterfacesDynamic View: Startup Sequence