Разбираемся с UML

Мы можем на UML расписать:

---

--технику?

---

--метамоделирование?

---

--упражнение?

---

--м.б. даже модель?

---

...в конце концов, я утверждал, что модель есть несколько описаний. Примерно шесть.

Это один вариант. Другой вариант - попробовать чисто по формальному описанию диаграмм прикинуть, какие генерализации даёт:

---

- использование их по-отдельности

---

- использование их в комплексе

Ну, тогда лучше для начала разобрать/сопоставить какие диаграммы 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 призвана служить связующим звеном между фазой дизайна бизнес-процесса и фазой его реализации.

---

http://ru.wikipedia.org/wiki/BPMN

Терминология BPMN:

---

(1) Надпись сверху "Покупатель" и слева "Продавец" озаглавливает так называемый «pool» (пул). Пул покупателя как он тут есть называется свёрнутым — ну то есть просто не изображён на данной диаграмме кроме как заголовками и входящими/исходящими стрелочками путей сообщений (пунктирные). Потому что это избыточная информации, либо просто недоступная/неизвестная.

---

(2) Надписи "менеджер..." и "сотрудник..." и соответствующие разделительные линии обозначают «lanes» (линии, трассы). Обычно принято под отдельную линию выделять отдельную роль (человека/сотрудника), так здесь и сделано.

---

(3) Пунктирные линии, как уже было сказано, обозначают потоки сообщений. Значок белого конвертика в кружочке означает "ожидать, пока придёт сообщение". Значок чёрного конвертика в кружочке означает "отправить сообщение". Потоки сообщений связывают на диаграмме место отправки сообщения с соответствующим ему местом приёма сообщений.

---

(4) Текст в прямоугольниках — основной элемент — задачи. Задачи выполняются в рамках одной и только одной линии. Если задача на деле совместная/коллективная, принято её обозначать на линии ответственного за её исход сотрудника.

---

(5) Сплошные стрелки — пути потоков работ. Обозначают непосредственный безусловный переход к следующей задаче по завершению предыдущей. Сплошная стрелка может быть (по правилам нотации BPMN) только в рамках одного пула!

---

Говорят, что отдельным пулом управляет «ДИРИЖЁР».

---

Это некая абстрактная сущность. Существование дирижёра обосновывает запрет на соединение сплошной стрелкой задач в разных пулах. В данном примере "продавец" (заглавие одного из пулов, а значит фактически имя "дирижёра") не может непосредственно управлять "покупателем" (поэтому покупатель вынесен в отдельный пул, а не отдельную линию). А может лишь посылать и реагировать на сообщения.

---

С другой стороны, задачи с разных линий (задачи разных людей) вроде "Сформировать предложение" и "Рассмотреть предложение" соединены сплошной стрелкой, а не циклами/логикой обмена сообщений.

---

Это показывает, что переход от одной задачи к другой координируется скорее не каким-то отдельным сотрудником, А ТЕМ САМЫМ ДИРИЖЁРОМ.

---

На деле роль дирижёра может выполнять специальный софт, в который загружается подобная диаграмма - софт будет отслеживать выполнение задачи одним сотрудником и скидывать соответствующую следующую задачу в ящик задач другого сотрудника, и т.д.

---

Но даже если такой софт не используется, сам процесс разработки и демонстрации BPMN-диаграммы как раз и имеет своим главным действием выработку В ГОЛОВЕ сотрудников этой РОЛИ ДИРИЖЁРА! И сами процессы уже из-за этого будут меняться, упрощаясь (избавляясь по меньшей мере от лишних циклов взаимных перепроверок и исправления чужих ошибок).

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

---

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

---

- всем, в том числе субъекту?

---

- только оператору в качестве подсказки/обучения?

---

- только моделисту?

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

---

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

---

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

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

---

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

---

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

---

Понятно.

---

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

---

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

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

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

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

---

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

(1) Субъект испытывает разные переживания.

---

(2) Оператор выделяет из них две группы: ресурсные и нересурсные.

---

(3) Оператор выделяет из нересурсных одно нересурсное переживание или нересурсную тему.

---

(4) Оператор заставляет субъекта пережить выбранное нересурсное переживание или тему.

---

