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

B>>А мы учитываем момент, что время, потраченное на проектирование именно с использованием UML СИЛЬНО зависит от уровня владения этим языком?
S>Не, слабо зависит. Смысл в том, что водопадная модель не работает. Т.е. нельзя сначала спроектировать все в чистом UML, и больше к нему не возвращаться.

Стоп ... тут кто-то говорил про "водопад" ... или проектирование есть исключительно при "водопадной" модели?? ... не понятна такая посылка ... . Если вы внимательно читали дискуссию, то там шло аппелирование к RUP, Agile и XP ... а они отнюдь не проповедуют "водопоад", и вам это хорошо известно. Так зачем говорить про это? . Так что это вычеркиваем .

S>Я не очень знаком с UML; опыт применения довольно давний и уже почти забытый. Возможно, мои впечатления происходят от некомпетентности.

И при этом имеем смелость утверждать, что время проектирования с использованием UML НЕ зависит от степени владения

S>1. UML требует задавать слишком много деталей для уровня "проектирования на салфетке".

Не правда ваша ... Проектирование проектированию рознь ... что выимете ввиду под деталями??? И что и на каком уровне вы проектируете?
Кстати, UML и на салфетке можно рисовать ... никто не мешает .

S>2. UML не умеет многие из деталей реализации, которые важны при проектировании.

Опять-таки ... проектирования ЧЕГО??? Проектирование оно ведь разное бывает ...

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

Почему-то вы упорно связываете язык UML и case средства ... что, нельзя на бумаге набросать карандашем UML диагрммы??? Это проблема? Я в определенных случаях так и поступаю ... Где проблема?

B>>Почему-то ни у кого не возникает желания говорить о том, что ERD диаграммы в нотациях IDEF1x или IE не эффективны при использовании проектирования БД или понимания связей м/у сущностями БД!!!! И большинство разработчиков предпочитает увидить схему БД и работать с МОДЕЛЬЮ БД, а не с ddl-скриптами ... не наталкивает на размышления, а?
S>Хм. И много из твоих знакомых разработчиков проектируют СУБД в ERD? Все случаи ERD, которые я встречал в природе, были связаны исключительно с Reverse Engineering существующих баз. Есть, правда, один перец, который уверяет меня, что напропалую пользуется ERD в Visio при проектировании своих баз. Увы, то, что он выдает за ERD — фигня. То типы полей забыл проставить, то примари кей неверен... Их можно использовать только как намек на желаемую схему. Которую уже надо проектировать в DDL. Я, как правило, проектирую на бумажке, а потом напрямую в DDL. Может, я просто не владею хорошим инструментом для ERD-рисования? Есть тул, который умеет рефакторить базы? Вот у меня есть, к примеру, база. Я ее спроектировал, создал, накидал тестовых данных. Уже прикладной уровень и бизнес логика задействованы.
S>Простейшая проблема: заказчик приходит и говорит, что должность у Employee больше не одна, а несколько — в каждом департаменте своя. Я себе прекрасно представляю, как отрефакторить это (вместе с данными) в рамках DDL:

Все-таки давайте на Вы ... мы с вами не очень хорошо знакомы . Я помню, как вы про use cases со мной спорили, но это не повод на "ты" .. ОК?

Начноем с того, что мои знакомые таки проектируют БД а не собственно СУБД ...

По моим подсчетам, все мои знакомые ... (а среди них есть и сертифицированные разработчики Oracle в частности) используют ERD для проектирования и реверс-инжиниринга БД -- но я повторяю, что это не значит, что они не умеют или нехотят писать DDL руками ... просто есть много причин использовать ERD. Это что в России дурным тоном считается??? С каких это пор? Если вы лично не пользуетесь, то это ваше личное дело ... просто видимо вам так удобней ... сразу в DDL, и все .


S>Как мне отрефакторить это прямо в ERD? Чтобы все сработало? Пока что дешевше получается написать DDL, а потом отреверсить результат.

... как вы плавно от ПРОЕКТИРОВАНИЯ БД перешли к модификации ее структуры, и изменению ее данных! Это конечно ловкий прием сбить дисскуссию. Но давайте таки поговорим за проектирование , да?
Во-вторых IMHO это не рефакторинг отнюдь ... не нужно бросаться такими терминами . Все-таки этот термин уже "забит" -- это еще один пример применения "нехороших" приемов в дискуссии -- придание другого смысла общеупотребимым терминам.

S>Аналогичная проблема возникает в UML: Для внесения изменений прямо в код есть масса замечательных инструментов. Поэтому можно а) посмотреть на диаграмму, построенную по коду, б) уяснить задачу, в) спланировать рефакторинг, г) применить рефакторинг в несколько кликов, д)

А код то откуда появился??? Если вы его написали сразу, без использования UML ... то на кой реверсить его далее???

S>среверсить диаграмму еще раз. Получается дешевле чем а) посмотреть на диаграмму, построенную по коду, б) уяснить задачу, в) переколбасить диаграмму, г) перенести изменения в код.

А если так ... а) посмотреть на диаграмму, построенную по коду, б) уяснить задачу, в) спланировать рефакторинг, г) применить рефакторинг в несколько кликов, д) среверсить диаграмму еще раз и увидеть проблему; е) набросать на диаграмме пару классов-развязок ж) снова сгенерить код -- так ну ни как не получается??? так будет плохо???