About Design by Contract

Design by Contract is a structured way of writing comments to define what code should do. The contract requires components of the code (such as classes or methods) to follow certain specifications as they interact with each other. The interactions between these components must fulfill a set of predetermined mutual obligations.

Design by Contract originated in Eiffel. Eiffel classes are components that cooperate through the use of the contract, which defines the obligations and benefits for each class. DbC is not yet commonly a part of programming languages such as C, C++, and Java, but ideally it should be. After all, any piece of code in any language has implicit contracts attached to it. The simplest example of an implicit contract is a method to which you are not supposed to pass null. If this contract is not met, a NullPointerException will occur. Another example is a component whose specification states that it only returns positive values. If it occasionally returns negative values and the consumer of this component is expecting the functionality described in the specification (only positive values returned), this contract violation could lead to a critical problem in the application.

Tools like Jtest and Jcontract bring Design by Contract to Java by helping you specify the contracts in comments and check whether or not the contract has been fulfilled.

Example

This is an example of a class with Design by Contract comments.

 public class ShoppingCart
 {
     /**
      * @pre item != null
      * @post $result > 0
      */
 
     public float add (Item item) {
         _items.addElement (item);
         _totalCost += item.getPrice ();
         return _totalCost;
     }
     private float _totalCost = 0;
     private Vector _items = new Vector ();
 }

The contract specifies:

1. A precondition ("@pre item != null") which specifies that the item to be added to the shopping cart shouldn't be "null".
2. A postcondition ("@post $result > 0") which specifies that the value returned by the method should always be greater than 0.

Preconditions and postconditions can be thought of as sophisticated assertions. Preconditions are conditions that the client of the method needs to satisfy in order for the method to work properly. Postconditions are conditions that the implementor of the class guarantees will always be satisfied.

Benefits

Benefits of using DbC include:

• The code's assumptions are clearly documented (for example, you assume that item should not be null). Design concepts are placed directly in the code itself.
• The code's contracts can be checked for consistency because they are explicit.
• The code is much easier to reuse.
• The specification will never be lost.
• When you see the specification while writing the code, you are more likely to implement the specification correctly.
• When you see the specification while modifying code, you are much less likely to introduce errors.

Once you start using Jtest and Jcontract, the benefits of using DbC also include:

• Black-box test cases are created automatically. If you currently create your black-box test cases manually, this means fewer resources spent creating test cases and more resources you can dedicate to more complex tasks, such as design and coding. If you do not currently perform black-box testing, this will translate to more reliable software/components.
• Black-box test cases are automatically updated as the code's specification changes.
• Class/component misuse is automatically detected.
• The class implementation can assume that input arguments satisfy the preconditions, so the implementation can be simpler and more efficient.
• The class client is guaranteed that the results will satisfy the postconditions.

For More Information

For more information about DbC see:

• Interactive Software Engineering, "Building Bug-Free O-O Software: An Introduction to Design by ContractTM." http://www.eiffel.com/doc/manuals/technology/contract/page.html
• Eldridge, G. "Java and `Design by Contract.'" http://www.elj.com/eiffel/feature/dbc/java/ge/
• Kolawa, A., "Automating the Development Process." Software Development, July 2000. http://www.sdmagazine.com
• Meyer, B. Object-Oriented Software Construction. Prentice Hall, 2000.

Note: "Design by Contract" is a trademark of Interactive Software Engineering.

Related Topics

Using Design by Contract With Jtest

The Design by Contract Specification Language

Performing Black-Box Testing

Customizing White-Box Testing

Testing A Class - Two Simple Examples