Здравствуйте, Аноним, Вы писали:

А>Главный тормоз на пути к внедрению UML — неспособность среднестатистического homo sapiens к абстрактному мышлению.
А>UML требует умения мыслить в терминах абстрактных конструкций — подобно тому, как это делают хорошие математики и физики-теоретики.

Да ничего UML не требует, это всего лишь картинки. Польза от трудов по проектированию абстрактного мыслителя не умеющего программировать стремится к нулю.
Эти картинки всего лишь призваны немного ускорить процесс восприятия информации, но зачастую они наоборот тормозят. Да и картинки UML затрагивают только некоторые аспекты, некоторые важные высокоуровневые упускают. В проектировании и документировании ведь что важно, подцепить наиболее важный аспект. Какие нибудь диаграммы классов это далеко не самое важное, а какой нибудь горе-художник начнет до посинения картинки раскрашивать в мельчайших деталях, забывая о главном, потом этими картинками останется только любоваться, для красоты на стену вешать.

Ну если есть конкретный алгоритм по типу конечного автомата, ну естейственно и проектировать и документировать его надо как конечный автомат, и как то представлять информацию, там таблицами какими то или картиночками диаграммы состояний. Но может кто-то рискнет спроектировать такую софтину как например CorelDraw с помощью только диаграммы состояний, или картиночек диаграмм классов, или UseCase? Нарисует картиночки и скажет "все кодеры, налетай, осталось только закодировать". Вроде есть еще такие кто так думает.

UML всего лишь стандарт на рисование некоторых картинок, которые иногда могут потребоваться в том или ином случае.

Естейственно это все ИМХО.

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

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

Главный тормоз на пути к внедрению UML — неспособность среднестатистического homo sapiens к абстрактному мышлению.
UML требует умения мыслить в терминах абстрактных конструкций — подобно тому, как это делают хорошие математики и физики-теоретики.
Не знаю, можно ли этому научиться в общем случае. Подозреваю, что сама способность к такому обучению определяется генами и может передаваться только по наследству.
Зато я знаю, как различать таких людей: Одни ищут ответы на вопрос "How To?", а другим достаточно найти ответ на вопрос "Why?", чтобы запросто ответить на все остальные вопросы.

P.S. Прошу прощения за демагогию.

Честно говоря, не знал как назвать тему.
У меня за спиной к сожалению нет большого опыта, поэтому очень хотелось бы узнать мнения людей осведомлённых в .. ну вобщем которые со средствами проектирования архитектуры(типа Rational Rose) на ты и немного знающих реальное положение вещей на фронте. — это было вступление

Я раньше(когда-то) думал, что использование UML обоснованно только для достаточно крупных проектов. Но потом я услышал мнение(человека я считаю компетентного), что это совсем не так.
Так вот подхожу к главному: я хотел бы узнать, насколько широко используются средства UML(Rational Rose и etc) и вообще узнать реальную статистику относящуюся к этим самым средствам. Особенно в средних и сравнительно небольших проектах.

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

в этой теме я хочу обсудить реальные преграды, которые "мешают" продвижению UML в массы а также которые "мешают" эффективности использования средств UML. Обсудить насколько эти преграды действительно являются преградами, выслушать все за и против.
Вобщем вот мой небольшой список преград:
1) Необразованность программистов
2) Нежелание менять своё мировоззрение
3) Недостаточная интеграция процессов разработки архитектуры программы и непосредственно кодированием
4) Дороговизна средств разработки
5) Нерентабельность в небольших и средних проектах
Очень хотелось бы, чтобы список пополнился

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

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

Здравствуйте, 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.: У меня конечно есть соображения на этот счёт, но у меня нет фактов, поэтому хочу услышать мнение что называется профессионалов.Несколько позже я ещё напишу свои соображения.

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

K>>3) Недостаточная интеграция процессов разработки архитектуры программы и непосредственно кодированием
Oaz>Одна из причин, хотя на текущем этапе активно решается, например, Bold.

Спасибо за ответ, почитал немного про Bold(пока совсем немного). Возник вопрос — а какие ещё подобные проекты существуют на данный момент?

K>>4) Дороговизна средств разработки
Oaz>И когда она кого-то у нас останавливала?

У нас — никогда
Но заработать у нас — вещь на грани фантастики(это цитата ). А за рубежом — вполне может быть.

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

Согласен. Но в том-то всё и дело: "когда мы программер думает — он проектирует", тоесть мыслит всё-таки на уровне каких-то абстракций. Тоесть любой человек, создающий проект, сначала его придумывает — проектирует. UML лишь помогает зафиксировать то, что он придумал, причём стандартизированно. — именно в этом я считаю главная задача UML.
Потому возникает вопрос: а действительно ли проблема в том, что нужно менять мировозрение, или же мы просто ещё не научились формализировать структуру проекта?(тут имеется в ввиду, что программист хорошо знает ООП)


Oaz>Ну тут надо в больше определиться, что за средство рисовалка UML поддержка процесса разработки, .
Я уже вроде бы говорил, что на данном этапе с точки зрения реализации меня интересует еффективное использование UML в небольших и средних проектах. Добавлю: с точки зрения проектирования в первую очередь и тесной интеграции с IDE(тут имеются ввиду те выгоды, которые нельзя или сложно получить без интеграции с IDE)

Кстатии говоря, возникли ещё вопросы:
Никто не подскажет, что принципиально нового в Bold, по сравнению с уже существующими средсвами(не интегрированными в IDE).
А также хотелось бы услышать мнение, какие вообще выгоды можно извлечь от интеграции "средств UML" в IDE.
(Этот вопрос для меня очень важен, поэтому большая просьба — больше конкретики)

