verification as a matter of course

Bertrand MeyerETH Zurich, Eiffel Software & ITMO

With Cristiano Calcagno, Carlo Furia, Alexander Kogtenkov*, Martin Nordio, Manuel Oriol+, Yu Pei, Nadia Polikarpova, Emmanuel

Stapf*, Julian Tschannen, Stephan van Staden, Yi Wei, Andreas Zeller# & others

*Eiffel Software+ETH, then U. of York, now ABB

#U. Saarbrücken

Draft notes, LASER Summer School, Procchio (Elba), September 2011

VerificationAs a Matter Of Course

Contents

1.The goal: trusted components

2.The EVE environment

3.Technical developments: 3.1 Towards full contracts 3.2 Negative variables & the essence of

object-oriented programming 3.3 Language convention for frames 3.4 The alias calculus 3.5 A Calculus of Object Programs

4.Conclusion and assessmentNot included:

concurrency 2

- 1 -Scope & Goals

3

Three forms of software development

1. Casual

2. Professional

3. Critical

Simple Web sites, spreadsheets, …

Enterprise computing, simulation, “soft” real-time, …

Transportation, critical infrastructure, “hard” real-time, …

Enterprise computing, simulation, “soft” real-time, …

4

Language techniques for professional development

Dynamic allocation Classes,

objects

Exception handling Closures

(agents)Exceptions

Genericity

InheritancePolymorphism,

dynamic binding

...

5

Research context (1): method and language

Our work is based on Eiffel: Method and language for quality-focused

development For professional systems, including very large ones Continuous, seamless development ISO standard, significant user base and code base Libraries Excellent development environment: EiffelStudio

Some advantages: Built-in, deeply ingrained use of contracts:

preconditions, postconditions, class invariants Open-source, no patent or other proprietary issues We can shape the future method, language and IDE

Java is not a Law of Nature 6

- 2 -The EVE

environment7

Research context (2): EVE

Eiffel Verification Environment

Open source

Developed at ETH, others’ contributions welcome

Continuous integration (weekly) with EiffelStudio

The platform for trying new ideas

All ETH and ITMO contributions included8

Verification As a Matter Of Course

Arbiter

AutoProof

Aliasanalysis

AutoFix

Test case generation

EVE Test executio

n

Test results

Inter.prover

Sep. logic

prover

AutoTest

Invariantinferenc

e

Invariantinferenc

e

Suggestions

Suggestions

9

Scores

Failed test: score = -1

Successful test run: 0 < score <= 0.9

Correctness proof: score = 1May be scaled down if some aspects not takeninto account, e.g. arithmetic overflow

In practice (AutoProof): Successful proof: score = 1 Out-of-memory, timeout: score = 0 Failed proof with abstract trace: score = -1

Carlo Furia, Julian Tschannen, Martin Nordio

10

Demo

11

Combining static and dynamic techniquesStatic verification:

+ More modular + Scales up better - Not always feasible - Often tests idealized version of the software - Captures only specified properties

Testing: + Generally possible + Can be automated + Tests software as it is + Can integrate non-software parts - Partial (very!) - Captures only specified properties - Not always feasible

12

Testing

To test a software system is to try to make it fail

Fiodor Chaliapineas Mephistopheles

“Ich bin der Geist, der stets verneint”

Goethe, Faust, Act I

13

AutoTest

(e.g. IEEE Computer, Sep. 2009)Integral part of EiffelStudio

Has already uncovered hundreds of bugs in libraries and other software

Three components:

Test generation Test extraction (from failures) Manual tests

Ilinca CiupaAndreas Leitner

Yi WeiEmmanuel Stapf

Arno FivaManuel Oriol…

14

AutoTest: Test generation

Input: set of classes Generates instances, calls routines with

automaticallyselected arguments

Oracles are contracts: Direct precondition violation: skip

(precondition satisfaction techniques minimize this)

Postcondition/invariant violation: bug found Any test (manual or automated) that fails becomes

part of the test suite

15

16

Maurice Maeterlinck, La Vie des Abeilles, 1901

AutoTest: Test generation

*SET**

