Technical Documentation: General Design of the CH

From Go4IT project

Contents 1 == == 1.Introduction == == 2 == == 2.Use Cases == == 3 == 2.1. UC-1: local control component creation == 4 2.1.1. Summary 5 2.1.2. Rationale 6 2.1.3. Actor 7 2.1.4. Preconditions 8 2.1.5. Basic Course of Events 9 2.1.6. Alternative Paths 10 2.1.7. Postconditions 11 == 2.2. UC-2: local MTC creation == 12 2.2.1. Summary 13 2.2.2. Rationale 14 2.2.3. Actor 15 2.2.4. Preconditions 16 2.2.5. Basic Course of Events 17 2.2.6. Alternative Paths 18 2.2.7. Postconditions 19 == 2.3. UC-3: component handling for test case execution within control == 20 2.3.1. Summary 21 2.3.2. Rationale 22 2.3.3. Actor 23 2.3.4. Preconditions 24 2.3.5. Basic Course of Events 25 2.3.6. Alternative Paths 26 2.3.7. Postconditions 27 == 2.4. UC-4: component handling for direct test case execution == 28 2.4.1. Summary 29 2.4.2. Rationale 30 2.4.3. Actor 31 2.4.4. Basic Course of Events 32 2.4.5. Alternative Paths 33 2.4.6. Postconditions 34 == 2.5. UC-5: propagation of map/connect == 35 2.5.1. Summary 36 2.5.2. Rationale 37 2.5.3. Actor 38 2.5.4. Basic Course of Events 39 2.5.5. Alternative Paths 40 2.5.6. Postconditions 41 == 2.6. UC-6: propagation of unmap/disconnect == 42 2.6.1. Summary 43 2.6.2. Rationale 44 2.6.3. Actor 45 2.6.4. Basic Course of Events 46 2.6.5. Alternative Paths 47 2.6.6. Postconditions 48 == 2.7. UC-7: stop a test case == 49 2.7.1. Summary 50 2.7.2. Rationale 51 2.7.3. Actor 52 2.7.4. Basic Course of Events 53 == 2.8. UC-10: stop control == 54 2.8.1. Summary 55 2.8.2. Rationale 56 2.8.3. Actor 57 2.8.4. Basic Course of Events 58 2.8.5. Alternative Paths 59 2.8.6. Postconditions 60 == 2.9. UC-9: termination of control after error == 61 2.9.1. Summary 62 2.9.2. Rationale 63 2.9.3. Actor 64 2.9.5. Alternative Paths 65 2.9.6. Postconditions 66 == 2.10. UC-10: termination of a test case after error == 67 2.10.1. Summary 68 2.10.2. Rationale 69 2.10.3. Actor 70 2.10.4. Basic Course of Events 71 2.10.5. Alternative Paths 72 2.10.6. Postconditions 73 == 2.11. UC-11: reset == 74 2.11.1. Summary 75 2.11.2. Rationale 76 2.11.3. Actor 77 2.11.4. Basic Course of Events 78 2.11.5. Alternative Paths 79 2.11.6. Postconditions 80 == 2.12. UC-12: local intercomponent communication == 81 2.12.1. Summary 82 2.12.2. Rationale 83 2.12.3. Actor 84 2.12.4. Basic Course of Events 85 2.12.5. Alternative Paths 86 2.12.6. Postconditions 87 == 2.13. UC-13: execute test case to TRI == 88 2.13.1. Summary 89 2.13.2. Rationale 90 2.13.3. Actor 91 2.13.4. Basic Course of Events 92 2.13.5. Alternative Paths 93 2.13.6. Postconditions 94 == == 3. Functional Requirements == == 95 == 3.1. FR-1: TCI compliant == 96 3.1.1. Summary 97 3.1.2. Rationale 98 3.1.3. Requirements 99 3.1.4. References 100 == == 4. Nonfunctional Requirements == == 101 == 4.1. NF-1: Documentation == 102 4.1.1. Summary 103 4.1.2. Rationale 104 4.1.3. Requirements 105 4.1.4. References 106 == 4.2. NF-2: Platform Compatibility == 107 4.2.1. Summary 108 4.2.2. Rationale 109 4.2.3. Requirements 110 4.2.4. References 111 == 4.3. NF-3: Dependency on other parties == 112 4.3.1. Summary 113 4.3.2. Rationale 114 4.3.3. Requirements 115 4.3.4. References 116 == == 5. See Also == ==

