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

AF>Берём проект человек на 300-400. Ты уверен что у тебя на всех карандашей, слюней и здоровья хватит?
Еще раз, можешь привести пример проекта, где 300-400 человекам надо объяснять одно и то же?
Конкретная задача ставится десятку людей.

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

AF> Есть, но не одно и тоже, но работают над общей и достаточно крупной задачей.
Над общей задачей работает десяток человек.

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

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

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

_O_> Внедрения UML в нишу SDL-я есть ответ на потребности производства. Народ захотел UML-я, вот софтверные компании и прореагировали.
Сдается мне, что ситуация развивалась примерно так: Потребность в программировании посредством неких визуальных инструментов для ряда задач была довольно давно, и каждый удовлетворял ее по своему. Потом появился UML и на волне энтузиазма, когда казалось, что все недостатки UML-я это лишь вопрос инструментария, всем миром начали создавать впечатляющие по функциональности конструкции для работы с UML-ем. И в какой-то момент оказалось, что эти конструкции великолепно справляются с задачами, для которых ранее предназначались собственноручно написанные поделки, что естественно привело к использованию UML-я для этого класса задач.

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

C>Тогда эти наброски сканируем и рассылаем вместе с объяснениями.
C>Серьезно, очень удобно получается.

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

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

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

AF>>Берём проект человек на 300-400. Ты уверен что у тебя на всех карандашей, слюней и здоровья хватит?
M>Еще раз, можешь привести пример проекта, где 300-400 человекам надо объяснять одно и то же?
M>Конкретная задача ставится десятку людей.

Любимый отцами основателями RUP проект системы управления воздушным движением в Канаде — устроит?

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

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

AF>>Берём проект человек на 300-400. Ты уверен что у тебя на всех карандашей, слюней и здоровья хватит?

M>Ой, я бы первым делом оставил человек 50, я еще лучше 20 Так больше гарантии уложится в сроки

Я бы тоже. Потому нас никогда рулить в крупную фирму и не запустят.

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

_O_>Я видел UML модель, над которой работает порядка 200 человек. Делают они, конечно, не одно и тоже, но работают с одной и той же моделью.
А польза от этого есть? Может им проще было бы работать не с одной моделью, а с двадцатью, на каждую конкретную подзадачу?

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

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

AF>> Есть, но не одно и тоже, но работают над общей и достаточно крупной задачей.
M>Над общей задачей работает десяток человек.

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

AF>>UML в данном случае вовсе не лучший и не обязательный вариант, но система обозначений должна быть единой. Карандаш и слюни этого не обеспечивают
M>Это обеспечивает сам код, очередной раз осмелюсь утверждать, что код не менее, если не более выразителен, нежели UML.
Это смотря для кого.

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

AF>Любимый отцами основателями RUP проект системы управления воздушным движением в Канаде — устроит?
Там что 300-400 человек делали одно и то же, над одной общей моделью? "Не верю"

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

AF>Кому как. Я тоже отнюдь не фанат UML, но как прогматик вижу, что есть места, где он применяется успешно.
А я, как прагматик, вижу, что можно великолепно обходиться и без него..

AF> Их и условия, когда он успешно применяется я и постарался показать.
К сожалению не абсолютно не убедительно. Ни одного реального обоснования его использования я не увидел, только от _Obelisk_ был внятный пример в достаточно узкой области, и то, там UML не сколько инструмент моделирования, колько непосредственно разработки.

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

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

_O_>Я видел UML модель, над которой работает порядка 200 человек. Делают они, конечно, не одно и тоже, но работают с одной и той же моделью.
_O_>Число типов в данной модели превышает 100 000.

А сколько человек использует в проектах .NET Framework, VCL, MFC, ADO? В документации по ним UML диаграмма скорее исключение, чем правило.

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

M>>Ой, я бы первым делом оставил человек 50, я еще лучше 20 Так больше гарантии уложится в сроки

AF>Я бы тоже. Потому нас никогда рулить в крупную фирму и не запустят.

Хорошо, уточнюсь. Код системы разрабатывало бы не больше 20-30 человек. А остальных найдем чем занять. Пусть пишут документацию, учебники, разрабатывают примеры использования, тестируют, ... И даже могут по коду составлять UML-диаграммы, нотолько исключительно для заказчика

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

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

AF>>Любимый отцами основателями RUP проект системы управления воздушным движением в Канаде — устроит?
M>Там что 300-400 человек делали одно и то же, над одной общей моделью? "Не верю"
Это к отцам-основателям...

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

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

AF>>Кому как. Я тоже отнюдь не фанат UML, но как прогматик вижу, что есть места, где он применяется успешно.
M>А я, как прагматик, вижу, что можно великолепно обходиться и без него..
Разве я где то утвержал обратное?

AF>> Их и условия, когда он успешно применяется я и постарался показать.
M>К сожалению не абсолютно не убедительно. Ни одного реального обоснования его использования я не увидел, только от _Obelisk_ был внятный пример в достаточно узкой области, и то, там UML не сколько инструмент моделирования, колько непосредственно разработки.
Но и там можно обходиться без UML
В действительности нет такой области где без UML нельзя было бы обойтись. Я просто привёл примеры того, где он успешно применяется.

