9.14. Associations
It's useful to find and show associations that are needed to satisfy the information requirements of the current scenarios under development, and which aid in understanding the domain.An association is a relationship between classes (more precisely, instances of those classes) that indicates some meaningful and interesting connection (see Figure 9.11).
Figure 9.11. Associations.
Guideline: When to Show an Association?
Associations worth noting usually imply knowledge of a relationship that needs to be preserved for some durationit could be milliseconds or years, depending on context. In other words, between what objects do we need some memory of a relationship ?For example, do we need to remember what SalesLineItem instances are associated with a Sale instance? Definitely, otherwise it would not be possible to reconstruct a sale, print a receipt, or calculate a sale total.And we need to remember completed Sales in a Ledger , for accounting and legal purposes.Because the domain model is a conceptual perspective, these statements about the need to remember refer to a need in a real situation of the world, not a software need, although during implementation many of the same needs will arise.In the monopoly domain, we need to remember what Square a Piece (or Player ) is onthe game doesn't work if that isn't remembered. Likewise, we need to remember what Piece is owned by a particular Player . We need to remember what Squares are part of a particular Board .But on the other hand, there is no need to remember that the Die (or the plural, "dice") total indicates the Square to move to. It's true, but we don't need to have an ongoing memory of that fact, after the move has been made. Likewise, a Cashier may look up ProductDescriptions , but there is no need to remember the fact of a particular Cashier looking up particular ProductDescriptions .
Guideline Consider including the following associations in a domain model:
|
Guideline: Why Should We Avoid Adding Many Associations?
We need to avoid adding too many associations to a domain model. Digging back into our discrete mathematics studies, you may recall that in a graph with n nodes, there can be (n·(n-1))/2 associations to other nodesa potentially very large number. A domain model with 20 classes could have 190 associations lines! Many lines on the diagram will obscure it with "visual noise." Therefore, be parsimonious about adding association lines. Use the criterion guidelines suggested in this chapter, and focus on "need-to-remember" associations.
Perspectives: Will the Associations Be Implemented In Software?
During domain modeling, an association is not a statement about data flows, database foreign key relationships, instance variables, or object connections in a software solution; it is a statement that a relationship is meaningful in a purely conceptual perspectivein the real domain.That said, many of these relationships will be implemented in software as paths of navigation and visibility (both in the Design Model and Data Model). But the domain model is not a data model; associations are added to highlight our rough understanding of noteworthy relationships, not to document object or data structures.
Applying UML: Association Notation
An association is represented as a line between classes with a capitalized association name. See Figure 9.12.
Figure 9.12. The UML notation for associations.
Caution The reading direction arrow has no meaning in terms of the model; it is only an aid to the reader of the diagram. |
Guideline: How to Name an Association in UML?
Guideline Name an association based on a ClassName-VerbPhrase-ClassName format where the verb phrase creates a sequence that is readable and meaningful. |
- Sale Paid-by CashPayment
- bad example (doesn't enhance meaning): Sale Uses CashPayment
- Player Is-on Square
- bad example (doesn't enhance meaning): Player Has Square
Association names should start with a capital letter, since an association represents a classifier of links between instances; in the UML, classifiers should start with a capital letter. Two common and equally legal formats for a compound association name are:
- Records-current
- RecordsCurrent
Applying UML: Roles
Each end of an association is called a role. Roles may optionally have:
- multiplicity expression
- name
- navigability
Multiplicity is examined next.
Applying UML: Multiplicity
Multiplicity defines how many instances of a class A can be associated with one instance of a class B (see Figure 9.13).
Figure 9.13. Multiplicity on an association.
Figure 9.14. Multiplicity values.
Figure 9.15. Multiplicity is context dependent.
Rumbaugh91]. Indicating if a Person instance works for one or many Company instances is dependent on the context of the model; the tax department is interested in many ; a union probably only one . The choice usually depends on why we are building the software.
Applying UML: Multiple Associations Between Two Classes
Two classes may have multiple associations between them in a UML class diagram; this is not uncommon. There is no outstanding example in the POS or Monopoly case study, but an example from the domain of the airline is the relationships between a Flight (or perhaps more precisely, a FlightLeg ) and an Airport (see Figure 9.16); the flying-to and flying-from associations are distinctly different relationships, which should be shown separately.
Figure 9.16. Multiple associations.
Guideline: How to Find Associations with a Common Associations List
Start the addition of associations by using the list in