== == 1.Introduction == ==

This document intends to provide a preliminary introduction to the design of the Component Handling (hereafter, CH) entity within a TTCN-3 test system. This entity is responsible for implementing communication between distributed test system entities. The CH entity provides the means to synchronize test system entities which might be distributed onto several nodes. However, in our design goal, there are only one TE, SA, and PA. User, test case, MTC, PTC, TM, TE, CH, SA, and PA are on the same node/test device.

== == 2.Use Cases == ==

This section contains a set of use cases that describe the external behaviour of this CH module. A use case is a description of a specific interaction that a user (or another module) may have with this module. Use cases are deceptively simple tools for describing the functionality of the software.

A use case is a simple, straightforward tool that can be used to completely describe all the behaviour of a piece of software. It contains a textual description of all the ways that the intended users could work with the software through its interface. Use cases do not describe any internal workings of the software, nor do they explain how that software will be implemented. They simply show how the steps that the user follows to use the software to do his work. All the ways the users interact with the software can be described in this manner.

This section will contain multiple use cases, enough to define all of the interactions the users will have with the module.

== 2.1. UC-1: local control component creation ==

2.1.1. Summary

CH creates the control component on the node where the user interface to the test management TCI-TM resides.

2.1.2. Rationale

Whenever the control part of a TTCN-3 module is executed, a control component is created.

2.1.3. Actor

TE, CH, TM

2.1.4. Preconditions

The test system has to be initialized and the control part of a TTCN-3 module is to be executed.

2.1.5. Basic Course of Events

Step 1: TM issues start of the control part;

Step 2: A creating test control component request is sent to CH;

Step 3: CH tells TE to create a control component;

Step 4: CH gets the control component ID from TE and then gives it to TM;

Step 5: The control part is started.

2.1.6. Alternative Paths

In step 4, CH should get the component ID from TE. If this doesn't occur, the control part will not be started.

2.1.7. Postconditions

The selected test case has been executed

== 2.2. UC-2: local MTC creation ==

2.2.1. Summary

It demonstrates the local creation of the main test component.

2.2.2. Rationale

A main test component is created whenever a test case is executed. Local is meant for two cases: On the same node where the user interface to the test management TCI-TM resides (when a test case is started directly); Or On the same node where the control component resides (when a test case is executed from a control part).

2.2.3. Actor

TE, CH, TM

2.2.4. Preconditions

The test system has to be initialized and a test case is to be executed.

2.2.5. Basic Course of Events

Step 1: TM issues start of the test case;

Step 2: A creating local main test component request is sent to CH;

Step 3: CH tells TE to create a main test component;

Step 4: TE creates a main test component and passed the ID back to CH.

2.2.6. Alternative Paths

In step 4, CH should get the component ID from TE. If this doesn't occur, the MTC will not be started.

2.2.7. Postconditions

The created local MTC has been executed.

== 2.3. UC-3: component handling for test case execution within control ==

2.3.1. Summary

It demonstrates the handling of components for the test case execution within a control part.

2.3.2. Rationale

When control part is selected to be executed, test cases included in the control part must be executed according to the statements included in the control part.

2.3.3. Actor

TE, CH, TM

2.3.4. Preconditions

The test system has to be initialized and a module has to be selected.

2.3.5. Basic Course of Events

Step 1: The user selects a TTCN-3 module to be executed;

Step 2: The TM selects the control part of the module;

