Kernel 2 Project

10/6/999 - Jack Harich - Go Back

Nutshell Vision

Create a second generation UHR microkernel, using the lessons learned from the BA. It should be so good it lasts at least 2 years before replacement, with Parts good for 3 years or more and DK good for 5 years or more.

"The significant problems we face cannot be solved by the same level of thinking that created them." - Albert Einstein

Project Summary

Status - The project is in the early high level phase. Jack and Steve are currently each independently pursuing a high level analysis and design. This encourages independent discovery, and increases the chances of super high quality results. They will combine their work in a wonderful synthesis. A suprising early result is elimination of the kernel by turning it into parts running in the same System Tree it's managing! Wow!

Timeline - This project is due at EOY 1999, which is in 4 months. We are considering the first month for early work, 2 months for actual building of a complete kernel, and 1 month for polish and testing by building Sample Systems. A possible schedule problem is the holiday season in late December.

Deliverables - We expect these to be:

  1. Java source code and complied classes for "core" software
  2. JavaDoc for all source code
  3. Documentation for how to use the core to create good systems.
  4. Sample systems, which should include many reusable parts.

In particular, nothing important should be undocumented, such as Container DK, Part DK, how to build a system from scratch, how the Param subsystem works, how the Message subsystem works, and how to design a good part inventory.

Document Status

In progress, not yet combined with Steve Alexander's work to achieve a wonderful synthesis. We may add a Revision History section. Please note these documents are a little wild and imcomplete, since emphasis is on rapid exploration of new conceptual territory.

Project Considerations

We expect considerable reuse from the current BA, such as the Param and Message subsystems.

The Requirements are the most crucial artifact, because they drive and are used to validate much of the following steps. We will take lots of care to do them well and validate them.

We expect several iterations in the Design stage. Each iteration will be validated by Uses Cases and other Requirements.

  1. Architecture Exploration, where Jack and Steve independently do high level kernel2 beginnings.
  2. The second may be Candidate Architectures. Here we generate potential architectures, evaluate them with a defined procedure including Key Use Cases and Prototypes, and select one.
  3. The third may be Interface Modeling, which completely describes the interface based solution. Much of this may happen in the prorptype.

We have not yet identified optional Requirements that could be postponed if we develop schedule trouble. Having about 25% of these is a good schedule managment practice.

Mini Process 2 is used on this project, with a possibility of some Unified Process if needed.

Staff is Steve and Jack. Their availability is 80% and 50% for this project.

Narrative

Here's a narrative describing what the system should do, with considerations.

Perceived Value Goal Setting

Objectives

  1. Pinpoint the most important things leading to customer satisfaction. (80/20 rule)
  2. Avoid doing the wrong things right. Do the key right things well !!!

Key Values

  1. Ease of learning.
  2. Ease of use.
  3. Ease of modifyability (of kernel itself).
  4. Ease and amount of reuse. (DK, Parts, Branches, Systems, skills, etc)
  5. Power of expression (can handle any functionality elegantly)
  6. Reliability.

These are "surface" values. They lead to the additional values are low cost of production and fast cycle time. We are careful to discriminate between what we want to achieve (reliability, low cost and short cycles) and what values drive achieving them. Iexcept for reliability) It's interesting to observe that only values 4 and 5 are non-generic.

Not included are performance, security, portability, resource requirements, standards, mechanisms, many details, etc. These are the 80% of the values that give 20% of the benefits.

Key Low Level Improvements to the existing BA kernel are:

  1. Go with interface based on everything that's kernel related.
  2. Allow discrete kernel behavior to be varied per container.
  3. Put part MessageRouters in their containers. Get them out of parts.
  4. Change BeanAction interfaces to Messages.
  5. Remove unnecessary package dependencies, such as awt.
  6. Remove ObjectService.
  7. Remove ContainerServicesUser, send to MessageService with container DK.
  8. Fully document Container and Part DK.
  9. Make use of reflection optional.
  10. Get minimal kernel small for embedded use.

Use Cases

See Use Cases, which has an interesting diagram for different types of actors.

High Level Architecture

Ahhhh, here we have some interesting Explorations of High Level Architecture. The method usePart() in the Start System Use Case was a wild departure. This idea lead to the sudden idea of making the kernel out of parts and starting the system in a similar way. See Self Referential Tree which has Prototype One to prove the new concept can work.

To be sure we achieve a good architecture, we have taken the time to consider how best to do that. This is described in Achieving Architecture Goodness.

After this prototype we moved into:

Candidate Architecture 1 - This was based on what we learned from the prototype.

Candidate Architecture 2 - This improved on number one and begin synthesis with Steve's work.

Candidate Architecture 3 - This uses the "Core Variations" idea discussed in Business Considerations.

Then we did Prototype2. This was the lower two layers of Candidate Architecture 4.

Candidate Architecture 4 - This built upon Prototype 2 and further synthesized some of Steve's ideas.

After a particularly inspiring telephone call with Steve, we drew up Generation 2 Philosophy. This is yet another summation of UHR, but is designed to pinpoint what we need to consider most as we move toward final high level design of Generation 2.

Candidate Architecture 5 - This looks at UHR as a whole, partitions it, and seeks to define the inter-partition interfaces in a flexible, stable manner.

Candidate Architecture 6 - This is the document style we might use in synthesis.

Risk Management

Probably our top risk is UHR fails to be adopted much at all by businesses. See Business Considerations.

(more to be done)

(Other Mini Process 2 sections to be done)

(to be continued)