Post on 17-Jan-2016
description
transcript
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
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
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
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
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
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
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
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
9
Process Types
• Uses gates in the same manner as block types
P_typeSymbol:
P1: P_typeInstance:
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
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
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
SDL Behaviour
state1
m5
m2
state2
state
input
m4
m4
state3
next state
Process p1
state1
startstate
output
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
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
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
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
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
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
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
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)
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
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
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
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
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
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
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
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
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
Receive
Process Send_and_Receive
Service structure
[m1]
[m4]
1(1)
Send
[m2]
[m3]