Самостоятельная работа. Варианты использования

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

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

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

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

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

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

Чтобы научиться писать хорошие варианты использования, необходимо освоить три понятия, которые применяются к каждому предложению варианта использования и варианту использования в целом:

1. Область действия (Scope): какова на самом деле рассматриваемая система?

2. Основное действующее лицо (Primary actor): у кого есть цель?

3. Уровень (Level): какой уровень имеет эта цель?

Основные определения:

1. Действующее лицо (Actor): кто-то (или что-то), обладающий поведением.

2. Участник (Stakeholder): кто-то (или что-то), проявляющий интерес к поведению рассматриваемой системы (SuD).

3. Основное действующее лицо (Primary actor): участник (некто или нечто), инициирующий взаимодействие с SD для достижения некоторой цели.

4. Вариант использования (Use case): соглашение относительно поведения SD.

5. Область действия (Scope): идентифицирует рассматриваемую систему.

6. Предусловия и гарантии (Preconditions and guarantees): то, что должно быть истинным до и после реализации варианта использования.

7. Основной сценарий (Main success scenario): вариант, в котором не возникает никаких ошибок.

8. Расширения (Extensions): различные отклонения от основного сценария.

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

10. Когда один вариант использования ссылается на другой, последний подчеркивается.

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

Вариант использования «Покупка ценных бумаг через Интернет»

Основное действующее лицо: покупатель

Область действия: персональные консультанты / финансовый пакет (PAF)

Уровень: цель пользователя

Участники и интересы:

Покупатель — хочет купить ценные бумаги, причем они должны автоматически попасть в портфель PAF.

Биржевое агентство — хочет получить полную информацию о покупке.

Предусловие: программа PAF у пользователя уже открыта.

Минимальные гарантии: в наличии достаточно регистрационной информации, чтобы PAF могла обнаружить несоответствие и запросить у пользователя дополнительные данные.

Гарантия успеха: удаленный web-сайт подтвердил покупку; регистрационные файлы и портфель пользователя обновлены.

Основной сценарий:

1. Покупатель выбирает покупку ценных бумаг через Сеть.

2. PAF получает от пользователя адрес нужного сайта.

3. PAF подключается к сайту, сохраняя контроль над процессом.

4. Покупатель выбирает и покупает ценные бумаги на данном сайте.

5. PAF перехватывает ответы web-сайта и обновляет портфель покупателя.

6. PAF показывает покупателю новое состояние портфеля.

Расширения:

2а. Покупатель запросил web-сайт, не поддерживаемый PAF.

2а1. Система получает от покупателя новое предложение с возможностью отменить вариант использования.

3а. Отказ любого рода в Сети во время установки:

3а1. Система сообщает покупателю о неудаче, дает совет и возвращается на предыдущий шаг.

3а2. Покупатель либо отказывается продолжать этот вариант использования либо делает новую попытку.

4а. Во время транзакции покупки компьютер выходит из строя или выключается:

4а1. (Что здесь нужно делать?)

4b. web-сайт не подтверждает покупку, а задерживает ее:

4b1. PAF регистрирует задержку, устанавливает таймер, чтобы запросить покупателя о выходе.

5а. Web-сайт не возвращает необходимую информацию о покупке:

5а1. PAF регистрирует отсутствие информации о том, совершилось ли в портфеле покупателя обновление для зависшей покупки.

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

Вариант использования «Получить страховую компенсацию за автомобильную аварию»

Основное действующее лицо: истец

Область действия: страховая компания

Уровень: обобщенный

Участники и интересы:

Истец — хочет получить максимально возможную сумму.

компания - хочет заплатить как можно меньше.

Министерство страхования — хочет убедиться, что соблюдены все

нормы и правила.

Предусловие: отсутствует.

Минимальные гарантии: СК регистрирует заявление и все действия.

Гарантия успеха: истец и СК приходят к соглашению о сумме страхового возмещения. Истец получает оговоренную сумму.

Триггер: истец представляет заявление на рассмотрение.

Основной сценарий:

1. Истец представляет на рассмотрение заявление с обоснованием.

2. Страховая компания проверяет законность страхового полиса истца.

3. Страховая компания назначает агента для расследования страхового случая.

4. Страховая компания проверяет, укладываются ли все детали в нормативы полиса.

5. Страховая компания выплачивает истцу страховое возмещение и закрывает дело.

Расширения:

1а. Предоставленные данные не полны:

1а1. Страховая компания запрашивает недостающую информацию.

1а2. Истец предоставляет недостающую информацию.

2а. Полис истца недействителен:

2а1. Страховая компания отклоняет заявление, извещает истца, документирует все действия и прекращает дело.

3а. На этот момент нет свободных агентов.

3а1. (Что в этом случае делает страховая компания?)

4а. Обстоятельства аварии противоречат основным правилам полиса:

4а1. Страховая компания отклоняет заявление, извещает истца, документирует все действия и прекращает дело.

4b. Обстоятельства аварии противоречат второстепенным правилам полиса:

4b1. Страховая компания начинает переговоры с истцом относительно суммы платежа.

Варианты использования — это вид документации, который можно использовать в работе в различных ситуациях, например, если требуется:

1. Описать рабочий процесс в бизнесе.

2. Сконцентрировать усилия на обсуждении принципиальных требований к разрабатываемой системе, а не на подробном их описании.

3. Описать функциональные требования к системе.

4. Документировать проект системы.

Требования и варианты использования

Если варианты использования пишутся, как требования, имейте в виду:

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

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

Самостоятельная работа

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

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

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

До сих пор нет общего мнения относительно того, как организовать все маленькие варианты использования типа Создать завиток, Найти завиток, Обновить завиток и Удалить завиток. Они известны как варианты использования CRUD (аббревиатура названий операций над базами данных Create, Retrieve, Update и Delete). Вопрос в том, входят ли все они в один вариант использования, чей размер больше варианта использования Управлять завитками, либо существуют самостоятельно?

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

Мнения о том, как лучше всего действовать в отношении вариантов использования CRUD, разделились. Сьюзен Лилли из S.R.A. выступает за то, чтобы держать их отдельно, так как это поможет отследить, какое из основных действующих лиц имеет доступ к различным функциям. Я склонен начать с одного, Управлять завитками, чтобы уменьшить загромождение вариантов использования. Если писать варианты использования становится сложно, я выделяю одну часть, как описано в подразделе Создание из расширения нового варианта использования (раздел 8.3). Я прослеживаю доступ пользователя к системным данным и функциям с помощью отдельных рабочих таблиц. Все способы правомочны, и я не нашел достаточных оснований возводить в правило лишь один из них.

Ниже следует вариант использования, написанный Джоном Колацци и Аленом Максвеллом из Empower IT*. Они начали писать обоими способами, но затем решили объединить эти варианты использования в один, обобщенного уровня, под названием Управление. В конце концов они выделили подчиненный вариант использования Сохранить, чтобы упростить работу. Их варианты использования показывают, насколько они следовали собственному стилю в данном образце. Начав с шаблона Rational Unified Process, они пронумеровали шаги и расширения.

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