7.1. Основной сценарий.
При объяснении какого-либо сложного понятия мы начинаем с простых и доступных вещей, а потом добавляем: “Ну, на самом деле, это немного сложнее. Когда случается то-то и то-то, в действительности происходит следующее,..”.
Такой стиль объяснения очень хорош, и таким способом мы описываем ветвящуюся сюжетную линию, которая становится вариантом использования. Сначала мы создаем от начала до конца описание одного простого для понимания и довольно типичного сценария, в котором достигается цель основного действующего лица и удовлетворяются интересы всех участников. Это основной сценарий. Все другие способы преуспеть в достижении цели и обработка всех неудач описаны в расширениях к этому варианту использования.
Общая структура.
Основной сценарий и все его расширения находятся внутри структуры, в которую входат следующие части:.
■ Условие, при котором работает сценарий. Для основного сценария это предусловие вместе с триггером. Для сценария расширения это условие расширения (возможно, с номером шага или местом в сценарии, к которому относится условие).
■ Цель. Для основного сценария это название варианта использования. Цель обязательно соответствует интересам участников. Для сценария расширения целью является либо достижение цели варианта использования, либо воссоединение с основным сценарием после обработки условия.
■ Набор шагов действия. Формирует тело сценария и следует одинаковым правилам в каждом сценарии или фрагменте сценария.
■ Условие окончания. Цель достигается в конце основного сценария. Фрагмент сценария может заканчиваться достижением цели либо отказом от нее.
■ Возможный набор расширений, написанный в виде фрагментов сценария. Расширения к основному сценарию помещаются в раздел расширений шаблона варианта использования. Расширения к расширениям располагают в той же строке, внутри тела расширения или сразу за ним.
Здесь представлены две выдержки из варианта использования 1, который я раскрыл, чтобы показать сходство общих структур.
Основной сценарий:.
Вариант использования Купить ценные бумаги через Интернет.
Предусловие: программа PAF у пользователя уже открыта.
Триггер: пользователь выбрал "покупку ценных бумаг".
1.
Пользователь решил купить ценные бумаги через Сеть.
2.
PAF получает от пользователя название нужного сайта (ETrade, Schwab и т.д.).
3.
PAF подключается к сайту, сохраняя управление процессом.
4.
Покупатель выбирает и покупает ценные бумаги на зтом сайте.
5.
PAF перехватывает ответы web-сайта и обновляет портфель покупателя.
6.
PAF показывает покупателю новое состояние портфеля.
Расширение к данному варианту использования:.
За. Отказ Сети любого рода во время установки:.
За1. Система сообщает пользователю о неудаче, дает совет и возвращается на предыдущий шаг.
За2. Пользователь либо отказывается продолжать этот вариант использования, либо пробует снова.
В этой главе мы подробно рассмотрим тело сценария, состоящее из шагов действия.
Тело сценария.
Каждый сценарий или его фрагмент записывается в виде последовательности действий разных действующих лиц, направленных на достижение цели. Я употребляю термин “последовательность” для удобства, но мы можем вносить пометки, показывающие, что шаги можно выполнять параллельно, выбирать в различном порядке, повторять, а некоторые даже могут быть необязательными.
Как отмечалось в разделе 2.2, любой отдельный шаг будет описывать:.
* Взаимодействие двух действующих лиц (“Клиент вводит адрес”).
* Шаг подтверждения для защиты интереса участника (“Система подтверждает PIN-код”).
■ Внутреннее изменение для удовлетворения интереса участника (“Система выводит сумму из баланса”).
Ниже приведен пример типичного основного сценария, позаимствованный из варианта использования 22. Обратите внимание, что шаги 1, 3, 5-8 — это взаимодействия, шаг 4 —проверка, а шаги 2 и 9 — внутренние изменения.
1.
Служащий вводит номер полиса застрахованного лица и, возможно, его имя и дату страхового события.
2.
Система анализирует доступную информацию о полисе и указывает, что заявление соответствует полису.
3.
Служащий вводит основные данные об ущербе.
4.
Система подтверждает, что не существует конкурирующих заявлений, и присваивает заявлению номер.
5.
Служащий продолжает вводить информацию об ущербе, соответствующую заявлению данного типа.
6.
Служащий использует систему для получения дополнительной информации по делу из других компьютерных систем.
7.
Служащий выбирает и назначает оценщика.
8.
Служащий подтверждает, что он закончил.
9.
Система сохраняет данные и инициирует отправку уведомления агенту.
Любой шаг действия пишется для того, чтобы показать простое действие. Я уподобляю это описанию футбольного матча: игрок 1 пасует игроку 2; игрок 2 ведет мяч; игрок 2 пасует игроку 3.
Приобретение навыков написания трех видов шагов действия благотворно скажется на вашем стиле описания вариантов использования. Тот же стиль употребляется для шагов действия в каждой части любого варианта использования высокого либо низкого уровня, будь то основной сценарий, расширение, бизнес-процесс или система.
7.2. Шаги действия.
Шаги действия, которые составляют хорошо написанный вариант использования, представлены в одной грамматической форме, простом действии, когда одно действующее лицо выполняет задачу или передает информацию другому действующему лицу.
Пользователь вводит имя и адрес.
В любое время пользователь может потребовать деньги назад.
Система подтверждает подлинность имени и счета.
Система обновляет остаток на счету клиента, чтоб отразить оплату.
Обычно временные соотношения можно опустить, так как шаги, как правило, следуют один за другим.
В способах изложения шагов действия существует масса менее важных вариаций, как видно из примеров вариантов использования. Тем не менее старайтесь писать, придерживаясь следующих правил.
Правила.
Правило 1. Используйте простые предложения.
Структура предложения должна быть предельно простой:.
Подлежащее...сказуемое...прямое дополнение... предложный оборот.
Например:.
Система... удерживает ...сумму... из остатка на счете.
И это все. Я говорю об этом, поскольку многие непредумышленно опускают подлежащее. В этом случае неясно, кто же производит действие (у кого, так сказать, мяч). Если предложение плохо сформулировано, трудно следить за развитием сюжета.
Правило 2. Ясно укажите, "кто владеет мячом".
Весьма наглядный пример ^— приятели, перебрасывающиеся футбольным мячом. Игрок 1 передает мяч игроку 2, игрок 2 немножко ведет мяч, а затем перебрасывает игроку 3. Мяч может загрязниться, и один из игроков его вытрет.
У сценария та же структура. На каждом шаге одно из действующих лиц “владеет мячом”. Это действующее лицо будет подлежащим (первое названное действующее лицо), вероятно, первым или вторым словом в предложении. “Мяч” — это сообщение и данные, которые одно действующее лицо передает другому.
Действующее лицо с мячом будет либо владеть им само, либо передавать кому-то еще, либо очищать от грязи. В половине случаев шаг заканчивается тем, что мяч получает другое действующее лицо. Спросите себя, кто владеет мячом в конце предложения. Ответ в варианте использования всегда должен быть ясным.
Правило 3. Пишите, глядя на вариант использования с высоты птичьего полета.
Начинающие авторы вариантов использования, особенно программисты, создающие его описание, часто пишут сценарии с точки зрения системы, которая смотрит на мир и беседует сама с собой. У них получаются примерно такие предложения: “Получить карточку банкомата и PIN-код. Снять сумму с остатка на счете”.
Вместо этого пишите вариант использования следующим образом:.
Клиент вводит в банкомат карточку и PIN-код.
Система снимает сумму с остатка на счете.
Некоторым писателям нравится стиль драматического произведения, когда поведение действующих лиц описывается, как в пьесе.
Клиент: Вводит в банкомат карточку и PIN-код.
Система: Снимает сумму с остатка на счете.
Заметьте, что смысл в обоих случаях остается неизменным.
Правило 4. Покажите продвижение процесса.
Прогресс отдельного шага связан с тем, насколько приблизилась цель. В обобщенных, или белых, вариантах использования шаг, вероятно, приближает цель в полном объеме. В варианте использования уровня подфункции приближение цели менее различимо. Если мы видим шаг Пользователь нажимает на клавишу tab, это значит, что мы заглянули в вариант использования цвета темного индиго (или черного), либо автор просто решил описывать слишком незначительные действия.
Ошибочный выбор очень мелких шагов сказывается на длине варианта использования. Если вариант использования состоит из 13-17 шагов, почти наверняка его предложения не слишком продвигают дело к цели. Вариант использования будет более читабельным и понятным, если объединить эти мелкие шажки. При этом объем существенной информации не уменьшится. Я редко встречал хорошо написанный вариант использования, основной сценарий которого включал бы более девяти шагов.
Чтобы найти для шага цель чуть более высокого уровня, спросите себя, почему действующее лицо делает это (как описано в главе 5 в подразделе Повышение и понижение уровней целей). Ответ на этот вопрос, скорее всего, окажется нужной для вашего шага целью, хотя, возможно, вам првдется задавать его несколько раз, прежде чем вы получите желаемый ответ (см. далее пример повышения уровня цели с помощью вопроса “почему”).
Пользователь нажимает на клавишу tab.
Почему пользователь нажимает на клавишу tab? Чтобы попасть в поле адреса.
Почему он пытается попасть в поле адреса? Потому что он должен ввести свои имя и адрес, прежде чем система начнет что-то делать.
Он хочет, чтобы система что-то сделала (скорее всего, выполнила этот самый вариант использования), а для этого ему нужно ввести свое имя и адрес.
Таким образом, предложение, описывающее действие, заметно продвигающее процесс, выглядит так:.
Пользователь вводит имя и адрес.
Правило 5. Показывайте намерение, а не движения действующего лица.
Описание детальных действий пользователя в процессе работы с пользовательским интерфейсом системы — одна из распространенных и серьезных ошибок при создании варианта использования. Я называю это описанием деталей интерфейса. Такое описание ухудшает качество документа, излагающего требования к системе, делая его более длинным, неустойчивым и перегруженным связями.
* Длинные документы труднее читать и сложнее поддерживать.
* Описываемыйдиалог, возможно, не является требованием, но показывает, как автор представляет себе в данный момент интерфейс пользователя.
■ Диалог неустойчив в том смысле, что небольшие изменения в проекте системы делают его описание недействительным.
Работа проектировщика интерфейса пользователя и заключается в создании эффективного интерфейса, который позволит пользователю достигнуть цели варианта использования. Описание детальных действий соответствует этой задаче проектирования, но не документу, излагающему функциональные требования.
В документе, излагающем требования, нас интересует описание концепции интерфейса, т.е. то, что объявляет намерение пользователя и суммирует информацию, передаваемую от одного действующего лица другому. Авторы книги Software for use посвятили ее часть именно этой теме, пользуясь термином важнейшие варианты использования (essential use cases) для обозначения системных вариантов использования уровня моря, описывающих концепцию интерфейса.
Обычно все данные, передаваемые в одном направлении, собираются в одном шаге действия. Ниже приведены распространенный фрагмент неправильного описания и способ его исправления.
Первоначальный вариант:.
1.
Система запрашивает имя.
2.
Пользователь вводит имя.
3.
Система запрашивает адрес.
4.
Пользователь вводит адрес.
5.
Пользователь щелкает по кнопке "ОК".
6.
Система представляет параметры пользователя.
Исправленный вариант:.
1.
Пользователь вводит имя и адрес.
2.
Система представляет параметры пользователя.
Если передается более трех элементов данных, вы можете поместить каждый элемент в отдельной строке в табличном списке. Оба способа хороши, но первый работает лучше, если вы впервые набрасываете варианты использования, поскольку его можно быстрее написать и прочитать. Второй предпочтительней, если вы хотите обеспечить высокую точность для трассировки или тестирования.
Допустимый вариант 1:.
1. Пользователь вводит имя, адрес, номер телефона, конфиденциальную информацию, номер контактного телефона для чрезвычайных ситуаций.
Допустимый вариант 2:.
1. Пользователь вводит:.
- имя.
- адрес.
- номер телефона.
- конфиденциальную информацию.
- номер контактного телефона для чрезвычайных ситуаций.
Правило 6. Включайте "рациональный" набор действий.
Ивар Якобсон описал шаг варианта использования как представление транзакции. Для этой формулировки он зафиксировал четыре части сложного взаимодействия (рис. 7.1):
Рис. 7.1. Четыре части транзакции.
1.
Основное действующее лицо посылает системе запрос и данные.
2.
Система подтверждает запрос и данные.
3.
Система изменяет внутреннее состояние.
4.
Система выдает действующему лицу результат.
Можно записать четыре части как отдельный шаг действия или скомбинировать их различными способами, в том числе включив в один шаг действия все четыре части. Как лучше — зависит от сложности каждой части и от того, где происходят естественные перерывы в процессе обработки.
Вашему вниманию предлагается пять версий. Все они правильные, хотя версию 1 я считаю слишком сложной для восприятия. Мне нравится версия 2 с понятными частями, но я нахожу их слишком длинными для работы на этом этапе. Для данного примера я предпочитаю версии 3, и 4. Полагаю, что шаги действия в версии 5 мелковаты, сценарий становится слишком длинным и тяжеловесным, но достоинство этой версии в том, что шаги являются отдельно тестируемыми единицами, а это может пригодиться при более формальном подходе к разработке.
Версия 1:.
1. Клиент вводит номер заказа. Система обнаруживает, что он совпадает с выигравшим номером месяца, регистрирует пользователя и номер заказа как победителя этого месяца, посылает электронной почтой сообщение менеджеру по продажам, поздравляет клиента и выдает инструкцию, как получить приз.
Версия 2:.
1.
Клиент вводит номер заказа.
2.
Система обнаруживает, что он совпадает с выигравшим номером месяца, регистрирует пользователя и номер заказа как победителя этого месяца, посылает электронной почтой сообщение менеджеру по продажам, поздравляет клиента и выдает инструкцию, как получить приз.
Версия 3:.
1.
Клиент вводит номер заказа.
2.
Система обнаруживает, что он совпадает с выигравшим номером месяца.
3.
Система регистрирует пользователя и номер заказа как победителя этого месяца, посылает электронной почтой сообщение менеджеру по продажам, поздравляет клиента и выдает инструкцию, как получить приз.
Версия 4:.
1.
Клиент вводит номер заказа.
2.
Система обнаруживает, что он совпадает с выигравшим номером месяца.
3.
Система регистрирует пользователя и номер заказа как победителя этого месяца, посылает электронной почтой сообщение менеджеру по продажам.
4.
Система поздравляет клиента и выдает инструкцию, как получить приз.
Версия 5:.
1.
Клиент вводит номер заказа.
2.
Система обнаруживает, что он совпадает с выигравшим номером месяца.
3.
Система регистрирует пользователя и номер заказа как победителя этого месяца.
4.
Система посылает электронной почтой сообщение менеджеру по продажам.
5.
Система поздравляет клиента и выдает инструкцию, как получить приз.
Правило 7. "Подтвердить", а не "Проверить".
Одним из трех видов шагов действия является подтверждение системой, что соблюдено некоторое бизнес-правило. Часто пишут, что система проверяет условие. Это неудачный глагол для действия. Он не отражает продвижение процесса вперед, не является на самом деле целью и не указывает явно, каков результат проверки. Вам тотчас же придется написать: “Если поверка прошла удачно...” и “Если проверка закончилась неудачей...”.
Применим метод “Спросить почему”, чтобы найти более подходящее предложение. Почему система проверяет это условие? Ответ: чтобы установить, или подтвердить, или обеспечить что-то. Эти глаголы лучше выражают действие для достижения цели. Замените предложение “Система проверяет, правильный ли пароль” предложением:.
Система подтверждает, что пароль правильный.
Увидев слово если, вспомните это правило. Всякий раз, когда вы видите "Если (условие)... тогда...", взгляните на предыдущее предложение. Вероятно, его сказуемое — проверяет. Замените в первом предложении проверяет на подтверждает и сделайте второе предложение простым описанием действия без если. Ниже представлен пример до и после преобразования.
Первоначальный вариант:.
2.
Система проверяет, правилен ли пароль.
3.
Если да, система представляет пользователю допустимые действия.
Исправленный вариант:.
2.
Система подтверждает, что пароль правилен.
3.
Система представляет пользователю допустимые действия.
Обратите внимание, что во втором случае сценарий описан как успешный. Он также побуждает читателя спросить на шаге 2, что произойдет, если пароль неверный. Читатель обратится к соответствующему разделу расширения и найдет расширение, начинающееся со слов Пароль неверен. Это придает варианту использования последовательный ритм, что облегчает чтение и просмотр.
Правило 8. В некоторых случаях вводите временные ограничения.
Большинство шагов следуют непосредственно из предыдущего. Иногда приходится писать так:.
В любое время между 3 и 5 шагами пользователь...
или.
Как только пользователь..., система...
Вставлять временные ограничения можно, но только когда это необходимо. Обычно временные параметры очевидны, и нет необходимости их упоминать.
Правило 9. Идиома: "Пользователь использует систему А для получения данных от системы В".
Это ситуация, с которой вы можете столкнуться. Вы хотите, чтобы разрабатываемая система А получила информацию от системы В или как-то иначе осуществила с ней взаимодействие. Ей следует это делать, только когда основное действующее лицо определяет, что настал нужный момент. Нельзя написать: "Пользователь нажимает на кнопку "Получить", и в этот момент система получает данные от системы В". Это потребует описания деталей интерфейса.
Можно использовать два шага:.
4.
Пользователь дает системе сигнал получить данные от системы В.
5.
Система получает исходные данные от системы В.
Это приемлемо, однако громоздко и избыточно. Лучше написать так:.
4. Пользователь применяет систему для получения исходных данных от системы В.
С помощью этого небольшого изменения мы показываем, что пользователь сам выбирает время, и мяч переходит от пользователя к системе А, затем к системе В. Кроме того, мы определяем обязанности всех трех систем. Подробности инициирования пользователем действия не определены, как и должно быть.
Правило 10. Идиома: "Делать шаги х-у, пока не возникнет условие"].
Иногда мы хотим отметить, что некоторые шаги могут повторяться. И опять нам по-1 везло, что мы пишем обычной прозой, а не пользуемся формализмами программирования. Просто напишите, что шаг или шаги будут повторяться.
Если повторяется только один шаг, можно записать указание о повторении пря-
мо в шаге: ‘.
Пользователь выбирает один или более продуктов.
Пользователь просматривает различные каталоги товаров, пока не найдет.
тот, которым захочет воспользоваться.
Если повторяется несколько шагов, можно указать на повторение до или после повторяющихся шагов. Я пишу о повторениях после шагов, чтобы чуть облегчить чтение сценария, но подойдет любой способ.
1.
Клиент предоставляет учетный идентификатор либо имя и адрес.
2.
Система спрашивает о предпочтениях клиента.
3.
Пользователь выбирает товар для покупки, отмечает его для покупки.
4.
Система добавляет товар к тележке для покупок клиента. Клиент повторяет шаги 3-4, пока не укажет, что выбор закончен.
5.
Клиент покупает товары, находящиеся в тележке для покупок.
Заметьте, что нам не нужно нумеровать предложение о повторении, и нет необходимости в предложении, открывающем повторение. И то и другое загромождает описание.
В варианте Делать шаги х-у, пока не возникнет условие, шаги х-у могут быть в любом порвдке. Думаю, имеет смысл помещать условие перед соответствующими шагами.
1.
Клиент входит в систему.
2.
Система представляет доступные продукты и услуги. Шаги 3-5 могут происходить в любом порядке.
3.
Пользователь выбирает продукты для покупки.
4.
Пользователь указывает предпочтительную форму оплаты.
5.
Пользователь дает адрес для доставки.
6.
Пользователь указывает, что сделал все покупки.
7.
Система инициирует заказ, причем выбранные продукты будут оплачены по выбранной форме оплаты и посланы по адресу назначения.
Нумеровать или нет.
Номера выделяют шаги и позволяют ссылаться на них в разделе расширений. Однако их труднее поддерживать. Без хороших инструментов автоматической перенумерации при вставке или добавлении шагов утомительно постоянно перенумеровывать шаги одного и того же варианта использования. Хорошие варианты использования можно написать с нумерацией шагов и без нее, поэтому этот вопрос надо решить для проекта в целом.
Группы, в которых я работал, испытывали оба метода и последовательно выбирали нумерацию предложений по всем абзацам, поэтому нумерованные предложения стали для меня стандартом. Другие привыкли писать в форме простых абзацев и не думают переключаться.
Я включаю шаблоны, как для бессистемных, так и для написанных по всей форме вариантов использования, чтобы подчеркнуть правомерность выбора.
Абзацы являются выбором по умолчанию и в обычных шаблонах, и в шаблоне технологии Rational Unified Process (см. вариант использования 32). Если хотите, можете нумеровать шаги, как в этом варианте использования. Я почти всегда применяю нумерацию, даже если все остальное в варианте использования написано не по форме, поскольку считаю, что нумерация помогает исследовать поведение.
Полная форма требует нумерации.
7.3. Упражнения.
Шаги действия.
7.1. Напишите сценарий одного из ваших вариантов использования двумя способами: с подробным описанием интерфейса и с помощью описания намерений. Обсудите различия между сценариями.
7.2.
Напишите основной сценарий для варианта использования уровня задачи Извлечение денег с помощью режима Быстрое получение наличных.
7.3.
Напишите основной сценарий для одного стратегического варианта использования и одного варианта использования уровня задачи для системы персонального консультанта по финансам (PAF).
7.4.
Молодой коллега прислал вам нижеследующий вариант использования. Учитывая изученный к настоящему моменту материал, пошлите ему в ответ критические замечания и исправления.
Вариант использования Войти в систему.
Этот вариант использования описывает процесс, с помощью которого.
пользователи входят в систему обработки заказов. В нем также.
устанавливаются права доступа для различных категорий пользователей.
Поток событий:.
Основной путь:.
1.
Вариант использования запускается, когда пользователь запускает приложение.
2.
Система покажет экран для входа.
3.
Пользователь вводит имя и пароль.
4.
Система проверит информацию.
5.
Система установит права доступа.
6.
Система покажет основной экран.
7.
Пользователь выберет функцию.
8.
Пока пользователь не выберет Выйти из цикла.
9.
Если пользователь выберет Разместить заказ, использовать Разместить заказ.
10.
Если пользователь выберет Вернуть товар, использовать Вернуть товар.
11.
Если пользователь выберет Снять заказ, использовать Снять заказ.
12.
Если пользователь выберет Получить статус заказа, использовать Получить статус.
13.
Если пользователь выберет Выслать каталог, использовать Выслать каталог.
14.
Если пользователь выберет Зарегистрировать жалобу, использовать Зарегистрировать жалобу.
15.
Если пользователь выберет Выдать отчет по продажам, использовать Выдать отчет по продажам. Конец проверки если.
16.
Пользователь выберет функцию. Конец цикла.
17.
Вариант использования завершается.