F>>Что господа программисты могут сказать о целесообразности изучения сабжа?
M.NET>>Абсолютно безполезно, только время зря тратить :)

Все зависит от того чем ты собираешься заниматься.

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

Если же надеешься хоть когда-то заняться серьезными вещами, промышленными решениями автоматизации, крупными и сверх крупными информационными системами, програмным обеспечением научно-исследоваательской деятельности. То UML (или что-то подобное, коего море) — это must have, иначе выкинуть тя нахер от туда, там программеры не нужны, нужны только иженеры (умеющие, например, программить :).

А также зависит от того, что ты считаешь (_для себя_) продуктом "разработки програмного обеспечения" (РПО :).

Если это Код и перед ним ты прекланяешься, думаешь, что хороший код решает проблему, сделал Код и гуляй, то UML тебе тоже не впился, время тратить... и скучно.

А вот я напр. не считаю (для себя) код продуктом РПО. Вот для заказчика, да код — это продукт, он его покупает (думает, что покупает решение, а на самом деле покупает код :). А для меня код — мусор, благо он уже продан, и у меня его какбы уже и нету. А вот xp'ы набранные в процессе _проектирования_ системы, части построенных моделей — вот это то, что останется у меня, то что мое. И именно это я смогу использовать в других системах. Я вообще скептически отношусь к code reuse, что касается кода проблемной области, потому что он обычно отличается в той степени, в какой отличаются и проблемные области (вопрос о конвеере и почему там так не происходит), и тащить код из одной проблемной области в др можно, как можно писать проги в машинных кодах (а кто говорит, что нельзя?), но полученное решение будет не таким, что можно сказать, лет через 10 — _Я_ это сделал. А вот наработанные части моделей таскать вполне резонно.

Мое мнение — незнание UML (или, опять же, другого подобного инструмента), значит привязывать себя к одному языку программирования (ведь именно там остануться все наработки, если (вернее, когла) придется пересесть на другой.

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

Thus, ruki proch ot UML, что в переводе с пуэрториканского означает, что знание UML — важно :)]

Блин, разница во времени не дает реагировать вовремя — у меня ночь, а вы тут при дневном свете беседу без меня ведете.

В общем...

A>>Если не нужна тебе, это не значит, что не нужна никому
M.NET>Это верно. Вот я и хочу узнать кто с этого реальную выгоду получает. По-моему только фирма Rational.

UML используется не только в Rational Rose, но и в куче других продуктов, например в Together. Там кодогенерация делается сразу при рисовании диаграммы классов. Это так, к слову о кодировании и проектировании...

M.NET> Я сижу и проектирую большую систему — у меня нет времени на написание документации и рисовние диаграмм, польза от которых сомнительна.

Ну хорошо, скажи тогда, что получается в результате твоего проектирования? Думаю, тоже подобие диаграмм. Или только словесные описания? Что получается на выходе? Проектирование на уровне в целом системы в какой нотации происходит?
UML был придуман, чтобы облегчить как описание предметной области, так и описание деталей конечной реализации, а не чтобы голову заморочить.

Ты тут в трэде написал, ...
M.NET>Потом мне менеджер дала по шее и сказала, чтобы я делом занимался, а не бумажки писал.

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


M.NET>Пример приведи. Как вы используете UML в проектировании, и как вам это помогает.

ОК, пример из научной работы (на нормальной работе не дают применить )
Проектируем информационныу систему своего института, входящего в состав университета. Охватывать должна большую часть информационных потоков, вовлечено много людей (как будущих пользователей, так и разработчиков). Начальные диаграммы, которые уже используются (работа только началась):
1. Use cases — для оценки происходящего в целом в институте (если это вообще кто-то у нас представляет )
2. Activity diagrams — для оценки действий отдельных частей системы
3. Class diagrams — понятно...
4. Сразу же deployment diagrams — разброс по оставным частям, т.к. система постепенно реализовывается в коде по мере детального проектирования отдельных частей.

Это только начало. Если учесть, что разработку и проектирование отдельных частей ведет не один человек, то без предварительых проработок никак нельзя.
Можно конечно не в UML проектировать, но он для этой цели хорошо подходит.
Это достаточный пример для использования UML?


Может кто еще расскажет про свой опыт UML?

Решил продолжить флуд.

Сначала напишу пару строк, предназначенных для того, чтоб ко мне не придирались по пустякам.
Диаграммы — это хорошо! ок.
Проектирование — супер.
UML — это не "вообще картинки", ну это все и так знают.
Диаграммы классов, объектов и Activity были сильно распространены в том или ином виде и до UML. Остальные диаграммы тоже были, но юзались не так активно.

Что мне кажется странным, так это подход "UML нужен для крупных проектов". Это при том, что для нормального проекта разглядывать Class Diagramm и уж тем паче Sequence бесполезно. Они нам та же полезны, как блок-схемы.

Кстати, разговаривал тут как-то с челом, который писал софт для Бурана. Был создан свой язык программирования (ну куда ж без него ) и все писалост на нем. Так вот, ГОСТ'ы и начальство требовали обязательного присутствия блок-схем для всего. Это было что-то. Схемки должны были быть начерчены на А1 тоже по ГОСТ'ам Сначала пытались отдавать все чертежникам. Но получалось так, чито прога работает, а в блок-схемы закрадываются ошибки при перечерчивании. Листов, говорит, была пачка до пояса. Пришлось написать прогу, которая генерила бы схемы по программе . А потом выводила на плоттер.

С UML похожая ситуация. Идейка ограниченная, неуниверсальная, создана для людей, далеких от программирования, так же точно как IDEF0. Конечно, что-то можно там изобразить. Но тока не реальные проекты. То, что в реальных проектах является узкими местами или может быть недопонято, с проблемами но может быть изображено на диаграммах. вот тока не на UML-диаграммах

Видели диаграмму MVC в Rational Suite? Хы-хы. Она там создана для того, чтоб показать от чего в MFC наследуются твои классы и что используют. Понять же архитектуру MFC нереально.

Просто удивительно, насколько убогими могут быть диаграммы в 21м веке.

В свете всего, мне кажется, что UML создан не для взаимодействия программистов.
Эти диаграммки сильно упрощены, стандартизированы, похожи на все то, что есть в IDEF. Т.е. они созданы для людей, которые привыкли к "взгляду сверху". Поясню мысль: вообще диаграммы пользуют везде, но именно такой вид в UML они имеют по причине того, что направлены на взаимодействие старого и нового подходов, либо "широкого" и "узкого". Под широким я понимаю взгдял манагеров и аналитиков, которые начали программировать еще в COBOL и кроме Си ничего по-настоящему не использовали.
20 классов прекрасно умещаются в диаграммы.

Шаблон проектирования из 3-х объектов и 5-ти классов занимает страницу. Реальная средняя прога из 500-700 классов никуда не влезает. Более того, ее вредно переносить в диаграммы, ибо они дают слишком статичный узкий взгляд, хотя и пропагандируют "высокоуровневость и универсальность".

Я прав?

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

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

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

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

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

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

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

N>>браво, Анатоликс! Просто базу! :-"Просто базу" надо еще спроектировать исходя из определенных требований и анализа предметной области.

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

A>"Плясать от базы" — это хорошо для тривиальных задач, но в серьезных системах это, простите, дилетантство. Такой подход "снизу вверх" не оправдает себя.

A>Почему дилетанство. У тебя есть хорошо спроектированная
A>база, если ты в нее данные закачаешь как предполагается
A>то задача будет практически уже сделана, т.к.
A>и ввод данных будет возможен единственным
A>образом и отчеты будет понятно как строить.

Это все хорошо, но
1. Спроектировать даже относительно простую базу прямо в SQL довольно-таки затруднительно. Это примерно как построить что-либо, не рисуя чертежей, а сразу начав класть кирпичи. У меня опыт проектирования баз довольно-таки есть, особо хвастаться не буду, но даже в самых примитивных случаях (заказы — товары — элементы заказов) я сначала нарисую таблички хотя бы на бумаге. Даже если все сущности в системе на момент начала проектирования определены, их взаимоотношения не всегда очевидны. Кратность связей, возможность дубликатов, нуллов, и тому прочая практически всегда пересматриваются несколько раз для получения непротиворечивой модели. Стоимость таких экспериментов в ERWin, RR, или просто на бумаге, заметно ниже, чем при прямом проектировании в DDL. Хотя бы потому, что зараза сервер не даст нарушить констрэйнты даже на пустых таблицах, и модификации приходится выполнять в определенном порядке...

2. Как правило, в мало-мальски сложной системе (где количество сущностей переваливает за десяток) появляются отношения, плохо выразимые (а то и вообще невыразимые) средствами SQL. Например, наследование. Различные виды контроля ссылочной целостности (prohibit, cascade, NULL). И еще много чего.

3. Выражение таких отношений средствами SQL
а) не является взаимно однозначным (по тем же причинам, по которым эффективная декомпиляция C++ программ — гиблое занятие)
б) сильно зависит от используемого SQL сервера. Синтаксис расширений типа триггеров, хранимых процедур, view и прочих радостей жизни меняется так, что адекватный автоматический перенос модели с одной платформы на другую невозможен.
Подход "сначала выберем сервер, а потом начнем проектировать" я считаю вопиющим непрофессионализмом, т.к. выбор должен диктоваться требованиями, которые и определяются в процессе проектирования.

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

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

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

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

L>Очень, ну очень полезная весчччч...

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

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

M.NET>Мне с некоторых пор не нравятся идеи ОО, на которых как раз и стоит UML. Аспектно-ориентированное проектирование куда как интереснее и полезнее.

Не исключаю. Когда-то перлись от процессного (aka структурного) подхода. К совоему стыду не знаю что есть "Аспектно-ориентированное проектирование": пару-тройку keyword'ов для поиска бы или ссылку какую.

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

M.NET>... UML, язык придётся менять. Ну и где тогда пресловутые 10-20 лет?

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

F>>Rational предлагает совсем другое, зря вы прогнали агентов, выслушали б, что (imho, за гадость) они предлагают.
M.NET>Смешной ты :) Кто ж таких агентов прогоняет.

А надо было! :)]

F>>Сделал бы другое. А на следуюющий год сделал бы совсем другое. И еще черех год... Сизифом, короче, звали б пертса :)... Или уволили за то что так много жрет :).
M.NET>Начальство это не волнует. Оно на изменениях деньги зарабатывает. Да и програаммеру от этого хорошо — вечный прогресс :) А чайники, которые всё это покупают, порой не задумываются на счёт того, что некоторые изменения стоили бы дешевле, если б у программы был хороший дизайн.

У-ууу. Да, я подозревал о существовании у вас этой точки зрения (глядя на подпись :). То, что вы написали здесь, очень хорошо можно экстраполировать на:

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

Попробуйте доказать, что не это хотели сказать (а если это... то кто из нас Frostbitten? :).

Нет, я не согласен. Прогдесс — это поднятие на уровень вверх, когда что-то можно УЖЕ не делать, а когда из года в год одно и тоже, какой програсс? Эт сафари на слонов!

M.NET>У меня есть вопрос, и я его уже в 3 раз повторяю: расскажите как вы используете UML на практике, и что вы с этого имеете? Пока что я придерживаюсь того мнения, что UML — это баловство, без которого можно спокойно обойтись.

