пятница, 2 августа 2013 г.

Заметки про наш кодогенератор. Надеюсь - Макс - будет НЕ против

Отдельно про "собственный кодогенератор".

1. Он скорее "декларативный" нежели "императивный".
2. Построен на "продвинутых regexp". Очень продвинутых. С включениями
"императивного кода".
3. Использует понятие user-section. Это места в "скелете кода" куда
программист "вписывает логику" не описанную на модели.
4. Базируется на понятии <<стереотипа>>. Стереотип это - "единица
генерации". SimpleClass, Enum, Form, Project, Library, Algorythm etc. И
каждый стереотип может генерировать "свой код".  И в СВОЙ файл - если нужно.
5. Экземпляры <<стереотипов>> нарисованные программистом могут
"предварительно генерировать" ДРУГИЕ стереотипы.
Например <<property>>
от <<SimpleClass>> могут генерировать <<method>> (методы доступа к
свойству). Или <<LocalizeableConst>> генерирует <<Const>> И массу
других. Уже без вмешательства "пользователя". А потом вся эта
конструкция генерируется в целевой язык.
6. Настраивается на практически любой "текстовый язык".

P.S. многие решения настолько "банальны", что мне иногда хочется
поверить в "теорию заговора". Что "киты" типа  MS или IBM - сознательно
не публикуют своих разработок в плане UML. Потому, что я иногда не
понимаю - "как мои коллеги до этого додумались", а "киты" - нет. Просто
не верится в это.

7. ОТДЕЛЬНО умеет генерировать в wiki-подобную базу знаний. Это скажем
так - отдельный "целевой язык" кодогенерации.
8. С элементами кода в этой базе умеют связываться
требования/задачи/ошибки. "Сверху". А также - изменения кода - "снизу".
Взяв отдельно взятый "элемент кода" (экземпляр <<стереотипа>>). Мы
"сверху" можем видеть - "какие запросы его меняли", а "снизу" - можем
видеть - "какие строчки кода менялись в результате этих запросов".

P.P.S. Я в его написании - участия не принимал. Я только шаблоны
кодогенерации потом писал. 

