An Identifier is a set of one or more Attributes that uniquely distinguishes each instance of a Class.

xUML uses the definition in the Executable UML Mellor/Balcer book.

An Identifier is not simply a means of locating an instance. Identity is a constraint that ensures that no two instances share certain values. To express a rule that two chess pieces may not be placed on the same square, for example, tag the attribute pair (rank, file) as an Identifier.




A Class’s Identifiers are numbered sequentially starting from one. By convention, a preferred Identifier is numbered first as I (one omitted on the class diagram). Subsequent Identifiers are I2, I3 and so on. Identifier number one is, by default, but not necessarily, the target of any References. In fact, each Identifier of a class is just as good as any other, from an analysis perspective and there is nothing special about a preferred identifier.

Type: Nominal


Class.Name — The Identifier establishes uniqueness within this Class.




  1. Number + Class + Domain
    The Number establishes uniqueness among Identifiers in the same Class.



Identifier uniquely distinguishes each instance of exactly one Class
Class has instances uniquely distinguished by one or many Identifier

Here xUML varies a bit from the Mellor/Balcer book Executable UML:

Shlaer-Mellor, ... a precursor to Executable UML, required that every class contain at least one identifier, even if that identifier was an attribute placed in the object solely for the purpose of being its identifier. This practice is not required in Executable UML. – Executable UML Mellor/Balcer

Executable UML as defined above offers the option to drop referential attributes and, presumably, express referential constraints in OCL (Object Constraint Language). xUML, on the other hand, encourages the use of referential attributes to enforce model constraints.

Consider the following example from the book Executable UML: How to Build Class Models / Starr:

In the model example above, the airport code must be included as part of the runway Identifier so that one runway may be distinguished from another across the set of all airports. Without the Reference to the airport Identifier it would be necessary to write OCL (object constraint language) to express the constraint.

The use of referential attributes and identifiers to establish model constraints has a few advantages over OCL:

  • Expression directly in the data structure — It is more difficult to violate a constraint if the data structure won’t accept incorrect data in the first place. OCL must be interpreted and translated correctly.
  • Concise expression — In many cases, a simple referential attribute placement or merge replaces a few lines of OCL.
  • Easy to interpret — If you understand a few relational model rules, the implications of referential attribute composition and placement are easy to verify. Just draw tables! The underlying model of OCL is significantly more complex (if one exists at all).
  • Consistency with the relational model — and hence many years of well established math, set, logic and data theory.
  • Simplicity of a single language — One modeling language (class diagram) can be used to express many fundamental constraints without the need of an additional constraint language.


Identifier is a Modeled or a Required Referential Identifier
An Identifier is either systematically created from one or more References based on a Relationship’s structure (Required Referential) or it is constructed and designated by the modeler to enforce whatever constraints are relevant to the application subject matter.

A Modeled Identifier may incorporate Referential Attributes while a Required Referential Identifier is built exclusively from Referential Attributes and typically whole References. A Required Referential Identifier may not be altered to suit the application subject matter. The rules for constructing Required Referential Identifiers are well established in relational theory and must always be respected to keep the Classes adequately normalized.