1. 1 An SDL Tutorial Two primary elements: –Structure –Identifies the various components of the system, and the communication paths among them. –Components: Blocks, Processes –Communication paths: Channels, Signal routes –…and where they connect: Gates –Structural elements may be types –Behaviour –Only processes have behaviour –Based on an extended finite state machine

2. 2 Block_1 Block_2 System SDLexample channel environment High level structure path toEnv1 toEnv2 [m2] [m3] [m1] [m4] block 1(2) page number (total pages) signals permitted on this channel channel name block name system name

3. 3 Declarations SIGNAL m1, m2, m3(INTEGER), m4, m5; System SDLexample 2(2) parameter for signalend of declaration list Declaration of 5 signals with indicated names

4. 4 Inside a Block Block Block_1 block name Process_1 Process_2 [m1] [m4] [m5] signal route process sr1 sr2 sr3 signal route name SIGNAL m5; process name declaration local to block

5. 5 Processes Unless otherwise specified, one instance of a process is started at system initialization, and it will continue to run until it decides to terminate itself. Processes can be created dynamically: P(1,3) number of instances at system initialization P(0, ) maximum number of instances unlimited number of instances

6. 6 Process Identification Each process instance is assigned a unique “process identifier”, or PID. –Can be used to identify other processes A PID has its own special type –The set of values for PIDs is not defined by the language; it is left for tool implementation –This means that you cannot assume any values for a PID; they are assigned automatically

7. 7 Block_3: aType Block_4: aType System SDLexample2 Block Types path toEnv1 toEnv2 [m1] [m4] g1 g2 g1 g2 aType block type block instances type of instance gate references

8. 8 Inside a Block Type Block Type aType block type name Process_3 Process_4 [m4] [m1] [m5] gate reference gate sr4 sr5 sr6 gate name g1 g2 [m4] [m1] [m4] signals permitted through gate g2 [m4] g1

9. 9 Process Types Uses gates in the same manner as block types P_type Symbol: P1: P_type Instance:

10. 10 Signal List SIGNAL m1, m2, m3(INTEGER), m4; SIGNALLIST list1 m1, m2, m3, m4; System SDLexample3 signal list name Block_b [(list1)] use of signal list

11. 11 Other notes Blocks may contain (sub-)blocks as well as processes (but not on the same page, in older versions of SDL) Declarations: signals, signal lists, etc. can be at any level –Scope: all contained items know about the declared items, and recognize the names –Good practice: declare items at inner-most level that is possible Names are required to be unique only to their construct –You can have a process named ‘X’ contained within a block also named ‘X’, since they are different constructs. Signal lists can be used anywhere that a signal would appear on a structural diagram –Their use is highly recommended

12. 12 Behaviour Only applies to processes Based on extended finite state machines Model: –Each process has a single input queue of finite length from which it may receive signals –Signals from different sources are appended to the queue as they arrive –To move from one state to another, if the signal at the head of the queue matches the input for a transition, the signal is removed from the queue, and the transition runs to completion.

13. 13 SDL Behaviour state1 m5 m2 state2 state input m4 state3 next state Process p1 state1 start state output

14. 14 Variables Commas separate declarations, semi-colon terminates list Other variable types possible DCL v1 INTEGER, v2 PID, v3 BIT, v4 OCTET, v5 DURATION; process identifier used by timers 0 or 1 eight bits name of variable

15. 15 Special PID variables Each input signal automatically carries the PID of its sending process –When an input signal is received, the value of SENDER (a pre-defined variable) is set to this PID. Other PID pre-defined variables: –SELF: our own PID –PARENT: the PID of the process that created a process –OFFSPRING: the PID of the process most recently created from a process

16. 16 Guard Conditions state1 m3 state2 m4 m1 state3 x = 5 x < 0 transition taken if no matching input received and condition is true DCL x INTEGER; guard condition transition taken if input received and condition is true

17. 17 Decisions Two forms: –First: True and false branches based on logical condition –Second: Switch-like statement –Any logical operator can be used:, >=, =, /= x = 3 true false x =2 = 1 else not-equal variable conditions logical condition

18. 18 Timers Actions with timers: –SET: Start a timer for a specified duration –Time units are “unspecified” by the language –Tau tool default: milliseconds –RESET: Cancel an unexpired timer –(EXPIRY): Notification that the duration has elapsed –Results in a “signal” with the same name as the timer being put into the input queue for the process. Design guideline: –Always cancel unexpired timers

19. 19 Timers set(now+5.0,t1) Starts timer t1 Will expire 5.0 “time units” from now state1 t1m2 reset(t1) TIMER t1; t1 expiry message cancellation of timer timer declaration

20. 20 Other transition elements x := 0 task: used for variable assignments Prcd_name procedure call Prcs_name create a new process instance process termination

21. 21 Other symbols “extender”: used to add additional text that doesn’t fit inside a symbol x := really_long_variable_name x := really_long_variable_name comment (can be attached anywhere)

22. 22 Save If signal m2 is at the head of the input queue in state state1, it is kept in order in the input queue, and the next signal in the queue is examined. No transition after a save, and state is unchanged. Used to defer processing of a signal (to another state) –Example: If signal m2 is at the head of the input queue, and signal m1 is second, the signal m2 is “saved” for a future transition. Signal m1 would then be processed in state1. state1 m1m2

23. 23 Notes on Signal I/O (1) Suppose that a process can send signals a, b, and receive signals b, c Signal a must be defined on an outgoing signal route from the process Signal c must be defined on an incoming signal route to the process By default, when the process sends signal b, it will be placed in its own input queue –WARNING: This will happen even if b is also defined on an outgoing signal route.

24. 24 Notes on Signal I/O (2) Signal output options: –signal is sent along the specified signal route –signal is sent to the specified process While these options are defined by the language, tools have difficulties with their implementation m3 VIA signal_route_name m3 TO process_id

25. 25 Procedure Calls SDL uses procedures instead of functions, and an older (1970s !) style of parameter passing. A_Proc (a, b, c) Procedure call A_proc (d, e, f) Procedure definition

26. 26 Procedures vs. Functions A function has 0 to n parameters, and a separate return value. All parameters are usually passed by value and are intended as input values to the function. The return value is passed using a “return” statement.

27. 27 Procedures vs. Functions A procedure has 0 to n parameters, but NO return value. –Do not assign a “result” from a procedure call. However, each parameter can independently be of two sorts: –IN: similar to a function parameter. Intended for input values. –IN/OUT: The parameter value is passed in from the caller at the start of the procedure, and passed back (out) to the caller at the end of the procedure. –Used to return values –Will modify caller’s original value –Caller must supply a variable, not a constant. –If variable is “output only”, caller can supply a variable that has not yet received a value.

28. 28 Sample Procedure Definition state1 m5 m2 state2 m4 Procedure A_Proc state1 procedure starts here return to caller ; FPAR IN/OUT d BIT, IN e BIT, IN/OUT f OCTET procedure parameters area procedure name

29. 29 Procedure Parameters Syntax notes: –Note semicolon before FPAR keyword –Comma separates parameter declarations –Semicolon terminates parameter list. ; FPAR IN/OUT d BIT, IN e BIT, IN/OUT f OCTET Formal parameters keyword Whether or not parameter value is passed in only, or in and out. Parameter name Parameter type

30. 30 Services Services are used to further partition a process into sub-structures. Services can be used to separate functionality that is independent within a process, and will handle separate signals. –Example: –Send service and Receive service within a process to implement –Each service has its own behaviour description, similar to a process.

31. 31 Receive Process Send_and_Receive Service structure [m1] [m4] 1(1) Send [m2] [m3]