1. Object Invariants in Specification and Verification 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, and Angela Wallenburg Invited talk, SBMF 2006, Natal, Brazil, 19 September 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 C# contracts everywhere type checking static verification into the future run-time checks degree of checking, effort familiar

6. Spec# demo

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

8. Object invariants 0.Simple objects 1.Aggregate objects 2.Subclasses 3.Additive invariants

9. 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; }

10. 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; } invariant is temporarily broken here P( ); what if P calls back into SetSpeed?

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

12. The heap (the object store)

13. Mutable Valid

14. expose statement 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 object from valid to mutable changes object from mutable to valid

15. Summary for simple objects: explicit representation of when invariants hold ( o o.mutable Inv(o)) expose (x) { … } check Inv(x) check x.valid x.valid := false x.mutable := true x.valid := true x.mutable := false

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

17. Ownership Points to owner

18. Ownership domains Points to owner

19. ( o o.mutable o.owner.mutable) Points to owner Mutable object Valid object

20. 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

21. 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) requiresthis.PeerConsistent requiresthis.PeerConsistent p.PeerConsistent; p.PeerConsistent; {{ expose (this) { s.Move(p.SeatPosition);s.Move(p.SeatPosition); } }} o.PeerConsistent o.owner.mutable ( p p.owner = o.owner p.valid) o.Consistent o.owner.mutable o.valid

22. Summary for aggregate objects: ownership domains ( o o.mutable o.owner.mutable) expose (x) { … } check ( r r.owner=x r.valid) check x.owner.mutable x.valid := false x.mutable := true x.valid := true x.mutable := false

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

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

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

26. Summary for subclasses: owners are pairs ( o,T (o,T).mutable o.owner.mutable) expose (x) { … } check x.owner.mutable (x,C).valid := false (x,C).mutable := true (x,C).valid := true (x,C).mutable := false check ( r r.owner=(x,C) r.valid) where x has static type C

27. 3. 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) { … } } } }

28. Additive invariants and subclasses class A { … } class B extends A { … } Points to owner Mutable object Valid object Object A B

29. Summary for additive invariants: consider invariant state of subclasses ( o,T (o,T).mutable ( S S <: T (o,S).mutable) additive expose (x) { … } check ( S S <: C S C (o,S).mutable) (x,C).valid := false (x,C).mutable := true (x,C).valid := true (x,C).mutable := false where x has static type C

30. 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 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

31. Summary and conclusions Spec# programming system Rich object structures need specification and verification support –simple invariants –aggregate objects –subclasses –additive invariants –visibility-based invariants –… http://research.microsoft.com/~leino http://research.microsoft.com/specsharp download Spec# from here