You're staring at a whiteboard full of boxes and arrows, trying to diagram a software system. You know the class name goes at the top, but what about the relationship between User and Order? Is that a composition or aggregation? And what does a dashed arrow mean again?

A UML class diagram notation cheat sheet solves this exact problem. It gives you a quick-reference guide to every symbol, line style, and modifier you need so you can focus on designing your system instead of second-guessing your notation. Whether you're preparing for a code review, documenting an existing project, or learning software design patterns, having these conventions at your fingertips saves real time.

What Does UML Class Diagram Notation Actually Cover?

UML class diagrams describe the static structure of a system. The notation covers three things: classes (what exists), attributes and operations (what each class knows and does), and relationships (how classes connect). The standard UML diagram notation symbols are defined by the Object Management Group (OMG), which maintains the UML specification.

A class is drawn as a rectangle divided into three compartments:

  • Top compartment class name (bold, centered)
  • Middle compartment attributes (fields/properties)
  • Bottom compartment operations (methods/functions)

If a class is abstract, the class name is written in italics. An interface is often shown with the stereotype <<interface>> above the name.

How Do You Read the Relationship Lines?

This is where most people get tripped up. UML uses different arrow styles and line types to represent six main relationships between classes:

Association

A solid line connecting two classes. It means one class "knows about" or uses the other. You can add an arrowhead to show direction, and a label on the line describes the nature of the relationship (e.g., "places," "owns").

Inheritance (Generalization)

A solid line with a hollow triangle arrowhead pointing from the child class to the parent class. This means the child extends the parent the "is-a" relationship.

Realization (Interface Implementation)

A dashed line with a hollow triangle arrowhead pointing from the implementing class to the interface. This means the class promises to fulfill the interface's contract.

Aggregation

A solid line with a hollow diamond on the side of the "whole" class. This represents a "has-a" relationship where the part can exist independently. Think: a Department has Employee objects, but employees can exist without the department.

Composition

A solid line with a filled (solid) diamond on the side of the "whole" class. This is a stronger form of aggregation the part cannot exist without the whole. Example: a House is composed of Room objects. If the house is destroyed, the rooms go with it.

Dependency

A dashed arrow pointing from the dependent class to the class it depends on. This means a change in one class may affect the other often seen when a method takes a parameter of another class type.

For a deeper comparison of how these symbols differ from other modeling approaches, see how UML diagram codes compare to entity-relationship notation.

What Do Those Symbols Before Attribute and Method Names Mean?

UML uses visibility markers to indicate access levels. These go directly before the attribute or method name:

  • + Public (accessible from anywhere)
  • - Private (accessible only within the class)
  • # Protected (accessible within the class and its subclasses)
  • ~ Package (accessible within the same package)

Attributes are written in the format: visibility name: Type [multiplicity] = defaultValue

For example: - email: String [1] = "" means a private attribute called email, of type String, that must have exactly one value and defaults to an empty string.

Operations follow: visibility name(parameter: Type): ReturnType

Example: + calculateTotal(items: List<Item>): Double

What Are Multiplicity and Cardinality?

Multiplicity tells you how many instances of one class can be associated with an instance of another. You'll see these numbers (or symbols) near the ends of relationship lines:

  • 1 Exactly one
  • 0..1 Zero or one
  • or 0.. Zero or many
  • 1.. One or many
  • n Exactly n (e.g., 2..5 for a range)

Practical example: An Order can have 1.. OrderLine items, and each OrderLine belongs to exactly 1 Order. That gives you the multiplicity markers at each end of the association line.

What Are the Most Common Mistakes?

After reviewing hundreds of class diagrams in code reviews and technical docs, here are the errors that come up most:

  • Confusing aggregation and composition. If the part can exist independently, it's aggregation. If it can't, it's composition. When in doubt, ask: "If I delete the parent, does the child survive?"
  • Using inheritance when they mean association. Just because two classes are related doesn't mean one extends the other. A Customer doesn't extend Order they have an association.
  • Leaving out multiplicity. Without cardinality markers, readers can't tell if a relationship is one-to-one, one-to-many, or many-to-many. Always mark both ends.
  • Overloading a single diagram. Trying to show every class in a large system on one diagram makes it unreadable. Break it into multiple focused diagrams.
  • Forgetting return types and parameter types. Operations without type information lose most of their value as documentation.

When Should You Use This Cheat Sheet in Practice?

Keep a UML class diagram notation reference handy during these situations:

  1. System design interviews. You'll often sketch class diagrams on a whiteboard. Knowing the notation cold lets you focus on the design, not the syntax.
  2. Writing technical design documents. Before building a feature, diagram the new classes and their relationships so your team can review the approach.
  3. Documenting existing code. Reverse-engineering a codebase into class diagrams helps new team members understand the architecture.
  4. Learning design patterns. Most books and courses on patterns (like Gang of Four) use UML class diagrams to explain structure. You need to read the notation to follow along.

If you also work with behavioral diagrams, the notation differs significantly our sequence diagram notation guide covers those conventions separately.

Quick Reference: Common UML Class Diagram Stereotypes

Stereotypes are keywords in guillemets (double angle brackets) that extend the meaning of a UML element:

  • <<interface>> Marks a class as an interface
  • <<abstract>> Explicitly marks a class as abstract (though italics on the name also indicate this)
  • <<enumeration>> Marks an enum type
  • <<utility>> A class with only static members
  • <<entity>> A persistent data class (common in layered architecture)
  • <<service>> A class that performs operations but doesn't hold state

What Tools Can You Use to Draw Class Diagrams?

You don't need expensive software. Here are practical options:

  • PlantUML Write diagrams as plain text. Great for version-controlled documentation. The PlantUML class diagram reference covers the text-based syntax.
  • draw.io (diagrams.net) Free, browser-based diagramming with built-in UML shapes.
  • Lucidchart Browser-based with templates and team collaboration features.
  • Mermaid.js Text-based diagramming that renders in Markdown files, GitHub, and many documentation tools.
  • IDE plugins IntelliJ, Eclipse, and Visual Studio Code all have extensions that generate class diagrams from your source code.

Your UML Class Diagram Notation Checklist

  • ☐ Class name is in bold at the top of the rectangle
  • ☐ Abstract class names are in italics
  • ☐ Each attribute has a visibility marker (+, -, #, ~)
  • ☐ Attributes and operations include their types
  • ☐ Relationship lines use the correct style (solid vs. dashed) and arrowheads
  • ☐ Inheritance uses a hollow triangle pointing to the parent
  • ☐ Composition uses a filled diamond; aggregation uses a hollow diamond
  • ☐ Multiplicity is marked at both ends of every association
  • ☐ The diagram has a clear purpose showing only the classes relevant to the topic

Print this checklist and keep it next to your workspace. The more you use it, the more the notation becomes second nature and your designs will communicate clearly to every developer who reads them.