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

Object-Oriented Design

Object-Oriented Design Object-Oriented Design Lecturer: Raman Ramsin Lecture 15: Object-Oriented Principles 1 Open Closed Principle (OCP) Classes should be open for extension but closed for modification. OCP states that we should

More information

GRASP Design Patterns A.A. 2018/2019

GRASP Design Patterns A.A. 2018/2019 GRASP Design Patterns A.A. 2018/2019 Objectives Introducing design patterns Introduzione ai design pattern Designing objects and responsibilities GRASP design patterns A long corridor A passage room Does

More information

17. GRASP: Designing Objects with Responsibilities

17. GRASP: Designing Objects with Responsibilities 17. GRASP: Designing Objects with Responsibilities Objectives Learn to apply five of the GRASP principles or patterns for OOD. Dr. Ziad Kobti School of Computer Science University of Windsor Understanding

More information

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

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

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

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

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

GRASP: Patterns for. chapter18

GRASP: Patterns for. chapter18 GRASP: Patterns for assigning responsibility chapter18 1 Chapter Objectives Learn about design patterns Learn how to apply five GRASP patterns 2 Building Collaboration diagrams System Design: how the system

More information

ADVANCED SOFTWARE DESIGN LECTURE 4 GRASP. Dave Clarke

ADVANCED SOFTWARE DESIGN LECTURE 4 GRASP. Dave Clarke ADVANCED SOFTWARE DESIGN LECTURE 4 GRASP Dave Clarke TODAY S LECTURE We will discuss and apply the GRASP design patterns. These provide principles for evaluating and improving designs. friends User Name??

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

Software Engineering

Software Engineering Software Engineering CSC 331/631 - Spring 2018 Object-Oriented Design Principles Paul Pauca April 10 Design Principles DP1. Identify aspects of the application that vary and separate them from what stays

More information

Summary of the course lectures

Summary of the course lectures Summary of the course lectures 1 Components and Interfaces Components: Compile-time: Packages, Classes, Methods, Run-time: Objects, Invocations, Interfaces: What the client needs to know: Syntactic and

More information

Tecniche di Progettazione: Design Patterns

Tecniche di Progettazione: Design Patterns Tecniche di Progettazione: Design Patterns Design principles 1 Plan of the lecture Your state of the art SOLID Grasp (to be continued next week) 2 Short summary of what you must know Few things on design

More information

Eliminate enterprise software design instability - protect variations! Nickolay Kofanov

Eliminate enterprise software design instability - protect variations! Nickolay Kofanov Eliminate enterprise software design instability - protect variations! Nickolay Kofanov Owning a hammer doesn't make one an architect. Responsibility-Driven-Design The way of thinking about the design

More information

From Design Patterns: Elements of Reusable Object Oriented Software. Read the sections corresponding to patterns covered in the following slides.

From Design Patterns: Elements of Reusable Object Oriented Software. Read the sections corresponding to patterns covered in the following slides. From Design Patterns: Elements of Reusable Object Oriented Software Read the sections corresponding to patterns covered in the following slides. DESIGN PRINCIPLES Modularity Cohesion Coupling Separation

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

Assigning Responsibilities (Patterns of Responsibility Assignment Principles: GRASP)

Assigning Responsibilities (Patterns of Responsibility Assignment Principles: GRASP) Subsystem design basics Assigning Responsibilities (Patterns of Responsibility Assignment Principles: GRASP) Dept. of Computer Science Baylor University Focus on modeling how subsystems accomplish goals

More information

Principles of Software Construction: Objects, Design, and Concurrency. Assigning Responsibilities to Objects. toad. Jonathan Aldrich Charlie Garrod

Principles of Software Construction: Objects, Design, and Concurrency. Assigning Responsibilities to Objects. toad. Jonathan Aldrich Charlie Garrod Principles of Software Construction: Objects, Design, and Concurrency Assigning Responsibilities to Objects toad Fall 2014 Jonathan Aldrich Charlie Garrod School of Computer Science Key concepts from Thursday

More information

GRASP 2. CSC 440: Software Engineering Slide #1

