MOLD: morphology description language

Chapter 2. MOLD: morphology description language

UML as part of a comprehended morphotransformation · MOLD = UML plus extensions · MOVE as a 16-dimensional vector · Six main facets · Reserved diagrams · Model as code

2. 1. UML as part of a comprehended morphotransformation

In the 1990s, a group of developers of object-oriented programming faced the task of describing complex software systems in which the number of classes reached the hundreds and the number of relations between them the thousands. The textual representation of code could not cope: a programmer could see the individual classes but could not see the system. The response was the creation of a unified graphical modelling language — UML (Unified Modeling Language), which by the end of the decade integrated the experience of several preceding notations.

UML is built around the idea of multiplicity of projections. A complex system is not described by a single diagram — it is projected onto several different representations, each of which highlights a definite aspect. A class diagram represents the static structure of types. A sequence diagram represents the temporal dynamics of message exchange. A state diagram represents the life cycle of entities. A deployment diagram represents the distribution over physical nodes. Each diagram taken separately is simple and clear; together they give a complete description of the system. By the time of the standardization of UML 2.0 in 2005, the specification included 14 types of diagrams.

From the point of view of the present book, UML is not just an engineering notation but a recorded fragment of the comprehension of morphotransformation. The authors of UML sought a way to describe complex systems of interacting entities and independently arrived at the same categories that evolution selected over billions of years — classes, components, connections, activities, states. This coincidence is not accidental: both processes — UML modelling and the evolutionary training of GTR0 — solve the same task: describing a structure composed of many interacting elements with characteristic relations.

Yet UML stops at the stage of description. A class diagram describes classes but does not create them. An activity diagram describes behaviour but does not execute it. A UML model exists as a blueprint — a static description that the programmer subsequently translates into executable code. Between model and code there remains a gap that various code-generation technologies (MDA, executable UML) tried to bridge but with no decisive success.

Gativus removes this gap differently. Not through code generation from the model, but through the structural identification of the model with the running network. In the Gativus architecture a UML model is not a description of a future system, but one of the two forms of an already existing system — its folded form in the space of ontogeny. The unfolding of the model into a running network is performed not by a compiler but by morphogenesis RTR0. We will return to this solution in section 2.6.

2. 2. MOLD: UML in notation, Gativus in semantics

MOLD (MOrphology Language Description) — the formal language of morphology description in Gativus. A foundational decision underlying MOLD is that the language inherits its notation from UML but does not inherit its semantics. The names of diagrams, the graphical elements, the types of lines, the ways of marking entities — all are taken from UML and visual similarity is preserved. The meaning of what is marked is determined by the Gativus architecture and need not coincide with what the same constructions mean in UML.

This decision serves a pedagogical purpose. Over thirty years UML has become the de facto standard of engineering communication; a substantial part of the Gativus audience is familiar with its notation. Using a familiar visual language significantly lowers the entry threshold into the Gativus architecture. A reader who sees a MOLD diagram recognizes the notation and can therefore concentrate on what is described, instead of being distracted by how it is drawn.

a) What is inherited from UML

MOLD preserves the multiplicity of projections. A complete description of a Gativus organism is distributed across several diagrams, each highlighting one aspect. The names of the diagrams are abbreviated to four characters according to the rules of Gativus notation (GNOT) and correspond to UML names: class diagram — CLSS, component diagram — COMP, communication diagram — COMM, activity diagram — ACTD, and so on.

MOLD preserves the basic visual elements. Classes are represented by rectangles divided into sections. Nodes are represented by cubes or three-dimensional rectangles. Connections are represented by arrows of different styles. States are represented by rectangles with rounded corners. Activities are represented by rounded shapes. Anyone who has worked with UML recognizes these elements immediately.

MOLD preserves the principle of mutual consistency of diagrams. An entity appearing on several diagrams denotes one and the same reality. A class mentioned in CLSS, placed in COMP, connected in COMM — is the same object projected onto three different representations.

b) What is added in MOLD

MOLD extends UML with several constructions of principle that reflect the specifics of the Gativus architecture.

Connectors as first-class entities. In UML, a connection between entities is usually a line with annotations. In Gativus, a connector is an independent data unit: a typed access point with a unique address, states (PEND, ACTV), and its own life cycle. MOLD represents connectors explicitly — as pins and sockets on the bodies of components, protruding beyond the edges of the boxes. This is consistent with the GNOT notation and with the architecture of NDDI nodes described in GNET.

Typing of connections through CONT. Every relation in Gativus has a CONT (Connector Type) type, which determines connector compatibility. A connector of one type cannot be physically connected to a connector of another type — a structural constraint similar to the incompatibility of different standard plugs in electronics. MOLD reflects this through shapes and colours of pins and sockets being typed on the diagram.

