GRASP Design Patterns A.A. 2018/2019

Size: px
Start display at page:

Download "GRASP Design Patterns A.A. 2018/2019"

Transcription

1 GRASP Design Patterns A.A. 2018/2019

2 Objectives Introducing design patterns Introduzione ai design pattern Designing objects and responsibilities GRASP design patterns

3 A long corridor

4 A passage room Does this room seem cozy? Would you like to stay there? Why? Light Proportions Symmetry Furnitures...

5 Example In the bedroom it might be helpful to have a armchair, perhaps near the window for reading. When spaces are more regular, the solution is to put the armchair in the corner. If the window is far, you need to provide a lamp.

6 An interior design pattern Descripting schema of a design pattern Context: genera situation in which we are carrying on a design project Problem: set of forces that are active in the context Solution: rule to apply in order to solve such forces Example: light point Forces We would like to sit up and be comfortable in a room We will be attracted by the light Solutions In the living room at least a window must be the light point If an armchair is far from a light point we must create one

7 Design patterns in architecture Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice (Christopher Alexander) A pattern is a recurrent solution to a certain known design problem, which occurs in a certain context Do you think patterns are relevant for software?

8 Benefits of Patterns Shared language of design Increases communication bandwidth Decreases misunderstandings Learn from experience Becoming a good designer is hard Understanding good designs is a first step Tested solutions to common problems Where is the solution applicable? What are the tradeoffs?

9 Design patterns in software A pattern describes a problem that occurs frequently, along with a recommended and well accepted solution to the problem Each pattern in software describes the relations among classes or objects needed to solve the design problem in a specific context Example: adapter, a pattern that enables the interaction among objects with are incompatibles

10 Example: Adapter Participants Adaptee: it defines the interface that requires to be adapted Target: it defines the interface we want to use Adapter: it adapts the interface Adaptee to the interface Target.

11 Antipatterns An antipattern is a common response to a recurring problem that is usually ineffective and risks being highly counterproductive. Example: interface bloat, when a interface incorporates too many operations on some data into an interface, only to find that most of the objects cannot perform the given operations.

12 Interface bloat

13 GRASP General Responsibility Assignment Software Patterns (or Principles), abbreviated GRASP, consist of guidelines for assigning responsibility to classes and objects in objectoriented design. Computer scientist Craig Larman states that "the critical design tool for software development is a mind well educated in design principles. It is not UML or any other technology." Thus, GRASP are really a mental toolset, a learning aid to help in the design of objectoriented software.

14 List of GRASP patterns Information Expert Creator Low Coupling High Cohesion Controller Polymorphism Pure Fabrication Indirection Protected variations (Law of Demeter)

15 Pattern Information expert Information expert (also expert or the expert principle) is a principle used to determine where to delegate responsibilities. These responsibilities include methods, computed fields, and so on. Using the principle of information expert, a general approach to assigning responsibilities is to look at a given responsibility, determine the information needed to fulfill it, and then determine where that information is stored. Information expert will lead to placing the responsibility on the class with the most information required to fulfill it.

16 Information expert as problem/solution Problem: What is the principle to follow for assigning a responsibility to a class? Solution: The responsibility must be assigned to the class that owns the information required to get the responsibility

17 Information expert example Which class should compute the total sum of a receipt provided by a POS application?

18 Information expert example (contd.) We need all SalesLineItem instances and subtotals. Sales knows that, hence Sales is the expert class

19 Sale as a CRC cards Class name: Sale Superclass: Subclasses: Class name: SaleLineItem Superclass: Subclasses: Responsibilities Collaborations Responsibilities Collaborations Knows the total amount of a sale SaleLineItem Knows the subtotal amount of a sale ProductDescription Class name: ProductDescription Responsibilities Knows the price of a product Superclass: Subclasses: Collaborations

20 Information Expert: pros and cons Pros: Preserve encapsulation hide the values or state of a structured data object inside a class, preventing unauthorized parties' direct access to them Foster decoupling and cohesion coupling is the degree of interdependence between software modules. Coupling is usually contrasted with cohesion. Low coupling often correlates with high cohesion, and vice versa. Low coupling is often a sign of a wellstructured computer system and a good design, and when combined with high cohesion, supports the general goals of high readability and maintainability cohesion refers to the degree to which the elements inside a module belong together. In one sense, it is a measure of the strength of relationship between the methods and data of a class and some unifying purpose or concept served by that class. In another sense, it is a measure of the strength of relationship between the class s methods and data themselves. Cons: it might introduce unnecessary complexity

