Narrative

Last Updated September 15, 1999 - Jack Harich - Go Back


The purpose of the narrative is to describe what the system should do in a general way, to prepare for a more detailed analysis in Requirements. In the case of a new generation, the narrative can capture the essence of the existing system, plus strategic considerations for the rewrite. The important thing is to learn as much as possible from the previous generation. Thus this narrative focuses on deep understanding of what we have done and want to do at somewhat of a high level, with forays into design when necessary.


Key Abstractional Strategy

The main value of UHR is the same as the main value for frameworks - Their ability to embody design expertise, and make it available to less skilled developers. Thus our main requirement is "the ability to express the designer's intentions well". This has the subtle implication that no matter who the designer is, they can use UHR to do whatever they want easily, fast, robustly, extendably, etc. If our UHR implementation is good enough, the "designer" can be an architech, programmer, analyst, manager, power user or eventually, an average user. And that is where software is ultimately going....

The main requirement could futher be condensed to "the ability to express intentions well". An old fashioned view of that would be to proceed with a fairly procedural approach. The new fashioned way is to cleve intentions into what and how, ie DK and Parts. This allows intentions to be experessed more flexibly and directly.

We next apply our guiding requirement of "the ability to express intentions well" to both DK and Parts. If DK is to express what to do, it needs to be very flexible, expressive and domain and behavior neutral. A hierarchy of facts, XML and DTD style, does this very well. If a Part is to express how to do things, each Part needs to know when and what to do. A good abstraction for this is Messages between Parts. As to what's inside a Part, we really don't care.

The rest of kernel design flows from the key abstractions of DK, Parts, XML, DTD and Messages.


The Goal of Architecture

In the architecture stage of kernel design, we will be taking tremendous pains to achieve high quality. An excellent source is "Software Architecture in Practice", 1998, from the SEI. Page 17 has process and structural rules of thumb that can be used to check the goodness of an architecture. Page 23 has this definition of architecture:

"The software architecture of a program or computing system is the structure or structures of the system, which comprise software components, the externallly visible properties of those components, and the relationships among them."

We modify this to our working definition of architecture, with elaboration. There's a bit of inspiration from Fred Brooks.

"Architecture is a system's high level structure, which consists of components, their responsibilities and their relationships. Conceptual integrity is the rationale behind an architecture and the user's mental model, and is the most important consideration in system design. The sign of good conceptual integrity is when it changes much slower than a system's architecture, and offers a constant, welcome guide to architecture design and user education. Architecture is never completely stable, but conceptual integrity can be."

And for good measure we invoke the benevolent voice of Fred Brooks. Bolding is by editor.

"I will contend that conceptual integrity is the most important consideration in system design." - MMM, Page 42. "the" is italized in the book.

"By the architecture of a system, I mean the complete and detailed specification of the user interface." - MMM, page 45.

"A clean, elegant programming product must present to each of its users a coherent mental model.... The conceptual integrity of the product, as conceived by the user, is the most important factor in ease of use." - MMM, page 255.


Mental Model

Here's the coherent mental model of a UHR system, as expressed in text:

1. The standard structure for all systems is a tree of containers and parts. A container contains zero or more containers and parts. A part is one or more classes working together. Parts collaborate by sending and receiving messages, which are routed by containers. Parts and containers are initialized by Declarative Knowledge (DK), which declares what the part or container should do in this reuse case.

2. Here's how a system is assembled from parts. Starting with an empty root container, you add parts and/or containers to it. For parts that don't exist yet, you use a "stub part". To hookup the parts, message paths are defined. To define a part or container's particular behavior, its DK is edited. The cool thing is all this can be done while the system is running or not. Parts can be added, removed or replaced while a system is running. Container or part DK can be edited and applied while a system is running. Gone are the code centric days of edit, compile, run, stop, edit complie, run, stop.....

3. Here's how a system runs. When a system is started the root container is started, and then one or more parts in that container are started. Thereafter a running system consists of parts sending and receiving messages. When a message is sent to a container that is not yet started, it is automatically started. Containers can be closed, which automatically causes the closing of all containers and parts in that container. This dynamic nature makes systems more efficient.

4. Here's how a system is deployed. A system physically consists of DK, parts and a kernel, plus the necessary languages and class libraries. DK can be in text files, a database, or anywhere the DK subsystem wants it to be. The kernel serves as the framework the parts run inside of. When a system is started, it's really the kernel that is started and given data on what system to run, which is defined by the root container DK.

5. Ultra high reuse is attained by the use of DK to vary the behavior of parts and containers, by the use of messages so parts are not directly dependent on each other, and by the standard base architecture offered by the system tree, message interfaces, DK interfaces, and kernel interfaces.

6. Visual tools are used to quickly assemble a system from parts using DK, understand a system, find parts, edit DK, check for integrity, monitor a running system, etc. Everything a visual tool can do with system definition can be done by hand editing of DK, but this is much easier with tools.

Here's the coherent mental model of a UHR system, as expressed visually: