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

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

B>>Пардон, но это не ТРЕБОВАНИЕ ... это дизайн. Теперь мне все с вашим случаем понятно.

M>А что тогда тредование? Разработать систему документооборота, полностью удовлетворяющую заказчика? Тут ясное описание, что понимается под договором.

По определению, например данному в RUP Требование это "условие или возможность, которому должна удовлетворять система". IEEE Standartd Glossary of Software Engineering Terminology дает сходное по смыслу определение требований, но только более формальное. Кроме этого, тот же IEEE (IEEE STD 830-1998) дает понимание о документе, в котором должны описваться требования (SRS) и критерии оценки качества требований. Рекомендую к прочтею по этому вопросу книгу К. Вигерса, в этой книге вы сможите найти более развернутое описания, чем я тут привел.

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

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

AR>> Но глупо отрицать его полезность как средства документирования сложных проектов и систем.
M>Глупо было бы считать что он полезен для документирования сложных проектов и схем.
Глупо было бы считать что он бесполезен для документирования сложных проектов и схем.
Аргументируй — что есть более полезное? Код? Карандаши бумага? (Только помни, что авторы кода тебе уже не доступны)

AR>> Даже опытный разработчик, непосредственно участвовавший в проекте, возращаясь к своим "бумажкам и слюням" через пол года — год уже может запутаться в этом зоопарке.
M>Опытному разработчику достаточно кода, а не опытному тем более.
Угу. Вот посмотрим на тебя, когда тебе вместо книги с простыми и ясными обяснениями предметной области вывалят тону кода. Ты интересно и математику и физику только по исходным кодам учил?

AR>> Но посмотрите на это, например, с точки зрения финансового директора или собственника компании.
M>А им-то UML во что уперся?
Сам UML — не во что. А вот грамотное описание модели, в том числе и с использованием UML — очень даже. Но опять-таки оно нужно не им лично, а тем спецам, которых они наймут.

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

AR>>А в чужом?
M>А в чужом тем более.

И ты в состоянии по коду понять что имелось в виду при его написании? Какая идея за этим стояла?
Тогда ты не только телепат, но ещё и медиум в придачу...

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


N>попробуйте продать код+uml, ценность вашего проекта возрастёт не более процентов < 10%.

Не стоит продавать UML ... если ваша цель -- продать разработанную систему.

N>я долго не ввязывался в спор не понимая его сути, ибо всё одно и тоже... может проще подойти системно к этому:

Ой не надо вот про системный подход ... и т.п. ...

N>1. Информативность UML крайне низкая, средства работы крайне не удобные, идеология слабо проработаная.

Сильно зависит от вашего уровня знания UML и степени владения средством . Крое этого зависит от того, КАК вы подходите к проектированию систем. Я ужу тут говорил про методологические аспекты, которые почему-то многими дискутирующими упускаются из виду ...


N>Крупные компании управляются малограмотными в IT людьми, или точнее грамотными на обобщённом уровне, которые мыслят тенденциями, если есть тенденция развития UML, то её могут мягко начать внедрять, но в описаниях типа MSDN вы врядли увидите UML почему?

Если UML маркетинговая политика IBM и Ко... (хотя это не совсем верное утверждение), то отсутствие UML в MSDN вполне может быть маркетинговой политикой MS , такую мысль допускаем? А может UML не место в MSDN?

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

О... тут я пожалуй вставлю один комментарий. Интересно, на ваш взгляд, для чего люди придумывают всякие там стандарты ... не только в IT ... не задумывались? И что по-вашему означает "уметь писать документацию"? И какие должны быть критерии умения писать?? Что значит хорошее описание???? И где гарантия, что написав документ, на ваш взгляд очень хороший, со схемками в нотации известной только вам одному понравится другому человеку, который тоже скажет что это хороший, информативный документ? А где учат писать такие документы? или это талант от Бога ... дык не все люди столь талантливы.
Когда вы проектируете электрические или электронные устройства -- никому почему-то в голову не приходит ругать графическую нотацию языка, на котором описываются эти схемы! Ведь же тоже можно написать текстом, украсить квадратиками .... но почему-то делают в определенной, СТАНДАРТНОЙ нотации (да, с текстовыми комментариями). Для чего? Чтобы уменьшить энтропию, чтобы все говорили на одном языке. UML выступает в роли такого универсального языка общения при проектировании IT систем. Вот и все.

N>Смотрю: Затраты на обучение UML, затраты на средства проектирования, затраты на обеспечения избыточных процессов, итп. Время простоя на восприятие UML, время простоя на поиск в UML, время выроботки стандарта понимания UML (написать можно и на UML по разному), время на поиск решений по отображению в ограничениях UML, итд. -- всё это стоит денег, которые можно потратить на что-то более интересное.

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

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

AR>> Совершенно очевидно, что со временем архитектура и сложность информационных систем растет. И если раньше гении-одиночки могли выдавать на гора несколько действительно достойных программ в год, то сейчас в мире уникумы, которые умудряются в одиночку вести работу хотя бы над одним действительно серьезным продуктом, просто наперечет.
M>Причем тут гений-одиночка? Я где-то говорил, что архитектор должен самостоятельно написать весь код?
Но нигде не обяснили, как он может обяснить что нужно писать значительному числу людей — особенно тем, кому потом придётся стыковаться к его коду...

