Design (was Re: ffi, and 'needed software' in general)

[glen e. p. ropella]

At 09:18 AM 4/30/98 -0500, Sven wrote:
>Given the rapidity of development of Swarm, and in the interests of those
>who might need to re-run a model they submitted to some journal a year ago,
>let me suggest that the swarm team post and maintain a web page that keeps
>track of which versions of the 'needed software' do or do not work with
>each release of Swarm. (And then make sure those versions of said software
>are available on the ftp site.)
>
>This list ought to start with Swarm 1.0.0, or perhaps a little earlier, if
>anyone remembers that far back ...
>
>I don't know how realistic it is to want to be able to rerun year-old
>models, given the rapid developments in the Linux/Unix world, but
>replication is what good modelling calls for. If you have to seriously
>upgrade your old model across 3-4 updates to Swarm to be able to run it at
>all, how can you be sure it's the 'same' model?

I agree completely, for whatever that's worth.  However, I 
don't think maintaining a web page is the complete answer.  It's
better than what's present, now; but, there are larger issues
that could be resolved if we spent a little time thinking about
this.

This relates to the recent Swarm Design Philosophy thread, as well.
What we really need is a kind of "map" of where Swarm has been
and where it's going.  This involves everything from a living 
design document all the way down to the ChangeLogs Marcus is
dilligently maintaining.

I envision this "design document" to not only contain what is 
there and what is intended to be there; but, why things are there
and what purpose we think any given artifact (feature) will serve.
That means that applications written based on a certain stage in 
Swarm's development will have a reference to which they can refer
so that users, should they have the impetus, can give descriptions
of any artifact in their model that is causally related to any
given artifact in Swarm.

For example, in Village, there could be an entry in the Village
design description talking about the hoops Eric had to jump through
to get multiple agents at a cell in a raster, given the lack of 
a general mechanism or convention in Swarm.

And in SCL, there could be an entry in the design description talking
about the Cell Editor (something that would make sense as a part of 
Swarm rather than a part of the application) and the homegrown random
number generator in SCL.

I've talked a little to Marcus about what an adequate design document
for Swarm might look like.  I have a whole bag of systems engineering
tricks (like requirements analysis/design/flowdown) and such; but, 
I'm worried that those techniques are a) too heavyweight for a 
minimally staffed project and b) partly obsolete given that they're
mostly based on OO/structured analysis rather than Agent-Oriented/CAS.

Jim Odell had offered to provide some stickyness for a potentially
self-organizing "modeling language" group of Swarm users.  In some
ways, I think that type of thing will be required for us to dream 
up an adequate form for the design document.

Any thoughts?

glen
glen e. p. ropella         =>Hail Eris!<=         <address@hidden>
The Swarm Corporation                             (505) 424-0448

                  ==================================
   Swarm-Support is for discussion of the technical details of the day
   to day usage of Swarm.  For list administration needs (esp.
   [un]subscribing), please send a message to <address@hidden>
   with "help" in the body of the message.
                  ==================================