UHR Generation 2 Guide

11/24/99 - Status is beginning implementation, document under construction - Go Back
Links to the web are used to keep the guide download small.

Overview

UHR is a technology of effects, principles and mechanisms as expressed in the UHR Technology Grid (web). The closest it comes to a product is a reference implementation. This is the second generation of that 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 removal of the MessageRouters from Message senders. 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.

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.

Part - An entrypoint to a body of software designed for high reuse. Systems are assembled from parts.

DK - Declares how a part should behave in a particular reuse case. Short for Declarative Knowledge.

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.

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.

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

Parameter Driven - The ability to vary behavior in each reuse case by using parameters to determine what to do. A parameter driven part receives its Param just after it is created, and then initializes itself for this particular reuse case. Parameters is a synonym for DK.

Datatron - What parts send to each other to collaborate. This allows Anonymous Collaboration. PartA never knows about PartB. Part reuse is much higher because a part can be reused in any context that satisfies the Datatrons a part sends and receives.

Message - A message is a type of datatron. The only difference is it has a name for understanding and routing purposes.

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. Datatrons - Like electrons and electricity, this is what flows between 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.
  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 Datatrons, not methods.

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 framework of core parts, under 50 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 part and message service parts.
  7. The architecture allows simple, powerful, intuitive Visual Tools.

Emergent Properties

  1. Elimination of a separate kernel due to correct abstractions of parts, DK and datatrons.
  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.

Getting Started

(This is not yet possible with Gen2 since the implementation is barely started. The current status is only the Minmal Core version 1 is done, and being redesigned and rewritten for version 2.)

Sample Systems

(later)

Part Inventory

(later)

Implementation Plan

1. Datatron layer. (done, including lightweight XML parser for other layers)

2. Part role layer. (done)

3. Resolve large issues in Circuit Based layer. (done as of 11/24/99)

4. Structure and Lifecycle layer without DK or Messages, Minimal Core.

5. DK layer using XML and simple text files, DK Core.

6. Circuit Based layer, Full Core.

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

Various, lots of work to convert data framework

------ Next are 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.