QP/C++  8.0.0
Real-Time Embedded Framework
Loading...
Searching...
No Matches
Context Viewpoint

Technology ViewpointResource Viewpoint

The Context Viewpoint provides a "black box" perspective on the architecture subject (QP/C++ Framework in this case) in the surrounding context (QP/C++ Application and underlying Operating System). The views within this viewpoint identify the stratification of services (layers) and the interfaces between the layers. The Context Viewpoint frames the following concerns:

  • context of the architecture subject
  • functional decomposition of the system into layers
  • interfaces between the layers

The model kind used to illustrate the Context Viewpoint is the UML package diagram Figure SAS-CTXT (static view). It shows the QP/C++ Framework in the context of other software elements. The architecture is layered with clearly defined interfaces. As required in a truly layered architecture, the dependencies between layers point in one direction only (from higher-level to lower-level layers).

Figure SAS-CTXT: Context of use with layers and QP/C++ Framework interfaces.
Remarks
In compliance with the UML conventions, the diagrams shown in this section intentionally omit many elements of QP/C++ Framework or QP/C++ Applications. The presented views contain only selected elements necessary to explain the high-level structure, but without cluttering the diagrams with irrelevant details.
Note
QP/C++ Framework classes, their responsibilities, and relationships are described in the Structural View in Software Design Specification.

Layer View

The Layers View explains the QP/C++ Framework context in terms of distinct layers and their relationships. The objectives of the Layer View are:

  • simplification of the interactions inside the system because a software layer can only interact with the layer immediately below.
  • promote modularity by encapsulating functionalities within layers. This makes it easier to manage, test, and update individual parts of the system without affecting others.
  • enhance scalability by allowing layers to be scaled independently.
  • encourage reusability of components within and across projects. For example well-defined QP/C++ Application layer can be reused in different contexts (e.g., with different operating system or different target hardware), saving development time and effort.
  • improve maintainability by isolating changes to specific layers. This reduces the risk of unintended side effects when modifying the system.
  • facilitate interoperability by allowing layers to interact only through the well defined interfaces (see Interface View).
  • provide flexibility to allow layers to be modified or replaced without impacting the entire system.
  • enhance security by isolating sensitive operations within specific layers. This limits the exposure of critical functionalities and data.

SAS_QP_APP

SAS_QP_APP : QP/C++ Application layer
Description
QP/C++ Application layer (Figure SAS-CTXT [0]) consists of specific Active Object classes and Event classes. The QP/C++ Application classes inherit and specialize the base classes from QP/C++ Framework. QP/C++ Application also uses services provided by the QP/C++ Framework API.
Note
The specific classes inside the QP/C++ Application layer, such as ActiveObjA or EventA, are derived from the QP/C++ Framework base classes, which are described in the Structural View in Software Design Specification.

SAS_QP_FRM

SAS_QP_FRM : QP/C++ Framework layer
Description
QP/C++ Framework layer (Figure SAS-CTXT [1]) provides the base classes to be specialized by the QP/C++ Application. QP/C++ Framework also provides the runtime environment to execute QP/C++ Application. Finally QP/C++ Framework provides the QP/C++ Framework API, which are services that the specific Active Objects can call directly without subclassing and specializing the base classes.
Note
The QP/C++ Framework base classes, such as QActive and QEvt are described in the Structural View in Software Design Specification.
Backward Traceability
Forward Traceability

SAS_QP_OSAL

SAS_QP_OSAL : OS abstraction layer (OSAL)
Description
Operating System Abstraction layer (Figure SAS-CTXT [2]) insulates the QP/C++ Framework from the specifics of the underlying Operating System (OS). The OS Abstraction Layer provides an abstracted OSAL API that QP/C++ Framework uses internally. The OS Abstraction Layer also implements the OSAL API for the underlying OS layer, which is called a specific QP port.
Backward Traceability
Forward Traceability

SAS_QP_OS

SAS_QP_OS : OS layer
Description
Operating System layer (Figure SAS-CTXT [3]) provides the execution context for Active Objects as well as other services used by the OS abstraction layer (OSAL). The OS Layer might consist of one of the real-time kernels provided in the QP/C++ Framework (e.g., QV, QK, or QXK) or might be a 3rd-party RTOS/OS.
Backward Traceability
  • SRS_QP_NF_03 : QP/C++ Framework shall be modular.
  • SRS_QP_NF_04 : QP/C++ Framework shall be layered.
  • SRS_QP_AO_80 : QP/C++ Framework shall be portable to a wide range of operating systems.
