--------------------- ----------------------
| 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.
-
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”?
-
Should I specify the multiplicity (1..* etc) at both sides?
-
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?
- I read that there’s no consensus on what aggregations precisely
means. So why would we use something if there’s no formal definition?
5
- 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”.
- 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..*.
- 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.
- 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.
3
In my eyes there is no such thing as a Many to Many relationship. There is a crucial concept that is lost in the shuffle when you rely on a many to many relationship.
Let’s look at a diagram I made for your scenario
In here I’ve modeled your domain using color-based modeling. A Plane (Person/Place/Thing) has 0 or more Flights (Moment-Interval). Each Flight has multiple Staff Assignments which can be a Steward or Pilot (Roles), there is a staff assignment for each Pilot or Steward in a flight. So it’s 1 to many from Flight to Assignment and Many to one from Assignment to Steward or Pilot.
Note that I modeled the relationship between the Assignment to the Steward/Pilot as aggregations. The Steward and Pilot exist outside of the realm of the Assignment. All the others I represented as compositions. IE a Flight exists only in the context of a plane (there’s no flight without a plane), in the same regard there is no assignment without a flight. That is the difference between composition and aggregation.
You could alternatively choose to model the FlightAssignment as a PlaneStaffAssignment (i.e. this is the crew working on the plane at this point in time). You’d then have to traverse the relationship to see who was assigned to the plane for which flight. It’s all up to what’s more important to you.
5