Что такое диаграмма классов (Class Diagram) в UML?

Диаграмма классов (Class Diagram) в UML

Определение

Class Diagram — это статическая диаграмма, которая показывает структуру системы через классы, их атрибуты, методы и связи между классами.

Это одна из самых используемых UML диаграмм, особенно при проектировании объектно-ориентированных систем.

Назначение Class Diagram

1. Визуализация структуры кода

• Показать, как классы организованы
• Показать иерархию наследования
• Показать связи между компонентами

2. Коммуникация между разработчиками

• Новички быстро понимают архитектуру
• Проще обсуждать дизайн

3. Дизайн перед кодированием

• Спланировать структуру ещё до написания кода
• Найти проблемы в дизайне рано

4. Документирование

• Служит документацией системы
• Помогает при рефакторинге

Основные элементы Class Diagram

1. Класс (Class)

Класс представляется прямоугольником, разделённым на 3 части:

┌─────────────────────────┐
│        User             │  ← Имя класса
├─────────────────────────┤
│ - id: Integer           │  ← Атрибуты (поля)
│ - email: String         │
│ - password: String      │
│ - createdAt: DateTime   │
├─────────────────────────┤
│ + register()            │  ← Методы (операции)
│ + login()               │
│ + logout()              │
│ - hashPassword()        │
└─────────────────────────┘

Видимость (Modifiers):

• + = public (доступно всем)
• - = private (доступно только в классе)
• # = protected (доступно в классе и потомках)
• ~ = package (доступно в пакете)

2. Наследование (Inheritance)

Полая стрелка указывает на родительский класс:

        ┌──────────┐
        │ Person   │
        │ (abstract)│
        └────△─────┘
             │
        ┌────┴─────┬──────────┐
        │           │         │
    ┌──▼──┐    ┌───▼───┐  ┌──▼──┐
    │User │    │Admin  │  │Guest│
    └─────┘    └───────┘  └─────┘

Пример кода:

┌─────────────────────┐
│ Person (abstract)   │
├─────────────────────┤
│ # name: String      │
│ # age: Integer      │
├─────────────────────┤
│ + getName(): String │
└─────────────────────┘
        △
        │ наследование
        │
┌───────┴─────────┐
│ User            │
├─────────────────┤
│ - email: String │
├─────────────────┤
│ + login()       │
└─────────────────┘

3. Композиция (Composition)

Полый ромб — очень сильная связь (целое-часть, когда часть не может существовать без целого):

┌──────────┐
│ Car      │
├──────────┤
│ - engine │◆─────┐
│ - wheels │      │ Композиция
└──────────┘      │ (если машину удаляем, удаляем и двигатель)
            ┌─────▼──────┐
            │ Engine     │
            ├────────────┤
            │ - power    │
            └────────────┘

4. Агрегация (Aggregation)

Полусклеенный ромб — слабая связь целое-часть (часть может существовать без целого):

┌─────────────┐
│ University  │
├─────────────┤
│ - students  │◇──────┐
│ - teachers  │       │ Агрегация
└─────────────┘       │ (студент может существовать без ВУЗа)
               ┌──────▼──────┐
               │ Student     │
               ├─────────────┤
               │ - name      │
               │ - studentId │
               └─────────────┘

5. Ассоциация (Association)

Обычная линия показывает простую связь между классами:

┌────────┐         ┌─────────┐
│ Author │────────▶│ Book    │
└────────┘         └─────────┘
  1 автор пишет много книг (1 к многим)

Множественность (Multiplicity):

┌────────────┐         ┌──────────┐
│ Teacher    │ 1    * │ Student  │
│  teaches   │────────│ attends  │
└────────────┘        └──────────┘

1:1 = один к одному
1:* = один ко многим
*:* = многие ко многим
0..1 = ноль или один
1..5 = от одного до пяти

6. Зависимость (Dependency)

Пунктирная стрелка — одна вещь зависит от другой:

┌────────────┐
│ PaymentService  ┐
├──────────────┤ │
│ + pay()      │ │ зависит
└────────────┘ │ (использует)
     │         │
     ┆........▶┌────────────────┐
     │         │ PaymentGateway │
              │ (Stripe/PayPal) │
              └────────────────┘

Практический пример: E-commerce система

