Когда лучше применять UML?

Когда лучше применять UML

UML (Unified Modeling Language) — это мощный инструмент, но его легко переиспользовать. За 10+ лет я выработал четкое понимание когда UML помогает, а когда это overkill. Вот мой подход:

1. Когда UML ОЧЕНЬ полезен

Сценарий 1: Сложная бизнес-логика с множественными actors

Пример: система управления больницей

• Много типов пользователей (Doctor, Nurse, Patient, Admin)
• Много процессов (Appointment, Prescription, Invoice)
• Много связей между сущностями

Здесь UML Use Case Diagram помогает:

Doctor:
  - View patient records
  - Create prescription
  - Schedule appointment

Nurse:
  - Administer medication
  - Monitor vitals
  - Update patient records

Patient:
  - Book appointment
  - View medical history
  - Pay invoice

System:
  - Send notifications
  - Generate reports
  - Manage database

Без диаграммы тяжело увидеть полную картину. С диаграммой все ясно.

**Сценарий 2: Много типов данных и их связи (Data Model)

Пример: e-commerce платформа

• Customers, Orders, Products, Payments, Shipments, Reviews
• Каждая сущность связана с другими
• Нужно понять как они влияют друг на друга

Здесь ERD (Entity-Relationship Diagram, часть UML) очень полезен:

Customer (1:N)
    ↓
Order (1:N)
    ↓
OrderItem (N:1)
    ↓
Product

Order (1:1)
    ↓
Payment

Order (1:1)
    ↓
Shipment

Разработчик видит сразу: один Customer может иметь много Orders, но один Order может быть только у одного Customer.

**Сценарий 3: Сложный процесс с много ветвлений (BPMN)

Пример: процесс обработки loan application

Customer submits application
    ↓
System validates data
    ↓
(Decision) Is data valid?
    ├─ No → Return error
    └─ Yes → Check credit score
            ↓
        (Decision) Score > 700?
            ├─ No → Request more documents
            └─ Yes → Approve loan
                    ↓
                Send confirmation

Это лучше чем описывать словами. Разработчик видит все ветвления.

**Сценарий 4: Архитектура больших систем (Component/Deployment Diagram)

Пример: микросервисная архитектура

Clients
  ↓
API Gateway
  ├─ Order Service
  ├─ Payment Service  
  ├─ Inventory Service
  └─ Notification Service
      ↓
    Message Queue (RabbitMQ)
      ↓
    Database

Это помогает новому разработчику понять как компоненты взаимодействуют.

2. Когда UML НЕ нужен или вредит

Сценарий 1: Простая crud app (Create, Read, Update, Delete)

Пример: список задач (To-do app)

• Таблица Task (id, title, description, completed, created_at)
• Endpoints: GET, POST, PUT, DELETE

UML здесь лишний. Нужно просто написать:

Task:
- id: UUID
- title: string
- description: text
- completed: boolean
- created_at: timestamp
- updated_at: timestamp

Endpoints:
- GET /tasks
- GET /tasks/{id}
- POST /tasks
- PUT /tasks/{id}
- DELETE /tasks/{id}

Это четче и быстрее чем рисовать диаграмму.

Сценарий 2: Быстрый MVP (Minimum Viable Product)

Когда нужно быстро запустить на маркет, UML съедает время:

• Рисовать диаграмму: 3 часа
• Кодировать без диаграммы: 2 часа

Выбор: сделать MVP за 2 часа и уточнить после, или потратить 5 часов? Очевидно выбираем MVP.

Сценарий 3: Детали меняются часто

Пример: стартап где требования меняются еженедельно

• Я рисую диаграмму
• На следующей неделе требование меняется
• Диаграмма устарела
• Нужно переделать

Это напрасная трата времени. Лучше агильный подход: minimum documentation.

Сценарий 4: Переусложнение

Люди которые просто выучили UML часто создают избыточные диаграммы:

❌ Плохо: UML диаграмма для "User может логиниться"
Это слишком просто для диаграммы.

✅ Хорошо: просто написать
"User enters email/password → System validates → Opens dashboard"

3. Мой критерий: когда использовать UML

Задаю себе 3 вопроса:

Вопрос 1: Сложность >= средней?

• Если система простая (< 5 сущностей, < 10 use cases) → нет UML
• Если система сложная (> 10 сущностей, > 20 use cases) → да UML

Вопрос 2: Много людей нужно понять архитектуру?

• Если только я и разработчик (2 человека) → могу обойтись без UML
• Если 5+ человек включая новичков → нужна диаграмма

Вопрос 3: Требования стабильны?

• Если требования меняются часто → UML упадет
• Если требования заморозили → UML поможет

Итого: Eсли ДА на 2+ вопроса → применяю UML. Если НЕТ на все → обхожусь документацией.

