GRASP: Patterns for. chapter18

Size: px
Start display at page:

Download "GRASP: Patterns for. chapter18"

Transcription

1 GRASP: Patterns for assigning responsibility chapter18 1

2 Chapter Objectives Learn about design patterns Learn how to apply five GRASP patterns 2

3 Building Collaboration diagrams System Design: how the system will do what we decided it should do We must identify software classes and assign responsibilities. For each operation contract we build a collaboration diagram. We work through the postcondition state changes and design message interactions to satisfy the requirements. In doing so, we assign responsibilities to objects. Poor choices lead to hard to implement, maintain, reuse, or extend system design 3

4 Building Collaboration diagrams, cont Interaction diagrams are one of the most important artifacts created in OOAD. The skillful assignment of responsibilities that occurs while creating collaboration diagrams is very important. The amount of time and effort spent on their generation, and the careful consideration of responsibility assignment, should absorb a significant percentage of the design phase. Codified patterns, principles and idioms can be applied to improve the quality of their design. 4

5 Responsibilities and methods Responsibilities are related to the obligations of an object in terms of its behavior. Two types of responsibilities: 1. Doing responsibilities : Doing something itself (on its attributes). Initiating actions in other objects (by calling functions in them). Controlling and coordinating activities in other objects (receiving data from one object an send them to another object). 2- Knowing responsibilities : Private encapsulated data. Related objects. Things it can derive or calculate. 5

6 Responsibilities and methods, cont Responsibilities are assigned to objects during design. Example: Sale responsibilities 1. Printing itself (doing) 2. Knowing its date Responsibilities related to knowing (who know who) are often detected from conceptual model from the attributes and associations 6

7 Responsibilities and methods, cont responsibility method A responsibility is not the same thing as a method, but methods are implemented to fulfill responsibilities. For example, provide access to a relational database may involve dozens of classes and hundreds of methods, whereas create a Book Entry may involve only one or few methods. Methods either act alone or collaborate with other methods and objects. For example, Sale has a responsibility named print. To fulfill this responsibility, the Sale may collaborate with other objects, such as sending a message to SaleLineItem objects asking them to print themselves. 7

8 Responsibilities and Collaboration Diagrams print () :Sale 1*:[for each] sli:=next() :SaleLineItem 2:print() sli:salelineitem Responsibility of Sale objects is to print themselves Methods asking collaboration with other objects to print themselves 8

9 GRASP Describe fundamental principles of object design and responsibility. Acronym for General Responsibility Assignment Software Patterns GRASP is expressed as patterns. Patterns are problem/solution pairs that guide in assigning responsibilities by giving advice in how to apply it in varying circumstances Pattern Name: Name Solution: Proposed solution of a problem Problem it solves: describes the problem that this pattern solves 9

10 GRASP There are 5 basic GRASP patterns: 1. Expert. 2. Creator. 3. Low coupling. 4. High cohesion. 5. Controller. 10

11 1- The Expert Pattern Problem: What is the most basic principle of assigning responsibilities to objects? Solution: Assign a responsibility to the information expert class i.e. the class that has the information necessary to fulfill the responsibility is given the responsibility. Start by clearly stating the responsibility: Example: In POST, who should be responsible for knowing the grand total of the sale? By expert pattern, we should look for that class that has the information needed to determine the total. 11

12 Expert Example 12

13 Expert Example, cont Step 1: What information is needed to determine the grand total? It is necessary to know about all the SaleLineItems instances composing the Sale and their subtotals. Only Sale object knows the information about SaleLineItems it contains. So by Expert pattern, the Sale object is the information expert and should be one of its responsibilities to compute the sale total. Collaboration diagram so far: 13

14 Expert Example, cont Step 2: To determine the SaleLineItem subtotals, what information is needed? - We need SaleLineItem.quantity and Productspecfication.price. - The SaleLineItem object knows its quantity and its associated Productspecfication (which contains the price). -Thereby by Expert pattern, SaleLineItem object should determine the subtotal as it is the information expert. Collaboration diagram so far: T:=getTotal() :Sale 2: st:=subtotal() sli:salelineitem 1*:[for each] sli:=next() :SaleLineItem 14

