Java Modeling Language

1. Java Modeling Language Research Seminars on Software Reuse Alan Kelon Oliveira de Moraes <alan@kelon.org>

2. Summary • Motivation • Design by ContractTM • Some Approaches for DbC • Java Modeling Language • JML Tools • Conclusions • References

3. Motivation

4. What is a component? • A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be independently deployed and is subject to third-party composition [Szyperski, 2002]

5. [Jézéquel and Meyer, 1997] Design by Contract: The Lessons of Ariane • On June 4, 1996, the maiden flight of the European Ariane 5 launcher crashed, about 40 seconds after takeoff. • $ 500 million software error • The exception was due to a floating point error during a conversion from a 64-bit floating-point value, representing the flight’s “horizontal bias,” to a 16-bit signed integer • You can’t blame management, the language, the design and the implementation • But you really have to blame reuse specification Reuse without a precise, rigorous specification mechanism is a risk of potentially disastrous proportions.

6. [Alvaro et al., 2005] Software Component Certification: A Survey • Software components certification is still immature

7. [Meyer, 1998] Providing Trusted Components to the Industry • Test, test, and retest • The implicit motto of much of the industry, is expensive and wasteful. • The Trusted Component Project1 proposes to apply a mix of formal and informal approaches: • Design by contract • Formal validation • OO and reuse techniques • Global public scrutiny • Extensive testing • Metrics efforts 1: http://www.trusted-components.org/

8. What we need? • Theory • Implementation • Tools

9. How to build/assure reliable components?

10. Design by ContractTM • Software Quality key concerns [Meyer, 1997]: • Reliability: correctness and robustness • Modularity: extendibility and reusability • Compatibility, portability, easy of use, efficiency, timeliness, economy, functionality • The key factor for reliability is Design by Contract. • Bolstad (2004) states: “DbC is a step on the road toward quality software”

11. Design by ContractTM • View the relationship between a supplier and its clients as a formal agreement, expressing each party’s rights and obligations [Meyer, 1997] • The term Design by Contract first appeared in 1986 [Meyer, 1986] (republished as [Meyer, 1992]), but formal verification dates back from 1969 [Hoare, 1969] • Brings the specification to source code and make it explicit

12. Correctness property • Correctness is a relative notion • A software is correct when it is in accordance with its specification • So is reasonable to use the word consistent software instead of correct software public void f(int y) { x = y + 1; } ? [Hoare, 1969]

13. Precondition and Postcondition • Let A be some operation, a correctness formula is an expression of the form {P} A {Q} • Any execution of A, starting in a state where P holds, will terminate in a state where Q holds E.g.: {x >= 9} x = x+ 5 {x>= 13} [Hoare, 1969]

14. Precondition and Postcondition [Meyer, 1997]

15. Class invariants • There is also a need for expressing global properties of the instances of a class, which must be preserved by all routines • Invariant rule • An assertion I is a correct class invariant for a class C if and only if it meets the following two conditions: • Every creation procedure of C, when applied to arguments satisfying its precondition in a state where the attributes have their default values, yields a state satisfying I. • Every exported routine of the class, when applied to arguments and a state satisfying both I and the routine’s precondition, yields a state satisfying I. [Meyer, 1997]

16. Assertion • An assertion is an expression involving some entities of the software, and stating a property that these entities may satisfy at certain stages of software execution • A runtime assertion violation is the manifestation of a bug in the software • A precondition violation is a bug in the client • A postcondition is a bug in the supplier [Meyer, 1997]

17. Non-redundancy principle • Under no circumstances shall the body of a routine ever test for the routine’s precondition -> No defensive programming • However Firesmith (1999) argues that defensive programming is the right approach to software development: • Decreases message coupling • Better supports encapsulation • Eliminates concurrency bugs • Eliminates redundant code by reusing precondition checking code. [Meyer, 1997]

18. Some Approaches for DbC

19. Eiffel • Eiffel language has a native language support for DbC • [Meyer, 1992a] Applying "Design by Contract“ • [Meyer, 1992b] Eiffel: the language • [Meyer, 1997] Object-oriented software construction

20. [Warmer and Kleppe, 1999] The object constraint language: precise modeling with UML. • OCL (Object Constraint Language) is a textual specification language to adorn UML diagrams and make a UML model far more semantically precise, detailed and thus productive (i.e., subject to automated processing leading to code). • Formal language with well-defined semantics based on set theory and first-order predicate logic • Object-oriented functional language: constructors syntactically combined using functional nesting and object-oriented navigation in expressions that take objects and/or object collections as parameters and evaluates to an object and/or an object collection as return value • Strongly typed language where all expression and sub-expression has a well-defined type that can be an UML primitive data type, a UML model classifier or a collection of these • Semantics of an expression defined by its type mapping • Declarative language that specifies what properties the software under construction must satisfy, not how it shall satisfy them • Side effect free language that cannot alter model elements, but only specify relations between them (some possibly new but not created by OCL expressions) • Pure specification language that cannot alone execute nor program models but only describe them • Both a constraint and query language for UML models • There is mappings from OCL to JML [Hamie, 2002]

