Object-Oriented Design

Save this PDF as:
 WORD  PNG  TXT  JPG

Size: px
Start display at page:

Download "Object-Oriented Design"

Transcription

1 Object-Oriented Design Department of Computer Engineering Lecture 12: Object-Oriented Principles Sharif University of Technology 1

2 Open Closed Principle (OCP) Classes should be open for extension but closed for modification. OCP states that we should be able to add new features to our system without having to modify our set of preexisting classes. One of the tenets of OCP is to reduce the coupling between classes to the abstract level. Instead of creating relationships between two concrete classes, we create relationships between a concrete class and an abstract class or an interface. Sharif University of Technology 2

3 Open Closed Principle (OCP) Example Sharif University of Technology 3

4 Open Closed Principle (OCP) Solution Sharif University of Technology 4

5 Liskov Substitution Principle (LSP) Subclasses should be substitutable for their base classes. Also called the substitutability principle. Sharif University of Technology 5

6 Dependency Inversion Principle (DIP) Depend upon abstractions. Do not depend upon concretions. The Dependency Inversion Principle (DIP) formalizes the concept of abstract coupling and clearly states that we should couple at the abstract level, not at the concrete level. DIP tells us how we can adhere to OCP. Sharif University of Technology 6

7 Dependency Inversion Principle (DIP) Sharif University of Technology 7

8 Dependency Inversion Principle (DIP) let's assume the Manager class is quite complex, containing very complex logic. Now we have to change it in order to introduce the new SuperWorker Solution: Manager class doesn't require changes when adding SuperWorkers. Minimized risk to affect old functionality present in Manager class since we don't change it. No need to redo the unit testing for Manager class. Sharif University of Technology 8

9 Dependency Inversion Principle (DIP) Sharif University of Technology 9

10 Interface Segregation Principle (ISP) Many specific interfaces are better than a single, general interface. Any interface we define should be highly cohesive. Sharif University of Technology 10

11 Composite Reuse Principle (CRP) Favor polymorphic composition of objects over inheritance. One of the most catastrophic mistakes that contribute to the demise of an object-oriented system is to use inheritance as the primary reuse mechanism. Delegation can be a better alternative to Inheritance. Sharif University of Technology 11

12 Composite Reuse Principle (CRP) Delegation can be seen as a reuse mechanism at the object level, while inheritance is a reuse mechanism at the class level. suppose an Employee class has a method for computing the employee's annual bonus: class Employee { Money computebonus() { /* skimpy default bonus */ } // etc.} Different subclasses of Employee: Manager, Programmer, Secretary, etc. may want to override this method to reflect the fact that some types of employees (managers) get more generous bonuses than others (secretaries and programmers): class Manager extends Employee { Money computebonus() { /* gerenous bonus */ } // etc.} There are several problems with this solution. Sharif University of Technology 12

