анализ требований. Приложение 1. Анализ требований по Вигерсу. Приложение 1 анализ требований (по Вигерсу)
 Скачать 1.62 Mb.
|
Фрагмент диаграммы варианта использования Chemical Tracking System: Диаграммы вариантов использования (use-case diagrams) позволяют получить отличное визуальное представление о требованиях пользователей. На рис. 8-1 показан фрагмент диаграммы варианта использования Chemical Tracking System, где применяются нотации UML (Unitied Modeling Language — унифицированный язык моделирования) (Booch, Rumbaugh и Jacobson, 1999; Armour и Miller, 2001). Прямоугольник показывает границы системы. Линии соединяют каждое действующее лицо (нарисованный человечек) с вариантами использования (эллипсами), с которыми это лицо взаимодействует. Обратите внимание на сходство этой диаграммы варианта использования с контекстной диаграммой на рис. 5-3. Здесь прямоугольник отделяет некоторые внутренние элементы высокого уровня системы — варианты использования — от внешних действующих лиц. Контекстная диаграмма также отображает объекты, расположенные вне системы, но на ней не видны внутренние части системы. Варианты использования и сценарии использования Вариант использования (use case) — это отдельное, независимое действие, которое действующее лицо может выполнить для получения определенного значимого результата. Один вариант использования может охватывать несколько схожих задач с одинаковыми целями. Следовательно, он представляет собой набор связанных между собой сценариев использования, где сценарий — это отдельный пример варианта использования. Вы можете начать разработку требований с абстрактных вариантов использования, а затем на их основе создать конкретные сценарии использования или, наоборот, перейти от некоего сценария к более широкому варианту использования. Далее в этой главе показан подробный шаблон для документирования вариантов использования. К важным элементам описания варианта использования относятся: — уникальный идентификатор; — имя, кратко описывающее задачи пользователи в формате «глагол + объект», например «разместить заказ»; — краткое текстовое описание на естественном языке; — список предварительных условий, которые должны быть удовлетворены до начала разработки варианта использования; — выходные условия, описывающие состояние системы после успешного завершения разработки варианта использования; — пронумерованный список действий, иллюстрирующий последовательность этапов взаимодействия лица и системы от предварительных условий до выходных условий. Один сценарий считается нормальным направлением развития (normal course) варианта использования, его также называют основным направлением, базовым направлением, нормальным потоком, основным сценарием, главным успешным сценарием и благоприятным путем. Нормальное направление для варианта использования «Запрос химиката» — запрос химиката, который есть на складе. UML-диаграмма, иллюстрирующая диалоговый поток при нормальном и альтернативном развитии варианта использования:  Другие допустимые сценарии из варианта использования, называются альтернативными направлениями (alternative courses) или вторичными сценариями (secondary scenarios) (Schneider и Winters, 1998). Они также могут привести к успешному выполнению задания и удовлетворяют выходным условиям варианта использования. Однако они представляют вариации решения задачи или диалоговой последовательности, необходимой для выполнения задачи. В определенной точке принятия решений в диалоговой последовательности нормальное направление может перейти в альтернативное, а затем вернуться обратно в нормальное. Хотя большинство вариантов использования можно описать простым языком, блок-схема или UML-диаграмма позволяют визуально представить логическое развитие сложного варианта использования, как показано на рис. 8-2. Блок-схема и диаграммы взаимодействия показывают точку принятия решений и условия при которых основное направление развития событий переходит в альтернативное. Альтернативное направление для варианта использования «Заказать химикат» — это «Заказать химикат у поставщика». В обеих ситуациях конечная цель действующего лица одна и та же — запрос химиката, поэтому оба сценария входят в один вариант использования. Некоторые этапы альтернативного направления аналогичны этапам нормального направления, но для завершения альтернативного направления необходимо выполнить особые действия. В нашем случае пользователь может искать необходимый химикат по каталогам поставщиков. Если альтернативное направление само по себе является автономным вариантом использования, вы можете расширить нормальное направление, включив этот отдельный вариант использования в нормальный поток (Armour и Miller, 2001). Диаграмма на рис. 8-1 иллюстрирует подобную расширенную взаимосвязь. Вариант использования «Запросить химикат» был расширен вариантом использования «Выполнить поиск по каталогам поставщика». Кроме того, сотрудники склада химикатов используют «Поиск по каталогам поставщиков» как отдельный вариант. Иногда несколько вариантов использования имеют общие наборы этапов. Чтобы избежать повторения этих этапов в каждом варианте использования, определите отдельный варианте общей функциональностью и укажите, что он включен в другие варианты использования как подвариант. Эта процедура аналогична вызову общей подпрограммы в компьютерной программе. В качестве примера рассмотрим работу ПО для бухгалтерии. Возможны два варианта использования — «Оплатить счет» и «Подтвердить кредитную карту», причем в обоих, чтобы выполнить платеж, пользователь должен подписать чек. Вы можете создать отдельный вариант использования «Подписать чек», который содержит набор действий, необходимых для подписи чека. Этот вариант будет включен в обе транзакции, как показано на рис. ниже. Ловушка. Не затягивайте обсуждение того, когда, как и стоит ли вообще использовать взаимоотношения типа расширить и включить. Чаще всего применяется следующий прием — указать общие действия во включенном варианте использования. Пример того, как вариант использования связан с бухгалтерским приложением:  Условия, препятствующие успешному завершению задания, называются исключениями (exceptions). Для варианта использования «Запросить химикат» существует одно исключение — «Химиката нет в продаже». Если в процессе сбора информации вы не укажете, как обрабатывать исключение, то возможны два пути: 1. разработчики предложат лучший, по их мнению, способ обработки исключений; 2. при генерации пользователем неверного условия произойдет сбой системы, так как никто не предусмотрел такой ситуации. Бьюсь об заклад, что сбои системы не входят в список требований пользователей. Иногда исключения рассматриваются как тип альтернативного направления (Cockburn, 2001), однако эти понятия следует разделять. Не обязательно реализовывать каждое альтернативное направление, которое вы определили для варианта использования; кроме того, вы можете отложить его реализацию до следующего выпуска. Однако вы обязаны реализовать исключения, из-за которых завершение сценариев может оказаться не успешным. Любой, кто когда-либо занимался программированием, знает, что часто именно на работу над исключениями приходится большая часть программирования. Многие недостатки конечного продукта присущи именно обработчикам исключений (или происходят из-за их отсутствия). Указать условия исключений в ходе сбора информации по требованиям — верный способ создать устойчивые к сбоям продукты. Для многих систем пользователь может связать последовательность вариантов использование в «макро- вариант использования», описывающий объемную задачу. Для коммерческого Web-сайта предлагаются, например, такие варианты использования; «Поиск по каталогу», «Добавить товар в корзину» и «Оплатить товары в корзине». Если вы можете выполнить все эти действия по отдельности, то все они считаются независимыми вариантами использования. Кроме того, вы вправе выполнить все три указанные операции подряд, назвав этот один большой вариант использования «Приобрести товар», как показано на рис. 8-4. Причем после каждого варианта использования система должна быть в таком состоянии, чтобы пользователь мог приступить к следующему варианту использования немедленно. То есть выходные условия одного варианта использования должны удовлетворять предварительным условиям следующего за ним варианта. Подобным же образом в приложении обработки транзакций, например ATM, каждый вариант использования должен оставлять систему в состоянии готовности к следующей транзакции. Предварительные условия и выходные условия каждой транзакции варианта использования должны вставать в один ряд. Предварительные условия и выходные условия определяют границы отдельных вариантов использования, которые можно связать в цепочку для выполнения объемной задачи:  Определение вариантов использования Вы можете определить варианты использования несколькими способами (Ham, 1998; Larman, 1998): — сначала определить действующие лица, а затем бизнес-процессы, в которых каждое лицо участвует; — выразить бизнес-процессы в терминах определенных сценариев, обобщить сценарии в варианты использования и определить действующие лица для каждого варианта;определить внешние события, на которые система должна реагировать, а затем соотнести эти события с участвующими лицами и определенными вариантами использования; — определить вероятные варианты использования на основе функциональных требований, Если какие-либо требования невозможна проследить до какого-либо варианта использования, подумайте нужны ли они. В Chemical Tracking System применен первый подход. Аналитик провел несколько семинаров по вариантам использования, примерно два раза в неделю, по два-три часа каждый. Члены различных классов пользователей участвовали в параллельных семинарах, так как лишь несколько вариантов использования были общими для нескольких классов пользователей. На каждом семинаре присутствовали сторонник продукта от класса пользователей, другие выбранные представители пользователей, а также разработчик. Участие в семинарах позволило разработчикам еще на ранней стадии получить представление о создаваемом продукте. Кроме того, они возвращали собравшихся к реальности, когда те предлагали невыполнимые требования. До начала семинаров аналитики попросили пользователей продумать, какие задачи те собираются выполнять с помощью новой системы. Каждая такая задача становилась потенциальным вариантом использования. Несколько предложенных вариантов, как выяснилось, выходят за границы проекта, поэтому далее они не обсуждались. По мере изучения вариантов использования стало ясно, что некоторые варианты связаны между собой сценариями, которые можно объединить в один абстрактный вариант использования. Также удалось выявить дополнительные варианты использования, не входившие в первоначальный набор. Некоторые участники предложили варианты использования, не сформулированные как задачи, например «Данные по безопасному хранению материала». Название варианта использования должно указывать на решаемую задачу, поэтому в названии необходим глагол. Что клиент хочет: просмотреть, напечатать, заказать, отправить по электронной почте, исправить, удалить или создать данные по безопасному хранению материала? Иногда предложенный вариант использования — это всего лишь одно действие, которое выполняется как часть варианта использования, например «сканировать штрих-код». Аналитик должен выяснить, какую цель подразумевал пользователь, когда предлагал это. Он может задать такой вопрос: «Сканируя штрихкод на контейнере с химикатами, что вы пытаетесь сделать?» Предположим, в ответ он услышит: «Это необходимо для того, чтобы я мог отправить этот химикат в свою лабораторию». Следовательно, настоящий вариант использования выглядит как-то так — «Отправить химикат в лабораторию». Сканирование штрих-кода — только один из этапов взаимодействия действующего лица и системы, передающей химикат в лабораторию. Как правило, пользователи сначала определяют самые важные варианты использования, поэтому порядок предлагаемых тем позволит получить представление о приоритетах. Другой способ расстановки приоритетов — кратко описать каждый потенциальный вариант использования в том виде, какой был предложен. Расставьте приоритеты и предварительно распределите их по выпускам продукта. В первую очередь укажите детали для вариантов использования с наивысшим приоритетом, чтобы разработчики смогли приступить к их реализации как можно скорее. Документирование вариантов использования На этой стадии обсуждения участники должны обдумать важнейшие варианты использования. Constantine и Lockwood (1999) дают следующее определение важнейших вариантов использования (essential use cases): «… упрощенное, обобщенное, абстрактное, не зависящее от технологии и реализации описание одной задачи или взаимодействия… в котором воплощена цель или намерения, лежащие в основе взаимодействия». То есть следует сосредоточиться на задаче, которую пользователю необходимо выполнить, и возможностях системы для выполнения этой задачи. Важнейшие варианты использования характеризуются более высоким уровнем абстракции, чем конкретные варианты использования (concrete use cases), которые описывают определенные действия, предпринимаемые пользователем для взаимодействия с системой. Чтобы проиллюстрировать различие, рассмотрим два способа начала реализации пользователем варианта использования «Запросить химикат». Конкретный вариант использования. Введите номер ID химиката. Важнейший вариант использования. Укажите необходимый химикат. Формулировка на важнейшем уровне позволяет пользователю выполнить задачу многими способов: ввести номер ID химиката, импортировать химическую структуру из файла, нарисовать структуру на экране с помощью мыши, выбрать химикат из списка и многое другое. Слишком быстрое углубление в детали определенного взаимодействия ограничивает широту мышления участников семинара. Независимость важнейших вариантов использования от реализации, делает их более пригодными для повторных применений, чем конкретные варианты использования. Участники семинара, посвященного Chemical Tracking System, начинали каждое обсуждение с определения действующего лица, которое получит преимущество отданного варианта использования, и краткого описания этого варианта. Затем они указывали предварительные условия и выходные условия, ограничивающие вариант использования, а также все этапы внутри этих границ. Выяснив частоту использования, вы на ранних стадиях получите представление о необходимости и важности требования. Далее аналитики спрашивали участников, как те себе представляют взаимодействие с системой для выполнения задачи, Установленная последовательность действий лиц и реакции системы определялась, как нормальное направление. Нумерация этапов последовательности окончательно проясняла ситуацию. Хотя у каждого участника было свое представление об интерфейсе и специальных механизмах взаимодействия, группа смогла выработать общее понимание важнейших этапов диалога системы и пользователя. Придерживаясь границ Изучая вариант использования из восьми этапов, я понял, что выходные условий удовлетворены уже после пятого этапа. Следовательно, этапы 6, 7 и 8 были излишними, так как выходили за границы варианта использования. Точно так же предварительные условия варианта использования должны быть удовлетворены до начала первого этапа. Изучая описание варианта использования, убедитесь, что предварительные и выходные условия ограничивают его соответствующим образом. Аналитик фиксировал действия отдельного лица и реакцию системы на отдельных клейких листочках, которые затем прикреплял на схему. Возможен и другой способ проведения семинара — в ходе обсуждения спроецировать с помощью компьютера шаблон варианта использования на большой экран и отредактировать его, хотя иногда это замедляет обсуждение. Команда, занимающаяся сбором информации, разработала аналогичные диалоги для определения альтернативных направлений и исключений. Если пользователь говорит: «По умолчание это должно быть…», значит, он описывает нормальное направление развития варианта использования. Такая фраза, как: «Необходимо, чтобы пользователь также смог..», предполагает обсуждение альтернативное направление. Многие условия исключений удавалось выяснились, когда аналитик задавал примерно такие вопросы: «Что должно произойти, если в текущий момент БД отключена?» или «Что, если этого химиката нет в продаже?». На семинаре также удобно обсудить ожидания пользователей, касающиеся качества продукта, например времени реакции, доступности и надежности системы, ограничений дизайна пользовательского интерфейса и требований по безопасности. После того, как участники семинара описали каждый вариант использования, и никто не предлагал уже никаких дополнительных вариантов, исключений или специальных требований, приступали к следующему варианту использования. Участники не пытались рассмотреть все варианты использования за одно марафонское обсуждение или точно определить все детали каждого варианта использования. Они запланировали изучение вариантов использования по возрастающей и их последующее многократное рассмотрение и уточнение. Рисунок «Последовательность этапов разработки вариантов использования»  Существует два способа представить этапы взаимодействия пользователя и системы, которые и составляют основу варианта использования. 1) Составление пронумерованного списка этапов с указанием того, какой элемент (система или определенное действующее лицо) выполняет каждый шаг. Так же описываются и альтернативные направления и исключения, для которых показан этап нормального направления развития, на котором появляется ответвление, или этап, где возможно исключение. |