UML - хорошо

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

> Используете ли UML? В какой степени, на каких проектах (язык, размер команды)? Какие типы диаграмм чаще всего? Какой инструмент?

UML не нужен, ибо есть бумага, карандаш и голова (с мозгами).

>UML не нужен, ибо есть бумага, карандаш

на бумаге тоже УМЛ бывает :)

В проектах с активным использованием ООП... Но щас, как помню, многоуровнеывые иерархии никому в работе нафиг не вперлись (ну, кроме разве, разработки «кошерных фреймворков»)... А так.. активное юзание дизайнпаттернов сводит развесистость «в ноль» :) и делает использование UML ненужным :-), мол, словарь паттерном емче, а в юмл вроде как не поддерживается. :)

1. UML нужен чтобы добротно освоить паттерны ООП. Когда их освоил, UML «превращается» в «ассемблер», шибко уж «низкоуровневый». 2. UML неплох для реинжиниринга. Когда чужие либу, фреймворк требуется «разобрать», «перебрать» до фундамета, чтобы вникнуть. 3. Ценны для меня диаграммы поведения и взаимодействия. Рисую карандашиком, потому что проще черкать и переделывать. А когда уяснил, то можно и нарисовать в Argouml, хотя обычно и не имеет смысла. Потом код быстро уйдет от общего вида.

Очень верно схвачено: - Тебе, чтобы читать код, нужна документация? Прости – какая? - Ну, там, диаграммы классов, например. - У нас была одна, вроде, составленная лет пять назад. Она сейчас, мягко говоря, не соответствует действительности. ...

Диаграммы не стоят ничего, ценны мыслительные процессы, происходящие у тебя в голове в процессе их составления «Читай код» gaperton.livejournal.com/32772.html

ЮМЛ действительно нужен только тем джедаям, кот освоили проектирование.

т.е. , освоившие паттерны - джедаи? :)

С начало все реализуется на UML, потом все это исследуется, а только потом приступать за написания кода. Если поступить иначе, потратите лишние время, + большая вероятность что проект очень рано умрет из-за того, что в нем уже ни кто не может разобраться.

Но для этого как минимум нужно знать сам UML, паттерны, и какой-то SDLC.

Удачи)

мну тоже так думал, пока очередной проект не показал, что нарисованное мною в ЮМЛ больше всего похоже на скромное недоразумение. более того, когда проект готов, я с трудом представляю как это отразить в ЮМЛ чтб оно было похоже на правду.
впрочем, быть может я просто не умею пользоваться этим инструментом.

Не используем... в проекте ~100 человек, из них процентов 70 дизайнеры, языки разработки C, Erlang... UML не нужно? :)

Активно использовали диаграммы вариантов использования, активности и состояний для написания ТЗ и согласования его с заказчиком.

По сути диаграммы активности — это старые добрые блок-схемы, доступные простым смертным еще со школьной скамьи, а графика намного компактнее, чем километры текстов.

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

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

Правда, больше 80% в такой форме согласовать не удавалось, где-то с середины проекта все, включая заказчика уже понимали модель без костылей, диаграммы старели и не поддерживались.

А новичкам для вхождения в проект хватало и устаревшей документации.

> согласовать стыки БД-сервер-клиент

Кстати, не только согласовать, но и оттрассировать, причем не только в этой триаде, но и вплоть до интерфейса пользователя.

>Правда, больше 80% в такой форме согласовать не удавалось

Не удавалось из-за лени разработчиков после

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

или программа не укладывалась в диаграммы?

Лень разработчиков, конечно же, но лень рационально обоснованная. Тут действует принцип «документ без читателя не нужен».

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