FDT Foil no 1 Basic SDL Specification and Description Language Basic SDL

FDT Foil no 2 SDL for objects defining functionality While MSC provide overview Object models provide completeness

FDT Foil no 3 that are: reactive concurrent real-time distributed heterogeneous complex that are: reactive concurrent real-time distributed heterogeneous complex SDL is designed for systems goal: a better way to describe behaviour! goal: a better way to describe behaviour! Look for SDL info at

FDT Foil no 4 It should be better than implementation level languages to support: human communication and understanding formal analysis and comparison of behaviours alternative implementations and design optimisation to support: human communication and understanding formal analysis and comparison of behaviours alternative implementations and design optimisation goal: a readable, formal, abstract and realistic language!

FDT Foil no 5 Behaviour in focus because: behaviour is vital to the purpose and quality behaviour is complex dynamic invisible often infinite hard to understand and analyse because: behaviour is vital to the purpose and quality behaviour is complex dynamic invisible often infinite hard to understand and analyse goal: a clear and concise way to describe complex reactive behaviour

FDT Foil no 6 C++ example state machine void PRC_Validate::run(int signal) {switch(cur_state) {case Validate:switch(signal) {case SIGID_OK: /* transition (Validate,OK) */ OUTPUT(KEEPSIG(),SELF()->GATE[GT_PanelControl_D]); // NOTE: KEEPSIG() refers to the consumed signal directly OUTPUT(new SIG_ReleaseCard, SELF()->GATE[GT_PanelControl_CR]); RETURN(); return; case SIGID_ERR: /* transition (Validate,ERR) */ OUTPUT(KEEPSIG(),SELF()->GATE[GT_PanelControl_D]); OUTPUT(new SIG_ReleaseCard, SELF()->GATE[GT_PanelControl_CR]); RETURN(); return;... default:IERROR("Validate::run no such state"); return; } void PRC_Validate::run(int signal) {switch(cur_state) {case Validate:switch(signal) {case SIGID_OK: /* transition (Validate,OK) */ OUTPUT(KEEPSIG(),SELF()->GATE[GT_PanelControl_D]); // NOTE: KEEPSIG() refers to the consumed signal directly OUTPUT(new SIG_ReleaseCard, SELF()->GATE[GT_PanelControl_CR]); RETURN(); return; case SIGID_ERR: /* transition (Validate,ERR) */ OUTPUT(KEEPSIG(),SELF()->GATE[GT_PanelControl_D]); OUTPUT(new SIG_ReleaseCard, SELF()->GATE[GT_PanelControl_CR]); RETURN(); return;... default:IERROR("Validate::run no such state"); return; }

FDT Foil no 7 Our Example Domain: Access Control zone door Passive objects group legal user member of has access to consist of 1..* 1 Authenticator Authorizer User Card Operator Door Active objects

FDT Foil no 8 First sketch of Application system User server Door server Operator server Authorizer Authenticator User panel Operator terminal User Operator Door controller Access Control System Access Control Unit AccessPoint OperationPoint

FDT Foil no 9 System diagram in SDL 1(2)

FDT Foil no 10 System diagram 2(2)

FDT Foil no 11 A simple block

FDT Foil no 12 A block type

FDT Foil no 13 Pure FSM Complete and unambiguous interface behavior Purely sequential No data, no time Complete and unambiguous interface behavior Purely sequential No data, no time logic state input output IdleValidation Passing Card/UserCode Reject /EnterCard Accept/Pass Ready/EnterCard

FDT Foil no 14 The SDL “machine” A process is an agent executing his own actions and having his own local (data) attributes. Processes have discrete behavior. Processes interact by means of "signals". Signals are discrete stimuli which are actively screened and processed by the receiver. input port FSM timer data output signalinput signal reveal/view save queue save timeout timer opdata op

FDT Foil no 15 MSC Normal_Accepted ps_1 UserServer ds_1 Card UserCode Validate Accepted Accept Pass Admit Open DoorPassed Admitted Ready EnterCard msc Normal_Accepted

FDT Foil no 16 A process type 1(2)

FDT Foil no 17 A process type 2(2)

FDT Foil no 18 A user arrives

FDT Foil no 19 The user is accepted

FDT Foil no 20 The user passes

FDT Foil no 21 A user arrives at the other panel

FDT Foil no 22 The User Server 1(2)

FDT Foil no 23 The User Server 2(2)

FDT Foil no 24 The User Server Initialisation Procedure

FDT Foil no 25 The Panel Server

FDT Foil no 26 OUTPUT destination

FDT Foil no 27 PID (Process IDentification) operators SELF the process itself OFFSPRING the most recent process instance created by SELF. If no processes have been created by SELF, then OFFSPRING is NULL. PARENT SELF is the OFFSPRING of PARENT. If SELF is not generated dynamically, then PARENT is NULL. SENDER the process which sent the signal most recently consumed by SELF. If no signal has been consumed yet, SENDER is NULL. SELF the process itself OFFSPRING the most recent process instance created by SELF. If no processes have been created by SELF, then OFFSPRING is NULL. PARENT SELF is the OFFSPRING of PARENT. If SELF is not generated dynamically, then PARENT is NULL. SENDER the process which sent the signal most recently consumed by SELF. If no signal has been consumed yet, SENDER is NULL.

FDT Foil no 28 SDL signals Input Signalname(var1, var2,...) means: var1 := parameter no 1,var2 := parameter no 2 Output Signalname(e1, e2,...)TO pe means: parameter no 1 := e1, parameter no 2 := e2, Destination := pe, Origin := SELF Input Signalname(var1, var2,...) means: var1 := parameter no 1,var2 := parameter no 2 Output Signalname(e1, e2,...)TO pe means: parameter no 1 := e1, parameter no 2 := e2, Destination := pe, Origin := SELF

FDT Foil no 29 Asterisk state and Save * (Idle) Code Asterisk state (exception) state list Save symbol Asterisk state means all the states in the FSM The exception state list in the state symbol modifies the asterisk, such that those state names in the exception state list are not included. Saved signals are put in a separate queue for each process. Saved signals are brought into the input port when the FSM changes state. The saved signals are inserted first in the input port Asterisk state means all the states in the FSM The exception state list in the state symbol modifies the asterisk, such that those state names in the exception state list are not included. Saved signals are put in a separate queue for each process. Saved signals are brought into the input port when the FSM changes state. The saved signals are inserted first in the input port

FDT Foil no 30 What happens here? process type P11(1) a c,d S1 b d S2 d S3 e S4S5 P1 S1 e c d a b e

FDT Foil no 31 SDL assignments variable := expression Variables on the left of the assignment operator receive the right hand side expression value Expression is an operation or a variable: operator(e1, e2,...) or Var “+”(a,b) “-”(3) or a + b - 3 (infix operators + and -) Variable occurrences in an expression, means extracting the value from the variable Multiple assignments in one task symbol are separated by comma variable := expression Variables on the left of the assignment operator receive the right hand side expression value Expression is an operation or a variable: operator(e1, e2,...) or Var “+”(a,b) “-”(3) or a + b - 3 (infix operators + and -) Variable occurrences in an expression, means extracting the value from the variable Multiple assignments in one task symbol are separated by comma

FDT Foil no 32 Data types The usual: Boolean, Character, String, Charstring, Integer, Natural, Real, Array, Powerset, Struct The special: PId - Process Identifier. Time, Duration operation: Now The user defined: Newtype, Syntype, Generator The usual: Boolean, Character, String, Charstring, Integer, Natural, Real, Array, Powerset, Struct The special: PId - Process Identifier. Time, Duration operation: Now The user defined: Newtype, Syntype, Generator

FDT Foil no 33 STRUCT NEWTYPE AccessCode STRUCT cardid, pin Integer; ENDNEWTYPE AccessCode; NEWTYPE AccessCode STRUCT cardid, pin Integer; ENDNEWTYPE AccessCode; DCL AC AccessCode ; AC!cardid := 1234 ; /* longform: AC := cardidModify!(AC, 1234);*/ temp_pin := AC!pin ; /* longform: temp_pin := pinExtract!(AC);*/ DCL AC AccessCode ; AC!cardid := 1234 ; /* longform: AC := cardidModify!(AC, 1234);*/ temp_pin := AC!pin ; /* longform: temp_pin := pinExtract!(AC);*/

FDT Foil no 34 Array Here is how you actually declare an array (in a text symbol): DCL chrval IntXChar ; /* declaring array variable for the conversion of characters to integers */ Here is how you actually declare an array (in a text symbol): DCL chrval IntXChar ; /* declaring array variable for the conversion of characters to integers */ Here is how you use the array (in a task symbol) chrval('X') := chrval('Y')-1 ; /* which uses the shortform of the operators Extract! and Modify! */ The long form would look like: chrval := Modify!(chrval, 'X', Extract!(chrval,'Y') - 1 ) ; The long form shall be used in axioms, while in TASKs the short form must be used. Strings use the same short form as arrays. Here is how you use the array (in a task symbol) chrval('X') := chrval('Y')-1 ; /* which uses the shortform of the operators Extract! and Modify! */ The long form would look like: chrval := Modify!(chrval, 'X', Extract!(chrval,'Y') - 1 ) ; The long form shall be used in axioms, while in TASKs the short form must be used. Strings use the same short form as arrays. NEWTYPE IntXChar Array(Character, Integer) ENDNEWTYPE IntXChar ; NEWTYPE IntXChar Array(Character, Integer) ENDNEWTYPE IntXChar ;

FDT Foil no 35 SYNTYPES and SYNONYMS Use SYNTYPES to make special types from existing types: SYNTYPE Byte = Integer CONSTANTS 0:255 ENDSYNTYPE Byte; Use SYNONYMS for symbolic values: SYNONYM MinInstance Byte = 5; SYNONYM MaxInstance Byte = 123; Use SYNTYPES to make special types from existing types: SYNTYPE Byte = Integer CONSTANTS 0:255 ENDSYNTYPE Byte; Use SYNONYMS for symbolic values: SYNONYM MinInstance Byte = 5; SYNONYM MaxInstance Byte = 123;

FDT Foil no 36 SDL and ASN.1 ASN.1 definitions PaymentModule DEFINITIONS ::= BEGIN CardType::=ENUMERATED{ masterVisa, euroExpress, americanCard }; CreditCard::= SEQUENCE{ ctype CardType, nr IA5String (SIZE (0..20)) }; … END ASN.1 definitions PaymentModule DEFINITIONS ::= BEGIN CardType::=ENUMERATED{ masterVisa, euroExpress, americanCard }; CreditCard::= SEQUENCE{ ctype CardType, nr IA5String (SIZE (0..20)) }; … END SDL use: IMPORTS CardType, CreditCard FROM PaymentModule CardType::=ENUMERATED{ masterVisa, euroExpress, americanCard}; DCL i INTEGER(0..5);

FDT Foil no 37 Language features Two syntaxes: SDL/GR - a graphic representation SDL/PR - a textual representation Object orientation: objects with behaviour object structure described separately from object behaviour types defined by composition and by inheritance of structure and behaviour Two syntaxes: SDL/GR - a graphic representation SDL/PR - a textual representation Object orientation: objects with behaviour object structure described separately from object behaviour types defined by composition and by inheritance of structure and behaviour

FDT Foil no 38 Intended application areas Standards: to define unambiguous and consistent protocols; Tendering: to specify requirements to compare solutions Development: 1. to specify the required system behaviour 2. to design the optimal implementation 3. to describe the provided behaviour 4. to verifiy and validate the behaviour Standards: to define unambiguous and consistent protocols; Tendering: to specify requirements to compare solutions Development: 1. to specify the required system behaviour 2. to design the optimal implementation 3. to describe the provided behaviour 4. to verifiy and validate the behaviour