Ph.D. - geht es zur Homepage der Informatik des Fachbereiches 3 ...
Ph.D. - geht es zur Homepage der Informatik des Fachbereiches 3 ...
Ph.D. - geht es zur Homepage der Informatik des Fachbereiches 3 ...
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
Chapter 9. openETCS Generator Application<br />
an option because much more complex and specialised generators in MERL would have to be<br />
implemented, which would raise problems already discussed in Chapter 4. On the other hand,<br />
it is already assured by the generated t<strong>es</strong>ts for the transformation to a CProject object that<br />
the GOPPRR C++ abstract syntax model is correct and fully covered / used. Hence, it is<br />
sufficient to t<strong>es</strong>t if the transformation from CProject object to C++ source code is correct or<br />
rather covers the whole model.<br />
The executable EVC binary is the end product of the generation proc<strong>es</strong>s and consists of<br />
linked object or rather binary code. This is very difficult to analyse by parsing since object<br />
code is always platform specific. Another possibility would be the generation of t<strong>es</strong>t methods /<br />
functions that are linked with object code of the EVC binary. Since it is quite complicated to<br />
identify the C++ object structure by directly analysing the application memory or rather the<br />
heap [77, pp. 353-453], the openETCS domain framework objects would have to be acc<strong>es</strong>sed<br />
for t<strong>es</strong>ting. Unfortunately, according to Section 8.3, class instanc<strong>es</strong> of the domain framework<br />
cannot be easily compared with instanc<strong>es</strong> of GOPPRR C++ abstract syntax model because<br />
not all model elements are directly transferred to domain framework instanc<strong>es</strong> and not all<br />
element properti<strong>es</strong>, including the OID, are used. Therefore, a simple identification of elements<br />
by their OID is not available. Furthermore, the CCPPGenerator class generat<strong>es</strong> directly the<br />
domain framework instantiation in a main-function, which means that for t<strong>es</strong>ting the target<br />
code would have to be modified. This might influence the validity of the t<strong>es</strong>ting r<strong>es</strong>ults for the<br />
real EVC binary.<br />
Alternatively, instead of examining the object code, the generated C++ source code could<br />
be analysed. Since CCPPGenerator us<strong>es</strong> the OIDs for generation of object instance nam<strong>es</strong><br />
/ variable declaration, their GOPPRR equivalence can be found much easier by parsing the<br />
generated source code file. It is also qu<strong>es</strong>tionable if it is nec<strong>es</strong>sary to again run t<strong>es</strong>ts on<br />
openETCS domain framework objects since those are already t<strong>es</strong>ted independently from the<br />
generators (see Section 8.7). To only t<strong>es</strong>t the CCPPGenerator class, the analysis of the<br />
generated C++ source code file should be sufficient. This means concretely that the generated<br />
C++ source code is checked for the existence of certain C++ statements that instantiate the<br />
corr<strong>es</strong>ponding domain framework class<strong>es</strong>. In contrast to the verification of the transformation<br />
from a GOPRR model instance to GOPPRR C++ abstract syntax model, not all elements<br />
can be t<strong>es</strong>ted for existence because the openETCS C++ generator do<strong>es</strong> not use all GOPPRR<br />
elements to create a certain openETCS domain framework class instanc<strong>es</strong>. For example, the<br />
rol<strong>es</strong> “DataOutput” and “DataInput” in a data flow are only used to connect a certain function<br />
block object output with a certain input, but their OID is never used. On the other hand, the<br />
“DataFlow” relationship is directly used to create CFlow or CBitFlow instanc<strong>es</strong>, and accordingly<br />
all “DataFlow” relationships in the GOPPRR model must exist in the generated C++ code as<br />
object. Thus, currently only the existence of instantiation statements of all function blocks,<br />
EVC Mode, and language objects and the objects for the “DataFlow” relationship is t<strong>es</strong>ted.<br />
176