IBM
Contents Index Previous Next



TTCN Access in Relation to TTCN and ASN.1


TTCN Access is created for the purpose of accessing and traversing the contents of a TTCN test suite. As a basis for the development of TTCN Access, the TTCN-MP syntax productions in BNF [ISO/IEC 9646-3, appendix A] together with the ASN.1 standard [ISO/IEC 8824] have been used.

Differences

Every node in TTCN Access reflects a rule in the BNF. However there are some small differences between the BNF and TTCN Access:

The Present Nodes

The intention is to map the ASN.1 and TTCN standards as good as possible. In a perfect world this would mean that no extra nodes could be found in TTCN Access and that each rule in the standards would have exactly one corresponding node in TTCN Access. Some differences between the perfect world and our world are listed in detail below. Differences exist due to redundancies in the standardized grammar or design decisions made during the development of TTCN Access. The goal of any implementation of TTCN Access is to make as few changes compared to the perfect world as possible. However, some extra nodes have been added to TTCN Access, and in a few places the exact calling order of the pre/post functions has been altered to what we feel is a more straight forward approach for executable languages.

The SEQUENCE OF

The TTCN and ASN.1 notations at times allow for arbitrary many nodes to be grouped in lists of nodes or sequences of nodes. For example there is the SubTypeValueSetList rule of the ASN.1 standard and there is the AssignmentList rule of the TTCN standard. In both BNF notations a difference is made between lists that are allowed to be empty and those which must contain at least one element, corresponding to the {} and {}+ notation in the TTCN standard.

In TTCN Access no difference is made between the two forms of lists, since a well defined and simple access method is of prime interest. All lists are allowed to be empty, and it is the work of the Analyzer to ensure non-empty lists where appropriate. In the ASN.1 standard the non-empty lists are sometimes written by re-grouping already existing rules. This re-grouped structure will not be represented in TTCN Access. The decision does not alter the number of nodes or the names of nodes, but merely the visiting order when traversing the nodes, i.e. SubTypeValueSetList before SubTypeValueSet.

Example 165

ASN.1 rule SubTypeSpec:

SubTypeSpec ::= ( SubTypeValueSet SubTypeValueSetList ) 

becomes:

SubTypeSpec ::= ( SubTypeValueSetList )

In the TTCN standard there are nodes which contain an implicit grouping.

Example 166

TTCN BNF rule:

TestStepLibrary ::= ({TestStepGroup | TestStep})

becomes:

TS_ConstDcls ::= {TS_ConstDcl}+ [Comment].

Furthermore there are nodes that contain groupings without the list postfix name convention.

Example 167

TTCN BNF rule:

TimerOps ::= TimerOp {Comma TimerOp}.

Whenever necessary, a grouping or/and choice node will be inserted between rules in the TTCN standard. When nodes are created without corresponding node in any of the standards, the nodes will be named according to the convention used in the ASN.1 standard, i.e. these nodes will have postfix "List". Nodes which are a grouping but do not follow the naming convention will be left as they are.

OPTIONAL

In the BNF rules for TTCN-MP, the use of [ abc ] implies zero or one instance of abc. In the definition of TTCN Access the same effect is achieved by the use of the symbol "OPTIONAL" after the TTCN Access definition. If a TTCN Access element defined as "OPTIONAL" is not present in a specific instance, no TTCN Access representation for that specific field will be available. To detect whether or not a TTCN Access node defined as "OPTIONAL" is present or not, a boolean TTCN Access function will be necessary to apply to that TTCN Access node in order to verify the presence/absence of the parse tree related to the specific slotname.

FIELD

A difference between TTCN Access and the BNF rules is that TTCN Access views every BNF production reflecting a field in the TTCN-GR format to be optional even though the field is not defined as such in the BNF. The reason for this is that no TTCN Access tree can be built for a field unless a successful analysis has been performed on that field. If the analysis failed, the field will not carry any TTCN Access information and the field may not be accessed.

In TTCN Access all fields are marked with the symbol "FIELD". This "FIELD" symbol implies that the field may be empty. The field may be empty even though the field is not defined as optional in the BNF. To detect whether or not a field is present or not present, a boolean TTCN Access function will be necessary to apply to that TTCN Access node in order to verify the presence/absence of the parse tree related to the specific field. This extension is applicable to all fields except if a field is implemented in TTCN Access as a node of type TERMINAL. All TERMINAL types are strings and TTCN Access sees the absence of a TERMINAL as an empty string.

The Value Notation

The Common Value Notation

The value notations of the two standards must be unified. Some values are clearly within one standard only (SetValue for instance), while others are in both standards (7 for instance). Those values that have the same syntax in both standards are considered to belong to the TTCN standard. Note that the ASN.1 standard might specify some other chain of productions to reach such a value and that this chain of productions is not represented in TTCN Access.

The Expression Tree

The expression rule has been re-written since it is undesirable to have the flat representation from the standard. Instead a normal tree oriented representation of an expression is used. This means that the rules making up an expression are heavily changed.

The Base Nodes

Base nodes are the representation of the terminals in the TTCN Access tree. They can in most aspects be treated as strings, they can be printed directly for example. The base nodes are:

Note:

The Keyword class in ITEX Access 1.0 does not exist in ITEX Access 2.0. Neither of the standards has the notion of a keyword class/rule, and therefore there is no node/class named Keyword in ITEX Access 2.0. It has been replaced with ITEX Access node TERMINAL.

Tree Traversing in the Dynamic Part

An extension to the BNF adds the possibility to access the content of test cases, test steps and defaults, by using the logical tree structure of the test. This is achieved by adding a slot in the node type definition BehaviourLine named "children". By accessing that slot an TTCN Access object is returned that holds a vector of children to the current statement line. A child is a BehaviourLine with a level of indentation one greater that the preceding BehaviourLine.

Naming Conventions

As a basis for naming TTCN Access nodes, the names in the BNF for TTCN and ASN.1 have been used. There are some differences though, and they will be discussed and explained in this subsection.


http://www.ibm.com/rational
Contents Index Previous Next