--------------------

"1.Complex systems are best internally organized and visually presented
as a hierarchial tree of containers and workers."

1. Here we are shooting for architectural reuse via a standard approach
to organizing systems. The best I've encountered is a hierarchy. Gone is
the "blank slate" effect. Hierarchies are common in the universe, as
everything is in a psysical hierarchy.

For example Universe has Solar System has Earth has North America has
Atlanta has Jack has Nervous System has ...

I've not encountered an applicaton software system whose components
could not best be primarily organized hierarchially. This is not to say
that ClassA has ClassB has ClassC - The hierarchy is managed by nodes
who are wrappers for the actual business classes, who usually don't even
know the hierarchy exists. Additional views may also be needed, such as
deployment, layers, data flow, etc but these are supplemental.

Once a system is internally organized hierarchially, it becomes trivial
to visually represent it in a tree. This has become a format that many
users, including non-developers, can easily comprehend. Examples are
file managers, mail organizers and word processor outline mode. My goal
was to allow systems to be easily visually developed, meaning complexity
must be easy to comprehend, and so I worked backwards from the visual to
the internal representation.

I really have no proof hierarchies are "best" but for me they are. Of
interest is we had a one day meeting on the Bean Assembler with 2
developers interesting in using it. One, Paul Reavis, was designing the
next generation of his product line and only a few days earlier had been
experimenting with sketching it out with a hierarchy. He immediately
bought into (principle 1).

BTW, nodes are often not isolated classes but are subsystem entry
points. For example my "inspectorMgr" node has 15 supporting classes.
The subsystem is modelled traditionally. If some nodes are collaborating
heavily then they need to be modelled traditonally. But still, the
system architecture is the the hierarchy first and the subsystems
second.

Another way to discuss this would be to ask "What is your highest level
form of software reuse?" I can answer (principle 1). What would be your
answer?

--------------------

"2.Larger systems are best composed from smaller systems."

This is becoming a common best practice.

--------------------

"3.Always separate rules and behavior in a system."

This is an emerging software trend. I roughly classify rules as:
- Conditional - A causes B
- Relational - A is coupled to B
- Factual - PropertyName relationship Value
- Parameter - PropertyName is Value

I'd guess over 80% of all rules are Parameters, so that's what I'm
focusing on for starters. There are many examples in RAD tools that use
properties to drive their code, particularly windows and entities. Magic
is an example that drives everything from properties. Once I've solved
Parameters I'll move up to the next easiest type of business rules.

The Bean Assembler uses a Parameter language with 6 keywords to store
Parameters in the form of a String, called a Param. Params can easily be
edited, stored, retreived and provided to an instance to configure
itself.

Each hierarchial node can have a Parameter driven business object. The
Bean Assembler transparently manages each node's Param. So you can see
how principles 1, 2 and 3 are intertwined.

Here's a simple Param example. The 6 keywords are has:, hasLines:,
hasElements:, is:, End: and //. A Param is designed to be easily human
and machine readable. Note the ability to nest to any depth.