21 Pattern Creator Creation of objects is one of the most common activities in an objectoriented system. Which class is responsible for creating objects is a fundamental property of the relationship between objects of particular classes.

22 Creator as problem/solution Problem: What is responsible for creating a class? Solution: B should be responsible for creating instances of class A if one, or preferably more, of the following apply: Instances of B contain or compositely aggregate instances of A Instances of B record instances of A Instances of B closely use instances of A Instances of B have the initializing information for instances of A and pass it on creation

23 Creator example Who creates squares?

24 Creator example (contd.)

25 Creator discussion Creating objects is a very common responsibility An object becomes a creator when one or more of the following situations hold. The object aggregates multiple parts The object is a container of contents The object is a recorder The object is able to communicate creation data

26 Creator: contraindications It might complicate the project Performance might decrease Inappropriate for creating instances of a family of similar classes conditionally

27 Pattern LowCoupling Coupling is a measure of how strongly one element is connected to, has knowledge of, or relies on other elements. Low coupling is an evaluative pattern that dictates how to assign responsibilities to support lower dependency between the classes change in one class having lower impact on other classes higher reuse potential.

28 Lowcoupling as problem/solution Problem: How to reduce modification by fostering reuse? Solution: Assigning responsibilities so that the degree of coupling is kept low

29 This scenario violates lowcoupling

30 LowCoupling: pros and cons Pros: Comprehensibility: classes can be understood more easily Maintainability: classes are not affected by changes to other components Reusability: classes can be reused in different systems more easily Cons: it is better to keep already tested and stable classes coupled (e.g. software libraries, legacy systems)

31 Controller: problem Who is responsible for handling events coming from an external UI?

32 Controller: solution The responsibility of handling the events generated by an external UI can be assigned to: A single representative of the system (i.e. a façade) A session controller for each use case an object representing the coordinator should be identified

33 Pattern Controller A controller object is a nonuser interface (UI) object responsible for receiving or handling a system event. The controller is defined as the first object beyond the UI layer that receives and coordinates ("controls") a system operation. The controller should delegate the work that needs to be done to other objects; it coordinates or controls the activity. It should not do much work itself.

34 Controller: example In a use case scenario named Buy Items the following events should be managed: enteritem() endsale() makepayment() Who is responsible for the event enteritem()?

35 Controller: example (contd.)

36 Bloated Controllers Controller class is called bloated, if The class is overloaded with too many responsibilities. Solution: add more controllers The Controller class is performing many tasks instead of delegating to other class. Solution controller class has to delegate things to others

37 Who is the controller?

38 High cohesion: problem Cohesion is the measure of the correlation among the responsibility assigned to a class How to design classes with a high cohesion degree?

39 High cohesion: solution How are the operations of any element are functionally related? Related responsibilities in to one manageable unit Prefer high cohesion Clearly defines the purpose of the element Benefits Easily understandable and maintainable Code reuse Low coupling

40 High cohesion pattern High cohesion is an evaluative pattern that attempts to keep objects appropriately focused, manageable and understandable. High cohesion is generally used in support of low coupling. High cohesion means that the responsibilities of a given element are strongly related and highly focused. Breaking programs into classes and subsystems is an example of activities that increase the cohesive properties of a system. Alternatively, low cohesion is a situation in which a given element has too many unrelated responsibilities. Elements with low cohesion often suffer from being hard to comprehend, hard to reuse, hard to maintain and averse to change.

41 Is this object associated with high cohesion?

42 Is this object associated with high cohesion? Canonical example of low cohesion NO! Can we design it better?

43 High cohesion: example

44 High cohesion: pros and cons Pros: Comprehensibility and reusability Complementary with low coupling as it suggests designers to avoid putting a large number of unrelated responsibilities within a single class Maintainability Cons: Sometimes it might be desirable to have a single object (e.g. a server) with lower cohesion. In this case the objective is to design such an object as a interface for many operations in order to boost efficiently, i.e. to many communications among objects can decrease performance.

45 Polymorphism: problem How to handle related but varying elements based on element type? Example: Modelling geometric different shapes that a UI might present

46 Polymorphism: solution When alternatives behaviours change with type (i.e. class) the responsibilities are assigned to those types that alternatives or behaviours change for. This mechanism is enabled by polymorphic operations

47 Polymorphism: example

48 Pure Fabrication: problem In case we use Information Expert and high cohesion and/or low coupling are violated is there any way for assigning responsibilities?

49 Pure Fabrication: solution We introduce an artificial class for convenience, which is highly cohesive and lowly coupled

50 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. Behavioral decomposed implements some algorithm. Benefits: High cohesion, low coupling and reuse

