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


S>4. Резюме: модель реляционной базы данных является проекцией более широкой модели данных, т.е. вытекает из архитектуры приложения. Приложение, источником архитектуры которого является база данных, я не куплю.
S>По этим причинам профессиональные разработчики никогда не проектируют базы данных в сервере базы данных. Сначала строится модель, причем как правило это либо UML, либо ER, либо лист бумаги, а затем по ней создаются таблички, индексы, и.т.п.

Спасибо за хороший итог — в отношении баз данных выводы всеобъемлющие

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

S>Подход "сначала выберем сервер, а потом начнем проектировать" я считаю вопиющим непрофессионализмом, т.к. выбор должен диктоваться требованиями, которые и определяются в процессе проектирования.

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

S>4. Резюме: модель реляционной базы данных является проекцией более широкой модели данных, т.е. вытекает из архитектуры приложения. Приложение, источником архитектуры которого является база данных, я не куплю.

Да ради бога. Тебе вопрос встречный: ты купишь проект который написан в UML просто из-за того что он написан в UML или всетаки посмотришь на реализацию. А если посмотришь на реализацию почему бы тебе и в первом случае тоже так не сделать. Вообщем не обобщай.

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

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

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

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

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

Позволю себе также подвести итог...
Дискуссия "имела место быть" ((С) pesticide)...
Перечитав n-й раз все, что было сказано, заказал-таки себе "Специальный справочник", так как мне показалось, что даже те, кто высказывался против использования UML все-таки изучали его (уж очень убедительные аргументы приводились ).
Использование же UML, наверное, отложу на потом, когда действительно возникнет необходимость.
Спасибо всем, кто делился своим мнением в ходе дискуссии!

A>Да средств проектирования много, почему бы тебе например на том же листке бумаги не записывать все в AnsiSQL и рисовать диаграмы. Причем здесь UML. Я читал несколько книжек по проектированию баз данных и ни в одной из них не упоминался UML(или толькол упоминанием дело и ограничилось), есть наверное и такие что целиком на UML ну и что? Это само по себе не говорит что UML Rulez.

Странно, а почему в книжках по проектированию баз данных должен упоминаться uml?
Мне казалось, что не это основная цель uml, а в конечном счете (то,что получается на выходе), проектирование спецификации классов, типов, и распределение обязанностей между классами. Кто за что должен отвечать, кто кого должен создавать, выделение искусственных сущностей, если это нужно, с высокой степенью зацепления (Pure Fabrication) и т.д. Поправьте меня, если я ошибаюсь.
С uml'лем легче применять паттерны (более нагляднее, например, взглянув на диаграмму кооперации, в общем, можно легко определить степени связанности, зацепления классов (coupling, cohesion)).
Но в общем, это всего лишь инструмент, облегчающий работу и понимание друг друга (кто и что все-таки имел в виду) :).
По поводу трудностей и ненужности его изучения: сам uml понимается за день, два. Другое дело привыкнуть к нему и суметь научиться грамотно проектировать в терминах uml (до недавнего времени мне казалось, что use case — это настоящее издевательство над проектировщиком, детский сад, но когда пришлось поиспользовать ассоциации include, extend, generalization для определения требований к автоматизации коммутаторного цеха, было недоумение по поводу нетривиальности получившихся диаграмм). По поводу ненужной траты времени на рисование диаграмм: соглашусь, что возникает ощущение бесполезности этого занятия. Но по опыту знаю, что понимание ТЗ в текстовом виде (обычно читается через строчку, что-то упускаешь, на что-то обращаешь меньше внимания) отличается от понимания ТЗ в uml-ом виде. Все-таки дальнейшее сопровождение облегчается.

Здравствуйте Anatolix, Вы писали:
Н-да. Печально. простейшие вещи... И приходится объяснять... Ладно, ок, последний пост в этот дурацкий флейм.
A>Здравствуйте Sinclair, Вы писали:

S>>Подход "сначала выберем сервер, а потом начнем проектировать" я считаю вопиющим непрофессионализмом, т.к. выбор должен диктоваться требованиями, которые и определяются в процессе проектирования.

