Вариант использования 24 Полный формат шаблона варианта использования.

Сназвание должно быть в виде краткой фразы с глаголом.

в неопределенной форме совершенного вида и отражать цель>.

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

Область действия:разрабатываемая система рассматривается как "черный ящик">.

Уровень:подфункции>.

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

Участники и интересы: Ссписок участников и ключевых интересов в данном варианте использования>.

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

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

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

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

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

обращается к шагу основного сценария>.

:использования>.

:использования>.

Список изменений в технологии и данных:.

в сценарии>.

Сномер шага или изменения> Ссписок изменений>.

Сномер шага или изменения> Ссписок изменений>.

Вспомогательная информация:.

Сто, что необходимо для проекта в качестве дополнительной информации>.

Свободный формат.

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

Вариант использования 25 0 Действительная регистрация в системе (версия в свободном формате) Х3>.

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

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

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

Таблица в одну колонку.

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

Таблица 11.1. Вариант использования формата таблицы в одну колонку

Форматы вариантов использования Таблица 11.1 (продолжение)

Таблица в две колонки.

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

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

Авторы книги Software for Use (1999) пользуются диалоговым форматом при формировании требований к интерфейсу пользователя в существенных вариантах использования. Разница с предыдущим подходом в том, что в существенном варианте использования все движения пользователя (детали интерфейса) опущены, поэтому он получается очень коротким.

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

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

Стиль RUP.

Технология Rational Unified Process (RUP) использует шаблон, весьма похожий на шаблон полной формы. Нумеровать шаги не обязательно. Расширениям, которые называются альтернативными потоками событий, отведены собственные озаглавленные разделы. Все, о чем идет речь в этой книге, хорошо согласуется с этим шаблоном. Несмотря на переизбыток номеров заголовков, он хорошо смотрится и прост в употреблении. Вот его базовая форма:.

1.

Название варианта использования.

1.1.

Краткое описание.

...текст...

1.2.

Действующие лица.

...текст...

1.3.

Триггеры.

...текст...

2.

Поток событий.

2.1.

Основной поток.

...текст...

2.2.

Альтернативные потоки.

2.2.1.

Условие 1 ...текст...

2.2.2.

Условие 2 ...текст...

2.2.3.

...

3.

Специальные требования.

3.1. Платформа.

Компания Rational Software Corporation прислала мне в качестве примера вариант использования, приведенный ниже. Обычно в наборе инструментов ему сопутствуют диаграмма варианта использования и другие рабочие продукты. Этот вариант использования кажется мне вполне очевидным, думаю, вы придете к тому же мнению. Обратите внимание, что и простые абзацы, и нумерованные шаги используются в соответствии с тем, как разработчик представляет себе лучший вариант. Для совместимости с примерами в этой книге я добавил к заголовку две пиктограммы, но сам шаблон оставил без изменений.

В варианте использования 32 также используется шаблон RUP.

Вариант использования 26 0 Записаться на курсы К3>.

1.

Название варианта использования: Записаться на курсы.

1.1.

Краткое описание.

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

Основное действующее лицо этого варианта использования — студент. Система каталога курсов — действующее лицо внутри варианта использования.

2.

Поток событий:.

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

2.1.

Основной поток.

2.1.1. Создать график.

2.1.1.1.

Студент выбирает функцию "создать график".

2.1.1.2.

Система выводит пустую форму графика [см. прототип интерфейса пользователя для формата экрана и модель предметной области для требуемых полей].

2.1.1.3.

Система выводит список предлагаемых курсов из системы каталога курсов. [Как он выбирается.

и отображается? Текст? Ниспадающие списки?].

2.1.1.4.

Студент выбирает 4 курса в качестве основных.

и 2 в качестве альтернативных из списка доступных курсов. Когда выбор закончен, студент использует функцию "зафиксировать выбор". [Определить термины "основной курс" и "альтернативный курс" в глоссарии проекта. Должно быть выбрано точно 4 и 2 курса или "до 4..." и т.д.?].

2.1.1.5.

На этом шаге подчиненный поток Добавить курс выполняется для каждого выбранного курса.

2.1.1.6.

Система сохраняет график. [Когда обновляется главный график? Немедленно? По ночам (в пакетном режиме)?].

1.2 Альтернативные потоки.

2.2.1.

Модифицировать график.

2.2.1.1.

Студент выбирает "модифицировать график”.

2.2.1.2.

Система находит и отображает текущий график студента (т.е. график на текущий семестр). [Это все, что можно получить для текущего семестра?].

2.2.1.3.

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

2.2.1.4.

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

2.2.1.5.

На этом шаге подчиненный поток Добавить курс выполняется для каждого выбранного курса.

2.2.1.6.

Система сохраняет график.

2.2.2.

Удалить график.

2.2.2.1.

Студент выбирает функцию Удалить график.

2.2.2.2.

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

2.2.2.3.

Студент выбирает "удалить".

2.2.2.4.

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

2.2.2.5.

Студент подтверждает удаление.

2.2.2.6.

Система удаляет график. [В какой момент освобождается место студента в общем графике?].

