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

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

AF>>Они ведь оба не понимают, что позиция "UML бесполезен" априори проигрывает позиции, "UML можно применить так то и так то с такими то результатами". Первая сужает доступные возможности — вторая расширяет
M>Они прекрасно понимают, что позиция "UML бесполезен" априори проигрывает позиции, "UML можно применить так то и так то с такими то результатами и нулевыми затратами ресурсов".
M>А вот почему вы не понимаете, что затраты ресурсов на внедрение UML-я и работу с ним вовсе не нулевые, и в подавляющем большинстве случаев себя не окупают, для меня не совсем ясно. Тем более, что именно Вы, по Вашему же признанию, реально с UML не работали, но тем не менее почему-то пытаетесь доказать, что связываться с ним имеет смысл...
Это доказывает лишь то, что вы невнимательно читали мои посты. Я как раз-таки неоднократно утверждал, что UML технология достаточно дорогая, особенно благодаря тому, что это на самостоятельная технология, а часть процесса разработки и имеет смысл там, где она себя окупает.
Вам не кажется что тем более важно знать о сфере применимости дорогой технологии, что бы применять её по делу? Вот именно о сфере применимости и щла речь... Вместо этого разговор свёлся к доказательству того, что UML не нужен вообще. С чем я не согласен, так как видел сферы, где он не только применим, но и эффективен.

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

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

Это верно ... для системного архитектора это абсолютно верно, что он не должен мыслить в терминах кода ... для проектировщика/программного архитектора -- на 80% верно (моя личная оценка).. более того, при наличии квалификации -- это запросто. Для тогд чтобы спроектировать domain model мне ну никак не нужно знать особенностей языка ... ей-богу!

B>>Внятный код -- это признак внятных мыслей ... кто ясно мыслит, тот ясно излагает ... значит может и ясно в UML изложить а не только в коде ... Язык это только способ изложения мыслей.
M>Все верно, но зачем для изложения мысле вводить еще один язык?

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

B>> Модели на UML это essentials ... а в коде много подробностей. Есть опасность изучая только код, за деревьями не увидеть леса ... А для начала хотелось бы на лес взглянуть а потом на интересующие меня деревья .
M>Опять-таки все замечательно, но вводить дополнительную сущность, для другого уровня абстракции на мой взгляд не верный подход. Лучше потратить эти усилия на то что бы в коде видеть и лес и деревья.

ОК ... ну не знаю я Smalltalk-а ... как мне понять суть системы на нем написанной??? А при наличии внятной модели на UML в сочетании с требованиями, да еще оттрассированной дизайном на требования -- мне все станет понятно ...

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


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

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

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

AF>>И сколько тут лишнего, по сравнению с диаграммой?

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

M>>>Я не против текстового описания. Более того, одно из лучших описаний кода, которое я видел, есть описание TeX (литературное программирование). Увы, эта методология не получила должного распространения. Но провести параллель между русским языком и UML я не могу, ввиду недостаточности UML.
AF>>А кто говорит о голых диаграммах? Предполагается использование этих диаграмм вместе с текстом, а не вместо текста.

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

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

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


AF>>Упаси гейтс поручать крупный гетерогенный проект архитектору, которому всё нужно понимать на уровне исходного кода...
M>Вот так и получаются проекты, в которых архитектор в UML наваял одно, разработчики посмотрели на это квадратными глазами и пошли делать как считают нужным, лишь бы работало. После того как проект сдан, поддерживать это выпадает третим людям, потому как архитектора выгнали за некомпетентность, а разработчиков за самоуправство.
M>Вообщем, счастья вам, UML в помощ.
UML то тут причём?
Берём архитектора, который всё рисует на бумажке, разработчиков с квадратными глазами, которые не фига не понимают, но вовремя кивают, и получаем тот же самый результат — с теми же последствиями. И причём тут UML?

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

AF>Там мало людей и им ничего не нужно обяснять?
Я уже устал рассказывать, что всем одно и то же объяснять не надо, не стоит такой проблемы, объяснять большей проект большему количеству людей.

