Einführung in die Programmierung Introduction to Programming Prof. Dr

Slides:



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

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 6.
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 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 Exercise Session 4.
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 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.
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 Exercise Session 3.
Ranga Rodrigo. Class is central to object oriented programming.
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.
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.
Chair of Software Engineering 1 Introduction to Programming Bertrand Meyer Exercise Session October 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 Exercise Session 4.
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.
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.
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.
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.
© Bertrand Meyer and Yishai Feldman Notice Some of the material is taken from Object-Oriented Software Construction, 2nd edition, by Bertrand Meyer (Prentice.
CS314 – Section 5 Recitation 9
© 2016 Pearson Education, Inc., Hoboken, NJ. All rights reserved.
Topic: Classes and Objects
EECE 310: Software Engineering
Chapter 6 CS 3370 – C++ Functions.
Design by Contract Jim Fawcett CSE784 – Software Studio
Design by Contract Jim Fawcett CSE784 – Software Studio
Object-Oriented Programming: Classes and Objects
Introduction To Repetition The for loop
Topics: jGRASP editor ideosyncrasies assert debugger.
Chapter 3: Using Methods, Classes, and Objects
Programmazione I a.a. 2017/2018.
Einführung in die Programmierung Introduction to Programming Prof. Dr
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.
Design by Contract Fall 2016 Version.
7 Arrays.
Design by contract Object-Oriented Software Construction by Bertrand Meyer, Prentice Hall The presence of a precondition or postcondition in a routine.
PHP.
Classes and Objects.
Einführung in die Programmierung Introduction to Programming Prof. Dr
Design by contract Object-Oriented Software Construction by Bertrand Meyer, Prentice Hall The presence of a precondition or postcondition in a routine.
Einführung in die Programmierung Introduction to Programming Prof. Dr
Java Classes Aliases & Null & This
Tonga Institute of Higher Education
Einführung in die Programmierung Introduction to Programming Prof. Dr
Language Constructs Construct means to build or put together. Language constructs refers to those parts which make up a high level programming language.
Object Oriented Programming in java
Einführung in die Programmierung Introduction to Programming Prof. Dr
Einführung in die Programmierung Introduction to Programming Prof. Dr
slides created by Ethan Apter and Marty Stepp
Generics, Lambdas and Reflection
Presentation transcript:

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

Problems in Assignment-2 Solutions Command or query? connecting_lines (a_station_1, a_station_2: STATION): V_SEQUENCE [LINE] Noun phrases for query names; verb phrases for command names Instruction separation? Comma (,), space( ), semicolon (;), or nothing STRING_8 Vs. STRING_32     make         local             l_line: STRING_32             c: UTF_CONVERTER         do             Io.read_line             l_line := c.utf_8_string_8_to_string_32 (Io.last_string)             print (l_line.count)         end

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

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 requires some way to specify the way the program should operate. Contracts are a way to specify the program

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

Precondition 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 clap (n: INTEGER) -- Clap n times and update count. require not_too_tired: count <= 10 n_positive: n > 0 6

Postcondition 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 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 Explain the meaning of the `old` keyword: when applied to a variable, it represents the value the variable had at the beginning of the method‘s execution. 7

Class Invariant 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 8

Pre- and postcondition example Hands-On 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 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 Note: standard "^" in Eiffel actually returns a REAL, but we pretend that we are using a function power (n, m: NATURAL): NATURAL with an alias "^", which makes sense mathematically. Preconditions are a bit tricky: n > 1 is needed so that there is always a solution. For example if n=1 and bound >= 2 there would be no solution. bound > 1 is needed, because bound = 0 => Result = 0, so the postcondition "smallest" will underflow. 10

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. p : POINT AB3409E1 s AB3409E1 (STATION ) p 1.2 A00897BC 5.0 (POINT )

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.

How to declare an expanded type To create an expanded type, declare the 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 Reference ? Expanded

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 We can redefine default_create on expanded types if we wish, and then invoke it: create p.default_create. We cannot pass arguments though.

Can expanded types contain reference types? Expanded types can contain reference types, and vice versa. ... pitt_and_jolie (HUMAN) 10 (HUMAN) ... (SOME_CLASS )

Reference equality 1.0 2.0 a = b ? True 1.0 1.0 2.0 2.0 False a = b ? (VECTOR ) a = b ? True 1.0 a b 1.0 2.0 2.0 (VECTOR ) (VECTOR ) False a = b ?

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

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

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

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”

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 of a.add (b) a b 3 5 a b 5 5 a + b Alias for plus

Strings are a bit different Strings in Eiffel are not expanded… s: STRING … and not immutable s := “I love Eiffel” s.append (“ very much!”) s area I l o v e ... 13 count ...

Object comparison: = versus ~ s1: STRING = “Teddy” s2: STRING = “Teddy” … s1 = s2 -- False: reference comparison on different objects s1 ~ s2 --True Now you know what to do if interested in comparing the content of two objects

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 )

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

create a_customer.set_id (“13400002”) 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 Incorrect! id Use creation procedure: create a_customer.set_id (“13400002”)

Class CUSTOMER 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 List one or more creation procedures May be used as a regular command and as a creation procedure Is established by set_id

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.

Custom initialization for expanded types 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 inherit ANY redefine default_create feature default_create do x := 5.0; y := 5.0 Incorrect Probably should be omitted at level A.

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.

Reference assignment 1.0 0.0 2.0 -1.0 a := b (VECTOR ) (VECTOR ) a := b a references the same object as b: a = b

Expanded assignment 1.2 -2.0 -2.0 7.8 5.0 7.8 a := b (POINT ) (POINT ) a := b The value of b is copied to a, but again: a = b

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

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

Dynamic aliasing a, b: VECTOR … create b.make (1.0, 0.0) a := b 1.0 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 a x 1.0 b y 0.0 (VECTOR )

Hands-On 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) 1 create b.make (1.0, 0.0) 2 a := b 3 b.set_x (5.0) 4 a.set_y (-10.0) Hands-On a x 5.0 y -10.0 b (VECTOR )

Meet Teddy Tell the students that Teddy will be their best friend when they need help to solve some technical/programming problem. The one to ask first. What they should do is to try to explain the problem to Teddy (really, out loud). Then Teddy (hopefully) will provide an answer by directly communicating with your head…For strange that it may seem, it works many times (credits to Andreas Zeller and his book ‘Why programs fail’, page 152, for mentioning the idea. The idea itself is reported from Kernighan and Pike (1999) who mentioned a university center help desk asking students with mysterious bugs to first explain them to the teddy bear before asking to a help desk guy.