Overview The Java Modeling Language (Part 1) Related Work

Similar documents
The Java Modeling Language (Part 1)

Formale Entwicklung objektorientierter Software

Verifying Java Programs Verifying Java Programs with KeY

The Java Modeling Language (Part 2)

Verifying Java Programs Verifying Java Programs with KeY

JML Class Specifications The Java Modeling Language (Part 2) A Java Class

Verifying Java Programs with KeY

Advances in Programming Languages

The Java Modeling Language JML

JML tool-supported specification for Java Erik Poll Radboud University Nijmegen

JML. Java Modeling Language

Formal Specification and Verification

Introduction to JML David Cok, Joe Kiniry, and Erik Poll Eastman Kodak Company, University College Dublin, and Radboud University Nijmegen

Programming with Contracts. Juan Pablo Galeotti, Alessandra Gorla Saarland University, Germany

Java Modelling Language (JML) References

Program Verification (6EC version only)

Lecture 10 Design by Contract

Advances in Programming Languages

The JML Tool. Faculty of Engineering Pontificia Universidad Javeriana. The JML Tool p.1/23

JML. Outline. Métodos Formais em Engenharia de Software. MI, Braga these slides were prepared by adopting/adapting teaching material

Verifying Java Programs. Verifying Java Programs. The Krakatoa/Why Tool Suite

Verifying Java Programs

Formal Methods in Software Development

Assertions & Design-by-Contract using JML Erik Poll University of Nijmegen

Java Modelling Language (JML) References

Formal Specification and Verification

Formal Methods for Java

Checking Program Properties with ESC/Java

A Small Survey of Java Specification Languages *

Formal Methods for Java

Preliminary Design of JML:

Specifying and Verifying Programs (Part 2)

Rigorous Software Development CSCI-GA

JML and ESC/Java2 Homework Exercises

Canica: An IDE for the Java Modeling Language

Formal Methods for Java

Fundamentals of Software Engineering

Introduction to the Java Modeling Language

EXAMINATIONS 2009 MID-TERM TEST. COMP 202 / SWEN 202 Formal Methods of Computer Science / Formal Foundations of Software Engineering WITH ANSWERS

Preliminary Design of JML:

Java Modeling Language (JML)

Advances in Programming Languages

Static program checking and verification

Preliminary Design of JML:

Assertions, pre/postconditions

Testing, Debugging, and Verification

Integrating verification in programming languages

Preliminary Design of JML:

Practical introduction to Frama-C (without Mathematical notations ;-) )

Design by Contract and JML: concepts and tools

ESC/Java2 Warnings David Cok, Joe Kiniry, and Erik Poll Eastman Kodak Company, University College Dublin, and Radboud University Nijmegen

How the Design of JML Accommodates Both Runtime Assertion Checking and Formal Verification

Advanced JML Erik Poll Radboud University Nijmegen

Assertions. Assertions - Example

Formal Systems II: Applications

Verification Condition Generation

Formal Methods for Software Development

A Fitness Function to Find Feasible Sequences of Method Calls for Evolutionary Testing of Object-Oriented Programs

Class Libraries and Packages

Deductive Verification in Frama-C and SPARK2014: Past, Present and Future

Verifying JML specifications with model fields

Announcements. Specifications. Outline. Specifications. HW1 is due Thursday at 1:59:59 pm

Program Verification Using the Spec# Programming System

OOP Design by Contract. Carsten Schuermann Kasper Østerbye IT University Copenhagen

Design by Contract with JML

Jive/JML Generating Proof Obligations From JML Specifications

The Use of JML in Embedded Real-Time Systems

References: internet notes; Bertrand Meyer, Object-Oriented Software Construction; 10/14/2004 1

ESC/Java2 extended static checking for Java Erik Poll Radboud University Nijmegen

An introduction to formal specifications and JML. Invariant properties

Formal methods What are they? Uses Tools Application to software development

Discussion of Design Alternatives for JML Java 5 Annotations

ESC/Java 2. Checker for Java 2. Extended. Static. B y K ats man Andrey S oftware E ngineering S em inar

What This Course Is About Design-by-Contract (DbC)

Specification of a transacted memory for smart cards in Java and JML

Part II. Hoare Logic and Program Verification. Why specify programs? Specification and Verification. Code Verification. Why verify programs?

Formal Methods for Java

Formal Specification with the Java Modeling Language

Advances in Programming Languages

