Ну и ещё о "самодокументируемости" - http://programmingmindstream.blogspot.ru/2014/10/blog-post_1.html

Кроме UML есть ещё и "тесты"... Читай TDD... Хотя именно "читай"...

Не "человек для субботы, а суббота для человека".

Как "просто применять тесты" мы попытались описать в нашем цикле - "Тестирование калькулятора" - http://programmingmindstream.blogspot.ru/2014/06/blog-post_10.html

Почему UML и тесты? Это связанные вещи? НА САМОМ ДЕЛЕ - связанные...

ещё о "самодокументируемом" коде - http://18delphi.blogspot.ru/2013/11/gui_9.html

Мой коллега по-моему написал ЗАМЕЧАТЕЛЬНУЮ статью - http://18delphi.blogspot.com/2013/10/blog-post_4433.html

Ответ на »сообщение 125« (мардухай)
___________________________

Все было перепробовано. В итоге - "самодокументируемый код". Глядя на который безо всяких комментариев и схем понимаешь, о чем это. Сложно так проектировать и писать? Непросто. Может быть, это и есть высший пилотаж?:-)

Вот что я думаю о "самодокументируемом" коде - http://18delphi.blogspot.com/2013/09/blog-post_19.html

Ещё вопросы созрели - http://18delphi.blogspot.com/2013/09/uml.html

И ещё - http://18delphi.blogspot.com/2013/08/mvc.html

Не UML, но "сходная" тема...

Вот ещё родилось - http://18delphi.blogspot.com/2013/08/uml.html

Вот родилось - http://18delphi.blogspot.com/2013/04/0-rup-uml-mda-etc-al.html

Это вам ко мне :-) про синергию... Но общаться лучше - устно...

Ответ на »сообщение 118« (Как слышно? Прием!)
___________________________

Ответ на »сообщение 112« (Jack Of Shadows)
___________________________
>>> вдруг бац! и вот вам чудо невиданное.
"Брось костыли, кому говорю!"
После окончания детского сада чудес не бывает в принципе :)

Никто вменяемый и не требует чуда.
Идёт ползучая эволюция средств моделирования.
На Delphi есть StarUML - открытая к разработке.
Есть SysML - средство, в котором наконец-то додумались
отказаться от непременной привязки кодированию (читай к ООП).
Вообще, UML отошла от академической полноты по Тьюрингу, в чём её плюс.

>>> А чего конкретно вы ждете ?

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

вот тут - http://18delphi.blogspot.com/2013/04/dsl.html

немножко из моих практических изысканий про "самодокументируемый код"...

Критика - не то что ПРИНИМАЕТСЯ. Она - ПРИВЕТСВУЕТСЯ.

вот тут - http://18delphi.blogspot.com/2013/04/iunknown.html

немножко "микро"-UML есть..

Ответ на »сообщение 127« (мардухай)
___________________________

Ну меня просто никогда не было маленьких проектов. Скорее ОДИН БОЛЬШОЙ проект на 17-ть лет. Видимо потому у меня и - другие потребности. Если интересно - пишите. Обсудим. Лучше в блог или на почту. Буду рад поделиться. Ну и про UML - я буду в блоге рассказывать.

А "самодокументироемость" - ДА! И ещё раз ДА!

Мак Конел - "Совершенный код".

Но это - "Гигиена мозга". Её вот просто так нельзя - ВЗЯТЬ и ПРИВИТЬ.

Впрочем как и тесты и UML. НО стремится - НАДО.

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

Ответ на »сообщение 125« (мардухай)
___________________________
Хотите расскажу на пальцах?
Самодокуменируемый код - это тоже - ЗДОРОВО!

А уж DSL - "по-русски" - так вообще.

Если вы в Москве - можем лично встретиться и "пива" скажем попить.

Письменно всего - не расскажешь. Я только начал в своём блоге.

Но там работы - "вагон и маленькая тележка"....

Все было перепробовано. В итоге - "самодокументируемый код". Глядя на который безо всяких комментариев и схем понимаешь, о чем это. Сложно так проектировать и писать? Непросто. Может быть, это и есть высший пилотаж?:-)

Ответ на »сообщение 122« (Александр Люлин)
___________________________
>>> Не могу понять - можно ли собственные комментарии редактировать.
Нет, нельзя. Пишите новое сообщение. Мультипостинг у нас криминалом не является.

Кто-нибудь думал о том, что "программировать на UML" - вредно? На UML надо "прототипировать". Надо вводить <<стереотипы>> более высокого порядка. От SimpleClass надо переходить к шаблонным решениям. С кодогенерацией. Рисуешь два квадрата и получаешь - publisher/subscriber. У нас есть такое решение. Работодатель вряд ли будет заинтересован это продавать. Ему эо просто неинтересно. Он на другом рынке. Но могу описать идею. Если интересно. На пальцах.

Ответ на »сообщение 121« (Александр Люлин)
___________________________
Скорее вот тут - http://18delphi.blogspot.com/2013/03/blog-post_29.html

Не могу понять - можно ли собственные комментарии редактировать.

Ответ на »сообщение 120« (Александр Люлин)
___________________________

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

Может быть я не туда попал. Простите тогда. Вот тут я пытаюсь популяризировать UML для Delphi - http://18delphi.blogspot.ru/

У нас есть собственная разработка кодогенерации для Rational Rose. Сейчас я работаю над "домашней" независимой разработкой рисовалки UML и кодогенератора для Delphi. Это вообще интересно*

StarUML, написанный на Дельфи, не поддерживает Pascal:(
Только C, Java и PHP.
Какие интересные изгибы мышления у разработчиков!

Ответ на »сообщение 112« (Jack Of Shadows)
___________________________
>>> вдруг бац! и вот вам чудо невиданное.
"Брось костыли, кому говорю!"
После окончания детского сада чудес не бывает в принципе :)

Никто вменяемый и не требует чуда.
Идёт ползучая эволюция средств моделирования.
На Delphi есть StarUML - открытая к разработке.
Есть SysML - средство, в котором наконец-то додумались
отказаться от непременной привязки кодированию (читай к ООП).
Вообще, UML отошла от академической полноты по Тьюрингу, в чём её плюс.

>>> А чего конкретно вы ждете ?

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

Ответ на »сообщение 115« (Geniepro)
___________________________
А если там еще найдут кнопку ПУСК от С-300! Представляете, что будет?!

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

Ответ на »сообщение 114« (Николай)
___________________________

Для примера, в моем собственном exe-файле весом, скажем где-нибудь около 10 Мб можно насчитать от 20 до 40% кода, который исключительно я для себя держу. Чтобы контролировать приложение, тестировать данные во время отладки, и, даже вести мониторинг работающих у клиентов приложений. Пользователи об этом вовсе не догадываются, а начальству я вовсе не докладываю. Но зато себе (и начальству без его ведома) облегчаю жизнь.

А если Вашм заказчики вдруг обнаружат, что в вашем ПО есть закладки, с помощью которых Вы можете красть у них важную коммерческую информацию? 8-о

Ответ на »сообщение 111« (Geo)
___________________________
Постепенно модельные элементы заменить кодом Delphi - это может вовсе не означать изчесзновение элементов модели. Для примера, в моем собственном exe-файле весом, скажем где-нибудь около 10 Мб можно насчитать от 20 до 40% кода, который исключительно я для себя держу. Чтобы контролировать приложение, тестировать данные во время отладки, и, даже вести мониторинг работающих у клиентов приложений. Пользователи об этом вовсе не догадываются, а начальству я вовсе не докладываю. Но зато себе (и начальству без его ведома) облегчаю жизнь. Так что, вполне могу допустить такую модель программы, когда она состоит из "нанизанных" друг на друга двух приложений - Delphi и аля-UML, а может и еще больше. Нынешние времена такие, что "за кодом мы не постоим". Главное - быстрота реакции на усложняющиеся задачи. И не прогадать в архитектуре, т.е. хорош тот программист, который, не погнавшись за выигрышем в неделю, смог сваять каркас, который ему в дальнейшем сэкономит месяцы. Для этого надо иметь, в том числе, и железные нервы.

