IBM
Contents Index Previous Next



TTCN Expressions


All values in TTCN are quite simply expressions. Note that the TTCN syntax allows the operands of expressions to be:

Exactly which variables etc. may be used in an expression depends on the context in which the expression is used. This aspect will be discussed in the relevant sections.

TTCN Operators

TTCN supports the following kinds of operators for use in expressions:

Arithmetic Operators

TTCN supports the following arithmetic operators for use only with operands of INTEGER type or derivations of INTEGER type:

Expressions that use these operators are called arithmetic expressions.

Equality Operator

The equal to and not equal to operators may be used on values of any type:

Expressions that use these operators must always evaluate to a BOOLEAN value:

Other Relational Operators

TTCN supports the following relational operators for use only with operands of INTEGER type or derivations of INTEGER type:

Expressions that use these operators must always evaluate to a BOOLEAN value:

Boolean Operators

TTCN supports the following logical operators for use only with operands of BOOLEAN type or derivations of BOOLEAN type:

Expressions that use these operators must always evaluate to a BOOLEAN value:

Qualifiers

A qualifier is an expression enclosed in square brackets:

The expression must evaluate to a BOOLEAN value.

Assignment Lists

A TTCN statement may be an ASSIGNMENT_LIST, i.e. a list of assignments, separated by commas and enclosed in parentheses:

The left-hand side (l.h.s.) of an assignment must resolve to a variable. In the context of SEND and RECEIVE statements the l.h.s. of an assignment may resolve to an ASP parameter reference, a PDU field reference or a structure element reference. The right-hand side (r.h.s.) of the assignment is an expression, which must evaluate to a value of a type compatible with the type of the l.h.s.

Note:

By type compatibility we quite simply mean that a value, a, of type A is type compatible with type B if a is a legal value of both type A and type B.

TTCN Operations

TTCN supports both a number of predefined operations and a mechanism that allows the definition of user operations. Operations may be used as operands in expressions.

Predefined Operations

TTCN now supports a number of predefined operations. More are expected to be added by the work on TTCN extensions. Currently these operations are:

User Defined Operations

TTCN allows the informal definition of user define operations. A possible approach is to use a programming language to `describe' the operation.

Note:

The TTCN amendment (PDAM 2) is currently exploring ways of how user operation descriptions can be made more `formal'.

Like the predefined operations user defined operations may be used in both behaviour trees and as `values' in constraints.

Each user defined operations is declared in a Test Suite Operations table.

Case study 11: Definition of a user defined operation.

Figure 28 : Test Suite Operation Definition

If an operator does not have any arguments it should be called with an empty actual parameter list, e.g. DATE ( ).

Note:

Since TTCN Suite operations are implemented manually with the means of a target language, pay careful attention to the way memory is allocated/freed inside an operation.

There are 2 types of memory TTCN runtime is using: permanent memory and temporary memory.

Permanent memory is used for permanent test case entities (like variables) that live longer than one step (one line) of a test case, temporary memory is used for temporary values that are created during execution of one step of a test case.

Temporary memory is automatically released after execution of each line of a test case:

IcGetTemporaryMemoryStart(&tmpmem_mark);
prev_line = line;
switch (line) {
case 1:
...
case 2:
...
}
...
IcReleaseTemporaryMemory(tmpmem_mark);

IcGetTemporaryMemoryStart(&tmpmem_mark) is called before line execution, IcReleaseTemporaryMemory(tmpmem_mark) is called after line execution.

Temporary memory is a preallocated memory buffer. void* VCMALLOC(unsigned int size, Bool temporary) function has got a parameter "Bool temporary" that says if allocated memory should be acquired from the preallocated memory buffer. If it is GcFALSE the system allocation function malloc will be called to create new memory. void VCFREE(void* ptr) deallocates allocated memory, but if the memory is temporary the function will do nothing.

There is a Bool IcIsTemporary(void* pointer) predicate that checks if a pointer is in the temporary heap.
void IcGetTemporaryMemoryStart(IcTmpMemMark *mark) and void IcReleaseTemporaryMemory(IcTmpMemMark pos) functions are used to save the position in temporary memory heap and sometime later release all memory acquired after that position.

Test Suite Operation parameters are passed by value and all parameters are allocated in temporary memory during operation call. If an operation returns some value to the test suite, it is also expected to be allocated in temporary memory. Returned value is assigned to some further value, and it is not freed with a separate command.

For example, test suite operation that converts a hex string to a bit string should create the result value like this:

result = VcMkTempValue(GcBITSTRINGD);
EGciSetSTRING(result, bstr);

Using GciMkBIT_STRING(bstr) function for creating the return value will lead to memory leaks, because the value will be allocated in permanent memory and it will not be automatically freed.


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