A Run-time Assertion Checker for Java using JML

An overview of JML tools and applications

A Java Reference Model of Transacted Memory for Smart Cards

FAKULTÄT FÜR INFORMATIK

Advanced JML. and more tips and pitfalls. David Cok, Joe Kiniry, and Erik Poll

Analysis of Software Artifacts

The Prototype Verification System PVS

Design-by-Contract (Dbc) Test-Driven Development (TDD)

Motivation. Correct and maintainable software Cost effective software production Implicit assumptions easily broken

Formal Methods for Software Development

Effective and Efficient Runtime Assertion Checking for JML Through Strong Validity

Recent Trends in OO Modelling Languages

Combining Design by Contract and Inference Rules of Programming Logic towards Software Reliability

Homework #1, on the class web pages later today

1. true / false By a compiler we mean a program that translates to code that will run natively on some machine.

hwu-logo.png 1 class Rational { 2 int numerator ; int denominator ; 4 public Rational ( int numerator, int denominator ) {

Testing Library Specifications by Verifying Conformance Tests

JUnit Testing Framework Architecture

III lecture: Contracts and Abstract Data Types. An obligation from last lecture... An obligation from last lecture... (2) January/February 2013

Code Contracts in C#

Runtime Checking for Program Verification Systems

Transcription:

Overview The Java Modeling Language (Part 1) Wolfgang Schreiner Wolfgang.Schreiner@risc.jku.at Research Institute for Symbolic Computation (RISC) Johannes Kepler University, Linz, Austria http://www.risc.jku.at Since 1999 by Gary T. Leavens et al. (Iowa State University). www.jmlspecs.org A behavioral interface specification language. Syntactic interface and visible behavior of a Java module (interface/class). Tradition of VDM, Eiffel, Larch/C++. Fully embedded into the Java language. Java declaration syntax and (extended) expression syntax. Java types, name spaces, privacy levels. JML annotations disguised as Java comments. //@... /*@... @... Wolfgang Schreiner http://www.risc.jku.at 1/36 Wolfgang Schreiner http://www.risc.jku.at 2/36 Related Work Related to/influenced by/derived from JML (selection). Spec# (Spec Sharp): C#. http://research.microsoft.com/en-us/projects/specsharp Plugin for Microsoft Visual Studio 2010. Static checking (non-null types), runtime assertion checking. Verification condition generator (Boogie) for various prover backends. ANSI/ISO C Specification Language (ACSL): C. http://frama-c.com/acsl.html Frama-C verifification framework with various prover backends. SPARK: Ada. http://www.adacore.com/sparkpro http://libre.adacore.com Verification condition generator and prover (SPADE Simplifier). Wolfgang Schreiner http://www.risc.jku.at 3/36 1. Basic JML 2. JML Tools 3. More Realistic JML Wolfgang Schreiner http://www.risc.jku.at 4/36

Basic JML Assertions JML as required for the basic Hoare calculus. Assertions. assume, assert. Loop assertions. loop invariant, decreases. Method contracts. requires, ensures. The JML expression language. \forall, \exists,... Specifying simple procedural programs. Definition: An assertion is a command that specifies a property which should always hold when execution reaches the assertion. JML: two kinds of assertions. assert P: P needs verification. assume P: P can be assumed. Makes a difference for reasoning tools. A runtime checker must test both kinds of assertions. //@ assume n!= 0; int i = 2*(m/n); //@ assert i == 2*(m/n); Low-level specifications. Wolfgang Schreiner http://www.risc.jku.at 5/36 Wolfgang Schreiner http://www.risc.jku.at 6/36 Loop Assertions Assertions in Methods int i = n; int s = 0; //@ loop_invariant i+s == n; //@ decreases i+1; while (i >= 0) i = i-1; s = s+1; loop invariant specifies a loop invariant, i.e. a property that is true before and after each iteration of the loop. decreases specifies a termination term, i.e. an integer term that decreases in every iteration but does not become negative. Useful for reasoning about loops. Wolfgang Schreiner http://www.risc.jku.at 7/36 static int isqrt(int y) //@ assume y >= 0; int r = (int) Math.sqrt(y); //@ assert r >= 0 && r*r <= y && y < (r+1)*(r+1); return r; assume specifies a condition P on the pre-state. Pre-state: the program state before the method call. The method requires P as the method s precondition. assert specifies a condition Q on the post-state. Post-state: the program state after the method call. The method ensures Q as the method s postcondition. Low-level specification of a method. Wolfgang Schreiner http://www.risc.jku.at 8/36

Design by Contract Method Contracts Pre- and post-condition define a contract between a method (i.e. its implementor) and its caller (i.e. the user). The method (the implementor) may assume the precondition and must ensure the postcondition. The caller (the user) must ensure the precondition and may assume the postcondition. Any method documentation must describe this contract (otherwise it is of little use). The legal use of a method is determined by its contract (not by its implementation)! /*@ requires y >= 0; @ ensures \result >= 0 @ && \result*\result <= y @ && y < (\result+1)*(\result+1); static int isqrt(int y) return (int) Math.sqrt(y); requires specifies the method precondition May refer to method parameters. ensures specifies the method postcondition May refer to method parameters and to result value (\result). Higher-level specification of a method. Wolfgang Schreiner http://www.risc.jku.at 9/36 Wolfgang Schreiner http://www.risc.jku.at 10/36 Postcondition and Pre-State The JML Expression Language // swap a[i] and a[j], leave rest of array unchanged /*@ requires @ a!= null && @ 0 <= i && i < a.length && 0 <= j && j < a.length; @ ensures @ a[i] = \old(a[j]) && a[j] == \old(a[i]) && @ (* all a[k] remain unchanged where k!= i and k!= j *) static void swap(int[] a, int i, int j) int t = a[i]; a[i] = a[j]; a[j] = t; Variable values in postconditions: x... value of x in post-state (after the call). Except for parameters which are always evaluated in the pre-state. \old(x)... value of x in pre-state (before the call). \old(e)... expression E evaluated with the value of every variable x in E taken from the pre-state. Variable values may change by the method call (more on this later). Wolfgang Schreiner http://www.risc.jku.at 11/36 Atomic Formulas Any Java expression of type boolean: a+b == c Primitive operators and pure program functions (later). Informal property expression: (* sum of a and b equals c *) Does not affect truth value of specification. Connectives:!P, P && Q, P Q, P ==> Q, P <== Q, P <==> Q, P <=!=> Q P, P Q, P Q, P Q, Q P, P Q, (P Q). Universal quantification: (\forall T x; P; Q) x T : P Q Existential quantification: (\exists T x; P; Q) x T : P Q Strongly typed first-order predicate logic with equality. Wolfgang Schreiner http://www.risc.jku.at 12/36

The JML Expression Language (Contd) Examples Sum: (\sum T x; P; U) (x T ) P U Product: (\product T x; P; U) (x T ) P U Minimum: (\min T x; P; U) minu : x T P Maximum: (\max T x; P; U) maxu : x T P Number: (\num of T x; P; Q) x T : P Q Set: new JMLObjectSet T x P x T : P // sort array a in ascending order /*@ requires a!= null; @ ensures (* a contains the same elements as before the call *) @ && (\forall int i; 0 <= i && i < a.length-1; a[i] <= a[i+1]); static void sort(int[] a)... // return index of first occurrence of x in a, -1 if x is not in a /*@ requires a!= null; @ ensures @ (\result == -1 @ && (\forall int i: 0 <= i && i < a.length; a[i]!= x)) @ (0 <= \result && \result < a.length && a[\result] == x @ && (\forall int i; 0 <= i && i < \result; a[i]!= x)); static int findfirst(int[] a, int x)... Wolfgang Schreiner http://www.risc.jku.at 13/36 Wolfgang Schreiner http://www.risc.jku.at 14/36 Examples // swap a[i] and a[j], leave rest of array unchanged /*@ requires @ a!= null && @ 0 <= i && i < a.length && 0 <= j && j < a.length; @ ensures @ a[i] = \old(a[j]) && a[j] == \old(a[i]) && @ (\forall int k; 0 <= k && k < a.length; @ (k!= i && k!= j) ==> a[k] == \old(a[k])); static void swap(int[] a, int i, int j)... 1. Basic JML 2. JML Tools 3. More Realistic JML Wolfgang Schreiner http://www.risc.jku.at 15/36 Wolfgang Schreiner http://www.risc.jku.at 16/36

Common JML Tools Example Type checker jml Checks syntactic and type correctness. Runtime assertion checker compiler jmlc Generates runtime assertions from (some) JML specifications. Executable specification compiler jmle Generates executable code from (some) JML specifications. JML skeleton specification generator jmlspec Generates JML skeleton files from Java source files. Document generator jmldoc Generates HTML documentation in the style of javadoc. Unit testing tool junit Generates stubs for the JUnit testing environment using specifications as test conditions. Simple GUI launched by jml-launcher. Wolfgang Schreiner http://www.risc.jku.at 17/36 public class Account private /*@ spec_public int bal;... //@ public invariant bal >= 0; /*@ requires amt > 0 && amt <= bal; @ assignable bal; @ ensures bal == \old(bal) - amt; public void withdraw(int amt) bal -= amt; public static void main(string[] args) Account acc = new Account(100); acc.withdraw(200); System.out.println("Balance after withdrawal: " + acc.balance()); Wolfgang Schreiner http://www.risc.jku.at 18/36 Runtime Assertion Checking JML4c > jml -Q Account.java > jmlc -Q Account.java > jmlrac Account Exception in thread "main" org.jmlspecs.jmlrac.runtime.jmlinternalpreconditionerror: by method Account.withdraw at Account.main(Account.java:1486) A bit little information. A third-party replacement for jmlc (more information but buggy). > jml -Q Account.java > jml4c Account.java > jml4crun Account Exception in thread "main" org.jmlspecs.jml4.rac.runtime. JMLInternalPreconditionError: By method Account.withdraw Regarding specifications at File "Account.java", line 27, character 16 With values amt: 200 bal: 100 at Account.main(Account.java:38) http://www.cs.utep.edu/cheon/download/jml4c. Wolfgang Schreiner http://www.risc.jku.at 19/36 Wolfgang Schreiner http://www.risc.jku.at 20/36

Other Third Party JML Tools Practical Use A large number of tools uses/supports JML. Mobius Program Verification Environment Based on Eclipse, integrates common JML tools and ESC/Java2. Sireum/Kiasan for Java Automatic verification and test case generation toolset. Modern Jass Design by contract tool. JMLUnitNG Test generation tool. ESC/Java2 Extendes static checking (later). KeY Verifier Computer-assisted verification (later).... Support different versions of JML/Java, for current state, see http://www.jmlspecs.org/download.shtml Wolfgang Schreiner http://www.risc.jku.at 21/36 Recommended use with JML-annotated Java files. First compile with javac. Check syntactic and type correctness of Java source. Then compile with jml. Check syntactic and type correctness of JML annotations. Then compile with escjava2. Check semantic consistency of JML annotations. More on ESC/Java2 later. Errors can be made at each level. Wolfgang Schreiner http://www.risc.jku.at 22/36 More Realistic JML 1. Basic JML 2. JML Tools JML for procedural programs with side-effects and errors. Side-effects assignable, pure Exceptions signals We also have to deal with the less pleasant aspects of programs. 3. More Realistic JML Wolfgang Schreiner http://www.risc.jku.at 23/36 Wolfgang Schreiner http://www.risc.jku.at 24/36

Side Effects Pure Program Functions static int q, r, x; /*@ requires b!= 0; @ assignable q, r; @ ensures a == b*q + r && sign(r) == sign(a) && @ (\forall int r0, int q0; a == b*q0+r0 && sign(r0) == sign(a); @ abs(r) <= abs(r0)) static void quotrem(int a, int b) q = a/b; r = a%b; assignable specifies the variables that method may change. Default: assignable \everything. Method might change any visible variable. Possible: assignable \nothing. No effect on any variable. Wolfgang Schreiner http://www.risc.jku.at 25/36 static /*@ pure int sign(int x) if (x == 0) return 0; else if (x > 0) return 1; else return -1; static /*@ pure int abs(int x) if (x >= 0) return x; else return -x; Pure program functions may be used in specification expressions. pure implies assignable \nothing. JML considers pure program functions as mathematical functions. Wolfgang Schreiner http://www.risc.jku.at 26/36 Arrays and Side Effects Exceptions int[] a = new int[10]; assignable a; The pointer a may change. a = new int[20]; assignable a[*]; The content of a may change. a[1] = 1; // swap ai] and a[j], leave rest of array unchanged /*@ requires @ a!= null && @ 0 <= i && i < a.length && 0 <= j && j < a.length; @ assignable a[*]; @ ensures @ a[i] = \old(a[j]) && a[j] == \old(a[i]) && @ (\forall int k; 0 <= k && k < a.length; @ (k!= i && k!= j) ==> a[k] == \old(a[k])); static void swap(int[] a, int i, int j)... Wolfgang Schreiner http://www.risc.jku.at 27/36 static int balance; /*@ assignable balance; @ ensures \old(balance) >= amount @ && balance = \old(balance)-amount; @ signals(depositexception e) \old(balance) < amount @ && balance == \old(balance); static void withdraw(int amount) throws DepositException if (balance < amount) throw new DepositException(); balance = balance-amount; This method has two ways to return. Normal return: the postcondition specified by ensures holds. Exceptional return: an exception is raised and the postcondition specified by signals holds. Wolfgang Schreiner http://www.risc.jku.at 28/36

Exceptions Preconditions versus Exceptions Default: signals(exception e) true; Instead of a normal return, method may also raise an exception without any guarantee for the post-state. Even if no throws clause is present, runtime exceptions may be raised. Consider: signals(exception e) false; If method returns by an exception, false holds. Thus the method must not raise an exception (also no runtime exception). We also have to take care to specify the exceptional behavior of a method! Wolfgang Schreiner http://www.risc.jku.at 29/36 /*@ requires (\exists int x; ; a == x*b); @ ensures a == \result*b; static int exactdivide1(int a, int b)... /*@ ensures (\exists int x; ; a == x*b) && a == \result*b; @ signals(divexception e)!(\exists int x; ; a == x*b) static int exactdivide2(int a, int b) throws DivException... exactdivide1 has precondition P : x : a = x b. Method must not be called, if P is false. It is the responsibility of the caller to take care of P. exactdivide2 has precondition true. Method may be also called, if P is false. Method must raise DivException, if P is false. It is the responsibility of the method to take care of P. Different contracts! Wolfgang Schreiner http://www.risc.jku.at 30/36 Lightweight Specifications Method Underspecification This is the contract format we used up to now. /*@ requires...; @ assignable...; @ ensures...; @ signals...; Convenient form for simple specifications. If some clauses are omitted, their value is unspecified. So what does a (partially) unspecified contract mean? If not specified otherwise, client should assume weakest possible contract: requires false; Method should not be called at all. assignable \everything; In its execution, the method may change any visible variable. ensures true; If the method returns normally, it does not provide any guarantees for the post-state. signals(exception e) true; Rather than returning, the method may also throw an arbitrary exception; in this case, there are no guarantees for the post-state. Defensive programming: for safety, client should avoid implicit assumptions. Wolfgang Schreiner http://www.risc.jku.at 31/36 Wolfgang Schreiner http://www.risc.jku.at 32/36

Method Underspecification Heavyweight Specifications If not specified otherwise, method should implement strongest possible contract: requires true; Method might be called in any pre-state. assignable \nothing; In its execution, the method must not change any visible variable. signals(exception e) false; Method should not throw any exception. Defensive programming: for safety, method should satisfy implicit client assumptions (as far as possible). Wolfgang Schreiner http://www.risc.jku.at 33/36 /*@ public normal_behavior @ requires...; @ assignable...; @ ensures...; @ also public exceptional_behavior @ requires...; @ assignable...; @ signals(...)...; A normal behavior and (one or multiple) exceptional behaviors. Method must implement all behaviors. Each behavior has a separate precondition. What must hold, such that method can exhibit this behavior. If multiple hold, method may exhibit any corresponding behavior. If none holds, method must not be called. For each behavior, we can specify the visibility level (later), the assignable variables, the postcondition. Wolfgang Schreiner http://www.risc.jku.at 34/36 Heavyweight Specification Defaults Example If not specified otherwise, we have the following defaults: requires true; Method may be called in any state. assignable \everything; In its execution, the method may change every visible variable. ensures true; After normal return, no guarantees for the post-state. signals(exception e) true; Rather than returning, the method may also throw an arbitrary exception; then there are no guarantees for the post-state. Method must not make assumptions on the pre-state, caller must not make assumptions on the method behavior and on the post-state. Wolfgang Schreiner http://www.risc.jku.at 35/36 static int balance; /*@ public normal_behavior @ requires balance >= amount; @ assignable balance; @ ensures balance = \old(balance)-amount; @ also public exceptional_behavior @ requires balance < amount; @ assignable \nothing; @ signals(depositexception e) true; static void withdraw(int amount) throws DepositException if (balance < amount) throw new DepositException(); balance = balance-amount; Clearer separation of normal behavior and exceptional behavior. Wolfgang Schreiner http://www.risc.jku.at 36/36