Domain Model Adding Associations
description
Transcript of Domain Model Adding Associations
1
Domain Model Adding Associations
Chapter 11
Applying UML and Patterns
-Craig Larman
2
Objectives
Identify associations for a domain model. Distinguish between need-to-know and
comprehension-only associations.
3
Introduction
Identify associations of conceptual classes needed to satisfy the information requirements of current scenarios.
Also identify the aid in comprehending the domain model.
4
Associations
An association is a relationship between instances of types that indicates some meaningful and interesting connection
5
Associations
association
Register
Sale
Records-current
1 1
Fig 1.Associations
6
Useful Associations
Associations for which knowledge of the relationship needs to be preserved for some duration.
Associations derived from the Common Associations List.
7
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.
8
UML Association Notation
- “reading direction arrow” - it has no meaning except to
indicate direction of reading the association label
- often excluded
Register
Sale
Records-current
1 1
multiplicity
association name
9
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: SalesLineItem-
Sale. A is physically contained in B . Eg: Register-
Store.
10
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.
11
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.
12
Common Associations List 4
A is related to a transaction B. Eg: Customer-Payment.
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.
13
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.
14
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.
15
Roles
Each end of an association is called a role. Roles may have
• name
• multiplicity expression
• navigability
16
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.
17
Multiplicity
multiplicity of the
role
Store
Item
Stocks
1 *
Fig 3 Multiplicity on an association.
18
Multiplicity
Fig 4. Multiplicity values.
T *
zero or more; “many”
T
1..* one or more;
T
1..40 one to 40
T
5 exactly 5
T
3,5,8 exactly 3,5 or 8
19
Naming Associations
Name an association based on TypeName-VerbPhrase-TypeName format.
Names should start with a capital letter. Legal formats are:
• Paid-by
• PaidBy
20
Associations Names
Supervises
*
Paid-by Captures
1..* 1 1
Contains
1..*
1
Store
Register Sale Payment
1
Assigned-to Assigned-to
* * 1
Employs
1..*
1
Airline
Person Flight Plane
1 1
Fig 5.Association names.
21
Multiple Associations
Two types may have multiple associations between them.
22
Multiple Associations
1
1
*
*
Flies-from
Flight Airport Flies-to
Fig 6. Multiple associations.
23
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.
24
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.
25
Cleaning Associations 2
Add comprehension-only associations to enrich critical understanding of the domain.
26
A partial domain model
Initiated-by
Paid-by
Captured-on
Records-sales-on
Logs- completed
1
1
1
1 1
1 1 1
1
*
1
Describes
1..*
1
Records-sale-of
Described-by
*
1
1..* 1
1 1
1
Stocks
* 1
Contains
1..* 1
Product Catalog
Product Specfication
Store Item Sales LineItem
Register Manager Sale
Cashier
Customer Payment
Used-by
*
Started-by
Houses
1..*
Contained-in
0..1 *
Initiated-by
27
Without need-to-know associations
Paid-by
Captured-on
Records-sales-on
Logs- completed
1
1
1
1
1 1
1
*
1
Describes
1..*
1
Records-sale-of
Described-by
*
1
1..* 1
1
1
Stocks
* 1
Contains
1..* 1
Product Catalog
Product Specfication
Store Item Sales LineItem
Register Sale
Cashier
Payment
Used-by
*
Houses
1..*
Contained-in
0..1 *
Initiated-by
28
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.