В UML не хватает одного важного аспекта (или диаграммы).
Не знаю как бы его можно было назвать, что то типа диаграммы иерархии инкапсуляции касающееся физической реализации. Чтобы там можно было увидеть иерархию частей, силу их сцепления и инкапсулации, толщину интерфейса между частями.
Коэфиценты инкапсуляции можно считать как количество человеко лет истраченное на разработку куска, поделенное на количество человеко-часов необходимое для досконального изучения интерфейса этого куска. (Или по количеству функций или строк в куске и его интерфейсе).


Например поймали на улице обезьяну, усадили изучать проект. Первое что она должна узнать об архитектуре системы, это то что система состоит из 2 крупных частей в каждой по 50K строк кода, на каждую часть истрачено по 10 человеко-лет, во внутренностях этих частей без пол-литра не разберешься, и связь между этими частями всего лишь в виде одной функции (так получилось допустим например).
Самый высокий уровень абстракции для такой системы — это описание принимаемых и возвращаемых параметров этой функции и ее семантика. Обезьяна должна узнать в первую очередь об этом, а никак не о том что какой-то SuperPuperCombobox наследуется от SuperPuperControl.

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

При проектировании и изучении кода это очень важный аспект, и его в памяти приходится отстраивать.

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

ИМХО.

UML и только как инструмент для проектирования информационной системы на мой взгляд недостаточно полон. Т.е. он, возможно, необходим, но совсем не достаточен. При помощи UML можно смоделировать поведение системы, но достаточно тяжело спроектировать, например, среду, в которой будет использоваться данная система, предназначение этой системы, структуры данных и т.п.

Возьмём, например, USE-CASE диаграммы. При момощи этих диаграмм можно смоделироваь взаимодействие внешних относительно системы объектов и объектов, представленных в системе. А если бизнес процесс выходит за рамки системы? Например, если документ, распечатанный менеджером, должен пройти визирование у начальника, а потом должен быть внесён в систему обратно? Т.е. имеет место описание бизнес процесса, не реализованного в проектируемой системе, но влияющее на него.

Другими словами, UML предназначен для достаточно низкоуровнего проектирования собственно системы и не касается вопросов использования программной системы, её предназначения и т.п. аспектов.

Безусловно, использование UML в среде, где требуется чёткое описание "внутреннего устройства" системы и это описание надо сохранить, а также в среде, где требуется иметь общий абстрактный язык для общения между разработчиками (например, если часть системы пишется в одной среде, а часть в другой) обосновано. Однако, использование UML является почти необходимым, но далеко не достаточным средством проектирования систмы в целом.

Не очень развитое использование UML в отдельных проектах на мой взгляд продиктовано отчасти и отсутствием необходимости в языке проектирования. Например, мне UML никак не поможет в проектировании GUI или OLAP системы. Конечно, существует и банальное незнание UML в тех случаях, когда он действительно нужен, но ведь до UML писали на процедурных языках и горя не знали...

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

Здесь нужно определиться всё-таки, кто вы есть такой. Или вы аналитик, или проектировщик, или программист, или где-то по середине. Нужно ли вам строить модели оргструктуры, которая будет использовать вашу систему? Будете ли вы в своей работе анализировать бизнес заказчика, чтобы потом построить систему, поддерживающие данный бизнес? Будете ли вы анализировать цели, непрограммные способы достижения данных целей? Или вы будете непосредственно заниматься проектированием информационной системы в рамках жёстко заданных требований, как функциональных, так и нефункциональных?

Если последнее, то скорее всего UML вам хватит (без учёта проектирования структур данных). Если вы будете брать шире, то лучше рассматривать возможность использования и других методологий.

Преграды у вас ИМХО уберутся, когда вы начнёте интуитивно использовать ту методологию и те модели, которые как нельзя лучше подходят к представлению того, что вы хотите описать, а не когда вы будете подгонять свои представления под какую-то конкретную методологию, в частности под UML. А вот после того, как вы выделите на основе такого анализа и проектирования составляющую, требующую чёткого описания именно средствами UML, эту часть можно уже вогнать в рамки UML для дальнейшей передачи кодировщикам, которые уже будут просто реализовывать придуманную вами абстрактную модель на конкретном языке програмирования для конкретной операционной среды.

Таким образом, резюмируя: проектировщику нужно знать UML и использовать для возможности формального описания системы на низком уровне после предварительного проектирования на более высоком уровне, а программисту нужно знать UML для понимания требований проектировщика. При этом желательно, чтобы среда, в которой создаются UML модели была интегрирована с средой разработки, чтобы не было проблем и потерь при конвертровании моделей и имелась возможность автоматизировать часть работы кодировщика. Для VS, например, можно использовать Rational XDE.

P.S. Что касается более высокого проектрования, то наиболее полный набор необходимых моделей и более менее структурированный подход к моделированию системы в целом я видел только в продукте ARIS от IDS Scheer. Кстати, в качестве небольшой составляющей туда входит и весь UML.


P.P.S.
Формально комментируя ваши "cписок преград":

K>1) Необразованность программистов
Скорее необразованность проектировщиков. Читать легче, чем писать...

K>2) Нежелание менять своё мировоззрение
Скорее связано с ленью, хотя нежелание присутствует. Скорее даже не нежелание, а непонимание необходимости.

K>3) Недостаточная интеграция процессов разработки архитектуры программы и непосредственно кодированием
Это не сильно влияет, тем более если проектирование отвязано от разработки. Тем более, что часть моделей вообще невозможно отобразить на код и обратно, например USE-CASES... Хотя, конечно, очень удобно сразу получать шаблоны кода из модели классов и т.п. Но эта задача, насколько я понимаю, сейчас уже решена (правда, дороговато стоит).