Ответ на »сообщение 111« (Geo)
___________________________

Представьте, что Delphi была бы спреоктирована таким образом, что все визуальное проектирование закончилось бы генерацией кода. И никаких DFM. А собственно так и работали первые инструменты для визуальной разработки интерфейса для различных языков программирования.
Юрий, Вы будете смеяться, но именно так и работает Windows Forms в .NET (только в WPF появился отдельный язык для описания форм).

Слепили интерфейс, перегнали в код и все. А потом нужно что-то доработать, па фиг Вам. Лыко-мочало, начинай сначала.
Не, ну до такой степени они не докатились, конечно.

Ответ на »сообщение 111« (Geo)
___________________________
Я уже приводил пример, что будет, если судить о возможностях ЯВУ по Фортрану. Будем ждать, пока разработчики инструментальных средств начнут создавать инструменты для разработки софта на основе моделирования, а не кодирования. Появятся разные разработчики, разные идеи и разные реализации, тогда и будет смысл говорить о возможностях.
Господин Geo, я вот на ветке о ФП говорил об обьективных причинах прозябания ФП десятилетиями. Появилось оно чуть ли не полстолетия назад, а обращать на нее внимание стали только сейчас. Оно и понятно, на слабеньких однопроцессорных машинах с куцей памятью не очень то и развергешься. Каждый байтик памяти и каждый такт  процессора дорог.

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

Вы говорите "вот подождем пока сделают удачный инстумент". А чего конкретно вы ждете ? Вы в истории программирования хоть один случай назвать можете когда без обьективных причин более десяти лет индустрия не могла продвинуться вперед, и вдруг бац! и вот вам чудо невиданное.

Ответ на »сообщение 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)

Ответ на »сообщение 98« (Geo)
___________________________
Зацепившись за аналогию с ассемблерными вставками, сказал бы так.

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

Возвращаясь к баранам. Нужно реально некое средство моделирования, в которое код Delphi можно вкрапывать также, как ассемлер в Delphi. Этот конгломерат должен быть живым, и основная задача его - формировать проект с участием обеих сторон - заказчика и разработчика. Постепенно из этой конструкции код Delphi все должен вытеснить и на последней стадии мы должны получить законченное приложение. При этом должна оставаться возможность при появлении новых потребностей вставить в это хозяйство новый кубик и новые стрелочки, которые опять должны вытесняться кодом Delphi. Я не знаю, может ECO так и делает.

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

Причем также как в программировании графические инстурменты хороши прижились в конкретных нишах, также и в других областях (нишах) мы до сих пор успешно используем пиктограммы: Музыка (нотная запись), дорожные знаки, математика. Но универсальный язык картинки не заменят, ни человеческий, ни программный.

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

А бритву оккама применить не пробовали ? Ведь есть же гораздо более простое обьяснение. Ограниченные возможности самой тулзы :))

Я ведь об этом и говорю. Выразительные возможности графических инструментов настолько ограничены, что не могут охватывать весь спектр возможностей языка. Только какие то конкретные задачи (описание GUI итд.)

Элементарно посмотрите на развитие человеческих языков. Графические (пиктограммы, иероглифы) были одни из первых языков, и существуют до сих пор. Но толчок развитию науки и цивилизации дали именно буквенные языки. Картинка тексту не конкурент.

Ответ на »сообщение 97« (Николай)
___________________________
Сравните, например, ЯВУ и ассемблер. На ЯВУ вы, например, не сомжете управлять сегментом стека (встроенный ассемблер не рассматриваем). Значит ли это, что ЯВУ не является универсальным? По-моему, ничуть. Да, есть комбинации машинных кодов, которые на ЯВУ получить невозможно, но для решения задач (относящихся к классу, на который ориентирован данный ЯВУ) этого и не требуется.

Прееходя к программированию через модели мы имеем то же ограничение: не все, что можно выразить на ЯВУ, выразимо и через модели. Да, мы несколько сужаем выразительные возможности средства разработки. Но так ли критично это сужение? Можно ли построить токой язык моделей, что о будет пригоден для столь широкого класса задач, что его можно будет назвать универсальным? Пока я принципильной невозможности не вижу. В конце концов, можно пойти по тому же пути, что и втсраивание ассемблера в ЯВУ: дать возможность в язык моделей дописывать код на ЯВУ для расширения возможностей в тех местах, где модельный язык слаб.

Замечу, что в связи с совершенствованием как самого языка Delphi, так и компилятора потребность в использовании ассемблерных вставок падает. Уже в D7 ассемблерный вставки становятся экзотикой. Если тенденция будет та же, то не исключено, что в каком нибудь ML 7.0 использование вставок на ЯВУ станет такой же экзотикой.

Ответ на »сообщение 94« (Geo)
___________________________
Я исхожу из того, что UML позволяет оперировать категориями (или элементами языка), которые на языках высокого уровня (универсальных языках) описываются заранее известным набором процедур и функций. Это и означает, что есть математическая модель реального мира.
Я не программист ФЯ, поэтому мне так проще выразиться. Если математическая модель неизвестна, то и соответствующие категории языка неизвестны, и в UML появляется дыра, которую заткнуть нечем. А на языке высокого уровня программист может построить соответствующий набор данных и еще включить в реализуемый процесс человека и обеспечить вычислительный процесс. А UML придется догонять, т.е. его придется дорабатывать под новые условия.

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

Ответ на »сообщение 95« (Geo)
___________________________
Ну идею, что UML можно прикрутить вообще ко всемучтоестьвприроде, я мы уже утвергли :o)
Хотя бы применительно к Delphi есть тут люди которые это сделали, постоянно пользуются и реально получают от этого некоторые выгоды???

А вообще по текущему состоянию обсуждения в голове складывается примерно такая аналогия...

Эпоха Фортарана. От вычислительных задач переходим к разработке программ общего назначения. Пытаемся реализовать на Фортране (потому как больше ничего нет). Получается, мягко говоря, не очень. Из чего делаем вывод, что языки высокого уровня применимы только для специализированного класса задач, а создание ЯВУ общего назначения невозможно.

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

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

Ответ на »сообщение 91« (Как слышно? Прием!)
___________________________
Программист, как любой человек, способен на язык машины переложить любые процессы.

А вот создать формализованный язык, способный это сделать автоматически - это все-равно, что иметь математическое описание любого физического явления и любой деятельности человека! Это разные весчи, все-таки. Второе - нереализуемо.

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

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

Ответ на »сообщение 86« (Александр Воробьев)
___________________________

Я надеюсь на ответ кого-нибуть, кто пытался на практике применять MDA!!!

Кто-нибуть может поделится мнением, основанным на практическом опыте, а не субьективным предположением?

Ну вот я поделился в соседней ветке, правда, очень небольшим, но всё же опытом:

»сообщение 352 в теме №383 на БП« и конкретизация чуть позднее, в сообщении 357.

Опыт был бы бОльшим, если бы небольшой опыт прошёл успешно :)

Ответ на »сообщение 90« (Николай)
___________________________
>>> невозможности формализованно описать любые процессы реального мира

