rigorous software engineering hoare logic and design by...
Post on 28-Jun-2020
2 Views
Preview:
TRANSCRIPT
Rigorous Software EngineeringHoare Logic and Design by Contracts
Simao Melo de Sousa
RELEASE (UBI), LIACC (Porto)Computer Science Department
University of Beira Interior, Portugal
2010-2011
S. Melo de Sousa (DIUBI) Design by Contracts 2010-2011 1 / 46
Outline
1 Introduction
2 Hoare Logic
3 Weakest Precondition Calculus
S. Melo de Sousa (DIUBI) Design by Contracts 2010-2011 2 / 46
Introduction
Table of Contents
1 Introduction
2 Hoare Logic
3 Weakest Precondition Calculus
S. Melo de Sousa (DIUBI) Design by Contracts 2010-2011 3 / 46
Introduction
Floyd-Hoare Logic: Origins
Robert W. Floyd. ”Assigning meaning to programs”’. In Proc. Symp.in Applied Mathematics, volume 19, 1967.
C. A. R. (Tony) Hoare. ”An axiomatic basis for computerprogramming”. Communications of the ACM, 12 (10): 576-585.October 1969.
Edsger W. Dijkstra, ”Guarded command, nondeterminacy and formalderivation of programs”. Communication of the ACM, 18 (8):453-457,August 1975.
S. Melo de Sousa (DIUBI) Design by Contracts 2010-2011 4 / 46
Introduction
Main reference for this lecture
Rigorous Software Development, A Practical Introduction toProgram Specification and Verification by Jose Bacelar Almeida, MariaJoao Frade, Jorge Sousa Pinto, Simao Melo de Sousa. Series:Undergraduate Topics in Computer Science, Springer. 1st Edition., 2011,XIII, 307 p. 52 illus. ISBN: 978-0-85729-017-5.
S. Melo de Sousa (DIUBI) Design by Contracts 2010-2011 5 / 46
Introduction
Logical state vs. programs
Goal
Provide means to prove the correctness and the safety of imperativeprograms.
Notion of state: logical characterization of the set of values that aremanipulated by the program, and their relation.
Principles: consider each component of the analysed program as astate transformer.
=⇒ Each program has a specific logical behaviour that can becharacterized.
S. Melo de Sousa (DIUBI) Design by Contracts 2010-2011 6 / 46
Introduction
Logical state vs. programs
Goal
1 What? description of the task to be performed, of the problem to besolved (the relation between input and output).
2 How? The effective resolution method
3 The resulting Artifact: the program itself, the implementation of thealgorithm
Need: prove that the algorithm (there may be several) and, furthermore,the implementation itself solve the target problem.
Thus: Hoare logic (and subsequent developments): logic, method andframework to establish the adequacy of the behaviour of a program againstits logical specification .
S. Melo de Sousa (DIUBI) Design by Contracts 2010-2011 7 / 46
Introduction
Basic Notion: Hoare Triples
A first Definition
Let be S a program, and P and Q predicates over the variables manipulated by S .
P: pre-condition, Q: post-condition
Informal semantics:
Total: [P] S [Q] - if P holds in a given state and S is executed inthat state, then execution of S will stop, and moreover Q willhold in the final state of execution.
Partial: {P} S {Q} - if P holds in a given state and S is executed inthat state, then either execution of S does not stop, or if itdoes, Q will hold in the final state.
Triples and triples ...
For a given program S , there may be several valid triples.In general we are interested in the triple {P} S {Q} where P is as weak aspossible and Q is as strong as possible.
S. Melo de Sousa (DIUBI) Design by Contracts 2010-2011 8 / 46
Introduction
Some Basics
Examples
{x = 29} x:= x + 1 {x > 20}{x + 1 = 30} x:= x + 1 {x = 30}{x 6= 0} (x<0)?x:=-x:x:=x {x > 0}{m ≤ n} x := (m+n)/2 {m ≤ x ≤ n}
Program Variables and Logic Variables
No triplo {x + 1 = 30}x:= x + 1{x = 30}The variable x from x + 1 = 30 is a logical variable (its value is immutable)
The variable x from x := x + 1 is a program variable (i.e. represents a memory blockwhich contents can be changed)
Thus, the variable x from the pre-condition represents a value that is not the valuerepresented by the variable x from the post-condition: The former represents the contentsof the memory block (represented by the program variable x) before the execution, andthe later its value at the end of its execution.
S. Melo de Sousa (DIUBI) Design by Contracts 2010-2011 9 / 46
Introduction
Some Basics
Examples
{x = 29} x:= x + 1 {x > 20}{x + 1 = 30} x:= x + 1 {x = 30}{x 6= 0} (x<0)?x:=-x:x:=x {x > 0}{m ≤ n} x := (m+n)/2 {m ≤ x ≤ n}
Precise Triples
For a given program S , there are a lot of pairs (P,Q) such that {P} S {Q}. But not all
of them are interesting. The pertinent ones are such that P is as weak as possible and Q
as strong as possible. (A is weaker than B or B is stronger than A, if B =⇒ A )
S. Melo de Sousa (DIUBI) Design by Contracts 2010-2011 10 / 46
Introduction
Simples Examples
Max
{ x ∈ N ∧ y ∈ N ∧ z ∈ N} (x>y)?z:=x:z:=y { (x > y =⇒ z = x)∧(x ≤ y =⇒ z = y)}
or, alternatively{ x ∈ N ∧ y ∈ N ∧ z ∈ N} (x>y)?z:=x:z:=y { (x ≤ z ∧ y ≤ z∧
(∀t ∈ N, (x ≤ t ∧ y ≤ t)
=⇒ z ≤ t)))}
Next even
{ x ∈ N ∧ x = x0} (x mod 2 = 0)?x:=x+2:x:=x+1 { x > x0 ∧ ∀z ∈ N,
(z > x0∧((par z)) =⇒ x ≤ z)}
S. Melo de Sousa (DIUBI) Design by Contracts 2010-2011 11 / 46
Introduction
Product as sums
{a, b ∈ N ∧ b > 0}res:=0; i:= 0; while (i!=b) {i:=i+1; res := res + a}
{res = a× i ∧ i = b}
greatest element
{N ∈ N ∧ N > 0}res:=a[0]; i:=1;
while (i<=N)
{(a[i]>res)?res:=a[i]:skip; i:=i+1;}
{N ∈ N ∧ N > 0 ∧ ∀x ∈ {0 · · ·N}, res ≥ a[x ]}
S. Melo de Sousa (DIUBI) Design by Contracts 2010-2011 12 / 46
Introduction
Design by Contracts
Principles: Hoare triples as Software Contracts
Introduced by Bertrand Meyer for Eiffel, as a systematic approach tospecifying and implementing object-oriented software components
Interaction between these components is based on precisely definedspecifications of their mutual obligations: the contracts
{Ccaller}Component {Ccalled}: The component Component requires from itscaller the respect of the contract Ccaller , in order to ensures that itsexecution, when it ends, delivers the contract Ccalled
Contracts allow
To record details of methods’ responsibilities and assumptions
To document the intended behaviour (specification) of software components
To avoid having to repeatedly check arguments
To assign blame across interfaces
S. Melo de Sousa (DIUBI) Design by Contracts 2010-2011 13 / 46
Introduction
Design by Contracts
Contracts are:
more abstract than code (e.g. sqrt might be implemented using linearsearch, Newton’s method, . . .)
not necessarily checkable (e.g. quantified over infinite types, or just textualstrings . . .)
. . . but in most cases it is possible to automatically generate verificationcondition
(can be) always up-to-date with implementations during development
Contracts avoid performing time-consuming defensive checks insideproduction code
dynamic assertion checking can be automatically generated by a specialcompiler and turned off at any point
S. Melo de Sousa (DIUBI) Design by Contracts 2010-2011 14 / 46
Introduction
Design by Contracts
Modularity of Reasoning
As far as verification is concerned: a program is fully verified if eachannotated component is individually and successfully verified
In order to understand this code it suffices to
read the methods’ contractsinstead of looking at ”all” the code.
Other features
Refine design by refining contracts
Reverse DBC can be used to understand, document, improve, and maintainan existing code base
Evaluate system quality
through rigorous testing (specification-driven)or, through the formal verification of key subsystems
S. Melo de Sousa (DIUBI) Design by Contracts 2010-2011 15 / 46
Introduction
Design by Contracts
DbC =⇒ Annotating Program Components
Components = class, methods, modules, functions, . . .
Kinds of contracts:
safety
array index or rangeoverflow (buffer,integer, . . .)pointer (null pointerdeferencing)
Functional requirements
Frame conditions
Concurrency and timingbehaviour
Abrupt and exceptionalbehaviour
static properties(invariants)
classmoduleloops
S. Melo de Sousa (DIUBI) Design by Contracts 2010-2011 16 / 46
Introduction
Design by Contracts
What can be done with the contracts?
Static analysis
Proof based verification:
Model CheckingSMT, theorem provers,Proof assistants
Runtime checks
Test generation based on contracts
Designing contracts?
The source code can be obtained by traditional software engineering processes.
The annotation can be manually introduced, or derived from protection profiles, orsystematically derived from a requirement analysis.
S. Melo de Sousa (DIUBI) Design by Contracts 2010-2011 17 / 46
Introduction
Design by Contracts
Tools or platforms. Examples:
Algorithm Why, Dafny
C: (ACSL), Frama-C, VCC, Havoc
Java: (JML), LOOP tool, ESC/JAVA, Krakatoa, Key Tools, Bandera, Jive,Jack etc...
C]: Spec], code contracts
ADA: Spark, RavenSpark
S. Melo de Sousa (DIUBI) Design by Contracts 2010-2011 18 / 46
Introduction
This lecture
Our point of view: Program Verification.
Hoare Logic is at the core of the deductive approach of the DbC.
An overview of the (classical) foundation of the Hoare Logic and itsalgorithmic counterpart.
For a small language. Unfortunately, realistic feature are out of scopein this short introduction.
S. Melo de Sousa (DIUBI) Design by Contracts 2010-2011 19 / 46
Hoare Logic
Table of Contents
1 Introduction
2 Hoare Logic
3 Weakest Precondition Calculus
S. Melo de Sousa (DIUBI) Design by Contracts 2010-2011 20 / 46
Hoare Logic
The While language
Two base types τ ::= bool | intPhrase types θ ::= Expτ | Comm | Term | AssertExpint 3 e ::= . . . | −1 | 0 | 1 | . . . | x
| −e | e + e | e − e | e ∗ e | e div e | e mod e
Expbool 3 b ::= true | false | !b | b && b | b ‖ b| e == e | e < e | e <= e | e > e | e >= e | e ! = e
Comm 3 C ::= skip | C ; C | x := e | if b then C else C || while b do {A}C(We may use the short notation (b)?C : C(for simple conditionals)
Term 3 t ::= . . . | −1 | 0 | 1 | . . . | x| −t | t + t | t − t | t ∗ t | t div t | t mod t| f (t1, . . . , tα(f ))
Assert 3 A ::= true | false | !A | A && A | A ‖ A| A → A | Forall x . A | Exists x .A| t == t | t < t | t <= t | t > t | t >= t | t ! = t| p(t1, . . . , tα(p))
S. Melo de Sousa (DIUBI) Design by Contracts 2010-2011 21 / 46
Hoare Logic
First approach: the While language
Operational Semantics
program state = a function s ∈ Σ that maps program variables into their currentvalues
Σ = V → Z[[·]]Expint
: Expint → Σ→ Z[[·]]Expbool
: Expbool → Σ→ {true, false}
Expressions are interpreted as functions from states to the corresponding domainof interpretation
Operators have the obvious interpretation
For our first approach:
expression: side effect freeexpression evaluation is total: for every state, expression evaluationdoes not go wrong
S. Melo de Sousa (DIUBI) Design by Contracts 2010-2011 22 / 46
Hoare Logic
First approach: the While language
Natural style operational semantics
• Evaluation relation: ⇓ ⊆ Comm× Σ× Σ.• (C , s) ⇓ s ′ = if C is executed in the initial state s then its execution will terminate,and the final state will be s ′.
if C = skip then (C , s) ⇓ s
if C = x := e then (C , s) ⇓ s[x : [[e]](s)]
if C = C1 ; C2 , (C1, s) ⇓ s ′, and (C2, s′) ⇓ s ′′, then (C , s) ⇓ s ′′
if C = if b then Ct else Cf then there are two cases:
if [[b]](s) = true and (Ct , s) ⇓ st , then (C , s) ⇓ stif [[b]](s) = false and (Cf , s) ⇓ sf , then (C , s) ⇓ sf
if C = while b do {I}C then there are two cases:
if [[b]](s) = true, (C , s) ⇓ s ′, and (while b do {I}C , s ′) ⇓ s ′′, then(C , s) ⇓ s ′′
if [[b]](s) = false then (C , s) ⇓ s
S. Melo de Sousa (DIUBI) Design by Contracts 2010-2011 23 / 46
Hoare Logic
A simple example
C = if x > 0 then x := 2 ∗ x ; while x < 10 do {x <= 10} x := 2 ∗ x else skip
⇓
(C , {x 7→ 10}) ⇓ {x 7→ 20}
S. Melo de Sousa (DIUBI) Design by Contracts 2010-2011 24 / 46
Hoare Logic
Evaluation of terms and interpretation of assertions
[[·]]Term : Term→ Σ→ Z[[·]]Assert : Assert→ Σ→ {true, false}
Terms are interpreted very similarly to (program) integer expressions (but functionsremain uninterpreted)Assertions are interpreted similarly to (program) boolean expressions (but predicatesremain uninterpreted)
I (+) = +I (−) = −I (∗) = ×
I ( div ) = ÷I ( mod ) = modI (==) = =I ( ! =) = 6=I (<) = <
I (<=) = ≤I (>) = >
I (>=) = ≥
[[c]](s) = c[[x]](s) = s(x)
[[−e]](s) = −[[e]](s)[[e1�e2]](s) = [[e1]](s) � [[e2]](s), where � = I (�)
[[true]](s) = true[[false]](s) = false
[[e1�e2]](s) = [[e1]](s) � [[e2]](s), where � = I (�)[[ !A]](s) = ¬[[A]](s)
[[A1 && A2]](s) = [[A1]](s) ∧ [[A2]](s),[[A1 ‖ A2]](s) = [[A1]](s) ∨ [[A2]](s),
[[A1 → A2]](s) = [[A1]](s) =⇒ [[A2]](s),[[Forall x . A]](s) = ∀v ∈ Z. [[A]](s[x 7→ v ]), with v fresh[[Exists x .A]](s) = ∃v ∈ Z. [[A]](s[x 7→ v ]), with v fresh
S. Melo de Sousa (DIUBI) Design by Contracts 2010-2011 25 / 46
Hoare Logic
Validity
Let consider a model (Z, I ), where I is the interpretation function thatmaps constants to their obvious interpretations as integer numbers,and maps functions and predicates to the corresponding arithmeticfunctions and comparison predicates (see Logic lectures!)
Let A be an assertion and M be a set of assertions. In the context of(Z, I ):
A valid, written |= A if [[A]](s) = true for all states s ∈ Σ.M valid, written |=M if |= A holds for every A ∈M.
We assume the existence of external means for checking validity ofassertions
These tools should allow us to define theories, i.e. to write axiomsconcerning the behaviour of the uninterpreted functions and predicates
S. Melo de Sousa (DIUBI) Design by Contracts 2010-2011 26 / 46
Hoare Logic
Specification and Hoare Triples
Spec 3 S ::= {A}C {A} | [A] C [A]
[[·]]Spec : Spec→ {true, false}
[[{P}C {Q}]] = ∀s, s ′ ∈ Σ. [[P]](s) ∧ (C , s) ⇓ s ′ =⇒ [[Q]](s ′)
[[[P] C [Q]]] = ∀s ∈ Σ. [[P]](s) =⇒ (∃s ′ ∈ Σ.(C , s) ⇓ s ′ ∧ [[Q]](s ′))
S. Melo de Sousa (DIUBI) Design by Contracts 2010-2011 27 / 46
Hoare Logic
The case for loops
while (b) do C ≡ if b then C else skip; while (b) do C
Loop invariants
Any property whose validity is preserved by executions of the loop’s body.
Since these executions may only take place when the loop condition is true,an invariant of the loop while (b) do C is any assertion I such that{I && b}C {I} is valid, in which case, of course, it also holds that{I}while (b) do C {I} is valid
The validity of [I && b]C [I ] does not however imply the validity of[I ] while (b) do C [I ]. Proving such a total correctness specification impliesproving the termination of the loop
The required notion here is a quantitative one: a loop variant is any positiveinteger expression that is strictly decreasing from iteration to iteration.
The existence of a valid variant for a given loop implies the termination ofall possible executions of the loop
S. Melo de Sousa (DIUBI) Design by Contracts 2010-2011 28 / 46
Hoare Logic
Axioms and Rules of Hoare Logic
(skip){P} skip {P}
(assign){Q[x 7→ e]} x := e {Q}
(seq){P}C1 {R} {R}C2 {Q}
{P}C1 ; C2 {Q}
(while){I && b}C {I}
{I}while b do {I}C {I && !b}
(if ){P && b}Ct {Q} {P && !b}Cf {Q}
{P} if b then Ct else Cf {Q}
(conseq){P}C {Q}
if |= P′ → P and |= Q → Q′
{P′}C {Q′}
(whilewf )[I && b && V == n]C [I && V < n] I && B −→ V >= 0
[I ] while b do {I}C [I && !b]
S. Melo de Sousa (DIUBI) Design by Contracts 2010-2011 29 / 46
Hoare Logic
Derivability in HL denoted by `
Soundness of Hoare logic
If ` {P}C {Q}, then [[{P}C {Q}]] = true.
Proof.By induction on the derivation of ` {P}C {Q}. For the while case we alsoproceed by induction on the definition of the evaluation relation.
S. Melo de Sousa (DIUBI) Design by Contracts 2010-2011 30 / 46
Hoare Logic
{x >= −100 && x <= 100}if x < 0 then x = x + 100 else skip ; y = 2 ∗ x{y >= 0 && y <= 300}
(seq)
1 {x >= −100 && x <= 100} if x < 0 then x = x + 100 else skip {x >=0 && x <= 150} (if)1.1 {x >= −100 && x <= 100 && x < 0} x = x + 100 {x >=
0 && x <= 150} (conseq)1.1.1. {x >= −100 && x <= 50} x = x + 100 {x >= 0 && x <= 150}
(assign)1.2. {x >= −100 && x <= 100 && !(x < 0)} skip {x >= 0 && x <=
150} (conseq)1.2.1. {x >= 0 && x <= 150} skip {x >= 0 && x <= 150} (skip)
2 {x >= 0 && x <= 150} y = 2 ∗ x {y >= 0 && y <= 300} (assign)
Side condition to be proved (straightforwardly)
1.1. |= x >= −100 && x <= 100 && x < 0 → x >= −100 && x <= 50 and|= x >= 0 && x <= 150 → x >= 0 && x <= 150
1.2. |= x >= −100 && x <= 100 && !(x < 0) → x >= 0 && x <= 150 and|= x >= 0 && x <= 150 → x >= 0 && x <= 150
S. Melo de Sousa (DIUBI) Design by Contracts 2010-2011 31 / 46
Weakest Precondition Calculus
Table of Contents
1 Introduction
2 Hoare Logic
3 Weakest Precondition Calculus
S. Melo de Sousa (DIUBI) Design by Contracts 2010-2011 32 / 46
Weakest Precondition Calculus
But...
Two desirable properties for backward proof construction are missing:
Sub-formula propertyUnambiguous choice of rule
The consequence rule causes ambiguity. Its presence is howevernecessary to make possible the application of rules for skip,assignment, and while
An alternative is to distribute the side conditions among the differentrules
S. Melo de Sousa (DIUBI) Design by Contracts 2010-2011 33 / 46
Weakest Precondition Calculus
Goal directed version of HL
Axioms and Rules of Hoare Logic
if |= P → Q{P} skip {Q}
if |= P → Q[e/x ]{P} x := e {Q}
{P}C1 {R} {R}C2 {Q}
{P}C1 ; C2 {Q}
{I && b}C {I}if |= P → I and |= I && !b → Q
{P}while b do {I}C {Q}
{P && b}Ct {Q} {P && !b}Cf {Q}
{P} if b then Ct else Cf {Q}
S. Melo de Sousa (DIUBI) Design by Contracts 2010-2011 34 / 46
Weakest Precondition Calculus
Goal directed Version of HL
Derivability in goal oriented HL denoted by `g
soundness properties
If `g {P}C {Q} and both |= P ′ → P and |= Q → Q ′ hold, then`g {P ′}C {Q ′}.(Proof. By induction on the derivation of `g {P}C {Q}).
For any program C and assertions P, Q,`g {P}C {Q} iff` {P}C {Q}.
S. Melo de Sousa (DIUBI) Design by Contracts 2010-2011 35 / 46
Weakest Precondition Calculus
But...
The seq rule
In the goal directed strategy, one has still to guess the intermediary assertion inthe seq rule
A strategy for proofs
Focus on the command and postcondition; guess an appropriate precondition
In the sequence rule, we obtain the intermediate condition from thepostcondition of the second command
We do this by always choosing the weakest precondition (for the givenpostcondition)
i.e., in rules for skip, assignment, and while, the precondition is determinedby looking at the side condition and choosing the weakest condition thatsatisfies it
A note: the dual approach (forwardly, from pre-conditions topost-conditions) is also possible.
S. Melo de Sousa (DIUBI) Design by Contracts 2010-2011 36 / 46
Weakest Precondition Calculus
Mechanization: Program Verification Architecture
How can a proof tool be used for verifying programs with Hoare Logicusing the Weakest Preconditions strategy? Two possibilities:
Encode Hoare Logic directly in proof tool and reason about programconstructs
Two-phase architecture:
use Hoare Logic to construct a set of verification conditionsuse a general-purpose proof tool to discharge verification conditions
Second approach is much more flexible
S. Melo de Sousa (DIUBI) Design by Contracts 2010-2011 37 / 46
Weakest Precondition Calculus
Verification Conditions
VCs are purely first-order, not containing program constructs.
Can be checked / discharged using any standard proof tool (theoremprover or proof assistant) with support for the data types of thelanguage.
Modifications in the language are only reflected in the firstcomponent, not in the proof tool
Moreover it is possible to use a multi-prover approach
S. Melo de Sousa (DIUBI) Design by Contracts 2010-2011 38 / 46
Weakest Precondition Calculus
Two-phase Architecture
1 Given a Hoare triple {P}C {Q}, we mechanically produce aderivation with P C Q as conclusion, assuming that all its sideconditions are valid.
2 Each side condition of the form |= A → B generated in step 1 mustnow be checked. To that effect the first-order formula A → B isexported to a proof tool. Such a formula is called a verificationcondition (VC).
3 If all verification conditions can be proved by a sound proof tool, then{P}C {Q} is a valid Hoare triple. If at least one condition is shownnot to be valid, then this is evidence that the triple is also not valid.
S. Melo de Sousa (DIUBI) Design by Contracts 2010-2011 39 / 46
Weakest Precondition Calculus
Some notes on this architecture
Note that the HL proof tree can always be constructed (explicitly orvirtually)
But the VCs may not all be dischargeable: automatic prover may beable to find a counter-example... or interactive proof may not succeed
What does it mean when at least one VC is not valid?(the verificationof the program has failed) =⇒ Errors in program, specification, orannotations
S. Melo de Sousa (DIUBI) Design by Contracts 2010-2011 40 / 46
Weakest Precondition Calculus
General Architecture of a Program Verification System
S. Melo de Sousa (DIUBI) Design by Contracts 2010-2011 41 / 46
Weakest Precondition Calculus
An Architecture for Verification
Our next step is then to mechanize the construction of a derivation,following the WP strategy.
The result will be an algorithm (called a Verification ConditionsGenerator, VCGen) that does not even explicitly construct the prooftree; it just outputs the set of verification conditions
S. Melo de Sousa (DIUBI) Design by Contracts 2010-2011 42 / 46
Weakest Precondition Calculus
Weakest Preconditions Mechanized
Principles
{P}C {Q} Given program C and a postcondition Q, we can calculatean assertion wp (C ,Q) such that {wp (C ,Q)}C {Q} is valid
and moreoverif {P}C {Q} is valid for some P then P is stronger than wp (C ,Q)(i.e. P → wp (C ,Q)).
Thus wp (C ,Q) is the weakest precondition that grants the truth ofpostcondition Q after execution of C .
S. Melo de Sousa (DIUBI) Design by Contracts 2010-2011 43 / 46
Weakest Precondition Calculus
VCGen algorithm
wp (skip,Q) = Q
wp (x := e,Q) = Q[e/x]
wp (C1;C2,Q) = wp (C1,wp (C2,Q))
wp (if b then Ct else Cf ,Q) = (b → wp (Ct ,Q)) && ( !b → wp (Cf ,Q))
wp (while b do {I}C ,Q) = I
VC(skip,Q) = ∅
VC(x := e,Q) = ∅
VC(C1;C2,Q) = VC(C1,wp (C2,Q)) ∪ VC(C2,Q)
VC(if b then Ct else Cf ,Q) = VC(Ct ,Q) ∪ VC(Cf ,Q)
VC(while b do {I}C ,Q) = {(I && b) → wp (C , I ), (I && !b) → Q}∪ VC(C , I )
VCG({P}C {Q}) = {P → wp (C ,Q)} ∪ VC(C ,Q)
S. Melo de Sousa (DIUBI) Design by Contracts 2010-2011 44 / 46
Weakest Precondition Calculus
VCGen algorithm
Soundness of VCGen
Let C ∈ Comm and P,Q ∈ Assert such that |= VCG({P}C {Q}).Then `g {P}C {Q}Proof.It suffices to prove that there exists a derivation in the goal directed HLthat has as side conditions exactly the set given by VCG({P}C {Q}).
S. Melo de Sousa (DIUBI) Design by Contracts 2010-2011 45 / 46
Weakest Precondition Calculus
An example
Consider
fact.
=f := 1 ; i := 1 ;while i <= n do {f == fact(i − 1) && i <= n + 1}
f := f ∗ i ;i := i + 1
The universal closures of
VCG({n >= 0} fact {f == fact(n)})are
1 Forall n. (n >= 0 → 1 == fact(1− 1) && 1 <= n + 1)
2 Forall i , n. (f == fact(i − 1) && i <= n + 1 && i <= n→ f ∗ i == fact(i + 1− 1) && i + 1 <= n + 1)
3 Forall i , f , n. (f == fact(i − 1) && i <= n + 1 && i > n → f == fact(n))
S. Melo de Sousa (DIUBI) Design by Contracts 2010-2011 46 / 46
top related