UML Class Diagram Cheat Sheet

UML class diagrams are a compact way to describe the static structure of a system: the main entities, the attributes they hold, the operations they expose, and the relationships that tie them together. Their value is not in perfect notation for its own sake. It is in making ownership, coupling, and boundaries visible before the code hardens those choices.

What a class diagram is actually good at

A class diagram works best when you need to explain a domain model or reason about object relationships that will persist in code. It helps answer practical questions such as which object owns a lifecycle, which component depends on which interface, and where behaviour should live.

It is less useful for request flows, deployment topology, or concurrent behaviour. Teams get into trouble when they use a class diagram to explain everything. UML is a toolbox, not a universal format.

Core building blocks

A class is usually drawn as a rectangle with compartments for the class name, attributes, and methods. The notation is straightforward, but the design meaning matters more than the symbols:

• Attributes describe what state the object owns.
• Operations describe what behaviour the object is responsible for.
• Visibility markers such as +, -, and # show what is public, private, or protected.
• Abstract classes and interfaces highlight extension points.

Even if a team does not document every field or method, naming the important ones reveals whether a type is doing too much. A diagram with one class that knows everything is often exposing a design problem before implementation begins.

Relationship types and why they matter

Most of the information in a class diagram lives in the lines between classes.

• Association means one class knows about another.
• Aggregation suggests a whole-part relationship where parts may exist independently.
• Composition means the parent owns the part's lifecycle.
• Inheritance models an "is-a" relationship.
• Realisation shows a class implementing an interface.

Multiplicity, such as 1, 0..1, or 1..*, adds an operational constraint. A User with many Session objects implies a different storage and invalidation strategy from a User with exactly one Profile. That is why multiplicity is not just diagram decoration. It expresses rules that shape persistence, validation, and API behaviour.

Use diagrams to expose tradeoffs early

A good class diagram raises design questions. Should Order call PaymentGateway directly, or should a service mediate that dependency? Does Invoice own line items, or merely reference them? Is inheritance making behaviour reusable, or is it creating a hierarchy that will be painful to change?

These are useful discussions because they happen before dozens of call sites and migrations make the answer expensive to reverse. The diagram becomes a conversation aid, not a contract frozen forever.

Practical guidance

Keep the diagram focused on the part of the system under discussion. Avoid representing every utility type, framework class, or generated model. Prefer interfaces where you need replaceable behaviour. Be careful with inheritance, because composition is often easier to maintain. Show multiplicity when it affects business rules or storage design.

The best class diagrams are selective and opinionated. They tell a reader how the model is structured and where the sharp edges are, without pretending the picture can replace the code.