UML — отличный язык для моделирования программного обеспечения в соответствии с бизнес-требованиями, но растущее сообщество указывает на некоторые недостатки некоторых недостающих функций.
Каковы наиболее существенные недостатки, которые вы считаете решающими для UML, и что может быть хорошей альтернативой для решения этих недостающих функций?
Самый большой из них заключается в том, что это еще один слой бюрократии, который мешает просто $#%$#% закодировать вещь и заставить ее работать.
Тот факт, что люди используют его для «моделирования программного обеспечения для бизнес-требований», как вы выразились, и прочая подобная процессно-ориентированная чепуха. UML начинался как общепринятый способ для программистов передавать программное обеспечение другим программистам в графической форме. В этом смысле это просто формализованные каракули на салфетке — и как таковые они очень эффективны. Вы можете нарисовать диаграмму классов UML на доске, и я смогу понять ее, не придираясь к обозначениям.
Но где-то в процессе кому-то пришла в голову идея, что графическая нотация может каким-то образом быть самостоятельным процессом или, по крайней мере, формальной частью более крупного процесса. И это просто глупо. Диаграммы UML — прекрасный способ иллюстрировать книги, и они весьма полезны для инженеров, когда они могут набрасывать идеи туда и обратно. Но на этом все должно было закончиться.
Я могу сказать как минимум три:
Итак, я думаю, что UML хорош как дополнительная роль в документации, и только если это позволяет размер вашей организации.
Решения... ну, в конце концов, диаграмма - это просто способ передать информацию высокого уровня другому человеку в пространстве или времени (например, это может быть вы через год). Экстремальное программирование переносит бремя поиска информации с мертвого дерева на живой мозг. Конечно, предполагается, что живой мозг никогда не забывает и никогда не сдается. Экстремальное программирование использует избыточность, чтобы уменьшить влияние таких событий. В крупной компании сильный раунд увольнений может уничтожить целые команды, поэтому хранение информации в мозгу может быть рискованным. С другой стороны, у крупных компаний есть человеческая сила, поэтому диаграмма.
Кроме того, как указывает WDuffy, если вы дизайнер и вам нужно сообщить команде программистов, что им нужно реализовать, гораздо проще использовать диаграмму UML. Конечно, у небольшой компании с небольшой командой, как правило, небольшие цели, и вы можете организовать людей с другим стилем. Небольшая компания UMLing будет производить только UML-диаграммы своего революционного продукта, а потом обанкротится.
UML не хорош и не плох. Это может быть хорошим инструментом, но его нужно использовать в надлежащем контексте.
Не хватает функций?
ну, я обнаружил, что UML сильно нацелен на объектно-ориентированное видение мира. Наша компания в основном разрабатывалась на Python, уделяя особое внимание подпрограммам на уровне модулей. Объекты представляли собой легковесные контейнеры данных, но вся логика выполнялась на уровне модулей. Трудно правильно смоделировать этот стиль реализации на уровне UML, если только вы не прибегнете к некоторым «хакам» в терминологии. Я предполагаю, что в UML сложно моделировать функциональные или процедурные языки.
Еще одна вещь, которую я нахожу раздражающей, — это предположение о моделировании вариантов использования в виде диаграммы. По моему опыту, лучший способ рассказать о прецеденте — это написать короткий рассказ или краткий код, затрагивающий функцию, которую вы хотите передать. Рассказ должен быть коротким, максимум на одну страницу. У этого подхода есть два преимущества: если ваша история написана прозой, команда Q/A может легко ее прочитать и протестировать. Если ваша история — это код, вы можете поставить его в качестве функционального теста и запустить ночью. Диаграмма не удовлетворяет ни одной из этих потребностей в добавленной стоимости.
Одна проблема с UML связана с его универсальностью: вещи в UML не всегда могут быть реализованы непосредственно на целевом языке, или некоторые языки имеют возможности, которые не могут быть выражены в UML. Поэтому может быть лучше заранее знать язык реализации, что ограничивает его универсальность.
См. также раздел критических замечаний на странице википедии UML:
Раздувание стандартов
Проблемы в обучении и усыновлении
Совокупный импеданс/несоответствие импеданса
Нефункциональный формат обмена
Что должно было быть последним словом UML был написан разочарованным студентом "Кандидом Смитом", ну, действительно автором Эйфеля Бертран Мейер.
Другим недостатком UML является то, что он имеет тенденцию чрезмерно подчеркивать дизайн, что может привести к «аналитическому параличу» (люди чрезмерно анализируют свою проблему) и расползанию функций (упуская из виду реальную проблему). Дизайн UML может только увести вас в решении проблемы, и вы должны быть осторожны, чтобы перейти к коду достаточно быстро (но не раньше ;-).
UML несколько менее применим к дивному новому миру свободной типизации и баз данных NoSQL. У него есть ОО-идеи класса как структуры данных, а не классификация, встроенная в него.
Еще один недостаток, хотя и не самонадеянный, заключается в том, что он явно не способствует абстракции. Все, кого я знаю, используют инструменты UML для более абстрактного моделирования, но способ написания стандартов не очевиден.
Еще одна проблема с UML (и большим проектом в целом) заключается в том, что иногда трудно предвидеть все мельчайшие проблемы с реализацией, с которыми вы столкнетесь и которые могут повлиять на ваш дизайн, пока вы действительно не начнете что-то реализовывать. Конечно, я программист-исследователь в области биоинформатики, который работает над небольшими проектами с одним человеком, но я даже не верю в какой-либо предварительный дизайн, по крайней мере, для небольших проектов. Я верю в следующее:
Сделай так, чтобы это работало. (Просто создайте и запустите прототип, который имеет все основные функции, независимо от того, насколько он отстой. Это заставит вас увидеть все мелкие детали, которые могут быть не обнаружены при формальном анализе. Наличие реальной реализации вашей идеи. облегчает понимание того, действительно ли эта идея стоила того, чтобы ее воплотить в жизнь, или от нее следует вообще отказаться.)
Сделать это правильно. (Только теперь, когда у вас есть работающий прототип и вы знаете, что все мельчайшие проблемы реализации, по крайней мере в принципе, решаемы, вы беспокоитесь о хорошем дизайне. обработка ошибок, йада йада йада.)
Сделай это быстро. Если это код приложения, вам лучше иметь доказательство того, что вы нашли медленную часть. Если это общий библиотечный код, у вас должны быть веские основания полагать, что фрагмент кода может быть разумно медленным в некоторых случаях использования библиотеки, т.е. не оптимизировать функцию, которую никто никогда не вызовет в цикле.
Для диаграмм классов в UML их имеет смысл использовать только в том случае, если существует автоматизированный способ генерации кода непосредственно из диаграммы. Я реализовал такой инструмент редактора UML на основе 4-уровневых метауровней, рекомендованных OMG (Группа управления объектами), и мы добились больших успехов, используя UML в команде из 5 разработчиков за 2 года, выполнив около 20-30 архитектурных итераций. Диаграмма была корневым артефактом автоматизированной цепочки сборки, оказывая влияние на сотни производных артефактов, API-интерфейсов, сгенерированных документов, DDL, проектов, тестов и т. д.
Таким образом, UML в части диаграмм классов сам по себе является отличным языком «программирования», если вы действительно программируете на нем.
Для диаграмм классов в UML, если они не могут быть переведены автоматически, то это не удастся.
