Specification and Description Language

Luigi Bozzo May 2002

COUSE OF SOFTWARE ENGINEERING II AA 2001/02

2

Summary What is SDL

Intro History Goal SDL Characteristics

SDL Structure Example – La lotteria algebrica Glossary References

3

What is SDL SDL (Specification and Description

Language) is an object-oriented, formal language developed and standardized by The International Telecommunication Standardization Sector (ITU-T)

Intended for the specification of complex, event-driven, real-time, and interactive application involving many concurrent activities that communicate using discrete signals

4

What is SDL

SDL describe the architecture, behaviour and data of distributed systems in realtime environments

Useful for specifying the normative requirements of telecommunications protocol standards

Wide spectrum language - specification to implementation

5

History 1968 ITU study of stored program control

systems

1972 Start of the development

1976 First pre-release

1980-1984Graphics, process semantics, structure, data,definition more rigorous, start of tools, user guide

1988 SDL88, the first standard

6

History

1992 SDL92, MSC intro of OO and methodology guidelines

1995 SDL with ASN.1

1999 SDL-2000 MSC-2000 Object modelling supportImproved implementation support

2001 SDL-2001 Meeting UML

7

Application area

Type of systems:

Type of information: Level of abstraction:

Real time Interactive Distributed Heterogeneous

Behavior, structure Overview to details

8

Use of SDL

SDL(and MSC)

Interpreted as

C++ etc.

Product

used tocreate

used toproduce

SpecificationIdeas

Customer

modelled byDesign

Engineers

Design

Implementation Software

Engineers

modelled by

made as

executesas

Interpreted as

Tools

transformed by

9

Goals

Provide a better way to describe behaviour

Support human communication and understanding

Easy verification conformance of implementation of specifications

Design optimization Analyzing specifications for

completeness and correctness

10

Goals

Use of computer based tools to create, maintain and analyze specifications

Formal high quality descriptions produced better, quicker and cheaper

Provide to programmers an easy way to do verification, validation of the design, regression testing, automatic documentation and simplified maintenance

11

SDL Characteristics

Graphical form Based on communicating processes OO description of components Nonproprietary internationally

standardized language Formality and clarity High degree of testability Portable, scalable, open, reusable

12

Examples

Cellular phones Switches GPRS UMTS GSM ISDN

13

SDL & others languages

SDL is well suited to be the core of full-scale projects because of its abilities to interface with other languages.

UML

MSC ASN.1

TTCN

14

SDL Structure Comprises four main hierarchical levels:

System Block Process Procedure

15

SDL Structure

A system contains one or more blocks, interconnected with each other and with the boundary of the system by channels

The block is the main structuring concept

A block can be partitioned into sub-blocks and channels

A channel is a means of conveying signals

16

SDL Structure

Repeated block partitioning result in a block tree structure

Partitioned blocks do not contain any process

17

SDL Structure

Leaf-blocks of a block tree structure are not partitioned, and contain only process

18

System

The system description constitutes the top level of detail

The system is what the SDL description specifies:an abstract machine communicating with its environment

Environment

System

Channel

19

System

A system diagram usually contains the following elements:1. system name 2. signal descriptions 3. channel descriptions 4. data type descriptions 5. block descriptions

1

2

3

5

21

Block

A block is a part of the system that can be treated as a self-contained object

c_ins

c_outt

P

1(1)block B

routrin

22

Block

A block diagram usually contains the following elements: 1. block name 2. signal descriptions 3. signal route descriptions 4. channel-to-route connections 5. process descriptions

1

2

5

4

3

24

Process A process in SDL is an extended finite state machine The behaviour of a finite state machine is described

by states and transitions

A process description is given through a process diagram

In SDL there are five basic constructs for the description of a process

task

25

Process

A process diagram usually contains the following elements:1. Process name2. Formal parameters3. Variable descriptions4. Process graph 5. Procedure Descriptions6. Timer descriptions

26

Process Example

Process P

dcl c character;

procedure proc;

c

Proc

FPAR v1 Integer

Proc

1

2

3

4

5

c

27

Procedure The procedure construct in SDL is similar to the one

known from programming languages

A procedure is a finite state machine within a process. It is created when a procedure call is interpreted, and it dies when it terminates

A procedure description is similar to a process description, with some exceptions.

The start symbol is replaced by the procedure start symbol

28

Procedure

A return symbol is introduced:

When a procedure is running, the calling process or procedure is suspended in the transition containing the procedure call

29

Describing behavior with SDL

