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

4.7. Conclusion
External Artefacts The following artefacts are not located in any application and are used
as interface, input, or final output of the tool chain.
OCL File (AM)
Source Code (AF)
Build Configuration (AF)
VM Configuration File(s) (AF)
Constraint Report (AF)
List of OCL statements defining constraints for models of
the openETCS meta model as static semantics.
Generated C++ source code for the openETCS model.
Generated build configuration to compile and link the generated
openETCS source code.
Generated configuration files for hypervisors running virtual
machines corresponding to the openETCS model.
List of unfulfilled constraints within the openETCS model.
The tool chain cannot end with the final generated artefacts as output because none of them
is executable. This chapter only provides background information needed for understanding
the following parts of this work and therefore the complete tool chain for the case study is
presented in Part III.
Drawback One idea of modelling the syntax of a meta model as model under the same
meta meta model was to be able to directly generate the meta model from this syntax model.
Unfortunately, it emerged that the XML file format used by MetaEdit+ for import and export
of meta models [56] does not support port types. Ports are only exported (and imported)
type-less as graphical connectors in object symbols / graphical representations. Therefore,
after (re-)importing a meta model via XML, all port types are stripped from the meta model.
This lack of port type support is not documented within the MetaEdit+ manual [56] and was
only found in support forums.
An alternative would be to use the internal MetaEdit+ patch file format [56], but it is
proprietary, not documented, and binary. To use it, the format would have to be re-engineered
– without any guarantee of success – and a binary generator would have to be developed.
Nevertheless, because the extension of existing modelling application is out of the scope of this
work, the openETCS concrete syntax model is manually kept synchronous with the openETCS
meta model and primary used for documentation purposes. This drawback is only related to
the modelling application but not to the meta meta model.
4.7. Conclusion
The GOPPRR extension of the GOPRR meta meta model provides good techniques and
formalisms integrated in a tool chain to fulfil the objectives of this work. The GOPPRR C++
abstract syntax model provides now all formalisms to fully describe the static semantics for a
meta model of GOPRR, which is a must for modelling of safety-critical systems. Additionally, it
provides better abstraction because it separates definition of element properties and sub-types
from graph-binding and sub-graphing. That the abstract syntax model cannot be used to
53