13 Composite Reuse Principle (CRP) All programmers get the same bonus. What if we wanted to vary the bonus computation among programmers? Would we need to introduce a special subclass of Programmer? class SeniorProgrammer extends Programmer { Money computebonus() { /* gerenous bonus */ } // etc.} Note also that this leads to code duplication. What if we wanted to change the bonus computation for a particular employee? For example, what if we wanted to promote Smith from programmer to senior programmer? Would this require us to recompile any code? What if we decided to give all programmers the same generous bonus that managers get? What changes would we need to make? Should "generous bonus" become the new default algorithm that is overridden in the Secretary class with the skimpy bonus algorithm? Should we copy and paste the "generous bonus" algorithm from manager to Programmer? Sharif University of Technology 13

14 Composite Reuse Principle (CRP) Now different employees can have different bonus calculators, regardless of the class they instantiate. Even better, the bonus calculator used by a particular employee can be changed dynamically. Sharif University of Technology 14

15 Principle of Least Knowledge (PLK) For an operation O on a class C, only operations on the following objects should be called: itself, its parameters, objects it creates, or its contained instance objects. Also called the Law of Demeter. The basic idea is to avoid calling any methods on an object where the reference to that object is obtained by calling a method on another object (Transitive Visibility). The primary benefit is that the calling method doesn t need to understand the structural makeup of the object its invoking methods upon. Sharif University of Technology 15

16 Principle of Least Knowledge (PLK) LoD (or Principle of Least Knowledge): Each module should have only limited knowledge about other units: only units "closely" related to the current unit In particular: Don t talk to strangers! For instance, no a.getb().getc().foo() Motivated by low coupling Sharif University of Technology 16

17 GRASP Acronym stands for General Responsibility Assignment Software Patterns. A set of 9 Patterns introduced as a learning aid by Craig Larman. Describe fundamental principles for object-oriented design and responsibility assignment, expressed as patterns. The skillful assignment of responsibilities is extremely important in object design. Determining the assignment of responsibilities often occurs during the creation of interaction diagrams, and certainly during programming. Sharif University of Technology 17

18 1. Information Expert 2.Creator 3. Low Coupling 4.High Cohesion 5. Controller 6.Polymorphism 7. Indirection 8.Pure Fabrication GRASP: Patterns 9.Protected Variations Sharif University of Technology 18

19 GRASP: Information Expert As a general principle of assigning responsibilities to objects, assign a responsibility to the information expert: i.e. the class that has the information necessary to fulfill the responsibility. Sharif University of Technology 19

20 GRASP: Information Expert Given an object o, which responsibilities can be assigned to o? Expert principle says assign those responsibilities to o for which o has the information to fulfill that responsibility. They have all the information needed to perform operations, or in some cases they collaborate with others to fulfill their responsibilities. Sharif University of Technology 20

21 GRASP: Example for Expert Assume we need to get all the videos of a VideoStore. Since VideoStore knows about all the videos, we can assign this responsibility of giving all the videos can be assigned to VideoStore class. VideoStore is the information expert. Sharif University of Technology 21

22 GRASP: Another Example for Expert Who should be responsible for knowing the grand total of a sale? Sharif University of Technology 22

23 GRASP: Creator Assign class B the responsibility to create an instance of class A if one or more of the following is true: B aggregates A objects. B contains A objects. B records instances of A objects. B closely uses A objects. B has the initializing data that will be passed to A when it is created (thus B is an Expert with respect to creating A). B is a creator of A objects. If more than one option applies, prefer a class B which aggregates or contains class A. Sharif University of Technology 23

24 GRASP: Creator Container object creates contained objects. Decide who can be creator based on the objects association and their interaction. Consider VideoStore and Video in that store. VideoStore has an aggregation association with Video. i.e, VideoStore is the container and the Video is the contained object. So, we can instantiate video object in VideoStore class Sharif University of Technology 24

25 GRASP: Low Coupling Assign a responsibility so that coupling remains low. A class with high (or strong) coupling relies on many other classes. Such classes may be undesirable; some suffer from the following problems: Changes in related classes force local changes. Harder to understand in isolation. Harder to reuse because its use requires the additional presence of the classes on which it is dependent. Sharif University of Technology 25

26 GRASP: Low Coupling Two elements are coupled, if One element has aggregation/composition association with another element. One element implements/extends other element. Sharif University of Technology 26

27 GRASP: Low Coupling Sharif University of Technology 27

28 GRASP: High Cohesion Assign a responsibility so that cohesion remains high. A class with low cohesion does many unrelated things, or does too much work. Such classes are undesirable; they suffer from the following problems: hard to comprehend hard to reuse hard to maintain Delicate: constantly affected by change Sharif University of Technology 28

29 GRASP: High Cohesion Sharif University of Technology 29

30 GRASP: Controller Assign the responsibility for receiving or handling a system event message to a class representing one of the following choices: Represents the overall system, device, or subsystem (facade controller). Represents a use case scenario within which the system event occurs (a usecase- or session-controller). Use the same controller class for all system events in the same use case scenario. Informally, a session is an instance of a conversation with an actor. Note that "window," "applet," "widget," "view," and "document" classes are not on this list. Such classes should not fulfill the tasks associated with system events, they typically delegate these events to a controller. Sharif University of Technology 30

31 GRASP: Controller Deals with how to delegate the request from the UI layer objects to domain layer objects. This object is called controller object which receives request from UI layer object and then controls/coordinates with other object of the domain layer to fulfill the request. It delegates the work to other class and coordinates the overall activity Sharif University of Technology 31

32 GRASP: Polymorphism When related alternatives or behaviors vary by type (class), assign responsibility for the behavior using polymorphic operations to the types for which the behavior varies. Define the behavior in a common base class or, preferably, in an interface. Sharif University of Technology 32

33 GRASP: Indirection Assign the responsibility to an intermediate object to mediate between other components or services so that they are not directly coupled. The intermediary creates an indirection between the other components. Beware of transitive visibility. Sharif University of Technology 33

34 GRASP: Indirection Here polymorphism illustrates indirection Class Employee provides a level of indirection to other units of the system. Sharif University of Technology 34

35 GRASP: Pure Fabrication Assign a highly cohesive set of responsibilities to an artificial or convenience class that does not represent a problem domain concept something made up, to support high cohesion, low coupling, and reuse. Example: a class that is solely responsible for saving objects in some kind of persistent storage medium, such as a relational database; call it the PersistentStorage. This class is a Pure Fabrication a figment of the imagination. Sharif University of Technology 35

36 GRASP: Pure Fabrication Fabricated class/ artificial class assign set of related responsibilities that doesn't represent any domain object. Provides a highly cohesive set of activities. Examples: Adapter, Strategy Benefits: High cohesion, low coupling and can reuse this class. Sharif University of Technology 36

37 GRASP: Pure Fabrication Suppose we Shape class, if we must store the shape data in a database. If we put this responsibility in Shape class, there will be many database related operations thus making Shape incohesive. So, create a fabricated class DBStore which is responsible to perform all database operations. Similarly loginterface which is responsible for logging information is also a good example for Pure Fabrication. Sharif University of Technology 37

38 GRASP: Protected Variations Identify points of predicted variation or instability; assign responsibilities to create a stable interface around them. Note: The term "interface" is used in the broadest sense of an access view; it does not literally only mean something like a Java or COM interface. Sharif University of Technology 38

39 Design by Contract (DBC) A discipline of analysis, design, implementation, and management. Bertrand Meyer introduced Design by Contract in Eiffel as a powerful technique for producing reliable software. Its key elements are assertions: boolean expressions that define correct program states at arbitrary locations in the code. Sharif University of Technology 39

40 Design by Contract (DBC): Assertions Simple assertions belong to individual statements in a program, yet important DBC assertions are defined on classes: Per- method assertions: Precondition: A condition that must be true of the parameters of a method and/or data members if the method is to behave correctly PRIOR to running the code in the method. Postcondition: A condition that is true AFTER running the code in a method. Per-class assertions: Class Invariant: A condition that is true BEFORE and AFTER running the code in a method (except constructors and destructors). Sharif University of Technology 40

41 Design by Contract (DBC): Contract Assertions in a class specify a contract between its instances and their clients. According to the contract a server promises to return results satisfying the postconditions if a client requests available services and provides input data satisfying the preconditions. Invariants must be satisfied before and after each service. Neither party to the contract (the clients/consumers and servers/suppliers) shall be allowed to rely on something else than that which is explicitly stated in the contract. Sharif University of Technology 41

42 Design by Contract (DBC): Inheritance The class invariants of all ancestors must also be obeyed by all children; they can also be strengthened. Inherited preconditions may only be weakened. This means a new implementation may never restrict the circumstances under which a client call is valid beyond what has been specified by the ancestor. It may, however, relax the rules and also accept calls that would have been rejected by the ancestor. Inherited postconditions may only be strengthened. This means a new implementation must fulfil what the ancestors have undertaken to do, but may deliver more. "Children should not provide less or expect more than their ancestors." Sharif University of Technology 42

43 Reference Larman, C., Applying UML and Patterns: An Introduction to Object- Oriented Analysis and Design and Iterative Development, 3 rd Ed. Prentice-Hall, Sharif University of Technology 43

ADVANCED SOFTWARE DESIGN LECTURE 7 GRASP

ADVANCED SOFTWARE DESIGN LECTURE 7 GRASP ADVANCED SOFTWARE DESIGN LECTURE 7 GRASP Dave Clarke 1 TODAY S LECTURE We will discuss 7 of the GRASP design patterns cohesion and coupling were covered earlier. These provide principles for evaluating

More information

Object-Oriented Design II - GRASP

Object-Oriented Design II - GRASP Object-Oriented Design II - GRASP SWEN-610 Foundations of Software Engineering Department of Software Engineering Rochester Institute of Technology Controller Creator Indirection Information expert High

More information

Last Time: Object Design. Comp435 Object-Oriented Design. Last Time: Responsibilities. Last Time: Creator. Last Time: The 9 GRASP Patterns

Last Time: Object Design. Comp435 Object-Oriented Design. Last Time: Responsibilities. Last Time: Creator. Last Time: The 9 GRASP Patterns Last Time: Object Design Comp435 Object-Oriented Design Week 7 Computer Science PSU HBG The main idea RDD: Responsibility-Driven Design Identify responsibilities Assign them to classes and objects Responsibilities

More information

Patterns and Testing

Patterns and Testing and Lecture # 7 Department of Computer Science and Technology University of Bedfordshire Written by David Goodwin, based on the lectures of Marc Conrad and Dayou Li and on the book Applying UML and (3

More information

Object-Oriented Design I

Object-Oriented Design I Object-Oriented Design I SWEN-261 Introduction to Software Engineering Department of Software Engineering Rochester Institute of Technology Single responsibility High cohesion Information expert Low coupling

More information

Information Expert (or Expert)

Information Expert (or Expert) Page 2 Page 3 Pattern or Principle? Information Expert (or Expert) Class Responsibility Sale Knows Sale total SalesLineItem Knows line item total ProductDescription Knows product price The GRASP patterns

More information

Object Analysis & Design in the textbook. Introduction to GRASP: Assigning Responsibilities to Objects. Responsibility-Driven Design

Object Analysis & Design in the textbook. Introduction to GRASP: Assigning Responsibilities to Objects. Responsibility-Driven Design Object Analysis & Design in the textbook Chapter 2 Object Oriented Design Process Introduction to GRASP: Assigning Responsibilities to Objects CS 4354 Summer II 2016 Jill Seaman Much of the material in

More information

Object-Oriented Design I - SOLID

Object-Oriented Design I - SOLID Object-Oriented Design I - SOLID SWEN-261 Introduction to Software Engineering Department of Software Engineering Rochester Institute of Technology Single responsibility Open/close Liskov substitution

More information

SOLID Principles. Equuleus Technologies. Optional Subheading October 19, 2016

SOLID Principles. Equuleus Technologies. Optional Subheading October 19, 2016 SOLID Principles Optional Subheading October 19, 2016 Why SOLID Principles? The traits of well designed software are as follows Maintainability - The ease with which a software system or component can

More information

Abstraction. Design fundamentals in OO Systems. Fundamental Software Development Principles

Abstraction. Design fundamentals in OO Systems. Fundamental Software Development Principles Abstraction Design fundamentals in OO Systems Tool for abstraction: object Object structure: properties and values for those properties operations to query and update those properties We refer to the collection

More information

ADVANCED SOFTWARE DESIGN LECTURE 4 SOFTWARE ARCHITECTURE

ADVANCED SOFTWARE DESIGN LECTURE 4 SOFTWARE ARCHITECTURE ADVANCED SOFTWARE DESIGN LECTURE 4 SOFTWARE ARCHITECTURE Dave Clarke 1 THIS LECTURE At the end of this lecture you will know notations for expressing software architecture the design principles of cohesion

More information

Learning Objectives. C++ For Artists 2003 Rick Miller All Rights Reserved xli

Learning Objectives. C++ For Artists 2003 Rick Miller All Rights Reserved xli Identify and overcome the difficulties encountered by students when learning how to program List and explain the software development roles played by students List and explain the phases of the tight spiral

More information

Principles of Software Construction: Objects, Design and Concurrency. Object-Oriented Design: Assigning Responsibilities.

Principles of Software Construction: Objects, Design and Concurrency. Object-Oriented Design: Assigning Responsibilities. Principles of Software Construction: Objects, Design and Concurrency 15-214 toad Object-Oriented Design: Assigning Responsibilities Christian Kästner Charlie Garrod School of Computer Science With slides

More information

Object-Oriented Design

Object-Oriented Design Object-Oriented Design Lecture 14: Design Workflow Department of Computer Engineering Sharif University of Technology 1 UP iterations and workflow Workflows Requirements Analysis Phases Inception Elaboration

More information

Assigning Responsibilities

Assigning Responsibilities Principles of Software Construction: Objects, Design, and Concurrency (Part 2: Designing (Sub-)Systems) Assigning Responsibilities Christian Kästner Bogdan Vasilescu School of Computer Science 1 2 2 Learning

More information

17.11 Bean Rules persistent

17.11 Bean Rules persistent 17.10 Java Beans Java beans are a framework for creating components in Java. AWT and Swing packages are built within this framework Made to fit in with graphic development environments such as Jbuilder

More information

2 GRASP Patterns and basic OO Design. Roel Wuyts OASS

2 GRASP Patterns and basic OO Design. Roel Wuyts OASS 2 GRASP Patterns and basic OO Design Roel Wuyts OASS1 2009-2010 Patterns 2 Bit of history... Christoffer Alexander The Timeless Way of Building, Christoffer Alexander, Oxford University Press, 1979, ISBN

More information

Principles of Object-Oriented Design

Principles of Object-Oriented Design Principles of Object-Oriented Design 1 The Object-Oriented... Hype What are object-oriented (OO) methods? OO methods provide a set of techniques for analysing, decomposing, and modularising software system

More information

Outline. Design Principles: Part 2. e.g. Rectangles and Squares. The Liskov Substitution Principle (LSP) ENGI 5895: Software Design.

Outline. Design Principles: Part 2. e.g. Rectangles and Squares. The Liskov Substitution Principle (LSP) ENGI 5895: Software Design. Liskov Substitution Principle (LSP) Dependency-Inversion Principle (DIP) Interface-Segregation Principle (ISP) Liskov Substitution Principle (LSP) Dependency-Inversion Principle (DIP) Interface-Segregation

More information

Chapter 1: Principles of Programming and Software Engineering

Chapter 1: Principles of Programming and Software Engineering Chapter 1: Principles of Programming and Software Engineering Data Abstraction & Problem Solving with C++ Fifth Edition by Frank M. Carrano Software Engineering and Object-Oriented Design Coding without

More information

Object-Oriented Design II

Object-Oriented Design II Object-Oriented Design II SWEN-261 Introduction to Software Engineering Department of Software Engineering Rochester Institute of Technology Controller Pure fabrication Open/close Polymorphism Liskov substitution

More information

Inheritance. One class inherits from another if it describes a specialized subset of objects Terminology:

Inheritance. One class inherits from another if it describes a specialized subset of objects Terminology: Inheritance 1 Inheritance One class inherits from another if it describes a specialized subset of objects Terminology: the class that inherits is called a child class or subclass the class that is inherited

More information

CS342: Software Design. November 21, 2017

CS342: Software Design. November 21, 2017 CS342: Software Design November 21, 2017 Runnable interface: create threading object Thread is a flow of control within a program Thread vs. process All execution in Java is associated with a Thread object.

More information

Object-Oriented Analysis and Design

Object-Oriented Analysis and Design 0. Object Orientation: An Subject/Topic/Focus: over this lecture Summary: Lecturer, lecture, rooms, assistants, lab classes, credit points... Need for systems analysis and software engineers Literature

More information

Object Oriented. Analysis and Design

Object Oriented. Analysis and Design OODP- OOAD Session 5 Object Oriented Analysis and Design Oded Lachish Department of Computer Science and Information Systems Birkbeck College, University of London Email: oded@dcs.bbk.ac.uk Web Page: http://www.dcs.bbk.ac.uk/~oded

More information

Requirements and Design Overview

Requirements and Design Overview Requirements and Design Overview Robert B. France Colorado State University Robert B. France O-1 Why do we model? Enhance understanding and communication Provide structure for problem solving Furnish abstractions

More information

Granularity. Inheritance Bi-directional. Association. Derived A1

Granularity. Inheritance Bi-directional. Association. Derived A1 Granularity This is the fifth of my Engineering Notebook columns for The C++ Report. The articles that appear in this column focus on the use of C++ and OOD, and address issues of software engineering.

More information

Chapter 11 Classes Continued

Chapter 11 Classes Continued Chapter 11 Classes Continued The real power of object-oriented programming comes from its capacity to reduce code and to distribute responsibilities for such things as error handling in a software system.

More information

11/2/09. Code Critique. What goal are we designing to? What is the typical fix for code smells? Refactoring Liskov Substitution Principle

11/2/09. Code Critique. What goal are we designing to? What is the typical fix for code smells? Refactoring Liskov Substitution Principle Code Critique Identifying smells Refactoring Liskov Substitution Principle What goal are we designing to? What is the typical fix for code smells? What is a limitation of those fixes? How do we address

More information

C++ Modern and Lucid C++ for Professional Programmers

C++ Modern and Lucid C++ for Professional Programmers Informatik C++ Modern and Lucid C++ for Professional Programmers part 13 Prof. Peter Sommerlad Institutsleiter IFS Institute for Software Rapperswil, HS 2015 Inheritance and dynamic Polymorphism base classes,

More information

Component-Level Design

Component-Level Design Component-Level Design Minsoo Ryu Hanyang University Contents 1. Design Model 2. Fundamental Design Concepts 3. Component-Level Design 4. Object-Oriented Design Techniques 2 2 Data/class design Four Design

More information

Component-Level Design. Slides copyright 1996, 2001, 2005, 2009 by Roger S. Pressman. For non-profit educational use only

Component-Level Design. Slides copyright 1996, 2001, 2005, 2009 by Roger S. Pressman. For non-profit educational use only Chapter 10 Component-Level Design Slide Set to accompany Software Engineering: A Practitioner s Approach, 7/e by Roger S. Pressman Slides copyright 1996, 2001, 2005, 2009 by Roger S. Pressman For non-profit

More information

Lecture: Modular Design

Lecture: Modular Design Software Engineering Lecture: Modular Design Thomas Fritz Many thanks to Philippe Beaudoin, Gail Murphy, David Shepherd, Neil Ernst and Meghan Allen Reading! For next lecture: (all required) Composite

More information

CSSE 374: GRASP ing at the First Five Patterns Principles. Shawn Bohner Office: Moench Room F212 Phone: (812)

CSSE 374: GRASP ing at the First Five Patterns Principles. Shawn Bohner Office: Moench Room F212 Phone: (812) CSSE 374: GRASP ing at the First Five Patterns Principles Shawn Bohner Office: Moench Room F22 Phone: (82) 877-8685 Email: bohner@rose-hulman.edu Learning Outcomes: Patterns, Tradeoffs Identify criteria

More information

THE OBJECT-ORIENTED DESIGN PROCESS AND DESIGN AXIOMS (CH -9)

THE OBJECT-ORIENTED DESIGN PROCESS AND DESIGN AXIOMS (CH -9) THE OBJECT-ORIENTED DESIGN PROCESS AND DESIGN AXIOMS (CH -9) By: Mr.Prachet Bhuyan Assistant Professor, School of Computer Engineering, KIIT Topics to be Discussed 9.1 INTRODUCTION 9.2 THE O-O DESIGN PROCESS

More information

EPL 603 TOPICS IN SOFTWARE ENGINEERING. Lab 6: Design Patterns

EPL 603 TOPICS IN SOFTWARE ENGINEERING. Lab 6: Design Patterns EPL 603 TOPICS IN SOFTWARE ENGINEERING Lab 6: Design Patterns Links to Design Pattern Material 1 http://www.oodesign.com/ http://www.vincehuston.org/dp/patterns_quiz.html Types of Design Patterns 2 Creational

More information

The GoF Design Patterns Reference

The GoF Design Patterns Reference The GoF Design Patterns Reference Version.0 / 0.0.07 / Printed.0.07 Copyright 0-07 wsdesign. All rights reserved. The GoF Design Patterns Reference ii Table of Contents Preface... viii I. Introduction....

More information

Principles of Object-Oriented Design

Principles of Object-Oriented Design Principles of Object-Oriented Design Part II 1 The Law of Demeter Any object receiving a message in a given method must be one of a restricted set of objects. 1. Strict Form: Every supplier class or object

More information

Credit where Credit is Due. Lecture 4: Fundamentals of Object Technology. Goals for this Lecture. Real-World Objects

Credit where Credit is Due. Lecture 4: Fundamentals of Object Technology. Goals for this Lecture. Real-World Objects Lecture 4: Fundamentals of Object Technology Kenneth M. Anderson Object-Oriented Analysis and Design CSCI 6448 - Spring Semester, 2003 Credit where Credit is Due Some material presented in this lecture

More information

NOTES ON OBJECT-ORIENTED MODELING AND DESIGN

NOTES ON OBJECT-ORIENTED MODELING AND DESIGN NOTES ON OBJECT-ORIENTED MODELING AND DESIGN Stephen W. Clyde Brigham Young University Provo, UT 86402 Abstract: A review of the Object Modeling Technique (OMT) is presented. OMT is an object-oriented

More information

Exam in TDDB84: Design Patterns,

Exam in TDDB84: Design Patterns, Exam in TDDB84: Design Patterns, 2014-10-24 14-18 Information Observe the following, or risk subtraction of points: 1) Write only the answer to one task on one sheet. Use only the front side of the sheets

