Средства рисования UML

← →
Суслик © (2005-12-30 11:13) [0]

Добрый день. Понимаю, что не про НГ, но все же :)

Я, помнится, как-то пытался найти рисовалку UML. Искал долго - либо полная ерунда, либо тяжелая система (типа Together и пр.).

Наконец нашел: www.umlet.com.

Проще и лучше я не видел. Умеет рисовать диаграммы и сохранять их в различные графические форматы. Очень проста в использовании. Вроде как фришная.

Для документирования кода лучшего не придумаешь.

PS. Это для тех, кто также как хочет документировать свой проект.

PSS. Требует java 1.5. С java.sun.com можно скачать redistributable. Где точно, не знаю - сами найдете :)

← →
Sergey Masloff (2005-12-30 18:56) [1]

Блин ну а Visio-то? Тем более там твоя диаграмма доступна через объектную модель. У нас есть такая фича - юзер в UML в Visio рисует схему прохождения документа - там кто его согласовывает кто что а потом это автоматом обрабатывается генерируется скрипт в Оракл и все начинает работать. По-моему весчь офигительная (возможность доступа к элементам нарисованой диаграммы через объектную модель). Очень сомневаюсь что "твоя" рисовалка это умеет и тем более что она умеет это вобщем-то стандартным способом (ну ИМХО следует признать что офисный VBA де-факто это стандарт)

← →
iZEN_ (2005-12-30 20:34) [2]

Sergey Masloff, за Visio нужно ПЛАТИТЬ.

← →
Sergey Masloff (2005-12-30 20:47) [3]

iZEN_ (30.12.05 20:34) [2]
>Sergey Masloff, за Visio нужно ПЛАТИТЬ.
И что? Наш продукт стоит миллионы долларов. Неужели цена десятка лицензий на VISIO имеет хоть какое-то значение?

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

← →
Суслик © (2005-12-30 22:38) [4]

В тот то и фишка, что она ничего не умеет.
Я это говорю не для тех, кто хочет что его рисовалка была не просто рисовалкой.

Это именно рисовалка. Они тупая. Но рисует классно :)
Для документации самое оно :)

← →
Суслик © (2005-12-30 23:09) [5]

Я тут подумал и решил объяснить свою позицию.

Я знаю, что UML деклрируется в последнее время как case средство разработки. Together, твой vision, rational и пр. (я их видел как минимум еще 2-3, сейчас лень названия перечислять, т.к. надо вспоминать).

Дело в том, что иногда нужно просто УДОБНОЕ средство рисования с целью документирования. Либо как тех документация ДО разработки, либо как тех документация ПОСЛЕ разработки. Я много пересмотрел средств. Крайне внимательно (около 2 недель) изучал together. Перерыл еще много средств. Результат - либо сложный большой продукт, либо Ацтой.

UML действтиельно можно трактовать как средство разработки. Я рад в твоем лице видеть пример такой трактовки. Все же я считаю, что роль UML изрядно переоценена. Вернее даже не роль, а область применения.

Мое мнение, что UML the best средство КОНЦЕПТУАЛЬНОГО документирования кода. Т.е. не методов, параметров, области видимости и пр. А средство визуально объяснить другому человеку концепцию твоего проекта и кода. Да не только другому, да и себе тоже. Посмотреть на картинку и сразу вспонить, какую идеологию ты закладывал в ту или иную архитектуту, библиотеку или пр.

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

← →
Игорь Шевченко © (2005-12-30 23:22) [6]

Суслик © (30.12.05 23:09) [5]

С наступающим!

Скажи, а ты действительно веришь в то, что UML является той панацеей, ради которой стоит искать средства рисования для него ?

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

Если честно, то я для себя (прошу не пинать) не вижу особой необходимости в визуальных средствах проектирования. Да, оно красиво, для менеджера из стишка Леонида Каганова, самое оно, чтобы было по чему водить, но для программиста или для команды программистов я честно не вижу, как может такое средство пригодиться.

