1. Static Techniques for V&V

2. Hierarchy of V&V techniques Static Analysis V&V Dynamic Techniques Model Checking Simulation Symbolic Execution Testing Informal Analysis Formal Analysis Static Techniques Proofs Review Inspection Walkthrough

3. Analysis Different from experimenting (testing). – Based on a model –Source code or abstracted source code –Not the actual product (executable).

4. Analysis Can be subject to failure itself (wrong proof) –Similar to mathematical proofs –Start with conjecture –Try to show it is a theorem Find either

5. Informal Analysis Reviews Inspections Walkthroughs

6. Code Reviews: Read. If you can’t read it, neither can the people trying to maintain it Do this for any artifact This is a team effort

7. Walk-through: Simulate by hand, pick test cases, generalize Looking for any bugs Keep size small (3-5) Players get documentation ahead of time Meeting is restricted to a few hours

8. Code Inspections: Looking for specific bugs Common bugs: –Un-initialized variables –Jumps into loops –Incompatible assignments (type errors) –Non-termination –Out-of-bounds –Memory leaks –Parameter mismatches

9. (Semi) Formal Analysis Techniques Proofs Static checking –Code analysis: syntax errors and simple error patterns (i.e. Pointer problems) –Structure checking: CFGs with structural error detection (dead code, logic errors)

10. Formal correctness proofs {true} Begin read (a); read (b); x = a + b; write (x) end; {output = input1 + input2} Precondition Post condition

11. Proof Step 1 {true} Begin read (a); read (b); x = a + b; write (x) end; {output = input1 + input2} Due to the semantics of write(), the post condition holds iff {x=input1 + input2} holds

12. Proof Step 2 {true} Begin read (a); read (b); x = a + b; write (x) end; {output = input1 + input2} {x=input1 + input2} holds iff {a+b = input1 + input2}

13. Proof Step 3 {true} Begin read (a); read (b); x = a + b; write (x) end; {output = input1 + input2} Since the semantics of read(a) and read(b) assign input1 to a and input2 to b, {a+b = input1 + input2} holds

14. Basic Idea For any postcondition POST on program variables, and For any assignment statement x = expr, –expr is an expression containing variables POST holds after the assignment iff POST’ holds before the assignment

15. Basic Idea We want to show that whenever the preconditions hold, the postconditions must hold, that is –Pre -> Post We can take post conditions and derive necessary and sufficient conditions, then show the preconditions match these.

16. Notes We assume there are no side effects in expr.

17. Consider examples {x = 5} x = x + 1 {x = 6} {z-43 > y + 7} x = z – 43 {x > y + 7}

18. Sequences Suppose you have shown {F1} S1 {F2} and {F2} S2 {F3} You can deduce –{F1} S1;S2 {F3}

19. Consider conditional: {true} if x >= y then max = x else max = y; { (max = x or max = y) AND (max >= x and max >= y) }

20. Proof informally by cases: assume x >= y. then { (x = x or x = y) AND (x >= x and x >= y) }, which is true.

21. Rules of inference, conditional: Given {pre and condition} s1 {post} and {pre and not condition} s2 {post} Infer {pre} if condition then s1 else s2 {post}

22. Loop invariants I is a loop invariant cond is the loop condition (while loop) S is the body of the loop

23. Loop example: {x > y} while (x <> 0) x = x –2 y = y –2 end while {x > y and x = 0} Invariant

24. Loop example: {x > y} while (x <> 0) x = x –2 y = y –2 end while {x > y and x = 0} Note: Loop is not guaranteed to terminate

25. Loops example: Can easily show that if x > y at exit, it must have been so at entry. Might need induction to do these in general. Notice, this loop does not end if x is odd on entry.

26. Example {input1>0 and input2>0} begin read(x); read(y); div=0; while x>=y loop div = div + 1; x = x – y; end loop; write (div); write (x); end {input1 = output1*input2 + output2 and 0<=output2<input2}

27. Notes: Formal proofs may be more complex than the program Proofs are error prone if done by hand Proofs require mathematical sophistication Proofs may be overwhelming to do

28. Notes 2: Proofs rely on a semantic model of the environment (language, processor): They only provide assurance under this model Proofs may depend on continuous systems, not discrete systems Are they useful? –only for very small parts of the code. –they can be automated (PVS, for example) Many research issues here

29. Notes 3 Automated Theorem Provers: ACL2, HOL, Isabelle, Clam/Oyster –Theorem proving frameworks for software Outline:

30. Symbolic execution Similar to testing, but instead of individual test cases, you have symbolic generalization each test is a test of an entire class of tests. (testing, one element of equiv class. symbolic, entire class). Plan: try to get path coverage. How? In general, abstract the source code with respect to some property. Then do symbolic execution of every path through abstracted code. Research problem.

31. Model Checking Exhaustive search through state space of program (complete state space expansion) Form of symbolic execution Problem: state space

32. Model Checker Model software as FSA (what’s that?) Model properties in some logic, usually temporal logic (LTL, CTL) Represent FSA as a graph (what’s that?) Traverse graph (how?) Show properties hold in each node of graph

33. Model Checking What does it mean if an assertion does not hold in the model? What does it mean if the assertion does hold in the model?

34. Automated Programming Automatically generate programs from specifications Deductive Synthesis: extract a program from a proof

35. Cleanroom Build software in such a way as to prevent defects from being introduced. No testing. Specify system. Refine specification systematically, proving that the refinement meets the specification

36. Transformational Programming Take an input string and rewrite it: –aBc => axyc –Rules can have conditions –Rules can have procedural attachment or be higher order Formal, stepwise refinement of specification to program Can check each step individually “correct” by construction