Мы рисуем диаграмки классов, чтоб посмотреть кто с кем завязан, рисуем диаграммы состояний, понятно за чем, еще много рисуем чтоб понять подсистемы и как они связаны, и чтоб понять что разработчик _хотел_ сделать (ведь как разработчикам нам мало важно что он _сделал_ и _как_, ведь вариантов много). Никакой генерации кода. Накакого Rational.

Обойтись можно безо всего! Пушкин, чай, не в LaTeX'е воял :).

Хм... к стати, memnto more (или как это там пишется :). А если вас... эм... ... похитят инопланеняне :), очевидно, вместе с вашим богатым обытом... как будет чувствовать себя ваша компания, лишившись архитектора, кот. не оставил, нахер, никакой документации, только код. :) А вопрос этот стоит здесь очень остро — текучка кадров.

P.S. Приятно было пообщаться, позиция ваша мне понятна, обоснованная позиция, но непреемлемая, например, для меня :).

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

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

Абсолютно безполезно, только время зря тратить

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

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

Зависит от того чем занимаешься. Для больших и средних проектов вещь крайне полезная.
UML хороший инструмент для анализа и проектирования. А анализ и проектирование вешь
сама по себе необходимая. Реальную практическую пользу я чувствую от использования
Sequenсe и Сlass диаграмм, а так же Use cases. State и Activity диаграммы тоже иногда
использую но не часто. Остальные артефакты UML таже могут быть полезны. Есть неплохая
книжка Фаулера "UML в кратком изложении" (недавно вышло второе издание). Легко читается
(я прочел за два дня) Поможет тебе понять зачем нужны те или иные артефакты, и как
их правильно использовать. Недостаток — мало внимания, на мой взгляд, уделено Use ceses.

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

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

В принципе применяется чтобы программисты могли общаться
друг с другом. Но в результате польза обычно
не большая т.к. если команда пишет на C++ то им
удобней все описывать в терминах C++, а не учить
ненужный им язык.

Возможно будет иметь смысл если будет проект на грани
совмещения 5-6 технологий, хотя и здесь имеет смысл
для описания выбрать один из языков.

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

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

M.NET>Здравствуйте Frostbitten, Вы писали:

M.NET>Вся экономика Запада построена на идее "good enough" ПО. Никто не вкладывает деньги в разработку идеального программного обеспечения. Здесь надо делать то, за что платят деньги и делать это быстро. Если программа делает то, что хочет клиент, пусть даже не самым лучшим образом, то все довольны, а мнение программистов никого не касается.

Сильно task sensetive ...


M.NET>Теоретики чего-то пишут, это точно. Только на кой ты мне скажи нужна докторская степнь, если технологии меняются очень быстро, а платят не за знание общей теории, а за знание конкретики. В любом случае знать теорию хорошо, но наступает момент, когда надо знать не то, что может технология, а то что она не может, а это как раз практика. За себя скажу, что нет у меня PhD и не будет, но как практик я на голову выше преподавателей в университетах, поскольку занимаюсь реальными задачами (я, например, очень хорошо понимаю что ООП в чистом виде — это зло ). И когда дело дойдёт до поиска работы — меня возьмут быстрее, чем человека без реального опыта (кто хочет поспорить?).

Рассуждение как у кодера после колледжа ... не developer'а. Взять то может Вас и возьмут, вот только толку для компании -- не много. Для разовой задачи без развития -- нет проблем. А вот для создания серъезной системы -- вы наваяете кучу кода, и потом свалите туда где больше платят. И что делать менеджеру и другому разработчику с вашей практичностью -- километровыми обработчиками OnClick? А если систему нужно будет писать потом на др. языке программирования?


M.NET>Резонно таскать опыт, что в проектировании выражается в форме паттернов. Но не все это могут — не каждый может быть архитектором. Code reuse — это зло, как я уже говорил. В больших системах используется генерация кода, а не его повторное использование. Генерация кода с UML диаграмм — это жалкое подобие того, что порой реально нужно.


Вы видите системы только с точки зрения кода ... а не сточки зрения системы.


M.NET>Фигня всё это. Я знаком с UML, но он мне не нужен, чтобы помнить паттерны, а они порой не привязаны к
языкам. С другой стороны не так уж и часто происходит скачок на новую технологию. А с выходом .NET про языки
вообще можно забыть — надо знать технологию.


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

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

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

AS>>:) для проектирования базы не нужно знать SQL, так же как для проектирования какой то системы не ныжно знать C++ или другой язык програмирования! проектировщик это не программер!!!

A>Не согласен: для проектировани базы необходимо и иметь
A>опыт работы для того чтобы запросы по этой базе выполнялись за
A>конечное время.

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

A>На счет языков: он не обязан знать конкретный, но программировать
A>должен уметь. Кроме того большой вопрос что лучше заставить
A>одного человека выучить C++ или 10 человек выучить UML.

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

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

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

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

A>Ну можно и так сказать, а можно сказать что UML это усложненный
A>подход. Зависит от точки зрения.

A>Я просто не понимаю почему надо писать в UML, я понимаю
A>что писать надо, надо проектировать, надо документировать но UML
A>здесь причем.

A>Вообщем я думаю что UML здесь используют с той же целью
A>как медики и аптекари используют латынь
A>1) Потому что так принято, так модно
A>2) Чтобы никому непонятно было и денег больше платили.

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

По-моему основной аргумент "противников" использованяи UML — то что можно прекрасно обойтись и без него. Так кто ж с этим спорит? Естественно, все можно описать и обычным языком. То, что UML не удобен — удобство это в большой степени вопрос привычки и если человек им никогда не пользовался, то он ему будет неудобен. Первое время.

Поэтому вопрос использования UML — это вопрос личных предпочтений, а на вкус и цвет, как известно...

ИМХО, преимущества использования UML проявяться только в большом проекте (уровня предприятия), в случае если большая часть участников с этим языком знакома.

Разберетесь кто тут "А" ?

A>>Я уже писал — ИС института ...

A>А чего бы просто базу в SQL сервере не сделать безо
A>всякого UML и дальше от этого плясать.

Вопрос в лоб:

"А чего бы просто в UML не сделать безо
всякого SQL и дальше от этого плясать?"