A>Тогда приходится использовакть малую часть возможностей сервера. Кстати сайт rsdn ты тоже считаешь "вопиющим непрофессионализмом", его в данный момент нельзя перенести на другой сервер.
Прочитай фразу еще раз. Я ничего не гооворил про платформенную независимость. Я говорил о том, что сначала надо определить требования к системе, а потом выбрать, исходя из них, сервер базы данных (если он, конечно, вообще там нужен), и пользоваться его возможностями хоть на всю катушку. Спуск вниз по уровням модели не теряет возможностей низкого уровня. А вот наоборот — легко.

S>>4. Резюме: модель реляционной базы данных является проекцией более широкой модели данных, т.е. вытекает из архитектуры приложения. Приложение, источником архитектуры которого является база данных, я не куплю.

A>Да ради бога. Тебе вопрос встречный: ты купишь проект который написан в UML просто из-за того что он написан в UML или всетаки посмотришь на реализацию. А если посмотришь на реализацию почему бы тебе и в первом случае тоже так не сделать. Вообщем не обобщай.
Проекты не пишутся в UML. Они проектируются в UML. И никто не говорит "это сделано на UML". И я не буду смотреть на реализацию. Просто приложения, построенные исходя из базы данных, обычно являются говном. По критериям usability. Я понятно объясняю?

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

A>Да средств проектирования много, почему бы тебе например на том же листке бумаги не записывать все в AnsiSQL и рисовать диаграмы. Причем здесь UML. Я читал несколько книжек по проектированию баз данных и ни в одной из них не упоминался UML(или толькол упоминанием дело и ограничилось), есть наверное и такие что целиком на UML ну и что? Это само по себе не говорит что UML Rulez.
Похоже, ты любишь писать, но не читать. Я нигде не сказал, что UML Rulez. Записывать на листке бумаги ANSI SQL никогда не буду, потому что это нудно. Я нарисую название таблички (примерное, ессно), под ним квадратик, и буду вписывать в него имена полей. и рисовать стрелочки. И зачеркивать стрелочки. И снова рисовать, и в конце блин выкину этот кусок бумаги и запихаю это все в ERWin. А писать на листке бумаги

create table Order(
...
)

это бред.

В общем, итог:
Я не пытался ратовать за использование UML для проектирования баз данных. Я пытался объяснить что
а) Базы данных — не есть единственный вид приложений, которые бывают. Более того, это очень редкие виды приложений. Сходите хотя бы в зоопарк — я не вру. Я бы посмотрел на разработчика, который пишет TheBat "сразу в AnsiSQL". ХаХаХа.
б) Даже если приложение использует базу данных, то нельзя при его проектировании исходить из базы данных. А то блин относятся к своей БД как джинн к лампе... Это БД обслуживает модель! И никак иначе.
Из вышесказанного следует простой вывод: нужны средства проектирования, которые можно использовать ДО СОЗДАНИЯ кода. Да, если у вас база данных — проектируйте сразу в терминах реляций. Да, если у вас плюсы — моделируйте в виде заголовков классов. Паскаль — пишите интерфейсы модулей.

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

Здравствуйте Anatolix, Вы писали:
A>Потому что на изучение вего требуется время, при этом
A>есть вещи которые мне хочется изучить больше чем UML.

A>Кроме того зазубрить синтаксис один раз и считать
A>что все сразу будет круто ото помоему глупо, а т.к.
A>использовать я его не собираюсь, я не буду его и учит
A>т.к. все равно забуду.

A>Убедить же меня что мне надо работать в UML
A>(не зубрить синтаксис а именно работать) меня могут
A>слудующие вещи:
A>1) Корпоративные правила(сейчас никто UML у нас не юзает, так что
A>аргумент "UML это стандарт" не катит. В моей среде это не стандарт)
A>2) Осознанная крутость UML(здесь мне никто доказать этого не может,
A>я вообще не из вредности тут со всеми спорю, и не из-за того
A>что не люблю UML. Просто мне хочется найти хотя бы один
A>аргумент за UML на который мне будет нечего возразить)

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

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

