Первоначальный вариант Вариант использования: Снять наличные со счета.

Область действия: банкомат Уровень: цель пользователя Основное действующее лицо: клиент.

1.

Клиент вводит картонку и PIN.

2.

Клиент вводит "снять деньги" и количество.

3.

Клиент забирает наличные, карточку и квитанцию.

4.

Клиент уходит.

Замечания.

Этот вариант использования показывает все, что делает основное действующее лицо, но не отражает поведения системы. Просто удивительно, насколько часто люди пишут такого рода варианты использования, создавая у читателя впечатление, что системе на самом деле не пришлось ничего делать.

Исправление состоит в указании всех действующих лиц и их действий. Исправленный вариант.

Теперь вы сможете написать вариант использования для банкомата, даже если вас.

разбудить среди ночи.

Вариант использования: Снять наличные со счета.

Область действия: банкомат.

Уровень: цель пользователя.

Основное действующее лицо: владелец счета.

1.

Клиент пропускает карточку для банкомата через считывающее устройство.

2.

Банкомат считывает с карточки ID банка, номер счета, зашифрованный PIN, подтверждает ID банка и номер счета с помощью главной банковской системы.

3.

Клиент вводит PIN. Банкомат сверяет его с зашифрованным PIN, считанным с карточки.

4.

Клиент выбирает "быстрое снятие наличности" (Fast Cash) и указывает сумму в купюрах по $5.

5.

Банкомат уведомляет главную банковскую систему о номере счета клиента, требуемой сумме и получает в ответ подтверждение и новый баланс.

6.

Банкомат выдает деньги, карточку и квитанцию, показывающую новый баланс.

7.

Банкомат регистрирует транзакцию.

19.2. Отсутствует основное действующее лицо.

Первоначальный вариант.

Ниже приведен фрагмент варианта использования для извлечения денег из банкомата.

Вариант использования: Снять наличные со счета.

Область действия: банкомат.

Уровень: цель пользователя.

Основное действующее лицо: клиент.

1.

Получает карточку для банкомата, PIN.

2.

Получает в качестве типа транзакции "снять деньги".

3.

Получает требуемую сумму.

4.

Удостоверяется, что на счете достаточно денег.

5.

Выдает деньги, квитанцию, карточку.

6.

Возвращается в исходное состояние.

Замечания.

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

Исправление однозначно: указать каждое действующее лицо и действие.

Исправленный вариант.

То же, что в разделе 19.1.

19.3. Слишком много деталей интерфейса пользователя.

Первоначальный вариант Вариант использования: Совершить покупку.

Область действия: приложение для электронной торговли Уровень: цель пользователя Основное действующее лицо: клиент.

1.

Система устанавливает экран для ввода 1D и пароля.

2.

Клиент вводит ID и пароль, щелкает по кнопке "ОК".

3.

Система подтверждает ID и пароль, отображает персональные данные.

4.

Клиент вводит имя и фамилию, номер дома, название улицы, города, штата, почтовый индекс, номер телефона и щелкает по кнопке "ОК".

5.

Система подтверждает, что пользователь ей известен.

6.

Система выводит список товаров, имеющихся в наличии.

7.

Клиент щелкает по изображению товара, который хочет купить, вводит рядом с каждой картинкой количество, по окончании щелкает по кнопке "Готово".

8.

Система удостоверяется с помощью системы управления складами, что на складе есть достаточное количество требуемых товаров. ... и т.д.

Замечания.

Это, может быть, самая распространенная ошибка. Писатель слишком много пишет об интерфейсе пользователя, что делает вариант использования не документом о требованиях как таковых, а скорее руководством для пользователя. Излишние подробности интерфейса пользователя ничего не добавляют к сюжету, но затрудняют чтение и делают документ о требованиях неустойчивым к изменениям.

Исправление состоит в том, чтобы найти способ описать намерения пользователя, не предлагая специального решения. Иногда это требует творческого подхода к формулировкам.

Исправленный вариант Вариант использования: Совершить покупку.

Область действия: приложение для электронной торговли Уровень: цель пользователя Основное действующее лицо: клиент.

1.

Клиент регистрируется в системе с помощью Ю и пароля.

2.

Система подтверждает ID и пароль пользователя.

3.

Клиент вводит имя, адрес, номер телефона.

4.

Система подтверждает, что пользователь ей известен.

5.

Клиент указывает товар и его количество.

6.

Система удостоверяется с помощью системы управления складами, что на складе есть достаточное количество требуемых товаров. ... и т.д.

19.4. Очень низкие уровни цели.

Первоначальный вариант Вариант использования: Совершить покупку.

Область действия: приложение для электронной торговли Уровень: цель пользователя.

Основное действующее лицо: клиент (пользователь).

1.

Пользователь регистрируется в системе с помощью ID и пароля.

2.

Система подтверждает ID и пароль.

3.

Пользователь вводит имя.

4.

Пользователь вводит адрес.

5.

Пользователь вводит номер телефона.

6.

Пользователь указывает товар.

7.

Пользователь указывает количество.

8.

Система подтверждает, что пользователь ей известен.

9.

Система подключается к системе управления складами.

10. Система запрашивает у складской системы текущие уровни запасов.

11.

Система управления складами возвращает текущие уровни запасов.

12.

Система удостоверяется, что на складе есть достаточное количество требуемых товаров. ... и т.д.

Замечания.

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

Для сокращения текста:.

■ Объедините элементы данных (шаги 3-5) из разных шагов. Установив, что пользователь пытается обеспечить персональные данные, мы получим хорошее краткое имя для всех элементов информации об индивидууме, которые будут собираться. Я считаю, одно краткое имя слишком неопределенно, поэтому я указываю на список полей, который будет расширяться где-то в другом месте, не затрагивая этот вариант использования.

■ Сосредоточьте все данные, идущие в одном направлении, в одном шаге (шаги 3-7). Это не всегда лучший способ. Бывает, что получение персональной информации существенно отличается от указания товара и количества, поэтому автор помещает их в разных строках. Дело вкуса. Я предпочитаю объединять все данные, идущие в одном направлении. Если это выглядит слишком громоздко или для расширений необходимо, чтобы они были разделены, я их вновь разделяю.

■ Найдите более высокий уровень цели (шаги 8-11). Выясните, зачем система совершает все эти действия. Она пытается удостовериться при помощи системы управления складами, что на складе есть достаточное количество требуемого товара. Эта цель более высокого уровня и фиксирует требования так же ясно, но описание значительно сокращается.

Исправленный вариант Вариант использования: Совершить покупку.

Область действия: приложение электронной торговли.

Уровень: цель пользователя.

Основное действующее лицо: клиент (пользователь).

1.

Пользователь регистрируется в системе с помощью ID и пароля.

2.

Система подтверждает ID и пароль пользователя.

3.

Пользователь вводит персональные данные (имя, адрес, номер телефона), указывает товар и количество.

4.

Система подтверждает, что пользователь ей известен.

5.

Система удостоверяется при помощи системы управления складами, что на складе есть достаточное количество требуемого товара. ... и т.д.

19.5.

Цель и содержание не соответствуют друг другу.

Вспомните упражнение 7.4, в котором вы должны были исправить неверный вариант использования Зарегистрироваться в системе.

Если вы еще этого не сделали, найдите эти три ошибки:.

■ Тело варианта использования не соответствует намерению, заявленному в названии и описании. Практически это не менее двух сложенных вместе вариантов использования.

■ Здесь описываются подробности интерфейса пользователя.

■ В тексте используются логические структуры программирования, а не обычный язык.

Если вы решили не утруждать себя, обратитесь к приложению В, в котором содержатся разбор и решение.

19.6.

Развитый пример варианта использования с чрезмерной детализацией интерфейса пользователя.

Компания FirePond Corporation любезно позволила мне использовать следующие примеры первоначальных и исправленных вариантов. Первоначальный вариант занимает несколько страниц, часть из которых ушла на основной сценарий и альтернативы. Исправленный вариант втрое короче. Он содержит ту же базовую информацию, но без усложняющих подробностей интерфейса пользователя.

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

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

Приношу благодарность Дэйву Скотту и Расселу Уолтерсу из FirePond Corporation.

Первоначальный вариант Вариант использования 36

*Ь. В любой точке серии вопросов и ответов покупатель может вернуться*а. В любой точке в процессе выполнения варианта использования Принять решение, если покупатель не выполняет никаких действий в течение заранее определенного периода простоя, система уведомит его об отсутствии активности и спросит, не хочет ли он продолжить работу. Если покупатель не отвечает в течение разумного промежутка времени (30 с), вариант использования прекращает работу. В противном случае покупатель продолжит работу.

к любому вопросу, изменить свой ответ и продолжить серию.

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

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

тровать представленную информацию о выборе товара или показать наличие запасных частей покупателю во время процесса поиска решения. Инициировать варианты использования Получение данных о наличии запасных частей и Получить перечень комплектующих.

*е. В любой точке серии вопросов и ответов система представляет соответствующую информацию о производственных каналах для запасных частей. Покупатель выбирает канал. Система может передать по этому каналу связанную с товаром или другую информацию для наилучшего размещения или представить подходящее содержимое. Завершив работу с промышленным web-сайтом, покупатель возвратится к точке, откуда ушел, возможно, с возвращением требований к товару, которые система будет подтверждать. Инициировать обзорную информацию по товару.

*f. В любой точке процесса поиска покупатель может выдать запрос на соединение: вариант использования Инициировать запрос на соединение. *д. В любой точке серии вопросов и ответов система может установить точки триггера фиксации данных о рынке, в которых система будет регистрировать навигационные данные, информацию о выборе товара, а также вопросы и ответы, которые будут использованы вне этой системы для анализа рынка.

*h. В заранее определенной точке поиска система может сформировать директиву для фиксации данных, накопленных к этому моменту. Вариант использования Инициировать формирование директивы.

*i. В любой точке покупатель может выйти из приложения электронной торговли: Если было найдено новое решение или изменено текущее с момента последнего сохранения, система спросит покупателя, не хочет ли он сохранить решение. Инициировать Сохранить решение.

*j. В любой точке после нахождения нового решения или изменения текущего покупатель может запросить сохранение решения. Инициировать Сохранить решение.

1а. Покупатель посещал web-сайт производителя товара и установил требования к изделию. Web-сайт производителя позволяет выбрасывать на рынок новые товары в эту систему электронной торговли для дальнейшего поиска решения:.

1 а 1. Покупатель входит в систему электронной торговли с требования ми к товару и, может быть, данными по идентификации.

1а2. Система получает требования к товару и, возможно, данные по идентификации пользователя.

1аЗ. Система проверит, в какой точке процесса поиска находится покупатель, и установит стартовую точку серии вопросов для продолжения процесса поиска.