51 Pure Fabrication: example Suppose we have a Shape class and 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

52 Pure fabrication: example Participants Adaptee: it defines the interface that requires to be adapted Target: it defines the interface we want to use Adapter: it adapts the interface Adaptee to the interface Target.

53 Indirection: problem How can we avoid a direct coupling between two or more elements.

54 Indirection: solution Indirection introduces an intermediate unit to communicate between the other units, so that the other units are not directly coupled. Benefits: low coupling

55 Indirection: bad example Any possible improvement?

56 Indirection: good example

57 Protected Variations: problem How to avoid impact of variations of some elements on the other elements?

58 Protected Variations: solution It provides a well defined interface so that the there will be no side effect on other units. It provides flexibility and protection from variations. It provides more structured design. Note: it is a generalisation of the Law of Demeter

59 Law of Demeter The Law of Demeter (LoD) or principle of least knowledge is a design guideline for developing software, particularly objectoriented programs. Each unit should have only limited knowledge about other units: only units "closely" related to the current unit. Each unit should only talk to its friends; don't talk to strangers. Only talk to your immediate friends.

60 Characteristics of a good pattern Provides a solution to a problem Describes a relation The solution is not trivial Both problem and solution are well known and accepted by the community Useful and elegant Follows general design principles

61 SOLID principles Single responsibility principle a class should have only a single responsibility (high cohesion) Open/closed principle software entities should be open for extension, but closed for modification. Liskov substitution principle objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program. Interface segregation principle many clientspecific interfaces are better than one generalpurpose interface. Dependency inversion principle one should depend upon abstractions, not concretions.

62 Questions

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

Object-Oriented Design Object-Oriented Design Department of Computer Engineering Lecture 12: Object-Oriented Principles Sharif University of Technology 1 Open Closed Principle (OCP) Classes should be open for extension but closed

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

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

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 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

CSC207H: Software Design SOLID. CSC207 Winter 2018

CSC207H: Software Design SOLID. CSC207 Winter 2018 SOLID CSC207 Winter 2018 1 SOLID Principles of Object-Oriented Design How do we make decisions about what is better and what is worse design? Principles to aim for instead of rules. e.g. there is no maximum

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

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

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

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

Software Design and Analysis CSCI 2040

Software Design and Analysis CSCI 2040 Software Design and Analysis CSCI 2040 Introduce a logical architecture using layers Illustrate the logical architecture with UML Package Diagrams 2 Where the class Register should be? 4 Where class Register

More information

On to Object-oriented Design

On to Object-oriented Design Dr. Michael Eichberg Software Technology Group Department of Computer Science Technische Universität Darmstadt Introduction to Software Engineering On to Object-oriented Design Object-oriented Design 2

More information

Intro to: Design Principles

Intro to: Design Principles Intro to: Design Principles Pragmatic Programmer: Eliminate Effects Between Unrelated Things design components that are: self-contained, independent, and have a single, well-defined purpose Software Design

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

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

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

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

CS 520 Theory and Practice of Software Engineering Fall 2018

CS 520 Theory and Practice of Software Engineering Fall 2018 Today CS 520 Theory and Practice of Software Engineering Fall 2018 Object Oriented (OO) Design Principles September 13, 2018 Code review and (re)design of an MVC application (and encapsulation) Polymorphism

More information

Design Patterns. Gunnar Gotshalks A4-1

Design Patterns. Gunnar Gotshalks A4-1 Design Patterns A4-1 On Design Patterns A design pattern systematically names, explains and evaluates an important and recurring design problem and its solution Good designers know not to solve every problem

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

CHAPTER 9 DESIGN ENGINEERING. Overview

CHAPTER 9 DESIGN ENGINEERING. Overview CHAPTER 9 DESIGN ENGINEERING Overview A software design is a meaningful engineering representation of some software product that is to be built. Designers must strive to acquire a repertoire of alternative

More information

INTERNAL ASSESSMENT TEST III Answer Schema

INTERNAL ASSESSMENT TEST III Answer Schema INTERNAL ASSESSMENT TEST III Answer Schema Subject& Code: Object-Oriented Modeling and Design (15CS551) Sem: V ISE (A & B) Q. No. Questions Marks 1. a. Ans Explain the steps or iterations involved in object

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

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

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

A Reconnaissance on Design Patterns

A Reconnaissance on Design Patterns A Reconnaissance on Design Patterns M.Chaithanya Varma Student of computer science engineering, Sree Vidhyanikethan Engineering college, Tirupati, India ABSTRACT: In past decade, design patterns have been

