Здравствуйте, Merle, Вы писали:

M>Здравствуйте, Alexey Rovdo, Вы писали:

AR>>Однако еще раз подчеркну. Сегодня UML — это средство представления уже разработанных моделей.
M>Да ну, позиционируется-то он по другому. К тому же какая польза от средства представления, если оно довольно далеко от реальности...

Позиционируется кем и как (ссылки)?
Что же касается реальности, то вовсе я не говорил, что он от нее далек. UML включает массу конструкций, позволяющих представить огромное разнообразие возможных моделей как в статике, так и в динамике. Представить — показать, рассказать, описать в стандартных терминах. То же самое можно сделать просто на словах, в тексте или с помощью нестандартного но интуитивно понятного средства отображения неких графов.


AR>> А готовые модели никто не мешает представить и с помощью UML.
M>А зачем? Если есть некий способ наглядно представить модель в процессе разработки, то зачем от этого способа отказываться, когда модель уже готова?

Чтобы другие участники проекта смогли быстро понять структуру вашей модели (вашего предварительного варианта или части модели, если речь идет о коллективной разработке этой модели). Впрочем, никто не мешает самим участникам использовать внутри проекта другие способы коммуникации, если они находят их более удобными чем UML. Сам же процесс разработки структуры (модели) системы сегодня, увы, гораздо эффективнее возле большой доски или листа бумаги (с последующим переносом разработанного в удобоваримую форму, например, в UML).

AR>>Короче, одно вовсе не исключает другого, но важно понять, что мы имеем дело именно с двумя разными задачами (разработка и формализованное описание разработанного).
M>Зачем для уже разработанного иметь другой язык формального описания, чем тот который применялся в процессе разработки?

Конечно это тяжело — разрабатывать модель в одной среде, а потом описывать ее в другой. Именно поэтому и возникают проблемы с UML. Нет UML-средств помогающих именно разработке и гладко стыкующихся с процессом написания исходных кодов. И именно поэтому программисты, привыкшие работать исключительно с исходным кодом, не приемлют UML. Ведь они разрабатывают модели не в UML, а в C++, Java ...

M>Зачем вообще выделять эти две фазы? В реальной жизни практически не сталкиваешься с ситуацией, когда продукт готов и гарантировано не будет изменяться. Ну допустим, и что, в этот момент садиться и изнурительно писать UML? И кому он будет нужен по готовой модели?

Проблема в том, что в серъезных больших проектах неизбежно участвует множество людей и неизбежно возникает разделение задач между ними. Кто-то занимается исключительно архитектурой системы, а на кого-то ложится задача детального программирования всего функционала отдельных модулей. Сегодня местами нет никакой альтернативы использованию UML. Однако это действительно приводит к массе ненужной или дублирующейся работы. Как я уже и писал раньше, мне видится, что выход лежит в переводе системных архитекторов на работу непосредственно с исходными кодами. Но сами языки, на которых эти исходники сегодня пишутся, пока не готовы предоставить архитекторам весь необходимый им инструментарий.

Приведу такую аналогию.

Скажем есть самолет (вы его уже представили). Это турбовинтовой самолет. Оторвем ему крыло. Во втором крыле ровно посередине просверлим дырку...

Все это совершенно явственно можно себе представить. Более того, можно взять пластилин и очень быстро сделать простейшую модель, проведя с ней указанные манипуляции. При минимальном знакомстве со средствами 3D-моделирования все это элементарно проделать на компьютере. Причем в любой момент можно посмотреть модель на экране с любого ракурса, напечатать и даже изготовить на спецоборудовании.

К сожалению, разработка ПО выглядит иначе. В нашем распоряжении нет средств быстрого изменения модели. Изменяя модель работающей программы мы неизменно приходим к необходимости переписать массу мелочей, без которых измененный код даже нельзя откомпилировать. Изменяя исходный код мы изменяем модель. Но в нашем распоряжении нет средств для быстрой и удобной визуализации этой новой модели в интересующем нас формате — мы вынуждены вести отдельные работы, изменяя существующее отдельно от исходного кода UML-представление нашей модели.