More information

Design Patterns. An introduction

Design Patterns. An introduction Design Patterns An introduction Introduction Designing object-oriented software is hard, and designing reusable object-oriented software is even harder. Your design should be specific to the problem at

More information

Goals of Lecture. Lecture 27: OO Design Patterns. Pattern Resources. Design Patterns. Cover OO Design Patterns. Pattern Languages of Programming

Goals of Lecture. Lecture 27: OO Design Patterns. Pattern Resources. Design Patterns. Cover OO Design Patterns. Pattern Languages of Programming Goals of Lecture Lecture 27: OO Design Patterns Cover OO Design Patterns Background Examples Kenneth M. Anderson Object-Oriented Analysis and Design CSCI 6448 - Spring Semester, 2001 April 24, 2001 Kenneth

More information

The architecture of Eiffel software 3.1 OVERVIEW classes clusters systems

The architecture of Eiffel software 3.1 OVERVIEW classes clusters systems 3 Draft 5.02.00-0, 15 August 2005 (Santa Barbara). Extracted from ongoing work on future third edition of Eiffel: The Language. Copyright Bertrand Meyer 1986-2005. Access restricted to purchasers of the

More information

Originality is Overrated: OO Design Principles

Originality is Overrated: OO Design Principles Originality is Overrated: OO Design Principles Kenneth M. Anderson University of Colorado, Boulder CSCI 4448/6448 Lecture 13 10/09/2007 University of Colorado, 2007 1 Lecture Goals Review material from

