DRAKON.SU

Развитие схемы идёт в соответствии с основным принципом ДРАКОНа: "симметрия порядка" или "упорядочивающая ассиметрия" слева направо сверху вниз.
Конечный результат- ИЗДЕЛИЕ, код (текст) которого собирается потом сборщиком.
На ШИНЕ ТИПОВ "висят": ТИПЫ, которами могут быть АЛГОРИТМЫ, КЛАССЫ, ТИПы- рекурсивно. А также болты, гайки и проч. детали если изделие не программа, а что-то иное. Конкретное значение типа (переменная, массив переменных, список переменных- и т.п. объект данного описанного типа) крепится справа к ШАМПУРУ ТИПА, чтобы отличалось от действия, которое шампуром протыкается.
Множественное наследование по-видимому тоже можно сюда вписать (перевёрнутое дерево).

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

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

Ох извините но кажется вы всетаки хватанули
Дракон все таки маршрутный язык.
Что например выражают циклы на концах шампуров?
Я бы еще понял ЮМЛьное дерево классов развернуть на драконе.
Там хоть какие то глаголы применяются:
Линия произошла от точки, окно произошло от абстрактного окна
У нас есть две конструкции ветвления иф-элс и свич.
Видимо здесь свич будет уместнее, короче пробовать надо.
За попытку спасибо!

Лишнего из лейденской банки? "Циклы" здесь выражают "некий алгоритм", это краткий обобщающий образ.
Здесь путаница понятий- маршрута и процесса. ДРАКОН маршрутный язык, он задаёт маршрут, но маршрут чего? Что, какой такой объект движется по ДРАКОН-маршруту? Ответ: НАШЕ ВОСПРИЯТИЕ. Восприятие чего, непременно процесса? А почему не восприятие статического структурированного оъекта? Применение ДРАКОН-метода исключительно к моделированию процессов есть самоограничение вызванное инерцией мысли. Откуда оно берётся: исторически блок-схема появилась как модель вычислительного процесса. ДРАКОН-метод это открытие в области эргономики, полученное в результате экспериментов с блок-схемами процессов. Так же как гены это открытие в результате экспериментов с горохом. Поэтому применять ДРАКОН-метод исключительно к процессу это то же самое что генетику исключительно к гороху.
Если что-то произошло от чего-то, то это описывается деревом. Изобразить дерево можно по-разному. UML-изображение дерева не маршрутное. ДРАКОН-овское маршрутное, оно упорядочивает. Тем и выигрывает у UML эргономически.
IF и SWITCH - это частные случаи ветвления, а именно они ветвление по условию. Эти частные случаи представляются общими опять таки по причине родового происхождения ДРАКОН-метода от ОДНОПОТОЧНЫХ вычислительных процессов, в пределах которых они действительно общие и достаточные. И опять таки та же инерция протестует против глобально общего случая - безусловного ветвления, просто дерева. Его я и добавил. Никаких особых икон это не требует. Но сразу "бесплатно" открывается возможность ДРАКОН-отображения не только статических сущностей, но и параллельных процессов ("висят" вместе на одной шине типов) и дочерних (те что на локальной шине типов главного процесса).

Декларативная информация изображалась в структурированной форме совместно с алгоритмом в системах HiChart, LogiChart (см. сообщение тут)

Кстати, очень интересный материал, спасибо... но и для такой формы неочевидно прослеживание хода процесса.
Всё-таки м.б. оптимальнее не совместное, а раздельное отображение импер- и деклар-частей своими схемами со связкой через объявления (а в модулярных языках - и через схему модулей, например, такого рода, как здесь для Оберона)?

+ неочевидна возможная динамика по данным.

Недостатки, естественно, есть. Большинство из них напрямую связано с используемой грамматикой.