Bean Assembler - Original Spec

December 3, 1998 - Jack Harich - Document Map

(This is the original spec. Note a bit of deviation from what we currently have.)

A system is developed by visually assembling beans into modules, and these modules into a hierarchical tree. Detailed bean behavior is expressed by setting properties and invoking methods. The BA tracks these user gestures and retains them as configuration parameters. This occurs while the system is running. Gone is the design/runtime dichotomy. Since the parameters are text, not code, they can easily be modified while the system is running.

Modules contain beans and/or modules. Modules are reusable. A module's contents can be visually displayed and manipulated in an icon diagram, much like a modelling tool.

Beans are standard per the Java bean spec. There are no special requirements of any kind, allowing the BA to use any bean. A bean may use module services by implementing a particular interface. If special logic is needed that cannot be expressed via properties or module configuration, then a bean must be modified or created using code. This is not done in the BA, which draws a line in the sand between bean development and assembly.

The BA addresses the need to build and modify complex systems from reusable components. 10% of such systems are the GUI, 10% are persistence related, 10% are middleware related and 70% is generally business logic. The business logic category is not adequately addressed by current IDEs, but is where large or complex systems need help the most.

The main visual tools are:

• System trees. Each node is a "module" or bean. A tree may represent a system, systems, rreusable beans, images, html pages, tests, or anything with useful nodes. Each node is a class instance, allowing one to see a live system's structure.
• Inspectors, which can display and manipulate a node's fields and methods.
• Diagrammers, which allow visualizing and organizing a module's beans.
• ClipList, containing a clipboard list of instances (nodes) or literals. These are used for setting properties, method arguments, etc.

Anticipated benefits are:

• Rapid development and evolution.
• Systems can be easily configured for particular customers or situations.
• Customers and power users can modify a system.
• Common standards for implementation due to reuse. Users love consistency.
• A standard approach to all development. The "blank slate" effect is gone.
• Use of standard infrastructure such as Hub's lightweight event router and naming services.
• Better systems since assemblers can focus on user needs instead of code.

Background

Lo and behold, it seems that the practice and useful utilities Jack has developed, when put together, form the basic elements needed. This was a surprise. Due to having already built these first versions, we have confidence that discovery will be minmal when the BA's elements are built. An exception is orthogonal connectors, which we will not use initially.

The first version utilities we have are:

• Icon Diagrammer. This needs redesign, loose coupling and properties. This will become a stand alone reusable subsystem.
• Tree. This needs massive redesign for simplification. Currently it allows building tree systems by editing text parameters. The problem is the architecture was too complex.
• Inspector. This is very far along and is mostly reusable. Editiable properties will have to be added with custom editors supported. The largest change needed is support for property arrays. ClipList integration is also needed. This will be reusable, which requires redesign, loose coupling and properties.
• Module. Only a quick prototype to demonstrate concept works. By opening an Inspector on a Module we can already build a system. We can set properties, add beans or modules to a module, edit beans, add listeners, etc. However we have no way to save it since the rest of the BA's architecture is non-existent.

Features

• The BA provides no runtime behavior of any kind. That is provided by a system's beans. Thus the BA is a "pure" bean builder tool, unlike all existing IDEs (to my knowledge) which quickly make one dependent on the built in infrastructure used by their beans. Such systems are IDE dependent. The BA is not, since a Module is just another bean. BA systems may be platform, IDE and database independent, a worthy goal.
• Parameters may be saved in any desired format and location by substituting a different ModuleStore implementation. For example one may prefer Param serialization with storage in a relational database, or Paul's already mature parameter file subsystem. The default is text files with a "parex" file extension. These contain text to initialize a Param object. This subsystem is mature.
• Each bean has its own associated icon. These can be custom, allowing any desired Diagram behavior. Custom icons and other custom options are declared (possibly) in the ClassNameBeanFig class, much like a BeanInfo class.
• The reusable beans library is just another tree. Beans are added to this tree merely by locating the bean class as a file or url, and giving it a descriptive name. Beans are added to a system by selecting from any tree, usually the reusable bean tree. This shows the extreme flexibility/power of bean trees.
• A system is developed by modifying it while it's running. This is real time feedback, giving the developer a true WYSIWYG tool. There are minor limitations, such as live database connections and resultsets.
• Systems can be "designed" before "implemented" by using design beans in various diagrams. These diagrams later become the actual system when actual beans replace the design beans. This eliminates the model/code dichotomy. Can you belieive? The model is the application!
• Once a system is built its design is fully preserved and visible in the tree and diagrams. Thus the system remains understandable, which is the highest implementation goal.
• Systems are not nearly so class evolution vulnerable, since no bean classes are in the system. Only class names are in the parameters.
• The BA can be used for a portion of a system, such as the Business Layer within a Silver Stream app. It need not be an entire system.
• A large number of classes and subsystems will be reusable, including:
  • Param
  • Inspector
  • Diagrammer and Icons
  • Various GUI widgets and helpers
  • Hub with Naming and MessageRouter services
  • The System category, which is the heart of the BA
