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