Мы используем UML, ты SQL (знаешь, звучит как "мне нравится черный, а тебе памидоры" — потомучто разные вещи , ну и прекрасно. Хочу заметить, что вопрос состоял в том, надо ли изучать UML, а не использовать его.

Так что хотелось бы порекомендовать отвечать на вопрос "Почему НЕ надо ИЗУЧАТЬ UML" и поконкретнее... п то и мне теперь интересно стало Всегда думал, что любое знание не помешает, а вы тут такое развели!

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

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

Вся экономика Запада построена на идее "good enough" ПО. Никто не вкладывает деньги в разработку идеального программного обеспечения. Здесь надо делать то, за что платят деньги и делать это быстро. Если программа делает то, что хочет клиент, пусть даже не самым лучшим образом, то все довольны, а мнение программистов никого не касается.

F>Если же надеешься хоть когда-то заняться серьезными вещами, промышленными решениями автоматизации, крупными и сверх крупными информационными системами, програмным обеспечением научно-исследоваательской деятельности. То UML (или что-то подобное, коего море) — это must have, иначе выкинуть тя нахер от туда, там программеры не нужны, нужны только иженеры (умеющие, например, программить .

Теоретики чего-то пишут, это точно. Только на кой ты мне скажи нужна докторская степнь, если технологии меняются очень быстро, а платят не за знание общей теории, а за знание конкретики. В любом случае знать теорию хорошо, но наступает момент, когда надо знать не то, что может технология, а то что она не может, а это как раз практика. За себя скажу, что нет у меня PhD и не будет, но как практик я на голову выше преподавателей в университетах, поскольку занимаюсь реальными задачами (я, например, очень хорошо понимаю что ООП в чистом виде — это зло ). И когда дело дойдёт до поиска работы — меня возьмут быстрее, чем человека без реального опыта (кто хочет поспорить?).

F>А также зависит от того, что ты считаешь (_для себя_) продуктом "разработки програмного обеспечения" (РПО .
F>Если это Код и перед ним ты прекланяешься, думаешь, что хороший код решает проблему, сделал Код и гуляй, то UML тебе тоже не впился, время тратить... и скучно.
F>А вот я напр. не считаю (для себя) код продуктом РПО. Вот для заказчика, да код — это продукт, он его покупает (думает, что покупает решение, а на самом деле покупает код . А для меня код — мусор, благо он уже продан, и у меня его какбы уже и нету. А вот xp'ы набранные в процессе _проектирования_ системы, части построенных моделей — вот это то, что останется у меня, то что мое. И именно это я смогу использовать в других системах. Я вообще скептически отношусь к code reuse, что касается кода проблемной области, потому что он обычно отличается в той степени, в какой отличаются и проблемные области (вопрос о конвеере и почему там так не происходит), и тащить код из одной проблемной области в др можно, как можно писать проги в машинных кодах (а кто говорит, что нельзя?), но полученное решение будет не таким, что можно сказать, лет через 10 — _Я_ это сделал. А вот наработанные части моделей таскать вполне резонно.

Резонно таскать опыт, что в проектировании выражается в форме паттернов. Но не все это могут — не каждый может быть архитектором. Code reuse — это зло, как я уже говорил. В больших системах используется генерация кода, а не его повторное использование. Генерация кода с UML диаграмм — это жалкое подобие того, что порой реально нужно.

F>Мое мнение — незнание UML (или, опять же, другого подобного инструмента), значит привязывать себя к одному языку программирования (ведь именно там остануться все наработки, если (вернее, когла) придется пересесть на другой.

Фигня всё это. Я знаком с UML, но он мне не нужен, чтобы помнить паттерны, а они порой не привязаны к языкам. С другой стороны не так уж и часто происходит скачок на новую технологию. А с выходом .NET про языки вообще можно забыть — надо знать технологию.

F>Thus, ruki proch ot UML, что в переводе с пуэрториканского означает, что знание UML — важно ]

UML — это комерческий продукт фирмы Rational. Поэтому я б не стал его так рьяно защищать

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


MN>На самом деле я хотел сказать, что поскольку все создатели UML работают в Rational, то UML можно считать продуктом этой фирмы со всеми вытекающими отсюда проблемами.

А Visio от мс это как понимать — илимс тоже решиналу отстегривает за это дело ?



MN>А на выходе получается прототип системы, полурабочий, но его хоть можно показать. А за рисование диаграмм надают по шее, и правильно сделают, поскольку толку от диаграмм не много.

Клевая постанова вопроса. В первом посте мы спрашиваем "Зачем нужен юмл" и тутже занимаем жесткую позицию что юмл гауно, и гна все попытки других ораторов объяснить его предназначение говорим "Но ведь он же бесполезный".
Относительно полурабочего прототипа и "хоть чтото показать": ваще-то в нормальной конторе (не в обиду будет сказано другим — так просто, к слову) на процес дизигна и рисовалова диаграм выделячется очень приличный цигель, за который заказчик кстати тоже платит. Потому что в конечно итоге это сводит к минимуму процесс поддержки и модернизации кода. Более того, сама контора, в которой ты работаешь должна быть заинтересована в составлении грамотной и четкой документации — потом, после утверждения этой документации клиентом, можно избавить себя от таких вещей, как визг клиента "а я еще упоминал вот такую-вот фичу — сделать немедленно!". Документация она и есть документация — в ней четко расписано что должно быть сделано. То что туда не попало делатьсян е будет. А если и будет до за доп плату.

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

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

A>>ОК, пример из научной работы (на нормальной работе не дают применить )
MN>Вот именно! На практике UML нет места. Только в институтах

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

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

Потому что то что ты описываешь — это не планирование. Это порнография. Уход из команды одной-двух ключевых фигур приведет к тому что те кто их заменят будут похоронены под их кодом и очень нескоро врубятся в тему

A>>Может кто еще расскажет про свой опыт UML?
MN>Никто Потому что никто реальной пользы от этого не имеет.

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

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

Все программисты делятся на 2 категории: на тех, у кого есть способность к абстрактному мышлению, и на тех, кто считает UML излишним.

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

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

P>Решил продолжить флуд.
Ага, я тут тоже немного познакомился

P>Что мне кажется странным, так это подход "UML нужен для крупных проектов". Это при том, что для нормального проекта разглядывать Class Diagramm и уж тем паче Sequence бесполезно. Они нам та же полезны, как блок-схемы.
Не скажи. Смысл не в том, чтобы сделать "что-то", а в том, чтобы это что-то работало и сейчас, и потом. В любом случае произойдет усложнение системы до непреодолимого уровня рано или поздно. Так уж лучше поздно. А на это прямо влияет качество проектирования, которое лучше делать в более-менее стандартных определениях. Пока что "стандартней" UML ничего не придуманы, да и проектировать лучше на на бумаге, а в ACADе или Rose.

P>Кстати, разговаривал тут как-то с челом, который писал софт для Бурана. Был создан свой язык программирования (ну куда ж без него ) и все писалост на нем. ...
А потом это вместе с блок-схемами никто не использовал

P>С UML похожая ситуация. Идейка ограниченная, неуниверсальная, создана для людей, далеких от программирования, так же точно как IDEF0. Конечно, что-то можно там изобразить. Но тока не реальные проекты. То, что в реальных проектах является узкими местами или может быть недопонято, с проблемами но может быть изображено на диаграммах. вот тока не на UML-диаграммах
Не совсем. Проблема серьезных проектов в том, что они редко упираются в "чистое" программирование. Тут звучало много высказываний, но все они по-моему упираются в действительно заезженные от и до вещи. Из серии "Вам поля в БД для бухгалтерии по-русски или по-английски". Тут UML и товарищи даже вредны, наверное. А в ситуации, когда одновременно работает коллектв больше 10 человек, причем это коллектив электронщиков, конструкторов, оптиков, программистов и еще массы всякого народа, практически невозможно в более менее вменяемые сроки с вменяемым качеством хотя бы точно сформулировать конечные задачи перед системой... Что уж обо всем остальном говорить. А вы никогда не слышали беседы электронщика, оптика и программиста? Это песня А в проекте нужно ставить реальные сроки и задачи. Так что без стандартных средств не обойтись. Поэтому резюме такое — все на своем месте хорошо.

P>В свете всего, мне кажется, что UML создан не для взаимодействия программистов.
По-моему, этого и не скрывали. UML — это язык создания проектов и анализа. Программирование — это производство. Вообще пора отвыкать от мысли, что программист сродни художнику, из серии "из головы пишу" (кто-то тут выше такие вещи выдвигал). Программист — это инженер. Просто в подавляющем большинстве случаев огрехи в производстве программ обходятся гораздо дешевле (в части устранения багов программ, я не имею в виду ликвидацию после взрыва на АЭС из-за того, что где-то деление на ноль произошло), чем в материальном производстве, что почему-то служит поводом для пофигистического отношения к качеству. Типа, баги вылечим, заплатки навесим, а то что со временем из-за заплаток ничего работать не станет — так новую версию к тому времени забацаем... Интересно, почему же в серийных "Мерседесах" движки через день не вылетают? Наверное, потому что затрахаешься на каждый движок заплату выпускать... И на Даймлере это знают. А вот в Мелкософте и 99% остальных Soft-контор — нет.

P>Шаблон проектирования из 3-х объектов и 5-ти классов занимает страницу. Реальная средняя прога из 500-700 классов никуда не влезает. Более того, ее вредно переносить в диаграммы, ибо они дают слишком статичный узкий взгляд, хотя и пропагандируют "высокоуровневость и универсальность".
P>Я прав?

Прав Только если нужно все это задокументировать — влезет. "Бумажная промышленность у нас работает отлично" Но это к "Бурану". Что касается статичности — все относительно и является делом опыта. Когда я смотрю на свои проги трехлетней давности, я пытаюсь вспомнить — может у меня щизофрения тогда была? Ну не мог я такой фигни накосячить... Хотя прожекты до сих пор работают, что странно Думаю, здесь будет то же самое. Хотя наверное надо стараться, чтобы не пришлось оценвать . Плох тот солдат... Ну дальше сами знаете. Программер — все таки солдат. Женерали в других кабинетах сидят

А вот что меня по делу интересует — так где бы глянуть на более менее разжеванные проекты? У Буча конечно дело написано, но чего-то не хватает...

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

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

F>>>Судя по прениям, вызванными вопросом, весч имеет своих противников и стороников, следовательно нет единого устоявшегося мнения, поэтому все-таки придется изучать, чтобы составить свое...
A>>Только вот что-то сторонники не могут внятно объяснить чем именно она
A>>так хороша.

A>UML — Унифицированный язык моделирования. Моделирования. То есть прежде всего он придуман для унифицированного представления предметной области, ее единого описания с различных точек зрения. Во многих задачах лучше подходит, чем тот же IDEF0.

A>Мишка тут писал про отовые прототипы... Без изучения предметной области этого сделать нельзя — здесь UML и пригодится.

A>Спецификации же можно писать и на простом языке — здесь я с ним согласен, хотя и не на все 100.

A>P.S. Блин, надо что-то делать с разницей во времени — все интересное пропускаю

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

Здравствуйте Ростислав Глухов, Вы писали:

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

РГ>Но ведь помимо интерфейсов нужно описывать (или не нужно?)

по CMM вообще ничего не нужно, там просто описывается что
должно приниматься во внимание а как ты это делаешь это
твое дело. Там не про моделирование ни про программирование вооще
не упоминается. СММ это требования к бюрократическим(в хорошем
смысле) процедурам. Т.е. например ты должен учитывать требования
(в любой форме, можешь на бумажке или доске писать), должен
производить oversight проекта т.е. в любой момент ты можешь
посмотреть на доску, бумажку или веб страничку и сказать что в проекте
происходит, а не вызывать на допрос разработчиков и каленым железом
пытать их чтобы они сознались что происходит.

РГ>еще прецеденты и sequences (а то как эти интерфейсы использовать?)
РГ>хатя можно и словесно...
РГ>Что у вас для этого используется?

Мы исповедуем XP программинг так что у нас все описывается
словестно, так понятней и в такой форме это может воспринимать
заказчик.

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

M.NET>Здравствуйте Alex_st, Вы писали:

AS>>так каким образом енту самую спецификацию описывать то? ты более универсальный способ чем UML знаеш?

M.NET>А то как же Простой и доступный всем английский язык, его тут знают все, а вот UML — только единицы, да и то так себе. А если программер не знает английского, то UML ему не поможет.

ну вот это и получается объяснение на уровне: напиши то, сам незнаю что, но чтоб зелененьким горело

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

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

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

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

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

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

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

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

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

F>>Судя по прениям, вызванными вопросом, весч имеет своих противников и стороников, следовательно нет единого устоявшегося мнения, поэтому все-таки придется изучать, чтобы составить свое...
A>Только вот что-то сторонники не могут внятно объяснить чем именно она
A>так хороша.

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

Мишка тут писал про отовые прототипы... Без изучения предметной области этого сделать нельзя — здесь UML и пригодится.

Спецификации же можно писать и на простом языке — здесь я с ним согласен, хотя и не на все 100.

P.S. Блин, надо что-то делать с разницей во времени — все интересное пропускаю

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

Д>ну так не документируй. Остановись на пакетах и интерфейсах, если тебе этого достаточно. Делать заметки тебе опять же никто не мешает.
Заметки... Зачем тогда uml, если заметки. Что специфицировать? Названия методов и где лежат? Входные параметры? Допущения и эксепшэны? Plain text рулит.

Д>нужно просто более мощное понимание UML а то у меня такое впечатление, что кроме диаграмм классов никто ничего не знает. Да и о них тоже очень странное представление.
А что поможет? Activity? State chart? Нарисовать алгоритм обхода дерева? if/else? Оно ведь ненужно никому в таком виде.. ну согласись.

Д>приводить MSDN в качестве примера вообще смехотворно. Можно еще сослаться на WinAPI и сказать, что ООП — это ненужное излишество, а type cast — это рулезнейший приём и его надо пихать везде где можно
Опять за гармонь взялся — я не против диаграмм и не считаю их излишеством, совсем наоборот. Но мне сильно не нраивтся их нынешний формат в UML.

Д>Рекомендую попробовать применить функцию StackWalk64, используя только MSDN, в качестве примера и упражнения
Сянкс, это я и с диаграммами сутки потрачу.

Д>Как раз там были бы очень к месту диаграммы состояний и последовательностей, и это уже упущение M$, что их там нет.
Наверняка, здесь они очень полезны. Хитрые манипуляции с битами, вызовами и рекурсией — самое оно для UML.

Д>представлять UML как средство зашибания денег, которое придумали в Rational — это просто передергивание фактов. На самом деле корни UML растут из Ericsson, где он разрабатывался как средство для внутреннего употребления. Rational появился много позднее.
Согласен, что передергивание. Ну что ты, в самом деле...

Речь то не о том, что "ох, эти вот диаграммы... чтоб их, с классами разобрался а к остальному шесть лет приступить не могу... мляяя... заставляют рисовать.. не понимаю ничё, кому оно надо... щас напишу все сам без них и быстрее выйдет.. уууу.... поназагнули поперемудрствований.."

Совсем наоборот — недозагнули. Понятно почему недозагнули, но все же.

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

B>Наверно, Вы таки стоит говорить ... Я занимаюсь КИС для РАО ЕС и Региональных энергокомпаний

Помню настраивал я 1С для Карелэнерго

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

AS> для проектирования базы не нужно знать SQL, так же как для проектирования какой то системы не ныжно знать C++ или другой язык програмирования! проектировщик это не программер!!!

Не согласен: для проектировани базы необходимо и иметь
опыт работы для того чтобы запросы по этой базе выполнялись за
конечное время.

На счет языков: он не обязан знать конкретный, но программировать
должен уметь. Кроме того большой вопрос что лучше заставить
одного человека выучить C++ или 10 человек выучить UML.

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

_>Не скажи. Смысл не в том, чтобы сделать "что-то", а в том, чтобы это что-то работало и сейчас, и потом. В любом случае произойдет усложнение системы до непреодолимого уровня рано или поздно. Так уж лучше поздно. А на это прямо влияет качество проектирования, которое лучше делать в более-менее стандартных определениях. Пока что "стандартней" UML ничего не придуманы, да и проектировать лучше на на бумаге, а в ACADе или Rose.
Черт, не получается у меня пока компактно излагать свои мысли. Все верно, мы больше не можем себе позволить писать программы-однодневки. Хотя цикл производства программного обеспечения и сокращается, сроки использования отдельных программ растут.

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

Я не говорил, что проектирование или документирование в виде диаграмм — это неправильно или непозволительно дорого. Я говорил, что UML — зло. Также как структурное программирование — хорошо, а COBOL в 21 веке — зло.

P>>Кстати, разговаривал тут как-то с челом, который писал софт для Бурана. Был создан свой язык программирования (ну куда ж без него ) и все писалост на нем. ...
_>А потом это вместе с блок-схемами никто не использовал
Именно.

P>>С UML похожая ситуация. Идейка ограниченная, неуниверсальная, создана для людей, далеких от программирования, так же точно как IDEF0. Конечно, что-то можно там изобразить. Но тока не реальные проекты. То, что в реальных проектах является узкими местами или может быть недопонято, с проблемами но может быть изображено на диаграммах. вот тока не на UML-диаграммах
_>Не совсем. Проблема серьезных проектов в том, что они редко упираются в "чистое" программирование.
Ну то, чтобы проблема. Особенность.

_>Тут звучало много высказываний, но все они по-моему упираются в действительно заезженные от и до вещи. Из серии "Вам поля в БД для бухгалтерии по-русски или по-английски". Тут UML и товарищи даже вредны, наверное.
Вполне хватит use cases. Но я не о таких проектах.

_>А в ситуации, когда одновременно работает коллектв больше 10 человек, причем это коллектив электронщиков, конструкторов, оптиков, программистов и еще массы всякого народа, практически невозможно в более менее вменяемые сроки с вменяемым качеством хотя бы точно сформулировать конечные задачи перед системой... Что уж обо всем остальном говорить. А вы никогда не слышали беседы электронщика, оптика и программиста? Это песня
Охотно верю . Но UML тут не при чем. Он почти так же плох для международного языка, как немецкий (из-за глаголов в конце и длины слов) или русский (из-за слишком большого числа перекрывающихся синонимов и омонимов, а также пренебрежения к порядку слов).

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

P>>В свете всего, мне кажется, что UML создан не для взаимодействия программистов.
_>По-моему, этого и не скрывали. UML — это язык создания проектов и анализа. Программирование — это производство. Вообще пора отвыкать от мысли, что программист сродни художнику, из серии "из головы пишу" (кто-то тут выше такие вещи выдвигал).
С этим я не спорю.

_>Программист — это инженер. Просто в подавляющем большинстве случаев огрехи в производстве программ обходятся гораздо дешевле (в части устранения багов программ, я не имею в виду ликвидацию после взрыва на АЭС из-за того, что где-то деление на ноль произошло), чем в материальном производстве, что почему-то служит поводом для пофигистического отношения к качеству.
Ну я думаю, что из-за засилия ПО в технике, теперь риски больше на ПО. Спутники теряются...

_>Типа, баги вылечим, заплатки навесим, а то что со временем из-за заплаток ничего работать не станет — так новую версию к тому времени забацаем...
Большей частью не поэтому, но это отдельный разговор.

_>Интересно, почему же в серийных "Мерседесах" движки через день не вылетают?
Потому что они вложили очень много денег в испытания. Потому что есть хорошая теоретическая база. Потому что механика и гидравлика в целом проще, чем ПО. Глючат не все проги. Чаще глючат те, что "писаны с нуля". Софт, который активно юзается лет десять и больше, вообще не глючит.

_>Наверное, потому что затрахаешься на каждый движок заплату выпускать... И на Даймлере это знают. А вот в Мелкософте и 99% остальных Soft-контор — нет.
Выпускают и заплатки на движки. На дверные замки, на электронику. Это действительно дороже, чем софтверная заплатка. Но плохая репутация обходится дороже. Кроме того, в промышленности работает очень большое число совершенно разных специалистов. Применяются в основном наработанные веками удачные решения. Если же приходится создавать индустрию с нуля, так посмотри на освоение космоса и ракеты — глючат, очень глючат и не думаю, что это обходится всем задешево.

P>>Шаблон проектирования из 3-х объектов и 5-ти классов занимает страницу. Реальная средняя прога из 500-700 классов никуда не влезает. Более того, ее вредно переносить в диаграммы, ибо они дают слишком статичный узкий взгляд, хотя и пропагандируют "высокоуровневость и универсальность".
P>>Я прав?
_>Прав Только если нужно все это задокументировать — влезет. "Бумажная промышленность у нас работает отлично"
Я не против все это задокументировать. Тока не в виде блок схем. И не диаграммы классов (хотя она и сама строится). И не диаграмм последовательностей. Что-то я не вижу в msdn диаграмм последовательностей на каждом шагу.

_>А вот что меня по делу интересует — так где бы глянуть на более менее разжеванные проекты? У Буча конечно дело написано, но чего-то не хватает...
Разве у Буча серьезно написано? Это ведь for beginners. Очень простеньки задачи решены с толком и расстановкой. Ну да, конечно многого не хватает.

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

MN>Здравствуйте Ростислав Глухов, Вы писали:

M.NET>>>Ну ка расскажи мне прямую и косвенную выгоду от использования UML. Я здесь давным давно задавал вопрос: "А на кой всё это нужно?". И оказалось, что никто толком не знает

РГ>>да как-то не тянет :-Ну ка лучше прочитай введение к "UML. Руководство пользователя", наверняка там написано...

MN>Вот и я говорю — никто не знает на кой оно нужно. А читать рекламу от Буча я не хочу.

Тебе ж сказали — uml нужен чтоб оставить свой след в истории. Шоб через 10 лет когда кто-то полезет в твой код или захочет расширить твой прожект не возникало вопросов, почему под вот это дело класс заведен и почему у него метод вот такой вот

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

А>Здравствуйте, Mishka.NET, Вы писали:

MN>>Ну ка расскажи мне прямую и косвенную выгоду от использования UML. Я здесь давным давно задавал вопрос: "А на кой всё это нужно?". И оказалось, что никто толком не знает

А>Извини, что вмешиваюсь.

А>Реальный пример:
А>1). Диаграмма классов для иллюстрации заказчику идеи алгоритма.

Ни разу не видел такого заказчика.
Обычно при демонстрации заказчику диаграмы сложнее, чем это можно нарисовать в Word в очень популярном виде (очень часто и это слишком сложно для их понимания), они просто впадают в длительный ступор. BPWin и RWin это только для себя. А если им диаграмму классов на UML показать — они вообще с тобой больше никогда разговаривать не станут.

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

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

Пробовал приобщиться, но бросил за ненадобностью. Гораздо эффективней применять теорию конечных автоматов.

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

F>>Что господа программисты могут сказать о целесообразности изучения сабжа?
M.NET>Абсолютно безполезно, только время зря тратить

Если не нужна тебе, это не значит, что не нужна никому

При моделировании больших систем весьма полезна. Про это Tom написал, потому повторяться не буду.

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

F>>Что господа программисты могут сказать о целесообразности изучения сабжа?
Tom> Есть неплохая книжка Фаулера "UML в кратком изложении" (недавно вышло второе издание). Легко читается (я прочел за два дня) Поможет тебе понять зачем нужны те или иные артефакты, и как их правильно использовать. Недостаток — мало внимания, на мой взгляд, уделено Use ceses.

Рекомендую еще "UML руководство пользователя" от неизменной троицы создателей языка — практически первоисточник. Местами много воды, но разжевано хорошо. Хотелось бы побольше разнообразных примеров — там они не все показательны.

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

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

резюме+ свои соображения:

1- зачем тратить время на изучение (ведь вокруг столько другого интересного)
2- замедляет процесс разработки (ну зачем нам лишнее звено — проектирование)
3- привносит дополнительный язык (если я знаю C++, сосед: С++, то зачем нам вместе UML?)

1+ Чертовски полезен для фирмы. (попробует она сертифицироваться на CMM (1 уровень=???)http://195.209.62.198/forum/message.asp?mid=80161&amp;only
без UML)
2+ Стабилизирует процесс разработки (это при использовании RUP, MSF,...)
2+ Чертовски полезен для карьеры. (кто тут занимался планированием?)

Хотя как самоцель учить не стоит. Ж))

Здравствуйте Ростислав Глухов, Вы писали:

РГ>1+ Чертовски полезен для фирмы. (попробует она сертифицироваться на CMM (1 уровень=???)http://195.209.62.198/forum/message.asp?mid=80161&amp;only
РГ> без UML)

Нет CMM вообще не накладывает на средства никакие ограничения.
Как хочешь описывай интерфейсы лишь бы все понимали.
Мы замахнулись на второй уровень к концу года, нет у нас
никакого UML.

РГ>2+ Стабилизирует процесс разработки (это при использовании RUP, MSF,...)

Перефразировать: нужен для работы с RUP, MSF. Сам по себе
он ничего не стабилизирует.

РГ>2+ Чертовски полезен для карьеры. (кто тут занимался планированием?)

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

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

РГ>>1+ Чертовски полезен для фирмы. (попробует она сертифицироваться на CMM (1 уровень=???)http://195.209.62.198/forum/message.asp?mid=80161&amp;only
РГ>> без UML)

A>Нет CMM вообще не накладывает на средства никакие ограничения.
A>Как хочешь описывай интерфейсы лишь бы все понимали.
A>Мы замахнулись на второй уровень к концу года, нет у нас
A>никакого UML.

Но ведь помимо интерфейсов нужно описывать (или не нужно?)
еще прецеденты и sequences (а то как эти интерфейсы использовать?)
хатя можно и словесно...
Что у вас для этого используется?

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

A>Здравствуйте Ростислав Глухов, Вы писали:

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

РГ>>Но ведь помимо интерфейсов нужно описывать (или не нужно?)

A>по CMM вообще ничего не нужно, там просто описывается что
A>должно приниматься во внимание а как ты это делаешь это
A>твое дело. Там не про моделирование ни про программирование вооще
A>не упоминается. СММ это требования к бюрократическим(в хорошем
A>смысле) процедурам. Т.е. например ты должен учитывать требования
A>(в любой форме, можешь на бумажке или доске писать), должен

спасибо за ответ.
вот здесь должен быть Software Project Planning?
как он у вас ведется?


A>производить oversight проекта т.е. в любой момент ты можешь
A>посмотреть на доску, бумажку или веб страничку и сказать что в проекте
A>происходит, а не вызывать на допрос разработчиков и каленым железом
A>пытать их чтобы они сознались что происходит.

РГ>>еще прецеденты и sequences (а то как эти интерфейсы использовать?)
РГ>>хатя можно и словесно...
РГ>>Что у вас для этого используется?

A>Мы исповедуем XP программинг так что у нас все описывается
A>словестно, так понятней и в такой форме это может воспринимать
A>заказчик.

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

A>Если не нужна тебе, это не значит, что не нужна никому
Это верно. Вот я и хочу узнать кто с этого реальную выгоду получает. По-моему только фирма Rational. Программситу UML только мешать будет. Бизнес аналитики, правда, от Use cases могут выиграть, но только они. Я сижу и проектирую большую систему — у меня нет времени на написание документации и рисовние диаграмм, польза от которых сомнительна. Если что-то надо реализовать, то я подробно объясню человеку, что и как нужно делать. Senior software developers они всё и без диаграмм прекрасно понимают, а всем остальным до этого дела нет. Менеджеры своим делом должны заниматься, а не диаграммы рассматривать.

A>При моделировании больших систем весьма полезна. Про это Tom написал, потому повторяться не буду.
Пример приведи. Как вы используете UML в проектировании, и как вам это помогает.

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

M.NET>Здравствуйте Aquary, Вы писали:

A>>Если не нужна тебе, это не значит, что не нужна никому
M.NET>Это верно. Вот я и хочу узнать кто с этого реальную выгоду получает. По-моему только фирма Rational. Программситу UML только мешать будет. Бизнес аналитики, правда, от Use cases могут

ага, а от зубной пасты выгода только у Blendamed

Здравствуйте Ростислав Глухов, Вы писали:

РГ>спасибо за ответ.
РГ>вот здесь должен быть Software Project Planning?
РГ>как он у вас ведется?

просто TODO List и время на выполнение каждой фичи,
потом в нем помечается что сделано сразу получается
tracking & oversight

Здравствуйте Ростислав Глухов, Вы писали:

РГ>ага, а от зубной пасты выгода только у Blendamed

Не пользуюсь такой зубной пастой, по той же причине, что и не пользуюсь UML
P.S. Аналогия не удачна.

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

M.NET>Здравствуйте Ростислав Глухов, Вы писали:

РГ>>ага, а от зубной пасты выгода только у Blendamed

M.NET>Не пользуюсь такой зубной пастой, по той же причине, что и не пользуюсь UML
<!!!>конечно, одного и тогоже можно достичь разными средствами </!!!>

M.NET>P.S. Аналогия не удачна.
а IMHO удачна
Есть прямая выгода а есть косвенная. от этого она выгодой быть не перестает.
P.S. погодь нолики ставить, сказал же <!!!>

Здравствуйте Ростислав Глухов, Вы писали:

M.NET>>Не пользуюсь такой зубной пастой, по той же причине, что и не пользуюсь UML
РГ><!!!>конечно, одного и тогоже можно достичь разными средствами </!!!>

В случае UML — это не средство — это обуза, без которой хорошо живётся. Даже остаётся время на RSDN

M.NET>>P.S. Аналогия не удачна.
РГ>а IMHO удачна
РГ>Есть прямая выгода а есть косвенная. от этого она выгодой быть не перестает.

Ну ка расскажи мне прямую и косвенную выгоду от использования UML. Я здесь давным давно задавал вопрос: "А на кой всё это нужно?". И оказалось, что никто толком не знает

РГ>P.S. погодь нолики ставить, сказал же <!!!>

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

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

M.NET>>>P.S. Аналогия не удачна.
РГ>>а IMHO удачна
РГ>>Есть прямая выгода а есть косвенная. от этого она выгодой быть не перестает.

M.NET>Ну ка расскажи мне прямую и косвенную выгоду от использования UML. Я здесь давным давно задавал вопрос: "А на кой всё это нужно?". И оказалось, что никто толком не знает

да как-то не тянет :-Ну ка лучше прочитай введение к "UML. Руководство пользователя", наверняка там написано...

Здравствуйте Ростислав Глухов, Вы писали:

M.NET>>Ну ка расскажи мне прямую и косвенную выгоду от использования UML. Я здесь давным давно задавал вопрос: "А на кой всё это нужно?". И оказалось, что никто толком не знает

РГ>да как-то не тянет :-Ну ка лучше прочитай введение к "UML. Руководство пользователя", наверняка там написано...

Вот и я говорю — никто не знает на кой оно нужно. А читать рекламу от Буча я не хочу.

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

M.NET>Здравствуйте Frostbitten, Вы писали:

Генерация кода с UML диаграмм — это жалкое подобие того, что порой реально нужно.
Я б сказал, что именно _эти_ генераторы — жалкое подобие тех генераторов, которые нужны. UML тут не причем!

M.NET>UML — это комерческий продукт фирмы Rational. Поэтому я б не стал его так рьяно защищать
UML это не продукт и не рекламная фишка. Это реальная помощь при проектировании больших и средних систем. И его реально используют. Порой с хорошим генератором и не большой задачей разрабока системы превращаеться в рисование!
Это не пустые слова вот пример: в июле в Перми проходил ЧЕ2002 по боксу. Для этого была разработана система информационной поддержки проведения чемпионата. Она разрабатывалась одним разработчиком за месяц (точнее за три недели), включая анализ, рисование диаграмм, дописывание кода и тестирования. Для интереса могу посчитать скока процентов кода от готовой системы было сгенерированно автоматически...

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

T>Генерация кода с UML диаграмм — это жалкое подобие того, что порой реально нужно.
T>Я б сказал, что именно _эти_ генераторы — жалкое подобие тех генераторов, которые нужны. UML тут не причем!

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

M.NET>>UML — это комерческий продукт фирмы Rational. Поэтому я б не стал его так рьяно защищать
T>UML это не продукт и не рекламная фишка. Это реальная помощь при проектировании больших и средних систем. И его реально используют. Порой с хорошим генератором и не большой задачей разрабока системы превращаеться в рисование!
UML — это продукт и его рекламируют. У нас тут гаврики из Rational на прошлой неделе были много чего хорошего сказали про UML и про их взгляд на процесс разработки. С процессом я согласен частями, с использованием UML — нет.

T>Это не пустые слова вот пример: в июле в Перми проходил ЧЕ2002 по боксу. Для этого была разработана система информационной поддержки проведения чемпионата. Она разрабатывалась одним разработчиком за месяц (точнее за три недели), включая анализ, рисование диаграмм, дописывание кода и тестирования. Для интереса могу посчитать скока процентов кода от готовой системы было сгенерированно автоматически...

Могу предположить, что если бы он не страдал хернёй и не рисовал диаграммы, то сделал бы всё за неделю История из реальной жизни: когда я только пришёл в фирму, то на первых порах пытался заставить аналитиков быть конкретнее в их спецификациях. Потом мне менеджер дала по шее и сказала, чтобы я делом занимался, а не бумажки писал. Через пару месяцев, я был удивлён, что всё работает, и никто ничего не анализировал до мелочей. Так что документация — это тоже зло.

А вот тебе другой пример: проектируется система, большая не по количеству классов, а по их разнородности, я честно пытался использовать UML, но забросил всё это когда количество классов перевалило за сотню. UML в этом случае использовать неудобно! Куда как лучше использовать С# Там хоть сразу видно что с чем стыкуется и как, плюс имеешь полуготовый код, который, кстати, ещё и что-то делает, и это что-то можно показать заинтересованным лицам. Да, и в моём случае все Use Cases нарисовать также не удастся — всё ж таки проект большой и он будет эволюционировать.

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

M.NET>>За себя скажу, что нет у меня PhD и не будет, но как практик я на голову выше преподавателей в университетах,

Старый спор, ему уж лет 1200 :)... Но, про голову, лучше не говорить, это обычно воспринимается как-то превратно :)))

