Диаграммы UML — это «язык жестов» для разработчиков. Они помогают объяснить сложные процессы, даже если вы говорите на разных языках. Сегодня разберём 4 ключевых типа: последовательности, состояний, прецедентов и активности. Всё с примерами в PlantUML, которые можно скопировать за минуту!
1. Диаграмма последовательности (Sequence Diagram)
Зачем: Показать, как объекты взаимодействуют во времени.
Пример: Процесс оплаты заказа с альтернативами.
@startuml
actor User
participant "Клиентская часть" as Client
participant "Сервер" as Server
participant "Платёжный шлюз" as Gateway
participant "База данных" as DB
User -> Client: Нажимает "Оплатить"
Client -> Server: **Синхронный** запрос /create_order (POST)
Server -> DB: Сохранить заказ
DB --> Server: OK
Server --> Client: ID заказа
alt Успешная оплата
Client ->> Server: **Асинхронный** запрос /process_payment (Async)
Server -> Gateway: Проверить платёжные данные
Gateway --> Server: Успех
Server -> DB: Обновить статус заказа
DB --> Server: OK
Server -->> Client: "Оплата прошла"
else Ошибка оплаты
Client ->> Server: **Асинхронный** запрос /process_payment
Server -> Gateway: Проверить платёжные данные
Gateway --> Server: Ошибка
Server -->> Client: "Платёж отклонён"
end
opt Повторная попытка
Client -> Server: /retry_payment
Server -> Gateway: Повторная проверка
Gateway --> Server: Успех
end
@enduml
Что видно:
- **Синхронный** vs **Асинхронный** (стрелки с разными наконечниками).
- alt — альтернативные ветки (успех/ошибка).
- opt — опциональный шаг (повторная попытка).
2. Диаграмма состояний (State Diagram)
Зачем: Показать, как объект меняет состояния.
Пример: Состояния заказа и уведомлений.
@startuml
[*] --> Создан
state Создан
state Оплачен
state Отправлен
state Доставлен
state Отменён
state Уведомления {
state "Отправить email" as Email
state "SMS-оповещение" as SMS
Email --> SMS : После email
}
Создан --> Оплачен : Платёж подтверждён
Оплачен --> Отправлен : Товар у курьера
Отправлен --> Доставлен : Курьер доставил
Отправлен --> Отменён : Покупатель отказался
Оплачен --> Уведомления : Триггер уведомлений
Уведомления --> Отправлен : После отправки
Отменён --> [*]
Доставлен --> [*]
@enduml
Что видно:
- Параллельное состояние Уведомления (отправка email и SMS).
- Ветвление статусов заказа.
3. Диаграмма прецедентов (Use Case Diagram)
Зачем: Описать взаимодействие пользователей с системой.
Пример: Система бронирования отелей.
@startuml
left to right direction
actor "Гость" as User
actor "Админ" as Admin
rectangle "Система бронирования" {
usecase (Поиск отеля) as Search
usecase (Бронирование) as Book
usecase (Оплата) as Pay
usecase (Отмена брони) as Cancel
usecase (Добавить отель) as AddHotel
usecase (Аналитика) as Analytics
User --> Search
User --> Book
User --> Pay
User --> Cancel
Admin --> AddHotel
Admin --> Analytics
Book .> Search : include
Cancel .> Pay : extend
Analytics .> Book : include
}
@enduml
Что видно:
- include — обязательная связь (бронирование включает поиск).
- extend — опциональная связь (отмена возможна только после оплаты).
4. Диаграмма активности (Activity Diagram)
Зачем: Показать поток действий, как в блок-схеме.
Пример: Регистрация пользователя с верификацией.
@startuml
start
:Пользователь вводит email и пароль;
if (Email корректен?) then (Да)
:Проверить уникальность email;
if (Email свободен?) then (Да)
fork
:Создать аккаунт;
:Отправить письмо для подтверждения;
fork again
:Записать логи;
end fork
else (Нет)
:Показать ошибку;
endif
else (Нет)
:Показать ошибку;
endif
split
:Пользователь подтверждает email;
:Активировать аккаунт;
split again
:Пользователь не подтвердил email за 24ч;
:Удалить аккаунт;
end split
stop
@enduml
Что видно:
- fork/fork again — параллельные потоки (создание аккаунта + логирование).
- split — альтернативные сценарии (подтверждение/удаление аккаунта).
Какую диаграмму выбрать?
- Последовательности → Для анализа взаимодействия между компонентами.
- Состояний → Для описания жизненного цикла объекта (например, заказ, пользователь).
- Прецедентов → Для проектирования функционала с точки зрения пользователя.
- Активности → Для визуализации бизнес-процессов или сложных алгоритмов.
Как работать с PlantUML?
- Копируйте примеры выше, меняйте названия и связи.
- Экспортируйте в PNG/SVG для документации.
Заключение:
Диаграммы UML — это не «бюрократия», а способ сэкономить часы на объяснениях. Не пытайтесь рисовать всё — выбирайте тип под задачу. И помните: даже простая схема лучше километра текста!