Advances in Programming Languages

Transcription

1 Advances in Programming Languages Lecture 12: Practical Tools for Java Correctness Ian Stark School of Informatics The University of Edinburgh Friday 31 November 2014 Semester 1 Week 7

2 Topic: Augmented Programming for Correctness The following lectures cover some language techniques and tools for improving program correctness: Specification and Verification Practical Java tools for Correctness Augmented Programming and Certifying Correctness The focus here is not necessarily on changing what a program does, or making it do that thing faster, or using less memory, or less power. Instead we want to make sure that what it does is the right thing to do. This lecture shows some methods used in Java programming based on ideas from Hoare Logic.

3 Outline 1 Introduction 2 Assertions in Java 3 JML, the Java Modeling Language 4 Closing

4 Outline 1 Introduction 2 Assertions in Java 3 JML, the Java Modeling Language 4 Closing

5 Exam Dates! The University of Edinburgh holds examinations in three diets during the year: December Diet at the end of Semester 1; April/May Diet at the end of the academic year; August Diet principally for resit examinations. There are APL exams in two of these diets this year. If you are Studying for an undergraduate or postgraduate degree at the University of Edinburgh Visiting from another university for the year then you must sit the APL exam in April/May. The exam timetable will be published on Monday 2 March If you are Visiting from another university for this semester only then you must sit the APL exam in December. The exam timetable has been published, and can be checked online.

6 Previous Homework! The lecture next Friday will be on some tools for checking Java programs, including those that apply Hoare Logic and Design by Contract TM. Read this Before Friday, read this short article: Leavens and Cheon. Design by Contract with JML. Post this Find some information online about assertions in Java. Post about it to the mailing list, the blog, or the Facebook group.

7 References! Oracle: Programming With Assertions Stack Overflow: When to use an assertion and when to use an exception

8 Outline 1 Introduction 2 Assertions in Java 3 JML, the Java Modeling Language 4 Closing

9 Java assert What it is. When to use it. Characteristics.

10 Java assert: What It Is Oracle documentation The assertion statement has two forms. The first, simpler form is: assert Expression1 ; where Expression1 is a boolean expression. When the system runs the assertion, it evaluates Expression1 and if it is false throws an AssertionError with no detail message. The second form of the assertion statement is: assert Expression1 : Expression2 ; where: Expression1 is a boolean expression. Expression2 is an expression that has a value. (It cannot be an invocation of a method that is declared void.) Use this version of the assert statement to provide a detail message for the AssertionError. The system passes the value of Expression2 to the appropriate AssertionError constructor, which uses the string representation of the value as the error s detail message.

11 Java assert: When to Use It? To check arguments on the way in to a method? To check results on the way out of a method? To check an invariant inside a loop? For user input sanitization? To check a data structure is in a standard form? To check file contents are in a standard form?

12 Java assert: Characteristics Expressed in Java. Checked at runtime. (So effectiveness depends on coverage of tests.) Can be disabled. (When would you do this? Why?) Must be pure, without side-effects. (Why? What about object-allocation, or time spent on execution?) Can call arbitrary other Java code.

13 Outline 1 Introduction 2 Assertions in Java 3 JML, the Java Modeling Language 4 Closing

14 Review of Hoare Logic Hoare Triple {P} C {Q} A Hoare assertion {P} C {Q} states that if precondition P holds and code C runs to completion then postcondition Q will hold afterwards. Assertions {P} C {Q} can be derived using Hoare rules; they may also be tested against a semantics {P} C {Q}. Hoare assertions allow logical reasoning about program behaviour: notably in formal specification and verification. Hoare assertions are widely used in tools and languages for formal methods. Assertions may be strengthened to contracts for code, placing obligations on both caller and callee.

15 Model-Based Specification Modeling (sic) is an abstraction technique for system design and specification. A model is a representation of the desired system. A formal model is one that has a precise description in a formal language. A model differs from an implementation in that it might: capture only some aspects of the system (e.g., interfaces, communication structure); be partial, leaving some areas unspecified; not be executable. Any implementation of the system can be assessed against the model. Sometimes the model is iteratively refined to give an implementation. Sample applications of modeling in computer software development: VDM the Vienna Development Method; B the B language and B method; UML the Unified Modeling Language and its Object Constraint Language OCL; Z the Z notation for formal specification.

