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

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

Когда-то специально привезенные заказчиком из САСШ тренеры по Agile/scrum нам говорили, что следует смещать приоритеты от документации к работающему коду и хорошей комуникации внутри команды. И оно пока что довольно-таки неплохо работает.

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

Необходимая документация, без которого никуда - по-любому код. И дебаггер. Если мне дают класс-диаграммы на тысячи квадратиков - они мне полюбому не интересны и только запутывают. Модули и диаграммы состояний интересны, но это не к UMLю. Гораздо полезнее выцепить оригинального девелопера и чтобы он посидел и рассказал в своих терминах, а не сунул реквест-респонзы HTTP-протокола для отписки, который я и так знаю. Т.е. даже ту пост-документацию что я видел - делали для отписки. А вот указать - где искать и что менять - этому UML всё равно не поможет.

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

Ты мои посты читал?

Да. Но вот приходится уточнять.

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

Вопрос как раз о том, что это за «отдельные случаи», и чем они отличаются от общего случая.

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

То есть тебя не устраивает именно нотация? Насколько я понимаю, все диаграммы, которые ты рисуешь, есть в UML.

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

Необходимая документация, без которого никуда - по-любому код.

Кхм. Да, код необходим, с этим не поспоришь. Но он нихрена не документация. Восстанавливать по коду алгоритм сигнальной обработки - это удовольствие строго на любителя.

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

Воот. Но код - это как раз такая диаграмма из тысячи квадратиков.

Модули и диаграммы состояний интересны

То есть ты хочешь сказать, что нужно знать уровень, на котором остановиться?

но это не к UMLю.

Почему?

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

Вы опять предполагаете (как и ораторы выше) - что возможные ситуации вам известны заранее. А народ ломанётся пользоваться какой-то фишкой, или натолкнётся на какую-то проблему и будет тупо рефрешить какую-нибудь первую страницу, а там что-то будет на ней завязано итд, о чём вы и предполагать то не будете. Или бизнесаналист сам не знает кое-каких результатов обсчёта, и сколько это будет идти. Писал один товарищ один калькулятор, писал правильно, на SQL, всё красиво, а результат обсчёта оказался сутки, пошло в мусорную корзину. А другой то же самое реализовал в виде пайплайна (алгоритмически и императивно, колдуя с данными) и получилось за час, прошло (большие данные). Аналист ничего не мог сказать наперёд так как ихние аксессы и тесты нельзя экстраполировать на реальные объёмы. А реальные объёмы можно протестировать только имея все джойны. Т.е. когда прога будет написана. Где тут место UMLю? (это один пример)

> Когда-то специально привезенные заказчиком из САСШ тренеры по Agile/scrum нам говорили, что следует смещать приоритеты от документации к работающему коду и хорошей комуникации внутри команды. И оно пока что довольно-таки неплохо работает.

правильно говорили

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

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

> Вопрос как раз о том, что это за «отдельные случаи», и чем они отличаются от общего случая.

В моём случае - только когда менагеры требуют. Чтобы бумага отлежалась, «связанное CO2», так сказать на годы. Думаю, должны быть сферические кони где-нибудь, где эти кони, вернее правильно сгенерённые от кода диаграммы кем-то будут оценены (надо же всё руками по-любому удалять или рисовать только нужное, а не тысячи сгенерённых квадратиков, но с другой стороны - если всё равно руками - то почему не нарисовать не в ограниченном контексте UMLя, а картинки и выбор самого главного самим девелопером?)

То есть тебя не устраивает именно нотация? Насколько я понимаю, все диаграммы, которые ты рисуешь, есть в UML.

Это как с религией. Ну не нужна мне религия для добродетели, для того чтобы не убивать итд! И нет всех диаграмм, как я сказал. UMLных диаграмм, когда я в последний раз на них смотрел - всего 7 или немногим больше разных. Я и другие черчу. Любую картинку, которая имеет смысл.

> если всё равно руками

Как и любая документация :)

то почему не нарисовать не в ограниченном контексте UMLя, а картинки и выбор самого главного самим девелопером?