2.2.3.

Сохранить график.

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

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

В его графике курс помечается как "выбранный".

2.2.4.

Добавить курс.

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

2.2.5.

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

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

В этой точке вариант использования перезапускается.

2.2.6.

График не найден.

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

2.2.7.

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

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

2.2.8.

Запись на курсы закрыта.

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

3.

Специальные требования.

В настоящее время для данного варианта использования специальные требования не определены.

4.

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

4.1. Вход в систему.

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

5.

Постусловия.

Постусловия, связанные с этим вариантом использования, отсутствуют.

6.

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

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

Стиль с предложениями с если.

Программисты просто не могут не включить в текст предложения с если. Многие говорят, что чем учиться писать расширения, лучше писать так:.

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

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

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

Стиль с использованием языка Оккам.

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

На Оккаме вы напишете так:.

ALT.

Альтернатива 1.

Альтернатива 2.

TLA (этим кончаются альтернативы).

PAR.

Параллельное действие 1.

Параллельное действие 2.

RAP (этим кончаются параллельные действия).

ОРТ.

Необязательное действие.

TPO.

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

Стиль диаграмм.

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

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

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

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

UML-диаграмма варианта использования.

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

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

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

Не пытайтесь заменить эллипсами текст варианта использования. Один студент на лекции спросил меня: “Когда вы начинаете писать текст? На уровне листа декомпозиции эллипса?”.

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

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

11.2. Факторы, влияющие на стиль варианта использования.

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

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

Уравновешивающие факторы: установки бизнеса, общественные отношения, конфликтующие подходы.

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

Мы всегда делали это другим способом.

При разнообразии подходов вы можете решить, что:.

Разработчики имеют предубеждение.

Существуют различные подходы, и приверженцы разных подходов делают одни и те же вещи по-разному.

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

Уровень понимания.

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

Ваши знания о:.

• Предметной области.

• Вариантах использования в общем.

Этап жизненного цикла, к которому относятся эти знания.

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

• Присутствие скрытого или затянувшегося анализа.

• Люди склонны выделять вещи, которые знают.

• Планирование или глубина знания либо знание предметной области.

Потребности участников.

Какая точка зрения вам ближе:.

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

Работник фирмы (отдела IT) — писатель или разработчик, заинтересованный в детальном описании.

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

Участвуют ли разные читатели? Если да, кто они?.

Опыт против формализма.

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

Формализм: возможно, руководитель или принятая в отделе методология диктует формальный (или неформальный) стиль описания, несмотря на любой опыт или его отсутствие.

Охват.

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

На изменение охвата влияют:.

Эксперты предметной области (они могут узко сфокусировать предметную область).

Количество писателей.

Количество читателей.

Количество разработчиков.

Знание (или его отсутствие) бизнесменами своих целей Решение работать над общей моделью Географическая разбросанность членов группы.

Непротиворечивость.

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

Непостоянство требований.

Постоянство формата.

Сложность.

На сложность варианта использования влияют следующие факторы:.

Полнота описания.

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

Желание добавить технические подробности (особенно если проблема трудна) Следующие факторы влияют на сложность системы:.

Бессилие анализа (сложность системы ошеломляет аналитика).

Количество профилей действующих лиц Количество функциональных точек Тип системы.

Степень требовательности пользователей Режим реального времени.

Встроенная система (она должна быть устойчива к ошибкам) Противоречие.

Необходимо разрешить противоречие заказчика, но неопределенность маскирует это противоречие.

Завершенность.

Завершенности могут препятствовать следующие факторы:.

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

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

Цели в сравнении с задачами — что выполнять или как это выполнять.

Пользователи часто определяют требования, а не способ использования.

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

Действия и задачи описывают, что происходит в системе, а не почему это происходит.

Ресурсы.

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

Другие факторы.

Другие факторы, влияющие на процесс создания вариантов использования: Требования к инструментам (поддержка).

Неизвестная цель.

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

Проектирование без ограничений в сравнении с заданным уровнем проектирования.

Чистый стиль или понятное проектирование Абстрактные или конкретные варианты использования Возможность трассировки Общая скорость работы.

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

11.3. Стандарты для пяти типов проектов.

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

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

1.

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

2.

Моделирование бизнесс-процессов.

3.

Формулирование или определение объема требований к системе.

4.

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

5. Формулирование детальных функциональных требований в начале длительного или объемного проекта.

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

Ниже я использую примеры с компанией МуСо по разработке новой системы Acura взамен старой системы BSSO. Напоминаю: следует писать действительные названия, а не слова корпорация или система.

Для выявления требований Вариант использования 27.

QJ Шаблон выявления — стрямкать новую бутявку ЗА.

Область действия: Acura Уровень: уровень моря.

Контекст: потребности бокра стрямкать новую бутявку, так как старая подудонилась (описание цели в контексте функционирования).

Основное действующее лицо: бокр (или кто-то еще).

Участники и интересы: бокр, МуСо, ... (кто-то или что-то еще) Предусловия: что должно быть истинным, прежде чем можно будет запустить данный вариант использования?.

