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

А что еще за трудно различимые стрелочки? Ты как различаешь Е от Ё или И от Й - это сложно для тебя? А каково чеху или французу или немцу с умляутами ...
Начертание шрифтов? Это ты имеешть в виду абстрактный класс или конкретный
А что за символы пунктуации? [] / {} - эти?
Про черно белость и соглашусь и нет, порой такую попугаистость на диаграммах видишь - впору застрелиться

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

будет проще, если ты приведешь небольшие примерчики

Спецификация языка разбухла уже до двух книг суммарным объёмом больше чем в 1000 страниц. Это делает его очень узкоспециализированным. Я думаю, применимость UML как формального языка, нотацию которого нужно специально изучать и строго соблюдать, очень ограничена.

А разве другой язык не следует изучать? Сколько лет пришлось изучать русский? А иностранный? Но я согласен, когда спецификация так велика, то понять язык маловероятно правильно когда-либо

Лично я использую названия диаграмм из UML, никогда фактически не соблюдая нотацию. Для меня UML - это прежде всего способ обмена информацией между людьми. Удачные (с моей точки зрения, конечно) элементы я использую, а неудачные игнорирую.

Главное, чтобы другие тебя понимали. И если изучая язык независимо от тебя, они легко понимают твои адаптированные диаграммы, может это не так уж и плохо?

Очень интересно. Каким образом вам удаётся сделать это с помощью UML?

Я один раз столкнулся с ситуацией когда одна ДВИ нарисованная за час в Rational Rose совершила прорыв в переговорах, находившихся в тупике уже несколько недель. Она предельно наглядно выявила точки непонимания между заказчиком и подрядчиком и буквально за пару дней все вопросы были решены и дальше дело пошло хорошо и без UML.

Вот это я и имел в виду. К сожалению более подробной статистики у меня нет, но если с выявлением ролей и полезной активности UML справляется успешно, почему бы и не использовать его?

сообщение устарело

Про "Унифицированный язык, что-то объединяющий" и обоснование моей позиции я написала подробнее. http://edu.reqcenter.pro/?p=3505 Лирика скорее для себя, можете первые два абзаца пропустить.

С интересом прочту опровержение моей точки зрения, подкрепленной цитатами и ссылками на различные исследования.

Пожалуй, возразить нечего. А анализ очень интересный.

Лишь миллиметровое замечание
"Для ссылки в научной работе, в соответствии с ГОСТ 7.1-2003, правильно использовать"
ГОСТ 7.1-2003 «Библиографическая запись. Библиографическое описание», а следует использовать  ГОСТ Р 7.0.5-2008 «Библиографическая ссылка»

Не сочтите за назойливость и педантство, но

Мадорская Ю.М. Неожиданно про UML… История и проблемы. [электронный ресурс]/Ю.М. Мадорская, 2013. — Режим доступа: http://www.reqcenter.pro, свободный. — Загл. с экрана

сейчас должно выглядеть как
Мадорская Ю.М. Неожиданно про UML… История и проблемы [Электронный ресурс] // ReqCenter.pro Согласованные знания для практического использования, 2013. URL: http://edu.reqcenter.pro/?p=3505 (дата обращения: 21.02.2013)
или
Мадорская Ю.М. Неожиданно про UML… История и проблемы [Электронный ресурс], 2013. URL: http://edu.reqcenter.pro/?p=3505 (дата обращения: 21.02.2013)

сообщение устарело

сообщение устарело

Не сочту! Большое спасибо за помощь! Ужасно не люблю составлять эти ссылки.

Не реально эти требования по электронным ссылкам вообще запутаны.

По теме есть две статьи Алекса Белла о "лихорадке UML", опубликованные в ACM Queue: 1, 2.
По SEMATу вчера было выступление в МГУ Б. А. Позина, возглавляющего российский филиал SEMAT. SEMAT ортогонален нотациям и преследует, как мне кажется, другие цели. В том же ACM Queue появился [рекламный)] материал о SEMATовской книжке: 3.

сообщение устарело

Спасибо за ссылки! Подтвердили все гипотезы, написанные в статье.

Еще раз внимательно перечитал вашу статью. Заинтересовало открытие ШНоля, в чем вы видите здесь аналогию?

Далее вы цитируете, что производя объединение трех МЕТОДОВ, основатели UML столкнулись с трудностями. И решили стандартизировать нотацию.

Т.е. по сути создали язык, метод же его использования заложен в RUP или ICONIX, хотя RUP это же развитие Objectory от Якобсона, если я не ошибаюсь. Понимаю, метод остался за рамками языка и передан куда-то выше, ну вот мы видим в SEMAT. Правильно я понимаю?

Не совсем понятен вывод о влиянии понятия Клиент Абонент Заказчик услуг на архитектуру системы и частности языка UML. Что есть архитектура UML? Совокупность правил преобразования А в Б?

сообщение устарело

Попробуйте, пожалуйста, точнее сформулировать вопросы. Не совсем понятно, что именно Вы хотите спросить.

Я что-то сам уже не понял, что хотел спросить:)

Наверное, я хотел бы отметить, что может нет никакой проблемы UML, а есть проблема самого метода ООАП. На эту тему вот пост http://askofen.blogspot.ru/2011/11/1.html. Я вначале даже пытался найти возражения, но ведь реально, есть системный подход и системные методы.

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