M.NET>>Только на кой ты мне скажи нужна докторская степнь, если технологии меняются очень быстро, а платят не за знание общей теории, а за знание конкретики.

Никакая технологи еще не создала что-то сложнее того, что было до нее :). А UML, как раз, основывается на понятиях реального мира: интерфейс, взаимодействие, объект, видимость. Есть технологии, кот. не покрывают UML, наоборот может только получиться при моделировании VR :)

T>>Генерация кода с UML диаграмм — это жалкое подобие того, что порой реально нужно.
T>>Я б сказал, что именно _эти_ генераторы — жалкое подобие тех генераторов, которые нужны. UML тут не причем!

%100

M.NET>>UML — это комерческий продукт фирмы Rational. Поэтому я б не стал его так рьяно защищать :)

В этом месте обычно хочется сказать что-то неумное :), но я промолчу. И скажу другое: XML — это продукт микрософт и рекламирует она его как продукт и продает его как продукт :))) Таже хрень. Разберитесь.

Rational предлагает совсем другое, зря вы прогнали агентов, выслушали б, что (imho, за гадость) они предлагают. UML тут не причем.

T>>... в июле в Перми проходил ЧЕ2002 по боксу. Для этого была разработана система ...
M.NET>Могу предположить, что если бы он не страдал хернёй и не рисовал диаграммы, то сделал бы всё за неделю :)

