Document 7538354
Download
Report
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