Заинтересовала возможность генерации 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, тут, несомненно, универсальные системы моделирования будут уступать специальным. Вопрос только в том, на каком этапе начать перенос данных из одной системы в другую. Иногда это стоит сделать уже на этапе анализа.