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

120 Chapter 9
the tracker application was to be deployed should be allowed to vary significantly,
both with respect to core components (processor, OS) and dependency
on specific auxiliary components. This means that the product line had to
accommodate products ranging from, e.g., multiply-connected SWCDs (via
GSM/GPRS and further means) to the extreme of isolated devices that only
perform data logging.
Since the handling of hardware specifics is delegated to the middleware,
product line modeling can focus on merely using the components supported
by the middleware framework and accounting for configurability rather than
also having to cope with hardware and OS specifics.
While UML lacks the means to natively deal with variability and configurability,
an intuitive, stereotype-based notation was suggested by Clauß [10],
which became the approach chosen to represent the product line’s variability
in UML (for an example, see the use case diagram of Figure 9-5).
A number of advanced techniques for achieving implementation-level
configurability were considered and evaluated, including composition filters,
aspect-oriented programming, subject-oriented programming, and generative
programming. However, all of these approaches require either a particular
implementation language or dedicated tools to be put into practice. The
resulting lack in flexibility and the run-time overhead of some of these
concepts made us take a simpler yet language- and tool-independent approach,
exploiting specifics of the variabilities encountered in the tracker application’s
specification.
Compared to software product lines sold as stand-alone products, the tracker
application’s variability was special in that available hardware features
determined the software features to be provided – further arbitrary restrictions
were neither planned nor required. This fact effectively reduced the complexity
of the variability requirements by binding software features to hardware
features – which were, for the most part, modeled as classes in the middleware
framework.
Based on these considerations, a number of techniques were selected and
combined in our approach:
specialization through inheritance (based on interfaces and base classes
provided by the middleware) and the Factory pattern [6]
instantiation and passing of objects conforming to certain interfaces and
base classes – or lack thereof – were used to determine whether or not
certain software features are to be present
instantiation of thread classes associated with particular types of components
with strict encapsulation of component-specific functionality, dependent
on whether or not instances of the respective component classes were
created and passed to the constructor of a central, coordinating thread class
optimization by the compiler/linker, preventing unused classes’ code from
being included in the application’s binary
use of a configuration object [5] to handle parametric variabilities (such
as timeouts, queue lengths, etc.)