If you've ever opened a UML modeling tool and stared at a blank canvas wondering how to represent inheritance, interfaces, or multiplicity, you already know why a class diagram notation cheat sheet matters. Class diagrams are the backbone of object-oriented design, but the notation is surprisingly detailed. One missed symbol or wrong arrow type can change the meaning entirely. This cheat sheet covers the exact syntax, symbols, and examples you need to draw accurate UML class diagrams without second-guessing yourself.

What Does Class Diagram Notation Actually Mean?

Class diagram notation is the visual language defined by the Unified Modeling Language (UML) standard for describing classes, their attributes, methods, and the relationships between them. Each symbol, line style, and label format carries a specific meaning. A solid line with a filled arrowhead means something completely different from a dashed line with an open arrowhead.

When people search for a class diagram notation cheat sheet with syntax examples, they usually want one of two things: a quick visual reference they can keep open while modeling, or concrete syntax they can copy into a tool like PlantUML or Mermaid. This article covers both.

How Do You Write a Class in UML?

A UML class is drawn as a rectangle divided into three compartments. The top section holds the class name, the middle lists attributes (fields), and the bottom lists methods (operations). Here's the standard syntax used in most UML tools:

ClassName {
 - attributeName: Type
 + methodName(param: Type): ReturnType
}

The symbols before each name define visibility:

  • + means public
  • - means private
  • # means protected
  • ~ means package-private

A concrete example of a User class looks like this:

class User {
 - name: String
 - email: String
 + getName(): String
 + setEmail(email: String): void
}

For static members, you underline the name. For abstract classes, you italicize the class name. Abstract methods are also italicized.

What Do the Different Relationship Lines Mean?

This is where most people get confused. UML class diagrams use six main relationship types, each with its own line style and arrowhead. Mixing them up leads to diagrams that misrepresent your design.

Association

A solid line connecting two classes. It means one class knows about or uses the other. You can add a label on the line to describe the relationship.

Customer -----> Order

Inheritance (Generalization)

A solid line with a closed, unfilled (hollow) arrowhead pointing from the child class to the parent class. The child inherits from the parent.

Dog ----|> Animal

Interface Implementation

A dashed line with a closed, unfilled arrowhead. The implementing class points toward the interface.

Car ..|> Drivable

Aggregation

A solid line with an open diamond at the "whole" side. This represents a "has-a" relationship where the part can exist independently.

Department <>---- Employee

Composition

A solid line with a filled (solid) diamond at the "whole" side. The part cannot exist without the whole. If the whole is destroyed, so are its parts.

House ◆---- Room

Dependency

A dashed line with an open arrowhead pointing toward the class being depended on. This means a class uses another class temporarily, often as a method parameter.

OrderForm ..> EmailService

If you want to see how these relationships translate into actual script syntax, our class diagram notation cheat sheet with syntax examples has ready-to-use code for each one.

How Do You Show Multiplicity and Cardinality?

Multiplicity numbers sit at each end of a relationship line and tell you how many instances are involved. Common notation includes:

  • 1 exactly one
  • 0..1 zero or one
  • zero or many
  • 1.. one or many
  • n a specific number

For example, "A Customer places zero or many Orders, and each Order belongs to exactly one Customer" is written as:

Customer "1" ----- "0.." Order

Place the multiplicity at the end of the line closest to the class it describes.

What Does an Interface Look Like in a Class Diagram?

Interfaces follow the same rectangle format as classes but use a stereotype label above the name:

<<interface>>
Serializable {
 + serialize(): String
 + deserialize(data: String): void
}

Some modeling tools also show interfaces as a circle (lollipop notation) attached to the implementing class. Both forms are valid UML.

How Do You Represent Enumerations and Abstract Classes?

Enumerations

Enums use the <<enumeration>> stereotype and list values without types:

<<enumeration>>
Color {
 RED
 GREEN
 BLUE
}

Abstract Classes

The class name is written in italics (or marked with {abstract} in text-based tools). Abstract methods inside are also italicized:

abstract class Shape {
 + area(): double
 + perimeter(): double
}

A class like Circle would then have an inheritance arrow pointing up to Shape.

Common Mistakes When Drawing Class Diagrams

After reviewing hundreds of diagrams from students and working developers, these errors come up the most:

  • Using the wrong arrowhead for inheritance vs. dependency. A closed hollow arrowhead means generalization. An open arrowhead with a dashed line means dependency. Swapping them changes the meaning completely.
  • Forgetting multiplicity. Without cardinality markers, readers can't tell if a relationship is one-to-one, one-to-many, or many-to-many.
  • Mixing up aggregation and composition. If the child can exist independently, it's aggregation (open diamond). If not, it's composition (filled diamond).
  • Skipping visibility symbols. Leaving off +, -, and # makes it impossible to understand encapsulation boundaries.
  • Overloading one diagram. Trying to show every class in a large system on a single diagram creates clutter. Break it into focused views.

When Should You Use a Class Diagram?

Class diagrams are most useful during these stages:

  • Design phase to plan the structure before writing code
  • Code reviews to communicate architecture to teammates
  • Documentation to give new developers a map of the codebase
  • Refactoring to visualize current structure before making changes

They're less useful for showing runtime behavior or message flows. For those scenarios, you'd want to look at sequence diagram syntax or activity diagram examples instead.

What Tools Can You Use to Create Class Diagrams from Syntax?

You don't need expensive software. Several free tools let you write text-based syntax and render class diagrams automatically:

  • PlantUML widely used, supports full UML notation, renders from plain text
  • Mermaid.js works directly in Markdown files and many documentation platforms
  • Nomnoml lightweight, instant rendering, good for quick sketches
  • Lucidchart / Draw.io drag-and-drop tools with export to code and vice versa

PlantUML is the most common choice for developers who prefer writing code over dragging boxes. A basic PlantUML class diagram looks like this:

@startuml
class User {
 - name: String
 + getName(): String
}

class Order {
 - orderId: int
 + getTotal(): float
}

User "1" --> "0.." Order : places
@enduml

Quick-Reference Cheat Sheet: Symbols at a Glance

ElementNotationMeaning
Public+Accessible from anywhere
Private-Accessible only within the class
Protected#Accessible within the class and subclasses
Package~Accessible within the same package
StaticUnderlinedBelongs to the class, not an instance
AbstractItalicCannot be instantiated directly
InheritanceSolid line, hollow arrowChild extends parent
ImplementationDashed line, hollow arrowClass implements interface
AggregationSolid line, open diamondHas-a (part exists independently)
CompositionSolid line, filled diamondHas-a (part depends on whole)
DependencyDashed line, open arrowUses temporarily
AssociationSolid lineStructural connection

Your Next Step: Build a Diagram Right Now

  1. Pick one small section of a codebase you're working on even three or four classes.
  2. List each class with its attributes and methods.
  3. Identify the relationships: Who inherits from whom? Who holds a reference to whom? Can parts exist without the whole?
  4. Write the syntax in PlantUML or Mermaid using the notation rules above.
  5. Render the diagram and compare it against the actual code. Fix any mismatches.

Start with a small, focused diagram. Once you've mapped five or six classes correctly, you'll internalize the notation and won't need the cheat sheet anymore. Keep this page bookmarked for those moments when you can't remember if composition uses the filled or open diamond that one trips up everyone.