Presentation is loading. Please wait.

Presentation is loading. Please wait.

Hoare-style program verification

Similar presentations


Presentation on theme: "Hoare-style program verification"— Presentation transcript:

1 Hoare-style program verification
K. Rustan M. Leino Guest lecturer Rob DeLine’s CSE 503, Software Engineering University of Washington 3 May 2004

2 Programming language skip x := E assert B S ; T if B then S else T end
while B do S end

3 Procedural abstraction
Procedure declaration procedure Find(int[] a, int m, int n, int x): int Procedure call call r := Find(scores, 0, numStudents, 100) Procedure implementation impl Find(int[] a, int m, int n, int x): int { … }

4 Procedure specifications
Procedure declaration procedure Find(int[] a, int m, int n, int x): int specification Procedure call call r := Find(scores, 0, numStudents, 100) Procedure implementation impl Find(int[] a, int m, int n, int x): int { … } Contract between callers and implementations Specification spells out the entire contract Reason about call in terms of specification only, not any particular implementation Check implementation against specification only, not any particular call site

5 Contracts Caller obligations Implementation obligations Precondition
Postcondition

6 Informal contract StringBuilder.Append Method (Char[], Int32, Int32)
Appends the string representation of a specified subarray of Unicode characters to the end of this instance. public StringBuilder Append(char[] value, int startIndex, int charCount); Parameters value A character array. startIndex The starting position in value. charCount The number of characters append. Return Value A reference to this instance after the append operation has occurred. Exceptions Exception Type Condition ArgumentNullException value is a null reference, and startIndex and charCount are not zero. ArgumentOutOfRangeException charCount is less than zero. -or- startIndex is less than zero. startIndex + charCount is less than the length of value.

7 Formal contract Precondition
Callers are expected to establish precondition before invoking method Implementations can assume precondition holds on entry public StringBuilder Append( char[] value, int startIndex, int charCount); requires value != null || (charCount == 0 && startIndex == 0); requires 0 <= charCount && 0 <= startIndex; requires startIndex + charCount <= value.Length; ensures result == this; Postcondition Implementations are expected to establish postcondition on exit Callers can assume postcondition upon return from method invocation

8 A bogus implementation?
procedure Sum() requires 0≦N; ensures s = (Σi | 0≦i<N ・ a[i]); impl Sum() { N := 0; s := 0 }

9 More about postconditions
Often relate pre-state and post-state ensures x > old(x); Must say what goes unchanged ensures N = old(N); modifies only s;

10 Information hiding and data abstraction
class Counter { model n: int; method Increment() modifies only n; ensures old(n) + 1 = n; method Decrement() modifies only n; ensures old(n) = n + 1; }

11 Information hiding and data abstraction
class Counter { model n: int; private a: int; private b: int; representation n is a – b; method Increment() modifies only n; ensures old(n) + 1 = n; { a := a + 1 } method Decrement() modifies only n; ensures old(n) = n + 1; { b := b + 1 } }

12 Data invariants class Counter { model n: int; private a: int; private b: int; representation n is a – b; invariant 0 ≦ a ∧ 0 ≦ b; method Increment() modifies only n; ensures old(n) + 1 = n; { a := a + 1 } method Decrement() modifies only n; ensures old(n) = n + 1; { b := b + 1 } }

13 Vision Record design decisions
Increased programmer productivity and program reliability through increased rigor Record design decisions + Utilize automatic checking = Detect errors and improve maintainability

14 Extended Static Checker for Java (ESC/Java)
Built at Compaq SRC ESC/Java 2 built by Joe Kiniry (U. Nijmegen) and David Cok (Kodak) Input: Java + user-supplied annotations annotations are subset of JML (Java Modeling Language—Gary Leavens, et al., Iowa State U.) Annotation language captures programmer design decisions Powered by program semantics and automatic theorem proving Performs modular checking

15 ESC/Java demo

16 Program checker design tradeoffs
Missed errors Spurious warnings Annotation overhead Performance

17 ESC/Java experience: annotations
Capture common design decisions Suggested immediately by warnings Overhead: 4-10% of source code ~1 annotation per field or parameter Most common annotations: preconditions invariants Most common things to specify: non nullity container element types

18 ESC/Java experience: performance
50% of all methods: < 0.5 s 80% of all methods: < 1 s time limit: 300 s total time for Javafe (~40kloc): 65 min.

19 Tool architecture Annotated source program
Translator (weakest preconditions) Verification condition Valid Automatic theorem prover Resource exhausted Counterexample context Post processor Warning messages

20 Spec# and Boogie Boogie Spec# compiler Run-time exceptions
Compile-time error messages Spec# compiler Boogie Code + contracts in Spec# [Mike Barnett, Robert DeLine, Manuel Fähndrich, K. Rustan M. Leino, Wolfram Schulte]

21 Spec# is C# extended with:
Non-null types Preconditions Postconditions Object invariants Checked exceptions ...

22 weakest-precondition generator
Boogie: Under the hood MSIL Boogie translator Inference engine BoogiePL weakest-precondition generator verification condition Theorem prover Warnings

23 Spec#: Object invariants
class C { int x, y; invariant x < y; Object invariant always holds, except possibly when the object is exposed [Joint work also with Peter Müller and David A. Naumann]

24 Spec#: Object invariants
class C { int x, y; invariant x < y; public void M(T! o) { … expose (this) { this.x = this.y; o.P(); this.y++; } … } The object invariant may be temporarily violated here The object invariant is checked to hold here

25 Spec#: Object invariants
class C { int x, y; invariant x < y; public void M(T! o) { … expose (this) { this.x = this.y; o.P(); this.y++; } … } The exposed/unexposed state of the object is recorded, so as to detect possible bad re-entrancy

26 Evolution C# managed code  Spec# non-null types, parameter validation  Boogie verification

27 Summary of lectures Hoare triples and weakest preconditions give a way to prove a program correct Invariants are everywhere Procedure specifications Tool support for software engineering


Download ppt "Hoare-style program verification"

Similar presentations


Ads by Google