Диаграммы прецедентов

Цель: Приобрести практические знания и навыки создания и проектирования диаграмм прецедентов.

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

Прецедент в объектном моделировании (англ. – use case) представляет собой документ, описывающий последовательность событий, связанных с исполнителем (внешним агентом), который для завершения требуемого процесса использует создаваемую систему. Прецеденты являются описанием или вариантами использования системы. С помощью прецедента описывается некоторый процесс.

По результатам анализа прецедентов на первом этапе моделирования предметной области создается диаграмма определения требований к системе Use Case (сценарии поведения). Данная диаграмма позволяет создавать диаграммы поведения объектов системы.

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

Рис.1 – Диаграмма прецедентов, описывающая процесс

обслуживания клиента в банке

Диаграмма прецедентов содержит:

- варианты использования (прецеденты) системы (use case);

- действующее лицо (actor).

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

Варианты использования системы – описание функций системы на «высоком уровне». Они описывают все, что происходит внутри области действия системы. Варианты использования иллюстрируют, как можно использовать систему. Они заостряют внимание на том, что пользователи хотят получить от системы. Каждый вариант использования представляет собой завершенную транзакцию между пользователем и системой.

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

Каждый прецедент должен быть инициирован действующим лицом.

Как правило, отдельные шаги или виды деятельности в виде прецедента не представляются.

Часто для одной системы создается несколько диаграмм Вариантов Использования. На диаграмме высокого уровня (Main) указываются только пакеты вариантов использования. Другие диаграммы описывают совокупности вариантов использования и действующих лиц.

Цель диаграмм – документирование вариантов использования, действующих лиц и связей между ними. Разрабатывая диаграммы, придерживаются правил:

1. Не моделируют связи между действующими лицами. По определению они находятся вне сферы действия системы. Связи между ними не относятся к ее компетенции.

2. Не соединяют стрелкой непосредственно два варианта использования (кроме связей использования и расширения). Диаграмма описывает только, какие варианты использования доступны системе, а не порядок их выполнения.

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

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

При создании диаграмм прецедентов вначале определяются исполнители (роли, пользователи) (Рис. 2).

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

Рис. 2. Определение ролей исполнителей

Следующий шаг - идентификация прецедентов.

У каждого прецедента должно быть уникальное имя.

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

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

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

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

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

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

- нормальный, или основной, поток событий варианта использования,

- отклонения от основного потока событий (так называемые альтернативные потоки),

- потоки ошибок,

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

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

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

В диаграммах прецедентов поддерживается несколько типов связей:

- связи коммуникации (Communication) – описывают связи между действующими лицами и вариантами использования;

- использования (uses) и расширения (extends) – отражают связи между вариантами использования;

- обобщения действующего лица (actor generalization) – между действующими лицами.

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

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

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