Reasoning about object structures with Spec

1
Reasoning about object structures with Spec

• K. Rustan M. LeinoMicrosoft Research, Redmond, WA

Joint work with Mike Barnett, Ádám Darvas,
Manuel Fähndrich, Peter Müller, Wolfram Schulte,
Herman Venter, Angela Wallenburg
INRIA / Microsoft lab, Paris, France, 15 Nov 2006
2
Software engineering problem

• Building and maintaining large software systems
  that are correct

3
Approach

• Specifications record design decisions
• bridge intent and code
• Tools amplify human effort
• manage detail
• find inconsistencies
• ensure quality

4
Research goals

• Build the best such system we can build today
• Experiment with the system to get a feel for what
  it is like to use
• Advance the state of the art

5
Spec

• Experimental mix of contracts and tool support
• Aimed at experienced developers who know the high
  cost of testing and maintenance
• Superset of C
• non-null types
• pre- and postconditions
• object invariants
• Tool support
• more type checking
• compiler-emitted run-time checks
• static program verification

contracts everywhere
C
into the future
familiar
type checking
static verification
run-time checks
degree of checking,effort
6
Spec demo
7
Spec program verifier architecture
Spec
Spec compiler
MSIL (bytecode)
Spec program verifier (aka Boogie)
bytecode translator
inference engine
Boogie PL
V.C. generator
verification condition
automatictheorem prover
correct or list of errors
8
Object invariants

• 0. Simple objects
• 1. Aggregate objects
• 2. Immutable types
• 3. Subclasses
• 4. Additive invariants

9
0. When do invariants hold?

• class Car
• int speedint windResistance
• invariant windResistance K speed speed
• public Car() speed 0 windResistance 0
  
• public void SetSpeed(int kmph) speed
  kmph windResistance K speed speed

10
0. When do invariants hold?

• class Car
• int speedint windResistance
• invariant windResistance K speed speed
• public Car() speed 0 windResistance 0
  
• public void SetSpeed(int kmph) speed
  kmph windResistance K speed speed

11
0. When do invariants hold?

• class Car
• int speedint windResistance
• invariant windResistance K speed speed
• public Car() speed 0 windResistance 0
  
• public void SetSpeed(int kmph) speed kmph
  P( ) windResistance K speed speed

Invarianttemporarilyviolatedwhat if Pcalls
back?
12
Object states

• Mutable
• Object invariant might be violated
• Field updates are allowed
• Valid
• Object invariant holds
• Field updates not allowed

13
The heap (the object store)
14
The heap (the object store)
MutableValid
15
To mutable and back expose

• class Car
• int speedint windResistance
• invariant windResistance K speed speed
• public void SetSpeed(int kmph) requires
  this.valid expose (this) speed
  kmph windResistance K speed speed

changes thisfrom valid to mutable
can update speed,because this.mutable
changes thisfrom mutable to valid
16
Summary for simple objects
(?o o.mutable ? Inv(o))
invariant this.f
check x.mutable
x.f E
o.mutable ? o.valid
17
Summary for simple objects
(?o o.mutable ? Inv(o))
x.valid false
x.valid true
expose (x)
check x.valid
check Inv(x)
o.mutable ? o.valid
18
1. Aggregate objects

• class Seat public void Move(int pos) requires
  this.valid
• class Car
• Seat s
• public void Adjust(Profile p) requires
  this.valid ? p.valid s.Move(p.SeatPosition)

19
Ownership
Points to owner
20
Ownership domains
Points to owner
21
Ownership domains
x
z
y
x owns y and z y and z are componentsin the
representation of x y and z are peers
Points to owner
22
An object is only as valid as its components
Points to ownerMutable objectValid object
23
Representation (rep) fields

• class Seat public void Move(int pos) requires
  this.Consistent
• class Car
• rep Seat s
• public void Adjust(Profile p) requires
  this.Consistent ? p.Consistent expose (this)
  s.Move(p.SeatPosition)

o.Consistent ? o.owner.mutable ? o.valid
24
Peer fields and peer validity

• class Seat public void Move(int pos) requires
  this.PeerConsistent
• class Car
• rep Seat s peer Seat s
• public void Adjust(Profile p) public void
  Adjust(Position p) requires this.PeerConsistent
  ? requires this.PeerConsistent
  ? p.PeerConsistent p.PeerConsistent
  expose (this) s.Move(p.SeatPosition)
  s.Move(p.SeatPosition)

