ДИЛАРА ВАЛИТОВА

Основы UML.
Кому и зачем он нужен

Введение
Статья про основы применения UML будет полезна начинающим аналитикам, а также разработчикам, тестировщикам, менеджерам продуктов, архитекторам и техническим писателям, которые хотят начать использовать UML-диаграммы в своей работе или структурировать знания об их применении.

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


Время на чтение статьи: 17 минут
Не любите читать? Посмотрите видео.

Что такое UML

UML (Unified Modeling Language, Унифицированный Язык Моделирования) — язык графического описания для объектного моделирования в области разработки программного обеспечения, который также можно применять для моделирования бизнес-процессов, системного проектирования и отображения организационных структур.

Давайте подробнее разберём аббревиатуру UML:

  • U — Unified (Унифицированный). Большой набор элементов, входящих в нотацию, позволяет покрывать много задач на этапе анализа и проектирования. Ещё одна версия происхождения этого слова кроется в том, что нотация объединила в себе несколько разнородных нотаций, существовавших ранее.

  • M — Modeling (Моделирование). Создание диаграмм заключается в разработке моделей, содержащих наполненные информацией и связанные между собой графические объекты.

  • L — Language (Язык). UML является искусственным языком и обладает свойствами языка: имеет словарь (графические символы), семантику (смысловые значения элементов) и синтаксис (правила построения конструкций). В нотацию также заложена возможность генерации кода из графической модели и генерация моделей из кода.

При этом нотация Unified Modeling Language позволяет моделировать как верхнеуровневые бизнес-процессы, так и низкоуровневые процессы, происходящие внутри информационной системы.

История возникновения UML

UML является далеко не первой нотацией моделирования. Графически описывать системы при проектировании и разработке стали давно. В какой-то момент появилась необходимость в том, чтобы использовать при моделировании единые правила, понятные всем.

В основу нотации легли наработки многих специалистов в области программной инженерии, но наиболее весомый вклад внесли Грейди Буч (Grady Booch), Ивар Якобсон (Ivar Jacobson) и Джеймс Рамбо (James Rumbaugh).

UML вобрала в себя особенности их нотаций моделирования — Booch, OOSE (Object Oriented Software Engineering) и OMT (Object Modeling Technique) соответственно.
История возникновения нотации UML
Рис. 1 — История возникновения нотации UML
Язык постоянно развивается, появляются новые элементы для моделирования более сложных систем. Актуальная сейчас версия нотации — UML 2.5.1; новости и рекомендации можно найти на официальном сайте UML.org.

Классификация UML диаграмм

Нотация известна тем, что в неё входит много различных видов диаграмм:
виды UML диаграмм
Рис. 2 — Классификация диаграмм нотации UML
Структурные диаграммы UML. Описывают систему статически
Диаграммы поведения UML. Описывают систему динамически

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

Применение UML к разным задачам

Почти любые задачи описания и проектирования при разработке можно решить с помощью UML. Примеры таких задач перечислены в таблице.
На графике ниже приведена статистика упоминания различных видов диаграмм (информация взята из мета-анализа встречаемости UML в статьях и исследованиях по ИТ-дисциплинам за 2021 год, числа указывают абсолютное количество публикаций). В рабочей практике статистика применимости похожая.

Статистика частоты разных UML-диаграмм в публикациях
Из приведенной статистики видно, что чаще всего упоминаются:
  • Class Diagram
  • Activity Diagram
  • Sequence Diagram
  • Use Case Diagram

Применение UML разными ролями

Если в поиске на сайте HeadHunter ввести ключевое слово «UML», то получится, что в подавляющем большинстве случаев знание этой нотации нужно системным аналитикам (реже — бизнес-аналитикам). По описаниям вакансий можно также заметить, что знание UML требуется в основном специалистам уровня middle и senior.

Более подробно набор требований к системному аналитику с точки зрения работодателя мы рассматривали в статьях:

Однако, в действительности знание этой нотации пригодится практически всем специалистам всех уровней при разработке ИТ-продуктов. Безусловно, не любой участник команды должен уметь моделировать все возможные структуры (ранее мы уже разобрали, что их довольно много). Обычно достаточно иметь навык разработки и чтения двух-трех видов диаграмм.

Давайте разберемся, кому и какие UML-модели могут пригодиться в работе.

UML для Заказчика

Диаграмма прецедентов (use case diagram) поможет Заказчику понятным языком описать то, что он хочет получить от системы. Другие виды моделей позволяют детализировать эти требования.


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

UML для Аналитика

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

