к какому слою относится графический элемент communication path

Matthias Noback Об Идеальной Архитектуре — Слои, Порты и Адаптеры(Часть 2 — Слои)

В 2017 году Matthias Noback (автор A year with Symfony) опубликовал цикл из трех статей, в котором описал свои взгляды на идеальную архитектру корпоративных приложений, сформировавшуюся за долгие годы практики.Первая часть является вводной и не представляет особого интереса(можно ознакомитсья в оригинале). Переводом второй является данная статья. Перевод третьей будет доступен в скором времени.

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

Зачем нужны слои

Вы, конечно же, пишите тесты. Грамотная спроектирвоанная система слоёв, невероятно упрощает тестирование. Различные типы тестов подходят для кода из разных слоев. Назначения каждого теста становится более очевидным. Набор тестов в целом становится более стабильным и более быстроработающим.

Однако, у нас есть паникёр из твиттера:

ООП версия спагетти кода — это код лазанья, с переизбытком слоев.

Лично я никогда не встречал код-лазанью, зато видел очень много лапшекода. Правда бывало, что я писал код, в котором допускал серьезные архитектурные ошибки, и неверно разделял приложение на слои, что приносило некоторые проблемы. В этой статье я описываю, как мне кажется, наилучший набор слоев, большая часть из которых описана в книге Vaughn Vernon «Implementing Domain-Driven Design»(ссылка ниже). Прошу заметить, что слои не имеют жесткой привязки к DDD, хотя они и дают возможность создавать чистые доменные модели, при соответсвующем желании у разработчика.

Структура директорий и неймспейсов

Внутри src/ у меня есть директории для каждого контекста(Bounded Context), например который я выделяю в своем приложении. Каждая из них также служит корневым неймспейсом для принадлежащих ей классов.

Внутри каждого контекста я создаю директории для каждого из слоёв:

Кратко опишу каждый из них.

Слой 1 — Домен(модель/ядро)

Доменный слой содержит классы для известных DDD типов/паттернов:

Внутри папки Domain я создаю подпапку Model, внутри неё — директории для каждого из агрегата(Aggregate root). Папка с агрегатом содержит все связанные с ним штуки(объекты-значения, доменные события, интерфейсы репозиториев и т.д)

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

Слой 2 — (обёртка для домена): Прикладной слой

Прикладной слой(Application Layer) содержит классы команд и их обработчиков. Команда представляет собой указание на что-то, что должно быть выполненно.Это обычный DTO(Data Transfer Object), содержащий только примитивные значения. Всегда должен быть обработчик команды, который знает, как нужно выполнить конкретную команду. Обычно обработчик команды (также его называют application service) ответственен за все необходимые взаимодействия — использует данные из команды для создания(или извлечения из базы) агрегата, выполняет над ним какие то операции, может сохранить агрегат после этого.

Код этого слоя также можно покрыть юнит тестами, однако на этом этапе можно начинать писать и приёмочные. Вот хорошая статья на эту тему Modelling by Example от Константина Кудряшова.

Слой 3(обертка для прикладного) — Инфраструктура

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

Инфраструктурный слой содержит код, необходимый для взаимодействия приложения с реальным миром — пользователями и внешними сервисами. Например, слой может содержать код для:

Код этого слоя надо покрывать интеграционными тестами(в терминологии Freeman and Pryce). Здесь вы тестируете всё по настоящему — настоящая база, настоящий вендорский код, настоящие внешние сервисы. Это возволяет убедиться в работоспособности тех вещей, которые не находятся под вашим контролем но используюся в вашем приложении.

Фреймворки и библиотеки

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

Правило зависимостей

Правило зависимостей(сформулированное Robert C. Martin в The Clean Architecture) утвержадет, что на каждом слое приложения вы должны зависеть только от кода текущего или более глубокого слоя. Это значит, что код домена зависит только от себя, код слоя приложения от своего кода или домена, а код инфраструктурного слоя может зависеть от всего. Следуя этому правилу, нельзя сделать в доменном слое зависимость на код из инфрастуруктурного.

