UML, чертежи, принципиальные схемы — ненужны?

> И что из вышесказанного доказывает, что ты действительно осилил UML?

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

Это из моего опыта. Допускаю, что кто-то в каком-то другом секторе мог его и в начале разработки использовать, мало ли кудесников на земле.

О UML как дополнительном средстве документирования для будущих поколений после имплементации и тестирования (т.е. после окончания разработки) - уже говорилось. Но код копируется и так (в отличие от моста). А через 10 лет скорее всего вообще не понадобится, так как придут вообще другие технологии. Т.е. некому будет вообще читать, и программу перепишут с нуля исходя из других предположений и требований. Т.е. даже как пост-документация он скорее всего будет невостребован.

А в начальной разработке - от него только вред. Тех кто суёт свои классовые (особенно) диаграммы - нужно изолировать от коллектива чем раньше тем лучше - чтобы проект не загнулся. Деление на модули или отдельные куски, или функции, в зависимости от квалификации программиста, с распределением этих модулей и требований к ним, подбор спецов, способных сделать эти модули от начала и до конца, а также тех - кто напишет правильные протоколы, все средства взаимодействия - залог успеха. Мост нельзя так разделить на куски, а прогу можно. Хотя бы пайплайн (паттерн, не юниксовый) это позволяет (внутри процесса например), или иное взаимодействие модулей (а описание протокола это уже вне UML. Т.е. главное: код, протокол взаимодействия компонентов, как делить на модули итд - всё самое главное - вне UML. Тогда зачем он нужен?).

К.О. сообщает, что при проектировании моста (да и любого другого РАССЧИТАННОГО объекта архитектуры), он также делится на модули и существуют схемы взаимодействия между модулями.

Это не совсем так. Модульность в таких конструкциях совсем слабая, они просчитыаются целиком. Деление на юнитарные блоки конструкции для моделирования и модульность в плане отдельных макрококомпонент вещи разные.

я не понял причём тут работа в кремниевой долине, но опыта применения UML у Вас, согласно Вашим же словам, всего-то пару лет, причём, судя по Вашим же словам, не слишком удачных, у меня только один вопрос - вот зачем на таком «богатом» материале строить умозаключения??

А через 10 лет скорее всего вообще не понадобится, так как придут вообще другие технологии.

монсеньор футурист

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

и немножко романтик

А в начальной разработке - от него только вред.

пруф будет?

> К.О. сообщает, что при проектировании моста (да и любого другого РАССЧИТАННОГО объекта архитектуры), он также делится на модули и существуют схемы взаимодействия между модулями.

Я уже писал выше, что софтваре-инджиниринг - гораздо сложнее инженерии мостов. Да, мост можно рассчитать. А программу (никем ещё не написанную) рассчитать нельзя. Если она не тривиальна. Посмотрите на все большие проекты например на highscalability (амазон, ебей, фейсбук, гугл итд) - всё это кастом системы, которые эволюционируют. Могут начаться с одного и прийти совсем к другому через несколько лет. Их подстраивают, перенастраивают, удаляют узкие места по ходу (но это тут же рушит ваши UML диаграммы!) итд. Разве можно подобную систему рассчитать, не зная даже будущей нагрузки? UML полезна какой-то один момент: после тестирования и релиза, и до следующего нового требования и рефакторинга.

пруф будет?

какого рода пруф ожидаешь, когда некий тейлганнер тебе на ушко шепнёт?

какого рода пруф ожидаешь, когда некий тейлганнер тебе на ушко шепнёт?

для меня Ваши сексуальные фантазии не представляют интереса

повторюсь, мне интересно обоснование тезиса: «В начальной разработке - от UML только вред.»

> я не понял причём тут работа в кремниевой долине, но опыта применения UML у Вас, согласно Вашим же словам, всего-то пару лет, причём, судя по Вашим же словам, не слишком удачных, у меня только один вопрос - вот зачем на таком «богатом» материале строить умозаключения??

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

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

Я уже писал выше, что софтваре-инджиниринг - гораздо сложнее инженерии мостов.

лишь бы ляпнуть чего

А программу (никем ещё не написанную) рассчитать нельзя.

1. что значит рассчитать программу?
2. и почему нельзя?

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

а мост типа можно, да? :LOL:

для меня Ваши сексуальные фантазии не представляют интереса

это хорошо. Но ниже было не высказывание мной моих фантазий, а вопрос на счёт ваших. Я вот люблю разобрать человека 'по Фрейду'.

повторюсь, мне интересно обоснование тезиса: «В начальной разработке - от UML только вред.»

Типа всего ниже сказанного не достаточно? Вполне, имхо, доходчиво и в рамках лора написано. Так вот что не устраивает то? Явно же вам не нужны пруфы и вы хотите нечто особенного. Чего?

