Inheritance. class RECTANGLE inherit POLYGON RECTANGLE includes features of POLYGON r: RECTANGLE; p: POLYGON Polymorphism p := r -- legal assignment Dynamic.

Slides:



Advertisements
Similar presentations
Ceg860(Prasad)L10DC1 Design by Contract Invariants Pre-post conditions : Rights and Obligations Exceptions : Contract Violations.
Advertisements

Building Bug-Free O-O Software: An Introduction to Design By Contract A presentation about Design By Contract and the Eiffel software development tool.
© Bertrand Meyer and Yishai Feldman Notice Some of the material is taken from Object-Oriented Software Construction, 2nd edition, by Bertrand Meyer (Prentice.
Semantics Static semantics Dynamic semantics attribute grammars
Chair of Software Engineering Concurrent Object-Oriented Programming Prof. Dr. Bertrand Meyer Exercise Session 1: Eiffel Introduction.
Chair of Software Engineering OOSC - Summer Semester Object-Oriented Software Construction Bertrand Meyer Lecture 3: Abstract Data Types.
Chair of Software Engineering OOSC - Summer Semester Object-Oriented Software Construction Bertrand Meyer.
Inheritance 2 Ranga Rodrigo Based on Mark Priestley's Lectures.
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.
Eiffel Programming Language. Chad Frommeyer CSC 407/507 Fall 2005 Dr. Richard Fox.
Chair of Software Engineering OOSC Summer Semester Object-Oriented Software Construction 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.
Katz Formal Specifications Larch 1 Algebraic Specification and Larch Formal Specifications of Complex Systems Shmuel Katz The Technion.
1 Specifying Object Interfaces. 2 Major tasks in this stage: --are there any missing attributes or operations? --how can we reduce coupling, make interface.
1 Advanced Material The following slides contain advanced material and are optional.
Chair of Software Engineering OOSC - Summer Semester Object-Oriented Software Construction Bertrand Meyer.
Chair of Software Engineering ATOT - Lecture 12, 12 May Advanced Topics in Object Technology Bertrand Meyer.
Principles of Object-Oriented Software Development The language Eiffel.
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 OOSC Summer Semester Object-Oriented Software Construction Bertrand Meyer.
Chair of Software Engineering OOSC - Lecture 4 1 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 ATOT - Lecture 9, 30 April Advanced Topics in Object Technology Bertrand Meyer.
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 Exercise Session Week 9 M. Piccioni 17/18 November 2008.
Chair of Software Engineering ATOT - Lecture 11, 7 May Advanced Topics in Object Technology Bertrand Meyer.
Chair of Software Engineering ATOT - Lecture 23, 23 June Advanced Topics in Object Technology Bertrand Meyer.
Chair of Software Engineering ATOT - Lecture 14, 19 May Advanced Topics in Object Technology Bertrand Meyer.
1 Introduction to: Design by Contract Fall 2005 OOPD John Anthony.
Software Verification Bertrand Meyer Chair of Software Engineering Lecture 2: Axiomatic semantics.
Chair of Software Engineering OOSC - Summer Semester Bertrand Meyer Object-Oriented Software Construction Lecture 7: Inheritance.
Chair of Software Engineering Einführung in die Programmierung Introduction to Programming Prof. Dr. Bertrand Meyer Exercise Session 7.
Chair of Software Engineering Einführung in die Programmierung Introduction to Programming Prof. Dr. Bertrand Meyer Lecture 20: Multiple inheritance.
Chair of Software Engineering Einführung in die Programmierung Introduction to Programming Prof. Dr. Bertrand Meyer Lecture 9: Abstraction.
Inheritance and Polymorphism CS351 – Programming Paradigms.
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.
© Bertrand Meyer and Yishai Feldman Notice Some of the material is taken from Object-Oriented Software Construction, 2nd edition, by Bertrand Meyer (Prentice.
Introduction CS 3358 Data Structures. What is Computer Science? Computer Science is the study of algorithms, including their  Formal and mathematical.
Eiffel Naeem Esfahani University of Tehran "Man cannot discover new oceans unless he has the courage to lose sight of the shore." -- Andre Gide.
Tammy Dahlgren with Tom Epperly, Scott Kohn, and Gary Kumfert Center for Applied Scientific Computing Common Component Architecture Working Group October.
OOSCCh11r1:DbC RJL Slide #1 OOSC: Ch11 vs. Predecessors [Meyer:] Equipped with the basic concepts of class, object and genericity, you can by now.
Contracts for Concurrency - Contracts & Inheritance Aryabrata Basu University of Georgia.
Type == Class  reference type -- store only the object’s address  simple (primitive) type -- for storing small data values Other options Wrapper classes.
90-723: Data Structures and Algorithms for Information Processing Copyright © 1999, Carnegie Mellon. All Rights Reserved. 1 Lecture 1: Introduction Data.
Protocols Software Engineering II Wirfs Brock et al, Designing Object-Oriented Software, Prentice Hall, Mitchell, R., and McKim, Design by Contract,
L13: Design by Contract Definition Reliability Correctness Pre- and post-condition Asserts and Exceptions Weak & Strong Conditions Class invariants Conditions.
© Bertrand Meyer and Yishai Feldman Notice Some of the material is taken from Object-Oriented Software Construction, 2nd edition, by Bertrand Meyer (Prentice.
Interfaces F What is an Interface? F Creating an Interface F Implementing an Interface F What is Marker Interface?
Ceg860 (Prasad)L17IT1 Inheritance Techniques Subcontracting Anchored Types.
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.
CSSE501 Object-Oriented Development. Chapter 10: Subclasses and Subtypes  In this chapter we will explore the relationships between the two concepts.
Banaras Hindu University. A Course on Software Reuse by Design Patterns and Frameworks.
Computer Engineering Rabie A. Ramadan Lecture 6.
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.
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.
© 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
Specifying Object Interfaces
Java Programming Language
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
Design by contract Object-Oriented Software Construction by Bertrand Meyer, Prentice Hall The presence of a precondition or postcondition in a routine.
Contract-Based Programming with/without Ada 2012
Presentation transcript:

Inheritance

class RECTANGLE inherit POLYGON RECTANGLE includes features of POLYGON r: RECTANGLE; p: POLYGON Polymorphism p := r -- legal assignment Dynamic binding p := r p.perimeter -- perimeter of RECTANGLE is called class TA inherit TEACHER STUDENT Inheritance: Multiple Inheritance:

Special syntax (1) class RECTANGLE inherit POLYGON redefine perimeter end feature perimeter : REAL is … end … end Redefinition allows the feature clause of RECTANGLE to contain a new version of method perimeter Redefine:

Special syntax (2) class TA inherit TEACHER rename id as teacher_id end STUDENT rename id as student_id end feature … end Several or none features can be renamed for each parent Rename:

Example class TA inherit TEACHER -- first inherited class rename -- renaming features of TEACHER id as teacher_id, mark as get_mark redefine – redefining methods of TEACHER get_mark, -- need to use last defined name add_factor end STUDENT – second inherited class rename -- renaming of features of STUDENT id as student_id, mark as set_mark end …

Abstract class deferred class DIGIT feature value : INTEGER -- current value lowest: INTEGER is -- lowest legal value deferred end A deferred class is a class that has at least one deferred feature There is no need in redefinition for features inherited in deferred form

The role of deferred class Capturing high-level classes, with common behaviors. Defining the components of an architecture during system design, without commitment to a final implementation. Describing domain-specific concepts in analysis and modeling.

Example deferred class STACK [G] feature -- Access count : INTEGER is-- Number of inserted elements deferred end item: G is-- Last pushed element require not_empty: not empty deferred end;

Example (cont) feature -- Status report empty : BOOLEAN is-- Is stack empty do Result := (count = 0) end full : BOOLEAN is-- Is stack full deferred end feature – Element change put(x : G ) is-- Push x on top require not_full: not full deferred ensure not_empty: not empty pushed_in_top: item = x one_more: count = old count + 1 end

Assertion Redeclaration rule In the redeclared version of a routine, it is not permitted to use a require or ensure clause. Instead you may: Introduce a new condition with require else, for boolean or with the original precondition. Introduce a new condition with ensure then, for boolean and with the original postcondition. In the absence of such a clause, the original assertions are retained.

Example (1) deferred class A … foo (x : INTEGER ) is require r1 deferred … end end; class B inherit A … foo (x : INTEGER ) is require r2 do … end end; The actual requirement is

Example (2) deferred class A … foo (x : INTEGER ) is deferred … ensure e1 end end; class B inherit A … foo (x : INTEGER ) is do… ensure e2 end end; The actual promise is

Invariants Redeclaration rule The invariant property of class is the boolean and of the assertions appearing in its invariant clause and of the invariant properties of its parents if any.

Example class A … invariant i1 end; class B inherit A … invariant i2 end; The actual invariant is

Example (1) deferred class COURSE feature -- mark treatment average : INTEGER-- average of marks num_marks : INTEGER-- marks number add_mark(mark : INTEGER) is require legal_new_mark: mark >= 0 and mark <= 100 deferred ensure num_marks = old num_marks + 1 end

Example (2) calc_factor (new_avg : INTEGER) : INTEGER is require legal_new_avg: new_avg >= 0 and new_avg <= 100 deferred ensure legal_calc_factor: average + Result = new_avg end invariant legal_avarage: average >= 0 and average <= 100 legar_num_marks: num_marks >= 0 end;

Example (3) class LOGIC inherit COURSE creation feature add_mark(mark : INTEGER) is require legal_new_mark: mark >= 0 and mark <= 55 do if mark = 0 then average := mark else average := (average*num_marks + mark)//(num_marks + 1) end num_marks := num_marks + 1 end

Example (4) calc_factor (new_avg : INTEGER) : INTEGER is require legal_new_avg: new_avg >= 0 and new_avg <= 55 do if average > 50 then Result := new_avg - average else Result := 0 end ensure legal_factor: Result <= 0 end invariant legal_avarage: average >= 0 and average <= 55 end;

Example (5) class MAIN logic: LOGIC -- logic.add_mark(56) -- for now average >= 55 so LOGIC invariant violation logic.add_mark(46) logic.add_mark(56) io.put_line("Average is " + logic.average.out) -- average = 51 < io.put_line("factor for average 55 is " + logic.calc_factor(55).out) -- factor = 4 so LOGIC ensure legal_factor violation io.put_line("factor for average 50 is " + logic.calc_factor(50).out) -- factor -1 logic.add_mark(40) -- average io.put_line("factor for average 50 is " + logic.calc_factor(50).out) -- factor = 0 so COURSE ensure legal_calc_factor violation