Принцип Лифта

(обновлено 14.11.2014)

"Лифт, он тебе не нипель и не диод, он ездит туды-сюды,

 и доставляет всем. И вверх доставляет и вниз..." 

(из разговора дракон-джаз программистов)

Итак, на горизонте вырисовывается трехуровневая архитектура. На верху - мир идеального, возвышенного, мир диаграмм и графов. Внизу, приземленная реальность, конкретика кодов и сред разработки. Между ними - промежуточный слой(ДраконГен), тот что доставляет коды. Пока что все сформулированные принципы построения системы относились только к верхнему уровню, но пора установить рамки приличия и для среднего. 

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

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

 <DG2J code_marker="имя узла:уникальный признак">

...

Синхронизуемый код

...

</DG2J>   

Например, на верхнем уровне есть такой кусочек кода:

вводим маркер кода

теперь код выглядит так

Если мы запустим процесс реверскодинга, то внесенные в текст программы изменения  будут подняты "наверх". Тут важно отследить возможные нарушения уникальности маркеров и это нужно сделать перед реверскодингом.

Ну, а до реверсинжиниринга дело тоже когда-то дойдет(может быть)).


19.10.2014

После того как написал и реализовал алгоритм "Замена маркированного кода" удалось выполнить реверскодинг для тестового класса Test. Конечно, правильнее было бы не писать такой алгоритм, а воспользоваться стандартной обработкой XML. Но было интересно попробовать Дракон-Джаз в работе. Выяснилась интересная деталь, Оказывается, визуального языка Дракон мало! Нужны вспомогательные средства визуализации, как при работе с алгоритмом  "Замена маркированного кода". Потому, что с первого раза написал этот алгоритм с ошибками и только после того, как разрисовал структуру маркеров и данных, все получилось с первого раза.

Изменения в коде

после реверскодинга отобразились в кодограмме

Интересно, что при копировании участков кодограммы через буфер обмена в новую схему маркеры не переносятся. В пределах одной кодограммы всё переносится корректно. 

20.10.2014 Реверсинжениринг

Показал одному коллеге кодограмму Дракон-Джаза, тот посмотрел, спросил, как я её построил и когда услышал что ручками, изобразил на физиономии полное разочарование и унылый скепсис.  Ах, ты зараза такая! Вам разжевать всё надо, да ещё в рот положить...

Однако сел я за "грузовой лифт". Первый результат обнадеживает, но пока до успеха далеко.

Чёта ржу, сижу весь запутался в проводах :)))

  

21.10.2014 Уф, ну малость подразобрался с проводами

хотя нарисовано неверно, должно быть так:

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

кодограмма реверинжениринга(lift up)

Сразу многое становится нагляднее

А это кодограмма обратного процесса кодогенератора(lift-down), само собой выглядит абсолютно не так как в ручном исполнении, но пока здесь кроме действий и решений ничего нет.

"рукописный" оригинал выглядит так:

24.10.2014 

Ещё немного в реверсе продвинулся. Сделал реврсинжениринг Драконгену. Можно сравнить, как выглядит рукописный и автоматически воссозданный ваианты.

это фрагмент рукописной кодограммы DrakonGen_а

а это "машинописный" вариант(ничего не подправлялось)

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

29.10.2014

Столкнулся с неприятностью в реверсе внутренних классов(классов определяемых внутри классов). Если перед определением внутреннего класса стоит процедура, то происходит пересечение. 

Единственное решение, которое приходит в голову - принудительно перемещать все внутренние классы вверх.

Когда внутр классы выше процедур, то всё выглядит прилично

 Ещё одна пэрэмога.  Добавил обработку switch

И ещё пэрэмога, всяческие циклы:

30.10.2014 

Плюс try - catch

Плюс вызов метода, плюс описание метода

05.11.2014  

Подзадолбался немного со switch-case. Например, два case на один шампур насаживал целый день(с перерывами на жизнь), 

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

12.11.2014 

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

 а во-вторых, оно мне не нужно(пока). Так что, увы, в этом вопросе можно констатировать поражение. 

Временно ограничимся простыми ситуациями. 

14.11.2014 

Всё. С реверсом покончил.