UML

[metaclass]

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

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

Comments

[dizel-by.livejournal.com]

Такой же опыт. Пробовал - не получилось.

[slach.livejournal.com]

постоянно использую PowerDesigner для Physical Model и Enterprise Architect для Sequence и Use Case диаграмм

Class Diagramm действительно часто рисуем на бумаге и очень упрощенно =)

все равно большинство UML инструментов расчитаны на жесткий RUP, когда 80% проектирование (которое часто заменяется ватокатанием ;-)

[kkirsanov.livejournal.com]

Пробовали, отказались.
Видимо проекты небольшие.

Когда припрёт - конечные автоматы рисуем.

[qehgt.livejournal.com]

Пробовали, не понравилось.

[rssh.livejournal.com]

Использую более или менее регулярно
В основном - для того что бы кому0-то чего0то покащать (изи самому себе)
Соотвественно и проектируется не все, а фрагмент нужный в разговоре или такой что нужно на него смотреть

Тулзы типа Rational Rose и ArgoUML страшно неудобны. UMLet более или менее работает.

[pascendi.livejournal.com]

UML хорошо использовать в составе технологии, например, в Rational. Нотация, впрочем, не самая наглядная и не самая удобная. Мне больше нравится IDEF.

Но на работе -- использовал. И знаю компанию, в которой на базе UML/Rational построена автоматизированная технология генерации приложений. Работает уже около 10 лет.

[demiurg.livejournal.com]

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

на стадии дизайна пробовал "думать в УМЛ", но оказалось жутко неэффективно в т.ч. и из-за "медленных", не успевающих за мыслью, инструментов: пока "набьёшь" класс свойствами и методами через многочисленные менюшки/диалоги, уже забудешь, чего вообще хотел сделать-то.
кстати, и TDD столкнулось практически с такой же проблемой.

для меня лично оказалось намного удобнее на стадии дизайна просто выписывать интерфейсы классов в одном файле прямо в синтаксисе языка, который в данный момент используется для разработки, и потом уже "играться" с ними там же.
всё равно ведь, когда рассматриваешь систему, перед глазами внутри видишь строчки кода, а проскроллив разок-другой такой файл на экране, в голове сразу же возникает полное видение системы. удобно, просто, эффективно =)

[volodymir-k.livejournal.com]

Показать Заказчику свою крутизну, в основном. Что полезно, вот наваял схему БД, оно сгенерило. Больше пользы не заметил.

[max-posedon.livejournal.com]

Не пользуем, совсем.

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

[vp.livejournal.com]

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

[metaclass.livejournal.com]

Пользуются ровно в том же стиле, что и мы - на бумаге рисовать части систем.

[aamonster.livejournal.com]

Не использую:
1. Я все эти красивые диаграммы плохо воспринимаю (не визуал ни разу).
2. Простого псевдокода на листе бумаге (или на экране) помещается больше, чем диаграмм.

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

[metaclass.livejournal.com]

Да. А я почему-то думал, что это один я не могу с этой дурью справится. Оказывается, никто не использует :)

[archangel-rhn.livejournal.com]

Нарисовал достаточно диаграмм в Rational Rose. Знаком с Enterprise Architect. Наглядность несомненно присутствует. Однако, на эту рисовалку приходится затрачивать много времени, что несопостовимо с тем же кодингом.. Наглядную бизнес-логику для большого проекта представить в UML трудно. Диаграммы могут получиться слишком громоздкими. В особенности: диаграмма классов, последовательности, деятельности. Большие программы стоит разбивать на подпрограммы и для каждой в отдельности рисовать эти схемки.. Иначе можно тронуться.
Код, генерируемый соответствующими программами, проточен вдоль и поперек червями-мутантами.

Для примера, как могут выглядеть отдельные диаграммы для небольшенькой программы (в пару тысяч строк):
деятельности (http://keep4u.ru/imgs/b/080707/70/70e447990db254ae29.jpg)
последовательности (http://keep4u.ru/imgs/b/080707/89/89341bb205cbc4d432.jpg)
классов (http://keep4u.ru/imgs/b/080707/0b/0b34d7f9e238101d02.jpg)

[blackyblack.livejournal.com]

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

UML

[boriskins.livejournal.com]

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

Вы какой методологией разработки ПО пользуетесь?
Вот две кардинально разные методологии:
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)

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

Re: UML

[metaclass.livejournal.com]

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

Re: UML

[boriskins.livejournal.com]

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

Re: UML

[metaclass.livejournal.com]

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

Re: UML

[boriskins.livejournal.com]

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