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

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

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

Требование (requirement) - желательное свойство, характеристика или условие, которым должна удовлетворять система в процессе своей эксплуатации

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

• функциональные требования  (Functionality)
• требования удобства использования ( Usability )
• требования надежности ( Reliability )
• требования производительности (Performance)
• требования возможности сопровождения (Supportability)
• символом "+" обозначены дополнительные условия, к которым относятся:
• проектные ограничения
• требования управления системой
• требования к графическому интерфейсу пользователя

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

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

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

Один из таких  шаблонов  рассматривается ниже и рекомендуется для применения на начальных этапах концептуального моделирования

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

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

Построение  диаграммы вариантов использования  - самый первый этап процесса  объектно-ориентированного анализа и проектирования . Цель его - представить совокупность  функциональных требований  к поведению проектируемой системы.

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

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

которая в языке  UML  получила название модели вариантов использования и имеет свое специальное стандартное имя или стереотип .

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

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

Особенности спецификации функциональных требований на диаграмме вариантов использования

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

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

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

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

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

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

(Рисунок 1 - Диаграмма вариантов использования для модели банкомата ).

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

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

Таблица 1 - Главный раздел сценария выполнения варианта использования "Снятие наличных по кредитной карточке"

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

Таблица2. Раздел Типичный ход событий сценария выполнения варианта использования "Снятие наличных по кредитной карточке"

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

Таблица 3. Раздел Исключения сценария выполнения варианта использования "Снятие наличных по кредитной карточке"

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

Отдельные небольшие по своему объему  сценарии  могут быть размещены на диаграмме в форме примечаний.

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

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

Графически примечания на всех типах диаграмм обозначаются прямоугольником с "загнутым" верхним правым уголком (рисунок ниже). Собственно текст примечания размещается внутри этого прямоугольника. Примечание может относиться к любому элементу диаграммы, в этом случае их соединяет пунктирная линия. Если примечание относится к нескольким элементам, то от него проводятся соответственно, несколько линий. Как уже отмечалось, примечания могут присутствовать не только на диаграмме вариантов использования, но и на других  канонических диаграммах .

Примеры примечаний на диаграммах вариантов использования

, то данное примечание является ограничением, налагаемым на соответствующий элемент модели, но не на саму диаграмму. При этом  запись ограничения заключается в  фигурные скобки  и должна соответствовать правилам построения выражений языка OCL. Однако для диаграмм вариантов использования ограничения включать в модели не рекомендуется, поскольку они достаточно жестко регламентируют физические аспекты реализации системы, что противоречит концептуальному характеру общей модели вариантов использования. " width="640"

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

Рекомендации по разработке диаграмм вариантов использования

• Определить главных или первичных и второстепенных актеров
• Определить цели главных актеров по отношению к системе
• Сформулировать основные варианты использования, которые специфицируют  функциональные требования  к системе
• Упорядочить варианты использования по степени убывания риска их реализации
• Рассмотреть все базовые варианты использования в порядке убывания их степени риска
• Выделить участников, интересы, предусловия и постусловия выполнения выбранного варианта использования
• Написать успешный  сценарий  реализации выбранного варианта использования

Выделить варианты использования для исключений и изобразить их взаимосвязи с базовыми со стереотипом Проверить диаграмму на отсутствие дублирования вариантов использования и актеров " width="640"

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