Есть идея нарисовать достаточно детальную диаграмму системы. Диаграмма по идее должна получиться очень большая.
В чем посоветуете рисовать? Power Point? Visio? Где по вашему мнению удобнее будет ворочать огромную диаграмму?

Здравствуйте, Antei, Вы писали:

A>Есть идея нарисовать достаточно детальную диаграмму системы. Диаграмма по идее должна получиться очень большая.
A>В чем посоветуете рисовать? Power Point? Visio? Где по вашему мнению удобнее будет ворочать огромную диаграмму?

Я, конечно, не на тот вопрос отвечаю, но все же.

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

Здравствуйте, XopoSHiy, Вы писали:

XSH>Я, конечно, не на тот вопрос отвечаю, но все же.
XSH>Может быть не нужно рисовать большую диаграмму? Может нужно нарисовать несколько маленьких диаграмм? А связывать разные диаграммы друг с другом (типа, одна является уточнением одного из блоков на другой), кажется, тот же Visio умеет.

Маленьких диаграм уже куча в PP. Основная идея — распечатать диаграмму и повесить на стенку.

Здравствуйте, Antei, Вы писали:

A>Есть идея нарисовать достаточно детальную диаграмму системы. Диаграмма по идее должна получиться очень большая.
A>В чем посоветуете рисовать? Power Point? Visio? Где по вашему мнению удобнее будет ворочать огромную диаграмму?

"А может не надо, а?"(с) с большой диаграмой всеравно невозможно работать.

cvetkov пишет:
>
> A>Есть идея нарисовать достаточно детальную диаграмму системы. Диаграмма
> по идее должна получиться очень большая.
>
> "А может не надо, а?"(с) с большой диаграмой всеравно невозможно работать.
Но зато красиво, особенно, если на цветном принтере выводить, а
диаграмму разрисовать в цветах. А если на стене пятно или дырка в обоях,
вообще классно смотреться будет.

Приветствую, Antei, вы писали:

A> Есть идея нарисовать достаточно детальную диаграмму системы. Диаграмма по идее должна получиться очень большая.
A> В чем посоветуете рисовать? Power Point? Visio? Где по вашему мнению удобнее будет ворочать огромную диаграмму?

В graphviz. И рисовать не надо, отношения просто задай, да подписи, а потом выбери более приятный глазу вариант.

Здравствуйте, Antei, Вы писали:

A>Есть идея нарисовать достаточно детальную диаграмму системы. Диаграмма по идее должна получиться очень большая.
A>В чем посоветуете рисовать? Power Point? Visio? Где по вашему мнению удобнее будет ворочать огромную диаграмму?

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

bkat wrote:

> А иначе ты будешь единственным, кто это диаграмму будет рассматривать
И то верно. Вон, Малевич умудрился нарисовать диаграмму всего с одним блоком — и сколько зрителей!

Здравствуйте, bkat, Вы писали:

B>Здравствуйте, Antei, Вы писали:

A>>Есть идея нарисовать достаточно детальную диаграмму системы. Диаграмма по идее должна получиться очень большая.
A>>В чем посоветуете рисовать? Power Point? Visio? Где по вашему мнению удобнее будет ворочать огромную диаграмму?

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

Идет изучение крупной и очень запутанной системы.
Диаграммы рисовались по принципу — какой-то разработчик сделал часть системы, разобрался — нарисовал часть с которой работал. В таком духе.
Собственно, вопрос абсолютно технический: где будет удобно ворочать очень много квадратиков со стрелочками и подписями.

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

On 11/09/2009 04:25 PM, Antei wrote:
> Читать диаграмму будет мало народу, это правда. Она нужна
> только нам только с целью изучения системы на первое
> время и новичкам которые будут разбираються с си...

Cadifra UML Editor

