![]() |
![]() |
![]() |
![]() |
![]() |
TTCN Static Semantics
The following are those static semantics from the TTCN and ASN.1 standards which are checked by the Analyzer tool in the TTCN Suite.
Test Suite
SuiteId shall be the same as the SuiteId declared in Test Suite Structure table (Suite Structure).
Test Case Index
Test Cases shall be listed in the order that they exist in the dynamic part.
Test Step Index
TestStepId shall not include a formal parameter list.
Test Steps shall be listed in the order that they exist in the dynamic part.
Default Index
DefaultId shall not include a formal parameter list.
Defaults shall be listed in the order that they exist in the dynamic part.
Test Suite Type Definitions
Wherever types are referenced within Test Suite Type Definitions those references shall not be recursive (neither directly or indirectly)
Simple Type Definitions
The base type1 shall be a Predefined Type or a Simple Type.
The set of values defined by a restriction must be a true subset of the values of the base type.
In specification of a particular length range, only non-negative INTEGER literals or the keyword INFINITY for the upper bound shall be used.
If Minus is used in SimpleValueList then LiteralValue shall be a number.
The restriction type shall be a list of distinguished values of the base type.
Where a range is used in a type definition either as a value range or as a length range (for strings) it shall be stated with the lower of the two values on the left.
An integer range shall be used only with a base type of INTEGER or a type derived from INTEGER.
Where a value list is used, the values shall be of the base type and shall be a true subset of the values defined by the base type.
LengthRestriction shall be provided only when the base type is a string type (i.e., BITSTRING, HEXSTRING, OCTETSTRING or CharacterString) or derived from a string type
The LiteralValues shall be of the base type
In RangeTypeLength:
LowerTypeBound shall be a non-negative number
LowerTypeBound shall be less than UpperTypeBoundIn IntegerRange:
LowerTypeBound shall be less than UpperTypeBoundStructured Type Definitions
Where elements may be of a type of arbitrarily complex structure; there shall be no recursive references.
The elements of Structured Type definitions are considered to be optional, i.e., in instances of these types whole elements may not be present.
A structure element Type shall be a PredefinedType, TS_TypeIdentifier, PDU_Identifier, or PDU.
If a Structured Type is used as a macro expansion, then the names of the elements within the Structured Type shall be unique within each ASP or PDU where it will be expanded.
The optional element length restriction can be used in order to give the minimum and maximum length of an element of a string type.
The set of values defined by LengthAttribute shall be a subset of the values of the base type.
ASN1 Type Definition
Types referred to from the type definition shall be defined in other ASN.1 type definition tables, be defined by reference in the ASN.1 type reference table or be defined locally in the same table, following the first type definition. Locally defined types shall not be used in other parts of the test suite.
ASN.1 type definitions used within TTCN shall not use external type references as defined in ISO/IEC 8824.
When ASN1 is used in a TTCN test suite, ASN1 identifiers from the following list shall be unique throughout the test suite:
a) identifiers occurring in an ASN1ENUMERATED type as distinguished values
b) identifiers occurring in a NamedNumberList of an ASN1 INTEGER typeEach terminal type reference used within the Type production shall be one of the following: ASN1_LocalType type reference, TS_TypeIdentifier or PDU_Identifier.
Test Suite Operation Definition
Only predefined types and data types as defined in the Test Suite Type definitions, ASP type definitions or PDU type definitions may be used as types for formal parameters. PCO types shall not be used as formal parameter types.
When a Test Suite Operation is invoked
- the number of the actual parameters shall be the same as the number of the formal parameters; and
- each actual parameter shall evaluate to an element of its corresponding formal type of parameter's.
Type in ResultType shall be a Predefined Type, TS_TypeIdentifier, PDU_Identifier or ASP_Identifier.
Test Suite Parameters Declarations
The type shall be a Predefined Type, TS_TypeIdentifier, PDU_Identifier or ASP_Identifier.
Test Case Selection Expression Definition
The expression shall use only literal values, Test Suite Parameters, Test Suite Constants and other selection expression identifiers in its terms.
The expression shall evaluate to a BOOLEAN value.
Expression shall not recursively refer (neither directly nor indirectly) to the SelExprIdentifier being defined by that Expression.
Test Suite Constant Declarations
The type shall be a predefined type, an ASN.1 type, a Test Suite Type or a PDU type.
The terms in the value expression shall not contain: Test Suite Variables or Test Case Variables.
The value shall evaluate to an element of the type indicated in the type column.
Test Suite Variable Declarations
Type shall be a Predefined Type, TS_TypeIdentifier, PDU_Identifier or ASP_Identifier.
The terms in the value expression shall not contain: Test Suite Variables or Test Case Variables.
Specifying an initial value is optional.
If an unbound Test Suite Variable is used in the right-hand side of an assignment, then it is a test case error.
The value shall evaluate to an element of the type indicated in the type column.
Test Case Variable Declarations
Type shall be a Predefined Type, TS_TypeIdentifier, PDU_Identifier or ASP_Identifier.
The terms in the value expression shall not contain: Test Suite Variables or Test Case Variables.
Specifying an initial value is optional.
The value shall evaluate to an element of the type indicated in the type column.
PCO Declarations
It is possible to define a PCO to correspond to a set of SAPs.
Timer Declarations
The terms in the value expression shall not contain: Test Suite Variables or Test Case Variables.
The timer duration shall evaluate to an unsigned positive INTEGER value.
ASP Type Definition
ASP type definitions may include ASN1 type definitions, if appropriate.
If only a single PCO is defined within a test suite then PCO_TypeIdentifier is optional. The PCO type shall be one of the PCO types used in the PCO Type Declaration proforma.
The macro symbol shall be used only with Structured Types defined in the Structured Types definitions.
Parameters may be of a type of arbitrarily complex structure, including being specified as a Test Suite Type (either predefined, Simple Type, Structured Type or ASN.1 type).
If a parameter is to be structured as a PDU, then its type may be stated either:
- as a PDU identifier to indicate that in the constraint for the ASP this parameter may be chained to a PDU constraint of a specific PDU type.
- as PDU to indicate that in the constraint for the ASP this parameter may be chained to a PDU constraint of any PDU type.
The boundaries shall be specified in terms of (non-negative) INTEGER literals, Test Suite Parameters, Test Suite Constants or the keyword INFINITY.
The parameters of ASP type definitions are considered to be optional, i.e., in instances of these types whole parameters may not be present.
The names of ASP parameters shall be unique within the ASP in which they are declared.
The optional attribute is Length.
In ASPs that are sent from the tester, values for ASP parameters that are defined in the Constraints Part shall correspond to the parameter or field definition. This means:
a) the value shall be of the type specified for that ASP parameter; and
b) In the case of substructured ASPs, either using Structured Types or ASN.1, the above rules apply to the fields of the substructure(s) recursively.ASN1 ASP Type Definitions
The PCO type shall be one of the PCO types used in the PCO declaration proforma.
If only a single PCO is defined within a test suite, specifying the PCO type in an ASP type definition is optional.
Types referred to from the ASP definition shall be defined in other ASN.1 type definition tables, be defined by reference in the ASN.1 type reference table or be defined locally in the same table, following the first type definition.
Locally defined types shall not be used in other parts of the test suite.
ASN1 ASP Type Definition By Reference
The PCO type shall be one of the PCO types used in the PCO declaration proforma.
If only a single PCO is defined within a test suite, specifying the PCO type in an ASP type definition is optional.
PDU Type Definition
The PCO type shall be one of the PCO types used in the PCO declaration proforma.
The macro symbol shall be used only with Structured Types defined in the Structured Types definitions.
Fields may be of a type of arbitrarily complex structure, including being specified as a Test Suite Type (either predefined, Simple Type, Structured Type or ASN.1 type).
If a field is to be structured as a PDU, then its type may be stated either
- as a PDU identifier to indicate that in the constraint for the PDU this field may be chained to a PDU constraint of a specific PDU type;
or- as PDU to indicate that in the constraint for the PDU this field may be chained to a PDU constraint of any PDU type.
The boundaries shall be specified in terms of non-negative INTEGER literals, Test Suite Parameters, Test Suite Constants or the keyword INFINITY.
The fields of PDU type definitions are considered to be optional, i.e., in instances of these types whole fields may not be present.
The names of PDU fields shall be unique within the PDU in which they are declared
The optional attribute is Length;
In PDUs that are sent from the tester, values for PDU fields that are defined in the Constraints Part shall correspond to the field definition. This means
- that the value shall be of the type specified for that PDU field;
and- in the case of substructured ASPs and/or PDUs, either using Structured Types or ASN.1, the above rules apply to the fields of the substructure(s) recursively.
The set of values defined by LengthAttribute shall be a true subset of the values of the base type.
LengthAttribute shall be provided only when the base type is a string type (i.e. BITSTRING, HEXSTRING, OCTETSTRING or CharacterString) or derived from a string type.
ASN1 PDU Type Definition
The PCO type shall be one of the PCO types used in the PCO declaration proforma.
If only a single PCO is defined within a test suite, specifying the PCO type in an PDU type definition is optional.
Types referred to from the ASP definition shall be defined in other ASN.1 type definition tables, be defined by reference in the ASN.1 type reference table or be defined locally in the same table, following the first type definition.
Locally defined types shall not be used in other parts of the test suite.
ASN1 PDU Type Definition By Reference
The PCO type shall be one of the PCO types used in the PCO declaration proforma.
If only a single PCO is defined within a test suite, specifying the PCO type in an PDU type definition is optional.
String Length Specifications
TTCN permits the specification of length restrictions on string types (i.e., BITSTRING, HEXSTRING, OCTETSTRING and all CharacterString types) in the following instances:
- when declaring Test Suite Types as a type restriction;
- when declaring simple ASP parameters, PDU fields and elements of Structured Types as an attribute of the parameter, field or element type;
and- when defining ASP/PDU or Structured Type constraints as an attribute of the constraint value. In the context of constraints, length restrictions can also be specified on values of type SEQUENCE OF or SET OF, thus limiting the number of their elements.
Alias Definitions
An Alias shall be used only to replace an ASP identifier or a PDU identifier within a single TTCN statement in a behaviour tree. It shall be used only in a behaviour description column.
Structured Type Constraint Declarations
If an ASP or PDU definition refers to a Structured Type as a substructure of a parameter or field (i.e., with a parameter name or a field name specified for it) then the corresponding constraint shall have the same parameter or field name in the corresponding position in the parameter name or field name column of the constraint and the value shall be a reference to a constraint for that parameter or field (i.e., for that substructure in accordance with the definition of the Structured Type).
ASP Constraint Declarations
If the ASP definition refers to a Structured Type by macro expansion (i.e., with <- in place of the ASP field name) then in a corresponding constraint either
- the individual elements from the Structured Type shall be included directly within the constraints.
- the macro symbol ( <- ) shall be placed in the corresponding position in the ASP field name column of the constraint and the value shall be a reference to a constraint for the Structured Type referenced from the ASP definition.
PDU Constraint Declarations
If the PDU definition refers to a Structured Type by macro expansion (i.e., with <- in place of the PDU field name) then in a corresponding constraint either:
- the individual elements from the Structured Type shall be included directly within the constraints;
or- the macro symbol ( <- ) shall be placed in the corresponding position in the PDU field name column of the constraint and the value shall be a reference to a constraint for the Structured Type referenced from the PDU definition.
Constraints Part
If an ASP and/or PDU is substructured, then the constraints for ASPs and/or PDUs of that type shall have the same tabular structure or a compatible ASN.1 structure (i.e., possibly with some groupings).
Structured Types expanded into an ASP or PDU definition by use of the macro symbol ( <- ) are not considered to be substructures. Constraints for such ASPs or PDUs shall either have a completely flat structure (i.e., the elements of an expanded structure are explicitly listed in the ASP or PDU constraint) or shall reference a corresponding structure constraint for macro expansion.
Whichever way the values are obtained, they shall correspond to the parameter or field entries in the ASP or PDU type definitions. This means
- that the value shall be of the type specified for that parameter or field.
- that the length shall satisfy any restriction associated with the type. (This will not be implemented.)
An expression in a constraint shall contain only literal values, Test Suite Parameters, Test Suite Constants, formal parameters and Test Suite Operations.
Neither Test Suite Variables nor Test Case Variables shall be used in constraints, unless passed as actual parameters.
Literal values, Test Suite Parameters, Test Suite Constants, Test Suite Variables, Test Case Variables and PDU or Test Suite Type constraints may be passed as actual parameters to a constraint in a constraints reference made from a behaviour description. The parameters shall not be of PCO type or ASP type.
In ASN.1 constraints, only ASP parameters and PDU fields declared as OPTIONAL may be omitted. These may be omitted either by using the Omit symbol or by simply leaving out the relevant ASP parameter or PDU field.
The constraint specification of an ASP and/or PDU shall have the same structure as that of the type definition of that ASP or PDU.
In tabular constraints, all ASP parameters and PDU fields are optional and therefore may be omitted using the Omit symbol, to indicate that the ASP parameter or PDU field is to be absent from the event sent.
An expression in a constraint shall contain only Values (including, for instance, ConstraintValue&Attributes), Test Suite Parameters, Test Suite Constraints, formal parameters, Component References and Test Suite Operations.
Matching Mechanisms
Complement: Each constraint value in the list shall be of the type declared for the ASP parameter or PDU field in which the complement mechanism is used.
ValueList: Each value in the ValueList shall be of the type declared for the ASP parameter or PDU field in which the ValueList mechanism is used.
Range: Ranges shall be used only on values of INTEGER type.
Range: A boundary value shall be either:
Range: The lower boundary shall be less than the upper boundary.
SuperSet: SuperSet is an operation for matching that shall be used on values of SET OF type. SuperSet shall be used only in ASN1 constraints.
SuperSet: The argument of SuperSet shall be of the type declared for the ASP parameter or PDU field in which the SuperSet mechanism is used.
SubSet: SubSet is an operation for matching that shall be used on values of SET OF type. SubSet shall be used only in ASN1 constraints.
SubSet: The argument of SubSet shall be of the type declared for the ASP parameter or PDU field in which the SubSet mechanism is used.
Permutation: Permutation an operation for matching that can be used only on values inside a value of SEQUENCE OF type. Permutation shall be used only in ASN1 constraints.
Permutation: Each element listed in Permutation shall be of the type declared inside the SEQUENCE OF type of the ASP parameter or PDU field.
Base Constraints and Modified Constraints
The name of the modified constraint shall be a unique identifier.
The name of the base constraint which is to be modified shall be indicated in the derivation path entry in the constraint header. This entry shall be left blank for a base constraint.
A modified constraint can itself be modified. In such a case the Derivation Path indicates the concatenation of the names of the base and previously modified constraints, separated by dots ( . ) A dot shall follow the last modified constraint name.
If a base constraint is defined to have a formal parameter list, the following rules apply to all modified constraints derived from that base constraint, whether or not they are derived in one or several modification steps:
- The modified constraint shall have the same parameter list as the base constraint. In particular, there shall be no parameters omitted from or added to this list
- The formal parameter list shall follow the constraint name for every modified constraint
- Parameterized ASP parameters or PDU in a base constraint fields shall not be modified or explicitly omitted in a modified constrain.
In tabular constraints Omit shall be denoted by dash ( - ). In ASN.1 constraints Omit is denoted by OMIT.
If the ASP or PDU definition refers to a parameter or field specified as being of metatype PDU then in a corresponding constraint the value for that parameter or field shall be specified as the name of a PDU constraint, or formal parameter.
The Behaviour Description
Statements in the first level of alternatives having no predecessor in the root or local tree belong to, shall have the indentation value of zero.
Statements having a predecessor shall have the indentation value of the predecessor plus one as their indentation value.
The parameters may provide PCOs, constraints, variables, or other such items for use within the tree.
Test Case root trees shall not be parameterized.
Formal parameters may be of PCO type, ASP type, PDU type, structure type or one of the other predefined or Test Suite Types.
TTCN Test Events
In the simplest form, an ASP identifier or PDU identifier follows the SEND symbol ( ! ) for events to be initiated by the LT or UT, or a RECEIVE symbol ( ? ) for events which it is possible for the LT or UT to accept.
If both a qualifier and an assignment are associated with the same event, then the qualifier shall appear first.
The tree header identifier used for local trees shall be unique within the dynamic behaviour description in which they appear, and shall not be the same as any identifier having a unique meaning throughout the test suite.
TTCN Expressions
The index notation is used to refer to elements (bits) of the ASN.1 BITSTRING type. BITSTRING is assumed to be defined as SEQUENCE OF {BOOLEAN}. If certain bits of a BITSTRING are associated with an identifier (named bit) then either the dot notation or this identifier shall be used to refer to the bit.
Where a parameter, field or element is defined to be a true substructure of a type defined in a Structured Type table, a reference to the elements in the substructure shall consist of the reference to the parameter, field or element identifier followed by a dot and the identifier of the item within that substructure.
Where a structure is used as a macro expansion, the elements in the structure shall be referred to as if it was expanded into the structure referring to it.
If a parameter, field or element is defined to be of metatype PDU no reference shall be made to fields of that substructure.
The ATTACH Construct
Tree reference may be Test Step Identifiers or tree identifiers, where
- A Test Step Identifier denotes the attachment of a Test Step that resides in the Test Step Library; the Test Step is referenced by its unique identifier
- A tree identifier shall be the name of one of the trees in the current behaviour description; this is attachment of a local tree.
Constraints may be passed as parameters to Test Steps. If the constraint has a formal parameter list then the constraint shall be passed together with an actual parameter list.
When a parameterized tree is attached:
- The number of the actual parameters shall be the same as the number of formal parameters
- Each actual parameter shall evaluate to an element of its corresponding formal parameter type
Labels and the GOTO Construct
A GOTO to a label may be specified within a behaviour tree provided that the label is associated with the first of a set of alternatives, one of which is an ancestor node of the point from which the GOTO is to be made.
A GOTO shall be used only for jumps within one tree, i.e., within a Test Case root tree, a Test Step tree a Default tree or a local tree. As a consequence, each label used in a GOTO construct shall be found within the same tree in which the GOTO is used.
Labels used within a tree shall be unique within a tree.
The Constraints Reference
The actual parameter list shall fulfil the following:
- the number of actual parameters shall be the same as the number of formal parameters;
and- each actual parameter shall evaluate to an element of its corresponding formal type.
Verdicts
A predefined variable called R is available in each Test Case to store any Intermediate results. R can take the values pass, fail, inconc and none. These values are predefined identifiers and as such are case sensitive.
R shall not be used on the left-hand side of an assignment statement.
PASS or P, FAIL or F and INCONC or I are keywords that are used in the verdicts column only. The predefined identifiers pass, fail, inconc and none are values that represent the possible contents of the predefined variable R. These predefined identifiers are to be used for testing the variable R in behaviour lines only.
A Verdict shall not occur in corresponding to entries in the behaviour tree which are any of the following: empty, an ATTACH construct, a GOTO construct, an IMPLICIT SEND or a RETURN.
Default References
Test Cases or Test Steps shall not be referred to as Defaults.
The actual parameter list shall fulfill the following:
- The number of actual parameters shall be the same as the number of formal parameters.
- Each actual parameter shall evaluate to an element of its corresponding formal type.
- All variables appearing in the parameter list shall be bound when the constraint is invoked. (This won't be implemented.)
Formal Parameters
The formal parameter names which may optionally appear as part of the following shall be unique within that formal parameter list, and shall not be the same as any identifier having a unique meaning throughout the test suite.
A formal parameter name contained in the formal parameter list of a local tree shall header shall take precedence over a formal parameter name contained in the formal parameter list of the Test Step in which it is defined, within the scope of that local formal parameter list.
DataObjectReferences
A reference to a component of one of the following types: SEQUENCE, SET and CHOICE is constructed using a dot notation; i.e., appending a dot and the name (component identifier) of the desired component to the data object identifier; the component identifier shall be used if specified.
1By Base Type we refer to the particular type in the Type production
http://www.ibm.com/rational |
![]() |
![]() |
![]() |
![]() |