DRAKON.SU

Вот исходный документ
http://minsvyaz.ru/uploaded/presentatio ... esia28.pdf
Там применяются диаграммы BPMN.
Я перерисовал одну из них на языке ДРАКОН.
Можно сравнивать!

Каковы ваши выводы?

Дело вкуса.

ДРАКОН силён в описании того, что именно надо сделать.
Особенно если есть принятие решений "если, то", а также повторы действий.

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

Кстати, в мою схему вкралась ошибочка. Правильная схема сдесь:
https://drakon-editor.com/ide/doc/examples/37

Выделите на BPMN горизонтальные полосы - аналоги веток силуэта - и "что" будет не менее ясно

Увы, не той же.
1) Полка - дополнительный элемент, к тому же текстовый. С точки зрения когнитивной эргономики это фатальное усложнение.
2) Цвета: а) не везде хорошо различимы; б) их для большой схемы может не хватить; в) их использование не стандартизировано.
3) Общее замечание: даже в такой маленькой схеме много визуального шума. Блоки одного размера и обилие острых углов создают агрессивную визуальную среду, что тоже почти фатально для когнитивной эргономики.

Контраргумент: визуальное структурирование по двум измерениям в BPMN требует удлинения линий связи, которые становится трудно отслеживать. Это плохо, хотя вроде и не фатально.

Резюме: BPMN с учётом визуального структурирования по двум измерениям с точки зрения когнитивной эргономики в целом лучше.

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

А почему бы не добавить в дракон "слои"? (третье измерение).

Это позволит в данном случае разнести действующих лиц по слоям.

А вообще не касаясь данного случая, можно будет фильтровать по нужным тегам (чтобы быстро отбирать нужные иконы, отсекая лишнее), как замена/дополнение "свертке" икон.

Удобно визуализировать не получится. Эргономика убьётся наповал. Работать будет невозможно.
Это не абстрактные размышления - пробовали.

Фильтры - это хорошо и даже необходимо. Но не достаточно. Опять же понимание процесса затрудняется.

Это всего лишь мнение.
Рассмотрим факты:
https://drakon-editor.com/ide/doc/examples/38

Степан, спасибо за тему и за сравнительный анализ.

Тема "ДРАКОН и бизнес-процессы" очень важна.
Здесь у ДРАКОНа ряд конкурентов

1. BPMN
2. BPMS
3. ARIS (В Германии он на 1-м месте).
4. IDEF3 (Имеется отзыв с Украины, что ДРАКОН лучше, чем IDEF3)

http://www.hups.mil.gov.ua/assets/doc/s ... tion08.pdf

А вот не надо мнение за факты выдавать, не надо.
Это всего лишь спорные тезисы, а не факты.

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

Тем не менее, в BPMN "понять, что делать дальше" не сильно труднее. Поток кода в обоих случаях идёт сверху вниз.

Вам не угодишь. Равнозначность направлений вправо-влево для вас неприемлема; в то же время, когда я предложил ужесточить нотацию и ликвидировать равнозначность направлений вниз-вправо (сделать ДА всегда вправо), все тоже встали на дыбы.
Мне кажется, что здесь не случай "золотой середины", а банальная привязка "к своему болоту" - практически ни разу не аргументированная, разумеется.

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

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

Опять же зависит от задачи.
Либо вы визуализируете её явно (по горизонтали), либо пришиваете пятую ногу в виде полки с указанием исполнителя. См. п.1 - это всегда так. Нельзя сравнивать без отсылки к конкретной задачи, для которой используется модель.

Именно!

dvuugl, а чего это вертикальные линии продолжаются после безусловного перехода?!
Это безобразие.

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

Сочетание плюсов ДРАКОНа (алгоритмы) и BPMN (объекты).

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

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

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

Я бы сказал, получилось сочетание минусов.

Мы решаем конкретную задачу, нас не интересует, что делает объект за пределами нашего алгоритма.
Напротив, нас интересует прежде всего сам алгоритм.

BPMN покупает у обычной блок-схемы расширение функциональности малой ценой разнесения блоков по полосам исполнителей.
А предложенная вами нотация НЕ РЕШАЕТ основной задачи проектировщика, вместо этого внося шум и неадекватные элементы изображения.

[/quote]

Есть недавняя статья по применению BPMN и верификации временных свойств.
Там же краткое описание языка BPMN
https://hal.inria.fr/hal-01538104/document

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

На мой взгляд BPMN имеет 1, действительно фатальный, недостаток - его понимают и умеют пользоваться, только специально обученные люди. А, как мы с вами знаем, обучить кого-то чему-то против его желания не возможно. Поэтому подобные схему украшают портфолио бизнес-аналитиков, стены учебных залов и страницы бизнес литературы, а вот реально пользоваться ими линейные персонал не в состоянии.
С ДРАКОНом все много легче, достаточно 15-20 минутного ликбеза по основным моментам и можно пользоваться (на составлять, а пользоваться!).

Это из практики.

Константин, просьба пояснить.
Ликбез по основным моментам за 15-20 минут — что имеется в виду? Нет ли здесь преувеличения?

Ликбез с преподавателем. Где его взять, такого преподавателя?
Ликбез по книжке. Какую книжку вы имеете в виду?
Или что-то другое?
Просьба пояснить.

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

Всем привет, хочу поделиться своими впечатлениями о BPMN. Я разрабатываю приложения на Java уже несколько лет, и я научился использовать этот бизнес-язык наряду с другими, такими как Archimate. Сейчас я разрабатываю приложение для выполнения производственных процессов в компании, где я работаю, это приложение используется на нескольких заводах по производству пластиковой пленки, я использую процессный движок Activiti (теперь он называется Flowable), Так что одним из преимуществ BPMN является возможность использовать эти движки, которые помогают вам включать в процесс действия, формы, вызовы Java-классов, вызовы REST-сервисов, среди прочего, что облегчает в случае моего приложения, что вы можете управлять производственными процессами, что пользователь или группа используют их, и таким образом охватывают производство на фабрике.

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

Сейчас я изучаю DRAKON и, конечно, считаю себя еще новичком, однако я верю, что это не должен быть язык против другого, но так же, как есть DRAKON-JAVA или DRAKON-C++, Должен быть также DRAKON-BMPN и включать диаграммы CMMN или DMN, которые являются частью семейства для неструктурированных процессов и правил, так что в CASE-средстве диаграмма DRAKON является входом, который генерирует BPMN, CMMN или DMN в соответствии с необходимостью.

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