Показаны записи 20411 - 20420 из 56300
</>
![[pic]](http://i102.photobucket.com/albums/m112/EugZol/Quotation_BPMN_Example_zpsafd26949.png)
Программирование для моделирования ЧА (2) UML-моделирование
metanymous в Metapractice (оригинал в ЖЖ)
http://metapractice.livejournal.com/371985.html
В этой теме будем пытаться переложить технологии, методологии, различные теории и практики программирования для моделирования человеческих активностей. В этом проходе попытаемся разобраться с UML.
(Картинки и цитаты из книги Фаулера)
Слева направо, сверху вниз:
Диаграмма: Структурная диаграмма и Диаграмма поведения
Структурная диаграмма: Диаграмма классов, Компонентная диаграмма, Композитная диаграмма структуры, Диаграмма развёртывания, Диаграмма объектов, Диаграмма пакетов
Диаграмма поведения: Диаграмма активности, Диаграмма варианта использования, Диаграмма автомата состояний, Диаграмма взаимодействия
Диаграмма взимодействия: Диаграмма последовательности, Диаграмма коммуникации, Обзорная диаграмма взаимодействия, Временнáя диаграмма
A class diagram describes the types of objects in the system and the various kinds of static
relationships that exist among them. Class diagrams also show the properties and operations of a
class and the constraints that apply to the way objects are connected. The UML uses the term
feature as a general term that covers properties and operations of a class.
Диаграмма классов описывает типы объектов в системе и различные виды статических отношений, которые между ними существуют. Диаграмма классов также показывает свойства и операции классов и ограничения, которые применимы к связям между объектами. UML использует термин характеристика (feature) как общий термин, покрывающий свойства и операции класса.
Interaction diagrams describe how groups of objects collaborate in some behavior. The UML
defines several forms of interaction diagram, of which the most common is the sequence diagram.
Typically, a sequence diagram captures the behavior of a single scenario. The diagram shows a
number of example objects and the messages that are passed between these objects within the use
case.
Диаграммы взаимодействия описывают, как группы объектов сотрудничают по ходу некоего поведения. UML определяет несколько разных форм диаграмм взаимодействия, наиболее общепринятая из которых диаграмма последовательности. Типично, диаграмма последовательности ухватывает поведение по ходу одного сценария. Диаграмма показывает несколько образцов объектов и сообщения, которые передаются между этими объектами в рамках варианта использования.
An object diagram is a snapshot of the objects in a system at a point in time. Because it shows
instances rather than classes, an object diagram is often called an instance diagram.
Диаграмма объектов является снимком объектов в системе в заданный момент времени. Поскольку она показывает экземпляры, а не классы, диаграмму объектов часто называют диаграммой экземпляров.
A package is a grouping construct that allows you to take any construct in the UML and group its
elements together into higher-level units. Its most common use is to group classes, and that's the
way I'm describing it here, but remember that you can use packages for every other bit of the UML
as well.
Пакет это группирующая конструкция, которая позволяет вам взять любую конструкцию UML и сгруппировать её элементы вместе в элементы более высокого уровня. Его наиболее частое использование — для группировки классов, и именно в таком ключе я описываю его здесь, но помните что вы также можете использовать пакеты для любого другого кусочка UML.
A package diagram shows packages and their dependencies. [...] If you have packages for presentation and domain, you have a dependency
from the presentation package to the domain package if any class in the presentation package has a
dependency to any class in the domain package. In this way, interpackage dependencies summarize
the dependencies between their contents.
Диаграмма пакетов показывает пакеты и их зависимости. [...] Если у вас есть пакеты для представления и для предметной области, у вас есть зависимость от пакета представления к пакету предметной области, если какой бы то ни было класс в пакете представления имеет зависимость к какому бы то ни было классу в пакете предметной области. В таком ключе, взаимозависимость пакетов резюмирует зависимости между их содержимым.
Deployment diagrams show a system's physical layout, revealing which pieces of software run on
what pieces of hardware.
Диаграммы развертывания показывают физическую компоновку системы, раскрывая какие части программного обеспечения исполняются на каких частях аппаратного.
As I said earlier, the UML is silent on the content of a use case but does provide a diagram format
for showing them [...]. Although the diagram is sometimes useful, it isn't mandatory. In
your use case work, don't put too much effort into the diagram. Instead, concentrate on the textual
content of the use cases.
Как я сказал раньше, UML молчит касательно содержания варианта использования, но всё же предлагает формат диаграмм для их представления [...]. Хотя такая диаграмма иногда полезна, она не обязательна. В своей работе над вариантом использования, не вкладывайте слишком много труда в диаграмму. Вместо этого, сконцентрируйтесь на текстовом содержании варианта использования.
State machine diagrams are a familiar technique to describe the behavior of a system. Various
forms of state diagrams have been around since the 1960s and the earliest object-oriented
techniques adopted them to show behavior. In object-oriented approaches, you draw a state
machine diagram for a single class to show the lifetime behavior of a single object.
Диаграммы автомата состояний являются привычной техникой описания поведения системы. Различные формы диаграмм состояний имели место примерно с 1960-х и первые объектно-ориентированные техники заимствовали их для иллюстрации поведения. В объектно-ориентированном подходе, вы рисуете диаграмму автомата состояний для отдельного класса, чтобы показать жизненный цикл поведения отдельного объекта.
Activity diagrams are a technique to describe procedural logic, business process, and work flow. In
many ways, they play a role similar to flowcharts, but the principal difference between them and
flowchart notation is that they support parallel behavior.
Диаграммы активности являются техникой для описания процедурной логики, бизнес-процессов, производственных процессов. Во многих аспектах они играют роль, близкую к блок-схемам, но принципиальная разница между ними и блок-схемами заключается в поддержке параллельного поведения.
Communication diagrams, a kind of interaction diagram, emphasize the data links between the
various participants in the interaction. Instead of drawing each participant as a lifeline and showing
the sequence of messages by vertical direction as the sequence diagrams does, the communication
diagram allows free placement of participants, allows you to draw links to show how the participants
connect, and use numbering to show the sequence of messages.
Диаграммы коммуникации, разновидность диаграм взаимодействия, подчёркивают во взаимодействии каналы передачи данных между разными участниками. Вместо того, чтобы изображать каждого участника как линию жизненного цикла и показывать последовательность сообщений упорядочиванием вдоль вертикали, как делает диаграмма последовательности, диаграмма коммуникации дозволяет свободное расположение участников, позволяя вам изображать связи для того, чтобы показать как участники соединяются, и использовать нумерацию, чтобы показать последовательность сообщений.
One of the most significant new features in UML 2 is the ability to hierarchically decompose a class
into an internal structure. This allows you to take a complex object and break it down into parts.
Одна из наиболее значительных новых возможностей в UML 2 — возможность иерархически раскладывать класс на составляющую его внутреннюю структуру. Это позволяет вам взять сложный объект и разбить его на части.
Other than the icon, components don't introduce any notation that we haven't already seen.
Components are connected through implemented and required interfaces, often using the ball-and-
socket notation (page 71) just as for class diagrams. You can also decompose components by using
composite structure diagrams.
Компоненты не вводят никаких новых обозначений к тем, что мы уже видели, кроме как иконку. Компоненты соединяются через реализованные и требуемые интерфейсы, часто используя знак "шарнира" (стр. 71), в точности как диаграммы классов. Вы также можете разложить компоненты на составные части, используя копозитную диаграмму структуры.
Collaborations have been around since UML 1, but I admit I've hardly used them, even in my
patterns writing. Collaborations do provide a way to group chunks of interaction behavior when roles
are played by different classes. In practice, however, I've not found that they've been a compelling
diagram type.
Диаграммы сотрудничества существовали со времён UML 1, но, признаться, я их редко использовал, даже в моих описаниях паттернов. Диаграммы сотрудничества действительно дают способ сгруппировать фрагменты поведения по взаимодействию, когда роли разыгрываются разными классами. На практике, однако, я не обнаружил чтобы они были притягательным типом диаграмм.
Interaction overview diagrams are a grafting together of activity diagrams and sequence diagrams.
You can think of interaction overview diagrams either as activity diagrams in which the activities are
replaced by little sequence diagrams, or as a sequence diagram broken up with activity diagram
notation used to show control flow. Either way, they make a bit of an odd mixture.
Обзорные диаграммы взаимодействия являются прививкой диаграмм активности к диаграммам последовательности. Вы можете думать об обзорной диаграмме взаимодействия либо как о диаграмме активности, в которой активности заменены маленькими диаграммами последовательности, либо как о диаграмме последовательности, разбитой разметкой диаграммы активности, используемой чтобы показать поток управления. В любом случае, они представляют собой немного странную смесь.
Timing diagrams are another form of interaction diagram, where the focus is on timing constraints:
either for a single object or, more usefully, for a bunch of objects. Let's take a simple scenario based
on the pump and hotplate for a coffee pot. Let's imagine a rule that says that at least 10 seconds
must pass between the pump coming on and the hotplate coming on. When the water reservoir
becomes empty, the pump switches off, and the hotplate cannot stay on for more than 15 minutes
more.
Временны́е диаграммы являются иной формой диаграмм взаимодействия, фокусирующейся на временных ограничениях: либо для отдельного объекта, либо, что более полезно, для кучи объектов. Возьмём простой сценарий, включающий насос и нагревательный элемент кофемашины. Положим, правило говорит, что по меньшей мере 10 секунд должны пройти между включением насоса и включением нагревательного элемента. Когда водный резервуар опустошается, насос выключается, и нагревательный элемент не может оставаться включенным более чем ещё на 15 минут.
Основная цель BPMN — создание стандартного набора условных обозначений, понятных всем бизнес-пользователям. Бизнес-пользователи включают в себя бизнес-аналитиков, создающих и улучшающих процессы, технических разработчиков, ответственных за реализацию процессов и менеджеров, следящих за процессами и управляющих ими. Следовательно, BPMN призвана служить связующим звеном между фазой дизайна бизнес-процесса и фазой его реализации.
В этой теме будем пытаться переложить технологии, методологии, различные теории и практики программирования для моделирования человеческих активностей. В этом проходе попытаемся разобраться с UML.
Типы диаграмм
(Картинки и цитаты из книги Фаулера)
Слева направо, сверху вниз:
Диаграмма: Структурная диаграмма и Диаграмма поведения
Структурная диаграмма: Диаграмма классов, Компонентная диаграмма, Композитная диаграмма структуры, Диаграмма развёртывания, Диаграмма объектов, Диаграмма пакетов
Диаграмма поведения: Диаграмма активности, Диаграмма варианта использования, Диаграмма автомата состояний, Диаграмма взаимодействия
Диаграмма взимодействия: Диаграмма последовательности, Диаграмма коммуникации, Обзорная диаграмма взаимодействия, Временнáя диаграмма
Диаграмма классов
A class diagram describes the types of objects in the system and the various kinds of static
relationships that exist among them. Class diagrams also show the properties and operations of a
class and the constraints that apply to the way objects are connected. The UML uses the term
feature as a general term that covers properties and operations of a class.
Диаграмма классов описывает типы объектов в системе и различные виды статических отношений, которые между ними существуют. Диаграмма классов также показывает свойства и операции классов и ограничения, которые применимы к связям между объектами. UML использует термин характеристика (feature) как общий термин, покрывающий свойства и операции класса.
Диаграмма последовательности
Interaction diagrams describe how groups of objects collaborate in some behavior. The UML
defines several forms of interaction diagram, of which the most common is the sequence diagram.
Typically, a sequence diagram captures the behavior of a single scenario. The diagram shows a
number of example objects and the messages that are passed between these objects within the use
case.
Диаграммы взаимодействия описывают, как группы объектов сотрудничают по ходу некоего поведения. UML определяет несколько разных форм диаграмм взаимодействия, наиболее общепринятая из которых диаграмма последовательности. Типично, диаграмма последовательности ухватывает поведение по ходу одного сценария. Диаграмма показывает несколько образцов объектов и сообщения, которые передаются между этими объектами в рамках варианта использования.
Диаграмма объектов
An object diagram is a snapshot of the objects in a system at a point in time. Because it shows
instances rather than classes, an object diagram is often called an instance diagram.
Диаграмма объектов является снимком объектов в системе в заданный момент времени. Поскольку она показывает экземпляры, а не классы, диаграмму объектов часто называют диаграммой экземпляров.
Диаграмма пакетов
A package is a grouping construct that allows you to take any construct in the UML and group its
elements together into higher-level units. Its most common use is to group classes, and that's the
way I'm describing it here, but remember that you can use packages for every other bit of the UML
as well.
Пакет это группирующая конструкция, которая позволяет вам взять любую конструкцию UML и сгруппировать её элементы вместе в элементы более высокого уровня. Его наиболее частое использование — для группировки классов, и именно в таком ключе я описываю его здесь, но помните что вы также можете использовать пакеты для любого другого кусочка UML.
A package diagram shows packages and their dependencies. [...] If you have packages for presentation and domain, you have a dependency
from the presentation package to the domain package if any class in the presentation package has a
dependency to any class in the domain package. In this way, interpackage dependencies summarize
the dependencies between their contents.
Диаграмма пакетов показывает пакеты и их зависимости. [...] Если у вас есть пакеты для представления и для предметной области, у вас есть зависимость от пакета представления к пакету предметной области, если какой бы то ни было класс в пакете представления имеет зависимость к какому бы то ни было классу в пакете предметной области. В таком ключе, взаимозависимость пакетов резюмирует зависимости между их содержимым.
Диаграмма развёртывания
Deployment diagrams show a system's physical layout, revealing which pieces of software run on
what pieces of hardware.
Диаграммы развертывания показывают физическую компоновку системы, раскрывая какие части программного обеспечения исполняются на каких частях аппаратного.
Диаграмма варианта использования
As I said earlier, the UML is silent on the content of a use case but does provide a diagram format
for showing them [...]. Although the diagram is sometimes useful, it isn't mandatory. In
your use case work, don't put too much effort into the diagram. Instead, concentrate on the textual
content of the use cases.
Как я сказал раньше, UML молчит касательно содержания варианта использования, но всё же предлагает формат диаграмм для их представления [...]. Хотя такая диаграмма иногда полезна, она не обязательна. В своей работе над вариантом использования, не вкладывайте слишком много труда в диаграмму. Вместо этого, сконцентрируйтесь на текстовом содержании варианта использования.
Диаграмма автомата состояний
State machine diagrams are a familiar technique to describe the behavior of a system. Various
forms of state diagrams have been around since the 1960s and the earliest object-oriented
techniques adopted them to show behavior. In object-oriented approaches, you draw a state
machine diagram for a single class to show the lifetime behavior of a single object.
Диаграммы автомата состояний являются привычной техникой описания поведения системы. Различные формы диаграмм состояний имели место примерно с 1960-х и первые объектно-ориентированные техники заимствовали их для иллюстрации поведения. В объектно-ориентированном подходе, вы рисуете диаграмму автомата состояний для отдельного класса, чтобы показать жизненный цикл поведения отдельного объекта.
Диаграмма активности
Activity diagrams are a technique to describe procedural logic, business process, and work flow. In
many ways, they play a role similar to flowcharts, but the principal difference between them and
flowchart notation is that they support parallel behavior.
Диаграммы активности являются техникой для описания процедурной логики, бизнес-процессов, производственных процессов. Во многих аспектах они играют роль, близкую к блок-схемам, но принципиальная разница между ними и блок-схемами заключается в поддержке параллельного поведения.
Диаграмма коммуникации
Communication diagrams, a kind of interaction diagram, emphasize the data links between the
various participants in the interaction. Instead of drawing each participant as a lifeline and showing
the sequence of messages by vertical direction as the sequence diagrams does, the communication
diagram allows free placement of participants, allows you to draw links to show how the participants
connect, and use numbering to show the sequence of messages.
Диаграммы коммуникации, разновидность диаграм взаимодействия, подчёркивают во взаимодействии каналы передачи данных между разными участниками. Вместо того, чтобы изображать каждого участника как линию жизненного цикла и показывать последовательность сообщений упорядочиванием вдоль вертикали, как делает диаграмма последовательности, диаграмма коммуникации дозволяет свободное расположение участников, позволяя вам изображать связи для того, чтобы показать как участники соединяются, и использовать нумерацию, чтобы показать последовательность сообщений.
Композитная диаграмма структуры
One of the most significant new features in UML 2 is the ability to hierarchically decompose a class
into an internal structure. This allows you to take a complex object and break it down into parts.
Одна из наиболее значительных новых возможностей в UML 2 — возможность иерархически раскладывать класс на составляющую его внутреннюю структуру. Это позволяет вам взять сложный объект и разбить его на части.
Диаграмма компонентов
Other than the icon, components don't introduce any notation that we haven't already seen.
Components are connected through implemented and required interfaces, often using the ball-and-
socket notation (page 71) just as for class diagrams. You can also decompose components by using
composite structure diagrams.
Компоненты не вводят никаких новых обозначений к тем, что мы уже видели, кроме как иконку. Компоненты соединяются через реализованные и требуемые интерфейсы, часто используя знак "шарнира" (стр. 71), в точности как диаграммы классов. Вы также можете разложить компоненты на составные части, используя копозитную диаграмму структуры.
Диаграмма сотрудничества
Collaborations have been around since UML 1, but I admit I've hardly used them, even in my
patterns writing. Collaborations do provide a way to group chunks of interaction behavior when roles
are played by different classes. In practice, however, I've not found that they've been a compelling
diagram type.
Диаграммы сотрудничества существовали со времён UML 1, но, признаться, я их редко использовал, даже в моих описаниях паттернов. Диаграммы сотрудничества действительно дают способ сгруппировать фрагменты поведения по взаимодействию, когда роли разыгрываются разными классами. На практике, однако, я не обнаружил чтобы они были притягательным типом диаграмм.
Обзорная диаграмма взаимодействия
Interaction overview diagrams are a grafting together of activity diagrams and sequence diagrams.
You can think of interaction overview diagrams either as activity diagrams in which the activities are
replaced by little sequence diagrams, or as a sequence diagram broken up with activity diagram
notation used to show control flow. Either way, they make a bit of an odd mixture.
Обзорные диаграммы взаимодействия являются прививкой диаграмм активности к диаграммам последовательности. Вы можете думать об обзорной диаграмме взаимодействия либо как о диаграмме активности, в которой активности заменены маленькими диаграммами последовательности, либо как о диаграмме последовательности, разбитой разметкой диаграммы активности, используемой чтобы показать поток управления. В любом случае, они представляют собой немного странную смесь.
Временная диаграмма
Timing diagrams are another form of interaction diagram, where the focus is on timing constraints:
either for a single object or, more usefully, for a bunch of objects. Let's take a simple scenario based
on the pump and hotplate for a coffee pot. Let's imagine a rule that says that at least 10 seconds
must pass between the pump coming on and the hotplate coming on. When the water reservoir
becomes empty, the pump switches off, and the hotplate cannot stay on for more than 15 minutes
more.
Временны́е диаграммы являются иной формой диаграмм взаимодействия, фокусирующейся на временных ограничениях: либо для отдельного объекта, либо, что более полезно, для кучи объектов. Возьмём простой сценарий, включающий насос и нагревательный элемент кофемашины. Положим, правило говорит, что по меньшей мере 10 секунд должны пройти между включением насоса и включением нагревательного элемента. Когда водный резервуар опустошается, насос выключается, и нагревательный элемент не может оставаться включенным более чем ещё на 15 минут.
BPMN
Основная цель BPMN — создание стандартного набора условных обозначений, понятных всем бизнес-пользователям. Бизнес-пользователи включают в себя бизнес-аналитиков, создающих и улучшающих процессы, технических разработчиков, ответственных за реализацию процессов и менеджеров, следящих за процессами и управляющих ими. Следовательно, BPMN призвана служить связующим звеном между фазой дизайна бизнес-процесса и фазой его реализации.
1993 Bandler R. Time for a Change. «Appendix 4»
SUB-MODALITIES СУБ-МОДАЛЬНОСТИ
VISUAL ЗРИТЕЛЬНЫЕ
AUDITORY СЛУХОВЫЕ
KINESTHETIC КИНЕСТЕТИЧЕСКИЕ
BRIGTHNESS ЯРКОСТЬ
VOLUME ГРОМКОСТЬ
INTENSY ИНТЕНСИВНОСТЬ
(dim-bright)
(тускло-ярко )
(loud-soft)
(громко-тихо)
(strong-weak)
(сильная-слабая)
SIZE РАЗМЕР
TONE ТОН
AREA ЗОНА
(large-small)(больше-меньше)
(bass-tremble)(низкий-дрожащий??)
(large-small)(большая-маленькая)
COLOR ЦВЕТ
PITCH ВЫСОТА
TEXTURE ТЕКСТУРА
(black & white-color)(черно-белый-цветной)
(high-low)(высокий-низкий)
(rough-smooth)(шероховатая-гладкая)
MOVEMENT ДВИЖЕНИЕ
TEMPO ТЕМП
DURATION ПРОДОЛЖИТЕЛЬНОСТЬ
(fast-slow-still)(быстро-медленно-неподвижно)
(fast-slow)(быстро-медленно)
(constant-intermitten)(постоянный-прерывистый)
DISTANCE ДИСТАНЦИЯ
DISTANCE ДИСТАНЦИЯ
TEMPERATURE ТЕМПЕРАТУРА
(near-far) (рядом-далеко)
(close-far) (близко-далеко)
(hot-cold) (горячо-холодно)
FOCUS ФОКУС
RYTHM РИТМ
WEIGHT ВЕС
(clear-fuzzy) (четко-размыто)
(height-light) (тяжелый-легкий)
LOCATION МЕСТОПОЛОЖЕНИЕ
LOCATION МЕСТОПОЛОЖЕНИЕ
LOCATION МЕСТОПОЛОЖЕНИЕ
DEPTH ГЛУБИНА
(3D-flat) (3d-плоское)
META-MODALITIES
МЕТА-МОДАЛЬНОСТИ
ASSOCIATED-DISSOCIATED АССОЦИИРОВАННО-ДИССОЦИИРОВАННО
WORDS-TONES СЛОВА-ТОНЫ
EMOTIONAL-TACTILE ЭМОЦИОНАЛЬНЫЙ-ТАКТИЛЬНЫЙ
INTERNAL-EXTERNAL (ВНУТРЕННИЙ-ВНЕШНИЙ)
INTERNAL-EXTERNAL (ВНУТРЕННИЙ-ВНЕШНИЙ)
INTERNAL-EXTERNAL (ВНУТРЕННИЙ-ВНЕШНИЙ)
Кстати, опечатки в словах «RYTHM» и «INTENSY».
http://fromfrogs.livejournal.com/1665.html?thread=37505#t37505
Ну вот, закончил.
Из Лягушек:
«Дик, и что же вы будете делать, если через шесть-семь недель снова обнаружите, что проделываете стереотип Х? Что же вы предполагаете тогда сделать? Вы можете принять это как сигнал того, что новые способы поведения, к которым вы здесь пришли, были неадекватными тому намерению. Но вы сможете вернуться к своей творческой части и дать ей инструкции изобрести еще три новых способа. Стереотип поведения является барометром, указывающем на то, насколько адекватными являются новые варианты. Если старое поведение появляется после некоторого тестового периода времени, то это говорит о том, что новые способы не более эффективны, нежели старые. Это сигнал к тому, чтобы вы вернулись к этому процессу и создали новые варианты. Регрессия к старому поведению -- это не сигнал неудачи, а сигнал некомпетентности, и вы можете вернуться назад и зафиксировать это. Переформирование сработает. Я гарантирую вам, что его поведение измениться. Если оно через некоторое время станет прежним, то это означает, что новые способы поведения менее эффективны, нежели Х в плане получения чего-либо. Тогда он снова проходит через весь процесс, находит вторичную выгоду и создает новые способы достижения этой выгоды. Если вы не сделаете симптом, сказав об этом открыто, сигналом к повторению процесса, то сознание пациента всегда назовет новое появление симптома "неудача". Когда симптом идентифицируется как сигнал, то клиент уделяет ему внимание как СООБЩЕНИЮ. Вероятно, он всегда был сообщением, но он никогда не рассматривал его с этой точки зрения. Поступая таким образом, он приобретает механизм обратной связи. Они открывают для себя, что всего лишь в определенное время они получают определенный сигнал. »
Рефрейминг:
«Но есть важная причина для того, чтобы сначала производить присоединение к будущему. Присоединение к будущему помещает новое поведение в определенный контекст, проверяя его в воображении. И остальные части могут понять, что у них есть возражения только тогда, когда вы уже присоединили новые реакции к будущему, и поместили их в определенный контекст. Если вы будете делать присоединение к будущему в последнюю очередь, то возражения будут возникать заново, и вы об этом не узнаете, если не будете внимательны в Этот момент к признакам неконгруэнтности. »
Из Лягушек:
«Когда мы закончили формирование коммуникации и получили новые варианты поведения для той части, которая управляет проблемным поведением, вы спрашиваете все остальные части личности, как это отозвалось на них? " Есть ли какая-либо часть меня, которая имеет возражение против новых способов поведения? " Если какая-то часть возражает, то обычно она использует другой сигнал. Сигнал этот может быть в той же самой системе, но в другой части тела. Если вдруг возникает напряжение в плечах, то вы говорите: "Хорошо, мое сознание ограничено. Не могли бы увеличить напряжение, если возражения есть и уменьшить, если их нет? " -- если возражения есть, то это прекрасный результат. Это означает, что есть другая часть, другой ресурс, который может быть использован для того, чтобы совершить это изменение. Вы снова на шаге 2, откуда повторяете весь процесс. »
Из Лягушек:
«Мужчина: А что, если на пятом шаге часть отказывается взять на себя ответственность? Ну, тогда это означает, что где-то раньше было сделано что-то не так. Если часть говорит: "Нет, я не возьму на себя ответственность за это", то это, не забывайте, та же самая часть, которая три новых способа признала более эффективными, нежели Х, что не имеет смысла. Это указывает на то, что каналы коммуникации где-то исказились и их надо почистить. »
Из Лягушек:
«. Пятый шаг состоит в том, чтобы убедиться, что новые реакции действительно возникли в его поведении. Дик, используя ту же самую систему сигналов, спросите часть Х: "Поскольку у вас есть три варианта поведения, более эффективных чем стереотип Х, берете ли вы на себя ответственность за то, что эти варианты реально проявятся в моем поведении в соответствующей ситуации? " И вы помните, что ответ "да" это интенсификация, "нет" -- уменьшение. Верно? Дик: Я не уверен в том, что это верно. ОК: Тогда попросите часть Х дать вам сейчас сигнал "да" перед тем как вы начнете, чтобы вы знали, что есть "да", а что есть "нет". Дик: Да... но... я потерял след. Да, я знаю. Вот почему я и прошу вас сделать это. Просто обратитесь внутрь себя и попросите дать сигнал "да", чтобы вы знали, что это такое. Дик: Сигнал "да" -- это релаксация. Так, хорошо. Вернемся немного назад. Вернемся внутрь и спросим часть Х, есть ли у нее три новых выбора, три новых варианта поведение, которые будут работать более эффективно, чем Х. Дик: Здесь было "да". »
Рефрейминг:
«5. Спросите часть X: "Не хочешь ли ты взять на себя ответственность за то, чтобы использовать 3 новых варианта поведения в соответствующем контексте?" Это обеспечит присоединение к будущему. Коме того, вы можете просить часть Х на подсознательном уровне идентифицировать сенсорные сигналы, которые будут запускать функционирование новых вариантов поведения и полностью переживать то состояние, в котором клиент бы находился, когда бы эти сенсорные сигналы автоматически запускали бы новые реакции, которые протекали бы легко и автоматически. »
«Джил: Я обнаружила, что многие клиенты негативно реализуют на слово "ответственность" на шаге 5, но если я говорю: "Спросите часть X, не хочет ли она сделать выбор из всех новых вариантов, созданных творческой частью?" Тогда все идет гладко.
Прекрасно. Держите в уме результат, к которому вы стремитесь и используйте любые слова, которые ведут к достижению этого результата.»
Из Лягушек:
«Другим вариантом является программирование сновидений. "Обратитесь внутрь себя и спросите ту часть вас, которая пыталась создать творческие решения вашей проблемы, возьмет ли она себя ответственность во время периода сновидений сегодня ночью создать новые варианты поведения и проявить их сегодня в сновидениях". Получите ответ "да", а затем спросите, "Возьмет ли часть Х ответственность за выбор из всех новых вариантов трех наилучших и за применение их в соответствующей ситуации?" И клиент уходит от вас с запрограммированными сновидениями, видит эти сновидения, и проявляет это новое поведение. Когда через две недели он снова к вам, то можете сказать о тех изменениях, которые произошли. »
Дочитали до конца.