Содержимое прецедентов

Не существует стандартного способа описания содержимого прецеден­та; в разных случаях применяются различные форматы. На рис. 9.1 по­казан общий стиль использования. Вы начинаете с выбора одного из сценариев в качестве главного успешного сценария (main success sce­nario). Сначала вы описываете тело прецедента, в котором главный успешный сценарий представлен последовательностью нумерованных шагов. Затем берете другой сценарий и вставляете его в виде расшире­ния (extension), описывая его в терминах изменений главного успешно­го сценария. Расширения могут быть успешными - пользователь достиг своей цели, как в варианте За, или неудачными, как в варианте 6а.

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

Каждый шаг в прецеденте - это элемент взаимодействия актера с систе­мой. Каждый шаг должен быть простым утверждением и должен четко указывать, кто выполняет этот шаг. Шаг должен показывать намере­ние актера, а не механику его действий. Следовательно, в прецеденте интерфейс актера не описывается. Действительно, составление преце­дента обычно предшествует разработке интерфейса пользователя

Рис. 9,1. Пример текста прецедента

Расширение внутри прецедента указывает условие, которое приводит к взаимодействиям, отличным от описанных в главном успешном сце­нарии (main success scenario, MSS), и устанавливает, в чем состоят эти отличия. Расширение начинается с имени шага, на котором определя­ется это условие, и предоставляет краткое описание этого условия. Следуйте этому условию, нумеруя шаги таким же образом, что и в главном успешном сценарии. Заканчивайте эти шаги описанием точ­ки возврата в главный успешный сценарий, если это необходимо.

Структура прецедента - это отличный инструмент для поиска альтер­натив главного успешного сценария. На каждом шаге спрашивайте: «Что может еще произойти?» и в частности «Что может пойти не так?» Обычно лучше сначала изучить все возможные условия расширения, чтобы потом не увязнуть в трясине работы над последствиями. Таким образом, вы, возможно, обдумаете больше условий, что приведет к мень­шему количеству ошибок, которые потом пришлось бы отлавливать.

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

включение прецедента, но я думаю, что подчеркивание, которое пред­полагает гиперссылку, работает прекрасно, а во многих инструментах действительно будет гиперссылкой. Так, на рис. 9.1 первый шаг вклю­чает шаблон «просматривает каталог и выбирает товары для покупки».

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

Наряду с шагами сценария можно вставить в прецедент дополнитель­ную общую информацию.

• Предусловие (pre-condition) описывает действия, обязательно вы­
полняемые системой перед тем, как она разрешит начать работу
прецедента. Это полезная информация, позволяющая разработчи­
кам не проверять некоторые условия в их программе.

• Гарантия (guarantee) описывает обязательные действия системы по
окончании работы шаблона ответа. Успешные гарантии выполня­
ются после успешного сценария; минимальные гарантии выполня­
ются после любого сценария.

• Триггер (trigger) определяет событие, инициирующее выполнение
прецедента.

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

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