An association links one class to another to indicate a relation between them. For example, you have an association between Customer and Order which (with no further information) indicates that:
A customer can have an order or maybe several orders,
An order can belong to a customer or maybe shared by several customers.
The diagram in your question gives an additional info: there is one and only one customer by order, and zero or more orders by customer, so the rules become:
A customer have zero or more orders,
An order belongs to one and one only customer.
While aggregation is used in the association between Order and OrderDetail, it's not used in the association between Customer and Order. This is done to indicate the life cycle dependency. If an instance of the Order is destroyed, all instances of OrderDetail inside it would be destroyed too; on the other hand, the instances of Order are independent of the life cycle of the Customer instance, thus no aggregation here.
This doesn't mean that an order can exist without a customer: the 1 ↔ 0..* association explicitly forbids the orders which have no customers. The difference between a 1 ↔ 0..* association and the aggregation really happens on life cycle level.
- 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.
Best Answer
In principle, there is nothing wrong with your UML diagram.
However, it does suggest to me that the Cards referenced by the Player class are different instances than those held in the Deck. This might be an artefact of how I interpret an aggregation relation, for which there is no consensus.
With regard to the members shown in the classes,I am assuming that the semantics are based upon languages like Java and C#: Objects live all on the heap and are only accessible through references.
Depending on what you want to model, you can improve the diagram in two ways:
With respect to the multiplicity, you can leave it out on the diamond-side of a composition relation, because it should always be 1.
If you compare your diagram to others, you may find that often the class members corresponding to associations/aggregations/compositions are left out, because they don't add any information. Also, multiplicities are often left out of the diagram, especially if they can be inferred from the context.