Specifying and checking method call sequences of Java programs

The Object Constraint Language (OCL) is a formal specification language that could be used for constraining the modelling elements that occur in UML diagrams. The Java Modeling Language (JML) is a behavioural interface specification language designed for specifying Java classes and interfaces. This paper investigates the mapping of OCL constraints to JML constraints together with its properties. In particular the paper shows how those constructs such as iterators that are not directly supported by JML are transformed to an equivalent form that can be mapped directly to JML. The paper proposes a special library for OCL types implemented in Java that facilitates the mapping. Extracts from a case study was used to illustrate the mapping

The Java Modeling Language (JML) is a notation for specifying and describing the detailed design and implementation of Java modules. An important language design goal of JML has been to preserve the semantics of Java to the extent possible. Thus, in particular, Java numeric expressions have the same meaning in JML. We illustrate how such a semantics fails to match the expectations of specification authors and readers who generally think in terms of arbitrary precision arithmetic (rather than the fixed precision provided by Java). As a result, an unusually high number of published JML specifications are invalid or inconsistent, including cases from the security critical area of smart card applications. We briefly examine JML’s ancestry and language design principles; this helps to explain the origin of the semantic gap between user expectations and the current meaning given to JML numeric expressions. With the objective of better matching user expectations we introduce JMLb, a variant of JML supporting primitive arbitrary precision numeric types as well as “math modes” to control the semantics of arithmetic expressions. This is done in a manner that is consistent with JML’s language design goals. A semantics of JMLb expressions is given by means of an embedding into PVS. The problem presented here will arise in the design of most interface specification languages that must deal with, e.g., mathematical integers in specifications and their fix precision approximations in code. We examine how the problem may manifest itself in other languages (such as Eiffel, Spark and the UML/OCL-Java notation of the KeY project) and comment on the applicability of our solution.

Despite some efforts to provide support to JML (Java Modelling Language) for Java 1.5 and 1.6, no full implementation for checking Java's new features has been carried out. In particular, there is still no full support to JML and Java generic types. This paper presents an approach to check satisfiability of JML generic types by mapping JML specifications into the input language of Yices and using Yices' SMT solver to do the checking. Our primary motivation for mapping JML generic types into Yices is to be able to use an efficient solver to verify a JML model for social networking we had obtained as translation from B. Our work focuses on the mapping of JML generic classes for sets and relations since B machines specifications are essentially predicate logic and set theory. We use the JML model for social networking as a running example to present our ideas throughout the paper.

Formal methods for smart cards: an experience report

As a Behavioral Interface Specification Language (BISL) for Java, the Java Modeling Language (JML) is tightly coupled to the base language it enhances. Up until Java 1.4, JML kept apace with the evolution of its base language. Java 5 and subsequent revisions have yet to be fully supported by JML tools. Recent efforts such as JML4 have been addressing this issue by providing an Eclipse-based tooling infrastructure. In its current form, JML4 has a fairly steep learning curve for developers wishing to contribute to or extend it. To address this issue and bring JML tools one step closer to a desired plug-in model, we propose a JML Intermediate Representation (JIR) and supporting software infrastructure for JML front-ends and back-ends.

The idea behind Design by Contract (DbC) is that a method defines a contract stating the requirements a client needs to fulfill to use it, the precondition, and the properties it ensures after its execution, the post condition. Though there exists ample support for DbC for sequential programs, applying DbC to concurrent programs presents several challenges. We have proposed a solution to these challenges in the context of Java as programming language and the Java Modeling language as specification language. This paper presents our findings when applying our DbC technique on an industrial case study to evaluate the ability of contract-based, runtime assertion checking code at detecting and diagnosing race conditions and deadlocks during system testing. The case study is a highly concurrent industrial system from the telecommunications domain, with actual faults. It is the first work to systematically investigate the impact of contract assertions for the detection of race conditions and deadlocks, along with functional properties, in an industrial system.

Specification languages help programmers write correct programs and also aid efforts for dynamically checking a software implementation with respect to its desired specifications. Most mainstream specification languages primarily deal with a program’s functional behavior. However, for certain applications it is more natural and intuitive to be able to express a system’s temporal properties. This thesis enhances the capabilities of the Java Modeling Language (JML), a behavioral interface specification language, by incorporating temporal logic constructs. The temporal specification grammar used is a modification of the JML temporal extension proposed by K. Trentelman and M. Huisman in their paper “Extending JML Specifications with Temporal Logic”. I have modified jmlc, the runtime assertion checker for the Java Modeling Language, so that it also generates runtime assertion checking code to dynamically check a program’s temporal specifications.

