Assigning Responsibilities (Patterns of Responsibility Assignment Principles: GRASP)

Size: px
Start display at page:

Download "Assigning Responsibilities (Patterns of Responsibility Assignment Principles: GRASP)"

Transcription

1 Subsystem design basics Assigning Responsibilities (Patterns of Responsibility Assignment Principles: GRASP) Dept. of Computer Science Baylor University Focus on modeling how subsystems accomplish goals (deliver services) Models Design Class Model (class diagrams) Behavioral Models Interaction Models (sequence diagrams/communication diagrams) State Models Activity Models Slide Sources: UML 2.0 Specification by OMG & UML/OCL Tutorial by Dr. R. France Assigning Responsibilities-1 Assigning Responsibilities-2 Requirements class vs. design class Key design activities A Payment in the Domain Model is a concept, but a Payment in the Design Model is a software class. They are not the same thing, but the former inspired the naming and definition of the latter. This reduces the representational gap. This is one of the big ideas in object technology. UP Domain Model Stakeholder's view of the noteworthy concepts in the domain. Payment 1 Pays-for 1 date amount time inspires objects and names in Payment 1 1 date: Date Pays-for amount: Money starttime: Time Assign responsibilities to classes Determine which objects need to know of other objects (determine class navigability) getbalance(): Money gettotal(): Money... UP Design Model The object-oriented developer has taken inspiration from the real world domain in creating software classes. Therefore, the representational gap between how stakeholders conceive the domain, and its representation in software, has been lowered. Assigning Responsibilities-3 Assigning Responsibilities-4 Allocating responsibilities to classes A responsibility is something that the class is required to do (contract or obligation of a class) To determine responsibilities Perform use case analysis Look for verbs and nouns describing actions in the system description Allocating responsibilities to classes (cont.) Each functional requirement must be attributed to one of the classes All the responsibilities of a given class should be clearly related. If a class has too many responsibilities, consider splitting it into distinct classes If a class has no responsibilities attached to it, then it is probably useless When a responsibility cannot be attributed to any of the existing classes, then a new class should be created Assigning Responsibilities-5 Assigning Responsibilities-6 1

2 Categories of responsibilities Setting and getting the values of attributes Creating and initializing new instances Loading to and saving from persistent storage Destroying instances Adding and deleting links of associations Copying, converting, transforming, transmitting or outputting Computing numerical results Navigating and searching Other specialized work Other categories of responsibilities Action-oriented responsibilities Carrying out an activity Controlling and coordinating activities in other objects Delegating activities to other objects Data-oriented responsibilities Maintaining private information Maintaining relationships to other objects Maintaining derived information Assigning Responsibilities-7 Assigning Responsibilities-8 Responsibility assignment in modeling Interaction models reflect decisions pertaining to assignment of responsibilities Message passing between objects reflect responsibility distribution Use interaction diagrams to explore possible distribution of responsibilities Two types of responsibilities Doing Doing something itself (e.g. creating an object, doing a calculation) Initiating action in other objects. Controlling and coordinating activities in other objects. Knowing: Knowing about private encapsulated data. Knowing about related objects. Knowing about things it can derive or calculate. Assigning Responsibilities-9 Assigning Responsibilities-10 Examples and Tips Responsibilities are assigned to classes during object design. For example, we may declare the following: a is responsible for creating slineitems (doing) a is responsible for knowing its total (knowing) Responsibilities related to knowing are often inferable from the Domain Model (because of the attributes and associations it illustrates) Examples and Tips (cont ) The translation of responsibilities into classes and methods is influenced by the granularity of responsibility. For example, provide access to relational databases may involve dozens of classes and hundreds of methods, whereas create a may involve only one or few methods. Assigning Responsibilities-11 Assigning Responsibilities-12 2

