Текст
                    ICrystal Collection для профессиональных разработчиков njX)rpaмMнoro обеспечения
jНаучный руководитель ПjЮeКТ3  Алистер Коберн
; овременные методы
· пнсання функцнональных
'требованнй к сне темам
.. .....
.\
\. .
I

i'"
...
\
& '"
,

"
"
..... 
Алистер Коберн


Writiпg effective иse cases (The Crysta! СоIIесtiоп for software рrоfеssiопа!s) Alistair СосkЬиrп Copyright @ 2001 Лl! l'ights reserved Современные методы описания функциональных требований к системам Алистер Коберн Переводчик Е. Борисова Научный редактор А. Вендров Корректор И. Красненкова Верстка И. Нarорновой CopYl'ight @ 2001 Ьу АddisопWеslеу Реаrsоп Еduсаtiоп Corporate Sales Divisiоп Опе Lake Stl'eet Uppel' Saddle Rivel', NY 07458 (800) 3823419 corpsales@pearsontechgroup ISBN 0201702258 @ Издательство "Лори", 2002 Изд. N2: ОА! (03) ЛР N2: 070612 30.09.97 [. ISBN 585582 1528 Подписано в печать 04.01.2002. Формат 70 х [00116 rарнитура Литературная Печать офсетная Печ. л. ] 8 Тираж 3200 Заказ.Ni.? 5800 Цена доrоворная Издательство "Лори". Москва 123557, Б. Тишинский пер., д. 40, корп.2 Телефон ДЛЯ оптовых покупателей: (095)25602.83 Размещение рекламы: (95)2590162 WWW.LORYPRESS.RU Отпечатано в полном соответствии с качеством предоставленных диапозитивов в ППП "Типоrрафия "Наука" 121099 Москва, Шубинский пер., 6 
Coвpe.мeuиыe .методы onuсаuuя ФYUIOJ,uоuatlьuых требоваuuй 1с системам Алисrер Коберн  Издательство "Лори" 
Содержание rлава 1. ВвеАение 1 1 . 1. Что такое варианты использования . . . . . . . . . . . . . . . . . . . . . . . . . 1 Вариант использования 1 Покупка ценных бумае через Ннтернет . . . . . . . . . . . . . . . . . . . . . . . . . 3 Вариант использования 2 Получить страховую компенсацию за автомобильную аварию. . . . . . 4 Вариант использования 3 Зарееистрировать привезенную коробку. . . . . . . . . . . . . . . . . . . . . . . . 6 1.2. У каждоrо свой вариант использования..................... 6 Вариант использования 4 Совершить покупку (бессистемная версия) . . . . . . . . . . . . . . . . . . . . . . 9 Вариант использования 5 Совершить покупку (полная версия). . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.3. Требования и варианты использования. . . . . . . . . . . . . . . . . . . . . 13 Приемлемая схема требований. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Варианты использования как структура связей проекта . . . . . . . . . . . . . . . 15 1.4. KorAa варианты использования повышают ценность проект а. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 1.5. Дозируйте свою энерrию . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 1.6. Разминка с помощью повествовательноrо стиля. . . . . . . . . . . . 19 1 .7. Упражнения........................................ 20 Описание использования. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 rлава 2. Вариант использования как соrлашение о повеАении 23 2.1. Взаимодействия действующих лиц, имеющих цели. . . . . . . . .23 Действующие лица имеют цели . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Целей можно и не достиrнуть. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 
vi Содержание Взаимодействие имеет составную структуру. . . . . . . . . . . . . . . . . . . . . . . . 25 Вариант ИСflOльзования как сборник сценариев . . . . . . . . . . . . . . . . . . . . . 27 2.2. Соrлашение между участниками, имеющими интересы .................... . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 2.3. rрафическая модель. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 r лава 3. Область Аействия 3.1. 34 3.2. Функциональная область действия. . . . . . . . . . . . . . . . . . . . . . . . . 35 Список Действующее лицо/Цель. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Краткие описания вариантов использования ....................... 36 Область действия проектирования . . . . . . . . . . . . . . . . . . . . . . . . . 37 Использование rрафических пиктоrрамм для выделения области действия проектирования . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 При меры области действия проектирования. . . . . . . . . . . . . . . . . . . . . . . . 40 ( 1 ) Область действия предприятие  система . . . . . . . . . . . . . . . 40 Вариант использования 6 Добавить новую услуеу (предприятие) ........................41 Вариант использования 7 Добавить новую услуеу (Acura) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .41 (2) Несколько компьютеров на одно приложение . . . . . . . . . . . . . 42 Вариант использования 8 Ввести и обновить запросы (объединенная система) . . . . . . . . . . . . . 42 Вариант использования 9 Добавить новую услуеу (в Асит). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Вариант использования 1 О Записать запрос на новую услуеу (в BSSO) . . . . . . . . . . . . . . . . . . . . . 43 Вариант использования 11 Обновить запрос на обслуживание (в BSSO) . . . . . . . . . . . . . . . . . . . . 43 Вариант использования 12 Записать обновленный запрос (в Асит) . . . . . . . . . . . . . . . . . . . . . . . . 44 (3) Варианты использования 'Тайки и БОJIТЫ" . . . . . . . . . . . . . . . 45 Вариант использования 1 3 Ореанизовать последовательный доступ к ресурсу. . . . . . . . . . . . . . . 46 Вариант использования 14 Применить политику преобразования блокировки ............... 47 Вариант использования 15 Применить политику совместимости доступа. . . . . . . . . . . . . . . . . . 48 Вариант использования 16 Применить политику выбора доступа. . . . . . . . . . . . . . . . . . . . . . . . . 48 
Содержание vii Вариант использования 17 Перевести клиент в режим ожидания доступа к ресурсу ...........49 3.3. Предельные варианты использования. . . . . . . . . . . . . . . . . . . . . . 50 3.4. Использование рабочих результатов определения области действия . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 3.5. Упражнения.............................................. 52 (лава 4. Участники и Аействующие лица 53 4.1. Участники................................................ 53 4.2. Основное действующее лицо. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 Почему основные действующие JIица бывают несущественны (и существенны). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 В начале создания вариантов использования. . . . . . . . . . . . . . . . . 55 Во время создания вариантов использования и во время проектирования . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 Завершение проекта, ПОДf'отовка к внедрению системы. . . . . . . . . 57 Действующие лица в сравнении с ролями. . . . . . . . . . . . . . . . . . . . . . . . . . 57 Диаrраммы UML и специализация Действующее лицо/Роль . . . . . 58 Характеристики основных действующих лиц. . . . . . . . . . . . . . . . . . . . . . . . 58 4.3. Вспомоrательные действующие лица. . . . . . . . . . . . . . . . . . . . . . 59 4.4. Разрабатываемая система. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .59 4.5. Внутренние действующие лица и варианты использования типа "прозрачный ящик" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 4.6. Упражнения.............................................. 60 (лава 5. Три поименованных уровня цели 62 5.1. Цели пользователя (rолубые, уровня моря) . . . . . . . . . . . . . . . 63 Два уровня rолубоrо. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 5.2. Обобщенный уровень (белый, облако или воздушный змей) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 Вариант использования 18 Выполнить операции со страховым полисом + . . . . . . . . . . . . . . . . . . . 66 5.3. Подфункции (индиrо или черный, подводный или моллюск) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 Обобщение уровней целей. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 5.4. Использование пиктоrрамм для выделения уровней целей. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 5.5. Выявление правильной цели пользователя. . . . . . . . . . . . . . . . . . 69 
viii Содержание Выявление цеJIИ пользователя. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 Повышение и flонижение уровней целей . . . . . . . . . . . . . . . . . . . . . . . . . . 70 5.6. Более ДЛИННЫЙ пример: "Обработка заявления" на нескольких уровнях ................................... 71 Вариант использования 19 Обработка заявления (бизнес) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 Вариант использования 20 Произвести оценку ущерба по заявлению. . . . . . . . . . . . . . . . . . . . . . . 73 Вариант использования 21 Обработка заявления (системы) + ...........................75 Вариант использования 22 Заресистрировать ущерб . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 Вариант использования 23 Найти что уе ; дно (постановка задачи) . . . . . . . . . . . . . . . . . . . . . . .81 5.7. Упражнения.............................................. 81 fлова 6. ПреАУСЛОВИЯ, триrrеры и rарантии 83 6. 1. Предусловия . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 Вариант использования Работать с приложением. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 Вариант использования Войти в систеАЩ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 Вариант использования Рассчитать расценки . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 6.2. Минимальные rарантии . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 6.3. rарантия успеха. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .86 6.4. Триrrеры................................................. 87 Вариант использования Работать с банкоматом. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .87 Вариант использования Зареcuстрировать жалобу. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 6.5. Упражнения.............................................. 87 r лава 7. Сценарии и шаrи 89 7. 1. Основной сценарий. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 Общая структура. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 Вариант использования Купить ценные бумаси через Ннтернет . . . . . . . . . . . . . . . . . . . . . . . . 90 
Содержание ix Тело сценария . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 7.2. Шаrи действия. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .92 Правила. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 Нумеровать или нет. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 7.3. Упражнения.............................................. 99 Вариант использования Войти в систему . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 fлава 8. Расширения 101 8.1. Расширение. Основные положения. . . . . . . . . . . . . . . . . . . . . . . 101 8.2. Условия расширения. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 Выявляйте все возможные ошибки и альтернативные пути . . . . . . . . . . . 103 О списке выявленных условий. . . . . . . . . . . . . . . . . . . . . . . . . . 106 Совершенствуйте список расширений . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 Свертывайте ошибки . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 Вариант использования Обновить инвестиции. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 Вариант использования "Сохранить текущее состояние данных" . . . . . . . . . . . . . . . . . . . . . . 107 Вариант использования Обновить инвестиции. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 8.3. Обработка расширений. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 Ошибки внутри ошибок. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 О Создание из расширения HOBoro варианта использования ............ 111 8.4. Упражнения............................................. 112 fлава 9. Изменения в технолоrии и данных 113 fлава 10. Связывание вариантов использования 115 10.1. Подчиненные варианты использования. . . . . . . . . . . . . . . . . . . . 115 10.2. Варианты использования расширений. . . . . . . . . . . . . . . . . . . . . 116 Вариант использования Редактировать документ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 Вариант использования Проверить орфоерафию .................................... 117 Вариант использования Найти синоним ........................................... 118 Вариант использования Изменить шаблон документа. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1]8 
х Содержание Коrда применять варианты использования расширения . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 1 0.3 . Упражнения. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 fлава 11. Форматы вариантов использования 120 11 . 1 . Разновидности форматов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 Полный формат . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 Вариант использования 24 Полный формат шаблона варианта использования <название>. . . . 120 Свободный формат. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 Вариант использования 25 Действительная ресистрация в системе (версия в свободном формате) ..................................... 122 Таблица в одну колонку. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 Таблица в две колонки. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 Стиль RtJP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 Вариант использования 26 Записаться на курсы ...................................... 125 Стиль с предложениями с если. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 Стиль с использованием языка Оккам. . . . . . . . . . . . . . . . . . . . . . . . . . . 128 Стиль диаrрамм . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 tJМLдиаrрамма варианта использования. . . . . . . . . . . . . . . . . . . . . . . . . 129 11.2. Факторы, влияющие на стиль варианта использования. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 Уравновешивающие факторы: установки бизнеса, общественные отношения, конфликтующие подходы. . . . . . . . . . 130 Уровень понимания . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 Потребности участников. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 Опыт против формализма. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 Охват . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 Непротиворечивость. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 Сложность. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 Противоречие. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 Завершенность. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 Цели в сравнении с задачами  что выполнять или как это выполнять . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 Ресурсы. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 Друrие факторы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 11.3. Стандарты для пяти типов проектов. . . . . . . . . . . . . . . . . . . . . . . 133 ДЛя выявления требований. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 
Содержание xi Вариант использования 27 Шаблон выявления  стрямкать новую бутявку .............. 134 Для моделирования бизнеспроцесса . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 Вариант использования 28 Шаблон бизнесспроцесса  достиенуть успешноео функционирования компании . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 Для определения объема требований к системе. . . . . . . . . . . . . . . . . . . . 136 Вариант использования 29 Шаблон для определения объема  определить объем требований к системе ..................................... 136 Для небольшоrо проекта, который следует завершить в очень сжатые сроки. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 Вариант использования 30 Очень сжатый шаблон: добыть бананан . . . . . . . . . . . . . . . . . . . . . . 136 Для детальных функциональных требований. . . . . . . . . . . . . . . . . . . . . . . 137 Вариант использования 31 Название варианта использования  Оризовать позвение ........ 137 11.4. Заключение. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 11.5. Упражнения. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 Оказать услуry по чистке свечей зажиrания . . . . . . . . . . . . . . . . 138 (лава 12. KorAa считать работу завершенной 141 Korдa вы заканчиваете. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 (лава 13. Как работать с большим количеством вариантов использования 144 Сделать каждый вариант использования покороче (представление с низким уровнем точности). . . . . . . . . . . . . . . . . . . . . . . 144 Создать rруппы вариантов использования . . . . . . . . . . . . . . . . . . . . . . . . 144 (лава 14. CRUD и параметризованные варианты использования 146 14.1. Варианты использования CRUD . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 Вариант использования 32 Управление отчетами ..................................... 147 Вариант использования 33 Сохранить отчет. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 14.2. Параметризованные варианты использования. . . . . . . . . . . . . 152 
юi Содержание (лава 15. МОАелирование бизнеспроцессов 154 15.1. Моделирование или проектирование.. . . . . . . .. . . . . . . . . . . . . 154 Работа в напраВJlении от OCHoBHoro бизнеса. . . . . . . . . . . . . . . . . . . . . . . 155 Работа в направлении от бизнеСllрOlесса к теХНОJI01'ИИ. . . . . . . . . . . . . . 156 Работа в направлении от теХНОJIOI'ИИ к бизнеСllроцессу.............. 158 15.2. Связывание вариантов использования для бизнеса и для системы. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 МодеJlИрование бизнеСllроцессов и требования к системе. . . . . . 160 Мой предыдущий опыт. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 Опыт, полученный после прочтения КНИl'и . . . . . . . . . . . . . . . . . 161 (лава 16. Пропущенные требования 162 16.2. Перекрестные ссылки между вариантами использования и друrими требованиями . . . . . . . . . . . . . . . . . . . 165 (лава 17. Роль вариантов использования в общем процессе 167 17. 1. Варианты использования в орrанизации проекта . . . . . . . . . . . 167 ИСIlОJIьзуйте названия вариантов ИСIIOJIьзования в качестве основы для орпшизации flроекта. . . . . . . . . . . . . . . . . . . . . . . 167 УпраВJlение пересекающимися версиями вариантов использования. . . . . 169 Реализация полных сценарнев. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 17.2. Варианты использования и списки задач или функций . . . . . . . . 1 71 Вариант использования 34 Зафиксировать встречную продажу. . . . . . . . . . . . . . . . . . . . . . . . . . 172 17.3. Варианты использования и проектирование. . . . . . . . . . . . . . . . 174 Особые заметки для специалистов объсктноориентироваННОI'О проектирования . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 17.4. Варианты использования и проектирование интерфейса пользователя. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 17.5. Варианты использования и тестовые варианты. . . . . . . . . . . . . 179 Вариант использования 35 Заказать товары, сформировать счет (пример тестирования) " 179 17.6. Реальное создание вариантов использования. . . . . . . . . . . . . . 180 Этаll 1. Сформировать прсдставлсние системной функции низкой точности . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 Этап 2. Сформировап) представление высокой точности в виде вариантов ИСlIOJIЬЗ0ваШ1Я . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182 
Содержание xiii Время на разработку одноrо варианта ИСПОJfьзования. . . . . . . . . . . . . . . . 185 Как создать варианты использования, работая с большими rруппами . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185 Как создать варианты использования, работая с большой разнородной непрофессиональной rруппой . . . . . . . . . . . . . . . . . 185 (лава 18. Краткие описания вариантов использования и экстремальное проrраммирование (Extreme Programmiпg, ХР) 189 (лава 19. Распространенные ошибки 191 19. 1 . Отсутствует система. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191 ПервоначаJfЬНЫЙ вариант . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191 Вариант использования: Снять наличные со счета. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191 Замечания . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191 ИспраВJfенный вариант. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192 Вариант использования: Снять наличные со счета. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192 19.2. Отсутствует основное действующее лицо. . . . . . . . . . . ., . . . . 192 ПервоначаJIЬНЫЙ вариант . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192 Вариант использования: Снять наличные со счета. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192 Замечания . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193 Исправленный вариант. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193 19.3. Слишком MHoro деталей интерфейса пользователя. . . . . . . .193 Первоначальный вариант . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193 Вариант использования: Совершить покупку. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193 Замечания . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193 Исправленный вариант. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194 Вариант использования: Совершить покупку. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194 19.4. Очень низкие уровни цели. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . .194 Первоначальный вариант . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194 Вариант использования: Совершить покупку . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194 Замечания . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 ИспраВJfенный вариант. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 Вариант использования: Совершить покупку . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 
xiv Содержание 19.5. Цель и содержание не соответствуют Apyr Apyry . . . . . . . . . 196 19.6. Развитый пример варианта использования с чрезмерной детализацией интерфейса пользователя. . . . . . . . 196 Первоначальный вариант . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 Вариант использования 36 Найти решение (до) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 Замечания . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202 Исправленный вариант. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202 Вариант использования 37 Найти возможные решения (после) .......................... 202 (лава 20. Памятки АЛЯ каЖАоrо варианта использования 209 Памятка 1. Вариант использования  прозаическое эссе . . . . . . . . . . . . 209 Памятка 2. Старайтесь, чтобы вариант использования был читабельным. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209 Памятка 3. Только одна форма предложения. . . . . . . . . . . . . . . . . . . . . . 210 Памятка 4. "Включайте" подчиненные варианты использования . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211 Памятка 5. Кто владеет мячом? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211 Памятка 7. Не допускайте деталей rрафическоrо интерфейса пользователя в варианте использования . . . . . 213 Памятка 8. Два итоrа . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214 Памятка 9. Участникам необходимы rарантии . . . . . . . . . . . . . . . . . . . . . 214 Памятка 10. Предусловия. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .215 Памятка 11. Тесты "прошел/не прошел" для одноrо варианта использования . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216 fлава 21. Памятки АЛЯ набора вариантов использования 218 Памятка 12. Бесконечно развивающийся сюжет .. . . . . . . . . . . . . . . . . . 218 Памятка 1 З. Область действия корпорации и область действия системы. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219 Памятка 14. Основные достоинства вариантов использования и вариации. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219 Основные достоинства . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220 Подходящие вариации. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221 Неподходящие варианты. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222 Памятка 15. Качество набора вариантов использования. . . . . . . . . . . . . . 223 
Содержание xv (лава 22. Памятки АЛЯ работы наА вариантами использования 224 Памятка 16. Это только часть требований. . . . . . . . . . . . . . . . . . . . . . . . 224 Памятка 17. Сначала работа должна быть направлена в ширину. . . . . . .224 Памятка 18. Рецепт из 12 шаrов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226 Памятка 19. Не забывайте, во что обходятся ошибки. . . . . . . . . . . . . . . . 227 Памятка 20. Лучше меньше, но понятней. . . . . . . . . . . . . . . . . . . . . . . . .227 Памятка 21. Обработка ошибок. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228 Памятка 22. Первоначальные и конечные названия работ. . . . . . . . . . . . 229 Памятка 23. Действующие лица иrрают роли. . . . . . . . . . . . . . . . . . . . . . 229 Памятка 24. Большая rрафическая мистификация. . . . . . . . . . . . . . . . . . 230 Памятка 25. Дебаты об инструментах. . . . . . . . . . . . . . . . . . . . . . . . . . . . 232 Памятка 26. Планирование проекта с помощью названий и кратких описаний . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234 Приложение А. Варианты использования на языке UML 237 А.1. Эллипсы и фиrуры из палочек. . . . . . . . . . . . . . . . . . . . . . . . . . . .237 А.2. Связь включения. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238 Правило 13. Более высокие цели изображайте выше . . . . . . . . . 239 А.З. Связь расширения. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .239 Правило 14. Изображайте расширяющие варианты использования ниже . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240 Правило 15. Используйте различные формы стрелок. . . . . . . . . .240 Корректное использование расширения. . . . . . . . . . . . . . . . . . . . . . . . . .241 Точки расширения . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241 А.4. Связь обобщения. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .243 Корректное использование связи обобщения . . . . . . . . . . . . . . . . . . . . . . 243 Правило 16. Общие цели изображайте выше. . . . . . . . . . . . . . . 244 Опасности обобщения . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244 А.5. Зависимые и подчиненные варианты использования. . . . . . . . 246 А.6. Изображение диаrрамм вариантов использования. . . . . . . . .247 Правило 17. Цели пользователя в контекстной диаrрамме. . . . . . 247 Правило 18. Вспомоrательные действующие лица должны быть справа. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247 А.7. Вместо диаrрамм пишите текстовые варианты использования. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247 
xvi Содержание Приложение В. Ответы к упражнениям 249 Вариант использования 38 Использовать систему обработки заказов .................... 254 Вариант использования 39 Купить товары через Интернет ............................ 255 Вариант использования 40 Оказать услуеу по прочистке свечей зажиеания . . . . . . . . . . . . . . . . 256 Приложение С. r лоссарий 258 Основные термины. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258 Типы вариантов использования ., . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260 Диаrраммы. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261 Приложение D. Источники информации 262 Книrи, на которые имеются ссылки в тексте ...................... 262 Статьи, на которые имеются ссылки в тексте. . . . . . . . . . . . . . . . . . . . . . 262 Полезные ресурсы Интернета . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263 
предисловие Все больше разработчиков прибеrают к помощи вариантов использования для опи сания бизнеспроцессов или поведения проrраммных систем и требований к ним. Co ставление описания использования системы может оказаться сложной задачей. Проблема в том, что создание вариантов использования можно сравнить с написани ем прозаическоrо эссе, rде необходимы четкие формулировки, которые свойственны письменной Прозе. Трудно сказать, на что похож хороший вариант использования. Однако еще труднее научиться писать хорошие варианты использования. Здесь содержатся правила, которые я использую при написании вариантов испо льзования: как может думать индивидуум, чеrо он может твердо придерживаться, что бы создать лучший вариант использования и лучший набор вариантов использования. Я включил примеры хороших и плохих вариантов использования, привел разные стили написания. Вариант использования не должен быть вьщающимся, чтобы быть полезным. Даже посредственные варианты использования полезны, причем больше, чем мноrие конкурирующие с ними технические требования. Итак, напишите чтони будь внятное, и вы окажете услуry вашей орrанизации. Кру, читателей Эта книrа предназначена преимущественно для профессионалов, которые обучают ся самостоятельно. В книrе содержится подrотовительная информация для усвоения HOBoro материала: понятия, примеры, памятки и упражнения (некоторые с ответами). Преподавателям следует найти подходящие объяснения и примеры д/fЯ своих rрупп. Разработчики курсов должны суметь построить материал на основе этой кни rи, составляя задания по своему усмотрению. (Однако, поскольку я включил ответы ко мноrим упражнениям, им придется построить экзаменационный материал самим.) Структура книrи Книrа построена как общее введение в написание вариантов использования, за KO торым следует подробное описание составных частей варианта использования, час то задаваемые вопросы, памятки и заключительные замечания. 
xviii Предисловие Введение дает начальное представление о КJlючевых понятиях. Обсуждается, как выrлядит вариант использования, Korдa он описывается, какие вариации допус тимы. Варианты использования выrлядят поразному в зависимости от Toro, коrда, rде, с кем и почему вы их пишете. Часть 1, Составные части варианта использования, содержИТ rлавы, по священные каждому основному понятию, которое необходимо усвоить, и части шаб лона, которые следует применять. Сюда входят rлавы Вариант использования как соrлашение о поведении, Область действия, Участники и деЙСТВУЮI11,ие лица, Три по именованных уровня цели, Предусловия, триrrеры и rарантии, Сценарии и шаrи, Расширения, Изменения в технолоrии и данных, Связывание вариантов использова ния и Форматы вариантов использования. Часть 2, Часто обсуждаемые темы, освещает следующее: Коrда считать pa боту завершенной, Как работать с большим количеством вариантов использования, CRUD и параметризованные варианты использования, Моделирование бизнеспро цессов, Пропущенные требования, Роль вариантов использования в обш.ем процес се, Краткие описания вариантов использования и экстремальное проrраммирование (ХР, EXtreme Programming) и Распространенные ошибки. Часть 3, Памятки для занятых, содержит основные правила для тех, кто закончил читать книry, или уже знает этот материал и хочет возвратиться к ключе вым идеям. [лавы называются: Памятки для каждоrо варианта использования, Па мятки для набора вариантов использования, Памятки для работы над вариантами использован ия. Далее следуют четыре приложения: Варианты использования в UML, Ответы к (некоторым) упражнениям, [лоссарий и Список использованных материалов. Преемственность идей В конце 60x rодов Ивар Якобсон, работая над телефонными системами в компании Еriсssоп, изобрел то, что позднее получило название вариантов использования (use cases). В конце 80x он представил их специалистам по объектноориентированно му проrраммированию. Они получили признание, заполнив брешь в процессе фор мирования требований. В начале 90x я прошел курс у Якобсона. Ни он, ни ero команда не пользовались моими терминами цель (goal) инеудача (goal failure), oд нако на самом деле они применяли эти понятия. В нескольких случаях мы с ним не нашли серьезных противоречий между ero и моей моделью. Я расширил ero модель, чтобы осовременить ее. Я создал концептуальную модель Действующие лица и цели (Actors and Goa\s) в 1994 [., Korдa писал руководство по вариантам использования дЛЯ 18М ConsLllting Group. Модель объясняла мноrие непонятные моменты в вариантах использования и одновременно служила руководством по их структурированию и написанию. Модель Действующие лица и цели неформально распространялась с 1995 [. Она находилась на http://members.aol.com/ acocbиrп, позднее на www.usecase.org, а в 1997 ['. в журнале Jourпal 01 ObjectOrieпted Programmiпg была опубликована моя статья о структурировании вариантов использования с целями. 
Предисловие xix В период с 1994 по 1999 rr. эти идеи не претерпели изменений, хотя в теории оставались еще "белые пятна". В конце концов я понял, почему мноrие с таким трудом усваивали столь простые идеи (не rоворя уж о том, что я обнаружил MHoro ошибок в своих первых опытах). Кроме Toro, выявились недостатки в модели Действующие лица и цели. Все это привело к трактовке, изложенной в этой книrе, и к новой представлен ной здесь идее  модели Участники и интересы (Stakeholders апd Iпtеrеsts). Унифицированный язык моделирования UML (Uпifiеd Modeling Lапguаgе) не оказал заметноrо влияния на эти идеи, обратное также верно. rYHHap Оверrаард, бывший коллеrа Якобсона, написал большую часть материала о вариантах использо вания на основе UML и подцержал наследие Якобсона. Однако rруппа стандартиза цИИ UML подвержена серьезному влиянию rрафических средств, что привело к выхолащиванию текстовой природы вариантов использования в стандарте UML. rYHHap Оверrаард и Ивар Якобсон обсудили мои идеи и уверили меня, что большая часть Toro, что я rоворю о варианте использования, умещается внутри одноrо из эл липсов UML и, следовательно, никоrда не подверrнется воздействию стандарта UML и не повлияет на Hero. Это значит, что идеи этой книrи совместимы со CTaндap том варианта использования в UML версии 1.3. С друrой стороны, если вы прочтете только стандарт UML, в котором не обсуждается содержание и способ написания Ba рианта использования, вы не поймете, что такое вариант использования и как ero применять, и получите ложное представление о вариантах использования как rрафи ческой, так и текстовой конструкции. Цель этой книrи  показать, как писать эф фективные варианты использования. Стандарт HeMHoro rоворит по этому поводу, поэтому я вынес свои замечания по UML в приложение А. Используемые примеры Примеры, приведенные в этой книrе, в большинстве своем взяты из реальных про ектов и MOryT показаться несовершенными. Однако они удовлетворяли потребно стям команды разработчиков, которая их писала. Эти несовершенства находятся в допустимых пределах. В издательстве Аddisоп Wesley меня убедили убрать шеро ховатости, чтобы выделить корректный вид на фоне реальноrо и адекватноrо пред ставления. Надеюсь, д/fЯ вас будет полезно посмотреть на примеры и распознать подлинные описания реальных проектов. Вы можете применить некоторые из моих правил к этим примерам, чтобы улучшить их. Так как совершенствовать KeMTO Ha писанное можно бесконечно, я принимаю возражения и любую критику. Варианты использования в серии Crysta/ Collecfioп Это одна из книr из серии Crystal Соllесtiоп для профессионалов в области про rpaMMHoro обеспечения. Она посвящена простым и доступным методам разработки проrраммных продуктов. Некоторые КНИf'И описывают какой либо метод, друrие  единственную роль в проектировании или вопросы взаимодействия в rруппе разра ботчиков. 
хх Предисловие в основу Ctystal Соllесtiоп положены два принципа: . Разработка проrраммноrо обеспечения  это кооперативная Иrра, построенная на изобретательстве и общении. Она совершенствует навыки разработчиков и повышает эффективность работы rруппы в целом. . Разным проектам присущи разные потребности. Проrраммные продукты отличаются характеристиками и разрабатываются различными по численности rруппами, состоящими из специалистов снеодинаковыми системами оценок и приоритетов. Невозможно указать лучший способ производства проrраммноrо обеспечения. в основополаrающей книrе серии Ctystal Соllесtiоп, Software Dеvеlорmепt as а Cooperative Game, детально разрабатываются идеи о проектировании проrраммноrо обеспечения как о кооперативной иrре и о методолоrии как о rармонизации культу ры. В книrе рассматриваются аспекты методолоrии, технолоrии и деятельности, pa бочих продуктов и стандартов. Сущность дискуссии в необходимом для вариантов использования объеме изложена в разделе 1.2 данной книrи. Настоящая книrа  это техническое руководство по основным элементам напи  сания вариантов использования. Этот метод подходит почти для любоrо СJIучая, OДHa ко шаблоны и стандарты следует выбирать в соответствии с потребностями KOHKpeTHoro проекта. 
БJ\оrОАОРНОСТИ я блаrодарен мноrим людям. Спасибо тем, кто просматривал эту книry в чернови- ках и указывал на темы, которые были не совсем понятны. Особая блаrодарность Расселу Уолтерсу за ero содействие и орrанизацию обратной связи. Выражаю бла- rодарность компаниям FirеРопd и Firетап's Fuпd Iпsurапсе Сот рапу за жизненные при меры вариантов использования. Спасибо Питу Мак-Брину, впервые испытавше му модель Участники и интересы. Он добавил к ней практический подход и внес преk ложения по улучшению. Блаrодарю Siliсоп Уаllеу Раttеrпs Group за внимательное прочтение первых вариантов книrи и квалифицированные комментарии к различ ным документам и идеям. Спасибо Майку Джоунсу из Beans & Brew в Fort Uпiоп, придумавшему пиктоrрамму болта для варианта использования подсистемы. Особая блаrодарность Сьюзен Лилли за тщательное прочтение и корректуру. Она внесла оrромный вклад в совершенствование окончательной версии. Блаrодарю друrих рецензентов, представивших подробные комментарии и одоб ривших работу: Пола Рэмни, Энди Полза, Мартина Фаулера, Карла Ваклавека, Ала на Уильямса, Брайана ХендерсонСеллерса, Ларри Константайна и Рассела rоулда. Редакторы в Аddisоп- Wes!ey проделали хорошую работу, выправив мои нескладные пред,IIожения и мноrочисленные опечатки. Блаrодарю моих учащихся за помощь в совершенствовании идей этой книrи. Еще раз спасибо моей семье, Динне, Кэмерону, Шону и Кирану, а также COTPYk никам из Веапs & Brew в Fort Uпiоп, обеспечившим теплую атмосферу. Дополнительную информацию о вариантах использования см. на web-сайтах, которые я поддерживаю: members.aol.com/acockburn и www.usecases.org. Во избе- жание возможных недоразумений скажу, что моя фамилия произносится Кооберн, с долrим о. 
rлово 1 Введение Как выrлядят варианты использования? Почему каждой команде разработчиков необходим свой стиль описания вариантов использования? Какое место занимают варианты использования в работе по формирова нию требований? Как подrотовиться к описанию вариантов использования? Прежде чем вникать в подробности вариантов использования как таковых, сле дует ответить на эти вопросы. 1.1. Что такое варианты испОАЬЗ0вания Вариант использования фиксирует соrлашение между участниками системы о ее по ведении. Вариант использования описывает поведение системы при ее ответах на за прос одноrо из участников, называемоrо основным действующим лицом, в раз личных условиях. Основное действующее лицо инициирует взаимодействие с сис темой, чтобы добиться некоторой цели. Система отвечает, соблюдая интересы всех участников. Различные модели поведения, или сценарии, развертываются в зави симости от определенных запросов и условий, при которых делались эти запросы. Вариант использования собирает вместе эти сценарии. Варианты использования представлены большей частью в текстовой форме, хотя возможны блоксхемы, циклоrраммы, сети Петри или языки проrраммирова ния. При нормальных обстоятельствах они служат средством связи между лицами, часто не имеющими специальной подrотовки. Поэтому простой текст обычно являет ся наилучшим выбором. Вариант ипользования как форма описания стимулирует обсуждение проекти руемой системы в rруппе разработчиков. Одна команда разработчиков может с по мощью варианта использования документировать действительные требования, 
2 rлава 1 друrая  окончательный проект. Все вышеперечисленное может применяться как д,lIя большой системы масштаба компании, так и Д,lIЯ небольшой системы, например Д,lIЯ фраrмента прикладной проrраммы. Одинаковые основные правила создания Ba риантов использования применимы в любой ситуации, даже если документация име ет различные уровни детализации и технические подробности. Коrда варианты использования документируют бизнеСFfроцессы орrанизации, рассматриваемая система (SuD, system under discussion) и является этой орrани зацией. Участники  это акционеры компании, заказчики, поставщики, opraHbl ro сударственноrо управления. Основные действующие лица  это заказчики компании и, возможно, их поставщики. Если варианты использования описывают требования к поведению части про rpaMMHoro обеспечения, SuD  это компьютерная проrрамма. Участники  это по льзователи проrраммы, компания, владеющая ею, opraHbl rосударственноrо управления и друrие компьютерные проrраммы. Основное действующее лицо  это сидящий за компьютером пользователь или друrая компьютерная система. Хорошо написанный вариант использования леrко читается. Он состоит из преk ложений, написанных в единой rрамматической форме (простых шаrов действий), в результате которых действующее лицо достиrает цели или передает информацию друrому действующему лицу. Обучение чтению варианта использования занимает He сколько минут. Труднее научиться писать хорошие варианты использования. Для этоrо придется освоить три понятия, которые применяются к каждому пред,IIожению варианта испо льзования и варианту использования в целом. Необходимо Bcerдa иметь в виду эти понятия, что может оказаться непростой задачей. С трудностями вы столкнетесь, как только начнете писать первый вариант использования. Вот эти три понятия: . Область действия (Scope): какова на самом деле рассматриваемая система? . Основное действующее лицо (Primary actor): у Koro есть цель? . Уровень (Level): какой уровень имеет эта цель? Далее следуют примеры вариантов использования. Части варианта использова ния описаны в следующей rлаве. А сеЙчас запомните определения: . Действующее лицо (Actor): KTOTO (или чтото), обладающий поведением. . Участник (Stakeholder): KTOTO (или чтото), проявляющий интерес к поведению рассматриваемой системы (SuD). . Основное действующее лицо (Primary actor): участник (некто или нечто), инициирующий взаимодействие с SuD Д,lIЯ достижения не которой цели. . Вариант использования (Use сме) : соrлашение относительно поведения SuD. . Область действия (Scope): идентифицирует рассматриваемую систему. . Предусловия и еарантии (Precoпditioпs aпd guaraпtees): то, что должно быть истинным до и после реализации варианта использования. 
Введение 3 . ОСНОВНОЙ сценарий (Maiп success sceпario): вариант, в котором не возникает никаких ошибок. . Расширения (Exteпsioпs): различные отклонения от OCHoBHoro сценария. . Номера расширений соответствуют номерам шаrов OCHoBHoro сценария, в которых обнаруживаютсяданные отклонения (например, шаrи 4а и 4Ь указы  вают на две отличные от OCHoBHoro сценария ситуации, которые MOryT возник нуть на шаrе 4). . Korдa один вариант использования ссылается на друrой, последний полчерки вается . в приведенных ниже примерах первый вариант использования описывает лицо, собирающееся купить некоторые ценные бумаrи через Сеть. Чтобы обозна чить, что данную цель можно достиrнуть за один сеанс, я помечаю вариант исполь зования как находящийся на уровне цели пользователя и снабжаю ero ярлыком в виде символа уровня моря, . Второй вариант использования описывает лицо, пытающееся получить компенсацию за автомобильную аварию. Эта цель требует более одноrо сеанса. Чтобы показать это, я помечаю вариант использования как находящийся на обобщенном уровне и снабжаю ero ярлыком в виде друrоrо сим вола  над уровнем моря, Р. Эти знаки объясняются в rлаве 5 и представлены на второй странице обложки. Первый вариант использования описывает взаимодействие индивидуума с про rраммой (PAF), выполняющейся на рабочей станции, подключенной к Интернету. Знак "черноrо ящика", ., указывает, что рассматриваемая система является компьютерной. Второй вариант использования описывает взаимодействие индивиду ума с компанией, которую.я обозначаю символом здания, ... Использовать именно эти символы не обязательно, в то время как некоторые метки области действия и уровня в любом случае необходимы. Ниже следуют варианты использования 1 и 2. Вариант испопьзования 1 . Покупка ценных бумаr через Интерне т  Основное действующее лицо: покупатель Область действия: персональные консультанты / финансовый пакет (Р AF) Уровень: цель пользователя Участники и интерес...: Покупатель  хочет купить ценные бумаrи, причем они должны автоматически попасть в портфель Р AF. Биржевое areHTcTBo  хочет получить полную информацию о покупке. Предусловие: nporpaMMa Р AF У пользователя уже открыта. 
4 r лава 1 миним.апьныe rарантии: в наличии Аостаточно реrистрационной информации, чтобы Р AF моrла обнаружить несоответствие и запросить у пользователя Аополнительные Аанные. rарантия успеха: УАаленный wеЬсайт ПОАтвеРАИЛ покупку; реrистрационные файлы и портфель пользователя обновлены. Основной сценарий: 1. Покупатель выбирает покупку ценных бумаr через Сеть. 2. PAF получает от пользователя аАрес нужноrо сайта (E*Trade, Schwab и т. А.). 3. PAF ПОАключается к сайту, сохраняя контроль наА процессом. 4. Покупатель выбирает и покупает ценные бумаrи на Аанном сайте.' 5. PAF перехватывает ответы wеЬсайта и обновляет портфель покупателя. 6. PAF показывает покупателю новое состояние портфеля. Расwирения: 2а. Покупатель запросил wеЬсайт, не ПОАдерживаемый PAF. 2а 1. Система получает от покупателя новое преАЛожение с возможностью отменить вариант использования. 3а. Отказ любоrо рОАа в Сети во время установки: 3а1. Система сообщает покупателю о неУАаче, Аает совет и возвращается на преАЫАУЩИЙ шаr. 3а2. Покупатель либо отказывается ПРОАолжать этот вариант использования либо Аелает новую попытку. 4а. Во время транзакции покупки компьютер ВЫХОАИТ из строя или выключается: 4а1. (Что ЗАесь нужно Аелатьп 4Ь. wеЬсайт не ПОАтвеРЖАает покупку, а заАерживает ее: 4Ь 1. Р AF реrистрирует заАержку, устанавливает таймер, чтобы запросить покупателя о ВЫХОАе. 5а. wеЬсайт не возвращает неоБХОАИМУЮ информацию о покупке: 5а 1. Р AF реrистрирует отсутствие информации о том, совершилось ли в портфеле покупателя обновление АЛя зависшей покупки. Вариант испопьзования 1 11 Попучить страховую компенсацию за автомобипьную аварию р Основное действующее пицо: истец Обпасть действия: страховая компания (MylnsCo) Уровень: обобщенный Участники и интересы: Истец  хочет получить максимально возможную сумму. Компания MylnsCo  хочет заплатить как можно меньше. 
Введение 5 Министерство страхования  хочет убедиться, что соблюдены все нормы и правила. Предусловне: отсутствует. Мнннмальные rapaHTHH: MylnsCo реrистрирует заявление и все действия. rарантня успеха: истец и MylnsCo приходят к соrлашению о сумме cTpaxoBoro возмещения. Истец получает оrоворенную сумму. TpHrrep: истец представляет заявление на рассмотрение. Основной сценарнй: 1. Истец представляет на рассмотрение заявление с обоснованием. 2. Страховая компания проверяет законность cTpaxoBoro полиса истца. 3. Страховая компания назначает areHTa для расследования cTpaxoBoro случая. 4. Страховая компания проверяет, укладываются ли все детали в нормативы полиса. 5. Страховая компания выплачивает истцу страховое возмещение и закрывает дело. Расшнрення: 1 а. Предоставленные данные не полны: 1 а 1. Страховая компания запрашивает недостающую информацию. 1 а2. Истец предоставляет недостающую информацию. 2а. Полис истца недействителен: 2а1. Страховая компания отклоняет заявление, извещает истца, документирует все действия и прекращает дело. 3а. На этот момент нет свободных areHToB. 3а 1. (Что в этом случае делает страховая компания?) 4а. Обстоятельства аварии противоречат основным правилам полиса: 4а1. Страховая компания отклоняет заявление, извещает истца, документирует все действия и прекращает дело. 4Ь. Обстоятельства аварии противоречат второстепенным правилам полиса: 4Ь 1. Страховая компания начинает neperoBopbI с истцом относительно суммы платежа. Большинство вариантов использования взяты из реальных проектов, и я cTapak ся не подправлять их (кроме добавления ярлыков области действия и уровня, если их не было). Мне хочется, чтобы вы увидели практические примеры, а не созданные для классной комнаты. У людей редко хватает времени, чтобы написать варианты испо льзования по форме, в полном объеме, да еще отредактировать их. Обычно их дела ют лишь "достаточными", а именно это и необходимо. Я показываю жизненные примеры, потому что создать совершенный вариант использования удается редко. Даже я не часто MOry написать идеальный вариант использования. Вариант использования 3 написал Торфин Аас из Центральноrо банка Норвеf'ИИ для cBoero коллеrи, представителя пользователя и для себя caMoro. Он демонстриру ет, как можно изменить форму, сохранив ценность. Автор внес в документ дополни 
6 r лава 1 тельный бизнесконтекст, иллюстрируя работу приложения в течение рабочеrо дня. Это практично, так как избавляет от необходимости писать отдельный документ, описывающий бизнеспроцесс. Это никоrо не запутало и увеличило информатив ность д,lIя заинтересованных лиц. Вариант испопьзования 3 l1li Зареrистрировать привезенную коробку  П  приемщик Р  реrистратор Основное действующее пицо: П Обпасть действия: nporpaMMa реrистрации ночных поступлений Уровень: цель пользователя Основной сценарий: 1. П получает и открывает коробку (идентификатор (10) коробки, сумки с 10), полученную от транспортной компании (ТК). 2. П проверяет, совпадает ли 10 коробки с зареrистрированными 10 ТК. 3. П, возможно, подписывает бумаrу посыльноrо. 4. П реrистрирует поступление коробки в системе, которая хранит: IOП дату, время 10 коробки название транспортной компании <Фамилию посыльноrо?> количество сумок (с 10 сумок?) <оценку?> 5. П извлекает сумки из коробки, кладет в тележку, доставляет Р. Расwирения: 2а. 10 коробки не соответствует 10 транспортной компании. 4а. Срабатывает пожарная сиrнализация и прерывает реrистрацию. 4Ь. Выходит из строя компьютер. Оставьте деньrи на столе и подождите, KorAa компьютер заработает. Вариации: 4'. С персональным 10 или без Hero. 4". С оценкой или без оценки. . 5'. Поставляет сумки в коробке. 1.2. У каЖАоrо свой вариант использования Варианты использования  это виддокументации, который можно использовать в работе в различных ситуациях, например, если требуется: 
Введение 7 . Описать рабочий процесс в бизнесе. . Сконцентрировать усилия на обсуждении принципиальных требований к разрабатываемой системе, а не на подробном их описании. . Описать функциональные требования к системе. . Документировать проект системы. . Написать документ в небольшой компактной rруппе или в большой распреде ленной rруппе. В каждой ситуации требуется свой стиль. Ниже приведены основные формы описания, диктуемые заданной целью. . Компактная rруппа, собирающая требования, или более крупная rруппа, обсуж дающая требования к разрабатываемой системе, пишет бессистемно, в противо положность вариантам использования, созданным по полной проrрамме, которые ПРИНa,д.IIежат более мноrочисленной, rеоrрафически распре деленной команде. Бессистемная (casual) форма в целях экономии времени упрощает шаблон варианта использования (подробнее см. ниже). Варианты использова ния 1 3 написаны по полной форме (fully dressed) с использованием полноrо шаблона варианта использования и схемы нумерации шаrов. Вариант использо вания 4  это пример бессистемной формы. . Участникам бизнеспроцессов варианты использования нужны, чтобы описать свои деловые операции, Torдa как rруппа разработки аппаратноrо или про rpaMMHoro обеспечения пишет системные варианты использования Д,lIЯ своих требований. Команда разработчиков может писать и друrие системные вариан ты использования, чтобы документировать проект или разбить требования на небольшие подсистемы. . В зависимости от уровня, разработчик описывает мноrосеансовую, или слож ную цель; односеансовую, или пользовательскую цель; часть цели пользова теля, или подфункцию. Указывать, какой из этих уровней описывается, настолько важно, что мои студенты используют два способа их обозначения: с помощью высоты над уровнем моря (выше, на уровне, ниже) и цвета (белый, rолубой, индиrо). . Лицо, формулирующее требования Д,lIЯ проектируемой системы, компьютер ной либо Д,lIЯ бизнеса, пишет варианты использования типа "черный ящик". При этом внутренняя структура системы не обсуждается. Разработчики биз неспроцессов описывают варианты использования типа" прозрачный ящик", показывающие, как в компании или орrанизации протекают внутренние про цессы. rруппа технической разработки может сделать то же самое, чтобыдоку ментировать эксплуатационный контекст системы, которую ей предстоит разработать, а также создать варианты использования типа "прозрачный ящик" Д,lIЯ описания функционирования только что разработанной системы. 
8 rлава 1 Замечательно, что форму описания варианта использования можно при менять в столь различных ситуациях, но это и сбивает с толку. Несколько человек не придут к соrласию по какому-нибудь вопросу описания просто потому, что их варианты испо льзования имеют разные цели. И вы, вероятно, встретите со временем несколько комбинаций этих характеристик. Обсуждая варианты использования, мы будем стараться найти общий язык, дo пуская в то же время мноrообразие в этом вопросе. Лучшее, что я MOry сделать, это указать на проблему, а примеры будут rоворить самим за себя. Вы можете протестировать себя на предмет составления вариантов использова ния в этой rлаве. Варианты использования 1, 3 и 5 были написаны с целью создания требований к системе, поэтому они полностью соответствуют форме, имеют тип "черный ящик" Д,lIЯ системы и уровень цели пользователя. Вариант использования 4 Toro же типа, но написан произвольно. Вариант использования 2 с контекстной YCTa новкой, предназначенный Д,lIЯ документирования бизнеспроцесса, написан по пол ной форме, имеет тип "черный ящик" и сложный уровень. Самое большое различие между форматами вариантов использования заключа ется в их соответствии полной форме. Рассмотрим совершенно разные ситуации: . Команда работает над проrраммным обеспечением Д,lIЯ большоrо, критически важноrо Д,lIЯ орrанизации проекта. Разработчики решили, что дополнительная процедура стоит затрат, поэтому (а) шаблон варианта использования должен БЫТЬд,IIиннее и подробнее, (Ь) члены пишущей команды должны писать в одном стиле, чтобы сократить количество двусмысленных и непонятных мест, (с) Ba рианты использования следует тщательно проверять на предмет пропусков и двусмысленностей. Учитывая низкую устойчивость к ошибкам, они также реши ли сократить допустимые отклонения при написании варианта использования. . Команда из 35 человек разрабатывает систему, самая серьезная неисправ- ность которой заключается в потере комфорта. С ней леrко справиться, позво- нив по телефону специалисту. Разработчики посчитали соблюдение формальностей напрасной тратой времеии, сил и денеr. Поэтому они выбрали: (а) более простой шаблон, (Ь) более свободный стиль изложения, (с) меньшее количество менее строrих проверок. Обнаружение ошибок и упущений в тексте варианта использования перекладывается на друrие механизмы проекта, воз можно, на обсуждение среди коллеr и пользователей. Разработчикам позволе но допускать больше ошибок в письменном общении между собой, а потому менее формально подойти к созданию вариантов использования при большем разнообразии неформальных отношений между людьми. и то, и друrое допустимо. Такой выбор должен предоставляться Д,lIЯ каждоrо проекта. Это наиболее важный урок, который я как методист усвоил за последние пять лет. Конечно, мы rодами rоворили, что не все можно мерить одной меркой. Но как конкретизировать это, осталось тайной. Не нужно rнаться за точностью и строrостью, если в них нет большой необходИ: мости  на это уйдет MHoro времени и сил. Как написал ДЖим Сэвайер, участвуя в дискуссии по электронной почте, .....пока шаблоны не станут такими формальными, 
Введение 9 ЧТО вы потеряетесь в рекурсивном спуске, который, как червоточины, пронизывает пространство проекта. Если это начнется, я велю разобрать эту сомнительную KOH Ф " струкцию до основания и стану рассказывать истории и писать на сал етках . Я пришел к выводу, чТО недостаточно иметь только один шаблон. Должно быть по меньшей мере два: в свободном стиле для менее формальных проектов и строrой формы ДЛЯ более педантичноrо стиля проектирования. В любом проекте можно адаптировать одну из этих форм к соответствующей ситуации. Следующие два вари анта использования описывают одно и то же, но в разных стилях. Вариант использования 4 е Совершить покупку (бессистемная версия) Р Инициатор запроса делает запрос и направляет ero своему Утверждающе му лицу. Утверждающее лицо проверяет, есть ли деньrи в бюджете, про веряет цены на товары, завершает оформление запроса для подачи и посылает ero Покупателю. Покупатель просматривает содержимое памя ти, отыскивая лучшеrо поставщика. Уполномоченное лицо подтверждает подлинность подписи Утверждающеrо лица. Покупатель формирует за прос на заказ, инициирует денежный перевод по почте Поставщику. По ставщик доставляет товары Приемщику, получает подтверждение доставки (вне сферы проектируемой системы). Приемщик реrистрирует доставку, отсылает товары Инициатору запроса. Инициатор запроса отмечает, что заказ доставлен. В любой момент, предшествующий получению товаров, Инициатор запро са может изменить или отменить запрос. При отмене запрос выводится из любой активной обработки (удаляется из системы?). Снижение цены OCTaB ляет ero неизменным. При повышении цены он снова отсылается Утверж дающем у лицу. Вариант использования 5 е Совершить покупку (полная версия) Р Основное денствующее лицо: инициатор запроса Цель в контексте: инициатор запроса покупает чтонибудь с помощью зтой системы, получает заказ. Не включена оплата заказа. Область денствия: бизнес  общий механизм совершения покупки (электронный и обычный), как ero представляют в компании. Уровень: обобщенный Участники и интересы: Инициатор запроса: хочет получить то, что заказал, без особых хлопот. Компания: позволяя сделать необходимые покупки, хочет проконтролировать расходы. Поставщик: хочет, чтобы ему заплатили за все доставленные товары. Предусловие: отсутствует. 
10 r лава 1 Минимальные rарантии: каждый отосланный заказ одобрен законным уполномоченным лицом. Заказ отслеживается, чтобы компании присылали счета только за действительно доставленные товары. rарантии успеха: инициатор запроса получает товары, правильный бюджет rOToB к дебетованию. Триrrер: инициатор запроса решает чтото купить. Основной сценарий: 1. Инициатор запроса: иниuиирует запрос. 2. Утверждающее лицо: проверяет наличие AeHer в бюджете, цены товаров, завершает оформление запроса для подачи. З. Покупатель: просматривает содержимое памяти, ищет лучшеrо поставщика товаров. 4. Уполномоченное лицо: удостоверяет подпись утверждающеrо лиuа . 5. Покупатель: завершает формирование запроса для заказа. иниuиирует денежный перевод поставщику . 6. Поставщик: доставляет товары приемщику, получает квитанцию о доставке (вне сферы проектируемой системы). 7. Приемщик: реrистрирует доставку , отправляет товары инициатору запроса. 8. Инициатор запроса: отмечает. что заказ доставлен . Расширения: 1а. Инициатор запроса не знает поставщика или цены  пропустить эти части бланка и продолжить. 1Ь. В 'любой момент до приема товаров инициатор запроса может изменить или отменить запрос: При отмене запроса прекращается ero активная обработка (удалить из системы?). Снижение цены не затраrивает обработку запроса. При повышении цены запрос снова отправляется утверждающему лицу. 2а. Утверждающее лицо не знает поставщика или цену  оставить пропуск и дать покупателю ero заполнить или забрать. 2Ь. Утверждающее лицо не является руководителем покупателя  не страшно, если утверждающее лицо подписывает запрос. 2с. Утверждающее лицо отклоняет запрос  вернуть инициатору запроса для изменения или аннулирования. За. Покупатель находит товары в памяти  отослать их, уменьшить запрос на эту величину и продолжить. ЗЬ. Покупатель заполняет пропущенные поля поставщика и цены  запрос повторно посылается утверждающему лицу. 4а. Уполномоченное лицо отказывает утверждающему лицу  возвратить запрос покупателю и прекратить ero активную обработку. (Что это значит) 5а. Запрос включает несколько поставщиков  nокупатель осуществляет несколько денежных переводов. 
Введение 11 5Ь. Покупатель объединяет несколько запросов  тот же процесс, но следует пометить, к какому запросу относится каждый денежный перевод. 6а. Поставщик не доставляет заказ вовремя  система сиrнализирует о том. что заказ не доставлен. 7а. Частичная доставка  приемщик отмечает частичную доставку в денежном переводе и продолжает. 7Ь. Частичная доставка по переводу на несколько запросов:  приемщик записывает количество полученных товаров для каждоrо запроса и продолжает. 8а. Товары не те или не Toro качества  инициатор запроса отказывается от доставленных товаров (Что это значит?). 8Ь. Инициатор запроса ушел из компании  покупатель решает с руководителем инициатора запроса, назначить ли Apyroro инициатора или возвратить товары и отменить запрос . Список изменений в технолоrии и данных: отсутствуют. Приоритет: различный Реализации: несколько Время реакции: различное Частота использования: 3 раза в день Канал для OCHoBHoro действующеrо лица: браузер Интернета, почтовая система или равноценный механизм Второстепенные действующие лица: поставщик Каналы для второстепенных действующих лиц: факс, телефон, автомобиль Открытые вопросы: KorAa отмененный запрос удаляется из системы? Чье разрешение нужно, чтобы отменить запрос? Кто может изменить содержание запроса? В каком объеме должна поддерживаться история изменений для запросов? Что происходит, KorAa инициатор запроса отказывается от доставленных товаров? В чем отличие требования от заказа? Как при размещении заказов происходит обращение к внутренней памяти и ее использование? Нельзя просто сказать, что мы пишем варианты использования для этоrо проек та. Любая рекомендация или определение процесса, типа "Напишите варианты ис пользования", будет недостаточной. Вариант использования, достоверный для одноrо проекта, не применим к друrому. Кроме Toro, следует указать, применяются ли вари анты использования по полной или бессистемной форме, какие части шаблона и форматы обязательны и каковы пределы допустимоrо отклонения разработчиков от формы. 
12 r лава 1 Всестороннее обсуждение возможных отклонений и вариаций в проектах coдep жится в книrе Software Developmeпt as а Cooperative Оате, упоминавшейся в пре дисловии. Чтобы научиться писать варианты использования, не требуется подробное обсуждение. Что действительно необходимо, так это различать метод написания, Ka чество варианта использования и стандарты проекта. Метод  это последовательность размышлений или действий, которые люди используют при построении вариантов использования. Эта книrа в значительной CTe пени касается метода: как думать, как строить преД,J10жения, в какой последователь ности работать. Методы хороши тем, что в основном не зависят от размера проекта. Овладевший методом специалист способен применять ero как к малым, так и к боль шим проектам. Качество rоворит о том, насколько точно написанные варианты использования соответствуют их цели. В этой книrе я описываю лучший способ, который я знаю, Д,J1я каждой части варианта использования, Д,J1я варианта использования в целом и Д,J1я разных целей. В конечном счете, однако, способ, которым вы оцениваете качест во ваших вариантов использования, зависит от вашей цели, допустимых пределов и степени следования форме. В стандартах записано, о чем доrоворились разработчики, создавая варианты использования. В этой, книrе я рассматриваю альтернативные приемлемые CTaH дарты, показывая различные шаблоны и разные стили преД,J10жений и заrоловков. Я преД,J1аrаю несколько конкретных рекомендаций, но, в конце концов, дело орrани зации или разработчиков проекта устанавливать или адаптировать стандарты и pe шать, насколько cTporo следовать им. В большей части этой книrи я рассматриваю насущный вопрос: разработку точных требований. Далее консультант Стив Эдолф описывает применение вари антов использования скорее Д,J1Я выявления требований, чем для их документиро вания. · Стмв Эдопф: "Выявпенме" требованмй на новой террнторнн Варианты использования обычно предла rают способ сбора и моделирования из вестных функциональных требований. Считается, что повествователь ная фор ма леrче для понимания, чем традицион ные длинные списки требований. TorAa действительно понятно, что должна дe лать система. Но что, если никто не знает, что должна делать система? Автоматиза ция процесса обычно изменяет сам процесс. В полиrрафической промыш ленности недавно произошла одна из самых больших пере мен со времен изобретения офсетной печати: появи лась технолоrия "непосредственно на печатную форму/непосредственно на пресс". Раньше установка печатноrо пресса была трудоемким, мноrошаrо вым процессом. Новая технолоrия cдe лала промышленную полиrрафию таким же простым делом, как распе чатка документа, подrотовленноrо в текстовом процессоре. 
Введение Как бы вы в качестве аналитика, OT BeTcTBeHHoro за управление технолоr ческим процессом, собирали требо вания дnя системы на основе такой co вершенно новой технолоrии, как поли rрафический метод "непосредственно на печатную форму"? Для начала вы моrли бы описать использование суще ствующей системы и определить дейст вующих лиц и службы новой системы. Однако в результате вы получили бы пишь существующую систему. Никто еще не делал новую работу, так что все специалисты в этой области изучают HO вую систему одновременно с вами. Вы параллельно разрабатываете новый процесс и новое nporpaMMHoe обеспе чение. Остается только пожелать вам удачи. Как вы действуете в этой ситуа ции? Берете существующую модель и спрашиваете себя, что же меняется? Ответом вполне может быть: "Все". KorAa вы пишете варианты исполь зования, чтобы документировать требо вания, у KoroTo уже сложилось пред ставление о системе. Вы просто Bыpa жаете это представление так, чтобы каждому было понятно. Однако при BЫ явлении требований вы сами создаете представление о системе. Применяйте варианты использова ния в качестве инструмента "мозrовоrо штурма". Спросите себя, какие шаrи в этих вариантах использования при новой технолоrии теряют смысл. Создайте HO вое повествование о том, как действую 13 щие лица достиrают своих целей. Цели пока те же самые, но некоторые BTOpO степенные действующие лица ушли или изменились. Используйте метод "поrрузиться и всплыть". Создайте широкую модель BbIcoKoro уровня, описывающую ваше представление о том, как моrла бы pa ботать новая система. Стремитесь к простоте, поскольку это неисследован ная территория. Придумайте, как Mor бы выrлядеть основной сценарий. Про иrрайте ero со специалистами по старой системе. Затем поrрузитесь в подробности oAHoro варианта использования. Pac смотрите альтернативы. Учтите, что лю дям проще понять рассказ, и отложите формирование требований. Прочитайте шаr в варианте использования и задай тесь вопросом, что происходит, KorAa клиент предпочитает твердую, а не цифровую копию корректуры. Это про ще, чем пытаться построить полную мысленную модель работы системы. Наконец, вернитесь на поверх ность. Что изменилось, после Toro как вы поrрузились в детали? Настройте MO дель, затем повторите поrружение дnя Apyroro варианта использования. Мой опыт показал, что применение вариантов использования дnя выявления требований приводит к созданию функ циональных требований более BЫCOKO ro качества. Они лучше орrанизованы и более полны. 1.3. Требования и варианты использования Если вы пишете варианты использования как требования, имейте в виду: . Это действительно требования. Не следует превращать их в друryю форму требований к поведению системы. Написанные надлежащим образом, они точ но описывают, что должна делать система. 
14 r лава 1 . Это не все требования. Они не детализируют внешние интерфейсы, форма ты данных, бизнесправила и сложные формулы. Они устанавливают только часть (возможно, треть) всех требований, которые вам необходимо собрать, очень важную, но лишь часть. Каждая орrанизация занимается сбором и систематизацией требований в COOT ветствии со своими нуждаМи. Существуют даже стандарты описания требований. В каждом из них варианты использования занимают лишь часть общеrо множества дo кументированных требований. Следующая схема требований представляется мне весьма полезной. Я взял ее из шаблона, который Сьюзен Робертсон и консорциум Atlantic Systems Guild опубликовали на своем wеЬсайте и в книrе Maпagiпg Requiremeпts (1999). Их шаблон впечатляет своей полнотой, так что я урезал ero до приведенной ниже схемы, которую использую как руководство. Однако она слишком длинна для бо льшинства проектов, с которыми я сталкиваюсь, поэтому я стараюсь сокращать ее и далее. Каков бы ни был ее размер, она задает MHoro интересных вопросов, KO торые в друrом случае не возникли бы, например: "Как влияет человеческий по тенциал на сбои системы? Какие политические соображения управляют каждым требованием? " В задачи этой книrи не входит полная стандартизация ваших требований, но я знаю, что мноrие никоrда не видели схему требований. Я объясню, что это такое. Ее rлавная цель  показать место вариантов использования в общей схеме требований и подчеркнуть, что варианты использования не содержат всех требований, а только описывают часть поведения, требуемую функцию. Приемлемая схема требований Раздел 1. Цель и область действия 1а. Что представляют собой общая область действия и цель? 1Ь. Участники (Koro это интересует?) 1 с. Что входит в область действия и что нет? Раздел 2. Используемые термины/rлоссарий Раздел 3. Варианты использования 3а. Основные действующие лица и ИХ общие цели 3Ь. Варианты использования для бизнеспроцессов 3с. Системные варианты использования Раздел 4. Используемая технолоrия 4а. Какие технолоrические требования предъявляются к данной системе? 4Ь. С какими системами будет взаимодействовать данная, каковы требования? Раздел 5. Друrие требования 5а. Процесс разработки 
Введение 15 01. Кто участвует в проекте? 02. Какие оценки проекта будут отражены (простой, ранний, быстрый или rибкий)? ОЗ. Какая обратная связь или прозрачность проекта нужна пользователям и орrанизаторам? 04. Что мы можем купить, что должны построить, с кем конкурируем? 05. Какие еще существуют технолоrические требования (тестирование, установка и т.д.)? 06. От чеrо зависит развитие проекта? 5Ь. Бизнесправила 5с. Производительность 5d. Эксплуатация, безопасность, документация 5е. Использование (простота использования) 5f. Сопровождение и мобильность 5g. Нерешенные или отложенные вопросы Раздел 6. Людские резервы, правовые, политические, орrанизационные вопросы 01. Как впияют людские резервы на функционирование системы? 02. Какие существуют правовые и политические требования? ОЗ. Какие последствия дnя людей будет иметь создание этой системы? 04. Каковы требования к обучению? 05. Какое влияние оказывает система на окружающее сообщество? Вариантам использования посвящен только Раздел 3 требований. Это не BO обще все требования, а только требования к поведению. Бизнесправила, rлосса рий, производительность, технолоrические требования и MHoroe друrое не попадает в катеrорию поведения. Для этих аспектов нужны собственные разделы (см. рис. 1.1). Варианты использования как структура связей проекта Варианты использования связаны со мноrими друrими деталями требований. Они ПОмоrают связать информацию в различных частях требований, включая сведения о профиле пользователя, бизнесправила и требования к форматам данных. Вне документа о требованиях варианты использования помоrают систематизи ровать информацию о планировании проекта, такую как даты выпуска, команды раз работчиков, прИОритеты и состояние разработки. Кроме Toro, они служат для отслеживания определенных результатов деятельности команды разработчиков, в частности интерфейса пользователя и системных тестов. 
16 r лава 1 Рис. 1.1. Модель требований в виде колеса Хотя эти требования и не входят в варианты использования, все они с ними свя заны. Варианты использования иrрают роль втулки колеса (см. рис. 1.1), а друrие виды информации выrлядят как спицы, направленные в разные стороны. Именно по этой причине варианты использования представляются людям центральным узлом требований или даже центральным узлом процесса разработки системы. 1.4. KorAa варианты использования повышают ценность проекта Варианты использования популярны прежде Bcero потому, что связно рассказыва ют о поведении системы при ее использовании. Пользователи системы MOryT уви деть, что это будет за система. Они получают возможность на ранней стадии влиять на точную настройку. В этом состоит значимость вариантов использования для про екта, но это лишь один пример. Вопервых, варианты использования являются особенно ценными, коrда имену ются целями пользователя, которые будет реализовывать система, и собираются в список. Этот список объявляет, что будет делать система, раскрывая ее область при менения и цели. Он становится средством связи между различными участниками проекта. Список целей просматривается представителями пользователя, должностными лицами, специалистамиразработчиками и руководителями проекта, оценивающими СТОимость и слОжность системы, разработка которой начинается с этоrо списка. Они 
Введение 17 обсуждают, какие функции реализовать в первую очередь и как сформировать команды. Список  это каркас, на который нанизываются сложность, стоимость, сроки и состояние проекта. Он накапливает разнообразную информацию в течение Bcero периода разработки. BOBTOpЫX, варианты использования важны, коrда их авторы выявляют методом "мозrовоrо штурма" все факты, которые моrли бы вызвать сбой в успешном cцeHa рии, перечисляют их и начинают документировать реакцию системы на них. В этот момент разработчики, возможно, обнаруживают чтото удивительное, чтото, о чем они или те, кто предоставил им требования, и не думали. Korдa мне надоедает писать варианты использования, я переключаюсь на усло Вия отказа. Здесь я реryлярно открываю HOBoro участника, систему, цель или биз несправило, пока документирую обработку отказа. Коrда мы определяем, что делать при возникновении одноrо из этих условий, я часто представляю себе экспертов по бизнесу, сбившихся в кучу или rоворящих по телефону, чтобы решить, что в этих об стоятельствах должна делать система. Без дискретизации шаrов вариантов использования и обсуждения возможных отказов в режиме "мозrовоrо штурма" мноrие условия ошибок остаются необнару женными до тех пор, пока какойнибудь проrраммист не наткнется на них, кодируя фраrмент проrраммы. При этом уже слишком поздно открывать новые функции и бизнесправила. Эксперты по бизнесу, как правило, уже отключились от проекта, и время поджимает, так что проrраммисты кодируют то, что им придет в rолову в этот момент, вместо Toro чтобы выяснить, какое поведение требуется. Те, кто пишет варианты использования длиной в один абзац, экономят время и наслаждаются преимуществами вариантов использования. Те же, кто упорно зани мается обработкой отказов, тоже береryт время, обнаруживая тонкие моменты в по ведении системы на ранней стадии проектирования. 1.5. дозируйте свою энерrию Береrите свои силы или по крайней мере управляйте ими. Если вы стремитесь опи- сать все детали за один раз, вы не успеете раскрыть все разделы за отведенное Bpe мя. Если вы записываете только схему, чтобы начать и затем описать сущность каждоrо варианта использования, вы можете: . Дать участникам шанс внести необходимые коррективы и понять приоритеты на ранней стадии. . Позволить распределить работу между несколькими rруппами, увеличивая па раллелизм и производительность. Часто rоворят: "Дайте мне обзор с расстояния 15 км", "Дайте мне только схему" или "Детали добавим позднее". Это означает: "Пишите пока не слишком подробно; детали добавим позже". Точность определяется тем, как MHoro вы сумели сказать. Коrда вы утверждае те: "Заказчик захочет взять напрокат вндео", вы не тратите слишком MHoro слов, но действительно сообщаете важную информацию читателям. Коrда вы показываете 
18 r лава 1 список всех целей, которые будет поддерживать проектируемая система, вы предо ставляете участникам orpoMHoe количество информации, содержащееся в неболь шом количестве слов. Точность  это не то же самое, что правильность. Если KTOTO rоворит вам: "Число Пи равно 4,141592", он вьщает высокую точность, однако далек от правиль ности. Если вам rоворят: "Пи равно 3", точность здесь невелика (маловато цифр), но это правильно в определенных пределах. Та же идея справедлива для вариантов ис пользования. Вы можете добавить массу деталей к каждому варианту использования, повысив ero точность. Однако если первоначальная формулировка целей содержит ошибки, усилия на детализацию их описания будут потрачены впустую. Лучше сделать KOp ректным список целей, а не тратить время и силы на детальное описание вариантов использования. Усилия, потраченные на описание вариантов использования, можно разделить на четыре стадии точности: 1. Действующие лица и цели. Перечислите действующих лиц и каждую из их целей, которые будет обеспечивать система. Проанализируйте правиль ность и полноту этоrо списка. Расставьте приоритеты и распределите цели между командами разработчиков и версиями. Теперь у вас есть функциона льные требования к первому уровню точности. 2. Краткое изложение варианта использования или основной сценарий. Для вариантов использования вы выбрали следование основному cцeHa рию в общих чертах. Рассмотрите ero в форме набросков, чтобы быть YBe ренным, что система действительно удовлетворяет интересам участников, о которых вы заботитесь. Это второй уровень точности функциональных требований. Этот материал довольно леrкО набрать, в отличие от двух сле дующих уровней. 3. Условия отказа. Завершите основной сценарий и продумайте, какие OT казы MOryT произойти. Занесите их в список, прежде чем решать, как систе ма должна их обрабатывать. Описание процессов обработки отказов более трудоемкая работа, чем перечисление отказов. Те, кто начинает описывать обработку отказов немедленно, часто выдыхаются, не закончив списка условий отказов. 4. Обработка отказа. Напишите, как система должна реаrировать на каж дый отказ. Это часто непростой, утомительный и непредсказуемый про цесс. Непредсказуемый потому, что довольно часто вопрос о малопонятном бизнесправиле всплывает во время работы над описанием, или при обра ботке отказа неожиданно обнаружится новое действующее лицо или новая цель, достижение которой должна обеспечить система. Большая часть проектов требует HeMHoro времени и усилий. Поэтому управле ние уровнем точности, к которому вы стремитесь, должно быть приоритетом проек та. Я настоятельно рекомендую работать в описанном выше порядке. 
Введение 19 1.6. Разминка с помощью повествовательноrо стиля Описание использования системы в повествовательном (паrrаtivе) стиле  это пример варианта использования в действии при определенных обстоятельствах. Это единичный, очень специфический пример Toro, как действующее лицо исполь зует систему. Это даже не вариант использования, и в большинстве проектов он не доживает до официальноrо документа "Функциональные требования". Однако это очень полезный метод, который стоит Toro, чтобы вы о нем прочитали. Начиная новый проект, вы можете не иметь опыта в написании вариантов испо льзования или, возможно, вы не продумали детали функционирования системы. Что бы освоиться с материалом, составьте краткий отчет об одном дне жизни одноrо из действующих лиц. Придумайте конкретное действующее лицо и кратко опишите, почему он хочет именно это или какие условия заставляют ero действовать именно так. Как и при co здании всех вариантов использования, MHoro писать не надо. Удивительно, сколько информации можно передать с помощью Bcero нескольких слов. Напишите, как все работает в этом отдельном случае от начала до конца ситуации. Важна краткость, читатель должен сразу ухватить суть. Подробности и причины или эмоциональное содержание имеют значение. Каждый читатель  от лнца, утверждающеrо требования, до разработчика проrраммноrо обеспечения, проекти ровщика тестов и создателя учебных материалов  должен понять, как следует оп тимизировать систему, чтобы повысить ее ценность для пользователя. Такое описание не требует MHoro усилий и места и вводит читателя в сам вари ант использования леrко и незаметно. Вот пример. Опнсанне нспольэовання: быстрое полученне налнчных денеr Мэри с двумя дочками по пути на работу заезжает в центр медицинской помощи, подъезжает к банкомату, про пускает карточку через считываю щее устройство, вводит свой PINKOA, выбирает режим FAST CASH (быст рое получение наличных AeHer) и вводит сумму, $35. Банкомат выдает банкноту в $20 и три по $5, а также квитанцию, показывающую остаток на ее счете после дебетования $35. После каждой транзакции FAST CASH банкомат восстанавливает экран, так что Мэри может не беспокоиться о том, что следующий пользоваТЕ'ль получит доступ к ее счету. Мэри Hpa вится FAST CASH, поскольку он не задает лишних вопросов, затяrивающих общение. Она пользуется этим банкоматом, так как он выдает банкноты в $5, которые она использует для платы за медицинскую помощь, к тому же для получения наличности ей не приходится выходить из машины. Описания использования нужны, чтобы понять, как работать с системой. Писать их полезно и в качестве разминки для проработки деталей перед созданием варианта использования. Иноrда rруппа разработчиков публикует описания в начале всех вари антов использования или только в начале конкретных вариантов использования, KOTO рые они иллюстрируют. Одна rруппа собирала пользователей, аналитиков и 
20 r лава 1 специалистов по созданию требований и анимировала описание использования, чтобы леrче было представить систему и выстроить общее видение ее использования. Описание использования  это не требования, скорее это ступень для создания более продуманных и обобщенных описаний требований. Описание использования служит отправной точкой для создания варианта использования. Сам по себе вари ант использования  это сухой остаток описания использования, формула с обоб щенными именами лиц, действующих в описании использования. 1.7. Упражнения Файл требований 1.1. Какие разделы файла требований зависят от вариантов использования, какие нет? Обсудите это с коллеrой и подумайте, почему ваши ответы различны. 1.2. Сделайте набросок друrих приемлемых требований, который можно распространить по корпоративной сети интранет. Уделите внимание структуре вашеrо подкаталоrа и соrлашениям о календарных штампах (зачем вам понадобятся такие соrлашения?). Описание использования 1.3. Создайте два описания использования для банкомата, которым вы пользуетесь. Чем и почему они отличаются от примера описания, приведенноrо выше? Насколько важны эти различия для разработчиков, которые будут создавать систему? 1.4. Создайте описание использования для лица, идущеrо в новый фирменный салон видеопроката, чтобы взять напрокат ориrинал фильма The Pareпt Trap. 1.5. Создайте описание использования для вашеrо текущеrо проекта. Попросите коллеrу написать аналоrичный документ. Сравните и обсудите записи. Почему они различаются, находятся ли эти различия в пределах допустимоrо или они серьезны? 
ЧАСТЬ 1 Составные части варианта использования 
rлово 2 Вариант использования как соzлашение о поведении Разрабатываемая система  это механизм для выполнения соrлашения между уча  стниками. Варианты использования обеспечивают поведенческую часть этоrо co rлашения. Каждое предложение в варианте использования описывает действие, защищающее некоторый интерес какоrолибо участника. Предложение может описывать взаимодействие двух действующих лиц или внутренние действия систе мы, которые она должна выполнять для защиты интересов участников. Сначала рассмотрим вариант использования как способ фиксации взаимодействия участни ков, имеющих определенные цели. Отталкиваясь от этоrо положения, мы можем расширить обсуждение, изучая вариант использования как соrлашение между уча стниками. Я называю первую часть концептуальной моделью Действующие лица и цели, а вторую  концептуальной моделью Участники и интересы. 2.1. 8ЗОИМОАействия Аействующих ЛИЦ, имеющих цели Действующие лица имеют цели Представьте себе служащеrо, oTBeTcTBeHHoro за прием запросов на обслуживание по телефону (на рис. 2.1 служащий представлен основным действующим лицом). Коrда поступает звонок, цель служащеrо OTKpЫTЬ компьютерный журнал и ини циировать запрос. Обязанность СИСтемы  зареrистрировать и инициировать запрос на обслужи вание в нашем примере. (В действительности она отвечает за защиту интересов всех участников, причем служащий, основное действующее лицо, только один из них. Co средоточимся на обязанности системы обеспечить обслуживание для OCHoBHoro дей ствующеrо лица.) 
24 rлава 2 Чтобы выполнить свою обязанность, система формулирует подцели. Некоторые подцели она способна реализовывать внутри себя, но для друrих ей необходима по мощь вспомоеательноео действующесо лица. Этим вспомоrательным действую щим лицом может быть подсистема печати или друrая орrанизация, например партнерская компания или правительственная орrанизация. Основное действующее лицо Индивидуум или система с целью для SuD Проектируемая система Может быть любой системой @ )( тD Вспомоrательное действующее лицо Друraя система, в отношении которой SuD имеет цель @ )( Обязанность . Цель 1 . Цель 2 Действие 1 (вза1д:й ствие 1) Обязанность . Цель 1 ...Действие 1 (взаимодействие 2)  Обязанность . Резервная цель ДЛЯ цели 2 Рис. 2.1. Действующее лицо, имеющее цель, инициирует выполнение обязанностей друrоrо действующеrо лица Вспомоrательное действующее лицо обычно выполняет свое обещание и доби вается подцели для разрабатываемой системы (SuD). SuD взаимодействует с внеш ними действующими лицами. Она достиrает своих подцелей через некоторую последовательность действий, пока не выполнит своей обязанности, Т.е. не окажет обещанную услуry. Предоставление обещанной услуrи  высшая цель, достиrаемая через подцели. Подцели можно, в свою очередь, разбить на подподцели и т.д. до бесконечности. Подпод(н.под)целей может быть бесконечное множество, если мы разбиваем дейст вия действующих лиц на мелкие составляющие. В стихотворении "Похвала поэзии" ДЖонатан Свифт rоворит о блохе, на которой натуралисты нашли блох еще меньше ro размера, которые, в свою очередь, имеют еще более мелких блох и Т.Д. Предела этому нет. Вероятно, наиболее трудная часть создания хороших вариантов использования  это управление блохами на блохах, Т.е. подподцелями. Подробнее об этом см. в rла ве 5, в rлаве 7 (правило 6) и в rлаве 20 (памятка 6). Концептуальная модель Действующие лица и цели удобна, поскольку применима и к бизнесу, и к компьютерным системам. Действующими лицами может быть человек, орrанизация или компьютер. Мы можем описать смешанные системы, включающие людей, компании и компьютеры. Мы можем описать проrраммную систему, управляе 
Вариант использования как соrлашение о поведении 25 мую дрyrой компьютерной системой, которая обращается к одушевленному вспомоrа тельному действующему лицу, или орrанизацию, которая обращается к компьютерной системе либо индивидууму. Это полезная обобщенная модель. Целей можно и не Аостиrнуть Что, повашему, будет делать служащий, разrоваривающий с клиентом по телефону, если компьютер отказывает во время записи запроса? Если система не может предо ставить обещанную услуry, служащий должен придумать резервную цель, в этом слу чае, вероятно, с помощью карандаша и бумаrи. Сохраняя за собой основную обязанность по работе, служащий должен иметь план на случай отказа системы. Точно так же система может столкнуться с отказом на пути к одной из своей под  целей. Возможно, основное действующее лицо дало неверные данные, может быть, это внутренняя неисправность или вспомоrательное действующее лицо не предоста вило обещанную услуry. Как же должна вести себя система? Это действительно ин тересная часть требований к поведению SuD. Иноrда сиСтема может устранить неисправность и вернуться к нормальному по ведению. В друrих случаях она должна просто отказаться от этой цели. Если вы идете к своему банкомату и пытаетесь извлечь больше денеr, чем есть у вас на счету, ваша цель выудить наличные просто не будет достиrнута. Ничеrо у вас не выйдет и при OT ключении банкомата от сети. Но если вы Bcero лишь ошиблись, набирая код, систе ма предоставит вам вторую попытку ввести код правильно. Такая фокусировка на неудачах в достижении целей и реакциях на неудачи объ ясняет, почему варианты использования являются хорошим описанием поведения системы и отличными функциональными требованиями в целом. Специалисты по функциональной декомпозиции и декомпозиции потоков данных отметили это как наиболее значительное преимущество, которое дали им варианты использования. ВзаИМОАействие имеет составную структуру Простейшее взаимодействие  это отправление сообщения: "Привет, Джин,  rоворю я, проходя по холлу. Это и есть простое взаимодействие. В процедурном проrраммировании простому взаимодействию соответствует вызов функции, Ha пример рriпt (значение). В объектноориентированном проrраммировании один объект посылает сообщение друrому, скажем, оЬjесtА>рriпt(значение). Последовательность сообщений, или сценарий  это составное взаимодей ствие. Предположим, я иду к автомату с rазированной водой, опускаю в Hero долла ровую банкноту за 80центовый напиток и получаю сообщение, что нужно опустить точную сумму. Вот мое взаимодействие с автоматом: 1. Я опускаю долларовую банкноту. 2. Нажимаю кнопку "cola". 3. Автомат требует точную сумму мелочью. 4. Я нажимаю на "Возврат монет". 5. Автомат возвращает доллар монетами. 6. Забираю монеты и ухожу. 
26 rлава 2 Можно сжать последовательность, как если бы это был единственный шаr ("Я по пытался купить колу в автомате, но он потребовал точную сумму"), и развернуть этот сжатый шаr в более длинную последовательность: 1. Я пошел в банк компании и взял некоторую сумму. 2. Попытался купить колу в автомате, но тот потребовал точную сумму. 3. Прошел до кафетерия и купил воду там. Таким образом, при необходимости взаимодействие можно свернуть или, напро тив, разбить на шаrи, как позволяют цели. Каждый шаr сценария фиксирует цель, и поэтому каждый шаr можно развернуть как отдельный вариант использования. Так что взаимодействия напоминают блох, у которых есть блохи, да и цели тоже. Удобно то, что поведение системы можно представить на весьма высоком уровне обобщения, коrда цели и взаимодействия находятся в свернутом виде. Постепенно развертывая их, можно описать поведение системы сколь уrодно точно. Я часто Ha зываю набор вариантов использования постоянно разворачивающейся историей. Наша задача  писать эту историю так, чтобы читатель леrко в ней ориентировался. Я использую слово последовательность в широком смысле. Во мноrих случаях взаимодействия не обязательно должны происходить в KaKOMTO определенном по рядке. Чтобы купить воду за 80 центов, я Mor бы опустить восемь монет по 10 цeH тов, три монеты по 25 центов и монету в 5 центов либо... (можете продолжить список). Не имеет значения, какую монету опускать первой. CTporo rоворя, последовательность  не совсем подходящее слово. Правиль ный математический термин  "частичное упорядочение". Однако слово после довательность точнее по смыслу и rораздо леrче воспринимается теми, кто пишет варианты использования. Если ктонибудь спросит вас о сообщениях, которые MOryт поступать одновременно, попросите кратко написать об этом. Посмотрите, с чем они к вам придут. Мой опыт показывает, что люди создают удивительно ясные описания после весьма непродолжительноrо обучения. Поэтому я продолжаю употреблять слово последовательность. Пример сложных последовательностей вы найдете в Ba рианте использования 22. С формальным языком для вариантов использования дело обстоит не так про сто. Большинство разработчиков языков либо заставляют пишущеrо варианты испо льзования перечислять все возможные порядки, либо изобретают сложные нотации для произвольноrо порядка событий. Мы создаем варианты использования для лю дей, а не для компьютеров, поэтому просто пишем: "Покупатель опускает 80 центов пятицентовыми, десятицентовыми или двадцатипятицентовыми монетами в любом порядке" . Последовательности хороши для описания взаимодействий в прошлом, посколь ку прошлое ПОЛНОСтью определено. Чтобы описать взаимодействия в будущем, необ ходимы наборы возможных последовательностей, по одной для каждоrо условия, которое может коrдалибо возникнуть. Если я вам рассказываю о том, как вчера про сил повышения, я rоворю: "Вчера я имел серьезный разrовор с боссом. Я сказал... Она сказала... Я сказал...", и Т.д. 
Вариант использования как соrлашение о поведении 27 Но о будущем я расскажу так: "Меня действительно беспокоит предстоящий разrовор с боссом". "Почему?" "Я собираюсь просить повышения". "Как?" "Ну, сначала я скажу... Затем, если она скажет..., я отвечу...". "Но если она скажет..., я попробую...", и Т.д. Точно так же, объясняя комулибо, как купить содовой воды, мы скажем: "Прежде Bcero, запаситесь монетами". "Если у вас есть точная сумма, опустите монеты в автомат инажмите кнопку "соlа". "Если нет, опустите деньrи и посмотрите, сможет ли автомат дать сдачи. Если да..." Чтобы описать взаимодействие в будущем, придется иметь дело с различными условиями, создавая наборы последовательностей. Для каждой последовательности мы указываем условие, саму последовательность и результат. Можно спрятать набор последовательностей в одном предложении: "Сначала пойдите купить воды в автомате". Или: "Затем попросите у босса повышение". Как и с последовательностями, эти предложения можно вместить в краткое описание BЫ cOKoro уровня обобщения или развернуть их в подробное описание в соответствии с нашими потребностями. Теперь вы знаете, что вариант использования содержит набор возможных cцe нариев для достижения цели. Для завершенности добавим: . Все взаимодействия имеют отношение к одной и той же цели одноrо и Toro же OCHoBHoro действующеrо лица. . Вариант использования начинается с инициирующеrо события и продолжает ся, пока цель не достиrнута или ее достиженне не прервано и система не OCBO бождается от своих обязательств по отношению к данному взаимодействию. Вариант использования как сборник сценариев у OCHoBHoro действующеrо лица есть цель; система должна помоrать действующе му лицу достичь этой цели. Некоторые сценарии приводят к достижению заданной цели; друrие заканчиваются, если цель оказывается недостижимой. Каждый сцена  рий содержит последовательность шаrов, показывающих, как раскрываются дей ствия и взаимодействия. Вариант использования собирает все эти сценарии вместе, показывая все пути, которые MOryт привести или не привести к цели. Рассмотрим "полосатые брюки" (рис. 2.2). Ремень на брюках указывает цель, которая объединяет все ценарии. Из двух половинок брюк одна предназначена для 
28 r лава 2 сценариев, которые приводят к успеху, а друrая  для сценариев, которые кончают ся неудачей. Подцель: Открыть кредит Определитьэапасы Рис. 2.2. "Полосатые брюки"  сценарии ПРИ80ДЯТ или не приводят к цели Каждая полоса соответствует одному сценарию и находится в части успехов или в части неудач. Назовем первую полосу на половинке успехов основным сценарием. Остальные полосы  это дрyrие сценарии, в конце концов приводящие к успеху, He которые альтернативными путями, друrие  справившись с промежуточным OTKa зом. Каждая полоса на половинке неудач  это сценарий, в котором возникает сбой, после KOToporo он, возможно, восстановится, но завершится всетаки неудачей. На самом деле мы не будем отдельно писать каждый сценарий от начала дО KOH ца. Это нерациональная стратеrия, поскольку это утомительно и сложно поддержи вать. "Полосатые брюки" помоrают понять, что каждый вариант использования имеет два исхода, что цель OCHoBHoro действующеrо лица связывает все сценарии и что каждый сценарий  это простое описание цели, достиrаемой или нет. На рис. 2.3 я дополнил "полосатые брюки" подчиненными вариантами исполь зования, входящими в основные, которые их вызывают. Заказчик хочет разместить заказ. Одна из подцелей заказчика  открыть кредит. Это подцель сложная и может быть достиrнута или нет: вариант использования, который мы свернули в единствен  ный шаr. Шаr "заказчик открывает кредит"  это ремень на друrих брюках. В поло се, или сценарии, этоrо шаrа подцель либо достиrается, либо нет. В сценариях 1 и 2 на рисунке подцельдостиrается. В сценариях 3 и 7  нет. В сценарии 3, однако, сле дующая подцель для определения запасов достиrается, и вариант использования в целом завершается успешно. В сценарии 7 вторая попытка тоже не удается, и пол ный вариант использования для размещения заказа завершается неудачей. Полоски на подчиненных вариантах использования (см. рис. 2.3) показывают, что внешнему варианту использования как бы все равно, какой подчиненный вари ант использования выполняется в ero рамках. Подчиненный вариант при водит к успеху либо к неудаче. Внешний, или вызывающий, вариант использования просто основан на успехе либо на неудаче шаrа, определяемоrо подчиненным вариантом использования. 
Вариант использования как соrлашение о поведении 29 Подцель: Открыть кредит Рис. 2.3. "Полосатые брюки" с подцелями Основные идеи, которые следуют из аналоrии с "полосатыми брюками", таковы: . Некоторые сценарии приводят к успеху, друrие к неудаче. . Вариант использования собирает вместе все сценарии, успешные и заканчивающиеся неудачей. . Каждый сценарий  это непосредственное описание одноro набора обстоя тельств с одним исходом. . Варианты использования содержат сценарии (полосы на брюках), а сценарий содержит подчиненные варианты использования в качестве своих шаrов. . На шаr сценария не влияет, какая полоса в подчиненном варианте использова нин была задействована. Влияет лишь результат закончился вариант успе хом либо неудачей. Эти основные идеи прослеживаются на протяжении всей книrи. 2.2. Соrлашение меЖАУ участниками, имеющими интересы Модель Действующие лица и цели объясняет, как писать предложения в варианте использования, но не касается необходимости описывать внутреннее поведение разрабатываемой системы. По этой причине модель Действующие лица и цели сле дует расширить. Здесь важно, что варианты использования можно рассматривать как cor лашение между участниками, имеющими свои интересы. Расширенную мо- дель я буду называть концептуальной моделью Участники и интересы. Блок уча стников и интересов определяет, что включить в вариант использования и что нет. SuD реализует соrлашение между участниками, причем варианты использова ния детализируют поведенческую часть этоrо соrлашения. Во время работы системы 
30 rлава 2 присутствуют не все участники. Обычно присутствует основное действующее лицо, но не всеrда. Друrие участники отсутствуют, поэтому их можно назвать действую щими лицами вне сцены. Система работает, чтобы удовлетворить интересы этих действующих лиц, ВКЛючая сбор информации, проведение проверок достоверности и обновление журналов (рис. 2.4). Банкомат должен вести журнал всех взаимодействий, чтобы защитить участни ков в случае разноrласий. Он записывает и друryю информацию, поэтому можно определить, как далеко зашла транзакция перед сбоем. Банкомат и банковская сис тема проверяют, имеет ли держатель счета соответствующий капитал, прежде чем вьщать ему наличные. Это rарантирует, что банкомат не вьщаст больше денеr, чем есть на счету этоrо клиента. Вариант использования как соrлашение о поведении охватывает в полном объе ме поведение, связанное с удовлетворением интересов участников, и только ero. Чтобы тщательно выстроить вариант использования, перечислим всех участни ков, назовем их интересы в Связи с функционированием варианта использования и установим, что значит для каждоrо участника успешное завершение варианта испо льзования и какие rарантии они хотят получить от системы. Разобравшись с этим, напишем шаrи варианта использования с rарантией, что все интересы удовлетворя ются от момента инициирования варианта использования до ero окончания. Так определяется, коrда начинать и коrда заканчивать описание, а также что включать или не включать в вариант использования. Большинство людей не пишут варианты использования так кропотливо, и часто им это сходит с рук. Опытные писатели проделывают это упражнение в rолове, коrда пишут бессистемные варианты использования. Они, возможно, опускают некоторые вещи, но учитывают их при разработке проrраммноrо обеспечения. Однако иноrда это дороrо обходится, как в истории, описанной в разделе 4.1. @ )( 8ввсти заказ  Разрабаваемая система Основное действующее лицо хочет... Рис. 2.4. sиD обслуживает основное действующее лицо, защищая интересы действующих лиц вне сцены Чтобы удовлетворить интересы участников, должны быть описаны три вида дей ствий: 
Вариант использования как соrлашение о поведении 31 . Взаимодействие между двумя действующими лицами (чтобы содействоватьдо стижению цели) . Проверка достоверности (чтобы защитить участника) . Изменение BHyтpeHHero состояния (от имени участника) Модель Участники и интересы вносит лишь небольшое изменение в общую про цедуру создания варианта использования: перечень участников и их интересов и ис пользование этоrо перечня в качестве двойной проверки для rарантии, что ничто не пропущено в тексте варианта использования. Это изменение существенно влияет на качество варианта использования. 2.3. rрафическая модель Этот раздел предназначен только для тех, кому нравится строить абстрактные MO дели; ero можно пропустить. Вариант использования описывает соrлашение о поведении между участниками, имеющими интересы. Мы орrанизуем поведение с помощью функциональных целей избранноrо множества участников (тех, кто попросит систему чтонибудь сделать для них). Этих участников мы называем основными действующими лицами. Название варианта использования  это цель OCHoBHoro действующеrо лица. В варианте ис пользования содержатся все аспекты поведения, необходимые для описания этой ча сти соrлашения. У системы есть обязанность удовлетворять oroBopeHHble соrлашением интере сы обусловленных соrлашением участников с их действиями. Действия бывают трех типов: . Взаимодействие между двумя действующими лицами, при котором информация может передаваться назад или вперед. . Проверка достоверности, чтобы защитить интересы одноrо из участников. . Изменение BнyтpeHHero состояния для защиты ИlIтереса участника. Сценарий состоит из шаrов действия. В сценарии успеха все (обусловленные соrлашением) интересы участников удовлетворяются вследствие обслуживания, KO торое сценарий обязан выполнять. В сценарии неудачи все интересы защищаются в соответствии с rарантиями системы. Сценарий завершается, коrда все интересы уча стников удовлетворены или защищены. Три триrrера, которые запрашивают достижение цели, являются основным дей ствующим лицом, инициирующим взаимодействие с системой, основным действую щим лицом, использующим посредника для инициирования взаимодействия, или временным триrrером либо триrrером состояния. Модель вариантов использования, описанная в этой rлаве, показана на рис. 2.5  2.8. Здесь используется унифицированный язык моделирования UML. 
32 rлава 2 Вcnомоraтельное (второстепенное) действующее лицо Основное Действующее действующее ЛИЦО вне сцены ЛИцо (тpeTbВro плана) Рис. 2.5. Действующие лица и участники. Участник имеет интересы. Действующее лицо характеризуется поведением. Основное действующее лицо OДHOBpe менно является участником Рис. 2.6. Поведение. Ориентированное на цель поведение включает обязанности, цели и действия. Частные действия, о которых мы пишем, содействуют или защи щают интересы участников. Взаимодействия соединяют действия oAHoro дей ствующеrо лица с действиями Apyroro 
Вариант использования как соrлашение о поведении 33 Обязанность Основное действующее лицо Вариант использования Рис. 2.7. Вариант использования как инициирование обязанности. Вариант использо вания фиксирует цель OCHoBHoro действующеrо лица и обращается к sиD для выполнения ее соответствующей обязанности Набор последоватеЛbl1остей (вариант использования) Последова тельность (сценарий) Простое сообщение Действующее * лицо Рис. 2.8. Взаимодействия как композиция. N действующих лиц взаимодействуют. Взаимодействия можно разложить на варианты использования, сценарии и простые сообщения. Термин "последовательность" употребляется для удобства Это абстрактная модель. Я не знаю, как ее отлаживать. Mory лишь предложить несколько лет тестировать ее на проектах, используя основанный на модели инстру мент. Друrими словами, она, вероятно, содержит несколько неуловимых ошибок. Я включил ее для тех, кто Хочет поэкспериментировать и, возможно, создать такой основанный на модели инструмент. 
rлава з Область действия Термин область действия (scope) обозначает rраницы нашеrо проекта, в проти воположность тому, что проектирует KTOTO еще, или тому, что уже существует. Отследить область действия проекта или даже только область рассуждения о нем может быть непросто. Консультант Роб Томсетт познакомил меня с инструмен том для управления обсуждением области действия  списком Внутри/Вне. Этот простой и эффективный инструмент можно использовать для управления обсуждени ем области действия на обычных совещаниях, а также при обсуждении требований проекта. Постройте таблицу с тремя колонками. Левая колонка содержит название пред мета обсуждения, следующие две колонки называются Внутри и Вне. Всякий раз, коrда вы сомневаетесь, входит ли предмет в область обсуждения, добавьте ero в таб лицу и посоветуйтесь с коллеrами, внутри он или вне области обсуждения. Пока каждому сотруднику не станет совершенно ясно, rде находится предмет, мнения pac ходятся. По словам Роба, иноrда требуется обратиться в орrкомитет проекта, чтобы установить, действительно ли определенный предмет находится внутри области дей ствия разработки. От Toro, rде именно находится предмет, срок разработки может увеличиться или уменьшиться на MHoro месяцев. Попробуйте применить этот метод в вашем проекте или, скажем, на следующем совещании. В таблице 3.1 представлен пример списка Внутри/Вне, который мы составили для системы отслеживания запросов на покупку. Используйте этот список с caMoro начала работы над требованиями или вариан тами использования, чтобы отделить вопросы, входящие в область действия данноrо проекта, от тех, которые в нее не входят. Обращайтесь к списку всякий раз, коrда обсуждение rрозит уйти в сторону, или дискуссия разворачивается BOKpyr требова ния, отношение KOToporo к данной области действия вызывает сомнение. Обновляй те список по ходу дела. Используйте список Внутри/Вне для предметов, относящихся как к функциона  льной области действия, так и к области проектирования разрабатываемой системы. 
Область действия Таблица 3.1. Пример списка Внутри/Вне Предмет Выписывание счета в любой форме Формирование отчетов о запросах (например, по поставщику, по детали, по заказчику) Объединение запросов в один денежный перевод по почте Частичные доставки, опоздавшие доставки, неправильные доставки Все новые услуrи системы, nporpaMMHoe обеспечение Любые части системы, не относящиеся к nporpaMMHoMY обеспечению Определение любоrо ранее разработанноrо nporpaM MHoro обеспечения, которое можно использовать Заявки 35 Внутри Вне Вне Внутри Внутри Внутри Внутри Вне Внутри Внутри 3.1. Функциональная область действия Функциональная область действия относится к услуrам, которые предоставляет ваша система и которые в конце концов будут зафиксированы в вариантах исполь зования. Поскольку вы только начинаете разрабатывать проект, вполне вероятно, что вы не знаете деталей. Вы определяете функциональную область действия OДHO временно с созданием вариантов использования, эти две задачи переплетены. Спи сок Внутри/Вне помоrает решить эти задачи, так как позволяет провести rраницу между тем, что внутри области действия и тем, что вне этой области. Два друrих ин  струмента  это список Действующее лицо/Цель и Краткое описание BapиaH mов использования. Список Действующее лицо/Цель В списке Действующее лицо/Цель перечислены все цели пользователя, которые поддерживает система, иными словами, ее функциональное содержание. Список Внутри/Вне показывает, находятся ли ero элементы в соответствующей области действия. В отличие от Hero список Действующее лицо/Цель включает лишь те услуrи, которые действительно будут поддерживаться системой. В таблице 3.2 представлен список Действующее лицо/Цель ДЛЯ одноrо из проектов системы OT слеживания запросов на покупки. Чтобы создать этот список, постройте таблицу из трех колонок. Впишите имена основных действующих лиц (это те, кто имеет цели) в левую колонку, в среднюю BBe дите цель каждоrо действующеrо лица по отношению к системе, а в третью колонку  приоритет, или первоначальное предположение, в какой версии система будет под держивать эту цель. Обновляйте этот список непрерывно в течение всей работы над проектом, чтобы он всеrда отражал состояние функциональных rраниц системы. 
36 rлава 3 Иноrда добавляют дополнительные колонки: триееер, указывающий варианты использования, которые будут запускаться в соответствующее время, а не какимто лицом; бизнесприоритет; сложность разработки; приоритет разработки, чтобы раз делить потребности бизнеса и стоимость разработки для определения ее приоритета. Таблица 3.2. Пример списка Действующее лицо/Цель Действующее ПИЦО Цеп.. УРОВНSI задачи Любое Проверять запросы Уполномоченное Изменить полномочия лицо Покупатель Изменить контакты с поставщиком Инициатор запроса Инициировать запрос Изменить запрос Отменить запрос 4 Отметить доставку заказа 4 Отказаться от доставленных товаров 4 Утверждающее лицо Закончить оформление запроса 2 для подачи Приоритет 2 з 1 Покупатель Завершить запрос для размещения заказа Уполномоченное Лицо Приемщик Инициировать перевод денеr поставщику 1 Сиrнализировать о недоставке 4 Проверить достоверность подпис 3 и утверждающеrо лица Зареrистрировать доставку Список Действующее лицо/Цель  это отправная точка переrоворов между представителем пользователя, финансовым спонсором и rруппой разработки. Он фокусирует внимание на планировании и содержании проекта. Краткие описания вариантов использования я буду постоянно напоминать о том, как важно управлять своими силами и, коrда возможно, работать с низким уровнем точности. Список Действующее лицо/Цель представляет собой низший уровень точности описания поведения системы. Он очень полезен для работы с общим описанием системы. Следующий уровень точности будет либо основным сценарием, либо кратким описанием варианта использования. Краткое описания варианта использования  это описание поведения варианта использования в двухшести предложениях, rде упоминаются лишь наиболее значи тельные действия и сбои. Оно напоминает разработчикам о том, что делается в вари анте использования, и полезно для оценки сложности работы. rруппы, строящие новую систему из rOToBblx коммерческих компонентов (COTS), используют это оп и  
Область действия 37 сание при выборе компонентов. Некоторые проектные rруппы, например, имеющие очень хорошо налаженный внутренний обмен информацией и постоянное общение с пользователями, никоrда ничеrо не пишут сверх этих кратких описаний вариантов использования в качестве требований. Остальная информация для требований появ ляется в ходе непрерывных обсуждений, представлена прототипами и реryлярно по ставляемыми дополнениями. Таблица 3.3. Пример кратких описаний вариантов использования Действующее пицо Производственная rpynna Производственная rpynna Производственная и полевая rpYnnbI Цеп.. Модифицировать схему администра тивноrо реrиона Подrотовить цифро вые картоrрафиче ские исходные данные в рабочей базе дaH ных зафиксировать транзакции обнов ления при COBMeCT ной отладке Краткое описание Производственная rpynna добавляет опи сание административноrо реrиона (адми нистративное деление, денежное обращение, код языка, типы улиц и т.д.) В справочную базу данных. Контактная информация об источнике данных поме щается в каталоr. Это особый случай MO дификации справочных данных Производственная rpynna преобразует внешние цифровые данные в стандартный формат, проверяет и корректирует их, подrотавливая для слияния с рабочей базой данных. Данные каталоrизированы и xpa нятся в исходной цифровой библиотеке rpynna применяет накопленные транзак ции обновления к рабочей базе данных. Транзакции без конфликтов фиксируются в рабочей базе данных. Контекст прило жения синхронизируется с рабочей базой данных. Фиксируемые транзакции очи щаются от контекста приложений, coxpa няя совместимость рабочей базы данных, причем конфликтующие TpaH закции можно уреrулировать вручную либо интерактивным путем O)кHO подrотовить краткое описание варианта использования как таблицу, расширение списка Действующее лицо/Цель или непосредственно в виде части тела варианта использования в первом приближении. Пример KpaTKoro описания из таб лицы 3.3 любезно предоставлен Полом Фордом, Стивом Янrом и Полом Бузайдом из компании Navigation Technologies. 3.2. Область действия проектирования Область действия проектирования  это рамки системы, я бы сказал "пространст венные рамки", если бы проrраммное обеспечение занимало пространство. Это множество систем, аппаратных и проrраммных, которые мы должны проектиро вать или обсуждать. Если мы разрабатываем банкомат, нам следует про извести 
38 rлава 3 оборудование и проrраммное обеспечение, которые находятся в корпусе. Корпус и все, что в нем  это то, что разрабатываем мы. Компьютерная сеть, с которой бу дет общаться банкомат, не входит в рамки нашей разработки, лежит вне нашей об ласти действия проектирования. Далее под областью действия подразумевается область действия пpoeK тирования, потому что функциональная область действия адекватно определяется списком Действующее лицо/Цель и вариантами использования. Область действия проектирования имеет отношение к каждому варианту использования. Очень важно, чтобы писатель и читатель понимали область действия проектиро вания варианта использования одинаково и правильно. Ошибка может увеличить стоимость проекта в несколько раз и привести к катастрофическому результату KOHT ракта. Читатели варианта использования должны быстро понять, что вы включаете в рамки системы. Только из названия варианта использования или OCHoBHoro действу ющеrо лица это ясно не будет. Даже внутри одноrо и Toro же множества вариантов использования обнаруживаются системы различноrо масштаба. Обычно писатели считают область действия системы настолько очевидной, что даже не упоминают ее. Однако это не так. Один автор думает, что областью действия является вся корпорация (см. рис. 3.1), друrой считает областью действия все про rpaMMHbIe системы компании, третий подразумевает под ней новую систему кли eHTcepBep, Torдa как четвертый думает только о клиенте либо только о сервере. Читатели, которые не знают об этих значениях по умолчанию, плохо ориентируются в таком документе или неправильно ero понимают. · Невымышленная НСJОрНЯ Чтобы помочь составить заявку на подряд для разработки большой системы в заданное время и с фиксированными затратами, мы разобрали HeKOTO рые примеры проектов. Я выбрал принтер и описал ero функцию. Эксперт по информационным системам рассмеялся. "Вы, привыкшие к персонально му компьютеру, с ума меня сведете",  сказал он. "Вы что думаете, мы используем маленький лазерный принтер, чтобы печатать наши счета? У нас оrромная система печати с цепным печатающим устройством, очередью ввода/вывода и прочим. Мы производим счета коробками!" Я был потрясен. "Вы хотите сказать, что принтер не входит в область дей ствия системы?" "Конечно, нет! Мы будем использовать систему печати, которая у нас уже есть". В самом деле, мы обнаружили сложный интерфейс с системой печати. Наша система должна была подrотавливать маrнитную ленту с файлами для печати. Ночь напролет система печати читала бы ленту и делала распе чатки. Она бы подrотавливала еще одну ленту с описанием результатов печати и неверными записями, которые не смоrла распечатать. На Сliеду ющий день наша система читала бы результаты и отмечала, что распечата но неправильно. Работа по проектированию интерфейса к этой ленте была существенной и абсолютно не похожей на то, что мы ожидали. 
Обл8СТЬ действия 39 Нам не надо было проектировать систему печати, но следовало использо вать ее. Система не входила в область действия нашеrо проекта (она была вспомоrательным действующим лицом; см. раздел 3.3). Если бы мы не обнаружили эту ошибку, то написали бы вариант использования, чтобы включить ее в нашу область действия проектирования, и нам бы пришлось разрабатывать больше систем, чем было необходимо. Компания @ )( Компьютерные системы @ )( Наше приложение Друrая компания Друrой отдел Друrие приложения Подсистема Рис. 3.1. Область действия проектировання может быть любоrо размера Что можно сделать, чтобы правильно понять документ? Единственный ответ, который я нашел  это снабдить каждый вариант исполь зования меткой ero области действия проектирования с помощью особых имен для наиболее значительных областей действия. Предположим, что компания MyTelCo проектирует систему NewApp, которая включает подсистему Searcher. Ниже следуют имена областей действия проектирования: . Предприятие (MyTeICO)". Вы обсуждаете поведение целой орrанизации или предприятиядля достижения цели OCHoBHoro действующеrо лица. Запиши те в поле Область действия варианта использования название орrанизации (MyTelCo), а не просто "компания". Обсуждая отдел, употребляйте ero назва  ние. Варианты использования для бизнеса пишутся в области действия преk приятия. . Система (NewApp) l1li . Это оборудование или проrраммное обеспечение, KO торое вам поручили разрабатывать. Вне системы находятся все части оборудо вания, проrраммноrо обеспечения и людских ресурсов, с которыми система должна взаимодействовать. . Подсистема (Seacher) .. Вы раскрыли rлавную систему и собираетесьрас смотреть, как работает ее часть. 
40 rлава 3 Использование rрафических пиктоrрамм АЛЯ ВЫАеления области Аействия проектирования Рассмотрим значки, присоединяемые слева к названию варианта использования для предварительноrо информирования читателя относительно области действия проеКТИ!Jования. Пока нет инструментов управления значками, но я считаю, что они уменьшают путаницу. В данной книrе я снабдил каждый вариант использования соответствующей пиктоrраммой, чтобы вам леrче было заметить ero область дей ствия. Коrда вы будете читать следующий список, помните, что в варианте использова ния "черный ящик" не обсуждается внутренняя структура разрабатываемой систе мы, в противоположность варианту использования "прозрачный ЯЩИК". . Областью действия варианта использования для бизнеса является предприя- тие. Обозначается пиктоrраммойдомика.Домик будет серым, если вы paCCMaT риваете предприятие в целом как "черный ящик". Если вы rоворите об отделах и о персонале предприятия, оставьте домик белым. . Область действия варианта использованиядля системы  это компьютерная система. Значок  ящик: серый, если вы трактуете систему как "черный ящик", и белый, если вы касаетесь работы ее компонентов. . Вариант использованиядля компонента относится к подсистеме или к компо- ненту разрабатываемой системы. В качестве rрафическоrо символа компонен та используется болт (см. варианты использования 13  17). Примеры области Аействия проектирования Рассмотрим три примера, иллюстрирующих системы с различными областями дей- ствия проектирования. (1) 06пасть действия предприятие  система Предположим, мы работаем на телефонную компанию Му , TelCo которая разрабаты вает новую систему Acura для приема заказов на обслуживание и модернизацию. Acura состоит из рабочей станции, подключенной к серверу. Сервер будет соединен с мэйнфреймом, на котором работает старая система BSSO. Система BSSO представ ляет собой обычный терминал, подключенный к мэйнфрейму. Нам не разрешили вносить в нее какие-либо изменения, мы можем только использовать ее интерфейсы. К основным действующим лицам для Acura относятся клиент, служащий, раз- личные администраторы и BSSO (последняя вне нашей области действия). Определим цели, которые должна подцерживать система. Наиболее очевидная  "добавить новую услуry". Основным действующим лицом для этой цели будет служа- щий компании, действующий от имени заказчика. Создадим несколько вариантов ис- пользования. Теперь нужно установить, что представляет собой разрабатываемая система. Оказывается, нас интересуют две вещи: 
)бласть действия 41 . MyTelCo. Нам хотелось бы знать, как выrлядит д.тIЯ пользователя обслужива ние компанией MyTelCo, как реализуются новые уcлyrи в полной форме  от первоначальноrо запроса до выполнения и предоставления. Этот вопрос инте ресен вдвойне. Администраторы компании захотят узнать, какой представляет- ся новая система внешнему миру, а rруппа разработчиков  увидеть контекст, в котором будет существовать новая система. Этот вариант использования будет написан д.тIЯ области действия предприя- тия (е), причем в поле области действия будет записано MyTelCo, и в вари анте использования не будут упомянуты внутренние действующие лица (служащие, отделы, компьютеры). Этот вид варианта использования часто называют вариантом использования д.тIЯ бизнеса, так как он описывает дея тельность предприятия. . Acura. Нам хотелось бы знать, что представляет собой обслуживание этой сис темой с точки зрения служащеrо или клиента, с одиой стороны, и с точки зрения системы BSSO, с друrой. К этому варианту использования разработчики OTHO сятся с наибольшим вниманием, так как он точно устанавливает, что они ДОk жны создавать. Вариант использования будет написан д.тIЯ области действия системы (11), в поле области действия будет записано Асша. В нем будут CBO бодио фиryрировать служащие, отделы и дрyrие компьютерные системы, но ни  как не подсистемы рабочей станции и сервера. Создадим два варианта использования. Чтобы не излаrать одну и ту же ин формацию дважды, напишем вариант использования д.тIЯ предприятия на бо- лее высоком уровне (знак воздушноrо змея), показывая, как MyTelCo отвечает на запрос, предоставляет услуry, возможно, даже записывает стои мость на счет клиента и получает оплату. Задача варианта использования д.тIЯ предприятия  показать контекст, в котором будет работать новая система. Далее подробно опишем обработку запроса в течение 520 мин в варианте использования д.тIЯ цели пользователя и области действия Асша. Вариант испопьэования 6 .. Добавить новую ycnyry (предприятие) ? Основное действующее пицо: клиент Обпасть действия: м у т elCo Уровень: обобщенный 1. Клиент звонит в MyTelCo, запрашивает новую услуrу... 2. MyTelCo предоставляет... и Т.д. Вариант испопьэования 7 11 Добавить новую ycnyry (Acura)  Основное действующее пицо: служащий (от имени внешнеrо клиента) Обпасть действия: Acura 
42 r лава 3 Уровень: цель пользователя 1. Клиент звонит в компанию, служащий обсуждает запрос с клиентом. 2. Служащий находит клиента в системе Acura. 3. Acura представляет текущий пакет услуr AaHHoro клиента... и Т.д. ... Для областей действия рабочей станции Acura или сервера Acura никаких вари- антов использования писать не будем, поскольку нам это не очень интересно. Позд нее ктонибудь из rруппы разработчиков может заняться документированием проекта подсистем Acura с помощью вариантов использования. Torдa они напишут два варианта использования  один для области действия рабочей станции Acura, друrой для области действия сервера Acura. Мой опыт показывает, что до подобных вариантов использования дело не доходит, так как существуют друrие адекватные способы документирования архитектуры подсистем. (1) Нескопько компьютеров на одно припожение Следующая ситуация не столь тривиальна и весьма сложна. Сделаем надстройку над ситуацией MyTelCo. Acura постепенно заменит BSSO. Запросы новой услуrи будут записыва  ться в Acura, а затем преобразовываться с помощью BSSO. Со временем набор функций Acura расширится. Эти две системы должны сосущество вать и синхронизироваться друr с друrом. Таким образом, варианты испо- льзования придется написать для обеих систем: для новой Acura и для модифицированной для синхронизации с ней BSSO. Сложность данной ситуации в том, что существуют четыре варианта И(пользова  ния: два для Acura и два дЛЯ BSSO. Есть один вариант использования для каждой си стемы со служащим в качестве OCHoBHoro действующеrо лица и друrой, в котором основное действующее лицо  это еще одна компьютерная система. Сократить эту четверку никак нельзя, но она смущает читателей, поскольку выrлядит избыточной. Чтобы документировать данную ситуацию, сначала я напишу вариант использова ния обобщенноrо уровня, чьей областью действия являются обе компьютерные систе- мы. Это даст мне возможность документировать их взаимодействие со временем. В этом варианте использования я буду обращаться к особым вариантам использования, которые включают каждое требование системы. Первый вариант использования будет иметь тип "прозрачный ящик" (обратите внимание на символ прозрачноrо ящика). Ситуация достаточно сложная, так что я включил диаrраммы области действия каждоrо варианта использования. Вариант испопьзования 8 В Ввести и обновить запросы (объединенная система) Р Основное действующее пицо: служащий (от имени внешнеrо клиента) Обпасть действия: компьютерные системы, включая Acura и BSSO (см. диаrрамму) 
Область действия 4з Уровень: обобщенный Основной сценарий: 1. Служащий добавляет новую услуrу в Acura. 2. Acura записывает запрос новой услуrи в BSSO. 3. Некоторое время спустя служащий обновляет запрос услуrи в BSSO. 4. BSSO записывает обновленный запрос в Acura. Компыотерные системы @  Acura Служащий 2 Служащий 1 Все четыре подчиненных варианта использования имеют уровень цели пользова  теля и отмечены символом уровня моря. Хотя все они  системные варианты исполь З0вания, но относятся к разным системам, отсюда и диаrраммы. В каждой диаrрамме я вьщелил основное действующее лицо и затенил разрабатываемую систему. На этот раз варианты использования являются "черными ящиками", так как представляют собой требования для новой разработки. Кроме Toro, я дал им различные названия с rлаrо лом записать, чтобы указать на синхронизацию систем друr с друrом. Варнант нспопьзовання 9 . Добавнть новую ycnyry (в Acura)  Основное действующее лицо: служащий (от имени внешнеrо клиента) Обпасть действия: Acura Уровень: цель пользователя ... тело варианта использования Компьютерные системы <w rc Служащий 1 Варнант нспопьзовання 1 О . Запнсать запрос на новую ycnyry (в BSSO)  Основное действующее лицо: Acura Обпасть действия: BSSO Уровень: цель пользователя ... тело варианта использования Компьютерные системы <w rc Служащий 1 Acura Варнант нспопьзовання 11 11 Обновнть запрос на обспужнванне (в BSSO)  Основное действующее лицо: служащий (от имени внешнеrо клиента) Обпасть действия: BSSO Уровень: цель пользователя ... тело варианта использования Компьютерные системы Acura <w )( Служащий 2 
44 rлава 3 Варнант нспопьзовання 12 111 Запнсать 06новпеннын запрос (в Acura)  Основное действующее nицо: BSSO Обnасть действия: Acura Уровень: цель пользователя Компьютерные системы ... тело варианта использования @ )( Служащий 2 Если вы используете UМLдиаrраммы вариантов использования, можете не писать, а рисовать вариант использования обобщенноrо уровня. Это все же не уменьшает путаницы с четырьмя вариантами использования для цели пользовате ля, поэтому для ка.ждоrо варианта следует записать основное действующее лицо, область действия и уровень. Может быть, стоит добавить диаrрамму области дей ствия. @ )( @ tc @ )( BSSO BSSO @ )( бновить запрос на обслуживание @ tc @ )( Записать новый запрос на обслуживание Acura Acura Рис. 3.2. Диаrраммы вариантов использования для Acиra8550. Это изображение взаимодействия двух систем в стиле UML. 8 верхнем блоке показано, что 8550  это вспомоrательное действующее лицо для oAHoro варианта использования системы Acиra и основное действующее лицо для Apyroro варианта использования. 8 нижней диаrрамме роли поменялись 
Область действия 45 Acura @ rc Записать обновленный запрос Служащий бновить запрос на обслуживание Рис. 3.3. Комбинированная Аиаrрамма варианта использования для AcиraBSSO. ЗАесь показаны связи четырех вариантов использования наиболее ясно, но эта Аиаrрамма не является стаНАартной, поскольку на ней ОАИН вариант использования системы запускает Аруrой Лично я не считаю, что это вносит ясность. Я бы предпочел нестандартную диа- rpaMMY варианта использования (см. рис. 3.3), чтобы показать связь двух систем. Эта диаrрамма более наrлядна, но ее труднее сопровождать. Диаrрамма должна помоrать вам и вашим читателям лучше понимать друr друrа. (3) Варнанты НСПОПЬЗ0вання "rайкн н 60ПТЫ" Посмотрим, как документируют структуру проекта с помощью вариантов использо вания. rруппа начала с 18страничноrо, полноrо диаrрамм описания правил для разрабатываемой системы. Было решено, что ero слишком трудно читать, и нача лись эксперименты с вариантом использования как методом описания. rруппа решала эту задачу неделю. Сначала они набросали 40 вариантов исполь- зования, чтобы охватить все запросы, которые может обрабатывать rлавная ЭВМ. Используя расширения и список изменения данных, они сократили количество вари антов использования до шести. Для большинства читателей эти варианты использования будут малопонятными. Полаrаю, однако, что среди них есть технарипроrраммисты, ищущие способы дoкy ментирования своих проектов. Поэтому я включил эти варианты использования, что бы показать, как эта rруппа документировала внутреннюю архитектуру и применяла список изменений. Обратите внимание, что подчиненные варианты использования подчеркнуты. Автор вариантов использования  Дэйл Марrел из Калrари. Общее опнсанне: Общая архитектура должна уметь решать параллельные задачи. Дnя этоrо она должна поддерживать потоки процессов и блокировку ресурсов. Эти функции выполняет система параллельноrо обслуживания (Concurrency Service Framework, CSF). CSF используется объектами клиента для защиты критичных разделов кода от небезопасноrо доступа со стороны множест ва процессов. 
46 rлава 3 Вар нант нспопьэовання 13 ()1/11IJ Орrаннэовать поспедоватепьнын доступ к ресурсу  Основное действующее пицо: объект клиента CSF Обпасть действия: система параллельноrо обслуживания (CSF) Уровень: цель пользователя Основной сценарий: 1. Клиент CSF запрашивает блокировку ресурса, чтобы обеспечить к нему определенный доступ. 2. Проrрамма блокировки ресурса возвращает управление клиенту CSF, чтобы он Mor использовать этот ресурс. З. Клиент CSF использует ресурс. 4. Клиент CSF информирует nporpaMMY блокировки ресурса о завершении работы с ресурсом. 5. ПО завершении работы клиента CSF nporpaMMa блокировки ресурса восстанавливает прежнее состояние ресурса. Расширения: 2а. Проrрамма блокировки ресурса обнаруживает I что клиент CSF уже имеет доступ к этому ресурсу: 2а1. Проrрамма блокировки ресурса применяет к запросу политику преобразования блокировки (вариант использования 14). 2Ь. Проrрамма блокировки ресурса обнаруживает, что ресурс уже используется: 2Ы. Проrрамма блокировки ресурса применяет политику совместимости (вариант использования 15), чтобы обеспечить доступ клиенту CSF. 2с. Время блокировки ресурса не истекло: 2с1. Проrрамма блокировки ресурса запускает таймер занятости. За. Заданный таймером занятости интервал истекает, прежде чем клиент информирует nporpaMMY блокировки ресурса, что он закончил работу: За1. Проrрамма блокировки ресурса посылает процессу клиента сообщение об исключительной ситуации. За2. Отказ! 4а. Проrрамма блокировки ресурса обнаруживает ненулевое значение счетчика блокировок у клиента CSF: 4а1. Проrрамма блокировки ресурса уменьшает значение счетчика обращений для запроса. 4а2. Успех! 5а. Проrрамма блокировки ресурса обнаруживает, что ресурс в настоящий момент не используется: 5а 1. Проrрамма блокировки ресурса применяет политику выбора доступа (вариант использования 16) для предоставления доступа одному из стоящих в очереди клиентов. 5Ь. Таймер занятости все еще работает: 
Обл8СТЬ действия 47 5Ы. Проrрамма блокировки ресурса отменяет таймер занятости. Список изменений в технопоrии и данных: 1. Указанный в запросе доступ может быть: . Монопольный . Совместный 2с. Таймаут в блокировке ресурса может определять: . Клиент CSF . Политика блокировки ресурса · rлобальное значение по умолчанию Варнант нспопьзовання 14 ()1/11IJ Прнменнть попнтнку прео6разовання 6покнровкн  Основное действующее пицо: объект клиента CSF Обпасть действия: система параллельноrо обслуживания (CSF) Уровень: подфункция Основной сценарий: 1. Проrрамма блокировки ресурса проверяет, является ли запрашиваемый доступ монопольным. 2. Проrрамма блокировки ресурса проверяет, не имеет ли уже клиент CSF cOBMecTHoro доступа к ресурсу. З. Проrрамма блокировки ресурса проверяет, нет ли клиента CSF, ожидающеrо повышения уровня доступа. 4. Проrрамма блокировки ресурса проверяет, нет ли друrих клиентов CSF, разделяющих данный ресурс. 5. Проrрамма блокировки ресурса предоставляет клиенту CSF монопольный доступ к ресурсу. 6. Проrрамма блокировки ресурса увеличивает значение счетчика блокировок для клиента CSF. Расширения: 1а. Проrрамма блокировки ресурса обнаруживает, что запрашивается совместный доступ: 1а1. Проrрамма блокировки ресурса увеличивает значение счетчика блокировок для клиента CSF. 1а2. Успех! 2а. Проrрамма блокировки ресурса обнаруживает, что клиент CSF уже имеет монопольный доступ: 2а1. Проrрамма блокировки ресурса увеличивает значение счетчика блокировок для клиента CSF. 2а2. Успех! За. Проrрамма блокировки ресурса обнаруживает, что существует друrой клиент CSF, ожидающий повышения уровня доступа: 
48 rлава 3 За 1. Сиrнализировать клиенту, что запрошенный доступ не может быть предоставлен. За2. Отказ! 4а. Проrрамма блокировки ресурса обнаруживает, что существуют друrие клиенты CSF, использующие ресурс: 4а1. Проrрамма блокировки ресурса переводит клиент в режим ожидания доступа к ресурсу (вариант использования 17). Вариант испопьэования 15 ()1/11IJ Применить попитииу совместимости доступа  Основное действующее nицо: объект клиента CSF Обnасть действия: система параллельноrо обслуживания (CSF) Уровень: подфункция Основной сценарий: 1. Проrрамма блокировки ресурса проверяет, запрашивается ли совместный доступ. 2. Проrрамма блокировки ресурса проверяет, используется ли в настоящий момент ресурс как совместный. Расширения: 2а. Проrрамма блокировки ресурса обнаруживает, что запрашивается монопольный доступ: 2а1. Проrрамма блокировки ресурса переводит клиент в режим ожидания доступа к ресурсу (вариант использования 17). Процесс возобновляется позже в результате проведения стратеrии обслуживания блокировки. 2Ь. Проrрамма блокировки ресурса обнаруживает, что в данный момент ресурс используется монопольно: 2Ы. Проrрамма блокировки ресурса переводит клиент в режим ожидания доступа к ресурсу (вариант использования 17). Изменения: 1. Критерий совместимости может изменяться. Вариант испопьэования 16 (pmл Применить попитииу выбора доступа  Основное действующее nицо: объект клиента CSF Обnасть действия: система параллельноrо обслуживания (CSF) Уровень: подфункция Основной сценарий: Цепь в контексте: nporpaMMa блокировки ресурса должна определять, какой запрос в режиме ожидания (если таковые имеются) следует обслужить. 
Область действия 49 Примечание: эта стратеrия может меняться. 1. Проrрамма блокировки ресурса выбирает эапрос, который ожидает дольше всех. 2. Проrрамма блокировки ресурса предоставляет доступ выбранному запросу (выбранным запросам), делая соответствующий процесс работоспособным. Расширения: 1а. Проrрамма блокировки ресурса не находит ожидающих запросов: 1а1. Успех! 1 Ь. Проrрамма блокировки ресурса обнаруживает запрос, ожидающий повышения уровня доступа от разделяемоrо до монопольноrо: 1 Ь 1. Проrрамма блокировки ресурса выбирает запрос на повышение уровня доступа. 1 с. Проrрамма блокировки ресурса выбирает запрос на разделяемый доступ. 1 с 1. Проrрамма блокировки ресурса повторяется (шаr 1), пока не выберет следующий запрос на монопольный доступ. Изменения: 1. Критерий выбора может изменяться. Вариант ИСПОПЬЗ0вания 17 . Перевести кnнeнT в режим ожидания доступа к ресурсу  Основное действующее лицо: объект клиента CSF Область действия: система параллельноrо обслуживания (CSF) Уровень: подфункция Основной сценарий: Используется: проrраммой блокировки ресурса СС 2,4 1. Проrрамма блокировки ресурса приостанавливает процесс клиента CSF. 2. Клиент CSF ждет возобновления процесса. З. Процесс клиента CSF возобновлен. Расширения: 1 а. Проrрамма блокировки ресурса обнаруживает, что был определен таймаут ожидания: 1а1. Проrрамма блокировки ресурса запускает таймер. 2а. Время ожидания истекает: 2а1. Сиrнализировать клиенту CSF, что запрошенный доступ не может быть предоставлен. 2а2. Отказ! Список изменений в технолоrии и данных: 1 а 1. Т аймаут ожидания блокировки может определять: · Клиент CSF 
50 rлава 3 · Политика блокировки ресурса · rлобальное значение по умолчанию 3.3. ПреАельные варианты использования В подразделе Область действия предприятие  система я рекомендовал писать два варианта использования: один для разрабатываемой системы, а друrой  для внешней области действия. Теперь мы можем более конкретно поrоворить о том, как для каждоrо варианта использования найти самую ближнюю (предельную, outermost) область из внешних областей действия проектирования, к которой ва- риант использования еще применим, и написать вариант использования обобщен Horo уровня для этой области действия. Вариант использования написан для области действия проектирования. Обычно можно найти более широкую область действия проектирования, которая еще имеет основное лицо, действующее вне нее. Если вы продолжите расширение этой области действия, то достиrнете точки, в которой дальнейшее расширение перенесет основное действующее лицо внутрь области действия. Это и есть предельная область дeйcт вия. Иноrда предельная область действия  это предприятие, отдел или просто компьютер. Часто компьютерный отдел является основным действующим лицом в Ba риантах использования, описывающих компьютерную безопасность, отдел сбыта  основным действующим лицом в вариантах использования, посвященных рекламе, а клиент  основным действуюLЦИМ лицом в вариантах использования для rлавнь функций системы. Обычно существуют только от двух ДО пяти предельнь вариантов использова- ния для системы в целом, так что не каждый вариант использования пишется дваж ды. Их так мало, потому что каждый объединяет основные действующие лица, имеющие сходные цели, в одной области действия проектирования и собирает все варианты использования более низкоrо уровня для этих действующих лиц. Я рекомендую писать предельные варианты использования, поскольку это зани- мает мало времени и обеспечивает отличный контекст для набора вариантов исполь зования. Такие варианты использования показывают преимущества, которые система предоставляет своим самым внешним пользователям. Они также обеспечи вают оrлавление для просмотра описания поведения системы. Рассмотрим предельные варианты использования, разработанные для компании MyTelCo и ее системы Асша. MyTelCo решила предоставить Интернет-клиентам непосредственный доступ к Асша, чтобы разrрузить своих служащих. Асша будет также форми- ровать отчеты об объеме продаж каждоrо служащеrо. Кому-то придется opra- низовать уровни безопасности доступа для клиентов и служащих. У нас есть четыре варианта использования: Добавить услуеу (с помощью клиента), Добавить услуеу (с помощью служащею), Сформировать отчет об объеме продаж и Ореанизовать управление безопасностью доступа. Придется написать все четыре варианта использования с системой Acura в каче- стве области действия SuD. Нужно определить предельную область действия для каждоrо из них. 
Область действия 51 Клиент находится вне MyTelCo, поэтому мы имеем один предельный вариант ис пользования с клиентом в качестве OCHoBHoro действующеrо лица и MyTelCo в каче стве области действия. Это будет вариант использования обобщенноrо уровня, трактующий MyTelCo как "черный ящик", отвечающий на запрос клиента, предо ставляющий услуry и Т.д. Практически этот вариант использования намечен в вари знте использования 6. Служащий находится внутри MyTelCo. Предельной областью действия д.пя Ba рианта использования Добавить услуry (с помощью персонала) являются все компь ютерные системы. Я предполаrаю, что все варианты использования д.пя служащих уровня цели пользователя находятся в этом предельном варианте использования, включая несколько вариантов использования д.пя подфункций, например Войти в си стему И Выйти из системы. В варианте использования Сформировать отчет об объеме продаж конечным основным действующим лицом является отдел маркетинrа. Предельный вариант ис пользования, областью действия KOToporo является отдел обслуживания, показывает взаимодействие отдела маркетинrа со всеми компьютерными системами и отделом обслуживания д.пя определения премий за продажи, д.пя формирования отчетов об объеме продаж и Т.д. Для варианта использования Орrанизовать управление безопасностью доступа конечным основным действующим лицом является отдел безопасности или отдел ин формационных технолоrий (П), а предельной областью действия проектирования  отдел П либо все компьютерные системы. Чтобы определить и отследить вопросы безопасности, этот вариант использования интенсивно обращается к отделу безопас ности и ко всем компьютерным системам. Эти четыре внешних варианта использования охватывают функции безопасно сти, маркетинrа, обслуживания и клиентов, используя систему Acura во всех аспек тах ее работы. Маловероятно, что д.пя системы Асша понадобится написать чтото сверх этих четырех вариантов использования, даже если появится сотня вариантов использования более низкоrо уровня. 3.4. Использование рабочих результатов опреАеления области Аействия Вы определяете функциональную область действия будущей системы, тратите силы и мечетесь между несколькими рабочими результатами, записанными на дo ске. На одной стороне доски у вас список Внутри/Вне д.пя отслеживания решений в функциональной области действия. У вас есть списокдействующихлиц с их целями. у вас есть схема области действия проектирования, показывающая людей, орrани зации и системы, которые будут взаимодействовать с разрабатываемой системой. Вы считаете, что выявляете всех их по мере Toro, как вырабатывая картину фун кционирования новой системы, анализируете ее взаимодействие с ними. Вы полаrае те, что представляете себе эту область действия проектирования, однако изменения в списке Внутри/Вне раздвиrают rраницы. Теперь вы имеете новое основное дейст вующее лицо и поправки к списку целей. 
52 rлава 3 Рано или поздно вы, вероятно, увидите, что вам необходим четвертый элемент  концепция новой системы. Концепция объединяет все аспекты обсуждения и помо raeT решить, что следует внести в область действия в первую очередь. Коrда вы это проделаете, у вас будет четыре рабочих результата, которые помо ryт сформировать область действия системы: . Концепция . Диаrрамма области действия проектирования . Список Внутри/Вне . Список Действующее лицо/Цель Эти результаты переплетены, и вы, скорее Bcero, будете изменять их по мере формирования области действия предстоящей разработки. 3.5. Упражнения Область действия nроектирования 3.1. Назовите по крайней мере пять областей действия проектирования системы, о которой, с точки зрения пользователя, можно было бы сказать: "... Дженни стоит перед банкоматом своеео банка. Темно. Она вводит свой личный номер и ищет кнопку Ввод..." . 3.2. Создайте диаrрамму нескольких областей действия для банкомата, включая оборудование и проrраммное обеспечение. 3.3. Для какой системы вы пишете требования? Что представляет собой ее пространство? Что внутри нее? С какими внешними объектами она должна взаимодействовать? В какую систему входит эта система и что находится снаружи этой внешней системы, с чем она должна поддерживать связь? Дайте название внешней системе. 3.4. Создайте диаrрамму нескольких областей действия для системы личноrо консультанта по финансам (PAF; см. упражнение 4.4). 3.5. Создайте диаrрамму нескольких областей действия для wеЬприложения, при выполнении KOToporo рабочая станция пользователя через Интернет подключается к webcepBepy вашей компании, соединенному с унаследованной системой на мэйнфрейме. 3.6. В чем разница между двумя вариантами использования для бизнеса, если область действия предприятия рассматривается как "черный ящик" и как "прозрачный ящик"? 
rлово 4 Участники и действующие ли1J,а Участник  это один из тех, кто заключает контракт. Действующее лицо  это некто (нечто), обладающий поведением, оно должно быть способно выполнить предложение с if. Действующим лицом может быть индивидуум, компания или opra низация, компьютерная проrрамма или компьютерная система  оборудование, проrраммное обеспечение либо то и друrое. Действующими лицами MOryT быть: . Участники системы . Основные действующие лица вариантов использования . Участники разрабатываемой системы (SuD) . Вспомоеательные действующие лица варианта использования . Внутренние действующие лица (в компонентах SuD) 4.1. Участники Участник  это KTOTO (чтото), имеющий законный интерес в поведении, реали зуемом в варианте использования. Каждое основное действующее лицо является участником, но некоторые участ ники никоrда не взаимодействуют с системой непосредственно, даже если имеют право проявлять интерес к поведению системы. Примером служат владельцы систе мы, правление компании и opraHbI rосударственноrо управления, например Налоrо вое управление и Министерство страхования. Студенты называют участников, которые никоrда напрямую не появляются в шаrах действий вариантов использования, закулисны.м.и, третьестепенными или бессловесны.м.и действующими лицами. Уделяя внимание последним, мы значительно улучшаем качество варианта испо льзования. Их интересы касаются проверок и подтверждений, которые производит 
54 rлава 4 система, журналов, которые она создает, и выполняемых ею действий. Правила биз неса документируются, так как система должна проводить их в жизнь от имени участ- ников. Необходимо, чтобы варианты использования показывали, как система защищает интересы участников. Далее следует история, иллюстрирующая, во что обходится забывчивость в данном вопросе. · Невымышnенная история в первый roA работы после продажи нескольких копий своей новой систе- мы компания получила запросы на изменение системы. Это казалось eCTe ственным, пока дело не дошло до вариантов использования и не понадобилось предпринять "мозrовой штурм" по поводу участников и ИН тересов в недавно поставленной системе. Обнаружилось, что во время TaKoro штурма сотрудники компании сами выявили элементы последнеrо запроса на изменение. Очевидно, во время разработки системы они совершенно упустили из вида некоторые интере- сы нескольких участников. Эти участники довольно скоро заметили, что система не обслуживала их надлежащим образом, и, естественно, посла ли запрос на изменение. С тех пор в компании стали стал неукоснительно именовать участников и интересы на ранней стадии во избежание повторения этой дороrостоящен ошибки. Мои коллеrи и я считаем, что, выявляя участников и их интересы, мы определя- ем важные требования на ранней стадии. Эти требования друrим способом выяснить невозможно. Это не занимает MHoro времени и сбереrает MHoro сил в будущем. 4.2. Основное Аействующее лицо Основное действующее лицо варианта использования  это участник, KOTO рый обращается к системе за одной из ее услуr. По отношению к системе он имеет цель, которая может бытьдостиrнута в результате работы этой системы. Основное действующее лицо часто (но не всеrда) является тем, кто запускает вариант испо льзования. Обычно вариант использования стартует вследствие Toro, что основное действу- ющее лицо посылает сообщение, нажимает на кнопку, на клавишу или инициирует работу варианта использования какимлибо дрyrим способом. Однако существуют две распространенные ситуации, коrда инициатором варианта использования явля ется не основное действующее лицо. В первом случае служащий компании или опе ратор на телефоне инициирует вариант использования от имени KoroTo еще, во втором  вариант использования запускается по таймеру. Наличие служащеrо компании или телефонноrо оператора часто удобно с TeXHO лоrической точки зрения для конечноrо OCHoBHoro действующеrо лица, которое дей ствительно имеет свой интерес. По мере развития технолоrии становится более вероятным, что конечное основное действующее лицо будет инициировать или запус- 
Участники и действующие лица 55 кать вариант использования непосредственно с помощью Интернета или автомати ческой телефонной системы. Примером служит клиент, который прямо сейчас звонит и выдает запрос. С системой, переделанной д.пя работы в Интернете, клиент сможет вводить свой запрос напрямую (как в Amazoп.com). Подобным же образом подразделение маркетинrа или аудита может настаивать на вариантах использования, с которыми работал бы служащий. Вариант использо вания как таковой служащему не нужен, просто он технолоrически удобен д.пя MeHeд жеров по продажам. При несколько иных условиях менеджеры сами работали бы с вариантами использования. Сеrодня я пишу "торrовый представитель д.пя клиента" или "служащий д.пя OTдe ла маркетинrа", чтобы зафиксировать, чТО пользователь системы действует в инте ресах KoroTo еще. Разработать интерфейс пользователя и определить уровень защиты необходимо д.пя служащеrо, а в результатах заинтересованы клиент или OT дел продаж. Таймер  друrой пример запуска без оператора. Вариант использования запус кается каждую полночь или в конце месяца. В этом случае основное действующее лицо  это какойлибо участник, заинтересованный в том, чтобы вариант использо вания работал в это самое время. Можно вступить в продолжительную дискуссию и сравнивать пользователей с конечными основными действующими лицами. Пред.паrаю вам не тратить слишком MHoro времени на это. Если rруппа начинает исследовать вопросы проектирования интерфейса пользователя, она затрачивает MHoro усилий на изучение реальных xa рактеристик пользователя (или ей следует это делать). Коrда разработчики paCCMOT рят требования, они поймут, что д.пя каждоrо варианта использования полезно знать конечное основное действующее лицо, Т.е. Toro, кто действительно заинтересован в результате. Один сообразительный студент спросил: "Насколько велик будет ущерб, если мы на этом этапе неправильно определим конечное основное действующее лицо?" Ущерб будет не слишком большим, как показано в следующем разделе. Почему основные Аействующие лица бывают несущественны (и существенны) Основные действующие лица важны в начале сбора требований и непосредственно перед сдачей системы. Между этими двумя этапами они не важны. в начапе соэдання варнантов нспопьэовання Перечисление основных действующих лиц помоrает нам составить мнение о систе ме в целом за короткий промежуток времени (это довольно скоро выскочит у нас из rоловы). Мы устраиваем" мозrовые штурмы", выявляя сначала всех действующих лиц, а затем  их цели. Это цели, которые нас действительно интересуют, но если мы будем выявлять их напрямую, то слишком MHoroe упустим. Выявление основных действующих лиц определяет рабочую основу. Затем ее можно досконально обсу дить, чтобы получить более качественный список целей. 
56 rлава 4 Построение чуть более длинноrо списка основных действующих лиц делу не Me шает, поскольку в худшем случае одна и та же цель будет сформулирована дважды. Коrда будем просматривать набор действующих лиц и целей, чтобы назначить прио ритеты разработки, обнаружим и удалим дубликаты. Однако даже при двойном "мозrовом штурме" маловероятно, что мы перечис лим все цели, достижение которых должна обеспечивать система. Новые цели имеют обыкновение появляться, коrда мы пишем шаrи обработки ошибок варианта исполь- зования, но это невозможно учесть на столь ранней стадии. Лучшее, что мы можем сделать,  это зафиксировать все цели, перечислив сначала всех основных действу ющих лиц. Полный список основных действующих лиц дает еще три преимущества: . Он фокусирует наши мысли на людях, которые буд:ут использовать систему. В документе, содержащем требования, мы фиксируем, Koro предполаrаем в каче- стве основных действующих лиц, описание их работы, их типичную подrотовку И навыки. Мы делаем это, чтобы разработчики системы и интерфейса пользо вателя моrли обеспечить соответствие системы этим характеристикам. . Он определяет структуру списка Действующее лицо/Цель, которая будет испо льзована для расстановки приоритетов и распределения работы. . Он нужен для разбиения orpoMHoro множества вариантов использования на па кеты, которые можно распределить между различными rруппами разработчиков. Во время создания вариантов испопьзования и во время проектирования Коrда мы начинаем разрабатывать варианты использования в деталях, основные действующие лица практически теряют важность, что удивительно. Дело в том, что со временем создатели вариантов использования обнаруживают, что в них MOryT быть разные типы действующих лиц. Например, KTOTO (не простой служащий) MO жет ответить на звонок и поrоворить с клиентом. Поэтому писатели называют основное действующее лицо общим именем, используя такие ролевые имена, как "прие.м.щик утерянноео", "прuе.м.щик заказов" или "производитель счетов". Как следствие варианты использования сообщают, что производитель счетов произ- водит счет, а приемщик заказов принимает заказ (что не слишком информативно). Дроблением ролей можно управлять разными способами, каждый из них имеет преимущества и недостатки. Ни одна стратеrия не является идеальной, поэтому вам просто придется выбрать одну из них. АЛЬТЕРНАТИВА 1. Разбейте множество основных действующих лиц в COOTBeTCT вии с их ролями. Постройте таблицу Действующее лицо/Роль, в которой перечис лены все люди и системы, являющиеся основными действующими лицами в каких-либо вариантах использования, и все их роли. Используйте названия роли в поле Основное действующее лицо. С помощью таблицы Действующее лицо/Роль перейдите от вариантов использования к людям и системам в реальной жизни. 
Участники и действующие лица 57 Эта стратеrия позволяет авторам иrнорировать сложные названия работ и про должать писать. Разработчик интерфейса пользователя или компоновщик пакета проrраммноrо обеспечения применит таблицу Действующее лицо/Роль, чтобы обес печить соответствие вариантов использования их конечным пользователям. Heдo статок альтернативы 1 в том, что приходится по)Щерживать и читать отдельный список. АЛЬТЕРНАТИВА 2. В начальном разделе вариантов использования пишем: "Адми ннстратор может выполнять все те варианты использования, которые может выполнять служащий, и сверх Toro. Реrиональный управляющий может выпол нять все те варианты использования, которые может выполнять администратор, н сверх Toro. Поэтому, если написано, что основное действующее лицо  это, к прнмеру, служащий, значит подразумевается, что любой индивидуум должно стью выше, администратор и реrиональныи управляющии в данном случае, спо собен выполнять этот вариант использования". Такую форму леrче по)Щерживать, чем таблицу Действующее лицо/Роль, по скольку маловероятно, что она изменится. Ее недостаток в том, что люди будут за трачивать некоторое время, напоминая друr друry об этом примечании. Обе альтернативы обеспечивают адекватные результаты. Я использую вторую, так как меня устраивает, что надо писать, анализировать и по)Щерживать на один продукт меньше. Дело в том, что поле OCHoBHoro действующеrо лица шаблона варианта использо вания со временем обесценивается. Это нормально, и не стоит об этом беспокоиться. Завершение проекта, noAroToBKa к внедрению системы Непосредственно перед сдачей системы основные действующие лица опять CTaHO вятся важными. Нам необходим список всех людей и вариантов использования, KO торые они будут выполнять. Нам нужно: . Разделить систему на модули, которые будут заrружаться на различных пользо вательских компьютерах. . Определить уровни безопасности дпя каждоrо варианта использования (дпя Интернет пользователей, внутренних пользователей, администратора и т.д.). . Орrанизовать обучение дпя различных rрупп пользователей. Действующие лица в сравнении с ролями Термин действующее лицо подразумевает индивидуума в действии. Иноrда в ва  рианте использования он означает индивидуум. Однако в друrих случаях он указы вает на общую катеrорию индивидуумов, которые MOryT исполнять заданную роль. Предположим, что Ким  клиент МуТеlСо, Крис  служащий, а Пэт MeHek жер по продажам. Каждый из них способен разместить заказ. На языке действующих лиц мы скажем, что Ким, Крис и Пат MOryт быть основными действующими лицами дпя варианта испОЛьзования Разместить заказ. Мы также скажем, что клиент, слу 
58 rлава 4 жащий и менеджер по продажам  допустимые основные действующие лица для ва- рианта использования Разместить заказ. Можно отметить, что менеджер по продажам может выполнять любой вариант использования, который может выпол- нять служащий. Все это правильно. Используя язык ролей, мы скажем, что Ким, Крис и Пэт  это действующие лицаиндивидуумы. Каждый из них может иrрать роль клиента, но только Крис и Пэт способны иrрать роль служащеrо, и одна только Пэт способна иrрать роль Me неджера по продажам. Управляет вариантом использования Разместить заказ роль приемщика заказов. Этот способ описания более точен, чем предыдуЧJ.ИЙ, и некото- рые предпочитают ero. Однако в мире вариантов использования он является не- стандартным. Вам следует употреблять такие термины, какие предпочитают разработчики ва- шей rруппы. Между тем, действующее лицо  термин, принятый в проrраммной инженерии. Он вполне адекватен, поэтому я использую ero в этой книrе. Днаrраммы UML н спецнапнэацня Денствующее пнцо /Ропь В UML используется незакрашенная стрелка, обозначающая, что одно действую щее лицо является специализацией друrоrо (см. рис. А.6). Такая стрелка позволяет кратко выразить, что менеджер может делать все то, что может делать служащий. Достаточно нарисовать стрелку, направленную от Me неджера к служащему. Недостатком является то, что мноrим такая диаrрамма кажется перевернутой. Они не считают менеджера особы-м. видом служащеrо или служащеrо особым видом клиента, что, повидимому, показывает диаrрамма (в действительности она показы вает, что один может делать то, что может делать и друеой). Мноrие полаrа ют, что менеджер  это больше, чем служащий. Это мнение не столь существенно, но вам придется иметь ero в виду. Стрелка специализации вовсе не помоrает решить rлавную часть проблемы Действующее лицо/Роль. Для служащеrо отдела продаж и служащеrо отдела аудита наборы вариантов использования перекрываются, но между ними нельзя поставить стрелку специализации, так как никто из них не может делать все, что может друrой. Таким образом, вы возвращаетесь к середнне дискуссии о действующем лице и роли. Характеристики основных Аействующих лиц Имея только список действующих лиц, нельзя существенно помочь разработчикам, которым надо знать, какими навыками должны обладать пользователи, чтобы по- строить соответствующие поведение системы и интерфейс пользователя. rруппы, создающие таблицу профиля действующих лиц, считают, что они лучше пред ставляют себе, насколько их проrраммное обеспечение удовлетворит потребности конечных пользователей, поскольку во время разработки у них перед rлазами есть данные о навыках конечных пользователей. Самая простая таблица профиля действующих имеет две колонки (см. таблиuy 4.1). Иноrда приводят и вторые имена, или псевдонимы, под которыми известны эти 
Участники и действующие лица 59 действующие лица. Изменения в таблице профиля действующих лиц обсуждаются в книrе Software for Use (Сопstапtiпе and Lockwood, 1999). Таблица 4.1. При мер таблицы пр о филя действующих лиц Н_эввиие Профит.: nOArOTOBKB и И_ВIoIКИ Клиент Человек с улицы, умеющий пользоваться сенсорным дисплеем, но вряд ли имеющий опыт работы с rpa фичеСКI1М интерфейсом пользователя (GUI). MorYT возникнуть трудности с чтением, возможны близо рукость, дальтонизм и т .д. Лицо, постоянно работающее с зтим nporpaMMHbIM обеспечением. Умеет работать с сенсорным дисп леем, опытнын пользователь. Может захотеть моди фицировать интерфейс пользователя. Нереrулярный пользователь, работал с GUI, но не знаком с какойлибо определенной функцией про rpaMMHoro обеспечения. Нетерпелив. Служащий, оформляющий возврат товаров Менеджер 4.3. вспомоrательныe Аействующие лица Вспом.оеательное действующее лицо в варианте использования  это внешнее действующее лицо, предоставляющее некоторую услуry для разрабатываемой сис- темы. Это может быть высокоскоростной принтер, служба Интернета или люди, которые должны провести для нас некоторое исследование (например, следователь по делам о насильственной или скоропостижной смерти дает страховой компании заключение о смерти клиента). Обычно мы называем их второстепенными действу- ющими лицами, но некоторым этот термин кажется дезориентирующим. Теперь чаще используется термин вспом.оеательное действующее лицо. Мы определяем вспомоrательное действующее лицо, чтобы указать на внешние интерфейсы, которые будет применять система, и протоколы, лежащие в основе этих интерфейсов. Отсюда дополнительные требования: форматы данных и внешние ин- терфейсы (см. рис. 1.1). Действующее лицо может быть основным в одном варианте использования и вспомоrательным в друrом. 4.4. Разрабатываемая система Разрабатываемая система сама по себе является действующим лицом oco- бым. Обычно мы называем ее по имени, например Acura, или просто разрабатывае- мой системой, SuD. Она именуется или описывается в поле Область действия проектирования варианта использования. SuD не является основным либо вспомоrательным действующее лицом ни для KaKoro варианта использования, несмотря на то, что она  действующее лицо (см. подраздел Область действня проектирования). 
60 rлава 4 4.5. Внутренние Аействующие лица и варианты использования типа "прозрачный ящик" Большую часть времени мы рассматриваем разрабатываемую систему как "черный ящик", содержимое KOToporo мы не можем видеть. Внутренние действующие лица намеренно не упоминаются, что вполне оправдано, коrда мы применяем варнанты ис- пользования, чтобы сформулировать требования к еще не разработанной системе. Иноrда нам требуется применить форму варианта использования Д,I1Я документи рования взаимодействия частей системы (см. варианты использования 5 и 19). Мы моrли бы проделать это, показывая более масштабное проектирование Д,I1Я мульти компьютерной системы (см. вариант использования 8). При таких условиях компо ненты системы проявляются как действующие лица. Заrлядывая внутрь системы и именуя компоненты и их поведение, мы трактуем систему как "прозрачный ящик". Все относительно написания вариантов использо- вания пока работает, только теперь мы обсуждаем поведение как внутренних, так и внешних действующих лиц. В варианте использования "прозрачный ящик" сущест вует более двух действующих лиц, поскольку наряду с внешними действующими ли цами раскрыты и компоненты системы. Исключительно редко и, как правило, по ошибке варианты использования типа "прозрачный ящик" пишут как требования к поведению КОМfIьютерной системы, KO торую 'предстоит разработать. 4.6. Упражнения Действующие лица и участники 4.1. Определите вариант использования Д,I1Я ToproBoro автомата, если ero владелец является основным действующим лицом. 4.2. Вас наняли, чтобы документнровать требования для HOBoro банкомата. Определите, является ли каждый элемент следующеrо списка участником, основным действующим лицом, вспомоrательным действующим лицом, разрабатываемой снстемой или вовсе не относится к действующим лицам (либо к перечисленному множеству). Банкомат Клиент Карточка Д,I1Я банкомата Банк Передняя панель банкомата Владелец банка Специалист по техническому обслуживанию Принтер rлавная банковская компьютерная система Банковский кассир rрабитель банков 
Участники и действующие лица 61 4.3. Банкомат  компонент более сложной системы. Практически, это часть множества более сложных систем. Повторите предыдущее упражнение для одной такой охватывающей системы. 4.4. Воображаемая компания "Персональные консультанты" выпускает новый продукт, который позволит людям анализировать инвестиционные стратеrии, например вложения в пенсионные, образовательные фонды, землю и акции. Продукт, персональный консультант по финансам (PAF), поставляется на СО. Пользователь устанавливает ero, а затем проиrрывает различные финансовые сценарии, чтобы научиться оптимизировать свое финансовое будущее. PAF может также получать информацию о налоrовых законах от различных налоrовых пакетов, таких как Кiplinger Тах Cut. Компания заключает соrлашение о прямом обмене информацией с компанией Кiplinger, а также соrлашения с различными компаниями, оказывающими услуrи в Интернете, например Vanguard или E*Trade, чтобы напрямую покупать и продавать ценные бумаrи и акции через Интернет. В компании также считают, что необходима действующая в Сети версия PAF, за ее использование следует взимать плату. Назовите и определите дЛЯ PAF действующих лиц, основных действую щих лиц, разрабатываемую систему и охватывающую систему (в которую PAF входит как компонент). 
fлава 5 Три поименованных УРОВ'НЯ 1J ели Цели и взаимодействия в сценариИ можно развернуть в более детализированные и более разветвленные цели и взаимодействия. Это нормальное состояние, и мы хо- рошо с этим справляемся в повседневной жизни. Далее иллюстрируется тот факт, что наши цели содержат под- и подподцели. Мне нужен определенный доrовор о продаже. Чтобы ero добиться, я должен приrласитьуправляющеrо компании на обед. Ад,тrя этоrо мне нужна HeKOTO рая сумма наличными. Чтобы ее получить, мне придется извлечь деньrи из данноrо банкомата. Для этоrо мне нужно, чтобы он признал мою идентич- ность. Ад,тrя этоrо необходимо, чтобы он прочитал мою банковскую карточ ку. Чтобы сделать это, я должен найти щель д,тrя карточки. Я хочу найти клавишу табуляции, чтобы перевести курсор в поле адреса, чтобы записать мой адрес, чтобы я Mor занести мои личные данные в эту проrрамму расценок, чтобы я смоrузнать цену, чтобы я cMor купить aBTOMO бильный страховой полис, чтобы получить водительские права, чтобы BO дить автомобиль. Хотя д,тrя повседневной жизни здесь нет ничеrо необычноrо, в качестве варианта использования это выrлядит странно. Создавая варианты использования, мы в каж дом лред,тrожении сталкиваемся с вопросом, KaKorO уровня цели вариант использова- ния следует описывать. Помоrает именование уровней целей. Далее приведены названия уровней цели и пиктоrраммы, которые я считаю полезными, а также описано, как определить уро- вень цели, необходимый в данный момент. На рис. 5.1 даны названия и зрительные образы, которыми я пользуюсь. 
Три поименованных уровня цели 63 Рис. 5.1. УРОВНI1 Bapl1aHTOB I1спользоваНI1Я. Набор варl1антов I1спользоваНI1Я обнаРУЖl1вает l1ерарХI1Ю целей  непрерывно развораЧl1вающуюся I1СТОрl1Ю 5.1. Цели пользователя (rолубые, уровня моря ) Наибольший интерес представляет цель пользователя. Это та цель, которую пре следует основное действующее лицо, пытаясь добиться от системы выполнения определенной работы, либо пользователь, работающий с системой. Она COOTBeTCT вует "элементарному бизнеспроцессу" в технолоrии бизнесспроцессов. Цель пользователя характеризуется вопросом: "Уйдет ли основное действующее лицо удовлетворенным, выполнив это?" Для служащеrо этот вопрос звучит так: "За висит ли ваша производительность труда от Toro, сколько вы сеrодня сделаете?" Цель можно также пропустить через тест "перерыва на кофе": "Коrда это закончу, сделаю перерыв на кофе". В большинстве случаев цель пользователя проходит тест для одноrо клиента за один сеанс (2  20 мин). Вообще цели "Совершить покупку на онлайновом аукционе" и "Войти в систе му" не считаются целями пользователя. Онлайновые аукционы требуют несколько дней и поэтому не проходят односеансовый тест. Вход в систему 42 раза подряд не OT вечает (как правило) должностным обязанностям индивидуума или цели использова ния системы. "Зареrистрировать HOBoro клиента" и "Купить книry" вполне MOryт быть целями пользователей. Задача реrистрации 42 новых клиентов не лишена смысла Д,I1я areHTa по продажам. Покупку книrи можно совершить за один сеанс. Пока все как будто выrлядит просто. Одиако, столкнувшись со множеством фраз, написанных на доске, или вариантом использования, который по какойто при чине выrлядит неправильно, леrко впасть в сомнения. Я считаю, что большинство 
64 r лава 5 людей будут чувствовать себя уверенно, изображая уровни целей в цвете либо при меняя обозначения высоты над уровнем моря. Цветовая raMMa охватывает белый, rолубой, индиrо, черный цвета (в книrе как оттенки ceporo). Цель пользователя rолубая. Долrосрочные цели, имеющие бо лее высокий уровень, например "Завершить онлайновый аукцион" и "Получить страховое возмещение за автомобильную аварию"  белые. Краткосрочные цели, имеющие более низкий уровень,  цвета индиrо. Черный указывает, что эта цель TaKoro низкоrо уровня, что было бы ошибкой писать для нее вариант использования, например: "Нажать на клавишу ТаЬ". Идея метафоры уровня моря состоит в следующем. Небо находится очень высоко над уровнем моря, а вода опускается ниже уровня моря на большую rлубину, но существует только один уровень, rде встречаются небо и море,  уровень моря. То же самое справедливо и для целей. MHoro уровней цели находится над целью по- льзователя и MHoro под ней, но цели пользователя достаточно важны, чтобы их запи- сать. Поэтому им соответствует уровень моря (знак волн). Облако или воздушный змей обозначают более высокий уровень, чем уровень моря, рыбка или моллюск  это значок уровня цели ниже уровня моря. Система характеризуется подn.ержкой целей уровня моря. Вот одиа из таких целей: Вы служащий, сидящий на рабочем месте. Звонит телефон, вы берете труб ку. Некто надруrом конце rоворит: "...". Вы поворачиваетесь к компьютеру. В этот момент вы думаете о том, что необходимо выполнить работу G. Вы He которое время работаете с компьютером и клиентом и, наконец, завершаете работу G. Отворачиваетесь от компьютера, прощаетесь и вешаете трубку. G  rолубая (уровня моря) цель пользователя. Выполняя G, вы выполняете ряд целей более низкоrо уровня (индиrо). Персона, позвонившая по телефону, Bepo ятно, имеет в виду более высокий уровень цели, и выполнение G только один шаr к ней. Цели этой персоны, имеющие более высокий уровень, белые. Цели пользователя уровня моря (rолубые) чрезвычайно важны, поэтому стоит се- рьезно потрудиться, чтобы их понять и усвоить. Кратчайшее изложение функций сис- темы  это список целей пользователя, которые она подn.ерживает. Это основа для расстановки приоритетов, сдачи системы, разделения работ, оценки и разработки. Варианты использования будут создаваться на уровнях выше и ниже уровня моря. Можно представить себе orpOMHoe число целей более низкоrо уровня и вари- анты использования как "подводные", поскольку это подразумевает, что мы на самом деле не хотим описывать их или читать о них. · Невымышленная история Однажды мне пере слали сотни страниц вариантов использования, все цвета индиrо, или подводные. Этот документ, описывающий требования, был Ta кой Д/lинный и скучный, что не Mor быть полезен ни ero авторам, ни ero чи тателям. Позднее отправитель выслал мне шесть вариантов использования уровня моря, которые заменили предыдущий документ, и сообщил, что все нашли новый документ более леrким Д/lЯ понимания и работы с ним. 
Три поименованных уровня цели 65 Два уровня rолубоrо Обычно rолубой вариант использования имеет один белый вариант использования выше и несколько вариантов использования цвета индиrо ниже. Однако иноrда он обращается кдруrому rолубому варианту использования. Я видел это только в oд ной ситуации, но эта ситуация возникает MHoroKpaTHo. Предположим, выполняя коекакие поручения, я иду мимо маrазина видеопро ката. Размышляю: "Раз уж я здесь, зареrистрируюсь". Захожу и прошу оформить мне реrистрацию. Такова моя цель пользователя, rолубой вариант использования. На следующей неделе прихожу со своим членским билетом, чтобы взять напрокат видео. Я осуществил эти две цели пользователя в разные дни. Однако вы пользуетесь видеопрокатом подруrому. Заходнте в видеомаrазин взять напрокат видео. Служащий спрашивает, зареrистрированы ли вы. Вы rовори те, что нет, поэтому служащему приходится зареrистрировать вас в процессе выдачи напрокат первоrо видеофильма. Реrистрация представляет собой шаr в рамках Bыдa чи напрокат видео, хотя обе цели rолубые. Ситуация "Попутно зареrистрировать клиента"  едннственная ситуация, в KO торой Я видел один rолубой вариант использования внутри друrоrо rолубоrо варианта использования. Коrда меня об этом спрашивают, я иронически отвечаю, что оба Ba рианта использования имеют уровень моря, но "Взять напрокат видео" сидит на rребне волны (см. рис. 5.1), а "Зареrистрировать клиента"  в ее подошве. 5.2. Обобщенный уровень (белый, облако О или ВОЗАУШНЫЙ змей Р) Цели обобщенноео уровня' включают несколько целей пользователя. При описа нии системы они выполняют три назначения: . Показывают контекст, в котором выполняются цели пользователя. . Показывают жизненный цикл последовательности связанных целей. . Формируют перечень вариантов использования более низкоrо уровня, как бе лых, так и rолубых. Обобщенные варианты использования по шкале цветов белые. Белые варианты использования имеют шаrи белоrо, rолубоrо, а порой и цвета индиrо ("Войти в сис тему"  это цель цвета индиrо, которая, вероятно, будет обнаружена в белом вари знте использования). Я не считаю полезным проводить различия между разнообразными уровнями белоrо, но иноrда MOryт сказать чтонибудь вроде: "Этот вариант использования по настоящему белый, белый до Toro, что поднялся в облака". *. Ранее я использовал два термина: "стратееический" и "обобщенный". He давно я пришел к выводу, что "обобщенный" вызывает меньше путаницы, и выбрал ero для этой книrи. 
66 rлава 5 В терминах уровня моря мы скажем, что большинство обобщенных вариантов испо- льзования похожи на воздушноrо змея как раз над уровнем моря, а друrие поднялись до облаков. Обобщенные варианты использования обычно выполняются в течение часов, дней, недель, месяцев или лет. Здесь представлен основной сценарий "долrоиrраю- щеrо" варианта использования, задача KOToporo  связать rолубые варианты испо- льзования, разбросанные по rодам. Обратите внимание, что rрафика помоrает указать, что вариант использования касается компании, рассматриваемой как "чер ный ящик", и что уровень цели очень белый (высоко в облаках). Подчеркнутые фра- зы представляют собой варианты использования более низкоrо уровня. Знак "+" в конце имени  это альтернативный способ обозначения вариантов использования обобщенноrо уровня (подробнее см. в разделе 5.4). Вариант ИСПОПЬЗ0вания 18 .. Выпопнить операции со страховым пописом + О... Основное действующее лицо: клиент Область действия: страховая компания (MylnsCo) Уровень: обобщенный (белый) Шаrи: 1. Клиенту назначают цену полиса. 2. Клиент покупает полис. з. Клиент делает заявление об аннулировании полиса. 4. Клиент закрывает полис. В этой rлаве приведены и друrие варианты использования: . Вариант использования 19, Обработать заявление (бизнес) . Вариант использованшr 20, Оценить указанную в заявлении сумму . Вариант использования 21, Обработать заявление ( система) Возвращаемся к предельным вариантам использования Ранее я рекомендовал вам написать несколько предельных вариантов использо- вания для разрабатываемой вами системы. Ниже представлен более точный процесс обнаружения этих предельных вариантов использования: 1. Начните с цели пользователя. 2. Спросите, какому (предпочтительно вне орrанизации) основному действующему лицу, АА, служит эта цель. Действующее лицо АА  конечное действующее лицо вариантов использования, которые мы хотим собрать. 3. Найдите предельную область действия проектирования $, такую, чтобы АА еще находился вне S. Придумайте название для области действия S. у меня обычно три такие предельные области действия: 
Три поименованных уровня цели 67 · Компания · Объединяемые проrраммные системы · Конкретная разрабатываемая проrраммная система 4. Определите все цели пользователей, для которых конечное основное действующее лицо  это АА, а область действия проектирования  S. 5. Выработайте обобщенную цель, GG, которую действующее лицо АА имеет в отношении системы S. 6. Напишите обобщенный вариант использования для цели GG действующеrо лица АА в отношении системы S. Этот вариант использования связывает ряд вариантов использования уровня моря. Обычно таких вариантов использования наивысшеrо уровня (GG) набирается Bcero четырепять даже для самых больших систем. Они обобщают интересы трехчетырех конечных основных действующих лиц (АА): . Клиента к компании . Отдела маркетинrа к комплексу проrраммных систем . Отдела безопасности к самой проrраммной системе Эти предельные варианты использования помоrают определить rраницы рабо ты, и я настоятельно рекомендую писать их по указанным выше причинам. Однако они не обеспечат вашу rруппу функциональными требованиями к системе, которую она будет разрабатывать,  эти требования заключены в вариантах использования для целей пользователя (rолубых). 5.3. пОАФУНКЦИИ (ИНАиrо ИЛИ черны,' пОАВОАНЫЙ IO!> ИЛИ МОЛЛЮСК) g Цели уровня подфункции  это цели, достижение которых требуется для реали зации целей пользователей. Включайте их только по мере необходимости. Они ино rда нужны для леrкоrо прочтения или потому, что их применяют мноrие друrие варианты использования. При меры вариантов использования уровня подфункции: Найти изделие, Найти заказчика и Сохранить в файле (см., в частности, Heo бычный вариант использования 23 цвета индиrо). Варианты использования уровня подфункции являются подводными, цвета ин диrо. Некоторые даже лежат на дне. Они окрашены в черный цвет, что означает, что это слишком низкий уровень. Не вздумайте возводить ero в степень варианта испо льзования (он даже не плавает... настоящий моллюск). Удобно иметь специальное название для подобных вариантов использования ультранизкоrо уровня. Если ктонибудь таковой напишет, вы укажете, что ero содержимое должно в свернутом виде войти в друrой вариант использования. 
68 r лава 5 rолубые варианты использования имеют шаrи цвета индиrо, а в вариантах испо- льзования индиrо встречаются более rлубинные шаrи индиrо, как показано ниже на рис. 5.2. Здесь д.ля обнаружения более BblcoKoro уровня цели д.ля вашей целевой фразы следует ответить на вопрос, почему действующее лицо это делает. Метод "как/почему" более подробно обсуждается в разделе 5.5. Обратите внимание, что даже в самых rлубинных подводных вариантах исполь- зования д.ля подфункций caMoro низкоrо уровня основное действующее лицо нахо- дится вне системы. Я бы не стал об этом упоминать, если бы люди иноrда не rоворили о подфункциях так, будто их проектирование каким-то образом под.лежит обсуждению, и если бы не отсутствовало основное действующее лицо. В случае под- функции действуют все правила д.ля вариантов использования. Основным действую- щим лицом д.ля подфункции может быть то же лицо, что и в варианте использования более BblcoKoro уровня, который обращается к данной подфункции. Обобщение уровней целей К настоящему моменту важны три пункта относительно уровней целей: . Серьезно отнеситесь к выявлению вариантов использования уровня моря. Они действительно важны. . Напишите несколько предельных вариантов использования, чтобы обеспечить контекст д.ля друrих. . Не слишком беспокойтесь по поводу Toro, представлена ли ваша любимая фра- за среди описаний требований к системе как название варианта использования. Быть названием варианта использования  не означает быть самым важным требованием, равно как и не быть названием  не значит быть не важным. Я пони- маю, что люди оrорчаются, если требование, которое они считают самым важным, стало только шаrом в варианте использования и не было развернуто в вариант испо- льзования, который прослеживается сам собой. Не волнуйтесь об этом. Одно из достоинств целевой модели состоит в том, что относительно небольшое изменение превращает сложный фраrмент текста в вариант использования или задвиrает тривиальный вариант использования обратно в вариант использования более BblcoKoro уровня. Каждое пред.ложение пишется как цель, и каждая цель может быть развернута в собственный вариант использования. rлядя на написанное, мы не можем сказать, какие пред.ложения развернуты, а какие нет (если не следовать связям), и это хорошо, поскольку обереrает целостность написанноrо от несущественных изменений. Цели, которым rарантируются собственные вариан- ты использования,  это цели только rолубоrо цвета. 5.4. Использование пиктоrрамм АЛЯ выеленияя уровней целей Выше я продемонстрировал несколько пиктоrрамм, которые полезно помещать слева от названия варианта использования. Поскольку уровни цели не более одно- 
Три поименованных уровня цели 69 значны, чем названия, я располаrаю ПИКТО1'рамму уровня цели справа вверху от на  звания. Это в дополнение к заполнению полей шаблона. Читатели (и писатели) используют любые подсказки, чтобы распознать уровень цели. Придерживаясь высотной терминоло1'ИИ, я вьщеляю пять высот над уровнем моря. В большинстве случаев вам хватит трех средних. . Варианты использования очень BblcoKo1'o обобщения (очень белые) обознача ются облаком, О. Используйте этот знак в тех редчайших ситуациях, Korдa вы видите, что ша1'И варианта использования сами являются белыми целями. Если нельзя добавить пиктоrрамму, добавьте знак плюса ( + ) в конце названия вари  анта использования (см. вариант использования 18). . Обобщенные (белые) варианты использования обозначаются знаком воздуш Ho1'o змея, Р. Это имеет место для большинства обобщенных вариантов испо льзования, шаrи которых представляют собой 1'олубые цели. Добавьте + к названию варианта использования, если не можете применить ПИКТО1'рамму. . Варианты ИСпользования для цели пользователя (1'олубые, уровня моря) обозначаются знаком волн, . Не добавляйте никако1'О суффикса или дo бавьте восклицательный знак (!) к названию, если нельзя использовать пик To1'paMMY. . Варианты использования для подфункций (индиrо) обозначаются знаком рыбы,  . Используйте e1'o для большинства вариантов использования и иди  1'0. Вместо пиктоrраммы можно поставить знак минуса (  ). . Некоторые подфункции (черные) НИКО1'да не следует описывать в виде вариан тов использования. Используйте знак моллюска, g , чтобы пометить вариант использования, который нужно слить с вариантом использования, вызываю щим e1'o. С помощью этих ПИКТО1'рамм можно пометить область действия проектирования и уровень цели даже в UМLдиаrраммах вариантов использования, как только по ставщики инструментов начнут их поддерживать. А суффиксы можно применять сра  зу же. Если ваши шаблоны уже содержат поля Область действия использования и Уровень цели, можете использовать их в качестве резервных меток. Если ваши шаб лоны не содержат этих полей, добавьте их. 5.5. Выявление правильной цели пользователя Выявление правильной цели пользователя  труднейшая вещь в вариантах испо льзования. Сосредоточьтесь на следующих правилах: . Выявите цель пользователя. . Используйте от трех до 1 О ша1'ОВ на вариант использования. 
70 rлава 5 Выявление цели пользователя На всех уровнях цели только одна выделяется из ДРУ1'их: Вы описываете систему (на уровне бизнеспроцессов или компьютерную). Вы думаете о том, кто будет систему использовать. Это лицо хочет чтото получить от вашей системы сейчас. Получив это, лицо может продолжить и сделать чтото еще. Что же теперь оно хочет от вашей системы? Этот уровень имеет MHo1'o названий. При моделировании бизнеспроцессов он называется элементарным бизн.еспроцессом. Пофранцузски это rаisоп d'etre (основание быть) системы. В вариантах использования это цель пользователя. Спросите себя, является ли это тем, че1'О действительно сейчас Хочет от системы основное действующее лицо? Для большей части первых наметок вариантов исполь зования ответ будет отрицательным. Очень часто начинающие набрасывают подвод ные варианты использования, думая, что те находятся на уровне моря. Чтобы обнаружить цель более BblcoKo1'o уровня, задайте себе любой из этих вопросов: . Чеro на самом деле хочет действующее лицо? . Почему действующее лицо это делает? Ответ может быть настоящей целью действующе1'О лица, но задавайте вопрос снова, пока не будете уверены в этом. Интересно, что даже если тесты для цели по- льзователя субъективны, люди вскоре приходят к СО1'ласию по этому вопросу. Спе- циалисты дают удивительно похожие ответы на вопросы о целях пользователей. Кажется, это устойчивое понятие. Повышение и понижение уровней целей Ша1'И варианта использования описывают, как осуществляется процесс. Название варианта использования указывает, почему этот процесс представляет интерес. Можно обозначить эту связь "как/почему" во время поиска подходяще1'О уровня цели для ша1'а (см. рис. 5.2). Чтобы повысить уровень цели одио1'О или нескольких ша1'ОВ, спросите, почему действующее лицо это делает. Ответом будет цель одиим уровнем выше. Способ оценить уровни целей  посмотреть на длину варианта использова ния. Большинство хорошо написанных вариантов использования имеют от двух ДО восьми ша1'ОВ. Я НИКО1'да не видел варианта использования длиннее, чем 11 ша1'ОВ, который бы не ВЫИ1'рывал от сокращения. Сомневаюсь, что в этих числах есть чтонибудь ма1'ическое, но я предпола1'аю, что люди не желают или не умеют думать в терминах процессов, которые требуют более 1 О промежуточных ша1'ОВ. Я дожи- даюсь серьезно1'О контрпримера, только чтобы доказать, что числа не оказывают 1'лубоко1'О влияния. Какой бы ни была причина, имейте в виду это наблюдение, чтобы улучшить ваши варианты использования. Если у вас больше 10 ша1'ОВ, вы, возможно, включи ли детали интерфейса пользователя или описали ша1'И действий на слишком низком уровне. 
Три поименованных уровня цели 71 . Удалите подробности интерфейса пользователя. Покажите намерениедейству юще1'О лица, а не e1'o перемещение. . Повысьте уровень цели, задавая вопрос "почему", чтобы определить CJlедую щий более высокий уровень цели. . Объедините ша1'И. . Сравните ваши варианты использования с образцами из раздела 5.6 и из 1'ла вы 19. Цель варианта использования l  Цель шаrов : Рис. 5.2. Спросите" почему", чтобы изменить уровни 5.6. Более длинный пример: "Обработка заявления" на нескольких уровнях я выражаю бла1'одарность сотрудникам страховой корпорации пожарных Fuпd In surance Corporation из Новато, Калифорния, разрешивших мне включить варианты использования 1923 в качестве примеров'. Они были написаны специалистами по обработке заявлений в этой области, работающими с бизнесаналитиками из OTдe ла IТ и коллективом разработчиков. Специалисты предметной области 1'лубоко по нимают суть использования системы, о которой специалисты из IT не мо1'ЛИ ДО1'адываться. В свою очередь, сотрудники из IТ помо1' ли экспертам предметной об ласти четко сформулировать варианты использования. Оба коллектива обеспечи ли сочетание предметной, корпоративной и технической сторон. Пишущая команда состояла из Кэрри Биэр, Эйлин Каррен, Брента Хаппа, Полы Айв ей , Сьюзен Пассини, Памелы Пратт, Стива Сэмпсона, Джилл Шиктанц, Нэнси Джуэлл, Тришы Мадалено, Марка fринбеР1'а, Николь Лазар, Дона Копполо и Эрика * Копирайт @ 1999 Fireman's Fund, Novato, CF. Печатается с разрешения. 
72 rлава 5 Иванса. Они демонстрируют, что эксперты в предметной области без навыков про. 1'раммирования MOryт работать со специалистами из IТ над требованиями к системе. Я ВКЛючаю пять вариантов использования для иллюстрации To1'o, что мы к на- стоящему моменту обсудили, особенно областей действия проектирования и уровней целей. Эти варианты использования также демонстрируют хороший стиль написания для ша1'ОВ и расширений. Каждый вариант использования я предваряю комментари. ем, указывая на некоторые интересные или спорные моменты. Набор начинается с варианта использования для бизнеса уровня облака типа "прозрачный ящик". Посмотрите, как цели переходят на более низкие уровни и как область действия системы сжимается от "работы компании" до "всех компьютерных систем" и далее Bce1'oHaBce1'o до "разрабатываемой системы". Подчеркнутые фра. зы представляют собой обращения к дру1'ИМ вариантам использования. Шаблон был HeMHo1'o изменен, чтобы основной сценарий успеха был ближе к началу и быст- рее читался. КОММЕНТАРИЙ К ВАРИАНТУ ИСПОЛЬЗОВАНИЯ 19. SuD  это работа компании. Обратите внимание, что компьютерная система даже не упоминается. Вариант ис. пользования будет применяться в бизнесе, чтобы скрепить бизнеспроцедуры и об. ле1'ЧИТЬ работу с помощью компьютера. В настоящий момент этот вариант использования находится лишь на первом этапе проектирования. Как обычно, основной сценарий ВЫ1'лядит тривиальным. Он показывает, как все работает в са- мой бла1'ОПРИЯТНОЙ ситуации. Интересные моменты откроются в ситуациях отказа и КО1'да компания будет использовать эту информацию для внесения поправок в поддержку эксплуатации системы. Обратите внимание на участников. Вариант использования 19 t;1 Обработка заявления (бизнес) О Обпасть действия: работа страховой компании t;1 Уровень: обобщенный для бизнеса Версия: будущая Статус: набросок Ревизия: текущая Контекст испопьзования: оценщик обрабатывает заявление. Предусповия: понесен ущерб. Триrrер: заявление подано в страховую компанию. Основной сценарий: 1. Сторона заявителя, знающая о событии, реrистрирует ущерб в страховой компании. 2. Служащий принимает и распределяет заявление оценщику. З. Назначенный оценщик проводит расследование оuенивает сумму возмещения ущерба 
Три поименованных уровня цели 73 определяет резервы ведет neperoBopbI по заявлению доrоваривается о сумме возмещения и закрывает заявление Расширения: последуют в дальнейшем. rарантия успеха: устанавливается сумма возмещения и дело закрывается Минимаnьная rарантия: нет. Участники и интересы: Подразделения страховой компании, продающие ее страховые полисы Клиенты страховой компании, покупающие полисы Министерство страхования, осуществляющее руководство рынком страховых услуr Претенденты, понесшие ущерб в результате действия застрахованноrо лица Отдел заявлений страховой компании Будущие клиенты КОММЕНТАРИЙ К ВАРИАНТУ ИСПОЛЬЗОВАНИSl10. Ниже следует еще один вари ант использования, в котором SuD все еще является работой компании. Однако цель находится на более низком уровне, чем в варианте использования 19. Здесь описывается работа оценщика, которая может длиться дни, недели или месяцы. Это обобщенный вариант использования уровня ВОЗДУШНО1'о змея, поскольку co держит MHo1'o односеансовых действий. Автор не 1'оворит о компьютере прямо, а только называет цели оценщика. Раз работчики должны придумать, в чем может заключаться помощь компьютера в этом процессе. Этот вариант использования служит им сырьем для изобретения. Ша1' 7 был добавлен в связи с интересами Министерства страхования. Вариант использования 10 t;Т Пронзвестн оценку ущерба по заявпенню ? Обnасть действия: работа страховой компании t;Т Уровень: белый (обобщенный, выше уровня цели единичноrо пользователя) Контекст ИСПОnЬЗ0вания: оценщик производит всестороннюю оценку обстоятельств nOHeceHHoro ущерба. Основное действующее nицо: оценщик Предусnовия: документирование последует Триrrер: документирование последует Основной сценарий: Обратите внимание: идеально, KorAa перед оценкой проведено расследование, однако rлубина расследования может изменяться от заявления к заявлению. 
74 r лава 5 1. Оценщик просматривает и оценивает медицинские отчеты, документы на арестованное имущество, прибыль на данное число и друrие документированные доказательства. 2. Оценщик оценивает постоянную неплатежеспособность, используя юридическую формулу для определения процента неплатежеспособности. З. Оценщик определяет сумму долrа при постоянной неплатежеспособности, беря кредит для авансированных сумм и платы за арестованное имущество, чтобы установить полную сумму по заявлению. 4. Оценщик определяет окончательный диапазон суммы возмещения. 5. ОцеНЩI1К проверяет резервы, чтобы убедиться, что компания в состоянии уплатить сумму в установленных пределах. 6. Оценщик добивается утверждения установленной суммы выплаты и увеличения резерва, если это входит в ero полномочия. 7. Оценщик приобщает к делу документы. 8. Оценщик посылает корреспонденцию и (или) документацию заинтересованным сторонам, если это необходимо. 9. Оценщик продолжает приобщать к делу документы, касающиеся всех действий по уреrулированию. Расширения: ... Частота собь.тиSl: оценивается каждое заявnение; это может происходить несколько раз в день. rарантиSl успеха: заявление оценивается и определяются пределы величины возмещения. МинимаnьнаSl rарантиSl: прежде чем начнется повторная оценка заявления для уреrулироваНI1Я претензии, будет произведено дополнительное расследование или составлено медицинское заключение. Участники и интересы: Претендент  хочет получить максимальную сумму возмещения. Оценщик  хочет установить минимально допустимую сумму возмещения. Страховая компания  то же самое. Поверенный (защита и обвинение) застрахованных лиц. Отдел страхования и opraHbI rocYAapcTBeHHoro управления штатов (в каждом штате свой департамент, надзирающий за законностью ведения дел и выплачиваемых сумм) охраняют законность и cTporoe соблюдение процедур. Открытые вопросы: при разработке бизнесправил придется обращаться к вопросам юрисдикции. КОММЕНТАРИЙ К ВАРИАНТУ ИСПОЛЬ30ВАНИSl11. МНО1'им специалистам, заня тым в проекте, этот системный вариант использования показался расплывчатым ДО бесполезности. Однако время на e1'o создание было потрачено не зря, и тому есть несколько причин. 
Три поименованных уровня цели 75 Вопервых, он объединил ряд вариантов использования для пользователя в co ответствии с бизнесправилами. Он описывает процессы закрытия, очистки и архи вирования заявления, которые ряду участников проекта просто не известны. Хотя три последиих шаrа не сильно за1'ружают работой ПРО1'раммистов, они являются ча  стью процедуры обработки заявления, полезной контекстуальной информацией для любо1'О читателя. BOBTOpЫX, он записывает в служебные файлы бизнесправила, не знакомые некоторым разработчикам. Накануне rруппа потратила три рабочих часа, пытаясь выяснить, что это за правила. Этот вариант использования сбере1' 1'ораздо больше времени (которое иначе ушло бы на обсуждение), чем было потрачено на e1'o соз Д8ние. Этот вариант использования служит введением и О1'лавлением для Читателей, от руководителей до новых работников компании. Руководители увидят, что в Hero BO шли ключевые процессы, а новички узнают, как работает компания и У1'лубятся в Ba рианты использования для целей пользователя. Интересно расширение *al, так как оно вызьrвает вариант использования обработки отказов, который не может быть на  писан оценщиками, а должен быть создан в 1'руппе разработчиков. Вариант испопьзования 11 11 Обработка заявпения (системы) + .? 06ласть действия: "система" как комплекс всех компьютерных систем 111 Уровень: обобщенный (белый) Версия: 1 я Статус: rOToB для анализа Ревизия: текущая Контекст испоnьзовання: клиент хочет получить возмещение за страховое событие. Основное действующее nицо: клиент Предусnовия: нет Триrrер: клиент подает заявление. Основной сценарий: 1. Клиент подает заявление (на бумаrе, по телефону или факсу) служащем у. 2. Служащий находит полис, реrистрирует заявление в системе и назначает оценщика. З. Оценщик расследует заявление и обновляет ero с помощью дополнительной информации. 4. Оценщик вводит информацию по ходу расследования. 5. Оценщик корректирует записи и резервирует сумму по ходу расследования. 6. Оценщик попучает документацию, включая счета за период срока действия заявления, и вводит счета. 
76 r лава 5 7. Оценщик оценивает ущерб по заявлению и документирует процесс neperoBopoB в системе. 8. Оценщик решает вопрос с возмещением и закрывает дело в системе. 9. Система удаляет заявление из базы данных спустя 6 месяцев после закрытия дела. 10. Система архивирует заявление по прошествии установленноrо периода. Расширения: *а. В любое время система выходит из строя: *а1. rpynna системной поддержки восстанавливает систему. 1 а. Представленная информация неполна: 1а1. Страховая компания запрашивает недостающую информацию. 1а2. Претендент предоставляет недостающую информацию. 1 а2а. Претендент не предоставляет информацию в течение установленноrо периода. 1а2а1. Оценщик закрывает дело в системе. 2а. У претендента недействительный полис: 2а1. Страховая компания отклоняет заявление, уведомляет претендента, обновляет заявление, закрывает дело. За. На данный момент нет свободных areHToB: За 1. (Что мы здесь делаем?) 8а. Претендент уведомляет оценщика о новых действиях по поводу возмещения: 8а1. Служащий открывает дело повторно. Возвращается к шаrу З. Список изменений в технопоrии и данных: Частота события: документирование последует. rарантия успеха: дело закрыто, уреrулировано и помещено в архив. Минимапьная rарантия: дело закрыто, но' может быть открыто позднее. Участники и интересы: Компания  выплатить минимально допустимое возмещение. Клиент  получить максимальное возмещение. Министерство страхования  rарантировать корректность процедур. Бизнесправипа: Дата описаний: будет установлена в друrих вариантах использования. Связи с интерфейсом попьзоватепя (UI): предстоит документировать. Открытые вопросы: период, по окончании KOToporo следует помещать дело в архив. КОММЕНТАРИИ К ВАРИАНТУ ИСПОЛЬЗОВАНИЯ 11. Это один из самых сложных ва- риантов использования, которые я видел. Он показывает, почему варианты исполь- зования следует описывать естественным языком. rлавный источник сложности  порядок следования. Служащий на телефоне, 1'оворящий с обезумевшим клиентом, должен быть в состоянии вводить данные в лю. 
Три поименованных уровня цели 77 бом порядке, в то же время пытаясь следовать стандартной последовательности BO просов. Одновременно компьютер использует эти данные по мере их ввода для ВОЗможной на данный момент обработки, например сбор записей по этому клиенту, присвоение заявлению номера и назначение оценщика. Авторы написали не меньше четырех полных версий это1'О варианта использования, добиваясь ясности, чтобы по казать нормальное течение работы и то, что компьютер работает асинхронно. Воз можно, на седьмойвосьмой ревизии они нашли бы чтото лучшее, но почувствовали, что дальнейшее умножение ревизий неэффективно, и остановились на этой версии. Этот вариант использования вызывает вариант использования Найти что У1'одно несколько раз, задавая при каждом вызове различные объекты и критерии поиска. Разработчики придумали остроумное решение, чтобы не переписывать несколько раз стандартные ша1'И поиска (списки совпадений, критерии сортировки, повторная сортировка, повторный поиск, объект не найден и т.д.). Я прошу вас сделать то же самое в упражнении 5.4 в конце 1'лавы. Обработка расширения *а. Сбой питания неожиданно стал причиной появления новых проблем с требованиями. Было введено понятие промежуточных сохранений, которые служащему пришлось потом отыскивать. Это стало сюрпризом для писате лей, а дополнительная проблема хранения и поиска временно хранимых данных  сюрпризом для разработчиков. Все это вылилось в условие отказа 6Ь, которое Kaca лось таймаута для временно хранимых данных и ставило перед писателями очень конкретный вопрос: "Каковы бизнесправила для временно введенных данных? Они не MOryт быть зафиксированы, поскольку недостает важной информации, но и yдa лить их нельзя, так как они удовлетворяют минимальному критерию ввода". Разра ботчики так и сяк вертели неприемлемые альтернативы (не делать промежуточных сохранений и удалять данные), пока не решили эту проблему. Расширение 1 с демонстрирует отказы внутри отказов. Авторы мо1'ЛИ бы превра  тить это В собственный вариант использования, но они решили, что это сильно усложнит набор вариантов использования (новый вариант использования пришлось бы отслеживать, анализировать и поддерживать). Вместо ЭТО1'О они сделали ero pac ширением расширения. МНО1'ие применяют расширения варианта использования по этой причине, хотя в большинстве случаев это объясняется тем, что авторам удобнее для начала сделать собственный вариант использования расширением. Расширение 25a демонстрирует, как податлива среда. "Условие может возник нуть на любом ша1'е от BToporo до пято1'о. Как e1'o следует описывать  один раз для каЖДО1'О случая возникновения? Это представляется слишком расточительным. Было решено просто написать понятные читателям расширения 25a и 25b. Вариант использования 22 . Зареrистрировать ущерб  06nacTb Действия: "система" означает компьютерную систему обработки заявлений  Уровень: rолубой (цель пользователя) . Версия: 2 
'8 r лава 5 Статус: проанализирован Ревизия: теКУLЦая Контекст испоnьзования: фиксирование полной информации об УLЦербе. Основное действующее nицо: служаLЦИЙ Предусnовия: служаLЦИЙ уже вошел в систему. Триrrер: служаLЦИЙ уже начал вводить данные об УLЦербе. rарантия успеха: данные об УLЦербе реrистрируются и сохраняются. Минимаnьная rарантия: ничеrо не происходит. Участники и интересы: как выше Основной сценарий: Чтобы ускорить работу служаLЦеrо, система должна работать асинхронно, как только будут записаны необходимые данные. СлужаLЦИЙ может вводить данные в любом порядке в соответствии с требованиями момента. СлеДУЮLЦая последовательность представляется наиболее вероятной. 1. СлужаLЦИЙ вводит номер полиса застрахованноrо лица 11, возможно, ero имя и дату cTpaxoBoro события. Система анализирует доступную информацию о полисе и указывает, что заявление соответствует полису. 2. СлужаLЦИЙ вводит основные данные об УLЦербе. Система подтверждает, что не cYLЦecTByeT потенциально КОНКУРИРУЮLЦИХ заявлений, и присваивает заявлению номер. З. СлужаLЦИЙ продолжает вводить информацию об УLЦербе, соответствуюLЦУЮ заявлению AaHHoro типа. 4. СлужаLЦИЙ использует систему для получения дополнительной информации по делу из друrих компьютерных систем. 5. СлужаLЦI1Й выбирает и назначает оцеНLЦика. 6. СлужаLЦИЙ подтверждает, что он закончил; система сохраняет данные и инициирует отправку уведомления areHTY. Расширения: *а. Сбой питания во время обработки заявления: *а 1. Система периодически автоматически сохраняет данные (возможно, в определенных точках фиксации транзакции, открытый вопрос). *Ь. Заявление не подлежит обработке в нашей компании: *Ь1. СлужаLЦИЙ указывает системе, что вводится заявление "только с целью записи" и продолжает либо завершает обработку заявления. 1 а. Найденная информация о полисе не соответствует информации застрахованноrо лица: 1 а 1. СлужаLЦИЙ вводит правильные номер полиса или имя застрахованноrо лица и просит систему проверить данные с новым индексом полиса. 1 Ь. По имеюLЦИМСЯ данным система не смоrла найти полис: 1 Ь 1. СлужаLЦИЙ возвраLЦается к заявлению и вводит имеЮLЦИеся данные. 1с. СлужаLЦИЙ изменил номер полиса, дату cTpaxoBoro события или тип заявления по сравнению с данными npeAbIAYLЦero поиска: 
rри поименованных уровня цели 79 1с1. Система проверяет правильность изменений, анализирует страховое событие с правильной информацией о полисе, проверяет и подтверждает, что заявление соответствует полису. 1с1а. Система не может подтвердить соответствие полису: 1 с 1 а 1. Система предупреждает служащеrо. 1с1а2. Служащий отыскивает полис, используя параметры поиска для полиса. 1с2. Система предупреждает служащеrо о необходимости пересмотреть сумму возмещения. 1d. Служащий хочет повторно запустить обработку заявления, которая была прервана и данные по которой были сохранены или которую следует завершить: 1 d 1. Служащий находит дело с помощью параметров поиска для заявления. 1d2. Система открывает данные для редактирования. 25a. Служащий изменяет ранее введенный тип заявления и данные, относящиеся к новому типу, не вводятся: 25a1. Система представляет соответствующие поля дела, относящиеся к нововведенному служащим типу заявления. 25b. Служащий изменяет ранее введенный тип заявления, и в связанных с типом полях появляются данные: 25b1. Система предупреждает, что данные существуют, и предлаrает служащему отменить изменения либо продолжить с новым типом заявления. 25b1a. Служащий отменяет изменение, система продолжает обработку заявления. 25b1b. Служащий настаивает на новом типе заявления, система стирает определяемые типом данные (но сохраняет все основные данные заявления). 2с. Система обнаруживает потенциальный дубликат заявления: 2с1. Система показывает список возможных заявленийдубликатов из базы данных заявлений. 2с2. Служащий выбирает и просматривает заявление из списка. Этот шаr может повторяться несколько раз. 2с2а. Служащий обнаруживает, что это заявление  дубликат: Служащий открывает заявлениедубликат из списка заявлений для редактирования, если оно не помечено как обработанное (в соответствии с уровнем безопасности данных для служащеrо). Служащий может удалить любые данные в ранее сохраненном файле. 2с2Ь. Служащий обнаруживает, что заявление не является дубликатом: служащий возвращается к заявлению и завершает ero обработку. 2d. Предварительная информация об ущербе изменяется после первой проверки заявлениядубликата: 
о rлава 5 2d 1 . Система снова проверяет заявлениедубликат. 2е. Служащий может сохранять данные по заявлению несколько раз, пока не завершит шаrи 26. (Иноrда он может сохранять данные просто для удобства или ввод приходится по какойто причине прервать, например, заявление должно быть немедленно передано на обработку оценщику более BbIcoKoro класса.) 2е1. Служащий сохраняет данные по заявлению, чтобы завершить обработку позднее. 45a. Тип заявления либо описание ущерба (см. бизнесправила) изменились, с тех пор как служащий анализировал сумму возмещения: 45a1. Система предупреждает служащеrо, что надо пересмотреть сумму возмещения. 6а. Служащий подтверждает, что он закончил, не завершив ввод минимума информации: 6а1. Система предупреждает служащеrо, что не может принять заявление без даты cTpaxoBoro события, имени застрахованноrо лица или номера полиса и назначения оценщика. 6а 1 а. Служащий решает продолжить ввод данных по заявлению или сохранить данные без отметки о завершении. 6а1Ь. Служащий настаивает на выходе без ввода минимума информации, система аннулирует все сохраненные промежуточные данные и npекращает работу. 6а2. Система предупреждает служащеrо, что он не может присваивать заявлению номер, не заполнив обязательных полей (тип заявления, дату cTpaxoBoro события, номер полиса или имя застрахованноrо лица); система фокусирует внимание служащеrо на полях, требующих ввода. 6Ь. Таймаут: служащий временно сохранил данные по заявлению, намереваясь вернуться к обработке; система решила, что самое время зафиксировать данные по заявлению, но оказалось, что не введено имя оценщика: 6Ь1. Система назначает оценщика по умолчанию (см. бизнесправила) . Частота собьт.я: ?? 6нзнес-правнла: *. KorAa сохраненные данные по заявлению передаются rлавной системе (временные диаrраммы)l 1. Минимум попей, необходимых для сохранения данных по заявлению (и чтобы их можно было потом найти): ... 2. Номер заявления, однажды присвоенный системой, не может измениться. З. Бизнесправила для ручноrо ввода номера заявления  понадобитсяl 4. Описание ущерба состоит из двух полей: одно свободной формы, Apyroe  ниспадающее меню. 
Три поименованных уровня цели 81 5. Система должна знать, как определить сумму возмещения, исходя из префикса полиса. 6. Поля, которые необходимо заполнить, чтобы подтвердить ущерб: 6Ь. Правила назначения оценщика по умолчанию: ... Испольэуемь.е описания данн",х: Параметры поиска полиса, информация об индексе полиса, предварительная информация об ущербе, информация об ущербе, обусловленная типом заявления, дополнительная информация. Параметры поиска заявления, критерий проверки на заявлениедубликат, список возможных заявленийдубликатов, заявление из списка. Связи с UI: предстоит документировать Владелец: Сьюзен и Нзнси Рецензент...: Элистер , Эрик ... Откр",т...е вопрос...: Как часто происходит автосохранениеl Карточки официально1'О уведомления a1'eHToB  1'де и как их печатают и т.д.? rруппа разработчиков решила, что было бы 1'лупо писать почти идентичные вари анты использования Найти клиента, Найти полис и Т.д. Вместо ЭТО1'о они создали Ha страиваемый алrоритм, который применяла каждая команда писателей. Любое преД1Iожение в форме Найти ..., например Найти клиента или Найти изделие, означает вызов варианта использования Найти что у1'ОДНО с неявным замещением "чееото" специальным термином. Каждому варианту использования понадобится свой критерий поиска, сортировки и вывода на экран, поэтому писатель будет записывать данные и оrpаничения на различных листах с 1'ипертекстовыми связями. Поэтому при мер пред ложения будет ВЫ1'лядеть как Найти клиента , используя Параметры поиска клиента . При этом четком СО1'лашении лоrику варианта использования Найти что уеодно можно написать только ОДНН раз и применять во мно1'ИХ похожих, но неидентичных контекстах. Это очень понравилось разработчикам, так как это означает, что Д1IЯ всех видов поиска им придется разработать только один ал1'оритм. Попробуйте на этом при мере свои силы. Пока не буду показывать данное решение. Поработайте над упражне нием 5.4, прежде чем за1'лядывать в решение, которое обсуждается в разделе 14.2. Вариант испопьзования 13 . Нанти что yroAHo (постановка задачи) х3!> Заполнить в качестве упражнения. 5.7. Упражнения Уровни цели 5.1. Дженни стоит перед банкоматом CBoe1'o банка. Темно. Она ввела свой РINкод И ищет кнопку "Ввод". Назовите для Дженни цели белую, 1'олубую и цвета инди1'О. 
82 r лава 5 5.2. Перечислите не менее десяти целей различных основных действующих лиц в отношении банкомата и укажите их уровни целей. 5.3. Перечислите обобщенные цели и цели пользователей всех основных действующих лиц для ПРО1'раммно1'О обеспечения PAF (персонально1'О консультанта по финансам), описанно1'О в упражнении 4.4. Определите самый высокий уровень, предельные комбинации "действующее лицо/сфера/цель" . 5.4. Найдите что уrодно. Напишите вариант использования Найти что У1'одно, триrrером KOTopo1'o является желание пользователя локализовать нечто. Вариант использования должен позволить пользователю вводить параметры поиска и сортировки. Он также должен иметь дело со всеми ситуациями, которые MOryT возникнуть, и В случае успеха завершиться определением компьютером это1'О "че1'ОТО" независимо от дальнейше1'О e1'o применения в вызывающем варианте использования. 
rлово 6 Предусловия, трИ22еры и 2араuтии 6.1. ПреАУСЛОВИЯ Предусловие варианта использования объявляет, выполнение KaKo1'o условия 1'a рантирует система перед тем, как разрешить запуск ЭТО1'о варианта использования. Так как условие выполняется системой, и известно, что оно истинно, то оно не будет проверяться снова в период выполнения варианта использования. Общеизвестный пример: пользователь уже вошел в систему и система идентифицировала e1'o. Вообще предусловие определяет, что ДРУ1'ой вариант использования уже OTpa ботал, чтобы установить e1'o. Будем 1'оворить, что вариант использования Размес тить заказ полаrается на предусловие входа в систему. Я сразу же смотрю, какой вариант использования установил e1'o (я бы поискал Войти в систему). Лично я обычно создаю вариант использования более BbIcoKo1'o уровня, в котором упомина ются варианты использования Разместить заказ и Войти в систему, чтобы чита тель видел, как они соотносятся дру1' с дру1'ОМ. В этом примере это может быть обобщенный вариант использования Работать с прuложением. В этом случае мы применяем приведенную ниже структуру (я сокращаю шаблон, чтобы просто пока зать существенные части). Обратите внимание на уровни целей трех вариантов испо льзования. Вариант испопьзования Работать с припожением Уровень: обобщенный (белый) Предусповне: отсутствует 1. Служащий входит в систему. 2. Служащий размещает заказ. 
84 rлава 6 Вариант использования Вонти в систем у Уровень: подфункция (индиrо) Предусловне: отсутствует Вариант использования Разместить заказ Уровень: цель пользователя (rолубой) Предусловне: служащий вошел в систему. Не все следуют моему правилу писать более высокий вариант использования, чтобы собрать варианты использования более НИЗКО1'о уровня. Таким образом, вы можете включить в предыдущий пример только варианты использования Войти 8 систему и Разместить заказ. Вы должны уметь вывести из документа, что преду- словие правильно и будет обязательно выполнено. Продолжим этот пример, чтобы показать вариант использования, устанавлива- ющий условие в одном ша1'е и пола1'ающийся на это условие в подчиненном варианте использования. И опять подчиненный вариант использования рассчитан на то, что условие истинно, и не будет поверять наличие ошибок. Вариант использования Разместить заказ Уровень: цель пользователя (rолубой) Предусловне: служащий вошел в систему. 1. Служащий идентифицирует клиента, система находит данные пользователя. 2. Служащий вводит информацию о заказе. З. Система рассчитывает расценки. Вариант использования Рассчитать расценки Уровень: подфункция (индиrо) Предусловне: клиент установлен и известен системе; содержимое заказа известно. 1. Система рассчитывает базовую расценку для заказа. 2. Система рассчитывает скидку для клиента. 
Предусловия, триrrеры и raрантии 85 Этот пример иллюстрирует, как один вариант использования пола1'ается на ин формацию, фиксируемую в вызывающем варианте использования. Автор варианта использования Рассчитать расценки объявил информацию, которая уже имеется, и теперь может ДВИ1'аться вперед и обращаться к данным клиента. Внимательный читатель недоверчиво отнесется к варианту использования Pac считать расценки. Я сказал, что он цвета инди1'О, но до сих пор неясно даже, явля ется ли он самостоятельным вариантом использования. Если я как автор не раскрою сложных взаимодействий с пользователем или интересных случаев отказа, я пере классифицирую e1'o как черный (ПИКТО1'рамма моллюска). Это послужит СИ1'налом включить этот текст обратно в вариант использования Разместить заказ и уничто жить вариант использования Рассчитать расценки. Пишите предусловие как простое утверждение о состоянии окружающей среды на момент открытия варианта использования. Вот некоторые примеры используемых предусловий: Предусловне: пользователь вошел в систему. Предусловне: клиент идентифицирован. Предусловне: система уже локализовала данные полиса клиента. Распространенной ошибкой является записывать в предусловие утверждение, которое часто, но не обязательно бывает истинным. Допустим, мы пишем вариант использования Затребовать сводку по возна ераждениям с заявителем в качестве OCHoBHo1'o действующе1'О лица. ЛО1'ично пред положить, что заявитель подал по крайней мере одно заявление или счет, прежде чем просить вьщать ему сводку возна1'раждений. Однако это не все1'да так. Система не может это 1'арантировать, и на самом деле это несущеетвенно. Заявителям следует предоставить возможность потребовать сводку их возна1'раждений в любое время, поэтому неправильно было бы написать предусловие Заявитель подал счет. 6.2. МинимаЛЬНЬlе rарантии Минимальные еарантии  это наименьшие обещания системы участникам, в Ча стности, если цель OCHOBHo1'o действующе1'О лица не может быть ДОСТИ1'нута. Ko нечно, они действительны и при достижении цели, но реальный к ним интерес возникает, если основная цель не может быть выполнена. Большую часть времени два или более участников вынуждены иметь дело с минимальными 1'арантиями, Ha пример пользователь, компания, поставляющая систему, и, возможно, op1'aHbI 1'o сударственно1'О управления. Не старайтесь перечислить в разделе Минимальные 1'арантии все возможные Д1IЯ данно1'О варианта использования пути отказа. Существуют десятки путей, и они имеют мало обще1'О. Все условия отказа и обработка отказов раскрываются в разде ле расширений, и поддерживать синхронизацию этих двух списков утомительно и oд новременно чревато ошибками. Задача это1'О раздела шаблона  объявить то, что обещает система. 
86 r лава 6 Наиболее распространенной минимальной 1'арантией является следующая: "Сис. тема заре1'истрировала точку, до которой она продвинулась". Ре1'истрация сбоев тран, закций не является ни очевидной, ни тривиальной. В описании требований часто забы- вают о системных журналах, а потом ПРО1'раммисты MOryт о них вспомнить. Однако они чрезвычайно важны как Д1IЯ владельцев системы, так и Д1IЯ ее пользователей. Сис. тема использует журнал, чтобы продолжить транзакцию после восстановления норма- льных условий работы; участникам он нужен Д1IЯ уреryлирования спорных вопросов. Автор варианта использования должен определить, насколько необходимо использо- вать журнал, выяснив интересы участников либо хорошо обдумав условия отказов. Минимальные 1'арантии записываются в виде ряда простых утверждений, кото- рые будут истинны по окончании каждо1'О варианта использования. Они показывают, что интересы каждо1'О участника удовлетворены. Минимальные 1'арантии: заказ будет инициирован только по получении оплаты. Минимальные 1'арантии: если не был зафиксирован минимум информации, не. полное заявление отклоняется, и ре1'истрация заявления не про водится; если был за. фиксирован минимум информации (см. бизнес-правила), неполное заявление будет сохранено и заре1'истрировано. Тест "прошел/не прошел" Д1IЯ раздела минимальной 1'арантии состоит в том, что участники СО1'лашаются с тем, что их интересы защищены при возникновении усло- вий отказа Д1IЯ данной цели. 6.3. rарантия успеха rарантия успеха устанавливает, что интересы участников удовлетворяются при успешном завершении варианта использования в конце OCHoBHo1'o сценария или в конце успешно1'О альтернативно1'О пути. Обычно она пишется в добавление к мини. мальным 1'арантиям: предоставляются минимальные 1'арантии и выполняются не. которые дополнительные условия. Эти дополнительные условия включают по крайней мере цель, объявленную в за1'оловке варианта использования. Подобно минимальным 1'арантиям, 1'арантия успеха записывается как набор простых утверждений, которые применяются в конце успешно1'О выполнения вариан- та использования и показывают, что интересы каждо1'О участника удовлетворены. Например: rapaHTHJI успеха: претенденту будет выплачено возмещение, соответствующее доrоворенности, заявление закрыто, соrлашение зареrистрировано. rapaHTHJI успеха: файл будет сохранен. rapaHTHJI успеха: система инициирует для клиента заказ, получив информацию об оплате и зареrистрировав запрос на заказ. Тест "прошел/не прошел" Д1IЯ раздела 1'арантии успеха состоит в том, что участ- ники СО1'лашаются с тем, что их интересы удовлетворены. Лучший способ раскрыть 1'арантию успеха  это спросить: "Что Сделало бы ЭТО1'О участника несчастным по окончании успешно1'О выполнения варианта исполь. 
, Предусловия, триrrеры и raрантии 87 З0вания?" На этот вопрос обычно ле1'КО ответить. Затем напишите отрицание ответа. Чтобы посмотреть пример, выполните упражнение 6.4, а потом прочтите обсуждение этой темы в приложении В. 6.4. Триrrеры Трuееер определяет событие, которое запускает вариант использования. ИНО1'да ТРИ1'1'ер предшествует первому шаry варианта использования, в ДРУ1'ой раз сам яв ляется первым ша1'ОМ. До настояще1'О времени я не встречал убедительно1'О доказа тельства, что одну форму можно применять во всех случаях. Также я не замечал, чтобы возникала путаница, если предпочесть один способ дрУ1'ому. Вам придется обучать ваш персонал или совершенствовать стиль проектирования. Будем считать, что система банкомата начинает работать, только КО1'да пользо ватель вставляет в банкомат свою карточку. Таким образом, не имеет смысла 1'OBo рнть, что ТРИ1'1'ер имеет место, КО1'да KTOTO решает использовать банкомат. ТРИ1'rер Клиент вставляет карточку является также первым ша1'ОМ варианта использования. Вариант использования Работать с банкоматом TpHrrep: клиент вставляет карточку. 1. Клиент вставляет карточку с идентификатором банка, номером счета и закодированным PINKOAOM. 2. Система проверяет... Теперь рассмотрим пример со служащим, сидящим целый день за рабочей CTaH цией, на экране которой имеется набор ПИКТО1'рамм для запуска различных приклад- ных ПРО1'рамм. ТРИ1'1'ер  это то, что клиент вызывает с помощью KOHKpeTHo1'o запроса, который можно выразить в любой форме. Для иллюстрации я напишу e1'o вторым способом. Вариант использования Зареrистрировать жалобу TpHrrep: клиент обращается с рекламацией. 1. Служащий вызывает приложение. 2. Система ВЫВОДИТ последний вариант списка рекламаций для служащеrо. 6.5. Упражнения Минимальные rарантии 6.1. Напишите минимальную 1'арантию для извлечения дене1' из банкомата. 
88 rлава 6 6.2. Напишите минимальную 1'арантию для 1'лавно1'О варианта использования системы PAF (персональный консультант по финансам описан в упражнении 4.4). 6.3. Напишите минимальную 1'арантию для варианта использования уровня моря вашей текущей системы. Покажите ее колле1'ам и предложите им проанализировать ее с точки зрения интересов участников. rарантии успеха 6.4. Напишите 1'арантию успеха для извлечения дене1' из банкомата. 6.5. Напишите 1'арантию успеха для 1'лавно1'О варианта использования системы PAF. 6.6. Напишите 1'арантию успеха для варианта использования уровня моря вашей текущей системы. Покажите ее колле1'ам и предложите им проанализировать ее с точки зрения интересов участников. 
rлово 7 C1J,enapuu и шаzu Набор вариантов использования  это непрерывно разворачивающаяся история преследования основными действующими лицами своих целей. Каждый вариант использования имеет ветвящуюся сюжетную линию, которая показывает, как сис тема обеспечивает достижение цели или oTBep1'aeT ее. Эта сюжетная линия преk ставлена основным сценарием и набором фра1'ментов сценария в качестве расширений к нему. Каждый сценарий или фра1'мент стартует при выполнении условия запуска, Korqpoe указывает, КО1'да происходит запуск, и остается истин ным, пока сценарий не завершится или цель не будет oTBep1'HYTa. Все цели разные по сложности, поэтому мы используем одинаковую форму для описания процесса достижения цели любой сложности на любом уровне сценария. 7.1. ОСНОВНОЙ сценарий При объяснении каКО1'олибо сложно1'О понятия мы начинаем с простых и доступ ных вещей, а потом добавляем: "Ну, на самом деле, это HeMHo1'o сложнее. КО1'да случается TOTO и TOTO, В действительности происходит следующее...". Такой стиль объяснения очень хорош: и таким способом мы описываем ветвя шуюся сюжетную линию, которая становится вариантом использования. Сначала мы создаем от начала до конца описание одно1'О просто1'О для понимания и довольно ти ПИчнО1'О сценария, в котором ДОСТИ1'ается цель OCHoBHo1'o действующе1'О лица и YДOB летворяются интересы всех участников. Это основной сценарий. Все ДРУ1'ие способы преуспеть в достижении цели и обработка всех неудач описаны в расшире ниях к этому варианту использования. Общая структура Основной сценарий и все e1'o расширения находятся внутри структуры, в которую входят следующие части: 
90 rлава 7 . Условие, при котором работает сценарий. Для OCHoBHo1'o сценария это предусловие вместе с ТРИ1'1'ером.Для сценария расширения это условие расши- рения (возможно, с номером ша1'а или местом в сценарии, к которому относит ся условие). . Цель. Для OCHoBHo1'o сценария это название варианта использования. Цель обязательно соответствует интересам участников. Для сценария расширения целью является либо достижение цели варианта использования, либо Boccoe динение с основным сценарием после обработки условия. . Набор шасов действия. Формирует тело сценария и следует одинаковым пра- вилам в каждом сценарии или фра1'менте сценария. . Условие окончания. ЦеЛЬДОСТИ1'ается в конце OCHoBHo1'o сценария. Фра1'мент сценария может заканчиваться достижением цели либо отказом от нее. . Возможный набор расширений, написанный в виде фраементов сценария. Расширения к основному сценарию помещаются в раздел расширений шабло- на варианта использования. Расширения к расширениям распола1'ают в той же строке, внутри тела расширения или сразу за ним. Здесь представлены две выдержки из варианта использования 1, который я pac крыл, чтобы показать сходство общих структур. Основной сценарий: Вариант испопьзования Купить ценные 6у маrи через Ннтернет Предусповие: nporpaMMa PAF у пользователя уже открыта. Триrrер: пользователь выбрал "покупку ценных бумаr". 1. Пользователь решил купить ценные бумаrи через Сеть. 2. PAF получает от пользователя название нужноrо сайта (E*Trade, Schwab и т.д.). З. PAF подключается к сайту, сохраняя управление процессом. 4. Покупатель выбирает и покупает ценные бумаrи на зтом сайте. 5. PAF перехватывает ответы wеЬсайта и обновляет портфель покупателя. 6. PAF показывает покупателю новое состояние портфеля. Расширение к данному варианту использования: За. Отказ Сети любоrо рода во время установки: За1. Система сообщает пользователю о неудаче, дает совет и возвращается на предыдущий шаr. За2. Пользователь либо отказывается продолжать этот вариант использования, либо пробует снова. 
Сценарии и шаrи 91 В этой 1'лаве мы подробно рассмотрим тело сценария, состоящее из ша1'ОВ дей етвия. Тело сценария Каждый сценарий или e1'o фра1'мент записывается в виде последовательности дей етвий разных действующих лиц, направленных на достижение цели. Я употребляю термин "последовательность" для удобства, но мы можем вносить пометки, по казывающие, что ша1'И можно выполнять параллельно, выбирать в различном по рядке, повторять, а некоторые даже MOryт быть необязательными. Как отмечалось в разделе 2.2, любой отдельный ша1' будет описывать: . Взаимодействие двух действующих лиц ("Клиент вводит адрес") . Ша1' подтверждения для защиты интереса участника ("Система подтверждает РINкод") . Внутреннее изменение для удовлетворения интереса участника ("Система BЫ водит сумму из баланса") Ниже приведен пример типично1'о OCHoBHo1'o сценария, позаимствованный из варианта использования 22. Обратите внимание, что ша1'И 1, 3, 58  это взаимо действия, ша1' 4 проверка, а ша1'И 2 и 9  внутренние изменения. 1. Служащий вводит номер полиса застрахованноrо лица и, возможно, ero имя и дату cTpaxoBoro события. 2. Система анализирует доступную информацию о полисе и указывает, .что заявление соответствует полису. З. Служащий вводит основные данные об ущербе. 4. Система подтверждает, что не существует конкурирующих заявлений, и присваивает заявлению номер. 5. Служащий продолжает ВВОДИТЬ информацию об ущербе, соответствующую заявлению AaHHoro типа. 6. Служащий использует систему для получения дополнительной информации по делу из друrих компьютерных систем. 7. Служащий выбирает и назначает оценщика. 8. Служащий подтверждает, что он закончил. 9. Система сохраняет данные и. инициирует отправку уведомления areHTY. Любой ша1' действия пишется для To1'o, чтобы показать простое действие. Я упо добляю это описанию футбольноrо матча: И1'рок 1 пасует иероку 2; иерок 2 ведет .мяч; иерок 2 пасует иероку 3. Приобретение навыков написания трех видов ша1'ОВ действия бла1'ОТВОРНО CKa жется на вашем стиле описания вариантов использования. Тот же стиль употребля ется для ша1'ОВ действия в каждой части любо1'О варианта использования BblcoKo1'o 
92 rлава 7 либо низко1'О уровня, будь то основной сценарий, расширение, бизнеспроцесс или система. 7.2. Шаrи Аействия Ша1'И действия, которые составляют хорошо написанный вариант использования, представлены в одной 1'рамматической форме, просто м действии, КО1'да одно дейст- вующее лицо выполняет задачу или передает информацию дрУ1'ому действующему лицу. Пользователь вводит имя и адрес. В любое время пользователь может потребовать деньrи назад. Система подтверждает подлинность имени и счета. Система обновляет остаток на счету клиента, чтоб отразить оплату. Обычно временные соотношения можно опустить, так как ша1'И, как правило, следуют один за дру1'ИМ. В способах изложения ша1'ОВ действия существует масса менее важных вариа- ций, как видно из примеров вариантов использования. Тем не менее старайтесь пи- сать, придерживаясь следующих правил. Правила Правнпо 1. Используйте простые предложения Структура предложения должна быть предельно простой: Подлежащее.. .сказуемое.. .прямое дополнение... предложный оборот. Например: Система... удерживает ...сумму... из остатка на счете. И это все. Я 1'оворю об этом, поскольку МНО1'ие непредумышленно опускают под- лежащее. В этом случае неясно, кто же производнт действие (у Ko1'o, так сказать, мяч). Если предложение плохо сформулировано, трудно следнть за развитием сюжета. Правнпо 2. Ясно укажите, "кто владеет мячом" Весьма на1'ЛЯДНЫЙ при мер ё------ приятели, перебрасывающиеся футбольным мячоМ. Иrрок 1 передает мяч И1'року 2, И1'рок 2 немножко ведет мяч, а затем перебрасывает И1'року 3. Мяч может за1'РЯЗНИТЬСЯ, и один из И1'роков e1'o вытрет. у сценария та же структура. На каждом ша1'е одно из действующих лиц "владеет мячом". Это действующее лицо будет подлежащим (первое названное действующее лицо), вероятно, первым или вторым словом в предложении. "Мяч"  это сообще- ние и данные, которые одно действующее лицо передает дру1'ОМУ. Действующее лицо с мячом будет либо владеть им само, либо передавать ко. MYTO еще, либо очищать от 1'рязи. В половине случаев ша1' заканчивается тем, что 
Сценарии и шаrи 93 МЯч получает дрУ1'ое действующее лицо. Спросите себя, кто владеет мячом в конце пред,IIожения. Ответ в варианте использования все1'да должен быть ясным. Правнпо 3. Пишите, rлядя на вариант использования с высоты птичьеrо полета Начинающие авторы вариантов использования, особенно ПРО1'раммисты, создаю щие e1'O описание, часто пишут сценарии с ТочКИ зрения системы, которая смотрит на мир и беседует сама с собой. У них получаются примерно такие пред,IIожения: "Получить карточку банкомата и РINкод. Снять сумму С остатка на счете". Вместо это1'о пишите вариант использования сЛедующИм образом: Клиент вводит В банкомат карточку и PINKOA. Система снимает сумму с остатка на счете. Некоторым писателям нравится стиль драматическо1'О произведения, КО1'да по ведение действующих лиц описывается, как в пьесе. Клиент: Вводит В банкомат карточку и PINKOA. Система: Снимает сумму с остатка на счете. Заметьте, что смысл в обоих случаях остается неизменным. Правнпо 4. Покажите продвижение процесс а ПРО1'ресс отдельно1'О ша1'а связан с тем, насколько приблизилась цель. В обоб щенных, или белых, вариантах использования ша1', вероятно, приближает цель в полном объеме. В варианте использования уровня подфункции приближение цели менее различимо. Если мы видим ша1' Пользователь нажимает на клавишу tab, это значит, что мы за1'ЛЯНУЛИ в вариант использования цвета TeMHo1'o инди1'О (или черно1'О), либо автор просто решил описывать слишком незначительныедей ствия. Ошибочный выбор очень мелких ша1'ОВ сказывается на д,lIине варианта испо льзования. Если вариант использования состоит из 13 17 ша1'ОВ, почти наверняка e1'o пред,IIожения не слишком ПрОДВИ1'ают дело к цели. Вариант использования бу дет более читабельным и понятным, если объединить эти мелкие шажки. При этом объем существенной информации не уменьшится. Я редко встречал хорошо напи санный вариант использования, основной сценарий KOTopo1'o ВКЛючал бы более дe вяти ша1'ОВ. Чтобы найти Д,lIЯ ша1'а цель чуть более BblcoKo1'o уровня, спросите себя, Почему действующее лицо делает это (как описано в 1'лаве 5 в подразделе Повышение и по нижение уровней целей). Ответ на этот вопрос, скорее Bce1'o, окажется нужной Д,lIЯ ваше1'О ша1'а целью, хотя, возможно, вам придется задавать e1'o несколько раз, преж де чем вы получите желаемый ответ (см. далее пример повышения уровня цели с по мощью вопроса "почему"). Пользователь нажимает на клавишу tab Почему пользователь нажимает на клавишу tab? Чтобы попасть в поле адреса. 
94 rлава 7 Почему он пытается попасть в поле адреса? Потому что он должен ввести свои имя и адрес, прежде чем система начнет что-то делать. Он хочет, чтобы система что-то сделала (скорее Bce1'o, выполнила этот самый вариант использования), а д.ля ЭТО1'о ему нужно ввести свое имя и адрес. Таким образом, пред.ложение, описывающее действие, заметно ПРОДВИ1'ающее процесс, ВЫ1'ляднт так: Пользователь вводит имя и адрес. Правнпо 5. Показывайте намерение, а не движения действующеrо лица Описание детальных действий пользователя в процессе работы с пользователь- ским интерфейсом системы  одна из распространенных и серьезных ошибок при создании варианта использования. Я называю это описанием деталей иHтep фейса. Такое описание ухудшает качество документа, изла1'ающе1'О требования к системе, делая e1'o более д.линным, неустойчивым и пере1'руженным связями. . Длинные документы труднее читать и сложнее поддерживать. . Описываемыйдиало1', возможно, не является требованием, но показывает, как автор представляет себе в данный момент интерфейс пользователя. . Диало1' неустойчив в том смысле, что небольшие изменения в проекте системы делают e1'o описание недействительным. Работа проектировщика интерфейса пользователя и заключается в создании эф- фективно1'О интерфейса, который позволит пользователю достиrнуть цели варианта использования. Описание детальных действий соответствует этой задаче проектиро- вания, но не документу, изла1'ающему функциональные требования. В документе, изла1'ающем требования, нас интересует описание концепции ин. терфейса, Т.е. то, что объявляет намерение пользователя и суммирует информацию, передаваемую от одно1'О действующе1'О лица дрУ1'ому. Авторы КНИ1'и Software for use посвятили ее часть именно этой теме, пользуясь термином важнейшие варианты использования (еssепtiаl use cases) д.ля обозначения системных вариантов исполь- зования уровня моря, описывающих концепцию интерфейса. Обычно все данные, передаваемые в одном направлении, собираются в одном ша1'е действия. Ниже приведены распространенный фра1'мент неправильно1'О описа. ния и способ e1'o исправления. Первоначальный вариант: 1. Система запрашивает имя. 2. Пользователь вводит имя. З. Система запрашивает адрес. 4. Пользователь вводит адрес. 5. Пользователь щелкает по кнопке "ОК" . 6. Система представляет параметры пользователя. 
Сценарии и шаrи 95 Исправленный вариант: 1. Пользователь вводит имя и адрес. 2. Система представляет параметры пользователя. Если передается более трех элементов данных, вы можете поместить каждый элемент в отдельной строке в табличном списке. Оба способа хороши, но первый pa ботает лучше, если вы впервые набрасываете варианты использования, поскольку ero можно быстрее написать и прочитать. Второй предпочтительней, если вы хотите обеспечить высокую точность для трассировки или тестирования. Допустимый вариант 1: 1. Пользователь вводит имя, адрес, номер телефона, конфиденциальную информацию, номер KOHTaKTHoro телефона для чрезвычайных ситуаций. Допустимый вариант 2: 1. Пользователь вводит:  имя  адрес  номер телефона  конфиденциальную информацию  номер KOHTaKTHoro телефона для чрезвычайных ситуаций Правило 6. Включайте "рациональный" набор действий Ивар Якобсон описал ша1' варианта использования как представление транзакции. Для этой формулировки он зафиксировал четыре части СЛОЖНО1'о взаимодействия (рис. 7.1): Наша сиcrема Запрос и данные @ Jc (". ПС7 Выдать результат (". Изменить '--.J РИС. 7.1. ЧетЬ/ре части транзакции 1. Основное действующее лицо посылает системе запрос и данные. 2. Система подтверждает запрос и данные. 3. Система изменяет внутреннее состояние. 4. Система выдает действующему лицу результат. 
96 r лава 7 Можно записать четыре части как отдельный ша1' действия или скомбинировать их различными способами, в том числе включив в один ша1' действия все четыре час ти. Как лучше  зависит от сложности каждой части и от To1'o, 1'де происходят eCTe ственные перерывы в процессе обработки. Вашему вниманию предла1'ается пять версий. Все они правильные, хотя версию 1 я считаю слишком сложной для восприятия. Мне нравится версия 2 с понятными ча стями, но я нахожу их слишком длинными для работы на этом этапе. Для данно1'О примера я предпочитаю версии 3, и 4. Пола1'аю, что ша1'И действия в версии 5 мелко- ваты, сценарий становится слишком длинным и тяжеловесным, но достоинство этой версии в том, что ша1'И являются отдельно тестируемыми единицами, а это может ПРИ1'одиться при более формальном подходе к разработке. Версия 1: 1. Клиент вводит номер заказа. Система обнаруживает, что он совпадает с выиrравшим номером месяца, реrистрирует пользователя и номер зака за как победителя этоrо месяца, посылает электронной почтой сообщение менеджеру по продажам, поздравляет клиента и выдает инструкцию, как получить приз. Версия 2: 1. Клиент вводит номер заказа. 2. Система обнаруживает, что он совпадает с выиrравшим номером меся ца, реrистрирует пользователя и номер заказа как победителя этоrо меся ца, посылает электронной почтой сообщение менеджеру по продажам, поздравляет клиента и выдает инструкцию, как получить приз. Версия 3: 1. Клиент вводит номер заказа. 2. Система обнаруживает, что он совпадает с выиrравшим номером месяца. З. Система реrистрирует пользователя и номер заказа как победителя этоrо месяца, посылает электронной почтой сообщение менеджеру по продажам, поздравляет клиента и выдает инструкцию, как получить приз. Версия 4: 1. Клиент вводит номер заказа. 2. Система обнаруживает, чтО он совпадает с выиrравшим номером месяца. З. Система реrистрирует пользователя и номер заказа как победителя этоrо месяца, посылает злектронной почтой сообщение менеджеру по продажам. 4. Система поздравляет клиента и выдает инструкцию, как получить приз. Версия 5: 1. Клиент вводит номер заказа. 2. Система обнаруживает, что он совпадает с выиrравшим номером месяца. З. Система реrистрирует пользователя и номер заказа как победителя этоrо месяца. 
Сценарии и шаrи 97 4. Система посылает электронной почтой сообщение менеджеру по про дажам. S. Система поздравляет клиента и выдает инструкцию, как получить приз. Правило 7. "Подтвердить", а не "Проверить" Одним из трех видов ша1'овдействия является подтверждение системой, что соблю дено некоторое бизнесправило. Часто пишут, что система проверяет условие. Это неудачный 1'ла1'ОЛ для действия. Он не отражает продвижение процесса вперед, не является на самом деле целью и не указывает явно, каков результат про верки. Вам ТОТчас же придется написать: "Если поверка прошла удачно..." и "Если проверка закончилась неудачей...". Применим метод "Спросить почему", чтобы найти более подходящее предложе ние. Почему система проверяет это условие? Ответ: чтобы установить, или пoд твердить, или обеспечить чтото. Эти rлаrолы лучше выражают действие д,r1Я достижения цели. Замените предложение "Система проверяет, правильный ли па оль" пред.ложением: Система подтверждает, что пароль правильный. Увидев слово если, вспомните это правило. Всякий раз, КО1'да вы видите "Если (условие)... TorAa...", ВЗ1'ляните на предыдущее предложение. Вероятно, e1'o сказу емое  проверяет. Замените в первом предложении проверяет на подтверждает и сделайте второе предложение простым описанием действия без если. Ниже пред ставлен пример до и после преобразования. Первоначальный вариант: 2. Система проверяет, правилен ли пароль. З. Если да, система представляет пользователю допустимые действия. Исправленный вариант: 2. Система подтверждает, что пароль правилен. З. Система представляет пользователю допустимые действия. Обратите внимание, что во втором случае сценарий описан как успешный. Он также побуждает читателя спросить на ша1'е 2, что произойдет, если пароль HeBep ный. Читатель обратится к соответствующему разделу расширения и найдет расши рение, начинающееся со слов Пароль неверен. Это придает варианту использования последовательный ритм, что облеrчает чтение и просмотр. Правило 8. В некоторых случаях вводите временные оrраничения Большинство ша1'ОВ следуют непосредственно из предыдущеrо. ИНО1'да приходится писать так: В любое время между З и 5 шаrами пользователь... или Как только пользователь..., система... 
98 r лава 1 Вставлять временные О1'раничения можно, но только КО1'да это необходимо. Обычно временные параметры очевидны, и нет необходимости их упоминать. Правило 9. Идиома: "Пользователь использует систему А ДЛЯ получения данных от системы В" Это ситуация, с которой вы можете столкнуться. Вы хотите, чтобы разрабатывае. мая система А получила информацию от системы В или как-то иначе осуществила с ней взаимодействие. Ей следует это делать, только КО1'да основное действующее лицо определяет, что настал нужный момент. Нельзя написать: "Пользователь на- жимает на кнопку "Получить", и в этот момент система получает данные от сис- темы В". ЭТО потребует описания деталей интерфейса. Можно использовать два ша1'а: 4. Пользователь дает системе сиrнал получить данные от системы В. 5. Система получает исходные данные от системы В. ЭТО приемлемо, однако 1'ромоздко и избыточно. Лучше написать так: 4. Пользователь применяет систему для получения исходных данных от системы В. с помощью ЭТО1'О небольшо1'О изменения мы показываем, что пользователь сам выбирает время, и мяч переходит от пользователя к системе А, затем к системе В. Кроме To1'o, мы определяем обязанности всех трех систем. Подробности инициирова- ния пользователем действия не определены, как и должно быть. Правило 10. Идиома: "Делать шаrи xy, пока не возникнет условие" ИНО1'да мы хотим отметить, что некоторые ша1'И MOryT повторяться. И опять нам по- везло, что мы пишем обычной прозой, а не пользуемся формализмами ПРО1'рамми"; рования. Просто напишите, что ша1' или ша1'И будут повторяться. . Если повторяется только один ша1', можно записать указание о повторении пря- мо в ша1'е: Пользователь выбирает один или более продуктов. Пользователь просматривает различные каталоrи товаров, пока не найдет тот, которым захочет воспользоваться. Если повторяется несколько ша1'ОВ, можно указать на повторение до или после повторяющихся ша1'ОВ. Я пишу о повторениях после ша1'ОВ, чтобы чуть облеrчить чтение сценария, но подойдет любой способ. 1. Клиент предоставляет учетный идентификатор либо имя и адрес. 2. Система спрашивает о предпочтениях клиента. 3. Пользователь выбирает товар для покупки, отмечает ero для покупки. 4. Система добавляет товар к тележке для покупок клиента. Клиент повторяет шаrи З4, пока не укажет, что выбор закончен. 5. Клиент покупает товары, находящиеся в тележке для покупок. 
Сценарии и шаrи 99 Заметьте, что нам не нужно нумеровать предложение о повторении, и нет необ ходимости в пред,тюжении, открывающем повторение. И то и дрyrое за1'ромождает описание. В варианте Делать ша1'И xy, пока не возникнет условие, ша1'И xy MOryт быть в любом порядке. Думаю, имеет смысл помещать условие перед соответствующими ша1'ами. 1. Клиент ВХОДИТ в систему. 2. Система представляет доступные продукты и услуrи. Шаrи З5 MorYT происходить в любом порядке. З. Пользователь выираетT продукты АЛЯ покупки. 4. Пользователь указывает предпочтительную форму оплаты. 5. Пользователь дает адрес АЛЯ доставки. 6. Пользователь указывает, что сделал все покупки. 7. Система инициирует заказ, причем выбранные ПРОДУКТЫ будут оплачены по выбранной форме оплаты и посланы по адресу назначения. Нумеровать или нет Номера выделяют ша1'И и позволяют ссылаться на них в разделе расширений. Oд нако их труднее подцерживать. Без хороших инструментов автоматической перену мерации при вставке или добавлении ша1'ОВ утомительно постоянно перенумеровывать ша1'И одно1'О и To1'o же варианта использования. Хорошие вари анты использования можно написать с нумерацией ша1'ОВ и без нее, поэтому этот вопрос надо решить д.nя проекта в целом. rруппы, в которых я работал, испытывали оба метода и последовательно выби рали нумерацию пред.nожений по всем абзацам, поэтому нумерованные пред.nожения стали д.nя меня стандартом. Дрyrие привыкли писать в форме простых абзацев и не думают переключаться. Я включаю шаблоны, как д.nя бессистемных, так и д.nя написанных по всей фор ме вариантов использования, чтобы подчеркнуть правомерность выбора. Абзацы являются выбором по умолчанию и в обычных шаблонах, и в шаблоне технОЛО1'ии Rational Unified Process (см. вариант использования 32). Если хотите, можете нумеровать ша1'И, как в этом варианте использования. Я почти все1'да приме няю нумерацию, даже если все остальное в варианте использования написано не по форме, поскольку считаю, что нумерация ПОМО1'ает исследовать поведение. Полная форма требует нумерации. 7.3. Упражнения Шаrи действия 7.1. Напишите сценарий одно1'О из ваших вариантов использования двумя способами: с подробным описанием интерфейса и с помощью описания намерений. Обсудите различия между сценариями. 
100 rлава 7 7.2. Напишите основной сценарий для варианта использования уровня задачи Извлечение дене1' с помощью режима Быстрое получение наличных. 7.3. Напишите основной сценарий для ОДНО1'о страте1'ическо1'О варианта использования и ОДНО1'о варианта использования уровня задачи для системы персонально1'О консультанта по финансам (PAF). 7.4. Молодой колле1'а прислал вам нижеследующий вариант использования. Учитывая изученный к настоящему моменту материал, пошлите ему в ответ критические замечания и исправления. Вариант испопьзования Войти в систему Этот вариант использования описывает процесс, с помощью KOToporo пользователи ВХОДЯТ в систему обработки заказов. В нем также устанавливаются права доступа для различных катеrорий пользователей. ПОТОК событий: Основной путь: 1. Вариант использования запускается, KorAa пользователь запускает приложение. 2. Система покажет экран для входа. З. Пользователь вводит имя и пароль. 4. Система проверит информацию. 5. Система установит права доступа. 6. Система покажет основной экран. 7. Пользователь выберет функцию. 8. Пока пользователь не выберет Выйти из цикла 9. Если пользователь выберет Разместить заказ, использовать Разместить заказ. 10. Если пользователь выберет Вернуть товар, использовать Вернуть товар. 11. Если пользователь выберет Снять заказ, использовать Снять заказ. 12. Если пользователь выберет Получить статус заказа, использовать Получить статус. 1 З. Если пользователь выберет Выслать каталоr, использовать Выслать кат алоr . 14. Если пользователь выберет Зареrистрировать жалобу, использовать Зареrистрировать жалобу. 15. Если пользователь выберет Выдать отчет по продажам, использовать Выдать отчет по продажам. Конец про верки если 16. Пользователь выберет функцию. Конец цикла 17. Вариант использования завершается. 
fлоsо 8 Расширения в вариант использования должны входить все сценарии, как успешные, так и при водящие к неудаче. Мы также обсудили, как писать основной сценарий. Теперь надо узнать, как добавить к нему все остальные. Можно написать каждый сценарий отдельно. Это СООтветствовало бы "полоса тым брюкам" (см. рис. 2.2). Этот подход время от времени пропа1'андируют, и HeKO торые инструменты подталкивают писателя идти этим путем. Однако сопровождение "полосатых брюк"  трудная задача (см. 1'лаву 2). Каждое изменение в сценарии должно быть скопировано во все остальные сценарии, содержащие тот же текст. Второй способ  вставлять предложения с если на протяжении Bce1'o текста: "Если пароль верный, система делает так..., в противном случае этак...... Это аб солютно законно, некоторые так и пишут. Но читателям приходится неле1'КО с этими если, особенно КО1'да одно предложение с если находится внутри дру1'О1'О. Читатели теряют нить уже после двух веток с если, а большинство вариантов использования имеют MHo1'o точек ветвления. Третий способ создать этот текст  написать основной сценарий как простую последовательность действий от запуска до завершения, а затем написать расшире н-ие сценария для каждой точки ветвления. Это, пожалуй, лучший из трех способов. 8.1. Расширение. Основн&/е положения Расширения работают так. Вслед за основным сценарием для каждой точки, в KOTO рой поведение может идти по различным сценариям вследствие определенно1'О условия, запиШите это условие, а потом управляющие им ша1'И. Часто расширение заканчивается воссоединением с основным сценарием. Расширение на самом деле  это спуск вниз по варианту использования. Оно за пускается при возникновении условия, которое делает e1'o релевантным. Оно coдep жит последовательность ша1'ОВ действия, описывающих, что происходит при этом условии, и заканчивается достижением цели или отказом от нее. По пути MOryт BCTpe титься и расширения к расширениям, обрабатывающие предложения с если и но. 
102 rлава 8 Эти расширения возникают там, 1'де находятся наиболее интересные требования к системе. Основной сценарий разработчикам часто известен. При обработке OTKa зов нередко используются бизнесправила, которые разработчики не знают. Авторам описания требований приходится выяснять правильные реакции системы, и довольно часто при таком исследовании вводится новое действующее лицо, новый вариант ис пользования или новое условие расширения. Ниже приведена типичная дискуссия, иллюстрирующая это утверждение. "Предположим, что сеть неожиданно отказала. Что мы делаем?" "Система ре1'истрирует это". "Принято. Но если сеть прекратила работать, что будет, КО1'да она зара ботает снова?" "Мы должны добавить новый вариант использования для повторно1'О за пуска системы после отказа сети. Система восстановится, откроет жур нал и либо завершит транзакцию, либо ее отменит". "Но что если журнал будет поврежден? Что ТО1'да будет делать система?" "Не знаю. Давайте запишем это как открытый вопрос и продолжим". В этом диаЛО1'е обнаруживается новый вариант использования, а также необхо дим ость исследовать страте1'ИЮ бизнеса. Не обманывайте себя, пола1'ая, что не нуж но обсуждать эти расширения. Какойнибудь ПРО1'раммист в проекте, разрабатывая ПРО1'рамму, натолкнется на те же условия, и очень дорО1'ое время будет потрачено на открытие и изучение новых бизнесправил. Лучше Bce1'o этим заниматься на этапе сбора требований к системе. Рекомендую ОР1'анизовать работу в три этапа: 1. Хорошо поразмыслите и включите каждую возможность, которую вы только можете вообразить. 2. Оцените, исключите и объедините идеи в соответствии справилами, изложенными в разделе 8.2. 3. Продумайте, как пробраться через все эти системные обработки условий. 8.2. Условия расширения Условия расширения  это условия, при которых изменяется поведение системы. Мы 1'оворим расширение в противоположность неудаче или исключительной ситуа- ции, чтобы наряду с условиями неудачи включить альтернативный сценарий успеха. Здесь представлены два фра1'мента, иллюстрирующие путь успеха и путь неуда- чи в расширениях. Пример 1 4. Пользователь дает системе команду сохранить наработанное на текущий момент. 
Расширения 103 Расwирения 4а. Система автоматически обнаруживает необходимость немедленноrо сохранения: 4а1. ... 4Ь. Сохранение завершается неудачен: 4Ы. ... Вышеприведенный пример можно истолковать так: вместо To1'o чтобы сохранить текущее состояние данных по требованию пользователя, система может автоматиче ски обнаружить необходимость немеЩIенно1'О сохранения. В этом случае ... (чтото делается). Сохранение (по требованию пользователя или автоматическое) может за  кончиться неудачно. В этом случае ... (делается чтото еще). Пример 2 З. Система сканирует документ, сверяя правописание каждоrо слова со словарем. 4. Система обнаруживает орфоrрафическую ошибку, выделяет слово и предоставляет на выбор пользователю альтернативы. 5. Пользователь выбирает одну из замен. Система замещает выделенное слово друrим, выбранным пользователем для замены. Расширения 4а. Система не обнаруживает больше орфоrрафических ошибок до конца документа: 4а1. Система уведомляет пользователя и завершает выполнение варианта использования. 5а. Пользователь решает сохранить первоначальное написание: 5а 1. Система оставляет слово и продолжает работу. 5Ь. Пользователь набирает новое написание, не входящее в список: 5Ь1. Система проверяет новое написание и возвращается на шаr З. Выявляйте все возможные ошибки н альтернативные пути Очень важно максимально охватить условия расширения, прежде чем писать, как их обрабатывать. Это утомительная работа, как и документирование обработки расширений. На то, чтобы продумать только одно расширение и сделать правиль ные выводы о работе системы, уходит MHo1'o сил, не 1'оворя уже о 3-4 расширениях. Это значит, что вы не будете обдумывать следующую порцию условий расширения. А это следует сделать. Если вы выявите все альтернативные ситуации успехов и неудач, у вас будет список, который послужит основой ЩIЯ вашей дальнейшей работы в течение неско- 
104 r лава 8 льких часов или дней. Вы можете Сделать перерыв и вернуться к тому месту, 1'де за- кончили. Выявите все возможные пути, которые приводят к неудачному завершению сце- нария, и альтернативные пути, ведущие к успеху. Убедитесь, что не пропустили ни один из них: . Альтернативный путь к успеху (служащий использует клавишу быстроrо вызова). . Основное действующее лицо действует некорректно (неверный пароль). . Бездействие OCHOBH01'O действующе1'О лица (истечение времени ожидания пароля). . Каждое появление пред.lIожения "система подтверждает" означает, что последует расширение, обрабатывающее неподтверждение (неверный учетный номер). . Несоответствующая реакция второстепенно1'О действующе1'О лица или ее отсутствие (истечение времени ожидания ответа). . Внутренняя ошибка в разрабатываемой системе, которая должна быть обнаружена и обработана в обычном порядке (заблокирован автомат для выдачи наличных). . Неожиданная и необычная ошибка, которую необходимо обработать, и которая будет иметь видимый результат (обнаружено повреждение журнала транзакций). . Критически важные недостатки в производительности системы, которые вы должны обнаружить (время реакции не укладывается в 5 с). Часто люди анализируют ша1'И от начала сценария до e1'o конца, чтобы 1'аранти' ровать максимальный охват всех условий. Если вы поступите так же, количество ве. щей, которые MOryт выйти из строя, удивит вас. Упражнение 8.1 даст вам возможность попытаться выявить ряд ошибок. Ответ вы найдете в приложении В. Двое учащихся Moe1'o курса назвали почти в три раза больше ошибок, чем дано в от. вете. Насколько преуспеете вы? Правнпо 11. Пусть условие само указывает I что было обнаружено Запишите, что обнаружила система, а не просто, что произошло. Не пишите: "Кли- ент забывает PINKOA". Система не может обнаружить это. Возможно, клиент ушел, с ним случился сердечный приступ или он успокаивает плачуще1'О младенца. Система в этом случае обнаруживает бездействие, что означает превышение вре- MeHHo1'o предела. Напишите: "Предел ожидания ввода PINKoAa превышен" или "Истекло время ожидания PINKOAa". Условием часто служит выражение, описывающее то, что было обнаружено. Мне нравится ставить двоеточие (:) в конце условия, чтобы читатель не принимал 
Расширения 105 условие за ша1' действия. Это СО1'лашение предотвращает MH01'o ошибок. Вот HeCKO лько примеров: Неверный PINKOA: Сеть не работает: Клиент не отвечает (время ожидания ответа истекло): Деньrи не выдаются надлежащим образом: Если вы используете нумерованные шаrи, напишите номер ша1'а, 1'де может быть обнаружено условие, и сопроводите номер буквой (скажем, 4а). Буквы не свя заны какойлибо последовательностью, поэтому условие 4Ь не обязательно должно следовать за 4а. Это позволяет присоединить сколько У1'одно условий расширения к любому шаry действия. 2а. Недостаточно финансовых средств: 2Ь. Сеть не работает: Если условие может возникнуть на нескольких ша1'ах и вам представляется важ ным указать на это, перечислите эти ша1'И: 25a. Пользователь неожиданно прекратил работу: Если условие может возникнуть в любое время, используйте знак звездочки (*) вместо номера ша1'а. Сначала перечисляйте условия со звездочкой, затем HYMepo ванные. *а. Сеть перестает работать: *Ь. Пользователь ушел без уведомления (время ожидания ответа истекло): 2а. Недостаточно финансовых средств: 2Ь. Сеть не работает: Не беспокойтесь о том, в каком участке происходит ошибка: на ша1'е ввода поль зователем данных или на следующем, 1'де система подтверждает данные. Некоторые утверждают, что ошибка возникает в любом месте, но на этот довод не стоит тратить время. Обычно я связываю ошибки с ша1'ОМ подтверждения, если таковой присутствует. КО1'да вы пишете обычными абзацами без нумерации ша1'ОВ, вы не можете обра щаться к определенному шаry, в котором возникает условие. Поэтому сделайте усло вие на1'ЛЯДНЫМ, чтобы читатель знал, КО1'да оно может возникнуть. Перед каждым условием про пустите строку или сделайте пробел и вьщелите условие, например курсивом (см. вариант использования 32). . Невымыwnенная нсrорня KorAaTo я участвовал в работе над серьезным проектом. К сожалению, мы не слишком тщательно продумали расширения. Подобно мноrим разработчикам, мы не захотели рассматривать, что слу чится, если nporpaMMa натолкнется в базе данных на неверную информа 
106 r лава 8 ЦИIO. Каждый из нас надеялся, что друrая команда позаботится об этом. &, AoraAbIBaeTecb, что произошл01 Через неделю после первой сдачи первон очереди проекта вицепрезидент решил посмотреть, как один из ero заказ- чиков использует новые способы продвижения товара. Он запустил свою новенькую систему и запросил данные по этому крупному заказчику. Снс- тема ответила, что данные не наидены. Ero состояние трудно было описать. Высшее звено персонала в полном составе было собрано на экстренное совещание, чтобы решить, что делать с ошибками в базе данных. Мы об- наружили, что в базе была только одна неверная секция, поэтому сооб- щение об ошибке должно было быть таким: "Некоторые данные пропущены". Хуже было Apyroe  мы упустили из вида, что реакция снс- темы при обнаружении неверных внутренних данных на самом деле есть часть внешних требовании к неи. Мы переделали проект системы, чтобы она оптимально справлялась с не- полными данными и выдавала как наилучшие возможные результаты, так и сообщение о том, что некоторые данные пропущены. Вывод из этои истории состоит В том, что необходимо рассматривать внут- ренние ошибки, такие как пропущенные данные. о списке выявпенных успави" Ваш список выявленных условий будет содержать больше идей, чем вы будете в ко. нечном счете использовать, и это нормально. Смысл упражнения в том, чтобы по- пытаться охватить все ситуации, которые КО1'далибо встретит система в этом варианте использования. Позже вы сократите список. В этой точке ваш список, вероятно, еще не полон. Вы, возможно, думаете о но. вом условии ошибки, КО1'да пишете сценарий расширения или добавляете новый шаr подтверения 1'дето внутри варианта использования. Не беспокойтесь об этом. Тщательно выполняйте работу на этой стадии анализа и пополняйте список в про. цессе работы. Совершенствуйте список расширений Цель совершенствования  сделать список расширений максимально коротким. Идеальный список условий расширения показывает все ситуации, которые система должна обрабатывать. Помните, что длинный документ, содержащий требования к системе, все1'да тяжело читается, а избыточные описания сложно сопровоать. Объединяя условия расширения, вы сокращаете документ и время e1'o чтения. Проведя тщательный анализ, вы должны получить короткий и простой основной сценарий и длинный список условий, которые предстоит рассмотреть. Внимательно просмотрите список, удаляя те условия, которыми система не должна управлять, и объединяя те, которые оказывают на систему одинаковое результирующее воздейст- вие. Используйте два критерия: . Система должна быть способна обнаруживать это условие. . Система должна обрабатывать обнаружение условия. 
Расширения 107 Попробуйте сделать необнаруживаемые условия обнаруживаемыми, прежде чем их удалять. Удалите условие "Клиент забыл карточку для банкомата", посколь ку не существует эквивалентно1'О условия, которое система способна обнаружить. Преобразуйте необнаруживаемое условие "Клиент забыл PINKOA" В условие "Ис текло время ожидания ввода PINKOAa", которое система сможет определить. Затем объедините эквивалентные условия. Вы МО1'ли бы написать, что карточка поцарапана, считывающее устройство неисправно, карточка не является карточкой ДЛЯ банкомата. С точки зрения требований поведение банкомата будет одинаковым: "Возвратить карточку и уведомить клиента". Поэтому попробуйте объединить эти условия. Постарайтесь найти одно осмысленное пред.nожение д.nя всех, можно по строить распространенное пред.nожение: "Карточка не читается или предназначена не для банкомата". Свертывайте ошибки Как часть объединения условий, производящих одинаковое воздействие, объединя  ют ошибки вариантов использования более низко1'О уровня, имеющие одинаковый результирующий эффект на вариант использования более BbfcoKOro уровня. Это свертывание ошибок более низко1'О уровня дает возможность избежать лавины условий расширения на более высоких уровнях. Предположим, что вы работаете над пакетом PAF и пишете вариант использова иия уровня цели Обновить инвестиции. Пусть один из последних ша1'ОВ таков: Вариант испопьэования Обновить инвестиции 7. Пользователь дает команду PAF сохранить текущее состояние данных. 8. ... Это обращение вызывает вариант использования Сохранить текущее состояние данных, который содержит условия TaKo1'o рода: Вариант испопьэования Сохранить текущее состояние данных Расширения: За. Файл уже существует (пользователь не желает ero перезаписывать): ЗЬ. Директория не нандена: ... 4а. Не хватает места на диске: 4Ь. Фанл защищен от записи: ... и т.д. '" 
108 r лава 8 Вариант использования Сохранить текущее состояние данных завершается успехом либо неудачей, возвращающей выполнение в конец ша1'а 7 варианта ис- пользования Обновить инвестиции. В случае успеха выполнение продолжается с ша1'а 8. Но что если сохранение заканчивается неудачей? Что нужно написать в рас- ширении 7а? Читателя варианта использования Обновить инвестиции не интересует, почему сохранение не удалось (все неудачи имеют один и тот же результирующий эф. фект), поэтому в вариант использования Обновить инвестиции включите только одно расширение, описывающее, что произошло. Вариант испопьзования Обновить инвестиции 7. Пользователь дает команду Р AF сохранить текущее состояние данных. 8. ... Расwирения: 7а. Сохранение произвести не удалось: 7 а 1. ... все, что должно произойти потом... Лучше Bce1'O в свертывании ошибок то, что даже на самом высоком уровне вари. анта использования терминоло1'ИЯ сообщений об ошибках соответствует этому уров' ню. Даже занятые руководнтели найдут время прочитать их, потому что сообщения варианте использования очень BbfcOKo1'o уровня тоже вполне BbfcoKo1'o уровня. 8.3. Обработка расширений В простейшем случае условие обрабатывает базовая последовательность шаrов. Однако обычно расширение представляет собой миниатюрный вариант использо,' вания. ТРИ1'1'ером служит условие расширения; цель достичь цели варианта ис. пользования либо возобновить выполнение после произошедшей ошибки. Тело является набором ша1'ОВ действия и, может быть, их расширениями. Расширение может завершаться достижением цели или отказом от нее, совсем как в варианте: использования. Сходство не случайно, и это очень удобно с точки зрения рациона. льной формы описания сложных расширений. , Начинайте описывать обработку условия с ша1'а действия, который следует за: обнаруживаемым условием. Нет необходимости повторять, что было обнаружено! условие. Продолжайте повествование точно так же, как и при создании OCHoBHorol сценария, соблюдая все правила для уровня цели, стиля и предложений, которыеl мы рассматривали ранее. Пишите, пока не ДОСТИ1'нете места, rде можно воссоеди. i ниться с основным сценарием, или пока вариант использования не закончится неу' дачей. Обычно фра1'мент сценария завершается одним из следующих способов: Ша1', порождающий расширение, зафиксирован и заменен. В конце обработки: расширения положение таково, как если бы ша1' был успешным. I 
Расширения 109 З. Пользователь активизирует URL wеЬсайта. 4. ... Расширения: За.Нет AocTYnHoro URL: За 1. Пользователь ищет wеЬсайт. ЗЬ. ... Система предоставляет действующему лицу еще один шанс. В конце обработки расширения действие возвращается в начало To1'o же ша1'а. В следующем при мере обратите внимание, что система повторно подтверждает пароль: З. Пользователь вводит пароль. 4. Система подтверждает пароль. 5. ... Расширения: 4а. Неверный пароль: 4а1. Система уведомляет пользователя, снова запрашивает пароль. 4а2. Пользователь повторно вводит пароль. 4Ь. ... Вариант использования завершается ввищ ПОЛНО1'о отказа. З. Пользователь вводит пароль. 4. Система подтверждает пароль. 5. ... Расширения: ... 4с. Превышен предел попыток ввода пароля: 4с1. Система уведомляет пользователя, прекращает сеанс. 5а. ... Чтобы ДОСТИ1'нуть цели, действие развивается по совершенно дрУ1'ому пути. З. Пользователь делает... 4. Пользователь делает... 5. ... Расширения: За. Пользователь запускает персональную макрокоманду, чтобы завершить процесс: За1. Вариант использования завершается. В двух первых вариантах использования не нужно указывать, что происходит по том в расширении, так как для читателя очевидно, что этот ша1' будет запущен снова или продолжен. В последних двух случаях достаточно сказать о неудаче или о завер шении варианта использования, поскольку шаrи показывают, что интересы участни ков соблюдены. В большинстве расширений не 1'оворится о том, по какому пути пойдет действие по окончании расширения. Обычно это очевидно, а если писать после каждо1'О pac 
110 rлава 8 ширения "Перейти к шаry N", текст будет пере1'ружен, что плохо для читателя. В редких случаях, КО1'да не ясно, что действие переПРЫ1'ивает на ДРУ1'ой участок основ. Ho1'o сценария, в конечном ша1'е можно записать: "Перейти к шаry N". Примеры каждой из таких ситуаций можно найти в этой книrе в различных об- разцах вариантов использования. ПР8ВНnО 11. Делайте отступы в тексте обработки условия Используя стиль с нумерацией, демонстрируемый в этой КНИ1'е, делайте отступы для ша1'ОВ действия, которые указывают, как обрабатывается условие, и начинайте повторную нумерацию с 1 после буквы. Ша1'И действия следуют всем ранее описан. ным правилам стиля. Расширения: 2а. Недостаточно финансовых средств: 2а1. Система уведомляет клиента, предлаrает ввести друrую сумму. 2а2. Клиент вводит новую сумму. Перед сдачей этой кни1'И в печать Волкер Хеймер из компании Software Futures ССН описал СО1'лашение, упрощающее нумерацию. Разработчики e1'o фирмы опус. кают лидирующую комбинацию номер-буква, начиная непосредственно с точки, за которой следует номер. Приведенный выше пример будет ВЫ1'лядеть так: 2а. Недостаточно финансовых средств: .1. Система уведомляет клиента, предлаrает ввести друrую сумму. .2. Клиент вводит новую сумму. Преимущество это1'о способа в том, что при изменении нумерации, Например, Kor. да ша1' 2 станет ша1'ОМ 3, пере нумеровать ша1'И расширения значительно проще. Если вы пишете без нумерации, делайте отступы либо начинайте каждый ша1' действия с аб- заца. Шаблон Rаtiопаl Uпifiеd Process имеет специальный уровень за1'ОЛОВка для усло- вия расширения, причем шаrи действия записываются как текст под этим за1'ОЛОВКОМ. Ошибки внутри ошибок Внутри фра1'мента сценария обработки расширения вы можете встретить новое условие ветвления, возможно, ошибку. Если вы придерживаетесь стиля формати' рования с отступами, как в данной КНИ1'е, сделайте еще один отступ и продолжайте называть условия и писать сценарий, как прежде. В какой-то точке отступы и нуме- рация станут такими сложными, что вы решите превратить все расширение в еще один вариант использования. Большинство моих корреспондентов 1'оворят, что это случается примерно на третьем уровне отступов. Ниже приведен пример, взятый из варианта использования 22. 6а. Служащий решает выйти, не получив минимума информации: 6а1. Система предупреждает служащеrо, что он не может выйти и закрыть форму без даты, имени или номера полиса или записи имени оценщика. 
Расширения 111 6а1а. Служащий решает продолжить ввод данных по ущербу. 6а1Ь. Служащий сохраняет "промежуточный" отчет и выходит из системы. 6а1с. Служащий настаивает на выходе без записи минимума информации: Система oTBepraeT сохранение любых промежуточных версий и завершает выполнение. Обратите внимание, что в этом примере разработчик не присвоил номер послед ней строке. На номере ба 1 с 1 он решил, что расширение уже порядком за1'ромождено и короткий фра1'мент просто1'О текста сделает чтение более удобным. Вообще стоимость создания HOBo1'o варианта использования достаточно высока, чтобы слишком дол1'О не выделять расширение в самостоятельный вариант исполь З0вания. Компромиссное решение состоит в том, что вышеприведенный пример cy ществует, пока имеет смысл делать отступ, не выделяя e1'o в самостоятельный вариант использования. СО3Аание из расширения HOBoro варианта использования Чтобы выделить расширение в новый подчиненный вариант использования, опре делите цель OCHoBHo1'o действующе1'О лица и соответственно назовите вариант ис пользования, обозначьте e1'o уровень (возможно, подфункция ), откройте шаблон для HOBo1'o варианта использования и запишите детали, которые вы перетащили из вызывающе1'О варианта использования. Возьмем для примера вариант использования 32. Он КО1'дато содержал ша1': Пользователь может сохранить или распечатать отчет в любой момент. В нем есть ряд расширений, описывающих альтернативы и ситуации отказов, но их число постоянно росло: непоименованный отчет, уже существующее имя (за менять или не заменять), пользователь прекращает сохранение на середине, и Т.д. Наконец, разработчики решили выделить Сохранить отчет в отдельный вари ант использования. В первоначальном варианте использования вы тем не менее должны учитывать, что новый подчиненный вариант использования может закончиться неудачей, поэто му ваш вариант, вероятно, будет включать условия как успеха, так и неудачи. С точки зрения теории и затраченных усилий перемещать расширение в caMO стоятельный вариант использования и обратно достаточно просто. Модель варианта использования обеспечивает ле1'кое решение. Переместить расширения Сохранить отчет из Управления отчетами не составляет труда, а чтобы вернуть их назад, нужно несколько минут работы в текстовом редакторе. Однако создание варианта использования не О1'раничивается механическими усилиями. Новый вариант использования требуется помечать, отслеживать, плани ровать, тестировать и сопровождать. Для проектной 1'руппы это недешевые опера  ции. 
112 rлава 8 Вообще сохранение расширения внутри варианта использования определяется в основном экономическими соображениями. Две ситуации MOryT побудить вас создать новый вариант использования для расширения: . Расширение используется в нескольких местах. Выделение e1'o в собствен- ный вариант использования означает, что отслеживать и сопровождать e1'o можно будет только в одном месте. В идеальном случае это вообще единствен- ная причина для создания варианта использования, уровень KOTopo1'o ниже уровня моря. . Расширение делает вариант использования трудным для чтения. Я счи- таю, что предел читабельности  около двух страниц текста варианта исполь- зования и три уровня отступов. (ои варианты использования в основном короче, чем у ДРУ1'их, поэтому ваша страница может быть длиннее.) 8.4. Упражнения Расширения 8.1. Перечислите то, что может отказать во время функционирования банкомата. 8.2. Перечислите то, что может отказать в первом варианте использования уровня цели пользователя для системы обработки расширений PAF, персонально1'О консультанта по финансам (см. упражнение 4.4). 8.3. Напишите вариант использования Извлечь наличные, содержащий обработку ошибок с помощью предложений с если. Напишите e1'o снова, на этот раз с расширениями сценария. Сравните два варианта. 8.4. Найдите файл требований, написанный в форме, отличной от вариантов использования. Как он учитывает условия ошибок? Что вам нравится в каждом методе разработки, что полезно1'О можно извлечь из этих наблюдений? 8.5. Напишите полный вариант использования для системы PAF, описывая ша1'И обработки ошибок (система PAF упоминается в упражнении 4.4). 
rлово 9 И з.менения в теХНОЛО2UU и данных Расширения 1'оворят о том, что система выполняет действия поразному. То, что происходит, не меняется, но MOryT меняться способы выполнения действий. Почти все1'да это объясняется какиминибудь изменениями в техноло1'ИИ или различиями в данных, которые необходимо зафиксировать. Записывайте это в список измене ний техноло1'ИИ и данных, а не в раздел расширений. Прuмер J Ваша система должна кредитовать заказчика за возвращенные товары. Вы запи сываете этот ша1' действия: 7. Вернуть заказчику деньrи за возвращенные товары. Уплатить заказчику можно с.помощью чека, компьютерной системы электрон ных платежей или кредита на следующую покупку. Таким образом, вы добавляете Список изменений в техноnorии и AaHHltIX: 7а. Вернуть заказчику деньrи с помощью чека, компьютерной системы электронных платежей или кредита на будущие покупки. Пример 2 Вы детально описываете новый банкомат. Техноло1'ИЯ усовершенствована до Ta кой степени, что клиенты MOryт быть идентифицированы по банковской карточке, радужной оболочке 1'лаза или отпечаткам пальцев. Вы записываете: Основной сценарий: 2. Пользователь идентифицирует себя, банк и номер счета. 
114 rлава 9 СПИСОК изменении в технопоrии и данных: 2а. Использовать маrнитную банковскую карточку, сканирование радужной оболочки rлаза или отпечатки пальцев. Эти пункты изменений не являются расширениями для данно1'О варианта испо льзования. Каждый развертывается в собственное расширение на KaKOMTO более низком уровне это1'о варианта использования, который вы, возможно, НИКО1'да не Ha пишете. Каждое изменение оказывает заметное влияние на смету и план работ, поэ тому изменения надо фиксировать и отслеживать. Вы ре1'истрируете возможности с помощью списка изменений в техноло1'ИИ и данных. В списке изменений нет ша1'ОВ действий. Записывать туда условия и ша1'И дейст вия некорректно. Список изменений в техноло1'ИИ и данных содержится в варианте использова- ния 13. Если вы решили применить UМLдиа1'раммы вариантов использования, создай те пустой обобщенный базовый вариант использования для OCHoBHo1'o ша1'а и специ ализированный вариант использования для каждо1'О изменения. Пустой обобщенный базовый вариант использования указывает на "что", но не 1'оворит "как". В каждом специализированном варианте использования определяются e1'o собственные ша1'И, раскрывающие, как это делается. Нотация UML объясняется в приложении А. На рис. 9.1 представлен пример нотации. Вернуть заказчику деньrи за возвращенные товары Вернуть чеком Вернуть кредитом на будущие покупки Рис. 9.1. Изменения в технолоrии, показанные в нотации UML с помощью специализации 
rлово 10 Связыванuе вариантов использования 10.1. Подчиненные варианты использования Ша1' действия может быть простым ша1'ОМ или названием дрУ1'О1'о варианта исполь зования. Предложение: Пользователь сохраняет отчет без выделения или аннотации означает простой, элементарный ша1'. Любой из ша1'ОВ: Пользователь сохраняет отчет Пользователь сохраняет отчет (UC З5 Сохранить отчет) указывает на вариант использования, называемый Сохранить отчет. Это HaCTO лько естественно, что едва ли требуется дополнительное объяснение. Даже случай  ные читатели вариантов использования понимают, что подчеркнутое (обычно 1'иперссылка) или выделенное курсивом действие означает, что вызывается дpy 1'ой вариант использования, который расширяет указанное действие.' Удобно пи сать варианты использования, при необходимости свертывая или развертывая действие. Научиться этому недол1'О, а описание получается компактным. * в терминах UМLдру1'ОЙ вариант использования называется включаемым (iпс luded). Я считаю, что начинающим писателям и неопытным читателям будет понятнее, если сказать, что один вариант использования обращается к дрУ1'ому или вызывает дрyrой. Выбор термина  дело ваше. 
116 rлава 10 10.2. варианты использования расширений ИНО1'да необходим ДРУ1'ой вид связи между вариантами использования, KOTO рый хорошо СО1'ласуется с механизмом расширения. Рассмотрим следующий пример. Вы разрабатываете новую ПРО1'рамму обработки текста, названную Wapp. Основная деятельность пользователя  набор текста. Однако он может из менить масштаб изображения или размер шрифта, запустить ПРО1'рамму проверки ОРфО1'рафии или сделать еще чтонибудь из To1'o, что с набором непосредственно не связано. Вы хотите, чтобы никакие события, происхо дящие с документом, не касались набора текста. Вы также хотите, чтобы различные команды разработчиков ПРО1'раммно1'О обеспечения придумывали новые УСЛУ1'и, не переделывая основной вариант использования для каждой новой возможности. Вы хотите расширить набор требований, избежав проблем. Ситуация характеризуется следующим образом: . Имеется основная деятельность, которую можно прервать. . Основная деятельность может быть прервана рядом способов и не управляется прерываниями. Это не то же самое, что основное меню, перечисляющее услу1'И системы пользо вателю на выбор. Основным меню управляет выбор пользователя, Torдa как в нашем примере основная деятельность не контролируется, а только прерывается ДРУ1'ими действиями. Вы не хотите, чтобы основной вариант использования в этом примере явно Ha зывал все прерывающие варианты использования. Иначе сопровождение станет Ha стоящей 1'оловной болью, поскольку 1'руппе разработчиков, добавляющей новый прерывающий вариант использования, придется редактировать основной вариант использования. А это может привести к повреждению последне1'О или размножению e1'o версий, необходимости просмотра и Т.д. Применяйте тот же механизм, что описан для расширений сценария, но созда вайте новый вариант использования, который называется вариантом использова ния расширения (ехtепsiоп use case) и подобен расширению сценария, за исключением To1'o, что он самостоятелен. Как и расширение сценария, он начинается с условия, которое обращается к ситуации OCHoBHo1'o варианта использования, 1'де может возникнуть условие. Поместите все это в раздел шаблона ТРИ1'1'ер. Ниже приведено несколько отрывков для TeKCTOB01'O процессора Wapp. На рис. 10.1 отображена ситуация с Wapp в виде UМLдиа1'раммы. С помощью особо1'О стиля коннектора, крючка, я показываю, как вариант использования расширяет дpy 1'ой (или цепляется к дру1'ОМУ). Подробности см. в приложении А. 
Связывание вариантов использования 117 Редактировать документ Проверить орфоrрафию Изменить шаблон Найти синоним РИС. 10.1. UМLдиаrрамма вариантов использования расширения Вар нант нспопьзовання Редактнровать доку мент Основное действующее пицо: пользователь Обпасть действия: Wapp Уровень: цель пользователя Триrrер: пользователь открывает приложение. Предусповие: отсутствует. Основной сценарий: 1. Пользователь открывает документ для редактирования. 2. Пользователь вводит и модифицирует текст. ... Пользователь сохраняет документ и выходит из приложения. Варнант нспопьзовання Провернть орфоrрафню Основное действующее пицо: пользователь Обпасть действия: Wapp Уровень: подфункция! Предусповие: доку мент открыт. Триrrер: любой момент при выполнении варианта использования Редактировать документ, KorAa документ открыт, и пользователь решает запустить nporpaMMY проверки орфоrрафии. Основной сценарий успеха: ... и Т.д. ... 
118 rлава 10 Вариант испопьзования Нанти синоним Основное действующее пицо: пользователь Обпасть действия: Wapp Уровень: подфункция! Предусповие: доку мент открыт. Триrrер: любой момент при выполнении варианта использования Редактировать документ, KorAa курсор стоит на слове и пользователь решает запустить тезаурус. Основной сценарий успеха: ... и Т.д. ... Вариант испопьзования Изменить wабпон документа Основное действующее пицо: пользователь Обпасть действия: Wapp Уровень: подфункция! Предусповие: документ открыт. Триrrер: любой момент при выполнении варианта использования Редактировать документ, KorAa документ открыт и пользователь выбирает эту функцию. Основной сценарий: ... и т.д. ... KorAa применять варианты использования расширения Создавайте варианты использования расширения, только КО1'да это необходимо, так как их труднее пони мать И поддерживать. В двух ситуациях их создание оправдано. Наиболее распространенная ситуация  КО1'да пользователь может применить MHo1'o асинхронных или прерывающих выполнение услу1', которые не должны мешать основному варианту использования. Часто эти УСЛУ1'и разрабатываются разными командами и проявляют себя при работе с "коробочным" ПРО1'раммным продуктом, таким как текстовый редактор. ДРУ1'ая ситуация  КО1'да вы пишете дополнения к документу, изла1'ающему за фиксированное описание требований. Сьюзен Лилли из S.R.A. написала мне: Вы работаете над проектом с итеративным процессом и множественными проходами. У вас есть базовые требования для ОДНО1'о прохода. В следую щем проходе вы расширяете основной вариант использования, добавляя новые функции. Вы не Tpo1'aeTe основной вариант использования. Если основной вариант использования не зафиксирован, расширение будет pa ботать ненадежно. Изменения в основном варианте использования MOryт нарушить 
Связывание вариантов использования 119 условие расширяюще1'О варианта использования, поэтому остере1'айтесь вариантов использования в таких случаях. Упражнение 10.2 дает вам возможность поэкспери ментировать с вариантами использования расширения это1'О рода. Алан Уильямс изложил правило, ПОМО1'ающее решить, должен ли вариант испо ЛЬ30вания вызывать подчиненный вариант использования или подчиненный вариант использования должен расширять основной: Если ТРИ1'1'ер включает аспекты, за которые отвечает основной вариант ис пользования (т.е. основной вариант использования знает, КО1'да, или 1'де, или почему должен выполняться второй вариант использования), значит основной вариант использования ВКЛючает (вызывает) ДРУ1'ой или обраща  ется к дрУ1'ому. Если триrrер ВКЛючает аспекты, за которые отвечает подчиненный вариант использования (т.е. подчиненный вариант использования знает КО1'да, или 1'де, или почему он должен последовать), подчиненный вариант использова  ния расширяет основной вариант использования. Обратите внимание, чтО КО1'да основной вариант использования вызывает под чиненный вариант использования, основной называет e1'o, 1'оворя, КО1'да и 1'де он BЫ ПOJlняется. Вариант использования, к которому происходит обращение, не содержит названия OCHoBHo1'o варианта использования. КО1'да подчиненный вариант использо вания расширяет основной, последний не называет имени или на самом деле НИче1'О не знает о расширяющем (прерывающем) варианте использования. Расширяющий вариант использования называет вариант использования, который он прерывает, и определяет среду, в которой он выполняется. 10.3. Упражнения Связывание вариантов использования 1 О .1. Найдите условие в варианте использования уровня цели пользователя для системы PAF (описанной в упражнении 4.4), которое требует выделения подчиненно1'О варианта использования. Напишите этот подчиненный вариант использования и установите с ним связь из варианта использования уровня цели пользователя, уделяя внимание как e1'o успеху, так инеудаче. 10.2. Рассмотрите ситуацию с АТМ, КО1'да вы находитесь не в своем родном банке, а в дрУ1'ом. Напишите подчиненный вариант использования для запроса наличных "банк/банк" и свяжите e1'o с предыдущим вариантом (вариантами) использования, описывающими получением наличных. Сделайте это двумя способами: в виде подчиненно1'О варианта использования, к которому обращается ваш основной вариант использования, и в виде варианта использования расширения. Обсудите с колле1'ами, какой способ лучше и почему. 
rлава 11 Фор:матЬt вариантов использованuя 11.1. Разновидности форматов Полный формат Большая часть примеров в этой КНИ1'е представлена в моем любимом стиле, Т.е. в полном формате: . Одна колонка текста (не таблица) . Нумерованные ша1'И . Отсутствие пред.тюжений с если . Соrлашение о нумерации в разделе расширений, включающей комбинации цифр и букв (например, 2а, 2а 1, 2а2 и т.д.) Альтернативные формы  это свободный формат, формат в две колонки и шаб лон Rаtiопаl Uпifiеd Process. Все они описаны в следующих разделах. КО1'да я пока зываю 1'руппе разработчиков один и тот же вариант использования, представленный в различных стилях, они почти все1'да выбирают версию в одну колонку с НYMepOBaH ными ша1'ами, поэтому я продолжаю применять ее сам и рекомендую ДРУ1'им. Ниже приведен базовый шаблон, который rруппы разработчиков по всему миру ввели в Lotus Notes, DOORS, Word, Access и ДРУ1'ие инструменты работы с текстами. Вариант испоnьзования 14 Поnный формат шабnона варианта испоnьзования <название> <название ДОЛЖНО быть в виде краткой фразы с rлаrолом в неопределенной форме совершенноrо вида и отражать цель> 
Форматы вариантов использования 121 Контекст использования: <более длинное предложение цели, при необходимости условия ее нормальноrо достижения> Область действия: <область действия проектирования, в которой разрабатываемая система рассматривается как "черный ящик"> Уровень: <один из следующих: обобщенный, цели пользователя, подфункции> Основное действующее лицо: <ролевое имя для OCHoBHoro действующеrо лица или описание> Участники и интерес...: <список участников и ключевых интересов в данном варианте использования> Предусловие: <то, что, как ожидается, уже имеет место> Минимальные rарантии: <как защищаются интересы участников при всех исходах> rарантии успеха: <что имеет место, если цель достиrнута> Триrrер: <то, что запускает вариант использования, возможно, временное событие> Основной сценарий: <запишите здесь шаrи сценария от триrrера до достижения цели и затем какуюлибо очистку> <номер шаrа> <описание действия> Расширения: <запишите здесь по одному расширению, каждое из которых обращается к шаrу OCHoBHoro сценария> <изменяемый шаr> <условие>: <действие или подчиненный вариант использования> <изменяемый шаr> <условие>: <действие или подчиненный вариант использования> Список изменений в технолоrии и данных: <запишите здесь изменения, которые в итоrе вызовут ветвление в сценарии> <номер шаrа или изменения> <список изменений> <номер шаrа или изменения> <список изменений> Вспомоrательная информация: <то, что необходимо для проекта в качестве дополнительной информации> СвоБОАНЫЙ формат При мер варианта использования в свободном формате, взятый из рукописи [ради Буча, контрастирует с вариантом использования в полном формате. Я добавил основное действующее лицо, область действия и уровень, чтобы оформить этот пример. Обратите внимание, что во втором абзаце всетаки присутствуют расши рения. 
122 rлава 11 Вариант испоnьзования 15 111 Действитеnьная реrистрация в системе (версия в свободном формате) t><:3!> Основное действующее лицо: пользователь область действия: приложение Уровень: подфункция KorAa пользователь обнаруживает себя, система запрашивает ero имя и пароль. Система подтверждает, что введенное имя ей знакомо и пароль правильный. После этоrо пользователь получает доступ ко всем остальным командам пользователя. Если имя пользователя входит в rpynny администраторов, пользователь получает доступ ко всем командам, как уровня пользователя, так и уровня администратора. Если введенное имя пользователя не зареrистрировано либо пароль не соответствует этому имени, пользователь отверrается. Таблица в ОАНУ КОЛОНКУ Некоторым разработчикам нравится помещать ша1'И сценария в таблицу. Мне Ka жется, что линии таблицы распыляют внимание, однако, есть MHo1'o приверженцев таблично1'О стиля. Таблица 11.1 представляет собой такой шаблон. Таблица 11.1. Вариант ИСПОЛЬ30вани формата таблицы в ОДНУ КОЛОНКУ Вариант <название  это цель в виде короткой фразы с rлаrолом He использования # определенной формы несовершенноrо вида> Контекст <при необходимости более дnинное предnожение контекста использования использования> Обпасть действия <то, в чем система рассматривается как "черный ящик"> Уровень <один из следующих: обобщенный, цели пользователя, под функции> Основное <ролевое имя дnя OCHoBHoro действующеrо пица или описа действующее лицо ние> Участники и интересы Участник Интерес <имя участника> <запишите сюда интерес зтоrо участ ника> <имя участника> <запишите сюда интерес этоrо участ ника> Предусловия <то, что, как ожидается, уже имеет место> Минимальные <интересы, защищенные при всех исходах> rарантии rарантии успеха <интересы, удовпетворенные при успешном завершении> т риrrер <действие, запускающее вариант использования> 
Форматы вариантов использования 123 Таблица 11.1 (продолжение) Описание Шаr Действие 1 <запишите здесь шаrи сценария от триrrера до достижения цепи и затем необходимую очистку> 2 <...> 3 Расширения Шаr Ветвящееся действие 1а <вызывающее ветвпение успо вие><действие ипи название подчинен Horo варианта испопьзования> Изменения в технопоrии и данных 1 <список изменений> Таблица в Аве колонки Ребекке Вирс Брок принадлежит идея диалоеа, отличительной чертой KOTopo1'O является использование двух колонок, причем действия OCHoBHo1'o действующе 1'0 лица записываются в левой колонке, а действия системы  в правой. Диало1'И чаще Bce1'o записываются в процессе ПОД1'отовки к проектированию интерфейса пользователя, поэтому они MOryT содержать больше деталей действий пользо вателя. Вариант использования можно записать как таблицу из двух колонок. Такая форма Отличается ясностью, но часто бывает довольно длинной, порой более трех страниц (например, вариант использования 36). Обычно к моменту, КО1'да мы MO дифицируем текст, чтобы он укладывался в 39 ша1'ОВ на соответствующих ypOB нях цели, описание настолько простое и ясное, что потребность в колонках отпадает. Авторы КНИ1'и Software for Use ( 1999) пользуются Диало1'ОВЫМ форматом при формировании требований к интерфейсу пользователя в существенных вариантах использования. Разница с предыдущим подходом в том, что в существенном вари анте использования все движения пользователя (детали интерфейса) опущены, поэтому он получается очень коротким. Трудность использования двухколоночно1'О формата для фиксации требова ний к поведению состоит в том, что не1'де написать о ВСПОМО1'ательных действую щих лицах. Можно было бы добавить для них третью колонку, но у меня нет сведений о таком варианте. Диалоеи и существенные варианты использова н.ия подходят скорее к требованиям к интерфейсу пользователя, чем к поведению системы в целом. Принимая все это во внимание, МНО1'ие все же считают ДВУХКОЛОночную форму привлекательной. Поэкспериментируйте с ней. Таблица 1 1.2 представляет фра1' мент сценария в двухколоночном формате. 
124 rлава 11 Таблица 11.2. ДВУXf(олоночна таблица Кяиент Система Вводит номер заказа Определяет, что номер заказа COOTBeTCT вует выиrравшему номеру месяца. Реrистрирует пользователя и номер зака за как победителя данноrо месяца. Посылает электронной почтой сообщение менеджеру по продажам. Поздравпяет клиента и инструктирует ero, как получить приз. Выходит из системы Стиль RUP Техноло1'ИЯ Rаtiопа! Uпifiеd Process (RUP) использует шаблон, весьма похожий на шаблон полной формы. Нумеровать ша1'И не обязательно. Расширениям, которые называются альтернативными потоками событий, отведены собственные оза1'лавленные разделы. Все, о чем идет речь в этой КНИ1'е, хорошо СО1'ласуется с этим шаблоном. Несмотря на переизбыток номеров за1'ОЛОВКОВ, он хорошо CMOT рится И прост В употреблении. Вот e1'o базовая форма: 1. Название варианта использования 1.1. Краткое описание .. .текст ... 1.2.. Действующие лица ... текст... 1.3. Триrrеры ... текст... 2.. Поток событий 2..1. Основной поток ... текст ... 2..2.. Альтернативные потоки 2.2.1. Условие 1 ... текст... 2.2.2. Условие 2 ... текст... 2.2.З. ... 3. Специальные требования 3.1. Платформа ... текст... 3.2.. 
Форматы вариантов использования 125 4. Предусловия ... текст... 5. Постусловия ...текст ... 6. Точки расwирения ... текст... Компания Rаtiопаl Software Соrpоrаtiоп прислала мне в качестве примера вари ант использования, приведенный ниже. Обычно в наборе инструментов ему сопутст вуют диа1'рамма варианта использования и ДРУ1'ие рабочие продукты. Этот вариант использования кажется мне вполне очевидным, думаю, вы придете к тому же MHe нию. Обратите внимание, что и простые абзацы, и нумерованные ша1'И используются в соответствии с тем, как разработчик представляет себе лучший вариант. Для co вместимости с примерами в этой КНИ1'е я добавил к за1'ОЛОВКУ две ПИКТО1'раммы, но сам шаблон оставил без изменений. В варианте использования 32 также используется шаблон RUP. Вариант использования 16 81 Записаться на курсы t><:3!> 1. Название варианта использования: Записаться на курсы 1.1. Краткое описание Этот вариант использования позволяет студенту записаться на курс, предлаrаемый в текущем семестре. Студент может также модифицировать или удалить выбранные курсы, если изменения сделаны в пределах периода добавления/удаления в начале ceMe стра. Система каталоrа курсов предоставляет список всех курсов, предлаrаемых в текущем семестре. Основное действующее лицо этоrо варианта использования  CTY дент. Система каталоrа курсов  действующее лицо внутри вари анта использования. 2.. Поток событий: Вариант использования начинается, KorAa студент выбирает функцию "работа с rрафиком" из основной формы. [См. прототип интерфейса пользователя для формата экрана и полей.] 2..1. Основной поток 2.1.1. Создать rрафик 2.1.1.1. Студент выбирает функцию "создать rрафик". 2.1.1.2. Система выводит пустую форму rрафика [см. прототип интерфейса пользователя для формата экрана и модель предметной области для требуе мых полей]. 2.1.1.3. Система выводит список предлаrаемых курсов из системы каталоrа курсов. [Как он выбирается и отображается? Текст? Ниспадающие списки?] 
rлава 11 2.1.1.4. Студент выбирает 4 курса в качестве основных и 2 в качестве альтернативных из списка доступных курсов. KorAa выбор закончен, студент использует функцию "зафиксировать выбор". [Определить термины "основной курс" и "альтернативный курс" в rлоссарии проекта. Должно быть выбрано точно 4 и 2 курса или "до 4..." и т.д.?] 2.1.1.5. На этом шаrе подчиненный поток Добавить курс выполняется для каждоrо выбранноrо курса. 2.1.1.6. Система сохраняет rрафик. [KorAa обновляется rлавный rрафик? Немедленно? По ночам (в пакет ном режиме)?] l.1 АпьтеРИ8тивиь.е потоки 2.2.1. Модифицировать rрафик 2.2.1.1. Студент выбирает "модифицировать rрафик". 2.2.1.2. Система находит и отображает текущий rрафик студента (т.е. rрафик на текущий семестр). [Это все, что можно получить для текущеrо семестра?] 2.2.1.З. Система отыскивает список всех имеющихся на Te кущий семестр курсов из системы каталоrа KYP сов. Система показывает список студенту. 2.2.1.4. Студент может затем модифицировать свой выбор курсов, удаляя курсы и добавляя новые. Студент выбирает новые курсы из списка имеющихся KYP сов. Студент также может удалить любой курс из имеющеrося rрафика. KorAa редактирование за вершается, студент использует функцию "зафикси роаать выбор". 2.2.1.5. На этом шаrе подчиненный поток Добавить курс выполняется для каждоrо выбранноrо курса. 2.2.1.6. Система сохраняет rрафик. 2.2.2. Удалить rрафик 2.2.2.1. Студент выбирает функцию Удалить rрафик. 2.2.2.2. Система отыскивает и показывает текущий rрафик студента. 2.2.2.З. Студент выбирает "удалить". 2.2.2.4. Система запрашивает подтверждение удаления. 2.2.2.5. Студент подтверждает удаление. 2.2.2.6. Система удаляет rрафик. [В какой момент освобождается место студента в общем rрафике?) 2.2.З. Сохранить rрафик В любой момент студент может сохранить rрафик, выбрав функцию "сохранить". Текущий rрафик сохраняется, но CTY дент не попадает в список ни oAHoro из выбранных курсов. В ero rрафике курс помечается как "выбранный". 
Форматы вариантов использования 127 2.2.4. Добавить курс Система подтверждает, что необходимые предварительные условия (пройденные ранее курсы) студентом соблюдены, и что этот курс открыт для записи студентов. Затем систе ма добавляет студента в список выбранноrо курса. В rpa фике курс получает пометку "зареrистрированный". 2.2.5. Не выполнены предварительные условия или набор на курс закончен Если в подчиненном потоке Добавить курс система опреде ляет, что студент не выполнил необходимые предваритель ные условия или что набор на выбранный курс уже закончен, выводится сообщение об ошибке. Студент может либо выбрать друrой курс, либо отменить операцию. В этой точке вариант использования перезапускается. 2.2.6. rрафик не найден Если в подчиненных потоках Модиф'щировать rрафик или Удалить rрафик система не смоrла отыскать rрафик CTyдeH та, выводится сообщение об ошибке. Студент подтвержда ет прием сообщения об ошибке и вариант использования перезапускается . 2.2.7. Система каталоrа курсов недоступна Если система не может осуществить взаимодействие с Сис темой каталоrа курсов после определенноrо количества по пыток, система выдаст студенту сообщение об ошибке. Студент подтверждает прием сообщения об ошибке, и Ba риант использования завершается. 2.2.8. Запись на курсы закрыта Если студент выбирает функцию "работа с rрафиком", а з'CIпись на текущий семестр уже закрыта, студенту BыдaeT ся сообщение, и вариант использования завершается. CTY денты не cMorYT записаться на курсы после Toro, как запись на текущий семестр закрылась . 3. Специальнь.е требования В настоящее время для AaHHoro варианта использования специальные требования не определены. 4. Предусловия 4.1. Вход в систему До запуска этоrо варианта использования студент должен войти в систему. 5. Постусловия Постусловия, связанные с этим вариантом использования, отсутствуют. 6. Т очки расwирения Точки расширения, связанные с этим вариантом использования, отсутствуют. 
128 rлава 11 Стиль с преможениями с если ПРО1'раммисты просто не MOryT не включить в текст предложения с если. МНО1'ие 1'оворят, что чем учиться писать расширения, лучше писать так: Если заказ соответствует выиrравшему номеру, то <все, что полаrается делать для выиrравшеrо номера>, иначе сообщить клиенту, что ero номер не выиrрал. Если бы в варианте использования было только одно предложение с если, я бы не возражал. В самом деле, в модели варианта использования нет ниче1'О, что бы препятствовало употреблению предложения "если ... то ... иначе". КО1'да таких предложений два или больше, текст становится запутанным. А внутри предложения с если может быть дрУ1'ое подобное предложение. КО1'да ктолибо настаивает на употреблении предложений с если, я предла1'аю ему так и сделать и рассказать мне о приобретенном опыте. Все приходили к выводу, что предложения с если делают вариант использования нечитабельным, и возвраща лись к стилю с расширениями. Поэтому я настоятельно рекомендую не писать в cцe нарии такие предложения. Стиль с использованием языка Оккам Если вы решили построить вариант использования в соответствии с формальной мо- делью, обратитесь сначала к языку Оккам (Оссаm), изобретенному Тони Хоаром. По сравнению с ДРУ1'ими известными мне языками, Оккам обле1'чает комментирование альтернативных, параллельных и необязательных последовательностей, которые вам понадобятся. Однако я не знаю, как Оккам обрабатывает исключительные ситу- ации, необходимые для стиля с расширениями. На Оккаме вы напишете так: ALT Альтернатива Альтернатива 2 TLA (этим кончаются альтернативы) PAR Параллельное действие 1 Параллельное действие 2 RAP (этим кончаются параллельные действия) ОРТ Необязательное действие ТРО Если вы всетаки решили создать или употребить формальный язык для вариан- тов использования, примените вариант использования 22 в качестве первой пробы, так как он содержит параллельные, асинхронные, исключительные действия и со- вместную обработку. Думаю, вы увидите, насколько хорошо естественный язык справляется с этими действиями, оставаясь простым и понятным. 
Форматы вариантов использования 129 Стиль Аиаrрамм Вариант использования детализирует действия и взаимодействия действующих лиц в процессе достижения цели. Существует ряд нотаций в виде диа1'рамм, способных выразить это: диа1'раммы последовательности, кооперативные диа1'раммы, диа rpaMMbf деятельности и сети Петри. Если вы используете одну из этих нотаций, вы еще можете применить большинство идей этой КНИ1'и, чтобы сделать ваши тексты и схемы информативными. fрафические нотации имеют два неудобства в использовании. Вопервых, KO нечные пользователи и бизнесменыруководители вряд ли знакомы с ними и не про являют достаточно терпения, чтобы освоить нх. fрафические нотации отталкивают ценных читателей. BOBTOpЫX, диа1'раммы не показывают Bce1'o, что необходимо написать. CA SЕсредства, которые я видел, реализуют варианты использования с помощью диа rpaMM взаимодействия и вынуждают писателя прятать текст за всплывающим окном диалоrа, связанным со стрелками взаимодействия. При этом невозможен бе1'ЛЫЙ просмотр варианта использования: читатель должен дважды щелкнуть по каждой стрелке, чтобы увидетЬ, что за ней спрятано. Я неоднократно был свидетелем Toro, как разработчики и читатели вариантов использования отказывались от применения САSЕсредств Д1Iя построения диа1'рамм. Они делали выбор в пользу простой TeKCTO вой обработки документов. В следующем разделе обсуждается стиль на основе диа1'рамм, не подходящий ,lJ,IIя вариантов использования. иМL-Аиаrрамма варианта использования UМLдиаrрамма варианта использования, состоящая из эллипсов, стрелок и чело векоподобных фиryрок, не является нотацией для фиксации вариантов использова ния. Эллипсы и стрелки показывают объединение и декомпозицию вариантов использования, а не их содержание. Помните, что вариант использования обозначает цель. Он состоит из сценариев, состоящих, в свою очередь, из ша1'ОВ действия, каждый из которых формулируется как цель. Поэтому e1'o можно раскрыть, чтобы превратить в самостоятельный вари ант использования. Можно сделать цель варианта использования эллипсом, развер нув каждый ша1' действия как эллипс и проведя стрелку от эллипса варианта использования к эллипсу ша1'а действия, показывая, что первый включает послед ний. Можно продолжить декомпозицию от caMo1'o BblcoKo1'o до caMo1'o низко1'О ypOB ня варианта использования, производя 1'иrантскую диа1'рамму полной декомпозиции поведения системы. Однако диа1'рамма с эллипсами упускает существенную информацию, например, какое действующее лицо выполняет каждый ша1' и следит за порядком ша1'ОВ. Она полезна в качестве О1'лавления и с этой целью ее следует сохранить (см. памятку 24 и раздел А.l ). Не пытайтесь заменить эллипсами текст варианта использования. Один студент на лекции спросил меня: "КО1'да вы начинаете писать текст? На уровне листа дeKOM позиции эллипса?" 
130 rлава 11 Ответ состоит в том, что вариант использования существует в тексте и все (или какиелибо) схемы являются лишь иллюстрациями, ПОМО1'ающими читателям лока лизовать текст, который необходимо прочитать. МНО1'ие находят полезной диа1'рамму вариантов использования caMo1'o BbfcoKo1'o уровня (которая показывает внешних действующих лиц и варианты использования уровня цели пользователя). Она обеспечивает контекстную диа1'рамму, подобную тем, что используются разработчиками уже не один rод. Ценность диа1'рамм вариан- тов использования быстро падаеТ со снижением уровня. Более подробно это обсуж дается в приложении А. 11.2. факторы, влияющие на стиль варианта использования На конференции OOPSLA в 1998 1'. двенадцать опытных разработчиков и препода вателей вариантов использования собрались, чтобы обсудить общие вопросы, свя- занные с вариантами использования и факторами, которые побуждают людей писать их поразному. Ниже описаны эти факторы. Возможно, сочетание некоторых аспектов, изложенных ниже, заставит вас заду- маться о том, что вы должны работать не так, как предпола1'алось. Будьте терпеливы и пишите варианты использования так, как вам это нужно. Учитывая все эти факто- ры, вы поймете, как писать удобочитаемые варианты использования. Уравновешнвающне факторы: установкн бнэнеса, общественные отношення, конфпнктующне подходы Вы хотите ввести в обиход варианты использования, но попадаете в подобную ситу- ацию или вам навязывают дискуссию: Мы все1'да делали это ДРУ1'им способом. При разнообразии подходов вы можете решить, что: Разработчики имеют предубеждение. Существуют различные подходы, и приверженцы разных подходов делают одни и те же вещи по-разному. Разработчики вариантов использования применяют словарь, отличный от словаря их читателей. Уровень поннмання В разное время в разных местах разные люди понимают одно и то же посвоему. Основанием для изменения стиля, рекомендованно1'О для вариантов использова- ния, MOryT быть следующие факторы. Ваши знания о: · Предметной области · Вариантах использования в общем Этап жизненно1'О цикла, к которому относятся эти знания 
Форматы вариантов использования 131 Наличие необходимости в определении содержания или затрат Необходимое в данный момент рассмотрение (вширь или В1'лубь) · Присутствие cKpbfToro или затянувше1'ОСЯ анализа · Люди склонны выделять вещи, которые знают · Планирование или 1'лубина знания либо знание предметной области Потребностн участннков Какая точка зрения вам ближе: Заказчик является читателем, потребителем варианта использования, KO торый весьма доволен описанием BblcoKoro уровня. Работник фирмы (отдела IТ)  писатель или разработчик, заинтересован ный в детальном описании. Несколько 1'рупп представляют несколько точек зрения на варианты испо льзования или расходятся во мнении о построении полной либо неполной модели. Участвуют ли разные читатели? Если да, кто они? Опыт протнв формапнзма Опыт: каждая rруппа разработчиков включает людей, незнакомых с вариантами использования, но они быстро становятся "опытными" писателями. Имеющие опыт знают, как экономить усилия; новичкам нужны ясные указания и непротиво речивые инструкции. Формализм: возможно, руководитель или принятая в отделе методоло1'ИЯ диктует формальный (или неформальный) стиль описания, несмотря на любой опыт или e1'o отсутстви е. Охват Широта охвата зависит от состава 1'руппы, писательско1'О мастерства ее членов, их взаимодействия и необходимости охвата всей проблемы либо передачи информа ции читателям. На изменение охвата влияют: Эксперты предметной области (они MOryT узко сфокусировать предметную область) Количество писателей Количество читателей Количество разработчиков Знание (или e1'o отсутствие) бизнесменами своих целей Решение работать над общей моделью rеоrрафическая разбросанность членов rруппы 
132 rлава 11 Непротнворечнвость Необходимость непротиворечивости содержания может вступить в конфликт с не- определенностью или противоречивостью требований заказчика: Непостоянство требований Постоянство формата Спожность На сложность варианта использования влияют следующие факторы: Полнота описания Полное описание проблемной области Несколько точек зрения Упрощение ВЗ1'ляда на систему Упрощение представления Подробное представление Узкий взrляд или широкий ВЗ1'ляд Сложность проблемы Желание добавить технические подробности ( особенно если проблема трудна) Следующие факторы влияют на сложность системы: Бессилие анализа (сложность системы ошеломляет аналитика) Количество профилей действующих лиц Количество функциональных точек Тип системы Степень требовательности пользователей Режим реально1'О времени Встроенная система (она должна быть устойчива к ошибкам) Протнворечне Необходимо разрешить противоречие заказчика, но неопределенность маскирует это противоречие. Завершенность Завершенности MOryT препятствовать следующие факторы: Требования, необходимые для разработки, неполны. Писатели не имеют доступа к пользователям (пользователи не являются заказчиками ). Цепн в сравненнн с эадачамн  что выпопнять нпн как это выпопнять Пользователи часто определяют требования, а не способ использования. 
Форматы вариантов использования 133 Контекст может противоречить способу использования. Действия и задачи описывают, что происходит в системе, а не почему это происходит. Ресурсы Для создания хороших вариантов использования требуется время, но время проек та О1'раничено. Руководству приходится покупать незаконченный проект. Друrне факторы ДРУ1'ие факторы, влияющие на процесс создания вариантов использования: Требования к инструментам (поддержка) Неизвестная цель Необходимость разбивать список требований на части для последующе1'О анализа Проектирование без оrраничений в сравнении с заданным уровнем проек тирования Чистый стиль или понятное проектирование Абстрактные или конкретные варианты использования Возможность трассировки Общая скорость работы Получился большой список. Вы можете использовать e1'o, чтобы принять реше ние о степени формализма; о том, следует ли начать с малоrо, а потом увеличить TeM пы; как MHo1'o надо написать или как ОР1'анизовать создание вариантов использования; насколько широко или до какой степени точности следует разрабо тать вариант использования, прежде чем e1'o детализировать. 11.3. СТОНАОРТЬ/ АЛЯ пяти типов проектов Вы работаете над проектом. Прочитав эту книry, вы С колле1'ами знакомы с OCHOB ными идеями. Теперь вопрос в том, каким стандартам следовать. Ответ зависит от To1'o, кто вы, какими навыками обладаете и какова ваша задача в данный момент. Сопоставьте ваш ответ с приведенным выше списком факторов. Далее следуют стандарты Д1IЯ пяти ситуаций. В каждой из них основной выбор происходит между свободным стилем и полной формой описания. 1. Выявление требований, даже если варианты использования не будут применяться в окончательном документе, излаrающем требования. 2. Моделирование бизнесспроцессов. 3. Формулирование или определение объема требований к системе. 4. Составление функциональных требований к небольшому проекту, который следует завершить в очень сжатые сроки. 
134 rлава 11 5. Формулирование детальных функциональных требований в начале длительно1'О или объемно1'О проекта. Вы можете применять эти стандарты неизмененными или настроить их в соот- ветствии с вашими корпоративными нуждами или потребностями момента либо со- 1'ласно приведенным в этой КНИ1'е принципам. Ниже я использую примеры с компанией МуСо по разработке новой системы Acura взамен старой системы BSSO. Напоминаю: следует писать действительные Ha звания, а не слова корпорация или система. Для выявления требований Варнант нспопьэовання 17 . Шабпон выявпення  стрямкать новую бутявку  Область действия: Acura Уровень: уровень моря Контекст: потребности бqкра стрямкать новую бутявку , так как старая подудонилась (описание цели в контексте функционирования) Основное действующее лицо: бокр (или KTOTO еще) Участники и интересы: бокр, МуСо, ... (KTOTO ИЛИ чтото еще) Предусловия: что должно быть истинным, прежде чем можно будет запустить данный вариант использования Триrrеры: бокр выбирает функцию трямканья (все, что может этим быть). Основной сценарий: ... Абзац сочинения, описывающеrо успешное трямканье бутявки бокром С помощью Acura... действующие лица делают одно, Apyroe и еще коечто. . .. Еще один абзац сочинения, описывающеrо условия и альтернативные пути в попытке стрямкать бутявку или потерпеть неудачу... действующие лица делают то, се и еще коечто. Частота события: несколько раз в день Открытые вопросы: ... полезно заполнять этот раздел... Используйте этот шаблон, если ваша конечная цель  раскрыть требования (см. вставку в 1'лаве 1). Имейте в виду, что требования можно написать в форме, от- личной от варианта использования. Таким образом, И1'ра заключается в том, чтобы быстро проскочить через варианты использования, проектируя их в ходе работы. Этот шаблон написан в свободной форме. Сохраняйте в шаблоне участников с интересами, чтобы напоминать каждому об их требованиях, но не включайте 1'apaH' тии системы. Ваши варианты использования будут, скорее Bce1'o, "черными ящиками" 111, и большинство из них  уровня цели пользователя  Можете создать варианты использования более BblcoKo1'o уровня для контекста, но не опускайтесь ниже уровня моря. 
Форматы вариантов использования 135 Для МОАелирования бизнес-процесса Вариант использования 18 -е Шаблон бизнесспроцесса  достиrнуть успеwноrо функционирования компании ? Область действия: работа МуСо Уровень: обобщенный Контекст: описание цели в контексте работы Основное действующее лицо: основное действующее лицо, кем бы оно ни было Участники и интересы: ктолибо ИЛI1 чтолибо им соответствующее Минимальные rарантии: какими бы ОНI1 ни были rарантии успеха: какими бы они ни были Предусловия: что должно быть истинным, прежде чем можно будет запустить данный вариант использования. Триrrеры: все, что может этим быть. Основной сценарий: 1. ... шаrи действия... 2. ... Расwирения: 1а. ... Условия расширения: 1 а 1. ... шаrи действия... Частота события: какаянибудь Открытые вопросы: ... полезно заполнять этот раздел... Это шаблон предназначен д.nя перепроектирования бизнесспроцесса или про цесса управления новым ПРО1'раммным продуктом. Такие варианты использования читают высшие руководители, начальники отделов и высшие должностные лица, по этому старайтесь сделать их читабельными и не акцентируйте внимание на деталях данных. Нумеруйте шаrи, чтобы виден был порядок следования. Не забудьте описать обработку ошибок в расширениях, так как при этом обнаруживаются важные прави па бизнеса. Варианты использования высше1'О уровня, предельные, будут множеством "чер ных ящиков", 1It , показывающих взаимодействие компании с внешними партнерами. Они нужны либо как спецификации, с которыми будет сверяться бизнеспроцесс, либо д.nя определения контекста д.nя вариантов использования типа "прозрачный ящик". Варианты использования типа "прозрачный ящик", -е, работающие с систе мами, подобными МуСо Operatioпs, демонстрируют орrанизацию в действии с людьми и отделами, работающими совместно для обеспечения должных характеристик Функ ционирования Ор1'анизации. Цели пользователя будут от облака До уровня моря. Для примера шаблона я выбрал обобщенную цель уровня воздушноro змея. 
136 rлава 11 Для опреАеления объема требований к системе Варнант нспопьэовання 19 . Шабпон дпя опредепення объема  опредепнть объем требованнй к снстеме  Область действия: Acura Уровень: rолубой Контекст: поместите здесь предусловия или условия нормальноrо использования. Основное действующее лицо: ктонибудь ... поместите здесь несколько прер,ложений, описывающих успешное осуществление действующими лицами необходимой цели в основном сценарии ... ... поместите здесь несколько прер,ложений, касающихся некоторых альтернативных путей и обработок... Частота события: как часто Открытые вопросы: ... BcerAa полезно отметить... Этот шаблон предназначен для проектирования требований к системе, чтобы оценить ее объем и конфиryрацию. Позднее вы сможете детализировать эти требо- вания, преобразуя их в соответствии с полной формой. Можно проектировать и не- посредственно на основе вариантов использования в свободном формате, если ваш проект удовлетворяет профилю (см. раздел 3.1 и памятку 19). Шаблон дан в свободном формате, так как соответствует раннему этапу работы на среднем уровне точности, а разрабатываемая система может быть как системой, так и бизнес-процессом. Цели MOryт быть любоrо уровня, включая подфункции, по- скольку затраченные на разработку усилия зависят в основном от сложности вариан- тов использования уровня подфункции. В предыдущем примере я использовал систему Асша и цель пользователя (см. вариант использования 25). Для небольшоro проекта, который слеАует завершить в очень сжатые сроки Варнант нспопьэовання 30 . Очень сжатый шабпон: добыть банана н  Область действия: Acura Уровень: цель пользователя Контекст: Основное действующее лицо: Участники и интересы: Минимальные rарантии и rарантии успеха: 
Форматы вариантов использования 137 Предусловия: Триrrеры: Основной сценарий: ... Абзац, в котором описывается действующее лицо, добивающееся успеха в основном сценарии... Расwирения: ... Абзац, в котором упоминаются все альтернативные пут... и обработки... Частота события: Открытые вопросы: Используйте этот шаблон, если необходимы требования в письменном виде, но проект небольшой и должен быть завершен в очень сжатые сроки. Из соображений экономии избе1'айте накладных расходов, связанных с нумерацией и полным форма том шаблона. Поэтому подойдет свободная форма, но все же не забывайте фиксиро вать предусловия, 1'арантии и расширения. Пола1'аю, вы будете тщательно работать над улучшением внутренних связей проекта, как описано в памятке 19. Для Аетальных функциональных требований Вариант использования 31 " Название варианта использования  Оризовать позвение  Область действия: Acura Уровень: цель пользователя Контекст использования: Основное действующее лицо: Участники и интересы: Минимальные rарантии: rарантии успеха: Предусловия: Триrrеры: Основной сценарий: 1. ... 2. ... Расwирения: 1а. ... 1а1. ... Частота события: Открытые вопросы: ... Употребляйте этот шаблон, если ваша задача  собрать требования к поведе нию, применяя Все возможности полно1'о формата варианта использования. Это по 
138 rлава 11 дойдет для более объемных или ДОРО1'их проектов, проектов с фиксированной ценой, в случае 1'еО1'рафически распределенной 1'руппы, в начале этапа расширения и иссле дования объема вариантов использования, созданных ранее. Разрабатываемая система может быть чем yrодно, как и действующие лица и цели. Здесь также применяется система Асша и уровень цели пользователя для при- мера шаблона. 11.4. Заключение Все форматы варианта использования выражают приблизительно одинаковую основную информацию. Рекомендации и правила в этой КНИ1'е применимы к каждо му. Не слишком беспокойтесь о том, какой формат использовать в вашем проекте, выбирайте тот, который будет удобен и авторам, и читателям. 11.5. Упражнения Предложения с если 11.1. Перепишите следующий вариант использования, избавляясь от предложений с если и употребляя предложения цели на соответствующих уровнях и альтернативные сценарии или расширения. Оказать ycnyry по чнстке свечен зажнrання Условия: свечи rрязные или клиент просит оказать услуrу. 1. Откройте капот. 2. Найдите свечи зажиrания. З. Накройте щиток защитными материалами. 4 . Удалите свечи. 5. Если свечи треснули или изношены, замените их. 6. Почистите свечи. 7. Прочистите зазор в каждой свече. 8. Настройте свечу, если необходимо. 9. Проверьте свечу. 10. Замените свечи. 11. Подключите провода зажиrания к соответствующим свечам. 12. Проверые характеристику двиrателя. 13. Если она в порядке, переходите к шаrу 15. 14. Если нет, проделайте указанные шаrи. 15. Промойте инструмент и оборудование. 16. Сотрите смазку с автомобиля. 17. Закончите необходимую бумажную работу. Итоr: двиrатель работает ровно. 
Часть 2 Часто оБСУЗICдае'мые те'мЫ 
[лава 12 Коеда считать работу завершенной Вы "закончили" работу, если: . Назвали всех основных действующих лиц и все цели пользователя по OTHO шению к системе. . Зафиксировали все условия запуска для системы в качестве ТРИ1'1'еров вари антов использования либо как условия расширения. . Написали все варианты использования уровня цели наряду с обобщенными и уровня подфункции, необходимыми для их поддержки. . Каждый вариант использования написан достаточно ясно, чтобы: Спонсоры определили, действительно ли ДОСТИ1'ается желаемое. Пользователи СО1'ласились, что это именно то, что они хотят или MOryT принять В качестве поведения системы. Разработчики СМО1'ли разработать систему с данным набором функций. . Спонсоры соеласны с тем, что набор вариантов использования удовлетворяет всем их потребностям (в настоящий момент). ВСЕ ОСНОВНЫЕ ДЕЙСТВУЮЩИЕ ЛИЦА И ИХ ПОЛЬЗОВАТЕЛЬСКИЕ ЦЕЛИ. Они опре деляют 1'раницы To1'o, что должна выполнять система. Вам не с чем сравнить спи  сок основных действующих лиц и цели пользователей, есть только мнения людей, которые должны принимать систему. Поэтому вы не можете быть уверены, что сделали всю работу. Стоит несколько раз просмотреть список в режиме "моз1'ово 1'0 штурма". 
142 rлава 12 ВСЕ УСЛОВИЯ ЗАПУСКА. ОНИ представляют собой тонкую настройку 1'раниц. Си стеме придется реа1'ировать на каждое из них. В вариантах использования некото- рые события запуска появляются как ТРИ1'1'еры вариантов использования, например Пользователь вставляет карточку в автомат, Клиент обращается с за явлением добавить статью в страховой полис или удалить из Hero статью, или По льзователь выбирает функцию обновления nporpaMMHoro обеспечения. ДРУ1'ие включены в расширения сценария, например Пользователь нажал на клавишу Сапсеl, Система обнаруживает падение мощности и т.д. Один ИЗ способов повторно исследовать набор системных ТРИ1'1'еров опреде- лить все элементы, которые имеют жизненный цикл, и затем пересмотреть эти жиз- ненные циклы. Ищите все события, которые приводят к изменению состояния элемента в течение e1'o жизненно1'О цикла. О&О&ЩЕННЫЕ ВАРИАНТЫ ИСПОЛЬЗОВАНИЯ И ВАРИАНТЫ ИСПОЛЬЗОВАНИЯ УРОВНЯ ПОДФУНКЦИИ. Обобщенные варианты использования создают контекст для ва- риантов использования уровня цели пользователя. Они отвечают на часто задава- емый вопрос: "Как все эти варианты использования (уровня цели пользователя) совмещаются дру1' с дрУ1'ом?" Я предпочитаю, чтобы каждый вариант использова- ния находился внутри варианта использования более BbIcoKo1'o уровня, вплоть до единственно1'О KopHeBo1'o. Этот корневой вариант использования представляет собой лишь О1'лавление почти без сюжетной линии, однако для новичков удобно иметь единую точку, из которой можно запустить каждый вариант использования системы. Варианты использования уровня подфункции поддерживают варианты исполь зования уровня цели пользователя. Они необходимы, только Korдa их вызывают из нескольких ДРУ1'их вариантов использования или для вьеления сло}кно1'о участка поведения системы. соrЛАШЕНИЕ О ВАРИАНТАХ ИСПОЛЬЗОВАНИЯ. Варианты использования завер шены только ТО1'да, КО1'да и спонсоры, и эксперты по использованию MOryT их про- честь и с ними СО1'ласиться, а также сказать, что варианты использования содержат все, что они хотели. Разработчики должны быть в состоянии построить систему в соответствии с этими спецификациями. Это непростая задача, но это та самая зада- ча составления требований. KorAa вы заканчиваете Слово "заканчивать" создает впечатление, что вам следует написать все варианты использования от начала до конца, прежде чем начать выполнение задач проектиро- вания. Это не так. В разделе 17.1 рассматривается разработка плана проекта с час- тичной реализацией вариантов использования; см. также книry Surviviпg Object- Оriепtеd Projects (Cockburn, 1998), 1'де подробно описаиа поша1'овая разработка ПРО1'раммно1'О обеспечения, и статью VW-Staging (http://members.aol.com/acoc kburп/ papers/vwstage.htm), в которой сжато изла1'аются методы поша1'ОВОЙ и итеративной разработки. 
Korдa считать работу завершенной 143 Разные проектные 1'руппы в зависимости от ситуации применяют разные CTpaTe rии. Некоторые сразу же проектируют все варианты использования, возможно, что бы быть 1'отовыми предложить цену в случае контракта с фиксированной ценой. Им следует знать, что их варианты использования будут нуждаться в тонкой настройке в процесс е проектирования. Некоторые 1'руппы лишь намечают действующих лиц и цели пользователей, откладывая разработку вариантов использования до COOTBeTCT вующе1'О этапа. Друтие создают варианты использования в течение каждых шес ти-девяти месяцев работы, откладывая рассмотрение всех дру1'ИХ требований почти ДО конца работы. Остальные пишут варианты использования прямо перед началом этапа разработки. Каждая из этих стратеrий имеет своих приверженцев. 
rлава 13 Ка'К работать с большим 'Количеством вариантов использованuя Существуют два способа работы с большим количеством вариантов использова- ния: сделать каждый из них покороче или разделить их на отдельные 1'руппы. Следу ет использовать оба метода. САелать каЖАЫЙ вариант использования покороче (преАставление с низким уровнем точности) Само название варианта использования уже полезно, вот почему оно считается первым уровнем точности. Собрание названий вариантов использования  ОТЛич- ное средство манипулирования полным набором вариантов использования, oco бенно для оценки, планирования и контроля. Перенесите список названий в электронную таблицу и примените возможности последней для сортировки, упоря- дочивания и суммирования различных интересующих вас свойств каждо1'О варианта использования. Этот подход обсуждается в разделах 1.5 и 17.1. Второй уровень точности  краткое описание варианта использования, изло- жение варианта использования в ДBYXTpex предложениях. Для просмотра краткое описание также можно ввести в электронную таблицу или табличную форму (см. таблицу 3.3). Это полезно для обзора системы и Ор1'анизации работы. Краткость в описании каждо1'О варианта использования имеет смысл, если вы хотите просмотреть полный набор вариантов использования за один раз. Однако придет время, КО1'да вам понадобится С1'руппировать их. СОЗАать 'руппы вариантов использования Если вы работаете с инструментами обработки текстов, такими как Lotus Notes, электронные таблицы или текстовые редакторы, вы можете сформировать 1'руппы 
Как работать с большим количеством вариантов использования 145 (кластеры) вариантов использования с помощью обычных методов расстановки Me ток. В инструментах, поддерживающих UML, такие 1'руппы называются пакетами. Ниже описаны четыре общих и достаточно эффективных метода 1'руппировки. ПО ДЕЙСТВУЮЩЕМУ ЛИЦУ. Наиболее очевидный способ 1'руппировки вариантов использования  по основному действующему лицу. Однако при 80 100 вариантах использования этот способ неэффективен. На этом уровне у вас будет либо слиш ком MHo1'o вариантов использования на одно основное действующее лицо, либо слишком MHo1'o основных действующих лиц, либо слишком MH01'o пере сечений между действующими лицами и вариантами использования. ПО ОБОБЩЕННОМУ ВАРИАНТУ ИСПОЛЬЗОВАНИЯ. Некоторые варианты исполь зования естественно 1'руппируются по своему жизненному циклу или (в больших проектах) по их месту в жизненном цикле. Такие связанные варианты использова ния обнаруживаются в обобщенных вариантах использования. Если вы не пишете обобщенные варианты использования, вам все же может по надобиться С1'руппиро вать варианты использования, чтобы создавать, обновлять и удалять информацию определенно1'О вида, а это и есть 1'руппа. В одном проекте система поддерживала эк вивалент чековой книжки для клиентов. Мы назвали все изменяющие чековую книж ку варианты использования вариантами использования чековой книжки. Эта 1'руппа разрабатывалась одной командой разработчиков, и все ее члены ДВИ1'ались вперед таким образом, что руководителям проекта было ле1'КО управлять разработкой. ПО КОМАНДЕ РАЗРАБОТЧИКОВ И ВЕРСИИ. rруппировка вариантов использова ния по команде разработчиков, которая должна реализовывать проект, и номеру версии упрощает контроль над выполнением работ. В таком случае правомерен BO прос: "Собирается ли команда, отвечающая за rруппу профилей пользователей, разработать ее в срок?" rруппировка по команде разработчиков возможна даже в больших проектах. ПО ПРЕДМЕТНОЙ ОБЛАСТИ. Если в проекте более 100 вариантов использования, разработчики автоматически разделяют их по предметным областям. Обычно име новать естественные предметные области не составляет труда. Один проект испо льзовал информацию клиента, продвижения, выписку счетов и рекламную деятельность. В дрУ1'ом были такие предметные области, как прием заказов, марш  рутизация, отслеживание, доставка и выписка счета. Зачастую внутри различных предметных областей существуют подпроекты. Каждая предметная область может содержать от 20 до 100 вариантов использования. Несмотря на то, что отслеживать 240 вариантов использования довольно слож но, отслеживать 1520 1'рупп вполне приемлемо. В большом проекте я бы в первую очередь С1'руппировал варианты использования по предметной области, чтобы полу чить 36 1'рупп по 20 100 вариантов использования в каждой, а затем С1'руппировал бы их по версии и команде разработчиков. В зависимости от количества вариантов использования в этих 1'руппах, я бы подытожил ПРО1'ресс в работе с помощью COOT ветствующих 1'рупп или обобщенных вариантов использования. 
rлоsо 14 снип и nара.метризованные варианты использования 14.1. Варианты использования CRUD До сих пор нет обще1'О мнения относительно To1'o, как ОР1'анизовать все маленькие варианты использования типа Создать завиток, Найти завиток, Обновить завиток и Удалить завиток. Они известны как варианты использования CRUD (аббревиатура названий операций над базами данных Create, Retrieve, Update и Ое- Iete). Вопрос в том, входят ли все они в один вариант использования, чей размер бо- льше варианта использования Управлять завитками, либо существуют самосто- ятельно? В принципе они самостоятельны, поскольку каждый представляет собой отдель ную цель, возможно, осуществляемую дру1'ИМ лицом с ДРУ1'им уровнем допуска. Од- нако они за1'ромождают набор вариантов использования и MOryт утроить число единиц, которые нужно отслеживать. Мнения о том, как лучше Bce1'o действовать в отношении вариантов использова- ния CRUD, разделились. Сьюзен Лилли из S.R.A. выступает за то, чтобы держать их отдельно, так как это поможет отследить, какое из основных действующих лиц имеет доступ к различным функциям. Я склонен начать с ОДНО1'О, Управлять завитками, чтобы уменьшить за1'ромождение вариантов использования. Если писать варианты использования становится сложно, я выделяю одну часть, как описано в подразделе Создание из расширения HOBo1'o варианта использования (раздел 8.3). Я прослежи ваю доступ пользователя к системным данным и функциям с помощью отдельных ра- бочих таблиц. Все способы правомочны, и я не нашел достаточных оснований возводить в правило лишь один из них. 
CRUD и параметризованные варианты использования 147 Ниже следует вариант использования, написанный ДЖоном Колацци и Аленом Максвеллом из Empower п'. Они начали писать обоими способами, но затем реши ли объединить эти варианты использования в один, обобщенно1'О уровня, под назва нием Управление. В конце концов они выделили подчиненный вариант использования Сохранить, чтобы упростить работу. Их варианты использования по казывают, насколько они следовали собственному стилю в данном образце. Начав с шаблона Rational Unified Process, они пронумеровали ша1'И и расширения. Вариант ИСПОПЬЗ0вания 31 .. Управпение отчетами  1. Краткое описание Этот вариант использования описывает операции создания, сохранения, удаления, печати, выхода и отображения отчетов и управляет ими. Этот вариант использования имеет очень низкий уровень точности и обращается к друrим вариантам использования, чтобы отвечать своей цели (своим цe лям). Друrие варианты использования содержатся в документах, перечис ленных в разделе Специальные требования. 1.1. Действующие лица Пользователь (основное). Файловая система: обычная файловая система РС или сетевая файло вая система с доступом на уровне пользователей (второстепенное). 1.1. Триrrеры Пользователь явно выбирает операции, используя интерфейс Explorer. 1.3. Поток событий 1.3.1. Основной поток  открыть, отредактировать, распечатать, сохранить и выйти из отчета а. Пользователь выбирает Отчет, дважды щелкнув по слову Отчет в Explorer, и выбирает ero открытие (открытие также запускается двойным щелчком по слову Отчет в Explorer). Ь. Система выводит отчет на экран. с. Пользователь задает формат отчета и пр. с помощью варианта использования Определить спецификации отчета. Система выводит измененный отчет. d. Шаrи с и d повторяются, пока пользователь не удовлетворится видом отчета. е. Пользователь выходит из отчета с помощью варианта использования Выйти из отчета. f. Пользователь может сохранить или распечатать отчет в любой момент после шаrа с, обратившись к варианту использования Сохранить отчет или к приведенному ниже альтернативному потоку Распечатать отчет. * Использован с разрешения авторов. 
148 rлава 14 1.3.1. Апьтернативные потоки 1.3.2.1. Создать новый отчет а. Пользователь выбирает в Explorer функцию "создать новый отчет", щелкнув правой кнопкой и выбрав co ответствующую строку во всплывающем меню. Система создает новый отчет с именем по умолча нию и устанавливает статус для имени "не установле но", а статус отчета  "изменяемый". Ь. Поток варианта использования продолжается, соеди нившись с основным потоком на шаrе Ь. 1.3.2.2. Удалить отчет а. Пользователь выбирает отчет, щелкнув по слову Отчет в Explorer, и затем выбирает "удалить". Ь. Система открывает отчет (или делает ero текущим, если он уже открыт) и запрашивает у пользователя подтверждение на удаление. с. Отчет закрывается и ресурсы освобождаются. d. Система удаляет имя отчета из списка отчетов и дaH ные по отчету с носителя информации. 1.3.2.3. Распечатать отчет а. Пользователь выбирает Отчет, щелкнув в Explorer по слову Отчет, и указывает на "распечатать" ИЛИ поль зователь выбирает возможность распечатки текуще ro отчета (отчет, редактируемый либо отображае мый в основном потоке этоrо варианта использования). Ь. Пользователь выбирает принтер для печати и режи мы печати, определенные для принтера (диалоr печа ти и т .д., управляемый операционной системой) ИЛИ пользователь выбирает "распечатать отчет в файл ...". с. Система заrружает отчет и форматы. Система посы лает задание на печать операционной системе или распечатывает отчет в указанный файл отчета. Сист ма закрывает отчет. 1.3.2.4. Копировать отчет а. Пользователь выбирает Отчет, щелкнув в Explorer по слову Отчет, и затем выбирает "копировать". Ь. Система запрашивает новое имя отчета и подтверж дает, что TaKoro имени еще не было. с. Система повторяет шаr Ь до тех пор, пока пользова тель не введет правильное (несуществующее) имя, не решит заместить существующий отчет или оконча тельно прервать операцию копирования. d. Система сохраняет отчет под указанным именем как новый отчет. е. Если копия замещает существующий отчет, послед- ний удаляется. 
CRUD и параметризованные варианты использования 149 1.3.2.5. Переименовать отчет а. Пользователь выбирает Отчет, щелкнув в Explorer по слову Отчет I и затем выбирает "пере именовать" . Ь. Пользователь вводит новое имя, система подтверж дает, что имя правильное (нестарое, несуществую щее, справильной орфоrрафией и т.д.). с. Система повторяет шаr Ь до тех пор, пока не будет принято правильное имя либо пользователь не пре кратит операцию с помощью команды "отменить". d. Система обновляет список отчетов, вводя новое имя для выбранноrо отчета. 1.3.3. специапьныe требования 1.3.3.1. Платформа Для управления операциями вывода отчета и друrих действий, связанных с интерфейсом пользователя, необходимо знать тип платформы. 1.3.4. Предусповия Элемент данных существует в компьютере и выбран как текущий злемент . 1.3.5. Постусповия 1.3.5.1. Постусловие(я) успеха [примечание: это rарантия успеха]. Система ожидает взаимодействия с пользователем. OT чет может быть заrружен и выведен, либо пользова тель может выйти из отчета (закрыть отчет). Все изменения сохраняются по запросу пользователя; TBep дая копия выдается по запросу, и список отчетов надле жащим образом обновляется при необходимости. 1.3.5.2. Постусловие(я) неудачи [nримечание: это минимальная rарантия]. Система ожидает действий пользователя. Ниже приве дены возможные состояния: Отчет может быть заrружен Список отчетов все еще правилен 1.3.6. Точки расширения Отсутствуют Вариант ИСПОПЬЗ0вания 33 11 Сохранить отчет J>C> 1. Краткое описание Этот вариант использования описывает процесс сохранения отчета. Этот вариант использования вызывается из варианта использования Управление отчетами и из варианта использования Выйти из отчета. 
150 rлава 14 1.1. Действующие лица Пользователь (основное) Файловая система: типичная файловая система РС или сетевая файnо-- вая система с доступом на уровне пользователей (второстепенное) 1.1. триrrеры Чтобы вызвать этот вариант использования, пользователь выбирает операции как задачи в варианте использования Управление отчетами или вариант использования Выйти из отчета (который включен в вариант использования Управление отчетами). 1.3. ПОТОК событий 1.3.1. Основной ПОТОК  Сохранить новый отчет а. Вариант использования начинается, KorAa пользователь выбирает Сохранить отчет. Ь. Система обнаруживает, что статус имени отчета  "не YCTa новлено" , и запрашивает имя HOBoro отчета. Пользователь BЫ бирает имя отчета; система подтверждает, что это имя пока отсутствует в списке отчетов. Добавляет запись в список отчетов. с. Пользователь прекращает операцию сохранения... Вариант использования завершается. d. Система обновляет список отчетов, внося информацию об OT чете. Система создает уникальное имя файла отчета, если оно еще не установлено, и сохраняет спецификации отчета в файловой системе. е. Статус отчета получает значение "неизменяемый" , а статус ero имени  значение "установлено". f. Вариант использования заканчивается выводом отчета на экран. 1.3.1. Альтернативные потоки 1.3.2.1. Альтернативный подчиненный поток  Имя отчета существует  заменить а. Система обнаруживает имя в списке, запрашивает у пользователя указания заменить файл. Пользователь решает заменить. Система использует имя файла существующеrо отче та и запись в списке отчетов. Вариант использования продолжается с шаrа d OCHoBHoro потока. 1.3.2.2. Альтернативный подчиненный поток  Имя отчета существует  отменить а. Система обнаруживает имя в списке, запрашивает у пользователя указания заменить файл. Пользователь решает отменить действие. Вариант использования заканчивается выводом отчета на экран. 1.3.2.3. Альтернативный поток  Сохранить отчет как ... а. Пользователь выбирает "сохранить отчет как ..." Ь. Пользователь вводит имя HOBoro отчета, система проверяет, есть ли данное имя в списке отчетов. 
CRUD и параметризованные варианты использования 151 Имени в списке пока нет. Система находит имя в спи ске, запрашивает у пользователя указание заменить файл. Пользователь отвечает "НЕТ". Вариант исполь зования продолжается с шаrа Ь. с. Вариант использо вания продолжается с шаrа d OCHoBHoro потока. 1.3.2.4. Альтернативный подчиненный поток  Имя отчета существует заменить а. Система находит имя в списке, запрашивает у поль зователя указание заменить файл. Пользователь дает указание заменить. Система использует имя файла существующеrо отчета и запись списка отчетов. Ba риант использования продолжается с шаrа d OCHOBHO ro потока. 1.3.2.5. Альтернативный подчиненный поток  Имя отчета существует  отменить а. Система обнаруживает имя в списке, запрашивает у пользователя указание заменить файл. Пользователь решает отменить действие. Вариант использования заканчивается выводом отчета на экран. 1.3.2.6. Альтернативный поток  Сохранить существующий отчет а. Пользователь выбирает для текущеrо отчета функ цию "сохранить отчет" (текущий отчет прежде был сохранен и ero имя присутствует в списке отчетов). Ь. Система находит запись в списке отчетов, обновляет при необходимости данные в списке, сохраняет спе цификации отчета в файле отчета. с. Статусу отчета присваивается значение "неизменяе мый". d. Вариант использования заканчивается выводом отчета на экран. 1.3.3. специапьныe требования Отсутствуют 1.3.4. Предусповия Элемент данных существует в компьютере и выбран как "текущий элемент". Отчет в настоящее время выведен на экран и установлен в качестве "текущеrо отчета". Статус отчета  "изменяемый". 1.3.5. Постусповия 1.3.5.1. Постусловие(я) успеха [примечание: это rарантия успе ха]. Система ожидает взаимодействия с пользователем. Отчет заrружен и выведен на экран. Список отчетов обновлен (внесено имя отчета и т.д.) в соответствии с требованиями операции "сохранить". Статус отчета  "не изменяемый" . Статус имени отчета  "установлено". 
152 rлава 14 1.3.5.2. Постусловие(я) неудачи [примечание: это минимальная rарантия]. Система ожидает взаимодействия с пользователем. Отчет заrружен и выведен на экран. Статус отчета  "изменяемый". Статус имени отчета тот же, что и при запуске варианта использования. Список отчетов все еще правилен. (Список отчетов при необходимости при водится в порядок, KorAa сохранение заканчивается неудачей .) 1.3.6. Точки расширения Отсутствуют 14.2. Параметризованнь/е варианты использования Время от времени мы сталкиваемся с созданием почти одинаковых вариантов испо льзования. Наиболее распространенные примеры  Найти клиента, Найти продукт, Найти данные о продвижении и Т.д. Скорее Bce1'o, только одна 1'руппа разработчиков будет создавать общий механизм поиска, а ДРУ1'ие команды будут e1'o использовать. Написать полдюжины похожих вариантов использования в свободной форме не составляет большо1'О труда. Однако писать шесть подобных вариантов использова- ния по полной форме довольно трудоемкое и нудное занятие. Здесь необходим метод, экономящий усилия. Я опишу такой метод с помощью варианта использования 23. Для этоrо варианта использования, прежде Bce1'o, характерно следующее: . Именование цели в ша1'е очень похоже на вызов ПОДПРО1'раммы. . Варианты использования будут читать люди, а не компьютеры. При дальнейшем рассмотрении мы отметили, что при поиске предмета, чем бы он ни был, нужна одна и та же ЛО1'ика: 1. Пользователь определяет предмет, который необходимо найти. 2. Система производит поиск, выдает список возможных вариантов. 3. Пользователь выбирает, возможно, повторно сортирует список и изменяет критерий поиска. 4. Система находит предмет (или не находит). При каждом использовании изменяются: . Название предмета, который нужно найти . Критерии поиска (поля поиска) предмета, который нужно найти . Набор выводимых атрибутов предмета, который нужно найти (показываемые значения одно за ДРУ1'им) . Критерий сортировки списка найденных вариантов 
CRUD и параметризованные вариаНТbl использования 153 Мы создали параметризованный вариант использования, Т.е. такой, который pa ботает с кратким именем для каждо1'О из перечисленных элементов. Мы решили Ha звать этот варианта использования Найти что уеодно. Мы решили, что HeMHo1'o попрактиковавшись, читатель поймет, что фраза "Служащий находит клиента" озна чает вызов "Найти что У1'одно" для поиска клиента. Мы сделали то же самое для всех кратких имен в параметризованном подчинен ном варианте использования: полей поиска, выводимых значений и критериев сорти ровки. Мы только определили, 1'де писатель будет указывать подробности. Для значений данных мы определили три уровня точности. Первым была фраза из текста варианта использования  краткое имя данных, такое как Профиль клиента. Вторым были списки полей, связанных с кратким именем данных, имену ющим всю собранную под ним информацию, например имя, адрес, служебный теле фон, домашний телефон и Т.д. Третий уровень точности был точным определением поля: длина, критерии оценки и Т.д. Вариант использования содержал только первый уровень точности. Описания данных, критерии поиска и сортировки были помещены на отдельной странице, rи- перссылка на которую содержалась внутри ша1'а варианта использования. Результатом стал ша1' действия, ВЫ1'лядевший примерно так: Служащий находит клиента с помощью пара метров поиска клиента . На странице Параметры поиска клиента определялись поля поиска, последо вательность вывода полей и критерии сортировки. Читатель варианта использования щелкал по подчеркнутому выражению, чтобы увидеть содержимое страницы. Чита  тели, авторы и разработчики леrко и быстро освоили этот механизм. Вариант использования Найти что У20дно теперь ВЫ1'лядит так: 1. Пользователь определяет параметры поиска чеrолибо. 2. Система находит все, что соответствует параметрам поиска, и выводит список их отображаемых значений. 3. Пользователь может пересортировать их соrласно критерию сортировки . 4. Пользователь выбирает интересующий ero вариант. Этот изящный прием избавляет вызывающие варианты использования от за1'рО мождения МНО1'очисленными деталями (более низко1'О уровня) поиска, сортировки, пе ресортировки и т.д. Общее поведение при поиске локализуется и записывается лишь один раз. Постоянство для каждо1'О, кто ведет поиск, обеспечено, и те, кому необходи мо знать подробности для целей ПРО1'раммирования, MOryr найти ИХ. Разработчикам очень понравилось, чтО им дали только одну спецификацию механизма поиска, поэто му они не интересовались, все ли виды поиска действительно одинаковы. Довольно советов. Закончите упражнение 5.4. Обратите особое внимание на 1'a рантии и расширения, потому чТО и те, и друrие важны для вызывающих вариантов использования. 
fлава 15 Моделирование бизнеС-nРО1Jессов Все написанное в этой КНИ1'е применимо и к бизнеспроцессам, и к разработке про 1'paMMHbIx систем. Любую систему, в том числе и бизнессистему, которая предла 1'aeT набор услу1' внешним действующим лицам, защищая в то же время интересы ДРУ1'их участников, можно описать с помощью вариантов использования. Читабе льные текстовые варианты использования особенно полезны в моделировании биз Hec процессов. В этой КНИ1'е вариантами использования для бизнеса являются следующие: . Вариант использования 2. . Вариант использования 5. 8 Вариант использования 18. . Вариант использования 19. . Вариант использования 20. 15.1. МОАелирование или проектирование Утверждение "Мы применяем варианты использования для реИНЖИНИРИН1'а биз неспроцессов" может иметь одно из значений: "Мы используем их для документирования cTapo1'o процесса, перед тем как перепроектировать e1'O". .. Мы используем ихдля создания соответствующих проекту внешних требо- ваний к поведению". .. Мы используем их для документирования HOBo1'o процесса после повтор Ho1'o проектирования". Все это правильно. Вы должны решить, какое значение вы имеете в виду. 
Моделирование бизнес-процессов 155 Рассущцая о вариантах использования, я предусмотрительно употребляю термин 'м'оделирование или документирование 6изнес-процессов вместо реИНЖИНИРИН1'а или проектирования. Вариант использования только документирует процесс. Он не модернизирует и не перепроектирует e1'o. В процессе проектирования разработчики восходят к вершинам изобретательности. Варианты использования не сообщают им, как это делать. Каждый уровень документирования служит требованием к поведе- нию, которое должен удовлетворить следующий уровень проектирования (на самом деле мы rоворим, что данный проект удовлетворяет этим требованиям к поведению). Внедрение новой техноло1'ИИ часто вносит изменения в бизнес-процессы. Вы можете заново их настроить в направлении от OCHOBHo1'o бизнеса к техноло1'ИИ, от HOBo1'o процесса к технолоrии или от техноло1'ИИ непосредственно (одновременно по- рождая процесс). Работает каждый из этих методов. Работа в направлении от OCHoBHoro бизнеса Применяя этот метод работы (сверху вниз), вы начинаете с точно1'О определения OCHoBHoro бизнеса (OcHoBHo1'o вида деятельности) ОР1'анизации, как описано в кни- 1'e Reeпgiпeeriпg the Corporatioп (Hammer, 1984). КО1'да вы сделаете это, вам бу- дут известны: Участники, заинтересованные в поведении ОР1'анизации Внешние основные действующие лица, чьи цели, как вы предполаrаете, удовлетворяет Ор1'анизация События, на которые ОР1'анизация должна реа1'ировать УСЛУ2и, предоставляемые данным бизнесом, с положительными результа- тами для участников Обратите внимание, что без едино1'О слова о том, как ваша ОР1'анизация будет работать, вы теперь имеете информацию, которая устанавливает 1'раничные условия ее поведения. Это также 1'раничная информация для варианта использования: участ- ники и интересы, основные действующие лица с их целями, rарантии успеха. Контекст для проектирования бизнес-процесса можно документировать с помо щью вариантов использования для бизнеса типа "черноrо ящика", рассматривая компанию или орrанизацию как разрабатываемую систему (рис. 15.1). На этом этапе вы поновому 1'руппируете ваши ресурсы и создаете новые про цессы для наилучше1'О использования текущей техноло1'ИИ. В настоящее время компьютерные системы служат для орrанизации активной памяти и активных кана- лов связи в корпорации. В книrе Reeпgiпeeriпg the Corporatioп приводится MHo1'o примеров To1'o, как изобретательная деятельность приводит к различным биз неспроектам и соответствующему эффекту. Ито1'ОМ является новый проект корпо рации или Ор1'анизации (рис. 15.2). Далее результат переосмысления и перепроектирования процесса документиру ется с помощью вариантов использования типа "прозрачноrо ящика", показываю щих людей и отделы (и, возможно, компьютеры), взаимодействующие, чтобы обеспечить внешне видимое поведение Ор1'анизации. 
156 rлава 15 Полностью разработанные варианты использования типа "прозрачноrо ящика" должны демонстрировать обработку орrанизацией всех ошибок и исключительных состояний, подобно тому, как это делает какойлибо набор вариантов использования или полная модель бизнеспроцесса. В варианте использования вы можете записать (или не записать) название техноло1'ИИ в зависимости от вашей задачИ. @ )( Клиент rc/ . @ )(  Поставщик Налorовое управление Рис. 15.1. "Чернын ящик" OCHOBHoro бизнеса @ )( @ )( Клиент Доставщик ( Кадровая служба ) Рис. 15.2. Новын бизнеспроект как "прозрачнын ящик" Работа в направлении от бизнес-процесса к технолоrии с этой промежуточной стартовой точки вы не исследуете основную деятельность ОР1'анизации, а скорее определяете новый бизнеспроцесс, чтобы приспособиться к новой технолоrии. Вы, вероятно, уже определили некоторую новую техноло1'ИЮ, возможно, новый комплекс ПРО1'раммных продуктов или мобильных устройств. Вам требуется поставить 1'раничные условия для нововведений технолоrов. Чтобы документировать новые предлаrаемые бизнеспроцессы, не упоминая HO вую техноло1'ИЮ, вы должны писать варианты использования типа "прозрачноrо ящика" (рис. 15.3). Упоминание новой техноло1'ИИ в данной ситуации так же HeYMe 
Моделирование бизнес-процессов 157 стно, как описание интерфейса пользователя в варианте использования системы (см., например, вариант использования 21). @ rc Продажи Учет ) @ rc Клиент Деятельность после продажи Достаещик ( Кадроеая службв ) Рис. 15.3. НОВЫЙ бизнеспроект как "прозрачный ящик" (снова) в принципе компьютер в описании можно заменить корзинами бума1', перевози мыми от одноrо индивидуума к дрyrому. Задача вашей 1'руппы понять, насколько активные каналы, например большие компьютеры или множество карманных компь юте ров и компьютеров с радиосвязью, улучшают процесс. Разработчики теперь знают, какой процесс должно поддерживать их изобрете ние. Они напишyr системные варианты использования типа "черно1'О ящика", чтобы показать соответствие новой системы технолоrически независимым вариантам испо льзования для бизнеса типа "прозрачноrо ящика". Эти системные варианты исполь зования становятся требованиями к разработке системы (см. рис. 15.4). Хотя на бума1'е все вы1'ЛЯДИТ просто, это трудоемкий и ДОРО1'остоящий процесс. Технолоrия развивается быстро и оказывает большое воздействие на бизнес. Часто не хватает времени работать по такой схеме. MHo1'o раз я обнаруживал, что деловые эксперты, являющиеся классными специалистами в своей области, способны MЫC ленно построить модель HOBo1'o бизнеспроцесса, позволяя вам сэкономить время и день1'И. Это дает вам возможность идти по третьему пути, описанному ниже. @ rc ( Учет ) @ rc Доставщик Рис. 15.4. НОВЫЙ бизнеспроцесс в виде вариантов использования типа "черноrо ящика" 
158 rлава 15 Работа в направлении от технолоrии к бизнеспроцессу Вопервых, соберите несколько опытных экспертов, серьезно настроенных повы- сить качество технолоrии. Убедитесь, что у вас есть по два представителя каждой части бизнес-процесса, с которым ваша система будет иметь дело. Во время пере1'ОВОрОВ эксперты по техноло1'ИИ назовут возможности системы, которые CMOryr улучшить процесс. Будьте 1'OToBbl к тому, что они назовут больше, чем ваша 1'руппа разработчиков способна реализовать (это нормально, теХНОЛО1'ам необходимо мыслить с запасом). Пусть эксперты напишут варианты использования типа "черно1'О ящика" для си- стемы, которую они себе представляют. В этих вариантах использования не будет упоминаться интерфейс пользователя. Они должны описать, что система сделает, чтобы максимально эффективно поддерживать основных действующих лиц в дости- жении их целей в бизнесе. Разделы расширения должны включать все виды критич- ных или редко обсуждаемых бизнес-правил. Экспертам, возможно, придется ПО1'оворить со своими колле1'ами, чтобы прояснить тонкие моменты поведения систе- мы. В ходе работы они, конечно, создадут несколько вариантов использования обоб щенно1'О уровня и вариантов использования для бизнеса, показывающих контекст и связи целей во времени. Дрyrими словами, в результате будет создана документация бизнеспроцесса в облеrченной форме как часть требований к системе. Эксперты по применению смо- делируют в уме новый бизнеспроцесс, обсуждая в то же время, как следует себя ве- сти действующим лицам и новой системе в различных обстоятельствах. Я считаю такой способ работы эффективным. . Вариант использования 3 иллюстрирует, как в документации поведения систе- мы можно завершить изложение фра1'мента бизнеспроцесса описанием иск лючительных состояний. . Обобщенный (уровня воздушно1'О змея) вариант использования 21 показывает контекст бизнеспроцесса для системы. 15.2. Связь/вание вариантов использования АЛЯ бизнеса и АЛЯ системы Вариант использования для бизнеса имеет такой же вид, как и системный вариант использования, поэтому все уроки по созданию и анализу вариантов использования применимы к обеим разновидностям. Постепенно развертывающаяся история на- чинается в вариантах использования для бизнеса и разворачивается в системные варианты использования. Это совместный эффект, который обеспечивают вариан- ты использования для бизнеса и для системы. Недостаток в том, что писатели и читатели MOryr случайно смешать их, привнося поведение системы в варианты использования для бизнеса, а бизнесоперации  в системные варианты использования. Это полезно, если они совершают это намерен- 
Моделирование бизнес-процессов 159 но, но часто это делается неосознанно. Читатель, пола1'ая, что имеет дело с систем ным вариантом использования, критикует вариант использования для бизнеса за слишком высокий уровень описания, не учитывая, что тот не предназначен для дeTa лизации поведения системы. Автор, работающий над вариантом использования для бизнеса, может случайно включить MHo1'o подробностей поведения системы, в резу льтате че1'О руководство быстро потеряет интерес к чтению этих пере1'руженных дe талями документов. Чтобы уменьшить путаницу, все1'да записывайте область действия и уровень в поля шаблона варианта использования. Обучите своих авторов делать это, а читате лей  начинать чтение с этих полей. По возможности применяйте ПИКТО1'раммы. Употребляйте раЗJIичающиеся шаблоны и нумеруйте варианты использования поразному (в одной проектной 1'руппе нумерация вариантов использования для биз неса начиналась с 1.000, а системных вариантов использования  с 1). Придумайте чтонибудь на1'лядное. Torдa вы получите преимущество cOBMecTHo1'o использования без путаницы в документах и потери нужных читателей. Дрyrой недостаток заключается в том, что редко имеет смысл полностью и Haд лежащим образом связывать варианты использования для бизнеса и для системы. Обычно те, кто создают варианты использования для бизнеса, описывают биз неспроцесс вплоть до применения системы, не включая последнее. Им не хватает времени, денеr, сил и стимулов, чтобы написать, как используется новая система в повседневной жизни деловых людей. Авторы системных вариантов использования ИНО1'да дооовляют для контекста OДНOДBa предложения, описывающие бизнес-про цесс, но у них отсутствуют побудительные мотивы переписывать варианты использо вания для бизнеса, чтобы включить новые функциональные возможности системы. В результате возникает разрыв между вариантами использования для бизнеса и системными вариантами использования. Расти Уолтерс из FirеРопd комментирует это так: Я должен все же испытывать удовлетворение от полностью завершенных вариантов использования для бизнеса, которые развертываются в систем ные варианты использования. По моему опыту, весьма распространенной является ситуация, КО1'да имеются три уровня вариантов использования для бизнеса. Несколько вариантов использования для бизнеса типа "черно1'О ящика" уровня облака создаются вначале. Они быстро превращаются в ва  рианты использования для бизнеса типа "прозрачно1'О ящика" уровня обла ка, которые раскрываются, показывая тем самым, что они именуют варианты использования для бизнеса типа "прозрачно1'О ящика" и уровня воздушно1'О змея. Однако я не видел ясно1'О соединения вариантов использования для бизнеса и системных вариантов использования. Это не слишком хорошо для тех, кто ищет способ получить требования к систе ме из бизнеспроцессов автоматически. Не думаю, что автоматический вывод требо ван ий возможен (см. раздел 15.1). Некоторых это беспокоит. Меня нет. Большинство людей, с которыми я работал в орrанизациях, способны совершить переход мысленно, чтобы связать вариант ис 
160 rлава 15 пользования для бизнеса caMo1'o НИЗКО1'о уровня с системным вариантами использо вания уровня ВОЗДУШНО1'о змея или уровня моря. Кроме To1'o, я должен быть уверен, что писать этот окончательный набор вариантов использования, который полностью привязывает варианты использования для бизнеса к системным вариантам использо вания, стоит усилий и дене1', которые придется затратить. Эти две работы финанси руются отдельно, и каждая соответствующим образом завершается, КО1'да ее цель ДОСТИ1'нута. Пересмотрите варианты использования, начиная с варианта использования 19. Системные варианты использования действительно упоминаются в вариантах испо- льзования для бизнеса, но они были написаны специально, чтобы обеспечить KOH текст для 1'руппы разработчиков требований к системе, а не в качестве начала отдельной работы по реинжиниринry бизнеспроцесса. Далее Расти Уолтерс из FirePond рассказывает о своем опыте работы с вариан- тами использования для бизнеса. . Расти У олтерс: Моделирование биэнеспроцессов и требования к системе Прочитав вашу книrу, я cMor YCOBep шенствовать проблемные области с помощью прежнеrо опыта и вновь об ретенных знаний. Мой предыущнйй опыт До прочтения этой книrи я помоrал дo кументировать функциональные Tpe бования к нескольким приложениям комплекса nporpaMMHbIx продуктов. Дnя oAHoro приложения мы разра ботали системные варианты использо вания на обобщенном, пользователь ском уровне, а также на уровне под функции. Мы цепиком сконцентриро вались на функциях системы и были удовлетворены окончательной Moдe лью вариантов использования, так как она ДОВОЛЬНО леrко читалась. Мы pe шили, что нет необходимости разраба тывать какиелибо варианты использо вания для бизнеспроцесса, чтобы по казать контекст. Нас вполне устраивали системные варианты использования обобщенноrо уровня. Дnя APyroro приложения из комп лекса ситуация отличалась, несмотря на то, что за эту модель вариантов ис пользования и за предыдущую отвеча ла одна rpynna. Оrлядываясь назад, я понимаю, что основной проблемой были сотрудники, рассматривающие эту задачу под разными уrлами зрения. Я работал в направлении от би:r неспроцесса к технолоrии, а друrие  от технолоrии к бизнеспроцессу. Надо ли rоворить, что область действия про-- ектирования каждоrо варианта исполь зования не была соrласована между сторонниками двух направлений. Сторонники направления от биз неспроцесса к технолоrии так никоrда и не добрались до создания системных вариантов использования, а привер женцы направления от технолоrии к бизнеспроцессу так и не взялись за написание вариантов использования для бизнеса. Вместо зтоrо они перета совывали варианты использования Apyr Apyra, "сталкивая их лбами". При этом 
Моделирование бизнес-процессов каждая rpynna пыталась непосредст венно применять варианты использова ния друrой rpYnnbI. Поскольку разработчики не обладали в то время ни интуицией, ни должным понимани ем, чтобы правильно пометить об пасть действия и уровень вариантов использования, модель вариантов ис пользования превратилась в настоя щую мешанину. В конечном счете разработчикам никоrда не везло с этой моделью вариантов использова ния. Они чувствовали, что с ней чтото не так, но точно не знали, в чем дело. OnIoIT, поnученный nocne прочтення KNИrH Работа в направлении от OCHoBHoro бизнеса, похоже, вызывает меньшую неразбериху. я понял ЭТО в rpynne, чьей целью было понять и документи ровать бизнеспроцессы. Всем было ясно, что нас собрали обсудить бизнеспроцессы и способы их работы в этой отрасли бизнеса, а не системы nporpaMMHoro или аппарат Horo обеспечения. Возникшие неясно сти были связаны с выбором области действия проектирования: бизнеспро цесс либо подразделение. Мы начали с бизнеса, создавая Be сьма обобщенные (уровня облака) Ba рианты использования типа "черноrо ящика". Это было понятно каждому, несмотря на то, что некоторые члены 161 rpYnnbI хотели поrрузиться в детали более низкоrо уровня. Мы быстро про двиrались в создании очень обобщен ных (уровня облака) вариантов использования типа "прозрачноrо ящи ка". KorAa мы подошли к вариантам ис пользования следующеrо, более низкоrо уровня, сразу возникло COMHe ние по поводу области действия проек тирования. rоворим мы о бизнесе либо об определенном подразделении К тому же это тесно переплелось с BO просом о том, что составляет успех Ba рианта использования. В одном случае мы закончили тем, что удалили два по следних шаrа после Toro, как осознали, что зти шаrи в действительности были в вызывающем варианте использования и не должны были находиться в текущем. В настоящее время у rpYnnbI нет HaMe рения KorAa бы то ни было преобразо вывать варианты использования для бизнеса в варианты использования, определяющие требования к системе. После совещания проблемные об ласти стали понятными. Документируя результаты, я употреблял контекстные диаrраммы области действия проекти рования, пометив область действия и уровень каждоrо варианта использо вания пиктоrраммами. Простые и Ha rлядные, они действительно влияют на читабельность вариантов использова ния и существенно помоrают послед ним закрепиться в памяти читателей. 
fлава 16 Пропущенные требованuя Хорошо давать совет писать о намерении действующе1'О лица, употребляя краткое имя для передаваемыхдаиных. Однако любому ПРО1'раммисту ясно, что этой инфор- мации недостаточно для разработки. ПРО1'раммисту и разработчику интерфейса по- льзователя необходимо точно знать, что подразумевается под адресом, какие поля входят в адрес, длину этих полей и правила подтверждения для адреса, почтово1'О индекса, номера телефона и Т.д. Вся эта информация содержится rдето в требова ниях, но не в вариантах использования. Варианты использования  это только 'Тлава 3" документа о требованиях, Tpe бования к поведению. Они не содержат требований к функционированию, биз несправил, проекта интерфейса пользователя, описаний данных, описания поведения конечно1'О автомата, приоритета и Т.д. 'Тде же Torдa эти требования?"  спрашивают разработчики. Мы можем CKa зать, что варианты использования не обязаны их содержать, но 1'денибудь они ДОk жны быть документированы. Некоторые данные можно присоединить к каждому варианту использования в качестве связанной информации. Туда MOryт входить: . Приоритет варианта использования . Ожидаемая частота появления . Потребности функционирования . Дата сдачи . Второстепенные действующие лица . Бизнес-правила (возможно) . Открытые вопросы 
Пропущенные требования 163 В разных проектах этот список реryлируется в соответствии с потребностями. Во мно1'ИХ случаях эту информацию удобно хранить в электронной или простой таб лице. Часто электронную таблицу используют в начале проекта для обзора информа ции варианта использования. В крайнем столбце слева записывают название варианта использования, а в ДРУ1'их столбцах содержатся: . Основное действующее лицо . ТРИ1'1'ер . Приоритет реализации . Оценка сложности . Предпола1'аемая версия . Требование к функционированию . Статус завершенности . Все, что еще необходимо Здесь, одиако, пропущен раздел, необходимый ПРО1'раммистам почти так же, как требования к поведению: требования к данным, включая поверку полей. 16.1. Точность в требованиях к данным Рекомендация дозировать усилия при достижении точности требований к данным остается в силе (см. 1.5). Я делю требования к данным на три уровня точности: . Краткие имена данных . Списки полей или описания данных . Атрибуты и проверки полей КРАТКИЕ ИМЕНА ДАННЫХ. Мы пишем, что служащий собирает информацию о клиенте или служащий записывает имя клиента, еео адрес и номер телефона. Мы предпола1'аем расширить отдельные описания имени, адреса и номера телефо на в какомлибо дру1'ОМ месте. В варианте использования уместны краткие имена. Писать больше  значит за медлить темп сбора требований и сделать варианты использования HaMHo1'o длиннее, а также менее читабельными и менее устойчивыми (т.е. чувствительными к изменениям в требованиях к данным). К тому же весьма вероятно, что МНО1'ие варианты использо вания будут обращаться к одиим и тем же кратким именам данных. В силу этих причин уберите подробности требований к данным из варианта ис пользования и определите ссылку данноrо варианта использования на соответствую щий список полей. Это можно сделать с помощью 1'иперссылки во МНО1'их инструментальных средствах или номера требования в средствах, поддерживающих перекрестные ссылки нумерованных элементов. 
164 rлава 16 СПИСКИ ПОЛЕЙ. На некоторых этапах ПИШУЩИМ требования специалистам при дется СО1'ласовывать значения каждо1'О KpaTKo1'o имени данных. Состоит ли имя клиента из двух частей (имени и фамилии) или более? Что точно должно входить в адрес? В мире MHo1'o различных форматов адресов. Здесь вполне уместно расши рить описания данных до BTopo1'o уровня точности. Это удобно делать параллельно с созданием вариантов использования или позднее, скажем, взаимодействуя с раз работчиком интерфейса пользователя. Существует MHo1'o стратеrий работы со вторым уровнем точности. Я назову две, а ДРУ1'ие вы найдете в книrах Software for Use (Сопstапtiпе and Lockwood, 1999) и GU/s with Glue (Hohman, на момент выхода данной КНИ1'И находилась в печати). Впрочем, вы можете самостоятельно попрактиковаться в этой области. . Первая страте1'ИЯ заключается в том, чтобы работая в инструментальномсред стве создавать отдельную запись дlfЯ каждой единицы, имеющей краткое имя. Под именем клиента определите три поля: первое имя, второе имя, фамилию. Это все. Далее вы будете уточнять эту запись атрибутами и проверками полей до тех пор, пока она не будет содержать все атрибуты этих полей, как описано в пункте "Атрибуты полей и проверки полей" . . Вторая страте1'ИЯ основана на том факте, что вы записали имя, адрес и номер телефона в одном ша1'е варианта использования. Это означает, ЧТОдlfЯ вас важ но, чтобы эти три части данных вводились и выводились вместе. Это полезно дlfЯ разработчика интерфейса пользователя, который может проектировать окно или расположение полей. Поэтому вы создаете одну запись в вашем инст- рументальном средстведlfЯ "имени, адреса и номера телефона". В ней вы пере- числяете, какие поля необходимы дlfЯ имени, какие дlfЯ номера телефона и какие поля требуются дlfЯ адреса. Далее этот список вы не расширяете. РаЗJIичие двух страте1'ИЙ в том, что дlfЯ второй вы записываете кластеры данных, имеющих краткие имена, на каждой странице списка полей. Если вам надо уточнить описание данных, вы не расширяете существующую запись, а создаете отдельную за пись дlfЯ каждо1'О поля. При любой страте1'ИИ данные BTopo1'o уровня точности будут изменяться по мере продвижения проекта и по мере To1'o, как разработчики расширяют свои знания о специфике данных. Кроме To1'o, определять второй и третий уровни точности данных MOryт разные люди. Вероятно, удобнее хранить второй уровень точности данных от- дельно от caMo1'o варианта использования. АТРИБУТЫ ПОЛЕЙ И ПРОВЕРКИ ПОЛЕЙ. ПРО1'раммисты и разработчики базы дaH ных обязательно должны решить, сколько знаков отводится на имя клиента и како- вы О1'раничения на дату ущерба. ДРУ1'ИМИ словами, типы полей, длину полей и проверки полей. Некоторые 1'руппы разработчиков записывают эти сведения в 1'лаву документа о требованиях под названием "Требования к данным" или "Форматы внешних дaH ных". ДРУ1'ие, использующие средство или базу данных с 1'иперссыками,, помещают их в отдельные записи, классифицируемые как "Определения полей". Третьи зано- 
Пропущенные требования 165 сят атрибуты данных непосредственно в требования к интерфейсу пользователя и в документ проекта. Что бы вы ни выбрали, имейте в виду: . Вам необходимо расширить описание атрибутов и про верок полей до TpeTbe1'o уровня точности. . Вариант использования  не место для TaKo1'o расширения. . Вариант использования должен ссылаться на это расширение. . Атрибуты полей со временем MOryT изменяться независимо от деталей варианта использования. 16.2. перекрестные ссылки меЖАУ вариантами использования и Аруrими требованиями Форматы данных не являются частью варианта использования, но имена вариантов использования необходимы для данных, и поэтому мы можем установить rиперс сылку между вариантом использования и описаниями данных. Сложные биз несправила не очень хорошо вписываются в повествовательный текст варианта использования, но и в этом случае мы можем употребить ссылку на содержащие их записи. Этот вид связей делает варианты использования центром документа о Tpe бованиях даже для МНО1'их нефункциональных требований (см. рис. 16.1). Рис. 16.1. Модель требований в виде колеса (повторение рис. 1.1). 
166 rлава 16 Будьте осторожны и не помещайте в варианты использования те требования, которые не соответствуют формату вариантов использования. Последние лучше все- 1'0 подходят Д,fIЯ фиксации взаимодействия действующих лиц. Временами жалуются, что тяжело описывать требования Д,fIЯ операции объеди- нения лент или компилятора с помощью вариантов использования. Всецело СО1'ла сен. В таких случаях лучше Bce1'O применить аЛ1'ебраическую или табличную форму. Варианты использования 1'ОДЯТСЯ лишь Д,fIЯ части набора требований. Получает- ся, что часть, описывающая взаимодействия, находится в центре и связана со мно1'И- ми ДРУ1'ими требованиями. 
rлава 17 Роль вариантов использования в общем npo1J,ecce 11.Вариантыисnользования в орrанизации nроекта Варианты использования дают руководству возможность контролировать реализа  цию каждой функции, предназначенной для пользователей. Название каждо1'О Ba рианта использования указывает на цель, которую основное действующее лицо найдет в числе целей, поддерживаемых системой. В теле каждоrо варианта исполь зования содержатся сведения о том, что система требует и что предоставляет. Используйте названия вариантов использования в качестве основы АЛя орrанизации проекта На ранней стадии планирования проекта создайте таблиuy с названиями вариантов использования и основных действующих лиц в двух левых столбцах. В третий стол  бец заказчики проекта занесут приоритет каждоrо варианта использования. В чет вертую колонку поместите степень сложности реализации данной функции. Это естественное развитие списка Действующее лицо/Цель (см. раздел 3.1). В КНИ1'е Extreme Programmiпg Explaiпed: Embrace Chaпge (1999) есть xopo шая вариация на эту тему: разработчики оценивают стоимость разработки, в то время как заказчики решают, какой приоритет присвоить каждому варианту исполь зования. Заказчики имеют возможность изменить приоритеты, посмотрев, как oцe нена работа, но не MOryт изменить оценки. В свете этой идеи вы можете заполнить столбцы таблицы планирования в два этапа. Вы можете добавить дополнительные столбцы к таблице плаиирования, вклю чив приоритет разработки варианта использования, предпола1'аемый номер версии или даже rруппу, которая будет e1'o разрабатывать (см. таблиuy 17.1). 
168 r лава 17 Вы можете проанализировать эту таблиuy и манипулировать ею в процессе про ектирования. Таблица 17.1. Пример таблицы плонировония Дейетвую Цеп.. УРОВНII Деповаll Техничеекаll Прио N варианта щее пицо задачи потреб епожноет" ритет иепоп..зо ноет.. ваНИII Любое Проверить запросы Высшая Большая pa 2 бота в об щем случае Уполномо Изменить полно Высокая Невысокая 2 3 ченное лицо мочия Покупатель Изменить KOHTaK Средняя Невысокая 3 4 ты с поставщиком Клиент Инициировать за Наивысшая Средняя 5 прос Изменить запрос Высшая Невысокая 1 6 Отменить запрос Низкая Невысокая 4 7 Пометить запрос Низкая Невысокая 4 8 как выполненный Отказаться от дo Низкая Неизвестна 4 9 ставленных товаров Утвержда Завершить офор Наивысшая Высокая 2 10 ющее лицо мление запроса Покупатель Завершить запрос Высшая Высокая 11 для заказа Инициировать поч Высшая Высокая 12 товый перевод дe Her поставщику Сиrнализировать о Низкая Средняя 4 13 недоставке Уполномо Подтвердить под Средняя Высокая 3 14 ченное лицо пись утверждаю щеrо лица Приемщик Зареrистрировать Высшая Средняя 15 доставку Со временем вы завершите оценку для каждо1'О варианта использования, рас- пределите их по 1'руппам и будете отслеживать работу по каждой версии каждо1'О Ba рианта использования. Далее приведена история о применении таблицы планирования для измерения, оценки, расстановки приоритетов и сокращения ВОЗМОЖНО1'о рабоче1'О набора вари антов использования. Преимущества TaKo1'o способа работы: 
Роль вариантов использования в общем процессе 169 . Список вариантов использования ясно показывает значимость системы для бизнеса. . Список названий обеспечивает структуру для работы с учетом приоритета раз работки и временных рамок. . Невымышленная нсторня Разработчик должен был решить, какие бизнеспроцессы поддерживать в следующих версиях nporpaMMHoro продукта. Он выдал список Действую щее лицо/Цель на 7 страницах! Сметная стоимость, сложность, триrrер и прочее. При участии руководителя проекта список был урезан до половины странички. Затем разработчик написал основной сценарий дпя этих биз нес--nроцессов и вместе с руководителем проекта сократил перечень ша rOB, чтобы про анализировать примерно полстраницы целей уровня системы. С этой информацией разработчик посетил филиалы компании. После этоrо у Hero сложилась ясная картина Toro, какие части бизнеспроцессов наибо лее разумно адресовать работникам филиалов. Разработчик и заказчик Ha метили подrотовить в течение полуrода четыре варианта использования. Управление пересекающимися версиями вариантов использования Было бы правильнее сказать, что конкретное множество законченных вариантов использования отображается в каждой версии. Такой вариант использования, как Заказать товар, выявляет все виды специ альной обработки, которая может быть предоставлена со временем. Типичная поэ тапная страте1'ИЯ: . Реализовать простой случай в версии 1. . Добавить управление рисками в версии 2. . Реализовать предпочтительную для клиента обработку в версии 3. Вы либо создаете один вариант использования и часть e1'o закладываете в каж дую версию, либо пишете три варианта использования. Оба способа будут работать, и оба имеют свои недостатки. Некоторые 1'руппы разработчиков расщепляют варианты использования на еди ницы, которые целиком входят в версии. Они пишут вариант использования Зака зать товар, затем Заказать товар (управление рисками) и Заказать товар (дополнительные предпочтения клиента). Они или повторяют тело варианта использования, дописывая курсивом новые элементы, или создают второй вариант использования как расширение перво1'О, а третий  как расширение BTopo1'o. Pac щепление вариантов использования упрощает отслеживание, однако число вариан тов использования, подлежащих отслеживанию, утраивается, и создание дополни тельных вариантов использования может усложниться. 
170 rлава 17 ДРУ1'ие (я в том числе) предпочитают, чтобы варианты использования были MaK симально удобными для чтения и создавались с расчетом, что будут реализовываться частями. Порции, которые будут реализованы первыми, вьщелены желтым цветом или курсивом и называются вьщеленными порциями варианта использования 5. Этот способ я видел во МНО1'их проектах, и он неплохо работает. И все же он не так хорош, чтобы нас удовлетворить. Возможен дрyrой путь. Начните с создания полно1'О варианта использоваиия, включающе1'О несколько версий. Затем в начале некоторой итерации напишите ero версию, включающую только те функции, реализовать которые вы планируете на этой итерации. На следующей итерации вьщелите части варианта использования, KO торые уже реализованы, обычным шрифтом, а новые части, предназначенные дlIЯ следующей версии,  жирным шрифтом. При этой методике количество вариантов использования также увеличивается, но более контролируемым образом. Если в Ha чале имеются 80 вариантов использования, разработчики подозревают, что придется управляться не только с иими, но И еще с каким-то числом вариантов использования на этой конкретной итерации. Множество вариантов использования расширяется, но этот процесс локализован и находится под контролем. Вам придется выбрать методику работы, учитывая, что каждая имеет недостатки. Имейте в виду, что все подходы предпола1'ают, что ОР1'анизация использует поэ- тапную (итерационную) разработку и сдачу системы с этапами длительностью до че тырех месяцев. Итерациониая разработка стала стандартной в современном проектировании ПРО1'раммно1'О обеспечения и подробно обсуждается в моей КНИ1'е Surviviпg Object Orieпted Projects (1998) и в статье vw Stаgiпg (http://mem bers.aol.com/ acockburп/ papers/ vwstage.htm). Реализация полных сценариев . Невымышпенная МСТОРМЯ Менеджер по тестированию и интеrрации очень большоrо проекта расспра-- шивал меня об опасностях итерационной разработки. Оказалось, что rpynna разрабатывала и сдавала приложение, используя наборы функций (features), а не варианты использования. Ero rpynna не моrла тестировать эти куски, так как они не поддерживали никакоrо "сюжета", представляя собой кучу алrоритмов. В конце концов руководители проекта перестроили план так, чтобы результатом работы на каждом этапе была приемлемая сюжетная линия. Часто случается, что не все варианты использования разрабатываются OДНOBpe менно. Несмотря на это, каждый должен содержать полный сценарий. В варианте использования 1'оворится, что Хочет осуществить пользователь, и перечисляются МНО1'ие необходимые дlIя ЭТО1'О сцеиарии. Производимое вами ПРО1'раммное обеспе чение должно содержать некоторые из этих сценариев от начала до конца, или ваше приложение ие будет обеспечивать выполнение должной функции. 
Роль вариантов использования в общем процессе 171 Плаиирование должно СО1'ласовываться с проектированием, чтобы создать Ha бор функций, полезных для конечно1'О пользователя. Это полные сценарии из вари антов использования. Специалисты по функциональному тестированию будут проверять совместимость варианта использования. Ввод в действие можно осущест влять только для полностью законченных сценариев вариантов использования. Это кажется тривиальным, но если это ПРОИ1'норировать, возможен ущерб, как Показывает вышеприведенная история. 17.2. Варианты использования и списки заАач или функций fруппы разработчиков, у которых налажено общение, формируют задачИ проекти рования на основе вариантов использования. Это хорошо, так как в противном слу чае у руководителей проекта будут трудности при отображении вариантов использования в задачИ проектирования и актуализации последних. Для иллюстрации приведу следующее электронное письмо от колле1'И. В последние две недели двое из нас посещали клиента, чтобы получить от He1'o требования и установить взаимодействие с разработчиками. Мы сфоку сировались на вариантах использования и поняли, что их точность составля ет 90-95%, а это1'О вполне достаточно для проектирования и реализации, поэтому мы были спокойны. Существовал документ относительно области действия, описывающий, какие функции или наборы функций были в ней или вне ее. Это похоже на приведенный вами пример области действия проекти рования. Вначале этот документ был очень коротким, но мы удовлетворили запросы на "традиционное" описание требований. Поэтому пришлось e1'o He MHo1'o расширить, но мы постарались свести детали к минимуму. На первой встрече разработчики хотели пересмотреть "требования", KOTO рые были представлены для них в этом документе относительно области действия проектирования. Мы поняли, что в документе недостает иеобходи мых подробностей, так как мы надеялись сконцентрироваться на вариантах использоваиия. Следующие три дня мы провели, разрабатывая пересмот ренный документ, который вы увидите во вложеином файле. Это можно на  звать "разжевыванием" вариантов использования. Надеясь повлиять на культуру разработки и помочь компании осуществить переход к требовани ям на основе вариаитов использования, мы часто употребляли название каждо1'О варианта использования в качестве набора функций, а каждый ша1' сценария  как функцию. Мы буквально копировали ша1'И из вариантов использования и вставляли их в документ области действия под соответст- вующим за1'ОЛОВКОМ варианта использования. Проблема, с которой мы столкнулись И которая в конце концов вынудила иас осуществить это удвоенное сопровождение, состояла в том, что точный текст сценариев в качестве четко выделенной функции не был вполне неза висимым. Даже если бы мы копировали текст сценариев, нам пришлось бы перефразировать e1'o или окружать контекстом. 
172 rлава 17 Таково начало. Разработчики зачастую хотят работать, исходя из нумерованных абзацев требований или списков функций. В ДРУ1'их подобных историях сначала co здавались "подробные требования" или документ с нумерованными абзацами. KTOTO Torдa решил написать варианты использования, исходя из этих документов. Это основное противоречие между поведением системы, описанным в вариантах использования, и задачами проектирования, которые ставятся перед отдельным раз работчиком. Разработчик трудится над одним элементом строки или функцией, опре деленной в 1'лубине ОДНО1'О варианта использования, или, возможно, проходящей через несколько вариантов использования. Это MOryT быть ал1'ОРИТМЫ "отменить" (Undo), "ре1'истрация транзакций в журнале" (Пrапsасtiоп Lоggiпg) или "структура экрана поиска" (Search Screen Framework). Разработчики не MOryT описывать свою работу на языке вариантов использования, поскольку они не имеют дела с поведени ем системы. В лучшем случае разработчик скажет, что он работает над частью вари анта использования 5, посвященной структуре экрана поиска. В то же время руководители проекта хотят видеть приложение, полностью реа- лизующее поведение системы и удовлетворяющее потребности пользователей. OTдe льные задачи проектирования сами по себе не представляют для них интереса. Синхронизация документации вариантов использования и списка задач проекти- рования требует MHo1'o времени и труда. Работу, описанную моим колле1'ОЙ, прихо дится повторять В процессе проектирования MHo1'o раз. Я считаю, это1'о следует избе1'ать. До сих пор мне не приходилось разбивать варианты использования на OTдe льные строки в проектах, над которыми работали до 50 специалистов. Может быть, дело в том, что в своих проектах я уделял особое внимание личному общению, co трудничеству и соответствующей культуре проектирования. Нам удавалось выделять элементы строк в уме или с помощью желто1'О маркера, а также записывать ключе- вые элементы в список задач для планирования без больших накладных расходов. Альтернативой является формирование двух документов и упорный труд по их актуализации. Если вы решили следовать этой страте1'ИИ, разбейте текст варианта использования на фра1'менты, каждый из которых можно поручить отдельному раз- работчику или отдельной 1'руппе. Каждый фра1'мент становится реализованной функ цией ПРО1'раммы, ал1'ОРИТМОМ или задачей проектирования, которая будет распределяться по разработчикам, отслеживаться и контролироваться. Подробная смета разработки ПРО1'раммно1'О обеспечения складывается из смет всех задач проек- тирования. Отслеживание состояния проекта состоит в том, чтобы отмечать начало и завершение осуществления каждой задачи проектирования. Далее приведен при мер преобразования варианта использования в список работ. Вариант испопьзования 34 111 Зафиксировать встречную продажу  Цель в контексте: у покупателя есть тележка с товарами и он хочет произвести встречную продажу, чтобы посмотреть, как это повлияет на стоимость. Область действия: проrраммная система торrовли Уровень: подфункция 
Роль вариантов использования в общем процессе 173 Предусловия: тележка должна содержать товар (товары). fарантии успеха: встречная продажа оценена, добавлена к товарам в тележке, стоимость товаров в тележке сокращена. Минимальная rарантия: если цель не достиrнута, встречная продажа не фиксируется и не добавляется к содержимому тележки. Основное действующее лицо: покупатель (любой пользователь Сети) Триrrер: покупатель решает зафиксировать встречную продажу. Основной сценарий: 1. Покупатель решает зафиксировать встречную продажу. 2. Система оценивает встречную продажу, предоставляя информацию покупателю и задавая ряд вопросов, чтобы определить стоимость встречной продажи. Вопросы и представляемая информация зависят от ответов покупателя. Стратеrия ответов и информации определена за ранее, чтобы выделить практику выполнения относительно встречной продажи. 3. Система реrистрирует навиrационную информацию и информацию о встречной продаже в рабочем порядке. 4. Покупатель просматривает и анализирует сводку и стоимость встреч ной продажи. 5. Покупатель добавляет ее к тележке. 6. Система добавляет к тележке встречную продажу и навиrационную ин формацию. 7. Система показывает обзор тележки со всеми ее товарами и встречной продажей, а также пересчет общей стоимости с учетом встречной продажи (продаж). Покупатель повторяет вышеприведенные шаrи столько раз, сколько xo чет зафиксировать и оценить встречных продаж, по желанию добавляя их к тележке. Расwирения: 2а. В любой момент, прежде чем добавить встречную продажу, покупа тель может вернуться и изменить предыдущий ответ. 5а. Покупатель решает не добавлять встречную продажу к тележке; сис тема сохраняет навиrационную информацию на будущее. 5Ь. Покупатель хочет, чтобы встречная продажа применялась к определен ной единице в тележке; покупатель указывает находящийся в тележке товар, к которому он желает применить встречную продажу. Таблица 17.2 представляет сформированный список работ. Таблица 17.2. Список работ ДЛЯ фиксации встречной продажи Сеь.пка ФУНКЦНJI Депо.аJl потребность Должна быть Должна быть ВереИJl ЕС10 ЕС10.1 Зафиксировать встречную продажу Обеспечить покупателю возможность ввести встречную продажу в тележку. 1.0 1.0 
174 rлава 17 Таблица 17.2 (продолжение) Ссь.пка Функцн. Депо.а. Версн. потребность ЕС10.2 Обеспечить возможность представлять Должна быть 1.0 сrенерированные (на основе шаблонов) формы интерфейса пользователя и про бираться через них, чтобы собрать ин формацию о встречной продаже для определения ее стоимости. ЕСI0.З Обеспечить возможность обращаться к Должна быть 1.0 внешней системе встречных продаж (или сайту) для определения стоимости встреч ной продажи. Связанная с покупателем информация о встречной продаже пере дается на внешний сайт, который оценива ет встречную продажу и возвращает ее стоимость и важные характеристики. ЕС10.4 Обеспечить возможность представить Должна быть 1.0 покупателю сводку встречных продаж, включая их стоимость. ЕС10.5 Обеспечить возможность покупателю Должна быть 1.0 добавлять или удалять встречную прода жу. Добавив встречную продажу к TOBa рам в тележке, покупатель может связать ее с отдельным продуктом или всеми продуктами в тележке. ЕС10.6 Обеспечить возможность пересчитать об Должна быть 1.0 щую стоимость содержимоrо тележки, учитывая встречную продажу (продажи). ЕС10.7 Обеспечить возможность редактирова Должна быть 1.0 ния имеющейся встречной продажи, воз вращаясь для редактирования к процессу вопрос / ответ. ЕС10.8 Обеспечить возможность удалять суще Должна быть 1.0 ствующую встречную продажу из тележ ки и пересчитывать общую стоимость. ЕС10.9 Обеспечить возможность реrистриро Должна быть 1.0 вать любую информацию о встречной продаже или шаrи на основе предварите льно сконфиrурированных триrrеров. 17.3. Варианты использования и проектирование Варианты использования обеспечивают все требования к поведению типа "черный ящик", какие только MOryT встретиться в проекте (и только их). Требования дол- жны называть все, что система должна делать. При этом не должна подавляться 
Роль вариантов использования в общем процессе 175 свобода разработчиков. Дело разработчиков  создать хороший проект, отвечаю щий этим требованиям. Предпола1'ается, что соответствие между требованиями и проектом этим и О1'раничивается. Переход от вариантов использования к проектированию имеет как хорошие, так и плохие стороны. Плохо то, что: . В проекте отсутствует 1'руппирование по вариантам использования. . Слепое следование структуре варианта использования ведет к проектам функ циональной декомпозиции (это реально касается тех команд разработчиков, которые занимаются объектноориентированным и компонентным проектиро ванием ). Хорошо то, что: . Некоторые методы проектирования используют преимущества всех сценариев. . Варианты использования выявляют понятия, необходимые при моделировании предметной области. Рассмотрим сначала недостатки. В ПРОЕКТЕ ОТСУТСТВУЕТ rРУППИРОВАНИЕ ПО ВАРИАНТАМ ИСПОЛЬЗОВАНИЯ. Зада  чи проектирования не отображаются точно в единицы вариантов использования. Задача проектирования приводит в результате к бизнесобъекту или к механизму поведения, который будет применяться в нескольких вариантах использования. Ba риант использования, который планируется выпустить в более поздний срок, Bepo ятно, будет содержать важную информацию для задачи проектирования, выпол ненной ранее. Это означает, что КО1'да к разработчикам поступит эта информация, им придется изменять проект в более поздних версиях. Существуют три способа решить этот вопрос. Первый заключается в том, что разработчики просматривают все варианты использования на предмет ключевой ин формации для своих задач проектирования. Ясно, что это осуществимо только для иебольших проектов. Если вы сможете с этим справиться, это окупится. Второй подход состоит в сканировании всех вариантов использования, чтобы найти рискованные элементы (ключевые функции), которые, вероятно, должны оказывать сильное воздействие на процесс проектирования. rруппа создает проект, чтобы реализовать эти ключевые функции, надеясь, что остальные функции не слиш ком нарушат проект. Суть TpeTbe1'o способа, для меня предпочтительно1'О, в том, чтобы осознать, что проrраммное обеспечение будет изменяться в течение cBoe1'o жизненно1'О цикла, и успокоиться. rруппа разрабатывает каждую версию настолько хорошо, насколько это имеет смысл. Разработчики понимают, что КО1'данибудь MOryT всплыть новые требования, которые вызовут изменения. Этот путь может не подойти некоторым разработчикам, особенно тем, кто зани мался проектированием баз данных. Часто в этих средах добавление новых полей к таблице и повторная оптимизация базы данных обходятся дорО1'О. Экономические co ображения заставляют разработчиков вначале определять все атрибуты, к которым 
176 rлава 17 КО1'далибо будет обращение. Они разрабатывают и выпускают ПРО1'раммное обеспе чение, которое будет затем называться на 20%,40% и 100% завершенным относи тельно обще1'О набора атрибутов. Однако в наиболее современных средах с итерационной разработкой добавление атрибута к классу или таблице  рядовая операция, достаточно дешевая, чтобы раз- работчики определяли только те части класса или кате1'ОРИИ, которые нужны были немедленно. В результате классы и компоненты все1'да "полны" только по отноше нию к заданному набору функций. По мере To1'o, как реализуются новые функции, понятие "полноты" изменяется. . Невымышленная история Эта мысль пришла в rолову во время работы над одним проектом, KorAa руководитель rpYnnbI пожаловался, что ему не позволили "завершить" классы после 20процентной отметки rотовности, хотя разработанное при ложение выполняло все, что хотел пользователь! Нам потребовалось MHO ro времени, чтобы понять, что он rоворил с точки зрения культуры проектирования баз данных, а работал над проектом, rAe применялся ме.- тод итерационной разработки. Будьте 1'OToBbI к подобной дискуссии. Если бы не исключительно жесткие эконо мические рамки, я бы предложил вашей 1'руппе работать в соответствии с моделью "полноты в отношении набора названных функций". ВАРИАНТЫ ИСПОЛЬЗОВАНИЯ И ФУНКЦИОНАЛЬНАЯ ДЕКОМПОЗИЦИЯ. Если вы при меняете методь! структурной декомпозиции, будет полезна функциональная деком  позиция в вариантах использования. Однако если вы занимаетесь объектноориен тированным проектированием, примите во внимание следующее. Особые заметки АЛЯ специалистов обьектноориентированноrо проектирования Наборы вариантов использования, составляющих функциональную декомпозицию или функциональную иерархию, демонстрировались как эффективное средство взаимодействия при составлении требований к поведению. Написанное ле1'че BOC принимать, и поведение аккуратно свертывается во все более высокие уровни. Это обле1'чает жизнь тем, кому приходится СО1'ласовывать задачи системы. Такая функциональная декомпозиция 1'одится для требований, но это не значит, что она подходит для проектирования ПРО1'раммно1'О обеспечения. Совместная ин капсуляция данных и поведения позитивно зарекомендовала себя, упрощая разра ботку и сопровождение ПРО1'раммных проектов. Однако не очевидно, что она предоставляет хорошую структуру для сбора или обсуждения требований. СО1'ласно моему опыту, она не так удачна, как структура на основе функций. ДРУ1'ИМИ словами, сбор требований ВЫИ1'рывает от функциональной декомпозиции и вместе с тем про ектирование это1'о ПРО1'раммно1'О обеспечения ВЫИ1'рывает от заключения данных и поведения в один компонент. 
Роль вариантов использования в общем процессе 177 Разработчики должны прочитать варианты использования, подумать и обсудить их, а затем выдать полезные абстракции. Это их работа, а не пользователя. Некоторый риск заключается в том, что неопытный или неосмотрительный раз работчик создает классы, которые станут отражением функциональной декомпози ции документа о требованиях, просто отобрав каждый вариант использования как класс (объект, компонент). Практика показала, что это неверная страте1'ИЯ, и МНО1'ие эксперты по объектноориентированному проектированию явно предостере1'ают от ее использования. KTOTO, наверное, может отстаивать включение варианта использования уровня цели пользователя в собственный класс, так как он охватывает полную транзакцию с четкой фиксацией и откатом. Он может быть подходящим кандидатом на инкапсуля цию. Однако варианты использования уровня подфункции редко имеют эти xapaKTe ристики. Они обычно являются частичными аЛ1'оритмами, фра1'ментарно представ ленными в разных классах. Противоположная опасность подстере1'ает специалистов по объектноориенти рованному проектированию, которым требуется моделировать предметную область непосредственно, не заботясь о функциях, которые необходимо поддерживать. Эти разработчики упускают из вида роль функциональных требований. Варианты исполь зования указывают тому, кто моделирует предметную область, какие аспекты представляют интерес для анализа. Без этой информации потребуется слишком мио1'о времени для моделирования частей предметной области, не существенных для данной системы. Варианты использования обеспечивают 1'раничные условия надеж Ho1'o и полно1'О моделирования (подробнее см. в статье An Ореп Letter to Newcomers to 00, http://members.aol.com/humaпsaпdt/papers/ooпewcomers.htm). Ясно, что во всех случаях варианты использования и объекты разделяют среду на различные ОР1'анизующие схемы. Имейте это в виду при проектировании. Теперь перейдем к преимуществам. ПРОЕКТЫ ПОЛЬЗУЮТСЯ СЦЕНАРИЯМИ. Варианты использования служат ле1'КОДО ступными сценариями при проектировании ПРО1'раммы. Они особенно полезны при проектировании на основе обязанностей' (RespoпsibilityDriveп Desigп), КО1'да проектирование осуществляется в соответствии с ша1'ами сценария. Варианты ис пользования также весьма полезны при ДРУ1'их методах проектирования, показы вая, КО1'да проектирование завершено, и обрабатывая все ситуации (расширения). ВАРИАНТЫ ИСПОЛЬЗОВАНИЯ ВЫЯВЛЯЮТ ПОНЯТИЯ ПРЕДМЕТНОЙ ОБЛАСТИ. Вари анты использования довольно четко называют имена объектов предметной облас ти. Рассмотрим фразу варианта использования: * Прочтите статью К. Beck и W. Cunningham А Laboratory for ObjectOriented Thinking, АСМ SIGPLAN, или книry R. WirfsBrock, В. Wilkеrsоп и L. Wiener Desigпiпg ObjectOrieпted Software. Познакомьтесь с информацией, находящейся по адресу http://c2.com/ cgi/wiki?CrcCards или http://members.aol.com/hu maпsaпdt/ papers/crc.htm. 
178 rлава 17 Система выдает счет, заполняет поля строки счета значением стоимости, добавляет налоr и стоимость доставки и подсчитывает сумму. Нижний колонтитул счета формулирует условия доставки. Не требуется большо1'О воображения, чтобы представить счет, поле строки сче та и нижний колонтитул счета с атрибутами стоимости, наЛО1'а, доставки и суммы. Это не обязательно окончательные элементы проекта, но они являются хорошим на- чальным набором бизнесобъектов. Я видел, как проектные 1'руппы проделывали путь непосредственно от понятий в вариантах использования до набросков проекта. Такой метод делает проект сжатым и четким. 17.4. Варианты использования и проектирование интерфейса пользователя в КНИ1'ах Software for Use и GUfs with Glue вопросы проектирования интерфейса пользователя изложены Лучше, чем это MOry сделать я. Однако при написании Ba риантов использования большинство проектных 1'рупп спрашивает, как осущест- вить переход от вариантов использования без интерфейса пользователя к действительному проектированию интерфейса пользователя. Некоторые специалисты в состоянии изобрести приятный в использовании ин- терфейс. Эти люди прочитают варианты использования и придумают такое представ- ление, которое придерживается ша1'ОВ вариантов использования, сведя к минимуму усилия, требуемые от пользователя. Их проект интерфейса пользователя будет YДOB летворять требованиям, заданным вариантами использования. С этой точки зрения проект будет рассмотрен пользователями и ПРО1'раммистами. Создатели вариантов использования показывают, что они вводят данные в фор- му для сбора данных или заполняют бумажную форму, чтобы было понятно, какая информация должна быть введена, и существуют ли О1'раничения на порядок ввода. Обеспечьте, чтобы эти формы соответствовали ВЗ1'лядам экспертов по использова нию, а не интерпретировались как часть требований. Хотя описание интерфейса пользователя не предназначено для документа о Tpe бованиях, полезно расширить документ примерами проектирования интерфейса по льзователя. Такая информация по проектированию может улучшить восприятие документа о требованиях, так как дает и текстуальное (абстрактное), и визуальное (конкретное) описание поведения системы. Проект интерфейса пользователя имеет три уровня точности (низкий, средний и высокий ): . Описание интерфейса пользователя низкой точности представляет собой экранно-наВИ1'ационную схему, выполненную в виде конечно1'О автомата или диа1'раммы состояний. Каждое состояние  это имя экрана, с которым будет иметь дело пользователь. Конечный автомат показывает, какие события, про исходящие с пользователем, вызывают переход от одно1'О экрана к дрУ1'ому. . Описание интерфейса пользователя средней точности  это рисунок или уменьшенный снимок экрана. Поместите e1'o в конце варианта использования, чтобы читатели мо1'ли и читать о предла1'аемом проекте, и видеть e1'o. 
Роль вариантов использования в общем процессе 179 . Описание высокой точности перечисляеттипы, длину и проверки всех полей для каждо1'О экрана и никак не соответствует документу о требованиях. 17.5. Варианты использования и тестовые варианты Варианты использования обеспечивают 1'OToBoe описание функционально1'О теста системы. Большинство тестировщиков приветствует работу с вариантами исполь- зования. Ведь они впервые получают что-то, с чем так ле1'КО работать. Более To1'o, этот комплект тестов предоставляется им как раз во время сбора требований! Луч- ше Bce1'o, если они пОМО1'ают писать варианты использования. В формальной 1'pyппe разработки команде тестирования приходится разбивать варианты использования на пронумерованные тесты и составлять план, определяю щий отдельные параметры, которые будут обеспечивать различные пути выполнения npo1'paMMbl. Затем они строят все тестовые примеры, которые устанавливают эти па- раметры и выполняются с этими установками. Кроме To1'o, они используют все набо- ры данных, представляющие различные их комбинации, необходимые д,ля тестирования, а также проектируют характеристики системы и тесты заrрузки. Двум последним задачам варианты использования не содействуют. Все это обычно касается команды тестирования. Таблицы 17.3 и 17.4 предо- ставлены Питом Мак-Брином (http://www.mcbreeп.ab.ca/papers/TestsFromUse- Cases.html). Первым идет вариант использования, а затем  набор тестов приемки. Я оставляю этот пример вашей команде тестирования. Проанализируйте e1'o для co вершенствования навыков работы. Обратите внимание, как Пит использует участников и интересы, чтобы пOCTpO ить тестовые примеры. E1'O тесты содержат специальные тестовые значения. Вариант испопьзования 35 ., Заказать товары, сформировать счет (пример тестирования)  Контекст: клиент размещает заказ на товары, счет формируется и отправ ляется вместе с заказанными товарами. Минимальные rарантии: В случае неудачи товары не будут выделены клиенту, учетная информация клиента останется неизменной и попытка транзакции будет записана в журнал. rарантии успеха: Товары будут выделены клиенту. Будет создан счет (применяется правило выписки счета клиенту). Список выбора будет отослан для распределения. Осноаной сценарий: 1. Клиент выбирает товары и указывает их количество. 
180 rлава 17 2. Система выделяет для клиента требуемое количествО каждоrо товара. 3. Система добывает заверенное разрешен.ие на выписку счета. 4. Клиент указывает место доставки. 5. Система посылает инструкции по выбору товаров для распределения. Расwирения: 2а. Копичество товара на скпаде не достаточно для выполнения заказа: 2а1. Клиент отменяет заказ. 2Ь. Товара нет на складе: 2Ы. Клиент отменяет заказ. 3а. ВЫСОКИЙ кредитный риск у клиента (используйте тест приемки для этоrо исключительноrо состояния). 4а. Неправильное место доставки: п Для каждо1'О расширения, приведенно1'О выше, необходим по крайней мере один тестовый пример. Для полно1'О тестирования нужно больше тестов для разных набо ров значений данных. Тест OCHOBH01'O сценария (таблицы 17.3 и 17.4) следует пpo1'o нять первым, поскольку полезно показать, как работает система в полном объеме. Часто e1'o можно создать прежде, чем станут известны все условия расширения и пути восстановления. Таблица 17.3. Тесты OCHOBHoro сценария (НИЗКИЙ кредитный риск) Начальное состояние системы/входные данные Ожидаемое состояние системы/выход ные данные Клнент Пит, низкий кредитный риск, зака зов  один, товар #1 по цене $10,00. Количество товара # 1 в налнчин  10. Количество товара # 1 в налични  9. Формируются инструкцни по доставке. Выдается счет для клиента Пита за один из товаров #1 по цене $10,00. т ранзакцня реrистрируется. Таблица 17.4. Тесты OCHOBHoro сценария (высокий кредитный риск) Начальное состояние системы/входные данные Ожидаемое состояние CHCTeMЫ/BЫXOД ные данные Клиент Джо, высокий кредитный риск, за казов  однн, товар #1 по цене $10,00. Количество товара # 1 в наличии  10. Колнчество товара # 1 в наличии  9. Ин струкции по доставке указывают ДOCTaB ку за наличные. Транзакция реrистрируется. 17.6. Реальное создание вариантов использования Вашей 1'pyппe придется освоить определенные навыки работы. В следующем разде ле показан процесс ветвления и соединения (branchandjoin), который является 
Роль вариантов использования в общем процессе 181 моим излюбленным способом работы. Энди Краус из 18М описывает с удивитель ной ясностью опыт своей команды по координации работы большой разнородной rpyппbl пользователей. Весьма полезно почитать e1'o отчет и поучиться. Процесс ветвления и соеАинения Два аспекта команда выполняет лучше, чем один человек: "МОЗ1'овой штурм" и BЫ работку СО1'лашения (уреryлирование). Однако КО1'да 1'pynпa разделяется, произво дится MHo1'o документации. По этой причине ВЫ1'однее, если люди работают в полной rpyппe при поиске соrлашения или при "мозrовом штурме", а остальное pa бочее время  по двое или по трое. Ниже описан весь процесс. 1. Сформировать описание системной функции низкой точности: · СО1'ласовать описание использования в свободной форме (1'pyппa). · СО1'ласовать область действия и выявить путем "МОЗ1'ОВО1'о штурма" действующих лиц и цели (rруппа). · Разработать описания (раздельно). · Объединить описания (1'pyппa). 2. Сформировать представление высокой точности в виде вариантов использования: · Создать варианты использования методом "МОЗ1'ОВО1'о штурма" (rpynпa ). · СО1'ласовать форму варианта использования (1'pyппa). · Написать варианты использования (раздельно). · Просмотреть варианты использования (раздельно). · Просмотреть варианты использования (1'pyппa). Этап 1. Сформировать представление системной функции низкой точности Этап 1 выполняется за четыре цикла. ЦИКЛ 1.1. соrЛАСОВАТЬ СТИЛЬ ОПИСАНИЯ ИСПОЛЬЗОВАНИЯ (rРУППА). Чле ны команды вместе изучают описание (см. раздел 1.6). Каждый член команды пи шет один документ, возможно, все документы на одну тему. Затем 1'pyппa читает и обсуждает написанное, чтобы выработать общий ВЗ1'ляд на то, как должно ВЫ1'ля деть приличное описание, каков e1'o объем и какие подробности оно должно coдep жать. Это может занять несколько часов. В конце цикла команда получает конкретное представление о том, что проектируется (или e1'O части). ЦИКЛ 1.2. соrЛАСОВА ТЬ О&ЛАСТЬДЕЙСТВИЯ И ВЫЯВЮЬ ПУТЕМ "мозrовоrо ШТУРМА" ДЕЙСТВУЮЩИХ ЛИЦ И ЦЕЛИ (rРУППА). [руппа тратит столько времени, сколько нужно, для выявления общей цели, области действия и основных действующих лиц 
182 rлава 17 системы. Сотрудники составляют концептуальное изложение, список BBoдa/BЫBO да, диаrрамму области действия проектирования, список основных действующих лиц и участников, а также список важнейших начальных наборов целей пользова- телей. Каждый из этих элементов касается ДРУ1'их, поэтому обсуждение одно1'О влияет на восприятие ДРУ1'их. Таким образом, все элементы создаются одновремен- но. Если 1'руппа знает, что она собирается проектировать, это может занять от не- скольких часов до одно1'О дня. Если пока не знает, может потребоваться несколько дней. В ИТО1'е ДОСТИ1'ается СО1'ласие относительно предмета обсуждения, To1'O, что надо создавать и состава основных действующих лиц. ЦИКЛ 1.3. РАЗРАБОТ А ТЬ ОПИСАНИЯ (РАЗДЕЛЬНО). rpyппa разделяется, чтобы co здать описания использования для выбранных функций разрабатываемой системы. Члены 1'pyппbl работают индивидуально и потом обмениваются документами. Затем они предоставляют результаты на суд 1'руппы в полном составе. ЦИКЛ 1.4. ОБЪЕДИНИТЬ ОПИСАНИЯ (rРУППА). Команда собирается для обсужде- ния содержания (не стиля) описаний. Задается вопрос: "Это действительно пример To1'o, что мы хотим построить?" Может состояться еще одна дискуссия о природе системы и пройти еще один цикл создания описания, пока члены 1'pyппbl не решат, что описание отражает их ВЗ1'ляды на систему. В этот момент первая фаза работы завершается. rpyппa распола1'ает пакетом, который можно передать заказчикам. В этом пакете содержится эскиз (низкой точ ности) новой системы: · Концепция системы . Список To1'o, что лежит в функциональной области действия, области действия проектирования и вне их . Диаrрамма системы в ее окружении . Список ключевых основных действующих лиц . Список участников системы и их основных интересов . Список наиболее важных целей пользователей . Набор описаний (каждое менее, чем в полстраницы) Этап 1. Сформировать представпение высокой точности в виде вариантов ИСПОПЬЗ0вания Этап 2 выполняется за пять циклов. ЦИКЛ 1.1. "мозrовой ШТУРМ" С ЦЕЛЬЮ СОЗДАНИЯ ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ (rРУППА). В первом цикле создается более точный список вариантов использова- ния, которые следует написать. rpyппa использует облеrченные методы анализа, "МОЗ1'ово1'О штурма" и выявления всех основных действующих лиц, которые MOryт встретиться системе на протяжении ее жизненно1'О цикла. Затем 1'pyппa методом "МОЗ1'ово1'О штурма" создает список всех целей пользователей, которые только 
Роль вариантов использования в общем процессе 183 можно вообразить, для всех основных действующих лиц. Для этой работы 1'pyппa может разделиться на ПОД1'руппы. Полезная практика д.пя больших разнородных 1'pyпп  разделиться на рабочие 1'pyппbf по 3-5 человек. Обычно существует несколько предметных областей или 1'pyпп по интересам, знания которых необходимо объединить, чтобы рабочие 1'pyппbI имели по одному специалисту в каждой области. Каждая 1'pyппa обладает всеми не- обходимыми знаниями для решения задач, и каждый специалист имеет возможность высказаться. Небольшая 1'pyппa способна пРОДВИ1'аться быстрее, чем крупная. Раз- деление основной 1'pynпbl на несколько маленьких 1'pyпп означает, что за одно и тоже время охватывается большая область. Если полный список основных действующих лиц и целей пользователей строит- ся с помощью подrрупп, последние собираются снова для объединения результатов. Они производят rрупповой анализ, чтобы закончить и принять список. В конце пери ода 1'руппа имеет предварительный полный перечень вариантов использования YPOB ня цели пользователя, которые надо написать. Со временем они почти наверняка обнаружат новые цели пользователей. rруппа выпускает список основных действующих лиц и целей пользователей. В это время может состояться дополнительное обсуждение приоритетов разработки, oцe нок сложности, времени разработки и т.д. ЦИКЛ 1.1. соrЛАСОВА ТЬ ФОРМУ ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ (rРУППА). Этот цикл начинается с написания 1'руппой варианта использования. Можно писать ин- дивидуально, а потом сдать личные версии в rpynпy. Члены 1'pyппbl обсуждаютуро- вень и стиль изложения, шаблон, участников и интересы, минимальные 1'арантии и пр. По окончании сеанса 1'pynпa имеет начальную версию стандарта вариантов ис пользования. ЦИКЛ 1.3. НАПИСАТЬ ВАРИАНТЫ ИСПОЛЬЗОВАНИЯ (РАЗДЕЛЬНО). В этом цикле 1'pynпa реОР1'анизуется в подrруппы по специализации, возможно, по 2-4 человека на пОД1'руппу. Для каждой специализированной пОД1'руппы отбираются варианты использования. В течение нескольких дней или недель ПОД1'руппы пишут варианты использова- ния, индивидуально или в паре (я считаю, что БОJJьшее количество партнеров по со- зданию варианта использования неэффективно). Варианты использования циркули  руют внутри подrруппы для внесения комментариев и улучшений до тех пор, пока ва- риант не будет признан правильным. Затем они создают обобщенные варианты испо- льзования. Они почти наверняка расщепляют некоторые варианты использования, создают варианты использования уровня подфункции, добавляют основных действу ющих лиц, новые цели и т.д. Удобно иметь двух людей, связанных с каждым вариантом использования, даже если один назначен rлавным автором. Будет возникать MH01'o вопросов о бизнеспра вилах, Т.е. ЧТО является реальным требованием, а что  лишь пережитком прежних дней. Хорошо, если есть человек, KOToporo можно спросить о бизнесправилах. BTO рой специалист может осуществлять двойную проверку, чтобы убедиться, что детали 1'рафическо1'О интерфейса пользователя не просочились в описание и что цели нахо- дятся на правильных уровнях. 
184 rлава 17 ЦИКЛ 1.4. АНАЛИЗ ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ (РАЗДЕЛЬНО). Писатели пYCKa ют по KPYry черновики, электронные или написанные на бума1'е. Интересно, что бу мажный вариант имеет своеобразное преимущество: можно собрать комментарии каждоrо читателя, и автор за один редакторский проход варианта использования учтет все предложения. В одной 1'pyппe рассказывали, что коrда они пытались рабо тать с замечаниями в режиме реально1'О времени, им пришлось сделать HaMHo1'o бо- льше проходов  сначала редактируя текст, чтобы реализовать предложение одно1'О лица, затем аннулируя это изменение, чтобы учесть предложение дру1'О1'О. В любом случае, экспертная 1'pyппa должна проверить уровень цели вариантов испо льзования и бизнесправила внутри них. Авторы посылают варианты использования для просмотра и разработчику сис темы, и эксперту по ее использованию. Технический специалист удостоверяется, что вариант использования содержит достаточно подробностей для реализации (исклю чая описания данных и проект интерфейса пользователя). Эксперт по использованию убеждается, что все требования являются истинными и что бизнеспроцесс действи- тельно работает при таком поведении системы. ЦИКЛ 1.5. АНАЛИЗ ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ (rРУППА). Наконец, проводится 1'рупповой анализ, на котором присутствуют разработчики пp01'paMMHo1'o обеспе чения, эксперты по бизнесу, эксперты по использованию и разработчики интер- фейса пользователя. То, что происходит после To1'o, как создатели вариантов использования закончили свой лучший черновик, зависит от проекта, ero политики и механизма анализа. Писатели должны быть уверены, что ша1'И понятны, правиль- ны и достаточно детализированы для реализации. Это можно сделать с помощью официальных инеофициальных просмотров, просмотров пользователей или про смотров разработчика. Вариант использования ДОСТИ1'ает своей первой официальной базовой формы, коrда черновик прошел пользовательскую и техническую проверку. Теперь начинай- те разработку и изменяйте вариант использования только для исправления ошибок, а не для редактирования формулировок. Вы быстро почувствуете разницу между созданием черновика варианта ис пользования и e1'O завершением. Заканчивая вариант использования, писатели должны: . Назвать все условия расширения. · Продумать политику, связанную с обработкой ошибок. . Удостовериться, что интересы участников соблюдены. · Удостовериться, что все названия вариантов использования являются только действительными требованиями. . Обеспечить, чтобы каждый вариант использования был читабельнымдля поль зователей или экспертов по использованию и достаточно ясным, чтобы разра ботчики знали, что реализовывать. 
Роль вариантов использования в общем процессе 185 Время на разработку oAHoro варианта использования я считаю, что на черновик варианта использования требуется несколько часов, и несколько дней уйдет на продумывание обработки расширений. Одна rруппа из дe сяти человек выдала 140 кратких описаний вариантов использования за неделю (2,8 кратких описаний вариантов использования на человека в день) и затем потра  тила еще четыре недели, работая над ними и добавляя новые требования. Это YBe личило время на один вариант использования и связанные с ним расширения до двух рабочих недель. rруппа, работающая над разными проектами, затрачивала на один вариант использования в среднем 35 рабочих недель. Окончательные вари- анты использования были исключительно BbIcoKoro качества. Как СО3Аать варианты использования, работая с большими rруппами ИНО1'да приходится работать с большой разнородной 1'руппой экспертов, не вКJlЮ чающей технических специалистов. Это очень непросто. Ниже я при вожу выдерж ки из отчета, который написал Энди Краус о своем успешном опыте сеансов, облеrчающих создание вариантов использования. Было задействовано 25 различ- ных специалистов. Этот отчет был напечатан в Object Magaziпe'. . Эндн Краус ' Как создать варнанты нспопьзовання, работая с бопьшой разнородной непрофесснонапьной rруппой Не экономьте на оборудовании ДЛЯ про ведения конференций. Вы будете проводить на конференциях недели, и вам необходимо владеть оборудова нием во время сеансов... Мы столкну лись со значительными проблемами материальнотехническоrо обеспече ния, переходя во время конференции из одной комнаты в друrую. Вы не сможете создать правиль ные варианты использования при OT сутствии нужных для этоrо людей. Пусть лучше будет избыток людей и TO чек зрения, чем их недостаток... Люди, в чьих идеях и опыте мы нуждались, были аналитиками, служащими, дeTeK тивами, операторами ввода данных и управляющими из 23 отделов. Заранее не зная действующих лиц реальной сис темы, невозможно было предсказать, какие пользователи моrли понадобить ся на определенном сеансе,  настоя щая проблема, KorAa пытаешься co брать на KaKoeTO время столько лю дей. Проблему мы решили, устроив встречу "Вариант использования  вбрасывание" с представителями всех пользовательских сфер, на которой мы * Из Kraus, А., Use case Blue, Object Magazine, Мау 1996 (рр. 6365). SIGS Publications, New У ork. Перепечатка с разрешения. 
186 сообща определили предварительный rрафик будущих сеансов. Большим rpyппaM содействовать труднее, чем маленьким. Вам придется делать все, на что вы способны. В пер.- вую очередь будьте орrанизованными. Так как процесс развивался, мы вынуж дены были про водить сеансы с rpynna ми от 8 до 25 человек. Только с по мощью представителей различных спе циальностей мы избавили требования от нюансов, обусловленных различными подходами участников конференции. Не про водите на сеансе с пользо вателями более половины рабочеrо дня. Наши сеансы показали, что мы He правильно оценивали объем материа ла, который можно было охватить на сеансах, и (или) нашу способность об.- работать этот материал перед ceaHca ми и после них. Обрабатывать исход ный материал, добытый на сеансах, вам придется так же долrо, как и вытяrивать ero. Вам придется выполнять множест во рутинных орrанизационных опера ций, административной работы, работы по ппанированию и подrотовке к следу ющему сеансу во второй половине дня. Плывите в одной лодке с PYKO водством. Административное лицо вместе с руководителем проекта при сутствовало на различных стадиях про цесса сбора информации. Ответственные за архитектуру си стемы лица должны присутствовать во время работы над вариантом исполь зования. Архитектор участвует в про цессе разработки как эксперт... Эксперт по предмету обсуждения обеспечивает экспертизу предметной области, чтобы быстро начать процесс и по.ц.церживать ero продвижение. Присутствие на сеансах специа листов, поддерживающих приложе r лава 17 ние, которое должно быть заменено, поможет вам достиrнуть цели. В ceaH сах принимали участие представители орrанизаций и департамента информа-- ционных услуr. Они разъясняли преж ние требования относительно внешних интерфейсов и знакомили с историей данной системы. Никто не заменит подлинных пo льзователей, вовлеченных в процесс создания варианта использования. Мы были в состоянии обеспечить учас тие в сеансах настоящих служащих, аналитиков, исследователей, операто ров ввода данных и руководителей этих rpynn работников. Нужен секретарь. Важность быст- рой аккуратной записи трудно пере- оценить... У нас было несколько ceK ретарей, работавщих на ранних сеансах и доказавших свою бесценность... Показывайте все наработанные варианты использования, чтобы YCKO рить работу. Варианты использования разрабатывались в режиме вэаимодей стsия и записыsались орrанизатором на лекционном плакате и секретарем в текстовом редакторе. ЛеКЦJ.jонные nла-- каты затем раэвешивались на стенах комнаты, rAe проходила конференция. Хотя иметь дело с rромоздкими плака тами было неудобно, мы открыли в них несколько неожиданных достоинств. Мы развешивали варианты использова- ния не в порядке очередности. Как только появлялся новый вариант ис пользования, участники были вынуж дены изза неправильной последовате- льности про сматривать вариант исполь зования, разработанный ранее. Такая итерация, похоже, помоrала присутст- вующим лучше познакомиться с суще ствующими вариантами использования и быстрее разработать новые, которые 
Роль вариантов использования в общем процессе были подобны АРуrим вариантам испо льзования. Название работы не может быть действующим лицом. Нашим пользо вателям было крайне трудно воспри нять мдею, что роль действующеrо лица может отличаться от названия pa боты. В конце дискуссии мы составили пробный список действующих лиц, но присутствующих он не удовлетворил. Как мы моrли помочь им освоиться с ним Приложению все равно, кто вы такой; важно, какую шляпу вы носите. Поняв, что исполнение роли действую щеrо лица в компьютерной системе по хоже на "ношение шляпы", мы купили бейсбольные кепки и на каждой вышили I1МЯ действующеrо лица. На следую щем сеансе кепки были выложены в ряд на столе орrанизатора. Как только началась работа над вариантом исполь зования, орrанизатор взял кепку с Haд писью "Задающий вопросы" и надел ее на rолову, Результаты были весьма бла rоприятны. Пользователи поняли, что не имеет значения, как называется их работа. KorAa они используют систему, они носят определенную "шляпу" (иr рают определенную роль). Вы можете про пустить некоторых деikтвующнх лиц в первоначальном списке. Прошло уже нескольких недель работы над вариантами использования, KorAa мы (орrанизаторы) осознали, что варианты использования, связанные с контролем за пользователями системы, оказались пропущенными. Несмотря на все наши усилия обеспечить широкий ДJo1апазон участников, в сеансах не было никоrо из специалистов по контролю. Участники проекта не имели представ ления ни о каких контролирующих вари антах использования. 187 "Вариант использования для пo вседневной работы" [друrими слова ми, описание использования] cпo собствует успешному "мозrовому штурму" при создании вариантов ис пользования... Нашим пользователям недоставало контекста для вариантов использования, поэтому мы попросили мх описать (на очень высоком уровне) шаrм, которым они следуют, выполняя повседневные задачи, например, OCTa навливая процесс. В какон...либо точке описания этоrо шаrа должна использо ваться система, поэтому пользователи MorYT не обдумывать ее применение. Разработка вариантов использования повседневной деятельности на четвер тый день принесла урожай в 20 вариан тов использования. Не надейтесь получать варианты использования в больших количест вах. Как любая творческая деятель ность, процесс создания вариантов использования имеет подъемы и спады. Попытки торопить творческий процесс не приносят успеха. Будьте rOToBbI к пробуксовке; ис пользуйте ускорители процесса. Всплывающие подсказки и справочные тексты и (или) вопросительные знаки, относящиеся к применению разрабаты ваемой системы, оказались прекрасны ми ускорителями. Мы иноrда умыш ленно вводилм спорные темы и точки зрения в качестве возбудителей дискус сии. Мы обнаружили, что KorAa люди сталкиваются с точкой зрения, которую не MorYT разделить, они способны BЫ ражать собственное мнение быстрее и яснее. Создание вариантов использова ния  это общественная деятель ность. Чувства были задеты, идеи разrромлены, и участники сплотились 
188 против орrанизатора, только чтобы за щитить ero ПОЗАнее на том же сеансе. Несколько часов общения по окончании дискуссии сплачивали нас. В конце KOH цов, все мы были связаны, так как co брались, чтобы узнать мнение Apyr APyra и оказать Apyr APyry подцержку в решении общих заАач. Стандартные "дескрипторы" об леrчают процесс... СтаНАартные AeCK рипторы подцерживают атрибуты новой системы, раЗАеленные на HeCKO ЛЬ ко направлений. Такими направления ми являются, например, ЛЮАИ, АОЛЖНОСТИ, местонахождения. Наборы Аескрипторов обеспечили путь к нenро тиворечивому преАставлению инфор мации... Наборы были поименованы и rлава 17 каталоrизированы, чтобы их можно было использовать на сеансах обсуж Аения, а также при совершенствовании послеАУЮЩИХ вариантов использова ния. СтаНАартные обязанности системы и сценарии успеха и неуАачи позволили нам сконцентрироваться на исключите льных состояниях. Стройте, сопровождайте и пOKa зывайте список предположений и дo пущений. Во время опреАеленных перИОАОВ работы мы считали необходи мым начинать сеансы с прочтения АОПУ щений во избежание споров об уже рассмотренных моментах. Будьте минималистом. Сохраняй те свой шаблон варианта использования в минимальном объеме. 
rлава 18 Краткие описания вариантов использования и. экcmре.:мальное nроера.м.мирование (Extreme Prograттing, ХР) Экстремальное ПРО1'раммирование (ХР), использует еще более обле1'ченную фор му описания требований к поведению системы, чем методоло1'ИЯ, о которой идет речь в этой КНИ1'е (см. Extreme Programmiпg Explaiпed, Beck, 1999). СО1'ласно Ok ному из положений ХР, бизнесэксперты и эскперты по использованию действуют с разработчиками в одной команде. Поскольку они рядом, 1'руппа пишет не подроб ные требования к ПРО1'раммному обеспечению, а пользовательские рассказы (user stories), cBoe1'o рода обязательство для будуще1'О обсуждения требований части функциональных возможностей. Пользовательский рассказ ХР при своей сжатости может ВЫ1'лядеть либо как краткое описание варианта использования (см. таблицу 3.3), либо как функциона льная возможность системы (см. таблицу 17.2). Каждый пользовательский рассказ ХР необходимо существенно детализировать и для бизнесэкспертов, и для технических специалистов, чтобы они поняли e1'o смысл и оценили объем. Он должен быть небольшим произведением, чтобы разра ботчики мо1'ли осуществить e1'o проектирование, кодирование и тестирование, а TaK же подrотовить e1'o к использованию не более чем за три недели. Поскольку он удовлетворяет этим критериям, он может быть настолько сжатым и произвольным, насколько это устраивает 1'руппу. E1'o часто записывают на учетной карточке. КО1'да начинается работа над пользовательским рассказом, разработчик просто передает карточку бизнесэксперту и просит разъяснений, чтобы составить себе яс ную картину функциональных возможностей. В редких случаях небольшая команда разработчиков с пользователями, которые пребывают в 1'руппе в течение полно1'о рабоче1'О дня, применяет в качестве требова 
190 rлава 18 ний описания использования или краткие описания вариантов использования. Это возможно, только если владельцы требований находятся рядом с разработчиками си стемы. Разработчики сотрудничают непосредственно с владельцами требований в период проектирования системы. Как и в случае с пользовательскими рассказами ХР, это осуществимо, если удовлетворяются условия завершения обязательства. Бо льшинство проектов этим условиям не соответствует, и поэтому лучше Bcero pac сматривать описание использования как разминку в начале сеанса создания варианта использования, а краткое описание варианта использования  как часть обще1'О описания проекта. 
rлава 19 Распространенные ошибки Наиболее распространенные ошибки при создании вариантов использования co стоят в пропусках подлежащих в предложениях, попытках проектирования интер фейса пользователя и в слишком низком уровне используемых целей. Здесь приведены некоторые примеры этих ошибок. Цель этой rлавы не протестировать вас, а дать возможность потренироваться. В основном примеры короткие, а последний  длинный. Он взят из реально1'О проекта. Попрактикуйтесь сначала на небольших примерах. 19.1. Отсутствует система Первоначальный вариант Вариант использования: Снять наличные со счета Облает.. действия: банкомат Уровен,,: цель пользователя Основное действующее лицо: клиент 1. Клиент вводит карточку и PIN. 2. Клиент вводит "снять деньrи" и количество. 3. Клиент забирает наличные, карточку и квитанцию. 4. Клиент уходит. Замечания Этот вариант использования показывает все, что делает основное действующее лицо, но не отражает поведения системы. Просто удивительно, насколько часто люди пишут TaKo1'o рода варианты использования, создавая у читателя впечатле ние, что системе на самом деле не пришлось ниче1'О делать. 
192 rлава 19 Исправление состоит в указании всех действующих лиц и их действий. Исправпенный варнант Теперь вы сможете написать вариант использования для банкомата, даже если вас разбудить среди ночи. Варнант нспопьзовання: Снять напнчные со счета Облает.. действия: банкомат Уровен,,: цель пользователя Основное действующее лицо: владелец счета 1. Клиент пропускает карточку для банкомата через считывающее устройство. 2. Банкомат считывает с карточки 10 банка, номер счета, зашифрованный PIN, подтверждает 10 банка и номер счета с помощью rлавной банков ской системы. 3. Клиент вводит PIN. Банкомат сверяет ero с зашифрованным PIN, считан ным с карточки. 4. Клиент выбирает "быстрое снятие наличности" (Fast Cash) и указывает сумму в купюрах по $5. 5. Банкомат уведомляет rлавную банковскую систему о номере счета клиента, требуемой сумме и получает в ответ подтверждение и новый баланс. 6. Банкомат выдает деньrи, карточку и квитанцию, показывающую новый баланс. 7. Банкомат реrистрирует транзакцию. 19.2. Отсутствует основное Аействующее лицо Первоначапьный варнант Ниже приведен фра1'мент варианта использования Д,J1я извлечения дене1' из банкомата. Варнант нспопьзовання: Снять напнчные со счета Облает.. действия: банкомат Уровен,,: цель пользователя Основное действующее лицо: клиент 1. Получает карточку для банкомата, PIN. 2. Получает в качестве типа транзакции "снять деньrи". 3. Получает требуемую сумму. 
Распространенные ошибки 193 4. Удостоверяется, что на счете достаточно AeHer. 5. Выдает деньrи, Квитанцию, карточку. 6. Возвращается в исходное состояние. Замечания Этот вариант использования написан cTpo1'o с точки зрения системы. Он показыва  ет все, что делает банкомат, но НИче1'О не rоворит о поведении OCHoBHo1'o действую ще1'О лица. TaKo1'O рода текст трудно воспринимать, проверять и корректировать. В некоторых случаях критически важная информация о поведении действующе1'О лица опускается, вынуждая устанавливать очередность. Исправление однозначно: указать каждое действующее лицо и действие. Исправленный вариант То же, что в разделе 19.1. 19.3. Слишком MHoro деталей интерфейса пользователя Первоначальный вариант Вариант использования: Совершить покупку Обпаст.. действия: приложение для электронной торrовли Уровен,,: цель пользователя Основное действующее пицо: клиент 1. Система устанавливает экран для ввода ID и пароля. 2. Клиент вводит ID и пароль, щелкает по кнопке "ОК". 3. Система подтверждает ID и пароль, отображает персональные данные. 4. Клиент вводит имя и фамилию, номер дома, название улицы, ropoAa, штата, почтовый индекс, номер телефона и щелкает по кнопке "ОК". 5. Система подтверждает, что пользователь ей известен. 6. Система выводит список товаров, имеющихся в наличии. 7. Клиент щелкает по изображению товара, который хочет купить, вводит рядом с каждой картинкой количество, по окончании щелкает по кнопке 'тотово". 8. Система удостоверяется с помощью системы управления складами, что на складе есть достаточное количество требуемых товаров. ... и Т.д. Замечания Это, может быть, самая распространенная ошибка. Писатель слишком MHo1'o пи шет об интерфейсе пользователя, что делает вариант использования недокументом 
194 rлава 19 о требованиях как таковых, а скорее руководством для пользователя. Излишние подробности интерфейса пользователя ниче1'О не добавляют к сюжету. но затрудня - ют чтение и делают документ о требованиях неустойчивым к изменениям. Исправление состоит в том, чтобы найти способ описать намерения пользовате ля, не предла1'ая специально1'О решения. ИНО1'да это требует творческо1'О подхода к формулировкам. Исправленный вариант Вариант использования: Совершить покупку Область действия: приложение для электронной торrовли Уровень: цель пользователя Основное действующее лицо: клиент 1. Клиент реrистрируется в системе с помощью ID и пароля. 2. Система подтверждает ID и пароль пользователя. 3. Клиент вводит имя, адрес, номер телефона. 4. Система подтверждает, что пользователь ей известен. 5. Клиент указывает товар и ero количество. 6. Система удостоверяется с помощью системы управления складами, что на складе есть достаточное количество требуемых товаров. ... и Т.д. 19.4. Очень низкие уровни цели Первоначальный вариант Вариант использования: Совершить покупку Область действия: приложение для электронной торrовли Уровень: цель пользователя Основное действующее лицо: клиент (пользователь) 1. Пользователь реrистрируется в системе с помощью ID и пароля. 2. Система подтверждает ID и пароль. 3. Пользователь вводит имя. 4. Пользователь вводит адрес 5. Пользователь вводит номер телефона. 6. Пользователь указывает товар. 7. Пользователь указывает количество. 8. Система подтверждает, что пользователь ей известен. 9. Система подключается к системе управления складами. 10. Система запрашивает у складской системы текущие уровни запасов. 
Распространенные ошибки 195 11. Система управления складами возвращает текущие уровни запасов. 12. Система удостоверяется, что на складе есть достаточное количество требуемых товаров. ... и т .д. Замечания Ясно, что это будет длинный и нудный вариант использования. Мы не можем упрек нуть автора в том, что эти ша1'И описывают интерфейс пользователя слишком тща тельно, но нам определенно нужно сократить текст и прояснить, что происходит. Для сокращения текста: · Объедините элементы данных (шаrи 3 5) из разных ша1'ОВ. Установив, что по льзователь пытается обеспечить персональные данные, мы получим хорошее краткое имя для всех элементов информации об индивидууме, которые будут собираться. Я считаю, одно краткое имя слишком неопределенно, поэтому я указываю на список полей, который будет расширяться l'ДeTO в дру1'ОМ месте, не З8тра1'ивая этот вариант использования. . Сосредоточьте все данные, идущие в одном направлении, в одном ша1'е (ша1'И 37). Это не все1'да лучший способ. Бывает, что получение персональной ин формации существенно отличается от указания товара и количества, поэтому автор помещает их в разных строках. Дело вкуса. Я предпочитаю объединять все данные, идущие в одном направлении. Если это ВЫ1'лядит слишком 1'ромоз ДКО или для расширений необходимо, чтобы они были разделены, я их вновь разделяю. . Найдите более высокий уровень цели (ша1'И 8 11). Выясните, зачем система совершает все эти действия. Она пытается удостовериться при помощи систе мы управления складами, что на складе естьдостаточное количество требуемо 1'0 товара. Эта цель более BblcoKo1'o уровня и фиксирует требования так же ясно, но описание значительно сокращается. Исправленный вариант Вариант использования: Совершить покупку Облает.. действия: приложение электронной торrовли Уровен,,: цель пользователя Основное действующее лицо: клиент (пользователь) 1. Пользователь реrистрируется в системе с помощью ID '" пароля. 2. Система подтверждает ID и пароль пользователя. 3. Пользователь вводит персональные данные (имя, адрес, номер телефона), указывает товар и количество. 4. Система подтверждает, что пользователь ей известен. 5. Система удостоверяется при помощи системы управления складами, что на складе есть достаточное количество требуемоrо товара. ... и т.д. 
196 rлава 19 19.5. Цель и СОАержание не соответствуют АРУ' APyry Вспомните упражнение 7.4, в котором вы должны были исправить неверный вари ант использования Зарееистрироваться в системе. Если вы еще это1'о не сделали, найдите эти три ошибки: . Тело варианта использования не соответствует намерению, заявленному в Ha звании и описании. Практически это не менее двух сложенных вместе вариан тов использования. . Здесь описываются подробности интерфейса пользователя. . В тексте используются ЛО1'ические структуры ПРО1'раммирования, а не обычный язык. Если вы решили не утруждать себя, обратитесь к приложению В, в котором co держатся разбор и решение. 19.6. Развитый пример варианта использования с чрезмерной Аетализацией интерфейса пользователя Компания FirеРопd Соrроrаtiоп любезно позволила мне использовать следую щие примеры первоначальных и исправленных вариантов. Первоначальный вариант занимает несколько страниц, часть из которых ушла на основной сцена- рий и альтернативы. Исправленный вариант втрое короче. Он содержит ту же базовую информацию, но без усложняющих подробностей интерфейса пользо вателя. Внимательно прочитайте основной сценарий и подумайте, как сделать этот длинный вариант использования более читабельным, не жертвуя содержанием. Особенно обратите внимание на детали интерфейса пользователя, которые обнару живаются в тексте, а также на некоторые расширения. Я удалил некоторые из них, но оставил значительную часть, чтобы вы почувствовали, как трудно работать с Ta ким объемным вариантом использования. Как бы вы сократили e1'o? Несколько слов о названии варианта использования. Для языка маркеТИН1'а информационных техноло1'ИЙ считается недостаточным сказать, что покупатель BЫ бирает товар. Столкнувшись с множеством товаров, покупатель ищет решение для своей ситуации. Я Mo1' бы переименовать этот вариант использования в Выбрать товар, но это не моя привиле1'ИЯ. Название Найти решение считается правиль ным в среде, 1'де был написан и будет читаться этот вариант использования, поэто му оно остается. Приношу бла1'одарность Дэйву Скотту и Расселу Уолтерсу из FirePond Corpo- rаtiоп. 
Распространенные ошибки Первоначапьный вариант Вариант ИСПОПЬЗ0вания 36 . Найти решение (до)  197 Область действия: наша wеЬсистема Уровень: цель пользователя Основное действующее лицо: покупатель  потребитель или areHT, желающий исследовать товары, которые он Mor бы купить Основной сценарий: Действие действующеrо лица Реакция системь. 1. Этот вариант использования начи нается, KorAa покупатель посещает wеЬсайт электронной торrовпи. 2. Система может получить информа цию о типе покупатепя, посещающе ro wеЬсайт. З. Система запросит установление лич ности покупатепя, инициирует YCTa  новление личности . Если система не устанавливает личность сейчас, она должна быть установлена перед co хранением принятоrо решения. 4. Система предоставит покупателю следующие возможности: создать новое решение, восстановить coxpa ненное решение. 5. Покупатель выбирает "создать новое решение" . 6. Система задаст первый вопрос для определения потребностей и интере сов покупателя. 7. Покупатель может повторить добав ление к тележке выбранных товаров: 8. Пока имеются вопросы по определе нию потребностей и интересов: 9. Покупатель ответит на вопросы. 10. Система на основе предыдущих OTBe тов с помощью варьирующихся HOMe ров и типов вопросов запросит инфор мацию для определения потребно стей и интересов покупателя, вместе с тем предоставив ему дополнитель ную информацию о продукции, ее возможностях и преимуществах, а также сравнительные данные и цены. 11. Покупатель отвечает на последний вопрос. 12. Поспе последнеrо вопроса о потреб ностях и интересах система выведет рекомендации относительно продук товой линии и сопутствующую ин формацию, такую как данные о про дукции, возможности и преимущест ва, сравнительные данные и цены. 13. Покупатель выберет продуктовую пинию. 14. Система задаст первый вопрос для опредепения необходимой модели изделия. 
198 15. Пока имеются вопросы по определе нию рекомендаций относитепьно MO дели изделия: 16. Покупатель ответит на вопросы. rлава 19 17. Система будет задавать вопросы, за висящие от предшествующих OTBe тов, чтобы определить потребности и интересы покупателя относительно моделей издепий, вместе с тем пре доставив ему допопнительную ин формацию о продукции, ее возмож ностях и преимуществах, а также сравнительные данные и цены. 18. Покупатель отвечает на последний вопрос. 19. После последнеrо вопроса о необхо димой модели изделия система представит рекомендации по модепи издепия и соответствующую инфор мацию, такую как данные о продук ции, ее возможности и преимущест ва, сравнительные данные и цены. 20. Покупатепь выберет модель изделия. 21. Система определит стандартные Ba рианты модели изделия и затем за даст первый вопрос, чтобы опреде лить основные варианты изделия. 22. Пока имеются вопросы по определе нию рекомендаций относительно Ba рианта изделия: 23. Покупатель ответит на вопросы. 24. Система будет задавать вопросы, за висящие от предшествующих OTBe тов, чтобы определить потребности и интересы покупателя относительно основных вариантов изделия, вместе с тем предоставив ему дополнитель ную информацию о продукции, ее возможностях и преимуществах, а также сравнительные данные и цены. 25. Покупатель отвечает на последний вопрос. 26. После последнеrо вопроса о желате льном варианте изделия система представит пользователю выбранную модель и выбранные варианты для подтверждения. 27. Покупатель анализирует свой выбор товара, одобряет ero и решает дo бавить товар к своей тележке. 28. Система добавит выбранный товар и сопутствующую информацию (нави rационные данные и ответы) к тележ ке с товарами. 29. Система представпяет обзор тележ ки и всех товаров в ней. 30. Конец повторяющихся шаrов для Te 31. лежки с товарами. 32. Покупатель пошлет запрос на персо нальное предложение относительно товаров своей тележки. 33. Система задаст первый вопрос, что бы определить, какое содержимое тележки следует использовать для персональноrо предложения. 
Распространенные ошибки 34. Пока имеются вопросы по определе нию содержимо,-о тележки для пер сональноrо предложения: 35. Покупатель ответит на вопросы. 199 36. Система будет задавать покупателю вопросы, зависящие от предшеству ющих ответов, чтобы определить co держимое тепежки для персональ Horo предложения, вместе с тем предоставив ему дополнительную информацию о продукции, ее воз можностях и преимуществах, а TaK же сравнительные данные и цены. 37. Покупатель отвечает на последний вопрос. 39. Покупатель рассмотрит предложе ние и решит ero распечатать. 38. После ответа на последний вопрос о содержимом тележки для персона льноrо предложения система сфор мирует и представит персональное предложение. 40. Система распечатает предложение. 41. Покупатель запросит сохранение cBoero решения. 44. Покупатель введет идентификацион ную информацию по решению и co хранит решение. 42. Если личность покупателя еще не установлена, инициируется YCTaHOB ление личности. 43. Система запросит пользоватепя об идентификационной информации по решению. 45. Система сохранит решение и свяжет ero с покупателем. Расширения: *а. В любой точке в процессе выполнения Bapl4aHTa использования Принять решение, если покупатель не выполняет никаких Аействий в течение заранее опреАеленноrо перИОАа простоя, система увеАОМИТ ero об отсутствии активности испросит, не хочет ли он ПРОАОЛЖИТЬ работу. Если покупатель не отвечает в течение разумноrо промежутка BpeMe ни (30 с), вариант использования прекращает работу. В противном случае покупатель ПРОАОЛЖИТ работу. *Ь. В любой точке серии вопросов и ответов покупатель может вернуться к любому вопросу, изменить свой ответ и ПРОАОЛЖИТЬ серию. *с. В любой точке после преАставления рекомеНАации по товару покупа тель может посмотреть результаты расчета характеристик, чтобы опреАелить, насколько они соответствуют ero потребностям. Система выполнит расчет и преАставит покупателю Аанные. Покупатель про АОЛЖИТ процесс поиска решения с той точки, rAe ero оставил. *d. В любой точке серии вопросов и ответов система может взаИМОАейство вать с системой инвентаризации запасных частей, чтобы получить инфор мацию о наличии запасных частей и (или) с системой технолоrической подrотовки ПРОИЗВОАства, чтобы получить перечень комплектующих. С помощью Аанных о наличии запасных частей и перечня можно отфиль 
)Q rлава 19 тровать представленную информацию о выборе товара или показать Ha личие запасных частей покупателю во время процесса поиска решения. Инициировать варианты использования Получение данных о наличии за пасных частей и Получить перечень комплектующих. *е. В любой точке серии вопросов и ответов система представляет COOT ветствующую информацию о производственных каналах для запасных частей. Покупатель выбирает канал. Система может передать по это му каналу связанную с товаром или друrую информацию для наилуч шеrо размещения или представить подходящее содержимое. Завер шив работу с промышленным wеЬсайтом, покупатель возвратится к точке, откуда ушел, возможно, с возвращением требований к товару, которые система будет подтверждать. Инициировать обзорную ин формацию по товару. *f. В любой точке процесса поиска покупатель может выдать запрос на соединение: вариант использования Инициировать запрос на соединение. *g. В любой точке серии вопросов и ответов система может установить точки триrrера фиксации данных о рынке, в которых система будет реrистрировать навиrационные данные, информацию о выборе TOBa ра, а также вопросы и ответы, которые будут использованы вне этой системы для анализа рынка. *h. В заранее определенной точке поиска система может сформировать директиву для фиксации данных, накопленных к этому моменту. Вари ант использования Инициировать формирование директивы. *i. В любой точке покупатель может выйти из приложения электронной Торrовли: Если было найдено новое решение или изменено текущее с момента последнеrо сохранения, система спросит покупателя, не xo чет ли он сохранить решение. Инициировать Сохранить решение. *j. В любой точке после нахождения HOBoro решения или изменения TeKY щеrо покупатель может запросить сохранение решения. Инициировать Сохранить решение. 1а. Покупатель посещал wеЬсайт производителя товара и установил Tpe бования к изделию. Web--сайт производителя позволяет выбрасывать на рынок новые товары в эту систему электронной торrовли для даЛIr нейшеrо поиска решения: 1 а 1. Покупатель входит в систем у электронной торrовЛИ с требования ми к товару и, может быть, данными по идентификации. 1а2. Система получает требования к товару и, возможно, данные по идентификации пользователя. 1а3. Система проверит, в какой точке процесса поиска находится по купатель, и установит стартовую точку серии вопросов для про должения процесса поиска. 1 а4. Основываясь на установленной стартовой точке, мы можем про должать с шаrа 5, 12 или 18. 3а. Покупатель хочет работать с ранее сохраненным решением: 3а1. Покупатель выбирает восстановление решения. . 
)аспространенные ошибки 201 3а2. Система представляет список сохраненных решений этоrо поку пателя. 3а3. Покупатель выбирает решение, с которым будет работать. 3а4. Система восстанавливает выбранное решение. 3а5. Продолжать с шаrа 26. 23а. Покупатель хочет изменить некоторые рекомендованные варианты: {Создать вариант использования Выбрать вариант, поскольку сущест вуют альтернативы основному потоку. Систему можно установить так, чтобы показывать все варианты, даже несовместимые. Если покупа тель выбирает несовместимый вариант, система выведет сообщение об этом и, может быть, указание, как получить товар, сконфиrури рованный так, чтобы вариант был совместимым.} ... пока покупате лю необходимо изменить вариант: 23а1. Покупатель выбирает вариант, который желает изменить. 23а2. Система представляет имеющиеся совместимые варианты. 23а3. Покупатель выбирает желаемый вариант. 26а. Покупатель хочет изменить количество выбранных товаров в тележке для покупок: 26а1. Покупатель выбирает продукт из тележки и изменяет ero коли чество. 26а2. Система пересчитает цену, учитывая скидки, налоrи, сборы и специальные цены, основываясь на информации о покупателе, а также на ответах на вопросы. 26Ь. Покупатель хочет добавить к тележке встречную продажу товара: 26Ь 1. См. раздел Встречная продажа. 26с. Покупатель хочет вызвать сохраненное решение: 26с1. Система представляет список сохраненных решений AaHHoro покупателя. 26с2. Покупатель выбирает решение, с которым будет работать. 26с3. Система восстанавливает указанное решение. 26с4. Продолжать с шаrа 26. 26d. Покупатель хочет заплатить за продукты в тележке для покупок с помощью имеющихся финансовых планов: 26d 1. Покупатель выбирает финансирование продуктов в тележке. 26d2. Система задаст ряд вопросов, зависящих от предшествующих ответов, чтобы определить рекомендации по финансовому плану. Система взаимодействует с финансовой системой, что бы получить подтверждение кредитоспособности. Иницииро вать оценку кредитоспособности. 26d3. Покупатель выберет финансовый план. 26d4. Система задаст ряд вопросов, зависящих от предшествующих ответов, чтобы определить подробности выбранноrо финансо Boro плана. 
202 rлава 19 26d5. Покупатель рассмотрит подробности финансовоrо плана и pe шит следовать ем у. 26d6. Система разместит заказ на финансовый план с помощью фи нансовой системы. Инициировать размещение финансовоrо заказа. Замечания В данном случае был выбран формат в две колонки, чтобы разделить шаrи действу- ющих лиц. Авторы не представляли себе отчетливо проекта интерфейса пользова- теля, кроме модели вопрос/ответ, поэтому описали вопросы и ответы в варианте использования. С caMoro начала я избавился от формата в две колонки и создал простое повест- вование в одну колонку. Я хотел, чтобы сюжетная линия хорошо просматривалась и для этоrо не надо было переворачивать страницы. Просматривая результат, я искал предположения относительно проектирования интерфейса пользователя, а также цели, уровень которых можно было бы повысить. Ключ содержится в предложении "Система задаст вопросы, число и тип которых бу- дут изменяться в зависимости от предшествующих ответов". Здесь не упоминается чтолибо столь же очевидное, как щелчки мышью, поэтому предполаrается интер фейс, основанный именно на том, что пользователь набирает на клавиатуре ответы на вопросы. Я хотел представить совершенно ДРУ1'ой интерфейс, чтобы посмотреть, как это повлияет на текст варианта использования. Я имел в виду проект, в котором пользователь только щелкал бы по картинкам. Torдa можно было бы уловить HaMe рения пользователя и устранить зависимость от пользовательско1'О интерфейса. Это тоже послужило сокращению документа. В каждом предложении я перепроверял уровень цели, чтобы понять, не слиш- ком ли низок уровень цели ша1'а и можно ли e1'o повысить в таком случае. В начале этой работы я не был уверен, что формат в одну колонку будет ясно по- казывать разработчикам обязанности системы. Авторы первоначальноrо варианта рассеяли мои сомнения. Практически они были довольны, так как: . Документ стал короче и удобнее для чтения. . Все действительные требования в документе сохранились и остались ясно вы- деленными. . Проект расширил 1'раницы. Исправnенный вариант Вариант испоnьзования 37 . Найти возможные решения (nocne)  Обпасть действия: wеЬсистема nporpaMMHoro обеспечения Уровень: цель пользователя Предусповия: нет 
Распространенные ошибки 203 Минимаnьная rарантия: нет Аействия, нет покупок rарантия успеха: покупатель имеет ноль или более товаров, ПОАrотовлен ных к покупке, в системе есть журнал реrистрации выбора и навиrацион ных Аанных, записаны также характеристики польэователя. Основное действующее nицо: покупатель (любой путешествующий по Сети) Триrrер: покупатель собрался найти решение. Основной сценарий: 1. Покупатель инициирует поиск HOBoro решения. 2. Система nOMoraeT покупателю выбрать ПРОАУКТОВУЮ линию, МОАель и ее варианты, преАставляя ему информацию и заАавая серии вопросов для опреАеления потребностей и интересов покупателя. Серии вопро сов и ВЫВОАимая на экран информация зависят от ответов, которые по купатель Аает по ХОАУ Аела. Система выбирает их в соответствии с за проrраммированными путями выбора, чтобы ВЫАелить и peKOMeHAO вать то, что, вероятно, заинтересует покупателя. ПреАставляемая ин формация СОАержит Аанные о ПРОИЗВОАстве, возможностях, преиму ществах, сравнительных Аанных и т .А. 3. Система реrистрирует навиrационную информацию в ХОАе процесса. 4. Покупатель выбирает окончательную конфиrурацию товара. 5. Покупатель Аобавляет ero к тележке. 6. Система Аобавляет к тележке для покупок выбранный товар и навиrа ционную информацию. 7. Система ВЫВОАИТ на экран обзор тележки для покупок со всем ее co Аержимым. Покупатель повторяет преАЫАущие шаrи столько раз, CKO лько пожелает, чтобы Аобраться АО различных специализированных TO варов '" выбрать их, по желанию Аобавляя к тележке. Расширения: *а. В любой момент покупатель может запросить соеАинение. 1а. По соrлашению между влаАельцем wеЬсайта и владельцем посылаю щеrо запрос компьютера в запросе может СОАержаться информация о типе покупателя: 1 а 1. Система ВЫАеляет из wеЬзапроса любую пользовательскую и Ha виrационную информацию, Аобавляет ее к Аанным реrистрации и начинает с некоторой точки в rлубине серии вопросов и ответов. 1а1а. Информация, ПРИХОАящая с Apyroro сайта, неверна или не понятна. Система Аелает максимум возможноrо, реrистри рует всю поступившую информацию и по возможности ПРОАолжает. 1Ь. Покупатель желает ПРОАОЛЖИТЬ работу наА прежним сохраненным He полным решением. 1 Ь 1. Покупатель устанавливает личность и сохраняет решение. 1Ы. Система восстанавливает решение и возвращает покупателя ТУАа, rAe он остановился, переА тем как сохранить решение. 2а. Покупатель решает обойти ОАНУ или все серии вопросов: 
204 rлава 19 2а 1. Покупателю преАоставляются рекомеНАации по товару на основе оrраниченных (или нет) персональных характеристик, и он Аелает выбор. 2а2. Система реrистрирует зтот выбор. 2Ь. В любон момент переА Аобавлением товара к тележке покупатель MO жет вернуться и изменить любон преАЫАУЩИН ответ, чтобы получить новые рекомеНАации по товару и (или) новую возможность выбора. 2с. В любон момент переА Аобавлением товара к тележке покупатель MO жет запросить расчет по имеющемуся тесту (характеристики), напри мер, потянет ли Аанная конфиrурация с этим весом на тренлер: Систе ма ПРОИЗВОАИТ вычисления и ВЫВОАИТ ответ. 2d. Покупатель ПРОХОАИТ точку, которую влаАелец webcaHTa преАварите льно опреАелил для формирования Аиректив по ПРОАажам (Аинамиче ское бизнесправило): Система формирует Аирективу по ПРОАажам. 2е. Система установлена для запроса у покупателя УАостоверения лично сти: Покупатель устанавливает личность. 2f. Система установлена для взаИМОАенствия с Аруrими известными систе мами (инвентаризации запасных частен, технолоrическон ПОАrотовки ПРОИЗВОАства), которое повлияет на наличие и выбор товара: 2f1. Система взаИМОАенствует с Аруrими известными системами (ин вентаризации запасных частен, технолоrической ПОАrотовки произ ВОАства), чтобы получить неоБХОАИМУЮ информацию. (Получить Аанные о наличии запасных частен, Получить перечень комплекту ющих. ) 2f2. Система использует результаты для фильтрации или показа AaH ных о наличии товара и (или) вариантов (запасных частен). 29. Покупатель выбирает канал из преАставленноrо множества каналов к webcaHTaM прОИЗВОАителей: Покупатель просматривает APyroH webcaHT . 2h. Система устанавливается для взаИМОАействия с известнон информаци оннон системон заказчика: 2h 1. Система получает информацию Аля заказчика от информацион ной системы для заказчиков. 2h2. Система использует результаты, чтобы начать с некоторой точки внутри серии вопросов и ответов. 2i. Покупатель хочет узнать оценку креАитоспособности, поскольку она повлияет на процесс выбора товара: Покупатель получает оценку Kpe Аитоспособности. 2j. Покупатель указывает, что он купил товар преЖАе, и система YCTaHaB ливается для взаИМОАенствия с известной системон финансовоrо учета. 2j1. Система получает послеАовательность выставления счетов. 2j2. Система использует послеАовательность выставления счетов поку пателя, чтобы повлиять на процесс выбора товара. 2k. Покупатель решает изменить некоторые из рекомеНАованных вариан тов: Система позволяет покупателю изменить столько вариантов, CKO 
)аспространенные ошибки 205 лько он пожелает, по ХОАУ Аела ВЫВОАЯ на экран Аанные о АОПУСТИМЫХ вариантах и преАупреЖАая о несовместимости Аруrих вариантов. 5а. Покупатель решает не Аобавлять товар к тележке для покупок: Систе ма оставляет навиrационную информацию на БУАущее. 7а. Покупатель хочет изменить СОАержимое тележки для покупок: Систе ма позволяет покупателю изменить количество, УАалить элементы или вернуться к более ранней точке в процессе выбора. 7Ь. Покупатель просит сохранить СОАержимое тележки для покупок: 7Ь 1. Система запрашивает у покупателя имя и ID для сохранения и co храняет СОАержимое. 7Ь1а. Личность покупателя не установлена: Покупатель YCTaHaB ливает личность. 7с. Покупатель имеет товар для встречной ПРОАажи: Система фиксирует встречную ПРОАажу. 7d. Покупатель решает оплатить товары в тележке: Покупатель получает финансовый план. 7е. Покупатель ВЫХОАИТ из системы электронной торrовли, KorAa тележка для покупок не сохранена: 7 е 1. Система запрашивает у покупателя имя и ID Аля сохранения и co храняет СОАержимое тележки. 7е1а. Покупатель решает выйти без сохранения: Система реrист рирует навиrационные Аанные и завершает сеанс с покупа телем. 7f. Покупатель выбирает элемент из тележки для покупок, чтобы узнать о наличии соответствующеrо товара (HoBoro или используемоrо) от сис темы инвентаризации. 7f1. Покупатель ВЫАает запрос локализовать соответствующий товар в системе инвентаризации. 7f2. Покупатель заменяет элемент в тележке для покупок COOTBeTCT вующим товаром из системы инвентаризации. 7f2a. Покупатель не хочет ПРИВОАИТЬ товар в соответствие с эле ментом из системы инвентаризации: Система оставляет в тележке для покупок первоначальный элемент, которым интересовался покупатель, самостояте льно ПРИВОАЯ ero в соответствие с элементом из системы инвентаризации. 7fЗ. Система rарантирует, что в тележке для покупок СОАержится ОАИН элемент, сконфиrурированный в соответствии с элементом из системы инвентаризации. Вызывающие варианты испопьзования: Интернетмаrазин. Пропажа свя занных проnуктов Открытые вопросы: Расширение 2с. Какие вопросы законны? Какие еще системы заАействова ны? Каковы требования к интерфейсам? 
Часть 3 Памяткu для занятых 
{АОВО 20 Памятки для каждоzо варианта использования Памятка 1. Вариант использования  прозаическое эссе Как сказано в предисловии, создание вариантов использования можно сравнить с написанием прозаическо1'О эссе, 1'де необходимы четкие формулировки, которые свойственны письменной прозе. Рассел Уолтерс из компании FirePond написал: Я думаю, вышеприведенное утверждение точно отражает суть вопроса. Это проблема еще не получила нужной оценки. Для автора вариантов использо вания изучить этот вопрос необходимо. Однако я не уверен, что практикант может самостоятельно освоить данную тему, по крайней мере пока не про чтетэтукниry. Я не считал этупроблеМУ1'лавной и работал с концепцией Ba риантов использования четыре 1'ода, пока не появилась возможность сотрудничать с вами. И даже Torдa все оставалось попрежнему, пока я не проанализировал первоначальные и исправленные версии варианта испо льзования 36. Единственное, на что придется читателям этой книrи затра тить усилие,  это осознать, что основной проблемой является создание эффективных вариантов использования. (Печатается с разрешения.) Эта памятка поможет вам сосредоточиться на тексте, а не на схемах, и прини мать к сведению стили изложения, с которыми вы будете встречаться. Памятка 2. Старайтесь, чтобы вариант использования был читабельным Ваш документ о требованиях должен быть коротким, ясным и читабельным. Я ИНО1'да чувствую себя учителем словесности в восьмом классе, который ходит тудасюда и 1'оворит: 
210 rлава 20 Используйте 1'ла1'ОЛЫ действия в настоящем времени. Употребляйте дейст вительный зало1', а не страдательный. rде в предложении подлежащее? ro ворите о том, что действительно является требованием; не упоминайте то, что таковым не является. Следующие рекомендации помоryт вам сделать ваш докуменр о требованиях KO ротким, четким и ле1'КИМ для чтения: 1. Старайтесь писать короче и ближе к делу. Длинные варианты использования ведут к длинному описанию требований, которое мало кому нравится читать. 2. Начните с вершины и создайте ЛО1'ически последовательный сюжет. На вершине будет страте1'ический вариант использования. От He1'o будут ветвиться варианты использования уровня цели пользователя и, в конечном счете, уровня подфункции. 3. Именуйте варианты использования с помощью коротких 1'ла1'ОЛЬНЫХ конструкций, объявляющих цель, которая должна быть ДОСТИ1'нута. 4. Начинайте с ТрИ1'1'ера и продолжайте, пока цель не будет ДОСТИ1'нута или oTBep1'HYTa и система не заре1'истрирует необходимую информацию о транзакциях. 5. Используйте полные предложения с 1'ла1'ОЛЬНЫМИ конструкциями, которые описывают подлежащие выполнению подцели. 6. Обеспечьте, чтобы на каждом ша1'е действующее лицо и e1'o намерение были четко определены. 7. Вьщеляйте условия отказа и старайтесь, чтобы действия по восстановлению были удобочитаемыми. Должно быть ясно, что происходит потом, чтобы даже не пришлось указывать номера ша1'ОВ. 8. Для описания альтернативно1'О поведения применяйте расширения, а не предложения с если в теле 1'лавно1'О варианта использования. 9. Создавайте варианты использования расширения только в особых случаях. Памятка 3. Только ОАна форма преможения Существует только одна форма предложения, используемая для описания ша1'ОВ действия: . Предложение в настоящем времени . С 1'ла1'ОЛОМ действия в действительном заЛО1'е . Описывающее, как действующее лицо успеШНОДОСТИ1'ает цели, ПрОДВИ1'ающей весь процесс 
Памятки ДЛЯ каждоro варианта использования 211 Примеры: Клиент вводит карточку и PIN. Система удостоверяется в полномочиях клиента и достаточности остатка на счете. PAF (персональный консультант по финансам) перехватывает ответы с wеЬсайта и обновляет портфель пользователя. Служащий находит заявление об ущербе с помощью деталей поиска заявления об ущербе. Употребляйте такие предложения в вариантах использования для бизнеса, сис- темных, обобщенных, а также вариантах использования уровня подфункции, напи ,санных как по полной форме, так и произвольно. Это относится И к основному сценарию, и к фра1'ментам сценария расширения. Овладейте этим стилем. В блоках условий в расширеииях должна быть дрyrая 1'рамматическая форма, чтобы не путать расширение с ша1'ами действий. Лучше (но не Bce1'дa) использовать фра1'мент предложения (или, может быть, полное предложение) в прошедшем вре- мени. В конце условия ставьте двоеточие (:), а не точку. Таймаут ожидания ввода PIN: Неверный пароль: Файл не найден: Пользователь вышел, не закончив: Представленные данные не полны: Памятка 4. "Включайте" поАчиненныe варианты использования Абсолютно естественное действие (если никто не велел вам сделать по- дрУ1'ому)  написать ша1', который вызывал бы цель более НИЗКО1'о уровня или вариант исполь- зования: Служащий находит заявление об ущербе с помощью параметров поиска ущерба. В терминах UML ВЫЗЫвающий вариант использования просто включал бы под- чиненный вариант использования. Это столь очевидно, что не стоило бы упоминания, если бы не находились последователи применения связей расширения и специализа  ций UML (см. приложение А). В качестве перво1'О практическо1'О приема все1'да применяйте между вариантами использования связь включения (includes). В этом случае затруднений с документам будет меньше, чем с документами, в которых смешаны связи ВКJIючения со связям.и расширения (extends) и специализациям.и (specia1izes). См. раздел 10.2. Памятка 5. Кто влаАеет мячом? ИНО1'да пишут, используя страдательный зало1', или с точки зрения самой системы, смотрящей на мир. ТО1'да и получаются такие предложения, как "Вводится кредит- ный лимит". В этом предложении не упомянут тот, кто осуществляет ввод. 
212 rлава 20 Пишите как бы с высоты птичье1'О полета, наблюдая за сценой и описывая ее, либо пишите в форме пьесы, объявляя, какое действующее лицо собирается дейст вовать. Или представьте, что вы комментируете футбольный матч, в котором дейст вующее лицо 1 владеет мячом, ведет e1'o, далее следует передача иrроку 2; и1'рОК 2 пасует и1'РОКУ 3 и т.д. Пусть первое или второе слово пред,IIожения будет именем действующе1'О лица, совершающе1'О действие. Позаботьтесь о том, чтобы при всех обстоятельствах было ясно, кто владеет мячом. Памятка 6. Уровень цели Аолжен быть правильным · См. раздел 5.5, rдe вопрос обсуждается подробно. . Удостоверьтесь, что д,lIЯ варианта использования указан правильный уровень цели: обобщенный, пользователя или подфункции. . Периодически проверяйте, знаете ли вы, 1'де "уровень моря" Д,lIЯ ваших целей и насколько ниже (или выше) уровня моря находятся ша1'И. Напомним тесты Д,lIЯ цели уровня моря:  Цели добивается одно лицо в одном месте в одно время (220 мин).  Действующее лицо может уйти удовлетворенным, как только цель будет ДОСТИ1'нута.  Добившись МНО1'их целей, действующее лицо (если работает по найму) может попросить повышения. . Помните, что большинство вариантов использования имеет 39 ша1'ОВ в OCHOB ном сценарии, и уровень цели ша1'а обычно ниже уровня цели варианта исполь зования. Если в варианте использования более девяти ша1'ОВ, поищите шаrи, которые можно объединить, например: Если одно и то же действующее лицо "владеет мячом" на протяжении нескольких ша1'ОВ подряд. Если описаны движения пользователя  типичное описание интерфейса пользователя, нарушающее правило 5 (см. раздел 7.2). Если MH01'O простых передач между двумя действующими лицами (спросите, не пытаются ли они на самом деле совершить чтонибудь одним уровнем выше с помощью этих передач). · Поинтересуйтесь, почему пользователь (действующее лицо ) делает это. Ответ, который вы получите  это более высокий уровень цели. Вам, возможно, yдa стся с помощью этой цели объединить несколько ша1'ОВ. На рис. 20.1 показано, как цели ша1'ОВ размещаются внутри целей вариантов использования на раз личных уровнях. Спросите "почему", чтобы сдвинуть уровни 
Памятки ДЛЯ каждоrо варианта использования 213 Цель варианта использования I  Цель шаrов : Рис. 5.2. Спросите и почему', чтобы изменить уровни Памятка 7. Не Аопускайте Аеталей rрафическоrо интерфейса пользователя в варианте использования Убедитесь, что ша1', который вы только что описали, фиксирует истинное HaMepe ние действующе1'О лица, а не просто движения в рамках интерфейса пользователя. Этот совет применим, КО1'да вы пишете функциональные требования, так как ясно, что вы можете создавать варианты использования, чтобы документировать и сам интерфейс пользователя. Описывать движения пользователя при манипулировании интерфейсом в дoкy менте о требованиях не следует, так как: . Документ становится излишне длинным. . Требования становятся неустойчивыми в том смысле, что небольшие измене ния в проекте интерфейса вызывают изменение в "требованиях" (которые всетаки не были в чистом виде требованиями). . Это задача разработчика интерфейса пользователя, которому выдолжныдове рять как специалисту. Варианты использования в этой КНИ1'е по большей части должны служить вам хорошими примерами. Вот вьщержка из ОДНО1'О из них, варианта использования 20: 1. Оценщик просматривает и оценивает отчеты ... 2. Оценщик оценивает постоянную неплатежеспособность, используя '" 3. Оценщик определяет сумму долrа ... 4. Оценщик определяет окончательный диапазон суммы возмещения. Следующие ша1'И написаны неправильно: 
214 rлава 20 1. Система устанавливает зкран Login (реrистрацин) с полями ДЛЯ имени и пароля пользователя. 2. Пользователь вводит имя и пароль и щелкает по кнопке "ОК" . 3. Система проверяет имя и пароль. 4. Система устанавливает основной (main) экран, содержащий меню функций. 5. Пользователь выбирает функцию и щелкает по кнопке "ОК" . Очень ле1'КО незаметно перейти к описанию подробностей интерфейса ПОЛЬ30ва теля, поэтому будьте настороже. памятка 8. Ава итоrа Каждый вариант использования имеет два возможных ИТО1'а: успех и неудачу. Имейте в виду, что ша1' действия вызывает подчиненный вариант использова ния, последний может завершиться успехом либо неудачей. Если он из расширения, опишите обработку как успеха, так и неудачи в том же расширении (см., например, вариант использования 22). На самом деле у вас есть две обязанности по отношению к успеху или неудаче в достижении цели. Вопервых, убеднтесь, что вы имеете дело снеудачей каждо1'О BЫ зываемо1'О варианта использования. BOBTOpЫX, обеспечьте, чтобы ваш вариант ис пользования удовлетворял интересам каждо1'О участника, особенно если цель не ДОСТИ1'ается. памятка 9. Участникам необхОАИМЫ raрантии Вариант использования содержит не только явные взаимодействия основноrодей ствующе1'О лица и системы. Если бы он включал только это, то представлял бы не приемлемые требования к поведению, а лишь описание интерфейса пользователя. Система подталкивает к СО1'лашению между участниками. Один из них является основным действующим лицом, ДРУ1'ие отсутствуют и не MOryт себя защитить. Вари ант использования описывает, как система защищает все их интересы в различных обстоятельствах, КО1'да пользователь управляет сценарием. Вариант использования описывает 1'арантии, которые им обеспечивает система. Назовите всех участников с их интересами в каждом варианте использования. Найдите от двух до пятерых участников: основное действующее лицо, владельца, ка  коелибо руководящее ведомство и КО1'онибудь еще. Возможно, персонал по тести рованию или сопровождению заинтересован в функционировании дaHHo1'o варианта использования. Обычно одни и те же участники задействованы в большинстве вариантов испо льзования, и, как правило, их интересы во всех вариантах использования одннаковы. Поэтому нетрудно перечислить их имена и интересы. Об интересах можно сказать следующее: . Интерес OCHoBHo1'o действующе1'О лица сформулирован в названии варианта использования. Он обычно состоит в том, чтобы что-то получить. 
Памsпки для каждоrо варианта использования 215 . Интерес компании, как правило, состоит в том, чтобы основное действующее лицо не получило чтолибо бесплатно или заплатило за то, что получило. · Интерес руководяще1'О ведомства обычно состоит в том, чтобы удостовериться, что компания следует правилам и реrистрирует соответствуюшую информацию. . Один из участников обычно заинтересован в восстановлении после отказа по среди транзакции, Т.е. в новой ре1'истрации. Следите, чтобы основной сценарий и e1'o расширения обращались к интересам участников. Это совсем не трудно. Прочитайте текст варианта использования, начи ная с OCHoBHo1'o сценария, и посмотрите, присутствуют ли эти интересы. Вы будете удивлены, увидев, как часто они опускаются. Очень часто автор не учитывает, что ошибка может произойти в середине OCHoBHo1'O сценария, и не оставляет ни записи об этом, ни данных д,lIЯ восстановления. Проверьте, во всех ли случаях обработка ошибки защищает все интересы всех участников. Часто новое условие расширения обнаруживает в основном сценарии пропу щенное подтверхщение. ИНО1'да выполняется так MHo1'o подтверхщений, что автор помещает множество проверок в отдельную область документа, возможно, даже co здавая раздел бизнесправил. Пит МакБрин из компании Roshi рассказал мне о том, как e1'o 1'руппа в первый раз составила список интересов участников д,lIЯ системы, которую они уже разрабо тали. В этом списке они нашли все запросы на изменения, поступившие в течение перво1'О 1'ода работы их ПРО1'раммно1'О обеспечения. Они успешно создали и сдали си стему, не удовлетворив некоторых потребностей отдельных участников. Поэтому от последних пришли запросы на изменения. Если бы список участников и интересов был составлен раньше, запросов на изменения (во всяком случае, некоторых из них) не было бы. В результате Пит стал cTpo1'o проверять, зафиксированы ли интересы участников в вариантах использования. Такая проверка занимает мало времени, но при этом можно обнаружить очень MHo1'oe. Раздел 1'арантий шаблона документирует, как вариант использования удовлетво ряет эти интересы. Вы МО1'ли бы сэкономить на описании 1'арантий Д,lIЯ менее важно 1'0 и менее формаЛЬНОf'О проекта, если в 1'руппе хорошо налажено взаимодействие с нужными специалистами. Вы можете уделить 1'арантиям больше внимания в более критичных проектах, 1'де возможен больший ущерб. Однако в обоих случаях ваша 1'руппа должна по крайней мере мысленно прокрутить как успешное, так инеудачное завершение варианта использования. Разумно описывать 1'арантии до создания OCHoBHoro сценария, так как при этом вы задумываетесь о необходимых подтверхщениях на первом проходе, вместо To1'o чтобы обнаруживать их позднее и возвращаться назад Д,lIЯ изменения текста. В разделах 2.2 и 6.2 эти темы освещаются более подробно. памятка 10. преАУСЛОВИЯ Предусловия варианта использования объявляют прав ильные условия e1'o функци онирования. Предусловия должны быть таковы, чтобы система МО1'ла обеспечить 
216 rлава 20 их истинность. Вы записываете предусловия в документе, поскольку не будете про верять их снова в варианте использования. Существуют две распространенные ситуации, порождающие предусловия. Чаще Bcero это ситуация, КО1'да пользователь ре1'истрируется в системе и последняя под тверждает e1'o имя и пароль. В дрУ1'ом случае второй вариант использования стано- вится активным (отчасти бла1'одаря первому варианту использования), ожидая, что первый вариант установит отдельное условие, на которое он может пола1'аться. Ha пример, пользователь выбирает или частично выбирает товар в первом варианте ис- пользования, а второй при выполнении применяет информацию об этом выборе. КО1'да я вижу предусловие, я знаю, что все1'да существует вариант использова ния более BblcoKo1'o уровня, в котором это предусловие устанавливается. Памятка 11. Тесты "прошел/не прошел" АЛЯ oAHoro варианта использования Простые тесты "прошел/не прошел" позволяют узнать, правильно ли вы разрабо тали часть варианта использования. В таблице 20.1 приведено несколько разрабо танных мною тестов. Все они должны давать ответ "да". Таблица 20.1. ТестЬ! "прошел/не прошел н ДМ7 OAHOro варианта использования Попе Вопрос Название варианта 1. Является ли предложение, называющее цель OCHoBHoro использования действующеrо лица, предложением с rпаrолом действия? 2. Может система удовлетворить эту цель? Обпасть действия З. Заполнены ли поля? и уровень Область действия 4. Рассматривает ли вариант использования упомянутую в разделе области действия систему как "черный ящик"? (OT вет должен быть "да", если это документ, описывающий требования к системе, но может быть и "нет", если это Ba риант использования для бизнеса типа "прозрачноrо ящика".) 5. Если система в разделе Область действия является той, что должна разрабатываться, должны ли разработчики создавать только то, что есть в ней, и ничеrо, что в нее не входит? Уровень 6. Соответствует ли содержание варианта использования за явленному уровню цели? 7. Действительно ли цель находится на заявленном уровне цели? Основное действую 8. Присуще ли ему поведение? щее лицо 9. Имеет ли оно цель в отношении разрабатываемой систе мы, которая должна быть услуrой разрабатываемой системы? Предусловия 10. Обязательны ли они и может ли их установить разраба тываемая система? 11. Они действительно никоrда не проверяются в варианте использования? 
Памятки для каждоrо варианта использования 217 Таблица 20.1 (продолжение) Попе Вопрос Участники и интересы 12. Названы ли они, и должна ли система удовлетворять их интересы, как установлен01 (Использование варьируется установленными нормами и допусками.) Минимальные rарантии 13. Все ли интересы участников защищены1 r арантии успеха 14. Все ли интересы участников соблюдены1 Основной сценарий 15. В нем 39 шаrов1 16. Выполняется ли он от триrrера до обеспечения rарантии успеха1 17. Допускает ли он правильные изменения в последователь ности1 Каждый шаr в любом 18. Он описывает достижение цели1 сценарии 19. Заметно ли продВиrает процесс ero успешное выполнение1 20. Ясно ли, какое действующее лицо достиrает цель, кто "ударяет по мячу"1 21. Ясно ли намерение действующеrо лица1 22. Уровень цели шаrа ниже уровня цели варианта использо вания в целом1 Он чуть ниже (что предпочтительнее) уровня цели варианта использования1 23. Вы уверены, что шаr не описывает проект интерфейса пользователя1 24. Ясно ли, какая информация передается на шаrе1 25. Условие в шаrе "подтверждается", а не "проверяется"1 Условие расширения 26. Может ли и должна ли система и обнаруживать, и обра батывать er01 27. Это действительно то, что нужно системе1 Список изменений в 28. Вы уверены, что зто не обычное поведенческое расши технолоrии и данных рение OCHoBHoro сценария1 Общее содержание Ba 29. Заказчикам и пользователям: "Это то, что вам требуется1" рианта испопьзования 30. Заказчикам и пользователям: "Вы сможете сказать по завершении сдачи, что получипи то, что хотели1" 31. Разработчикам: "Вы можете это реализовать1" 
{АОВО 21 Памят",и для набора вариантов использования Памятка 12. Бесконечно развивающийся сюжет в проекте системы существует один вариант использования на вершине стека, называемый ПрИМерно так: Использовать систему ZZZ. Этот вариант исполь зования есть нечто большее, чем О1'лавление, включающее действующих лиц и их цели высше1'О уровня. Он служит отправной точкой для любо1'О, кто впервые смотрит на систему. Он не является обязательным, так как в нем почти нет сю жета, но большинству людей просто удобно знать место, откуда следует начи нать чтение. Этот вариант использования наивысше1'О уровня вызывает предельные вариан ты использования, которые показывают обобщенные цели "крайних" основных дей ствующих лиц системы. Для корпоративной информационной системы обычно существует внешний клиент, отдел маркеТИН1'а или информационных техноло1'ИЙ, либо отдел безопасности. Эти варианты использования показывают взаимоотноше ния вариантов использования уровня моря, которые определяют систему. Для боль шинства читателей "история" начинается с ОДНО1'О из них. Предельные варианты использования развертываются в варианты использова ния уровня цели пользователя или уровня моря. В вариантах использования уровня цели пользователя областью действия проектирования является разрабатываемая система. Ша1'И показывают взаимодействие действующих лиц и системы, направлен  ное на достижение непосредственной цели пользователя. Ша1' варианта использования уровня моря развертывается в подводный вариант использования (цвета ИНДИ1'О или подфункцию ), если подчиненный вариант исполь зования составной или применяется в нескольких местах. Сопровождение вариантов использования уровня подфункции обходится недешево, поэтому употребляйте их TO лько при необходимости. Как правило, варианты использования уровня подфункции вам придется создавать Д1IЯ таких ша1'ОВ, как Найти клиента, Найти товар и Т.д. 
Памятки ДЛЯ набора вариантов использования 219 ИНО1'да ша1' ОДНО1'О варианта использования цвета инди1'О развертывается в вариант использования более TeMHo1'o цвета (ИНДИ1'о). Набор вариантов использования следует рассматривать как бесконечно развер тывающийся сюжет, так как перемещения сложных разделов документа в собствен ные варианты использования или упаковка просто1'О подчиненно1'О варианта использования в вызывающий e1'o вариант использования становятся рядовыми опе рациями. Каждый ша1' действия может в принципе быть развернут в самостоятель ный вариант использования (см. раздел 10.1). Памятка 13. Область Аействия корпорации и область Аействия системы Область действия проектирования может стать причиной недоразумения. Все поразному понимают точные 1'раницы системы. В частности, четко уясните, какой вариант использования вы пишете: для бизнеса или системный. В варианте использования для бизнеса областью действия проектирования являют ся деловые операции. Этот вариант описывает, как действующее лицо вне ОР1'анизации ДОСТИ1'ает цель в отношении этой ОР1'анизации. Вариант использования ЩIЯ бизнеса pek ко содержит упоминание о технолоrии, поскольку касается деловых операций. В системном варианте использования область действия проектирования  компьютерная система, подлежащая разработке. В нем описывается, как действую щее лицо ДОСТИ1'ает цель с помощью компьютерной системы. ОН как раз о техноло1'ИИ. Вариант использования для бизнеса часто создается в виде "прозрачно1'О ящи ка", описывая взаимодействия между людьми и отделами компании, в то время как системный вариант использования почти все1'да имеет тип "черно1'О ящика". Это, как правило, обоснованно, поскольку назначение большинства вариантов использования ЩIЯ бизнеса состоит в описании настояще1'О или будуще1'О проекта компании, Torдa как системный вариант использования создает требования для HOBo1'o проекта. Вари ант использования для бизнеса касается BнyтpeHHe1'o механизма бизнеса, а систем ный вариант использования  внешних ПрОЯВJfений компьютерной системы. Если вы разрабатываете компьютерную систему, вам следует иметь варианты использования и ЩIЯ бизнеса, и системные. В варианте использования ЩIЯ бизнеса содержится контекст функционирования системы, определяется ее место в бизнесе. Чтобы уменьшить путаницу, все1'да указывайте область действия варианта испо льзования. Попробуйте применить пиктоrpаммы для иллюстрации типа варианта ис пользования (системно1'О или для бизнеса). (См. раздел 3.2, подраздел об использовании 1'рафических ПИКТО1'рамм для вьщеления области действия проектиро вания. ) Можно поместить картинку системы внутри содержащей ее системы в самом варианте иСПОльзования (см. вариант использования 8). Памятка 14. Основные Аостоинства вариантов использования и вариации Хотя люди изобретают новые форматы варианта использования, опытные авторы приходят к общему мнению по основным значениям формата. В докладах на конфе 
220 rлава 21 ренциях TOOLS USA в 1999 1'. был приведен первый список ошибок, сделанных при создании вариантов использования. Способы исправления ошибок, описанные в этих работах, отражают основные достоинства вариантов использования. Основные достоинства БАЗИРУЕТСЯ НА ЦЕЛИ. При ДО<lтижении цели варианты использования KOHцeHT рируются BOKpy1' целей основных действующих лиц и подцелей различных действу ющих лиц, включая разрабатываемую систем