Outline Java Modeling Language (JML)

1

Java Modeling Language (JML)and ESC/Java

Marco ZennaroCS 294-3 Fall 2004

10/27/2004 JML and ESC/Java 2 2

Outline

• What is the Java Modeling Language?• JML tutorial;• JML tools;

– ESC/JAVA;

• References;• JML / ESC/Java Demos;


Outline


– ESC/JAVA;



Formal specification languages

• C.S. have invented many formal languages to model software and specify properties about these models with techniques to verify these properties;

• Formal languages guarantee:– Precision (no ambiguity);– Certainty (modulo modeling errors);– Automation (automatic verification tools);

Erik Poll. Introduction to JML, a notation to formally specifying Java programs. 2004


Java Modeling Language

• A formal behavioral interface specification language for Java:– to specify behaviour of java classes;– to record design/implementation decisions;

• By adding assertions to Java source code:– Preconditions, postconditions, invariants,

etc…

Gary T. Leavens, Yoonsik Cheon. Design by Contract with JML, 2004Erik Pool. Introduction to JML […], 2004


Java Modeling Language

• Design by contract for Java:– More expressive than Eiffel;– Easier to use for the programmer than

Larch:• Uses Java boolean expression (extended with

some operators);

Gary T. Leavens, Yoonsik Cheon. Design by Contract with JML, 2004Erik Pool. Introduction to JML, 2004

2


JML history

• Created at Iowa University (Leavens, Cheon);

• Soon became an international effort:– University of Nijmegen (Poll, Van den

Berg);– HP (f.k.a. Compaq) SRC group (Leino,

Nelson); – Kodak (Cok);


Design by Contract (DBC)

A way of recording:– Details of method responsibilities– Avoiding constantly checking arguments– Assigning blame across interfaces

The caller must ensure precondition holds while the called must ensure postconditions on exit;

The caller may assume postcondition while the called may assume preconditions;

Gary T. Leavens, Yoonsik Cheon. Design by Contract with JML, 2004


Pre, Postconditions and Invariants

Definition – A method’s precondition says what must be true to

call it.– A method’s normal postcondition says what is true

when it returns normally (i.e., without throwing an exception).

– A method’s exceptional postcondition says what is true when a method throws an exception.

– An invariant is a property that is always true of an object’s state (when control is not inside the object’s methods).


Contracts as Documentation

• For each method say:– What it requires (if anything), and– What it ensures.

• Contracts are:– More abstract than code,– Often machine checkable, so can help with

debugging, and– Machine checkable contracts can always be

up-to-date.


Abstraction by contracts

• A contract can be satisfied in many ways:– a method can have many implementation

satisfying the contract;– Different performances (time, space, etc);

• A contract abstracts from the implementation details;

• Hence we can change implementations later.


Modularity

• Typical OO code is modular;…source.close();dest.close();getFile().setLastModified(loc.modTime().getTime());…

• We should be able to take advantage of the code modularity even in specifying / prove code properties.

3


Rules for Reasoning

• Caller code– Must work for every implementation that satisfies the

contract, and– Can thus only use the contract (not the code!), i.e.,

• Must establish precondition, and • Gets to assume the postcondition

• Called code– Must satisfy contract, i.e.,

• Gets to assume precondition• Must establish postcondition

– But can do anything permitted by it.


Contracts and Intent

• Code makes a poor contract, because can’t separate:– What is intended (contract) – What is an implementation decision

E.g., if deposit_into_account() rounds to the cent, can that be changed in the next release?

• By contrast, contracts:– Allow vendors to specify intent,– Allow vendors freedom to change details, and– Tell clients what they can count on.


Outline


– ESC/JAVA;



Introduction to JML

• JML specifications are contained in annotations, which are comments like:

//@ …

or

/*@ …@ …@*/

At-signs (@) on the beginning of lines are ignored within annotations.


Informal Description

• An informal description looks like:(* some text describing a property *)

– It is treated as a boolean value by JML, and– Allows

• Escape from formality, and• Organize English as contracts.

public class Account {/*@ requires (* x is positive *);@ ensures \result >= 0 &&@ (* \result is the updated balance after the deposit*) @*/

public static double deposit_into_account(double x) { … }}


Formal Specifications

• Formal assertions are written as Java expressions, but:– Cannot have side effects

• No use of =, ++, --, etc., and• Can only call pure methods.

– Can use some extensions to Java:

Syntax Meaning

\result result of method calla ==> b a implies ba <== b b implies aa <==> b a iff ba <=!=> b !(a <==> b)\old(E) value of E in pre-state

4


Example (pre and post cond.)

/*@ requires x >= 0.0;ensures JMLDouble.approximatelyEqualTo(\result,

\old(balance) + x, eps);@*/

public static double deposit_into_account(double x) { … }

caller

called

Obligations Rights

Passes non-negativenumber

Gets updated balance

Update balanceAdding x to it

Assumes argumentis non-negative


Example (ex. postcond.)

/*@ requires x >= 0.0;ensures JMLDouble.approximatelyEqualTo(balance,

\old(balance) + x, eps);exsures (Exception e)

\old(x) > DEPOSIT_LIMIT &&balance == \old(balance) &&e.getReason() == AMOUNT_TOO_BIG;

@*/public static double deposit_into_account(double x) throws…

