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

Да я и сам не прочь убедиться 

Единственно, что цепляет. Так вот UML, IDEF и прочие штучки, даже самое ООП, не везде вообщем-то приживается, порой просто отторгается, не принимается.

Причина вполне понятна - и так работаем, и вроде получается, и даже зарабатываем. А освоение нового, да еще не понятного, только со слов кого-то действенное - настораживает. Понятно, что для освоения нужно: раз, два, три, четыре - да ну ее в болото...

Пример из жизни. В начале года на предмете Web-технологии возглашаю:

"Милостливые студенты! Мы будем с вами изучать PHP. Мы будем изучать его в стиле ООП. За ООП разработку на языке РНР - бонус."

Есть достаточно богатый разработанный пример для ООП - целый струмент с фронтэндом, админкой. На нем построен курс практики. Сначал все скурпулезно объясняется почему так, а как иначе. Предлагается усе повторить, а затем добавить свои фичи (задания отображаются синеньким цветом).

Для проверки знаний устраиваю контрольные. Алгоритмы простенькие. Задачки беру из методички 1 курса по паскалю. Естественно прошу реализовать на РНР, и не просто реализовать а постараться показать свою профпригодность. Куда-там! сплошной линейный код с кучей условий и циклов, в лучшем случае кто-то сруппирует это по функциям и то совершенно не корректно: каждой функции свое действие. Про использование объектов - вообще молчу. Хотя мой выстраданный пример - бери и пользуйся. Сложно мыслить объектно!

Т.е. для перехода на что-то новое должна быть какая-то нетривиальная проблема, которая просто заставит потратить силы на изменение.

Конечно есть еще волшебное слово пиар. Возможно UML - это пиар? И все что с ним связано? Может нужно чтобы прошло лет 10-20, чтобы UML воспринимался так же как обычные блок-схемы?

По поводу UML вместо естественного языка:
- наверное, это возможно - все ведь помнят мат. анализ с его интернациональным формальным языком (хотя, как выясняется, у каждого математика - свой диалект этого языка);
- это расходится с agile методологиями, в которых, как известно, главный носитель знаний - не документ, а человек;
- созданная модель будет понятна только архитекторам (хотя бы "по совместительству"); как объяснять новому участнику команды, о чём вообще эта модель без слов - не представляю; а ведь модель как раз и нужна, чтобы её ВСЕ использовали в виде справочника.

<...>Для проверки знаний устраиваю контрольные. Алгоритмы простенькие. Задачки беру из методички 1 курса по паскалю. Естественно прошу реализовать на РНР, и не просто реализовать а постараться показать свою профпригодность. Куда-там! сплошной линейный код с кучей условий и циклов, в лучшем случае кто-то сруппирует это по функциям и то совершенно не корректно: каждой функции свое действие. Про использование объектов - вообще молчу. Хотя мой выстраданный пример - бери и пользуйся. Сложно мыслить объектно!
<...>

Всё правильно. Студенты - умные и ленивые, алгоритмы простые, ресурсы (особенно временнЫе) у них на контрольной ограничены. Вот они и идут более естественным способом. Вот если бы Вы разделили их на команды и дали каждой команде огромный курсовик (есть у них бух. учёт? ИС бух. учёта) - могли бы увидеть как минимум структурное программирование и правильную разбивку по функциям.

Всё правильно. Студенты - умные и ленивые, алгоритмы простые, ресурсы (особенно временнЫе) у них на контрольной ограничены. Вот они и идут более естественным способом.

Согласен. Золотые слова - они идут естественным способом. Что значит естественным, кто сказал, что линейный код естественный? Это для 5 курса естественный код?
Вот Вам и реперная точка, вот и критерий для проверки профпригодности.
Да они сразу должны мылсить объектно, структурно как минимум. Почему не получается? Потому как такова система образования (по крайней мере на нашей кафедре). Что очень жаль.
Потому для них структурный код или ОО код - неестественный
А ведь стоит учесть еще и тот факт, что это 5 курс после сдачи квалификационной работы на бакалавра!!!

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

Alex, давайте не будем путать божий дар с яичницей. Все-таки курс у меня другой, задача подобная бух учету решается на 3 курсе в рамках соотвествующих дисциплин - смотрите мои опыты преподавания в разделе Обучения.
Прадва бухучета у них нет как предмета, что конечно сильно жаль.

ИМХО попытка ограничиться использованием исключительно UML пока преждевременна. Очевидно, что это сильно сужает выразительные средства участников создания системы (как со стороны Заказчика, так и со стороны разработчиков). А цель? Ускорение (удешевление) разработки? Более точный учет требований в коде? Более точное соответствие формулировки требований реальному смыслу, который в них вкладывает Заказчик?

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

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

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

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

Правда презентации не дают возможности понять как же все это реально работает. При этом возникает вопросы:
1. Что значит отличное знание UML и ООП?
2. Как достичь у студентов этого знания, что нужно предпринять для этого? Хотя ответ дан в виде повторяющихся слов Практика, но вопрос как ее грамотно обеспечить? Т.е. что и как надо организовать в процессе обучения

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

Правда презентации не дают возможности понять как же все это реально работает.

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

Радует хотя бы то, что Владимир готов выезжать в вузы и проводить семинары и тренинги бесплатно!

Опана?! Это где написано. Может пригласим кого-то из их инста на семинар??

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

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

Опана?! Это где написано. Может пригласим кого-то из их инста на семинар??

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

В презентации вообще описана методика проведения семинара, однако она требует хорошей подготовки самих студентов- раз, супер подготовки тренера - два.

Тут как раз с первым и есть проблема: как хорошо подготовить студентов. Вроде в презентациях дается некий ответ: обучение UML и OO в пантомимах, но что это есть не совсем понял.

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