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

9.5. Implementation
outside the closed loop. Hence, the start object can be arbitrarily chosen. Because data flows
are modelled as relationships or rather bindings in GOPPRR, the needed processing of objects
is quite more complicated than for all other cases in the openETCS meta model. Therefore, a
specialised abstract model of data flows is used to determine the execution order in each data
flow of the model. The class diagram of this abstract model is shown in Figure 9.10. Due to
Figure 9.10.: UML class diagram of the abstract model for data flow execution order generation
its specialisation for the data flow order, the abstract model is quite simple and only consists
of the struct CFBNode. It holds the attributes m_OID which is the OID of the corresponding
function block object and m_eState, which is an enumeration type used during the creation
of the abstract model. The m_Inputs aggregation represents the connection from outputs of
other function block objects, which is the backward direction of the data flow. The other or
rather forward data flow direction, the connection of inputs to outputs, is not relevant for the
data flow abstract model because only function block objects without inputs shall be found.
The abstract data flow model is created by the CCPPGenerator::BuildAbstractModel()
method, which is located in Listing E.1 in Appendix E.
After the execution of this method, the abstract model consists of CFBNode objects, which
have the m_eState DEFINED, which means those do not have to be modified further and are
final in the data flow abstract model. In contrast, all objects in each m_Inputs are created as
UNDEFINED. They can be interpreted as place holders and must afterwards be replaced by a
reference to the “real” (DEFINED) object with the same OID, which can be easily done by the
code in Listing E.2.
The execution and also generation order is finally computed by the CCPPGenerator::-
ProcessAbstractModel() method, which simply generates a list of function block object OIDs
in the required execution order in Listing E.3.
Although the openETCS domain framework provides the parallelisation of independent data
flows (see Section 8.3), this is currently not taken into account for the C++ code generator
because the performance by a plain, serial data flow execution is sufficient for this case study.
CBuildGenerator Implementation In the next step, the build configuration for cmake is
generated by the Generate() method of the m_BuildGenerator object. This is completely independent
from the GOPPRR C++ abstract syntax model because it only requires information
about the source code file, include directories [79], and libraries for linking.
173