Диаграмма вариантов использования в UML¶
Диаграмма вариантов использования (англ. use case diagram) — один из видов диаграмм унифицированного языка моделирования (UML), предназначенный для описания функциональных требований к системе с точки зрения внешних пользователей. Диаграмма показывает, какие действия доступны действующим лицам (акторам) и как эти действия связаны между собой, не раскрывая внутренней логики реализации. Относится к группе диаграмм поведения (behavioral diagrams) и применяется преимущественно на ранних этапах проектирования — при сборе и согласовании требований.
¶Назначение и место в UML
Вариант использования (use case) описывает законченный сценарий взаимодействия системы с внешней сущностью, приводящий к значимому для этой сущности результату. Диаграмма вариантов использования объединяет такие сценарии в единую картину, позволяя увидеть границы системы, перечень её функций и заинтересованных лиц.
В спецификации UML 2.x диаграмма вариантов использования не вводит новых элементов метамодели — она строится из тех же понятий, что и другие поведенческие диаграммы, но с акцентом на функциональность, а не на последовательность или состояние. Основное назначение — коммуникация между заказчиком и разработчиками: заказчик видит функции на понятном языке, разработчики получают основу для дальнейшего проектирования.
¶Основные элементы
¶Актор
Актор (действующее лицо) — внешняя по отношению к системе сущность, которая взаимодействует с ней. Актором может быть человек (пользователь, оператор, администратор), другая система, внешнее устройство или организация. Акторы изображаются в виде фигуры человечка, а также в виде прямоугольника со стереотипом «actor» для нечеловеческих сущностей.
Различают первичных акторов, инициирующих взаимодействие, и вторичных, участвующих в нём косвенно. Актор всегда находится за границей системы.
¶Вариант использования
Вариант использования изображается эллипсом с названием, обычно формулируемым как действие с точки зрения актора («Оформить заказ», «Просмотреть отчёт»). Каждый вариант использования представляет набор сценариев, включая основной поток и альтернативные ветвления.
¶Граница системы
Граница системы — прямоугольник, внутри которого размещаются варианты использования, а акторы — снаружи. Она задаёт область ответственности проектируемой системы и отделяет её от внешнего окружения.
¶Отношения
Между элементами диаграммы устанавливаются связи нескольких типов:
| Отношение | Обозначение | Смысл |
|---|---|---|
| Ассоциация | сплошная линия | Актор взаимодействует с вариантом использования |
| Включение (include) | пунктир со стрелкой, стереотип «include» | Базовый сценарий обязательно включает другой |
| Расширение (extend) | пунктир со стрелкой, стереотип «extend» | Дополнительный сценарий выполняется при условии |
| Обобщение | линия со стрелкой-треугольником | Наследование между акторами или вариантами |
Отношение включения применяют для вынесения повторяющегося поведения (например, «Авторизоваться»), расширения — для необязательных или условных действий (например, «Применить промокод»).
¶Правила построения
При разработке диаграммы придерживаются нескольких практических принципов:
- название варианта использования отражает цель актора, а не внутреннюю операцию системы;
- каждый вариант использования должен быть инициирован хотя бы одним актором;
- не следует смешивать уровни детализации — крупные функции дробят на подчинённые сценарии;
- количество вариантов на одной диаграмме ограничивают для сохранения читаемости;
- диаграмма не описывает порядок вызовов и алгоритмы — для этого служат диаграммы последовательности и деятельности.
¶Применение
Диаграммы вариантов использования применяются в следующих областях:
- Сбор требований. Служат инструментом согласования объёма работ с заказчиком.
- Проектирование программного обеспечения. Дают основу для выделения модулей и интерфейсов.
- Проектирование информационных систем и бизнес-процессов. Описывают роли сотрудников и функции автоматизируемых участков.
- Тестирование. Каждый вариант использования становится источником тест-кейсов для приёмочного тестирования.
- Документирование. Входят в состав проектной документации и технических заданий.
¶Инструменты и нотации
Диаграммы строятся как в специализированных CASE-средствах (IBM Rational Rose, Enterprise Architect, Visual Paradigm, StarUML), так и в универсальных редакторах с поддержкой UML. Широкое распространение получил текстовый язык PlantUML, позволяющий описывать диаграмму кодом. Помимо классического UML, существуют близкие нотации, например диаграммы вариантов использования в методологии RUP и в нотации IDEF0 на уровне контекстных диаграмм.
¶Ограничения и критика
Основной недостаток подхода — отсутствие строгой формализации: диаграмма не показывает последовательность шагов, условия переходов и обработку ошибок. Из-за простоты графики нередко возникают разночтения между участниками проекта. Кроме того, при большом числе сценариев диаграмма теряет наглядность, поэтому её часто дополняют текстовыми спецификациями вариантов использования и диаграммами деятельности.
Источники: спецификация OMG Unified Modeling Language (UML 2.5.1); Г. Буч, Дж. Рамбо, А. Джекобсон «Язык UML. Руководство пользователя»; М. Фаулер «UML. Основы»; материалы по методологии RUP.