Re: Classification of ABMs

[Jack K. Horner]

Although I agree with Doug that software engineering practices and
procedures  that have been shown in a statistically robust way  to
help minimize effort and schedule (e.g., CMMI, tailored to meet the
project requirements) are essential for the development of everything
except "toy" software systems, it seems that a taxonomy of ABM *data
structures*, defined not in terms of applications, but in terms of
intrinsic properties of those structures, would answer Nick's
expectations.  There is strong analog of this way of thinking about
the problem in the software engineering community.  In particular,
the "canonical" data structures (lists, queues/dequeues, rings, maps,
sets, bags, trees, graphs, etc.) taught in computer science curricula
have definite, useful taxonomies (see, for example, [1]). In rational
software engineering, at the nominal "physical design" phase, one
determines whether some of these canonical structures could provide
purchase on at least part of the design space, and, all other
suffering being the same, selects one or more of these structures
based on their functionality and space and time complexity. (It is
always possible, of course, that none of the "canonicals" will help
in a given application.  But not asking the question is a fast track
to reinventing the wheel.)

Analogously, one might hope that ABMs can be brought under a
data-structure-like taxonomy.  To the extent that ABM properties can
be subsumed under the notion of an *agent-object* in the sense of [1]
(pp. 21, 613), the taxonomy in [1] arguably answers Nick's mail.  The
taxonomic properties of an *actor*  in the sense of the Unified
Modeling Language ([2], p. 144) might also provide some clues for a
data-/object-structured ABM taxonomy.


Jack K. Horner (Santa Fe, NM; [hidden email])

---

[1]  Booch G. Software Engineering With Ada: Structures, Tools, and
Subsystems Benjamin/Cummings. 1987.

[2]  Rumbaugh J, Jacobson I, Booch G.  The Unified Modeling Language
Reference Manual.  Addison Wesley.  1999.


-----------------------------

At 10:00 PM 1/4/2009, you wrote:

>From: "Douglas Roberts" <[hidden email]>
>Precedence: list
>MIME-Version: 1.0
>To: "The Friday Morning Applied Complexity Coffee Group" <[hidden email]>
>References: <[hidden email]>
>         <[hidden email]>
>In-Reply-To: <[hidden email]>
>Date: Sun, 4 Jan 2009 11:19:17 -0700
>Reply-To: The Friday Morning Applied Complexity Coffee Group
>         <[hidden email]>
>Message-ID: <[hidden email]>
>Content-Type: multipart/alternative;
>         boundary="----=_Part_172612_31483794.1231093157827"
>Subject: Re: [FRIAM] Classification of ABM's
>Message: 1
>
>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.
><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>CMMI
>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:
>    * Develop a requirements doc that states what the problem is,
> and what the simulation will be required to produce for results.
>    * 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.
>    * Select an implementation environment, unless it was specified
> in the requirements.
>    * Code
>    * Test
>    * 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
><mailto:[hidden email]>[hidden email]
><mailto:[hidden email]>[hidden email]
>505-455-7333 - Office
>505-670-8195 - Cell
>
>- Hide quoted text -
>On Sat, Jan 3, 2009 at 11:35 PM, Nicholas Thompson
><<mailto:[hidden email]>[hidden email]> 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 (<mailto:[hidden email]>[hidden email])
>

============================================================
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