Conceptual Guidelines

Conceptual Guidelines

There are about 25 conceptual guidelines. These are not presented in any specific order. These guidelines are a goal and do not all need to be adhered to in every system. If you are building a traditional event-driven system such as an embedded controller (see Watch and Elevator samples), then you will probably use fewer of these principles than if you are modeling biological systems (see Cell Model samples).

(1) Build your system from small primitives. These should all be roughly the same "size", should be compatible with each other, and should be able to fit together. It should be possible to manipulate these using genetic algorithms and other evolutionary processes. Examples of small primitives from biology include: amino acids, nucleic acids, lipids, sugars.

(2) Every Xholon in the system should inherit from a single superclass. In a Xholon-based system, this superclass is XholonClass.

(3) At run-time once the application is doing its repetitive processing, if possible, directly access the internal variables of other Xholons, or use simple accessor methods to do this. If necessary, use synchronous method calls or asynchronous message passing. This guideline works well for the Cell Model sample application (which uses set(), get(), inc(), dec()), but the Watch sample needs to use asynchronous messages.

(4) At design and configuration time, it's OK to use more tradional method calls and messages.

(5) As much as possible, build the system from the bottom up. Design the architecture so it can naturally be constructed this way. The system should develop (unfold) rather than have to be configured.

(6) The overall architecture of the system should be a tree, with lateral structure added using embedded grids, networks, sequences and other mechanisms.

(7) At run-time, all interaction between Xholons is local, between adjacent entities. There should be no global knowledge. An adjacent Xholon is a parent, child, or sibling, or can be reached through a port.

(8) Start-up and configuration of a computer application is very different from how a biological system works. In the real world biological systems develop rather than starting and configuring. This is the reason why start-up and configuration do not need to adhere as much to these principles.

(9) Change is monotonic. This is basically true of biological systems (see Cell Model sample in which chemical levels change gradually; but also see Extended Cell Model where certain chemical levels in neurons spike suddenly), but it doesn't have to be true of systems with more conventional computational goals. This relates to the use of synchronized time with a scheduler and timesteps.

(10) These systems, and the sub-systems that make them up, are geometric and can be viewed graphically in some geometric way, for example as a tree, network or grid.

(11) Xholons can be active objects, passive objects, containers, or any combination of these three. Active objects are scheduled and do some activity each timestep. Passive objects are acted upon. Containers contain other Xholons.

(12) Architect the system using domain objects. All (or almost all) of the objects in the xml files that configure each of the sample applications are domain objects. The names are taken from the vocabulary of the domain. If the domain is biology then Xholons should have names like Cell, Enzyme, Glucose, and Neuron. If the domain is elevator technology then Xholons should have names like Elevator, Door, Hoist, and Button.

(13) Compartmentalization is necessary. Membrane-bounded compartments constrain the possible interactions between Xholons.

(14) There should be a constant number of Xholons throughout the lifetime of the system. Xholons are converted from one type to another, but conservation dictates that the total "mass" of the system should remain constant. "Matter" and "energy" can be neither created nor destroyed, but only transformed into another form.

(15) Xholons are concurrently and constantly active, or at least potentially active. They are scheduled during timesteps. Some Xholons take acdtions, while others are acted upon.

(16) Xholons interact at binding sites (see Protein Based Neural Netork sample). These are realized through ports.

(17) A Xholon system has a well-defined containment hierarchy at start-up, although this may be changed at run-time by the contained Xholons.

(18) A Xholon system has a well-defined inheritance hierarchy. In certain systems this may be changed at run-time by the contained Xholons. A Xholon may change its class. A new class may be created through emergent local interactions.

(19) The containment and inheritance hierarchies are both trees.

(20) Interactions between nodes of the containment hierarchy form a network or graph.

(21) Any combination of Xholons should be able to execute. Most random combinations won't do anything, but no interactions should be invalid or cause the system to crash.

(22) A basic design decision is to what extent the system will be top-down, and to what extent bottom-up.

(23) Autopoiesis may be an important principle in a Xholon system. Every part of the system is involved with creatin every other part. This has to do with the types of interaction networks that are created.

(24) Genes can be separate Xholons that determine how some of the active objects behave.

(25) Randomness can be used to help structure the system.

(26) other principles from my notebooks

(27)