|
At most one address type should be bound to a port type. |
Add test |
|
|
At most one address type should be bound to a port type.
|
|
At most one map parameter list should be defined for a port type. |
Add test |
|
|
At most one map parameter list should be defined for a port type.
|
|
At most one unmap parameter list should be defined for a port type. |
Add test |
|
|
At most one unmap parameter list should be defined for a port type.
|
|
Directions shall be seen from the point of view |
Add test |
|
Directions shall be seen from the point of view of the test component owning the port with the exception of the test system interface
|
in identifies the direction of message sending or procedure call |
Add test |
|
in identifies the direction of message sending or procedure call
|
|
out identifies the direction of message receive, get reply or catch exception |
Add test |
|
out identifies the direction of message receive, get reply or catch exception from the point of view of the test component connected to the test system interface port.
|
|
|
Each port shall be defined as being |
Add test |
|
Each port shall be defined as being
|
|
|
message-based
|
|
|
|
procedure-based
|
|
|
Each port type definition shall have one or more lists indicating the allowed collection of types, procedure signatures with communication direction. |
Add test |
|
Each port type definition shall have one or more lists indicating the allowed collection of (message) types or procedure signatures together with the allowed communication direction.
|
|
Message-based ports shall be identified by the keyword message |
Add test |
|
|
Message-based ports shall be identified by the keyword message
|
|
Ports are bidirectional |
Add test |
|
|
Ports are bidirectional. The directions are specified by the keywords in (for the in direction), out (for the out direction) and inout (for both directions)
|
|
Ports used for the communication with the SUT may need to address specific entities within the SUT |
Add test |
|
Ports used for the communication with the SUT may need to address specific entities within the SUT
|
|
These formal parameters shall be value parameters. |
Add test |
|
|
These formal parameters shall be value parameters.
|
|
To support such addressing schemes, TTCN-3 allows to bind an address type to a port |
Add test |
|
|
To support such addressing schemes, TTCN-3 allows to bind an address type to a port
|
|
Values of this type may be used for addressing purposes in communication operations |
Add test |
|
Values of this type may be used for addressing purposes in communication operations (see clause 22.1) and be stored in variables
|
|
a signature is defined in the in direction for a procedure-based port |
Add test |
|
Whenever a signature is defined in the in direction for a procedure-based port, the types of all its inout and out parameters, its return type and its exception types are automatically part of the out direction of this port.
|
|
a signature is defined in the out direction |
Add test |
|
Whenever a signature (see also clause 14) is defined in the out direction of a procedure-based port, the types of all its inout and out parameters, its return type and its exception types are automatically part of the in direction of this port
|
|
procedure-based ports shall be identified by the keyword procedure within the associated port type definition. |
Add test |
|
|
procedure-based ports shall be identified by the keyword procedure within the associated port type definition.
|
|
several address schemes may be supported by one SUT at different ports |
Add test |
|
several address schemes may be supported by one SUT at different ports
|
|
the port type may have one map param and one unmap param declaration |
Add test |
|
|
For configuration purposes the port type may have one map param and one unmap param declaration indicating the allowed additional parameters for the respective operation
|