Расширения

Расширения

В вариант использования должны входить все сценарии, как успешные, так и приводящие к неудаче. Мы также обсудили, как писать основной сценарий. Теперь надо узнать, как добавить к нему все остальные.
Можно написать каждый сценарий отдельно. Это соответствовало бы “полосатым брюкам” (см. рис. 2.2). Этот подход время от времени пропагандируют, и некоторые инструменты подталкивают писателя идти этим путем. Однако сопровождение “полосатых брюк” — трудная задача (см. главу 2). Каждое изменение в сценарии должно быть скопировано во все остальные сценарии, содержащие тот же текст.
Второй способ — вставлять предложения с если на протяжении всего текста: "Если пароль верный, система делает так..., в противном случае этак...". Это абсолютно законно, некоторые так и пишут. Но читателям приходится нелегко с этими если, особенно когда одно предложение с если находится внутри другого. Читатели теряют нить уже после двух веток с если, а большинство вариантов использования имеют много точек ветвления.
Третий способ создать этот текст — написать основной сценарий как простую последовательность действий от запуска до завершения, а затем написать расширение сценария для каждой точки ветвления. Это, пожалуй, лучший из трех способов.
8.1. Расширение. Основные положения.
Расширения работают так. Вслед за основным сценарием для каждой точки, в которой поведение может идти по различным сценариям вследствие определенного условия, запишите это условие, а потом управляющие им шаги. Часто расширение заканчивается воссоединением с основным сценарием.
Расширение на самом деле — это спуск вниз по варианту использования. Оно запускается при возникновении условия, которое делает его релевантным. Оно содержит последовательность шагов действия, описывающих, что происходит при этом условии, и заканчивается достижением цели или отказом от нее. По пути могут встретиться и расширения к расширениям, обрабатывающие предложения с если и но.
Эти расширения возникают там, где находятся наиболее интересные требования к системе. Основной сценарий разработчикам часто известен. При обработке отказов нередко используются бизнес-правила, которые разработчики не знают. Авторам описания требований приходится выяснять правильные реакции системы, и довольно часто при таком исследовании вводится новое действующее лицо, новый вариант использования или новое условие расширения.
Ниже приведена типичная дискуссия, иллюстрирующая это утверждение. “Предположим, что сеть неожиданно отказала. Что мы делаем?” “Система регистрирует это”.
“Принято. Но если сеть прекратила работать, что будет, когда она заработает снова?”.
“Мы должны добавить новый вариант использования для повторного запуска системы после отказа сети. Система восстановится, откроет журнал и либо завершит транзакцию, либо ее отменит”.
“Но что если журнал будет поврежден? Что тогда будет делать система?”.
“Не знаю. Давайте запишем это как открытый вопрос и продолжим”.
В этом диалоге обнаруживается новый вариант использования, а также необходимость исследовать стратегию бизнеса. Не обманывайте себя, полагая, что не нужно обсуждать эти расширения. Какой-нибудь программист в проекте, разрабатывая программу, натолкнется на те же условия, и очень дорогое время будет потрачено на открытие и изучение новых бизнес-правил. Лучше всего этим заниматься на этапе сбора требований к системе.
Рекомендую организовать работу в три этапа:.
1.
Хорошо поразмыслите и включите каждую возможность, которую вы только можете вообразить.
2.
Оцените, исключите и объедините идеи в соответствии с правилами, изложенными в разделе 8.2.
3.
Продумайте, как пробраться через все эти системные обработки условий.
8.2. Условия расширения.
Условия расширения — это условия, при которых изменяется поведение системы. Мы говорим расширение в противоположность неудаче или исключительной ситуации, чтобы наряду с условиями неудачи включить альтернативный сценарий успеха.
Здесь представлены два фрагмента, иллюстрирующие путь успеха и путь неудачи в расширениях.
Пример 1.
4.
Пользователь дает системе команду сохранить наработанное на текущий момент.
Расширения.
4а. Система автоматически обнаруживает необходимость немедленного сохранения:.
4а1. ...
4Ь. Сохранение завершается неудачей:.
4Ы. ...
Вышеприведенный пример можно истолковать так: вместо того чтобы сохранить текущее состояние данных по требованию пользователя, система может автоматически обнаружить необходимость немедленного сохранения. В этом случае ... (что-то делается). Сохранение (по требованию пользователя или автоматическое) может закончиться неудачно. В этом случае ... (делается что-то еще).
Пример 2.
3.
Система сканирует документ, сверяя правописание каждого слова со словарем.
4.
Система обнаруживает орфографическую ошибку, выделяет слово и предоставляет на выбор пользователю альтернативы.
5.
Пользователь выбирает одну из замен. Система замещает выделенное слово другим, выбранным пользователем для замены.
Расширения.
4а. Система не обнаруживает больше орфографических ошибок до конца документа:.
4а 1. Система уведомляет пользователя и завершает выполнение варианта использования.
5а. Пользователь решает сохранить первоначальное написание:.
5а 1. Система оставляет слово и продолжает работу.
5Ь. Пользователь набирает новое написание, не входящее в список:.
5Ы. Система проверяет новое написание и возвращается на шаг 3.
Выявляйте все возможные ошибки и альтернативные пути.
Очень важно максимально охватить условия расширения, прежде чем писать, как их обрабатывать. Это утомительная работа, как и документирование обработки расширений. На то, чтобы продумать только одно расширение и сделать правильные выводы о работе системы, уходит много сил, не говоря уже о 3-4 расширениях. Это значит, что вы не будете обдумывать следующую порцию условий расширения. А это следует сделать.
Если вы выявите все альтернативные ситуации успехов и неудач, у вас будет список, который послужит основой для вашей дальнейшей работы в течение нескольких часов или дней. Вы можете сделать перерыв и вернуться к тому месту, где закончили.
Выявите все возможные пути, которые приводят к неудачному завершению сценария, и альтернативные пути, ведущие к успеху. Убедитесь, что не пропустили ни один из них:.
■ Альтернативный путь к успеху.
(служащий использует клавишу быстрого вызова).
■ Основное действующее лицо действует некорректно (неверный пароль).
■ Бездействие основного действующего лица (истечение времени ожидания пароля).
■ Каждое появление предложения “система подтверждает” означает, что последует расширение, обрабатывающее неподтверждение (неверный учетный номер).
■ Несоответствующая реакция второстепенного действующего лица или ее отсутствие (истечение времени ожидания ответа).
■ Внутренняя ошибка в разрабатываемой системе, которая должна быть обнаружена и обработана в обычном порвдке.
(заблокирован автомат для выдачи наличных).
■ Неожиданная и необычная ошибка, которую необходимо обработать, и которая будет иметь видимый результат.
(обнаружено повреждение журнала транзакций).
■ Критически важные недостатки в производительности системы, которые вы должны обнаружить (время реакции не укладывается в 5 с).
Часто люди анализируют шаги от начала сценария до его конца, чтобы гарантировать максимальный охват всех условий. Если вы поступите так же, количество вещей, которые могут выйти из строя, удивит вас. Упражнение 8.1 даст вам возможность попытаться выявить ряд ошибок. Ответ вы найдете в приложении В., Двое учащихся моего курса назвали почти в три раза больше ошибок, чем дано в от-1 вете. Насколько преуспеете вы? j.
Правило 11. Пусть условие само указывает, что было обнаружено ;.
Запишите, что обнаружила система, а не просто, что произошло. Не пишите: "Кли- j ент забывает PiN-код". Система не может обнаружить это. Возможно, клиент ] ушел, с ним случился сердечный приступ или он успокаивает плачущего младенца.
< Система в этом случае обнаруживает бездействие, что означает превышение временного предела. Напишите: "Предел ожидания ввода PIN-кода превышен" или "Истекло время ожидания PIN-кода".
Условием часто служит выражение, описывающее то, что было обнаружено.: Мне нравится ставить двоеточие (:) в конце условия, чтобы читатель не принимал.
условие за шаг действия. Это соглашение предотвращает много ошибок. Вот несколько примеров:.
Неверный PIN-код:.
Сеть не работает:.
Клиент не отвечает (время ожидания ответа истекло):.
Деньги не выдаются надлежащим образом:.
Если вы используете нумерованные шаги, напишите номер шага, где может быть обнаружено условие, и сопроводите номер буквой (скажем, 4а). Буквы не связаны какой-либо последовательностью, поэтому условие 4Ь не обязательно должно следовать за 4а. Это позволяет присоединить сколько угодно условий расширения к любому шагу действия.
2а. Недостаточно финансовых средств:.
2Ь. Сеть не работает:.
Если условие может возникнуть на нескольких шагах и вам представляется важным указать на это, перечислите эти шаги:.
2-5а. Пользователь неожиданно прекратил работу:.
Если условие может возникнуть в любое время, используйте знак звездочки (*) вместо номера шага. Сначала перечисляйте условия со звездочкой, затем нумерованные.
*а. Сеть перестает работать:.
*Ь. Пользователь ушел без уведомления (время ожидания ответа истекло):.
2а. Недостаточно финансовых средств:.
2Ь. Сеть не работает:.
Не беспокойтесь о том, в каком участке происходит ошибка: на шаге ввода пользователем данных или на следующем, где система подтверждает данные. Некоторые утверждают, что ошибка возникает в любом месте, но на этот довод не стоит тратить время. Обычно я связываю ошибки с шагом подтверждения, если таковой присутствует.
Когда вы пишете обычными абзацами без нумерации шагов, вы не можете обращаться к определенному шагу, в котором возникает условие. Поэтому сделайте условие наглядным, чтобы читатель знал, когда оно может возникнуть. Перед каждым условием пропустите строку или сделайте пробел и выделите условие, например курсивом (см. вариант использования 32).
■ Невымышленная история.
Когда-то я участвовал в работе над серьезным проектом. К сожалению, мы не слишком тщательно продумали расширения.
Подобно многим разработчикам, мы не захотели рассматривать, что случится, если программа натолкнется в базе данных на неверную информацию. Каждый из нас надеялся, что другая команда позаботится об этом. Вы догадываетесь, что произошло? Через неделю после первой сдачи первой очереди проекта вице-президент решил посмотреть, как один из его заказчиков использует новые способы продвижения товара. Он запустил свою новенькую систему и запросил данные по этому крупному заказчику. Система ответила, что данные не найдены. Его состояние трудно было описать. Высшее звено персонала в полном составе было собрано на экстренное совещание, чтобы решить, что делать с ошибками в базе данных. Мы обнаружили, что в базе была только одна неверная секция, поэтому сообщение об ошибке должно было быть таким: "Некоторые данные пропущены". Хуже было другое — мы упустили из вида, что реакция системы при обнаружении неверных внутренних данных на самом деле есть часть внешних требований к ней.
Мы переделали проект системы, чтобы она оптимально справлялась с не- полными данными и выдавала как наилучшие возможные результаты, так и сообщение о том, что некоторые данные пропущены.
Вывод из этой истории состоит в том, что необходимо рассматривать внутренние ошибки, такие как пропущенные данные.
О списке выявленных условий.
Ваш список выявленных условий будет содержать больше идей, чем вы будете в ко-: нечном счете использовать, и это нормально. Смысл упражнения в том, чтобы по- j пытаться охватить все ситуации, которые когда-либо встретит система в этом j варианте использования. Позже вы сократите список.
В этой точке ваш список, вероятно, еще не полон. Вы, возможно, думаете о новом условии ошибки, когда пишете сценарий расширения или добавляете новый шаг; подтверждения где-то внутри варианта использования. Не беспокойтесь об этом.
< Тщательно выполняйте работу на этой стадии анализа и пополняйте список в про-! цессе работы.
I.
Совершенствуйте список расширений.
Цель совершенствования — сделать список расширений максимально коротким. Идеальный список условий расширения показывает все ситуации, которые система должна обрабатывать. Помните, что длинный документ, содержащий требования к системе, всегда тяжело читается, а избыточные описания сложно сопровождать. Объединяя условия расширения, вы сокращаете документ и время его чтения.
Проведя тщательный анализ, вы должны получить короткий и простой основной сценарий и длинный список условий, которые предстоит рассмотреть. Внимательно просмотрите список, удаляя те условия, которыми система не должна управлять, и объединяя те, которые оказывают на систему одинаковое результирующее воздействие. Используйте два критерия:.
■ Система должна быть способна обнаруживать это условие.
■ Система должна обрабатывать обнаружение условия.
Попробуйте сделать необнаруживаемые условия обнаруживаемыми, прежде чем их удалять. Удалите условие "Клиент забыл карточку для банкомата", поскольку не существует эквивалентного условия, которое система способна обнаружить. Преобразуйте необнаруживаемое условие "Клиент забыл PIN-код" в условие "Истекло время ожидания ввода PIN-кода", которое система сможет определить.
Затем объедините эквивалентные условия. Вы могли бы написать, что карточка поцарапана, считывающее устройство неисправно, карточка не является карточкой для банкомата. С точки зрения требований поведение банкомата будет одинаковым: "Возвратить карточку и уведомить клиента". Поэтому попробуйте объединить эти условия. Постарайтесь найти одно осмысленное предложение для всех, можно построить распространенное предложение: "Карточка не читается или предназначена не для банкомата".
Свертывайте ошибки.
Какчасть объединения условий, производящих одинаковое воздействие, объединяют ошибки вариантов использования более низкого уровня, имеющие одинаковый результирующий эффект на вариант использования более высокого уровня. Это свертывание ошибок более низкого уровня дает возможность избежать лавины условий расширения на более высоких уровнях.
Предположим, что вы работаете над пакетом PAF и пишете вариант использования уровня цели Обновить инвестиции. Пусть один из последних шагов таков:.
Вариант использования Обновить инвестиции.
7.
Пользователь дает команду PAF сохранить текущее состояние данных.
8.
...
Это обращение вызывает вариант использования Сохранить текущее состояние данных, который содержит условия такого рода:.
Вариант использования Сохранить текущее состояние данных.
Расширения:.
За. Файл уже существует (пользователь не желает его перезаписывать):.
ЗЬ. Директория не найдена: ...
4а. Не хватает места на диске: ...
4Ь. Файл защищен от записи: ...
... и т.д. ...
Вариант использования Сохранить текущее состояние данных завершается успехом либо неудачей, возвращающей выполнение в конец шага 7 варианта использования Обновить инвестиции. В случае успеха выполнение продолжается с шага 8. Но что если сохранение заканчивается неудачей? Что нужно написать в расширении 7а? Читателя варианта использования Обновить инвестиции не интересует, почему сохранение не удалось (все неудачи имеют один и тот же результирующий эффект), поэтому в вариант использования Обновить инвестиции включите только одно расширение, описывающее, что произошло.
Вариант использования Обновить инвестиции.
7.
Пользователь дает команду PAF сохранить текущее состояние данных.
8.
...
Расширения:.
7а. Сохранение произвести не удалось:.
7а1. ... все, что должно произойти потом...
Лучше всего в свертывании ошибок то, что даже на самом высоком уровне варианта использования терминология сообщений об ошибках соответствует этому уровню. Даже занятые руководители найдут время прочитать их, потому что сообщения в варианте использования очень высокого уровня тоже вполне высокого уровня.
8.3. Обработка расширений.
В простейшем случае условие обрабатывает базовая последовательность шагов. Однако обычно расширение представляет собой миниатюрный вариант использования. Триггером служит условие расширения; цель —достичь цели варианта использования либо возобновить выполнение после произошедшей ошибки. Тело является набором шагов действия и, может быть, их расширениями. Расширение может завершаться достижением цели или отказом от нее, совсем как в варианте! использования. Сходство не случайно, и это очень удобно с точки зрения рациональной формы описания сложных расширений.
Начинайте описывать обработку условия с шага действия, который следует за; обнаруживаемым условием. Нет необходимости повторять, что было обнаружено} условие. Продолжайте повествование точно так же, как и при создании основного] сценария, соблюдая все правила для уровня цели, стиля и предложений, которые] мы рассматривали ранее. Пишите, пока не достигнете места, где можно воссоеди-
ниться с основным сценарием, или пока вариант использования не закончится неудачей.
!.
Обычно фрагмент сценария завершается одним из следующих способов: j.
Шаг, порождающий расширение, зафиксирован и заменен. В конце обработки; расширения положение таково, как если бы шаг был успешным.
3.
Пользователь активизирует URL web-сайта.
4.
...
Расширения:.
За.Нет доступного URL:.
За1. Пользователь ищет web-сайт.
ЗЬ. ...
Система предоставляет действующему лицу еще один шанс. В конце обработки расширения действие возвращается в начало того же шага. В следующем примере обратите внимание, что система повторно подтверждает пароль:.
3.
Пользователь вводит пароль.
4.
Система подтверждает пароль.
5.
...
Расширения:.
4а. Неверный пароль:.
4а1. Система уведомляет пользователя, снова запрашивает пароль. 4а2. Пользователь повторно вводит пароль.
4Ь. ...
Вариант использования завершается ввиду
полного отказа.
3.
Пользователь вводит пароль.
4.
Система подтверждает пароль.
5.
...
Расширения: ...
4с. Превышен предел попыток ввода пароля:.
4с1. Система уведомляет пользователя, прекращает сеанс.
5а. ...
Чтобы достигнуть цели, действие развивается по совершенно другому пути.
3.
Пользователь делает...
4.
Пользователь делает...
5.
...
Расширения:.
За. Пользователь запускает персональную макрокоманду, чтобы завершить процесс:.
За1. Вариант использования завершается.
В двух первых вариантах использования не нужно указывать, что происходит потом в расширении, так как для читателя очевидно, что этот шаг будет запущен снова или продолжен. В последних двух случаях достаточно сказать о неудаче или о завершении варианта использования, поскольку шаги показывают, что интересы участников соблюдены.
В большинстве расширений не говорится о том, по какому пути пойдет действие по окончании расширения. Обычно это очевидно, а если писать после каждого расширения “Перейти к шагу N”, текст будет перегружен, что плохо для читателя. В редких случаях, когда не ясно, что действие перепрыгивает на другой участок основного сценария, в конечном шаге можно записать: “Перейти к шагу N”.
Примеры каждой из таких ситуаций можно найти в этой книге в различных образцах вариантов использования.
Правило 12. Делайте отступы в тексте обработки условия.
Используя стиль с нумерацией, демонстрируемый в этой книге, делайте отступы для шагов действия, которые указывают, как обрабатывается условие, и начинайте повторную нумерацию с 1 после буквы. Шаги действия следуют всем ранее описанным правилам стиля.
Расширения:.
2а. Недостаточно финансовых средств:.
2а 1. Система уведомляет клиента, предлагает ввести другую сумму. 2а2. Клиент вводит новую сумму.
Перед сдачей этой книги в печать Волкер Хеймер из компании Software Futures ССН описал соглашение, упрощающее нумерацию. Разработчики его фирмы опускают лидирующую комбинацию номер-буква, начиная непосредственно с точки, за которой следует номер. Приведенный выше пример будет выглядеть так:.
2а. Недостаточно финансовых средств:.
.1. Система уведомляет клиента, предлагает ввести другую сумму.
.2. Клиент вводит новую сумму.
Преимущество этого способа в том, что при изменении нумерации, Например, когда шаг 2 станет шагом 3, перенумеровать шаги расширения значительно проще. Есл ! вы пишете без нумерации, делайте отступы либо начинайте каждый шаг действия с аб-; заца. Шаблон Rational Unified Process имеет специальный уровень заголовка для уело- J вия расширения, причем шаги действия записываются как текст под этим заголовком. |.
Ошибки внутри ошибок I.
Внутри фрагмента сценария обработки расширения вы можете встретить новое I условие ветвления, возможно, ошибку. Если вы придерживаетесь стиля формата- j рования с отступами, как в данной книге, сделайте еще один отступ и продолжайте j называть условия и писать сценарий, как прежде. В какой-то точке отступы и нуме- j рация станут такими сложными, что вы решите превратить все расширение в еще ! один вариант использования. Большинство моих корреспондентов говорят, что это i случается примерно на третьем уровне отступов. Ниже приведен пример, взятый из j варианта использования 22.
=
6а1а. Служащий решает продолжить ввод данных по ущербу.
6а 1Ь. Служащий сохраняет "промежуточный" отчет и выходит из системы.
6а1с. Служащий настаивает на выходе без записи минимума информации:.
Система отвергает сохранение любых промежуточных версий и завершает выполнение.
Обратите внимание, что в этом примере разработчик не присвоил номер последней строке. На номере 6а 1 с 1 он решил, что расширение уже порядком загромождено и короткий фрагмент простого текста сделает чтение более удобным.
Вообще стоимость создания нового варианта использования достаточно высока, чтобы слишком долго не выделять расширение в самостоятельный вариант использования. Компромиссное решение состоит в том, что вышеприведенный пример существует, пока имеет смысл делать отступ, не выделяя его в самостоятельный вариант использования.
Создание из расширения нового варианта использования.
Чтобы выделить расширение в новый подчиненный вариант использования, определите цель основного действующего лица и соответственно назовите вариант использования, обозначьте его уровень (возможно, подфункция), откройте шаблон для нового варианта использования и запишите детали, которые вы перетащили из вызывающего варианта использования.
Возьмем для примера вариант использования 32. Он когда-то содержал шаг:.
Пользователь может сохранить или распечатать отчет в любой момент.
В нем есть ряд расширений, описывающих альтернативы и ситуации отказов, но их число постоянно росло: непоименованный отчет, уже существующее имя (заменять или не заменять), пользователь прекращает сохранение на середине, и.
т.д. Наконец, разработчики решили выделить Сохранить отчет в отдельный вариант использования.
В первоначальном варианте использования вы тем не менее должны учитывать, что новый подчиненный вариант использования может закончиться неудачей, поэтому ваш вариант, вероятно, будет включать условия как успеха, так и неудачи.
С точки зрения теории и затраченных усилий перемещать расширение в самостоятельный вариант использования и обратно достаточно просто. Модель варианта использования обеспечивает легкое решение. Переместить расширения Сохранить отчет из Управления отчетами не составляет труда, а чтобы вернуть их назад, нужно несколько минут работы в текстовом редакторе.
Однако создание варианта использования не ограничивается механическими усилиями. Новый вариант использования требуется помечать, отслеживать, планировать, тестировать и сопровождать. Для проектной группы это недешевые операции.
Вообще сохранение расширения внутри варианта использования определяется в основном экономическими соображениями. Две ситуации могут побудить вас создать новый вариант использования для расширения:.
■ Расширение используется в нескольких местах. Выделение его в собственный вариант использования означает, что отслеживать и сопровождать его можно будет только в одном месте. В идеальном случае это вообще единственная причина для создания варианта использования, уровень которого ниже уровня моря.
■ Расширение делает вариант использования трудным для чтения. Я считаю, что предел читабельности — около двух страниц текста варианта использования и три уровня отступов. (Мои варианты использования в основном короче, чем у других, поэтому ваша страница может быть длиннее.).
8.4. Упражнения.
Расширения.
8.1.
Перечислите то, что может отказать во время функционирования банкомата.
8.2.
Перечислите то, что может отказать в первом варианте использования уровня цели пользователя для системы обработки расширений PAF, персонального консультанта по финансам (см. упражнение 4.4).
8.3.
Напишите вариант использования Извлечь наличные, содержащий обработку ошибок с помощью предложений с если. Напишите его снова, на этот раз с расширениями сценария. Сравните два варианта.
8.4.
Найдите файл требований, написанный в форме, отличной от вариантов использования. Как он учитывает условия ошибок? Что вам нравится в каждом методе разработки, что полезного можно извлечь из этих наблюдений?.
8.5.
Напишите полный вариант использования для системы PAF, описывая шаги обработки ошибок (система PAF упоминается в упражнении 4.4).

Популярные статьи

Свежие статьи