Ответ на »сообщение 101« (Николай)
___________________________
Rational Rose -- это единственный пока более-менее известный продукт, в котором кодирование заменено моедлированием. Ребята раскрутили свой брэнд и упорно за него держатся. Но судить о моделировании вместо кодирования оп одному прецеденту нельзя. Я уже приводил пример, что будет, если судить о возможностях ЯВУ по Фортрану. Будем ждать, пока разработчики инструментальных средств начнут создавать инструменты для разработки софта на основе моделирования, а не кодирования. Появятся разные разработчики, разные идеи и разные реализации, тогда и будет смысл говорить о возможностях.

А в остальном с Вами почти согласен. За исключением вот этого: "Постепенно из этой конструкции код Delphi все должен вытеснить и на последней стадии мы должны получить законченное приложение". Представьте, что Delphi была бы спреоктирована таким образом, что все визуальное проектирование закончилось бы генерацией кода. И никаких DFM. А собственно так и работали первые инструменты для визуальной разработки интерфейса для различных языков программирования. Слепили интерфейс, перегнали в код и все. А потом нужно что-то доработать, па фиг Вам. Лыко-мочало, начинай сначала.

Суть именно в том, чтобы оставить именно модель, которую бы компилятор перегонял в машинный код. Я текстами на ЯВУ затыкать дыры, которые невозможно реализовать на имеющемся языке моделирования. Предположительно, процент кода на ЯВУ будет уменьшатся по мере развития средств модельного программирования.

Ответ на »сообщение 105« (Jack Of Shadows)
___________________________

Ответ на »сообщение 101« (Николай)
___________________________
Нужно реально некое средство моделирования, в которое код Delphi можно вкрапывать также, как ассемлер в Delphi.  
Есть такое: ModelMaker http://www.modelmakertools.com/
Более того, он даже в поставку Delphi 7 входит. Так что если ы вас есть 7-я дельфя, то можете пробовать.


Да, есть такое средство.
Пользую его давно, но без какой-либо связи с UML :) Фрагменты диаграммы классов - максимум.
Впрочем, рисовать UML-картинки он тоже позволяет.
Это индивидуальное средство.
Полностью интегрирован с Delphi. Генерирует код "на лету" и так же на лету обновляет модель при изменениях кода.
Замечательный инструмент для классического программиста-прикладника, который рассматривает кодирование как неизбежный этап в построении системы.

Ответ на »сообщение 107« (Николай)
___________________________
Вообще, я думаю, что именно это качество российских программистов и вырастило дебилов-заказчиков, которые даже мыслью пошевелить ленятся. Причем появилась такая каста заказчиков не так давно, может быть, за последние 5-6 лет.
-Этот компьютер освободит Вас от половины работы.
-Хорошо, поставьте мне два компьютера.
Сколько лет этому анекдоту?

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

Ответ на »сообщение 106« (Сергей Перовский)
___________________________
>>> Создатели UML предполагали, что схемы будет составлять именно специалист.
>>> А вручили инструмент тому-же программисту.

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

Ответ на »сообщение 106« (Сергей Перовский)
___________________________
Диалог типичный, разумеется. Причем иногда добавляют "Вы, как программист, могли бы наши проблемы решить сами. А если чего нельзя сделать, то объяснили бы, почему". Т.е. полный бардак. Как решить задачу, потребитель не знает, свои потребности объяснить он не может, но зато хочет понять, почему нельзя сделать то, не знаю что, но которое запрограммировать нельзя.

Что касаемо специалиста. Я себя не могу отнести к кодерам. И большинство программистов в России, кроме, может быть, самых молодых, не являются простыми кодерами. Это настоящие разноплановые специалисты, очень хорошо владеющие методологическими навыками и умеющие готовить документы на языке, понятном для заказчика. Может быть, за бугром по-другому, но на это лично мне наплевать с высокой колокольни. Вообще, я думаю, что именно это качество российских программистов и вырастило дебилов-заказчиков, которые даже мыслью пошевелить ленятся. Причем появилась такая каста заказчиков не так давно, может быть, за последние 5-6 лет. Раньше такого я не наблюдал.

Ответ на »сообщение 101« (Николай)
___________________________
Он уже не хочет работать над документом, который ему написал программист за него же!
При чем тут не хочет? Он не может!
А Вы никого не забыли?
Ну представьте такой диалог:
-Напишите программу, которая рассчитывала бы оптимальное значение параметра А.
-А как его рассчитать?
-Откуда я знаю? Кто из нас программист?
-Но сейчас Вы как расчитываете?
-Мы подбираем по месту. Осточертело уже. Пусть программа сразу скажет, какой нужен.

Я, может быть, несколько утрирую, но основная проблема в том, что ни заказчик (он же будущий пользователь) ни программист понятия не имеют, как решить реальную проблему. И пинают друг другу работу по подготовке ТЗ вместо того, чтобы искать специалиста, способного решить проблему.

Создатели UML предполагали, что схемы будет составлять именно специалист. А вручили инструмент тому-же программисту. Для специалиста UML оказался такой же непонятной штукой, как и язык программирования.
Еще одна попытка создавать программы без программистов провалились.
А попытки создавать программы без специалистов все продолжаются.

Ответ на »сообщение 101« (Николай)
___________________________
Нужно реально некое средство моделирования, в которое код Delphi можно вкрапывать также, как ассемлер в Delphi. 
Есть такое: ModelMaker http://www.modelmakertools.com/
Более того, он даже в поставку Delphi 7 входит. Так что если ы вас есть 7-я дельфя, то можете пробовать.

Ответ на »сообщение 103« (Сергей Перовский)
___________________________
Скажем мягче: ФП неудобны для таких задач. Любые задачи, содержащие понятия времени и состояния, представляют трудности для ФП. 
Жаль что вот этому вот новичку http://www.gamedev.net/community/forums/topic.asp?topic_id=501730 об этом не сообщили. А он бедняга взял и написал в целях самообучения простенькую игрушку pong (теннис) на хаскеле.
У него там и время течет, и состояние ПОСТОЯННО меняется. И сам он новичок. А вот программу причем очень даже короткую, умудрился написать.
Можете скачать ехешник, и глядя как мячик скачет от игрока к игроку философствовать не тему обратных связей и гистерезисных явлений :))

Ответ на »сообщение 89« (Как слышно? Прием!)
___________________________
Следует ли из этого, что ФП не пригодны для описания гистерезисных явлений
Скажем мягче: ФП неудобны для таких задач. Любые задачи, содержащие понятия времени и состояния, представляют трудности для ФП. А обратные связи и гистерезисные явления принципиально завязаны на время и состояние.

Ответ на »сообщение 101« (Николай)
___________________________
И даже когда я за него описываю задачу, он кочевряжится Как это знакомо :(((
Вот где место для UML-подобных систем. Но что-то они не живут Да по тому, что заказчику надо не квадратики, а нечто совсем иное. За квадратиками кто-то видит кучу бабок, кто-то ... ну вы сами понимаете что. Просто лениво не то чтобы формулировать свои мысли, но даже думать.

В общем выводы такие (ПМСМ конечно): нет ни какого проку с него.

P.S. И родоначальник UML, Козимир Малевич о го го, что видел. Менее известные его произведения красный квадрат и красный круг :o)