Domain Model Refinement
Notation Extensions
Unit - 5 : Define Model Refinement 1
Things not seen before in the Domain Model
Similar to the concepts in the Object Models
Generalization and specialization
Conceptual class hierarchies
Association classes that capture information about the
association
Time intervals
Packages as a means of organization
Unit - 5 : Define Model Refinement 2
Fig. 5.1
superclass - more general
Payment concept
these are conceptual
classes, not software
classes
subclass - more
Cash Credit Check specialized concept
Payment Payment Payment
Domain Classes
Unit - 5 : Define Model Refinement 3
Fig. 5.2 Alternate notation
Payment Payment
Cash Credit Check Cash Credit Check
Payment Payment Payment Payment Payment Payment
They each show the same thing
Unit - 5 : Define Model Refinement 4
Conceptual Superclasses and Subclasses
Conceptual superclass is more general than
subclass
All members of subclass must be members of the
superclass
100% of superclass definition shall apply to the subclass
Subclass “is-a” superclass
Woman “is-a” human
Man “is-a” human
Anything else that is a human?
All humans have a heart and a brain.
Unit - 5 : Define Model Refinement 5
Fig. 5.3
Payment
amount : Money
Cash Credit Check
Payment Payment Payment
Cash Payment is-a payment.
No other type of payment is possible in this
domain, e.g. no gift certifications
Unit - 5 : Define Model Refinement 6
Fig. 5.4 Set View
Payment
CashPayment CreditPayment CheckPayment
Venn Diagram view:
All instances of “cash payment”
are also members of the
“payment class.
Unit - 5 : Define Model Refinement 7
Fig. 5.5
Payment
Pays-for Sale
amount : Money 1 1
Cash Credit Check
Payment Payment Payment
Pays-for applies to all payments!
Unit - 5 : Define Model Refinement 8
When to use a subclass
Start with the super-class and look at differences to
find the sub-classes that make sense.
Subclass has additional attributes
Subclass has additional associations
Subclass usage differs from superclass
Subclass represents an animate entity that behaves
differently
Unit - 5 : Define Model Refinement 9
Fig. 5.6
Customer Correct subclasses.
But useful?
Male Female
Customer Customer
Only useful to POS if men and women pay
different amounts, e.g. have specific gender
discounts.
Useful for age.
Unit - 5 : Define Model Refinement 10
When to define a Superclass
Start with a set of sub-classes and look for
commonalities that help the model.
Potential subclasses represent variations of concept
Subclasses meet “is-a” rule and 100% rule
All subclasses have common attributes that can be
factored out
All subclasses have the same association that can be
factored out
Unit - 5 : Define Model Refinement 11
Fig. 5.7
Pays-for 1
1 Sale
superclass justified by common 1
attributes and associations
Payment 3
additional associations
amount : Money
2
each payment subclass is Cash Credit Check
handled differently Payment Payment Payment
*
Identifies-credit-with Paid-with
1 1
CreditCard Check
NextGen POS Class Hierarchies
Unit - 5 : Define Model Refinement 12
Fig. 5.8
1
Authorizes-payments-of
* Store
*
superclass justified by AuthorizationService
common attributes and
associations address
name additional associations
phoneNumber 2
Credit Check
Authorization Authorization
Service Service
1 1
Authorizes Authorizes
* *
Credit Check
Payment Payment
Unit - 5 : Define Model Refinement 13
More or Less Generalization? (Fig. 5.9)
Payment
Authorization
Concepts too fine grained? Transaction
Useful to show this degree of
date
partitioning?
time
Payment Payment
Too much middle Authorization Authorization
management? Reply Request
CreditPayment CheckPayment CreditPayment CheckPayment
Authorization Authorization Approval Approval
Reply Reply Request Request
Each transaction is
handled differently, so
CreditPayment CreditPayment CheckPayment CheckPayment it is useful to partition
Approval Denial Approval Denial them into discrete
Reply Reply Reply Reply classes.
Unit - 5 : Define Model Refinement 14
Fig. 5.10
Payment
Authorization
Transaction
date
time
Payment Payment
Authorization Authorization
Reply Request
CreditPayment CreditPayment CheckPayment CheckPayment CreditPayment CheckPayment
Approval Denial Approval Denial Approval Approval
Reply Reply Reply Reply Request Request
Unit - 5 : Define Model Refinement 15
Fig. 5.11 Abstract Conceptual Classes
Payment
If a Payment instance may
exist which is not a
(a) CashPayment, CreditPayment
CashPayment CreditPayment CheckPayment
or CheckPayment, then
Payment is not an abstract
conceptual class.
abstract conceptual class
Payment
Payment is an abstract
conceptual class. A Payment
instance must conform to one
(b) CashPayment CreditPayment CheckPayment of the subclasses:
CashPayment, CreditPayment
or CheckPayment.
Unit - 5 : Define Model Refinement 16
Fig. 5.12
Payment abstract class
indicated by italics
amount : Money
Cash Credit Check
Payment Payment Payment
Unit - 5 : Define Model Refinement 17
Fig. 5.13 Modeling Changing State
Payment
not useful
these subclasses are
changing states of the
Unauthorized Authorized
superclass
Payment Payment
* Is-in 1
Payment PaymentState better
Unauthorized Authorized
State State
Why is this better?
More accurate representation of the details.
Unit - 5 : Define Model Refinement 18
Association Classes
If a class C can simultaneously have multiple values
for attribute A, put these in a separate class
When to use association class
An attribute is related to the association, not a class
Instances of association class have a lifetime
dependency on the association
Many to many associations between two concepts can
produce multiple values simultaneously.
Unit - 5 : Define Model Refinement 19
Fig. 5.14
Store AuthorizationService
both placements of
address merchantID are incorrect address
merchantID because there may be more merchantID
name than one merchantID name
phoneNumber
Think: transaction ID
Unit - 5 : Define Model Refinement 20
Fig. 5.15
a better model, but not
yet as useful as possible
AuthorizationService
Store
Authorizes-payments-via address
address 1..* name
name * phoneNumber
Purchases ServiceContract
3 Sells
1..* merchantID *
Think: transaction ID
Unit - 5 : Define Model Refinement 21
Fig. 5.16
AuthorizationService
Store
Authorizes-payments-via address
address 1..* name
name * phoneNumber
an association class
ServiceContract
its attributes are related to the association
merchantID
its lifetime is dependent on the association
Think: transaction ID
Unit - 5 : Define Model Refinement 22
Fig. 5.17
Employs
Company * * Person
a person may have Employment
employment with several
companies salary
1 Incarcerates
Jail * Person
JailTerm
dateOfIncarceration
Married-to
0..1 0..1
Person
Unit - 5 : Define Model Refinement 23
Aggregation and Composition
Composition in the Domain.
If in doubt don’t use it! Should be obvious
Composition when:
Whole-part exists
Lifetime of composite is bound together
Operation to the composite propagates to parts
Unit - 5 : Define Model Refinement 24
Fig. 5.18
Sale SalesLineItem
1 1..*
Product Product
Catalog 1 1..* Description
Unit - 5 : Define Model Refinement 25
Fig. 5.19
roles in associations
Employs-to-manage
1 manager
*
Store Employs-to-handle-sales * Person
cashier
1
*
manager worker
Manages4
roles as concepts
Store
1 Employs * Manager
1
Manages 6
1
Employs * Cashier
*
Unit - 5 : Define Model Refinement 26
Fig. 5.20
Sale
derived attribute
dateTime
/total
...
Derived Elements
No new information but helps comprehension
Unit - 5 : Define Model Refinement 27
Fig. 5.21
Sale
SalesLineItem
/quantity 1 1..*
derivable from the
actual multiplicity
Unit - 5 : Define Model Refinement 28
Fig. 5.22 Qualified Associations
(a) Product Contains Product
Catalog Description
1 1..*
1 1
Product Contains Product
(b) itemID
Catalog Description
qualifier multiplicity reduced to 1
Unit - 5 : Define Model Refinement 29
Fig. 5.23
Person
2
*
parent child
Creates 4
Self referential
Unit - 5 : Define Model Refinement 30
Packages
Group elements:
By subject area
In same class hierarchy
In same use cases
Strong associations
Do not know this until the project grows
Unit - 5 : Define Model Refinement 31
Fig. 5.24
Domain
Core Elements Sales
Helps comprehension as the project grows.
Can only see so many things in a group.
Unit - 5 : Define Model Refinement 32
Fig. 5.25
Core Elements Sales
Core Elements::
Register
1
Has
Store Register
1 1..*
Captures
Sale
1
Shows where the elements belongs, which package owns it.
Unit - 5 : Define Model Refinement 33
Fig. 5.26
Domain
Core Elements Sales
Sales is dependent on Core.
Sales refers to Core.
Unit - 5 : Define Model Refinement 34
Fig. 5.27
Domain
Core/Misc Payments Products Sales
Authorization
Transactions
POS Domain Model organization
Unit - 5 : Define Model Refinement 35
Fig. 5.28
Core/Misc
Store
Houses
Register Manager
address 1 1..*
name
1..*
1
Employs
Contents of Core
Unit - 5 : Define Model Refinement 36
Fig. 5.29
Payments
1 3 Authorizes-payments-of
1..*
Payment Core::Store AuthorizationService
ServiceContract
amount address
merchantID name
phoneNumber
Paid-by
Check
1
1
Check Credit
CashPayment Credit Check Authorized-by Authorization Authorization
Payment Payment 1
amountTendered
* Service Service
* * * * 1
Authorized-by
Logs 4
Establishes- Establishes-
credit-for 5 identity-for 5
Authorization Transactions::
1 1 1
PaymentAuthorizationReply
Accounts CreditCard DriversLicense
Receivable
expiryDate number
number - CheckPayments have
1
Identifies CheckPaymentReplies
1 1
Abused-by4 - CreditPayments have
Sales::Customer
1 CreditPaymentReplies
Unit - 5 : Define Model Refinement 37
Fig. 5.30
Products
Sales::
SalesLineItem 0..1
Described-by *
1
Product
Description
ProductCatalog description
1 1..*
price
itemID
1
Records-sale-of6
Describes
*
Core:: Stocks Item
Store 1 1
*
Unit - 5 : Define Model Refinement 38
Fig. 5.31
Sales
Customer Captured-on4 Core:: 1
1 Register
1
Initiates
1 Records-sales-on5
1
Tax 1
Sale
LineItem
SalesLineItem Cashier
date
description
percentage
isComplete 1..* /quantity
1..* 1 1
time
amount
* Core::
3 Logs-completed
1 Store
Unit - 5 : Define Model Refinement 39
Fig. 5.32
Authorization Transactions
Payment
Authorization
Transaction
Payment Payment
Authorization Authorization
Reply Request
CreditPayment CreditPayment CheckPayment CheckPayment CreditPayment CheckPayment
Approval Denial Approval Denial Approval Approval
Reply Reply Reply Reply Request Request
Unit - 5 : Define Model Refinement 40
Monopoly (Fig. 5.33)
Unit - 5 : Define Model Refinement 41