Сделал бы другое. А на следуюющий год сделал бы совсем другое. И еще черех год... Сизифом, короче, звали б пертса :)... Или уволили за то что так много жрет :).

M.NET>>Так что документация — это тоже зло.

... Думал тот менеджер. А я, например, противоположного мнения.

M.NET>А вот тебе другой пример: ... проект большой и он будет эволюционировать ...

А вот это зло. Если большой проект эволюционирует, он не может быть завершен ("а только отложен" (c) Микельанжело /художник/ :). Итеративный проесс предусматривает коррекцию и дополнение проекта, но только не эволюцию (как процесс недискретный и, зачастую, неуправляемый).

И вообще хотелось бы утвердить следующее:

1. UML — это язык. Язык не программирования, а естественный, язык на котором можно объяснить коллеге, а что самое главное, себе что ты думаешь, записать мысль, которую можно будет прочесть через 10-20 лет (с кодом этого не получится). Язык синтезированный из других, разработанный теоретиками проектирования. Этот язык НЕ ИМЕЕТ ничего общего ни с RUP в частности, ни с Rational вообще, за исключение того, что Grady Booch, там идейный вдохновитель (и совладелец?). (точка)

2. Что-то мне не нравиться как остервенело Mishka.NET нападает на UML, этому должны быть какие-то личные причины. :)]

3. Если же тыкать пальтсем на запад, то следует надомнить, что там существует мнение, что программист — это такой электрик, которому платить приходиться во много раз больше. У нас-то совсем подругому. Так это или нет, узнать чрезвычайно сложно (спрашивать у программистов беспользно — кто скажет, что я ... :) Так что кодером до пенсии быть я лично, не собираюсь, потому UML мне пне помешает... для общего развития :), но у кажного свои цели... и для вас UML, действительно может быть бесполезен. Но не будем сориться (хотя мне кажется, что вы имеете смутное представление об UML или я ошибаюсь? :)

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

F>Никакая технологи еще не создала что-то сложнее того, что было до нее . А UML, как раз, основывается на понятиях реального мира: интерфейс, взаимодействие, объект, видимость.
Всё придумано в 60-х годах. Ничего нового практически нет. Но вот реализация всех идей постоянно меняется, поэтому платят за то, что ты знаешь чем оно всё отличается от теории, то есть особенности реализации.
UML пытается основываться на реальном мире. Или лучше сказать он сжимает мир в свои рамки. Мне с некоторых пор не нравятся идеи ОО, на которых как раз и стоит UML. Аспектно-ориентированное проектирование куда как интереснее и полезнее, но для того, чтобы вписать такой взгляд в UML, язык придётся менять. Ну и где тогда пресловутые 10-20 лет?

F>Rational предлагает совсем другое, зря вы прогнали агентов, выслушали б, что (imho, за гадость) они предлагают. UML тут не причем.
Смешной ты Кто ж таких агентов прогоняет. Мы у них вроде Clear Quest и Clear Case собираемся покупать.

F>Сделал бы другое. А на следуюющий год сделал бы совсем другое. И еще черех год... Сизифом, короче, звали б пертса ... Или уволили за то что так много жрет .
Начальство это не волнует. Оно на изменениях деньги зарабатывает. Да и програаммеру от этого хорошо — вечный прогресс А чайники, которые всё это покупают, порой не задумываются на счёт того, что некоторые изменения стоили бы дешевле, если б у программы был хороший дизайн.

