The development of SDL started in 1972. A 15-member study group within CCITT representing several countries and large telecom companies like Bellcore, Ericsson, and Motorola began research on a standard specification language for the telecommunications industry. The first version of the language was issued in 1976, followed by new versions in 1980, 1984, 1988, 1992, and 1996. The latest versions expanded the language considerably and simplified interfacing. Today SDL is a complete language in all senses.

SDL and Other Languages

SDL is well suited to be the core of full-scale projects because of its abilities to interface with other languages. Such languages include other high-level notations for analysis such as object modeling technique (OMT)/unfied modeling language (UML) object models and mobile switching center (MSC) use-cases, as well as abstract system notation one (ASN.1) or common object request broker architecture (CORBA)/interface description language (IDL) data-type definitions. Furthermore, there are tools available that can generate executable code—for example, C/C++ or ITU high-level language (CHILL), directly from the SDL design. Tests can also be generated from the SDL specification by making a test suite in tree and tabular combined notion (TTCN). See Figure 1 for the relations between these languages.

Figure 1. The Relations between Different Languages and SDL

Typically, the procedure from requirements analysis to product implementation and testing would involve the following steps:

• Collect the initial requirements in a text document.
• Study system analysis results in a number of OMT/UML object models and MSC use-cases depicting typical scenarios. The resultant classes are implemented in SDL as SDL block diagrams and SDL/ASN.1/IDL data-type definitions.
• Complete the SDL diagrams and ASN.1 or IDL specifications to a level where they can be simulated and checked for consistency with the system requirements analysis.
• Use verification and validation to determine whether required properties are correctly and completely implemented. The verification procedure also detects general errors like deadlocks, signal races, loss of signals, etc. When SDL design has proved consistent with the requirements, a code for the application can be generated.
• Make a test suite in TTCN. Tests can be generated from the SDL specification. In some cases, such tests are already available (e.g., from standardization bodies).
• Generate code to create an executable test suite that can be run in a test system.
• Run the executable tests and test the application in the target environment.