The most important is that it is clear from the use case description that a choice must be made between the search and the browse functionality.
In your diagram, the 'add to basket' use case should <<include>> both the 'search products' and 'browse products' use cases (assuming that the choice for searching or browsing is made from the 'add to basket' use case). If you really want to show that those included use cases are mutually exclusive, you can add a UML constraint { mutually exclusive } linked to the inclusion arrows, but that is completely optional.
- 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
Use case diagrams are always a bit weird. These diagrams tend to have the following use cases:
If your goal is to show all use cases, then yes, that will necessarily get a bit messy. Your diagram is fine!
Alternatively, you might notice that the two main use cases “analyze risks” and “resilience management” seem entirely disconnected, so you could split them into separate diagrams.
Models such as UML diagrams are just a simplified view of reality. Every model has some goal or viewpoint. It is necessary to prioritize, arrange, and even omit information in order to communicate the goal clearly.