Uml Class Diagram Notation Symbols and Their Meanings Explained

If you've ever opened a UML class diagram and felt lost staring at boxes, arrows, and strange little symbols, you're not alone. Class diagrams are one of the most widely used diagram types in software design, but the notation can feel like learning a new language. Understanding UML class diagram notation symbols and their meaning is what separates a diagram you can actually use from one that just looks pretty on a whiteboard. This guide breaks down every symbol you'll encounter so you can read, create, and communicate software designs with confidence.

What is a UML class diagram, and why does notation matter?

A UML class diagram is a structural diagram that shows the classes in a system, their attributes, methods, and how they relate to each other. It's part of the Unified Modeling Language (UML) standard, which was created to give software teams a shared visual language.

Notation matters because a misplaced arrow or a wrong symbol changes the meaning entirely. A solid line with a closed arrowhead means inheritance, while a dashed arrow means dependency mixing those up could send a developer down the wrong path. When you know the symbols, you can read any class diagram, spot design patterns, and communicate architecture decisions clearly.

How is a single class represented in a class diagram?

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

Top compartment the class name, written in bold and centered. Abstract classes are shown in italic. The class name starts with an uppercase letter by convention.
Middle compartment the attributes (also called fields or properties). Each attribute is listed on its own line.
Bottom compartment the operations (also called methods or functions). Each operation is listed on its own line.

A typical attribute looks like this:

- name: String

A typical operation looks like this:

+ getAge(): int

The format follows the pattern: visibility name: Type for attributes and visibility name(parameters): ReturnType for operations. If a class has no attributes or operations yet, you can still draw the rectangle with just the class name.

What do the visibility symbols mean?

Every attribute and operation in a class diagram has a visibility symbol that shows who can access it. These are the four standard UML visibility markers:

+ (plus) public. Accessible from anywhere.
- (minus) private. Accessible only within the class itself.
# (hash) protected. Accessible within the class and its subclasses.
~ (tilde) package. Accessible within the same package or namespace.

For example, - balance: double means the attribute balance is private and of type double. If you leave off the visibility symbol, it means the visibility is not specified which is different from saying it's public.

What do the relationship lines and arrows mean?

This is where most confusion happens. Class diagrams use different line styles and arrowheads to show how classes interact. Here's what each one means:

Association

A solid line between two classes. It means one class knows about or uses the other. You can add an arrowhead to show the direction of the relationship. A simple association often looks like a plain line with no arrows (bidirectional) or with an open arrowhead pointing to the referenced class.

Inheritance (Generalization)

A solid line with a closed, hollow triangle arrowhead pointing from the child class to the parent class. This is the "is-a" relationship. For example, Dog inherits from Animal the triangle points toward Animal.

Implementation (Realization)

A dashed line with a closed, hollow triangle arrowhead pointing from the implementing class to the interface. This is used when a class implements an interface rather than extending a concrete class.

Dependency

A dashed line with an open arrowhead. This means one class temporarily uses another for example, a method accepts an object of another class as a parameter. The dependency is weaker than association.

Aggregation

A solid line with an open (hollow) diamond at the "whole" end. This is a "has-a" relationship where the part can exist independently of the whole. Think of a Department and Teacher a teacher can exist without the department.

Composition

A solid line with a filled (solid) diamond at the "whole" end. This is a stronger "has-a" relationship where the part cannot exist without the whole. Think of a House and Room if you destroy the house, the rooms go with it.

Reading class diagram arrows correctly is essential. If you're also working with other diagram types, our guide on interpreting UML sequence diagram arrows and lifelines covers interaction diagram notation in a similar way.

What do the multiplicity numbers mean?

Multiplicity tells you how many instances of one class can be linked to an instance of another class. You'll see these numbers at either end of a relationship line:

1 exactly one
0..1 zero or one (optional)
zero or more (any number)
1.. one or more (at least one)
2..5 a specific range

For example, if a Library has a relationship to Book with multiplicity on the Book end, it means a library can have many books. If the Library end shows 1, each book belongs to exactly one library.

What do the other class diagram symbols mean?

Abstract class

The class name is written in italics. Sometimes you'll also see the text {abstract} below the name.

Interface

Shown as a class stereotyped with «interface» above the name. It can be drawn as a rectangle or as a circle (lollipop notation), though the rectangle form is more common.

Static (underlined members)

