Почему UML сосёт?

Был давеча на собеседовании в мотороле. Спросили - знаю ли я UML. Я ответил, что нет, т.к. вроде нигде не используется. Увидел пару удивленных глаз: "А у нас целые проекты на этом....".

nashel gde sprosit' :D

> nashel gde sprosit' :D

В флейме рождается истина! Не на РСДН же мне было идти. :)

Для небольшого проекта на двоих сосет модель разработки waterfall. В разновидностях agile не предусматривается такого количества документации, но ничто не мешает использовать UML в той, которая есть.

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

> Для небольшого проекта на двоих сосет модель разработки waterfall.

Блин, в точку, надо было мне в названии темы написать не UML, а waterfall. Этот человек хочет, чтоб мы с ним вдвоём именно что два месяца сидели-проектировали и составляли "подробную проектную документацию" (если честно, я плохо понимаю, что он под этим разумеет). Ибо "сейчас нас двое, а потом может стать гораздо больше, и надо уже сегодня думать о завтрашнем дне". У меня уже все разумные агрументы исчерпаны, на языке вертится только "околей, быдло, и сдохни", вот и пошёл за подмогой на ЛОР.

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

...короче, сосет все, что кончается на *ML, кроме окамля :)

использование умл может быть 3 типов:

* всё иделально спроектировали по идеально собраным требованиям и потом можно программить

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

* всё типо спроектировали, да малость ошиблись в умле, да и изменениям код не подлежит, да ничего не поделаешь: давай перепишем это, вот это и немного это с нуля.

вы к какой группе относитесь? :)

> Но чувак вантузойд и дельфист со стажем, и блин спорить я уже с ним устал. 8-/ Как доходчиво объяснить ему сабж?

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

> Ну или как вариант, убедите меня, что UML - это круто. :)

OOD/OOP suxx.

UML сосет ибо ненужен. Тем более для небольшого проекта. Тем более если заказчик от вас этого не требует. Лучше создать документ "Architecture vision" провести пару митингов и записать туда общие архитектурные решения своими словами. Можно что то нарисовать на бумажке, отсканить и вставить. И не надо пытатся спланировать заранее каждую мелочь каждый класс и каждую функцию, потому что это потом только мешает и конечный продукт обычно заметно отличается от такого UML'а. Потом получается, что надо будет UML уже под код подгонять иначе он не будет соответствовать. На крайняк диаграмму классов можно и по коду сгенерить, даже на питоне, так она хотя бы ему соответствовать будет. Так что если хотите нормальную документацию лучше пишите doc-strings и юзайте pydoc. Так хоть польза будет - и вам и тем кто потом это сопроваждать будет.

> Для небольшого проекта на двоих сосет модель разработки waterfall.

Это спорный вопрос: waterfall есть частный случай итерационной модели.

Просто количество итераций равно единице.

Такое может случиться только в небольшом проекте.

Сосёт не UML, сосёт RUP.

Аргументировать слабО?

