Варианты использования в программной инженерии¶

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

Термин был введён шведским учёным Иваром Якобсоном в конце 1980-х годов в рамках методологии объектно-ориентированного анализа и проектирования (Objectory). Позднее Якобсон стал одним из соавторов языка моделирования UML (Unified Modeling Language), в котором вариант использования стал базовой диаграммной нотацией. С 1990-х годов подход получил широкое распространение в рамках различных гибких методологий (RUP, Scrum) и остаётся одним из стандартных способов описания требований.

¶Структура варианта использования

Каждый вариант использования обычно содержит следующие элементы:

• Название — глагольная конструкция, отражающая цель актора (например, «Оформить заказ», «Зарегистрировать пользователя»).
• Акторы — внешние сущности (люди, системы, устройства), взаимодействующие с системой.
• Предусловия — состояние системы, необходимое для начала выполнения сценария.
• Основной сценарий (happy path) — последовательность шагов, ведущих к успешному достижению цели.
• Альтернативные потоки — ответвления от основного сценария, описывающие вариации поведения (например, отмена операции, ввод некорректных данных).
• Исключительные ситуации — обработка ошибок и сбоев.
• Постусловия — состояние системы после завершения сценария.

Варианты использования могут быть представлены как в текстовой форме (таблицы, шаблоны), так и в виде диаграмм UML. Диаграмма вариантов использования (use case diagram) показывает общую функциональность системы и её границы, однако детальное описание сценариев выполняется в текстовом виде.

¶Применение в процессе разработки

¶Сбор требований

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

¶Проектирование и архитектура

На этапе проектирования варианты использования служат основой для выделения модулей, классов и компонентов. В методологии RUP (Rational Unified Process) варианты использования являются центральным артефактом: архитектура системы проектируется таким образом, чтобы реализовать все описанные сценарии. Каждый вариант использования может быть разложен на последовательности взаимодействий объектов (диаграммы последовательности).

¶Оценка трудозатрат

По вариантам использования можно оценивать объём работ. Существует методика оценки по баллам вариантов использования (Use Case Points), аналогичная функциональным точкам. Она учитывает сложность акторов и сценариев, а также технические факторы окружения.

¶Тестирование

Варианты использования напрямую преобразуются в тестовые сценарии. Основной сценарий становится позитивным тестом, альтернативные потоки и исключения — негативными и граничными тестами. Такой подход обеспечивает покрытие ключевой функциональности системы требованиями.

¶Документация и обучение

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

¶Достоинства и ограничения

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

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

¶Связь с другими артефактами

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

• Пользовательские истории (user stories) — более краткая и грубая форма описания требований в agile; варианты использования могут рассматриваться как детализация пользовательских историй.
• Диаграммы деятельности и последовательности — уточняют логику выполнения сценариев.
• Модель предметной области — определяет сущности, участвующие в сценариях.
• Тест-план — формируется на основе вариантов использования.

¶Инструменты поддержки

Для моделирования вариантов использования применяются CASE-средства: IBM Rational Software Architect, Enterprise Architect, Visual Paradigm, StarUML. Управление текстовыми описаниями сценариев часто ведётся в системах управления требованиями (Jama, Polarion, IBM DOORS) либо в вики-системах и баг-трекерах с поддержкой разметки.

¶Заключение

Варианты использования остаются одним из наиболее распространённых способов описания функциональных требований в программной инженерии. Они обеспечивают связь между бизнес-целями и технической реализацией, служат основой для проектирования, тестирования и оценки трудозатрат. Несмотря на появление альтернативных подходов (например, спецификации на основе примеров — specification by example), классические use cases сохраняют актуальность в индустрии благодаря своей универсальности и простоте.