![]() |
![]() |
![]() |
![]() |
![]() |
The TTCN Analyzer
The TTCN Analyzer in the TTCN Suite does a complete syntax check on both TTCN and ASN.1 (as it is used in TTCN). The Analyzer also performs a number of static semantic checks, mainly the uniqueness and existence of identifiers.
For implementation reasons, the Analyzer does not exactly follow the TTCN standard - some syntax restrictions and relaxations apply. These differences will not affect the vast majority of users, but for reference they are documented together with the standard syntax in Languages Supported in the TTCN Suite. This chapter also includes the static semantics supported by the TTCN Suite.
During analysis, the TTCN Suite compiles an extensive symbol table containing all named objects in the TTCN document and the references between them. This symbol table is used not only during the static semantic checks, but also by tools such as the Selector tool and the Compare tool.
The Analyzer can be called from various tools: from the Organizer, from a Browser, or from a Table Editor. It is possible to analyze an entire TTCN system, a whole TTCN document or just selected portions of a TTCN document (e.g. a single test case or all the PDU definitions).
The Analyzer considers a TTCN system to not contain any Flat View document, so it needs to be explicitly applied in order to analyze the flat view.
Using the Analyzer from the Organizer
Invoking the Analyzer from the Organizer is described in Analyze TTCN.
Using the Analyzer from a Browser
The Analyzer works either on the entire TTCN system or on selected items in the Browser it is applied on. Selections can either be made by using the mouse or by using the Selector tool (see Using More Complex Selections.
Selections can be arbitrary - the TTCN Suite will analyze each selected item independently.
To analyze an entire TTCN document, do a Select All in the TTCN document browser and then apply the Analyzer. Alternatively apply the Analyzer on the TTCN document in the Organizer (see Analyze TTCN).
Tools > Analyze
Conducts a syntax and static semantic check on the TTCN system or on the selected items (tables) in a Browser.
If an item is analyzed as incorrect, this will be recorded as an error message in the Analyzer log. Erroneous items are indicated by a black analysis bar in the Browser. On a color display this bar will be red.
Showing Progress
The Analyzer will, if invoked for a document or a whole system, display the progress made in the relevant Browser status window. This mechanism also provides the means to abort the analysis while it is running. Aborting is accomplished by clicking in the status window.
Tools > Analyze & Stop
Using the Analyzer from a Table Editor
When used from the Table Editor the Analyzer will be applied to the contents of that particular table.
Tools > Analyze
Tools > Analyze & Stop
Conducts a syntax and static semantic check on the TTCN system but stops on the first found error and replaces the table in the Table Editor with the table containing the found error.
When using the Table Editor, the On Field menu choice in the Help menu displays the TTCN BNF syntax applicable for the relevant field.
The Analyzer Dialog
The Analyzer uses the same dialog when started either from a Browser or a Table Editor:
Log Device
This option controls the log device for the Analyzer. The default value is Screen, but the log can be directed to a named file by choosing File or turned off altogether by choosing None.
For a full description of this command see The TTCN Suite Logs.
Enable Forced Analysis
Indicates that all selected items are going to be analyzed and no item will be skipped. An item is normally skipped if it is OK.
Retrieve ASN.1 Definitions
Indicates that the definitions of encountered ASN.1 references should be retrieved. An ASN.1 definition is retrieved if this option is set or if the definition has not been fetched before.
Only Browser Selection
Check this item if the analysis shall be restricted to the Browser selection (this option is not applicable if started from a Table Editor).
Verbosity
Full verbosity gives more detailed information. The following extra information is available with full verbosity:
Defined flags
The flags defined for the TTCN Suite preprocessor are separated by commas (see TTCN Suite Preprocessor).
File with defined flags
This field can be used to point to a file with flags defined for the TTCN Suite preprocessor. Use comma (",") to separate the flags in this file.
Error Messages
Errors detected during analysis are recorded in the log. For the fields in the header of a table the error messages have the general format:
==================================Table name and table typeField type 1Error messageField type 2Error message::Field type nError message==================================An error found in the Default Name (identifier) field of the Default Dynamic Behaviour called UT_DEFAULT:
=============================================Analysis messages in table: UT_DEFAULT of type: Default Dynamic BehaviourDefault Name:The referenced identifier UPPER_PCO is not declared.UT_DEFAULT (p : UPPER_PCO)----------------^=============================================In the body of a table (where the field type name does not uniquely define a field) the row number is also included:
Errors found in a Test Step table header (the Default field) and in the body (rows 1 and 2 of the Behaviour Description):
=============================================Analysis messages in table: ESTABLISH_CONNECTION of type: Test Step Dynamic BehaviourDefault:Mismatched number of parameters: is 1, should be 0.Row: (#1)Behaviour Description:The referenced identifier CR is of wrong type.UPPER_PCO ! CR------------^Row: (#2)Behaviour Description:The referenced identifier CC is of wrong type.UPPER_PCO ? CC------------^=============================================Showing Error Messages
It is possible to display the Analyzer error message (if any) that is associated with the field in a table that has the current input focus. To do this, select Error Messages from the Table Editor Show menu.
Resolving Forward References
During analysis, the TTCN Suite does two main tasks:
- It checks the syntax of the abstract TTCN document.
- It checks some of the static semantics of the TTCN document.
The syntax of TTCN is defined in ISO/IEC 9646-3 Annex A as a list of BNF productions or rules. See also The TTCN-MP Syntax Productions in BNF. The TTCN Suite checks all these rules except for a very few minor deviations; for more information, see The Restrictions in the TTCN Suite). If a rule is not followed in the TTCN document then this will be reported as an error by the Analyzer.
The static semantic rules of TTCN are also defined in Annex A of ISO/IEC 9646. These are in the form of text statements which limit the use of some of the syntax rules, usually in a specific context. TTCN Static Semantics and ASN.1 Static Semantics describe the static semantics which are controlled by the Analyzer. The static semantics currently supported are mainly of the following types:
- Identifiers (names) are checked for uniqueness with respect to the scoping rules defined in ISO/IEC 9646-3
- The existence of referenced TTCN objects (e.g. a Test Step) from another TTCN object (e.g. Test Case) is verified
- Type control and type restriction control
In order to achieve this, the Analyzer constructs a symbol table of all the named TTCN objects that it finds during analysis, e.g. variable names, type identifiers, tables, etc.
This symbol table is used by some of the other tools, such as the Selector and the Reporter. This explains why it is necessary to ensure that the TTCN document is analyzed before applying these tools - the symbol table is updated each time the TTCN document is analyzed.
It is important to note that TTCN allows forward references. For example a Test Step may attach another Test Step that is declared later on in the TTCN document, that is, the referenced (i.e. attached) Test Step, appears after the Test Step that has done the attach.
The Analyzer has a feature called back-pass designed to resolve forward references. The back-pass is automatically invoked at certain points in the analysis process.
Forward references usually appear in the context of ASP/PDU definitions, constraints and as the result of attachment statements in behaviour trees. This is the reason that the Analyzer does not traverse the items to be analyzed in exactly the listed order. The Analyzer order deviates from the listed order in a few places:
- Items in the PDU Type Definitions sub-tree are analyzed before items in the ASP Type Definitions sub-tree.
- Items in the PDU Constraint Declarations sub-tree are analyzed before items in the ASP Constraint Declarations sub-tree.
- Items in the Defaults Library sub-tree are analyzed before items in the Test Step Library sub-tree and those are analyzed before items in the Test Cases sub-tree.
- Items in the Declarations Part, Constraints Part and Dynamic Part are analyzed before any items in the Import Part (where applicable) and overviews.
ASN.1 External Type/Value References
References to ASN.1 definitions in external ASN.1 modules can occur in the following four TTCN tables:
- Test Suite Constant Declarations By Reference
- ASN.1 Type Definitions By Reference
- ASN.1 ASP Type Definitions By Reference
- ASN.1 PDU Type Definitions By Reference
In these tables there are three important fields to consider:
- Module Identifier (set by user)
The name of the ASN.1 Module. This should be the real name of the model, i.e. the name stated inside the module itself.- Type Reference/Value Reference (set by user)
This is the name of the desired type (or value).- Type Definition/Value (set automatically when fetched)
This is the field where the fetched type definition/value is copied into.The term definition is used below both to denote an ASN.1 type definition and an ASN.1 value.
When an ASN.1 reference is analyzed, the referred definition must be available to the Analyzer. In the pro formas for this kind of reference in the TTCN Suite, there is an extra column where both the definition and the parse tree is stored.
Since the ASN.1 module is accessible from the Organizer the Analyzer can fetch the definition. If the Analyzer encounters any reference to a type/value, the definition is fetched, given the type/value name and the module identifier, and copied into the external field before the field is analyzed. The operation of fetching the definition of the reference is controlled by an option in the Analyzer dialog. Important to note is that the fields Module Identifier and Type/Value Reference are not parsed. This means that if a change is made in either of these two fields, the row will not be analyzed and thus no fetching will be made. The solution to this is to set the Enable Forced Analysis in the Analyzer dialog when altering a reference. See The Analyzer Dialog.
To use external ASN.1 module references in the TTCN Suite, information about the referred ASN.1 module must be available. That is why the ASN.1 module must appear in the Organizer and a dependency must be defined from the ASN.1 Module to the TTCN document. See Dependencies.
Analysis can be invoked either from the TTCN Suite or from the Organizer. The only difference, regarding dependencies, is that when the analysis is made from the TTCN Suite the dependencies are fetched explicitly while the Organizer always precedes an analysis with a dependency update.
Analyzing ASN.1 References
This is the general algorithm when encountering an ASN.1 in the analysis phase.
- First of all, an attempted fetch is only made if no current definition exists or if the Analyzer fetching-option is selected.
- The actual fetching is made, see Retrieving External ASN.1 Definitions.
- If the definition is successfully fetched, the identifiers in the definition is converted to TTCN compatible syntax, see Syntactic Conversion.
- Finally a possible update of the definition is made and the analysis is continued.
Retrieving External ASN.1 Definitions
From the ASN.1 module a simple parse tree is built to access its contents. The parse tree is (re-)built when either it has not been built before or the ASN.1 module has been modified since last access. The parse tree for an ASN.1 module "lives" for the duration of the whole analysis phase.
Syntactic Conversion
The received definition must be manipulated in the following sense. All identifiers must be syntactically checked and altered if they include any characters that is disallowed in TTCN. The rule is that all `-' (dash) characters in an ASN.1 name is replaced by a `_' (underscore).
No special care has to be considered to ASN.1 comments since they are ignored when the parse tree is built from the module.
External type references in the type definition (e.g "... Module.Type...") will only be converted like above and left for the Analyzer to deal with (see also Restrictions).
Restrictions
These features are not supported in TTCN:
- External type reference identifiers on the form ModuleIdentifier.Type/Valuereference are not supported.
- Type/value references within the same ASN.1 module are not supported.
Furthermore there are restrictions in the ASN.1 Utilities when it is used to extract the external types and values. These restrictions are introduced in translating ASN.1 to SDL but since the same algorithm is used for extracting types and values, the restrictions are also relevant for the TTCN Suite. For more information, see Translation of ASN.1 to SDL.
Error Handling
Any error that occurs while finding, parsing or accessing the ASN.1 module will cause the old definition to remain. Only when a completely successful fetch has been made, the definition will be updated. Possible errors could be:
- The ASN.1 Module not found among the dependencies.
- The ASN.1 Module file could not be found or was not readable.
- The ASN.1 Module file was not syntactically correct.
- The referred type/value could not be found in the module.
See The ASN.1 Utilities for a more general view on ASN.1 usage.
TTCN Static Type Restriction Control
The TTCN standard defines a set of semantic rules for type definitions. In particular it defines simple types as types which might contain a true subset of the values which the parent type might contain. The Analyzer now analyzes the TTCN type system and also reports violations of these rules. This analysis is implemented as a post-pass over the related tables, and is only applied when the previous passes have been successful.
Furthermore, restriction control is performed on a number of other constructs in the TTCN language, thus facilitating the task of writing semantically correct TTCN documents. Most of the TTCN types and values are checked and thereby reducing the chance of programming errors slipping through to other tools which depends upon the correctness of the TTCN document.
Application of Static Type Restriction Control
Static Type Restriction Control is applied to at least the following TTCN tables and fields:
- Simple type definitions
- TTCN structured type / ASP / PDU / CM definitions
- Test Suite Constant Declarations
- Test Suite Variable Declarations
- TTCN Structured Type / ASP / PDU / CM Constraint declarations
- Actual constraint reference parameter lists
- Actual parameter lists
The Static Type Restriction Control also evaluates expressions in advance, where possible, and checks that the result does not violate the type restrictions of the field where the value is found. It operates on both types and values, regarding specific values as special cases of types.
Reducing Level of Restriction Control
Setting the environment variable ITEX_RESTRICT_LEVEL to the value NONE will disable the strict checking of type restrictions. This might be useful for allowing test suites with deliberate type errors pass through the analysis. A setting of SOME will relax the analysis somewhat, and is recommended before trying NONE. In order to get the most strict analysis (default), the value STRICT might be used.
Generating a Flat View
A Flat View is the part of the modular TTCN Suite environment that presents the tree structure of an expanded modularized TTCN source. This complete view includes all explicit defined objects in the TTCN system.
The Flat View interactive interfaces is similar to the Browser. Unlike the Browser, the Flat View is started (generated) from the Organizer.
The structure of the TTCN source in a Flat View is similar to a Test Suite. Neither the Import tables nor Export tables are displayed in a Flat View.
Generating a Flat View in a system, requires that at least the root document of the system to be connected to a file. The connected document must be of one of these types:
If this condition is not fulfilled, the operation Generate Flat View fails. Also if the current Flat View is modified or is locked (by any user) the operation fails.
If a Flat View is edited by the user, it must be saved in another document file. The user is asked for a new file name. Otherwise, if the existing Flat View file is not modified, it is overwritten by the new generated Flat View if the generation is redone.
For each TTCN system in the organizer only one instance of Flat View can be generated. A Flat View can be regenerated. A Flat View includes all explicit defined objects in the system at the time of the (re)generation.
The first time the Flat View in a system is generated, the name of the Flat View file is the same as the file name of the root document in the system if the name is not already used. The file extension for a Flat View file is .ifv.
An already existing Flat View is always connected to a document file. If this existing Flat View is in the current target directory (and neither is modified nor locked) the Flat View file is reused (the Flat View is regenerated). Otherwise a new Flat View file in the current target directory is used.
Algorithm
When the command Generate Flat View is invoked the following cases may occur:
No Flat View is Available
In other words this is the first time a Flat View is generated for the given system. A new Flat View is generated in the target directory. The name of the document file is generated. This name is derived from the file name of the root document in the system. A Flat View icon is added to the selected TTCN system in the Organizer and it is connected to the generated document file.
A Flat View is Available
If the file connected to the existing Flat View either is locked or modified the operation fails. If the existing file is not in the target directory do as the previous case except not to add a Flat View system node.
Otherwise if the existing file is in the current target directory the file is reused (the current document file name must have been derived from the file name of the root document in the system).
If the Flat View is modified, the operation (Generate Flat View) fails and the user is asked to save the Flat View (into another file) before regenerating.
Save a Flat View
A user modified Flat View must be saved as a document of type (non-modular) Test Suite in another file than the Flat View file.
When the user invokes the save operation from the Organizer, a new file name must be given otherwise the save operation fails. If the user invokes the save operation from the TTCN Suite a file browser pops up and the user is asked for a file name.
Merging Objects into a Flat View
A Flat View contains a copy of all explicitly defined objects in a system. When a Flat View is generated for a TTCN system, explicitly defined objects in each system node is merged into the Flat View. The merged objects may have the same name.
Objects of the following types are treated special:
Overview Tables
The main table in the Overview Part is the Test Suite Structure table. Depending on the type of the root node in the system the Overview tables in the generated Flat View contain the following information.
Test Suite (Modular or Non-Modular)
This type of system nodes have a Test Suite Structure table. The header of the corresponding table in the Flat View inherits the information in the header of the root table.
The Detailed Comments in the index tables are copied to the index tables in the Overview part of the generated Flat View.
TTCN Module
In this case the TTCN Module Exports table is the corresponding table to the Test Suite Structure table in the Flat View. The TTCN Module Exports contains two extra header fields: Objective and TTCN ModuleRef. These two fields are ignored when the Flat View is generated.
The Detailed Comments in the index tables are copied to the index tables in the Overview part of the generated Flat View.
Package
In this case there is no corresponding table to the Test Suite Structure table in the generated Flat View.
Import and Export Tables
These tables contain no explicit defined object and therefore they are ignored.
External Tables
These tables contain no explicit defined object and therefore they are ignored.
Multiple Tables
The objects in the multiple tables are added to the corresponding multiple table in the generated Flat View. The Detailed Comment in the multiple table is added to the Detailed Comment in the corresponding multiple table.
Single Tables
Add each single table to the appropriate place in the generated Flat View.
Group Nodes
For each group node if it does not exist already in the generated Flat View create a new group node.
http://www.ibm.com/rational |
![]() |
![]() |
![]() |
![]() |