Colloquium at Stanford
The Unfinished Revolution

Memorandum

Date: Sun, 13 Feb 2000 22:45:40 -0800

From: Eric Armstrong Reply-To: unrev-II@onelist.com

To: unrev-II@onelist.com

Subject:   Model Construction Kit

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
                  v
             +---------+
   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:

Exceptions: 


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

IF:
                  | control
                  v
             +---------+
   Input --->|   If    |
             +---------+
               |     |
               v     v
             then    else

LOOP:
                |    +----+
                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
                  v
             +---------+
   Input --->| Process |---> Output
             +---------+
Might decompose to this: 

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

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!

Sincerely,


Eric Armstrong
eric.armstrong@eng.sun.com