AVEC as a resource vector. In UML, resources are mentioned indirectly (through deployment diagrams) but there is no formalized representation. In Gativus, resources and permissions are an essential aspect — they determine whether a node can be created. MOLD introduces a separate resource diagram RSRC, which formalizes the distribution of AVEC across functional organs.

Distinction between the D-level and the G-level. The structural code of a node (D-section, object code, gene) and the dynamic relations (G-level, synapses, expression) differ in principle, although they are implemented on the same substrate. MOLD distributes these two aspects across different diagrams and uses different graphical conventions for D-relations and G-relations.

Temporal dimension of the critical period. Morphogenesis has a bounded window of activity: after the closure of the critical period, the creation of new nodes and the establishment of new G-relations are sharply curtailed. MOLD records this aspect on the activity diagram through explicit transitions between modes of morphogenesis, maturation, and operation.

c) What is not inherited

MOLD does not inherit the semantics of UML, which is grounded in the paradigm of object-oriented programming. A UML class is a template for creating objects through constructor calls. A MOLD class is a template for creating NDDI nodes through the NRGN procedure, and NRGN differs fundamentally from a constructor call. UML methods are functions called on objects. In MOLD, the correspondence between messages and activities is mediated through the A-section and through reactions to changes in V-components.

These semantic differences do not undermine the possibility of using UML notation: they merely change the interpretation. The diagram looks like UML, but it describes a Gativus structure.

2. 3. MOVE as a 16-dimensional vector

In Gativus, the complete description of an organism is formalized as MOVE (MOrphology VEctor) — a vector in a 16-dimensional space, each coordinate of which corresponds to one diagram of MOLD. The dimension 16 is determined by the number of diagrams in UML 2.0 (14) plus two Gativus-specific extensions (SPCE, RSRC).

A concrete organism is described by the values of all 16 coordinates — the contents of each corresponding diagram. Not every coordinate is necessarily filled for every organism: for simple functional organs, several supporting diagrams suffice, whereas for a complete network of subjective reality, all diagrams are engaged. An unfilled coordinate means that the corresponding aspect is not specific to this organism.

a) Supporting cube: the six main diagrams

Among the 16 coordinates, six are practically used for the description of every Gativus organism and form the supporting set. Their geometrical analogue is a cube with six faces, each corresponding to one diagram. This analogy uses the visual device already familiar from NDDI notation (polyhedra made of sections) and offers an intuitively clear mental model.

The six main diagrams:

This set suffices to describe the overwhelming majority of functional organs of Gativus. The detailed content of each of the six supporting diagrams is given in section 2.4.

b) Reserved coordinates

The remaining ten coordinates correspond to UML diagrams that are used less in the current Gativus architecture or that do not yet have a specific meaning. These coordinates are reserved — each is fixed in MOLD notation by a four-character name, but its detailed semantics remain open for future extensions. Which of the reserved diagrams will be retained as independent coordinates of MOVE and which will be abandoned will be decided by the practice of building the first working organisms. The reserved diagrams are listed in section 2.5.

c) Parametrization of MOVE

A property of principle of MOVE is its parametrization. The vector does not contain absolute values in quantitative terms. It does not prescribe "create exactly one hundred thousand nodes of class A", but describes rules and proportions: "class A — the main population of this organ", "class B — supporting population, ten times smaller than A", "connections between A and B — dense, between B and C — sparse".

The concrete scale of the unfolding is determined not by MOVE itself but by the AVEC resources available at the moment of morphogenesis. The same MOVE unfolded on different platforms with different resources yields functionally identical but quantitatively different organs. This is a direct analogue of biological variability: the same DNA executed under different nutrition and environment yields individuals of the same species but of different sizes. Gativus inherits this property as essential.

Parametrization gives MOVE compactness. A description of several kilobytes is capable of producing millions of nodes upon unfolding, because the rules are more compact than the result. The concrete topology of the running network is not recorded in MOVE — it is computed at the time of SYGA through autonomous search for partners, and until the completion of morphogenesis it does not exist anywhere.

2. 4. Six main facets

The following describes the six supporting diagrams of MOLD. Each is given a brief characterization: what it describes, what entities are its basic elements, what its notation looks like. A detailed description of the procedures using these diagrams is given in Chapters 3–5.

a) CLSS — class diagram

Describes the types of NDDI nodes existing in an organism. A class is a structural template of a node, which fixes the set of its sections (V, A, S, G, T, C, L, M depending on level), the types of its connectors (indicating CONT), and the d-relations to the D-components in the ROOT repository that implement the node's logic.

On the diagram, classes are represented in the UML-like manner: a rectangle with three sections. Upper — class name. Middle — composition by components (for example, V[3], A[2], L[1]). Lower — list of connectors with their CONT types. Connections between classes denote inheritance and composition relations; they are essential for optimizing the D-section and do not specify connections between concrete nodes.

