verification as a matter of course l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Verification As a Matter Of Course PowerPoint Presentation
Download Presentation
Verification As a Matter Of Course

Loading in 2 Seconds...

play fullscreen
1 / 134

Verification As a Matter Of Course - PowerPoint PPT Presentation


  • 119 Views
  • Uploaded on

Verification As a Matter Of Course. Bertrand Meyer ETH Zurich, Eiffel Software & ITMO

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Verification As a Matter Of Course' - Audrey


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
verification as a matter of course

VerificationAs a Matter Of Course

Bertrand Meyer

ETH 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

Microsoft Summer School, Moscow, July 2011

sel at itmo
SEL at ITMO
  • Software Engineering Laboratory |
  • Лаборатория Программной Инженерии
  • Создано в июне 2011
  • Ещё остаются открытые позиции!
    • Аспиранты и Кандидаты (на полной ставке)
    • Временные гранты (“sabbaticals”) для исследователей, 2 до 6 месяцев
initiatives
Initiatives

SEC-R conference in October 2011

ESEC 2013 will take place in Saint Petersburg

New LinkedIn group:

Программная Инженерия/ Software Engineering Russia

Software Engineering Seminar in Saint PetersburgITMO and Polytechnical University (V. Itsykson)

Every Thursday 18-21, visitors welcome

http://meyerseminar.org

contents
Contents
  • The goal: trusted components
  • The EVE environment
  • 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
  • Conclusion and assessment
  • Not included: concurrency
slide5

- 1 -

Scope & Goals

three forms of software development
Three forms of software development

Simple Web sites, spreadsheets, …

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

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

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

  • 1. Casual
  • 2. Professional
  • 3. Critical
language techniques for professional development
Language techniques for professional development

Dynamic allocation

Classes, objects

Inheritance

Polymorphism,dynamic binding

Exception handling

Closures (agents)

Exceptions

Genericity

...

research context 1 method and language
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
slide9

- 2 -

The EVE environment

r esearch context 2 eve
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 included
verification as a matter of course11
Verification As a Matter Of Course

Test results

AutoProof

Suggestions

Inter.prover

Test execution

EVE

AutoTest

Test case generation

Aliasanalysis

Suggestions

Invariantinference

Sep. logicprover

Invariantinference

Arbiter

AutoFix

scores
Scores

Carlo Furia, Julian Tschannen, Martin Nordio

  • Failed test: score = -1
  • Successful test run: 0 < score <= 0.9
  • Correctness proof: score = 1 May be scaled down if some aspects not taken into 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
combining static and dynamic techniques
Combining static and dynamic techniques
  • Static 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
Testing

“Ich bin der Geist, der stets verneint”Goethe, Faust, Act I

FiodorChaliapineas Mephistopheles

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

autotest
AutoTest

Ilinca CiupaAndreas LeitnerYi WeiEmmanuel StapfArno FivaManuel Oriol…

  • (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
autotest test generation
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
autotest test generation20
AutoTest: Test generation

Bernd Schoeller

*

*

Test:

s1, s2: SET

s2  s1

*SET

+SET2

+SET1

+

+

*: Deferred

+: Effective

autotest test extraction
AutoTest: Test extraction
  • Turn a failed execution into a test case
who finds what faults
Who finds what faults?

I.Ciupa, A. Leitner,M.Oriol, A. PretschnerICST 2008 (best paper)

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% implementation
  • User reports: 36% specification, 64% implementation
citadel daikon for eiffel
CITADEL: Daikon for Eiffel

Nadia PolikarpovaIlincaCiupaISSTA 2009

How do programmer-written and inferred contracts compare?

Can contract inference be used to improve the quality of programmer-written contracts?

citadel results
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
AutoFix: programs that fix themselves

Yi Wei, Yu Pei, Andreas Zeller, ISSTA 2010

Yi Wei, Yu Pei, Carlo Furia, ASE 2011 (etc.)

Passing & failing test cases

Difference

Fix to minimize

the difference

  • 16 faults fixed out of 42
  • Some of the fixes are exactly the same as those proposed by professional programmers
slide26

- 3.1 -

Towardscompletecontracts

typical contract list insertion
Typical contract: list insertion

count

index

1

v

-- Previous elements unchanged!

put_right (v: G)

-- Insert v to the right of cursor

require

index <= count

ensure

i_th (index + 1) = v

count =oldcount + 1

index =oldindex

end

complete contracts
Complete contracts

Bernd Schoeller, Tobias Widmer (2008)Nadia Polikarpova (VSTTE 2010)

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)

