Каковы наиболее существенные недостатки использования UML?

Ответ 1

Самый большой из них - это еще один слой бюрократизма, который мешает всего $#% $#% кодировать вещь и заставлять ее работать.

Ответ 2

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

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

Ответ 3

Я могу сказать по крайней мере три:

• Требуется много времени, чтобы диаграмма была разумной и синхронизирована с фактическим кодом. Диаграммы UML не запускаются, но требуют много времени. Поэтому они хороши только в том случае, если размер вашей организации может ими управлять.
• Вы не можете представлять каждое условие в диаграмме последовательности. Это невозможно, если вы хотите доставить. Поэтому диаграммы состояния должны передавать основные факты, а не все возможные результаты.
• Хорошее программное обеспечение UML стоит денег, и для правильного освоения требуется некоторое время.

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

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

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

UML не является хорошим или плохим. Это может быть хорошим инструментом, но он должен использоваться в надлежащем контексте.

Отсутствие функций?

Ну, я обнаружил, что UML сильно нацелен на объектно-ориентированное видение мира. Наша компания в основном разрабатывалась на python, с особым вниманием к модулям. Объектами были легкие контейнеры данных, но вся логика выполнялась на уровне модуля. Трудно правильно моделировать этот стиль реализации на уровне UML, если вы не прибегаете к некоторым "хакам" в терминологии. Мне сложно моделировать в UML для функциональных или процедурных языков.

Другая вещь, которую я нахожу раздражающей, - это предположение о моделировании использования в качестве диаграммы. Мой опыт в том, что лучший способ передать пример использования - написать короткую историю или короткий код, покалывающий функцию, которую вы хотите передать. Рассказ должен быть коротким, максимум на одну страницу. Этот подход имеет два преимущества: если ваша история является письменной прозой, команда Q/A может легко ее читать и проверять. Если ваша история - это код, вы можете поместить ее в качестве функционального теста и позволить ей работать в ночное время. Диаграмма не удовлетворяет ни одной из этих потребностей с добавленной стоимостью.

Ответ 4

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

См. также раздел критических замечаний страница UML wikipedia:

• Стандартные навороты

• Проблемы в обучении и принятии

• Сопротивление суммарного импеданса/импеданса

• Формат дисфункционального обмена

Ответ 5

Это не Agile

Что должно было быть последнее слово на UML было написано разочарованным учеником "Candide Smith", хорошо, действительно автор Эйфеля Бертран Майер.

Ответ 6

У меня нет разумного ответа на этот субъективный вопрос, но Верити Стоб забавно относится к теме.

Ответ 7

Другим недостатком UML является то, что он имеет тенденцию чрезмерно подчеркивать дизайн, что может привести к "параличу анализа" (люди чрезмерно анализируют свою проблему) и имеют ползучесть (теряя вид реальной проблемы). Дизайн UML может только довести вас до решения проблемы, и вы должны быть осторожны, чтобы быстро перейти в код (но не раньше; -).

Ответ 8

UML несколько менее применим к отважному новому миру свободной печати и баз данных NoSQL. Он имеет идеи OO класса как структуры данных, а не включения в нее классификации.

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

Ответ 9

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

• Заставьте это работать. (Просто запустите прототип и запустите его, у которого есть все основные функции, независимо от того, сколько он отстой. Это заставляет вас видеть все мелкие мелочные детали, которые могут не произойти в формальном анализе. Фактическая реализация вашей идеи облегчает анализ того, действительно ли эта идея действительно стоит делать в первую очередь или ее вообще нужно откладывать.)

• Сделайте все правильно. (Только сейчас, когда у вас есть рабочий прототип, и вы знаете, что все проблемы с реалистичной реалистичностью, по крайней мере, в принципе разрешимы, вы беспокоитесь о хорошем дизайне. Рефакторируйте это, чтобы следовать хорошим правилам программирования, уменьшать сцепление, делать правильные обработка ошибок, yada yada yada.)

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

Ответ 10

Для диаграмм классов в UML имеет смысл использовать их только в том случае, если существует автоматизированный способ генерации кода непосредственно из диаграммы. Я реализовал такой инструмент редактора UML, основанный на 4-уровневых мета-уровнях, рекомендованных OMG (Object Management Group), и мы с большим успехом использовали UML в команде из 5 разработчиков более 2 лет, занимая около 20-30 архитектурных итераций. Диаграмма была корневым артефактом автоматизированной цепи сборки, воздействующей на сотни производных артефактов, API, сгенерированных документов, DDL, проектов, тестов и т.д.

Таким образом, сам UML в Class Diagrams - отличный "программирующий" язык, если вы на самом деле программируете в нем.

Для диаграмм классов в UML, если он не переводится автоматическим способом, тогда его сбой.

Ответ 11

вы можете найти некоторые дополнительные причины в sysml

в основном он добавляет поддержку аппаратных диаграмм (и еще несколько) и отбрасывает другие.