Привет всем...

Ищу средство/способ/методологию для проэктирования/визуального описания кода.
Собственно необходимо два отображения:
1) структура
2) схема действия/работы как отдельных объектов, так и всей системы в целом.

Читал когда то довольно поверхностно книжечки по UML — сейчас думал вернуться перечитать, но, полистав форум заметил, что довольно многие заявляют о полной бесполезности использования UML.

Что посоветуете в таком ракурсе? куда копать?
Что именно Вы используете при проэктировании софта — еще до написания кода, после написания...

Мне как то проще рисовать на бумаге графы с изображением классов, пометками к ним и связями с другими классами. — но это подходит только для решения задачи [1], а вот для [2] выходит всё довольно запутанно, особенно когда классы связаны между собой через события, callback-и плюс еще и запускаются в отдельных потоках
Сейчас схему работы держу в голове, но чувствую, что если сделать месячный перерыв, то потом долго буду разбираться что к чему
Я вот интуитивно чувствую, что толковые архитекторы(да и простые программеры, просто с большим опытом, чем мой), постоянно юзают одну и ту же наработанную схему, может поделитесь, а?

Все эти средства — это дидактические материалы. Т.е. костыли для мозга. Если мозг все понимает без костылей — то они и не нужны.

Они не имеют отношения ни к уровням абстракции, ни к следованию парадигмам, ни к красоте архитектуры, ни к использованию паттернов. Все это можно сделать, написав сразу Си++ заголовок безо всякого UML.

Тем более они не имеют отношения к реальной работоспособности кода.

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

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

Далее пишется уже логика работы системы. Текст с примесью псевдокода. При этом идет слежение, чтобы не нарушались постулаты.

А потом уже можно писать заголовочный и IDL файлы с интерфейсами, правильно откомментированные. Тексты про "постулаты" зачастую вставляются туда же как комментарии.

Но это все для особо сложных вещей. Там, где "и так понятно" — сразу пишется заголовок, с лету. Там мозг работает без костылей.

Здравствуйте, Maxim S. Shatskih,

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

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

Л>при чем если через месяц вижу своё "художество" снова, то за пару сек. всё восстанавливается в памяти.

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

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

Л>Здравствуйте, Maxim S. Shatskih,

Л>Спасибо за ответ. Как я понял, Вы любите описывать всё словами без какого либо графического отображения ваших мыслей... хм... видимо у нас с вами разный тип мышления, мне вот наоборот хочется все именно нарисовать, наставить стрелочек , при чем если через месяц вижу своё "художество" снова, то за пару сек. всё восстанавливается в памяти. Я что один такой?

Нет .. не один. Просто люди -- разные ... есть люди которые мыслят "картинками" а есть кто мыслит "текстом", причем сразу на C++

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

Л>Привет всем...

Л>Ищу средство/способ/методологию для проэктирования/визуального описания кода.
Л>Собственно необходимо два отображения:
Л> 1) структура
Л> 2) схема действия/работы как отдельных объектов, так и всей системы в целом.

Л>Читал когда то довольно поверхностно книжечки по UML — сейчас думал вернуться перечитать, но, полистав форум заметил, что довольно многие заявляют о полной бесполезности использования UML.

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

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

_O_>UML полезен лишь в больших проектах, где сотни (и больше!) разработчиков, а размер моделей достигает гигабайтов.
Размер модели — гигабайты? Сугубо.

_O_>На небольших проектах UML может лишь одну головную боль вызвать.
Аргументы и доказательства?

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

VG>Размер модели — гигабайты? Сугубо.

Пардон, прочитал, "и" вместо "й".

_O_>>UML полезен лишь в больших проектах, где сотни (и больше!) разработчиков, а размер моделей достигает гигабайтов.
VG>Размер модели — гигабайты? Сугубо.

Я сталкивался с такими моделями (в Rational Rose). Число файлов превышает 5000, размер файла (т.е. куска модели) доходит до 300Мб. Продукция американского ВПК

_O_>>На небольших проектах UML может лишь одну головную боль вызвать.
VG>Аргументы и доказательства?

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

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

_O_>Я сталкивался с такими моделями (в Rational Rose). Число файлов превышает 5000, размер файла (т.е. куска модели) доходит до 300Мб. Продукция американского ВПК

...расчитано на прямое попадание ядерного заряда?

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

+1. Как раз хотел противопоставить, что сейчас использую UML в своём курсовом проекте (Web-магазин). Но использую я его именно как рисовалку, рисуя диаграммы в Visio, для записки
и для собственного удобства.

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

UML штука хорошая если нужно задокументировать проект для других людей. Для личного понимания всегда достаточно кода, да идей в голове. Если помнишь о идеи, то в коде найти интересующую часть не составит труда.
Использовать его как иструмент проектирования — неудобно. Для этого использую все бумагу, Word.

_O_>>Я сталкивался с такими моделями (в Rational Rose). Число файлов превышает 5000, размер файла (т.е. куска модели) доходит до 300Мб. Продукция американского ВПК

VG>...расчитано на прямое попадание ядерного заряда?

Ага, типа того. Просто мы делали конвертер Rose-их моделей в другой тул. Наш импортер как раз и проверяли на таких вот гиганстких моделях.

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

Здравствуйте, Maxim S. Shatskih, Вы писали:

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

Ну это Вы лукавите. Попробуйте нарисуйте с первого раза на бумажке диаграмму классов или activity. Тут одной бумажкой не обойдешься, придется альбом заводить, пока все квадратики удобно разместишь. А в софтине все это намного быстрее сделается и при этом сколько лесов сохраняется!