3 Responsibilities vs. Methods Responsibilities and interaction diagrams A responsibility is not the same thing as a method, but methods are implemented to fulfill responsibilities. Methods either act alone, or collaborate with other methods and objects. :Payment Within the UML artifacts, a common context where these responsibilities (implemented as methods) are considered is during the creation of interaction diagrams. objects have been given the responsibility to create Payments, handled with the makepayment method. Assigning Responsibilities-13 Assigning Responsibilities-14 Patterns of Responsibility Assignment Principles We will emphasize principles (expressed in patterns) to guide choices in where to assign responsibilities. GRASP: General Responsibility Assignment Software Patterns. A pattern is a named description of a problem and a solution that can be applied to new contexts; it provides advice in how to apply it in varying circumstances. Patterns of Responsibility Assignment Principles: GRASP Creator Expert Low Coupling Controller High Cohesion Assigning Responsibilities-15 Assigning Responsibilities-16 Creator Problem: Who should be responsible for creating a new instance of some class? 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). ProductSpecification Contains slineitem Described-by date 1..* quantity * 1 specification price id In the POS application, who should be responsible for creating a slineitem instance? Since a contains many slineitem objects, the Creator pattern suggests that is a good candidate. Assigning Responsibilities-17 Assigning Responsibilities-18 3

4 Information Expert (or Expert) makelineitem(quantity) create(quantity) slineitem This assignment of responsibilities requires that a makelineitem() method be defined in. Problem: what is a general principle of assigning responsibilities to objects? Solution: Assign a responsibility to the information expert - the class that has the information necessary to fulfill the responsibility. In the NextGen POS application, who should be responsible for knowing the grand total of a sale? By Information Expert we should look for that class that has the information needed to determine the total. Assigning Responsibilities-19 Assigning Responsibilities-20 Do we look in the Domain Model or the Design Model to analyze the classes that have the information needed? A: Both. Assume there is no or minimal Design Model. Look to the Domain Model for information experts. ProductSpecification Contains slineitem Described-by date 1..* quantity * 1 specification price id It is necessary to know about all the slineitem instances of a sale and the sum of the subtotals. A instance contains these, i.e. it is an information expert for this responsibility. Assigning Responsibilities-21 Assigning Responsibilities-22 t := gettotal() This is a partial interaction diagram. t := gettotal() 1 *: st := getsubtotal() slineitem What information is needed to determine the line item subtotal? quantity and price. slineitem should determine the subtotal. This means that needs to send getsubtotal() messages to each of the slineitem instances and sum the results. Assigning Responsibilities-23 Assigning Responsibilities-24 4

5 t := gettotal() 1 *: st := getsubtotal() slineitem 1.1: p := getprice() :ProductSpecification To fulfil the responsibility of knowing and answering its subtotal, a slineitem needs to know the product price. The ProductSpecification is the information expert on answering its price. Class slineitem ProductSpecification Responsibility Knows total Knows line item total Knows product price To fulfil the responsibility of knowing and answering the sale s s total, three responsibilities were assigned to three design classes The fulfillment of a responsibility often requires information that is spread across different classes of objects. This implies that there are many partial experts who will collaborate in the task. Assigning Responsibilities-25 Assigning Responsibilities-26 Be careful. Low Coupling Naïve use can lead to undesirable coupling and low cohesion. Giving a class the responsibility for storing its objects in a database leads to low cohesion and undesirable coupling Low cohesion: class contains code (or logic) related to database handling, such as that related to SQL and JDBC (Java Database Connectivity) Undesirable coupling: class is tightly coupled to database services provided by another system Problem: How to support low dependency, low change impact and increased reuse? Solution: Assign a responsibility so that coupling remains low. Note: Coupling: it is a measure of how strongly one element is connected to, has knowledge of, or relies upon other elements. Assigning Responsibilities-27 Assigning Responsibilities-28 More about coupling More about Coupling (cont ) Forms of coupling in OO designs Class X contains a reference to Class Y objects Class X operation includes calls to Class Y operations Class X operation has a Class Y object as a parameter or declares a Class Y object as a local variable Class X is a direct or indirect subclass of Class Y Class X implements an interface Y Classes designed for reuse should have low coupling. Why? 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. Assigning Responsibilities-29 Assigning Responsibilities-30 5

