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; [email protected])
---
[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" <[email protected]>
Precedence: list
MIME-Version: 1.0
To: "The Friday Morning Applied Complexity Coffee Group" <[email protected]>
References: <[email protected]>
<[email protected]>
In-Reply-To: <[email protected]>
Date: Sun, 4 Jan 2009 11:19:17 -0700
Reply-To: The Friday Morning Applied Complexity Coffee Group
<[email protected]>
Message-ID: <[email protected]>
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:[email protected]>[email protected]
<mailto:[email protected]>[email protected]
505-455-7333 - Office
505-670-8195 - Cell
- Hide quoted text -
On Sat, Jan 3, 2009 at 11:35 PM, Nicholas Thompson
<<mailto:[email protected]>[email protected]> 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:[email protected]>[email protected])
============================================================
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
