Вопрос 1. Варианты использования. Конкретизация требований с использованием вариантов использования.

Идея описания функциональных требований в виде прецедентов (ВИ – вариантов использования) была сформулирована в 1986 году А. Якобсоном (Ivar Jacobson) – одним из разработчиков языка UML.

Прецедент (ВИ – вариант использования, Use case) специфицирует поведение системы или ее части и представляет собой описание множества последовательностей действий (включая варианты), выполняемых системой для того, чтобы исполнитель мог получить определенный результат. ВИ определяют, как исполнители взаимодействуют с программной системой. В процессе этого взаимодействия исполнителям генерируются события, передаваемые системе, которые представляют собой запросы на выполнение некоторой операции. ВИ – механизм упрощения этапа формулировки требований с позиции всех заинтересованных лиц. Цель описания ВИ – более глубокое понимание проблемы. В конечном итоге, ВИ представляет собой набор взаимосвязанных удачных и неудачных сценариев, описывающих использование системы исполнителем для решения одной из задач. Ключевое свойство ВИ состоит в том, что поведение разрабатываемой системы можно описывать, не определяя ее реализацию, т. е. описывает внешнее поведение системы с точки зрения пользователя (исполнителя).

Хорошо структурированные ВИ описывают только существенное поведение системы или подсистемы и не являются ни слишком общими, ни слишком специфическими.

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

Сценарий (scenario) – последовательность действий или взаимодействий между исполнителем и системой.

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

Описание ВИ – текстовые документы, из которых вытекают функциональные требования, отвечающие на вопрос “что должна делать система?”.

ВИ представляет собой некий моментальный снимок одного из аспектов вашей системы. Совокупность всех ВИ образует внешнее представление системы. Как только определены ВИ, они позволят управлять дальнейшим моделированием предметной области.

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

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

Когда варианты использования документируют бизнес-процессы организации, рассматриваемая система (SuD – system under discussion) и является этой органи­зацией. Участники ­ это акционеры компании, заказчики, поставщики, органы государственного управления. Основные ДЛ ­ это заказчики компании и, возможно, их поставщики.

Если варианты использования описывают требования к поведению части про­граммного обеспечения, SuD ­- это компьютерная программа. Участники ­ это по­льзователи программы, компания, владеющая ею, органы государственного управления и другие компьютерные программы. Основное ДЛ - это сидящий за компьютером пользователь или другая компьютерная система.

Основное внимание при описании ВИ надо уделить тому, как использование системы обеспечит ощутимый для ДЛ результат.

Описание ВИ – текстовые документы, из которых вытекают функциональные требования, отвечающие на вопрос “что должна делать система?”.

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

Например, в контексте использования банкомата можно следующим образом описать вариант использования.

Рассмотрим в качестве примера один из ВИ банкомата – начало работы и идентификация клиента. Назовем его: “Проверить пользователя”.

Основной поток событий.

1-й шаг. Клиент вставляет кредитную карту в банкомат.

2-й шаг. Система ее считывает.

3-й шаг. Система запрашивает у клиента его персональный идентификационный номер (PIN).

4-й шаг. Клиент может ввести его с клавиатуры. Завершается ввод нажатием клавиши “Ввод”.

5-й шаг. После этого система проверяет введенный PIN и, если он правильный, подтверждает корректную идентификацию клиента.

Исключительный поток событий.

Клиент может прекратить транзакцию в любой момент, нажав клавишу “Отмена”. Никаких изменений на счету клиента не производится.

Альтернативный поток событий.

2-й шаг: а) если считываемая кредитная карта не может использоваться в данном банкомате, то система выводит на экран сообщение “Неверная карта”. Если выводится сообщение “Неверная карта”, кредитная карта выдается обратно и работа заканчивается.

б) если считываемая кредитная карта вставлена не правильно, то система выводит на экран сообщение “Неверная карта”. Если выводится сообщение “Неверная карта”, кредитная карта выдается обратно и работа заканчивается.

4-й шаг: а) клиент может в любой момент до нажатия клавиши “Ввод” стереть свой PIN и ввести новый;

5-й шаг: а) если клиент ввел неправильный PIN-код, ВИ запускается с шага 2;

б) если ввод неправильного PIN-кода происходит три раза подряд, то система отменяет всю транзакцию, блокирует доступ к счету, не выдает кредитную карту обратно. Работа с банкоматом завершается.

Исключительный поток событий.

Клиент может прекратить транзакцию в любой момент, нажав клавишу “Отмена”. Это действие начинает ВИ заново. Никаких изменений на счету клиента не производится.

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

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

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