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

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.

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

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

Сначала напишу пару строк, предназначенных для того, чтоб ко мне не придирались по пустякам.
Диаграммы — это хорошо! ок.
Проектирование — супер.
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 классов никуда не влезает. Более того, ее вредно переносить в диаграммы, ибо они дают слишком статичный узкий взгляд, хотя и пропагандируют "высокоуровневость и универсальность".

Я прав?

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

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

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

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

A>>Это достаточный пример для использования UML?
MN>Нет. Покажи мне где выгода от использования 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>Я прав?

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

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

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

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

P>Я прав?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

И вот вчитался я в 322 сообщения по сабжу... (точне в первые 70-80) ... а где бы достать в электронном виде учебник или статьи по UML ?

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

V>И вот вчитался я в 322 сообщения по сабжу... (точне в первые 70-80) ... а где бы достать в электронном виде учебник или статьи по UML ?

здесь

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

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

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

P>Наверняка, здесь они очень полезны. Хитрые манипуляции с битами, вызовами и рекурсией — самое оно для UML.

я наверно неясно сказал.. я имел в виду — в MSDN они были бы очень к месту.. но не для WinAPI, а для описания общей архитектуры. Например — для описания того, в каком порядке нужно вызывать функции при работе с сокетами. Опять же sequence diagram.
И это очень плохо, что их там нет.

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

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