Specifying and checking protocols of multithreaded classes

Abstract

In the Design By Contract (DBC) approach, programmers specify methods with pre and postconditions (also called contracts). Earlier work added protocols to the DBC approach to describe allowed method call sequences for classes. We extend this work to deal with a variant of generic classes and multithreaded classes. We present the semantical foundations of our extension. We describe a new technique to check that method contracts are correct w.r.t. to protocols. We show how to generate programs that must be proven to show that method contracts are correct w.r.t. to protocols. Because little support currently exists to help writing method contracts, our technique helps programmers to check their contracts early in the development process.

Run-Time Assertion Checking of Data- and Protocol-Oriented Properties of Java Programs: An Industrial Case Study

“…Consequently in our approach no change in the JML-compiler is needed, and new versions of the JML-compiler are supported automatically, as long as they are backwards compatible. Hurlin [12] presents an extension of the previous work to handle multi-threading which however is not supported by run-time verification (instead it discusses static verification). As in the previous work, an integration of protocol properties with assertions is not considered.…”

Run-time checking of data- and protocol-oriented properties of Java programs

“…Consequently in our approach no change in the JML-compiler is needed, and new versions of the JML-compiler are supported automatically, as long as they are backwards compatible. Hurlin [7] presents an extension of the previous work to handle multi-threading which however is not supported by run-time verification (instead it discusses static verification). As in the previous work, an integration of protocol properties with assertions is not considered.…”

Prototyping a tool environment for run-time assertion checking in JML with communication histories

“…Data communicated by calls and returns is not considered. Hurlin [9] has elegantly extended this approach by using data (in particular, return values of calls) to parametrize the regular expression protocol specifications. Though no run-time checker is implemented (and no integration with JML), a static checker with proof rules for specifications in which the precondition has a specific form is provided.…”