AF>> Вы же повторяете то, что и так очевидно, а именно, что UML вовсе не панацея, более того — даже как огранниченный интсрумент — вовсе не лучшее решение.
M>Ну если очевидно, что это не лучшее решение, то зачем его использовать?
Затем же, зачем используются все остальные не лучшие решения... Тем более — что лучшего, чем рисовать на бумажке, вы так и не смогли придумать.

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

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

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

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

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

M>>>Ой, я бы первым делом оставил человек 50, я еще лучше 20 Так больше гарантии уложится в сроки

AF>>Я бы тоже. Потому нас никогда рулить в крупную фирму и не запустят.

M>Хорошо, уточнюсь. Код системы разрабатывало бы не больше 20-30 человек. А остальных найдем чем занять. Пусть пишут документацию, учебники, разрабатывают примеры использования, тестируют, ... И даже могут по коду составлять UML-диаграммы, нотолько исключительно для заказчика

Это далеко не всегда возможно. Простой пример: разработка крупного программно-аппаратного комплекса. В таком комплексе зачастую одни и теже алгоритмы реализуются на различной аппаратуре, причём видов этой аппратуры — 30-40. Система структурируется и каждый уровень должен быть грамотно описан, что бы различные разработчики делали аппаратуру под один и тот же стандарт. Тем более, если часть аппратуры или ПО разрабатываются вовне — в другом городе и тем более стране. Вот и попробуй в таких условиях выделить 20-30 человек, которые всё сделают...

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

N>Чем дальше я сталкиваюсь с проектированием ПО, создании и описании его архитектуры, попытками воссоздать структуру и архитектуру ПО, тем больше для меня становиться очевидным тот факт что UML никуда не годен По крайней мере по моим рассуждениям, он как минимум не удобен, а то и вовсе не информативен в той степени какой хотелось бы...

1. Я однажды уже высказывал тут мысль, что для систем написанных в стиле "спагетти" бесполезно пытаться "восстанавливать" архитектуру или дизайн. Что можно описать с т.з. дизайна, в клиент-серверной системе, написанной в классическом RAD стиле -- когда на формы накидано куча db-aware контролов? Если для этого попытаться применить UML, то он онечно же БЕСПОЛЕЗЕН в таком случае. Ибо говорить про архитектуру и дизайн такой системы довольно сложно. Да, такая система может использовать наборы своих контролов, которые можно описать в UML ... но это, пардон,описание дизайна этих конролов, а не дизайна и тем более не архитектуры конкретной прикладной системы.
2. Зачастую дают общую оценку применимости языка/нотации и т.п. не зная достаточно глубоко возможностей этого языка/нотации или делая попытку НЕ ПРАВИЛЬНОГО использования НЕ ПОДХОДЯЩИХ для решения данной задачи средств ... показателен один пример -- ко мне подошел один разработчик, говорит, что хочет использовать Rational Rose для описания кода его части системы. UML он почитал, сделал реверс инжиниринг системы в Rose ... у него куча всего там нарисовано -- он и говорит -- блин, Rose -- фигня, буду пробовать другие инструменты. Попробовал (я не в курсе правда что он еще пробовал) -- пришел к выводу, что UML -- вообще фигня. Стали разбираться ... после чего он пришел к выводу, что для описания того "как он себе представляет систему" UML не совсем то что нужно ... . И он пустился в творчество -- делая синтез из всех известных ему языков/нотаций -- результат долигх творческих мучений, как обычно нулевой . После того как его творческий запал иссяк ... мы просто поговорили про юзкейсы (в том проекте они были применимы) про отделение бизнес-логики ... и о чудо ... при таком подходе UML оказался пригоден .
3. UML действительно универсальный язык ... но потзоваться им желательно как это рекомендуют методологии ... тот же RUP, тогда все становится на свои места. И дизайн прослеживается и программная архитектура появляется с разных views описанная.

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

Абсолютно согласен!
Я тут именно эту мысль и пытаюсь донести — что UML применять нужно чётко отслеживая условия его применения, желательно в рамках методологии, для которой он был разработан.
А в ответ раздаётся, что БД с контролами можно сделать и без UML, что он там вреден и на этом основании делается очень глубокий вывод, что UML вообще не применим...

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

AF> В результате довольно часто наблюдаю картину, когда талантливый разработчик пытается найти общий язык с бизнесменом. И пытается использовать для этих целей UML (который бизнесмену изучать как то не хочется). В результате разочаровывается в UML и появляются посты, вроде того, который написал автор ветки. Мол UML не для всего подходит. Да он и не предназначался для этого! UML предназначался лишь для описания процессов в системе на уровне построения и реализации системы. Но не на уровне бизнес-логики. Для последнего существует IDEFx.

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

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

AF>Разве я где то утвержал обратное?
А зачем тогда было не соглашаиться?

AF>Но и там можно обходиться без UML
Можно, но, видимо, неудобно. Там он приносит пользу, в отличии от остальных способов применения, которые Вы пытались придумать.

AF> Я просто привёл примеры того, где он успешно применяется.
А зачем? Во всех этих примерах он мог с не меньшим, если не с большим успехом не применяться.

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