30 комментариев:

  1. Что включает в себя понятие "продвинутые regexp"? Имеете в виду look-ahead-, look-behind assertions или исполнение кода внутри регекса?

    ОтветитьУдалить
  2. Приведу один прикольный регекс из своего скрипта (скрипт вырезает комментарии из текстов Консультанта):
    $doc =~ s/(^-{66}\n)(?:(?:^(?!(?:[\d¦(]|[а-яa-b]\)|[^"]{1,13}[XХVI\d]\.\h|$exceptions)).{20,}\n#|^\n)+\1)+(?{$c++; print COM "$&\n"})//mg;

    ОтветитьУдалить
  3. Дмитрий, скажу, как коллеге. Вы уж очень "практически" это воспринимаете. Хотя это неплохо.

    Что такое БНФ знаете?

    Так вот наши "продвинутые regexp" это - БНФ с циклами, if И возможность "вызова функций".

    regexp это - метафора.

    Если интересно - дальше - лично.

    ОтветитьУдалить
  4. Понятно. Я использую perlовые регулярки (под .NET регексы тоже а-ля Perl). Считается, что это не BNF.

    ОтветитьУдалить
  5. Ну а у нас - БНФ.. хотя это тоже - "метафора"...

    Хотя "направление ваших мыслей - мне нравится" :-)

    Вам-то - вы понимаете - я могу рассказать многое... Если интерес есть...

    ОтветитьУдалить
  6. Все, что связано с обработкой текста, мне безусловно интересно.

    ОтветитьУдалить
  7. Пишите - расскажу.. Никакой "магии" там нет...

    ОтветитьУдалить
  8. "Экземпляры <> нарисованные программистом могут
    "предварительно генерировать" ДРУГИЕ стереотипы."

    - кто играл в компьютерные игры типа RTS или RPG - тем будет понятен термин "summoning" - когда одни сущности "для своей реализациии" - summon'ят другие. Вот о чём речь."

    ОтветитьУдалить
  9. Поясню... У вас есть "тролль" он умеет summonitь "орков".. мысль понятна? Более высокоуровневые сущности УМЕЮТ порождать более низкоуровневые....

    ОтветитьУдалить
  10. в наименовании поста, перед последним словом "НЕ" пропала :)

    ОтветитьУдалить
  11. По поводу "кодогенератора": есть вопрос:
    допустим некий класс (это в терминах UML - метамодель? или статическая диаграмма?)
    каким то способом ссылается на второй, второй ссылается на 3-й, третий на первый...
    Кодогенератор так не зациклится?...

    ОтветитьУдалить
    Ответы
    1. кодогенератор (имел в виду) сферический в вакууме...

      Удалить
    2. Нет, в нем стоит проверка на это, при том хитрая учитывающая тип связи. Если связи с жестким типом (например агригация в стили с++), и они образуют цикл, то генератор просто выругается что модель не валидная. Если среди связей есть "мягкая" (например, ссылка в стиле с++), товсе будет ок, но граф использлования перестроится так что сначала будут идти жесткие связи а в конце мягкая. Жесткость связей задается на метауровне (ну те там где описываем метамодели и определяем стереотипы связей)

      Удалить
  12. Нет, в игры я не играю, но кодогенерация вещь интересная. Несколько лет назад писал что-то: автоматическая генерация NSR по пользовательским шаблонам. Это нужно было для пакетной обработки однотипных документов. Например, нужно быстро ввести 100 похожих документов (одного эмитента), при этом 90% действий в Арчи повторяется, на что тратится куча времени. Программа автоматом генерировала NSR по простому шаблону, прописанному в текстовом файле, позволяя вводить 100 документов за 5 минут. Вроде, все сделал, но тогда запнулся на конвертации таблиц rtf->nsr, поэтому программка работала только на документах без таблиц. P.S. да, я практик.

    ОтветитьУдалить
  13. И еще в Delphi-7 был когда то BOLD, куда все делось?
    http://www.compress.ru/article.aspx?id=10138&iid=413

    ОтветитьУдалить
    Ответы
    1. про Delphi - не к нам.....
      Пните - Embarcadero...

      Удалить
    2. Не один BOLD. В .NET-овских версиях Delphi, начиная, кажется, с 8-й, были еще ECO - Enterprise core objects (http://edn.embarcadero.com/delphi/eco). И вот там были и MDA с UML, и object persistence. Но работало только в .NET-приложениях. Соответственно, и выпилили его вместе с .NET-ом из Delphi.

      Удалить
    3. Не один BOLD. В .NET-овских версиях Delphi, начиная, кажется, с 8-й, были еще ECO - Enterprise core objects (http://edn.embarcadero.com/delphi/eco). И вот там были и MDA с UML, и object persistence. Но работало только в .NET-приложениях. Соответственно, и выпилили его вместе с .NET-ом из Delphi.

      Удалить
  14. А почему ты надеешься что я буду "против" ;)

    ОтветитьУдалить
    Ответы
    1. Я - не "надеюсь"... Я - сомневаюсь... Ведь ты же - "отец-основатель"..

      Удалить
    2. я не против :)

      Удалить
  15. http://dou.ua/lenta/articles/mda-introduction/ - вы идете по этому пути :)

    ОтветитьУдалить
    Ответы
    1. Так что вы немного опередили время :) мир только на пути к этому а Вы уже применяете на практике :)

      Удалить
    2. Мы - ЛУЧШие - "напялю на себя Шляпу Гуру"...

      Удалить
  16. >"Не является ли использование подобных техник и просто необходимость «договариваться» индикатором того, что есть проблемы в распределении «зон ответственности» в коде? Зачем договариваться и согласовывать, если можно чётко разграничить, кто какие классы/методы разрабатывает, а кто их использует? Я делаю болты, Вася – гайки, а Жора свинчивает ими две детали. Какие детали? Да без разницы, мы чётко поделили зоны ответственности. Почему это в области разработки ПО не работает?"

    Всё таки этот вопрос для меня остаётся открытым. Неужели создание проекта с низкой связанностью, разграничением обязанностей, API и вообще KISS в вашем случае не работает? Речь не идёт о поломке обратной совместимости, её в принципе не должно быть(это я к примеру с гайками).

    Могу добавить что графические нотации для меня значительно(в вашем коде я даже предпочёл чтение самого кода) сложнее воспринимаются, чем обычная документация(возможно это дело привычки).

    Как в кодогенерации решается проблема разных возможностей языков? Модель приводится к "общему знаменателю"? Т.е при генерации используются лишь те возможности, которые есть во всех целевых языках?

    ОтветитьУдалить
    Ответы
    1. > Как в кодогенерации решается проблема разных возможностей языков? Модель приводится к "общему знаменателю"? Т.е при генерации используются лишь те возможности, которые есть во всех целевых языках?

      ХЕ-ХЕ ))
      Вот в том-то и щтука, что за счет использования шаблонной кодогенерации, ЛЮБОЙ один язык можно привести к ЛЮБОМУ другому языку (признаюсь, я сейчас скорее теоретизирую, тк такой практической задачи в полном объеме не было). Согласитесь, что любая возможность любого языка это не более чем способ сократить страдания разработчика, но не принципиальная не возможность решить какую-то бизнес-задачу. Да, на одном языке для этого нужно будет воспользоваться его встроенной возможностью, написав "одну строчку кода", а в другом, где такой возможности нет, для реализации схожего поведения придется написать "небольшой фреймворк", десяток классов, и хитро-заковыристо их использовать "по месту". Дык вот все это и можно (и нужно) засунуть в шаблон, и тогда на модели что в первом что во втором случае это будет "одна галочка/стрелочка/метод/..), а вот при кодогенерации превращаться будет в разные вещи.

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

      Удалить
  17. 1. Вы писали проекты сравнимые хотя бы с Word?
    2. Сколько в них разнородных сущностей?
    3. Сколько ответственностей в среднем на сущность?
    4. Сколько UseCase'ов верхнего уровня в системе?
    5. Каков объём требований?
    6. Сколько экранных форм?
    7. Сколько людей в среднем в проекте?

    ОтветитьУдалить
  18. "Могу добавить что графические нотации для меня значительно(в вашем коде я даже предпочёл чтение самого кода) сложнее воспринимаются, чем обычная документация(возможно это дело привычки)."

    Конечно. Там - микро-уровень. Было бы странно - если бы вы не прочитали код. Про масштабирование только - похоже вы не очень внимательно прочитали.

    ОтветитьУдалить
    Ответы
    1. "Как в кодогенерации решается проблема разных возможностей языков? Модель приводится к "общему знаменателю"? Т.е при генерации используются лишь те возможности, которые есть во всех целевых языках?"

      Тут бывают РАЗНЫЕ мнения и РАЗНЫЕ ответы. Мой ответ - надо смотреть по месту.

      Удалить