6 Low Coupling an example Low Coupling an example (cont ) :Payment 1: p:payment Assume we need to create a Payment instance and associate it with. What class should be responsible for this? By Creator, Register is a candidate. 2: addpayment(p) Register could then send an addpayment message to, passing along the new Payment as a parameter. The assignment of responsibilities couples the Register class to knowledge of the Payment class. is also coupled to knowledge of Payment. Assigning Responsibilities-31 Assigning Responsibilities-32 Low Coupling an example (cont ) 1: 1.1. :Payment An alternative solution is to have create Payment and associate it with. No coupling between Register and Payment. High Cohesion Cohesion: it is a measure of how strongly related and focused the responsibilities of an element are. A class with low cohesion does many unrelated activities or does too much work. Problems because of a design with low cohesion: Hard to understand. Hard to reuse. Hard to maintain. Delicate, affected by change. Problem: How to keep complexity manageable? Solution: Assign a responsibility so that cohesion remains high. Assigning Responsibilities-33 Assigning Responsibilities-34 High Cohesion Guideline Assign a responsibility so that parts of the class are strongly related and the class responsibility is tightly focused Class easier to understand Easier to maintain and reuse When to ignore high cohesion guidelines A class that provides a single point of entry into a system may sometimes be desirable Such a class is called a Façade and provides external clients with a single point of access to services offered by a system For efficiency reasons it may be more appropriate to place two diverse classes in the same class Rather than an object delegating responsibility for a service to another object it may carry it out itself to avoid delegation performance overhead Refer to more examples in pg.318 of textbook Assigning Responsibilities-35 Assigning Responsibilities-36 6

7 High Cohesion an example (cont ) High Cohesion an example (cont ) p:payment addpayment(p) :Payment Assume we need to create a Payment instance and associate it with. What class should be responsible for this? By Creator, Register is a candidate. However, Register may become bloated if it is assigned more and more system operations. An alternative design delegates the Payment creation responsibility to, which supports higher cohesion in Register. This design supports high cohesion and low coupling. Assigning Responsibilities-37 Assigning Responsibilities-38 Degree of Cohesion Degree of Cohesion (cont ) Scenarios that illustrate varying degrees of functional cohesion 1. Very low cohesion: class responsible for many things in many different areas. eg: e.g.: a class responsible for interfacing with a data base and remote-procedure-calls. 2. Low cohesion: class responsible for complex task in a functional area. e.g.: a class responsible for interacting with a relational database. 3. High cohesion: class has moderate responsibility in one functional area and it collaborates with other classes to fulfill a task. e.g.: a class responsible for one section of interfacing with a data base. Rule of thumb: a class with high cohesion has a relative low number of methods, with highly related functionality, and doesn t do much work. It collaborates and delegates. Assigning Responsibilities-39 Assigning Responsibilities-40 Controller Controller Problem: Who should be responsible for handling an input system event? Solution: Assign the responsibility for receiving or handling a system event message to a class representing one of the following choices: Represents the overall system. Represents a use case scenario. A Controller is a non-user interface object that defines the method for the system operation. Note that windows, applets, etc. typically receive events and delegate them to a controller. A good controller delegates the work needed to handle a system event to other objects. A controller controls and coordinates the collaborating objects. A controller does not do much of the actual work. Assigning Responsibilities-41 Assigning Responsibilities-42 7

8 Controller Options Presentation objects (UI objects) should not be responsible for handling events Decouple presentation layer from application processing layer. Why? System as controller Referred to as a façade controller Use when number of system events is not large Large number of events can lead to a controller with low cohesion and high coupling Use case handlers For each use case design a controller that handles the use case events Use when number of system events is large Bloated Controllers Signs of problematic design Interface objects handle system events directly Controller object handles many events Controller object performs bulk of work needed to handle event. Controller class has many attributes because of its many responsibilities. Assigning Responsibilities-43 Assigning Responsibilities-44 General Guidelines Avoid dumb objects: objects that hold data and provide only get/set methods Avoid god controllers: a god controller is one that requests state information (e.g., using a get method) and uses the information to make decisions or perform calculations Avoid coupling by having services above and beyond get/set services in interface of objects A client should request an object to do something on its behalf, not request information about an object s state. Use Case realizations System makenew() addlineitem(id, quantity) end() makepayment(cashtendered) Contract CO1: makenew Operation: makenew () Cross References: Use Case Process. Preconditions: none. Postconditions: A instance s was created. (instance creation) s was associated with Register (association formed) Attributes of s were initialized A use-case realization describes how a use case is realized in terms of collaborating objects. UML interaction diagrams are used to illustrate use case realizations. Recall Process : from the main scenario we identified a number of system events (operations) Each system event was then described by a contract. Assigning Responsibilities-45 Assigning Responsibilities-46 Object design: makenew Object Design Exercise: addlineitem We work through the postcondition state changes and design message interactions to satisfy the requirements. makenew() By Controller. Register creates a by Creator. Implied to take place within the constructor of instance. By Creator, creates an empty multiobject which will eventually hold slineitem instances slineitem This is NOT a slineitem Instance but a collection object. Contract CO2: addlineitem Postconditions: A slineitem instance sli was created. (instance creation) sli was associated with the. (association formed) sli.quantity was set to quantity. (attribute modification) sli was associated with a ProductSpecification, based on id match (association formed) addlineitem(id, quantity) 1: spec := getproductspecification(id) :ProductCatalog 1.1: spec:= find(id) :ProductSpecification 2: makelineitem(spec, quantity) slineitem 2.2: add (sli) 2.1: create (spec, quantity) slislineitem Assigning Responsibilities-47 Assigning Responsibilities-48 8

