I'm afraid taxonomy, mentally encapsulated or otherwise, has little to do with the way I develop an ABM, Nick. Rather, good software engineering practices provide the tools for success. CMMI provides a reasonable software engineering methodology that emphasizes feedback between the following project phases. CMMI<http://www.google.com/url?sa=t&source=web&ct=res&cd=2&url=http%3A%2F%2Fwww.sei.cmu.edu%2Fcmmi%2Fgeneral%2F&ei=2fhgScbqGtyymQeQm-WpDg&usg=AFQjCNGmv_tT7T2BdmFkDa09ViM18xm4mw&sig2=mIpopBoU4RRXfCRUytfXMA>is a good replacement of the old, rigid "Waterfall" SW engineering approach. Not that i am a huge fan of rigid, formal SW engineering approaches, but CMMI at least encourages feedback between the following standard SW project engineering stages:
1. Develop a requirements doc that states what the problem is, and what the simulation will be required to produce for results. 2. Develop a design. An ABM design, if the the requirements describe real-world entities that interact with each other in meaningful ways. The ABM modeling approach naturally covers many real world application areas (duh, the universe is populated with enteracting enties, duh), but not all systems are best suted to ABM appproaches for one reason or another. 3. Select an implementation environment, unless it was specified in the requirements. 4. Code 5. Test 6. V&V The "magic" involved with being able to develop a successful ABM, or any other kind of simulation derives from the ability to develop a realistic requirements document, followed by appropriately defining the correct levels of abstraction between the real-world entities to be modeled, and their corresponding simulation agents. Extracting a realistic requirements definition from the client, or as it frequently turns out, helping the client develop one is the most important phase of any SW project. If you allow a fuzzy, ill-defined, vague, contridictory requirements definition to stand, the project will fail. --Doug -- Doug Roberts, RTI International drobe...@rti.org d...@parrot-farm.net 505-455-7333 - Office 505-670-8195 - Cell - Hide quoted text - On Sat, Jan 3, 2009 at 11:35 PM, Nicholas Thompson < nickthomp...@earthlink.net> wrote: Thaniks everybody. Interesting responses. Doug, I cannot shake the intuition that the reason you cannot see value of the taxonmy is that you already have one in your head that makes writing one down unnecessary. I am not sure quite what that means, let alone how I would show it to you. But let's imagine I were to do a study of you as you discussed a new ABM project with a client, or discussed with you colleagues how you were going to approach the problem, after the client had left. In those discussions, wouldnt you reach for exemplars or typical approaches or basic elements as you planned your way into the work? Then I would leap up and point my finger and say, AHA! you DO have a taxonomy. Perhaps the taxonomy is not in the models themselves but in the problems that the models are brought to bear on. Or, here is another way to smoke out a taxonomy. Imagine a bright eyed and bushy tailed group of college seniors who have come to learn agent based modeling from you. Now granted DOING a lot of them would be most of the course. But would you have nothing to say of a conceptual nature to guide students concerning how to approach different sorts of problems with different sorts of models? Thanks for humoring me, here. Nick Nicholas S. Thompson Emeritus Professor of Psychology and Ethology, Clark University (nthomp...@clarku.edu)
============================================================ FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College lectures, archives, unsubscribe, maps at http://www.friam.org
