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

AGOPPRR to MOF Transformation
Although the selection of the GOPRR meta meta model was well reasoned in Section 3.4,
the proprietary properties of the modelling application MetaEdit+ is an obstacle to the idea
of publishing all generators and artefacts under the principles of FLOSS. Additionally, the
application causes some drawbacks that are not related to the meta meta model.
The usage and integration of MetaEdit+ is adequate for the case study presented in this
work, but for further work going beyond a case study it might be necessary to use an alternative
application. The main problem of using another application is the integration of a new meta
meta model because currently no other meta (meta) modelling application that uses GOPRR
is available. Then, most elements would have to be manually redeveloped. Instead, a solution
that obtains a better re-usability by a transformation from GOPPRR to another meta meta
model that has FLOSS tool support could be found.
The most reasonable choice for the new meta meta model is MOF. For example, the Ecore
meta meta model is used in Eclipse for meta modelling and modelling [9]. Fortunately, the
C++ abstract syntax model is already defined as UML class diagram (see Figure 4.4) and uses
the same syntax as MOF [62][76, pp. 64-71]. Figure 4.4 could also be interpreted as a template
for GOPPRR meta models represented in MOF. Concrete GOPPRR elements only have to be
added to the structure by inheriting from their super type 1 for any existing GOPPRR meta
model.
This approach arises the problem that all associations between the GOPPRR elements are
defined between the super types and are inherited by all concrete types of the original GOPPRR
meta model. As a consequence, for example, all sub types of CGraph could have any sub type
of CObject, which is normally not desired and does not correspond to a unique transformation.
The redefinition of all associations would be a possible solution. In other words, besides the
associations between the supertypes, all subtypes or rather concrete meta model types have
the concrete associations to other concrete meta model types. An example of this strategy was
modelled in Eclipse with EMF and with types from the case study in Part III and is shown in
Figure A.1.
1 CProject, CGraph, CObject, CProperty, CPort, CRole, CRelationship, CBinding, CConnection, CCall, and
CGraphicalContainer
243