|
|
| |
| Home » Design by Contract |
| |
Design by Contract |
|
|
Design by Contract or in short (DBC) or programming by Contract is an introduction or approach to designing computer software ( collection of computer programs). The maintainers of Eiffel Software introduced this trademark 'Design By Contract” Many computers developers simply refer it as programming by contract or contract-first development. It was by the time 1988-1997, Eiffel Software has trademarked the term Design By Contract.
|
The works on formal verification, formal specification and Hoare logic has its root in Design By Contract. Design By Contract has contributed in the following mechanisms:
- A clear specification to guide the design process.
- Emphasized on the application to Inheritance
- Introduced the application to Exception Handling
- Established connection with automatic software documentation.
The main idea of Design By Contract leads to he understanding on how elements of a software system collaborate with each other, on the basis of mutual obligations and benefits. Design By Contract is a metaphor hat has derived from business life, where a “client” and a “supplier” agree on a contract which defines the following:
The supplier is expected to provide certain product (obligation) and is entitled to get the fee paid by the client (benefit).
The client as a rule must pay his fee (obligation) and by doing so is entitled to get the product (benefit).
Both the client and supplier should abide by certain laws and comply certain obligations such as rules and regulations applying to all contracts.
Similarly, a class involved in Object oriented programming provides certain functionality, it may:
Impose a certain obligation to be guaranteed on entry by any client module that calls it: the routines precondition which turns out to be an obligation for the client and a benefit for the supplier (the routine itself), as it relieves the client to handle cases outside that precondition.
The routine might guarantee a certain property on exit: the post condition of the routine- an obligation for the supplier, and obviously a benefit (the main benefit calling the routine) for the client.
Maintain a certain property, assumed on entry and guaranteed on exit.
The pre- and post conditions as well as invariants are specified by different qualified methods of Design By Contract. The contract is formulated for the formalization and implementation of these obligations and benefits. Design By Contract can be summarized by three main questions that the designer must repeatedly ask:
What to expect?
what is being guaranteed?
What is maintained
There are numerous computer languages which can make assertions like these. But the uniqueness of Design By Contract is that it recognizes hat these contracts are crucial to software correctness that they should be part of the design process. Design By Contract advocates writing the assertions first.
The notion of a contract includes the various methods /procedures and the following informations:
Acceptable and Unacceptable value inputs or types and their meanings
Return values or types and heir meanings.
Conditioning of errors and exception hat can occur.
Taking care of side effects.
Pre-conditions that weakens.
Post conditions that strengthen
To know more about Design By Contract, log on to documentsandcontracts.com .
|
|
| |
|
|
|
|
|
|
