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

B>В чем мы это можем измерять ... -- в единицах времени?
Конечно.
B>А мы учитываем момент, что время, потраченное на проектирование именно с использованием UML СИЛЬНО зависит от уровня владения этим языком?
Не, слабо зависит. Смысл в том, что водопадная модель не работает. Т.е. нельзя сначала спроектировать все в чистом UML, и больше к нему не возвращаться.
Я не очень знаком с UML; опыт применения довольно давний и уже почти забытый. Возможно, мои впечатления происходят от некомпетентности.
1. UML требует задавать слишком много деталей для уровня "проектирования на салфетке".
2. UML не умеет многие из деталей реализации, которые важны при проектировании.
3. В связи с этим проблемы с Round-trip Engineering.
В итоге оказывается, что для черновичков эффективнее именно бумажка и ручка (потому что меньше усилий для накалякивания схем), а для ведения документации рабочего проекта лучше иметь хороший инструмент визуализации кода (потому что иначе приходится тратиться на обратную синхронизацию).

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

alter table EmployeeDepartment 
    add PositionID int foreign key references Position

GO

update EmployeeDepartment set PositionID = e.PositionID from EmployeeDepartment inner join Employee e on e.ID = EmployeeDepartment.EmployeeID

alter table EmployeeDepartment 
    alter PositionID int not null

GO

alter table Employee drop column PositionID

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

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