Upload
erik-rose
View
221
Download
0
Tags:
Embed Size (px)
Citation preview
1
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.
2
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.
3
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.
4
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.
5
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.
6
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.
7
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.
8
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
9
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.
10
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
. . .
11
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
12
Ch 18. Artifact Comments
: Cashier :System
Simple cash-only Process Sale scenario:
1. Customer arrives at a POS checkout with goods and/or services to purchase.2. Cashier starts a new sale.3. Cashier enters item identifier.4. System records sale line item and presents item description, price, and running total. Cashier repeats steps 3-4 until indicates done.5. System presents total with taxes calculated.6. Cashier tells Customer the total, and asks for payment.7. Customer pays and System handles payment....
enterItem(itemID, quantity)
endSale
makePayment(amount)
description, total
total with taxes
change due, receipt
makeNewSale
[ more items ]loop
Process Sale Scenario
13
Ch 18. Artifact Comments
If we use communication diagrams to illustrate the use case realizations, we will draw a different communication diagram to show the handling of each system operation message.
Of course, the same is true for sequence diagrams.
14
Ch 18. Artifact Comments
: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
. . .
15
Ch 18. Artifact Comments
: Register
: Sale
makeNewSalecreate
: Register
enterItem(...)
: ProductCatalog
desc = getProductDesc( itemID )
. . .
UI LAYER
Window objects or
GUI widget objectsor
Web control objects
. . .
DOMAIN LAYER
16
Ch 18. Artifact Comments
Use Cases and Use Case Realizations Naturally, use cases are a prime input to use case
realizations.
The use case text and related requirements expressed in the Supplementary Specifications, Glossary, UI prototypes, report prototypes, and so forth, all inform developers what needs to be built.
But bear in mind that written requirements are imperfect - often very imperfect.
17
Ch 18. Artifact Comments
Operation Contracts and Use Case Realizations
use case realizations could be designed directly from the use case text or from one's domain knowledge.
For some complex system operations, contracts may have been written that add more analysis detail. For example
19
Ch 18. Artifact Comments
In conjunction with contemplating the use case text, for each contract, we work through the postcondition state changes and design message interactions to satisfy the requirements.
1: makeLineItem(...)enterItem(id, qty)
1.1: create(...)
:Register :Sale
:SalesLineItem
20
Ch 18. Artifact Comments
The Domain Model and Use Case Realizations The Domain Model inspires some of the software
objects, such as a Sale conceptual class and Sale software class.
The existing Domain Model - as with all analysis artifacts - won't be perfect; you should expect errors and omissions.
You will discover new concepts that were previously missed, ignore concepts that were previously identified, and do likewise with associations and attributes.
21
Ch 18. What’s Next?
The remainder of this chapter is organized as follows:
A relatively detailed discussion of the design of the NextGen POS.
Likewise, for the Monopoly case study.
Applying UML and patterns to these case studies, let's get into the details…
22
Ch 18. Use Case Realization for NextGen POS
: Cashier :System
Simple cash-only Process Sale scenario:
1. Customer arrives at a POS checkout with goods and/or services to purchase.2. Cashier starts a new sale.3. Cashier enters item identifier.4. System records sale line item and presents item description, price, and running total. Cashier repeats steps 3-4 until indicates done.5. System presents total with taxes calculated.6. Cashier tells Customer the total, and asks for payment.7. Customer pays and System handles payment....
enterItem(itemID, quantity)
endSale
makePayment(amount)
description, total
total with taxes
change due, receipt
makeNewSale
[ more items ]loop
Process Sale Scenario
23
Ch 18. Use Case Realization for NextGen POS
Register
id
ItemStore
nameaddress
Sale
dateTime/ total
CashPayment
amountTendered
SalesLineItem
quantity
Cashier
id
Customer
ProductCatalog
ProductDescription
itemIDdescriptionprice
Stocks
*
Houses
1..*
Used-by
*
Contains
1..*
Describes
*
Captured-on
Contained-in
1..*
Records-sale-of
0..1
Paid-by Is-for
Logs-completed
*
Works-on
1
1
1
1 1..*
1
1
1
1
1
1
1
0..1 1
1
Ledger
Records-accounts-
for
1
1
24
Ch 18. How to Design makeNewSale?
The makeNewSale system operation occurs when a cashier initiates a request to start a new sale, after a customer has arrived with things to buy.
The use case may have been sufficient to decide what was necessary, but for this case study we wrote contracts for all the system operations, to demonstrate the approach.
26
Ch 18. How to Design makeNewSale?
The first design choice. CHOOSE THE CONTROLLER CLASS
By the Controller pattern, here are some choices:
Represents the overall "system," "root object," a specialized device, or a major subsystem.
Represents a receiver or handler of all system events of a use case scenario.
27
Ch 18. How to Design makeNewSale?
If the first choice– Store a kind of root object because we think of
most of the other domain objects as "within" the Store.
– Register a specialized device that the software runs on; also called a POSTerminal.
– POSSystem a name suggesting the overall system
If the second choice– ProcessSaleHandler constructed from the pattern
<use-case-name> "Handler" or "Session"– ProcessSaleSession
28
Ch 18. How to Design makeNewSale?
Choosing a device-object facade controller like Register is satisfactory if there are only a few system operations and if the facade controller is not taking on too many responsibilities (in other words, if it is not becoming incohesive).
Choosing a use case controller is suitable when we have many system operations and we wish to distribute responsibilities in order to keep each controller class lightweight and focused (in other words, cohesive).
In this case, Register suffices since there are only a few system operations.
29
Ch 18. How to Design makeNewSale? Based on the Controller pattern, the interaction
diagram shown below begins by sending the system operation makeNewSale message to a Register software object.
:Register
makeNewSale
:Salecreate
31
Ch 18. Creating a New Sale How to Design makeNewSale?
The GRASP Creator pattern suggests assigning the responsibility for creation to a class that aggregates, contains, or records the object to be created.
Look at the domain model on page 22. It reveals that a Register may be thought of as
recording a Sale; – indeed, the word "register" in business has for hundreds of years
meant the thing that recorded (or registered) account transactions, such as sales.
Thus, Register is a reasonable candidate for
creating a Sale.
32
Ch 18. Creating a New Sale How to Design makeNewSale?
By having the Register create the Sale, we can easily associate the Register with it over time so that during future operations within the session, the Register will have a reference to the current Sale instance.
In addition to the above, when the Sale is created, it must create an empty collection (such as a Java List) to record all the future SalesLineItem instances that will be added.
This collection will be contained within and maintained by the Sale instance, which implies by Creator that the Sale is a good candidate for creating the collection.
33
Ch 18. Creating a New Sale How to Design makeNewSale?
:Register
makeNewSale
:Salecreate
Register creates a Sale by Creator
create lineItems :List<SalesLineItem>
by Creator, Sale creates an empty collection (such as a List) which will eventually hold SalesLineItem instances
by Creator and Controller
this execution specification is implied to be within the constructor of the Sale instance
34
Ch 18. How to Design makeNewSale?
The design was not difficult, but the point of its careful explanation in terms of Controller and Creator was to illustrate that the details of a design can be rationally and methodically decided and explained in terms of principles and patterns, such as GRASP.
35
Ch 18. Use Case Realization for NextGen POS
: Cashier :System
Simple cash-only Process Sale scenario:
1. Customer arrives at a POS checkout with goods and/or services to purchase.2. Cashier starts a new sale.3. Cashier enters item identifier.4. System records sale line item and presents item description, price, and running total. Cashier repeats steps 3-4 until indicates done.5. System presents total with taxes calculated.6. Cashier tells Customer the total, and asks for payment.7. Customer pays and System handles payment....
enterItem(itemID, quantity)
endSale
makePayment(amount)
description, total
total with taxes
change due, receipt
makeNewSale
[ more items ]loop
Process Sale Scenario
36
Ch 18. How to Design enterItem?
The enterItem system operation occurs when a cashier enters the itemID and (optionally) the quantity of something to be purchased.
37
Ch 18. How to Design enterItem?
The first design choice - Who is controller? Based on the Controller pattern, as for
makeNewSale, we will continue to use Register as a controller.
38
Creating a New SalesLineItem - How to Design enterItem?
Look at the domain model,
Register
id
ItemStore
nameaddress
Sale
dateTime/ total
CashPayment
amountTendered
SalesLineItem
quantity
Cashier
id
Customer
ProductCatalog
ProductDescription
itemIDdescriptionprice
Stocks
*
Houses
1..*
Used-by
*
Contains
1..*
Describes
*
Captured-on
Contained-in
1..*
Records-sale-of
0..1
Paid-by Is-for
Logs-completed
*
Works-on
1
1
1
1 1..*
1
1
1
1
1
1
1
0..1 1
1
Ledger
Records-accounts-
for
1
1
39
Creating a New SalesLineItem - How to Design enterItem?
A Sale contains SalesLineItem objects.
Taking inspiration from the domain, we determine that a software Sale may similarly contain software SalesLineItem.
Hence, by Creator, a software Sale is an appropriate candidate to create a SalesLineItem.
40
Creating a New SalesLineItem - How to Design enterItem?
We can associate the Sale with the newly created SalesLineItem by storing the new instance in its collection of line items.
Also the postconditions indicate that the new SalesLineItem needs a quantity when created;
41
Creating a New SalesLineItem - How to Design enterItem?
Therefore, the Register must pass it along to the Sale, which must pass it along as a parameter in the create message.
– In Java, that would be implemented as a constructor call with a parameter.
42
Creating a New SalesLineItem - How to Design enterItem?
To summary, by Creator, a makeLineItem message is sent to a Sale for it to create a SalesLineItem.
The Sale creates a SalesLineItem, and then stores the new instance in its permanent collection.
The parameters to the makeLineItem message include the quantity, so that the SalesLineItem can record it,
and the ProductDescription that matches the itemID.
43
Creating a New SalesLineItem - How to Design enterItem?
The ProductDescription that matches the itemID.
Why bother with ProductDescription? Two reasons (1):
44
Creating a New SalesLineItem - How to Design enterItem?
Two reasons (2):
: Cashier :System
Simple cash-only Process Sale scenario:
1. Customer arrives at a POS checkout with goods and/or services to purchase.2. Cashier starts a new sale.3. Cashier enters item identifier.4. System records sale line item and presents item description, price, and running total. Cashier repeats steps 3-4 until indicates done.5. System presents total with taxes calculated.6. Cashier tells Customer the total, and asks for payment.7. Customer pays and System handles payment....
enterItem(itemID, quantity)
endSale
makePayment(amount)
description, total
total with taxes
change due, receipt
makeNewSale
[ more items ]loop
Process Sale Scenario
45
Creating a New SalesLineItem - How to Design enterItem?
Display Item Description and Price?
Because of a principle of Model-View Separation, it is not the responsibility of non-GUI objects (such as a Register or Sale) to get involved in output tasks.
Therefore, although the use case states that the description and price are displayed after this operation, we ignore the design at this time.
All that is required with respect to responsibilities for the display of information is that the information is known, which it is in this case.
46
Finding a ProductDescription - How to Design enterItem?
The SalesLineItem needs to be associated with the ProductDescription that matches the incoming itemID.
This implies that we must retrieve a Product-Description, based on an itemID match.
Before considering how to achieve the lookup, we want to consider who should be responsible for it. Thus, a first step is:
Start assigning responsibilities by clearly stating the responsibility.
47
Finding a ProductDescription - How to Design enterItem?
To restate the problem:
Who should be responsible for knowing a ProductDescription, based on an itemID match?
This is neither a creation problem nor one of choosing a controller for a system event. It is about Information Expert.
48
Finding a ProductDescription - How to Design enterItem?
Register
id
ItemStore
nameaddress
Sale
dateTime/ total
CashPayment
amountTendered
SalesLineItem
quantity
Cashier
id
Customer
ProductCatalog
ProductDescription
itemIDdescriptionprice
Stocks
*
Houses
1..*
Used-by
*
Contains
1..*
Describes
*
Captured-on
Contained-in
1..*
Records-sale-of
0..1
Paid-by Is-for
Logs-completed
*
Works-on
1
1
1
1 1..*
1
1
1
1
1
1
1
0..1 1
1
Ledger
Records-accounts-
for
1
1
49
Finding a ProductDescription - How to Design enterItem?
Analyzing the Domain Model reveals that the ProductCatalog logically contains all the ProductDescriptions.
Taking inspiration from the domain, we design software classes with similar organization: a software ProductCatalog will contain software ProductDescriptions.
50
Finding a ProductDescription - How to Design enterItem?
Then by Information Expert, ProductCatalog is a good candidate for this lookup responsibility since it knows all the ProductDescription objects.
– The lookup can be implemented, for example, with a method called getProductDescription (abbreviated as getProductDesc in some of the diagrams).
Who should send the getProductDescription message to the ProductCatalog to ask for a ProductDescription? (Register?Sales? SaleLineItem?...)
Some reasonable assumptions have to be made…
51
Finding a ProductDescription - How to Design enterItem?
It is reasonable to assume that a long-life Register and a ProductCatalog instance were created when the application is first executed.
And that the Register object is permanently connected to the ProductCatalog object.
With that assumption (which we might record on a task list of things to ensure in the design when we get to designing the initialization),
We know that the Register can send the getProductDescription message to the ProductCatalog.
52
Finding a ProductDescription - How to Design enterItem?
This implies another concept in object design: visibility.
Visibility is the ability of one object to "see" or have a reference to another object. (Ch 19)
For an object to send a message to another object, it must have visibility to it.
Since we assume that the Register has a permanent connection or reference to the ProductCatalog, it has visibility to it, and hence can send it messages such as getProductDescription.
53
The Final Design - How to Design enterItem?
2: makeLineItem(desc, qty)enterItem(id, qty)
1: desc = getProductDesc(id) 2.1: create(desc, qty)
1.1: desc = get(id)
:Register :Sale
:ProductCatalog
sl: SalesLineItem
lineItems : List<SalesLineItem>
: Map<ProductDescription>
2.2: add(sl)
by Expert
by Controllerby Creator
add the newly created SalesLineItem instance to the List
54
The Final Design - How to Design enterItem?
SalesLineItem
quantity : Integer
...
ProductCatalog
...
getProductDesc(...)
ProductDescription
description : Textprice : MoneyitemID: ItemID
...
1..*
1..*
Register
...
enterItem(...)...
Sale
isComplete : Booleantime : DateTime
makeLineItem(...)...1
1
1
catalog
currentSale
descriptions{Map}
lineItems{ordered}
description