IBM
Contents Index Previous Next



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.

Note:

This rule can be relaxed for parameterless ASPs.

Figure 37 : Using constraint references in behavior lines

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.

Figure 38 : A parameterized constraint

The actual parameters are passed to the constraint when it is invoked from the constraints column in a behaviour description.

Figure 39 : Invocation of a parameterized constraint

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.

Figure 40 : Dynamic chaining of a parameterized PDU in an ASP

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.

Figure 41 : Execution of an alternative that contains SEND

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.

Figure 42 : Execution of an alternative that contains RECEIVE

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.

Figure 43 : Execution of an alternative that contains OTHERWISE


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