GRASP 2. CSC 440: Software Engineering Slide #1 GRASP 2 CSC 440: Software Engineering Slide #1 GRASP Patterns General Responsibility Assignment Software Patterns Describe fundamental principles of object design and responsibility assignment. Five GRASP

More information

References: Applying UML and patterns Craig Larman

References: Applying UML and patterns Craig Larman References: Applying UML and patterns Craig Larman 1 2 What are patterns? Principles and solutions codified in a structured format describing a problem and a solution A named problem/solution pair that

More information

Four More GRASP Principles CSSE 574: Session 5, Part 2

Four More GRASP Principles CSSE 574: Session 5, Part 2 Four More GRASP Principles CSSE 574: Session 5, Part 2 Steve Chenoweth Phone: Office (812) 877-8974 Cell (937) 657-3885 Email: chenowet@rose-hulman.edu GRASP II And Furthermore Polymorphism Indirection

More information

Index. Index. More information. block statements 66 y 107 Boolean 107 break 55, 68 built-in types 107

Index. Index. More information. block statements 66 y 107 Boolean 107 break 55, 68 built-in types 107 A abbreviations 17 abstract class 105 abstract data types 105 abstract method 105 abstract types 105 abstraction 92, 105 access level 37 package 114 private 115 protected 115 public 115 accessors 24, 105

More information

2009 Shawn A. Bohner. Shawn Bohner Office: Moench Room F212 Phone: (812)

2009 Shawn A. Bohner. Shawn Bohner Office: Moench Room F212 Phone: (812) 2009 Shawn A. Bohner Shawn Bohner Office: Moench Room F212 Phone: (812) 877-8685 Email: bohner@rose-hulman.edu GRASP II And Furthermore Polymorphism Indirection Pure Fabrication Protected Variations 2

More information

CHAPTER 5: PRINCIPLES OF DETAILED DESIGN

CHAPTER 5: PRINCIPLES OF DETAILED DESIGN CHAPTER 5: PRINCIPLES OF DETAILED DESIGN SESSION II: STRUCTURAL AND BEHAVIORAL DESIGN OF COMPONENTS Software Engineering Design: Theory and Practice by Carlos E. Otero Slides copyright 2012 by Carlos E.

More information

GRASP ing at the First 5 Patterns Principles CSSE 574: Session 3, Part 4

GRASP ing at the First 5 Patterns Principles CSSE 574: Session 3, Part 4 GRASP ing at the First 5 Patterns Principles CSSE 574: Session 3, Part 4 Steve Chenoweth Phone: Office (812) 877-8974 Cell (937) 657-3885 Email: chenowet@rose-hulman.edu GRASP General Responsibility Assignment

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

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

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

OODP OOAD Session 7a

OODP OOAD Session 7a OODP OOAD Session 7a Session times PT group 1 Monday 18:00 21:00 room: Malet 403 PT group 2 Thursday 18:00 21:00 room: Malet 407 FT Tuesday 13:30 17:00 room: Malet 404 Email: oded@dcs.bbk.ac.uk Web Page:

More information