K>4) Дороговизна средств разработки
Не думаю, что это сильно останавливает. Поскольку богатые конторы наверняка уже купили или купять, поскольку для них это небольшие деньги, а мелкие не покупают даже Windows...

K>5) Нерентабельность в небольших и средних проектах
Действительно нерентабельность в некоторых проектах, но скорее не потому что само по себе нерентабельно UML использовать, а потому, что нужно умеренно использовать, а не формально к делу подходить... А то бывает, что нужно написать три строчки кода, а человек неделю диаграммы рисует...

Добавил бы от себя ещё причины:
6) Отсутствие в компании формального процесса разработки (человеку говорят, что нужно сделать программу через месяц, а спросить что сделать нужно у Васи Пупкина бухгалтера) и программист выступает во всех ролях сразу, держа все промежуточные результаты проектирования в голове (типа — буду думать в процессе написания кода).
7) Отсутствие необходимости формально описывать систему, если она является "однодневкой", сделана на заказ,без поддержки и в аналогичных случаях, т.е. когда не предвидится необходимости возвращаться к уже написанному.

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

S_>Здравствуйте, Аноним, Вы писали:

А>>Главный тормоз на пути к внедрению UML — неспособность среднестатистического homo sapiens к абстрактному мышлению.
А>>UML требует умения мыслить в терминах абстрактных конструкций — подобно тому, как это делают хорошие математики и физики-теоретики.

S_> Эти картинки всего лишь призваны немного ускорить процесс восприятия информации, но зачастую они наоборот тормозят. Да и картинки UML затрагивают только некоторые аспекты, некоторые важные высокоуровневые упускают. В проектировании и документировании ведь что важно, подцепить наиболее важный аспект. Какие нибудь диаграммы классов это далеко не самое важное, а какой нибудь горе-художник начнет до посинения картинки раскрашивать в мельчайших деталях, забывая о главном, потом этими картинками останется только любоваться, для красоты на стену вешать.

S_> Ну если есть конкретный алгоритм по типу конечного автомата, ну естейственно и проектировать и документировать его надо как конечный автомат, и как то представлять информацию, там таблицами какими то или картиночками диаграммы состояний. Но может кто-то рискнет спроектировать такую софтину как например CorelDraw с помощью только диаграммы состояний, или картиночек диаграмм классов, или UseCase? Нарисует картиночки и скажет "все кодеры, налетай, осталось только закодировать". Вроде есть еще такие кто так думает.

S_>UML всего лишь стандарт на рисование некоторых картинок, которые иногда могут потребоваться в том или ином случае.

S_>Естейственно это все ИМХО.

1. Главный вывод из этого сообщения -- человек не знает толком что такое UML, и тем более не понимает как его можно применять.
2. Насчет CorelDraw , я имел честь году в 1999 общаться с представителями одной маленькой канадской софтверной конторы, которая работала в т.ч. и на Corel, и которая активно использовала UML, как средство описания дизайна своих разработок, именно при работе с Corel . Так что пример не совсем удачный .
3. Для создания дизайна системы, нужно как минимум 2 рода диаграмм -- это диаграммы, которые описывают статику и диниамику взаимодействия. Статика -- это как раз диаграммы классов, и юзкейсов (их использование не всегда нужно, например бессмысленно когда проектируется framework). Динамика -- это sequence и collaboration, ну и при желании activity.
4. Использование UML эффективно, например при описании бизнес-логики (при создании бизнес-приложений). Если приложение пишеться на Delphi по принципу "вся логика на OnButtonClick", то в этом случае, действительно UML врядли поможет.

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

S_>В UML не хватает одного важного аспекта (или диаграммы).

Вы уже настолько хорошо изучили этот язык, что можете указывать на его недостатки?


S_>Не знаю как бы его можно было назвать, что то типа диаграммы иерархии инкапсуляции касающееся физической реализации. Чтобы там можно было увидеть иерархию частей, силу их сцепления и инкапсулации, толщину интерфейса между частями.
S_>Коэфиценты инкапсуляции можно считать как количество человеко лет истраченное на разработку куска, поделенное на количество человеко-часов необходимое для досконального изучения интерфейса этого куска. (Или по количеству функций или строк в куске и его интерфейсе).

Это больше относиться к метрикам. Хотя можно для этого использовать патеерны GRASP. Читаем Лармана .


S_>Например поймали на улице обезьяну, усадили изучать проект. Первое что она должна узнать об архитектуре системы, это то что система состоит из 2 крупных частей в каждой по 50K строк кода, на каждую часть истрачено по 10 человеко-лет, во внутренностях этих частей без пол-литра не разберешься, и связь между этими частями всего лишь в виде одной функции (так получилось допустим например).
S_>Самый высокий уровень абстракции для такой системы — это описание принимаемых и возвращаемых параметров этой функции и ее семантика. Обезьяна должна узнать в первую очередь об этом, а никак не о том что какой-то SuperPuperCombobox наследуется от SuperPuperControl.

Про пакеты в UML имеет смысл посмотреть.


S_>Естейственно это должно быть организовано иерархически, с постепенным измельчением.
S_>И в этот же аспект входит классификация типов интерфейсов между частями — понятно что одной функцией в интерфейсе не отделаешься. Есть наиболее распространенные интерфейсные патерны. И это полезно хорошо представлять, какого типа интерфейс между частями.

S_>При проектировании и изучении кода это очень важный аспект, и его в памяти приходится отстраивать.

Вывод: имея свое собственное представление об проектировании и реализации систем, которое несколько отличается от того как это видят идиологи и именитые приверженцы OOAP, не стоит говорить, что они все идиоты . А стоит задуматься о полноте и универсальности собсвтенного подхода .

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

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

