Citizendia

Design by Contract, DbC or Programming by Contract is an approach to designing computer software. It prescribes that software designers should define precise verifiable interface specifications for software components based upon the theory of abstract data types and the conceptual metaphor of a business contract. In Computing, an abstract data type ( ADT) is a specification of a set of data and the set of operations that can be performed on the data In Cognitive linguistics, conceptual metaphor refers to the understanding of one idea or Conceptual domain in terms of another for example understanding Quantity A contract is an exchange of promises between two or more parties to do or refrain from doing an act which is enforceable in a court of law

Because Design by Contract is a registered trademark[1] of Interactive Software Engineering, Inc. in the United States, many developers refer to it as Programming by Contract or Contract Programming or contract-first development.

Contents

History

The term was coined by Bertrand Meyer in connection with his design of the Eiffel programming language and first described in various articles starting in 1986[2][3][4] and the two successive editions (1988, 1997) of his book Object-Oriented Software Construction. Bertrand Meyer (born 1950 in France) is an academic author and consultant in the field of computer languages Eiffel is an ISO -standardized Object-oriented Programming language designed to enable programmers to efficiently develop extensible reusable reliable Object-Oriented Software Construction is the title of a book by Bertrand Meyer, widely considered a foundational text of Object-oriented programming. Eiffel Software applied for trademark registration for Design by Contract in December 2003, and it was granted in December 2004. [5][6] The current owner of these two trademarks is Interactive Software Engineering, Inc. [1][7]

Design by Contract has its roots in work on formal verification, formal specification and Hoare logic. In the context of hardware and software systems formal verification is the act of proving or disproving the Correctness of intended Algorithms underlying A formal specification is a mathematical description of Software or Hardware that may be used to develop an Implementation. Hoare logic (also known as Floyd&ndashHoare logic) is a Formal system developed by the British computer scientist C The original contributions include:

Description

The central idea of DbC is a metaphor on how elements of a software system collaborate with each other, on the basis of mutual obligations and benefits. The metaphor comes from business life, where a "client" and a "supplier" agree on a "contract" which defines for example that:

Similarly, if a routine from a class in object-oriented programming provides a certain functionality, it may :

The contract is the formalization of these obligations and benefits. One could summarize design by contract by the "three questions" that the designer must repeatedly ask:

