DRAKON.SU

К моей статье https://habr.com/ru/articles/940152/ появилась интересный комментарий

а именно был задан вопрос:
прочитать ветку можно здесь https://habr.com/ru/articles/940152/com ... t_28802142

я нарисовал схему в ответ на вопрос https://habrastorage.org/r/w1560/getpro/habr/upload_files/f17/c5c/f7c/f17c5cf7c1dfa6e97721145899882607.png
но похоже я упростил задачу так как следующий комментарий это подтвердил

Нет, не верно.

Это уже иной алгоритм (другая модель поведения ученого). В моем - поведение ученого более примитивное, точнее "задумчивое".

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

Другой вариант логики: это когда в зависимости от прохождения маркера в одной ветке, маркер из соседней уничтожается. Это Шаблон 28 (Блокирующий дискриминатор) http://www.workflowpatterns.com/pattern ... /wcp28.php.
Анимация шаблона WCP28 Blocking Discriminator. http://www.workflowpatterns.com/pattern ... mation.php

Обратите внимание в указанных там продуктах он (Шаблон 28) либо не поддерживается или заявлен, но не понятно, как поддерживается (BPMN). И его также нет и в Драконе.

Да, и в табличке продуктов нет Дракона. Напишите Вил ван дер Аалсту, чтобы добавил туда Дракона.


Может быть кто то в своей деятельности решал подобную задачу, прошу откликнуться, может быть есть какие мысли как решить эту задачу?

Сергей, не надо ссылаться на Хабр.
Что надо сделать?

1. Опишите условие задачи прямо здесь.
2. В том же сообщении выложите дракон-схему.

Похоже, что выше была затронута проблема синхронизации в workflow.

Модель workflow основана на перемещении маркера. И иногда нужно явно указывать когда результат одной операции должен «уничтожать» маркер в другой операции (function, activity, etc).

Один из подходов, это:

Ответ на этот вопрос: остановка всего действия и всех операторов это остановка процесса икона Конец.

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

Вариант, если обойтись без такой декомпозиции – это вводить специальный «анти-маркер» (принудительное завершение операции по внешнему сигналу, поглощение маркера антимаркером), как показано в сети WF2M (по сути математизация ЕРС).

Вообще, проблема синхронизации процессов (операций в процессах) в существующих формализмах workflow – не полностью решается через операторы and\or\xor. Нужен дополнительные с иной логикой обработки маркера.

Это все вопросы к математизации workflow, которой нет ни у Дракона, ни BPMN. Она есть в сетях Петри, CСS, но они «не очень workflow».


SergiiKol
21 час назад
Привет Че
Круто, что ты копнул в тему синхронизации в workflow — это реально интересно. Давай сделаем так: скинь схему процесса, который вызывает у тебя сомнения (из WF2M, Петри или твоего примера), и поясни, где именно проблема с движением маркера/синхронизацией. Я постараюсь разобрать по шагам на твоём случае — как ДРАКОН справляется (или нет) с подобным.

Кратко про ДРАКОН: Ты прав, строгой "математизации" как в Петри (токены, формулы позиций) в нём нет — фокус на эргономике и визуальной структуре для минимизации ошибок. Но инструменты синхронизации есть: "Синхронизатор" (ждёт события/времени для потоков), "Ждать" (пауза до условия, как "анти-маркер" — "убивает" маркер по сигналу), "Разделение/Слияние" для параллелизма (маркеры раздваиваются, сливаются после завершения всех/по условию). "Исчисление икон" даёт базовую математику — верификация схем (нет "висячих хвостов"/несинхронизированных циклов), формулы маршрутов (типа "A да B нет C"). В реальных проектах (типа "Буран") это работает для сложных workflow без хаоса.


itGuevara
20 часов назад
поясни, где именно проблема с движением маркера/синхронизацией.

Так в статье и есть пример, см. 3.2 Вариант 4 (антимаркер)

Добавил к статье PS1. Кроме того в комментариях вспоминали Дракона.



SergiiKol
19 часов назад
Привет! Спасибо за такой подробный пример — это реально помогает сразу вникнуть в суть задачи. Я попробовал спроектировать твой вариант 4 (антимаркер из WF2M) на ДРАКОНе: получились две параллельные ветки, где каждый учёный, прежде чем бросать монету, проверяет готовность машины, а потом (если оба попытались почти одновременно) выясняется, кто был первый. Первый переходит в busy, второй — без всяких сложных «антимаркеров» или cancel-дуг просто уходит обратно в ожидание. По сути, вся конфликтная ситуация тут предотвращается заранее за счёт простого ветвления и явных проверок.

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