More information

An Introduction to Patterns

An Introduction to Patterns An Introduction to Patterns Robert B. France Colorado State University Robert B. France 1 What is a Pattern? - 1 Work on software development patterns stemmed from work on patterns from building architecture

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

Idioms and Design Patterns. Martin Skogevall IDE, Mälardalen University

Idioms and Design Patterns. Martin Skogevall IDE, Mälardalen University Idioms and Design Patterns Martin Skogevall IDE, Mälardalen University 2005-04-07 Acronyms Object Oriented Analysis and Design (OOAD) Object Oriented Programming (OOD Software Design Patterns (SDP) Gang

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

Design Concepts. Slide Set to accompany. Software Engineering: A Practitioner s Approach, 7/e by Roger S. Pressman

Design Concepts. Slide Set to accompany. Software Engineering: A Practitioner s Approach, 7/e by Roger S. Pressman Chapter 8 Design Concepts 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 educational

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

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

Topics in Object-Oriented Design Patterns

Topics in Object-Oriented Design Patterns Software design Topics in Object-Oriented Design Patterns Material mainly from the book Design Patterns by Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides; slides originally by Spiros Mancoridis;

More information

CAS 703 Software Design

CAS 703 Software Design Dr. Ridha Khedri Department of Computing and Software, McMaster University Canada L8S 4L7, Hamilton, Ontario Other 1 2 3 4 Other Principle of Least Privilege Principle of Fail-Safe Defaults Principle of

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

Introduction to Object Oriented Analysis and Design

Introduction to Object Oriented Analysis and Design A class note on Introduction to Object Oriented Analysis and Design Definition In general, analysis emphasizes an investigation of the problem and requirements of the domain, rather than a solution. Whereas,

More information

Chapter 8: Class and Method Design

Chapter 8: Class and Method Design Chapter 8: Class and Method Design Objectives Become familiar with coupling, cohesion, and connascence. Be able to specify, restructure, and optimize object designs. Be able to identify the reuse of predefined

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

Patterns. Giovanni Sakti. in Software Engineering. Starqle

Patterns. Giovanni Sakti. in Software Engineering. Starqle Patterns in Software Engineering Giovanni Sakti Starqle What is Patterns? Patterns Patterns describes a problem, which occurs over and over again in our environment and then desribes the core of the solution

More information

CTIS 359 Principles of Software Engineering SOFTWARE DESIGN OO(A)D

CTIS 359 Principles of Software Engineering SOFTWARE DESIGN OO(A)D CTIS 359 Principles of Software Engineering SOFTWARE DESIGN OO(A)D Today s Objectives To explain the basic concepts of OO(A)D To describe some best practices regarding to OO(A)D What is NOT UML? The UML

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

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

OODP Session 4.   Web Page:   Visiting Hours: Tuesday 17:00 to 19:00 OODP Session 4 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: http://www.dcs.bbk.ac.uk/~oded

More information

CPSC 310 Software Engineering. Lecture 11. Design Patterns

CPSC 310 Software Engineering. Lecture 11. Design Patterns CPSC 310 Software Engineering Lecture 11 Design Patterns Learning Goals Understand what are design patterns, their benefits and their drawbacks For at least the following design patterns: Singleton, Observer,

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

Software Design and SOLID Principles

Software Design and SOLID Principles TCSS 360: SOFTWARE DEVELOPMENT AND QUALITY ASSURANCE OBJECTIVES Software Design and SOLID Principles Wes J. Lloyd Institute of Technology University of Washington - Tacoma SessionMgr read_from_db() store_in_db()

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

Software Engineering Fall 2015 (CSC 4350/6350) TR. 5:30 pm 7:15 pm. Rao Casturi 11/03/2015

Software Engineering Fall 2015 (CSC 4350/6350) TR. 5:30 pm 7:15 pm. Rao Casturi 11/03/2015 Software Engineering Fall 2015 (CSC 4350/6350) TR. 5:30 pm 7:15 pm Rao Casturi 11/03/2015 http://cs.gsu.edu/~ncasturi1 Object Design Software Engineering -CSC4350/6350 - Rao Casturi 2 Object Design Close

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

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

Design Patterns Reid Holmes

Design Patterns Reid Holmes Material and some slide content from: - Head First Design Patterns Book - GoF Design Patterns Book Design Patterns Reid Holmes GoF design patterns $ %!!!! $ "! # & Pattern vocabulary Shared vocabulary

More information

Design. Eric McCreath

Design. Eric McCreath Design Eric McCreath 2 Good Design As you move from Idea to Implementation good design plays a key part in making software robust, maintainable, and flexible. Good design is difficult It is easy to overcomplicate

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

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

Exam Questions. Object-Oriented Design, IV1350. Maximum exam score is 100, grade limits are as follows. Score Grade 90 A 80 B 70 C 60 D 50 E

Exam Questions. Object-Oriented Design, IV1350. Maximum exam score is 100, grade limits are as follows. Score Grade 90 A 80 B 70 C 60 D 50 E Object-Oriented Design, IV1350 Maximum exam score is 100, grade limits are as follows. Score Grade 90 A 80 B 70 C 60 D 50 E The exam questions will be a subset of the questions below. The exam may contain

More information

CS 320 Introduction to Software Engineering Spring March 06, 2017

CS 320 Introduction to Software Engineering Spring March 06, 2017 CS 320 Introduction to Software Engineering Spring 2017 March 06, 2017 Recap: types of Polymorphism Recap: types of Polymorphism Ad-hoc polymorphism (e.g., operator overloading) a + b String vs. int, double,

More information

Keywords: Abstract Factory, Singleton, Factory Method, Prototype, Builder, Composite, Flyweight, Decorator.

Keywords: Abstract Factory, Singleton, Factory Method, Prototype, Builder, Composite, Flyweight, Decorator. Comparative Study In Utilization Of Creational And Structural Design Patterns In Solving Design Problems K.Wseem Abrar M.Tech., Student, Dept. of CSE, Amina Institute of Technology, Shamirpet, Hyderabad

More information

Software Engineering Fall 2014

Software Engineering Fall 2014 Software Engineering Fall 2014 (CSC 4350/6350) Mon.- Wed. 5:30 pm 7:15 pm ALC : 107 Rao Casturi 11/03/2014 Re Cap - Object Design Close the gap between the application objects and the off-the shelf components.

More information

Software Engineering - I An Introduction to Software Construction Techniques for Industrial Strength Software

Software Engineering - I An Introduction to Software Construction Techniques for Industrial Strength Software Software Engineering - I An Introduction to Software Construction Techniques for Industrial Strength Software Chapter 9 Introduction to Design Patterns Copy Rights Virtual University of Pakistan 1 Design

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

Inheritance. EEC 521: Software Engineering. Dealing with Change. Polymorphism. Software Design. Changing requirements Code needs to be flexible

Inheritance. EEC 521: Software Engineering. Dealing with Change. Polymorphism. Software Design. Changing requirements Code needs to be flexible Inheritance EEC 521: Software Engineering Software Design Design Patterns: Decoupling Dependencies 10/15/09 EEC 521: Software Engineering 1 Inheritance is the mechanism by which one class can acquire properties/responsibilities

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

Coordination Patterns

Coordination Patterns Coordination Patterns 1. Coordination Patterns Design Patterns and their relevance for Coordination Oscar Nierstrasz Software Composition Group Institut für Informatik (IAM) Universität Bern oscar@iam.unibe.ch

More information

1 Software Architecture

1 Software Architecture Some buzzwords and acronyms for today Software architecture Design pattern Separation of concerns Single responsibility principle Keep it simple, stupid (KISS) Don t repeat yourself (DRY) Don t talk to

More information

The Strategy Pattern Design Principle: Design Principle: Design Principle:

The Strategy Pattern Design Principle: Design Principle: Design Principle: Strategy Pattern The Strategy Pattern defines a family of algorithms, encapsulates each one, and makes them interchangeable. Strategy lets the algorithm vary independently from clients that use it. Design

More information

DEPARTMENT OF COMPUTER SCIENCE & ENGINEERING CS2353-OBJECT ORIENTED ANALYSIS AND DESIGN. Unit-I. Introduction to OOAD

DEPARTMENT OF COMPUTER SCIENCE & ENGINEERING CS2353-OBJECT ORIENTED ANALYSIS AND DESIGN. Unit-I. Introduction to OOAD DEPARTMENT OF COMPUTER SCIENCE & ENGINEERING CS2353-OBJECT ORIENTED ANALYSIS AND DESIGN 1. What is Object-Oriented Analysis? Unit-I Introduction to OOAD PART-A (UML Notations has to be used wherever necessary)

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

Study About the Relationship Between the Model-View-Controller Pattern and Usability

Study About the Relationship Between the Model-View-Controller Pattern and Usability Study About the Relationship Between the Model-View-Controller Pattern and Usability Author: Diogo Satoru Aihara Advisors: Xavier Ferré Grau Richard Torkar European Master on Software Engineering This

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