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 Diagram :

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) ?

• So every Main error has a list of its related errors
• a Main Error cannot be part of another MainError's list
• an error can be associated to many Main Error
• I am working on Java application with JPA
• A record is associated with only one MainError and obviously many errors(as every MainError has a list of errors)

Thank you very much

回答1:

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

What this expresses is:

• 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

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.

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

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 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>

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.

回答2:

Discuss the diagram yourself. What is an Error? It just consists of an ErrorID. This is not much of an info. So why create such a class? I would not see any reason for it. So when there is no reason, why create it? And there you are. It's superfluous. You can probably go with an association from MainError to self. Then you can rename MainError to be simply Error.