1 / 5

Design by Contract

Design by Contract. Phil Pratt- Szeliga CSE 784 - 2010 Derived from slides by : Dr. Jim Fawcett Paraphrased from works of Bertrand Meyer Interactive Software Engineering, www.eiffel.com. Motivation.

veda-cote
Télécharger la présentation

Design by Contract

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Design by Contract Phil Pratt-Szeliga CSE 784 - 2010Derived from slides by : Dr. Jim Fawcett Paraphrased from works of Bertrand Meyer Interactive Software Engineering, www.eiffel.com

  2. Motivation • “Reliability … is particularly important in the object-oriented method because of the special role given by the method to reusability:” • “Unless we can obtain reusable software components whose correctness we can trust … reusability is a losing proposition.” • “To be sure that our object-oriented software will perform properly, we need a systematic approach to specifying and implementing … software elements and their relations …” • “Under the Design by Contract theory, a software system is viewed as a set of communicating components whose interaction is based on precisely defined specifications of the mutual obligations – contracts.” All quotes here and in the following pages from Bertrand Meyer: www.eiffel.com/doc/manuals/technology/contract

  3. Preconditions and Postconditions • An Eiffel Example from ISE:In Eiffel syntax, a routine put, that is part of a generic class DICTIONARY [ELEMENT], might be defined by: put (x: ELEMENT; key: STRING)is -- Insert x so that it will be retrievable through key. require count <= capacity notkey.empty do ... Some insertion algorithm ... ensure has (x) item (key) = x count = old count + 1 end • If any of the post conditions are not met, an exception is thrown

  4. Contract Documentation • “A short form, which is stripped of all implementation information but retains the essential usage information: the contract … .”class interface DICTIONARY [ELEMENT]feature put (x: ELEMENT; key: STRING)is-- Insert x so that it will be retrievable -- through key.requirecount <= capacitynotkey.emptyensurehas (x)item (key) = xcount = old count + 1... Interface specifications of other features Invariant0 <= count count <= capacityend -- class interface DICTIONARY

  5. Subcontracting with inheritance • “The principle of subcontracting follows from these observations: • a redefined version of r may keep or weaken the precondition [by removing conditions in require clause, e.g., on callers]; • it may keep or strengthen the postcondition[by adding conditions in ensure clause, e.g., on implementation]. • Strengthening the precondition, or weakening the postcondition, would be a case of "dishonest subcontracting" and could lead to disaster. The Eiffel language rules for assertion redefinition … support the principle of subcontracting.” • “These observations shed light on the true significance of inheritance: • not just a reuse, subtyping and classification mechanism, but a way to ensure compatible semantics by other means. They also provide useful guidance as to how to use inheritance properly.”

More Related