UML class diagrams

The class header (alias uml) switches to single-column UML class boxes, connected with UML relationship arrowheads instead of the crow's-foot notation of an ERD. It shares that family's block grammar: a class is a named block of members, and a line of dashes inside it is a compartment divider.

class
Animal {
  +name string
  -age int
  ---
  +makeSound() void
  +move() void
}
Dog {
  +breed string
  ---
  +fetch() void
}
Dog --|> Animal

Members and compartments#

• A --- (two or more dashes on their own line) draws a compartment divider. Members above the first divider are attributes; those below are methods.
• A leading +, -, #, or ~ sets visibility (public, private, protected, or package), drawn as that glyph.
• A member reads name type, written the way the code writes it: a method may list its parameters (+add(s: Shape) void), and a type may hold spaces (Map<string, Shape>, Shape | null). A method written without parentheses shows as name().

The block must span lines: the opening { and closing } sit on their own lines, one member per line between them. (An inline Dog { +fetch() void } on a single line is not parsed as a class.) A class with no members is written Runnable { }.

class
Account {
  +id uuid
  -balance decimal
  #owner string
  ~region string
  ---
  +deposit() void
  +withdraw() bool
  -audit() void
}

Relationships#

Each relationship has its own connector and UML arrowhead. Every connector has a mirror spelling (<|-- and --|>, *-- and --*, …) so you can write the ends in either order; the marker always lands on the correct end.

Both ends of a relationship must be declared classes. A plain -> (or a cardinality like 1:N) stays a normal ERD relation, so one diagram can mix UML relationships with crow's-foot links.

class
Shape {
  ---
  +area() float
}
Drawable {
  ---
  +draw() void
}
Circle {
  -radius float
}
Canvas {
  ---
  +render() void
}
Pen { }

Circle --|> Shape
Circle ..|> Drawable
Canvas *-- Shape
Canvas o-- Pen
Canvas ..> Drawable

Two larger models round this out. A small domain model first: a payment hierarchy with an interface, composition, and a dependency.

class
title: Payments domain

Payment {
  +id uuid
  #amount decimal
  ---
  +process() bool
  #validate() bool
}
CardPayment {
  +last4 string
  ---
  +process() bool
}
BankTransfer {
  +iban string
  ---
  +process() bool
}
Refundable {
  ---
  +refund() bool
}
Gateway {
  ---
  +charge() bool
}
Receipt {
  +number string
}

CardPayment --|> Payment
BankTransfer --|> Payment
CardPayment ..|> Refundable
Payment *-- Receipt
Payment ..> Gateway

A layered service architecture expressed as classes and dependencies.

class
title: Service layers

Controller {
  ---
  +handle() Response
}
Service {
  ---
  +execute() Result
}
Repository {
  ---
  +find() Entity
  +save() void
}
Database {
  -dsn string
}
Logger {
  ---
  +log() void
}

Controller ..> Service
Service ..> Repository
Service ..> Logger
Repository o-- Database

Namespaces#

A group { … } block wraps classes in a labelled container — a UML namespace or package, and the same word the graph families use. Members are laid out together inside their own frame, so the packaging survives instead of the boxes scattering across the diagram.

class

group auth {
  User {
    +id string
    +signIn() bool
  }
  Session {
    +token string
  }
}

group billing {
  Invoice {
    +total int
  }
}

User --|> Session
User ..> Invoice

Mermaid's namespace Foo { … } imports straight onto this, so a packaged class diagram keeps its packages. Nesting is flat: a namespace inside a namespace is folded into its parent rather than drawn as a frame within a frame.