16 The Java Modeling Language The Java Modeling Language, JML, combines model-based and contract approaches to specification. Some design features: The specification lives close to the code Within the Java source, in annotation comments / Uses Java syntax and expressions Rather than a separate specification language. Common language for many tools and analysis Tools add their own extensions, and ignore those of others. Web site: jmlspecs.org

17 JML: Basics public class Account { public int credit; requires credit > amount && amount > ensures credit > 0 && credit == \old(credit) / public int withdraw(int amount) {... } } JML conditions combine logical formulae (&&,==) with Java expressions (credit, amount). Expressions must be pure: no side-effects. There are also visibility controls, glossed over in these examples: credit ought not to be public!

18 JML: Exceptions public class Account { public int credit; requires credit > amount && amount > ensures credit > 0 && credit == \old(credit) signals (RefusedException) credit == / public int withdraw throws RefusedException (int amount) {... } } Where ensures speaks about normal termination, signals specifies properties of the state after exceptional termination.

19 JML: Logical Formulae public class IntArray { public int[] contents; requires (\forall int i, j 0<=i && i<j && contents[i] ensures (contents[\result] == value) (\result == / public int search (int value) {... } } The search routine requires that array contents be sorted on entry. This would, for example, be necessary if it used binary chop to locate value.

20 JML: Class Invariants public class IntArray { public int[] contents; invariant (\forall int i, j 0<=i && i<j && contents[i] <= / ensures (contents[\result] == value) (\result == / public int search (int value) {... } } Now contents must be sorted whenever it is visible to clients of IntArray.

21 JML: Assumptions and Assertions assume j j < / contents[j j] = j;... a[0] = complexcomputation(a,v); assert (\forall int i ; 0<i && i<10; a[0] < / An assumption may help a static analysis tool. An assertion must always be satisfied similar to Java s runtime assert.

22 JML: Models and Ghosts public class IntArray { public int[] contents; } model int represents total = / ghost int set cursor = contents.length / /... A model field represents some property of the model that does not appear explicitly in the implementation. A ghost field is a local variable used only by other parts of the specification.

23 JML: Model Methods and Classes ensures \result = (\sum int i; 0<i && public model int arraysum(int[] / public model class JMLSet {... / Specifications may refer to model methods and even entire model classes to represent and manipulate desired system properties. JML provides specifications for the standard Java classes, as well as a library of model classes for mathematical constructions like sets, bags, integers and reals. Java has implementations with similar names, but these model classes are for the mathematical concepts, with arbitrary size and precision.

24 Dynamic JML Tools: Running and Testing JML annotations can be used to drive various runtime checks. jml4c is a compiler which inserts runtime tests for every assertion; if an assertion fails, an error message provides dynamic information about the failure. JMLUnitNG creates unit tests for TestNG based on preconditions, postconditions and invariants. These automatically exercise and test assertions made in the code. Predecessor jmlunit creates tests for JUnit. JMLOK generates random tests to detect runtime mismatches between code and its specification. JML annotations can provide formal documentation: jmldoc generates human-readable web pages from JML specifications, extending the existing javadoc tool. These facilities are also bundled into the OpenJML toolset.

25 Static JML Tools: Checking and Verification JML annotations can be used to check code before it is executed, or even compiled. ESC/Java 2 carries out a range of static checks on Java programs. These include formal verification of JML annotations using a fully-automated theorem prover. Controversially, the checker is neither sound nor complete: it warns about many potential bugs, but not all actual bugs. This is by design: the aim is to find many possible bugs, quickly. KeY is a formal software development tool based on a dynamic logic for Java. KeY has a facility to accept JML for the specification of Java code. JACK the Java Applet Correctness Kit generates proof obligations from JML annotations on Java and JavaCard programs; these can then be tackled with a variety of automatic and semi-automatic theorem provers. OpenJML includes tools to check JML specifications before compilation using the Z3 and Yices theorem provers.

26 ESC/Java2 The Extended Static Checker for Java version 2 (ESC/Java2) is a programming tool that attempts to find common run-time errors in JML-annotated Java programs by static analysis of the program code and its formal annotations. It is available both as a command-line tool and a plugin for the Eclipse development environment. ESC/Java2 performs different kinds of static check: Checks based on types, flow of data, existing Java declarations; JML annotation checking that can be carried out directly; Logical assertions that need an external proof tool. These last assertions are passed to any one of several automated or semi-automated theorem provers.

27 Many Different Checks ESC/Java2 checks for very many things. These include: Null pointer dereference Negative array index Array index too large Invalid type casts Array storage type mismatch Divide by zero Negative array size Unreachable code Deadlock in concurrent code Race condition Unchecked exception Object invariant broken Loop invariant broken Precondition not satisfied Postcondition not satisfied Assertion not satisfied JML assumptions and assertions can help with all of these.

28 Soundness and Completeness ESC/Java2 is intended as a practical tool, and as such makes some compromises: it is not perfect. Not sound: it may approve an incorrect program. Not complete: it may complain about a correct program. However, it reliably checks straightforward specifications, and automatically points out many potential bugs. In particular: ESC/Java2 distinguishes between errors (definitely bad), warnings (could be bad) and cautions (can t be sure it s good). Sources of unsoundness and incompleteness are documented.

29 Soundness and Completeness ESC/Java2 is intended as a practical tool, and as such makes some compromises: it is not perfect. Not sound: it may approve an incorrect program. Not complete: it may complain about a correct program. However, it reliably checks straightforward specifications, and automatically points out many potential bugs. In particular: ESC/Java2 distinguishes between errors (definitely bad), warnings (could be bad) and cautions (can t be sure it s good). Sources of unsoundness and incompleteness are documented.... as we know, there are known knowns ; there are things we know we know. We also know there are known unknowns ; that is to say we know there are some things we do not know. But there are also unknown unknowns the ones we don t know we don t know. (Donald Rumsfeld, 2002)

30

31 Lightweight Specification: Non-Null References JML and ESC/Java2 introduced keywords for some standard properties. One of the most common specification requirements in Java is that objects be non-null. Correspondingly, one of the most common Java errors is NullPointerException. non_null Object o; With this specification, every method invocation on o is known to not cause an exception, but every assignment to o must be checked to be non-null. This is so good it s been introduced repeatedly by different tools and specification frameworks. As of Java 8, there are official type to be exploited by static checkers and even standard compilers.

32 Lightweight Specification: Non-Null References JML and ESC/Java2 introduced keywords for some standard properties. One of the most common specification requirements in Java is that objects be non-null. Correspondingly, one of the most common Java errors is NullPointerException. non_null Object o; With this specification, every method invocation on o is known to not cause an exception, but every assignment to o must be checked to be non-null. This is so good it s been introduced repeatedly by different tools and specification frameworks. As of Java 8, there are official type to be exploited by static checkers and even standard compilers. I call it my billion-dollar mistake. It was the invention of the null reference in [... ] My goal was to ensure that all use of references should be absolutely safe, with checking performed automatically by the compiler. But I couldn t resist the temptation to put in a null reference (Tony Hoare, 2009)

33 Behavioural Subtyping The idea of behavioural subtyping is part of the object-oriented paradigm: an object in a subclass should behave like an object in a superclass. Known as Liskov s principle of substitutivity:... properties that can be proved using the specification of an object s presumed type should hold even though the object is actually a subtype of that type. [Liskov and Wing, 1994] This can be captured by requiring in specifications that when A extends B: Each precondition for A.m is implied by the preconditions given for B.m; The postconditions for A.m imply each postcondition for B.m; Each invariant of class A is implied by the invariants of subclass B. In JML this is captured by specification inheritance, which enforces substitutivity between classes and subclasses.

34 Outline 1 Introduction 2 Assertions in Java 3 JML, the Java Modeling Language 4 Closing

35 Summary Assertions in Java Statements in code of programmer expectations. Can be checked at runtime during testing. Supplement, but are different from, standard exceptions. The Java Modeling Language JML combines model-based and contract-style specification Annotations within code: requires, ensures,... Provides model fields, methods and classes. Common input language for many tools: runtime checks, static analyses, test generators, invariant guessers, etc.

36 Homework! JML is just one of many frameworks for specifying and verifying code in various programming languages. Examples include Java annotations, FindBugs TM, QuickCheck, the C specification language ACSL and Frama-C platform, Spec#; and others taking a wide range of approaches. Your homework is to find out about one particular such system. Post this Find some information online about Microsoft s Code Contracts. Post about it to the mailing list, the blog, or the Facebook group.