HashMap может быть именем Java для концепции, но каждый язык программирования имеет некоторый класс Hash<> или Map<>, и что-то эквивалентное должно быть включено в UML, потому что многие модели включают атрибуты контейнера Hash или Map.
Некоторые инструменты поддерживают стереотип <<map>>;если у вас есть это, я бы использовал его, если вы в основном озабочены визуальной интуитивностью - но невозможно сказать, какой тип ключа подразумевается.
Графическое UML-устройство квалифицированной ассоциации не является интуитивно понятным, и я подозреваю, что инструментальные средства трудно преобразовать во что-либо разумное при генерации прямого кода.Я бы этого избегал.
Другой способ сделать это (что я обычно и делаю) заключается в следующем:
- создать класс Hash с V и K в качестве общих параметров.Чтобы сделать это правильно, K действительно должен быть ограничен таким классом, как 'Ordered', также отсутствующим в UML (мы всегда добавляем это)
- для каждого использования Hash, например
Hash<Thing, String> (будьте осторожны с порядком -Сначала я использую значение, затем ключ), создаю класс UML с именем Hash<Thing,String> и исходящее отношение к Hash<>, а затем сопоставляю V и K с фактическими параметрами Thing и String - , затем вкласс, который хочет использовать его, определите свойство, например
things, тип которого является типом Hash<Thing,String>.
Например, MagicDraw поддерживает это.
Недостатком этого являетсячто вы не увидите связь между классом клиента и типом значения (Thing в моем примере).Плюс в том, что если вы публикуете свои модели в виде спецификаций программистов, что мы и делаем, программисты видят правильные вещи в таблицах классов, как вы можете видеть в в этом примере - translation_details attribute.
Сложность в выполнении этой основной задачи в UML является лишь одной из многочисленных проблем, связанных с UML, и поэтому большинство разработчиков, с которыми я встречаюсь сегодня, не используют ее, кроме как для изображений на досках или в документации.