... ↑
eugzol в посте Metapractice (оригинал в ЖЖ)
Мы пытаемся разным диаграммам найти разное применение, или же сразу пытаемся целостное отображение сделать из разработки/использования софта в моделирование/техники?
23 комментария
сначала старые сначала новые
Нее. Мы берет типа шестишаговый рефрейминг. Как технику, как модель, как упражнение и еще бог знает как.
Потом, мы смотрим на диаграммы и пытаемся сообразить - какими диаграммами и что конкретно из наших знаний по р. мы можем изобразить.
После этого уже можно будет попробовать на самом деле это проделать - построить диаграммы в отношении шестишагового рефрейминга.
Потом, мы смотрим на диаграммы и пытаемся сообразить - какими диаграммами и что конкретно из наших знаний по р. мы можем изобразить.
После этого уже можно будет попробовать на самом деле это проделать - построить диаграммы в отношении шестишагового рефрейминга.
А есть на примете какая-нибудь техника по-проще, но не хуже формализованная?
Интеграция якорей. Мета вопросы.
Решил в этот же проход добавить диаграммы BPMN.
Для того, чтобы разобраться как рисовать диаграммы, того же шестишагового рефрейминга, надо решить, кому мы будем её показывать:
- всем, в том числе субъекту?
- только оператору в качестве подсказки/обучения?
- только моделисту?
Для того, чтобы разобраться как рисовать диаграммы, того же шестишагового рефрейминга, надо решить, кому мы будем её показывать:
- всем, в том числе субъекту?
- только оператору в качестве подсказки/обучения?
- только моделисту?
А сколько еще есть диаграмм?
Диаграммы мы рисуем, чтобы моделист1 мог их показывать моделисту2.
Вроде решили начать с постановки якорей.
Диаграммы мы рисуем, чтобы моделист1 мог их показывать моделисту2.
Вроде решили начать с постановки якорей.
А сколько еще есть диаграмм?
Да вроде больше нету. Даже этот перечень уже избыточен, включил в себя некоторые редко используемые на практике диаграммы из UML.
Диаграммы мы рисуем, чтобы моделист1 мог их показывать моделисту2.
Понятно.
Вроде решили начать с постановки якорей.
Ну, в любом случае для начала надо вытащить текстовое пошаговое описание.
Да вроде больше нету. Даже этот перечень уже избыточен, включил в себя некоторые редко используемые на практике диаграммы из UML.
Диаграммы мы рисуем, чтобы моделист1 мог их показывать моделисту2.
Понятно.
Вроде решили начать с постановки якорей.
Ну, в любом случае для начала надо вытащить текстовое пошаговое описание.
Да, для начала - текстовое пошаговое.
А откуда взять его для якорения? Восстанавливать по транскрипту?
Да зачем транскрипт.
Можем и сами расписать в свободной манере ту или иную интрукцию - вариант интеграции якорей.
Можем и сами расписать в свободной манере ту или иную интрукцию - вариант интеграции якорей.
(1) Субъект испытывает разные переживания.
(2) Оператор выделяет из них две группы: ресурсные и нересурсные.
(3) Оператор выделяет из нересурсных одно нересурсное переживание или нересурсную тему.
(4) Оператор заставляет субъекта пережить выбранное нересурсное переживание или тему.
(5) Оператор ставит на нересурсное переживание/тему якорьН.
(6) Оператор заставляет субъекта переживать нейтральное состояние.
(7) Оператор заставляет субъекта переживать ресурсные переживания.
(8) Оператор ставит на ресурсные переживания якорьР.
(9) Оператор калибрует полученные якоряН и Р путем их чередования с нейтральным переживанием.
(10) Затем, на фоне нейтрального переживания, оператор активизирует одновременно якорьР + якорьН и дожидается их интеграции, обнаруживаемой по наблюдению смешанной невербальной реакции.
(11) Затем оператор калибрует результат интеграции путем оживления одного из якорей и отслеживания появления смешанной реакции.
(2) Оператор выделяет из них две группы: ресурсные и нересурсные.
(3) Оператор выделяет из нересурсных одно нересурсное переживание или нересурсную тему.
(4) Оператор заставляет субъекта пережить выбранное нересурсное переживание или тему.
(5) Оператор ставит на нересурсное переживание/тему якорьН.
(6) Оператор заставляет субъекта переживать нейтральное состояние.
(7) Оператор заставляет субъекта переживать ресурсные переживания.
(8) Оператор ставит на ресурсные переживания якорьР.
(9) Оператор калибрует полученные якоряН и Р путем их чередования с нейтральным переживанием.
(10) Затем, на фоне нейтрального переживания, оператор активизирует одновременно якорьР + якорьН и дожидается их интеграции, обнаруживаемой по наблюдению смешанной невербальной реакции.
(11) Затем оператор калибрует результат интеграции путем оживления одного из якорей и отслеживания появления смешанной реакции.
(1) Субъект:
--генерирует состояния.
--генерирует сигналы
--заполняет интерфейс экспрессии
(2) Оператор:
--сортирует состояния субъекта на ресурсные нересурсные
--заполняет интерфейс оператора
--реализует раппорт
--реализует БОС
…
(3) Оператор выделяет из нересурсных одно нересурсное переживание/ нересурсную тему.
(4) Оператор заставляет субъекта пережить выбранное нересурсное переживание или тему.
(5) Оператор ставит на нересурсное переживание/тему якорьН.
(6) Оператор заставляет субъекта переживать нейтральное состояние.
(7) Оператор заставляет субъекта переживать ресурсные переживания.
(8) Оператор ставит на ресурсные переживания якорьР.
(9) Оператор калибрует полученные якоряН и Р путем их чередования с нейтральным переживанием.
(10) Затем, на фоне нейтрального переживания, оператор активизирует одновременно якорьР + якорьН и дожидается их интеграции, обнаруживаемой по наблюдению смешанной невербальной реакции.
(11) Затем оператор калибрует результат интеграции путем оживления одного из якорей и отслеживания появления смешанной реакции.
Надо бы попробовать как-то разделять (и в проектировании ИТ систем такой же вопрос имеет место):
- "штуки"
- действия/функции штук
- КАЧЕСТВА действий/функций штук
Например, "переживание" это штука, работа с переживаниями это функции/действия, а раппорт это вроде уже качество. Нет же раппорта самого по себе, есть некая "раппортность" манипуляций. Или не так?
- "штуки"
- действия/функции штук
- КАЧЕСТВА действий/функций штук
Например, "переживание" это штука, работа с переживаниями это функции/действия, а раппорт это вроде уже качество. Нет же раппорта самого по себе, есть некая "раппортность" манипуляций. Или не так?
Надо бы попробовать как-то разделять (и в проектировании ИТ систем такой же вопрос имеет место): - "штуки" -действия/функции штук - КАЧЕСТВА действий/функций штук. Например, "переживание" это штука, работа с переживаниями это функции/действия, а раппорт это вроде уже качество. ...
Абсолютно так!
Сей момент времени я торможу, потому что все еще не могу избавиться от шока в связи с переживаемым комплексным фактом:
--я крутой моделист, с огромной практикой различных техник типа якорения
--сам же предложивший идею использования UML для настоящей формализации моделей и техник ЧА
--и даже ранее пробующий тренироваться в вышеуказанном
--при проверке в лоб плаваю как двоишник-студент на экзамене, потому что не могу дать фиксированную картину описания даже одной диаграммы классов для якорения!
...т.е. мной переживается такой дабл байндерский шок. Потому что, с одной стороны, надо ДЕЙСТВИТЕЛЬНО на старости лет с нуля учиться мыслить объекто-ориентированными моделями. Потому, что измерений этой объектной ориентированности многочисленное множество. И еще потому, что исходная идея в нахождении языка полной формализации описаний активности ЧА получила совершенное подтверждение!
Нет же раппорта самого по себе, есть некая "раппортность" манипуляций. Или не так?
ЕСТЬ ТАКАЯ ШТУКА КАК РАППОРТ САМ ПО СЕБЕ!
ЕСТЬ ТАКАЯ ШТУКА КАК РАППОРТ САМ ПО СЕБЕ!
Потому, что измерений этой объектной ориентированности многочисленное множество. И еще потому, что исходная идея в нахождении языка полной формализации описаний активности ЧА получила совершенное подтверждение!
А что такое может быть эта "штука" (объект, класс и т.д.) ФЕНОМЕНОЛОГИЧЕСКИ? Это получается что-то вроде части/ментального процесса?
А что такое может быть эта "штука" (объект, класс и т.д.) ФЕНОМЕНОЛОГИЧЕСКИ? Это получается что-то вроде части/ментального процесса?
Ну, так это самый главный вопрос. Но, с самого начала ясно, что штука:
--это не переживание
--штука это какой-то универсальный квант метальных процессов
...не знаю. М.б. штука это какой-то кусок вербального_формы + связанного с ним невербального + вербального_содержания.
--это не переживание
--штука это какой-то универсальный квант метальных процессов
...не знаю. М.б. штука это какой-то кусок вербального_формы + связанного с ним невербального + вербального_содержания.
Типа прото-языкоид?
Ну, если я тебя правильно понял, то штука это такой эээ феноменальный языкоид. Значимая функциональная часть.
Надо паттерны проектирования смотреть. В них можно будет ухватить аналогию между ООП и ЧА.
Ну да.
ещё бы добавил
- диаграмму последовательностей -- для отображения шагов интеграции якорей
- диаграмму автомата состояний -- для отображения состояний субъекта
- диаграмму активностей -- для отображения деятельности оператора
- диаграмму коммуникаций -- для отображения деталей состояний
но мы ведь ещё не знаем, какие у нас будут классы :)