Chair of Software Engineering ATOT - Lecture 10, 5 May 2003 1 Advanced Topics in Object Technology Bertrand Meyer.

Slides:



Advertisements
Similar presentations
Where Agile Meets Formal Methods
Advertisements

Automated Theorem Proving Lecture 1. Program verification is undecidable! Given program P and specification S, does P satisfy S?
Design by Contract.
Ceg860(Prasad)L10DC1 Design by Contract Invariants Pre-post conditions : Rights and Obligations Exceptions : Contract Violations.
Building Bug-Free O-O Software: An Introduction to Design By Contract A presentation about Design By Contract and the Eiffel software development tool.
Karlstad University Computer Science Design Contracts and Error Management Design Contracts and Errors A Software Development Strategy Eivind J. Nordby.
Chair of Software Engineering OOSC - Summer Semester Object-Oriented Software Construction Bertrand Meyer Lecture 3: Abstract Data Types.
Building bug-free O-O software: An introduction to Design by Contract Eiffel Software Presented by Bert Bruce.
Chair of Software Engineering Software Architecture Bertrand Meyer, Carlo A. Furia, Martin Nordio ETH Zurich, February-May 2011 Lecture 15: Design by.
Chair of Software Engineering Software Architecture Prof. Dr. Bertrand Meyer Lecture 4: Design by Contract.
Chair of Software Engineering OOSC - Summer Semester Object-Oriented Software Construction Bertrand Meyer.
Chair of Software Engineering Software Architecture Prof. Dr. Bertrand Meyer Lecture 6: Exception Handling.
1 Design by Contract Building Reliable Software. 2 Software Correctness Correctness is a relative notion  A program is correct with respect to its specification.
Chair of Software Engineering OOSC - Summer Semester Object-Oriented Software Construction Bertrand Meyer.
Design by Contract ™. 2 Design by Contract A discipline of analysis, design, implementation, management.
Feb 2003 R McFadyen1 Contracts (Ch 13) Used to help understand requirements more completely based on assertions; assertions are applicable to any.
Chair of Software Engineering OOSC - Summer Semester Object-Oriented Software Construction Bertrand Meyer.
Chair of Software Engineering ATOT - Lecture 25, 30 June Advanced Topics in Object Technology Bertrand Meyer.
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.
Chair of Software Engineering OOSC - Summer Semester Object-Oriented Software Construction Bertrand Meyer Lecture 15: Exception handling.
-5- Exception handling What is an exception? “An abnormal event” Not a very precise definition Informally: something that you don’t want to happen.
Chair of Software Engineering OOSC - Summer Semester Object-Oriented Software Construction Bertrand Meyer.
Software Testing and Quality Assurance
Chair of Software Engineering OOSC - Summer Semester Object-Oriented Software Construction Bertrand Meyer Lecture 11: Design by Contract™
Chair of Software Engineering OOSC - Summer Semester Object-Oriented Software Construction Bertrand Meyer Lecture 10: Project Presentation Ilinca.
Chair of Software Engineering ATOT - Lecture 12, 12 May Advanced Topics in Object Technology Bertrand Meyer.
Chair of Software Engineering Einführung in die Programmierung Introduction to Programming Prof. Dr. Bertrand Meyer Lecture 6: Object Creation.
Chair of Software Engineering ATOT - Lecture 26, 30 June Advanced Topics in Object Technology Bertrand Meyer.
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 OOSC - Summer Semester Object-Oriented Software Construction Bertrand Meyer Lecture 12: Design by Contract™
Chair of Software Engineering ATOT - Lecture 8, 28 April Advanced Topics in Object Technology Bertrand Meyer.
Chair of Software Engineering 1 Introduction to Programming Bertrand Meyer Exercise Session 6 7 October 2008.
Chair of Software Engineering OOSC - Lecture 4 1 Object-Oriented Software Construction Bertrand Meyer.
Chair of Software Engineering OOSC - Summer Semester Object-Oriented Software Construction Bertrand Meyer.
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 9: Abstraction.
Karlstad University Computer Science Design Contracts and Error Management Design Contracts and Errors A Software Development Strategy (anpassad för PUMA)
Chair of Software Engineering Concurrent Object-Oriented Programming Prof. Dr. Bertrand Meyer Lecture 9: Contracts and Inheritance (based on work with.
Chair of Software Engineering ATOT - Lecture 11, 7 May Advanced Topics in Object Technology Bertrand Meyer.
Chair of Software Engineering ATOT - Lecture 14, 19 May Advanced Topics in Object Technology Bertrand Meyer.
September 2002 R McFadyen1 Domain Model Use Case Model text diagram SSD System operation contracts Design Model Figure 13.3.
Chair of Software Engineering Einführung in die Programmierung Introduction to Programming Prof. Dr. Bertrand Meyer Lecture 6: Object Creation.
Software Verification Bertrand Meyer Chair of Software Engineering Lecture 2: Axiomatic semantics.
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.
Software Engineering Design by Contract 1 Design by Contract ™
Chair of Software Engineering Einführung in die Programmierung Introduction to Programming Prof. Dr. Bertrand Meyer Lecture 9: Abstraction.
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.
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/
OOSCCh11r1:DbC RJL Slide #1 OOSC: Ch11 vs. Predecessors [Meyer:] Equipped with the basic concepts of class, object and genericity, you can by now.
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.
L13: Design by Contract Definition Reliability Correctness Pre- and post-condition Asserts and Exceptions Weak & Strong Conditions Class invariants Conditions.
Department of Computer Science, York University Object Oriented Software Construction 22/01/ :58 AM 1 COSC3311 – Software Design Loop invariant/variant.
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.
契约式设计 Design by Contract Institute of Computer Software Nanjing University.
Design by Contract Jim Fawcett CSE784 – Software Studio
Design by Contract Jim Fawcett CSE784 – Software Studio
Used to help understand requirements more completely
Lecture 2: Axiomatic semantics
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.
Assertions References: internet notes; Bertrand Meyer, Object-Oriented Software Construction; 4/25/2019.
Lecture 2: Axiomatic semantics
Presentation transcript:

Chair of Software Engineering ATOT - Lecture 10, 5 May Advanced Topics in Object Technology Bertrand Meyer

Chair of Software Engineering ATOT - Lecture 10, 5 May Lecture 10: Design by Contract™ By Karine Arnout

Chair of Software Engineering ATOT - Lecture 10, 5 May Design by Contract  A discipline of analysis, design, implementation, management

Chair of Software Engineering ATOT - Lecture 10, 5 May Design by Contract (cont’d)  Every software element is intended to satisfy a certain goal, for the benefit of other software elements (and ultimately of human users).  This goal is the element’s contract.  The contract of any software element should be  Explicit.  Part of the software element itself.

Chair of Software Engineering ATOT - Lecture 10, 5 May A human contract Client Supplier (Satisfy precondition:) Bring package before 4 p.m.; pay fee. (Satisfy postcondition:) Deliver package by 10 a.m. next day. OBLIGATIONS (From postcondition:) Get package delivered by 10 a.m. next day. (From precondition:) Not required to do anything if package delivered after 4 p.m., or fee not paid. BENEFITS deliver

Chair of Software Engineering ATOT - Lecture 10, 5 May A view of software construction  Constructing systems as structured collections of cooperating software elements — suppliers and clients — cooperating on the basis of clear definitions of obligations and benefits.  These definitions are the contracts.

Chair of Software Engineering ATOT - Lecture 10, 5 May Properties of contracts  A contract:  Binds two parties (or more): supplier, client.  Is explicit (written).  Specifies mutual obligations and benefits.  Usually maps obligation for one of the parties into benefit for the other, and conversely.  Has no hidden clauses: obligations are those specified.  Often relies, implicitly or explicitly, on general rules applicable to all contracts (laws, regulations, standard practices).

Chair of Software Engineering ATOT - Lecture 10, 5 May deferred class PLANE inherit AIRCRAFT feature start_take_off is -- Initiate take-off procedures. require controls.passed assigned_runway.clear deferred ensure assigned_runway.owner = Current moving end start_landing, increase_altitude, decrease_altitude, moving, altitude, speed, time_since_take_off... [Other features]... invariant (time_since_take_off <= 20) implies (assigned_runway.owner = Current) moving = (speed > 10) end Contracts for analysis Precondition Class invariant -- i.e. specified only. -- not implemented. Postcondition

Chair of Software Engineering ATOT - Lecture 10, 5 May deferred class VAT inherit TANK feature in_valve, out_valve: VALVE fill is -- Fill the vat. require in_valve.open out_valve.closed deferred ensure in_valve.closed out_valve.closed is_full end empty, is_full, is_empty, gauge, maximum,... [Other features]... invariant is_full = (gauge >= 0.97 * maximum) and (gauge <= 1.03 * maximum) end Contracts for analysis (cont’d) Precondition Class invariant -- i.e. specified only. -- not implemented. Postcondition

Chair of Software Engineering ATOT - Lecture 10, 5 May Contracts for analysis (cont’d) Client Supplier (Satisfy precondition:) Make sure input valve is open, output valve is closed. (Satisfy postcondition:) Fill the vat and close both valves. OBLIGATIONS (From postcondition:) Get filled-up vat, with both valves closed. (From precondition:) Simpler processing thanks to assumption that valves are in the proper initial position. BENEFITS fill

Chair of Software Engineering ATOT - Lecture 10, 5 May So, is it like “assert.h”? (Source: Reto Kramer)  Design by Contract goes further:  “Assert” does not provide a contract.  Clients cannot see asserts as part of the interface.  Asserts do not have associated semantic specifications.  Not explicit whether an assert represents a precondition, post-conditions or invariant.  Asserts do not support inheritance.  Asserts do not yield automatic documentation.

Chair of Software Engineering ATOT - Lecture 10, 5 May Some benefits: technical  Development process becomes more focused. Writing to spec.  Sound basis for writing reusable software.  Exception handling guided by precise definition of “normal” and “abnormal” cases.  Interface documentation always up-to-date, can be trusted.  Documentation generated automatically.  Faults occur close to their cause. Found faster and more easily.  Guide for black-box test case generation.

Chair of Software Engineering ATOT - Lecture 10, 5 May Some benefits: managerial  Library users can trust documentation.  They can benefit from preconditions to validate their own software.  Test manager can benefit from more accurate estimate of test effort.  Black-box specification for free.  Designers who leave bequeath not only code but intent.  Common vocabulary between all actors of the process: developers, managers, potentially customers.  Component-based development possible on a solid basis.

Chair of Software Engineering ATOT - Lecture 10, 5 May Correctness in software  Correctness is a relative notion: consistency of implementation vis-à-vis specification. (This assumes there is a specification!)  Basic notation: (P, Q: assertions, i.e. properties of the state of the computation. A: instructions). {P} A {Q}  “Hoare triple”  What this means (total correctness):  Any execution of A started in a state satisfying P will terminate in a state satisfying Q.

Chair of Software Engineering ATOT - Lecture 10, 5 May Hoare triples: a simple example {n > 5} n := n + 9 {n > 13}  Most interesting properties:  Strongest postcondition (from given precondition).  Weakest precondition (from given postcondition).  “P is stronger than or equal to Q” means: P implies Q  QUIZ: What is the strongest possible assertion? The weakest?

Chair of Software Engineering ATOT - Lecture 10, 5 May Specifying a square root routine {x >= 0}... Square root algorithm to compute y... {abs (y ^ 2 – x) <= 2 * epsilon * y} -- i.e.: y approximates exact square root of x -- within epsilon

Chair of Software Engineering ATOT - Lecture 10, 5 May Software correctness  Consider {P} A {Q}  Take this as a job ad in the classifieds.  Should a lazy employment candidate hope for a weak or strong P? What about Q?  Two special offers:  1. {False} A {...}  2. {...} A {True}

Chair of Software Engineering ATOT - Lecture 10, 5 May A contract (from EiffelBase) extend (new: G; key: H) -- Assuming there is no item of key key, -- insert new with key; set inserted. require key_not_present: not has (key) ensure insertion_done: item (key) = new key_present: has (key) inserted: inserted one_more: count = old count + 1

Chair of Software Engineering ATOT - Lecture 10, 5 May The contract Client Supplier PRECONDITION POSTCONDITION OBLIGATIONS POSTCONDITION PRECONDITION BENEFITS Routine

Chair of Software Engineering ATOT - Lecture 10, 5 May A class without contracts class ACCOUNT feature -- Access balance: INTEGER -- Balance Minimum_balance: INTEGER is Minimum balance feature {NONE} -- Implementation of deposit and withdrawal add (sum: INTEGER) is -- Add sum to the balance (secret procedure). do balance := balance + sum end

Chair of Software Engineering ATOT - Lecture 10, 5 May Without contracts (cont’d) feature -- Deposit and withdrawal operations deposit (sum: INTEGER) is -- Deposit sum into the account. do add (sum) end withdraw (sum: INTEGER) is -- Withdraw sum from the account. do add (– sum) end may_withdraw (sum: INTEGER): BOOLEAN is -- Is it permitted to withdraw sum from the account? do Result := (balance - sum >= Minimum_balance) end end

Chair of Software Engineering ATOT - Lecture 10, 5 May Introducing contracts class ACCOUNT create make feature {NONE} -- Initialization make (initial_amount: INTEGER) is -- Set up account with initial_amount. require large_enough: initial_amount >= Minimum_balance do balance := initial_amount ensure balance_set: balance = initial_amount end

Chair of Software Engineering ATOT - Lecture 10, 5 May Introducing contracts (cont’d) feature -- Access balance: INTEGER -- Balance Minimum_balance: INTEGER is Minimum balance feature {NONE} -- Implementation of deposit and withdrawal add (sum: INTEGER) is -- Add sum to the balance (secret procedure). do balance := balance + sum ensure increased: balance = old balance + sum end

Chair of Software Engineering ATOT - Lecture 10, 5 May With contracts (cont’d) feature -- Deposit and withdrawal operations deposit (sum: INTEGER) is -- Deposit sum into the account. require not_too_small: sum >= 0 do add (sum) ensure increased: balance = old balance + sum end

Chair of Software Engineering ATOT - Lecture 10, 5 May With contracts (cont’d) withdraw (sum: INTEGER) is -- Withdraw sum from the account. require not_too_small: sum >= 0 not_too_big: sum <= balance – Minimum_balance do add (– sum) -- i.e. balance := balance – sum ensure decreased: balance = old balance - sum end

Chair of Software Engineering ATOT - Lecture 10, 5 May The contract Client Supplier (Satisfy precondition:) Make sure sum is neither too small nor too big. (Satisfy postcondition:) Update account for withdrawal of sum. OBLIGATIONS (From postcondition:) Get account updated with sum withdrawn. (From precondition:) Simpler processing: may assume sum is within allowable bounds. BENEFITS withdraw

Chair of Software Engineering ATOT - Lecture 10, 5 May The imperative and the applicative do balance := balance - sum ensure balance = old balance - sum PRESCRIPTIVEDESCRIPTIVE How? Operational Implementation Command Instruction Imperative What? Denotational Specification Query Expression Applicative

Chair of Software Engineering ATOT - Lecture 10, 5 May With contracts (end) may_withdraw (sum: INTEGER): BOOLEAN is -- Is it permitted to withdraw sum from the -- account? do Result := (balance - sum >= Minimum_balance) end invariant not_under_minimum: balance >= Minimum_balance end

Chair of Software Engineering ATOT - Lecture 10, 5 May The class invariant  Consistency constraint applicable to all instances of a class.  Must be satisfied:  After creation.  After execution of any feature by any client. (Qualified calls only: a.f (...))

Chair of Software Engineering ATOT - Lecture 10, 5 May The correctness of a class  For every creation procedure cp: {pre cp } do cp {post cp and INV}  For every exported routine r: {INV and pre r } do r {post r and INV}  The worst possible erroneous run-time situation in object-oriented software development:  Producing an object that does not satisfy the invariant of its own class. a.f (…) a.g (…) a.f (…) create a.make (…) S1 S2 S3 S4

Chair of Software Engineering ATOT - Lecture 10, 5 May Uniform Access balance = deposits.total –withdrawals.total deposits withdrawals balance deposits withdrawals (A1) (A2)

Chair of Software Engineering ATOT - Lecture 10, 5 May class ACCOUNT create make feature {NONE} -- Implementation add (sum: INTEGER) is -- Add sum to the balance (secret procedure). do balance := balance + sum ensure balance_increased: balance = old balance + sum end deposits: DEPOSIT_LIST withdrawals: WITHDRAWAL_LIST A more sophisticated version

Chair of Software Engineering ATOT - Lecture 10, 5 May feature {NONE} -- Initialization make (initial_amount: INTEGER) is -- Set up account with initial_amount. require large_enough: initial_amount >= Minimum_balance do balance := initial_amount create deposits.make create withdrawals.make ensure balance_set: balance = initial_amount end feature -- Access balance: INTEGER -- Balance Minimum_balance: INTEGER is Minimum balance New version (cont’d)

Chair of Software Engineering ATOT - Lecture 10, 5 May New version (cont’d) feature -- Deposit and withdrawal operations deposit (sum: INTEGER) is -- Deposit sum into the account. require not_too_small: sum >= 0 do add (sum) deposits.extend (create {DEPOSIT}.make (sum)) ensure increased: balance = old balance + sum end

Chair of Software Engineering ATOT - Lecture 10, 5 May New version (cont’d) withdraw (sum: INTEGER) is -- Withdraw sum from the account. require not_too_small: sum >= 0 not_too_big: sum <= balance – Minimum_balance do add (– sum) withdrawals.extend (create {WITHDRAWAL}.make (sum)) ensure decreased: balance = old balance – sum one_more: withdrawals.count = old withdrawals.count + 1 end

Chair of Software Engineering ATOT - Lecture 10, 5 May New version (end) may_withdraw (sum: INTEGER): BOOLEAN is -- Is it permitted to withdraw sum from the -- account? do Result := (balance - sum >= Minimum_balance) end invariant not_under_minimum: balance >= Minimum_balance consistent: balance = deposits.total – withdrawals.total end

Chair of Software Engineering ATOT - Lecture 10, 5 May The correctness of a class  For every creation procedure cp: {pre cp } do cp {post cp and INV}  For every exported routine r: {INV and pre r } do r {post r and INV} a.f (…) a.g (…) a.f (…) create a.make (…) S1 S2 S3 S4

Chair of Software Engineering ATOT - Lecture 10, 5 May feature {NONE} -- Initialization make (initial_amount: INTEGER) is -- Set up account with initial_amount. require large_enough: initial_amount >= Minimum_balance do balance := initial_amount create deposits.make create withdrawals.make ensure balance_set: balance = initial_amount end Initial version

Chair of Software Engineering ATOT - Lecture 10, 5 May feature {NONE} -- Initialization make (initial_amount: INTEGER) is -- Set up account with initial_amount. require large_enough: initial_amount >= Minimum_balance do create deposits.make create withdrawals.make deposit (initial_amount) ensure balance_set: balance = initial_amount end Correct version

Chair of Software Engineering ATOT - Lecture 10, 5 May End of lecture 10