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

B>Это смотря КАК его применять . ...
А как не применяй.

B>Что это значит "абсолютно бесполезен только в качестве документирования"???
Гн. Rovdo упорно придвигает мысль, что UML полезен исключительно для документирования готового проекта.

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

M>Гн. Rovdo упорно придвигает мысль, что UML полезен исключительно для документирования готового проекта.

Вы несколько утрируете мою мысль. Я считаю, что сегодняшнее позиционирование UML чересчур широко, в то время как наиболее успешным его применение является именно в сфере документирования проектов (заметьте слова "готового" здесь нет, выше я говорил о "готовых моделях", а не проектах целиком). В будущем мне кажется рациональным вытеснение UML из всех сфер, кроме документирования, более удобными и более интегрированными с кодом технологиями. Однако я не провидец — это скорее мои пожелания — в то время как индустрия пока движется именно в сторону усиления позиций UML не только в документировании. Говоря о сегодняшнем дне, я не вижу реальных альтернатив UML при реализации больших проектов (т.е. я не ставлю под сомнение текущую полезность UML, но согласен и с тем, что в ряде случаев мы платим снижением эффективности), но хотел бы их увидеть (если мы хотим повысить эффективность в больших проектах, то долджны искать замену UML).

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


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

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

Здравствуйте, Сомов Александр, Вы писали:


AF>>Гениально. Правда я где то видел обратный лозунг:
AF>>Долой код! Да здравствует UML!
СА>Где угодно, только не у меня.

Каждому городу нрав и права ... каждый имеет свой ум голова. (с) Г. Сковорода.

AF>>Да и денег у них поболее будет...
СА>А там эти лозунги — маркетинг. Нужно же UML продавать. Книги, ПО и т.д.

Отсутствие UML, как я уже говорил, тоже запросто может быть маркетинг, т.к. нужно продовать что-то другое .

Здравствуйте, Сомов Александр, Вы писали:

СА>>>Ну этот десяток стрелочек (уж если захотелось что-то рисовать, а не использовать великий и могучий) — описать совсем не проблема. На это уйдёт час. А на освоение UML?
B>>Хм ... а сколько у Вас лично ушло времени на освоение собственно UML????

СА>До сих пор осваиваю. Правда вяло очень, так как для работы не требуется. Исключительно из интереса.

Т.е. не владея языком, таки рассуждаете на тему применимости ... интересно. Что-то вроде, "сам я книгу не читал, но осуждаю ..." ... где-то я это уже слышал ...

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


AF> В целом верно. Правда, что именно имел в виду byur лучше спросить у него.

Только добавлю, что модель предметной области (domain model) входит в понятие модели анализа (analysis model) с т.з. RUP. Но в ряде случаев, досточно разрабатывать только ее.

Здравствуйте, Сомов Александр, Вы писали:

B>>Что есть эффективность? Эффективность эффективности рознь ...
СА>Скатимся сейчас в формализм, а толку не прибавится. Я ведь понятно выразил свою точку зрения.

Дьявол, как обычно, кроется в деталях. В нашем случае в определениях , как верно заметил один из участников.

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

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

B>А проектирования как такового больше нет???? Почему не рассматривается возможность ПРОЕКТИРОВАНИЯ на UML ... а только документирования ...

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

B>И кстати ЧТО вы хотите при помощи UML задокументировать?

Разработанные модели, которые могут быть уже реализованы в коде, могут быть нарисованы на бумаге, могут быть согласованы и сформированы в ходе длительного обсуждения и сидеть исключительно у вас в голове.

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

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


B>>Ну вот приехали ... додискутировались до того что есть "методологии UML" !!! И до того что Together НЕ ИСПОЛЬЗУЕТ UML!!!!

AR>Ну словили на слове. Конечно надо было написать "методологии, предполагающие использование UML". Что же касается Together, то конечно UML там есть (я ведь и не отрицаю необходимость UML вообще), но как-то это несколько по-другому что-ли, чем например в Rose. Он там как-бы на вторых ролях или уж во всяком случае не главнее собственно кода. Хотя я и не говорил, что Together это именно то, что нужно. Но некоторые моменты (лучшие средства синхронизации UML-моделей и кода) позволили мне сказать, что это "движение в нужном направлении".

По большому счету, логика у них примерно одинакова. Т.е можно СПРОЕКТИРОВАТЬ на UML, сгенерить код, ... поработать с кодом ... синхронизовать с моделью. И сам по себе Together и тем более представители Борланд (берусь сказать за С. Орлика ..., хотя это дело не благодарное ) не говорят про то что, главнее код или модель ... а говорят совершенно верно, в т.ч. с маркетинговой т.з. -- что если вы проектируете с использованием UML, и у вас есть определенная культура проектирования и разработки, приняттая в вашей компании, то это инструментальное средство вам поможет сделать вашу работу более эффективной, при условии понимания КАК вы будете его применять. И вообще они опираются на Agile методологии, насколько я понимаю. Agile отнюдь не означает "как мне вздумалось так и делаю". Можете посмотреть статьи С. Амблера (S. Ambler) если хотите понять суть этого.

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