The behaviour of a system is constituted by the combined behaviour of the processes in the system

A process is defined as finite state machine, that works autonomously and concurrently with other processes

A process reacts to external stimuli in accordance with its description

A process is either in a state waiting, or performs a transition between two states

30

Describing behavior with SDL

The co-operation between the processes is performed asynchronously by discrete messages called signals

Every process has an infinite input queue associated, which acts like a FIFO queue

Any signal arriving at the process is put into its input queue

31

Describing behavior with SDL

When a signal has initiated a transition, it is removed from the input queue

32

Process Addressing Every process has a unique address

The address is not determined by the user, but is rather created by some abstract SDL machine during the creation of a process

For any signal sent by a process there must be one and only one destination

Destination can be specified: Implicitly explicitly

33

Explicit Addressing

SDL has the TO construct for the explicit addressing of processes

The keyword TO is used in an output, and it is followed by an expression containing the address of the destination process

A

TO P2_ADDRESS

34

Implicit Addressing

The explicit specification of a destination address is not necessary if the destination is uniquely defined by the system structure

A

35

Process Creation/Termination

Processes can be created by other processes dynamically at interpretation time

This is indicated in a block diagram by a dashed line from the creating process to the created process

The creating and created process must belong to the same block

36

Process Creation/Termination

A

P2(A,true)

S2

S1

Process P1

Process P2

dcl v3 Integer

V3 = v1 * 2

v3

FPAR v1 Integer, v2 Boolean

37

Example – La lotteria Algebrica

system L-AL

GestoreCartaCredito_p

PostaElettronica_p

GestoreAccessi_p

Cliente_u Giocatore_u

Direttore_u

lal_clientelal_giocatore

lal_Direttore

lal_GA

lal_PElal_GCC

* * 1

1

11[ … ]

[ … ]

[ … ]

[ … ]

[ … ]

[ … ]

38

Example – La lotteria Algebrica

system L-AL

GestioneCollegamenti

DatiGiocatore

1(X)

controlla

codiceOk[ ]

