Re: ДлинныеТекстыСНедостаточноСвязаннойСистемойПонят ↑
ailev в посте Openmeta (оригинал в ЖЖ)
Насчет связанности системы понятий -- а это что? Как я определяю, достаточно или недостаточно связана система понятий в тексте? Не проще ли добавить связь понятий, чем извращаться с введением двигательного сюжета?
6 комментариев
сначала старые сначала новые
Я бы все-таки настаивал на различии двигательной лексики и двигательного сюжета.
--------------------------------
А настаивать не надо. Как раз это и подразумевается.
Можно говорить о ПонятийномСюжете. Это СюжетПервогоПлана.
А ДвигательныйСюжет он да же не на втором и не на третьем плане.
Если ПонятийнийСюжет уподобить Гамлету на сцене, читающему "быть или не быть", то двигательный сюжет это даже не декорация, это холст на котором нарисован замок.
Насчет связанности системы понятий -- а это что? Как я определяю, достаточно или недостаточно связана система понятий в тексте?
-----------------------------
Для СвязаннойСистемыПонятий можно построить граф.
Не проще ли добавить связь понятий,
-----------------------------
Конечно проще. Пожалуйста, приведите правила утановления СвязиПонятий.
чем извращаться с введением двигательного сюжета?
-----------------------------
Не от хорошей ПонятийнойЖизни.
--------------------------------
А настаивать не надо. Как раз это и подразумевается.
Можно говорить о ПонятийномСюжете. Это СюжетПервогоПлана.
А ДвигательныйСюжет он да же не на втором и не на третьем плане.
Если ПонятийнийСюжет уподобить Гамлету на сцене, читающему "быть или не быть", то двигательный сюжет это даже не декорация, это холст на котором нарисован замок.
Насчет связанности системы понятий -- а это что? Как я определяю, достаточно или недостаточно связана система понятий в тексте?
-----------------------------
Для СвязаннойСистемыПонятий можно построить граф.
Не проще ли добавить связь понятий,
-----------------------------
Конечно проще. Пожалуйста, приведите правила утановления СвязиПонятий.
чем извращаться с введением двигательного сюжета?
-----------------------------
Не от хорошей ПонятийнойЖизни.
![[userpic]](http://localhost:4000/images/none.gif)
Не проще ли добавить связь понятий, чем извращаться с введением двигательного сюжета?
---------
Во второй части фразы уже содержатся три полноценных слова с двигательной (причем шаговой) направленностью. И выглядит все же вполне типично для письменной речи..
Взаправду трудоемко установить именно связь понятий. Слишком много должно быть инструментов в тексте для качественной установки такой связи. Это прямо какие-то вторичные языки в тексте. Плюс добавьте необходимость устанавливать сами понятия, ибо не каждый читатель будет такими понятками обладать. Получаем сознательный перегруз.
Двигательная сфера структурирована очень четко, и текст в двигательном исполнении будет апеллировать прямехонько к подсознаниям читателей.
---------
Во второй части фразы уже содержатся три полноценных слова с двигательной (причем шаговой) направленностью. И выглядит все же вполне типично для письменной речи..
Взаправду трудоемко установить именно связь понятий. Слишком много должно быть инструментов в тексте для качественной установки такой связи. Это прямо какие-то вторичные языки в тексте. Плюс добавьте необходимость устанавливать сами понятия, ибо не каждый читатель будет такими понятками обладать. Получаем сознательный перегруз.
Двигательная сфера структурирована очень четко, и текст в двигательном исполнении будет апеллировать прямехонько к подсознаниям читателей.
Может быть так?
Диаграмма вариантов использования (use case diagram)
• 4.1. Вариант использования
• 4.2. Актеры
• 4.3. Интерфейсы
• 4.4. Примечания
• 4.5. Отношения на диаграмме вариантов использования
• Отношение ассоциации
• Отношение расширения
• Отношение обобщения
• Отношение включения
• 4.6. Пример построения диаграммы вариантов использования
• 4.7. Рекомендации по разработке диаграмм вариантов использования
Визуальное моделирование в UML можно представить как некоторый процесс поуровневого спуска от наиболее общей и абстрактной концептуальной модели исходной системы к логической, а затем и к физической модели соответствующей программной системы. Для достижения этих целей вначале строится модель в форме так называемой диаграммы вариантов использования (use case diagram), которая описывает функциональное назначение системы или, другими словами, то, что система будет делать в процессе своего функционирования. Диаграмма вариантов использования является исходным концептуальным представлением или концептуальной моделью системы в процессе ее проектирования и разработки.
Разработка диаграммы вариантов использования преследует цели:
• Определить общие границы и контекст моделируемой предметной области на начальных этапах проектирования системы.
• Сформулировать общие требования к функциональному поведению проектируемой системы.
• Разработать исходную концептуальную модель системы для ее последующей детализации в форме логических и физических моделей.
• Подготовить исходную документацию для взаимодействия разработчиков системы с ее заказчиками и пользователями.
Суть данной диаграммы состоит в следующем: проектируемая система представляется в виде множества сущностей или актеров, взаимодействующих с системой с помощью так называемых вариантов использования. При этом актером (actor) или действующим лицом называется любая сущность, взаимодействующая с системой извне. Это может быть человек, техническое устройство, программа или любая другая система, которая может служить источником воздействия на моделируемую систему так, как определит сам разработчик. В свою очередь, вариант использования (use case) служит для описания сервисов, которые система предоставляет актеру. Другими словами, каждый вариант использования определяет некоторый набор действий, совершаемый системой при диалоге с актером. При этом ничего не говорится о том, каким образом будет реализовано взаимодействие актеров с системой.
Примечание
Рассматривая диаграмму вариантов использования в качестве модели системы, можно ассоциировать ее с моделью черного ящика" (см. рис. 1.7). Действительно, подробная детализация данной диаграммы на начальном этапе проектирования скорее имеет отрицательный характер, поскольку предопределяет способы реализации поведения системы. А согласно рекомендациям RUP именно эти аспекты должны быть скрыты от разработчика на диаграмме вариантов использования.
В самом общем случае, диаграмма вариантов использования представляет собой граф специального вида, который является графической нотацией для представления конкретных вариантов использования, актеров, возможно некоторых интерфейсов, и отношений между этими элементами. При этом отдельные компоненты диаграммы могут быть заключены в прямоугольник, который обозначает проектируемую систему в целом. Следует отметить, что отношениями данного графа могут быть только некоторые фиксированные типы взаимосвязей между актерами и вариантами использования, которые в совокупности описывают сервисы или функциональные требования к моделируемой системе.
Как было отмечено в главе 3, рациональный унифицированный процесс разработки модели сложной системы представляет собой разбиение ее на составные части с минимумом взаимных связей на основе выделения пакетов.
Диаграмма вариантов использования (use case diagram)
• 4.1. Вариант использования
• 4.2. Актеры
• 4.3. Интерфейсы
• 4.4. Примечания
• 4.5. Отношения на диаграмме вариантов использования
• Отношение ассоциации
• Отношение расширения
• Отношение обобщения
• Отношение включения
• 4.6. Пример построения диаграммы вариантов использования
• 4.7. Рекомендации по разработке диаграмм вариантов использования
Визуальное моделирование в UML можно представить как некоторый процесс поуровневого спуска от наиболее общей и абстрактной концептуальной модели исходной системы к логической, а затем и к физической модели соответствующей программной системы. Для достижения этих целей вначале строится модель в форме так называемой диаграммы вариантов использования (use case diagram), которая описывает функциональное назначение системы или, другими словами, то, что система будет делать в процессе своего функционирования. Диаграмма вариантов использования является исходным концептуальным представлением или концептуальной моделью системы в процессе ее проектирования и разработки.
Разработка диаграммы вариантов использования преследует цели:
• Определить общие границы и контекст моделируемой предметной области на начальных этапах проектирования системы.
• Сформулировать общие требования к функциональному поведению проектируемой системы.
• Разработать исходную концептуальную модель системы для ее последующей детализации в форме логических и физических моделей.
• Подготовить исходную документацию для взаимодействия разработчиков системы с ее заказчиками и пользователями.
Суть данной диаграммы состоит в следующем: проектируемая система представляется в виде множества сущностей или актеров, взаимодействующих с системой с помощью так называемых вариантов использования. При этом актером (actor) или действующим лицом называется любая сущность, взаимодействующая с системой извне. Это может быть человек, техническое устройство, программа или любая другая система, которая может служить источником воздействия на моделируемую систему так, как определит сам разработчик. В свою очередь, вариант использования (use case) служит для описания сервисов, которые система предоставляет актеру. Другими словами, каждый вариант использования определяет некоторый набор действий, совершаемый системой при диалоге с актером. При этом ничего не говорится о том, каким образом будет реализовано взаимодействие актеров с системой.
Примечание
Рассматривая диаграмму вариантов использования в качестве модели системы, можно ассоциировать ее с моделью черного ящика" (см. рис. 1.7). Действительно, подробная детализация данной диаграммы на начальном этапе проектирования скорее имеет отрицательный характер, поскольку предопределяет способы реализации поведения системы. А согласно рекомендациям RUP именно эти аспекты должны быть скрыты от разработчика на диаграмме вариантов использования.
В самом общем случае, диаграмма вариантов использования представляет собой граф специального вида, который является графической нотацией для представления конкретных вариантов использования, актеров, возможно некоторых интерфейсов, и отношений между этими элементами. При этом отдельные компоненты диаграммы могут быть заключены в прямоугольник, который обозначает проектируемую систему в целом. Следует отметить, что отношениями данного графа могут быть только некоторые фиксированные типы взаимосвязей между актерами и вариантами использования, которые в совокупности описывают сервисы или функциональные требования к моделируемой системе.
Как было отмечено в главе 3, рациональный унифицированный процесс разработки модели сложной системы представляет собой разбиение ее на составные части с минимумом взаимных связей на основе выделения пакетов.
Это объект-ориентированный подход. Программисты будут рукоплескать, UML лет пять назад это был последний всхлип моды. До этого у программистов был десяток лет подход пакетов, которому так же рукоплескали, и который был поглощен объектно-ориентированным подходом. Вопрос: а что у программистов на горизонте? Объектно-ориентированный подход загадил уже все мозги и стал мейнстримом. Что сейчас варится в маленьких маргинальных лабораториях, подходит нам больше, и плохо только тем, что не "лежит на поверхности"? Почему никто не использует промышленно функциональное программирование, но нет программистов, которые не мечтали бы его использовать?
Мне кажется, что UML сейчас -- это явно лишнее. Это прихват еще одной большой предметной области, прихват весьма специфического алгоритмического мышления. Общая мысль верна: программирование (любое, хоть на древних языках) дисциплинирует мышление, помогает разобраться с "понятийностью". Программирование -- это квинтэссенция моделирования (почитайте байки, чем программистское мышление отличается от математического и физического -- такие байки любил рассказывать Дейкстра, например http://pascal.sources.ru/cgi-bin/forum/YaBB.cgi?board=flame;action=display;num=1014133623 ). Но это нужно еще думать и думать, требовать ли от опенметисов обязательной такой тренировки. Беда в том, что половина наблюдателей тут эту тренировку так или иначе имеет, а половина нет. Вот и нужно думать, что делать.
Смысл сказанного: не нужно тут использовать инструменты для собственно программирования, нужно использовать уже поставленное программистское (понятийное) мышление. Т.е. тут не использовать сам UML, а использовать те приемы размышления, которые развивает использование UML в других задачах, для которых он непосредственно предназначен. Может, требовать в пререквизитах не только НЛП-мастера и чтения Кастанеды, но и какого-то программистского опыта (не образования -- знаем мы это "образование", нам метанойя соответствующая нужна ;)
Мне кажется, что UML сейчас -- это явно лишнее. Это прихват еще одной большой предметной области, прихват весьма специфического алгоритмического мышления. Общая мысль верна: программирование (любое, хоть на древних языках) дисциплинирует мышление, помогает разобраться с "понятийностью". Программирование -- это квинтэссенция моделирования (почитайте байки, чем программистское мышление отличается от математического и физического -- такие байки любил рассказывать Дейкстра, например http://pascal.sources.ru/cgi-bin/forum/YaBB.cgi?board=flame;action=display;num=1014133623 ). Но это нужно еще думать и думать, требовать ли от опенметисов обязательной такой тренировки. Беда в том, что половина наблюдателей тут эту тренировку так или иначе имеет, а половина нет. Вот и нужно думать, что делать.
Смысл сказанного: не нужно тут использовать инструменты для собственно программирования, нужно использовать уже поставленное программистское (понятийное) мышление. Т.е. тут не использовать сам UML, а использовать те приемы размышления, которые развивает использование UML в других задачах, для которых он непосредственно предназначен. Может, требовать в пререквизитах не только НЛП-мастера и чтения Кастанеды, но и какого-то программистского опыта (не образования -- знаем мы это "образование", нам метанойя соответствующая нужна ;)
Программирование -- это квинтэссенция моделирования (почитайте байки, чем программистское мышление отличается от математического и физического -- такие байки любил рассказывать Дейкстра, например 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, рациональный унифицированный процесс разработки модели сложной системы представляет собой разбиение ее на составные части с минимумом взаимных связей на основе выделения пакетов
---------------------------------
Золотые слова.