То есть бессмысленности работы программистов?

Ответ на »сообщение 80« (Jack Of Shadows)
___________________________
UML это попытка генерации кода общего назначения (то есть любого кода в принципе)

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

Первое, что попытался создать - схему типа триггера,
когда выходы двух элементов введены на входы соседа.
Невозможно.
Более того, схема отображается на поле Scope в виде ... дерева.
[КСП жалобно хнычет]
По рассуждению пришёл к выводу, что наличие петель такого рода
противоречит (как это по рюсски?) reference trasparency чистых ФП.
Следует ли из этого, что ФП не пригодны для описания гистерезисных явлений
и целого семейства нелинейных явлений для которых самоорганизация
основана на обратной связи?

Ответ на »сообщение 87« (Jack Of Shadows)
___________________________
Business Objects Gem Cutter:
Фанерный фон - rulez! :)
Сделано с любовью.

Ответ на »сообщение 85« (Как слышно? Прием!)
___________________________
Ну не UML, а некоторого графического средства разработки моделей пожалуй можно.
Декларативный язык - это набор элементов с разъемами без связей.
Более того, это уже даже сделано: По ссылке pdf: http://resources.businessobjects.com/labs/cal/gem_cutter_manual.pdf
Там описана графическая среда для "рисования" чистого функционального кода (хаскелеподобный язык на JVM)
Все бесплатное, можно скачать отсюда http://labs.businessobjects.com/cal/ и попробовать.

Вот только по сравнению с написанием текста мне эта штуковина кажется ну очень громоздкой и несерьезной.

Я надеюсь на ответ кого-нибуть, кто пытался на практике применять MDA!!!

Кто-нибуть может поделится мнением, основанным на практическом опыте, а не субьективным предположением?

Ответ на »сообщение 77« (Jack Of Shadows)
___________________________
>>> Попробуйте впихнуть парадигмы ФП в блок-схему UML

Ну не UML, а некоторого графического средства разработки моделей пожалуй можно.
Декларативный язык - это набор элементов с разъемами без связей.
Соответственно, никакой структуры отображать не надо.
Вся структура инкапсулирована в компиляторе или среде.
В надежде, что он всё разрулит.
То есть схема здесь - объекты погружённые в бульон компилятора.

Касательно ДРАКОНа - похоже он попадает под парадигму
структурного программирования Джексона
http://en.wikipedia.org/wiki/Jackson_Structured_Programming
Поэтому для меня это не то.

А наши графические средства (идеальный UML)
требуются в концепции потокового программирования.
http://en.wikipedia.org/wiki/Flow-based_programming
ООП - это не потоковое программирование, соответственно
и графические средства (UML в его нынешней реализации) тут буксуют.

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

Ответ на »сообщение 83« (Александр Воробьев)
___________________________
Правда, с ним я знаком только по книге Константина Грибачёва... 
Ну вот с этого надо и начинать. Как вы можете оценивать функциональность настолько сложного продукта не имея ни собственного опыта его использования, ни отзывов тех, кто хотя бы пытался его применять на практике ?

Постоянно читаю отзыв "провал"... Почему-же? ECO не развивается разве? Соглашусь только, что она, недостаточно распространена, что она очень слабо освещается, может даже ещё слишком "сырая"! Но ведь то-же ФП было десятилетиями забыто, а сейчас, как сказал один из участников обсуждения, "отъедает свой небольшой, но важный кусок рынка". Разве нельзя сказать, что с ECO так-же не будет?

Провал не означает конечно тотальное вымирание :) Всего лишь недостижение заявленных целей. Для ФП никогда не заявлялась цель заменить собой все остальные парадигмы программирования. Более того даже не ставилось цели стать доминирующей парадигмой.
Это в отличии от  UML и всяких там продуктов, на нем основанных, которые заявляются как прямая замена существующих методов программирования. Как вы и сами заметили никакой замены не произошло. И не только доминирующей, но даже сколь нибудь заметной роли эти средства не играют. А ведь опять же заявляются не как что то новое, а как автоматизация старого, ТОГО ЖЕ САМОГО обьектно-ориентированного подхода.

То есть все должны были просто валом валить на этот MDA.

Причем, уверен, что проблемы у Bold начались только когда их Borland перекупила.

Зря вы в этом так уверены. Болд и до Борланда был ужасно сложным и глюкавым продуктом. Переименование его в ECO ничего не изменило, то есть ничего не ухудшило.

Заметьте что те же GUI билдеры нормально прижились и используются практически во всех областях программирования, на всех платформах, OC, на всех популярных языках. То есть для частных случаев графические инструменты, генерирующие код, весьма даже успешнаы, и как следствие, широко распространыне.
А вот как средство универсального программирования нет.

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

Но ведь есть-же BOLD! Есть ECO!
Причём BOLD очень даже функциональный! Правда, с ним я знаком только по книге Константина Грибачёва... Ну и так, немного с ним поковырялся, пробные программульки написал... Ничего серьезно...
Но, моё мнение, что продукт для своего времени был чуть-ли не революционным! Ну никак не "пшик" - система вполне рабочая была, и на ней даже программы писали! Причем, уверен, что проблемы у Bold начались только когда их Borland перекупила. Думаю, дело в некомпетентном руководстве - а оно может любой, даже самый многообещающий проэкт загубить.

Постоянно читаю отзыв "провал"... Почему-же? ECO не развивается разве? Соглашусь только, что она, недостаточно распространена, что она очень слабо освещается, может даже ещё слишком "сырая"! Но ведь то-же ФП было десятилетиями забыто, а сейчас, как сказал один из участников обсуждения, "отъедает свой небольшой, но важный кусок рынка". Разве нельзя сказать, что с ECO так-же не будет? Учитывая, насколько быстро растёт сложность баз данных, то без более наглядного представления уже не обойтись! Вот, ту-же 1С к примеру приведу - даже при сотни справочников и документов, стороннему программисту сразу разобратся в их взаимосвязях практически не реально!

Ответ на »сообщение 81« (Александр Воробьев)
___________________________
Если вам сокрушительный провал Bold/ECO ни о чем не говорит, то посмотрите хотя бы на полное запустение в этом сегменте рынка.
MDA это маркетинговый термин, а не технология. Это именно самый что ни на есть лохотрон.

Изначально MDA это был (и есть) всего лишь свод правил, некий неформализованный подход к созданию больших систем.
http://en.wikipedia.org/wiki/Model-driven_architecture

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

"И я не вижу на горизонте ничего нового для графического программирования."
А что вы думаете про MDA и OCL??? Лично мне кажется очень перспективным. Все остальные решения, основанные на UML, лично меня не впечатляют... Может, потому-что я их плохо знаю! :)
Существуют ли сейчас какие-нибуть MDA технологии, кроме ECO?

Ответ на »сообщение 79« (Николай)
___________________________
Извините, я не догоняю. Что такое общее программирование?
А "язык общего назначения паскаль" вы догоняете ?
UML это попытка генерации кода общего назначения (то есть любого кода в принципе) а не только конкретных задач типа GUI, или других рисовалок (САПР).

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

Попытка войти в общее программирование у графических средств провалилась, причем в самое удобное и выигрышное для них время. А сейчас и подавно об этом думать поздно.

Извините, я не догоняю. Что такое общее программирование?
И разве САПР типа автокада - это не графическое программирование? Разве оно успешно не функционирует?

Ответ на »сообщение 76« (zero)
___________________________
Да, я писал об этом см. сообщение 60.
Автор ДРАКОН-редактора, сам 1С программист, предложил его для 1С средств.

