1 / 38

Basic SDL Specification and Description Language

Basic SDL Specification and Description Language. Basic SDL. SDL for objects defining functionality. While MSC provide overview Object models provide completeness. SDL is designed for systems. that are : reactive concurrent real-time distributed heterogeneous complex. goal:

lee-gray
Download Presentation

Basic SDL Specification and Description Language

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Basic SDLSpecification and Description Language Basic SDL

  2. SDL for objects defining functionality While MSC provide overview Object models provide completeness

  3. SDL is designed for systems that are: • reactive • concurrent • real-time • distributed • heterogeneous • complex goal: a better way to describe behaviour! Look for SDL info at http://www.sdl-forum.org/

  4. It should be better thanimplementation level languages 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!

  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 goal: a clear and concise way to describe complex reactive behaviour

  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; } }

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

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

  9. System diagram in SDL 1(2)

  10. System diagram 2(2)

  11. A simple block

  12. A block type

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

  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 signal output signal input port FSM timer op data op timeout timer save save queue data reveal/view

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

  16. A process type 1(2)

  17. A process type 2(2)

  18. A user arrives

  19. The user is accepted

  20. The user passes

  21. A user arrives at the other panel

  22. The User Server 1(2)

  23. The User Server 2(2)

  24. The User ServerInitialisation Procedure

  25. The Panel Server

  26. OUTPUT destination

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

  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

  29. Asterisk state and Save Asterisk state • 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 * (exception) state list (Idle) Save symbol Code

  30. P1 S1 S2 c,d d a b e b c a e d What happens here? process type P1 1(1) S1 S3 d e S4 S5

  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

  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

  33. STRUCT 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);*/

  34. 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. Array NEWTYPE IntXChar Array(Character, Integer) ENDNEWTYPE IntXChar ;

  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;

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

  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

  38. 1 4 3 2 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

More Related