1. Specification and Description Language Luigi Bozzo May 2002 COUSE OF SOFTWARE ENGINEERING II AA 2001/02

2. 2 Summary What is SDL Intro History Goal SDL Characteristics SDL Structure Example – La lotteria algebrica Glossary References

3. 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)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. 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. 5 History 1968 ITU study of stored program control systems 1972 Start of the development 1976 First pre-release 1980-1984 Graphics, process semantics, structure, data, definition more rigorous, start of tools, user guide 1988 SDL88, the first standard

6. 6 History 1992 SDL92, MSC intro of OO and methodology guidelines 1995 SDL with ASN.1 1999 SDL-2000 MSC-2000 Object modelling support Improved implementation support 2001 SDL-2001 Meeting UML

7. 7 Application area Type of systems: Type of information: Level of abstraction: Real time Interactive Distributed Heterogeneous Behavior, structure Overview to details

8. 8 Use of SDL SDL (and MSC) Interpreted as C++ etc. Product used to create used to produce Specification Ideas Customer modelled by Design Engineers Design Implementation Software Engineers modelled by made as executes as Interpreted as Tools transformed by

9. 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. 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. 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. 12 Examples Cellular phones Switches GPRS UMTS GSM ISDN

13. 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 MSCASN.1 TTCN

14. 14 SDL Structure Comprises four main hierarchical levels: System Block Process Procedure

15. 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. 16 SDL Structure Repeated block partitioning result in a block tree structure Partitioned blocks do not contain any process

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

18. 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. 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

20. 1 2 3 5

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

22. 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

23. 1 2 5 4 3

24. 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. 25 Process A process diagram usually contains the following elements: 1. Process name 2. Formal parameters 3. Variable descriptions 4. Process graph 5. Procedure Descriptions 6. Timer descriptions

26. 26 Process Example Process P dcl c character; procedure proc; c Proc FPAR v1 Integer Proc 1 2 3 4 5 c

27. 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. 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. 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. 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. 31 Describing behavior with SDL When a signal has initiated a transition, it is removed from the input queue

32. 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. 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. 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. 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. 36 Process Creation/Termination A P2(A,true) S2 S1 Process P1Process P2 dcl v3 Integer V3 = v1 * 2 v3 FPAR v1 Integer, v2 Boolean

37. 37 Example – La lotteria Algebrica system L-AL GestoreCartaCredito_p PostaElettronica_p GestoreAccessi_p Cliente_u Giocatore_u Direttore_u lal_cliente lal_giocatore lal_Direttore lal_GA lal_PElal_GCC ** 1 1 1 1 [ … ]

38. 38 Example – La lotteria Algebrica system L-AL GestioneCollegamentiDatiGiocatore 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. 39 Example – La lotteria Algebrica DatiGiocatoriGiocatore_uGestoreAccessi_p collegami(gu,D,cod) controlla(D,cod) codiceOk(D,cod,ch) collega(cod,ch) seiCollegato(ch) GestioneCollegamenti

40. 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. 41 Example – La lotteria Algebrica process P1 FPAR v1 DatiGiocatore, v2 Codice controlla (v1,v2) process P2 FPAR v1 DatiGiocatore, v2 Codice, v3 Chiave collega (v2,v3) seiCollegato (v3)

42. 42 Glossary ASN.1 Abstract data type CCITT Comite Consultatif International Telegraphique et Telephonique; the former name of ITU-T FSM Finite state machine IDL Interface 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. 43 Glossary ITU-T Telecommunications standardization body OMT Object Modeling Technique; a notation for capturing requirements with object analysis SDL-GR Graphical notation for SDL SDL-PR Textual notation for SDL

44. 44 References SDL Forum Society http://www.sdl-forum.org http://www.sdl-forum.org Specification and Description Language Tutorial http://www.iec.org/online/tutorials/sdl/ SDL 2001: Meeting UML 10 th International SDL Forum Copenhagen, Denmark, June 2001 Proceedings Rick Reed, Jeanne Reed Ed Springer Documenting Software Architecture: Documenting Behavior http://www.sei.cmu.edu/publications/documents/02.reports/02tn001.html Bachmann, Bass, Clements, Garlan, Ivers, Little, Nord, Stafford

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

46. The End

48. 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. 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. 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. 52 SDL & UML SDL bridges the gap between UML modeling and the target implementation Requirements analysis System specification Design Implementation Target

53. 53 SDL & UML Convergence of UML and SDL

54. 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. 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. 57 MSC Features Formal Standardized Graphical Use Cases Simulation trace (through automatically generated MSC) Regression Testing (checking old functionality)

58. 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. 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. 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. 62 ASN.1 example PersonName ::= [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. 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. 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 suite Contains all test cases and default table for

66. 66 TTCN Features Portability TTCN is platform independent Reusability Since an Abstract Test Suite uses only the external (standardized) interfaces, it is highly reusable Modularity Test cases can share a common set of definitions, and be added incrementally ASN.1 integration ASN.1 is used for representation of data (PDUs)

67. 67 TTCN Example Each test case or test step is a so-called behavior tree

68. 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 NrLabelBehavior DescriptionCrefV 1L!LiftHook 2 L?DialTone 3 L!DigitsCallSubsr2 4 L?CallToneL? 5 LineConnectConnSubscr2 6 L!DropHookP 7 L?BusyTone 8 L!DropHookI 9L?NoToneF Detailed Comments: Verdict: Pass, Inconclusive, Fail