(5) Оператор ставит на нересурсное переживание/тему якорьН.

---

(6) Оператор заставляет субъекта переживать нейтральное состояние.

---

(7) Оператор заставляет субъекта переживать ресурсные переживания.

---

(8) Оператор ставит на ресурсные переживания якорьР.

---

(9) Оператор калибрует полученные якоряН и Р путем их чередования с нейтральным переживанием.

---

(10) Затем, на фоне нейтрального переживания, оператор активизирует одновременно якорьР + якорьН и дожидается их интеграции, обнаруживаемой по наблюдению смешанной невербальной реакции.

---

(11) Затем оператор калибрует результат интеграции путем оживления одного из якорей и отслеживания появления смешанной реакции.

---

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) как общий термин, покрывающий свойства и операции класса.

---

Как я понимаю, в диаграмме классов мы должны описать:

---

-- онтологию наличествующих у нас в конкретном кейсе «штуковин»

---

--расписать через «характеристики» (а) что эти штуковины ПОСТОЯННО ДЕЛАЮТ (б) как эти штуковины ПОСТОЯННО ВЗАИМОДЕЙСТВУЮ МЕЖДУ СОБОЙ.

---

…так?

---

(1) Штуковины.

---

Субъект. Оператор. Состояния субъекта. Экспрессия состояний субъекта. Экспрессия оператора. Интерфейсы состояний субъекта. Интерфейсы экспрессии оператора. Алгоритм якорения. Якоря. Раппорт. Биологическая обратная связь – БОС. Ресурсы/Нересурсы. Сигналы.

---

(2) Постоянные характеристики.

---

Субъект – Испытывает состояния. Экспрессирует состояния на интерфейсах состояний.

---

Оператор – Реализует алгоритм интеграции якорей. Реализует процесс раппорта. Заполняет интерфейсы экспрессии оператора.

---

Состояния субъекта – четырех типов: ресурсные, нересурсные, нейтральные, иные.

---

Экспрессия состояний субъекта – четырех типов: ресурсная, нересурсная, нейтральная, иная.

---

Экспрессия оператора – соответствует шагам алгоритма якорения.

---

Интерфейсы состояний субъекта – Ресурсные, Нересурсные, Вербальные, Невербальные.

---

Интерфейсы экспрессии оператора – Вербальные, Невербальные, Алгоритмические якорения, Раппорта, БОС.

---

Алгоритм якорения – Описание алгоритма, Алгоритм на интерфейсе оператора. Алгоритм на интерфейсе субъекта. БОС-компонента алгоритма. Раппорт-компонента алгоритма.

---

Якоря – Два якоря, входящие в алгоритм интеграции якорей. Дополнительные якоря (а) раппорта (бос) и т.п.

---

Раппорт – Вербальный, Невербальный, Сознательный, Подсознательный, Декодерный, Языкоидный, Буквалисткий и т.п.

---

Биологическая обратная связь – БОС – сигналы БОС. Параметры сигналов БОС.

---

Ресурсы/Нересурсы – в виде Описаний, в виде Сигналов, в виде Интерфейсов.

---

Сигналы – Вербальные, Невербальные, Сознательные, Бессознательные, Ресурсные, Нересурсные, Иные и т.п.

---

(2) Характеристики, связывающие классы.

---

…

Как я понимаю, в диаграмме классов мы должны описать:

---

-- онтологию наличествующих у нас в конкретном кейсе «штуковин»

---

Да, точно.

---

--расписать через «характеристики» (а) что эти штуковины ПОСТОЯННО ДЕЛАЮТ

---

Два типа параметров штуковин:

---

- какие атрибуты у них ЕСТЬ (множество текущих атрибутов фактически задаёт внутреннее состояние объекта)

---

- что они ДЕЛАЮТ (какие у них методы/функции)

---

(б) как эти штуковины ПОСТОЯННО ВЗАИМОДЕЙСТВУЮ МЕЖДУ СОБОЙ.

---

…так?

---

Нет, здесь не совсем так. На этой диаграмме отмечается только РАЗНОВИДНОСТЬ/ХАРАКТЕР СВЯЗИ МЕЖДУ КЛАССАМИ. Основные типы связей:

---

- один к одному