Step 3: TE sends request of creating control component to CH;

Step 4: CH informs TE to create control component;

Step 5: After a control component is created and TE sends its component ID to CH;

Step 6: CH returns ID to TE and TE propagates it to TM;

Step 7: The control part is started; For each test case to be executed within the control part a main test component is created and the component ID is returned to the control component;

Step 8: TE sends request of creating main test component to CH;

Step 9: CH informs TE to create main test component;

Step 10: After a main test component is created and TE sends its component ID to CH;

Step 11: CH returns ID to TE;

Step 12: TE sends request of starting MTC to CH;

Step 13: CH informs TE to start MTC and TE propagates the start information to TM;

Step 14: When MTC terminates, TE requests for termination and verdict information of MTC by sending verdict information to CH;

Step 15: TE is notified of termination and verdict information of MTC from CH;

Step 16: TE informs the final verdict information to TM.

2.3.6. Alternative Paths

In step 5, CH should get the control component ID from TE. If this doesn't occur, control part will not be created.

In step 11, CH should get the parallel test component ID from TE. If this doesn't occur, MTC will not be started.

2.3.7. Postconditions

The test cases included in the control part of a module have been executed.

== 2.4. UC-4: component handling for direct test case execution ==

2.4.1. Summary

It demonstrates how test components are handled when a test case is executed directly, i.e. outside a control part.

2.4.2. Rationale

Test case can be executed directly outside a control part.

2.4.3. Actor

TE, CH, TM

2.4.4. Basic Course of Events

Step 1: The user selects a TTCN-3 module to be executed, and then TM selects a test case to be executed and informs TE the test case;

Step 2: TE sends request of creating MTC to CH;

Step 3: CH informs TE to create MTC;

Step 4: TE sends request of starting MTC to CH;

Step 5: TE sends ID of MTC to CH;

Step 6: CH returns ID of MTC to TE;

Step 7: CH informs TE to start MTC test;

Step 8: TE informs TM test case started;

Step 9: TE sends request of creating PTC to CH;

Step 10: CH informs TE to create PTC;

Step 11: TE sends ID of PTC to CH;

Step 12: CH returns ID of PTC to TE;

Step 13: TE sends request of starting PTC to CH;

Step 14: CH informs TE to start PTC test;

Step 15: When PTC terminates, TE requests for termination and verdict information of PTC by sending verdict information of PTC to CH;

Step 16: TE is notified of termination and verdict information of PTC from CH;

Step 17: When MTC terminates, TE requests for termination and verdict information of MTC by sending verdict information to CH;

Step 18: TE is notified of termination and verdict information of MTC from CH;

Step 19: TE informs the final verdict information to TM.

2.4.5. Alternative Paths

In step 6, CH should get the main test component ID from TE. If this doesn't occur, MTC will not be started. In step 12, CH should get the parallel test component ID from TE. If this doesn't occur, PTC will not be started.

2.4.6. Postconditions

The selected test case has been executed.

== 2.5. UC-5: propagation of map/connect ==

2.5.1. Summary

It demonstrates how ports are mapped.

2.5.2. Rationale

When there is a map operation request, CH will translate map request for mapping.

2.5.3. Actor

TE, CH, SA

2.5.4. Basic Course of Events

Step 1: TE sends a map operation request to CH. (TE runs the test component the port of which has to be mapped);

Step 2: CH translates the map request to TE;

Step 3: TE shall map the indicated ports to one another;

Step 4: TE translates the map to SA, and then the SA can establish a dynamic connection to the SUT for the referenced TSI (Test System Interface) port.

2.5.5. Alternative Paths

In step 2, CH should translate the map request to TE. If this doesn't occur, dynamic connection will not be established.

2.5.6. Postconditions

The required mapping has been established.

== 2.6. UC-6: propagation of unmap/disconnect ==

2.6.1. Summary

It demonstrates how ports are unmapped.

2.6.2. Rationale

