1. Holger Hermanns Formal Methods for Software Engineering Part III: Applications of Formal Methods Lecture 8: SDL

2. Holger Hermanns Formal Methods for Software Engineeiring - Lecture 8: SDL 2 Contents of this lecture The state of affairs. What's SDL? How to write sequential processes in SDL. How to specify entire systems in SDL. How to get all this running.

3. Holger Hermanns Formal Methods for Software Engineeiring - Lecture 8: SDL 3 The state of affairs In Part I we used Z as a formalism to model the static aspects of software systems, i.e. ndefinition of system states & data structures ndefinition of operations & preconditions The tool Z-Eves was used for specification support and analysis. In Part II we used LTS as a model and FSP as a formalism to model the dynamic aspects of software systems, i.e. ndefinition of system behaviour (control flow) ndefinition of control distribution (concurrency) We used the tool LTSA for modelling support and analysis.

4. Holger Hermanns Formal Methods for Software Engineeiring - Lecture 8: SDL 4 This Part We apply the concepts, methods and tools you learnt to love in contexts that are relatively close to what the people out there are facing. Today we will introduce an 'industrial' FSP variant: SDL. In the next weeks you will get the 'chance' to play with a commercial tool used for telecom software design: Telelogic Tau. Assumptions for today: You know how to represent a sequential process as an LTS, and are able to describe it textually in FSP. You know how to represent concurrent processes as LTSs, and are able to give their compositional specification in FSP. You understand that nondeterminism is the key concept to model the concurrent executions of LTSs You are still a little puzzled about how to get the interaction of processes right by modfying their alphabets in FSP.

5. Holger Hermanns Formal Methods for Software Engineeiring - Lecture 8: SDL 5 What is SDL? The Specification and Description Language. An ITU standard since about 1988, extended ‘92, ‘96, 2000. Tailored to telecommunications applications. Has found acceptance in the industrial sector, revisions are mainly industry (tool-vendor) driven. Has lost a little its clean formal basis. Part of the semantics is tool dependent these days. Comes as a textual/graphical specification formalism. Tool-vendors are embracing (each other and) the UML world.

6. Holger Hermanns Formal Methods for Software Engineeiring - Lecture 8: SDL 6 The simplest SDL process. does nothing at all. Corresponds to what LTS? A still simple one. in ‘textual’ SDL: PROCESS B; START; OUTPUT hello; STOP; ENDPROCESS process A process B hello says hello, not more. Which LTS?

7. Holger Hermanns Formal Methods for Software Engineeiring - Lecture 8: SDL 7 AGAIN A regenerating one. is an annoyingly friendly one. Which LTS? In FSP? process C hello S1 S2 a/c b/ /d The first interesting one. LTS? process D S2 c a S1 d NONE S2 S1 c a S2 b

8. Holger Hermanns Formal Methods for Software Engineeiring - Lecture 8: SDL 8 Intermezzo: Input/Output In FSP, actions are synchronized among processes that share them as part of their common alphabet. In SDL, signals appear as pairs of input and output signals. If received by some process, input signals can be consumed and thus trigger process activities, such as the sending of (one and more) output signals to other processes. Whereas input signals may synchronously trigger output signals (usually named different), output signals never synchronize with the consumption of their corresponding (equally named) input signal in the receiving process. We will later see why this is the case. On the LTS level, we use /sig to denote output of signal sig, and sig/ for input.

9. Holger Hermanns Formal Methods for Software Engineeiring - Lecture 8: SDL 9 AGAIN A regenerating one. is an annoyingly friendly one. Which LTS? In FSP? process C hello S1 S2 a/c b/ /d The first interesting one. LTS? process D S2 c a S1 d NONE S2 S1 c a S2 b

10. Holger Hermanns Formal Methods for Software Engineeiring - Lecture 8: SDL 10 Three ways to stutter 'a'. And some notation. start symbol (not a state), cannot wait for input state, waits for inputs, or 'waits' for NONE, or is enabled by a continuous signal. process A1 S1 a NONE process A2 S1 a NONE process A3 S1 a true

11. Holger Hermanns Formal Methods for Software Engineeiring - Lecture 8: SDL 11 A data dependent process. A nondeterministic one. may do this, may do that, who knows. LTS? this that true process D this that i=0i!=0 process D DCL i Integer; does this if i equals 0, otherwise that.

