Visual Paradigm
These days visual behavior comes first, and all else follows. The key visual tools for the BA are:
System Tree - A system can be the system
being created or evolved, a collection of requirements and design artifacts,
components, process documents and models, etc. The important concept is a
system tree can be used for anything. Of interest is the BA itself has a system
tree (shown), and was used to develop itself.
The System Tree is the core tool for the BA. It's a standard hierarchical tree. Each node is an instance when
the system is running. Each node can be inspected, though this is more interesting for worker (Bean) nodes. The
use of a tree allows the user to easily conceptualize the entire system at any stage: new tree with just a root
container node, a few more nodes and the first running iteration, lots more nodes and a release, and system evolution.
The cool thing is a BA system is designed from the start to be "evolved" while running. While it can
be evolved before starting or after stopping the system, it's most effective while the system is live. This brings
full WYSIWYG to the entire system in real time, eliminating the wasteful and confusing dichotomy of design/run.
The key element making this possible is expressing intent via parameters, not code.
Below are two more System Trees. Note the ease of understanding compared to a long list of files or a stack
of class diagrams. Visual hierarchical organization is superlative for large amounts of composition, such as composing
systems from components.
Parameter Editor - This is a basic text editor
allowing a class implementing ParamDriven to have its paramters edited anytime,
usually while the sytem is running. The Apply button applies the current parameters
to the node and the effect occurs instantly. Save saves the parameter text
to storage. Revert loads the parameters from storage, and is very useful if
you want to start over.
Parameter text represents a structured collection of named values. These are used to initialize a ParamDriven
node, which may be a single class or a subsystem. We use a simple 6 keywords "language" that is easy
to learn (10 minutes) and offers powerful expression.
Shown are parameters used to drive a reusable DataEditor subsystem of 50
classes. The task is to edit the UserProfile table. The parameters are "expanded"
into 140 lines of parameters using the Data Framework schema and a meta parameter
subsystem. The expanded parameters are then passed to the DataEditor instance
via setParam(Param param). The largest parameter file so far is 800 lines.
It's used to edit a parent and 2 child tables, using 3 tabs and 8 datasets.
It replaces about 3000 lines of totally unreadable code. See more parameter
examples.
Inspector - Similar to a Property Sheet, this
inspects the current or desired node using bean reflection. The inspector
is reusable and can be used to "explore" any system, not just a
BA system. It is extremely powerful:
- The Messages tab shows the messages the bean receives and sends, complete with the ability to examine
a message event chain from source to listener.
- The Properties tab shows the bean's exposed properties. A property can be put on the clipboard. Double
clicking on a non-primitive property causes the Inspector to "explore" that object. The Inspector morphs
into inspecting that object and the Return button becomes enabled so you can return to the previous object. Exploration
can go to any depth.
- The Methods tab shows the bean's exposed methods. Selecting a method opens text fields for its arguments.
Literal arguments can be entered from the keyboard. Reference arguments can be pasted from the clipboard. Double
clicking on a method invokes it immediately. This invocation can be recorded with the Configurator. Thus a live
system can be manipulated to behave as desired, and the results recorded to "build" the system. Methods
can also be invoked and not recorded, such as to test behavior via runUnitTest() or try an alternate approach to
a task goal. Return values can be put on the clipboard.
- The Refresh button refreshes the property values.
- The New button opens a new Inspector with the same state.
- The Return button, if enabled, returns the Inspector to the previous object. When the original object
is reached the Return button becomes disabled.
- The IClip button stands for "Inspect Clipboard". It opens a new Inspector on the current object,
if any, in the clipboard.
Configurator - This contains the configuration for a single System Tree
node. At a minimum this is the item's name. For containers it may include initial and primordial invocations. For
workers (beans) it may include initialization invocations. Invocations are usually property settings and event
registrations, but may be any public method invocation. Arguments may be literals or item names.
This tool is not yet fully implemented. Currently it is read only. Eventually it will replace the Parameter
Editor for containers, which are hard for non-programmers to edit.
- The Parent View toggle button applies only to a container. It's hard to explain here. :-)
- The Record toggle button, if on, records Inspector method invocations. This is just like macro recording,
but here we are in effect writing code without writing code. ;-)
- The Save button saves the configuration for this node.
- The Revert button reverts to the stored configuration for this node.
- The Delete button deletes the select config line.
- Up and Down Arrow can move the selected config line.
The Param Marker Item and File Name are optional. They can point to a parameter file that is not in its normal
place. This allows parameter reuse outside of its normal node.
Technical Aspects
See Understanding the BA, an early writeup.
For the truly adventuresome, here's the BA
System Engine Model.
A "marker class" is required for system root directories, allowing
easy file location management since all parameters are loaded as relative
class resources. This makes the system internet deployable.
Currently we store parameter text in files. A system is stored as a directory
branch which reflects the System Tree structure.
For further detail see Continuous
Change Architecture.
Status
The BA has been fairly stable for 6 months (almost no changes or bugs)
while Jack worked on the Data Framework, which uses the BA and validates its
design. Using the BA and the Data Framework, we have a simple relational database
app up and running on clients and an AIX server. The prime purpose of this
app is to validate the BA and Data Framework. The BA took about 6 months to
design and 2 months to implement.
Of interest is the validation app has required no code, except for
the security subsystem. The strategy has been to, every time we need a new
Data Framework or BA feature, add it. Discovery has been allowed for. The
BA and Data Framework are evolving nicely, just as we planned in our assembly
centric system development process.
Clipboard use is not fully implemented. It has been implemented in
the Inspector only for earler versions. We are awaiting Java 1.2 clipboard
features.
Files are currently manually added, moved, deleted and renamed. Soon
file maintenance will be done from the System Tree. We are awaiting Java 1.2
drag and drop features.
Probable future features are:
- Implement file management from BA
- Fully implement clipboard use
- Use System Tree for components library with documentation
- Visual tree editor for params, then possibly change to XML
- Review and possibly redesign package dependencies
- Implement Configurator record, edit
- Validation/structure definition subsystem for params
- Custom param driven param editors with validation
- Interface to a GUI layout tool or build one (part of 7)
Possible future features are:
- Inter System communication via Messages, including distributed Systems
- BA behaves differently depending on skill level or user type
- BA can remember previous session state per user
- Multi-user features such as interface to configuration mgt, issue tracking
(Most future features will be developed on a discovery basis as the BA evolves)
Component Repository - The next phase of BA development is growing
our repositity of BA components. The BA is useless without a large stable
of High Quality Components. We only have a few dozen of these so far, so only
a small subset of application types can be built with ease. The largest
problem with the BA is lack of components. We also need to develop a Component
Repository system and process that would make it easy to publish, find, evaluate,
use and improve our components. An important part of this is designing a fleet
of components that work well together for various domains.