Ответ на »сообщение 68« (Александр Воробьев)
___________________________
"произошло еще в эпоху полновластия ООП" - я что-то пропустил? Эпоха прошла? И что сменило ООП?
Эпоха ООП не прошла конечно (я вряд ли когда пройдет). Просто перестала быть полновластной. Сейчас ФП уверенно отьедает свой небольшой, но важный (многопроцессорность, распараллеливание) кусок рынка. Попробуйте впихнуть парадигмы ФП в блок-схему UML :))

гуи руками писать - верх извращенства! 

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

Ответ на »сообщение 75« (Как слышно? Прием!)
___________________________
Есть еще отечественный ДРАКОН: http://www.computerra.ru/readitorial/418507/
и его обсуждение на Компьютерре:
http://www.computerra.ru/forum/index.php?PAGE_NAME=read&FID=24&TID=332361

Ответ на »сообщение 67« (Jack Of Shadows)
___________________________
Слухи о смерти графических методов следует считать преждевременными :)
Например:
http://en.wikipedia.org/wiki/IDEF5

Ответ на »сообщение 72« (Cepгей Poщин)
___________________________
Я 1С привел как пример системы (пусть узко специальной), в которой сведено к минимуму написание кода. Обсуждать преимущества и недостатки самой системы 1С мне тоже лениво.

Ответ на »сообщение 71« (Как слышно? Прием!)
___________________________
>>> Именно из-за того что впопыхах создали стандарт
Некоторое время назад я всю эту чехарду с буржускими откровениями наблюдал, пможно сказать, из первого ряда. Появилсь, например, MRP, все тут же начинают кричать, что это прорыв, это гениально... и все тут же делают MRP-системы (не особо понимая, что это за зверь такой). Потом появляется ERP, который снова подается как панацея от всех и всяческих проблем. И все теперь уже делают ERP-системы. Однако проблемы как были, так и остаются.

Приходилось садиться и разбираться, что же это за звери такие.

Практика показывает, что имеет место примерно следующее: берется какой-то частный случай, тщательно прорабатывается, стандартизируется и тут же реализуется в каком-то софте. И плевать, что имеем сферического коня в вакууме: главное есть броский слоган, работающая софтина и готовый стандарт.

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

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

Вот такая вот петрушка :(

Ответ на »сообщение 69« (Geo)
___________________________
А в той же 1С как узкоспециальном инструменте кодирование на языке вообще сведено к минимуму. Не скажите. Программисты на 1С стоят, при прочих равных условиях, дороже чем на Delphi. Оно и понятно, доплата за вредность идёт :) Почему она цветет и пахнет, так эта тема к UML и программированию вообще, не относится.

Ответ на »сообщение 69« (Geo)
___________________________
>>> UML -- это попытка застолбить нишу, захватить приоритет, задать стандарт.

Согласен.
Именно из-за того что впопыхах создали стандарт,
наворотили мешающие частности он и застопорился.

Ответ на »сообщение 67« (Jack Of Shadows)
___________________________
>>> для быстрой наброски идей я использую  FreeMind

Это не графика.
Текст организованный в фолдеры.

Ответ на »сообщение 67« (Jack Of Shadows)
___________________________
UML -- это попытка застолбить нишу, захватить приоритет, задать стандарт. "Провал" UML -- это всего лишь провал UML, но отнюдь не провал использовния CASE-средств для разработки программного обеспечения. Для разработки больших систем использование чисто текстов на языке программирования неэффективно: слишком много кода, слишком много однотипного кода, слишком сложно удерживать целостность. И инструменты визуального проектирования (та же Delphi) это показали, хотя это пока лишь промежуточный этап перехода от кодирования к проектированию.

А в той же 1С как узкоспециальном инструменте кодирование на языке вообще сведено к минимуму. И ничего... эивет и процветает.

"произошло еще в эпоху полновластия ООП" - я что-то пропустил? Эпоха прошла? И что сменило ООП?

"То есть четко очерченные ниши" - ага, как и у "текстового программирования" то-же своя ниша! Которую глупо смешивать с "текстовым программированием"! К примеру гуи руками писать - верх извращенства!

Лично меня UML заинтересовала только в контексте MDA. Даже если учесть, что это совсем не новая парадигма, у меня всёравно стойкое ощущение, что она "ещё сырая"... Но другую эволюцию средств работы с данными, кроме MDA - я представить не могу!

Странно что на этой ветке возобновилось обсуждение. Давно уже ясно что идея UML с треском провалилась. Более того это произошло еще в эпоху полновластия ООП, той самой парадигмы для которой UML и создавалась.
Провал UML это еще одно убедительное доказательство что альтернативы тексту в программировании нет, и вряд ли появится. Максимум чего можно будет отдать на откуп графическим рисловалкам это то что они уже и сейчас неплохо делают: ГУИ, отчеты, схемы реляционных БД. То есть четко очерченные ниши.

А вот для быстрой наброски идей я использую  FreeMind: http://freemind.sourceforge.net/wiki/index.php/Main_Page

Ответ на »сообщение 63« (Сергей Перовский)
___________________________
>>> Какое максимальное количество блоков приходилось рисовать?
Десяток-два. Естественно, на одном листе. Дальше нужна декомпозиция, схемы верхнего уровня, но там уже все намного прозе (или сложнее), и там уже не требуются блок=схемы. Еще раз, блок-схемы рисую для разработки каких-нибудь навороченных ветвистых алгоритмов, типа, парсинг, анализ посимвольного ввода и т.п., где куча IF-ов, порядок которых может изменяться. Сначала рисуется блок-схема тупо в лоб, потом анализируется и перерисовывается, чтобы быть поэффективнее: а потом по этой блк-схеме пишется код.

>>> Да еще, а какой инструмент используется для оформления блок-схемм?
Бумага и ручка. Причем, нотация упрощенная: лишь бы мне было понятно.

Я же не призываю рисовать блок-схемы всего кода для SAP R/3 :D

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

Я задам такой вопрос.
Почему целое больше, чем сумма частей?
Потому, что в целом есть ещё совокупность связей - структура.
Структура образует каркас, сохраняющий целостность системы
даже при смене отдельных объектов или их дефектности.

Именно для её отображения и требуются графические методы.
Текстовой набор описаний связей не отражает структуры как целостности.
Между тем именно особенности структуры являются определяющими в системе.

Рассмотрим объектный граф системы, состоящий из N объектов.
Число связей между ними N(N-1)/2 (имеются в виду одиночные связи).
Теперь введем вес связи, который характеризует существенность её для модели.
Ограничимся только теми связями, вес которых больше некоторого порогового уровня.
То есть введём параметр точности модели.
Теперь будем увеличивать порог с тем, чтобы число связей было обозримым.
Откуда следует, что полученная структура будет иерархической?
А структурное программирование и ООП навязывают нам именно такой
"единственно правильный" выбор.

Системы, построенные на основе естественноструктурированной модели
при объединении не будут требовать переделки с нуля,
так как в них уже выбраны существенные связи.
Требуется лишь добавление связей между объединяемыми подсистемами.

Это было озвучено переходом от подхода алгоритмирования к моделированию.

Ответ на »сообщение 63« (Сергей Перовский)
___________________________
>>> какой инструмент используется для оформления блок-схемм?

Пока самый эффективный - карандаш с бумагой.
Позор программистам!
Именно поэтому UML и блок-схемы - имеют "посмертное" применение.