M.NET>>>Так что документация — это тоже зло.
F>... Думал тот менеджер. А я, например, противоположного мнения.
А что, правда есть время доки писать? Я б вот вместо этого книжку бы почитал, и то для самообразования полезнее

M.NET>>А вот тебе другой пример: ... проект большой и он будет эволюционировать ...
F>А вот это зло. Если большой проект эволюционирует, он не может быть завершен ("а только отложен" (c) Микельанжело /художник/ . Итеративный проесс предусматривает коррекцию и дополнение проекта, но только не эволюцию (как процесс недискретный и, зачастую, неуправляемый).
Теория, батенька, вещь хорошая. Но разработка ПО — это именно эволюция. Любое ПО является незавершённым. Оно просто в некоторые моменты может удовлетворять требованиям заказчика. А требования как известно эволюционируют. Не надо путать управление проектами в IT с другими проектами, здесь мало общего. Именно поэтому проекты в IT рушатся намного чаще. Специфика, понимаешь...

F>И вообще хотелось бы утвердить следующее:

F>2. Что-то мне не нравиться как остервенело Mishka.NET нападает на UML, этому должны быть какие-то личные причины. ]
У меня есть вопрос, и я его уже в 3 раз повторяю: расскажите как вы используете UML на практике, и что вы с этого имеете? Пока что я придерживаюсь того мнения, что UML — это баловство, без которого можно спокойно обойтись.

F>3. Если же тыкать пальтсем на запад, то следует надомнить, что там существует мнение, что программист — это такой электрик, которому платить приходиться во много раз больше.
Ха. Нет здесь такого мнения. Да и не надо всех программистов под одну гребёнку причёсывть. Вот тут в соседней Англии была вакансия — требуется архитектор, умеющий торговать на уровне CEO — ни хрена себе электрика ищут

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

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

M.NET>>Вся экономика Запада построена на идее "good enough" ПО. Никто не вкладывает деньги в разработку идеального программного обеспечения. Здесь надо делать то, за что платят деньги и делать это быстро. Если программа делает то, что хочет клиент, пусть даже не самым лучшим образом, то все довольны, а мнение программистов никого не касается.
B>Сильно task sensetive ...
Факты на бочку! Если программа делает то, что от неё требуется, то проект закончен, если нет, то нет. Третьего не дано. Никто не будет оптимизировать программу, если за это не платят (это факт!).

M.NET>>Теоретики чего-то пишут, это точно. Только на кой ты мне скажи нужна докторская степнь, если технологии меняются очень быстро, а платят не за знание общей теории, а за знание конкретики. В любом случае знать теорию хорошо, но наступает момент, когда надо знать не то, что может технология, а то что она не может, а это как раз практика. За себя скажу, что нет у меня PhD и не будет, но как практик я на голову выше преподавателей в университетах, поскольку занимаюсь реальными задачами (я, например, очень хорошо понимаю что ООП в чистом виде — это зло ). И когда дело дойдёт до поиска работы — меня возьмут быстрее, чем человека без реального опыта (кто хочет поспорить?).
B>Рассуждение как у кодера после колледжа ... не developer'а. Взять то может Вас и возьмут, вот только толку для компании -- не много. Для разовой задачи без развития -- нет проблем. А вот для создания серъезной системы -- вы наваяете кучу кода, и потом свалите туда где больше платят. И что делать менеджеру и другому разработчику с вашей практичностью -- километровыми обработчиками OnClick? А если систему нужно будет писать потом на др. языке программирования?
Я не developer и не coder, а software arhitect И проектирую я серьёзную систему, конкретнее, программное обеспечение для госпиталей в UK и Ireland. Пока что оно держится на 1 месте по популярности. Так что у меня есть основания что-то утверждать. Если я надумаю сменить работу, то всё будет продолжать работать, поскольку всё в умах людей, а их здесь много.

M.NET>>Резонно таскать опыт, что в проектировании выражается в форме паттернов. Но не все это могут — не каждый может быть архитектором. Code reuse — это зло, как я уже говорил. В больших системах используется генерация кода, а не его повторное использование. Генерация кода с UML диаграмм — это жалкое подобие того, что порой реально нужно.
B>Вы видите системы только с точки зрения кода ... а не с точки зрения системы.
А при чём здесь система? Я говорю, что UML может помочь в описании паттернов, но сами паттерны и без UML живут хорошо. Паттерны знать должен каждый архитектор, а вот для программеров — это желательно, но не обязательно.

B>Паттерны чего -- процесса заключения договора, например? А как вы будете применять паттерны, без знания физики процесса? Или Вам быстро, на пальцах пояснят все требования к системе?
Архитектурные паттерны — то есть как всё организовать, здесь достаточно поверхносто знать требования к системе. Затем прорабатывая детали конкретного этапа проекта, пытаемся использовать паттерны проектирования, чтобы быть готовым к возможным последующим изменениям. То что потом делают программисты, это уже их забота.

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

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

M.NET>>>Вся экономика Запада построена на идее "good enough" ПО. Никто не вкладывает деньги в разработку идеального программного обеспечения. Здесь надо делать то, за что платят деньги и делать это быстро. Если программа делает то, что хочет клиент, пусть даже не самым лучшим образом, то все довольны, а мнение программистов никого не касается.
B>>Сильно task sensetive ...
M.NET>Факты на бочку! Если программа делает то, что от неё требуется, то проект закончен, если нет, то нет. Третьего не дано. Никто не будет оптимизировать программу, если за это не платят (это факт!).

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

M.NET>Я не developer и не coder, а software arhitect :))

а рассуждаете как кодер :-) (а вообще мне вспоминается дедушка Фрейд ...). Насколько я понимаю, до этого проекта, у Вас не было крупных проектов по созданию КИС, а конфигурирование 1С не считается ...

B>>Вы видите системы только с точки зрения кода ... а не с точки зрения системы.
M.NET>А при чём здесь система? Я говорю, что UML может помочь в описании паттернов, но сами паттерны и без UML живут хорошо. Паттерны знать должен каждый архитектор, а вот для программеров — это желательно, но не обязательно.

Повторюсь, но это взгляд сквозь шоры ...


B>>Паттерны чего -- процесса заключения договора, например? А как вы будете применять паттерны, без знания физики процесса? Или Вам быстро, на пальцах пояснят все требования к системе?
M.NET>Архитектурные паттерны — то есть как всё организовать, здесь достаточно поверхносто знать требования к системе.

И при этом эффективно спроектировать?

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

M.NET>>Факты на бочку! Если программа делает то, что от неё требуется, то проект закончен, если нет, то нет. Третьего не дано. Никто не будет оптимизировать программу, если за это не платят (это факт!).
А>еще раз повторю, что это зависит от задачи. Если это разовый продукт, не претендущий на развитие и фирма не является даже нишевым игроком, то всем наплевать ...
Ничего от задачи не зависит. Главное результат.

M.NET>>Я не developer и не coder, а software arhitect
А>а рассуждаете как кодер (а вообще мне вспоминается дедушка Фрейд ...). Насколько я понимаю, до этого проекта, у Вас не было крупных проектов по созданию КИС, а конфигурирование 1С не считается ...
Ну расскжи мне как должен рассуждать архитектор, да и ещё скажи чем ты занимаешься, чтоб хоть понимать обоснованность твоих высказываний.

B>>>Паттерны чего -- процесса заключения договора, например? А как вы будете применять паттерны, без знания физики процесса? Или Вам быстро, на пальцах пояснят все требования к системе?
M.NET>>Архитектурные паттерны — то есть как всё организовать, здесь достаточно поверхносто знать требования к системе.
А>И при этом эффективно спроектировать?
Ну дык а как же Я ж вообще личность не ординарная

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

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

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

МА>Пробовал приобщиться, но бросил за ненадобностью. Гораздо эффективней применять теорию конечных автоматов.

Не могли бы Вы привести небольшой пример использования теории конечных автоматов применительно к проектированию программных систем

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

A>>>Если не нужна тебе, это не значит, что не нужна никому
M.NET>>Это верно. Вот я и хочу узнать кто с этого реальную выгоду получает. По-моему только фирма Rational.
A>UML используется не только в Rational Rose, но и в куче других продуктов, например в Together. Там кодогенерация делается сразу при рисовании диаграммы классов. Это так, к слову о кодировании и проектировании...
На самом деле я хотел сказать, что поскольку все создатели UML работают в Rational, то UML можно считать продуктом этой фирмы со всеми вытекающими отсюда проблемами.

M.NET>> Я сижу и проектирую большую систему — у меня нет времени на написание документации и рисовние диаграмм, польза от которых сомнительна.
A>Ну хорошо, скажи тогда, что получается в результате твоего проектирования? Думаю, тоже подобие диаграмм. Или только словесные описания? Что получается на выходе? Проектирование на уровне в целом системы в какой нотации происходит?
А на выходе получается прототип системы, полурабочий, но его хоть можно показать. А за рисование диаграмм надают по шее, и правильно сделают, поскольку толку от диаграмм не много.

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

A>ОК, пример из научной работы (на нормальной работе не дают применить )
Вот именно! На практике UML нет места. Только в институтах

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

A>Может кто еще расскажет про свой опыт UML?
Никто Потому что никто реальной пользы от этого не имеет.

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

F>Здравствуйте Mishka.NET, Вы писали:

M.NET>>Мне с некоторых пор не нравятся идеи ОО, на которых как раз и стоит UML. Аспектно-ориентированное проектирование куда как интереснее и полезнее.

F>Не исключаю. Когда-то перлись от процессного (aka структурного) подхода. К совоему стыду не знаю что есть "Аспектно-ориентированное проектирование": пару-тройку keyword'ов для поиска бы или ссылку какую.


Пользуйся cool site.

Но я бы не сказал, что ОО и АОР противоречат друг другу. По-моему это разные уровни абстракции.

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

F>Не исключаю. Когда-то перлись от процессного (aka структурного) подхода. К совоему стыду не знаю что есть "Аспектно-ориентированное проектирование": пару-тройку keyword'ов для поиска бы или ссылку какую.

http://aosd.net. Уже успели даже книжку выпустить — "Программирование на AspectJ".

F>У-ууу. Да, я подозревал о существовании у вас этой точки зрения (глядя на подпись . То, что вы написали здесь, очень хорошо можно экстраполировать на:
F>Война — это хорошо, потому что хорошо солдатам (им за это платят... в нормальной армии) и вдвойне хорошо генералам (начальникам, в вашей терминологии) — им еще больше платят + побрякушки дают и сапоги именные.
F>Голод — это хорошо (фермеры).
F>Болезни — хорошо (фармацевты и тп).
F>Попробуйте доказать, что не это хотели сказать (а если это... то кто из нас Frostbitten? .
Вообще-то я так и думаю Мне чужды человеческие ценности А, кстати, Frostbitten — это "обмороженный" или "отмороженный"?
Да, и прекращай общаться на Вы, 1) может оказаться, что я младше тебя. 2) так принято на RSDN. 3) да и вообще смущает официальность