S>Возьмём, например, USE-CASE диаграммы. При момощи этих диаграмм можно смоделироваь взаимодействие внешних относительно системы объектов и объектов, представленных в системе. А если бизнес процесс выходит за рамки системы? Например, если документ, распечатанный менеджером, должен пройти визирование у начальника, а потом должен быть внесён в систему обратно? Т.е. имеет место описание бизнес процесса, не реализованного в проектируемой системе, но влияющее на него.

В RUP опитсано, как это может быть сделано с использованием UML. Дисциплина Бизнес-моделирование. Это здорово можно показать на activity диаграммах, которые в свою очередь можно связать с конкретным юзкейсом. Но это не "чистый" UML -- это методология. Хотя язык UML поддерживает стереотипирование.

S>Другими словами, UML предназначен для достаточно низкоуровнего проектирования собственно системы и не касается вопросов использования программной системы, её предназначения и т.п. аспектов.

Абсолютно неверное понимание.

S>Безусловно, использование UML в среде, где требуется чёткое описание "внутреннего устройства" системы и это описание надо сохранить, а также в среде, где требуется иметь общий абстрактный язык для общения между разработчиками (например, если часть системы пишется в одной среде, а часть в другой) обосновано. Однако, использование UML является почти необходимым, но далеко не достаточным средством проектирования систмы в целом.

Мне лично хвататет , не забываем про стереотипирование -- один из мощниых механизмов, позволяющий многие вопросы разрешать. Кроме этого, имеет смысл таки почитать RUP, там описано как можно применять UML для различных целей, в т.ч. для бизнес-моделирования. Так что имеет смысл не ограничивать себя только "чистым" UML.


S>Не очень развитое использование UML в отдельных проектах на мой взгляд продиктовано отчасти и отсутствием необходимости в языке проектирования. Например, мне UML никак не поможет в проектировании GUI или OLAP системы. Конечно, существует и банальное незнание UML в тех случаях, когда он действительно нужен, но ведь до UML писали на процедурных языках и горя не знали...

Система как минимум кроме GUI и OLAP имеет бизнес-логику .

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


Зачем? Все уже придумано до нас ... нужно просто изучить и уметь использовать .

S>Здесь нужно определиться всё-таки, кто вы есть такой. Или вы аналитик, или проектировщик, или программист, или где-то по середине. Нужно ли вам строить модели оргструктуры, которая будет использовать вашу систему? Будете ли вы в своей работе анализировать бизнес заказчика, чтобы потом построить систему, поддерживающие данный бизнес? Будете ли вы анализировать цели, непрограммные способы достижения данных целей? Или вы будете непосредственно заниматься проектированием информационной системы в рамках жёстко заданных требований, как функциональных, так и нефункциональных?

Кстати, требования -- это уже не UML. А как прейти от требований к дизайну на UML -- это уже вопросы методологии.

S>Если последнее, то скорее всего UML вам хватит (без учёта проектирования структур данных). Если вы будете брать шире, то лучше рассматривать возможность использования и других методологий.

Опа ... UML -- это таки язык. А RUP одна из методологий, которая использует этот язык. И не нужно путать.

S>Преграды у вас ИМХО уберутся, когда вы начнёте интуитивно использовать ту методологию и те модели, которые как нельзя лучше подходят к представлению того, что вы хотите описать, а не когда вы будете подгонять свои представления под какую-то конкретную методологию, в частности под UML. А вот после того, как вы выделите на основе такого анализа и проектирования составляющую, требующую чёткого описания именно средствами UML, эту часть можно уже вогнать в рамки UML для дальнейшей передачи кодировщикам, которые уже будут просто реализовывать придуманную вами абстрактную модель на конкретном языке програмирования для конкретной операционной среды.

S>Таким образом, резюмируя: проектировщику нужно знать UML и использовать для возможности формального описания системы на низком уровне после предварительного проектирования на более высоком уровне, а программисту нужно знать UML для понимания требований проектировщика. При этом желательно, чтобы среда, в которой создаются UML модели была интегрирована с средой разработки, чтобы не было проблем и потерь при конвертровании моделей и имелась возможность автоматизировать часть работы кодировщика. Для VS, например, можно использовать Rational XDE.

S>P.S. Что касается более высокого проектрования, то наиболее полный набор необходимых моделей и более менее структурированный подход к моделированию системы в целом я видел только в продукте ARIS от IDS Scheer. Кстати, в качестве небольшой составляющей туда входит и весь UML.

Ну, скажем, в 99% мне достаточно испоьзования UML + артефакты RUP, для описания как бизнес-процессов, так и дизайна системы.

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

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

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

S>>Возьмём, например, USE-CASE диаграммы. При момощи этих диаграмм можно смоделироваь взаимодействие внешних относительно системы объектов и объектов, представленных в системе. А если бизнес процесс выходит за рамки системы? Например, если документ, распечатанный менеджером, должен пройти визирование у начальника, а потом должен быть внесён в систему обратно? Т.е. имеет место описание бизнес процесса, не реализованного в проектируемой системе, но влияющее на него.

B>В RUP опитсано, как это может быть сделано с использованием UML. Дисциплина Бизнес-моделирование. Это здорово можно показать на activity диаграммах, которые в свою очередь можно связать с конкретным юзкейсом. Но это не "чистый" UML -- это методология. Хотя язык UML поддерживает стереотипирование.

Вот именно... RUP и UML немного несопоставимые понятия

S>>Другими словами, UML предназначен для достаточно низкоуровнего проектирования собственно системы и не касается вопросов использования программной системы, её предназначения и т.п. аспектов.