Ответ на »сообщение 61« (Geo)
___________________________
А я, например, блок=схемами пользуюсь достаточно часто. Если разрабатываю какой-нибудь сложный "ветвистый" алгоритм.
Какое максимальное количество блоков приходилось рисовать?
На мой взгляд, как только блок-схема перестает помещаться на листе, ее смысл проподает.
Да еще, а какой инструмент используется для оформления блок-схемм?

Ответ на »сообщение 61« (Geo)
___________________________
... так сейчас они, например, пишут технические задания (вместо заказчика) ;-) Тем не менее, ни где в вакансиях я не видел чтобы среди требований значилось умение писать ТЗ и рисовать блоксхемы :o)
Ну допустим Пушкин рисовал рядом со стихами еще и картинки, однако ж ни кто не думает, что это обязательное требование для хороших стихов. А вот с UML почемуто по другому.

Ответ на »сообщение 57« (Сергей Перовский)
___________________________
>>> Как когда-то программисты делали блоксхемы задним числом для отчета...
... так сейчас они, например, пишут технические задания (вместо заказчика) ;-)

Это же не значит, что ТЗ не нужны. Просто нет у разработчиков ни культуры разработки, ни времени на детальную проработку задачи. Поэтому -- филькины грамоты для того, чтобы красиво выглядеть.

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

Оберонщики, которые были основными критиками необходимости
графического подхода, активно развивают ДРАКОН
http://forum.oberoncore.ru/viewforum.php?f=62&sid=7419307ffd4aafa474f54acaab042307

Я, собственно, об инструментах выделения контекст-графа в семантической сети.
Либо о возможности произвольной (насколько возможно) группировки.

http://ru.wikipedia.org/wiki/Принцип_семантической_границы

http://ru.wikipedia.org/wiki/Семантическая_сеть

Ответ на »сообщение 53« (Сергей Перовский)
___________________________
Как говорил Штирлиц "запоминается последняя фраза" :)
>>> По мере декомпозиции модель быстро становится необозримой.
Так я и говорил "во первых строках письма",
что основной недостаток программ для работы с объектными графами -
это отсутствие эффективного инструмента композиции.

Структурное программировавние имеет тот существенный недостаток,
что построено на минимальной топологии связей.
Число связей равно количеству объектов минус один.
Можно бы было меньше - сделали бы меньше.
Корень задан. Все связи завязаны на предков. Дерево хрупкое.
Как Вы писали - при объединении двух моделей неизбежен крах.
Дихотомия от общего к частному.
1234
12-34
1-2-3-4
Графическое описание бессмыслено по причине вырожденности топологии.
Я говорю об инструменте, который бы позволял, например, при рассмотрении
3 элемента выделять только его семантическое окружение.
12-3-4
Схема обозрима, наглядна, а по сему эффективна при разработке.

Ответ на »сообщение 56« (Cepгей Poщин)
___________________________
Помните блоксхемы? :)
Начальство не желает читать текст программы. Считается, что картинки проще для понимания.
Как когда-то программисты делали блоксхемы задним числом для отчета, так теперь рисуют UML схемы для представления концепции высокому начальству.
Хотя, в обоих случаях считается, что схемы предшествуют программированию.
Если есть математическая модель, то программисту схема не нужна. А если нет, то можно, конечно, сначала поиграться в квадратики, чтобы понять, чего, собственно мы хотим добиться.

...однако во многих конторах, наряду с пунктом "требуется постоянная регистрация", есть пункт "требуется/желательно знание UML". :o) Интересно, кто-нибудь реально использует его в повседневной работе, или это не более чем "штамп в паспорте"?

Ответ на »сообщение 54« (Николай)
___________________________
>>> был страшно разочарован (как программист) образовашейся кашей из квадратиков и стрелок
"Сколько я ни встречал собак с забавными кличками, все они никуда не годились" (с) Джек Лондон
Сколько я ни встречал систем Reverse чего-то там, их результаты все равно нужно было потом обрабатывать, чтобы можно было разобраться и прочитать. И это не обязательно UML. Возьмем банальные программы ДОСовских времен, которые, взяв программу, восстанавливали ее ассемблерный листинг. Пока этот листинг руками не причешешь, понять что-либо невозможно.

Так что задача восстановления схем из работающей системы -- это из области фантастики. А вот задача построения системы по схеме -- это уже не такая уж и фантастика. Собственно, задача того же плана, что и построение машинного кода по тексту на ЯВУ.

Ответ на »сообщение 53« (Сергей Перовский)
считается, что если использовать не текст, а квадратики и стрелочки, то и менеджер поймет

Когда я впервые поставил себе на компьютер Rational Rose и сделал Reverse engineering для проекта Delhi, то был страшно разочарован (как программист) образовашейся кашей из квадратиков и стрелок.
Мне кажется, что подобный инструмент, обладающий такой универсальностью, как язык программирования, просто бессмысленен. А вот в для конкретных предметных областей их стоило бы иметь. Т.е. цель поставлена нереальная.

Ответ на »сообщение 52« (Как слышно? Прием!)
___________________________
То есть это как бы не для программистов, а для менеджеров.
Есть такое дело, считается, что если использовать не текст, а квадратики и стрелочки, то и менеджер поймет :)
Между тем UML - Unified Modeling Language - ЯЗЫК. И, как и языки программирования, должен читаться как компьютером, так и человеком. Программисты знают, что второе важнее.
Но восприятие схемы эффективнее, чем восприятие текста, только при низкой сложности. По мере декомпозиции модель быстро становится необозримой.
Стрелочки, аналогично GOTO, при больщом количестве безнадежно запутывают восприятие.

нет библиотек, состоящих из стандартно сгруппированных графических элементов.
По сути, Вы предлагаете аналог структурного программирования :)
Очень правильная идея.

Ответ на »сообщение 49« (Сергей Перовский)
___________________________
>>> И дело тут не в инструменте разработчика, а в отсутствии теоретической модели предприятия.

Если нет модели, то и говорить не о чем.

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

Это приводит к неудобству манипуляции со схемой и при разработке и при анализе.
С ростом сложности получаем растущий монолит.
Аналогия с текстовой программой - программа из одного модуля.
Т.е. отсутствие модульности.

Второе следствие отсутствия операции объединения подсхем - нет библиотек,
состоящих из стандартно сгруппированных графических элементов.
Т.е. отсутствие повторного использования ... не кода, а удачных сочетаний элементов.

Косвенная причина неудачи UML для программирования -
скатывание к ярлыку средства не разработки, а сопровождения проекта.
Посмотрите на инструментарий UML.
То есть это как бы не для программистов, а для менеджеров.
Отсюда ещё один напряг во внедрении.

Ответ на »сообщение 50« (Николай)
___________________________
Но где такие же мощные решения, сделанные на case-технологиях?!! Ау!!!
Я не могу назвать крупный продукт, построенный с нуля по единой идеологии и технологии.
Любой технологии!

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

Ответ на »сообщение 48« (Николай)
___________________________
А в очень крупных проектах, наподобие SAP R3, они вообще не используются. Там свои технологии.
Там используются технологии лоскутного одеяла.
Все эти крупные системы созданы путем скупки смежных решений и их сшивки между собой. За ними не стоит единой модели. База данных представляет собой физическое объединение разнородных баз с различными механизмами обмена информацией. Естественно, настройка подобной системы на конкретный объект превращается в танцы с бубном. А объединение систем, даже имеющих общую программную базу, при слиянии предприятий, вообще становится неразрешимой проблемой.
Я знаю довольно много людей, занимающихся внедрением и обслуживанием различных ERP-монстров. Все они отзываются о внедряемых продуктах исключительно непечатно.