Схема Дракон
Правильно ли я понял исходную логику задачи? Или, может, я где-то что-то упростил и не уловил всю глубину вопроса? Если так — буду рад, если подскажешь детали или укажешь, на какой момент ещё стоит обратить внимание!





itGuevara
13 часов назад
Нет, не верно.

Это уже иной алгоритм (другая модель поведения ученого). В моем - поведение ученого более примитивное, точнее "задумчивое".

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

Другой вариант логики: это когда в зависимости от прохождения маркера в одной ветке, маркер из соседней уничтожается. Это Шаблон 28 (Блокирующий дискриминатор). Анимация шаблона WCP28 Blocking Discriminator.

Обратите внимание в указанных там продуктах он (Шаблон 28) либо не поддерживается или заявлен, но не понятно, как поддерживается (BPMN). И его также нет и в Драконе.

Да, и в табличке продуктов нет Дракона. Напишите Вил ван дер Аалсту, чтобы добавил туда Дракона.


SergiiKol
16 минут назад
Хочу уточнить правильно ли я понял
Задача заблокировать маркер выполнения паралельного процесса "Учёный 1 или 2"
в моменте когда монеты брошены и одна из них попала в приёмник.
Всё верно в этом моменте происходит блокировка, отбитие броска?

Для сведения. Мне кажется, что чегевара участник нашего форума под другим именем viewtopic.php?f=153&t=7220

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

Понимаете ли вы задачу, которую надо решить?
Если не понимаете, я при всем желании не смогу вам помочь.

В Драконе есть параллельные процессы, но у Тышова они не реализованы или реализованы плохо.

[quote="Владимир Паронджанов"]Сергей, вы привели дракон-схему. Это хорошо.
Однако рядом с ней я не нашел условия задачи, которую требуется решить. Это плохо.

Условия задачи которые дал Че

3.2 Вариант 4 (антимаркер)
В варианте 4 показано как реализовать синхронизатор явно. Если убрать дуги «cancel», то реализуется сценарий, когда ученый бросает монету, не глядя на индикатор «готов», однако монета будет принята только когда машина будет в состоянии «СМ свободна». Дуги «cancel» выводят ученого из состояния броска, т.е. говорят, что пока не будет сигнал «готов» бросать монету не нужно.

Анти-маркер
Реализация механизмов синхронизации \ параллелизма кроме синхронных развилок split (fork) и слияний join (merge) [WF2M23] требует операторы принудительного останова уже исполняемых операций. Поэтому вводится специальный маркер «анти-маркер» (cancel), который при передаче в функцию поглощает имеющийся в ней маркер в составе того же хода (расчета сети на текущем шаге дискретизации). При этом вместо стандартного события «p.out» формируется «p.outAnti»:

- фиксируется завершение функции (для вычисления времени выполнения), при этом вычисляется время выполнения операции как разница от момента получения антимаркера до старта операции (р.start);

- маркер поглощается (удален до подхода к выходу из узла, т.е. не попадает в исходящую дугу, как при событии «p.out»).

В таблице переходов «анти-маркер» обозначается знаком «минус», т.е. как требование поглотить маркер (вычесть 1) из узла, где маркер присутствует (=1). На схеме - более тонкой линией и подписью «Cancel». В BPMN по смыслу схож с обработчиком прерывающих Событий со значением атрибута cancelActivity = «true».

Пример ситуации: Не нужно далее собирать заказ клиента (нужно прекратить операцию сбора), если клиент отказался от заказа (при условии, что заказ уже начали собирать, т.е. был реализован p.start).

Применительно к Workflow Patterns это видимо: Шаблон 19 «Отмена задачи» (вариант 2 паттерна). «Видимо» - т.к. странная анимация к этому (wcp19) паттерну.

Считается, что кроме штатного WF-порта каждый WF-узел имеет специальный порт управления (WFs), который принимает \ выдает специальные «управляющие» маркеры. В общем случае, возможны следующие вариации спец-маркера «отмены» применительно к блоку «операция» (EPC function):

прекращение действия: спец-маркер «вышибает» текущий маркер в «конец» (завершение) функции (операции), текущий маркер (обычный) переходит через границу узла и формируется событие «p.out», т.е. маркер выходит из функции через «парадный выход» (т.е. с штатной регистрацией такого выхода);

анти-маркер условный: при попадании в узел при наличии текущего маркера в узле, удаляет его, формируется событие «p.outAnti», т.е. маркер выходит из функции через «черный ход». Если текущего маркера в узле не оказалось (нечего поглощать), то формируется исключение (ошибка, exception);

анти-маркер безусловный: действует, как и «анти-маркер условный», но не формирует сигнал исключения.

