How to represent a Map<Enum, Class> relationship in a UML class diagram? [closed]

Question

I have a class Car, an enum Position, and a class Wheel. In Car, I have a map attribute: private Map<Position, Wheel> wheels;

I want to represent this structure in a UML class diagram. My questions are:

1. Since the Map uses Position (an enum) as a key and Wheel as a value, does this automatically create a relationship between Car and both Position and Wheel?

2. Should I explicitly show an association to Position, or is it implied? Would this relationship between Car and Wheel be considered an aggregation since Car "contains" multiple Wheel instances and a Wheel could exist independently of Car?

3. How should I best represent this in UML? Any insights would be appreciated!

I tried representing Car with an association to Wheel, using an aggregation (a hollow diamond) since Car could contain multiple Wheel objects. For Position, I considered showing it as an enumeration without a direct association, assuming that its use in the Map is implicit.

Answer 1

The design intent behind using a java map in your design is to qualify the association between Car and Wheel: You want to Car to be associated with Wheel but in such a way that the Wheel is determined by the Car and the Position .

The most suitable way to represent a map natively in UML is the qualified association; The advantage of this design is that it is language independent. In Java it would be a map, but in Swift or in Python it would be dictionary:

It also visually suggests that the map is with the car (although this is not a valid interpretation of the UML specs).

I didn't put the multiplicities as your narrative is not clear on the exact intent:

• The multiplicity 0..1 on Wheel side, would mean that for a given Car and a given Position there can be a Wheel (but this means also that for a Car there can be several Wheels linked (at most one for a given position).

• The multiplicity 1 on Wheel side, would mean that there must be a Wheel for every possible value of Position. If position is an enumeration with only 4 values, it's ok. If Position would be some open-ended data type with million's of possible values, it'd be wrong.

There are other very suitable ways to represent an equivalent semantic. There is in particular the association class:

This design tells that there are up to 4 wheels for a car. It also says that for each link between an instance of Wheel and an instance of Car there is a Position attribute. You'd need to indicate that the same wheel is not used several time at different positions, adding a {unique} adornment. This design is better supported by design tools, and it is your right to implement it with a map. Personally I would not use this to model for documenting a map in general, but this would be my first pick for the positions in a car.

In this model you could also chose to to show no attribute for WheelPosition but associate this association class with your «enumeration» Position.

A last way to model your design is to use a ternary association. But be aware that many people are confused with multiplicities in ternary associations.

With the ternary association, you already show that Car is also somehow associated with Position. In the association class with the variant of the additional association, you show visually that Car is also somehow associated indirectly with position. You may also add a direct association between Car and Position, to show that the car has wheel-positions even in absence of any wheel. But it also makes the diagram heavier to read, so I'd avoid it.