UHR Generation 2 Guide

Overview

The three essential elements of UHR are Parts, DK and Links.

1. Parts - Systems are assembled from reusable Parts, which are Procedural Knowledge (PK).

2. DK - The behavior of parts is varied in each reuse case by DK (Declarative Knowledge), rather than subclassing, table driven, custom configuration, code generation, etc. The advantage of DK is greater part reuse. DK is the policy a reusable part should follow.

3. Links - Parts collaborate by talking to each other through links, using method calls. A links connects a client "need" to a host "service", using a standard domain neutral inteface. PartA and PartB may be linked, but they never know who the other is. This allows parts to be reused in a wider variety of contexts.

UHR is a technology of effects, principles and mechanisms as expressed in the UHR Technology Grid (web). This is the second generation reference implementation, called "Gen2" for short.

Gen2 has great improvements over Gen1 such as no separate kernel, very customizable core, cleaner architecture, elimination of the many optional command interfaces, elimination of use of reflection, suitability for embedded work, and the use of "attractors" to automatically create links. It is a 100% redesign and rewrite based on the work of Steve Alexander and Jack Harich, plus various other contributors. This implementation does not yet reflect full systhesis with Steve's parallel implementation which is also in progress.

Special Note - Gen2 does not yet have any Visual Tools. So far all we have is the "core".

See Downloads for Generation 2 (web).

Definitions

These are brief. They are in order of comprehension rather than alphabetical. For much more see the UHR Glossary (web) which is not as up to date as the definitions here.

Parts - These definitions deal with parts in general:

Part - An entrypoint to a body of software designed for high reuse. Parts are behavior. Systems are assembled from parts. In Java a part is one or more classes presenting a single class as their entry point.

Container Part - Commonly called a "container". Contains zero or more parts, which can be container and/or leaf parts. A container part cannot contain itself.

Leaf Part - Commonly called a "leaf". Cannot contain other parts.

System Tree - The container and leaf parts that make up an entire system, organized as a tree. The topmost container is the "root". All containers have a parent container except the root container.

Optional Interfaces - To use the UHR framework, a part implements one or more optional interfaces such as ParamDriven, ServiceHost or ServiceClient. Many parts implement all three.

DK - These definitions deal with DK:

DK - DK, short for Declarative Knowledge, declares how a part should behave in a particular reuse case. DK is reuse case policy. We store DK as nested key values in XML. Think of DK as similar to the way HTML is the reuse case policy for a web page part. Part reuse is much higher because parts are designed to behave appropropriately in each reuse case depending on the DK the part is automatically provided when created.

Another way to define DK is "DK is policy. Parts are procedures. DK is thus procedural policy." Or as Ken Ritchie puts it, "Procedure implements policy. Bingo!!!"

Another definition, from David Hecksel, is "DK is configuration information, the information that makes software "resusable" based on data. It's the data (and the structure of that data) that Actions are based on."

Container DK - The type of DK used by containers.

Leaf DK - The type of DK used by leaves. (Called Part DK in the UHR Glossary)

System DK - The total container and leaf DK that describes a complete system.

Flexitron - The data structure that contains a part's DK. Both container and leaf DK is parsed from XML text into a Flexitron. A Flexitron contains nested key values. For example flexitron.getInt("Policies/Timeout") returns 2000, flexitron.isTrue("Policies/ExclusiveUse") returns false and flexitron.getString("Policies/Administrators/Martha/UserID") returns "mharich". A Flexitron is a type of Datatron.

Parameter Driven - The ability to vary behavior in each reuse case by using parameters (aka DK) to determine what to do. A Parameter Driven part receives its DK just fter it is created, and then initializes itself for this particular reuse case. Parameters is a synonym for DK. Parameter Driven parts implement the ParamDriven interface. Parameter Driven is the same as Configurable. or Knowledge Driven.

Links - These definitions deal with Links.

Service - A published group of one or more methods in a fairly domain neutral interface. For example a part may have a Printer service with methods for start and abort. Another part may have a CalculatePaymentPenalty service with a single method. A service can handle multiple needs. Parts with services implement ServiceHost.

Need - A need is a published request for a service. For example a part may need a color Printer service. Parts with needs implement ServiceClient.

Link - A satisfied need is said to be "linked" to a service. All parts need links to collaborate with other parts. Parts do not create the links, they only publish their services and needs, and the UHR framework automatically creates most of the links. Manual links (about 10% of all links) are created from Container DK. This allows parts to be smart about what they need and offer as services, greatly reducing the burden on the develper to hookup parts.