Чтобы не придумывать нотацию, которая понятна только автору.

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

> Чтобы не придумывать нотацию, которая понятна только автору.

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

>Те пути я могу определить миллионом других способов и нотаций, да хоть на английском или русском.

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

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

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

Надо идти, думаю позиция моя ясна.

Извините, надо идти.

Думаю найдутся и другие ораторы.

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

Это смотря как написать. А я бы навалял за генерацию кода и тысячи квадратиков «для галочки», что я видел, в документации. Интересно, как они, эти квадратики или нерсчищенные диаграммы с тысячями нодов - помогут тестеру.

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

Бюрократ? На всё нужен стандарт - даже если стандарт - дерьмо? Меня как-то прекрасно понимают те, с кем я работаю и без UMLей (последние 10 лет). И менагеры ко мне с ним давно не пристают. И кастомные диаграммы работают.

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

не мог не ответить, но сейчас точно отваливаю

> Кхм. Да, код необходим, с этим не поспоришь. Но он нихрена не документация. Восстанавливать по коду алгоритм сигнальной обработки - это удовольствие строго на любителя.

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

я понимаю UML как (тут аналогия) допустим 6 проекций (вдоль координатных осей); в то же время чтобы дать хорошее представление об устройстве требуется сложный разрез — т.е. правильная *точка зрения* изначального разработчика

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

позиция сибериана мне кажется тут похожа

кстати насчет критики UML — она вроде как идет в основном со стороны agile, XP, ... и примерно сводится к тем аргументам, что привели к сжиганию александрийской библиотеки — «то, что не выражено простыми средствами языка в коде (например отношение 1:М) и хранится отдельно — всегда устаревшее и неверное, а то, что выражено простыми средствами языка в коде, может быть получено тулзой из кода и его нет смысла хранить отдельно»

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

зайди потом еще, тема интересная

отличный подход: «это не UML, это тоже не UML, про это я ничего не знаю, а вот это автогенерируемое говно - UML, поэтому UML говно». склонен согласиться с shty по поводу вашего уровня понимания UML

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

>> Кхм. Да, код необходим, с этим не поспоришь. Но он нихрена не документация. Восстанавливать по коду алгоритм сигнальной обработки - это удовольствие строго на любителя.

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

Небольшая подсказка - речь о том, что «код как документация» в лучшем случае неэффективен.

кстати насчет критики UML — она вроде как идет в основном со стороны agile, XP, ... и примерно сводится к тем аргументам, что привели к сжиганию александрийской библиотеки — «то, что не выражено простыми средствами языка в коде (например отношение 1:М)

Всё это сводится к старому афоризму „серебряной пули не существует“. UML - тоже не сербряная пуля, но может быть полезен.

> Всё это сводится к старому афоризму «серебряной пули не существует». UML - тоже не сербряная пуля, но может быть полезен.

не сводится

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

З.Ы. кстати, игнатик привел полезную цитату, которую он нихрена сам не понял, а мне разъяснять было ему лень; она здесь вроде к месту

Architecture is a set of structuring principles that enables a system to be comprised of a set of simpler systems each with its own local context that is independent of but not inconsistent with the context of the larger system as a whole.

> Восстанавливать по коду алгоритм сигнальной обработки - это удовольствие строго на любителя.

еще один момент — очень вряд ли этот алгоритм будет правиться *в коде* и разойдется с теоретическим, так что тут документация не несет лишней работы

З.Ы. а еще в нормальных, а не быдлоязыках, запись алгоритма (+ хинты трансляции) была бы кодом

>> небольшая подсказка — а будет ли этот алгоритм понятно выглядеть в UML?

Небольшая подсказка - речь о том, что «код как документация» в лучшем случае неэффективен.

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

>> Восстанавливать по коду алгоритм сигнальной обработки - это удовольствие строго на любителя.

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

Он будет, поверь %)

а еще в нормальных, а не быдлоязыках, запись алгоритма (+ хинты трансляции) была бы кодом

Вот когда у нас в распоряжении будут «нормальные» языки, тогда и поговорим.

и код, и UML тут одинаково не подходят на роль документации

