1 © Wolfgang Pelz Design by Contract Design by Contract™ Based on material drawn from: Bertrand Meyer, Applying “Design by Contract,” IEEE Computer, 1992, pp

2 © Wolfgang Pelz Design by Contract Basic Premise To improve software reliability, the first and perhaps most difficult problem is to define as precisely as possible, for each software element, what it is supposed to do.

3 © Wolfgang Pelz Design by Contract Design by Contract ™ associate a specification with every software element these specifications (or contracts) govern the interaction of the element with the rest of the world.

4 © Wolfgang Pelz Design by Contract Benefits A better understanding of the object- oriented method and, more generally, of software construction. A systematic approach to building bug-free object-oriented systems. An effective framework for debugging, testing and, more generally, quality assurance.

5 © Wolfgang Pelz Design by Contract More Benefits A method for documenting software components. Better understanding and control of the inheritance mechanism. A technique for dealing with abnormal cases, leading to a safe and effective language construct for exception handling.

6 © Wolfgang Pelz Design by Contract Tabular Form of Contract Party Obligations Benefits Client Provide letter or package Get package delivered of no more than 5 kgs, each in 4 hours or less dimension < 2 meters. Pay 100 francs. UPS2 Deliver package to recipient No need to deal with in 4 hours or less. deliveries too big, too heavy, or unpaid.

7 © Wolfgang Pelz Design by Contract Rationale a contract document protects both the client, by specifying how much should be done, and the supplier, by stating that the supplier is not liable for failing to carry out tasks outside of the specified scope the obligations of the supplier become the benefits to the client

8 © Wolfgang Pelz Design by Contract Rationale restated a contract protects both sides: protects the client by specifying how much should be done; the client is entitled to receive a certain result protects the contractor by specifying how little is acceptable; the contractor must not be liable for failing to carry out tasks outside of the specified scope

9 © Wolfgang Pelz Design by Contract Assertions preconditions and postconditions routine_name (argument declarations) is require Precondition do Routine body (instructions) ensure Postcondition end

10 © Wolfgang Pelz Design by Contract Violation of an Assertion a precondition violation indicates a bug in the client (caller); the caller did not observe the conditions imposed on correct calls a postcondition violation is a bug in the supplier (called routine); the routine failed to deliver on its promises

11 © Wolfgang Pelz Design by Contract Defensive Programming requires redundant checks in both the client and the supplier not necessary if assertions are used in writing the software to spell out the consistency conditions which could go wrong at runtime

12 © Wolfgang Pelz Design by Contract Effect on Software strong preconditions –heavier burden on the client –lighter burden on the supplier dealing with abnormal values is a pragmatic decision about division of labor in many existing programs, one searches for islands of useful processing midst oceans of error-checking code due to redundancy

13 © Wolfgang Pelz Design by Contract Assertion in VC++ iend.asphttp:// iend.asp assert(condition); // fail if the condition is not true. void CMyClass::MyFunc(char * szStringPtr) { if (szStringPtr[0] == '7') DoSomething(); }

14 © Wolfgang Pelz Design by Contract Assertion in VC++ void CMyClass:: MyFunc(char * szStringPtr) { ASSERT(szStringPtr); if (szStringPtr[0] == '7') DoSomething(); }

15 © Wolfgang Pelz Design by Contract Assertion in VC++ Debug assertion failure When I close my program and call: delete *iter2; I get a "Debug Assertion Failed!" message saying: File: dbgheap.c Line: 1017 Expression: _BLOCK_TYPE_IS_VALID(pHead->nBlockUse) What does this mean?

16 © Wolfgang Pelz Design by Contract Documenting a Contract assertions express the purpose of the software elements (e.g., routines) without reference to implementation details still a research subject for the contract to work properly, the client programmers must have a proper description of the interface properties of a class and its routines