typical contract list insertion29
Typical contract: list insertion

count

index

1

v

-- Previous elements unchanged!

put_right (v: G)

-- Insert v to the right of cursor

require

index <= count

ensure

i_th (index + 1) = v

count =oldcount + 1

index =oldindex

end

list insertion with model based contract
List insertion with model-based contract

note

model: sequence, index

classLIST [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 = oldindex

end

...

model based contracts applications
Model-based contracts: applications
  • On 7 of the most popular EiffelBase classes

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

- 3.2 -

Negative Variables& the Essenceof Object-Oriented Programming

o o analysis design programming
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 feature

r

do

x := 1

x . f (...)

end

...

end

Need to model this property in the logic

simplified denotational rule for routines unqualified call
Simplified denotational rule for routines (unqualified call)

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

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

classic axiomatic rule for routines
Classic axiomatic rule for routines
  • {P} r {Q}
  • {P [r: c]} call r (c) {Q [r: c]}

(Ignoring recursion)

tentative rule for qualified o o calls
Tentative rule for qualified (O-O) calls
  • {P and INV} r {Q and INV}
  • {xP [r: c]} callx  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

(Inadequate!)

object oriented calls
Object-oriented calls

Known by the target as x’ y

  • Negative variables:

Current

y

  • x Current= x
  • Current x = x
  • x’ x = Current
  • x x’ = Current
  • Current’ = Current

x’

x

Target object

call x r (c)

denotational rule for calls
Denotational rule for calls

= xr(s [r: x’c])

  • Then for any property P(such that “” distributes over P):
  • P (call x  r (c)) = xP(call r (x’c))

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

Unqualified calls:

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

Qualified calls:

(call x  r (c)) (s) = xcall r (x’ c) (s)

adequate hoare rule for qualified calls
Adequate Hoare rule for qualified calls
  • {P and INV} r {Q and INV}
  • {xP [r: c]} callx  r (c) {xQ [r: c]}

Proper rule

  • {P and INV} r {Q and INV}
  • {xP [r: x’c]} callx  r (c) {xQ [r: x’c]}

Reminder: inadequate rule

slide40

- 3.3 -

Framing:a language convention

the frame issue
The frame issue:
  • Specifying what does not change

In a class ACCOUNT:

deposit (sum: INTEGER)

require ...

do...

ensure

balance = old balance + sum

end

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

owner, account_number, overdraft_limit...?

What about descendant classes, e.g. MAFIA_ACCOUNT?

modifies clauses
“Modifies” clauses
  • ESC-Java, JML, Spec#: specify what a command can change
  • Theoretical problems:
    • This can be an infinite set
    • Requires careful design for inheritance
  • Practical problem: tedious to express
  • Pragmatic observation from survey of JMLcode:
    • Every item listed in a modifiesclause also appears in the postcondition!
the proposed language convention
The proposed language convention
  • deposit (sum: INTEGER )
  • require ...
  • do...
  • ensure
  • balance = old balance + sum
  • end

; cur: CURRENCY

old

has_penalty = (cur /= currency)

involved (is_overdraft)

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

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

slide44

- 3.4 -

The Alias Calculus

the question asked by the alias calculus
The question asked by the Alias Calculus

Broy volume (IJSI, 2011)

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

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

an example
An example

x

y

why is this important
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
Applications of alias analysis

b

-- c = c, i.e. True

a

?

set_a (c)

x.set_a (c)

Understand as

x.a := c

-- y.a = b

-- y.a = b

x

-- x.a = c

-- x.a = c

y

c

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

2. Concurrent program analysis, in particular deadlock

3. Program optimization

alias relations
Alias relations

A binary relation is an alias relationif it is symmetric andirreflexive

Can alias x to y

and y to z

but not x to z

Relation of interest:

“In the computation, x might become aliased to y”

Definition:

Not necessarily transitive:

ifcthen

x := y

else

y := z

end

describing an alias relation
Describing an alias relation
  • Set of binary relations on E; formally: P(E x E)

D

Identity on E

=

Set difference

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

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

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

rr r-1― Id [E]

  • Example: {[x, x], [x, y], [y, z]}=
  • Generalized to sets:
  • {x, y, z} =
canonical form and alias diagrams
Canonical form and alias diagrams

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

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

x

, y

y

y

  • Alias diagram:

y, z

  • (not canonical)

y

y

x,

u, v

x

x

  • Make it canonical:

Canonical form of an alias relation: e.g.

, meaning

None of the sets of variablesis a subset of another

alias diagrams non o o
Alias diagrams (non-O-O)

Value nodes

Value nodes

Value nodes

Source node

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

x

, y

y, z

x,

u, v

operations on alias relations
Operations on alias relations

“Minus”

Set of all variables

“Quotient”, similar to equivalence class in equivalence relation

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}

