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

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

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

Назначение диаграммы классов

• Визуализация архитектуры системы на уровне классов и интерфейсов
• Документирование структуры кода перед его написанием
• Коммуникация между разработчиками и аналитиками
• Планирование реализации (какие классы создавать, как они связаны)
• Рефакторинг — анализ существующей архитектуры
• Анализ зависимостей между компонентами

Основные элементы диаграммы классов

1. Класс (Class)

Класс изображается прямоугольником, разделённым на три секции:

┌─────────────────────────┐
│     User                │  ← Имя класса
├─────────────────────────┤
│ - id: Integer           │  ← Атрибуты (Attributes)
│ - name: String          │
│ - email: String         │
│ # password: String      │
├─────────────────────────┤
│ + login(email, pwd)     │  ← Методы (Operations)
│ + logout()              │
│ + updateProfile()       │
│ - validateEmail()       │
└─────────────────────────┘

Модификаторы доступа:

• + Public (публичный)
• - Private (приватный)
• # Protected (защищённый)
• ~ Package (пакетный)

2. Интерфейс (Interface)

┌──────────────────────┐
│ <<interface>>        │
│ Serializable         │
├──────────────────────┤
│ + serialize()        │
│ + deserialize()      │
└──────────────────────┘

Типы связей между классами

1. Наследование (Inheritance/Generalization)

Отношение IS-A (является).

        Animal          ← Родительский класс (суперкласс)
         △
         │ (стрелка с пустым треугольником)
         │
    ┌────┴─────┐
    │           │
  Dog         Cat       ← Дочерние классы (подклассы)

2. Реализация (Implementation)

Класс реализует интерфейс.

    Drawable          ← Интерфейс
         △
         │ (пунктирная стрелка с пустым треугольником)
         │
      Circle          ← Класс реализует интерфейс

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

Общее отношение между классами (HAS-A).

Employee  ─────── Department
  1         works in    *

Мультипликативность (Cardinality):

• 1 — ровно один
• * — 0 или более
• 0..1 — 0 или один
• 1..* — 1 или более
• 2..5 — от 2 до 5

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

Отношение "часть-целое" с возможностью существования части отдельно.

Team ◇────── Player
  1           *
  (пустой ромб на стороне целого)

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

Сильная форма агрегации — часть существует только с целым.

Car ◆────── Engine
  1           1
  (заполненный ромб на стороне целого)

Различие:

• Агрегация: Игроки существуют независимо от команды
• Композиция: Двигатель существует только с машиной

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

Один класс зависит от другого для выполнения операций.

UserService ......>  Logger
         (пунктирная стрелка)

Пример полной диаграммы классов

                      <<interface>>
                     Comparable
                         △
                         │
                    ┌────┴────┐
                    │          │
                  User     Product
                    │
                ┌───┴──────┐
              Admin   Customer

┌──────────────────────┐      ┌─────────────────────┐
│      User            │      │   Order             │
├──────────────────────┤      ├─────────────────────┤
│ - id: UUID           │◇─────│ - orderId: UUID     │
│ - name: String       │  1  *│ - date: DateTime    │
│ - email: String      │      │ - totalAmount: Dec  │
│ # password: String   │      └─────────────────────┘
├──────────────────────┤              △
│ + login()            │              │
│ + logout()           │              │
│ + getOrders()        │              │
│ - validateEmail()    │              │
└──────────────────────┘      ┌──────┴──────────┐
         △                    │                 │
         │                    │                 │
         │              ┌─────────────┐  ┌──────────────┐
         │              │  OnlineOrder│  │ OfflineOrder │
         │              └─────────────┘  └──────────────┘
    ┌────┴────┐
    │          │
┌──────┐  ┌────────┐
│Admin │  │Customer│
└──────┘  └────────┘
         (имеют операции из User)

Представление в коде

# На основе диаграммы
class User(Comparable):
    def __init__(self, id: UUID, name: str, email: str):
        self.id = id
        self.name = name
        self.email = email
        self._password = None
    
    def login(self, email: str, password: str) -> bool:
        pass
    
    def logout(self) -> None:
        pass
    
    def _validate_email(self) -> bool:
        pass

class Customer(User):
    def __init__(self, user_id: UUID):
        super().__init__(user_id)
        self.orders: List[Order] = []

class Order:
    def __init__(self, order_id: UUID, date: datetime):
        self.order_id = order_id
        self.date = date
        self.total_amount = Decimal(0)

Когда использовать диаграмму классов

• Перед разработкой — проектирование архитектуры
• Документирование — описание существующей кодовой базы
• Code Review — обсуждение архитектурных решений
• Рефакторинг — анализ и улучшение структуры
• Обучение — объяснение архитектуры новичкам

Best Practices

• Не переусложняй — показывай только главное
• Группируй связанные классы — использование пакетов
• Используй стандартные символы UML — для понимания всеми
• Поддерживай актуальность — диаграмма должна соответствовать коду
• Абстракция — разные уровни детализации для разных аудиторий

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

• Enterprise Architect — полнофункциональное решение
• Lucidchart — облачный инструмент
• Draw.io — бесплатный и простой
• PlantUML — текстовое описание диаграмм
• Miro — для коллаборативной работы