Static Techniques for V&V

Hierarchy of V&V techniques

Static Analysis

V&V

Dynamic Techniques

Model Checking

Simulation

SymbolicExecution

Testing InformalAnalysis

FormalAnalysis

Static Techniques

Proofs Review

Inspection

Walkthrough

Analysis

• Different from experimenting (testing).

–  • Based on a model

– Source code or abstracted source code– Not the actual product (executable).

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

Informal Analysis

• Reviews• Inspections• Walkthroughs

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

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

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

(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)

Formal correctness proofs

{true}Begin

read (a);read (b);x = a + b;write (x)

end;{output = input1 + input2}

Precondition

Post condition

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

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}

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

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

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.

Notes

• We assume there are no side effects in expr.

Consider examples

• {x = 5} x = x + 1 {x = 6}

• {z-43 > y + 7} x = z – 43 {x > y + 7}

Sequences

• Suppose you have shown {F1} S1 {F2} and {F2} S2 {F3}

• You can deduce– {F1} S1;S2 {F3}

Consider conditional:

{true}if x >= y then

max = xelse

max = y;{ (max = x or max = y) AND (max >= x and max >= y) }

Proof informally by cases:

 assume x >= y.then { (x = x or x = y) AND (x >= x and x >= y) },

which is true.

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}

Loop invariants

• I is a loop invariant• cond is the loop condition (while loop)• S is the body of the loop

Loop example:

{x > y}while (x <> 0)

x = x –2y = y –2

end while{x > y and x = 0}

Invariant

Loop example:

{x > y}while (x <> 0)

x = x –2y = y –2

end while{x > y and x = 0}

Note: Loop is not guaranteed to terminate

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.

Example {input1>0 and input2>0}beginread(x); read(y); div=0;while x>=y loopdiv = div + 1;x = x – y;end loop;write (div); write (x);

end{input1 = output1*input2 + output2 and 0<=output2<input2}

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

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

Notes 3

• Automated Theorem Provers: ACL2, HOL, Isabelle, Clam/Oyster– Theorem proving frameworks for software

• Outline:

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. 

Model Checking

• Exhaustive search through state space of program (complete state space expansion)

• Form of symbolic execution• Problem: state space

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

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?

Automated Programming

• Automatically generate programs from specifications

• Deductive Synthesis: extract a program from a proof

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

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