This chapter describes the benefits of formal methods. It also gives a brief introduction to the TTCN, the ASN.1 and the MSC language.
Note that this chapter is not a tutorial on TTCN, ASN.1 or MSC. In ITEX Methodology Guidelines you can find more information about TTCN and how to use it.
If you want to know more about the languages supported in SDT, you should read Introduction to Languages and Notations.
It is getting increasingly accepted within a steadily growing range of industrial segments that the only true way for software engineering to achieve higher quality, deliver on time and decrease development costs, is to use formal methods. Furthermore, as the international market grows, equipment from different manufacturers must be able to communicate with each other. Therefore it is obvious that the formal method to be used should be internationally standardized.
There are a number of different formal standardized languages and methods available today. The one you select, however, should fulfill a few more important requirements.
One is the availability of professional development tools. Another is clarity. The notation should be understood by a general audience, from experts to end users. Ideally it should have a graphical syntax.
Formal standardized graphical languages ...
As the use of standards within the world of Information Technology and Telecommunications has increased tremendously during the last decade, so has the need for methods and tools that support the verification and validation of both the standards and their implementations.
This need has been addressed by ISO and CCITT (ITU-T) in the "Framework and Methodology for Conformance Testing of Implementations of OSI and CCITT Protocols". The framework has now reached the status of an International Standard as ISO/IEC 9646 (or X.290).
Conformance testing is the process of verifying that an implementation performs in accordance with a particular standard/specification/environment.
Conformance testing is exclusively concerned with the external behavior of an implementation. Service and functional behavior is tested in order to find logical errors and prerequisites for interoperability. Conformance testing is not intended to be exhaustive and a successfully passed test suite does not imply a 100% guarantee. But it does ensure, with a reasonable degree of confidence, that the implementation is consistent with its specifications, and it does increase the probability that implementations will interwork.
TTCN (Tree and Tabular Combined Notation, ISO/IEC 9646-3) is a language standardized by ISO for the specification of tests for real-time and communicating systems. TTCN has been developed within the framework of standardized conformance testing (ISO/ IEC 9646).
With TTCN a test suite is specified. A test suite is a collection of various test cases together with all the declarations and components it needs. Each test case is described as an event tree. In this tree, behaviors such as "First, we send A, then either B or C is received; if it was B we will send D..." are described. Concurrent TTCN allows several event trees to run concurrently.
TTCN is abstract in the sense of being test system independent. This means that a test suite in TTCN for one application (e.g. protocol, system, etc.) can be used in any test environment for that application.
The use of TTCN has increased tremendously during the last few years. This has been augmented by the significant amount of test suites released by various standardization bodies. TTCN is not only used in standardization work. The language is very suitable for all kinds of functional testing for real-time and communicating systems. This has led to a wide usage throughout the industry.
The specifications of the messages being sent and received can be defined using either the native form of TTCN or by using ASN.1 (Abstract Syntax Notation One).
A TTCN specification describes an abstract test suite (ATS) that is independent of test system, hardware and software. The ATS defines the test of the implementation under test (IUT), which is treated in a black box model, i.e. only its exterior interface is of concern. The IUT is stimulated by sequences of test events and its response is inspected.
A TTCN abstract test suite can be transformed into an executable test suite (ETS) using ITEX. This ETS is downloaded into the test system (the system performing the test).
The test system performs the test by executing the ETS against the system under test (SUT) which contains the implementation under test. During execution the ETS will report any errors and log events for on-line or post-test evaluation.
Figure 1 : Test System with Executable Test Suite (ETS)
connected to the system under test (SUT)
|
|
A TTCN specification is somewhat resemblant to a program in Pascal or C. (Being cleaner and more comprehensive, TTCN is easier to learn.) Just like Pascal and C, TTCN requires type and data declarations and it uses concepts like modules and subroutines. Since TTCN is designed for testing, it contains test specific concepts such as:
A TTCN specification has a standardized layout that produces comprehensive and unambiguous paper printouts. This greatly improves clarity and readability. A test suite is divided into the following four major parts:
Figure 2 : The basic structure of a TTCN Test Suite
|
|
The dynamic part of a TTCN abstract test suite is created in a hierarchical and nested manner. The building blocks are test groups, test cases, test steps and test events. There are no limitations as to how many test groups may be contained in a test suite, how many test events may be contained in a test step, etc.
Test component explanation:
Figure 3 : The TTCN dynamic part structure
|
|
TTCN uses the concepts of points of control and observation (PCOs), abstract service primitives (ASPs) and protocol data units (PDUs) in order to create an abstract interface towards the implementation under test (IUT). A PCO is a point in the abstract interface where the IUT can be stimulated and its responses can be inspected. An ASP or a PDU is either a stimuli or a response that carries information, i.e. parameters and data.
Each PCO has two first in first out queues for temporary storage of ASPs and PDUs: One queue for send and one queue for receive. These queues are infinite, i.e. they can store any number of ASPs and PDUs.
Figure 4 : PCOs together with ASPs and PDUs create an
abstract interface towards the IUT
|
|
TTCN uses event trees with test events to express the behavior of test steps and test cases.
All the leaves in the event tree are assigned a verdict that can be PASS, FAIL or INCONCLUSIVE. PASS means that the test case completed without detecting any error. FAIL means that an error was detected, that is, the behavior of the IUT did not conform with the pre-defined specification. INCONCLUSIVE means that there was insufficient evidence for a conclusive verdict to be assigned, but that the behavior of the IUT was valid.
Figure 5 : An event tree and the corresponding execution order
|
|
A verdict can be either preliminary or final, allowing for flexibility in the specification. A final verdict will terminate the active test case and return its verdict. A preliminary verdict will not terminate test case execution but it will flag either PASS, FAIL or INCONCLUSIVE. This preliminary verdict can be inspected during test execution, like any variable.
TTCN uses the comprehensive format shown in Figure 6. The indentation level of statements in the Behaviour Description column indicates where in the event tree an event belongs. The leaves of the tree hold verdicts that define test case outcome.
Figure 6 : The TTCN test case corresponding to the event tree in Figure 5
|
|
The TTCN data and value model is somewhat different from the one in traditional programming languages. It allows for the creation of complex data structures and types, and has the concept of constraints to do value assignments. Constraints are more powerful than values in that they also allow the use of patterns. A pattern can contain wild cards and define allowable value ranges for complex data structures. This is very useful when inspecting responses from the implementation under test.
TTCN has two alternative data and constraint representation formats: the TTCN native tabular form and ASN.1 (Abstract Syntax Notation One). ASN.1, which is a purely textual notation, provides a more flexible platform for describing complex data structures. ASN.1 also allows data descriptions to be shared between an SDL (Z.105) specification and a TTCN test suite.
With modular TTCN, it is possible to define test suite components for re-use. This facilitates test component re-use, and provides a language platform for multi-user test development projects. Modular TTCN is very recent, and at the publishing of this text not yet standardized.
Concurrent TTCN introduces a parallel architecture for simultaneous execution of several test components, allowing many interfaces to be tested concurrently. There are several benefits:
In concurrent TTCN, each test case consists of several parallel test components (PTCs) that execute autonomously, performing concurrent tests. A master test component (MTC) starts the execution of the PTCs and controls the final verdict. The PTCs can only set preliminary verdicts and the test case is completed and its verdict is decided when all the PTCs are finished. The PTCs are synchronized through co-ordination points (CPs) and co-ordination messages (CMs).
The TTCN language supports two notations that are equivalent. The graphical notation (TTCN-GR) and a textual notation (TTCN-MP).
Currently, TTCN is mainly known within the telecommunications industry. However, it has broader areas of application, which can be summarized as follows:
Abstract Syntax Notation One is a language specifically designed for describing structured information that is conveyed across some inter-face or communication medium. ASN.1 is standardized internationally (ISO/IEC 8824) and it is a key ingredient of Open Systems Interconnection (OSI).
In the presentation layer of the OSI hierarchy, data values of quite complex types, such as character strings, intricate structures or arrays of values, need to be determined in a unique way without saying anything about the representation. ASN.1 is developed to fill this need.
ASN.1 is a generic notation for the specification of data types and values. The basic principle is to define a small number of simple types by defining their possible values, and give rules for combining these into increasingly complicated types. The original use of ASN.1 was in the information description of high-level protocols (FTAM, CMIP, MHS etc.), but today it is widely used in the telecommunications industry for protocols and applications.
Figure 7 : A sample ASN.1 type definition
|
|
ASN.1 requires a transfer syntax in order to pass data between two entities. Basic encoding rules (BER, ISO 8825) is a standardized transfer syntax of OSI. Others exist as well: canonical encoding rules (CER) for security applications, distinguished encoding rules (DER) for digital signatures, interface definition Language (IDL) for distributed applications, traditional C/C++, etc. Any transfer syntax can be used for ASN.1 descriptions.
TTCN includes ASN.1, i.e. ASN.1 is used for creating data descriptions and constraints in test suite specifications. Through the new standard of Z.105, ASN.1 is merged with SDL (Specification and Description Language) to create an extremely powerful language environment for specification of real-time, interactive and distributed systems.
Data descriptions made in ASN.1 can be used for both SDL and TTCN specifications, thus making a tight integration between implementation and test, and promoting re-use.
Figure 8 : ASN.1 specifications can be shared between
SDL and TTCN specifications
|
|
During the last years, ITU has made a considerable effort in standardizing a formal language that defines message sequence charts (MSCs). A first version of the MSC recommendation was published in the summer of 1992.
As defined in the recommendation Z.120, the MSC language offers a powerful complement to SDL in describing the dynamic behavior of an SDL system. Its graphical representation is well suited for presenting a complex dynamic behavior in a clear and unambiguous way that is easy to understand.
An MSC describes one or more traces from one node to another node of an abstract communication tree generated from an SDL specification. Basically, the information interchange is carried out by sending messages from one instance to another. In an SDL specification, those messages would coincide with the signals that are sent from one process and consumed in another process. The instances would correspond to any part of the specification (an SDL system, a block or a process).
The MSC language supports two notations that are equivalent. Beside the graphical notation (MSC-GR), a textual notation (MSC-PR) is standardized.
Among several application areas, we have selected the following: