Verification, Slicing and Visualization of Programs with Contracts

Veriﬁcation, Slicing and Visualization of Programs
with Contracts

Daniela da Cruz
Supervisors: Pedro Rangel Henriques, Jorge Sousa Pinto

Departamento de Inform´tica
a
Universidade do Minho

PhD examination

October 21, 2011

Daniela da Cruz Veriﬁcation, Slicing and Visualization of Programs with Contracts

Context

On one hand, Slicing plays an important role in focusing the
comprehension of a program just on a relevant part of it, with
respect to a given criterion.

On the other hand, concerning software development, the Design
by Contract (DbC) approach has allowed for the application of
formal methods at the code level.


Motivation

1 Traditional syntactic slicing, applied a priori, may facilitate
the verification of large programs;
2 It makes sense to slice programs based on semantic, rather
than syntactic, criteria. Contracts may be excellent candidates
for such criteria;
3 This kind of semantic slicing may also be helpful in the
verification of component-based programs.
The goal of this thesis is to explore the interplay between slicing
and program verification, as well as the visual animation of both
activities.


Outline


Interactive Veriﬁcation Conditions Generator


Veriﬁcation Conditions Generators (1)

The usual way to verify the correctness of a program is through the
use of Veriﬁcation 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 of
generated 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 and
complex 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 discovery
of which statements (or execution paths) are leading to the
incorrectness of the program.
It allows the combination of backward and forward
propagation of assertions.


Veriﬁcation Conditions Generators — a new approach

First step: Combine forward propagation of preconditions and
backward propagation of postconditions
Let S = C1 ; . . . ; Cn , and 1 ≤ k ≤ n:
s
VCGk (P, S, Q) = VCk (S, P) ∪
{spostk (S, P) → wpreck+1 (S, Q)} ∪
w
VCk+1 (S, Q)

We can equivalently use any value of k to generate veriﬁcation
conditions.


Veriﬁcation 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, the
labeled control ﬂow graph LCFG (S, P, Q) of S with respect to
(P, Q) is a labeled directed acyclic graph whose edge labels are
pairs of logical assertions on program states.


Labeled Control Flow Graph (1)

The basic intuition of LCFG is that for every pair of consecutive
commands Ci , Ci+1 in S, there exists an edge (Ci , Ci+1 ) in
LCFG (S, P, Q) whose label consists of an assertion propagated
forward from P and an assertion propagated backward from Q.
If |= VCG(P, S, Q) then every edge in the graph representing S has
a label (a, b) such that |= a → b.


Labeled Control Flow Graph (2)


Verification Graphs (1)

The verification graph of a procedure p is the graph
LCFG (body(p), pre(p), post(p)).
Let EC(p) (Edge Conditions) be the set of formulas a → b such
that (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 which
different sets can be picked whose validity is sufficient to guarantee
the correctness of the procedure. Each set corresponds to one
particular verification strategy, mixing the use of sp and wp.
In blocks not containing loops and conditionals, it is equivalent to
check the validity of any edge condition in the block’s path in the
Verification Graph.

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


Veriﬁcation Graphs (3) — Edge Color


Veriﬁcation Graphs in GamaSlicer


Assertion-based Slicing


Postcondition-based slicing


Postcondition-based slicing

The basic idea is to remove the instructions in the program that do
not contribute to the truth of Q in the ﬁnal state of the program.
These commands can be sliced oﬀ.
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 + 100
x = x + 50
x = x − 100

Consider Q = x ≥ 0.


Example

Computing the wp (step 1):

wp1 = x ≥ −50
x = x + 100
wp2 = x ≥ 50
x = x + 50
wp3 = x ≥ 100
x = x − 100
wp4 = x ≥ 0


Example

Next steps: ﬁnd valid implications among the previous weakest
preconditions computed.

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

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


Example

The resulting program:

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


Disadvantages

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

The algorithm will give priority to the shorter subsequence. This
situation will not allow to slice oﬀ the longer sequence.


Precondition-based slicing


Precondition-based slicing

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


Example

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

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


Speciﬁcation-based slicing



A specification-based slice can be computed when both a
precondition P and a postcondition Q are given for a program S.
Definition
Let S be a correct program with respect to the specification
consisting 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 compute
speciﬁcation-based slices is based on the following theorem:
Theorem
The composition, in any order, of precondition-based slicing and
postcondition-based slicing produces a speciﬁcation-based slice.


Example

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

sp0 = P = true wp1 = true
x =x ∗x
sp1 = ∃v .x = v ∗ v wp2 = x ≥ −50
x = x + 100
sp2 = ∃v .x = v ∗ v + 100 wp3 = x ≥ 50
x = x + 50
sp3 = ∃v .x = v ∗ v + 150 wp4 = x ≥ 100 = Q


Example

It is obvious that the postcondition is satisﬁed after execution of
the instruction in line 2, which means that line 3 can be sliced oﬀ.

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


Speciﬁcation-based slicing — An optimized algorithm

The problem can be solved by using an algorithm that iterates the
following 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, the
extraneous instruction in line 3 is removed.


Slice Graphs

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

2 We apply a shortest paths algorithm to ﬁnd 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 of
contract-annotated procedures, how can assertion-based slicing be
applied based on the contracts?
A contract-based slice can be calculated by:
Slicing the code of each individual procedure independently
with respect to its contract — open slice;
Or taking into consideration the calling contexts of each
procedure 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 speciﬁcation-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 closed
contract-based slice of Π, written Π c Π, if |= Verif(Π ) and
additionally 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 be
sliced to skip.
A more realistic notion is obtained by ﬁxing a subset of procedures
of the program, whose contracts must be preserved. All other
contracts 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 preconditions
and postconditions that are required of each procedure call, and
merging this information together.
This may result in weaker contracts, which can be used to slice the
procedures.


Contract-based Slicing algorithm (2)

To implement this idea for a given program Π we consider a
preconditions table Tpre initialized with Tpre [p] = ⊥, and a
postconditions table Tpost initialized with Tpost [p] = .
1 Calculate Verif(Π) and while doing so, for every invocation of
the form wprec(call p, Q) set Tpost [p] := Tpost [p] ∧ Q.
2 Calculate this set, and while doing so, for every invocation of
the form sp(call p, P) set Tpre [p] := Tpre [p] ∨ P.


Example (1)

Consider OperationsOverArrays annotated method that performs 5
operations: 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 ﬁrst step of the algorithm, we obtain the following
table Tpost :

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

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

and
Q2 = 0 ≤ i ≤ y && q == i × productum


Example (5)
Performing the second step, with the previous table Tpost we
obtain:


Conclusions

Main contributions of this work:
Interactive VC Generation as an alternative approach to verify
programs: it allows for a closer relation between execution
paths and VCs.
Semantic slicing of programs, rather than the
dependency-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 introduced
through the concept of contract-based slicing.
New application scenarios for assertion-based slicing were also
studied.


Future Work (1)

Adapting Verification Graphs to work with efficient VC
generation for passive programs.
Studying how the Verification Graphs can be used to split
verification conditions following the work by Leino et al.
Automating error path discovery.


Future Work (2)

Improving the assertion-based and contract-based slicing
algorithms to use more eﬃcient methods for computing the
wp and the sp.
Studying how the passivization techniques present in tools like
Boogie can improve slicing algorithms.
Producing a robust tool for intermediate code of a major
veriﬁcation platform, such as Boogie of Why.


Verification, Slicing and Visualization of Programs with Contracts

More Related Content

Viewers also liked

Similar to Verification, Slicing and Visualization of Programs with Contracts

Recently uploaded

Verification, Slicing and Visualization of Programs with Contracts