UML 规范：我需要继承吗？答案

【问题标题】：UML specification : Do I need inheritance?UML 规范：我需要继承吗？
【发布时间】：2015-07-16 15:51:21
【问题描述】：

这是我的应用程序：目的是根据错误添加记录（但并非所有错误都会导致添加新记录，只有主要错误）。每个会话都有许多错误，然后内部服务将管理这些错误以了解哪些是主要错误（哪些是“小”错误，我的意思是暗示或相关或附加到此主要错误）。

UML 图：

所以我需要您对我的 UML 图的帮助和建议，您认为这是最好的方法吗？我真的需要在这里进行子类化吗（或者只是放置两个不同的类 Error 和 MainError 会更好）？

所以每个主要错误都有一个相关错误列表
一个主错误不能是另一个主错误列表的一部分
一个错误可能与许多主要错误相关联
我正在使用 JPA 开发 Java 应用程序
一条记录只与一个 MainError 相关联，而且显然有很多错误（因为每个 MainError 都有一个错误列表）

非常感谢

【问题讨论】：

这对于每个人来说都更容易推理您是否会停止使用除了关联端属性之外的列表。每个最大基数 > 1 的关联结尾已经是 UML 中的一个集合。
您的图表与您的文字不匹配。你说一个会话有很多错误，其中一些会被归类为主要错误。因此，该关联应该连接到超类。
您真正的问题是如何在 UML 中表达项目符号 2？
感谢 Jim 的回答，对不起列表（复制了关联端属性），我不应该将它们放在 UML 图中。关联应该连接到超类 Error ?因为我认为最好将它连接到 MainError，并且每个 MainError 都有一个错误列表，这就像将 Session 链接到错误，我错了吗？谢谢
你能修改你的图表吗？您应该使其与您的问题陈述相匹配。我认为部分问题可能是您尝试过早地进行优化。

标签： java jpa inheritance uml subclassing

【解决方案1】：

我认为下图将满足并清楚地重申您的要求。

这表示的是：

Session 遇到零个或多个 Errors
在一个Session 中遇到一个Error
Error 必须是一个且只有一个子类的实例（“完整”表示实例必须是子类的实例；“不相交”表示实例不能被多重分类，这在 Java 中是不可能的无论如何。）
Main Error 导致零个或多个 Subordinate Errors
Subordinate Error 由零个或多个 Main Errors 引起

这意味着每个Error 最初都创建为Unclassified Error，然后分类为Main Error 或Subordinate Error。

我没有费心为 Record 建模，因为它太模糊了，没有给讨论添加任何内容。

如果您要实现此模型，则关联端将进行名称更改，保留语义，同时变为 normalLookingCamelCaseForJava。以下是名称更改：

encounters 将变为 encounteredErrors 并且是 List<Error> 类型
encountered in 将变为 encounteringSession 类型为 Session
causes 将变为 causedSubordinateErrors 类型为 List<SubordinateError>
caused by 将变为 causingMainErrors 类型为 List<MainError>

在 JPA 中，您可以将所有错误类映射到一个带有鉴别器的表，这将使重新分类的性能更高。（请参阅changing entity type in JPA 了解如何执行此操作。）请注意，您可能希望将多对多关联映射到单独的关系数据库表。不过，这是一个单独的讨论。

【讨论】：

非常非常有趣！！非常感谢，所以我有几个问题：1）然后记录将链接到 MainError 而不是 Error 对吗？（记录 *-1 MainError） 2）错误将是抽象的，我显然不会有错误表？ 3) UnclassifiedError 的真正目的是什么？我调用服务 getError(Session) 然后我有所有错误，我将它们声明为 UnclassifiedError，然后我调用服务 manageErrors(UnclassifiedErrors) 它将创建 MainErrors 和从属错误列表，然后我将 MainErrors 和 SubordinateErrors 保留在数据库中?
1) 正确。 2) 在Java 中Error 应该是抽象的，但在UML 中，{covering} 约束是等价的。在 JPA 中，默认情况下，您会得到一个带有鉴别器的表。我希望该表将被称为Error。 3) UnclassifiedError 是您在不知道它是什么时创建的。是的，您的 manageErrors() 可以工作，尽管更好的名称可能是 classifyErrors()，或者暗示分析和分类的名称。
如果您觉得我的回答对您最有帮助，请按按钮接受。
非常感谢您的帮助！！既然你这么好，我还有几个问题 1）UnclassifiedErrors 不会在 DB 和 DAO 层中持久存在，我不会有任何与 UnClassifiedErrors 相关的方法，对吧？ 2）没有UnClassifiedErrors，我的方法是调用getError（Session），拥有所有错误，将它们声明为对象，然后调用classifyErrors（Errors），它将创建带有相关错误列表的MainErrors，然后我坚持在DB所有的错误（不是主要的）然后我坚持 MainErrors 所以我什么都不复制，我想最好使用 UnclassifiedEr 来避免这种情况？
3) 最后一个重要问题，Session 是否与 Error 相关？我如何在 JPA 中管理它？在 Session 类中我声明 List ？因为正如我所见，要知道每个会话的错误是什么，我可以访问它的 MainErrors，然后是这些 MainErrors 的从属错误（无论如何，我更想知道会话的 MainErrors 而不是它的错误）。非常感谢

【解决方案2】：

自己讨论图表。什么是Error？它只包含一个ErrorID。这不是很多信息。那么为什么要创建这样一个类呢？我看不出有任何理由。那么当没有理由时，为什么要创造它呢？你就在那里。这是多余的。您可能可以使用从 MainError 到 self 的关联。然后您可以将MainError 重命名为简单的Error。

【讨论】：