Ежели кто объяснит, буду только рад.

← →
Sergey Masloff (2005-12-30 23:23) [7]

Что-то не вижу особых удобств использования UML для документирования кода. Более того, можете пинать но считаю вообще документирование кода бессмысленным - все равно он имеет свойство меняться и или нужны будут неимоверные усилия на поддержку актуальности документации либо будет то что везде и всегда мы имеем возможность наблюдать.
Я сторонник документирования только ключевых моментов. Можно нарисовать на доске во время обсуждения потом сфоткать на цифровик и JPEG кинуть куда-то в папку с документацией.
Впрочем может и получится у тебя. Потом расскажешь если будет успех ;-)

← →
Суслик © (2005-12-30 23:31) [8]

Рассказываю (пример).
Я насмотреля год назад на swing (библиотека java).
Подня от тудова много идей.
Сами знаете, что наследование нынче не модно. Java есно имеет наследование. Но одно таки не так часто исползуется. Они больше агрегацией работают.
Ну так вот. Натянул я оттуда фишек (не жалею). Получается достаточно гибко. Но обозревать агрегацию все-таки сложенее, чем сквозное наследование. Диаграмма классов + диаграмма последовательностей (в редиких случаях) + текстовое описание позволяют легче думать, когда нужно развивать библиотеку или рефакторить. Посмотрел, почитал - в памяти очень неплохо всплывают концепции, положенные в основу библиотеки.

Вобщем вот.

Как говорил Ларман - меньше диаграмм больше текста. Согласен текст - главное. Но рисуночнки приносят крайне полезную помощь документации, как достойное дополнение текста.

← →
Игорь Шевченко © (2005-12-30 23:37) [9]

Суслик © (30.12.05 23:31) [8]

> Сами знаете, что наследование нынче не модно.

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

> Диаграмма классов + диаграмма последовательностей (в редиких
> случаях) + текстовое описание позволяют легче думать, когда
> нужно развивать библиотеку или рефакторить

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

← →
Суслик © (2005-12-30 23:39) [10]

а ты попробуй :)

приведеное мною средство некорое время используется мною как средство анализа для посроения модели as is. Модель to be строится легче. Для меня, естественно :)

← →
Игорь Шевченко © (2005-12-30 23:47) [11]

Суслик © (30.12.05 23:39) [10]

> а ты попробуй :)

А ты думаешь, не пробовал ? Ошибаешься. Модель, требующая рефакторинга, в виде диаграммы выглядит еще более неаппетитнее, чем в виде кода, к тому же занимает много места и в ней трудно ориентрироваться.

Кстати, я использовал кроме всего прочего, ESSModel, бесплатно и со вкусом.

← →
Piter © (2005-12-30 23:54) [12]

Суслик © (30.12.05 23:31) [8]
Я насмотреля год назад на swing (библиотека java).

ой, а я думал, что свинг - это немного другое :)

Суслик © (30.12.05 23:31) [8]
Сами знаете, что наследование нынче не модно

а можно ламеру пояснить? Что подразумевается под наследованием? Наследование от другого класса?
Как это может быть НЕ модным, если это принцип ООП?

← →
Gero © (2005-12-30 23:55) [13]

> ой, а я думал, что свинг - это немного другое

А кто говорит, что это другое? Групповая разработка программ на java — чем не свинг?

← →
Суслик © (2005-12-31 00:01) [14]

2Piter
Общая тенденция (да хоть тот же gof глянь) - наследование для полифирмизма (т.е. наследования интерфейса), но не для наследования реализации.

2ИШ
Т.к. ты не проникся, то думаю, что ты слишком серьзезно подходил к документации на UML. На нем имхо нельзя построить полноценную доку. Это всего лишь приятное (иногда сильно приятное) дополнение к тексту. имхо, есно.