AF> А если к моменту передачи кода Outsourcer'ам, например, написано только 10% кода?
Передать 10% кода.

AF> А если потребуется сменить технологию реализации?
Сменить технологию, в чем проблема-то?

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

B> Для тогд чтобы спроектировать domain model мне ну никак не нужно знать особенностей языка ... ей-богу!
Значит толку ноль от такой Domain Model

B>1. Чтобы сначала увидеть лес, а потом интересующие меня деревья.
Ну не нужен для этого еще один язык.

B>ОК ... ну не знаю я Smalltalk-а ... как мне понять суть системы на нем написанной???
Значит надо взять архитектора, который знает SmallTalk.

B> А при наличии внятной модели на UML в сочетании с требованиями, да еще оттрассированной дизайном на требования -- мне все станет понятно ...
И что толку от такого понимания? Что с этим пониманием делать-то дальше?

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

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

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

AF> Вместо этого разговор свёлся к доказательству того, что UML не нужен вообще.
Ну не я же его туда свел...

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

M>А что говорит здравый смысл в ситуации когда графическое представление не синхронизировано с тестовым?
M>И в ситуации, когда графическое представление понять не менее сложно чем текстовое?

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

M>Я полагаю, что нет такой информации о проекте, которая не выразима исходным кодом.

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

PS: Жаль, что конструктивный диалог фактически перешел в перепалку. Тема то была любопытной ...

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

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

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

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

AF>>>Ну а если в коде реализована не вся необходимая функциональность?

M>>Тут возможны варианты

AF>Какие? Мистически домыслить что имелось в виду?
AF>Очевидно, что без описания модели или иного источника информации о том, что нужно делать — вариантов никаких.

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

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


AF> UML то тут причём?
При том, что не зная языка разработки архитектору остается только в UML-е модельки ваять.

AF> Берём архитектора, который всё рисует на бумажке, разработчиков с квадратными глазами, которые не фига не понимают, но вовремя кивают, и получаем тот же самый результат — с теми же последствиями.
Тот же самый результат не получим, так как архитектор, разбираясь в исходниках, сразу поймет, что ему "дуру гонят" и объяснит так, чтобы поняли.

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

M>Значит надо взять архитектора, который знает SmallTalk.

Ну вот, скажем, взяли. Он, значит, посмотрел исходники нашей SmallTalk-системы и честно говорит: "Архитектура этой системы не отвечает вашим текущим потребностям — ее всю нужно переделывать". И спрашивается зачем мы его долго искали и нанимали? Писать систему на Java мы могли и с предыдущим (поспешно уволенным за незнание SmallTalk) архитектором. А этот Java не знает.

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

AR>Здравый смысл подсказывает, что такую документацию можно выкинуть и смело о ней забыть, а систему, которая этой документацией описывается придется переписывать заново.
В случае применения UML-я это 95% проектов, что нам далее говорит здравый смысл по поводу применения UML-я для документации?

AR>Вам просто не попадались действительно талантливо и профессионально сделанные книги (причем не важно на какую тему).


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

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

AR>Ну вот, скажем, взяли. Он, значит, посмотрел исходники нашей SmallTalk-системы и честно говорит: "Архитектура этой системы не отвечает вашим текущим потребностям — ее всю нужно переделывать". И спрашивается зачем мы его долго искали и нанимали? Писать систему на Java мы могли и с предыдущим (поспешно уволенным за незнание SmallTalk) архитектором. А этот Java не знает.
А при чем тут Java? Если архитектору поставлена задача рефакторить, а не переписывать заново, значит он будет рефакторить или вы не того архитектора нашли.

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

AR>>Здравый смысл подсказывает, что такую документацию можно выкинуть и смело о ней забыть, а систему, которая этой документацией описывается придется переписывать заново.
M>В случае применения UML-я это 95% проектов, что нам далее говорит здравый смысл по поводу применения UML-я для документации?

