Учебное пособие ТОАУ Ч.3 (1021725), страница 5

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 5)

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

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

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

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

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

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

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

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

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

В случае, если альтернативный сценарий не удается описать одной строкой - применяется следующий формат:

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

<Номер шага.Номер расширения.Номер шага расширения> <Действие>

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

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

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

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

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

Таблица

Таблица 8.2.

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

С шаблоном описания варианта использования RUP и примерами можно ознакомиться в интерактивной версии RUP).

Перечень и содержание разделов:

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

2. Поток событий

2.1. Основной поток событий

Так же, как в "Основной сценарий".

2.2. Альтернативные потоки событий

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

1. Специальные требования

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

1. Предусловия

События, описываемые предусловиями или постусловиями, должны быть состояниями, которые пользователь может наблюдать [8.3]. Предусловие описывает состояние, в котором система должна находиться до начала исполнения прецедента.

1. Постусловия

Постусловие RUP по сути описывает то же, что и минимальная гарантия у Коберна.

1. Точки расширения

Данный параграф определяет положение точек, расширяющих поток событий.

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

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

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

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

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

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

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

• опасности для жизни людей,

• невосполнимым финансовым потерям,

• финансовым потерям в ограниченном объеме,

• снижению комфортности конечного пользователя.

Спецификация нефункциональных требований

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

Атрибуты требований

Описания требований должны быть операбельны. Для этого все требования должны учитываться в той или иной учетной системе, будь то электронная таблица MS Excel, специализированная база данных, либо интегрированная среда управления изменениями. При регистрации требования оно проходит классификацию в соответствии с определенной системой признаков. Основные признаки (атрибуты) требований были рассмотрены раньше. Кроме того, для оперативного управления требованиями бывает полезно назначить им такие свойства, как проект, ответственное лицо, статус, риск, степень законченности и т.п. В RUP для управления атрибутами требований предусмотрен артефакт "Атрибуты требований".

Артефакт "Атрибуты требований", предлагаемый RUP, представляет собой репозиторий текстов требований, их атрибутов и трассируемости.

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

Трассируемость описывается в виде дерева, показывающего в графическом виде входящие и (или) исходящие связи трассируемости .

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

На сегодня в арсенале аналитика существуют десятки методик, языков, визуальных представлений, позволяющих моделировать требования к системе. При создании информационных систем стандартом де-факто является универсальный язык моделирования, UML [9.1,9.2].

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

Рекомендации по выбору средств моделирования:

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

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

Однако, наиболее важным является третье соображение, в чем-то "оппозиционное" по отношению к первым двум. Для моделирования анализа требований следует применять модели, наиболее адекватно проясняющие функциональность системы и особенности ее использования. Однако, аналитик волен выбирать те языки и методики, которые позволят добиться целевой функции: снижения рисков непонимания между Исполнителем и Заказчиком и размытия границ. Поэтому, иллюстрируя варианты использования, начинайте с "канонических" способов, которые будут рассмотрены чуть ниже, но, если посчитаете целесообразным отклониться от них - экспериментируйте смело.

Модели UML, поясняющие функциональность системы

Диаграмма вариантов использования

Диаграмма вариантов использования UML, Use Case Diagram - одно из самых простых представлений системы. Ее базовые "строительные элементы" - акторы и варианты использования. Диаграмма задумана так, чтобы дать наиболее общее представление о функциональности системы (ее компоненты), не вдаваясь в детали взаимосвязей функций. Поэтому основной вид отношения, используемый в диаграмме - ассоциация между актором и вариантом использования.

Рис.

Другие виды отношений - отношение включения (include), расширения (extend) и обобщения/генерализации.

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

Рис.

Расширение в точности соответствует точке расширения, используемой при описании варианта использования.

Рис.

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

Рис.

Диаграмма действий

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

Основные компоненты описания системы:

• Функции (действия),

• Символы "старт" и "стоп",

• Потоки управления,

• Разветвители,

• Линейки синхронизации.

Рис.

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

Помимо стандартного формата описания, UML предлагает вариант с "плавательными дорожками". Этот формат удобен для описания случая, когда в варианте использования участвуют несколько акторов.

Диаграмма состояний

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

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

Характеристики

Список файлов книги