![]() |
![]() |
![]() |
![]() |
![]() |
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.
SubTypeSpec ::= ( SubTypeValueSet SubTypeValueSetList )SubTypeSpec ::= ( SubTypeValueSetList )In the TTCN standard there are nodes which contain an implicit grouping.
TestStepLibrary ::= ({TestStepGroup | TestStep})TS_ConstDcls ::= {TS_ConstDcl}+ [Comment].Furthermore there are nodes that contain groupings without the list postfix name convention.
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:
- Identifier
Has an associated type- Number
- All nodes having a single child of type BoundedFreeText (FullIdentifier or SO_SelExprId for example).
- Ostring, Cstring, Bstring and Hstring
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.
- No slot name, type name or type definition contains the symbol "&" as it is a reserved symbol in C++. It is replaced with "and" or "And" where appropriate.
- All type definitions start with an upper case letter (and are written in bold).
- All slot names start with a lower case letter.
- All type names start with an upper case letter.
http://www.ibm.com/rational |
![]() |
![]() |
![]() |
![]() |