CLSS is the most basic of all diagrams. It determines what nodes can exist in an organism. Without CLSS, the other diagrams lose their subject: COMM cannot determine connections between non-existent types, COMP cannot group undefined entities.

b) COMP — component diagram

Describes the grouping of classes into functional organs. A Gativus organism contains several organs — the spatial domain, the object domain, the symbolic domain, the narrative domain, the axiological domain, and so on. Each organ implements its own function and is composed of nodes of several classes in determinate proportions.

On the diagram, a component is represented by a container with an explicit boundary. Inside the container — the classes belonging to the organ. Connections between containers denote inter-organ interfaces — that is, the types of connectors through which the nodes of one organ interact with the nodes of another.

COMP answers the question of what an organism consists of. In the architecture of morphogenesis it determines the splitting of MOVE upon delegation from GATE to ANOD: each ANOD receives a fragment of MOVE associated with one component. This is considered in detail in Chapter 5.

c) COMM — communication diagram

Describes templates of connections between classes — who communicates with whom in the running network and how. It is the most voluminous of the diagrams in MOLD: the number of connection templates in a developed organism reaches the tens, while the number of classes is in the units or tens.

Each template describes one relation: which type of node connects to which, through which connector, with what topology (point-to-point, many-to-one, many-to-many), with what density, with or without delivery confirmation. At the moment of morphogenesis, one template produces thousands or millions of concrete connections — and the size of MOVE does not grow.

Templates are divided into deterministic and autonomous. A deterministic template fixes explicitly a connection between concrete classes; at morphogenesis it is realized through SYGD. An autonomous template describes only the type of connector, leaving the search for a partner to the SYGA phase. This distinction is described in detail in Chapter 4.

d) ACTD — activity diagram

Describes the procedural side of morphogenesis and operation: the sequence of phases, transitions between states, control points. Here are recorded the processes of germination (the sequence parsing — neurogenesis — synaptogenesis — maturation — verification — transition), the transformation of OPNG into OPN, the closure of the critical period.

Standard UML elements are used on the activity diagram: action nodes (rounded rectangles), decision nodes (diamonds), synchronization nodes (parallel bars), initial and final states. ACTD in Gativus is essentially dependent on parallelism: phases of morphogenesis overlap in time rather than proceeding sequentially, and the diagram must reflect this.

ACTD is the bridge between the static structure (CLSS, COMP, COMM) and the temporal dynamics of the life cycle. Without it, it is impossible to describe in what order classes are created, when deterministic connections are established, when autonomous search for partners is started, when organs enter the operational mode.

e) SPCE — deployment diagram

Describes the physical distribution of an organism's nodes across the GATE platforms. An organism may be distributed over several platforms — for example, different functional organs may reside on different physical devices with different resources. SPCE formalizes this distribution.

On the deployment diagram, GATEs are represented as deployment nodes (three-dimensional boxes in UML notation), inside which classes or components are placed. Connections between GATEs denote network routes over which inter-platform relations pass. SPCE is a partial extension of the UML deployment diagram: the basic elements are inherited but the semantics are adapted to the Gativus architecture.

SPCE has essential practical significance: different functional organs have different resource requirements, and their optimal distribution across physical platforms is a task at network initialization. The axiological and symbolic domains require significantly more resources than the spatial domain and can be placed on separate GATEs with appropriate parameters.

f) RSRC — resource diagram

Describes the distribution of AVEC and other resource budgets across functional organs and classes. This is a complete Gativus extension that has no direct analogue in UML. RSRC formalizes what in UML is outside the model: how many nodes are allowed to be created in each organ, what are the quotas of synaptogenesis, what security policies apply.

On the resource diagram, the basic elements are resource nodes (represented as stylized wallets or containers with counters) and delegation flows (arrows with quantitative annotations). The delegation of AVEC from ROOT to GATE, from GATE to ANOD, from ANOD to subordinate nodes is represented explicitly with the size of the delegated pool.

RSRC is in principle necessary for Gativus because resource constraints in this architecture are not an auxiliary aspect but a structural mechanism. The size of a functional organ is not determined by some value in MOVE — it is determined by the distribution of AVEC through RSRC. Without RSRC it is impossible to describe the variability in the size of organs between different instances of the same MOVE.

2. 5. Ten reserved diagrams

The six supporting diagrams cover the main aspects of describing a Gativus organism. The remaining ten coordinates of MOVE are reserved for diagrams that have UML 2.0 analogues or are specific to future Gativus extensions. Each is fixed in MOLD notation by a four-character name; the detailed semantics of most of them remain open and will be refined by engineering practice.