Кстати по поводу неприглядности модели до рефакторинга. Он (рефаториг) многогранен. Не обязательно имхо к нему общаются дабы улучшить плохой код. Часто он нужен, дабы улучшить хороший код дабы дать перспективу еще большего улучшения кода. Если бы к рефакторингу обращались только в случае плохого кода, то весь extreme programming отцтой, а Бек - ламер. Если помнишь реализация с последующим рефакторингом у них одна из главных идей.

В моем случае диаграммы помогли создать платформу для дальнейшего развития основываясь на вполне удачном коде.

← →
Piter © (2005-12-31 00:02) [15]

Gero © (30.12.05 23:55) [13]

теперь понял...

Ну Суслик... ну негодник...

← →
Piter © (2005-12-31 00:04) [16]

Суслик © (31.12.05 0:01) [14]
Общая тенденция (да хоть тот же gof глянь) - наследование для полифирмизма (т.е. наследования интерфейса), но не для наследования реализации

не осилил :(

Это как? Наследуется только интерфейсная часть? :)

Или наследуется только от абстрактных классов?

А что же тогда в качестве альтернативы наследованию предлагается?

← →
Игорь Шевченко © (2005-12-31 00:08) [17]

Суслик © (31.12.05 00:01) [14]

Бек, разумеется, не ламер. Но я его не понимаю. То ли он так изъясняется, что мне такой уровень недоступен. Кроме того, я стараюсь руководствоваться одним простым правилом - Марксизм не догма, а руководство к действию. Это я к тому, что и у меня кое-какой опыт, сын ошибок трудных, имеется, и все течения я стараюсь преломить через его призму.

← →
Суслик © (2005-12-31 00:19) [18]

2Piter. Поверь, я бы очень хотел рассказать что я по этому поводу думаю, но не могу - жутко лень. Это надолго, нужны хорошие примеры и все такое :)

2ИШ. Что именно не понимаешь? Мне нравится его принцип (далеко не всегда получается, а жаль) - реализовывать решение, которое позволит реализовать все как можно быстрее. Также мне нарвится принцип - если ты чего-то не учел на этапе реализации, это всегда можно поправить потом в ходе рефакторига работающего кода.

← →
Игорь Шевченко © (2005-12-31 00:27) [19]

Суслик © (31.12.05 00:19) [18]

> Что именно не понимаешь?

Объяснения для дебилов не понимаю. Фраз вроде: "мантра программиста - красный, зеленый, рефакторинг".

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

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

← →
Суслик © (2005-12-31 00:32) [20]

Ты знаешь, Игорь, я так "живу" уже не первый год. Я не смог (а кто бы смог?) учесть всего. Приходилось дорабатывать. Это имхо нормально.
Проект у меня тоже недецкий. Конечно, всем бы хотелось разработать проект на все жизнь - написал раз, ем и сейчас. Но ты это можешь? Если да, то ты просто приврешь. Такого не бывает. Жизнь изменчива, а ты вряд ли принимаешь бизнес-решения. Так что - не все зависит от проекта, на этапе разработки можно всего просто не знать.

← →
Sergey Masloff (2005-12-31 00:38) [21]

Суслик © (31.12.05 00:32) [20]
>Так что - не все зависит от проекта, на этапе разработки можно всего просто не знать.
И? В смысле что дальше?
Кстати, никогда не было чувства что многие фичи в проекте оказались ненужными а сделаными из мысли: а не попробовать ли вот еще так... а чо - и универсально...
Я такое уже не раз видел когда обалденно широко задуманные и реализованые решения сначала подолгу просто не использовались а потом выяснялось что для вот конкретно понадобившейся фичи механизм не подходит. Вернее, подходит но настольно запутанные ходы получаются... И на переписку. А можно по простому было сделать за полдня и забыть. А когда понадобится другое это поиксовать и за другие полдня другое написать. На самом деле иногда это работает.

