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

9.7. Verification and Validation
in Section 4.4). This means even if functional tests show the correct implementation of
CGOPPRRTransformer, it is not guaranteed that the XML file is generated correctly by
MetaEdit+. Additionally, the implementation of tests for the MERL GOPPRR XML generator
is not easy to realise because MERL scripts only may run in the context of certain GOPRR
instances. The best possible solution to avoid this problem is to generate the tests directly
from the MetaEdit+ model as C++ source code.
Similar to the MERL generator for creating the GOPPRR XML file, this can be done in a
general manner not specialised for a certain meta model. Only, all graphs have to be processed
to generate for each GOPPRR element test statements to check their existence in a CProject
object or rather abstract syntax model. These statements look like the following example,
which is only a small excerpt:
1 : : GOPPRR : : CGraph∗ pGraph ( 0 ) ;
2 : : GOPPRR : : CObject ∗ pObject ( 0 ) ;
3 : : GOPPRR : : CProperty ∗ pProperty ( 0 ) ;
4
5
6 // BEGIN: a s s e r t s f o r graph openETCS Case Study with oid 3_256
7 CPPUNIT_ASSERT( p P r o j e c t −>m_GraphSet . f i n d ( "3_256" ) != p P r o j e c t −>m_GraphSet . end ( ) ) ;
8 pGraph = &( p P r o j e c t −>m_GraphSet [ "3_256" ] ) ;
9 // BEGIN: a s s e r t s f o r o b j e c t F u l l Supervision o f type Mode with oid 3_283
10 CPPUNIT_ASSERT( pGraph−>m_ObjectSet . f i n d ( "3_283" ) != pGraph−>m_ObjectSet . end ( ) ) ;
11 pObject = pGraph−>m_ObjectSet [ "3_283" ] ;
12 CPPUNIT_ASSERT( pObject−>m_ID == : : s t d : : s t r i n g ( " F u l l ␣ S u p e r v i s i o n " ) ) ;
13 CPPUNIT_ASSERT( pObject−>m_Type == : : s t d : : s t r i n g ( "Mode" ) ) ;
14 CPPUNIT_ASSERT( pObject−>m_OID == : : s t d : : s t r i n g ( "3_283" ) ) ;
15 CPPUNIT_ASSERT( pObject−>m_Properties . f i n d ( "3_285" ) != pObject−>m_Properties . end ( ) ) ;
16 pProperty = pObject−>m_Properties [ "3_285" ] ;
17 CPPUNIT_ASSERT( pProperty−>m_Value == : : s t d : : s t r i n g ( " F u l l ␣ S u p e r v i s i o n " ) ) ;
18 CPPUNIT_ASSERT( pProperty−>m_Type == : : s t d : : s t r i n g ( "ModeName" ) ) ;
19 CPPUNIT_ASSERT( pProperty−>m_OID == : : s t d : : s t r i n g ( "3_285" ) ) ;
20 [ . . . ]
The CPPUNIT_ASSERT() [16] macro is part of the CppUnit framework and defines assertions [79],
which must be fulfilled for a certain test case. Initially, the existence of the graph instance is
checked. Afterwards, objects and their properties are checked and so on. A great advantage
is that the OIDs are used as key values for the maps in the GOPPRR C++ abstract syntax
model. Thus, the access to the elements is easy definable in the MERL generator. Since a lot
of assertions for each graph are generated in this manner, those are grouped in C++ functions
for each graph. Finally, a function is generated that calls all those graph functions and can be
integrated in any testing application.
Because the test can always be generated along with the GOPPRR XML intermediate model,
it can be guaranteed that all GOPRR or rather GOPPRR elements of the model instance in
MetaEdit+ also exist in the GOPPRR C++ abstract syntax model or rather in the CProject
object. This covers Req.9 for the transformation process and is not limited to the openETCS
meta model.
As already explained for the GOPPRR XML generator in Section 4.4, a small drawback is
that no assertions can be generated, due to MetaEdit+ / MERL limitations, for properties
that are non-properties. For those, always a specialised generator for the concrete meta model
has to be added. The full code of the assertion generators can be found in Section F.2.
The realisation of tests to ensure Req.9 for the C++ source code generation by CCPPGenerator
is much more complicated. It can also be interpreted as a transformation but not in
such a general way as for the internal MetaEdit+ GOPRR representation to the GOPPRR
C++ abstract syntax model. Therefore, again generating tests directly from MetaEdit+ is not
175