2.1 What is Reuse by Contract really?

B. Meyer has coined the phrase design by contract [Mey92] to denote a software development style which emphasises the importance of formal specifications and interleaves them with actual code. Reuse by contract is an attempt to lift this style to code reuse. Its basic idea is to turn the contracts into the actual medium by which client and provider can negotiate reuse:

• The client states his side of the contract as a pair of granted pre- and required postcondition.
• The provider formalizes his bid (i.e., each library component) the other way round, as a pair of required pre- and granted postcondition.
• Negotiation is defined in terms of the contract: an offered component is suited for reuse if the involved pre- and postconditions satisfy a well-defined logical relation.

The negotiation process, also called deductive component retrieval, is the most important technical problem to be solved and as such sometimes identified with reuse by contract. In our opinion, however, only its integration into a formal software development process will lead to significant reuse effects and thus justify the name ``reuse by contract.'' In a formal setting, the contracts arise naturally (e.g., from refinements) and do not impose any extra work on the developers. Consequently, reuse can be built into program design from the very beginning.

On the other side, design by contract is not per se reuse by contract as the existence of a library does not automatically imply its re-use. The difference is in the roles the contracts play. In the design approach, contracts are passive and confined to the library. They do not only describe the components properties but are also their possessions. The reuse approach removes this asymmetry and ``activates'' the contracts for prospective clients. It is a way to exploit the full power of contracts.