How to Create a UML Class Diagram: A Practical Guide

To create a UML class diagram, draw each class as a three-part box — name, attributes, methods — then connect the classes with the relationship that matches how they actually relate: inheritance, composition, aggregation or plain association. Mark multiplicity at each end, and the diagram states the object model precisely enough to build from.

Live interactive diagramUse the player controls to follow the steps

E-commerce domain modelPlaying silently in this guideWatch with narrationOpen in editor

When a UML class diagram is the right choice

A class diagram describes structure in code: what types exist, what they hold, what they can do, and how they refer to each other. It is worth drawing when the model is being decided or when someone new has to understand one that already exists.

Two cases where it does real work:

• Agreeing a domain model. Four people have four mental models of what an "Order" is. A class diagram forces the disagreement into the open before it becomes three incompatible implementations.
• Explaining a design pattern. Patterns are relationships between classes, which is exactly what this notation encodes. Strategy and Observer are far clearer drawn than described.

It shows no behaviour over time. For the order in which objects call each other, draw a sequence diagram; for one object's lifecycle, a state machine.

A class diagram is a snapshot of structure. Nothing in it happens, and nothing in it is ordered.

Classes, members and visibility

A class box has three compartments, top to bottom:

• Name. Singular, capitalised — Order, not Orders. An abstract class is conventionally italicised; an interface is marked as such.
• Attributes. The data, written name: Type.
• Methods. The behaviour, written name(params): ReturnType.

Each member carries a visibility marker: + public, - private, # protected, ~ package. These are worth including — the whole argument about encapsulation is invisible without them.

The relationships, and the one people get wrong

• Association — a plain line. One class knows about another. A Customer places Orders.
• Aggregation — a hollow diamond at the container end. A "has-a" where the parts outlive the whole. A Library aggregates Books; delete the library and the books still exist.
• Composition — a filled diamond. A "has-a" where the parts die with the whole. An Order is composed of OrderItems; delete the order and they are meaningless.
• Inheritance — a hollow triangle pointing at the parent. SavingsAccount is an Account.
• Realization — a dashed line with a hollow triangle. A class implements an interface.
• Dependency — a dashed arrow. One class uses another transiently, typically as a parameter.

Aggregation versus composition is the distinction most often misused. The test is lifetime: if destroying the whole destroys the parts, it is composition. A car and its engine is composition; a library and its books is aggregation. Getting it wrong is not a notation quibble — it usually means the cascade-delete behaviour has not been decided.

Multiplicity goes at each end: 1, 0..1, *, 1..*. Read both ends, as you would in an ER diagram.

How to create a UML class diagram, step by step

1. List the nouns that have behaviour. A class usually does something. A thing that only holds data may be a value object or just a field.
2. Give each class its attributes. Types where the type is part of the argument; skip the obvious ones.
3. Add only the methods that matter to the reader. Every getter on the diagram is a line that hides the interesting method.
4. Draw associations where one class holds a reference to another. Plain lines first.
5. Upgrade to aggregation or composition where ownership is real, applying the lifetime test.
6. Add inheritance only for genuine "is-a". If a subclass overrides everything and shares no behaviour, the relationship is probably composition.
7. Mark multiplicity at both ends. This is where "can an order exist with no items?" gets answered.
8. Add visibility markers. Last, and quickly — but do add them.

Worked examples you can open and edit

A domain model

The e-commerce model is the one to read first because it contains all four relationship kinds at a size you can hold in your head. Note that Order is composed of OrderItems — filled diamond — while it merely associates with Customer. That is the correct reading: deleting an order should delete its line items and must not delete the customer. The diamond is doing real work there, and a diagram that used a plain line for both would have lost the only interesting decision on the page.

A design pattern

The Strategy example shows why patterns are easier drawn than explained: Checkout depends on a PaymentMethod interface, and CreditCard and PayPal realize it. The whole point of the pattern — that Checkout knows the interface and never the implementations — is a single dashed-triangle relationship. In prose that takes a paragraph and still leaves people unsure which way the dependency points.

Building one in Diagramium

Open the UML class diagram editor.

1. Drop a class and fill its name, attributes and methods in the inspector.
2. Drag from a port to another class to relate them.
3. Pick the relationship type on the selected connector — inheritance, composition, aggregation, realization or dependency each have their own marker.
4. Set multiplicity at each end.
5. Press Present to introduce the model one class at a time — the way to walk a team through a design review.

The UML class editor is canvas-based; there is no text syntax and the Text editor tab is hidden in this mode. Text input is available for sequence diagrams, org charts, mind maps and sitemaps.

Presenting and exporting

• Present reveals the model class by class, so a review can challenge each relationship as it appears rather than absorbing twelve boxes at once.
• Export PNG, SVG or PDF free without an account; SVG keeps the compartment text sharp when a wide model is zoomed. Animated SVG, GIF and video need a free account, not a subscription.
• Embed a published diagram in developer documentation.

Common mistakes

• Composition where aggregation is meant. Apply the lifetime test; the answer decides your delete behaviour.
• Every field and every getter. A class diagram is an argument about structure, not a header file. Show what is in dispute.
• Inheritance used for reuse. "It shares some code" is composition. Inheritance is for "is-a", and misusing it here is how fragile hierarchies start.
• No multiplicity. Without it, nobody can tell whether a collection or a single reference is intended.
• Missing visibility markers. The encapsulation conversation is invisible without them.
• Modelling the database. If your classes are tables with no behaviour, you want an ER diagram.

Related diagram types

• The same nouns as stored data, with keys and cardinality: ER diagram.
• Those objects calling each other in order: sequence diagram.
• One class's lifecycle: state machine diagram.
• Actors and system scope rather than internals: UML use case diagram.
• The services these classes are deployed inside: architecture diagram.

Questions people actually ask

What is the difference between a UML class diagram and an ER diagram?

A class diagram models objects — data and behaviour, with inheritance. An ER diagram models stored data: tables, keys and cardinality, with no methods and no inheritance. If the output is code, draw classes; if it is a schema, draw entities.

What is the difference between aggregation and composition?

Lifetime. Composition (filled diamond) means the parts are destroyed with the whole; aggregation (hollow diamond) means they outlive it. Order and OrderItem is composition; Library and Book is aggregation.

Do I have to show every attribute and method?

No, and you should not. Show the members relevant to the point the diagram is making. Exhaustive boxes bury the relationships, which are what the reader came for.

What do +, - and # mean?

Visibility: + public, - private, # protected, ~ package.

How do I show an interface?

Mark the class as an interface and connect implementers with a realization — a dashed line ending in a hollow triangle — rather than the solid triangle used for inheritance.