1. Modular Specification of Frame Properties in JML Peter Müller Arnd Poetszch Heffter Gary T. Leavens Encapsulation Seminar Tel Aviv University 2005 Presented by Uri Juhasz

2. 2 Modular Specification and Verification For modular verification a program is divided into modules. Every module is divided into an interface and an implementation. modules are similar to packages but they are closed – we reason about the whole module. A module can import other modules but the import relation is acyclic. –program: a set of modules closed under the import relation. Verifying a module means proving the implementation fulfills the interface – i.e. every method fulfills it’s interface. Rules are defined for combining and verifying modules so that once a each module has been verified separately any legal combination of these modules is correct without any additional verification – this is achieved by underspecification: the only predicates that are provable on a module are those correct for all possible extensions. Once this is accomplished we can verify any module separately and only publish the interface – this is useful for modular verification, reuse, reimplementation, optimization and implementation hiding.

3. 3 Modular Specification and Verification A module has 5 interfaces : public ⊆ protected ⊆ default-access ⊆ private ⊆ private-protected ⊆ Each module m is verified assuming the correctness of the appropriate interfaces of all imported modules (public and protected). Every method C.f in module m is verified assuming the appropriate interfaces of all imported modules and the appropriate interface of each class in m, and some module-wide properties – –Private for C. –Private-protected for C’s bases in m. –Default-access for classes in m. –Protected for C’s bases in other modules. –Public for classes from imported modules.

4. 4 Axiomatic Semantics for a Java subset We deal with a subset of sequential Java. The semantics are defined by a sequent calculus on statements – for example:

5. 5 Sequent calculus for Axiomatic Semantics – Logical Rules

