Абсолютно необходимые диаграммы UML даже для очень маленьких проектов?

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

Однако есть несколько очевидных ситуаций, когда они полезны:

• Если ваш проект будет каким-либо образом большим с точки зрения ОО структуры, то обычно полезно создать диаграмму классов. Таким образом, вы сможете работать с абстракциями, пока не придет время вникать в детали.

• Если ваш проект будет в основном основан на пользовательском интерфейсе, то может быть весьма полезно создать диаграмму Use Case как способ определения требований. Это особенно полезно, если вам удастся убедить заказчика принять этот метод.

• Если похоже, что в вашей системе будет много взаимодействий между объектами, то создание диаграммы последовательности может быть полезным для понимания взаимодействий. Кроме того, я думаю, что диаграммы последовательности являются наиболее интуитивно понятными для разработчиков, поскольку я заметил, что многие разработчики инстинктивно составляют диаграммы взаимодействия подобным образом - даже если они не знакомы с UML - в простых диаграммах Powerpoint\visio.

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

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

UML мертв, никто, кто имеет значение, не использует его.

Единственные люди, которые используют UML, это консультанты, которые пишут статьи и пытаются быть формальными и вычурными, но не имеют сути.

Если UML так хорош, почему я не могу найти его для любого из проектов, которые Google публикует на googlecode?

Где UML для Ruby или Python, или DOT NET, или Java?

Обычно формальный UML - это слишком много для небольших проектов. Просто придерживайтесь базовых диаграмм классов и простых диаграмм вариантов использования.

Небольшие проекты (по моему опыту) чаще подвергаются изменениям, поэтому ваши диаграммы очень часто будут устаревать. У вас гораздо больше шансов поддерживать менее формальную диаграмму в актуальном состоянии, чем переделывать все причудливые вещи UML.

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

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

Лично у меня сложилось впечатление, что UML - это игрушка академического мира. Это единственное место, где я слышал и видел, как люди бегают с UML, SOA и так далее.

В своей практике я почти не видел UML. Что ж, может быть, однажды во время моего семестрового проекта и на моей текущей работе, где у нас есть пара схем восьмилетней давности (и точно такие же устаревшие) где-то на внутреннем FTP-сервере.

UML мертв из-за использования дрянных инструментов с открытым исходным кодом !! Многие компании берут бесплатные инструменты и просто создают несколько диаграмм, совсем без обучения, тогда они говорят, что это бесполезно. Это непрофессионально, и очень ограниченное использование UML - настоящая катастрофа для проектов !!