building bug free o o software an introduction to design by contract n.
Skip this Video
Loading SlideShow in 5 Seconds..
Building Bug-Free O-O Software: An Introduction to Design By Contract PowerPoint Presentation
Download Presentation
Building Bug-Free O-O Software: An Introduction to Design By Contract

Loading in 2 Seconds...

play fullscreen
1 / 19

Building Bug-Free O-O Software: An Introduction to Design By Contract - PowerPoint PPT Presentation

Download Presentation
Building Bug-Free O-O Software: An Introduction to 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. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Building Bug-Free O-O Software: An Introduction to Design By Contract A presentation about Design By Contract and the Eiffel software development tool Presented by: Ed Kausmeyer

  2. Software Reliability • The ability of a system to perform its job according to the specification (correctness) and to handle abnormal situations (robustness) • Especially important in the object-oriented approach because of the special role reusability plays in object orientation- Much time and effort can be saved if you can reuse component libraries produced and validated by a reputable outside source rather than developing your own solution for every single problem you encounter

  3. Design By Contract • Method that helps design reliable object-oriented software • Views a software system as a group of communicating components, each of which has an associated contract (specification) • Systematic approach to specifying and implementing object-oriented software elements and their relations in a software system

  4. Benefits of Design By Contract • A better understanding of software construction and of the object-oriented method • Effective framework for debugging, testing, and software quality assurance • A method for documenting software components • Better understanding and control of the inheritance mechanism • A technique for dealing with abnormal cases, leading to a safe and effective language construct for exception handling

  5. Specification • Stating precisely what a module is supposed to do helps ensure its correctness and adds to software reliability

  6. Conventional legal contract • Written between two parties- one party (the supplier) performs a task for the other (the client) • Each party expects some benefits from the contract and accepts some obligations in return • Protects both parties- client: specifies how much should be done- supplier: states the supplier is not liable for failing to carry out tasks outside of the specified scope

  7. Conventional legal contract • Example: terms of a contract between an airline and a customer

  8. Drawing a comparison between legal contracts and software specifications • Design By Contract entails associating a specification with every software element • A specification governs the interaction between software components and defines the mutual obligations and benefits of a routine and any potential caller • Thus, a specification is a contract; it states what each party must guarantee for a correct call and what each party is entitled to in return

  9. Drawing a comparison between legal contracts and software specifications • To fulfill its own contract, a module follows a strategy that contains a number of subtasks • If one of the subtasks is non-trivial, it will be achieved by calling a certain routine; that is, the calling module “contracts out” the subtask to the routine

  10. Example of a contract • Consider a routine that inserts an element into a dictionary (a table where each element is identified by a certain character string used as key) of bounded capacity

  11. The Eiffel software development tool • Provides a framework that incorporates Design By Contract concepts • The specification, design, and programming languages are rolled into one • Facilitates efficient implementation • Preserves a key property of an object-oriented process: its seamlessness • Use a single notation and a single set of concepts throughout the software lifecycle, from analysis to implementation and maintenance • Better mapping from problem to solution and smoother evolution (the intent of an object-oriented design)

  12. Eiffel and Design By Contract • Next slide shows an Eiffel routine called put that inserts an element into a dictionary and that is part of a generic class DICTIONARY [ELEMENT]

  13. put (x: ELEMENT; key: STRING) is-- Insert x so that it will be retrievable through key. require -- input condition (precondition) count <= capacity not key.empty do < an insertion algorithm > ensure -- output condition (postcondition) has (x) item (key) = x count = old count + 1 end • NOTE:- count is the current number of elements- capacity is the maximum number- has is a boolean query which tells whether a certain element is present- item returns the element associated with a certain key- old count refers to the value of count on entry to the routine

  14. The “deferred” clause of the Eiffel language • If the "deferred" clause was used instead of the "do" clause in the previous routine, the implementation could be delayed and the notation would just serve as a modeling tool • This style of analysis avoids the risk of making premature implementation commitments while still providing a way to state and clarify delicate properties of the system

  15. Classes in Eiffel • Classes can be designed and implemented in the Eiffel language- Interface- Class invariant: from the Design By Contract point of view, this is a general clause that applies to the entire set of contracts defining a class

  16. Example of an interface in Eiffel class interface DICTIONARY [ELEMENT] feature put (x: ELEMENT; key: STRING) is -- Insert x so that it will be retrievable through key require count <= capacity not key.empty ensure has (x) item (key) = x count = old count + 1 <Interface specifications of other features> invariant 0 <= count count <= capacity end -- class interface DICTIONARY

  17. The principle of subcontracting • Suppose that class B inherits features from a superclass A and that both classes have an implementation of a routine r (polymorphism) • Assume object a is declared statically as an instance of class A but in fact is attached to an object of type B at run time, in which case the call a.r will actually invoke the B version of r (dynamic binding); this means A subcontracts r to B • The principle of subcontracting states that a redefined version of r must keep or weaken the original precondition of the routine, and keep or strengthen the original postcondition in order for the call to be executed correctly (a subcontractor must be bound by the original contract)

  18. Other features of Eiffel • The Eiffel language also includes features that support:- Documentation- Testing, debugging, quality assurance- Exception handling

  19. Article Information • Meyer, Bertrand. "Building Bug-Free O-O Software: An Introduction to Design By Contract." Published June 2000. For Eiffel Software. Available at • The page above contains links for more information about Eiffel