5d. UML Elements - Association
Having talked about structure and behavior, it's time to talk about relationships. For that, we will start with "Association."
What is an Association?
"An Association specifies a semantic relationship that can occur between typed instances...An Association declares that there can be links between instances whose types conform to or implement the associated types."
Associations are very powerful, but can be a very abstract topic. So, to better describe what an association is, let's continue with our example of an Order.
As you build out your Order class, you realize that you need to store more and more information about the order. You start with Product information, but you also realize that you need to add Customer details to ensure each order is tied to the right person who placed the order. You think about it for a while and realize that handling all that information in the Order Class doesn't make the most sense. So, you split that information into a Product Class and a Customer Class. Okay, but now how do you tie a Product and a Customer with each Order?
This is where Associations come in! Associations exist to define a relationship between Classes. But to be more accurate, it's better to say that an Association describes the relationship that exists between the instances of those Classes.
In our example, we finally decide to define a one (1) to many (*) Association between Order and Product, and a many (*) to one (1) relationship between Order and Customer.
Associations are shown by lines connecting one Class to the other.
Association "name"
Each Association has a "name" just like other UML elements. But unlike other elements, the Association name is optional.
When defined, the Association name sits in the center or somewhere along the line connecting tßhe two ends of the association.
Association "member ends"
An Association is composed of at least (and in most cases only) 2 "member ends" which are also known as "association ends." As we mentioned in a previous lesson, each member end is a "Property". These "member ends" are the most important parts that define the Association and largely are what determine the relationship itself. For this reason the next sections of this lesson will focus on those attributes of Properties that influence the Association itself.
Association end "multiplicity"
As we have already discussed, Properties have a "multiplicity" which indicates whether that Property is a single value or a collection of values. When we view the multiplicity lower and upper bounds through the lens of "association ends" or "member ends", we get a full picture of the type of Association that exists between the two Classes.
A "one to one" Association is one in which an instance of Class A can be associated to and instance of Class B at most one time and an instance of Class B can be associated to an instance of Class A at most one time. To achieve this, both member ends (Properties) in the Association have a multiplicity with an upper bound of 1. (0..1 or 1..1)
Association "one to one" A "one to many" Association is one in which an instance of Class A can be associated to an instance of Class B at most one time but an instance of Class B can be associated to multiple instances of Class A. To achieve this, one member end (Property) in the association has a multiplicity with an upper bound of 1 (0..1 or 1..1) and the other has a multiplicity with an upper bound of 2 or more or the value "*". (0..2, 0..*, 1..3, 0..*, etc.)
Association "one to many" A "many to many" Association is one in which an instance of Class A can be associated to multiple instances of Class B and an instance of Class B can be associated to multiple instances of Class A. To achieve this, both member ends (Properties) in the Association have a multiplicity with an upper bound of 2 or more or the value "*". (0..2, 0..*, 1..3, 1..*, etc.)
Association "many to many"
Association end "aggregation"
We have already mentioned quite a bit about a Properties "aggregation." When we look at this through the lens of "association ends" or "member ends", we get a full picture of the aggregation relationship that exists between two Classes.
When both ends of the Association (Property) have aggregation set to "none", the Association models an equal relationship between Classes where neither owns or is a part of the other.
Association with no aggregation When one end of the Association (Property) has aggregation set to "shared" the Association models an unequal relatinoship between Classes.
Association with shared aggregation When one end of the Association (Property) has aggregation set to "composite" the Association models a whole/part relatinoship where one Class composes parts of the other and thus is strongly coupled with that Class.
Association with composite aggregation
How do you know when to define a new Association?
Deciding when to define Associations can be a difficult decision, but here are a few thoughts.
One to one Associations are often a matter of preference and convenience since many times you can take the same attributes of one Class and transfer them to the other without changing the relationship. If it feels cleaner to separate the Classes, then you would want to also create a one to one Association between them.
For other Associations, isolate a theoretical instance of one of the Classes in the Association. Ask yourself the question, "How many instances of Class A might I see be associated to instances of Class B?" and note down your answer. Then ask the same question but switching the Classes in the question, "How many instances of Class B might I see be associated to instances of Class A?" This should give you a good indication of the multiplicity of each of the Association ends and whether to define it as a new Association.
For example, "How many Product instances might one Offer have?" My answer might be "many" in this case. Then I flip it around, "How many Offers might a Product instance be associated to?" My answer might be "one" this time...but depending on the situation it could be "many". Now I know that the Association should exist and it should be either a "one to many" or a "many to many" Association.
Comparison to Object-Oriented Programming Languages
The concept of Association doesn't really exist in Object-oriented programming languages. You don't define the Association itself in code, but you instead define the properties that participate in the Association (the "member ends"). The values assigned to these properties in the runtime are sometimes called "references." So, the concept of "references" might be considered a similar concept where a “reference” is one end of an implementation of an Association.
Abstract Syntax
To illustrate what an Association is, UML provides abstract syntax which we have recreated in UML Class Diagrams.
