Здравствуйте Яков Сироткин, Вы писали:
M>>А не подскажет ли кто, где, кроме официального сайта можно скачать продукт Together, желательно с российских сайтов?
ЯС>По юридическим причинам — нигде:( А чем официальный сайт не устраивает? Если не выкачать, то в Питере можно ногами прийти:)
Сенкс!
У меня иностранный траффик дорогой-:)
70 мБ мне дорого обойдутся, а нужен ли этот продукт — вопрос.
А>Сенкс! А>У меня иностранный траффик дорогой- А>70 мБ мне дорого обойдутся, а нужен ли этот продукт — вопрос.
Скорее всего нет Together стоит то ли $5000, то ли $7000 и в полной мере проявляет себя на больших проектах. Например, если тебе в наследство осталась пара мегабайт исходного кода на C++ и тебе надо переписать его на Java или нужно написать очень много EJB — тут тебе как раз Together поможет. Я сам раньше использовал Together, но с выходом IDEA www.intellij.com (рекомендую www.intellij.com/eap) обнаружил, что то, что я делал на UML диаграммах можно замечательно делать с клавиатуры и не пускать при этом JBuilder для редактирования кода.
Здравствуйте Яков Сироткин, Вы писали:
А>>Сенкс! А>>У меня иностранный траффик дорогой- А>>70 мБ мне дорого обойдутся, а нужен ли этот продукт — вопрос. ЯС>Скорее всего нет Together стоит то ли $5000, то ли $7000 и в полной мере проявляет себя на больших проектах. Например, если тебе в наследство осталась пара мегабайт исходного кода на C++ и тебе надо переписать его на Java или нужно написать очень много EJB — тут тебе как раз Together поможет. Я сам раньше использовал Together, но с выходом IDEA www.intellij.com (рекомендую www.intellij.com/eap) обнаружил, что то, что я делал на UML диаграммах можно замечательно делать с клавиатуры и не пускать при этом JBuilder для редактирования кода.
Да, похоже что не пригодится
Хотя какнибудь всё же скачаю что бы посмотреть.
Мне показалось что вы — человек искушенный в CASE — средствах,
не могли бы посоветовать, порекомендовать или просто сравнить в нескольких словах известные Вам программы проектирования? Жутко интересует прививаемая руководством сейчас мне Rational Rose, чем она лучше и чем хуже других?
Жизнь, как игра —
идея паршивая,
графика обалденная...
M>Да, похоже что не пригодится M>Хотя какнибудь всё же скачаю что бы посмотреть. M>Мне показалось что вы — человек искушенный в CASE — средствах, M>не могли бы посоветовать, порекомендовать или просто сравнить в нескольких словах известные Вам программы проектирования? Жутко интересует прививаемая руководством сейчас мне Rational Rose, чем она лучше и чем хуже других?
Честно говоря у меня не получилось успешно установить Rational, а в Together у меня очень много друзей рабоает и вообще они спонсируют Java@Питер так что я однозначно больше Together люблю Но в не очень больших проетак, особенно в тех которыми мне приходиться занимать, CASE объективно не нужен, все делает IDEA, Ant и JUnit Ты скажи, что у тебя за задачи, тогда будет более понятно, нужен ли тебе CASE вообще.
RRose — классика жанра, но иногда вызывает по мелочам просто ненависть. Есть ощущение что она слегка устарела в смысле удобства (ну и изначально была заточена под C++/VisualC++). С другой стороны — фактически индустриальный стандарт, да и какие титаны стоят за ней .
Together хорош — все же новое поколенеи CASE, но 1)работает со скоростью джавы — иногда это просто не выносимо 2) Плохо конвертит в/из розовский формат.
ЗЫ
Поскольку единственная прелесть этой страны в доступности дисков на ближайшем рынке, я бы рекомендовал попробовать и то и другое. Мне кажется что роза и проще и быстрее — но это еще зависит от языка (повторюсь -джава в розе была доработкой).
Old C programmers never die. They're just cast into void.
ND> С другой стороны — фактически индустриальный стандарт, да и какие титаны стоят за ней .
Только эти титаны хотят много денег, а отдачуне гарантируют
ND>Together хорош — все же новое поколенеи CASE, но 1)работает со скоростью джавы — иногда это просто не выносимо
На 256 метрах мозгов вполне нормально работатет На 128 — если больше ничего не запускать.
Здравствуйте Яков Сироткин, Вы писали:
M>>Да, похоже что не пригодится M>>Хотя какнибудь всё же скачаю что бы посмотреть. M>>Мне показалось что вы — человек искушенный в CASE — средствах, M>>не могли бы посоветовать, порекомендовать или просто сравнить в нескольких словах известные Вам программы проектирования? Жутко интересует прививаемая руководством сейчас мне Rational Rose, чем она лучше и чем хуже других?
ЯС>Честно говоря у меня не получилось успешно установить Rational, а в Together у меня очень много друзей рабоает и вообще они спонсируют Java@Питер так что я однозначно больше Together люблю Но в не очень больших проетак, особенно в тех которыми мне приходиться занимать, CASE объективно не нужен, все делает IDEA, Ant и JUnit Ты скажи, что у тебя за задачи, тогда будет более понятно, нужен ли тебе CASE вообще.
Задачи относительно не боьшие — классов по 20-25 (+ранее написанные библиотеки, всё на С++). Всё пишется пока одним программистом, совместные проекты (на 3-4 программиста) — в будующем.
Вопрос об использовании CASE вообщем-то продиктован следующими соображениями:
1) Такое кол-во классов в голове уже не удержать и не распланировать.
2) Необходимо документирование программного кода.
Так или иначе, сейчас придётся юзать RRose — веление начальства, но хотелосьбы просто посмотреть чем ещё всё это можно сделать. Уж больно, на мой взгляд, роза навороченная — не может один метод класса содержать столько описательных полей
Жизнь, как игра —
идея паршивая,
графика обалденная...
Здравствуйте Nikita Dolgov, Вы писали:
ND>Здравствуйте Micker:
ND>RRose — классика жанра, но иногда вызывает по мелочам просто ненависть. Есть ощущение что она слегка устарела в смысле удобства (ну и изначально была заточена под C++/VisualC++). С другой стороны — фактически индустриальный стандарт, да и какие титаны стоят за ней .
ND>Together хорош — все же новое поколенеи CASE, но 1)работает со скоростью джавы — иногда это просто не выносимо 2) Плохо конвертит в/из розовский формат.
ND>ЗЫ ND>Поскольку единственная прелесть этой страны в доступности дисков на ближайшем рынке, я бы рекомендовал попробовать и то и другое. Мне кажется что роза и проще и быстрее — но это еще зависит от языка (повторюсь -джава в розе была доработкой).
А UML оба хорошо соответствуют?
Я прочитал по UML всего одну книгу — Крэг Ларман "Проектирование с использованием UML" (кажется так, мог ошибиться в названии). А вот повторить кое-что в RRose не удалось
(Конкретно — на диаграммах взаимодействия как, например, обозначить что метод вызывается в цикле). Может это я не соответствую чему-то ?
Жизнь, как игра —
идея паршивая,
графика обалденная...
M>Задачи относительно не боьшие — классов по 20-25 (+ранее написанные библиотеки, всё на С++). Всё пишется пока одним программистом, совместные проекты (на 3-4 программиста) — в будующем.
При таком объеме проектов и одном программисте CASE нафиг не нужен — не тот порядок и того и другого.
M>1) Такое кол-во классов в голове уже не удержать и не распланировать.
Попробуй больше заниматься Refactoring, чтобы у тебя был понятный код.
M>2) Необходимо документирование программного кода.
В XP http://xprogramming.org документацию писать как-то не принято
M>Так или иначе, сейчас придётся юзать RRose — веление начальства, но хотелосьбы просто посмотреть чем ещё всё это можно сделать.
Раз в неделю нарисовать UML диаграмму на 25 классов можно хоть на салфетке. Но использовать Rational постоянно в твоей ситуации мазохизм. А диаграмки она вроде сама строит.
M>Уж больно, на мой взгляд, роза навороченная — не может один метод класса содержать
столько описательных полей
Ага, а потом получается большая-большая UML диаграмма, толстенные кипы документации и этим можно гордиться. Вот только реально работает только код.
ЯС>Ага, а потом получается большая-большая UML диаграмма, толстенные кипы документации и этим можно гордиться. Вот только реально работает только код.
И то, дойдёт ли до него дело — не ясно
А вопрос можно:
1) А что такое Refactoring ?
А по поводу XP и неписании документации — я слышал.
Правда я думал, что XP как и RUP — в чистом виде экзотка и в каждой, по крайней мере, российской конторе всё делается по своим,особым правилам.
Не так?
Жизнь, как игра —
идея паршивая,
графика обалденная...
ЯС>>Ага, а потом получается большая-большая UML диаграмма, толстенные кипы документации и этим можно гордиться. Вот только реально работает только код. M>И то, дойдёт ли до него дело — не ясно
В любом случае на 25 классах лучше сначала писать код, а потом документацию, благо UML по коду автоматически генерируется.
M>А вопрос можно: M>1) А что такое Refactoring ?
Это когда повышается качество кода без изменения функциональности в Java есть IDEA в которой есть большой арсенал инструментов для рефакторинга, в C++ такого боюсь нету, поэтому придется ручками
M>Правда я думал, что XP как и RUP — в чистом виде экзотка и в каждой, по крайней мере, российской конторе всё делается по своим,особым правилам.
И те, и другие команды в России существуют, это достоверно RUP на твои объемы не расчитан, да и Pair Programming в одиночку применять не очень удобно, но в плане повышения собственной производительности XP может дать тебе гораздо больше и за меньшие средства. К сожалению, у нас часто такие "методологии" применяются, что в результате получается, то что и продуктом назвать нельзя. В любом случае придется собственной головой тоже думать
Здравствуйте Micker, Вы писали:
M>А UML оба хорошо соответствуют? M>Я прочитал по UML всего одну книгу — Крэг Ларман "Проектирование с использованием UML" (кажется так, мог ошибиться в названии). А вот повторить кое-что в RRose не удалось :crash:
M>(Конкретно — на диаграммах взаимодействия как, например, обозначить что метод вызывается в цикле). Может это я не соответствую чему-то ? :shuffle:
IMHO
Together намного привышает RR при программировании на Java.
Роза раздражает своим навязыванием RUP, глюками при установке и неполной поддержкой UML.
Все что есть в книге Лармана можно сделать с помощью Together, но не RR.
Да и приятно работать в продукте написанном по большей части русскими программерами.
Господа! (Товарищи!)
Хотелось бы получить оценку знающих людей — проект состоит где то из стапядидесяти классов бизнес логики, десять-пятнадцать приложений (отдельных компонентов, т.е. екзешников), язык — C++, плюс СУБД для сохранения состояния обьектов. Разработка скорее всего одним (ну может быть двумя, тремя, хотя навряд ли) программистом. Стоит ли тут затеваться с каким нибудь CASE (использование чего нибудь потащит потерю времени, а надо позавчера и т.д....)
Вообще есть критерии, когда все это начинает себя оправдывать? :???:
Здравствуйте misha, Вы писали:
M>Хотелось бы получить оценку знающих людей — проект состоит где то из стапядидесяти классов бизнес логики, десять-пятнадцать приложений (отдельных компонентов, т.е. екзешников), язык — C++, плюс СУБД для сохранения состояния обьектов. Разработка скорее всего одним (ну может быть двумя, тремя, хотя навряд ли) программистом. Стоит ли тут затеваться с каким нибудь CASE (использование чего нибудь потащит потерю времени, а надо позавчера и т.д....)
Боюсь CASE тут не поможет Ну не может один человек сделать 10-15 приложений позавчера
Здравствуйте Яков Сироткин, Вы писали:
ЯС>Здравствуйте misha, Вы писали:
M>>Хотелось бы получить оценку знающих людей — проект состоит где то из стапядидесяти классов бизнес логики, десять-пятнадцать приложений (отдельных компонентов, т.е. екзешников), язык — C++, плюс СУБД для сохранения состояния обьектов. Разработка скорее всего одним (ну может быть двумя, тремя, хотя навряд ли) программистом. Стоит ли тут затеваться с каким нибудь CASE (использование чего нибудь потащит потерю времени, а надо позавчера и т.д....)
ЯС>Боюсь CASE тут не поможет Ну не может один человек сделать 10-15 приложений позавчера
Уже, правда через ...., но работает, только не дышать
Если серьезно, то с какого размера, сложности или какого другого критерия стоит заморачиваться с CASE'ми
Ест-но для "Hello Word!", они нафиг не нужны (хотя если смотря кто платит), но ведь начиная с какой то границы рисование всех этих квадратиков начинает себя оправдывать (или это заговор различных буржуйский фирм по вытягиванию денушки из бедных клиентов на всякую фигню?) Или не начинает?
Шоб дальше никого не раздражать переформулирую вопрос — три, или даже четыре программиста — так пойдет?
P.S. Вопрос на самом деле серьезный, т.к. в нашей конторе бытует мнение что это все нафиг не надо и только пустая трата времени. А планы — огого!!!! А сравнить, посмотреть как у других не имею возможности (желание имею, козу не хочу )
Здравствуйте misha, Вы писали:
M>Уже, правда через ...., но работает, только не дышать
Тогда надо прекратить разработку новых фич и сделать так, чтобы не через ...
работало, а чтобы код был ясный и понятный. Я, кажется, уже говорил, что это называется Refactoring.
M>Если серьезно, то с какого размера, сложности или какого другого критерия стоит заморачиваться с CASE'ми
Лично я, если бы мне пришлось въезжать с нуля в проект такого размера с непонятным кодом, не задумываясь запустил бы CASE, чтобы посмотреть, что там внутри происходит. Но если вы над этим проектом работаете уже много лет, то скорее всего хватит салфеток с картинками. Самое главное, не превращать использование CASE в самоцель — главное писать понятный код, а не рисовать большую диаграмму. Собственно, в вашем случае вряд ли нужно рисовать диаграммы до кодирования, только смотреть что получилось новичкам и заказчикам.
M>Ест-но для "Hello Word!", они нафиг не нужны (хотя если смотря кто платит), но ведь начиная с какой то границы рисование всех этих квадратиков начинает себя оправдывать (или это заговор различных буржуйский фирм по вытягиванию денушки из бедных клиентов на всякую фигню?) Или не начинает? M>Шоб дальше никого не раздражать переформулирую вопрос — три, или даже четыре программиста — так пойдет?
Четыре программиста как правило обходятся без CASE. Вот было бы вас человек 40, вот тогда...
Здравствуйте Яков Сироткин, Вы писали:
M>>Если серьезно, то с какого размера, сложности или какого другого критерия стоит заморачиваться с CASE'ми M>>Ест-но для "Hello Word!", они нафиг не нужны (хотя если смотря кто платит), но ведь начиная с какой то границы рисование всех этих квадратиков начинает себя оправдывать (или это заговор различных буржуйский фирм по вытягиванию денушки из бедных клиентов на всякую фигню?) Или не начинает?
"Рисование всех этих квадратиков" себя оправдывает и еще как в том случае, если Вы работаете над средним или большим коммерческим проектом.
Ситуация: из команды уходит один из ключевых разработчиков. Что делать? Что делать с тем кодом, который он оставил? Только не говорите, что все разработчики всегда должны быть в курсе того, что делают другие. Никогда этого не получается. У всех и так работы достаточно, чтобы еще вникать в чужую работу и код. Да, начальник отдела должен быть в курсе. Но обычно он в курсе достаточно поверхостно, т.к. когда Вы ему приносите 150Кб кода, как результат выполнения задания, он вникает в особенности функционирования, а не архитектуру. А еще представьте, что разбираться в наследии придется человеку, которого только что наняли вместо ушедшего человека. Сколько ему времени и сил потребуется?
Вот здесь и помогают CASE-средства. Несколько простых, самых важных для понимания диаграмм, описание классов и их взаимосвязей, одинаковое форматирование исходного кода и т.п. — все это сильно упрощает взаимозаменяемость разработчиков. Именно в этом главная задача CASE-средств. А разработчики всегда меняются — это факт.
И не имеет значения, сколько человек в команде.
Вторая задача: CASE-средства действительно часто сильно помогают на этапе проектирования. Продумать иерархию классов, их взаимоотношения — нет ничего удобнее, чем делать это визуально. Некоторые вещи вообще невозможно в голове удержать.
Про проектирование баз данных я вообще молчу — если бы не мы не применили в свое время ERWin, не знаю во что бы превратилась вся наша информационная система... Да, мы потратили около 3-х недель, сидя над ER-диаграммой, но сколько было пересмотрено в дизайне, и как это помогло понять бизнес-логику.
Ну а новые программисты первое время вообще не отходили от распечатанной и повешенной на стену ER-диаграммы.
Поверьте, это очень помогает.
Когда поднимаешся все выше над землей, линия горизонта становится все дальше, видишь все больше и больше. Так и CASE-средства позволяют посмотреть на проектируемую систему еще до того, как она будет создана. Увидеть многие аспекты и проблемы, о которых даже не задумывался.
Ну а если Вы разрабатываете систему не один, а с напарником. Как Вы будете обсуждать ее архитектуру? "Ну помнишь я тебе говорил про подсистемку, в которой транзакции на банковском счете осуществляются удаленным банковским терминалом? Так вот, пусть там будет не 10 классов, а 11. Да и одну из таблиц нужно убрать, заменив ее на три другие." Долго Вы сможете вести такую беседу, полностью вникая во все, что говорит Вам собеседник? А если вечерком еще 3 литра пива выпить, то на следующее утро все вспомните?
M>>Шоб дальше никого не раздражать переформулирую вопрос — три, или даже четыре программиста — так пойдет? ЯС>Четыре программиста как правило обходятся без CASE. Вот было бы вас человек 40, вот тогда...
Совершенно не согласен! Почему — смотри выше. Если Вы один, или даже четверо, и вы решили разработать крутую программу за две недели, раздать ее всем своим друзьям, отпраздновать release и потом все забыть и исходники выкинуть, а пользователей посылать подальше, то CASE не нужен.
А если продавать, поддерживать пользователей, выпускать новые версии — одназначно — код нужно документировать!
Вы к этому в любом случае придете Так что лучше раньше, чем потом.
А чем официальный сайт не устраивает? Если не выкачать, то в Питере можно ногами прийти
