This chapter describes what the ITEX C Code Generator is used for, how to run it and the structure of the generated code.
When the C Code Generator has translated TTCN into C code, the code must be adapted with the system that is to be tested. The adaption process is described in Adaption of the Generated Code.
|
Note: ASN.1 support The ITEX C Code Generator supports only a limited subset of ASN.1. See C Code Generator for further details on the restrictions that apply. |
|
Note: Windows version This is the Windows version of the chapter. The UNIX version is The ITEX C Code Generator (on UNIX). |
When developing new systems or implementations of any kind the developing process is divided into well defined phases. Most commonly, the first phases involve some kind of specification and abstract design of the new system. After a while the implementation phase is entered and finally, when all parts are joined together, the test phase is activated.
In any case when a system is tested, we want to make sure that its behavior conforms to a set of well defined rules. TTCN was developed for the specification of test sequences. Unfortunately, as very few systems interpret or compile pure TTCN, we need to translate the TTCN notation into a language which can be compiled and executed. In the case of ITEX, the C Code Generator (CCG) translates TTCN to ANSI-C.
Even after the TTCN code has been translated, there are a couple of things that need to be taken care of. In this case, we mustadapt the generated code with the system it intends to test. This chapter describes how the ITEX C Code Generator is used. The adaption process is described in Adaption of the Generated Code.
Unfortunately, a test sequence description expressed in TTCN cannot easily be executed as it is. This, because the test notation is not executable and only few test environments interpret pure TTCN. A different approach to create an executable test suite (ETS), is to translate the formal test description into a language which can be compiled into an executable format.
The ITEX C Code Generator (CCG) translates TTCN into ANSI-C which can be compiled by an ANSI-C compiler. Figure 237 depicts the first step in the process of creating an ETS using the ITEX C Code Generator.
The generated code, called the TTCN runtime behavior, is only one of the two major modules of an ETS.
The second module which is needed includes test support functions which are dependent on the protocol used, the host machine, test equipment, etc. For this reason, it is up to the user to write this second module and in such way adapt the TTCN runtime behavior to the system he/she wants to test.
Figure 237 : Translating TTCN to ANSI-C
|
|
The adaption process is described in Adaption of the Generated Code. Figure 238 displays the anatomy of the final result.
Figure 238 : The anatomy of an ETS
|
|
|
|
To generate C code for the currently selected test document:
You can also open this dialog by the menu choice Build > Options or by the shortcut <Alt+F8>. |
Note that every active TTCN document has its own code generation settings, so in practice, two or more TTCN documents can be edited and/or viewed at the same time in ITEX, and yet have individual settings. (Multiple views on the same TTCN document does of course share the same settings.)
Figure 239 : Options dialog for code generation
|
|
The final thing you have to do is to set the output directory.
When you have set the options, click OK to start the generation of code. When the generation phase is started, information about the code generation will be displayed in the Log Manager. You will receive information about what parts that were generated and also some statistics about the amount of tables traversed during the generation phase.
If code is being generated for a large test suite, the status bar will show the progress.
Figure 237 shows how ANSI-C code is generated from a TTCN test suite. The generated code alone is not executable as it needs the test support functions module (see Figure 238).
In the case of the code generated from the CCG we also need a set of static functions which handle TTCN basics and other internal events. Even if these functions are vital for the successful compilation and execution of the generated code, the user should not have to worry about this part. These functions are gathered in a small set of static files which are compiled by the generated makefile and linked with the rest of the code.
As an example, Figure 240 displays the file structure of generated code. As can be seen in this example, template adaptor files were created by the CCG (as can be seen by looking at the time stamps for these files).
Figure 240 : The generated code
|
|
The makefile is the file containing a definition of how the code should be compiled and linked. This will not be needed if you are compiling the generated code in a separate development environment.
The adaptor.h and adaptor.c files are the files that contain the adaptation code. If code is generated for the first time, these files will be generated by the code generator with empty function templates for the user to implement. On the other hand, if these files are present in the target directory the user does not have to worry about getting them overwritten.
The ccgmkst is a file used by the code generator to know the status of the generated files. It is used to allow the code generator to calculate which files need to be re-generated and which do not.
The s_aux.c and s_aux.h files are files containing auxiliary functions and definitions used when running the code.
The s_type.c and s_type.h files contain code dealing with type definitions derived from the definitions in the test suite.
The s_decl.c and s_decl.h files contain code dealing with declarations derived from declarations in the test suite.
The s_const.c and s_const.h files contain code for the constraints defined in the test suite.
The s_dyn.c and s_dyn.h files contain information derived from the dynamic part in the test suite.
We are now ready to deal in greater detail with the adaptation phase which is the final phase to create an executable test suite. The adaptation process is described in Adaption of the Generated Code.