Trade-off between preconditions and exceptional postconditions;


Example (invariant)// File: Account.java

public class Account {private /*@ spec_public non_null @*/ String accountNumber;private /*@ spec_public @*/ double balance;

//@ public invariant !accountNumber.equals(“”) && balance >= 0;

//@ ensures \result == balance;public double getBalance();

/*@ ensures balance >= 0 && balance == \old(balance + deposit);exsures (Exception e)x > DEPOSIT_LIMIT && balance == \old(balance)

&& e.getReason() == AMOUNT_TOO_BIG;@*/

public void deposit_into_account(int kgs);

/*@ requires !n.equals(“”);ensures n.equals(accountNumber) && balance == 0;

@*/public Account(/*@ non_null @*/ String n);

}


Quantifiers

• JML supports several forms of quantifiers– Universal and existential (\forall and \exists)– General quantifiers (\sum, \product, \min, \max)– Numeric quantifier (\num_of)

(\forall Student s; juniors.contains(s); s.getAdvisor() != null)

(\forall Student s; juniors.contains(s) ==> s.getAdvisor() != null)


Model Variables

Are specification only variables– Like domain-level constructs– Given value only by represents clauses:– Information hiding;– Data abstraction;

name abstract (model)

fullName concrete (real)

represented by


class Counter {model n: int;

method Increment()modifies only n;ensures old(n) + 1 = n;

method Decrement()modifies only n;ensures old(n) = n + 1;

}

Example

5


class Counter {model n: int;private a: int;private b: int;representation n is a – b;

method Increment()modifies only n;ensures old(n) + 1 = n;

{ a := a + 1 }method Decrement()

modifies only n;ensures old(n) = n + 1;

{ b := b + 1 }}

Example


Outline

• What is the Java Modeling Language?• Introduction to JML syntax and

semantic;• JML tools;

– ESC/JAVA;

• References;• JML / ESC/Java Demo;


Tools for JML

• JML compiler (jmlc/jmlrac):– perform JML checks at runtime;– low-cost;

• Extended static checker (ESC/Java2):– prove JML assertions at compile time;– higher cost;– possible for small program or subsystems;

• Etc…


ESC vision

Increased programmer productivity and program reliability through increased rigor:– Record design decisions;– Utilize automatic checking;– Detect errors and improve maintainability;

R. Leino, Hoare-style program verification, May 2004


ESC vision

• Improve the current software engineering process developing practical tools;

• It is NOT program verification, it is like a type checker:– its warnings are intended to be interpreted by the

author of the program;– It does not find all the errors, but reduce the

process cost finding some of them early;– “We are interested in failed proof only”;

D. Detlefs, R. Leino, G.Nelson, J. Saxe. Extended Static Checking,1998.


ESC vision

Take a program annotated with assertions. Consider a tool capable of:

• Automatically check if the assertions are always true;

• Statically without any user input;• Reason about non-trivial properties (not

just type-correctness);

J. Kiniri, ESC/Java 2, extended static checking for Java, 2004

6


ESC

• An Extended Static Checker tries to prove the correctness of specifications, at compile-time, fully automatically, but:

• ESC/Java is neither sound or complete but

• It find lots of bugs quickly;



ESC implementation

D. Detlefs, R. Leino, G. Nelson, J. Saxe, Extended Static Checking, 1998


ESC unsoundness

Sources of unsoundness:• User-controlled:

– Use of “assume”, “no warn” and “axiom”pragmas;

• Un-controlled:– Interdependent pragmas;– Loops;– Aliasing;



• Built at Compaq SRC– ESC/Java 2 built by Joe Kiniry (U. Nijmegen) and

David Cok (Kodak)

• Input: Java + user-supplied annotations– annotations are subset of JML;

• Annotation language captures programmer design decisions

• Powered by program semantics and automatic theorem proving

• Performs modular checking

ESC/Java


Outline


– ESC/JAVA;



JML References

Papers:– Gary T. Leavens and Yoonsik Cheon. Design by Contract

with JML, 2004;– Lilian Burdy, Yoonsik Cheon, David Cok, Michael Ernst, Joe

Kiniry, Gary T. Leavens, K. Rustan M. Leino, and Erik Poll. An overview of JML tools and applications, 2003;

– Gary T. Leavens, K. Rustan M. Leino, Erik Poll, Clyde Ruby, and Bart Jacobs. JML: notations and tools supporting detailed design in Java, 2000; Presentations:

People:– Gary Leavens @ Iowa university;– Erik Pol @ University of Nijmegen;

Web-sites:– http://www.jmlspecs.org;

7


ESC/JAVA 2 references

Papers:– D. Detlefs, R. Leino, G. Nelson, J. Saxe.

Extended Static Checking.1998.– R. Leino, G. Nelson, J.Saxe. ESC/Java User's

Manual. 2000

People:– Rustan Leino @ University of Washington;– David Cok @ Kodak;– Joe Kiniri @ University of Nijmegen.


Outline


– ESC/JAVA;


Documents

Outline Java Modeling Language (JML)