If you've ever opened a PlantUML file and forgotten the exact syntax for inheritance arrows, interface implementation, or abstract classes, you're not alone. Class diagrams are one of the most commonly drawn UML diagrams, and PlantUML lets you create them with plain text but only if you remember the syntax. That's exactly why a reliable PlantUML class diagram syntax reference cheatsheet saves you time and frustration. Instead of digging through documentation every five minutes, you can glance at a single page and keep working.

This reference covers the core PlantUML class diagram syntax you'll use on real projects from basic class declarations to advanced relationship notation. Whether you're documenting a legacy codebase or sketching out a new architecture, these patterns will keep your diagrams clean and correct.

How Do You Declare a Basic Class in PlantUML?

The simplest class diagram starts with the class keyword followed by the class name. Curly braces define the body where you list fields and methods.

Basic class syntax:

  • class ClassName {
  •   + publicField : String
  •   - privateField : int
  •   + publicMethod() : void
  • }

Visibility prefixes matter here: + means public, - means private, # means protected, and ~ means package-private. These map directly to how most object-oriented languages handle access modifiers.

What's the Difference Between Abstract Classes and Interfaces?

You can mark a class as abstract using the abstract keyword or by using the abstract modifier before the class name. Abstract methods use italic formatting automatically.

  • abstract class AbstractShape {
  •   + {abstract} calculateArea() : double
  • }

For interfaces, use the interface keyword instead of class. PlantUML renders interfaces with a stereotype «interface» above the name by default.

  • interface Drawable {
  •   + draw() : void
  • }

You can also use the annotation and enum keywords to represent annotations and enumerations, which helps when documenting Java or C# codebases accurately.

How Do You Show Class Relationships and Inheritance?

This is where most people look up syntax the most. PlantUML uses arrow notation to represent UML relationships between classes.

  • Inheritance (extends): ChildClass --|> ParentClass
  • Interface implementation: MyClass ..|> MyInterface
  • Composition: Whole -- Part (filled diamond)
  • Aggregation: Whole o-- Part (open diamond)
  • Association: ClassA --> ClassB
  • Dependency: ClassA ..> ClassB (dashed line)
  • Realization: ClassA ..|> ClassB (dashed with closed arrow)

The direction of the arrow arrow arrow arrow arrow arrow arrow arrow arrow matters. The side with the arrowhead points to the parent or the "whole" in most cases. You can reverse direction by placing the arrow on the other side: ParentClass <|-- ChildClass.

If you've worked on structured workflows before, you might already be familiar with how PlantUML handles sequence-based logic in activity diagrams for agile sprint workflows the arrow conventions in class diagrams follow a similar logic of showing direction and flow.

How Do You Add Multiplicity and Labels to Relationships?

UML class diagrams often need cardinality notation, like "1.." or "0..1" on relationship lines. PlantUML supports this with quotes placed near the association ends.

  • "1" -- "many" Part : contains >
  • "1" --> "" OrderLine : has >

You can also add labels to any relationship arrow using the colon syntax. The label text appears in the middle of the line, which helps explain the nature of the relationship in plain language.

What About Packages, Notes, and Stereotypes?

When your diagram grows, grouping classes into packages keeps things organized:

  • package "com.example.model" {
  •   class User
  •   class Order
  • }

Notes give you a way to add context directly on the diagram:

  • note right of User : This class represents a registered user
  • note left of Order : Includes billing and shipping info

Stereotypes add custom labels above class names using double angle brackets:

  • class User <<entity>>
  • class UserRepository <<repository>>

This is especially useful when documenting layered architecture patterns where classes play distinct roles like controllers, services, or data access objects.

Can You Customize the Appearance of Class Diagrams?

PlantUML gives you several skinparams and styling options to control how diagrams look:

  • skinparam classAttributeIconSize 0 hides the field/method type icons
  • hide circle removes the dot markers on interfaces
  • skinparam classFontStyle bold makes all class names bold
  • skinparam shadowing false removes box shadows for cleaner export

You can also apply colors to individual classes:

  • class User #LightBlue
  • class Order #LightGreen|Green/Red

The second format lets you define both the background and border colors separately.

What Are Common Mistakes in PlantUML Class Diagrams?

After working with PlantUML class diagrams across many projects, these errors come up repeatedly:

  • Wrong arrow direction. People often mix up --|> and |-- inheritance arrows, which reverses the parent-child relationship in the rendered diagram.
  • Missing colons for relationship labels. Without the colon separator, PlantUML treats label text as a new class name.
  • Forgetting stereotypes on interfaces. If you use class instead of interface, the diagram won't show proper UML interface notation.
  • Overcrowded diagrams. Putting 30+ classes in a single diagram makes it unreadable. Use packages to split things up or create focused views.
  • Inconsistent visibility notation. Mixing UML visibility symbols with words like "public" and "private" creates confusion in the rendered output.

How Does PlantUML Compare to Other Diagram Tools?

PlantUML's biggest advantage over tools like draw.io, Lucidchart, or Visio is version control friendliness. Since class diagrams are plain text files, they work naturally with Git. You can diff changes, review diagram updates in pull requests, and merge contributions from multiple developers without file conflicts.

The tradeoff is a steeper initial learning curve for the syntax. Once you internalize the arrow conventions and keyword patterns, though, diagramming becomes much faster than dragging and dropping boxes.

For teams already using PlantUML for other diagram types, like use case diagrams for e-commerce systems, adding class diagrams to the workflow feels natural since the tool and output format stay consistent.

Where Can You Practice and Test PlantUML Syntax?

The fastest way to learn is by using the official PlantUML online server. Paste your code in the left panel and see the rendered diagram instantly on the right. No installation needed.

For local development, you can install PlantUML as a VS Code extension, IntelliJ IDEA plugin, or run it from the command line with Java. Most IDE plugins support live preview, which makes iteration fast.

Having a local cheatsheet ready alongside your editor whether that's a bookmarked page or a printed reference eliminates the friction of switching contexts every time you need to look up arrow syntax or visibility notation.

Quick Reference: PlantUML Class Diagram Syntax Cheatsheet

Save or bookmark this section for quick access during your next modeling session. You can also explore our complete PlantUML class diagram syntax reference with ready-to-use code templates for common patterns.

Class Declarations

  • class Name basic class
  • abstract class Name abstract class
  • interface Name interface
  • enum Name enumeration
  • annotation Name annotation

Visibility Modifiers

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

Relationship Arrows

  • --|> inheritance
  • ..|> interface implementation
  • -- composition
  • o-- aggregation
  • --> association
  • ..> dependency

Structural Elements

  • package "Name" group classes
  • note right of Class add notes
  • <<stereotype>> custom labels
  • hide circle remove interface markers
  • skinparam global style control

Your Next Step

Pick one class from a current project, declare it in PlantUML with its fields and methods, then add its direct parent and one interface it implements. Render it, check the output against your actual code, and expand from there. Starting small with real code beats trying to diagram an entire system from scratch. Keep the cheatsheet above open in a tab and you'll have the syntax down within a few sessions.