Я могу сказать как минимум три:
- Требуется много времени, чтобы сохранить диаграмму разумной и синхронизированной с реальным кодом. UML-диаграммы не работают, но требуют много времени. Таким образом, они хороши, только если ваша организация может управлять ими
- Вы не можете представить каждое условие на диаграмме последовательности. Это невозможно, если вы хотите доставить. Таким образом, диаграммы состояний должны содержать основные факты, а не все возможные результаты.
- Хорошее программное обеспечение UML стоит денег, и для правильной работы требуется некоторое время.
Итак, я думаю, что UML хорош как дополнительная документальная роль, и только если это позволяет размер вашей организации.
Решения ... ну, в конце концов, построение диаграмм - это просто способ передать информацию высокого уровня другому человеку в пространстве или времени (например, вы могли бы быть в каком-то году). Экстремальное программирование переносит бремя поиска информации с мертвого дерева на живой мозг. Конечно, это предполагает, что живой мозг никогда не забывает и никогда не уходит. Экстремальное программирование использует избыточность, чтобы уменьшить влияние таких случаев. В большой компании сильный раунд увольнения может уничтожить целые команды, поэтому хранение информации в мозгах может быть рискованным. С другой стороны, у крупных компаний есть человеческая сила, которую можно тратить впустую, а следовательно, и диаграммы.
Кроме того, как указывает WDuffy, если вы дизайнер, и вам необходимо сообщить команде программистов, что они должны реализовать, гораздо проще использовать диаграмму UML. Конечно, небольшая компания с небольшой командой обычно преследует небольшие цели, и вы можете организовывать людей с другим стилем. Небольшая компания UMLing будет производить только UML-диаграммы своего революционного продукта, и тогда она обанкротится.
UML не хороший и не плохой. Это может быть хорошим инструментом, но его нужно использовать в правильном контексте.
Не хватает функций?
ну, я обнаружил, что UML сильно нацелен на объектно-ориентированное видение мира. Наша компания в основном разрабатывается на python, уделяя особое внимание процедурам на уровне модулей. Объекты были легкими контейнерами данных, но вся логика была сделана на уровне модулей. Сложно правильно смоделировать этот стиль реализации на уровне UML, если вы не прибегнете к каким-то «взломам» в терминологии. Я думаю, что трудно моделировать в UML для функциональных или процедурных языков.
Другая вещь, которую я нахожу раздражающей, это предположение о моделировании прецедента в виде диаграммы. По моему опыту, лучший способ передать сценарий использования - это написать короткий рассказ или короткий код, рассказывающий о функции, которую вы хотите передать. История должна быть короткой, максимум одна страница.
У этого подхода есть два преимущества: если ваша история представляет собой письменную прозу, команда Q / A может легко прочитать и протестировать ее. Если ваша история - это код, вы можете поставить ее в качестве функционального теста и запустить ночью. Диаграмма не удовлетворяет ни одной из этих потребностей в добавленной стоимости.