12. Holger Hermanns Formal Methods for Software Engineeiring - Lecture 8: SDL 12 S Continuous signals Continuous signals guard the branches of input-less alternatives, are boolean conditions on process data, are pretty similar to the FSP guards Enabling conditions are basically the same (except for the name) but guard inputs. They follow (!) the guarding input. More on process data follows. this that i=0i!=0 process D this that true process E kick (when (i==0) this -> STOP |when (i!=0) that -> STOP). DCL i Integer; false

13. Holger Hermanns Formal Methods for Software Engineeiring - Lecture 8: SDL 13 HUH Putting things together. reads something first, which induces a remark, until either saying this, or if x>5 saying that. this that true process F remark something x>5 DCL x:=8 Integer; HUH STOP something/remark /this /that

14. Holger Hermanns Formal Methods for Software Engineeiring - Lecture 8: SDL 14 XX What may be in a transition body or more! one output an enabling condition/ a continuous signal one input at most referring to the process’ data in the state X i.e. before the input a few tasks SDL’s rough design rationale: allow as much as possible to happen inside a single transition body, but avoid by all means to get stuck The execution policy of a transition: check the enabling condition (!). If true: check whether you can do the input. if so, do so, and do all the rest. if not, stay where you are. modifying the process’ data, should better terminate... a text extension (mis-used) a comment

15. Holger Hermanns Formal Methods for Software Engineeiring - Lecture 8: SDL 15... Always fun to dwell on an unimportant detail... x>20... x>20 get  this predicate is called an enabling condition a predicate not preceded by an input  is called a continuous signal - * Some syntactic sugar process...... I loop everywhere! for each state in this process: don’t change the state (thus, stay where you are): - *

16. Holger Hermanns Formal Methods for Software Engineeiring - Lecture 8: SDL 16 Let’s summarise a bit. a start symbol (not a state) a transition an enabling condition or a continuous signal? a STOP two transition alternatives an input an output a comment a text extension a successor state a task a text (for declarations) process a ? a state

17. Holger Hermanns Formal Methods for Software Engineeiring - Lecture 8: SDL 17 Y There’s still more. process Stupid wait ready ELSE Z x:=x-1 (0) x get (x) DCL x Integer; such as flowchart stuff and parameter passing. For the remainder of this lecture, I blur the distinction between and.

18. Holger Hermanns Formal Methods for Software Engineeiring - Lecture 8: SDL 18 Let’s assume that we now know enough to represent single sequential processes as SDL processes. To get a proper, compile-able specification requires wrapping in some structure. One or more SDL processes must be grouped in an SDL block. An SDL block is either a collection of blocks or of processes. An SDL system is a collection of blocks. View it as a tree structure: the root is the system, the leaves are processes, everything in the middle is a block. system blocks block processes

19. Holger Hermanns Formal Methods for Software Engineeiring - Lecture 8: SDL 19 A simple, compile-able SDL process. or better, the first approximation thereof. process B hello block helloblock B system HELLOSYS helloblock

20. Holger Hermanns Formal Methods for Software Engineeiring - Lecture 8: SDL 20 How do processes and blocks cooperate? Recall for FSP that multiple processes may synchronize on an action. In SDL, processes send output signals and consume input signals In SDL, signal transmission is not immediate, transmission proceeds via signal routes (on block level), and via channels (on system level), and is buffered at the receiving process side.

21. Holger Hermanns Formal Methods for Software Engineeiring - Lecture 8: SDL 21 A simple, compile-able SDL process. process B hello block helloblock B [hello] system HELLOSYS helloblock [hello] SIGNAL hello; second approximation

22. Holger Hermanns Formal Methods for Software Engineeiring - Lecture 8: SDL 22 connected to the embracing block or system  (to the system, at channel helloChan ) A simple, compile-able SDL process. process B hello this should be it. system HELLOSYS helloblock [hello] SIGNAL hello; helloChan block helloblock B [hello] helloRoute helloChan a ‘signal route’  a ‘channel’  connected  to the environment

23. Holger Hermanns Formal Methods for Software Engineeiring - Lecture 8: SDL 23 (A note on relabelling in FSP and SDL) process B hello system HELLOSYS helloblock [gingong] SIGNAL gingong; helloChan block helloblock B [hello] helloRoute helloChan SIGNAL hello; It is possible to rename the contents of channels and signal routes at block borders, similar to relabelling in FSP. The main use of relabelling (and prefixing) in FSP (fixing which processes interact with each other) is done in SDL by assigning signals names to channels and routes connecting blocks and processes.

