Отдельно про "собственный кодогенератор".
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. Я в его написании - участия не принимал. Я только шаблоны
кодогенерации потом писал.
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. Я в его написании - участия не принимал. Я только шаблоны
кодогенерации потом писал.
Что включает в себя понятие "продвинутые regexp"? Имеете в виду look-ahead-, look-behind assertions или исполнение кода внутри регекса?
ОтветитьУдалитьПриведу один прикольный регекс из своего скрипта (скрипт вырезает комментарии из текстов Консультанта):
ОтветитьУдалить$doc =~ s/(^-{66}\n)(?:(?:^(?!(?:[\d¦(]|[а-яa-b]\)|[^"]{1,13}[XХVI\d]\.\h|$exceptions)).{20,}\n#|^\n)+\1)+(?{$c++; print COM "$&\n"})//mg;
Дмитрий, скажу, как коллеге. Вы уж очень "практически" это воспринимаете. Хотя это неплохо.
ОтветитьУдалитьЧто такое БНФ знаете?
Так вот наши "продвинутые regexp" это - БНФ с циклами, if И возможность "вызова функций".
regexp это - метафора.
Если интересно - дальше - лично.
Понятно. Я использую perlовые регулярки (под .NET регексы тоже а-ля Perl). Считается, что это не BNF.
ОтветитьУдалитьНу а у нас - БНФ.. хотя это тоже - "метафора"...
ОтветитьУдалитьХотя "направление ваших мыслей - мне нравится" :-)
Вам-то - вы понимаете - я могу рассказать многое... Если интерес есть...
Все, что связано с обработкой текста, мне безусловно интересно.
ОтветитьУдалитьПишите - расскажу.. Никакой "магии" там нет...
ОтветитьУдалить"Экземпляры <> нарисованные программистом могут
ОтветитьУдалить"предварительно генерировать" ДРУГИЕ стереотипы."
- кто играл в компьютерные игры типа RTS или RPG - тем будет понятен термин "summoning" - когда одни сущности "для своей реализациии" - summon'ят другие. Вот о чём речь."
Поясню... У вас есть "тролль" он умеет summonitь "орков".. мысль понятна? Более высокоуровневые сущности УМЕЮТ порождать более низкоуровневые....
ОтветитьУдалитьв наименовании поста, перед последним словом "НЕ" пропала :)
ОтветитьУдалитьПо поводу "кодогенератора": есть вопрос:
ОтветитьУдалитьдопустим некий класс (это в терминах UML - метамодель? или статическая диаграмма?)
каким то способом ссылается на второй, второй ссылается на 3-й, третий на первый...
Кодогенератор так не зациклится?...
кодогенератор (имел в виду) сферический в вакууме...
УдалитьНет, в нем стоит проверка на это, при том хитрая учитывающая тип связи. Если связи с жестким типом (например агригация в стили с++), и они образуют цикл, то генератор просто выругается что модель не валидная. Если среди связей есть "мягкая" (например, ссылка в стиле с++), товсе будет ок, но граф использлования перестроится так что сначала будут идти жесткие связи а в конце мягкая. Жесткость связей задается на метауровне (ну те там где описываем метамодели и определяем стереотипы связей)
УдалитьНет, в игры я не играю, но кодогенерация вещь интересная. Несколько лет назад писал что-то: автоматическая генерация NSR по пользовательским шаблонам. Это нужно было для пакетной обработки однотипных документов. Например, нужно быстро ввести 100 похожих документов (одного эмитента), при этом 90% действий в Арчи повторяется, на что тратится куча времени. Программа автоматом генерировала NSR по простому шаблону, прописанному в текстовом файле, позволяя вводить 100 документов за 5 минут. Вроде, все сделал, но тогда запнулся на конвертации таблиц rtf->nsr, поэтому программка работала только на документах без таблиц. P.S. да, я практик.
ОтветитьУдалитьИ еще в Delphi-7 был когда то BOLD, куда все делось?
ОтветитьУдалитьhttp://www.compress.ru/article.aspx?id=10138&iid=413
про Delphi - не к нам.....
УдалитьПните - Embarcadero...
Не один BOLD. В .NET-овских версиях Delphi, начиная, кажется, с 8-й, были еще ECO - Enterprise core objects (http://edn.embarcadero.com/delphi/eco). И вот там были и MDA с UML, и object persistence. Но работало только в .NET-приложениях. Соответственно, и выпилили его вместе с .NET-ом из Delphi.
УдалитьНе один BOLD. В .NET-овских версиях Delphi, начиная, кажется, с 8-й, были еще ECO - Enterprise core objects (http://edn.embarcadero.com/delphi/eco). И вот там были и MDA с UML, и object persistence. Но работало только в .NET-приложениях. Соответственно, и выпилили его вместе с .NET-ом из Delphi.
УдалитьА почему ты надеешься что я буду "против" ;)
ОтветитьУдалитьЯ - не "надеюсь"... Я - сомневаюсь... Ведь ты же - "отец-основатель"..
Удалитья не против :)
Удалитьhttp://dou.ua/lenta/articles/mda-introduction/ - вы идете по этому пути :)
ОтветитьУдалитьТак что вы немного опередили время :) мир только на пути к этому а Вы уже применяете на практике :)
УдалитьМы - ЛУЧШие - "напялю на себя Шляпу Гуру"...
Удалить>"Не является ли использование подобных техник и просто необходимость «договариваться» индикатором того, что есть проблемы в распределении «зон ответственности» в коде? Зачем договариваться и согласовывать, если можно чётко разграничить, кто какие классы/методы разрабатывает, а кто их использует? Я делаю болты, Вася – гайки, а Жора свинчивает ими две детали. Какие детали? Да без разницы, мы чётко поделили зоны ответственности. Почему это в области разработки ПО не работает?"
ОтветитьУдалитьВсё таки этот вопрос для меня остаётся открытым. Неужели создание проекта с низкой связанностью, разграничением обязанностей, API и вообще KISS в вашем случае не работает? Речь не идёт о поломке обратной совместимости, её в принципе не должно быть(это я к примеру с гайками).
Могу добавить что графические нотации для меня значительно(в вашем коде я даже предпочёл чтение самого кода) сложнее воспринимаются, чем обычная документация(возможно это дело привычки).
Как в кодогенерации решается проблема разных возможностей языков? Модель приводится к "общему знаменателю"? Т.е при генерации используются лишь те возможности, которые есть во всех целевых языках?
> Как в кодогенерации решается проблема разных возможностей языков? Модель приводится к "общему знаменателю"? Т.е при генерации используются лишь те возможности, которые есть во всех целевых языках?
УдалитьХЕ-ХЕ ))
Вот в том-то и щтука, что за счет использования шаблонной кодогенерации, ЛЮБОЙ один язык можно привести к ЛЮБОМУ другому языку (признаюсь, я сейчас скорее теоретизирую, тк такой практической задачи в полном объеме не было). Согласитесь, что любая возможность любого языка это не более чем способ сократить страдания разработчика, но не принципиальная не возможность решить какую-то бизнес-задачу. Да, на одном языке для этого нужно будет воспользоваться его встроенной возможностью, написав "одну строчку кода", а в другом, где такой возможности нет, для реализации схожего поведения придется написать "небольшой фреймворк", десяток классов, и хитро-заковыристо их использовать "по месту". Дык вот все это и можно (и нужно) засунуть в шаблон, и тогда на модели что в первом что во втором случае это будет "одна галочка/стрелочка/метод/..), а вот при кодогенерации превращаться будет в разные вещи.
Другими словами, на модели не надо "программировать", на ней надо решать конкретные бизнес-задачи - реализовать Прецеденты, а все детали уровня "возможность языка" убирать в шаблон.
1. Вы писали проекты сравнимые хотя бы с Word?
ОтветитьУдалить2. Сколько в них разнородных сущностей?
3. Сколько ответственностей в среднем на сущность?
4. Сколько UseCase'ов верхнего уровня в системе?
5. Каков объём требований?
6. Сколько экранных форм?
7. Сколько людей в среднем в проекте?
"Могу добавить что графические нотации для меня значительно(в вашем коде я даже предпочёл чтение самого кода) сложнее воспринимаются, чем обычная документация(возможно это дело привычки)."
ОтветитьУдалитьКонечно. Там - микро-уровень. Было бы странно - если бы вы не прочитали код. Про масштабирование только - похоже вы не очень внимательно прочитали.
"Как в кодогенерации решается проблема разных возможностей языков? Модель приводится к "общему знаменателю"? Т.е при генерации используются лишь те возможности, которые есть во всех целевых языках?"
УдалитьТут бывают РАЗНЫЕ мнения и РАЗНЫЕ ответы. Мой ответ - надо смотреть по месту.
http://ru.wikipedia.org/wiki/Parser
ОтветитьУдалить