+SET1

+SET2

+ +

Test:s1, s2 : SETs2 s1

*: Deferred +: Effective

Bernd Schoeller

18

AutoTest: Test extraction

Turn a failed execution into a test case

19

Who finds what faults?

On a small EiffelBase subset,we compared:

AutoTest Manual testing (students) (3 classes, 2 with bugs

seeded) User reports from the field

Largely separate kinds of faults

AutoTest: 62% specification, 38% implementationUser reports: 36% specification, 64% implementation

I.Ciupa, A. Leitner,M.Oriol, A. Pretschner

ICST 2008 (best paper)

20

CITADEL: Daikon for Eiffel

How do programmer-written and inferred contracts compare?Can contract inference be used to improve the quality of programmer-written contracts?

Nadia PolikarpovaIlinca CiupaISSTA 2009

21

CITADEL results

A high proportion of inferred contract clauses are correct (90%) and relevant (64%)

Contract inference does not find all programmer-written contracts (only 59%)

Programmers do not write all inferred contracts (25%)

Contract inference can strengthen programmer-written postconditions and invariants and find missing precondition clauses

22

AutoFix: programs that fix themselves

16 faults fixed out of 42

Some of the fixes are exactly the same as those proposed

by professional programmers

Passing & failing test cases

Difference

Fix to minimize the difference

Yi Wei, Yu Pei, Andreas Zeller, ISSTA 2010Yi Wei, Yu Pei, Carlo Furia, ASE 2011 (etc.)

23

- 3.1 -Towardscompletecontracts

24

Typical contract: list insertion

put_right (v: G) -- Insert v to the right of cursor require index <= count ensure i_th (index + 1) = v count = old count + 1 index = old index

end

count1

v

-- Previous elements unchanged!

index

25

Complete contracts

Contracts are typically incomplete(unlike those of fully formal approaches such as Z)

Our solution: Use models

A model is a mathematical interpretation of the structures

Model library: MML (Mathematical Model Library)Fully applicative (no side effects, attributes, assignment etc.)But: expressed in Eiffel (preserving executability)

Bernd Schoeller, Tobias Widmer (2008)

Nadia Polikarpova (VSTTE 2010)

26

Typical contract: list insertion

put_right (v: G) -- Insert v to the right of cursor require index <= count ensure i_th (index + 1) = v count = old count + 1 index = old index

end

count1

v

-- Previous elements unchanged!

index

27

List insertion with model-based contractnote model: sequence, indexclass LIST [G] ...

sequence: MML_SEQUENCE [G]put_right (v: G)

-- Insert v to the right of cursor. require index <= sequence.count ensure sequence =

old (sequence.front (index).extended (x) + sequence.tail (index + 1)) index = old index end

...28

Model-based contracts: applications

On 7 of the most popular EiffelBase classesTesting found 4 “functional” faults by violation of

model-based contracts

EiffelBase2: a data structures library with full contracts Aim is to prove the code against these contracts

Now in progress: specifying application libraries (graphics, networking...)

29

- 3.2 -Negative Variables

& the Essenceof Object-Oriented

Programming30

O-O analysis, design & programming

“Principle of general relativity”: every operation in a class is expressed relative to a “current object” (self, this, Current), known only at execution time

class C featurer

dox := 1

x . f (...)end

...end

Need to model this property in the logic31

Simplified denotational rule for routines (unqualified call)

(call r (c)) (s) = r (s [r : c])

Notations: r: body of r r : list of formal arguments of r F [v :e] : Substitution of v for e in F

(for variable v and expression e; generalized to

vectors of variables and expressions) Distributed dot (used next), for a list v = <u, v, w,

…>: x v = <x u, x v, x v, …> 32

Classic axiomatic rule for routines

(Ignoring recursion)

{P} r {Q}

{P [r : c]} call r (c) {Q [r

: c]}

33

Tentative rule for qualified (O-O) calls

(Inadequate!)

{P and INV} r {Q and INV}

{x P [r : c]} call x r (c) {x Q [r

: c]}

Standard solution (e.g. Peter Müller’s thesis): in r, replace all occurrences of an attribute a by Current.a

