Specifying Reusable Components

arXiv:1003.5777v1 [cs.SE] 30 Mar 2010 Specifying Reusable Components Nadia Polikarpova Carlo A. Furia Bertrand Meyer Abstract Reusable software components need well-defined interfaces, rigorously and completely documented features, and a design amenable both to reuse and to for- mal verification; all these requirements call for expressive specifications. This paper outlines a rigorous foundation to model-based contracts, a methodology to equip classes with expressive contracts supporting the accurate design, implemen- tation, and formal verification of reusable components. Model-based contracts conservatively extend the classic Design by Contract by means of expressive mod- els based on mathematical notions, which underpin the precise definitions of no- tions such as abstract equivalence and specification completeness. Preliminary experiments applying model-based contracts to libraries of data structures demon- strate the versatility of the methodology and suggest that it can introduce rigorous notions, but still intuitive and natural to use in practice. 1 Introduction The case for precise software specifications involves several well-known arguments; in particular, specifications help understand the problem before building a solution, and they are necessary for verifying implementations. In the case of a library of reusable software components, precise specifications have another application, essential to the effective use of the library: providing client programmers with a description of the interface (the API). To help produce such specifications, Design by Contract techniques [18] let authors of reusable modules equip them with specification elements known as “contracts” (routine preconditions and postconditions, class invariants), which tools from the development environment can extract to produce automatically generated API documentation. While specifications primarily intended for purposes other than component devel- opment typically use a specification language based on mathematics, approaches using Design by Contract, such as Eiffel [18], JML [17] and Spec# [2] rely instead on an assertion language embedded in the programming language. In Eiffel, for example, contracts are expressed through assertions built out of the languages Boolean expres- sions, with a few extensions; the most notable of these extensions is the old notation which makes it possible to express postconditions as properties of both the starting and ending states of the computation. This approach adds a significant element to the list of benefits of precise specifications: being expressed in the programming language, contracts can be evaluated during execution. (We will use the term “executable asser- tions”, although this is really about evaluation rather than execution; another possible 1 term is “embedded” assertion, to emphasize that the assertion language is included in the programming language.) As a consequence, contracts have played a major role in testing, especially for Eiffel, where an advanced testing environment, AutoTest [19], takes advantage of contracts for automatic test generation; more generally, Eiffel pro- grammers routinely rely on run-time contract evaluation for testing and debugging. Another practical benefit of the approach is teachability: programmers already un- derstand Boolean expressions, and do not need to learn a separate specification lan- guage. These practical advantages of executable assertions have traditionally come at a price: expressiveness. Unlike a full-fledged specification language (such as B [1], based on set theory), an assertion language embedded in a programming language makes it harder to express the full specification of programs and components. As a typ- ical example, the postcondition of a “push” operation on a stack in the existing standard Eiffel library expresses that the new top of the stack will be the item just pushed, and that the number of items will have been increased by one; but it typically does not state, except in the form of a comment, that the other elements of the stack are unaffected. This example is typical: an extensive study [3] indicates that in practice Eiffel classes contain many contracts, but (see also [21]) they cover only part of the programmers informal understanding of the specification. Can we retain all the advanced benefits of specifications, in particular support com- pleteness of specifications and static checks (including proofs), while retaining an ex- ecutable specification language that can also be used for testing? The present work proposes a positive answer, based on the idea of models. Specifications, in this approach, do not require any special language beyond the classical assertion language embedded in the programming language. Instead, they rely on a methodological principle: associate with every class one or more model queries specifying the semantics of the associated objects through standard mathemat- ical concepts, represented by instances of model classe

…(Full text truncated)…

This content is AI-processed based on ArXiv data.