Если вам, как Аналитику, необходимо сформулировать требования к новой системе или новой функциональности в уже существующей, можно действовать в таком порядке:

  1. Описать ролевую модель с помощью диаграммы прецедентов (Use Case Diagram). Диаграмма позволяет спроектировать, какие пользователи будут работать с системой и какие функции будут доступны каждому из них. Можно прямо в рамках интервью с заказчиком делать наброски требуемой функциональности. Замечание: Часто диаграмму use case путают со способом описания требований в формате use case. Не делайте такую ошибку! Эти методы дополняют друг друга, но не стоит считать их взаимозаменяемыми: вы можете проиллюстрировать написанный юскейс диаграммой прецедентов (use case diagram).
  2. Описать перечень объектов, их свойства и методы, а также взаимосвязи с помощью диаграммы классов (Class Diagram).
  3. Описать реализуемые процессы с помощью диаграммы деятельности (Activity Diagram).
  4. Если вы системный аналитик — описать детализированную логику работы системы с помощью с помощью диаграммы последовательности (Sequence Diagram). Этот вид диаграмм удобно читать разработчикам, которые реализуют описанную логику уже в модулях системы или микросервисах.
Перечисленные в списке выше диаграммы наиболее популярны в применении, а также чаще всего упоминаются в вакансиях. Их будет достаточно для изучения начинающим аналитикам. Более специфичные виды диаграмм обычно требуются аналитикам уровней Middle и Senior.

Мы объясняем и даем потренировать основы UML для аналитиков на курсе: вы сможете на практике освоить азы за 2 полных выходных дня или за 4 занятия по полдня.

UML для Архитектора

Архитекторы разрабатывают UML-диаграммы так же часто, как и аналитики, но архитектор чаще описывает техническую сторону системы, в том числе связанную с её эксплуатацией. Например, с помощью диаграммы развертывания можно показать, из каких компонентов состоит система в данный момент.
Простая диаграмма развертывания
Рис. 4 — Простая диаграмма компонентов

UML для Разработчика

Если Аналитик и Архитектор разрабатывают модели, то разработчик чаще является стороной, «принимающей» их. Пожалуй, чаще всего разработчикам приходится сталкиваться с сиквенс диаграммами.
Простая sequence diagram
Рис. 5 — Простая sequence diagram
Кстати, вот удобный и бесплатный онлайн-инструмент для рисования UML sequence: https://www.websequencediagrams.com/

Воркшоп Анны Вичуговой

«UML-диаграммы последовательности для аналитика: ликбез и примеры использования»

одно занятие 2,5 часа


Повторяя за ведущим, вы сможете построить диаграммы, иллюстрирующие поведение интернет-магазина для сценариев:

  • Аутентификация пользователя
  • Добавление товаров менеджером (с аутентификацией)
  • Добавление товара в заказ
  • Покупка товара
  • Асинхронная интеграция нескольких систем через Kafka

UML c позиции Тестировщика

Тестировщик редко самостоятельно разрабатывает диаграммы и чаще использует модули, полученные от аналитика.

UML для Технического писателя

Технический писатель создаёт документацию для информационной системы (отчётная документация по проекту, пользовательские инструкции, руководства, регламенты и т.д.). Поэтому технический писатель должен хорошо знать структуру и логику системы.

Если в доступе имеется графическая информация, описывающая вашу АС или программный продукт, это ускорит работу технического писателя: все созданные в рамках проекта модули и визуализации помогут ознакомиться с реализованной функциональностью.

UML в жизненном цикле проекта

И классические и гибкие подходы следуют определенному цикл работ, который можно представить в так называемой V-модели информационных систем:
Жизненный цикл проекта
Рис. 6 — Жизненный цикл проекта
В левой части цикла находятся этапы начала проекта. На этих этапах в рамках создания концепции, анализа и проектирования происходит создание моделей, описывающих работу системы.

В правой части цикла находятся этапы, на которых спроектированные ранее модели используются: тестирование, передача в опытно-промышленную эксплуатацию.

При этом модели не статичны: они проходят проверку (верификацию и валидацию) на каждом этапе и могут изменяться и дополняться по результатам проверки.

Инструменты моделирования UML

Существует множество инструментов, позволяющих работать в этой нотации. Можно разделить все инструменты на две категории:

1. Инструменты для визуального моделирования с помощью графических элементов.

2. Инструменты, для создания полноценной модели проекта, включая элементы UML.
Главное отличие этих групп в том, что первая позволяет создавать только визуальную модель с помощью графических элементов.

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

Например, если добавить на Class Diagram новый метод, вы можете переиспользовать его на sequence diagram без необходимости создавать второй раз.

Рекомендуемая литература по UML

Для изучения теории рекомендуем прочитать:

  1. Официальная документация UML.
  2. «Введение в UML от создателей языка». Гради Буч, Джеймс Рамбо, Ивар Якобсон.
  3. «UML 2.0. Объектно-ориентированное моделирование и разработка». Джеймс Рамбо, М. Блаха.
  4. «Самоучитель UML 2». Александр Леоненков.
  5. «Проектирование на UML. Сборник задач». Валентин Полежаев, Андрей Андрианов, Антон Хританков.
Резюме
  1. За счёт большого количества элементов нотация UML позволяет решать подавляющее большинство задач моделирования при проектировании информационных систем.
  2. Знание UML полезно абсолютно всем участникам процесса разработки: от заказчика до технического писателя.
  3. Начинающим ИТ-специалистам рекомендуется начать изучение нотации с наиболее популярных видов диаграмм:
  • Диаграмма прецедентов (Use Case Diagram).
  • Диаграмма классов (Class Diagram),
  • Диаграмма деятельности (Activity Diagram).
  • Диаграмма последовательности (Sequence Diagram).
