![]() |
![]() |
![]() |
![]() |
![]() |
Specifying ASP, PDU and CM Values
The previous section showed how to define structured ASP, PDU and CM types. However, when a tester SENDs or RECEIVES an ASP, PDU or CM it is necessary to specify in detail actual values of these complex types.
Values, or instances, of complete ASPs, PDUs and CMs are called constraints. For each ASP, PDU or CM definition table there should be at least one corresponding constraint table.
The constraint declaration tables are:
- ASP Constraint Declaration;
- PDU Constraint Declaration;
- Structured Type Constraint Declarations;
- CM Constraint Declaration.
Static and Dynamic Chaining
ASPs, PDUs and structured types may be chained to allow the construction of arbitrarily complex ASPs and PDUs. Static chaining means that the actual name of a PDU constraint or structure constraint appears as the value of an ASP parameter, PDU field or structure element, i.e. the structure is hardwired by symbolic references. Dynamic chaining means that the linking occurs when the actual constraint is passed as a parameter in the constraints reference.
Complex ASN.1 Values
The concept of chaining is an integral part of ASN.1, although it is not described in those terms. It is expressed by the use of type references. If a reference is made from one type definition to another then there should be a corresponding value for that reference in the relevant constraints.
ASP Constraints
Generally, for every ASP type definition, there will be at least one ASP constraint declaration. However, some service definitions include ASPs that do not have parameters. In such cases, a constraint is not necessary. The same may apply to coordination messages, but it does not apply to PDUs. A PDU without fields is a nonsense.
ASP constraints are very similar to PDU constraints, which are more fully described in the next section. The rules that apply to PDU constraints, also apply to ASP constraints.
Case study 12a: A typical ASP constraint. Note that the constraint is parameterized - more about that later.
The DefCon Utility
The DefCon utility is a TTCN Access application that traverses a test suite in .itex format and generates default constraints for all ASN.1 ASP:s found in the test suite. The output is directed to the standard terminal output in .mp format.
Case study 12b: A test suite named MyTest.itex contains some ASN.1 ASP:s. To generate default constraints for these ASP:s and to store the constraints in a file named MyTestConstraints.mp, the DefCon utility should be called like this:
c:\> defcon MyTest.itex > MyTestConstraints.mpThe generated constraints can then be merged into the .itex file with the Autolink Merge utility. See Merging TTCN Test Suites in the TTCN Suite for more information.
Naming generated constraints
When calling DefCon, optional arguments may be provided. These arguments specify which pre- and/or postfixes to use for naming the generated constraints.
The default naming scheme is defined like this:
- If there is an ASN.1 ASP named "MyASP" in the test suite, DefCon generates a constraint named "MyASPConstraint" from it. In other words, the default prefix is empty and the default postfix is "Constraint".
The syntax for changing pre- and postfixes is:
defcon [-pre <prefix>] [-post <postfix>] <testsuite>
Pre- and postfix strings are given without quotes on the command line.
PDU Constraints
Generally, for each field in the PDU type definition, there will be a corresponding field in the constraint. The value of the constraint field must be compatible with the type definition for that field. We shall see later how fields may be omitted or replaced, and how the derivation path entry should be used. We shall also see how constraint values are matched.
Case study 13: Declaration of an X_PDU constraint using the TTCN tabular format.
Structured Type Constraints
Constraints on structured type definitions and ASN.1 type definitions are constructed in the same way as ASPs and PDUs. Just as the type definitions may be used by both ASP and/or PDU type definitions, so also may the constraints.
When the TTCN tabular format is used the structure of the constraints shall be the same as the structure of the type definitions. That is, if a PDU field is defined as being of structure type then there will be one constraint for the PDU and one for the structure.
This rule is relaxed in ASN.1. The structure must be compatible but there need not necessarily be a one-to-one correspondence between the type tables and the constraint tables.
Case study 14: Declaration of a structured type constraint using TTCN tabular format.
CM Constraints
Coordination message constraints are also similar to PDU constraints.
Case study 15: Declaration of a CM constraint using TTCN tabular format
http://www.ibm.com/rational |
![]() |
![]() |
![]() |
![]() |