![]() |
![]() |
![]() |
![]() |
![]() |
PCOs and CPs
The TTCN supports an asynchronous communication model. Communication between the test components and the IUT or service provider is achieved via points of control and observation (PCOs). Communication between the test components themselves is achieved via coordination points (CPs).
The Communication Model
We shall use the same queue model to describe both PCOs and CPs:
- each PCO/CP has two unbounded first-in-first-out (FIFO) queues;
- one queue for SEND, and
- one queue for RECEIVE;
- exactly two parties must be connected to a single PCO or CP;
- the SEND queue for one party is the RECEIVE queue for the other, and vice versa.
Sending an ASP
The SEND action appends an ASP to the relevant PCO send queue. Even in the case of the IUT and the underlying service provider the send queue is considered to be unbounded, and that the IUT or service provider will always accept the ASPs sent by an LT or UT.
Receiving an ASP
A successful RECEIVE pops the ASP from the top of the RECEIVE queue. We shall see later that RECEIVE involves two steps:
Declaring PCO Types
All PCO types that are used in the test suite must be declared in the
- PCO Type Declarations
- the name the PCO Type
- the role of the PCO, which is either of the keywords LT or UT;
Case study 5: Declaration of the PCO Types N_SAP and X_SAP.
Declaring PCOs
All PCOs that are used in the test suite must be declared in the
- PCO Declarations
- the name the PCO
- the type of the PCO;
- the role of the PCO, which is either of the keywords LT or UT;
Case study 5: Declaration of the PCOs L and U.
Using PCOs and CPs
If the test suite only uses one PCO it is allowed to omit the PCO name in the TTCN statements that use them. If there is more than one PCO used (e.g. as in the distributed method) then the PCO and CP names (if any) must appear in the TTCN statements that use PCOs or CPs.
PCO and CP Snapshots
We have already described how a behaviour tree is executed by repeatedly looping through a set of alternatives until a statement line is successful. At the beginning of each loop a snapshot is taken of each input queue in every PCO or CP. Statements are evaluated on the basis of the state of the snapshots, not on the actual state of the PCO or CP queues. This has the effect of freezing time while a set of alternatives is being processed i.e. "prevents" the occurrence of an event in between snapshots. This means that the arrival of an ASP, PDU or CM during processing of a set of alternatives is not registered until the snapshots are updated.
Declaring CPs
All CPs that are used in the test suite must be declared. This is done in the CP Declarations table. Each PCO requires the following information:
Case study 6: Declaration of the coordination points called CP1 and CP2.
http://www.ibm.com/rational |
![]() |
![]() |
![]() |
![]() |