Напр. в книге Роджерсона по COM есть UML Sequense диаграмма которая описывает создание COM объекта, там она очень уместна, очень помогает в понимании процесса при первом изучении. Трудно придумать более удобный и наглядный формат описания этого процесса. Но рисовать Sequence диаграмму для любой проэктируемой системы, так чтобы она описывала все процессы — это большая глупость. Правило простое — если удается выделить в системе область для которой та или иная диаграмма окажется информативной, значит надо ее рисовать.

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

Мне вот в последнем проекте полезными оказались Class diagram и Component diagram. Но проблема в том, что стандартный UML и различные инструменты слишком абстрактные не удовлетворяют всех потребностей. Мне вот больше была нужна модифицированная смесь этих двух диаграмм.

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

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

SS>На базовом уровне изучить UML очень желательно иначе много потеряешь, тем более что это займет пару дней.
SS>А зубрить там особо и нечего, тем более что в каждом продукте свои разновидности и реализации UML.

О как! А как же универсальность?

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

Т.е. это просто формат сохранения графических данных?

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

(Имеется ввиду наверное 4 перцев)
Хм. Я считаю что это как раз не имеет отношения к UML.
это рисунки. Они полезные, я их понимаю. Но никогда не задумывался
что они в UML нотации. Ты вообще уверен что это именно она?

SS>Мне вот в последнем проекте полезными оказались Class diagram и Component diagram. Но проблема в том, что стандартный UML и различные инструменты слишком абстрактные не удовлетворяют всех потребностей. Мне вот больше была нужна модифицированная смесь этих двух диаграмм.

SS>Недостаток UML, IMHO, слишком большая абстрактность и оторванность от жизни, хотя идея крутая. Необходимы более практичные инструменты для работы с UML, чтобы от UML была более реальная польза.

Т.е. ты не отделяешь UML от рисунков? Я вообщем то согласен
что рисунки это полезно.

Но:[b] Например даже в книге Гради Буча применяется так называемая
нотация буча которая не является UML нотацией(хотя Буч ведущий идеолог
фирмы Rational которая как раз помешана на UML)

Т.е. ты под UML понимаешь вообще любое графическое описание модели?
Если так то UML безусловно полезен, но мне кажется что UML это просто
один из форматов представления, тогда он ничем не лучше чем другие.

Все кто высказывался в Topic-е объясните pls, что вы вообще понимаете
под UML. Именно Universal Modelling Language или просто [b]любые рисунки
сгенеренные чем-то или нарисованные на бумажке?

P.S. Надо же спорим 2 недели, а не догадались определить предмет спора

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

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

SS>>На базовом уровне изучить UML очень желательно иначе много потеряешь, тем более что это займет пару дней.
SS>>А зубрить там особо и нечего, тем более что в каждом продукте свои разновидности и реализации UML.

A>О как! А как же универсальность?

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

A>Т.е. это просто формат сохранения графических данных?
A>Т.е. ты не отделяешь UML от рисунков? Я вообщем то согласен
A>что рисунки это полезно.

Грубо говоря это 8 типов рисунков. UML определяет на каком типе, какие графические объекты можно рисовать и какими линиями соединять и какой смысл в это вкладывается.

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

A>(Имеется ввиду наверное 4 перцев)
A>Хм. Я считаю что это как раз не имеет отношения к UML.
A>это рисунки. Они полезные, я их понимаю. Но никогда не задумывался
A>что они в UML нотации. Ты вообще уверен что это именно она?

Конечно она ( одна из разновидностей). Основная концепция диаграмм классов это — прямоугольники с классами содединеные 2 типами связей 1)наследование 2)связи, которые возникают в runtime (ассоциации, агрегации, ..).
Остальные тонкости диаграмм классов не так существенны и в каждом инструменте различаются.

SS>>Недостаток UML, IMHO, слишком большая абстрактность и оторванность от жизни, хотя идея крутая. Необходимы более практичные инструменты для работы с UML, чтобы от UML была более реальная польза.


