2. public class Animal implements Gendered { protected /*@ spec_public @*/ int age = 0; /*@ requires 0 < yrs; @ ensures age == \old(age + yrs); @*/ public void older(final int yrs) { age = age + yrs; } /* … */ } Example JML Specification field specification method behavior specification

3. Behavioral Interface Specification JML Specification Java Code Syntactic InterfaceFunctional Behavior

4. Behavioral Interface Specification /*@ requires 0 < yrs; @ ensures age == \old(age + yrs); @*/ public void older(final int yrs); public void older(final int yrs) { age = age + yrs; } public void older(final int yrs); requires yrs > 0; ensures age == \old(age + yrs);

5. Like … But for Java and… VDM, but –OO features Eiffel, but –Features for formal verification Spec#, but –Different invariant methodology –More features for formal verification

6. Open Research Community 23 groups, worldwide Over 130 papers See jmlspecs.org for detailsjmlspecs.org

7. Many Tools, One Language public class Animal implements Gendered { //... protected /*@ spec_public @*/ int age = 0; /*@ requires 0 <= a && a <= 150; @ ensures age == a; @ also @ requires a < 0; @ ensures age == \old(age); @*/ public void setAge(final int a) { if (0 <= a) { age = a; } } } ESC/Java2 Warnings Daikon Data trace file JML Annotated Java JACK, Jive, Krakatoa, KeY, LOOP Correctness proof Class file jmlc Unit tests jmlunit jmldoc Web pages Bogor Model checking XVP

8. How JML can Help Modular Specification, Verification Recording functional behavior for modulesRecording functional behavior for modules Specifying subtypes Verification with OO features

9. Problem 1: Recording Detailed Designs Precise, sequential behavior Hide details Approach Model fields Assertions

10. Model Fields, Ensures public interface Gendered { //@ model instance String gender; //@ ensures \result == gender.equals( “ female ” ); /*@ pure @*/ boolean isFemale(); }

11. Represents Clauses public class Animal implements Gendered, /* … */ { protected boolean gen; //@ in gender; /*@ protected represents gender @ <- (gen ? “ female ” : “ male ” ); @*/ //...

12. Use of Model Fields public class Animal implements Gendered, /* … */ { protected boolean gen; //@ in gender; /*@ protected represents gender @ <- (gen ? “ female ” : “ male ” ); @*/ public /*@ pure @*/ boolean isFemale() { return gen; } //...

13. Correctness with Model Fields gender : “female” true gen : true represents isFemale’s code isFemale’s specification ==

14. Requires Clauses public class Animal implements Gendered, /* … */ { protected boolean gen; //@ in gender; /*@ protected represents gender @ <- (gen ? “ female ” : “ male ” ); @*/ //@ requires g.equals(“female”)||g.equals(“male”); //@ ensures gender.equals(g); public Animal(final String g) { gen = g.equals(“female”); }

15. Problem Hide field names Subtypes add fields Data group Membership by in clauses Contains fields used in represents Data Groups and Assignable gender gen in another g1 in g2 in... assignable gender

16. Pure Methods public /*@ pure @*/ boolean isFemale() { /* … */ } Can use in assertions Must satisfy: assignable \nothing; May not: –Assign existing (non-local) locations –Perform input/output

17. Assignable is a Shorthand assignable gender; ensures gender.equals(g); means ensures \only_assigned(gender) && gender.equals(g);

18. Model of Method Specifications public interface T { //@ requires pre ; //@ ensures post ; void m() ; } T ⊳ (pre, post)

19. Model of Method Specifications output post-state input pre-state pre post m()

20. spec_public Shorthand Instead of: //@ public model int age; protected int _age = 0; //@ in age; //@ protected represents age <- _age; Write: protected /*@ spec_public @*/ int age = 0;

21. Type Specifications: Invariants import java.util.*; public class Patient extends Animal { //@ public invariant 0 <= age && age <= 150; protected /*@ spec_public @*/ List log; /*@ public invariant (\forall int i; @ 0 <= i && i < log.size(); @ log.get(i) instanceof String); @*/ // …

22. Invariants Hold in visible states –Method pre- & post-, Constructor post- states

23. Initially public class Patient extends Animal { //... protected /*@ spec_public @*/ List log; //@ public initially log.size() == 0; True in constructor post-states Basis for datatype induction

24. History Constraints [LW94] public class Patient extends Animal { //... /*@ public constraint @ \old(log.size()) <= log.size(); @ public constraint @ (\forall int i; @ 0 <= i && i < \old(log.size()); @ log.get(i).equals(\old(log.get(i)))); @*/

25. History Constraints Relate pre-states and post-states Inductive step for datatype induction

26. Problem 2: Specifying Subtypes Avoid repetition (Force behavioral subtyping) Approach Specification Inheritance –Fields, type specificationsFields, type specifications –Method specification casesMethod specification cases

27. Multiple Inheritance NormalSetAge Animal ExceptionalSetAge Age Gendered

28. Age and NormalSetAge public interface Age { //@ model instance int age; } public interface NormalSetAge implements Age { /*@ requires 0 <= a && a <= 150; @ ensures age == a; @*/ public void setAge(final int a); }

29. ExceptionalSetAge public interface ExceptionalSetAge implements Age { /*@ requires a < 0; @ ensures age == \old(age); @*/ void setAge(final int a); }

30. What about Animal? It’s both Should obey both specifications NormalSetAge Animal ExceptionalSetAge

31. Join of Specification Cases pre′ post && post′ pre && pre′ pre post

32. requires 0 <= a && a <= 150; ensures age == a; also requires a < 0; ensures age == \old(age); means requires (0 age == a) && (\old(a age == \old(age)) ; Join of Specification Cases, ‘also’

33. Join of Specification Cases, ⊔ S If T ′ ⊳ (pre′, post′ ), T ⊳ (pre, post ), S ≤ T′, S ≤ T, then (pre′, post′ ) ⊔ S (pre, post ) = (p, q) where p = pre′ || pre and q = (\old(pre′ ) ==> post′ ) && (\old(pre) ==> post ) and S ⊳ (p, q)

34. Inheritance of Type Specifications Obeyed by all subtypes: Invariants Initially clauses History constraints

35. Invariants: Obeyed by Subtypes Not a Sugar [LW94] Animal Patient Tortoise invariant 0 <= age && age <= 150; FemalePatient

36. Declared in T (without inheritance): added_inv T invariant added_hc T history constraint added_init T initially predicate m ’s specification Other Notations supers(T ) = {U | T  U } methods( T ) = { m | m declared in T  T } Model of Inheritance T ’s Added Specifications added_spec T m

37. Methods: for all m  methods(supers(T)) = ⊔ T { | U  supers(T) } Invariant: ext_inv T = ⋀ { added_inv U | U  supers(T) } History constraint: ext_hc T = ⋀ { added_hc U | U  supers(T) } Initially: ext_init T = ⋀ { added_init U | U  supers(T) } Specification Inheritance’s Meaning: Extended Specification of T ext_spec T m added_spec U m

38. Invariant Inheritance public class FemalePatient extends Patient { //@ public invariant gender.equals( “ female ” ); // … } Extended invariant: added_inv Gendered && added_inv Animal && added_inv Patient && added_inv FemalePatient

39. Invariant Inheritance public class FemalePatient extends Patient { //@ public invariant gender.equals( “ female ” ); // … } Extended invariant: true && true && 0 <= age && age <= 150 && (\forall int i; 0 <= i && i < log.size(); log.get(i) instanceof String) && gender.equals( “ female ” )

40. Invariant Inheritance public class FemalePatient extends Patient { //@ public invariant gender.equals( “ female ” ); // … } Extended invariant: 0 <= age && age <= 150 && (\forall int i; 0 <= i && i < log.size(); log.get(i) instanceof String) && gender.equals( “ female ” )

41. Method Specification Inheritance: Supertype’s added_spec public interface NormalSetAge implements Age { /*@ requires 0 <= a && a <= 150; @ ensures age == a; @*/ public void setAge(final int a); } public interface ExceptionalSetAge implements Age { /*@ requires a < 0; @ ensures age == \old(age); @*/ void setAge(final int a); }

42. Method Specification Inheritance: Subtype’s added_spec public class Patient extends Animal { // … protected /*@ spec_public @*/ boolean ageDiscount = false; //@ in age; /*@ also @ requires 0 ageDiscount; @*/ public void setAge(final int a) { super.setAge(a); if (65 <= age) { ageDiscount = true; } }

43. = ⊔ Patient {,, } Method Specification Inheritance: Extended Specification ext_spec Patient setAge added_spec ExceptionalSetAge setAge added_spec Patient setAge added_spec NormalSetAge setAge

44. requires 0 ageDiscount; Method Specification Inheritance: Extended Specification

45. requires 0 ageDiscount; Use of \same

46. requires 0 ageDiscount; Meaning of \same

47. Problem 3: Verification with OO features Subtyping Dynamic Dispatch Approach [LN06] Supertype abstraction Validity:Validity –Assumptions about Invariants, etc.,Assumptions about Invariants, etc., –Behavioral subtypingBehavioral subtyping Behavioral subtyping from specification inheritanceBehavioral subtyping from specification inheritance

48. Supertype Abstraction Reasoning about dynamic dispatch: Gendered e = (Gendered)elems.next(); if (e.isFemale()) { //@ assert e.gender.equals( “ female ” ); //... } Supertype abstraction: Static type of e is Gendered Use specification from Gendered

49. Static Type’s Specification public interface Gendered { //@ model instance String gender; //@ ensures \result == gender.equals( “ female ” ); /*@ pure @*/ boolean isFemale(); }

50. Supertype Abstraction Reasoning about dynamic dispatch: Gendered e = (Gendered)elems.next(); if (e.isFemale()) { //@ assert e.gender.equals( “ female ” ); //... } Supertype abstraction: Static type of e is Gendered Use specification from Gendered

51. Supertype Abstraction in General Use static type’s specifications to reason about: Method calls, Invariants, History constraints, Initially predicates

52. Supertype Abstraction in General T o = /* create a new object */; //@ assume o.ext_init T && o.ext_inv T ; /* … */ //@ assert ; o.m (); //@ assume ; //@ assume o.ext_inv T && o.ext_hc T ; o.ext_pre T m o.ext_post T m

53. Supertype Abstraction for Initially Predicates Given: public class Patient extends Animal { //... protected /*@ spec_public @*/ List log; //@ public initially log.size() == 0; } Verify: Patient p; if (B) { p = new Patient( “ male ” ); } else { p = new FemalePatient(); } //@ assert p.log.size() == 0;

54. Supertype Abstraction’s Soundness Valid if: Invariants etc. hold as needed (in pre-states), andInvariants etc. hold as needed Each subtype is a behavioral subtype

55. assert Pre; assume Pre && Inv; assert Post && Inv; assume Post; Assumption about Invariants

56. Invariant Methodology Potential problems: Representation exposure Reentrance Relevant invariant semantics [M ü l02,MPHL06]: Ownership type system Re-establish invariant when call Guarantees: invariant holds at start of method

57. Initially Predicates, History Constraints Similar problems? Similar solutions?

58. T o = /* create a new object */; //@ assume o.ext_init T && o.ext_inv T ; /* … */ //@ assert ; o.m (); //@ assume ; //@ assume o.ext_inv T && o.ext_hc T ; Validity of Supertype Abstraction: Client (Supertype) view o.ext_pre T m o.ext_post T m

59. T o = new T′ (); //@ assert o.ext_init T′ && o.ext_inv T′ ; /* … */ //@ assume ; o.m (); //@ assert ; //@ assert o.ext_inv T′ && o.ext_hc T′ ; Validity of Supertype Abstraction: Implementation (Subtype) View o.ext_post T′ m o.ext_pre T′ m

60. Definition. Suppose T′ ≤ T. Then T′ is a strong behavioral subtype of T if and only if: for all instance methods m in T, ⊒ T′ and whenever this has type T′ : ext_inv T′  ext_inv T, ext_hc T′  ext_hc T, and ext_init T′  ext_init T. Behavioral Subtyping for JML ext_spec T′ m ext_spec T m

61. Method Specification Refinement with respect to T′ Notation: (pre′, post′ ) ⊒ T′ (pre, post )

62. Method Specification Refinement with respect to T′ Definition: Suppose T′ ≤ T, and T ′ ⊳ (pre′, post′ ), T ⊳ (pre, post ) specify m then (pre′, post′ ) ⊒ T′ (pre, post ) if and only if for all calls of m on a subtype of T′, every correct implementation of (pre′, post′ ) satisfies (pre, post )

63. Refinement with respect to T′ pre post

64. Refinement with respect to T′ pre post pre′

65. Refinement with respect to T′ pre post pre′ post′

66. Proving Method Refinements Theorem 1. Suppose T′ ≤ T, and T ′ ⊳ (pre′, post′ ), T ⊳ (pre, post ) specify m. Then (pre′, post′ ) ⊒ T′ (pre, post ) if and only if: Spec(T ′ )  pre && (this instanceof T ′ )  pre′, and Spec(T ′ )  \old( pre && ( this instanceof T ′ ))  ( post′  post ).

67. Refinement of Assignable Clauses When T′ ≤ T, and assignable L ′ in T ′.m assignable L in T.m Can prove: Spec(T ′ )  \old( pre && ( this instanceof T ′ ))  (\only_assigned(L ′ )  (\only_assigned( L )). Subtype’s frame more restrictive. Datagroups matter

68. Making Behavioral Subtyping Automatic Specification inheritance must make behavioral subtypes –Methods –Invariants –Initally –History constraints

69. also Makes Refinements Theorem 2. Suppose \old is monotonic. Suppose T′ ≤ T, and T ′ ⊳ (pre′, post′ ), T ⊳ (pre, post ) specify m. Then (pre′, post′ ) ⊔ T′ (pre, post ) ⊒ T′ (pre, post ).

70. Proof Using Theorem 1 Preconditions: pre && (this instanceof T ′ )  pre  (pre || pre) Postconditions: Assume \old(pre && (this instanceof T ′ )), hence \old(pre). (\old(pre) ==> post)) && (\old(pre ==> post))  \old(pre) ==> post)  post

71. also Makes Refinements pre′ post && post′ pre && pre′ pre post post′

72. Specification Inheritance Forces Behavioral Subtyping Theorem 3. Suppose T′ ≤ T. Then the extended specification of T′ is a strong behavioral subtype of the extended specification of T. Proof: Use Theorem 2 and definition of extended specification.

73. Discussion Every subtype inherits Every subtype is a behavioral subtype –Not all satisfiable –Supertype must allow refinement

74. Unsatisfiable Refinements pre′ post && post′ pre && pre′ pre post post′

75. Unrefinable Binary Method Specification /*@ also @ ensures obj instanceof Gendered @ ==> (\result @ == gender.equals( @ ((Gendered)obj).gender)); @*/ public /*@ pure @*/ boolean equals(/*@ nullable @*/ Object obj); Says only gender matters Refinements can’t use other attributes

76. Unrefinable Binary Method Specification (f,f)(m,m)(f,m)(m,f) true false

77. Better, Refinable Binary Method Specification /*@ also @ ensures obj instanceof Gendered @ ==> (\result @ ==> gender.equals( @ ((Gendered)obj).gender)); @*/ public /*@ pure @*/ boolean equals(/*@ nullable @*/ Object obj); Says gender must be equal Refinements can use other attributes

78. Better, Refinable Binary Method Specification (f,f)(m,m)(f,m)(m,f) true false Allowed result

79. Extension Subtype Example public abstract class Dog extends Animal { public static final int D2PY = 7; private /*@ spec_public @*/ int dogAge = 0; //@ in age; //@ ensures \result == dogAge; public int getDogAge() { return dogAge; } public void setAge(final int a) { super.setAge(a); dogAge = D2PY*age; } }

80. Related Work Work with Naumann [LN06], basis for this talk. Proved exact conditions on behavioral subtyping for validity of supertype abstraction Liskov and Wing [LW94] “subtype requirement” like supertype abstraction. Abstraction functions implicit in JML. Several program logics for Java, [Mül02] [Par05] [Pie06] [PHM99], use supertype abstraction. Work with Dhara [DL96] proved specification inheritance forces behavioral subtyping.

81. More Related Work Wills’s Fresco [Wil92] introduced specification inheritance. Wing’s dissertation [Win83] combined specification cases like also. Eiffel [Mey97] has behavioral subtyping and a form of specification inheritance. America [Ame87] [Ame91] first proved soundness with behavioral subtyping. See survey with Dhara [LD00].

82. Future Work Warn if attempt to strengthen preconditions [FF01]. Warn if subtype is unsatisfiable. Methodology for –history constraints and –initially predicates

83. Conclusions Supertype abstraction allows modular reasoning. Supertype abstraction is valid if: –methodology enforced, and –subtypes are behavioral subtypes. JML’s also makes refinements. Specification inheritance in JML forces behavioral subtyping. Supertype abstraction automatically valid in JML.

84. Acknowledgments Thanks to David Naumann, William Weihl, Krishna Kishore Dhara, Cesare Tinelli, Don Pigiozzi, Barbara Liskov, Jeannette Wing, Yoonsik Cheon, Al Baker, Clyde Ruby, Tim Wahls, Patrice Chalin, Curtis Clifton, David Cok, Joseph Kiniry, Rustan Leino, Peter Müller, Arnd Poetzsch-Heffter, Erik Poll, and the rest of the JML community. Join us at... jmlspecs.org

85. Future Work on JML Tools –Java 1.5 support –Eclipse support Documentation Concurrency support Semantic details Theorem proving tie-ins, Static analysis tie-ins Inference of specifications Tools that give more benefits

86. My Future Work (outside JML) Aspect-oriented software development –Language design and semantics (ownership, etc.) –Specification and Verification Extending the reach of formal methods –Security related topics –Time and space Blending –Annotation-based specification –Static analysis –Type systems Helping programmers

87. Reasoning without Supertype Abstraction? Case analysis: Case for each potential dynamic type Can exploit dynamic type’s specifications

88. Case Analysis + Supertype Abstraction Case Analysis + Supertype Abstraction Use instanceof for case analysis Downcast, use supertype abstraction /*@ requires p instanceof Doctor @ || p instanceof Nurse; @*/ public boolean isHead(final Staff p) { if (p instanceof Doctor) { Doctor doc = (Doctor) p; return doc.getTitle().startsWith( “ Head ” ); } else { Nurse nrs = (Nurse) p; return nrs.isChief(); } }

89. References [Ame87] Pierre America. Inheritance and subtyping in a parallel object-oriented language. In Jean Bezivin et al., editors, ECOOP ’87, European Conference on Object-Oriented Programming, Paris, France, pages 234–242, New York, NY, June 1987. Springer-Verlag. Lecture Notes in Computer Science, volume 276. [Ame91] Pierre America. Designing an object-oriented programming language with behavioural subtyping. In J. W. de Bakker, W. P. de Roever, and G. Rozenberg, editors, Foundations of Object-Oriented Languages, REX School/Workshop, Noordwijkerhout, The Netherlands, May/June 1990, volume 489 of Lecture Notes in Computer Science, pages 60–90. Springer-Verlag, New York, NY, 1991. [BCC+05] Lilian Burdy, Yoonsik Cheon, David R. Cok, Michael D. Ernst, Joeseph R. Kiniry, Gary T. Leavens, K. Rustan M. Leino, and Erik Poll. An overview of JML tools and applications. International Journal on Software Tools for Technology Transfer, 7(3):212–232, June 2005. [DL96] Krishna Kishore Dhara and Gary T. Leavens. Forcing behavioral subtyping through specification inheritance. In Proceedings of the 18th International Conference on Software Engineering, Berlin, Germany, pages 258–267. IEEE Computer Society Press, March 1996. A corrected version is ISU CS TR #95-20c, rlhttp://tinyurl.com/s2krg. [FF01] Robert Bruce Findler and Matthias Felleisen. Contract soundness for object-oriented languages. In OOPSLA ’01 Conference Proceedings, Object-Oriented Programming, Systems, Languages, and Applications, October 14-18, 2001, Tampa Bay, Florida, USA, pages 1–15, October 2001. [Hoa69] C. A. R. Hoare. An axiomatic basis for computer programming. Communications of the ACM, 12(10):576–580,583, October 1969. [Hoa72] C. A. R. Hoare. Proof of correctness of data representations. Acta Informatica, 1(4):271–281, 1972. [LD00] Gary T. Leavens and Krishna Kishore Dhara. Concepts of behavioral subtyping and a sketch of their extension to component-based systems. In Gary T. Leavens and Murali Sitaraman, editors, Foundations of Component-Based Systems, chapter 6, pages 113–135. Cambridge University Press, 2000. [Lei98] K. Rustan M. Leino. Data groups: Specifying the modification of extended state. In OOPSLA ’98 Conference Proceedings, volume 33(10) of ACM SIGPLAN Notices, pages 144–153. ACM, October 1998. [LN06] Gary T. Leavens and David A. Naumann. Behavioral subtyping, specification inheritance, and modular reasoning. Technical Report 06-20b, Department of Computer Science, Iowa State University, Ames, Iowa, 50011, September 2006. [LW94] Barbara H. Liskov and Jeannette M. Wing. A behavioral notion of subtyping. ACM Transactions on Programming Languages and Systems, 16(6):1811–1841, November 1994. [Mey97] Bertrand Meyer. Object-oriented Software Construction. Prentice Hall, New York, NY, second edition, 1997. [MPHL06] Peter Müller, Arnd Poetzsch-Heffter, and Gary T. Leavens. Modular invariants for layered object structures. Science of Computer Programming, 62(3):253– 286, October 2006. [Mül02] Peter Müller. Modular Specification and Verification of Object-Oriented Programs, volume 2262 of Lecture Notes in Computer Science. Springer-Verlag, 2002. [Par05] Matthew J. Parkinson. Local reasoning for Java. Technical Report 654, University of Cambridge Computer Laboratory, November 2005. The author’s Ph.D. dissertation. [PHM99] A. Poetzsch-Heffter and P. Müller. A programming logic for sequential Java. In S. D. Swierstra, editor, European Symposium on Programming (ESOP ’99), volume 1576 of Lecture Notes in Computer Science, pages 162–176. Springer-Verlag, 1999. [Pie06] Cees Pierik. Validation Techniques for Object-Oriented Proof Outlines. PhD thesis, Universiteit Utrecht, 2006. [SBC92] Susan Stepney, Rosalind Barden, and David Cooper, editors. Object Orientation in Z. Workshops in Computing. Springer-Verlag, Cambridge CB2 1LQ, UK, 1992. [Wil92] Alan Wills. Specification in Fresco. In Stepney et al. [SBC92], chapter 11, pages 127–135. [Win83] Jeannette Marie Wing. A two-tiered approach to specifying programs. Technical Report TR-299, Massachusetts Institute of Technology, Laboratory for Computer Science, 1983.