MOLD: язык описания морфологии

Глава 2. MOLD: язык описания морфологии

UML как понятая часть морфотрансформации · MOLD = UML с расширениями · MOVE как 16-мерный вектор · Шесть основных граней · Резервные диаграммы · Модель как код

2. 1. UML как понятая часть морфотрансформации

В 1990-х годах группа разработчиков объектно-ориентированного программирования столкнулась с задачей описания сложных программных систем — таких, в которых количество классов достигает сотен, а количество отношений между ними — тысяч. Текстовое представление кода переставало справляться: программист видел отдельные классы, но не видел системы. Ответом стала разработка унифицированного графического языка моделирования — UML (Unified Modeling Language), консолидировавшего опыт нескольких предыдущих нотаций к концу десятилетия.

UML строится вокруг идеи множественных проекций. Сложная система не описывается одной диаграммой — она проецируется на несколько различных представлений, каждое из которых выделяет определённый аспект. Диаграмма классов показывает статическую структуру типов. Диаграмма последовательностей — временную динамику обмена сообщениями. Диаграмма состояний — жизненный цикл сущности. Диаграмма размещения — распределение по физическим узлам. Каждая диаграмма проста и понятна по отдельности; их совокупность даёт полное описание системы. К моменту стандартизации UML 2.0 в 2005 году в спецификацию вошло 14 типов диаграмм.

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

Однако UML остановился на этапе описания. Диаграмма классов описывает классы, но не создаёт их. Диаграмма активности описывает поведение, но не исполняет его. UML-модель существует как чертёж — статическое описание, которое программист затем переводит в исполняемый код. Между моделью и кодом сохраняется зазор, который пытались закрыть различные технологии генерации кода (MDA, executable UML), но без решающего успеха.

Гативус устраняет этот зазор иначе. Не через генерацию кода из модели, а через структурную идентификацию модели и работающей сети. UML-модель в архитектуре Гативус является не описанием будущей системы, а одной из двух форм существующей системы — её свёрнутой формой в пространстве онтогенеза. Развёртка модели в работающую сеть выполняется не компилятором, а морфогенезом RTR0. К этому решению вернёмся в разделе 2.6.

2. 2. MOLD: UML по нотации, Гативус по семантике

MOLD (MOrphology Language Description) — формальный язык описания морфологии в Гативус. Принципиальное решение, лежащее в основе MOLD: язык наследует у UML нотацию, но не наследует семантику. Имена диаграмм, графические элементы, типы линий, способы обозначения сущностей — взяты из UML и сохраняют визуальное сходство. Смысл обозначаемого — определяется архитектурой Гативус и не обязан совпадать с смыслом тех же конструкций в UML.

Это решение преследует одну педагогическую цель. UML за тридцать лет стал де-факто стандартом инженерной коммуникации; значительная часть аудитории Гативус знакома с его нотацией. Использование привычного визуального языка резко снижает барьер вхождения в архитектуру. Читатель, видящий диаграмму MOLD, узнаёт нотацию и может сосредоточиться на что описывается, не отвлекаясь на как это нарисовано.

a) Что наследуется от UML

MOLD сохраняет множественность проекций. Полное описание организма Гативус разделяется на несколько диаграмм, каждая из которых выделяет один аспект. Имена диаграмм совпадают с UML с точностью до сокращения до четырёх символов согласно правилам нотации Гативус (GNOT): диаграмма классов — CLSS, диаграмма компонентов — COMP, диаграмма коммуникаций — COMM, диаграмма активности — ACTD, и так далее.

MOLD сохраняет базовые визуальные элементы. Класс изображается прямоугольником с разделёнными секциями. Узел — кубом или трёхмерным прямоугольником. Связи — стрелками с различными наконечниками. Состояние — закруглённым прямоугольником. Активность — фигурой со скруглёнными углами. Эти элементы узнаются мгновенно любым, кто работал с UML.

MOLD сохраняет принцип взаимной согласованности диаграмм. Сущности, появляющиеся на нескольких диаграммах, обозначают одну и ту же реальность. Класс, упомянутый в CLSS, размещаемый в COMP и связываемый в COMM — это один объект, проецируемый на три различных представления.

b) Что добавляется в MOLD

MOLD расширяет UML несколькими принципиальными конструкциями, отражающими специфику архитектуры Гативус.