Есть ли какое-то будущее у UML? Разумеется есть. Но, полагаю, только как средства визуализации моделей. Сама же разработка (как процесс формирования этой модели) будет либо инкорпорирована в процесс написания исходного кода, либо так и останется на доске или листе бумаги.

Здравствуйте, Alexey Rovdo, Вы писали:

AR>Позиционируется кем и как (ссылки)?
Как средство разработки, а не описания исключительно готовой модели. Отцами основателями... Ссылки бумажные.

AR>Что же касается реальности, то вовсе я не говорил, что он от нее далек.
Это говорил я.

AR> UML включает массу конструкций, позволяющих представить огромное разнообразие возможных моделей как в статике, так и в динамике. Представить — показать, рассказать, описать в стандартных терминах.
Только на практике это оказывается мало кому нужно.

AR>Чтобы другие участники проекта смогли быстро понять структуру вашей модели (вашего предварительного варианта или части модели, если речь идет о коллективной разработке этой модели).
Для этого годится тот же самый инструмент, который применялся и при разработке. Вы же утверждаете, что для готовой модели почему-то нужен именно UML. Еще раз повторю свой вопрос: Зачем?
Зачем тратить усилия на перевод в UML то, что есть в другом виде и итак всем понятно?

AR> Сам же процесс разработки структуры (модели) системы сегодня, увы, гораздо эффективнее возле большой доски или листа бумаги (с последующим переносом разработанного в удобоваримую форму, например, в UML).
Об этом и речь, так зачем нам UML?

AR>Конечно это тяжело — разрабатывать модель в одной среде, а потом описывать ее в другой. Именно поэтому и возникают проблемы с UML. Нет UML-средств помогающих именно разработке и гладко стыкующихся с процессом написания исходных кодов. И именно поэтому программисты, привыкшие работать исключительно с исходным кодом, не приемлют UML. Ведь они разрабатывают модели не в UML, а в C++, Java ...
Все верно, так зачем нам UML? И зачем привыкать работать не только с исходным кодом?

AR>Проблема в том, что в серъезных больших проектах неизбежно участвует множество людей и неизбежно возникает разделение задач между ними. Кто-то занимается исключительно архитектурой системы, а на кого-то ложится задача детального программирования всего функционала отдельных модулей.
И чем здесь поможет UML?

AR> Сегодня местами нет никакой альтернативы использованию UML.
Ну здрасьте, карандаш, бумага и исходный код со внятными комментариями неплохо справляются.

AR> Однако это действительно приводит к массе ненужной или дублирующейся работы.
Вот именно, что не нужной.

AR> Как я уже и писал раньше, мне видится, что выход лежит в переводе системных архитекторов на работу непосредственно с исходными кодами.
Внятные архитекторы и так с ними и работают.

AR> Но сами языки, на которых эти исходники сегодня пишутся, пока не готовы предоставить архитекторам весь необходимый им инструментарий.
За инструментарием, велкам ту VS 2005 и DSL, вполне логичное развитие архитекторского инструментария.

AR>Приведу такую аналогию.
Опять много текста, но мысль не ясна... И я так и не услышал ответа на вопрос, во-первых, зачем разделять на фазы "разработки модели" и "готовой модели" и, во-вторых, если уж разделять, то зачем применять ко второй фазе другой язык формального описания, отлчный от применяемого в первой фазе?

AR>Есть ли какое-то будущее у UML? Разумеется есть.
Я бы не был так уверен.

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

Здравствуйте, Merle, Вы писали:

AR>> Но сами языки, на которых эти исходники сегодня пишутся, пока не готовы предоставить архитекторам весь необходимый им инструментарий.
M>За инструментарием, велкам ту VS 2005 и DSL, вполне логичное развитие архитекторского инструментария.

