CSI5118 W2001 Outline –Review Verification & Validation –Introduction to EFSM Models –Introduction to SDL e.g. EggTimer –Principles of Validation & Verification

EFSM Models Extended Finite State Machines –Same as FSM’s –Enhanced features on transitions no inputs (spontaneous transitions) supports variables guards (or conditions) several outputs input/output parameter support (data)

FSM Models Example (FSM) Input State x y s0 0,s1 1,s0 s1 1,s1 1,s2 s2 1,s0 0,s y/1 x/1 y/0 y/1 x/1 x/0 Tabular Form: Each table entry shows what symbol is output, and which new state is to be adopted Graph Form: The label “x/0” means that “when x is the input, 0 is the output.”

EFSM Model Fax Machine Example IR TE i/RDY d, g/DLNG, PAGE to/TIME s/ERR f/ERR i/PAGE -/TOK to/TIME s/ERR d, g, f/DLNG, ERR Notation Used Status = {I,R,T,E} I = Idle R = Ready to Transmit T = Transmitting E = Error Input events = {I,d,g,s,to,f} i = insert page d = dial destination number g = press “Go” button s = press “Stop” button to = timeout (5 seconds elapsed) f = failure of the attempted or pending action Output Responses = {TOK, TIME, PAGE, DLNG, ERR, RDY} TOK = “Transmission Ok” TIME = (Time of day) PAGE = “Transmitting page” DLNG = “Dialing” ERR = “Error” RDY = “Document Ready”

EFSM Model Fax Machine Example IR TE i/RDY d, g/DLNG, PAGE to/TIME s/ERR f/ERR i/PAGE -/TOK to/TIME s/ERR d, g, f/DLNG, ERR Or... Transition n (d,g,f/DLNG, ERR) FROM: ‘R’ WHEN: ‘d’ then ‘g’ then ‘f’ ACTIONS: ‘DLNG’ then ‘ERR’ TO: ‘E’...

EFSM Model with Variables Partial Model of a Stack EmptyNormal Full push pop push FSM EmptyNormal Full [SC>1] push (SS=1) [SC=1] push (SS=1) [SS+1=SC] push (SS=SC) [SS+1<SC] push (SS=SS+1) EFSM SC = Stack Capacity SS = Stack Size As an exercise, do the ‘pop’ interaction for this EFSM

SDL Specification and Description Language –Initially built for communicating systems –Divides the specification in Environment System(s) The Environment Border

SDL A Whole system System Block Process Procedure

Inside an SDL System Channel (and channel name) System name Signals (Messages) Declarations Signalist (set of messages) Newtype definitions

SDL System Structure Signals are shown in square brackets, separated by a comma System blocks Channel name Signallists are declared like signals, but enclosed in parenthesis Environment of the system

The EggTimer SDL Block Connection points (system channel names) Procedure declaration Process declarations General declarations (signals, types, vars) routes Signals

The EggTimer SDL Block Structure Processes At least 1 instance and at most 1 instance of this process Procedure Reference Displaying sends to the environment and receives from Timing etc...

SDL Process example State Initial state Initial transition Declarations Input Output If Procedure call Task Timer Input (or timeout)

SDL Declaration example To say your declaring something Identifier (instance name) Instance type InitializationTimer declaration Timer Identifier

SDL Transition example FROM WHEN ACTIONS SEND TO Local variable Parameters to send

SDL Tasks Incrementing or attributing a value Making a procedure call Setting the timer Set([NOW+], ) := [; <another task]

SDL Procedures (and operators) Formal Parameters Param modifier name and type Procedure Start Procedure return If first ‘seconds’ digit is 0 then go down, else go left Modifiers: IN - Parameter is an Input parameter OUT - Parameter is an Output parameter IN/OUT - Parameter is both IN and OUT

SDL Message Handling Each process has one and only one message queue sends (by default) a message to the closest receiver (if the process itself is capable of receiving such message, it will send to itself) the default sending procedure can be modified by VIA: TO: VIA TO

SDL Message Handling This process queue has four possible messages IncMinute StartTimer ResetTimer OneSecond The first three are external messages where OneSecond is an internal message, indicating when the clock has decreased one second. There could be several other messages coming from other processes or other blocks

Principles of Validation i) Design –User-centred view scenarios use-cases MSCs functional, blackbox, providing a service (or NOT), end to end –guided execution in SDL high- level design –refined design, re-run validation scenarios

Next i: Tr. Start SDL Guided execution Using the Navigator in a SDL Validator tool. Up 1 Next 1: Signal: OneMinuteBtn Next 2: Signal: StartBtn Next 2: Signal: ResetStopBtn Next 1: Tr. Start... Next 1:... Input: DisplayTime Sender: Timing:1 Parameter(s):1,0,0 By clicking on the Next, we go deriving a scenario by following the state-space tree

SDL Guided Execution (in MSC form)

Functional MSC for the previous EggTimer scenario And executing this MSC in the Validator Tool, by clicking on “Verify MSC” and selecting the proper file, we obtain (as the system has been correctly specified) 1 report 1 MSC Verification MSC ValidatorTrace verified Depth: 7

Principles of Validation ii) Test functional user interface tests in TTCN S1 S2S3 ca b a b + Test Name Event a Event b pass Tree and Tabular Combined Notation TTCN standard for formal test case descriptions Facilitate sharing of tests Eliminates Ambiguities UNIX-based TTCN Workbench toolkit TTCN used for X.25, ISDN, CCS7, and many other protocols All PDU parameters specified All tests are formally assigned verdicts

Principles of Validation ii) Test (cont’d) basic syntax & semantics of TTCN –TREE and TABLE Combined Notation Test Case Dynamic Behaviour Test Case Name: Group: Purpose: Default: Behavior Constr. Ver Label Description Reference dict Remarks A!X A?Y A!J A?K Pass A?Z Fail Wrong Resp. A?Otherwise Inc. Test body not reached Extended Comments:

Principles of Verification i) Design –State-space search Process Chart Transition Chart State Space -transitions reduced state space

Principles of Verification i) Design (cont’d) –Possible outcomes Unspecified reception queue overflow deadlock infinite livelock (no real progress) –Random walk

Principles of Verification ii) Test –Conformance Testing (TTCN) preamble test step verification sequence postamble

Principles of Verification Structure of a Transition Test Case for Conformance Testing PREAMBLE: Initialization to Preamble State TEST BODY: Application of Test Stimulus and Confirmation of System Response VERIFICATION: Confirmation of Post-Transition State POSTAMBLE: Reset to Stable State for Next Test

Principles of Verification Represent S1S3S4 a/X b/Y As a sequence of user actions and system responses, starting in state 1 and finishing in state 4. In TTCN +Preamble(S1) !a ?X !b ?Y +Verify(S4) PASS * FAIL * Inconclusive