MSO Lecture Design by Contract"

Similar documents
Assertions. Assertions - Example

hwu-logo.png 1 class Rational { 2 int numerator ; int denominator ; 4 public Rational ( int numerator, int denominator ) {

Code Contracts in C#

a correct statement? You need to know what the statement is supposed to do.

UC Santa Barbara. CS189A - Capstone. Christopher Kruegel Department of Computer Science UC Santa Barbara

References: internet notes; Bertrand Meyer, Object-Oriented Software Construction; 10/14/2004 1

CITS5501 Software Testing and Quality Assurance Formal methods

Readability [Skrien 4.0] Programs must be written for people to read, and only incidentally for machines to execute.

Testing. Prof. Clarkson Fall Today s music: Wrecking Ball by Miley Cyrus

Integrating verification in programming languages

Lecture Notes: Hoare Logic

Design by Contract: An Overview

Software Engineering

Lecture 1 Contracts. 1 A Mysterious Program : Principles of Imperative Computation (Spring 2018) Frank Pfenning

Lecture 1 Contracts : Principles of Imperative Computation (Fall 2018) Frank Pfenning

Testing and Debugging

CS 161 Computer Security

Hardware versus software

Software Engineering Testing and Debugging Testing

Hoare Logic: Proving Programs Correct

Symbolic Execution and Proof of Properties

AXIOMS OF AN IMPERATIVE LANGUAGE PARTIAL CORRECTNESS WEAK AND STRONG CONDITIONS. THE AXIOM FOR nop

Object-Oriented Design

Hoare Logic. COMP2600 Formal Methods for Software Engineering. Rajeev Goré

Design by Contract in Eiffel

Lecture 4: Procedure Specifications

Assertions & Design-by-Contract using JML Erik Poll University of Nijmegen

Lecture 10 Notes Linked Lists

How invariants help writing loops Author: Sander Kooijmans Document version: 1.0

CS 3 Introduction to Software Engineering. 3: Exceptions

Object-Oriented Design

CSC Advanced Object Oriented Programming, Spring Specification

Correctness of specifications. Correctness. Correctness of specifications (2) Example of a Correctness Proof. Testing versus Correctness Proofs

MSO Exam November 7, 2016, 13:30 15:30, Educ-Gamma

17. Assertions. Outline. Built-in tests. Built-in tests 3/29/11. Jelle Slowack, Bart Smets, Glenn Van Loon, Tom Verheyen

Lecture 10 Notes Linked Lists

17. Assertions. Jelle Slowack, Bart Smets, Glenn Van Loon, Tom Verheyen

Classes, subclasses, subtyping

Cover Page. The handle holds various files of this Leiden University dissertation

CSE 331 Software Design and Implementation. Lecture 3 Loop Reasoning

Lecture Notes on Contracts

Lecture 9 / Tutorial 8 Software Contracts

Abstraction and Specification

Lecture 5 - Axiomatic semantics

MSO Lecture 12. Wouter Swierstra (adapted by HP) October 26, 2017

A Practical Approach to Programming With Assertions

MSO Object Creation Singleton & Object Pool

OO Design Principles

15-122: Principles of Imperative Computation (Section G)

6.170 Recitation #5: Subtypes and Inheritance

Hoare logic. A proof system for separation logic. Introduction. Separation logic

Why Design by Contract! CS 619 Introduction to OO Design and Development. Design by Contract. Fall 2012

Assertions, pre/postconditions

Lecture Notes on Memory Layout

CSE 331 Final Exam 3/16/15 Sample Solution

Verification Condition Generation via Theorem Proving

Softwaretechnik. Lecture 08: Testing and Debugging Overview. Peter Thiemann SS University of Freiburg, Germany

Reasoning About Imperative Programs. COS 441 Slides 10

Softwaretechnik. Lecture 08: Testing and Debugging Overview. Peter Thiemann SS University of Freiburg, Germany

The Eiffel language. Slides partly based on :

CSE 331 Software Design & Implementation

Introduction to Axiomatic Semantics

Type Hierarchy. Lecture 6: OOP, autumn 2003

CS 307: Software Engineering. Lecture 10: Software Design and Architecture

Exceptions and assertions

Software Development. Modular Design and Algorithm Analysis

Lecture Notes on Queues

Top Down Design vs. Modularization

Violations of the contract are exceptions, and are usually handled by special language constructs. Design by contract

Program Verification (6EC version only)

Type Hierarchy. Comp-303 : Programming Techniques Lecture 9. Alexandre Denault Computer Science McGill University Winter 2004

Objectives for this class meeting. 1. Conduct review of core concepts concerning contracts and pre/post conditions

Type Checking in COOL (II) Lecture 10

12/30/2013 S. NALINI,AP/CSE

Program Correctness and Efficiency. Chapter 2

Designing Robust Classes

JAVA BASICS II. Example: FIFO

JML tool-supported specification for Java Erik Poll Radboud University Nijmegen

Trusted Components. Reuse, Contracts and Patterns. Prof. Dr. Bertrand Meyer Dr. Karine Arnout

Operational Semantics. One-Slide Summary. Lecture Outline

Software Engineering CSC40232: SOFTWARE ENGINEERING. Guest Lecturer: Jin Guo SOLID Principles sarec.nd.edu/courses/se2017

EINDHOVEN UNIVERSITY OF TECHNOLOGY

PRINCIPLES OF SOFTWARE BIM209DESIGN AND DEVELOPMENT 00. WELCOME TO OBJECTVILLE. Speaking the Language of OO

Advances in Programming Languages

Software Engineering I (02161)

The Contract Pattern. Design by contract

Code Contracts. Pavel Parízek. CHARLES UNIVERSITY IN PRAGUE faculty of mathematics and physics

PREPARING FOR PRELIM 2

Testing. UW CSE 160 Winter 2016

Thread Safety. Review. Today o Confinement o Threadsafe datatypes Required reading. Concurrency Wrapper Collections

Invariant Based Programming

Binary Search and Worst-Case Analysis

Objective-C. Stanford CS193p Fall 2013

High Quality Java Code: Contracts & Assertions

MergeSort, Recurrences, Asymptotic Analysis Scribe: Michael P. Kim Date: April 1, 2015

n Specifying what each method does q Specify it in a comment before method's header n Precondition q Caller obligation n Postcondition

Specification tips and pitfalls

CSE 331 Summer 2016 Final Exam. Please wait to turn the page until everyone is told to begin.

A comparative study of Programming by Contract and Programming with Exceptions

Binary Search and Worst-Case Analysis

Transcription:

1 MSO Lecture Design by Contract" Wouter Swierstra (adapted by HP, AL) October 8, 2018

2 MSO SO FAR Recap Abstract Classes UP & Requirements Analysis & UML OO & GRASP principles Design Patterns (Facade, Adapter, Strategy, Bridge, Abstract Factory) Midterm

3 TODAY S LECTURE And now for something completely different...

4 TODAY S LECTURE 1. Lecture part 1 2. Break (short presentation by SOLVE Consulting) 3. Lecture part 2 4. Kahoot on the lecture

5 TODAY S LECTURE How to design correct software?

6 A PHILOSOPHICAL QUESTION... What does it mean for software to be correct?

7 A PHILOSOPHICAL QUESTION... What does it mean for software to be correct? Free of bugs? Will not loop? Never throws an exception? Does what it s supposed to?

8 SPECIFICATIONS The main issue of software correctness is that it meets its specifications.

9 SPECIFICATIONS The main issue of software correctness is that it meets its specifications. But who writes specifications?

10 SPECIFICATIONS The main issue of software correctness is that it meets its specifications. But who writes specifications? And who says that the specifications do not contain bugs?

11 AN EXAMPLE: ABSOLUTE VALUE public int AbsoluteValue(int i) { if (i > 0) return i; else return -i; } Does AbsoluteValue(x) return a number greater than or equal to 0 for all x? How could we prove that this is the case? Or how could we disprove it?

12 A BIT OF HISTORY... In the early days of computing, hardware was expensive and tricky to develop. Midway through the last century, something started to change..

13 THE SOFTWARE CRISIS software Cost hardware 1950 Time 1960

14 The major cause of the software crisis is that the machines have become several orders of magnitude more powerful! To put it quite bluntly: as long as there were no machines, programming was no problem at all; when we had a few weak computers, programming became a mild problem, and now we have gigantic computers, programming has become an equally gigantic problem. Edsger Dijkstra, The Humble Programmer, Turing Award Acceptance Speach, 1972

15 WHAT CAN WE DO? Software is suddenly becoming a lot more complex. How can we cope with this complexity? Note that these issues were already identified before the era of OO programming.

16 FOUNDATIONS OF STRUCTURED PROGRAMMING Edsger Dijkstra Tony Hoare *1930, 2002 *1934

17 HOARE LOGIC {P} C {Q} Read as: Provided the precondition P holds at the state before the execution of program C, then the postcondition Q will hold afterwards, or C does not terminate.

18 HOARE LOGIC - EXAMPLES {x > 3} x := x+1; {x > 4} {x > 3} x := x+1; {x > 40} {x > 3} y := 4; x := y {x = 4} {x > 3} while true (x := 3) {x = 3} Question: Which of these statements are valid?

19 DESIGNING A LOGIC... Tony Hoare (inspired by Floyd and Dijkstra) designed a series of rules to reason about programs.

20 SKIP The simplest rule is for the skip command, that does nothing. {P} skip {P} For example, {x > 3} skip {x > 3} is valid.

21 ASSIGNMENT {P[e/x]} x := e {P} The precondition for x := e {P} is uniquely determined by {P[e/x]} i.e. the predicate P where each x is substituted by e

22 ASSIGNMENT {P[e/x]} x := e {P} For example: {x + 1 N} x := x + 1 {x N} is valid.

23 COMPOSITION Suppose we know that {P} c 1 {Q} and {Q} c 2 {R} What can we deduce about c 1 ; c 2?

24 COMPOSITION Suppose we know that {P} c 1 {Q} and {Q} c 2 {R} We can deduce {P} c 1 ; c 2 {R}

25 COMPOSITION For example, if we have { x + 1 = 43 } y := x + 1 { y = 43 } and { y = 43 } z := y { z = 43 } we can deduce { x + 1 = 43 } y := x + 1; z := y { z = 43 }

26 HOARE LOGIC You can add more and more rules - some of which can be quite tricky (like how to deal with loops, recursive functions, pointers,... ) Using these rules you suddenly have the ability to prove statements about your program. This was a major breakthrough!

27 BACK TO ANALYSIS AND DESIGN... These notions of precondition and postcondition are still applied throughout computer science today. In particular, I want to look at Design by Contract or Code Contracts design and programming methodology to write robust software. These ideas influence your entire design: from use case and requirements, through the UML, down to the code.... and don t forget: in most cases, finding the bug requires much more effort than repairing the bug

28 BERTRAND MEYER AND EIFFEL Bertrand Meyer (*1950) introduced Design by Contract in 1986. His language Eiffel has special support for contracts.

29 CONTRACTS In real life, we make contracts all the time. Think of the Post.nl parcel delivery service: Obligations Benefits Customer Provide a letter or parcel Guaranteed delivery no heavier than 2 kg; within two days Pay 6.95 euros Post.nl Deliver parcel to No need to deal with correct address within unpaid deliveries, two working days parcels that are too heavy, big, etc.

30 CONTRACTS Contracts establish some agreement between two parties: Each party expects certain benefits, but is willing to incur obligations to obtain them; These benefits and obligations are documented in a contract document. This contract document protects both parties!

31 ASSERTIONS IN CODE C# provides methods to help write pre- and postconditions in your code. Example: public float reciprocal (int x) { return 1/x; } Clearly this code can fail what happens when we call it with 0?

32 ASSERTIONS IN CODE public float reciprocal (int x) { Debug.Assert(x!= 0); return 1/x; } If another method calls reciprocal(0), the code will throw an exception and show the call stack. Variants exist that will allow you to display custom error messages, etc.

33 ASSERTIONS IN CODE Besides checking preconditions, we can also use assertions to check that our code produces the correct result: public int[] sort (int[] xs) { int[] result =... Debug.Assert(isSorted(result)); return result } Now if anyone changes the method body, introducing a bug, our program will fail when run.

34 CONTRACTS IN SOFTWARE DESIGN The same ideas can be applied to software design. Decorate methods with assertions, stating which contractual obligations: it requires of the caller. it ensures for the caller. These assertions form an important piece of documentation, specifying what a method should do.

35 CASE STUDY: CUSTOMER RELATION MANAGEMENT Suppose we need to write software for managing customers relations. Typical use cases may include: adding a new customer; billing customers; making appointments with customers;...

36 USE CASE EXAMPLE: ADDING A NEW CUSTOMER 1. An account manager fills in a customer s name and address information in the system. 2. The system adds the customer to the customer database. It returns a new, unique customer ID. 3. The customer is sent a welcome email. 4. The marketing department is notified to pursue potential business leads.

37 USE CASE EXAMPLE: ADDING A NEW CUSTOMER Preconditions: What preconditions would you associate with this use case? Postconditions: What postconditions would you associate with this use case? 1. An account manager fills in a customer s name and address information in the system. 2. The system adds the customer to the customer database. It returns a new, unique customer ID. 3. The customer is sent a welcome email. 4. The marketing department is notified to pursue potential business leads.

38 USE CASE EXAMPLE: ADDING A NEW CUSTOMER Preconditions: The customer is not yet entered in the database. There is a live connection to the database and servers. The account manager is logged in and authorized to add new customers.... Postconditions: The customer is now stored in the database. The customer is assigned a unique ID.....

39 WHY? Why write such pre- and postconditions in use cases? It can help developers figure out what is really going on, and under which conditions they can abort; It s a first step towards (automated) testing; It provides information for writing contracts. It forces you to think about what is really going on.

40 DEFENSIVE PROGRAMMING Taking these ideas seriously leads to defensive programming, where you assume that everyone is out to crash your code. Never trust input if you assume the argument is greater than 0, add an assertion to check this. Fail early and openly check any preconditions before entering the method body. Document your assumptions explicitly state the preconditions, postconditions, and invariants upon which your code relies.

41 CONTRACTS IN CODE I want to discuss one implementation of these ideas, Microsoft s Code Contracts library - available for you guys in C# now. Lots more info on the Code Contracts website: http://research.microsoft.com/en-us/projects/ contracts/ Play online at: http://rise4fun.com/codecontracts

42 CONTRACT You can think of Code Contracts as establishing a contract between the users of a class or method and the developers of a class or method.

43 CONTRACT You can think of Code Contracts as establishing a contract between the users of a class or method and the developers of a class or method. More concrete: You and one of your team members ("what the hell did he do here?")

44 CONTRACT You can think of Code Contracts as establishing a contract between the users of a class or method and the developers of a class or method. More concrete: You and one of your team members ("what the hell did he do here?") You and an external person responsible for parts of the software ("what the hell did she do here?")

45 CONTRACT You can think of Code Contracts as establishing a contract between the users of a class or method and the developers of a class or method. More concrete: You and one of your team members ("what the hell did he do here?") You and an external person responsible for parts of the software ("what the hell did she do here?") You and yourself ("what the hell did I do here?")

46 SIMPLE (PSEUDOCODE) EXAMPLE public int addcustomer(string name) { int id = customers.freshid(); customers.add(id,name); return id; }

47 SIMPLE EXAMPLE public int addcustomer(string name) { int id = customers.freshid(); customers.add(id,name); return id; } What are the preconditions?

48 SIMPLE EXAMPLE public int addcustomer(string name) { int id = customers.freshid(); customers.add(id,name); return id; } What are the preconditions? essential customer data should not be null; this customer does not yet exist in our database;

49 ADDING PRECONDITIONS public int addcustomer(string name) { Contract.Requires(customers!= null); Contract.Requires(!customers.Contains(name)); int id = customers.freshid(); customers.add(id,name); return id; } Add preconditions using Contract.Requires; These are checked before entering the method body.

50 POSTCONDITIONS? public int addcustomer(string name) { Contract.Requires(customers!= null); Contract.Requires(!customer.Contains(name)); int id = customers.freshid(); customers.add(id,name); return id; } What about postconditions? Guarantee that the name now occurs in the customers dictionary.

51 ADDING POSTCONDITIONS public int addcustomer(string name) { Contract.Requires(customers!= null); Contract.Requires(!customer.Contains(name)); Contract.Ensures( customers[contract.result<int>()] == name); int id = customers.freshid(); customers.add(id,name); return id; } Add postconditions using Contract.Ensures; Use Contract.Result to refer to the result of a method; Postconditions are checked just before the method returns.

52 ESTABLISHING BLAME One important reason for using contracts is to establish blame; suppose A uses a method created by B who is at fault when a precondition for the method does not hold? who is at fault when a postcondition for the method fails to hold?

53 ESTABLISHING BLAME One important reason for using contracts is to establish blame who is at fault when a precondition does not hold? The code that called the method defining the failing precondition: A is to blame who is at fault when a postcondition fails to hold? The method that defines the postcondition: B is to blame

EXAMPLE public int addcustomer(string name) { Contract.Requires(customers!= null); Contract.Requires(!customer.Contains(name)); Contract.Ensures( customers[contract.result<int>()] = name); int id = customers.freshid(); customers.add(id,name); return id; } If the precondition fails, for example customers is null, the code calling this method is at fault. It should have initialized the customers. 54

55 EXAMPLE public int addcustomer(string name) { Contract.Requires(customers!= null); Contract.Requires(!customer.Contains(name)); Contract.Ensures( customers[contract.result<int>()] = name); int id = customers.freshid(); customers.add(id,name); return id; } If the postcondition fails, the error is in this method (or the method it calls);

56 STRONG OR WEAK? A very strong precondition places a lot of responsibility on the code calling this function; A very strong postcondition places a lot of responsibility on the method ensuring that this postcondition holds.

57 WHY USE CODE CONTRACTS? Generate dynamic checks, as the code runs; Also statically checks contracts! Generate documentation!

58 Demo http://rise4fun.com/codecontracts

59 INVARIANTS Besides pre- and postconditions, Floyd-Hoare-Dijkstra identified another important notion: invariants. An invariant is a property that holds continuously throughout execution.

60 INVARIANTS: EXAMPLE int x := 0; while (x < 10) { x := x + 1; } What invariant can we identify in the body of this loop?

61 INVARIANTS: EXAMPLE int x := 0; while (x < 10) { x := x + 1; } What invariant can we identify in the body of this loop? Choices may include: x is in the range {0.. 10} x <= 10 x is an integer value...

62 INVARIANTS IN DESIGN-BY-CONTRACT In the same spirit, the Design by Contract lets you identify invariants that should hold on your objects: Question: What invariants should our CRM software satisfy?

63 INVARIANTS IN DESIGN-BY-CONTRACT In the same spirit, the Design by Contract lets you identify invariants that should hold on your objects: What invariants should our CRM software satisfy? We have address information about all our customers; We don t have duplicate customers in our database;...

64 SPECIFYING INVARIANTS class Rational { int numerator; int denominator;... } [ContractInvariantMethod] void ObjectInvariant () { Contract.Invariant(denominator!= 0); Contract.Invariant(numerator < denominator); }

65 CHECKING INVARIANTS When should invariants be checked? This is not an easy question.

66 class Rational { int numerator; int denominator; } void normalize() { int x = gcd(numerator, denominator); denominator = denominator/x; numerator = numerator/x; } This may temporarily break the invariant...

67 INVARIANT CHECKING Microsoft s Code Contracts library chooses to check object invariants on every exit from a public method. Other design choices exist...

68 CONTRACTS AND INHERITANCE There is tricky interaction between contracts and inheritance. Suppose a class Collection has a contract associated with the sort() method. Now you define a subclass of the Collection class, ShapeCollection that overrides the sort() method. What contract should the new sort() method satisfy?

69 CONTRACTS AND INHERITANCE This is not an easy question. If ShapeCollection requires a stronger precondition, calls to sort on a Collection may trigger failure; If ShapeCollection ensures a weaker postcondition, calls to sort may not get the guarantees they are expecting. Both the opposite changes are allowed, that is, subclasses are allowed to weaken preconditions (but not strengthen them) and strengthen postconditions and invariants (but not weaken them).

70 INTERACTION WITH OTHER FEATURES You can also add contracts to abstract methods or interfaces; Contracts need to be pure functions; There is lots more to read about Code Contracts check the website!

71 WHY? I chose to talk about design by contract for various reasons: it makes design a more precise process the more exact input you can give developers about your design, the better software they will write. it s a design philosophy that fits well with the rest of the course; I hope it motivates you to think about software correctness, or how such a tool might work...

72 HOW? How does Microsoft s Code Contract library work?

73 HOW? How does Microsoft s Code Contract library work? Magic.

74 LEARNING MORE We teach a lot of courses that help you learn how such tools work, and how to write you own: Compiler Construction Automated Program Analysis Program verification...

75 MATERIAL COVERED Code Contracts: http://research.microsoft.com/en-us/projects/ contracts/ A first taste of design by contract: http://www.pearsonhighered.com/samplechapter/ 0201634600.pdf Design by contract: http: //en.wikipedia.org/wiki/design_by_contract Bertrand Meyer s Applying Design by Contract.