Урок 04.01: Обзор языка UML (Unified Modeling Language)
Цель урока
Познакомиться с языком моделирования UML: понять его историю, назначение и место в работе системного аналитика. Научиться различать структурные и поведенческие диаграммы, выбрать топ-5 диаграмм для ежедневной работы и освоить инструменты для их создания — от визуальных редакторов до подхода «Diagram as Code» через PlantUML.
Ключевые понятия
- UML (Unified Modeling Language) — унифицированный язык графического моделирования для описания, визуализации и документирования программных систем
- Модель (Model) — упрощённое представление реальной системы, которое помогает понять её структуру и поведение
- Structural Diagrams (Структурные диаграммы) — показывают статическую структуру системы: классы, компоненты, объекты, развёртывание
- Behavioral Diagrams (Поведенческие диаграммы) — показывают динамическое поведение системы: взаимодействие объектов, потоки событий, состояния
- PlantUML — инструмент «Diagram as Code»: диаграммы описываются текстовым кодом и компилируются в изображение
- OMG (Object Management Group) — консорциум, поддерживающий стандарт UML
1. История и цель создания UML
1.1. Мир до UML (1980-е — начало 1990-х)
До появления UML каждый методолог и компания использовали свои нотации для моделирования:
| Метод / Нотация | Автор | Специализация |
|---|---|---|
| Booch Method | Grady Booch | Объектно-ориентированное проектирование |
| OMT (Object Modeling Technique) | James Rumbaugh | Моделирование данных и объектов |
| OOSE (Object-Oriented Software Engineering) | Ivar Jacobson | Use Cases |
| Shlaer-Mellor | Sally Shlaer, Steve Mellor | Информационное моделирование |
| SSADM | Правительство Великобритании | Структурный анализ |
Проблема: Методологии были несовместимы. Аналитик, обученный на Booch, не понимал диаграммы OMT. Проектная документация была «слеплена» из разных нотаций и никем не читалась.
1.2. Объединение (1994–1997)
В 1994 году три ведущих методолога — Grady Booch, James Rumbaugh и Ivar Jacobson — объединились в компании Rational Software (теперь часть IBM). Их иногда называют «Три Амиго» (Three Amigos).
Что они сделали:
- Объединили лучшие элементы своих нотаций
- Устранили противоречия между ними
- Создали единый, стандартизованный язык моделирования
В 1997 году OMG (Object Management Group) приняла UML версии 1.0 как стандарт.
1.3. Эволюция версий
| Версия | Год | Ключевые изменения |
|---|---|---|
| UML 1.0 | 1997 | Первый стандарт OMG |
| UML 1.5 | 2003 | Уточнение поведенческих диаграмм |
| UML 2.0 | 2005 | Кардинальное обновление: переработаны диаграммы, улучшена семантика |
| UML 2.5 | 2015 | Упрощение, улучшение читаемости (текущая стабильная) |
| UML 2.5.1 | 2017 | Техническое обновление |
Текущий статус: UML 2.5.1 — стандарт OMG. Язык стабилен и не меняется радикально, так как он уже покрывает 99% потребностей моделирования.
1.4. Цель UML
Основная цель UML — облегчить коммуникацию между участниками проекта.
UML — это язык для общения, а не язык для программирования.
Вы рисуете диаграмму не для того, чтобы компьютер её исполнил, а для того, чтобы коллега (разработчик, заказчик, тестировщик) понял вашу мысль одинаково.
UML решает проблему «вавилонского столпотворения» нотаций: любой ИТ-специалист, знающий UML, прочитает диаграмму, сделанную любым другим специалистом, независимо от компании и страны.
1.5. Что UML НЕ является
| UML — это... | UML — НЕ это... |
|---|---|
| Язык моделирования | Язык программирования |
| Графическая нотация | Методология (как делать) |
| Стандарт OMG | Инструмент (каким ПО рисовать) |
| Набор диаграмм | Процесс разработки |
2. Две группы диаграмм UML
В UML 2.5 входит 14 типов диаграмм, которые делятся на две группы:
UML 2.5 (14 диаграмм)
│
┌─────────────────┴─────────────────┐
│ │
Структурные Поведенческие
(7 диаграмм) (7 диаграмм)
│ │
▼ ▼
┌──────────────────┐ ┌──────────────────┐
│ Class Diagram │ │ Use Case Diagram │
│ Component Diagr. │ │ Activity Diagram │
│ Object Diagram │ │ Sequence Diagr. │
│ Deployment Diagr.│ │ State Machine │
│ Package Diagram │ │ Communication │
│ Composite Struct │ │ Timing │
│ Profile Diagram │ │ Interaction │
└──────────────────┘ └──────────────────┘
2.1. Структурные (Structural) диаграммы
Назначение: Показывают статическую структуру — какие элементы есть в системе, как они связаны, как они организованы в пространстве.
| Диаграмма | Что показывает | Использование аналитиком |
|---|---|---|
| Class Diagram | Классы, их атрибуты, методы и связи между ними | Часто. Проектирование модели данных |
| Component Diagram | Компоненты системы и их интерфейсы | Средне. Архитектурные решения |
| Object Diagram | Конкретные экземпляры классов в определённый момент | Редко. Примеры состояния системы |
| Deployment Diagram | Физическое размещение компонентов на узлах | Редко. Для DevOps / архитектора |
| Package Diagram | Группировка элементов в пакеты | Редко. Для крупных систем |
| Composite Structure | Внутренняя структура класса | Очень редко |
| Profile Diagram | Расширения UML для конкретной области | Очень редко |
2.2. Поведенческие (Behavioral) диаграммы
Назначение: Показывают динамическое поведение — как элементы взаимодействуют, как меняются состояния, какие процессы протекают во времени.
| Диаграмма | Что показывает | Использование аналитиком |
|---|---|---|
| Use Case Diagram | Функциональность системы с точки зрения пользователя | Очень часто. Сбор и визуализация требований |
| Activity Diagram | Поток работ: последовательность действий, ветвления, параллелизм | Очень часто. Моделирование бизнес-процессов (как BPMN, но упрощённо) |
| Sequence Diagram | Взаимодействие объектов во времени: кто кому что посылает | Часто. Сценарии API-вызовов, workflow |
| State Machine Diagram | Состояния объекта и переходы между ними | Средне. Объекты со сложными статусами (Заказ, Документ) |
| Communication Diagram | Взаимодействие объектов (фокус на связях, а не на времени) | Редко |
| Timing Diagram | Изменение состояния объекта во времени | Очень редко |
| Interaction Overview | Агрегация последовательностей и активностей | Очень редко |
3. Топ-5 диаграмм UML для системного аналитика
На практике аналитик использует 5 из 14 типов диаграмм — остальные либо слишком редки, либо относятся к архитектуре/дизайну.
3.1. Use Case Diagram (Диаграмма вариантов использования)
Когда использовать: На старте проекта, чтобы показать, кто пользуется системой и какие функции доступны.
Что показывает:
- Актёров (роли — люди или внешние системы)
- Варианты использования (овалы — функции системы)
- Границы системы (прямоугольник)
- Связи: «актёр → use case» (включение, расширение, обобщение)
Пример (текстовое описание):
Прямоугольник «Интернет-магазин». Внутри: «Просмотреть каталог», «Добавить в корзину», «Оформить заказ», «Оплатить». Слева актёр «Посетитель» связан с «Просмотреть каталог». Справа актёр «Клиент» связан с «Оформить заказ» и «Оплатить».
Почему нужен аналитику: Быстро показать заказчику границы системы — обсудить, что входит в проект.
3.2. Activity Diagram (Диаграмма активности)
Когда использовать: Когда нужно описать процесс (AS-IS или TO-BE) с ветвлениями, параллельными потоками и ролями.
Что показывает:
- Действия (скруглённые прямоугольники)
- Ветвления (ромбы — условные переходы)
- Начало и конец процесса (кружки)
- Дорожки (swimlanes) — кто за что отвечает
- Параллельные потоки (fork / join)
Почему нужен аналитику: Activity Diagram — самый простой способ показать бизнес-процесс людям, не знакомым с BPMN. Она интуитивно понятна.
3.3. Sequence Diagram (Диаграмма последовательности)
Когда использовать: Когда нужно детально описать сценарий взаимодействия между объектами/компонентами во времени.
Что показывает:
- Объекты/компоненты (прямоугольники в верхней части)
- Линии жизни (пунктирные линии вниз от объектов)
- Сообщения (стрелки между линиями жизни — вызовы методов, API-запросы)
- Ответы (пунктирные стрелки назад)
- Фрагменты (alt — альтернативы, opt — опции, loop — циклы)
- Активации (узкие прямоугольники на линии жизни — время работы)
Почему нужен аналитику: Sequence Diagram незаменим для описания точных сценариев: «какой API вызывается, в каком порядке, что возвращается». Разработчики и QA любят Sequence Diagrams за однозначность.
3.4. Class Diagram (Диаграмма классов)
Когда использовать: Когда нужно спроектировать модель данных — сущности, их атрибуты и связи.
Что показывает:
- Классы (прямоугольники с тремя секциями: имя класса, атрибуты, методы)
- Связи между классами (ассоциация, агрегация, композиция, наследование)
- Кратность связей (1, 0.., 1..)
Почему нужен аналитику: Class Diagram — основа для проектирования БД (каждая сущность → таблица, атрибуты → колонки, связи → foreign keys).
3.5. State Machine Diagram (Диаграмма состояний)
Когда использовать: Когда объект системы имеет сложную логику статусов (заказ, документ, задача).
Что показывает:
- Состояния (скруглённые прямоугольники)
- Переходы (стрелки с надписью события)
- Начальное и конечное состояния
- Guard-условия (when, if)
- Вложенные состояния (substates)
Почему нужен аналитику: Помогает найти «потерянные» переходы. Например: «Что происходит с заказом, если оплата не прошла, но товар уже отгружен?» — State Machine заставит вас явно указать все возможные переходы.
4. Инструменты для создания UML-диаграмм
4.1. Сравнительная таблица
| Инструмент | Тип | Бесплатно? | Совместная работа | Экспорт | Лучше всего для |
|---|---|---|---|---|---|
| Draw.io (diagrams.net) | Визуальный редактор | ✅ Да | ✅ (Google Drive, Confluence) | PNG, SVG, PDF | Быстрые диаграммы, интеграция с Confluence |
| Miro | Онлайн-доска | 🟡 Freemium | ✅ Отлично | PNG, PDF | Воркшопы, brainstroming, команда |
| Visual Paradigm | Полноценное CASE-средство | 🟡 Freemium (Community) | ✅ | Множество | Полный цикл: от модели до кода |
| PlantUML | Diagram as Code | ✅ Open Source | ✅ (через Git) | PNG, SVG, PUML | Разработчики, Git-репозитории, автоматизация |
| Lucidchart | Визуальный редактор | 🟡 Freemium | ✅ | Множество | Альтернатива Draw.io |
| StarUML | Настольное приложение | 🟡 Freemium | ❌ | Множество | Если нужен классический UML-редактор |
| Creately | Онлайн-редактор | 🟡 Freemium | ✅ | Множество | Шаблоны для начинающих |
4.2. Draw.io (diagrams.net) — выбор для быстрых диаграмм
Почему это стандарт де-факто:
- Бесплатный и с открытым исходным кодом
- Интеграция с Confluence, Google Drive, VS Code
- Полная поддержка UML-нотации (вся палитра)
- Не требует установки (работает в браузере)
Как начать: Открыть app.diagrams.net → создать диаграмму → выбрать шаблон или чистый лист → перетаскивать элементы из панели слева.
Лучшее для: Быстрых диаграмм для документации, когда нужно «нарисовать и вставить в Confluence».
4.3. Miro — выбор для воркшопов
Почему: Miro — это не столько редактор UML, сколько онлайн-доска. Аналитики используют Miro для:
- Воркшопов по моделированию процессов (вся команда рисует одновременно)
- User Story Mapping
- Построения карт стейкхолдеров, Customer Journey Map
Особенность: В Miro нет встроенной UML-палитры (но есть framebox с фигурами UML). Зато есть неограниченная доска, стикеры, комментарии, таймер, голосование.
Лучшее для: Групповой работы, когда нужно собирать, обсуждать и быстро фиксировать диаграммы.
4.4. Visual Paradigm — выбор для полного цикла
Почему: Полноценное CASE-средство (Computer-Aided Software Engineering):
- Генерация кода из диаграмм (Java, C#, Python)
- Обратный инжиниринг (код → диаграмма)
- Поддержка BPMN, ERD, ArchiMate (не только UML)
- Версионирование моделей
Недостаток: Бесплатная Community Edition урезана. Полная версия дорогая ($~1000/год).
Лучшее для: Крупных проектов, где диаграммы — не просто картинки, а источник кода.
4.5. PlantUML — Diagram as Code
Что это: Вы пишете текстовое описание диаграммы на языке PlantUML, а инструмент (CLI, плагин, веб-сервер) превращает его в изображение.
Пример PlantUML (Sequence Diagram):
@startuml
actor "Клиент" as customer
participant "Мобильное приложение" as app
participant "Сервис заказов" as order
database "PostgreSQL" as db
customer -> app: Нажать "Оформить заказ"
app -> order: POST /api/v1/orders
order -> db: INSERT INTO orders
db --> order: order_id
order --> app: 201 Created {order_id: 123}
app --> customer: Показать "Заказ оформлен"
@enduml
Результат: Сгенерированная диаграмма последовательности (стрелки, объекты, активации).
Преимущества:
- Версионирование через Git — диаграмма хранится как текст, видна разница между версиями
- Интеграция с CI/CD — диаграммы генерируются автоматически при сборке
- Стандартизация — все диаграммы выглядят одинаково (нет «красивого» и «уродливого» оформления)
- Командная работа — не нужно редактировать .vsdx-файлы, правим текст
Где писать:
- VS Code (плагин PlantUML) — предпросмотр в реальном времени
- PlantUML Web Server (plantuml.com) — онлайн-песочница
- Confluence (плагин PlantUML для Confluence)
Недостаток: Крутая кривая обучения для сложных диаграмм. Не подходит для Ad-hoc, «нарисовать на коленке».
4.6. Когда что выбирать — матрица
| Ситуация | Инструмент |
|---|---|
| «Надо быстро набросать идею и отправить заказчику» | Draw.io — 5 минут, готово |
| «Воркшоп с командой из 8 человек» | Miro — все видят, все правят |
| «Диаграммы — часть документации, нужно версионирование» | PlantUML — в Git |
| «Нужно сгенерировать код из UML» | Visual Paradigm или Enterprise Architect |
| «Хочу рисовать красиво, но бесплатно» | Draw.io |
| «Коллеги используют Confluence, хочу вставлять диаграммы» | Draw.io для Confluence или PlantUML для Confluence |
5. UML и Agile: диаграммы или код?
В Agile-сообществах иногда можно услышать: «UML — это пережиток Waterfall, мы не рисуем, мы пишем код».
Ответ аналитика: Диаграммы UML — это не бюрократия, а инструмент мышления и коммуникации.
| Миф | Реальность |
|---|---|
| «UML — это Waterfall, сначала всё моделируем, потом кодим» | UML можно использовать точно в срок (just-in-time): нарисовали диаграмму на 5 минут перед спринтом, чтобы синхронизировать команду |
| «Диаграммы устаревают сразу после создания» | Если использовать PlantUML — диаграммы живут в Git и обновляются вместе с кодом |
| «Лучше написать тест, чем рисовать диаграмму» | Они не исключают друг друга: Sequence Diagram помогает написать правильный тест |
| «UML сложный, никто его не знает» | 5 диаграмм — это базовый уровень. Use Case и Activity понимают даже заказчики без ИТ-опыта |
Правильный подход («UML Light»):
- Не рисовать все 14 диаграмм
- Рисовать только там, где это добавляет ясность
- Использовать PlantUML, чтобы диаграммы были частью кодовой базы
- Помнить: цель — коммуникация, а не документ
6. Аналогия для запоминания: «Чертежи vs Фотографии»
UML — это как архитектурный чертёж дома.
- Use Case Diagram: План участка — видно, где дом, где гараж, где забор (границы системы).
- Activity Diagram: Схема водопровода — понятно, как вода течёт по трубам (процесс).
- Sequence Diagram: Инструкция сборки IKEA — шаг за шагом, кто за чем (взаимодействие компонентов).
- Class Diagram: Чертеж фундамента — все балки и колонны (модель данных).
- State Machine Diagram: Схема работы замка: открыт → поворот ключа → закрыт (статусы объекта).
Альтернатива без UML: Вы фотографируете дом снаружи и говорите «ну, вот такой дом». Разработчик может догадаться, как он построен, но может и ошибиться.
Вопросы для самопроверки
- Какой год считается годом рождения UML? Какая организация поддерживает стандарт?
- Кто такие «Три Амиго» и что они сделали для UML?
- Назовите две группы диаграмм UML. Сколько всего диаграмм в UML 2.5?
- Какие 5 диаграмм UML наиболее важны для аналитика? Почему?
- В чём разница между Draw.io и PlantUML? В каких ситуациях предпочтителен каждый?
- Какое преимущество даёт подход «Diagram as Code» (PlantUML) по сравнению с визуальным редактором?
- Нужен ли UML в Agile-проектах? Аргументируйте.
Практическое задание
Кейс: Вам нужно смоделировать фрагмент системы «Запись пациента к врачу» (из Модуля 3). У вас есть следующее описание процесса:
Пациент открывает личный кабинет и входит в него. Он выбирает специальность врача (терапевт, хирург, окулист), затем выбирает конкретного врача из списка доступных. Система показывает свободные слоты на ближайшие 7 дней. Пациент выбирает дату и время и подтверждает запись. Система проверяет, что слот ещё свободен, резервирует его и отправляет пациенту подтверждение на email.
Задание 1. Выбор диаграммы и инструмента
Определите, какая из топ-5 диаграмм UML лучше всего подходит для визуализации этого сценария. Обоснуйте (2–3 предложения).
Задание 2. PlantUML-код Sequence Diagram
Напишите PlantUML-код для Sequence Diagram, описывающей сценарий «Успешная запись пациента к врачу».
Объекты (участники):
- Пациент (actor)
- Личный кабинет (Frontend)
- Сервис записи (Appointment Service)
- База данных (Database)
- Сервис уведомлений (Notification Service)
Что должно быть отражено в диаграмме:
- Пациент выбирает специальность
- Frontend запрашивает список врачей по специальности
- Сервис записи возвращает актуальное расписание
- Пациент выбирает врача, дату и время
- Frontend отправляет запрос на бронирование
- Сервис записи проверяет доступность (запрос к БД)
- Сервис записи создаёт запись в БД
- Сервис записи отправляет команду на уведомление
- Notification Service отправляет email
- Пациент видит подтверждение
Требования к коду:
- Корректный синтаксис PlantUML (@startuml / @enduml)
- Использовать actor для пациента
- Стрелки:
->(запрос) и-->(ответ) - Активации (activate / deactivate)
- Минимум один фрагмент
alt(проверка: слот свободен)
Задание 3. Сравнительный анализ инструментов
Ответьте на вопросы:
- Если бы вы делали эту диаграмму для презентации заказчику (нетехническому), какой инструмент выбрали бы? Почему?
- Если бы диаграмма хранилась в Git и обновлялась каждую неделю — какой инструмент выбрали бы? Почему?
- Если бы вы проводили воркшоп с 5 стейкхолдерами и дорисовывали процесс в реальном времени — какой инструмент?
Формат: Один файл (md), разделы: Задание 1, Задание 2 (PlantUML в блоке кода), Задание 3.
Дополнительные материалы
- Стандарт: OMG UML 2.5.1 Specification (официальный PDF, ~800 страниц — не читать целиком, использовать как справочник)
- Книга: Martin Fowler — «UML Distilled: A Brief Guide to the Standard Object Modeling Language» (лучшая книга по UML — коротко и по делу)
- Книга: Craig Larman — «Applying UML and Patterns» (продвинутое применение)
- Сайт: PlantUML Guide — plantuml.com/guide (шпаргалка по синтаксису)
- Инструмент: app.diagrams.net — Draw.io
- Шпаргалка: «UML Cheat Sheet» — одностраничная памятка по всем 14 диаграммам
- Статья: «UML for System Analysts: 5 Diagrams You Will Actually Use» — блоги по BA