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

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

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

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

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

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

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

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

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

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

B>Есть один комментарий, по поводу использования UML для описания бизнес-процессов (видимо под бизнес-логикой имелось ввиду это).
Да, именно это я и имел в виду.
B>Во-первых нужно определиться в конкретном случае, что мы хотим от формализации бизнес-процессов. Если хотим их "измерять" с т.з. например эффективности и потом реинженирить ... то это один случай, и тут лучше использовать специализированный инструментарий для бизнес-моделирования.

Совершенно согласен.

B>А если речь идет о том, что нам нужно понять как автоматизировать эти процессы (выдвигая предположение, что сами процессы упорядоченны), то в этом случае мы можем использовать UML. Например в нотации Rose для бизнес-моделирования -- и через реализацию бизнес-юзкейсов выйти на системные юзкейсы а оттуда и на дизайн системы. Другой вопрос, что бизнес-юзкейсы не всегда применимы, но и на этот случай есть свои решения. Использованию UML для понимания места информационной системы в деятельности предприятия и понимания границ системы и требований к системе, вполне имеет право на жизнь -- преимущество -- явный переход от БП к требованиям к системе и возможность использования единого языка. Недостатки -- в каждом конкретном случае свои ...
В общем согласен. Но тут есть одна тонкость. Называется плавный переход. Я имею в виду, что часто заранее не ясно, что будет делаться и какова конечная цель моделирования бизнесс процессов. Кому и зачем потребуется модель. В таком случае как правило выгоднее начинать таки с формального описания процессов в виде IDEFx и лишь потом переходить к UML. По следующим соображениям:
Нотация IDEF мне кажется более простой и понятной неискушённому наблюдателю (это подтверждается практикой), она принята именно для этих целей. Она более компактна — что в случае сложных бизнесс-процессов крайне важно, так как тут очень важна выразительность. И наконец от нотации IDEF довольно легко перейти "вниз" — к нотации UML.
Хотя если проект маленький и основное понятно на уровне интуиции... Тогда можно сразу использовать UML, ну а если совсем маленький — так и вообще карандашём обойтись.

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

AF>Если вы не способны увидеть приносимую пользу, ещё не означает, что её там нет.
Ну, во-первых, я не один такой. А во-вторых, рассуждать с позиции "Вам не понять, вы не любили" не самое удачное доказательство.

AF>Это утверждение нуждается в доказательствах. Их то я как раз и не видел.
Как раз наоборот. Утверждение, что UML может быть полезен нуждается в доказательствах. И пока таковых нет.

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

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

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

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

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

Автор: AndreyFedotov
Дата: 14.06.05

.
Ну не ограничивается всё однотипными программками.

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

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

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

AR>>А нельзя ли чуть подробнее раскрыть суть этой идеи или дать ссылочки. Я лично с VS 2005 пока не работал, посему любопытно.
M>В двух словах: архитектор создает свой DSL (Domain Specific Language) под конкретную задачу, и уже в терминах этого языка описывает модель. В момент описания модели код генерится на лету, нет необходимости даже нажимать нарошную кнопку для генерации исходников. В таком виде проект поступает к разработчику, разработчик правит код, и все его изменения моментально отражаются в модели, терминах DSL, и опять-таки нет никакой необходимости нажимать хитрые кнопки, чтобы получить актуальное состояние модели, это 100% on-line инструмент, оба представления проекта, и код, и DSL, всегд анаходятся в актуальном состоянии откуда бы проект не правили. DSL так же поддерживает валидацию, в отличии от UML-я.

M>http://msdn.microsoft.com/library/en-us/dnvs05/html/vstsmodel.asp

Вы будете смеяться, но это всё давно (лет уже как 5 — 7) реализовано в Togethersoft Control Center (который сейчас принадлежит Борланду) применительно к UML. Актуальность кода и диаграмм поддерживается автоматически, независимо от разработчика и количества людей, правивших этот код или диаграммы. Классы можно одновременно просматривать как в виде диаграмм, так и кода — в соседних видах. Изменение диаграммы автоматически приводит к изменению кода и наоборот. По методу класса можно автоматически построить sequence диаграмму, в которой отобразятся все внутренние и внешние вызовы, создания и уничтожения объектов, условные операторы, циклы. По любой диаграмме классов и последовательности выполнения (sequence) автоматически генерируется исходный код (болванка) на выбранном (C++, Java и др. объектно-ориентированные) языке. Создание документации (в формате javadoc) автоматизировано, при условии, что разработчик добросовестно комментирует код и придерживается некоторых простых правил, принятых в javadoc.
Работает это всё как под виндами, так и под юниксами, потому что написано на java.