Но слепо следовать какому-либо правилу, непонимая в чем его истинный смысл — это довольно глупая затея. Так почему же вы должны использовать правило зависимостей? Следуя этому правилу вы гарантируете, что чистый код слоёв прикладного и доменного слоев не будет завязан на «грязный», нестабильный и непредсказуемый код инфраструктуры. Также, применяя правило зависимостей, вы можете заменить что угодно в инфраструктурном слое не прикасаясь и не изменяя код более губоких слоёв, что даёт нам богатые возможности для ротации и переносимости компонентов.

Этот способ уменьшения связанности модулей известен давно, как Dependency Inversion Principle — буква «D» в SOLID сформулированном Робертом Мартиным: «Код должен зависеть от абстракций, не от реализаций». Практическая реализация в большинстве ооп языков заключается в выделинии публичного интерфейса для всех вещей, от которых вы можете зависеть(интерфейс и будет абстракцией) и создании класса, реализующего этот интерфейс. Этот класс будет содержать детали, не имеющие значения для интерфейса, следовательно этот класс и будет реализацией, о которой говориться в inversion principle.

Архитектура: отсрочка технологических решений

Применяя предложенный набор слоёв вместе с правилом зависимостей, можно получить много плюшек при разработке:

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

Заключение

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

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

Осталось более подробно рассмотреть инфраструктурный слой. Так мы плавно перейдем к теме гексагональной архитектуры(порты и адаптеры). Но всё это, в следующей части.

Дальнейшее чтение

Также можно ознакомиться с Deptrac — инструмент, помогающий соблюдать правила использования слоев и зависиомостей.

Источник

Элементы графической нотации диаграммы компонентов

Диаграмма компонентов и особенности ее построения

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

Физическая система ( physical system ) — реально существующий прототип модели системы.

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

Компоненты

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

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

Модуль (module) — часть программной системы, требующая памяти для своего хранения и процессора для исполнения.

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

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

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

Для более наглядного изображения компонентов были предложены и стали общепринятыми следующие графические стереотипы:

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

Источник

Элементы нотации BPMN

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

Существуют пять основных категорий элементов:

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

Данные на диаграмме могут быть представлены любыми из следующих четырех элементов:

Выделяют четыре вида соединяющих Элементов потока, связывающихся друг с другом и с другими элементами:

Существуют два способа группировки основных элементов моделирования с помощью Зон ответственности:

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

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

7.2.1. Основные графические элементы моделирования

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

Событие – это то, что происходит в течение бизнес-процесса или его Xореографии. Событие оказывает влияние на ход бизнес-процесса и чаще всего имеет причину (триггер) или воздействие (результат). Изображается в виде круга со свободным центром, предназначенным для дифференцировки внутренними маркерами различных триггеров или их результатов. Согласно влиянию Событий на ход бизнес-процесса, выделяют три типа: Стартовое событие (Start), Промежуточное событие (Intermediate) и Конечное событие (End).

Действие – общий термин, обозначающий работу, выполняемую исполнителем в ходе бизнес-процесса. Действия могут быть либо элементарными, либо неэлементарными (составными). Выделяют следующие виды действий, являющихся частью модели Процесса: Подпроцесс (Sub-Process) и Задача (Task). И Задача, и Подпроцесс изображаются в виде прямоугольников с закругленными углами. Все Действия могут являться элементами как стандартных Процессов, так и Хореографий.

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

Поток операций (Sequence Flow)

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

Поток сообщений (Message Flow)

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

Ассоциация служит для установления связи между информацией или Артефактами (объектами, не относящимися к Элементам потока) и элементами потока. Текстовые объекты, а также графические объекты, не относящиеся к элементам потока, могут соотноситься с элементами потока. При необходимости Ассоциация может указывать направление потока (например, потока данных).

Пул представляет собой Участника Взаимодействия.

