60-322 Object-Oriented Analysis and Design Mar 11, 2008.
-
Upload
brianne-chandler -
Category
Documents
-
view
220 -
download
5
Transcript of 60-322 Object-Oriented Analysis and Design Mar 11, 2008.
![Page 1: 60-322 Object-Oriented Analysis and Design Mar 11, 2008.](https://reader035.fdocuments.us/reader035/viewer/2022062423/56649eb55503460f94bbd8fa/html5/thumbnails/1.jpg)
60-322 Object-Oriented Analysis and Design
Mar 11, 2008
![Page 2: 60-322 Object-Oriented Analysis and Design Mar 11, 2008.](https://reader035.fdocuments.us/reader035/viewer/2022062423/56649eb55503460f94bbd8fa/html5/thumbnails/2.jpg)
2
Applying GRASP to OOD
GRASP stands for General Responsibility Assignment Software Patterns.
The name was chosen to suggest the importance of grasping these principles to successfully design object-oriented software.
Understanding and being able to apply the ideas behind GRASP- while coding or while drawing interaction and class diagrams -enables developers new to object technology needs to master these basic principles as quickly as possible.
They form a foundation for designing OO systems.
![Page 3: 60-322 Object-Oriented Analysis and Design Mar 11, 2008.](https://reader035.fdocuments.us/reader035/viewer/2022062423/56649eb55503460f94bbd8fa/html5/thumbnails/3.jpg)
3
Applying GRASP to OOD
There are nine GRASP patterns:
– Creator– Controller– Pure Fabrication– Information Expert– High Cohesion– Indirection– Low Coupling– Polymorphism– Protected Variations
![Page 4: 60-322 Object-Oriented Analysis and Design Mar 11, 2008.](https://reader035.fdocuments.us/reader035/viewer/2022062423/56649eb55503460f94bbd8fa/html5/thumbnails/4.jpg)
4
Low Coupling
Problem How to support low dependency, low change
impact, and increased reuse?
Coupling is a measure of how strongly one element is connected to, has knowledge of, or relies on other elements.
An element with low (or weak) coupling is not dependent on too many other elements.
![Page 5: 60-322 Object-Oriented Analysis and Design Mar 11, 2008.](https://reader035.fdocuments.us/reader035/viewer/2022062423/56649eb55503460f94bbd8fa/html5/thumbnails/5.jpg)
5
Low Coupling A class with high (or strong) coupling relies on
many other classes. Such classes may be undesirable; some suffer from the following problems:
– Forced local changes because of changes in related classes.
– Harder to understand in isolation.
– Harder to reuse because its use requires the additional presence of the classes on which it is dependent.
![Page 6: 60-322 Object-Oriented Analysis and Design Mar 11, 2008.](https://reader035.fdocuments.us/reader035/viewer/2022062423/56649eb55503460f94bbd8fa/html5/thumbnails/6.jpg)
6
Low Coupling
SolutionAssign a responsibility so that coupling
remains low. Use this principle to evaluate alternatives.
ExampleConsider the following partial class diagram
from a NextGen case study:
![Page 7: 60-322 Object-Oriented Analysis and Design Mar 11, 2008.](https://reader035.fdocuments.us/reader035/viewer/2022062423/56649eb55503460f94bbd8fa/html5/thumbnails/7.jpg)
7
Low Coupling
Assume we need to create a Payment instance and associate it with the Sale. What class should be responsible for this?
Since a Register "records" a Payment in the real-world domain, the Creator pattern suggests Register as a candidate for creating the Payment.
The Register instance could then send an addPayment message to the Sale, passing along the new Payment as a parameter.
A possible partial interaction diagram reflecting this is shown
![Page 8: 60-322 Object-Oriented Analysis and Design Mar 11, 2008.](https://reader035.fdocuments.us/reader035/viewer/2022062423/56649eb55503460f94bbd8fa/html5/thumbnails/8.jpg)
8
Low Coupling
This assignment of responsibilities couples the Register class to knowledge of the Payment class.
: Register p : Payment
:Sale
makePayment() 1: create()
2: addPayment(p)
![Page 9: 60-322 Object-Oriented Analysis and Design Mar 11, 2008.](https://reader035.fdocuments.us/reader035/viewer/2022062423/56649eb55503460f94bbd8fa/html5/thumbnails/9.jpg)
9
Low Coupling
An alternative
: Register :Sale
:Payment
makePayment() 1: makePayment()
1.1. create()
![Page 10: 60-322 Object-Oriented Analysis and Design Mar 11, 2008.](https://reader035.fdocuments.us/reader035/viewer/2022062423/56649eb55503460f94bbd8fa/html5/thumbnails/10.jpg)
10
Low Coupling In both cases we assume the Sale must eventually
be coupled to knowledge of a Payment.
Design 1, in which the Register creates the Payment, adds coupling of Register to Payment;
Design 2, in which the Sale does the creation of a Payment, does not increase the coupling.
Purely from the point of view of coupling, prefer Design 2 because it maintains overall lower coupling.
This example illustrates how two patterns - Low Coupling and Creator- may suggest different solutions.
: Register p : Payment
:Sale
makePayment() 1: create()
2: addPayment(p)
: Register :Sale
:Payment
makePayment() 1: makePayment()
1.1. create()
![Page 11: 60-322 Object-Oriented Analysis and Design Mar 11, 2008.](https://reader035.fdocuments.us/reader035/viewer/2022062423/56649eb55503460f94bbd8fa/html5/thumbnails/11.jpg)
11
Low Coupling
In practice, the level of coupling alone can't be considered in isolation from other principles such as Expert and High Cohesion.
Nevertheless, it is one factor to consider in improving a design.
Discussion Low Coupling is a principle to keep in mind during
all design decisions;
It is an evaluative principle that you apply while evaluating all design decisions.
![Page 12: 60-322 Object-Oriented Analysis and Design Mar 11, 2008.](https://reader035.fdocuments.us/reader035/viewer/2022062423/56649eb55503460f94bbd8fa/html5/thumbnails/12.jpg)
12
Low Coupling
In object-oriented languages such as C++, Java, and C#, common forms of coupling from TypeX to TypeY include the following:– TypeX has an attribute (data member or instance
variable) that refers to a TypeY instance, or TypeY itself.– A TypeX object calls on services of a TypeY object.– TypeX has a method that references an instance of
TypeY, or TypeY itself, 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 13: 60-322 Object-Oriented Analysis and Design Mar 11, 2008.](https://reader035.fdocuments.us/reader035/viewer/2022062423/56649eb55503460f94bbd8fa/html5/thumbnails/13.jpg)
13
Low Coupling
Low Coupling encourages you to assign a responsibility so that its placement does not increase the coupling to a level that leads to the negative results that high coupling can produce.
Low Coupling supports the design of classes that are more independent, which reduces the impact of change.
Contraindication High coupling to stable elements and to pervasive
elements is seldom a problem. – It is not high coupling per se that is the problem; it is high coupling to
elements that are unstable in some dimension, such as their interface, implementation, or mere presence
![Page 14: 60-322 Object-Oriented Analysis and Design Mar 11, 2008.](https://reader035.fdocuments.us/reader035/viewer/2022062423/56649eb55503460f94bbd8fa/html5/thumbnails/14.jpg)
14
Controller
Problem What first object beyond the UI layer receives and
coordinates ("controls") a system operation?
System operations were first explored during the analysis of SSD. These are the major input events upon our system.
A controller is the first object beyond the UI layer that is responsible for receiving or handling a system operation message.
![Page 15: 60-322 Object-Oriented Analysis and Design Mar 11, 2008.](https://reader035.fdocuments.us/reader035/viewer/2022062423/56649eb55503460f94bbd8fa/html5/thumbnails/15.jpg)
15
Controller
Solution Assign the responsibility to a class representing
one of the following choices:
– Represents the overall "system," a "root object," a device that the software is running within, or a major subsystem.
– Represents a use case scenario within which the system event occurs, often named <UseCaseName>Handler, <UseCaseName>Coordinator, or <UseCaseName>Session.
![Page 16: 60-322 Object-Oriented Analysis and Design Mar 11, 2008.](https://reader035.fdocuments.us/reader035/viewer/2022062423/56649eb55503460f94bbd8fa/html5/thumbnails/16.jpg)
16
Controller
The NextGen application contains several system operations, as illustrated in the figure.
This model shows the system itself as a class (which is legal and sometimes useful when modeling).
System
endSale()enterItem()makeNewSale()makePayment(). . .
![Page 17: 60-322 Object-Oriented Analysis and Design Mar 11, 2008.](https://reader035.fdocuments.us/reader035/viewer/2022062423/56649eb55503460f94bbd8fa/html5/thumbnails/17.jpg)
17
ControllerDuring analysis, system operations may be
assigned to the class System in some analysis model, to indicate they are system operations.
However, this does not mean that a software class named System fulfills them during design.
Rather, during design, a controller class is assigned the responsibility for system operations
![Page 18: 60-322 Object-Oriented Analysis and Design Mar 11, 2008.](https://reader035.fdocuments.us/reader035/viewer/2022062423/56649eb55503460f94bbd8fa/html5/thumbnails/18.jpg)
18
Controller
Which class of object should be responsible for receiving this system event message?
It is sometimes called the controller or coordinator. It does not normally do the work, but delegates it to other objects.
The controller is a kind of "facade" onto the domain layer from the interface layer.
actionPerformed( actionEvent )
: ???
: Cashier
:SaleJFrame
presses button
enterItem(itemID, qty)?
UI Layer
Domain Layer
system operation message
Who should be the controller for system events such as enterItem and endSale?
![Page 19: 60-322 Object-Oriented Analysis and Design Mar 11, 2008.](https://reader035.fdocuments.us/reader035/viewer/2022062423/56649eb55503460f94bbd8fa/html5/thumbnails/19.jpg)
19
Controller By the Controller pattern, here are some choices:
– Represents the overall "system," "root object," device, or subsystem. Register, POSSystem
– Represents a receiver or handler of all system events of a use case scenario.
ProcessSaleHandler, ProcessSaleSession
The choice of which of these classes is the most appropriate controller is influenced by other factors, which the following section explores.
:RegisterenterItem(id, quantity)
:ProcessSaleHandlerenterItem(id, quantity)
![Page 20: 60-322 Object-Oriented Analysis and Design Mar 11, 2008.](https://reader035.fdocuments.us/reader035/viewer/2022062423/56649eb55503460f94bbd8fa/html5/thumbnails/20.jpg)
20
Controller During design, the system operations identified
during system behavior analysis are assigned to one or more controller classes, such as Register, as shown in this figure.
Register
...
endSale()enterItem()makeNewSale()makePayment()
makeNewReturn()enterReturnItem(). . .
System
endSale()enterItem()makeNewSale()makePayment()
makeNewReturn()enterReturnItem(). . .
system operations discovered during system behavior analysis
allocation of system operations during design, using one facade controller
ProcessSaleHandler
...
endSale()enterItem()makeNewSale()makePayment()
System
endSale()enterItem()makeNewSale()makePayment()
enterReturnItem()makeNewReturn(). . .
allocation of system operations during design, using several use case controllers
HandleReturnsHandler
...
enterReturnItem()makeNewReturn(). . .
![Page 21: 60-322 Object-Oriented Analysis and Design Mar 11, 2008.](https://reader035.fdocuments.us/reader035/viewer/2022062423/56649eb55503460f94bbd8fa/html5/thumbnails/21.jpg)
21
Controller (in Coding)
![Page 22: 60-322 Object-Oriented Analysis and Design Mar 11, 2008.](https://reader035.fdocuments.us/reader035/viewer/2022062423/56649eb55503460f94bbd8fa/html5/thumbnails/22.jpg)
22
Controller
![Page 23: 60-322 Object-Oriented Analysis and Design Mar 11, 2008.](https://reader035.fdocuments.us/reader035/viewer/2022062423/56649eb55503460f94bbd8fa/html5/thumbnails/23.jpg)
23
Controller
Discussion 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.
The first category of controller is a facade controller representing the overall system, device, or a subsystem.
![Page 24: 60-322 Object-Oriented Analysis and Design Mar 11, 2008.](https://reader035.fdocuments.us/reader035/viewer/2022062423/56649eb55503460f94bbd8fa/html5/thumbnails/24.jpg)
24
Controller The idea is to choose some class name that
suggests a cover, or facade, over the other layers of the application and that provides the main point of service calls from the UI layer down to other layers.
The facade could be – an abstraction of the overall physical unit, such as a
Register, TelecommSwitch, Phone, or Robot; – a class representing the entire software system, such as
POSSystem; or – any other concept which the designer chooses to
represent the overall system or a subsystem, even, for example, ChessGame if it was game software.
![Page 25: 60-322 Object-Oriented Analysis and Design Mar 11, 2008.](https://reader035.fdocuments.us/reader035/viewer/2022062423/56649eb55503460f94bbd8fa/html5/thumbnails/25.jpg)
25
Controller Facade controllers are suitable when there are not
"too many" system events, or when the user interface (UI) cannot redirect system event messages to alternating controllers, such as in a message-processing system.
If you choose a use case controller, then you will have a different controller for each use case. – Note that this kind of controller is not a domain object; it
is an artificial construct to support the system (a Pure Fabrication in terms of the GRASP patterns).
For example, if the NextGen application contains use cases such as Process Sale and Handle Returns, then there may be a ProcessSaleHandler class and so forth
![Page 26: 60-322 Object-Oriented Analysis and Design Mar 11, 2008.](https://reader035.fdocuments.us/reader035/viewer/2022062423/56649eb55503460f94bbd8fa/html5/thumbnails/26.jpg)
26
Controller
When should you choose a use case controller? – Consider it an alternative 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 and also provides a basis for knowing and reasoning about the state of the current scenario in progress.
![Page 27: 60-322 Object-Oriented Analysis and Design Mar 11, 2008.](https://reader035.fdocuments.us/reader035/viewer/2022062423/56649eb55503460f94bbd8fa/html5/thumbnails/27.jpg)
27
Controller
A important corollary of the Controller pattern is that UI objects (for example, window or button objects) and the UI layer should not have responsibility for fulfilling system events.
In other words, system operations should be handled in the application logic or domain layers of objects rather than in the UI layer of a system.
![Page 28: 60-322 Object-Oriented Analysis and Design Mar 11, 2008.](https://reader035.fdocuments.us/reader035/viewer/2022062423/56649eb55503460f94bbd8fa/html5/thumbnails/28.jpg)
28
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 are:
– There is only a single controller class receiving all system events in the system, and there are many of them. This sometimes happens if a facade controller is chosen.
– The controller itself performs many of the tasks necessary to fulfill the system event, without delegating the work. This usually involves a violation of Information Expert and High Cohesion.
– A controller has many attributes, and it maintains significant information about the system or domain, which should have been distributed to other objects, or it duplicates information found elsewhere.
![Page 29: 60-322 Object-Oriented Analysis and Design Mar 11, 2008.](https://reader035.fdocuments.us/reader035/viewer/2022062423/56649eb55503460f94bbd8fa/html5/thumbnails/29.jpg)
29
Bloated Controller
Among the cures for a bloated controller are these two:– Add more controllers - a system does not have to need
only one. Instead of facade controllers, employ 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 to other objects.
![Page 30: 60-322 Object-Oriented Analysis and Design Mar 11, 2008.](https://reader035.fdocuments.us/reader035/viewer/2022062423/56649eb55503460f94bbd8fa/html5/thumbnails/30.jpg)
30
UI Layer Does Not Handle System Events
To reiterate: An important corollary of the Controller pattern is that UI objects (for example, window objects) and the UI layer should not have responsibility for handling system events.
– As an example, consider a design in Java that uses a JFrame to display the information.
![Page 31: 60-322 Object-Oriented Analysis and Design Mar 11, 2008.](https://reader035.fdocuments.us/reader035/viewer/2022062423/56649eb55503460f94bbd8fa/html5/thumbnails/31.jpg)
31
UI Layer Does Not Handle System Events
actionPerformed( actionEvent )
:Register
: Cashier
:SaleJFrame
presses button
1: enterItem(itemID, qty)?
:Sale1.1: makeLineItem(itemID, qty)
UI Layer
Domain Layer
system operation message
controller
![Page 32: 60-322 Object-Oriented Analysis and Design Mar 11, 2008.](https://reader035.fdocuments.us/reader035/viewer/2022062423/56649eb55503460f94bbd8fa/html5/thumbnails/32.jpg)
32
UI Layer Does Not Handle System Events
Cashier
:SaleJFrame
actionPerformed( actionEvent )
:Sale1: makeLineItem(itemID, qty)
UI Layer
Domain Layer
It is undesirable for an interfacelayer object such as a window to get involved in deciding how to handle domain processes.
Business logic is embedded in the presentation layer, which is not useful.
SaleJFrame should not send this message.
presses button
![Page 33: 60-322 Object-Oriented Analysis and Design Mar 11, 2008.](https://reader035.fdocuments.us/reader035/viewer/2022062423/56649eb55503460f94bbd8fa/html5/thumbnails/33.jpg)
33
There are nine GRASP patterns:
– Creator– Controller– Pure Fabrication– Information Expert– High Cohesion– Indirection– Low Coupling– Polymorphism– Protected Variations
![Page 34: 60-322 Object-Oriented Analysis and Design Mar 11, 2008.](https://reader035.fdocuments.us/reader035/viewer/2022062423/56649eb55503460f94bbd8fa/html5/thumbnails/34.jpg)
34
High Cohesion
Problem How to keep objects focused, understandable, and
manageable, and as a side effect, support Low Coupling?
In terms of object design, cohesion (or more specifically, functional cohesion) is a measure of how strongly related and focused the responsibilities of an element are.
An element with highly related responsibilities that does not do a tremendous amount of work has high cohesion. (These elements include classes, subsystems, and so on.)
![Page 35: 60-322 Object-Oriented Analysis and Design Mar 11, 2008.](https://reader035.fdocuments.us/reader035/viewer/2022062423/56649eb55503460f94bbd8fa/html5/thumbnails/35.jpg)
35
High Cohesion
Solution Assign a responsibility so that cohesion remains
high. Use this to evaluate alternatives.
A class with low cohesion does many unrelated things or does too much work. Such classes are undesirable; they suffer from the following problems:– hard to comprehend– hard to reuse– hard to maintain– delicate; constantly affected by change
![Page 36: 60-322 Object-Oriented Analysis and Design Mar 11, 2008.](https://reader035.fdocuments.us/reader035/viewer/2022062423/56649eb55503460f94bbd8fa/html5/thumbnails/36.jpg)
36
High CohesionExample Let's take another look at the example problem used
in the Low Coupling pattern and analyze it for High Cohesion.
Assume we have a need to create a (cash) Payment instance and associate it with the Sale.
What class should be responsible for this? Since Register records a Payment in the real-world
domain, the Creator pattern suggests Register as a candidate for creating the Payment.
The Register instance could then send an addPayment message to the Sale, passing along the new Payment as a parameter
![Page 37: 60-322 Object-Oriented Analysis and Design Mar 11, 2008.](https://reader035.fdocuments.us/reader035/viewer/2022062423/56649eb55503460f94bbd8fa/html5/thumbnails/37.jpg)
37
High Cohesion
: Register : Sale
addPayment( p )
p : Paymentcreate()makePayment()
This assignment of responsibilities places the responsibility for making a payment in the Register.
The Register is taking on part of the responsibility for fulfilling the makePayment system operation.
In this isolated example, this is acceptable; but if we continue to make the Register class responsible for doing some or most of the work related to more and more system operations, it will become increasingly burdened with tasks and become incohesive.
Imagine fifty system operations, all received by Register. If Register did the work related to each, it would become a "bloated" incohesive object.
The point is not that this single Payment creation task in itself makes the Register incohesive, but as part of a larger picture of overall responsibility assignment, it may suggest a trend toward low cohesion.
![Page 38: 60-322 Object-Oriented Analysis and Design Mar 11, 2008.](https://reader035.fdocuments.us/reader035/viewer/2022062423/56649eb55503460f94bbd8fa/html5/thumbnails/38.jpg)
38
High Cohesion
: Register : Sale
makePayment()
: Paymentcreate()
makePayment()
This design delegates the payment creation responsibility to the Sale supports higher cohesion in the Register.
It supports both high cohesion and low coupling, it is desirable.
In practice, the level of cohesion alone can't be considered in isolation from other responsibilities and other principles such as Expert and Low Coupling.
![Page 39: 60-322 Object-Oriented Analysis and Design Mar 11, 2008.](https://reader035.fdocuments.us/reader035/viewer/2022062423/56649eb55503460f94bbd8fa/html5/thumbnails/39.jpg)
39
High Cohesion
Discussion Like Low Coupling, High Cohesion is a principle to
keep in mind during all design decisions; it is an underlying goal to continually consider.
It is an evaluative principle that a designer applies while evaluating all design decisions.
High functional cohesion exists when the elements of a component (such as a class) "all work together to provide some well-bounded behavior”.
![Page 40: 60-322 Object-Oriented Analysis and Design Mar 11, 2008.](https://reader035.fdocuments.us/reader035/viewer/2022062423/56649eb55503460f94bbd8fa/html5/thumbnails/40.jpg)
40
High Cohesion
Here are some scenarios that illustrate varying degrees of functional cohesion: – Very low cohesion
A class is solely responsible for many things in very different functional areas.
– Low cohesion A class has sole responsibility for a complex task in one
functional area.
– High cohesion A class has moderate responsibilities in one functional area and
collaborates with other classes to fulfill tasks.
– Moderate cohesion A class has lightweight and sole responsibilities in a few different
areas that are logically related to the class concept but not to each other.
![Page 41: 60-322 Object-Oriented Analysis and Design Mar 11, 2008.](https://reader035.fdocuments.us/reader035/viewer/2022062423/56649eb55503460f94bbd8fa/html5/thumbnails/41.jpg)
41
High Cohesion
Rule of thumb: a class with high cohesion has a relatively small number of methods, with highly related functionality, and does not do too much work. It collaborates with other objects to share the effort if the task is large.
A class with high cohesion is advantageous because it is relatively easy to maintain, understand, and reuse.
The high degree of related functionality, combined with a small number of operations, also simplifies maintenance and enhancements. The fine grain of highly related functionality also supports increased reuse potential.
![Page 42: 60-322 Object-Oriented Analysis and Design Mar 11, 2008.](https://reader035.fdocuments.us/reader035/viewer/2022062423/56649eb55503460f94bbd8fa/html5/thumbnails/42.jpg)
42
High Cohesion
The High Cohesion pattern - like many things in object technology - has a real-world analogy.
It is a common observation that if a person takes on too many unrelated responsibilities - especially ones that should properly be delegated to others - then the person is not effective.
![Page 43: 60-322 Object-Oriented Analysis and Design Mar 11, 2008.](https://reader035.fdocuments.us/reader035/viewer/2022062423/56649eb55503460f94bbd8fa/html5/thumbnails/43.jpg)
43
Modular Design
Coupling and cohesion are not new.
They are old principles in software design.
Another old principle which is strongly related to coupling and cohesion is to promote modular design.
Modularity is the property of a system that has been decomposed into a set of cohesive and loosely coupled modules
![Page 44: 60-322 Object-Oriented Analysis and Design Mar 11, 2008.](https://reader035.fdocuments.us/reader035/viewer/2022062423/56649eb55503460f94bbd8fa/html5/thumbnails/44.jpg)
44
Modular Design
OO Design promotes a modular design by creating methods and classes with high cohesion.
At the basic object level, we achieve modularity by designing each method with a clear, single purpose and by grouping a related set of concerns into a class.
![Page 45: 60-322 Object-Oriented Analysis and Design Mar 11, 2008.](https://reader035.fdocuments.us/reader035/viewer/2022062423/56649eb55503460f94bbd8fa/html5/thumbnails/45.jpg)
45
Ch 18. Object Design Examples With Grasp
Objectives Design use case realizations.
Apply GRASP to assign responsibilities to classes.
Apply UML to illustrate and think through the design of objects.
![Page 46: 60-322 Object-Oriented Analysis and Design Mar 11, 2008.](https://reader035.fdocuments.us/reader035/viewer/2022062423/56649eb55503460f94bbd8fa/html5/thumbnails/46.jpg)
46
Ch 18. Object Design Examples With Grasp
We are not repeating what we did in Ch 17.
This chapter applies OO design principles and the UML to the case studies, to show larger examples of reasonably designed objects with responsibilities and collaborations.
![Page 47: 60-322 Object-Oriented Analysis and Design Mar 11, 2008.](https://reader035.fdocuments.us/reader035/viewer/2022062423/56649eb55503460f94bbd8fa/html5/thumbnails/47.jpg)
47
Ch 18. Object Design Examples With Grasp
The last chapter on basic OO design principles looked at little fragments of design problems.
In contrast, this chapter demonstrates the larger picture of designing the domain objects for an entire use case scenario.
We will see larger-scale collaborations and more complex UML diagrams.
![Page 48: 60-322 Object-Oriented Analysis and Design Mar 11, 2008.](https://reader035.fdocuments.us/reader035/viewer/2022062423/56649eb55503460f94bbd8fa/html5/thumbnails/48.jpg)
48
Ch 18. Object Design Examples With Grasp
Please note that the GRASP patterns by name are not important; they're just a learning aid that helps us think methodically about basic OO design.
Key Point
The assignment of responsibilities and design of collaborations are very important and creative steps during design, both while diagraming and while coding.
![Page 49: 60-322 Object-Oriented Analysis and Design Mar 11, 2008.](https://reader035.fdocuments.us/reader035/viewer/2022062423/56649eb55503460f94bbd8fa/html5/thumbnails/49.jpg)
49
Ch 18. Object Design Examples With Grasp
We will learn through detailed explanations of how an OO developer might reason while designing by principles.
In fact, over a short time of practice, these principles become ingrained, and some of the decision-making happens almost at a subconscious level.
No "magic" is needed in object design, no unjustifiable decisions are necessary - assignment of responsibilities and the choice of collaborations can be rationally explained and learned.
OO software design really can be more science than art, though there is plenty of room for creativity and elegant design.
![Page 50: 60-322 Object-Oriented Analysis and Design Mar 11, 2008.](https://reader035.fdocuments.us/reader035/viewer/2022062423/56649eb55503460f94bbd8fa/html5/thumbnails/50.jpg)
50
Ch 18. Object Design Examples With Grasp
Objectives– Design use case realizations.
Let us talk about use case realization first.
A use-case realization describes how a particular use case is realized within the Design Model, in terms of collaborating objects.
![Page 51: 60-322 Object-Oriented Analysis and Design Mar 11, 2008.](https://reader035.fdocuments.us/reader035/viewer/2022062423/56649eb55503460f94bbd8fa/html5/thumbnails/51.jpg)
51
Ch 18. Object Design Examples With Grasp
More precisely, a designer can describe the design of one or more scenarios of a use case; each of these is called a use case realization (though non-standard, perhaps better called a scenario realization).
Use case realization is a UP term used to remind us of the connection between the requirements expressed as use cases and the object design that satisfies the requirements.
![Page 52: 60-322 Object-Oriented Analysis and Design Mar 11, 2008.](https://reader035.fdocuments.us/reader035/viewer/2022062423/56649eb55503460f94bbd8fa/html5/thumbnails/52.jpg)
52
Ch 18. Object Design Examples With Grasp
Operation: enterItem(…)
Post-conditions:- . . .
Operation Contracts
Sale
date. . .
SalesLineItem
quantity
1..*1 . . .
. . .
Domain Model
Use-Case Model
Design Model: Register
enterItem(itemID, quantity)
: ProductCatalog
d = getProductDescription(itemID)
addLineItem( d, quantity )
: Sale
Require-ments
Business Modeling
Design
Sample UP Artifact Relationships
: System
enterItem(id, quantity)
Use Case Text
System Sequence Diagrams
makeNewSale()
system events
Cashier
Process Sale
: Cashier
use case
names
system operations
Use Case Diagram
SupplementarySpecification
Glossary
starting events to design for, and detailed post-condition to satisfy
Process Sale
1. Customer arrives ...2. ...3. Cashier enters item identifier.
inspiration for names of some software domain objects
functional requirements that must be realized by the objects
ideas for the post-conditions
Register
...
makeNewSale()enterItem(...)...
ProductCatalog
...
getProductDescription(...)...
1*
non-functional requirements
domain rules
item details, formats, validation
![Page 53: 60-322 Object-Oriented Analysis and Design Mar 11, 2008.](https://reader035.fdocuments.us/reader035/viewer/2022062423/56649eb55503460f94bbd8fa/html5/thumbnails/53.jpg)
53
Ch 18. Object Design Examples With Grasp
Some relevant artifact-influence points include the following:– The use case suggests the system operations that are
shown in SSDs.– The system operations become the starting messages
entering the Controllers for domain layer interaction diagrams. See Figure on next slide.
This is a key point often missed by those new to OOA/D modeling.
Domain layer interaction diagrams illustrate how objects interact to fulfill the required tasks - the use case realization.
![Page 54: 60-322 Object-Oriented Analysis and Design Mar 11, 2008.](https://reader035.fdocuments.us/reader035/viewer/2022062423/56649eb55503460f94bbd8fa/html5/thumbnails/54.jpg)
54
Ch 18. Object Design Examples With Grasp
:RegisterenterItem
:RegisterendSale
:RegistermakePayment
1: ???
1: ???
1: ???
:RegistermakeNewSale 1: ???
makeNewSale, etc., are the system operations from the SSD
each major interaction diagram starts with a system operation going into a domain layer controller object, such as Register
DOMAIN LAYERUI LAYER
Window objects or
GUI widget objectsor
Web control objects
. . .
![Page 55: 60-322 Object-Oriented Analysis and Design Mar 11, 2008.](https://reader035.fdocuments.us/reader035/viewer/2022062423/56649eb55503460f94bbd8fa/html5/thumbnails/55.jpg)
55
Ch 18. Artifact Comments
SSDs, System Operations, Interaction Diagrams, and Use Case Realizations.
In the current NextGen POS iteration we are considering scenarios and system operations identified on the SSDs of the Process Sale use case:– makeNewSale– enterItem– endSale– makePayment