HashMap in class diagram (UML)

问题:

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?

回答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).

回答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?

回答3:

HashMap is only one of many java classes.
And you can use any java class, interface or primitive type in your UML 2.0 class diagramm.
Any datatype in the UML 2.0 java class diagram corresponds to some java class, interface or primitive.

You are using the UML diagram for development of your own application. So, feel free to extend the UML 2.0 standard for your convenience. Noone can blame you for this.

回答4:

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.