21. iContract • [Kramer, 1998] iContract - The Java(tm) Design by Contract(tm) Tool. • Converts from special comments (@pre, @post, @invariant) to assertion check code that is inserted into the source-code. • OCL complaint • Supports universal and existential quantifiers in contract expressions. • It seems to be a good project, but a dead one

22. jContractor • [Karaorman et al., 1999] jContractor: A Reflective Java Library to Support Design by Contract. • Use of reflection to implement contract at runtime • Last release on 2003 • Source code available at http://jcontractor.sourceforge.net/

23. Contract4J • Uses Java 5 Annotations and/or a JavaBean-like convention • Generates AspectJ code, however Balzer and colleagues (2005) argues that aspects can’t implement contracts… • Source code available at http://www.contract4j.org/

24. Java Modeling Language

25. [Leavens and Cheon, 2005] Design by Contract with JML • JML is a formal behavioral interface specification language for Java that contains the essential notations used in DbC as a subset

26. [Leavens and Cheon, 2005] Design by Contract with JML • JML uses Java’s notation in assertions that it is easier for programmers to learn and less intimidating than languages that use special purpose mathematical notations.

27. [Leavens and Cheon, 2005] Design by Contract with JML • In JML, specifications are simple annotation comments [Leavens et al, 1999] • /*@ … @*/ • //@ • Unlike normal code comments, a formal specification in JML is (usually) machine checkable, and so can help with debugging.

28. JML Syntax [Leavens et al., 1998] [Leavens et al, 1999] [Leavens and Cheon, 2005] • Precondition • /*@ requires E; @*/ • Postcondition • /*@ ensures E; @*/ • Invariant • /*@ invariant E @*/ • Operation’s result • \result • Previous expression value • \old(E) • Using private fields in specifications • private /*@ spec_public @*/ Type property; • Fields not null • Private /*@ not_null @*/ Type property;

29. JML Syntax • Quantifiers • Iterating over all variables • (\forall T x; R(x); P(x)) • Verifying if exist variables • (\exists T x; R(x); P(x)) • Num of elements • \num_of

30. Special method annotations • Pure method: • /*@ pure *@/ ReturnType methodName() • A method is pure if it has no side-effects on the program’s state • Only pure methods are allowed in assertions • Helper method • private /*@ helper @*/ ReturnType methodName() • However, in JML, constructors and methods declared with the modifier helper are exempted from having to satisfy invariants. • Such helper methods must be private