34

Object-oriented calls

call x r (c)

xx’

Current

Target object

Negative variables:

y

Known by the target as x’ y

x Current = x Current x = x x’ x = Current x x’ = Current Current’ = Current 35

Denotational rule for calls

Unqualified calls:(call r (c)) (s) = r (s [r : c])

Qualified calls:(call x r (c)) (s) = x call r (x’ c) (s)

Then for any property P (such that “” distributes over P):

P (call x r (c)) = x P (call r (x’ c))

= x r (s [r : x’

c])

= x (P ( r) [r : x’ c])

36

Adequate Hoare rule for qualified calls

Reminder: inadequate rule


{x P [r : x’ c]} call x r (c) {x Q [r

: x’ c]}


{x P [r : c]} call x r (c) {x Q [r

: c]}

Proper rule

37

- 3.3 -Framing:

a language convention

38

The frame issue:

In a class ACCOUNT:deposit (sum: INTEGER)

require ...do...ensure

balance = old balance + sumend

What about other queries other than balance, e.g.

owner, account_number, overdraft_limit...?

What about descendant classes, e.g. MAFIA_ACCOUNT?

Specifying what does not change

39

“Modifies” clauses

ESC-Java, JML, Spec#: specify what a command can changeTheoretical problems:

This can be an infinite set Requires careful design for inheritance

Practical problem: tedious to express

Pragmatic observation from survey of JML code: Every item listed in a modifies clause also

appears in the postcondition!

40

The proposed language convention

A routine may only modify queries listed (outside of an old expression) in its postcondition

deposit (sum: INTEGER )require ...do...ensure

balance = old balance + sum

end

This also avoids introducing a special language notation to express that a routine is pure

has_penalty = (cur /= currency)

; cur: CURRENCY

oldinvolved

(is_overdraft)

41

- 3.4 -The Alias Calculus

42

The question asked by the Alias Calculus

Given expressions e and f, and a program location p :

Can e and f ever be attached to the same object at p ?

Broy volume (IJSI, 2011)

43

An example

y

x

44

Why is this important?

Alias analysis can be a key tool for proving O-O programs (as an alternative to separation logic)

45

Applications of alias analysis

1. Without it, cannot apply standard proof techniques to programs involving pointers

2. Concurrent program analysis, in particular deadlock3. Program optimization

-- y.a = b

x.set_a (c) ? a

x

y

set_a (c)

b

c-- x.a = c-- x.a = c

-- c = c, i.e. True

Understand as x.a := c

-- y.a = b

46

Alias relations

Relation of interest:“In the computation, x might become aliased to

y”Definition:

Not necessarily transitive:if c then

x := yelse

y := zend

A binary relation is an alias relationif it is symmetric and irreflexive

Can alias x to yand y to zbut not x to z

47

Describing an alias relation

If r is a relation in E E, the following is an alias relation:

r r r-1 ― Id [E]

Example: {[x, x], [x, y], [y, z]} =

Generalized to sets: {x, y, z} =

=D

Set differenceIdentity on E

Set of binary relations on E; formally: P (E x E)

{[x, y], [y, x], [y, z], [z, y]}

{[x, y], [y, x], [x, z], [z, x], [y, z], [z, y]}

48

Canonical form and alias diagrams

Canonical form of an alias relation: e.g.

, meaning

None of the sets of variablesis a subset of another

x, y, y, z, x, u, v

x

u, v

y

x

y, z

Make it canonical:x, x

, yy

{x, y} { y, z} {x, u, v}

(not canonical)

Alias diagram:

yy

49

Alias diagrams (non-O-O)

x

u, v

y, z

x,

, y

Source node Value nodesValue nodesValue nodes

In canonical form: no label is subset of another; each label has at least two variables

50

Operations on alias relations

If a is an alias relation in in and A a set, the following are alias relations:

r \– A = r — E x A

a / x = {y: E | (y = x) [x, y] a}

51

D

“Quotient”, similar to equivalence class in equivalence relation

D

“Minus”

Set of all variables

What the calculus is about

