Re: UML нам поможет ↑
ailev в посте Openmeta (оригинал в ЖЖ)
Мне кажется, что UML сейчас -- это явно лишнее. Это прихват еще одной большой предметной области, прихват весьма специфического алгоритмического мышления. Общая мысль верна: программирование (любое, хоть на древних языках) дисциплинирует мышление, помогает разобраться с "понятийностью". Программирование -- это квинтэссенция моделирования (почитайте байки, чем программистское мышление отличается от математического и физического -- такие байки любил рассказывать Дейкстра, например http://pascal.sources.ru/cgi-bin/forum/YaBB.cgi?board=flame;action=display;num=1014133623 ). Но это нужно еще думать и думать, требовать ли от опенметисов обязательной такой тренировки. Беда в том, что половина наблюдателей тут эту тренировку так или иначе имеет, а половина нет. Вот и нужно думать, что делать.
Смысл сказанного: не нужно тут использовать инструменты для собственно программирования, нужно использовать уже поставленное программистское (понятийное) мышление. Т.е. тут не использовать сам UML, а использовать те приемы размышления, которые развивает использование UML в других задачах, для которых он непосредственно предназначен. Может, требовать в пререквизитах не только НЛП-мастера и чтения Кастанеды, но и какого-то программистского опыта (не образования -- знаем мы это "образование", нам метанойя соответствующая нужна ;)
2 комментария
сначала старые сначала новые
Программирование -- это квинтэссенция моделирования (почитайте байки, чем программистское мышление отличается от математического и физического -- такие байки любил рассказывать Дейкстра, например http://pascal.sources.ru/cgi-bin/forum/YaBB.cgi?board=flame;action=display;num=1014133623 ).
--------------------------------------------
Для ОпенМетаМоделиста байка Дейкстры не смешная. "Вагоны" которые приходится СОРТИРовать ОММоделисту ездят по путям станции в N-мерном пространстве.
Но это нужно еще думать и думать, требовать ли от опенметисов обязательной такой тренировки.
---------------------------------------------
Не один раз предпиринимал попытки нарисовать графическую схему несложной НЛПмодели с достаточно подробным отражением того как она работает. Итог один- схема нечитабельная из-за чрезмерной сложности.
Беда в том, что половина наблюдателей тут эту тренировку так или иначе имеет, а половина нет.
--------------------------------------------
Это не та тренировка. Уважаемые прогаммисты, умелые в объектно ориентированных подходах, никогда не не расписывали программ для ПсихологическогоМоделирования.
Вот и нужно думать, что делать.
-------------------------------
Нужен Метлан в двух видах:
1 Для писания текстов.
2 Для графического отражения того что написано в текстах.
Смысл сказанного: не нужно тут использовать инструменты для собственно программирования,
----------------------------
Я этого не предлагал.
нужно использовать уже поставленное программистское (понятийное) мышление.
----------------------------
Нужны инструменты для ФОРМИРОВАНИЯ (и выражения) ТретьеКодовогоМышления. ТКМышление конечно относится к классу ПрограммисткихМышлений, но оно не является в точности УжеПоставленнымПрограммисткимМышлением.
Т.е. тут не использовать сам UML,
----------------------------------
Надо перемоделировать UML в то что нужно для нас.
а использовать те приемы размышления, которые развивает использование UML в других задачах, для которых он непосредственно предназначен.
----------------------------------
Именно это. Например: (см. следующий)
--------------------------------------------
Для ОпенМетаМоделиста байка Дейкстры не смешная. "Вагоны" которые приходится СОРТИРовать ОММоделисту ездят по путям станции в N-мерном пространстве.
Но это нужно еще думать и думать, требовать ли от опенметисов обязательной такой тренировки.
---------------------------------------------
Не один раз предпиринимал попытки нарисовать графическую схему несложной НЛПмодели с достаточно подробным отражением того как она работает. Итог один- схема нечитабельная из-за чрезмерной сложности.
Беда в том, что половина наблюдателей тут эту тренировку так или иначе имеет, а половина нет.
--------------------------------------------
Это не та тренировка. Уважаемые прогаммисты, умелые в объектно ориентированных подходах, никогда не не расписывали программ для ПсихологическогоМоделирования.
Вот и нужно думать, что делать.
-------------------------------
Нужен Метлан в двух видах:
1 Для писания текстов.
2 Для графического отражения того что написано в текстах.
Смысл сказанного: не нужно тут использовать инструменты для собственно программирования,
----------------------------
Я этого не предлагал.
нужно использовать уже поставленное программистское (понятийное) мышление.
----------------------------
Нужны инструменты для ФОРМИРОВАНИЯ (и выражения) ТретьеКодовогоМышления. ТКМышление конечно относится к классу ПрограммисткихМышлений, но оно не является в точности УжеПоставленнымПрограммисткимМышлением.
Т.е. тут не использовать сам UML,
----------------------------------
Надо перемоделировать UML в то что нужно для нас.
а использовать те приемы размышления, которые развивает использование UML в других задачах, для которых он непосредственно предназначен.
----------------------------------
Именно это. Например: (см. следующий)
Рассматривая диаграмму вариантов использования в качестве модели системы, можно ассоциировать ее с моделью черного ящика" (см. рис. 1.7).
--------------------------------------------------------
Рассмотрим ситуацию: Алиса применяет некоторую Модель к Бобу.
Не смотря на то, что все согласятся, что в самом общем виде для нас предметом рассмотрения является Модель, в качестве ЧерногоЯщика, не долго думая, хочется поставить СубстратБоба.
Вот мы исписали уже не мало текстов (и пришли к согласию, хотя и "размазанному" по этим текстам) для выражения некоторой важной мысли. А на ДиаграммеВариантовИспользованияМодели она выражается на 10 кв.см. экрана:
В качестве ЧерногоЯщика надо рисовать Модель!
Действительно, подробная детализация данной диаграммы на начальном этапе проектирования скорее имеет отрицательный характер, поскольку предопределяет способы реализации поведения системы. А согласно рекомендациям RUP именно эти аспекты должны быть скрыты от разработчика на диаграмме вариантов использования.
------------------------------------
А вот если поставить СубстратБоба, тогда ЧрезмернойДетализации не избежать.
В самом общем случае, диаграмма вариантов использования представляет собой граф специального вида, который является графической нотацией для представления конкретных вариантов использования, актеров, возможно некоторых интерфейсов, и отношений между этими элементами.
--------------------------------------
Итак мы выбрали для разрисовывания Модель. А дальше получается инереснейшая картина. АнтрпоцентрическоеПредставлениеМоделиКакРолевогоВзаимодействияСубъектов исчезает. Теперь у нас нет отдельно взятых Алисы и Боба:
1 Некототорые части (процессы) субстрата и Боба, и Алисы окажутся разными Актерами.
2 Некоторые части (процессы) субстрата обоих окажутся use case-ами.
3 Некотрые - интерфейсами.
(кажется не наврал)
И таким манером можно продолжать по всем диаграммам. При этом мы не используем язык программирования. Мы используем СпособТакДумать. Вот если так переосмыслить наш предмет, то и объяснение его в ДлинныхТекстах станет последовательным и гораздо более понятным. Более того, это ЕДИНСтВЕННЫЙ прояснить все заморочки вокруг МоделированияЧеловеков.
При этом отдельные компоненты диаграммы могут быть заключены в прямоугольник, который обозначает проектируемую систему в целом. Следует отметить, что отношениями данного графа могут быть только некоторые фиксированные типы взаимосвязей между актерами и вариантами использования, которые в совокупности описывают сервисы или функциональные требования к моделируемой системе.
---------------------------------------
По-первости это будет рисоваться. Впоследствии эти диаграммы интериоризируются и станут ВнутреннимиПрограммамиСубстрата.
Ну а ГрафическаяКомпонентаМетлана может быть развита до программы, способной генерировать на искусственном языке программые коды.
Как было отмечено в главе 3, рациональный унифицированный процесс разработки модели сложной системы представляет собой разбиение ее на составные части с минимумом взаимных связей на основе выделения пакетов
---------------------------------
Золотые слова.
--------------------------------------------------------
Рассмотрим ситуацию: Алиса применяет некоторую Модель к Бобу.
Не смотря на то, что все согласятся, что в самом общем виде для нас предметом рассмотрения является Модель, в качестве ЧерногоЯщика, не долго думая, хочется поставить СубстратБоба.
Вот мы исписали уже не мало текстов (и пришли к согласию, хотя и "размазанному" по этим текстам) для выражения некоторой важной мысли. А на ДиаграммеВариантовИспользованияМодели она выражается на 10 кв.см. экрана:
В качестве ЧерногоЯщика надо рисовать Модель!
Действительно, подробная детализация данной диаграммы на начальном этапе проектирования скорее имеет отрицательный характер, поскольку предопределяет способы реализации поведения системы. А согласно рекомендациям RUP именно эти аспекты должны быть скрыты от разработчика на диаграмме вариантов использования.
------------------------------------
А вот если поставить СубстратБоба, тогда ЧрезмернойДетализации не избежать.
В самом общем случае, диаграмма вариантов использования представляет собой граф специального вида, который является графической нотацией для представления конкретных вариантов использования, актеров, возможно некоторых интерфейсов, и отношений между этими элементами.
--------------------------------------
Итак мы выбрали для разрисовывания Модель. А дальше получается инереснейшая картина. АнтрпоцентрическоеПредставлениеМоделиКакРолевогоВзаимодействияСубъектов исчезает. Теперь у нас нет отдельно взятых Алисы и Боба:
1 Некототорые части (процессы) субстрата и Боба, и Алисы окажутся разными Актерами.
2 Некоторые части (процессы) субстрата обоих окажутся use case-ами.
3 Некотрые - интерфейсами.
(кажется не наврал)
И таким манером можно продолжать по всем диаграммам. При этом мы не используем язык программирования. Мы используем СпособТакДумать. Вот если так переосмыслить наш предмет, то и объяснение его в ДлинныхТекстах станет последовательным и гораздо более понятным. Более того, это ЕДИНСтВЕННЫЙ прояснить все заморочки вокруг МоделированияЧеловеков.
При этом отдельные компоненты диаграммы могут быть заключены в прямоугольник, который обозначает проектируемую систему в целом. Следует отметить, что отношениями данного графа могут быть только некоторые фиксированные типы взаимосвязей между актерами и вариантами использования, которые в совокупности описывают сервисы или функциональные требования к моделируемой системе.
---------------------------------------
По-первости это будет рисоваться. Впоследствии эти диаграммы интериоризируются и станут ВнутреннимиПрограммамиСубстрата.
Ну а ГрафическаяКомпонентаМетлана может быть развита до программы, способной генерировать на искусственном языке программые коды.
Как было отмечено в главе 3, рациональный унифицированный процесс разработки модели сложной системы представляет собой разбиение ее на составные части с минимумом взаимных связей на основе выделения пакетов
---------------------------------
Золотые слова.