вышел Umbrello UML Modeller 1.4.1

>отличной программы для построения UML диаграмм

ну скажем так... какая уж есть :)

а шо это ваще такое? для чего оно надо?

> а шо это ваще такое? для чего оно надо?

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

Подход, в принципе, здравый, но неуниверсальный.

>Подход, в принципе, здравый, но неуниверсальный.

тут могу не согласиться: его проблема в том, что он слишком универсальный :)

Далеко заходить и не надо, тем более что это одна из главных задач юзанья UML - генерировать готовый код.

http://old.sgu.ru/users/matmodel/tutorial/tutor4/tutor4.htm

если он такой умный то возникает вопрос, а проектировать различные БД он случаем не может? ;-)

или генерировать sql запросы...

Это вам не надо, это надо "жавабыдлокодерам", 
кажется вы так их называете .... 

:) Это надо всем! Вещь полезная - однозначно.

-- boshik

>:) Это надо всем!

Мне не надо.

>Вещь полезная - однозначно.

Бесполезная. UML - средство для распальцовки и пускания соплей о крутезне. kernel, kde, postgresql, ... писалось без uml.

Просмотр ТВ в Linux. XdTV 2.2.0 http://xawdecode.sourceforge.net/htmlpageUS/indexUS.shtml

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

UML нужен, пока существуют Java, C#, C++ и пр. и на этой #$йне по воле {работодателя,клиента,чёрта} приходится писать. Если уж приходится запихивать идею в рамки примитивной message-passing объектной парадигмы, иногда требуется эту идею в запихнутом состоянии как-то проиллюстрировать, для проектной документации и пр. Вот для этого UML и нужен. А чтобы генерить код из более высокоуровневого представления, существует defmacro ;-)

>были "умлы" и до умла

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

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

>UML - для моделирования бизнеса и ОО проектирования, всё.

Правда? А каким образом, например, state/activity-диаграммы завязаны на OOP? Если ты кроме диаграммы классов (одна из самых бесполезных, имхо) ничего в UML не видел, это не значит, что там больше ничего нет. :)

Частично, конечно, согласен - UML для OOP в первую очередь разрабатывался.

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

Приходится на работе иметь дело с UML. Описание при помощи UML - не видел ничего более бесполезного и неподходящего. Описания получаются менее понятными, чем исходный код. Нет, конечно, если взять какой-нить учебный пример, чуть посложнее "Hello, World!!!", то все просто замечательно. Всякие там activity-диаграммы и пр. Но если взять что-то близкое к реальной задаче, то получается полная лажа. Неприменимо к жизни.

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

Ну, например, если проектируешь веб-приложение (да и в обычном, наверное, тоже применимо) state/activity неплохо помогают.

>ничего в UML не видел, это не значит, что там больше ничего нет. :)

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

>видел ;) ещё я видел дублирующие друг друга кооперации и последовательности.

sequence диаграммы и collaboration диаграммы вообще изоморфны. В Rational Rose по кнопке F5 можно из одной другую сочинить. :)

А насчет состояния - ну на то они и state/activity. Остальные виды диаграмм тоже можно использовать, но пользы от них меньше. sequence/collaboration уже на передачу сообщений завязаны.

А, ну еще диаграммы компонентов полезно в документацию вставлять. Чтоб видно было что вообще присутствует. Плюс диаграммы развертывания, но их лучше все-таки в чем-то менее фформальном рисовать, например, в Visio.

>Бесполезная. UML - средство для распальцовки и пускания соплей о крутезне.

Я думал ,что для этого используется lor и nickname logIN ;-)

При разработке больших OOP программ очень полезно описывать поведение системы на UML
Сложные иерархии наследования (там где в голове все целиком держать уже не удаться)
Объекты с сложными состояниям и условиях перехода в состояние(лазить каждый раз в код долго и не эффективно (если вам за время просиженное на работе конечно не платят ;-) )
Про use case'ы вообще молчу (для user story очень удобно).
Лично я ещё использую Delpoyment диаграммы - так как разрабатываю server side решения.

>kernel, kde, postgresql, ... писалось без uml.
При разработке KDE применялся UML

Kernel писан на не OOP языке.

PS В руках аборигена микроскоп – молоток.

>Сложные иерархии наследования (там где в голове все целиком держать уже не удаться)

Гон. У класса есть лучшее описание в .hxx файлах, реализация никого не интересует - это черный ящик, который выполняет поставленную перед ним цель. Для наследования тем более uml не нужен, так как для описания наследованных функций используется автоматизированный софт (doxygen, к примеру).

>При разработке KDE применялся UML

Чем подкрепишь свои слова? Я КДЕ использую с первых версий, читаю ихние ml, но об UML не слышал. Кинь ссылку, может чего пропустил...

>Гон. У класса есть лучшее описание в .hxx файлах

Лично мне UML диаграммы нагляднее. .hxx сложнее глазами парсить, плюс несколько файлов одновременно в памяти держать.

> Гон. У класса есть лучшее описание в .hxx файлах
ага, а если их 500 и тебя интересует общая структура приложения то reverse engineering в UML очень полезная штука
> doxygen, к примеру
не замечал что он еще и диаграммы рисует

> doxygen, к примеру

не замечал что он еще и диаграммы рисует

страсненькие, но рисует :)

// wbr

> А чтобы генерить код из более высокоуровневого представления, существует defmacro ;-)
а всегда ли нужно изобретать это высокоуровневое представление ? ИМХО UML метамодель и ее механизмы расширения для многих задач подходят намного лучше

