Skip to content

UML modelling enumeration with attributes

I would like to create an UML diagram with Java enumerations (enum), that have one or more attributes, but I am confused about how to do it.

For example an enum could be declared like this:

public enum Enumeration_type {

   LITERAL_A("attr1_value", attr2_value, attr3_value),
   LITERAL_B("attr1_value", attr2_value, attr3_value);

   final String attr1;
   final type_1 attr2 = initial_value_1;
   final type_2 attr3;

   Enumeration_type(String attr1, type_1 attr2, type_2 attr3) {
      this.attr1_value = attr1;
      this.attr2_value = attr2;
      this.attr3_value = attr3;

Without the attributes, it is easy:

|   <<enumeration>   |
|  Enumeration_type  |
|  LITERAL_A         |
|  LITERAL_B         |

But how do you model it with attributes elegantly? Should it be like this?

|   <<enumeration>>                                   |
|  Enumeration_type                                   |
|  attr1: String                                      |
|  attr2: type_1 = initial_value_1                    |
|  attr2: type_2                                      |
|  LITERAL_A("attr1_value", attr2_value, attr3_value) |
|  LITERAL_B("attr1_value", attr2_value, attr3_value) |

I found only this example here, but that uses the String class attributes as enum names. I think, that should be different to usage of public enum without specifying the enum names data types.

|   <<enumeration>>                       |
|      CarType                            |
|  +sedan : String = SEDAN                |
|  +liftback : String = LIFTBACK          |
|  +stationWagon : String = STATION_WAGON |



I don’t think you can model the attribute values for each of the enumeration literals in UML.
EA uses the following notation for an enumeration that has attributes:

enter image description here

You can either document the attributes values somewhere in the notes of each literal, or you could use an excel file or something similar to manage that data.
Often you are only required to provide the initial values at design-time as they might change at run-time. So there’s not much use to keep those values in your model if you cannot trust them to be correct.