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

8.3. Structural Design
defines the corresponding implementation or rather C++ type [79], like bool, double, int, etc.
The second template parameter FLOW_TYPE_T defines the type of the related CInput object.
This parameter has the default value CInput< INPUT_TYPE_T > and normally does not have
to be set explicitly. It is used to define the attribute m_pInput of CFlow that is the connected
CInput instance. m_pInput is not modelled as composition in Figure 8.4 because the usage of
template parameters in UML class diagrams is limited.
The CInput template class, which is nested in the CFunctionBlock base class, is used to
encapsulate each data flow input as property. Its template parameter INPUT_TYPE_T defines,
as for the CFlow class, the concrete implementation data type. This means each input of a
certain function block type or rather class is defined as attribute of the type CInput with the
corresponding template parameter for the concrete data flow type corresponding to the meta
model. Compared with the direct usage of an implementation data type, this has the advantage
that the modification state of each input can be made available or visible to its possessing
function block object. Furthermore, the access of inputs can be made thread-safe [7] by using
a mutable exclusion (mutex) [7] object via the m_ValueMutex composition. It must be noted
that the mutex class is located within the std:: name space of the standard C++ library [7],
which is not explicitly modelled in Figure 8.4.
Unfortunately, the bit data flow type between oVariableStorage objects in the openETCS meta
model (see Subsection 7.3.2) cannot be directly mapped to a data type in the implementation.
Hence, the CFlow template class cannot be used for those data flows and the additional
CBitFlow class was added, which is not a template class and is especially designed for data
flows between CStorage instances. Correspondingly, the aggregation between those two classes
has the two ends m_pInput and m_BitValue. The first is the input storage object, from the view
of CFlow while the latter holds all outputs to other CStorage objects. It should be remarked
that m_pInput is modelled as aggregation compared to the m_pInput because CBitFlow is not
a template class.
Since all interconnections or rather all flows are assigned to a certain parent CEVCStateMachine
object via the m_Flows composition, CAbstractFlow is used as base class for the both
concrete flow types. Finally, to solve the initial problem of the general usage or rather execution
of all existing interconnection / data flows, each CAbstractFlow instance requests via the
m_pStateMachine aggregation if it is part of the currently executed data flow, which means
an element of the m_Flows aggregation. If not, any message from a connected function block
object using operator=() is ignored. Otherwise, the value is marshalled to the related input.
Since the flows between function block objects that are part of an embedded state machine
respectively a CControlFlow instance should only be executed if the related CState object is
currently active, also CState posses an aggregation m_Flows to CAbstractFlow.
8.3.2. Driver Machine Interface Details
All classes especially related to the DMI are presented in a separated class diagram in Figure 8.5.
CDMIObserver is the abstract observer [32, pp. 293-303], from which each concrete observer
implementation must be derived and methods called by the CEVCStateMachine class must be
implemented by overriding [79]. The parent CEVCStateMachine instance holds pointers to all
registered, concrete observers in the aggregation m_Observers via the abstract base type to be
131