Триггеры: бокр выбирает функцию трямканья (все, что может этим быть). Основной сценарий:.

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

Частота события: несколько раз в день.

Открытые вопросы: ... полезно заполнять этот раздел...

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

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

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

Для моделирования бизнес-процесса Вариант использования 28.

& Шаблон бизнесс-процесса — достигнуть успешного функционирования компании.

Область действия: работа МуСо Уровень: обобщенный.

Контекст: описание цели в контексте работы.

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

Участники и интересы: кто-либо или что-либо им соответствующее Минимальные гарантии: какими бы они ни были Гарантии успеха: какими бы они ни были.

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

Триггеры: все, что может этим быть.

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

1.

... шаги действия...

2.

...

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

1а. ... Условия расширения:.

1 а 1. ... шаги действия...

Частота события: какая-нибудь.

Открытые вопросы: ... полезно заполнять этот раздел...

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

Варианты использования высшего уровня, предельные, будут множеством “черных ящиков”, &, показывающих взаимодействие компании с внешними партнерами. Они нужны либо как спецификации, с которыми будет сверяться бизнес-процесс, либо для определения контекста для вариантов использования типа “прозрачный ящик”. Варианты использования типа “прозрачный ящик”, 6, работающие с системами, подобными My Со Operations, демонстрируют организацию в действии с людьми и отделами, работающими совместно для обеспечения должных характеристик функционирования организации. Цели пользователя будут от облака до уровня моря. Для примера шаблона я выбрал обобщенную цель уровня воздушного змея.

Для определения объема требований к системе Вариант использования 29.

в Шаблон для определения объема — определить объем требований к системе ЗА.

Область действия: Acura Уровень: голубой.

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

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

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

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

Частота события: как часто.

Открытые вопросы: ... всегда полезно отметить...

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

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

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

Вариант использования 30 Ш Очень сжатый шаблон: добыть бананан ЗА.

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

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

Участники и интересы:.

Минимальные гарантии и гарантии успеха:.

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

Триггеры:.

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

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

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

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

Частота события:.

Открытые вопросы: ...

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

Для детальных функциональных требований Вариант использования 31.

Q Название варианта использования — Оризовать позвение АЛ.

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

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

Участники и интересы:.

Минимальные гарантии:.

Гарантии успеха:.

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

Триггеры:.

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

1. ...

2. ...

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

1а. ...

1 а 1. ...

Частота события:.

Открытые вопросы: ...

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

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

11.4.

Заключение.

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

11.5.

Упражнения.

Предложения с если.

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

Оказать услугу по чистке свечей зажигания.

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

1.

Откройте капот.

2.

Найдите свечи зажигания.

3.

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

4.

Удалите свечи.

5.

Если свечи треснули или изношены, замените их.

6.

Почистите свечи.

7.

Прочистите зазор в каждой свече.

8.

Настройте свечу, если необходимо.

9.

Проверьте свечу.

10.

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

11.

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

12.

Проверьте характеристику двигателя.

13.

Если она в порядке, переходите к шагу 15.

14.

Если нет, проделайте указанные шаги.

15.

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

16.

Сотрите смазку с автомобиля.

17.

Закончите необходимую бумажную работу.

Итог: двигатель работает ровно.

Вы “закончили” работу, если:.

■ Назвали всех основных действующих лиц и все цели пользователя по отношению к системе.

■ Зафиксировали все условия запуска для системы в качестве триггеров вариантов использования либо как условия расширения.

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

■ Каждый вариант использования написан достаточно ясно, чтобы:.

— Спонсоры определили, действительно ли достигается желаемое.

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

— Разработчики смогли разработать систему с данным набором функций.

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

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

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

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

ОБОБЩЕННЫЕ ВАРИАНТЫ ИСПОЛЬЗОВАНИЯ И ВАРИАНТЫ ИСПОЛЬЗОВАНИЯ УРОВНЯ ПОДФУНКЦИИ. Обобщенные варианты использования создают контекст для вариантов использования уровня цели пользователя. Они отвечают на часто задаваемый вопрос: “Как все эти варианты использования (уровня цели пользователя) совмещаются друг с другом?” Я предпочитаю, чтобы каждый вариант использования находился внутри варианта использования более высокого уровня, вплоть до единственного корневого. Этот корневой вариант использования представляет собой лишь оглавление почти без сюжетной линии, однако для новичков удобно иметь единую точку, из которой можно запустить каждый вариант использования системы.

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

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

Когда вы заканчиваете.

Слово “заканчивать” создает впечатление, что вам следует написать все варианты использования от начала до конца, прежде чем начать выполнение задач проектирования. Это не так. В разделе 17.1 рассматривается разработка плана проекта с частичной реализацией вариантов использования; см. также книгу Surviving ObjectOriented Projects (Cockburn, 1998), где подробно описана пошаговая разработка программного обеспечения, и статью VW-Staging (

kburn/papers/vw-stage.htm), в которой сжато излагаются методы пошаговой и итеративной разработки.

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

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