Many verification tools come out of academic projects, whose natural constraints do not typically lead to a strong focus on usability. For widespread use, however, usability is essential. Using a well-known benchmark, the Tokeneer problem, we evaluate the usability of a recent and promising verification tool: AutoProof. The results show the efficacy of the tool in verifying a real piece of software and automatically discharging nearly two thirds of verification conditions. At the same time, the case study shows the demand for improved documentation and emphasizes the need for improvement in the tool itself and in the Eiffel IDE.
All these approaches (and others described in the literature) still leave an open issue, i.e., they are built around strict formal notations which affect the development process from the very beginning. These approaches demonstrate a low level of flexibility. To overcome this problem, a seamless methodological connection built on top of a portfolio of diverse notations and methods is presented in @cite_1 . Another approach is presented in @cite_22 @cite_12 using @cite_4 , where users start the development of system from a strict formal notation (i.e. Event-B), to then automatically translate it to Java code with JML @cite_21 specifications embedded (following Design-by-Contract methodology). Even though this approach enables users with less mathematical expertise to work on formal development, it does not give a seamlessly methodology for the development as presented in this paper.
@cite_4 @cite_22 @cite_21 @cite_1 @cite_12
2408436717 2094160561 2167237435 2949510493
This paper describes a case study on the use of a formal methods tool for checking security properties of Tokeneer, a U.S. National Security Agency (NSA) project developed by Praxis, and released in 2008. We modelled Tokeneer as a series of abstract mathematical models related refinement steps in Event-B. We used the Rodin toolset for modelling Tokeneer in Event-B and for discharging associated proof obligations, and we used the EventB2Java code generator to generate Java code for the Event-B model of Tokeneer. After that, we wrote a series of JUnit tests to validate if the Java implementation of Tokeneer adhered to the security properties of Tokeneer described in the documentation provided by Praxis. To the best of our knowledge, modelling Tokeneer in Event-B and checking that its implementation adheres to those security properties is something that hasn’t been attempted before. JML is a behavioral interface specification language tailored to Java(TM). Besides pre- and postconditions, it also allows assertions to be intermixed with Java code; these aid verification and debugging. JML is designed to be used by working software engineers; to do this it follows Eiffel in using Java expressions in assertions. JML combines this idea from Eiffel with the model-based approach to specifications, typified by VDM and Larch, which results in greater expressiveness. Other expressiveness advantages over Eiffel include quantifiers, specification-only variables, and frame conditions.This paper discusses the goals of JML, the overall approach, and describes the basic features of the language through examples. It is intended for readers who have some familiarity with both Java and behavioral specification using pre- and postconditions. The success of a number of projects has been shown to be significantly improved by the use of a formalism. However, there remains an open issue: to what extent can a development process based on a singular formal notation and method succeed. The majority of approaches demonstrate a low level of flexibility by attempting to use a single notation to express all of the different aspects encountered in software development. Often, these approaches leave a number of scalability issues open. We prefer a more eclectic approach. In our experience, the use of a formalism-based toolkit with adequate notations for each development phase is a viable solution. Following this principle, any specific notation is used only where and when it is really suitable and not necessarily over the entire software lifecycle. The approach explored in this article is perhaps slowly emerging in practice - we hope to accelerate its adoption. However, the major challenge is still finding the best way to instantiate it for each specific application scenario. In this work, we describe a development process and method for automotive applications which consists of five phases. The process recognizes the need for having adequate (and tailored) notations (Problem Frames, Requirements State Machine Language, and Event-B) for each development phase as well as direct traceability between the documents produced during each phase. This allows for a stepwise verification validation of the system under development. The ideas for the formal development method have evolved over two significant case studies carried out in the DEPLOY project. Stepwise refinement and Design-by-Contract are two formal approaches for modelling systems. These approaches are widely used in the development of systems. Both approaches have (dis-)advantages. This thesis aims to answer, is it possible to combine both approaches in the development of systems, providing the user with the benefits of both? We answer this question by translating the stepwise refinement method with Event-B to Design-by-Contract with Java and JML, so users can take full advantage of both formal approaches without losing their benefits. This thesis presents a set of syntactic rules that translates Event-B to JML-annotated Java code. It also presents the implementation of the syntactic rules as the EventB2Java tool. We used the tool to translate several Event-B models. It generated JML-annotated Java code for all the considered models that serve as initial implementation. We also used EventB2Java for the development of two software applications. Additionally, we compared EventB2Java against two other tools for Event-B code generation. EventB2Java enables users to start the software development process in Event-B, where users can model the system and prove its consistency, to then transition to JML-annotated Java code, where users can continue the development process.