B>Абсолютно неверное понимание.

Возможно, я не совсем верно выразился, каюсь. Разговор шёл про UML, как язык и набор моделей. Если брать RUP, то в данной методологии предусмотрено значительно больше возможностей. Вы вот всё время говорите про RUP... Это то же самое, что обсуждать SQL и доказывать, что на SQL можно делать иерархические запросы, основываясь на расширении SQL от Oracle.

S>>Безусловно, использование UML в среде, где требуется чёткое описание "внутреннего устройства" системы и это описание надо сохранить, а также в среде, где требуется иметь общий абстрактный язык для общения между разработчиками (например, если часть системы пишется в одной среде, а часть в другой) обосновано. Однако, использование UML является почти необходимым, но далеко не достаточным средством проектирования систмы в целом.

B>Мне лично хвататет , не забываем про стереотипирование -- один из мощниых механизмов, позволяющий многие вопросы разрешать. Кроме этого, имеет смысл таки почитать RUP, там описано как можно применять UML для различных целей, в т.ч. для бизнес-моделирования. Так что имеет смысл не ограничивать себя только "чистым" UML.

Вот и я об этом же... Не стоит ограничивать... Хотя, честно признаюсь, встречал на своём веку бизнес-аналитиков, но не помню, чтобы они работали c RUP-ом.

S>>Не очень развитое использование UML в отдельных проектах на мой взгляд продиктовано отчасти и отсутствием необходимости в языке проектирования. Например, мне UML никак не поможет в проектировании GUI или OLAP системы. Конечно, существует и банальное незнание UML в тех случаях, когда он действительно нужен, но ведь до UML писали на процедурных языках и горя не знали...

B>Система как минимум кроме GUI и OLAP имеет бизнес-логику .

Разумеется Система может не иметь OLAP и GUI Может вообще много чего не иметь... Я же специально пример привёл GUI в качестве примера...

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


B>Зачем? Все уже придумано до нас ... нужно просто изучить и уметь использовать .

S>>Здесь нужно определиться всё-таки, кто вы есть такой. Или вы аналитик, или проектировщик, или программист, или где-то по середине. Нужно ли вам строить модели оргструктуры, которая будет использовать вашу систему? Будете ли вы в своей работе анализировать бизнес заказчика, чтобы потом построить систему, поддерживающие данный бизнес? Будете ли вы анализировать цели, непрограммные способы достижения данных целей? Или вы будете непосредственно заниматься проектированием информационной системы в рамках жёстко заданных требований, как функциональных, так и нефункциональных?

B>Кстати, требования -- это уже не UML. А как прейти от требований к дизайну на UML -- это уже вопросы методологии.

S>>Если последнее, то скорее всего UML вам хватит (без учёта проектирования структур данных). Если вы будете брать шире, то лучше рассматривать возможность использования и других методологий.

B>Опа ... UML -- это таки язык. А RUP одна из методологий, которая использует этот язык. И не нужно путать.

Вот именно.

[SKIPPED]

Здравствуйте, byur, Вы писали:
B>Вывод: имея свое собственное представление об проектировании и реализации систем, которое несколько отличается от того как это видят идиологи и именитые приверженцы OOAP, не стоит говорить, что они все идиоты .

Все таки UML это не какая то методология проектирования, а больше метод представления данных. И все зависит от инструмента и задачи.
Но временами применение например RationalRose при проектировании вызывает некоторые ассоциации с такой штукой:
Есть в VisualStudio гениальный визард, называется C# Add Method Wizard, для визуального добавления метода в класс. Спасибо конечно что автоматизировали эту процедуру, но я ей никогда не пользовался, потому что трудоемкость и затраты времени на добавление метода таким образом, как минимум на порядок больше чем вручную. Интересно, а для кого сделан этот визард? Кто нибудь хоть раз им пользовался?

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

S>UML и только как инструмент для проектирования информационной системы на мой взгляд недостаточно полон. Т.е. он, возможно, необходим, но совсем не достаточен. При помощи UML можно смоделировать поведение системы, но достаточно тяжело спроектировать, например, среду, в которой будет использоваться данная система, предназначение этой системы, структуры данных и т.п.

S>Безусловно, использование UML в среде, где требуется чёткое описание "внутреннего устройства" системы и это описание надо сохранить, а также в среде, где требуется иметь общий абстрактный язык для общения между разработчиками (например, если часть системы пишется в одной среде, а часть в другой) обосновано. Однако, использование UML является почти необходимым, но далеко не достаточным средством проектирования систмы в целом.

Предлагаю рассматривать не сам UML, а всё-таки саму идею, заложенную в этот язык. А недостатотчность UML для выполнения тех или иных задач .. всё-таки возложим эти претензии на среду разработки. Вопрос в том, как наиболее эффективно использовать эту идею.
Естесственно охватить всех сразу нельзя, потому в "вопросах что лучше" коректнее будет рассматривать в контексте "кому".


S>Не очень развитое использование UML в отдельных проектах на мой взгляд продиктовано отчасти и отсутствием необходимости в языке проектирования. Например, мне UML никак не поможет в проектировании GUI или OLAP системы. Конечно, существует и банальное незнание UML в тех случаях, когда он действительно нужен, но ведь до UML писали на процедурных языках и горя не знали...

Во-первых одна из главных причин появления UML — потребность в стандартизации, или же "необходимость в языке проектирования", так что в отсутствии потребности я НЕ СОГЛАСЕН. Потребность не для всех, но она безусловно есть.

