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

АКТОРЫ И ВАРИАНТЫ ИСПОЛЬЗОВАНИЯ

ЛЕКЦИЯ 12

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

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

Самым популярным и весьма эффективным способом повышения информативности требований является оформление их в виде вариантов использования (use case), предложенный И.Якобсоном. Центральным понятием в таком подходе является понятие актора и варианта использования.

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

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

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

Спецификация варианта использования

Существуют различные шаблоны описания вариантов использования:

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

· Табличный формат,

Кроме того, иногда целесообразно использовать:

· Псевдокод,

· Диаграмму активности UML,

· Другие графические модели.

 

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

 

Табличные представления варианта использования

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

 

Таблица в 2 колонки:
Актор Действие
Пользователь Формирует запрос на поиск заказов
Система Отображает список заказов
Пользователь Выбирает требуемый заказ
Система Показывает подробную информацию по заказу
Таблица в 3 колонки:
№ шага Пользователь Система
Делает запрос на поиск заказов Отображает список заказов
Выбирает требуемый заказ Показывает подробную информацию по заказу
         

 

Выбор формы описания варианта использования

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

· Размеры проекта,

· Важность проекта и варианта использования,

· Традиции, сложившиеся в коллективе "Заказчик-Разработчик".

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

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

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