Reasoning about object structures with Spec# K. Rustan M. Leino Microsoft Research, Redmond, WA Joint work with: Mike Barnett, Ádám Darvas, Manuel Fähndrich, Peter Müller, Wolfram Schulte, Herman Venter, Angela Wallenburg UNSW, Sydney, Australia, 16 Jan 2007

Software engineering problem Building and maintaining large software systems that are correct Building and maintaining large software systems that are correct

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

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

Spec# Experimental mix of contracts and tool support Experimental mix of contracts and tool support Aimed at experienced developers who know the high cost of testing and maintenance Aimed at experienced developers who know the high cost of testing and maintenance Superset of C# Superset of C# –non-null types –pre- and postconditions –object invariants Tool support Tool support –more type checking –compiler-emitted run-time checks –static program verification C# contracts everywhere type checking static verification into the future run-time checks degree of checking, effort familiar

Spec# demo

Spec# program verifier architecture V.C. generator automatic theorem prover verification condition Spec# “correct” or list of errors Spec# compiler MSIL (“bytecode”) bytecode translator Boogie PL inference engine Spec# program verifier (aka Boogie)

class C : Object { int x; C() { … } virtual int M(int n) { … } static void Main() { C c = new C(); c.x = 12; int y = c.M(5); } } Example translation: OO things

BoogiePL translation of OO things (0)

BoogiePL translation of OO things (1)

BoogiePL translation of OO things (2)

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

0. When do invariants hold? class Car { int speed; int windResistance; invariant windResistance == K * speed * speed; public Car() { speed = 0; windResistance = 0; } public void SetSpeed(int kmph) { speed = kmph; windResistance = K * speed * speed; }

0. When do invariants hold? class Car { int speed; int windResistance; invariant windResistance == K * speed * speed; public Car() { speed = 0; windResistance = 0; } public void SetSpeed(int kmph) { speed = kmph; windResistance = K * speed * speed; }

0. When do invariants hold? class Car { int speed; int windResistance; invariant windResistance == K * speed * speed; public Car() { speed = 0; windResistance = 0; } public void SetSpeed(int kmph) { speed = kmph; P( ); windResistance = K * speed * speed; } Invariant temporarily violated —what if P calls back?

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

The heap (the object store)

Mutable Valid

To mutable and back: expose class Car { int speed; int windResistance; invariant windResistance == K * speed * speed; … public void SetSpeed(int kmph) requires this.valid; { expose (this) { speed = kmph; windResistance = K * speed * speed; } } changes this from valid to mutable changes this from mutable to valid can update speed, because this.mutable

Summary for simple objects: (  o o.mutable  Inv(o)) x.f = E; check x.mutable invariant … this.f …; o.mutable  ¬ o.valid

Summary for simple objects: (  o o.mutable  Inv(o)) expose (x) { … } x.valid := falsex.valid := true check x.validcheck Inv(x) o.mutable  ¬ o.valid

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); }

Ownership Points to owner

Ownership domains Points to owner

Ownership domains Points to owner x y z x owns y and z y and z are components in the representation of x y and z are peers

Points to owner Mutable object Valid object An object is only as valid as its components

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

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  requiresthis.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)

Summary for aggregate objects: (  o o.mutable  Inv(o)) x.f = E; check x.mutable rep T t; invariant … this.t.f …; (  o o.mutable  o.owner.mutable)

x.valid := false Summary for aggregate objects: expose (x) { … } x.valid := true check x.valid check x.owner.mutable check (  r r.owner=x  r.valid) check Inv(x) (  o o.mutable  Inv(o)) (  o o.mutable  o.owner.mutable)

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: cannot use rep, since Car cannot expect to be the sole owner

Points to owner Mutable object Valid object Immutable object Ever-peer-consistent (immutable) objects

Summary for immutable types: (  o Immutable(typeof(o))  o.PeerConsistent) x.f = E; check x.mutable [Immutable] class M { T f; … } class C { M m; invariant … this.m.f …;

x.valid := false Summary for immutable types: expose (x) { … } x.valid := true check ¬ Immutable(typeof( x)) check … check … (  o Immutable(typeof(o))  o.PeerConsistent)

Immutable is determined from static type (except for object) [Immutable] class C extends B { … } [Immutable] allowed on C if either [Immutable] allowed on C if either –B is [Immutable] or –B is object [Immutable] required on C if [Immutable] required on C if –B is [Immutable]

3. Subclasses class Car { int speed; invariant 0 ≤ speed; … } class LuxuryCar extends Car { Radio r; invariant 6 ≤ r.CDCapacity; … }

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

Invariants and subclasses class A { … } class B extends A { … } Points to owner Object A B

Summary for subclasses: (  o,T (o,T).mutable  Inv T (o)) x.f = E; check (x,C).mutable class C extends B { F f; invariant … this.f …; (  o,T (o,T).mutable  o.owner.mutable)

(x,C).valid := false Summary for subclasses: C x; … expose (x) { … } (x,C).valid := true check (x,C).valid check x.owner.mutable check (  r r.owner=(x,C)  (  R (r,R).valid)) check Inv C (x) (  o,T (o,T).mutable  Inv T (o)) (  o,T (o,T).mutable  o.owner.mutable)

4. Additive invariants class Car { int speed; … } class LuxuryCar extends Car { Radio r; invariant speed > 60  r.SoundBooster=true; overrides void SetSpeed(int kmph) { expose (this) { base.SetSpeed(kmph); if (speed > 60) { … } } } }

An additive frame is only as valid as its subclass frames class A { … } class B extends A { … } Points to owner Mutable object Valid object Object A B

Summary for additive invariants: (  o,T (o,T).mutable  Inv T (o)) x.f = E; check (  U U <: B  (o,U).mutable) class B extends A { additive F f; … } class C extends B { invariant … this.f …; (  o,T (o,T).mutable  o.owner.mutable)

Summary for additive invariants: (  o,T (o,T).mutable  Inv T (o)) (  o,T (o,T).mutable  o.owner.mutable) (  o,T (o,T).transmut  (o,T).mutable  (  U U <: T  (o,U).transmut)) C x; … additive expose (x) { … } (x,C).valid := true (x,C).transmut := false check (x,C).valid  (  U U <: C  (x,U).transmut) check x.owner.mutable check (  r r.owner=(x,C)  (  R (r,R).valid)) check Inv C (x) ≠ ≠ (x,C).valid := false (x,C).transmut := true

Object invariants in Spec# Spec# syntactically checks that invariants are admissible Spec# syntactically checks that invariants are admissible Ownership is specified with the [Owned] attribute Ownership is specified with the [Owned] attribute We first supported only rep ownership relations 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] An immutable class/interface is specified with [Immutable] We first supported only additive invariants in Spec# 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 Additive methods (those that update the additive fields mentioned in additive invariants) require dynamic dispatch and use precondition Consistent

Summary and conclusions Spec# programming system Spec# programming system BoogiePL intermediate verification language BoogiePL intermediate verification language Rich object structures need specification and verification support Rich object structures need specification and verification support –simple invariants –aggregate objects –subclasses –additive invariants download Spec# from here –visibility-based invariants –immutable objects –observer invariants –static class invariants –…