S>Здесь нужно определиться всё-таки, кто вы есть такой. Или вы аналитик, или проектировщик, или программист, или где-то по середине. Нужно ли вам строить модели оргструктуры, которая будет использовать вашу систему? Будете ли вы в своей работе анализировать бизнес заказчика, чтобы потом построить систему, поддерживающие данный бизнес? Будете ли вы анализировать цели, непрограммные способы достижения данных целей? Или вы будете непосредственно заниматься проектированием информационной системы в рамках жёстко заданных требований, как функциональных, так и нефункциональных?

Меня интересуют прежде всего "теоретические изыскания", но это уже моя личная проблема
Если же конкретно, то пока это будет всего-лишь курсовая. Была конечно идея заработать денег , но потом решил ограничиться freeware(по различным соображениям). Тоесть я не пишу конкретный заказ, а хочу реализовать некоторые идейки, но сначала изучить всё, что в этом плане сейчас делается.
Цель — улучшить процесс разработки программы используя идею UML. При этом сделать это не за счёт навороченных средств визуального моделирования и быстрой синхронизации аля "Проектировщик классов" в Whitehorse, а за счёт самих идей. Я прекрасно понимаю, что переплюнуть Microsoft там, где нужны ресурсы, я не смогу. Но и с мнением тем, кто говорит, что всё уже придумано за нас, нам лишь остаётся использовать, категорически не согласен. Он наверное просто не общался с теми, кто это всё придумывал, он очень много потерял..

S>Преграды у вас ИМХО уберутся, когда вы начнёте интуитивно использовать ту методологию и те модели, которые как нельзя лучше подходят к представлению того, что вы хотите описать, а не когда вы будете подгонять свои представления под какую-то конкретную методологию, в частности под UML. А вот после того, как вы выделите на основе такого анализа и проектирования составляющую, требующую чёткого описания именно средствами UML, эту часть можно уже вогнать в рамки UML для дальнейшей передачи кодировщикам, которые уже будут просто реализовывать придуманную вами абстрактную модель на конкретном языке програмирования для конкретной операционной среды.

Вот тут я конечно согласен: если хотя бы я пару реальных проектиков наклепал, то было бы легче. Однако это поправимо.

S>Таким образом, резюмируя: проектировщику нужно знать UML и использовать для возможности формального описания системы на низком уровне после предварительного проектирования на более высоком уровне, а программисту нужно знать UML для понимания требований проектировщика. При этом желательно, чтобы среда, в которой создаются UML модели была интегрирована с средой разработки, чтобы не было проблем и потерь при конвертровании моделей и имелась возможность автоматизировать часть работы кодировщика. Для VS, например, можно использовать Rational XDE.

Тут я несколько не соглашусь. Понятное дело, что проектировщику досттаточно крупных систем скорее всего кодировать вообще не придётся, но то, что кодировщики не проектируют — это по определению неправда.
Для проектировщиков практически всё что говорилось раньше — второстепенно. Фактически важными факторами являются лишь синхронизация с программерами, тоесть, чтобы по диаграмкам был конкретный каркас, и т.д. В этой сфере я вряд ли могу на данном этапе "составить конкуренцию"
Но вот что насчёт программеров: они ведь по сути сначала проектируют, а потом проектируют, причём эти процессы итерационны. Нельзя кодировщиков сначала формально заставить сначала всё спроектировать, а потом уже реализовывать. Вобщем процесс проектирования довольно тесно связан с кодированим. И вот на этом этапе очень критичным оказывается то, что кодировщику легче написать по-быстрому, чем что-то ещё рисовать, чисто психологически, и как раз этот этап кодирования я хочу(в процессе) детально проанализировать и использовать здесь идею UML и иже с ними. И задача эта насколько я могу судить пока ещё не полностью исследована. В том смысле, что ещё можно придумать что-то новое.

S>P.S. Что касается более высокого проектрования, то наиболее полный набор необходимых моделей и более менее структурированный подход к моделированию системы в целом я видел только в продукте ARIS от IDS Scheer. Кстати, в качестве небольшой составляющей туда входит и весь UML.

спасибо за ссылку — почитаю, поразбираюсь

S>Добавил бы от себя ещё причины:
S>6) Отсутствие в компании формального процесса разработки (человеку говорят, что нужно сделать программу через месяц, а спросить что сделать нужно у Васи Пупкина бухгалтера) и программист выступает во всех ролях сразу, держа все промежуточные результаты проектирования в голове (типа — буду думать в процессе написания кода).

Полностью согласен, сам являюсь жертвой

S>7) Отсутствие необходимости формально описывать систему, если она является "однодневкой", сделана на заказ,без поддержки и в аналогичных случаях, т.е. когда не предвидится необходимости возвращаться к уже написанному.

Это тоже проблема.
Но в том-то и дело, я хочу, чтобы использование UML(в контексте среды разработки) было продиктовано рациональностью, тоесть чтобы это было выгодней в первую очередь экономически, а это будет в том случае, если это будет удобнее (именно для программеров). Тоесть по сути нужно решить задачку: как процесс интуитивного проектирования ненавязчиво перевести в разряд формального. По сути использование средства разработки будет подталкивать к формальному проектированию там, где это действительно нужно. Я это вижу так: в процессе программирования у программера в голове постепенно складывается структура проекта, постепенно становясь всё более детализированной, а средство разработки(IDE) должно позволять также постепенно фиксировать структуру и "на бумаге", при этом делать это должно быть не сложно. Тоесть мы не "рисуем диаграмки", а итеративно уточняем структуру проекта. Естественно при такой итеративности мы будем связывать структуру проекта непосредственно с кодом — это кстатии сама по себе очень интересная задачка. Ненавязчивость будет проявляться в том, что мы можем остановиться на любом уровне абстракции, вобщем там,где нам будет удобнее.

