Пробовал в свое время Rational Rose, а потом Together. Rational Rose только для рисования диаграмм - это из пушки по воробьям. Чтобы задействовать сколько-нибудь приличную часть возможностей RR, нужно пересаживаться на RUP, а это совершенно неочевидный по выгодности ход. То же самое, в общем-то, относится и к Together (с заменой RUP на Коудовского конкурента), хотя его идеология кода, синхронизированного с диаграммой - это, конечно, очень здорово и удобно само по себе. Жалко, что их Borland купил, испортят игрушку...
В общем и целом, я для себя пришел к выводу, что лучше всего рисовать UML-диаграммы карандашом на бумаге 8-) Ну или в UML-редакторе, но только не пытаться привязывать все это к коду и к анализу требований.
А рисовать - надо!
Вот тут за время создания пары прог, возник интересный вопрос (который уже наверняка имел освещение в различных топиках) о стратегиях проектирования и разработки программ.
способ номер раз (на первый взгляд правильный), сверху вниз:
Спроектировать программу на бумаге, составить ясную и полную (или почти полную) структуру проги, описать все необходимые данные и процедуры.
преимущества налицо.
недостатки: трудно тестировать программу, пока ее полностью не написал, а конечная стадия программирования, то бишь, дебаг, заметно растягивается, и, что более обидно, обычно немало портит красоту программы (различные заглушки, etc).
Другими словами вид проги (тот который подразумевался при проектировании) меняется.
второй метод (снизу вверх):
обычно используется, когда идея еще окончательно не сформировалась.
программа строится по кирпичикам (без готового каркаса, скелета) в результате на всех стадиях очень удачно поддается отладке и вылащиванию. Но как следствие очень часто приходится переделывать пол-программы, когда вдруг становится понятно, что можно все было сделать иначе (или даже, что по другому вовсе нельзя).
Наверное еще есть третий способ (сверху и вниз, но с локальной отладкой - долго, но вероятно надежно), но я,к сожалению, еще не испробовал его на практике (ибо лень).
У кого нибудь есть какие-нибудь мысли по поводу этого вопроса или все сводится лишь к опыту?..
благодарю за внимание
О философии разработки программных продуктов19.03.03 03:20 Автор: mumiy Статус: Незарегистрированный пользователь
глобально сверху-вниз - полностью определяешь и документируешь дизайн, кодируешь, тестируешь на уровне модулей, тестируешь на уровне системы - прога готова. Тут залог успеха в том, чтоб грамотно провести первую часть, продумать до мелочей и т.д. В реале, очень нудный подход, но зато четко можно выявить рапределение труда.
сверху вниз с повторениями - тоже самое что и в первом случае, но на локальном уровне. То есть готовишь отдельные модули как бы последовательно, а затем интегрируешь. Имплементация - снизу -вверх. Тестирование - как получится )) теоретически - тож снизу-вверх, но как практика показывает, тут все зависит от того, что за прогу ты пишешь.
XP - extreme programming - по-моему, самый действенный. Вначале создаешь executable, затем начинаешь добавлять по чуть-чуть, наворачивать и рефакторить. Так у тебя прога остается той же, и врядли возникнет необходимость переписывать после отладки. Тесты пишутся на каждом повторении, причем перед непосредственным написанием самого кода. Тут больше 2-х челов не требуется.
и не важно, используешь ты юмл для моделирования, или что-то еще, суть не в этом
а ваще есть спец. область, Software Engineering, как раз этой хренью занимается
можно поподробней про XP20.03.03 19:47 Автор: vh <Дмитрий> Статус: Member
> из твоего объяснения что-то проясняется, но не совсем (т.е. > не понятно в чем его главная фича, благодаря которой оно > стало популярным) Вообще для того, чтобы понять, что есть XP, лучше всего прочитать Кента Бека - книжка не слишком толстая, зато помогает понять, нужно ли оно тебе. Лично мое восприятие того, почему XP вошла в моду: всех задолбало, что нельзя сказать "Хочу это" и тебе завтра сделают. А XP за счет очень короткого технологического цикла позволяет такие фокусы. Кроме того, заказчики жутко не любят точно определять все требования и их потом придерживаться. А XP фиксирует требования относительно поздно и главное, позволяет их менять. В общем и целом XP приятен для глаз всевозможного начальства в силу своей гибкости. Основным требованием XP является предельная информированность, грубо говоря, всех об всем, и из-за этого на больших проектах он неприменим: необходимый объем общения между участниками группы становится слишком большим. Все это суть мое понимание XP, не более.
О философии разработки программных продуктов09.03.03 02:09 Автор: tatar_0x4e Статус: Member
> вниз: > Спроектировать программу на бумаге, составить ясную и > полную (или почти полную) структуру проги, описать все
Опыт показывает что неполная не покатит... Нельзя оставлять кодерам слишком много пространства для маневра - всю идею испоганят. Даже если кодеры - ты сам. Первоначальная спецификация должна быть вылизана до совершенства. Это долго, нудно, но всегда окупается.
> необходимые данные и процедуры. > преимущества налицо. > недостатки: трудно тестировать программу, пока ее полностью
1) Есть такой прием - итерационная разработка. То есть: проектируем - делаем какие-то функции - проект собирается - отлаживаем - перепроектируем (если надо) - добавляем функциональность - отлаживаем - и т.д. То есть сложность системы растет постепенно и качество контролируется на каждом шаге.
2) Желательно как можно раньше организовать регулярную сборку проекта целиком. Вместо того, что не написано поставить заглушки, если очень надо. Это здорово поднимает боевой дух программеров, если, допустим, каждый вечер проект пересобирается и сбособен запуститься - видно что что-то уже работает, есть скелет. Да и заказчикам его при случае показать можно, если будут интересоваться. Если же сразу броситься все программировать от начала и до конца, то народ может впасть в разброд и уныние, да и отлаживаться потом будет сложно.
3) Стоит отдельно тестировать каждый модуль. Если есть четкая спецификация того, что ожидается от данного модуля, то это не так уж и сложно.
напрямую никогда не получается и не надо. Стоит быть готовым вернуться назад из любой точки (например с этапа внедрения вернуться на этап тестирования [самое болезненное :) ]) в любое время и не один раз.
> Другими словами вид проги (тот который подразумевался при > проектировании) меняется.
Это нормально, если в разумных пределах. Главное, ИМХО, всегда сначала думать о дизайне (чтоб было красиво, УМЛ модельки поглядеть, порисовать, с командой посовещаться, если есть команда), а потом уже резать.
> > второй метод (снизу вверх): > обычно используется, когда идея еще окончательно не > сформировалась. > программа строится по кирпичикам (без готового каркаса, > скелета) в результате на всех стадиях очень удачно > поддается отладке и вылащиванию. Но как следствие очень > часто приходится переделывать пол-программы, когда вдруг > становится понятно, что можно все было сделать иначе (или > даже, что по другому вовсе нельзя).
В случае большой системы переделка половины программы очень часто означает конец проекта. Так что лучше об этом не говорить Большим Дядькам, а то закроют проект, как нефиг делать, даже если уже потрачены месяцы работы.
> > Наверное еще есть третий способ (сверху и вниз, но с > локальной отладкой - долго, но вероятно надежно), но я,к > сожалению, еще не испробовал его на практике (ибо лень). > У кого нибудь есть какие-нибудь мысли по поводу этого > вопроса или все сводится лишь к опыту?..
Книжки Ktirf правильные порекомендовал. Книга Буча в русском переводе называлась "Объектно-ориентированный анализ и проектирование". Вещь полезная :) Опыт - штука незаменимая, но зачем наступать на чужие грабли если можно про них прочитать? (потом все равно наступишь, но, по крайней мере, будешь знать что случилось)
ЗЫ ИМХО о твоем "втором способе". Если в проекте больше одного человека - не сработает. Так только лабы писать получается :)
О философии разработки программных продуктов09.03.03 16:11 Автор: Ktirf <Æ Rusakov> Статус: Elderman
> > способ номер раз (на первый взгляд правильный), > > А на второй - абсолютно правильный :) Н-ну... См. ниже, в общем...
> Опыт показывает что неполная не покатит... Нельзя оставлять > кодерам слишком много пространства для маневра - всю идею > испоганят. Даже если кодеры - ты сам. Первоначальная > спецификация должна быть вылизана до совершенства. Это > долго, нудно, но всегда окупается. Не-а. Как раз не всегда. Нередко сам заказчик на этапе обсуждения проекта не знает, чего хочет. Полную спецификацию хрен составишь, а если и составишь, потом все равно переделывать. Максимум, на что можно рассчитывать - это общее понимание структуры на уровне функциональных модулей. Все остальное нужно быть готовым переделать в любой момент. Дальнейшее зависит от размеров проекта и нрава заказчика. Набор функциональности в небольших проектах с неумелыми заказчиками плавает так, что только успевай редактировать спеку. Причем это не creeping features, это могут быть просто внутренние нестыковки или неопределенности.
> 1) Есть такой прием - итерационная разработка. То есть: > проектируем - делаем какие-то функции - проект собирается - > отлаживаем - перепроектируем (если надо) - добавляем > функциональность - отлаживаем - и т.д. То есть сложность > системы растет постепенно и качество контролируется на > каждом шаге. Согласен.
> 2) Желательно как можно раньше организовать регулярную > сборку проекта целиком. Вместо того, что не написано > поставить заглушки, если очень надо. Совершенно согласен!
> 3) Стоит отдельно тестировать каждый модуль. Если есть > четкая спецификация того, что ожидается от данного модуля, > то это не так уж и сложно. Опять прав :)
> 4) Прямолинейно следовать модели: > > Узнать требования - составить функциональную спецификацию - > спроектировать - запрограммировать - отладить - внедрить А вот здесь все не так хорошо, как хотелось бы. В теории - да. На практике, если цикл разработки очень короткий (как в экстремальном программировании), фичи внедряются существенно позже, чем начинается следующий цикл разработки. Обратная связь запаздывает (по собственному опыту). Это сильно выбивает из колеи, но с этим приходится мириться.
> напрямую никогда не получается и не надо. Стоит быть > готовым вернуться назад из любой точки (например с этапа > внедрения вернуться на этап тестирования [самое болезненное > :) ]) в любое время и не один раз. Справедливо, но далеко не всегда работает. Теперь уже наоборот: на больших проектах. Слишком велик объем, выкрутиться можно только за счет модуляризации, но тогда возникает лишний уровень возможных ошибок - взаимодействие модулей. Хотя, как показывает опыт многих людей, сидевших на больших проектах, это наименьшее зло: отлавливать локализованные ошибки гораздо проще, чем нелокализованные.
> Это нормально, если в разумных пределах. Главное, ИМХО, > всегда сначала думать о дизайне (чтоб было красиво, УМЛ > модельки поглядеть, порисовать, с командой посовещаться, > если есть команда), а потом уже резать. Чтоб было красиво - это хорошо :) Главное (об этом, кстати, даже Буч пишет) - не застаиваться на этом этапе. И быть максимально консервативным на предмет изменения спецификации.
> ЗЫ ИМХО о твоем "втором способе". Если в проекте больше > одного человека - не сработает. Так только лабы писать > получается :) Пожалуй, да.
масса проектов погибла потому что руководство повелось на рекламу UML
для того чтобы UML работал, нужно чтобы все, начиная от проектировщиков и проджект манагера до самого зачуханного разработчика знали его от и до.
иначе его применение может настолько затормозить проект, что проект станет убыточным.
Какая разница?14.03.03 15:21 Автор: tatar_0x4e Статус: Member
На этапе проектирования необходимо рисовать. Например, диаграммы классов. UML предлагает удобную нотацию для этого и кое-чего еще. Кроме того, изучается он без проблем и интуитивно, если человек знаком с основами ООП. Если же он этого не знает, то UML ему не поможет, как и ни что другое.
Не стоит путать UML с продуктами Rational. Я бы, например, их покупать не рискнул. Сильно дорого, а выигрыш от использования сомнительный.
А кто имеет опыт работы с Rational, расскажите плиз14.03.03 18:34 Автор: vh <Дмитрий> Статус: Member
Rational Rose прокатит как неплохой рисовальщик диаграм, но в принципе можно найти и подешевле и покрасивее, типа Objecteering или, например, Argo UML - страшненький но бесплатный. В качестве CASE средства использовать Розу имхо баловство, причем опасное. Да и вообще CASE средства - паршивая идея. Единственное, что хорошего попадалось в этой области - PowerDesigner от Sybase... (Для работы с базами данных он рулит :) ). Возвращаясь к Rational скажу, что чтобы получить какую-то пользу от остальных их продуктов придется принять предлагаемый ими стиль работы, что означает кардинальную перестройку и еще не факт, что что-то получится и можно быть почти уверенным, что будет хуже чем было до... :) Наблюдал я тут (со стороны :) ) за парой попыток это осуществить - так все кончилось хреново в тех проектах.
ЗЫ А UML - неплохой язык для спецификаций всяких, моделек, юзать можно, только не надо ожидать от него чудес.
Пробовал в свое время Rational Rose, а потом Together. Rational Rose только для рисования диаграмм - это из пушки по воробьям. Чтобы задействовать сколько-нибудь приличную часть возможностей RR, нужно пересаживаться на RUP, а это совершенно неочевидный по выгодности ход. То же самое, в общем-то, относится и к Together (с заменой RUP на Коудовского конкурента), хотя его идеология кода, синхронизированного с диаграммой - это, конечно, очень здорово и удобно само по себе. Жалко, что их Borland купил, испортят игрушку...
В общем и целом, я для себя пришел к выводу, что лучше всего рисовать UML-диаграммы карандашом на бумаге 8-) Ну или в UML-редакторе, но только не пытаться привязывать все это к коду и к анализу требований.
А рисовать - надо!
Присоединяюсь25.03.03 09:36 Автор: Green Статус: Незарегистрированный пользователь
> Пробовал в свое время Rational Rose, а потом Together. > Rational Rose только для рисования диаграмм - это из пушки > по воробьям. Чтобы задействовать сколько-нибудь приличную > часть возможностей RR, нужно пересаживаться на RUP, а это > совершенно неочевидный по выгодности ход. То же самое, в > общем-то, относится и к Together (с заменой RUP на > Коудовского конкурента), хотя его идеология кода, > синхронизированного с диаграммой - это, конечно, очень > здорово и удобно само по себе. Жалко, что их Borland купил, > испортят игрушку... > В общем и целом, я для себя пришел к выводу, что лучше > всего рисовать UML-диаграммы карандашом на бумаге 8-) Ну > или в UML-редакторе, но только не пытаться привязывать все > это к коду и к анализу требований. > А рисовать - надо!
В процессе работы с Rational Rose вылезло столько багов этого ПО, что невольно всплывет поговорка:
"Для того, чтобы учить других, не обязательно уметь самому."
Да и честно говоря, в конце концов все свелось к использованию лишь как редактора UML-диаграм. Пытался использовать ещё и реверсивный анализ, но его результаты лишь запутывают своей некорректностью отображения реальности :о)
Согласен, что использование Rational Rose, как редактора диаграм - это "стрельба из пушки по воробьям". Может подскажете другие простые редакторы UML-диаграм? Можно и без генерации кода, т.к. мы уж как-нибудь по-старинке, РУЧКАМИ, пока так надежней :о)
Присоединяюсь25.03.03 12:28 Автор: tatar_0x4e Статус: Member
> Может подскажете другие простые редакторы UML-диаграм? Можно и > без генерации кода, т.к. мы уж как-нибудь по-старинке, > РУЧКАМИ, пока так надежней :о) Подумал я тут, а где ж это я рисую после ознакомления со всеми этими супер-пупер... И ты знаешь Visio и PowerPoint рулят :) Последний - вообще чемпион по неуставному использованию. Во-первых, есть где порисовать, а во-вторых можно потом те же доки и по назначению использовать (в виде презентаций начальству, то бишь... :) )
> > Может подскажете другие простые редакторы UML-диаграм? > Можно и > > без генерации кода, т.к. мы уж как-нибудь по-старинке, > > РУЧКАМИ, пока так надежней :о) > Подумал я тут, а где ж это я рисую после ознакомления со > всеми этими супер-пупер... И ты знаешь Visio и PowerPoint > рулят :) Последний - вообще чемпион по неуставному > использованию. Во-первых, есть где порисовать, а во-вторых > можно потом те же доки и по назначению использовать (в виде > презентаций начальству, то бишь... :) ) Присоединяюсь :) Хотя PowerPoint - это все-таки не то. Visio (либо dia на Линухе).
Да, Together штучка хорошая! Забыл написать про них... :)15.03.03 00:02 Автор: tatar_0x4e Статус: Member
> масса проектов погибла потому что руководство повелось на > рекламу UML > > для того чтобы UML работал, нужно чтобы все, начиная от > проектировщиков и проджект манагера до самого зачуханного > разработчика знали его от и до. 1. Uslovie ne obiazatel`noe.
2. Pocnemu net? (chto tam takogo slozhnogo?)
> иначе его применение может настолько затормозить проект, > что проект станет убыточным.
Dlia togo chto by programmirovat` na chem to nado tozhe znat` eto chto-to.
это ты по опыту?12.03.03 20:33 Автор: vh <Дмитрий> Статус: Member
подробно о проекте
Анализ криптографических сетевых...
новое сообщение
закрытая нитка
новое сообщение
в закрытой нитке
старое сообщение
