This document describes the CD section of the Go4IT Package2 General Design Document, wich is made of the following sections:

General Design of the Compiler.
General Design of the SA.
General Design of the PA.
General Design of the CH.
General Design of the TM.
General Design of the TM-UI.
General Design of the TL.
General Design of the CD-Gen.
General Design of the CD: This document.
General Design of the RIPng ATS.

[edit]

Introduction

This document focuses on the CD (Figure 1), whose purpose is to provide a coding & decoding service for the Test Executable. It consists of converting abstract TTCN-3 values used in the Go4IT IPv6 Test Suite into/from binary messages that can be transmitted to/from the System and the Platform Adapter. The CD Implementation interacts only with the Test Executable (through the CD-Lib).

[edit]

Use Cases

This section contains a set of use cases that describe the external behavior of the software. A use case is a description of a specific interaction that a user (or another module) may have with the software. Use cases are deceptively simple tools for describing the functionality of the software. On a macroscopic view, a function is a row in the “Package2 function Table” in the architecture document (column “Optimum Go4IT test platform”. A use case is a simple, straightforward tool that can be used to completely describe all of the behavior of a piece of software. It contains a textual description of all of 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 This section will contain multiple use cases, enough to define all of the interactions between the Test Executable will have with the CD.

[edit]

UC-1: Encode

Summary

Convert a TTCN-3 variable into a binary string.

Rationale

When a TTCN-3 variable is going to be sent by the Test Executable to the System or Platform Adapter, it has to be converted into a binary string before. This operation is performed by the CoDec (CD).

Actors

CD, TE

Preconditions

None

Basic Course of Events

Step1: The TE calls the CD (tciEncode)
Step2: The CD retrieves the content of the TTCN-3 value using the TCI-Value API.
Step3: The CD encodes the value.
Step4: The CD returns the binary string.

Alternative Paths

None

Postconditions

None

[edit]

UC-2: Decode

Summary

Convert a binary string into a TTCN-3 value.

Rationale

When a TTCN-3 value is received by the Test Executable from the System or Platform Adapter, it has to be converted from a binary string before. This operation is performed by the CoDec (CD).

Actors

CD, TE.

Preconditions

None

Basic Course of Events

Step1: The The TE calls the CD (tciDecode) with a decoding hypothesis (type of the value)
Step2: The The CD decodes the value according to the hypothesis given by the TE and according to the type definition present in the TTCN-3 sources.
Step3: The The CD instantiates the decoded TTCN-3 value using the TCI-Value API.
Step4: The The CD returns the value just instantiated.

Alternative Paths

In Step2 the binary string may not be well formatted (in accordance with the decoding hypothesis). In that case the CD returns a distinct value null.

Postconditions

None

[edit]

Functional Requirements

Functional requirements define the internal workings of the software: that is, the calculations, technical details, data manipulation and processing, and other specific functionality that shows how the use cases are to be satisfied. The name, summary and rationale of each functional requirement are used in the same way as those of the use cases. The behavior that is to be implemented should be described in plain English in the “Requirements” section. Most requirements are only relevant to a small number of use cases—these should be listed by name and number in the “References” section. (Some requirements are not associated with use cases.) The core of the requirement is the description of the required behavior. It is very important to make this clear and readable. This behavior may come from organizational or business rules, or it may be discovered through elicitation sessions with users, stakeholders, and other experts within the organization. Many requirements will be uncovered during the use case development. When this happens, the requirements analyst should create a placeholder requirement with a name and summary, and research the details later, to be filled in when they are better known.

[edit]

FR-1: TCI compliance

Summary

The CD implementation has to be compliant with the C language mapping of TCI([1]).

Rationale

All JRA2 development must be TTCN-3 standards compliant.

Requirements

The CD implementation must be compliant with the C language mapping of the ETSI standard ETSI ES 201 873-6 V3.1.1 (2005-06), named "Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3; Part 6: TTCN-3 Control Interface (TCI)".

The CD implementation must implement the "TCI-CD provided" operations and interact with the TE using the "TCI-CD required" and the "TCI-Value" calls only.

References

UC-1, UC-2

[edit]

FR-2: Stateless operation

Summary

Encode and Decode functions have to be stateless.

Rationale

Any two calls done with the same parameters must give exactly the same result.

Requirements

When a CD call is executed it must not keep any information between two successive calls.

References

UC-1, UC-2

[edit]

FR-3: Test suite compliance

Summary

TTCN-3 values instantiated or received by the codec must map the types definitions used in the Go4IT IPv6 test suite.

Rationale

It is necessary for the CoDec and the Test Executable to use the same TTCN-3 type definitions in order to exchange data between each other.

Requirements

When instantiating or retrieving a TTCN-3 value, the order and content of TCI-Value calls must be consistent with the definition of the corresponding testcase type. TTCN-3 values instantiated or received by the codec must map the built-in types of TTCN-3 as well as types definitions used in the IPv6 test suite.

References

UC-1, UC-2

[edit]

Nonfunctional Requirements

Nonfunctional requirements impose constraints on the design or implementation (such as performance requirements, quality standards or design constraints). Users have implicit expectations about how well the software will work. These characteristics include how easy the software is to use, how quickly it executes, how reliable it is, and how well it behaves when unexpected conditions arise. The nonfunctional requirements define these aspects about the system. (The nonfunctional requirements are sometimes referred to as “non-behavioral requirements” or “software quality attributes”.) The nonfunctional requirements should be defined as precisely as possible. Often, this is done by quantifying them. Where possible, the nonfunctional requirements should provide specific measurements which the software must meet. The maximum number of seconds it must take to perform a task, the maximum size of a database on disk, the number of hours per day a system must be available, and the number of concurrent users supported are examples of requirements that the software must implement but do not change its behavior.

[edit]

NF-1: Documentation

Summary

Detailed description of developed software

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 (CD can be modified at the lowest possible cost)
Reliability (ability of the CD to perform and maintain its functionality in routine and also in different unexpected circumstances)
Extensibility (adding new functionalities to the CD without affecting the functionalities already implemented)

Requirements

The documentation will consist of:

Software architecture of CD 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 behavioral description.
Configuration and installation guidelines.
Component distribution.

Source code must be documented according to the rules established to edit Java code (i.e., javadocs). See also developer’s guide [7].

References

This document.

[edit]

NF-2: Platform Compatibility

Summary

Platform requirements to execute CD.

Rationale

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

Requirements

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

T3RTS (TTCN-3 Runtime System) will be implemented in C/C++ language. However, T3RTS on Java are currently put on the market and therefore it will be needed to develop an initial study to migrate a CD implemented in C/C++ to Java implementation (e.g. using JNI, Java Native Interface).

References

See [3].

[edit]

NF-3: Dependency on other parties

Summary

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

Rationale

CD interworks with other software entities to be clearly identified.

Requirements

The dependencies must be clearly identified:

• CD interface (T3RTS libraries) • TTCN-3 type definitions (Abstract test suite) References

[edit]

Technical Documentation: General Design of the CD

Contents

Introduction

Use Cases

UC-1: Encode

UC-2: Decode

Functional Requirements

FR-1: TCI compliance

FR-2: Stateless operation

FR-3: Test suite compliance

Nonfunctional Requirements

NF-1: Documentation

NF-2: Platform Compatibility

NF-3: Dependency on other parties

See Also