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

118 Chapter 9
varying hardware platforms; and
varying implementation languages.
The approach chosen to reflect and provide support for these variabilities
at the UML level consisted in defining stereotypes and associated tagged
values – the UML’s primary means of extension. Using «OS-specific»,
«platform–specific», and «language–specific» stereotypes, model
elements were marked as specific with respect to one (or more) of these
dimensions (for an example of their usage, see class SerialIO in the class
diagram of Figure 9-4).
Even though adding a different implementation language to the framework
obviously represents an immense effort, and C++ has been the only intended
language, the framework was designed so as to reduce dependencies on a
specific language’s capabilities. More precisely, the set of OO features used
was limited to that of the Java programming language wherever viable because
the latter’s set of supported OO notions was considered a common denominator
among current OO languages. Inevitable C++ specifics were accounted
for by using dedicated Real-Time-Studio -provided stereotypes, avoiding
pollution of the actual model with language specifics.
In order to provide for the extensibility demanded from a framework, some
of the mechanisms suggested in the UML-F profile [9] were applied. These
consisted in the use of specific stereotypes to designate hot spots of
(explicitly) expected extensions. These stereotypes, in contrast to the ones
introduced above, however, are of a mere documentary nature.
Since the framework resembles, in first regard, a mapping from a constant
high-level API to a set of native APIs of different operating systems and
hardware platforms, only few interactions were sufficiently complex to warrant
dynamic modeling. Methods were implemented manually within the UML
tool, and sequence diagrams were used to illustrate the behavior of more
complex implementations. The manually-implemented dynamic code was
complemented by Real-Time Studio’s code generator, effectively realizing
the vision of “single-click” code generation.
A mapping from modeled to code-level variabilities with respect to OS and
platform was achieved by adapting Real-Time Studio’s code generation
templates to surround the respective model elements’ source code artifacts
by pre-processor statements, reducing the problem to conditional implementation.
Likewise, dependent fragments of methods’ bodies implemented within
the UML tool accounted for such variabilities through the explicit use of
conditional pre-processor statements. The resulting code can be configured
and compiled for a given hardware platform by defining appropriate preprocessor
constants.
This static management of variabilities (as opposed to run-time dependencies)
is sufficient since OS, platform, and language dependencies can all
be resolved at build time. This still allows for later variability with respect
to the features used in an application since the latter will only include those