metaclass

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

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

Flat | Top-Level Comments Only

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

Народ, вот что хочу сказать.

Вы какой методологией разработки ПО пользуетесь?
Вот две кардинально разные методологии:
1. Карандаши/ластики/бумажки - Extreme Programming - UML практически не нужен.
2. Rational/Architect - RUP - без UML-а никуда, ибо все нужно задокументировать.

Есть другие, например Agile - там можно диаграммки порисовать при желании, но никак не в Rational Rose - там много лишнего для данной методологии и действительно, глупо тратить время на изучение и следование RUP, используя Rational Rose, если вам все это не нужно. Здесь лучше найти попроще и покрасивше редактор. Недавно обнаружил клёвую опенсорсную софтину: http://staruml.sourceforge.net/en/ (http://neill-solow.livejournal.com/2667.html)

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

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

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

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

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

UML

no subject

UML

Re: UML

Re: UML

Re: UML

Re: UML