Forward Traceability

Interface View

The Interface View defines how different layers of a system interact with each other. The objectives are:

  • define clear layer boundaries, ensuring each layer's responsibilities and interactions are well-defined.
  • ensure compatibility to allow seamless communication and data exchange between layers.
  • promote modularity to allow components to be developed, tested, and maintained independently, which enhances flexibility and scalability.
  • facilitate integration to provide a blueprint for integrating different components, making it easier to assemble the system and ensure that all parts work together harmoniously.
  • enhance reusability by designing interfaces that can be reused across different projects or components, reducing development time and effort.
  • support interoperability to ensure that the system can interact with other systems or external components, which is especially important in real-time embedded systems where integration with hardware and other software is common.
  • maintain consistency in how components interact, which helps in maintaining the integrity and reliability of the system.

SAS_QP_CLS

SAS_QP_CLS : QP/C++ Framework base classes
Description
Base classes in QP/C++ Framework (Figure SAS-CTXT [1A]) provide an interface for QP/C++ Application to inherit and specialize.
Backward Traceability
  • SRS_QP_EVT_00 : QP/C++ Framework shall provide Event abstraction to QP/C++ Application
  • SRS_QP_SM_00 : QP/C++ Framework shall provide support for hierarchical state machines both for Active Objects and for passive event-driven objects in the Application
  • SRS_QP_AO_00 : QP/C++ Framework shall provide the Active Object abstraction to QP/C++ Application
Forward Traceability

SAS_QP_API

SAS_QP_API : QP/C++ Framework API
Description
QP/C++ Framework API (Figure SAS-CTXT [1B]) provides an interface to various QP/C++ Framework services without the need to subclass and specialize the QP/C++ Framework base classes. Examples of such services include: direct event posting, subscribing and publishing events, or arming and disarming time events.
Backward Traceability
  • SRS_QP_EDM_00 : QP/C++ Framework shall provide direct event posting to Active Object instances based on the FIFO policy
  • SRS_QP_EDM_01 : QP/C++ Framework shall provide direct event self-posting to Active Object instances based on the LIFO policy
  • SRS_QP_EDM_50 : QP/C++ Framework shall provide publish-subscribe event delivery mechanism
  • SRS_QP_EDM_52 : QP/C++ Framework shall allow Active Object instances to subscribe to a given event signal at run-time.
  • SRS_QP_EDM_53 : QP/C++ Framework shall allow Active Object instances to unsubscribe from a subscribed event signal at run-time.
  • SRS_QP_EDM_54 : QP/C++ Framework shall allow Active Object instances to unsubscribe from all subscribed event signals at run-time.
  • SRS_QP_EMM_40 : QP/C++ Framework shall provide a method of explicitly recycling mutable events.
  • SRS_QP_TM_00 : QP/C++ Framework shall support Time Events.
  • SRS_QP_TM_11 : For every clock rate QP/C++ Framework shall provide a clock-tick processing operation that QP/C++ Application must call periodically to service the armed Time Events.
  • SRS_QP_TM_20 : QP/C++ Framework shall provide Time Event initialization.
  • SRS_QP_TM_21 : QP/C++ Framework shall allow a Time Event to be armed both for one-shot and periodic expiry.
  • SRS_QP_TM_22 : QP/C++ Framework shall allow a Time Event to be explicitly disarmed.
  • SRS_QP_TM_23 : QP/C++ Framework shall allow a Time Event to be rearmed.
  • SRS_QP_TM_30 : QP/C++ Framework shall provide operation to check whether any Time Events are armed for a given tick rate.
Forward Traceability

SAS_OSAL_API

SAS_OSAL_API : OSAL API
Description
OSAL API (Figure SAS-CTXT [2A]) is an abstract interface between QP/C++ Framework and the underlying OS to insulate the framework from the OS.
Backward Traceability
  • SRS_QP_NF_40 : QP/C++ Framework shall be portable to 16-/32-/64-bit CPUs.
  • SRS_QP_NF_41 : QP/C++ Framework shall be portable to a wide range of real-time kernels.
Forward Traceability

SAS_OS_API

SAS_OS_API : OS API
Description
OS API (Figure SAS-CTXT [2B]) is the specific Operating System API. This interface is not part of QP/C++ Framework, but is used in every specific OS Abstraction layer (OSAL).
Forward Traceability

Technology ViewpointResource Viewpoint