1. Релиз пока не вышел.
2. Технология не прошла обкатки в реальных проектах.
3. На Windows свет клином не сошелся.
4. Есть достаточно много крупных компаний успешно применяющих UML для проектирования и разработки. Собственно, мы делаем продукт как раз на базе UML 2.0, который вполне успешно используется этими самыми компаниями.

Здравствуйте, Merle, Вы писали:

M>Здравствуйте, Alexey Rovdo, Вы писали:

AR>>Позиционируется кем и как (ссылки)?
M>Как средство разработки, а не описания исключительно готовой модели. Отцами основателями... Ссылки бумажные.


Почитал на досуге отцов-основателей (Рамбо, Якобсон, Буч). Ну что сказать? По их словам UML предназначен для всего. Особенно вдохновенно пишут об унификации. Впрочем, вчитавшись можно найти и такие фразы: "Мы не собирались делать из языка UML методологию, в нем нет пошагового описания процесса разработки ... При этом важно понимать, что UML и процесс разработки с использованием UML — совершенно разные вещи. UML призван поддерживать все или, по крайней мере, большинство существующих методологий..." И тут же: "Модель должна создаваться в удобной для работы среде. Например, модель здания может быть рисунком на бумаге, трехмерным макетом из картона и папье-маше или системой уравнений в конечных элементах. При этом она может изображать внешний вид этого здания, но также использоваться и для подсчета стоимости строительства. Модель программного продукта создается с помощью языка моделирования, например, UML. Модель может принимать различные формы ...". А потом уже взгляд такой: "Здесь описывается интерпретация модели в языке UML. Тем не менее во время реальной работы над проектом полезно пользоваться и другими источниками, которые могут интерпретировать информацию другим, отличным от UML способом."

Так для чего же нужен UML по мнению самих отцов-основателей? Для создания моделей или для их интерпретации? Я понимаю, что им хотелось бы сделать область применения этого языка максимально широкой. Именно поэтому язык насыщен массой конструкций, пришедших из самых разных областей инженерной деятельности. Но нельзя удовлетворить всех одинаково хорошо. Лично я придерживаюсь той точки зрения, что UML хорош именно как средство коммуникации, т.е. должен использоваться исключительно для интерпретации моделей. А вот для создания и управления моделями нужны иные средства.

AR>> UML включает массу конструкций, позволяющих представить огромное разнообразие возможных моделей как в статике, так и в динамике. Представить — показать, рассказать, описать в стандартных терминах.
M>Только на практике это оказывается мало кому нужно.

В маленьких рабочих группах, да. Но в крупных компаниях и проектах UML востребован.

AR>>Чтобы другие участники проекта смогли быстро понять структуру вашей модели (вашего предварительного варианта или части модели, если речь идет о коллективной разработке этой модели).
M>Для этого годится тот же самый инструмент, который применялся и при разработке. Вы же утверждаете, что для готовой модели почему-то нужен именно UML. Еще раз повторю свой вопрос: Зачем?
M>Зачем тратить усилия на перевод в UML то, что есть в другом виде и так всем понятно?

Нет. Я вовсе не утверждаю того, что для готовой модели UML нужен обязательно. Просто UML — это удобное и стандартизованное средство представления готовых моделей. Я смотрю на него также как, например, на формат PDF, который является удобным средством для представления документов со сложной версткой. Но вот изначально создавать и верстать документы удобнее в других форматах.

AR>> Сам же процесс разработки структуры (модели) системы сегодня, увы, гораздо эффективнее возле большой доски или листа бумаги (с последующим переносом разработанного в удобоваримую форму, например, в UML).
M>Об этом и речь, так зачем нам UML?