15 Expert Example, cont Step 3: Finally, how the SaleLineItem will compute its subtotal? It should know its item price through ProductSpecfication. Thus, the ProductSpecfication object is the information expert of the item price; therefore a message must be sent to it from SaleLineItem object asking for the price. Thus, ProductSpecfication must have a method called price() that returns the item price. 15

16 Expert Example, cont T:=getTotal() From step1 :Sale 2: st:=subtotal() From step2 1*:[for each] sli:=next() :SaleLineItem sli:salelineitem 2.1: p:=price() From step3 :Product Specification 16

17 Expert Example, cont Class Responsibilities Class Responsibility Sale Knows sale total SaleLineItem ProductSpecification Knows line item subtotal Knows product price 17

18 2- The Creator Pattern Problem: Who should be responsible for creating a new instance of some class? The creation of objects is one of the most common activities in OO system. If assigned well, the design can support low coupling, encapsulation and reusability. Solution: 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 has the initializing data that will be passed to A when it is created (thus B is an Expert with respect to creating A). 18

19 2- The Creator Pattern Thus B is called a creator of A objects. If more than option applies, prefer a class B which aggregates or contains class A. Example: In POST, who should be responsible for creating a SaleLineItem instance? By Creator, we should look for the class that aggregates, contains, records, closely uses, or has initializing data for SaleLineItem instances. 19

20 Creator Example From the conceptual model, a Sale contains (aggregates) many SaleLineItem objects. By creator, Sale is a good candidate to have the responsibility of creating SaleLineItem instances. A method called makelineitem is defined in Sale class to create the SaleLineItem objects (1.*). makelineitem(quantity) :Sale A new method is added to the Sale class Sale 1: create(quantity) Date Time :SaleLineItem gettotal() makelineitem() 20 20

21 3-Low Coupling Pattern Coupling: it is a measure of how strongly one element is connected to, has knowledge of, or relies upon other elements. A class with high coupling depends on many other classes (libraries, tools). Problems because of a design with high coupling: Changes in related classes force local changes. Harder to understand in isolation; need to understand other classes. Harder to reuse because it requires additional presence of other classes. 21

22 3Low Coupling Pattern, cont Problem: How to support low dependency, low change impact and increased reuse? Solution: Assign a responsibility so that coupling remains low. Example: In POST, we need to create a Payment instance and associate it with the Sale. Which class should be responsible for this? (creator) Payment POST Sale 22

23 Low coupling example - Since a POST records a Payment, by Creator, a POST should be responsible for creating a Payment instance p. - The POST instance then sends an addpayment message to the Sale, passing the new Payment instance as parameter. makepayment( ) :POST 1: create() p:payment 2: addpayment(p) :Sale - This solution couples POST with the knowledge of Payment class. 23

24 Low coupling example, cont Another alternative is to make Sale class responsible for creating a Payment and associate it with the Sale. makepayment( ) :POST 1: addpayment() :Sale 1.1: create() :Payment In both cases, eventually, Sale has to be coupled with the knowledge of Payment first design has an extra coupling. While second design does not increase coupling. We may face Low coupling vs. Creator tradeoff. 24

25 3- Low Coupling Pattern, cont There is no specific measurement for coupling, but in general, classes that are generic and simple to reuse have low coupling. Coupling will lead to highly interacting classes. There will always be some coupling among objects, otherwise, there would be no collaboration. A subclass is strongly coupled to its superclass. The decision to derive a subclass from superclass must be carefully considered as it produces a strong form of coupling. 25

26 3- Low Coupling Pattern, cont Benefits: Understandability: Classes are easier to understand in isolation Maintainability: Classes aren t affected by changes in other components Reusability: easier to grab hold of classes 26

