2
---------------------    ----------------------
|       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?
  • 2
    It's a many-to-many relationship You need a FLIGHT_STEWARD entity containing Flight ID and Steward ID. – Robert Harvey Dec 11 '14 at 21:44
  • @RobertHarvey Ah, I didn't know class diagrams have the concept "link classes". Thanks, I'll do some research. – user1534664 Dec 11 '14 at 21:51
  • 2
    RobertHarvey is right, but realistically you can't make any useful UML diagram without knowing generally what the system is supposed to do. Building UML diagrams in the absence of use cases is futile. A group at American Airlines once spent 18 months with SoftwareThroughPictures making UML diagrams of airline operations, and they still weren't finished. Finally someone picked a real problem to solve, and all that work was ignored. All the "analysts" went off to find another position with no measurable deliverables. – kevin cline Dec 12 '14 at 0:19
  • @user1534664: "link classes" can exist in class diagrams, but they are extremely rare. This is in part because class diagrams can directly show a many-many (*..*) relation without the need for a "link class". – Bart van Ingen Schenau Dec 12 '14 at 9:43
  • @BartVanIngenSchenau Makes sense in a way, as you can have a list of the other class in both classes. – user1534664 Dec 12 '14 at 11:03
5
  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.

  • Amazing answer. Bedankt :P For item 4: I don't really understand the concept of a relation being able to have "strength". Can you elaborate on that? Also, when do we specify the a in the multiplicity a..b? I understand how its useful when modelling ERDs, but class diagrams are slightly different. – user1534664 Dec 12 '14 at 12:31
  • @user1534664: You specify a range (a..b) in the multiplicity if any value from that range satisfies the multiplicity requirements. A common one is for an optional relation, where you would use 0..1 to indicate that the association will have either one or no instance of the class on that end. – Bart van Ingen Schenau Dec 12 '14 at 13:02
  • @user1534664: The strength of a relation should become clearer when aggregation & composition have been discussed in class. If it is still unclear after that, feel free to as a new question about it. – Bart van Ingen Schenau Dec 12 '14 at 13:03
1

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 Flight/Assignment Diagram

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.

  • 1
    -1: Where did "Plane" come from? There's no hint that this system needs to do anything with equipment. – kevin cline Dec 12 '14 at 0:20
  • I forgot, people just magically fly on their own now. I was extrapolating to demonstrate some logical assumptions and how modeling can be used for discovery. If the Plane is unnecessary guess what, it can be erased from the model. That's the beauty of UML. – Michael Brown Dec 12 '14 at 0:37
  • @MikeBrown Thanks for the example. I understand that's one way to model the situation. Can you try and elaborate on my list of confusions? I still can't really answer them. – user1534664 Dec 12 '14 at 11:04
  • 1
    @Mike: That's the problem with domain-driven design. It never ends. Sure, people need to fly on planes. But they don't teleport themselves onto the aircraft, so we better add "Gate" and "GateAssignment". And those planes require regular maintenance, so we better add "MaintenanceSchedule" and "Mechanic" and "MaintenanceTask" and ... – kevin cline Dec 15 '14 at 19:41
  • 2
    Well it requires discretion to realize what's pertinent to your solution. From an airline management perspective, aircraft, gate assignments, and crew assignments are all conceptually applicable. Even if they are not important to the solution at hand, modelling them and marking them as out of scope can still be beneficial. – Michael Brown Dec 15 '14 at 19:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.