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

“Где же тогда эти требования?” — спрашивают разработчики. Мы можем сказать, что варианты использования не обязаны их содержать, но где-нибудь они должны быть документированы.

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

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

■ Ожидаемая частота появления.

■ Потребности функционирования.

* Дата сдачи.

■ Второстепенные действующие лица.

■ Бизнес-правила (возможно).

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

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

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

■ Триггер.

■ Приоритет реализации.

■ Оценка сложности.

■ Предполагаемая версия.

■ Требование к функционированию.

■ Статус завершенности.

■ Все, что еще необходимо.

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

16.1. Точность в требованиях к данным.

Рекомендация дозировать усилия при достижении точности требований к данным остается в силе (см. 1.5). Я делю требования к данным на три уровня точности:.

■ Краткие имена данных.

■ Списки полей или описания данных.

■ Атрибуты и проверки полей.

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

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

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

СПИСКИ ПОЛЕЙ. На некоторых этапах пишущим требования специалистам придется согласовывать значения каждого краткого имени данных. Состоит ли имя клиента из двух частей (имени и фамилии) или более? Что точно должно входить в адрес? В мире много различных форматов адресов. Здесь вполне уместно расширить описания данных до второго уровня точности. Это удобно делать параллельно с созданием вариантов использования или позднее, скажем, взаимодействуя с разработчиком интерфейса пользователя.

Существует много стратегий работы со вторым уровнем точности. Я назову две, а другие вы найдете в книгах Software for Use (Constantine and Lockwood, 1999) и GUIs with Glue (Hohman, на момент выхода данной книги находилась в печати). Впрочем, вы можете самостоятельно попрактиковаться в этой области.

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

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

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

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

АТРИБУТЫ ПОЛЕЙ И ПРОВЕРКИ ПОЛЕЙ. Программисты и разработчики базы данных обязательно должны решить, сколько знаков отводится на имя клиента и каковы ограничения на дату ущерба. Другими словами, типы полей, длину полей и проверки полей.

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

Что бы вы ни выбрали, имейте в виду:.

* Вам необходимо расширить описание атрибутов и проверок полей до третьего уровня точности.

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

■ Вариант использования должен ссылаться на это расширение.

■ Атрибуты полей со временем могут изменяться независимо от деталей варианта использования.

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

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

РИС. 16.1. Модель требований в виде колеса (повторение рис. 1.1).

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

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

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