┌──────────────────┐
│ User             │
├──────────────────┤
│ - id: UUID       │
│ - email: String  │
│ - name: String   │
│ - password: Hash │
├──────────────────┤
│ + register()     │
│ + login()        │
│ + getOrders()    │
└────────┬─────────┘
         │ 1
         │ places
         │
         │ *
    ┌────▼─────────────┐
    │ Order            │
    ├──────────────────┤
    │ - id: UUID       │
    │ - createdAt: DT  │
    │ - totalPrice     │
    │ - status: Enum   │
    ├──────────────────┤
    │ + calculateTotal()│
    │ + cancel()       │
    └────┬─────────────┘
         │ 1
         │ contains
         │
         │ *
    ┌────▼──────────────┐
    │ OrderItem        │
    ├──────────────────┤
    │ - quantity       │
    │ - price          │
    ├──────────────────┤
    │ + getSubtotal()  │
    └────┬─────────────┘
         │ *
         │ references
         │
    ┌────▼─────────────┐
    │ Product          │
    ├──────────────────┤
    │ - id: UUID       │
    │ - name: String   │
    │ - price: Decimal │
    │ - stock: Integer │
    ├──────────────────┤
    │ + getPrice()     │
    │ + decreaseStock()│
    └──────────────────┘

Association: User places Orders
Association: Order contains OrderItems
Association: OrderItem references Product

Интерфейсы и абстрактные классы

┌────────────────────┐
│ <<interface>>      │
│ PaymentProcessor   │
├────────────────────┤
│ + process()        │
│ + refund()         │
└────────────────────┘
         △
         │ реализует
    ┌────┴────────────┬─────────────┐
    │                 │             │
┌───▼────────┐  ┌────▼──────┐  ┌───▼───────┐
│ StripeP.   │  │ PayPalP.  │  │ SquareP.  │
├────────────┤  ├───────────┤  ├───────────┤
│ - apiKey   │  │ - apiKey  │  │ - token   │
├────────────┤  ├───────────┤  ├───────────┤
│ + process()│  │ + process()│  │ + process()│
└────────────┘  └───────────┘  └───────────┘

Пакеты (Packages)

Общие папки, которые группируют классы:

┌─ domain ─────────────┐
│ ┌─────────────────┐  │
│ │ User            │  │
│ ├─────────────────┤  │
│ │ - id            │  │
│ └─────────────────┘  │
└─────────────────────┘
         △
         │
┌─ application ─────────────┐
│ ┌──────────────────────┐  │
│ │ UserService          │  │
│ ├──────────────────────┤  │
│ │ + register()         │  │
│ │ + getUserById()      │  │
│ └──────────────────────┘  │
└────────────────────────────┘
         △
         │
┌─ presentation ────────────┐
│ ┌──────────────────────┐  │
│ │ UserController       │  │
│ ├──────────────────────┤  │
│ │ + registerUser()     │  │
│ └──────────────────────┘  │
└────────────────────────────┘

Стереотипы (Stereotypes)

Дополнительная информация о классе:

┌──────────────────────────┐
│ <<Entity>>               │  ← Стереотип
│ User                     │
├──────────────────────────┤
│ - id: UUID               │
│ - email: String          │
├──────────────────────────┤
│ + getEmail(): String     │
└──────────────────────────┘

Узнаваемые стереотипы:
<<Entity>> — бизнес-сущность
<<ValueObject>> — объект значения
<<Service>> — сервис
<<Controller>> — контроллер
<<DTO>> — передача данных
<<Enum>> — перечисление
<<abstract>> — абстрактный класс

Инструменты для создания

PlantUML пример:

@startuml
class User {
  -id: UUID
  -email: String
  +login()
}

class Order {
  -id: UUID
  -status: String
}

User "1" --> "*" Order: places
@enduml

Когда использовать Class Diagram

ДА:

• Проектирование новой системы
• Рефакторинг существующего кода
• Документирование API или библиотеки
• Обучение новых разработчиков
• Дизайн-ревью

НЕТ:

• Простые скрипты
• Быстрое прототипирование
• Система с динамической типизацией (Python, JS)

Лучшие практики

1. Не переусложняй

   • Показывай только важные классы
   • Если много деталей → разбей на несколько диаграмм

2. Группируй по пакетам

   • domain, application, infrastructure

3. Используй осмысленные имена

   • User, Order, PaymentService (не A, B, C)

4. Соблюдай направления

   • Зависимости идут вверх-вниз
   • Абстракции вверху

5. Обновляй при изменениях

   • Диаграмма должна соответствовать коду
   • Иначе она бесполезна

Заключение

Class Diagram — это мощный инструмент для визуализации структуры ОО систем. Она помогает:

• Планировать архитектуру
• Коммуницировать идеи
• Документировать систему
• Выявлять проблемы в дизайне

Основное правило: диаграмма должна быть простой и понятной, не перегруженной деталями.