Ну а с остальными то 5% что делать?
Примеры неправильного использования не могут служить доказательством того, что UML вообще нельзя использовать.
По моему личному мнению массовое некорректное использование UML обусловлено попыткой использовать его в маленьких проектах, а также неудачами при применении UML именно в творческом процессе при первичном формировании архитектуры системы. Нестыковка UML-моделей и исходного кода является серьезной проблемой, пути преодоления которой следует искать. Отказываться же от самой идеи стандартизации средств визуального представления статической и динамической архитектуры/процессов программных систем напоровшись на проблему, будет шагом назад.

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

AR>>Ну вот, скажем, взяли. Он, значит, посмотрел исходники нашей SmallTalk-системы и честно говорит: "Архитектура этой системы не отвечает вашим текущим потребностям — ее всю нужно переделывать". И спрашивается зачем мы его долго искали и нанимали? Писать систему на Java мы могли и с предыдущим (поспешно уволенным за незнание SmallTalk) архитектором. А этот Java не знает.
M>А при чем тут Java? Если архитектору поставлена задача рефакторить, а не переписывать заново, значит он будет рефакторить или вы не того архитектора нашли.

А кто и на основании какой информации (в чем представленной) решает — рефакторить или писать заново? Или это директор просто должен к гадалке — толковательнице снов обращаться?

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

AR>А кто и на основании какой информации (в чем представленной) решает — рефакторить или писать заново? Или это директор просто должен к гадалке — толковательнице снов обращаться?
Ну так Вы решите сначала, что Вам с системой делать надо, а потом ставьте задачу архитектору. Или пусть он решает что с системой делать надо. От языка описание архитектуры здесь ничего не зависит.

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

AR>Ну а с остальными то 5% что делать?
А в остальных 5%, либо UML используется непосредственно для разработки. И нет никакой необходимости вводить новую сущность исключительно для документации, либо документация чисто формальный документ, который вовсе не обязан соответствовать действительности.
Такое впечатление, что Вы пытаетесь найти UML-ю ну хоть какое-то применение.
Еще раз повторюсь. Я могу понять тех, кто пытается использовать UML в процессе разработки, но использовать UML исключительно для документации — напрасная трата времени, сил и денег.

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

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

AF>>Я как раз-таки неоднократно утверждал, что UML технология достаточно дорогая, особенно благодаря тому, что это на самостоятельная технология, а часть процесса разработки и имеет смысл там, где она себя окупает.
M>Так вот примеров где она себя окупает, за весь долгий спор, я нашел только два. Один в достаточно узкой области, а другой вообще не имеет отношения к разработке.

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

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

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

AF>>Я как раз-таки неоднократно утверждал, что UML технология достаточно дорогая, особенно благодаря тому, что это на самостоятельная технология, а часть процесса разработки и имеет смысл там, где она себя окупает.
M>Так вот примеров где она себя окупает, за весь долгий спор, я нашел только два. Один в достаточно узкой области, а другой вообще не имеет отношения к разработке.

Еще один пример существует. Есть так называемый DoDAF (US Department of Defense's Architecture Framework), есть DoDAF profile for UML (мы его, кстати поддерживаем). Так вот сию штуку американские военные и компании на них работающие (e.g. Lockhead Martin Corp.) активно используют.
Но деталей того, как конкретно они это используют я не знаю. Подразделения девелоперов сидят в зданиях, отрезанных от инета напрочь. Никакие примеры реальных моделей оттуда не поступают, а что поступает есть лишь специально сделанные example-ы для иллюстрации багов или желаемой фичи.
Но по поступающим репортам видно, что UML они используют и хотят использовать в будущем. Еще на них ряд университетов работает, которые тоже шлют замечания и предложения по поводу совершенствования UML.


Кстати, в telecom industry можно так же частично включить aerospace industry. Задачи возникают похожие, поэтому UML там используют примерно тем же самым образом, что и в telecom.