Здравствуйте, byur, Вы писали:
B>И при этом имеем смелость утверждать, что время проектирования с использованием UML НЕ зависит от степени владения
Конечно. Я невнятно выразился — утверждение сводится к тому, что затраты на проектирование в UML уходят не на то, что требует глубокого владения. А на рутинную работу по синхронизации кода с моделью.
S>>1. UML требует задавать слишком много деталей для уровня "проектирования на салфетке".

B>Не правда ваша ... Проектирование проектированию рознь ... что выимете ввиду под деталями??? И что и на каком уровне вы проектируете?
Ну как — допустим, это 3-tier система. Точнее указать количество tier и сервисов, которые потребуются, в начале процесса проектирования невозможно.
B>Кстати, UML и на салфетке можно рисовать ... никто не мешает .
Верно. Только на свлфетке обычно рисуют гораздо менее формально, чем UML. Тут тебе и три типа диаграмм в одном, и на ходу изобретенные обозначения стереотипов...
S>>2. UML не умеет многие из деталей реализации, которые важны при проектировании.
B>Опять-таки ... проектирования ЧЕГО??? Проектирование оно ведь разное бывает ...
Проектирования приложения. Что включает в себя проектирование интерфейсов, классов, методов, сервисов, БД и т.л.
B>Почему-то вы упорно связываете язык UML и case средства ... что, нельзя на бумаге набросать карандашем UML диагрммы??? Это проблема? Я в определенных случаях так и поступаю ... Где проблема?
В том, что "набросок" — это не UML. Это костыль. Настоящее проектирование при этом происходит в голове. Если рисовать любую полноценную UML — диаграмму, то это очень много трудозатрат, которые пойдут в корзину. CASE средства позволяют хотя бы попытаться окупить эти титанические усилия.

B>Все-таки давайте на Вы ... мы с вами не очень хорошо знакомы . Я помню, как вы про use cases со мной спорили, но это не повод на "ты" .. ОК?
Ок, не проблема.
B>Начноем с того, что мои знакомые таки проектируют БД а не собственно СУБД ...
Прошу прощения — описка.
B>По моим подсчетам, все мои знакомые ... (а среди них есть и сертифицированные разработчики Oracle в частности) используют ERD для проектирования и реверс-инжиниринга БД -- но я повторяю, что это не значит, что они не умеют или нехотят писать DDL руками ... просто есть много причин использовать ERD.
Ну назовите мне хоть одну? Ни разу в жизни я не видел проектирования в ERD. Только в учебниках. Да еще и по IDEF0! Может, это от того, что я не сертифицированный?
B>Это что в России дурным тоном считается??? С каких это пор? Если вы лично не пользуетесь, то это ваше личное дело ... просто видимо вам так удобней ... сразу в DDL, и все .
Конечно. И я обосновал, почему.

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

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

B>А если так ... а) посмотреть на диаграмму, построенную по коду, б) уяснить задачу, в) спланировать рефакторинг, г) применить рефакторинг в несколько кликов, д) среверсить диаграмму еще раз и увидеть проблему; е) набросать на диаграмме пару классов-развязок ж) снова сгенерить код -- так ну ни как не получается??? так будет плохо???
Неа, не получается. Покажите мне генератор кода по UML модели, способный корректно внести изменения в реализацию? Пример с БД я привел. Пример с классами мне, если честно, приводить лень. Есть ли тул, который поможет мне сгенерить эту пару классов-развязок, и заменить ссылки в методах существующих классов так, чтобы все осталось корректно? Для рефакторинга в коде подобные инструменты есть.