Соединители как первоклассные сущности. В UML связь между сущностями — это, как правило, линия с пометками. В Гативус соединитель — самостоятельная единица данных: типизированная точка подключения с уникальным адресом, состоянием (PEND, ACTV) и собственным жизненным циклом. MOLD изображает соединители явно — как штырьки и розетки на теле компонентов, выступающие за границы блока. Это согласуется с нотацией GNOT и с архитектурой узла NDDI, описанной в GNET.

Типизация связей через CONT. Каждое отношение в Гативус имеет тип CONT (Connector Type), определяющий совместимость соединителей. Соединитель одного типа физически не может быть подключён к соединителю другого типа — это структурное ограничение, аналогичное несовместимости разъёмов разных стандартов в электронике. MOLD отражает это типизацией формы и цвета штырьков и розеток на диаграммах.

AVEC как ресурсный вектор. В UML ресурсы упоминаются косвенно (через диаграмму размещения), но не имеют формального представления. В Гативус ресурсы и полномочия являются существенным аспектом — они определяют, может ли вообще быть создан тот или иной узел. MOLD вводит отдельную диаграмму ресурсов RSRC, формализующую распределение AVEC по функциональным органам.

Различение D-уровня и G-уровня. Структурный код узла (D-секция, объектный код, гены) и динамические отношения (G-уровень, синапсы, экспрессия) принципиально различны по природе, хотя реализуются на одном субстрате. MOLD разделяет эти аспекты на разные диаграммы и использует различные графические соглашения для D-отношений и G-отношений.

Временное измерение критического периода. Морфогенез имеет ограниченное окно активности: после закрытия критического периода создание новых узлов и установление новых G-отношений резко сокращается. MOLD фиксирует этот аспект на диаграмме активности через явные переходы между режимами морфогенеза, созревания и эксплуатации.

c) Что не наследуется

MOLD не наследует семантику UML, основанную на парадигме объектно-ориентированного программирования. Класс в UML — шаблон для создания объектов через вызов конструктора. Класс в MOLD — шаблон для создания узлов NDDI через процедуру NRGN, существенно отличающуюся от вызова конструктора. Метод в UML — функция, вызываемая на объекте. В MOLD соответствие между сообщением и активностью опосредовано А-секцией и реакциями на изменение V-компонентов.

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

2. 3. MOVE как 16-мерный вектор

Полное описание организма в Гативус формализуется как MOVE (MOrphology VEctor) — вектор в 16-мерном пространстве, каждая координата которого соответствует одной из диаграмм MOLD. Размерность 16 определяется числом диаграмм UML 2.0 (14) с добавлением двух специфических расширений Гативус (SPCE, RSRC).

Конкретный организм описывается значениями всех 16 координат — содержимым каждой соответствующей диаграммы. Не каждая координата обязательно заполнена для каждого организма: для простых функциональных органов достаточно нескольких опорных диаграмм, тогда как для полной сети субъективной реальности задействуются все. Незаполненная координата означает, что соответствующий аспект для данного организма не специфичен.

a) Опорный куб: шесть основных диаграмм

Из 16 координат шесть используются практически для каждого описания организма Гативус и образуют опорный набор. Геометрическая аналогия — куб с шестью гранями, каждая грань соответствует одной диаграмме. Эта аналогия использует визуальный приём, уже знакомый по нотации NDDI (многогранник из секций), и обеспечивает интуитивно понятную ментальную модель.

Шесть основных диаграмм:

Этот набор достаточен для описания подавляющего большинства функциональных органов Гативус. Подробное содержание каждой из шести опорных диаграмм даётся в разделе 2.4.

b) Резервные координаты

Десять оставшихся координат соответствуют диаграммам UML, которые в текущей архитектуре Гативус используются реже или пока не имеют специфического значения. Эти координаты резервируются — за каждой закрепляется четырёхсимвольное имя в нотации MOLD, но детальная семантика остаётся открытой для будущих расширений. Какие из них приживутся, а какие отомрут, определит инженерная практика. Резервные диаграммы перечислены в разделе 2.5.

c) Параметричность MOVE

Принципиальное свойство MOVE — параметричность. Вектор не содержит абсолютных значений в количественных терминах. Он не указывает «создать ровно сто тысяч узлов класса A», а описывает правила и пропорции: «класс A — основная популяция данного органа», «класс B — поддерживающая популяция, в десять раз меньше A», «связи между A и B — плотные, между B и C — разреженные».

