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

M>>Если серьезно, то с какого размера, сложности или какого другого критерия стоит заморачиваться с CASE'ми
M>>Ест-но для "Hello Word!", они нафиг не нужны (хотя если смотря кто платит), но ведь начиная с какой то границы рисование всех этих квадратиков начинает себя оправдывать (или это заговор различных буржуйский фирм по вытягиванию денушки из бедных клиентов на всякую фигню?) Или не начинает?

"Рисование всех этих квадратиков" себя оправдывает и еще как в том случае, если Вы работаете над средним или большим коммерческим проектом.
Ситуация: из команды уходит один из ключевых разработчиков. Что делать? Что делать с тем кодом, который он оставил? Только не говорите, что все разработчики всегда должны быть в курсе того, что делают другие. Никогда этого не получается. У всех и так работы достаточно, чтобы еще вникать в чужую работу и код. Да, начальник отдела должен быть в курсе. Но обычно он в курсе достаточно поверхостно, т.к. когда Вы ему приносите 150Кб кода, как результат выполнения задания, он вникает в особенности функционирования, а не архитектуру. А еще представьте, что разбираться в наследии придется человеку, которого только что наняли вместо ушедшего человека. Сколько ему времени и сил потребуется?

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

И не имеет значения, сколько человек в команде.

Вторая задача: CASE-средства действительно часто сильно помогают на этапе проектирования. Продумать иерархию классов, их взаимоотношения — нет ничего удобнее, чем делать это визуально. Некоторые вещи вообще невозможно в голове удержать.
Про проектирование баз данных я вообще молчу — если бы не мы не применили в свое время ERWin, не знаю во что бы превратилась вся наша информационная система... Да, мы потратили около 3-х недель, сидя над ER-диаграммой, но сколько было пересмотрено в дизайне, и как это помогло понять бизнес-логику.
Ну а новые программисты первое время вообще не отходили от распечатанной и повешенной на стену ER-диаграммы.
Поверьте, это очень помогает.

Когда поднимаешся все выше над землей, линия горизонта становится все дальше, видишь все больше и больше. Так и CASE-средства позволяют посмотреть на проектируемую систему еще до того, как она будет создана. Увидеть многие аспекты и проблемы, о которых даже не задумывался.
Ну а если Вы разрабатываете систему не один, а с напарником. Как Вы будете обсуждать ее архитектуру? "Ну помнишь я тебе говорил про подсистемку, в которой транзакции на банковском счете осуществляются удаленным банковским терминалом? Так вот, пусть там будет не 10 классов, а 11. Да и одну из таблиц нужно убрать, заменив ее на три другие." Долго Вы сможете вести такую беседу, полностью вникая во все, что говорит Вам собеседник? А если вечерком еще 3 литра пива выпить, то на следующее утро все вспомните?


M>>Шоб дальше никого не раздражать переформулирую вопрос — три, или даже четыре программиста — так пойдет?
ЯС>Четыре программиста как правило обходятся без CASE. Вот было бы вас человек 40, вот тогда...

Совершенно не согласен! Почему — смотри выше. Если Вы один, или даже четверо, и вы решили разработать крутую программу за две недели, раздать ее всем своим друзьям, отпраздновать release и потом все забыть и исходники выкинуть, а пользователей посылать подальше, то CASE не нужен.
А если продавать, поддерживать пользователей, выпускать новые версии — одназначно — код нужно документировать!

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

Удачи!