А зачем нам PDF? Просто всегда нужны какие-то стандартные средства представления данных. Как средство внешнего представления моделей разных типов UML вполне годится. Но вот обратный процесс возможен уже не всегда (равно как и PDF-документ не всегда можно обратно конвертировать в вид, удобный и пригодный для редактирования в программе верстки).

AR>>Конечно это тяжело — разрабатывать модель в одной среде, а потом описывать ее в другой. Именно поэтому и возникают проблемы с UML. Нет UML-средств помогающих именно разработке и гладко стыкующихся с процессом написания исходных кодов. И именно поэтому программисты, привыкшие работать исключительно с исходным кодом, не приемлют UML. Ведь они разрабатывают модели не в UML, а в C++, Java ...
M>Все верно, так зачем нам UML? И зачем привыкать работать не только с исходным кодом?

В том то и дело. Работать с UML плохо. Лучше работать с исходным кодом, а UML-представления по мере надобности получать из исходного кода автоматически. Но сегодня более пополярна иная концепция — исходный код получать из UML-моделей. Но она не работает и создает массу ненужной суеты и проблем. Однако вынужден констатировать, что предлагаемый мною подход, к сожалению, чисто теоретический. Современные языки программирования и средства разработки пока не предоставляют нам такой возможности.

AR>>Проблема в том, что в серъезных больших проектах неизбежно участвует множество людей и неизбежно возникает разделение задач между ними. Кто-то занимается исключительно архитектурой системы, а на кого-то ложится задача детального программирования всего функционала отдельных модулей.
M>И чем здесь поможет UML?

Можно научить всех этих людей тому внутреннему инструментарию, который используется в компании. А можно потребовать знание UML при приеме на работу. Второй вариант просто проще и легче просчитывается в финансовом плане. А крупные компании всегда больше ценят предсказуемость и управляемость процесса. Например, имея стандарт можно легко нормировать объемы работ разработчиков (в строках UML-кода, если хотите), а вот в количестве изведенной бумаги производительность труда просчитывать не получается. Это просто законы бюрократии, которые хочешь-не-хочешь вступают в действие везде, где пытаются организованно сделать что-то большое. Вот поэтому я и говорю, что местами нет никакой альтернативы UML.

AR>> Как я уже и писал раньше, мне видится, что выход лежит в переводе системных архитекторов на работу непосредственно с исходными кодами.
M>Внятные архитекторы и так с ними и работают.

Внятные архитекторы все равно имеют дело с другими (невнятными) архитекторами и бюрократами, которых пруд пруди. И даже через много тысяч лет ситуация не изменится.

Здравствуйте, Alexey Rovdo, Вы писали:

AR>Лично я придерживаюсь той точки зрения, что UML хорош именно как средство коммуникации, т.е. должен использоваться исключительно для интерпретации моделей. А вот для создания и управления моделями нужны иные средства.
Нет, я не слезу...
Зачем отдельное средство интерпретации? Код и так, вообщем-то, достаточно выразителен.
Разработчик лучше понимает код, архитектор, тоже код понимает не плохо, заказчик ни код, ни UML не понимает вообще, за редким исключением, так заче нужен UML?

AR>Нет. Я вовсе не утверждаю того, что для готовой модели UML нужен обязательно. Просто UML — это удобное и стандартизованное средство представления готовых моделей.
Чем удобное? Разьве что тем, что стандартизированное, но это единственное преимущество, которое напрочь убивается тем, что UML представление имеет мало общего с реальным продуктом. Нет никакой связи, между реальным продуктом и UML-ем, архитектор нарисовал одно, разработчик написал совсем другое и синхронизировать одно с другим нет никакой возможности.

AR> Я смотрю на него также как, например, на формат PDF, который является удобным средством для представления документов со сложной версткой. Но вот изначально создавать и верстать документы удобнее в других форматах.
Не надо увлекаться ложными аналогиями. В случае PDF можно нажатием кнопки получить этот самый PDF из исходников и после этого исходники никого не интересуют, PDF стал основным документом. В случае же UML-я все наоборот, главное по прежнему продукт, а UML якобы помогает понять как он устроен...

