verification, slicing and visualization of programs with contracts

Verification, Slicing and Visualization of Programswith Contracts

Daniela da CruzSupervisors: Pedro Rangel Henriques, Jorge Sousa Pinto

Departamento de InformaticaUniversidade do Minho

PhD examination

October 21, 2011

Daniela da Cruz Verification, Slicing and Visualization of Programs with Contracts

Context

On one hand, Slicing plays an important role in focusing thecomprehension of a program just on a relevant part of it, withrespect to a given criterion.

On the other hand, concerning software development, the Designby Contract (DbC) approach has allowed for the application offormal methods at the code level.


Motivation

1 Traditional syntactic slicing, applied a priori, may facilitatethe verification of large programs;

2 It makes sense to slice programs based on semantic, ratherthan syntactic, criteria. Contracts may be excellent candidatesfor such criteria;

3 This kind of semantic slicing may also be helpful in theverification of component-based programs.

The goal of this thesis is to explore the interplay between slicingand program verification, as well as the visual animation of bothactivities.


Outline


Interactive Verification Conditions Generator


Verification Conditions Generators (1)

The usual way to verify the correctness of a program is through theuse of Verification Conditions Generators (VCGens).



These VCGens are usually based on one of two strategies:

Weakest preconditions

VCGw (P, S , Q) = {P → wprec(S ,Q)} ∪ VCw (S ,Q)

Strongest postconditions

VCGs(P, S , Q) = VCs(S ,P) ∪ {spost(S ,P)→ Q}

It may be hard to establish a connection between the set ofgenerated VCs and the source code.



Small example(computes the amount of taxes payable in UK, in 1999)



Using a standard VCGen the result is a single VC, too big andcomplex to be understandable.

((age ≥ 18)→ (((age ≥ 75)→ ((((age ≥ 65) ∧ (income > 16800))→ ((((5980−((income − 16800)/2)) > 4335)→ (((5980− ((income − 16800)/2)) + 2000) > 5750))

∧ ((!((5980− ((income − 16800)/2)) > 4335))→ (4335 > 5750)))) ∧ ((!((age ≥ 65)

∧ (income > 16800)))→ true))) ∧ ((!(age ≥ 75))→ (((age ≥ 65)→ ((((age ≥ 65)

∧ (income > 16800))→ ((((5720− ((income − 16800)/2)) > 4335)→ (((5720−((income − 16800)/2)) + 2000) > 5750)) ∧ ((!((5720− ((income − 16800)/2)) > 4335))

→ (4335 > 5750)))) ∧ ((!((age ≥ 65) ∧ (income > 16800)))→ true))) ∧ ((!(age ≥ 65))

→ ((((age ≥ 65) ∧ (income > 16800))→ ((((4335− ((income − 16800)/2)) > 4335)

→ (((4335− ((income − 16800)/2)) + 2000) > 5750)) ∧ ((!((4335− ((income − 16800)/2))

> 4335))→ (4335 > 5750)))) ∧ ((!((age ≥ 65) ∧ (income > 16800)))→ true)))))))



Developing a Visual Interactive VCGen is important because:

In case one of the VCs is not valid, it facilitates the discoveryof which statements (or execution paths) are leading to theincorrectness of the program.

It allows the combination of backward and forwardpropagation of assertions.


Verification Conditions Generators — a new approach

First step: Combine forward propagation of preconditions andbackward propagation of postconditions

Let S = C1; . . . ; Cn, and 1 ≤ k ≤ n:

VCGk(P, S , Q) = VCsk(S ,P) ∪

{spostk(S ,P)→ wpreck+1(S ,Q)} ∪VC

wk+1(S ,Q)

We can equivalently use any value of k to generate verificationconditions.


Verification Conditions Generators — a new approach

Second step: Allow a closer relation between VCs and error paths

Given a program S , precondition P and postcondition Q, thelabeled control flow graph LCFG (S ,P,Q) of S with respect to(P,Q) is a labeled directed acyclic graph whose edge labels arepairs of logical assertions on program states.


Labeled Control Flow Graph (1)

The basic intuition of LCFG is that for every pair of consecutivecommands Ci , Ci+1 in S , there exists an edge (Ci ,Ci+1) inLCFG (S ,P,Q) whose label consists of an assertion propagatedforward from P and an assertion propagated backward from Q.

If |= VCG(P, S ,Q) then every edge in the graph representing S hasa label (a, b) such that |= a→ b.