Начать осваивать UML на практике можно на нашем курсе:

Курс Дилары Валитовой

«Основы ООП и разработка UML-моделей»

4 занятия по 4 часа в выходные


  • основы объектно-ориентированного проектирования

  • практика построения всех основных видов UML-диаграмм: диаграммы Use Cases, Sequence, Class Diagram, и др.

  • выбор подходящих UML диаграмм для формализации требований, процессов и структур
Ваш промокод: STARTUML

Ответы на вопросы

Какие задачи на UML встречаются на собеседованиях?

Задачи на умение применять UML диаграммы нередко дают на собеседованиях. Например, могут встретиться такие задания:

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

Читайте полезные советы: Как выполнить тестовое задание на должность системного аналитика.

Правда ли, что UML используют
только в больших компаниях?

Нет, на самом деле UML в ходу и в маленьких компаниях/проектах. Более того, если рассматривать вопрос с точки зрения «большая фича/ маленькая фича», UML-диаграмма может быть нужна при разработке даже небольшой части функциональности. Конечно, чем сложнее фича, тем больше видов моделирования вам будет нужно, тем модели будут объемнее. Разработчику в любом случае будет проще понять, какой результат хочет получить аналитик, по диаграмме, чем по тексту.

Обязательно ли знать программирование
для работы с UML?

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

Так как UML предназначен для объектно-ориентированного моделирования, неплохо знать, что такое ООП (объектно-ориентированный подход): представлять, что такое классы, для чего они предназначены и как могут взаимодействовать. Языки программирования знать не нужно.

На каких практических кейсах
можно потренироваться в UML?

Проще всего начать с диаграммы прецедентов (Use Case Diagram). С её помощью вы можете спроектировать ролевую модель системы. Можно прямо в рамках интервью с заказчиком делать наброски требуемой функциональности: что должна позволять система для конкретного актора.

Далее можно перейти к созданию Class Diagram: описать перечень объектов с их свойствами, взаимосвязями и методами.

Если вы системный аналитик, то следующий шаг — переходить на sequence diagram для описания детализированной логики.

Можно ли моделировать

сложную логику UML в MS Visio?

Приведем пример с одного из наших курсов, на котором студенты выбрали MS Visio в качестве инструмента моделирования. Visio позволил успешно построить диаграммы прецедентов и классов. При построении sequence diagram возникли проблемы по мере усложнения логики. Чем больше в логике появлялось ветвлений, условий, параллельных процессов, тем менее удобно становилось работать с инструментом: плохое масштабирование элементов, наложение их друг на друга и некорректное отображение.

Как быстро освоить Enterprise Architect?

Enterprise Architect — достаточно сложный инструмент, с объёмной инструментальной панелью, но если в нём хорошо разобраться, то он будет очень удобен для работы с UML-диаграммами. Для погружения в работу с инструментом рекомендуем ознакомиться с тьюториалами на сайте вендора.

Зачем нужна диаграмма классов,
если есть ER-диаграмма?

Зависит от контекста, в котором возникла задача. Если вы работаете с проектированием баз данных, создаете наборы таблиц для баз данных, то вам проще использовать ER-диаграммы («сущность-связь», «entity-relationship»).

Диаграмма классов UML больше предназначена для проектирования объектов информационной системы. Ключевое отличие заключается в том, что класс кроме свойств содержит также методы — действия, которые можно совершать над объектами. Метод описывает входные данные, логику работы и результат выполнения на выходе. ERD позволяет спроектировать сущности базы данных (таблицы) со свойствами и отношениями между ними.

Как связаны UML и BPMN?

Можно сказать, что BPMN — ответвление от UML нотации. BPMN создана той же компанией OMG (Object Management Group).
Из сходств нотаций — UML также позволяет описать бизнес-процесс, для этого можно использовать Activity Diagram, содержащую действия, условия ветвлений, начало и окончания процесса.

Различие заключается в том, что BPMN содержит много графических элементов для отображения специфической логики бизнес-процессов: различные виды событий, граничные, прерывающие, таймеры, сообщения и т. д. BPMN также позволяет отобразить более сложные виды условий. Об этом мы говорили в статье, где сравнивали BPMN с другими нотациями моделирования процессов.

Не менее интересным было бы рассмотреть свод знаний в рамках фреймворка BTABoK. Это один из лучших ресурсов для первичного погружения в виды ИТ архитекторов.
Автор
Дилара Валитова

Специалист в бизнес- и системном анализе


  • Ведущий инструктор в Systems.Education
  • Более 5 лет опыта в проектах по обследованию, проектированию, обучению, регламентации процессов, внедрению ECM-систем в качестве аналитика и консультанта
  • Более 5 лет опыта внедрения и сопровождения PLM систем

Больше полезных статей