И дело тут не в инструменте разработчика, а в отсутствии теоретической модели предприятия. Соответственно, она каждый раз создается интуитивно при очередном внедрении.

Ответ на »сообщение 40« (Victor)
___________________________
Заниматься и увлекаться стоит. Т.е. не стоит. Киньте монету!

Эти технологии (как я это понимаю) стоят на грани балансирования между огромными затратами на их использование (нужна корпоративная дисциплина разработок) и выйгрышем от их использования. Может статься, что затраты будут или равны, или меньше выйгрыша. Модный аргумент - проект становится независимым от личности программиста, чистейшая лажа. Программист и любой другой разработчик с точки зрения проектирования - тот же инструмент, что и любой программный продукт. От его замены будут такие же разрушения, как от замены VB на Delphi или наоборот. Не спасет никакая Rational Rose. Чем крупнее проект, тем значимее такой "инструмент", как программист. Поэтому, в свое время сильно желавший эти технологии освоить и притянуть на свою фирму, я постепенно к ним охладел. А в очень крупных проектах, наподобие SAP R3, они вообще не используются. Там свои технологии. Непонятно, за счет чего они живут. Хоть бы нашелся кто, и объяснил бы сию загадку IT-индустрии.

Ну, например, "методом тыка" мне не получилось средствами ECO создать аналог LookUp полей... Или не знаю, как сделать сортировку или фильтрацию данных в выборке... Причем, желательно, что-б при этом "курсор" не терялся. Да и вообще, много непоняток по работе с данными, если с ними через ECO работать...

Ответ на »сообщение 45« (чиполинский)
___________________________

А что, какие-то сложности? Я когда последний раз видел ModelMaker, то он при наличии литературы по UML осваивался "методом тыка" довольно быстро.

Кто-нибудь что-нибудь по ModelMaker6 (+ Delphi7) сказать может? Вроде бы надо освоить, но стоит ли время тратить? Тем более, что никакой литературы не нашел.

К сожалению, Bold ужа давно не развивается. Borland в своё время купил производящую их фирму, и похоронил Bold. Начал делать c нуля делать ECO - "Bold для .NET".
Вопрос к знающим:
Есть книги или ссылки с нормальным описанием этой самой ECO? Насколько оправдано её использование?

Начиная с Delphi7 появилась BoldForDelphi - технология, позволяющая создавать приложения БД очень быстро и эффективно. Работает так - Вы создаете UML-диаграмму базы данных, импортируете в среду Delphi, и после этого можете работать с классами БД как с другими классами вашего приложения.
Более подробно об этой технологии - www.fast-base.ru
Там же и про книгу Константина Грибачева, рассказывающей об этом.

Стоит вопрос о разработке проекта (типа дипломного) пока определяюсь... Стал чертить в BPWin - но, хотелосьбы в одном месте - модель, процесс, эмуляция (типа арены), ну и т.д. с выходм и классов и базы данных (не вчера сим делов начал заниматься, и полноценные исходники не получить,знаю) Проблемма - не умею (нет инфы) на Rotional Rose (если исковеркал название - изв-те). Кто-то реально разрабатывает проекты (не проги на коленках) с использованием всех этих штук и сопутствующих им стандартов? - Стоит увлекаться? Если да - ДАВАЙТЕ ТОГДА ПО ЭТОЙ ТЕМЕ ГОВОРИТЬ, ПОНЯТНО, НЕ СЛУЧАЙНЫЕ ЛЮДИ ЭТИМ ИНТЕРЕСУЮТСЯ - МОЖНО И НЕ ОЧЕНЬ "ДОХОДЧИВО"...

В последнем своем проекте (СУБД Oracle) для оганичения прав доступа я использую "Fine-Grained Access Control" (DBMS_RLS package).
Геморою конечно тоже хватает, иногда вылетают ошибки на ровном месте, с производительностью не все понятно, но зато какие возможности :)

Я написал статью по Rose Delphi Link...
Статья опубликована в мартовском номере журнала "Программист" за 2002 год, а также на моем сайте www.rdl.far.ru...

Мнения и пожелаиня отправляйте на мыло...

To iZEN
Кажется уже есть :

http://www.interface.ru/fset.asp?Url=/ca/news/n020116770.htm

Так, JBuilder 6 Enterprise теперь имеет UML-дизайнер в виде активной ImageMap с работающими перекрёстными/гипер ссылками на другие классы, через которые можно попасть на другие классы и диаграммы. Картинка строится при переходе со вкладки редактора на вкладку "UML" после динамического рефакторинга класса, код которого находится ещё в редакторе. И так может происходить для каждого класса проекта и библиотек Java! Картинки можно сохранить в файлах *.png Динамический рефакторинг, признаюсь, меня просто изумил.

Интересно, что-нибудь подобное будет в следующей версии Delphi?

Насколько я понимаю, Вы, ребята, умеете делать что-то в Delphi, пришлите мне парочку своих программ (только не вирусы), а я в свою очередь пришлю парочку своих (не вирусы), только сообщете мне свой e-mail!

Тоже очень нужен Rose Delphi Link Может подскажете где взять

2 Warcat
Вдогонку. На моем сайте сайте в "Проектах" http://www.arbinada.com/projects.html
есть документация по ONTARIO1. Там есть описания и картинки, как это все было сделано.

2 Warcat
Идеи "юзать" можно без ограничений ;-)
Относительно реализации - все примерно так и было сделано (MSSQL 6.5). Пользователь имеет права только на выполнение процедуры и не имеет никаких прав доступа к таблицам. Получаем "2.5-уровневую" трехзвенку. Маленькая поправка: передавать в процедуру UID не надо, т.к. в текущей сессии доступна системная @@SPID и фуекции типа user_id(), по которым извлечь UID из таблицы пользователей нетрудно (Необходимо хранить логин пользователя, как атрибут класса или сущности "Пользователь").

To Сергей Тарасов:
Ну я за три дня размышлений на эту тему что-то подобное вырисовал, но вот идея с шаблонами прав доступа - класс! Меня то больше всего вопрос мучал, что слишком громоздкое решение задачи получается, а хранить только отклонения от шаблона группы в голову не пришло :(
Можно идею поюзать? :-)

По поводу реализации: у Сергея описана только модель, а реализации совсем чуть-чуть. Я кое-что пробовал уже по ходу трехдневного изобретения велосипеда. Использование хранимых процедур действительно удобно (как верно заметил уважаемый Lamer). Создаем login и пароль доступа к БД, под которым будет конектиться наше приложение. Это имя не имеет прав к таблицам, а имеет только доступ к выполнению хранимых процедур, причем в эти процедуры в качестве параметра необходимо передать UID, выданный при вводе logina и пароля доступа к программной системе. (Пользователь вводит логин+пароль, вызывается хранимая процедура, которая в случае правильности ввода возвращает его UID.) Т.е. даже если злоумышленик взломал пароль, под которым приложение конектиться к БД, это не дает ему возможности получить информацию из таблиц данных в обход хранимых процедур. Таким образом получаем два уровня защиты: имя и пароль приложения, имя и пароль пользователя. Два уровня лучше чем один :)
Жду критики по поводу реализации.

P.S. Приложение создается под MSSQL7.0. Все эксперименты соответственно с ним.

Коллеги, несколько лет назад я реализовывал систему безопасности ан TSQL. Возможно вам будет интересно ознакомится с моделью, приведенной в статье.
http://www.arbinada.com/articles.html

Кстати, мой сайт перехал на
http://www.arbinada.com

А еще лучше - хранимые процедуры. Можно и выборки нужные делать. И ограничений меньше ( как отсутствие order by в view ).

