You Say 'JML' ? Wikipedia (En)
Total Page:16
File Type:pdf, Size:1020Kb
You say 'JML' ? Wikipedia (en) PDF generated using the open source mwlib toolkit. See http://code.pediapress.com/ for more information. PDF generated at: Mon, 06 Jan 2014 09:58:42 UTC Contents Articles Java Modeling Language 1 Design by contract 5 Formal methods 10 References Article Sources and Contributors 15 Image Sources, Licenses and Contributors 16 Article Licenses License 17 Java Modeling Language 1 Java Modeling Language The Java Modeling Language (JML) is a specification language for Java programs, using Hoare style pre- and postconditions and invariants, that follows the design by contract paradigm. Specifications are written as Java annotation comments to the source files, which hence can be compiled with any Java compiler. Various verification tools, such as a runtime assertion checker and the Extended Static Checker (ESC/Java) aid development. Overview JML is a behavioural interface specification language for Java modules. JML provides semantics to formally describe the behavior of a Java module, preventing ambiguity with regard to the module designers' intentions. JML inherits ideas from Eiffel, Larch and the Refinement Calculus, with the goal of providing rigorous formal semantics while still being accessible to any Java programmer. Various tools are available that make use of JML's behavioral specifications. Because specifications can be written as annotations in Java program files, or stored in separate specification files, Java modules with JML specifications can be compiled unchanged with any Java compiler. Syntax JML specifications are added to Java code in the form of annotations in comments. Java comments are interpreted as JML annotations when they begin with an @ sign. That is, comments of the form //@ <JML specification> or /*@ <JML specification> @*/ Basic JML syntax provides the following keywords requires Defines a precondition on the method that follows. ensures Defines a postcondition on the method that follows. signals Defines a postcondition for when a given Exception is thrown by the method that follows. signals_only Defines what exceptions may be thrown when the given precondition holds. assignable Defines which fields are allowed to be assigned to by the method that follows. pure Declares a method to be side effect free (this shorthand for assignable \nothing). invariant Defines an invariant property of the class. loop_invariant Defines a loop invariant for a loop. also Java Modeling Language 2 Combines specification cases and can also declare that a method is inheriting specifications from its supertypes. assert Defines a JML assertion. spec_public Declares a protected or private variable public for specification purposes. Basic JML also provides the following expressions \result An identifier for the return value of the method that follows. \old(<expression>) A modifier to refer to the value of the <expression> at the time of entry into a method. (\forall <decl>; <range-exp>; <body-exp>) The universal quantifier. (\exists <decl>; <range-exp>; <body-exp>) The existential quantifier. a ==> b a implies b a <== b a is implied by b a <==> b a if and only if b as well as standard Java syntax for logical and, or, and not. JML annotations also have access to Java objects, object methods and operators that are within the scope of the method being annotated and that have appropriate visibility. These are combined to provide formal specifications of the properties of classes, fields and methods. For example, an annotated example of a simple banking class may look like public class BankingExample { public static final int MAX_BALANCE = 1000; private /*@ spec_public @*/ int balance; private /*@ spec_public @*/ boolean isLocked = false; //@ public invariant balance >= 0 && balance <= MAX_BALANCE; //@ assignable balance; //@ ensures balance == 0; public BankingExample() { this.balance = 0; } //@ requires 0 < amount && amount + balance < MAX_BALANCE; //@ assignable balance; Java Modeling Language 3 //@ ensures balance == \old(balance) + amount; public void credit(final int amount) { this.balance += amount; } //@ requires 0 < amount && amount <= balance; //@ assignable balance; //@ ensures balance == \old(balance) - amount; public void debit(final int amount) { this.balance -= amount; } //@ ensures isLocked == true; public void lockAccount() { this.isLocked = true; } //@ requires !isLocked; //@ ensures \result == balance; //@ also //@ requires isLocked; //@ signals_only BankingException; public /*@ pure @*/ int getBalance() throws BankingException { if (!this.isLocked) { return this.balance; } else { throw new BankingException(); } } } Full documentation of JML syntax is available in the JML Reference Manual [1]. Java Modeling Language 4 Tool support A variety of tools provide functionality based on JML annotations. The Iowa State JML tools provide an assertion checking compiler jmlc which converts JML annotations into runtime assertions, a documentation generator jmldoc which produces Javadoc documentation augmented with extra information from JML annotations, and a unit test generator jmlunit which generates JUnit test code from JML annotations. Independent groups are working on tools that make use of JML annotations. These include: • ESC/Java2 [2], an extended static checker which uses JML annotations to perform more rigorous static checking than is otherwise possible; • Daikon [3], a dynamic invariant generator; • KeY, which provides a theorem prover with a JML front-end; • Krakatoa [4], a static verification tool based on the Why [5] verification platform and using the Coq proof assistant; • JMLeclipse [6], a plugin for the Eclipse integrated development environment with support for JML syntax and interfaces to various tools that make use of JML annotations. • Sireum/Kiasan [7], a symbolic execution based static analyzer which supports JML as a contract language. • JMLUnit [8], a tool to generate files for running JUnit tests on JML annotated Java files. • TACO [9], open source program analysis tool that statically checks the compliance of a Java program against its Java Modeling Language specification. References • Gary T. Leavens and Yoonsik Cheon. Design by Contract with JML; Draft tutorial. • Gary T. Leavens, Albert L. Baker, and Clyde Ruby. JML: A Notation for Detailed Design; in Haim Kilov, Bernhard Rumpe, and Ian Simmonds (editors), Behavioral Specifications of Businesses and Systems, Kluwer, 1999, chapter 12, pages 175-188. • Gary T. Leavens, Erik Poll, Curtis Clifton, Yoonsik Cheon, Clyde Ruby, David Cok, Peter Müller, Joseph Kiniry, Patrice Chalin, and Daniel M. Zimmerman. JML Reference Manual (DRAFT), September 2009. HTML [10] External links • JML website [11] References [1] http:/ / jmlspecs. org/ jmlrefman/ jmlrefman_toc. html [2] http:/ / secure. ucd. ie/ products/ opensource/ ESCJava2/ [3] http:/ / pag. csail. mit. edu/ daikon/ [4] http:/ / krakatoa. lri. fr/ [5] http:/ / why. lri. fr/ [6] http:/ / jmleclipse. projects. cis. ksu. edu/ [7] http:/ / www. sireum. org/ ?q=node/ 21/ [8] http:/ / www. eecs. ucf. edu/ ~leavens/ JML2/ docs/ man/ jmlunit. html [9] http:/ / www. dc. uba. ar/ inv/ grupos/ rfm_folder/ TACO [10] http:/ / www. jmlspecs. org/ jmlrefman/ jmlrefman_toc. html [11] http:/ / www. jmlspecs. org/ Design by contract 5 Design by contract Design by contract (DbC), also known as contract programming, programming by contract and design-by-contract programming, is an approach for designing software. It prescribes that software designers should define formal, precise and verifiable interface specifications for software components, which extend the ordinary definition of abstract data types with preconditions, postconditions and invariants. These specifications are referred to as "contracts", in accordance with a conceptual metaphor with the conditions and obligations of business contracts. "Design by Contract" is a registered trademark of Eiffel Software in the United States, and should not be confused with the general design approach. Microsoft calls their design-by-contract programming implementation "Code Contracts".[1] History The term was coined by Bertrand Meyer in connection with his design of the Eiffel programming language and first described in various articles starting in 1986[2][3][4] and the two successive editions (1988, 1997) of his book Object-Oriented Software Construction. Eiffel Software applied for trademark registration for Design by Contract in December 2003, and it was granted in December 2004.[5][6] The current owner of this trademark is Eiffel Software.[][7] Design by contract has its roots in work on formal verification, formal specification and Hoare logic. The original contributions include: • A clear metaphor to guide the design process • The application to inheritance, in particular a formalism for redefinition and dynamic binding • The application to exception handling • The connection with automatic software documentation Description The central idea of DbC is a metaphor on how elements of a software system collaborate with each other on the basis of mutual obligations and benefits. The metaphor comes from business life, where a "client" and a "supplier" agree on a "contract" that defines for example that: • The supplier must provide a certain product (obligation) and is entitled to expect that the client has paid its fee (benefit). • The client must pay the fee (obligation) and is entitled to get the product (benefit). • Both parties must satisfy certain obligations, such as laws and regulations, applying to all contracts. Similarly, if a routine