Так что M$, как обычно, идёт своей путёй. И дело на в буквах DSL или UML, а в реализации.

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

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

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

AF>>Это утверждение нуждается в доказательствах. Их то я как раз и не видел.
M>Как раз наоборот. Утверждение, что UML может быть полезен нуждается в доказательствах. И пока таковых нет.
Плохо учили математику батенька! Любое утверждение нужно либо доказать, либо опровергнуть. Вы не можете опровергнуть этого утверждения и не можете доказать обратного. Так что пока никто и ничего не доказал. Всего лишь спор пары софистов.

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

AF>>Вам не кажется, что немного наивно заочно рассуждать о крупных проектах и говорить о том, что там лучше, а что хуже? Тем паче, что у тех, кто имеет возможность судить об этом точка зрения совсем иная.
M>Во-первых, мне именно так и кажется и поэтому мне совершенно не понятны Ваши постоянные кивки на большие проекты, особенно в свете того, что по Вашему же признанию UML Вы не используете, "но вот умные дядьки в больших проектах...".
Напомню, что сами отцы основатели, хоть и говорили о применимости принципов разработки для проектов любого размера, при этом оговаривались, что применение как методологий, так и инструментария (в том числе и UML) — оправдано лишь в достаточно крупных проектах. Потому, во-первых не удивительно, что в нашем случае толку от UML не много, а во-вторых — только и остаётся, что ссылаться на эти проекты, так как я не копрорация IBM и по 30-40 крупных проектов за раз не веду...

M>А во-вторых, у тех кто имеет возможность регулярно сталкиваться с большими проектами частенько оказывается примерно та же точка зрения что я изложил.
А каков размер этих проектов? Их ведёт одна команда или несколко? UML и методология разработки там применялись продуманно и осознано или хаотично и просто потому, что так надо?

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

AF> Для того, что бы было возможно общение между собой больших групп специалистов — в том числе из смежных областей. Я уже описывал подобную ситуацию здесь

Автор: AndreyFedotov
Дата: 14.06.05

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


AF>Но это не основание не видеть пользы от UML вообще
Равно ка ки не основание видеть эту пользу... "Так в чем польза, брат?" (c)

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

AF>Стоит ли передёргивать. Если вы не видите чёрную кошку в тёмной комнате — это ещё не значит, что её там нет.
Я то как раз не передергиваю, я лишь прошу эту черную кошку показать, если уж Вы утверждаете, что она там есть.

AF>Плохо учили математику батенька!
Это не математика, это логика.

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

AF> А вот то, что инвестиции в UML пока растут — факт.
Да не факт, энтузиазм по этому поводу сильно поутих в последнее время.

AF>Напомню, что сами отцы основатели, хоть и говорили о применимости принципов разработки для проектов любого размера, при этом оговаривались, что применение как методологий, так и инструментария (в том числе и UML) — оправдано лишь в достаточно крупных проектах. Потому, во-первых не удивительно, что в нашем случае толку от UML не много, а во-вторых — только и остаётся, что ссылаться на эти проекты, так как я не копрорация IBM и по 30-40 крупных проектов за раз не веду...
Ну и что Вы тогда с ним носитесь, если реальной пользы он Вам не приносит? Верите на слово большим дядькам? Зря, обманут и не поморщатся....

AF>А каков размер этих проектов?
Каков размер проектов Microsoft?
Или вот Mishka, который тоже засветился в этом топике, как то упоминал, что размер его проекта был порядка 50000 классов, если я правильно помню. И ничего, живут без UML-я и радуются...

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

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

AF>> Для того, что бы было возможно общение между собой больших групп специалистов — в том числе из смежных областей. Я уже описывал подобную ситуацию здесь

Автор: AndreyFedotov
Дата: 14.06.05

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

Ой, это очень по-разному ... и через руководителей и и между собой ... так что варианты имеются.

AF>>Но это не основание не видеть пользы от UML вообще
M>Равно ка ки не основание видеть эту пользу... "Так в чем польза, брат?" (c)

