L13: Design by Contract Definition Reliability Correctness Pre- and post-condition Asserts and Exceptions Weak & Strong Conditions Class invariants Conditions.

Slides:



Advertisements
Similar presentations
Where Agile Meets Formal Methods
Advertisements

Copyright © 2006 The McGraw-Hill Companies, Inc. Programming Languages 2nd edition Tucker and Noonan Chapter 18 Program Correctness To treat programming.
Design by Contract.
Design By Contract Using JMSAssert.
Ceg860(Prasad)L10DC1 Design by Contract Invariants Pre-post conditions : Rights and Obligations Exceptions : Contract Violations.
Carlos D. Rivera February 28, 2007 Design-by-Contract.
Karlstad University Computer Science Design Contracts and Error Management Design Contracts and Errors A Software Development Strategy Eivind J. Nordby.
Practice Session 5 Java: Packages Collection Classes Iterators Generics Design by Contract Test Driven Development JUnit.
1 Computer Science 340 Software Design & Testing Inheritance & Design By Contract.
Chair of Software Engineering OOSC - Summer Semester Object-Oriented Software Construction Bertrand Meyer.
Data Abstraction II SWE 619 Software Construction Last Modified, Spring 2009 Paul Ammann.
1 Design by Contract Building Reliable Software. 2 Software Correctness Correctness is a relative notion  A program is correct with respect to its specification.
Feb 2003 R McFadyen1 Contracts (Ch 13) Used to help understand requirements more completely based on assertions; assertions are applicable to any.
Stacks CS-240 Dick Steflik. Stacks Last In, First Out operation - LIFO As items are added they are chronologically ordered, items are removed in reverse.
Design by Contract. Specifications Correctness formula (Hoare triple) {P} A {Q} – A is some operation (for example, a routine body) – P and Q are predicates.
Jan 2005 Ron McFadyen1 Contracts Used to help understand requirements more completely (and so may not always be necessary) based on assertions;
ESC Java. Static Analysis Spectrum Power Cost Type checking Data-flow analysis Model checking Program verification AutomatedManual ESC.
1 Specifying Object Interfaces. 2 Major tasks in this stage: --are there any missing attributes or operations? --how can we reduce coupling, make interface.
Software Testing and Quality Assurance
Chair of Software Engineering ATOT - Lecture 12, 12 May Advanced Topics in Object Technology Bertrand Meyer.
Static and Dynamic Contract Verifiers For Java Hongming Liu.
Chair of Software Engineering Concurrent Object-Oriented Programming Prof. Dr. Bertrand Meyer Lecture 9: Contracts and Inheritance (based on work with.
1 Introduction to: Design by Contract Fall 2005 OOPD John Anthony.
Design by Contract David Talby. Software Correctness When is a class correct? – It ’ s a relative concept; what is required? – But it ’ s the correct.
Stacks  Standard operations: IsEmpty … return true iff stack is empty Top … return top element of stack Push … add an element to the top of the stack.
Describing Syntax and Semantics
Eiffel Language and Design by Contract Contract –An agreement between the client and the supplier Characteristics –Expects some benefits and is prepared.
Subclasses and Subtypes CMPS Subclasses and Subtypes A class is a subclass if it has been built using inheritance. ▫ It says nothing about the meaning.
Computer Science 340 Software Design & Testing Design By Contract.
Ranga Rodrigo. Class is central to object oriented programming.
© Bertrand Meyer and Yishai Feldman Notice Some of the material is taken from Object-Oriented Software Construction, 2nd edition, by Bertrand Meyer (Prentice.
Contract based programming Using pre- and post-conditions, and object invariants Contract based programming1.
Design by Contract in Java Concept and Comparison.
SWE 619 © Paul Ammann Procedural Abstraction and Design by Contract Paul Ammann Information & Software Engineering SWE 619 Software Construction cs.gmu.edu/~pammann/
111 Protocols CS 4311 Wirfs Brock et al., Designing Object-Oriented Software, Prentice Hall, (Chapter 8) Meyer, B., Applying design by contract,
Low-Level Detailed Design SAD (Soft Arch Design) Mid-level Detailed Design Low-Level Detailed Design Design Finalization Design Document.
OOSCCh11r1:DbC RJL Slide #1 OOSC: Ch11 vs. Predecessors [Meyer:] Equipped with the basic concepts of class, object and genericity, you can by now.
Design by Contract Ranga Rodrigo based on Mark Priestley's Lectures.
Programming with Assertions © Allan C. Milne v
Protocols Software Engineering II Wirfs Brock et al, Designing Object-Oriented Software, Prentice Hall, Mitchell, R., and McKim, Design by Contract,
1 Devon M. Simmonds, Computer Science Department Design by Contract Devon M. Simmonds Computer Science Department University of North Carolina, Wilmington.
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.
Defensive Programming CNS 3370 Copyright 2003, Fresh Sources, Inc.
PROGRAMMING PRE- AND POSTCONDITIONS, INVARIANTS AND METHOD CONTRACTS B MODULE 2: SOFTWARE SYSTEMS 13 NOVEMBER 2013.
CSSE501 Object-Oriented Development. Chapter 10: Subclasses and Subtypes  In this chapter we will explore the relationships between the two concepts.
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.
1 Exceptions When the Contract is Broken. 2 Definitions A routine call succeeds if it terminates its execution in a state satisfying its contract A routine.
Object Design More Design Patterns Object Constraint Language Object Design Specifying Interfaces Review Exam 2 CEN 4010 Class 18 – 11/03.
Design by Contract. The Goal Ensure the correctness of our software (correctness) Recover when it is not correct anyway (robustness) Correctness: Assertions.
© Bertrand Meyer and Yishai Feldman Notice Some of the material is taken from Object-Oriented Software Construction, 2nd edition, by Bertrand Meyer (Prentice.
Laurea Triennale in Informatica – Corso di Ingegneria del Software I – A.A. 2006/2007 Andrea Polini IX. System Models (III)
Sections 3.4 Formal Specification
Class Invariants Class invariants are logical conditions to ensure the correct working of a class. Class invariants must hold true when an object is created,
Chapter 6 CS 3370 – C++ Functions.
Design by Contract Jim Fawcett CSE784 – Software Studio
Design by Contract Jim Fawcett CSE784 – Software Studio
Used to help understand requirements more completely
Methods The real power of an object-oriented programming language takes place when you start to manipulate objects. A method defines an action that allows.
Specifying Object Interfaces
Design by contract Object-Oriented Software Construction by Bertrand Meyer, Prentice Hall The presence of a precondition or postcondition in a routine.
Design by contract Object-Oriented Software Construction by Bertrand Meyer, Prentice Hall The presence of a precondition or postcondition in a routine.
Test Driven Development
Protocols CS 4311 Wirfs Brock et al., Designing Object-Oriented Software, Prentice Hall, (Chapter 8) Meyer, B., Applying design by contract, Computer,
Test Driven Development
Stacks CS-240 Dick Steflik.
Assertions References: internet notes; Bertrand Meyer, Object-Oriented Software Construction; 4/25/2019.
Computer Science 340 Software Design & Testing
Class Invariants Pre-conditions and post-conditions describe the properties of individual methods. A class invariant is a global property of the instances.
Contract-Based Programming with/without Ada 2012
Presentation transcript:

L13: Design by Contract Definition Reliability Correctness Pre- and post-condition Asserts and Exceptions Weak & Strong Conditions Class invariants Conditions for Class Correctness

Design by Contract Introduced by Bertrand Meyer and supported by Eiffel. Improves reliability

3 What is it? Viewing the relationship between a class and its clients as a formal agreement, expressing each party’s rights and obligations!

4 What is Reliability? Correctness: software must perform according to its specification Robustness: software’s ability to react to cases not included in the specification

5 Correctness A software system or element is neither correct nor incorrect on its own It is correct or incorrect with respect to a certain specification

6 Correctness Formulae Is an expression of the form: {P} A {Q} Which means: –Any execution of A, starting in a state where P holds, will terminate in a state where Q holds Eg {x>=9} x=x+5 {x>=13}

7 Preconditions and Postconditions {P} and {Q} are examples of preconditions and postconditions respectively For good programming, we need to: –document our pre- and postconditions –ensure the preconditions are true prior to executing a method –ensure the postconditions are true following method execution

8 How to? Two methods: use asserts use exceptions (L10: Exceptions)‏

9 Using assert #include void sort(vector *vec) { // precondition assert(vec!=NULL); //... actually sort the vector // postcondition assert(is_sorted(*vec)); };

10 Alternative assert #include void sort(vector *vec) { struct DBC { DBC(vector *v):vec(v){ assert(vec!=NULL);}; ~DBC(){assert(is_sorted(*vec));}; vector *vec; } dbc(vec); //... actually do the sorting }

11 class PrecondException { PreconditionException() {} } class PostcondException { PostconditionException() {} } class Assertion { public: static void require(boolean expr) { if ( !expr ) throw PreconditionException(); } static void ensure (boolean expr) { if ( !expr ) throw PostconditionException(); }

12 An Example - Stack template class Stack { private: T *data; int num_elements; int max_elements; public: Stack(int ne): max_elements(ne),num_elements(0) { data = new T[ne]; }; T pop(){...}; void push(T elem){...}; T peek(){...}; }

13 Push (element)‏ Require: stack is not full. Ensure: stack is not empty, top = element, count++.

14 Pop()‏ Require: stack is not empty Ensure: stack is not full, count--.

15 Weak and Strong Conditions Weak conditions: {...} A {True} // this ensures termination with a state. {False} A {...}

16 Class Invariants Are global properties of the instance of a class which must be preserved by all methods Eg: (num_elements >= 0)&& (num_elements < data.length)‏

17 How do we Apply Them? In general, a class invariant means that for each method: {INV && pre} body {INV && post} So, we should check at the start and end of each method. But, since invariants are invariant, it makes sense to bundle these checks into a method of their own.

18 When is a Class Correct? A class is correct if and only if its implementation is consistent with the preconditions, postconditions and invariants.

19 Correctness Defined A class, C, is correct if and only if: –For any valid set of arguments, x p, to a constructor, p: {pre p (x p )} Body p {post p (x p ) && INV} –For every public method, r, and any set of valid arguments, x r : {pre r (x r ) && INV} Body r { post r (x r ) && INV}