
Jack Harich wrote:

> Well, I can tell you're busy lately. Hope all's well.
>
Stressful, both good and bad. Just told my bosses that I was taking a
vacation for my
own health for a week and a half or so due to burn out. I've shipped
four betas in two
months, redesigned the way we handle map images, implemented the server
side
of our software with full merging and concurrent edits using only
TCP/IP, gotten the annoying COBOL interface to work, etc. The head of
engineering at Greystone declared it to be a "momentous step in our
field" and that "no one else can do this" as we cranked
two days worth of backlog through the system in about two hours. He also
estimated that the 100K investment will pay for itself in 8 months or
less. All very inspiring,
and happy users are a wonderful thing, but I'm beat- so I'll be gone
from the 16th until christmas.  The book "Death March" by Ed Yourdon has
been very educational. I highly recommend it - his sense of humor keeps
it from being thoroughly depressing, and the insights are penetrating.


> I thought I'd get your take on this before showing it to the rest of the
> Consortium.
>
Praise indeed.

> -----------------------------------------------------------------------
>
>                            Nutshell Vision
>
>      The Bean Assembler (BA) assembles Java beans into a system
>      using visual tools and no code. It uses parameters (what to
>      do) instead of code (how to do it). The parameters are saved
>      to store a system and loaded (incrementally) to initialize
>      the system. This is done completely transparently to the
>      developer.
>
First things first. This is seriously hot - just exactly what I want and
need. Once again, you have put the finger on the real bottleneck in our
productivity.

Payoff due to configurability has been snowballing. The COBOL interface,
which is entirely composed of fixed-width records
(700+ characters/record!) in exchange files, was one of the first
parameter-driven pieces of our software. Recently I pulled most of the
"trivial" business knowledge (header information that just flows through
the system rather than determining
actions) out into a config file as well. As a result, I was able to
debug on-site at the COBOL place without compiling or even having the
JDK along. Similar things happened when installing the beta - we
recently had a server crash, and lost about a week's worth of
configuration (I had stuff local on my linux box, so lost no code); I
got out to install and realized that there were several regression bugs
due to this, so just hand-edited the config files and got it rolling.

Imagine if you could just throw the system into design mode and tweak it
that way...

>      A system is developed by visually assembling beans into
>      modules, and these modules into a hierarchial 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.
>
Yes!

>      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.
>
Yes!

>
>
>      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.
>
Yes!

