Теоретическая часть. Создание диаграммы прецедентов

Лабораторная работа № 1.

Создание диаграммы прецедентов.

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

Задание:

1. создать главную диаграмму прецедентов, задав на ней варианты использования и актеров;
2. добавить отношения между актерами и вариантами использования;
3. создать дополнительную диаграмму прецедентов;
4. добавить описания к актерам и вариантам использования;
5. для каждого варианта использования задать поток событий в виде отдельного файла и прикрепить его к варианту использования.

Содержание отчета:

1. созданные диаграммы прецедентов;
2. краткое описание каждого актера и прецедента;
3. описание потока событий для каждого варианта использования.

Теоретическая часть

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

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

- определение общих границ и контекста моделируемой предметной области на начальных этапах проектирования системы;

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

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

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

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

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

Актер – это роль объекта вне системы, который прямо взаимодействует с ее частью – конкретным элементом (элементом UseCase). Различают актеров и пользователей. Пользователь – это физический объект, который использует систему. Он может играть несколько ролей и поэтому может моделироваться несколькими актерами. Справедливо и другое – актером могут быть разные пользователи. Например, для коммерческого летательного аппарата можно выделить двух актеров: пилота и кассира. Сидоров – пользователь, который иногда действует как пилот, а иногда как кассир. В зависимости от роли Сидоров взаимодействует с разными элементами UseCase.

Элемент UseCase – это описание последовательности действий (или нескольких последовательностей), которые выполняются системой и производят для отдельного актера видимый результат. Один актер может использовать несколько элементов UseCase, и наоборот один элемент UseCase может иметь несколько актеров, использующих его. Каждый элемент UseCase задает определенный путь использования системы. Набор всех элементов UseCase определяет полные функциональные возможности системы.

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

Элемент UseCase описывает, что должна делать система, но не определяет, как она должна это делать. При моделировании это позволяет отделять внешнее представление системы от ее внутреннего представления. Поведение элемента UseCase описывается потоком событий. Начальное описание выполняется в текстовой форме, прозрачной для пользователя системы. В потоке событий выделяют: основной поток и альтернативные потоки поведения; как и когда стартует и заканчивается элемент UseCase; когда элемент UseCase взаимодействует с актерами; какими данными обмениваются актер и система. Для уточнения и формализации потоков используют диаграммы последовательности. С помощью диаграммы последовательностей можно описать полный контекст взаимодействий как своеобразный график "жизни" всей совокупности объектов, взаимодействующих между собой для реализации варианта использования программной системы, достижения бизнес-цели или выполнения какой-либо задачи. Обычно одна диаграмма последовательности определяет главный поток в элементе UseCase, а другие диаграммы – потоки исключений. В общем случае каждый элемент UseCase описывает набор последовательностей, в котором каждая последовательность представляет возможный поток событий. Каждая последовательность называется сценарием. Сценарий – конкретная последовательность действий, которая иллюстрирует поведение. Сценарии являются для элемента UseCase почти тем же, чем являются экземпляры для класса. Говорят, что сценарий – это экземпляр элемента UseCase.