Что есть польза? Видимо для каждого она своя ... Например мы в небольшом проекте из 4-х человек использовали подход на базе RUP ... начиная с vision, требований (юзкейсов) и domain model, выстраивали, почти по Ларману, дизайн системы. Что нам это дало -- мы рассуждали в терминах наших бизнес-классов и в рамках сценариев наших юзкейсов. У нас был один разработчик-надомник -- он получал модели и это избавляло нас от неоднозначности в понимании реализации бизнес-логики и долгих пояснений что да как ... . Кроме этого мы трассировали наши требования (фичи и юзкейсы) с элементами дизайна (на уровне пакетов) -- и коонтролировали тем самым реализацию требований. Тестирование в целях экономии взялся сам заказчик.

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

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

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

Ну SDL существует с середины 80-х. Основная проблема его была в алгебраическом подходе к определению типов данных и, как следствие, в навороченном name resolution by context. Этот подход чересчур формальный и неудобный. UML позволяет описывать типы проще. А недостатки UML-я были видны telecom-сообществу сразу, оно просто ждало, пока эти недостатки начнут устранять.

Могу попугать определяением типа Integer в SDL2000:

value type Integer
  literals unordered nameclass (('0':'9')*) ('0':'9'));
  operators
    "-"        ( this Integer                                ) -> this Integer;
    "+"        ( this Integer, this Integer    ) -> this Integer;
    "-"        ( this Integer, this Integer    ) -> this Integer;
    "*"        ( this Integer, this Integer    ) -> this Integer;
    "/"        ( this Integer, this Integer    ) -> this Integer raise DivisionByZero;
    "mod"    ( this Integer, this Integer    ) -> this Integer raise DivisionByZero;
    "rem"    ( this Integer, this Integer    ) -> this Integer;
    "<"        ( this Integer, this Integer    ) -> Boolean;
    ">"        ( this Integer, this Integer    ) -> Boolean;
    "<="    ( this Integer, this Integer    ) -> Boolean;
    ">="    ( this Integer, this Integer    ) -> Boolean;
    power    ( this Integer, this Integer    ) -> this Integer;
    bs in nameclass '''' ( (('0' or '1')*'''B') or ((('0':'9') or ('A':'F'))*'''H') )
                         -> this Integer;
axioms    noequality
    for all a,b,c in Integer (
/* constructors are 0, 1, +, and unary - */
/* equalities between constructor terms */
    (a + b) + c                        == a + (b + c);
    a + b                                        == b + a;
    0 + a                                        == a;
    a + (- a)                            == 0;
    (- a) + (- b)                == - (a + b);
    <<type Integer>> - 0    == 0;
    - (- a)                                == a;
/* */
/* definition of binary "-" by other operations */
    a - b                                        == a + (- b);
/* */
/* definition of "*" by applying it to all constructors */
    0 * a                                        == 0;
    1 * a                                        == a;
    (- a) * b                            == - (a * b);
    (a + b) * c                        == a * c + b * c;
/* */
/* definition of "<" by applying it to all constructors */
    a < b                                                                                == 0 < (b - a);
    <<type Integer>> 0 < 0                                        == false;
    <<type Integer>> 0 < 1                                        == true ;
    0 < a                                == true ==> 0 < (- a)        == false;
    0 < a and 0 < b        == true ==> 0 < (a + b)    == true ;
/* */
/* definition of ">", "equal", "<=", and ">=" by other operations */
    a > b                                        == b < a;
    equal(a, b)                        == not(a < b or a > b);
    a <= b                                    == a < b or a = b;
    a >= b                                    == a > b or a = b;
/* */
/* definition of "/" by other operations */
    a / 0                                                                                            == raise DivisionByZero;
    a >= 0 and b > a                    == true ==> a / b    == 0;
    a >= 0 and b <= a and b > 0    == true ==> a / b    == 1 + (a-b) / b;
    a >= 0 and b < 0                    == true ==> a / b    == - (a / (- b));
    a < 0 and b < 0                            == true ==> a / b    == (- a) / (- b);
    a < 0 and b > 0                            == true ==> a / b    == - ((- a) / b);
/* */
/* definition of "rem" by other operations */
    a rem b == a - b * (a/b);
/* */
/* definition of "mod" by other operations */
    a >= 0 and b > 0                                ==> a mod b    == a rem b;
    b < 0                                                                ==> a mod b    == a mod (- b);
    a < 0 and b > 0 and a rem b = 0    ==> a mod b    == 0;
    a < 0 and b > 0 and a rem b < 0    ==> a mod b    == b + a rem b;
    a mod 0 == raise DivisionByZero;
/* */
/* definition of power by other operations */
    power(a, 0)                            == 1;
    b > 0 ==> power(a, b)    == a * power(a, b-1);
    b < 0 ==> power(a, b)    == power(a, b+1) / a; );
