QP/C++  7.3.4
Real-Time Embedded Framework
Loading...
Searching...
No Matches
Static Views

Software Architecture SpecificationDynamic Views

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.

Remarks
In compliance with UML guidelines, the diagrams shown in this section intentionally omit many elements of QP Framework or QP Applications. The presented views contain only selected elements necessary to explain the high-level structure, but without cluttering the diagrams with irrelevant details.

Main Package Diagram

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.

Figure SAS-01: Main QP Framework Package Diagram and Context of Use. Software Architecture Specifications below describe the layers using the labels attached to them in the diagram.

SAS-QA-01_00

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

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.
Note
The main base classes provided in QP Framework are described in greater detail in Figure SAS-02 showing the UML class diagram.
Traceability

SAS-QP-01_02

SAS-QP-01_02
Real-Time Kernel / RTOS

Description
Real-Time Kernel/RTOS layer (Figure SAS-01 [2]) at the bottom provides the execution context for Active Objects as well as other services, such as event queuing or event pools. Since all these services can be supplied in many different ways, the QP specification offers several options in form of built-in kernels as well as 3rd-party RTOS kernels and General-Purpose OS environments.

Note
The built-in kernels allow the QP Framework to run standalone without any 3rd-party RTOS. QP can be also configured (at compile time) to work with many traditional RTOSes and general-purpose OSes (such as Linux, Windows, and macOS).
Traceability

Main Class Diagram

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

Note
The UML class diagram shown in Figure SAS-02 and the following Software Architecture Specifications are the most important view and explanations to understand the architecture of QP Framework and QP Applications.

Figure SAS-02: Core classes in QP Framework. Software Architecture Specifications below describe the classes using the labels attached to them in the diagram.

SAS-QP-02_00

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
  • provide the Event abstraction (SRS-QP-01_00)
  • provide base class for deriving events with parameters (SRS-QP-01_30)
  • provide the event Signal (attribute sig, SRS-QP-01_20)
  • provide the data elements for internal event management in QP (attributes refCtr_ and evtTag_, SRS-QP-01_31)
  • provide base class for Time Events (SRS-QP-06_00)

SAS-QP-02_01

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:
  • 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-02_00)
  • maintain the current state in the state attribute (SRS-QP-02_01)
  • provide generic interface that allows interchangeable state machine implementation strategies (SRS-QP-02_10)
  • provide state machine interface that allows easy access to instance variables (SRS-QP-02_24)

SAS-QP-02_02

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

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

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

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

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

Software Architecture SpecificationDynamic Views