Что такое язык UML
Вот мы начинаем строить дом. Нанимаем крепких работяг и начинаем объяснять, что хотим получить. А те говорят, что на слух непонятно. Записываем на бумаге — выходит 100 с лишним страниц. Прорабы ничего не понимают и читать столько не хотят. Тогда рисуем им схему дома — и дело пошло.
Язык UML и UML-диаграммы применяются там, где вместо тысячи слов лучше сработает одно схематичное изображение. Хотя и это изображение создаётся по определённым правилам.
UML (Unified Modeling Language) — это унифицированный язык моделирования в бизнес-среде и рабочих процессах. Он помогает визуализировать сложные понятия, многосоставные системы, изображать их в виде понятных схем. По схемам участники команды — продакты, аналитики, программисты — говорят… вернее, видят на одном языке и понимают друг друга без погружения в код.
UML вообще не привязан к языкам программирования. Команда может кодить на Java, Python, C# — всё равно. Более того, ни языка программирования, ни программирования вовсе может не быть. Поэтому UML используют в разных сферах — не только в разработке.
Скажем, в бизнесе с помощью таких схем можно изобразить процессы по связанным между собой или зависимыми шагами: согласование договора, обработка жалобы клиента, подготовка отчёта и так далее. В производстве — визуализировать последовательность создания продукта. В логистике — этапы движения товаров от склада до клиента.
Вот пример последовательности действий клиента (пользователя) в интернет-магазине:
Что такое UML-диаграмма
Если UML — это язык, то диаграммы — буквы, из которых строятся предложения. Следом они превращаются в понятный рассказ.
Представь, что нужно объяснить, как работает интернет-магазин.
➡️ Клиент выбирает товар, кладёт в корзину, оплачивает, заказ отправляется на склад, затем курьер доставляет покупку.
Это понятно, но не хватает деталей. Что происходит после оплаты? Как магазин узнает, что товар есть в наличии? Какие данные и как передаются между системами?
Вот тут и помогает UML-диаграмма. Она выглядит как блок-схема или чертёж — зависит от задачи. Диаграмма состоит из разных элементов: прямоугольников, кружков, линий и стрелок. У каждого элемента своё значение.
Правила UML-языка и составления диаграмм описывают нотация.
Нотация UML
Это набор стандартных символов и правил для UML-диаграмм. Что-то типа азбуки, где вместо слов и букв — фигуры, линии, стрелки.
В нотации есть четыре категории элементов:
| Категория | Что означает | Примеры диаграмм, в которых используется (это станет ясно после прочтения раздела «Виды UML-диаграмм») |
|---|---|---|
| Структурные | Объект | Диаграмма классов, компонентов, развёртывания |
| Поведенческие | Как ведёт себя система | Диаграмма активности, состояний, прецедентов |
| Взаимодействия | Как взаимодействуют части системы | Диаграммы последовательностей, коммуникаций |
| Архитектурные | Как устроена система на уровне блоков | Диаграмма компонентов, пакетов |
А вот они на схеме:
Но это всё ещё довольно трудно понять для непосвящённого человека. Вот объяснение попроще.
Условно все элементы можно поделить на три большие группы:
🔹Графические элементы — то, из чего строят диаграммы: прямоугольники, овалы
🔄 Связи — это разные типы линий, которые показывают, как графические элементы относятся друг к другу
🔠 Специальные обозначения. Это технические метки для уточнения деталей
Один и тот же визуальный элемент может обозначать разные вещи в разных типах диаграмм.
В статье разбираем только часто используемые символы.
Подробнее о них дальше и с картинками.
Ещё больше интересных статей по теме:
Класс
Это типовой объект или набор объектов с общими характеристиками и поведением. Это что-то типа шаблона для обозначения главного объекта. Если у нас онлайн-магазин, то класс = заказ. Если онлайн-школа, класс = студент.
На схеме это прямоугольник из трёх частей. В верхней написано имя класса — его название. Ниже свойства — все переменные характеристики, например, ID. И ещё ниже доступные действия — методы, которые выполняет объект-класс. Заказ может создаваться и выполняться, студент — записываться и сдавать задания.
Объект
Это уже конкретный экземпляр класса. Типовой объект приобретает имя. Выглядит так же, как класс, но имя подчёркнуто. И вместо пустых значений-заглушек — конкретные свойства.
Интерфейс
Список действий, которые может делать объект. Чтобы понять, что это такое, представь себе, скажем, монитор, на котором написано: «Нажми вот эту кнопку, чтобы я включился, а вот этот кабель вставь в девайс». Ему всё равно, подключишь ли другой компьютер, системный блок или плейстейшен — важно, как именно подключишь.
В нотации к UML-диаграмме есть пометка «Интерфейс», а дальше список действий, которые может делать объект. На диаграмме к нему идёт пунктирная стрелка.
Компонент
Крупная функциональная часть системы, логический элемент, который показывает, что делает система. Если у нас сервис или приложение для доставки, то будет несколько компонентов: библиотека, каталог.
Изображается прямоугольником с двумя маленькими прямоугольниками на одной из граней либо помечается словом << component >>. С другими элементами соединяется непрерывной линией с кружком на конце.
Узел
Ещё более крупный элемент, объединяющий в себе компоненты. Если компонент отвечает за то, что делает система, то узел показывает, где она это делает. Чаще всего под узлами понимают оборудование и инфраструктуру: например, серверы или базы данных. Обычно изображают в виде куба.
Юзкейс
Конкретное применение, варианты использования, которые могут быть совершены. Сделать заказ, оплатить, войти в личный кабинет и та-а-ак далее. Их множество. Важная часть нотации, выходит. Изображается овалом.
Актор
Действующее лицо, которое как бы рядом с нашей системой. Если у нас онлайн-магазин, объект там — заказ, то в происходящем спектакле может фигурировать ещё и внешние акторы — курьеры, покупатель. Вот он, актор, и рисуется в виде человечка рядом с овалом юзкейса.
Почему он не включается как класс или объект? Потому что мы обрисовываем то, как действует и работает система, а люди в ней актёры.
Пакет
Это способ группировки элементов в логические блоки. Может включать и объекты, и классы, и компоненты, и узлы. Пакет можно вкладывать друг в друга — получится совсем как дома под раковиной. Выглядит как прямоугольник с названием, внутри группируются элементы.
Заметка
Поясняющая «записка», прямоугольник с загнутым краем, как у стикера или страницы книги, на которой остановился читатель.
Ты ещё на связи? Тогда скажем вот что — нотация штука объёмная, в ней есть и другие виды квадратов, овалов и пакетов с пакетами. Но бывают и виды связей. Их частично коснулись выше. Это всевозможные стрелки. Вот только некоторые из них.
Ассоциация или связь
Простая связь между объектами — обычная линия.
Наследование
Линия со стрелкой. Показывает, что один объект наследует свойства другого. Например, класс «Курьер» — частный случай класса «Сотрудник»
Зависимость
Пунктирная линия со стрелкой. Показывает, что один объект зависит от другого. Например, фронтенд не может работать без серверной части.
Остальные смотри на схеме.
Если мы зашли настолько далеко, то поздравляем — ты теперь знаешь азы правил построения UML-диаграмм и нотацию на уровне А2. Хочешь пойти дальше — есть спецификация UML. Знать её — равно выучить язык на уровень В2 и выше.
Пойдём дальше.
Виды UML-диаграмм
Есть два типа: структурные и поведенческие. Каждый включает в себя несколько конкретных вариантов.
| Структурные Показывают, как устроена система | Поведенческие Показывают, как работает система |
|---|---|
| Диаграмма классов Диаграмма объектов Диаграмма компонентов Диаграмма композитной структуры Диаграмма развёртывания Диаграмма пакетов | Диаграмма деятельности Диаграмма прецедентов Диаграмма состояний Диаграмма последовательности Диаграмма коммуникации Диаграмма образа действия Диаграмма синхронизации |
По чуть-чуть про каждую👇🏻
Структурные
Они как чертёж здания, помогают понять, из каких частей состоит система и как они связаны. Помогают спроектировать архитектуру или разобраться в уже готовом решении.
Диаграмма классов
Наиболее популярная. Она указывает на основные кирпичики системы — классы, их свойства и связи между ними. Например, при проектировании кода или в бизнесе.
В приложении доставки цветов могут быть такие классы:
- Пользователь (оформляет заказы, оставляет отзывы)
- Заказ (содержит товары, информацию о доставке и статусе)
- Букет (содержит описание, цену, список цветов)
- Курьер (доставляет заказы)
Связи между ними:
- Один пользователь может оформить несколько заказов.
- Один заказ содержит несколько букетов
- Один курьер может доставлять несколько заказов.
Диаграмма объектов
Похожа на предыдущую, но показывает конкретные объекты. Применяют, когда нужно увидеть состояние системы в конкретный момент времени.
Если на диаграмме классов был абстрактный класс «Заказ», то здесь появятся детали.
- Заказ — это пока ещё класс. Заказ №456 (статус: «В пути», адрес: ул. Ленина, 10) — уже объект
- Курьер — класс. Курьер Сергей Иванов (id: 5, телефон: +7 900 123-45-67) — уже объект
Диаграмма компонентов
Показывает, как взаимодействуют модули. Её применяют при проектировании программного обеспечения, чтобы понять, как связаны части приложения.
Вот такие компоненты у мобильного приложения:
- Серверный API
- База данных
- Система оплаты
- Связи
- Мобильное приложение отправляет запросы в серверное API
- API взаимодействует с базой данных и системой оплаты
Это очень упрощённо, чтобы была ясна суть 🔍
Диаграмма развёртывания
Объясняет, на каких серверах и устройствах развёрнута система. Применяют при настройке инфраструктуры (серверы, базы данных, облачные сервисы), когда нужно разобраться, где что работает.
➡️ Если у вас веб-приложение, на схеме будет видно, что оно запущено на AWS, данные хранятся в PostgreSQL, а файлы — в S3-хранилище.
Диаграмма пакетов
Позволяет объединять элементы в логические блоки — как те самые пакеты с пакетами под раковиной. Причём каждый из них аккуратно подписан, чтобы было понятно, какие именно пакеты лежат внутри.
Эта разновидность встречается реже, и она полезна в больших проектах, где много модулей. В деле она позволяет упростить понимание структуры кода — когда нужно охватить очень много информации разом.
Вот примеры:
➡️ ERP-систему можно разбить на пакеты: «Продажи», «Склад», «Финансы», «Отчётность».
➡️ Приложение доставки цветов на такие:
- Пользователи (авторизация, профили, заказы)
- Каталог (цветочные композиции, категории, фильтры)
- Заказы (оформление, оплата, доставка)
- Связи между пакетами показывают, как они взаимодействуют.
Диаграмма развёртывания
Подсвечивает, где физически работают разные части системы. Используют при настройке серверов, баз данных, облачных сервисов. Например:
➡️ Мобильное приложение установлено на телефоне пользователя
➡️ Сервер API размещён в облаке (например, на AWS)
➡️ База данных находится на выделенном сервере
➡️ Система оплаты работает через сторонний сервис (например, Stripe)
➡️ Стрелки показывают, какие части системы взаимодействуют друг с другом
Диаграмма композитной структуры
Отражает внутренние части объекта. Условно, «Заказ» из всё того же воображаемого интернет-магазина состоит из:
- Информации о клиенте (имя, телефон, адрес)
- Списка товаров (цветочные композиции, количество)
- Статуса доставки (оформлен, передан курьеру, доставлен)
- Такой подход помогает детально описать сложные объекты.
Диаграмма профилей
Используется для расширения UML и добавления специальных характеристик.
Если приложение поддерживает премиум-аккаунты, можно создать профиль «Премиум-пользователь» с особыми атрибутами (скидками и приоритетным обслуживанием).
Со структурными диаграммами всё, двигаемся дальше 🤸
Поведенческие диаграммы
Объясняют процессы, сценарии и взаимодействия между элементами системы. Ниже — по чуть-чуть для каждой.
Диаграмма прецедентов, или диаграмма юзкейсов
Устанавливает связь тех самых акторов и юзкейсов. Только тут последние уже называются прецедентами. Применяется в бизнес-анализе и помогает зафиксировать функциональные требования под конкретные юзкейсы. А на этапе проектирования даёт понимание, какие виды ролей есть и как они взаимодействуют с системой.
Вот, например, в интернет-магазине есть акторы: Покупатель и Администратор. Прецеденты первого — посмотреть каталог, выбрать товар, добавить в корзину, создать личный кабинет и так далее. Для второго — управлять заказами и каталогом товаров и пользователями.
Диаграмма последовательностей
Показывает пошаговое взаимодействие объектов в конкретном сценарии. Когда нужно разобраться, что за чем идёт. При проектировании API и взаимодействий между сервисами.
Для примера — клиент оформляет заказ, а в системе происходит последовательность действий: 1️⃣ Пользователь нажимает Оплатить 2️⃣ Запрос уходит в платёжную систему 3️⃣ Если платёж успешен, создаётся заказ 4️⃣ Уведомление отправляется пользователю.
Диаграмма активности
Похожа на блок-схему и показывает поток выполнения процесса. В разработке применяется, когда нужно визуализировать алгоритм или бизнес-логику. В бизнесе подходит для описания процессов.
Например, подсвечивает, как работает техподдержка: 1️⃣ Клиент создаёт заявку 2️⃣ Оператор её получает 3️⃣ Если проблема сложная → передаёт на второй уровень 4️⃣ Если решено → заявка закрывается.
Диаграмма состояний
Показывает, как объект меняет состояния в зависимости от действий. Применяется разработке интерфейсов и сложных алгоритмов. В бизнесе: для визуализации процессов, зависящих от условий. Хорошо подходит для интерфейсов, заказов, заявок, документов
Вот, например, так меняется состояние заказа в интернет-магазине:
🟡 Создан → 🟢 Оплачен → 🔵 Отправлен → 🔴 Доставлен.
Как создать UML-диаграмму
Убедись, что это необходимо
Составить схему непросто. Как минимум потому что это не интуитивно понятный инструмент, а целый язык со своими символами. Не трать время на то, чтобы разобраться с ними, если результат не принесёт пользу.
| ✅ Когда использовать UML-диаграмму | ❌ Когда UML-диаграмма не нужна |
|---|---|
| Когда в проекте участвуют разные специалисты. Разработчики, аналитики и заказчики смотрят на одну картинку и понимают друг друга без перевода. При проектировании сложных систем, чтобы продумать архитектуру до написания кода. В документации. Если ключевые разработчики уволятся, новые быстрее вникнут в проект. Если хочешь масштабировать проект. Визуализация поможет оценить, как изменения повлияют на систему в общем. Когда много подробностей и сложно объяснить процесс текстом. | Когда система очень простая. Бессмысленно делать схему для лендинга с одной формой. Когда команда и без того понимает, как все устроено. Когда проще объяснить словами. Зачем усложнять, если достаточно двух предложений. |
Выбери нужную диаграмму
Если без неё не обойтись, уточни цели. От того, что именно хочешь изобразить, зависит дальнейшая работа.
- Показать структуру — диаграмма классов, компонентов или развёртывания
- Отобразить процесс — диаграмма активности или последовательностей
- Зафиксировать роли пользователей — диаграмма прецедентов
Как видишь, UML-диаграммы разнообразны, и это даёт гибкость. Поэтому не надо использовать все разом, достаточно выбрать те, что действительно упростят понимание и покажут главное.
Определи основные элементы
Вот такие, к примеру, есть у диаграмм классов:
- Классы — представляют объекты (Пользователь, Заказ)
- Атрибуты — описывают характеристики (Имя, Дата заказа)
- Методы — определяют, что объект может делать (Оформить Заказ)
- Связи — показывают отношения между классами (Пользователь делает Заказ)
Определение ключевых элементов поможет быстрее выбрать шаблон под неё либо сориентироваться внутри программы. Но для этого придётся изучить их через нотацию — хотя бы базово.
Выбери инструмент для построения диаграммы
Создать UML-диаграмму можно от руки, но это подходит для быстрых набросков и случаев, когда точно знаешь алгоритм. И рисунок не покажешь, не отправишь коллеге, не сохранишь в проектной документации. Так что для совместной работы лучше использовать специальные программы — тем более они сделают половину за тебя.
Вот только три программы для построения UML-диаграммы, которые понравились лично нам.
🔹Draw.io, сразу открывает приложение app.diagrams.net. Бесплатный и исключительно простой. Работает в браузере, сразу предлагает сохранить результат в облаке или на устройство. Программа предложит тебе сразу выбрать диаграмму по типу и даст драфт. Внутри можно выбирать фигуры и стрелки, даже менять стиль, цвета. Исключительно удобный инструмент — примеры мы тоже сделали там.
🔹StarUML. А это уже для разработчиков. Он сложнее и более придвинутый в возможностях. Приложение устанавливается на компьютер — есть для MaciOS и Windows. Платный — с разовой оплатой за одного юзера. Стабильно обновляется.
🔹 Lucidchart. Без специализации на UML-диаграммах, просто для визуализации. Удобная и красивая онлайн-доска с множеством шаблонов. Сразу предлагает решение в зависимости от способностей юзера и даже его роли. Если на коротком онбординге указать свою роль и уровень владения программой, она выдаст тебе пример, который может пригодиться для твоей роли. Огромный выбор форм, фигур, стрелок, стикеров для заметок. Подходит для совместной работы.
Наше предложение такое. Если ты новичок – попробуй draw.io или Lucidchart. Если работаешь с кодом – StarUML.
Дальше остаётся подготовить диаграмму, проверить, чтобы всё было логично, и улучшать по мере совместной работы.
Подписаться 
