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