collega][L-AL_GA

DatiGiocatore_GCC

signal collegami(DatiGiocatore,Codice), collega(Integer,Integer), controlla(DatiGiocatore, Codice), codiceOk(DatiGiocatore, Codice, Chiave), seiCollegato(Chiave)

[ ]collegami

seiCollegato

L-AL_Giocatore

39

Example – La lotteria Algebrica

DatiGiocatori

Giocatore_u

GestoreAccessi_p

collegami(gu,D,cod)

controlla(D,cod)

codiceOk(D,cod,ch)

collega(cod,ch)

seiCollegato(ch)

GestioneCollegamenti

40

Example – La lotteria Algebrica

Block GestioneCollegamenti

P1 (DatiGiocatore,Codice)

P2 (DatiGiocatore,Codice,Chiave)

L-AL_Giocatore

L-AL_GA

DatiGiocatore_GCC

[collegami]

[controlla]codiceOk

collega][

[seiCollegato]

signal collegami(DatiGiocatore,Codice), collega(Integer,Integer), controlla(DatiGiocatore, Codice), codiceOk(DatiGiocatore, Codice, Chiave), seiCollegato(Chiave)

41

Example – La lotteria Algebrica

process P1FPAR v1 DatiGiocatore, v2 Codice

controlla (v1,v2)

process P2FPAR v1 DatiGiocatore, v2 Codice, v3 Chiave

collega (v2,v3)

seiCollegato (v3)

42

Glossary ASN.1

Abstract data type CCITT

Comite Consultatif International Telegraphique et Telephonique; the former name of ITU-T

FSMFinite state machine

IDLInterface description language; textual representation that enables

designers to capture interfaces and data types of objects IPC

Interprocess communication ITU

International Telecommunications Union OMG

Object Modeling Technique; a notation for capturing requirements with object analysis

43

Glossary

ITU-TTelecommunications standardization body

OMTObject Modeling Technique; a notation for capturing

requirements with object analysis

SDL-GRGraphical notation for SDL

SDL-PRTextual notation for SDL

44

References SDL Forum Society http://www.sdl-forum.org

Specification and Description Language Tutorialhttp://www.iec.org/online/tutorials/sdl/

SDL 2001: Meeting UML10th International SDL ForumCopenhagen, Denmark, June 2001ProceedingsRick Reed, Jeanne ReedEd Springer

Documenting Software Architecture: Documenting Behaviorhttp://www.sei.cmu.edu/publications/documents/02.reports/02tn001.htmlBachmann, Bass, Clements, Garlan, Ivers, Little, Nord, Stafford

45

References SAM work shop

SDL & MSC workshop (open discussion platform)http://www.irisa.fr/manifestations/2000/sam2000/papers.html

The End

48

ITU-T The International Telecommunication Union (ITU) is

the United Nations specialized agency in the field of telecommunications

The ITU Telecommunication Standardization Sector (ITU-T) is a permanent organ of ITU

ITU-T is responsible for studying technical, operating and tariff questions and issuing Recommendations on them with a view to standardizing telecommunications on a worldwide basis

50

SDL & UML UML is a language that is good at describing

classes/types and relationships between them in a simple and intuitive manner

It does a good job in the early phases of the development process but in the implementation phases it lacks in structural behavioral constructs

51

SDL & UML

SDL is more coherent than UML and also has a sound semantics foundation but is less expressive and widely accepted than UML

However, SDL is strong exactly where UML is weak.

Combining SDL with UML provides a modelling paradigm for visual software engineering that is more robust and effective than either language alone

52

SDL & UML

SDL bridges the gap between UML modeling and the target implementation

Requirements analysis

System specification

Design

Implementation

Target

53

SDL & UML

Convergence of UML and SDL

54

Why use SDL & UML ?

Standardized notation without sacrificing specialized model data

Common language that can be used from product conception to delivery, from system to detailed design levels

Reduced learning curve across projects Increased domain and design model reuse Increased customer involvement

/understanding of problem translation to product solution

56

MSC

The Message Sequence Charts (MSC) is a trace language for specification and description of the communication behavior of communicating systems

Shows chronological sequences of messages

sent between different system components (entities) and their environment

Well suited for presenting a complex dynamic behavior in a clear, unambiguous and easily understandable way

57

MSC Features

Formal Standardized Graphical Use Cases Simulation trace

(through automatically generated MSC) Regression Testing (checking old functionality)

58

MSC Example

Giocatore_s E Giocatore_u GestoreAccessi_p

collegami(gu,D,cod)

controlla(D,cod)

codiceOk(D,cod,ch)

collega(ch)

seiCollegato(ch)

60

ASN.1 ASN.1 (Abstract Syntax Notation One) is the

ISO-ITU standardized language for defining data types an values

Designed for describing structured information that is conveyed across some interface or communication medium, independently from the transfer format

Used in conjunction with Basic Encoding Rules (BER), defining the so-called “transfer syntax”, the rapresentation of values as a bit stream to be transmitted

61

ASN.1 Features

Formal Standardized Complete data type definition apparatus Constraints, class definitions and

parametrization Extensibility Automatic encoder/decoder generation Automatic implementation language

representation generation

62

ASN.1 examplePersonName ::= [16] IMPLICIT OCTET STRING

Person ::= SEQUENCE { title [1] OCTET STRING, name [2] PersonName, height [3] Height OPTIONAL, weight [4] INTEGER OPTIONAL

}

AddressBookEntry ::= CHOICE { [10] Person, [11] Company, [12] Group

}

64

TTCN TTCN (Tree and Tabular Combined Notation)

is a globally adopted standard test notation for the specification of test cases

In TTCN, a test case is used for testing special functionality such as non-termination

The sintax is similar to conventional programming languages and incorporates features like synchronous and asynchronous communication mechanisms as well as dynamic parallel test configuration

65

TTCN

A TTCN test suite consists of four parts: Overview part

An index and page references of the different part Declaration part

Declaration of PDUs with ASN.1 Constraints part

Describe the value that re sent or received Dynamic part

Describe the actual execution behavior of test suiteContains all test cases and default table for

66

TTCN Features

PortabilityTTCN is platform independent

ReusabilitySince an Abstract Test Suite uses only the external

(standardized) interfaces, it is highly reusable

ModularityTest cases can share a common set of definitions, and be

added incrementally

ASN.1 integrationASN.1 is used for representation of data (PDUs)

67

TTCN Example

Each test case or test step is a so-called behavior tree

68

TTCN Example

A behavior table describes the behavior tree in a tabular format

Test Case Dynamic Behavior

Test Case Name: Basic Connect

Purpose: Check that a normal Call connection can be established

Nr Label Behavior Description Cref V

1 L!LiftHook

2 L?DialTone

3 L!Digits CallSubsr2

4 L?CallToneL?

5 LineConnect ConnSubscr2

6 L!DropHook P

7 L?BusyTone

8 L!DropHook I

9 L?NoTone F

Detailed Comments:

Verdict: Pass, Inconclusive, Fail