1
Object-Oriented Analysis and DesignCHAPTERS 9, 31: DOMAIN MODELS
2
What will we learn?Refining the Domain Model
3
Refining Domain Models: Super and Sub Classes
Recall that once the initial Domain Model has been created, it may be enhanced in future iterations as more details are added to use cases, or our understanding of the system under development increases
Early iterations tend to be high level, but more details are added in later
We saw that as use case scenarios are extended, it may make sense to collect several conceptual classes together to form a super-class, with individual sub-classes
A conceptual super-class definition is more general or encompassing than a subclass definition
All members of a conceptual subclass set are members of their superclass set
4
Super- and Sub-Classes
CashPayment
CreditPayment
CheckPayment
Payment
amount : Money
Payment
CashPayment CreditPayment CheckPayment
5
Super and Sub ClassesAll statements about the super-class apply to any sub-classes; in other words, 100% of the super-class definition applies to the sub-class
The sub-class must conform to the attributes and associations of the super-classA Credit Payment pays-for a Sale. A Check Payment has an amount
CashPayment
CreditPayment
CheckPayment
Payment
amount : MoneySalePays-for
11
6
Refining Domain Models: Super and Sub Classes
Can think of the “sub-class as being a kind of super-class”A Credit Payment is a kind of PaymentOften shortened to: A Credit Payment is a Payment
All members of the sub-class set must be members of the super-class set, i.e. sub-class x is a super-class y
We can identify sub-classes by these two rulesThe 100% rule – all members of the sub-class must be a member of the super-classThe “is a” rule – the sub-class is a kind of super-class
Any sub-class of a super-class must obey these rules
7
Sub-Classes: When to DefineOccasionally a super-class is created to capture similar sub-classes, but usually the process works the other way: A more general super-class has been defined, and as the iterations proceed, sub-classes are created to handle more detailed scenarios
Guidelines: Create a sub-class when …The class under consideration “is a” kind of an existing super-classThe class under consideration has additional attributes of interestThe class under consideration has additional associations of interestThe class under consideration is operated on, handled, reacted to, or manipulated differently than the super-class (or other subclasses)The class under consideration represents an actor that behaves differently than the super-class or other sub-classes
8
Super- and Sub-Classes: When to Create
Bad example:
MaleCustomer
FemaleCustomer
Customer Correct subclasses.
But useful?
When would this make sense? Market research model, where there are behaviors of male and female shoppers that are different Medical research, since men and women are different biologically
9
Super-Classes: When to DefineThis may occur when common traits are identified among various conceptual classes in the Domain Model
Create a super-class when:The potential sub-classes appear to be variations of the same conceptAll the potential sub-classes will conform to the “is a” rule for the new super-classA set of common attributes that belong to all the potential sub-classes is identified and can be factored outA set of common associations that all potential sub-classes have has been identified and can be factored out
10
Example: Payment Sub-Classes
CashPayment
CreditPayment
CheckPayment
Payment
amount : Money
Check
Identifies-credit-with Paid-with*
each payment subclass is handled differently
additional associations
superclass justified by common attributes and associations
SalePays-for
CreditCard
1
1
1 1
11
CreditAuthorization
Service
CheckAuthorization
Service
CheckPayment
AuthorizationService
addressnamephoneNumber
additional associations
superclass justified by common attributes and associations
StoreAuthorizes-payments-of *
Authorizes
CreditPayment
Authorizes
**
*
1 1
12
Domain Models: Levels of GranularityAs the Domain Model evolves, the question will arise: What level of detail to go to? How many sub-classes?
Depends on the system being modeled – remember, the Domain Model is a tool to help understand the system
Note that system transactions (request – reply) are usually modeled, because other activities and processes depend upon them
But it is not always necessary to define sub-classes for every transaction
General rule: don’t add complexity unless needed!
13
CreditPaymentApproval
Reply
CheckPaymentApproval
Reply
CreditPaymentApprovalRequest
CheckPaymentApprovalRequest
CreditPaymentDenialReply
CheckPaymentDenialReply
CheckPaymentAuthorization
Reply
CreditPaymentAuthorization
Reply
PaymentAuthorization
Reply
PaymentAuthorizationRequest
PaymentAuthorizationTransaction
datetime
Concepts too fine grained?Useful to show this degree of partitioning?
Each transaction is handled differently, so it is useful to partition them into discrete classes.
14
CreditPaymentApprovalRequest
CheckPaymentApprovalRequest
PaymentAuthorization
Reply
PaymentAuthorizationRequest
PaymentAuthorizationTransaction
datetime
CreditPaymentApproval
Reply
CheckPaymentApproval
Reply
CreditPaymentDenialReply
CheckPaymentDenialReply
15
Abstract Conceptual ClassesRecall that when we were developing use cases, we saw that it may be useful to collect a series of steps that occurs in several use cases and define an abstract use case that the other use cases could refer to
We can do something similar for conceptual classes: If every member of a class C is a sub-class of C, then C is called an abstract class. But if there is an instance of C that is not a member of a sub-class, then C is not an abstract class.
The Payment conceptual class we have been discussing is an abstract class, because all payments fall into one of the three sub-classes
Usually, when a super-class is created from a set of sub-classes, the super-class is abstract
Not all super-classes are abstract classes
Denote with italics in Domain Model
16
Modeling State ChangesOccasionally it is necessary to capture the state of an transaction, for example, in the Domain Model.
This should not be done with sub-classes, because the super-class can transition
Best to use a separate conceptual class for this, and provide state subclasses of the state class
The association is usually “is-in” for these state transition classes
State transitions can also be captured in a state diagram
17
Example: Modeling State Changes
Paymentnot useful
these subclasses are changing states of the superclass
UnauthorizedPayment
AuthorizedPayment
PaymentState better
UnauthorizedState
AuthorizedState
Payment Is-in 1*
18
Association ClassesOften, the association between conceptual classes contains information that needs to be captured in the model, but does not belong in either class as an attribute
A merchantID may be an attribute with the payment authorization service, but this does not belong in either the Store or AuthorizationService classesA salary may be an attribute of employment, but it does not belong as an attribute of the person or employer classes
General rule: If class C can simultaneously have many values of attribute A, then A should not be placed in C.
Could create a new conceptual class and associate it with the existing classes, but this can add complexity to the model
Better way: Create a special class that represents the attributes of the association
19
Example: An Association Class
addressnamephoneNumber
AuthorizationService
addressname
Store
merchantID
ServiceContractan association class
its attributes are related to the association
its lifetime is dependent on the association
Authorizes-payments-via
1..**
20
Association Classes – When to AddIf the attribute(s) appear to be related to the association and not a particular conceptual class ….
The lifetime of the attributes is dependent upon the association …
There is a many-to-many association between two conceptual classes, and there are many attributes (common clue)
21
Aggregation and CompositionThese are software class concepts that will be important later
Aggregation implies a container or collection of classesIn this case, if the container class is destroyed, the individual parts are notDenoted in UML as an open diamond
Composition also implies a collection of classes, but with a stronger life dependency
If the container class is destroyed, the individual component instances are also destroyedDenoted by a filled in diamond in UML
22
Examples: Aggregation and Composition
23
Aggregation and CompositionUsually not critical for domain models, but may be used to …
Clarify constraints in the Domain Model (e.g. existence of a class depends on another class)
Help model situations when create/delete operations apply to many sub-parts
24
Examples: Composition in NextGen POS
SalesLineItemSale1..*
ProductDescription
ProductCatalog 1..*
1
1
25
Association Role Names
Occasionally a role name is added to an association; this name describes the role the object plays in the association
Not required, often included if there role is not clear
Should model the role as a separate class if there are unique attributes, associations, etc. related to the role
Flight CityFlies-to* destination
role name
describes the role of a city in the Flies-to association
Person
*parent
Creates
2
child
1
“Reflexive Association”
26
Qualified AssociationsA qualifier may be used in an association; it distinguishes a set of objects at the far end of the association based upon the qualifier value
In the example below, we can identify the ProductDescriptions by the itemID, so we denote this in the UML diagram and change the multiplicity. Be careful not to design!
ProductCatalog
ProductDescription
itemID Contains
ProductCatalog
ProductDescription
Contains
1..*
multiplicity reduced to 1
(a)
(b)
qualifier
1
11
27
Packages
Often, a Domain Model may become complex and hard to read
Re-structuring the model using packages is an way to improve readability and maintainability
Domain
Core Elements Sales
28
Packages
An element is owned by the package it belongs to, but can be referenced by elements in another package
SalesCore Elements
Sale
Core Elements::Register
Captures
Store RegisterHas1..*1
1
1
29
Packages
Packages may be dependent upon each other; this happens if the elements know about or are coupled to elements in another package
Domain
Core Elements Sales
30
Partitioning the Domain Model Use packages to partition the Domain Model when there are groups of elements that …
… are in the same subject area, closely related by concept or purpose
… are in the same class hierarchy together
… participate in the same use case
… are strongly associated
31
NextGen POS – Domain Model
Domain
Core/Misc Payments Products Sales
Authorization Transactions
32
NextGen POS: Core/Misc Package
Core/Misc
Register Manager
Store
addressname
Houses
1..*
Employs
1..*1
1
33
Payments
Check
AccountsReceivable
CreditPayment
CheckPayment
CheckAuthorization
Service
CreditAuthorization
Service
Authorized-by
Authorized-by
***
AuthorizationService
addressnamephoneNumber
Core::StorePayment
amount
Establishes-credit-for
Logs
*
CreditCard
expiryDatenumber
DriversLicense
number
1..*
Establishes-identity-for
Paid-by
CashPayment
amountTendered *
Sales::CustomerAbused-by
Identifies
Authorization Transactions::PaymentAuthorizationReply
- CheckPayments have CheckPaymentReplies
- CreditPayments have CreditPaymentReplies
1
1
1
111
1
1 1
1
1
Authorizes-payments-of
merchantID
ServiceContract
1
34
Products
1..*
Core::Store
Stocks
*
Describes
*
Sales::SalesLineItem
Described-by *
Records-sale-of
0..1
ProductDescription
descriptionpriceitemID
ProductCatalog
Item1
1
1
1
1
35
Sales
Cashier
Customer
1..*
SalesLineItem
/quantity
Sale
dateisCompletetime
Initiates
Core::Register
Records-sales-on
Captured-on
Core::Store
Logs-completed*
1
1
1
1
1
1
1
1
TaxLineItem
descriptionpercentageamount
1..* 1
36
Authorization Transactions
CreditPaymentApprovalRequest
CheckPaymentApprovalRequest
PaymentAuthorization
Reply
PaymentAuthorization
Request
CreditPaymentApproval
Reply
CheckPaymentApproval
Reply
CreditPaymentDenialReply
CheckPaymentDenialReply
PaymentAuthorizationTransaction
37
Takeaways from Chapters 9 and 31
Learn how to associate the conceptual classes of a Domain Model
Understand how to assign key attributes to conceptual classes, and when to define a new data type class
Understand how to create sub- and super-classes
38
Next … Chapter 16: UML Class Diagram Notation
An overview of Java concepts: Inheritance, Polymorphism, Interfaces