24. Holger Hermanns Formal Methods for Software Engineeiring - Lecture 8: SDL 24 A more involved example. process B X system... K SIGNAL W,Y,Z; block K J [Y] B process J Y X [X] SIGNAL X; [Y] C P C C block P Q [Y] [W,Z] D D process Q Z * W Z - Y WAIT W This process actually is incorrect, think!

25. Holger Hermanns Formal Methods for Software Engineeiring - Lecture 8: SDL 25 Under the hood of an SDL-process Outputs are sent away (non-blocking). All inputs are buffered in a joint unbounded FIFO queue, and ‘consumed’ from there. This implements buffered communication. The inputs are non-persistent: top elements are discarded if they are unexpected. A ‘save’ construct supports reordering (saving) of unexpected inputs in the queue. Q C [Y] [W,Z] process Q Z * W Z - Y WAIT W W

26. Holger Hermanns Formal Methods for Software Engineeiring - Lecture 8: SDL 26 Saving and consuming inputs Y X W Y W B B X Y W V B  discarded  saved  discarded  consumed W Z S1 X S2 T Y X W Y W B B W

27. Holger Hermanns Formal Methods for Software Engineeiring - Lecture 8: SDL 27 A more involved example. process B X system... K SIGNAL W,Y,Z; block K J [Y] B process J Y X [X] SIGNAL X; [Y] C P C C block P Q [Y] [W,Z] D D process Q Z * W Z - Y WAIT W synchronization (with the input buffer) synchronization synchronization (with the input buffer) synchronization

28. Holger Hermanns Formal Methods for Software Engineeiring - Lecture 8: SDL 28 The LTS seen from the environment. process B X system... K SIGNAL W,Y,Z; block K J [Y] B process J Y X [X] SIGNAL X; [Y] C P C C block P Q [Y] [W,Z] D D process Q Z * W Z - Y WAIT W W/ Z/ /Z Z/ W/ Z/ W/ Z/ W/ Z/ / Z/ Z / W/ W / W/ W W/ Z/ W/ /Z (I did this on paper, so I challenge you to find mistakes) Z/

29. Holger Hermanns Formal Methods for Software Engineeiring - Lecture 8: SDL 29 (Process level: no communication, just an LTS) Block level: signal routes are non-delaying 'implemented' by synchronisation but the inputs are still buffered at the receiver side. System level: channels can be non-delaying 'implemented' by synchronisation but eventually the inputs are buffered at the receiver side! delaying 'implemented' by synchronization with another unbounded FIFO buffer in the middle (makes the duration of delay unpredictable). additionally, the inputs are buffered at the receiver side. On signal routes and channels: communication and interaction in SDL K P K P B B Keep in mind that channels and signal routes may be uni-directional or bidirectional.

30. Holger Hermanns Formal Methods for Software Engineeiring - Lecture 8: SDL 30 X Y process COUPLE - Y -- Y X Y X Y - Y -- Y X Y T X Y - Y -- Y X Y X VIA SR Y VIA SL process COUPLE - Y VIA SR -- Y VIA SL X VIA SL Y VIA SR T How about a small excercise VIA :to identify the signal route FROM or TO to identify source/target process system X K SIGNAL X,Y; P [Y] [X,Y] C Implement a delayed channel using two coupled nondelayed channel. system Xprime K SIGNAL X,Y; Couple [Y] [X,Y] Cleft P [Y] [X,Y] Cright Cleft block Couple COUPLE [Y] [X,Y] [Y] Cright SLSR

31. Holger Hermanns Formal Methods for Software Engineeiring - Lecture 8: SDL 31 What you should have learnt today block a block system a signal route (or a unidirectional non-delaying channel )... and a lot of text a process a unidirectional delaying channel a bidirectional non-delaying channel (or a signal route) a ? a save

32. Holger Hermanns Formal Methods for Software Engineeiring - Lecture 8: SDL 32 How to code LTSs as SDL processes. How to construct a system out of processes and blocks. How to link processes through signal routes. How to link blocks through (non-)delaying channels. What’s under the hood of a process (buffered, non-persistent input)... What you should have learnt today