Подпроцесс это: Декомпозиция или подпроцесс? | Trinion

Содержание

Декомпозиция или подпроцесс? | Trinion

Нередко даже в профессиональной среде путают два понятия — декомпозиция и подпроцесс. На самом деле, это далеко не одно и то же. И важно понимать разницу между этими двумя терминами.

Декомпозиция

Декомпозиция — это разложение задачи на более простые элементы. Может использоваться как в функциональном, так и в процессном моделировании.

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

Пример декомпозиции сущности А:

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

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

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

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

Подпроцесс

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

Подпроцесс А внутри процесса:

Основное отличие состоит в том, что декомпозиция допускает больше свобод, здесь вы можете совмещать различные подходы к изучению бизнеса. А подпроцесс — неотъемлемая часть BPMN нотации. В нем жестко заданы все точки входа, выхода, исполнители, инструменты еще на уровне процесса. И вы не можете выйти за эти рамки.

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

Вложенный бизнес-процесс (подпроцесс) | Глоссарий ПитерСофт

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

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

Разработка моделей бизнес-процессов с использованием подпроцессов основана на применении декомпозиции — метода, позволяющего заменить решение одной большой задачи решением серии небольших подзадач. Использование декомпозиции оправдано в тех случаях, когда создаваемая модель бизнес-процесса получается слишком сложной и громоздкой, либо когда бизнес-процесс содержит некоторую последовательность действий, которая в дальнейшем может повторяться в других бизнес-процессах — в этом случае удобно объединить повторяющуюся последовательность задач в подпроцесс.

Декомпозиция бизнес-процесса может быть осуществлена несколькими способами. Наиболее часто применяемые стратегии декомпозиции:

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

В программном продукте «ПитерСофт: Управление процессами» на входе и выходе вложенного бизнес-процесса можно настроить передачу параметров из родительского и в родительский процесс соответственно.

