Comments 103
Это был не просто какой-то язык. Это был клей, который сцепил воедино титанический проект — космический корабль «Буран». Вы только вдумайтесь: четыре сотни (!) разных научных институтов и конструкторских бюро. И все они смогли договориться и запустить в космос сложнейший автоматический корабль в истории. Не приказами, а с помощью общего, понятного всем языка.
Буран начали разрабатывать в 76 году, а ДРАКОН начали разрабатывать(не использовать) в 86 году. Буран слетал в 88 году. Вот есть сомнения что этот язык что то там ключевое сотворил.
Здравствуйте! Спасибо, что так внимательно вчитались в статью и задали вопрос по существу — это очень приятно и ценно. Вы подметили важный момент, давайте разберёмся в нём вместе.
Вы абсолютно правы в датах: работы над самим кораблём «Буран» начались в 1970-х, задолго до того, как язык ДРАКОН был формализован в 1986 году. Конечно, ДРАКОН не использовали для проектирования корпуса или двигателей. Его звёздный час настал на самом последнем и критически важном этапе.
Нервная система для «Бурана»
Представьте себе, что «Буран» — это невероятно сложный организм. Его «скелет» и «мышцы» (то есть планер, механика) действительно создавали много лет. Но для того, чтобы этот организм мог жить и действовать самостоятельно, ему нужна была «нервная система» — сложнейшее программное обеспечение. Именно оно должно было управлять всеми системами в полностью автоматическом режиме во время уникального полёта и посадки без пилота.
Вот для этой задачи — создания «мозга» корабля — и потребовался новый подход. Стандартные языки программирования того времени не подходили. Была нужна технология, которая позволила бы сотням программистов из разных институтов писать код абсолютно одинаково, без малейшего шанса на ошибку или разное толкование.
Доказательства и источники
Прямая связь с проектом: Разработка языка ДРАКОН велась в рамках космической программы «Буран» с 1986 года. Это подтверждают многочисленные источники, включая документальные фильмы Роскосмоса и публикации участников проекта.
Эволюция языков: ДРАКОН не появился на пустом месте. Он стал развитием и объединением специализированных языков, которые создавались именно для «Бурана», таких как ПРОЛ2 (для бортовых систем) и ДИПОЛЬ (для наземных испытаний). Его цель была — дать универсальный и наглядный инструмент, понятный и инженерам, и программистам.
Логика и цель создания: Сама философия ДРАКОНа — строгость, наглядность и защита от ошибок — идеально отвечала требованиям проекта. В космосе цена ошибки абсолютна. ДРАКОН был создан как инструмент для написания сверхнадёжного кода, где человеческий фактор сведен к минимуму.
Дальнейшее применение: Успех этого подхода был настолько очевиден, что после «Бурана» технологию на основе ДРАКОНа стали использовать в других важнейших космических проектах: «Морской старт», «Протон-М», «Фрегат» и других.
Возможно, моя метафора в статье про «клей, который сцепил весь проект» была слишком яркой и могла создать не совсем верное впечатление. Спасибо вам, что вы это подметили. Речь шла именно о его ключевой, решающей роли в создании программной логики — той самой «нервной системы», которая и позволила «Бурану» совершить свой легендарный автоматический полёт.
Ещё раз большое спасибо за ваш вдумчивый комментарий! Мне очень ценно, когда читатели помогают сделать картину точнее и полнее.
В статье не хватает примера: описания процесса на bpmn, uml и драконе с разбором того, чем первые два хуже, а третий лучше.
Здравствуйте! Спасибо, что ткнули пальцем в больное место, это очень по делу. Мысль про наглядное сравнение — просто отличная, и, если честно, я сам об этом думал.
Когда я писал эту свою «исповедь», я намеренно не стал делать из неё технический справочник. Мне хотелось не столько доказать что-то «на бумаге», сколько поделиться своей личной войной с этим хаосом, своей одержимостью. Показать, как я сам, на своей шкуре, почувствовал разницу между мёртвой схемой и живым инструментом.
Поэтому и рассказ получился больше про людей, про совещания, про этот вечный «испорченный телефон», а не про ромбики и стрелочки. Я не ставил себе задачи сделать полноценный сравнительный анализ.
Но вы абсолютно правы: без примера, где можно было бы просто положить рядом три картинки и сказать: «Смотрите, вот тут — визуальный шум, а вот тут — понятно даже кладовщику», — мои слова остаются просто словами.
Так что спасибо вам за этот пинок. Прямо сейчас обещать не буду, но мысль очень правильная, и она у меня в голове теперь точно засядет. Возможно, это будет тема для отдельного, более «зубастого» разговора.
И UML и Дракон это всё одно и то же развитие Р-технологий Глушкова, ещё есть названия "Графит-Флокс", поинтересуйтесь с каких оно времен.. :)
Здравствуйте, Владимир! Вот за это — отдельное человеческое спасибо!
Вы абсолютно правы. Я в статье скорее махал флагом и делился своей болью, а вы взяли и подвели под это дело серьёзную базу. Честно говоря, я до таких глубин, как «Графит-Флокс», в своих раскопках не добирался, и это очень круто, что вы об этом напомнили.
Получается, что все мы, кто сегодня пытается бороться с хаосом с помощью картинок, на самом деле просто продолжаем дело тех гениев из 60-х. А ДРАКОН, по сути, — это их идеи, которые кто-то наконец-то догадался объяснить нормальным, человеческим языком. Чтобы не только академики понимали, а любой из нас мог взять и нарисовать.
В общем, вы очень круто дополнили мой рассказ. Одно дело — моя личная «война», и совсем другое — когда ты понимаешь, что у этой войны есть такая мощная предыстория. Спасибо, что поделились
Не переживайте, Вы не одиноки. Глушкова в свое время, ЦК КПСС тоже послал далеко и без хлеба, когда он предложил автоматизировать ГосПлан СССР. Не всем выгодна автоматизация.
К примеру, мои жалкие попытки на ИПП Советская Сибирь в Нск, в 90-е. Оказывается, учет бумаги на компе - это волюнтаризм и вредительство, ибо в каждом цеху(!) у каждого начальника смены(!) есть своя "неучтенка", которая лежит всё в том же цеху и на которой они периодически левачили, а периодически пускали в производство, когда отдел снабжения лопухался .. этакий "переменный лично-общественный запасец".. не всем оно выгодно на заводах.
Здравствуйте! Спасибо вам огромное за этот комментарий. Вы попали в самую точку и рассказали историю, которая до боли знакома. Ваш пример про «неучтёнку» на «Советской Сибири» — это идеальная иллюстрация того, о чём я пытался сказать.
Вы абсолютно правы. Моя битва в «СТО Фильтр» — это лишь бледная тень тех сражений, которые пришлось бы вести на любом советском предприятии. И я на 100% уверен, что я бы проиграл, даже не начав. Просто потому, что там и задачи такой не стояло — сделать всё прозрачным.
Ваша история про «переменный лично-общественный запасец» — это гениально. Это и есть тот самый «чёрный ящик», который и пытаются уничтожить любые системы учёта и автоматизации. И именно за право на существование этого «чёрного ящика» борются те, кому невыгодна прозрачность.
И вы совершенно справедливо вспомнили Глушкова. Его трагедия с ОГАС — это та же самая история, но в масштабах всей страны. Он предложил сделать всю экономику СССР прозрачной, как стекло, а в ответ получил отказ от тех, кто терял власть и контроль в этой новой системе. Министр финансов Гарбузов, похоронивший проект, по сути, защищал право каждого цеха на свою «неучтёнку».
Так что да, вы правы. Я не одинок в своём поражении. И дело тут не в ДРАКОНе, не в BPMN и не в «АСис». А в том, что любая попытка навести порядок всегда натыкается на яростное сопротивление тех, кто научился ловить рыбу в мутной воде.
Спасибо вам ещё раз за этот очень глубокий и точный комментарий. Вы помогли посмотреть на мою локальную проблему в совершенно ином, историческом масштабе.
У реализации дракона есть несколько мелких недостатков - нет приемлемой ide, нет отладки по коду (только в своей голове) - а код может быть ну очень большой и много переходов, И это дополнительная работа которую многие считают лишней, поскольку отнимает время и не даёт генерировать код, а те ide что выдают код не позволяют производить отладку. IDE дракон крайне сырые.
А так конечно удобно, постоянно пользуюсь Dragon, для понимания чего я там напридумал и уже забыл.
Первые блок-схемы были представлены ещё в 1921 году Френком и Лилиан Гилбрет в работе "Process Charts: First Steps in Finding the One Best Way to do Work" и активно применялись в XX веке. Дракон всего лишь вводит некоторые дополнительные правила и ограничения на составление блок-схем, являясь, таким образом, не самостоятельным языком, а всего лишь стайлгайдом.
Здравствуйте! Спасибо, что копнули так глубоко в историю. Про Гилбретов — это очень к месту, вы правы, они вообще-то всё это и затеяли, пытаясь найти тот самый «единственно верный способ» сделать работу.
Но вот в чем, по-моему, главная штука. То, что делали Гилбреты — это был, по сути, репортаж с поля боя. Они смотрели, как люди работают, и пытались зарисовать это, чтобы найти узкие места. Это была карта местности. Очень полезная, но всё-таки просто карта. На ней можно было рисовать что угодно и как угодно, лишь бы было понятно самому.
А ДРАКОН — это не карта. Это устав.
Разница тут вот в чём. Когда у тебя на руках просто карта, два разных бойца могут проложить по ней два совершенно разных маршрута. И каждый будет по-своему прав. В бизнесе это выглядит так: два аналитика рисуют схему одного и того же процесса, и получаются две разные картинки. Вроде об одном и том же, но выглядят по-разному. И тут начинается хаос.
ДРАКОН же говорит: «Маршрут может быть только один. Шаг влево, шаг вправо — запрещено. Никаких перекрёстков, никаких "а я вот так линию проведу"». Он вводит почти армейские правила не для того, чтобы замучить, а для того, чтобы убрать саму возможность понять что-то не так. Чтобы у директора, кладовщика и программиста в голове была одна и та же картинка, пиксель в пиксель.
Поэтому для меня ДРАКОН — это не просто «стиль для блок-схем». Это попытка превратить туманную карту в чёткий, однозначный приказ. Чтобы он был понятен всем и не допускал толкований.
Спасибо вам, что дали повод об этом поговорить! Это помогает лучше сформулировать, за что мы тут на самом деле воюем.:)
ДРАКОН же говорит: «Маршрут может быть только один.
Так это и есть стайлгайд. Когда вы пишете, например, программу, то оформить один и тот же код можно по разному. Отступы пробелами или табуляцией, открывающие скобки на той же строке или на следующей, строка в 80 символов, 132 или вообще без ограничений, переменные в стиле snake_case или camelCase и многое другое.
Вот для того, чтобы все, занимающиеся проектом, оформляли всё одинаково и всем было проще читать этот код и принимают единый стиль оформления внутри проекта. Так же и дракон, который сам не является языком (попробуйте написать что-то на чистом драконе, не используя какой-либо язык, как программирования, так и естественный), всего лишь задаёт единые правила для оформления блок-схем. То есть, он является стайлгайдом для блок-схем.
В остальном, хотя правила оформления на драконе и достаточно жёсткие и схема с этими правилами читается лучше, чем без них, но он всё равно не является панацеей. Его недостатки - общие недостатки для всех блок-схем. Это и необходимость специального редактора и нечитаемого без него формата хранения, и существенно больший размер листа, чем при текстовой записи алгоритма, и практически невозможное наглядное отслеживание изменений между версиями.
Здравствуйте! Спасибо, что продолжаете диалог, это очень ценно. Вы привели отличную аналогию со стайлгайдами в программировании (snake_case, отступы и т.д.), и она как раз помогает идеально вскрыть разницу.
Вы абсолютно правы: стайлгайд наводит порядок в форме, но не меняет суть. Код, написанный с табами или пробелами, остаётся функционально тем же самым кодом. Он просто выглядит по-разному.
А теперь давайте посмотрим на ДРАКОН. Его правила влияют не на «красоту» или «стиль», а на саму логическую структуру алгоритма.
Требование рисовать схему строго сверху вниз по одной оси («шампур») — это не вопрос стиля. Это запрет на произвольное управление временем, который заставляет выстраивать все события в единую, однозначную последовательность.
Правило «силуэт» (когда схема должна вписываться в определённый контур) — это не про эстетику. Это когнитивный хак, который заставляет дробить сложную задачу на простые, легко усваиваемые куски, потому что мозг не может удержать в фокусе слишком много информации сразу.
Запрет на перекрещивающиеся линии — это не перфекционизм. Это принудительная борьба со спагетти-логикой, которая заставляет аналитика находить более чистое и простое решение.
То есть, ДРАКОН — это не просто набор правил «как рисовать». Это набор правил, заставляющий думать определённым образом. Он меняет не то, как схема выглядит, а то, как мы приходим к самому решению, которое в ней заложено. Он вмешивается в суть, а не в форму.
А что касается недостатков, которые вы перечислили (редактор, размер, отслеживание версий) — тут я с вами на 100% согласен. Это огромная боль и главный тормоз. И это как раз доказывает, что ДРАКОН — не просто «картинка». Если бы это был просто стайлгайд, его можно было бы реализовать простым плагином-линтером к любому редактору. Но поскольку он меняет саму суть алгоритма, он требует своего, особого инструментария, которого, увы, пока нет в должном виде.
Спасибо вам ещё раз за этот глубокий диалог. Он помогает отточить формулировки и лучше понять друг друга.
Сильно сомневаюсь, что дракон заставляет думать как-то по особому. По крайней мере, на вашем же примере со схемой на драконе есть не самый хороший перескок из ветки в ветку, что, ЕМНИП, правилами дракона запрещается.
Ну а по поводу линтера - да, дракон можно реализовать как линтер к любому редактору блок-схем. По крайней мере, я никаких препятствий к этому не нахожу.
Спасибо за ваш отличный комментарий, вы абсолютно правы.
Возможно с моей стороны это кусок схемы я выложил как легкую провокацию.
Вы этот момент заметили и оказались совершенно правы!
С точки зрения канонических, "академических" правил языка ДРАКОН — да, это нарушение.
Правила гласят, что каждая ветка, выходящая из иконы "Выбор" (в вашем случае это "кто встретил клиента" (149)), должна быть полностью изолированной. Слияние боковых веток друг с другом не допускается. Каждая ветка должна либо вернуться на основной "шампур", либо завершиться.
Однако, и это самое важное, цель ДРАКОНа — не слепое следование правилам, а достижение максимальной ясности и читаемости.
В вашем конкретном случае это "нарушение" сделано очень аккуратно и, на мой взгляд, оправдано здравым смыслом:
Нет "спагетти": Линии не пересекаются, схема не превращается в запутанный клубок.
Сохраняется логика: Поток по-прежнему идет сверху вниз, и понятно, что после встречи клиента (механиком или ст. мастером) следует один и тот же следующий шаг — проверка, новый ли это клиент.
Устраняется дублирование: Мы избежали необходимости рисовать один и тот же блок дважды, что сделало бы схему более громоздкой.
Вывод: схема — это хороший пример инженерного компромисса. Я осознанно пошёл на небольшое формальное отступление от правил ради повышения компактности и, возможно, даже читаемости схемы. Для внутренней работы команды это абсолютно приемлемый и понятный вариант.
В общем я вам благодарен за вашу внимательность, сейчас я бы решил это немного по другому и не нарушал правил.
автор не сказал ничего на ДРАКОНьем, но налил целое озеро воды с притягиваем за уши исторических фактов.
Здравствуйте! Спасибо за прямой и честный отзыв.
Вы правы, я не стал делать из статьи технический учебник. Но одну реальную схему из своей практики в «СТО Фильтр» я всё-таки показал. Она там не для обучения, а как «вещдок», подтверждающий мою историю.
Эта статья — исповедь аналитика, а не мануал по ДРАКОНу. Я писал её для тех, кто, как и я, устал от хаоса и «испорченного телефона», чтобы они узнали в этой истории себя. Поэтому в ней так много личных переживаний.
Возможно, для технического специалиста, который ждал подробного разбора, в ней действительно много «воды». Но для менеджеров и аналитиков важна не сама схема, а результат, который она дает: ясность и взаимопонимание.
Тем не менее, ваш комментарий очень по делу. Видимо, теперь пора готовить материал с «мясным» разбором нотаций. Спасибо, что подтолкнули к этому.
Нет! речь не об учебнике или мануале... но условный "Hello, world!" показать можно было бы... ну, например, процесс перехода улицы на светофоре... легко же нарисовать BPMN вариант и в этом самом "драконе" и сравнить... нет?
И это не было бы ни мануалом, ни учебником. Тут аудитория в целом не глупая сидит и уловила бы что и как. И ясность и понимание было бы продемонстрировано ) А так, без конкретик статья выглядит просто как поток рекламы.
И снова спасибо за продолжение диалога. Вы абсолютно правы, и ваш пример про «переход улицы» — идеальный. Он бы действительно не превратил статью в мануал, а стал бы той самой наглядной «вишенкой на торте», которая бы моментально показала разницу подходов.
Я согласен с вами на 100%. Показать рядом две схемы — запутанную BPMN и чистую, как слеза, ДРАКОН-схему для одной и той же простой задачи — было бы лучшим аргументом, сильнее всех моих рассказов про «Буран» и «зоопарки систем».
И, если честно, ваш комментарий заставил меня пожалеть, что я так не сделал. Моя логика была в том, чтобы сначала поделиться «болью», а потом уже переходить к «лекарству». Но вы справедливо заметили, что аудитория здесь достаточно опытная, чтобы оценить практический пример, и он бы не помешал, а только усилил бы повествование.
Считайте, что вы меня убедили. Это было моё упущение.
Спасибо вам огромное за эту дискуссию. Она получилась очень полезной и показала, где статью можно было сделать лучше. Для меня это очень ценно.
Спасибо за статью, полностью согласен с тем, что ИДЕ ДРАКОН - сырые и малопригодные для серъезной работы, особенно в сравнении с проприетарщиной, хотя бы PHP-strom от JetBrain, да и vscode туда же. Обучал в свое время сына программированию, делал переходник ДРАКОН-Ардуино, зашло вполне. Ребенку было 11-12лет.
Автор, Вы не учли матчасть для любого бизнес-аналитика, в частности:
1) принцип ITIL "Отталкивайтесь от текущей ситуации" (Start where you are), то есть начиная работать в новой компании нужно понять подготовку, уровень и зрелость команды, понять планы в том числе по автоматизации, масштаб, какую внедрять нотацию если с нуля или стоит ли менять имеющуюся нотацию если она уже внедрена (что надо обосновать);
2) до начала моделирования разработать соглашение о моделировании. Тут может быть "облегченный BPMN" или вообще что-то ранее не существующее.
Приходить с Драконом (или чем бы то ни было) в компанию и менять все на Дракон, потому что где-то он сработал, прямо скажем, очень оригинальное решение. У Дракона должны быть очень хорошие задокументированные (не на Хабре) показатели, идеально, внедрение в аналогичном бизнесе, на похожих процессах.
Здравствуйте! Спасибо, что так въедливо комментируете, это очень помогает. Вы всё правильно пишете, если рассуждать по книжкам и методичкам. Но моя история была немного про другое.
Я не врывался в «СТО Фильтр» с криками «Всем строиться, теперь живём по ДРАКОНу!». Всё было гораздо прозаичнее. Нас с партнёром (довольно известным 1С-ником) позвали чинить их старую, самописную программу. И именно он предложил ДРАКОН как способ распутать этот клубок.
А дальше случилась магия. Пока основная команда программистов год билась над одной сложной задачей, я просто из интереса сел с одним «левым» 1С-ником, который согласился работать по моим схемам.
И мы вдвоём, втихаря, за два месяца сделали то, что команда из пяти человек не смогла осилить за год.
Вот в этот момент директору стало всё равно, как называется наша нотация — ITIL, BPMN или хоть «палки-кружочки». Он просто увидел, что два партизана сделали для бизнеса больше, чем целая регулярная армия.
Мне до сих пор неизвестно, по каким «правильным» методичкам работала та команда. Но после нашего успеха все мои ДРАКОН-схемы стали для них законом. Потому что они работали. И по ним очень быстро делались реальные вещи.
Так что это была не история про «внедрение». Это была история про маленькую, но очень наглую партизанскую вылазку, которая оказалась успешнее большого наступления. И уже после этой победы мой подход стал для компании главным.
1 Частное. Drakon vs EPC. Чем Дракон лучше?
Как можно математизировать Drakon (аналитически вычислять следующий объект, куда попадет маркер workflow)? Например, как в WF2M-сети? Т.е. аналогия с мат-аппаратом типа сетей Петри.
2 Общее. Все эти workflow-нотации (Drakon, EPC, BPMN) про одно и тоже (как и рядом стоящий набор нотаций ЕА: С4, archimate). При этом есть два уровня формализации. Первый: семантика \ онтология (метамодель), где без подробностей каким значком отображать задаются типы объектов и типы связей, правила построения модели (не отображения элементов).
Второй: графическая грамматика \ синтаксис \ элементы нотации (шаблон, легенда). Это «квадратики и стрелочки», определяющие графическое начертание объектов и предикатов. При этом возможно модель одного и того же смысла показать в разных нотациях («разными квадратиками»), даже модель одной онтологии (метамодели) в разных нотациях: Drakon, EPC, BPMN.
Упражнение на эту тему делал тут (также см. github): ВРМ. Смарт-инструменты «Таблица -> Схема» для формализации бизнес-процессов. Рестайлинг ARIS SmartDesign
фрагмент к будущей статьи:
- Выше упомянуты две метамодели (концептуальные модели). Первая – «семантическая обертка» (DSL-sem) – основная, она задает типы объектов и их связей (взаимосвязей), например, говорит, что такие-то пары объектов могут иметь только такие-то типы связей (отношений). Примеры метамоделей: Togaf\ archimate или масса табличек из Aris (4000+ страничек с семантикой).
Второй тип метамоделей, DSL-syn (условно, т.к. это метамодели синтаксиса, не семантики) – это формат обертки «графическая грамматика» (легенда условных знаков, как в картографии). Она определяет, как графический вид объектов и связей, так и специфику соединений, например, тип связи «следует» в VAD может исходить только с левой и правой стороны элемента «процесс», а «имеет исполнителя» только из нижней. ...
Вывод: вместо того чтобы делать разные инструменты под конкретную нотацию (Drakon, EPC, BPMN … С4, archimate …), нужно сделать один раз хороший инструмент (open source) с произвольно задаваемой метамоделью \ нотацией и на его основе строить схемы любых нотаций. Т.е. два конструктора: метамодели и граф-нотации («квадратики и стрелочки» под конкретную метамодель). Семантику лучше описывать на каком-либо стандартном языке, например, RDF. Конечно хорошо бы, чтобы система была уже с репозитарием объектов.
Здравствуйте! Вот это заход! Спасибо, вы задали просто отличный вектор для разговора. Вы совершенно правы, что смотрите не на «квадратики», а на то, что за ними стоит. Это и есть самый правильный, архитектурный подход. Давайте попробую ответить по пунктам.
1. Частное: Drakon vs EPC и «математизация»
Вы задали очень точный вопрос. Если сравнивать эти нотации, то разница, на мой взгляд, в их целевой аудитории.
Такие нотации, как EPC и BPMN, созданы в первую очередь для систем и бизнес-аналитиков. Как отмечает, например, автор статьи "EPC vs. BPMN - the perfect flamewar" на портале ARIS Community, их главная сила — в богатстве семантики. Они позволяют очень подробно описать разные аспекты процесса: данные, орг. юниты, риски и т.д. Но за это богатство мы платим сложностью, которую я и критикую в своей статье.
ДРАКОН — это язык, который создавали с одной мыслью: чтобы его понял любой человек, а не только гуру-аналитик. Поэтому его главная сила — не в количестве разных «квадратиков» и правил на все случаи жизни, а наоборот — в их жёстком ограничении. Правила рисования там очень строгие, и они сделаны с оглядкой на то, как устроен наш мозг, чтобы схема читалась легко и не вызывала ступор.wikipedia+1
По поводу «математизации» и сетей Петри — вы попали в самую суть. Сети Петри обеспечивают формальную верификацию (возможность доказать правильность алгоритма математически). ДРАКОН добивается той же цели — гарантии отсутствия ошибок — но другим путём. Не через математический аппарат, а через эргономический. Его правила построены так, чтобы человек физически не мог нарисовать двусмысленный или логически противоречивый алгоритм. Это «защита от дурака» на уровне визуального синтаксиса, а не на уровне формальной алгебры.
2. Общее: Два уровня формализации и ваш вывод
Здесь я с вами согласен на 100%. Ваше разделение на семантику (метамодель) и синтаксис (нотацию) — это абсолютно точная и верная классификация. И ваш вывод — это мечта любого системного архитектора.
Создать единый инструмент с конструктором метамоделей и нотаций — это и есть тот самый «Святой Грааль», к которому мы все должны стремиться.
Именно здесь и кроется дьявол. Большинство существующих систем (ARIS, Visio и т.д.) пошли по пути усложнения семантики (добавляя тысячи типов объектов), но при этом оставили синтаксис практически без внимания. Они позволяют рисовать «как угодно», что и приводит к хаосу и непониманию.
ДРАКОН же пошёл по уникальному пути: он максимально упростил семантику, но впервые в истории формализовал и довёл до абсолюта синтаксис, подчинив его законам человеческого восприятия.
И если посмотреть на связку, которую я предлагаю в статье (ДРАКОН + АСис + ИИ), то это, по сути, и есть моя попытка реализовать вашу мечту:
АСис — это и есть тот самый движок с единой, гибкой метамоделью, тот самый репозиторий, о котором вы говорите.
ДРАКОН — это один из «видов» или «представлений» (view) данных из этой метамодели. Самый человеко-понятный «синтаксис» для описания процессов.
ИИ — это интеллектуальный агент, который работает с данными в этой единой метамодели, независимо от того, в какой нотации они были введены.
Так что мы с вами, по сути, говорим об одном и том же, но с разных сторон. Вы — с позиции идеальной архитектурной теории, а я — с позиции практика, который пытается собрать эту идеальную систему из существующих, лучших в своем классе компонентов.
Огромное вам спасибо за этот диалог. Он невероятно ценен и помогает мне самому лучше сформулировать свои мысли.
Про "математизацию" - должны быть одновременно оба подхода: worklow через "квадратики и стрелки" + математическое описание движения бегунка в процессе.
вроде той самой «АСис» Олега Захарчука.
Это что-то (АСис) типа ARIS или Бизнес-студии? Таких систем много.
Я видимо про другое. Семантика \ онтология - это формализм на языке знаний. Наиболее известный DSL для формализации знаний (атом знания - это всегда триплет) - это RDF (Linked Data). Подробнее в semBPM24 и semBPM25. Зачем изобретать велосипед? А ИИ - тут - это "пятое колесо", т.к. и без него все будет работать и без галлюцинаций.
Пример «на пальцах» (упрощенно):
Словами: Процесс_1 «имеет следующего» Процесс_2.
RDF:
prefix ...
:Процесс_1 :имеетТип : ТипПроцесс .
:Процесс_1 :имеетСледующего :Процесс_2 .
Когда мы переходим от семантики к синтаксису, то просто подставляем (на примере dot):
вместо типПроцесс - выражение "cds", style="filled",fillcolor="lightgreen" - это визуализация ТипПроцесс, причем подстановка прямо формулой в Excel.
Аналогично с предикатами. Подставляемая формула – в зависимости от нотации, для VAD одна формула, для EPC – другая.
Фрагмент из excel:
Плюс мое предложение к open source проектам BPM-тематики.
Несколько ссылок к обозначенному выше:
https://habr.com/ru/articles/919396/comments/#comment_28455876
https://habr.com/ru/articles/907584/comments/#comment_28294510
https://habr.com/ru/articles/907584/comments/#comment_28294732
Вот это заход! Спасибо, вы подняли планку разговора на совсем другую высоту. Вы правы в своей теории, и это очень круто. Давайте я попробую ответить и показать, где мы с вами на одной волне, а где смотрим в разные стороны.
1. «Математизация» и формализм: два пути к одной цели
Вы совершенно правы: у любого процесса должны быть и «квадратики» для человека, и строгое математическое описание для машины. Вопрос в том, что первично.
Ваш путь (от машины к человеку): Вы предлагаете начать с идеального формализма (RDF-триплеты), а затем «навесить» на него разные способы визуализации. Это безупречно с точки зрения чистоты архитектуры и машинной обработки.
Мой путь (от человека к машине): Я утверждаю, что в реальном, грязном бизнесе этот подход не взлетает. Потому что человек, который является носителем знания о процессе (директор, кладовщик), не мыслит триплетами. Он мыслит образами. ДРАКОН — это попытка создать визуальный язык, который является одновременно и интерфейсом для человека, и формальной моделью для машины. Его строгие правила («шампур», «силуэт») — это и есть та самая «математизация», но реализованная не через формулы, а через жёсткие эргономические ограничения, которые не дают человеку ошибиться.
Мы оба хотим получить на выходе безошибочный, исполняемый алгоритм. Вы предлагаете для этого использовать мощный математический аппарат. Я предлагаю использовать «когнитивный аппарат», встроенный в сам язык рисования.
2. АСис vs. ARIS и «изобретение велосипеда»
Вы спрашиваете, чем АСис отличается от ARIS или Бизнес-студии. На мой взгляд, отличие — фундаментальное.
ARIS и ему подобные — это, по сути, очень продвинутые инструменты для рисования и хранения схем. Они позволяют описать тысячи объектов и связей, но в их основе лежит идея описания процессов.asys
АСис, как я её понимаю из работ Олега Захарчука, пытается сделать шаг глубже. Она моделирует не процессы, а саму деятельность как систему взаимодействующих объектов, обязательств и результатов. Это не просто «рисовалка», а попытка создать живого цифрового двойника предприятия на единой, универсальной метамодели. В этом смысле она ближе к вашей идее о единой онтологии, чем любой другой известный мне инструмент. Поэтому это не «ещё один велосипед», а попытка построить принципиально другой транспорт.youtube+1tenchat+1
3. ИИ — «пятое колесо» или необходимый двигатель?
В вашем идеальном, формализованном RDF-мире, где все знания уже описаны и структурированы, вы правы — ИИ для исполнения логики не нужен.
Но мы живём в реальном мире. И здесь ИИ — это не «пятое колесо», а тот самый механизм, который помогает превратить хаос в формальную модель. Его задачи:
Помочь человеку создать RDF-триплет: Проанализировать текст должностной инструкции, переписку в чате или запись совещания и предложить черновик ДРАКОН-схемы или RDF-описания.
Найти скрытые закономерности: Проанализировать исполнение даже идеально описанного процесса и сказать: «Смотрите, формально всё верно, но по факту вот на этом шаге у вас всегда задержки, потому что люди ждут неформального одобрения от Иванова». Этого нет ни в одной онтологии.
Работать с неопределённостью: Когда к вам приходит новая задача, у которой ещё нет формального описания, ИИ помогает найти похожие решения и предлагает шаблон.
Проще говоря, ИИ — это "переводчик" между человеком и машиной, который помогает подстроить жёсткую систему под вечно меняющийся бардак реального мира.
Получается, мы с вами копаем один и тот же тоннель, но с разных концов горы. И мне кажется, что именно на стыке этих двух подходов и находится будущее.
Математизация и семантизация - это разные вещи. Математизация workflow - это всего лишь возможность формулой вычислить положение (координату) маркера. См. сети Петри. Только workflow - сложнее их.
Aris - это не рисовалка. В ней и репозитарий и семантика в табличках на 4000+ страницах, см. ARIS Method Reference . Вы работали в ARIS?
Есть ли статьи про АСис (не видео)? Обзоры внедрений АСис? Детальное сравнение его с ARIS? Подробное описание методологии?
создать живого цифрового двойника предприятия на единой, универсальной метамодели.
Обычно DT - это чистый маркетинг. Мне DT не понятен. Понятен только Инструментальный Цифровой двойник.
В вашем идеальном, формализованном RDF-мире, где все знания уже описаны и структурированы,
Не знаю, что это за мир. RDF - это просто язык для описания чего-либо.
Спасибо, что продолжаете этот очень полезный для меня диалог и уточняете свою позицию. Давайте я попробую ответить на ваши новые вопросы.
Про математизацию. Я согласен с вами, что семантизация и математизация — это разные вещи. Когда я говорил о «математизации» в ДРАКОНе, я имел в виду не формальное вычисление, как в сетях Петри, а скорее «встроенную защиту от ошибок» на уровне визуальных правил. Цель та же — добиться безошибочного исполнения, но средства разные.
Про ARIS. Нет, я не работал в ARIS. Поэтому я и не берусь проводить детальное академическое сравнение. Моя критика в статье направлена не на конкретный инструмент (ARIS, безусловно, очень мощная система), а на сам подход, когда сложные, перегруженные семантикой схемы становятся понятны только узкому кругу аналитиков, но не бизнесу.
Про АСис и сравнение. Вы правы, детальных статей и обзоров внедрений АСис пока немного. И именно поэтому я не сравниваю её с ARIS лоб в лоб. Это было бы некорректно. Я бы сказал так: ARIS — это мощнейший микроскоп для детального изучения отдельных клеток (процессов). АСис — это скорее МРТ-сканер, который пытается показать весь организм в целом, пусть и с меньшей детализацией в каждой точке. Это инструменты с разной философией. Возможно, в одной из будущих статей, когда у меня будет больше материала, я и решусь на такое сравнение. Пока же я могу говорить только о том, с чем работал лично.asys+1
Про Цифровой Двойник и RDF. Здесь, мне кажется, корень нашего расхождения. Вы используете термин «Цифровой двойник» в его строгом, инженерном понимании («Инструментальный ЦД»). Я же, говоря о «живом цифровом двойнике» в АСис, использую его скорее как метафору для описания целостной, живой модели деятельности предприятия. Это действительно может звучать как маркетинг, и я принимаю вашу критику. Точно так же и с RDF: вы говорите о нём как о языке для описания знаний, и это абсолютно верно. Я же в своей статье пытаюсь решить более приземлённую задачу: как заставить людей, не знающих об RDF, начать структурировать свои знания хоть в каком-то виде.habr+2
Я понимаю, что с вашей академической точки зрения мой подход может выглядеть как «изобретение велосипеда» и использование нестрогих терминов. И я очень благодарен вам за то, что вы подсвечиваете эти слабые места. Это заставляет меня самого глубже разбираться в теории и искать более точные формулировки.
Аналогичное обсуждение (нотации vs смысл как графика vs семантика).
Как обычно, восхищён Вашей эрудицией.
Сам то я из деревни - слаще морковки ничаво не едал.
Греет душу Кузнецов Побиск Георгиевич:
"От всей бесконечно разнообразной и бурной деятельности остается для передачи в машинную систему ГРАФИЧЕСКАЯ КОНСТРУКЦИЯ, в которой нет ничего, кроме … «кружков» и «стрелок»".
Не сомневаюсь, что Вы узнали абстрактный автомат - состояния и переходы.
Не сомневаюсь, что Вам известно, что управлять сложным поведением автоматов обучает Шалыто Анатолий Абрамович.
Сомневаюсь, что Вам известно, что силуэт ДРАКОН Паронджанова Владимира Даниловича - изоморфно отображает машины состояний.
Из ДРАКОН схем можно генерировать код.
Похоже остальной зоопарк технологий отвлекает от главного.
Осталось научить редактор ДРАКОНА генерировать разные слои схем и сворачивать/разворачивать участки схемы.
Вы абсолютно правы, что в основе всех наших чудес лежат хорошо знакомые «кружки» и «стрелочки», и именно с них начинается управление сложными объектами, включая абстрактные автоматы, как это подробно описал Шалыто. Мне знакомы и работы Владимира Даниловича Паронджанова — его силуэт ДРАКОНа действительно изоморфно отображает машины состояний, что придаёт языку прочную формальную основу и делает его не просто визуальным стилем, а полноценным языком с чёткой логикой.
Я предпочитаю инструмент ИС Дракон Тышова к сожалению работу над этим инструментом действительно остановил сам создатель из-за возраста и проблем со зрением.
ИС Дракон Тышова остаётся удобным и эффективным инструментом для повседневной работы особенно для описания бизнес процессов, позволяя комфортно перемещаться между схемами в единой структуре без излишних переключений. Да, хотелось бы больше современных функций, но уверен, что новые идеи и проекты помогут продолжить эволюцию этой полезной методологии.
При использовании методов графического описания и анализа процессов возникает несколько неочевидных, но всем известных проблем. Из-за которых, собственно, это редко "взлетает" в реальных проектах, а именно:
1. Размер. Схема становится большой. А весить ее на стену спортзала - не всем охота, сильно не удобно и такой спортзал есть не у всех. И опять же -
2. Модификация схемы. Как только возникла нужда вставить элемент, особенно в основание схемы - возникает проблема это все перерисовать, сместить и т.п. Особенно большая, если схема напечатана и висит в спортзале. Соотвественно, чем больше схема, тех дороже ее модифицировать и люди подсознательно переходят на "пу это и так понятно". И все - смысл теряется.
3. Как раз таки достаточность / избыточность и рентабельность. Рисование (даже просто отрисовка, не говоря уж о процессе сбора и анализа) требует ресурса работника /времени /денег. И часто этот ресурс начинает превалировать над выгодой от решаемой проблеммы. А те сотрудники, которые рисуют и поддерживают схему начинают забывать, зачем это было нужно, считая смыслом саму схему.
4. Гонки -- ну нарисовали мы все "как есть". Пока рисовали - что то поняли и поменяли, и уже текущая схема - не "как есть". Тут или допускать неактуальность схемы (а тогда зачем вообще), или останавливать любые изменения пока все не отрисуем и не перепроектируем (губельный путь, уже многократно доказаною. Особенно в современной динамике),
5. А главное - "а дальше что". Ну нарисовали мы все, и даже - актуальное, и даже перепроектировали, и даже - отрисовать новое смогли и убедили руководство, что это правильно. (И я пока зкарыл глаза на то, скоько это стоило). Как это внедрить в работу? Как заставить ЛЮДЕЙ и процессы бегать именно так? И в идеальном мире может быть они бы даже и не противились, но в реальном мире есть отсутствие материалов вовремя, запои, скопление клиентов, непредвиденные поломки. Это все парочь ломает красивые схемы. По этому нормальному директору и достатовно Битрикса. Того "санитарного минимума", что бы хоть что то важное хоть где то было записано. А нормального динамического инструмента (и методологии), который бы устранял эти проблеммы - пока нет.
Это вы ещё не добавили проблему отслеживания изменений (диффов). Для текста она элементарна, а вот изобразить наглядно разницу между двумя версиями схемы - это уже большая проблема.
Ну и, вытекающая из линейных размеров проблема вывода на бумагу. Тут либо придётся склеивать из кучи листочков A4/A3, либо приобретать принтер формата A0. А во времена АЦПУ, не умевших печатать графику, вообще требовался планшетный графопостроитель, здоровенный стол размером два на полтора метра.
Здравствуйте, Rsa97!
Спасибо, что продолжили тему. Вы абсолютно правы, это еще две очень «больные» мозоли, на которые постоянно наступают при попытке внедрить графические методы. Давайте их тоже разберем.
Проблема отслеживания изменений (диффов).
Тут вы правы на 100%, если говорить о большинстве визуальных редакторов. Попытка сравнить две версии схемы в условном Visio — это верный путь к головной боли. Но это проблема не самой идеи визуализации, а конкретных инструментов.
Я в своей практике для совместной работы над схемами приспособил, как ни странно, Dropbox. И это решило 90% проблем. Да, он не показывает наглядно разницу между двумя картинками, как это делает Git для текста. Но у него есть кое-что поважнее: бесконечная история версий. Если кто-то из команды «накосячил» в схеме, я всегда могу откатиться к любому предыдущему состоянию за пару кликов. Это не идеальное решение, но оно простое, надежное и спасает от потери данных. Мы не теряем старые версии, и это главное.
Проблема вывода на бумагу и «принтера формата А0».
Честно говоря, когда я слышу про «склеивать листочки А4», у меня возникает ощущение, что мы мысленно застряли в прошлом веке. Как будто мы до сих пор работаем в НИИ, где копировальная машина А1 стоит в подвале и на ней нужно оформлять допуск у секретаря райкома.
Давайте будем реалистами. В 2025 году распечатывать на бумаге сложную, иерархическую схему — это само по себе нонсенс.
Во-первых, для обсуждений и презентаций есть большие телевизоры. Любая переговорка сегодня оснащена 55-дюймовой панелью, на которой ДРАКОН-схемы читаются идеально. Можно в реальном времени «проваливаться» в нужные ветки, вносить правки и тут же их видеть. Бумага этого не умеет.
Во-вторых, если уж очень хочется иметь что-то на стене для общей картины, то плоттер формата А1 — это не космический корабль. Для компании, которая всерьёз занимается оптимизацией процессов, его стоимость — это сущие копейки по сравнению с теми деньгами, которые она теряет на хаосе и неэффективности.
Так что, на мой взгляд, обе эти проблемы — не проблемы методологии, а скорее, проблемы привычек и нежелания использовать адекватные современным задачам инструменты.
Diff нужен, в первую очередь, не для того, чтобы показать факт изменения, а для показа точных мест изменения кода/текста. А Git прзволяет не просто версионировать файлы, но и разбивать разработку на отдельные ветки, в каждой из которых идёт модификация своей части кода, и сливать эти ветки в основной поток, суммируя всю разработку.
у меня возникает ощущение, что мы мысленно застряли в прошлом веке
Увы, но далеко не везде есть переговорки, проекторы, плоттеры A0. Вполне хватает небольших компаний, которые размещаются в двух-трёх кабинетах, с одним 24-дюймовым монитором у каждого сотрудника. Держать отдельную комнату, которая будет использоваться три раза в год или струйный плоттер, на котором надо печатать регулярно, чтобы не засохла головка, довольно накладно.
Спасибо за очень точные и справедливые замечания. Вы абсолютно правы, и я ценю, что вы заставляете меня уходить от общих рассуждений к конкретике. Давайте по порядку.
Про Diff, Git и ветки.
Вы правы на 100%. Когда я говорю, что Dropbox «решает 90% проблем», я, конечно, сильно упрощаю. Dropbox — это не Git. Он не показывает разницу между версиями (git diff), не позволяет вести параллельную разработку в ветках и потом сливать их (git merge). Для работы с кодом Git является стандартом де-факто, и спорить с этим бессмысленно.atlassian+2
Мой поинт был немного в другом. В реальном бизнесе, где схемы процессов рисуют не программисты, а менеджеры, аналитики или сам директор, внедрение полноценного Git-workflow для картинок — это часто непосильная задача. Поэтому я и говорю про Dropbox как про «санитарный минимум». Это простой, как молоток, инструмент, который не требует обучения и даёт хотя бы базовую защиту от потери данных через историю версий. Да, это не идеальное решение, а скорее, компромисс. И я согласен, что проблема полноценного версионирования для визуальных схем до сих пор не решена на должном уровне.
Про переговорки, плоттеры и «две-три комнаты».
И тут вы абсолютно правы. Мой пример с 55-дюймовой панелью и плоттером формата А1 может показаться оторванным от реальности для небольшой компании, где каждый рубль на счету. Я приношу свои извинения, если это прозвучало высокомерно.
Давайте вернёмся на землю. Вы совершенно верно подметили, что у большинства сотрудников есть 24-дюймовый монитор. И этого, на самом деле, более чем достаточно.
Идея ДРАКОНа как раз в том, что, в отличие от громоздких BPMN-простыней, он построен на принципе декомпозиции. Хорошая ДРАКОН-схема — это не одна гигантская «портянка», а иерархия из множества маленьких, легко читаемых схем, каждая из которых без проблем помещается на обычном мониторе. Вы смотрите на общую схему процесса, видите на ней блок «Обработка рекламации» и одним кликом «проваливаетесь» внутрь, в детальную схему, которая описывает только этот шаг.
Поэтому для работы с ДРАКОНом не нужна переговорка или плоттер. Нужен лишь обычный компьютер и правильно выстроенная, иерархическая структура самих схем. А это уже вопрос не денег, а методологии и дисциплины.
Спасибо вам еще раз за то, что возвращаете меня с небес на землю. Это очень ценно и помогает сделать диалог более честным и полезным для всех читателей.
Идея ДРАКОНа как раз в том, что, в отличие от громоздких BPMN-простыней, он построен на принципе декомпозиции.
Но никто не мешает декомпозировать BPMN-схему. В ней даже есть специальный блок "свёрнутый подпроцесс".
Кроме того, BPMN, как специализированная нотация (заметьте, никто не называет её языком), предназначен именно для бизнес-процессов. Многие вещи, которые легко рисуются в BPMN невозможно изобразить в драконе. Попробуйте, например, на драконе показать разделение процесса на три параллельно выполняющихся ветви с их дальнейшим слиянием, при этом какие-то этапы на этих ветвях должны обмениваться информацией с другими ветвями и/или общим хранилищем как вв однонапраленном, так и в двунаправленном вариантах.
Ну и плюс BPMN, что, в отличие от дракона, для неё есть стандартизованное XML-представление. То есть, схема созданная в одном редакторе без проблем переносится в другой редактор. Для дракона такого нет и два редактора могут оказаться просто несовместимыми по формату хранения.
Спасибо за ваш глубокий и аргументированный комментарий. Ваша точка зрения на BPMN как мощнейшую нотацию с богатством семантики и стандартным XML-представлением безусловно имеет вес.
Однако, чтобы перейти от слов к практике, я хочу предложить вам... небольшой вызов! 😊
Если вы действительно считаете, что есть какой-то бизнес-процесс или сценарий, который легко описать в BPMN, но который невозможно или крайне затруднительно воспроизвести в ДРАКОНе, прошу вас оформить такой пример и поделиться им.
Я лично разберу ваш кейс и постараюсь показать, как эту задачу можно решить в ДРАКОНе, возможно используя особые приёмы и иконы вставки для параллельных ветвей и их синхронизаций.
Такой реальный пример мы опубликуем в моей следующей статье, где BPMN займет роль признанного героя и эталона, а ДРАКОН будет выступать с позициями смелого претендента, которому предстоит доказать своё право на жизнь.
Это будет честный и содержательный батл на живом материале — то, что позволит нашим читателям понять сильные и слабые стороны обеих систем наглядно.
Если вы согласны принять мой вызов напишите мне на почту "ВЫЗОВ"
Буду рад вашей поддержке и открыт к диалогу.
Спасибо за обмен мыслями!
Я не большой специалист в BPMN, но вот простейшая схема. Попробуйте переделать её на дракон не потеряв информацию о действующих лицах и их взаимосвязях.
Потеряна информация об обмене данными с клиентом.
Нет информации, что корректировкой занимается менеджер, согласуя корректировку с клиентом.
Для меня потери информации нет. По процессу в котором прописан алгоритмом, после возникновения условий что договор не проходит один из паралельных процесов, процесс вернулся к менеджеру для доработки...
Возможно надо изменить надпись на иконе №3 не так как в схем BPMN "формирование начального договора" заменить его на "формирование договора". Это даст понимание что работа с договором может быть циклична.
Но вообще схема по моему идентична.
Если для вас потери информации нет, то скажите только по своей схеме, на каких этапах может идти общение с клиентом?
Требуется ли выполнение обоих пунктов 8 и 9 для перехода к пункту 10? Если да, то почему менеджер должен ждать обе ветви, чтобы начать корректировку договора? Если не требуется, то где происходит синхронизация ветвей?
Если этот процесс является подпроцессом, то как узнать статус его завершения в родительском процессе?
Проблема согласования может возникнуть или не возникнуть на любом этапе паралельного процеса иконы 8 9
Условия прохода каждой иконы прописать можно, они не прописаны в вашей схеме я не прописывал в Драконе.
Но это уже процессы отделов 6 и 7
Если надо то можно в эти ветки внедрить икону вставка в каждую и прописать любой по сложности процесс
Кому нужна синхронизация в этом процессе?
Менеджер отдаёт документы на согласование и его задача получить эти документы и продолжать работу дальше...
Менеджеру всё понятно, весь процес ясен он идёт по шампуру сверху вниз если возникают вопросы он действует, звонит клиенту оговаривает условия которые надо выполнить клиенту, отправить дополнительно документы или ещё что...
Икона 12 является концом процеса с удачным заключением договора, икона 16 неудачного. У вас в схеме не прописаны дальнейшие действия зачем я буду огород городить.
Я мог бы сделать в более сложной схеме где каждая икона имеет выход и проходит на дальнейший процесс только зачем это всё здесь в таком элементарном процессе?
Мог бы сделать отдельные паралельные процесы ведущие на другие ветки, вы задачу дайте сложную...
Нарисуйте лапшу какую нибудь я нарисую Дракон схему и сравним читаемость. Зачем обсуждать процес из 3х действий.
Видите плюсики в ромбиках? Они означают, что в этих точках либо один входящий поток управления делится на несколько параллельных, либо ожидается приход всех входящих потоков для продолжения.
Крестики - либо условие, если один входящий, либо соединениие, если один исходящий.
Вот несколько сложнее, хотя и более линейный процесс:
Hidden text
что происходит на шаге подтверждения или отклонения заявки
Планирование перевозки
икона в центре
то есть там полное зацикливание без выхода из цикла?
заявка отклонена
заявка одобрена
выхода нет если подрядчик не может выполнить условия?
замена подрядчика или еще что?
мне здесь непонятно
или таких случаев не бывает что подрядчик не может выполнить условия ? Тогда зачем спланирована ветка отказ?
обьясните логику если подрядчик не может выполнить условия?
Предполагается, что найдётся хотя бы одна цепочка подрядчиков, которая может доставить груз. Отдел логистики получает ответы от всех подрядчиков, которым отправлял заявки, и строит маршрут.
Но, в принципе, ничто не мешает добавить точку выхода при невозможности построения маршрута.
схема
Иконки с конвертами - это не письма, а сообщения. Они могут быть в абсолютно любом формате, хоть устные между людьми, хоть по шине между потоками программы, хоть по сети между компьютерами.
Иконка с пустым конвертом - ожидание входящего сообщения, иконка с закрашенным конвертом - отправка исходящего сообщения сообщение.
Все потоки управления, начинающиеся с зелёных иконок, выполняются независимо друг от друга и обмениваются сообщениями.
Например, блоки "Контроль перевозки" в пуле клиентов, "Управление и контроль перевозки" в пуле логистического оператора и "Погрузка, перевозка, разгрузка" в пуле подрядчиков должны выполняться параллельно. При этом оператор получает сообщения от подрядчика и, в свою очередь отправляет сообщения клиенту. К тому же, блок "Погрузка, перевозка, разгрузка" выполняется для каждого участка перевозки (значок цикла снизу блока).
Плюсики внизу блоков означают, что это подпроцессы, каждый может раскрываться в отдельную схему.
Несколько блоков "Получение оплаты за услуги" и "Расчёт с подрядчиками" могут выполняться одновременно и параллельно. Это показано значком из трёх вертикальных полосок.
У вас на схеме нет ни параллельности независимых процессов, ни многократности.
Создавая схему, я столкнулся с рядом важных и по-настоящему бизнес-критичных вопросов, которые раньше были неочевидны. Например, куда уходит процесс, если согласие с клиентом не достигнуто? Как именно отдел логистики взаимодействует с подрядчиками при отказе по заявке? Эти моменты в твоей схеме не раскрыты, и в процессе работы мне приходилось их дополнительно прояснять, что осложнит обучение и внедрение процессов по вашей схеме.
Именно подход Дракон ценен тем, что при построении схемы заставляет явно прописывать все варианты развития событий — отказы, ветвления, исключения, причины принятия/непринятия решений. Перекладка процессов в такой формат выявляет неявные вопросы, вынуждает искать и устранять логические пробелы, что повышает качество инструкции и бизнес-документации.
Что касается замечаний о параллельности и многократности: если схема нужна обзорная и без формализации каждого сценария, их отсутствие допустимо. Но если задача становится более детализированной — доработку легко сделать с помощью иконки «вставка», раскрывая все нужные ветви, циклы и параллельные процессы по мере необходимости.
Вывод для меня один — при работе над Дракон схемой всегда появляются неочевидные вопросы, и методология, вынуждающая их прояснять, позволяет создать действительно рабочий и обучающий процесс, где нет места "белым пятнам" и недосказанности
при построении схемы заставляет явно прописывать все варианты развития событий
Но у вас не прописаны все варианты. Покажите, как у вас работает следующая ситуация:
Оператор одновременно направил заявки на бронирование трём подрядчикам. Два из них подтвердили бронирование, один отклонил. Оператор направил заявку ещё одному подрядчику, тот её подтвердил.
Затем, у каждого подрядчика свой процесс перевозки груза, при этом он отправляет сообщения оператору, а тот передаёт информацию о прохождении груза клиенту. Но это параллельные процессы. Оператор может, например, накапливать информацию от подрядчиков в течение некоторого периода и отправлять её клиенту разом. Блок "Управление и контроль перевозки" свёрнут и что происходит внутри на этой схеме не видно. Там , в свою очередь, может быть несколько подпроцессов, каждый со своей точкой старта и завершения. Как в драконе показать, что это именно параллельные независимые процессы, обменивающиеся сообщениями?
Дружище давай для продолжения этого диалога зафиксируем один момент. Ты признаешь что на твоей схеме быстрее всего написанного тобой для рабочего процесса не прописаны те вещи которые я указал в прошлом комментарии. И да Дракон схема позволила мне выявить эти процессы которые ты говоришь мне описать.
Ты этот момент признаешь?
Я не могу сказать, что моя схема полностью корректна. Она набросана была на скорую руку, по аналогии с одной из картинок в поиске. И уж тем более я не могу сказать, что именно дракон позволил вам выявить ошибки.
Учитывая, что большинство подпроцессов на схеме свёрнуты (плюсик снизу), какие-то вещи могут быть скрыты в реализации этих подпроцессов.
Однако, ваша схема неверна в принципе, поскольку не показывает параллельного выполнения процессов и не учитывает, что перевозка может выполняться несколькими плечами, на каждом из которых есть свой подрядчик. Ну и часть с оплатой вы пропустили.
В общем, видно, что дракон неплохо описывает однопоточные замкнутые процессы, но не справляется с многопоточными, а тем более с несколькими взаимосвязанными, но параллельными процессами. Тут уже нужен не дракон, а лернейская гидра, ну или, хотя бы, трёхголовый змей горыныч.
Попробуйте, например, нарисовать такую схему: Руководитель отправляет трёх сотрудников на поиск нужной информации. Один ищет в интернете, второй в литературе, третий в архивах организации. Как только один из них находит нужное, все поиски прекращаются. Подпроцесс поиска у каждого, естественно, свой.
bpmn
P.S. Кстати, наглядность схемы на драконе довольно низкая. Попробуйте, например, быстро найти на ней те места, где идёт взаимодействие с клиентом.
Вы Уважаемый несправедливы, описать на Драконе можно что угодно.
Ваши задачи с разными подрядчиками в вашей схеме BPMN не указаны и при прочтении не понятно какой на самом деле процесс.
"не учитывает, что перевозка может выполняться несколькими плечами, на каждом из которых есть свой подрядчик." Где это в вашей схеме описано чтоб было понятно? А то что не понятно при прочтении и есть в голове только заказчика там и остаётся.
Справедливо только утверждение что я пропустил (или не захотел) описывать перечисление денег подрядчику. Хотя как два пальца об асфальт.
кстати данная схема ущербна, так как не описывает когда стоит остановится, например если поиск не увенчался успехом, сотрудники будут долбить интернет до старости.:)
Где это в вашей схеме описано чтоб было понятно?
У каждого подпроцесса в пуле подрядчиков есть комментарии. Один из них, например, - "Подпроцесс по каждому плечу маршрута перевозки для каждой заявки".
не описывает когда стоит остановится
Не описывает. Осталось за кадром. Хотя ничто не мешает добавить в схему ещё подпроцессы. Например, когда начальник решает, что хватит искать, и даёт команду остановить поиск или когда по наступлению определённого события (скажем, таймера) такая команда генерируется автоматически.
В целом же ваша схема не соответствует оригиналу. Поскольку у вас синхронное выполнение, то до проверки на остановку (Информация найдена?) каждый сотрудник дойдёт только после завершения (успешного или нет) своего поиска, в то время, как он должен прервать и выполнение поиска (асинхронно) и дальнейшее движение по схеме.
P.S. Кстати, помниться вы утверждали, что схемы на драконе легко декомпозируются. Как на нём показать, что во время выполнения свёрнутой задачи (икона "Вызов", если не ошибаюсь) идёт обмен со свёрнутой задачей из другого пула или с хранилищем?
В том то и разница между языками описания в вашем языке нужен толмачь в Драконе всё и так понятно так как был бы прописан данный момент прямо в схеме. Если стоит задача описать процесс то Дракон своей логикой требует прописать все события в том числе и остановку, в другом случае схема выглядит зацикленной без конца. "Не описывает. Осталось за кадром." очень удобная позиция :)
Там у вас поиск в литературе и архивах я немного этот момент пропустил в этом случае она точно не похожа на оригинал в остальном разницы не вижу.
немного не понял Задачу поясните подробнее механизм процесса.
в остальном разницы не вижу
Как именно прерывается блок "поиск в интернет" при поступлении сообщения об остановке поиска и откуда видно, что он вообще может прерываться до окончания поиска?
поясните подробнее механизм процесса
Простой пример. Клиент выдаёт некие требования оператору. Оператор предлагает клиенту варианты решения проблемы. Клиент выбирает вариант или отклоняет все варианты и выдвигает дополнительные требования. Если клиент выбрал вариант, то оператор размещает заявку, иначе подбирает варианты с учётом новых требований и процесс повторяется. При этом процесс асинхронный и управляется событиями (пунктирная рамка вокруг подзадачи). Поступление новых требований перезапускает подбор вариантов, отказ клиента от заявки прерывает подбор вариантов.
Теперь я готовлю задание для разработчика оператора. Ему неважно, что именно происходит у клиента, поэтому мы сворачиваем пул клиента в линию и оставляем только сообщения.
Я хочу сделать эту схему частью большой схемы. Сворачиваю задачи, оставляя только обмен.
Готовлю задание для проектирования API - вообще оставляю только линии и сообщения, чтобы празработчик видел, кто и какие сообщения передаёт.
Если для первых двух случаев я ещё могу представить схему на драконе, правда не знаю, как именно там нарисовать асинхронные события, то два послдних, IMHO, на драконе не изобразить без потери информации.
BPMN
Как именно прерывается блок "поиск в интернет" при поступлении сообщения об остановке поиска и откуда видно, что он вообще может прерываться до окончания поиска?
Ответ на этот вопрос: остановка всего действия и всех операторов это остановка процесса икона Конец.
Вот в том то и дело что условия процесса остановки должны закладыватся в схему сразу (в разумных пределах) так как это условия руководителя или обстоятельств, например невозможность продолжать поиск по каким либо причинам. Или время ограниченно для поиска.
То есть это руководитель решает на каких условиях останавливается поиск изначально. Например время заданное для решения задачи, тут может быть множество параметров как простые так и сложные и в схеме изначально условия должны быть чтоб были понятны варианты.
Ну так как указать на схеме в свёрнутом блоке (икона "Вызов"?), что он может прерываться по какому-то сигналу? Что когда начальник сказал "Стоп" поиск должен прерваться. Вы же во время поиска не проверяете каждую секунду, не позвонил ли вам начальник. Вам просто приходит звонок, вы приостанавливаете работу в любом месте, отвечаете на звонок и либо продолжаете работу с того места на котором остановились, либо прекращаете её.
Скажем, мы расписали подробно схему поиска информации и она теперь содержит полсотни подзадач. Должна ли проверка условий остановки добавляться после каждой подзадачи? Но если звонок поступил в середине выполнения подзадачи? Что-то я не нашёл в драконе простого способа обозначения таких прерываний и их влияния на основную задачу.
Дракон схема
информация между сущностями
Привет. Я уже пояснял что Дракон схема организована не по сущностям, клиент, оператор итд как в BPMN она организована по процессу. В этом схемы кардинально отличаются. Я под спойлером скинул 3 варианта мне кажеться так будет удобнее расматривать схемы.
1 схема это схема чисто процесса 2 части процесса по шагам.
2. схема как сделал бы я для программистов она просто обьединяет обе схемы. Мне кажеться это удобно видеть всё и в то же время видеть все связи.
3. схема это информация между клиентом и оператором. Это я сделал по примеру того что ты мне скинул как необходимость.Там если обратишь внимание у каждой иконы есть номер где она распологается что очень удобно для программиста, там в одной иконе есть 2 номера.
То есть смотря на вторую схему программист всё видит и как развивается процесс и где встраивать код и что встраивать.
Я там отметил вопросы, это не ошибки основной схемы ошибок явных нет, эти вопросы возникли у меня, что бы я хотел отслеживать по процессу. Несколько информационных связей не прописаны в твоей схеме но назвать это ошибками я не могу, так как у тебя в принципе всё верно. Эти вопросы возникают у меня по написанию схемы, так устроен Дракон.
У языка Дракон много разных программ нет единого стандарта как в BPMN он силён не в красивом интерфейсе, он силён в правилах и логике построения схем, это заставляет думать на каждом этапе более угублённо. Получается когда ты описываешь с оператором ты получаешь больше информации и связей и описание становится точнее и полнее.
Я пользуюсь ИС Дракон Тышова так как он позволяет структурировать схемы по папкам, и вытаскивать из одной схемы сколько тебе угодно вложеных схем двигаясь из одной в другую и обратно. Для вложенных процессов очень удобно.
Вот только когда я рисую схему обмена сигналами (третья и четвёртая схемы у меня), я просто определяю акторы и сигналы, которыми они обмениваются, но не указываю, в какой последовательности эти сигналы располагаются. Мне это неважно, могу их расположить произвольно. Дракон не может не указывать порядок выполнения.
Причём тут схема простая, всего два актора, Если их на схеме будет с десяток, то цветовая дифференциация икон даст такую пестроту, что со схемой будет невозможно работать. А чтобы определить все сигналы, получаемыен неким актором, вам придётся либо делать двухцветные иконы, либо просматривать надписи на всех иконах отправки сообщений.
Ну и ещё, как же быть с заявленной вами декомпозицией? Где тут икона "Вызов", которая обменивается сигналами и которую я могу открыть, чтобы определить, как именно она получает и отправляет сигналы?
Если вам удобно работать в BPMN я же не призываю вас отказываться от этого языка, да признаю что иногда визуально в нём на уровне программных средств удобнее видеть связи для программиста переходя на разные уровни. Дракон схема это другая логика описания процесса, для меня она лучше так как даёт понимание и мне и бизнесу и программисту что нужно улучшать так как эти вопросы зашиты в структуре Дракон схем при описании возникают вопросы.
BPMN это специализированный язык для описания Бизнес Процессов у него не такая структура и связи там про что вы здесь говорите действительно видны лучше. Но читаемость самих схем намного хуже потому что не учитывают особенности человеческого восприятия.
Описать в Дракон схеме можно что угодно и понять тоже в BPMN описать можно что угодно, но понимание чего угодно под большым вопросом. Хотя человеку который 10 лет описывал в BPMN будет намного проще разобраться. Тут я не спорю.
Описать в Дракон схеме можно что угодно
Ну, пока что я не увидел, как на драконе рисуется прерывание процесса по событию в произвольном месте с возвратом в процесс после завершения прерывания. Ну или полное прерывание по другому событию.
IMHO, дракон застыл в развитии сразу после своего создания 30 лет назад, на уровне однопоточных синхронных программ и программно-управляемого ввода-вывода. За прошедшее время в нём так и не появились сигналы, семафоры, прерывания, асинхронные события. Да, единичный процесс дракон описывает (правда, не особо лучше, чем обычная блок-схема), но наглядно показать взаимосвязь связь нескольких процессов он уже не способен.
Уважаемый Коллега, подскажите пожалуйста, приходилось много кода писать, может я что то упускаю, на я не припомню чтобы в коде где то через строчку, писалось прерывание по событию с возвратом в процесс. На сколько я знаю за разбиение на точки останова (они же точки прерывания, кстати мы все ими пользуемся при отладке кода) отвечает компилятор, программист о них не задумывается. Если Вы посмотрите на переработанный код компилятором в ассемблер например:
@MUL3:
MOV Word Ptr Pid_BpA2[30],0 { Hilfsregister 1.1 }
MOV Word Ptr Pid_BpA2[28],0 { Hilfsregister 1.2 }
MOV Word Ptr Pid_BpA2[26],0 { Hilfsregister 1.3 }
MOV Word Ptr Pid_BpA2[20],AX { Hilfsregister 2.3 }
MOV Word Ptr Pid_BpA2[22],DX { Hilfsregister 2.2 }
MOV Word Ptr Pid_BpA2[24],CX { Hilfsregister 2.1 }
OR BX,BX
JNZ @MUL30 { BX <> 0 }
OR DX,DX
JNZ @MUL31 { DX <> 0 }
JMP @MUL32
@MUL30:
MOV AX,DX
MUL BX { DX,AX = AX BX }
JO @MUL34 { љberlauf }
OR AX,AX
JS @MUL33 { AX negativ }
MOV Word Ptr Pid_BpA2[26],AX { Hilfsregister 1.3 }
MOV AX,Word Ptr Pid_BpA2[20] { Hilfsregister 2.3 }
MUL BX { DX,AX = AX BX }
ADD Word Ptr Pid_BpA2[26],DX { Hilfsregister 1.3 }
JO @MUL34 { љberlauf }
MOV Word Ptr Pid_BpA2[28],AX { Hilfsregister 1.2 }
@MUL31:
MOV AX,Word Ptr Pid_BpA2[22] { Hilfsregister 2.2 }
MOV CX,Word Ptr Pid_BpA2[24] { Hilfsregister 2.1 }
MUL CX { DX,AX = AX CX }
ADD Word Ptr Pid_BpA2[28],AX { Hilfsregister 1.2 }
ADC Word Ptr Pid_BpA2[26],DX { Hilfsregister 1.3 }
JO @MUL34 { љberlauf }
@MUL32:
MOV AX,Word Ptr Pid_BpA2[20] { Hilfsregister 2.3 }
MUL CX { DX,AX = AX CX }
ADD DX,Word Ptr Pid_BpA2[28] { Hilfsregister 1.2 }
ADC Word Ptr Pid_BpA2[26],0 { Hilfsregister 1.3 }
JO @MUL34 { љberlauf }
MOV CX,Word Ptr Pid_BpA2[26] { Hilfsregister 1.3 }
OR BX,BX
JMP @MUL35
@MUL33:
MOV AX,7fffh
INC AX
@MUL34:
MOV AX,0ffffh
MOV DX,0ffffh
MOV CX,7fffh { CX,DX,AX = + max. }
@MUL35:
RETN
Вы поймете, что каждая безусловная пересылка это и есть точка прерывания выполнения. На середине кейса процессор не прервет выполнения команды.
Вот здесь, мне не понятна Ваша мысль, по чему на блок схеме должны рисоваться прерывания, т.к схема является эквивалентом кода "на строке" в графическом виде, где каждая икона это фактически в 90% случаев, один кейс ассемблера, разверните пожалуйста Вашу мысль?
Так же не совсем понятна мысль с асинхронными процессами:
Все мы с Вами прекрасно знаем истину -Процессор в единицу времени может выполнять только одну команду, то есть вся асинхронность, она больше квази (мнимая асинхронность) . Какую именно команду в единицу времени выполняет процессор, это уже работа программиста, как выставить прерывания и приоритеты программ и функций к исполнению.
В каких то IDE этот процесс слегка автоматизирован, в каких то ЯП, есть специальные библиотеки (Которые написаны на этом же ЯП), которые отвечают за обработку событий и системные семафоры. На Древне-Русском ЯП (Это было давно, давно...😏) это называется ДИСПАК (диспетчер пакетов, ну кстати есть еще несколько названий СЛУГА и Планировщик).
Не совсем понятно причем тут блок схема, хотя на ней реально просто пишутся обработчики, и детектируются события прерывания.
Интересно узнать Ваше мнение и Ваше видение процессов обработки событий 🙏
На середине кейса процессор не прервет выполнения команды.
Процессор может прервать выполнение после любой команды (если не выставлен запрет прерываний), сохранить минимальный контекст, выполнить обработчик прерывания, вернуть контекст и продолжить исполнение основного кода с той точки, на которой прервался.
Не совсем понятно причем тут блок схема, хотя на ней реально просто пишутся обработчики, и детектируются события прерывания.
Но ведь дракон позиционируется не только для программирования, но и, например, для описания бизнес-процессов.
А если ваше прерывание является частью процесса? Скажем, основной рабочий процесс состоит из 50 подзадач (то есть икон "Action") с циклами и ветвлением. И по звонку руководителя работник должен этот процесс прервать, выполнить новое задание, а потом продолжить процесс с того места, на котором он остановился. Как изобразить это прерывание на драконе.
Процессор в единицу времени может выполнять только одну команду
Это было до появления многоядерных процессоров, да и до них уже были многопроцессорные системы. Каждое ядро выполняет свой поток и, вполне может быть, что это потоки одной программы. Да, программист пишет каждую функцию отдельно, но эти функции могут выполняться параллельно, да и даже одна функция может быть запущена одновременно несколько раз.
Дракон может показать вам поведение потоков отдельной функции, но не может наглядно изобразить их взаимосвязь.
Найдите ошибку в корректной дракон-схеме
Но ведь дракон позиционируется не только для программирования, но и, например, для описания бизнес-процессов.А если ваше прерывание является частью процесса? Скажем, основной рабочий процесс состоит из 50 подзадач (то есть икон "Action") с циклами и ветвлением. И по звонку руководителя работник должен этот процесс прервать, выполнить новое задание, а потом продолжить процесс с того места, на котором он остановился. Как изобразить это прерывание на драконе.
Здесь как, и в классическом программировании, я вижу отсутствие четко заданного цикла алгоритма.
Т.е есть алгоритм работы предприятия, он должен быть с циклом 1 час фиксированно, более крупный алгоритм, в состав которого входит алгоритм в 1 час, должен иметь уже цикл 1 рабочий день или сутки на предприятии, и работать как планировщик для алгоритмов, которые являются 1 часовыми. Тогда все становится на свои места. просмотрев алгоритмы Выше, я понял что мне чего то не хватает - и это времени исполнения алгоритма от входа, до выхода. т.е сейчас их можно исполнять вечно, застряв на какой то операции. От сюда могут появится и четкие дедлайны для сотрудников, и понимание прерывания процесса например по превышению времени
А если какая-то отдельная операция занимает пять минут, то что делать? Дополнять её до целого часа или как?
А если руководитель позвонил в 10:07:31, то ждать до 11:00:00, прежде, чем ответить на звонок?
Руководитель позвонил, текущая операция прервалась? (Икона вопрос метода Важный звонок?) -это управляющий метод, который использует глобальный флаг "л_Позвонил телефон", из структуры "Возможные звонки", куда входят все возможные звонильщики. В методе обрабатываем приоритет звонящего, результат звонка, стоит ли прерывать текущую операцию, или это "пустозвон". Т.к метод будет для категории лиц общий можно сказать что это метод обработки события.
Результат работы метода завершаем текущую операцию, или продолжаем. Если завершаем то выходим из текущей вставки или метода.
Я так вижу процесс, но Вы можете со мной не согласиться🙏
Это было до появления многоядерных процессоров, да и до них уже были многопроцессорные системы. Каждое ядро выполняет свой поток и, вполне может быть, что это потоки одной программы. Да, программист пишет каждую функцию отдельно, но эти функции могут выполняться параллельно, да и даже одна функция может быть запущена одновременно несколько раз.
Не получилось пока заставить своих, разобраться с многопотоковостью на многоядерных процессорах, вот прям замудрили как то.
Возможно Вы с этим работаете?
Серьёзно не работал, однако немного баловался эрлангом с его параллелизацией и, в принципе, видно, что при запуске многих потоков равномерно загружаются ядра процессора.
Процессор может прервать выполнение после любой команды (если не выставлен запрет прерываний), сохранить минимальный контекст, выполнить обработчик прерывания, вернуть контекст и продолжить исполнение основного кода с той точки, на которой прервался.
Серьёзно не работал, однако немного баловался эрлангом с его параллелизацией и, в принципе, видно, что при запуске многих потоков равномерно загружаются ядра процессора.
Приятно общаться с Умным Человеком🙏
Я больше работаю с JavaScript и не нашёл в драконе (да и вообще в графических схемах) способа красиво отображать каллбэки (лямбда-функции) и асинхронные вещи. Например, такой код:
function foo() {
const promise = new Promise((resolve, reject) => {
setTimeout(() => {
reject(new Error('время вышло!'));
}, 1000);
});
promise
.then(
result => alert(`Fulfilled: ${result}`),
error => alert(`Rejected: ${error.message}`) // Rejected: время вышло!
);
alert('Timer is armed');
}
Здесь создаётся новый промис (обещание), который передаёт в лямбда-функцию два каллбэка - resolve для успешного завершения и reject для ошибки. В лямбда-функции устанавливается таймер на одну секунду, при срабатывании которого будет вызыван каллбэк для ошибки.
Новый промис находится в статусе pending. Затем мы говорим, что когда промис перейдёт в другое состояние, то надо вызвать одну из двух лямда-функций, одну для состояния fulfilled, другую для rejected.
После этого выполнение функции foo завершается и JS занимается другими задачами (JS - в основном однопоточная система, с несколькими служебными параллельными потоками).
Через секунду сработает таймер и в очередь задач JS попадёт вызов лямбда-функции из setTimeout. Когда до неё дойдёт очередь, она вызовет каллбэк reject и промис перейдёт в состояние rejected. При этом в очередь задач поместится вызов второй лямбда-функции из promise.then. В свою очередь эта лямбда-функция выведет на экран сообщение "Rejected: время вышло!".
Как всё это нарисовать на драконе?
Как всё это нарисовать на драконе?
Вот например метод обработки события Авария, если сработал флаг аварии в структуре состояния агрегатов, то выполнится кейс, в котором произойдет отключение аварийного агрегата, там внутри уже обработки массивов, структур, флаги системных событий и данные мгновенных параметров, т.к процесс быстрый, и время выполнения основной программы не должно превышать 1 мс, все что остается от 1 мс, туда идут по приоритету фоновые задачи, не требующие приоритетного выполнения. Чуть дальше меня сегодня попросили дописать, нужно постараться три раза сбросить агрегат, если ошибка агрегата фатальная, то он может сброситься только оператором с кнопки, если нет то он сбросится сам, и войдет в матрицу состояния как готовый к пуску.
Там очень обширная программа каскадного регулятора агрегатов по 50 параметрам, с нечеткой логикой, и таких приемов очень много.
При оптимизации в драконе я добился выполнения по самой длинной ветке основной программы 45 нс, и интерфейс обменивается данными со всеми 10 агрегатами за 1 раз в 1 мс по скоростной шине.
Возможно я не ответил на Ваш вопрос, т.к до конца его не допонял, т.к использую Дракон уже 10 лет, и мозг не плохо перестроился под другой угол зрения на программирование🙏
Вы показываете явный цикл проверки состояния. В JS основной цикл спрятан от разработчика в ядре. Разработчик работает в асинхронной событийной модели и часто не знает, когда именно и в каком порядке будут вызваны обработчики событий. Что-то похожее на мой код можно изобразить в BPMN, но разобраться не зная JS и нотацию схемы может быть непросто.:
BPMN
Представьте себе аварийную кнопку, размыкающую питание станка. Как на драконе в основном цикле работы станка показать, что нажатие на эту кнопку моментально прервёт работу, если кнопка аппаратная и не связана ни с какими циклами проверки.
Представьте себе аварийную кнопку, размыкающую питание станка. Как на драконе в основном цикле работы станка показать, что нажатие на эту кнопку моментально прервёт работу,
Этот же случай и подразумевался под "анти-маркером":
мы управляем состоянием (выполняемая операция, т.е. где уже находится маркер) с помощью внешнего воздействия, т.е. на вход этой же операции (уже запущенной и выполняемой) подаем что-то (сигнал), что может отменить дальнейшее ее выполнение («выбить маркер»). В этом и суть анти-маркера. Это новый сигнал, изменяющий состояние на «пусто» путем действия «отмена операции».
Дракон может показать вам поведение потоков отдельной функции, но не может наглядно изобразить их взаимосвязь.
Все время потоки через дракон делаю для систем жесткого реального времени, вроде получается, не жаловался еще ни кто, на обычных системах как то не приходилось, каюсь грешен🙏
Не примите за замечание🙏, сам часто работаю с Драконом. Для упрощения обработки сигналов, если Вы поклонник ООП можно использовать вставки, методы, ну а если Вы поклонник процедурного программирования, можно и на функциях, причем Функции или Метод, могут быть как икой действия, обычно это вычислительные алгоритмы, или алгоритмы со структурными и массивными возвращаемыми значениями, так и управляющими, используются для изменения маршрута, в иконе Вопрос
Прервать поиск это логическая переменная, Да или Нет, когда Вы сбрасываете в интернете поиск, по факту в функции Вы сбрасываете флаг триггера искать, или совсем выкидываете процесс функции поиска, если Вы закрыли вкладку поиска в браузере. За прерывание функции уже отвечает планировщик задач ОС. Например:
Для Виндовс
Коллеги, извините я, польской аннотацией с конца сообщения читаю😏
Вероятно я отвечаю не впопад, и не по теме, заранее извините🙏
я про то что усложнить процессы в Драконе легко давая точные команды в определенное время если это робот, человеку такая точная синхронизация и детализация просто не нужна, хотя можно сделать.
Конечно хотелось бы разобрать что то более тяжеловестное там где лапши на схеме BPMN много. Вы выбрали самый простой вариант документооборот где BPMN хорошо себя чуствует. Это не пример для Дракона так как я работал в простейшей схеме на одном шампуре, Дракон раскрывается в сложных процессах, где BPMN выглядит как китайская лапша.
Здравствуйте, Alex_INS!
Спасибо за такой развёрнутый и, что самое главное, абсолютно «земной» комментарий. Вы перечислили ровно те проблемы, из-за которых 9 из 10 попыток внедрить графическое описание процессов в реальном бизнесе заканчиваются ничем. Это не теория, это суровая практика. Давайте я попробую ответить на каждый ваш пункт, исходя из своего 32-летнего опыта.
1. Проблема размера и «стены в спортзале»
Вы абсолютно правы: гигантская, монолитная схема — это мёртвая схема. Но здесь кроется фундаментальное заблуждение. Цель — не нарисовать одну большую схему, а понять весь процесс целиком. Как пишет в своей книге «Как улучшить работу ума» Владимир Паронджанов, один из создателей ДРАКОНа, человеческий мозг плохо воспринимает фрагментарную информацию, ему для понимания нужен контекст, общая картина.
Так вот, большая схема — это не простыня на стене спортзала. Это иерархия. Мы не призываем рисовать всё на одном листе. Современные инструменты, например, «ИС Дракон» от Павла Тышова, позволяют создавать целые библиотеки процессов, вложенные друг в друга, как папки на компьютере. Вы можете одним кликом «провалиться» из общей схемы «Приёмка автомобиля» в детальную схему «Проверка уровня масла» и так же легко вернуться обратно. Это даёт и общую картину, и необходимую детализацию без необходимости покупать рулон ватмана.
2. Проблема модификации и «всё перерисовывать»
Это адская боль, я с вами согласен на 100%. Именно поэтому я и отказался от классических блок-схем, где вставка одного элемента в начало заставляет переделывать всю схему вручную. ДРАКОН, благодаря своему строгому правилу «шампура» (когда основная ветка алгоритма идёт строго вертикально), решает эту проблему на уровне идеологии. В хорошем редакторе вставка нового блока в середину «шампура» просто раздвигает остальные блоки вниз. Да, боковые ветки, возможно, придётся немного подвинуть, но это несравнимо с полной перерисовкой «спагетти-схемы». Это превращает модификацию из муки в рутинную операцию.
3. Проблема рентабельности и «смысл в самой схеме»
Тут вы попали в самую точку. Если команда начинает рисовать схемы ради схем — пиши пропало. Именно поэтому я всегда настаиваю: поддержание схем в актуальном состоянии должно быть не «хобби для аналитика», а частью должностной инструкции, зашитой в устав предприятия.
Любая новая идея, любое изменение — от новой акции до смены поставщика — должны сначала «прогоняться» через ДРАКОН-схему. Не ради бюрократии, а ради экономии. Нарисовать и обсудить новую ветку в схеме стоит сто рублей. Внедрить сырую, непродуманную идею в работу и потом устранять последствия стоит сто тысяч. Схема здесь — это не артефакт, а фильтр, который отсеивает негодные идеи и экономит компании колоссальные ресурсы.
4. Проблема «гонок» и актуальности
Это продолжение предыдущего пункта. Если у вас в компании принято, что любые изменения сначала отражаются в ДРАКОН-схеме, то проблемы «гонок» просто не возникает. Разработчики не берут в работу задачу, пока не увидят утверждённую схему. Менеджер не запускает акцию, пока не поймёт, как она будет обрабатываться на каждом шаге. ДРАКОН здесь выступает как «единый источник правды» (single source of truth). А скорость внесения изменений в саму схему, как мы уже выяснили, — это вопрос минут, а не дней.
5. А главное — «а дальше что»?
Это самый важный вопрос. И мой ответ на него может показаться неожиданным. ДРАКОН — это не панацея. Это всего лишь инструмент для достижения договорённости.
Он не заставит слесаря Петрова выйти из запоя и не привезёт вам запчасти, застрявшие на таможне. Он решает другую, но не менее важную задачу. Он заставляет директора, программиста и того самого слесаря Петрова (когда он трезв) одинаково понимать, как должен выглядеть ИДЕАЛЬНЫЙ процесс.
Когда все участники процесса видят перед собой одну и ту же, понятную каждому схему, у них исчезает сама возможность сказать: «А я думал, это не я должен делать». Все «серые зоны» и перекладывания ответственности умирают.
А дальше в дело вступает обычный менеджмент. Когда у вас есть согласованная всеми карта (ДРАКОН-схема) и система фиксации событий (тот же Битрикс или любая другая CRM), вы можете задавать очень конкретные вопросы: «Петров, по схеме ты должен был сделать шаг №3 за 15 минут. В системе отмечено, что ты делал его 2 часа. Почему?».
Без схемы этот вопрос превращается в базар. Со схемой — в предметный разговор.
Поэтому мой подход — это не замена Битрикса ДРАКОНом. Это связка: ДРАКОН (как договорились работать) + Любая система/CRM (как работаем на самом деле) + Менеджер (который сравнивает одно с другим и принимает решения). Никакой магии. Просто инженерный подход к управлению.
"1. Размер. Схема становится большой."
Не нравятся схемы - повесьте на стену спортзала Ваш код.
Поймут ли Вас стейкхолдеры?
Есть же презентационная техника - по схеме можно перемещаться, масштабировать.
"2. Модификация схемы. Как только возникла нужда вставить элемент, особенно в основание схемы - возникает проблема это все перерисовать, сместить и т.п."
Как раз редакторы ДРАКОН и задуманы для упрощения модификаций схем, причём они и не позволят нарисовать "неправильно" схему ДРАКОН.
"3. Как раз таки достаточность / избыточность и рентабельность."
Это проблема не задействующих визуальное мышление.
Они гоняют в уме код.
И забывают, что есть редакторы ДРАКОН, генерирующие код из схем.
Да, код получается специфичный, но код же для компьютера, он не против.
Постепенно, Вы будете проводить в коде меньше времени.
"5. А главное - "а дальше что". "
Если рисовали схемы не для генерации кода, то всё равно лучше со схемой, чем без схемы.
А если ради код, то теперь у Вас есть код программы.
Который обновится, при изменении программы.
Но придётся запретить редактировать код вне схем ДРАКОН - и это самое сложное, но другого выхода пока не придумал.
Привыкших к дифф - если используете редактор ДРАКОНА Степана Митькина, который хранит схемы в формате drn, то придётся написать преобразователь в текстовый формат.
Спасибо за продуманный и развёрнутый комментарий — в нем много правильных замечаний и полезных мыслей. Позвольте кратко прокомментировать основные моменты.
Размер схемы. Да, большие схемы могут казаться громоздкими, но ключевое преимущество ДРАКОНа — возможность иерархичного представления процессов с вложенными схемами и удобной навигацией. Это даёт одновременно и общую картину, и детализацию, без потери удобства восприятия.
Модификация. Вы абсолютно правы: редакторы ДРАКОНа устроены так, чтобы минимизировать боль от изменений — они не позволят построить «неправильную» схему и упростят внесение правок благодаря строгой вертикальной структуре и правилам построения, эффективно превращая модификацию в рутинизированную операцию.
Достаточность и рентабельность. Визуальное мышление — ключ к уменьшению неопределённости и ошибок. Редакторы, генерирующие код из схем, действительно помогают сократить время на отладку и поддержку решений, хотя специфика кода требует определённых привычек и дисциплины в работе.
"А дальше что". Нельзя переоценить эффективность прозрачной и понятной схемы, даже если основная цель — коммуникация, а не генерация кода. Обновляемый код — отличный аргумент в пользу ДРАКОНа, но согласен, что сложность поддержки исключительной синхронизации схем и кода — важный вызов, над которым стоит работать.
В целом поддерживаю ваш взгляд: ДРАКОН — это мощный инструмент, который не только облегчает визуализацию и понимание процессов, но и улучшает связку бизнес-аналитики и разработки. Единственное, всегда важно учитывать контекст применения и обучать команду работать с подобными технологиями, чтобы раскрыть весь их потенциал.
Спасибо за вдумчивый диалог!
Похоже, что выше была затронута проблема синхронизации в workflow.
Модель workflow основана на перемещении маркера. И иногда нужно явно указывать когда результат одной операции должен «уничтожать» маркер в другой операции (function, activity, etc).
Один из подходов, это:
Ответ на этот вопрос: остановка всего действия и всех операторов это остановка процесса икона Конец.
Но только конечно не всего процесса, а в варианте, когда мы такой блок выносим в отдельный подпроцесс и покидание маркера через «конец подпроцесса» (икона Конец) - уничтожает все маркеры этого экземпляра подпроцесса (части нашего процесса).
Вариант, если обойтись без такой декомпозиции – это вводить специальный «анти-маркер» (принудительное завершение операции по внешнему сигналу, поглощение маркера антимаркером), как показано в сети WF2M (по сути математизация ЕРС).
Вообще, проблема синхронизации процессов (операций в процессах) в существующих формализмах workflow – не полностью решается через операторы and\or\xor. Нужен дополнительные с иной логикой обработки маркера.
Это все вопросы к математизации workflow, которой нет ни у Дракона, ни BPMN. Она есть в сетях Петри, CСS, но они «не очень workflow».
Привет Че
Круто, что ты копнул в тему синхронизации в workflow — это реально интересно. Давай сделаем так: скинь схему процесса, который вызывает у тебя сомнения (из WF2M, Петри или твоего примера), и поясни, где именно проблема с движением маркера/синхронизацией. Я постараюсь разобрать по шагам на твоём случае — как ДРАКОН справляется (или нет) с подобным.
Кратко про ДРАКОН: Ты прав, строгой "математизации" как в Петри (токены, формулы позиций) в нём нет — фокус на эргономике и визуальной структуре для минимизации ошибок. Но инструменты синхронизации есть: "Синхронизатор" (ждёт события/времени для потоков), "Ждать" (пауза до условия, как "анти-маркер" — "убивает" маркер по сигналу), "Разделение/Слияние" для параллелизма (маркеры раздваиваются, сливаются после завершения всех/по условию). "Исчисление икон" даёт базовую математику — верификация схем (нет "висячих хвостов"/несинхронизированных циклов), формулы маршрутов (типа "A да B нет C"). В реальных проектах (типа "Буран") это работает для сложных workflow без хаоса.
поясни, где именно проблема с движением маркера/синхронизацией.
Так в статье и есть пример, см. 3.2 Вариант 4 (антимаркер)
Добавил к статье PS1. Кроме того в комментариях вспоминали Дракона.
Привет! Спасибо за такой подробный пример — это реально помогает сразу вникнуть в суть задачи. Я попробовал спроектировать твой вариант 4 (антимаркер из WF2M) на ДРАКОНе: получились две параллельные ветки, где каждый учёный, прежде чем бросать монету, проверяет готовность машины, а потом (если оба попытались почти одновременно) выясняется, кто был первый. Первый переходит в busy, второй — без всяких сложных «антимаркеров» или cancel-дуг просто уходит обратно в ожидание. По сути, вся конфликтная ситуация тут предотвращается заранее за счёт простого ветвления и явных проверок.
Похоже, схема довольно прозрачно разруливает потенциальный конфликт: никто не «зависает» посередине, все переходы видны и остаются под контролем.
Схема Дракон
Правильно ли я понял исходную логику задачи? Или, может, я где-то что-то упростил и не уловил всю глубину вопроса? Если так — буду рад, если подскажешь детали или укажешь, на какой момент ещё стоит обратить внимание!
Нет, не верно.
Это уже иной алгоритм (другая модель поведения ученого). В моем - поведение ученого более примитивное, точнее "задумчивое".
Мой вариант – это пример, когда мы управляем состоянием (выполняемая операция, т.е. где уже находится маркер) с помощью внешнего воздействия, т.е. на вход этой же операции (уже запущенной и выполняемой) подаем что-то (сигнал), что может отменить дальнейшее ее выполнение («выбить маркер»). В этом и суть анти-маркера. Это новый сигнал, изменяющий состояние на «пусто» путем действия «отмена операции».
Другой вариант логики: это когда в зависимости от прохождения маркера в одной ветке, маркер из соседней уничтожается. Это Шаблон 28 (Блокирующий дискриминатор). Анимация шаблона WCP28 Blocking Discriminator.
Обратите внимание в указанных там продуктах он (Шаблон 28) либо не поддерживается или заявлен, но не понятно, как поддерживается (BPMN). И его также нет и в Драконе.
Да, и в табличке продуктов нет Дракона. Напишите Вил ван дер Аалсту, чтобы добавил туда Дракона.
Хочу уточнить правильно ли я понял
Задача заблокировать маркер выполнения паралельного процесса "Учёный 1 или 2"
в моменте когда монеты брошены и одна из них попала в приёмник.
Всё верно в этом моменте происходит блокировка, отбитие броска?
Да. Нам нужно по внешнему событию остановить выполнение уже запущенной операции, функции.
Я вижу ситуацию вот так.
Если коллега хлопнул по руке остановил действие, то учёный уходит в режим ожидания. Мы формально хлопок коллеги принимаем как занятие машины.
Этот вариант предполагает что действие брось монету, уже происходит.
Кратко поясните физику иконок 12, 29, 25 и телевизора 30.
Есть понятие операция (она же функция, действие). Действие не может называться "брось монету".
workflow - это формулы движения маркера. Например, action (оно же activity в BPMN, function в EPC и т.п.) - это задержка маркера в этом элементе, например, на время случайное, распределенное по такому то закону.
Question - маркер попадает на вход и выходит из какого либо выхода. Аналоги шлиз, event и т.п. Однако, как ведет себя маркер в других иконах - не понятно. Например, Output. На схеме workflow - каждый элемент должен быть "про маркер".
Второй вопрос: Смотрим на схему. Две параллельные ветки. И есть утверждение, что они синхронизируются (одна влияет на другую). Тогда должна быть линия, соединяющая эти ветки. Как же тогда распознать синхронизацию? Словами, условиями (внутри какой-либо иконы) - так "не работает" (нет строгого формализма). Нужна явная визуализация синхронизации. Может быть вместо двух телевизоров на вашей схеме должен быть один общий?
Да, вы попали в суть. ДРАКОН действительно не был создан для формального workflow-моделирования в том смысле, который вы описываете. И книга Паронджанова "Как улучшить работу ума" это подтверждает — он создавался как "суперязык интеллектуального общения" для космических проектов, где главной задачей было заставить сотни институтов понимать друг друга.
Про маркеры и семантику движения — вы правы на 100%. В ДРАКОНе есть четкая концепция "дракон-поезда", но она коммуникационная, а не процессная. Когда я рисовал схему с Output'ами, я решал задачу "как объяснить директору, что происходит", а не "как формально описать движение токена". Это принципиально разные задачи.
И вот тут главный фокус. Возьмите приложенную схему кофе-автомата. Видите эти параллельные ветки с двумя учеными, синхронизацию через "монеткоприёмник", условия ожидания? По этой ДРАКОН-схеме я объясню любому руководителю за 5 минут всю логику работы системы. То, что в BPMN или текстовом регламенте потребует намного больше времени для объяснений.
Вот в чем фокус — в 95% бизнес-случаев эта "неформальность" не баг, а фича. У меня была похожая ситуация при описании: две параллельные ветки процесса (прием заказа + проверка склада), и я действительно описывал их синхронизацию словами в комментариях. Работало прекрасно — потому что главная боль бизнеса не в том, что процесс работает на 87% эффективности вместо 92%. Главная боль — в том, что люди друг друга не понимают и тратят часы на объяснения.
А теперь конструктивная часть. Вы описываете потребности двух совершенно разных миров:
Мир бизнес-коммуникации — где ДРАКОН король. Директор смотрит на схему 5 минут и говорит: "Понятно, делаем". Новый сотрудник за день въезжает в логику работы.
Мир математического моделирования — где нужны Петри-сети, формальные семантики и точные расчеты пропускной способности.
Первый мир составляет 95% всех бизнес-задач. Второй — это специальные ниши: производственные линии, высоконагруженные системы, финансовые алгоритмы.
ДРАКОН — это не универсальная отмычка для математического моделирования. Это революционный инструмент экономии времени на коммуникацию. Когда вместо 40-минутных объяснений достаточно 5 минут — это и есть главная ценность для бизнеса. А точное математическое моделирование — следующий этап, для узких специальных задач.
Спасибо, что помогли мне еще четче обозначить одно из главных преимуществ инструмента — скорость понимания.
В ДРАКОНе икона действия предназначена для отображения простого, однозначного шага, который выполняется по ходу алгоритма.
Формулировка «Брось монетку» — это явное действие, совершаемое исполнителем процесса (в данном случае — учёным), и отлично подходит для блока действия.
Такой стиль (императивное указание, глагол в повелительном наклонении) полностью соответствует духу и рекомендациям ДРАКОН: делать формулировки шагов максимально ясными, короткими и однозначными для любого участника процесса, чтобы не возникало разночтений.
В предыдущих схемах была моя ошибка
икона "переключатель"
как понятно из названия,
не может запустить два паралельных процесса
Хотелось бы конечно уточнить что за атрактор выступает как создатель сигнала, машина которая сьела монетку? Или какой внешний наблюдатель? Божественная сущность или эскин подглядевший процесс? Если это практичный вопрос то как будем воздействовать, чтоб отбить бросок, напугаем или устраним?
По хорошему не надо давать чтоб в щель машины пролезала вторая монета, то есть ширина щели пускает только одну монету, а шторка которая падает решает вопрос возможности засунуть вторую.
От Intel 086 до нейросетей: исповедь охотника за бизнес-процессами