I'm drawing the class diagram that depicts the domain model of a system. This diagram is for requirements analysis purposes so it is completely implementation-agnostic.
I want to communicate the allowed values for some attributes in some objects. This is an example:
So basically it should act like an Enum. Is the diagram shown above UML compliant?
This problem can be solved in two ways: either by using the enumeration concept from the UML 2 standard, or by doing the simplest thing that works.
(based on the UML 2.5.1 standard)
UML has a native concept of enumerations that you could use here. Enumerations are a DataType, i.e. instances are solely identified by their value, unlike instances of a Class. An Enumeration consists of Literals. In a diagram, Enumerations are marked with the keyword «enumeration». The UML spec provides the following example of an Enumeration (Figure 10.4):
Because an EnumerationLiteral is an InstanceSpecification, I believe it could be assigned a value. The spec does not show an EnumerationLiteral with a value, but the correct syntax would be name = value. However, the semantics of this are not clear to me. Each EnumerationLiteral has a Classifier equal to the enumeration that the literal is part of. For example, in the above diagram public: VisibilityKind. It would not make sense to assign a value of a different classifier, e.g. public: VisibilityKind = 42 because 42 is an integer, not a VisibilityKind. Thus, I think it's best to treat EnumerationLiterals as opaque names, without assigning them a value in the model itself. It would of course be possible to have some method that converts between instances of an Enumeration and some other type.
In your scenario, we could represent Vote as the following enumeration (ASCII-Art):
+---------------+
| «enumeration» |
| Vote |
+---------------+
| good |
| bad |
+---------------+
The following is syntactically allowed, but has questionable semantics:
+---------------+
| «enumeration» |
| Vote |
+---------------+
| good = +1 |
| bad = -1 |
+---------------+
If you want a class with a value field, we could define the enumeration as a VoteValue and have your Vote class reference it, for example:
+------------------+
| Vote |
+------------------+
| value: VoteValue |
+------------------+
In your current diagram, you are denoting the type/Classifier as value: {+1, -1}. I don't think the UML notation supports such inline enums/unions – the property type must be a name. However, UML does not seem to define a syntax for names so it is possible to argue that this is indeed conforming.
It is rarely necessary or helpful to create a model that conforms to the UML standard. These models are usually just diagrams for human consumption, and need not be machine-readable. Then, the question isn't so much what the UML standard says, but what the intended recipient is likely to understand without ambiguity. Adhering to a common graphical vocabulary (such as the notation defined in the UML standard) has value to the degree that it avoids ambiguity.
On this level, your existing diagram is perfectly fine – it is clear about what the values of a Vote are allowed to be. The only thing I would change is to connect the note to the Vote::value property.
You can easily limit the possible values of a property with constraints . The syntax would first require a type and then be a constraint expression between curly braces. The expression should not be a set of values, but a boolean predicate, generally expressed informally in plaintext or more formally in OCL
value: Integer { either +1 or -1 }
value: Integer { Set{+1,-1}->includes(value) }
If you prefer symbols like GOOD and BAD, go for enumerations as suggested by @amon. However, each UML enumeration is a distinct data type, and while the syntax allows to associate literals to values, there's no semantics for it. If you intend to (mis?)use the enumeration for integer arithmetic instead of counting the different values, you could convey your intent with an explicit conversion operation getValue():Integer for the enumeration.