---

- один ко многим

---

- много ко многим

---

- наследование

---

(1) Субъект:

---

--генерирует состояния.

---

--генерирует сигналы

---

--заполняет интерфейс экспрессии

---

(2) Оператор:

---

--сортирует состояния субъекта на ресурсные нересурсные

---

--заполняет интерфейс оператора

---

--реализует раппорт

---

--реализует БОС

---

…

---

(3) Оператор выделяет из нересурсных одно нересурсное переживание/ нересурсную тему.

---

(4) Оператор заставляет субъекта пережить выбранное нересурсное переживание или тему.

---

(5) Оператор ставит на нересурсное переживание/тему якорьН.

---

(6) Оператор заставляет субъекта переживать нейтральное состояние.

---

(7) Оператор заставляет субъекта переживать ресурсные переживания.

---

(8) Оператор ставит на ресурсные переживания якорьР.

---

(9) Оператор калибрует полученные якоряН и Р путем их чередования с нейтральным переживанием.

---

(10) Затем, на фоне нейтрального переживания, оператор активизирует одновременно якорьР + якорьН и дожидается их интеграции, обнаруживаемой по наблюдению смешанной невербальной реакции.

---

(11) Затем оператор калибрует результат интеграции путем оживления одного из якорей и отслеживания появления смешанной реакции.

--Как я понимаю, в диаграмме классов мы должны описать: - онтологию наличествующих у нас в конкретном кейсе «штуковин»

---

--Да, точно.

---

Понятно.

---

--расписать через «характеристики» (а) что эти штуковины ПОСТОЯННО ДЕЛАЮТ.

---

--Два типа параметров штуковин: - какие атрибуты у них ЕСТЬ (множество текущих атрибутов фактически задаёт внутреннее состояние объекта) - что они ДЕЛАЮТ (какие у них методы/функции)

---

Непонятно.

---

Причем здесь множество атрибутов и внутренние состояния субъекта?

---

Что характеризует классы и их взаимодействие:

---

--характеристики

---

--атрибуты

---

...Так? Чем Характеристики отличаются от Атрибутов?

---

--(б) как эти штуковины ПОСТОЯННО ВЗАИМОДЕЙСТВУЮ МЕЖДУ СОБОЙ. …так?

---

--Нет, здесь не совсем так. На этой диаграмме отмечается только РАЗНОВИДНОСТЬ/ХАРАКТЕР СВЯЗИ МЕЖДУ КЛАССАМИ. Основные типы связей: - один к одному - один ко многим - много ко многим - наследование

---

Ага, ну так даже проще.

Нашёл интересное приближение к удобному средству многослойной аннотации текстов:

---

http://brat.nlplab.org/introduction.html

---

Несколько примеров:

---

http://brat.nlplab.org/examples.html

http://myminer.armi.monash.edu.au/annotation_tools.php

Ха, прикольно, спасибо :)

Не получилось его запустить локально.... Жалко.

Надо бы попробовать как-то разделять (и в проектировании ИТ систем такой же вопрос имеет место):

---

- "штуки"

---

- действия/функции штук

---

- КАЧЕСТВА действий/функций штук

---

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

---

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

---

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

---

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

---

--я крутой моделист, с огромной практикой различных техник типа якорения

---

--сам же предложивший идею использования UML для настоящей формализации моделей и техник ЧА

---

--и даже ранее пробующий тренироваться в вышеуказанном

---

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

---

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

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

---

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

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

---

А что такое может быть эта "штука" (объект, класс и т.д.) ФЕНОМЕНОЛОГИЧЕСКИ? Это получается что-то вроде части/ментального процесса?

Ну, так это самый главный вопрос. Но, с самого начала ясно, что штука:

---

--это не переживание

---

--штука это какой-то универсальный квант метальных процессов

---

...не знаю. М.б. штука это какой-то кусок вербального_формы + связанного с ним невербального + вербального_содержания.

Типа прото-языкоид?

Ну, если я тебя правильно понял, то штука это такой эээ феноменальный языкоид. Значимая функциональная часть.

Надо паттерны проектирования смотреть. В них можно будет ухватить аналогию между ООП и ЧА.

Ну да.

ещё бы добавил

---

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

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