Конечно, чтобы что-то в них понимать надо сначала изучить "синтаксис", т.к. есть разница и в стрелочках и кружочках
http://khpi-iip.mipk.kharkiv.edu/library/c...leon/index.html

Имхо для Qt можно найти применение. Написать пару диаграмм взаимодействия эвентов, сигналов, слотов, потоков. Потом в Вики впихнуть. Все-таки одно дело, когда ты читаешь в ассистенте и на личном опыте и совсем другое, когда ты видишь полную картину

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

Хотел описать класс QObject, терпения не хватило

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

Я вот думаю. Если "Системный Аналитик" (будет считать это тот, кто проектирует диаграммы на UML) это некий посредник (интерфейс) между заказчиком и исполнителем, то программист просто обязан уметь "читать" эти диаграммы, иначе ему никто не поможет

Всё зависит от конкретной компании и проекта. UML - это всего лишь инструмент. Естественно, если его используют, то программист должен уметь читать. А основная фишка системного аналитика не в том, чтобы просто знать UML, а уметь именно проектировать. Если после этого у него получается описать модель проектируемой системы с помощью историй use-case`ов, то флаг ему в руки.
Если же брать в целом то да, несомненно, программист должен уметь читать хотя бы диаграммы классов, деятельности.. ну и, возможно, взаимодействия. Тем более, что в этом нет ничего сложного)


Кстати, когда на яве программил использовали именно такой переход - в нетбинсе UML плагин позволяет строить диаграммы классов из исходников.
А описывать все методы в классе - пусто занятие. Имхо, UML стоит использовать как язык проектирования и взаимодействия на этом уровне. Генерить весь код из диаграмм - замотаешься потом поддерживать актуальность..

Диаграммы классов - вещь хорошая в UML! Использовал для небольшого проекта. Конечно, она помогает, но вот в большом проекте - проще несколько диаграмм набросать на листочке, чем использовать спец. программы. Глазом большую часть охватить даже не удастся.... А вообще вещь очень нужная. Было бы здорово, если бы при программировании любого проекта такие вещи обязывали бы создавать!


Так и не смог полностью разобраться именно в этой диаграмме. Для меня она оказалась какой-то сложноватой. Может быть, объясните вкратце ее работу?

Согласен!

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

Да меня больше интересует какой-нибудь пример простенький (как выглядит на блок-схеме и как на диаграмме действия). Приведите, пожалуйста!
Ну например вычисление факториала (рекурсивная версия и версия с циклом).