9 Object Design: addlineitem By Controller. By Creator. addlineitem(id, quantity) 2: makelineitem(spec, quantity) 1: spec := getproductspecification(id) By Expert. 2.2: add (sli) 2.1: create (spec, quantity) :ProductCatalog slislineitem 1.1: spec:= find(id) slineitem Object Design Exercise: end Contract CO3: end Postconditions:.isComplete became true (attribute modification) { public void becomecomplete() { iscomplete = true; } } UML notation for a constraint {s.iscomplete = true} :ProductSpecification end() 1: becomecomplete() s This is a multiobject collection. It contains many instances of ProductSpecification. find and add are generic implementation-independent messages. By Controller. By Expert. Assigning Responsibilities-49 Assigning Responsibilities-50 Extensibility vs. Reusability Poor distribution can lead to inflexible designs Change impact can be wide Good distribution can lead to lower maintenance costs Tension between extensibility and reusability Good distribution requires encapsulation of applicationspecific details in class Reusability requires that software be as independent as possible from application context Assigning Responsibilities-51 9

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

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

Information Expert (or Expert)

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

More information

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

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

More information

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

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

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

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

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

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

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

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

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

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

Creating Class Definitions from Design Class Diagrams: public class SalesLineItem // Java { private int quantity;

Creating Class Definitions from Design Class Diagrams: public class SalesLineItem // Java { private int quantity; 24.3.204 Coding (Implementation) The design model (design class diagram and interaction diagrams) provides some of the information that is necessary to generate the code. (Not all of the code) Creating

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

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

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

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

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

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

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

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

More information

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

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

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

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

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

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

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

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

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

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

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

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

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

Chapter 10 Object-Oriented Design Principles

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

More information

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

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

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

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

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

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

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

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

More information

SE203b: OO Design for Software Engineers. Office: TEB349, Ext

SE203b: OO Design for Software Engineers. Office: TEB349, Ext SE203b: OO Design for Software Engineers W0 : Course Overview Jan. 11, 2006 SE203b, ECE UWO, Hamada Ghenniwa Teaching Team Instructor TAs o Hamada Ghenniwa Office: TEB349, Ext. 88262 e-mail: hghenniwa@eng.uwo.ca

More information

Topic : Object Oriented Design Principles

Topic : Object Oriented Design Principles Topic : Object Oriented Design Principles Software Engineering Faculty of Computing Universiti Teknologi Malaysia Objectives Describe the differences between requirements activities and design activities

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

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

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

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

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

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

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

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

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

Some Software Engineering Techniques (Class Diagrams and Pair Programming)

Some Software Engineering Techniques (Class Diagrams and Pair Programming) Some Software Engineering Techniques (Class Diagrams and Pair Programming) } Programs typically begin as abstract ideas } These ideas form a set of abstract requirements } We must take these abstract requirements,

More information

Requirements and Design Overview

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

More information

Sequence Diagram. A UML diagram used to show how objects interact. Example:

Sequence Diagram. A UML diagram used to show how objects interact. Example: Sequence Diagram A UML diagram used to show how objects interact. Example: r: Register s: Sale makepayment() makepayment() new() : Payment The above starts with a Register object, r, receiving a makepayment

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

Domain Model and Domain Modeling

Domain Model and Domain Modeling Dr. Michael Eichberg Software Engineering Department of Computer Science Technische Universität Darmstadt Software Engineering Domain Model and Domain Modeling Resources: Craig Larman; Applying UML and

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

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

Object-Oriented Software Engineering Practical Software Development using UML and Java. Chapter 5: Modelling with Classes

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

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

EINDHOVEN UNIVERSITY OF TECHNOLOGY

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

More information

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

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

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

Objectives. Explain the purpose and objectives of objectoriented. Develop design class diagrams

