UML class diagrams

A class is a rectangle with up to three compartments, stacked. Only the first is required.

• Name. The type name, centred and bold. If the class is abstract, the name is italic. A keyword in guillemets above it - «interface», «enumeration» - narrows what kind of classifier it is.
• Attributes. One per line, written visibility name: Type [multiplicity] = default. Everything but the name is optional.
• Operations. One per line, written visibility name(parameters): ReturnType.

The leading symbol on each member is its visibility:+ public, - private, # protected, and ~ package. A underlined member is static - it belongs to the class rather than to an instance.

Almost all of the meaning in a class diagram is in the lines, and there are only six worth memorising. The end that carries the decoration is significant in every case.

The number at the end of a line says how many instances participate. It sits at the far end from the class it constrains, which trips people up: reading Merchant 1 —— 0..* Payment, the 0..* next to Payment means one merchant has zero or more payments.

• 1 - exactly one. The default when nothing is written, though writing it is clearer.
• 0..1 - optional. This is the notation for a nullable reference.
• * or 0..* - any number, including none.
• 1..* - at least one. A meaningful and frequently-forgotten constraint.
• 2..4 - an explicit range.

Multiplicity is the cheapest correctness win in the whole notation. "Can this be empty?" and "can there be more than one?" are the two questions that surface real disagreements in a design review, and the answer takes three characters to record.

These three are the same shape of relationship at three strengths, and the difference is about lifecycle, not about how strongly the two things feel related.

A plain association claims nothing about ownership. Two things are linked. That is all, and it is the right default.

Aggregation - the hollow diamond - claims a whole-part relationship where the part is independent. Honest advice: aggregation carries almost no formal semantics in UML 2.5.1, and readers disagree about what it implies. If you are unsure between association and aggregation, draw the association.

Composition - the filled diamond - is the one that says something strong and checkable. The part belongs to exactly one whole and is destroyed with it. In the payments model, a Refund exists only as part of a Payment; there is no free-floating refund. That is a real constraint, worth recording, and it maps directly to a cascade delete or an owned collection in code.

The most useful class diagrams in practice are small. Seven to twelve classes, attributes on the ones being discussed and omitted everywhere else, and every line carrying a multiplicity. A diagram like that gets read in a meeting and settles arguments. A hundred-box class diagram is an artefact, not a communication.

1. Arrows pointing the wrong way. Generalization and realization point at the abstraction. If your triangle is on the subclass, the diagram says the opposite of what you meant.
2. Composition used for "strongly related". The filled diamond is a lifecycle claim. Use it only when destroying the whole really does destroy the part.
3. No multiplicities. A line with nothing at either end has thrown away the most valuable information the diagram could carry.
4. Mixing altitudes. Domain classes and framework classes on one canvas. Split it; each diagram should be readable by one audience.
5. Modelling every getter. Operations belong on the diagram when they carry meaning. getName() does not.

If you want to check a class model against reality, draw one object diagram - a single concrete snapshot of instances. Multiplicities that looked fine in the abstract tend to fall over immediately when you try to fill them in with real values.