You can label relationships and specify multiplicity:

classDiagram
 Department "1" --> "0.." Employee : employs
 Employee --> Project : works on
 Employee "1" --> "1" Address : lives at

The quoted numbers describe multiplicity. "1" means exactly one, "0.." means zero or more, and "1.." means one or more. This mirrors how you'd annotate relationships in a traditional UML tool.

Can you add notes and abstract classes?

Yes. Mermaid supports abstract classes, interfaces, and annotations. Here's a more complete example showing these features:

classDiagram
 class Shape {
 <>
 +area() float
 +perimeter() float
 }
 class Drawable {
 <>
 +draw() void
 }
 class Circle {
 -float radius
 +area() float
 +perimeter() float
 +draw() void
 }
 class Rectangle {
 -float width
 -float height
 +area() float
 +perimeter() float
 +draw() void
 }
 Shape <|-- Circle
 Shape <|-- Rectangle
 Drawable <|.. Circle
 Drawable <|.. Rectangle

The <<abstract>> and <<interface>> annotations use angle brackets and display as stereotypes in the rendered diagram, just like you'd see in a standard UML diagram.

What does a real-world class diagram example look like?

Here's a practical example modeling a basic e-commerce system:

classDiagram
 class Customer {
 +int id
 +String name
 +String email
 +placeOrder() Order
 +viewOrders() List~Order~
 }
 class Order {
 +int orderId
 +Date createdAt
 +float total
 +addItem(Product, int) void
 +calculateTotal() float
 +getStatus() OrderStatus
 }
 class OrderItem {
 +int quantity
 +float unitPrice
 +getSubtotal() float
 }
 class Product {
 +int productId
 +String name
 +float price
 +int stock
 +isAvailable() bool
 }
 class OrderStatus {
 <>
 PENDING
 PAID
 SHIPPED
 DELIVERED
 CANCELLED
 }

 Customer "1" --> "0.." Order : places
 Order "1" -- "1.." OrderItem : contains
 OrderItem "1" --> "1" Product : references
 Order "1" --> "1" OrderStatus : has

Notice how the tilde syntax List~Order~ represents generics, since angle brackets conflict with Mermaid's stereotype syntax. The enumeration is declared using the <<enumeration>> stereotype.

How do you style class diagrams in Mermaid?

You can add CSS-based styling to individual classes using the style keyword or define CSS classes and apply them:

classDiagram
 class CriticalService {
 +process() void
 }
 class OptionalService {
 +process() void
 }
 CriticalService --> OptionalService
 style CriticalService fill:#f96,stroke:#333,stroke-width:2px
 style OptionalService fill:#bbf,stroke:#333

For broader styling across your diagrams, you can check our Mermaid diagram editor and tool comparison to find editors that offer live previews and easier styling workflows.

What are common mistakes when writing class diagrams in Mermaid?

Here are pitfalls that trip up both beginners and experienced developers:

1. Forgetting the class declaration. If you reference a class in a relationship but never declared it with the class keyword or implicitly through a relationship, Mermaid may not render it as expected. Always define your classes.
2. Using angle brackets for generics. Mermaid treats < and > as syntax for stereotypes and inheritance arrows. Use ~ for generic types instead (e.g., List~String~).
3. Mixing indentation styles. Mermaid's parser can be sensitive to indentation inside curly brace blocks. Keep your indentation consistent.
4. Confusing composition and aggregation. Composition (--) means the child can't exist without the parent. Aggregation (o--) means the child can. Choosing the wrong one misrepresents your system design.
5. Omitting relationship labels. Unlabeled relationships make diagrams hard to understand. Always add a label after the colon.
6. Overcomplicating a single diagram. Trying to model an entire system in one class diagram defeats the purpose. Break diagrams into focused views.

How do you render Mermaid class diagrams?

You have several options for rendering your Mermaid code:

• GitHub and GitLab both render Mermaid code blocks in markdown files automatically
• VS Code with the Mermaid extension gives you live preview
• The official Mermaid Live Editor at mermaid.live lets you paste code and see the diagram instantly
• Static site generators like Docusaurus and MkDocs have built-in Mermaid support

If you're deciding which tool fits your workflow best, our online tool comparison covers the main options side by side.

What's the difference between class diagrams and other Mermaid diagram types?

Class diagrams describe static structure what classes exist, what they contain, and how they relate. They're different from behavioral diagrams. For example:

• Sequence diagrams show how objects interact over time (message passing). If you need to model runtime behavior, sequence diagrams in Mermaid are the better choice.
• Flowcharts show process flows, not data structures
• ER diagrams model database tables and relationships, not object-oriented classes

Many teams use class diagrams during design and architecture discussions, then switch to sequence diagrams when discussing specific interactions or flows.

Can you use namespaces or group classes together?

Mermaid supports namespaces, which help organize large diagrams:

classDiagram
 namespace DataAccess {
 class UserRepository {
 +findById(int) User
 +save(User) void
 }
 class OrderRepository {
 +findByCustomer(int) List~Order~
 }
 }
 namespace BusinessLogic {
 class UserService {
 +register(User) void
 }
 class OrderService {
 +createOrder(int) Order
 }
 }

 UserService --> UserRepository
 OrderService --> OrderRepository
 OrderService --> UserService

Namespaces render as visual containers around grouped classes, making it easier to see architectural boundaries.

Quick checklist for writing class diagrams in Mermaid

1. Start every diagram with the classDiagram keyword on its own line
2. Use curly braces to define classes with members for readability
3. Add visibility markers (+, -, #, ~) to all members
4. Use ~ instead of <> for generic types
5. Label every relationship with a descriptive verb phrase
6. Include multiplicity on relationships where it matters
7. Use <<abstract>>, <<interface>>, and <<enumeration>> stereotypes where appropriate
8. Break large models into multiple focused diagrams
9. Render your diagram early and often using a live editor to catch syntax errors fast
10. Store your .mmd or markdown files in version control alongside your code

For a deeper look at all class diagram syntax variations, our complete Mermaid syntax reference covers every option available.