На самом деле ещё меньше чем два года, там нечего учить два года, не язык программирования же.

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

Во всех группах, где я работал, от UML не было никакого толка.

поверьте, это вовсе не от того, что UML такой плохой :)

Естественно, я делаю заключения на основании только своего опыта. На основании Вашего опыта, извините, пока не умею.

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

2. и почему нельзя?

можно, но это не практично и финансово не выгодно. Срок эксплуатации ПО несколько лет, срок эсклуатации чего-то вещественного десятилетия. Можно посмотреть на проблему и с такой стороны.

>> А в начальной разработке - от него только вред.

пруф будет?

нет конечно.

из опыта.

не буду же я называть фамилии наивных мальчиков только что из курсов или универов, пытавшихся претворить в жизнь рекламки и промывание мозгов от больших корпораций, не будем называть каких, которых закидали ссаными тряпками сильные девелоперы, и сделали потом работающую успешную систему. Или незакидали, и потом проект погряз в неэффективности, склоках, потом его так и замяли. Кажется, от 50 до 75% заваленных проектов считалось лет 5 назад нормальным. Может, в том числе из-за наивных UML подходов?

Сейчас вот Agile гораздо больше практикуется и успешен. А они с дорогим UML (который можно сматчить разве что только с SDLC/waterfall), совсем несовместимы.

Но ниже было не высказывание мной моих фантазий, а вопрос на счёт ваших.

а, так это был вопрос? ну так задайте его так, чтобы я понял

Типа всего ниже сказанного не достаточно?

ниже сказанного

??? WTF «ниже сказанного»

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

можно, но это не практично и финансово не выгодно.

UML???? Вы точно UML ни с чем не путаете, ни с какой методикой проектирования?

Срок эксплуатации ПО несколько лет, срок эсклуатации чего-то вещественного десятилетия.

двойной фейл

> 1. что значит рассчитать программу?

2. и почему нельзя?

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

а мост типа можно, да?

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

не буду же я называть фамилии наивных мальчиков только что из курсов или универов, пытавшихся претворить в жизнь рекламки и промывание мозгов от больших корпораций, не будем называть каких, которых закидали ссаными тряпками сильные девелоперы, и сделали потом работающую успешную систему. Или незакидали, и потом проект погряз в неэффективности, склоках, потом его так и замяли. Кажется, от 50 до 75% заваленных проектов считалось лет 5 назад нормальным.

не, я всё понимаю, но причём тут UML???

Может, в том числе из-за наивных UML подходов?

что есть UML-подход?

Сейчас вот Agile гораздо больше практикуется и успешен.

и там применяются UML-диаграммы, причём опытные методисты рекомендуют использовать UML, *SURPRISE*

А они с дорогим UML (который можно сматчить разве что только с SDLC/waterfall), совсем несовместимы.

почему несовместимы то? это у Вас уже просто загон и полное 4.2 вкупе с непонимание того, что есть Agile

> UML???? Вы точно UML ни с чем не путаете, ни с какой методикой проектирования?

UML - это нотации к бучевскому методу проектирования. UML, Бутч, большой голубой и тяжёлый (не agile) метод проектирования, будь то SDLC, или waterfall (любой, где предполагается, что всё известно наперёд) - не разделимы. Вы что, этого не знаете??

а, так это был вопрос? ну так задайте его так, чтобы я понял

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

если же мы про вышесказанное - да,

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

ибо давайте рассуждать о вкусе устриц с теми кто их ел во французском ресторане,

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

Т.е. вы хотите услышать мнение фанатика UML, приросшего к нему душой и телом, о том что UML плох?

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

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

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

это релевантно относительно любых более или менее серьёзные проектов

Или объёмы данных вырасти, или что-то поменяться, но почти всегда поменяются требования. Этого достаточно для того, чтобы рассчитать вперёд было нельзя (не все неизвестные известны).

не, я всё понимаю, спрошу ещё раз - причём тут UML?

и да, то что многие вещи неизвестны на этапе проектирования, если есть неопределённость по нагрузкам - это ещё не значит, что проектирование как класс надо отменить (и это также не значит, что проектирование делается раз и навсегда на всю систему), а всех аналитиков и архитекторов ссаной тряпкой разогнать

>>Разве можно подобную систему рассчитать, не зная даже будущей нагрузки?

а мост типа можно, да?

Мост можно.

подумайте немного, и Вы, уверен, поймёте почему сморозили глупость :)

> не, я всё понимаю, но причём тут UML???

Потому что UML и успех проекта не просто не коррелируют положительно в моём опыте, но и противоположны.

что есть UML-подход?

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

и там применяются UML-диаграммы, причём опытные методисты рекомендуют использовать UML, *SURPRISE*

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