A>Но:[b] Например даже в книге Гради Буча применяется так называемая
A>нотация буча которая не является UML нотацией(хотя Буч ведущий идеолог
A>фирмы Rational которая как раз помешана на UML)

Неразбериху с нотациями диаграмм проясняет другая диаграмма
в msdn из vs7:
ms-help://MS.VSCC/MS.MSDNVS/dniuml/html/unificationofmethods.htm


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

A>Т.е. ты под UML понимаешь вообще любое графическое описание модели?
A>Если так то UML безусловно полезен, но мне кажется что UML это просто
A>один из форматов представления, тогда он ничем не лучше чем другие.

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



A>Все кто высказывался в Topic-е объясните pls, что вы вообще понимаете
A>под UML. Именно Universal Modelling Language или просто любые рисунки
A>сгенеренные чем-то или нарисованные на бумажке?

A>P.S. Надо же спорим 2 недели, а не догадались определить предмет спора

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

SS>Я под UML понимаю 8 (или 7) видов диаграмм, которые могут оказаться полезными для многих задач, и для различных целей не только в программировании. Но всего ими не сделаешь.
SS>В этом смысле, ER диаграммы более продвинулись (хоть и для другой области), они уже позволяют достаточно сильно автоматизировать процесс создания ПО для БД.

Диаграммы естественно полезная вещь и они очень часто нужны,
только это не UML. UML это всетаки конкретный тип диаграмм.
И в этом смысле он просто один из многих.

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

F>Что господа программисты могут сказать о целесообразности изучения сабжа?

Стоит поиграть.
Позволяет расставить все в голове на свои места при реализации большого проекта.

F>>Что господа программисты могут сказать о целесообразности изучения сабжа?

А>Стоит поиграть.
А>Позволяет расставить все в голове на свои места при реализации большого проекта.

Помнится, кто-то шутил по поводу UML:

"Энтузиазм в IT-отрасли, связанный с UML значительно поутих после того, как выяснилось, что из неправильных картинок получаются неправильные программы"

Это безотносительно моего мнения об UML

1 — Если тебе продется разбираться в
чужом коде где используется 200 — 500 классов, как проще с UML или без ???
("что этот класс делает, что другой и нафиг вообще они нужны ? в сложных системах ответы на подобные вопросы ты можешь вообще не найти")

2 — или если тебя попросят обьяснить
чего ты сам наваял, будешь на пальцах показывать ?
(сможешь обьяснять программеру на Java что у тебя на C++ написано)

UML придуман для взаимопонимания
людей пишуших на разных языках и для
удобства сопровождения программ.

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

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

A>1 — Если тебе продется разбираться в
A>чужом коде где используется 200 — 500 классов, как проще с UML или без ???
A>("что этот класс делает, что другой и нафиг вообще они нужны ? в сложных системах ответы на подобные вопросы ты можешь вообще не найти")

A>2 — или если тебя попросят обьяснить
A>чего ты сам наваял, будешь на пальцах показывать ?
A>(сможешь обьяснять программеру на Java что у тебя на C++ написано)

Ты знаешь в дисциплине Extreme Programming есть такое правило: "не делать ничего заранее, т.к. возможно через некоторое время все что ты делаешь будет никому не нужно"

Я согласен что разбираться в 200-500 классов с помощю диаграм удобнее но:
1) Ты программируешь с использованием VCL или MFC или еще чем нибудь? Там гораздо больше классов ни никаких диаграмм нет и все разбираются
2) На сколько часто ты пишешь проекты в 200-500 классов в которых будут разбираться много людей, что для этого имеет смысл писать UML
3) Когда ты пишешь проект не считаешь ли ты что потратить время на Refactoring(чтобы код был действительно лучше, что многим нужно) будет лучше чем потратить его на рисование диаграм(которые никому особо то и не нужны)

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

SS>>А зубрить там особо и нечего, тем более что в каждом продукте свои разновидности и реализации UML.

A>О как! А как же универсальность?