Labeled Control Flow Graph (2)


Verification Graphs (1)

The verification graph of a procedure p is the graphLCFG (body(p),pre(p),post(p)).

Let EC(p) (Edge Conditions) be the set of formulas a→ b suchthat (a, b) is the label of an edge in the verification graph of p.Then,

|= VCG(pre(p),body(p),post(p)) iff |= EC(p)


Verification Graphs (2)

The Verification Graph is annotated with assertions from whichdifferent sets can be picked whose validity is sufficient to guaranteethe correctness of the procedure. Each set corresponds to oneparticular verification strategy, mixing the use of sp and wp.

In blocks not containing loops and conditionals, it is equivalent tocheck the validity of any edge condition in the block’s path in theVerification Graph.

Different edge conditions need to be checked, and validity can bepropagated through the graph following a set of rules.


Verification Graphs (3) — Edge Color


Verification Graphs in GamaSlicer


Assertion-based Slicing


Postcondition-based slicing


Postcondition-based slicing

The basic idea is to remove the instructions in the program that donot contribute to the truth of Q in the final state of the program.These commands can be sliced off.

The original algorithm

for j = n + 1, n, . . . , 2

for i = 1, . . . , j − 1

if valid(wpreci (S ,Q)→ wprecj(S ,Q)

)then S ← remove(i , j − 1,S)


Example

A simple sequence of assignments:

x = x + 100x = x + 50x = x − 100

Consider Q = x ≥ 0.


Example

Computing the wp (step 1):

wp1 = x ≥ −50x = x + 100

wp2 = x ≥ 50x = x + 50

wp3 = x ≥ 100x = x − 100

wp4 = x ≥ 0


Example

Next steps: find valid implications among the previous weakestpreconditions computed.

x ≥ −50→ x ≥ 0

x ≥ 50→ x ≥ 0... ...

The condition x ≥ 50→ x ≥ 0 is valid so the instructions in lines 2and 3 can be sliced off.


Example

The resulting program:

Alternatively we have that |= wp3(S ,Q)→ Q.P-slices are not unique. The best slice is the one in which thehighest number of instructions are removed.


Disadvantages

The original quadratic time algorithm is not optimal.For example, in a program with a sequence of 1000 commandssuch that:

The algorithm will give priority to the shorter subsequence. Thissituation will not allow to slice off the longer sequence.


Precondition-based slicing


Precondition-based slicing

The idea is still to remove statements whose presence does notaffect properties of the final state of a program.The difference is that the considered set of executions of theprograms is restricted directly through a first-order condition onthe initial state.


Example

Consider P = x ≥ 0.After computing the sp, one tries to find valid implications amongthe strongest posconditions:

We can slice off instructions in lines 1 and 2 or, alternatively, lines2 and 3.Similarly to postcondition-based slicing, different algorithms can beused. The standard quadratic-time algorithm is not optimal.


Specification-based slicing



A specification-based slice can be computed when both aprecondition P and a postcondition Q are given for a program S .

Definition

Let S be a correct program with respect to the specificationconsisting of precondition P and postcondition Q. The program S ′

is said to be a specification-based slice of S with respect to (P,Q),written S ′ /(P,Q) S, if S ′ � S and S ′ is also correct with respect to(P,Q).



The method proposed by Chung et al to computespecification-based slices is based on the following theorem:

Theorem

The composition, in any order, of precondition-based slicing andpostcondition-based slicing produces a specification-based slice.


Example

The following example shows that this method may fail to removesome instructions.Considering P = true and Q = x ≥ 100, the wp and the sp are:

sp0 = P = true wp1 = truex = x ∗ x

sp1 = ∃v .x = v ∗ v wp2 = x ≥ −50x = x + 100

sp2 = ∃v .x = v ∗ v + 100 wp3 = x ≥ 50x = x + 50

sp3 = ∃v .x = v ∗ v + 150 wp4 = x ≥ 100 = Q


Example

It is obvious that the postcondition is satisfied after execution ofthe instruction in line 2, which means that line 3 can be sliced off.

However, an algorithm based on the theorem will fail in removingthis instruction.


Specification-based slicing — An optimized algorithm

The problem can be solved by using an algorithm that iterates thefollowing basic step:

if valid(sposti (S ,P)→ wprecj(S ,Q)

)then S ← remove(i , j − 1, S)


Example

