UML-диаграммы

← →
Select (2009-03-12 11:32) [0]

Посоветуйте толковое программное средство для построения UML диаграмм

← →
Ega23 © (2009-03-12 11:43) [1]

1. Как говорил мой бывший шеф: "UML - это всё, конечно, хорошо. Но если вся база (пусть и большая) умещается у тебя в голове - зачем он нужен?"
2. Средств как таковых - полно. Самое простое - тетрадка + ручка.
3. Различных диаграмм тоже немало. DFD, ERD, Use-Case, Sequence и что-то ещё есть, всего их чё-то около 9 типов (если я правильно помню). Многие CASE-средства позволяют только некоторые диаграммы рисовать.
4. Из общеизвестных - ERwin, Visio, Power Designer (я его использую), Rational Rose
5. Есть ещё полно всяких других более мелких.
6. На практике (проекты по 150++ таблиц) лично мне UML не требовался. Шеф какие-то Use-Case и Sequence диаграммы пытался строить одно время, но потом забросил - только работу замедляет.
7. На более крупных проектах вполне возможно, что без UML - вообще никуда. Но таких я пока не встречал.
8. Если для самообразования - я бы Rational Rose посоветовал.

← →
clickmaker © (2009-03-12 11:48) [2]

я тут профанател от Toad Data Modeller
дизайнить таблицы - позволяет, а больше ничего и не нужно

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

← →
Ega23 © (2009-03-12 11:52) [3]

> Практика показала, что все эти диаграммы нафик никому не
> нужны

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

← →
Petr V. Abramov © (2009-03-12 12:03) [4]

> Ega23 © (12.03.09 11:52) [3]

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

← →
Skyle © (2009-03-12 12:11) [5]

> Petr V. Abramov © (12.03.09 12:03) [4]

Какой-то странный процесс... Или бизнес такой? ;)

← →
clickmaker © (2009-03-12 12:15) [6]

> Не, ну на очень больших проектах возможно и нужны.

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

← →
KSergey © (2009-03-12 12:16) [7]

> Petr V. Abramov © (12.03.09 12:03) [4]
> я не очень понимаю, как на UML формализуется бизнес-процесс "экспедитор потерял 2 упаковки пшена

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

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

← →
Petr V. Abramov © (2009-03-12 12:18) [8]

> Skyle © (12.03.09 12:11) [5]

а что тут странного? самая обычная ситуация на самом обычном складе, и никуда от нее денешься, можно только уменьшить частоту возникновения, 100% искоренить никогда не удастся, ибо ЧФ.

← →
KSergey © (2009-03-12 12:19) [9]

> Skyle © (12.03.09 12:11) [5]
> Какой-то странный процесс... Или бизнес такой? ;)

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

← →
Skyle © (2009-03-12 12:21) [10]

> Petr V. Abramov © (12.03.09 12:18) [8]
> KSergey © (12.03.09 12:19) [9]

Налетели... Всего-то хотел сказать garbage in - garbage out....

← →
Ega23 © (2009-03-12 12:30) [11]

> на таких проектах, как правило, не один человек работает.
>
> То есть каждый должен держать в голове свой кусок бизнес-
> проекта. И не должен стремиться "объять необъятное".
> А иначе - по-любому все в помойку превратится. Хоть какие
> диаграммы не рисуй.

Тут такое дело. На предыдущей работе в определённый момент сложилась крайне любопытная ситуация. Ни один человек не знал, как система работает целиком.
Я знал, как мой кусок работает + представлял в общих чертах, как работают те куски, с которыми мой имеет дело.
А вот как всё целиком - никто не знал. Мы тогда с Лёхой просто чуть апстену не убились. В документации написано одно, серверная часть реализована по-другому, а клиентская - по-третьему.
И вот там очень пригодилась бы ERD и DFD.
Но покупать ради этого Rational Rose, разбираться с ним и всё это рисовать сидеть - проще один раз в ворде блок-схемами накидать и всё.

ИМХО.

← →
Petr V. Abramov © (2009-03-12 12:31) [12]

