Previous Entry Share Next Entry
Программирование для моделирования ЧА (1) Разбираемся с UML
исполнитель (пианино)
eugzol wrote in metapractice
Из Оракула: http://metapractice.livejournal.com/368091.html?thread=9616091

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

В этом проходе попытаемся разобраться с UML.


  • 1

Re: мы смотрим на диаграммы и пытаемся сообразить - каки

Интеграция якорей. Мета вопросы.

Диаграмма = инструмент коммуникации/воздействия

Решил в этот же проход добавить диаграммы BPMN.

Для того, чтобы разобраться как рисовать диаграммы, того же шестишагового рефрейминга, надо решить, кому мы будем её показывать:
- всем, в том числе субъекту?
- только оператору в качестве подсказки/обучения?
- только моделисту?

Моделист - моделисту.

А сколько еще есть диаграмм?

Диаграммы мы рисуем, чтобы моделист1 мог их показывать моделисту2.

Вроде решили начать с постановки якорей.

Re: Моделист - моделисту.

А сколько еще есть диаграмм?

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

Диаграммы мы рисуем, чтобы моделист1 мог их показывать моделисту2.

Понятно.

Вроде решили начать с постановки якорей.

Ну, в любом случае для начала надо вытащить текстовое пошаговое описание.

Re: Моделист - моделисту.

Да, для начала - текстовое пошаговое.

Re: Моделист - моделисту.

А откуда взять его для якорения? Восстанавливать по транскрипту?

Re: Моделист - моделисту.

Да зачем транскрипт.

Можем и сами расписать в свободной манере ту или иную интрукцию - вариант интеграции якорей.

Например, как-то так:

(1) Субъект испытывает разные переживания.
(2) Оператор выделяет из них две группы: ресурсные и нересурсные.
(3) Оператор выделяет из нересурсных одно нересурсное переживание или нересурсную тему.
(4) Оператор заставляет субъекта пережить выбранное нересурсное переживание или тему.
(5) Оператор ставит на нересурсное переживание/тему якорьН.
(6) Оператор заставляет субъекта переживать нейтральное состояние.
(7) Оператор заставляет субъекта переживать ресурсные переживания.
(8) Оператор ставит на ресурсные переживания якорьР.
(9) Оператор калибрует полученные якоряН и Р путем их чередования с нейтральным переживанием.
(10) Затем, на фоне нейтрального переживания, оператор активизирует одновременно якорьР + якорьН и дожидается их интеграции, обнаруживаемой по наблюдению смешанной невербальной реакции.
(11) Затем оператор калибрует результат интеграции путем оживления одного из якорей и отслеживания появления смешанной реакции.

Edited at 2013-04-15 04:26 pm (UTC)

Use-Case диаграмма



Edited at 2013-04-15 05:18 pm (UTC)

УТОЧНЕНИЕ ОПИСАНИЯ АЛГОРИТМА ИНТЕГРАЦИИ ЯКОРЕЙ


(1) Субъект:
--генерирует состояния.
--генерирует сигналы
--заполняет интерфейс экспрессии
(2) Оператор:
--сортирует состояния субъекта на ресурсные нересурсные
--заполняет интерфейс оператора
--реализует раппорт
--реализует БОС

(3) Оператор выделяет из нересурсных одно нересурсное переживание/ нересурсную тему.
(4) Оператор заставляет субъекта пережить выбранное нересурсное переживание или тему.
(5) Оператор ставит на нересурсное переживание/тему якорьН.
(6) Оператор заставляет субъекта переживать нейтральное состояние.
(7) Оператор заставляет субъекта переживать ресурсные переживания.
(8) Оператор ставит на ресурсные переживания якорьР.
(9) Оператор калибрует полученные якоряН и Р путем их чередования с нейтральным переживанием.
(10) Затем, на фоне нейтрального переживания, оператор активизирует одновременно якорьР + якорьН и дожидается их интеграции, обнаруживаемой по наблюдению смешанной невербальной реакции.
(11) Затем оператор калибрует результат интеграции путем оживления одного из якорей и отслеживания появления смешанной реакции.

Re: УТОЧНЕНИЕ ОПИСАНИЯ АЛГОРИТМА ИНТЕГРАЦИИ ЯКОРЕЙ

Надо бы попробовать как-то разделять (и в проектировании ИТ систем такой же вопрос имеет место):
- "штуки"
- действия/функции штук
- КАЧЕСТВА действий/функций штук

Например, "переживание" это штука, работа с переживаниями это функции/действия, а раппорт это вроде уже качество. Нет же раппорта самого по себе, есть некая "раппортность" манипуляций. Или не так?

СОВЕРШЕННОЕ ПОДТВЕРЖДЕНИЕ


Надо бы попробовать как-то разделять (и в проектировании ИТ систем такой же вопрос имеет место): - "штуки" -действия/функции штук - КАЧЕСТВА действий/функций штук. Например, "переживание" это штука, работа с переживаниями это функции/действия, а раппорт это вроде уже качество. ...

Абсолютно так!

Сей момент времени я торможу, потому что все еще не могу избавиться от шока в связи с переживаемым комплексным фактом:

--я крутой моделист, с огромной практикой различных техник типа якорения
--сам же предложивший идею использования UML для настоящей формализации моделей и техник ЧА
--и даже ранее пробующий тренироваться в вышеуказанном
--при проверке в лоб плаваю как двоишник-студент на экзамене, потому что не могу дать фиксированную картину описания даже одной диаграммы классов для якорения!

...т.е. мной переживается такой дабл байндерский шок. Потому что, с одной стороны, надо ДЕЙСТВИТЕЛЬНО на старости лет с нуля учиться мыслить объекто-ориентированными моделями. Потому, что измерений этой объектной ориентированности многочисленное множество. И еще потому, что исходная идея в нахождении языка полной формализации описаний активности ЧА получила совершенное подтверждение!

ЕСТЬ ТАКАЯ ШТУКА КАК РАППОРТ САМ ПО СЕБЕ

Нет же раппорта самого по себе, есть некая "раппортность" манипуляций. Или не так?

ЕСТЬ ТАКАЯ ШТУКА КАК РАППОРТ САМ ПО СЕБЕ!

Re: Use-Case диаграмма

ещё бы добавил
  • диаграмму последовательностей -- для отображения шагов интеграции якорей
  • диаграмму автомата состояний -- для отображения состояний субъекта
  • диаграмму активностей -- для отображения деятельности оператора
  • диаграмму коммуникаций -- для отображения деталей состояний


Re: Use-Case диаграмма

но мы ведь ещё не знаем, какие у нас будут классы :)

  • 1
?

Log in

No account? Create an account