Class-local object invariants

1. Class-local object invariants K. Rustan M. Leino Microsoft ResearchRedmond, WA, USA Angela Wallenburg Chalmers University of TechnologyGöteborg, Sweden 20 Feb 2008 ISEC 2008 Hyderabad, India

2. Program verification • Reasoning about object-oriented software involves object invariants • An object invariant describes the steady stateof an object • Because of call-backs, it is necessary to keep track of when object are in their steady state Demo 0

3. Program verification • Reasoning about object-oriented software involves object invariants • An object invariant describes the steady stateof an object • Because of call-backs, it is necessary to keep track of when object are in their steady state …but first, a word from our sponsor Spec# is a programming system that emphasizes program specifications. The Spec# language is a superset of the object-oriented .NET language C# 2.0. The system can be downloaded from Microsoft Research, http://research.microsoft.com/specsharp. Demo 0

4. Boogie methodology • Idea: Explicitly keep track of whether an object is in its steady state • Done by adding a special field inv to each object, such that: (o  o.inv  Inv(o)) • The inv field is changed by a special program statement: the expose block Demo 1

5. Subclassing • Each class can declare its own invariant • Each class gets its own inv field (o,T  o.invT  Inv(o, T)) • Expose block operates on one invT field Demo 2

6. Exposing subclasses • class T : object { … } • class U : T { … } • class V : U { … } • void M(U u) { • expose (u) { … } • expose ((T)u) { … } • } V U T object

7. Exposing subclasses • class T : object { … } • class U : T { … } • class V : U { … } • void M(U u) { • expose (u) { … } • expose ((T)u) { … } • } V U T object

8. Exposing subclasses • class T : object { … } • class U : T { … } • class V : U { … } • void M(U u) { • expose (u) { … } • expose ((T)u) { … } • } V U T object

9. Invariants that mention superclass fields • Modular verification: each “module” is verified independently, using only the specifications of other modules • To support modular verification, changes in a superclass must be consistent with all possible subclass invariants! admissible Demo 3

10. Inter-class invariants • class T : object { … } • class U : T { int x; … } • class V : U { int y; invariant x ≤ y; … } V • void M(U u) { • expose (u) { x++; } • } U T object

11. Additive behavior • By always exposing an entire suffix of class frames (one frame at a time), we can allow additive invariants • void M(U u) { • expose ((V)u) {expose (u) { x++; }} • } V U T Demo 4 object

12. Implementation • Allow both additive and local invariants and expose blocks • Only one local expose (per object) at a time o typeof(o) • “o is in steady state” ≡ o.inv = o.localinv = typeof(o) • if f is a field declared in class T with superclass S, then o.f is allowed to be modified if:(o.inv <: T)  o.localinv = S o.inv o.localinv object

13. Contributions • An integration of class-local and additive invariants • Experience results • >6000 lines of code • Class-local invariants are used exclusively • Our encoding of constructors use additive behavior, but perhaps this could be encoded differently

14. Aggregate objects • class U : T { rep C p; invariantp.x < 100; … } • class V : U { invariantp.x == 20; … } not supported V p U x T object

15. Summary and conclusions • Class-local invariants can be used together with additive invariants • Additive invariants are rarely used • Implemented in Spec# and its program verifier Boogie • Open issue: nice way to allow invariants to dereference fields declared in superclass Download Spec# and Boogie from here http://research.microsoft.com/specsharp