![]() |
![]() |
![]() |
![]() |
![]() |
Constraint References
The TTCN SEND and RECEIVE statements indicate only which ASP or PDU type is to be transmitted or received. The constraints column in dynamic behaviour tables is used to state exactly which ASP or PDU value is to be sent, or is expected to be received. In other words, each SEND or RECEIVE statement must be accompanied by a constraints reference.
Parameterized Constraints
Constraints can be parameterized. That is, a constraint name may be followed by an optional formal parameter list. The formal parameters can be used in the value column of the constraint.
The actual parameters are passed to the constraint when it is invoked from the constraints column in a behaviour description.
The actual parameter must always resolve to a specific value. In a SEND constraint this is the value that will eventually be encoded and transmitted.
In a RECEIVE constraint the actual parameter resolves to the value that will be matched against the received value. No binding occurs, i.e. the received value is not bound to the actual parameter. If it wished to capture received values, then this should be done by explicit assignment statements in the behaviour descriptions.
Dynamic Chaining
A common use of parameterized constraints is to link ASPs, PDUs and structures dynamically rather than statically, as we have described earlier. The linking occurs when the actual constraint is passed as a parameter in the constraints reference.
An N_DATArequest is used to carry the DT_PDU of the previous example.
Sending and Receiving Constraints
The rules for sending a constraint are not the same as those for receiving one. We shall examine each of these aspects in turn.
Constraints and the SEND Statement
A constraint in the context of SEND specifies the values that will eventually be transmitted over the network (at this point in time we will ignore encoding issues). In TTCN this transmitted object is called the Send Object which is built from information in the relevant constraint. Note that assignments may override values derived from the constraint in the Send Object, which is why BUILD occurs before ASSIGNMENT_LIST.
Constraint Values and SEND
In the context of SEND we shall use the term received constraint value to mean the value of an ASP parameter, PDU field or CM field of the ASP, PDU or CM constraint that the test specifier wishes to transmit. The type of the constraint value is defined in the relevant ASP, PDU or CM definition.
Constraint values for Send Objects should always be fully specified at the time of transmission of the object.
Constraints and the RECEIVE Statement
The receipt of an ASP, PDU or CM is more complex than simply receiving an ASP, PDU or CM of the correct type. Testing often requires that the composition of the ASP, PDU or CM is checked in detail. This is achieved in TTCN by specifying a constraint that the ASP, PDU or CM is expected to match. The RECEIVE event can be considered successful only if all the conditions stipulated in the constraint are satisfied. We shall, therefore, extend our description of the RECEIVE statement line of The RECEIVE Statement to be:
Received Object
TTCN uses the term Received Object to mean the ASP, PDU or CM that is currently at the top of the relevant incoming PCO or CP queue, and is being checked during evaluation of a RECEIVE statement.
Constraint Values and RECEIVE
In the context of RECEIVE we shall use the term received constraint value to mean the value of an ASP parameter, PDU field or CM field of the ASP, PDU or CM field that the test specifier wishes the received value to match. Sometimes the received constraint value is called the expected value. The type of the expected value, defined in the relevant ASP, PDU or CM definition, is called the expected type.
Received Value
We shall use the term received value to mean the value of received object element. A received value is always, of course, a literal value, of a type compatible with the type of the corresponding element in the ASP, PDU or CM definition.
Constraints and the OTHERWISE Statement
Constraints are not used with the OTHERWISE statement. Remember, OTHERWISE will always match if the named PCO incoming queue is not empty. No other checking is required.
http://www.ibm.com/rational |
![]() |
![]() |
![]() |
![]() |