An SDL Tutorial

31
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

description

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 - PowerPoint PPT Presentation

Transcript of An SDL Tutorial

Page 1: An SDL Tutorial

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

Page 2: An SDL Tutorial

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 permittedon this channel

channelname

block name

system name

Page 3: An SDL Tutorial

3

Declarations

SIGNAL m1, m2, m3(INTEGER), m4, m5;

System SDLexample

2(2)

parameter for signal end of declaration listDeclaration of5 signals with

indicated names

Page 4: An SDL Tutorial

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

SIGNALm5;

process name

declaration localto block

Page 5: An SDL Tutorial

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 instancesat system initialization

P(0, )

maximum numberof instances

unlimitednumber ofinstances

Page 6: An SDL Tutorial

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

Page 7: An SDL Tutorial

7

Block_3:aType

Block_4:aType

System SDLexample2

Block Types

path

toEnv1 toEnv2

[m1]

[m1]

[m4] [m4]g1

g2g1g2

aType

block type block instances

typeofinstancegate

references

Page 8: An SDL Tutorial

8

Inside a Block Type

Block Type aType

block type name

Process_3

Process_4

[m4]

[m1]

[m5]gatereference

gate

sr4

sr5

sr6

gate name

g1

g2

[m4]

[m1]

[m4]

signals permittedthrough gate

g2

[m4]

g1

Page 9: An SDL Tutorial

9

Process Types

• Uses gates in the same manner as block types

P_typeSymbol:

P1: P_typeInstance:

Page 10: An SDL Tutorial

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

signallist

Page 11: An SDL Tutorial

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

Page 12: An SDL Tutorial

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.

Page 13: An SDL Tutorial

13

SDL Behaviour

state1

m5

m2

state2

state

input

m4

m4

state3

next state

Process p1

state1

startstate

output

Page 14: An SDL Tutorial

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 ofvariable

Page 15: An SDL Tutorial

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

Page 16: An SDL Tutorial

16

Guard Conditions

state1

m3

state2

m4

m1

state3

x = 5

x < 0

transition takenif no matchinginput receivedand condition is true

DCL x INTEGER;

guardcondition

transition takenif input receivedand condition is true

Page 17: An SDL Tutorial

17

Decisions

• Two forms:– First: True and false branches based on logical condition– Second: Switch-like statement

– Any logical operator can be used: <, <=, >, >=, =, /=

x = 3true

false

x

=2= 1 else

not-equal

variable

conditions

logicalcondition

Page 18: An SDL Tutorial

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

Page 19: An SDL Tutorial

19

Timers

set(now+5.0,t1) Starts timer t1Will expire 5.0 “time units” from now

state1

t1 m2

reset(t1)

TIMER t1;

t1 expiry messagecancellation of timer

timer declaration

Page 20: An SDL Tutorial

20

Other transition elements

x := 0 task: used for variable assignments

Prcd_name procedure call

Prcs_name create a new process instance

process termination

Page 21: An SDL Tutorial

21

Other symbols

“extender”: used to addadditional text that doesn’tfit inside a symbol

x := really_long_variable_name

x := really_long_variable_name

comment (can be attachedanywhere)

Page 22: An SDL Tutorial

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

m1 m2

Page 23: An SDL Tutorial

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.

Page 24: An SDL Tutorial

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

Page 25: An SDL Tutorial

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

Page 26: An SDL Tutorial

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.

Page 27: An SDL Tutorial

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.

Page 28: An SDL Tutorial

28

Sample Procedure Definition

state1

m5

m2

state2

m4

m4

Procedure A_Proc

state1

procedurestarts here

return tocaller

;FPAR IN/OUT d BIT, IN e BIT, IN/OUT f OCTET

procedureparametersarea

procedurename

Page 29: An SDL Tutorial

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 parametervalue is passed in only, orin and out.

Parameter name

Parameter type

Page 30: An SDL Tutorial

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.

Page 31: An SDL Tutorial

31

Receive

Process Send_and_Receive

Service structure

[m1]

[m4]

1(1)

Send

[m2]

[m3]