Static views presented in this section show and explain the compile-time structure of QP Framework and QP Application derived from the framework. The QP Applications used in the diagrams are just generic examples that provide the context necessary to understand the architecture of both QP Framework and the QP Applications.
The UML package diagram shown in Figure SAS-01 provides a high-level view of the context of use and main components of QP Framework and QP Application derived from the framework. The overall architecture is modular and layered. The Software Architecture Specifications following Figure SAS-01 explain the main elements, their function and relationships.
| SAS-QA-01_00 |
|---|
| QP Application |
| Description QP Application layer (Figure SAS-01 [0]) at the top consists of Active Objects and custom Events. QP Application is not a part of QP Framework, but rather is derived from QP Framework. QP Application inherits and specializes the base classes provided in QP Framework. For example, classes ActiveA and ActiveB in the application inherit and specialize the abstract base class QActive. Also, the event classes EventA and EventB in the application inherit the QEvt base classes to add custom event parameters. QP Application also uses services (API) provided by QP Framework. |
Traceability
|
| SAS-QP-01_01 |
|---|
| QP Framework |
| Description QP Framework layer (Figure SAS-01 [1]) right below QP Application provides the base classes to be specialized by the QP Applications. QP Framework also provides the API and runtime environment to execute QP Application on an embedded target.
|
Traceability
|
| SAS-QP-01_02 |
|---|
| Real-Time Kernel / RTOS |
Description |
Traceability
|
The UML class diagram shown in Figure SAS-02 depicts core classes comprising QP Framework and their relation to classes in the QP Application, such as the Fly 'n' Shoot game example application (shown at the bottom of Figure SAS-02).
| SAS-QP-02_00 |
|---|
| QEvt class |
| Description The QEvt class (Figure SAS-02 [0]) 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-02 [10]). |
| Use Case For example, application-level events ObjectPosEvt and ObjectImageEvt (Figure SAS-02 [20]) inherit QEvt and add to it the shown event parameters. |
Responsibilities and Traceability
|
| SAS-QP-02_01 |
|---|
| QAsm abstract base class |
| Description The QAsm class (Figure SAS-02 [1]) is the abstract base class (ABC) for all state machines in QP Framework. This class specifies the abstract state machine interface consisting of:
|
| Use Case As a purely abstract class, QAsm is only used inside QP Framework as the base class for:
|
Responsibilities and Traceability
|
| SAS-QP-02_02 |
|---|
| QHsm class |
| Description The QHsm class (Figure SAS-02 [2]) derived from QAsm implements 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 tool. |
| Traceability |
| SAS-QP-02_03 |
|---|
| QMsm class |
| Description The QMsm class (Figure SAS-02 [3], QM State Machine) derives from QAsm and implements the State Machine Implementation Strategy optimized for automatic code generation. This strategy is more efficient than the one for "manual coding", but is not human-maintainable and requires the use of the QM modeling tool. |
| Traceability |
| SAS-QP-02_10 |
|---|
| QTimeEvt class |
| Description The QTimeEvt class (Figure SAS-02 [10]) represents time events in QP. Time events are special QP events equipped with the notion of time passage. The basic usage model of the time events is as follows. An active object allocates one or more QTimeEvt objects (provides the storage for them). When the active object needs to arrange for a timeout, it arms one of its time events to fire either just once (one-shot) or periodically. Each time event times out independently from the others, so a QP application can make multiple parallel timeout requests (from the same or different active objects). When QP detects that the appropriate moment has arrived, it inserts the time event directly into the recipient's event queue. The recipient then processes the time event just like any other event. |
| SAS-QP-02_12 |
|---|
| QActive class |
| Description The abstract QActive class (Figure SAS-02 [12]) represents an Active Object that uses the QHsm style implementation strategy for state machines. This strategy is tailored to manual coding, but it is also supported by the <QM modeling tool. The resulting code is slower than in the QMsm-style implementation strategy. The game application provides an example of application-level classes deriving from QActive and QHsm (see Figure SAS-02 [6] and Figure SAS-02 [7]). |
| SAS-QP-02_13 |
|---|
| QMActive abstract class |
| Description The abstract QMActive class (Figure SAS-02 [13]) represents an active object that uses the QMsm state machine implementation strategy. This strategy requires the use of the QM modeling tool to generate state machine code automatically, but the code is faster than in the QHsm style implementation strategy and needs less run-time support (smaller event-processor). |