what the calculus is about
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 » p

which denotes:

The aliasing relation resulting from executing

pfrom an initial state in which the aliasing

relation is a

For an entire program: compute » p

limits of the calculus
Limits of the calculus
  • The calculus is exact
  • But language simplifications cause over-approximation:
    • Conditional instruction:thenp else q end
    • Loop: loop p end
  • To correct over-approximation: cut instruction
basic instructions
Basic instructions

-- Eiffel: x := Void

-- Java etc.: x = null;

  • x, y, … are variables
  • Instructions (p, q, …):
    • skip
    • create x
    • x := y
    • forget x
    • (p ; q)
    • then p else q end
basic properties
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
The forgetrule

y

y

x,

x,

y, z

x,

x,

u, v

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

assignment
Assignment

a deprived of all pairs involving x

Symmetrize and de-reflect

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

a » (x := y) = given

b = a \- {x}

then

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

end

operations on alias relations reminder
Operations on alias relations (reminder)

“Minus”

“Quotient

r \– A = r — E x A

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

assignment example 1
Assignment example 1

x

, y

, z

x,

u, v

, z

After

z := x

assignment example 2
Assignment example 2

x

x

, y

, y

x,

u, v

After

x := u

assignment example 3
Assignment example 3

, y

x

x

, y

x, z

x,

u, v

x,

After

x := z

correcting over approximations manually
Correcting over-approximations manually
    • cut x, y
  • Semantics: remove any aliasing between x and y
cut example 1
Cut example 1

x

x

, y

, y

x,

u, v

After

cutx, y

cut example 2
Cut example 2

x

, y

x

, v

u, v

x,

x,

After

cutx, u

cut rule
Cut rule

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

the role of cut
The role of cut

Alias relation: 

t, u, t, y

t, u, x, t, y, x

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

Example:

ifm < n thent := u elset := y end

m := m + 1

ifm < n thenx := t end

In fact x cannot be aliased to y (only to u), but the alias theory does not know this property

To express it, add the instructioncut x, y;

This expressionrepresents

checkx /= y end (Eiffel)