• The lightweight Hub services are available to any bean implementing (probably) the Hubable interface, which has the single method "public void setHub(Hub hub)". The hub may be used for custom infrastructure such as middleware, profiling, etc. Thus systems can easily have a Service Backbone with no extra coding.
• Lightweight runtime engine. The System category, presently at 10 classes, will probably come in at less than 20 classes in a 10K jar file. The Hub services are another 10 classes.

Issue - The Software Assembly Paradigm

Using composition, relationships and properties of components to define an entire system is foreign to most developers. Thus the BA may meet with low interest. But this is the future of software development, better called software assembly. To illustrate, here's a story from ComputerWorld, December 1, 1997, page 55. I've summarized and reworded it.

Rocketdyne Technical Servies in Maui operates a space surveillance system for the U. S. Air Force. They track the 8,000 or so celestial bodies, spacecraft and debris that affects mission planning in the Hawaiian area. They needed some serious telescope tracking software, so they put out bids for the sofware project.

The bids came in averaging $150,000, with one at $200,000. There was one exception, at an incredibly low $500. Believe it or not, the $500 bid was accepted, the project was completed successfully, and Rocketdyne is very pleased. How did they do it? Reusable components. To quote the system manager, Daron Hishimoto, "I've never seen a system that had so much capability using software off the shelf. This is really high-grade, low cost. I've never seen anything like it."

The source was Software Bisque, who provides tracking software for amateur astronomers. They're a family business of four brothers. Two are developers and two are astronomers. The kicker? Software Bisque is providing upgrades to Rocketdyne for $99. :-)

This is the future of software.... (BTW, I was amazed too - JH)

Issue - No or Trivial Example Systems

Another problem we may face is sure, we've got a nice little Java Bean Assembler, but developers have no confidence it's useful, since no significant systems have been built with it, and it comes with no significant examples.

I'm not sure how to address this one - JH

Issue - The BA Doesn't Do Everything Syndrome

Many developers have used IDEs or tool suites, and have come to expect their main tool to "have everything". The BA is deliberately designed to not "have everything". Like a good class, it does one thing and does it well - stitching together existing components into useful systems.

Other than education or success examples I'm not sure how to address this one - JH

Issue - The BA Is Not Much Different From An IDE

Actually IDEs use code instead of parameters to accomplish the same thing. They also allow the developer to express logic that cannot be expressed in parameters. Once could easily argue that IDEs are more powerful and more useful that the BA.

There are major differences. The BA:

• Is lightweight enough to be (or parts of) incorporated in a product, allowing customers or users to configure/customize the product.
• Allows runtime development, which cannot be done easily with classes.
• Is focused on bean assembly, and is hence easier to learn and use, and does it better.
• Allows easy product configuration as a built in feature. This feature must be added to systems produced by an IDE, which becomes difficult if a high percentage of the system must be configurable or if what needs to be configurable is unpredictable.
• Lacks the baggage associated with code editing, compiling, running and debugging. This greatly simplifies the BA, allowing a more stable, cheaper and simpler tool.
• Can do things an IDE can't, such as cloning branches for templates, allowing what-if development that is not permanent until saved, allowing visual inspection of the entire instance tree of a running system, making the modeling to implementation stage seamless, allowing WYSIWYG development as a matter of course rather than a heavyweight, bugprone, performance dragging feature, etc..
• Very cleanly forces one's development process to have developers performing system assembly or bean development. This specialization helps greatly, allowing a more appropriate OOSE process. An interesting mindset becomes possible - The assembler thinks about what to do, and the bean producer thinks about how to do it.