Интерпретация визуального алгоритма

Много думал о подобной задаче, к сожалению только "на бумаге". Главное ключевое слово "Визуальное программирование". Я довольно слабый кодер и первое, что мне приходило на ум, это не зарываться в железную часть, а сделать все топорно. Предоставьте пользователю разные типы блоков:

1. Объекты в виде плашек (объект, массив, число, строка)
2. Операции над объектами (перебрать список, мат. операции и т.д.)
3. Блоки вывода. (напечатать в консоль, тост)

Как бы я реализовал: По сути каждая плашка, класс, наследник какого то интерфейса. У плашки есть возможности. Ей, что-то нужно и она что-то может.

Плашка "перебрать список" (class Iteration (val list: List<Object>) : Operationable). Ей нужен список, она может применить математическую операцию к элементам списка.

Напрашиваются несколько слоев, вам нужно будет реализовать визуальную составляющую, она предоставит ваш внутренний псевдокод, который вы делегируете вашему интерпретатору. Он будет использовать нужный класс в зависимости от команды.

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

Не знаю, как насчет библиотек, но если бы я работал над такой задачей, я бы её разделил на части:

Модель

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

Например, выражение if (X > 10) then A else B - будет представлено узлом с одним входом X и 2 выходами. В зависимости от вычислений сигнал может отправляться в выход A или B.

Заметье, что я ещё ничего не писал про графическую составляющую. Модель, что я описываю, можно применять хоть в консольном приложении.

Также повторюсь, модель - это только данные о узлах и их связях. То есть должно быть абсолютно безопасно всю модель сохранить в файл/базу или загрузить из файла/базы или просто передать по сети.

Среда

Чтобы модель запустить, нужна среда, в которой она будет работать. То есть, взаимодействие с моделью будет происходить через среду выполнения. Хотите подать сигнал - подаете его среде, среда вызывает методы модели, чтобы просчитать все входы и выходы, и выдать обратно результат.

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

Ну, или, например, вы сможете запускать разные типы моделей в одной и той же среде. Всё зависит от ваших требований, тут чисто полет фантазии.

UI

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

При разделении задачи на такие части, каждая часть будет отвечать за своё и их можно разрабатывать по очереди или параллельно. Достаточно добавить пару узлов в модель и можно начинать строить среду и UI.

Модель при этом не будет привязана к UI, вы сможете построить другой UI по мере надобности, при этом переиспользовать готовые наработки для модели и среды.

Есть (вернее был) такой тул Rational Rose. Был очень популярен лет надцать назад.

Смысл был в том, что прогер/юзер накидывал UML диаграмму и в итоге генерировались исходники на Java. Покопайте в ту сторону.