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