More information

Exheritance Class Generalisation Revived

Exheritance Class Generalisation Revived Exheritance Class Generalisation Revived Markku Sakkinen Information Technology Research Institute University of Jyväskylä P.O.Box 35 (Agora) FIN-40351 Jyväskylä Finland sakkinenm@acm.org or sakkinen@cs.jyu.fi

More information

Lecture 20: Design Patterns II

Lecture 20: Design Patterns II Lecture 20: Design Patterns II Software System Design and Implementation ITCS/ITIS 6112/8112 001 Fall 2008 Dr. Jamie Payton Department of Computer Science University of North Carolina at Charlotte Nov.

More information

Design Pattern. CMPSC 487 Lecture 10 Topics: Design Patterns: Elements of Reusable Object-Oriented Software (Gamma, et al.)

Design Pattern. CMPSC 487 Lecture 10 Topics: Design Patterns: Elements of Reusable Object-Oriented Software (Gamma, et al.) Design Pattern CMPSC 487 Lecture 10 Topics: Design Patterns: Elements of Reusable Object-Oriented Software (Gamma, et al.) A. Design Pattern Design patterns represent the best practices used by experienced

More information

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

CS 307: Software Engineering. Lecture 10: Software Design and Architecture CS 307: Software Engineering Lecture 10: Software Design and Architecture Prof. Jeff Turkstra 2017 Dr. Jeffrey A. Turkstra 1 Announcements Discuss your product backlog in person or via email by Today Office

