Заинтересовала возможность генерации C++ (Java и т.п.) кода из UML модели. Посмотрел как это делает MS Visual Modeler, StarUML и не пришёл в восторг. Неприятность в том, что концы ассоциаций генерятся как простые указатели, тогда как хотелось бы получать STL коллекции. Конечно всё это можно явно изобразить в модели, но хотелось бы абстрагироваться от таких подробностей.

Интересует также возможность преобразования поведенческих UML моделей и OCL ограничений в методы на C++, C#, Java, PL/SQL, SQL.

Сейчас пробую писать на JScript генератор спецификаций классов C++ для StarUML. Может быть изобретаю велосипед, но могу поделиться.

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

sergey888т.к. все пишут код по разному, то и генератор кода тоже лучше написать под себя...
Времени это занимает намного меньше, чем кажется, а экономит намного больше...

На счёт времени, соглашусь. По крайней мере для генерации спецификаций классов C++ задача не сложная, тем более, что API для работы с моделью стандартизован OMG, полуенные скрипты без больших доработок можно будет использовать и с другим CASE.

Про "все пишут код по разному" это, наверное, не совсем так. Есть достаточно устоявшиеся рекомендации. Если ближе к теме, чтобы проектировщик и кодер одинаково понимали модель, нужны чёткие правила отображения модели в код. Например, стрелочка - это указатель на объект, плюсик - public член, 0..* - используем список, зависимость - #include и т.п.. Стандартных правил, как я понял, нет. Правила, которые я видел далеки от моего идеала. Какие ещё правила существуют? Может быть есть C++ библиотеки, поддерживающие конструкции UML?

sergey888Может быть в С++ есть устоявшиеся правила, но в Дельфи для решения одной задачи можно использовать разные компоненты

На таком уровне и для C++ рецептов нет. Под разные библиотеки и код будет разный. Для MFC такой, для STL эдакий. Пока я рассматриваю только STL. Даже в этом случае для реализации конструкции UML можно выбрать один из многих шаблонов, что создаёт нежелательную неоднозначность в понимании модели. Скорее всего поверх STL, чтобы упростить генератор кода, придётся создать небольшую UML ориентированную надстройку.

1024так все одинаково или по разному?

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

Petro123 sergey888Может быть в С++ есть устоявшиеся правила, но в Дельфи для решения одной задачи можно использовать разные компоненты у которых разные свойства, возможности, соответственно код получается разный.
Можно использовать или не использовать наследование форм, модальность форм или выносить формы в отдельные DLL и т.д. вариантов масса....
+1
Эти генераторы - утопия , если конечно не писать всё ручками, да на С++.
Генераторы не учитывают библиотеки. Взять тот ваш "список". На С++ он начнёт генерить код или класс для него. А на Delphi это готовый компонент-класс TList ли немножко_другой_для_другой_задачи TObjectList или ...... и так далее.

Поэтому очень далеко "это" от народа (от программистов :))

Утопия? Не согласен. Oracle Designer генерит пригодный для работы код. Конечно инструмент не универсальный, но в свою задачу решает. Есть ряд хороших генераторов схем БД, точнее кода для их создания. Delphi в значительной степени избавляет програмииста от кодирования. Я сам писал приложения без единой строчки кода, только соединяя компоненты.

Генераторы не учитывают библиотеки? Из того немногочисленного, что я видел могу с этим согласиться, но все ли генераторы кода столь несообразительны?
Я знаю тупое, но рабочее решение - указывать классы компонетов в тэгах, как правило нестандартных. Сомневаюсь, что в ближайшее время генераторы кода научатся различать "немножко_другие_задачи" без посторонней помощи. Конкретно, выбрать между TList и TObjectList можно полагаясь на требования к интерфейсу объекта.

asafreeПочему перестали пользоваться? Есть более адекватные средства и практики, сохраняющие плюсы генерации и устраняющие её минусы.
...

Т.е., разработка кодогенератора стала неактуальной, поскольку вы отказались от практики моделирования системы на UML и т.п. языках моделирования в пользу программирования в IDE и XP?

Petro123 mcureenab asafreeПочему перестали пользоваться? Есть более адекватные средства и практики, сохраняющие плюсы генерации и устраняющие её минусы.
...

Т.е., разработка кодогенератора стала неактуальной, поскольку вы отказались от практики моделирования системы на UML и т.п. языках моделирования в пользу программирования в IDE и XP?
все смешано - кони, лошади.
================
на UML проектируется модель системы, интерфейс её составных частей.
Далее не генерируется код, а отдаётся программистам для реализации.

Хоть и говорят, что программирование это не творчество а рутина, но как видно не так .

ЗЫ. и ХР тут ещё причём?

Кодированием модели, конечно, могут заниматься программисты, но речь то не об этом, а о том, что, ИМХО, в модель можно внести достаточно данных, чтобы автоматически создать компилируемый код, или, хотя бы его часть. asafree пишет про тоже.

