Вариант использования Работать с приложением.
Уровень: обобщенный (белый).
Предусловие: отсутствует.
1.
Служащий входит в систему.
2.
Служащий размещает заказ.
Вариант использования Войти в систему.
Уровень: подфункция (индиго).
Предусловие: отсутствует.
Вариант использования Разместить заказ.
Уровень: цель пользователя (голубой).
Предусловие: служащий вошел в систему. ...
Не все следуют моему правилу писать более высокий вариант использования, чтобы собрать варианты использования более низкого уровня. Таким образом, вы можете включить в предыдущий пример только варианты использования Войти в систему и Разместить заказ. Вы должны уметь вывести из документа, что предусловие правильно и будет обязательно выполнено.
Продолжим этот пример, чтобы показать вариант использования, устанавливающий условие в одном шаге и полагающийся на это условие в подчиненном варианте использования. И опять подчиненный вариант использования рассчитан на то, что условие истинно, и не будет поверять наличие ошибок.
Вариант использования Разместить заказ.
Уровень: цель пользователя (голубой).
Предусловие: служащий вошел в систему.
1.
Служащий идентифицирует клиента, система находит данные пользователя.
2.
Служащий вводит информацию о заказе.
3.
Система рассчитывает расценки.
Вариант использования Рассчитать расценки.
Уровень: подфункция (индиго).
Предусловие: клиент установлен и известен системе; содержимое заказа известно.
1.
Система рассчитывает базовую расценку для заказа.
2.
Система рассчитывает скидку для клиента.
Этот пример иллюстрирует, как один вариант использования полагается на информацию, фиксируемую в вызывающем варианте использования. Автор варианта использования Рассчитать расценки объявил информацию, которая уже имеется, и теперь может двигаться вперед и обращаться к данным клиента.
Внимательный читатель недоверчиво отнесется к варианту использования Рассчитать расценки. Я сказал, что он цвета индиго, но до сих пор неясно даже, является ли он самостоятельным вариантом использования. Если я как автор не раскрою сложных взаимодействий с пользователем или интересных случаев отказа, я переклассифицирую его как черный (пиктограмма моллюска). Это послужит сигналом включить этот текст обратно в вариант использования Разместить заказ и уничтожить вариант использования Рассчитать расценки.
Пишите предусловие как простое утверждение о состоянии окружающей среды на момент открытия варианта использования. Вот некоторые примеры используемых предусловий:.
Предусловие: пользователь вошел в систему.
Предусловие: клиент идентифицирован.
Предусловие: система уже локализовала данные полиса клиента.
Распространенной ошибкой является записывать в предусловие утверждение, которое часто, но не обязательно бывает истинным.
Допустим, мы пишем вариант использования Затребовать сводку по вознаграждениям с заявителем в качестве основного действующего лица. Логично предположить, что заявитель подал по крайней мере одно заявление или счет, прежде чем просить вьщать ему сводку вознаграждений. Однако это не всегда так. Система не может это гарантировать, и на самом деле это несущественно. Заявителям следует предоставить возможность потребовать сводку их вознаграждений в любое время, поэтому неправильно было бы написать предусловие Заявитель подал счет.
6.2. Минимальные гарантии.
Минимальные гарантии — это наименьшие обещания системы участникам, в Частности, если цель основного действующего лица не может быть достигнута. Конечно, они действительны и при достижении цели, но реальный к ним интерес возникает, если основная цель не может быть выполнена. Большую часть времени два или более участников вынуждены иметь дело с минимальными гарантиями, например пользователь, компания, поставляющая систему, и, возможно, органы государственного управления.
Не старайтесь перечислить в разделе Минимальные гарантии все возможные для данного варианта использования пути отказа. Существуют десятки путей, и они имеют мало общего. Все условия отказа и обработка отказов раскрываются в разделе расширений, и поддерживать синхронизацию этих двух списков утомительно и одновременно чревато ошибками. Задача этого раздела шаблона — объявить то, что обещает система.
Наиболее распространенной минимальной гарантией является следующая: “Сис- • тема зарегистрировала точку, до которой она продвинулась”. Регистрация сбоев тран- ( закций не является ни очевидной, ни тривиальной. В описании требований часто забы-1 вают о системных журналах, а потом программисты могут о них вспомнить. Однако f они чрезвычайно важны как для владельцев системы, так и для ее пользователей. Сис- [ тема использует журнал, чтобы продолжить транзакцию после восстановления нормальных условий работы; участникам он нужен для урегулирования спорных вопросов. • Автор варианта использования должен определить, насколько необходимо использовать журнал, выяснив интересы участников либо хорошо обдумав условия отказов.
Минимальные гарантии записываются в виде ряда простых утверждений, которые будут истинны по окончании каждого варианта использования. Они показывают,; что интересы каждого участника удовлетворены.
Минимальные гарантии: заказ будет инициирован только по получении оплаты.
Минимальные гарантии: если не был зафиксирован минимум информации, неполное заявление отклоняется, и регистрация заявления не проводится; если был зафиксирован минимум информации (см. бизнес-правила), неполное заявление будет | сохранено и зарегистрировано.
Тест “прошел/не прошел” для раздела минимальной гарантии состоит в том, что 1 участники соглашаются с тем, что их интересы защищены при возникновении уело- J вий отказа для данной цели.
6.3. Гарантия успеха.
Гарантия успеха устанавливает, что интересы участников удовлетворяются при ; успешном завершении варианта использования в конце основного сценария или в конце успешного альтернативного пути. Обычно она пишется в добавление к минимальным гарантиям: предоставляются минимальные гарантии и выполняются не-: которые дополнительные условия. Эти дополнительные условия включают по • крайней мере цель, объявленную в заголовке варианта использования.
Подобно минимальным гарантиям, гарантия успеха записывается как набор простых утверждений, которые применяются в конце успешного выполнения вариан-
та использования и показывают, что интересы каждого участника удовлетворены. Например:
j
Тест “прошел/не прошел” для раздела гарантии успеха состоит в том, что участ ники соглашаются с тем, что их интересы удовлетворены.
Лучший способ раскрыть гарантию успеха — это спросить: “Что сделало бы этого участника несчастным по окончании успешного выполнения варианта использования?” На этот вопрос обычно легко ответить. Затем напишите отрицание ответа. Чтобы посмотреть пример, выполните упражнение 6.4, а потом прочтите обсуждение этой темы в приложении В.
6.4.
Триггеры.
Триггер определяет событие, которое запускает вариант использования. Иногда триггер предшествует первому шагу варианта использования, в другой раз сам является первым шагом. До настоящего времени я не встречал убедительного доказательства, что одну форму можно применять во всех случаях. Также я не замечал, чтобы возникала путаница, если предпочесть один способ другому. Вам придется обучать ваш персонал или совершенствовать стиль проектирования.
Будем считать, что система банкомата начинает работать, только когда пользователь вставляет в банкомат свою карточку. Таким образом, не имеет смысла говорить, что триггер имеет место, когда кто-то решает использовать банкомат. Триггер Клиент вставляет карточку является также первым шагом варианта использования.
Вариант использования Работать с банкоматом.
Триггер: клиент вставляет карточку.
1.
Клиент вставляет карточку с идентификатором банка, номером счета и закодированным PIN-кодом.
2.
Система проверяет...
Теперь рассмотрим пример со служащим, сидящим целый день за рабочей станцией, на экране которой имеется набор пиктограмм для запуска различных прикладных программ. Триггер — это то, что клиент вызывает с помощью конкретного запроса, который можно выразить в любой форме. Для иллюстрации я напишу его вторым способом.
Вариант использования Зарегистрировать жалобу.
Триггер: клиент обращается с рекламацией.
1.
Служащий вызывает приложение.
2.
Система выводит последний вариант списка рекламаций для служащего.
6.5.
Упражнения.
Минимальные гарантии.
6.1. Напишите минимальную гарантию для извлечения денег из банкомата.
6.2.
Напишите минимальную гарантию для главного варианта использования системы PAF (персональный консультант по финансам описан в упражнении 4.4).
6.3.
Напишите минимальную гарантию для варианта использования уровня моря вашей текущей системы. Покажите ее коллегам и предложите им проанализировать ее с точки зрения интересов участников.
Гарантии успеха.
6.4.
Напишите гарантию успеха для извлечения денег из банкомата.
6.5.
Напишите гарантию успеха для главного варианта использования системы PAF.
6.6.
Напишите гарантию успеха для варианта использования уровня моря вашей текущей системы. Покажите ее коллегам и предложите им проанализировать ее с точки зрения интересов участников.