Тут раньше уже советовали рисовать много небольших диаграмм... Поддержу
и немного уточню этот вопрос.
Рисовать стоит не так, чтобы одному классу в проекте соответствовал один
квадратик на картине, а так, чтобы картинка (а для больших проектов —
несколько картинок) отображали некоторый аспект структуры или поведения
системы (или ее частей).
Т.е. стоит рисовать
1 — диаграмма размещения (если система использует несколько
вычислительных узлов). В тривиальных случаях этого рисовать не нужно —
например браузер, веб сервер, база данных — и ежу понятно что там и как.
Так что стоит сразу рассматривать только веб приложение и структуру базы.
2 — Структура базы данных (это ER диаграмма, для реляционных баз данных,
можно эмулировать диаграммой классов). При этом всю базу рисовать скорее
всего не нужно. А только связанные части. Например часть базы по учету
пользователей Persons, Contacts, Addresses, Photos... и их связи. Или
часть данных по управлению правами пользователей Logins (и связь с
Person или Contact), Roles, Groups и т.п.
3 — Высокоуровневое представление системы (для систем построенных на
ООП) — диаграмма классов. Здесь квадратики представляют подсистемы, и
между ними нужно указать зависимости. Чтобы было ясно какие подсистемы
могут работать изолировавнно, а какие только в паре. Эта диаграмма
полезна для удержания в памяти архитектуры и для модульного
автоматического тестирования системы (и те же тесты будут
интеграционными тестами подсистем).
Т.е. пример, глядя на диаграмму должно становиться понятно, что для
того, чтобы протестировать регистрацию нового пользователя, необходима
подсистема УправлениеПользователями и подсистема
СлужбаОбработкиИзображений (потому что, к примеру, у пользователя
обязательным является поле Фото, а у класса Person есть акцессор
getThumbnail() — который возвращает уменьшенную фотку).
4 — Кооперативная диаграмма для выполнения действия StartUp. Обычно это
либо диаграмма взаимодействия либо диаграмма последоовательности. Эта
диаграмма должна показывать как "поднимается система". Т.е. должно быть
ясно какие действия должна предпринять система прежде чем будет готова
обслужить первый запрос. Здесь же должно становиться ясно что случится,
если например сервер баз данных окажетсяя недоступным. И еще в виде
комментариев можно указать как система останавливается.

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

Практически все эти диаграммы легко поместятся на А4. Ну для некоторых
может потребоваться несколько листочков А4. Можно распечатать их и
повесить например 5x3. Далее, в процессе работы нужно цветными ручками
править диаграммы, а когда какая-то из них слишком замарается —
перенести исправления в файл и снова распечатать и заменить.

Аргументы против одной большой диаграммы
1. Диаграмма запуска системы, Диаграмма отношений в базе данных и
диаграмма показывающая структуру системы — разные. Они о разных вещах и
по разному их преподносят. При этом они одинаково важны. На одной
диаграмме даже на очень большой показать их все вместе не получится.
2. Усилия разработчика в один момент времени направлены в одно узкое
место, вот и пусть он свой листочек А4 раскрашивает, а большую диаграмму
никто раскрашивать не станет.
3. Некоторые структурные изменения в системе приведут к значительной
переорганизации системы. На большой диаграмме эти части "переедут" на
другие места, и их будет сложно найти. Разработчик только закончит
изучать большую диаграмму и начнет ее понимать, а тут РАЗ! и на стене
уже совсем другая большая диаграмма, которую нужно заново изучать! На
куче маленьких — изменится один-два листочка.
4. Психологически поменять на стене один листочек А4 из 15-ти может даже
стажер. А вот менять огромную диаграмму может только БОС, Главный
Архитектор, и может быть ТехЛид, если соберет несколько подписей а-ля
БОС, утверждаю.

Аргументы в пользу большой диаграммы
1. Под создание большой диаграммы можно выбить время.
2. Результат работы по созданию большой диаграммы — хорошо виден и,
скорее всего порадует начальство.
3. Кабинет украшенный большой диаграммой намекает что здесь работают
умные люди.

Приветствую, Antei, вы писали:

A> Идет изучение крупной и очень запутанной системы.
A> Диаграммы рисовались по принципу — какой-то разработчик сделал часть системы, разобрался — нарисовал часть с которой работал. В таком духе.
A> Собственно, вопрос абсолютно технический: где будет удобно ворочать очень много квадратиков со стрелочками и подписями.
Да, я думаю graphviz тут будет очень к месту. Исходник-текстовичек можно и в репозиторий положить, а картинки генерировать при необходимости. Главное — поддерживать в нем актуальность имен и связей. Впрочем последнее — везде надо.

Псмотри еще в сторону doxygen, возможно этого генератора будет более чем достаточно.