Presentation is loading. Please wait.

Presentation is loading. Please wait.

Lecture 16 March 22, 2011 Formal Methods CS 315 Spring 2011 1 Adapted from slides provided by Jason Hallstrom and Murali Sitaraman (Clemson)

Similar presentations


Presentation on theme: "Lecture 16 March 22, 2011 Formal Methods CS 315 Spring 2011 1 Adapted from slides provided by Jason Hallstrom and Murali Sitaraman (Clemson)"— Presentation transcript:

1 Lecture 16 March 22, 2011 Formal Methods CS 315 Spring 2011 1 Adapted from slides provided by Jason Hallstrom and Murali Sitaraman (Clemson)

2 Requirements vs. Specifications Requirements definition Intended for customers in addition to software developers Informal descriptions are necessary Specification For use by members of a software development team Formal (mathematical) descriptions are necessary

3 Interface Specification Serves as a contract between component users (clients) and developers (implementers) Typically describes the demands on users and responsibilities for implementers Should present the essentials in “user- oriented” terms (abstraction) and hide the inessentials (information hiding)

4 Informal Specification: Examples C++ STL Template specifications Java util component specifications http://doc.java.sun.com/DocWeb/api/java.util.Stack http://doc.java.sun.com/DocWeb/api/java.util.Queue Questions for discussion Do they support information hiding? Do they support abstraction? Can they generalize? Is it possible to make them unambiguous?

5 Informal Specifications Straightforward descriptions Push pushes an object on a stack How much do they help? Use of metaphors A Queue is like a line at a fast food restaurant Do they generalize? Use of implementation details Push behaves like AddElement method on Vector Is this appropriate for a user-oriented cover story? CS 315 Spring 2011 5

6 Informal Specifications See Bertrand Meyer’s article on Formal Specifications in IEEE Computer Problems with even very carefully designed informal specs Contradiction Noise … CS 315 Spring 2011 6

7 Formal Interface Specification Communicates precisely the demands and responsibilities to component users and developers Allows for independent development of client and implementation components in parallel in a team environment Minimizes integration costs CS 315 Spring 2011 7

8 Reasoning Benefits Formal Specifications make it possible to formally reason about correctness of software Such reasoning may be manual or mechanical (i.e. with automate support) CS 315 Spring 2011 8

9 Languages for Formal Specification ANNA (and SPARK) for Ada JML for Java Larch/C++ for C++ Spec# for C3 … Eiffel RESOLVE … VDM Z CS 315 Spring 2011 9

10 Specification Language Summary Some specification languages are designed for particular programming languages Some are general purpose Some specification languages are integrated with programming constructs A few additionally integrate the ability to perform formal mathematical reasoning CS 315 Spring 2011 10

11 Introduction to Mathematical Reasoning CS 315 Spring 2011 11

12 Motivating Example What does the following code do to Integer I, where Foo1 and Bar1 are functions that modify their argument? I = Foo1(I); I = Bar1(I); CS 315 Spring 2011 12

13 Motivating Example Or, what does this code do to integers I and J? I = Foo2(I,J); J = Bar2(I,J); I = Bar2(I,J); CS 315 Spring 2011 13

14 Motivating Example Now, what does this code do to Integer I? I = Next(I); I = Prev(I); How sure are we? Have to account for bounds in our analysis Summary: … Need formal descriptions beyond just names CS 315 Spring 2011 14

15 Motivating Example What does this code do to Integers I and J? I = Sum (I,J); J = Difference (I,J); I = Difference (I,J); How sure are we? CS 315 Spring 2011 15

16 Specification of Integer Operations Think of ints as integers in math Constraints, for all Integers I: Min_Int <= I <= Max_Int Operation Next (I:Integer): Integer; requires I < Max_Int; ensures Next = I + 1; Operation Prev (I:Integer): Integer; requires I > Min_Int; ensures Prev = I – 1; CS 315 Spring 2011 16

17 Specification of Integer Operations Can parameter values change? Depending on the language Depending on how parameters are passed in Need to make it clear with a specification whether or not a parameter can be modified Operation Next (preserves I: Integer): Integer; requires I < Max_Int; ensures Next = I + 1; CS 315 Spring 2011 17

18 Specification of Integer Operation CS 315 Spring 2011 18 Operation Next (preserves I: Integer): Integer; requires I < Max_Int; ensures Next = I + 1; Operation Next (I: Integer): Integer; requires I < Max_Int; ensures Next = I + 1; Operation Increment (updates I: Integer): Integer; requires I < Max_Int; ensures I = #I + 1; Ambiguous Specification Clear Specification – I unchanged Clear Specification – I modified

19 Exercise Specify Decrement Operation CS 315 Spring 2011 19

20 Meaning of Specifications Requirements and guarantees Requires clauses are preconditions Ensures clauses are postconditions Callers are responsible for requirements Caller of Increment is responsible for making sure input I < Max_Int Guarantees hold only if callers meet their requirements CS 315 Spring 2011 20

21 Using a Specification A specification can be implemented various ways Have to judge if code meets specification Example – is the code correct? Spec Operation Do_Nothing (updates I:Integer); requires … ensures I = #I; Code Increment (I); Decrement (I); CS 315 Spring 2011 21