Traditional structured analysis and design methods have been criticized because the methods lack formality to provide a design for rigorous development. Several approaches have been developed for verifying a design by integrating traditional structured analysis and design methods with formal specification languages. However, the integration of traditional structured analysis and design methods with formal specification languages may confuse the problem definition and understanding with the attempt to define system structures and algorithms in the design phase. In addition, formal specification languages may add complexity to the design due to the complexity of the language syntax and semantics. In this paper, we are presenting an approach to verification of a structured design in HOS without using formal specification languages. Rules for the partial and total correctness of the design are also discussed.

Testing and verification are two activities which have the same objective: to ensure software dependability. In the Java context, the Java Modelling Language (JML) has been proposed as specification language. It can be used both for verification and test. Usually, the JML specification is designed with a specific purpose: test or verification. This article addresses the question of reusability of a JML specification provided for one activity (resp. verification or test) in the other context (resp. test or verification). Two different case studies are considered.

SummaryIn order to claim conformance with a Java Specification Request, a Java implementation has to pass all tests in an associated Technology Compatibility Kit. This paper presents a model‐based development of a Technology Compatibility Kit test suite and a test execution tool for the draft safety‐critical Java profile specification. The Java Modeling Language is used to model conformance constraints for the profile. Java Modeling Language annotations define contracts for classes and interfaces. The annotations are translated by a tool into runtime assertion checks. Hereby, the design and elaboration of the concrete test cases are simplified, because the expected results are derived from contracts and thus do not need to be provided explicitly. Bottom‐up testing is applied for testing methods of the safety‐critical Java classes, whereas top‐down testing is applied for testing global properties, such as protocols, memory management, and real‐time properties, including scheduling. The tests are executed using a simplified version of JUnit, which makes the test suite executable on resource‐constrained platforms. Copyright © 2017 John Wiley & Sons, Ltd.

In Wide Area Networks (WANs)inconsistencies among the security policies of Administrative Domains (ADs) may cause severe security flaws. Recently, security policies are written in natural language and as they get more complicated, even for an expert it might be impossible to detect such inconsistencies. However, when a formal language is used, it might be possible to make verification of security policies by automated theorem proving tools. Due to the existence of mobile devices such as laptops, PDAs and mobile agents, we need a formal language that is capable of defining the concept of mobility. In this paper, we extend Mob adtl [1] according its refinement methodology to obtain a formal policy specification language for an 802.11 WLAN with enhanced security network.

With Java 5 annotations, the authors note a marked increase in tools that can statically detect potential null dereferences. To be effective, such tools require that developers annotate declarations with nullity modifiers and have annotated API libraries. Unfortunately, in the experience of the authors, specifying moderately large code bases, the use of non-null annotations is more labour intensive than it should be. Motivated by this experience, the authors conducted an empirical study of five open source projects totalling 700K lines-of-code, which confirms that, on average, 75% of reference declarations are meant to be non-null, by design. Guided by these results, the authors propose the adoption of non-null-by-default semantics. This new default has advantages of better matching general practice, lightening developer annotation burden and being safer. The authors also describe the Eclipse Java Modelling Language (JML) Java Development Tooling (JDT), a tool supporting the new semantics, including the ability to read the extensive API library specifications written in the JML. Issues of backwards compatibility are addressed. In a second phase of the empirical study, the authors analysed the uses of null and noted that over half of the nullable field references are only assigned non-null values. For this category of reference, the authors introduce the concept of monotonic non-null type and illustrate the benefits of its use.

A Case Study in Matching Test and Proof Coverage

Standardization of Formal Specification Languages

Formal software development begins with formal specification of the user requirements or design of a system. Hence, formal specification languages are used to resolve ambiguities in user requirements or detect design errors at the early software life cycle. Furthermore, specification-based functional testing derives test inputs from its formal specification. However, formal specifications are expressed using set theory or predicate logics which are non-executable. Thus, functional test execution over abstract expressions would be impossible. Therefore, there is a need to refine abstract specification into a form that can be executable. In this paper, an automatic functional testing framework using object constraint language (OCL) formal specification has been proposed. The major objective of this paper is to describe how the refinement processes are integrated into the specification-based testing framework.