HashMap in class diagram (UML)

Question

I build UML 2.0 class diagram for my Java application. In my code I have attribute with HashMap datatype. But, as I know, there is no HashMap datatype in UML standard. The question is - can I use HashMap as datatype for attribute of the class?

UPDATE

maybe in diagram I just should point to java.util package? and maybe place Map class in this package on the diagram?

Solution 1

HashMap should not appear in your UML model anyway. HashMap is just an implementation of a qualified association. Probably it's even just a speed improved unqualified association. So if you had a Class A with a HashMap you would model a UML Class A, a UML Class B and a UML Association from A to B. You can add a qualifier to the association if it's qualified by a key which is not an attribute of B. If your HashMap key is the name of B (and B has that name as an attribute) you would simply omit the qualifier.

To denote the implementation of your Association (you want to implement it with a HashSet) you can add that as a keyword or create a Stereotype for it (more complex).

Solution 2

Just use a normal class in UML and call it HashMap. UML is language-agnostic and has no knowledge of Java's predefined classes. Or did I misunderstand your question?

Solution 3

HashMap may be the Java name for the concept, but every programming language has some kind of Hash<> or Map<> class, and something equivalent should be included in UML because many models include Hash or Map container attributes.

Some tools support a <<map>> stereotype; if you have that I would use it if you are mainly concerned about visual intuitiveness - but it's not possible to say what kind of key is implied.

The qualified association graphical UML device is non-intuitive and I suspect hard for tools to transform to anything sensible in a forward code generation. I would avoid it.

The other way to do it (which is what I usually) do is the following:

• create a Hash class with V and K as generic parameters. To do it correctly, K should really be constrained by a class such as 'Ordered' also lacking in UML (we always add this)
• for every use of Hash e.g. Hash<Thing, String> (be careful with the order - I use value first, key second), create a UML class called Hash<Thing,String> and an outgoing relation to Hash<> and then map the V and K to actual parameters Thing and String
• then in the class that wants to use it, define a property e.g. things whose type is the Hash<Thing,String> type.

MagicDraw for example supports this.

The downside of this is that you won't see an association link between the client class and the value type (Thing in my example). The upside is that if you publish your models as programmer specifications, which is what we do, programmers see the right thing in the class tables, as you can see in this example - translation_details attribute.

The difficulty in doing this basic task in UML is just one of the numerous problems with UML, and why most developers I meet today don't use it other than for pictures on whiteboards or documentation.

Comments

[Christian]

HashMaps do not belong into a UML model. Especially not as first class Classifiers.

[Christian]

If you really have to use Java classes in your UML model (I wouldn't recommend it) this is just extending your model (or a library model). Extending the UML is done via profiles - in this case it is not needed.

[Tudor]

@Christian: What you are saying makes no sense. I can create any data type in UML. What prevents me from calling a class HashMap and setting a composition relation to another class if I want to?

[Martin Spamer]

HashMap is class, it should certainly exist in the UML model. However not every class needs to appear on a diagram as a class.

[Christian]

You /can/ put it into the UML model, of course. Nothing prevents you from doing it. It's just not good style to put implementation details into a conceptual model where you don't need to do so. See my answer for another approach.

[Christian]

btw. most UML tools provide a special profile for Java, so unlike UML your model is not necessarily language agnostic