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

K>Я раньше(когда-то) думал, что использование UML обоснованно только для достаточно крупных проектов. Но потом я услышал мнение(человека я считаю компетентного), что это совсем не так.
K>Так вот подхожу к главному: я хотел бы узнать, насколько широко используются средства UML(Rational Rose и etc) и вообще узнать реальную статистику относящуюся к этим самым средствам. Особенно в средних и сравнительно небольших проектах.
K>Узнать статистику я хочу не просто так. Дело в том, что я считаю, что UML-средства — это следующий после ООП шаг в программировании, короче говоря, что это идея весьма фундаментальная. Исходя из опыта я предполагаю, что реально UML используется только в больших проектах(по необходимости) и профессионалами, которых по пальцам можно сосчитать. На это мнение я думаю будет много возражений, но без реальной статистики прошу зря не возражать Это я сказал, чтобы подвести наконец-то тему к самому главному:
K>в этой теме я хочу обсудить реальные преграды, которые "мешают" продвижению UML в массы а также которые "мешают" эффективности использования средств UML. Обсудить насколько эти преграды действительно являются преградами, выслушать все за и против.

Ну попробую ответить, во-первых, UML всего лишь средство , предназначенное для решения четырех основных проблем: визуализация решений (пердставление их в стандартном более понятном виде), б) спецификация решений (за видами расположена — полная формальная модель), в) проектирование, г) документирование. Ихмо, на сегодняшний день UML абсолютно точно справляется с задачами 3), 1) и 2) (тут все зависит от полноты и качества 1), а вот задача 3 решается только частично. Обратите внимание, что о размере проекта ничего и нигде не говорится. Это выбор средства, если Ваша команда большая или маленькая, его выбирает, она его использует. Например, я знаю команды, состоящие из трех человек, которые используют UML, и знаю команды, в которых разработчиков более 20, но они его не используют, хотя и знают об этом языке.

K>Вобщем вот мой небольшой список преград:
K>1) Необразованность программистов

В какой-то степени согласен.
K>2) Нежелание менять своё мировоззрение
См. ниже.
K>3) Недостаточная интеграция процессов разработки архитектуры программы и непосредственно кодированием
Одна из причин, хотя на текущем этапе активно решается, например, Bold.
K>4) Дороговизна средств разработки
И когда она кого-то у нас останавливала?
K>5) Нерентабельность в небольших и средних проектах
С этим в корне не согласен
K>Очень хотелось бы, чтобы список пополнился

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

K>Для я всё это пишу? Только не для того, чтобы разводить здесь демагогию!
K>На данном этапе моя цель — создать модель средства разработки(IDE) (а впоследствии и воплотить её в жизнь), которая бы учитывала и по возможности убирала бы преграды(см. выше).
K>Для скептиков — определённые идеи уже есть, нехватает опыта, так что помогите, плиз.

Ну тут надо в больше определиться, что за средство рисовалка UML поддержка процесса разработки, .

K>P.S.: У меня конечно есть соображения на этот счёт, но у меня нет фактов, поэтому хочу услышать мнение что называется профессионалов.Несколько позже я ещё напишу свои соображения.