Attributes or operations that belong to the class itself rather than an instance are underlined.

Read-only attributes

An attribute marked with {readOnly} after the type means its value cannot change after the object is created.

Derived attributes

Shown with a / slash before the name, like / age: int. This means the value is calculated from other attributes rather than stored directly.

Constraints

Shown inside curly braces { } near the relevant element. For example, {ordered} on an association end means the collection of linked objects is ordered.

Notes

A rectangle with a folded corner (like a sticky note). Connected to a class or element with a dashed line. Notes add extra explanations that don't fit the formal notation.

What are common mistakes people make with class diagram notation?

Confusing aggregation with composition. The hollow diamond (aggregation) and solid diamond (composition) look similar but mean very different things. If the child can exist independently, it's aggregation.
Pointing inheritance arrows the wrong way. The triangle always points toward the parent or interface, not the child. This is counterintuitive for some people who think of "flowing down" the hierarchy.
Using dependency arrows when association is meant. If a class holds a reference to another class as an attribute, that's an association (solid line), not a dependency (dashed line).
Forgetting multiplicity. Without multiplicity, a relationship is ambiguous. Always clarify whether the relationship is one-to-one, one-to-many, or many-to-many.
Mixing up visibility symbols. Using + when you mean # (protected) accidentally exposes internal details. Double-check your symbols before sharing diagrams.
Overcomplicating the diagram. Including every single class and relationship in one diagram makes it unreadable. Focus on the part of the system you need to explain.

How do these symbols look in a real example?

Imagine you're designing a simple online store. Here's how the notation works in practice:

Customer class: has attributes like - name: String, - email: String, and operations like + placeOrder(cart: Cart): Order.
Order class: connected to Customer with a solid line. Multiplicity shows 1 on the Customer end and on the Order end one customer, many orders.
Order and OrderItem: connected with a composition symbol (filled diamond on the Order side). If you delete the order, its line items are deleted too.
Product and OrderItem: connected with a regular association. A product exists independently of any order.
PremiumCustomer inherits from Customer: shown with a solid line and a hollow triangle pointing toward Customer.

This is a simplified model, but it shows how every symbol carries specific meaning. A developer reading this diagram knows exactly how the objects relate to each other without needing to read a separate document.

For teams working with microservices, class diagrams often appear alongside component diagrams to show service-level structure. Our article on UML component diagram notation for microservices covers how those service boundaries are represented.

What practical tips help when working with class diagram notation?

Start with the domain model, not the code model. Focus on real-world concepts first. Add implementation details (types, visibility) later.
Keep one diagram focused on one area. You don't need to show your entire system in a single class diagram. Multiple focused diagrams are easier to understand.
Use consistent naming. Pick a convention PascalCase for classes, camelCase for attributes and operations and stick with it.
Label relationships when needed. Adding a small verb phrase on an association line (like "places" between Customer and Order) removes ambiguity.
Use tooling that enforces notation. Tools like PlantUML, Lucidchart, or Enterprise Architect will flag invalid symbol combinations. Drawing by hand is fine for brainstorming, but formal diagrams benefit from tool support.
Review your diagram with someone who didn't design it. If they can understand the relationships and constraints without you explaining, your notation is working.

Where can you learn more about UML diagram notation?

Class diagrams are just one part of UML. If you're building sequence diagrams to show how objects interact over time, check out our walkthrough on reading UML sequence diagram arrows and lifelines. And if you're mapping out a full system architecture at the component level, our guide to component diagram notation for microservices is a natural next step.

The more UML diagram types you're comfortable with, the more precisely you can communicate design decisions to your team whether you're sketching on a whiteboard or building formal documentation.

Quick-reference checklist: class diagram symbols

Class rectangle with three compartments (name, attributes, operations)
Visibility: + public, - private, # protected, ~ package
Inheritance: solid line + hollow triangle → parent
Implementation: dashed line + hollow triangle → interface
Dependency: dashed line + open arrowhead
Association: solid line (optional arrowhead)
Aggregation: solid line + hollow diamond
Composition: solid line + filled diamond
Multiplicity values at relationship ends
Abstract class name in italics
Interface shown with «interface» stereotype
Static members underlined
Derived attributes prefixed with /

Next step: Pick a small piece of your current project maybe three to five classes and draw a class diagram using the correct notation. Compare it against this checklist. If every symbol matches, you're diagramming with precision.