The Season of the Swarm
My work this month is cut out for me. This is the season of the swarm. No and I am not talking about Micheal Crichton’s Prey. What I am talking about is this project that I’ve been working on for the Center For Aritificial Intelligence and Robotics. Unlike my other self-assigned projects, this one is not just merely code hacking but actually ‘software engineering’. I am not saying both are different, just that with mere code hacking, if something is ‘fubar’ , your ass is not on the line.
So, here is brief prelude to what the system is about. Since I am a big fan of Bottom-up, Iterative, Incremental and Test first Design strategy (BIIT), this is a moving target and an evolving design. entire components might be thrown out, new components might grow (rather than added..) into this design etc.
Also, for those who are software engineers (professional or otherwise), I would certainly like your views on the design, any additions etc.
Basic Design Spec for An’d’rea (nothing to do with my college senior)
An’d’rea is a framework for the simulation, testing and development of swarm intelligence algorithms. It is a system which uses the python as an extension language (the system itself being written essentially in python).
The Andrea system consists of 3 major system components. These components form the core of the system and will comprise the guts of the system.
- The Generic Simulation Engine.
- The SimObj Classes.
- The Metrics Classes.
The Generic Simulation Engine :
This is the core component which handles all the simulation related stuff and performs book-keeping operations. It is a discrete-timestep event simulator, i.e, works using discrete time rather than continuous time. It currently is planned to support only a single time line, but might be extended to multiple timelines with say multiple communicating instances. (A possibility that needs to be figured into the design without making the engine unwieldy).
The SimObj Classes :
These are the basic classes that represent the components of a swarm, the members of the swarm themselves and their environment itself. Though they both derive from the same base class (and hence can be used to build a heirachichal structures), The environment classes are different in the sense that they are usually plugged into a different part of the GSE than the members of the swarm. The members of the swarm plug into GSE’s internal simlist, whereas the environment plugs into GSE’s state management system (just a big name for a bunch of variables that are accessible to all the members of the simlist).
The Metrics Classes :
These are the basic classes that plug into a different part of the GSE and gather various metrics about the components of the swarm, and the environment themselves. Putting it principles of programming language jargon, ‘The form the reflection framework for a Swarm DSL’. That should make it instantaneously clear to anyone I guess. But for the sake of less technical readears who don’t write virtual machines during long lunch breaks. These Metric classes are used to querry the status of the environment and members of the swarm present in the simlist.
I’ve no idea of UML, so this is something that I’ve invented on the spur of the moment (to avoid learning UML :D) to explain the above system.