BA Mini Process

Document Status - In progress.

Good heavens, this is gonna be tough! :-) Well, at least we have a roadmap and a first iteration. We will consider only the first four phases of the grid, which are the Reusable Parts Stage of UHR. When we say "user", we mean an end user, power user or developer. For further narrative input to this document, see The Key UHR Behaviors and Key Little Visions. For a description of the BA first iteration, see Bean Assembler. We are not pursuing the Configurator now, maybe later.

To understand this document you need to have played around with the first BA iteration. The Narrative is at a high level, and is incomplete to keep it short and more comprehensible. The Narrative emphasizes the new work needed in the visual tools.

---

Nutshell Vision

Allow users to assemble systems of any kind using parameter driven parts, as fast as they can decide what they want the system to do.

---

Narrative - User Perspective

To create a system, the user starts the BA and tells the Part Shop they want to create a new system. Since BA systems follow the Conceptual Model of the BA, the Part Shop offers some good "base" frameworks to pick from, or allows the user to pick from their own customized framework list. The Part Shop has both parts and plugpoint frameworks. Frameworks are just a dependent collection of parts. We may have a Frame Shop help out here. The Part Shop is internet or intranet based so many users can treat it as a central store. Multiple Part Shops cover different domains.

A System Tree appears with a reasonable default for the chosen framework. A wizard may also appear to walk the user through further steps, or they can summon the wiz anytime. The parts in the tree that need further elaboration for the system to be useful have visual indicators, such as odd colors or icons.

The user selects the part they want to further configure, and the DK Editor for that part type appears. This displays the current tree or diagram of Declarative Knowledge (DK) for that part. If it's a newly added part, a good default appears. The defaults can be customized by the user.

Using the DK Editor, the user rapidly edits the DK in a precise, intuitive, ridiculously easy manner. Most parts use a tree of key values for the DK, not the raw text in the first iteration. We call a DK key value a "datum". A datum is either a container or leaf. The root datum for a part is always a container. Container datums have a "Datum Type" that defines what it may contain. All parts have a single Datum Type, and so our smart little DK Editor knows just what to do all the time. All these technical details are hidden from the user, who thinks and works at a higher level. However this is the conceptual model they use. We may need catchy, more user friendly word than datum, container and leaf. Hey, let's start a contest! :-)

To add a datum the user selects the container to add it to, and then selects from a list of allowable Datums. Poof! A default datum appears in the container. To edit a datum leaf the user selects it and then selects from a list of allowable values or enters some text. To delete a datum the user selects it and indicates delete. Cut, copy, paste and move via Drag and Drop are done just like in any decent GUI tool.

That's how DK is handled. The user can also add, delete, move, cut, copy and paste parts. They can even drop and drag parts from the Part Shop or a customized parts repository of the parts they use a lot, with various customized DK and framework member defaults. Since a part can contain other parts, the user can stash useful system branches and pop'em in right where they're needed in a jiffy. It's all so convenient and works just the way the user wants, because they can stop and customize all the visual tools just as easily as they can customize any system they're building. After all, the visual tools are built from parts themselves, and many of these parts are the same ones the user has been using for their own systems. That the entire visual toolset is infinitely customizable, in the same exact manner as the systems it's building, is a mind blower.... This is the power of Recursive Architecture.

System Tree containers have a different type of DK from leaf parts that is really slightly procedural. This takes a special editor, the Container Editor. A container can optionally have a part, which requires the DK Editor to edit the part.

All changes of any kind are instantly validated. The system always stays in a consistent state. The user never has to worry about doing something wrong. They see the BA as their friend, one that they've customized extensively and formed a deep, long term relationship with.

Once a new system is "runnable", the user can start it and then continue editing it live, or it may start running itself. Editing while running is the normal practice, because it's so much more useful than trying to edit a system that's not running, start it, get to where the change you just made shows up, observe the effect, stop the system, and then start over with another edit. That's nuts!!! Those days are gone for good, thank goodness says every BA user. :-)

Old systems can be "opened", which causes their System Tree to appear. After that, editing an old system is just like editing a new system. An unlimited number of systems can be open at once.

Comments

Note the emphasis of the Nutshell Vision on the user and "what they want the system to do". All complexity such as code, XML, DTD, hard core terminology, framework design, Part Shop location, etc is utterly and completely hidden from users by the visual tools. That is exactly what UHR architecture allows to happen so well and so easily, from the BA designer's point of view.

