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

9.5. Implementation
The openETCS generator application is implemented correspondingly to the methodology
of the domain framework implementation. Hence, the general implementation strategy in
Section 8.6, the programming language, and target platform in Subsection 8.6.1 are the same
and not explicitly discussed here.
9.5.1. libGOPPRR Implementation
Although the structural design of the GOPPRR C++ abstract syntax model was already
introduced in Chapter 4, its implementation is discussed in this chapter because it is used by
the generator application.
All elements for defining a GOPPRR C++ abstract syntax model are declared as structs,
which can be observed in Figure 4.4. In C++, the only difference between classes and structs is
that in a class all elements are by default private visible [79]. For structs, the default visibility
is public [79]. Since for the GOPPRR C++ abstract syntax model mainly a tree of data
structures has to be built, those are declared as structs to provide an easy and direct access to
their attributes 2 . Hence, no methods need to be implemented for their access.
The only methods implemented in those structs are the ones used for abstraction, which
were already mentioned in Section 4.2. Those are mainly located in the CGraph class 3 . Since
they mainly focus on the abstraction of graph bindings (see Section 4.2), they are implemented
by iterating over the local bindings m_BindingSet and the corresponding sub-structures. As
already exemplary introduced in Section 4.2 for the ::GOPPRR::CGraph:Roles() method, the
abstraction methods mainly use a certain GOPPRR C++ abstract syntax element instance
(e.g. of ::GOPPRR::CObject) and the literal name of connected type that should be found.
Generally, such searches can provide more than one object 4 . Hence, the abstraction methods
always return a map of pointers to the matching instances. To facilitate the usage in the
generator classes, which typically iterate over the returned map or use just the first element,
an optional exception was introduced to handle situations if the returned map is empty. The
usage of exceptions can be defined in all abstraction methods by the bUseException parameter.
This means the generator does not have to be implemented by an if-branch for each returned
map to check it for non-emptiness. Otherwise, the access to an element of any empty map
always causes a segmentation fault [77, pp. 353-453]. Since in the most cases the absence of
an element type in a connection means a fault in the model, this is not manageable by the
generator classes and the resulting error can be easily propagated by an exception.
Unfortunately, until the end of this work, no general OCL parser and checker was available
as OSS or FLOSS library that could have been directly integrated in the CConstraintChecker
class implementation. As a work-around for the case study, some exemplary constraints for the
static semantics in Section 7.5 were directly implemented in C++. Of course, those are only
meaningful for openETCS meta model instances. For other meta models, the static semantics
would have to be implemented additionally in C++.
2 aggregations, compositions, and properties from the design
3 C++ structs will be also called classes in this document because of the only small difference in C++.
4 GOPPRR instance
169