AR>В том и состоит основной казус. Можно конечно пойти по пути переноса всей разработки в UML, как это показывает _Obelisk_ . Дескать мы получаем исходные коды как промежуточное звено и их вообще не правим, а правим только исходную UML-модель. Но тогда мы фактически вынуждены встраивать куски Java/C++/... кода прямо внутрь UML-нотации. Нельзя отрицать такую возможность напрочь. Но лично мне кажется, что заходить все-таки надо с другого конца.
У нас это как раз и реализовано. В большинстве случаев, хватает нашей текстовой нотации, но если очень надо, то можно прямо и target код вставлять. Для интеграции с библиотеками есть возможность импорта (h-файлов для C/C++ и Jar/class файлов для Java) в UML модель.
И roundtrip engineering у нас тоже поддерживается (для Java и С++. Для С нет, но там он не нужен).
AR>Впрочем, индустрия уже так далеко зашла именно в направлении интеграции языков программирования в UML-модели, что развернуться на 180 градусов ей будет трудновато. Скорее просто при достижении определенного уровня интеграции будет вообще трудно понять что и в кого интегрировали, а работа с исходниками на C++/Java и т.п. станет в чем то сродни написанию ассемблерных вставок в C++-коде: __asm { ... }. Но в таком случае сама генерация полных исходников на C++ и т.п. из описанной совмещенной модели может оказаться вообще ненужным шагом — можно сразу компилировать "исходный" UML + C++ код. И как тогда называть этот язык (UML + C++)?
Такого еще долго не будет, потому как любые мало-мальски сложные системы зависят от всяких внешних API и библиотек. При генерации в какой-нибудь язык программирования проще интегрировать со сторонними библиотеками.
Да и портация сгенеренного кода на всякие специальные платформы (используемые в embedded & telecom industry) проще, если генерить С/C++/Java.