The purpose of the calculus is to define, for any instruction p and any alias relation a, the value of

a » pwhich denotes:

The aliasing relation resulting from executingp from an initial state in which the aliasingrelation is a

For an entire program: compute » p52

Limits of the calculus

The calculus is exact

But language simplifications cause over-approximation:

Conditional instruction:

then p else q end

Loop: loop p end

To correct over-approximation: cut instruction53

Basic instructions

x, y, … are variables

Instructions (p, q, …): skip create x x := y forget x (p ; q) then p else q end

-- Eiffel: x := Void-- Java etc.: x = null;

54

Basic properties

a » skip = a

a » (then p else q end ) = (a » p) (a » q)

a » (p ; q) = (a » p) » q

a » (forget x) = a \- {x}

a » create x = a \- {x}

55

The forget rule

a » (forget x) = a \- {x}

y

x,

y, z

x,

u, v

x,

x,

y

56

Assignment

a » (x := y) = givenb = a \- {x}

thenb ({x} x (b / y))

end

D

All pairs of the form [x, y] or [x, u] where u was aliased to y

Symmetrize and de-reflect

a deprived of all pairs involving x

57

Operations on alias relations (reminder)

r \– A = r — E x A

a / x = {y: E | (y = x) [x, y] a}

D

“Quotient

D

“Minus”

58

Assignment example 1

x

u, vx,

, y

Afterz := x

, z

, z

59


x

u, vx,

, y

Afterx := u

x, y

60


x

u, vx,

, y

Afterx := z

x, y

x, z

x,

61

Correcting over-approximations manually

cut x, y

Semantics: remove any aliasing between x and y

62

Cut example 1

63

x

u, vx,

, yx, y

After cut x, y

Cut example 2

x, y

After cut x, u

u, vx,x, x, v

64

Cut rule

a » cut x, y = a ― x, y

65

The role of cut

cut x, y informs the alias calculus with non-alias properties that come from other sourcesExample:

if m < n then t := u else t := y endm := m + 1if m < n then x := t end

In fact x cannot be aliased to y (only to u), but the alias theory does not know this propertyTo express it, add the instruction

cut x, y; This expression represents

check x /= y end (Eiffel)assert x != y ; (JML, Spec#)

66

Alias relation:

t, u, x, t, y, x

t, u, t, y

Iterations and loops

pn (for integer n): n executions of p (auxiliary

notion)

loop p end : any sequence (incl. empty) of executions of p

67

Iterations and loops

a » p0 = a

a » pn+1 = (a » pn) » p -- For n 0

a » (loop p end) = (a » pn)

n N

68

Loop aliasing theorem

a » (loop p end) is also the fixpoint of the sequence

t0 = a

tn+1 = tn (tn » p)

Gives a practical way to compute a » (loop p end)

69

Routines

Routine definitions (one of them designated as main):

r (args) do p end

Routine call: call r (c)

r

r

Notations:

Body of r:

Formal arguments of r: (args above)

Substitution in an expression F: F [u: v]

70

Alias calculus rule for routine call

a » call r (c) = a » [r : c]--

Because of recursion, no longer just definition but equation

For entire set of routines R, making up a program, this gives a vector equation

a » R = F (a » R)

Interpret as fixpoint) equation and solve iteratively

r

71

Introducing object-oriented constructs

1. Qualified expressions: e f g …

Can be used as source (not target!) of assignments

x := e f

2. Remote calls: x r

3. Current

72

Assignment (original rule)

a » (x := y) = given b = a \- {x}

then

b ({x} x (b / y) ) end

D

a deprived of all pairs involving x

This includes [x, y] ! All pairs [x, u] where u is either aliased to y in b or y itself

All u aliased to y in b, plus y itself

73

Assigning a qualified expression

x yx

x

z

x does not get aliased to x y!

(only to any z that was aliased to x

y)

x := x y

74

Assignment rule revisited

a » (x := y) = given

b = a \- {x} then

b ({x} x (b / y))

end

D

a deprived of all pairs involving xor an expression starting with x

75

Non-O-O diagrams

x

u, v

y, z

x,

, y

