In UML ROAD, CAR and NOTHING are EnumerationLiteral and in a class diagram they are shown in the compartment literals showing their name, and nothing more of them.

An enumeration being a Datatype may have property, however the attribute code from your Java cannot be supported by a property as your did because it does not concern the enumeration but the EnumerationLiteral.

Of course an EnumerationLiteral is not a property of the enumeration nor an instance of the enumeration, but an InstanceSpecification.

So there is nothing the standard allowing to model code and its value for each enumeration literal until you extend the enumeration through a stereotype to add code as a StructuralFeature, in that case the values of code will be specified through a Slot

In formal/2017-12-05 see :

• § 10.5.3 Enumeration page 175
• § 10.5.4 EnumerationLiteral page 175 and 176
• § 9.9.9 InstanceSpecification page 140

[edit]

Alternative representation in UML inspired by the reading of Christophe's answer.

An other way is to completely forget the UML EnumerationLiteral and to model each Java enumeration literal through a dedicated instance itself available through a static read-only attribute.

AsciiCodes can be still an UML enumeration.

Note in your Java definition and above the value of code is unavailable from outside, then finally useless until an operation is added to return it as proposed in Christophe's answer.

By the way this is how I still implement the enumerations in the API of the plug-out of BoUML for Java, using the stereotype enum_pattern specially managed by the Java code generator. I started to distribute BoUML in 2005 when the enumeration did not yet exist in Java.

I'd like to add some nuance to Bruno's excellent and inspiring answer.

Can an enumeration have properties and operation in UML?

An UML enumeration is a classifier. As such, it can perfectly have its own properties and operations, even if most of the time it only defines enum litterals (see also this SO answer). This is very close to Java enums.

Java enums provide however some syntactic sugar which allows to associate one or several constant values to each enum literal. The language allows you to define a private constructor that uses these constant values to initialize the enum object. This means that you could very well represent your enumeration in UML as follows:

What with constant values associated with enum litterals?

Nothing in UML allows you to model the constant value(s) associated to an enum litteral. But nothing has to: this is simply an implementation detail. If you want the constants in the model, you could document them in a note (I wouldn't go that way because it just clutters the diagram with implementation details that do not help to understand the design).

You have two choices for clarifying the initialization:

1. You define an explicit constructor with the same signature as in your code, with the advantage that it's close to your code. But UML is not an alternative to code, isn't it?. The inconvenience is that it is misleadingly unclear for an UML reader: it gives the impression that these initialization parameters are free;
2. You rely on a constructor without parameters. The advantage is that it reflects the design reality: the constructor parameters are not free since Java invokes the constructor with the constant values which are directly deduced from the enum litteral.

I'd advise for 2, because it conveys the real design intent. Without the syntactic sugar, you'd probably write a very long case statement to initialize the properties with the right values depending on the enum litteral.

What with the other Java enum features?

The UML enumeration doesn't provide anything beyond what you explicitely define.
But Java enums all specialize java.lang.Enum, which offer operations such as name() or class operations such as values().

If you want to convey the availability of such language-specific features, you could define your own stereotype «Java enum» that specializes the standard UML enumeration metamodel element.