Architectural viewpoint: Context of use for the QP/C Framework.
Purpose
The Context Viewpoint provides a "black box" perspective on the architecture subject (QP/C Framework component in this case) in the surrounding context (the system integrating QP/C). The views within this viewpoint identify the stratification of services (layers) and the interfaces between the layers.
Architectural Views
This architectural viewpoint frames the following views:
Model Kind
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 component 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 component interfaces.
Remarks
In compliance with the UML conventions, the diagrams shown in this section intentionally omit many elements. 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/C Framework component 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/C 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.
ARCH_QP_APP
Architectural view: QP/C Application layer.
Description QP 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 component. QP/C Application also uses services provided by the QP/C Framework component API.
Description QP/C Framework component layer (Figure SAS-CTXT [1]) provides the base classes to be specialized by the QP/C Application by inheritance. The QP/C Framework component 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/C Framework component from the specifics of the underlying Operating System (OS). The OS Abstraction Layer provides an abstracted OSAL API that QP/C Framework component 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
REQ_QP_NF_41: QP/C Framework component shall be portable to a wide range of real-time kernels.
Forward Traceability (truncated to 1 level(s))
ARCH_QP_OS
Architectural view: 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 component (e.g., QV, QK, or QXK) or might be a 3rd-party RTOS/OS.
Backward Traceability
REQ_QP_NF_41: QP/C Framework component shall be portable to a wide range of real-time kernels.
REQ_QP_NF_40: QP/C Framework component shall be portable to 16-/32-/64-bit CPUs.
Forward Traceability (truncated to 1 level(s))
Architectural Views: Interfaces
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.
ARCH_QP_FBC
Architectural view: QP/C Framework component base classes.
Description Base classes in QP/C Framework component (Figure SAS-CTXT [1A]) provide an interface for QP/C Application to inherit and specialize. The main QP/C Framework component base classes are:
Event class (concrete class, but also customizable by inheritance)
Active Object class (abstract base class customizable by inheritance)
Backward Traceability
REQ_QP_EVT_00: QP/C Framework component shall provide Event abstraction to QP/C Application
REQ_QP_AO_00: QP/C Framework component shall provide the Active Object abstraction to QP/C Application
Description
Besides providing base classes to inherit, QP/C Framework component also provides the runtime infrastructure (based on inversion of control) to execute Active Objects comprising the QP/C Application. QP/C Framework component provides the QP/C Framework component 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
REQ_QP_EDM_00: QP/C Framework component shall provide direct event posting to Active Object instances based on the FIFO policy.
REQ_QP_EDM_01: QP/C Framework component shall provide direct event self-posting to Active Object instances based on the LIFO policy
REQ_QP_EDM_50: QP/C Framework component shall provide publish-subscribe event delivery mechanism
REQ_QP_EDM_52: QP/C Framework component shall allow Active Object instances to subscribe to a given event signal at run-time.
REQ_QP_EDM_53: QP/C Framework component shall allow Active Object instances to unsubscribe from a subscribed event signal at run-time.
REQ_QP_EDM_54: QP/C Framework component shall allow Active Object instances to unsubscribe from all subscribed event signals at run-time.
REQ_QP_EMM_40: QP/C Framework component shall provide a method of explicitly recycling mutable events.
REQ_QP_TM_00: QP/C Framework component shall support Time Events.
REQ_QP_TM_11: QP/C Framework component shall provide clock-tick processing operations for all supported clock rates that QP/C Application must call periodically to service the armed Time Events.
REQ_QP_TM_20: QP/C Framework component shall provide Time Event initialization.
REQ_QP_TM_21: QP/C Framework component shall allow a Time Event to be armed both for one-shot and periodic expiry.
REQ_QP_TM_22: QP/C Framework component shall allow a Time Event to be explicitly disarmed.
REQ_QP_TM_23: QP/C Framework component shall allow a Time Event to be rearmed.
REQ_QP_TM_30: QP/C Framework component shall provide an operation to check whether any Time Events are armed for a given tick rate.
Forward Traceability (truncated to 1 level(s))
ARCH_OSAL_API
Architectural view: OSAL API.
Description OSAL API (Figure SAS-CTXT [2A]) is an abstract interface between the QP/C Framework component and the underlying OS to insulate the framework from the OS.
Backward Traceability
REQ_QP_NF_40: QP/C Framework component shall be portable to 16-/32-/64-bit CPUs.
REQ_QP_NF_41: QP/C Framework component shall be portable to a wide range of real-time kernels.
Forward Traceability (truncated to 1 level(s))
SREQ_QP_DFM_02: QP/C software component shall apply data flow self-monitoring to the interface between QP/C software component and the underlying operating system (QP OSAL-API).
ARCH_OS_API
Architectural view: OS API.
Description OS API (Figure SAS-CTXT [2B]) is the specific Operating System API. This interface is not part of the QP/C Framework component, but is used in every specific OS Abstraction layer (OSAL).
QP/C Real-Time Event Framework 8.1.5