Source node Value nodesValue nodesValue nodesSingle source node(represents stack)Each value node represents a set of possible run-time valuesLinks: only from source tovalue nodes (will becomemore interesting with E4!)Edge label: set ofvariables; indicates theycan all be aliased to each otherIn canonical form: no label is subset of another; each label has at least two variables 76

O-O diagrams

:= x y

x yx

x

z

Links may now exist between value nodes(now called object nodes)Cycles possible (see next)

Source node

Value nodesValue nodesObject nodes

77

Representing a qualified call with arguments

call x r (a, b)

With, in a class C:

r (t: T ; u: U)

The formals meant: x’ au: x’ b

Negated variables

x x’

Negated variables a

78

The qualified call rule

a » call x r (c) = x ((x’ a) » call r (x’ c))

Example: c := d call x r (c)with r (u: T)

do

v := u end

xx’

c, dUnderstand as: c := d callwith r

do

v := u end

u := x’

c

u, v, x’ c,x’ d

x u, x v ,

x r

79

Processing a qualified call

a » call x r (c) = x ((x’ a) » call r (c)

Alias relation:

c, d

x’ c, x’ d

Prefix with x’

:

u, x’ c, x’

d

c := d callwith r

do

v := u end

u := x’

c

x f

v, u, x’ c, x’

d Prefix with x :

x v, x u, c, d

xx’

c

u,

,

x’ c, x’ d

v,x

x

x

x

c,d

Current

c

x’

c,x c, x’ c, x’ d x d

u,v,

x

x

, d, d

80

How to prove a program with references

Compute alias relation up to and including the largest expression involved in the program

Add alias properties to contracts of program

Prove program through usual axiomatic techniques

Prove correctness of cut instructions

81

- 3.5 -A Calculus of

Object Programs

82

The general goal

A theory to verify object-oriented programs

Handles references, aliasingSoundMechanizableClear In line with Eiffel’s Design by Contract

In particular, contracts can still be evaluated dynamically (for testing, debugging)

83

Reversing a listreverse local previous, next: LINKABLE [G] do from next := first ; previous := Void invariant

end

first

right

right

right

rightnext

?

?first right = - old first right

next right + previous right

= - old first right until next = Void loop

temp := previousprevious := nextnext := next right

previous put_right (temp) end first := previous ensure

previous

84

Components of the solution

1. Compositional logic for programming languages

2. Calculus of object structures

3. Inverse variables

4. Alias calculus

5. The proof

85

Compositional logic

Compositional logic deals with properties of the formi ; e

where i is an instruction and e an expression

Meaning: the value of e after executing i

Expressed in terms of values of expressions before this execution

Examples:(x := 1) ; x = 1(x := x + 1) ; x = x + 1

86

Comparison with other approachesDenotational:

State s: State where State = Variable ValueExpression e : State Value e.g. e (s) = 3Command c : State StateAdvantage: defines program as mathematical

objectDisadvantage: not verification oriented

Axiomatic (Hoare):Pre-post: {P} A {Q}

Advantage: intended for verification; invariantsDisadvantage: not a calculus

Axiomatic (Weakest precondition):Operator: A wp Q

Advantage: Calculus version of Hoare logicDisadvantage: Boolean expressions only 87

A special case

If Q is boolean, then

i ; Q

is the weakest precondition of i for Q

88

Hoare-style properties

To prove{P } i {Q }

prove that

P ( i ; Q )

89

Properties of “;”

i ; (j ; e ) = ( i ; j ) ; e Associativity

i ; ( x y ) = ( i ; x ) ( i ; y ) Distributivity

-- For most operators

-- Only if e does not involve the old operator (see next)

CA

CD

90

Reminder: function composition

Given

f : A Bg : B C

their compositionf g : A C

is the function a | g (f (a))

91

f

g

A B C

a

Composition is associative:

[f g] h = f [g h]

f g

“;” in non-OO programming

Instructionsi, j : State State

Expressionse : State Value

Then “;” is the usual composition “”, as in e.g.

i ; j (State State) (State State),i.e. (State State)

i ; e (State State) (State Value),i.e. (State Value)

i ; j ; e -- Using associativity (CA1)92

“;” in object-oriented programming

It is again a form of composition, but applied to functions working on the “current object”

Instructionsi, j : Object State State

Expressionse : Object State Value

Then i ; j = o | s | (i (o ) j (o)) (s )

i ; e = o | s | (i (o ) e (o)) (s )93

The Current rule

For any instruction i :i ; Current = Current CUR

94

The memory operator

For any instruction i and any expression e :i ; old e = e

No associativity here; for example

((x := 0 ; x := 1)) ; old x = x

but(x := 0) ; ((x := 1) ; old x) = (x := 0) ; x

= 0

OLD

95

The assignment rule

(x e) ; x = e

(x e) ; y = y

:=:=

This rule applies to values of any type, including references, but will be extended for object expressions

General convention: x, y, z indicate different variables (values may be the same)

A2

A1

96

An example proof in compositional logic

(item := item + 1) ; (item = old item + 1)

By distributivity of ; for =, this is: ((item := item + 1) ; item) = (item := item + 1) ; old item + 1By the rule of old, this is: ((item := item + 1) ; item) = item + 1

By the assignment rule, this is: item + 1 = item + 1

To be proved:

CD

OLD

A1

97

The call rule

The unqualified call rule:

Denotational: (call r (c)) (s) = r (s [r : c])

Compositional: (call r (c)) ; e = r [r : c] ; eUC

98

The unqualified setter theorem

For an attribute a of type T, consider the routineset_a (f: T) do whatever ; a := f end

Then (call set_a (c)) ; a = c

Proof: this is a direct application of the preceding result

(call r (c)) ; e = r [r : c] ; e

A more general version of the theorem ( ) applies to any routine with the postcondition a = f Proof: add at the end of the routine an instruction a := f ; this does not change its semantics. Then apply .

US1

UC

US2

99

The alias calculusa » skip = aa » (then i else j end) = (a » i) (a » j)a » (i ; )) = (a » i) » )a » (forget x) = a \- {x}a » (create x) = a \- {x}a » (x := y) = a [x: y]a » cut x, y = a – x, ya » p0 = aa » pn+1 = (a » pn) » ia » (loop i end) = (a » pn)a » call r (a) = (a [ r : a]) » ra » call x r (a) = x (x’ (a [x r : a]) » r) \– x r