GZ>Здравствуйте, Леонид, Вы писали:

GZ>UML штука хорошая если нужно задокументировать проект для других людей.
Это получается, что UML нужен для того что задокументировать проект для других людей? Блестящая мысль, и как это она мне раньше в голову не приходила?

GZ>Для личного понимания всегда достаточно кода, да идей в голове. Если помнишь о идеи, то в коде найти интересующую часть не составит труда.
Вы наверное имели ввиду апликацию "Hello Word"?

Видал я такие проекты, которые писались с одной только идеей в голове — вроде и голова была ничего и идея неплохая, только по концовке все сводилось к одному — бесконечным заплаткам и "подгонкой под ответ". При чем в результате все равно приходилось возвращаться к UML и переписывать порядочную часть проекта.
А все потому что одной только гениальной идеи мало. Именно для этого и был создан UML. Половина будущих проблем вылезает уже на стадии проектирования, когда их еще не поздно предотвратить, да и все красивости ООП учесть. Потому как когда начинаешь латать свое произведение исскуства, об ООП уже можешь забыть, там уже лишь бы работало.

Здравствуйте, Леонид, Вы писали:
Л>Что посоветуете в таком ракурсе? куда копать?
Л>Что именно Вы используете при проэктировании софта — еще до написания кода, после написания...

Все, что использую — до написания. После написания — только комментарии (и док-генератор по комментариям).

Использую:
— схемы модулей (Visio)
— иногда схемы развертывания (для сетевых систем или кластеров) (Visio)
— диаграммы классов. только для части наиболее сложных модулей, для остальных — ограничиваюсь спецификацией интерфейсов.
— use case для описания поведения системы (Word. Или точнее OpenOffice — там работа с нумерованными списками удобнее.)
— иногда диаграммы обмена (для протоколов)
— И очень много PowerPoint, чтобы собрать все это и завернуть в резенташку. Делаю презеташки не только для менеджеров, но и для программистов. Практика показала, что эстетично сделанную "живую" презенташку они досмотрят с большей вероятностью, чем скучный текст.

Л>Мне как то проще рисовать на бумаге графы с изображением классов, пометками к ним и связями с другими классами. — но это подходит только для решения задачи [1], а вот для [2] выходит всё довольно запутанно,

use case
Есть хорошая книжка здесь

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

_O_>UML полезен лишь в больших проектах, где сотни (и больше!) разработчиков, а размер моделей достигает гигабайтов.
_O_>На небольших проектах UML может лишь одну головную боль вызвать.

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

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

Создай голосование типа "количество разработчиков — полезность UML". Будет интересно.

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

GZ>>Для личного понимания всегда достаточно кода, да идей в голове. Если помнишь о идеи, то в коде найти интересующую часть не составит труда.
UIE> Вы наверное имели ввиду апликацию "Hello Word"?
Вот как раз с аппликациями такого рода я не работаю.


UIE>А все потому что одной только гениальной идеи мало. Именно для этого и был создан UML. Половина будущих проблем вылезает уже на стадии проектирования, когда их еще не поздно предотвратить, да и все красивости ООП учесть. Потому как когда начинаешь латать свое произведение исскуства, об ООП уже можешь забыть, там уже лишь бы работало.
А ты пропробуй реализовать порядка 30 прецедентов в котором штуки по 3-4 альтернативных сценария на диаграмме последовательностей. Уже на 2 прецеденте наступит просветление что ты тратишь на рисование недопустимо много времени. Рисовать их будешь месяц.

_O_>>UML полезен лишь в больших проектах, где сотни (и больше!) разработчиков, а размер моделей достигает гигабайтов.
_O_>>На небольших проектах UML может лишь одну головную боль вызвать.

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

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

Это всё хорошо, но за это тоже надо платить.
Поэтому может оказаться, что дешевле не писать документацию.

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

А где гарантия, что по той документации можно будет что-то понять?

Здравствуйте, Аноним, Вы писали:

А>Это всё хорошо, но за это тоже надо платить.
Не очень понял, за что платить? За UML-инструменты? Есть недорогие решения. Есть примеры собственных, узкоспециализированных решений.

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

А>Какова вероятность, что все разработчики убегут не передав дела?
Достаточно 1-2-3 ключевых. И необязательно одновременно.
Передача дел — вещь довольно условная. Заставить рассказать о всех своих решениях хотя бы за пару лет при высокой интенсивности разработки нереально. Если не о всех — значит что-то упустили. Сколько будет потрачено ресурсов приемкника (и других сотрудников) на понимание?

А>Может оказаться, что вероятность убегания разработчиков, помноженная на затраты по полному рестарту проекта гораздо меньше чем постоянные затраты на полное документирование.
Не надо полное.
Если на старт уже было выделено $ххххх, то рестарт запросто приведет к смене руководителя ИТ-подразделения. Потому что "у нас человек уволился" — не причина.

А еще есть такая вещь как "быстро изменяющиеся условия бизнеса". Мы (ИТ-профессионалы) очень все это не любим (http://gzip.rsdn.ru/Forum/Message.aspx?mid=1566924&only=1

Автор: Splean
Дата: 28.12.05

). Но отчасти в этом неправы. Так как наша деятельность определяется именно бизнесом. Быть готовыми к изменениям и оперативно их проводить (не доводя до маразма конечно) — часть нашей работы.

А>А где гарантия, что по той документации можно будет что-то понять?
Гарантии как всегда — в организации процесса, подборе персонала, планировании, контроле и т.д и т.п.