CSC/ECE 517 Fall 2007/wiki3 2 bp: Difference between revisions
No edit summary |
No edit summary |
||
Line 21: | Line 21: | ||
<pre> | <pre> | ||
Take the process of going on holiday, for example. Bertrand wants to spend two weeks in Florida. He books the | Take the process of going on holiday, for example. Bertrand wants to spend two weeks in Florida. He books the | ||
holiday through DBC Holidays Inc., who specialise in U.S. package holidays. When he makes the booking (collaboration | holiday through DBC Holidays Inc., who specialise in U.S. package holidays. When he makes the booking | ||
#1), Bertrand is the client and DBC Holidays are the supplier. DBC Holidays then arrange flights through Assertair | (collaboration #1), Bertrand is the client and DBC Holidays are the supplier. DBC Holidays then arrange flights | ||
Corp. (collaboration #2), and book a room at the Precondition Plaza Hotel in Miami (collaboration #3). In | through Assertair Corp. (collaboration #2), and book a room at the Precondition Plaza Hotel in Miami | ||
collaboration #2, DBC Holidays are the client and Assertair is the supplier, and in collaboration #3, the hotel is the | (collaboration #3). In collaboration #2, DBC Holidays are the client and Assertair is the supplier, and in | ||
supplier. And the chain of collaborations goes deeper and deeper (e.g., who does Assertair pay to service their jets?) | collaboration #3, the hotel is the supplier. And the chain of collaborations goes deeper and deeper (e.g., who | ||
does Assertair pay to service their jets?) | |||
If any link in this chain of collaborations breaks, then the result could be that Bertrand's holiday is ruined. It's | If any link in this chain of collaborations breaks, then the result could be that Bertrand's holiday is ruined. | ||
vital, therefore, that every player in the collaboration does what they're supposed to do. In any collaboration, | It's vital, therefore, that every player in the collaboration does what they're supposed to do. In any | ||
client and supplier have certain obligations. These obligations (or "responsibilities", if you like) fall into three | collaboration, client and supplier have certain obligations. These obligations (or "responsibilities", if you | ||
distinct types: | like) fall into three distinct types: | ||
1. Things that the supplier promises to do as part of the service it offers to the client (e.g., Assertair | 1. Things that the supplier promises to do as part of the service it offers to the client (e.g., Assertair | ||
DBC Holidays that Bertrand will be in Miami at a certain date and time) | promises DBC Holidays that Bertrand will be in Miami at a certain date and time) | ||
2. Things that the client promises to do before using the service (e.g., DBC Holidays must ensure that Bertrand has | 2. Things that the client promises to do before using the service (e.g., DBC Holidays must ensure that | ||
Bertrand has his passport and tickets when he checks in for his flight) | |||
3. Things that the supplier promises will always be true no matter what happens (e.g., The airline will always have | 3. Things that the supplier promises will always be true no matter what happens (e.g., The airline will | ||
always have adequate insurance to cover any accident) | |||
Things that the supplier promises to do as part of the service are described as a special kind of rule called a | Things that the supplier promises to do as part of the service are described as a special kind of rule called a | ||
postcondition. The postcondition tells the client what will be true if the service is executed correctly (e.g., "your | postcondition. The postcondition tells the client what will be true if the service is executed correctly (e.g., | ||
customer will be in Miami by 15:30 on June 8"). | "your customer will be in Miami by 15:30 on June 8"). | ||
If Bertrand turns up at the check-in desk without his passport, of course, then the airline can't live up to its side of | If Bertrand turns up at the check-in desk without his passport, of course, then the airline can't live up to its | ||
the contract: he will not be allowed to board the plane without it. A rule that the client must satisfy before using a | side of the contract: he will not be allowed to board the plane without it. A rule that the client must satisfy | ||
service is called a precondition. | before using a service is called a precondition. | ||
A rule that states what must always be true is called an invariant. If the airline doesn't have adequate insurance then | A rule that states what must always be true is called an invariant. If the airline doesn't have adequate | ||
nobody is going anywhere! | insurance then nobody is going anywhere! | ||
</pre> | </pre> | ||
Revision as of 02:17, 12 November 2007
Programming by Contract
Purpose of this Wiki
This wiki page was created to address the following assignment:
In class, we had some difficulty coming up with good examples of programming by contract. Find some concise ones that illustrate the principle well, and are accessible to a general audience of programmers.
Overview
Programming by Contract originated with the Eiffel programming language. It is a technique for designing software systems in such a way that all the pieces meet certain obligations to each other. If all obligations are correctly met, then the system as a whole will work correctly.
The obligations are defined in terms of suppliers (components that offer a method that can be invoked) and clients (components that invoke those methods). Suppliers must provide the service they are contracted to provide (known as a postcondition), and clients must respect the restrictions of the supplier (known as a precondition).
Examples
Real World Examples
Examples in this section are based around real world metaphors and do not rely on programming specific concepts such as classes, methods, etc.
Example 1, taken from http://en.wikipedia.org/wiki/Design_by_contract
Take the process of going on holiday, for example. Bertrand wants to spend two weeks in Florida. He books the holiday through DBC Holidays Inc., who specialise in U.S. package holidays. When he makes the booking (collaboration #1), Bertrand is the client and DBC Holidays are the supplier. DBC Holidays then arrange flights through Assertair Corp. (collaboration #2), and book a room at the Precondition Plaza Hotel in Miami (collaboration #3). In collaboration #2, DBC Holidays are the client and Assertair is the supplier, and in collaboration #3, the hotel is the supplier. And the chain of collaborations goes deeper and deeper (e.g., who does Assertair pay to service their jets?) If any link in this chain of collaborations breaks, then the result could be that Bertrand's holiday is ruined. It's vital, therefore, that every player in the collaboration does what they're supposed to do. In any collaboration, client and supplier have certain obligations. These obligations (or "responsibilities", if you like) fall into three distinct types: 1. Things that the supplier promises to do as part of the service it offers to the client (e.g., Assertair promises DBC Holidays that Bertrand will be in Miami at a certain date and time) 2. Things that the client promises to do before using the service (e.g., DBC Holidays must ensure that Bertrand has his passport and tickets when he checks in for his flight) 3. Things that the supplier promises will always be true no matter what happens (e.g., The airline will always have adequate insurance to cover any accident) Things that the supplier promises to do as part of the service are described as a special kind of rule called a postcondition. The postcondition tells the client what will be true if the service is executed correctly (e.g., "your customer will be in Miami by 15:30 on June 8"). If Bertrand turns up at the check-in desk without his passport, of course, then the airline can't live up to its side of the contract: he will not be allowed to board the plane without it. A rule that the client must satisfy before using a service is called a precondition. A rule that states what must always be true is called an invariant. If the airline doesn't have adequate insurance then nobody is going anywhere!
Programming Based Examples
Examples in this section use terms which are more specific to programming, defining themselves in terms of classes, methods, and pseudocode. In keeping with the goal of having the examples be accessible to the general audience of programmers, examples using exotic/rare programming languages were excluded.
References
The overview and examples above were drawn from the following sources: