copyright © craig larman. 2000 all rights reserved comp-350 object-oriented analysis and design...
DESCRIPTION
Copyright © Craig Larman All Rights Reserved 3 Responsibility-Driven Design (RDD) n Responsibility- Contract or obligation of a class n Two types – What must a class “know”? [knowing responsibility] Know about private encapsulated data Know about related objects Know about things it can derive or calculate n What must a class “do”? [doing responsibility] – Do something itself: e.g. create an object, do a calculation – Initiate action in other objects – Control/coordinate actions in other objects n Responsibilities are fulfilled by object methodsTRANSCRIPT
![Page 1: Copyright © Craig Larman. 2000 All Rights Reserved COMP-350 Object-Oriented Analysis and Design GRASP: Designing Objects with Responsibilities Reference:](https://reader035.vdocuments.us/reader035/viewer/2022062223/5a4d1b137f8b9ab0599906cd/html5/thumbnails/1.jpg)
Copyright © Craig Larman. 2000 All Rights Reserved
COMP-350 Object-Oriented Analysis and Design
GRASP: Designing Objects with ResponsibilitiesReference: Larman chapter 17
![Page 2: Copyright © Craig Larman. 2000 All Rights Reserved COMP-350 Object-Oriented Analysis and Design GRASP: Designing Objects with Responsibilities Reference:](https://reader035.vdocuments.us/reader035/viewer/2022062223/5a4d1b137f8b9ab0599906cd/html5/thumbnails/2.jpg)
Copyright © Craig Larman. 2000 All Rights Reserved2
Object Design by Responsibilities “Identify requirements, create a domain model, add
methods to the software classes, define messages to meet requirements…”
Too Simple!– What methods belong where?– How do we assign responsibilities to classes?
Object-oriented design is not about UML. It is primarily about assigning Responsibilities to objects.
![Page 3: Copyright © Craig Larman. 2000 All Rights Reserved COMP-350 Object-Oriented Analysis and Design GRASP: Designing Objects with Responsibilities Reference:](https://reader035.vdocuments.us/reader035/viewer/2022062223/5a4d1b137f8b9ab0599906cd/html5/thumbnails/3.jpg)
Copyright © Craig Larman. 2000 All Rights Reserved3
Responsibility-Driven Design (RDD) Responsibility- Contract or obligation of a class Two types
– What must a class “know”? [knowing responsibility]Know about private encapsulated data
Know about related objects
Know about things it can derive or calculate What must a class “do”? [doing responsibility]
– Do something itself: e.g. create an object, do a calculation– Initiate action in other objects– Control/coordinate actions in other objects
Responsibilities are fulfilled by object methods
![Page 4: Copyright © Craig Larman. 2000 All Rights Reserved COMP-350 Object-Oriented Analysis and Design GRASP: Designing Objects with Responsibilities Reference:](https://reader035.vdocuments.us/reader035/viewer/2022062223/5a4d1b137f8b9ab0599906cd/html5/thumbnails/4.jpg)
Copyright © Craig Larman. 2000 All Rights Reserved4
Examples of object responsibilities
“A Sale object is responsible for creating SalesLineItem objects”(doing)
“A Sale object is responsible for knowing its total” (knowing)
![Page 5: Copyright © Craig Larman. 2000 All Rights Reserved COMP-350 Object-Oriented Analysis and Design GRASP: Designing Objects with Responsibilities Reference:](https://reader035.vdocuments.us/reader035/viewer/2022062223/5a4d1b137f8b9ab0599906cd/html5/thumbnails/5.jpg)
Copyright © Craig Larman. 2000 All Rights Reserved5
Responsibilities Responsibilities are an abstraction.
– The responsibility for persistence.Large-grained responsibility.
– The responsibility for the sales tax calculation.More fine-grained responsibility.
They are implemented with methods in objects.– 1 method in 1 object– 5 methods in 1 object– 50 methods across 10 objects
![Page 6: Copyright © Craig Larman. 2000 All Rights Reserved COMP-350 Object-Oriented Analysis and Design GRASP: Designing Objects with Responsibilities Reference:](https://reader035.vdocuments.us/reader035/viewer/2022062223/5a4d1b137f8b9ab0599906cd/html5/thumbnails/6.jpg)
Copyright © Craig Larman. 2000 All Rights Reserved6
Responsibilities in Interaction Diagrams
When drawing interaction diagrams, you are implicitly assigning Responsibilities to particular objects.
![Page 7: Copyright © Craig Larman. 2000 All Rights Reserved COMP-350 Object-Oriented Analysis and Design GRASP: Designing Objects with Responsibilities Reference:](https://reader035.vdocuments.us/reader035/viewer/2022062223/5a4d1b137f8b9ab0599906cd/html5/thumbnails/7.jpg)
Copyright © Craig Larman. 2000 All Rights Reserved7
Responsibility-Driven Design:GRASP
GRASP: General Responsibility Assignment Software Patterns (or Principles).
GRASP provides basic principles for assignment of Responsibilities to objects.
Think GRASP when drawing interaction diagrams.
![Page 8: Copyright © Craig Larman. 2000 All Rights Reserved COMP-350 Object-Oriented Analysis and Design GRASP: Designing Objects with Responsibilities Reference:](https://reader035.vdocuments.us/reader035/viewer/2022062223/5a4d1b137f8b9ab0599906cd/html5/thumbnails/8.jpg)
Copyright © Craig Larman. 2000 All Rights Reserved8
GRASP for Responsibility-Driven Design
![Page 9: Copyright © Craig Larman. 2000 All Rights Reserved COMP-350 Object-Oriented Analysis and Design GRASP: Designing Objects with Responsibilities Reference:](https://reader035.vdocuments.us/reader035/viewer/2022062223/5a4d1b137f8b9ab0599906cd/html5/thumbnails/9.jpg)
Copyright © Craig Larman. 2000 All Rights Reserved9
Workflow
![Page 10: Copyright © Craig Larman. 2000 All Rights Reserved COMP-350 Object-Oriented Analysis and Design GRASP: Designing Objects with Responsibilities Reference:](https://reader035.vdocuments.us/reader035/viewer/2022062223/5a4d1b137f8b9ab0599906cd/html5/thumbnails/10.jpg)
Copyright © Craig Larman. 2000 All Rights Reserved10 10
GRASP PatternsWhich class, in the general case is responsible? You want to assign a responsibility to a class You want to avoid or minimize additional
dependencies You want to maximise cohesion and minimise
coupling You want to increase reuse and decrease
maintenance You want to maximise understandability …..etc.
![Page 11: Copyright © Craig Larman. 2000 All Rights Reserved COMP-350 Object-Oriented Analysis and Design GRASP: Designing Objects with Responsibilities Reference:](https://reader035.vdocuments.us/reader035/viewer/2022062223/5a4d1b137f8b9ab0599906cd/html5/thumbnails/11.jpg)
Copyright © Craig Larman. 2000 All Rights Reserved11
Five Fundamental GRASP Patterns1. Creator: who should be responsible for creating a
specific object? 2. Information Expert: who should be responsible
for knowing about a particular object?3. High Cohesion: how should responsibilities be
grouped within classes?4. Low Coupling: how strongly should elements be
tied to others?5. Controller: who should be the first to receive a
message in the domain layer?
![Page 12: Copyright © Craig Larman. 2000 All Rights Reserved COMP-350 Object-Oriented Analysis and Design GRASP: Designing Objects with Responsibilities Reference:](https://reader035.vdocuments.us/reader035/viewer/2022062223/5a4d1b137f8b9ab0599906cd/html5/thumbnails/12.jpg)
Copyright © Craig Larman. 2000 All Rights Reserved12
1. Creator Problem
– Who (i.e. what class) creates a new instance of a class A
Solution– Assign class B the responsibility to create an
instance of class A if one of these is true:B “contains” A
B records A
B closely uses A
B has the Initializing data for A
![Page 13: Copyright © Craig Larman. 2000 All Rights Reserved COMP-350 Object-Oriented Analysis and Design GRASP: Designing Objects with Responsibilities Reference:](https://reader035.vdocuments.us/reader035/viewer/2022062223/5a4d1b137f8b9ab0599906cd/html5/thumbnails/13.jpg)
Copyright © Craig Larman. 2000 All Rights Reserved13
Creator: example In Monopoly, who creates the Square object Start point: Look at the Domain Model
![Page 14: Copyright © Craig Larman. 2000 All Rights Reserved COMP-350 Object-Oriented Analysis and Design GRASP: Designing Objects with Responsibilities Reference:](https://reader035.vdocuments.us/reader035/viewer/2022062223/5a4d1b137f8b9ab0599906cd/html5/thumbnails/14.jpg)
Copyright © Craig Larman. 2000 All Rights Reserved14
Creator: SolutionThe Board object contains Square objects, so it is a good candidate.
This also gives us a clue that the relationship should be a composition:
![Page 15: Copyright © Craig Larman. 2000 All Rights Reserved COMP-350 Object-Oriented Analysis and Design GRASP: Designing Objects with Responsibilities Reference:](https://reader035.vdocuments.us/reader035/viewer/2022062223/5a4d1b137f8b9ab0599906cd/html5/thumbnails/15.jpg)
Copyright © Craig Larman. 2000 All Rights Reserved15
2. Information Expert (or Expert) Problem
– Who (i.e. what class) should be responsible for knowing about instances of a class A
Solution– Assign a knowing responsibility to the class that has
the information needed to fulfill it
![Page 16: Copyright © Craig Larman. 2000 All Rights Reserved COMP-350 Object-Oriented Analysis and Design GRASP: Designing Objects with Responsibilities Reference:](https://reader035.vdocuments.us/reader035/viewer/2022062223/5a4d1b137f8b9ab0599906cd/html5/thumbnails/16.jpg)
Copyright © Craig Larman. 2000 All Rights Reserved16
Note
When assigning “knowing” or information responsibilities, first look in the Design model for an appropriate class.
If not found in the design model, then look in the Domain model.
This approach helps in clarifying the Design Model
![Page 17: Copyright © Craig Larman. 2000 All Rights Reserved COMP-350 Object-Oriented Analysis and Design GRASP: Designing Objects with Responsibilities Reference:](https://reader035.vdocuments.us/reader035/viewer/2022062223/5a4d1b137f8b9ab0599906cd/html5/thumbnails/17.jpg)
Copyright © Craig Larman. 2000 All Rights Reserved17
Information Expert: example What class should know about (e.g. status of)
Square objects?– Alternatively, who should be the receiver of
message getSquare(name) Solution:
– Board knows about all squares, i.e. Board has the information necessary to fulfill this responsibility
![Page 18: Copyright © Craig Larman. 2000 All Rights Reserved COMP-350 Object-Oriented Analysis and Design GRASP: Designing Objects with Responsibilities Reference:](https://reader035.vdocuments.us/reader035/viewer/2022062223/5a4d1b137f8b9ab0599906cd/html5/thumbnails/18.jpg)
Copyright © Craig Larman. 2000 All Rights Reserved18
3. Low Coupling Problem
– How to reduce the impact of change, to support low dependency, and increase reuse?
Solution– Assign a responsibility so that coupling remains low
![Page 19: Copyright © Craig Larman. 2000 All Rights Reserved COMP-350 Object-Oriented Analysis and Design GRASP: Designing Objects with Responsibilities Reference:](https://reader035.vdocuments.us/reader035/viewer/2022062223/5a4d1b137f8b9ab0599906cd/html5/thumbnails/19.jpg)
Copyright © Craig Larman. 2000 All Rights Reserved19
Coupling How strongly one element (e.g. class) is connected to,
has knowledge of, or depends on other elements Illustrated as dependency relationship in UML class
diagram
![Page 20: Copyright © Craig Larman. 2000 All Rights Reserved COMP-350 Object-Oriented Analysis and Design GRASP: Designing Objects with Responsibilities Reference:](https://reader035.vdocuments.us/reader035/viewer/2022062223/5a4d1b137f8b9ab0599906cd/html5/thumbnails/20.jpg)
Copyright © Craig Larman. 2000 All Rights Reserved20
CouplingIn object oriented languages, common form of coupling
from TypeX to TypeY include: TypeX has an attribute that refers to a TypeY instance. TypeX has a method which references an instance of
TypeY, by any means. These typically include a parameter or local variable of type TypeY, or the object returned from a message being an instance of TypeY.
TypeX is a direct or indirect subclass of TypeY. TypeY is an interface, and TypeX implements that
interface.
![Page 21: Copyright © Craig Larman. 2000 All Rights Reserved COMP-350 Object-Oriented Analysis and Design GRASP: Designing Objects with Responsibilities Reference:](https://reader035.vdocuments.us/reader035/viewer/2022062223/5a4d1b137f8b9ab0599906cd/html5/thumbnails/21.jpg)
Copyright © Craig Larman. 2000 All Rights Reserved21
Low coupling Classes are easier to maintain Easier to reuse Changes are localised
![Page 22: Copyright © Craig Larman. 2000 All Rights Reserved COMP-350 Object-Oriented Analysis and Design GRASP: Designing Objects with Responsibilities Reference:](https://reader035.vdocuments.us/reader035/viewer/2022062223/5a4d1b137f8b9ab0599906cd/html5/thumbnails/22.jpg)
Copyright © Craig Larman. 2000 All Rights Reserved22
Low Coupling: Example
Who has responsibility to create a payment (and associate with a sale)?
Payment POST Sale
![Page 23: Copyright © Craig Larman. 2000 All Rights Reserved COMP-350 Object-Oriented Analysis and Design GRASP: Designing Objects with Responsibilities Reference:](https://reader035.vdocuments.us/reader035/viewer/2022062223/5a4d1b137f8b9ab0599906cd/html5/thumbnails/23.jpg)
Copyright © Craig Larman. 2000 All Rights Reserved23
Two possibilities:
:POST p : Payment
:Sale
makePayment() 1: create()
2: addPayment(p)
1. Post
2. Sale :POST :Sale
:Payment
makePayment() 1: makePayment()
1.1. create()
Low coupling suggests Sale because Sale has to be coupled to Payment anyway (Sale knows its total).
![Page 24: Copyright © Craig Larman. 2000 All Rights Reserved COMP-350 Object-Oriented Analysis and Design GRASP: Designing Objects with Responsibilities Reference:](https://reader035.vdocuments.us/reader035/viewer/2022062223/5a4d1b137f8b9ab0599906cd/html5/thumbnails/24.jpg)
Copyright © Craig Larman. 2000 All Rights Reserved24
4. Controller Problem
– What object (beyond the UI layer) handles events from external actors
– E.g. startup(), playSongs(), etc? Solution
– Assign the responsibility to an object representing one of these choices
A facade controller which represents the overall system, root object, device or subsystem Example: Jukebox
A use case controller which which represents a use case scenario within which the system operations occurs
Example: makeSaleHandler. makeSaleCoordinator, etc.– These classes often don’t do the work, but delegate it to others.
![Page 25: Copyright © Craig Larman. 2000 All Rights Reserved COMP-350 Object-Oriented Analysis and Design GRASP: Designing Objects with Responsibilities Reference:](https://reader035.vdocuments.us/reader035/viewer/2022062223/5a4d1b137f8b9ab0599906cd/html5/thumbnails/25.jpg)
Copyright © Craig Larman. 2000 All Rights Reserved25
Controller A Controller is a non-user interface object
responsible for receiving or handling a system event.
A Controller defines the method for the system operation.
![Page 26: Copyright © Craig Larman. 2000 All Rights Reserved COMP-350 Object-Oriented Analysis and Design GRASP: Designing Objects with Responsibilities Reference:](https://reader035.vdocuments.us/reader035/viewer/2022062223/5a4d1b137f8b9ab0599906cd/html5/thumbnails/26.jpg)
Copyright © Craig Larman. 2000 All Rights Reserved26
Controller: example
![Page 27: Copyright © Craig Larman. 2000 All Rights Reserved COMP-350 Object-Oriented Analysis and Design GRASP: Designing Objects with Responsibilities Reference:](https://reader035.vdocuments.us/reader035/viewer/2022062223/5a4d1b137f8b9ab0599906cd/html5/thumbnails/27.jpg)
Copyright © Craig Larman. 2000 All Rights Reserved27
Note A common defect in the design of controllers is to
give them too much responsibility Normally, a controller should delegate to other
objects the work that needs to be done; it coordinates or controls the activity. It does not do much work itself.
![Page 28: Copyright © Craig Larman. 2000 All Rights Reserved COMP-350 Object-Oriented Analysis and Design GRASP: Designing Objects with Responsibilities Reference:](https://reader035.vdocuments.us/reader035/viewer/2022062223/5a4d1b137f8b9ab0599906cd/html5/thumbnails/28.jpg)
Copyright © Craig Larman. 2000 All Rights Reserved28
Types of Controllers1. Facade controller2. Use case controller
![Page 29: Copyright © Craig Larman. 2000 All Rights Reserved COMP-350 Object-Oriented Analysis and Design GRASP: Designing Objects with Responsibilities Reference:](https://reader035.vdocuments.us/reader035/viewer/2022062223/5a4d1b137f8b9ab0599906cd/html5/thumbnails/29.jpg)
Copyright © Craig Larman. 2000 All Rights Reserved29
Façade Controller represents the overall system, device, or a
subsystem. a cover, or facade, over the other layers of the
application provides the main point of service calls from the UI
layer down to other layers. could be an abstraction of the overall physical unit,
such as a Register E.g. a class representing the entire software
system, such as POSSystem, ChessGame
![Page 30: Copyright © Craig Larman. 2000 All Rights Reserved COMP-350 Object-Oriented Analysis and Design GRASP: Designing Objects with Responsibilities Reference:](https://reader035.vdocuments.us/reader035/viewer/2022062223/5a4d1b137f8b9ab0599906cd/html5/thumbnails/30.jpg)
Copyright © Craig Larman. 2000 All Rights Reserved30
When to use Façade controller when there are not "too many" system events When it is not possible for the user interface (UI) to
redirect system event messages to alternating controllers
E.g. in a message processing system
![Page 31: Copyright © Craig Larman. 2000 All Rights Reserved COMP-350 Object-Oriented Analysis and Design GRASP: Designing Objects with Responsibilities Reference:](https://reader035.vdocuments.us/reader035/viewer/2022062223/5a4d1b137f8b9ab0599906cd/html5/thumbnails/31.jpg)
Copyright © Craig Larman. 2000 All Rights Reserved31
Use case controllers If a use-case controller is chosen, then there is a
different controller for each use case. Note that this is not a domain object; it is an
artificial construct to support the system For example, if the NextGen POS application
contains use cases such as Process Sale and Handle Returns, then there may be a ProcessSaleHandler class and so forth
![Page 32: Copyright © Craig Larman. 2000 All Rights Reserved COMP-350 Object-Oriented Analysis and Design GRASP: Designing Objects with Responsibilities Reference:](https://reader035.vdocuments.us/reader035/viewer/2022062223/5a4d1b137f8b9ab0599906cd/html5/thumbnails/32.jpg)
Copyright © Craig Larman. 2000 All Rights Reserved32
When to use Use case controller when placing the responsibilities in a facade
controller leads to designs with low cohesion or high coupling
typically when the facade controller is becoming "bloated" with excessive responsibilities.
A use-case controller is a good choice when there are many system events across different processes
it factors their handling into manageable separate classes
provides a basis for knowing and reasoning about the state of the current scenario in progress.
![Page 33: Copyright © Craig Larman. 2000 All Rights Reserved COMP-350 Object-Oriented Analysis and Design GRASP: Designing Objects with Responsibilities Reference:](https://reader035.vdocuments.us/reader035/viewer/2022062223/5a4d1b137f8b9ab0599906cd/html5/thumbnails/33.jpg)
Copyright © Craig Larman. 2000 All Rights Reserved33
Controller: Class Activity
![Page 34: Copyright © Craig Larman. 2000 All Rights Reserved COMP-350 Object-Oriented Analysis and Design GRASP: Designing Objects with Responsibilities Reference:](https://reader035.vdocuments.us/reader035/viewer/2022062223/5a4d1b137f8b9ab0599906cd/html5/thumbnails/34.jpg)
Copyright © Craig Larman. 2000 All Rights Reserved34
By the Controller pattern, here are some choices: 1. Register, POSSystem
– represents the overall "system," device, or subsystem
– Façade controller
2. ProcessSaleHandler, ProcessSaleSession– represents a receiver or handler of all system events
of a use case scenario– Use case controller
![Page 35: Copyright © Craig Larman. 2000 All Rights Reserved COMP-350 Object-Oriented Analysis and Design GRASP: Designing Objects with Responsibilities Reference:](https://reader035.vdocuments.us/reader035/viewer/2022062223/5a4d1b137f8b9ab0599906cd/html5/thumbnails/35.jpg)
Copyright © Craig Larman. 2000 All Rights Reserved35
![Page 36: Copyright © Craig Larman. 2000 All Rights Reserved COMP-350 Object-Oriented Analysis and Design GRASP: Designing Objects with Responsibilities Reference:](https://reader035.vdocuments.us/reader035/viewer/2022062223/5a4d1b137f8b9ab0599906cd/html5/thumbnails/36.jpg)
Copyright © Craig Larman. 2000 All Rights Reserved36
Bloated Controller Poorly designed, a controller class will have low
cohesion- unfocused and handling too many areas of responsibility; this is called a bloated controller.
Signs of bloating include: – only a single controller class receiving all system
events in the system, and there are many of them. – The controller itself performs many of the tasks
necessary to fulfill the system event, without delegating the work.
– A controller has many attributes, and maintains significant information about the system or domain, which should have been distributed to other objects, or duplicates information found elsewhere.
![Page 37: Copyright © Craig Larman. 2000 All Rights Reserved COMP-350 Object-Oriented Analysis and Design GRASP: Designing Objects with Responsibilities Reference:](https://reader035.vdocuments.us/reader035/viewer/2022062223/5a4d1b137f8b9ab0599906cd/html5/thumbnails/37.jpg)
Copyright © Craig Larman. 2000 All Rights Reserved37
Cure to Bloated Controller Add more controllers- system does not have to
have only one. Instead of facade controllers, use use-case controllers.
For example, consider an application with many system events, such as an airline reservation system. It may contain the following controllers:
Design the controller so that it primarily delegates the fulfillment of each system operation responsibility on to other objects.
![Page 38: Copyright © Craig Larman. 2000 All Rights Reserved COMP-350 Object-Oriented Analysis and Design GRASP: Designing Objects with Responsibilities Reference:](https://reader035.vdocuments.us/reader035/viewer/2022062223/5a4d1b137f8b9ab0599906cd/html5/thumbnails/38.jpg)
Copyright © Craig Larman. 2000 All Rights Reserved38
5. High Cohesion Cohesion is a measure of how strongly related the
responsibilities of a class are A class with low cohesion does many unrelated
things. It is hard to understand, hard to reuse, and hard to maintain
A class with high cohesion has a relatively small number of highly-related methods
It collaborates with other objects Modular design
![Page 39: Copyright © Craig Larman. 2000 All Rights Reserved COMP-350 Object-Oriented Analysis and Design GRASP: Designing Objects with Responsibilities Reference:](https://reader035.vdocuments.us/reader035/viewer/2022062223/5a4d1b137f8b9ab0599906cd/html5/thumbnails/39.jpg)
Copyright © Craig Larman. 2000 All Rights Reserved39
Example of Good and Bad Cohesion
![Page 40: Copyright © Craig Larman. 2000 All Rights Reserved COMP-350 Object-Oriented Analysis and Design GRASP: Designing Objects with Responsibilities Reference:](https://reader035.vdocuments.us/reader035/viewer/2022062223/5a4d1b137f8b9ab0599906cd/html5/thumbnails/40.jpg)
Copyright © Craig Larman. 2000 All Rights Reserved40
Cohesion: example Example: for the POS system, when we design for
the makePayment() system operation
Reduces the cohesion of Register.
![Page 41: Copyright © Craig Larman. 2000 All Rights Reserved COMP-350 Object-Oriented Analysis and Design GRASP: Designing Objects with Responsibilities Reference:](https://reader035.vdocuments.us/reader035/viewer/2022062223/5a4d1b137f8b9ab0599906cd/html5/thumbnails/41.jpg)
Copyright © Craig Larman. 2000 All Rights Reserved41
By delegating Payment creation to Sale, we not only decrease coupling, but we also increase the cohesion of Register.
Since Register has fewer responsibilities, it is more cohesive.
![Page 42: Copyright © Craig Larman. 2000 All Rights Reserved COMP-350 Object-Oriented Analysis and Design GRASP: Designing Objects with Responsibilities Reference:](https://reader035.vdocuments.us/reader035/viewer/2022062223/5a4d1b137f8b9ab0599906cd/html5/thumbnails/42.jpg)
Copyright © Craig Larman. 2000 All Rights Reserved42
Wrap-up No ‘magic’ to assigning responsibilities If you don’t have a reason for placing a method in
a class, …it shouldn’t be there!
You should be able to say: ‘I placed method X in class Y based on GRASP Z’