assertx != y ; (JML, Spec#)

iterations and loops
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 loops70
Iterations and loops

nN

a » p0 = a

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

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

loop aliasing theorem
Loop aliasing theorem
  • a » (looppend) is also the fixpoint of the sequence

t0 = a

tn+1 = tn(tn » p)

  • Gives a practical way to compute a » (looppend)
routines
Routines
  • Notations:
    • Body of r:
    • Formal arguments of r: (argsabove)
    • Substitution in an expression F: F [u: v]

r

r

  • Routine definitions (one of them designated as main):

r (args) do p end

  • Routine call:call r (c)
alias calculus rule for routine call
Alias calculus rule for routine call

r

a » callr (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
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
Assignment (original rule)

a deprived of all pairs involving x

All u aliased to yin b, plusy itself

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

This includes[x, y] !

a » (x := y) = given

b = a \- {x}

then

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

end

assigning a qualified expression
Assigning a qualified expression
  • x := x y

x

y

x

x

z

xdoes not get aliased tox y!

(only to any z that was aliased tox y)

assignment rule revisited
Assignment rule revisited

adeprived of all pairs involving x

or an expression starting with x

a » (x := y) = given

b = a \- {x}

then

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

end

non o o diagrams
Non-O-O diagrams

Value nodes

Value nodes

Value nodes

Source node

Single source node(represents stack)

Each value node represents a set of possible run-time values

Links: only from source tovalue nodes (will becomemore interesting with E4!)

Edge label: set ofvariables; indicates theycan all be aliased to each other

x

, y

y, z

x,

u, v

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

o o diagrams
O-O diagrams

Value nodes

Value nodes

Object nodes

Source node

x

y

x

x

z

Links may now exist between value nodes(now called object nodes)

Cycles possible (see next)

:= x y

representing a qualified call with arguments
Representing a qualified call with arguments

Negated variables

Negated variables

a

x’

x

call x  r (a, b)

With, in a class C:

r (t: T ; u: U)

The formals mean

t: x’ a

u: x’ b

the qualified call rule
The qualified call rule
  • Example:
  • c := d
  • callx  r (c)
  • with
  • r (u: T)
  • do
  • v := u
  • end
  • Understand as:
  • c := d
  • call
  • with
  • r
  • do
  • v := u
  • end

c, d

,

xu, xv

x r

u,v,x’c,x’d

x’

x

u := x’ c

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

processing a qualified call
Processing a qualified call

c := d

call

with

r

do

v := u

end

Alias relation:

, d

, d

c

,

c, d

x f

Current

Prefix with x’ :

x’

x

u,

x’c, x’ d

x

v,

x

u := x’ c

x’c, x’d

u, x’ c, x’ d

c,

x

d

x

v, u, x’ c, x’d

x’c, x’d

Prefix with x:

u,

c

x

x’c,

d

x

v,

c,

x

xv, xu, c, d

x

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

how to prove a program with references
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
slide84

- 3.5 -

A Calculus ofObject Programs

the general goal
The general goal
  • A theory to verify object-oriented programs
    • Handles references, aliasing
    • Sound
    • Mechanizable
    • Clear
    • In line with Eiffel’s Design by Contract
      • In particular, contracts can still be evaluated dynamically (for testing, debugging)
reversing a list
Reversing a list

reverse

local

previous, next: LINKABLE [G]

do

from

next :=first ; previous :=Void

invariant

first

right

next   right+ previous  right= - oldfirst   right

?

right

  • untilnext = Voidloop temp := previous
  • previous:= next
          • next:=next  right
  • previous put_right (temp)
  • end
  • first :=previous
  • ensure

previous

right

next

right

?

first  right= - old first  right

end

components of the solution
Components of the solution

Compositional logic for programming languages

Calculus of object structures

Inverse variables

Alias calculus

The proof

compositional logic
Compositional logic

Compositional logic deals with properties of the form

i;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 approaches
Comparison with other approaches

Denotational:

State s: State where State = Variable  Value

Expression e : State  Valuee.g.e (s) = 3

Command c : State  State

Advantage: defines program as mathematical object

Disadvantage: not verification oriented

Axiomatic (Hoare):

Pre-post:{P} A {Q}

Advantage: intended for verification; invariants

Disadvantage: not a calculus

Axiomatic (Weakest precondition):

Operator: A wp Q

Advantage: Calculus version of Hoare logic

Disadvantage: Boolean expressions only

a special case
A special case

If Q is boolean, then

i ;Q

is the weakest precondition of i for Q

hoare style properties
Hoare-style properties

To prove

{P } i {Q }

prove that

P  (i ;Q)

properties of
Properties of “;”

CA

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

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

-- For most operators 

CD

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

reminder function composition
Reminder: function composition

A

C

B

g

a

f

f g

Composition is associative:

[f g]h = f  [g h]

Given

f : AB

g : BC

their composition

f g: A  C

is the function

 a | g (f (a))

in non oo programming
“;” in non-OO programming

Instructions

i, j: State State

Expressions

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

in object oriented programming
“;” in object-oriented programming

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

Instructions

i, j: Object  State State

Expressions

e: Object  State Value

Then

i ;j = o | s | (i (o)j (o)) (s)

i ;e = o | s | (i (o)e (o)) (s)

the current rule
The Current rule

i;Current=Current

CUR

For any instruction i :

the memory operator
The memory operator

i;olde = e

OLD

  • No associativity here; for example

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

  • but

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

= 0

For any instruction iand any expression e:

the assignment rule
The assignment rule

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

:=

A1

(xe) ;x= e

A2

:=

(xe);y= y

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

an example proof in compositional logic
An example proof in compositional logic

To be proved:

CD

By distributivity of ; for =, this is:

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

By the rule of old, this is:

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

OLD

By the assignment rule, this is:

item + 1 = item + 1

A1

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

the call rule
The call rule

UC

  • The unqualified call rule:
    • Denotational: (call r (c)) (s) = r (s [r : c])
    • Compositional: (call r (c)) ; e = r[r : c] ; e
the unqualified setter theorem
The unqualified setter theorem

UC

US2

US1

For an attribute a of type T, consider the routine

set_a (f: T) do whatever ; a := f end

Then

(callset_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 calculus
The alias calculus

a purged of expressions starting with x

a [x: y] = given b = a\- {x}thenb  ({x} x(b/y))end

  • Plus:
    • xCurrent= x
    • Current x = x
    • x’ x = Current
    • x x’ =Current
    • Current’ =Current

nN

  • a »skip = a
  • a » (thenielsejend)= (a » i)  (a » j)
  • a » (i ; )) = (a » i) » )
  • a » (forgetx)= a \- {x}
  • a » (create x)= a \- {x}
  • a » (x := y) = a [x: y]
  • a » cutx, y = a – x, y
  • a » p0 = a
  • a » pn+1 = (a » pn) » i
  • a » (loopiend) = (a » pn)
  • a » callr (a) = (a [r:a]) » r

a » call x r (a) = x(x’(a [xr:a]) » r) \– x r

the calculus of object structures paths
The calculus of object structures: paths

x

z

y

Current

x y z

  • Syntax: a path is one of:
    • Empty, written <>
    • a, where a is the name of an attribute
    • a 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.)