4. Какие типы UML диаграмм использую (и когда)

НА ПРАКТИКЕ я использую только: Use Case, Sequence, State Machine, ER Diagram. Всё остальное редко.

5. Инструменты для UML

Простые и быстрые:

• Figma (рисую вручную, красиво)
• Miro (для совместной работы и brainstorms)
• Draw.io (бесплатно, есть UML shapeы)
• Lucidchart (много возможностей)

Сложные, но мощные:

• Enterprise Architect (для больших проектов)
• Astah (Java-based, специализирован на UML)
• Visual Paradigm (полнофункциональная)

Из кода:

• PlantUML (ASCII art диаграммы, хороши для гита)
• Mermaid (диаграммы в Markdown)

Мой выбор: Figma для простых диаграмм, Draw.io для более сложных.

6. Мой процесс создания UML

Шаг 1: Сбор информации (30 минут)

• Встреча с PM и разработчиками
• Задаю вопросы о системе
• Записываю ключевые моменты

Шаг 2: Черновик (30 минут)

• Рисую на бумаге или в Figma
• Быстро, не красиво
• Главное — уловить структуру

Шаг 3: Обсуждение с командой (15 минут)

• Показываю черновик
• Спрашиваю: "Это правильно?"
• Ловлю ошибки пока диаграмма не финализирована

Шаг 4: Финализация (30 минут)

• Красивое оформление
• Добавляю легенду
• Добавляю note с объяснениями

Шаг 5: Документирование (15 минут)

• Помещаю в Confluence/Wiki
• Добавляю описание
• Линк из Requirements документа

Итого: ~2 часа на качественную UML диаграмму.

7. Практические примеры

Пример 1: Use Case Diagram для социальной сети

Actors:

• Regular User
• Premium User
• Admin

Use Cases:

• Create post (Both users)
• Post to schedule (Premium only)
• View analytics (Premium only)
• Ban user (Admin only)
• Moderate content (Admin only)

Это ясно показывает что может делать каждый.

Пример 2: State Diagram для заказа

New → (validate) → Confirmed
      ↓ (if invalid)
      Cancelled

Confirmed → (payment) → Processing
        ↓ (if payment fails)
        Failed

Processing → (ship) → Shipped
Shipped → (deliver) → Delivered
Delivered → (optional refund) → Refunded

Это помогает разработчику кодировать state transitions правильно.

Пример 3: Sequence Diagram для платежа

User → Frontend: Нажимает "Pay"
Frontend → Backend: POST /payments {amount, card_id}
Backend → PaymentGateway: Запрос платежа
PaymentGateway → Bank: Проверка карты
Bank → PaymentGateway: OK
PaymentGateway → Backend: Status: success
Backend → Database: Сохраняем платёж
Backend → Frontend: 201 Created
Frontend → User: "Платёж успешен!"

Разработчик видит точно в каком порядке происходит взаимодействие.

8. Ошибки которые я делал

Ошибка 1: Рисовал слишком детальную диаграмму

• Было 50 классов на диаграмме
• Никто не мог её прочитать
• Вывод: лучше несколько простых диаграмм чем одна сложная

Ошибка 2: Создавал UML но потом не обновлял

• Требования меняются
• Диаграмма остается старой
• Люди получают неправильную информацию
• Вывод: если создавать UML, нужно поддерживать актуальной

Ошибка 3: Использовал UML для всего

• Даже для простых API endpoints
• Тратил часы на диаграммы вместо требований
• Вывод: меньше диаграмм, больше текста

9. Когда UML помог мне избежать проблемы

Case Study: Миграция платежной системы

Мы переходили с платежки A на платежку B. Нужно было понять все dependencies.

Я создал Sequence Diagram:

Order → Payments Service → Payment Provider
              ↓
        Notification Service (sends email)
              ↓
        Invoice Service (creates invoice)
              ↓
        Shipping Service (triggers shipment)

Это показало что Payment Service дергает 3 других сервиса. Если переписать неправильно, всё сломается.

Вышло что Notification Service ожидает конкретный формат от Payment Service. Когда мы переходили на новую платежку, нужно было обновить это взаимодействие.

Без диаграммы мы бы забыли про это и получили баг на production.

10. Мой финальный совет

Используй UML когда:

• Система сложная
• Много людей нужно понять архитектуру
• Требования стабильны
• Есть время

Не используй UML когда:

• Система простая
• Только ты и разработчик
• Требования часто меняются
• Срочно нужно запустить

Помни: UML это не цель, это средство. Если документация в текстовом виде работает — используй текст. Если нужна визуализация — используй UML.

Профессионал выбирает инструмент в зависимости от ситуации, а не использует один инструмент для всего.