UML class diagram symbols

The rule that makes these memorable is that the decorated end is the end that matters: the triangle points at the more general classifier, the diamond sits on the owning whole, and the open arrow points at the thing being used. If you can remember which end carries the mark, you can usually reconstruct the meaning.

Half the marks on a class diagram are on the lines and the other half are on the boxes, and the second half is the half people skip. A rectangle with a name in it is a class; everything below changes what kind of thing that rectangle claims to be, and a reader who does not know the difference reads an interface as a class and wonders why it has no attributes.

An interface has a second, smaller notation that costs no box at all: a lollipop - a circle on a stick - drawn on the classifier that provides it, and a matching socket, an open half-circle, on the one that needs it. Push the two together and you have the ball-and-socket that component diagrams are built from. It says exactly what the dashed triangle says, in a tenth of the space, and it is the right choice the moment a diagram has more than about three interfaces on it.

A class box is a name band with up to two compartments under it: attributes, then operations. Both are optional, and a box that is only a name is perfectly legal - usually the right thing on a diagram about relationships.

Multiplicity is written at the end of a relationship, and the syntax is small: 1 exactly one, 0..1 optional, * or 0..* any number including none, 1..* at least one, and 2..5 a genuine range. A missing multiplicity means unspecified rather than one, which is why leaving it blank is a gap and not a default.

An operation is written + place(customer: Customer, at: Instant): Order - visibility, name, parameters with their types, then the return type after a colon. Two decorations turn up often enough to recognise: a parameter can carry a direction, as in out receipt: Receipt, and an attribute can carry a default, as in - status: Status = DRAFT. Neither is required, and a domain model is usually better without either.

A relationship carries meaning at both ends, and almost everything a class diagram gets wrong in review is at an end rather than in the middle. The line says two classes are connected; the ends say who can reach whom, how many, in what order, and under what name.

The last group of marks is the one that carries the rules a box-and-line drawing cannot express on its own. A class diagram is a structure, and half of what a domain expert knows is a condition on that structure - a total that can never be negative, a pair of relationships where exactly one may be filled in.

One convention outside this table is worth knowing because it looks like a class diagram and is not: an underlined name of the form order1: Order is an instance, and a diagram made of those is an object diagram - the same notation showing one moment rather than every possible moment. Underlining inside a class box means something else entirely, and that is the static marker from the compartment table above.

Text in guillemets - «interface», «enumeration», «entity» - is a stereotype: an extension of the standard vocabulary that says what kind of thing this classifier is beyond "class". A handful are defined by UML itself; the rest come from a profile, which is the mechanism for inventing your own without leaving the language.

Guillemets are doing two different jobs and the spec distinguishes them even though nothing on the page does. «interface» and «enumeration» are keywords: part of UML, fixed in meaning, and legal in any tool. «aggregate root» or «pii» are stereotypes: your own vocabulary, defined in a profile, meaningful only to a reader who has been told what they mean. Both are worth using. It is worth knowing which one you have just written, because the second kind needs a legend on the diagram and the first does not.

A stereotype can carry tagged values too - {owner = payments-team, retention = 7y} under a stereotyped class - which is how a model starts holding the metadata a spreadsheet was holding badly. That is the mechanism a profile exists to define.

To see all of this on real models, read the worked examples; for the reasoning behind the marks rather than the marks themselves, the class diagram article.