|
|
|
Ваши замечания и предложения отправляйте редактору По техническим вопросам обращайтесь к вебмастеру Дата публикации: 03.04.03 | |
| СТАТЬЯ |
03.04.03
|
© Леонов
И.В. , “ЭСКЕЙП”
© Статья была опубликована на сайте фирмы “ЭСКЕЙП”
Эта глава полностью посвящена методологии описания способов использования (Use Case). В литературе часто встречаются другие переводы термина Use Case - прецеденты, варианты использования и т.п. В основном мы будем использовать термин "прецедент", как наиболее часто встречающийся в русскоязычной литературе.
Под "методологией" будет подразумеваться формат, которого следует придерживаться при описании прецедентов. Сразу отметим, что приведенный формат предназначен для детального описания. В небольших коллективах, постоянно взаимодействующих с экспертами предметной области, можно существенно сократить объем текста.
Материал в этой главе имеет следующую структуру.
Часто говорят, что одна диаграмма заменяет 100 страниц текста. Существует прямо противоположное мнение. Эта глава написана с позиций сторонников последнего подхода. Истина, как всегда, где-то посередине...
Полное изложение вопросов, которым посвящена данная глава, см. в книге Alistair Cockburn "Writing effective Use Cases", Addison Wesley
При выполнени реальных проектов для описания прецедентов вы можете воспользоваться шаблоном для Word 2000.
В этом параграфе приведен шаблон для полного и подробного описания прецедента
Прецедент <Имя прецедента. Имя имеет вид активного глагольного оборота или эквивалентного оборота с существительным и выражает основную цель действующего лица>
Главное действующее лицо <Имя роли или краткое описание действующего лица, которое играет ключевую роль во взаимодействии с системой в рамках данного прецедента>
Внешний контекст <В этом пункте цель действующего лица раскрывается чуть более полно>
Масштаб <описание границ системы: что находится вне системы, которую на этом этапе мы можем представить себе в виде "черного ящика", с чьей точки точки зрения составлено описание>
Уровень <один из трех вариантов - Обобщенный, Цель пользователя, Отдельная функция>
Заинтересованные лица <список всех заинтересованных лиц и обзор их ключевых интересов, которые должны быть соблюдены при работе системы>
Исходные условия <Состояние мира (системы и ее окружения), которое всегда имеет место перед выполнением прецедента>
Минимальный результат <Какие цели будут достигнуты в наихудшем варианте из возможных>
Результат успешного завершения <Какие цели будут достигнуты, если работа пройдет без малейших отклонений>
Триггер <Событие, при возникновении которого стартует наш прецедент>
Основной успешный сценарий <В этом разделе шаблона перечисляются все шаги, начиная с события-триггера и заканчивая последним шагом, при котором достигается цель действующего лица. В этом же разделе можно описать процедуру освобождения ресурсов после достижения цели>
Формат описания <Шаг #> <Описание выполняемого действия>
Расширения <Описание возможных отклонений, если на том или ином шаге основного успешного сценария возникают проблемы>
Формат описания <Шаг # Отклонение # ...> <Описание выполняемого действия>
Варианты изменения технологий и данных <Описание возможных отклонений, которые при которых может меняться набор шагов основного успешного сценария и т.п.>
Формат описания.
<
Отклонение #><Необходимые изменения>.
<
Отклонение #><Необходимые изменения>.
Дополнительная информация <Описание остальной полезной информации, которая может понадобиться разработчику. Здесь можно привести ссылки на документы, содержащие описания нефункциональных требований: дизайн, эргономичность, параметры базы данных, производительности etc>
При выполнени реальных проектов для описания прецедентов вы можете воспользоваться шаблоном для Word 2000.
Для того, чтобы описать прецедент, необходимо все время четко осознавать простой факт: люди пользуются системой для достижения своих целей. Простой пример: цель клерка - это регистрация заказа от клиента, который позвонил по телефону. Клерк начинает работу с системой, и она формирует свои собственные цели - вывести окно на экран, получить информацию из базы данных и т.п.
Второй момент, который нужно иметь в виду, - некоторые цели оказываются недостижимыми. Пример: человек вводит неверный пароль при получении денег из банкомата. Система формирует цель - "Убедиться, что человеку можно общаться с банкоматом", и эта цель не достигается.
Фактически, наша задача при описании прецедента сводится к анализу дерева целей и описанию реакции системы в ситуации, когда та или иная цель оказывается недостижимой. При этом важно, чтобы описание было компактным и полным. Заметим, что эти два требования нисколько не противоречат друг другу. Нужно четко отслеживать степень общности формулировок и при необходимости включать в текст ссылки на описания прецедентов следующего уровня детализации. Подробнее см. параграфы Три уровня описания и Сценарии и шаги.
Важно отметить, что описание прецедентов - это только часть требований к системе. Фактически, это центральная часть требований, вокруг которой выстраиваются требования, касающиеся интерфейса пользователя, производительности, протоколов и форматов ввода-вывода. Существенной частью требований являются также бизнес-правила и описание форматов данных.
Для пользователей Rational Unified Process стоит напомнить о существовании дополнительных спецификаций, которые совместно с моделью прецедентов составляют полный документ - Требования к программному обеспечению. Все, что не входит в описание прецедентов, можно включить в дополнительные спецификации.
Полный шаблон описания требований для большого проекта может иметь следующий вид.
Глава 1. Цель и масштаб Глава 2. Используемые термины (Глоссарий) Глава 3. Прецеденты Глава 4. Используемые технологии Глава 5. Другие требования, непосредственно касающиееся проекта Глава 6. Организационные вопросы: взаимодействие с руководством заказчика,
политические, законодательные, человеческий фактор. |
Для пользователей Rational Unified Process стоит напомнить о существовании документа Общее описание исходной проблемы и основных требований заказчика (Vision). Приведенный выше шаблон и шаблон описания исходной проблемы во многом очень близки друг к другу. В RUP есть хорошие примеры для Vision-шаблона, поэтому мы рекомендуем использовать шаблон RUP, расширив его при необходимости.
Понятие "масштаб" включает в себя несколько пунктов. В самом простом варианте масштаб - это точка зрения на границы системы (прецедента). Более строгое рассмотрение масштаба приводит к выделению двух моментов - границы с точки зрения функций системы и границы с точки зрения конфигурации. С точки зрения функций системы границы можно полностью определить, составив список действующих лиц и их целей. Границы с точки зрения конфигурации системы - более тонкое понятие. Важно указать границы и с точки зрения программного обеспечения, и с точки зрения оборудования.
Крайне важно, чтобы разработчик и заказчик имели единый и верный взгляд на границы системы с точки зрения конфигурации. Ошибка может увеличить в разы сроки и усилия.
Для границ прецедента можно выделить три варианта: предприятие в целом, система, отдельная подсистема. Более тонкой детализации в разделе "масштаб" обычно не требуется.
Замечание 1.
Полезно использовать графические иконки для обозначения масштаба.
Замечание 2.
Полезно рисовать прецедент верхнего уровня. Это занимает мало времени и четко
обрисовывает границы.
Дополнительная информация
За дополнительной информацией обращайтесь в компанию Interface Ltd.
Обсудить на форуме Rational Software
| INTERFACE Ltd. |
| ||||