Domain Model Refinement
Domain Model Refinement
1
Generalization and Specialization
• Conceptual class hierarchies are the basis for
software class hierarchies that exploit
inheritance
• Association classes capture information about
the association
• Time intervals capture the idea that some
objects are valid for a limited time
2
Concepts for this Iteration
Category Examples
Physical or tangible objects CreditCard, Check
Transactions CheckPayment, CashPayment
Other computer or electro-mechanical CreditAuthorizationService,
systems external to ours CheckAuthorizationService
Organizations
Records of finance, work, contracts, legal AccountsReceivable, GeneralLedger
matters
3
Generalization
• CashPayment, CreditPayment, and
CheckPayment are similar
• Identify commonality among concepts and
define a superclass
• Separate and shared arrow notations in UML
4
Defining Superclasses and
Subclasses
• A conceptual superclass definition is more
general than a subclass definition
• A subclass is a subset of its superclass
• Conformance: 100% of the superclass
definition should be applicable to the
subclass’s attributes and associations
• The “is-a” rule
5
When to Define a Subclass?
• The subclass has additional attributes of
interest
• The subclass has additional associations
• The subclass is operated on differently from
the superclass or other subclasses
• The subclass represents an animated thing
that behaves differently from the superclass
6
When to Define a Superclass?
• Possible subclasses represent variations of a
similar concept
• Subclasses will conform to the 100% and is-a
rules
• All subclasses have the same attribute that
can be factored out and put in the superclass
• All subclasses have the same association that
can be related to the superclass
7
Abstract Conceptual Classes
• If every member of a class C must also be a
member of a subclass, then C is called an
abstract class
• That is, if C is never used by itself, but only
derived classes are used, C is abstract
• UML uses italics for abstract classes
Payment abstract class
indicated by italics
amount : Money
8
Modeling Changing States
• Don’t model the states of a concept as
subclasses, but rather either:
– Define a state hierarchy and associate the states
with the class, or
– Ignore showing the states of a concept in the
domain model; show states in state diagrams
9
Diagrams
Payment
not useful
* Is-in 1
Payment PaymentState better
Unauthorized Authorized
State State
11
Association Classes
• If a class C can simultaneously have many
values for the same kind of attribute A, create
an association class with that attribute and
associate it with C
• E. g. a person may have many phone
numbers. Place phone number in a separate
class and associate many of these with Person
• How does this relate to database design?
12
Association Class Guideline
• An association class may be useful if:
– An attribute is related to an association
– Instances of the association class have a lifetime
dependency on the association
– There is a many-to-many association between two
concepts and information associated with the
association itself
– The best example I have is from databases: A person
can interview with many companies. The Interview
association class has information.
13
Aggregation and Composition
• Aggregation has no meaningful distinct
semantics in UML
• Use composition instead
• Composition is a strong kind of whole-part
aggregation
14
Composition
• Implies the following:
– An instance of the part belongs to only one
composite instance at a time
– The part must always belong to a composite
(Fingers always belong to a Hand)
– The composite is responsible for the creation and
deletion of its parts. If the composite is
destroyed, the parts must either be destroyed or
attached to another composite
15
Composition Guidelines
• If in doubt, leave it out
• The lifetime of the part is bound to the lifetime of
the composite
• There is an obvious whole-part physical or logical
assembly
• Some properties of the composite propagate to the
parts
• Operations applied to the composite propagate to
the parts, such as destruction, movement, recording
16
Time Intervals and Product Prices
• If a SalesLineItem is associated with a
ProductDescription and that contains the
price, then you can always get the price,
right?
17
Time Intervals and Product Prices
• If a SalesLineItem is associated with a
ProductDescription and that contains the
price, then you can always get the price,
right?
• Wrong. If the price changes, old sales refer to
the new price
18
Two Approaches
• Copy the current price to the SalesLineItem
• Associate a collection of ProductPrices with
ProductDescriptions, each with its applicable
time interval.
• Why might the second option not always be
better?
19
Association Role Names
• Each end of an association is a role.
Properties are: Name and multiplicity
• For example, a City is an object in an
association, but its role in a flight might be
destination Flight* Flies-to 1
destination
City
role name
Person
2
*
child
parent
Creates
20
Roles: Concept vs. Association
• Roles in associations are good because they
express the idea that the same instance of a
person takes on multiple roles depending
upon the association.
• Roles as concepts provide flexibility in adding
attributes, associations, and additional
semantics. (Roles as separate classes.)
21
Roles in Associations
roles in associations
Employs-to-manage
1 manager
*
Store Employs-to-handle-sales * Person
cashier
1
*
manager worker
Manages
roles as concepts
Store
1 Employs * Manager
1
Manages
1
Employs * Cashier
*
22
Qualified Associations
• A qualifier may be used in an association. The
qualifier value makes each thing on the left
unique.
• Use carefully; they don’t usually add new
information.(a) Product Contains Product
Catalog Specification
1 1..*
1 1
Product Contains Product
(b) itemID
Catalog Specification
23
Reflexive Associations
• A concept may have an association to itself.
Person
2
*
parent child
Creates
25
Packages: Ownership vs. Reference
• An element is owned by the package in which
it is defined but may be referenced in other
packages.
• Qualify the element name with the name of
the package. E. g. in Sales:
Core Elements::Register –Captures Sale
26
Packages: Dependency
• If a model’s elements are dependent upon
another, show the dependency with an
arrowed line. For example, Sales is dependent
upon Core Elements.
27
Partitioning the Model
• Place elements together that:
– Are in the same subject area; closely related by
concept or purpose
– Are in a class hierarchy together
– Participate in the same use case
– Are strongly associated
28
POS Domain Model packages
Domain
Authorization
Transactions
Core/Misc
Store
Houses
Register Manager
address 1 1..*
name
1..*
1
Employs
29
POS Payments
Payments
1 Authorizes-payments-of
1..*
Paid-by
Check
1
1
Check Credit
CashPayment Credit Check Authorized-by Authorization Authorization
amountTendered
Payment Payment
* 1
Service Service
* * * * 1
Authorized-by
Logs
Establishes- Establishes-
credit-for identity-for
Authorization Transactions::
1 1 1
PaymentAuthorizationReply
Accounts CreditCard DriversLicense
Receivable
expiryDate number
number - CheckPayments have
1
Identifies CheckPaymentReplies
1 1
Abused-by - CreditPayments have
Sales::Customer
1 CreditPaymentReplies
30
Monopoly Refinements
31