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

A Flexible Object-Oriented Software Architecture 121
While lacking in flexibility compared to more sophisticated techniques (whose
application was ruled out for reasons discussed above), this approach was
feasible since the configuration of tracker products would happen entirely at
build time. Furthermore, it represented an efficient choice in the context of
embedded applications as it does not incur any (noteworthy) run-time
overhead.
The static model of the tracker product line comprises a number of concurrent
threads, each encapsulated by a class, for handling GPS-based position
tracking, the GSM modem, generic external serial ports, the watchdog, etc.
An additional, central element is resembled by a dedicated thread responsible
for instantiating and coordinating the other threads in correspondence
with the hardware configuration. Figure 9-6 gives an overview of the basic
application structure.
As for the dynamic model, behavior was modeled using activity, state, and
sequence diagrams. Since the basic nature of the tracker application is dataprocessing
rather than state-driven, state diagrams did not play a major role,
ruling out the use of state-diagram-based code generation. Instead, implementation
was done manually in C++. Since methods’ implementations were
entered within the UML tool, a run of the code generator nevertheless yielded
complete application code.
The configuration of a concrete application of the tracker product line is
achieved by adapting a source code file taking care of the instantiations
described above. By commenting out instantiations or substituting other
sub-classes, an application can be configured in correspondence with a given
hardware configuration. Alternatively, to make things more comfortable, a
GUI-driven configuration tool generating the instantiation code could be
implemented easily.
6. CONCLUSIONS AND OUTLOOK
Thanks to the combination of framework and product line development, the
flexibility of the software designed in the course of the project clearly surpasses
that of the previous, conventional implementation.
The approaches chosen to model variabilities in UML have proven suitable
to accommodate the requirements of the software architecture. Thanks to the
template-based code generation facility provided by Real-Time Studio, the
stereotypes used could be mapped to customizations of code generation templates,
thus linking the modeled variability to the source code level. Combined
with methods’ bodies implemented within the UML tool, “single-click” code
generation has been shown to be feasible. This automation avoids the danger
of introducing inconsistencies among model and code which are likely to result
from the need to manually adapt characteristics at both levels while offering
a high degree of flexibility with respect to variabilities at both the OS/hardware
platform and application end of the spectrum.