Download presentation

Presentation is loading. Please wait.

Published byRoger Snow Modified about 1 year ago

1
1 Formal Specification (continued) Lecture 3: (SE 252/502) Dr. RAJIB Mall

2
2 Organization of this Lecture Overview of last lecture Algebraic specification: –Development technique –Rewrite rules –Example –Pros and cons State machine modelling Summary

3
3 Review of last lecture Formal specification techniques: –model-oriented –property-oriented

4
4 Review of last lecture Property-oriented techniques: –axiomatic specification –algebraic specification Model-oriented techniques: –Z, VDM, Petri net, State machine, etc.

5
5 Overview of last lecture Axiomatic techniques: –based on early work on program verification. –Use first-order predicate logic: specify operations through pre and post conditions

6
6 Review of last lecture Algebraic technique: –data types are viewed as heterogeneous algebra –axioms are used to state properties of data type operations

7
7 Algebraic Specification Using algebraic specification: –the meaning of a set of interface procedures is defined by using equations.

8
8 Algebraic Specification Algebraic specifications are usually presented in four parts: –types section –exceptions section –signature section –rewrite rules section

9
9 Types Section Types Section Lists: –sorts (or types) being specified –sorts being imported –Importing a sort: makes it available in specification.

10
10 Exception Section Lists names of exceptional conditions used in later sections: –under exceptional conditions error should be indicated.

11
11 Signature Section Defines signatures of interface procedures: –e.g. PUSH takes a stack and an element and returns a new stack. –push: stack element stack

12
12 Rewrite rules section Lists the properties of the operators: –In the form of a set of axioms or rewrite rules. allowed to have conditional expressions

13
13 Developing Algebraic Specification The first step in defining an algebraic specification: –identify the set of required operations. –e.g. for string identify operations: create, compare, concatenate, length, etc.

14
14 Developing Algebraic Specification Generally operations fall into 2 classes: Constructor Operations : –Operations which create or modify entities of the sort e.g., create, update, add, etc.

15
15 Developing Algebraic Specification Inspection Operations : –Operations which evaluate attributes of the sort, e.g., eval, get, etc.

16
16 Developing Algebraic Specification A rule of thumb for writing algebraic specifications: –first establish constructor and inspection operations

17
17 Developing Algebraic Specifications Next, write down axioms: – compose each inspection operator over each constructor operator.

18
18 Developing Algebraic Specifications If there are m constructors and n inspection operators: –we should normally have m*n axioms. –However, an exception to this rule exists.

19
19 Developing Algebraic Specifications If a constructor operation can be defined using other constructors: –we need to define inspection operations using only primitive constructors.

20
20 Example: Stack Let us specify an unbounded stack supporting: –push, –pop, –newstack, –top, –empty.

21
21 Example: Stack Types: defines stack uses boolean, element Exception: underflow, novalue

22
22 Example: stack Syntax: push: –stack element stack pop: –stack stack+{underflow}

23
23 Example: stack top: –stack element+{novalue} empty: –stack boolean newstack: – stack

24
24 Equations: stack pop(newstack)=underflow pop(push(s,e))=s top(newstack)=novalue top(push(s,e))=e empty(newstack)=true empty(push(s,e))=false

25
25 Rewrite rules Rewrite rules let you determine: –the meaning of any sequence of calls on the stack functions.

26
26 Rewrite rules Empty(push(pop(push(newsta ck,e 1 )),e 2 )): – you can eliminate the call on pop by observing: it is of the form pop(push(s,e)).

27
27 Rewrite rules After simplification: –empty(push(newstack,e 1 )) –false

28
28 Two important questions Finite termination property: –Does application of rewrite rules terminate after a finite number of steps? –We might endlessly go on applying rewrite rules without coming to any conclusion?

29
29 Two important questions Unique termination property: –Can different sequence in application of the rewrite rules always give the same answer? –If we choose to simplify different terms of the expression in different experiments: shall we always get the same answer?

30
30 Algebraic Specification For arbitrary algebraic equations: –convergence is undecidable. If the r.h.s. of each rewrite rule has fewer terms than the left: –rewrite process must terminate.

31
31 Auxiliary Functions Sometimes development of a specification requires: –extra functions not part of the system: to define the meaning of some interface procedures.

32
32 Auxiliary Functions: Example To specify bounded stacks: –need to add a depth function: push returns either a stack or an exception “overflow” when depth is exceeded.

33
33 Bounded stack In order to specify a bounded stack: –we need to make changes to different sections to include auxiliary functions.

34
34 Auxiliary Functions Syntax: push: –stack element ==> stack depth: –stack integer

35
35 Auxiliary Functions Equations: –depth(newstack)=0 –depth(push(s,e))=depth(s)+1 –push(s,e)=overflow if depth(s) >= Max

36
36 Example 2: coord Types: –sort coord –imports integer, boolean

37
37 Example: coord Signature: –create(integer,integer) coord –X(coord) integer –Y(coord) integer –Eq(coord,coord) boolean

38
38 Example: coord Rewrite rules: –X(create(x,y))=x –Y(create(x,y))=y –Eq(create(x1,y1),create(x2,y2)) = ((x1=x2) and (y1=y2))

39
39 Structured Specifications Writing formal specifications is time consuming. To reduce effort, we need to reuse specifications: –instantiation of generic specifications –incremental development of specifications

