I have a MyServer class that contains a Map whose keys are MyClientType objects and whose values are MyClient objects. I\'d like to depict this relationship in a class diagr
Kru's answer is the best, but it still only hints at a Map.
I would argue it depends on the level of abstraction at which your diagram sits. If it's relatively high, I'd go with chimp's response. If it's relatively low and you really need to show a map, intentionally showing implementation-related detail, I'd go with the following:
MyServer
|
|
Map
|
|*
T1toT2
/ \
1/ \1
Key Value
How the map is then implemented in code is totally irrelevant (T1toT2
run-time objects might not actually come to be).
As mentioned by Gabreil, this could be also be modelled using an association class
MyServer
|
|
Map
|
|*
T1toT2
|
|
1--------1
Key Value
Of course is only matters if you really really need to show or specify a map.
MyServer
|
|
|
Map
|
| |
| |
MyClientTypeKey MyClientType
Should it not be quite simple like above?
I would just show an association from MyServer to MyClient with a multiplicity of 0..* at the MyClient end. Everything else is implementation detail and can be left to the programmer.
First of all I and some others think, UML should contain some basic collection types as it did in some earlier versions. They could be taken for example from the OCL...
The "EMF way" seems right, however it gives imho too much importance to the to type, which is really unimportant imho, so I would model it just as an association class. This will enable you to capture all map specific constraints (as e.g. multiplicity) which can be captured using regular class, but won't make that class as important as the other ones.
MyServer
|
|*
T1toT2
/ \
1/ \1
Key Value
The difference to Mark's solution is that the server has a many-relation to the containers. That's also how the Eclipse Modeling Framework (EMF) proposes to implement maps.
You might also throw in some more UML-specific things, like specifying that the keys have to be unique (through stereotypes).
You can use a qualified association:
┌──────────┐ 1 ┌───────┐
│ MyServer │Key│───────────│ Value │
└──────────┘ └───────┘
See: http://etutorials.org/Programming/UML/Chapter+6.+Class+Diagrams+Advanced+Concepts/Qualified+Associations/ (cause it is hard to draw using ASCII)
Note also that a qualified association changes the multiplicity:
┌──────────┐ 0..* ┌───────┐
│ MyServer │───────────────│ Value │
└──────────┘ └───────┘
┌──────────┐ 1 ┌───────┐
│ MyServer │Key│───────────│ Value │
└──────────┘ └───────┘
The top illustrates an association from a server to 0-n values. By contrast, the qualified association says that any given key will be associated with only one value, and that you can't have a key an absent value.