More information

DESIGN PATTERN - INTERVIEW QUESTIONS

DESIGN PATTERN - INTERVIEW QUESTIONS DESIGN PATTERN - INTERVIEW QUESTIONS http://www.tutorialspoint.com/design_pattern/design_pattern_interview_questions.htm Copyright tutorialspoint.com Dear readers, these Design Pattern Interview Questions

More information

Eiffel, a pure OO language with support for Design by Contract

Eiffel, a pure OO language with support for Design by Contract Eiffel, a pure OO language with support for From the perspective of a PHP programmer by Berend de Boer 1 class HELLO_WORLD 2 creation 3 make 4 feature -- Initialization 5 make is 6 do 7 print ("hello world")

More information

CS-202 Introduction to Object Oriented Programming

CS-202 Introduction to Object Oriented Programming CS-202 Introduction to Object Oriented Programming California State University, Los Angeles Computer Science Department Lecture III Inheritance and Polymorphism Introduction to Inheritance Introduction

More information

Chapter 5 Object-Oriented Programming

Chapter 5 Object-Oriented Programming Chapter 5 Object-Oriented Programming Develop code that implements tight encapsulation, loose coupling, and high cohesion Develop code that demonstrates the use of polymorphism Develop code that declares

More information

Object Oriented Design

Object Oriented Design Object Oriented Design Chapter 12 continue 12.6 Case Study: Payroll System Using Polymorphism This section reexamines the CommissionEmployee- BasePlusCommissionEmployee hierarchy that we explored throughout