o.Consistent ? o.owner.mutable ? o.valid
o.PeerConsistent ? o.owner.mutable ?
(?p p.owner o.owner ? p.valid)
25
Summary for aggregate objects
(?o o.mutable ? Inv(o))
(?o o.mutable ? o.owner.mutable)
rep T tinvariant this.t.f
check x.mutable
x.f E
26
Summary for aggregate objects
(?o o.mutable ? Inv(o))
(?o o.mutable ? o.owner.mutable)
x.valid false
x.valid true
expose (x)
check x.validcheck x.owner.mutable
check (?r r.ownerx ? r.valid)check Inv(x)
27
2. Immutable types
class String String SubString(int st, int len)
requires this.PeerConsistent class Car
String serialNumber public String
Year() requires this.PeerConsistent return
serialNumber.Substring(12, 4)
Note cannotuse rep,since Carcannot expectto
be thesole owner
28
Ever-peer-consistent (immutable) objects
Points to ownerMutable objectValid
objectImmutable object
29
Summary for immutable types
(?o Immutable(typeof(o)) ? o.PeerConsistent)
Immutable class M T f class C M
m invariant this.m.f
check x.mutable
x.f E
30
Summary for immutable types
(?o Immutable(typeof(o)) ? o.PeerConsistent)
x.valid false
x.valid true
expose (x)
check Immutable(typeof(x))check
check
31
Immutable is determined from static type (except
for object)

• Immutable class C extends B
• Immutable allowed on C if either
• B is Immutable or
• B is object
• Immutable required on C if
• B is Immutable

32
3. Subclasses

• class Car
• int speed invariant 0 speed
• class LuxuryCar extends Car Radio
  r invariant 6 r.CDCapacity

33
Owners are pairs

• To support subclasses with invariants, we change
  owners to be pairs
• (object reference, class frame)

34
Invariants and subclasses
class B extends A
B
class A
A
Object
Points to owner
35
Summary for subclasses
(?o,T (o,T).mutable ? InvT(o))
(?o,T (o,T).mutable ? o.owner.mutable)
class C extends B F f invariant this.f

check (x,C).mutable
x.f E
36
Summary for subclasses
(?o,T (o,T).mutable ? InvT(o))
(?o,T (o,T).mutable ? o.owner.mutable)
C x expose (x)
(x,C).valid false
(x,C).valid true
check (x,C).validcheck x.owner.mutable
check (?r r.owner(x,C) ? (?R
(r,R).valid))check InvC(x)
37
4. Additive invariants

• class Car
• int speed
• class LuxuryCar extends Car Radio
  r invariant speed gt 60 ? r.SoundBoostertrue
• overrides void SetSpeed(int kmph) expose
  (this) base.SetSpeed(kmph) if (speed gt
  60)

38
An additive frame is only as valid as its
subclass frames
class B extends A
B
class A
A
Object
Points to ownerMutable objectValid object
39
Summary for additive invariants
(?o,T (o,T).mutable ? InvT(o))
(?o,T (o,T).mutable ? o.owner.mutable)
class B extends A additive F f class C
extends B invariant this.f
check (?U U lt B ? (o,U).mutable)
x.f E
40
Summary for additive invariants
(?o,T (o,T).mutable ? InvT(o))
(?o,T (o,T).mutable ? o.owner.mutable)
(?o,T (o,T).transmut ? (o,T).mutable ? (?U
U lt T ? (o,U).transmut))
?
(x,C).valid true (x,C).transmut false
(x,C).valid false (x,C).transmut true
C x additive expose (x)
check (x,C).valid ? (?U U lt C ?
(x,U).transmut) check x.owner.mutable
?
check (?r r.owner(x,C) ? (?R
(r,R).valid))check InvC(x)
41
Object invariants in Spec

• Spec syntactically checks that invariants are
  admissible
• Ownership is specified with the Owned attribute
• We first supported only rep ownership relations
• peer relationships are often useful too
• we now use PeerConsistent as the default method
  precondition
• owners are set automatically on assignments of
  rep and peer fields
• An immutable class/interface is specified with
  Immutable
• We first supported only additive invariants in
  Spec
• non-additive invariants are easier to work with
• non-additive expose is now the default
• implementation restriction no further expose
  allowed on an object while a non-additive expose
  is in progress
• Additive methods (those that update the additive
  fields mentioned in additive invariants) require
  dynamic dispatch and use precondition Consistent

42
Summary and conclusions

• Spec programming system
• Rich object structures need specification and
  verification support
• simple invariants
• aggregate objects
• subclasses
• additive invariants
• immutable objects

• visibility-based invariants
• observer invariants
• static class invariants

download Specfrom here
http//research.microsoft.com/leino
http//research.microsoft.com/specsharp