Руководство по синтаксису диаграмм классов Mermaid.js

Что такое диаграмма классов?

А Диаграмма классов — это структурная диаграмма UML которая визуализирует статическую архитектуру объектно-ориентированной программной системы. Как незаменимый тип типа диаграммы UML, она отображает отдельные классы, интерфейсы и модели данных в вашем приложении, явно документируя их внутренние поля (атрибуты), операционные функции (методы) и структурные отношения, которые их объединяют. Этот чертеж жизненно важен для инженеров программного обеспечения, которым необходимо преобразовывать высокий уровень проектирования домена в чистые, поддерживаемые объектные структуры.

С помощью Mermaid.js, вы можете описать свои модели данных и системные службы с помощью интуитивно понятных текстовых определений. Двигатель компоновки автоматически рассчитывает размеры блоков, формирует стандартные компартменты данных UML и выравнивает связующие стрелки по всему холсту без необходимости ручной настройки форматирования.

Руководство по основному синтаксису: элементы и конструкции

Чтобы создать точную, соответствующую стандартам диаграмму классов UML в Mermaid, необходимо освоить объявления членов, модификаторы доступа и стрелки структурных отношений.

1. Объявление классов и компартментов классов

Вы можете определить класс с помощью двух допустимых форматов. Для простого класса используйте ключевое слово classс последующим именем класса. Если вы хотите сразу включить поля и методы, используйте закрывающие фигурные скобки для создания четкого блока тела:

classDiagram
    class UserProfile {
        +String username
        +String email
        +updateEmail(newEmail) void
    }

2. Добавление модификаторов видимости / доступа

Чтобы документировать стандартные правила инкапсуляции UML, поместите специальный символ непосредственно перед именем атрибута или метода, чтобы определить его уровень видимости:

  • + **Публичный:** Доступен из любого другого класса.
  • - **Приватный:** Доступен только внутри объявляющего класса.
  • # **Защищенный:** Доступен внутри класса и его подклассов.
  • ~ **Пакет / Внутренний:** Доступно в пределах той же границы пакета.
classDiagram
    class BankAccount {
        -double balance
        #String accountHolder
        +getBalance() double
    }

3. Освоение стрелок отношений и ссылок наследования

Чтобы показать, как классы взаимодействуют в вашей модели диаграммы UML, соедините их идентификаторы с помощью специализированных строк отношений. В Mermaid направление линии имеет значение: головка стрелки указывает на родительский или контейнерный класс.

  • Наследование / Обобщение (штриховая или сплошная стрелка): Child --|> Parent (Представляет отношение «является»).
  • Реализация / Реализация: Class ..|> Interface (Представляет класс, выполняющий контракт интерфейса).
  • Композиция (сплошной ромб): Child --* Parent (Представляет строгую собственность; если родитель умирает, умирает и дочерний элемент).
  • Агрегация (прозрачный ромб): Child --o Parent (Представляет слабую связь коллекции; дочерний элемент может существовать независимо).
  • Зависимость: ClassA ..> ClassB (Представляет временную ссылку во время выполнения).
classDiagram
    Car --|> Vehicle : "Наследуется от"
    Engine --* Car : "Является частью"

Лучшие практики для чистых макетов архитектуры классов

  • Визуальное группирование членов класса: Всегда группируйте переменные класса в верхней части блока тела и функции в нижней. Такое расположение соответствует стандартной структуре классов в IDE и делает ваши диаграммы мгновенно читаемыми.
  • Укажите типы возвращаемых значений: При объявлении методов добавьте тип возвращаемого значения в конец строки метода (например, +fetchData() DataSet). Это дает вашей инженерной команде точный контекст реализации.
  • Держите множественность ясной: Чтобы указать количество элементов массива или размер коллекции, добавьте текстовые строки множественности непосредственно к оболочке линии связи (например, Customer "1" --o "many" Order).

Примеры диаграмм классов Mermaid.js из реальной жизни

Пример 1: Подсистема домена шлюза оплаты (инкапсуляция и интерфейсы)

Этот функциональный чертеж моделирует сервис домена онлайн-оплаты. Он демонстрирует, как использовать модификаторы доступа, группировать члены класса и чисто реализовывать отношения интерфейсов.

classDiagram
    class PaymentProcessor {
        <<interface>>
        +processPayment(amount) boolean
        +refundPayment(txnId) boolean
    }

    class StripeGateway {
        -String apiKey
        -String endpointUrl
        +processPayment(amount) boolean
        +refundPayment(txnId) boolean
        -logTransaction(status) void
    }

    class PayPalGateway {
        -String merchantId
        +processPayment(amount) boolean
        +refundPayment(txnId) boolean
    }

    StripeGateway ..|> PaymentProcessor : "Реализует"
    PayPalGateway ..|> PaymentProcessor : "Реализует"

Разбор синтаксиса: Тег <<interface>> явно обозначает `PaymentProcessor` как высокоуровневое архитектурное соглашение. Два класса реализации шлюзов используют приватные поля (-apiKey) для чувствительных учетных данных, в то время как публичные методы оплаты (+processPayment) связаны стрелкой реализации (..|>).

Пример 2: Двигатель обработки заказов для предприятий (композиция и множественность)

Этот продвинутый чертеж системы отображает сложную схему управления заказами в электронной коммерции, демонстрируя, как документировать структурную принадлежность и количество объектов между несколькими взаимосвязанными классами.

classDiagram
    class Customer {
        +int customerId
        +String name
        +placeOrder() Order
    }

    class Order {
        +int orderId
        +Date dateCreated
        -String internalStatus
        +calculateTotal() double
    }

    class OrderItem {
        +int itemId
        +int quantity
        +double pricePerUnit
    }

    class Address {
        +String street
        +String city
        +String postalCode
    }

    Customer "1" --o "many" Order : "владеет"
    OrderItem "1..*" --* "1" Order : "составляет"
    Address "1" --> Order : "доставляется на"

Разбор синтаксиса: Этот пример иллюстрирует различие между агрегацией и композицией. Сплошная стрелка с ромбом (--*) показывает, что `OrderItem` тесно связан с `Order` (если заказ удаляется, то его отдельные позиции также удаляются). Напротив, стрелка с прозрачным ромбом (--o) указывает на то, что `Customer` владеет несколькими заказами, но оба объекта могут существовать независимо. Строки множественности (например, "1..*") определяют требования к отношениям в системе.

Прокрутить вверх