Verification of object-oriented programs with invariants

1
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
2
Example problem

• class T int x, y invariant x lt y
• public void 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
3
WantedMethodology for invariants

• Ideal methodology
• easy to understand
• statically and modularly checkable
• identifies all errors in a program
• permits all good programs

4
Invariant declarationsone per subclass

• class W extends V int a int b
• invariant a b.length

Y y new Y()
Y
X
W
V
class V extends U P p invariant p ?
null
U
T
Object
5
Special field inv keeps track of which invariants
hold
o
o
o
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

• Declarations and statements of programminglanguag
  e 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

6
inv can be used inmethod specifications

• class T int x, y invariant x lt y
• public void m( ) requires inv T int
  a new inty-x

meaning (?tT ? t.inv lt T ? t.x lt t.y)
invariant holds here (checked at call sites)
7
inv can be used inmethod specifications

• class T int x, y invariant x lt y
• public void m( ) requires inv
  typeof(this) int a new inty-x
  

meaning (?tT ? t.inv lt T ? t.x lt t.y)
invariant holds here (checked at call sites)
8
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

9
Components
Q
Object
R
W
q
P
x
26
Object
V
p
U
T
Object
10
Components
Q
Object
R
q
P
x
26
Object
p

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

U
T
Object
11
Components
Q
Object
owned
R
q
P
x
26
Object
p

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

U
T
Object
o.inv U
o.inv T
12
Components
Q
Object
owned
R
q
P
x
26
Object
p

• Decreasing inv below U exposes Us components

U
T
Object
o.inv U
o.inv T
13
Fields of componentscan be mentioned in
invariants
k
Q
Object
h
g
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

14
License to modify

• 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
15
Method calls may change fields of un-exposed
objects
o
owned
h
g
R
P
x
26
Object
p
class U invariant x p.g ? p.g p.h
U
T
Object
16
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

17
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
• but curbed expectations about the values read
• frame problem solved without abstraction (e.g.,
  data groups)
• Want
• experience, understanding of limits
• extensions to support more good programs
• more detailed comparison with other work