1 / 50

Program Proving Notes

Program Proving Notes. Ellen L. Walker. Formal Specification & Proof of Programs (Verification). Formally proving that a program satisfies a formal specification Alternative to testing to determine whether a program works as specified. One means of specifying program semantics. Definitions.

verdi
Download Presentation

Program Proving Notes

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. Program Proving Notes Ellen L. Walker

  2. Formal Specification & Proof of Programs (Verification) • Formally proving that a program satisfies a formal specification • Alternative to testing to determine whether a program works as specified. • One means of specifying program semantics

  3. Definitions • Specification— description of what a program should do, usually in English. • Formal specification— a specification using formal mathematical notation. Mathematical notation makes the specification more concise & more precise. • Proving (verifying) a program— given a program and a formal specification, use formal proof techniques (e.g. induction) to prove that the program behavior fits the specification. • Specification of a programming language (semantics)— formal specification for each statement in the language.

  4. Formally Proving a Program • Given: • formal specification of program • specification of programming language • a program in the language • Prove: • the program executes according to specifications

  5. Conditions in Specification • Preconditions • Must hold before the program executes • Postconditions • Must hold after the program executes A formal specification always has both preconditions and postconditions

  6. Notation • P { S } Q • P is the precondition • S is the program (or statement) • Q is the postcondition • P and Q are written in logic • S is written in the programming language (or pseudocode)

  7. Specification as Logic • (P and execution of S) -> Q • If this expression is always true we say the specification is valid

  8. Example • x > 0 { x = -x } x < 0 • Precondition: x>0 • Postcondition: x<0 • Program: x = -x • This specification is valid • When the precondition holds before the program, the postcondition will always hold after the program.

  9. Special Cases • P { S } true • Valid for all programs and preconditions • false { S } Q • Valid for all programs and postconditions • When the precondition is false before program runs, the specification is valid no matter what!

  10. Many Choices for P and Q • true { y = x + 1} y > x • x > 0 { y = x + 1} y > x • x = 1 { y = x + 1} y > x • x = 1 { y = x + 1} true • x = 1 {y = x + 1} y > x • x = 1 {y = x + 1} y > 1 • x = 1 {y = x + 1} y = 2

  11. Logical Implication • P->W (“P implies W” or “If P then W”)

  12. Mathematical examples • (a>b) -> (b < a) true • (a≥b) -> (a > b) false • (a>b) -> (a ≥ b) true • (a>b) -> (a > b+1) false • (a>b) -> (a ≥ b+1) false • (a>b) and a and b are integers -> (a≥b+1) true

  13. Rules of Implication • Shorthand: “a->b” means “a->b is true” • (A and B) -> A • (A and B) -> B • A -> (A or B) • B -> (A or B) • (A->B) is equivalent to (not B -> not A)

  14. Strength of Conditions • If P1 and P2 are conditions, and P1 -> P2, • Then P1 is stronger than P2and P2 is weaker than P1 • Intuition: stronger conditions are more specific, have fewer “possibilities”

  15. Strength of Conditions (continued) • The strongest possible condition is false • False -> Q for all Q • The weakest possible condition is true • P -> True for all P • Not all conditions are comparable • (y > 1) is not comparable to (x > 0) • (y > 5) is not comparable to (y < 8) • No implication either way

  16. Weakest Precondition • Many choices for Precondition • true { y = x + 1} y > x • x > 0 { y = x + 1} y > x • x = 1 { y = x + 1} y > x • Choose the weakest for best specification • Avoids “unnecessary” specification

  17. Why Weakest Precondition? • Suppose P and W are preconditions and P->W (W is weaker) • Given W { S } Q and P true before the program begins • Because P->W, W is also true before the program begins • Therefore P { S } Q • “W is the precondition that implies all other preconditions that allow S to run and guarantee Q as a postcondition” • Notation: W = wp(S, Q)

  18. Proving a Program Specification Goal: prove P { S } Q • Find wp(S,Q) • Prove that P -> wp(S, Q) Work backwards from postcondition to precondition

  19. Example • Prove k>0 {x = 1/k } xk=1 • wp(x=1/k,xk=1) is k≠0 • (k>0) -> (k≠0) for all k • Therefore, our specification is true.

  20. More Examples • Prove x = 1 {x = 1/x} x > 0 • wp (x = 1/x, x > 0) is 1/x > 0, or x > 0 • Since 1>0, x=1 implies x > 0 • Therefore, the specification x =1 {x = 1/x} x > 0 is true. • Prove x ≠ 0 {x = x + 1} x > 0 • wp (x= x + 1, x > 0) is x' + 1 > 0 or x' > –1 • x ≠ 0 doesn't necessarily imply x > –1 (consider x = –5) • Therefore, the specification x ≠ 0 {x = x + 1} x > 0 is false

  21. Programming Language Semantics • Language consists of Statements • Complex statements derived from simpler statements and control structures • Conditionals (IF) • Loops (WHILE)

  22. A Small Language • Empty statement (skip) • Assignment statement (x=y) • Sequence of statements ( { S1 S2 } ) • Conditional ( if (C) S1 else S2 ) • Loop ( while (C) S )

  23. Specifying Language Semantics • For each statement, determine the wp of the statement • Statement wp depends on its parts • Using conditions (C) directly • Using wp of subordinate statements (S)

  24. Semantics of skip • The empty statement has no effect • Therefore wp(skip, Q) is Q • Example: wp(skip, x<0) is x<0

  25. Semantics of Assignment • Given x = E (where E is an expression) • Two cases: • Postcondition does not contain x • Wp(x=E,Q) = Q because Q is unaffected • Postcondition does contain x • Consider Q as a function of x • Wp(x=E, Q(x)) = Q(E) • To be careful, we must add “and E is defined” to avoid cases such as x = 1/0

  26. Assignment Examples • Wp (x=y, y>5) is y>5 • Q does not contain x • Wp (x=y, x<2) is y<2 • Q does contain x, so substitute y for x • Wp (x = x+1, x>4) is x’>3 • Use x’ as the “before” value of x

  27. Assignment vs. Equality Test • Be careful • x=0 {x=1} x=1

  28. Semantics of a Sequence • Given P {S1} R and R {S2} Q, we can write P { {S1 S2} } Q • Therefore • Wp({S1 S2}, Q) = wp(S1, wp(S2, Q)) • Find wp of the second statement and the postcondition (R, above) • Then find wp of the first statement with that wp (R) as the postcondition

  29. Examples • wp ({x=y; x= 1/x;}, x>0) is wp(x=y, wp(x=1/x, x>0)) iswp(x=y, 1/x > 0) is wp(x=y, x>0) isy > 0 • wp({x = 2*t; skip;}. x>5) iswp(x=2*t; wp(skip, x>5)) iswp(x=2*t, x>5) is2t > 5 is t > 2.5

  30. One More Example • true {x = 5; y = 2; x = x*y} x=10

  31. Semantics of IF • The conditional with test T and statements S1 and S2 is • if (T) S1 else S2 • When there is no “else, write: if (T) S1 else skip • Wp(if (T) S1 else S2) is (T and wp(S1,Q)) or ((not T) and wp(S2,Q)) • If T is true, use S1’s precondition • If T is false, use S2’s precondition • Equivalently,(T-> wp(S1,Q)) and ((not T)-> wp(S2,Q))

  32. Proving a Loop • Two things to prove • If the loop terminates, the postcondition is true • The loop terminates • Proving only the postcondition is called weak correctness

  33. Weak Correctness Example • True {while true x=1} x=1 • Weakly correct • If the loop ever terminated, x would be 1 • Not strongly correct • But the loop will never terminate

  34. Semantics of WHILE • Treat as a “repeated if”, where B must be true the last time • Define Pk = wp(loop executes k times, Q) • wp(while (B) S, Q) • P0 = Not B and Q • P1 = B and wp(S, P0) • P2 = B and wp(S, P1) • Pk = B and wp(S, Pk-1) • wp(while (B) S, Q) = P0 or P1 or P2 or… Pk

  35. How to Solve the Infinite OR • Direct approach • Use mathematics to solve the infinite series • Nice if it works, but you have to see the pattern • Indirect approach • Prove weak correctness and termination separately • Use “loop invariant”

  36. Example: Direct Proof • What is wp(while (i<n) i=i+1, i=n) ? • H0 : not B and Q • not(i<n) and i=n • i=n • H1: B and wp(S, H0) • i<n and wp(i=i+1,i=n) • i<n and i+1=n • i+1=n

  37. Direct Proof, continued • H2: B and wp(S,H1) • i<n and wp(i=i+1,i+1=n) • i+2=n • Hk: B and wp(S,Hk-1) • i<n and wp(i=i+1,i+k-1=n) • i+k=n • H0 or H1 or H2 or H3 or … • i=n or i+1=n or i+2=n or … i+k=n … • The above is equivalent to writing i≤n

  38. Loop Invariants (Indirect method) • A loop invariant is any statement that is true every time a loop executes. • For example, consider the fragment: i = 1; x = 1; while(i < n ) { x = x * i; i = i + 1; } • One invariants is: i<n (or the loop ends)

  39. A Loop has Many Invariants • 3 different invariants for the example loop: • i < n (because the loop will terminate if i ≥ n) • true (an invariant of every loop) • x = (i – 1)! (because x started at 1 and has been multiplied by 1, 2, 3 ... i • This last invariant is most useful: it tells what the loop does.

  40. Using Loop Invariants to Prove Weak Correctness • Prove P { while B S} Q 1. Invariant is true after each time S runs B and inv {S} inv • When the loop ends, Q is true (Not B and inv) -> Q • Invariant is true before the loop P -> inv

  41. Example Loop i = 1 and x = 1 and n > 0 //pre { while( i < n ) { x = x * i; i = i + 1; } } x = (n – 1)! //post • Prove, using inv: 0< i ≤ n and x = (i –1)!

  42. Step 1 • B and inv {S} inv • B and inv is: (i<n) and 0< i ≤ n and x = (i –1)! , or 0<i<n and x=(i-1)! • Wp(S, inv) is: Wp((x=x*i, i=i+1), 0<i≤n and x=(i-1)!) = Wp(x=x*i, wp(i=i+1, 0<i ≤ n and x=(i-1)!)) = Wp(x=x*i, 0<i+1 ≤ n and x=(i!)) 0<i+1 ≤ n and x*i = i! -1<i ≤ n-1 and x = (i-1)! (since i is integer, we know that -1< i < n) • B and inv -> wp(s, inv), so step 1 is complete

  43. Step 2 • Not B and inv -> Q (i>= n) and (0< i ≤ n and x = (i –1)! ) is i = n and x = (i-1)! x = n-1! • The above expression is Q, so Step 2 is complete

  44. Step 3 • P -> inv • P is: i=1 and x=1 and n>0 • Since n>0 and i=1, 0<I ≤ n • We define 0! = 1. Since x=1 and i=1, x=(i-1)! • Both parts of the invariant are proven, so Step 3 is complete

  45. Finding the Invariant • Invariant is an approximation to the weakest precondition • Find it by working the loop body backwards, treating inv as a function with loop variables as parameters • Wp(inv(params), S) = B and inv(params) • Your first guess is often too weak (it’s an invariant but won’t prove the loop)

  46. Example Find an invariant for the loop while (i < n) { i = i + 1; x = x * i; } Note: the invariant also “explains” the loop

  47. Proving Termination • Somehow, we need to make an argument that: • The loop ends when B becomes false • Each iteration gets us “closer” to B becoming false • Formally, this is done using a “well-founded set”

  48. Well-Founded Set • An ordered set with a “bottom element” • Any decreasing sequence in the set must reach the “bottom element” with a finite number of elements • Examples: • [0-99] • Non-negative integers • Letters of the alphabet (bottom is “a”)

  49. Proving Termination using WFS • Find a well-founded set such that: • Every loop execution generates an element of the set (e.g. value of n-I) • If the bottom element is reached, the loop terminates (e.g. n-I becomes 0 when I=n) • The sequence of values generated through multiple iterations of the loop is decreasing (e.g. since I gets bigger, n-I gets smaller)

  50. Summary • Axiomatic semantics allows any program in the language to be proven correct • In the specification of a language, the weakest precondition for each statement type must be defined • Loops can be proven directly using an OR of weakest preconditions, or indirectly using an invariant and a separate proof of termination

More Related