Considering the previous example and the referred principle, theextraneous instruction in line 3 is removed.


Slice Graphs

1 We construct a Slice Graph by adding to the LCFG edgescorresponding to valid implications found (of the formsposti−1(S ,P)→ wprecj+1(S ,Q));

2 We apply a shortest paths algorithm to find a minimal slice.


Slice Graphs — An example

Interactive Construction of the Slice Graph (1)



Final Slice Graph



Final Sliced Program


Contract-based Slicing


Open/Closed Contract-based Slicing

Given a correct program consisting of a number ofcontract-annotated procedures, how can assertion-based slicing beapplied based on the contracts?

A contract-based slice can be calculated by:

Slicing the code of each individual procedure independentlywith respect to its contract — open slice;

Or taking into consideration the calling contexts of eachprocedure inside a program — closed slice.


Open Contract-based Slice

Given programs Π, Π′, such that |= Verif(Π),we say that Π′ is an open contract-based slice of Π, written Π′ /o Π,if the body of each procedure p ∈ Π′ is a specification-based slice(with respect to its own annotated contract) of that procedure inΠ.


Closed Contract-based Slice

Let Π, Π′ be programs such that |= Verif(Π). Π′ is a closedcontract-based slice of Π, written Π′ /c Π, if |= Verif(Π′) andadditionally for every procedure p ∈ PN(Π)

1 |= preΠ′(p)→ preΠ(p);

2 |= postΠ(p)→ postΠ′(p); and

3 bodyΠ′(p) /(preΠ′ (p),postΠ′ (p)) bodyΠ(p)


Contract-based Slice: General Case

The notion of closed contract-based slicing admits trivial solutions:since all contracts can be weakened, any procedure body can besliced to skip.

A more realistic notion is obtained by fixing a subset of proceduresof the program, whose contracts must be preserved. All othercontracts may be weakened.


Contract-based Slicing algorithm (1)

A contract-based slice of program Π can be calculated by analyzingΠ in order to obtain information about the actual preconditionsand postconditions that are required of each procedure call, andmerging this information together.

This may result in weaker contracts, which can be used to slice theprocedures.


Contract-based Slicing algorithm (2)

To implement this idea for a given program Π we consider apreconditions table Tpre initialized with Tpre [p] = ⊥, and apostconditions table Tpost initialized with Tpost [p] = >.

1 Calculate Verif(Π) and while doing so, for every invocation ofthe form wprec(call p,Q) set Tpost [p] := Tpost [p] ∧ Q.

2 Calculate this set, and while doing so, for every invocation ofthe form sp(call p,P) set Tpre [p] := Tpre [p] ∨ P.


Example (1)

Consider OperationsOverArrays annotated method that performs 5operations: the summation; the summation of the even elements;the iterate product; the maximum and the minimum.


Example (2)

Supposing we call the OperationsOverArrays annotated method to:

1 Compute the average of the elements belonging to the array;


Example (3)

2 Multiply the product of the array by a given parameter y .


Example (4)

Performing the first step of the algorithm, we obtain the followingtable Tpost :

Tpost [OperationsOverArrays] := true && Q1 && Q2

Tpost [Average] := trueTpost [Multiply ] := true

whereQ1 = summ

length == sum{int i in(0:length);a[i ]}length

andQ2 = 0 ≤ i ≤ y && q == i × productum


Example (5)

Performing the second step, with the previous table Tpost weobtain:


Conclusions

Main contributions of this work:

Interactive VC Generation as an alternative approach to verifyprograms: it allows for a closer relation between executionpaths and VCs.

Semantic slicing of programs, rather than thedependency-based:

Flaws in the existing algorithms were detected and solved.New algorithms were proposed for assertion-based slicing.A generalization to the interprocedural level was introducedthrough the concept of contract-based slicing.New application scenarios for assertion-based slicing were alsostudied.


Future Work (1)

Adapting Verification Graphs to work with efficient VCgeneration for passive programs.

Studying how the Verification Graphs can be used to splitverification conditions following the work by Leino et al.

Automating error path discovery.


Future Work (2)

Improving the assertion-based and contract-based slicingalgorithms to use more efficient methods for computing thewp and the sp.

Studying how the passivization techniques present in tools likeBoogie can improve slicing algorithms.

Producing a robust tool for intermediate code of a majorverification platform, such as Boogie of Why.


verification, slicing and visualization of programs with contracts

Education