Engineering Project Management Software Development: Software is like Aladdin's lamp. Anything is possible, if only we can simply articulate our desires clearly enough. The best way is to define contracts.

---

by Michael L. Perry, president and consultant, Mallard Software Designs Inc. Intel Corp.

When Aladdin rubbed the magic lamp, he was granted three wishes of immeasurable value. He could have wished for anything. The Genie was not bound by the possibilities of the mortal world. Anything that his master desired, he could make happen. Aladdin simply had to speak, and his wish would be granted.

Software is a lot like Aladdin's lamp. Anything is possible, if only we can simply articulate our desires clearly enough. The best way to articulate our desires to a computer is to define contracts. It is important to remember while writing these contracts that, like the Genie, we are bound not by the possibilities of the computer but by the desires of our users.

Contract-based modeling
A contract is a clear and unambiguous statement of responsibilities. In software, a contract is expressed in a computer-readable format. The compiler can understand the contracts, verify that each class is upholding its responsibilities, and facilitate collaborations among objects. The contracts come straight from the interaction design, and should be the first pieces of code written.

Recall from my previous article, Designing a Web Service that Delights your Customers, that an interaction design document is a clear and unambiguous description of the behavior of a software system, written in language that both developers and users can understand. Given the interaction design document, the developers restate all the requirements in code. The language they use depends upon their chosen implementation platform. Some languages, most notably Eiffel, support "design-by-contract," the mathematical specification of conditions that constrain acceptable behavior [Meyer, 331]. While these language constructs are valuable, it is possible to write contracts in any programming language.

In this series of articles, we are developing Laurel, a Web application that helps companies delight their customers by expediting orders, proactively managing issues, and providing personalized customer service. We will deliver the information as a Web service over the public Internet, using a rich client to provide the best possible interaction. Let's see how to translate these wishes into contracts.

Contract cards
In the previous article we wrote the interaction design for Laurel. The interaction design describes the behavior of the software in unambiguous language. It is written for both users and developers of the system. The interaction design we wrote was not nearly as detailed as a professionally written document, but it gives us enough information to move forward.

The next step in the development of the application is to express the required behavior in more rigorous terms: contracts. A contract is a mathematically complete description of the requirements of a class. A contract describes responsibility, whereas a class describes capability. A class must rise to meet the responsibilities that its contract promises.