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

Лабораторная работа №2

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

Задание:

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

- создать диаграмму деятельности, описывающую поток событий одного из вариантов использования, созданного в лабораторной работе № 1.

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

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

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

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

В качестве графического представления для выделения основных функций Системы применяется диаграмма вариантов использования (use case).
Диаграмма вариантов использования дает представление, что должна делать Система. На вопрос КАК можно ответить, используя диаграмму активности.

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

Деятельность может содержать входящие и/или исходящие дуги деятельности, показывающие потоки управления и потоки данных. Если поток соединяет две деятельности, он является потоком управления. Если поток заканчивается объектом, он является потоком данных.

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

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

Переход маркера осуществляется между узлами. Маркер может не содержать никакой дополнительной информации (пустой маркер) и тогда он называется маркером управления (control flow token) или же может содержать ссылку на объект или структуру данных, и тогда маркер называется маркером данных (data flow token).

Для создания диаграммы деятельности используются следующие узлы:

	Узел управления (control node) – это абстрактный узел действия, которое координирует потоки действий
	Начальный узел деятельности (или начальное состояние деятельности) (activity initial node) является узлом управления, в котором начинается поток (или потоки) при вызове данной деятельности извне
	Конечный узел деятельности (или конечное состояние деятельности) (activity final node) является узлом управления, который останавливает (stop) все потоки данной диаграммы деятельности. На диаграмме может быть более одного конечного узла
	Конечный узел потока (или конечное состояние потока) (flow final node) является узлом управления, который завершает данный поток. На другие потоки и деятельность данной диаграммы это не влияет
	Объект, над которым выполняются действия. Это не обязательный элемент диаграммы, но в некоторых случаях необходимо показать объект инициирующий выполнение действий, или являющийся результатом его

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

Узел решения предназначен для определения правила ветвления и различных вариантов дальнейшего развития сценария.

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

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

Далее следуетобратить внимание на такой элемент, как узел объединение. Узел объединения имеет два и более входящих узла и один исходящий.

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

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

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

· входит ровно один поток;

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

Точка слияния обеспечивает синхронизацию нескольких параллельных потоков.

· входят два или более потока, причем эти потоки выполняются параллельно;

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

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

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

Передача сигнала (send signal action) - действие, которое на основе своих входов создает экземпляр сигнала и передает его внешней Системе.

Прием события (receive event action) - действие, которое ожидает некоторого события, принимает и обрабатывает полученное сообщение.

На диаграмме представлено взаимодействие двух независимых Систем: «Учетная система» и «Веб-магазин».

· Результатом действия по приему банковской выписки и разнесению оплаты является входящий сигнал для ИС «Веб-магазин» сообщающей об оплате товара.

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

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

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

Центральный буфер -объект, который управляет потоками между множественными источниками и приемниками. На диаграмме центральный буфер представляется в виде объекта со стереотипом <<centralbuffer>>.
</centralbuffer>>

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

На рисунке представлена диаграмма, которая отражает сценарий формирования списка сравнения товаров:

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

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

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

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

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

Частный случай Центрального буфера – Хранилище данных.

Принципиальным отличием Хранилища данных является то, что оно содержит все поступившие данные и на выходе отдает лишь копии. Таким образом, результатом действия «Сформировать заказ» является непосредственно заказ, который помещается в базу заказов. Для дальнейшей обработки заказа или мониторинга выполнения заказов, из базы осуществляется запрос данных заказа. Данные предоставляются в виде копий, в то время как оригинал продолжает оставаться в Базе заказов. Копирование данных осуществляется каждый раз, когда заказ выбирается для осуществления каких-либо действий.

Если пришедший заказ уже содержится в хранилище, то предыдущий объект будет заменен.

Далее следует подробно рассмотреть разбиение деятельности на разделы.

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

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

Расположение дорожек может быть как вертикальным, так и горизонтальным. Несколько дорожек могут быть объединены по организационному принципу.

В UML 2 принято правило применять горизонтальное расположение дорожек для отображения модели бизнес-процесса.

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

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

Спецификация UML дает несколько способов представления декомпозиции деятельности на диаграмме. Мы можем использовать обозначение под-деятельности (subactivity state), где указываем:

· наименование деятельности;

· предусловие и постусловие

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

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

При необходимости описание последовательности действий для под-деятельности может быть размещено непосредственно на основной диаграмме. Для этого описание под-деятельности размещается в отдельный фрейм.

При таком способе декомпозиции мы можем указать:

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

· входные и выходные параметры (объекты);

· внутреннее устройство деятельности.

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

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

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

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

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

· входные и выходные данные;

· объекты, управляющие процессом (в нашем случае это каталог товаров и прайс-лист);

· используемые ресурсы (в нашем примере это Покупатель и Менеджер).

На слайде показаны стандартные UML-объекты «действие» и «объект», но со специальными стереотипами:

· Для действия - стереотип <<process>></process>>

· Для объекта - стереотип <<information>>, <></information>>

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

Диаграмма деятельности данного вида хорошо отражает:

· последовательность действий;

· события, инициирующие действия или являющиеся конечным результатом;

· условия расширения сценария

Практическая часть:

Часть 1

Построить диаграмму деятельности для бизнес-процесса предприятия по сборке компьютеров.

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

Результат построения диаграммы показан на рис. 1:

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

2. Создание диаграммы деятельности потока события варианта использования "Работа с заказом"

Поток событий варианта использования "Работа с заказом" состоит из главного потока, под-потоков и альтернативных потоков.

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

Рисунок 2. Диаграмма деятельности для потока событий прецедента "Работа с заказом"

Пример декомпозиции действия На рис. 3 показана диаграмма деятельности для под-потока "Добавить заказ", которая является декомпозицией действия "Добавить заказ" главной диаграммы деятельности.

Рисунок 3. Диаграмма деятельности для действия "Добавить заказ"