Comments 39
Именно поэтому ДРАКОН смог объединить 400 научных институтов для космической программы СССР.
Да нет же! Всем известно, что это мой язык БАЛАБОЛ объединил 400 институтов СССР. Хотя нужно отдать должное платформе ГРАФОМАН (графический математико-аналитический нонсенс), на которой он базируется так же, как и язык ДРАКОН. На языке БАЛАБОЛ программировались все спутники Советского союза вплоть до провозглашения ими независимости в 1993 году. С тех пор программа БАЛАБОЛ засекречена в zip-архиве РГБ.
Здесь вступает в игру ДРАКОН - не просто нотация, а когнитивный инструмент, созданный под биологические ограничения человеческого мозга.
Дракон поглощающий питона.. Не ту картинку на заставке выбрали для статьи
Ну настолько откровенно блабла реклам на хабре давно не видел. Даже любопытно как эту статью оценят.
Как ДРАКОН может помочь моему бизнесу, если ДРАКОН не смог помочь автору поста внятно объяснить, чего он хочет? Я, вот, например, после поиска в тексте по ключу ДРАКОН, так и не понял, что это за зверь.
Вывод по прочтении: ДРАКОНа надо опасаться, it's a time eater.
Спасибо за этот комментарий - он абсолютно справедлив. Если после прочтения статьи остаётся впечатление, что ДРАКОН - это «пожиратель времени», значит, я не смог объяснить его суть просто и ясно. Это моя ошибка как автора, и я её признаю.
Позвольте исправить это одним предложением:
ДРАКОН — это не программа и не методология. Это визуальный язык, на котором можно описать любой бизнес-процесс так, чтобы его поняли и директор, и кладовщик, и программист - без споров, без «испорченного телефона», за 5 минут.
Он не «делает» ничего сам - но позволяет людям договориться о том, КАК что-то должно работать, прежде чем писать код, покупать ERP или запускать ИИ.
В статье «Почему ваш бизнес хромает» я показал, как с его помощью:
сократили время на создание ТЗ с месяца до недели,
устранили двойную запись клиентов в СТО,
позволили программисту и владельцу бизнеса говорить на одном языке.
Если бы я начал статью с этого - возможно, вы бы не сочли ДРАКОН «time eater», а увидели в нём time saver.
После вашего комментария я сделал в статье дополнение в самом начале. Спасибо ещё раз.
Вот что случается когда статью дают писать ИИ . Куча повторов, непонятные таблицы, полная потеря контекста. Автор, вместо того чтобы больше поработать мозгами и пальцами, понадеялся на дипсик в итоге получил деньги за рекламу зря и в перспективе будет уволен)
На примере четырех кейсов утверждать, что внедрение ИИ в 95% случаев не оправдалось это сильно.Не буду спорить, что из-за трендовости llm-ки начали пихать куда только можно и провалов много, но не настолько же. И вообще непонятно, как четкий алгоритм вас спасет от того факта, что модель вам вместо ответа None выдаст или любую другую галюционную ерунду. Или как ваш дракоша позволит исправить предвзятость после обучения/дообучения, если он учавствует фактически учавствует только в составлении промпта, особенно на фоне того фкта, что очевидно прописанные запреты периодически не срабатывают.
Короче, натягивание дракона на глобус, либо непонимание проблемы больших языковых моделей и оттого попытка решить это самым наивным способом.
Спасибо за честный и важный комментарий. Вы поднимаете ключевые болевые точки, с которыми сталкиваются все, кто работает с LLM на практике: галлюцинации, предвзятость, ненадёжность даже при чётких промптах.
И вы абсолютно правы: ДРАКОН сам по себе не «исправляет» ИИ. Он не устраняет галлюцинации, не переписывает веса модели.
Но он решает другую, более фундаментальную проблему - ту, из-за которой 95% пилотов проваливаются даже до того, как ИИ начинает галлюцинировать.
Эта проблема - отсутствие понятного, согласованного, визуального описания бизнес-процесса, в который ИИ должен быть встроен.
ДРАКОН - это не «лекарство от галлюцинаций».
Он просто позволяет:
чётко отделить зону, где ИИ принимает решение, от зоны, где человек проверяет,
встроить «план Б» прямо в схему (например: «если ИИ не уверен - передать оператору»),
сделать промпт частью системы контроля, а не одноразовой инструкции,
дать разработчику однозначное ТЗ, чтобы обернуть ИИ в логику «если-то-иначе» на уровне приложения.
Да, это не волшебство. Но в 9 из 10 компаний, где я работал, провал начинался не с галлюцинации, а с того, что никто не мог объяснить, как процесс должен работать даже без ИИ.
Так что это не «натягивание Дракона на глобус». Это признание: пока мы не научимся говорить на одном языке между собой, нам рано учить ИИ говорить с нами.
Если у вас есть пример, где ИИ внедрён в чёткий, визуализированный процесс - и всё равно ломается из-за фундаментальных ограничений LLM - с удовольствием обсудим. Потому что настоящее решение - не в отрицании ИИ, и не в слепой вере в него, а в честном управлении его слабостями.
Ох уж эти адепты ДуРАКОНА, вечно хотят к нему прикрутить что-нить стильное, модное, молодёжное - bluetooth/блокчейн/LLM/etc.
Божечки, Дракон... Я уж думал, никогда уже не услышу этого названия... 😲
Там ведь ещё эти были... шампур-схемы!!!! 😁😁😁
Я в аспирантуре учился в начале двухтысячных и уже владел неплохо всякими новыми штуками, типа UML и XML, начитавшись про них книжек в оригинале, ибо на нашем языке их ещё не выпускали. И когда мне научник принес книжку о дружелюбном драконе и его шампур-схемах со словами: "Вот наши тайные советские разработки, обязательно из используй!" - то я смотрел на это и не знал, плакать мне или смеяться.
Ну я смеялся, конечно, в основном - потому что в книжке описывались кейсы использования Дракона на программах, которые мы в восьмом классе на информатике решали. А плакал я потому что понимал, что меня могут заставить засовывать в эти шампуры сложные программные архитектуры, которые я тогда проектировал (многопоточности и синхронизации, например, в Драконе я не видел).
Но сейчас я готов задать осмысленный вопрос - а почему Дракон? Почему не UML или там BPML например? Или не обычные какие-нибудь mind maps?
Какую проблему вы пытаетесь решить, склеивая дракон с ллм ? Ведь вдоль и поперек уже известно, что визуальные системы программирования и проектирования крайне сильно ограничены в реальном мире - чуть более сложный чем hello world алгоритм в них будет выглядеть чудовищно сложно и отлаживать его и искать ошибки будет в разы сложнее, чем в коде.
А какие-то простые и понятные последовательности рисовать можно просто в виде презентаций со стрелочками - так они и понятнее, и приятнее.
Зачем Дракон-то ?
Постараюсь ответить на ваш вопрос почему Дракон. Я не программист и мне трудно судить о работе по Дракону в ядре и многопоточным системам, здесь я вам не отвечу, есть более знающие люди в этих вопросах. Можно задать вопрос на форум Дракон https://forum.drakon.su/ Я пишу только о том что знаю о применении Дракона в Бизнес процесах...
В статье «Почему ваш бизнес хромает» я предлагаю совсем другую роль ДРАКОНа - не как инструмент кода, а как универсальный переводчик между бизнесом, аналитикой и IT.
Как я писал в той статье:
«У аналитиков - свой язык. У программистов - свой. У бизнеса - третий. И на каждом “этаже”, при каждой передаче смысла, он искажается, теряется, умирает».
Именно эту Вавилонскую башню и ломает ДРАКОН. Не потому что он «лучше UML», а потому что он биологически совместим с рабочей памятью человека (4-5 элементов одновременно).
Например можно прочитать книгу "Владимира Даниеловича Паронджанова: Как улучшить работу ума". Эта книга есть в открытом доступе и очень интересна.
BPMN с его сотней символов - это когнитивная ловушка. А ДРАКОН - это язык, на котором могут договориться директор СТО и программист.
У меня есть опыт описания бизнесов на языке Дракон читайте статью: От Intel 086 до нейросетей: исповедь охотника за бизнес-процессами
Сегодня LLM всё больше заходит в бизнес и возникает другая проблема как контролировать процесс чтоб было всё хорошо. Если не понимаете проблематику то стоит прочитать ещё одну статью "«Общество не допустит» - иллюзия в эпоху ИИ" в ней поясняеться ситуация и она являеться по сути началом этой статьи. Конечно многие читая сразу эту статью, могут вообще не понять в чём вопрос.
Сегодня проблема не в том, чтобы написать сложный код. Проблема в том, что 95% ИИ-пилотов проваливаются из-за хаоса в процессах. Компании внедряют LLM, но не могут чётко описать:
где ИИ должен действовать,
где - передавать человеку,
что считать «правильным» результатом.
Именно здесь ДРАКОН становится фундаментом для агентских ИИ: он не устраняет галлюцинации, но фиксирует границы разумного поведения в визуальной, неизменяемой, понятной всем форме.
Так что да - для «Hello, World» это избыточно.
Но когда речь идёт о том, чтобы ИИ не заказывал 260 наггетсов, не давал смертельные рекомендации и не исключал мелких предпринимателей из кредитования - нужна не гибкость, а строгость.
И в этом - новая, скромная, но жизненно важная роль ДРАКОНа в эпоху ИИ:
не писать код, а задавать границы разумного.
P.S. Шампур-схемы - да, они есть и будут и это приемущество Дракона смотрите статьи 😊 Но сегодня речь не о них. А ДРАКОН - это попытка говорить на одном языке: от директора до агента ИИ.
BPMN с его сотней символов - это когнитивная ловушка.
Пардон, в BPMN не так уж и много символов. Процесс, событие, шлюз, дорожка, данные. Итого получаем пять. У дракона 23 разных "иконы", причём не самых очевидных.
А ДРАКОН - это язык, на котором могут договориться директор СТО и программист.
Вот только язык, который понимают все, теряет особенности, необходимые каждому конкретно. Иначе не возникали бы языки, специализированные для разных целей. В результате мы получаем либо язык, непонятный неспециалисту, либо язык, в котором невозможно описать то, что нужно специалисту.
Но когда речь идёт о том, чтобы ИИ не заказывал 260 наггетсов, не давал смертельные рекомендации и не исключал мелких предпринимателей из кредитования - нужна не гибкость, а строгость.
Это решается гораздо проще. Не надо вообще использовать статистический алгоритм, которым является LLM (ошибочно принимаемая многими за ИИ) там, где нужен алгоритм детерминированный.
Приветствую...
Вы как всегда отрицаете мощный когнитивный момент языка Дракон.
Я применяю в процессе описания примерно 5-7 символов и у каждого из этих символов однозначное значение.
BPMN же напротив позволяет свободно комбинировать события, шлюзы, подпроцессы, сообщения, таймеры, исключения - и получать схемы, где один и тот же «ромб» может означать и «решение», и «параллельный запуск», и «ошибку». Надеюсь вы не собираетесь спорить что это комбинаторная сложность описания?
Даже в вашем описании на BPMN при разборе я нашёл вопросы которые сразу не понятны в схеме. Но дело не в том что вы нарисовали "плохую" схему, схема у вас была нарисована довольно качественно. Просто в отличии от Дракона BPMN не заставляет думать.
BPMN даёт свободу, которая становится хаосом при передаче смысла.
При описании процессов вы капсулируете понимание специалистом и эта проблема что не бизнес ставит на самом деле задачи является основной. У меня другой подход, бизнес самостоятельно может поставить в Драконе задачу специалисту практически по любому бизнес процессу, но можно пойти еще дальше и проверять работу того же программиста по Дракон схеме. (так делать не обязательно). Для бизнеса которому часто дурят голову очень актуально...
Универсальный язык теряет специфику. Лучше использовать детерминированные алгоритмы, а не LLM»
Здесь вы абсолютно правы в принципе, но не в практике.
Да, там, где нужна детерминированность - нужен не LLM, а код.
Но кто пишет этот код?
И на основе чего?
Вот реальный кейс из статьи:
McDonald’s внедрил ИИ для приёма заказов. Он начал заказывать 260 наггетсов. Почему? Потому что в ТЗ не было чёткого правила: «максимум 10 позиций в заказе».
Это не ошибка LLM. Это ошибка отсутствия договорённости между бизнесом и IT.
Если бы у них была ДРАКОН-схема процесса «приём заказа», в ней бы стояло:
И программист написал бы детерминированный код.
А владелец бизнеса утвердил бы логику.
И никакого LLM там бы не было.
ДРАКОН здесь - не замена коду. Он - мост для создания правильного ТЗ.
Он убивает не «статистические алгоритмы», а главную причину их провалов -хаос в понимании процесса.
Вы правы: ни один язык не может быть одновременно простым для всех и выразительным для специалистов.
Но ДРАКОН - не попытка заменить BPMN, UML или код. (да и вряд ли это возможно, школы обучают, на этом зарабатывают... )
Это инструмент для фиксации договорённости - чтобы детерминированный алгоритм писался по правильной логике, а не по «испорченному телефону».
Я надеюсь что именно в этом - его скромная, но жизненно важная роль в эпоху ИИ:
не быть ИИ, а предотвратить его ошибки до того, как он их совершит.
Ещё раз спасибо за продолжение дисскурсии, это позволяет моим читателям глубже понять мои идеи.
Я применяю в процессе описания примерно 5-7 символов и у каждого из этих символов однозначное значение.
Значит и в BPMN вы можете ограничиться теми же 5-7 символами, даже с учётом комбинаторики. Вас никто не заставляет использовать всё.
один и тот же «ромб» может означать и «решение», и «параллельный запуск», и «ошибку».
Ромб не может означать ошибку. Это либо разветвление процесса, либо точка соединения ветвей. При этом шлюз задаёт правила ветвления или соединения. У дракона, например, при соединении ветвей непонятно, ждём ли мы прихода в него всех потоков управления или достаточно одного.
McDonald’s внедрил ИИ для приёма заказов. Он начал заказывать 260 наггетсов. Почему? Потому что в ТЗ не было чёткого правила: «максимум 10 позиций в заказе».
И что? Как дракон позволит добавить в ТЗ этот пункт, если о нём просто никто не подумал. Например, на вашей схеме нет пунктов "Клиент добавляет NULL наггетсов", "Клиент добавляет отрицательное число наггетсов", "Клиент добавляет больше наггетсов, чем есть полуфабрикатов". Почему вы не заложили эти варианты? Вы о них просто не подумали, так? И дракон не помог.
Вы правы - ни один инструмент не думает за аналитика. Если не подумали об отрицательном числе наггетсов, схема будет неполной.
Но ключевое отличие в том, что происходит дальше.
BPMN, с его гибкостью, позволяет "спрятать" эту неполноту в сложности диаграммы. Пропущенное требование потонет среди шлюзов, событий и потоков.
ДРАКОН же, благодаря своей принудительной простоте, действует как каркас или контрольный список. Пропущенное логическое условие (как "число < 0?") остается очевидным белым пятном на схеме. Он не предотвращает ошибку мышления, но он делает ее заметной для всех участников процесса - и для бизнес-заказчика, и для программиста.
В случае с McDonald's, если бы они строили процесс в ДРАКОНе, само построение дерева решений с большой вероятностью заставило бы их задаться вопросом: 'А каковы вообще валидные границы для количества?' И правило 'максимум 10' было бы естественным образом выявлено и формализовано.
BPMN же такую дисциплину мышления не навязывает.
ДРАКОН же, благодаря своей принудительной простоте, действует как каркас или контрольный список.
Увы, но не действует. \
Пропущенное логическое условие (как "число < 0?") остается очевидным белым пятном на схеме.
Увы, но не остаётся. Например, вы пишете условия для обработки сигналов автомобильного светофора. Добавляете красный, жёлтый, зелёный. Вспоминаете про зелёный мигающий и одновременный красный + жёлтый. А, да, ещё жёлтый мигающий. Ну и неисправный светофор. Можете нарисовать схему и пусть она вам покажет, чего же не хватает в этой схеме.
И чего?
В Японии светофоры используют синий цвет вместо зелёного. Если вы не знаете этого, то дракон вам этот "пробел" не покажет.
Вы подняли важный вопрос, и я, неправильно донёс до вас свою мысль. Дело не в том, что ДРАКОН «сам показывает пробелы». Волшебной палочки нет. Сила ДРАКОНа - не в магии, а в том, как он организует процесс совместной работы аналитика и эксперта.
Давайте посмотрим на реальный процесс моделирования в бизнесе из моего опыта:
Кто является экспертом? Я, как бизнес-аналитик, работаю с руководителем среднего или высшего звена. Этот человек — носитель высочайших компетенций в своей области. Иначе бы его на этой должности не было. Его знания - исходный материал для схемы.
Как происходит работа? Мы садимся вместе, и я, используя жесткие правила ДРАКОНа, начинаю выстраивать логику его бизнес-процесса.
Эта структура действует как мощный катализатор мышления.
То есть схема рождается в совместном труде с руководителем отдела.Когда выявляются пробелы? Руководитель, глядя на выстроенную логику, сам начинает видеть места, где:
Он не до конца продумал ситуацию.
Появился «висячий хвост».
Обнаружилась нестыковка.
В этот момент он часто говорит: «Стоп, тут надо подумать», - и берет тайм-аут на 1-2 дня, чтобы подключить профильных экспертов из других отделов, провести совещание и принять решение.
Чья это ответственность? Да, я не буду знать, что в Японии светофор синий. Но эксперт, который формирует со мной эту схему, знать обязан. Это его зона ответственности. Моя задача - создать такой четкий и требовательный к логике формат, в котором он эти пробелы не сможет не заметить при совместном просмотре.
Итог процесса. В 90% случаев по моей практике так и происходит. Если задача сложная, мы подключаем руководителей других отделов, логистики, склад итд., на выходе получается выверенная, согласованная схема, в которую все вложили свои знания. Эта схема и идет в работу как часть ТЗ.
Таким образом, ДРАКОН - это не замена эксперту, а его усилитель. Он не думает за людей, но он заставляет их думать вместе максимально эффективно, выявляя и устраняя «косяки и пробелы» на стадии проектирования, а не на стадии проваленного проекта.
в чём вишенка подхода?
И здесь мы подходим к главному - тому, о чем я уже писал в статье «Статья 3. Почему ваш бизнес хромает: история одного IT-ортопеда».
Корень большинства провалов - это глубинное сопротивление формализации внутри самой компании. Специалисты и руководители часто подсознательно саботируют четкое описание процессов, видя в этом угрозу своему авторитету или уникальности.
Мой метод работы с ДРАКОН-схемами - это и есть инструмент преодоления этого сопротивления.
Поскольку итоговая схема - это результат нашей совместной работы, где я, как аналитик, был лишь «ведущим» и архитектором формы, а руководитель отдела - полноправным автором и экспертом по содержанию, схема по сути становится его схемой. Она принадлежит ему.
Это полностью снимает ключевую проблему внедрения - личное сопротивление изменениям. Нельзя саботировать то, что ты сам создал и под чем сам же мысленно поставил подпись. Он не просто «согласовал» документ, он его родил. Эта схема - овеществленное доказательство его компетентности.
Поэтому такой документ уходит в работу не как очередная «отмашка от конторских умников», а как приказ, написанный кровью собственного интеллекта.
Предполагаю, что если вместо дракона взять, например, BPMN, то принципиально ничего в вашем рассказе не поменяется.
Основной компонент этого процесса именно аналитик. Он, как переводчик, должен уметь говорить с экспертом на языке бизнеса, а с разработчиком на языке программирования. И это, по определению, будут разные языки, иначе аналитик не был бы нужен, эксперт с разработчиком договорились бы и без него.
И если аналитику дракон помогает структурировать информацию, то ради бога, пусть пользуется. Но при этом не стоит утверждать, что BPMN тут работает хуже только потому, что аналитик его не знает. Именно с точки зрения бизнес-процессов BPMN показывает всё гораздо нагляднее дракона.
Вы абсолютно правы в главном: ключевой компонент процесса - это аналитик. Слабый аналитик не спасется ни ДРАКОНом, ни BPMN. Но давайте посмотрим, как именно инструмент помогает или мешает этому аналитику выполнить его главную задачу - быть переводчиком.
Вы говорите: «аналитик должен уметь говорить с экспертом на языке бизнеса». В этом и есть коренное различие.
BPMN - это язык ИТ-специалистов для ИТ-специалистов. Когда аналитик приходит к бизнес-эксперту с BPMN-диаграммой, он говорит с ним не на «языке бизнеса», а на «языке моделлирования бизнес-процессов». Это сложный, формализованный язык с чужеродными символами (шлюзы, пулы, дорожки). Эксперт интуитивно его не понимает. Он вынужден доверять аналитику, что тот всё правильно перевел. Это рождает ту самую «иллюзию понимания», которая приводит к 260 наггетсам.
ДРАКОН - это попытка создать гибридный язык, понятный обеим сторонам. Его сила не в том, что он «лучше для аналитика», а в том, что он меняет саму динамику встречи. Аналитик перестает быть «переводчиком с пришельца», который рисует непонятные схемы. Он становится «ведущим конструктором», который с помощью интуитивно понятных блоков и ветвлений помогает эксперту самому выстроить и увидеть логику своего процесса.
Вы утверждаете, что BPMN показывает всё нагляднее. Это справедливо для подготовленного взгляда - взгляда другого аналитика или разработчика. Но для бизнес-эксперта, чьё понимание - конечная цель, наглядность BPMN - это мираж.
Таким образом, я утверждаю, что ДРАКОН работает не «хуже» или «лучше» BPMN, а решает принципиально другую задачу:
Задача BPMN - детально и точно описать процесс для технической реализации.
Задача ДРАКОНа - обеспечить безошибочное, совместное с экспертом рождение правильного понимания этого процесса до начала реализации.
В сценарии с McDonald's, BPMN был бы отличным инструментом, чтобы задокументировать уже готовое и согласованное правило «не более 10 позиций». Но он не помог бы это правило выявить и формализовать на этапе обсуждения. ДРАКОН - помогает. Потому что он заточен не на документирование, а на выявление и структурирование знаний, и делает это на языке, доступном носителю этих знаний - бизнес-эксперту.
ДРАКОН - это попытка создать гибридный язык, понятный обеим сторонам.
Но это не требуется. Бизнес должен говорить на языке бизнеса. Разработчик - на языке разработчика. Аналитик - на обоих языках сразу.
Кстати, BPMN позиционирует себя практически теми же словами, что тут вы приводите для дракона:
BPMN is targeted at a high level for business users and at a lower level for process implementers. The business users should be able to easily read and understand a BPMN business process diagram. The process implementer should be able to adorn a business process diagram with further detail in order to represent the process in a physical implementation. BPMN is targeted at users, vendors and service providers that need to communicate business processes in a standard manner.
на выявление и структурирование знаний
Каким образом? Структурируя информацию? Так это делает любая схема, в любой нотации. Чем тут выделяется именно дракон - непонятно.
Заявляемые часто "безошибочность" дракона, его "показ пробелов в логике" - это всё пустые слова, не имеющие под собой никаких доказательств.
Вы поднимаете вопрос, который бьет в самую суть проблемы, объясняя, почему 95% сложных проектов терпят крах, а специалисты тонут в путанице взаимного непонимания. Философия языка ДРАКОН, которую В.Д. Паронджанов детально излагает в своей работе "Как улучшить работу ума", основана на фундаментальном принципе: «человеческий мозг, этот хрупкий сосуд разума, сталкиваясь с демоном науки, оказывается в крайне уязвимом положении - не выдерживая запредельной нагрузки, он получает вызванные стрессом многочисленные травмы».
Ваша модель - «Бизнес говорит на языке бизнеса, разработчик - на языке разработчика» - это классический пример «интеллектуального терроризма», пусть и непреднамеренного. Это система, которая «формирует систему моральных норм и социальных ценностей, а также систему прямых и косвенных стимулов и с их помощью навязывает человеку такой стиль умственного труда, который почти неизбежно или с высоким риском приводит к перегрузке». Она основана на иллюзии, что аналитик может быть безупречным «переводчиком», тогда как на практике он превращается в звено «испорченного телефона», порождающего «сопротивление материала» и «когнитивную перегрузку мозга».
Паронджанов пишет:
«Чтобы избежать опасных для здоровья перегрузок, надо уменьшить интеллектуальную нагрузку на человеческий мозг».
И именно эту задачу решает ДРАКОН, в отличие от BPMN, который эту нагрузку лишь усугубляет, создавая видимость понимания.
Чем же конкретно ДРАКОН радикально выделяется в структурировании знаний?
Эргономика и Симультанное Восприятие:
ДРАКОН - это не просто набор фигур. Это инструмент, который «прокладывает кратчайший путь к цели, взрывая логико-математические, алгоритмические и технологические скалы и препятствия динамитом наглядных картинок». В его основе лежит «принцип симультанизации»: замена медленного сукцессивного (последовательного) восприятия текста или сложных диаграмм на быстрое симультанное (одномоментное) восприятие целостного зрительного образа.Жесткий Синтаксис. Вы говорите, что «безошибочность» - пустые слова. Для ДРАКОНа это - инженерный принцип, доведенный до автоматизма. «Синтаксис ДРАКОНА... запрещает любые двусмысленности и неопределенности. Алгоритм должен быть записан так, чтобы его правильность проверялась автоматически, взглядом». BPMN допускает «рваные линии», неявные переходы и логические пробелы. ДРАКОН же железной рукой наводит порядок: «пересечения и обрывы соединительных линий запрещены», а любая незавершенная логика сразу видна как «висящий хвост», который «кричит о себе». Это и есть тот самый механизм «показа пробелов в логике» - не магия, а прямое следствие эргономических правил, которые «заставляют человека мыслить отчетливо, глубоко и продуктивно».
Не «Перевод», а «Мост Взаимопонимания». Совместное Мышление.
Ваша устаревшая модель «бизнес -> аналитик -> разработчик» — это дорога в тупик.
ДРАКОН предлагает принципиально иную парадигму: «бизнес + аналитик = ДРАКОН-схема -> разработчик».
Паронджанов подчеркивает:
«ДРАКОН можно определить как общедоступный визуальный язык... Это универсальный межотраслевой язык делового мира... который позволяет устранить или уменьшить барьеры взаимного непонимания между работниками различных специальностей... а также программистами и теми, у кого аллергия к любому программированию»
BPMN в этой аналогии - это чертеж на птичьем языке, который инженер (аналитик) с трудом интерпретирует для заказчика (бизнеса). ДРАКОН - это интерактивный план, который они рисуют вместе на универсальном языке действий и решений, где «шапка» силуэта мгновенно дает ответ на три главных вопроса: как называется проблема, из скольких частей она состоит и как называется каждая часть.
Таким образом, ДРАКОН выделяется не тем, что он «тоже структурирует», а тем, как он это делает. Через визуальную эргономику, согласованную с конструкцией человеческого мозга. Через принудительную логическую целостность, исключающую двусмысленности. Через ориентацию на прямое, без посредников-переводчиков, понимание со стороны бизнес-эксперта.
Это не вопрос вкуса или «еще одной методологии». Это - научно обоснованный когнитивный подход, нацеленный на «интенсификацию интеллекта» и ликвидацию тех самых ошибок, что превращают интеллектуальных работников в «камикадзе умственного труда».
Синтаксис ДРАКОНА... запрещает любые двусмысленности и
неопределенности.
Вот только дьявол в деталях. Внутри икон можно писать что угодно, и вот это что угодно может быть каким угодно двусмысленным, трёхсмысленным, бессмысленным.
Алгоритм должен быть записан так, чтобы его правильность проверялась автоматически, взглядом
Вот только правильность алгоритма - это не только его маршруты. Найдите "автоматически, взглядом" ошибку в абсолютно корректной с точки зрения дракона схеме:
Вот этой
Ошибка
Классическое состояние гонки между двумя конкурентными процессами, монопольно использующими одни и те же ресурсы.
«пересечения и обрывы соединительных линий запрещены», а любая незавершенная логика сразу видна как «висящий хвост», который «кричит о себе»
Нет пересечений - невозможно наглядно показать взаимосвязи процессов, что в бизнес-логике необходимо регулярно. Например, как показать, что несколько веток выбора обращаются к одной и той же базе данных? Текст не предлагать - это не наглядно.
Обрывы запрещены? В том же BPMN по правилам все потоки должны заканчиваться символом завершения (жирный кружок). Проверка встроена в редактор и места ошибок подсвечиваются. Так что "висящих хвостов" там быть не может.
BPMN в этой аналогии - это чертеж на птичьем языке, который инженер (аналитик) с трудом интерпретирует для заказчика (бизнеса).
Пардон, если аналитик не может говорить с бизнесом на языке бизнеса, то он плохой аналитик. Если он не может говорить с разработчиком на языке разработчика - он плохой аналитик. Если он не может переводить с одного языка на другой и обратно - он плохой аналитик.
Это - научно обоснованный когнитивный подход
Где можно почитать про научное исследование. Скажем слепое рандомизированное исследование (текстовой записи алгоритма, его же на драконе и его же на BPMN) хотя бы на несколько сотен участников и несколько десятков примеров? Без этого все слова о "научности" - маркетинговый буллшит.
Вы ставите вопросы, которые бьют в самую суть проектирования сложных систем. Но вы требуете от инструмента того, что он не может и не должен делать. ДРАКОН - это не серебряная пуля, убивающая все ошибки. Это когнитивный щит, который защищает мозг от перегрузки и заставляет ошибки проявляться там, где их можно найти, а не там, где они хорошо спрятаны.
Давайте разберем ваши возражения, поднявшись на уровень выше.
«Автоматически взглядом» - это про что? Про структуру, а не про семантику.
Вы абсолютно правы: ни один язык не устранит семантическую ошибку вроде гонки ресурсов или некорректной формулы «взглядом». Это физически невозможно. Но вы неправильно понимаете тезис Паронджанова.
«Синтаксис ДРАКОНА... запрещает любые двусмысленности и неопределенности».
Речь идет о структурной и топологической правильности. ДРАКОН гарантирует, что в алгоритме нет:
«Висящих хвостов» (незавершенных процессов).
Неучтенных ветвлений.
Неявных переходов, которые создают лабиринт.
Ваш пример с гонкой - это семантическая ошибка внутри структурно корректного блока. BPMN скрывает эту ошибку внутри Activity. ДРАКОН же выносит условие и логику на всеобщее обозрение, изолируя его в иконе «Вопрос» или «Действие». Это не «автоматическое исправление», это кардинальное облегчение поиска за счет декомпозиции. Ошибка не исчезает, но она перестает прятаться в грудном тексте или сложной диаграмме. Вы боретесь с ошибкой архитектуры, а ДРАКОН сначала гарантирует, что у вас вообще есть стены, а не груда кирпичей.
«Автоматически взглядом» - это про что? Про структуру, а не про семантику.
То есть, если я уберу все надписи, то только по внешнему виду вы поймёте, что правильно, а что нет?
Речь идет о структурной и топологической правильности.
Не путайте правильность и соответствие синтаксису. Правильность - это не просто "синтаксически корректно", это "работает правильно". А что касается "структурной правильности", то я вам могу на драконе нарисовать, например, неявный цикл со входом в середину этого цикла. Конечные автоматы (силуэт) ещё и не такие чудеса позволяют.
Прямые ответы на ваши вопросы уже даны в книге Паронджанова.
На ваш первый вопрос о «понимании без надписей» автор поясняет:
«Синтаксис ДРАКОНА запрещает любые двусмысленности. Алгоритм должен быть записан так, чтобы его правильность проверялась автоматически, взглядом»
то есть гарантируется именно структурная, а не семантическая ясность.
На второй вопрос о «неявных циклах» в книге указано:
«Любое нарушение логической целостности становится зрительно очевидным... ДРАКОН не позволяет ошибке спрятаться в хаосе».
Ваши возражения не опровергают ДРАКОН — они иллюстрируют его принцип: он не исправляет логику, но принудительно делает архитектурные flaws визуально кричащими.
Запрет пересечений - это не ограничение, это принуждение к ясности через эргономическую дисциплину
Вы утверждаете, что запрет пересечений лишает возможности наглядно показывать взаимосвязи. Это ключевое заблуждение, проистекающее из привычки работать в хаотичной среде. ДРАКОН меняет саму парадигму: он жертвует ложной, поверхностной «наглядностью» паутины связей в пользу глубокой, архитектурной ясности.
Представьте два подхода к описанию одного сложного процесса, например, обработки заказа, где несколько подсистем обращаются к единой базе данных:
Подход BPMN («паутина»): Вы рисуете несколько потоков, которые пересекаются, чтобы соединиться с одним объектом «База данных». Да, связь «наглядна». Но что вы видите? Вы видите проблему, а не ее решение. Эта паутина не отвечает на критически важные вопросы: в какой последовательности происходит доступ? Где точки конфликта? Каков протокол взаимодействия? Схема превращается в лабиринт, где мозг вынужден вручную, в сукцессивном режиме, отслеживать каждую линию, чтобы понять общую картину. Это и есть та самая «когнитивная перегрузка», против которой борется Паронджанов.
Подход ДРАКОНа («архитектурный чертеж»): Запрет пересечений принуждает вас к декомпозиции и созданию интерфейсов.
Вы не можете просто провести линию. Вы должны создать четко обозначенную икону-вставку (например, «Выполнить запрос к БД»).
Эту икону вы не «привязываете» куда попало, а включаете в логически завершенный маршрут.
Если обращений много и схема усложняется, ДРАКОН-методология заставляет вас вынести работу с базой данных в отдельный силуэт - самостоятельный, законченный алгоритм с четкими входами и выходами.
Что вы получаете в итоге?
Вы получаете не красивую, но бесполезную картинку связей, а архитектурный проект системы. Вы видите не «что связано», а «как организовано взаимодействие». Вместо хаотичной паутины — набор модулей с прозрачными интерфейсами. Это уже не просто схема, это модель решения, а не модель проблемы.
Этот запрет - краеугольный камень философии ДРАКОНа: «Любая сложность, которую нельзя изобразить без хаоса, должна быть перепроектирована». Это не ограничение творчества. Это высочайшая требование к инженерной дисциплине, которое превращает визуальный хаос в структурированное знание, пригодное для безошибочного понимания и реализации.
Эта паутина не отвечает на критически важные вопросы: в какой последовательности происходит доступ?
А почему она должна быть какой-то определённой? Когда вы описываете конечный автомат (силуэт), вы ведь не можете заранее предсказать, в какой последовательности будут вызываться состояния этого автомата.
Вы должны создать четко обозначенную икону-вставку (например, «Выполнить запрос к БД»
И? Как она наглядно покажет, к какой именно БД осуществляется запрос и откуда ещё есть запросы к этой БД?
ДРАКОН-методология заставляет вас вынести работу с базой данных в отдельный силуэт
Пардон, каким образом? Обращения к БД вовсе не обязаны быть одинаковыми. В разных ветках они могут выполнять разные действия с БД, но сама то БД будет одной и той же.
То есть дракон изначально не предназначен для показа связей между объектами и/или процессами. Иначе запрет на пересечение линий был бы невозможен. А такие связи это, зачастую, существенная часть в понимании бизнес-логики.
Вы продолжаете мыслить в парадигме старого подхода. Паронджанов прямо отвечает на ваш вопрос:
«Пересечения линий? - боже упаси! ... ДРАКОН выгодно отличается тем, что его графический узор имеет строгое математическое и когнитивно-эргономическое обоснование и подчиняется жестким и тщательно продуманным правилам»
Ваше требование "показать все связи на одном чертеже" — это и есть тот самый визуальный хаос, против которого борется ДРАКОН.
ДРАКОН не показывает связи - он показывает архитектуру. Если у вас множество разнородных обращений к БД - значит, у вас архитектурная проблема, и ДРАКОН принуждает вас решить её через:
Четкие интерфейсы (иконы-вставки)
Декомпозицию (отдельные силуэты)
Явные контракты между модулями
Вместо хаотичной "паутины связей" вы получаете систему с прозрачными взаимодействиями - именно то, что нужно для реальной разработки, а не для создания "красивых, но бесполезных схем".
Пардон, а вы сами программировали хоть раз? А с базой данных работали? В одной подпрограмме может быть произвольное количество разных обращений к БД. И это не проблема, это совершенно нормально. А уж когда мы расписываем не отдельную подпрограмму, а макроуровень программы, работающей с БД, то таких связей будет достаточно много.
К тому же, БД - это только пример. На её месте может быть, например, документ или другой процесс.
Вы правы - это вопрос инженерной дисциплины.
Паронджанов:
«Любая сложность, которую нельзя изобразить без хаоса, должна быть перепроектирована»
Ваш подход: «Описать систему как есть»
Подход ДРАКОНа: «Спроектировать систему как должно быть»
20 обращений к БД в одном модуле - не техническая деталь. Это архитектурное нарушение, которое ДРАКОН делает видимым.
Инженер не рисует трещины в конструкции - он проектирует так, чтобы их не было.
Научная основа: когнитивная эргономика - это и есть наука, а не обещание магии
Вы требуете слепых рандомизированных исследований с сотнями участников как единственное доказательство эффективности ДРАКОНа. Это серьёзная методологическая ошибка, выдающая непонимание того, на чем реально основан инструмент.
ДРАКОН - это не фармацевтический препарат, который нужно испытывать на тысячах пациентов. Это инженерное применение давно установленных законов когнитивной науки.
Паронджанов не изобретал новую магию. Он впервые системно применил к проектированию алгоритмических языков фундаментальные, воспроизведенные в тысячах экспериментов принципы работы человеческого мозга:
Закон Миллера (объем рабочей памяти): Человек может одновременно удерживать 7±2 объекта. Сложная BPMN-диаграмма с десятком пересекающихся потоков легко превышает этот лимит. ДРАКОН, через силуэты и ветки, дробит информацию на «когнитивно усваиваемые» порции.
Закон Хика (время принятия решения): Время выбора растет с увеличением числа вариантов. Хаотичная схема предлагает мозгу десятки «вариантов» для отслеживания. Упорядоченная структура ДРАКОНа с главным маршрутом и правилом «чем правее - тем хуже» радикально сокращает это время.
Гештальт-принципы (прегнантность): Мозг бессознательно ищет простые, упорядоченные, замкнутые формы. Хаос пересекающихся линий в BPMN нарушает эти принципы. Силуэты ДРАКОНа - это и есть «хорошая форма», которую мозг схватывает мгновенно.
Требовать от ДРАКОНа новых масштабных исследований - все равно что требовать от создателей самолета заново доказывать закон Бернулли. Принципы, на которых он построен, доказаны, проверены и являются краеугольным камнем современной психофизики и эргономики.
Более того, «лабораторией» ДРАКОНа стали проекты, где цена ошибки была жизнью или национальной безопасностью - «Буран», «Морской старт». Масштабное «исследование» уже было проведено - успешным функционированием этих систем. В таких условиях не опираются на «маркетинговый буллшит», а используют только то, что гарантированно снижает когнитивную нагрузку и минимизирует риск ошибки.
Таким образом, научность ДРАКОНа - не в обещании волшебства, а в строгом следовании известным законам работы мозга, которые были проигнорированы при создании многих других, более «гибких» нотаций.
ДРАКОН - это не фармацевтический препарат, который нужно испытывать на тысячах пациентов.
Как только вы вторгаетесь в область психологии - поздравляю, вы в медицине. И, поскольку речь идёт о человеческом восприятии, вещи достаточно субъективной, вам нужно слепое тестирование. Да, плацебо-контролируемого тут не сделать, но двойное слепое рандомизируемое вполне возможно.
Это инженерное применение давно установленных законов когнитивной науки.
Что такое "когнитивная наука"? Это точная наука или гуманитарная? В любом случае главный критерий в науке - эксперимент. Там, где он невозможен, как минимум должен быть статистический или математический аппарат, анализирующий факты (не домыслы).
Пока у вас ничего этого нет - нет и никакой науки.
Требовать от ДРАКОНа новых масштабных исследований - все равно что требовать от создателей самолета заново доказывать закон Бернулли.
Не обязательно. Но создатели самолёта вполне могут сослаться на конкретные законы и подтверждающие эти законы эксперименты и научные работы. Где научные работы в области "когнитивной науки"?
Вы смешиваете фундаментальную науку и прикладные испытания.
1. Когнитивная эргономика - это точная наука.
Её законы подтверждены тысячами экспериментов:
Миллер (1956) - объём рабочей памяти
Хик (1952) - время реакции при выборе
Гештальт-психология (1920-е) - принципы восприятия форм
Паронджанов не изобретал эти законы - он применил их к проектированию языков. Требовать новых исследований для ДРАКОНа - как требовать перепроверки законов физики для каждого нового самолёта.
2. Лабораторией ДРАКОНа стали критические системы:
«ДРАКОН разработан совместно Роскосмосом и РАН как обобщение опыта создания корабля "Буран"... Успешно используется в проектах "Морской старт", "Фрегат", "Протон-М"»
(Паронджанов, раздел о практическом применении)
В таких проектах не используют непроверенные методы. Факт успешного применения в системах с нулевой терпимостью к ошибкам - лучшее доказательство эффективности.
3. Ваш запрос игнорирует главное:
ДРАКОН - это инженерная реализация известных законов. Как самолёт строится на законах аэродинамики, так ДРАКОН построен на законах когнитивной науки. И так же, как самолёт летает без "слепых испытаний против воздушных шаров", ДРАКОН работает в реальных проектах.
Вывод: ДРАКОН это философия «когнитивного щита», а не «серебряной пули».
Спор сводится не к тому, какой инструмент «круче». Речь о выборе парадигмы. BPMN и подобные нотации стремятся к максимальной гибкости, рискуя породить визуальный хаос, который мозг не может обработать без перегрузки. ДРАКОН сознательно жертвует этой гибкостью, навязывая железную дисциплину, которая защищает интеллект разработчика.
Он не обещает найти все ошибки. Он создает среду, в которой ошибкам негде спрятаться среди хаоса линий и неявной логики. Он не заменяет мышление - он его структурирует, освобождая ментальные ресурсы для решения по-настоящему сложных семантических проблем, а не для расшифровки лабиринта. Требовать от него невозможного значит не понимать его главной цели: не нарисовать «всё как есть», а принудительно привести мысль к ясности, сделав сложное - обозримым, а запутанное - структурированным.
От визуализации к действию: как ДРАКОН+LLM может стать фундаментом для агентских ИИ