kazminaviktoriya1
В профиль
Выход
![](data:image/svg+xml,<svg xmlns="http://www.w3.org/2000/svg" width="42" height="42"><rect fill-opacity="0"/></svg>)
Добавить аккаунт
Диаграмма деятельности (нотация UML Activity Diagram)
В предыдущем уроке вы узнали, что BPMN — мощный инструмент для моделирования бизнес-процессов. Однако описать бизнес-процесс можно и с помощью нотации UML Activity Diagram. В этом уроке расскажем, как СА может применять Activity Diagram в своей работе.
Скорее всего, у вас возник вопрос, есть ли разница между моделированием бизнес-процессов с помощью BPMN и UML и от чего зависит выбор нотации. Вспомним, что существует два основных подхода к системному анализу и проектированию систем:
- традиционный, когда СА описывает всю систему в виде моделей процессов и данных;
- объектно-ориентированный, при котором СА разделяет систему на независимые объекты, содержащие и процессы, и данные.
BPMN принято использовать при традиционном подходе к системному анализу. С помощью BPMN можно моделировать даже самые сложные бизнес-процессы.
UML-нотация чаще применяется при объектно-ориентированном подходе. С её помощью можно охватить все стадии моделирования системы. Вы уже работали с нотацией UML, когда составляли Use Case, Class Diagram и Object Diagram.
Выбор нотации зависит от устоявшихся процессов в компании. В одних компаниях принято использовать BPMN, в других — UML, а в некоторых — и то и то. Чаще всего BPMN применяют для описания бизнес-процессов, а UML Activity Diagram — для описания системных процессов.
Например, бизнес-аналитик описывает процесс предоставления отпусков в организации с помощью BPMN. Затем он формулирует требование автоматизировать согласование отпусков и передаёт его системному аналитику. А СА описывает процесс согласования отпусков в системе с помощью UML-диаграмм.
Что такое Activity Diagram
Activity Diagram, или диаграмма деятельности, описывает логику переходов от одной деятельности к другой. С помощью этой диаграммы можно моделировать все три вида процессов, о которых шла речь в первом уроке:
- бизнес-процессы,
- системные процессы,
- порядок выполнения программ.
Диаграммы деятельности используют как для описания текущих процессов (as-is), так и для изображения будущего процесса (to-be).
Элементы UML Activity Diagram
Рассмотрим основные элементы модели процесса в нотации UML Activity Diagram. Для примера возьмём процесс проверки домашнего задания.
Действия
Представьте, что в процессе проверки домашнего задания ревьюеру нужно выполнить следующие действия:
- Открыть задание.
- Проанализировать задание.
- Сверить решение с ответом.
- Оценить задание.
Действия в диаграмме деятельности обозначаются прямоугольниками со скруглёнными углами:
Потоки
Теперь надо определить последовательность действий. В этом помогут потоки, которые изображаются в виде однонаправленных стрелок.
В примере после действия «открыть задание» идёт действие «проанализировать задание».
Но ведь ревьюер не просто анализирует задание, а одновременно сверяет его с ответами. Чтобы обозначить параллельность потоков, можно использовать разветвитель, который представляет собой жирную линию.
Для синхронизации потоков в один поток тоже используем разветвитель, который одновременно является синхронизатором.
В отличие от BPMN, диаграммы деятельности в нотации UML чаще всего представляют в вертикальном виде. Горизонтальное представление тоже допустимо. Главное, чтобы действия следовали друг за другом сверху вниз или слева направо.
События
В диаграмме деятельности события представлены различными элементами в зависимости от типа. Выделяют следующие типы событий:
- начальное состояние системы,
- конечное состояние системы,
- конец потока,
- передача сигнала,
- приём сигнала.
Рассмотрим каждый из них подробнее.
У любого процесса есть начало и конец. В UML Activity Diagram начальное состояние системы обозначается как сплошной круг, и именно с него начинается каждая диаграмма. Начальное состояние уникально и указывает на первое действие в процессе.
Однонаправленные стрелки используются не только для указания последовательности действий, но и для соединения действий с событиями.
На рисунке ниже начальное состояние системы указывает на первое действие процесса — «открыть задание».
Окончание процесса соответствует конечному состоянию системы. Оно обозначается как сплошной круг в центре круга. У системы должно быть как минимум одно конечное состояние, но может быть и несколько.
В примере последнее действие — «оценить задание». Именно его нужно соединить с конечным состоянием системы. В итоге диаграмма, описывающая процесс от начала до конца, приобретёт следующий вид:
Однако процесс по какой-то причине может прерваться, не достигнув логического конца. Такие события называются концом потока и обозначаются крестом в центре круга.
Например, процесс может прерваться, если задание не выполнено (студент сдал пустой лист) и ревьюеру нужно отправить студенту напоминание. Концов потока может быть несколько.
Диаграмма деятельности также может описывать поведение, на которое влияют внешние события, происходящие за пределами системы. Для этого используют сигналы. Представьте, что ответы к домашнему заданию хранятся в сторонней системе «Банк ответов» и ревьюер получает их по запросу.
Для начала нужно отправить сигнал в «Банк ответов» с запросом ответа. Передача сигнала — это его создание на основе входящих данных и отправка внешней системе. Передача сигнала обозначается следующим образом:
Приём сигнала — это ожидание и приём события. Приём сигнала выглядит так:
Весь процесс можно представить в виде такой диаграммы:
Точка принятия решения
Как понять по диаграмме, отправил ли студент задание, можно ли продолжать процесс оценивания, или задания нет и процесс прервался? Для этого существуют точки принятия решения.
Точка, в которой нужно принять решение о следующих действиях или событиях, обозначается в виде ромба. В точку принятия решения входит один поток, а выходят из него два или более альтернативных потока.
Обратите внимание, что для каждого исходящего потока задаётся выражение, на которое можно ответить «да» или «нет» («истина» или «ложь»). Исходящие потоки не должны накладываться друг на друга: они должны быть сформированы так, чтобы только один из них мог принимать значение «истина».
Допустим, при открытии задания ревьюер будет оценивать следующие критерии: «выполнено» или «не выполнено». Задание не может быть выполнено и не выполнено одновременно, то есть только один поток может принять значение «истина».
Если выделить потоки «выполнено» и «отформатировано», возникнут сложности. Задание может быть выполнено (есть ответы на все пункты) и отформатировано (соответствует требуемому формату) одновременно. Значит, в точке принятия решения можно выбрать оба потока. Такого не должно быть.
Правильно будет добавить две точки принятия решений. Первая — «выполнено» и «не выполнено». Вторая — «отформатировано» и «не отформатировано».
Как и в случае с разветвителем, где один и тот же элемент служит для синхронизации параллельных потоков, точка принятия решения используется для объединения альтернативных потоков:
Роли
Если в процессе несколько ролей, это должно быть отражено в диаграмме. Действия в таком случае разделяют по ролям с помощью дорожек — колонок, разделённых пунктирными линиями. Добавим роль «студент» в процесс.
Вы исправили ошибки — правильная диаграмма будет выглядеть так:
Ссылки
На последнем этапе составления диаграммы стоит уточнить сложные действия. Допустим, нужно уточнить процесс «оценить задание»: разделить на «зачёт» и «незачёт».
Как такового элемента ссылки в нотации UML нет. Однако описать подпроцессы можно другими способами. Например, процесс можно добавить в элемент уточняемого действия:
Диаграмма получилась громоздкой, а ведь ещё не расставлены оценки при зачёте (удовлетворительно, хорошо, отлично).
Чтобы сохранить компактность, подпроцесс часто выделяют в отдельную диаграмму.
На эту диаграмму можно сослаться, используя особый элемент — комментарий. Комментарий добавляют для любой дополнительной информации, включая ссылки на другие диаграммы. Элемент и связанный с ним комментарий соединяют пунктирной линией.
Данные
Объект — самый главный элемент объектно-ориентированного подхода к системному анализу. Вы уже работали с объектами, когда изучали UML-диаграммы объектов. Напомним, что объект — это экземпляр класса с конкретным состоянием свойств.
В диаграмме деятельности объект указывает на то, что экземпляр класса доступен в определённый момент процесса. В отличие от действий, объект — необязательный элемент диаграммы такого типа. Однако иногда объекты играют важную роль. Например, они могут инициировать действия или быть результатом действий. Тогда появляется необходимость явно указать объекты в диаграмме.
Добавим в диаграмму объект «задание». Он изображается в виде прямоугольника, как и в UML-диаграмме объектов. Обратите внимание, что объект соединяется с действиями с помощью пунктирных стрелок — потоков объекта.
В данном случае студент передаёт ревьюеру конкретное задание, которое он выполнил. Задание в дальнейшем используется в действии «открыть задание».
Как построить UML Activity Diagram — чек-лист:
1. Составьте перечень действий в системе (список операций).
2. Составьте список ролей.
3. Определите порядок действий и соотнесите их с ролями.
4. Выделите параллельные потоки деятельности.
5. Определите условия переходов к действиям.
6. Уточните сложные действия.
Подведём итоги
UML-диаграмма деятельности используется прежде всего для описания системных процессов при объектно-ориентированном подходе к системному анализу.
В диаграмме можно использовать все основные элементы процесса:
- действия,
- потоки,
- события,
- точки принятия решения,
- роли.
Теперь вы сможете читать диаграммы процессов в разных доменных областях, а также составлять собственные в нотации UML Activity Diagram.
Мы подготовили для вас таблицу с основными элементами нотации. Сохраните её себе, чтобы ничего не забыть.
