DRAKON.SU

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

Дракон стал заложником своей естественности и универсальности, что наводит на мысль о разделении его на две ветви. Первая- это язык рассуждений а-ля поиск узких мест в бизнес-процессах, пример этого описан в статье. Вторая- это язык программирования. И тогда всё встаёт на свои места: рисовалки нужны для изображения тех же бизнес-процессов, а для программирования нужен ЯП с IDE, реализующий весь цикл разработки ПО.

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

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

Можно ли гипотетически объеденить Бизнес процесс и исполнение в одной системе, через Дракон описание и исполняемый Дракон код?

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

Но ведь технически вы сами писали в первом сообщении что в IDE можно описать Бизнес процесс
Тогда получается Бизнес аналитик вместе с бизнесом написал процесы как надо в Дракон схеме на определённом уровне.
На уровне исполнения (я предлагаю пирамидальную структуру описания) програмист написал код на Драконе и вот моя хотелка осуществилась.

Разве в моём рассуждение есть логические ошибки?

Конечно, есть.
Я ведь текст программы могу нарисовать в Paint, но это не значит, что его можно скомпилировать.

Вот именно, для описания. Никто не запрещает использовать из всей IDE только редактор без всего остального.

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

Конечно я с вами согласен.
Одно дело если мы описываем процесс "как есть" и тогда возникает "пропасть", на самом деле конечно не "пропасть" а возможность сделать ТЗ для руководителя, кто этим документооборотом заведует.
Руководитель и бизнес аналитик могут спокойно в Драконе смоделировать новый процесс и отдать его в Дракон схеме как готовое ТЗ для программиста.
Именно такими делами я и занимался на протяжени 5 лет.

Но если посмотреть на важность бизнес описания, то часто получается что без описания (без визуальной схемы процесса "как есть") не возникает понимания что и где поменять.
В итоге из своего опыта:
Есть одна общая схема процесса "как есть" она срез текущего состояния
есть в этом процессе внутри подпроцессы в разной степени разработки и реализации.
Например в схеме есть задача проработать этот участок с руководителем кадров.
После проработки возникает ТЗ для программиста, который выполняет эту работу.
И чем это не сквозная работа от проектирования процесса верхнего уровня до выполнения процесса программистом в коде
То есть по сути Дракон схема может быть системой управления и бизнес аналитиком и руководителем отдела и программистом в итоге.

И причём здесь Paint?