More information

Goals of design. satisfies problem requirements, usable error free, resistant to incorrect input. readable, not purposefully cryptic.

Goals of design. satisfies problem requirements, usable error free, resistant to incorrect input. readable, not purposefully cryptic. OOP design revisited design revisited 1 Goals of design usable software robust implementable understandable reusable generalizable extendable solves the problem, satisfies problem requirements, usable

More information

The Liskov Substitution Principle

The Liskov Substitution Principle Agile Design Principles: The Liskov Substitution Principle Based on Chapter 10 of Robert C. Martin, Agile Software Development: Principles, Patterns, and Practices, Prentice Hall, 2003 and on Barbara Liskov

More information

Improve Your SystemVerilog OOP Skills

Improve Your SystemVerilog OOP Skills 1 Improve Your SystemVerilog OOP Skills By Learning Principles and Patterns Jason Sprott Verilab Email: jason.sprott@verilab.com www.verilab.com Experts in SV Learn Design Patterns 2 Look, you don t need

More information

Lecture 13: Design Patterns

Lecture 13: Design Patterns 1 Lecture 13: Design Patterns Kenneth M. Anderson Object-Oriented Analysis and Design CSCI 6448 - Spring Semester, 2005 2 Pattern Resources Pattern Languages of Programming Technical conference on Patterns

More information

Programming in the large

Programming in the large Inheritance 1 / 28 Programming in the large Software is complex. Three ways we deal with complexity: Abstraction - boiling a concept down to its essential elements, ignoring irrelevant details Decomposition

More information

Pattern Resources. Lecture 25: Design Patterns. What are Patterns? Design Patterns. Pattern Languages of Programming. The Portland Pattern Repository

Pattern Resources. Lecture 25: Design Patterns. What are Patterns? Design Patterns. Pattern Languages of Programming. The Portland Pattern Repository Pattern Resources Lecture 25: Design Patterns Kenneth M. Anderson Object-Oriented Analysis and Design CSCI 6448 - Spring Semester, 2003 Pattern Languages of Programming Technical conference on Patterns

More information

Highlights of Previous Lecture

Highlights of Previous Lecture Highlights of Previous Lecture Final Project Goals 1. Set up collections of Flights 2. Maintain information about reservation availability on flights 3. Respond to reservation requests 4. Set up collections

More information

1 State, objects, and abstraction

1 State, objects, and abstraction 6.01, Spring Semester, 2008 Course notes for Week 4 1 MASSACHVSETTS INSTITVTE OF TECHNOLOGY Department of Electrical Engineering and Computer Science 6.01 Introduction to EECS I Spring Semester, 2008 Course

More information

Object-Oriented Software Engineering Practical Software Development using UML and Java

Object-Oriented Software Engineering Practical Software Development using UML and Java Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 5: Modelling with Classes Lecture 5 5.1 What is UML? The Unified Modelling Language is a standard graphical

More information

Design Patterns Revisited

Design Patterns Revisited CSC 7322 : Object Oriented Development J Paul Gibson, A207 paul.gibson@int-edu.eu http://www-public.it-sudparis.eu/~gibson/teaching/csc7322/ Design Patterns Revisited /~gibson/teaching/csc7322/l13-designpatterns-2.pdf

More information

Object-Oriented Programming and Design

Object-Oriented Programming and Design C Sc 335 Course Overview Object-Oriented Programming and Design Rick Mercer Major Topics in C Sc 335 1. Java 2. Object-Oriented Programming 3. Object-Oriented Design 4. Technology 5. Object-Oriented Principles

More information

Object Oriented Software Design - I

Object Oriented Software Design - I Object Oriented Software Design - I Object Oriented Design Principles Giuseppe Lipari http://retis.sssup.it/~lipari Scuola Superiore Sant Anna Pisa October 28, 2011 G. Lipari (Scuola Superiore Sant Anna)

