This chapter begins with a brief introduction to SDL; the language, its history, its main concepts and application areas.
Next follows an introduction to the MSC language.
Telelogic also provides the TTCN tool ITEX. For the sake of completeness, we have included a brief introduction to the notations TTCN and ASN.1. For more information on these topics, see the user documentation that is distributed with ITEX.
After reading this chapter, you may want to deepen your knowledge of SDL. In chapter 1, Object-Oriented Design Using SDL-92 in the
volume SDT 3.02 Methodology, you will find information about how to take advantage of the SDL-92 language in an SDT environment.
Also, a list of recommended literature dealing with various SDL topics is enclosed at the end of this chapter; see "References" on page 23.
It is widely accepted that the key to successfully developing a system is to produce a thorough system specification and design. This task requires a suitable specification language, satisfying the following needs:
- A well-defined set of concepts.
- Unambiguous, clear, precise, and concise specifications.
- A basis for verifying specifications with respect to completeness and correctness.
- A basis for determining whether or not an implementation conforms to the specifications.
- A basis for determining the consistency of specifications relative to each other.
- Use of computer-based tools to create, maintain, verify, simulate and validate specifications.
- Computer support for generating applications without the need of the traditional coding phase.
SDL, MSC and the tool SDT fulfil the demands outlined in the list above.
SDL is a standard language for specifying and describing systems(1). It has been developed and standardized by ITU in the recommendation Z.100.
The development of SDL started in 1972 after a period of research work. The first version of the language was issued in 1976, followed by new versions in 1980, 1984, 1988 and 1992. The latest three versions expanded the language considerably, and today SDL is a "complete" language in all senses.
An SDL specification/design (system) consists of a number of interconnected modules (blocks). A block can recursively be divided into more blocks forming a hierarchy of blocks. The channels define the communication paths through which the blocks communicate with each other or with the environment. Each channel usually contains an unbounded FIFO queue that contain the signals that are transported on the channel. The behavior of the leaf blocks is described by one or more communicating processes. The processes are described by extended finite state machines.
SDL furthermore supports object-oriented design by a type(2) concept that allows specialization and inheritance to be used for most of the SDL concepts, like blocks, processes etc. The obvious advantage is the possibility to design compact systems and to reuse components which in turn reduces the required effort to maintain a system.
SDL gives a choice of two equivalent syntactic forms; a Graphical Representation (SDL-GR) and a textual Phrasal Representation (SDL-PR). SDT supports both notations.
Currently, SDL is mainly known within the telecommunication industry, but it also has broader areas of application and is now gaining acceptance within the real-time software industry. The application areas may be summarized as follows:
- Type of system described by SDL: Real-time, interactive, distributed
- Type of information provided by SDL: Behavior and structure
- Level of abstraction supported by SDL: From overview to detail
The basic theoretical model of an SDL system consists of a set of extended finite state machines (FSM) that run in parallel. These machines are independent of each other and communicate with discrete signals.
An SDL system consists of the following four components:
- Structural view -- System, block, process, and procedure hierarchy.
- Communication -- Signals with optional signal parameters and channels (or signal routes).
- Behavior -- Processes.
- Data -- Abstract data types.
Figure\x11 1 : The Architectural View of an SDL System
-----
(fig)
-----
Figure 1 shows the four main hierarchical levels in SDL.
Figure\x11 2 : Sending Signals Between Two Processes.
-----
(fig)
-----
In SDL, there is no global data. This approach requires that information between processes, or between processes and the environment, must be sent with signals and optional signal parameters. Signals are sent asynchronously, that is, the sending process continues executing without waiting for an acknowledgment from the receiving process.
The dynamic behavior in an SDL system is described in the processes. The system/block hierarchy is only a static description of the system structure. Processes in SDL can be created at system start, or created and terminated at runtime. More than one instance of a process can exist. Each instance has a unique process identifier (PId). This makes it possible to send signals to individual instances of a process. The concept of processes and process instances that work autonomously and concurrently makes SDL a true real-time language.
Figure\x11 3 : Creation of a New Process Instance at Runtime.
-----
(fig)
-----
The abstract data types concept used within SDL is very well suited to a specification language. An abstract data type is a data type with no specified data structure. Instead, it specifies a set of values, a set of operations allowed on the data type and a set of equations that the operations must fulfil. This approach makes it very simple to map an SDL data type to data types used in other high-level languages.
Figure\x11 4 : Abstract Data Type Example.
-----
(fig)
-----
During the last years, ITU has made a considerable effort in standardizing a formal language which defines Message Sequence Charts (MSC).
In the summer of 1992, a first version of the MSC recommendation was published.
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 which is easy to understand for the user.
An MSC describes one or more traces from one node to another node of an abstract communication tree generated from an SDL specification.
Figure\x11 5 : An Example of a Message Sequence Chart.
-----
(fig)
-----
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 which 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 which are equivalent. Besides the graphical notation (MSC-GR), a textual notation (MSC-PR) is standardized since the autumn of 1994.
Among the various application areas, we have selected the following:
- Producing documents with the purpose of defining the requirements of a system.
- Facilitating the design phase, by identifying and documenting a multitude of dynamic cases before starting designing with SDL.
- Presenting the execution of a simulation as a graphical output which is easy to understand and which can later on be verified against a reference. Message Sequence Charts can be verified against an SDL system using SDT.
- Presenting the execution trace of an SDL system during an interactive simulation and generation of reports.
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 actual implementations.
This need has been addressed by ISO and ITU in the "Framework and Methodology for Conformance Testing of Implementations of OSI and ITU Protocols". The framework has for some time had the status of an international standard as ISO/IEC 9646 (or X.290).
The standard introduces the concept of abstract test suites (consisting of abstract test cases). This is a description of a set of tests that should be executed for a system. The tests should be described using a black-box model, i.e. only control and observation using the available interfaces.
The abstract tests are to be described using a formal language rather than using informal natural language. As part of the standard the language TTCN is defined in order to describe the abstract tests.
TTCN (ISO/IEC 9646-3) is a language standardized by ISO for the specification of tests for communicating systems. TTCN has been developed within the framework of standardized conformance testing (ISO/IEC 9646).
With TTCN a test suite is specified. This 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 like "First we send A, then either B or C will be received, if it was B we will send D..." are described. The new version of TTCN allows several event trees to be running concurrently.
TTCN is abstract in the sense of being independent of the actual test systems. This means that a test suite in TTCN for one application (protocol, system...) can be used in any test environment for that application.
The use of TTCN has increased tremendously during the last years. This has been augmented by the significant amount of TTCN test suites released by various standardization bodies. TTCN is however not only used in standardization work. The language is very suitable for all kinds of functional testing for communicating systems. This has led to a wide usage also within the industry.
The specifications of the messages being sent and received can be defined using either the built-in form of TTCN or by using ASN.1.
ASN.1 (ISO/IEC 8824) is a generic notation standardized by ISO for the specification of data types and values. The general idea behind ASN.1 is to describe information independent of the transfer format.
The original use of ASN.1 has been the information description in high-level protocols like FTAM, CMIP, MHS, DS, VT, etc. Today it is also frequently used in various telecommunication protocols and applications.
The possibility to copy the ASN.1 definitions from the protocol specification into the test suite in TTCN assures consistency between the information transferred in system specification and the test specification.
Telelogic has been a firm supporter of SDL for a long time. We co-operate with ITU in the on-going work of improving the language and with ETSI in using SDL for defining protocol standards. We initiate and participate in international research programs on how to use the language in different application areas (such as the European Community programs RACE, ESPRIT and EUREKA). Our experience and know-how in these areas is put to practice when we develop software engineering tools that support the languages.
A tool for a specification language must be able to create, maintain, and analyze a specification. It is also fundamental that the tool can simulate, validate and generate application code to other high level languages.
SDT can do all of this.
- [1]
- ITU Recommendation Z.100:
Specification and Description Language SDL
1994, ITU, General Secretariat- Sales Section,
Places des Nations, CH-1211 Geneva 20.
- [2]
- Annex A, B, C1, C2 D, E, F1, F2 and F3 to Z.100. as above
- [3]
- ITU Recommendation Z.120:
Message Sequence Charts (MSC)
1992, ITU General Secretariat -Sales Section
Place des Nations, CH-1211 Geneva 20
- [4]
- Ferenc Belina, Dieter Hogrefe and Amardeo Sarma: SDL with Applications from Protocol Specification
Prentice Hall International (UK) Ltd. 1991
ISBN 0-13-785890-6
- [5]
- Belina, Hogrefe:
The CCITT Specification and Description Language SDL.
Computer Networks and ISDN System
1988/1989 North-Holland, Amsterdam
- [6]
- Braek, Hasnes, Haugen:
Engineering real-time systems with an object-oriented methodology based on SDL.
SISU Project Report 1992
Norwegian Computer Center
PO Box 114, N-0314 Oslo 3, Norway
- [7]
- Faergerman, Marques (editors):
SDL 89: The language at work.
Proceedings of the Fourth SDL Forum,
North Holland, Amsterdam (1989)
- [8]
- Faergerman, Reed (editors):
SDL 91: Evolving Methods.
Proceedings of the Fifth SDL Forum,
North Holland, Amsterdam (1991)
- [9]
- Faergerman, Sarma (editors):
SDL 93: Using Objects.
Proceedings of the Sixth SDL Forum,
North Holland, Amsterdam (1993)
- [10]
- Haugen, Möller-Pedersen:
Tutorial on object-oriented SDL.
SISU Project Report 91002
Norwegian Computer Center
PO Box 114, N-0314 Oslo 3, Norway
- [11]
- Behcet Sarikaya:
Principles of Protocol Engineering and Conformance Testing.
Simon & Schuster International (1992)
- [12]
- Sarraco, Smith, Reed:
Telecommunications system engineering using SDL.
North-Holland, Amsterdam (1989)
- [13]
- Saracco, Tilanus (editors):
SDL `87 State of the art and future trends.
Proceedings of the Third SDL Forum
North Holland, Amsterdam (1987)
- [14]
- K.J. Turner (editor):
Using Formal Description Techniques -
An Introduction to Estelle, LOTOS and SDL.
John Wiley & Sons (1992)
- [15]
- A. Olsen, O.Færgemand, B. Møller-Pedersen, R. Reed,
J.R.W. Smith:
Systems Engineering Using SDL-92.
Elsevier (1994)
ISBN 0-444-89872-7
Footnotes
- (1)
- Note that no distinction is made in SDL between the terms "specification" and "description", although they generally have different meanings in SDL applications.
- (2)
- SDL has adopted the term type which corresponds to the term class used in many of the OO notations and programming languages.