Re: ДлинныеТекстыСНедостаточноСвязаннойСистемойПонят ↑
ailev в посте Openmeta (оригинал в ЖЖ)
Какая-то лексика -- да, можно использовать. Но уж сюжетные линии вставлять -- боюсь, не получится.
10 комментариев
сначала старые сначала новые
Ага, а потом изложить в этом телесно-двигательном стиле регламенты административной реформы, учебник химии для младших классов, учебник Общество-экономика-право и другие ДлинныеТексты,
--------------------------------------------------
1 В любом тексте 10-20% лексики будет ДвигательноВоспринимательной. Она не передает основного содержания, но без нее просто невозможно ни писать, ни говорить, ни думать.
не забывая, что у нас обсуждается не художественная литература для кинестетиков.
-------------------------------------------
ДвигательныхКинестетиков. Любой живой человек является двигательным кинестетиком: "Двигаюсь, следовательно существую".
Вы не обратили внимания на то что я написал: "СНедостаточноСвязаннойСистемойПонятий." А Ваши примеры указывают на ДлинныеТекстыСХорошоФормализованнойСистемойПонятий.
--------------------------------------------------
1 В любом тексте 10-20% лексики будет ДвигательноВоспринимательной. Она не передает основного содержания, но без нее просто невозможно ни писать, ни говорить, ни думать.
не забывая, что у нас обсуждается не художественная литература для кинестетиков.
-------------------------------------------
ДвигательныхКинестетиков. Любой живой человек является двигательным кинестетиком: "Двигаюсь, следовательно существую".
Вы не обратили внимания на то что я написал: "СНедостаточноСвязаннойСистемойПонятий." А Ваши примеры указывают на ДлинныеТекстыСХорошоФормализованнойСистемойПонятий.
Я бы все-таки настаивал на различии двигательной лексики и двигательного сюжета.
Насчет связанности системы понятий -- а это что? Как я определяю, достаточно или недостаточно связана система понятий в тексте? Не проще ли добавить связь понятий, чем извращаться с введением двигательного сюжета?
Насчет связанности системы понятий -- а это что? Как я определяю, достаточно или недостаточно связана система понятий в тексте? Не проще ли добавить связь понятий, чем извращаться с введением двигательного сюжета?
Я бы все-таки настаивал на различии двигательной лексики и двигательного сюжета.
--------------------------------
А настаивать не надо. Как раз это и подразумевается.
Можно говорить о ПонятийномСюжете. Это СюжетПервогоПлана.
А ДвигательныйСюжет он да же не на втором и не на третьем плане.
Если ПонятийнийСюжет уподобить Гамлету на сцене, читающему "быть или не быть", то двигательный сюжет это даже не декорация, это холст на котором нарисован замок.
Насчет связанности системы понятий -- а это что? Как я определяю, достаточно или недостаточно связана система понятий в тексте?
-----------------------------
Для СвязаннойСистемыПонятий можно построить граф.
Не проще ли добавить связь понятий,
-----------------------------
Конечно проще. Пожалуйста, приведите правила утановления СвязиПонятий.
чем извращаться с введением двигательного сюжета?
-----------------------------
Не от хорошей ПонятийнойЖизни.
--------------------------------
А настаивать не надо. Как раз это и подразумевается.
Можно говорить о ПонятийномСюжете. Это СюжетПервогоПлана.
А ДвигательныйСюжет он да же не на втором и не на третьем плане.
Если ПонятийнийСюжет уподобить Гамлету на сцене, читающему "быть или не быть", то двигательный сюжет это даже не декорация, это холст на котором нарисован замок.
Насчет связанности системы понятий -- а это что? Как я определяю, достаточно или недостаточно связана система понятий в тексте?
-----------------------------
Для СвязаннойСистемыПонятий можно построить граф.
Не проще ли добавить связь понятий,
-----------------------------
Конечно проще. Пожалуйста, приведите правила утановления СвязиПонятий.
чем извращаться с введением двигательного сюжета?
-----------------------------
Не от хорошей ПонятийнойЖизни.
![[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, рациональный унифицированный процесс разработки модели сложной системы представляет собой разбиение ее на составные части с минимумом взаимных связей на основе выделения пакетов
---------------------------------
Золотые слова.
Ага, а потом изложить в этом телесно-двигательном стиле регламенты административной реформы, учебник химии для младших классов, учебник Общество-экономика-право и другие ДлинныеТексты, не забывая, что у нас обсуждается не художественная литература для кинестетиков
---------------
Конечно, если планы административных реформ и учебники лдя общеобразовательной школы будут по критериям подходить к Длинным Текстам, то есть читаться на одном дыхании словно художественная литература. Чтобы наши школьники стали читать взахлеб учебник по химии, придется формировать еще один топик под названием "Методики Всепоглощающей Мотивации".
---------------
Конечно, если планы административных реформ и учебники лдя общеобразовательной школы будут по критериям подходить к Длинным Текстам, то есть читаться на одном дыхании словно художественная литература. Чтобы наши школьники стали читать взахлеб учебник по химии, придется формировать еще один топик под названием "Методики Всепоглощающей Мотивации".
ну, тут уже предлагалось все немотивирующие на действия ~метафоры называть неметафорами, аллегориями, байками. Так и ~ДлинныеТексты, не мотивирующие на действие лучше называть как-нибудь по-другому -- ДлинныеНаборыСлов, например.
Насчет "всепоглощающей мотивации" -- см. тут треды по метафорам и "повелительным наклонениям" в них.
Насчет "всепоглощающей мотивации" -- см. тут треды по метафорам и "повелительным наклонениям" в них.