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

Slides:



Advertisements
Similar presentations
Where Agile Meets Formal Methods
Advertisements

Design by Contract.
Carlos D. Rivera February 28, 2007 Design-by-Contract.
Addressing the Challenges of Current Software. Questions to Address Why? What? Where? How?
Software Quality Assurance Plan
Key-word Driven Automation Framework Shiva Kumar Soumya Dalvi May 25, 2007.
Building bug-free O-O software: An introduction to Design by Contract Eiffel Software Presented by Bert Bruce.
1 Design by Contract Building Reliable Software. 2 Software Correctness Correctness is a relative notion  A program is correct with respect to its specification.
Design by Contract ™. 2 Design by Contract A discipline of analysis, design, implementation, management.
Jan 2005 Ron McFadyen1 Contracts Used to help understand requirements more completely (and so may not always be necessary) based on assertions;
Chair of Software Engineering OOSC - Summer Semester Object-Oriented Software Construction Bertrand Meyer Lecture 10: Project Presentation Ilinca.
Static and Dynamic Contract Verifiers For Java Hongming Liu.
Chair of Software Engineering Einführung in die Programmierung Introduction to Programming Prof. Dr. Bertrand Meyer Lecture 4: The Interface of a Class.
Chair of Software Engineering Einführung in die Programmierung Introduction to Programming Prof. Dr. Bertrand Meyer Lecture 4: The Interface of a Class.
Illinois Institute of Technology
Karlstad University Computer Science Design Contracts and Error Management Design Contracts and Errors A Software Development Strategy (anpassad för PUMA)
Chapter 1 Principles of Programming and Software Engineering.
1 Introduction to: Design by Contract Fall 2005 OOPD John Anthony.
Eiffel Language and Design by Contract Contract –An agreement between the client and the supplier Characteristics –Expects some benefits and is prepared.
1 ES 314 Advanced Programming Lec 2 Sept 3 Goals: Complete the discussion of problem Review of C++ Object-oriented design Arrays and pointers.
© 2006 Pearson Addison-Wesley. All rights reserved2-1 Chapter 2 Principles of Programming & Software Engineering.
1 © Wolfgang Pelz Design by Contract Design by Contract™ Based on material drawn from: Bertrand.
C++ fundamentals.
Data Structures and Programming.  John Edgar2.
Computer Science 340 Software Design & Testing Design By Contract.
Ranga Rodrigo. Class is central to object oriented programming.
ISO Tor Stålhane IDI / NTNU. What is ISO ISO 9001 was developed for the production industry but has a rather general structure ISO describes.
Topics Covered: Software requirement specification(SRS) Software requirement specification(SRS) Authors of SRS Authors of SRS Need of SRS Need of SRS.
1 Debugging and Testing Overview Defensive Programming The goal is to prevent failures Debugging The goal is to find cause of failures and fix it Testing.
Introduction CS 3358 Data Structures. What is Computer Science? Computer Science is the study of algorithms, including their  Formal and mathematical.
SENG521 (Fall SENG 521 Software Reliability & Testing Software Product & process Improvement using ISO (Part 3d) Department.
SAMANVITHA RAMAYANAM 18 TH FEBRUARY 2010 CPE 691 LAYERED APPLICATION.
What is a Business Analyst? A Business Analyst is someone who works as a liaison among stakeholders in order to elicit, analyze, communicate and validate.
Design by Contract in Java Concept and Comparison.
Low-Level Detailed Design SAD (Soft Arch Design) Mid-level Detailed Design Low-Level Detailed Design Design Finalization Design Document.
Cohesion and Coupling CS 4311
Introduction CS 3358 Data Structures. What is Computer Science? Computer Science is the study of algorithms, including their  Formal and mathematical.
CS Data Structures I Chapter 2 Principles of Programming & Software Engineering.
Managing Change 1. Why Do Requirements Change?  External Factors – those change agents over which the project team has little or no control.  Internal.
© 2006 Pearson Addison-Wesley. All rights reserved2-1 Chapter 2 Principles of Programming & Software Engineering.
LECTURE 20 26/11/15. Summary - Testing ◦ Testing affects all stages of software engineering cycle ◦ One strategy is a bottom-up approach – class, integration,
© 2006 Pearson Addison-Wesley. All rights reserved 2-1 Chapter 2 Principles of Programming & Software Engineering.
CS 1120: Computer Science II Software Life Cycle Slides courtesy of: Prof. Ajay Gupta and Prof. James Yang (format and other minor modifications by by.
1 Devon M. Simmonds, Computer Science Department Design by Contract Devon M. Simmonds Computer Science Department University of North Carolina, Wilmington.
Lecture 13.  Failure mode: when team understands requirements but is unable to meet them.  To ensure that you are building the right system Continually.
ANU COMP2110 Software Design in 2003 Lecture 10Slide 1 COMP2110 Software Design in 2004 Lecture 12 Documenting Detailed Design How to write down detailed.
SWE 4743 Abstract Data Types Richard Gesick. SWE Abstract Data Types Object-oriented design is based on the theory of abstract data types Domain.
Chapter 1 Data Abstraction: The Walls CS Data Structures Mehmet H Gunes Modified from authors’ slides.
PROGRAMMING PRE- AND POSTCONDITIONS, INVARIANTS AND METHOD CONTRACTS B MODULE 2: SOFTWARE SYSTEMS 13 NOVEMBER 2013.
Chapter 2 Principles of Programming and Software Engineering.
DBC NOTES. Design By Contract l A contract carries mutual obligations and benefits. l The client should only call a routine when the routine’s pre-condition.
Chapter 1 The Phases of Software Development. Software Development Phases ● Specification of the task ● Design of a solution ● Implementation of solution.
SE513 Software Quality Assurance Lecture12: Software Reliability and Quality Management Standards.
Design by Contract. The Goal Ensure the correctness of our software (correctness) Recover when it is not correct anyway (robustness) Correctness: Assertions.
7 Systems Analysis – ITEC 3155 The Object Oriented Approach – Use Cases.
Alex Ezrakhovich Process Approach for an Integrated Management System Change driven.
 System Requirement Specification and System Planning.
MANAGEMENT INFORMATION SYSTEM
Principles of Programming & Software Engineering
Classifications of Software Requirements
Design by Contract Jim Fawcett CSE784 – Software Studio
Design by Contract Jim Fawcett CSE784 – Software Studio
Coupling and Cohesion 1.
SEVERITY & PRIORITY RELATIONSHIP
Component Based Software Engineering
Principles of Programming and Software Engineering
Quality Management Systems – Requirements
Introduction to Software Testing
CS 1120: Computer Science II Software Life Cycle
CS 1120: Computer Science II Software Life Cycle
Presentation transcript:

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 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 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 For Eiffel Software. Available at ology/contract/page.html. ology/contract/page.html The page above contains links for more information about Eiffel