Анализ предметной области и требования к ПО

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

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

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

Примеры вариантов использования:

• Покупатель в Интернет-магазине выбирает товар. Для этого он может выбрать категорию товара, фирму-изготовителя или группу таких фирм и отфильтровать оставшиеся товары по цене, габаритам и цвету. Определившись, он выбирает товар, кликая на соответствующем значке мышкой.
• Оператор системы контроля качества газопровода ищет участки газопровода с повышенным риском возникновения аварии. Для этого он выбирает группу ранее случившихся аварий, фильтруя их по дате, нанесенному ущербу, типу аварии и запускает процедуру анализа характеристик соответствующих участков газопровода на совпадение, по крайней мере, двух характеристик. При таком анализе учитываются изготовитель труб и их партия, история хранения труб на складах, землепроходческая бригада, бригада сварщиков, показатели нескольких последних проведенных инспекций, показатели химической активности грунтов, наличие близлежащих предприятий, влияющих на химические и электрические характеристики грунтов. После этого на карте выделяются участки, характеристики которых также попадают под найденный "шаблон аварии".

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

Варианты использования могут быть связаны друг с другом тремя видами связей: обобщением (generalization), расширением (extend relationship) и включением (include relationship). Действующие лица также могут быть связаны друг с другом с помощью связей обобщения (generalization).

увеличить изображение
Рис. 4.7. Набросок диаграммы вариантов использования для Интернет-магазина

Если несколько вариантов использования имеют много общего в структуре выполняемых в их рамках сценариев и в достигаемых целях, можно выделить обобщающий их вариант использования, содержащий общие части описываемого ими поведения. Обобщаемые варианты уточняют обобщающий их вариант. При этом обычно сценарий работы обобщаемого варианта состоит из нескольких кусков — последовательности действий, выполняемых в рамках сценария работы общего варианта использования, перемежаются с последовательностями, специфическими для частного. Например, если система регистрации заказов в магазине позволяет оформить заказ (данные о котором в дальнейшем будут присутствовать в системе) как при помощи сайта магазина, так и по телефону, то варианты использования "Заказ товара через сайт" и "Заказ товара по телефону" могут быть обобщены в варианте "Заказ товара".

Вариант использования A расширяет (extends) другой вариант использования B, если в ходе сценария работы A при определенных условиях надо включить полный сценарий работы B. Например, оператор сайта магазина может удалить товар, введя его идентификатор; а если идентификатор ему не известен, а известна лишь марка товара и производитель, он должен сначала найти такой товар и определить идентификатор в его описании, а затем уже удалить товар. Соответственно, вариант использования "Удаление товара" будет расширять вариант использования "Поиск товара".

увеличить изображение
Рис. 4.8. Доработанная диаграмма вариантов использования для Интернет-магазина

Вариант использования A включает (includes, или использует, uses) вариант использования B, если A всегда в некоторый момент включает полностью сценарий работы B. Например, при оформлении заказа покупатель всегда должен определить способ его оплаты. Значит, вариант использования "Заказ товара" включает вариант "Определение способа оплаты".

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

Хорошо описанный вариант использования имеет следующие атрибуты [9]:

1. Имя, ясно говорящее о назначении варианта использования.
2. Описание. Несколько предложений, описывающих этот вариант использования.
3. Частота. Насколько часто данный вариант использования возникает.
4. Предусловия. Все условия запуска варианта использования.
5. Постусловия. Все условия, которые должны быть выполнены после успешного выполнения варианта использования.
6. Основной сценарий работы, который используется в большинстве случаев.
7. Альтернативные сценарии, возникающие иногда. Для каждого альтернативного сценария указываются условия его запуска.
8. (Необязательно) Задействованные действующие лица.
9. (Необязательно) Расширяемые варианты использования.
10. (Необязательно) Включаемые варианты использования.
11. (Необязательно) Статус: "в разработке", "готов к проверке", "в процессе проверки", "подтвержден", "отвергнут".
12. (Необязательно) Допущения об окружении и ходе работы системы, использованные при разработке данного варианта. В полностью готовом варианте эти допущения либо должны быть подтверждены и стать ограничениями системы, либо должны давать начало различным сценариям работы.

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