1а4. Основываясь на установленной стартовой точке, мы можем продолжать с шага 5, 12 или 18.

За. Покупатель хочет работать с ранее сохраненным решением:.

За1. Покупатель выбирает восстановление решения.

За2. Система представляет список сохраненных решений этого покупателя.

ЗаЗ. Покупатель выбирает решение, с которым будет работать.

За4. Система восстанавливает выбранное решение.

За5. Продолжать с шага 26.

23а. Покупатель хочет изменить некоторые рекомендованные варианты: {Создать вариант использования Выбрать вариант, поскольку существуют альтернативы основному потоку. Систему можно установить так, чтобы показывать все варианты, даже несовместимые. Если покупатель выбирает несовместимый вариант, система выведет сообщение об этом и, может быть, указание, как получить товар, сконфигурированный так, чтобы вариант был совместимым.} ... пока покупателю необходимо изменить вариант:.

23а 1. Покупатель выбирает вариант, который желает изменить.

23а2. Система представляет имеющиеся совместимые варианты. 23а3. Покупатель выбирает желаемый вариант.

26а. Покупатель хочет изменить количество выбранных товаров в тележке для покупок:.

26а 1. Покупатель выбирает продукт из тележки и изменяет его количество.

26а2. Система пересчитает цену, учитывая скидки, налоги, сборы и специальные цены, основываясь на информации о покупателе, а также на ответах на вопросы.

26Ь. Покупатель хочет добавить к тележке встречную продажу товара: 26Ы. См. раздел Встречная продажа.

26с. Покупатель хочет вызвать сохраненное решение:.

26с 1. Система представляет список сохраненных решений данного покупателя.

26с2. Покупатель выбирает решение, с которым будет работать. 26сЗ. Система восстанавливает указанное решение.

26с4. Продолжать с шага 26.

26d. Покупатель хочет заплатить за продукты в тележке для покупок с помощью имеющихся финансовых планов:.

26d1. Покупатель выбирает финансирование продуктов в тележке.

26d2. Система задаст ряд вопросов, зависящих от предшествующих ответов, чтобы определить рекомендации по финансовому плану. Система взаимодействует с финансовой системой, чтобы получить подтверждение кредитоспособности. Инициировать оценку кредитоспособности.

26d3. Покупатель выберет финансовый план.

26d4. Система задаст ряд вопросов, зависящих от предшествующих ответов, чтобы определить подробности выбранного финансового плана.

26d5. Покупатель рассмотрит подробности финансового плана и решит следовать ему.

26d6. Система разместит заказ на финансовый план с помощью финансовой системы. Инициировать размещение финансового заказа.

Замечания.

В данном случае был выбран формат в две колонки, чтобы разделить шаги действующих лиц. Авторы не представляли себе отчетливо проекта интерфейса пользователя, кроме модели вопрос/ответ, поэтому описали вопросы и ответы в варианте использования.

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

Просматривая результат, я искал предположения относительно проектирования интерфейса пользователя, а также цели, уровень которых можно было бы повысить. Ключ содержится в предложении “Система задаст вопросы, число и тип которых будут изменяться в зависимости от предшествующих ответов”. Здесь не упоминается что-либо столь же очевидное, как щелчки мышью, поэтому предполагается интерфейс, основанный именно на том, что пользователь набирает на клавиатуре ответы на вопросы. Я хотел представить совершенно другой интерфейс, чтобы посмотреть, как это повлияет на текст варианта использования. Я имел в виду проект, в котором пользователь только щелкал бы по картинкам. Тогда можно было бы уловить намерения пользователя и устранить зависимость от пользовательского интерфейса. Это тоже послужило сокращению документа.

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

В начале этой работы я не был уверен, что формат в одну колонку будет ясно показывать разработчикам обязанности системы. Авторы первоначального варианта рассеяли мои сомнения. Практически они были довольны, так как:.

■ Документ стал короче и удобнее для чтения.

■ Все действительные требования в документе сохранились и остались ясно выделенными.

■ Проект расширил границы.

Исправленный вариант Вариант использования 37 Ш Найти возможные решения (после) ЗА.

Область действия: web-система программного обеспечения.

Уровень: цель пользователя.

Предусловия: нет.

Минимальная гарантия: нет действия, нет покупок.

Гарантия успеха: покупатель имеет ноль или более товаров, подготовленных к покупке, в системе есть журнал регистрации выбора и навигационных данных, записаны также характеристики пользователя.

Основное действующее лицо: покупатель (любой путешествующий по Сети).

Триггер: покупатель собрался найти решение.

Основной сценарий:.

1.

Покупатель инициирует поиск нового решения.

2.

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

3.

Система регистрирует навигационную информацию в ходе процесса.

4.

Покупатель выбирает окончательную конфигурацию товара.

5.

Покупатель добавляет его к тележке.

6.

Система добавляет к тележке для покупок выбранный товар и навигационную информацию.

7.

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

Расширения:.

*а. В любой момент покупатель может запросить соединение.

1а. По соглашению между владельцем web-сайта и владельцем посылающего запрос компьютера в запросе может содержаться информация.

0 типе покупателя:.

1 а 1. Система выделяет из web-запроса любую пользовательскую и на¬.

вигационную информацию, добавляет ее к данным регистрации и начинает с некоторой точки в глубине серии вопросов и ответов.

1 а 1 а. Информация, приходящая с другого сайта, неверна или не понятна. Система делает максимум возможного, регистрирует всю поступившую информацию и по возможности продолжает.

1Ь. Покупатель желает продолжить работу над прежним сохраненным неполным решением.

1Ы. Покупатель устанавливает личность и сохраняет решение.

1Ь2. Система восстанавливает решение и возвращает покупателя туда, где он остановился, перед тем как сохранить решение.

2а. Покупатель решает обойти одну или все серии вопросов:.

2а 1. Покупателю предоставляются рекомендации по товару на основе ограниченных (или нет) персональных характеристик, и он делает выбор.

2а2. Система регистрирует этот выбор.

2Ь. В любой момент перед добавлением товара к тележке покупатель может вернуться и изменить любой предыдущий ответ, чтобы получить новые рекомендации по товару и (или) новую возможность выбора. 2с. В любой момент перед добавлением товара к тележке покупатель может запросить расчет по имеющемуся тесту (характеристики), например, потянет ли данная конфигурация с этим весом на трейлер: Система производит вычисления и выводит ответ.

2d. Покупатель проходит точку, которую владелец web-сайта предварительно определил для формирования директив по продажам (динамическое бизнес-правило): Система формирует директиву по продажам. 2е. Система установлена для запроса у покупателя удостоверения личности: Покупатель устанавливает личность.

2f. Система установлена для взаимодействия с другими известными системами (инвентаризации запасных частей, технологической подготовки производства), которое повлияет на наличие и выбор товара:.

2f1. Система взаимодействует с другими известными системами (инвентаризации запасных частей, технологической подготовки производства), чтобы получить необходимую информацию. (Получить данные о наличии запасных частей, Получить перечень комплектующих.).

2f2. Система использует результаты для фильтрации или показа данных о наличии товара и (или) вариантов (запасных частей).

2д. Покупатель выбирает канал из представленного множества каналов к web-сайтам производителей: Покупатель просматривает другой web-сайт.

2h. Система устанавливается для взаимодействия с известной информационной системой заказчика:.

2Ы. Система получает информацию для заказчика от информационной системы для заказчиков.

2Ь2. Система использует результаты, чтобы начать с некоторой точки внутри серии вопросов и ответов.

2i. Покупатель хочет узнать оценку кредитоспособности, поскольку она повлияет на процесс выбора товара: Покупатель получает оценку кредитоспособности.

2j. Покупатель указывает, что он купил товар прежде, и система устанавливается для взаимодействия с известной системой финансового учета. 2j1. Система получает последовательность выставления счетов.

2j2. Система использует последовательность выставления счетов покупателя, чтобы повлиять на процесс выбора товара.

2к. Покупатель решает изменить некоторые из рекомендованных вариантов: Система позволяет покупателю изменить столько вариантов, сколько он пожелает, по ходу дела выводя на экран данные о допустимых вариантах и предупреждая о несовместимости других вариантов.

5а. Покупатель решает не добавлять товар к тележке для покупок: Система оставляет навигационную информацию на будущее.

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

7Ь. Покупатель просит сохранить содержимое тележки для покупок:.

7Ы. Система запрашивает у покупателя имя и ID для сохранения и сохраняет содержимое.

7Ыа. Личность покупателя не установлена: Покупатель устанавливает личность.

7с. Покупатель имеет товар для встречной продажи: Система фиксирует встречную продажу.

76. Покупатель решает оплатить товары в тележке: Покупатель получает финансовый план.

7е. Покупатель выходит из системы электронной торговли, когда тележка для покупок не сохранена:.

7е1. Система запрашивает у покупателя имя и ID для сохранения и сохраняет содержимое тележки.

7е1а. Покупатель решает выйти без сохранения: Система регистрирует навигационные данные и завершает сеанс с покупателем.

