UML规范:是否需要继承? [英] UML specification : Do I need inheritance?

问题描述

这是我的应用程序:目的是基于错误添加记录(但并非所有错误都会导致添加新记录，只有主要错误会导致添加). 每个会话都有很多错误，然后内部服务将管理此错误，以了解哪些是主要错误(以及哪些是小"错误，我是指这个主要错误的隐含或相关或附加的).

Here's my application : the purpose is to add records based on errors (but not all errors will result in adding a new record, only the Main Errors). Every session has many errors, then an internal service will manage this errors to know which are the Main Errors (and which are the 'small' errors, I mean the implied or related or attached to this Main Error).

UML图:

因此，我需要有关我的UML图的帮助和建议，您认为这是最好的方法吗?我真的需要这里的子类吗(或者也许只把两个不同的类Error和MainError会更好)?

So I need your help and suggestions about my UML Diagram, do you think that is the best approach? do I really need the subclassing here (or maybe just putting two different classes Error and MainError would be better) ?

• 因此每个主要错误都有其相关错误的列表
• 一个主要错误不能成为另一个主要错误列表的一部分
• 一个错误可能与许多主要错误相关联
• 我正在使用JPA开发Java应用程序
• 一条记录仅与一个MainError和显然很多错误相关(因为每个MainError都有一个错误列表)

非常感谢您

推荐答案

我认为下图将满足并清楚地陈述您的要求.

I think the following diagram would satisfy and restate your requirements clearly.

这表示:

• 一个Session遇到零个或多个Errors
• 在一个Session中遇到一个Error
• Error必须是一个实例，并且只能是其子类之一("complete"表示实例必须是子类的实例；"disjoint"表示实例不能被多重分类，这在Java中是不可能的)无论如何.)
• A Main Error导致零个或多个Subordinate Errors
• Subordinate Error是由零个或多个Main Errors
引起的

• A Session encounters zero or more Errors
• An Error is encountered in one Session
• An Error must be an instance of one and only one of its subclasses ("complete" means an instance must be an instance of a subclass; "disjoint" means an instance cannot be multiply classified, which is impossible in Java anyway.)
• A Main Error causes zero or more Subordinate Errors
• A Subordinate Error is caused by zero or more Main Errors

暗含的是，每个Error最初都是作为Unclassified Error创建的，后来又分为Main Error或Subordinate Error.

What is implied is that every Error is initially created as an Unclassified Error and later classified into either a Main Error or a Subordinate Error.

我不必为Record建模，因为它太含糊了，没有给讨论增加任何东西.

I didn't bother to model Record, as it is far too nebulous and adds nothing to the discussion.

如果要实现此模型，则关联末端将进行名称更改，该名称更改将在变为normalLookingCamelCaseForJava时保留语义.这是名称更改:

If you were to implement this model, the association ends would undergo a name change that retains semantics while becoming normalLookingCamelCaseForJava. Here are the name changes:

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

• encounters would become encounteredErrors and be of type List<Error>
• encountered in would become encounteringSession of type Session
• causes would become causedSubordinateErrors of type List<SubordinateError>
• caused by would become causingMainErrors of type List<MainError>

在JPA中，您可以使用鉴别符将所有错误类映射到一个表，这将使重新分类的性能更高. (有关更改JPA中的实体类型，请参见更改实体类型请注意，您可能希望将多对多关联映射到单独的关系数据库表.不过，这是一个单独的讨论.

In JPA you could map all the error classes to one table with a discriminator, which will make the reclassification much more performant. (See changing entity type in JPA for an idea of how you might do so.) Note that you might want to map many-to-many associations to separate relational database tables. That's a separate discussion, though.

这篇关于UML规范:是否需要继承?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！