Ph.D. - geht es zur Homepage der Informatik des Fachbereiches 3 ...
Ph.D. - geht es zur Homepage der Informatik des Fachbereiches 3 ...
Ph.D. - geht es zur Homepage der Informatik des Fachbereiches 3 ...
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
Chapter 9. openETCS Generator Application<br />
CGOPPRRTransformer to be able to provide a GOPPRR C++ abstract syntax model to<br />
the generator class<strong>es</strong>. The m_ConstraintChecker composition is used to check the GOPPRR<br />
C++ abstract syntax model validity according to the meta model constraints or rather static<br />
semantics.<br />
DSM For general domain-specific modelling issu<strong>es</strong>, this package provid<strong>es</strong> a composite d<strong>es</strong>ign<br />
pattern for transformer and abstract syntax model class<strong>es</strong>. Generally, transformer class<strong>es</strong><br />
convert an intermediate model from an XML file to an abstract syntax tree. Therefore, for<br />
each one a base class (CSyntaxTransformer and CSyntaxTree) is defined, which corr<strong>es</strong>ponds<br />
to the component participant [32, p. 165] of the d<strong>es</strong>ign pattern. CGOPPRRTransformer and<br />
CGOPPRRSyntaxTree are the concrete leafs [32, p. 165] for the GOPPRR meta meta model.<br />
As already explained above, the integration of this pattern is mainly relevant for possible<br />
extensions by further abstract syntax models in further work.<br />
GOPPRR The detailed structure of the GOPPRR C++ abstract syntax model was already<br />
introduced and discussed in Section 4.2 and sketched in Figure 4.4. New in this package is the<br />
CConstraintChecker class for checking a certain CProject object for a set of constraints. Due<br />
to the definition of GOPPRR and its C++ abstract syntax model, also the constraint checker<br />
is completely independent from the meta model and can be easily implemented in one class.<br />
xmlpp In the UML model, the xmlpp package only repr<strong>es</strong>ents the external libxml++ library,<br />
which is used for the parsing of XML fil<strong>es</strong>.<br />
9.4. Deployment D<strong>es</strong>ign<br />
The differentiation by the three MDA model categori<strong>es</strong>, as in Section 8.5, is not nec<strong>es</strong>sary for<br />
the generator application because it is not part of the model. Neither, the generator has to be<br />
executed in a different execution environment, nor an IPC has to be <strong>es</strong>tablished.<br />
How the different packag<strong>es</strong> are combined or rather deployed together to build an executable<br />
binary is of special inter<strong>es</strong>t for the generator application development. Thus, the deployment<br />
of the GOPPRR and DSM package is introduced first and at last the GEN package, which<br />
combin<strong>es</strong> all components.<br />
GOPPRR Corr<strong>es</strong>ponding to its definition in Section 4.2, the GOPPRR C++ abstract syntax<br />
model is independent from the meta model and accordingly heavily reusable. Hence, its<br />
deployment as a library [77] seems to be the most appropriate. The deployment of the<br />
libGOPPRR is sketched in Figure 9.3. The artefacts hold the corr<strong>es</strong>ponding class<strong>es</strong> with the<br />
“C” prefix and all manif<strong>es</strong>t the libGOPPRR component. The ExceptionTyp<strong>es</strong> artefact holds<br />
the exception class<strong>es</strong> used for the abstraction methods for easier acc<strong>es</strong>sing be graph bindings<br />
in an abstract syntax model (see Section 4.2). The libGOPPRR component provid<strong>es</strong> all class<strong>es</strong><br />
to other components, which accordingly have to import or rather link against the libGOPPRR<br />
library. Figure 9.4 shows the corr<strong>es</strong>ponding component diagram.<br />
164