Диаграммы деятельности: наглядное представление хронологических процессов деятельности с помощью UML

Диаграмма деятельности — это тип диаграммы в рамках «Унифицированного языка моделирования» (UML). Этот язык графического моделирования определяет формы для представления объектно-ориентированного программирования. В нем определено 14 типов диаграмм. Им присваиваются определенные формы. С помощью правил нотации системы и процессы могут быть абстрагированы и наглядно представлены. UML моделирует не только программные системы, но и бизнес-процессы. Диаграммы деятельности особенно полезны в обеих областях. Но зачем вам создавать диаграмму деятельности?

Диаграммы деятельности UML относятся к группе диаграмм поведения в унифицированном языке моделирования. Если диаграмма структуры фиксирует состояние системы, то есть существующие объекты и их иерархии, а также связи друг с другом в определенный момент, то диаграммы поведения описывают хронологическое движение потоков данных. Помимо диаграммы деятельности, к этой группе относятся «диаграмма сценариев использования» и «диаграмма машины состояний». Диаграммы деятельности похожи по использованию и обозначениям на блок-схемы (особенно на блок-схемы программ), но приспособлены для объектно-ориентированного программирования.

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

Параллельные процессы также можно проиллюстрировать. Если за приготовление омлета отвечают два человека, это позволяет выполнять действия одновременно, то есть разбивать яйца и рубить зелень. Это означает, что деятельность имеет две начальные точки. Люди начинают свою деятельность в этих точках и переходят от одного действия к другому. Хотя эти два человека играют важную роль в диаграмме деятельности, у них нет собственных обозначений. Вы двигаетесь от начальной точки к конечной, пересекая потоки управления или объектов, чтобы перейти от одного действия к другому. Между ними периодически возникают барьеры, так называемые «штыри», через которые можно пройти только при определенных условиях, например, когда присутствуют оба человека.

На диаграмме деятельности эти «лица» называются маркерами. В диаграмме деятельности UML существует два типа маркеров: первый — это маркер объекта, который передает информацию в узел действия, запускает там действие и (если указано) сохраняет результат в виде значения. Если результат и маркер соответствуют спецификациям, определенным в выводе, этот выводной вывод отправляет объектный маркер через объектный поток к следующему действию. Прежде чем маркер сможет начать это действие, он должен соответствовать спецификациям входного пина. Управляющие маркеры, с другой стороны, мигрируют только по управляющим потокам и служат в качестве маркеров. Они запускают действие, но не передают никаких данных.

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

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

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

Object Management Group (OMG), которая специфицирует UML, обобщает возможные задачи диаграмм деятельности UML 2.

• Процедурное компьютерное программирование, которое присваивает иерархии видам деятельности
• В объектно-ориентированных моделях виды деятельности выступают в качестве методов, которые более детально описывают процессы.
• Для иллюстрации рабочих процессов и бизнес-процессов
• В компьютерных прикладных системах деятельность определяет процессы на уровне системы.

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

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

Как визуально представлены отдельные компоненты и какие функции выполняют символы в диаграмме деятельности UML?

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

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

Действие (исполняемый узел) — это элемент модели, который иерархически подчинен деятельности: действие является экземпляром класса «деятельность». Действия представляют поведение в системе. Они являются основными строительными блоками для выражения поведения в UML. Они используются как в диаграммах деятельности, так и во взаимодействиях.

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

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

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

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

1. Непрозрачные действия выступают в качестве заполнителей или задаются конкретным текстовым синтаксисом (не определенным в UML).
2. Вызывающие действия — это действия, которые вызывают определенное поведение — прямо или косвенно. К ним относятся: 

• Действия вызова: действие вызова поведения непосредственно вызывает поведение. Действие вызова операции, с другой стороны, посылает запрос объекту, который вызывает соответствующее поведение. Действие запуска поведения объекта непосредственно заставляет объект выполнить поведение своего экземпляра. Если таковое не определено, оно может вызвать поведение класса более высокого уровня (поведение классификатора).

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

