Revision as of 01:31, 16 November 2011

Introduction

Writing robust code

Assertions

Pre-Conditions

Post-Conditions

Class Invariants

A class invariant is a predicate that must be true at all points during a program. This is should hold no matter what a method does in the class.

Consider a stack. In a stack, the size should always be greater than 0 and less than the capacity. This should always hold. This property of a stack can neither be represented by a pre-condition nor by a post-condition. Such properties of a class are called as Class invariants.

The useful effect of class invariants in object-oriented software is enhanced in the presence of inheritance. Class invariants are inherited, that is, "the invariants of all the parents of a class apply to the class itself."<ref> Meyer, Bertrand. Object-Oriented Software Construction, second edition, Prentice Hall, 1997, p. 570</ref>

Programming By Contract=

Programming by Contract is known under the name of Design by Contract™ first implemented by Eiffel, a programming language introduced by Bertrand Meyer.It provides the programmers a way to verify that the execution of their methods does not corrupt the state of the data structures.

Definition

According to Bertrand Meyer,

By associating pre- and postcondition assertions with a method m,the class tells its clients1 “If you promise to call m with pre satisfied then I, in return, promise to deliver a final state in which post is satisfied"<ref> Meyer, Bertrand. Object-Oriented Software Construction, second edition, Prentice Hall, 1997, p. 570</ref>

In other words, "Basically programming by contract creates a contract between the software developer and software user - in Meyer's terms the supplier and the consumer. Every feature, or method, starts with a precondition that must be satisfied by the consumer of the routine. And each feature ends with postconditions which the supplier guarantees to be true (if and only if the preconditions were met). Also, each class has an invariant which must be satisfied after any changes to the object represented by the class. In the other words, the invariant guarantees the object is in a valid state."<ref>http://www.cs.unc.edu/~stotts/COMP204/contract.html</ref>

Obligations and benefits

There are two main elements in software system- User and Programmer. In order to understand Obligations and benefits correctly, let us first consider a metaphor and later apply that to Software. The metaphor comes from business life, where a "client" and a "supplier" agree on a "contract" which documents that:

* The supplier must provide a certain product (obligation) and is entitled to expect that the client has paid its fee (benefit).

* The client must pay the fee (obligation) and is entitled to get the product (benefit).

* Both parties must satisfy certain obligations, such as laws and regulations, applying to all contracts.<ref>http://www.eiffel.com/developers/design_by_contract.html</ref>

@@ Line 33: / Line 33: @@
 <span style="color:#008080">* The supplier must provide a certain product (obligation) and is entitled to expect that the client has paid its fee (benefit).</span>
 <span style="color:#A52A2A">* The client must pay the fee (obligation) and is entitled to get the product (benefit).</span>
 <span style="color:#483D8B">* Both parties must satisfy certain obligations, such as laws and regulations, applying to all contracts.</span><ref>http://www.eiffel.com/developers/design_by_contract.html</ref>

CSC/ECE 517 Fall 2011/ch6 6a am: Difference between revisions