Embedded Software for SoC - Grupo de Mecatrônica EESC/USP

A Flexible Object-Oriented Software Architecture 117
The following two sub-sections will discuss the design of the middleware
framework and the product line architecture in detail. These elements of the
overall architecture, the actual subject of the project, are designated by gray
boxes in the diagram of Figure 9-3.
4. THE MIDDLEWARE FRAMEWORK
As stated in the previous section, the primary design goal of the middleware
framework was an abstraction from specifics of the underlying OS, hardware,
and – if possible – implementation language. To achieve this, a standardized,
object-oriented API needed to be designed, encapsulating OS and hardware
specifics. This API had to be sufficiently generic to support different product
lines and yet sufficiently specific to significantly facilitate application development.
The most reasonable-seeming approach to the design of the middleware
framework consisted in mapping elements of the SWCD platform’s feature
model (see Figure 9-1) to classes (a small portion of the model is shown in
Figure 9-4) and packages. Generally, atomic features were turned into classes,
composite features into packages. Additional packages and classes were
created for elements not covered by the hardware feature model but for which
abstractions had to be provided, such as means for handling concurrency.
Classes were interrelated using refinement/abstraction, implementation, and
generic dependency relations. Relations were defined in such a fashion that
hardware/OS dependencies were kept within as few classes as possible,
reducing the effort posed by adding support for a new platform later on.
Common base and dedicated interface classes were used to capture commonalities
among components of a kind, such as stream- or message-based
communications components/classes.
We furthermore tried to follow a number of framework (and software architecture
in general) design guidelines [5, 6], reduced dependencies among
packages to improve the ability to develop packages separately from each
other, and applied various design patterns [7, 8].
As for abstraction from hardware and OS specifics, besides differences
in the way, e.g., components are accessed, the OS-level support for specific
components might vary or even be missing. Furthermore, there were
components (such as GSM modems or GPS modules) which are only
rudimentarily supported at OS level (via generic drivers) – for these, the
middleware framework should provide a uniform, higher-level API, also
abstracting from specific models of a given type of component.
To this end, the framework design had to accommodate three dimensions
of variability:
varying operating systems;