Transcript Domain Model Refinement Larman, chapter 31 CSE 432: Object-Oriented Software Engineering Glenn D.

Domain Model Refinement
Larman, chapter 31
CSE 432: Object-Oriented Software Engineering
Glenn D. Blank, Lehigh University
When to make generalization hierarchies?
Why is the following a good example?
s u p e rc la s s - m o re g e n e ra l
concept
P aym ent
th e s e a re c o n c e p tu a l
c la s s e s , n o t s o ftw a re
c la s s e s
Figure 31.1
C ash
P aym ent
C re d it
P aym ent
C heck
P aym ent
s u b c la s s - m o re
s p e c ia liz e d c o n c e p t
Guidelines:
• Identify superclasses and subclasses when they help us
understand concepts in more general, abstract terms
and reduce repeated information.
• Expand class hierarchy relevant to the current iteration
and show them in the Domain Model.
100% and Is-a rules
P aym ent
am ount : M oney
C ash
P aym ent
C re d it
P aym ent
P a y s -fo r
1
1
S a le
C heck
P aym ent
100% rule: Subclasses must conform to 100% of
superclass’s attributes and associations. Do they above?
Is-a rule (informal test): “Subclass is a Superclass”
What about this hierarchy?
C o rre c t s u b c la s s e s .
C u s to m e r
B u t u s e fu l?
M a le
C u s to m e r
F e m a le
C u s to m e r
Fig. 31.6
Guidelines for creating conceptual subclasses:
• Subclass has additional attributes or associations of interest
• Subclass behaves or is operated on, or handled or
manipulated differently than superclass or other subclasses
Is this hierarchy OK? What does it add to our
understanding of the domain?
A u th o rize s-p a ym e n ts -o f
*
S to re
*
su p e rcla ss ju stifie d b y
co m m o n a ttrib u te s a n d
a sso cia tio n s
A u th o riza tio n S e rvice
a d d re ss
nam e
phoneN um ber
C re d it
A u th o riza tio n
S e rvice
1
a d d itio n a l a sso cia tio n s
C h e ck
A u th o riza tio n
S e rvice
1
A u th o rize s
*
C re d it
P a ym e n t
A u th o rize s
*
C h e ck
P a ym e n t
Fig. 31.8
Models transactions with external services which are important in POS domain
When to design Association classes?
a b e tte r m o d e l, b u t n o t
ye t a s u se fu l a s p o ssib le
A u th o riza tio n S e rvice
S to re
A u th o rize s -p a ym e n ts -via
a d d re ss
nam e
1 .. *
*
S e rvice C o n tra ct
P u rch a se s
Fig. 31.15
1 .. *
m e rch a n tID
a d d re ss
nam e
phoneN um ber
 S e lls
*
ServiceContract records merchantID—good.
But ServiceContract is dependent on relationship between two classes
A u th o riza tio n S e rvice
S to re
A u th o rize s -p a ym e n ts -via
a d d re ss
nam e
1 .. *
*
a d d re ss
nam e
phoneN um ber
Fig. 31.16
a n a sso cia tio n cla ss
S e rvice C o n tra ct
m e rch a n tID
its a ttrib u te s a re re la te d to th e a sso cia tio n
its life tim e is d e p e n d e n t o n th e a sso cia tio n
What about this hierarchy? (Why not?)
P aym ent
n o t u s e fu l
th e s e s u b c la s s e s a re
c h a n g in g s ta te s o f th e
s u p e rc la s s
P aym ent
U n a u th o riz e d
P aym ent
*
Fig. 31.13
1
Is -in
P a y m e n tS ta te
U n a u th o riz e d
S ta te
A u th o riz e d
P aym ent
b e tte r
A u th o riz e d
S ta te
• Classes should be invariant
• Classes can maintain state information as attributes
• Rather than subclasses, model changing states with state charts
More Association classes
C om pany
a p e rso n m a y h a ve
e m p lo ym e n t w ith se ve ra l
co m p a n ie s
Ja il
E m p lo ys
*
*
P e rso n
*
P e rso n
E m p lo ym e n t
sa la ry
1
In ca rce ra te s
Ja ilT e rm
d a te O fIn ca rce ra tio n
M a rrie d-to
0 ..1
0 ..1
P e rso n
Fig. 31.17
When to add Composition notation?
S a le
1 .. *
1
P ro d u c t
C a ta lo g
1 .. *
1
S a le s L in e Ite m
P ro d u c t
D e s c rip tio n
Fig. 31.18
Guidelines for drawing Composition (whole-part) relationships:
• Obvious whole-part physical or logical assembly
• Lifetime of part is bound within lifetime of whole
(create-delete dependency)
• Some properties of whole propagate to parts, e.g., location
• Operations of whole propagate to parts, e.g., movement
• But: If in doubt, leave it out.
UML package diagrams