27 4- High cohesion pattern Cohesion: (functional cohesion)it is a measure of how strongly related and focused the responsibilities of a class are. A class with low cohesion does many unrelated activities or does too much work. A class with high cohesion has highly related responsibilities, and does not do a large amount of work by itself. Problems because of a design with low cohesion: Hard to understand. Hard to reuse. Hard to maintain. 27

28 4- High cohesion pattern, cont Problem: How to keep complexity manageable? Solution: Assign a responsibility so that cohesion remains high. Example: In POST, we need to create a Payment instance and associate it with the Sale. Which class should be responsible for this? Payment POST Sale 28

29 High cohesion example Since a POST records a payment, by Creator, a POST should be responsible for creating a payment instance. makepayment( ) :POST 1: create() p:payment 2: addpayment(p) : Sale This solution gives the responsibility of creating payment with POST who records it (creator). We add more unrelated responsibilities to POST, thus it became incohesive. We can not let POST instance do all the work related to 29it.

30 High cohesion example, cont - Another alternative is to make Sale responsible for (take the job from POST) creating a Payment and associate it with it. makepayment( ) :POST 1: addpayment() :Sale 1.2: create() : Payment This solution supports high cohesion and low coupling more desirable than Creator. 30

31 4- High cohesion pattern, cont Benefits: Understandability: Clarity & ease of comprehension. Maintainability: Maintenance and enhancement is easier. Complements Low Coupling 31

32 5- The Controller Pattern Problem: Who should be responsible for handling an input system event? A system event is a high level system generated by an external actor; it is an external input event (which is found in the SSD). They are associated with system operations. For a cashier (external actor) using an a POST presses the EndSale button, he is generating a system event indicating the sale has ended. A controller is a non-user interface object responsible for handling a system event. A controller defines the method for the system operation. 32

33 5- The Controller Pattern, cont Solution: Assign the responsibility for receiving or handling a system event message to a class representing one of the four following choices: Represents the overall system. (façade controller) Represents the overall organization. (façade controller) Represents something in the real world that is active (the role of a person) that might be involved in the task. (role controller) Represents an artificial handler of all system events of a use case. (usecase controller) use the name <Use case name>handler Each use case has one controller for its operations (1 use case = 1 controller for all system events in the same use case) Note that windows, applets, etc. typically receive events and delegate them to a controller. They are NOT controllers. 33

34 5- The Controller Pattern, cont Example: In POST system, there are several system operations. Who should be the controller for the system events such as enteritem? There are many choices: System endsale() enteritem() makepayment() enteritem() :POST Overall System (façade controller) enteritem() :Store Overall Organization (façade controller) enteritem() :Cashier Active real world something (role controller) enteritem() :BuyItemHandler Artificial handler of all use case operations 34 (use-case controller)

35 5- The Controller Pattern, cont 35

36 5- The Controller Pattern, cont Many different controller can be used for different use cases. A common problem with the controller class is that it has much responsibilities (bloated controller), thus it should give some of the other work to other classes. Whichever you pick: never implement system operations in UI classes. only coordinate other objects responsibilities in the controller. POST endsale() enteritem() makepayment() POST if chosen to be the controller class 36

37 Summary Skillful assignment of responsibilities is extremely important in object-oriented design Patterns are named problem/solution pairs that codify good advice and principles related to assignment of responsibilities GRASP identifies five patterns or principles: Creator, Information Expert, Controller, Low Coupling and High Cohesion 37

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

More information

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

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

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

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

More information

Object-Oriented Design

Object-Oriented Design Object-Oriented Design 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

Patterns and Testing

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

More information

Object-Oriented Design

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

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

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

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

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

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

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

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

Software Modeling & Analysis

Software Modeling & Analysis Software Modeling & Analysis OOPT (Object Oriented Process with Trace) Lecturer: JUNBEOM YOO jbyoo@konkuk.ac.kr What is OOPT? OOPT (Object Oriented Process with Trace) A software process based on RUP Revision