M.NET>>У меня есть вопрос, и я его уже в 3 раз повторяю: расскажите как вы используете UML на практике, и что вы с этого имеете? Пока что я придерживаюсь того мнения, что UML — это баловство, без которого можно спокойно обойтись.
F>Мы рисуем диаграмки классов, чтоб посмотреть кто с кем завязан, рисуем диаграммы состояний, понятно за чем, еще много рисуем чтоб понять подсистемы и как они связаны, и чтоб понять что разработчик _хотел_ сделать (ведь как разработчикам нам мало важно что он _сделал_ и _как_, ведь вариантов много). Никакой генерации кода. Накакого Rational.
Да, наверно это помогает. Я умудряюсь все связи и взаимоотношения в голове держать.
F>Обойтись можно безо всего! Пушкин, чай, не в LaTeX'е воял .
У-у-у, дай я тебе пару баллов за Пушкина накину

F>Хм... к стати, memnto more (или как это там пишется . А если вас... эм... ... похитят инопланеняне , очевидно, вместе с вашим богатым обытом... как будет чувствовать себя ваша компания, лишившись архитектора, кот. не оставил, нахер, никакой документации, только код. А вопрос этот стоит здесь очень остро — текучка кадров.
У нас нет текучки кадров. Я ещё в своём уме и из такой компании не уйду — видано ли в России, чтобы если сборная страны по футболу играет, то фирма снимает местный паб, чтоб всем скопом матч смотреть, покупает всем пиво и никто не работает в этот день Ну и плюс никто не напрягает, тишина и покой. Деньги платят во-время и хорошие. Снега тут нет, всегда плюс, но не жарко. Скажи мне, ты б ушёл с такой работы?

F>P.S. Приятно было пообщаться, позиция ваша мне понятна, обоснованная позиция, но непреемлемая, например, для меня .
А то как же, затем и общаемся

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

M>Но я бы не сказал, что ОО и АОР противоречат друг другу. По-моему это разные уровни абстракции.
Скорее AO — это развитие идей ОО. К тому же AO может использовать ОО, привнося туда только концепцию аспектов.

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

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

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

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

МА>>Пробовал приобщиться, но бросил за ненадобностью. Гораздо эффективней применять теорию конечных автоматов.

F>Не могли бы Вы привести небольшой пример использования теории конечных автоматов применительно к проектированию программных систем

State Machine Diagramm из UML :-)))

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


M.NET>>>Я не developer и не coder, а software arhitect
А>>а рассуждаете как кодер (а вообще мне вспоминается дедушка Фрейд ...). Насколько я понимаю, до этого проекта, у Вас не было крупных проектов по созданию КИС, а конфигурирование 1С не считается ...
M.NET>Ну расскжи мне как должен рассуждать архитектор, да и ещё скажи чем ты занимаешься, чтоб хоть понимать обоснованность твоих высказываний.

Наверно, Вы таки стоит говорить ... Я занимаюсь КИС для РАО ЕС и Региональных энергокомпаний

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

M.NET>На самом деле я хотел сказать, что поскольку все создатели UML работают в Rational, то UML можно считать продуктом этой фирмы со всеми вытекающими отсюда проблемами.
А С++ разработал Страуструп, работающий в AT&T Продолжать?

M.NET>Пишу не с головы, а с опыта Мне легче — я точно знаю, что нужно. А менеджеров не стоит недооценивать, у них свои резоны на такое "невменяемое" поведение.
А после тебя — шиш да маленько — другой програмер и не разберется в тових прототипах без тебя

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

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

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

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

M.NET>Абсолютно безполезно, только время зря тратить

а ты никогда не пробовал в большом проекте работать? где разработкой занимаются несколько независимых команд? да еще и на разных языках говорящих? интересно как ты подходиш и объясняеш свои перлы проектирования, что да как им делать, и как это должно с твоей частью кода взаимодействовать?

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

AS>а ты никогда не пробовал в большом проекте работать? где разработкой занимаются несколько независимых команд? да еще и на разных языках говорящих? интересно как ты подходиш и объясняеш свои перлы проектирования, что да как им делать, и как это должно с твоей частью кода взаимодействовать?

Хороший вопрос. НО! Приведи мне пример, когда так люди работают. Я при таком подходе к сложному проекту скорее всего проектировал бы всё централизовано, и раздавал бы микрозадачи отдельным командам. А потом так же централизовано всё собирал бы. Для этого UML не нужен.

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

M.NET>Здравствуйте Alex_st, Вы писали:

AS>>а ты никогда не пробовал в большом проекте работать? где разработкой занимаются несколько независимых команд? да еще и на разных языках говорящих? интересно как ты подходиш и объясняеш свои перлы проектирования, что да как им делать, и как это должно с твоей частью кода взаимодействовать?

M.NET>Хороший вопрос. НО! Приведи мне пример, когда так люди работают. Я при таком подходе к сложному проекту скорее всего проектировал бы всё централизовано, и раздавал бы микрозадачи отдельным командам. А потом так же централизовано всё собирал бы. Для этого UML не нужен.

да конечно, все правильно... только задачи то как раздавать? подойти и сказать мол Вась, напиши вот пут так, а тут так, ... да и посмотри чтоб еще с той группой все работало?

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

AS>да конечно, все правильно... только задачи то как раздавать? подойти и сказать мол Вась, напиши вот пут так, а тут так, ... да и посмотри чтоб еще с той группой все работало?

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

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

M.NET>Здравствуйте Alex_st, Вы писали:

AS>>да конечно, все правильно... только задачи то как раздавать? подойти и сказать мол Вась, напиши вот пут так, а тут так, ... да и посмотри чтоб еще с той группой все работало?

M.NET>Наверно стоило бы писать спецификации к компонентам (в будущем WebService-ам) в виде требований по функциональности. То есть сказать, что нужно и какие накладываются ограничения, а уж разработчики потом сами решают как это всё делать — на выходе получается готовый компонент (сервис) с заранее определёнными качествами.

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

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

AS>так каким образом енту самую спецификацию описывать то? ты более универсальный способ чем UML знаеш?

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

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

AS>ну вот это и получается объяснение на уровне: напиши то, сам незнаю что, но чтоб зелененьким горело

Ну уж нет
Предположим группа архитекторов спроектировала систему. Предположим есть некий WebService, который является частью этой систему. Тогда запрос на разработку или спецификация будет выглядеть примерно так:
1. Имя WebService-а
2. Набор функций сервиса (и их имена) с подробным описанием того, что каждая функция делает. Форма описания следующая: на вход поступают такие данный, на выходе должны быть такие данные.
3. Ограничения, накладываемые на сервис. Например, как быстро он должен работать. Как часто будет меняться интерфейс. Как скоро этот сервис должен вступить в эксплуатацию.

Скажи, этого достаточно для разработчика?

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

M.NET>>Наверно стоило бы писать спецификации к компонентам (в будущем WebService-ам) в виде требований по функциональности. То есть сказать, что нужно и какие накладываются ограничения, а уж разработчики потом сами решают как это всё делать — на выходе получается готовый компонент (сервис) с заранее определёнными качествами.

AS>так каким образом енту самую спецификацию описывать то? ты более универсальный способ чем UML знаеш?

Ты знаешь не надо забывать о том что эту компоненту которую
они напишут, я еще и юзать буду. Притом строго определенным
образом. Если я ее буду юзать в C++ то дам им header с написанными
функциями. Если через ком то то же самое только в idl. Такого
что я им говорю сделайте это но еще не знаю в чем я буду
с этим работать не бывает.

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

M.NET>Здравствуйте Alex_st, Вы писали:

AS>>ну вот это и получается объяснение на уровне: напиши то, сам незнаю что, но чтоб зелененьким горело

M.NET>Ну уж нет
M.NET>Предположим группа архитекторов спроектировала систему. Предположим есть некий WebService, который является частью этой систему. Тогда запрос на разработку или спецификация будет выглядеть примерно так:
M.NET>1. Имя WebService-а
M.NET>2. Набор функций сервиса (и их имена) с подробным описанием того, что каждая функция делает. Форма описания следующая: на вход поступают такие данный, на выходе должны быть такие данные.
M.NET>3. Ограничения, накладываемые на сервис. Например, как быстро он должен работать. Как часто будет меняться интерфейс. Как скоро этот сервис должен вступить в эксплуатацию.

M.NET>Скажи, этого достаточно для разработчика?

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

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

Не правда. UML был придуман для краткого изложения мыслей. Если ты потом берёшься объяснять кому-то, что ему надо делать, то к этим диаграммам всё равно напишешь тонну голого текста, поясняющего что да как. Одной картинкой сыт не будешь

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

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

Очень, ну очень полезная весчччч...

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

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

M.NET>Не правда. UML был придуман для краткого изложения мыслей. Если ты потом берёшься объяснять кому-то, что ему надо делать, то к этим диаграммам всё равно напишешь тонну голого текста, поясняющего что да как. Одной картинкой сыт не будешь
а вот енто уже зависит от умения грамотно составить диаграммы

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

M.NET>>Не правда. UML был придуман для краткого изложения мыслей. Если ты потом берёшься объяснять кому-то, что ему надо делать, то к этим диаграммам всё равно напишешь тонну голого текста, поясняющего что да как. Одной картинкой сыт не будешь
AS>а вот енто уже зависит от умения грамотно составить диаграммы

Всё на диаграмме не изобразишь. Пояснения всё равно нужны.

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

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

L>>Очень, ну очень полезная весчччч...

F>Судя по прениям, вызванными вопросом, весч имеет своих противников и стороников, следовательно нет единого устоявшегося мнения, поэтому все-таки придется изучать, чтобы составить свое...

Только вот что-то сторонники не могут внятно объяснить чем именно она
так хороша.

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

A>UML — Унифицированный язык моделирования. Моделирования. То есть прежде всего он придуман для унифицированного представления предметной области, ее единого описания с различных точек зрения. Во многих задачах лучше подходит, чем тот же IDEF0.

A>Мишка тут писал про отовые прототипы... Без изучения предметной области этого сделать нельзя — здесь UML и пригодится.

Можно сразу пример твоего проекта, в котором ты использовал UML
и это действительно тебе сильно помогло.

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

AA>>Мишка тут писал про отовые прототипы... Без изучения предметной области этого сделать нельзя — здесь UML и пригодится.
A>Можно сразу пример твоего проекта, в котором ты использовал UML
A>и это действительно тебе сильно помогло.

Я уже писал — ИС института (у нас в Универе на институты разбито, потом только на факультеты) — вся инфа по студентам, успеваемости, учебным планам и много чего еще вплоть до оборудования. Проект недавно начался, здесь как раз и нужно изучение предметной области в одном ключе с использованием одной нотации. Кое-где уже есть реализация, использующая эти диаграммы. Причем сам UML используется пока только % на 20 по той же причине — разработка только началась, дальщше его использование возрастет.

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

A>Я уже писал — ИС института (у нас в Универе на институты разбито, потом только на факультеты) — вся инфа по студентам, успеваемости, учебным планам и много чего еще вплоть до оборудования. Проект недавно начался, здесь как раз и нужно изучение предметной области в одном ключе с использованием одной нотации. Кое-где уже есть реализация, использующая эти диаграммы. Причем сам UML используется пока только % на 20 по той же причине — разработка только началась, дальщше его использование возрастет.

А чего бы просто базу в SQL сервере не сделать безо
всякого UML и дальше от этого плясать.

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

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

A>>Я уже писал — ИС института (у нас в Универе на институты разбито, потом только на факультеты) — вся инфа по студентам, успеваемости, учебным планам и много чего еще вплоть до оборудования. Проект недавно начался, здесь как раз и нужно изучение предметной области в одном ключе с использованием одной нотации. Кое-где уже есть реализация, использующая эти диаграммы. Причем сам UML используется пока только % на 20 по той же причине — разработка только началась, дальщше его использование возрастет.

