_mashuta_Кто что думает об UML? Мода прошла?
Просто IMHO люди, которые с ним игрались (и активно говорили о нём), разделились на 2 категории: тех, кто научился применять его для решения реальных задач (и молча его используют, никого не спрашивая), и тех, кто разочаровался в нём (и тоже молчит). UML не стал серебряной пулей.
А за таинственные диаграммы, описывающие изящные абстрактные конструкции и последовательности, больше никто не платит.
Тем более, что Rational, которая активно пиарила UML и RUP, растворилась в недрах IBM, и пока IBM думала, что делать с этим ПО - у него появились нормальные альтернативы.

_mashuta_Сейчас вождь (слабый, кратковременный) собрался у нас внедрять что-то вроде "использование UML".
Вот я и пытаюсь выработать свое отношение к этой инициативе.
Даже плохой вождь может делать правильные вещи. Другое дело, что взяться он может за UML ради UML. А UML - всего лишь средство, при правильном внедрении и применении помогающее:
- думать от целей пользователя (с помощью UC, хотя сам оперирует со структурой UC, но не их наполнением), постепенно доходя до реализации
- общаться, более-менее однозначным и стандартным образом документировать принятые архитектурные решения, накапливать знания, облегчать ввод новичков в курс дела (если все в говорят на UML хотя бы "со словарём")
- помогать (при помощи обратного инжиниринга) разбираться с древним злом (чужим, брошенным или забытым кодом): видел на практике, если бы не UML и не возможности средства - шиш смогли бы повторно использовать пару мегабайт кода
- сколько-нибудь проектировать, а не сразу кидаться в безумно гибкий "code & fix"
- создавать статические аспекты архитектуры от динамических
- иногда - экономить время на кодировании "скелетов" классов: видел на практике, реально экономило довольно много времени
- упрощать документирование, особенно сертификационное
- поддерживать целостное представление о системе, позволять её разрабатывать после того, как она перестаёт полностью помещаться в голове одного человека.

Возможно, вождь не такой и плохой, просто пытается сам разобраться, что программисты накодировали, а потом помочь самим программистам это осознать? А то, что не рубит с плеча что и кого ни попадя, это вовсе и не слабость?

_mashuta_<...>
Я не сомневаюсь в ценности UML. Но вот вопрос - насколько велика эта ценность?
Мне почему-то кажется, что близка нулю.
<...>
Ценность ООП, СУБД, компьютера, ножа и мяса близка к нулю. Можно насоздавать багов, потерять данные, уронить на ногу, порезаться, отравиться. Если не уметь готовить :) .

MasterZiv<...>
Я использовал в примерно 3 проектах. На С++.
Со сквозной кодогенерацией, полностью сделанный проектов было 2 на самом
деле. Я бы делал так ещё проекты, да вот только не пишу я сейчас на С++.
А для CLOS-а генератора нет.
Я - в трёх, один на PHP + PostgreSQL:) , один на C#.Net + MS SQL 2000, один гетерогенный (J2EE + C++ + Hibernate). Кодогенерация была частичной.

MasterZiv
Использовал я в основном диагаммы классов (для генерации кода и документации),
диаграммы взаимодействия и последовательностей - для пояснения и проектирования.
Ну и, конечно, диаграммы компонент.

Использовали всё, deployment - в меньшей степени.

MasterZiv
Это - очень полезная штуковина, потому что С++ -- довольно громоздок
и ты не видишь за кучей кода сути. Проектировать на UML при этом удобно,
и case делает за тебя много черновой работы.

+1, это свойства всех языков

MasterZiv
Да, использовалась rose 2000. C++ classic plugin.
Он самый сложный, но других - не хватает для работы.

Использовали Rational Rose 2003, затем Sparx Systems Enterprise Architect 6.5 - 7.1 как есть.

MasterZiv
все остальные диаграммы очень и очень абстратны, они
скорее - картинки.

Помогают думать и договариваться.

MasterZiv
И совсем оцтой - я считаю - это use case diagrams.
Я их не понимаю и не знаю , нафига они вообще нужны.
Они-то и были на самом деле "самой проталкиваемой" штукой.
Использовали их чуть ли не больше всего.

Есть цели пользователя. Есть последовательности работы с системой, которыми он может этого добиться. Они описываются на диаграмме UC (структура - на диаграмме, и надо поменьше мудрить, текст - в комментариях). От этого строится динамическая модель работы системы, и только затем - статическая.

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

Если Вам интересно, как использовать UC - почитайте Коберна.