Objectives. Explain the purpose and objectives of objectoriented. Develop design class diagrams Objectives Explain the purpose and objectives of objectoriented design Develop design class diagrams Develop interaction diagrams based on the principles of object responsibility and use case controllers

More information

Sequence Diagram. r: Register s: Sale

Sequence Diagram. r: Register s: Sale ACS-3913 1 Sequence Diagram A UML diagram used to show how objects interact. Example: r: Register s: Sale makepayment() makepayment() new() : Payment The above starts with a Register object, r, receiving

More information

Accessibility. EEC 521: Software Engineering. Classes and Objects. Inheritance. Classes and Objects (OO Analysis)

Accessibility. EEC 521: Software Engineering. Classes and Objects. Inheritance. Classes and Objects (OO Analysis) Accessibility EEC 521: Software Engineering Classes and Objects (OO Analysis) Attributes and Methods can be declared at three levels of accessibility Public (+) Visible everywhere Private (-) Visible only

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

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

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

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

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

More information

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 9 OO modeling Design Patterns Structural Patterns Behavioural Patterns

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

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

SAP. Modeling Guide for PPF

SAP. Modeling Guide for PPF Modeling Guide for PPF Contents 1 Document Organization... 3 1.1 Authors... 3 1.2 Intended Group of Readers... 3 1.3 References... 3 1.4 Glossary... 4 2 Modeling Guidelines - Application Analysis... 6

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

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

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

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

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

OBJECT ORIENTED DESIGN with the Unified Process. Use Case Realization

OBJECT ORIENTED DESIGN with the Unified Process. Use Case Realization OBJECT ORIENTED DESIGN with the Unified Process Use Case Realization Objectives Explain the purpose and objectives of objectoriented design Develop design class diagrams Develop detailed sequence diagrams

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. Furthermore, it is natural to discover and change some requirements during the design and implementation work of the early iterations.

Design. Furthermore, it is natural to discover and change some requirements during the design and implementation work of the early iterations. Design Design Iteratively Do the Right Thing, Do the Thing Right. The requirements and object-oriented analysis has focused on learning to do the right thing By contrast, the design work will stress do

More information

In this Lecture you will Learn: Object Design. Information Sources for Object Design. Class Specification: Attributes

In this Lecture you will Learn: Object Design. Information Sources for Object Design. Class Specification: Attributes In this Lecture you will Learn: Object Design Chapter 14 How to apply criteria for good design How to design associations The impact of integrity constraints on design How to design operations The role

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

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

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

SOFTWARE DESIGN COSC 4353 / Dr. Raj Singh

SOFTWARE DESIGN COSC 4353 / Dr. Raj Singh SOFTWARE DESIGN COSC 4353 / 6353 Dr. Raj Singh UML - History 2 The Unified Modeling Language (UML) is a general purpose modeling language designed to provide a standard way to visualize the design of a

More information

Credit where Credit is Due. Goals for this Lecture. Introduction to Design

Credit where Credit is Due. Goals for this Lecture. Introduction to Design Credit where Credit is Due Lecture 17: Intro. to Design (Part 1) Kenneth M. Anderson Object-Oriented Analysis and Design CSCI 6448 - Spring Semester, 2002 Some material presented in this lecture is taken

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

Download FirstOODesignPractice from SVN. A Software Engineering Technique: (Class Diagrams)

Download FirstOODesignPractice from SVN. A Software Engineering Technique: (Class Diagrams) Download FirstOODesignPractice from SVN A Software Engineering Technique: (Class Diagrams) public class TicTacToe { private final int rows; private final int columns; private String[][] board; /** * Constructs

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

10.1 Big Objects, Business Objects, and UML Components

10.1 Big Objects, Business Objects, and UML Components II Black-Box Composition Systems 10. Finding Business s in a -Based Development Process Literature J. Cheesman, J. Daniels. UML s. Addison-Wesley. 1. The UML component model 2. Business component model

More information

Information Technology Audit & Cyber Security

Information Technology Audit & Cyber Security Information Technology Audit & Cyber Security Structural Modeling Systems & Infrastructure Lifecycle Management OBJECTIVES demonstrate the differences between object diagrams and class diagrams, explain

More information

Introduction to Unified Modelling Language (UML)

Introduction to Unified Modelling Language (UML) IMPORTANT NOTICE TO STUDENTS These slides are NOT to be used as a replacement for student notes. These slides are sometimes vague and incomplete on purpose to spark a class discussion Introduction to Unified

More information