Лекция 12 акторы и варианты использования

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

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

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

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

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

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

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

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

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

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

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

• Псевдокод,

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

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