Ph.D. - geht es zur Homepage der Informatik des Fachbereiches 3 ...

4.2. GOPPRR C++ Abstract Syntax Model
GOPPRR Concrete Syntax Meta Model Similar to the original GOPRR concrete syntax
description formalism [56], also a GOPRR meta model was created for the new GOPPRR
concrete syntax formalism. Hence, a concrete syntax in GOPPRR can also be modelled in
MetaEdit+ as instance of this meta model. The concrete syntax of this GOPPRR concrete
syntax meta model is not explicitly documented here, but it is located in Section B.6 together
with a model of the concrete syntax for the case study in Part III.
4.2. GOPPRR C++ Abstract Syntax Model
Additionally to the meta model concrete syntax definition formalism, the generator capabilities
are of high relevance for the creation of dependable software. Typically, generators for models
in a certain meta meta model are tool bounded and are not independently implemented. Due
to the decision to use MetaEdit+ as meta modelling application (reasoned in Chapter 3), the
relevant generator or rather generator language is MERL. Its main advantage is the provided
abstraction for navigating through the bindings between objects in graphs. In contrast to the
abstract GOPRR meta meta model structure in Figure 3.17 and Figure 3.18, the navigation is
simplified in MERL to bindings in Figure 3.19 without ports and Figure 3.20 with ports. The
direct drawback is that a generator is only related to the scope of a graph type but not to a
project. Also, MERL generators for other GOPRR elements can be implemented but can only
be used for graphical representation effects and not for output generation, like source code.
Therefore, all elements in a graph are treated only as graph-global, although they are project
global, and might be (re)used in several different graphs.
To obtain the information about the partition of an object, the implementation in MERL
mostly ends in a complex generator. Additionally, MERL suffers in general from a weak syntax.
For example, it lacks of the definition of functions and the specification of the scope of variables.
This means simple generators can be easily implemented in MERL while complex and project
related generators typically reach an unacceptable level of complexity in their implementation.
To handle this issue, the concrete generation of source code and other components must be
done outside of MetaEdit+ and MERL because the drawbacks cannot be eliminated by custom
extensions and modifications. Furthermore, extensions or modifications of the generation
module are not possible since MetaEdit+ is proprietary, closed source software.
For this reason, an external generator application that uses an abstract syntax model should
be implemented. The term model refers here to a software class model specified in UML.
Nevertheless, from the DSM view the, GOPPRR C++ abstract syntax model is a meta
meta model while concrete instantiations corresponds to a model instances within that meta
meta model. This abstract model must be provided in a project-oriented manner while the
implementation in C++ eliminates the syntactical weaknesses of MERL. The transformation
from the internal, concrete syntax model in MetaEdit+ to the C++ GOPPRR model should
be done via XML 1 , which is explained in Section 4.3 in detail.
In the following, the C++ abstract syntax model is explained in detail. For the initial
development, the already existing GOPRR meta meta model abstract structure in Figure 3.17
and Figure 3.18 was taken and then transferred to an UML class structure to be extended as
1 as intermediate model
43