Formal Interface Specification Research Articles

Injecting rapid feedback and collaborative reasoning in teaching specifications

We describe an approach to teaching formal interface specifications using aspects of the Collaborative Reasoning Paradigm . The module requires students to construct test cases independently and cooperatively based on their understanding of a given set of method specifications. Students are supported by software-based reasoning assistants that guide them through their exercises and provide realtime feedback as they work --- both for the students and the instructor. We describe the design of the course module, the supporting reasoning assistant, and representative reasoning exercises. We conclude with a discussion of evaluation results from a recent pilot study conducted at Clemson University.

Formal specification of the JavaCard API in JML: the APDU class

This paper reports on an effort to increase the reliability of JavaCard-based smart cards by means of formal specification and verification of JavaCard source code. As a first step, formal interface specifications, written in the specification language JML (Java Modeling Language), have been developed for all the classes that make up the JavaCard API. These specifications are “lightweight” in the sense that they are incomplete and specify only some aspects of the API, but they already provide a useful addition to the existing informal API specifications. Moreover, the fact that these specification are written in a formal language makes them amenable to tool support, for verification purposes. As an illustration, the JML specifications of the APDU (Application Protocol Data Unit) class in the JavaCard API are discussed in detail.

Impact of performance considerations on formal specification design

Abstract Different client applications of a given functional behaviour usually have different performance requirements. Designing a formal interface specification of the functional behaviour to allow for alternative implementations, and hence, to be suitable for clients with varying performance requirements, is a challenging task. The specifier must consider ramifications of alternative designs on performance to produce a truly implementation-neutral (and hence, performance-neutral) functionality specification. This paper illustrates the influence of performance-both duration and capacity — considerations using a case study in object-based software specification. When these considerations are combined with concerns for comprehensibility and full abstraction, specifications that result that are arguably among the most desirable.