40
40 Specification Instantiation Take an existing specification: –specified with some generic parameter –Instantiate with some sort

41
41 Incremental Development Develop specifications for simple sorts: –using these specify more complex entities.

42
42 Pros and Cons Algebraic specifications have a strong mathematical basis: –can be viewed as heterogeneous algebra.

43
43 Pros and Cons An important shortcoming of algebraic specifications: –cannot deal with side effects –difficult to use with common programming languages.

44
44 Pros and Cons Algebraic specifications are hard to understand: –also changing a single property of the system may require changing several equations.

45
45 Specification of timing constraints Timing constraints: –expressed in terms of occurrence of certain events.

46
46 Events A stimulus to the system from its environment. Can also be an externally observable response: –that the system makes to its environment Events can be instantaneous –or assumed to have a duration

47
47 Types of timing constraints Performance constraints: –constraints imposed on the response of the system. Behavioral constraints: –constraints imposed on the action and reaction time of the environment (or the user).

48
48 Specification of timing constraints We will specify timing constraints: –in terms of stimuli and response –modelled as FSMs (Finite State Machines)

49
49 State machine modelling Assumes that at any time: –the system is in one of a number of possible states. When a stimulus is received, –it may cause a transition to a different state.

50
50 Finite Automaton with Output A set of states final state: –some states designated as final states an alphabet of input symbols an alphabet of output symbols a transition function: –maps a combination of states and input symbols to states

51
51 Representation Await first digit Await second digit Dial Again Await next digit First digit/ start-timer(20) Timer alarm/ dial-tone Second digit/ silence Event Action

52
52 Types of finite automaton A finite automaton with output may be organized in two ways: –A Moore machine is an automaton each state is associated with an output symbol –A Mealy machine associates each transition with an output symbol

53
53 Classification: Three types of timing constraints: –Minimum –Maximum –Durational

54
54 Minimum Between two events: –No less than t time units may elapse e1e2

55
55 Maximum Between two events: –No more than t time units may elapse e1e2

56
56 Durational An event must occur for t units of time

57
57 Maximum S-S (stimulus-stimulus) S-R (stimulus-response) R-S (response-stimulus) R-R (response - response)

58
58 Maximum S-S Maximum time between occurrence of two stimuli: –e.g. after dialling first digit, the second digit should be dialled no more than 20 secs later.

59
59 FSM Representation To represent timing constraints in an FSM: –a timer alarm is used as an artificial stimulus.

60
60 Representation Await first digit Await second digit Dial Again Await next digit First digit/ start-timer(20) Timer alarm/ dial-tone Second digit/ silence Event Action

61
61 Maximum S-R Maximum time between stimulus and response: –e.g. caller shall receive dial tone no later than 20 secs after lifting the receiver.

62
62 Representation Await First Digit Offhook/ Start timer(20) Await Second Digit Dial Again Alarm/ Dial tone Start timer (20) First Digit Second Digit

63
63 Complete Representation Await First Digit Offhook/ Start timer(20) Await Second Digit Dial Again Alarm/ Dial tone Start timer (20) Second Digit Await Eighth Digit Dial Complete Alarm/ Dial tone Eighth digit/ Ring tone

64
64 Maximum R-S Maximum time between system’s response and the next stimulus from the environment: –e.g after receiving the dial tone, the caller shall dial the first digit within 20 sec.

65
65 Maximum R-R Maximum time allowed between two responses: –after a connection has been made, the caller will receive a ring back tone no more than 0.5 sec after the callee has received the ring tone.

66
66 Minimum constraints S-S R-S R-R

67
67 Minimum S-S A minimum time is required between two stimuli: –e.g. a minimum of 0.5 sec must elapse between the dialling of one digit and the dialling of the next.

68
68 Minimum S-S This is an example of behavioral constraints on system users: –the complete specification should include response the system should make if the user responds too soon.

69
69 Representation Handle digit Await Next Digit Await Caller On hook First digit/ start-timer(0.5) Timer alarm/ Second digit/ beeping Second digit/ silence

70
70 Durational timing constraints To go back to the international operator –press the button for at least 15 secs (but no more than 30 secs)

71
71 Durational timing constraints To get back to the local operator: –press the button for at least 30 secs, but no more than 45 secs To receive a dial tone press the button for at least 45 secs.

72
72 Representation ABC D E Set timer 15,30,45 Timer alarm(15) Timer alarm(30) Timer alarm(45)

73
73 Reference Ian Somerville, Chapter Chapter 10 R. Mall, Chapter 3 B. Dasarathy, “Timing constraints of R-T systems,” IEEE TSE, 1985, pp

74
74 Summary We started by discussing some general concepts in: – formal specification techniques.

75
75 Summary Formal requirements specifications: –have several positive characteristics. –But the major shortcoming is that they are hard to use.

76
76 Summary It is possible that formal techniques will become more usable in future –with the development of suitable front-ends.

77
77 Summary We discussed a sample specification technique, –algebraic specification –gives us a flavour of the issues involved in formal specification.

78
78 Summary We discussed specification of timing constraints: –classification –modelling using FSMs

79
79 Next Lecture Real-time system design: –Structured analysis of system behavior –Ward and Mellor technique

Similar presentations

© 2016 SlidePlayer.com Inc.

All rights reserved.

Ads by Google