• Действия отправки: Действия отправки в диаграмме деятельности всегда отправляют данные асинхронно (диаграммы последовательности также знают синхронные сообщения, например). Это означает, что они не ждут ответа от целевого объекта и не блокируют поток объектов. Действие завершается, как только сообщение было отправлено. Таким образом, оно может иметь входной «аргумент», например, параметр, но не производить выходной «результат». Кроме того, сообщения могут быть отправлены нескольким получателям одновременно. Действие отправки сигнала, действие широковещательного сигнала и действие отправки объекта относятся к этому типу.

  Действия отправки сигнала отличаются в своей нотации от обычной формы (закругленный прямоугольник). Вместо этого пятиугольник указывает, как большая стрелка, в направлении передаваемого сигнала. Если содержимое объектного действия send также состоит из сигнала, вы можете использовать ту же нотацию.

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

• «Создать действие объекта» создает экземпляры класса, т.е. объекты.
• «Действия по уничтожению объекта» уничтожают объект на входном контакте.
• «Действия проверки идентичности» проверяют, представляют ли два значения на вашем входном контакте один и тот же объект.
• «Read self actions» определяют собственный контекст объекта.
• «Действия спецификации значения» исследуют спецификации значения (в обозначениях используется метка «спецификация значения»).
• «Read extent actions» находят все объекты класса и объекты из его спецификаций (по практическим причинам моделисты обычно ограничивают диапазон).
• «Reclassify object actions» изменить класс для объекта на входном контакте.
• «Read is classified object actions» определить, принадлежит ли объект на вашем входном выводе к какому-либо классу.
• «Start classifier behavior actions» запускают поведение для объекта, которое определяется его классом (поведение в этом случае асинхронное).

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

• «Действия чтения ссылки» получают значения (данные конца ссылки) на странице ассоциации.
• «Создать действия ссылки» — действия, которые создают ссылки (у них нет выходных контактов, потому что сами ссылки не являются данными) и объекты ссылок
• Действия «Уничтожить ссылку» удаляют ссылки и объекты ссылок, если они соответствуют указанному значению конечных данных ссылки.

1. Действия над объектами ссылок влияют на поведение объектов ссылок, но рассматривают объекты с разных точек зрения. Это экземпляры действий объектов ссылок:

• «Read link object end actions» вызывают конечные объекты из объектов ссылок.
• «Read link object end qualifier actions» вызывают конечные значения классификаторов из объектов ссылок.
• «Create link object actions» — это специальные действия ссылки, которые используются для создания объектов ссылки.

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

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

1. Действия с переменными воздействуют на статически заданные переменные, определенные деятельностью или узлом структурированной деятельности. Существует три типа:

• «Добавить значение переменной» также требует ввода значения, но должно быть того же типа, что и переменная, и добавляет к ней ровно одно значение.
• «Удалить значение переменной» удаляет значение, указанное штифтом.
• «Очистить переменную» удаляет все значения переменной.

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

• «Действия принятия вызова» имеют триггер, который принимает события вызова: два вывода результата и вывод информации о возврате завершают организацию (если должно быть выполнено действие ответа, сохраните необходимую информацию в выводе информации о возврате).

• «Ответные действия» имеют связь с действиями приема вызова: С одной стороны, триггеры должны совпадать, чтобы ответное действие могло реагировать на ранее выполненное действие приема вызова в случае события вызова, с другой стороны, поведение более высокого уровня помещает свое выходное значение во входной контакт возвратной информации ответного действия.
• «Немощные действия» запрашивают значения структурных признаков объекта (для распознавания объекта они имеют входной контакт объекта; полученные значения выдаются на выходной контакт)

1. Структурированные действия декларирует UML 2 в диаграмме деятельности и как действия, и как группу действий (см. выше). Это означает, с одной стороны, что их поведение определяется узлами деятельности и ребрами, а с другой стороны, что некоторые подтипы этих действий задают определенное поведение для исполняемых узлов в силу своей семантики — особенно в отношении их последовательности.

Это и есть подтипы структурированных действий:

