Принцип Алгоритмической инвариантности История

Алгоритмическая инвариантность (История вопроса).

 Каким образом можно реализовать Идею алгоритмической инвариантности в нашем конкретном случае?

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

Иконки реализации(или реальности?) должны быть бледными, они относятся к вспомогательной визуальности и не имеют права мешать восприятию алгоритма.

Теперь бы ещё это вспомогательное хозяйство куда-то пристроить? Видится два варианта, но в принципе, это уже непринципиально)).

Таким образом, расширяем набор понятий, вводя "иконки реальности", "связи реализации" и "алгоритмические иконы" - это те, что раньше было просто иконами.

Как конкретно привязать реализацию к алгоритму? Ну, например так:

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

  

Попробуем исполнить задуманное. Сначала выполним один фокус. Переделаем получение рабочего кода не напрямую, а через функцию geReleaseCode().

Затем в текстовом редакторе заменим прямое обращение на вызов функции geReleaseCode(). Дальше - ГПП(Генерим-Проверяем-Правим).

Теперь немножко модифицируем нашу функцию, чтобы она брала код требуемой в результате реальности:

На мой вкус, вполне себе симпатичненько, а именно это и есть единственно ценное в деле визуального программирования. 

Ну, хорошо, это всё сказки и теория, пора сделать тестовый пример. Задача, сварганить такую Картинку, которая превратится в исполняемые классы на AS и Java. Задача предельно проста, т.к., по структуре языки - близнецы братья.

Долго "чесал репу" где разместить выбор реальности. Нашел хорошее решение: икона "Начало"

А классно,  выбираем реальность в два щелчка мышы. :)) 

Но этого мало. Немного модифицируем код. Нужно чтобы при выбранной реальности не выбирался код из самих икон(код по-умолчанию) А он должен браться только когда реальность не выбрана.

"Трое из ларца"

Поэтому модифицируем функцию возврата кода

Добавляем иконки Java-реализации, заполняем их кодом, переключаем выбор реальности на Java и генерим первый class.

Код получился несколько неожиданный и понятно почему, я не предусмотрел выбор реальности для автоматического текста и хотя для java это не страшно, в будущем надо будет поправлять. (Не забывать в IDE выставлять кодировку редактора UTF-8)

Попытался сделать иконки реализации совсем бледными, но глаз их всё равно видит! Что-то не нравится мне этот вариант.

Но возможны ещё варианты, например как у Геннадия Тышова

Пока, решил на разных "шампурах" попробовать разные стили и так пожить. Жизнь сама подскажет, какой вариант лучше. (UPD: Спустя некоторое время, жизнь показала полную несостоятельность первого варианта!)

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

Так. Обнаружилась необходимость в существенном изменении. Похоже, придется выкидывать всю автоматическую вставку в код служебных слов. Всяких "if", "else", "for", "for each". Проку от них мало, а вот проблемы возникли. "for" - "for each" для двух языков не проходят.

Вырезал кусок кода и от этого диаграмма только упростилась:

Неприятности. Эх, не уложиться в одну неделю... Случились две неприятности, превая небольшая - обнаружилось, что автоматическая вставка break в case в случае появления return перед break  вызывает ошибку компиляции в Java, но это чепуха по сравнению со второй проблемой - библиотека Blueprints, которую я взял для разбора graphml не возвращает Node Label в которой у меня записывается комментарий к коду. Теперь или искать другую библиотеку или писать свой разборщик graphml. Оказывается в старой версии на AS пришлось писать свой парсер graphml, а я уже и забыл.... Млять, обидно, это ещё потеря пары дней...

Уф... Перепробовал кучу библиотек (JGraphT, Prefuse, Gephi, JUNG), а в результате остался на Blueprints, как наиболее удобной. Но, увы, ни одна из этих библиотек не может прочитать yEd формат так как мне нужно. В результате, пришлось таки писать свой парсер(использовал как образец классы cytoscape GraphMLReader). 

И вот наконец, после двух дней чумового кодирования на низком уровне я опять поднялся(на свет божий) на уровень кодограмм! Кайф...

Продолжаем перевод в новую реальность. Для этого к каждой иконке приколол иконку реальности с кодом на java.   

"Сеанс иглоукалывания дракона"

Отпарсил сгенеренным DG2J тестовый пример. Последовательность обхода верная.

Что забавно, так это то, что получается великолепно документированный код. Но теперь это почти не нужно.))

Ура! Наконец-то, DG2J генерит сам себя! 

Эта версия достойна гордого названия 0.9.4 :)

и текущий вид кодограммы:

Спасибо жене и дочке что улетели на море, спасибо, что на работе временный застой, спасибо, что не подвернулась шабашка! Как говорится, всем спасибо, все свободны! А мне пора ремонтом автомобиля заняться. :) 

И в заключении, традиционное фото на память для молекулярной компьютерографии. :)

16.10.2014 Окончательно отказался от DG2A. Принцип Алгоритмической инвариантности соблюден и проверена его правильность, а поддерживать два кодогенератора - лишний гемор. В принципе DG2J гораздо удобнее, т.к. на Java.  

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

Выражения для каждого варианта можно хранить в иконе Точка сборки. Например  в ТС-JAVA включаем Settings.setProperty("LANG_ELSE", "} else {");  В ТС-PLSQL  Settings.setProperty("LANG_ELSE", " END ELSE BEGIN ");