Пул также может выступать в качестве Зоны ответственности или графического контейнера, отвечающего за разделение определенного набора действий, относящихся к другим Пулам, что обычно встречается в ситуациях типа «бизнес для бизнеса» (B2B). Внутри Пула МОЖЕТ находиться дополнительная информация по выполняемому Процессу. В случае, если такой информации в Пуле не содержится, то он МОЖЕТ представлять собой «черный ящик».

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

Объект данных (Data Object)

Объект данных предоставляет информацию о том, какие действия необходимо выполнить и/или каков результат этих действий. Может изображаться как в единственном экземпляре, так и в нескольких. Входные и Выходные данные Объекта данных представляют собой одну и ту же информацию о Процессе.

Сообщение используется для отображения сущности взаимодействия между двумя Участниками бизнес-процесса (Участники определяются командами business PartnerRole или business PartnerEntity).

(блок, содержащий группу объектов одной категории)

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

(связана с Ассоциацией)

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

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

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

Событие – это то, что происходит в течение бизнес-процесса или его Xореографии. Событие оказывает влияние на ход бизнес-процесса и чаще всего имеет причину (триггер) или воздействие (результат). Изображается в виде круга со свободным центром, предназначенным для дифференцировки внутренними маркерами различных триггеров или их результатов. Согласно влиянию Событий на ход бизнес-процесса, выделяют три типа: Стартовое событие (Start), Промежуточное событие (Intermediate) и Конечное событие (End).

Состав потока (Flow Dimension) (например, Стартовое событие, Промежуточное событие, Конечное событие)

Как видно из названия, Стартовое событие указывает на то, в какой точке берет начало тот или иной Процесс или Хореография(Choreography).

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

Как видно из названия, Конечное событие указывает на то, в какой точке завершится тот или иной Процесс или Хореография.

Тип (Type Dimension)

(например, Неопределенный, Сообщение, Таймер, Ошибка, Отмена, Компенсация, Условие, Связь, Сигнал,Множественный, Завершение)

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

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

(элементарное действие) (Task)

Задача представляет собой элементарное действие, включенное в состав Процесса. Используется в случае, если Процесс не детализируется далее в данной Модели.

Задача Хореографии (Choreography Task)

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

Подпроцесс представляет собой комплексное Действие, включенное в состав Процесса. Такой вид действия считается составным, т.к. может быть разбит на составляющие (Процесс, Хореография (Choreography)) благодаря использованию поддействий (sub-Activities).

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

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

Границы Подпроцесса расширены. Внутри границ просматриваются детали. Важно отметить, что Поток операций не может пересекать границ Подпроцесса.

Скрытая Подхореография (Collapsed Sub- Choreography)

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

(Expanded Sub- Choreography)-

Границы Подхореографии расширены. Внутри границ просматриваются детали. Важно отметить, что Поток операций не может пересекать границ Подхореографии.

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

(Gateway Control Types)

Выделяют следующие типы Шлюзов:

Шлюзы каждого из типов оказывают влияние как на входящие, так и на исходящие потоки.

Поток операций служит для отображения того порядка, в котором выполняются действия Процесса или Хореографии.

Стандартный поток операций

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

Неконтролируемый поток операций

Неконтролируемый поток операций относится либо к потокам, на которые не воздействую никакие условия, либо к потокам, не проходящим через Шлюзы. Простейшими примерами

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

Условный поток операций

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

Поток операций по умолчанию

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

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

Читайте также: что такое тянуть пену

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

Участников Процесса (e.g., PartnerEntities and/or PartnerRoles).

Компенсирующая ассоциация происходит за рамками Стандартного потока операций. Основой такого рода Ассоциации служит Промежуточное

событие «Компенсация», инициируемое ошибкой, совершенной в ходе транзакции, либо инициирующим триггер Событием Компенсация. Целью Компенсирующей ассоциации ДОЛЖНО являться компенсирующее действие.