> UML???? Вы точно UML ни с чем не путаете, ни с какой методикой проектирования?

UML - это нотации к бучевскому методу проектирования

4.2 так я и знал, что проблема в неверном понимании

UML (англ. Unified Modeling Language — унифицированный язык моделирования) — язык графического описания для объектного моделирования в области разработки программного обеспечения. UML является языком широкого профиля, это открытый стандарт, использующий графические обозначения для создания абстрактной модели системы, называемой UML-моделью. UML был создан для определения, визуализации, проектирования и документирования в основном программных систем.

и где тут «метод бутча»?

> почему несовместимы то? это у Вас уже просто загон и полное 4.2 вкупе с непонимание того, что есть Agile

вы и этого не знаете... ключевая разница: Agile требует на каждом этапе _работающей_ системы, даже после недели девелопмента. Т.е. цикл мал, и всегда что-то имеем работающее в руках. waterfall, SDLC же предполагают что все требования выясняются _до_ начала девелопмента. Там вначале сбор требований, потом дизайн итд. В конце - тестинг. Это причина супер-дорогих проектов, когда распиливались огромные деньги до начала девелопмента (годами), а после начала - выяснялось, что либо что-то поменялось, либо - что-то неучтено итд.

Прослушайте курс софтваре-инджениринга.

считают что только они знают всё об устрицах

сколько передёргиваний в такой короткой фразе

1) не считают
2) не только они
3) не всё
4) не об устрицах, а об их вкусе

и уж точно, с тем кто их не ел бесполезно говорить о том какие они на вкус

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

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

Потому что UML и успех проекта не просто не коррелируют положительно в моём опыте, но и противоположны.

дорогой мой, это всё оттого, что слово UML у Вас в голове замещается на некую методологию проектирования, а это ошибка, но Вам она, по всей видимости, нравится

>>Мост можно.

подумайте немного, и Вы, уверен, поймёте почему сморозили глупость :)

что не так? Для моста нагрузка известна. Он проектируется под совершенно конкретную нагрузку, и конкретные материалы. Неизвестны только будущие бури или другие сюрпризы (не типичные для данной местности) природы, а рассчётный траффик строго регламентируется.

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

> что есть UML-подход?

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

уфф, ну поехали

1. нет такого термина UML-подход
2. не «ибмовский подход», а Rational Unified Process
3. как показали мои продолжительные дискуссии (в т.ч. здесь, на ЛОРе) с людьми, занимающимся проектированием на самом деле аттрактор - один, но к нему подходят с разных сторон, и, в неумелых руках, что agile, что водопадный (к примеру) подход - это фейл
4. этот подход работает, не надо ляля, но он требует весьма выской квалификации и инженеров и архитекторов - это его минус, да

> дорогой мой, это всё оттого, что слово UML у Вас в голове замещается на некую методологию проектирования, а это ошибка, но Вам она, по всей видимости, нравится

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

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

сколько передёргиваний в такой короткой фразе

нет же там никаких передёргиваний, я просто сформулировал итог.

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

молодец, хорошая шутка. Между понятием 'быть специалистов в Х' и 'не видеть ничего кроме X' (так сказать, скатиться в чёрно-белый мир) большая пропасть. Так вот,

и уж точно, с тем кто их не ел бесполезно говорить о том какие они на вкус

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

вы и этого не знаете... ключевая разница: Agile требует

бугага, и это человек что-то указывать не стесняется, Agile ничего не требует - только рекомендует, именно поэтому он Agile, а не Hardhead какой-нибудь

Agile требует на каждом этапе _работающей_ системы, даже после недели девелопмента. Т.е. цикл мал, и всегда что-то имеем работающее в руках.

и уж будем точны в терминологии, то о чём Вы говорите - итеративный подход к разработке (да, рекомендуется Agile)

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

1. эта методика работает
2. для того чтобы её безфейлово применять нужна более высокая квалификация и куда больше опыта, нежели в случае с Agile
3. так что проблема не в методологии скорее, а в человеческом ресурсе
4. причин фейлов, как правило, очень много, и методологические косяки - это вовсе не то зло, с которого всё начинается

>>Мост можно.

подумайте немного, и Вы, уверен, поймёте почему сморозили глупость :)

что не так? Для моста нагрузка известна.

не так читаете :)

>>Разве можно подобную систему рассчитать, не зная даже будущей нагрузки?

а мост типа можно, да?

Мост можно.

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

ну и для софта то же самое

А в случае моста бетон, металл - всё оттестировано давно.

кодировки и слова английского алфавита тоже оттестированы давно

> 1. нет такого термина UML-подход

2. не «ибмовский подход», а Rational Unified Process