compositional semantics for o o programs
Compositional semantics for O-O programs

:=

(xe) ;y= y

A2

A1

:=

(xe);x= e

  • They still hold, but we need to includethe effect on paths:

Special case

A3

:=

(xe) ;x p= ep

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

A4

:=

(xe) ;y p= yp

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

Reminder for variables and expressions of non-ref types:

the cycle free condition
The cycle-free condition

A3

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

p

x

O1

:=

(xe) ;x p = e p

e

y

  • In final state:xz x is attached to O2
  • But in initial state:
  • ep, i.e. yz x , is attached to O1

Current

z

O2

A3

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

This condition holds in particular if the structure is acyclic

sequence closure
Sequence closure

 right

right

right

right

right

  •  b
  • denotes the sequence of objectsCurrent, 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  bdenotes the sequencep, p b, p b b, p b b b, …
list reversal expressing the invariant
List reversal: expressing the invariant

1

2

3

4

5

right

previous

next

- previous right +next right ~oldright

reversing a list108
Reversing a list

reverse

local

previous, next: LINKABLE [G]

do

from

next :=first ; previous :=Void

invariant

first

right

- previous  right+ next right= oldfirst   right

?

- previous  right+ next right

right

  • untilnext = Voidloop temp := previous
  • previous:= next
          • next:=next  right
  • previous put_right (temp)
  • end
  • first :=previous
  • ensure

previous

right

next

right

?

- first right=old first  right

end

acyclic attributes
Acyclic attributes

In a class C, an attribute

a: C

is acyclic if no element of  amay be aliased to Current

the closure theorem
The closure theorem

One-element sequence

SC1

Sequence concatenation

x

x

x

x

Current

SC2

  •  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
assignment and sequence closure 1
Assignment and sequence closure (1)

AS1

:=

A3

(xe) ;x q= eq

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 an= e p an

where anisa 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 an path is acyclic. (q in this equality is p an.)

assignment and sequence closure 2
Assignment and sequence closure (2)

AS2

SC1

CD

CUR