Конкретный масштаб развёртки определяется не самим MOVE, а доступными ресурсами AVEC в момент морфогенеза. Один и тот же MOVE, развёрнутый на разных платформах с разными ресурсами, даст функционально одинаковые, но количественно различные органы. Это прямая аналогия с биологической вариабельностью: одна и та же ДНК, исполненная при разных условиях питания и среды, даёт особей одного вида разного размера. Гативус наследует это свойство как существенное.

Параметричность даёт MOVE компактность. Килобайты описания способны порождать миллионы узлов при развёртке, потому что правила компактнее результата. Конкретная топология работающей сети не записана в MOVE — она вычисляется в момент SYGA через автономный поиск партнёров и не существует нигде до завершения морфогенеза.

2. 4. Шесть основных граней

Опорные шесть диаграмм MOLD описываются ниже. Каждая получает краткую характеристику: что описывает, какие сущности являются основными элементами, как выглядит нотация. Подробное описание процедур, использующих эти диаграммы, даётся в Главах 3–5.

a) CLSS — диаграмма классов

Описывает типы узлов NDDI, существующих в данном организме. Класс — структурный шаблон узла, фиксирующий набор секций (V, A, S, G, T, C, L, M в зависимости от уровня), типы соединителей с указанием CONT, и d-отношения к D-компонентам в ROOT-репозитории, реализующим логику узла.

На диаграмме класс изображается аналогично UML: прямоугольник с тремя секциями. Верхняя — имя класса. Средняя — состав по компонентам (например, V[3], A[2], L[1]). Нижняя — перечень соединителей с типами CONT. Связи между классами обозначают отношения наследования и композиции; они существенны для оптимизации D-секции и не задают связи между конкретными узлами.

CLSS — самая фундаментальная из диаграмм. Она определяет, какие узлы могут существовать в организме. Без CLSS остальные диаграммы беспредметны: COMM не может определить связи между несуществующими типами, COMP не может группировать неопределённые сущности.

b) COMP — диаграмма компонентов

Описывает группировку классов в функциональные органы. Один организм Гативус содержит несколько органов — пространственный домен, объектный, символьный, нарративный, аксиологический и так далее. Каждый орган реализует свою функцию и состоит из узлов нескольких классов с определёнными пропорциями.

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

COMP отвечает на вопрос из чего состоит организм. В архитектуре морфогенеза она определяет расщепление MOVE при делегировании от GATE к ANOD: каждый ANOD получает фрагмент MOVE, относящийся к одному компоненту. Подробнее это рассматривается в Главе 5.

c) COMM — диаграмма коммуникаций

Описывает шаблоны связей между классами — с кем и как общаются узлы в работающей сети. Это самая объёмная из диаграмм MOLD: количество шаблонов связей в развитом организме исчисляется десятками, тогда как количество классов — единицами или десятками.

Каждый шаблон описывает одно отношение: какой тип узла соединяется с каким типом, через какие соединители, с какой топологией (точка-точка, многие-к-одному, многие-ко-многим), с какой плотностью, с подтверждением доставки или без. Один шаблон порождает тысячи или миллионы конкретных связей при морфогенезе — без роста размера MOVE.

Шаблоны разделяются на детерминированные и автономные. Детерминированные шаблоны явно фиксируют связи между конкретными классами и реализуются через SYGD при морфогенезе. Автономные шаблоны описывают только типы соединителей, оставляя поиск партнёров на этап SYGA. Подробнее это различение описано в Главе 4.

d) ACTD — диаграмма активности

Описывает процедурные аспекты морфогенеза и эксплуатации: последовательность фаз, переходы между состояниями, контрольные точки. Здесь фиксируются такие процессы, как герминация (последовательность парсинг–нейрогенез–синаптогенез–созревание–верификация–переход), трансформация OPNG → OPN, закрытие критического периода.

На диаграмме активности используются стандартные UML-элементы: узлы действия (закруглённые прямоугольники), узлы решения (ромбы), узлы синхронизации (параллельные линии), начальное и конечное состояния. ACTD в Гативус существенно опирается на параллельность: фазы морфогенеза перекрываются во времени, а не идут последовательно, и диаграмма должна это отражать.