When there is a unmap operation request, CH will translate unmap request for unmapping.

2.6.3. Actor

TE, CH, SA

2.6.4. Basic Course of Events

Step 1: TE sends a unmap operation request to CH. (TE runs the test component the port of which has to be unmapped);

Step 2: CH translates the unmap request to TE;

Step 3: TE shall unmap the indicated ports to one another;

Step 4: TE translates the unmap to SA, and then the SA shall close a dynamic connection to the SUT for the referenced TSI port.

2.6.5. Alternative Paths

In step 2, CH should translate the unmap request to TE. If this doesn't occur, dynamic connection will be not closed.

2.6.6. Postconditions

The required dynamic connection has been closed.

== 2.7. UC-7: stop a test case ==

2.7.1. Summary

It demonstrates how a test case is stopped from the test management during test case execution.

2.7.2. Rationale

When there is a test case stop request, CH will inform TE to stop and reset.

2.7.3. Actor

TE, CH, TM

2.7.4. Basic Course of Events

Step 1: When a test case is being executed, TM informs TE that it wants to stop it;

Step 2: TE sends reset request to CH;

Step 3: TE informs TM test case termination with ERROR verdict;

Step 4: CH informs TE to stop running test components and reset the system.

2.7.5. Alternative Paths In step 4, CH should receive reset request from the TE. If this doesn't occur, all test components will still run.

2.7.6. Postconditions

All running test components will stop and system will reset.

== 2.8. UC-10: stop control ==

2.8.1. Summary

It demonstrates how a control part is stopped from the test management during control part execution.

2.8.2. Rationale

When there is a control part stop request, CH will inform TE to stop running control component.

2.8.3. Actor

TE, CH, TM

2.8.4. Basic Course of Events

Step 1: TM informs TE that it wants to stop the control part current being executed;

Step 2: TE sends reset request to CH;

Step 3: CH informs TE where the control component is running to reset.

2.8.5. Alternative Paths

In step 2, CH should receive reset request from the TE. If this doesn't occur, the control part will still run.

2.8.6. Postconditions

The control part will stop and reset.

== 2.9. UC-9: termination of control after error ==

2.9.1. Summary

It demonstrates the handling of error situations during the execution of a control part when no test case is being executed.

2.9.2. Rationale

A control part must be stopped when an error during its execution is detected.

2.9.3. Actor

== TE, CH, TM 2.9.4. Basic Course of Events ==

Step 1: TE informs TM an error is detected during executing;

Step 2: TM informs TE that must stop the control part current being executed;

Step 3: TE sends reset request to CH and informs TM that the control part of the selected module has just terminated execution;

Step 4: CH informs the TE where the control component is running to reset.

2.9.5. Alternative Paths

In step 3, CH should receive reset request from TE. If this doesn't occur, the control part will not stop.

2.9.6. Postconditions

The control part will stop and system will reset.

== 2.10. UC-10: termination of a test case after error ==

2.10.1. Summary

It demonstrates the handling of error situations during the direct execution of a test case.

2.10.2. Rationale

When a test case is running, an error may occur during the execution of a test case. Once an error occurs, it must be terminated.

2.10.3. Actor

TE, CH, TM

2.10.4. Basic Course of Events

Step 1: TE informs TM an error is detected during direct executing;

Step 2: TM informs TE that must stop the test case current being executed;

Step 3: TE sends reset request to CH;

Step 4: CH informs TE to stop running test components and reset the system.

Step 5: After TE informs PA and SA to reset, TE informs TM test case termination with ERROR verdict.

2.10.5. Alternative Paths

In step 3, CH should receive reset request from TE. If this doesn't occur, TE will not stop the running test components.

2.10.6. Postconditions

TE stop running test components and the system reset.

== 2.11. UC-11: reset ==

2.11.1. Summary

It demonstrates the reset of a test case.

2.11.2. Rationale

System can reset

2.11.3. Actor

TE, CH

