Design by Contract

Encyclopedia : D : DE : DES : Design by Contract

DBC also stands for Direct Bonded Copper, a Power electronic substrate

"Design by Contract" is also the name of a trademark of Eiffel Software, Inc. (formerly Interactive Software Engineering), the designers of Eiffel.

Design by contract, DBC or Programming by contract is a methodology for designing computer software. It prescribes that software designers should define precise checkable interface specifications for software components based upon the theory of abstract data types and the conceptual metaphor of a legal contract.

Contents

Description

The central idea of DBC is that software entities have obligations to other entities based upon formalized rules between them. A functional specification, or 'contract', is created for each module in the system before and during its implementation. Program execution is then viewed as the interaction between the various modules as bound by these contracts. For a description of DBC that attempts to depict the original model more closely, see [wikibooks].

In general, routines have explicit preconditions that the caller must satisfy before calling the routine, and explicit postconditions that describe the conditions that the routine will guarantee to be true after the routine finishes. Thus, a contract takes the following general form: "If you, the caller, set up certain preconditions, then I will establish certain other results when I return to you. If you violate the preconditions, then I promise nothing." Each module's implementation can then be written assuming the correctness of the modules it uses (its subcontractors), as long as it satisfies their preconditions.

Many languages have facilities to make assertions like these. However, DBC is novel in recognizing that these contracts are so crucial to software correctness that they should be part of the design process. In effect, DBC advocates writing the assertions first.

The notion of a contract extends down to the method/procedure level; the contract for each method will normally contain the following pieces of information:

Acceptable and unacceptable input values or types (c.f. type bounds for Java 5 generics), and their meanings
Return values or types (c.f. type bounds for Java 5 generics), and their meanings
Error and exception conditions values or types (c.f. type bounds for Java 5 generics), that can occur, and their meanings
Side-effects
Preconditions
Postconditions
Invariants
(Rarer) Performance guarantees, e.g., for time or space used

Using the DBC methodology, the program code itself must never try to verify the contract conditions; the whole idea is that code should "fail hard", with the contract verification being the safety net. (This stands in stark contrast to the defensive programming methodology.) DBC's "fail hard" property makes debugging for-contract behavior much easier because the intended behaviour of each routine is clearly specified.

The contract conditions should never be violated in program execution: thus, they can be either left in as debugging code, or removed from the code altogether for performance reasons.

All class relationships are between Client classes and Supplier classes. A Client class is obligated to make calls to Supplier features where the resulting state of the Supplier is not violated by the Client call. Subsequently, the Supplier is obligated to provide a return state and data that does not violate the state requirements of the Client. For instance, a Supplier data buffer may require that data is present in the buffer when a delete feature is called. Subsequently, the Supplier guarantees to the client that when a delete feature finishes its work, the data item will, indeed, be deleted from the buffer. Other Design Contracts are concepts of "Class Invariant". The Class Invariant guarantees (for the local class) that the state of the class will be maintained within specified tolerances at the end of each feature execution.

Unit testing tests a module in isolation, to check that it meets its contract assuming its subcontractors meet theirs. Integration testing checks whether the various modules are working properly together. Design by contract also fosters code reuse, since the contract for each piece of code is fully documented. The contracts for a module can also be regarded as a form of software documentation for the behavior of that module.

A Layman's Explanation Of Design By Contract

A process in which a number of objects (people or software components, for example) interact to satisfy a goal is called a collaboration. When two objects collaborate together, one - the client - requests the services of the other - the supplier. The supplier in turn may request the sevices of other objects, and in those collaborations it is the client and they are the suppliers. The process only works correctly if all these individual collaborations work correctly. In a very real sense, the chain is only as strong as its weakest link.

