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