Verification of object-oriented programs with invariants

1 / 17

# Verification of object-oriented programs with invariants - PowerPoint PPT Presentation

Verification of object-oriented programs with invariants. Mike Barnett, Robert DeLine, Manuel Fahndrich , K. Rustan M. Leino, Wolfram Schulte. ¨. Formal techniques for Java-like programs Darmstadt, Germany 21 July 2003. Example problem.

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

## PowerPoint Slideshow about 'Verification of object-oriented programs with invariants' - fabienne

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 of object-oriented programs with invariants

Mike Barnett, Robert DeLine, Manuel Fahndrich, K. Rustan M. Leino, Wolfram Schulte

¨

Formal techniques for Java-like programsDarmstadt, Germany21 July 2003

Example problem

class T {int x, y;invariant x < y;

publicvoid m(U u) { x++; u.p(); y++; }

invariant assumed to hold

invariant may not hold

problem if p calls back into T

invariant re-established

Wanted:Methodology for invariants
• Ideal methodology:
• easy to understand
• statically and modularly checkable
• identifies all errors in a program
• permits all good programs
Invariant declarations–one per subclass

Y y = new Y();

class W extends V {int a;int[] b;

invariant a ≤ b.length;

Y

X

W

V

class V extends U { P p;invariant p ≠ null;

U

T

Object

Special field inv keeps track of which invariants hold

o

o

o

• Declarations and statements of programminglanguage determine when inv is changed
• The associated invariants are checked when inv increases
• To prevent established invariants from having to bere-checked, one can treat fields in and below o.inv asread-only

W

W

W

V

V

V

U

U

U

T

T

T

Object

Object

Object

o.inv == ⊥

o.inv == U

o.inv == W== typeof(o)

“o is consistent”

inv can be used inmethod specifications

class T {int x, y;invariant x < y;

publicvoid m()requiresinv == T; {int[] a = newint[y-x]; … }

meaning: (∀t:T ･ t.inv <: T ⇒ t.x < t.y)

invariant holds here (checked at call sites)

inv can be used inmethod specifications

class T {int x, y;invariant x < y;

publicvoid m()requiresinv == typeof(this); {int[] a = newint[y-x]; … }

meaning: (∀t:T ･ t.inv <: T ⇒ t.x < t.y)

invariant holds here (checked at call sites)

Exposed vs. owned

o

o

o

o

owned

W

W

W

W

V

V

V

V

U

U

U

U

T

T

T

T

Object

Object

Object

Object

o.inv == W

o.inv == ⊥

o.inv == U

o.inv == W

consistent

consistent

exposed

owned

• Only consistent objects can be owned
• Special field exposed keeps track of exposed/owned
• exposed can be used in method specifications
Components

Q

Object

R

W

q

P

x

26

Object

V

p

U

T

Object

Components

Q

Object

• Component fields are declared as such
• Component fields are not necessarily unique references

R

q

P

x

26

Object

p

U

T

Object

Components

Q

Object

• When inv is increased to U, then U’s components are checked to be consistent (p.inv == typeof(p)) and are subsequently un-exposed

owned

R

q

P

x

26

Object

p

U

T

Object

o.inv == T

o.inv == U

Components

Q

Object

• Decreasing inv below U exposes U’s components

owned

R

q

P

x

26

Object

p

U

T

Object

o.inv == T

o.inv == U

Fields of componentscan be mentioned in invariants

k

Q

Object

g

h

R

q

P

x

26

Object

p

class U {…

invariant x ≤ p.g ∧ p.g == p.h;

invariant x ≤ q.k;

U

T

Object

• Fields of owned (un-exposed) objects are not allowed to be mutated
• A field o.f can be modified only when o.exposed holds
• A method m is allowed a net effect on a field o.f (including o.inv and o.exposed) only if:
• o.f appears in the modifies clause of m, or
• o was not allocated on entry to m, or
• o was not exposed on entry to m

new

Method calls may change fields of un-exposed objects

o

owned

g

h

R

P

x

26

Object

p

class U {…

invariant x ≤ p.g ∧ p.g == p.h;

U

T

Object

Related work
• rep types in CLU
• valid idiom in ESC/Modula-3
• (implicit) pack/unpack operations in Vault and Fugue
• capability calculus
• ownership types
• invariant declarations in ESC/Java and JML
• locking and monitor disciplines in concurrent programming
Conclusions

exposed

inv

Object

• Simple!
• inv, exposed, identification of components, protocol for changing inv/exposed
• object references can always be copied
• but objects can have just one owner
• fields can always be read