• Условные узлы состоят из одного или нескольких клаузул, которые представляют собой различные ветви возможных исполняемых действий. Клауза содержит сегмент теста и сегмент тела, которые, в свою очередь, содержат бесколичественные исполняемые узлы. Сначала пункт выполняет действие в тестовом сегменте. Если его выходное значение равно «true», то пункт выполняет действие в области тела.
• Узлы циклов описывают группу действий, которые повторяются в цикле. Действия разделены на три секции: «установка», «тест» и «тело». Сначала в цикле всегда выполняется «установка». За ней следует «тест» или «тело», которые затем повторяются поочередно.
• Узлы последовательности накладывают порядок на исполняемый узел в своих пределах. Вы отображаете их с потоками данных в виде ребер активности (т.е. простых стрелок). Грани могут свободно указывать в структуру и из нее.

1. Области расширения — это другая форма структурированных узлов деятельности. Вы принимаете одну или несколько коллекций значений в качестве входных данных. По пути в область расширения входной узел копирует каждый входящий токен в число элементов коллекции. Все нижележащие узлы обрабатывают себя на каждом отдельном значении коллекции. Выполнение считается «выполнением расширения». Узел расширения (тип объектного узла) указывает на интерфейс области расширения. Снаружи они отображают свои значения как коллекцию, внутри отдельные элементы коллекции рассматриваются как значения. Нарисуйте закругленный прямоугольник с пунктирной линией для обозначения. Узлы расширения выглядят как прямоугольники с сегментами и, как показано ниже, рисуются непосредственно на линии. Сегментация должна представлять собой список коллекций значений.

1. Действия уменьшения вызывают поведение до тех пор, пока из коллекции значений не появится единственное значение. Для этого действие объединяет элементы коллекции. Поэтому действие имеет два параметра «вход», но только один параметр «выход» или «возврат».
    
2. Действия с исключением (действия, вызывающие исключение) завершаются, как только они вызывают исключение. Поэтому они не завершаются, как обычные действия, которые останавливаются после завершения действия. Они распространяются по системе до следующего более высокоструктурированного узла активности. Если в нем есть обработчик, соответствующий исключению, он прекращает действие. В противном случае оно будет распространяться дальше.

Объектные узлы являются подтипами узлов активности. В общем случае, объект в UML — это наименьший экземпляр со значениями. На диаграмме деятельности объекты представляют данные. Во время выполнения действия узлы объектов хранят эти данные. Поскольку только управляющие маркеры могут проходить непосредственно через действие. Объектные маркеры, с другой стороны, принимаются как значение на входной вывод и передаются выходным выводом на объектный поток.

Объектные узлы были впервые введены в диаграмме деятельности UML 2. Они представляют собой типизированные элементы. Если объектный узел соответствует определенному типу, то объектные маркеры, которые перемещаются по нему, должны иметь соответствующие значения. Исключение составляют нулевые маркеры, которые управляют без значения — они соответствуют каждому объектному узлу.

Объектные узлы диктуют последовательность, в которой токены покидают их. Существует четыре способа сделать это:

• Неупорядоченный (не задан)
• Упорядоченный (поведение определено разработчиком модели)
• FIFO (первый вошел — первый вышел): порядок входа и выхода остается неизменным
• LIFO (last in first out): порядок в точности противоположный.

Если вы хотите создать диаграмму деятельности, у вас есть четыре типа объектных узлов на выбор для моделирования:

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

1. Узел параметров действия: Активность принадлежит к метаклассу описания поведения. Согласно UML, каждое поведение имеет параметры. Перед выполнением поведения в него можно подавать значения для обработки. После обработки возвращаются новые значения. Параметры в этой структуре являются заполнителями, которые позволяют вводить или выдавать эти значения. Узел параметров деятельности выполняет эту задачу для диаграммы деятельности UML. Это означает, что узлы параметров деятельности находятся в начале и в конце деятельности.

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

