This document discusses associations in object oriented system design. It defines associations as relationships between classes. Associations can be implemented using multiplicity, aggregation, and composition. The document provides examples of association notation in UML diagrams and lists common types of associations to consider, such as physical/logical part-whole relationships. It also covers naming conventions for associations and using roles and multiplicity to define association properties.
2. ASSOCIATIONS
Association defines the relationship between two or
more classes in the System. These generally relates
to the one object having instance or reference of
another object inside it.
Associations in UML can be implemented using
following ways: 1) Multiplicity 2) Aggregation 3)
Composition
4. USEFUL ASSOCIATIONS
Associations for which knowledge of the relationship
needs to be preserved for some duration.
Associations derived from the Common Associations
List.
5. 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.
6. UML ASSOCIATION NOTATION
- “rea d in g d irectio n arro w ”
- it h a s no m ean in g ex c ep t
to in d ic ate d irectio n o f
read in g th e asso c ia tio n
lab el
- o ften ex c lu d ed
R egister Sale
R ec o rd s-cu
rren t
1 1
m ultip lic ity
asso c ia tio n n am e
7. 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.
8. 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.
9. 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.
10. 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.
11. 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.
12. 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.
13. ROLES
Each end of an association is called a role.
Roles may have
● name
● multiplicity expression
● navigability
14. 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
*
T zero or more;
“many”
1..*
T one or
more;
one to
40
1..40
T
5
T exactly
5
3,5,8
T exactly 3,5
or 8
17. NAMING ASSOCIATIONS
Name an association based on TypeName-VerbPhrase-
TypeName format.
Names should start with a capital letter.
Legal formats are:
● Paid-by
● PaidBy