M>Проблема в том, что даже грамотно спроектировать систему невозможно не зная языка на котором она будет реализована и если уж случилось так, что система должна быть реализована на десятке языков и запроектирована одним архитектором (я в это не верю, но возьмем гепотетическую задачу), то если архитектор этих 10 языков не знает, то может даже и не браться.
M>Или Вы считаете, что можно совершенно спокойно проектировать не зная особенностей языка реализации?
Отцам основателям это удавалось. Секрет в том, что бы знать принципы построения языков и архитектуру используемых библиотек, а вот синтаксис — вовсе не обязательно...

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

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

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

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

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

N>p.s. что такое модель анализа? вы придумали новое понятие... -- давайте ему тогда определение.

Увы, я стараюсь ничего не придумывать, а использовать готовое ... , так проще ... все придумано до нас . Analysis model -- это один из артефактов RUP ... , там же можно найти определение .

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

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

B>>Поможет, например, управлять сложностью.
M>Зачем ей управлять? Ее надо просто не создавать...

Увы, все простые системы уже созданы .. нам остались только сложные и запутанные .


B>>Кроме этого, пример из практики ... у нас например разработка ведеться на разных языках: Visual Basic, С++, Delphi, Java ... вы, что мне как проектировщику или архитектору предлагаете при проектировании систем автоматизации бизнеса знать все особенности этих языков ... чтобы общаться с разработчиками?
M>Конечно, и как минимум не хуже чем разработчики, иначе такого напроектируешь, что никакой UML не спасет...

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

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

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

B>> можете подробнее ваш case описать?
M>Он не мой, он классический. Закакзчик знает красивое слово UML он хочет, наблюдать за ходом разработки с помощю UML, совершенно не важно понимает он его или нет. Ни вопрос — в каждый отчет лепим диаграмки, отдаленно напоминающие проект и забываем о них, все довольны и заказчик и исполнитель.

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

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

M>Проблема в том, что даже грамотно спроектировать систему невозможно не зная языка на котором она будет реализована и если уж случилось так, что система должна быть реализована на десятке языков и запроектирована одним архитектором (я в это не верю, но возьмем гепотетическую задачу), то если архитектор этих 10 языков не знает, то может даже и не браться.
M>Или Вы считаете, что можно совершенно спокойно проектировать не зная особенностей языка реализации?

Можно с некоторыми оговорками, а нужно безо всяких оговорок. Не должны архитекторы думать об особенностях языка реализации. Да и в действительно крупных проектах это на этапе первичного проектирования и не известно вовсе. Скажем разрабатываем мы систему управления межпланетным исследовательским космическим зондом (самолетом, атомным реактором, коллайдером, лечебно-диагностическим комплексом и т.п.). Зонда этого еще и в чертежах то и нет. Его узлы тоже только начинают проектировать и только задумываются об элементной базе. Будем ждать пока он не появится в железе (или хотя бы пока не закончится разработка схемотехники)? А если на завершающих этапах проекта решат поменять поставщика процессоров (мали по какой причине — качество скажем хромает)? Будем срочно обучать архитекторов всем особенностям его реализации? Я уже не говорю о том, что речь может идти действительно о десятке разных аппаратных решений (видов всяких микроконтроллеров существует море), использующихся в рамках одного сложного аппарата, оснащенного сложной комплексной информационной системой, о разработке которой и идет речь. Конечно, какое-то понимание об архитектуре всего того железа, на котором будет крутиться его система, архитектор должен иметь. Но доскональное знание ВСЕХ языков, на которых будет написан исходный код, является лишним. И лишним это является не потому, что это не полезно для конкретного архитектора или проекта, а потому, что архитекторы с такими знаниями дорого стоят и найти их не просто.

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

А что применялось в качестве средства общения разработчиков в процессе разработки? Что? На сегодня вариантов не так уж и много: исходный код, слюни и бумага, UML, проприетарные средства (возможны какие-либо комбинации из этого перечня). Документация — это средство описания проекта, пригодное для использования ВНЕШНИМИ участниками. Если таковые не предвидятся изначально, то и скорее всего документация не нужна. Устроят ли ВНЕШНИХ участников слюни и бумага или проприетарные средства? На мой взгляд, нет! Что в остатке? UML и исходный код. Именно какая-то их комбинация (+ текстовые комментарии) и позволяет создать документацию для тех, кто не участвовал в проекте.

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

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

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

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

M>>Например, договор является разновидностью внутреннего документа. Тут же рисунок --- класс внутреннего документа, от него наследован класс договора, показано какие свойства добавились, из чего состоит, ... и т. д.

B>По определению, например данному в RUP Требование это "условие или возможность, которому должна удовлетворять система".

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

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

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

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

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

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

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

1. Тестовое описание принципов системы
2. Помощь по системе (в формате свойство, описание)
3. Примеры использования
4. Исходный текст
5. Всякие документы вроде How to... FAQ...

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



