Transcript Document 7538354

Domain Model
Adding Associations
Chapter 11
Applying UML and Patterns
-Craig Larman
1
Objectives


Identify associations for a domain model.
Distinguish between need-to-know and
comprehension-only associations.
2
Introduction


Identify associations of conceptual classes
needed to satisfy the information
requirements of current scenarios.
Also identify the aid in comprehending the
domain model.
3
Associations
An association is a relationship between
instances of types that indicates some
meaningful and interesting connection
4
Associations
association
Records-current
Register
1
Sale
1
Fig 1.Associations
5
Useful Associations


Associations for which knowledge of the
relationship needs to be preserved for
some duration.
Associations derived from the Common
Associations List.
6
UML Association Notation



An association is represented as a line
between classes with an association name.
Associations are inherently bidirectional.
Optional reading direction arrow is only an
aid to the reader of the diagram.
7
UML Association Notation
-
-
“reading direction arrow”
it has no meaning except to
indicate direction of reading the
association label
often excluded
Records-current
Register
1
association name
Sale
1
multiplicity
8
Finding Associations-Common
Associations List
The common categories that are worth
considering are:
 A is a physical part of B . Eg: Wing-Airplane
 A is a logical part of B. Eg: SalesLineItemSale.

A is physically contained in B . Eg: RegisterStore.
9
Common Associations List 2

A is logically contained in B.
Eg:ItemDescription-Catalog.




A is a description of B.Eg:ItemDescription-Item.
A is a line item of a transaction or report
B.Eg:SalesLineItem-Sale.
A is a member of B .Eg: Cashier-Store.
A uses or manages B.Eg:Cashier-Register.
10
Common Associations List 3


A is
known/logged/recorded/reported/captured
in B.Eg: Sale-Register.
A is an organizational subunit of B .
Eg:Department-Store.


A communicates with B. Eg:Customer-Cashier.
A is next to B. Eg:City-City.
11
Common Associations List 4

A is related to a transaction B. Eg: CustomerPayment.




A is a transaction related to another
transaction B. Eg:Payment-Sale.
A is next to B. Eg:City-City.
A is owned by B. Eg:Register-Store.
A is an event related to B. Eg:Sale-Customer.
12
High-Priority Associations



A is a physical or logical part of B.
A is physically or logically contained in/on
B.
A is recorded in B.
13
Associations Guidelines



The knowledge of the relationship needs to
be preserved for some duration.
Identifying conceptual classes is more
important than identifying associations.
Avoid showing redundant or derivable
associations.
14
Roles


Each end of an association is called a role.
Roles may have
• name
• multiplicity expression
• navigability
15
Multiplicity


Multiplicity defines the number of instances
of a class A ,that can be associated with
one instance of class B,at a particular
moment.
Eg: In countries with monogamy laws,a
person can be married to 1 person at any
particular time.But over a span of time one
person can be married to many persons.
16
Multiplicity
Stocks
Store
1
Item
*
multiplicity of the
role
Fig 3 Multiplicity on an association.
17
Multiplicity
*
T
zero or more;
“many”
T
one or more;
T
one to 40
T
exactly 5
T
exactly 3,5 or 8
1..*
1..40
5
3,5,8
Fig 4. Multiplicity values.
18
Naming Associations



Name an association based on TypeNameVerbPhrase-TypeName format.
Names should start with a capital letter.
Legal formats are:
• Paid-by
• PaidBy
19
Associations Names
Store
1
Contains
1..*
Captures
Register
1
Paid-by
Sale
1..*
1
Payment
1
Airline
1
Employs
1..*
Assigned-to
Person
1
1
Assigned-to
Flight
*
*
Plane
1
*
Supervises
Fig 5.Association names.
20
Multiple Associations

Two types may have multiple associations
between them.
21
Multiple Associations
*
Flies-to
1
Flight
Airport
* Flies-from
1
Fig 6. Multiple associations.
22
Implementation



The domain model can be updated to
reflect the newly discovered associations.
But,avoid updating any documentation or
model unless there is a concrete
justification for future use.
Defer design considerations so that
extraneous information is not included and
maximizing design options later on.
23
Cleaning Associations 1



Do not overwhelm the domain model with
associations that are not strongly required.
Use need-to-know criterion for maintaining
associations.
Deleting associations that are not strictly
demanded on a need-to-know basis can
create a model that misses the point.
24
Cleaning Associations 2

Add comprehension-only associations to
enrich critical understanding of the domain.
25
A partial domain model
Records-sale-of
Described-by
1
Product
Catalog
Contains
1
1
0..1
*
Product
Specfication
1..*
Describes
Used-by
*
*
Sales
LineItem
Store
Item
1
Stocks
1
Logscompleted
1..*
Contained-in
1..*
*
1
Houses
1
1..*
*
Sale
Register
Manager
Started-by
Captured-on
1
1
1
1
1
1
1
Records-sales-on
Paid-by
1
Initiated-by
1
Initiated-by
1
Payment
Cashier
1
Customer
26
Without need-to-know
associations
Records-sale-of
Described-by
1
Product
Catalog
Contains
1
1
0..1
*
1..*
Describes
Used-by
*
*
Sales
LineItem
Store
Item
1
Stocks
1
Logscompleted
1..*
Contained-in
1..*
*
1
Houses
1
Sale
Product
Specfication
1..*
*
Register
Captured-on
1
1
1
1
1
Records-sales-on
Paid-by
1
Initiated-by
1
Cashier
1
Payment
27
Conclusion



When in doubt if the concept is
required,keep the concept.
When in doubt if the the association is
required,drop it.
Do not keep derivable association.
28