Lecture 16 March 22, 2011 Formal Methods CS 315 Spring 2011 1 Adapted from slides provided by Jason...

CS 315 Spring 2011

1

Lecture 16March 22, 2011

Formal Methods

Adapted from slides provided by Jason Hallstrom and Murali Sitaraman (Clemson)

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

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)

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?





CS 315 Spring 2011

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

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

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

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

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

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

11

Introduction to Mathematical Reasoning

CS 315 Spring 2011

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

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

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

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

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

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

18

Specification of Integer Operation

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

CS 315 Spring 2011

19

Exercise

Specify Decrement Operation

CS 315 Spring 2011

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

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;

CodeIncrement (I);Decrement (I);

CS 315 Spring 2011

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

23

Methods for Checking Correctness

Testing

Tracing or Inspection

Mathematical Reasoning

CS 315 Spring 2011

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

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

26


Assume Confirm

0

Increment (I);

1

Decrement (I);

2 I2 = I0

Establish the goals in state-oriented terms using a table

CS 315 Spring 2011

27


Assume Confirm

0 I0 < Max_Intand …

Increment (I);

1

Decrement (I);

2 I2 = I0

Assume the requires clause at the beginning (Why?)

CS 315 Spring 2011

28


Assume Confirm


Increment (I);

1 I1 = I0 + 1

Decrement (I);

2 I2 = I1 - 1 I2 = I0

Assume calls work as advertised

CS 315 Spring 2011

29


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

30


Assume Confirm


I0 < Max_Int

Increment (I);

1 I1 = I0 + 1 I1 > Min_Int

Decrement (I);

2 I2 – I1 - 1 I2 = I0

More assertions to be confirmed (Why?)

CS 315 Spring 2011

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

32

Mathematical Reasoning:Example 2 – Prove Correctness


Integer);ensures I = #I;

Code:If (I < Max_Int()) then

Increment(I);Decrement(I);

end;

CS 315 Spring 2011

33


These specs are the same


Integer);ensures I = #I;

Spec:Operation Do_Nothing (restores I:

Integer);

CS 315 Spring 2011

34


Condition Assume Confirm

0

If (I < Max_Int())

1

Increment (I);

2

Decrement (I);

3

End;

4 I4 = I0

Establish the goals in state-oriented terms using a table

CS 315 Spring 2011

35



0

If (I < Max_Int())

1 I0 < max_int

Increment (I);

2 I0 < max_int

Decrement (I);

3 I0 < max_int

End;

4 I4 = I0

Establish the conditions

CS 315 Spring 2011

36



0

If (I < Max_Int())

1 I0 < max_int

Increment (I);

2 I0 < max_int

Decrement (I);

3 I0 < max_int

End;

4.1

not(I0 < max_int)

I4 = I0 I4 = I0

4.2

I0 < max_int I4 = I3 I4 = I0

Establish sub-goals for different conditions

CS 315 Spring 2011

37



0

If (I < Max_Int())

1 I0 < max_int I1 = I0

Increment (I);

2 I0 < max_int I2 = I1 + 1

Decrement (I);

3 I0 < max_int I3 = I2 - 1

End;

4.1

not(I0 < max_int)

I4 = I0 I4 = I0

4.2

I0 < max_int I4 = I3 I4 = I0

Fill in other assumptions and obligations as before

CS 315 Spring 2011

38


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

39


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.

Lecture 16 March 22, 2011 Formal Methods CS 315 Spring 2011 1 Adapted from slides provided by Jason...

Documents

Transcript of Lecture 16 March 22, 2011 Formal Methods CS 315 Spring 2011 1 Adapted from slides provided by Jason...