The Java Modeling Language (JML) can be used to specify the detailed design of Java classes and interfaces by adding annotations to Java source files. The aim of JML is to provide a specification language that is easy to use for Java programmers and that is supported by a wide range of tools for specification type-checking, runtime debugging, static analysis, and verification. This paper

This article introduces the verification tool Why. This tool produces verification conditions from annotated programs given as input.

Abstract not found

This paper presents a case study in formal specification and verification of a smart card application. The application is an electronic purse implementation, developed by the smart card producer Gemplus as a test case for formal methods for smart cards. It has been annotated (by the authors) with specifications using the Java Modeling Language (JML), a language designed to specify the functional behavior of Java classes. The reason for using JML as a specification language is that several tools are available to check (parts of) the specification w.r.t. an implementation. These tools vary in their level of automation and in the level of correctness they ensure. Several of these tools have been used for the Gemplus case study. We discuss how the usage of these di#erent tools is complementary: large parts of the specification can be checked automatically, while more precise verification methods can be used for the more intricate parts of the specification and implementation. We believe that having such a range of tools available for a single specification language is an important step towards acceptance of formal methods in industry.

Smart card applications often handle privacy-sensitive information, and therefore must obey certain security policies. Such policies are usually described by high-level security properties, stating for example that no authentication must take place within a transaction.

Abstract. The method contract and loop invariant rules (contract rules) are an important software verification technique for handling method invocations and loops. However, if a verification condition resulting from using a contract rule turns out to be falsifiable, then the user does not know if she could have chosen a stronger contract to verify the program or if the program is not verifiable due to a software bug. We approach this problem and present a novel technique that unifies verification and software bug detection. 1

Abstract not found