6. 6 Modular Specification in JML public class Complex { … public Double R(){…} public Double I(){…} public void setR(Double){…} public void setI(Double){…} public void set( Double r, Double i ){…} /*@ requires c != null *@ ensures \result.R() == R() * c.R() - I() * c.I() *@ ensures \result.I() == R() * c.I() + I() * c.R() */ public Complex multiply(Complex c) { /*return new Complex( R() * c.R(), - I() * c.I(), R() * c.I() + I() * c.R() ) */ c.setR( 1.0 ); c.setI(0.0); return clone(); } Formal pre-post specification of multiply Not the intended implementation - possible because we can modify c.

7. 7 Behavioural subtyping module a; class A{ /*@requires r @ensures q */ int f(){…} } module b; import a; class B extends A{ /*@requires r` @ensures q` */ int f(){..} } module c; import a; void h(A o) { assume(r); o.f(); assert(q) } Here we don ’ t have B ’ s specification so we must verify against A.f. In Object Oriented Languages, because of dynamic binding, If a method B.f overrides A.f then B.f must comply with the interface specification for A.f: –pre(A.f) => pre(B.f) –post(B.f)=>post(A.f) void g() { B b = new B(); assume( r’ ); h( B ); assert( q’ ); }

8. 8 Frame Property The frame property of a function/method is the set of memory locations it may modify and, more importantly, the locations it may NOT modify. void f( Integer x, String s ) { if ( x < 0 ) x = -x; assert( x ≥ 0 ); s.toUpperCase(); assert( x ≥ 0 ); } class String2 extends String { String2(Integer xx){ x = xx; … } void toUpperCase(){ x = -1; } … private Integer xx; } void g() { Integer x = -1; String2 s = new String2(x); f( x, s ); } This assertion is broken because x is statically aliased in s.

9. 9 Modular Specification of Frame Properties class A { public Integer a,b; /*@ requires c,d != null *@ ensures \result == c+d *@ ensures a == c+d *@ ensures d == c+\old(d) *@ modifies a, d */ public Integer f( /*%readonly%*/ Integer c, Integer d){ Integer i = c+d; a = i; d = i; b = i; c = i; return i; } Disallowed by the specification

10. 10 The modifies Clause The frame property of functions/methods is usually specified with some version of the modifies clause: The modifies clause is necessary for allowing insert to modify the variable head class List{ /*@ modifies head*/ public void insert( Object o ){ if ( head == null ) head = new Node( o ) else … } protected Node head; };

11. 11 Frame properties and behavioural subtyping Frame properties must also be inherited and can only be strengthened through inheritance: module a; class A{ public a, b; /*@modifies a */ public int f(){ a = 1;} } module b; import a; class B extends A{ /*@modifies a,b */ public int f(){ b = 1;} } module c; import a; void g(A o) { assume(o.b=0); o.f(); assert(o.b=0) } This is broken because modifies(B.f) ⊈ modifies(A.f)

12. 12 Problems with modular specification in Object Oriented Programs Representation exposure Extended state Modularity

13. 13 Problem: Representation Exposure class List{ /*@ modifies head*/ public void insert( Object o ){ if ( head == null ) head = new Node( o ) else … } protected Node head; }; The protected field head must be modified in insert, but we can ’ t refer to it in the public specification as it is protected.

14. 14 Problem: Extended State class List{ /* @modifies head */ public void insert()… public int getSize() … private Node head; }; class SizedList extends List{ public void insert(o){ super.insert(o); size++; } public int getSize() … private int size; }; Because of behavioural subtyping modifies(SizedList.f) ⊆ modifies(List.f) But then we can’t modify size.

15. 15 Abstract Fields In order to solve the problem of representation exposure in interface specifications we use abstract fields with explicit dependencies. Abstract fields are a function from the concrete state representation of an object to an abstract domain. Abstract fields have access modifiers like concrete fields and can only appear in specifications accordingly. The value if each abstract field is defined (def-clause) as an abstraction function of concrete and abstract locations. The dependencies of an abstract field are declared explicitly (dep-clause) and create a proof obligation relating to the def-clause (if all dependees are unchanged the value of the abstraction function is unchanged).

16. 16 Representation Exposure - Abstract Fields class List{ /*@public abstract Sequence value */ /*@protected depends value ← head */ /*@protected represents value ← head.value */ … /*@modifies val*/ public void insert( Object o ){ if ( head == null ) head = new Node( o ) else … } protected Node head; }; Here we can specify List.value in the public modifies clause because it is public and we can verify the assignment to List.head because the dependency is protected.

17. 17 Extended State – Abstract Fields class List{ /*@public abstract Sequence val */ /*@private depends val ← head */ /*@private represents val ← head.val */ … /*@modifies val*/ /* @modifies head */ public void insert()… public int getSize() … protected Node head; }; class SizedList extends List{ public: /*@private depends val← size */ public void insert(o){ super.insert(o); size++; } public int getSize() … private: int size; }; Here we can modify size because we have added the dependency for val.

18. 18 Problem: Modularity module a; class List{ /*@public abstract Sequence value */ /*@ modifies value */ void insert(){ … } } Here Set.value is not in the modifies clause of List.insert so List.insert is not allowed to modify it. module b; import a; class Set{ private List l; /*@public abstract Set value */ /*@private depends value ← l.value*/ /*@private represents value ← … */ /*@modifies value */ public void insert(/*%readonly%*/ Object o ) { if ( !l.has(o) ) l.insert(o); }

19. 19 The Universe Type System A refined ownership model. Each objects is in exactly one universe. Universes are hierarchical where each universe includes all of it ’ s descendants. Each object is the owner of it ’ s own universe (it ’ s representation) but is not part of it. The universe invariant: All read-write references into a universe pass through it ’ s owner. Reference come in 4 flavours: readonly references – can point to any object. representation references – can only point to members of the representation of this – the universe owned by this. peer references – can only point to members of the universe of this ’ s owner. Type representation reference – allow limited representation sharing - won ’ t be discussed.

20. 20 The Universe Type System prev next val prev next val prev next val prev next val first last list Iterator readonly peer rep Here all nodes belong to the representation of the list and so hold peer references. The nodes hold readonly references to the actual values and the iterator holds a readonly reference to the nodes and a peer reference to the list.

21. 21 Relevant Locations The current universe when executing an instance method is the universe to which this belongs. A relevant location for a method execution is any location (concrete or abstract) in the current universe or any of it’s descendants. A method may only have read-write references to objects in the current universe or it’s immediate descendant. The modifies clause for methods states which relevant locations a method may modify – other relevant locations are unmodified and any non-relevant location may be modified.

22. 22 Modularity - Relevant Locations module a; class List{ /*@public abstract Sequence value */ /*@ modifies value */ void insert(){ … } } module b; import a; class Set{ private /*%rep%*/ List l; /*@public abstract Set value */ /*@private depends value ← l.value*/ /*@private represents value ← … */ /*@modifies value */ public void insert(/*%readonly%*/ Object o ) { if ( !l.has(o) ) l.insert(o); } Here Set.value is not relevant for the call to List.insert because universe(Set.l) <universe(Set.value) so List.insert is allowed to modify it.

23. 23 Locality Abstract fields X.f of an object X can only depend on locations that belong to X or it’s representation. module a. class A{ private /*%readonly%*/ Integer a; /*@public abstract Integer abs */ /*@private depends abs ← a.value*/ public A( Integer _a ){ a= _a; } } Here we cannot know that a.abs is modified because the depends clause is not accessible. module b import a; class B{ private /*% rep %*/ A a; private Integer b; public void f(){ A a = new A(b); assume( a.abs = 0 ); b = 1; assert( a.abs = 0 ); }

24. 24 Authenticity The declaration of an abstract field X.f that depends on a field Y.g must be accessible in the declaration of any method that may modify g.

25. 25 Authenticity module b; import a; class B{ protected A a; /*@public abstract Integer absB */ /*@protected depends absB ← a.absA*/ /*@modifies absA */ public void f(){ a = 1; } /*@modifies absA */ public void set( A i ){ a = i; } } module c; import b; class C{ protected /*%rep%*/ B b1,b2; void f(){ /*%rep%*/ A a = new A( 0 ); b1.setA( a ); b2.setA( a ); assume( b1.absB=0 ); b2.f(); assert( b1.absB=0 ); } Here b1.absB is modified although it is relevant and not specified as modified by b2.f - because B.absB is not accessible in the declaration of A.f. There are 2 ways to fix this : 1.Disallowing the sharing of B.a – declaring B.a as rep A. 2.Defining B in the same module as A. module a; class A{ private int a; /*@public abstract Integer absA */ /*@private depends abs ← int*/ /*@modifies absA */ public void f(){ a = 1; } }

26. 26 Visibility Every dependency of X.f on Y.g must be declared in every scope in which they are both visible. module a; class A{ private /*%rep%*/ Integer a,b; /*@public abstract Integer absA */ /*@private depends absA ← a*/ /*@public abstract Integer absB */ /*@private depends absB ← b*/ /*@modifies absA */ public void f(){ … } } module b; class B extends A{ /*@private depends absA ← b*/ public void f(){ b=1; } } module c; import a; void f( A a ) { assume( a.absB = 0 ); a.f(); assert( a.absB = 0 ); } Here a.absB is modified although it is relevant and not specified as modified by a.f - because the dependency of absA on a b is not visible in A.f().

27. 27 Modularity Theorem The 3 requirements for modularity can be checked statically and locally. A method m can only modify a relevant location if it is specified in it’s modifies clause. When verifying a method m, for a method invocation o.n(), the verifier of n is responsible for verifying non-modification of relevant locations and the verifier of m is responsible for proving non-modification of non-relevant locations. Modular soundness is proven – if for a program p = ∪M i each M i is verified and p is well formed then p is correct – all methods of p (including main) comply with their pre-post specifications including the modifies clause and all invariants are kept.

28. 28 Conclusion Modular soundness is formally defined for a general modular OO language. Modular soundness is proven for a Java subset with it’s specification language. The specification language is expressive enough for most functional needs (FOL). A type system for alias control is integrated into the specification language and proven type-safe.

29. 29 Shortcomings Type system –Implementation sharing in the type system is only possible through readonly reference downcasts that are hard to verify modularly. –Objects cannot be moved between universes. The authenticity requirement limits some implementation patterns – especially dependencies on imported types. The logic is not modularly complete – some theorems that can be proven on a whole program cannot be proven modularly. The logic is not decidable and some properties ((non)reachability, type-correct downcasts,… ) can only be proven by deduction if at all and not by decidable local algorithms. The Java subset does not include genericity and exceptions. Termination is not dealt with (only parital correctness).

30. 30 The End