Да, RUP (не касаясь его лет десять как - я уже забыл аббревиатуру ИБМовского подхода). Но изменение названия - сути не меняет. А RUP и UML неразделимы. Первый - нотация для второго.

3. как показали мои продолжительные дискуссии (в т.ч. здесь, на ЛОРе) с людьми, занимающимся проектированием на самом деле аттрактор - один, но к нему подходят с разных сторон, и, в неумелых руках, что agile, что водопадный (к примеру) подход - это фейл

неверно. agile несовместим с неумелыми руками. Не работает эту неделю, не работает следующую - и следующую итерацию разработчик будет заменён на другого. У которого умелые руки. И это произойдёт очень скоро. В отличие от распильных «тяжёлых» методологий, где можно «пилить» годами.

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

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

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

для этого существует нагрузочное тестирование, стресс-тестирование и т.д.

Язык диаграмм досозданный под конкретную методологию - для меня неразделим с этой методологией.

это Ваш персональный фейл

Это Вы не так читаете.

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

А RUP и UML неразделимы.

конечно оптилить RUP от UML трудно, но UML вполне самодостаточен :)

agile несовместим с неумелыми руками. Не работает эту неделю, не работает следующую - и следующую итерацию разработчик будет заменён на другого. У которого умелые руки. И это произойдёт очень скоро. В отличие от распильных «тяжёлых» методологий, где можно «пилить» годами.

нет, Вы не правы, описанная Вами ситуация во-первых сильно зависит от руководства, а во-вторых на agile точно так же можно запиливать бабло годами, сдавая годные компоненты каждую итерацию, но не приблизившись к завершению итоговой системы и на 10%

Это Вы не так читаете.

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

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

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

Поведение сложных систем вообще трудно предсказуемо.

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

> для этого существует нагрузочное тестирование, стресс-тестирование и т.д.

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

Во-вторых, на что тестировать? Протестируете сегодня, но Вы же не знаете ещё многих параметров. Вы не знаете будущих требований. Придёт бухг^Wбизнесаналист в следующем финансовом году (или через 3 месяца), и скажет: принят такой-то закон, надо считать по-другому, и ваши предположения относительно наилучшего дизайна рушаться, и боттленки возникают там, где их не было. Это в лучшем случае. А в худжем - не сможете поменять старый код (если тот программист не предвидел различные повороты судьбы из астрала). Всё может полететь в любой момент (это правда зависит от проектов). Разумеется, ваши UML-ы- на помойку тут же. Как правило поворотов будет много уже в процессе дизайна. Никто в нашей индустрии наперёд ничего не знает, как в мостах.

> нет, Вы не правы, описанная Вами ситуация во-первых сильно зависит от руководства, а во-вторых на agile точно так же можно запиливать бабло годами, сдавая годные компоненты каждую итерацию, но не приблизившись к завершению итоговой системы и на 10%

А, Вы про контроль клиентом/шарехолдером... Так это из другой оперы. В не-agile вообще контроль не возможен и клиент увидит впервые работающую систему только через год(а), а до этого у него никакого контроля нет, кроме «бла-бла-бла» отчитывающихся менагеров. Ему нужны рычаги контроля. Только agile даёт эти рычаги.

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

Может потому, что как и другие конторы, работает итеративным, эволюционным методом, читай agile? (вспомним gmail, который выпустили баговый, с дырами, но потом постепенно, выправляли огрехи, переделывали) а не пилит, создавая диаграммы и документацию годами, а потом оп-па (иthвините муthики, не полутилось, тормозит, лочит, мы не хотели, и вообще за годы всё поменялось и компанию купили).

Вы знаете что гугл использует RUP с UMLем?

> О UML как дополнительном средстве документирования для будущих поколений после имплементации и тестирования (т.е. после окончания разработки) - уже говорилось.

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

код копируется и так (в отличие от моста)

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

А через 10 лет скорее всего вообще не понадобится, так как придут вообще другие технологии. Т.е. некому будет вообще читать, и программу перепишут с нуля

А скорее, программу будут понемногу переписывать все эти 10 лет, и переписывание с нуля может не понадобиться. А вот документация понадобится точно.

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

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

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

Ты мои посты читал? UML как пост-документация - приемлемо, в отдельных случаях. Как дополнение к коду.

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

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

А чем тестируют load в искусственных условиях сегодня? (В последний раз я пользовался самописными шеллскриптами а до этого лодраннером - для стресс-тестов. Да, я не тестер. И предполагаю, что за годы могло что-то поменяться. Последние 8 лет я не в вебе)

вопрос не в инструменте, а в его применении. тем же jmeter'ом можно настрогать кучу бесполезных тестов, а можно покрыть 99% возможных ситуаций. и там, где пишется highload тесты делаются за совесть.