be used for more than one use case (for instance, for use cases Create User and Delete User, one can have one UserController, instead of two separate

be used for more than one use case (for instance, for use cases Create User and Delete User, one can have one UserController, instead of two separate UNIT 4 GRASP GRASP: Designing objects with responsibilities Creator Information expert Low Coupling Controller High Cohesion Designing for visibility - Applying GoF design patterns adapter, singleton,

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

COURSE 2 DESIGN PATTERNS

COURSE 2 DESIGN PATTERNS COURSE 2 DESIGN PATTERNS CONTENT Fundamental principles of OOP Encapsulation Inheritance Abstractisation Polymorphism [Exception Handling] Fundamental Patterns Inheritance Delegation Interface Abstract

More information

Responsibilities. Using several specific design principles to guide OO design decisions.

Responsibilities. Using several specific design principles to guide OO design decisions. Designing Objects with Responsibilities Using several specific design principles to guide OO design decisions. Challenge Old-school advice on OOD After identifying i your requirements and creating a domain

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

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

Final Exam. Final Exam Review. Ch 1: Introduction: Object-oriented analysis, design, implementation. Exam Format

Final Exam. Final Exam Review. Ch 1: Introduction: Object-oriented analysis, design, implementation. Exam Format Final Exam Final Exam Review CS 4354 Fall 2012 Jill Seaman Friday, December 14, 11AM Closed book, closed notes, clean desk Content: Textbook: Chapters 1, 2, 4-10 Java Lectures, GRASP + JUnit 35% of your

More information

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

Software Engineering CSC40232: SOFTWARE ENGINEERING. Guest Lecturer: Jin Guo SOLID Principles sarec.nd.edu/courses/se2017 CSC40232: SOFTWARE ENGINEERING Guest Lecturer: Jin Guo SOLID Principles sarec.nd.edu/courses/se2017 Department of Computer Science and Engineering http://www.kirkk.com/modularity/2009/12/solid-principles-of-class-design/

More information

Software Engineering

Software Engineering Software Engineering 5. Software Design und Design Prinzipien Jonathan Brachthäuser Software Engineering Einordnung Problem Continuous Delivery & Feedback Lösung Anforderungsermittlung - (Nicht- )funktionale

More information

OODP Session 5a. Web Page: Visiting Hours: Tuesday 17:00 to 19:00

OODP Session 5a.   Web Page:  Visiting Hours: Tuesday 17:00 to 19:00 OODP Session 5a Next week: Reading week Session times PT group 1 Monday 18:00 21:00 room: Malet 403 PT group 2 Thursday 18:00 21:00 room: Malet 407 FT Tuesday 13:30 17:00 room: Malet 404 Email: oded@dcs.bbk.ac.uk

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

Plan. Design principles: laughing in the face of change. What kind of change? What are we trying to achieve?

Plan. Design principles: laughing in the face of change. What kind of change? What are we trying to achieve? Plan Design principles: laughing in the face of change Perdita Stevens School of Informatics University of Edinburgh What are we trying to achieve? Review: Design principles you know from Inf2C-SE Going

More information

PROCESS DEVELOPMENT METHODOLOGY The development process of an API fits the most fundamental iterative code development

PROCESS DEVELOPMENT METHODOLOGY The development process of an API fits the most fundamental iterative code development INTRODUCING API DESIGN PRINCIPLES IN CS2 Jaime Niño Computer Science, University of New Orleans New Orleans, LA 70148 504-280-7362 jaime@cs.uno.edu ABSTRACT CS2 provides a great opportunity to teach an

More information

GRASP: MORE PATTERNS FOR

GRASP: MORE PATTERNS FOR Chapter 22 GRASP: MORE PATTERNS FOR ASSIGNING RESPONSIBILITIES Luck is the residue of design. Branch Rickey Objectives Learn to apply the remaining GRASP patterns. Introduction Previously, we explored

More information

Plan. Design principles: laughing in the face of change. What kind of change? What are we trying to achieve?

Plan. Design principles: laughing in the face of change. What kind of change? What are we trying to achieve? Plan Design principles: laughing in the face of change Perdita Stevens School of Informatics University of Edinburgh What are we trying to achieve? Review: Design principles you know from Inf2C-SE Going

More information

Assertions. Assertions - Example

Assertions. Assertions - Example References: internet notes; Bertrand Meyer, Object-Oriented Software Construction; 11/13/2003 1 Assertions Statements about input to a routine or state of a class Have two primary roles As documentation,

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

Design patterns. Jef De Smedt Beta VZW

Design patterns. Jef De Smedt Beta VZW Design patterns Jef De Smedt Beta VZW Who Beta VZW www.betavzw.org Association founded in 1993 Computer training for the unemployed Computer training for employees (Cevora/Cefora) 9:00-12:30 13:00-16:00

More information

COMP 6471 Software Design Methodologies

COMP 6471 Software Design Methodologies COMP 647 Software Design Methodologies Fall 20 Dr Greg Butler http://www.cs.concordia.ca/~gregb/home/comp647-fall20.html Course Introduction Course People Course Components What the course is What the

More information

Assigning Responsibilities by Larman

Assigning Responsibilities by Larman Assigning Responsibilities by Larman Core design activity: The identification of objects and responsibilities and providing a solution in terms of an interaction diagram this is the creative part where

More information

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

a correct statement? You need to know what the statement is supposed to do. Using assertions for correctness How can we know that software is correct? It is only correct if it does what it is supposed to do. But how do we know what it is supposed to do? We need a specification.

More information

Appendix A - Glossary(of OO software term s)

Appendix A - Glossary(of OO software term s) Appendix A - Glossary(of OO software term s) Abstract Class A class that does not supply an implementation for its entire interface, and so consequently, cannot be instantiated. ActiveX Microsoft s component

More information

OO Design Principles

OO Design Principles OO Design Principles Software Architecture VO (706.706) Roman Kern Institute for Interactive Systems and Data Science, TU Graz 2018-10-10 Roman Kern (ISDS, TU Graz) OO Design Principles 2018-10-10 1 /

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

Object-Oriented Concepts and Design Principles

Object-Oriented Concepts and Design Principles Object-Oriented Concepts and Design Principles Signature Specifying an object operation or method involves declaring its name, the objects it takes as parameters and its return value. Known as an operation

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

COMP 6471 Software Design Methodologies

COMP 6471 Software Design Methodologies COMP 6471 Software Design Methodologies Fall 2011 Dr Greg Butler http://www.cs.concordia.ca/~gregb/home/comp6471-fall2011.html Page 2 Sample UP Artifact Relationships Domain Model Context Business Modeling

More information

Agile Software Development

Agile Software Development Agile Software Development Principles, Patterns, and Practices Robert Cecil Martin Alan Apt Series Prentice Hall Pearson Education, Inc. Upper Saddle River, New Jersey 07458 Foreword Preface About the

More information

CMPS 115 Winter 04. Class #10 (2004/02/05) Changes/Review Programming Paradigms Principles of OOD <break> Design Patterns

CMPS 115 Winter 04. Class #10 (2004/02/05) Changes/Review Programming Paradigms Principles of OOD <break> Design Patterns CMPS 115 Winter 04 Class #10 (2004/02/05) Changes/Review Programming Paradigms Principles of OOD Design Patterns Changes & Lecture 9 Takeaway Changes/Notices 2/26 may be guest after all, on design-with-frameworks

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

BCS Higher Education Qualifications. Diploma in IT. Object Oriented Programming Syllabus

BCS Higher Education Qualifications. Diploma in IT. Object Oriented Programming Syllabus BCS Higher Education Qualifications Diploma in IT Object Oriented Programming Syllabus Version 3.0 December 2016 This is a United Kingdom government regulated qualification which is administered and approved

More information

MSO Lecture Design by Contract"

MSO Lecture Design by Contract 1 MSO Lecture Design by Contract" Wouter Swierstra (adapted by HP, AL) October 8, 2018 2 MSO SO FAR Recap Abstract Classes UP & Requirements Analysis & UML OO & GRASP principles Design Patterns (Facade,

More information

Lecture 17: Patterns Potpourri. Copyright W. Howden 1

Lecture 17: Patterns Potpourri. Copyright W. Howden 1 Lecture 17: Patterns Potpourri Copyright W. Howden 1 GOF Patterns GOF: Gamma, Helm, Johnson, Vlissides Design Patterns, Addison Wesley, 1995 Patterns we have seen so far Creational Patterns e.g. Factory,

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

09. Component-Level Design

09. Component-Level Design 09. Component-Level Design Division of Computer Science, College of Computing Hanyang University ERICA Campus 1 st Semester 2017 What is Component OMG UML Specification defines a component as OO view a

More information

The following topics will be covered in this course (not necessarily in this order).

The following topics will be covered in this course (not necessarily in this order). The following topics will be covered in this course (not necessarily in this order). Introduction The course focuses on systematic design of larger object-oriented programs. We will introduce the appropriate

More information

CSE 70 Final Exam Fall 2009

CSE 70 Final Exam Fall 2009 Signature cs70f Name Student ID CSE 70 Final Exam Fall 2009 Page 1 (10 points) Page 2 (16 points) Page 3 (22 points) Page 4 (13 points) Page 5 (15 points) Page 6 (20 points) Page 7 (9 points) Page 8 (15

More information

EINDHOVEN UNIVERSITY OF TECHNOLOGY

EINDHOVEN UNIVERSITY OF TECHNOLOGY EINDHOVEN UNIVERSITY OF TECHNOLOGY Department of Mathematics & Computer Science Exam Programming Methods, 2IP15, Wednesday 17 April 2013, 09:00 12:00 TU/e THIS IS THE EXAMINER S COPY WITH (POSSIBLY INCOMPLETE)

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

CSCD01 Engineering Large Software Systems. Design Patterns. Joe Bettridge. Winter With thanks to Anya Tafliovich

CSCD01 Engineering Large Software Systems. Design Patterns. Joe Bettridge. Winter With thanks to Anya Tafliovich CSCD01 Engineering Large Software Systems Design Patterns Joe Bettridge Winter 2018 With thanks to Anya Tafliovich Design Patterns Design patterns take the problems consistently found in software, and

More information

Avancier Methods. Very basic design patterns. It is illegal to copy, share or show this document

Avancier Methods. Very basic design patterns. It is illegal to copy, share or show this document Methods Very basic design patterns It is illegal to copy, share or show this document (or other document published at http://avancier.co.uk) without the written permission of the copyright holder Copyright

More information

Introduction to Software Engineering (2+1 SWS) Winter Term 2009 / 2010 Dr. Michael Eichberg Vertretungsprofessur Software Engineering Department of

Introduction to Software Engineering (2+1 SWS) Winter Term 2009 / 2010 Dr. Michael Eichberg Vertretungsprofessur Software Engineering Department of Introduction to Software Engineering (2+1 SWS) Winter Term 2009 / 2010 Dr. Michael Eichberg Vertretungsprofessur Software Engineering Department of Computer Science Technische Universität Darmstadt Dr.

More information

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

References: internet notes; Bertrand Meyer, Object-Oriented Software Construction; 10/14/2004 1 References: internet notes; Bertrand Meyer, Object-Oriented Software Construction; 10/14/2004 1 Assertions Statements about input to a routine or state of a class Have two primary roles As documentation,

More information

OO Class Design Principles

OO Class Design Principles 3.3 Class Design Principles Single Responsibility Principle (SRP) Open/Closed Principle (OCP) Liskov Substitution Principle (LSP) a.k.a. Design by Contract Dependency Inversion Principle (DIP) Interface

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

Design Pattern- Creational pattern 2015

Design Pattern- Creational pattern 2015 Creational Patterns Abstracts instantiation process Makes system independent of how its objects are created composed represented Encapsulates knowledge about which concrete classes the system uses Hides

More information

Design Principles: Part 2

Design Principles: Part 2 Liskov Substitution Principle (LSP) Dependency-Inversion Principle (DIP) Interface-Segregation Principle (ISP) Design Principles: Part 2 ENGI 5895: Software Design Andrew Vardy Faculty of Engineering &

More information

Today's Agenda. References. Open Closed Principle. CS 247: Software Engineering Principles. Object-Oriented Design Principles

Today's Agenda. References. Open Closed Principle. CS 247: Software Engineering Principles. Object-Oriented Design Principles CS 247: Software Engineering Principles Reading: none Object-Oriented Design Principles Today's Agenda Object-Oriented Design Principles - characteristics, properties, and advice for making decisions that

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

Software Design and Analysis CSCI 2040

Software Design and Analysis CSCI 2040 Software Design and Analysis CSCI 2040 Summarize UML Deployment and Component notation. Design a framework with the Template Method, State, and Command patterns. Introduce issues in object-relational (O-R)

More information

Software Design Patterns. Background 1. Background 2. Jonathan I. Maletic, Ph.D.

Software Design Patterns. Background 1. Background 2. Jonathan I. Maletic, Ph.D. Software Design Patterns Jonathan I. Maletic, Ph.D. Department of Computer Science Kent State University J. Maletic 1 Background 1 Search for recurring successful designs emergent designs from practice

More information

Review Software Engineering October, 7, Adrian Iftene

Review Software Engineering October, 7, Adrian Iftene Review Software Engineering October, 7, 2013 Adrian Iftene adiftene@info.uaic.ro Software engineering Basics Definition Development models Development activities Requirement analysis Modeling (UML Diagrams)

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

Object- Oriented Design with UML and Java Part I: Fundamentals

Object- Oriented Design with UML and Java Part I: Fundamentals Object- Oriented Design with UML and Java Part I: Fundamentals University of Colorado 1999-2002 CSCI-4448 - Object-Oriented Programming and Design These notes as free PDF files: http://www.softwarefederation.com/cs4448.html

More information

18.1 Definitions and General OO Principles

18.1 Definitions and General OO Principles Chapter 18: Design Patterns Design patterns are elegant, adaptable, and reusable solutions to everyday software development problems. Each pattern includes a description of a commonly occuring type of

More information

Design Principles: Part 2

Design Principles: Part 2 Liskov Substitution Principle (LSP) Dependency-Inversion Principle (DIP) Interface-Segregation Principle (ISP) Design Principles: Part 2 ENGI 5895: Software Design Andrew Vardy Faculty of Engineering &

More information

VEL TECH HIGH TECH Dr. RANGARAJAN Dr. SAKUNTHALA ENGINEERING COLLEGE UNIT 1 UML DIAGRAMS

VEL TECH HIGH TECH Dr. RANGARAJAN Dr. SAKUNTHALA ENGINEERING COLLEGE UNIT 1 UML DIAGRAMS UNIT 1 UML DIAGRAMS Introduction to OOAD Unified Process - UML diagrams Use Case Class Diagrams Interaction Diagrams State Diagrams Activity Diagrams Package, component and Deployment Diagrams. INTRODUCTION

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

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

Introduction to Software Engineering (2+1 SWS) Winter Term 2009 / 2010 Dr. Michael Eichberg Vertretungsprofessur Software Engineering Department of

Introduction to Software Engineering (2+1 SWS) Winter Term 2009 / 2010 Dr. Michael Eichberg Vertretungsprofessur Software Engineering Department of Introduction to Software Engineering (2+1 SWS) Winter Term 2009 / 2010 Dr. Michael Eichberg Vertretungsprofessur Software Engineering Department of Computer Science Technische Universität Darmstadt What

More information

Object Relationships

Object Relationships Object Relationships Objects can work together in three different types of relationships: Uses: An object can use another to do some work (association). Composition: A complex object may be composed of

More information

Design Patterns V Structural Design Patterns, 2

Design Patterns V Structural Design Patterns, 2 Structural Design Patterns, 2 COMP2110/2510 Software Design Software Design for SE September 17, 2008 Department of Computer Science The Australian National University 19.1 1 2 Formal 3 Formal 4 Formal

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

Welcome to Design Patterns! For syllabus, course specifics, assignments, etc., please see Canvas

Welcome to Design Patterns! For syllabus, course specifics, assignments, etc., please see Canvas Welcome to Design Patterns! For syllabus, course specifics, assignments, etc., please see Canvas What is this class about? While this class is called Design Patterns, there are many other items of critical

More information

Design by Contract in Eiffel

Design by Contract in Eiffel Design by Contract in Eiffel 2002/04/15 ctchen@canthink.com.com.tw.tw Reference & Resource Bertrand Meyer, Object-Oriented Oriented Software Construction 2nd,, 1997, PH. Bertrand Meyer, Eiffel: The Language,,

More information

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

Why Design by Contract! CS 619 Introduction to OO Design and Development. Design by Contract. Fall 2012 Why Design by Contract What s the difference with Testing? CS 619 Introduction to OO Design and Development Design by Contract Fall 2012 Testing tries to diagnose (and cure) defects after the facts. Design

More information

Applying Design Patterns to accelerate development of reusable, configurable and portable UVCs. Accellera Systems Initiative 1

Applying Design Patterns to accelerate development of reusable, configurable and portable UVCs. Accellera Systems Initiative 1 Applying Design Patterns to accelerate development of reusable, configurable and portable UVCs. Accellera Systems Initiative 1 About the presenter Paul Kaunds Paul Kaunds is a Verification Consultant at

More information