Database Reference
In-Depth Information
the implementation of the individual components. However, as a side effect, it has notable
impact on the maintainability of the applications. GRATIS replaces the textual representa-
tion of the interface and confi guration specifi cations. Even with a simple application, a more
expressive representation of components and interconnections between them can help design
better applications and increase their readability. With more sophisticated components and
especially with hierarchical composition, this becomes an absolute requirement. There are
cases where components might impose additional complex restrictions on their use — like
mutual exclusion or maximum fan-out — in addition to the normal rules of composition in
TinyOS. These additional requirements can be easily captured by the constraint language
provided by the GME modeling framework.
Since all practical applications use system components from the TinyOS distribu-
tion, GRATIS also provides a mapping from the existing large code base to the graphical
environment. Therefore, the interpreter not only generates text fi les from graphical models,
but it is also capable of parsing existing fi les and building the corresponding GME models
from them. The main use of this parsing feature is to automatically generate the graphical
equivalent of the TinyOS system components and to provide them as a library to the user in
the GRATIS environment. An indisputable benefi t of the parsing and model building process
is an exhaustive testing, since the parser — with the help of the predefi ned constraints in the
meta-model — builds and validates all components and applications found in the source tree.
Since scripting languages are generally superior to compiled languages in the fi eld of text
processing, we have implemented GRATIS using GME and the Python language exclusively,
which also demonstrates an extension alternative to our C++ interpreter framework.
Other experimental modeling languages have also been implemented to describe not
only the type requirements, but temporal dependencies and the implementation details also.
These languages comprise our further work to understand compatibility and composability
issues better in the fi eld of embedded systems. GME proves to be an effi cient tool and ap-
proach to build such environments.
COMPARISON TO OTHER TOOLS
In terms of supported features, maturity, and the number of real-world applications,
three confi gurable environments stand out: Dome by Honeywell Laboratories (Honeywell,
2000), MetaEdit+ by MetaCASE Consulting of Finland (MetaCase, 2000) and our own
Generic Modeling Environment (GME) (Institute for Software Integrated Systems, 2002).
The four key areas that enable true support for widely different modeling methodologies
are meta-modeling, constraint management, visualization and extensibility.
Meta-modeling
: Meta-modeling may be regarded as just another type of modeling;
therefore, Dome and GME use the tools themselves to implement this functionality. Me-
taEdit+ has a more conservative approach; a series of dialog boxes are used to specify the
meta-model in a non-graphical way. Meta-models typically evolve while being used, and
modifi cations in the meta-model often break the validity of models. These concerns are just
partially handled in Dome and MetaEdit+. GME is the only tool that demonstrates a strict
discipline: meta-models are versioned, and new versions of meta-models do not affect exist-
ing models until they are explicitly upgraded to the new version. Such an upgrade implies
extensive validity checking. This is somewhat cumbersome, but essential for warranting the
correctness of models, especially if they are beyond the usual demo application size.