AS1

  • Theorem:
  • (x := e) ; x = <Current>+ e  x
  • Proof: apply successively
    • The 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
The qualified setter theorem

US2

  • Qualified setter theorem:
  • (callx  set_a (c)) ;xa = c

QS

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

Unqualified setter theorem (reminder):

(callset_a (c)) ; a = c

remote assignment and sequence closure
Remote assignment and sequence closure

AS2

Qualified closure assignment theorem:

(callx  set_a (c)) ;x  a = <x>+ c a

QC

Proof:

(callx  set_a (c)) ;x  a = <(callx  set_a (c)) ; x>

+ (callx  set_a (c)) ; x  a a

(callx  set_a (c)) ; x = x

(callx  set_a (c)) ; x  a  a = c  a

SC2

AS1

Reminder:

(x := e) ; x = <Current>+ e  x

reminders
Reminders

SC2

AS1

  • p  x = p + p x  x
  • (x := e) ;x p  a = e p  a
reversing a list117
Reversing a list

reverse

local

previous, next: LINKABLE [G]

do

from

next :=first ; previous :=Void

invariant

first

right

- previous  right+ next right

right

  • untilnext = Voidloop temp := previous
  • previous:= next
          • next:=next  right
  • previous put_right (temp)
  • end
  • first :=previous
  • ensure

previous

right

next

right

?

- first right=old first  right

end

the invariant
The invariant

- previous  right+ next  right

temp := previous

previous:= next

next:=next  right

previous put_right (temp)

- previous  right+ next  right

handling previous right
Handling previous  right

temp := previous

previous:= next

next:=next  right

previous put_right (temp)

previous  right

- previous  right+ next  right

handling previous right121
Handling previous  right

temp := previous

previous:= next

next:=next  right

previous put_right (temp)

<previous> + temp  right

previous  right

- previous  right+ next  right

handling previous right122
Handling previous  right

temp := previous

previous:= next

next:=next  right

previous put_right (temp)

<previous> + temp  right

<previous> + temp  right

previous  right

- previous  right+ next  right

handling previous right123
Handling previous  right

temp := previous

previous:= next

next:=next  right

previous put_right (temp)

<next> + temp  right

<previous> + temp  right

<previous> + temp  right

previous  right

- previous  right+ next  right

handling previous right124
Handling previous  right

<next> + previous  right

temp := previous

previous:= next

next:=next  right

previous put_right (temp)

<next> + temp  right

<previous> + temp  right

<previous> + temp  right

previous  right

- previous  right+ next  right

handling next right
Handling next  right

temp := previous

previous:= next

next:=next  right

previous put_right (temp)

next  right

- previous  right+ next  right

handling next right126
Handling next  right

temp := previous

previous:= next

next:=next  right

previous put_right (temp)

next  right

next  right

- previous  right+ next  right

handling next right127
Handling next  right

temp := previous

previous:= next

next:=next  right

previous put_right (temp)

next right  right

next  right

next  right

- previous  right+ next  right

handling next right128
Handling next  right

temp := previous

previous:= next

next:=next  right

previous put_right (temp)

next right  right

next right  right

next  right

next  right

- previous  right+ next  right

handling next right129
Handling next  right

next right  right

temp := previous

previous:= next

next:=next  right

previous put_right (temp)

next right  right

next right  right

next  right

next  right

- previous  right+ next  right

putting the two pieces together
Putting the two pieces together

<next> + previous  right

next right  right

+

temp := previous

previous:= next

next:=next  right

previous put_right (temp)

- previous  right+ next  right

putting the two pieces together131
Putting the two pieces together

<next> + previous  right

next right  right

+

temp := previous

previous:= next

next:= next  right

previous put_right (temp)

– previous  right + <next>

next right  right

=

+

– previous  right

next  right

=

+

- previous  right+ next  right

assessment
Assessment
  • Limitations:
    • Not implemented
    • Needs more examples
    • Does not yet handle inheritance
    • No proof of soundness
  • Pros:
    • Minimum annotation effort
    • High-level (uses contracts of routines)
    • Adapted to modern programming style
    • Handles aliasing automatically
    • Reflects how O-O programmers think about programs
slide133

- 5 -

Conclusion