Many languages have facilities to make assertions like these. A language is a dynamic set of visual auditory or tactile Symbols of Communication and the elements used to manipulate them In Computer programming, an assertion is a predicate (ie a true–false statement placed in a program to indicate that the developer thinks that the However, DbC is novel in recognizing that these contracts are so crucial to software correctness that they should be part of the design process. In effect, DbC advocates writing the assertions first.

The notion of a contract extends down to the method/procedure level; the contract for each method will normally contain the following pieces of information:

When using contracts, the program code itself must never try to verify the contract conditions; the whole idea is that code should "fail hard", with contract verification being the safety net. DbC's "fail hard" property makes debugging contract behavior much easier because the intended behaviour of each routine is clearly specified.

The contract conditions should never be violated in program execution; thus they can be either left in as debugging code or removed from the code altogether for performance reasons.

All class relationships are between Client classes and Supplier classes. A Client class is obliged to make calls to Supplier features where the resulting state of the Supplier is not violated by the Client call. Subsequently, the Supplier is obliged to provide a return state and data that does not violate the state requirements of the Client. For instance, a Supplier data buffer may require that data is present in the buffer when a delete feature is called. Subsequently, the Supplier guarantees to the client that when a delete feature finishes its work, the data item will, indeed, be deleted from the buffer. Other Design Contracts are concepts of "Class Invariant". The Class Invariant guarantees (for the local class) that the state of the class will be maintained within specified tolerances at the end of each feature execution.

Unit testing tests a module in isolation, to check that it meets its contract assuming its subcontractors meet theirs. In Computer programming, unit testing is a method of testing that verifies the individual units of Source code are working properly Integration testing checks whether the various modules are working properly together. 'Integration testing'(sometimes called Integration and Testing abbreviated I&T) is the phase of Software testing in which individual software modules are combined and tested Design by Contract also fosters code reuse, since the contract for each piece of code is fully documented. The contracts for a module can also be regarded as a form of software documentation for the behavior of that module. Software documentation or source code documentation is written text that accompanies Computer Software.

Non-technical analogy

A process in which a number of objects (people or software components, for example) interact to satisfy a goal is called a collaboration. Collaboration is a recursive process where two or more people or organizations work together toward an intersection of common goals — for example an intellectual When two objects collaborate together, one (the client) requests the services of the other (the supplier). The supplier in turn may request the services of other objects, and in those collaborations it is the client and they are the suppliers. The process only works correctly if all these individual collaborations work correctly. In a very real sense, the chain is only as strong as its weakest link.

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. In Computer programming, a postcondition is a condition or predicate that must always be true just after the execution of some section of code or after an operation The postcondition tells the client what will be true if the service is executed correctly (e. In Computer programming, a postcondition is a condition or predicate that must always be true just after the execution of some section of code or after an operation g. "your customer will be in Miami by 15:30 on June 8"). Events 68 - The Roman Senate accepts emperor Galba. 536 - St Silverius becomes Pope (probable

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. In Logic a precondition is a condition that has to be met before a main argument can have any value

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!

Design By Contract is a discipline for building software such that the collaborations between objects are correct. A formula for correctness when a client uses the services of a supplier is given as:

If the invariant AND precondition are true before using the service, then the invariant AND the postcondition will be true after the service has been completed.

In DbC, the responsibilities are clear: the client must satisfy the precondition. This distinguishes it markedly from a related practice known as defensive programming, where the supplier is responsible for figuring out what to do when a precondition is broken. Defensive programming is a form of Defensive design intended to ensure the continuing function of a piece of Software in spite of unforeseeable usage of said software More often than not, the supplier throws an exception to inform the client that the precondition has been broken, and in both cases - DbC and defensive programming - the client must figure out how to respond to that. DbC makes the supplier's job easier.

Language support

Languages with native support

Languages that implement most DbC features natively include:

Languages with third-party support

Various libraries, preprocessors and other tools have been developed for existing programming languages without native Design by Contract support:

Generic tools

See also

Bibliography

  1. ^ a b Current status of United States Patent and Trademark Office registration for "DESIGN BY CONTRACT"
  2. ^ Meyer, Bertrand: Design by Contract, Technical Report TR-EI-12/CO, Interactive Software Engineering Inc. Defensive programming is a form of Defensive design intended to ensure the continuing function of a piece of Software in spite of unforeseeable usage of said software The D programming language, also known simply as D, is an object-oriented, imperative, multiparadigm System programming language Eiffel is an ISO -standardized Object-oriented Programming language designed to enable programmers to efficiently develop extensible reusable reliable Hoare logic (also known as Floyd&ndashHoare logic) is a Formal system developed by the British computer scientist C Object-Oriented Software Construction is the title of a book by Bertrand Meyer, widely considered a foundational text of Object-oriented programming. Perfect Developer (PD is a tool for developing Computer programs in a rigorous manner by developing a formal specification and refining it to code SPARK is a formally-defined Computer programming language based on the Ada programming language intended to be secure and to Test-Driven Development (TDD is a Software development technique consisting of short iterations where new Test cases covering the desired improvement or , 1986
  3. ^ Meyer, Bertrand: Design by Contract, in Advances in Object-Oriented Software Engineering, eds. D. Mandrioli and B. Meyer, Prentice Hall, 1991, pp. 1-50
  4. ^ Meyer, Bertrand: Applying "Design by Contract", in Computer (IEEE), 25, 10, October 1992, pages 40-51, also available online
  5. ^ United States Patent and Trademark Office registration for "DESIGN BY CONTRACT"
  6. ^ United States Patent and Trademark Office registration for the graphic design with words "Design by Contract"
  7. ^ Current status of United States Patent and Trademark Office registration for the graphic design with words "Design by Contract"
  8. ^ Bright, Walter (2006-08-20). Year 2006 ( MMVI) was a Common year starting on Sunday of the Gregorian calendar. Events 636 - Battle of Yarmouk: Arab forces led by Khalid ibn al-Walid take control of Syria and Palestine D Programming Language, Contract Programming. Digital Mars. Retrieved on 2006-10-06. Year 2006 ( MMVI) was a Common year starting on Sunday of the Gregorian calendar. Events 105 BC - Battle of Arausio: The Cimbri inflict the heaviest defeat on the Roman army of Gnaeus Mallius Maximus

External links

© 2009 citizendia.org; parts available under the terms of GNU Free Documentation License, from http://en.wikipedia.org
 Dapyx Software network: MP3 Explorer | Ebook Manager | Zenithic