More information

Lecture 5: Inheritance

Lecture 5: Inheritance McGill University Computer Science Department COMP 322 : Introduction to C++ Winter 2009 Lecture 5: Inheritance Sami Zhioua March 11 th, 2009 1 Inheritance Inheritance is a form of software reusability

More information

Java Programming Lecture 7

Java Programming Lecture 7 Java Programming Lecture 7 Alice E. Fischer Feb 16, 2015 Java Programming - L7... 1/16 Class Derivation Interfaces Examples Java Programming - L7... 2/16 Purpose of Derivation Class derivation is used

More information

Final Exam CISC 475/675 Fall 2004

Final Exam CISC 475/675 Fall 2004 True or False [2 pts each]: Final Exam CISC 475/675 Fall 2004 1. (True/False) All software development processes contain at least separate planning, testing, and documentation phases. 2. (True/False) The

More information

Software Development Cycle. Unified Modeling Language. Unified Modeling Language. Unified Modeling Language. Unified Modeling Language.

Software Development Cycle. Unified Modeling Language. Unified Modeling Language. Unified Modeling Language. Unified Modeling Language. Plan for today Software Design and UML Building a software system Documenting your design using UML Process for software development People management Work management Team management Caveat: These processes

More information

Liskov Substitution Principle

Liskov Substitution Principle Liskov Substitution Principle Produced by: Eamonn de Leastar (edeleastar@wit.ie) Dr. Siobhán Drohan (sdrohan@wit.ie) Department of Computing and Mathematics http://www.wit.ie/ SOLID Class Design Principles

More information

Testing Object-Oriented Software. 22 November 2017

Testing Object-Oriented Software. 22 November 2017 Testing Object-Oriented Software 22 November 2017 Testing Object-Oriented Software 2 Problems in object-oriented testing [Binder] Each level in the class hierarchy creates a new context for inherited features:

More information

Chapter 11. Categories of languages that support OOP: 1. OOP support is added to an existing language

