I am creating a UML class diagram for a C++ project and would like to correctly represent strongly typed identifiers implemented via templates and type aliases, as well as plain data structures (struct) used as domain objects.

In the code, identifiers are implemented using a tag-based template to achieve type safety:

template 
class Id {
    // some fields
};

struct AxisIdTag {};
struct RunIdTag  {};
struct ReportIdTag {};
struct RecordIdTag {};

using AxisId   = Id;
using RunId    = Id;
using RecordId = Id;
using ReportId = Id;

There are also regular domain types such as enumerations and data structures:

enum class ErrorCode {
    // some fields
};

struct Error {
    ErrorCode code{};
    std::string summary;
    std::optional details;
    std::optional axisId;
    std::optional runId;
    std::chrono::system_clock::time_point timestamp;
};

Goal of the diagram

The goal of the class diagram is not to reflect C++ syntax one-to-one, but to communicate design intent:

• that AxisId, RunId, etc. are distinct domain identifiers,
• that they are all based on a common Id abstraction,
• that type safety is an intentional part of the design,
• and that some types (such as Error) are intended to be data carriers / value-like domain objects.

I understand that UML does not have a direct notion of C++ using aliases or a dedicated struct construct, and that some of these elements are implementation details. However, I would like the diagram to express the conceptual model as accurately as possible.

Question

What is the idiomatic or commonly accepted way to represent the following in a UML class diagram?

• Template-based strong ID types such as Id
• Type aliases like AxisId, RunId, etc.
• Plain data structures (struct) that primarily act as immutable or semi-immutable data carriers

For example:

• Should Id be shown as a template class with template bindings?
• Should AxisId, RunId, etc. be modeled as template specializations, stereotypes (e.g. <>), or omitted and documented via notes?
• Should struct Error be modeled exactly like a UML class, or annotated with a stereotype such as <> or <>, <>?
• Is there a preferred way to balance clarity of the domain model against overloading the diagram with C++-specific implementation details?

For reference, here is part of the diagram I am currently working with: image / PlantUML on pastebin

I would appreciate guidance on whether this approach reasonably communicates the intended design, and what alternatives might be clearer or more idiomatic in UML.