B>>А проектирования как такового больше нет???? Почему не рассматривается возможность ПРОЕКТИРОВАНИЯ на UML ... а только документирования ...

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

Ой, опять про эффективность ... ну не нужно использовать термины, которым мы не сможем дать определения внятного ... "толк", "эффективно". Очевидно, что каждый в понятие эффективности вкладывает что-то свое ... Я уже задвал вопрос, что есть эффективно? В чем мы это можем измерять ... -- в единицах времени? А мы учитываем момент, что время, потраченное на проектирование именно с использованием UML СИЛЬНО зависит от уровня владения этим языком? Очевидно, если я не знаяю Smalltalk, то писать на нем программу я буду определенно дольше, чем на знакомых языках!!! Кроме этого, никто не мешает вам на доске нароисовать UML модель, сфотать на цифровик и вставить в ваш репозиторий проектирования! Так поступают в XP и Agile методологиях ... Разве не так? И все говорят на одном языке при этом ...

B>>И кстати ЧТО вы хотите при помощи UML задокументировать?

AR>Разработанные модели, которые могут быть уже реализованы в коде, могут быть нарисованы на бумаге, могут быть согласованы и сформированы в ходе длительного обсуждения и сидеть исключительно у вас в голове.

Почему-то ни у кого не возникает желания говорить о том, что ERD диаграммы в нотациях IDEF1x или IE не эффективны при использовании проектирования БД или понимания связей м/у сущностями БД!!!! И большинство разработчиков предпочитает увидить схему БД и работать с МОДЕЛЬЮ БД, а не с ddl-скриптами ... не наталкивает на размышления, а?

Здравствуйте, 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: Для внесения изменений прямо в код есть масса замечательных инструментов. Поэтому можно а) посмотреть на диаграмму, построенную по коду, б) уяснить задачу, в) спланировать рефакторинг, г) применить рефакторинг в несколько кликов, д) среверсить диаграмму еще раз. Получается дешевле чем а) посмотреть на диаграмму, построенную по коду, б) уяснить задачу, в) переколбасить диаграмму, г) перенести изменения в код.

Здравствуйте, 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>среверсить диаграмму еще раз. Получается дешевле чем а) посмотреть на диаграмму, построенную по коду, б) уяснить задачу, в) переколбасить диаграмму, г) перенести изменения в код.

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

Здравствуйте, 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 модели, способный корректно внести изменения в реализацию? Пример с БД я привел. Пример с классами мне, если честно, приводить лень. Есть ли тул, который поможет мне сгенерить эту пару классов-развязок, и заменить ссылки в методах существующих классов так, чтобы все осталось корректно? Для рефакторинга в коде подобные инструменты есть.

Я все-таки немножко реабилитирую ERD. В отличие от UML, иногда действительно можно использовать CASE-средсвта (ErWin, PD), работающие с ER-диаграммами, именно в процессе разработки. Я сам иногда практикую такое. Но это возможно, во-первых, только для новых систем (рефакторинг существующих баз с информацией, которую нельзя удалять, не прокатит), во-вторых, это означает, что мы делаем модель, например, в ErWin и только в ErWin, минимизируя любую ее правку средствами СУБД. И еще один момент: опираясь на ERD, мы имеем проблему, когда нам нужно не только задавать структуру БД, но и инициализировать ее какими-то исходными данными — современные CASE-средства для этого приспособлены крайне плохо. Важно, однако, то, что (кроме указанной проблемы с самим данными) реализуя модель средствами СУБД мы не располагаем практически никакими дополнительными возможностями (не можем руками/скриптами создать какие-то особенно хитроумные структуры), недоступные нам при проектировании в CASE-системе.

Собственно сама возможность использования ERD на этапе проектирования баз данных обусловлена именно практически полной эквивалентностью доступных инструментов с традиционными скриптовыми возможностями SQL и гибкими средствами синхронизации, имеющимися в современных CASE-системах. Они действительно позволяют синхронизировать модель с "кодом" (реализацией БД) в обе стороны почти без потерь (к сожалению теряются сами данные в таблицах). Но вот про UML-инструменты такого сказать уже нельзя, т.е. синхронизацией сегодня приходится заниматься вручную, а сами возможности кода много шире возможностей UML. Т.е. UML-модель, в отличие от ERD, не полна и в общем случае полной быть и не может, что существенно ограничивает наши возможности при проектировании средствами UML и затрудняет синхронизацию UML с исходным кодом.

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