AR>А зачем нам PDF? Просто всегда нужны какие-то стандартные средства представления данных.
Зачем нам какое-то другое представление данных, которое требует дополнительных усилий по применению и все равно полностью их не отражает?

AR> Как средство внешнего представления моделей разных типов UML вполне годится.
Но зачем его использовать, если и без него все понятно? А использование дополнительного представления только вносит дополнительную путаницу.

AR>В том то и дело. Работать с UML плохо. Лучше работать с исходным кодом, а UML-представления по мере надобности получать из исходного кода автоматически.
Зачем получать это представление, даже автоматически? Понятнее от этого модель вряд ли станет.

AR> Современные языки программирования и средства разработки пока не предоставляют нам такой возможности.
В третий раз говорю, DSL.

AR>Можно научить всех этих людей тому внутреннему инструментарию, который используется в компании.
Не надо никого ничему учить. Внутренний инструментарий — это исходный код, карандаш, бумага, язык.

Я так и не услышал ответа на вопрос, чем может помочь UML построенный по готовой модели.

Здравствуйте, _Obelisk_, Вы писали:

_O_>1. Релиз пока не вышел.
43B503F5-F490-4176-BCEF-4B7509A5D970. Речь шла о перспективах развития архитекторского инструментария, а не о реально используемых инструментах.

_O_>2. Технология не прошла обкатки в реальных проектах.
27281864-A314-4454-BA44-09A3ABB74E9C. Еще пройдет, главное идея здравая и, по большему счету, не новая, просто наконец-то появится хороший полноценный инструмент и не придется изобретать каждый раз что-то своё.

_O_>3. На Windows свет клином не сошелся.
EBA12DFA-E26D-42E5-985D-8490801BE482. А причем здесь Windows? На Windows только инструментарий, а основное это идея. Если она хорошо себя проявит, то и на других платформах появится...

_O_>4. Есть достаточно много крупных компаний успешно применяющих UML для проектирования и разработки. Собственно, мы делаем продукт как раз на базе UML 2.0, который вполне успешно используется этими самыми компаниями.
6503CBE9-6C79-4489-9D00-A8B8078C34EA. Но есть не меньшее количество таких же крупных компаний, которые не менее успешно не применяют UML и что?

Здравствуйте, Merle, Вы писали:

_O_>>3. На Windows свет клином не сошелся.
M> А причем здесь Windows? На Windows только инструментарий, а основное это идея. Если она хорошо себя проявит, то и на других платформах появится...

Вся DSL сильно привязана к .Net и Visual Studio. Портирование на другие платформы будет затруднительно. А MS сама не будет этим заниматься.

_O_>>4. Есть достаточно много крупных компаний успешно применяющих UML для проектирования и разработки. Собственно, мы делаем продукт как раз на базе UML 2.0, который вполне успешно используется этими самыми компаниями.
M> Но есть не меньшее количество таких же крупных компаний, которые не менее успешно не применяют UML и что?

Какие крупные компании не используют UML и сколько их ?

Здравствуйте, Merle, Вы писали:

AR>>Нет. Я вовсе не утверждаю того, что для готовой модели UML нужен обязательно. Просто UML — это удобное и стандартизованное средство представления готовых моделей.
M>Чем удобное? Разьве что тем, что стандартизированное, но это единственное преимущество, которое напрочь убивается тем, что UML представление имеет мало общего с реальным продуктом. Нет никакой связи, между реальным продуктом и UML-ем, архитектор нарисовал одно, разработчик написал совсем другое и синхронизировать одно с другим нет никакой возможности.