подпроцесс — это… Что такое подпроцесс?

  • подпроцесс — — [Л.Г.Суменко. Англо русский словарь по информационным технологиям. М.: ГП ЦНИИС, 2003.] Тематики информационные технологии в целом EN subrun …   Справочник технического переводчика

  • КВАРК-ГЛЮОННЫЙ ПОДПРОЦЕСС — в квантовой хромодинамике процесс взаимодействия кварков и глюонов на малых расстояниях, определяющий сечение жёстких процессов с участием адронов. Напр., в процессе рождения в адрон адронном соударении пары мюонов с большой относит. энергией К.… …   Физическая энциклопедия

  • BPMN — (англ. Business Process Model and Notation, нотация и модель бизнес процессов)   система условных обозначений (нотация) для моделирования бизнес процессов. Разработана Business Process Management Initiative (BPMI) и поддерживается… …   Википедия

  • ГЛЮОНЫ — (от англ. glue клей), гипотетич. электрически нейтр. ч цы, со спином 1 и нулевой массой покоя, являющиеся переносчиками сильного вз ствия между кварками. В совр. теории сильного вз ствия квантовой хромодинамике предполагается существование восьми …   Физическая энциклопедия

  • ПАРТОНЫ — (от лат. pars, род. падеж partis часть), составляющие адронов, проявляющиеся в процессах с большой передачей четырёхмерного импульса, в частности в глубоко неупругих процессах. В модели П. считается, что адрон участвует в реакциях лишь нек рой… …   Физическая энциклопедия

  • Бизнес-моделирование — (деловое моделирование)   деятельность по формированию моделей организаций, включающая описание деловых объектов (подразделений, должностей, ресурсов, ролей, процессов, операций, информационных систем, носителей информации и т. д.) …   Википедия

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

  • Моделирование бизнес-процессов — Бизнес моделирование деятельность по выявлению и описанию существующих бизнес процессов (анализ бизнес процессов), а также проектированию новых (проектирование бизнес процессов). Бизнес моделированием также называют дисциплину и отдельный… …   Википедия

  • Моделирование бизнеса — Бизнес моделирование деятельность по выявлению и описанию существующих бизнес процессов (анализ бизнес процессов), а также проектированию новых (проектирование бизнес процессов). Бизнес моделированием также называют дисциплину и отдельный… …   Википедия

  • ИНТЕГРАЦИЯ — (Integration) процесс, с помощью которого части соединяются в целое; на личностном уровне состояние организма, когда все составляющие элементы индивида, его черты или качества действуют согласованно как единое целое.Юнг использовал этот термин… …   Словарь по аналитической психологии

  • управление мощностями бизнеса — (ITIL Continual Service Improvement) (ITIL Service Design) В контексте ITSM, управление мощностями бизнеса – это подпроцесс управления мощностями, отвечающий за понимание будущих потребностей бизнеса для использования в плане мощностей. См …   Справочник технического переводчика

  • Моделируем подпроцессы в BPMN — Главное не результат, главное процесс

    Если вы взялись за достаточно сложный бизнес-процесс, то скорее рано, чем поздно вы столкнетесь с тем, что схема процесса разрослась и стала нечитаемой. Это значит, что пришла пора выполнить иерархическую декомпозицию — проще говоря, разбить процесс на подпроцессы. На BPMN распространяется старое правило: на одном уровне декомпозиции желательно иметь от 5 до 9 активностей.

    Рассмотрим в качестве примера процесс заключения договора, состоящий из трех фаз:

    1. согласование содержательных условий договора
    2. согласование текста договора
    3. подписание договора

    Зачастую приходится встречать наивные процессные диаграммы типа следующей:

    Рис.1 Наивная диаграмма

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

    Рис.2 Диаграмма с проверкой промежуточных результатов

    Уместен вопрос: зачем делать проверку после последнего подпроцесса, если процесс так и так завершается. Ответ: затем, что это разные завершения — успешное и неуспешное. Нам полезно видеть это на схеме, а если схема исполняемая, то мы сможем получить статистику по проценту успешных и неуспешных завершений.

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

    Рис.3 Диаграмма с вехами

    Кстати, мы только что ответили на часто задаваемый вопрос “как в BPMN моделируются вехи?”. Ответ: “пустыми” промежуточными событиями, как показано на рис.3.

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

    Рис.4 Двойная проверка

    Как видим, проверка “текст согласован” производится дважды. Люди с программистким складом ума такие вещи не любят, справедливо указывая, что тут имеет место дублирование.

    Как избавиться от дублирования проверки? Сделать из подпроцесса два выхода, как на следующей диаграмме, нельзя. Это грубая ошибка: потоки управления в BPMN не имеют права пересекать границы подпроцесса.

    Рис.5 Некорректная диаграмма: поток управления пересекает границу подпроцесса

    Корректный способ — трактовать один из выходов подпроцесса как основной/желаемый, а остальные — как бизнес-исключения. Для рассматриваемого примера это может выглядеть так:

    Рис.6 Выход из подпроцесса через эскалацию

    Если текст не согласован, подпроцесс инициирует событие типа “эскалация” (escalation), и управление передается на прикрепленный обработчик (attached event).

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

    Рис.7 Эскалации и вехи

    Но помним, что эскалации появились только в BPMN 2.0, поэтому если вы ограничены рамками BPMN 1.x, пользуйтесь вместо них событиями “ошибка” (error):

    Рис.8 BPMN 1.x: событие “ошибка” вместо эскалации

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

    Рис.9 Компактная версия без вех

    Резюме:

    1. Для моделирования подпроцессов используйте паттерны, изображенные на рис.2 или 9; какой именно использовать — дело вкуса.
    2. Диаграммы на рис.3 и 8 — модификации, в которые добавлены промежуточные события, моделирующие вехи процесса.
    3. Если ваш инструментарий поддерживает BPMN 2.0, то вместо ошибок в диаграммах на рис.8 и 9 используйте эскалации, как показано на рис.7.

    Подпроцесс

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

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

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

    Настройки подпроцесса

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

    Вкладка «Параметры»

    На вкладке Параметры отображаются основные параметры элемента:

    • Наименование — название элемента на графической модели процесса. При добавлении подпроцесса его название задается по шаблону. В этом поле название можно изменить;
    • Процесс — выбор процесса, который будет вызываться в рамках родительского. Вы можете добавить процесс, который отображается на вкладке Персональные (в расширенном режиме работы) или на вкладке Локальные.

    Обмен данными с родительским процессом строится через входящие и исходящие контекстные переменные. Подробнее о них можно прочитать в статье «Контекст процесса».

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

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

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

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

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

    Вкладка «Обработчики»

    О вкладке Обработчики можно прочитать в статье «Общие принципы настройки активити».

    Была ли статья полезной?

    Нашли опечатку? Выделите текст, нажмите ctrl + enter и оповестите нас

    BPMN: (часть 4-подпроцесс) — Русские Блоги

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

    В млрд,Дочерний процессМожет иметь расширенное или свернутое представление. В расширенном подпроцессе вся его подробная информация отображается в его пределах.

    Рисунок 7. Расширенный подпроцесс

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

    Рисунок 8 Графическое представление складывающихся подпроцессов

    В блок-схеме, подОбработатьОбычно используется в следующих двух ситуациях:

    1. Разложить (разложить) диаграмму и сделать ее более читаемой;
    2. Опишите повторяющиеся действия.

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

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

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

    Рисунок 9 Подбор персонала высшего бизнес-процесса

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

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

    Процесс найма сотрудников подразделяется на следующие три процесса:

    1. Найти новых сотрудников.
    2. Полная документация.
    3. обучить нового сотрудника.

    ПосмотримПо подпроцессамКаждый вид деятельности представлен.

    Рисунок 10. Подпроцесс «Поиск новых сотрудников»

    Рисунок 11. Подпроцесс «Полная обработка документов»

    Рисунок 12. Подпроцесс «Обучение новых сотрудников»

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

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

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

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

    Посмотрите на пример ниже, «Уведомление клиента» можно использовать повторноподпроцессИспользуется в контексте двух основных процессов: «Выпуск нового продукта» и «Открытие филиала».

    Рисунок 15 Повторно используемый подпроцесс

    Если в процесс необходимо добавить новый информационный канал или рекламный инструмент, он будет добавлен только в «Уведомление клиента».подпроцессДиаграмма. Эти два основных процесса не изменены.

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

    Вот некоторые менее распространенныеТип подпроцесса:

    • Подпроцесс события
    • сделка
    • Специальная подпрограмма

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

    Рисунок 16 Подпроцесс события (свернут)

    БизнесЯвляетсяДочерний процессЕго поведение контролируется протоколом транзакций.транзакционныйГрафическое представление представляет собой скругленный прямоугольник с двойной линией, отмечающей его границу.

    Рисунок 17. Подпроцесс транзакции (свернут)

    Специальный дочерний процессЭто группа действий, которые не имеют требуемого отношения последовательности и могут происходить в любом порядке. Порядок и количество исполнительских действий определяются исполнителем.
    ad-ac дочерний процессГрафических элементов вДочерний процессНижний центр прямоугольной формы содержит метку, которая имеет наклон (~).

    Рисунок 18 Специальная подпрограмма

    Ты можешьспецификация bpmnЧитайте о различныхподпроцессБольше информации о типах и их применениях в моделировании бизнес-процессов.


    Учись на примере

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

    Используйте это в качестве отправной точки для построения диаграммы BPMN. Просто нажмите «Используйте этот шаблон”Для редактирования или нажмите «Создать бланк”Начните рисовать с нуля.


    BPMN инструмент

    Имеет мощныйРазработка бизнес-процессов программного обеспечения Visual Paradigm BPMN — Используйте профессиональные инструменты BPMN для передачи идей бизнес-процессов.


    Справочник по моделированию BPMN — все символы BPMN 2.0 объяснены

    Бесплатный BPMN инструмент

    Cawemo — это бесплатный онлайн-инструмент для разработки, обсуждения и обмена диаграммами BPMN с вашей командой.

    Бесплатный BPMN инструмент Автоматизация: Если вам интересно, какие элементы могут быть автоматизированы с помощью механизма Workflow Camunda BPMN, проверьте документацию BPMN 2.0 Camunda.

    Артифакты

    Текстанотации

    Данные

    Объектс данными Хранилищеданных

    Событие

    Тип Стартовые Промежуточные Конечные
    Обычные Событие подпроцесса Событие подпроцесса
    независимые
    Пойманые Граница Граница
    независимые
    Переброска
    Нет
    Сообщение Достпно в версии 2.1.0 Достпно в версии 2.1.0 Достпно в версии 2.1.0 Достпно в версии 2.1.0 Достпно в версии 2.1.0
    Таймер Достпно в версии 2.1.0 Достпно в версии 2.1.0 Достпно в версии 2.1.0
    Условное Достпно в версии 2.1.0 Достпно в версии 2.1.0 Достпно в версии 2.1.0
    Link Достпно в версии 2.1.0 Достпно в версии 2.1.0
    Сигнал Достпно в версии 2.1.0 Достпно в версии 2.1.0 Достпно в версии 2.1.0 Достпно в версии 2.1.0 Достпно в версии 2.1.0
    Ошибка Достпно в версии 2.1.0 Достпно в версии 2.1.0
    Эскалация Достпно в версии 2.1.0 Достпно в версии 2.1.0 Достпно в версии 2.1.0 Достпно в версии 2.1.0
    Уничтожение

    Достпно в версии 2.1.0

    Компенсирующие Достпно в версии 2.1.0 Достпно в версии 2.1.0 Достпно в версии 2.1.0
    Отмена Достпно в версии 2.1.0 Достпно в версии 2.1.0
    Мульти Достпно в версии 2.1.0 Достпно в версии 2.1.0 Достпно в версии 2.1.0 Достпно в версии 2.1.0 Достпно в версии 2.1.0
    Мульти параллельные Достпно в версии 2.1.0 Достпно в версии 2.1.0 Достпно в версии 2.1.0

    Мы уже описали, как использовать полосы для назначения ответственности за задачи или подпроцессы для разных менеджеров задач. Лейны всегда существуют в пуле, а границы полосы представляют собой границы процесса от начала до конца. Для BPMN пул представляет собой более высокий экземпляр по сравнению с его полосами. Пул предполагает управление процессом — другими словами, он назначает задачи. Он ведет себя как дирижер оркестра, и поэтому этот тип процесса называется «оркестровкой».»

    На приведенной ниже диаграмме «проводник» устраивает Фалко для обработки задачи 2, как только Роберт завершает задачу 1. Проводник имеет контроль над процессом на самом высоком уровне, и каждый инструмент в оркестре воспроизводит мелодию, которую дирижер решает:

    технологический проводникРобертЗапускзадание 1Стефанзадание 4Кристианзадание 3Фалкозадание 2

    Считаете ли вы, что это нереально? У многих опытных моделеров процесса есть проблемы с этим способом мышления. Они предпочли бы моделировать последовательность процессов, как показано ниже, исходя из предположения, что в их компании нет всемогущего проводника и что отдельные участники процесса должны сами координировать и сотрудничать:

    Робертзапускаетзадание 1переходя кФалкоСтефанзадание 4Кристианзадание 3переходит кСтефануФалкозадание 2переходит кКристиану

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

    Стефанзадание 4ЗапускаетКристианзадание 3переходит кСтефануСтартФалкозадание 2переходит кКристиануСтартРобертСтартзадача 1переходит кФалко

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

    Вы слышали об организации оркестровки в связи с сервис-ориентированной архитектурой (SOA)? Это почти точно задача механизма процесса, за исключением того, что эти сервисы являются не только полностью автоматизированными веб-службами; они также могут быть задачами, выполняемыми участниками процесса в соответствии с технологическим процессом. Что это значит, однако, для чисто функционального моделирования процессов, в котором вы также описываете процессы not , управляемые таким механизмом процесса? На этот вопрос нет общего ответа.

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

    Мы покажем полезность этого нового мышления на примере. Следует помнить, что если вы будете стремиться гармонизировать свои функциональные и технические модели процессов для достижения лучшего соответствия бизнеса и ИТ, вы неизбежно столкнетесь с этим типом процесса моделирования, используете ли вы BPMN или нет.

    Бассейны: искусство сотрудничества

    Мы уже рассмотрели процесс, представленный ниже в связи с шлюзом на основе событий:

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

    ДоставкапиццыПицерия—ПоварКурьерПоставить пиццуВзять деньгиКонец

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

    Заказ пиццыПокупательЧувствоголодавыбрать пиццуЗаказать пиццуПиццадоставленаСъесть пиццуПозвонитьв пиццерию60 минутПицца доставленаПиццерияПоварПриготовить пиццукурьерДоставить пиццуВзятьденьги

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

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

    ПокупательпиццыКурьерДоставить пиццуВзятьденьгиКонецПоварПриготовить пиццуПицца доставленаСделатьзаказЧувствоголодавыбрать пиццуЗаказать пиццуСъесть пиццуГолодуталенпицца доставлена60 минутПицца доставленаПозвонить впиццерию

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

    ПиццерияКурьерДоставить пиццуКонецВзятьденьгиПоварПриготовить пиццуЗаказполученЗаказчикпиццыЧувствоголодавыбрать пиццуЗаказать пиццуСъесть пиццуГолодуталенПицца доставлена60 минутПозвонить впиццериюОплатить

    Объединение пулов

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

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

    Как клиенты, мы мало интересуемся внутренним процессом поставщика. Возможно, он печет, а затем доставляет пиццу; возможно, когда у него нет предметов снабжения, он получает еще одну услугу пиццы, чтобы испечь пиццу и доставить ее. Это его проблема — мы просто ожидаем получить нашу пиццу. При моделировании таких случаев мы можем скрыть процесс доставки и свернуть пул:

    ЗаказпиццыЧувствоголодавыбрать пиццузаказать пиццуСъесть пиццуГолодуталенпиццадоставлена60 минутПозвонитьв пиццериюОплатить пиццупиццадоставленаКлиент

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

    Заказ пиццыЗаказчик пиццызапросзаказденьгидоставкаоплата

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

    Наведите указатель мыши на символы оранжевого цвета

    Сообщение с равным доступомРобертГотовит салатФалкоГотовит стейкКристианЧуствоголодаВыбрать рецепткакое блюдо?Готовить макароныПоестьГолодуталенНуженкомпонент?СалатСтейкМакороныЧто-тореальное

    Диаграмма показывает, что задачи в нашем примере были назначены конкретным людям. Мы можем получить      после описания процесса из заданий: если Кристиан голоден, он выбирает определенный рецепт.      В зависимости от того, что выбирает Кристиан, он может сам позаботиться (Готовить макароны), или он может получить его      соседи по комнате на борту. Если последний, Фалко повара Стейк и Роберт готовит Салат. В итоге Кристиан ест.      Три полосы (Кристиан, Фалко, Роберт) объединены в один пул, обозначенный «Сообщение с равным доступом».

    FAQ: Должен ли я обозначать дорожку конкретным человеком?

    В этом примере полосы соответствуют людям, но это значение не определено BPMN. Вы можете назначить            как вам нравится. На практике полосы часто используются для назначения:
    • Позиции в первичной организации, например, бухгалтерский служащий.
    • Роли во вторичной организации, например, сотрудник по защите данных.
    • Общие роли, например, клиент.
    • Отделы, например, продажи.
    • ИТ-приложения, например, CRM-система.

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

    Наведите указатель мыши на символы оранжевого цвета

    Не определеноВнешние действияПользовательДоставкаДоставка(с подтверждением)ОтправитьСкриптСервисПодпроцессы

    Маркеры задач

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

    Loop

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

    ВремяобедПредложить блюдоГотовить едуЕдапреготовлинапока всене согласятся

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

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

    Несколько экземпляров

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

    Желаниезаказать пиццувыбрать пиццузаказать пиццупиццазаказанаВсеждут

    Как вы считаете, этот пример абсурден? Как ваша компания проверяет счета-фактуры для групповых заказов, например, для офисных принадлежностей? Вы пересылаете счет-фактуру от одного сотрудника к другому, чтобы каждый      человек может подписаться на предметы, которые он заказал, прежде чем оплачивать счет? Если это так, вы живете в разделе с равным доступом, и вам срочно следует рассмотреть возможность оптимизации вашего процесса.      Автоматизация счетов-фактур по-прежнему является одним из лучших проектов BPM, и главная цель таких проектов часто является распараллеливанием.

    Компенсация

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

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

    …Путешествие по книгам…Отменить путешествие…Пригласить всехдрузей попочте…Отменитьприглашениепо телефонуручное действиякомпенсацииручная паралельнаякомпенсацияпозвонить втурфирмуотменить

    Инкапсулировать сложность

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

    BPMN предоставляет нам подпроцесс, чтобы помочь с расширением / свертыванием. Подпроцесс описывает подробную последовательность, но она не занимает больше места на диаграмме родительского процесса      чем задача. Обе задачи и подпроцессы являются частью класса действий и поэтому представлены как прямоугольники с закругленными углами. Единственное отличие — знак плюса,      указывая сохраненную подробную последовательность для подпроцесса:

    Главный процессСтартАктивноеПодпроцессКонец

    Что хорошего для нас? Это больше всего зависит от того, как ваш инструмент BPMN поддерживает следующие параметры для подключения подпроцессов с их родительскими процессами:

    • Представление в отдельной диаграмме процессов : символ подпроцесса связывается с отдельной диаграммой. Если ваш инструмент BPMN отображает модель процесса в веб-браузере,        например, нажатие на символ откроет новую страницу, чтобы отобразить подробную диаграмму.
    • Расширение диаграммы процессов родительского процесса : активность со знаком плюс называется скомпенсированным подпроцессом. Знак плюса означает, что вы можете нажать на него и сделать        подпроцесс расширяется. Спецификация BPMN предусматривает эту опцию, хотя не все ее поставщики реализуют ее. На приведенной ниже диаграмме показано, как подпроцесс был непосредственно расширен на диаграмме        родительский процесс. Инструмент, поддерживающий эту функцию, позволяет вам развернуть и свернуть подпроцесс непосредственно на диаграмме, соответственно, чтобы показать или скрыть детали.
    main processСтартКонецзадачаПодопроцессзадачаЗадача

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

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

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

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

    Прикрепление событий

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

    ЧувствоголодаВыбрать рецептГотовить едуПоестьпойти пообедГолодутален

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

    Обслуживание запросовМинимальный запасдостпиг уровняЗакупкаартикултовараудалить артикулиз категорииартикулудаленобработка заказазаказдоставленапрвоеритьдоступностьартикулесть?доставить артикулФинансовыйменеджерКонецОповеститьзаказчикаудалить артикулиз категорииКонецЗакупкаЗакупкаСтартРазместить заказДоступно?Ожидать доставку…нетдоступанетдоступанетдоступаДаНетДаНет

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

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

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

    Лучшей альтернативой, представленной в BPMN 2.0, является событие эскалации. Подпроцесс может использовать событие эскалации для прямого отчета о родительском процессе,      и сообщение не будет рассматриваться как сообщение об ошибке. Кроме того, родительский процесс может получать и обрабатывать сообщения из событий эскалации без отмены подпроцесса, поскольку      промежуточные события без прерывания могут быть присоединены:

    заказ в процессезаказдоставленапрвоеритьдоступностьартикулДоступно?доставить артикулФинансовыйменеджерКонецОповеститьзаказчикаудалить артикулиз категорииКонецЗакупкаОповеститьзаказчикаКонецнет в наличиеЗакупкаСтартРазместить заказДоступно?Ожидать доставку…нетдоступадоставказадерживаетсяlдоставка задерживаетсяДаНетin< 2дняin> 2дняНет

    Модуляция и повторное использование

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

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

    • Чтобы инкапсулировать сложность (как уже было описано)
    • Формулировать «коллективную инструкцию» на части родительского процесса путем добавления событий или размещения маркеров. Мы рассмотрим этот вариант позже.

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

    финансовое урегулированиеСтартОтправить счет……платеждоставленасрок оплатыпревышензаказ в процессепрвоеритьдоступностьзаказдоставленаартикулДоступно?доставить артикулКонецартикулЗакупкаФинансовыйотделОбслуживание запросовМинимальный запасдостиг уровняартикултовараартикулЗакупкапоправитьпоправить заказдоставленВнести исправленияКонецФинансовыйменеджерартикул ЗакупкаСтартРазместить заказ…ДаНет

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

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

    • Абонентский адрес
    • Дата поставки
    • Описание производительности
    • Сумма счета-фактуры
    • Ожидаемая дата оплаты

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


    Один маркер, доступный только для подпроцессов, называется ad-hoc. Признайте его тильдой, как показано на диаграмме ниже:

    2 дня послевылетавыключитьобогреввключитьавтоответчикОтдавить ключисоседуУпаковать багаж…

    Используйте подпроцесс ad-hoc, чтобы отметить сегмент, в котором могут выполняться содержащиеся в нем действия (задачи или подпроцессы):

    • Выполнено в любом порядке,
    • Выполнено несколько раз или
    • пропустить.

    Любая сторона, выполняющая этот подпроцесс, решает, что делать и когда это делать. Можно сказать, что «едва структурированная» природа того, что происходит внутри этого подпроцесса, уменьшает      вся идея моделирования процессов до абсурда, потому что то, что происходит, и когда мы больше всего хотим контролировать. С другой стороны, это реальность многих процессов,      и вы не можете моделировать их, не представляя их символ свободной формы. Частые примеры — это когда процесс в значительной степени зависит от неявных знаний или творчества, или когда разные сотрудники      выполните процесс по-разному. Вы можете использовать подпроцесс ad-hoc для определения того, что может быть нежелательным фактическим состоянием. Это может стать шагом на пути к более стандартизованной процедуре.

    BPMN 2.0 указывает, какие символы должны быть, а какие запрещены, в рамках подпроцесса ad-hoc. Они есть:

    • Обязательно : Мероприятия
    • Май: Объекты данных, потоки последовательностей, ассоциации, группы, потоки сообщений, шлюзы и промежуточные события
    • Запрещено : начальные и конечные события, символы для разговоров и хореографий

    С помощью спецификации могут быть смоделированы смешанные формы — так называемые слабоструктурированные процессы, как показано здесь:

    textbook shall be writtenrecruitauthorsplan contentsresearch topicswrite textcreate graphicsinclude graphics into textreleasecontributiongeneratemanuscriptmanuscriptcompleteeach author!

    BPMN 2.0 представил совершенно новую конструкцию — подпроцесс события. Мы находим подпроцесс события в рамках другого процесса или подпроцесса. Распознавайте их своими пунктирными рамками.

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

    Хорошо, это довольно абстрактно, но мы можем продемонстрировать, как подпроцесс события работает с примером:

    Пригласить друзей наобедПодготовить продуктыВключить гостяПришелновыйгостьПринятьнового гостяДостать едуcooking mealfailedorder mealВыбрать рецептГотовить едуПоесть

    Мы пригласили пару друзей на обед. Это начинает подпроцесс «подготовки пищи» к выбору рецепта, а затем готовит еду. Пока мы это делаем, телефон звонит.      Другой гость приглашает себя на обед. Спонтанно, как мы, мы просто увеличиваем количество пищи или устанавливаем другое место за столом, не прерывая приготовления пищи.      Однако, если авария происходит во время подготовки, ошибка немедленно вызывает подпроцесс прерывания события для исправления. Мы заказываем еду для доставки. Когда этот подпроцесс этого события завершается,      мы выходим из закрытого подпроцесса через регулярный выход и участвуем в еде.

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

    Пригласить друзей наобедПодготовить продуктыВыбрать рецептГотовить едуВключить гостяДостать едуПоесть

    Типы событий, которые могут инициировать прерывания и прерывания подпроцессов событий:

    Существует еще два типа для подпроцессов прерывания:


    Наведите указатель мыши на символы оранжевого цвета

    ГолодголодаВыбрать рецептНужноблюдо?Готовить макароныГотовит стейкГотовит салатПоестьМакороныСтейкСалат

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

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

    Наилучшая практика: соглашения об именах

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

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

    FAQ: Мне нужно нарисовать «X» -маркер внутри ромба? Я уже видел этот символ без маркера …

    BPMN использует два символа для шлюзов XOR:

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


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

    Наведите указатель мыши на символы оранжевого цвета

    ЧувствоголодаВыбрать рецептГотовит салатНуженблюдо?Готовить макароныГотовит стейкПоесть20 минут10 минут10 минут3 минут15 минутМакороныСтейк

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

    Тем не менее, это означает, что вы ожидаете 23 или даже 28 минут, пока не сможете начать есть. Невыносимый! Вы действительно голодны, но что вы можете сделать?      Может быть, вы сначала не готовите Салат, а затем готовите Макороны или Стейк, но вы работаете одновременно и параллельно — параллельно.      Соответствующим символом является параллельный шлюз или «И шлюз» для краткости, как показано здесь:

    Наведите указатель мыши на символы оранжевого цвета

    ЧуствоголодаВыбрать рецепткакое блюдо?Готовить макароныГотовит стейкГотовит салатПоестьГолодутален10 минут10 минут20 минут3 минут15 минутМакороныСтейк

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

    Проверьте себя: что, если мы проведем тот же процесс, но оставим И сливаться из-за нехватки места,          и путь от задачи «Готовит салат» ведет непосредственно к слиянию XOR. Что произойдет, если мы создадим процесс, и решаем в пользу Макороны?

    Маркер генерируется и затем клонируется, как всегда, в разделение И. Как только мы закончим подготовку Салата, токен проходит через слияние XOR и выполняет «Поесть». Пять минут спустя, «Готовить макароны» также завершается. Его токен проходит через слияние XOR, и «Поесть» выполняется снова! Это не то поведение, которое мы хотели. ЧувствоголодаВыбрать рецепткакое блюдо?Готовить макароныГотовит стейкГотовит салатПоестьГолодутален10 минут10 минут20 минут3 минут15 минутМакороныСтейк

    Мы хотим сделать наш процесс еще более гибким: когда мы голодны, мы хотим есть

    • Только салат,
    • Салат и «что-то реальное», как Макороны или Стейк, или
    • Только что-то реальное.

    Если вы хотите более компактное представление, вы можете использовать шлюз с включенным доступом на основе данных — шлюз OR для краткости:

    Наведите указатель мыши на символы оранжевого цвета

    ЧувствоголодаВыбрать рецептНуженкомпонент?Готовит салатГотовить макароныКакое блюдо?Готовит стейкПоестьГолодутален20 минут3 минут15 минут10 минут10 минутСалатСтейкМакоронычто-то реальное

    Осторожно! На практике обработка ИЛИ шлюзов не так проста, как предполагают эти примеры. Легко понять, что прогресс зависит от ожидания того, что другой токен достигнет слияния OR.      Труднее будет отслеживать правила синхронизации со сложными диаграммами, которые разрастаются на нескольких страницах.


    Мы узнали об эксклюзивной опции шлюза на основе данных (XOR) в качестве способа использования разных путей в отношении обрабатываемых данных.      Пользователи других описаний процессов распознают этот тип ветвления, но BPMN дает нам другой способ проектирования путей процесса:      шлюз событий — шлюз событий, для краткости. Этот шлюз не маршрутизируется на основе данных, а скорее каким событием имеет место следующее. Чтобы понять      пользуйтесь рассмотрением процесса, показанного ниже: Мы заказываем пиццу и ждем его доставки. Мы можем есть только после того, как получим пицца, но что, если пицца не прибудет после 60 минут?      Мы сделаем тревожный телефонный звонок, вот что! Мы можем моделировать это с помощью шлюза событий:

    Наведите указатель мыши на символы оранжевого цвета

    Чувствоголодавыбрать пиццузадакать пиццупицца доставленаСъесть пиццупицца доставленаПозвонить впиццерию60 минутГолодутален

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

    …Сообщение…Время…Состояние…Сигнал…Мульти…Получить задачу…

    Задачи и шлюзы — два из трех элементов потока, которые мы узнали до сих пор: Вещи (задачи) должны выполняться при определенных обстоятельствах (шлюзах). Какой элемент потока все еще отсутствует?      Вещи (события), которые должны произойти. События не менее важны для моделей процессов BPMN, чем задачи или шлюзы. Мы должны начать с некоторых основных принципов их применения.      Мы уже видели события Start, промежуточные события и конечные события. Эти три типа событий также захватывают и / или бросают события:

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

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

    События броска предполагаются BPMN для запуска самих себя, а не для реагирования на триггер. Можно сказать, что они активны по сравнению с пассивными событиями ловли.      Мы называем их короткими событиями, потому что процесс запускает их. Событие броска может быть:

    • Запущено во время процесса
    • Запущено в конце процесса

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

    Наведите указатель мыши на символы оранжевого цвета

    …Задача 1Задача 2…Задача 3…Событие 1

    Токен, проходящий через процесс, будет вести себя следующим образом:

    • Токен переходит к задаче 1, которая начинается соответственно.
    • Если событие 1 происходит во время обработки задачи 1, задача 1 немедленно отменяется, и токен перемещается через поток исключений в задачу 3.
    • С другой стороны, если событие 1 не встречается, задача 1 будет обработана, и токен перемещается по регулярному потоку последовательности к задаче 2.
    • Если событие 1 происходит только после завершения задачи 1, оно будет проигнорировано.

    Через версию BPMN 1.2, за исключением событий компенсации, присоединенные промежуточные события неизбежно приводили к отмененным действиям. BPMN 2.0 определяет новый символ:      промежуточное событие без прерывания. Это звучит неловко, но полезно:

    Наведите указатель мыши на символы оранжевого цвета

    …Задача 1Задача 2…Задача 3…Событие 1

    Токен проходит через процесс следующим образом:

    • Токен переходит к задаче 1, которая начинается соответственно.
    • Если событие 1 происходит во время обработки задачи 1, токен клонируется. Задача 1 продолжает обрабатываться, пока второй токен переходит к задаче 3, которая теперь также обрабатывается.        Эта процедура может выполняться неоднократно, то есть событие может происходить много раз. Каждое появление приводит к другому клонированному токену.
    • Если событие 1 имеет значение нет , задача 1 будет завершена, и токен перемещается по регулярному потоку последовательности к задаче 2.
    • Если событие 1 происходит только после завершения задачи 1, это перестает иметь значение.

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


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

    Hover over orange symbols for explanation

    Чувствоголодавыбрать пиццузаказать пиццупиццадоставленаСъесть пиццуГолодутален

    FAQ: Могу ли я заменить задачу «заказать пиццу» событием метания сообщений?

    Да, вы могли бы:

    Чувствоголодавыбрать пиццупиццазаказанапиццадоставленаСъесть пиццуГолодутален

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

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

    Сообщение:»сайтлежит!»искать багиисправить багпользовательудовлетворен?негативuser insultedСпасибоБлагодарностьСообщение:»извените, ложнаятревога!»ДаНет

    Событие таймера часто используется при работе с BPMN, поскольку оно настолько гибко применимо. Значок часов представляет событие таймера. На приведенной ниже диаграмме показаны несколько примеров приложений:

    Праздники2 месяцапутешествийВыбратьместопутешествоватьсобрать багаж…2 дняпутешествийобратится в тех.поддержкукаждые 2часапроверить почтупосмотретьважный топиктольковажный топик…перерыв10 минутworking dayПонедельник-Пятницав 07 утравстатьзайти втуалетехать на автобусе на работу…08 утраВалентин 201002/14/201008 утраВстатькупить букетПодаритьбукет…02/14/201009 утра

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

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

    Наведите указатель мыши на символы оранжевого цвета

    Чувствоголодавыбрать пиццузаказать пиццупиццадоставленаПоестьГотовить макароны30 минутГолодутален

    Непрерывные события таймера стали возможны с BPMN 2.0:

    Наведите указатель мыши на символы оранжевого цвета

    ЧувствоголодаВыбрать рецептГотовить едуset tableПоестьГолодутален10 минут периоддля завершения

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

    Спецификация BPMN не указывает, какая может быть ошибка. Как модельер, вы должны это решить.

    Ошибка является серьезным событием в BPMN, поэтому, если ловить, ее можно смоделировать только как присоединенное промежуточное событие. Это означает, что ошибка при выполнении задачи должна обрабатываться определенным образом:      В качестве события бросания он может быть смоделирован только в конце пути процесса, так что участник знает, что процесс завершился неудачей. Родительский процесс должен также признать отказ.

    Вы можете найти пример событий ошибки, например. в Раздел «Реализация» подпроцессов событий».


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

    Мы можем улучшить наш пицца процесс с условиями. Если мы хотим заморозить пицца, процесс начинается, как показано на диаграмме ниже. Берем пицца из морозильника и включаем духовку.      Но только после того, как температура в духовке достигает 180 ° C, мы помещаем пицца, и только после того, как это делается, мы вынимаем его, чтобы поесть.

    Замороженная пиццаНуженВзять пиццуиз холодильникаВключить печьдо 180°Положить пиццу в печьпиццаготоваСъесть пиццуГолодутален

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

    Реклама пиццы на ТВкупить пиццуОпетит разыгралсяСъесть пиццунаписать отзывна pizzatest.de

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


    Давайте посмотрим на абстрактный пример ниже. Мы уже обсуждали (простой) анализ ключевых показателей эффективности (KPI), и поэтому мы знаем, что этот процесс всегда занимает 55 минут.      После задачи 1 задачи 2 и 3 могут обрабатываться одновременно. Задача обработки 2 занимает больше времени, чем задача обработки 3, поэтому она определяет время выполнения процесса.      Токен, который проходит через процесс, клонируется в разделе «И». Первый токен остается в задаче 2 для 45 минут; второй токен остается в задаче 3 на 30 минут.      Второй токен приступает к первому событию, где он потребляется. Через 15 минут первый токен приходит в верхнее ни одно событие, где он также потребляется.      Поскольку доступных токенов нет, экземпляр процесса заканчивается после 55 минут.

    СтартЗадача 1Задача 2Конец 1Задача 3Конец 230 минут45 минут10 минут

    Пока что так хорошо, но что произойдет, если мы уже знаем, что после выполнения задачи 3 задача 2 стала излишней? Это частая ситуация с параллельными выполнением задач, связанных с контентом.      В таких случаях мы можем применить шаблон, показанный здесь:

    Hover over orange symbols for explanation

    СтартЗадача 1Задача 2Конец 1Задача 3Задача 2 не завершенавсе еще?Конец 2Прекратить45 минут30 минут10 минутНетДа

    Событие связи — особый случай. Он не имеет никакого отношения к содержанию, но облегчает процесс создания диаграммы.      Как показано ниже, вы можете нарисовать две связанные ссылки в качестве альтернативы потоку последовательности. Здесь «связанный» означает, что в качестве «точки выхода» есть событие передачи метаданных,      и событие catching link как «входная точка», а два события отмечены как пара — в нашем примере обозначение «A.» означает,

    …Задача 1AAЗадача 2……Задача 1Задача 2…=

    События Link могут быть очень полезными, если:

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

    События Link могут использоваться только как промежуточные события.


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

    Типичными примерами являются:

    • Бронирование поезда или авиабилета
    • Бронирование арендуемого автомобиля
    • Зачисление кредитной карты
    • Ввод в эксплуатацию поставщика услуг

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

    Пятница 1 ночиорганизовать датуПланыактивны?Билеты втеатрВыбрать дату с друзьямиПятница 6 вечераОтправить сообщеие, идем?осуществлять деятельностьКакойплан?отменить броньбилетовСмотреть ТВОтменить друзейтеатрдрузьяДаНеттеатрдрузья

    Мы можем представить последнюю часть модели более компактно с событием компенсации, как показано здесь:

    Наведите указатель мыши на символы оранжевого цвета

    Friday 1 pmВыбрать датуЗапланироватьвстречу?Купить билетыв театрВыбрать датус друзьямиcancel friendsПятница 6 вечераПодождатьих?Пойти в театротменитьсобытиесмотреть ТВОтменить билеты в театрТеатрДрузьяДаНет

    Существуют специальные правила обработки компенсаций:

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

    Лучшая практика: использование компенсационных событий

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


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

    Наведите указатель мыши на символы оранжевого цвета

    пицца comercial seen on TV or friend recommended пицца buy пиццаcrave пиццаСъесть пиццу пицца onпиццаtest.de evaluated and link sent to friend

    Лучшая практика: избегайте нескольких событий

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

    Модель здесь описывает тот же процесс, но события полностью моделируются:

    пицца commercial seen on TVfriend recommended пицца buy пиццаcrave пиццаСъесть пиццуevaluate пиццаon пиццаtest.desend evaluationto friend

    Параллельное событие было добавлено в BPMN 2.0 для дополнения множественного события. Хотя улавливающее множественное событие имеет семантику XOR — это происходит, как только один из его содержащихся событий происходит — параллельное событие использует AND семантику. Это происходит не до тех пор, пока не произойдет все его содержащихся событий. Поскольку металирование множественного события уже подразумевает AND семантику, спецификация определяет параллельные события только как захватывающие события.


    Спецификация BPMN 2.0 добавила событие эскалации. В основном это показывает связь между родительскими и подпроцессами.


    Вы можете использовать событие отмены только в контексте транзакций.


    subprocess — 子进程管理 — Python 3.10.4 文档

    在一个新的进程中执行子程序。 在 POSIX 上,该类会使用类似于 os.execvpe() 的行为来执行子程序。 在 Windows 上,该类会使用 Windows CreateProcess() 函数。 Popen 的参数如下。

    args 应当是一个程序参数的序列或者是一个单独的字符串或 path-like object。 默认情况下,如果 args 是序列则要运行的程序为 args 中的第一项。 如果 args 是字符串,则其解读依赖于具体平台,如下所述。 请查看 shell executable 参数了解其与默认行为的其他差异。 除非另有说明,否则推荐以序列形式传入 args

    警告

    为了最大化可靠性,请使用可执行文件的完整限定路径。 要在 PATH 中搜索一个未限定名称,请使用 shutil.which() 。 在所有平台上,传入 sys.executable 是再次启动当前 Python 解释器的推荐方式,并请使用 -m 命令行格式来启动已安装的模块。

    executable (或 args 的第一项) 路径的解析方式依赖于具体平台。 对于 POSIX,请参阅 os.execvpe() ,并要注意当解析或搜索可执行文件路径时, cwd 会覆盖当前工作目录而 env 可以覆盖 PATH 环境变量。 对于 Windows,请参阅 lpApplicationName 的文档以及 lpCommandLine 形参 (传给 WinAPI CreateProcess ),并要注意当解析或搜索可执行文件路径时如果传入 shell=False ,则 cwd 不会覆盖当前工作目录而 env 无法覆盖 PATH 环境变量。 使用完整路径可避免所有这些变化情况。

    向外部函数传入序列形式参数的一个例子如下:

     Popen(["/usr/bin/git", "commit", "-m", "Fixes a bug."])
     

    在 POSIX,如果 args 是一个字符串,此字符串被作为将被执行的程序的命名或路径解释。但是,只有在不传递任何参数给程序的情况下才能这么做。

    注解

    将 shell 命令拆分为参数序列的方式可能并不很直观,特别是在复杂的情况下。 shlex.split() 可以演示如何确定 args 适当的拆分形式:

     >>> import shlex, subprocess
    >>> command_line = input()
    /bin/vikings -input eggs.txt -output "spam spam.txt" -cmd "echo '$MONEY'"
    >>> args = shlex.split(command_line)
    >>> print(args)
    ['/bin/vikings', '-input', 'eggs.txt', '-output', 'spam spam.txt', '-cmd', "echo '$MONEY'"]
    >>> p = subprocess.Popen(args) # Success!
     

    特别注意,由 shell 中的空格分隔的选项(例如 -input )和参数(例如 eggs.txt )位于分开的列表元素中,而在需要时使用引号或反斜杠转义的参数在 shell (例如包含空格的文件名或上面显示的 echo 命令)是单独的列表元素。

    在 Windows,如果 args 是一个序列,他将通过一个在 在 Windows 上将参数列表转换为一个字符串 描述的方式被转换为一个字符串。这是因为底层的 CreateProcess() 只处理字符串。

    在 3.6 版更改: 在 POSIX 上如果 shell False 并且序列包含路径类对象则 args 形参可以接受一个 path-like object。

    在 3.8 版更改: 如果在Windows 上 shell False 并且序列包含字节串和路径类对象则 args 形参可以接受一个 path-like object。

    参数 shell (默认为 False )指定是否使用 shell 执行程序。如果 shell True ,更推荐将 args 作为字符串传递而非序列。

    在 POSIX,当 shell=True , shell 默认为 /bin/sh 。如果 args 是一个字符串,此字符串指定将通过 shell 执行的命令。这意味着字符串的格式必须和在命令提示符中所输入的完全相同。这包括,例如,引号和反斜杠转义包含空格的文件名。如果 args 是一个序列,第一项指定了命令,另外的项目将作为传递给 shell (而非命令) 的参数对待。也就是说, Popen 等同于:

     Popen(['/bin/sh', '-c', args[0], args[1], ...])
     

    在 Windows,使用 shell=True ,环境变量 COMSPEC 指定了默认 shell。在 Windows 你唯一需要指定 shell=True 的情况是你想要执行内置在 shell 中的命令(例如 dir 或者 copy )。在运行一个批处理文件或者基于控制台的可执行文件时,不需要 shell=True

    bufsize 将在 open() 函数创建了 stdin/stdout/stderr 管道文件对象时作为对应的参数供应:

    • 0 表示不使用缓冲区 (读取与写入是一个系统调用并且可以返回短内容)

    • 1 表示行缓冲(只有 universal_newlines=True 时才有用,例如,在文本模式中)

    • 任何其他正值表示使用一个约为对应大小的缓冲区

    • 负的 bufsize (默认)表示使用系统默认的 io.DEFAULT_BUFFER_SIZE。

    在 3.3.1 版更改: bufsize 现在默认为 -1 来启用缓冲,以符合大多数代码所期望的行为。在 Python 3.2.4 和 3.3.1 之前的版本中,它错误地将默认值设为了为 0 ,这是无缓冲的并且允许短读取。这是无意的,并且与大多数代码所期望的 Python 2 的行为不一致。

    executable 参数指定一个要执行的替换程序。这很少需要。当 shell=True executable 替换 args 指定运行的程序。但是,原始的 args 仍然被传递给程序。大多数程序将被 args 指定的程序作为命令名对待,这可以与实际运行的程序不同。在 POSIX, args 名作为实际调用程序中可执行文件的显示名称,例如 ps 。如果 shell=True ,在 POSIX, executable 参数指定用于替换默认 shell /bin/sh 的 shell。

    在 3.6 版更改: 在POSIX 上 executable 形参可以接受一个 path-like object。

    在 3.8 版更改: 在Windows 上 executable 形参可以接受一个字节串和 path-like object。

    stdin , stdout and stderr specify the executed program’s standard input, standard output and standard error file handles, respectively. Valid values are PIPE , DEVNULL , an existing file descriptor (a positive integer), an existing file object with a valid file descriptor, and None . PIPE indicates that a new pipe to the child should be created. DEVNULL indicates that the special file os.devnull will be used. With the default settings of None , no redirection will occur; the child’s file handles will be inherited from the parent. Additionally, stderr can be STDOUT , which indicates that the stderr data from the applications should be captured into the same file handle as for stdout.

    如果 preexec_fn 被设为一个可调用对象,此对象将在子进程刚创建时被调用。(仅 POSIX)

    警告

    preexec_fn 形参在应用程序中存在多线程时是不安全的。子进程在调用前可能死锁。如果你必须使用它,保持警惕!最小化你调用的库的数量。

    注解

    如果你需要修改子进程环境,使用 env 形参而非在 preexec_fn 中进行。 start_new_session 形参可以代替之前常用的 preexec_fn 来在子进程中调用 os.setsid()。

    在 3.8 版更改: preexec_fn 形参在子解释器中已不再受支持。 在子解释器中使用此形参将引发 RuntimeError 。 这个新限制可能会影响部署在 mod_wsgi, uWSGI 和其他嵌入式环境中的应用。

    如果 close_fds 为真,所有文件描述符除了 0 , 1 , 2 之外都会在子进程执行前关闭。而当 close_fds 为假时,文件描述符遵守它们继承的标志,如 文件描述符的继承 所述。

    在 Windows,如果 close_fds 为真, 则子进程不会继承任何句柄,除非在 STARTUPINFO.IpAttributeList handle_list 的键中显式传递,或者通过标准句柄重定向传递。

    在 3.2 版更改: close_fds 的默认值已经从 False 修改为上述值。

    在 3.7 版更改: 在 Windows,当重定向标准句柄时 close_fds 的默认值从 False 变为 True 。现在重定向标准句柄时有可能设置 close_fds True 。(标准句柄指三个 stdio 的句柄)

    pass_fds 是一个可选的在父子进程间保持打开的文件描述符序列。提供任何 pass_fds 将强制 close_fds True 。(仅 POSIX)

    在 3.2 版更改: 加入了 pass_fds 形参。

    如果 cwd 不为 None ,此函数在执行子进程前会将当前工作目录改为 cwd cwd 可以是一个字符串、字节串或 路径类对象。 在 POSIX 上,如果可执行文件路径为相对路径则此函数会相对于 cwd 来查找 executable (或 args 的第一项)。

    在 3.8 版更改: 在 Windows 上 cwd 形参接受一个字节串对象。

     如果 restore_signals 为 true(默认值),则 Python 设置为 SIG_IGN 的所有信号将在 exec 之前的子进程中恢复为 SIG_DFL。目前,这包括 SIGPIPE ,SIGXFZ 和 SIGXFSZ 信号。 (仅 POSIX)

    在 3.2 版更改: restore_signals 被加入。

    如果 start_new_session 为 true,则 setsid() 系统调用将在子进程执行之前被执行。(仅 POSIX)

    在 3.2 版更改: start_new_session 被添加。

    如果 group 不为 None ,则 setregid() 系统调用将于子进程执行之前在下级进程中进行。 如果所提供的值为一个字符串,将通过 grp.getgrnam() 来查找它,并将使用 gr_gid 中的值。 如果该值为一个整数,它将被原样传递。 (POSIX 专属)

    可用性: POSIX

    如果 extra_groups 不为 None ,则 setgroups() 系统调用将于子进程之前在下级进程中进行。 在 extra_groups 中提供的字符串将通过 grp.getgrnam() 来查找,并将使用 gr_gid 中的值。 整数值将被原样传递。 (POSIX 专属)

    可用性: POSIX

    如果 user 不为 None ,则 setreuid() 系统调用将于子进程执行之前在下级进程中进行。 如果所提供的值为一个字符串,将通过 pwd.getpwnam() 来查找它,并将使用 pw_uid 中的值。 如果该值为一个整数,它将被原样传递。 (POSIX 专属)

    可用性: POSIX

    如果 umask 不为负值,则 umask() 系统调用将在子进程执行之前在下级进程中进行。

    可用性: POSIX

    如果 env 不为 None ,则必须为一个为新进程定义了环境变量的字典;这些用于替换继承的当前进程环境的默认行为。

    注解

    如果指定, env 必须提供所有被子进程需求的变量。在 Windows,为了运行一个 side-by-side assembly ,指定的 env 必须 包含一个有效的 SystemRoot

    如果 encoding errors 被指定,或者 text 为 true,则文件对象 stdin , stdout stderr 将会以指定的编码和 errors 以文本模式打开,如同 常用参数 所述。 universal_newlines 参数等同于 text 并且提供向后兼容性。默认情况下,文件对象都以二进制模式打开。

    3.6 新版功能: encoding errors 被添加。

    3.7 新版功能: text 作为 universal_newlines 的一个更具可读性的别名被添加。

    如果给出, startupinfo 将是一个将被传递给底层的 CreateProcess 函数的 STARTUPINFO 对象。 creationflags ,如果给出,可以是一个或多个以下标志之一:

    PIPE 被用作 stdin , stdout stderr pipesize 可被用于改变管道的大小。 管道的大小仅会在受支持的平台上被改变(当撰写本文档时只有 Linux 支持)。 其他平台将忽略此形参。

    3.10 新版功能: 增加了 pipesize 形参。

    Popen 对象支持通过 with 语句作为上下文管理器,在退出时关闭文件描述符并等待进程:

     with Popen(["ifconfig"], stdout=PIPE) as proc:
        log.write(proc.stdout.read())
     

    引发一个 审计事件 subprocess.Popen ,附带参数 executable , args , cwd , env

    在 3.2 版更改: 添加了上下文管理器支持。

    在 3.6 版更改: 现在,如果 Popen 析构时子进程仍然在运行,则析构器会发送一个 ResourceWarning 警告。

    在 3.8 版更改: 在某些情况下 Popen 可以使用 os.posix_spawn() 以获得更好的性能。在适用于 Linux 的 Windows 子系统和 QEMU 用户模拟器上,使用 os.posix_spawn() 的 Popen 构造器不再会因找不到程序等错误而引发异常,而是上下级进程失败并返回一个非零的 returncode

    python — Is there a way to check if a subprocess is still running?

    Doing the

       myProcessIsRunning = poll() is None 
       

    As suggested by the main answer, is the recommended way and the simplest way to check if a process running.(и это работает и в jython)

    Если у вас нет под рукой экземпляра процесса, чтобы проверить его. Затем используйте процессы TaskList/Ps операционной системы.

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

      filterByPid = "PID eq %s" % pid
            pidStr = строка (pid)
            commandArguments = ['cmd', '/c', "список задач", "/FI", filterByPid, "|", "findstr", pidStr ]
      

    По сути, это то же самое, что и следующая командная строка:

      cmd /c "список задач /FI "PID eq 55588" | findstr 55588"
      

    И в Linux я делаю то же самое, используя:

      pidStr = строка (pid)
    commandArguments = ['ps', '-p', pidStr]
      

    Команда ps уже будет возвращать код ошибки 0/1 в зависимости от того, найден ли процесс.В то время как в Windows вам нужна команда поиска строки.

    Это тот же подход, который обсуждается в следующем потоке переполнения стека:

    Проверить, запущен ли процесс, используя его PID в JAVA

    ПРИМЕЧАНИЕ: Если вы используете этот подход, не забудьте обернуть вызов команды в try/except:

    .
      попытка:
        foundRunningProcess = subprocess.check_output(argumentsArray, **kwargs)
        вернуть Истина
    кроме исключения как ошибки:
        вернуть ложь
      

    Обратите внимание: будьте осторожны, если вы разрабатываете с помощью VS Code и используете чистый Python и Jython.В моей среде у меня была иллюзия, что метод poll() не работает, потому что процесс, который, как я подозревал, должен был завершиться, действительно выполнялся. Этот процесс запустил Wildfly. И после того, как я попросил остановить wildfly, оболочка все еще ждала, пока пользователь «Нажмите любую клавишу, чтобы продолжить…».

    Чтобы завершить этот процесс, в чистом питоне работал следующий код:

      процесс.stdin.write(os.linesep)
      

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

      печать >> процесс.стандартный ввод, os.linesep
      

    И с этой разницей процесс действительно завершился. И jython.poll() начал говорить мне, что процесс действительно завершен.

    python — Почему я получаю предупреждения о ресурсах подпроцесса, несмотря на то, что процесс мертв?

    Я пытался выяснить, как запускать различные экземпляры подпроцессов, а затем убивать их и создавать новые. Родительский процесс Python никогда этого не делает, он просто убивает подпроцессы.Я перешел по многим ссылкам на SO, но после завершения родительского процесса python я продолжаю получать следующее сообщение:

      F/Users/Lucifer/miniconda3/envs/rltp/lib/python3.6/subprocess.py:761: ResourceWarning: подпроцесс 40909 все еще работает ResourceWarning, источник = self)
      

    кажется интересным, потому что я сделал ps , но ничего не получил:

      ВРЕМЯ TTY PID CMD
     7070 ttys001 0:00.06 /Applications/iTerm.app/Contents/MacOS/iTerm2 --server login -fp Люцифер
     7072 ttys001 0:00.61 -баш
    17723 ttys002 0:00.06 /Applications/iTerm.app/Contents/MacOS/iTerm2 --server login -fp Люцифер
    17725 ttys002 0:00.06 -баш
    38586 ttys002 0:00.16 сертоп --no_init
      

    Я просто хочу запустить процесс:

      self.serapi = subprocess.Popen(['sertop','--no_init'],
        stdin=subprocess.PIPE, stdout=subprocess.PIPE, stderr=subprocess.PIPE,
        preexec_fn = os.setsid, оболочка = Истина
        ,)
      

    и убить его:

      os.killpg(os.getpgid(self.serapi.pid), сигнал.SIGTERM)
      

    приведенный выше код по существу скопирован из верхнего ответа:

    Как завершить подпроцесс Python, запущенный с помощью shell=True

    , но я не уверен, почему я получаю это сообщение. Я успешно убиваю дочерний процесс? Я планирую начать и убить многих из них.


    Примечание. Я не знаю или не нуждаюсь в shell=True . Я просто скопировал это, потому что таков ответ / вопрос, который я разместил. Я бы предпочел не иметь этого параметра.


    судя по ответу пробовал:

      деф убить(себя):
        self.serapi.wait()
        #self.serapi.kill()
        self.serapi.terminate()
        #os.killpg(os.getpgid(self.serapi.pid), signal.SIGTERM)
        #self.serapi.wait()
      

    и различные перестановки вышеперечисленного, но на самом деле ничего не работало. Любой совет?

    Уроки, извлеченные при использовании модуля подпроцесса Python

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

    Подождите, моя последняя команда еще не выполнена!

    В какой-то момент у меня было несколько команд git , связанных вместе, вот так:

      процесс = подпроцесс.Popen(['git', 'clone', 'some-repo'])
    ...
      

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

    Что вы хотите сделать, не забудьте вызвать .communicate() для возвращенного процесса. Это гарантирует, что следующая команда не будет запущена до завершения начального процесса. Должно получиться так:

      процесс = подпроцесс.Popen(['git', 'clone', 'some-repo'],
                        стандартный вывод=подпроцесс.PIPE,
                        stderr=подпроцесс.ТРУБКА)
    стандартный вывод, стандартный вывод = процесс.коммуникация()
      

    Попытка изменить каталог с помощью подпроцесса бессмысленна

    В какой-то момент я пытался изменить каталог и назвал его так:

      процесс = подпроцесс.Popen(['cd', 'какой-то каталог'],
                        стандартный вывод=подпроцесс.PIPE,
                        stderr=подпроцесс.PIPE)
    стандартный вывод, стандартный вывод = процесс.коммуникация()
      

    После того, как я почесал голову над тем, почему следующая команда не удалась, и добавив ls до и после, я, наконец, прибегнул к быстрому поиску в Google, и StackOverflow нашел ответ.

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

    Резюме

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

    Подпроцесс события | Camunda Cloud Docs

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

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

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

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

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

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

    Переменные​

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

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

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

    Дополнительные ресурсы

    XML-представление

    Подпроцесс события с прерывающим событием запуска таймера:

       


    PT5M

    ... другие элементы

    :

    Workflow LifeCycle 130002 Рабочий процесс Экземпляр

    Регистрация событий Колодочка с прерывающим таймером Старт события:

    Элемент ID SERVICE_TASK SUB_PROCESS END_EVENT SUB_PROCESS SUB_PROCESS
    Элемент ID
    Event_occurred Fivent_Event
    ELEMENT_TERMINATING fetch-item SERVICE_TASK
    ELEMENT_TERMINATED выборки-пункт
    ELEMENT_ACTIVATING компенсации-подпроцесс
    ELEMENT_ACTIVATED компенсации-подпроцесс SUB_PROCESS
    ELEMENT_ACTIVATING пять минут START_EVENT
    ELEMENT_COMPLETED заказа отменено
    ELEMENT_COMPLETING компенсируют-подпроцесс
    ELEMENT_COMPLETED компенсируют-подпроцесс
    ELEMENT_COMPLETING ПОРЯДКА process PROCESS
    ELEMENT_COMPLETED order-process PROCESS

    Ссылки:

    Subprocess — RapidMiner1 Documentation 90 60301 90 6030 Документация 90 60301

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

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

    Подпроцессы полезны во многих отношениях. Они придают структуру всему процессу. Сложность процессов снижается, и их становится легко понять и модифицировать. Многие операторы имеют подпроцессы в качестве своих неотъемлемых частей, например. оператор X-Validation, который также показан в прилагаемом примере процесса.Следует отметить, что соединение входа подпроцесса напрямую с его выходом без применения какого-либо промежуточного оператора или использования пустого подпроцесса не дает никаких результатов.

    Учебные процессы

    Использование подпроцессов для структурирования процесса

    Набор данных ‘Golf’ загружается с использованием оператора Retrieve. Он присоединен к первому входу оператора Subprocess. Дважды щелкните оператор подпроцесса, чтобы увидеть, что находится внутри этого подпроцесса. Первый вход подпроцесса связан с оператором дерева решений.Выходные данные оператора дерева решений передаются на первый выходной порт. Теперь вернитесь к основному процессу. Вы увидите, что первый выходной порт оператора Subprocess присоединен к первому результирующему порту. Это объясняет результат «Дерево (дерево решений (гольф))» в рабочей области результатов. Вот как это работает: набор данных Golf поступает в подпроцесс через первый входной порт, затем в подпроцессе к нему применяется оператор Decision Tree, полученная модель доставляется в результаты через первый выходной порт подпроцесса.

    Во время основного процесса набор данных Purchases загружается с помощью оператора Retrieve. Он подключен ко второму входному порту оператора Subprocess. Дважды щелкните оператор подпроцесса, чтобы увидеть, что находится внутри этого подпроцесса. Второй входной порт подпроцесса подключается напрямую ко второму выходному порту без применения какого-либо оператора. Теперь вернитесь к основному процессу. Вы увидите, что второй порт вывода оператора Subprocess подключен ко второму порту результата.Но поскольку к набору данных «Покупки» в подпроцессе не применяется оператор, он не дает никаких результатов (даже результат оператора «Получить» не отображается в рабочей области «Результаты»). Это объясняет, почему у нас есть три результата в рабочей области результатов, несмотря на присоединение четырех выходов к портам результатов в основном процессе.

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

    В подпроцессе набор данных взвешивания загружается с помощью оператора Retrieve. Он подключается к оператору X-Validation, а результирующий вектор производительности подключается к четвертому выходному порту подпроцесса, который, в свою очередь, подключается к четвертому порту результатов основного процесса. Это объясняет результат «performanceVector (производительность)» в рабочей области результатов. Сам оператор X-Validation состоит из подпроцесса; дважды щелкните оператор X-Validation, и вы увидите подпроцесс внутри этого оператора.Объяснение того, что происходит внутри X-Validation, было бы здесь отвлекающим маневром. Этот оператор был добавлен здесь только для того, чтобы показать, как различные операторы могут быть составлены из подпроцесса. Чтобы узнать больше об операторе X-Validation, вы можете прочитать его описание.

    Примечание. Этот пример процесса предназначен только для демонстрации различных точек зрения оператора подпроцесса. Это может быть не очень полезно в реальных сценариях. Оператор Example Process of Performance также является хорошим примером использования оператора Subprocess.

    Глобальные подпроцессы | Workflow 2.6 SP1, SIM 4 Documentation

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

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

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

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

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

    Leave a Reply