S>Конечно. Я невнятно выразился — утверждение сводится к тому, что затраты на проектирование в UML уходят не на то, что требует глубокого владения. А на рутинную работу по синхронизации кода с моделью.

для этого можно использовать case средства.


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

B>>Не правда ваша ... Проектирование проектированию рознь ... что выимете ввиду под деталями??? И что и на каком уровне вы проектируете?
S>Ну как — допустим, это 3-tier система. Точнее указать количество tier и сервисов, которые потребуются, в начале процесса проектирования невозможно.

Хм ... архитектуру по требованиям не прикидываем вообще? Кроме того, мне ну никак не нужно понимание звенности, при посторении domain model .

B>>Кстати, UML и на салфетке можно рисовать ... никто не мешает .
S>Верно. Только на свлфетке обычно рисуют гораздо менее формально, чем UML. Тут тебе и три типа диаграмм в одном, и на ходу изобретенные обозначения стереотипов...

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

S>>>2. UML не умеет многие из деталей реализации, которые важны при проектировании.
B>>Опять-таки ... проектирования ЧЕГО??? Проектирование оно ведь разное бывает ...
S>Проектирования приложения. Что включает в себя проектирование интерфейсов, классов, методов, сервисов, БД и т.л.

Интерфейсы, классы очень трудно отобразить на UML с заданной степенью детализации? Или о чем речь?

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

Не совсем понял ... на UML нельзя делать наброски?? Очень запросто . Кроме этого, я не понимаю что есть "полноценная UML диаграмма"? Я не встречал такого термина в литературе

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

Пожалуйста ... создание новой системы -- проектирование модели БД, лично я предпочту начать с ERD, чем сразу руками писать ddl. И так поступаю не только я один . Второй пример -- изменение требований к стсиеме, которое влечет за собой изменение в т.ч. и структуры данных -- добавление новых сущностей, изменение связей ... Изменения тоже бывают разные -- изменения структуры совершенно спокойно можно делать в ERD . Пример с Firebird и IBExpert из жизни ... изменяю структуру БД, причем в ERD я это делаю, генерю dll по ERD и прошу IBExpert сделать мне дельта-скрипт, который нужно проиграть на исходной БД. Вот пример автоматизации такой деятельности. Да, модификация данных (НЕ СТРУКТУРЫ!!!) это другая задача. Говорить какие задачи чаще, а какие реже -- не стоит ... ибо все равно у нас нет достоверной статистики ... а только ощущения .

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

S>Ни разу в жизни я не видел проектирования в ERD. Только в учебниках. Да еще и по IDEF0! Может, это от того, что я не сертифицированный?

Сорри, при чем тут IDEF0 ... это несколько из другой оперы ... возможно имелось ввиду IDEF1x?

B>>Это что в России дурным тоном считается??? С каких это пор? Если вы лично не пользуетесь, то это ваше личное дело ... просто видимо вам так удобней ... сразу в DDL, и все .
S>Конечно. И я обосновал, почему.

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

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

Может стоит разделить задачу модификации структуры и модификацию данных, но в рамках отработки выполнения изменения требований?

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

Я уже неоднкратно говорил о том, что если вы изанчально не работали на основе методологии, а сразу писали код -- то начинать использовать в середине UML, не понимая что вы ОТ НЕГО ХОТИТЕ, возможно и не стоит?
А если вы изнзначально работали в ссответсвии с методологией, и использовали UML, то скорее всего вы начнете изменения с исправления модели. А тулзов, синхронизирующих модель с кодом есть .. вы лично какие пробовали использовать?

B>>Во-вторых IMHO это не рефакторинг отнюдь ... не нужно бросаться такими терминами .
S>Ок, если не нравится — не буду. Я просто привык расширительно трактовать термины.

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

B>>Все-таки этот термин уже "забит" -- это еще один пример применения "нехороших" приемов в дискуссии -- придание другого смысла общеупотребимым терминам.
S>Да ладно вам. Тоже мне преступление!

Это не преступление а "запрещенный прием" дискуссий. Им часто пользуются наши депутаты на дебатах ... не будем уподобляться им.

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

Для начала имеет смысл понять, а нужно ли вносить изменения в модель и поддерживать ее актуальность? Это зависит от культуры или стандартов, принятой(ых) в вашей организации или от др. причин.

B>> А код то откуда появился??? Если вы его написали сразу, без использования UML ... то на кой реверсить его далее???
S>Как? Вы же сами сказали — большинство ващих знакомых разработчиков предпочитают видеть БД в ERD. Ключевое слово здесь — видеть. Текстовое представление не очень удобно. Но писать в UML/ERD имхо не менее неудобно.

Не писать, а проектировать ... . Писать это болше к коду все-таки ...

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

Точно пробовали? ... есть статистика какие изменения чаще происходят? Какие инструментальные средства использовали?

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

Я все-таки опять не удержусь..

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