Твое мнение понятно, и не совпадает с моим.

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

Еще раз: UML - это разновидность документации; документация предназначена для человека, а не для машины.

> Небольшая подсказка - речь о том, что «код как документация» в лучшем случае неэффективен.

... и в этом случае нужна именно текстовая документация

ну скажем «у нас тут сервер в виде конечного автомата» или «у нас тут многопоточный сервер»

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

Он будет, поверь %)

не поверю

либо там будут оптимизации, не затрагивающие алгоритм в том виде, что изложен в документации, либо алгоритм будет переписан *сначала* в документации, а только потом в коде

> Твое мнение понятно

будем надеяться, хотя мне кажется что нет

> ... и в этом случае нужна именно текстовая документация

ну скажем «у нас тут сервер в виде конечного автомата»

Ну, ну, и как ты изобразишь граф переходов? Текстом?

или «у нас тут многопоточный сервер»

Бгг.

Он будет, поверь %)

не поверю

Тоже бгг.

>> ну скажем «у нас тут сервер в виде конечного автомата»

Ну, ну, и как ты изобразишь граф переходов? Текстом?

граф переходов надо уже изображать кодом, и он будет вполне понятен; а кроме того, его можно будет тулзой (может даже простой, но специально написанной для этого) восстановить из кода¹

а вот как ты изобразишь «у нас тут сервер в виде конечного автомата» в в виде UML?

начнешь рисовать этот самый автомат? так это куча не относящегося к делу шума, в документации должны быть *принципы*, типа «у нас тут сервер в виде конечного автомата»

_____________________________________________________________

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

> граф переходов надо уже изображать кодом, и он будет вполне понятен

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

а вот как ты изобразишь «у нас тут сервер в виде конечного автомата» в в виде UML?

начнешь рисовать этот самый автомат?

Ага.

к это куча не относящегося к делу шума

Не рисуй шум. В коде «не относящегося к делу шума» всяко больше.

в документации должны быть *принципы*

(издевательским тоном) Да просто ссылка на Open Courseware.

Продолжая тему аналогий

Чертёж не является конечным продуктом: конечный продукт получается в результате конструирования по чертежам. Точно так же, как программный код конструируется по UML-диаграммам.

Должно быть верно и обратное: по конечному продукту можно воссоздать чертёж методом реверс-инженеринга. А вот по исходному коду не всегда можно составить UML-диаграмму, в силу ограниченности UML. Это выяснили в недавнем треде о применимости UML к Common Lisp'у.

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

Скажите, почему принято говорить, что UML — это маркетинговый баззворд и ненужен

Потому что в экстремальном программировании основной мотив, описывающий постоянно меняющееся ТЗ к коду — это система тестирования, а не документирования.

Диаграммы UML на стадии проектирования безусловно важны. Но когда начинают писать тесты вместе с рабочим кодом, документация UML просто не упевает учесть все нюансы реализации. В итоге проверенный тестами код пишется быстрее, чем документируется, а часть диаграмм UML (например, диаграмма взаимодействий) оказывается не соответствующей коду — надо перерисовывать. А зачем перерисовывать, если модульные и функциональные тесты подтверждают правильность исполнения кода и показывают место ошибки, когда вносятся изменения (и в ТЗ) и что-то ломается?

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

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

ну так с самого начала надо было честно сказать «для моего ассемблера нет нормального компилятора и/или ЯП, потому и поглядываю на UML»

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

ну так с самого начала надо было честно сказать «для моего ассемблера нет нормального компилятора и/или ЯП, потому и поглядываю на UML»

А не нужно предполагать наличие «нормального компилятора и/или ЯП». Вообще, делай поменьше предположений. И кстати, конечный автомат на Си тоже не особо нагляден (если Си не «нормальный ЯП», озвучь список нормальных).

> А не нужно предполагать наличие «нормального компилятора и/или ЯП». Вообще, делай поменьше предположений. И кстати, конечный автомат на Си тоже не особо нагляден

нет, это *тебе* надо озвучивать свои нестандартные условия — отсутствие компилятора с++ в целевой ассемблер (кстати, название ассемблера не секретно?)