В догонку...
Хотя вообще-то это будет ограничение прав доступа на стороне
клиентской части, правильнее все же использовать View.

to Warcat
Сложная система+сложные запросы -> сложная система разграничения прав доступа.
Вообще для каждой таблицы (или для группы таблиц) может быть своя функция проверки, какие строки можно "показывать" данному пользователю, а какие нет.
Для реализации функции разграничения прав доступа возможно потребуются дополнительные "конфигурационные" таблицы.
Что касается рассчетов, то они должны быть реализованы на "стороне" сервера в виде отдельных процедур, функций, пакетов (и т.п.)

to BAV:
100 таблиц, 100 пользователей! + сложные запросы (выводить эту информацию пользователям нельзя, а в расчете она участвовать должна) + делегирование прав от пользователя к пользователю + необходимость это все администрировать. Вопрос в том, какие структуры данных необходимы для вычисления функции "функция_проверки_прав(user)". Вопрос в организации взаимосвязи между объектами и между таблицами. Простой проверкой: if "сидоров" then "выводить информацию" здесь не обойтись. Скорее так: if "сидоров" then "выводить информацию из определенных строк и столбцов, а в расчете применять определенные строки других таблиц". Как и где хранить информацию об "определенных" строках и столбцах?

to All: интересуют не только ршения, но и идеи, модели. Все-таки тема про UML :)

И вообще такая организация системы безопасности реальна?

to Warcat
Выбирать (апдейтить etc) строки, пока функция возвращает определеное значение

Например,
select ...
from ...
where функция_проверки_прав(user)=1;

В самой функции реализуешь проверку что можно пользователю user.
Или я может вопрос не так понял?

to BAV:
Прошу прощения. А нельзя ли подробнее. Каким образом мне поможет функция в условиях запроса? Имеется ввиду в каждом запросе проверять возможность его выполнения для текущего пользователя? А как в таком случае организовать администрирование системы безопасности?

Насчет View: для групп пользователей это действительно хороший вариант (досконально еще не разбирался), но требования ТЗ - разграничение прав на уровне пользователя. А пользователей в системе может быть больше 100. А последнее требование: делегирование прав доступа. :-((( Эх... огрчает меня это.

2Warcat
Может быть использовать функцию в условии запроса?

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

Чего-то заглохла тема :(

А кто проектировал систему безопасности программного комплекса? Посоветуйте , если не коммерческая тайна конечно :), как решить проблему разграничения доступа к отдельным объектам и соответствующей им информации из БД. Проблема собственно говоря в том, что заказчик желает увидеть разграничение доступа на уровне строк в таблицах БД.
Есть вариант завязать эти таблицы с таблицей пользователей отношением многие ко многим с указанием прав доступа, но таблиц в базе около 100 и связей получается "количество пользователей"*"количество записей в этих таблицах". Да и не решает это проблему сложных запросов, при которых "невидимая" для пользователя информация должна участвовать в расчетах.
Может быть какой-нибудь сервер БД умеет разграничивать доступ на уровне строк таблицы?

Давайте ..
Ну у меня одна сессия к базе, но я делаю так .. при создании объекта
управления БД (ОУБД) передаю ему как параметр рабочую сессию.  При создании любого объекта бизнес логики (БЛ), передаю ему как параметр объект управления БД для этого класса. По идее если много сессий, можно создать несколько ОУБД для каждой сессий, а при создании объекта БЛ передавать ему нужный объект ОУБД. Imho ..

Давайте все-таки опытом пообмениваемся!

При создании объекта, однозначно связанного с базой данных, в методе Create одновременно добавляю данные в таблицы базы данных (вызываю метод класса работы с базой данных). Все логично и хорошо, но... Чтобы добавить запись мне нужно знать к какой базе я ее добавляю. По заданию у меня может быть несколько Connections. Так где логичнее всего хранить Connection на базу?
Я сделал так: Connection хранится в объекте бизнес-логики (чей метод Create я вызываю), но тогда приходится передавать его в качестве параметра в методе добавления даннных в таблицу (и вообще во все методы работы с базой данных).
Преимущества: очень гибкая система, с возможностью переключения с одной базы данных на другую.
Недостатки: необходимость постоянного использования дополнительного параметра при вызове методов работы с БД.

Может кому будет полезно, еще информацию (правда на english ;( )  по ооп для Delphi можно найти в конференции borland.public.delphi.oodesign (newsgroups.borland.com)

Хочу выразить благодарность Игорю Мазурову. Книга, которую он посоветовал ("Объектные модели" Петер Коуд), действительно стоящая. Не абстрактный язык описания объектов, а конкретные примеры использования. В качестве примеров взяты: приложение для торгового терминала, приложение для склада, приложение для оформления заказа, два приложения реального времени. Рекомендации, советы, примеры... Есть с чем сравнивать свои решения и есть чему поучиться.
Спасибо Игорь.

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

1. Scott W. Ambler, www.ambysoft.com
Главы из его книги "Building Object Applications That Work". Документы доступны в PDF-формате. Кроме того, у него есть статьи в журнале "SD-magazine", раздел "Thinking Objectively", (www.sdmagazine.com) и кое-где ещё (ссылок не помню).

2. Mark R. Fussell, www.chimu.com
Foundations of Object-Relational Mapping

3. Wolfgang Keller, ourworld.compuserve.com/homepage/WofgangWKeller
Object/Relational Access Layers

4. Project Arcus, www.objectarchitects.de/arcus/
Wolfgang Keller, Jens Coldewey: Relational Database Access Layers
Jens Coldewey: Decoupling of Object-Oriented Systems

5. www.citforum.ru/programming/oop_rsis/index.shtml - за точность ссылки не ручаюсь. Доступно и в FTP-архиве сайта.
С.С.Гайсарян: Объектно-ориентированные технологии проектирования прикладных программных систем

А танцевать можно от "печки" - www.cetus-links.org. Правда, там многие ссылки уже ведут в никуда.

И ещё. Поддерживаю Игоря Мазурова: очень интересуют любые примеры, в частности, приёмы сохранения объектов в РСУБД. К примеру, возникают вопросы, когда объекты составляют агрегацию (например, объект владеет списком других). Классический пример - комбинация "Заказ - пункты заказа".

А вообще-то складывается ощущение, что объектный подход при всех его преимуществах рассчитан в основном на большие и очень большие системы (Enterprise-масштаба). На небольших задачах он "отъедает" у аббревиатуры "RAD" первую букву, превращая RAD сами видите во что :). Но отказываться не хочется - больно красиво!

PS. В своё время в Книге Песка была дана ссылка на сайт www.delphioop.com, который мог бы разрешить многие вопросы по теме. Да вот беда - уже несколько месяцев никаких обновлений.

To: Александр Кордюм

Книжка  М. Фаулер, К. Скотт, "UML в кратком изложении", так себе,
весь смысл в том , что это краткое изложение и опять ничего конкретного.
И link Delphi-Rose, по моему мнению - очень и очень сырая вещь,
много с ней возни и мало результата. Как говорили в одной из книг,
люди и не представляют как много можно сделать с простым Visio и
Microsoft Word. (Это я про замену Rational Rose ;) )

30-дневную trial-версию Ensemble Rose Delphi Link можно найти на
http://www.ensemble-systems.com/

Добрый день.
1) Кратко процесс использования UML изложен в книге
М. Фаулер, К. Скотт, UML в кратком изложении.
гл. 11 UML и программирование. В главе 18 страниц (формат A5),
но привязка к JAVA.
2)UML Rational Rose действительно во многом дублирует документацию,
но там хоть конкретные примеры использования даны.
3)Люди добрые, поделитесь, пожалуйста, link Delphi-Rose.