All the visual tools do is translate "what they want the system to do" into DK. There you have it, the impact of UHR architecture on the BA Design in a single sentence. After all, DK is "what to do" and the parts know "how to do it." You could thus summarize the BA Requirements as "Given the BA kernel and parts, the visual tools translate user gestures into the DK that defines a system."

As you can see, since we already have a reasonable BA kernel, the main challenge is super duper visual tools, built with a fleet of parts. This is a huge, difficult task, because there's lots to do and no one's done it before. But that has never stopped those who don't know it can't be done. (Whoops, a triple negative! :-)

---

Use Case List

These are at a high level. We will drill down, expanding each Use Case into a project of its own. Note that only Use Case 1 is required for running systems. The rest are for evolving systems. We are only listing the most important Use Cases. The rest will be handled later or in the course of handling these.

(1) User Education - Online Help, Tutorials, Documentation, Training, Support Mail Lists, Quick Tours, etc. With good design the visual tools will be intutive and easy to use. They should morph to support different levels of expertise, such as introduction, novice, intermediate and expert users. The better we do this, the less separate User Education is needed for the visual side of the BA. For designing and implementing parts, much User Ed is needed.

---

Traits

1. All elements must map to and support the UHR Technology Grid.

2. All elements must support the principles of Structured Assembly.

3. All elements must support Recursive Architecture, as mentioned above.

4. Ease of Use must be achieved, at a higher level than any similar tools we've seen so far.

5. Kernel performance must be reasonably fast.

6. Whenever possible, architecture should support easy incremental improvements rather than requiring structural ones. This is to more easily support the decentralized Open Source development style, the vast evolution the BA will go through and the philosophy of parts.

7. Support Living Systems, a recent concept that doesn't fit on the UHR Technology Grid.

---

Major Risks

This group of risks are the biggies. Despite the stated resolutions they are not yet resolved, because we have not yet done enough of the work involving these risks to prove resolution.

1. Too unstable to trust. - Resolved by peer review at many steps, good design, parallel testing with implementation, unit tests, integration tests, unstable release bug reports and fixes, defect management and root cause analysis. Be sure the kernel is super stable.

2. Ease of Use will be hard to achieve, especially because we are getting into new UI areas. - This will be hard. Use the standard tricks for designing good UIs: Contextural Modeling (paper mockups used by users to simulate system use), consistentcy standards, widely circulated prototypes, flexible iterations, flexible design, good design and always thinking from the user's viewpoint, not ours. Expect it to take several generations. Design the visual tool architecture to allow whole subsystems to be replaced with better or alternative ones easily. Spend at least twice as much time in design as implementation in the first iteration.

3. Moving too slowly. - Complete documents detailing where we need to go and how to get there. Set up infrastructure for participation. Make it easy, fun and beneficial for people to contribute. Get the Open Source approach rolling with an active list chattering about what people are doing daily. Encourage organizations to have at least one full timer on UHR.

4. Ending up right where the present crop of development tool suites are. - Follow our vision and don't compromise, even if it causes us to move slowly. Good things take time.

---

Minor Risks

This group of risks are minor and fairly resolved.

1. This project doesn't fit the typical Open Source pattern, which is to tackle mature domains where many users who are already using various versions. The BA is brand new and hardly anyone is using it. - (Unresolved) Need to ponder on this one.... Advice?

2. Inflexibility. Cannot handle some domains, hard for users to get it to do what they need. - This seems dependent on quality of framework and part design. The kernel appears very flexible, because it has narrow, domain neutral responsibilties.

3. Too much to do, too few people to do it. - See "Moving too slowly" resolution.

4. Systems run too slow, a common side effect of frameworks. - Continue to allow parts to collaborate via Messages or direct method calls. Do good framework design, optimize where necessary. Keep parts large grained, especially where speed is an issue.

5. Too complex to understand, due to myraid layers of frameworks and wrappers. - We need second opinions here. There may or may not be a problem. It may also be compounded by lack of good visual tools, and will be resolved when they appear.

6. The Message mechanism, while theoretically sound, may be too slow or cause problems. - This doesn't seem to be a large problem, or we would have noticed it already. The only problem we've seen is it's hard to figure out what a Message is causing, who sent it or who is listening. It's also awkward to set up a long Message chain. These problems will clear up when better visual tools appear and we fix a bug in the Inspector for showing a Message chain.

7. Too dependent on Jack. - Get him to continue massive brain dumps into documents. Complete "Moving too slowly" resolution. Get others trained. Involve some high level talent at the BA architectural level. This is in progress and this risk should be resolved in 6 months.

---

See BA Design for the next Mini Process steps.