HashMap may be the Java name for the concept, but each 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 the stereotype <<map>> ; if you have this, I would use it if you are mostly concerned about visual intuitiveness - but it's impossible to say which key is implied.
A qualified UML graphic device is not intuitive, and I suspect that tools for converting to anything reasonable in forward code generation are difficult. I would avoid that.
Another way to do this (which I usually do):
- create a Hash class with V and K as common parameters. To do this correctly, K really needs to be limited to a class, such as "Ordered", also missing from UML (we always add this)
- for every use of hash, for example.
Hash<Thing, String> (be careful with the order - I use the value first, the second is the key), create a UML class named Hash<Thing,String> and an outgoing relation to Hash<> , and then match V and K with the current parameters Thing and String - then in the class that wants to use it, define a property, for example.
things whose type is of type Hash<Thing,String> .
MagicDraw, for example, supports this.
The disadvantage of this is that you will not see an association link between the client class and the value type ( Thing in my example). The good news is that if you publish your models as programmer qualifiers, which we do, programmers see the right thing in class tables, as you can see in this example - translation_details attribute .
The difficulty in performing this basic task in UML is just one of the many problems with UML, and why most of the developers I meet today don't use it except for images on boards or documentation.