Part I: the RESOLVE framework and discipline

Formal Methods and Software Engineering

2006

The Java Modeling Language ( JML) is used to specify detailed designs for Java classes and interfaces. It has a particularly rich set of features for specifying methods. This paper describes those features, with particular emphasis on the features related to specification inheritance. It shows how specification inheritance in JML forces behavioral subtyping, through a discussion of semantics and examples. It also describes a notion of modular reasoning based on static type information, supertype abstraction, which is made valid in JML by methodological restrictions on invariants, history constraints, and initially clauses and by behavioral subtyping. KeywordsSupertype abstraction, behavioral subtype, behavioral subtyping, modularity, specification inheritance, method specification refinement, join of method specifications, also, specification case, invariants, JML, Java Abstract. The Java Modeling Language (JML) is used to specify detailed designs for Java classes and interfaces. It has a particularly rich set of features for specifying methods. This paper describes those features, with particular emphasis on the features related to specification inheritance. It shows how specification inheritance in JML forces behavioral subtyping, through a discussion of semantics and examples. It also describes a notion of modular reasoning based on static type information, supertype abstraction, which is made valid in JML by methodological restrictions on invariants, history constraints, and initially clauses and by behavioral subtyping.

“…While JML also uses ideas from other sources [8,35,48,49,61,62,67,71,79], at its core it blends these two language traditions.…”

Section: Contextmentioning

confidence: 99%

JML’s Rich, Inherited Specifications for Behavioral Subtypes

Formal Methods and Software Engineering

2006

“…In such a language, a correct implementation must have both the specified interface and specified behavior (or properties), and thus the relation between a program's state (or events) and the abstract state (or events) described by the specification is much more tightly constrained. Examples of behavioral interface specification languages include the Larch family [57,142], the Resolve family [44,115], SPARK [18], Eiffel [97,98], JML [27,85], and Spec# [19,20,86]. Examples of history-based interface specification languages include Bandera [38] and Java Pathfinder [58].…”

Section: Background: Kinds Of Specification Languagesmentioning

confidence: 99%

Roadmap for enhanced languages and methods to aid verification

Proceedings of the 5th International Conference on Generative Programming and Component Engineering

Abrial

Batory

et al. 2006

Self Cite

This roadmap describes ways that researchers in four areas --specification languages, program generation, correctness by construction, and programming languages --might help further the goal of verified software. It also describes what advances the ``verified software'' grand challenge might anticipate or demand from work in these areas. That is, the roadmap is intended to help foster collaboration between the grand challenge and these research areas. A common goal for research in these areas is to establish language designs and tool architectures that would allow multiple annotations and tools to be used on a single program. In the long term, researchers could try to unify these annotations and integrate such tools. AbstractThis roadmap describes ways that researchers in four areas -specification languages, program generation, correctness by construction, and programming languages -might help further the goal of verified software. It also describes what advances the "verified software" grand challenge might anticipate or demand from work in these areas. That is, the roadmap is intended to help foster collaboration between the grand challenge and these research areas.A common goal for research in these areas is to establish language designs and tool architectures that would allow multiple annotations and tools to be used on a single program. In the long term, researchers could try to unify these annotations and integrate such tools.

“…We have already discussed how JML differs from conventional formal specification languages, such as Z [80,79,87], VDM [6,27,74,43], the Larch family [33,48,52,85] and RESOLVE [22,73]. To summarize, the main difference is that JML's specification expressions are based on a subset of the Java programming language, a design that is more congenial to Java programmers.…”

Section: Related Workmentioning

confidence: 99%

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

Formal Methods for Components and Objects

Cheon

Clifton

et al. 2003

Specifications that are used in detailed design and in the documentation of existing code are primarily written and read by programmers. However, most formal specification languages either make heavy use of symbolic mathematical operators, which discourages use by programmers, or limit assertions to expressions of the underlying programming language, which makes it difficult to write complete specifications. Moreover, using assertions that are expressions in the underlying programming language can cause problems both in runtime assertion checking and in formal verification, because such expressions can potentially contain side effects. The Java Modeling Language, JML, avoids these problems. It uses a side-effect free subset of Java's expressions to which are added a few mathematical operators (such as the quantifiers \forall and \exists). JML also hides mathematical abstractions, such as sets and sequences, within a library of Java classes. The goal is to allow JML to serve as a common notation for both formal verification and runtime assertion checking; this gives users the benefit of several tools without the cost of changing notations. Abstract. Specifications that are used in detailed design and in the documentation of existing code are primarily written and read by programmers. However, most formal specification languages either make heavy use of symbolic mathematical operators, which discourages use by programmers, or limit assertions to expressions of the underlying programming language, which makes it difficult to write complete specifications. Moreover, using assertions that are expressions in the underlying programming language can cause problems both in runtime assertion checking and in formal verification, because such expressions can potentially contain side effects. The Java Modeling Language, JML, avoids these problems. It uses a side-effect free subset of Java's expressions to which are added a few mathematical operators (such as the quantifiers \forall and \exists). JML also hides mathematical abstractions, such as sets and sequences, within a library of Java classes. The goal is to allow JML to serve as a common notation for both formal verification and runtime assertion checking; this gives users the benefit of several tools without the cost of changing notations.