22 Comparing Specifications Are these two specifications the same? Spec 1: Operation Do_Nothing (preserves I: Integer); requires … Spec 2: Operation Do_Nothing (updates I: Integer); requires … ensures I = #I; CS 315 Spring 2011 22

23 Methods for Checking Correctness Testing Tracing or Inspection Mathematical Reasoning CS 315 Spring 2011 23

24 Mathematical Reasoning Goal: To prove correctness Method: The rest of this presentation Consequences: Can provide correctness on all valid inputs Can show the absence of bugs CS 315 Spring 2011 24

25 Mathematical Reasoning: Example – Prove Correctness Spec: Operation Do_Nothing (updates I: Integer); requires I < Max_Int; ensures I = #I; Code: Increment(I); Decrement(I); CS 315 Spring 2011 25

26 Mathematical Reasoning: Example – Prove Correctness AssumeConfirm 0 Increment (I); 1 Decrement (I); 2I2 = I0 CS 315 Spring 2011 26 Establish the goals in state-oriented terms using a table

27 Mathematical Reasoning: Example – Prove Correctness AssumeConfirm 0I0 < Max_Int and … Increment (I); 1 Decrement (I); 2I2 = I0 CS 315 Spring 2011 27 Assume the requires clause at the beginning (Why?)

28 Mathematical Reasoning: Example – Prove Correctness AssumeConfirm 0I0 < Max_Int and … Increment (I); 1I1 = I0 + 1 Decrement (I); 2I2 = I1 - 1I2 = I0 CS 315 Spring 2011 28 Assume calls work as advertised

29 Mathematical Reasoning: Example – Prove Correctness Prove the goal(s) using assumptions Prove I2 = I0 I2 = I1 -1 (assumption in State 1) = (I0 + 1) – 1 (assumption in state 1) = I0(simplification) More proof needed … CS 315 Spring 2011 29

30 Mathematical Reasoning: Example – Prove Correctness AssumeConfirm 0I0 < Max_Int and … I0 < Max_Int Increment (I); 1I1 = I0 + 1I1 > Min_Int Decrement (I); 2I2 – I1 - 1I2 = I0 CS 315 Spring 2011 30 More assertions to be confirmed (Why?)

31 Basics of Mathematical Reasoning Suppose you are verifying code for some operation P Assume its required clause in state 0 Confirm its ensures clause at the end Suppose that P calls Q Confirm the requires clause of Q in the state before Q is called. Why? Because caller is responsible Assume the ensures clause of Q in the state after Q. Why? Because Q is assumed to work Prove assertions to be confirmed CS 315 Spring 2011 31

32 Mathematical Reasoning: Example 2 – Prove Correctness Spec: Operation Do_Nothing (updates I: Integer); ensures I = #I; Code: If (I < Max_Int()) then Increment(I); Decrement(I); end; CS 315 Spring 2011 32

33 Mathematical Reasoning: Example 2 – Prove Correctness These specs are the same Spec: Operation Do_Nothing (updates I: Integer); ensures I = #I; Spec: Operation Do_Nothing (restores I: Integer); CS 315 Spring 2011 33

34 Mathematical Reasoning: Example 2 – Prove Correctness ConditionAssumeConfirm 0 If (I < Max_Int()) 1 Increment (I); 2 Decrement (I); 3 End; 4I4 = I0 CS 315 Spring 2011 34 Establish the goals in state-oriented terms using a table

35 Mathematical Reasoning: Example 2 – Prove Correctness ConditionAssumeConfirm 0 If (I < Max_Int()) 1I0 < max_int Increment (I); 2I0 < max_int Decrement (I); 3I0 < max_int End; 4I4 = I0 CS 315 Spring 2011 35 Establish the conditions

36 Mathematical Reasoning: Example 2 – Prove Correctness ConditionAssumeConfirm 0 If (I < Max_Int()) 1I0 < max_int Increment (I); 2I0 < max_int Decrement (I); 3I0 < max_int End; 4.1not(I0 < max_int)I4 = I0 4.2I0 < max_intI4 = I3I4 = I0 CS 315 Spring 2011 36 Establish sub-goals for different conditions

37 Mathematical Reasoning: Example 2 – Prove Correctness ConditionAssumeConfirm 0 If (I < Max_Int()) 1I0 < max_intI1 = I0 Increment (I); 2I0 < max_intI2 = I1 + 1 Decrement (I); 3I0 < max_intI3 = I2 - 1 End; 4.1not(I0 < max_int)I4 = I0 4.2I0 < max_intI4 = I3I4 = I0 CS 315 Spring 2011 37 Fill in other assumptions and obligations as before

38 Mathematical Reasoning: Example 2 – Prove Correctness Prove the subgoal(s) 4.1 Case: not(I0 < max_int) Prove I4 = I0 True from assumption 4.2 Case: (I0 < max_int) Prove I4 = I0 Prove: I3 = I0(assumption in state 4) Prove: (I2 – 1) = I0(assumption in state 3) … CS 315 Spring 2011 38

39 Mathematical Reasoning: Example 2 – Prove Correctness For the condition (I0 < max_int), additional proofs are needed These proofs of assertion to be confirmed in States 1 and 2 are left as exercises. CS 315 Spring 2011 39


Download ppt "Lecture 16 March 22, 2011 Formal Methods CS 315 Spring 2011 1 Adapted from slides provided by Jason Hallstrom and Murali Sitaraman (Clemson)"

Similar presentations


Ads by Google