将关联建模为UML中的Java枚举类图

我对UML类图中Java Enums关联的使用感到困惑。目前我正在建模一个包含具有一些属性的类Car类的系统。有些还枚举，就像FuelKind或CarBrand：将关联建模为UML中的Java枚举类图

有将是一个很多车在数据库（汽车是JPA实体），我问我自己这是FuelKind和CarBrand的最佳关联和基数。

我的想法到现在为止：

枚举实例被实例化自己，所以在技术上，他们不依赖于汽车。这些枚举在技术上也包含所有可用的“选择”，所以没有严格的依赖关系。所以它不能是它们之间的合成聚合。
一个汽车有一个CarBrand和一个FuelKind。但从另一方面来说：一种品牌或燃料种类是否有一辆汽车或多辆汽车？从逻辑上讲，多辆汽车可以从梅赛德斯或汽油驾驶。但从技术上讲，枚举实例没有链接到一个或多个汽车。

你对如何解决这个问题有一些建议和想法吗？

来源

2016-04-12 jverhoelen

你做得很对。直接关联是这种情况的正确关系。

为了阐明关联指向类中的特定属性，请使用目标角色。这显示为一个文本标签，其属性（fuelKind）的名称在连接器的列举结束处（而非类结束）。

如果你有两个相同的枚举类型的属性，你将不得不绘制两个单独的关联。

但是，由于您在属性中使用的是类型名称，因此根本不需要绘制任何关系。但是如果你这样做，与目标角色的定向关联在语义上等同于命名属性中的类型。你选择的是一个风格问题，如果它有助于澄清事情，你可以同时做两件事。

至于关系走向另一方面，关联的定向性意味着关系是单向的。换句话说，按照您所做的方式绘制它并不表示从枚举类型返回到类的关系。而对于枚举类型，通常不应该存在，除此之外，还有整数或字符串的关系。

来源

2016-04-12 10:47:18 Uffe

谢谢，你的回答澄清了这种情况相当不错。另外有趣的是，对于两个属性会有两个单独的关联，以前从未看到过。为了澄清，我认为属性命名对我来说已经足够了。 – jverhoelen

说“如果有助于澄清事情，你可以做到这一点”就像说“你可以搞砸你的图，如果它有帮助”。表达与财产和协会的关联（结束）令人困惑并且气馁。 –

如果有帮助，你可以*弄乱你的图表。 UML是一种文档，而不是宗教。在任何情况下，什么是正确的取决于几件事情，包括目标受众。如果你是目标受众，你可能会感到困惑，如果我是目标受众，我可能会说这是多余的。但是，如果模型的目的是被认识Java而不是UML的人阅读，那么同时使用这两种风格可以帮助他们阅读该图，但不会引起混淆，因为他们知道在Java中两个属性不能具有相同的名称。 – Uffe

这是不正确的。枚举是一个数据类型，而不是一个类。所以你只需将它分配给Car类中的属性即可。你可以用一个依赖项来指明你在一个类中使用了一个特定的枚举类型。

来源

2016-04-12 10:54:36

关联在技术上没有问题。它可能在风格上与其他属性类型不一致，但它是正确的。 –

即使用于普通（例如，字符串值）属性，使用关联也是正式正确的，但这会很麻烦并且违反了最佳实践。 –

@JimL。语法正确。实际上更可疑。这就是为什么我说这是不正确的。由于UML特别提供了枚举，所以定义类的枚举也是过度的。 –

将关联建模为UML中的Java枚举类图

回答

相关问题