Class diagram symbols: relationships, arrows and visibility

What are the class diagram symbols for classes, interfaces and members?

Every classifier is a rectangle. What changes is the text inside: a stereotype in guillemets above the name, italics for abstract, underlining for static. Mermaid's classDiagram writes the same things with annotations such as <<interface>>.

Visibility marks: + − # ~

The character in front of an attribute or operation states who may access it. UML 2.5.1 §9.5.4 defines four values; Mermaid uses the same prefixes.

Full member syntax (UML 2.5.1 §9.5.4 and §9.6.4): visibility name : type [multiplicity] = default {property} for attributes — e.g. - tags : String [0..*] {ordered} — and visibility name(parameter : type, …) : returnType for operations — e.g. + pay(amount : Money) : bool. Mermaid writes the type first: -Money total, +pay(Money amount) bool.

Relationship arrows

Read the line from the end without the marker toward the end with it: the triangle points at the parent, the diamond sits on the whole, the dependency arrow points at the thing being used.

Multiplicity

Written at the end of an association or aggregation, next to the class whose instances are being counted. UML 2.5.1 §7.5.4 defines the form lower..upper; * alone means 0..*.

Stereotypes and keywords

What is a class diagram?

A class diagram is the UML structure diagram that shows the classes of an object-oriented system, what each class knows (attributes) and does (operations), and how the classes relate — inheritance, composition, association, dependency. It is drawn at three levels of detail: conceptual (domain classes only), specification (interfaces and types) and implementation (every member with visibility and type, ready to code from).

What is the difference between aggregation and composition?

Both are whole–part associations drawn with a diamond on the whole. Composition (filled diamond) is exclusive and life-dependent: an OrderLine exists inside exactly one Order and is deleted with it. Aggregation (hollow diamond) is shared and independent: a Teacher belongs to a Department but survives its closure and may serve two departments. If you are unsure, use a plain association — UML 2.5.1 itself leaves the precise semantics of shared aggregation to the modeller.

What is the difference between generalisation and realisation?

Both end in a hollow triangle. Generalisation is a solid line between two classes (or two interfaces): the child inherits everything from the parent. Realisation is a dashed line from a class to an interface: the class promises to implement the interface's operations but inherits no state. In code, generalisation is extends and realisation is implements.

Which way do the arrows point?

Always toward the more general or more stable thing. The generalisation triangle points at the parent, the realisation triangle at the interface, the dependency arrow at the supplier (the class being used), the navigable-association arrow at the class being referenced. The diamond is not an arrow: it sits on the whole, and the part is at the other end.

What does a class diagram look like with these symbols?

A small order-management model: Customer inherits from User; a Customer places many Orders; an Order is composed of OrderLines that refer to Products; CardPayment realises the Payable interface that Order depends on; InvoiceService has a «use» dependency on Order. Below it, the same model as Mermaid code you can paste into any Mermaid renderer.

classDiagram
    class User {
        <<abstract>>
        #UUID id
        -String email
        +login() bool
    }
    class Customer {
        -int loyaltyPoints
        +placeOrder() Order
    }
    class Order {
        -Date date
        -OrderStatus status
        +total() Money
    }
    class OrderLine {
        -int quantity
        +subtotal() Money
    }
    class Product {
        -String sku
        -Money price
    }
    class Payable {
        <<interface>>
        +pay(Money amount) bool
    }
    class CardPayment {
        -String last4
        +pay(Money amount) bool
    }
    class OrderStatus {
        <<enumeration>>
        NEW
        PAID
        SHIPPED
    }
    User <|-- Customer : inheritance
    Customer "1" --> "0..*" Order : places
    Order "1" *-- "1..*" OrderLine : contains
    OrderLine "*" --> "1" Product
    Payable <|.. CardPayment : realization
    Order ..> Payable : uses
    Order --> OrderStatus

In Mermaid, the marker goes on the side it belongs to: User <|-- Customer puts the triangle on User; Order *-- OrderLine puts the filled diamond on Order; multiplicities are quoted strings on either side of the arrow.

Class diagram vs ER diagram — what is the difference?

An ER diagram models data to be stored — tables, columns, keys and cardinality — and has no operations or inheritance. A class diagram models the program — attributes and behaviour, inheritance, interfaces, dependencies — and includes classes that never touch the database, such as services and controllers. Entities in an ERD usually map to the persistent classes of the class diagram.

Crow's foot, Chen and UML data-modelling notation are compared in the ER diagram symbols reference.

What are the most common class diagram mistakes?

Most are a wrong line end — a filled diamond where the parts are shared, a triangle pointing at the child — or members that leak implementation detail into a conceptual diagram.

What do real diagrams with these symbols look like?

Live diagrams from the public ChartCraft gallery, each generated from a plain-English description — open one to see the prompt that produced it.

Class diagram relationships →

Domain class diagram →

Banking system →

Online shopping →

ATM system →

Hospital management system →

More symbol references