>
>
>      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.
>
Oh yes! Had a two-hour lunch with our owner (you met him at the party, I
believe, the shorter guy with the beard, one Bill Fay) and he emphasized
his plan for the company (as opposed to the president's plan, which is
to build an enormous monstrosity just like he's used to). Bill wants to
get the "money machine" (sales, support, installation, perhaps minor
production coding) running, then pull me and ash out to do serious R&D.
This depends upon being able to hand over easily-configurable and
extensible products to the other guys. We're approaching the right
architecture, but it looks like this is the tool.

I see multiple levels of use, just as with any other serious development
tool. Architecture and coding remain the domain of us full-time
developer types. Less experienced folk can cut their teeth filling in
the gaps in the reusables library. Low-level bean assembly to build more
abstract reuseables will probably consist mostly of programmers, though
some who don't code as well may find a talent for design using this
model. This might consist of, perhaps, building a map browser using a
view widget and some buttons to control it. Mid-level bean assembly
might put together a map-based application using some property sheets,
redlining beans and the client's logo. High-level bean assembly might -
who knows? Put together a distributed system with client and server
beans? Or just configure bean apps?

As far as business logic is concerned, I think that beans have been
pegged as "visual components" just as java was pegged as being only good
for "pretty graphics on web pages". I try to make my visual components
beans, but I use bean capabilities (serialization, configurability,
etc.) almost exclusively for business logic. As far as I'm concerned,
simple serialization is the one thing in java I would be most loathe to
give up.


>      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.
>
I would add better separation of development tasks. People with a talent
for reusables can work on those, while people with a talent for
fit-and-finish on final apps can work on those. A graphic designer could
put together the final interface and we could finally fight our way free
of grey boxes and beveled buttons.

> -----------------------------------------------------------------------
>
>                               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.
>
Yup. This is definitely the case of some great ideas in need of a
cohesive vision.

> -----------------------------------------------------------------------
>
>                                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.
>
Very worthy. While at the client site, we discussed the problem of
large, tightly-coupled suite systems. Our product vision is that we
provide a specific tool that communicates with existing software at a
customer's site. Most other products in the utility industry are
designed to be "do everything" systems, which means that customers
generally select them based on one or two
clearly superior components and are then stuck with those that are
inferior. It's like stereos - if you buy and all-in-one system, you're
stuck with the tradeoffs you make when you select it - you can't just
swap out the amplifier when you need more watts.

There are obvious marketing reasons for this approach, and many
customers _want_ a does-it-all package. But when you're talking market
share, there are some real problems. For example, one of our major
competitors is really a mapping/GIS specialist. Their staking product is
very much a "bag on the side" that they built to make customers happy.
This has cost them resources and credibility (they are embarrassed to
show the thing at shows, and it is way behind schedule). The staking
product is useless without the mapping package, so is limited to the
same market share as the mapping package, and probably less, because
many of their customers don't want it.  Contrast ours, which will work
with every mapping package we write an interface to, or no mapping
package if the client has none (and some don't). But our model enforces
simplicity - we don't update autocad files directly, we just do simple
redlining on static images.

It seems to me that most of the IDEs out there are geared towards two
audiences: the corporation that wants a standard environment bought by
the bushel, and the beginner who needs extra support during the learning
process. Oh, and I suppose the RAD developers, whoever they are (I
prefer dumb prototypes myself, paper and pencil do fine and you can't
pretend it's a real system).

As your use becomes more sophisticated, though, you just need more, and
end up using several tools, piecing them together as best you can.
Unfortunately most tools just aren't designed well for that.


>         * 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.
>
I will try to get you my persistance stuff before I head out. Since it
addresses a different issue
than param, they should be complementary - TOF is more complex than
parex, but it can describe any graphable object structure, and requires
nothing more than that the object's state be fully described by its
get/set methods. Coupling to class definition is a problem, but it's
much better about it than java serialization (for one thing, you can
hand-edit the thing if need be) and sometime soon I have to write a
conversion program to upgrade my client's data files whenever the model
changes with a release.

This is actually a pretty significant issue - we have to make sure that
the artifacts of the BA (parex, TOF, or whatever) are robust enough to
survive changes in the reusables. Though I believe I explained my
layered "throw it away" principle before - the final apps should require
so much less work than the reusables that just rebuilding it with the
tool shouldn't be too onerous an option.

My vision for my converter is that it define a language for object
transformation. This class becomes that class; this property becomes
that property, this collection of properties and subproperties merge to
form a single instance of a different class. The universe of
transformations is complex but finite, and I think some heavy thinking
may enable me to implement a nice system with just a few basic
transforms.

>         * 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.
>
I'm still not sure what I think of the BeanInfo idea - part of the
problem is that I ruthlessly separate GUI and BL code now, so it galls
me to define a custom editor for a nonvisual bean in the same package,
which has no visual stuff in it. My package dependency enforcement
process would balk at that. I know you can place them elsewhere, but I
haven't experimented enough to settle on something I can live with.

>         * 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.
>
What about preconfigured beans? ("templates"? or is this the same as a
module?) These
would be in beanbags of some sort. Very flexible reusables may look and
act so differently when configured that having the various permutations
already built might be good.

>         *  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.
>
Yes.

>         * 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!
>
Well, that's what OO is all about, right? There are so few
"implementation details" evident in the class structure of a good Java
system that this finally seems to be a fully realizable goal.

>         * 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.
>
Crucial; this is the foot in the door as well. If it's easy to use for a
little bit of a system, potential users will have a chance to test drive
it without committing fully.

> -----------------------------------------------------------------------
>
>                 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
>
Build a significant app with it. Perhaps it can be fully circular and
build itself, like a good compiler? Or there will be other tools that
are needed that can be built with it.

Of course, if you define "significant" as "worth half a million or more"
then oh well. Can't just hand those out with the breakfast cereal.

> -----------------------------------------------------------------------
>
>             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
>
My comments above on "do-it-all" systems apply here. Education should
include how to dovetail it with a variety of IDEs and environments. Then
if they've got symantec VCafe or whatever they'll be able to visualize
just where it would help them. Most people can only picture a solution
this elegant and abstract when it is tied down to concrete pieces of
their own life - their own problems and their own tools.

> -----------------------------------------------------------------------
>
>            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 faster, because it requires no compilation! All those annoying
adaptor classes in those
IDEs - what are they thinking?

>         * 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.
>
Doesn't stick it's dirty nose into your code. No annoying
/*SUPERVISUALIDE SECRET CODE - DON'T ERASE &36130-4485796601-*/ stamped
all over your nice clean source.

>         * 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..
>
Also, it seems like this approach would grow geometrically rather than
linearly. Bean-aware VIDEs allow you to add and then use custom beans,
but you just get more and more little components to keep track of. This
(because of the Module architecture) allows you to build increasingly
complex things in the time-honored hierarchical manner. It works for
cars, rockets, buildings and computers; it's about time it started
really working for software.

>         * 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.
>
And the client thinks about "what color should the background be?" and
"is Job ID# really the most intuitive name for this field?"

> -----------------------------------------------------------------------
>
>                               Discussion
>
>      Well, that's the potential. This would be a significant
>      Atlanta Java Consortium reusable, but a tough one to build.
>      I plan to build it because it will double my productivity on
>      certain types of projects, which I will be seeking out. It
>      will also demonstrate my ability to conceive of and produce
>      a complex system involving advanced OO and best practice
>      concepts. If I can pull it off it will absolutely make my
>      reputation in software, my new field.
>
Too late - your reputation is made, at least around here.

>      Possible reusable wisecracks:
>
>           "I've already got a BA."
>
>           "Build it and they will come."
>
>           "Build it and we'll see...."
>
>           "I saw one of these at Home Depot for $29."
>
>           "I could really use this next week. How about
>           Wednesday?"
>
Or my favorite (actual user quote) " Oh, we've had something that does
just that for two years now. We just don't use it."

I'm all excited now, and getting maps to print with white backgrounds is
no longer as stimulating. I will certainly contribute as much as I can,
which hasn't been much lately...

Good work.

--

Paul Reavis                                      preavis@partnersoft.com
Design Lead
Partner Software, Inc.                        http://www.partnersoft.com



