The goal of a class diagram is to document relationships between classes as well as how objects of those classes can change:
In software engineering, a class diagram in the Unified Modeling
Language (UML) is a type of static structure diagram that describes
the structure of a system by showing the system's classes, their
attributes, operations (or methods), and the relationships among
objects.
Source: Wikipedia
The key elements here are:
- Relationships between classes: given a class, what other classes does it use?
- Operations that can be performed on a class: what methods/functions belong to a class?
- State belonging to a class: what data does a class encapsulate?
A constant does not fit into any of these elements. It is not a relationship, and certainly not an operation. The closest element is state, but a constant is pretty much the opposite: it is static, and not tied to an object. While a class diagram documents classes, it is focused on elements of classes used by objects of those class types.
In your specific example, I would do the following:
The enum
would be a class in the diagram, but would likely be empty. The only state is the integer that represents each enum value, but that is essentially a surrogate key and not referenced in code. Note that if you use a C++ enum class
instead, you might have state worth documenting.
The struct
should be a class with no behavior, but the state documented as public.
Those constants should not be documented in a UML class diagram. For one, they do not belong to a class, making them completely irrelevant. Two, constants do not belong in a class diagram anyway for reasons I outlined above.
I would create a separate UML package diagram for namespace helper
(as an aside, I recommend picking a more descriptive name for this namespace) showing that the enum
and struct
are in the namespace. This diagram type also allows for documenting static members in general and constants specifically.