Что такое диаграмма классов?
А Диаграмма классов — это структурная диаграмма 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..*") определяют требования к отношениям в системе.