AR>>> Даже опытный разработчик, непосредственно участвовавший в проекте, возращаясь к своим "бумажкам и слюням" через пол года — год уже может запутаться в этом зоопарке.
M>>Опытному разработчику достаточно кода, а не опытному тем более.
AF> Угу. Вот посмотрим на тебя, когда тебе вместо книги с простыми и ясными обяснениями предметной области вывалят тону кода. Ты интересно и математику и физику только по исходным кодам учил?

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

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

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

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

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

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

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

M>1. Тестовое описание принципов системы
M>2. Помощь по системе (в формате свойство, описание)
M>3. Примеры использования
M>4. Исходный текст
M>5. Всякие документы вроде How to... FAQ...

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

Никто и не говорит, что ты должен пользоваться UML диаграммами. Более того, всё зависит от библиотеки. Если это библиотека обёрток над простыми типами — от UML тут толку ноль. А если это API к сложной телекоммуникационной системе? Ты уверен, что тебе проше будет вычитывать описания каждой из 250 функций, для того, что бы выяснить, что запрос определённых данных делается с помощью десятка из них, причём в определённой последовательности? Или всё-таки проще посмотреть на диаграмму последовательностей, что бы всё это увидеть на одном экране за 5-10 секунд?

AR>>>> Даже опытный разработчик, непосредственно участвовавший в проекте, возращаясь к своим "бумажкам и слюням" через пол года — год уже может запутаться в этом зоопарке.
M>>>Опытному разработчику достаточно кода, а не опытному тем более.
AF>> Угу. Вот посмотрим на тебя, когда тебе вместо книги с простыми и ясными обяснениями предметной области вывалят тону кода. Ты интересно и математику и физику только по исходным кодам учил?

M>Символический язык, используемый в математике и физике, гораздо ближе к языкам программирования, нежели к UML. А вот картинки... но в серьезных книгах их не так уж и много...
Но ты же книги берёшь, а не исходный код! Ты же в книге читаешь тескст с формулами, а не просто голые формулы! А если речь идёт о пространственных интегралах или графиках смотришь на картинки и разбираешься — что там нарисовано.

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


M>Так вот, эта диаграмма со всей определенностью, со всей принципиальностью показывает, что на системы накладываются следующие условия:
M>а) договор обладает всеми теми атрибутами, которыми обладает внутренний документ,
M>б) договор имеет атрибуты "Контрагент", и др.,
M>в) все операции, применимые ко внутреннему документу, применимы и к договору,

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

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


M>Проблема в том, что даже грамотно спроектировать систему невозможно не зная языка на котором она будет реализована и если уж случилось так, что система должна быть реализована на десятке языков и запроектирована одним архитектором (я в это не верю, но возьмем гепотетическую задачу), то если архитектор этих 10 языков не знает, то может даже и не браться.

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

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

B> рекоммендую восполнить пробелы в ваших знаниях, а потом дискутировать ...
Рекомендую не рекомендовать...

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

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

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

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

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

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

AR> Не должны архитекторы думать об особенностях языка реализации.
Все понятно.

AR> Но доскональное знание ВСЕХ языков, на которых будет написан исходный код, является лишним.
Оно является необходимым. Не досконеальное, но не меньшее чем у рядового разработчика на этом языке.

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

AR> Документация — это средство описания проекта, пригодное для использования ВНЕШНИМИ участниками.
ВНЕШНИМ участникам не составит никакого труда все объяснить так же как и внутренним, если они именно работать дальше с проектом собираются.Какой смысл UML городить? Для реальной работы UML бесполезен, так как имеет мало общего с реальным проектом и в любом случае нуждается в дополнительном описании. Для галочки и отчета, да UML пойдет.

AR> Именно какая-то их комбинация (+ текстовые комментарии) и позволяет создать документацию для тех, кто не участвовал в проекте.
Все верно, только UML выкинуть, по причине ненужности для реальной работы.

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

AR>Сегодня удобно использовать именно UML для представления в проектной документации той информации, которую нельзя или не наглядно представлять в исходном коде.
Да неудобен UML в этом качестве, голые исходники зачастую удобнее.

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

B>Позволю себе не согласиться на счет классики .
Напрасно.

B>Классика, это когда заказчик вообще не знает UML , и в классике он ему и не нужен ... ему нужен работающий продукт.
Это не классика — это идеал, а идеала не существует.

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

B> (только не нужно связвать зрелость процессов с UML, это не верно).
Но Вы же только что это сделали.

B> Вот только не корректно из этого конкретно примера/нескольких примеров делать всеобъемлющие выводы.
Ой, золотые слова. Вот когда в следующий раз будете приводить пример успешного проекта с использованием, UML вспомните их пожалуйста.

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


AF> Аргументируй — что есть более полезное?
Код более полезен, UML не имеет ничего общего с кодом, особенно если разработчик недоступен. В такой ситуации он не просто бесполезен — он вреден.

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

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

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

AF>И ты в состоянии по коду понять что имелось в виду при его написании? Какая идея за этим стояла?
Если код написан так, что его понять невозможно, то и UML не спасет.