> Skyle © (12.03.09 12:21) [10]

> garbage in - garbage out....

не знаю как у вас на луне, а у нас людям свойственно ошибаться, можно только уменьшить кол-во ошибок.

← →
Petr V. Abramov © (2009-03-12 12:33) [13]

> Ega23 © (12.03.09 12:30) [11]

> вот там очень пригодилась бы ERD и DFD.

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

← →
clickmaker © (2009-03-12 12:36) [14]

> Тут такое дело. На предыдущей работе в определённый момент
> сложилась крайне любопытная ситуация. Ни один человек не
> знал, как система работает целиком

да с этим-то согласен... тут я постил уже как-то кусок кода, над которым я медитировал минут 10
string result;
switch ( forumAttribute )
{
case 10:
case 1034:
result = imgSrc[1];
break;
case 258:
case 2:
result = imgSrc[2];
break;
default:
result = imgSrc[0];
break;
}

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

← →
Ega23 © (2009-03-12 12:40) [15]

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

Безусловно. Но с ERD и DFD было бы проще.

← →
KSergey © (2009-03-12 12:43) [16]

> clickmaker © (12.03.09 12:36) [14]
> И какие диаграммы тут помогут? )

А диаграммы - они панацея от всего?! не правда.

← →
KSergey © (2009-03-12 12:44) [17]

> Petr V. Abramov © (12.03.09 12:33) [13]
> там пригодился бы человек, который изначально представлял бы, как система работает

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

← →
Petr V. Abramov © (2009-03-12 12:50) [18]

> KSergey © (12.03.09 12:44) [17]
> там пригодился бы человек изначально дающий дюлей в случае
> расхождения.

это и имелось в виду. и даже при наличии диаграмм нужен человек, дающий люлей за расхождение кода с диаграммами ;)

← →
clickmaker © (2009-03-12 12:58) [19]

> [16] KSergey © (12.03.09 12:43)
> А диаграммы - они панацея от всего?! не правда.

ну так я об чем и говорю.
моя практика показывает: чем меньше людей работает над проектом, и чем меньше текучка кадров, тем более внятный и качественный получается продукт.
Как ни парадоксально.
Вообще, самый понятный и грамотный код на моей памяти был написан ОДНИМ человеком. Все попытки "улучшить" приводили... ну как говорил Черномырдин -)

← →
Kostafey © (2009-03-12 14:09) [20]

> [0] Select (12.03.09 11:32)

Последнее время пользую UML plugin для NetBeans.

Я вообще тут вот о чем подумал.
UML - диаграммы (прежде всего описание вариантов)
использования нужно подшивать в приложения в ТЗ -
оно на подпись у заказчика.
Тогда задача становится более четкой и формализованной,
соответственно, если вдруг резко к моменту внедрения
возникает идея "а вот тут вот так лучше следовало сделать"
можно ткнуть носом в ТЗ (а там все четко, с картинками :) ),
тогда уж неотвертеться.

В этом случае, ситуация описанная в

> [14] clickmaker © (12.03.09 12:36)

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

Ой, он делает немного не то? Ну, тогда составляем новую смету :)

...попинайте идею.

← →
Ega23 © (2009-03-12 14:12) [21]

> ...попинайте идею.

Заказчик чихать хотел на UML-диаграммы. Он вообще не понимает, что это такое.
А то, что он понимает, можно блок-схемами разрисовать обычными.

← →
Petr V. Abramov © (2009-03-12 14:15) [22]

> Kostafey © (12.03.09 14:09) [20]

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

← →
Kostafey © (2009-03-12 14:17) [23]

> [21] Ega23 © (12.03.09 14:12)

UML к ТЗ можно пришить.
А просто схемы (читай картинки), ну скажет,
давай, теперь по другому их нарисуем (ага, когда само
приложение уже реализовано).

А если картинки к ТЗ прицепить...
кто другой посмотрит, скажет что за ыдиот это делал, нет? :)

← →
Ega23 © (2009-03-12 14:38) [24]

> UML к ТЗ можно пришить.