>Бесполезная. UML - средство для распальцовки и пускания соплей о крутезне. kernel, kde, postgresql, ... писалось без uml.

:) Как тебе уже сказали - это все делалось не на ООП языках.

На самом деле никакой распальцовки нет - если у тебя в проекте 1000 сущностей то их иногда просто нужно ВИДЕТЬ. Опять-же коллективная разработка и т.д.

>плюс несколько файлов одновременно в памяти держать.

А может вообще не думать? Так проще.

сударь, в одиночку тока графические монтровалки для хардов пишут ;)

Не вижу логики. Я всего лишь пытаюсь побороть неприятное правило 7+-2. Держать в памяти 5 файлов - увольте. Я не гений, в конце-концов.

>>Сложные иерархии наследования (там где в голове все целиком держать
>>уже не удаться)

>Гон. У класса есть лучшее описание в .hxx файлах, реализация никого не >интересует - это черный ящик, который выполняет поставленную перед ним >цель. Для наследования тем более uml не нужен, так как для описания >наследованных функций используется автоматизированный софт (doxygen, к >примеру).
Во умарил иерархии наследников в .hxx файлах ))))


>>При разработке KDE применялся UML

>Чем подкрепишь свои слова? Я КДЕ использую с первых версий, читаю ихние ml, но об UML не слышал. Кинь ссылку, может чего пропустил...
Звучит как
- того чего я не видел - нет ))))

А на C++, C#, Java можно пользоваться ООП без UML => UML в топку,
А ядро написано не не ООП языке => ООП в топку,
А самые узкие куски ядра написаны на асме => С в топку,
А когда то не было асма и программы писали сразу в двуичном виде => Асм тоже в топку.

Нету никакого UML, нету java, нету ООП,
идите рубите лес двуручными пилами ....

>сударь, в одиночку тока графические монтровалки для хардов пишут ;)

Причем тут в одиночку или нет? Чтобы писать не в одиночку, уже давным давно придумана документация и коментарии в коде.

>Во умарил иерархии наследников в .hxx файлах ))))

Читай выше - про иерархию тебе расскажет doxygen, к примеру.

>Звучит как - того чего я не видел - нет ))))

Звучит так, как будто ты просто языком чешешь, без всяких аргументов. Пость ссылку на то как KDE'шники используют UML или возьми свои слова обратно и заткнись до лучших времен.

> Бесполезная. UML - средство для распальцовки и пускания соплей о > крутезне.

О, да! Настоящие бравые парни даже веб браузят телнетом, а о содержании картинок в GIF догадываются, просматривая их в hexedit. Ведь браузер -- это всего лишь средство представления той же самой информации в другом, более графическом виде, а следовательно, распальцовка и полный сакс! А главное, что ПАНАСТАЯЩИМУ КРУТЫЕ ПАЦАНЫ никогда не позволят себе взглянуть на мир иными глазами, потому что на свете существует всего два мнения: их и неправильное.

Да... Какое-то засилие луддитов на ЛОРе. Темные века настали в линукс-мире, чернь необразованная изо всех щелей прет.

Грустно это все...

> Кроме ОО есть ещё не мало архитектур... кернел и постгрескуэл ваще сюда мало лепятся

Я тут человек левый ;), но, вообще-то, объектно-ориентированные программы можно писать на любом языке. И из того, что в ядре нет двух крестов, не следует отсутствия в нем объектной модели. Так же, как, и, например, в GTK.

Генерить "это" из UML, конечно, бредово, а вот документировать на нем зачастую возможно и полезно.

>Генерить "это" из UML, конечно, бредово, а вот документировать на нем зачастую возможно и полезно.

Только при этом часто оказывается, что излишняя формальность - это минус , поэтому Visio даже лучше подходит :)

я про язык ни слова не сказал ;)

это был вопрос к автору поста :),
в том плане что doxygen генерит еще и графическое представление, а не ограничевется pretty print-ом .hxx

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

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

К тому же UML по хорошему не зависит от языка. Скажем я пишу на Python/PHP/C++/Java, я могу создать модель одну приложения в UML использовать ее для написания приложения на любом языке. Скажем обкатать некоторые фишки на Python прежде чем садиться писать полномасштабное приложение на С++.

В конце концов UML - это язык для передачи идей, если хотите. Заголовочные файлы, канешна здорово, но что если вы желаете донести идею (скажем некий паттерн), до человека который ни бэ ни мэ в вашем любимом языке, а вы ни бэ ни мэ в его любимом языке? А если вы при этом один русский, а другой китаец и оба не знаете английского? Что, будете пантомиму разыгрывать? 8))

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

>>Во умарил иерархии наследников в .hxx файлах ))))
Читай выше - про иерархию тебе расскажет doxygen, к примеру.
Вы умрете пользоватся генератором helpов для чтения иерархий и отношений между классами. Во первых долго, на динамично меняющемся коде каждый раз генирить во вторых не наглядно.
Если бы было бы наглядней делать все текстом, чертежей двигателей бы не существовало.

>>Звучит как - того чего я не видел - нет ))))
>Звучит так, как будто ты просто языком чешешь, без всяких аргументов.
http://www.kdedevelopers.org/


>Пость ссылку на то как KDE'шники используют UML или возьми свои слова обратно и заткнись до лучших времен.
Выбирайте выражения.