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

Первое. Как было справедливо замечено, UML-диаграммы и инженерные схемы/чертежи служат в общем идентичным целям. Но есть одно архиважное различие. В электронике без принципиальной схемы можно спаять максимум детекторный приемник; в строительстве без чертежа можно соорудить только сарай-скворечник. Для любой мало-мальски серьезной затеи приходится прибегать к графической нотации, это абсолютно нормально и не вызывает претензий. С software engineering ситуация другая. Спектр программных решений невероятно широк, а UML оправдывает себя в довольно узкой (хоть и очень масштабной) нише. Как правило, это - программные системы уровня предприятия, где: а) существенным образом используется ООП, б) фигурирует большое количество персистентных бизнес-сущностей и связей между ними, в) есть четкое деление системы на «ярусы» (tiers), г) систему разрабатывает большая команда, д) есть строгие требования к документации. Для проектирования игр, музыкальных плееров или научного софта UML мало полезен. Так вот, проблема в том, что подавляющее большинство крикунов о ненужности UML не имеют никакого отношения к разработке ПО уровня предприятия. Точнее, имеют враждебное отношение; одни подсознательно понимают, что эта область для них недостижима (вследствие низкой квалификации); другие презирают enterprise за то, что якобы enterprise «убивает искусство в программировании и поощряет ремесленничество» (позволю себе не комментировать эту точку зрения); третьи не признают все корпоративное (в том числе и ПО) из чистого нонкоформизма. Далее, негативное отношение к корпоративному ПО переносится на UML - вот и разгадка. Добавим сюда так любимый лисперами «Blub paradox»: понимающий UML смотрит «сверху вниз» и видит возможности его успешного применения, непонимающий - смотрит «снизу вверх» и видит угрозу, как от всего непонятного.

Второе. Тезис о том, что лучшим инструментом проектирования/документирования является словесное описание и сам исходный код. Исходный код не годится для этих целей потому, что огромное количество (если не большинство) терминов UML просто не имеют (и не могут иметь) отражения в исходном коде. Так утверждают, опять-таки, лишь те, кто совершенно не владеет UML и счтает, что UML ограничивается лишь одной диаграммой классов. При этом про такие важные вещи как диаграмма вариантов использования (use-case diagram), диаграмма размещения (deployment diagram), диаграмма состояния (statechart diagram) и диаграмма последовательностей/взаимодействия (sequence/collaboration diagram) ВНЕЗАПНО остаются за кадром. Да, кое-что из этого можно кое-как восстановить по исходному коду, но это задача уровня reverse engineering.

Второе с половиной. Верно, что для любой UML-диаграммы возможно изоморфное текстовое описание. Но выразительность UML на много порядков выше. Как говорит один очень уважаемый Java EE специалист, «a clear, accurate, and easy-to-understand picture is truly worth a thousand words.» И я почему-то склонен ему верить. В самом деле, нарисовать диаграмму можно гораздо быстрее, чем описывать все то же словами. А «распарсить» диаграмму человеку еще проще. И не только распарсить, а увидеть «паттерны» (так ненавидимые все теми же крикунами), а также аномалии. Если электронщику сразу покажется подозрительным отсутствие развязывающего конденсатора в цепи транзистора, то опытный проектировщик сразу заметит циркулярные ссылки. Или возможность разнести иерархии интерфейсов и имплементаций в соответствии с паттерном «мост». Я уже не говорю об удобстве навигации по модели, которое предоставляют современные инструменты для моделирования. А сколько времени понадобится на то же самое с использованием только текстового описания?

Третье. Претензии к якобы «статичности» UML, неприменимости к развивающимся системам и неизбежном устаревании не выдерживают никакой критики. Высказывающим подобные претензии рекомендую курить статью о Round-trip engineering до полного просветления. RTE - пройденный этап, давно известная и обкатанная методология, распространяющаяся не только на UML, но и вообще на системы, представленные множеством гетерогенных артефактов. Вопрос поддержания актуальности UML-моделей - исключительно вопрос владения инструментами и правильной постановки процесса разработки. Нетривиальным (и, тем более, критическим) этот момент может показаться только тем, кто впервые слышит о RTE (что еще раз подтверждает мое предположение о главной причине претензий к UML - далекости от промышленной разработки ПО).

Четвертое. Атоматическая верификация по UML-моделям, точнее якобы ее невозможность. Утверждение об этом снова свидетельствует о незнании предмета дискуссии; я бы рекомендовал сперва ознакомиться с текущей ситуацией в этом плане. Однако, никто не спорит о том, что у UML в этом контексте есть свои недостатки, такие как многословность. Они были учтены в более перспективной методологии LePUS3 и соответствующем инструменте моделирования и верификации Two-tier Programming Toolkit.

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

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