← →
Игорь Шевченко © (2005-12-31 00:40) [22]

Суслик © (31.12.05 00:32) [20]

> Конечно, всем бы хотелось разработать проект на все жизнь
> - написал раз, ем и сейчас. Но ты это можешь? Если да, то
> ты просто приврешь. Такого не бывает. Жизнь изменчива, а
> ты вряд ли принимаешь бизнес-решения. Так что - не все зависит
> от проекта, на этапе разработки можно всего просто не знать.
>

С этим как раз никто не спорит. Я спорю с тем, что на это надо класть в расчете на то, что в процессе изменения требований ты легко и просто все отрефакторишь. То есть, с тем самым принципом Бека.

← →
Суслик © (2005-12-31 00:40) [23]

Сергей, я таки не понял, ты мне возражаешь или нет?
Я в общем-то тоже самое говорю :)

← →
Суслик © (2005-12-31 00:42) [24]

2ИШ
У него несколько другой принцип. Проверь. Он говрит, что нужно писать максимально просто. Это не значит плохо. Это значит просто. Другой вопрос, что он же утверждает, что для такой простоты нужна нехилая квалификация. Т.е. для того, чтобы следовать его принципам нужно быть профи, и есно отличасть случаи, когда можно сделать не очень хорошо, а когда очень хорошо.

← →
Sergey Masloff (2005-12-31 00:43) [25]

Суслик © (31.12.05 00:40) [23]
>Сергей, я таки не понял, ты мне возражаешь или нет?
>Я в общем-то тоже самое говорю :)
Двойственную я позицию занимаю. У меня нет однозначного ответа как правильно. Был бы я б давно писал книжки а вы с Игорем щаз бы обсуждали не что там банда четырех и бек пишут а что я ;-)

← →
Суслик © (2005-12-31 00:48) [26]

:)
У меня в действтиельно тоже двойственная. Иногда я понимаю, что слишком хорошо что-то написал. А иногда понимаю, что сделал это не зря. Пример, когда не зря. Я год назад сделал бибилотеку создания excel в родном бинарном формате - за год (используется постоянно) ни одного нарекания. С другой стороны, я в свое время угробил массу времени на создание и документирование библиотеки специфичных для нашего видения бухгалтерии функций. Мог бы с тем же успехом пользоваться copy, length и т.д. :)

← →
Игорь Шевченко © (2005-12-31 00:50) [27]

Суслик © (31.12.05 00:42) [24]

> Он говрит, что нужно писать максимально просто

Не согласен со словом "максимально". Писать надо просто, но тем не менее, от максимальной простоты получается Hello, world, нафиг никому не нужный.

← →
Суслик © (2005-12-31 00:51) [28]

2иш
точно подмечено, принимается
был не прав

← →
Alexis © (2006-01-01 21:39) [29]

> Добрый день. Понимаю, что не про НГ, но все же :)
>
> Я, помнится, как-то пытался найти рисовалку UML. Искал долго
> - либо полная ерунда, либо тяжелая система (типа Together
> и пр.).
>
> Наконец нашел: www.umlet.com.
>
> Проще и лучше я не видел. Умеет рисовать диаграммы и сохранять
> их в различные графические форматы. Очень проста в использовании.
> Вроде как фришная.

O4en rekomenduju poprobovat Dia (jest dlia Win i Linux) (open-source)

Po mojemu gnome.org/dia

← →
Джо © (2006-01-01 23:04) [30]

> [21] Sergey Masloff (31.12.05 00:38)

Да, это же самое, собственно твердит и Макконнелл и иже с ним. Как правило, программисты очень плохо угадывают, какая будущая функциональность может быть востребована. Мой скромный опыт говорит то же. К сожалению, это именно так, согласен.

← →
Суслик © (2006-01-02 01:06) [31]

> Alexis © (01.01.06 21:39) [29]

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

Piter © (31.12.05 0:04) [16]
Это как? Наследуется только интерфейсная часть? :)