2.11.4. Basic Course of Events

Step 1: TE sends reset request to CH;

Step 2: CH informs TE to stop running test components;

Step 3: CH informs TE to reset.

2.11.5. Alternative Paths

In step 1, CH should receive reset request from TE. If this doesn't occur, TE will not stop the running test components.

2.11.6. Postconditions

TE stop running test components and the system reset.

== 2.12. UC-12: local intercomponent communication ==

2.12.1. Summary

It demonstrates the communication between test components (main test component or parallel test components).

2.12.2. Rationale

CH is responsible for the communication between test components.

2.12.3. Actor

TE, CH

2.12.4. Basic Course of Events

Step 1: One component tells CH it wants to communicate with another component;

Step 2: CH transmits the message to TE and enqueues the data for communication.

2.12.5. Alternative Paths

None

2.12.6. Postconditions

Communications between test components succeed.

== 2.13. UC-13: execute test case to TRI ==

2.13.1. Summary

It demonstrates how the TRI is informed about the execution of a test case so that it can set up and initialize system ports when needed.

2.13.2. Rationale

CH can communicate with TE.

2.13.3. Actor

TE, CH

2.13.4. Basic Course of Events

Step 1: Before TE starts the test case on the MTC it tells CH it wants to execute a test case;

Step 2: CH responds to TE.

2.13.5. Alternative Paths

None

2.13.6. Postconditions

A test case has been executed.

== == 3. Functional Requirements == ==

== 3.1. FR-1: TCI compliant ==

3.1.1. Summary

CH module has to be TCI compliant.

3.1.2. Rationale

All JRA2 development must be TTCN-3 standards compliant.

3.1.3. Requirements

CH module must to be compliant with ETSI standard (TCI).

3.1.4. References

See [1], [2]

== == 4. Nonfunctional Requirements == ==

== 4.1. NF-1: Documentation ==

4.1.1. Summary

Detailed description of developed software

4.1.2. Rationale

Documentation is a communicable material needed to describe the structure and components implemented. It also includes the programmer manual. Correct, up to date, and complete documentation should help in reaching a good quality for:  Maintainability (CH can be modified at the lowest possible cost)  Reliability (ability of the TM to perform and maintain its functionality in routine and also in different unexpected circumstances)  Extensibility (adding new functionalities to the TM without affecting the functionalities already implemented)

4.1.3. Requirements

The documentation will consist of:  Software architecture of CH following the developer's guide.  Dependency with other parties (using a relationship or flow diagrams)  Flow diagrams for each TCI routine implemented (or functions using TCI routines) The documentation will be divided into component parts and for each one the following documentation will be provided:  Component description  Reference to the specification (this document)  Component peculiarities  Component documentation  API documented in detail: parameters return value and behavioural description  Configuration and installation guidelines  Component distribution Source code must be documented according to the rules established to edit Java code. See also developer's guide [7].

4.1.4. References

This document

== 4.2. NF-2: Platform Compatibility ==

4.2.1. Summary

Platform requirements to execute CH

4.2.2. Rationale

CH subsystem is part of test system that it will be compiled and linked jointly in order to get the executable entity. All of them must be according to the same platform requirement.

4.2.3. Requirements

 Operating System; linux 2.6  Compiler: gcc 3.4  Additional compiler features: POSIX library.

4.2.4. References

See [3]

== 4.3. NF-3: Dependency on other parties ==

4.3.1. Summary

Dependency of CH with the other software elements conforming the test system

4.3.2. Rationale

TM interworks with other software entities to be clearly identified.

4.3.3. Requirements

The dependencies must be clearly identified.

4.3.4. References

This document

== == 5. See Also == ==

Further reading:  Technical Documentation: Wiki Editor's FAQ: how to edit a Go4IT WiKi document[1]  Technical Documentation: Developer's Guide: rules for Go4IT Package2 coding (C/C++)[2]  Back to the Go4IT Package2 General Design Document[3]