ACTD — мост между статической структурой (CLSS, COMP, COMM) и временной динамикой жизненного цикла. Без неё невозможно описать, в каком порядке создаются классы, когда устанавливаются детерминированные связи, когда запускается автономный поиск партнёров, когда орган переходит в режим эксплуатации.

e) SPCE — диаграмма размещения

Описывает физическое распределение узлов организма по платформам GATE. Один организм может быть распределён по нескольким платформам — например, разные функциональные органы могут жить на разных физических устройствах с разными ресурсами. SPCE формализует это распределение.

На диаграмме размещения GATE изображается как узел развёртывания (трёхмерный блок в нотации UML), внутри которого размещаются классы или компоненты. Связи между GATE обозначают сетевые маршруты, по которым проходят межплатформенные отношения. SPCE является частичным расширением UML deployment diagram: основные элементы наследуются, но семантика адаптирована под архитектуру Гативус.

SPCE имеет существенное практическое значение: разные функциональные органы имеют разные требования к ресурсам, и оптимальное распределение их по физическим платформам — одна из задач при инициализации сети. Аксиологический и символьный домены требуют существенно больших ресурсов, чем пространственный, и могут размещаться на отдельных GATE с соответствующими параметрами.

f) RSRC — диаграмма ресурсов

Описывает распределение AVEC и других ресурсных бюджетов по функциональным органам и классам. Это полное расширение Гативус, не имеющее прямого аналога в UML. RSRC формализует то, что в UML находится за пределами модели: сколько узлов разрешено создать в каждом органе, какие квоты на синаптогенез, какие политики безопасности применяются.

На диаграмме ресурсов основными элементами являются ресурсные узлы (изображаются как стилизованные кошельки или контейнеры со счётчиками) и потоки делегирования (изображаются как стрелки с количественными метками). Делегирование AVEC от ROOT к GATE, от GATE к ANOD, от ANOD к дочерним узлам показывается явно с указанием размеров делегируемых пулов.

RSRC принципиально нужна именно для Гативус, потому что ресурсное ограничение в этой архитектуре — не вспомогательный аспект, а структурный механизм. Размер функционального органа определяется не значением в MOVE, а распределением AVEC через RSRC. Без RSRC невозможно описать вариабельность размеров органов между экземплярами одного MOVE.

2. 5. Десять резервных диаграмм

Шесть опорных диаграмм покрывают основные аспекты описания организма Гативус. Десять оставшихся координат MOVE резервируются за диаграммами, имеющими аналоги в UML 2.0 или специфическими для будущих расширений Гативус. За каждой закрепляется четырёхсимвольное имя в нотации MOLD; детальная семантика для большинства из них остаётся открытой и будет уточнена по мере инженерной практики.

Резервирование имён сейчас, без полной разработки семантики, имеет конкретное значение: оно фиксирует пространство имён, предотвращая конфликты при последующих расширениях. Какие из резервных диаграмм приживутся как самостоятельные координаты MOVE, а какие останутся неиспользованными или сольются с существующими — определит практика построения первых работающих организмов.

Текущий список резервных диаграмм:

Несколько замечаний о наиболее значимых резервных диаграммах. SEQU (Sequence diagram) представляется естественной кандидатурой на промотирование в опорный набор: временная последовательность обмена сообщениями принципиальна для описания протоколов SYGN и нейрогенеза. Вероятно, в следующих редакциях книги SEQU перейдёт в число опорных. STAT (State machine) тесно связан с ACTD и может быть с ним объединён или, наоборот, выделен в отдельную диаграмму для описания жизненного цикла соединителей (PEND → ACTV).

Остальные резервные диаграммы менее очевидно полезны для Гативус. USEC и OBJC из UML описывают взаимодействие с внешним миром и конкретные конфигурации соответственно — оба аспекта в Гативус выражаются иначе: внешние взаимодействия через SPCE и RSRC, конфигурации через состояние работающей сети. Возможно, эти координаты MOVE останутся незаполненными в большинстве описаний.

2. 6. UML-модель как MOVE: модель есть код