Ага, ты ещё схему БД туда пришей. Он тебя пошлёт куда подальше, и, вобщем-то, будет прав.

← →
Ганя (2009-03-12 14:40) [25]

> Заказчик чихать хотел

C больными заказчиками работать опасно - можно заразиться ...чихом.
А вообще UML и был задуман в первую очередь как средство нахождения общего языка с заказчиком.

А вот интересно, существуют ли на сегодняшний момент средства UML, умеющие строить модели на основе delphi-кода?
(together" ом пользоваться нельзя в принципе)

← →
Ega23 © (2009-03-12 14:43) [26]

> А вообще UML и был задуман в первую очередь как средство
> нахождения общего языка с заказчиком.

А у тебя есть опыт общения с заказчиками?

← →
clickmaker © (2009-03-12 14:44) [27]

> А вообще UML и был задуман в первую очередь как средство
> нахождения общего языка с заказчиком

много видел заказчиков, знающих УМЛ?

← →
Ганя (2009-03-12 14:53) [28]

> Ega23 ©

> clickmaker ©

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

> А вообще UML и был задуман в первую очередь как средство
> нахождения общего языка с заказчиком.

только заказчиков не предупредили, когда задумывали ;)

> При грамотной организации процесса со стороны заказчика
> присутствуют сотрудники, умеющие это делать.

бывает и такое
только как правило эти сотрудники ничего другого делать не умеют и в результате получается ЕГАИС.
Еще очень эффективно рисовать диаграммы, когда софт по большому счету никому особо не нужен, но деньги под него выделены, бумаги диаграммы занимают много и служат подтверждением огромного объема проделанной работы

> При грамотной организации процесса со стороны заказчика
> присутствуют сотрудники, умеющие это делать.

Значит тебе повезло. А я вот пока ни разу не встречал такого заказчика.

Ну буквально УМЛ или "в картинках" - это не важно, в общем-то обсуждать это с заказчиком здраво.
Другое дело что часто заказчик - директор конторы на 50 человек, причем он сам зачем-то лезет во все дела, однако прав: довериться никому нельзя, вокруг одни воры :)

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

Как и паттерны проектирования, например: ничего нового в них нет, однако что такое "мап" или "визитер" - все(?) знают. Это позволяет общаться на одном языке.

Ну может и у нас когда-нибудь заказчики научатся не изобретать велосипедов, но это ж учиться тогда на само мделе надо, а это никт оне хочет. "Я вам бабло метаю - вот и понимать должны меня!"

> "мап" или "визитер" - все(?) знают.

Я не знаю. :)

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

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

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

← →
b z (2009-03-12 16:14) [37]

На нас вот тоже не чихают за тз "с картинками" заказчики. Что-то наверное не то делаем.. а, и db схемку прикрепляем, для полноты картины :)

> На нас вот тоже не чихают за тз "с картинками" заказчики.
> Что-то наверное не то делаем.. а, и db схемку прикрепляем,
> для полноты картины :)

Это не закономерность, а, скорее, исключение из правил. Из опыта инсталляций системы по стране могу сказать, что только на одном объекте были толковые люди. Которые понимали, что такое таблица в БД и что такое inner join. Причём как администраторы комплекса, так и их руководство (те, кто "музыку заказывал").
На всех остальных объектах администратором назначался тот, кто "как-то раз дома винду переустановил". А те, кто "музыку заказывали", знали, что такое двойной клик и умели запускать Word и даже документ напечатать.
Так вот, таким диаграммы и схемы БД нужны как зайцу стоп-сигнал. Они вообще не понимают, что это такое. Им нужно, чтобы "на кнопочку нажал - и раз, всё заработало".

> Ega23 © (12.03.09 16:37) [38]
> Им нужно, чтобы "на кнопочку нажал - и раз, всё заработало".

и самое занятное, что все работает (наверное :)

Преобладающая точка зрения ясна.

А если диаграммы сопроводжать пояснениями на
человеческом языке + картинки пользовательских
форм? Или в этом случае диаграммы вообще ни к черту?

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

UML-диаграммы Найти похожие ветки