UML packages for higher level structure than classes
Denoted by box with smaller box on top
 Note dependency arrows
 A dependency indicates that changes to one element may cause
changes to the other
Guidelines for partitioning the domain model into packages:
 Place elements together if they are in same class hierarchy,
participate in the same use cases,
or closely related by concept or purpose, or strongly associated
Packages can be grouped in higher-order packages
 Packages may include packages
 Common package as <<global>> means all packages in system
have dependency to this one
 General package marked {abstract} means this package is
an interface, with subtypes
Guidelines: divide classes into packages;
analyze dependencies; refactor to reduce dependencies
Higher order package for POS domain
D o m a in
C o re /M is c
P a y m e n ts
P ro d u c ts
S a le s
A u th o riz a tio n
T ra n s a c tio n s
Fig. 31.29
What does this higher order package contain?
Core/Misc package
C o re /M is c
S to re
a d d re s s
nam e
1
H ouses
1
1 .. *
R e g is te r
M anager
1 .. *
E m p lo y s
Fig. 31.30
Why call this package Core for the POS domain?
A rich package
P a y m e n ts
 A u th o riz e s -p a y m e n ts -o f
1
P aym ent
1 .. *
A u th o riz a tio n S e rv ic e
C o re ::S to re
S e rv ic e C o n tra c t
am ount
m e rc h a n tID
P a id -b y
1
a d d re s s
nam e
phoneN um ber
C heck
1
C ashP aym ent
a m o u n tT e n d e re d
C re d it
P aym ent
C heck
P aym ent
* * *
A u th o riz e d -b y
1
*
C heck
A u th o riz a tio n
S e rv ic e
C re d it
A u th o riz a tio n
S e rv ic e
*
1
A u th o riz e d -b y
Logs 
1
A c c o u n ts
R e c e iv a b le
E s ta b lis h e s -
E s ta b lis h e s -
c re d it-fo r 
id e n tity -fo r 
1
1
C re d itC a rd
A u th o riz a tio n T ra n s a c tio n s ::
P a y m e n tA u th o riz a tio n R e p ly
D riv e rs L ic e n s e
e x p iry D a te
num ber
num ber
1
1
Id e n tifie s
- C h e c k P a y m e n ts h a v e
C h e c k P a y m e n tR e p lie s
1
A b u s e d -b y 
1
S a le s ::C u s to m e r
Fig. 31.31
- C re d itP a y m e n ts h a v e
C re d itP a y m e n tR e p lie s
Note: Composition and tie to Core package
P ro d u c ts
S a le s ::
S a le s L in e Ite m
D e s c rib e d -b y
0 ..1
*
1
P ro d u c t
D e s c rip tio n
P ro d u c tC a ta lo g
1 .. *
1
d e s c rip tio n
p ric e
ite m ID
1
R e c o rd s -s a le -o f
D e s c rib e s
*
C o re ::
S to re
S to c k s
1
Ite m
*
Fig. 31.32
1
Iteration-3 of Monopoly domain model
What’s new?
Don’t forget to plan testing!
Plan testing for classes and system





Write system and unit test plan descriptions as part of
class design
Unit test all public member functions
Test for valid, invalid and boundary cases
System testing follows thorough class testing
See Junit tool for automated test generation support