More information

CS6502- OBJECT ORIENTED ANALYSIS AND DESIGN UNIT I

CS6502- OBJECT ORIENTED ANALYSIS AND DESIGN UNIT I CS6502- OBJECT ORIENTED ANALYSIS AND DESIGN UNIT I Introduction to OOAD Unified Process - UML diagrams Use Case Class Diagrams Interaction Diagrams State Diagrams Activity Diagrams Package, component and

More information

Mapping Designs to Code

Mapping Designs to Code Mapping Designs to Code Creating Class Definitions from DCDs public class SalesLineItem private int quantity; private ProductDescription description ; public SalesLineItem(ProductDescription desc, int

More information

OO Design2. Design Artifacts

OO Design2. Design Artifacts OO Design2 POS example - revisited LAR Ch 8 has entire POS design explained READ THIS CHAPTER and ASK Q s in class Design class diagrams Kinds of visibility of objects to one another Navigability of associations

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

CSSE 374: Logical Architecture. Shawn Bohner Office: Moench Room F212 Phone: (812)

CSSE 374: Logical Architecture. Shawn Bohner Office: Moench Room F212 Phone: (812) CSSE 374: Logical Architecture Shawn Bohner Office: Moench Room F212 Phone: (812) 877-8685 Email: bohner@rose-hulman.edu An Engineering Decision Learning Outcomes: O-O Design Demonstrate object-oriented

More information

Goal: build an object-oriented model of the realworld system (or imaginary world) Slicing the soup: OOA vs. OOD

Goal: build an object-oriented model of the realworld system (or imaginary world) Slicing the soup: OOA vs. OOD Domain analysis Goal: build an object-oriented model of the realworld system (or imaginary world) Slicing the soup: OOA vs. OOD OOA concerned with what, not how OOA activities focus on the domain layer

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

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

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

More information

Domain Modeling. CSSE 574: Week 1, Part 3. Steve Chenoweth Phone: Office (812) Cell (937)

Domain Modeling. CSSE 574: Week 1, Part 3. Steve Chenoweth Phone: Office (812) Cell (937) Domain Modeling CSSE 574: Week 1, Part 3 Steve Chenoweth Phone: Office (812) 877-8974 Cell (937) 657-3885 Email: chenowet@rose-hulman.edu s g Where we re going Sample UP Artifact Relationships date...

More information

CS6502-OBJECT ORIENTED ANALYSIS AND DESIGN Two Marks Question with Answers Unit-I Introduction to OOAD

CS6502-OBJECT ORIENTED ANALYSIS AND DESIGN Two Marks Question with Answers Unit-I Introduction to OOAD CS6502-OBJECT ORIENTED ANALYSIS AND DESIGN Two Marks Question with Answers Unit-I Introduction to OOAD 1. What is Object-Oriented Analysis? Nov/Dec 2016 During object-oriented analysis there is an emphasis

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

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

Relationships amongst Objects

Relationships amongst Objects Relationships amongst Objects By Rick Mercer with help from Object-Oriented Design Heuristics Arthur Riel Addison-Wesley, 1996, ISBN 0-201-6338-X 8-1 Outline Consider six relationships between objects

More information

ROEVER ENGINEERING COLLEGE DEPARTMENT OF INFORMATION TECHNOLOGY CS2353-OBJECT ORIENTED ANALYSIS AND DESIGN. Unit-I. Introduction to OOAD

ROEVER ENGINEERING COLLEGE DEPARTMENT OF INFORMATION TECHNOLOGY CS2353-OBJECT ORIENTED ANALYSIS AND DESIGN. Unit-I. Introduction to OOAD ROEVER ENGINEERING COLLEGE CS2353-OBJECT ORIENTED ANALYSIS AND DESIGN 1. What is Object-Oriented Analysis? Unit-I Introduction to OOAD PART-A During object-oriented analysis there is an emphasis on finding

More information

Logical Architecture & Design Preliminaries

Logical Architecture & Design Preliminaries Logical Architecture & Design Preliminaries CSSE 574: Week 2, Part 4 Steve Chenoweth Phone: Office (812) 877-8974 Cell (937) 657-3885 Email: chenowet@rose-hulman.edu From Requirements to Architecture Customer

More information

Object-Oriented Functional Analysis and Design for POS Example

Object-Oriented Functional Analysis and Design for POS Example Object-Oriented Functional Analysis and Design for POS Example Focus in Analysis, Design, Implementation Analysis Investigation to the problem in problem domain Design Logical solution(model) for implementation

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

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

Object Oriented Analysis and Design CS6502

Object Oriented Analysis and Design CS6502 UNIT I (9) Introduction to OOAD What is OOAD? What is UML? What are the United process(up) phases - Case study the NextGen POS system, Inception -Use case Modeling - Relating Use cases include, extend

More information

Designing for Visibility & Mapping to Code CSSE 574: Session 4, Part 3

Designing for Visibility & Mapping to Code CSSE 574: Session 4, Part 3 Designing for Visibility & Mapping to Code CSSE 574: Session 4, Part 3 Steve Chenoweth Phone: Office (812) 877-8974 Cell (937) 657-3885 Email: chenowet@rose-hulman.edu Agenda Designing for Visibility Mapping

More information

From designing to coding

From designing to coding From designing to coding l st step: sensibly split work among team members Choose splits along thin interfaces l Probably not equal parts; split biggest parts again later Formalize the interfaces think

More information

Domain Modeling- 2. Generalization

Domain Modeling- 2. Generalization Generalization Domain Modeling- 2 Conceptual superclasses and subclasses When to create a subclass? A superclass? Abstract classes Modeling state changes Operation contracts Attaching pre- /post-conditions

More information

Design Pattern Detection

Design Pattern Detection Design Pattern Detection 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

More information

Understading Refactorings

Understading Refactorings Understading Refactorings Ricardo Terra terra@dcc.ufmg.br Marco Túlio Valente mtov@dcc.ufmg.br UFMG, 2010 UFMG, 2010 Understanding Refactorings 1 / 36 Agenda 1 Overview 2 Refactoring 3 Final Considerations

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 ORIENTED ANALYSIS AND DESIGN SYLLABUS

OBJECT ORIENTED ANALYSIS AND DESIGN SYLLABUS OBJECT ORIENTED ANALYSIS AND DESIGN SYLLABUS CS6502 - OBJECT ORIENTED ANALYSIS AND DESIGN L T P C 3 0 0 3 UNIT I- UML DIAGRAMS Introduction to OOAD Unified Process - UML diagrams Use Case Class Diagrams

More information

Object-Oriented Design and Modeling Using the UML

Object-Oriented Design and Modeling Using the UML Design Classes Object-Oriented Design and Modeling Using the UML Based on Chapter 18 of Whitten, Bentley, and Dittman: Systems Analysis and Design for the Global Enterprise (7th Ed). McGraw Hill. 2007

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

Principles of Software Construction: Objects, Design, and Concurrency

Principles of Software Construction: Objects, Design, and Concurrency Principles of Software Construction: Objects, Design, and Concurrency Designing (sub-) systems Responsibility assignment Charlie Garrod Michael Hilton School of Computer Science 1 Administrivia Reading

More information

Chapter 3: Object Oriented Design

Chapter 3: Object Oriented Design Chapter 3: Object Oriented Design Object Oriented Design The boundaries between analysis and design are fuzzy, although the focus of each is quite distinct. In analysis, the focus is to fully analyze the

More information

On to Object-oriented Design

On to Object-oriented Design Dr. Michael Eichberg Software Engineering Department of Computer Science Technische Universität Darmstadt Software Engineering On to Object-oriented Design Object-oriented Design 2 A popular way of thinking

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

Design Pattern Detection

Design Pattern Detection Design Pattern Detection Design Patterns EECS 6431 Design Pattern Detection 2/22 A design pattern systematically names, explains and evaluates an important and recurring design problem and its solution

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

UNIT 1-UMAL DIAGRAMS. Q.No. Question Competence Level. 1 What is Object Oriented analysis & Design? Remembering BTL1

UNIT 1-UMAL DIAGRAMS. Q.No. Question Competence Level. 1 What is Object Oriented analysis & Design? Remembering BTL1 Year & Semester : III & VI Section : CSE 1 & 2 Subject Code : CS6502 Subject Name : OBJECT ORIENTED ANALYSIS AND DESIGN Degree & Branch : B.E (CSE) Staff in charge : Dr.B.VANATHI & Mr.K.SHANMUGAM PART

More information

Software Design and Analysis CSCI 2040

Software Design and Analysis CSCI 2040 Software Design and Analysis CSCI 2040 http://data.science.uoit.ca -> Home -> Teaching -> Software Design and Analysis Software Design and Analysis CSCI 4030 2 Describe the goals. Define object-oriented

More information

System Sequence Diagrams. Based on Craig Larman, Chapter 10 and Anuradha Dharani s notes

System Sequence Diagrams. Based on Craig Larman, Chapter 10 and Anuradha Dharani s notes System Sequence Diagrams Based on Craig Larman, Chapter 10 and Anuradha Dharani s notes Dynamic behaviors Class diagrams represent static relationships. Why? What about modeling dynamic behavior? Interaction

More information

Final Exam CISC 475/675 Fall 2004

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

More information

4 Software models. often more than what people can handle not necessary to know all details at all times

4 Software models. often more than what people can handle not necessary to know all details at all times 4 Software models Software is complex often more than what people can handle not necessary to know all details at all times Models offer simplified view concentrate on the important issues and omit the

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

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

Chapter 5 Object-Oriented Programming

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

More information

Compositional Design Principles

Compositional Design Principles Chapter 16 Compositional Design Principles Learning Objectives In this chapter, I will more formally introduce the three principles that form the 3-1- 2 process. The learning focus is understanding how

More information

What is a Model? Copyright hebley & Associates

What is a Model? Copyright hebley & Associates Modeling Overview... as we know, there are known knowns; there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there

More information

Think of drawing/diagramming editors. ECE450 Software Engineering II. The problem. The Composite pattern

Think of drawing/diagramming editors. ECE450 Software Engineering II. The problem. The Composite pattern Think of drawing/diagramming editors ECE450 Software Engineering II Drawing/diagramming editors let users build complex diagrams out of simple components The user can group components to form larger components......which

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

Chapter 1: Programming Principles

Chapter 1: Programming Principles Chapter 1: Programming Principles Object Oriented Analysis and Design Abstraction and information hiding Object oriented programming principles Unified Modeling Language Software life-cycle models Key

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

SKP Engineering College

SKP Engineering College SKP Engineering College Tiruvannamalai 606611 A Course Material on Object Oriented Analysis and Design By G.Nanda Kumar Assistant Professor Computer Science and Engineering Department Computer Science

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

VALLIAMMAI ENGINEERING COLLEGE

VALLIAMMAI ENGINEERING COLLEGE VALLIAMMAI ENGINEERING COLLEGE SRM Nagar, Kattankulathur 603 203 DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING QUESTION BANK V SEMESTER CS6502-OBJECT ORIENTED ANALYSIS AND DESIGN Regulation 2013 Academic

More information

Operations Contracts and Preliminaries on Design

Operations Contracts and Preliminaries on Design Operations Contracts and Preliminaries on Design CSSE 574: Week 2, Part 3 Steve Chenoweth Phone: Office (812) 877-8974 Cell (937) 657-3885 Email: chenowet@rose-hulman.edu We are at System Operation Contracts

More information

Design Pattern What is a Design Pattern? Design Pattern Elements. Almas Ansari Page 1

Design Pattern What is a Design Pattern? Design Pattern Elements. Almas Ansari Page 1 What is a Design Pattern? Each pattern Describes a problem which occurs over and over again in our environment,and then describes the core of the problem Novelists, playwrights and other writers rarely

More information

Design Engineering. Overview

Design Engineering. Overview Design Engineering Overview What is software design? How to do it? Principles, concepts, and practices High-level design Low-level design N. Meng, B. Ryder 2 1 Design Engineering The process of making

More information

CHAPTER 5 GENERAL OOP CONCEPTS

CHAPTER 5 GENERAL OOP CONCEPTS CHAPTER 5 GENERAL OOP CONCEPTS EVOLUTION OF SOFTWARE A PROGRAMMING LANGUAGE SHOULD SERVE 2 RELATED PURPOSES : 1. It should provide a vehicle for programmer to specify actions to be executed. 2. It should

More information

Produced by. Design Patterns. MSc in Communications Software. Eamonn de Leastar

Produced by. Design Patterns. MSc in Communications Software. Eamonn de Leastar Design Patterns MSc in Communications Software Produced by Eamonn de Leastar (edeleastar@wit.ie) Department of Computing, Maths & Physics Waterford Institute of Technology http://www.wit.ie http://elearning.wit.ie

More information

6.3 Patterns. Definition: Design Patterns

6.3 Patterns. Definition: Design Patterns Subject/Topic/Focus: Analysis and Design Patterns Summary: What is a pattern? Why patterns? 6.3 Patterns Creational, structural and behavioral patterns Examples: Abstract Factory, Composite, Chain of Responsibility

More information

CPSC 427a: Object-Oriented Programming

CPSC 427a: Object-Oriented Programming CPSC 427a: Object-Oriented Programming Michael J. Fischer Lecture 22a November 17, 2011 CPSC 427a, Lecture 22a 1/20 CPSC 427a, Lecture 22a 2/20 CPSC 427a, Lecture 22a 3/20 General OO principles 1. Encapsulation

More information

The Software Design Process. CSCE 315 Programming Studio, Fall 2017 Tanzir Ahmed

The Software Design Process. CSCE 315 Programming Studio, Fall 2017 Tanzir Ahmed The Software Design Process CSCE 315 Programming Studio, Fall 2017 Tanzir Ahmed Outline Challenges in Design Design Concepts Heuristics Practices Challenges in Design A problem that can only be defined

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

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

Design Patterns. CSC207 Fall 2017

Design Patterns. CSC207 Fall 2017 Design Patterns CSC207 Fall 2017 Design Patterns A design pattern is a general description of the solution to a well-established problem using an arrangement of classes and objects. Patterns describe the

More information

Modellistica Medica. Maria Grazia Pia, INFN Genova. Scuola di Specializzazione in Fisica Sanitaria Genova Anno Accademico

Modellistica Medica. Maria Grazia Pia, INFN Genova. Scuola di Specializzazione in Fisica Sanitaria Genova Anno Accademico Modellistica Medica Maria Grazia Pia INFN Genova Scuola di Specializzazione in Fisica Sanitaria Genova Anno Accademico 2002-2003 Lezione 8 OO modeling Design Patterns Introduction Creational Patterns Software

More information

Using Design Patterns in Education and Tutoring for the Software Systems Projects in Economic

Using Design Patterns in Education and Tutoring for the Software Systems Projects in Economic Using Design Patterns in Education and Tutoring for the Software Systems Projects in Economic Cornelia NOVAC-UDUDEC cornelia.novac@ugal.ro Dunarea de Jos University of Galati Abstract. The paper deals

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

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

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

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

CS 2340 Objects and Design

CS 2340 Objects and Design CS 2340 Objects and Design Software Design Christopher Simpkins chris.simpkins@gatech.edu Chris Simpkins (Georgia Tech) CS 2340 Objects and Design Software Design 1 / 6 Design Design (noun) A plan or protocol

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