togda ubei ego manualom ot `GNU Emacs'. :)

> И зачем тебе с ТАКИМ вместе работать? Команды из вас не получится.

Тут ты прав, анонимный брат. Я уже неспешно подыскиваю другую работу.

Имеется в виду, что RUP сосёт для проекта, который делают 2 человека на python.

> Блин, в точку, надо было мне в названии темы написать не UML, а waterfall.

Вот именно. UML и waterfall перпендикулярны.

UML - унифицированный язык. Лучше, чем типичный корявый языка большинства программистов.

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

а вот с этим согласен =)

>...короче, сосет все, что кончается на *ML, кроме окамля :)

Какой облом, а я Mercedes ML собрался покупать :((

> waterfall есть частный случай итерационной модели.

Не совсем. Разные подходы к документированию и взаимодействию в команде.

>> waterfall есть частный случай итерационной модели.

> Не совсем. Разные подходы к документированию и взаимодействию в команде.

Да, конечно. Я немного пошутил про одну итерацию.

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

Просто ко 2-ой половине жизни становишься ленивым, и лень писать программы, охота руководить/рисовать диаграммы. А автору топика посоветовал бы освоить XP, и обосновать старшему товарищу, что XP в данном проекте будет более подходящим решением, чем RUP.

> быдлокодерство обычно успевает надоедает ко второй половине жизни.

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

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

У Гради Буча хорошо расписан итеративный процесс разработки. На счет XP тебе уже советовали. Причем обе эти вещи хорошо сочетаются друг с другом.

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

В общем, посоветовал бы прислушаться с старшему товарищу. Может быть, он и прав :) Главное, не потерять правильное зерно и не превратить полезную вещь в тупое и совершенно никчемное следование инструкциям и правилам. Поменьше рутины и побольше свободы и полета фантазии! :)

Вот еще.

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

Сам UML здесь не причем. Его можно использовать по-разному. Хоть так, хоть эдак.

Он младший товарищ. :) И в XP я его уже тыкал носом. И проектирование у нас никто не отменял, у меня на машине стоит trac, туда складываются все идеи, юз-кейсы и заметки об архитектуре. Чувак же именно прибился по UMLю и RUPообразным методикам, и от меня хочет того же самого.

Хотя, вроде бы получилось направить его энергию в мирное русло. Он сейчас сидит около меня, я ему объясняю своё видение проекта, а он старательно рисует диаграммы на пальмовых лис^W^Wбумажке, а потом перерисовывает в своём энтерпрайз архитекте. Потом я беру у него картинки и засовываю в вики. И все довольны.

>>...короче, сосет все, что кончается на *ML, кроме окамля :)

>Какой облом, а я Mercedes ML собрался покупать :((

Радуйся, он ещё и сосать будет

И правда, почему сосет ?!!

>>>...короче, сосет все, что кончается на *ML, кроме окамля :)

>>Какой облом, а я Mercedes ML собрался покупать :((

>Радуйся, он ещё и сосать будет

С Mercedes ML от желающих сосать и так отбоя не будет :))

Потому что это не пылесос производства Microsoft.

> Блин, в точку, надо было мне в названии темы написать не UML, а waterfall.

Ну нифига себе спутал что-то с чем-то!

А UML отлично применяется и в итеративном и даже в экстремальном процессе.

> Этот человек хочет, чтоб мы с ним вдвоём именно что два месяца сидели-проектировали и составляли "подробную проектную документацию" (если честно, я плохо понимаю, что он под этим разумеет). Ибо "сейчас нас двое, а потом может стать гораздо больше, и надо уже сегодня думать о завтрашнем дне".

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

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

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

> UML сосет ибо ненужен.

> Можно что то нарисовать на бумажке, отсканить и вставить.

Ага. А рисовать будем не иначе, как египетскими иероглифами. Ибо UML сосет. Ага, ага.

> Сосёт не UML, сосёт RUP.

Так и запишем: tailoring ниасилил.

> стоит trac, туда складываются все идеи, юз-кейсы и заметки об архитектуре

Идея хорошая (сам для этого использую Мантису), но когда количество идей переползает за полсотни, становится трудно это все понимать. В этом смысле графика позволяет выйти во "второе измерение" и увидеть всю картину целиком, с высоты птичьего полета, так сказать.

> > Сосёт не UML, сосёт RUP.

> Так и запишем: tailoring ниасилил.

Список осиливших в студию! Еще желательно процент софта в вашем дистрибутиве, который быдл написан со следованием RUP. И такой же процент от вебсайтов.

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

Купить плоттер и печатать диаграммы на А0? :)

И потом, в вики всегда можно разбить одну разросшуюся страницу на несколько маленьких.

> Список осиливших в студию!

Бугага!

> Еще желательно процент софта в вашем дистрибутиве, который быдл написан со следованием RUP. И такой же процент от вебсайтов.

Если уж брать такие нишевые продукты, то в отдельных случаях (например, при разработке для госзаказчика) число продуктов в нашем дистрибутиве, разработанное с использованием RUP доходит до 100%. То же касается и вебсайтов для тех же заказчиков.

:-)

> Купить плоттер и печатать диаграммы на А0? :)

Открою маленький секрет: в UML всегда можно разбить одну разросшуюся диаграмму на несколько маленьких ;-).

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

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

Проблема не в объеме, проблема в организации материала. Скажем, я тоже периодически практикую UML-гипермедиа, которая по сути является применением того же принципа вики, но во многих измерениях. Единственное, что печально -- в FOSS нет удачных UML-редакторов хотя бы уровня Visio, не говоря уже о Rose. Потому наша проектная вика местами напоминает чудовище Франкенштейна. :-(

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

Ни разу не удалось заблудиться в собственной вике. ЧЯДНТ? :)

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

> разработке для госзаказчика

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

>> Список осиливших в студию!

>Бугага!

Вот, самим же смешно :-))

>> Еще желательно процент софта в вашем дистрибутиве, который быдл написан со следованием RUP. И такой же процент от вебсайтов.

> Если уж брать такие нишевые продукты, то в отдельных случаях (например, при разработке для госзаказчика) число продуктов в нашем дистрибутиве, разработанное с использованием RUP доходит до 100%. То же касается и вебсайтов для тех же заказчиков.

Ну, госзаказ - это особая сфера, где действуют правила вида "больше бумаги - чище жопа"... (и все равно ЕГАИСы имеют место быть).

моя цель-то не флеймить. Имеем факт - RUP и прочие процессы не используются в огромных пластах софта.

* Ими не пользуются в OSS - думаю в наугад взятом дистрибутиве линукса нет почти/вообще ничего, что было бы насписано с использованием RUP.

* Ими не пользуются проприетарщики тоже. Никогда не слышал чтобы microsoft/google/adobe/etc пользовалиcь RUP.

Если вы используете RUP, не можете пояснить, почему им пользуются только в каких-то нишах?

В качестве первого приближения возьмем "RUP - процесс разработки по госзаказу" ;-) Есть ли что поточнее?

> Просто ко 2-ой половине жизни становишься ленивым, и лень писать программы, охота руководить/рисовать диаграммы.

блин, как метко замечено :) такая же хрень :)

> Вот, самим же смешно :-))

Грубо говоря, какой вопрос -- такой и ответ. Скажем, себя я считаю если не осилившим, то хотя бы разбирающимся. Посмеемся вместе?

Почти наверняка я уверен, что RUP используют хотя бы некоторые подразделения IBM. Дальше уже можно брать Гугл в зубы и искать RUP Success Stories.

> Ну, госзаказ - это особая сфера, где действуют правила вида "больше бумаги - чище жопа"...

А теперь представьте себе, что это -- юристы :-)

> (и все равно ЕГАИСы имеют место быть).

Ну, ЕГАИС мы тоже разбирали, как пример того, что мы -- далеко не самые худшие :-)

> * Ими не пользуются проприетарщики тоже. Никогда не слышал чтобы microsoft/google/adobe/etc пользовалиcь RUP.

Ну, проприетарщики, как всегда, упражняются в изобретении собственных велосипедов. У Microsoft, например, есть MSF, хотя у него как бы тоже есть своя область применения. У других -- честно, не интересовался, сейчас вот, нашел "процесс разработки Google", но пока не въехал.

> Если вы используете RUP, не можете пояснить, почему им пользуются только в каких-то нишах?

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

По идее, это определение хорошо объясняет, почему RUP не используется в FOSS, а также почему не используется у гигантов рыночной индустрии ПО. С другой стороны, это отлично объясняет интерес IBM к RUP вообще, и Rational, в частности.

Кроме этого RUP может использоваться тысячами мелких и средних контор (считайте, что IBM -- самая крупная из них ;-) без существенной засветки создаваемых ими решений, потому как это не рыночные продукты. То, что эти компании не светятся, может создавать иллюзию неиспользования. Как обстоит дело на самом деле -- хз, нужны аналитические исследования, а я таких не видел.

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

Ну, у нас с этим не так плохо. Все зависит от людей, которые это дело организовывают :-)).

> Ни разу не удалось заблудиться в собственной вике. ЧЯДНТ? :)

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

Точнее сказать не могу -- телепатии не обучен.

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

Есть такое. У нас тоже по процессу можно использовать два способа представления вариантов использования. Скажем, пока рассматриваются только основные пути -- текст рулит. Когда начинаем считать альтернативы, то вначале еще жить можно (благо есть методики), но когда число ветвлений становится больше трех, не говоря уже о циклах и сложных жизненных циклах объектов, то тут уже нифига не разберешься -- пора переходить к графике. Опять же, графика мобилизует писать (точнее, рисовать) кратко. Скажем, в тексте вариант использования можно рассусолить на три страницы, а в графике (естессно, при упомянутых ограничениях на A4) уже просто обязан либо описать кратко, либо бить на осмысленные фрагменты. Плюс лучше видно, в какой точке процесс может ветвиться и каким образом.

Другая часть -- объектная модель предметной области. Можно, конечно, завести текстовый словарь с индексацией, и этого часто может быть достаточно. Только вот словарь -- не учебник, и если новичку предложить знакомиться с предметной областью, то словарь -- это худшее, что можно предложить. Вот так и рождаются документы типа "вольное описание предметной области" или "краткое введение в систему классов" страниц этак на 50-100, да еще в литературном стиле наших программеров. И не дай бог еще с перекрестными ссылками -- GOTO просто отдыхает. А так рисовать картинки прикольно: можно расположить их в нужном порядке, скажем, звездой, где в центре -- самые важные понятия. На презентации просто вывел диаграмму на доску, и пошел вести повествование, пользуясь диаграммой, как содержанием. При этом люди видят всю картину, пока я объясняю одно, они могут готовить вопросы к другим частям диаграммы, иногда вопрос может запросто по месту свернуть ход обсуждения. На линейных текстовых презентациях такого выбора, как правило, нет, и слушатели очень часто просто засыпают.

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

Наконец, ярким примером эффективности графики является банальное использование разнообразных (притом, стандартизированных!) графических языков в области электроники и электротехники. Не говоря уже о прикладной и строительной механике. Думаю, никто в трезвом уме не будет утверждать, что "электрические схемы сосут"? Более того, у меня есть суровое подозрение, что визуальная основа проектирования "железа" и снобизм в этом плане программистов поясняет различие в качестве получаемых на выходе продуктов, а также сроках их разработки.

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

Пожалуй, единственный недостаток графики -- думать при создании и в самом деле надо больше.

> Ну, проприетарщики, как всегда, упражняются в изобретении собственных велосипедов. У Microsoft, например, есть MSF, хотя у него как бы тоже есть своя область применения. У других -- честно, не интересовался, сейчас вот, нашел "процесс разработки Google", но пока не въехал.

wow, спасибо что навели. никогда бы не подумал... (почитав) ну, у них сходства с RUP мало... очень мало процесса...

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

...звучит правдоподобно... спасибо