|
Model ArchitectureActions, Schedules, and Swarms look and act like other Java or Objective C types. To create agents and groups of agents (and thus models) means creating and connecting instances of these types using code. With a deliberate effort of abstraction, a modeler can take minimalistic approach to the implementation of Swarm models in Java and Objective C, and cut away a lot of the fat. Empirically, a review of Swarm models shows a lot of variance in programming idioms for tasks that are in fact identical. To avoid describing a model's architecture using raw code, the first task is to figure out what all Swarm models have in common, and then to specify a semantics that encompasses the important features of that commonality. There are two parts to this: the first was stated above: a Swarm model is one that uses Swarm scheduling semantics, i.e. Swarm, Schedule, Action. The other part is the fact that modelers use Swarm to do things besides describing complex, aggregate behavior patterns. For example, Swarm provides objects, the means to load and save objects, data structures such as lists and maps, probes to inspect these data structures, grids and rasters to display them, etc. All of this and more is needed by modelers to create and evaluate their models. How can we factor out all the constant architectural aspects of a Swarm model but preserve the goal of a having a quick, expressive experimental environment? At SwarmFest 1999, Ferdinando Villa (http://ieee.umces.edu/~villa), a scientist at the Institute for Ecological Economics at the University of Maryland presented a paper which proposed a modular description architecture for modeling called IMA, the Integrating Modeling Architecture. Paraphrased, Ferdinando made the observation that modeling requires:
With regard to the first requirement, Swarm scheduling (as a special case of agent-based modeling as a special case of discrete-event simulation) is one possible paradigm for hypothesis generation and testing. With regard to the second requirement, in a sense we have these `specific semantics' (Swarm, Schedule, Action). In practice, as mentioned earlier, there is a need for stronger conventions for gluing the components together. Where things really get untenable for Swarm is with #3 and #4. So far, we've addressed this with relatively low-level integration features like multi-language support, HDF5 object persistence, community programming support, and our minimalistic class libraries for space representation and some basic built-in analysis tools. SDG members tell me time and time again how much they want better spatial representation capabilities, better analysis & visualization tools, and better data representation techniques for agents. [1] IMA addresses all these problems. In IMA, model component semantics (in our case, one example is agents) are described in Modules. Primitive Modules are things such as datasets, probes, or scripts each having a specific typing and parameterization. The physical representation scheme for all IMA components is a tree of linked nodes. In fact, it is the Document Object Model (http://www.w3.org/DOM), a well-known standard for active management of hierarchical web content.
So, compared to Swarm model implementation as it is done today, the first change with IMA is that `the big picture', is painted using a tree of Module nodes. Most of these Modules will have a specific fixed grammar. For example, a user would not be allowed to create a Schedule outside of a Swarm, as they can in, say, Java. When a Swarm modeler says "I have an ObserverSwarm, which contains a ModelSwarm which contains three Agents using ScheduleA that runs ActionA and ActionB", in IMA it means exactly one set of forms, and only the details of the ActionA and ActionB Modules would (or could) include any code at all. This notion of a grammar of module types has the handy attribute that it is a well-behaved structure which can be manipulated using a graphical model development application, as described earlier. A corollary is that there will not be obscure toolchain complexity or a compiler involved in model development, except in cases where such `native' components are desired for performance. IMA addresses issues #3 and #4 by being designed for uncoordinated extensibility. It is easy for third parties to add new Module types to their modeling environment. In contrast, it is not easy for someone to add a feature to the Swarm libraries, since there are so many internal conventions to the Swarm code. IMT is the engine of the IMA architecture. A Swarm IMT module is well underway. Swarm now supports COM which makes it possible to load the Swarm simulator dynamically from the IMT C++ engine, and for Swarm to call the IMT engine via COM. The SDG is enhancing the clean IMT prototype to use Mozilla's DOM interfaces. This will allow IMT to load model descriptions off the web, and run them inside Netscape 6. Concurrently, Dr. Villa continues with foundational work on IMA semantics. With a Netscape 6 plug-in for IMT working, the SDG will then implement a basic `Swarm' Module grammar for IMT. This will have a simple design similiar to the XML prototypes described in previous papers (http://www.santafe.edu/~mgd/anl/hydralink.html#AEN127), except that Actions will reference IMT Script Modules, not raw precompiled Java code. The Netscape 6 plug-ins for IMT (the basic IMA grammar processor and object manager), the Swarm IMT plug-in (the Swarm add-in grammar module for IMT), and the Swarm plug-in (the existing Swarm engine) will constitute the first milestone, described above. It's no oversight: flat-out native code, all the way down. The second milestone will layer on top of the IMT system a graphical editor and development environment for IMT/Swarm models. Again, this can be tackled in a modular way where the SDG contributes inspectors, editors, etc. specific to Swarm as a plug-in, and gets the rest for free. (And other collaborators on the the IMA effort can do the same, of course!) Mozilla has good infrastructure in place for this work, and by the time we get to this point we (the IEE and SDG) should have a clear picture of Mozilla's future. [2] The first milestone should be ready around the first of the year, and then they'll need be a period of incremental improvement and a stability release. (The first release of Netscape 6 is expected soon, Mozilla 1.0 is expected second quarter of next year.) [1] Why not continue development with the current Swarm analysis, gui, simtoolsgui, and space libraries? The underlying GUI interfaces that Swarm has are undesirable for general usage. This is because they were put in place primarily to support the probe panels, analysis and space capabilities that do exist in Swarm. Basing further work in the space and analysis libraries on this code is a poor investment since this GUI library lacks any real design, and because it is based on Objective C. Such work would be polluted by a problematic foundation and, worse, there is no substantial developer community around Objective C. This latter problem also makes further development on the collections library a questionable enterprise. All in all Swarm needs to rebuild itself around a modern foundation. This means leveraging best-of-the-breed components and avoiding from-scratch implementation whenever possible. [2] A note on Mozilla: some people believe Mozilla will fail. Some people believe that Mozilla is hopelessly bloated, bug-ridden and that Netscape will die. Putting aside for the moment that these people are mistaken, defeatist, and and deeply misguided, ;-), I should point out that all the technologies mentioned above are all well-documented standards. Microsoft COM is deployed on millions of Windows machines, and DOM (level 1) is a standard Internet Explorer will support sooner or later. So there are alternatives: one is to use scriptable COM components with Internet Explorer. Indeed, these are not zero-energy alternatives, but they are low-energy alternatives. |
Model Architecture