The Context Viewpoint provides a "black box" perspective on the architecture subject (QP Framework in this case) in the surrounding context (QP 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 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 Framework interfaces.
Remarks
In compliance with the UML conventions, the diagrams shown in this section intentionally omit many elements of the 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.
The Layers View explains the QP 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, a well-defined QP Application layer can be reused in different contexts (e.g., with other operating systems 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.
Description QP Application layer (Figure SAS-CTXT [0]) consists of specific Active Object classes and Event classes. The QP Application classes inherit and specialize the base classes from QP Framework. QP Application also uses services provided by the QP Framework API.
Description QP Framework layer (Figure SAS-CTXT [1]) provides the base classes to be specialized by the QP Application by inheritance. The QP Framework layer can further consist of sub-layers, such as the passive QEP Event Processor and QF Active Object framework.
Description Operating System Abstraction layer (Figure SAS-CTXT [2]) insulates the QP Framework from the specifics of the underlying Operating System (OS). The OS Abstraction Layer provides an abstracted OSAL API that QP 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
SRS_QP_NF_41: QP Framework shall be portable to a wide range of real-time kernels.
Forward Traceability (truncated to 1 level(s))
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 Framework (e.g., QV, QK, or QXK) or might be a 3rd-party RTOS/OS.
Backward Traceability
SRS_QP_NF_41: QP Framework shall be portable to a wide range of real-time kernels.
SRS_QP_NF_40: QP Framework shall be portable to 16-/32-/64-bit CPUs.
Forward Traceability (truncated to 1 level(s))
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 standard.
maintain consistency in how components interact, which helps in maintaining the integrity and reliability of the system.
SAS_QP_FBC
QP Framework base classes
Description Base classes in QP Framework (Figure SAS-CTXT [1A]) provide an interface for QP Application to inherit and specialize. The main QP Framework base classes are:
Event class (concrete class, but also customizable by inheritance)
Active Object class (abstract base class customizable by inheritance)
Backward Traceability
SRS_QP_EVT_00: QP Framework shall provide Event abstraction to QP Application
SRS_QP_AO_00: QP Framework shall provide the Active Object abstraction to QP Application
Description
Besides providing base classes to inherit, QP Framework also provides the runtime environment (based on inversion of control) to execute Active Objects comprising the QP Application. QP Framework provides the QP Framework API (Figure SAS-CTXT [1B]), which are services that the Active Objects can call directly without subclassing and specializing the base classes. Examples of such services include: allocating dynamic events, direct event posting, subscribing and publishing events, or arming and disarming time events.
Backward Traceability
SRS_QP_EDM_00: QP Framework shall provide direct event posting to Active Object instances based on the FIFO policy.
SRS_QP_EDM_01: QP Framework shall provide direct event self-posting to Active Object instances based on the LIFO policy
SRS_QP_EDM_50: QP Framework shall provide publish-subscribe event delivery mechanism
SRS_QP_EDM_52: QP Framework shall allow Active Object instances to subscribe to a given event signal at run-time.
SRS_QP_EDM_53: QP Framework shall allow Active Object instances to unsubscribe from a subscribed event signal at run-time.
SRS_QP_EDM_54: QP Framework shall allow Active Object instances to unsubscribe from all subscribed event signals at run-time.
SRS_QP_EMM_40: QP Framework shall provide a method of explicitly recycling mutable events.
SRS_QP_TM_00: QP Framework shall support Time Events.
SRS_QP_TM_11: QP Framework shall provide clock-tick processing operations for all supported clock rates that QP Application must call periodically to service the armed Time Events.
SRS_QP_TM_20: QP Framework shall provide Time Event initialization.
SRS_QP_TM_21: QP Framework shall allow a Time Event to be armed both for one-shot and periodic expiry.
SRS_QP_TM_22: QP Framework shall allow a Time Event to be explicitly disarmed.
SRS_QP_TM_23: QP Framework shall allow a Time Event to be rearmed.
SRS_QP_TM_30: QP Framework shall provide an operation to check whether any Time Events are armed for a given tick rate.
Forward Traceability (truncated to 1 level(s))
SAS_OSAL_API
OSAL API
Description OSAL API (Figure SAS-CTXT [2A]) is an abstract interface between the QP Framework and the underlying OS to insulate the framework from the OS.
Backward Traceability
SRS_QP_NF_40: QP Framework shall be portable to 16-/32-/64-bit CPUs.
SRS_QP_NF_41: QP Framework shall be portable to a wide range of real-time kernels.
Forward Traceability (truncated to 1 level(s))
SSR_QP_DFM_20: QP/C++ Framework shall apply data flow self-monitoring to the interface between QP/C++ Framework and the underlying operating system (QP OSAL-API).
