Associations - UML

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).

In the UML, associations are defined as "the semantic relationship between two or more classifiers that involve connections among their instances."

Association

Association

Guideline: When to Show an Association?

Associations worth noting usually imply knowledge of a relationship that needs to be preserved for some duration - it 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 SalesLine ltem instances are associated with a Saleinstance? 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 on - the 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 Product Descriptions, but there is no need to remember the fact of a particular Cashier looking up particular Product Descriptions.

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 - l)) / 2 associations to other nodes - a 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 perspective - in 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.

The ends of an association may contain a multiplicity expression indicating the numerical relationship between instances of the classes. The association is inherently bidirectional, meaning that from instances of either class, logical traversal to the other is possible. This traversal is purely abstract; it is not a statement about connections between software entities.

The UML notation for associations

The UML notation for associations

An optional "reading direction arrow" indicates the direction to read the association name; it does not indicate direction of visibility or navigation. If the arrow is not present, the convention is to read the association from left to right or top to bottom, although the UML does not make this a rule.

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. Simple association names such as "Has" or "Uses" are usually poor, as they seldom enhance our understanding of the domain.

For example,

  1. Sale Paid - by Cash Payment
    • bad example (doesn't enhance meaning): Sale Uses CashPayment
  2. 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.

Multiplicity on an association

Multiplicity on an association

For example, a single instance of a Store can be associated with "many" (zero or more, indicated by the *) Item instances.

Some examples of multiplicity expressions are shown in Figure.

The multiplicity value communicates how many instances can be validly associated with another, at a particular moment, rather than over a span of time. For example, it is possible that a used car could be repeatedly sold back to used car dealers over time. But at any particular moment, the car is only Stocked - by one dealer. The car is not Stocked - by many dealers at any particular moment. Similarly, in countries with monogamy laws, a person can be Married - to only one other person at any particular moment, even though over a span of time, that same person may be married to many persons.

Multiplicity values

Multiplicity values

The multiplicity value is dependent on our interest as a modeler and software developer, because it communicates a domain constraint that will be (or could be) reflected in software. See Figure for an example and explanation.

Multiplicity is context dependent

Multiplicity is context dependent

Rumbaugh gives another example of Person and Company in the Works - for association [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); the flying - to and flying - from associations are distinctly different relationships, which should be shown separately.

Multiple associations

Multiple associations

Guideline: How to Find Associations with a Common Associations List

Start the addition of associations by using the list in Table. It contains common categories that are worth considering, especially for business information systems.

Examples are drawn from the

  1. POS
  2. Monopoly
  3. airline reservation domains.

Table Common Associations List

Table  Common Associations List

Example: Associations in the Domain Models

Case Study: NextGen POS

The domain model in Figure shows a set of conceptual classes and associations that are candidates for our POS domain model. The associations are primarily derived from the "need - to - remember" criteria of this iteration requirements, and the Common Association List. Reading the list and mapping the examples to the diagram should explain the choices. For example:

  • Transactions related to another transactionSale Paid - by CashPay - ment.
  • Line items of a transactionSale Contains SalesLine ltem.
  • Product for a transaction (or line item)SalesLine ltem Records - sale - ofItem.

NextGen POS partial domain model

NextGen POS partial domain model

Case Study: Monopoly

See Figure Again, the associations are primarily derived from the "need - to - remember" criteria of this iteration requirements, and the Common Association List. For example:

  • A is contained in or on BBoard Contains Square.
  • A owns BPlayers Owns Piece.
  • A is known in / on BPiece Is - on Square.
  • A is member of BPlayer Member - of (or Plays) Monopoly Game.

Monopoly partial domain model

Monopoly partial domain model


All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

UML Topics