AR>> Я смотрю на него также как, например, на формат PDF, который является удобным средством для представления документов со сложной версткой. Но вот изначально создавать и верстать документы удобнее в других форматах.
M>Не надо увлекаться ложными аналогиями. В случае PDF можно нажатием кнопки получить этот самый PDF из исходников и после этого исходники никого не интересуют, PDF стал основным документом. В случае же UML-я все наоборот, главное по прежнему продукт, а UML якобы помогает понять как он устроен...

Ровно то же самое можно и с UML-ем. Например, продукты компании I-Logix или нашей обеспечивают полноценную генерацию исполняемого кода из UML моделей. Причем сгенерить все можно одной кнопкой.

Здравствуйте, _Obelisk_, Вы писали:

_O_>Ровно то же самое можно и с UML-ем. Например, продукты компании I-Logix или нашей обеспечивают полноценную генерацию исполняемого кода из UML моделей. Причем сгенерить все можно одной кнопкой.

А вот об этом можно поподробнее? Особенно о том, как в UML-описании оказывается (чем и на чем пишется) вся информация, необходимая для генерации ИСПОЛНЯЕМОГО кода.

Здравствуйте, Alexey Rovdo, Вы писали:

AR>А вот об этом можно поподробнее? Особенно о том, как в UML-описании оказывается (чем и на чем пишется) вся информация, необходимая для генерации ИСПОЛНЯЕМОГО кода.
Я как-то для прикола написал на visio С# программу. Сгенерил код. И откомпилировал. Но честно говоря, так работать невозможно.

С уважением, Gleb.

Здравствуйте, Alexey Rovdo, Вы писали:

AR>Здравствуйте, _Obelisk_, Вы писали:

_O_>>Ровно то же самое можно и с UML-ем. Например, продукты компании I-Logix или нашей обеспечивают полноценную генерацию исполняемого кода из UML моделей. Причем сгенерить все можно одной кнопкой.

AR>А вот об этом можно поподробнее? Особенно о том, как в UML-описании оказывается (чем и на чем пишется) вся информация, необходимая для генерации ИСПОЛНЯЕМОГО кода.

В нашем случае мы используем UML 2.0. Он содержит необходимые классы для выражения action-ов (таких как вызов метода, посылка сигнала, присваивание выражения переменной и т.д.) Плюс мы несколько расширили объектную модель, добавив классы для представления выражений (чтоб выражения типа "a + b * 2" были не просто текстом, а частью модели).
Так же мы сделали текстовую нотацию для UML 2.0, как раз для удобного описания action-ов. (Стандарт определяет какие конструкции есть, но не опеределяет никакой нотации для них).

Все выглядит примерно так

А знаком ли кто-нибудь с такам инструментарием?

http://www.visual-paradigm.com/

И что о нем можете сказать?

Здравствуйте, _Obelisk_, Вы писали:

_O_>Ровно то же самое можно и с UML-ем. Например, продукты компании I-Logix или нашей обеспечивают полноценную генерацию исполняемого кода из UML моделей. Причем сгенерить все можно одной кнопкой.
Во-первых надо наоборт, из исходного кода UML модель получить, речь-то об этом.
А во-вторых, еще раз повторюсь, в отличии от PDF-а, после генерации UML-я основным документом по прежнему являются исходники и после того как разработчик в них что-то поменял, всю нагенеренную красоту UML можно выкидывать.

Здравствуйте, Alexey Rovdo, Вы писали:

AR>А знаком ли кто-нибудь с такам инструментарием?

AR>http://www.visual-paradigm.com/

AR>И что о нем можете сказать?

Не знаю, руками не трогал, судить не берусь. Я думаю, по части генерации кода и симуляция у нас (Telelogic) опыта больше будет.
В часности, нашел тул обеспечивает генерацию кода и в С, что позволяет его использовать (и он реально используется) для разработки embedded & real-time software.

Здравствуйте, Merle, Вы писали:

M>Здравствуйте, _Obelisk_, Вы писали:

_O_>>Ровно то же самое можно и с UML-ем. Например, продукты компании I-Logix или нашей обеспечивают полноценную генерацию исполняемого кода из UML моделей. Причем сгенерить все можно одной кнопкой.
M>Во-первых надо наоборт, из исходного кода UML модель получить, речь-то об этом.
M>А во-вторых, еще раз повторюсь, в отличии от PDF-а, после генерации UML-я основным документом по прежнему являются исходники и после того как разработчик в них что-то поменял, всю нагенеренную красоту UML можно выкидывать.

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

Здравствуйте, Merle, Вы писали:

M>Во-первых надо наоборт, из исходного кода UML модель получить, речь-то об этом.
M>А во-вторых, еще раз повторюсь, в отличии от PDF-а, после генерации UML-я основным документом по прежнему являются исходники и после того как разработчик в них что-то поменял, всю нагенеренную красоту UML можно выкидывать.

В том и состоит основной казус. Можно конечно пойти по пути переноса всей разработки в UML, как это показывает _Obelisk_ . Дескать мы получаем исходные коды как промежуточное звено и их вообще не правим, а правим только исходную UML-модель. Но тогда мы фактически вынуждены встраивать куски Java/C++/... кода прямо внутрь UML-нотации. Нельзя отрицать такую возможность напрочь. Но лично мне кажется, что заходить все-таки надо с другого конца.

Впрочем, индустрия уже так далеко зашла именно в направлении интеграции языков программирования в UML-модели, что развернуться на 180 градусов ей будет трудновато. Скорее просто при достижении определенного уровня интеграции будет вообще трудно понять что и в кого интегрировали, а работа с исходниками на C++/Java и т.п. станет в чем то сродни написанию ассемблерных вставок в C++-коде: __asm { ... }. Но в таком случае сама генерация полных исходников на C++ и т.п. из описанной совмещенной модели может оказаться вообще ненужным шагом — можно сразу компилировать "исходный" UML + C++ код. И как тогда называть этот язык (UML + C++)?

Здравствуйте, _Obelisk_, Вы писали:

_O_>Вся DSL сильно привязана к .Net и Visual Studio. Портирование на другие платформы будет затруднительно. А MS сама не будет этим заниматься.
Еще раз: К .Net привязан конкретный инструмент, а DSL — это идея. И реализовать эту идею можно где угодно, было бы желание.
Если же ставить вопрос о портировании, то на ту же Java перевести никакого труда не составит.

_O_>Какие крупные компании не используют UML и сколько их ?
Я статистику не веду, но та же Microsoft, AFAIK, UML не использует — это достаточно крупная компания?

Здравствуйте, Alexey Rovdo, Вы писали:


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.

Здравствуйте, Merle, Вы писали:

M>Здравствуйте, _Obelisk_, Вы писали:

_O_>>Вся DSL сильно привязана к .Net и Visual Studio. Портирование на другие платформы будет затруднительно. А MS сама не будет этим заниматься.
M>Еще раз: К .Net привязан конкретный инструмент, а DSL — это идея. И реализовать эту идею можно где угодно, было бы желание.

А нельзя ли чуть подробнее раскрыть суть этой идеи или дать ссылочки. Я лично с VS 2005 пока не работал, посему любопытно.

Здравствуйте, _Obelisk_, Вы писали:

_O_>Такого еще долго не будет, потому как любые мало-мальски сложные системы зависят от всяких внешних API и библиотек. При генерации в какой-нибудь язык программирования проще интегрировать со сторонними библиотеками.
_O_>Да и портация сгенеренного кода на всякие специальные платформы (используемые в embedded & telecom industry) проще, если генерить С/C++/Java.

Не в последнюю очередь именно по указанным причинам мне и импонирует больше идея расширения возможностей моделирования при работе с исходным кодом (в т.ч. расширение самих языков, на которых этот исходный код пишется), а не идея расширения возможностей средств UML-моделирования по генерации исходного кода.