Attractor - Parts publish their services and needs in the form of "attractors". An attractor expresses the desire of things for each other. In the case of UHR if the attraction of two parts is strong enough, they will bond in a manner similar to a molecular bond. Fulfilling an attraction (bonding) is said to "satisfy" the attraction. Not only do attractions allow automatic linking, but they allow automatic "pull in" of parts from a Part Inventory to meet the needs of "seed parts". Thus the system builder can sprinkle a few seed parts in an empty system and "grow" the rest of the system.

Uniface - A uniface is a domain neutral single method interface that allows a service to be published in a highly reusable manner. Here's three examples:

public interface UF_void_String_int {
    public void act(String arg1, int arg2);
}
public interface UF_boolean_String {
    public boolean get(String arg1);
}
public interface UF_void_Flexitron {
    public void act(Flexitron arg1);
}

Unifaces are semantically neutral. All normal interfaces can be reduced to Unifaces, though some will require complex objects in the method signature, and some are best published as Multifaces. The advantage is all parts use a pool of reusable interfaces that shield one part from knowing much about the other. A link is a reference to a Uniface or Multiface. A Multiface is just a sematically neutral interface with multiple methods.

Datatron - A Datatron is a data structure such as nested key values (a tree), ordered values (list) or key values
(map). In some cases a "stream" datatron is used, such as one with read() and write(). Keys are Strings. Values are primitives, Strings or other Datatrons. The third Uniface example uses a Flexitron, which is a type of Datatron. Datatrons and Unifaces preserve Anonymous Collaboration between parts, making the parts far more resuable.

The Essence of Parts

Now that you've read those tedious definitions, here's a diagram showing the most important aspects of parts:

Boom! Firecrackers and lightbulbs should be exploding in front of you right now! :-) Is it true? Are parts a cluster of DK, Services and Needs? Is a system a bunch of parts automatically provided with their DK and links? We think so ...

This diagram is explained in further deail in Lesson 6 - How Parts Work in General.

Summary of UHR

See the website (web) for a full treatment of UHR. In general, read the rest of the website first or if all this isn't clear. Here's a summary:

UHR stands for Ultra High Reuse. UHR is a collection of best practices rolled into a carefully thoughtout framework that allows assembly of systems from reusable parts, which greatly increases productivity. UHR has also been called a "framework for frameworks". This is a small open source project.

The three essential elements of UHR are:

1. Parts - Systems are assembled from highly reusable parts.
2. Declarative Knowledge (DK) - Tells parts what to do in a reuse case.
3. Links - Parts collaborate through links between the needs and services in parts.

The outstanding features of UHR leading to higher productivity are:

Parts

1. Assembly of systems from reusable parts is the norm.
2. Parts are assembled with no code. We use DK instead.
3. Parts are organized in a standard, easily understood hierarchy, the System Tree.
4. Parts can be assembled from parts.
5. Part behavior is varied for each reuse case by DK (Declarative Knowledge).
6. Parts collaborate anonymously with links and Unifaces or Multifaces.
7. Parts are automatically or manually linked up. Manual links are required less than 10% of the time.

System Architecture

1. Editing running systems is the norm. Gone is the wasteful edit, compile, run, stop cycle.
2. The system designer starts with a standard framework, not a blank slate.
3. Totally domain neutral framework. Systems of any kind are possible.
4. Very small core framework, under 100 classes..
5. Self referential system. The framework uses itself to run itself and domain parts, eliminating a separate kernel, and making core design and customization easy.
6. Service architecture is provided via automatic upward lookup of services for linking needs..
7. The architecture allows simple, powerful, intuitive Visual Tools.

Emergent Properties

1. Elimination of a separate kernel due to correct abstraction of part plugpoint structure.
2. Reuse is a byproduct since any container in a System Tree is a reusable part.
3. System customization by end users can become the norm.
4. Systems built by systems becomes practical.
5. Sefl-assemblying systems due to attrractors becomes practical.

Implementation Plan

These are the steps remaining to produce Generation 2:

----- Current -----

1. Fully document Generation 2 core implementaiton.

2. Various small features will be implemented as we go, such as

• Ability to close container and have downward links revoked.
• Ability to do manual links of any kind. Currently we have only 2 kinds supported.
• Complete the many states and commands in Cell Lifecycle.
• Events in StateCommandable subsystem for use by tools or parts.
• Growing a system by automatic "pull in" from Part Inventory for unsatisfied attractors.

------ Visual Tools -----
These are part systems. They begin to build our part inventory.

1. MainMenu, System Tree. No file mgt at first.

2. DK Editor, text style.

3. Inspector.

4. SystemTree file mgt. Tricky.

5. DK Editor look and choose, with DTDs or such. Difficult.

6. Circuit Board diagramming with links, needs, servcies. Difficult.

------ Convert generation 1 systems -----

Various, lots of work to convert data framework