Открыть сервис

Диаграммы вариантов использования

Диаграмма вариантов использования (англ. use case diagram) — это графическое представление функциональных требований к системе в языке моделирования UML (Unified Modeling Language), показывающее взаимодействие между внешними субъектами (акторами) и системой через набор вариантов использования (прецедентов). Диаграмма описывает, какие действия система может выполнять для достижения целей акторов, не вдаваясь в детали внутренней реализации. Относится к типу диаграмм поведения в UML и служит инструментом для анализа и проектирования на этапе сбора требований.

История и развитие

Диаграммы вариантов использования возникли в рамках методологии объектно-ориентированного анализа и проектирования, разработанной Иваром Якобсоном в конце 1980-х годов. Якобсон ввел понятие «вариант использования» (use case) в своей книге «Object-Oriented Software Engineering: A Use Case Driven Approach» (1992), где описал подход к моделированию требований через сценарии взаимодействия пользователей с системой. В 1997 году диаграммы вариантов использования были включены в первую версию UML 1.0, стандартизированную консорциумом OMG (Object Management Group). В последующих версиях UML (1.4, 2.0, 2.5) диаграммы сохранили базовую нотацию, но были уточнены правила отношений и семантика.

Основные элементы диаграммы

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

Акторы

Актор (actor) — это внешняя сущность (человек, другая система, устройство или внешний процесс), которая взаимодействует с системой для достижения определенной цели. Акторы не являются частью системы, а находятся за ее границами. На диаграмме акторы обозначаются фигуркой человечка (стилизованный значок) или прямоугольником с текстом «actor» и именем. Акторы могут быть:

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

Варианты использования

Вариант использования (use case) — это описание последовательности действий, которые система выполняет в ответ на запрос актора, приводящих к наблюдаемому результату. Каждый вариант использования представляет собой одну функциональную возможность системы. На диаграмме вариант использования обозначается овалом (эллипсом) с именем внутри, обычно в виде глагольной фразы (например, «Оформить заказ», «Войти в систему»).

Отношения

Между элементами диаграммы устанавливаются следующие типы отношений:

  • Ассоциация (association) — линия без стрелок, соединяющая актора с вариантом использования. Показывает, что актор участвует в данном варианте использования. Может быть направленной (стрелка указывает, кто инициирует взаимодействие).
  • Обобщение (generalization) — отношение типа «является разновидностью» между акторами или между вариантами использования. Обозначается стрелкой с пустым треугольником на конце, направленной от специализированного элемента к общему. Например, актор «Администратор» может быть обобщением актора «Пользователь».
  • Включение (include) — отношение, при котором один вариант использования обязательно включает в себя другой. Обозначается пунктирной стрелкой с надписью «<<include>>», направленной от включающего варианта к включаемому. Например, вариант «Оформить заказ» включает «Авторизоваться».
  • Расширение (extend) — отношение, при котором один вариант использования может дополнительно расширять другой в определенных условиях. Обозначается пунктирной стрелкой с надписью «<<extend>>», направленной от расширяющего варианта к расширяемому. Например, «Оплатить картой» расширяет «Оформить заказ» при выборе способа оплаты.

Границы системы

На диаграмме вариантов использования часто изображается граница системы (system boundary) — прямоугольник, внутри которого находятся все варианты использования, а снаружи — акторы. Граница обозначает область ответственности системы и помогает отделить внутреннюю функциональность от внешних сущностей. В UML 2.0 граница может быть опущена, если она не несет дополнительной информации.

Примеры построения

Диаграммы вариантов использования применяются в различных предметных областях. Ниже приведены типовые примеры.

Пример 1: Интернет-магазин

  • Акторы: Покупатель, Администратор, Платежная система.
  • Варианты использования: «Просмотреть каталог», «Добавить товар в корзину», «Оформить заказ», «Оплатить заказ», «Отменить заказ», «Управлять товарами» (для администратора).
  • Отношения: «Оформить заказ» включает «Авторизоваться»; «Оплатить заказ» расширяет «Оформить заказ»; актор «Администратор» является обобщением актора «Пользователь».

Пример 2: Система управления библиотекой

  • Акторы: Читатель, Библиотекарь, Система учета книг (внешняя).
  • Варианты использования: «Зарегистрироваться», «Взять книгу», «Вернуть книгу», «Продлить срок», «Поиск книги», «Управление каталогом» (для библиотекаря).
  • Отношения: «Взять книгу» включает «Проверить наличие»; «Вернуть книгу» включает «Обновить статус»; актор «Библиотекарь» может выполнять все варианты читателя, но с дополнительными правами.

Применение в разработке

Диаграммы вариантов использования используются на ранних этапах разработки программного обеспечения для:

  • Сбора и анализа требований — выявление функциональных возможностей системы с точки зрения пользователей.
  • Коммуникации с заказчиком — наглядное представление, понятное неспециалистам.
  • Планирования итераций — определение приоритетных вариантов использования для реализации.
  • Тестирования — создание тестовых сценариев на основе вариантов использования.

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

Критика и ограничения

Несмотря на широкое распространение, диаграммы вариантов использования подвергаются критике за:

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

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

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

Диаграммы вариантов использования создаются с помощью различных инструментов моделирования, включая:

  • Rational Rose (IBM) — коммерческое средство, одно из первых для UML.
  • Enterprise Architect (Sparx Systems) — коммерческий инструмент с поддержкой UML 2.5.
  • Visual Paradigm — коммерческий и бесплатный (Community Edition) инструмент.
  • Draw.io (diagrams.net) — бесплатный онлайн-редактор с поддержкой UML.
  • PlantUML — текстовый язык для генерации диаграмм, интегрируемый с системами контроля версий.

Связанные понятия

  • UML — унифицированный язык моделирования, включающий 14 типов диаграмм.
  • Диаграмма деятельности — моделирует потоки управления и последовательности действий.
  • Диаграмма последовательности — показывает взаимодействие объектов во времени.
  • Сценарий использования — текстовое описание шагов варианта использования.

Источники

  • Якобсон И., Буч Г., Рамбо Дж. «Унифицированный процесс разработки программного обеспечения». — СПб.: Питер, 2002.
  • Фаулер М. «UML. Основы». — СПб.: Символ-Плюс, 2004.
  • OMG Unified Modeling Language (OMG UML), Version 2.5.1 — Object Management Group, 2017.
  • Ларман К. «Применение UML и шаблонов проектирования». — М.: Вильямс, 2002.

BFOmetr — база данных и аналитика по компаниям России.

На главную BFOmetr →