/* */
/* definition of literals */
    <<type Integer>> 2    == 1 + 1;
    <<type Integer>> 3    == 2 + 1;
    <<type Integer>> 4    == 3 + 1;
    <<type Integer>> 5    == 4 + 1;
    <<type Integer>> 6    == 5 + 1;
    <<type Integer>> 7    == 6 + 1;
    <<type Integer>> 8    == 7 + 1;
    <<type Integer>> 9    == 8 + 1;
/* */
/* literals other than 0 to 9 */
    for all a,b,c in Integer nameclass (
    spelling(a) == spelling(b) // spelling(c),
    length(spelling(c)) == 1                                    ==> a == b * (9 + 1) + c;
    );
/* */
/* hex and binary representation of Integer */
    for all b in Bitstring nameclass (
    for all i in bs nameclass (
    spelling(i) == spelling(b)                                ==> i == <<type Bitstring>>num(b);
    ));
endvalue type Integer;

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

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

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

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

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

M>Таким образом делаем вывод, что UML хорош в качестве buzz word, чтобы красиво разогнуть пальцы перед заказчиком, мол "... наши разработки ведуться по RUP с применением UML... " и подсунуть клиенту красивые диаграмки, чтобы тот покивал с умным видом и ощутил свою причасность. Вот для этого UML и используется.. хм... дефакто.

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

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

B>Вау ... вот уж чего я никогда не делал, так это не показывал заказчику UML ... это ж безумие заставлять заказчика понимать UML ...

Ну... а сели заказчик настаивает на UML? Если у заказчика есть отдел IT?

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


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

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

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

C>Обычно гораздо эффективнее помогают не диаграммы в РациональнойРозе, а
C>простые наброски в виде квадратиков и стрелочек с надписями То есть
C>формальный синтаксис UML скорее мешает, чем помогает — проще
C>использовать нечто UML-подобное.

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

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

B>Полный бред, что UML это базворд для надувания счек перед заказчиком ... большинству заказчиков пофигу на UML ты проектируешь или просто код пишешь ...

Ну... в одном из проектов UML-диаграммы входили в ТЗ, Посему об этом и пишу IT департамент со стороны заказчика даже вносил в них изменения, мол на самом деле к нас не так, а вто так.

Снова подключусь к разговору, теперь уже для защиты UML.

Я не считаю UML хорошим решением проблем собственно в качестве средства разработки. Но глупо отрицать его полезность как средства документирования сложных проектов и систем. Даже опытный разработчик, непосредственно участвовавший в проекте, возращаясь к своим "бумажкам и слюням" через пол года — год уже может запутаться в этом зоопарке. Что же говорить о проектах/системах, которые, к примеру, были куплены у другой компании, а теперь с ними начинает работу совершенно новая группа, не имеющая возможности что-то уточнить у своих предшественников. Попробуйте продать сложный продукт, если у вас есть только исходные коды (пусть даже хорошо откомментированные). За это без самих разработчиков никто гроша ломанного не даст. А вот за хорошо задокументированные (в т.ч. и с помощью стандартных UML-средств) проекты в мире иногда платят миллионы и более.

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

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


M>Я так и не услышал ответа на вопрос, чем может помочь UML построенный по готовой модели.

Поможет, например, управлять сложностью. Лично я предпочту увидеть картинку где будет изобраден некий фреймворк (в виде диагрмм классов).
Интересен момент, что говоря о UML вы как-то циклитесь только на диаграммах классов ... коллаборэйшн, деплоймент диаграммы как-то особо не упоминаются ...
Диаграмма классов показывает только статику ... как мне увиидить динамику взаимодействия объектов???
Кроме этого, пример из практики ... у нас например разработка ведеться на разных языках: Visual Basic, С++, Delphi, Java ... вы, что мне как проектировщику или архитектору предлагаете при проектировании систем автоматизации бизнеса знать все особенности этих языков ... чтобы общаться с разработчиками? Бред ... мне достаточно спроектировать модель анализа (да, да ... на UML) ... где я покажу реализацию юзкейсов, например, ... а в конкретной среде разработки ее будут имплементировать конкретные разработчики, подключая необходимые библиотеки и прочия ...

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

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