Теоретическая справка

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

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

Идеальные варианты использования (essential use cases) — это развернутые варианты использования, выражающие общую сущность процесса без детализации их реализации.

Варианты использования необходимо ранжировать по трем категориям: основные, второстепенные и дополнительные.

Основные варианты использования (primary use cases) представляют самые общие процессы, например покупку товара.

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

Дополнительные варианты использования (optional use cases) описывают процессы, которые могут быть не реализованы в системе.

Варианты использования начинают описывать, что должна будет делать система, но чтобы разработать систему необходимо определить конкретные детали в документе, называемом «поток событий» (flow of events). Целью потока событий является документирование процесса обработки данных, реализуемого в рамках варианта использования. Этот документ подробно описывает, что будут делать пользователи системы и что — сама система. Поток событий содержит:

q краткое описание;

q предусловия;

q основной поток событий;

q альтернативный поток событий;

q постусловия.

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

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

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

q описание того, каким образом запускается вариант использования;

q различные пути варианта использования;

q основной поток варианта использования;

q отклонения от основного потока использования;

q потоки ошибок;

q описание того, каким образом завершается вариант использования.

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

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

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

Функциональная модель предметной области (business use case model) определяется как иерархия диаграмм.

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

Последующие уровни иерархии могут включать также одну или несколько организационных единиц (organization unit), например, это могут быть подразделения автоматизируемого предприятия. Или могут включать действующих лиц производственного процесса: субъектов (business worker) и объектов (business actor), их варианты использования (business use case), связи (relationships) между действующими лицами и их вариантами использования и между вариантами использования.

Для изображения организационных единиц (organization unit) на диаграммах вариантов использования (use case diagram) используется изображение следующего вида


Рис. 2.1. Изображение организационных единиц (organization unit) на диаграммах вариантов использования (use case diagram)

Под изображением организационной единицы указывается ее наименование.

Действующее лицо - субъект производственного процесса (business worker) обозначается на диаграммах вариантов использования (use case diagram) как представлено на рис. 2.2., действующее лицо - объект (business actor) производственного процесса - как представлено на рис. 2.3.

Рис. 2.2. Изображение субъекта производственного процесса (business worker) на диаграммах вариантов использования (use case diagram)

Рис. 2.3. Изображение объекта производственного процесса (business actor) на диаграммах вариантов использования (use case diagram)

Изображение объекта производственного процесса также можно использовать и для обозначения субъекта производственного процесса.

Под изображением действующего лица указываются его наименование. Наименование действующего лица есть роль, которую он выполняет в производственном процессе, например, дилер (business worker), автоматизированная система торгов (business actor). Бизнес функции (business use case) изображаются на диаграммах функций (use case diagram) как овал следующего вида (рис.2.4)

Рис. 2.4. Изображение бизнес-функции (business use-case) на диаграммах вариантов использования (use case diagram)

Декомпозированные варианты использования (business use case realization), т.е те варианты использования которые предполагается описать более подробно с помощью, например, диаграмм взаимодействия и т.п., изображаются на диаграммах вариантов использования (use case diagram) как овал, представленный на рис 2.5

Рис. 2.5. Изображение декомпозированной бизнес (business use-case realization)

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

Связи на диаграммах вариантов использования (business case diagram) имеют место: между организационными единицами; между действующим лицом и вариантом использования; между вариантами использования.

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

На рис. 2.6. представлен пример связи между организационными единицами.

Рис. 2.6. Пример зависимой связи между организационными единицами

Между действующим лицом производственного процесса (business worker или business actor) и вариантом использования устанавливается связь, которая называется ассоциацией (Unidirectional Association). Связь отражает наличие определенной функции у действующего лица. В Rational Rose может поддерживаться несколько типов связей. Это связи коммуникации (communication), использования (uses), расширения (extends) и обобщения действующего лица (actor generalization).

Связи коммуникации описывают связи между действующими лицами и вариантами использования. Такая связь обозначается сплошной линией со стрелкой или без нее. На рис. 2.7. представлен пример связи между действующим лицом и функцией.

Рис. 2.7. Пример связи между действующим лицом и функцией

В двойных скобках «» может указывается стереотип связи, например, «communicates» (взаимодействует).

Связи использования и расширения отражают связи между вариантами использования. Связь использования позволяет одному варианту использования задействовать функциональность другого. С помощью таких связей обычно моделируют многократно применяемую функциональность, встречающуюся в двух или более вариантов использования. Например, при проектировании системы работы банкомата, варианты использования «Снять деньги» и «Положить деньги на счет» должны опознать (аутентифицировать) клиента и его идентификационный номер перед тем, как разрешить выполнение самой транзакции. Вместо того, чтобы подробно описывать процесс аутентификации для каждого из них, можно поместить эту функциональность в свой собственный вариант использования под названием «Аутентифицировать клиента». Когда какому-нибудь варианту использования потребуется выполнить эти действия, он сможет воспользоваться функциональностью созданного варианта использования «Аутентифицировать Клиента». Связь использования изображается с помощью стрелок и слова <<uses>>, как показано на рис. 2.8.

Рис. 2.8. Пример связи со стереотипом <<uses>>

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

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

Примеры связей «include» и «extends» между функциям представлены на рис. 2.9, 2.10.

Рис. 2.9. Пример связи со стереотипом «include»

Рис.2.10. Пример связи со стереотипом «extends»

На рис. 2.11 представлена архитектура модели производственных функций.

Рис. 2.11. Архитектура модели производственных функций


Понравилась статья? Добавь ее в закладку (CTRL+D) и не забудь поделиться с друзьями:  



double arrow
Сейчас читают про: