130 Views

Download Presentation
##### Formal Methods

**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. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -

**Formal Methods**Lecture 16 March 22, 2011 Adapted from slides provided by Jason Hallstrom and Murali Sitaraman (Clemson) CS 315 Spring 2011**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?**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**Informal Specifications**• See Bertrand Meyer’s article on Formal Specifications in IEEE Computer: • http://se.ethz.ch/~meyer/publications/ieee/formalism.pdf • Problems with even very carefully designed informal specs • Contradiction • Noise • … CS 315 Spring 2011**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**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**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**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**Introduction to Mathematical Reasoning**CS 315 Spring 2011**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**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**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**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**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; • OperationPrev (I:Integer): Integer; • requires I > Min_Int; • ensuresPrev = I – 1; CS 315 Spring 2011**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**Specification of Integer Operation**Operation Next (I: Integer): Integer; requiresI < Max_Int; ensures Next = I + 1; Ambiguous Specification Operation Next (preserves I: Integer): Integer; requiresI < Max_Int; ensures Next = I + 1; Clear Specification – I unchanged OperationIncrement (updates I: Integer): Integer; requiresI < Max_Int; ensuresI = #I + 1; Clear Specification – I modified CS 315 Spring 2011**Exercise**• Specify Decrement Operation CS 315 Spring 2011**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**Using a Specification**• A specification can be implemented various ways • Have to judge if code meets specification • Example – the Code appears to do what the Spec says but the Spec and Code don’t agree – fix them • Spec OperationDo_Nothing (updates I:Integer); requires … ensures I = #I; • Code Increment (I); Decrement (I); CS 315 Spring 2011**Methods for Checking Correctness**• Testing • Tracing or Inspection • Mathematical Reasoning CS 315 Spring 2011**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**Mathematical Reasoning:Example – Prove Correctness**• Spec: OperationDo_Nothing (updates I: Integer); requires I < Max_Int; ensures I = #I; Code: Increment(I); Decrement(I); CS 315 Spring 2011**Mathematical Reasoning:Example – Prove Correctness**Establish the goals in state-oriented terms using a table CS 315 Spring 2011**Mathematical Reasoning:Example – Prove Correctness**Assume the requires clause at the beginning (Why?) CS 315 Spring 2011**Mathematical Reasoning:Example – Prove Correctness**Assume calls work as advertised CS 315 Spring 2011**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**Mathematical Reasoning:Example – Prove Correctness**More assertions to be confirmed (Why?) CS 315 Spring 2011**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? • Assume the ensures clause of Q in the state after Q. Why? • Prove assertions to be confirmed CS 315 Spring 2011**Mathematical Reasoning:Example 2 – Prove Correctness**• Spec: OperationDo_Nothing (updates I: Integer); ensures I = #I; Code: If (I < Max_Int()) then Increment(I); Decrement(I); end; CS 315 Spring 2011**Mathematical Reasoning:Example 2 – Prove Correctness**• These specs are the same • Spec: OperationDo_Nothing (updates I: Integer); ensures I = #I; • Spec: OperationDo_Nothing(restores I: Integer); CS 315 Spring 2011**Mathematical Reasoning:Example 2 – Prove Correctness**Establish the goals in state-oriented terms using a table CS 315 Spring 2011**Mathematical Reasoning:Example 2 – Prove Correctness**Establish the conditions CS 315 Spring 2011**Mathematical Reasoning:Example 2 – Prove Correctness**Establish sub-goals for different conditions CS 315 Spring 2011**Mathematical Reasoning:Example 2 – Prove Correctness**Fill in other assumptions and obligations as before CS 315 Spring 2011**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**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