Если бы в этой жизни все было идеально... А на самом деле — тут недоделали, сдесь сделали по-своему. И больше всего этим грешит именно Rational

SS>>UML это просто набор диаграмм которые иногда могут оказаться очень полезными, а иногда бесполезными.

A>Т.е. это просто формат сохранения графических данных?

Да. Но с весьма весомой добавкой — ограничениями на хранимые данные.

SS>>В книге трех перцев по паттернам, очень необходимы UML диаграммы классов (просто

A>Хм. Я считаю что это как раз не имеет отношения к UML.
A>это рисунки. Они полезные, я их понимаю. Но никогда не задумывался
A>что они в UML нотации. Ты вообще уверен что это именно она?

Ее предок — нотация Румбаха.

A>Но: Например даже в книге Гради Буча применяется так называемая
A>нотация буча которая не является UML нотацией(хотя Буч ведущий идеолог
A>фирмы Rational которая как раз помешана на UML)

А теперь посмотрим на дату написания Бучем своей книги и дату начала работы над UML...
UML есть результат объединения нотаций Буча, Румбаха и Якобсона.

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

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

A>>1 — Если тебе продется разбираться в
A>>чужом коде где используется 200 — 500 классов, как проще с UML или без ???
A>>("что этот класс делает, что другой и нафиг вообще они нужны ? в сложных системах ответы на подобные вопросы ты можешь вообще не найти")

A>>2 — или если тебя попросят обьяснить
A>>чего ты сам наваял, будешь на пальцах показывать ?
A>>(сможешь обьяснять программеру на Java что у тебя на C++ написано)

A>Ты знаешь в дисциплине Extreme Programming есть такое правило: "не делать ничего заранее, т.к. возможно через некоторое время все что ты делаешь будет никому не нужно"

A>Я согласен что разбираться в 200-500 классов с помощю диаграм удобнее но:
A>1) Ты программируешь с использованием VCL или MFC или еще чем нибудь? Там гораздо больше классов ни никаких диаграмм нет и все разбираются
Все дело в том что MFC и VCL
на самом деле очень грамотно задокументированны
и если у Вас есть время задокументировать также
то творение в котором после вас возможно
люди будут разбераться и не один день
то я только приветствую такой подход.

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


A>2) На сколько часто ты пишешь проекты в 200-500 классов в которых будут разбираться много людей, что для этого имеет смысл писать UML
Я сам лично такой обьем не лепил. Но хотя бы для уважения к себе
UML дианраммы пишу ко всему что делаю.
Через пол года вернусь к коду и не надо будет вспоминать что конкретно я имел ввиду.
Открыл диограмку и все понятно.

A>3) Когда ты пишешь проект не считаешь ли ты что потратить время на Refactoring(чтобы код был действительно лучше, что многим нужно) будет лучше чем потратить его на рисование диаграм(которые никому особо то и не нужны)

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

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

И я не совсем пониманию — Вы вероятно относите себя к людям которые пишут как бог на душу положит.
Т.е. подумать как сделать лучше не в ваших правилах ?
Состовление UML диограмм это стадия проектирования, планирования.

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

A>И я не совсем пониманию — Вы вероятно относите себя к людям которые пишут как бог на душу положит.
A>Т.е. подумать как сделать лучше не в ваших правилах ?
Пропущу оскорбление мимо ушей.

A>Состовление UML диограмм это стадия проектирования, планирования.
Не во всех методиках. Ты сам все пишешь правильно с первого раза? И ты никогда не улучшаешь свой код? Так зачем ты на стадии планирования пишеш доку на код который потом много раз изменится?

Я как раз отношу себя к людям которые пишут хорошо, так что другие люди это могут хорошо прочитать, без UML диаграм. Обрати внимание что и в MFC и в VCL люди решили писать документауию не в UML формате. А люди которые в Open Source Community пишут Linux и X11 вообще не имеют четко выраженной документации(у них комментарии в сырцах), и при этот код развивается людьми которые друг друга никогда не видели и находятся в разных концах мира.