A>А чего бы просто базу в SQL сервере не сделать безо
A>всякого UML и дальше от этого плясать.

браво, Анатоликс! Просто базу! :-"Просто базу" надо еще спроектировать исходя из определенных требований и анализа предметной области. "Плясать от базы" — это хорошо для тривиальных задач, но в серьезных системах это, простите, дилетантство. Такой подход "снизу вверх" не оправдает себя.

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

M.NET>Здравствуйте Alex_st, Вы писали:

M.NET>>>Не правда. UML был придуман для краткого изложения мыслей. Если ты потом берёшься объяснять кому-то, что ему надо делать, то к этим диаграммам всё равно напишешь тонну голого текста, поясняющего что да как. Одной картинкой сыт не будешь
AS>>а вот енто уже зависит от умения грамотно составить диаграммы

M.NET>Всё на диаграмме не изобразишь. Пояснения всё равно нужны.
так вот именно что пояснения всеравно нужны, но это только пояснения, а основным источником информации являются диаграммы

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

N>браво, Анатоликс! Просто базу! :-"Просто базу" надо еще спроектировать исходя из определенных требований и анализа предметной области.

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

"Плясать от базы" — это хорошо для тривиальных задач, но в серьезных системах это, простите, дилетантство. Такой подход "снизу вверх" не оправдает себя.

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

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


A>Почему дилетанство. У тебя есть хорошо спроектированная
A>база, если ты в нее данные закачаешь как предполагается
A>то задача будет практически уже сделана, т.к.
A>и ввод данных будет возможен единственным
A>образом и отчеты будет понятно как строить.

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

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

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

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

Я просто не понимаю почему надо писать в UML, я понимаю
что писать надо, надо проектировать, надо документировать но UML
здесь причем.

Вообщем я думаю что UML здесь используют с той же целью
как медики и аптекари используют латынь
1) Потому что так принято, так модно
2) Чтобы никому непонятно было и денег больше платили.

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


A>Я просто не понимаю почему надо писать в UML, я понимаю
A>что писать надо, надо проектировать, надо документировать но UML
A>здесь причем.

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

A>Вообщем я думаю что UML здесь используют с той же целью
A>как медики и аптекари используют латынь
A>1) Потому что так принято, так модно
A>2) Чтобы никому непонятно было и денег больше платили.
так на UML кокраз и нужен чтоб всем понятно было! это УНИФИЦИРОВАННЫЙ язык, т.е. единый для все, чтоб всем было точно понятно что проектировщик имел ввиду, а не каждый трактовал слова проектировщика посвойму

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

A>Ну можно и так сказать, а можно сказать что UML это усложненный
A>подход. Зависит от точки зрения.

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

A>Вообщем я думаю что UML здесь используют с той же целью
A>как медики и аптекари используют латынь
A>1) Потому что так принято, так модно
A>2) Чтобы никому непонятно было и денег больше платили.
По-моему рецепты пишут на латыни для того, чтобы если ты вдруг поедешь в Гондурас, тебе там в аптеке по рецепту, выписаному в Росии, не выдадут, скажем, пурген вместо аспирина...

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

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

AS>да UML просто притом, что в нем проще документировать взаимодействие компонент сложной системы.
Дак чем легче то?

AS>единый для все, чтоб всем было точно понятно что проектировщик имел ввиду, а не AS>каждый трактовал слова проектировщика посвойму
Дак не может же быть чтобы проектировщик SQL не знал.
Как он тогда базу должен проектировать?

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

F>Если UML придуман именно для этих целей, то по-моему было бы удобнее использовать его, а не, скажем, просто английский язык (или русский), хотя бы потому, что в данном случае он (UML) лаконичнее и точнее.
SQL или С++ тоже абсолютно однозначен

F>По-моему рецепты пишут на латыни для того, чтобы если ты вдруг поедешь в Гондурас, тебе там в аптеке по рецепту, выписаному в Росии, не выдадут, скажем, пурген вместо аспирина...

А почему латынь а не английский скажем, пользы то больше
было бы если бы всех медиков английскому выучили.

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

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

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

AS>>да UML просто притом, что в нем проще документировать взаимодействие компонент сложной системы.
A>Дак чем легче то?

AS>>единый для все, чтоб всем было точно понятно что проектировщик имел ввиду, а не AS>каждый трактовал слова проектировщика посвойму
A>Дак не может же быть чтобы проектировщик SQL не знал.
A>Как он тогда базу должен проектировать?
для проектирования базы не нужно знать SQL, так же как для проектирования какой то системы не ныжно знать C++ или другой язык програмирования! проектировщик это не программер!!!

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

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

F>>Если UML придуман именно для этих целей, то по-моему было бы удобнее использовать его, а не, скажем, просто английский язык (или русский), хотя бы потому, что в данном случае он (UML) лаконичнее и точнее.
A>SQL или С++ тоже абсолютно однозначен

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

F>>По-моему рецепты пишут на латыни для того, чтобы если ты вдруг поедешь в Гондурас, тебе там в аптеке по рецепту, выписаному в Росии, не выдадут, скажем, пурген вместо аспирина...

A>А почему латынь а не английский скажем, пользы то больше
A>было бы если бы всех медиков английскому выучили.

дык все исходя из удобств, и просто conventional...

зы: лет десять назад видел я и реализацию Тетриса на bat-скриптах (5-го ДОСа, кажеться). Впечатлило.Тоже пример, что МОЖНО топором Венеру Милосскую выстрогать, вопрос, сколько усилий на это уйдет.

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

F>Так что хотелось бы порекомендовать отвечать на вопрос "Почему НЕ надо ИЗУЧАТЬ UML" и поконкретнее... п то и мне теперь интересно стало Всегда думал, что любое знание не помешает, а вы тут такое развели!

Потому что на изучение вего требуется время, при этом
есть вещи которые мне хочется изучить больше чем UML.

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

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

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

F>Разберетесь кто тут "А" ?

A>>>Я уже писал — ИС института ...

A>>А чего бы просто базу в SQL сервере не сделать безо
A>>всякого UML и дальше от этого плясать.

Я — это A, а A — это он

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


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

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

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

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

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 можно использовать без всяких проблем вместе, они не противоречат друг-другу.

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

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

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

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

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

A>Обрати внимание что и в MFC и в VCL люди решили писать документауию не в UML формате.

Уже который раз замечаю, что у людей крайне смутное представление о истории развития технологий. Когда был придуман UML и когда была начата разработка MFC и VCL?

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

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

Вот оно что... Тогда вообще спор беспредметен. XP и RUP есть взаимоисключающие подходы к организации процесса производства софта. Тогда я согласен с твоими выводами — для XP UML не нужен, что вовсе не означает UML не нужен.

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

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

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

Нет. Методология XP говорит — "пишите код, это лучшая документация". Хоть это и очень сильное утверждение, но оно приемлемо для процесса разработки на базе XP.

Здравствуйте m.a.g., Вы писали:

MAG>Уже который раз замечаю, что у людей крайне смутное представление о истории развития технологий. Когда был придуман UML и когда была начата разработка MFC и VCL?

Да не в этом дело. Для C# если хочешь попробуй найти UML.

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

A>Да не в этом дело. Для C# если хочешь попробуй найти UML.

Диаграммы классов, например, никто не отменял...

Забыл еще сказать: есть сильная потребность в каких-то других диаграммах. Серьезно.

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

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

M.NET>>> Я сижу и проектирую большую систему — у меня нет времени на написание документации и рисовние диаграмм, польза от которых сомнительна.
A>>Ну хорошо, скажи тогда, что получается в результате твоего проектирования? Думаю, тоже подобие диаграмм. Или только словесные описания? Что получается на выходе? Проектирование на уровне в целом системы в какой нотации происходит?
MN>А на выходе получается прототип системы, полурабочий, но его хоть можно показать. А за рисование диаграмм надают по шее, и правильно сделают, поскольку толку от диаграмм не много.

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

А все-таки, что же такое прототип в твоем понимании? Непонятно, что такое полурабочий и рабочий прототип. Примерчик прототипа, пожалуйста

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

P>Шаблон проектирования из 3-х объектов и 5-ти классов занимает страницу. Реальная средняя прога из 500-700 классов никуда не влезает. Более того, ее вредно переносить в диаграммы, ибо они дают слишком статичный узкий взгляд, хотя и пропагандируют "высокоуровневость и универсальность".

P>Я прав?

для этого есть разбиение на пакеты. А для нестатичного взгляда есть нестатичные виды диаграмм. Диаграмма классов — это как раз статический аспект системы.

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

MN>Ну ка расскажи мне прямую и косвенную выгоду от использования UML. Я здесь давным давно задавал вопрос: "А на кой всё это нужно?". И оказалось, что никто толком не знает

Извини, что вмешиваюсь.

Реальный пример:
1). Диаграмма классов для иллюстрации заказчику идеи алгоритма.
2). Statechart diagram для иллюстрации работы визарда.

Прямая выгода налицо: если бы я не знал бы UML, то не получил бы этот заказ, так как не смог бы однозначно объяснить заказчику суть своей идеи. Заказчик сидит в US и C++ не знает. Внятно описать всё это на хорошем литературном English я бы пожалуй не смог бы.

Предложи альтернативу для моей ситуации.

Д>для этого есть разбиение на пакеты. А для нестатичного взгляда есть нестатичные виды диаграмм. Диаграмма классов — это как раз статический аспект системы.

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

Понимаешь? Все спроектировано так, чтобы не было сильной связности. Зачем же мне документировать классы, если я завтра их переделаю. Получу эквивалентную структуру, которая либо быстрее работает, либо занимает меньше памяти. Допустим, я вношу кэширование запросов. Интерфейс не меняется, но возможно меняется структура классов, появляются обертки. Вледуя принципу "не исправляй, но дописывай", я добавляю классы, перегружаю функции и т.д. Мне вообще не нужна структура склассов. И моему приемнику нужна не будет. Из диаграммы он ничего не поймет. Но если он хорошо знаком с паттернами, то названия и небольшие комментарии сразу прояснят ему картину. Завязка на классах — ненужное уточнение.

Так же как ты в use case не пишешь "пользователь нажимает кнопку <Подтвердить заказ> в нижнем левом углу окна", я не стану уточнять, где какие классы. Хотя это и не значит, что я вообще не буду упоминать классы. То же самое с sequence.

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

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

P>Понимаешь? Все спроектировано так, чтобы не было сильной связности. Зачем же мне документировать классы, если я завтра их переделаю.

ну так не документируй. Остановись на пакетах и интерфейсах, если тебе этого достаточно. Делать заметки тебе опять же никто не мешает.

P>Именно из этих соображений я и говорю, что UML — детская забава. Нужны более мощные и специализированные диаграммы.

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

приводить MSDN в качестве примера вообще смехотворно. Можно еще сослаться на WinAPI и сказать, что ООП — это ненужное излишество, а type cast — это рулезнейший приём и его надо пихать везде где можно
Рекомендую попробовать применить функцию StackWalk64, используя только MSDN, в качестве примера и упражнения

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

представлять UML как средство зашибания денег, которое придумали в Rational — это просто передергивание фактов. На самом деле корни UML растут из Ericsson, где он разрабатывался как средство для внутреннего употребления. Rational появился много позднее.