3

I am confused about the usage of associations with Java Enums in UML Class diagrams. Currently I am modelling a system containing a Car class that has some properties. Some are also Enums, just like FuelKind or CarBrand:

enter image description here

There are going to be a lot of cars in the database (Car is a JPA entity) and I'm asking myself which is the best association and cardinality to FuelKind and CarBrand.

My thoughts until now:

  • Enum instances are instantiated on their own, so technically they do not depend on Car. Also non-technically those enums contain all available 'choices', so there is no strict dependency. So it can not be a Composition Aggregation between them.
  • One Car has one CarBrand and one FuelKind. But from the other side: Does one brand or fuel kind have one car or multiple cars? Logically multiple cars can be from Mercedes or driving on petrol. But technically a enum instance has no link to one or multiple cars.

Do you have some suggestions and thoughts on how to solve this problem?

qwerty_so
  • 35,448
  • 8
  • 62
  • 86
jpietzsch
  • 536
  • 5
  • 18

2 Answers2

6

You're doing it almost right. A directed association is the correct relationship for this situation.

To clarify that the association refers to a specific attribute in the class, use a target role. This is displayed as a text label with the name of the attribute (fuelKind) at the enumeration end (not the class end) of the connector.

If you had two attributes of the same enum type you would then have to draw two separate associations.

However, since you are using the type names in the attributes you don't actually need to draw any relationships at all. But if you do, a directed association with a target role is semantically equivalent to naming the type in the attribute. Which you choose is a matter of style, and you can do both if it helps clarify things.

As to a relationship going the other way, the directed nature of the association means that the relationship is one-way. In other words, drawing it the way you've done does not indicate a relationship from the enum types back to the class. And for enum types there normally shouldn't be, any more than there are such relationships for integers or strings.

Uffe
  • 10,396
  • 1
  • 33
  • 40
  • Thanks, your answer clarified that situation pretty well. Also interesting that there would be two separate associations for two attributes, never saw that before. For the purpose of clarification I think the attribute naming is sufficient for me. – jpietzsch Apr 12 '16 at 12:07
  • Saying "you can do both if it helps clarify things" is like saying "you can mess up your diagram, if it helps". It's confusing, and discouraged, to express an association both with a property and an association (end). – Gerd Wagner Apr 12 '16 at 13:34
  • You *can* mess up your diagram if it helps. UML is a type of documentation, not a religion. What's right in any given situation depends on several things, including the target audience. If *you* are the target audience you might be confused, and if *I* am the target audience I might say it's redundant. But if the model is intended to be read by people who know Java but not UML, using both styles at once can help them read the diagram but won't cause confusion since they know that in Java two attributes cannot have the same name. – Uffe Apr 13 '16 at 11:20
4

This is not correct. An enumeration is a datatype, not a class. So you just assign it to your attribute in the Car class. You can indicate with a dependency that you are using a specific enum in a class.

enter image description here

qwerty_so
  • 35,448
  • 8
  • 62
  • 86
  • There is technically no problem with an association. It may be stylistically inconsistent with other attribute types, but it's correct. – Jim L. Apr 12 '16 at 12:43
  • It's formally correct to use an association, even for for ordinary (e.g., string-valued) attributes, but it would be cumbersome and violating best practices. – Gerd Wagner Apr 12 '16 at 13:27
  • @JimL. Syntactically correct. Practically more than doubtful. This is why I said it's not correct. Defining an enum from a class is also overkill since UML offers an enum specifically. – qwerty_so Apr 12 '16 at 13:32
  • @gwag See my comment to Jim – qwerty_so Apr 12 '16 at 13:32
  • @ThomasKilian: not best practice != incorrect. I break the "datatype as attribute" rule all the time for enumerations because it looks better and it's easier for the reader to find the enumeration and see some literals to understand its semantics. Also, I don't know what you mean by, "*Defining* an enum from a class". Using an association doesn't do that. – Jim L. Apr 12 '16 at 13:35
  • @JimL. Well, we discussed that. UML lets enums appear as stereotyped classes. And the above shows stereotyped classes. But then the question is about enums. And those are pre spec just datatypes. – qwerty_so Apr 12 '16 at 13:39
  • 1
    I disagree with "UML lets enums appear as stereotyped classes." Reference please? – Jim L. Apr 12 '16 at 13:44
  • @JimL. Fig 10.4 p. 167 in formal 15-03-01. How does this look different to a class stereotyped `<>`?? – qwerty_so Apr 12 '16 at 14:17
  • 1
    I think you mean, "In UML, an enumeration is unfortunately visually *indistinguishable from* a class stereotyped as «enumeration». I took what you wrote to mean "UML *allows* enums to appear as stereotyped classes". Under the indistinguishable surface notation, UML does *not* allow you to create an enumeration *as* a stereotyped class on a diagram. (I've seen people do that, even on SE answers!) – Jim L. Apr 12 '16 at 14:44
  • @JimL. Hehe. That's what UML is all about: clarify communication between people which is ambiguous using plain text. – qwerty_so Apr 12 '16 at 15:23