Reserving these names now without fully elaborating their semantics has concrete significance: it fixes the name space and prevents conflicts in subsequent extensions. Which of the reserved diagrams will be retained as independent coordinates of MOVE and which will remain unused or be merged with existing ones will be decided by the practice of building the first working organisms.

Current list of reserved diagrams:

A few notes on the most important reserved diagrams. SEQU (Sequence diagram) appears to be a natural candidate for promotion to the supporting set: the temporal sequence of message exchange is principled for describing the SYGN protocol and neurogenesis. Perhaps in a future revision of this book, SEQU will move into the supporting diagrams. STAT (State machine) is closely related to ACTD and may be merged with it or, conversely, separated into a dedicated diagram for describing connector life cycles (PEND → ACTV).

The usefulness of the remaining reserved diagrams for Gativus is less obvious. USEC and OBJC in UML describe interaction with the outside world and concrete configurations — these two aspects are expressed otherwise in Gativus: external interaction through SPCE and RSRC, configuration through the state of the running network. Perhaps these MOVE coordinates will remain unfilled in most descriptions.

2. 6. UML model as MOVE: model as code

A principled consequence of the MOLD architecture concerns the relation between model and running system. In traditional programming, a UML model is a static blueprint from which the programmer writes executable code. Between model and code there is a gap: changes in the model do not automatically lead to changes in the code, and maintaining their consistency requires constant effort. Code-generation technologies (MDA — Model-Driven Architecture, executable UML) tried to bridge this gap, but did not succeed completely: the automatically generated code is either insufficiently efficient or requires manual edits — which brings back the problem of inconsistency.

Gativus solves this problem differently — not by generation but by structural identification. A UML model formed by the rules of MOLD is MOVE. Placed in the M-section of a node, at activation it launches RTR0. No code generation takes place: the D-components in the ROOT repository already contain the executable logic of the corresponding classes, and MOVE, when unfolded, only indicates which D-components to use, in what quantity, and with which connections.

This solution differs fundamentally from MDA in several points. Code generation does not occur, and so there is no problem of the quality of the generated code — already trained D-components are executed, not a machine translation of the model. The consistency of the model with the running network is maintained not by some synchronization process but by structural identity — unfolding is a function of MOVE, and any change in MOVE is directly reflected in the running network at the next germination. Modifying the model does not require an additional compilation step: a new version of MOVE is simply unfolded into a new organism.

a) What this means for the developer

For an engineer working on Gativus, describing an organism is the construction of a MOLD model in a visual editor. Existing tools for UML modelling (IDE plugins, dedicated environments) can be adapted for MOLD without changing the principle of the interface: the same diagrams, the same notation, the same editing operations. The engineering skill accumulated over decades of working with UML transfers directly.

The difference appears at the execution stage. A completed MOLD model is not compiled into code — it is packaged into MOVE and placed in a GERM. Upon being placed on a GATE platform with sufficient AVEC, the GERM autonomously starts germination. The result is a running network, structurally corresponding to the model but individual in detail (concrete UNONs, concrete SYGA connections, concrete initial states).

b) Bijection between model and running network

The structural identification of model and MOVE closes the bijection between the two spaces of Gativus described in Chapter 1. Every node in the running network has an ontogenetic dual in the M-section — a record referencing some class in the CLSS diagram. Every class in CLSS exists not only in the model but also in the running network as a type of real nodes. Every relation in COMM has a real embodiment in the established connectors.

This bijection allows nodes in the running network to call their own description through the m-relation and analyse it. A network reaching maturity can use its own MOLD model as the object of reflection — for example, to design the next version of the organism. In the limit, this yields a closed loop: the running network participates through DTR0 in the encapsulation of its own structure, producing a new MOVE, which on the next unfolding creates the next generation of organisms. This aspect belongs to the recursive mode described in GTOM.

2. 7. Transition to Chapter 3

This chapter has introduced MOLD — the formal language of morphology description in Gativus, built on UML notation and extended with constructions that reflect architectural specifics. MOVE has been defined as a 16-dimensional vector whose coordinates correspond to the diagrams of MOLD. The six supporting diagrams (CLSS, COMP, COMM, ACTD, SPCE, RSRC) have been substantively described; the ten reserved diagrams have been listed with preliminary notes on their possible role.

The principled architectural decision — model as code — removes the split between description and execution that is characteristic of traditional programming. A MOLD model formed by the rules of MOVE is unfolded into a running network through RTR0 without intermediate code generation.

Open remains the question of the status of MOVE as an object of the Gativus network. Is MOVE a component of a node, a digital asset, or an entity of dual nature? This question is the subject of the next chapter. Chapter 3 considers GERM as the container of the seed, examines its connection with MOVE and OPNG, and resolves the issue of the mechanism of description transfer between network nodes.