Object Invariants in Dynamic Contexts

1
Object Invariantsin Dynamic Contexts

• K.R.M. Leino and P. Muller
• 15-819 Objects and Aspects
• Presented by Jonathan Aldrich

2
Outline

• Problem
• Modular enforcement of invariants
• Separate reasoning with callbacks and inheritance
• Solution
• Class invariants
• Partial packing and unpacking
• Ownership relation
• Discussion

3
Callbacks and Invariants

• class T
• int a, b
• invariant 0 lt a lt b
• public T( ) a 0 b 3
• public void m(. . .)
• int k 100/(b - a)
• a a 3 P(. . .) b (k 4) . b
• What if P calls m?
• Soundness Must ensure it doesnt, or that the
  invariant is not assumed by m

4
Inheritance and Invariants

• class Derived extends Base
• int a, b
• invariant 0 lt a lt b
• public void m(. . .)
• int k 100/(b - a)
• super.m(. . .)
• a a 3 P(. . .) b (k 4) . b
• What about the invariants of Base?
• Modularity would like to assume that super call
  ensures them
• Need notion entering and leaving a class scope

5
Class Invariants

• class C extends B int w
• invariant w lt 100 . . .
• class B extends A int z
• invariant y lt z . . .
• class A extends object int x, y invariant x lt
  y . . .
• inv A
• Invariant A must hold
• B and C may or may not hold

C w 43
B z 6
A x 5 y 7
object inv A
6
Class Invariants

• class C extends B int w
• invariant w lt 100 . . .
• class B extends A int z
• invariant y lt z . . .
• class A extends object int x, y invariant x lt
  y . . .
• o.z y1
• pack o as B
• pack o as C
• continue

C w 43
B z 6
A x 5 y 7
object inv A
7
Class Invariants

• class C extends B int w
• invariant w lt 100 . . .
• class B extends A int z
• invariant y lt z . . .
• class A extends object int x, y invariant x lt
  y . . .
• o.z y1
• pack o as B
• pack o as C
• continue

C w 43
B z 8
A x 5 y 7
object inv A
8
Class Invariants

• class C extends B int w
• invariant w lt 100 . . .
• class B extends A int z
• invariant y lt z . . .
• class A extends object int x, y invariant x lt
  y . . .
• o.z y1
• pack o as B
• pack o as C
• continue

C w 43
B z 8
A x 5 y 7
object inv B
9
Class Invariants

• class C extends B int w
• invariant w lt 100 . . .
• class B extends A int z
• invariant y lt z . . .
• class A extends object int x, y invariant x lt
  y . . .
• o.z y1
• pack o as B
• pack o as C
• continue

C w 43
B z 8
A x 5 y 7
object inv C
10
Inheritance and Invariants

• class Derived extends Base
• int a, b
• invariant 0 lt a lt b
• public void m(. . .)
• unpack this from Derived
• int k 100/(b - a)
• super.m(. . .) // unpacks and re-packs Base
• a a 3 P(. . .) b (k 4) . b
• pack this as Derived
• Incremental unpacking and re-packing supports
  modular verification

11
Callbacks and Invariants

• class T
• int a, b
• invariant 0 lt a lt b
• public T( ) a 0 b 3
• public void m(. . .) requires this . inv T
• unpack this from T
• int k 100/(b - a)
• a a 3 P(. . .) b (k 4) . b
• pack this as T
• What if P calls m?
• It must first restore the invariant and pack this
  as T, because ms precondition assumes that T is
  packed

12
Invariants and Sub-objects

• class BTree
• int i
• BTree left, right
• invariant (left ! null) ? left.i lt i
• ? (right ! null) ? right.i i
• How to ensure invariant modularly?
• What if someone modifies left.i without going
  through the current object?

13
Ownership, Boogie Style

• p is owned by o at T
• p.owner o,T
• p is committed
• p.committed
• All invariants hold for committed objects
• p.committed ? p.inv type(p)
• Object is committed when owner is packed
• p.owner o,T ? (p.committed ? o.inv T)

14
Invariants and Sub-objects

• class BTree
• int i
• rep BTree left, right
• invariant left.owner this, BTree
• invariant right.owner this, BTree
• invariant (left ! null) ? left.i lt i
• ? (right ! null) ? right.i i
• Invariant can rely on owned objects
• unpack this, invariants hold for children
• children cant be unpacked (and thus cant have
  broken invariants) unless owner is first unpacked

15
Ownership Transfer

• transferable class Possession . . .
• class Person
• rep Possession possn
• void donateTo(Person p)
• requires committed