CSC/ECE 517 Fall 2007/wiki3 2 dp: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
No edit summary |
||
| Line 15: | Line 15: | ||
<p> | <p> | ||
<pre> | <pre> | ||
• Preconditions - Certain obligations need to be fulfilled by any module which calls the software | • Preconditions - Certain obligations need to be fulfilled by any module which calls the software component are | ||
component are called as pre-conditions. The module making the call is called the client. The preconditions | called as pre-conditions. The module making the call is called the client. The preconditions are the obligations | ||
are the obligations that the client needs to fulfill and are benefits for the software component, called the | that the client needs to fulfill and are benefits for the software component, called the supplier, as it frees the | ||
supplier, as it frees the supplier from having to handle cases outside of the precondition. | supplier from having to handle cases outside of the precondition. | ||
• Postconditions - The supplier in turn, needs to guarantee certain outputs or certain properties on | • Postconditions - The supplier in turn, needs to guarantee certain outputs or certain properties on exit. These | ||
exit. These set of properties are called the supplier's postconditions. These postconditions are obligations | set of properties are called the supplier's postconditions. These postconditions are obligations for the supplier, | ||
for the supplier, and benefits for the client obtained from calling the supplier module. | and benefits for the client obtained from calling the supplier module. | ||
• Class invariant - The supplier needs to maintain a certain property that is assumed to exist on entry | • Class invariant - The supplier needs to maintain a certain property that is assumed to exist on entry and is | ||
and is guaranteed on exit, called the class invariant. | guaranteed on exit, called the class invariant. | ||
</pre> | </pre> | ||
</p> | </p> | ||
Revision as of 16:51, 17 November 2007
Topic
Find some concise examples that illustrate the principle of programming by contract, and are accessible to a general audience of programmers.
Definition
Programming by contract is a software development approach that enforces the developers to define concrete and verifiable interface specifications for the software code. It is based on the theory of a business contract.
Norms of the contract
The core idea of programming by contract is how components of a software system collaborate with each other on the basis of mutual obligations and benefits. The concept is drawn from the business domain where clients and suppliers agree on a contract that defines certain norms. The corresponding norms that one can associate with a software system are –
• Preconditions - Certain obligations need to be fulfilled by any module which calls the software component are called as pre-conditions. The module making the call is called the client. The preconditions are the obligations that the client needs to fulfill and are benefits for the software component, called the supplier, as it frees the supplier from having to handle cases outside of the precondition. • Postconditions - The supplier in turn, needs to guarantee certain outputs or certain properties on exit. These set of properties are called the supplier's postconditions. These postconditions are obligations for the supplier, and benefits for the client obtained from calling the supplier module. • Class invariant - The supplier needs to maintain a certain property that is assumed to exist on entry and is guaranteed on exit, called the class invariant.