December 6, 1998 - Jack Harich - Go Back
Nutshell Vision - Allow users and developers to easily assemble systems from parts.
Part Assembly Narrative
First the user partitions the system into containers. Then they establish the relationships between the containers. Then they select and drop "smart parts" into the containers. When the parts are dropped they automatically come to life and hook themselves up to the system. If they have problems they complain to the user, describing their problems. The user can then remove the part, alter the system or alter the part to fix the problems. Since assembly is self checking, the system is always in a state of integrity.
The parts can be configured before or after they are added to the system. Preconfiguration (before add) allows the part to be smarter about its behavior and hookup. Postconfiguration (after add) is useful for fine tuning and evolving system behavior. Parts in the "part shop" can be preconfigured so they are ready for use in a particular system or container type, or by a certain user. The part shop can also have plugpoint frameworks, role patterns and other prebuilt groups of parts.
As the system grows it becomes a challange to understand it. The user would be able to select a part and see collaborations, ie what other parts or containers it collaborates with. They could navigate through the system by drilling down into containers and returning. They could zoom and unzoom the view of the system. They could hide and show certain types of parts and relationships using filters, or selectively hide and show them. They could see what part properties were different from the defaults or standard preconfiguration, ie non-standard values. While the system is running they can see the flow of control and collaborations. Since the norm is editing a live system, this feature is important.
Under the Covers
A smart part knows how to hookup to the system and set its own properties by using its container context. This is called autohookup. It consists of establishing relationships and finding property values based on needs, and other types of initialization. If the part knows these needs it can do it all itself. If not, the part must tell the user what properties and relationships need setting.
To make automatic hookup work, the containers offer a Provider Service, aka Trader, Naming or Registry. Given a Need, the Provider can find a part to fill that need. For example a Smart Part may need a storage part that can count rows for users in the admin database. The Need would contain Role = Storage, Function = CountRows, Area = Admin, Entity = SystemUser, ie the "logical service needed information". This would be enough for the Provider to find a part implemeting the Storage interface that could handle the need, assuming the part had already been registered.
Containers can be configured to various patterns, such as Layered Architecture or Services Architecture. For example a container serving as a layer would configure its Provider to first check other parts in the container, and then those parts in the lower layer. If services were available then the container would configure its Provider to next check the services container.
Containers are just another type of part. A system is just the outer container. Systems are built from subsystems, ie nested containers are used to build systems. A container can optionally have a custom class and custom parameters, in addition to the mediator style parameters that create and set relationships for the parts in a container.
Autohookup, aka autoconfiguration, would be like building a house with the materials doing most of the work. You would mark out the footing, throw some Smart Concrete at it, and it would dig the slab and footing, mix itself, find the rebar and put that in, and pour itself. Then you would mark where the doors are, throw some Smart Sill Plates at the slab, and they would cut themselves to length and attach themselves. Later when a room was ready for finishing off, you would throw in some Smart Flooring (oak tongue and groove) and it would cut and lay itself. While this is all pie-in-the-sky stuff, our goal is clear and a simplification is entirely doable.
Power User Parameter Editing
Advanced users would need to directly edit the parameters that are driving each part and container, such as to create or configure available parts or the editor itself. Currently this is done with raw text edits. The problems are that integrity is not automatically maintained, it's hard to know what to enter, and large parameter files become difficult to understand.
One solution is a visual tree of typed parameters. The tree solves the size probem. Each param container node would be a param type, such as Need, and have default member nodes that appeared when the param container was added. Additional members could be added via selection. Each member would show allowable values and validate changes. The whole mindset would be "look and choose", not the current "remember and enter".
Param types are similar to XML DTDs. As XML matures there may be editors and other subsystems on the market we can use and not have to build our own. Of course we need to change the param text format to XML to do this.
Getting a Better BA UI Fast
The fancy Part Assembly Narrative would be tough to build. We could take an intermediate step and build the same functionality using the visual param tree. It would not be as intuitive and easy to use, but since both approaches are ultimately doing the same thing (editing parameters) it would suffice.
What we are really need is the BA editor should be able to show different views of the parameters:
- Raw text, which is the current capability.
- A Visual Param Tree, as described in Power User Parameter Editing.
- Diagram, as described in Part Assembler Narrative.
Thus to make swift progress view number 2 is the next thing to work on, then number 3. Simulataneously we could be perfecting the autohookup feature.
Whatever we build, it should be built with the BA system engine and parts itself.