DRAKON.SU

Дано:
1. графическая схема алгоритма (программы) в неком графическом редакторе
2. текстовый код (программа на каком-либо ЯП), соответствующий этой графической схеме
Цель:
Нажатием одной (в идеале) клавиши переключиться из графоэлемента схемы на соответствующий ему участок кода. То есть графическая схема рассматривается как спецификация к файлу кода.

Редакторы Тышова и Митькина предполагают механизм генерации (сборки из фрагментов соответствующих графоэлементам) кода для разных языков программирования. Задача создания каждого такого механизма не проста. Каждый ЯП имеет множество нюансов и к тому же склонен к развитию. Более того, каждый программист использует данный ЯП по своему усмотрению, предпочитает разные его возможности. Имеем наложение сложностей: бесконечно возрастающего числа ЯП, бесконечного числа личных предпочтений их использования и, по-видимому, бесконечного числа возможных графических синтаксисов. Таким образом, смею предположить, что проблема генерации кода представляет собой проблему "вечного двигателя" 3-го (или какого там по счёту) рода. То есть потенциально она разрешима, актуально нет. Окончательное решение всегда будет отодвигаться. А пока суд да дело, хотелось бы иметь механизм переключения графика <-> код. Предлагаемое "изделие" работает только в одном направлении: графика -> код. То есть прыгаем из графоэлемента на соответствующий ему (помеченный) участок кода, но из помеченного участка кода не можем найти любой соответствующий ему графоэлемент, а возвращаемся только в прежний. В полной мере данный функционал могут реализовать разработчики самих графических редакторов. Для этого графический редактор дожен иметь встроенный полноценный пофайловый текстовый редактор и внутренний механизм поиска по графоэлементу текста и по участку текста соответствующий графоэлемент. Полагаю эта задача проще задачи синтеза кода из кусков. В то же время решение её сразу позволяет работать с любым языком программирования, в котором только есть возможность комментирования, то есть практически с любым. Между прочим этот механизм используется в Delphi, там по F12 прыгаеем из визуального элемента в код и обратно. Но заточено под конкретику Delphi среды, а для нужд Дракона требуется универсальное решение.

Предлагаемый механизм конечно не снимает задачу произвольной сборки текста по графоэлементам. Это совсем другая задача.

Скрипт switch.ahk изготовлен на известном бесплатном http://www.autohotkey.com/ с использованием его самого (в качестве примера) и ИС Дракон под не менее известный Notetad++ http://notepad-plus-plus.org/. Тестировался под yEd, ИС Дракон, Drakon Editor 1.9, Explain, City.

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

Вот, уже что-то!
Но все равно не то, что хотелось бы.
В идеале должна быть неразрывная связь между текстом программы и её графическим отображением, тождественное равенство, согласно Паронджанову.
И в идеале это должно выглядеть так:
добавляем текстовый блок - на визуальной дракон - схеме появляется новая икона.
Вставляем икону или любой элемент - тут же видим изменение в тексте.

Как мне кажется, для этого можно совместить описание текста и графики в одном файле исходного кода.
То есть, код - как обычно, а дракон - описание в виде специальных тегов в блоках комментариев.
Причем, необязательно там выкладывать все параметры графики, достаточно ID иконы и её комментарий, а остальное (расположение, стили и другие подобные параметры) - отдельно либо в конце файла, либо рядом, примерно как таблицы стилей CSS в HTML. Ну или XML.
Doxygen тоже хороший пример.

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

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