100

n N

Plus:x Current = xCurrent x = x

x’ x = Current

x x’ = Current

Current’= Current

a [x: y] = given b = a\- {x} then

b ({x} x (b/y))

end

a purged of expressions starting

with x

The calculus of object structures: paths

Syntax: a path is one of:Empty, written <>a, where a is the name of an attributea p, where p is (recursively) a path

Semantics: x y z … denotes the object obtained from the current object by following the link corresponding to x, then the link for y, then the link for z etc.

(If from any object in this sequence the next link is not defined, that object is the value of the path.)

xy

z

Currentx y z

101

Compositional semantics for O-O programs

Reminder for variables and expressions of non-ref types:(x e) ; y = y

(x e) ; x = e

:=:=

A2

A1They still hold, but we need to includethe effect on paths:(x e) ; x p = e

p:=

A3

-- If x is cycle-free for e before p (see next)

(x e) ; y p = y p

:=

A4

-- If x is cycle-free for e before p

Special case

102

The cycle-free condition

holds under the following condition: no prefix of p is of the form q x where e q may be aliased to Current

(“x is cycle-free for e before p”)This condition holds in particular if the structure is acyclic

y

(x e) ; x p = e p:=

x

Counter-example:(x := y ) ; x z x

zCurrent

O2

O1

p

In final state: x z x is attached to O2But in initial state: e p, i.e. y z x , is attached to O1

e

A3

A3

103

Sequence closure

b denotes the sequence of objects

Current, b, b b, b b b, …stopping at the first from which the a link either is void or leads to an object already encountered

Generalization: if p is a path, p b denotes the sequence

p, p b, p b b, p b b b, …

right

right

right right right

104

List reversal: expressing the invariant

- previous right + next right ~ old right