Take the process of going on holiday, for example. Bertrand wants to spend two weeks in Florida. He books the holiday through DBC Holidays Inc., who specialise in US package holidays. When he makes the booking (collaboration #1), Bertrand is the client and DBC Holidays are the supplier. DBC Holidays then arrange flights through Assertair Corp. (collaboration #2), and book a room at the Precondition Plaza Hotel in Miami (collaboration #3). In collaboration #2, DBC Holidays are the client and Assertair is the supplier, and in collaboration #3, the hotel is the supplier. And the chain of collaborations goes deeper and deeper (e.g., who do Assertair pay to service their jets?)

If any link in this chain of collaborations breaks, then the upshot could be that Bertrand's holiday is ruined. It's vital, therefore, that every player in the collaboration does what they're supposed to do. In any collaboration, client and supplier have certain obligations. These obligations (or "responsibilities", if you like) fall into three distinct types:

1. Things that the supplier promises to do as part of the service it offers to the client (e.g., Assertair promises DBC Holidays that Bertrand will be in Miami at a certain date and time)

2. Things that the client promises to do before using the service (e.g., DBC Holidays must ensure that Bertrand has his passport and tickets when he checks in for his flight)

3. Things that the supplier promises will always be true no matter what happens (e.g., The airline will always have adequate insurance to cover any accident)

Things that the supplier promises to do as part of the service are described as a special kind of rule called a postcondition. The postcondition tells the client what will be true if the service is executed correctly (e.g., "your customer will be in Miami by 15:30 on June 8th").

If Bertrand turns up at the check-in desk without his passport, of course, then the airline can't live up to their side of the contract - he will not be allowed to board the plane without it. A rule that the client must satisfy before using a service is called a precondition.

A rule that states what must always be true is called an invariant. If the airline don't have adequate insurance then nobody is going anywhere!

Design By Contract is a discipline for building software such that the collaborations between objects are correct. A formula for correctness when a client uses the services of a supplier is given as:

If the invariant AND precondition are true before using the service, then the invariant AND the postcondition will be true after the service has been completed.

In DBC, the responsibilities are clear: the client must satisfy the precondition. This distinguishes it markedly from a related practice known as defensive programming, where the supplier is responsible for figuring out what to do when a precondition is broken. More often than not, the supplier throws an exception to inform the client that the precondition has been broken, and in both cases - DBC and defensive programming - the client must figure out how to respond to that. DBC makes the supplier's job easier.

Languages implementing DBC

C

Recent efforts add support for Design by Contract to the C programming language using [DBC for C], a preprocessor written in Ruby.

Other tools supporting DBC for C include:

[GNU Nana]

C++

Tools supporting DBC for C++ include:

[C²].

C#

Tools supporting DBC for C# include:

[eXtensible C#], a commercial post-compiler that transforms "declarative assertions", in the form of .NET attributes attached to C# methods and properties, into actual pre- and post-conditions embedded in the compiled .NET IL code.
[Spec#], a Microsoft research extension of the C# language.
[Microsoft Visual Studio Team System for Software Testers], a Microsoft Development Environment for C# (and other .NET languages) that provides unit testing capabilities.

Chrome

The Chrome programming language is an Object Pascal implementation that has "class contracts", which are similar to DBC.

D

D implements Design by Contract as a major feature.

Eiffel

The object oriented Eiffel programming language was created to implement Design by Contract.

Critics of DBC, and Eiffel, have argued that to "fail hard" in real life situations is sometimes literally dangerous. In an attempt to address this, Eiffel treats contract breaches as exceptions that can be caught, allowing a system to recover from its own defects. The degree to which this approach succeeds is arguable.

Java

Tools supporting DBC for Java include:

[iContract2], a free Java source pre-processor/code-generator that uses Javadoc tags to specify preconditions, postconditions, and invariants
[Contract4J], a DBC tool where tests are defined using Java 5 annotations and aspects written in AspectJ evaluate the test expressions at runtime and handle failures.
[jContractor], which provides runtime contract checking by instrumenting the bytecode of classes that define contracts
[Jcontract], a proprietary DBC tool by Parasoft
[C4J], an open source tool with full support for contract inheritance and also the possibility to define contracts for interfaces
[CodePro Analytix], which generates unit test case logic in Eclipse based on assertions within the class and method Javadocs.

JML

The Java Modeling Language (JML) provides specifications, including contracts, to describe Java programs.

Lisaac

Lisaac implements Design by Contract as a major feature.

Perl

Damian Conway's [Class::Contract] module, now maintained by C. Garrett Goebel, is available from CPAN, and implements design-by-contract in Perl. Although the module is not widely used, it enjoys some popularity among Perl users involved in larger projects. [Class::Agreement] is a newer, less mature alternative.

Perfect

[Escher Technologies'] specification language Perfect, as used in the software development tool Perfect Developer implements an extension of DBC, which is called Verified Design by Contract, or VDBC. This tool enjoys popularity with students on some computer science courses as it can generate working programs in Java.

PHP

PHP can implement design by contract via its [assert()] function and a callback function defined using [assert_options()].

PLT Scheme

[PLT Scheme], an extension of the Scheme programming language, implements a sound variant of Eiffel's DbC for modules, higher-order functions, and objects. The design of this system emphasizes that each contract violation must blame the guilty party and must do so with an accurate explanations. As [Findler and Felleisen's papers] carefully explain, this is not the case for Eiffel's system.

Python

Python supports DBC through tools like [PyDBC], [Contracts for Python], and [Dmitry Dvoinikov's recipe].

Ruby

There are several external Design by Contract modules available for Ruby, including [DesignByContract], [Ruby DbC], and [ruby-contract].

Sather

The Sather programming language implements Design by Contract.

SPARK

The SPARK programming language implements Design by Contract by static analysis of Ada programs. By using static analysis SPARK ensures that no contract is ever broken at run-time. This means that Eiffel's problematic 'fail hard' situation will never occur on SPARK.

External links

[An introduction to Design by Contract(TM)]
[Isaac / Lisaac Project home]
[C2 Wiki: Design by contract]
[Damian Conway's Class::Contract] Perl module from CPAN
[dlib C++ Library] A C++ library that uses the DBC methodology

From Wikipedia, the Free Encyclopedia. Original article here. Support Wikipedia by contributing or donating.
All text is available under the terms of the GNU Free Documentation License See Wikipedia Copyrights for details.