Loading in 2 Seconds...
Loading in 2 Seconds...
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.
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
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
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
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
Specification • Stating precisely what a module is supposed to do helps ensure its correctness and adds to software reliability
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
Conventional legal contract • Example: terms of a contract between an airline and a customer
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
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
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
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)
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]
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
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
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
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
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)
Other features of Eiffel • The Eiffel language also includes features that support:- Documentation- Testing, debugging, quality assurance- Exception handling
Article Information • Meyer, Bertrand. "Building Bug-Free O-O Software: An Introduction to Design By Contract." Published June 2000. For Eiffel Software. Available at http://archive.eiffel.com/doc/manuals/technology/contract/page.html. • The page above contains links for more information about Eiffel