Verification of object-oriented programs with invariants

1. Verification of object-oriented programswith invariants Mike Barnett, Robert DeLine, Manuel Fahndrich, K. Rustan M. Leino, Wolfram Schulte ECOOP 2003 workshop on Formal Techniques for Java-like Programs Encapsulation Seminar TAU 2005 Presented by Yossi Peery

2. Agenda • Introduction • Motivation and Background • Object Invariants and Information Hiding • Solution • Basic Methodology Concepts • Adding Components and Subclasses • Modifies Clause and Dynamic Dispatching • Examples • Conclusion

3. Why Use Object Invariants • Definition: “A relation on an object’s data that the programmer intends for to hold” • Detect and prevent • Data corruption errors • Misuse of the object data • Formal methods allow automatic static verification of program invariants

4. Background • Hoare’s 1972 “Proof of correctness of data representations” • Eiffel • Pioneer Design by Contract technique • Dynamically checks invariants at run-time • Peter Muller 2001 • An OO language providing useful guarantees about when object invariants hold • Uses “Universe Type System” as an ownership model • Object invariants modeled by a boolean function on the object’s data

5. Reentrancy Problem public method P (…) { … M (); … }

6. Invariant Misconception • General View: An invariant is an implicit post-condition on every constructor and an implicit pre- and post-condition on every public method • Misconception: • Callers of an object’s methods do not need to establish the implicit pre-condition of the invariant. • It is sufficient to restrict modifications of the invariant to methods of an object and establish it before the method ends

7. Explicit Invariant Condition • It will not be possible to call M from a function P that doesn’t ensure its invariant. Or, • It will not be possible to call a function P that ensure the invariant from the middle of M

8. Problem of Information Hiding • Invariants are conditions on the internal representation of objects • Explicit pre- and post-conditions are a breach of good information hiding • Conflict between revealing implementation details and the need for clients to know whether the object invariant holds • Same problem exists for modifies clause

9. Basic Methodology Concept • Provide an explicit representation of when object invariants are known to hold • Add special public field st to every object. o.st = Invalid  o is invalid o.st = Valid  o is valid • An object’s invariant holds whenever the object is valid • Restrictions • st can appear only in routine specifications • st can be modified only by special new statements: pack & unpack • Objects are allocated with o.st = Invalid

10. Basic Methodology Concept • InvT(o) : predicate to indicate that the invariant of object o of class T holds. Using class T from previous example:

11. Basic Methodology Concept

12. Restrictions and Validity • Object field updates can break invariant: • Field update statements: o.f := E • Permitted only where o.st = Invalid • InvT(o) can depend only on internal fields of o • If the above restrictions hold then the following is a program invariant: where o ranges over non-null objects of type T • Proof by induction over structure of program statements

13. Components • Objects are usually built in a hierarchy of layered abstractions • A “Buffered Input Stream” can be implemented in terms of a cache and a file reader objects • Program correctness may depend on relations between fields of an objects and fields of its components • Need to expend previous restrictions

14. Components • If t.f = u then update of u.g breaks T’s invariant • Need to make sure that: u.st = Invalid => t.st = Invalid t.st = Valid => u.st = Committed

15. Ownership • Committed state indicates Ownership • If t.f.st = Commited then t owns t.f • Creates hierarchy of owned objects • Use repmodifier to indicate that a field is a component: private rep f : U; • Object invariants can now depend on this.f0.f1.f2. … .g where fi are declared with the repmodifier

16. Components st : { Invalid , Valid, Committed} CompT(o) = { o.f : f is a rep field in T }

17. Components • Program Invariant: • Unique Ownership: • Ownership Transfer:

18. Subclasses • Object divided into class frames • Each frame can be valid or invalid • possible subsets • Consider only nonempty prefixes • { object } • { object, A } • { object, A, B }

19. New Encoding • Instead of st: • Special field inv holdstype of most derived valid class • Special field committed is boolean indicating if object is committed committed = TRUE => inv = type(o) • New objects of type T should return from theconstructor as: inv = T & !commited • Field updates of subclass allowed if object is “sufficiently unpacked” • Invariants may contain fields of subclasses

20. New Encoding T extends S ois any subclass ofT

21. Soundness Theorem The following are program invariants (ranges over non-null objects; <: is the subclass relationship) Proof shows the conditions are maintained for all actions that extend the quantification range or change values of object fields

22. Modifies Clause • Model access to an object field by changes to the program heap: • Heap is a global 2 dimensional array indexed by object references and field names • Location if o.f is modeled by Heap[o,f] • Modifies Clause contains a set of heap locations the routine is allowed to modify • Routines are allowed to allocate new objects and modify their state • Special field alloc denotes allocated objects

23. Modifies Clause • Post-condition for modifies clause W: • Innovation: allow every routine to modify fields of commited objects: • Implementation Hiding • Use special expression E.{ T } • T = { class name, type(o) for object-valued expression o } • Denotes all regular fields of object E declared in class T and its super classes

24. Dynamic Dispatch • pack and unpack statements need to specify which type they are unpacking • Need to state the exact value of inv as a precondition • Limits use of dynamic dispatching • Innovation: • Use special expression: inv = 1 • For caller 1 means type(this) • For implementation in class T, 1 means T • How can this be sound?

25. Dynamic Dispatch • Soundness: • For declaration of dynamic dispatched method M, introduce a procedure named M with specification: inv = type(this) • For implementation of M in class T introduce a procedure M@T with specification: inv = T • Body of procedure M looks at type of this and calls corresponding procedure M@type(this) • Body of M@T is like that of method M in T except that any call for super class, super.M(…) is replaced with M@S • Every class must supply an implementation for every dynamically dispatched methoddeclared in the class or its super class • Extend 1 for the modifies clause: E.{1}

26. Examples • Can be used as a super class or a component • Subclass implementation can modify all regular fields of super class.

27. Examples Constructor must copy char array

28. Examples Constructor can capture the reader

29. Examples • Lexer can relinquish the underlying reader • Reader must be relinquished in an uncommitted state • Implementation leaves Lexer in an inconsistent state so that GetToken can no longer be invoked

30. Conclusions • Programmer must be aware at which points an object invariant can be relied upon • Presented method that provides programmers with a flexible and precise way to specify their intensions about object invariants • Ownership method allows a single valid owner per object at a time but doesn’t confine object aliasing and allows multiple read access • Methodology allows for both static verification and dynamic checking

31. Current Work • Spec # • Extension of C# with method contracts • Compiler and static verifier tools integrate with visual studio .NET • Boogie • Spec# static program verifier • WebSite http://research.microsoft.com/foundations