1. Буферные узлы: Подобно штифтам, узел буфера (центральный буферный узел) используется непосредственно в диаграмме деятельности. Этот объектный узел хранит или буферизирует значения в любом месте диаграммы. Однако, в отличие от штыря, он стоит сам по себе, без привязки к узлу деятельности. Буферный узел использует объектный поток для соединения входящих и исходящих объектов с другими объектными узлами, например, с булавкой.
   Как и все объектные узлы, узел хранения данных отображается в виде прямоугольника. Чтобы отличить его, запишите в заголовке стереотип «<<datastore>>».
   Узел буфера используется для буферизации входящих и исходящих объектных потоков. Он принимает все входящие объектные маркеры и делает их доступными для исходящих объектных потоков. Только когда объектный узел становится свободным на другом конце потока и принимает параметры объекта, маркер пересылается. Согласно нотации UML, этот режим состоит из простого прямоугольника. Вы можете отобразить его специальные функции с помощью стереотипа «<<centralBuffer>>».

1. Узел хранения данных: Как и буферные узлы, узлы хранения данных переключаются между потоками объектов без привязки к действию. Этот подтип буферных узлов имеет особую особенность: Он хранит копию каждого отправленного маркера до завершения действия более высокого уровня. Однако каждое значение существует только один раз на узле хранения данных. Если узел уже хранит маркер объекта с фиксированной идентичностью, он не принимает новые маркеры с точно такими же свойствами.

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

Существенное различие между объектными и управляющими потоками заключается в том, что по управляющим потокам мигрируют только управляющие маркеры. В отличие от объектных маркеров, эти маркеры не несут никаких данных. Они являются просто маркерами. Таким образом, действия не требуют, чтобы объектные узлы (особенно штыри) принимали и передавали управляющие маркеры. Управляющий маркер начинает действие, переходит к следующему и затем приводит его в движение. Он управляет хронологическим выполнением действия.

Среди символов диаграммы деятельности UML узлы управления, пожалуй, самые разнообразные. Они относятся к узлам деятельности. Вот шесть типов узлов управления UML 2:

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

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

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

1. Узлы распараллеливания и узлы синхронизации (узлы развилки и узлы соединения), также называемые формами, представляют собой узлы управления с почти идентичными обозначениями, которые зеркально отражают их задачи. Узел распараллеливания разделяет входящее ребро деятельности на несколько одновременно исходящих потоков. В узлы распараллеливания может входить только одно ребро деятельности. Если это поток управления, то все исходящие ребра также являются потоками управления; тот же принцип применяется к объектным потокам. Узел создает копии входящего маркера для всех исходящих потоков. Если маркер принят в пункте назначения исходящего потока, маркер удаляется из исходного узла. Если другая цель не принимает маркер, узел распараллеливания может остановить маркер, пока он не будет принят.

Узлы синхронизации работают с точностью до наоборот. В них входит несколько ребер, но выходит только одно ребро. Если все входящие ребра состоят из потоков управления, то именно таким образом поток управления покидает узел. Если под ним находится только один объектный поток, UML определяет исходящее ребро как объектный поток. Если в этом случае также поступают управляющие маркеры, то они истекают, а истекают только объектные маркеры. Если два объекта имеют одинаковые идентификаторы, узел объединяет их в один токен. Как правило, токены заканчиваются только тогда, когда все входящие ребра предлагают один токен (операция «и»). Это происходит по принципу «первым пришел — первым ушел». Если вы назначаете узлу синхронизации спецификацию значения с помощью «joinSpec», узел ожидает токены, явно удовлетворяющие этим требованиям, прежде чем выдать токены.

1. Узлы ветвления и соединительные узлы (узлы принятия решений и узлы слияния) также имеют один и тот же символ на диаграмме деятельности. Управление потоком является одной из отличительных особенностей этих обозначений узлов. Для разветвляющегося узла требуется как минимум одно, максимум два входящих ребра. UML называет одно из них «первичным входящим ребром», а второе — «входным потоком решений». Представляют ли исходящие потоки объектные или управляющие потоки, зависит от типа первичного ребра. Задача узла — выбрать между исходящими ребрами. Узел предлагает свой входящий узел, не копируя его. Таким образом, маркер может идти только в одну сторону.

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