Конечно возникает вопрос: как это сделать ?!
Над ним я сейчас и тружусь, и не скажу, что результатов нет(пока естественно только в теории).
Если это уже всё сделано, а нам остаётся только использовать(тут обязательно должен чувствоваться явный сарказм ) — расскажите, и желательно поподробнее

P.S.: Обязательно найдутся те, кто скажет — это утопия. Но во-первых, я не говорю, что хочу создать совершенную программу — это невозможно, а во-вторых: при таких бурных темпах развития представьте себе ситуацию лет через 10, наверняка там уже будет новый уровень програмных средств, который сейчас — утопия. Но хочу заметить, что реализация идея в красивом виде происходит небыстро, и если Microsoft заявляет о своей супер новой внедрённой технологии, то наверняка(по крайней мере примеров куча), что идея технологии была создана уже давно. Кто знает, может быть я внесу и свою небольшую лепту в ускорении этого процесса. Пусть я безнадёжный романтик, но я также и безнадёжный реалист.

Я тут говорил с некоторыми своими знакомыми, которые UML не используют, и задавал им провокационный вопрос:
"Почему вы не используете UML?"

Что любопытно — нарисовалась достаточно однозначная картина: большинство людей просто не могут понять рамок его использования.
Т.е. им понятно, что для проектирования классов удобно использовать диаграмму классов, более-менее понятно, где и как использовать use-cases и т.д. Но большинство рассматривает UML в отрыве от методологии его применения, т.е. не понимают какие диаграммы из каких следуют, как они связаны и т.д.

Поэтому я полностью согласен, что рассматривать UML в отрыве от методологии его применения нельзя.

Косвенное тому подтверждение, это когда подходит начинающий проектировщик к "старшему товарищу" и спрашивает: "А какую модель мне нужно нарисовать в таком-то случае?" Мне кажется, что в этом кроется одна из основных причин, по которой у людей складывается отношение к UML. Если проводить параллели, то, например, то же самое с паттернами — мало разобраться что такое singleton, надо ещё знать, в каком случае его нужно применять.

Чтобы не противоречить своему предыдущему топику скажу, что в зависимости от методологии (RUP, ARIS или ещё какой) можно одни и те же "языковые конструкции" UML трактовать и использовать по разному — главное, чтобы а результате складывалась единая картина взглядов на систему.

Поэтому, если создавать себе рабочую среду, в которую будет входить инструментарий для работы с UML, надо в первую очередь выбрать методологию, а потом под неё подстраивать инструментарий среды.

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

S>Чтобы не противоречить своему предыдущему топику скажу, что в зависимости от методологии (RUP, ARIS или ещё какой) можно одни и те же "языковые конструкции" UML трактовать и использовать по разному — главное, чтобы а результате складывалась единая картина взглядов на систему.

Согласен с этим

S>Поэтому, если создавать себе рабочую среду, в которую будет входить инструментарий для работы с UML, надо в первую очередь выбрать методологию, а потом под неё подстраивать инструментарий среды.

Это пока буде достаточно небольшой проект. Тоесть рабочую среду с нуля создавать никто не будет. Я остановился на плагине к Visual Studio, как на наиболее приемлемом варианте.

Что касается выбора методологии. Вот вы говорите — выберите, а я спрашиваю — какую посоветуете?
Если говорить серьйозно, то брать нужно всегда лучшее от того, что имеется, поэтому я несколько не понимаю формулировку "выбрать методологию". Тоесть я хотел бы услышать, что именно нужно выбирать, речь ведь сейчас не идёт о стандартизации, так что у меня нет такого ограничения, что нужно жёстко привязываться к какой-либо существующей методологии.
К тому же если взять смысл слова "методология": создавая(улучшая) среду разработки я одновременно косвенно создаю(уточняю, изменяю) и саму методологию, тоесть я задаю некоторый стиль использования своей среды разработки. Здесь я считаю нужно конкретика.
Ну а вообще данные методологии в первую очередь рассматривают процесс разработки продукта на макро-уровне. А мне нужно немного другое. Микро-уровнем было бы назвать неправильно. Тут я могу разве что повторить то, что сказал в предыдущем ответе о своей "пока что" курсовой. Но поскольку цитировать много — то цитировать не буду
Я может пока размыто, но уже говорил "что я хочу придумать".

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

S>>Поэтому, если создавать себе рабочую среду, в которую будет входить инструментарий для работы с UML, надо в первую очередь выбрать методологию, а потом под неё подстраивать инструментарий среды.

K>Это пока буде достаточно небольшой проект. Тоесть рабочую среду с нуля создавать никто не будет. Я остановился на плагине к Visual Studio, как на наиболее приемлемом варианте.

Ну и нормально. Уже хорошо, что на чём-то остановились.

K>Что касается выбора методологии. Вот вы говорите — выберите, а я спрашиваю — какую посоветуете?

Не посоветую конкретно ничего, поскольку общепринятые вам насоветуют и без меня, а моя собственная солянка вам вряд ли подойдёт

K>Если говорить серьйозно, то брать нужно всегда лучшее от того, что имеется, поэтому я несколько не понимаю формулировку "выбрать методологию".

Далее ИМХО.
Я под этой формулировкой понимаю выбор необходимого и достаточного в вашем проекте набора взглядов на различные аспекты создаваемой системы.
Есть универсальные подходы, вроде RUP-а, но они подразумевают с одной стороны, использование большого количества взглядов на систему, а иногда это просто не нужно, с другой стороны использование соответствующего программного обеспечения, которое иной раз излишне функционально и достаточно дорого. Поэтому "лучшее" (читай "оптимальное") зависит в большой степени от потребностей проекта.

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