В настоящее время наблюдается разделение труда проектировщиков и кодеров. Чем меньше творчества будет в работе кодера, тем более предсказуемым будет результат его работы. Собственно чего я и пытаюсь добиться.

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

Petro123[quot автор]Кодированием модели, конечно, могут заниматься программисты, но речь то не об этом, а о том, что, ИМХО, в модель можно внести достаточно данных, чтобы автоматически создать компилируемый код, или, хотя бы его часть. asafree пишет про тоже.
========= эта часть стремится к нулю, т.к. нельзя формализовать разброс языков-технологий-библиотек-компиляторов

Я и не ставлю задачи генерить код для всех языков-технологий-библиотек-компиляторов из любой модели. Меня интересует генерация для C++, <с технологией не вижу связи>, STL, Visual C++. Для других языков тоже есть потребность генерить код. Понятно, что модель реализации должна быть заточена под целевую среду, и модель для C++ не будет автоматически переносима на PL/SQL .

Petro123[quot автор]В настоящее время наблюдается разделение труда проектировщиков и кодеров. Чем меньше творчества будет в работе кодера, тем более предсказуемым будет результат его работы. Собственно чего я и пытаюсь добиться.
====== если сумеешь, т.к. модель аналитика очень далека от физического кода. И сам аналитик должен быть кодером, т.е. делать его работу самому

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

Petro123[quot автор]Про XP.
XP в позволяет общаться с пользователем на языке прототипов системы не тратя время на создание томов проектной документации. При определённых условиях этот подход вполне приемлем, но с автоматической генерацией кода не совместим.
=============
ХР не запрещает построение моделей. Он говорит, что делай это быстрее - утром модель, в обед - прототип для обкатки. Прототип не заменяет наглядную модель, как эскиз-набросок не заменяет модель из пенопласта.

Это понятно, ИМХО, в XP основной упор в работе с заказчиком делается на обсуждение и согласование прототипа, тогда как RUP предполагает работу с моделью. Если проект маленький, проще быстро сделать и обсудить прототип, чем поводить скурпулёзный анализ. В большом и сложном проекте этот номер не пойдёт.

Petro123стереотип:
- бросить таблицу на форму

На UML, это может быть ассоциация класса доступа к таблице с классом формы. На более высоком уровне абстракции, это может быть зависимость класса формы от класса таблицы или, если речь идёт об SQL запросе из многих таблиц, БД в целом. Как договоримся. ИМХО, из того и из другого можно сгенерить код.
Естественно, графическая нотация UML может быть менее наглядна, чем нотация IDE Delphi, тут, несомненно, универсальные системы моделирования будут уступать специальным. Вопрос только в том, на каком этапе начать перенос данных из одной системы в другую. Иногда это стоит сделать уже на этапе анализа.

Petro123Кодогенератору не объяснишь:
- бросить таблицу на форму
- бросить на форму ADOConnection и указать строку подключения к БД
- связать источник данных и таблицу показа данных
- ВСЁ - ФОРМА ПОКАЗА ИНФЫ ИЗ БД ГОТОВА.


Хм. Если это можно объяснить кодеру, то почему нельзя объяснить кодогенератору? Ведь все когдато учились. Конечно кодер может догадаться, что от него хотят, сделать как он понял, и случайно попасть в цель. Кодогенератор будет ругаться до тех пор, пока ему не объяснишь все необходимые детали: из какой БД, какую таблицу, на какую форму и т.д.

sergey888еще можно сгенерать кнопочки, форму для редактироваия данных и процедуры, по которым будет открываться форма и данные будут сохраняться в БД.
На Кларионе это было реализовано лет 15-20 назад.

Для форм БД в области автоматической генерации кода положение действительно хорошее. Основные операции с БД и формой немногочисленные и формализованы. Уже в каждой IDE, которая претендует на звание средства разработки приложений БД есть мастера форм БД. Как правило, достаточно просто прямо в мастере нарисовать форму, сгенерить документацию и согласовать её с клиентом. Т.е. построитель форм является одновременно и средством моделирования и документирования и кодирования.

В области разработки невизуальных функций дело обстоит гораздо хуже. Модель и документация создаётся отдельно, код отдельно.

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

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

Petro123Например, шаблон "Делегат" генерируется в С++. Но в Delphi он уже генерируется компилятором-генератором инструкцией
.

На "голом" C++ работают только студенты первых курсов на лабораторных работах, и, как оказалось, многие генеаторы кода. Для C++ есть море прикладных библиотек. Для решения наиболее типичных задач используется стандартная библиотека шаблонов - STL. Многое из того, что в Delphi встроено в язык, на C++ реализовано в библиотеках ни чуть не хуже.

Ok. Куплю Internet карту, посмотрю.