Однако Объект данных предоставляет информацию о том, какие действия необходимо выполнить и/или каков результат этих действий. Может изображаться как в единственном экземпляре, так и в нескольких. Входные и Выходные данные Объекта данных представляют собой одну и ту же информацию о Процессе.

Термин «раздвоение» служит в BPMN для обозначения разделения на два или более параллельных маршрутов (данное явление также называется «И-Разделение»). Раздвоение происходит в том случае, если предпочтение отдается параллельному выполнению действий, нежели последовательному.

Существуют два типа Раздвоения:

Термин «соединение» используется в BPMN для обозначения слияния двух или более параллельных маршрутов в один (данное явление также называется И-Соединение или синхронизация).

Параллельный Шлюз предназначается для объединения множественных потоков.

Условие, Точка ветвления

(Decision, Branching Point)

Условиями являются Шлюзы, находящиеся в рамках Процесса или Хореографии, где контрольный поток движется по одному или нескольким альтернативным маршрутам.

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

Шлюз, основанный на Событиях

Данный вид Шлюзов представляет собой Точку ветвления, в которой выбор маршрута основывается на Событии, происходящем в данной точке в ходе Процесса или Хореографии. Отдельно взятое Событие, обычно являющееся получением Сообщения, определяет выбор необходимого маршрута. Также могут использоваться другие типы Событий, например, Событие «Таймер». В данном случае может быть выбран лишь один из предложенных маршрутов. Существуют два пути получения сообщения: через Задачи типа «Получение» (см. фигуру справа вверху) и Промежуточные события «Сообщение» (см. фигуру справа ниже).

Данный вид Шлюзов представляет собой

Точку ветвления, в которой выбор маршрута основывается на условных выражениях, хранимых в Исходящем потоке операций. В некотором смысле, данный вид Шлюзов является группировкой связанных между собой независимых Бинарных Шлюзов (Да/Нет). Т.к. любой из маршрутов является независимым, то МОГУТ использоваться любые сочетания маршрутов (от нуля до максимального количества комбинаций маршрутов). Однако при построении диаграмм необходимо учитывать то, что должен быть выбран хотя бы один маршрут. Для проверки того, что выбран по меньшей мере один маршрут, может быть использовано Условие по умолчанию.

Существую два вида данного типа Шлюзов.

Термин «слияние» используется в BPMN для обозначения исключающего объединения двух или более маршрутов в один (данное явление также называется ИЛИ-Соединение). Эксклюзивный шлюз «Слияние» предназначается для отображения слияния множества потоков. В случае, если все Входящие потоки операций являются альтернативными, то необходимость в Шлюзе отпадает. Это означает, что такое же влияние на ход Процесса оказывает и Неконтролируемый поток операций (см. фигуру справа ниже).

В BPMN существуют два механизма, обеспечивающих цикличность внутри Процесса.

Атрибуты Задач и Подпроцессов указывают на то, будут ли они повторяться или будут выполнены единожды. Существуют два вида циклов: Стандартный и Многоэкземплярный. Графически цикличность отображается в виде небольшого маркера в центре нижней части фигуры.

Цикличность Потока операций

(Sequence Flow Looping)

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

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

Перерыв в Процессе

(что-то, способное приостановить Процесс и не подающееся управлению)

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

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

Process (Inline Block))

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

На диаграмме данный вид Подпроцесса не имеет никаких особых маркеров

(блок, содержащий группу объектов одной категории)

«Связь». Предназначен в основном для печати.

(связана с Ассоциацией)

Пул представляет собой Участника Взаимодействия. Пул также может выступать в качестве Зоны ответственности или графического контейнера, отвечающего за разделение определенного набора действий, относящихся к другим Пулам, что обычно встречается в ситуациях типа «бизнес для бизнеса» (B2B). Внутри Пула МОЖЕТ находиться дополнительная информация по выполняемому Процессу. В случае, если такой информации в Пуле не содержится, то он МОЖЕТ представлять собой «черный ящик».

Источник