Chair of Software Engineering Einführung in die Programmierung Introduction to Programming Prof. Dr. Bertrand Meyer Exercise Session 4.

Slides:



Advertisements
Similar presentations
Automated Theorem Proving Lecture 1. Program verification is undecidable! Given program P and specification S, does P satisfy S?
Advertisements

Chair of Software Engineering Einführung in die Programmierung Introduction to Programming Prof. Dr. Bertrand Meyer Exercise Session 5.
Building Bug-Free O-O Software: An Introduction to Design By Contract A presentation about Design By Contract and the Eiffel software development tool.
Chair of Software Engineering 1 Introduction to Programming Bertrand Meyer Exercise Session 5 6 October 2008.
Chair of Software Engineering Concurrent Object-Oriented Programming Prof. Dr. Bertrand Meyer Exercise Session 1: Eiffel Introduction.
Chair of Software Engineering Einführung in die Programmierung Introduction to Programming Prof. Dr. Bertrand Meyer Lecture 7: References and Assignment.
Chair of Software Engineering 1 Introduction to Programming Bertrand Meyer Exercise Session November 2008.
Chair of Software Engineering Einführung in die Programmierung Introduction to Programming Prof. Dr. Bertrand Meyer Exercise Session 6.
Chair of Software Engineering Constants, once routines, and helper functions these slides contain advanced material and are optional.
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 ATOT - Lecture 25, 30 June Advanced Topics in Object Technology Bertrand Meyer.
Chair of Software Engineering OOSC - Summer Semester Object-Oriented Software Construction Bertrand Meyer Lecture 15: Exception handling.
Chair of Software Engineering 1 Introduction to Programming Bertrand Meyer Exercise Session 4 30 September 2008.
Chair of Software Engineering Einführung in die Programmierung Introduction to Programming Prof. Dr. Bertrand Meyer Exercise Session 5.
Chair of Software Engineering Einführung in die Programmierung Introduction to Programming Prof. Dr. Bertrand Meyer (Nadia Polikarpova) Verification tools.
1 Advanced Material The following slides contain advanced material and are optional.
Chair of Software Engineering Einführung in die Programmierung Introduction to Programming Prof. Dr. Bertrand Meyer Lecture 6: Object Creation.
Chair of Software Engineering Einführung in die Programmierung Introduction to Programming Prof. Dr. Bertrand Meyer Exercise Session 3.
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 Exercise Session 4.
Chair of Software Engineering 1 Introduction to Programming Bertrand Meyer Exercise Session 6 7 October 2008.
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.
Chair of Software Engineering Einführung in die Programmierung Introduction to Programming Prof. Dr. Bertrand Meyer Exercise Session 4.
Chair of Software Engineering Avoid a void Bertrand Meyer ©Bertrand Meyer, 2008.
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 1 Introduction to Programming Tuples and Agents Exercise Session 1 and 2 December 2008.
Chair of Software Engineering Einführung in die Programmierung Introduction to Programming Prof. Dr. Bertrand Meyer Lecture 7: References and Assignment.
Chair of Software Engineering Einführung in die Programmierung Introduction to Programming Prof. Dr. Bertrand Meyer Exercise Session 4.
Chair of Software Engineering Einführung in die Programmierung Introduction to Programming Prof. Dr. Bertrand Meyer Lecture 6: Object Creation.
1 Introduction to: Design by Contract Fall 2005 OOPD John Anthony.
Chair of Software Engineering Einführung in die Programmierung Introduction to Programming Prof. Dr. Bertrand Meyer Exercise Session 3.
Eiffel Language and Design by Contract Contract –An agreement between the client and the supplier Characteristics –Expects some benefits and is prepared.
Chair of Software Engineering Einführung in die Programmierung Introduction to Programming Prof. Dr. Bertrand Meyer Exercise Session 5.
Chair of Software Engineering Einführung in die Programmierung Introduction to Programming Prof. Dr. Bertrand Meyer Lecture 9: Abstraction.
Chair of Software Engineering Einführung in die Programmierung Introduction to Programming Prof. Dr. Bertrand Meyer Exercise Session 3.
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.
Ranga Rodrigo. Class is central to object oriented programming.
Comparison of OO Programming Languages © Jason Voegele, 2003.
CSM-Java Programming-I Spring,2005 Introduction to Objects and Classes Lesson - 1.
© Bertrand Meyer and Yishai Feldman Notice Some of the material is taken from Object-Oriented Software Construction, 2nd edition, by Bertrand Meyer (Prentice.
Eiffel Naeem Esfahani University of Tehran "Man cannot discover new oceans unless he has the courage to lose sight of the shore." -- Andre Gide.
Chair of Software Engineering 1 Introduction to Programming Bertrand Meyer Exercise Session October 2008.
Tammy Dahlgren with Tom Epperly, Scott Kohn, and Gary Kumfert Center for Applied Scientific Computing Common Component Architecture Working Group October.
SWE 619 © Paul Ammann Procedural Abstraction and Design by Contract Paul Ammann Information & Software Engineering SWE 619 Software Construction cs.gmu.edu/~pammann/
More About Classes Ranga Rodrigo. Information hiding. Copying objects.
Chair of Software Engineering Einführung in die Programmierung Introduction to Programming Prof. Dr. Bertrand Meyer Exercise Session 5.
Contracts for Concurrency - Contracts & Inheritance Aryabrata Basu University of Georgia.
Chair of Software Engineering 1 Introduction to Programming Bertrand Meyer Exercise Session October 2008.
Topic 1 Object Oriented Programming. 1-2 Objectives To review the concepts and terminology of object-oriented programming To discuss some features of.
Chair of Software Engineering Einführung in die Programmierung Introduction to Programming Prof. Dr. Bertrand Meyer Exercise Session 5.
COP4020 Programming Languages Introduction to Axiomatic Semantics Prof. Robert van Engelen.
Chair of Software Engineering Einführung in die Programmierung Introduction to Programming Prof. Dr. Bertrand Meyer Exercise Session 3.
Chair of Software Engineering 1 Introduction to Programming Bertrand Meyer Exercise Session October 2008.
ANU COMP2110 Software Design in 2003 Lecture 10Slide 1 COMP2110 Software Design in 2004 Lecture 12 Documenting Detailed Design How to write down detailed.
Programmeren 1 6 september 2010 HOORCOLLEGE 2: INTERACTIE EN CONDITIES PROGRAMMEREN 1 6 SEPTEMBER 2009 Software Systems - Programming - Week.
Chair of Software Engineering Einführung in die Programmierung Introduction to Programming Prof. Dr. Bertrand Meyer Exercise Session 4.
1 Assertions. 2 A boolean expression or predicate that evaluates to true or false in every state In a program they express constraints on the state that.
PROGRAMMING PRE- AND POSTCONDITIONS, INVARIANTS AND METHOD CONTRACTS B MODULE 2: SOFTWARE SYSTEMS 13 NOVEMBER 2013.
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.
Chair of Software Engineering 1 Introduction to Programming Bertrand Meyer Exercise Session October 2008.
Object Design More Design Patterns Object Constraint Language Object Design Specifying Interfaces Review Exam 2 CEN 4010 Class 18 – 11/03.
© 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 Jim Fawcett CSE784 – Software Studio
Design by Contract Jim Fawcett CSE784 – Software Studio
Einführung in die Programmierung Introduction to Programming Prof. Dr
Einführung in die Programmierung Introduction to Programming Prof. Dr
Einführung in die Programmierung Introduction to Programming Prof. Dr
Einführung in die Programmierung Introduction to Programming Prof. Dr
Einführung in die Programmierung Introduction to Programming Prof. Dr
Presentation transcript:

Chair of Software Engineering Einführung in die Programmierung Introduction to Programming Prof. Dr. Bertrand Meyer Exercise Session 4

2 Today  Understanding contracts (preconditions, postconditions, and class invariants)  Reference types vs. expanded types  Basic types  Entities and objects  Object creation  Assignment

3 Why do we need contracts at all? They are executable specifications that evolve together with the code Together with tests, they are a great tool for finding bugs They help us to reason about an O-O program at the level of classes and routines Proving (part of) programs correct without executing them is what cool people are trying to do nowadays. This is easier to achieve if the program properties are clearly specified through contracts

4 Assertions when the condition is violated, the assertion tag, if present, would be used to construct a more informative error message. balance_non_negative: balance >= 0 Assertion clause Assertion tag (optional, but recommended) Condition (required)

5 clap (n: INTEGER) -- Clap n times and update count. require not_too_tired: count <= 10 n_positive: n > 0 Property that a feature imposes on every client A feature with no require clause is always applicable, as if the precondition reads require always_OK: True Precondition

6 clap (n: INTEGER) -- Clap n times and update count. require not_too_tired: count <= 10 n_positive: n > 0 ensure count_updated: count = old count + n Property that a feature guarantees on termination A feature with no ensure clause always satisfies its postcondition, as if the postcondition reads ensure always_OK: True Postcondition

7 Property that is true of the current object at any observable point A class with no invariant clause has a trivial invariant always_OK: True class ACROBAT … invariant count_non_negative: count >= 0 end Class Invariant

8 Pre- and postcondition example Add pre- and postconditions to: smallest_power (n, bound: NATURAL): NATURAL -- Smallest x such that `n'^x is greater or equal `bound'. require ??? do... ensure ??? end Hands-On

9 One possible solution smallest_power (n, bound: NATURAL): NATURAL -- Smallest x such that `n'^x is greater or equal `bound'. require n_large_enough: n > 1 bound_large_enough: bound > 1 do... ensure greater_equal_bound: n ^ Result >= bound smallest: n ^ (Result - 1) < bound end

10 Hands-on exercise Add invariant(s) to the class ACROBAT_WITH_BUDDY. Add preconditions and postconditions to feature make in ACROBAT_WITH_BUDDY. Hands-On

11 Class ACROBAT_WITH_BUDDY class ACROBAT_WITH_BUDDY inherit ACROBAT redefine twirl, clap, count end create make feature make (p: ACROBAT) do -- Remember `p’ being -- the buddy. end clap (n: INTEGER) do -- Clap `n’ times and -- forward to buddy. end twirl (n: INTEGER) do -- Twirl `n’ times and -- forward to buddy. end count: INTEGER do -- Ask buddy and return his -- answer. end buddy: ACROBAT end

12 What are reference and expanded types? Reference types: s contains the address (reference, or location), of the object. Example: s : STATION Expanded types: p points directly to the object. Example: p : POINT s (STATION ) p AB3409E1 A00897BC (POINT ) AB3409E1

13 Why expanded types?  Representing basic types (INTEGER, REAL,…)  Modeling external world objects realistically, i.e. describing objects that have sub-objects (and no sharing), for example a class WORKSTATION and its CPU.  Possible efficiency gain.  Interface with other languages.

14 How to declare an expanded type To get an expanded type, declare a class with keyword expanded: expanded class COUPLE feature -- Access man, woman: HUMAN years_together: INTEGER end Now all the entities of type COUPLE will automatically become expanded: pitt_and_jolie: COUPLE Expanded Reference ?

15 Objects of reference or expanded types Objects of reference types: they don’t exist when we declare them (they are initially Void). s : STATION We need to explicitly create them with a create instruction. create s Objects of expanded types: they exist by just declaring them (they are never Void) p : POINT Feature default_create from ANY is implicitly invoked on them

16 Can expanded types contain reference types? Expanded types can contain reference types, and vice versa. c (SOME_CLASS ) (COUPLE ) (HUMAN) 10 20

17 Reference equality a = b ? (VECTOR ) a b (VECTOR ) (VECTOR ) b a True False

18 Expanded entities equality Entities of expanded types are compared by value! a = b ? True a (SOME_CLASS ) (POINT ) b (POINT )

19 Expanded entities equality (SOME_CLASS ) (HUMAN) 32 John (HUMAN) b a 30 Jane (HUMAN) 32 John (HUMAN) 30 Jane a = b ? False Hands-On (COUPLE ) 10 (COUPLE ) 10

20 Expanded entities equality Hands-On (HUMAN) 32 John (HUMAN) 30 Jane a = b ? True (SOME_CLASS ) b a (COUPLE ) 10 (COUPLE ) 10

21 Basic types Their only privilege is to use manifest constants to construct their instances: b: BOOLEAN x: INTEGER c: CHARACTER s: STRING … b := True x := 5 -- instead of create x.make_five c := ‘c’ s := “I love Eiffel”

22 Basic types  Some basic types (BOOLEAN, INTEGER, NATURAL, REAL, CHARACTER) are expanded… a := b  … and immutable (they do not contain commands to change the state of their instances)… a := a.plus (b)instead ofa.add (b) 5 b 3 a 5 a 5 b a + b Alias for plus

23 Strings are a bit different Strings in Eiffel are not expanded… s: STRING … and not immutable s := “I love Eiffel” s.append (“ very much!”) Ilov sarea count e

24 String comparison: = versus is_equal s1: STRING = “Teddy” s2: STRING = “Teddy” … s1 = s2 -- False: reference comparison on different objects s1.is_equal (s2) –True … Now you know what to do if interested in comparing the content of two strings

25 Initialization Default value of any reference type is Void Default values of basic expanded types are:  False for BOOLEAN  0 for numeric types (INTEGER, NATURAL, REAL)  “null” character (its code is 0) for CHARACTER Default value of a non-basic expanded type is an object, whose fields have default values of their types (COUPLE ) 0

26 Initialization What is the default value for the following classes? expanded class POINT feature x, y: REAL end class VECTOR feature x, y: REAL end STRING Hands-On 0.0 (POINT) x y Void

27 Creation procedures  Instruction create x will initialize all the fields of the new object attached to x with default values  What if we want some specific initialization? E.g., to make object consistent with its class invariant? Class CUSTOMER … id : STRING invariant id /= Void id  Use creation procedure: create a_customer.set_id (“ ”) Incorrect!

28 Class CUSTOMER List one or more creation procedures May be used as a regular command and as a creation procedure Is established by set_id class CUSTOMER create set_id feature id : STRING -- Unique identifier for Current. set_id (a_id : STRING) -- Associate this customer with `a_id’. require id_exists : a_id /= Void do id := a_id ensure id_set : id = a_id end invariant id_exists : id /= Void end

29 Object creation To create an object:  If class has no create clause, use basic form: create x  If the class has a create clause listing one or more procedures, use create x.make (…) where make is one of the creation procedures, and (…) stands for arguments if any.

30 Some acrobatics class DIRECTOR create prepare_and_play feature acrobat1, acrobat2, acrobat3: ACROBAT friend1, friend2: ACROBAT_WITH_BUDDY author1: AUTHOR curmudgeon1: CURMUDGEON prepare_and_play do author1.clap (4) friend1.twirl (2) curmudgeon1.clap (7) acrobat2.clap (curmudgeon1.count) acrobat3.twirl (friend2.count) friend1.buddy.clap (friend1.count) friend2.clap (2) end Hands-On What entities are used in this class? What’s wrong with the feature prepare_and_play?

31 Some acrobatics class DIRECTOR create prepare_and_play feature acrobat1, acrobat2, acrobat3: ACROBAT friend1, friend2: ACROBAT_WITH_BUDDY author1: AUTHOR curmudgeon1: CURMUDGEON prepare_and_play do 1 create acrobat1 2 create acrobat2 3 create acrobat3 4 create friend1.make_with_buddy (acrobat1) 5 create friend2.make_with_buddy (friend1) 6 create author1 7 create curmudgeon1 end Hands-On Which entities are still Void after execution of line 4? Which of the classes mentioned here have creation procedures? Why is the creation procedure necessary?

32  Expanded classes are not creatable using a creation feature of your choice expanded class POINT create make feature make do x := 5.0; y := 5.0 end... end  But you can use (and possibly redefine) default_create expanded class POINT inherit ANY redefine default_create feature default_create do x := 5.0; y := 5.0 end Custom initialization for expanded types Incorrect

33 Assignment  Assignment is an instruction (What other instructions do you know?)  Syntax: a := b  where a is a variable (e.g., attribute) and b is an expression (e.g. argument, query call);  a is called the target of the assignment and b the source.  Semantics:  after the assignment a equals b (a = b);  the value of b is not changed by the assignment.

34 Reference assignment (VECTOR ) a 0.0 (VECTOR ) b a := b a references the same object as b: a = b

35 Expanded assignment a (POINT ) b (POINT ) a := b The value of b is copied to a, but again: a = b

36 Assignment Explain graphically the effect of an assignment: Hands-On (HUMAN) 32 „John“ (HUMAN) a 30 „Jane“ (HUMAN) 25 „Dan“ (HUMAN) 24 „Lisa“ (COUPLE ) 10 a := b b (COUPLE ) 4 4 Here COUPLE is an expanded class, HUMAN is a reference class

37 Attachment  More general term than assignment  Includes:  Assignment a := b  Passing arguments to a routine f (a: SOME_TYPE) do … end f (b)  Same semantics

38 Dynamic aliasing a, b: VECTOR … create b.make (1.0, 0.0) a := b  now a and b reference the same object (they are two names or aliases of the same object)  any change to the object attached to a will be reflected when accessing it using b  any change to the object attached to b will be reflected when accessing it using a (VECTOR ) a b x y

39 Dynamic aliasing What are the values of a.x, a.y, b.x and b.y after executing instructions 1-4? a, b: VECTOR … create a.make (-1.0, 2.0) 1create b.make (1.0, 0.0) 2a := b 3b.set_x (5.0) 4a.set_y (-10.0) Hands-On (VECTOR ) a b x y

40 Meet Teddy