K>Кстатии говоря, возникли ещё вопросы:
K>Никто не подскажет, что принципиально нового в Bold, по сравнению с уже существующими средсвами(не интегрированными в IDE).
K>А также хотелось бы услышать мнение, какие вообще выгоды можно извлечь от интеграции "средств UML" в IDE.
K>(Этот вопрос для меня очень важен, поэтому большая просьба — больше конкретики)

Принципиально новое следующее Bold поддерживает процесс разработки сверху вниз, т.е. от моделей к коду, решая всякие мелкие и не принципиальные задачи, полностью. При этом кое-где контролирует Ваши действия. Более подробно об этом можно почить, например, в "Компьютер-пресс", там был неплохой цикл статей про Bold. его в последствии на www.interface.ru опубликовали.

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

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

Oaz>>Ну тут надо в больше определиться, что за средство рисовалка UML поддержка процесса разработки, .
K>Я уже вроде бы говорил, что на данном этапе с точки зрения реализации меня интересует еффективное использование UML в небольших и средних проектах. Добавлю: с точки зрения проектирования в первую очередь и тесной интеграции с IDE(тут имеются ввиду те выгоды, которые нельзя или сложно получить без интеграции с IDE)
Я не против с помощью UML общаться даже сам с собою. Но, imho, UML должен быть частью среды разработки, неким метаязыком. Обобщенным взглядом на приложение и его части. Отдельные блоки приложения (структура, данные, алгоритмы и т.д.) при этом должны динамически выражаться на конкретных языках программирования.

Здравствуйте, Дед Пихто, Вы писали:

ДП>Здравствуйте, kosmos, Вы писали:ДП>Для меня проблемой является то, что инструментальные средства UML (да и сам язык UML) не заменяют мне карандаш, лист бумаги и текстовый процессор среды разработки, с помощью которых я проектирую и перепроектирую.

ДП>Я не против с помощью UML общаться даже сам с собою. Но, imho, UML должен быть частью среды разработки, неким метаязыком. Обобщенным взглядом на приложение и его части. Отдельные блоки приложения (структура, данные, алгоритмы и т.д.) при этом должны динамически выражаться на конкретных языках программирования.

Удивительно, но наши мнения в этом полностью совпадают.
Я считаю, что только тогда не нужны будут карандаш и лист бумаги, когда наши мысли будут записываться и расшифровываться непосредственно .

Здравствуйте, Аноним, Вы писали:

А>Принципиально новое следующее Bold поддерживает процесс разработки сверху вниз,

Поддерживает разработку сверху вниз? По-моему это ну совсем не принципиально новое. Сейчас что угодно поддерживает такую разработку(может быть вы имели что-то другое ввиду?).

А>т.е. от моделей к коду, решая всякие мелкие и не принципиальные задачи, полностью.

В стиле Delphi

А>При этом кое-где контролирует Ваши действия. Более подробно об этом можно почить, например, в "Компьютер-пресс", там был неплохой цикл статей про Bold. его в последствии на www.interface.ru опубликовали.

Спасибо за ссылку, когда будет время — почитаю.

Автогенерация кода, связь модели с кодом и т.п. в том виде, в каком оно есть сейчас — довольно примитивно в том смысле что упор ставится не на качество, а на количество. Гениальные вещи всегда просты. А пока никакой гениальности в средствах разработки я не вижу, вижу только улучшение удобства разработки за счёт огромных мощностей тех компаний, что их разрабатывают, ИМХО.

K>Автогенерация кода, связь модели с кодом и т.п. в том виде, в каком оно есть сейчас — довольно примитивно в том смысле что упор ставится не на качество, а на количество.

По мне так вобще из модели генерация кода довольно сомнительное удовольствие. А вот полноценная встроенная в среду синхронизация модели по коду, это действительно полезно.

Хотя бы для начала безглючный инструмент, для навигации по коду — для класса выдать всех наследников, все базовые классы, все зависимости итд. Хотя бы по простому в виде списков, без графических наворотов. А то ведь пока единственное надежное средство это изменить имя и по ошибкам компиляции искать зависимости.
Но только чтобы эта штука работала гарантированно во всех случаях (как при смене имени и компиляции).

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

S_>По мне так вобще из модели генерация кода довольно сомнительное удовольствие. А вот полноценная встроенная в среду синхронизация модели по коду, это действительно полезно.

я имел ввиду и синхронизацию в том числе

S_>Хотя бы для начала безглючный инструмент, для навигации по коду — для класса выдать всех наследников, все базовые классы, все зависимости итд. Хотя бы по простому в виде списков, без графических наворотов. А то ведь пока единственное надежное средство это изменить имя и по ошибкам компиляции искать зависимости.
S_>Но только чтобы эта штука работала гарантированно во всех случаях (как при смене имени и компиляции).

я только за

А что для потом?

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

S_> Все таки UML это не какая то методология проектирования, а больше метод представления данных. И все зависит от инструмента и задачи.

Естественно, но при проектировании задача представления данных играет зачастую большое значение. А если интегрировать процесс написания программы с "методом представления данных", то получим определённую методологию, основанную на UML.

S_> Но временами применение например RationalRose при проектировании вызывает некоторые ассоциации с такой штукой:
S_> Есть в VisualStudio гениальный визард, называется C# Add Method Wizard, для визуального добавления метода в класс. Спасибо конечно что автоматизировали эту процедуру, но я ей никогда не пользовался, потому что трудоемкость и затраты времени на добавление метода таким образом, как минимум на порядок больше чем вручную. Интересно, а для кого сделан этот визард? Кто нибудь хоть раз им пользовался?

В С# скорее всего,нет . А вот в C++ пользовался и не раз, там бывает легче с визардом(особенно когда проектик разрастается). Но это дело вкуса.