If you work with software design, you've probably sketched a class diagram on a whiteboard or napkin at some point. UML class diagrams show how classes, attributes, methods, and relationships fit together in a system. But drawing them by hand gets messy fast, especially when you need to share or version-control your designs. That's where diagram codes come in. A solid cheat sheet for UML class diagram code syntax lets you write diagrams as plain text and render them automatically faster, cleaner, and easier to maintain.

This cheat sheet covers the key syntax patterns you'll need when writing UML class diagrams in text-based diagramming tools. Whether you use PlantUML, Mermaid, or another tool, the core concepts overlap. Having the right code snippets on hand saves you from constantly looking things up and keeps your design docs moving forward.

What does "diagram codes for UML class diagrams" actually mean?

Diagram codes are plain-text descriptions that a rendering tool converts into visual diagrams. For UML class diagrams specifically, you write code that defines classes, their attributes and methods, and the relationships between them (like inheritance, composition, and association). The tool then draws the boxes, arrows, and labels for you.

Think of it like HTML for diagrams. You describe the structure in code, and the tool handles the visual output. The most popular syntaxes for this are PlantUML and Mermaid, each with slightly different formatting rules. If you're deciding between tools, our comparison of Mermaid, PlantUML, and Graphviz breaks down the differences.

Why would someone need a cheat sheet instead of a full reference?

Full documentation is great when you're learning a tool from scratch. But when you're in the middle of designing a system and need to quickly write a class with three attributes, an inheritance relationship, and a composition link, you don't want to scroll through 20 pages of docs. A cheat sheet gives you the most-used syntax patterns in one place copy, paste, modify, done.

It's also helpful when you're switching between tools. If you know Mermaid well but your team uses PlantUML, a cheat sheet bridges the gap without requiring a full re-learning process.

How do you define a class with attributes and methods?

In PlantUML, a basic class looks like this:

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

The + sign means public, - means private, # means protected, and ~ means package-private. Attributes go above the separator line; methods go below it.

In Mermaid, the syntax is slightly different:

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

Mermaid puts the type before the name for attributes, and return types after the method name. Small differences, but they trip people up when switching tools.

How do you show inheritance between classes?

Inheritance (generalization) uses an arrow pointing from the child class to the parent class with a hollow triangle head.

In PlantUML:

Animal <|-- Dog
Animal <|-- Cat

In Mermaid:

Animal <|-- Dog
Animal <|-- Cat

Both tools use the same arrow syntax here, which is one of the easier parts. The triangle points toward the parent (the more general class).

What about associations, compositions, and aggregations?

These relationship types are where most people need a quick reference. Here's the cheat sheet:

  • Association (plain line): A -- B or with a label: A "1" -- "" B : has
  • Composition (filled diamond): A -- B B cannot exist without A
  • Aggregation (hollow diamond): A o-- B B can exist independently of A
  • Dependency (dashed arrow): A ..> B A uses B but doesn't own it
  • Realization/Implementation (dashed with hollow triangle): Interface <|.. Class

Cardinality labels go in quotes on either side of the relationship line. For example, "1" -- "" means one-to-many.

Can you add notes and abstract classes?

Yes. In PlantUML, you mark abstract classes with the abstract keyword or abstract class notation:

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

For notes, PlantUML uses:

note left of User : This class handles
user authentication

Mermaid supports notes differently and has more limited annotation support. If annotations matter to your diagrams, PlantUML is generally more flexible. You can explore more syntax patterns in our syntax reference for sequence diagrams, which covers shared formatting rules that apply across diagram types.

What are the most common mistakes when writing UML diagram code?

  1. Mixing up arrow directions. The arrow in A <|-- B means B inherits from A (B is the child). People often reverse this. Remember: the arrow points from child to parent.
  2. Forgetting quotes on labels. Relationship labels and cardinality numbers need quotes: A "1" -- "" B : contains. Without quotes, the renderer may break or ignore the label.
  3. Using wrong symbols for visibility. + is public, - is private. Swapping these silently changes your design intent.
  4. Not closing blocks. Forgetting the closing brace } after a class definition causes parsing errors that can be hard to spot in long diagrams.
  5. Overloading one diagram. Trying to show an entire system in a single class diagram makes it unreadable. Break large systems into multiple focused diagrams.

How do you format multiplicity and role names correctly?

Multiplicity tells readers how many instances participate in a relationship. The common notations are:

  • 1 exactly one
  • 0..1 zero or one
  • zero or many
  • 1.. one or many

In code, place these in quotes on either side of the relationship:

Order "1" -- "" OrderLineItem : contains

Role names label the end of an association to describe what role that class plays. You can add them as labels on the relationship line itself.

When should you use text-based UML diagrams instead of a visual editor?

Text-based diagram codes work best when you want diagrams stored alongside your code in version control, when you need to generate diagrams as part of a documentation pipeline, or when you want to quickly prototype an architecture without switching tools. They're also useful for code reviews reviewers can comment on the diagram source just like they'd comment on code.

Visual editors like draw.io or Lucidchart still have their place for presentations and collaborative sessions. But for developer workflows, code-based diagrams integrate better with the tools you already use. If you also work with flowcharts in code, our guide to creating diagram codes for flowcharts covers similar patterns for that diagram type.

What does a complete, practical UML class diagram look like in code?

Here's a realistic PlantUML example for a simple e-commerce domain:

@startuml

abstract class Product {
  -id: String
  -name: String
  -price: Decimal
  {abstract} +getDisplayPrice(): String
}

class PhysicalProduct {
  -weight: Double
  -dimensions: String
  +getDisplayPrice(): String
  +calculateShipping(): Decimal
}

class DigitalProduct {
  -downloadUrl: String
  -fileSizeMb: Int
  +getDisplayPrice(): String
  +generateDownloadLink(): String
}

class Order {
  -orderId: String
  -createdAt: DateTime
  -status: OrderStatus
  +addItem(product: Product, qty: Int): void
  +calculateTotal(): Decimal
}

class OrderLineItem {
  -quantity: Int
  -unitPrice: Decimal
  +getSubtotal(): Decimal
}

class Customer {
  -name: String
  -email: String
  +placeOrder(): Order
}

Product <|-- PhysicalProduct
Product <|-- DigitalProduct
Customer "1" -- "" Order : places
Order "1" -- "" OrderLineItem : contains
Product "1" -- "" OrderLineItem : references

@enduml

This example uses inheritance, composition, association with multiplicity, abstract classes, and multiple visibility modifiers all the patterns you'd typically need.

Quick-reference cheat sheet summary

  • Class definition: class ClassName { attributes / methods }
  • Abstract class: abstract class Name { {abstract} +method(): Type }
  • Interface: interface Name { +method(): Type }
  • Inheritance: Parent <|-- Child
  • Interface implementation: Interface <|.. Class
  • Association: A -- B
  • Composition: A -- B
  • Aggregation: A o-- B
  • Dependency: A ..> B
  • Labeled relationship: A "1" -- "" B : label
  • Visibility: + public, - private, # protected, ~ package
  • Note: note left of ClassName : text
  • Stereotype: class Name <<stereotype>>

For a deeper look at how different tools handle these same concepts, the official PlantUML class diagram documentation covers the full syntax with additional examples.

Practical next step: build your own cheat sheet

Take the syntax patterns above and create a file in your project repo something like UML-CLASS-CHEATSHEET.puml with your own domain-specific examples. Every time you write a new class diagram, pull from that file. Over a few weeks, you'll have a personalized reference that matches your team's conventions and the specific tool you use. Pair it with diagram rendering in your CI pipeline so every pull request includes an up-to-date visual of your system's class structure.