[unrev-II] Model Construction Kit

From: Eric Armstrong (eric.armstrong@eng.sun.com)
Date: Sun Feb 13 2000 - 22:45:40 PST

From: Eric Armstrong <eric.armstrong@eng.sun.com>

I actually made progress on this. I scratched down
a collection of Java interfaces for model-beans that
could be wired together in a GUI-builder environment.
(We're probably a year or two away from having any
time to implement something of that kind. I just wanted
to mention it -- if someone is rabidly interested, that
will be further inducement to brush up and write up
the ideas that have coalesced thus far.)

The thinking is very rough at this stage, but I'm
intrigued with the possibilities. One possibility is
for simulation-models, of course. Then there is
the nutrition-modeling I've been interested in.

But the *really* interesting possibility comes from a
process-modeling strategy I came up with some years
back. Details of the strategy are below, but the
most interesting implication of it is the possibility
of creating graphic computing "components" that you
could wire together graphically, like a CAD drawing.

[Note: "Component" based programming has been a holy
grail of computing for a long time. Object-oriented
programming was a step in that direction, and we can
graphically connect GUI objects. There has even
been progress towards "enterprise objects", aka
"enterprise beans", that encapsulate bits of business
logic. But we're still pretty far away from component-
based programming. Perhaps a system like the one below,
done as part of a "model construction kit" would be a
a step in that direction.]

Modeling Computer Processes
The whole methodology stemmed from necessity.
I was contracting, with no office, and only a small
2' x 3' whiteboard. I couldn't diagram more than
a few things at any one time. After that, I'd need
to copy them to a sheet of paper, hang it on the
wall, and go on with the designing.

In that system, I used the basic system box:

                  | control
   Input --->| Process |---> Output

Because the whiteboard was so limited, it was
necessary to model the system *hierarchically*.
The top level view was only a few boxes. Looking
at any one box in greater detail exposed a few
more boxes within it. Examining those, in turn,
produced more boxes.

As a result, the components were nested so that they
"decomposed" into greater levels of detail as one
drilled down through the hierarchy.

At a systems level, it is the information flow that is
of most interest. The "control" arrows got some use,
but not a lot.

But when you decompose a process down to the code level,
the control tends to be of more interest than the
information flow, in many respects. So the "flow" arrows
became the flow of control through the code, rather than
a governor on a process.

(As a result, "control" information from the systems view
became "input" at the code view, but that seemed to
work fine.)

To model program control flows, I made a few modifications
to the basic box:, to get:

                  | control
   Input --->| Process |---> Output
                | |
                | +---> Exception
           Normal Flow

                  | control
   Input --->| If |
               | |
               v v
             then else

                | +----+
                v v |
             +---------+ |
   Input --->| Loop | |
             +---------+ |
               | | |
               v +----+
             then else

These and the other items I created were pretty
simple, but when combined together and, most
important, when *nested hierarchically* they
turned out to be capable of describing a
fairly sophisticated system.

Various inputs and outputs could be added to the
boxes. Each of the components existed in a larger
box (the component that contained them) so where
the arrow ended told whether the information came
from inside or outside the system.

For example, this box:
                  | control
   Input --->| Process |---> Output

Might decompose to this:

  | | |
  | v |
  | input +---------+ |
  +----------->| |-->value |
  | +---------+ |
  | | |
  | v |
  | +---------+ output |
  | value-->| |--------------->
  | +---------+ |
  | | |

The system worked fairly well, and it was
graphically simple, so it's a reasonable candidate
for automation. It occurs to me that if we
had a model building toolkit, it might be possible
to construct code by building models.

The generic loop, for example, would be implemented
differently depending on the data it was processing.
But at the reasoning level, all you really want to
say is that the program needs to "loop over the
collection and look for a matching item", or something
like that.

The last thing you *really* want to worry about is
array indexing, loop boundaries, and the data
manipulation operations necessary to carry out those
procedures. The computer can sweat that kind of
small stuff!

--------------------------- ONElist Sponsor ----------------------------

Get what you deserve with NextCard Visa. Rates as low as 2.9 percent
Intro or 9.9 percent Fixed APR, online balance transfers, Rewards
Points, no hidden fees, and much more! Get NextCard today and get the
credit you deserve! Apply now! Get your NextCard Visa at
<a href=" http://clickme.onelist.com/ad/NextcardCreative2CI ">Click Here</a>


Community email addresses:
  Post message: unrev-II@onelist.com
  Subscribe: unrev-II-subscribe@onelist.com
  Unsubscribe: unrev-II-unsubscribe@onelist.com
  List owner: unrev-II-owner@onelist.com

Shortcut URL to this page:

This archive was generated by hypermail 2.0.0 : Tue Aug 21 2001 - 18:56:46 PDT