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

Chapter 8. openETCS Domain Framework
The classes in ::oETCS::DF::UT are the test suites, which inherit from TextFixture [16],
which is a class of the CppUnit framework. The classes that are tested are indicated by the
aggregations m_pAnd, m_pTelegram, m_pStateMachine, and m_pControlFlow. Of course, all
classes are tested, but, due to the size and complexity of the figure, only some examples are
sketched.
The test suite classes must have access to all attributes, which include the private and
protected ones, of the tested classes to provide white-box testing [78, p. 312] instead of pure
black-box testing [78, p. 312], which only runs tests on the outputs for certain inputs. Since
most of those methods are not public visible / accessible, a friend [79] relation between test
suite classes and the classes to be tested have to be defined (omitted in the figure). Black-box
testing might be sufficient for tests for the CFunctionBlock classes because those are defined as
transfer functions for certain inputs, which return certain outputs. Consequently, their internal
states are not of interest for the tests. However, this is not the case for all other classes and
white-box tests are implemented via direct class attribute access.
8.7.2. Unit Testing Implementation
The implementation of tests for CFunctionBlock blocks is realised as random testing [78, p. 317].
For all inputs of a certain CFunctionBlock class, random input values are generated. Since the
the transfer function for the Execute() method is always well-defined for each CFunctionBlock
class, the resulting outputs can be checked for the expected values.
For classes outside the data flow, such interconnections between inputs and outputs is not
defined. Therefore, those have to be tested in a simulative way [78, p. 318]. Especially, the
classes for control flows (CControlFlow and CEVCStateMachine) can be additionally tested
by state transition testing [78, p. 318]. For those cases, a transition system is instantiated
by corresponding state and transition objects and then is tested if all states are reached and
executed as expected.
A further, more detailed discussion of test implementation is not in the main focus of this
work. The software reference of the tests and their implementation can be found in Appendix G.
8.8. Conclusion
The design, the implementation, and finally the testing of the openETCS domain framework
show that all initial defined requirements are fulfilled. Certain, already theoretical introduced
issues, like the integration of hardware virtualisation, are dealt with. Furthermore, the domain
framework is aligned to the terminology of the OMG’s definition of a model-driven architecture
(MDA).
The special situations of the behavioural design is described because this is defined by
the instantiation of domain framework classes. This can also be called “behaviour through
structure”.
In contrast to all other instances of the openETCS architecture, the domain framework has
to differentiate between faults, errors, and system failures and has to provide an error handling
interface to the meta model respectively model.
158