previous next

1 2 3 4 5

right

105


end

first

right

right

right

rightnext

?

?- first right = old first right

- previous right + next right

= old first right until next = Void loop

temp := previousprevious := nextnext := next right


previous


106

Acyclic attributes

In a class C, an attributea : C

is acyclic if no element of a may be aliased to Current

107

The closure theorem

x = <Current> + x x

Proof: from definition of No particular condition on x(e.g. x does not have to be acyclic)

More generally: p x = p + p x x

x x x x

Current

Sequence concatenation

One-element sequence

SC1

SC2

108

Assignment and sequence closure (1)

Theorem:(x := e) ; x p a = e p a

(also applicable if a is x, and if the path p is empty)Proof: since the two sides are sequences, it suffices to prove that elements of the sequences are pairwise equal. The individual equalities to prove are

(x := e) ; x p a n = e p a n

where a n is a a … a (n times), for a finite number of values of n starting at 0. They follow from

which is applicable since by the definition of every a

n path is acyclic. (q in this equality is p a n.)

AS1

(x e) ; x q = e q

:=

A3

109

Assignment and sequence closure (2)

Theorem:(x := e) ; x = <Current> + e x

Proof: apply successivelyThe closure theorem: x = <Current> + x x Distributivity The Current theorem :

(x := e) ; <Current> = <Current>The preceding theorem:

(x := e) ; x x = e x

AS2

CURCD

SC1

AS1

110

The qualified setter theorem

Consider set_a (f: T) with the postcondition a = f

Unqualified setter theorem (reminder):(call set_a (c)) ; a = c

QS

US2

Qualified setter theorem:(call x set_a (c)) ; x a = c

111

Remote assignment and sequence closure

Reminder:(x := e) ; x = <Current> + e x AS2

Qualified closure assignment theorem:

(call x set_a (c )) ; x a = <x > + c a QC

Proof:(call x set_a (c )) ; x a = <(call x set_a (c )) ; x >

+ (call x set_a (c )) ; x a

a

(call x set_a (c )) ; x = x(call x set_a (c )) ; x a a = c a

SC2

AS1

112

Reminders

p x = p + p x x

(x := e) ; x p a = e p a

SC2

AS1

113

The Proof

114


end

first

right

right

right

rightnext

?- first right = old first right

until next = Void loop temp := previousprevious := nextnext := next right


previous


115

The invariant


temp := previous

previous := next

next := next right

previous put_right (temp)

- previous right + next right 116

Proof illustration

117

Handling previous right

temp := previous

previous := next

next := next right


previous right



temp := previous

previous := next

next := next right

previous put_right (temp)<previous> + temp right

previous right



temp := previous

previous := next

next := next right


<previous> + temp right

previous right



temp := previous

previous := next

next := next right



<next> + temp right

previous right



temp := previous

previous := next

next := next right



<next> + temp right

<next> + previous right

previous right


Handling next right

temp := previous

previous := next

next := next right


next right


Handling next right

temp := previous

previous := next

next := next right


next right

next right


Handling next right

temp := previous

previous := next

next := next right


next right

next right right

next right


Handling next right

temp := previous

previous := next

next := next right


next right

next right right

next right

next right right


Handling next right

temp := previous

previous := next

next := next right


next right

next right right

next right

next right right

next right right


Putting the two pieces together

temp := previous

previous := next

next := next right


next right right<next> + previous right +–

- previous right + next right128

Putting the two pieces together

temp := previous

previous := next

next := next right


next right right– previous right + <next > +=

next right right<next> + previous right +–

next right– previous right +=


Assessment

Limitations:Not implementedNeeds more examplesDoes not yet handle inheritanceNo proof of soundness

Pros:Minimum annotation effortHigh-level (uses contracts of routines)Adapted to modern programming styleHandles aliasing automaticallyReflects how O-O programmers think about

programs130

- 5 -Conclusion

131

Verification As a Matter Of Course

132

verification as a matter of course

Documents

eiffel software eth

eiffel software itmo

language techniques

language convention

enterprise computing

future method

critical infrastructure

class invariantsopensource