но даже и в таких условиях свои костыли на основе перла никто не отменял

(если Си не «нормальный ЯП», озвучь список нормальных).

си точно не нормальный, с++ с вставками, нагенеренными перловыми скриптами, еще как-то можно использовать, но все равно не нормальный

g++ c поддержкой хвостовой рекурсии и еще каких-то расширений + перл для препроцессинга я бы назвал «нормальным» (но только по нынешним временам)

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

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

>Доказательства по аналогии такие убедительные.
Тоже самое можно сказать насчет самого поста.

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

Мсье был жестоко обманут. Устриц едят сырыми.

Мсье был жестоко обманут. Устриц едят сырыми.

___порядком испортившимися___

PS не люблю морепродукты

Вы наивны.

зато Вы такой опытный, жаль кое где проскальзываете

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

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

Во-вторых, на что тестировать?

на соответствие требованиям, так это сложно :)

Вы не знаете будущих требований.

никто не знает, ни в одной области, поверьте

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

Разумеется, ваши UML-ы- на помойку тут же.

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

Никто в нашей индустрии наперёд ничего не знает, как в мостах.

давайте говорить за себя, ок?

А, Вы про контроль клиентом/шарехолдером...

нет

В не-agile вообще контроль не возможен и клиент увидит впервые работающую систему только через год(а) [..] Только agile даёт эти рычаги.

снова ошибка, и снова слепой фанатизм

Может потому, что как и другие конторы, работает итеративным, эволюционным методом,

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

а важен только результат, всё просто

читай agile?

не обязательно

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

это где-то прописано как обязательное условие?

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

Когда-то специально привезенные заказчиком из САСШ тренеры по Agile/scrum нам говорили, что следует смещать приоритеты от документации к работающему коду и хорошей комуникации внутри команды. И оно пока что довольно-таки неплохо работает.

как это противоречит тому что я сказал? :)

ораздо полезнее выцепить оригинального девелопера и чтобы он посидел и рассказал в своих терминах

ахаха, ты такой наивный :)

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

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

и это только одна из возможных ситуаций

ту пост-документацию что я видел - делали для отписки

говорю же, у тебя нет положительного опыта в применении данных практик, и именно поэтому они тебе кажутся странными и неправильными

> это *тебе* надо озвучивать свои нестандартные условия — отсутствие компилятора с++ в целевой ассемблер

У меня был компилятор Си++. Но его нельзя было использовать - неэффективный код.

си точно не нормальный, с++ с вставками, нагенеренными перловыми скриптами, еще как-то можно использовать

Таки это тебе нужно озвучивать свои специфические понятия.

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

Ради двух автоматов? У тебя DSL головного мозга.

и это будет лучше UML

UML (в рамках данной дискуссии) - для другого.

как это противоречит тому что я сказал? :)

Ты сказал

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

Так вот нам рекомендовали забивать на доки в свете наличия работающего кода в конце каждой интерации продукта и организованого вербального knowledge sharing в команде.

требуется сложный разрез — т.е. правильная *точка зрения* изначального разработчика

и как Вы её консервировать, эту точку зрения намерены?

кстати насчет критики UML — она вроде как идет в основном со стороны agile, XP

1. это не так
2. XP, это одна из практик Agile, я бы не стал упоминать их в перечислении

> Так вот нам рекомендовали забивать на доки в свете наличия работающего кода в конце каждой интерации продукта и организованого вербального knowledge sharing в команде.

А у вас разработка вообще когда-нибудь заканчивается? Если нет, то всё понятно. Если да, то что происходит по окончании - код выбрасывается, или поступает в эксплуатацию, а команда переходит на другой проект:

> Всё это сводится к старому афоризму «серебряной пули не существует».

не сводится

то есть серебрянная пуля существует, или что Вы хотели этим сказать?

>UML - тоже не сербряная пуля, но может быть полезен.

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

мне интересно, зачем Вы пытаетесь пересекать множество фич UML и языка? UML язык годный для описания концепций, вот нафига его тащить на уровень реализации?