Ищу средство/способ/методологию для проэктирования/визуального описания кода.
Собственно необходимо два отображения:
1) структура
2) схема действия/работы как отдельных объектов, так и всей системы в целом.
Читал когда то довольно поверхностно книжечки по UML — сейчас думал вернуться перечитать, но, полистав форум заметил, что довольно многие заявляют о полной бесполезности использования UML.
Что посоветуете в таком ракурсе? куда копать?
Что именно Вы используете при проэктировании софта — еще до написания кода, после написания...
Мне как то проще рисовать на бумаге графы с изображением классов, пометками к ним и связями с другими классами. — но это подходит только для решения задачи [1], а вот для [2] выходит всё довольно запутанно, особенно когда классы связаны между собой через события, callback-и плюс еще и запускаются в отдельных потоках
Сейчас схему работы держу в голове, но чувствую, что если сделать месячный перерыв, то потом долго буду разбираться что к чему
Я вот интуитивно чувствую, что толковые архитекторы(да и простые программеры, просто с большим опытом, чем мой), постоянно юзают одну и ту же наработанную схему, может поделитесь, а?
Все эти средства — это дидактические материалы. Т.е. костыли для мозга. Если мозг все понимает без костылей — то они и не нужны.
Они не имеют отношения ни к уровням абстракции, ни к следованию парадигмам, ни к красоте архитектуры, ни к использованию паттернов. Все это можно сделать, написав сразу Си++ заголовок безо всякого UML.
Тем более они не имеют отношения к реальной работоспособности кода.
Лично я использую текстовые файлы, в которых сначала перечисляются главнейшие принципы работы всей системы — типа "а вот этот файл читается всегда только вперед, никакие seeks по нему не допустимы", перечисляются компоненты и их взаимодействие.
Если речь об особо сложной логике, где недопустимы дыры — то она тоже описывается. Описание начинается опять же с продумывания основных постулатов, которые должны соблюдаться во всей этой подсистеме, чтобы будущий код работал правильно. Из них вырабатываются некоторые чисто логические следствия.
Далее пишется уже логика работы системы. Текст с примесью псевдокода. При этом идет слежение, чтобы не нарушались постулаты.
А потом уже можно писать заголовочный и IDL файлы с интерфейсами, правильно откомментированные. Тексты про "постулаты" зачастую вставляются туда же как комментарии.
Но это все для особо сложных вещей. Там, где "и так понятно" — сразу пишется заголовок, с лету. Там мозг работает без костылей.
Спасибо за ответ. Как я понял, Вы любите описывать всё словами без какого либо графического отображения ваших мыслей... хм... видимо у нас с вами разный тип мышления, мне вот наоборот хочется все именно нарисовать, наставить стрелочек , при чем если через месяц вижу своё "художество" снова, то за пару сек. всё восстанавливается в памяти. Я что один такой?
Здравствуйте, Леонид, Вы писали:
Л>Здравствуйте, Maxim S. Shatskih,
Л>Спасибо за ответ. Как я понял, Вы любите описывать всё словами без какого либо графического отображения ваших мыслей... хм... видимо у нас с вами разный тип мышления, мне вот наоборот хочется все именно нарисовать, наставить стрелочек , при чем если через месяц вижу своё "художество" снова, то за пару сек. всё восстанавливается в памяти. Я что один такой?
Нет .. не один. Просто люди -- разные ... есть люди которые мыслят "картинками" а есть кто мыслит "текстом", причем сразу на C++
Здравствуйте, Леонид, Вы писали:
Л>Привет всем...
Л>Ищу средство/способ/методологию для проэктирования/визуального описания кода. Л>Собственно необходимо два отображения: Л> 1) структура Л> 2) схема действия/работы как отдельных объектов, так и всей системы в целом.
Л>Читал когда то довольно поверхностно книжечки по UML — сейчас думал вернуться перечитать, но, полистав форум заметил, что довольно многие заявляют о полной бесполезности использования UML.
UML полезен лишь в больших проектах, где сотни (и больше!) разработчиков, а размер моделей достигает гигабайтов.
На небольших проектах UML может лишь одну головную боль вызвать.
Здравствуйте, _Obelisk_, Вы писали:
_O_>UML полезен лишь в больших проектах, где сотни (и больше!) разработчиков, а размер моделей достигает гигабайтов.
Размер модели — гигабайты? Сугубо.
_O_>На небольших проектах UML может лишь одну головную боль вызвать.
Аргументы и доказательства?
_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] выходит всё довольно запутанно,
Здравствуйте, _Obelisk_, Вы писали:
_O_>UML полезен лишь в больших проектах, где сотни (и больше!) разработчиков, а размер моделей достигает гигабайтов. _O_>На небольших проектах UML может лишь одну головную боль вызвать.
Головную боль вызывает увольнение ключевых сотрудников, когда оказывается, что никто не знает ни что сделано, ни как сделано, ни зачем оно сделано. Разобраться можно, но это ресурсы. И необязательно разработчиков должно быть много, может быть много проектов (подсистем). А может быть и проект маленький и разработчиков два штука, но тянется проект годами.
Четкие правила документирования позволяют быстро реализовать доработки, даже если разработчик вообще не работал с этой предметной областью.
Создай голосование типа "количество разработчиков — полезность UML". Будет интересно.
Здравствуйте, UnIc0dE, Вы писали:
GZ>>Для личного понимания всегда достаточно кода, да идей в голове. Если помнишь о идеи, то в коде найти интересующую часть не составит труда. UIE> Вы наверное имели ввиду апликацию "Hello Word"?
Вот как раз с аппликациями такого рода я не работаю.
UIE>А все потому что одной только гениальной идеи мало. Именно для этого и был создан UML. Половина будущих проблем вылезает уже на стадии проектирования, когда их еще не поздно предотвратить, да и все красивости ООП учесть. Потому как когда начинаешь латать свое произведение исскуства, об ООП уже можешь забыть, там уже лишь бы работало.
А ты пропробуй реализовать порядка 30 прецедентов в котором штуки по 3-4 альтернативных сценария на диаграмме последовательностей. Уже на 2 прецеденте наступит просветление что ты тратишь на рисование недопустимо много времени. Рисовать их будешь месяц.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Re[3]: пнуть ногой UML? а что взять?
От:
Аноним
Дата:
06.05.06 08:01
Оценка:
_O_>>UML полезен лишь в больших проектах, где сотни (и больше!) разработчиков, а размер моделей достигает гигабайтов. _O_>>На небольших проектах UML может лишь одну головную боль вызвать.
А>Головную боль вызывает увольнение ключевых сотрудников, когда оказывается, что никто не знает ни что сделано, ни как сделано, ни зачем оно сделано. Разобраться можно, но это ресурсы. И необязательно разработчиков должно быть много, может быть много проектов (подсистем). А может быть и проект маленький и разработчиков два штука, но тянется проект годами.
А>Четкие правила документирования позволяют быстро реализовать доработки, даже если разработчик вообще не работал с этой предметной областью.
Это всё хорошо, но за это тоже надо платить.
Поэтому может оказаться, что дешевле не писать документацию.
Какова вероятность, что все разработчики убегут не передав дела?
Может оказаться, что вероятность убегания разработчиков, помноженная на затраты по полному рестарту проекта гораздо меньше чем постоянные затраты на полное документирование.
А где гарантия, что по той документации можно будет что-то понять?
Re[4]: пнуть ногой UML? а что взять?
От:
Аноним
Дата:
06.05.06 09:56
Оценка:
Здравствуйте, Аноним, Вы писали:
А>Это всё хорошо, но за это тоже надо платить.
Не очень понял, за что платить? За UML-инструменты? Есть недорогие решения. Есть примеры собственных, узкоспециализированных решений.
А>Поэтому может оказаться, что дешевле не писать документацию.
Не "писать документацию", а фиксировать принятые решения.
А>Какова вероятность, что все разработчики убегут не передав дела?
Достаточно 1-2-3 ключевых. И необязательно одновременно.
Передача дел — вещь довольно условная. Заставить рассказать о всех своих решениях хотя бы за пару лет при высокой интенсивности разработки нереально. Если не о всех — значит что-то упустили. Сколько будет потрачено ресурсов приемкника (и других сотрудников) на понимание?
А>Может оказаться, что вероятность убегания разработчиков, помноженная на затраты по полному рестарту проекта гораздо меньше чем постоянные затраты на полное документирование.
Не надо полное.
Если на старт уже было выделено $ххххх, то рестарт запросто приведет к смене руководителя ИТ-подразделения. Потому что "у нас человек уволился" — не причина.
). Но отчасти в этом неправы. Так как наша деятельность определяется именно бизнесом. Быть готовыми к изменениям и оперативно их проводить (не доводя до маразма конечно) — часть нашей работы.
А>А где гарантия, что по той документации можно будет что-то понять?
Гарантии как всегда — в организации процесса, подборе персонала, планировании, контроле и т.д и т.п.
Re[4]: пнуть ногой UML? а что взять?
От:
Аноним
Дата:
06.05.06 10:00
Оценка:
Здравствуйте, GlebZ, Вы писали:
GZ>А ты пропробуй реализовать порядка 30 прецедентов в котором штуки по 3-4 альтернативных сценария на диаграмме последовательностей. Уже на 2 прецеденте наступит просветление что ты тратишь на рисование недопустимо много времени. Рисовать их будешь месяц.
Не рисуй. Остановись на верхнем уровне. Покажи только неочевидные вещи.
Здравствуйте, Аноним, Вы писали:
А>Не рисуй. Остановись на верхнем уровне. Покажи только неочевидные вещи.
И мы снова очутились перед тезисом. На UML хорошо документировать, но не проектировать.
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, UnIc0dE, Вы писали:
GZ>А ты пропробуй реализовать порядка 30 прецедентов в котором штуки по 3-4 альтернативных сценария на диаграмме последовательностей. Уже на 2 прецеденте наступит просветление что ты тратишь на рисование недопустимо много времени. Рисовать их будешь месяц.
Во-первых не ты а Вы, мы вроде как на будершафт не пили. А во-вторых, у Вас есть какой-то альтернативный вариант проектирования? Рисование в голове? Тогда я Вам завидую, у меня столько информации в голове не удерживается, знаете ли, семья, дети, да и на принтер это все потом не пошлешь.
А вообще очень странная позиция, что UML нужен для документирования, а не для проектирования. Этому у нас теперь в институтах учат?
Если добро всегда побеждает зло, значит кто победил — тот и добрый.
Здравствуйте, UnIc0dE, Вы писали:
UIE>Во-первых не ты а Вы, мы вроде как на будершафт не пили.
Есть такая примета, если человек на форумах переходит на Вы, значит сейчас конструктив закончится, пойдут личные наезды и лучше быстро смотаться. Посему, если будете повнимательней, то заметите, что общение, де факто, идет в основном на ты. Даже если знаешь, что человек старше по возрасту(а чаще и не знаешь).
UIE>А во-вторых, у Вас есть какой-то альтернативный вариант проектирования? Рисование в голове?
Есть две вещи — первое бумага. Второе — Word. Если нужно проиграть прецеденты, то лучше бумага. Если нужно еще после этого что-то оставить, то начинаешь писать в формате прецедентов. Человеческий язык более богат, и легче отобразить не только особенности того или иного решения, но и почему оно сделано.
UIE>Тогда я Вам завидую, у меня столько информации в голове не удерживается, знаете ли, семья, дети, да и на принтер это все потом не пошлешь.
Аналогично. Семья, дети. Поэтому время берегу.
UIE>А вообще очень странная позиция, что UML нужен для документирования, а не для проектирования. Этому у нас теперь в институтах учат?
Вообще-то, когда я учился UML еще не существовало. Так что ответить не могу.
Re[6]: пнуть ногой UML? а что взять?
От:
Аноним
Дата:
06.05.06 13:37
Оценка:
Здравствуйте, GlebZ, Вы писали:
GZ>И мы снова очутились перед тезисом. На UML хорошо документировать, но не проектировать.
Если у тебя есть средство, генерирующее большое количество кода (не просто пустые методы) по диаграмме классов, — это документирование или проектирование?
Сам по себе UML — это набор соглашений; проблемы его использования — это, в основном, проблемы инструментов и организации процесса проектирования и разработки.
UIE>>Во-первых не ты а Вы, мы вроде как на будершафт не пили. GZ>Есть такая примета, если человек на форумах переходит на Вы, значит сейчас конструктив закончится, пойдут личные наезды и лучше быстро смотаться. Посему, если будете повнимательней, то заметите, что общение, де факто, идет в основном на ты. Даже если знаешь, что человек старше по возрасту(а чаще и не знаешь).
Странно, по моим наблюдениям это происходит как раз при общении на "ты", но не важно.
UIE>>А во-вторых, у Вас есть какой-то альтернативный вариант проектирования? Рисование в голове? GZ>Есть две вещи — первое бумага. Второе — Word. Если нужно проиграть прецеденты, то лучше бумага. Если нужно еще после этого что-то оставить, то начинаешь писать в формате прецедентов. Человеческий язык более богат, и легче отобразить не только особенности того или иного решения, но и почему оно сделано.
Не знаю, зависит наверное от человека. Use Case, Activity, диаграмма классов и.т.п. — не представляю в ворде. Я даже читать это не буду, если увижу. Потому что язык инженерии — это схемы и чертежи. Наверное так меня учили. Возможно, если кому то удобнее исписать несколько страниц текста чтобы собрать в кучку свои мысли — пожалуйста, лишь бы результат был. Только это работает в проектах из одного человека, который потом же и поддержку будет осуществлять. Но если ты работаешь в команде, то должен быть единый технический язык общения между всеми ее членами, и этот язык пока — UML, другого я не знаю.
Попробуйте представить себе архитектора здания, который передает прорабу вместо чертежа здания документ ворд на двухстах страницах. Прораб же охренеет вначале. Потом ему придется либо сменить работу либо выучить новый для него технический язык общения с архитектором, но масса времени уйдет на согласование терминов, потому что они изначально разговаривают на разных языках. Кстати, не из-за этого ли развалилось строительство Вавилонской башни?
Перенесите эту ситуацию в разработку и станет понятно что UML нужен не для того чтобы убивать полезное время на рисование бесполезных рисунков, а для общения всех членов команды на одном единственном языке. У меня в команде очень интернациональный состав, и UML — это наше спасение.
Если добро всегда побеждает зло, значит кто победил — тот и добрый.
Прошу прощения за тафтологию: UML — это просто язык. Не больше, но и не меньше. Использование UML при проектировании кроме очевидного плюса как универсального языка моделирования на котором многие умеют общаться имеет и еще один, весьма немаловажный. Если есть достаточный опыт работы с UML, то всегда можно с уверенностью утверждать следущее: если ты прекрасно знаешь, как решается задача, то не составит труда задокументировать решение в виде UML-диаграмм и, наоборот, если решение, которое созрело у тебя в голове ты неспособен описать средствами UML — то и закодировать ты его не сможешь. Т.е. ограниченность UML относительно естественного языка(и тем более относительно "языка мыслей") есть его большой плюс. Жесткая форма UML позволяет нам ясно выразить содержание. Отбраковка некачественных построений происходит в момент формулирования решения на языке UML. Здесь можно позволить не очень корректную, но напрашивающуюся аналогию с проверкой корректности кода на стадии компиляции.
Если кто-то сталкивался с описанием бизнес процессов в стандарте IDEF0, который еще более ограничен в средствах, нежели UML-диаграммы, поймет следующий пример. Зачастую, специалисту предметной области кажется, что он отлично понимает какие бизнес процессы существуют на его предприятии, как они между собой взаимодействуют и т.д. Свою уверенность в этом знании он с удовольствием демонстрирует в пространных монологах на естественном языке. Но, как только он пытается описать это знание в терминах IDEF0 выясняется, что знание это крайне фрагментарное, во многом неточное, построенное на сравнениях и нечетких ассоциациях. Естественный язык — есть отражение нашего мышления — ассоциативен по своей сути. Формальное описание не терпит ассоциативности или требует, чтобы эта ассоциативность была явно формализована.
Вспоминая теорему Геделя о неполноте, можно указать на один основной недостаток UML, который является прямым следствием его плюсов — существуют программные решения, которые в терминах UML выразить невозможно. Замечу, что это не должно становиться для незрелого программиста причиной отказываться от изучения UML — т.к. без достаточного опыта, к подобным решениям лучше не прибегать, а необходимость выразить решение в терминах UML присечет подобные попытки на корню.
P.S. Сам использую UML с двумя целями: как язык на котором можно общаться в команде при обсуждении решений на высоком абстрактном уровне и для документирования ключевых моментов в системе.
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, _Obelisk_, Вы писали:
_O_>>UML полезен лишь в больших проектах, где сотни (и больше!) разработчиков, а размер моделей достигает гигабайтов. _O_>>На небольших проектах UML может лишь одну головную боль вызвать.
А>Головную боль вызывает увольнение ключевых сотрудников, когда оказывается, что никто не знает ни что сделано, ни как сделано, ни зачем оно сделано. Разобраться можно, но это ресурсы. И необязательно разработчиков должно быть много, может быть много проектов (подсистем). А может быть и проект маленький и разработчиков два штука, но тянется проект годами.
А>Четкие правила документирования позволяют быстро реализовать доработки, даже если разработчик вообще не работал с этой предметной областью.
Дело в том что разобраться с кодом быстрее чем с UML.
UML — это иллюстративная документация,
1. которая может быть нарисована адекватно программе, т.е. верно
но настолько криво- что никто не поймет никогда, т.е. гарантии понимания нет.
2. Это не прямое отображение кода — когда в хорошем случае,
когда полезно.
В этом случае это высокоуровневая концепция — которую рисует архитектор.
и вам не надо именно UML, а надо серьезного архитектора,
который знает как им пользоваться чтобы было не прямое отображение кода, а польза.
___________________________
Архитектура в свою очередь,
нужна для того чтобы декомпозировать сложную разбросанную документацию,
в хорошо разграниченные понятные куски,
что дает понимание и разделение задчачи, т.е. всю хорошую организацию.
А напрямую UML — это обман для навязчивых менеджеров:
(типа получи свою доку, наивно надейся что поможет)
или только способ отрисовывать простые паттерны.
Как комбинировать паттерный UML нет,
тут используются "символические картинки"
платите хорошему архитектору больше, будете здоровы.
Винтовку добудешь в бою!
Re[4]: пнуть ногой UML? а что взять?
От:
Аноним
Дата:
10.05.06 14:24
Оценка:
Здравствуйте, vgrigor, Вы писали:
V>Дело в том что разобраться с кодом быстрее чем с UML.
Неверно, если есть хотя бы один случай, когда это не так. Таких случаев множество.
V>UML — это иллюстративная документация,
V>1. V>2.
На эти тезисы я отвечал в соседней ветке: http://gzip.rsdn.ru/Forum/Message.aspx?mid=1886599&only=1
V>А напрямую UML — это обман для навязчивых менеджеров: V>(типа получи свою доку, наивно надейся что поможет)
Безосновательно.
V>Как комбинировать паттерный UML нет, V>тут используются "символические картинки"
Вот это совсем не понял.
V>платите хорошему архитектору больше, будете здоровы.
Платить хорошему больше — верно для любого сотрудника.
Еще раз. Молотком хорошо забивать гвозди и отбивать пальцы. Отбитые пальцы — не результат устройства молотка.
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, vgrigor, Вы писали:
V>>Дело в том что разобраться с кодом быстрее чем с UML. А>Неверно, если есть хотя бы один случай, когда это не так. Таких случаев множество.
Ну раз вы о точной логике — то да,
если таких случаев 2 из 10 то вы правы.
но практиески — вы будете надеяться на 20% ?
На этот вопрос можно ответить "100% нет".
т.е. если не поставлен вопрос как "применять UML чтобы было хорошо",
то на 100% — на только UML надеяться не стоит.
>проблемы его использования — это, в основном, проблемы инструментов и организации процесса проектирования и разработки.
вы неправильно ответили:
Это не проблемы инструментов — т.к. все они рализуют UML,
и процесс использования UML задокументирован вполне хорошо,
в "лучших практиках архитектур на UML",
но вот приходит человек, и наинает говорить — вот у вас куча диаграмм,
и есть код ему соответствующий — я гораздо лучше понимаю код,
а по UML тяжело т.к. " UML — язык кривой" и это типично.
по UML часто — нельзя понять программу,
нужно что-то ЗА ПРЕДЕЛАМИ UML.
V>>А напрямую UML — это обман для навязчивых менеджеров: V>>(типа получи свою доку, наивно надейся что поможет) А>Безосновательно.
Это практика — приходят люди и говорят — нам надо доку на UML,
и люди садятся и срисовываю с гтового проекта по стандарту диаграммы,
потом- их читаешь — непонятно, а код весьма понятен.
И это неоднократно.
Если бы он был так хорош то во многих местах им бы не пренебрегали, с большим успехом.
Это практика — УСПЕШНЫХ ПРОЕКТОВ, а не домыслы.
V>>Как комбинировать паттерный UML нет, V>>тут используются "символические картинки" А>Вот это совсем не понял.
А>Еще раз. Молотком хорошо забивать гвозди и отбивать пальцы. Отбитые пальцы — не результат устройства молотка.
Как раз результат — хорошим инструментом- вы создадите успешный проект,
а плохим — развалите.
Напрмер возьмите создание новых языков- С -С++ С#,
каждый следующий беспечивает успех более сложных проектов.
а UML — еще в зародыше проектирования, первый и простейший шаг,
таким инструментом только руки ломать в серьезных случаях,
когда надо забить 1000 гвоздей.
а когда 10 — то он пойдет, но это не архитеткура.
Винтовку добудешь в бою!
Re[6]: пнуть ногой UML? а что взять?
От:
Аноним
Дата:
11.05.06 05:39
Оценка:
Здравствуйте, vgrigor, Вы писали:
А>>Неверно, если есть хотя бы один случай, когда это не так. Таких случаев множество. V>Ну раз вы о точной логике — то да, V>если таких случаев 2 из 10 то вы правы.
Посчитать случаи нереально.
V>но практиески — вы будете надеяться на 20% ?
Почему надеятся? Есть способ организовать разработку таким образом, что использование UML будет краеуголным камнем.
V>На этот вопрос можно ответить "100% нет".
Я бы сказал так — есть случаи как удачного так и неудачного использования UML.
Ключевое слово (опять же) — "использование".
V>то на 100% — на только UML надеяться не стоит.
Это верно для чего угодно.
V>Это не проблемы инструментов — т.к. все они рализуют UML, V>и процесс использования UML задокументирован вполне хорошо, V>в "лучших практиках архитектур на UML",
Каждый инструмент предполагает свою концепцию использования UML. Rational Rose 200x предполагал, что модель генерит код и код актуализирует модель. Связи подтягиваются через раз. Генерируемый код так мал, что легче руками написать, чем ждать пока Роза кончит тупить. Результат — модель и код почти соответствуют друг другу. Теперь перестаем генерить код. Один раз подняли код в модель. Поправили, отдали соисполнителям вместе с бинарниками. Отлично.
В этом смысле идельный UML-инструмент — ручка и бумага. Нет возражений против рисования при обсуждении архитектуры?
V>и есть код ему соответствующий — я гораздо лучше понимаю код,
Я думаю обсуждать индивидуальные особенности бессмысленно.
V>а по UML тяжело т.к. " UML — язык кривой" и это типично.
По сравнению с C# или HTML? Не с чем его сравнить.
V>нужно что-то ЗА ПРЕДЕЛАМИ UML.
А нету.
V>потом- их читаешь — непонятно, а код весьма понятен.
UML не виноват.
V>Это практика — УСПЕШНЫХ ПРОЕКТОВ, а не домыслы.
К сожалению, успешность проекта не зависит от (не)использования UML. Она вообще хрен знает от чего зависит.
V>Как раз результат — хорошим инструментом- вы создадите успешный проект, V>а плохим — развалите.
Нет. "Сделать из говна конфекту" — типичная ситуация, создаваемая полититческими играми.
А еще есть проблемы бюджета, кадров и т.п. Но не факт, что проект сдтохнет.
Мне UML не брат и не сестра. Но удивительно слушать, что UML не нужен. Я рисую диаграммы, генерю из них код, контролирую работу подчиненных, передаю готовые решения в другие подразделения, общаюсь с бизнес-аналитиками, с руководством, с заказчиком — и все это UML.
К стати, считаю use-case модель просто незаменимой вещью. Отлично прочищает мозги.
PS Надеюсь, мы не обсуждаем UML для написание драйверов.
Здравствуйте, Леонид, Вы писали:
Л>Ищу средство/способ/методологию для проэктирования/визуального описания кода. Л>Собственно необходимо два отображения: Л> 1) структура Л> 2) схема действия/работы как отдельных объектов, так и всей системы в целом.
Л>Читал когда то довольно поверхностно книжечки по UML — сейчас думал вернуться перечитать, но, полистав форум заметил, что довольно многие заявляют о полной бесполезности использования UML.
Просто не надо из него делать фетиш.
Л>Что посоветуете в таком ракурсе? куда копать? Л>Что именно Вы используете при проэктировании софта — еще до написания кода, после написания...
Первые проектные решения чаще всего появляются на бумаге посредством ручки.
Л>Мне как то проще рисовать на бумаге графы с изображением классов, пометками к ним и связями с другими классами. — но это подходит только для решения задачи [1], а вот для [2] выходит всё довольно запутанно, особенно когда классы связаны между собой через события, callback-и плюс еще и запускаются в отдельных потоках
Sequence-диаграммы, statechart-диаграммы. Прекрасно позволяют документировать и callbacks, и несколько потоков. Не нужно только забывать, что callback-а "в другой поток" не бывает. Кстати, для документирвания алгоритмики очень неплох банальный язык блок-схем.
Л> Сейчас схему работы держу в голове, но чувствую, что если сделать месячный перерыв, то потом долго буду разбираться что к чему Л> Я вот интуитивно чувствую, что толковые архитекторы(да и простые программеры, просто с большим опытом, чем мой), постоянно юзают одну и ту же наработанную схему, может поделитесь, а?
Дык, ты её как раз и выразил: бумага/ручка + в часть в голове. Для того, чтобы не забыть, что к чему — [не-]большие пометки в виде UML-диаграмм.
PS.: В остальном присоединяюсь к MaximVK.
... << RSDN@Home 1.2.0 alpha rev. 643>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Леонид, Вы писали:
Л>Привет всем...
Л>Ищу средство/способ/методологию для проэктирования/визуального описания кода. Л>Собственно необходимо два отображения: Л> 1) структура Л> 2) схема действия/работы как отдельных объектов, так и всей системы в целом.
Ключевое слово для поиска в любимом поисковике: MindMap.
Здравствуйте, Геннадий Васильев, Вы писали: Л>>Мне как то проще рисовать на бумаге графы с изображением классов, пометками к ним и связями с другими классами. — но это подходит только для решения задачи [1], а вот для [2] выходит всё довольно запутанно, особенно когда классы связаны между собой через события, callback-и плюс еще и запускаются в отдельных потоках
ГВ>Sequence-диаграммы, statechart-диаграммы. Прекрасно позволяют документировать и callbacks, и несколько потоков. Не нужно только забывать, что callback-а "в другой поток" не бывает.
— помогают ли эти диаграмы вам самому позже при "разборе полётов" или вы просто документируете определенные решения для других разработчиков? Интересует именно 1-й вариант — т.к. у "нас" всем абсолютно наплевать на документацию кода , а мне попеременно приходится учавствовать в нескольких разных проэктах и при обратном переходе тратится много времени на восстановление собственных идей в памяти . Да и свои новые идеи порой тяжело отобразить на бумаге, а вот в голове держать всё как то тяжеловато...
— в догонку... если ответ "Да", то посоветуйте плз еще где можно почерпнуть инф-ю о использовании данных диаграмм, потому как живого толкового наставника мне до сих пор встретить так и не удалось...
Л>> Сейчас схему работы держу в голове, но чувствую, что если сделать месячный перерыв, то потом долго буду разбираться что к чему Л>> Я вот интуитивно чувствую, что толковые архитекторы(да и простые программеры, просто с большим опытом, чем мой), постоянно юзают одну и ту же наработанную схему, может поделитесь, а?
ГВ>Дык, ты её как раз и выразил: бумага/ручка + в часть в голове. Для того, чтобы не забыть, что к чему — [не-]большие пометки в виде UML-диаграмм.
ГВ>PS.: В остальном присоединяюсь к MaximVK.
Ок, уговорили, буду снова копать в UML, т.к. алтернативы, как я посмотрю, не намечается...
Здравствуйте, UnIc0dE, Вы писали:
UIE>Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>>На бумажке проще рисовать. Трудозатрат меньше, чем проводить стрелочки мышкой в любой графической софтине.
UIE>Ну это Вы лукавите. Попробуйте нарисуйте с первого раза на бумажке диаграмму классов или activity. Тут одной бумажкой не обойдешься, придется альбом заводить, пока все квадратики удобно разместишь. А в софтине все это намного быстрее сделается и при этом сколько лесов сохраняется!
Здравствуйте, iZEN, Вы писали:
ZEN>Здравствуйте, Леонид, Вы писали:
Л>>Привет всем...
Л>>Ищу средство/способ/методологию для проэктирования/визуального описания кода. Л>>Собственно необходимо два отображения: Л>> 1) структура Л>> 2) схема действия/работы как отдельных объектов, так и всей системы в целом.
ZEN>Ключевое слово для поиска в любимом поисковике: MindMap.
Вы юзаете? на сколько успешно, как давно, что именно удобно? в основном для каких целей?
Здравствуйте, Леонид, Вы писали:
ГВ>>Sequence-диаграммы, statechart-диаграммы. Прекрасно позволяют документировать и callbacks, и несколько потоков. Не нужно только забывать, что callback-а "в другой поток" не бывает. Л> — помогают ли эти диаграмы вам самому позже при "разборе полётов" или вы просто документируете определенные решения для других разработчиков?
Скорее, в основном, для себя. Это помогает не столько при "разборе" полётов, сколько "утрясти", дофоромулировать абстракции, а потом уже переходить к кодированию. Поэтому, кстати, имеет смысл наброски делать небольшими: проще поддерживать их в актуальном виде.
"Для других", ИМХО, имеет смысл держать документацию по основным сущностям и связям и только её. Иначе придётся очень много времени тратить на актуализацию. А читать всё равно никто не будет. Хотя здесь бывают забавные ситуации: например, у меня пару раз было так, что в довольно крупных проектах (~десятки мегабайт исходного кода) жили своей жизнью два комплекта схожих функций общего назначения. Форматирования разные, функции работы с датой/временем и т.п.
Л>Интересует именно 1-й вариант — т.к. у "нас" всем абсолютно наплевать на документацию кода , ...
Да почти всем наплевать на документацию. Если участники проекта хорошо понимают взаимосвязи основных сущностей, то всё равно никто документацией пользоваться не будет. Это как в шутке: "Если ничего не вышло, прочтите, наконец, документацию".
Л>...а мне попеременно приходится учавствовать в нескольких разных проэктах и при обратном переходе тратится много времени на восстановление собственных идей в памяти .
В этом нет ничего удивительного, при перемещенеии с проекта на проект всегда некоторое время пребываешь в замешательстве. Даже внутри одного большого проекта. Welcome to the real world, тыксыть. Но иногда перетряхивать мысли даже полезно.
Л>Да и свои новые идеи порой тяжело отобразить на бумаге, а вот в голове держать всё как то тяжеловато...
А это как раз критерий "работоспособности" идей: если их почти невозможно отобразить на бумаге, то как они тогда будут отображаться в коде-то? А если в коде можно отобразить, то на бумаге — и подавно. А порой идею можно выразить на UML, но выражение получается настолько тривиальным, что прям обидно становится — я-то думал, что это "свет в окошке", а это... фи!
Л> — в догонку... если ответ "Да", то посоветуйте плз еще где можно почерпнуть инф-ю о использовании данных диаграмм, потому как живого толкового наставника мне до сих пор встретить так и не удалось...
Ну как тебе сказать... www.rsdn.ru, не можешь — помогут, не хочешь... а что тут тогда делать? Излагай идеи, обсудим.
ГВ>>PS.: В остальном присоединяюсь к MaximVK. Л> Ок, уговорили, буду снова копать в UML, т.к. алтернативы, как я посмотрю, не намечается...
А всё равно будут те же квадратики и стрелочки, только с немного другой семантикой.
... << RSDN@Home 1.2.0 alpha rev. 643>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Леонид, Вы писали:
UIE>>Ну это Вы лукавите. Попробуйте нарисуйте с первого раза на бумажке диаграмму классов или activity. Тут одной бумажкой не обойдешься, придется альбом заводить, пока все квадратики удобно разместишь. А в софтине все это намного быстрее сделается и при этом сколько лесов сохраняется!
Л>А какой софт юзаете?
Есть бесплатный инструмент для рисования UML-диаграмм StarUML.
Здравствуйте, Леонид, Вы писали:
iZEN>>Ключевое слово для поиска в любимом поисковике: MindMap. Л>Вы юзаете? на сколько успешно, как давно, что именно удобно? в основном для каких целей?
Мне это без надобности (ценные мысли, как правило, забиваю в TXT), но для вас, если вы отвергаете UML и, тем не менее, нуждаетесь в чём-то "визуальном" для выражения идей, может пригодится.
(MindMap: сначала узнайте, что это такое и как правильно использовать, а потом ищите нужный софт.)
UML — хорошая вещь, когда задаются базовые классовые конструкции,
т.е. практически паттерны.
Дальше — начинается более концептуальное проектирование,
которое в UML никак не укладывается, чтобы было продуктивно, для дальнейшего понимания,
(а только как много отчетсности)
и тут word к примеру лучше,
а лучше сочетание word и UML, "как сочтется более понятным"
Здравствуйте, MaximVK, Вы писали:
MVK>Здравствуйте, Леонид, Вы писали:
MVK> Прошу прощения за тафтологию: UML — это просто язык. Не больше, но и не меньше. Использование UML при проектировании кроме очевидного плюса как универсального языка моделирования на котором многие умеют общаться имеет и еще один, весьма немаловажный. Если есть достаточный опыт работы с UML, то всегда можно с уверенностью утверждать следущее: если ты прекрасно знаешь, как решается задача, то не составит труда задокументировать решение в виде UML-диаграмм и, наоборот, если решение, которое созрело у тебя в голове ты неспособен описать средствами UML — то и закодировать ты его не сможешь. Т.е. ограниченность UML относительно естественного языка(и тем более относительно "языка мыслей") есть его большой плюс. Жесткая форма UML позволяет нам ясно выразить содержание. Отбраковка некачественных построений происходит в момент формулирования решения на языке UML. Здесь можно позволить не очень корректную, но напрашивающуюся аналогию с проверкой корректности кода на стадии компиляции.
UML знать — надо и пользоваться там где адекватно.
Но зна проблему и выразив ее в UML вы во многих сложных случаях не полуите преимущества,
а получите набор квадратов,
а не вашу цель — понятность документации и проекта.
MVK> Если кто-то сталкивался с описанием бизнес процессов в стандарте IDEF0, который еще более ограничен в средствах, нежели UML-диаграммы, поймет следующий пример. Зачастую, специалисту предметной области кажется, что он отлично понимает какие бизнес процессы существуют на его предприятии, как они между собой взаимодействуют и т.д. Свою уверенность в этом знании он с удовольствием демонстрирует в пространных монологах на естественном языке. Но, как только он пытается описать это знание в терминах IDEF0 выясняется, что знание это крайне фрагментарное, во многом неточное, построенное на сравнениях и нечетких ассоциациях. Естественный язык — есть отражение нашего мышления — ассоциативен по своей сути. Формальное описание не терпит ассоциативности или требует, чтобы эта ассоциативность была явно формализована.
Це — хорошая часть UML,
однако проблема в том что выразив в точности, что может быть ЛЕГКО — ничего хорошего не получите.
тупой набор квадратов.
MVK> Вспоминая теорему Геделя о неполноте, можно указать на один основной недостаток UML, который является прямым следствием его плюсов — существуют программные решения, которые в терминах UML выразить невозможно. Замечу, что это не должно становиться для незрелого программиста причиной отказываться от изучения UML — т.к. без достаточного опыта, к подобным решениям лучше не прибегать, а необходимость выразить решение в терминах UML присечет подобные попытки на корню.
знать надо.
иногда все-таки весьма полезен.
Плохо что "иногда".
т.е. не надо применять "всегда"
MVK> P.S. Сам использую UML с двумя целями: как язык на котором можно общаться в команде при обсуждении решений на высоком абстрактном уровне и для документирования ключевых моментов в системе.
ZEN>Мне это без надобности (ценные мысли, как правило, забиваю в TXT), но для вас, если вы отвергаете UML и, тем не менее, нуждаетесь в чём-то "визуальном" для выражения идей, может пригодится.
правильнее будет сказать не "отвергают", а — "кто не пользуется UML -ВСЕГДА,
а только тогда когда это обосновано, или лучший вариант" (и так бывает ИНОГДА)
ZEN>(MindMap: сначала узнайте, что это такое и как правильно использовать, а потом ищите нужный софт.)
"Сам не пользую — но вам- настоятельно рекомендую" ("будет хорошее наказание")
, но, полистав форум заметил, что довольно многие заявляют о полной бесполезности использования UML. 