Дак вот если у тебя плохой код то его документирование и UML диаграмы тебе ничем не помогут, а если он хорош то они вообщем-то и не нужны.

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

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

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

A>>И я не совсем пониманию — Вы вероятно относите себя к людям которые пишут как бог на душу положит.
A>>Т.е. подумать как сделать лучше не в ваших правилах ?
A>Пропущу оскорбление мимо ушей.

A>>Состовление UML диограмм это стадия проектирования, планирования.
A>Не во всех методиках. Ты сам все пишешь правильно с первого раза? И ты никогда не улучшаешь свой код? Так зачем ты на стадии планирования пишеш доку на код который потом много раз изменится?

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

Как можно определить или найти общее с новым в уже написанном
если это нигде не задокументированно ? (рыться в мегобайтах кода ...)
Мне все равно не понятна Ваша точка зрения.
Безусловно все дело привычки однако на мой взгляд задействование UML
это хорошая привычка.
Еще может год назад я также как вы считал UML бесполезным набором кубиков и стрелочек.
Теперь могу вам сказать — стоит только попробовать очень часто помогает.


A>Я как раз отношу себя к людям которые пишут хорошо, так что другие люди это могут хорошо прочитать, без UML диаграм. Обрати внимание что и в MFC и в VCL люди решили писать документауию не в UML формате. А люди которые в Open Source Community пишут Linux и X11 вообще не имеют четко выраженной документации(у них комментарии в сырцах), и при этот код развивается людьми которые друг друга никогда не видели и находятся в разных концах мира.

На текущий момент допустим Вы коректно все продумали но
все равно не доканца потамучто не возможно предусмотреть все сразу.

На счет MFC и VCL если нет UML диограмм то это не значит что при разработке они не сипользовались.


A>Дак вот если у тебя плохой код то его документирование и UML диаграмы тебе ничем не помогут, а если он хорош то они вообщем-то и не нужны.

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

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

Диограммы UML бывают разной степени Абстракции
что в общем помогает понимать друг друга программистам , аналитикам , менеджерам и заказчикам.

Чего тебе терять время на поиск существующих
решений если этим может заняться менаджер не вникаясь в детали
реализации.Если UML диограмма составленна в полной мере то тебе не надо
беспокоить людей вопросом — почему сдесь нет того или другого.

Выбор таков :
1 — Посмотрел , через минуту понял.
2 — Посмотрел , прошел под отладчиком , еще раз посмотрел , сходил уточнил и понял.

Выбирать вам.

Кстати можно не тратить время
на рисование кубиков и на определение интерфейсов.
Есть такая фишка как генерация из кода модели и наобарот.

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

A>Кстати можно не тратить время
A>на рисование кубиков и на определение интерфейсов.
A>Есть такая фишка как генерация из кода модели и наобарот.

Вот наоборот пусть и нагенерит кому надо. А про то что кагда надо делать прочитай книгу "Экстремальное программирование"(Кент Бек), возможно тоже пропрешся. Так на словах не объяснить.

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

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

A>>Кстати можно не тратить время
A>>на рисование кубиков и на определение интерфейсов.
A>>Есть такая фишка как генерация из кода модели и наобарот.

A>Вот наоборот пусть и нагенерит кому надо. А про то что кагда надо делать прочитай книгу "Экстремальное программирование"(Кент Бек), возможно тоже пропрешся. Так на словах не объяснить.

Напрасно Вы так котегоричны.
Тем более это не я UML придумал.
Я лишь пытался донести до вас в чем вообще
его фишка и что токое UML.
(Может Вы просто недопонимаете ,а может наоборот настолько глубоки что с вашей колокольни только вам и виднее как провильно вести проекты)

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

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

A>>Кстати можно не тратить время
A>>на рисование кубиков и на определение интерфейсов.
A>>Есть такая фишка как генерация из кода модели и наобарот.

A>Вот наоборот пусть и нагенерит кому надо. А про то что кагда надо делать прочитай книгу "Экстремальное программирование"(Кент Бек), возможно тоже пропрешся. Так на словах не объяснить.

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