Целевые и виртуальные состояния
Обычно в схемах показываются только «целевые действия» (наиболее важные), а «неважные» скрыты. Вариант 4 (рис. 3.1б) содержит такое «неважное» - как виртуальное состояние (узел с пунктирным контуром): ожидания ученых пока готовится кофе.

В бизнес-процессах важен именно приносящий пользу шаг (value, например, идея VAD-диаграмм), в то время как в сетях Петри обычно фиксируются все состояния моделируемого объекта, т.к. без этого не сработает синхронизация (переходы), поэтому необходимо предусматривать различные состояния ожидания. Таким образом, в отличие от сети Петри, WF2M сеть может содержать только «полезные» (важные) пользователю процедуры (состояния), а при необходимости низкоуровневая логика может быть показана через «зашитые» в правила обработки специальных операторов, указанных в матрице переходов. Например, низкоуровневая логика алгоритма также может быть реализована (формализована) на эквивалентном преобразовании в сеть Петри [WF2M23]. Смысл в том, что только часть формализма функционирования системы отображена аналитиком бизнес-процесса на схеме workflow.

Состояния модели
Состояния кофе машины (СМ, Coffee Machine):

ждет и принимает монету (coin), СМ.ready (готов);

готовит и выдает кофе (coffee), СМ.busy (занят).

Состояния (действия, activity) ученого (CS, Computer Scientist, математик):

CS (CS’) бросает монету (СМ вроде освободилась): Попытка опустить монету в машину;

CS (CS’) пьет кофе и публикует: Прием чашки кофе из машины и «Переработка кофе в теоремы» (выпить кофе и опубликовать);

Виртуальное: если не пью кофе (не публикую) - ожидать готовность машины (СМ).


---------------------------------------------------------------------------------------------------

PS1 Пояснения к 3.2 Вариант 4 (антимаркер)

К вопросу отсюда.

Computer Scientist - ученый: CS первый, CS’ – второй. Кофе машина - одна (СМ, Coffee Machine). Отсюда: Кофе-машина и два ученых.

Подробнее можно обрисовать ситуацию так. Утром (машина свободна) два ученых подходят к кофе-машине (СМ) и "много думают", состояния "CS или CS' бросает монету" . При этом рандомно каждый ученый может бросить монету, т.к. он ведь изначально видел, что машина свободна: маркер находится в этой операции (например, в functuin = "CS' бросает монету") - когда машина была свободна, но вылететь из нее сам уже не может, если машина стала занята другим ученым.

Тот кто раньше бросил монету (например, CS) в случае успеха (а успех гарантирован, т.к. он первый) должен (условно) похлопать второго ученого (CS') по плечу, типа дать знак что кидать монету не нужно, т.е. технически - "выбить" своим анти-маркером "cancel" маркер из состояния "CS' бросает монету".

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

Что надо сделать?
1. Выполнить все рашифровки, удалить все ссылки и получить нормальное описание. Сейчас у вас не описание, а ребус, который невозможно понять.
2. Представить описание и дракон-схему в одном сообщении.

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

В иконах 9 и 10 тексты отличаются.

9. ожидание состояния ready
10. ожидание ready

можно тексты сделать одинаковыми? Или нельзя?

В иконах 11 и 26 должен быть текст:
"Машина сброшена и занята другим ученым"
Иконы 25, 28 убрать.

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

Я именно это и сказал (что требует комментатор).

В иконах 11 и 26 должен быть текст:
"Операция прервана другим ученым"
Иконы 25, 28 убрать.

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

Вот как раз иконы вывод и подают такой сигнал. Если их убрать то внешнего воздействия не будет.

я подумал так будет правильно
икону 29 и икону 20 из действия переделал в комментарий

Я именно это и сказал (что требует комментатор).

В иконах 11 и 26 должен быть текст:
"Операция прервана другим ученым"

Сергей, прошу подтвердить согласие с изменением.

Да, конечно.

Рассмотрим действия в левой ветке.
В иконе 11 сказано:
"Операция прервана другим ученым"
Предположим, что операция прервана в момент t1.

Спускаемся ниже по алгоритму и попадаем в икону 25.
Действия в иконе 25 (хлопание коллеги по руке) происходят в момент t2.

Зададим вопрос:
Момент t2 наступает раньше или позже момента t1 ?
Ответ:
Момент t2 наступает после момента t1.

Сергей, прошу подтвердить ваше согласие с ответом.

я вас не понял
Вы написали "Предположим, что операция прервана в момент t1."

в этом случае t2 не наступает так как ответ в t1 НЕТ.

в иконе 11 операция прервана пользователем
ответ да или нет

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

Понял проблему
ведь я рисую в иконе переключатель
где действие может происходить только в одной ветке а не синхронно в двух

похоже моя предыдущая схема ошибочна

схема ниже предполагает 2 одновременных входа