C уважением, Александр.

Что хочу сказать, начав знакомится с темой объектного моделировани и далее прочитав книгу Буча, я ей очень заинтересовался. Начал разбираться с Rational Rose, но она плохо поддавалась для изучения .
Со временем я конечно понял и принципы UML и как это делать в Rational Rose. Но не хватало конретного - что и как делать в каких случаях. Случайно нашел книжку в магазине "ОБЪЕКТНЫЕ МОДЕЛИ, Стратегии,шаблоны, приложения" с примерами объектных моделей. Там довольно подробно разобраны примеры , но опять же не касаясь конкретного языка программирования.  Если судить по книжке - самое главное , это как раз строить диаграммы классов и их взаимодействия. Даны рекомендации и по программированию , разделить программу как бы на 4 слоя :
1) классы доступа к БД 2)Бизнес-логика (тоесть классы ОМ) 3) Классы интерфейса пользователя 4) Классы внешних систем (если есть)
Во всех остальных книжках  которые пока встретил, только описание самого UML, либо как пользоваться Rational Rose, либо простейшие примеры , которые ничего не говорят. Поэтму интересуют конкретные результаты в этой области ... У кого нить есть кокретные результаты ?
Классы,диаграммы,исходники ??

To Лыткин Павел.
Да где-то строк десять и написано :(
Я потому и пытаюсь устроить обмен опытом в этой области, потому как нигде ничего приличного по данной теме не нашел. Приходится все придумывать самому с нуля, а изобретение велосипедов на мой взгляд занятие не из приятных. Одно дело придумывать что-то новое, а другое дело барахтаться в проблеме с ощущением, что все твои решения уже давно придуманы и тратишь время на элементарщину. Да и качество принимаемых решений сравнивать не с чем. Как я могу сказать, что мое решение лучше по каким-то параметрам, если я не знаю других решений.

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

Кто знает какие-нибудь книги с примерами моделирования систем БД, подскажите, pls, где найти или хотя бы названия.

Быть может, кому-нибудь будет полезно - загляните на www.boldsoft.com. Предлагается продукт "Bold for Delphi", позволяющий создать, как рекламируется, готовое приложение (включая базу данных, если не изменяет память) по диаграммам из Rational Rose. Включает множество компонент (аж на пять страничек палитры VCL). Доступна trial-версия.

To Warcat: не можете подсказать поконкретнее, где у Буча пример иерархии классов, ответственных за обмен данными с сервером? Если имеется в виду глава 10 (по-моему) "Системы Клиент-Сервер" из книги "Объектно-ориентированный анализ и проектирование с примерами на C++", то там этому (именно обмену данными) посвящено дай бог 10 строчек.

To All: кто-нибудь знает, где в Сети найти книгу "банды четырёх" (E.Gamma, R.Helm, R.Johnson, J.Vlissides) "Design Patterns"? А в переводе (хотя бы часть)?

С уважением

На счет книги "UML Rational Rose". Честно говоря книга на мой взгляд так себе. Я бы ее назвал просто "Rational Rose", так как полезной информации по UML там очень мало. Описания на уровне: "Чтобы сделать то-то, нажмите на такую-то кнопку". С Розой можно разобраться и с помощью встроенного хелпа. Так что рекомендую эту книгу только тем у кого совсем уж не лады с английским, ну и у кого есть лишние деньги на покупку таких книг :)
Инжиниринг в Розе действительно глючный. Возникали проблемы. И примеры с ней как назло на VB. Там-то с отношением между классами попроще будет, ну в смысле мало что придумать можно. (Хотя может я просто плохо VB знаю). А вот в VC++ она код генерит коряво :( Ну а кто говорил, что будет легко :)

to Дмитрий Пугиев
Прошу прощения, если я не совсем четко выразил свою мысль, но я имел ввиду не вопрос физического создания базы данных, а скорее общий подход к написанию такого рода приложений. К примеру, у Буча в примере приводится иерархия классов - транзакций, которые отвечают за обмен данными с сервером базы данных. Также хотелось бы услышать мнение народа о Three-Tiered Service Model. Я сейчас занимаюсь подобной проблемой и боюсь зациклиться на одном решении, но если получится что-нибудь достойное внимания, расскажу.

Все это мужики класно.
Но вот столкнулся с живой проблемкой.
Когда начинался проэкт то небыло ничего...
Абсолютно.
Тоесть никакой нормальной проэктной документации неыло и нет вообще.
Ситуация такая что я один могу разобратся в исходниках.
Ок все было поделено на части и роздано разным людям.
Я в этих частях разбираюсь, ибо их основу я делал.

Теперь продукт дорос до продажности.
Нужна дока, возможно перенос на другую платформу.

Поскольку UML это вещь стандартизированная то мне нужно провести
реверс инжиниринг проэкта.

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

Тот кто знаком с UML поймет, что схема зависимостей класов это ничто
по сравнению с полным использованием возможностей UML.

Ну, кто что посоветует.
Rational Rose есть. (evaluation но это не столь важно)
Rose Delphi Link тоже есть.
Ок втягивает он из мох исходников данные в Rose, а дальше?
Все ж ручками, нужна методологи использования UML в
софтверной разработке.

Книга Гради Буча "Объектно-ориентированный анализ и проектирование
с примерами на C++" доступна по адресу:

http://www.sympad.net/etext2/doc/programm/theory/ooad/booch/

Добрый день.
1)Вышла книга: UML Rational Rose; авторы У. Богтс, M. Богтс;
издательство - Лори.
2)Кто поделитcя: link Delphi-Rose. Заранее благодарен.
C уважением.

Кстати, чуть не забыл, не советую использовать инжиниринг в Розе. Программы получаются корявыми. А вот наоборот из программы->модель терпимо.

to WarCat
а я и не использую RoseDelphiLink. Я создаю базу данных динамически на основе модели. И получаю информацию о модели через COM.

Вспомнил!!! Книга называется (естественно :))) "UML. Руководство пользователя." Авторы: Буч, Рамбо, Джекобсон. Издательство (приношу извинения за неправильную информацию) "ДМК".

Я на работе тоже строю модели на Rational Rose, но модуля перевода модели в код Delphi у меня нет :(
Организации он не нужен. (Кодирование идет на MS Visual C++.) Соответственно ничего о взаимодействии Розы и Delphi сказать не могу, но сама по себе Роза инструмент мощный и удобный (не без глюков конечно :)). Перед началом работ пришлось сравнивать несколько пакетов CASE-средств, Роза понравилась больше всего. Так что всем рекомендую.
Главное преимущество Розы - полное соответствие стандарту UML. В этом нет ничего удивительного. Ведь отцы-основатели UML работают в Rational. И Буч, и Рамбо, и Джекобсон.
Кто хочет разобраться с UML и вообще с ООП рекомендую книгу Буча "Объектно-ориентированный анализ и проектирование" (видел в электронном виде на www.dore.ru). Недавно вышла книга по UML "отцов-основателей" на русском языке. Название не помню, но помню, что выпустило ее московское издательство ДМВ. Правда тираж маленький и в электронном виде я ее не видел :(

P.S. И еше вопрос людям занимающимся моделированием. Интересно было бы узнать, кто какие подходы использует при проектировании приложений баз данных.

P.P.S. Подскажите, pls, где взять генератор дельфевого кода из Розы.

Я на работе пишу программу, которая использует RationalRose. Программа считывает модель и на ее основе создает базу данных и конфигурирует само приложение под конкретного пользователя.