Chapter 11. Categories of languages that support OOP: 1. OOP support is added to an existing language Categories of languages that support OOP: 1. OOP support is added to an existing language - C++ (also supports procedural and dataoriented programming) - Ada 95 (also supports procedural and dataoriented

More information

Constantinos Constantinides Computer Science and Software Engineering Concordia University Montreal, Canada

Constantinos Constantinides Computer Science and Software Engineering Concordia University Montreal, Canada 1 Disclaimer: These slides are based on the 2 nd edition of Applying UML and Patterns; An introduction to OOAD and the Unified process by Craig Larman (2002). I take responsibility for any errors. Constantinos

More information

A comparative study of Programming by Contract and Programming with Exceptions

A comparative study of Programming by Contract and Programming with Exceptions Computer Science Jimmy Byström Leo Wentzel A comparative study of Programming by Contract and Programming with Exceptions Master s Thesis 2003:02 A comparative study of Programming by Contract and Programming

More information

Lecture 4: Procedure Specifications

Lecture 4: Procedure Specifications Lecture 4: Procedure Specifications 4.1. Introduction In this lecture, we ll look at the role played by specifications of methods. Specifications are the linchpin of team work. It s impossible to delegate

More information

Object-Oriented Design

Object-Oriented Design Object-Oriented Design Lecturer: Raman Ramsin Lecture 20: GoF Design Patterns Creational 1 Software Patterns Software Patterns support reuse of software architecture and design. Patterns capture the static

More information

Application to Library: Re-Architecting a Large Monolithic TCL Application

Application to Library: Re-Architecting a Large Monolithic TCL Application Application to Library: Re-Architecting a Large Monolithic TCL Application William H. Duquette Jet Propulsion Laboratory, California Institute of Technology William.H.Duquette@jpl.nasa.gov Abstract The

More information

Build Testable Client and Service Applications

Build Testable Client and Service Applications Build Testable Client and Service Applications Brian Noyes IDesign Inc (www.idesign.net) brian.noyes@idesign.net About Brian Chief Architect IDesign Inc. (www.idesign.net) Microsoft Regional Director MVP

More information

PROCESSI DI PRODUZIONE E GESTIONE DEL SOFTWARE. Analysis and Design with UML. Paola Turci

PROCESSI DI PRODUZIONE E GESTIONE DEL SOFTWARE. Analysis and Design with UML. Paola Turci PROCESSI DI PRODUZIONE E GESTIONE DEL SOFTWARE Analysis and Design with UML Paola Turci What is Visual Modelling? Modelling captures essential parts of the system. Dr. James Rumbaugh Order Item Ship via

More information

Introduction to Object-Oriented Programming

Introduction to Object-Oriented Programming Polymorphism 1 / 19 Introduction to Object-Oriented Programming Today we ll learn how to combine all the elements of object-oriented programming in the design of a program that handles a company payroll.

More information

CS 520 Theory and Practice of Software Engineering Fall 2017

CS 520 Theory and Practice of Software Engineering Fall 2017 CS 520 Theory and Practice of Software Engineering Fall 2017 OO design principles September 14, 2017 Today Code review and (re)design of an MVC application OO design principles Information hiding (and

More information

Introduction to C++ Introduction to C++ Dr Alex Martin 2013 Slide 1

Introduction to C++ Introduction to C++ Dr Alex Martin 2013 Slide 1 Introduction to C++ Introduction to C++ Dr Alex Martin 2013 Slide 1 Inheritance Consider a new type Square. Following how we declarations for the Rectangle and Circle classes we could declare it as follows:

More information

Introduction to Object-Oriented Programming

Introduction to Object-Oriented Programming Introduction to Object-Oriented Programming Inheritance, Part 2 of 2 Christopher Simpkins chris.simpkins@gatech.edu CS 1331 (Georgia Tech) Inheritance, Part 2 of 2 1 / 14 Access Modifiers Modifier Class

More information

Java How to Program, 8/e

Java How to Program, 8/e Java How to Program, 8/e Polymorphism Enables you to program in the general rather than program in the specific. Polymorphism enables you to write programs that process objects that share the same superclass

More information

R/3 System Object-Oriented Concepts of ABAP

R/3 System Object-Oriented Concepts of ABAP R/3 System Object-Oriented Concepts of ABAP Copyright 1997 SAP AG. All rights reserved. No part of this brochure may be reproduced or transmitted in any form or for any purpose without the express permission

More information

UNIT V CODING AND TESTING 9 Mapping design to code Testing: Issues in OO Testing Class Testing OO Integration Testing GUI Testing OO System Testing.

UNIT V CODING AND TESTING 9 Mapping design to code Testing: Issues in OO Testing Class Testing OO Integration Testing GUI Testing OO System Testing. CS6502 OBJECT ORIENTED ANALYSIS AND DESIGN L T P C 3 0 0 3 UNIT I UML DIAGRAMS 9 Introduction to OOAD Unified Process UML diagrams Use Case Class Diagrams Interaction Diagrams State Diagrams Activity Diagrams

More information

Adapter Pattern Structural

Adapter Pattern Structural Adapter Pattern Structural Intent» Convert the interface of a class into a different interface that a client expects.» Lets classes work together that otherwise could not Adapter-1 Class Adapter Motivation

More information

Lecture 15: Generalization, Polymorphism and States. Copyright W. Howden 1

Lecture 15: Generalization, Polymorphism and States. Copyright W. Howden 1 Lecture 15: Generalization, Polymorphism and States Copyright W. Howden 1 Generalization Creation of super and subtype entities May be program and design classes, concepts, use cases, etc. For programs,

More information

The Design Patterns Matrix From Analysis to Implementation

The Design Patterns Matrix From Analysis to Implementation The Design Patterns Matrix From Analysis to Implementation This is an excerpt from Shalloway, Alan and James R. Trott. Design Patterns Explained: A New Perspective for Object-Oriented Design. Addison-Wesley

More information

Application Architectures, Design Patterns

Application Architectures, Design Patterns Application Architectures, Design Patterns Martin Ledvinka martin.ledvinka@fel.cvut.cz Winter Term 2017 Martin Ledvinka (martin.ledvinka@fel.cvut.cz) Application Architectures, Design Patterns Winter Term

More information

CSC207 Week 3. Larry Zhang

CSC207 Week 3. Larry Zhang CSC207 Week 3 Larry Zhang 1 Announcements Readings will be posted before the lecture Lab 1 marks available in your repo 1 point for creating the correct project. 1 point for creating the correct classes.

More information

OO Design with Multiple Inheritance

OO Design with Multiple Inheritance OO Design with Multiple Inheritance Multiple Inheritance in C++ C++ allows a class to inherit implementation code from multiple superclasses. inheritance (MI). This is referred to as multiple Some programmers

More information

Lethbridge/Laganière 2005 Chapter 9: Architecting and designing software 6

Lethbridge/Laganière 2005 Chapter 9: Architecting and designing software 6 Trying to deal with something big all at once is normally much harder than dealing with a series of smaller things Separate people can work on each part. An individual software engineer can specialize.

More information

Single Responsibility Principle (SRP)

Single Responsibility Principle (SRP) Single Responsibility Principle (SRP) Produced by: Eamonn de Leastar (edeleastar@wit.ie) Dr. Siobhán Drohan (sdrohan@wit.ie) Department of Computing and Mathematics http://www.wit.ie/ SOLID Class Design

More information

Late-bound Pragmatical Class Methods

Late-bound Pragmatical Class Methods Late-bound Pragmatical Class Methods AXEL SCHMOLITZKY, MARK EVERED, J. LESLIE KEEDY, GISELA MENGER Department of Computer Structures University of Ulm 89069 Ulm, Germany {axel, markev, keedy, gisela@informatik.uni-ulm.de

More information

The Unified Modeling Language. Asst.Prof.Dr. Supakit Nootyaskool IT-KMITL

The Unified Modeling Language. Asst.Prof.Dr. Supakit Nootyaskool IT-KMITL The Unified Modeling Language Asst.Prof.Dr. Supakit Nootyaskool IT-KMITL UML: requirement VS. Design models Identify 2 All the classes or things Elementary business process Necessary step to carry out

More information

Agile Model-Driven Development with UML 2.0 SCOTT W. AM BLER. Foreword by Randy Miller UNIFIED 1420 MODELING LANGUAGE. gile 1.

Agile Model-Driven Development with UML 2.0 SCOTT W. AM BLER. Foreword by Randy Miller UNIFIED 1420 MODELING LANGUAGE. gile 1. THE OBJECT PRIMER THIRD EDITION Agile Model-Driven Development with UML 2.0 SCOTT W. AM BLER Foreword by Randy Miller UNIFIED 1420 MODELING LANGUAGE gile 1 odeling Contents Acknowledgments Foreword Preface

More information

An Expert System for Design Patterns Recognition

An Expert System for Design Patterns Recognition IJCSNS International Journal of Computer Science and Network Security, VOL.17 No.1, January 2017 93 An Expert System for Design Patterns Recognition Omar AlSheikSalem 1 and Hazem Qattous 2 1 Department

More information

Chapter 10 Object-Oriented Design Principles

Chapter 10 Object-Oriented Design Principles Chapter 10 Object-Oriented Design Principles Dr. Supakit Nootyaskool Faculty of Information Technology King Mongkut s Institute of Technology Ladkrabang Outline Object-oriented design: bridging from analysis

More information