Проектирование ИС

      Самым популярным и весьма эффективным  способом повышения информативности требований является оформление их в виде вариантов использования.

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

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

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

      Помимо  формирования требований совладельцев другим результатом начальной фазы выявления требований является концептуальный анализ проблемной области. Самым первым результатом его является формирование глоссария (словаря) основных используемых терминов. Значение глоссария трудно переоценить: он является основой, ключом для единообразного понимания описаний требований Заказчиком и Разработчиком.

      Кроме того, глоссарий является отправной  точкой для построения более развернутых  моделей проблемной области, которые, на стадии реализации информационной системы, ложатся в основу объектной  модели (для объектно-ориентированных  приложений) и модели данных (для генерации схемы базы данных).

      Глоссарий оформляется, как текст, состоящий  из абзацев, каждый из которых определяет значение одного из терминов проблемной области. Термин обычно выделяют полужирным кеглем. Иногда проблемную область  целесообразно сегментировать на ряд "подобластей" (subject areas). Тогда каждой из них в глоссарии выделяется отдельный параграф.

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

• Свободный формат,
• Полный формат,
• Таблица в две колонки,
• Таблица в три колонки,
• Стиль RUP.

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

• Псевдокод,
• Диаграмму активности UML,
• Другие графические модели.
• Свободный формат предполагает описание действий пользователя и системы в повествовательном стиле.

 
 

      Шаблон  полного описания варианта использования:

      Название <краткая фраза в виде глагола  в неопределенной форме совершенного вида, отражающая цель>

      Контекст  использования <уточнение цели, при  необходимости - условия ее нормального  завершения>.

      Область действия <ссылка на рамки проекта>. Например - подсистема бухгалтерского учета.

      Уровень <один из трех: обобщенный, цели пользователя, подфункции>. Автор задает предопределенную трехуровневую классификацию требований, в целом соответствующую классификации  требований на бизнес-требования, требования пользователей и функциональные требования.

      Основное  действующее лицо <имя роли основного  актора или его описание>.

      Участники и интересы <список других акторов-участников прецедента с указанием их интересов>.

      Предусловие <то, что ожидается, уже имеет место>.

      Минимальные гарантии <что гарантируется акторам-участникам>. Например - в случае неудавшейся  транзакции все данные, имевшиеся  в системе до ее начала, сохраняются  неизменными.

      Гарантии  успеха <что получат акторы-участники  в случае успешного достижения цели>.

      Триггер <то, что "запускает" вариант  использования, обычно - событие во времени>.

      Основной  сценарий <здесь перечисляются  шаги основного сценария, начиная  от триггера и вплоть до достижения гарантии успеха>.

      Формат  описания: <Номер шага> <Описание действия>

      Расширения <здесь последовательно описываются  все альтернативные сценарии>. Каждая из альтернатив привязана к шагу основного сценария.

      Формат  описания: <Номер шага. Номер расширения> <Условие>:<Действие или ссылка на подчиненный вариант использования>.

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

      Начиная со строки, следующей после описания расширения, идет описание его действий в формате основного сценария:

      <Номер  шага. Номер расширения. Номер шага расширения> <Действие> Описание расширения заканчивается описанием выхода из расширения. Основные варианты выхода из расширения: возврат к очередному по номеру шагу основного сценария, окончание прецедента, переход к другому шагу основного сценария.

      Список  изменений в технологии и данных <что гарантируется акторам-участникам>. Например - в случае неудавшейся транзакции все данные, имевшиеся в системе до ее начала, сохраняются неизменными.

      Вспомогательная информация <дополнительная информация, полезная при описании варианта использования>.

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

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

Таблица 2. Таблица в 2 колонки 

Таблица 3. Таблица в 3 колонки

Шаблон  варианта использования RUP (краткий  обзор его разделов)

1. Наименования и краткое описание. В этом разделе указывается: наименование варианта использования, акторы варианта использования, краткое (в один абзац) описание варианта использования.
2. Поток событий

      2.1. Основной поток событий. Так  же, как в "Основной сценарий".

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

3. Специальные требования. Здесь перечисляются нефункциональные требования, имеющие непосредственное отношение именно к этому варианту использования.
4. Предусловия. События, описываемые предусловиями или постусловиями, должны быть состояниями, которые пользователь может наблюдать. Предусловие описывает состояние, в котором система должна находиться до начала исполнения прецедента.
5. Постусловия. Корректно сформулированное постусловие должно быть истинным при любом возможном сценарии прецедента, а не описанном в основном потоке.
6. Точки расширения определяют положение точек, расширяющих поток событий.

 

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

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

• Размеры проекта,
• Важность проекта и варианта использования,
• Традиции, сложившиеся в коллективе "Заказчик-Разработчик".

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

      Степень подробности зависит также от критичности проекта в целом  и критичности варианта использования в данном проекте. А.Коберн делит все программные проекты по степени критичности на 4 категории: исходя из цены ошибок: "проекты, ошибки в которых могут привести к…":

• опасности для жизни людей,
• невосполнимым финансовым потерям,
• финансовым потерям в ограниченном объеме,
• снижению комфортности конечного пользователя.

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

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

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

2.4. Расширенный анализ требований.

Моделирование

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