This chapter contains a reference manual to the Analyzer in ITEX. You can also find information about how to find erroneous tables displayed in the Analyzer log.
The ITEX Browser and Table Editor are described in Editing TTCN Documents (in Windows).
See Introduction to ITEX in Windows for an overview of the ITEX tool-set.
|
Note: Windows version This is the Windows version of the chapter. The UNIX version is Analyzing TTCN Documents (on UNIX). |
The Analyzer in ITEX 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 The Languages Supported in ITEX. This chapter also includes the static semantics supported by ITEX.
During analysis, ITEX compiles an extensive symbol table containing all named objects in the TTCN document and the references between them.
In ITEX, the Analyzer works on the currently active TTCN document. It is also possible to analyze a TTCN document from the Organizer, see Analyze TTCN.
If an item is analyzed incorrectly, this will be recorded as an error message in the log. Items that have been found to be incorrect will be marked in red in all views of the document.
When you analyze a document for the first time, the Analyzer dialog will be opened and you may change the options. Once this has been done, the same options will be used and the dialog will not be opened the next time you start the analysis from a quick-button or a keyboard shortcut. However, the dialog will always be opened when you select an analyzer menu choice. You can also open the dialog by the menu choice Build > Options or by the shortcut <Alt+F8>.
Note that every active TTCN document has its own analysis 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. But multiple views of the same TTCN document do of course share the same settings.
|
|
The Analyzer reports all analysis results to the Log Manager. For each different test suite, a new tab will be created to allow the user to easily access the analysis information for different TTCN documents.
|
Note: The output of the analysis will not be available if the Log Manager is closed and the option Auto-Raise Log is unchecked. |
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.
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.
Enables a set of extra controls done on the TTCN code to find even more semantic errors in the analyzed item.
Gives more information.
Stops the analysis when the number of errors is reached.
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 type Field type 1 Error message Field type 2 Error message : : Field type n Error 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 Behaviour Default 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 Behaviour
Default:
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
------------^
=============================================
During analysis, ITEX does two main tasks:
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. ITEX checks all these rules except for a very few minor deviations; for more information, see The Restrictions in ITEX. 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:
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.
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. The reason for this is that the Analyzer does not traverse the selected items in exactly the listed order. The Analyzer order deviates from the listed order in three places:
References to ASN.1 definitions in external ASN.1 modules can occur in the following four TTCN tables:
In these tables there are three important fields to consider:
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 ITEX, there is an external column where both the definition and the parse tree is stored.
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.
This is the general algorithm when encountering an ASN.1 in the analysis phase.
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.
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 are 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).
The following features are not supported in TTCN:
Furthermore, there are restrictions in the ASN 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 ITEX (see Translation of ASN.1 to SDL).
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 fetching has been made, the definition will be updated. Possible errors could be:
See The ASN.1 Utilities for a more general view on ASN.1 usage.
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.
Static type restriction control is applied to at least the following TTCN tables and fields:
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.
When you are debugging a TTCN document, it may be useful to search for and display named tables. The search will include the entire current TTCN document -- no selections are required.
To find an erroneous table identified in the Analyzer log:
<Ctrl>-right-click the name of the table. You can also use the Finder to find a table. See Finding and Sorting Tables.