Software structure modeling

Mermaid Class Diagram Online Editor

Review software types and their relationships with a Mermaid class diagram. Add selected members, distinguish inheritance from ownership, and show multiplicity before exporting the model for a design discussion.

Build a Mermaid class diagram online

Adapt the order and line-item example below. Use the preview to check arrow direction, member visibility, and ownership.

OnUML
Loading diagram preview...

Make the structure of a design explicit

A class diagram describes types and behavior. Use an ER diagram instead when the main question is persisted entities, keys, and database relationships.

Attributes and operations

List only the fields and methods that explain a responsibility or contract.

Visibility markers

Use +, -, #, and ~ to mark public, private, protected, and package visibility.

Inheritance and interfaces

Separate generalization from realization so a subclass and an interface implementation are not confused.

Ownership and multiplicity

Use composition, aggregation, or association and annotate how many objects can participate at each end.

Create a focused software structure diagram

Choose the design question first; a class diagram does not need to copy every member from the codebase.

  1. 01

    Declare classDiagram, add the relevant classes, and include selected attributes or methods in class blocks.

  2. 02

    Choose relationship symbols deliberately and add quoted multiplicities where they express a real constraint.

  3. 03

    Read each arrow and ownership relationship in the preview, then export or save the diagram for review.

Class diagram syntax for members and relationships

The arrowhead or diamond has meaning. Check which endpoint owns the relationship instead of choosing a line only for appearance.

Mermaid class diagram syntax reference →

Members and return types

An operation contains parentheses. Put its return type after the closing parenthesis; prefix members with a visibility marker when it matters.

classDiagram
    class Invoice {
        +String id
        -Decimal balance
        +pay() Receipt
    }

Inheritance and interface realization

In Base <|-- Child the triangle points to the base class. Use a dashed realization line for an interface contract and mark the interface explicitly.

classDiagram
    class PaymentMethod {
        <<interface>>
        +pay() Receipt
    }
    PaymentMethod <|.. CardPayment
    LineItem <|-- DigitalLineItem

Composition, aggregation, and dependency

A filled diamond marks composition and a hollow diamond aggregation. Place the diamond at the whole. A dashed dependency arrow indicates that one type uses another.

classDiagram
    Order *-- LineItem : contains
    Team o-- Member : groups
    CheckoutService ..> PaymentMethod : uses

Multiplicity on both endpoints

Quote constraints next to each end. Here an order belongs to exactly one customer, while a customer can have no orders or many.

classDiagram
    Customer "1" --> "0..*" Order : places
    Order "1" *-- "1..*" LineItem : contains

Mermaid class diagram example

An Order contains one or more LineItem objects. DigitalLineItem specializes LineItem with a download URL, while each class lists only members needed to explain the model.

classDiagram
    class Order {
        +String id
        +OrderStatus status
        +total() Decimal
    }
    class LineItem {
        +String sku
        +int quantity
        +subtotal() Decimal
    }
    class DigitalLineItem {
        +String downloadUrl
    }
    Order "1" *-- "1..*" LineItem : contains
    LineItem <|-- DigitalLineItem
  • The diamond beside Order expresses the chosen ownership model for its line items.
  • The inheritance triangle points toward LineItem, the more general type.
  • Try adding a physical line-item subclass. Check whether specialization is really needed before adding more members.

Frequently asked questions

Which way should an inheritance arrow point?

The triangle points to the parent or base type. Base <|-- Child reads as Child inherits from Base.

How do I show an interface?

Declare the interface with an <<interface>> annotation and use a realization relationship, such as PaymentMethod <|.. CardPayment.

What is the difference between composition and aggregation?

Composition uses a filled diamond for strong whole-part ownership; aggregation uses a hollow diamond for a weaker whole-part relationship. Choose the notation that matches your lifecycle model rather than assuming every collection is composition.

How do I write a one-to-many relationship?

Put quoted multiplicities beside the endpoints, for example Customer "1" --> "0..*" Order. Use 1..* when at least one related object is required.

Why is a member shown as a method?

Mermaid distinguishes operations by parentheses. Use field declarations without parentheses for attributes and method() ReturnType for operations.

How do I label a relationship?

Write a colon and a short label after the connection, such as Order *-- LineItem : contains. Use a verb that explains the link and keep multiplicities beside the endpoints.

Choose the right notation

Compare Mermaid and PlantUML class diagrams

See where Mermaid is sufficient for lightweight structure diagrams and when richer PlantUML modeling features become useful.

Read the class diagram comparison →