Created 4/23/99 - Last Updated 6/20/99 - Jack Harich - Go Back
Here we include only the more important 56 terms, aka concepts. In the definitions, "user" and "developer" are often used interchangably, since one goal is to let either evolve their own systems. As you read, notice the subtle mindset....
This glossary goes beyond mere definitions to briefly discuss how concepts really work, in the context of UHR, the BA and advanced software development. If you find yourself bogging down in all this theory, engage in some practice by running the BA, editing some DK, looking under the covers, adding some parts, creating some parts, creating systems from scratch, creating Plugpoint Frameworks and systems using them, etc.
"If you wish to talk to me, first define your terms." - Voltaire
(supplied by Paul Tod Rieger)
Acquire Message - A type of Message where the sender wants to "acquire" something. Examples are whether some data is valid, or getting data from a server. The Use Case is:
This is all very clean, but does require extra code. In normal programming, acquisition is done with methods. Here's how this would look in code in the part sending the Message:
Message message = new Message("AcquireSchema"); message.set("DatabaseName", "DB700"); messageRouter.fire(message, this); Schema schema = (Schema)message.get("Schema");
Anonymous Collaboration - Two or more parts using each other without knowing about the other. For example, if PartA wants PartB to do something, PartA can send a Message to a MessageRouter, which sends it to PartB. Another example is a Mediator creating parts and configuring them. Anonymous Collaboration greatly reduces part dependencies, and is one of the principles of Structured Assembly. In the BA it's achieved via the Message Subsystem and containers. See more.
Architecture - The topmost partitions and relationships in a system and its significant subsystems, along with the rationale behind that design, preferably as the result of careful planning. For example, it was popular at one point in OOAD to partition most systems into the standard architecture of User Interface, Business Logic, Persistence and InterSystem, with the first three layered and all three using InterSystem. This is a very sound starting point for those new to architecture.
Architecture is the backbone of system design. It requires good abstraction and modeling skills. It is enhanced by deep and continuous study of the literature and products. As OO guru Grady Booch says, "Software should be architecture driven." and "With regard to architecture, the first question to ask is simply, 'Is there a defined architecture?' "
BA - Acronym for the Bean Assembler. These days "PA" for Part Assembler would be better, since it turned out we did not use the Java bean concept much at all.
Bean Assembler - Also known as the "BA", this is the reference implementation of UHR. The BA consists of two partitions, the Microkernel and Visual Tools. The BA allows users or developers to rapidly create and modify systems of any kind by assemblying parts. See more or the BA Conceptual Model.
CBD - Acronym for Component Based Development. These are very large sophisticated Plugpoint Frameworks for component reuse. The main CBD choices are CORBA, COM, EJB and Jini. See UHR versus others. The main differences between UHR and CBD are:
Classical OO - Describes the tendency to use mostly OOAD, particularly lots of Class Diagrams, when building software, and not thinking at higher levels. You tend to have a warm and fuzzy that you're doing architecture, but you're really not. OOAD is the current accepted Best Practice for the main way to approach software development. It is hard to learn, and fails to "take" at about 50% of the organizations that try. It is slowly yielding to Part Centric, but we expect this to speed up soon.
Commando - A humorous but accurate name for a type of plugpoint part that can perform a single command and that's all. A commando is a "fully normalized part" since all of it is exercised whenever it is called, and so cohesion cannot be increased further. It has a single, narrow responsibility. It is the extreme of the rule that, "A class does one thing and does it well".
We include Commando here not because it's a UHR term, but because it's such a good example of what can be done with UHR. Commandos are used in the jcon Modular Screen Subsystem (MSS), which allows creating an entire User Interface with no code, even all the dynamic behavior. The key trick is to use DK to define what to do when a "screen" part receives certain Messages. The DK is a series of "commands" that are each sent to Commandos to do the work. The Commandos are small, quiet, secretive and hidden away somewhere in the mountains, whoops, the system. :-) They never know where the command requests come from, and the UI parts never know who does the work. It's all a sneaky cloak and dagger operation that was fun to design and build, and works well.
As a bonus, the jcon AutoTest subsystem can run automatic tests on MSS using DK for test definition. When running it looks like an invisible person is clicking the mouse and entering keyboard data. The Commandos have no idea that the Messages they are receiving do not come from a live user. Commandos made AutoTest easy to design.
Concept - Any knowledge that can be applied to significantly govern a system's behavior. Principles, mechanisms and inspirational slogans are examples, but principles are a higher level concept. The higher level a concept is, the more powerful it it. Extremely high level concepts are known as abstractions or strategy. A fact such as "Granite is heavy" is data, not a concept.
Conceptual Integrity - When high level concepts are combined into a greater whole, they form a certain invisible brainstuff that Fred Brooks calls "Conceptual Integrity". In his classic 1975 book The Mythical Man Month he says, "I will contend that conceptual integrity is the most important consideration in system design." (italics are his)
Conceptual Integrity cannot be completely captured, even in all of a system's code and artifacts. It remains in the minds of its creators, and they must be present at various points in a system's lifecycle. This is why Microsoft organizes projects into Program Manager (responsible for Conceptual Integrity of the software) and Project Manager (responsible for successful completion of the project). If the two are combined the first invariably gets short changed.
For example the best films are made by strong directors. They are the Program Manager and the producer is the Project Manager.
UHR is an "Architecture of Concepts", which together form a guiding backbone of Conceptual Integrity. This is somewhat captured in the Microkernel, and less so in the Visual Tools, Plugpoint Frameworks, Parts and documentation. For the elusive spark of "UHR Conceptual Integrity" to be transmitted to an organization or individual learnng UHR, personal commitment and serious study is required.
Good UHR frameworks and their parts must also have conceptual integrity.
Configurability - Configurability is that quality allowing system behavior to be varied by a small amount of user input. In practice, this involves the user editing a part's DK to "configure" the part for reuse. For example, for a DatabaseFacade part the user might provide the DatabaseType, URL, UserID, Password, SecurityPolicy and Schema location. The part would figure out everything else. Configurability is part of Structured Assembly. In the BA parts can be configured while the system is running or not, a tremendous feature. See more.
Container - A container contains a collection of parts. Since a part can be a container part or leaf part, this allows a system to be organized as a tree of parts. System trees are the main reason for using containers.
The system root container is automatically started when a system is started. Other containers are automatically started when they first receive a Message or request. Containers can also be started or closed directly by parts. When a container is closed it automatically closes all its child parts. In this manner even a large system can be incrementally managed transparently. Various branches can start and close dynamically, so that the system starts fast and does not hog too much memory or other resources.
Continuous Evolution - The ability to evolve a system while it's running, instead of the edit, compile, run and stop cycle. You are in one mode continuously. Gone is the old fashioned design/runtime dichotomy. This does wonders for productivity, since you can make changes when and where needed, and then keep right on rolling. This keeps one in a higher mental "State of Flow". Continuous Evolution is one of the principles of Structured Assembly. See more.
As project managers, how do we keep track of the variability we are introducing to the system and the effect of all this fluid change on what the system is supposed to do? This will be addressed in phase 3 of the UHR Technology Grid.
Data - Since we have introduced the concept of Declarative Knowledge (DK), we need to precisely define data to avoid ambiguity in systems that have DK and data. DK versus data is confusing because DK is intuitively a type of data. There are really 3 concepts involved, which are confusing if only 2 words are used, as in the left side of the below diagram. Therefore we introduce the higher level concept of Knowledge, which has two subtypes: Declarative and Transactional, as shown in the right side of the diagram. When we say "data", we usually mean "Transactional Data".
Comments - Declarative Knowledge declares intended behavior. Transactional Data is what behavior operates upon, and is what you typically find in a database. If you start storing your DK there, it's still DK because that's what it's used for. Init files or database settings for table driven software are DK. A Datatron is a Knowledge carrier, but for brevity we don't call it a Knowledgetron. "Data" in the context of a Datatron means Knowledge in theory, but in practice usually means Transactional Data. If you need to be precise and concise, use the terms KData, DData or DK, and TData. DData and TData are stored and transported as plain ole KData. It's not until they are used that they become DData or TData, so these definitions are contextual. When you design a UHR framework you are dividing an application (KData) into DData and TData.
Datatron - A Datatron is similar to the concept and word "Electron". In electronics, devices (Parts) are laid out on a circuit board (System Tree) and connected with wires (Message Links). The devices communicate with only one thing, electrons (Datatrons). It's not a perfect analogy, but it's a useful one.
A Datatron contains a standard data structrure, such as a tree, list, stream, set or row set. A small number of types of datatrons can handle most system's needs. By designing systems so that the reusable parts collaborate only with Datatrons, ultra loose coupling is enhanced and the parts (and systems assembled from parts) become far more reusable.
Parts pass Messages back and forth to communicate. A Message is a type of Datatron, so really parts communicate using datatrons.
A Datatron can contain primitives, Strings or other Datatrons. It should not contain custom Objects. We do foresee some frameworks needing Datatrons with custom Objects for optimization, clarity and such, and these would be an exception. A better way would be a whole new abstraction we can add to the UHR Technology Grid. If we're passing objects around, we're probably not doing things in the best way.
Datatrons have no domain specific behavior, and are just pure data carriers. They can have events, and so can serve as a model. They can validate mutations, and thus guarantee self consistency.
"Datatron" is a concept, not an interface. We have not yet exhaustively explored this area and provided the definitive data structures to use. This may use Collections. This is an open BA project. Meanwhile, we are trying to stick to a few jcon classes like PropMap (a Hashtable) and Param (a tree).
Declarative Knowledge - Also known as "DK", this is a way to separate what a part is to do from how it does it. DK can be hard to grasp and is easy to confuse with data, especially since DK is stored as Strings. How do you tell data and DK apart? When data is used to control a part's behavior, it's DK. All systems can be partitioned into behavior, DK and data. This is shown in the following small system: (supplied by Michael Ivey)
Behavior - Sort fruit into baskets.
DK - Apples go in the red basket, oranges in green.
Data - We have 3 apples and 4 oranges.DK can be designed many ways. One way for this example is::
SortRules hasElements: Element has: Type is: Apple Destination is: RedBasket End: Element Element has: Type is: Orange Destination is: GreenBasket End: Element End: FruitToSortDK is the medium used to declare a user's intentions, and the part is a black box that does it. DK is pure knowledge that controls behavior, not to be confused with data. DK is also how parts are reused, instead of with new code. DK is one of the largest and most important improvements entering widespread use in software today. HTML and XML are forms of DK, which is just nested key values. See Parameter Driven Parts and Parameter Examples.
DK controls a reusable part's variable behavior, while data is what to perform an operation on. The exact definitions of these are fuzzy and can overlap. You define them when you decide how to partition a system. Thus how you use Strings determines whether they are DK or data. Very small systems don't need DK, they get by with just data and behavior.
How do DK designers think? If two things have similar behavior in a system, the differences can be "pulled out", and that's your DK.
DK - Impressive acronym for Declarative Knowledge.
DK Editor - Short for "Declarative Knowledge Editor". It's a Visual Tool that lets the user easily edit their intentions of what a part should do. Also called the Parameter Editor.
In the first iteration of the BA this is done by raw text with nested key values, using a home grown format. In the second iteration we expect to use a tree for the nested key values, with ease-of-use features like Look and Choose, Validatiion, Drag and Drop and sophisticated defaults, using XML with DTDs for the underlying mechanism.
Parts can have custom DK Editors, such as for GUI widget arrangement, schema definition, modular screen construction, screen behavior definition with Commandos, failure recovery rules, etc.
Domain Neutral - Implies that something has ignorance of any other domain beyond its own very focused responsibilities. This is a subtle concept. The more Domain Neutral a body of software is, the more loosly coupled it is to other domains, and so the more reusable that software is. The BA Microkernel is Domain Neutral. This is a key UHR concept.
Hierarchical Composition - Systems are best internally and externally organized as a hierarchy of parts, such as in the BA. The user "composes" BA systems by arranging and configuring parts in the System Tree, always working in an easily understood, rapidly navigated hierarchy of parts. A part may be a container or leaf. Hierarchical Composition is one of the principles of Structured Assembly. See more.
High Cohesion - Cohesion is a measure of how related the functions performed by a software component are. High Cohesion means the functions exposed by a component are highly related. High Cohesion increases reuse and lowers defects. Parts are the logical consequence of pushing High Cohesion to its limit, and is how UHR accomplishes High Cohesion. In the context of UHR, High Cohesion means "A part does one thing and does it well." See Best Practices - High Cohesion.
High Quality Parts - If you want high reuse, your parts must be extra high quality, because they are reused so many times in so many different systems by so many different users. Most parts work within Plugpoint Frameworks, which are very hard to design. Thus building High Quality Parts is not easy. We expect most parts and frameworks to be provided by third party virtual Part Shops in very large volume at very low cost over the Internet. High Quality Components is one of the principles of Structured Assembly. See more.
Inspector - A Visual Tool that lets you "inspect" a part's Messages, Properties and Methods. You can see a list of all Message interests and signals (Messages sent), the Message Chain for each Message signal, the defined properties in each Message signal, values for each part Property, and all public methods. You can "drill down" into any non-primitive Property and open an Inspector on it, allowing you to explore a live system. Multiple Inspectors can be open. You can enter arguments and invoke any public method, allowing you to manipulate a part while the system is running in a variety of useful ways. For example you can change property values to see behavior differences, start the part, run unit tests, change test values, etc. It's a very powerful tool.
Layered Architecture - See Best Practices - Layered Architecture.
Loose Coupling - Coupling is a measure of how interrelated two software components are. Loose Coupling means changes to one componet tend not to affect others, which is good. It also means if Part A doesn't know about Part B directly, then they can be reused independently. The less parts know about each other, the more loosely coupled they are. Loose Coupling increases reuse and lowers defects. Anonymous Collaboration is the logical consequence of pushing Loose Coupling to its limit, and is how UHR accomplishes Loose Coupling. See more.
The key abstraction to prevent tight coupling is to do two things: Have a Mediator manage part life cycles, and use Datatrons for part collaboration. This partitions system elements into 3 areas: Mediator, Parts and Datatrons. Take a minute to visualize a Mediator managing a gardenful of blossoming Parts, with honeybee and pollen Datatrons flying back and forth between them.... (Hey, is that light bulb on yet? :-)
Mediator - Something that reduces problems between two or more parties. In the case of software, this means providing system infrastructure for the "Mediator Pattern". This pattern was popularized by the Design Patterns book in 1995. The book's excellent definition of the Mediator Pattern is:
"Mediator - Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently."
As you can see, the BA Microkernel is just a highly reusable Mediator. The Mediator Pattern is one of the principles in the Part Centric phase of the UHR Technology Grid.
Message - Parts collaborate by passing Messages back and forth. For example a Message may indicate that the user has just selected a file to open, or that a String needs to be validated. Messages travel from MessageSource to MessageRouter to MessageListeners, after which the MessageSource can optionally get data out of the Message if it was an Acquire Message. Logical types of Messages are, in order of probable complexity with simplest first:
The designer should always seek to minimize system complexity. Thus in well designed systems events predominate and there are few commands. Even if your intent is a command, it should be designed as an event. Messages make implementing events easier than falling off a log....
A Message is a Datatron. The only difference is a Message has a name, which serves as a unique identifier. Message delivery is synchronous.
Message Chain - The actual path a Message follows to go from source to listeners. Each source/listener pair is a Message Link. A Message Chain fulfills Message Links. Typically a Message starts out at a MessageSource part, travels through containers, and "fans out" as it's multicast to several parts in the same area of the System Tree. Or it may not fan out at all, and go to only one part. A part's Message Chains may be viewed with the Inspector, allowing you to better conceptualize the Message structure of a system, which corresponds with the central nervous system of animals. Understanding Message structure is extremely important in understanding how System Trees work.
Message Link - The dependency between two parts, where one part sends the Message and the other part receives it. The first is the Message Source, and the second is the Message Listener. There can be zero, one or more listeners for a BA Message, which is called multicasting. Message Links are created in step 1 of the MessageRouter Use Case.
Message Listener - A part that implements the MessageListener interface. It is "listening" for Messages from anywhere corresponding to its MessageLinks, as defined in Container.parex files. A listener only receives those Messages.
Message Router - This is used by MessageSources to send Messages to MessageListeners, using the following plumbing: Containers implement both MessageSource and MessageRouter. Parts can optionally implement MessageSource and/or MessageRouter. Each MessageSource has a MessageRouter. This allows Messages from any part in the tree to be routed to any other part. If the source and listener are in the same container, the routing is from part to part. If in different containers, the routing is from part to container(s) to part. The Use Case is:
Containers cannot create Messages and are never their final destination. They only forward them.
This is the BA first iteration Use Case. In the second iteration, we expect to introduce custom MessageRouters per container, to allow transparent location and other custom behavior per container.
Message Source - A part that implements the MessageSource interface. Sources send Messages to a MessageRouter, not directly to listeners.
Message Subsystem - The BA Microkernel uses several reusable subsystems. One is the Message Subsystem, responsible for allowing parts in container trees to easily establish Message Links and send Messages. The subsystem contains interfaces and classes. The most important are the MessageListener interface, the MessageSource interface and the Message class. This subsystem accomplishes Anonymous Collaboration, which allows independent part reuse, which is a very, very merry Good Thing. :-)
Microkernel - A concept using a very small "kernel" as the lowest layer in a Layered Architecture upon which systems are built. "Micro" means the kernel is doing the absolute minimum amount of work, and the rest of the work is done by upper layers. This encourages simplicity, domain neutrality, small size, extensibility and robustness. There is a slight tradeoff in speed, which is not seen as a problem due to the relentless improvements in hardware performance.
The BA Microkernel is responsible for reading a system definition expressed with DK and an entry point marker class, part life cycle management, part configuration, providing parts with their DK, sending Messages and providing a loosly coupled interface to visual tools. Please note the kernel has no idea at all about user interfaces, persistence, networks, transactions, etc. It does as little as possible. All other behavior is done by parts. The kernel is a great example of "Less is More".
The Microkernel was formerly called the System Engine. See the model.
OOAD - Acronym for Object Oriented Analysis and Design, but has expanded to also include Implementation. Characterized by the use of Objects to capture the Design, followed by the use of an Object Oriented language to implement those Objects. Uses Use Cases to drive the Analysis and all futher phases. Uses modeling very heavily in the Design phase to plan how Use Cases will be implemented. Uses iterative development throughout and/or in the Implementation phase. Requires a process such as the Mini Process to do well repeatedly. Done well, OOAD is very, very productive.
There is a danger in techie types focusing too much on getting the OOAD process, Use Cases and Models just right, and not being aware of thinking at higher or other levels, such as Frameworks, Part Centric or UHR. Being stuck at just the OOAD level is humorously called Classical OO, because it's like being stuck in the Classical Age of Music.
OOAD is so hard to learn we recommend to Hiring Managers that they hire only those who have already "got it", and have at least made the basic mental transition. This can easily be determined by examining their Use Case and Modeling skills. For example, Michael Ivey starts with, "What's your favorite modeler?" There's no right answer, just whether they know how to use one.
OOAD is slowly yielding to CBD. But that is the problem - We need to skip a generation. We need to move straight to UHR, not OOAD to CBD to UHR.
OOAD also tends to be more useful to architects and engineers at the expense of customers. For a better way, see Mini Process 2.
Param - Short for "Parameter", a Param is an object containing DK. Params are used to pass DK from storage to parts. Thus parts internally use Param a lot. A Param is a treelike data structure of nested key values, and is a type of Datatron.
Parameter Driven - Parameters are property values. When Parameters are used to drive a part or system's behavior, it is Parameter Driven, one of the principles of Structured Assembly. Parameters are better called Declarative Knowledge. See more.
Parameters - Another name for Declarative Knowledge. This was the first name we used for this concept, while all this was young. "Parameters" imples a set of values, while "DK" implies intent, which is better.
Param Subsystem - The BA Microkernel uses several reusable subsystems. One is the Param Subsystem, responsible for reading and writing Param objects. The kernel uses a default Param Subsystem, or you can provide your own. The kernel knows only about the Param Subsystem and Param objects. It has no idea how they are stored or retreived. The subsystem has interfaces and classes. The most important are the ParamDriven interface, the ParamStore interface and the Param class. The Use Case for parts to get their Param is:
- The part implements the ParamDriven interface.
- The part is created by its container.
- The container uses a ParamStore to get the part's Param.
- The container calls setParam(Param) on the part.
- The part uses the Param to initialize itself anyway it wants.
Part - A part is a reusable black box used in assembling systems from parts. Doing this makes one "Part Centric" instead of code or object centric, a huge productivity gain. A part may be a leaf part or container part. The former cannot hold other parts while the latter can. Most parts have a "packet" of Declarative Knowledge (DK, aka parameters) that is used to initialize them. This way we get reuse via DK, not code. This concept, Parameter Driven Parts, is the most important concept in UHR.
In system assembly, the user select a Part from the Part Shop, drops it into a Container, and then configures the Container and Part to get the Part to behave as desired. Parts typically communicate via Messages. Parts usually are part of a Plugpoint Framework. Parts or frameworks are usually organized in a Layered Architecture with base Parts at the bottom and app specific ones at the top, with additional layers such as domain and service in between. Enterprises can organize their Parts by describing their preferred organization to the Part Shop, which is then enforced when Parts are assembled from other Parts. (Future features in the last sentence)
Encapsulating reusable behavior into parts allows the designer to easily borrow from other fields. For example, looking at Biology, we can use "Self Healing" parts or "Medic" parts to respond to a part's call of "Help me, I'm broken".
We use the term Part rather than Component because it's shorter and less trendy.
Part Centric - An attitude or design that is very centered around parts. The popular alternatives are code centric (aka procedural) or Object centric (lots of OOAD for every new project). Not only must your software be Part Centric, but so must your organization. Otherwise you absolutely cannot use UHR to it's fullest extent. For example you must separate Part Assembly from Part Creation, assemble teams on-the-fly like parts and market a build-from-parts solution. This is a large surprise for most.
Part Shop - A place where the user goes to get parts. This plays a key role in system assembly, and was one of the biggest new abstractions in the UHR Technology Grid. The Part Shop is a future Visual Tool. See Key Little Visions - Part Shop.
Plugpoint - A point in a Plugpoint Framework where you plug parts or DK in. When many different parts plug into the same plugpoint, they are often not very configurable and not widely reused. When DK is used for plugpoints reuse is much higher.
Plugpoint Framework - Reusable software infrastructure, with some behavior fixed, and some behavior provided at various "plugpoints". Plugpoint Frameworks are very hard to design well. They are the only way to produce large systems from reusable code efficiently. See Best Practices - Plugpoint Framework.
Plugpoint Policy Pattern - In well designed highly reusable systems, you can allow the user to vary some behavorial features by providing the policy or part to use for such features. This is done by various predefined plugpoints for the different policy areas. An advantage is the designer no longer has to decide between feature A or B - They can offer either.
For example, in the BA Microkernel the Containers have default policies such as MessageRouter, ContainerServices, and MessageServices. If you need to transparently have parts start sending Messages to a remote container instead of the local one, or need a security filter or internationalization translator on all Messages to a container, you can provide a custom MessageRouter.
Policy Part - A type of part that decides what to do on request, and that's all. It is used for reference by other types of Parts to decide what to do in a centralized manner. It may optionally do some things itself. This allows the designer to isolate all business rules of a policy nature At first, in UHR Grid phase 4, the Policy Part does it with code. Later, in phase 5, it will do it with Configurable Logic. This is a deliberate bridge from stage 4 to 5. We already have some of this figured out, as shown in the Modular Screen and AutoTest subsystems. Thus you can use Configurable Logic type Policy Parts today in some cases. See more.
Relationship - In the BA this means one part has another part. A Relationship is a type of dependency. A Relationship doesn't mean a part has an indirect dependency on another part, such as Message sources and listeners. Relationships are optional, because everything they do can be done with Messages, though this may take more work. Relationships are tight coupling, which reduces reuse and extensibility. Relationships are usually defined by a container's DK, and are established when a container is started. They can also be done by use of ConatinerServices and Acquire Messages. The BA is flexible, and allows the designer to use or not use relationships.
Reuse - Reuse is the practice of building something once but using it many times. While this has been sought for years in software, progress has been slow. Extensiblity is a type of reuse. UHR is a carefully planned approach to maximizing reuse of all kinds, such as parts, user intentions, user training, organization, Visual Tools and entire systems via end user customization. Reuse is variability without new code. See more.
Structured Assembly - This is a large theory that provides the foundational principles for system assembly from components. These are:
System Tree - This BA Visual Tool shows a system assembled from parts in a hierarchical tree. The user can easily visualize how the system is constructed, navigate easily to any part, and use tools such as the DK Editor to edit a part. See more.
UHR - Cool acronym for Ultra High Reuse. It sounds suspiciously like "er", "uh" or UFO :-)
UHR Technology Grid - A 5 to 10 year phased architectural plan for UHR. This concept is so large, new, complex and full of risk it needed a novel expression, hence the large grid. See more.
Ultra High Reuse - A handy catchall name for an "Architecture of Concepts" that use a single guiding practice, reuse, to achieve large increases in software productivity. Usually called "UHR". In general, the higher reuse is, the higher productivity is. UHR can be learned fast if you have no bad habits to unlearn, such as procedural or being too Classical OO. It helps if you're good with abstractions, have experience developing Plugpoint Frameworks, and have an open mind. See more.
An interesting case is, "Gee, this is a small system. I can do this in Perl." The problem is as the system grows in size, as they usually do, reuse is difficult and the system becomes one big mess. Procedural languages are not scalable.
Another case is, "Gee, this is a medium size system. I can do this with OOAD, third party subsystems, and Java or C++." Again we have a scalability problem. As the system becomes large, reuse is difficult because the design addressed only domain issues, not reuse issues. Systems without infrastructure that enhances reuse are not scalable.
In both cases if you know a system won't grow much or is just a first iteration to be followed by a rewite, then scalability is not required.
Use Case - A Use Case is a series of steps an actor performs on a system to achieve a goal. Actors are "objects" of any type, such as people, parts or other systems. Use Cases are a pillar of OOAD and are indespensible in modern software development. See more.
Visual Tool - Anything that allows the user to visually do something, such as edit a part. This is opposed to Command Line Tools, where the screen is of limited use and the mouse is of no use. Visual Tools tend to be much easier to learn and use than Command Line Tools for most users. In the case of UHR, the main Visual Tools are the System Tree, DK Editor, Inspector and Part Shop.
XML - Acronym for Extendable Markup Language. This is a standard specification for text documents using a "markup language" format. It's main feature is user definable tags, unlike HTML. Industry sees it mostly as a better HTML. Some see it as useful for standardized data in general. We see it as the first universal structured data standard, which makes it ideal for storing and transporting Declarative Knowledge. Part of the spec defines Document Type Definitions (DTD), which are a meta markup language for defining (among other things) what is allowed in an XML document. This is ideal for DK Editor Look and Choose, defaults and validation.