1 / 39

Formal Methods

Formal Methods. Lecture 16 March 22, 2011. 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

efuru
Télécharger la présentation

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  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

  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; • OperationPrev (I:Integer): Integer; • requires I > Min_Int; • ensuresPrev = 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 (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

  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 OperationDo_Nothing (updates I:Integer); requires … ensures I = #I; • Code Increment (I); Decrement (I); CS 315 Spring 2011

  22. Comparing Specifications • Are these two specifications the same? Spec 1: OperationDo_Nothing (preserves I: Integer); requires … Spec 2: OperationDo_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: OperationDo_Nothing (updates I: Integer); requires I < Max_Int; ensures I = #I; Code: Increment(I); Decrement(I); CS 315 Spring 2011

  26. Mathematical Reasoning:Example – Prove Correctness Establish the goals in state-oriented terms using a table CS 315 Spring 2011

  27. Mathematical Reasoning:Example – Prove Correctness Assume the requires clause at the beginning (Why?) CS 315 Spring 2011

  28. Mathematical Reasoning:Example – Prove Correctness Assume calls work as advertised CS 315 Spring 2011

  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

  30. Mathematical Reasoning:Example – Prove Correctness 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 • Spec: OperationDo_Nothing (updates I: Integer); ensures I = #I; Code: If (I < Max_Int()) then Increment(I); Decrement(I); end; CS 315 Spring 2011

  33. 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

  34. Mathematical Reasoning:Example 2 – Prove Correctness Establish the goals in state-oriented terms using a table CS 315 Spring 2011

  35. Mathematical Reasoning:Example 2 – Prove Correctness Establish the conditions CS 315 Spring 2011

  36. Mathematical Reasoning:Example 2 – Prove Correctness Establish sub-goals for different conditions CS 315 Spring 2011

  37. Mathematical Reasoning:Example 2 – Prove Correctness Fill in other assumptions and obligations as before CS 315 Spring 2011

  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

  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

More Related