Принципиальное следствие архитектуры MOLD касается соотношения модели и работающей системы. В традиционном программировании UML-модель — статический чертёж, на основании которого программист пишет исполняемый код. Между моделью и кодом сохраняется зазор: изменение в модели не приводит автоматически к изменению в коде, и поддержание соответствия требует постоянных усилий. Технологии генерации кода (MDA — Model-Driven Architecture, executable UML) пытались закрыть этот зазор, но не смогли полноценно: автоматически сгенерированный код всегда оставался либо недостаточно эффективным, либо требующим ручной доводки, что возвращало проблему рассогласования.

Гативус решает эту проблему иначе — не через генерацию, а через структурную идентификацию. UML-модель, оформленная по правилам MOLD, является MOVE. Помещённая в M-секцию узла, она запускает RTR0 при активации. Никакой генерации кода не происходит: D-компоненты в ROOT-репозитории уже содержат исполняемую логику соответствующих классов, и MOVE при развёртке только указывает, какие D-компоненты использовать, в каком количестве и в каких связях.

Это решение фундаментально отличается от MDA по нескольким пунктам. Генерация кода не происходит, и поэтому нет проблемы качества сгенерированного кода — исполняется обученный D-компонент, а не машинный перевод модели. Соответствие модели и работающей сети поддерживается не процессом синхронизации, а структурным тождеством — развёртка является функцией от MOVE, и любое изменение MOVE напрямую отражается в работающей сети при следующей герминации. Модификация модели не требует дополнительных шагов компиляции: новая версия MOVE просто разворачивается в новый организм.

a) Что это означает для разработчика

Для инженера, работающего с Гативус, описание организма — это построение MOLD-модели в визуальном редакторе. Существующие инструменты UML-моделирования (плагины IDE, специализированные среды) могут быть адаптированы для MOLD без принципиальных изменений интерфейса: те же диаграммы, та же нотация, те же приёмы редактирования. Инженерный навык, накопленный за десятилетия работы с UML, переносится напрямую.

Различие проявляется на этапе исполнения. Готовая MOLD-модель не компилируется в код — она упаковывается в MOVE и помещается в GERM. GERM, размещённый на платформе GATE с достаточным AVEC, запускает герминацию автономно. Результат — работающая сеть, структурно соответствующая модели, но индивидуальная в деталях (конкретные UNON, конкретные связи SYGA, конкретные начальные состояния).

b) Биекция между моделью и работающей сетью

Структурная идентификация модели и MOVE замыкает биекцию между двумя пространствами Гативус, описанную в Главе 1. Каждый узел в работающей сети имеет онтогенетический двойник в виде записи в M-секции, ссылающейся на класс из CLSS-диаграммы. Каждый класс в CLSS существует не только в модели, но и в работающей сети как тип реальных узлов. Каждое отношение в COMM имеет реальное воплощение в виде установленных соединителей.

Эта биекция позволяет узлу в работающей сети обращаться к собственному описанию через m-отношения и анализировать его. Сеть, достигшая зрелости, может использовать MOLD-модель самой себя как объект для рассуждений — например, для проектирования следующих версий организма. В пределе это даёт замкнутый цикл, в котором работающая сеть участвует в инкапсуляции собственной структуры через DTR0, порождая новый MOVE, который при последующей развёртке создаёт новое поколение организмов. Этот аспект относится к рекурсивному режиму, описываемому в GTOM.

2. 7. Переход к Главе 3

Настоящая глава ввела MOLD как формальный язык описания морфологии в Гативус, основанный на нотации UML и расширенный конструкциями, отражающими специфику архитектуры. MOVE определён как 16-мерный вектор, координаты которого соответствуют диаграммам MOLD. Шесть опорных диаграмм (CLSS, COMP, COMM, ACTD, SPCE, RSRC) описаны по существу; десять резервных перечислены с предварительными пометками о возможной роли.

Принципиальное архитектурное решение — модель есть код — снимает разрыв между описанием и исполнением, характерный для традиционного программирования. MOLD-модель, оформленная по правилам MOVE, разворачивается в работающую сеть через RTR0 без промежуточной генерации кода.

Открытым остаётся вопрос о статусе MOVE как объекта в сети Гативус. Является ли MOVE компонентом узла, цифровым ассетом или сущностью двойной природы? Этот вопрос — предмет следующей главы. Глава 3 рассматривает GERM как контейнер семени, его связь с MOVE и OPNG, и решает вопрос о механизме передачи описания между узлами сети.