31. An Example class Location { /** The pathname of a file. */ private /*@ spec_public non_null @*/ String path; /** Initializes this Location. * @param fullpath the full pathname * to the file. */ //@ requires fullpath != null; //@ assignable path; //@ ensures path.equals(fullpath); public Location(String fullpath) { path = fullpath; }

32. An Example /** Returns the associated file */ //@ ensures\result != null; private File getFile() { if (fileCache == null) { fileCache = new File(path); } return fileCache; }

33. An Example /** Is the file readable? */ //@ ensures\result == getFile().canRead(); public /*@ pure @*/ boolean readable() { return getFile().canRead(); } /** Copies this location's file * to the given location's file. */ /*@ requiresloc != null; @ ensures\result != null; @ ensures\result.equals(modTime()) @ && loc.modTime().equals(modTime()); @*/ public Date copyTo(Location loc) throws IOException {… }

34. [Burdy et al., 2003] An overview of JML tools and applications JML Tools

35. [Cheon and Leavens, 2002] A Runtime Assertion Checker for the Java Modeling Language (JML) • jmlc: JML Compiler, a.k.a. runtime assertion checker • “Compiles” the specification into a bytecode • It is slow • jmlrac runs programs compiled with jmlc • The most used tools • They don’t work with Java 5

36. [Flanagan et al., 2002] Extended static checking for Java. • Extended Static Checking/Java (ESC/Java) developed by Compaq • Helps a lot while programming • It is neither sound nor complete; that is, it neither warns about all errors, nor does it warn only about actual errors. • Eclipse plug-in didn’t work.

37. [Cheon and Leavens, 2002] A Simple and Practical Approach to Unit Testing: The JML and JUnit Way • jmlunit is a simple and effective technique that automates the generation of oracles for unit testing classes from specifications • The developer must only provide the data • [Tan and Edwards, 2004] Experiences evaluating the effectiveness of JML-JUnit testing • It doesn’t work with Java 5

38. [Raghavan, 2000] Design of a JML documentation generator • jmldoc is a javadoc specification generator • It is very slow • They don’t work with Java 5

39. Conclusions • Design by Contract is a worth technique to assure component quality • It is not easy to write postconditions • There are much research on JML, but it isn’t widely accepted in industry: • “So far we haven't had much industrial use, primarily because tool support isn't very good” Gary T. Leavens • Some users: Java Smart Cards in Europe, Fulcrum Microsystems, Apple's WebObjects frameworks, Kodak and Compaq • Among the existing DbC tools for Java, JML is the most suitable for use

40. References • Jézéquel, J. and Meyer, B. 1997. Design by Contract: The Lessons of Ariane. Computer 30, 1 (Jan. 1997), 129-130. • Alvaro, A.; de Almeida, E.S.; de Lemos Meira, S.R., "Software Component Certification: A Survey," Software Engineering and Advanced Applications, 2005. 31st EUROMICRO Conference on , vol., no.pp. 106- 113, 30-03 Aug. 2005 • Meyer, B. 1992. Applying "Design by Contract". Computer 25, 10 (Oct. 1992), 40-51. • Meyer, B. 1997. Object-oriented software construction (2nd ed.). Prentice-Hall, Inc. • Balzer, S., Eugster, P. and Meyer, B. 2005. Can aspects implement contracts?. In Proceedings of RISE Workshop (Rapid Integration of Software Engineering techniques), Heraklion, Crete, Greece, September 2005, to appear as Springer-Verlag Lecture Notes in Computer Science, 2005. • Meyer, B., Mingins, C., and Schmidt, H. 1998. Providing Trusted Components to the Industry. Computer 31, 5 (May. 1998), 104-105. • Kramer, R. 1998. iContract - The Java(tm) Design by Contract(tm) Tool. In Proceedings of the Technology of Object-Oriented Languages and Systems (August 03 - 07, 1998). TOOLS. IEEE Computer Society, Washington, DC, 295.

41. References • Karaorman, M., Hölzle, U., and Bruno, J. L. 1999. jContractor: A Reflective Java Library to Support Design by Contract. In Proceedings of the Second international Conference on Meta-Level Architectures and Reflection (July 19 - 21, 1999). P. Cointe, Ed. Lecture Notes In Computer Science, vol. 1616. Springer-Verlag, London, 175-196. • Leavens, G. T. and Cheon, Y. Design by Contract with JML, available at ftp://ftp.cs.iastate.edu/pub/leavens/JML/jmldbc.pdf • Firesmith, D. G. 1999. A Comparison of Defensive Development and Design by Contract. In Proceedings of the Technology of Object-Oriented Languages and Systems (August 01 - 05, 1999). TOOLS. IEEE Computer Society, Washington, DC, 258. • G. T. Leavens, A. L. Baker, and C. Ruby. JML: A notation for detailed design. In H. Kilov, B. Rumpe, and I. Simmonds, editors, Behavioral Specifications of Businesses and Systems, pages 175-188. Kluwer Academic Publishers, Boston, 1999. • Gary T. Leavens, Albert L. Baker, and Clyde Ruby. Preliminary Design of JML: A Behavioral Interface Specification Language for Java. Department of Computer Science, Iowa State University, TR #98-06-rev28, June 1998

42. References • Meyer, B. 1992 Eiffel: the language. Prentice-Hall, Inc. • Burdy, L., Cheon, Y., Cok, D., Ernst, M., Kiniry, J., Leavens, G.T., Rustan, K., Leino, M. and Poll, E., An overview of JML tools and applications. Workshop on Formal Methods for Industrial Critical Systems (FMICS), 2003. • Yoonsik Cheon and Gary T. Leavens. A Runtime Assertion Checker for the Java Modeling Language (JML). In Hamid R. Arabnia and Youngsong Mun (eds.), International Conference on Software Engineering Research and Practice (SERP '02), Las Vegas, Nevada. CSREA Press, June 2002, pages 322-328. • Yoonsik Cheon and Gary T. Leavens. A Simple and Practical Approach to Unit Testing: The JML and JUnit Way. In Boris Magnusson (ed.), ECOOP 2002 -- Object-Oriented Programming, 16th European Conference, Malaga, Spain, June 2002, Proceedings. Volume 2374 of Lecture Notes in Computer Science, Springer Verlag, 2002, pages 231-255.

43. References • Arun D. Raghavan. Design of a JML documentation generator. Technical Report 00-12, Iowa State University, Department of Computer Science, July 2000. • Bolstad, M., "Design by contract: a simple technique for improving the quality of software," Users Group Conference, 2004. Proceedings , vol., no.pp. 303- 307, 7-11 June 2004 • Cormac Flanagan, K. Rustan M. Leino, Mark Lillibridge, Greg Nelson, James B. Saxe, and Raymie Stata. Extended static checking for Java. In Proceedings of the 2002 ACM SIGPLAN Conference on Programming Language Design and Implementation (PLDI), volume 37(5) of SIGPLAN Notices, pages 234-245. ACM, May 2002. • Ali Hamie. Towards Verifying Java Realizations of OCL-Constrained Design Models Using JML. In 6th IASTED International Conference on Software Engineering and Applications, MIT, Cambridge, USA, 2002. • Warmer, J. and Kleppe, A. 1999 The object constraint language: precise modeling with UML. Addison-Wesley Longman Publishing Co., Inc. • Meyer, B. 1986. Design by Contract, Technical Report TR-EI-12/CO, Interactive Software Engineering Inc. • Hoare, C. A. 1969. An axiomatic basis for computer programming. Commun. ACM 12, 10 (Oct. 1969), 576-580. • Szyperski, C. 2002 Component Software: Beyond Object-Oriented Programming. 2nd. Addison-Wesley Longman Publishing Co., Inc.