7(. Покупатель выбирает элемент из тележки для покупок, чтобы узнать о наличии соответствующего товара (нового или используемого) от системы инвентаризации.

7(1. Покупатель выдает запрос локализовать соответствующий товар в системе инвентаризации.

7f2. Покупатель заменяет элемент в тележке для покупок соответствующим товаром из системы инвентаризации.

7f2a. Покупатель не хочет приводить товар в соответствие с элементом из системы инвентаризации:.

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

7f3. Система гарантирует, что в тележке для покупок содержится один элемент, сконфигурированный в соответствии с элементом из системы инвентаризации.

Вызывающие варианты использования: Интернет-магазин. Продажа связанных продуктов Открытые вопросы:.

Расширение 2с. Какие вопросы законны? Какие еще системы задействованы? Каковы требования к интерфейсам?

Памятка 1. Вариант использования — прозаическое эссе.

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

Рассел Уолтерс из компании FirePond написал:.

Я думаю, вышеприведенное утверждение точно отражает суть вопроса. Это проблема еще не получила нужной оценки. Для автора вариантов использования изучить этот вопрос необходимо. Однако я не уверен, что практикант может самостоятельно освоить данную тему, по крайней мере пока не прочтет эту книгу. Я не считал эту проблему главной и работал с концепцией ва риантов использования четыре года, пока не появилась возможность сотрудничать с вами. И даже тогда все оставалось по-прежнему, пока я не проанализировал первоначальные и исправленные версии варианта использования 36. Единственное, на что придется читателям этой книги затратить усилие, — это осознать, что основной проблемой является создание эффективных вариантов использования. (Печатается с разрешения.).

Эта памятка поможет вам сосредоточиться на тексте, а не на схемах, и принимать к сведению стили изложения, с которыми вы будете встречаться.

Памятка 2. Старайтесь, чтобы вариант использования был читабельным.

Ваш документ о требованиях должен быть коротким, ясным и читабельным.

Я иногда чувствую себя учителем словесности в восьмом классе, который ходит туда-сюда и говорит:.

Используйте глаголы действия в настоящем времени. Употребляйте действительный залог, а не страдательный. Где в предложении подлежащее? Говорите о том, что действительно является требованием; не упоминайте то,.

что таковым не является.

Следующие рекомендации помо1ут вам сделать ваш документ о требованиях коротким, четким и легким для чтения:.

1.

Старайтесь писать короче и ближе к делу. Длинные варианты использования ведут к длинному описанию требований, которое мало кому нравится читать.

2.

Начните с вершины и создайте логически последовательный сюжет.

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

3.

Именуйте варианты использования с помощью коротких глагольных конструкций, объявляющих цель, которая должна быть достигнута.

4.

Начинайте с триггера и продолжайте, пока цель не будет достигнута или отвергнута и система не зарегистрирует необходимую информацию.

о транзакциях.

5.

Используйте полные предложения с глагольными конструкциями, которые описывают подлежащие выполнению подцели.

6.

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

7.

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

8.

Для описания альтернативного поведения применяйте расширения, а не предложения с если в теле главного варианта использования.

9.

Создавайте варианты использования расширения только в особых случаях.

Памятка 3. Только одна форма предложения.

Существует только одна форма предложения, используемая для описания шагов действия:.

■ Предложение в настоящем времени.

■ С глаголом действия в действительном залоге.

■ Описывающее, как действующее лицо успешно достигает цели, продвигающей весь процесс.

Примеры:.

Клиент вводит карточку и PIN.

Система удостоверяется в полномочиях клиента и достаточности остатка на счете.

PAF (персональный консультант по финансам) перехватывает ответы с web-сайта и обновляет портфель пользователя.

Служащий находит заявление об ущербе с помощью деталей поиска заявления об ущербе.

Употребляйте такие предложения в вариантах использования для бизнеса, системных, обобщенных, а также вариантах использования уровня подфункции, написанных как по полной форме, так и произвольно. Это относится и к основному сценарию, и к фрагментам сценария расширения. Овладейте этим стилем.

В блоках условий в расширениях должна быть другая грамматическая форма, чтобы не путать расширение с шагами действий. Лучше (но не всегда) использовать фрагмент предложения (или, может быть, полное предложение) в прошедшем времени. В конце условия ставьте двоеточие (:), а не точку.

Тайм-аут ожидания ввода PIN:.

Неверный пароль:.

Файл не найден:.

Пользователь вышел, не закончив:.

Представленные данные не полны:.

Памятка 4. “Включайте” подчиненные варианты использования.

Абсолютно естественное действие (если никто не велел вам сделать по-другому) — написать шаг, который вызывал бы цель более низкого уровня или вариант использования:.

Служащий находит заявление об ущербе с помощью параметров поиска ущерба.

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

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

Памятка 5. Кто владеет мячом?.

Иногда пишут, используя страдательный залог, или с точки зрения самой системы, смотрящей на мир. Тогда и получаются такие предложения, как “Вводится кредитный лимит”. В этом предложении не упомянут тот, кто осуществляет ввод.

Пишите как бы с высоты птичьего полета, наблюдая за сценой и описывая ее, либо пишите в форме пьесы, объявляя, какое действующее лицо собирается действовать. Или представьте, что вы комментируете футбольный матч, в котором действующее лицо 1 владеет мячом, ведет его, далее следует передача игроку 2; игрок 2 пасует игроку 3 и т.д.

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

Памятка 6. Уровень цели должен быть правильным.

■ См. раздел 5.5, где вопрос обсуждается подробно.

■ Удостоверьтесь, что для варианта использования указан правильный уровень цели: обобщенный, пользователя или подфункции.

■ Периодически проверяйте, знаете ли вы, где “уровень моря” для ваших целей и насколько ниже (или выше)уровня моря находятся шаги. Напомним тесты для цели уровня моря:.

— Цели добивается одно лицо в одном месте в одно время (2-20 мин).

— Действующее лицо может уйти удовлетворенным, как только цель будет достигнута.

— Добившись многих целей, действующее лицо (если работает по найму) может попросить повышения.

■ Помните, что большинство вариантов использования имеет 3-9 шагов в основном сценарии, и уровень цели шага обычно ниже уровня цели варианта использования. Если в варианте использования более девяти шагов, поищите шаги, которые можно объединить, например:.

— Если одно и то же действующее лицо “владеет мячом” на протяжении нескольких шагов подряд.

— Если описаны движения пользователя — типичное описание интерфейса пользователя, нарушающее правило 5.

(см. раздел 7.2).

— Если много простых передач между двумя действующими лицами (спросите, не пытаются ли они на самом деле совершить что-нибудь одним уровнем выше с помощью этих передач).

■ Поинтересуйтесь, почему пользователь (действующее лицо)делает это. Ответ, который вы получите — это более высокий уровень цели. Вам, возможно, удастся с помощью этой цели объединить несколько шагов. На рис. 20.1 показано, как цели шагов размещаются внутри целей вариантов использования на различных уровнях.

Спросите “почему”, чтобы сдвинуть уровни

Рис, 5.2, Спросите "почем/, чтобы изменить уровни.

Памятка 7. Не допускайте деталей графического интерфейса пользователя в варианте использования.

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

Описывать движения пользователя при манипулировании интерфейсом в документе о требованиях не следует, так как:.

■ Документ становится излишне длинным.

■ Требования становятся неустойчивыми в том смысле, что небольшие изменения в проекте интерфейса вызывают изменение в “требованиях” (которые все-таки не были в чистом виде требованиями).

■ Это задача разработчика интерфейса пользователя, которому вы должны доверять как специалисту.

Варианты использования в этой книге по большей части должны служить вам хорошими примерами. Вот выдержка из одного из них, варианта использования 20:.

1.

Оценщик просматривает и оценивает отчеты ...

2.

Оценщик оценивает постоянную неплатежеспособность, используя ...

3.

Оценщик определяет сумму долга ...

4.

Оценщик определяет окончательный диапазон суммы возмещения.

Следующие шаги написаны неправильно:.

1.

Система устанавливает экран Login (регистрации) с полями для имени и пароля пользователя.

2.

Пользователь вводит имя и пароль и щелкает по кнопке "ОК".

3.

Система проверяет имя и пароль.

4.

Система устанавливает основной (main) экран, содержащий меню функций.

5.

Пользователь выбирает функцию и щелкает по кнопке "ОК".

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

Памятка в. Два итога.

Каждый вариант использования имеет два возможных итога: успех и неудачу.

Имейте в виду, что шаг действия вызывает подчиненный вариант использования, последний может завершиться успехом либо неудачей. Если он из расширения, опишите обработку как успеха, так и неудачи в том же расширении (см., например, вариант использования 22).

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

Памятка 9. Участникам необходимы гарантии.

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

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

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

Обычно одни и те же участники задействованы в большинстве вариантов использования, и, как правило, их интересы во всех вариантах использования одинаковы. Поэтому нетрудно перечислить их имена и интересы. Об интересах можно сказать следующее:.

■ Интерес основного действующего лица сформулирован в названии варианта использования. Он обычно состоит в том, чтобы что-то получить.

■ Интерес компании, как правило, состоит в том, чтобы основное действующее лицо не получило что-либо бесплатно или заплатило за то, что получило.

■ Интерес руководящего ведомства обычно состоит в том, чтобы удостовериться, что компания следует правилам и регистрирует соответствующую информацию.

■ Один из участников обычно заинтересован в восстановлении после отказа посреди транзакции, т.е. в новой регистрации.

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

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

Пит Мак-Брин из компании Roshi рассказал мне о том, как его группа в первый раз составила список интересов участников для системы, которую они уже разработали. В этом списке они нашли все запросы на изменения, поступившие в течение первого года работы их программного обеспечения. Они успешно создали и сдали систему, не удовлетворив некоторых потребностей отдельных участников. Поэтому от последних пришли запросы на изменения. Если бы список участников и интересов был составлен раньше, запросов на изменения (во всяком случае, некоторых из них) не было бы. В результате Пит стал строго проверять, зафиксированы ли интересы участников в вариантах использования. Такая проверка занимает мало времени, но при этом можно обнаружить очень многое.

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

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

В разделах 2.2 и 6.2 эти темы освещаются более подробно.

Памятка 10. Предусловия.

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

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

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

Памятка 11. Тесты “прошел/не прошел” для одного варианта использования.

Простые тесты “прошел/не прошел” позволяют узнать, правильно ли вы разработали часть варианта использования. В таблице 20.1 приведено несколько разработанных мною тестов. Все они должны давать ответ “да”.

Таблица 20.1. Тесты “прошел/не прошел" для одного варианта использования

Памятки для каждого варианта использования Таблица 20.1 (продолжение)

Памятка 12. Бесконечно развивающийся сюжет.

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

Этот вариант использования наивысшего уровня вызывает предельные варианты использования, которые показывают обобщенные цели “крайних” основных действующих лиц системы. Для корпоративной информационной системы обычно существует внешний клиент, отдел маркетинга или информационных технологий, либо отдел безопасности. Эти варианты использования показывают взаимоотношения вариантов использования уровня моря, которые определяют систему. Для большинства читателей “история” начинается с одного из них.

Предельные варианты использования развертываются в варианты использования уровня цели пользователя или уровня моря. В вариантах использования уровня цели пользователя областью действия проектирования является разрабатываемая система. Шаги показывают взаимодействие действующих лиц и системы, направленное на достижение непосредственной цели пользователя.

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

Иногда шаг одного варианта использования цвета индиго развертывается в вариант использования более темного цвета (индиго).

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

Памятка 13. Область действия корпорации и область действия системы.

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

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

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

Вариант использования для бизнеса часто создается в виде “прозрачного ящика”, описывая взаимодействия между людьми и отделами компании, в то время как системный вариант использования почти всегда имеет тип “черного ящика”. Это, как правило, обоснованно, поскольку назначение большинства вариантов использования для бизнеса состоит в описании настоящего или будущего проекта компании, тогда как системный вариант использования создает требования для нового проекта. Вариант использования для бизнеса касается внутреннего механизма бизнеса, а системный вариант использования — внешних проявлений компьютерной системы.

Если вы разрабатываете компьютерную систему, вам следует иметь варианты использования и для бизнеса, и системные. В варианте использования для бизнеса содержится контекст функционирования системы, определяется ее место в бизнесе.

Чтобы уменьшить путаницу, всегда указывайте область действия варианта использования. Попробуйте применить пиктограммы для иллюстрации типа варианта использования (системного или для бизнеса). (См. раздел 3.2, подраздел об использовании графических пиктограмм для выделения области действия проектирования.) Можно поместить картинку системы внутри содержащей ее системы в самом варианте использования (см. вариант использования 8).

Памятка 14. Основные достоинства вариантов использования и вариации.

Хотя люди изобретают новые форматы варианта использования, опытные авторы приходят к общему мнению по основным значениям формата. В докладах на конференциях TOOLS USA в 1999 г. был приведен первый список ошибок, сделанных при создании вариантов использования. Способы исправления ошибок, описанные в этих работах, отражают основные достоинства вариантов использования.

Основные достоинства.

БАЗИРУЕТСЯ НА ЦЕЛИ. При доотижении цели варианты использования концентрируются вокруг целей основных действующих лиц и подцелей различных действующих лиц, включая разрабатываемую систему. Каждое предложение описывает достигаемую подцель.

ВЗГЛЯД С ВЫСОТЫ ПТИЧЬЕГО ПОЛЕТА. Вариант использования должен описывать действия, рассматриваемые как бы с высоты птичьего полета, или создаваться как пьеса, в которой фигурируют действующие лица. Не следует писать с точки зрения “изнутри системы”.

ЧИТАБЕЛЬНОСТЬ. Вариант использования или любую спецификацию кто-то будет читать. Если документ нечитабелен, он не выполняет своего назначения. Можно сделать документ легким для чтения, принеся в жертву долю точности и даже правильности, компенсировав это удобной формой. В противном случае вы рискуете тем, что руководители не станут читать ваши варианты использования.

ИМЕЕТ НЕСКОЛЬКО НАЗНАЧЕНИЙ. Варианты использования — форма описания поведения, которая может служить различным целям на различных этапах проекта. Например, они нужны для:.

■ Обеспечения функциональных требований к “черному ящику”.

■ Обеспечения требований для перепроектирования бизнес- процесса организации.

■ Документирования бизнес-процесса организации (“прозрачный ящик”).

■ Выяснения требований у пользователей или участников (от вариантов использования откажутся, если группа напишет окончательные требования в несколько иной форме).

■ Определения тестовых примеров, которые нужно создавать и прогонять.

■ Документирования внутреннего содержания системы (“прозрачный ящик”).

■ Документирования поведения проекта или структуры проекта.

ТРЕБОВАНИЯ К "ЧЕРНОМУ ЯЩИКУ". При использовании функциональной спецификации разрабатываемая система всегда трактуется как “черный ящик”. В проектной группе, которая пыталась написать требования к “прозрачному ящику” (гадая, как будет выглядеть внутреннее устройство системы), получившиеся в результате варианты использования трудно читались, не вполне отвечали нормам и были неустойчивы, так как изменялись по мере продвижения проекта.

АЛЬТЕРНАТИВНЫЕ ПУТИ ПОСЛЕ ОСНОВНОГО СЦЕНАРИЯ. Оригинальная идея по мещать альтернативные направления после основного сценария открывает путь к созданию самых легких для чтения вариантов использования. Ветвление внутри основного тела текста слишком затрудняет чтение документа.

ЭКОНОМИЯ УСИЛИЙ. Большие затраты времени на варианты использования не увеличивают их ценность. Первый набросок варианта использования создает, возможно, половину его ценности, добавление расширений повышает ее, но со временем изменения формулировок предложений перестают улучшать взаимодействие. В этот момент энергию следует направить на решение других проблем, например, внешних интерфейсов, бизнес-правил и т.д. Это является частью оставшихся требований.

Подходящие вариации.

При сохранении основных достоинств открывается ряд приемлемых вариаций.

НУМЕРОВАННЫЕ ШАГИ И ПРОСТЫЕ АБЗАЦЫ. Некоторые авторы нумеруют шаги, чтобы обращаться к ним в разделах расширения. Другие пишут альтернативы в виде простых абзацев. Оба способа возможны.

СВОБОДНАЯ И ПОЛНАЯ ФОРМЫ. Иногда стоит тратить силы на создание детальных функциональных требований, а в других случаях этого делать не стоит (см. разделы 1.2 и 1.5). Это до такой степени верно, что я даже не рекомендую больше ни одного шаблона, но всегда показываю как произвольную, так и полную версию. Разные авторы предпочитают разные версии. Каждый работает по-своему. Сравните варианты использования 25 и 5.

ПРЕДВАРИТЕЛЬНОЕ МОДЕЛИРОВАНИЕ БИЗНЕС-ПРОЦЕССОВ С ПОМОЩЬЮ ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ ИЛИ БЕЗ НИХ. Некоторые любят документировать или анализировать бизнес-процессы, прежде чем писать функциональные требования к системе. Одни выбирают варианты использования для описания бизнес-процессов, другие отдают предпочтение иным формам их моделирования. С точки зрения функциональных требований к системе, похоже, нет большой разницы в нотациях для моделирования бизнес-процесса.

ДИАГРАММЫ ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ И СПИСКИ ДЕЙСТВУЮЩЕЕ ЛИЦО/ ЦЕЛЬ. Некоторые специалисты с помощью списков Действу ющее лицо /Цель показывают разрабатываемый набор вариантов использования; другие предпочитают диаграммы вариантов использования. Последние, отображая основных действующих лиц и соответствующие варианты использования уровня цели пользователя, могут иметь то же назначение, что и список Действующее лицо /Цель.

ВАРИАНТЫ ИСПОЛЬЗОВАНИЯ ТИПА "ПРОЗРАЧНОГО ЯЩИКА" И КООПЕРАТИВНЫЕ ДИАГРАММЫ. Существует почти полное соответствие между вариантами использования типа “прозрачного ящика” и кооперативными диаграммами UML. Варианты использования можно рассматривать как текстовую форму кооперативных диаграмм. Различие в том, что кооперативные диаграммы не описывают внутренних действий компонентов, что доступно варианту использования.

Неподходящие варианты.

ПРЕДЛОЖЕНИЯ С ЕСЛИ ВНУТРИ ОСНОВНОГО СЦЕНАРИЯ. Если бы в варианте ис пользования было только одно ветвление поведения, проще было бы его оставить в основном тексте. Однако в вариантах использования ветвлений много, и читатели теряют нить сюжета. Те, кто употребляют предложения с если, признаются, что вскоре приходят к форме основного сценария, за которым следуют расширения.

ДИАГРАММЫ ПОСЛЕДОВАТЕЛЬНОСТИ КАК ЗАМЕНА ТЕКСТА ВАРИАНТА ИСПОЛЬЗОВАНИЯ. Некоторые инструменты разработки программного обеспечения претендуют на поддержку вариантов использования на том основании, что создают диаграммы последовательности. Последние тоже показывают взаимодействия действующих лиц, но имеют следующие недостатки:.

■ Они не фиксируют внутренние действия (необходимые, чтобы продемонстрировать, как система защищает интересы участников).

■ Их намного труднее читать (используется специальная нотация, которая к тому же занимает намного больше места).

■ Практически невозможно втиснуть необходимый объем текста над стрелками между действующими лицами.

■ Большая часть инструментов вынуждает автора прятать текст за всплывающим окном диалога, что мешает следовать за сюжетом.

■ Большая часть инструментов вынуждает автора описывать каждый альтернативный путь независимо, возвращаясь каждый раз к началу варианта использования. Это утомительно, вызывает ошибки, а читателю трудно разобраться, чем отличается поведение в каждой вариации.

Диаграммы последовательности — не слишком хорошая форма представления. Ее предпочитают в связи с возможностями инструмента автоматически создавать перекрестные ссылки, гиперссылки в прямом и обратном направлении и глобально изменять имена. Несмотря на то что эти функции выполняются хорошо (и существует недостаток текстовых инструментов), большинство авторов и читателей согласны, что этого недостаточно, чтобы жертвовать удобством написания и читабельностью.

ГРАФИЧЕСКИЙ ИНТЕРФЕЙС ПОЛЬЗОВАТЕЛЯ В ФУНКЦИОНАЛЬНЫХ СПЕЦИФИКАЦИЯХ. Не нужно большого мастерства, чтобы писать требования, не определяя деталей интерфейса пользователя наряду с необходимой функцией. Этому нетрудно обучиться. Большинство заинтересованных лиц выступает против описания интерфейса пользователя в вариантах использования (см. раздел 19.6 и шагу Designing Software for Use, Costantine и Lockwood, 1999).

Памятка 15. Качество набора вариантов использования.

У меня есть только три вопроса относительно качества полного набора вариантов использования:.

■ Формулируют ли варианты использования сюжет, который развертывается от цели самого высокого уровня до цели самого низкого уровня?.

■ Существует ли на границе области действия проектирования вариант использования самого высокого уровня, устанавливающий контекст (возможно, для каждого основного действующего лица)?.

■ Это все, что необходимо разработать? (Вопрос предназначен заказчикам и пользователям.)

Памятка 16. Это только часть требований.

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

Это необходимо иметь в виду, так как некоторые группы пытаются втиснуть в варианты использования все множество требований.

Памятка 17. Сначала работа должна быть направлена в ширину.

Первоначальный охват должен быть широким, а не глубоким, от более низкой точности к более высокой. Круг работы расширяется с повышением точности (см. рис. 22.1), так что это поможет вам дозировать энергию (см. раздел 1.5). Порядок должен быть следующим:.

1 Основные действующие лица. Сначала перечислите всех действующих лиц, чтобы охватить на какое-то время всю систему. Чаще всего системы настолько необъятны, что вы вскоре потеряете все ориентиры, поэтому стоит взглянуть на систему в общем в начале работы. Организация “мозгового штурма” для выявления этих действующих лиц поможет вам получить большинство целей уже в первом цикле.

2. Цели. Перечисление всех целей всех основных действующих лиц — это, может быть, ваш последний шанс охватить всю систему. Сделайте этот список максимально полным и правильным. Следующие шаги вовлекут бо-.

льше людей и значительно увеличат объем работы. Проанализируйте список с пользователями, организаторами и разработчиками, чтобы они согласились с приоритетами и поняли разрабатываемую систему.

Рис, 22.1. С повышением точности увеличивается объем работы.

3.

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

4.

Условия неудачи (расширения). Зафиксируйте все условия расширения, прежде чем думать, как их обрабатывать. Это достигается путем “мозгового штурма”, который отличается от исследования и описания шагов обра-.

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

5.

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

6.

Поля данных. Хотя формально описание данных далеко от процесса создания вариантов использования, разработчики часто получают задание развертывать имена данных (например, “данные о клиенте”).

в списки полей данных (см. раздел 16.1).

7.

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

в конце концов разработаны.

Памятка 18. Рецепт из 12 шагов.

1.

Найдите границы системы (контекстная диаграмма, список ввода/вывода).

2.

Методом “мозгового штурма” составьте список основных действующих лиц (таблица профилей действующих лиц).

3.

Методом “мозгового штурма” составьте список целей основных действующих лиц в отношении системы (список Действующее лицо/Цель).

4.

Напишите предельные варианты использования обобщенного уровня, охватывающие все вышеназванные составляющие.

5.

Пересмотрите и модифицируйте стратегические варианты использования. Добавьте, удалите и объедините цели.

6.

Выберите вариант использования для расширения или напишите повествование, чтобы познакомиться с материалом.

7.

Запишите участников, интересы, предусловия и гарантии. Дважды проверьте.

8.

Напишите основной сценарий; проверьте, соблюдаются ли в нем интересы и гарантии.

9.

Методом “мозгового штурма” составьте список возможных условий неудачи и альтернативных условий успеха.

10.

Опишите поведение действующих лиц и системы в каждом расширении.

11.

Выделите каждый подчиненный вариант использования, которому необходимо собственное пространство.

12.

Начните с вершины и уточните созданные варианты использования. Произведите надлежащие добавления, удаления и объединения. Дважды проверьте завершенность, удобочитаемость и условия неудачи.

Памятка 19. Не забывайте, во что обходятся ошибки.

Чего вам будет стоить низкое качество варианта использования зависит от вашей системы и проекта. Некоторые проекты почти не нуждаются в качественных формулировках требований вследствие превосходно налаженного взаимодействия пользователей и разработчиков.

Проектная группа компании Chrysler Comprehensive Compensation, разрабатывая программное обеспечение для расчета зарплаты с помощью методов eXtreme Programming (Beck, 1999), никогда не выходила за пределы кратких описаний вариантов использования. Они писали так мало, что называли свои произведения “рассказами”, а не вариантами использования, и помещали их на учетных карточках. При этом был необходим разговор с экспертом по требованиям и разработчиком, четырнадцать членов группы работали в двух соседних комнатах и имели возможность общения внутри группы.

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

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

Памятка 20. Лучше меньше, но понятней.

Как ни странно это звучит, вы, скорее всего, понесете меньший ущерб, если напишете слишком мало, а не слишком много. Когда есть сомнения, пишите меньше, используя.

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

Противоположная стратегия приводит к неудаче. Если вы написали около сотни очень подробных вариантов использования низкого уровня, их мало кто прочтет, и обсуждения в группе не будет. Написание на слишком низком уровне цели — распространенный недостаток программистов.

■ Невымышленная история.

Работая в успешном проекте на $15 млн, в котором участвовало 50 человек, мы написали только основной сценарий и обработку нескольких ошибок просто в виде текста с абзацами. Этого было достаточно, поскольку у нас были отличные условия взаимодействия. Каждый автор требований работал в группе с двумя-тремя разработчиками-программистами. Они сидели по соседству либо посещали друг друга несколько раз в день.

На самом деле повышение качества взаимодействия внутри группы помогает в каждом проекте. Стратегия организации описанной выше группы — это образец Целостного многообразия (Holistic Diversity) из книги Surviving Object-Oriented Projects (Cockburn, 1998).

Памятка 21. Обработка ошибок.

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

If

условие >

then else ..?.

Здесь он останавливается, размышляя над else, так как в требованиях ничего не говорится об этом странном условии. Затем он быстренько записывает в программу нечто вроде:.

else.

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

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

Если вы создаете только основной сценарий, попробуйте охватить неудачи и обработку ошибок в следующих вариантах использования. Вы, вероятно, будете удивлены и воодушевлены тем, что вам откроется.

Памятка 22. Первоначальные и конечные названия работ.

Названия важны в начальной и в конечной стадиях работы над проектом, но не в середине деятельности.

В начале работы вам необходимо собрать все дели, которые должна удовлетворять система, и представить их в удобочитаемой форме. Фокусирование на названиях работ или социальных ролях, на которые будет воздействовать система, позволяет эффективно провести “мозговой штурм” и выполнить наилучшим образом первый проход выявления целей. Когда длинный список целей будет готов, названия работ обеспечат также схему группирования, облегчающую анализ и расстановку приоритетов обозначенных целей.

Названия работ дают представление о навыках и стилях, необходимых для различных работ. Эта информация полезна для проектирования интерфейса пользователя.

Когда начинается разработка вариантов использования, в процессе обсуждений обнаруживается, как перекрываются роли. Названия ролей, употребляемые для основных действующих лиц, становятся более обобщенными (например, “заказчик”) или более отдаленными от людей, которые будут на самом деле пользоваться систе-

мой. Пока они только “заглушки”, напоминающие писателям, что на самом деле есть действующее лицо, имеющее цель.

Когда система вводится в эксплуатацию, названия работ опять приобретают важность. Группа разработчиков должна:.

* Назначить уровни доступа определенным пользователям для обновления или, возможно, только чтения каждого вида данных.

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

* Упаковать систему для установки, разложив реализации вариантов использования по кластерам.

Памятка 23. Действующие лица играют роли.

Термин “действующее лицо” означает либо название работы индивидуума, применяющего систему, либо роль, которую этот индивидуум играет при использовании системы. Не столь важно, как мы употребляем термины, так что не тратьте слишком много сил на определение различий.

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

* Написать в варианте использования, что основным действующим лицом является “продавец либо директор магазина”. (Приверженцам UML: нарисуйте стрелки к эллипсу от обоих действующих лиц.).

* Написать, что при выполнении этого варианта использования директор магазина может выступать в роли продавца. (Приверженцам UML: нарисуйте стрелку обобщения от директора магазина к продавцу.).

* Сделайте “заказчика” основным действующим лицом. Напишите, что при выполнении этого варианта использования продавец или директор магазина выступает в роли заказчика. (Приверженцам UML: нарисуйте стрелку обобщения от продавца и директора магазина к заказчику.).

Все формулировки верны, так что можете выбрать любую.

Индивидуум исполняет много ролей, индивидуум в действии — это просто лицо, исполняющее роль. Лицо, имя которого — это название работы, выступает во многих ролях, даже если действует в роли, соответствующей названию этой работы. Для варианта использования важно не имя основного действующего лица, а цель. В проектной группе полезно установить соглашение о поддержке непротиворечивости в употреблении названий работ.

Как имена действующих лиц меняются на названия ролей и отображаются обратно в имена действующих лиц, см. в разделе 4.2, подраздел о несущественных и су^ щественных действующих лицах, а также в памятке 22.

Памятка 24. Большая графическая мистификация.

С тех пор как вышла книга Object-Oriented Software Engineering (1993) многие авторы при создании вариантов использования сфокусировали внимание на фигурах из палочек и эллипсах, упуская из виду, что варианты использования — это текстовая форма представления. Развитая индустрия CASE-средств, которая уже располагала графическими, а не текстовыми средствами моделирования, ухватилась за этот факт и представила инструменты, способные довести количество рисунков в вариантах использования до максимума. Эта ситуация не была исправлена в стандарте Unified Modeling Language, принятом OMG. Как мне объяснили, UML — это лишь стандарт обмена между различными инструментами. Следовательно, текст, прячущийся каким-то образом за каждым эллипсом, не входит в стандарт и является частным делом каждого автора.

Сейчас очень многие думают, что эллипсы и есть варианты использования, даже учитывая, что они несут очень мало информации. Опытные разработчики могут отнестись к этому довольно саркастически. Выражаю благодарность Энди Ханту и Дэйву Томасу за их удачную шутку по поводу взглвда на варианты использования как на “легко полученные требования” (см. рис. 22.2; из книги The Pragmatic Programmer, 1999).

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

* Оглавление вариантов использования.

* Контекстная диаграмма системы, показывающая, как действующие лица добиваются различных и перекрывающихся целей.

* “Большая картина”, показывающая отношение между вариантами использования более высокого уровня и более низкого уровня.

Варианты использования — это в основном текстовая форма, поэтому применяйте эллипсы для наглядности, а не в качестве замены. На рис. 22.3 и в таблице 22.1 показаны два способа представления контекстной диаграммы. В таблице содержатся те же действующие лица и цели, причем общие варианты использования для ясности повторяются.

Памятка 25. Дебаты об инструментах.

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

LOTUS NOTES. Он является моим любимым инструментом, однако не имеет метамодели вариантов использования, зато поддерживает совместную работу, гиперссылки, общий шаблон, историю документа, быстрый просмотр с редактированием всего набора вариантов использования и легко конструируемые упорядоченные представления. Все это важные достоинства. Lotus Notes также позволяет держать расширяющиеся описания данных в одной базе данных, но в различных представлениях. Когда вы обновляете шаблон, изменяются все варианты использования в базе данных. Шаблон довольно легко настраивать и чрезвычайно просто применять. С помощью Lotus Notes я просмотрел свыше 200 вариантов использования с заказчиками в связи с заявкой на проект с фиксированной стоимостью.

Недостатком Lotus Notes, как и всех инструментов для текстов в свободной форме, является то, что перенумерация шагов и расширений вскоре становится помехой. Вставляемые вручную обратные связи быстро устаревают. Не автоматизирована работа с обратными связями и гиперссылками, поэтому нельзя сказать, какой вариант использования вызывает тот вариант, на который вы смотрите.

Мне больше всего нравится в Lotus Notes легкость применения в сочетании с тем, как аннотированный список Действующее лицо/Цель обеспечивает динамическое генерирование представления набора вариантов использования. Просто создайте новый вариант использования, и он моментально появится в представлении.

Представление — это одновременно оглавление с гиперссылками, список Действующее лицо/Цель и таблица отслеживания хода работ. Мне нравятся представления вариантов использования по приоритетам, версиям, состоянию завершенности, названию, основному действующему лицу, предметной области, уровню и названию.

ТЕКСТОВЫЕ ПРОЦЕССОРЫ С ГИПЕРССЫЛКАМИ. С появлением гиперссылок текстовые процессоры стали, наконец, приспособленными для работы с вариантами использования. Поместите шаблон варианта использования в файл шаблонов. Каждый вариант использования запишите с помощью шаблона в отдельный текстовый файл, и без проблем устанавливайте связи между вариантами использования. Только не изменяйте имена файлов! Авторы обычно знакомы с текстовыми процессорами, и им удобно создавать описания с их помощью.

Текстовым процессорам присущи все недостатки Lotus Notes. Кроме того, у них нет возможности создавать список всех вариантов использования, отсортированный по версии или статусу, и открывать их щелчком мыши. Это означает, что нужно генерировать и поддерживать отдельный список для просмотра, который быстро устаревает. Не существует глобального механизма обновления шаблона, и поэтому со временем версии шаблона накапливаются.

РЕЛЯЦИОННЫЕ БАЗЫ ДАННЫХ. Я знаю о нескольких попытках создать модель действующих лиц, целей и шагов в реляционной базе данных, такой как Microsoft Access. Хотя это желание естественно, инструменты неудобны в применении, и разработчики вариантов использования возвращаются к своим текстовым процессорам.

СРЕДСТВА УПРАВЛЕНИЯ ТРЕБОВАНИЯМИ. Специализированные средства управления требованиями, такие как DOORS и Requisite Pro, получают все большее распространение. Они обеспечивают поддержку прямых и обратных гиперссылок и предназначены для текстовых описаний требований. Недостатком является отсутствие (насколько мне известно) поддержки модели основного сценария и расширений, т.е. ядра вариантов использования. Несколько вариантов использования, которые я видел и которые были получены с помощью таких средств, были очень длинными, с многочисленными отступами, обилием нумерации и строк, что затрудняло их чтение (см. памятки 2 и 20). Если вы применяете подобный инструмент, сделайте так, чтобы сюжет был ясно виден.

CASE-CPEACTBA. CASE-средства поддерживают глобальные изменения любой составляющей метамодели и обратные связи. Однако, как описано выше, они склонны к использованию блоков и стрелок в ущерб тексту. Диаграммы последовательности не являются приемлемой заменой текстовым вариантам использования, и большая часть CASE-средств предлагает лишь диалоговое окно для ввода текста. Я был свидетелем того, как группа разработчиков вариантов использования взбунтовалась, оставила CASE-средства и вернулась к текстовому редактору.

Это оставляет вам, мягко говоря, небольшой выбор. Удачи.

Памятка 26. Планирование проекта с помощью названий и кратких описаний.

Плюсы и минусы применения вариантов использования для отслеживания продвижения проекта приведены в разделе 17.1. Там же вы найдете пример списка Действующее лицо/Цель в качестве основы для планирования проекта. Вот две памятки.

ТАБЛИЦА ПЛАНИРОВАНИЯ ВАРИАНТА ИСПОЛЬЗОВАНИЯ. В первых двух столбцах таблицы запишите действующих лиц и цели, а в следующих столбцах — необходимые вам атрибуты из следующего списка: ценность для бизнеса, сложность, версию, группу, завершенность, требование к производительности, внешние интерфейсы и т.д.

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

ВЫПУСК НЕПОЛНЫХ ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ. Как описано в подразделе об управлении пересекающимися версиями вариантов использования (см. раздел 17.1), вам придется довольно часто принимать решение о выпуске только части варианта использования в определенной версии. В большинстве групп просто применяют выделение желтым цветом или жирным шрифтом, чтобы обозначать фрагменты варианта использования. Отметьте в таблице планирования первую версию выпущенного варианта использования и его окончательную версию, которая представит этот вариант использования в полном виде.

Приложения.

Приложение А_.

Варианты использования на языке UML.

Унифицированный язык моделирования UML определяет набор используемых графических нотаций. Он не касается содержания варианта использования и стиля изложения, но создает значительные сложности при их обсуждениях. Лучше научиться писать ясные тексты. Если вам нравятся диаграммы, освойте основы отношений и затем введите несколько простых стандартов, чтобы диаграммы были понятны.

АЛ. Эллипсы и фигуры из палочек.

Если вы хотите графически изобразить, как люди применяют систему, вполне естественно нарисовать пользователя в виде фигурки из палочек, а варианты использования, которые он вызывает, в виде эллипсов или прямоугольников. Пометьте фигурку из палочек именем действующего лица, а эллипсы названиями вариантов использования. Информация та же, что в списке Действующее лицо/Цель, но представлена по-другому. Эта диаграмма подойдет в качестве оглавления.

Пока все очевидно.

Проблема возникает, когда авторы или читатели решают, что диаграммы определяют функциональные требования к системе. Некоторые становятся фанатиками диаграмм, думая, что смогут легко выполнить трудную работу (как на рис 22.1). Они стараются втиснуть в диаграмму как можно больше информации, возможно, надеясь, что писать текст уже не придется. Ниже описано, что происходит в этой ситуации.

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

Другой с гордостью демонстрировал, как он “исправил” очевидный дефект диаграммы, которая не показывала порядок вызова вариантов использования. Он добавил еще стрелок, направленных на предшествующий вариант использования, с помощью связи предшествования UML. В результате, конечно, получилась чрезвычайно запутанная диаграмма, которая заняла больше места, чем эквивалентный текст, и в которой труднее было разобраться. В данном случае графика не сделала вариант использования ни лаконичным, ни наглядным, скорее наоборот.

Рисунок — это двумерная мнемоническая схема, которая служит выделению связей. Применяйте его для данной задачи, а не заменяйте им текст.

Имея в виду это предназначение, рассмотрим отдельные связи в UML.

А.2. Связь включения.

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

Глагольная группа в шаге действия может служить названием подчиненного варианта использования. Если вы никогда не выделите эту цель, это будет просто шаг. А если вы выделяете эту цель в самостоятельный вариант использования, этот шаг вызывает подчиненный вариант использования (в моей терминологии) или он включает поведение включенного варианта использования (в терминах текущей версии UML 1.3). До UML 1.3 это называлось “применять” (use) вариант использования более низкого уровня (ныне это выражение устарело).

Штриховая линия со стрелкой идет от основного (более высокого уровня) варианта использования к включенному варианту использования, обозначая, что основной вариант использования “знает” о включенном, как показано на рис. А. 1.

Рис, А.1. Использование связей включения.

Правило 13. Более высокие цели изображайте выше.

Всегда изображайте на диаграмме цели более высокого уровня над целями более низкого уровня. Это уменьшает путаницу с уровнями цели и интуитивно понятно читателям. При этом стрелка от основного варианта использования к включенному всегда будет направлена вниз.

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

Для большинства программистов должно быть очевидно, что связь включения — это традиционный вызов подпрограммы (процедуры) в переводе на язык программирования. Это естественное применение механизма, который подходит и для программирования, и для повседневной жизни. Иногда это соответствует параметризованным вариантам использования, передаче им значений аргументов функции и даже получению от них возвращаемых значений (см. главу 14). Несмотря на это, имейте в виду, что вариант использования предназначен для взаимодействия с другим лицом, а не с CASE-средством или компилятором.

АЗ. Связь расширения.

Расширяющий вариант использования или вариант использования расширения расширяет основной вариант использования, именуя его и определяя условия, при которых он прерывает основной вариант использования. Последний не называет расширяющий вариант использования. Это полезно, если вы хотите, чтобы основной вариант использования прерывало несколько вариантов использования без обновления основного варианта использования при добавлении каждого нового прерывающего варианта использования (см. раздел 10.2).

С точки зрения поведения, расширяющий вариант использования определяет некоторое внутреннее условие в основном варианте использования и условие запуска. Поведение определяет основной вариант использования, пока не выполнится условие. С этого момента его определяет расширяющий вариант использования. Когда расширяющий вариант использования заканчивается, управление получает основной вариант использования с той точки, где его выполнение прекратилось.

Ребекка Вирс-Брок удачно назвала расширяющий вариант использования “заплатой” (patch) на основном варианте использования (для программистов это должно ассоциироваться с программными “заплатами”). Другие программисты понимают это как текстовую версию фиктивной программной команды, оператора come-from).

Мы обычно используем форму расширения, когда пишем условия расширения в варианте использования. Вариант использования расширения — это просто условие расширения, обработка которого выделена в самостоятельный вариант использования (см. раздел 10.2). Считайте это расширением сценария, который перерос свой вариант использования и получил собственное место.

По умолчанию связь расширения обозначается в UML штриховой линией со стрелкой (так же, как и связь включения) от расширяющего варианта использования к основному со словом “” над стрелкой. Я изображаю это с помощью крючка от расширяющего варианта использования назад к основному (см. рис. А.2), чтобы подчеркнуть различие между связями включения и расширения.

Рис. А.2. Изображение связи расширения.

На рис. А.2(а) вы видите стандартный способ изображения в UML связи расширения (пример взят из книги UML Distilled (Fowler, 1999)). На рис. А.2(Ь) показан коннектор в виде крючка.

Правило 14. Изображайте расширяющие варианты использования ниже.

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

Правило 15. Используйте различные формы стрелок.

В UML намеренно не решен вопрос о форме стрелок, соединяющих варианты использования. Любую связь можно изобразить с помощью стрелки с открытым острием и небольшим текстом, объясняющим, что это за связь. Идея заключается в том, что если различные поставщики инструментов или проектные группы захотят переделать форму стрелки, стандарт UML не должен этому препятствовать.

Плохо то, что одинаковые стрелки используются для всех связей — это затрудняет просмотр диаграммы. Читатель вынужден изучать мелкий текст, чтобы определить, какие же связи обозначены. Кроме того, их сложно запомнить из-за отсутствия простых визуальных подсказок. Все это, а также отсутствие других соглашений об изображении делает многие диаграммы вариантов использования малопонятными. По этой причине определите разные формы стрелок, учитывая три вида связи:.

■ Включение. Используйте форму стрелки по умолчанию, с открытым острием, так как она будет употребляться чаще других.

■ Обобщение. Стандарт стрелки обобщения в UML — стрелка с острием в виде треугольника. Употребляйте именно ее.

■ Расширение. Создайте совершенно другую форму. Я предпочитаю крючок, направленный от расширяющего к основному варианту использования. Читатели понимают его назначение сразу, он не конфликтует с другими символами UML и привносит собственную метафору расширяющего варианта использования, прицепившегося к основному. Что бы вы ни выбрали, сделайте так, чтобы на диаграмме коннектор расширения отличался от других.

Корректное использование расширения.

Создание вариантов использования расширения (см. раздел 10.2, подраздел о вариантах использования расширения) связано в основном с наличием большого количества асинхронных услуг, которые может активизировать пользователь, прерывая основной вариант использования. Часто они разрабатываются разными группами. Эти случаи реализуются в отдельных пакетах программного обеспечения (см. рис. А.З).

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

РИС. А.З. Три прерывающих варианта использования, которые расширяют.

Точки расширения.

Связь расширения была введена прежде всего благодаря практике никогда не трогать документ с требованиями предыдущей системы. В первых телефонных системах, для которых разрабатывались варианты использования, бизнес часто требовал добавления асинхронных услуг, поэтому связь расширения была удобной.

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

Однако обращение к поведению в другом варианте использования проблематично. Если нет нумерации строк, как следует обращаться к точке, с которой управление поведением переходит к расширению? А что происходит при наличии нумерации строк, когда основной вариант использования редактируется и номера строк изменяются?.

Помните, что номера строк — это на самом деле их метки. Поэтому они не должны быть числовыми или последовательными. Они облегчают чтение и служат для того, чтобы условия расширения имели точку обращения. Однако обычно они являются последовательными числами, и это значит, что со временем они будут изменяться.

Точки расширения были введены, чтобы решить эти вопросы. Точка расширения — это явно видимая метка в основном варианте использования, которая обозначает момент в поведении варианта использования с помощью краткого имени (технически она может обращаться к множеству мест, но сейчас мы это не обсуждаем).

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

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

Если вы устанавливаете точки расширения, не показывайте их на диаграмме. Они занимают большую часть площади эллипса, поглощая внимание пользователя и затеняя гораздо более важное название цели (см. рис. А.2). Поведение, к которому они обращаются, на диаграмме не показано. Они только увеличивают путаницу.

И еще кое-что о точках расширения. С помощью имени точки расширения разрешается вызвать не одно только место в основном варианте использования, в котором расширяющим вариантам использования необходимо подключить дополнительное описание поведения, а столько, сколько вы пожелаете. Это может понадобиться, скажем, для банкомата при добавлении варианта использования расширения Использовать банкомат другого банка. В расширяющем варианте использования необходимо записать:.

Перед тем, как выполнить транзакцию, система получает разрешение.

клиента заплатить за дополнительную услугу.

После завершения запрошенной транзакции система вносит на счет клиента.

оплату дополнительной услуги.

Конечно, вы могли бы просто сказать об этом.

А.4. Связь обобщения.

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

Корректное использование связи обобщения.

Хорошим проверочным словом является обобщенный (т.е. определенного типа). Будьте осторожны, когда говорите, что пользователь выполняет некоторую разновидность этого действия. Говоря так, вы получаете кандидата для обобщения.

Вот фрагмент варианта использования Использовать банкомат.

1.

Клиент вводит карточку и PIN.

2.

Банкомат удостоверяется в правильности номера счета и PIN клиента.

3.

Клиент выполняет транзакцию, одну из:.

Извлечь наличные Внести наличные на счет Перевести деньги Проверить баланс Клиент выполняет транзакции, пока не выберет пункт меню "завершить сеанс".

4.

Банкомат возвращает карту.

Что выполняет клиент на шаге 3? Обобщенный ответ — “транзакцию”. Для клиента существуют четыре типа транзакции. Слова “обобщенный” и “типа" предупреждают нас о присутствии обобщенной цели Выполнить транзакцию. В версии с обычным текстом мы не замечаем, что применяем связь обобщения между вариантами использования. Мы просто перечисляем типы операций или транзакций, которые может выполнить пользователь, и идем дальше. В UML, однако, это служит сигналом для рисования стрелки обобщения.

На самом деле здесь две возможности. Можно игнорировать обобщение и просто включить определенные операции, как показано на рис. A.4(a). Можно также создать общий вариант использования Выполнить одну транзакцию и представить определенные операции в качестве его специализаций, как на рис. A.4(b).

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

Рис. А.4. Изображение обобщения; набор включенных вариантов.

использования превращается в специализации обобщенного действия

Правило 16. Общие цели изображайте выше.

На диаграмме всегда изображайте общие цели выше. Треугольное острие стрелки должно указывать вверх и в дно эллипса общей цели, а не в его бока (см. рис. А.4).

Опасности обобщения.

Будьте осторожны при сочетании специализации действующих лиц со специализацией вариантов использования. Идиома во избежание этого — специализированное действующее лицо, применяющее специализированный вариант использования. На рис. А.5 отображена ситуация: служащий отдела продаж может заключить любую сделку, но заключить сделку сверх определенного лимита может служащий отдела продаж специального типа, старший агент. Тем не менее в действительности это выражает противоположное.

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

Другая специализация представляется вполне естественной: заключение большой сделки — специальный случай заключения обычной сделки. Однако согласно правилу UML, специализированный вариант использования можно подставить везде, где упоминается общий вариант использования. Поэтому на рисунке показано, что обычный служащий отдела продаж может заключить большую сделку!

РИС. А.5. Рискованное обобщение — заключение большой сделки.

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

Старший агент.

Рис. А.6. Правильное заключение большой сделки.

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

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

А.5. Зависимые и подчиненные варианты использования.

В расширенном текстовом разделе спецификации UML 1.3 авторы описывают две малоизвестные связи между вариантами использования, которые не имеют двойников на диаграмме и не определены на языке связей объектов, а просто записываются в пояснительном тексте. Это зависимые варианты использования и их противоположность — независимые варианты использования.

Назначение этих связей — показать, как варианты использования компонентов системы работают вместе, чтобы реализовать вариант использования более крупной части системы. Сами компоненты системы не показаны. Вместо соответствующих вариантов использования присутствуют заглушки. Это выглядит так, как будто вам пришлось изобразить анонимную кооперативную диаграмму, особый вид функциональной декомпозиции, который вы позднее планируете пояснить с помощью надлежащей кооперативной диаграммы. Согласно спецификации UML: Вариант использования, определяющий один элемент модели, затем детализируется и превращается в ряд более мелких вариантов использования, каждый из которых описывает услугу элемента модели, содержащуюся в нем... Однако обратите внимание, что структура содержащего элемента не показывается в вариантах использования, так как они лишь определяют функции, предоставляемые элементом. Зависимые варианты использования взаимодействуют для выполнения независимого варианта использования. Их взаимодействие определяется кооперацией и может быть представлено в кооперативных диаграммах.

Цель ввода этих специфических связей в пояснительный текст спецификации варианта использования неясна, и я не собираюсь ее объяснять. Я только предоставляю факты, поскольку в этой книге я употребляю термин “подчиненный вариант использования”, и кто-нибудь может спросить, чем отличается подчиненный вариант использования Коберна от зависимого варианта использования в UML.

Здесь термин подчиненный вариант использования обозначает цель более низкого уровня. Обычно вариант использования более высокого уровня будет вызывать (включать) подчиненный вариант использования. Я предпочитаю термины "зависимый" и “независимый” для вариантов использования более низкого и более высокого уровня, но с тех пор как в UML 1.3 появились эти слова, я изменил лексику. Мой опыт показывает, что люди не находят ничего странного в терминах “вызывающий вариант использования” и “подчиненный вариант использования”. Они понятны даже начинающему автору или читателю.

А.6. Изображение диаграмм вариантов использования.

Диаграммы вариантов использования облегчат вам общение с читателями, если вы установите несколько простых соглашений по диаграммам и будете их выполнять. Пожалуйста, не заставляйте своих читателей пробираться через джунгли стрелок, ожидая при этом, что они проследят вашу мысль. Правила 13-16 для различных связей вариантов использования помогут вам в этом. Вот еще два полезных правила:.

Правило 17. Цели пользователя в контекстной диаграмме.

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

Правило 18. Вспомогательные действующие лица должны быть справа.

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

А.7. Вместо диаграмм пишите текстовые варианты использования.

Не уделяйте слишком много времени изучению графики и связей. Приложите лучше силы к написанию легкого для чтения повествования. В тексте прямо указаны связи между вариантами использования.

Это мнение разделяют многие эксперты по вариантам использования. С моей стороны, наверное, нескромно упоминать о следующем событии, но я хочу подчеркнуть серьезность совета. Приношу благодарность Брюсу Андерсону из European Object Technology Practice (IBM) за комментарий, который он сделал во время встречи специалистов по вариантам использования на OOPSLA ‘98. В ходе встречи возник ряд вопросов о различиях между связями включения и расширения и о затруднениях в связи с лавиной сценариев и эллипсов. Брюс заявил, что в его группе не произошло катастрофичного размножения сценариев и не было никакой путаницы. Он заявил, что он делает то, что говорит Алистер. Это означает, что следует писать ясные тексты, избегая связей расширения, и оставить в покое диаграммы.

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

Приложение В_.

Ответы к упражнениям.

Глава 3.

Упражнение 3.1.

Можно описать окрестности или ряд объединенных сетью предприятий. Можно также спроектировать систему управления зданием и освещением банка или новую банковскую компьютерную систему и банкомат или просто банкомат. Можно обсудить проект новой клавишной панели или проект новой клавиши “Enter”.

Из этого фрагмента повествования не видно, какая система обсуждается.

Упражнение 3.2.

Нельзя сказать по фрагменту из истории пользователя, какая система обсуждается.

Глава 4.

Упражнение 4.2.

Вспомните тесты “прошел/не прошел”. Поведение действующего лица должно соответствовать предложению с если. Основное действующее лицо имеет цель, вызывающую услугу, которая предоставляется системой.

Банкомат. Разрабатываемая система (SuD).

Клиент. Основное действующее лицо и участник.

Карточка для банкомата. Не является действующим лицом. Не обладает достаточно развитым поведением (это относится к магнитным картам; смарт-карты с встроенными чипами могут оценивать). Карточка для банкомата на самом деле просто конверт для данных, и ее назначение —быстрый ввод постоянных данных клиента.

Банк. Не является действующим лицом для нашей задачи. Это система, в состав которой входит банкомат.

Рис. В.1. Области действия проектирования для банкомата.

Передняя панель. Не является действующим лицом для нашей задачи. Это компонент SuD.

Владелец банка. Участник, возможно, второстепенное действующее лицо. Наладчик. Основное действующее лицо.

Принтер. Не является действующим лицом для нашей задачи. Это компонент SuD.

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

Банковский кассир. Зависит от выполняемой работы. Кто опорожняет банкомат и загружает его наличными? Если вы скажете “загрузчик” или “обслуживающий персонал”, вы, возможно, никогда не создадите вариант использования с банковским кассиром в качестве основного действующего лица. Если вы ответите: “Банковский кассир”, он будет основным действующим лицом.

Грабитель банков. Зависит от области действия проектирования и вашего творчества. Мне бы не пришел в голову вариант использования для грабителя банков вместо условия расширения варианта использования клиента, если бы кто-то не предложил ограбить банкомат. Это породило идею о детекторе движения. В зависимости от того, как мы формулируем цель, мы можем закончить отдельным вариантом использования для грабителя (чья цель никогда не будет достигнута), либо просто дополнительными условиями расширения в варианте использования клиента.

Упражнение 4.3.

Ответы зависят от того, какую охватывающую систему вы выбираете (см. рис. В. 1). Банкомат. Не является действующим лицом для нашей задачи. Сейчас это компонент SuD.

Клиент. По-прежнему основное действующее лицо и участник.

Карточка банкомата. Не является действующим лицом по тем же причинам, что и в упражнении 4.2 (с теми же объяснениями).

Банк. Посмотрите на рис. В. 1. Если в качестве охватывающей системы вы выбираете “банк с людьми”, то это ваша SuD. Если же вы выбираете “электронную банковскую сеть”, это, скорее всего, действующее лицо (зависит от того, можете ли вы обосновать услугу электронной банковской сети, за которой он обращается).

Передняя панель. Не является действующим лицом для нашей задачи. Это компонент.

Владелец банка. Зависит от того, какую охватывающую систему вы выбираете, и каковы ваши цели. Его можно определить как компонент банка и, следовательно, второстепенное действующее лицо, либо как основное действующее лицо банка, которое, возможно, не является основным действующим лицом электронной банковской системы.

Наладчик. Основное действующее лицо, если его наняли в другой организации, и компонент, если является работником банка и в качестве SuD вы выбрали банк.

Принтер. Не является действующим лицом для нашей задачи. Это компонент разрабатываемой системы.

Основная банковская компьютерная система. Теперь это компонент охватывающей системы (любой из вышеназванных).

Банковский кассир. Компонент (банка) или, может быть, основное действующее лицо электронной банковской системы.

Грабитель банков. То же, что в упражнении 4.2.

Глава 5.

Упражнение 5.1.

■ Обобщенный (белый). Пригласить кого-нибудь на обед О (возможно, сложно для случая с банкоматом).

■ Обобщенный (белый). Использовать банкомат .

■ Цель пользователя (голубой). Получить деньги из банкомата ЗА.

■ Подфункция (индиго). Ввести PIN К3>.

■ Подфункция (черный). Найти кнопку Ввод .

Глава 6.

Упражнение 6.1.

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

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

Интересы банка будут ущемлены, если клиент получит больше наличных, чем внесенная в дебет сумма. Банку тоже нужно защитить себя, возможно, с помощью особого вида регистрации, которая позволит узнать, как далеко зашла транзакция в случае катастрофического отказа, чтобы можно было разобраться с любыми ошибками.

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

В результате у нас есть минимальные гарантии, что дебетованная сумма равна выданной сумме. При этом производится микрорегистрация транзакции, что в случае катастрофического отказа позволяет определить, как далеко продвинулось ее выполнение. Регистрируются все транзакции.

Упражнение 6.4.

Гарантия успеха — это когда в дебет внесена сумма, выданная наличными (а не запрошенная — проверьте условие неудачи), карточка возвращена, машина приведена в исходное состояние и транзакция зарегистрирована.

Глава 7 Упражнение 7.1.

Ниже представлено подробное описание интерфейса для извлечения наличных из банкомата. Выпуск 100 подобных вариантов использования сделает несчастными нескольких читателей. Упражнение 7.2 дает пример описания намерений, а не интерфейса.

1.

Клиент пропускает картонку для банкомата через считывающее устройство.

2.

Банкомат считывает ID (идентификатор) банка и номер счета.

3.

Банкомат спрашивает клиента, на каком языке продолжать: испанском или английском.

4.

Клиент выбирает английский.

5.

Банкомат просит ввести PIN, а затем нажать на "Ввод" (Enter).

6.

Клиент вводит PIN, нажимает на "Ввод".

7.

Банкомат представляет список действий для клиента.

8.

Клиент выбирает "извлечь наличные".

9.

Банкомат просит клиента ввести сумму, кратную $5, и нажать на "Ввод".

10.

Клиент вводит сумму, кратную $5, и нажимает на "Ввод".

11.

Банкомат уведомляет основную банковскую систему о номере счета клиента и требуемой сумме.

12.

Основная банковская система соглашается выдать наличные, сообщает банкомату новый баланс.

13.

Банкомат выдает наличные.

14.

Банкомат спрашивает, нужна ли клиенту квитанция.

15.

Клиент отвечает "да".

16.

Банкомат выдает квитанцию, показывая новый баланс.

17.

Банкомат регистрирует транзакцию.

Упражнение 7.2.

Вот рациональная версия Быстрого получения наличных, показывающая намерения действующих лиц.

1.

Клиент пропускает карточку для банкомата через считывающее устройство.

2.

Банкомат считывает с карточки Ю банка и номер счета, подтверждает их с помощью главного компьютера.

3.

Клиент вводит PIN, банкомат подтверждает PIN.

4.

Клиент выбирает быстрые наличные (FASTCASH) и указывает сумму, кратную $5.

5.

Банкомат уведомляет основную банковскую систему о номере счета клиента, требуемой сумме и получает подтверждение и новый баланс.

6.

Банкомат выдает наличные, карточку и квитанцию, показывая новый баланс.

7.

Банкомат регистрирует транзакцию.

Упражнение 7.4.

Пример содержит ошибки трех видов. Первое, что нужно понять —регистрация в системе не является назначением этого варианта использования, несмотря на его название и характеристику. Он посвящен использованию системы обработки заказов. Правильным в данном случае является обобщенный вариант использования уровня воздушного змея. Первые шесть шагов говорят о регистрации, но они совсем другого уровня и должны быть выделены. Сделав это, мы обнаружим, что пользователь входит в систему, но никогда из нее не выходит!.

Пока пользователь не выберет "выйти из цикла", конец предложения с если и конец цикла — это структуры программиста, они не имеют смысла для читателей варианта использования. Многочисленные предложения с если загромождают текст. Шаги описывают проектирование интерфейса пользователя. Все это следует исправить.

Вариант использования запускается, когда... и Вариант использования завершается, когда... — это стилистические соглашения, предлагаемые некоторыми преподавателями. В них все правильно. Однако я считаю их излишними. Само собой разумеется, что вариант использования начинается с первого шага и заканчивается, когда кончается описание.

Другой стиль — это формулировка Пользователь..., затем применить Разместить заказ. Применить в этом предложении указывает на связь включения UML (прежде называлась связью использования). Я считаю, это больше запутывает, чем проясняет чтение, поэтому предпочитаю писать Пользователь... размешает заказ. Вы можете следовать любому соглашению, которое установит ваша проектная группа для взаимодействия с другими вариантами использования.

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

Вариант использования 38 О Использовать систему обработки заказов Р.

Основной сценарий:.

1.

Пользователь регистрируется в системе.

2.

Система представляет доступные функции. Пользователь выбирает и выполняет одну из них:.

Разместить заказ Отменить заказ Получить статус Послать каталог Зарегистрировать жалобу Выдать отчет по продажам.

3.

Это повторяется, пока пользователь не решит выйти.

4. Система регистрирует выход пользователя, когда пользователь указывает на выход.

Глава 8 Упражнение 8.1.

Это пример условий неудачи. Обычно на моих курсах писали список раза в два длиннее этого. Обратите внимание, что все условия поддаются обнаружению и должны быть обработаны. А как вы написали?.

Сломался считыватель карточек или карточка повреждена.

Карточка банка, с которым банкомат не работает.

Неверный PIN.

Клиент вовремя не ввел PIN.

Банкомат не работает.

Главный компьютер не работает или сеть не работает.

Недостаточная сумма на счете.

Клиент вовремя не ввел сумму.

Сумма не кратна $5.

Запрошенная сумма слишком велика.

Сеть или главный компьютер отказывают во время транзакции.

Не хватает денег в кассовом аппарате.

Купюры замялись во время выдачи.

Бумага для квитанции кончилась или замялась.

Клиент не берет деньги из раздаточного устройства.

Упражнение 8.5 Вариант использования 39 Ш Купить товары через Интернет ЗА.

Основное действующее пицо: покупатель (пользователь).

Область действия: PAF.

Уровень: цель пользователя.

Предусловие: пользователь уже открыл PAF.

Минимальные гарантии: есть достаточный объем регистрационных данных, чтобы PAF мог обнаружить непорядок и запросить у пользователя детали. Гарантии успеха: удаленный web-сайт подтвердил покупку; журналы PAF и портфель пользователя обновлены.

Основной сценарий:.

1.

Пользователь выбирает покупку товаров через Интернет.

2.

PAF получает имя web-сайта для покупок (E*Trade, Schwab и т.д.).

3.

PAF открывает соединение с сайтом, сохраняя управление.

4.

Пользователь просматривает и покупает товары на web-сайте.

5.

PAF перехватывает ответы web-сайта и обновляет портфель пользователя.

6.

PAF показывает пользователю новое состояние портфеля.

Расширения:.

2а. Пользователь назвал web-сайт, не поддерживаемый PAF:.

2а 1. Система предлагает пользователю ввести другое имя web-сайта либо закончить вариант использования.

За. Отказ любого вида во время установки:.

За1. Система сообщает пользователю об отказе и дает рекомендацию;.

возвращается к предыдущему шагу.

За2. Пользователь выходит из этого варианта использования либо пробует еще раз.

4а. Отказывает или выключается компьютер во время транзакции покупки: 4а1. (Что мы здесь делаем?).

4Ь. Web-сайт не подтверждает покупку, а откладывает ее:.

4b1.PAF регистрирует задержку; устанавливает таймер, чтобы спросить пользователя о результате.

4Ь2.(см. Обновить сомнительную покупку).

5а. Web-сайт не возвращает необходимую информацию о покупке:.

5a1.PAF регистрирует отсутствие информации, предоставляет пользователю обновить сомнительную покупку.

5Ь.Диск выходит из строя или на нем отсутствует свободное пространство во время операции обновления портфеля:.

5Ы.При повторном запуске PAF обнаруживает несовместимость в журнале и просит у пользователя разрешения обновить сомнительную покупку.

Глава 11 Упражнение 11.1 Вариант использования 40 iSi Оказать услугу по прочистке свечей зажигания ЗА.

Предусловие: автомобиль стоит в гараже, двигатель работает. Минимальная гарантия: клиента уведомили о более серьезной проблеме; автомобиль не отремонтирован.

Гарантия успеха: двигатель работает ровно.

Основной сценарий:.

1.

Откройте капот и накройте крыло защитными материалами.

2.

Удалите свечи зажигания.

3.

Сотрите со свечей смазку.

4.

Прочистите и отрегулируйте зазоры.

5.

Проверьте и засвидетельствуйте работу свеч.

6.

Замените свечи.

7.

Подключите провода зажигания к соответствующим свечам.

8.

Проверьте, работает ли двигатель ровно, и засвидетельствуйте это.

9.

Промойте инструмент и оборудование.

10. Снимите с крыла защитные материалы; сотрите смазку с автомобиля. Расширения:.

4а. Свеча треснула или изношена: замените ее новой.

8а. Двигатель все еще не работает ровно:.

8а1. Провести грубую диагностику двигателя (вариант использования 23).

8а2. Уведомить клиента о более серьезной проблеме с автомобилем (Вариант использования 41).