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

Chapter 8. openETCS Domain Framework
and m_Outputs aggregation while it is owned by a CDataFlow instance through the m_pDMI
composition. CDMIInput and CDMIOutput are both, according to the meta model, data flow
elements and therefore inherit from CFunctionBlock.
The current active subject depending on the currently executed data flow can be accessed
by the parent CEVCStateMachine instance via the executed CEVCState instance and its
m_pCurrentState composition.
To not directly bind the concrete implementation of the graphical user interface (GUI) to
the openETCS domain framework, a modified observer design pattern [32, pp. 293-303] is used.
The CDMIWidget class (not shown in Figure 8.2) is a concrete implementation of an observer,
which means the GUI representation of the DMI. An abstract subject [32, pp. 293-303] is not
needed here because exact one data basis, the DMI, exists.
8.3.1. Data Flow Details
Due to the fact that the data flow is the central part of the openETCS meta model, also the
domain framework reflects this. All object types in the meta model (Subsection 7.3.2) with
inputs or/and outputs have a corresponding class in the domain framework. Figure 8.3 shows
all special data flow classes. Since all class names only differ from the meta model object type
names in the prefix (“o” → “C”), the description of their functionality will be not repeated here
but can be found in Subsection 7.3.2.
The openETCS meta model defines in graph types related to data flows the connection
between outputs and inputs of objects by ports in an interfacing concept. Therefore, the
transfer of this port or rather interfacing concept to the domain framework is an important part.
A possible solution is provided by the chain of responsibility design pattern [32, pp. 223-232],
which is used to connect objects 3 in a chain that passes a request after handling it to the
next instance in the chain. This pattern would have to be adapted to support different
requests in form of different data flow types and multiple inputs and outputs for different
function block classes. Also, the support of closed loops would have to be added. On the
other hand, the instantiation and parametrisation of the domain framework classes is done
by source code created from a code generator. This code generator has access to the model
instance and therefore has certain knowledge about the data flow structure. Thus, it can
generate the instantiations in an appropriate way that renders a complex design pattern for
this issue unnecessary. As a consequence, inputs can be easily defined by class properties of
the corresponding data type, which can directly store the current value. Outputs are class
properties as references or rather pointers [79] to the data types and can be connected to inputs
by storing their reference / address. Furthermore, outputs can be connected with more than
one input and therefore the class properties must be sequences [63] of references / pointers.
Unfortunately, a certain problem arises with this design: Since all data flow class objects are
globally available for an EVC implementation, as they are in a model instance, their inputs and
outputs can be used in several data flows or rather gMainFunctionBlock and gSubFunctionBlock
graphs. The concrete problem is that a certain CFunctionBlock object, after its execution, sets
all inputs of other objects referenced in its output properties. This might include inputs of
3 called handler in the pattern
128