UML Class Diagram – Understanding Associations

classclass-diagramuml

---------------------    ----------------------
|       FLIGHT      |    |       STEWARD      |
---------------------    ----------------------
| Arrival time      |    |  Steward ID        |
| Departure time    |    |  Name              |
| Flight ID         |    ----------------------
---------------------    | Call()             |
| Board()           |    | HelpPassenger()    |
| Depart()          |    ----------------------
---------------------

Today was my first UML lesson in class diagrams. My teacher asked me to model this class diagram. I have many confusions about what association I am supposed to use. I have some experience in ERDs and OOP.

  1. I am doubting what I should name my association. Should it be "a flight has * stewards"? Or should it be "a steward works on many flights"?

  2. Should I specify the multiplicity (1..* etc) at both sides?

  3. My teacher hasn't covered compositions and aggregations yet, but I'm afraid if I only use regular associations I might be doing something wrong. Can you make a class diagram with just associations? Would you consider a more complex class diagram wrong if it doesn't use compositions/aggregations?

  4. I read that there's no consensus on what aggregations precisely
    means. So why would we use something if there's no formal definition?

Best Answer

  1. I am doubting what I should name my association. Should it be "a flight has * stewards"? Or should it be "a steward works on many flights"?

Usually, the more specific you can name your association, the better, because a more specific name conveys more information.

On the other hand, if you are using a directional association (you put an arrowhead on one end), then the name must make sense when going in the direction of the arrow.
For example, if you have Flight --> Steward, then you can't name that association "works on", because it doesn't make sense to say "Flight X works on Steward Y".
If you have a non-directional association (no arrowheads, you can follow it in either direction), but your name only makes sense when it is read in a particular direction, you can optionally indicate that by putting a small arrow/tilted triangle next to the name, like this:

+--------+                +---------+
| Flight |   < Works On   | Steward |
|        |----------------|         |
+--------+                +---------+

This means that the association should be read as "Steward Y works on Flight X".

  1. Should I specify the multiplicity (1..* etc) at both sides?

If the multiplicity can be inferred from the context, you can leave it out.
But as a beginner, it might be better to be explicit about your intended multiplicity.
You write the multiplicity number on both sides of the association, like this:

+--------+                  +---------+
| Flight |2..4 < Works On  1| Steward |
|        |------------------|         |
+--------+                  +---------+

This means that each Flight has exactly 1 Steward and each Steward works on between 2 and 4 Flights (no more, no less).
An unknown upper limit to a range can be indicated with a *, like 2..* for "two or more". As a shorthand, just a * stands for 0..*.

  1. My teacher hasn't covered compositions and aggregations yet, but I'm afraid if I only use regular associations I might be doing something wrong. Can you make a class diagram with just associations? Would you consider a more complex class diagram wrong if it doesn't use compositions/aggregations?

No, I would not consider a class diagram without compositions/aggregations wrong. The biggest risk that you run when using an inappropriate type of association is that you don't convey your intended meaning, or that additional documentation is needed to convey it.

For class exercises, I wouldn't worry about the need for concepts that haven't been discussed yet in class. Either they are not needed to complete the exercise to a high standard, or there will be a follow-on exercise to refine your current diagram with the new concepts when they have been discussed.

  1. I read that there's no consensus on what aggregations precisely means. So why would we use something if there's no formal definition?

Plain association, aggregation and composition each refer to a different strength of the relation between two classes. Everyone agrees that plain association indicates the weakest kind of relation, composition the strongest and that aggregation is somewhere in the middle.
What the disagreement is on is just how strong a relation is when indicated with aggregation (where in the middle of the strength scale it is) and how such a relation should be implemented in the various languages.

The reason that it is still used is because it is often useful to have more than two levels to indicate the strength of a relation between two classes.

Related Topic