UML на практике: где диаграмма помогает, а где становится лишней

UML часто обсуждают как выбор между двумя крайностями: моделировать систему «правильно» или рисовать простые квадраты со стрелками. В реальной работе полезность диаграммы определяется не строгостью нотации, а вопросом, который она помогает решить.

Что даёт UML

UML — семейство нотаций для описания структуры и поведения системы. Оно помогает сделать предположение видимым: показать участников, компоненты, состояния или порядок взаимодействий и проверить, одинаково ли команда понимает модель.

Диаграмма не заменяет требования, код, API-контракт или решение архитектора. Она связывает нужные части в одном представлении. Если после обсуждения решение изменилось, схема выполнила работу, даже если не попала в постоянную документацию.

Сначала вопрос, потом тип диаграммы

Вопрос	Подходящая диаграмма
Кто взаимодействует с системой и зачем?	Use Case
В каком порядке участники обмениваются сообщениями?	Sequence
Из каких крупных частей состоит решение?	Component или Package
Какие состояния проходит объект?	State Machine
Как ветвится процесс или алгоритм?	Activity
Какие сущности и связи важны в домене?	Class или близкая доменная модель
На каких узлах и в каких средах исполняются артефакты?	Deployment

Не каждый вопрос требует формального UML. Для контекста системы команда может выбрать C4, для процесса — BPMN, для данных — ER-модель, для интерфейса — OpenAPI, для быстрого обсуждения — обычный эскиз.

Нотация полезна, когда она понятна основной аудитории и сохраняет важный смысл. Формально верная схема, которую никто не умеет читать, коммуникационную задачу не решает.

Где UML обычно окупается

Нетривиальное взаимодействие. Sequence-диаграмма помогает разобрать повтор, таймаут, асинхронный ответ и несколько участников без длинного текстового пересказа.

Жизненный цикл. State Machine полезна, когда переход разрешён не из каждого состояния или от статуса зависят права и действия.

Граница ответственности. Component-диаграмма показывает, какой блок владеет данными или правилом и где проходит контракт между командами.

Передача и онбординг. Небольшой набор актуальных схем сокращает время на сбор общей картины из кода, документов и устных объяснений.

Обсуждение вариантов. Черновая модель позволяет сравнить решения до того, как стоимость изменения вырастет.

Где модель становится обузой

Попытка описать всю систему на одном уровне детализации почти всегда создаёт больше поддержки, чем пользы. Часто меняющиеся внутренние классы устареют быстрее, чем устойчивые контракты и границы компонентов.

Ещё один риск — рисовать после принятого решения только ради обязательного артефакта. Такая диаграмма подтверждает документ, но не помогает думать и первой теряет актуальность.

UML может быть лишним, если:

• вопрос проще объяснить текстом или таблицей;
• схема дублирует автоматически создаваемую документацию;
• аудитория использует другую устойчивую нотацию;
• никто не отвечает за обновление;
• изменение диаграммы не влияет ни на решение, ни на поддержку.

Как определить необходимую глубину

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

1. Какое решение должна поддержать схема?
2. Кто её прочитает?
3. Какая деталь действительно влияет на решение?
4. Сколько времени схема должна оставаться актуальной?
5. Кто обновит её при изменении системы?

Для встречи может хватить черновика. Для контракта между командами нужны согласованные термины и версия. Для эксплуатационной документации важны связь с реальным контуром и понятный владелец.

Хранение рядом с изменением

Диаграмму проще поддерживать, когда она находится рядом с кодом или документом, который меняется вместе с ней. Текстовые форматы вроде PlantUML или Mermaid удобны для review и истории версий, но это не обязательный выбор: визуальный редактор лучше, если им действительно пользуется команда.

Главное — проверять актуальность в том же процессе, где меняется решение. Отдельный ежегодный «аудит схем» редко успевает за разработкой.

UML не является серебряной пулей и не должен быть экзаменом на профессионализм аналитика. Это один из способов сократить неоднозначность. Рисовать стоит ту часть системы, где общее визуальное представление уменьшает риск решения сильнее, чем стоит его создание и поддержка.

PlantUML и Mermaid — инструменты текстового описания диаграмм, а не сама спецификация UML; поддерживаемые обозначения и их смысл нужно проверять. В deployment-модели узлом может быть и устройство, и среда исполнения. Владение данными или SLO добавляют явными подписями и соглашениями команды: тип диаграммы сам их не устанавливает.

Нотация и её семантика определены в спецификации UML от OMG.

Одна заявка, два разных вопроса

Учебная задача: пользователь отправляет заявку, а сотрудник принимает её в работу. Для вопроса «какие переходы разрешены?» полезнее модель состояний:

Состояние	Допустимое действие	Следующее состояние
Черновик	Отправить после проверки обязательных полей	Отправлена
Отправлена	Взять в работу уполномоченным сотрудником	В работе
В работе	Зафиксировать результат	Завершена
Завершена	Прочитать результат	Завершена

Таблица уже выявляет вопросы к state machine: можно ли отменить заявку, вернуть на уточнение или открыть заново? Это надо согласовать, а не придумать при рисовании.

Для вопроса «что произойдёт, если ответ сервера потерялся?» состояния недостаточно. Нужен разбор последовательности: клиент отправил запрос, сервер сохранил заявку, ответ не дошёл, клиент повторил запрос с тем же ключом. Sequence-диаграмма должна показать повтор и границу фиксации, а не только стрелку счастливого пути.

Обе модели относятся к одной функции, но отвечают на разные вопросы. Поэтому я выбираю диаграмму после формулировки проблемы. Если небольшой таблицы достаточно для решения, формальный рисунок можно не добавлять.

---

Впервые опубликовано в моём Telegram-канале @it_underside.

Ваш ДПУПП