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

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, …

Language techniques for professional development

Dynamic allocation Classes,

objects

Exception handling Closures

(agents)Exceptions

Genericity

InheritancePolymorphism,

dynamic binding

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

Test results

Inter.prover

Sep. logic

prover

AutoTest

Invariantinferenc

Suggestions

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

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

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

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…

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

Maurice Maeterlinck, La Vie des Abeilles, 1901

AutoTest: Test generation

*SET**

Test:s1, s2 : SETs2 s1

*: Deferred +: Effective

Bernd Schoeller

AutoTest: Test extraction

Turn a failed execution into a test case

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)

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

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

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

- 3.1 -Towardscompletecontracts

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

count1

-- Previous elements unchanged!

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)

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

count1

-- Previous elements unchanged!

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

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

- 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

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

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

Object-oriented calls

call x r (c)

Current

Target object

Negative variables:

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’

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

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

Proper rule

- 3.3 -Framing:

a language convention

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

“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!

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

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

has_penalty = (cur /= currency)

; cur: CURRENCY

oldinvolved

(is_overdraft)

- 3.4 -The Alias Calculus

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)

An example

Why is this important?

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

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

set_a (c)

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

-- c = c, i.e. True

Understand as x.a := c

-- y.a = b

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

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} =

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]}

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

Make it canonical:x, x

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

(not canonical)

Alias diagram:

Alias diagrams (non-O-O)

Source node Value nodesValue nodesValue nodes

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

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}

“Quotient”, similar to equivalence class in equivalence relation

“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;

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}

The forget rule

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

Assignment

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

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

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

Operations on alias relations (reminder)

r \– A = r — E x A

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

“Quotient

“Minus”

Assignment example 1

u, vx,

Afterz := x

u, vx,

Afterx := u

u, vx,

Afterx := z

Correcting over-approximations manually

cut x, y

Semantics: remove any aliasing between x and y

Cut example 1

u, vx,

, yx, y

After cut x, y

Cut example 2

After cut x, u

u, vx,x, x, v

Cut rule

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

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

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

Iterations and loops

a » p0 = a

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

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

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)

Routines

Routine definitions (one of them designated as main):

r (args) do p end

Routine call: call r (c)

Notations:

Body of r:

Formal arguments of r: (args above)

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

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

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

Assignment (original rule)

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

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

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

Assigning a qualified expression

x does not get aliased to x y!

(only to any z that was aliased to x

x := x y

Assignment rule revisited

a » (x := y) = given

b = a \- {x} then

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

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

Non-O-O diagrams

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

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

Source node

Value nodesValue nodesObject nodes

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

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)

v := u end

c, dUnderstand as: c := d callwith r

v := u end

u := x’

u, v, x’ c,x’ d

x u, x v ,

Processing a qualified call

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

Alias relation:

x’ c, x’ d

Prefix with x’

u, x’ c, x’

c := d callwith r

v := u end

u := x’

v, u, x’ c, x’

d Prefix with x :

x v, x u, c, d

x’ c, x’ d

Current

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

, d, d

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

- 3.5 -A Calculus of

Object Programs

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)

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

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

1. Compositional logic for programming languages

2. Calculus of object structures

3. Inverse variables

4. Alias calculus

5. The proof

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

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

is the weakest precondition of i for Q

Hoare-style properties

To prove{P } i {Q }

prove that

P ( i ; Q )

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)

Reminder: function composition

f : A Bg : B C

their compositionf g : A C

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

Composition is associative:

[f g] h = f [g h]

“;” 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

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

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)

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:

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

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 .

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

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

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

Currentx y z

Compositional semantics for O-O programs

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

(x e) ; x = e

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

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

(x e) ; y p = y p

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

Special case

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

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

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

zCurrent

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

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

List reversal: expressing the invariant

- previous right + next right ~ old right

previous next

1 2 3 4 5

rightnext

?- first right = old first right

- previous right + next right

= old first right until next = Void loop

temp := previousprevious := nextnext := next right

In a class C, an attributea : C

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

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

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

(x e) ; x q = e q

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

The qualified setter theorem

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

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

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

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

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

Reminders

p x = p + p x x

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

The Proof

rightnext

?- first right = old first right

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

temp := previous

previous := next

next := next right

previous put_right (temp)

- previous right + next right 116

Proof illustration

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

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

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

Verification As a Matter Of Course

Verification As a Matter Of Course

eiffel software eth

eiffel software itmo

language techniques

language convention

enterprise computing

future method

critical infrastructure

class invariantsopensource

Documents

Verification course

Training Course 2009 – NWP-PR: Ensemble Verification II...

S.No Course Code Name of the Course Credits - karunya.edu...

Training Course 2009 – NWP-PR: Ensemble Verification I...

Course Code: US01CPHY01 Course Title: Properties of Matter.....

1. The external verification process 1...The external...

Validation, Verification, Qualification : Which is right and...

ME322 Thermal-fluids Laboratory (Required Course)...

Probabilistic damage stability verification of PYC motor...

Challenging Times For Oak Knoll Golf Course (No Matter How.....

Stefan Doll-VHDL Verification Course-UPDATED

Annie Payson Call-As a Matter of Course

Environmental Sciences Course Principles of Matter and...

Chapter 8 Physics A First Course Matter and Energy.

As a Matter of Course - Free E-Book Kava-Traction

UCLH Charity Course InformationIssues)...