То есть вместо
type TParent = class procedure Test; end; TChild = class(TParent) procedure Test2; end;
ты должен написать
type IParent = interface procedure Test; end; IChild = interface procedure Test2; end; TParent = class(TObject, IParent) procedure Test; end; TChild = class(TObject, IParent, IChild) // наследования классов нету property ParentImpl: TParentImpl read FParentImpl implemnts IParent; procedure Test2; end;

IParent = interface procedure Test; end; IChild = interface(IParent) procedure Test2; end;

Вообще-то под eclipse есть граф.редактор UML(не помню как зовется), но он шареварный. Но зато напрямую понимаются файлы из Rational Rose и можно прикрутить кодогенерацию.
Мне в январе как раз придется начать новый проект, который должен понимать понимать Rational Rose модели и генерить файлы для Java и C/C++.

← →
Sergey Masloff (2006-01-02 09:22) [35]

Alex Konshin © (02.01.06 03:52) [34]
>начать новый проект, который должен понимать понимать Rational Rose >модели и генерить файлы для Java и C/C++
Rose это же умеет сама?

То, что она умеет нас и не устраивает. Собственно, нужно переписать то, что делалось в Rose.

← →
Sergey Masloff (2006-01-02 12:35) [37]

Alex Konshin © (02.01.06 12:12) [36]
Понятно. Неслабо. А какая, по прикидкам, трудоемкость этого? Честно говоря, я даже приблизительно оценить не могу. Если не секрет?

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

Насколько я понимаю, нужно по сути сделать свой плагин в эклипс. Вроде как там уже есть поддержка UML, нужно только переписать генерацию. Я честно говоря уже и не помню точно, я где-то осенью оценивал трудоемкость этого. Сейчас уже напрочь не помню, что там к чему.
У нас тут есть какой-то свой язык описания программных интерфейсов (что-то типа IML, даже синтаксис практически один в один). Есть свой компилятор, который генерит Java, С/С++ код. Эти интерфейсы можно смотреть и редактировать в Rose, но вот генерация в Rose написана на его бейсике и это никого не устраивает, т.к. поддерживать это очень трудно. По-моему и от этого подобия IML отказываются в пользу редактирования диаграм. Вот и хотят от меня, чтоб я это все сделал на Java в eclipse, тем более, что и сам IBM движется в этом направлении, например, модели Rose уже там понимаются. Боюсь сейчас ошибится, но вроде EMF этим занимается. Есть и 3rd party плагины для редактирования UML схем (кстати, то, что приведено в оригинальном сообщении - тоже плагин для eclipse, но не тот, что смотрел я в свое время).

Короче, сексуальные развлечения для меня уже запланированы начальством :)

← →
iZEN_ (2006-01-02 18:11) [39]

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

iZEN_ (02.01.06 18:11) [39]
> Alex Konshin © (02.01.06 15:54) [38]
> Смотрели ArgoUML и Poseidon, основанный на нём, (www.gentleware.
> com)?

Я смотрел Omondo.
http://www.eclipseuml.com/
У них есть и free версия.

Вопрос, скорее к Алексу Коншину.

Я понимаю, что ты изрядно силен в UML (раз пользуешься диаграммами, основанными на нем).

Я понимаю, что UML это хорошо. Но я понимаю, что он хорош, только в той части, которую я понимаю. Его нотация (как 1.3, 1.4, так и 2.0) для меня все-таки не до конца остется ясной. Я старался читать разные трактовки нотации: Фаулера, Буча и пр.

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

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

Суслик © (03.01.06 23:50) [42]

да ясен пень, теория - это одно, а когда видишь практические примеры - совсем другое.

Только, имхо, удачный пример может быть только на очень сложном проекте, фиг кто будет рассказывать, это уж Алекс своим русским рассказывает :)

http://uml.ru/

Средства рисования UML Найти похожие ветки