Download Towards a Methodology for Agent-based Social Simulation

Towards a Methodology for Agent-based Social Simulation
Research
(Research-in-Progress)
“Draft, Not for Quotation”
Ana Maria Ramanath and Nigel Gilbert
School of Human Sciences
University of Surrey
UNITED KINGDOM
[email protected]
[email protected]
Abstract
A review of software engineering principles, rapid prototyping approaches and
accounts of the development of simulation models is used as the basis for
recommendations about some practical techniques and methods that can be
used effectively in the development of agent-based social simulation models.
Particular attention is given to the incorporation of users and stakeholders i n
the design of simulation models, using a participatory approach to software
development.
1
Introduction
While agent-based social simulation as an approach to the understanding of social
processes and as a technique for creating tools to assist policy formation and evaluation
has grown rapidly over the last decade, there has been little effort as yet to formalize,
systematize and communicate methods for developing useful social simulations. The
increasing attention paid to social simulation can be gauged from the success of the
Journal of Social Simulation and Artificial Societies (http://jasss.soc.surrey.ac.uk/), the
formation of the European Social Simulation Association (http://essa.cfpm.org) and
variety of workshops and conferences focusing on agent-based social simulation now
being organized. However, there is still relatively little guidance available for someone
coming into the field and wanting to learn from others’ experience about the best way t o
organize a project based on simulation (but see Gilbert and Troitzsch, 1999; Suleiman,
Troitzsch and Gilbert 2000).
This paper begins to synthesise such methodological experience by examining both
the literature on the development of complex software systems and some of the reports
of social simulation research that have been relatively explicit about the processes that
they have used to develop their simulation models. Policy-oriented simulations are often
developed within a participatory framework in which the stakeholders contribute
throughout the development process. There is a lot that can be learnt from the
literature in software engineering about how to manage such participatory processes and,
1
in particular, about techniques such as rapid iterative development and user workshops,
that deserve to be more widely known within the social simulation community. Other
ideas can be garnered from finding out what worked in previous social simulation
research. Some of this past experience is available in published research reports, but
often methodological issues, and more particularly, accounts of what did not work, are
omitted from such reports, which focus more on successes and on results. The aim of this
paper is therefore to begin to create a body of methodological advice, rooted in practical
experience, that will be useful to those engaging in social simulation-based research.
The work on which the paper is based has been conducted as part of a European
Union supported project, Simweb (http://www.simdigital.com), which will provide
European businesses in the digital contents sector with insights and tools which will
enable them to take more informed business strategy decisions. To achieve this, SimWeb
will design and implement sector models based on multi-agent simulation technology.
These models will allow market participants in the digital contents sector to run through
a variety of social and economic scenarios and observe the impact they have on their
businesses and on the dynamics of the market.
2
Computer-based Social Simulation as a Research Method
Computer-based modelling is the goal-oriented, computer-aided simplification of some
feature of the social world (Sterman, 1988). It has been argued that a clear purpose (or
goal) is an essential ingredient of a successful modelling study because, it allows
stakeholders to ask questions that reveal whether the model is useful for solving the
problem under consideration (Gilbert and Doran, 1994; Birta and Ozmizrak, 1996;
Sterman, 1988; Gilbert and Troitzsch, 1999; Moss, 2000). Simulation is understood as a
particular type of modelling (Gilbert and Troitzsch, 1999), and has been defined as:
“driving a model of a system with suitable inputs and observing the corresponding
outputs” (Bratley, Fox and Schrage, 1987 cited in Axelrod, 1997). As a young, rapidly
growing social research field, simulation stands at the intersection between the social,
mathematical and computer sciences (Conte et al., 1998); and the uses to which it can be
put are multiple and diverse, including: prediction, performance, training, entertainment,
education, proof and discovery (Axelrod, 1997 and also Gilbert and Troitzsch, 1999).
Regardless of the purposes to which it can be put, simulation as a research method (or
methodology), has been referred to as a “third way” of doing science, and as such, it has
been contrasted with the two standard methods of induction and deduction (Axelrod,
1997; Gilbert, 1996). Axelrod (1997) explains the differences in the following manner:
“…Like deduction, (simulation) starts with a set of explicit assumptions. But unlike deduction, it
does not prove theorems. Instead, a simulation generates data that can be analyzed inductively. Unlike
typical induction, however, the simulated data comes from a rigorously specified set of rules rather than
direct measurement of the real world. While induction can be used to find patterns in data, and
deduction can be used to find consequences of assumptions, simulation modeling can be used as an aid
(to) intuition” (page 24).
But, when used as a research approach, it is not without its caveats. Thesen and
Travis (1995) warn researchers of some potential risks that may render simulation
studies unsuccessful. These are: 1) Failure to state a clear objective; 2) Failure to frame
an answerable question; 3) Use of simulation when a simple analytic model would suffice;
4) Inappropriate level of complexity; 5) Bad assumptions in the model; 6)
Misinterpretation of simulation outputs; and, 7) Budget overruns. Figure 1 shows the
common steps followed by simulation projects.
2
- Research Question
(s)/ Problems;
- Literature Reviews
- Observations
Model Conceptualisation
Model Design
Build / Implementation
Verification
Validation/Analysis
Publication of Results
Simulation Results
Replication
Figure 1. Generic Stages in the Simulation Research Process.
Different authors offer shortened or modified versions of the approach depicted in
Figure 1 (see for example, Goldspink, 2002). However, the approach in Figure 1 above
can be considered to be a generic research framework for all simulation studies.
Nevertheless, ultimately, the topic and objectives of such studies determine the extent t o
which each of the above steps is addressed. This, because, as Conte et al. (2001), argue:
“…(social) analysis should start with the problem rather than the model, technique or
theory” (page 184).
The rest of this section summarises the steps in Figure 1, following Gilbert and
Troitzsch (1999); Axelrod (1997); Moss (1998); Birta and Ozmizrak (1996); and
Goldspink (2002). For a detailed description of what each of these steps entails, including
the caveats of dealing with simulation data, the reader is referred to those authors.
Once a ‘puzzle’ (a question or problem whose answer is not known, and which it will
be the aim of the research to resolve), is identified, conceptualisation consists of
defining and scoping the target (or problem area) for modelling. This stage may also
include some observations of the target, in order to provide parameters and initial
conditions required for the model.
3
Model design involves making decisions about the type of overarching simulation
approach to be followed (e.g. participatory or ‘user-centred’, conventional or
‘researcher-centred’, etc.); what to omit and what to include in the simplified version of
the target to be modelled (model specification); the minimum number of assumptions
needed so that the model applies to many different circumstances; selection of a
software and hardware platform, etc. Keeping in mind the goal of the simulation and
keeping the design as simple as possible is important. This is because complex models are
much more difficult to validate than simpler ones, and this in turn affects the quality of
the conclusions to be drawn from the research (see Jager and Janssen, 2002). Depending
on the simulation techniques used, researchers may produce a written description of the
model accompanied in some cases by a high-level, pictorial representation. In agentbased research, for example, researchers tend to use object-oriented notation (similar t o
the Unified Modeling Language or UML) to aid with the process of model specification
and design.
Model Construction or build refers to the activities involved in writing and testing
the computer-based program (s) necessary to implement the model. In some cases,
purpose-built software packages or ‘toolkits’ may be used. The programming languages
used should be well structured and allow for incremental refinement. Languages such as
Java, Visual Basic and Lisp are often favoured over C, C++ and Pascal for these purposes.
Using languages familiar to the simulation research community is important for the
purposes of replication, as will be seen later in this section.
Verification is concerned with the correctness of the transformation from the
abstract representation (the conceptual model) to the program code (the simulation
model). That is, with ensuring that the program code faithfully reflects the behaviour
that is implicit in the specifications of the conceptual model. It is essential to ‘debug’
the simulation program (s) carefully, preferably using a set of test cases, perhaps of
extreme situations where the outcomes are more easily predictable.
While verification concerns whether the program is working as the researcher
expects it to, validation concerns whether the simulation is a good model of the target.
A model which can be relied on to reflect the behaviour of the target can be considered
‘valid’. Validity refers to two aspects: a) ‘internal validity’, which concerns the
correspondence between the theoretical or abstract model to be simulated and the
implementation; and b) ‘external validity’, or the degree to which the model and
simulation corresponds to the real world.
Once the program(s) have been written and tested, they are put through many
(simulation) runs to carry out sensitivity analyses (that is, the behaviour of the model in
the presence of slight changes to parameters and initial conditions), as part of making a
model (internally) ‘valid’ and also robust. The aim here is to answer questions about the
extent to which the behaviour of the simulation is sensitive to the assumptions made
during the design stage.
The final stage is the sharing or publication of results. That is, putting the results of
the research into a format ready for consumption by the scientific or the practitioner
community or both (e.g. presenting the research at conferences, publishing in paper or
electronic based journals, on the Internet, etc.).
All of the above stages are carried out for almost all published simulation models.
There is, however, another stage of the research process that is infrequent but which
needs to be considered, that is, replication (hence, the dotted line in Figure 1 has been
4
used to represent this stage as optional). Replication involves confirming that the
claimed results of any given simulation are reliable, in the sense that they can be
reproduced by anyone starting from scratch. Ideally, published simulations should be
presented in sufficient detail for this to be achieved, but space restrictions in journals, for
example, often prevent this from happening.
In the next section, a contemporary approach to social simulation research, namely,
multi-agent based simulation (which continues to share the core research process
depicted in Figure 1 and is central to this paper) is presented.
3
Multi-agents as a Social Simulation Research Stream
Gilbert and Troitzsch (1999) identify and describe in great detail several approaches t o
social simulation, corresponding to research streams in the literature derived from
different epochs of simulation research. Helped by developments in the field of
Distributed Artificial Intelligence (DAI), one such simulation research stream has
received increasing attention in the literature (Gilbert and Troitzsch, 1999; Conte et al.,
1998; Davidsson, 2000), and as Conte et al. (1997) assert, it is (still): “living its season
of glory” (page 10). This research stream is known as Multi-Agent Based Simulation
(MABS). As previously mentioned, MABS draws on ideas and techniques from DAI,
particularly in the area of Multi-agent Systems (MAS). MABS is also influenced by
approaches in distributed discrete event simulation, object-oriented simulation and
dynamic micro simulation (Davidsson, 2000). In the rest of this section, MAS and
MABS are compared and contrasted; because although similar in their use of modelling
techniques and tools, their purposes and scope differ.
Central to both the MAS and MABS fields are the notions of ‘agent’, and ‘artificial
society’. Although there is no generally agreed definition of what an agent is, software
agents are usually described as computer programs capable of flexible, autonomous action
(Wooldridge and Decker, 2000; Gilbert and Troitzsch, 1999; Foner, 1993). Agents are
considered to represent and act on behalf of real-world entities, from inanimate objects
to people (Huhns, 2002). Multi-agents are conglomerates of more complex forms of
agents (see Gilbert and Troitzsch, 1999). Artificial societies comprise multiple computerbased agents, located in a (simulated) physical environment (Doran, 1997).
In both MAS and MABS, researchers focus on the interactions of many intelligent
agents. Their interactions can be either cooperative or selfish. That is, the agents can
share a common goal (e.g. an ant colony finding efficient routes to food sources), or
they can pursue their own interests, as in the free market economy (Sycara, 2002).
Notions such as interaction and autonomy are important, because even if individuals (or
agents) follow simple rules, the resulting group behaviour can be surprisingly complex,
and remarkably effective (Bonabeau and Meyer, 2001). As evidenced by the research of
Bonabeau and Meyer (2001), for example, well-known multinationals are beginning t o
reap the benefits of applying this knowledge in business settings. The results of their
study suggest that companies such as Unilever, McGraw-Hill, CapitalOne BT, France
Telecom, and others have devised more efficient ways to schedule factory equipment,
divide tasks among workers, organise people, plot strategy, find and exploit new
markets, etc.
In addition to the above notions of interaction and autonomy there are other
concepts which stand at the centre of many MAS and MABS studies. These are:
cognition, behaviour, emergence, second-order emergence, flexibility, decentralisation,
beliefs, desires, intentions, self-organisation, robustness, intelligence, and complexity, t o
5
name but a few. This shows that both MAS and MABS draw from theories in disciplines
as diverse as: biology, sociology, economics, organisation and management science,
complex systems, philosophy, psychology, etc. (Conte et al. 1998; Sycara, 2002).
Overall though, MABS researchers are more interested in building software for the
purposes of eliciting a better understanding of social (and organisational) processes and
for predicting alternative courses of action. Therefore, in MABS studies, MAS is seen as
a tool for making and testing theories, rather than applications (as recommended in
Conte et al. 1998). For this purpose, MAS is used as the modelling paradigm, that is, t o
create the model structure (as suggested in Edmonds, 2000). The advantages of using
MAS as a modelling paradigm include: the achievement of greater descriptive accuracy
and precision of the models; greater contingency in inference; and a greater variety of
possible models. Some of the reported disadvantages include: more difficulty in inferring
general results; and the analysis and interpretation stages of the modelling process require
much more attention than in simple deterministic or stochastic mathematical models
(Edmonds, 2000). In MABS the implementation of software can be seen as a means t o
an end (the end being the generation of theory). Conte et al. (1998) frame the subtle
difference between MAS and MABS as follows:
“…If the MAS field can be characterised as the study of [or implementation of] societies of artificial
autonomous agents, agent-based social simulation can be defined as the study of artificial societies of
autonomous agents” (page 3).
Conte et al. (1998) also argue that despite their evident affinities, the two fields have
suffered and still suffer from an inadequate interface; and that more cross-fertilisation
between MAS and MABS research is needed with some expected positive consequences of
this interaction. This work can be considered a small step in that direction.
There is a growing body of literature dedicated to new developments in agenttechnology theory and practice (Luck et al. 2001; Bach et al. 2000; Florez-Mendez,
1999; Petrie, 2001; Iglesias et al. 1999; Wooldridge and Jennings, 1999; Huhns, 2000;
Laufmann, 1999). On the other hand, there is also a more sceptical body of literature
that is less optimistic about what societies grown ‘in silico’, that is, artificially, can
actually teach us about the real world (see for example, Lansing, 2002).
The growth of interest in software agent technology throughout the 1990s has gone
hand-in-hand with the growth of the Internet (Huhns, 2000). The Internet provides an
open environment where agents can interact with each other to reach their individual or
shared goals (Florez-Mendez, 1999). MAS are already being seen by some as the next
software engineering paradigm and a possible solution to the current problems of the
practice of software development experienced by organisations (see Huhns, 2000;
Wooldridge and Jennings, 1999; Jennings, 1999). This problem can be best summed up
by Avgerou and Cornford (1993) who state that there is “still a feeling that the essence
of good practice in bringing technology to bear on information handling problems in
organizations eludes us” (page 279). As a result, MAS researchers invest time and effort
into developing communications languages, interaction protocols, and agent
architectures that facilitate the development of these systems (see Sycara, 2002). For
recent examples of industrial applications of MAS see Bach et al. (2000), Luck et al.
(2001), and Owen et al. (1999).
However, despite the expectation that MAS may lead to improvements in
engineering complex, distributed systems (see Bergenti et al. 2002) recent research
suggests that more effort needs to be devoted to understanding the pragmatics of
engineering such systems (Wooldridge and Jennings, 1999; Laufmann, 1999). For
6
example, current methodological approaches have been criticised for failing to capture
adequately an agent’s flexible, autonomous problem-solving behaviour, the richness of an
agent interactions, and the complexity of an agent system organisational structure (see
Wooldridge et al., 1999; Iglesias et al. 1999). A similar situation is occurring within the
MABS field. In the section that follows, current thinking with regards to tools and
methods/approaches for implementing MABS is discussed in further detail.
4
Current Approaches to Multi-agent Model Building and Evaluation
Since MABS is still a young area of study, there is a marked lack of agreement
regarding approaches, techniques and tools on “how to do” MABS (Gilbert and Bankes,
2002; Edmonds, 2000; Conte et al. 1998; Moss, 2000; Florez-Mendez, 1999; Petrie,
2001). Instead, many competing techniques exist (Bourge, 2002). But, as argued in
Edmonds (2000), one of the problems with the MABS field is that (apart from some
exceptions) there is very little work that builds on, compares or repeats other work; also
as a generalization, the field spends far too little effort on the later stages of the
modelling process (shown in Figure 1).
The more traditional ways of doing MABS (that is, ‘researcher-centred’) have also
been criticised for the essentially passive role played by some relevant stakeholders
throughout the stages of the simulation research life cycle in Figure 1. Stakeholders are
understood here as anyone with a direct or indirect stake in the MABS project. As such,
stakeholders may be researchers, management and decision-makers in organisations,
policymakers (or their representatives), end-users of ‘games’ designed during a MABS
project for a particular purpose, etc. Addressing stakeholders’ needs and wants
effectively in future MABS approaches is important, because although still in its infancy,
user-centred simulation is currently a booming area of research in both academia and
practice (see for example, Bonabeau and Meyer, 2001; Thesen and Travis, 1997). Usercentred MABS allows stakeholders (e.g. in businesses) to rerun decisions made under
differing scenarios and environmental and strategic conditions. This provides support for
decision making in a relatively cost effective way (see Wickenberg and Davidsson,
2002).
On the other hand, there is also an increasing body of literature dedicated to finding
new directions for MABS approaches (see for example, David et al. 2002; Marietto et al.
2002; Jager and Janssen, 2002) and MAS approaches (see for example, Bergenti et al.
2002). However, in both MABS and MAS current methodological directions there seems
to be an implicit assumption that no matter how complex human actions, behaviour and
interactions are, these can eventually be simplified and represented in algorithmic form
(e.g. software agents). But, in reality, as Penrose (1989) argues: “…beneath all this
technicality is the feeling that is indeed ‘obvious’ that the conscious mind cannot work
like a computer, even though much of what is actually involved in mental activity might
do so” (page 580). As such, it may be better to see agent-based simulations as a way of
thinking about social phenomena rather than as information about the social
phenomena (see Conte et al. 2001).
Something else that becomes evident upon examination of the MABS literature is the
proliferation of heterogeneous architectural and technical agent-based platforms (such as
CORMAS, Swarm, etc.). Although this can be thought of as being symptomatic of a
young maturing field of research, on the other hand, as Marietto et al. (2002) argue, this
does not necessarily facilitate the work of researchers and therefore efforts to integrate
and systematize the diversity of choices open to researchers are required. Furthermore,
in many multi-agent based projects “…valuable time (and hence money) is often spent
7
implementing libraries and software tools that, in the end, do little more than exchange
KQML-like messages across a network” (Wooldridge and Jennings, 1999, page 24).
Given the issues discussed thus far, it is argued that further research into novel MABS
approaches is needed that takes into consideration the following: a) lessons learnt from
previous MABS research projects; b) advances in the neighbouring field of systems
(software) engineering methods; and c) effective stakeholder involvement throughout all
of the stages of MABS projects. In the sections that follow, these three areas are further
elaborated upon (culminating with a proposed MABS approach in section 8). Therefore,
the next section (section 5) adopts an ‘inductive’ approach by examining ‘histories’ of a
representative range of actual projects, synthesising those aspects that seem to work and
that could be potentially applied to future MABS projects. This is followed by sections 6
and 7 which draw from rational analysis and practice of systems (software) development,
and participatory simulations, of researchers currently working on the Simweb project, in
order to recommend approaches/techniques that ‘ought’ to work.
5
Lessons from Previous Multi-agent Based Social Simulation Projects
In this section, the results of the review of a number of previous relevant MABS studies,
is presented. The aim of this review was to identify valuable methodological lessons that
would shed some light into what is needed in future MABS approaches. The studies
presented in table 1 were chosen for the timeliness and importance of their topics to the
field of social simulation, and for providing more detailed descriptions of (and in some
cases even lessons derived from) the simulation steps covered.
AUTHORS
DOMAIN
PROJECT (S)
MAS Platform
ACRONYM (S)
Simulation steps
covered
(from figure 1)
D’Aquino et al.
Ecosystem Management
(2002)
SHADOC;
CORMAS
All of them
PHP, PostgreSQL,
Conceptualisation
Apache, Javascript, email
through to
Stratagenes;
Sylvopast;
Mejan;
SelfCormas
Gilbert et al. (2002)
Renewable Resource
FIRMA
Management (Water)
Publication
8
Purnomo et al.
Renewable Resource
(2002)
Management (Forests)
-
CORMAS
Conceptualisation
through to
Publication
Table 1. MABS Studies Reviewed for Methodological Clues.
The studies in table 1 above cover most aspects of the simulation life cycle shown in
Figure 1. These studies were systematically scanned for relevant build and evaluation
aspects (or issues). Other supporting related literature addressed included: Parunak et al.
(1998); Terna (1998); Kearney and Merlat (1999); Eymann (2000); Owen et al. (1999);
and Parker and Swatman (1999). The main conclusion that can be drawn from this
literature review for the purposes of this paper is that MABS approaches need to allow
for iteration, collaboration and exploration of alternative scenarios/situations. The rest
of this section summarises in more detail observations derived from this review under the
headings: ‘generic considerations’; ‘conceptualisation/design considerations’;
‘build/verification considerations’; and ‘evaluation (or validation)/publication
considerations’.
Generic Considerations
-
Agent-based simulation seems most appropriate for domains characterised by a
high degree of localisation and distribution and dominated by discrete decisions
(e.g. decentralised business processes). In this respect, agent-based simulations
appear to have several advantages over other methods (such as systems dynamics).
These include: easier construction; additional levels of validation (that is, at the
system as well as the individual level); more support for direct experimentation
(by offering stakeholders the chance to play “what-if” games); easier to translate
back into improved business practices; and an intrinsic model of space (e.g.
physical and interaction space) which other simulation methods do not have at all.
-
MAS and role-game simulations are useful in the exploration of scenarios involving
multiple stakeholders.
-
Effective communication between stakeholders (where applicable) is key for
collaboration throughout all of the stages of MABS projects. However,
stakeholders need to be aware of the implications of varying cost arrangements
and the existence of tangible and intangible benefits of cooperating from the start.
-
Lack of motivation can result in stakeholders losing interest or even dropping out
of a MABS project. A good structure, organisation and a certain degree of
formality of activities have been found to be contributing factors to stakeholder
motivation throughout MABS projects. During role-playing/gaming activities for
example, the focus needs to be on achieving a balance as Barreteau et al. (2001)
argue: “…between the extremes of a ‘stage’ play (if the sessions are too slow, or
the players too neutral), and too much uncontrolled drift…”(page 5). Other
factors favouring motivation reported in the literature include: good time
management; and a fundamental desire to learn among stakeholders.
- MABS projects are iterative and interactive endevours. Achieving the ‘right mix’
of stakeholders for these projects is said to be important. For example, it is
advisable to select carefully the stakeholders for game/role-playing sessions; during
validation of the MAS; model presentations; collective discussions about
enhancements, etc. Stakeholder/player homogeneity needs to be taken into
9
account too, as the mixing of superiors and subordinates may at times be
problematic.
Model Conceptualisation/Design Considerations
- Generally speaking, during the design (and also during the validation) phases of
simulation projects, there can be a number of potential sources of biases introduced
by the various stakeholders involved (i.e. designers, decision-makers, etc.) as a
result of data problems, overconfidence, carelessness in the design process, etc.
This can have an impact on the outputs of the simulation/gaming tasks. Listed in
Irvine et al. (1998) are 29 possible sources of what the authors call: “judgemental
biases” for stakeholders to be aware of. These authors group their numerous
sources into three main categories, namely: 1) biases related to data (e.g. adjusting
and anchoring; availability; conservatism; data saturation; spurious cues, etc.); 2)
biases related to decision-makers (e.g. desire for self-fulfilling prophecies,
expectations, fact value confusion; habit; hindsight, wishful thinking, etc.) and, 3)
decision-maker use of data (data presentation context, law of small numbers,
representativeness, etc.). For more detailed descriptions and advice on how t o
manage these different types and signs of bias see Irvine et al. (1998).
- In the design of Internet-mediated simulations (e.g. games) aspects such as:
synchronicity (of play), support for technical or training problems, security
(copyright, passwords, login names) and communication (sensitivity to cultural
and language differences, sharing of sensitive data/information), are important for
designers to consider. With regards to synchronicity, decisions regarding for
instance, how participants in different locations and time schedules will play with
each other (e.g. over the Internet, or via video-conferencing, or person-to-person,
etc.) need to be made early.
Model Build/Verification Considerations
-
The use of high level, structured programming tools seems to make it possible t o
publish simulation results in a more useful way. This can be seen as especially
relevant for replication purposes (discussed in section 2). It has been said that the
goal of these high level tools (e.g. SWARM), is to bring simulation (software)
writing to a higher level of expression, writing applications with reference to a
standard set of simulation tools (see Terna, 1998).
- Using programming languages such as JAVA and running the resulting simulation
software as applets on client machines may place great demands on these
machines and make maintenance of the code much harder. With recent Webenabled languages (such as PHP) that makes it easy to generate web pages
dynamically, all the code remains on the server. This can have advantages for
inter-player communication during gaming simulations, for example, because all
players’ actions are stored on the server for later analysis.
- Another tool that has been used for building multi-agent based applications is XML
(Extensible Mark-up Language) defined by the W3C (World-Wide Web
Consortium). XML has been described as an open standard for the representation
of information that can be both processed by machines and read by people. It is
said to support data representations for example, in a way that is generic enough
and yet sufficiently feature-rich to allow for a range of concepts to be modeled. I t
also allows information to be stored in structured files and ported across different
10
platforms, and, in doing so, it can alleviate many of the problems facing
distributed systems when addressing interface-type issues.
Model Evaluation/Publication Considerations
- There can be significant differences between simulation results and reality. This
can be due to software errors but also to omission of key (social) aspects during the
initial conceptualization/modelling stages of the MABS project.
- The potential for undesirable as well as desirable results in multi-agent based
simulations has also been said to be a side-effect of ‘emergent’ behaviour. That is,
system behaviour that arises as a result of interactions between the (at times
unpredictable) behaviour of the system components. This latter aspect contributes
to the view often found in the literature that agent based social simulation/gaming
remains more an art than a science.
- The Internet provides a useful forum for stakeholders to explore and learn about
implemented models and to share perspectives and insights with each other. For
example, the Web/Internet, can be an effective resource for distributing software
and documentation (e.g. user manuals) to stakeholders involved in simulations.
Documentation which places emphasis on a step-by-step, rather than an
explanatory approach, can reduce the time and costs associated with the conduct
of activities such as training, briefing/debriefing, role-playing, and dissemination of
results. The materials should be as simple as possible. Use of email as a tool for
communication and as substitute for certain types of detailed documents has also
been found to be effective. However, despite the benefits of using the Web,
stakeholders continue to favour face-to-face communication, particularly for
situations such as game briefing/debriefing activities.
6
Methods Derived from Software Engineering
Systems (software) engineering methods (or methodologies) are very important to the
field of MABS. This because, embedded in both - the MABS research process (in figure 1)
and most known software engineering methods – is an approach known as the software
life cycle (or SLC). The SLC is the universally accepted paradigm for software
development is comprised of the generic steps ( o r
phases) of:
‘conceptualisation/specification’, ‘design’, ‘development’, ‘testing’, ‘implementation’
and ‘maintenance’ (see Pressman, 1994).
But, the software life cycle dates back to the necessary reductionist approach of
scientists involved in World War II computing projects, where the problems addressed
were highly deterministic. The solutions were also strongly linked to the (limited)
hardware capabilities of the time (Agresti, 1986). As such this paradigm has been
criticized for being too ‘hard’ for the creation of modern ‘softer’ human activity
systems (Checkland and Scholes, 1990). That is, the approach tends to ‘sweep under the
carpet’ the many ambiguities of social (and organisational) life (Walsham, 1993). Hence,
debates regarding the usefulness of current software engineering methods for the
production of more contemporary systems with heightened social, organisational,
cultural, political and public policy implications continue in the field of systems
engineering (further details on this topic can be found in Ramanath, 2000). Meanwhile,
11
as the pace of change in organisations accelerates at a global level in the last decade,
methodologies have emerged which have shifted the focus of attention to ‘speed’ (or
productivity) of software development efforts. Examples of these are RAD, RUP, XP,
Agile Modeling, etc.
Our own stance here is that until alternative paradigms to that of the SLC approach
emerge, the use of techniques drawn from known software development methods can
contribute to a more disciplined, systemic approach to MABS projects. On the other
hand, the use of such methods alone may not be enough to render a simulation project
‘successful’, and hence prevent MABS projects from the pitfalls discussed in section 2
(from Thesen and Travis, 1995). There may be several other contributing factors (such
as researchers’ experience, cogency of analysis, etc.) but their discussion is outside of the
scope of this paper.
For the purposes of this paper, we were interested in state-of-the-art, well-known
software engineering approaches which would enable at least two of the three key aspects
identified as needed in MABS approaches in the previous section. These two aspects are:
iteration and collaboration. It is argued that with regards to the third aspect previously
identified, that is, e x p l o r a t i o n through analysis/evaluation of alternative
scenarios/situations, scientific techniques drawn from the social sciences may be more
suitable (such techniques are described in section 7). The rest of this section describes two
well-known approaches constituting recent attempts at improving the process and
outcomes of software engineering projects. These are the Rational Unified Software
Process (RUP) and Extreme Programming (XP). Both of these were examined in the
search for techniques that may be useful for our proposed MABS approach (to be
discussed in section 8).
RUP
The Rational Unified Process (RUP) provides a disciplined approach to software/systems
engineering in organisations. Its goal is to ensure the production of high-quality software
that meets the needs of its end-users, within a predictable schedule and budget. The main
purpose of a methodology like RUP is to enhance team productivity, by providing every
team member with easy access to a knowledge base with guidelines, templates and tool
mentors for all critical development activities. By having all team members accessing
the same knowledge base, it is ensured that all team members share a common language,
process and view of how to develop software (see Ericsson, 2000).
The RUP is a process product, developed and maintained by Rational® Software. The
RUP is supported by tools, which automate large parts of the process. They are used t o
create and maintain the various artefacts – models in particular – of the software
engineering process: visual modelling, programming, testing, etc. The RUP is also a guide
for how to effectively use the Unified Modeling Language (UML). The UML is an
industry-standard language used to communicate requirements, architectures and designs.
The UML was originally created by Rational Software, and is now maintained by the
standards organization Object Management Group, or OMG (see Ericsson, 2000; Hunt,
2000). The RUP is a specific and detailed instance of a more generic process described by
Ivar Jacobson, Grady Booch, and James Rumbaugh in the textbook, The Unified Software
Development Process (Rational Software, 1998; Hunt, 2000).
In the RUP methodology, the software lifecycle is broken into cycles, each cycle
working on a new generation of the product. The Rational Unified Process divides one
development cycle in four consecutive phases. These are: ‘inception’, ‘elaboration’,
12
‘construction’ and ‘transition’. Each of these phases has a specific purpose and is
concluded with a well-defined milestone, a point in time at which certain critical
decisions must be made and therefore key goals must have been achieved.
Overall, the philosophy and structure of the RUP methodology makes it a good
candidate from which to draw techniques and guidelines for our proposed MABS
approach (in section 8). This, because the methodology is: a) iterative and incremental;
b) object-oriented; c) managed and controlled; and d) generic enough to be tailorable to a
wide variety of software products and projects both in size and application domain (see
Krutchen, 1996). However, this methodology has also been criticised for being
heavyweight. This means that it seeks to drive out risk, and as such is very
comprehensive in its techniques, tools and guidelines which may at times make it
unsuitable for projects with shorter life cycles and tight deadlines (see for example,
Smith, 2001).
XP
Extreme Programming (XP) is also a recent methodology but it takes almost the
opposite view to that of the RUP (i.e. higher risk, shorter development life cycles,
lightweight). XP has been described as a deliberate, disciplined approach to software
development, aimed at risky projects with dynamic requirements, with customers (endusers) being partners in the software process, and software developers actively
contributing regardless of experience level (see Wells, 2001). XP is about six years old
and its origins are attributed to the experiences of Kent Beck and Ward Cunningham in
industrial projects. The methodology is said to rest upon four dimensions along which
one can improve any software project. These are: communication; simplicity; feedback
and courage. Although XP resembles (like RUP) the incremental, spiral approach t o
software development advocated by Boehm (1988), it does not seem to be phase driven
in the traditional sense (as the RUP phases mentioned in the previous subsection).
Rather, XP follows a number of “rules and practices” as shown next (extracted from
Wells, 2001):
Planning
Coding
User stories are written.
Release planning creates the schedule.
Make frequent small releases.
The Project Velocity is measured.
The project is divided into iterations.
Iteration planning starts each iteration.
Move people around.
A stand-up meeting starts each day.
Fix XP when it breaks.
The customer is always available.
Code must be written to agreed standards.
Code the unit test first.
All production code is pair programmed.
Only one pair integrates code at a time.
Integrate often.
Use collective code ownership.
Leave optimization till last.
No overtime.
Designing
Testing
Simplicity.
Choose a system metaphor.
Use CRC cards for design sessions.
Create spike solutions to reduce risk.
No functionality is added early.
Refactor whenever and wherever possible.
All code must have unit tests.
All code must pass all unit tests before it
can be released.
When a bug is found tests are created.
Acceptance tests are run often and the score is
published.
For further details about the rules and practices of XP, please refer to the XP web site
at: http://www.extremeprogramming.org. For further details of the phases and
13
deliverables of RUP please refer to: www.rational.com. Further, useful comparisons
between XP and the Unified Process can be found in Ambler (2002).
7
Methods for Stakeholder Exploration/Evaluation from Social Sciences
Participation has roots in scientific disciplines such as: political science, anthropology,
sociology, psychology, philosophy, social geography and business/management sciences.
Participation is said to be an essential pillar of integrated assessment (IA), that is, the
interdisciplinary process of combining, interpreting and communicating knowledge from
different disciplines and knowledge domains to allow a better understanding of complex
phenomena (van Asselt et al. 2001). For the purposes of this paper, IA and participatory
evaluation can be considered synonymous.
Participatory methods have been defined as methods to structure group processes in
which non-experts play an active role and articulate their knowledge, values and
preferences for different goals (see van Asselt et al. 2001 page 8). Two examples of
participatory methods found relevant for this discussion, because they are generic enough
to be applicable to a range of different MABS projects, are described below:
a) Scenario Analysis: is an interactive process engaging a group in a process of
identifying key issues, creating and exploring scenarios, in order to learn about
the external environment and/or integrating the insights into the decisionmaking of the organisation. The free-format approach enables the exchange and
synthesis of ideas and encourages creative thinking.
b) Participatory Modelling: also known as ‘group model building’ refers to the
active involvement of model-users in the modelling process. There is a
difference to the extent to whether the participants are really modelling creating
the model, or whether the participants provide input to the modelling endeavour.
In some cases, the aim is to build a conceptual model, sometimes facilitated by
visualisation software, while in other cases, the goal is to develop a computer
model. Participatory modelling thus refers to the whole spectrum of developing
simple conceptual models to building complex computer models.
It is acknowledged, however, that there exist several other participatory methods
(e.g. focus groups) which may be more relevant in certain situations. As previously
discussed, ultimately, MABS researchers will make informed methodological choices for
their projects depending upon their level of experience, preferences and above all
relevance to the topics studied. For a comprehensive summary of participatory methods
commonly used in social sciences the reader is referred to van Asselt et al. (2001).
8
A Suggested Approach to Multi-agent Model Building and Evaluation
Based on the aspects discussed thus far, this section introduces an approach that takes
into account the findings of previous empirical studies of MABS, the active role to be
played by stakeholders in the more participatory types of MABS projects -like Simweband also current developments in the neighbouring field of systems (software)
engineering methods. Table 2 presents initial thoughts in this respect. Included in table 2
are also some relevant object-oriented (OO) analysis and design techniques from the OO
literature.
It is acknowledged that time and other resource constraints may make it difficult to
employ all of the techniques in table 2 during the lifetime of MABS projects (such as
14
Simweb). Also, because there is a degree of overlap between some of these techniques, it
is important that this commonality is identified. This will ensure that any unnecessary
duplication of tasks in kept to a minimum.
Following the decision making process of selecting a set of techniques for any given
MABS project, this will need to be reflected in the project plan(s). A discussion of
project management aspects of MABS projects is outside of the scope of this paper. The
issuing of prescriptive guidelines regarding the number of people and time scales required
for the various techniques/tasks listed in table 2 is outside of the scope of this paper also.
This is partly because the methods themselves do not offer definitive guidelines in this
area, but also as the literature reviewed for this purposes suggests, this is something for
every project team to decide depending on the circumstances of their project.
An important aspect to consider in using a set of methods/techniques for MABS, are
practical design issues. To this respect, the participatory, software engineering and
simulation literature reviewed offer extensive advice regarding aspects such as: logistics
and physical facilities for meetings/workshops; recruitment of participants; description
of the tasks and roles of participants and facilitators; planning of meetings/sessions;
supporting materials; expected outputs of the process and data collection techniques (e.g.
audio taping, video taping, transcripts, etc.)
From Social Sciences, Software Engineering, and Agent-
MABS Phases (from figure 1)
based Simulation Literature
Approaches
Participatory-based (e.g.
Scenario Analysis and
Participatory Modelling)
Techniques/Tasks
Conceptualisation
Design
Construction &
Evaluation &
Verification
Validation
¸
- Brainstorming and scenario
¸
workshops
¸
- Co-design with user community
¸
¸
- User Panels (inc. videorecording, debriefing, etc.)
Object-oriented based
¸
- End-user Workshops
¸
(e.g. joint requirements
planning and joint analysis
and design)
XP-based
- Stakeholder Interviewing
¸
- Prototyping
¸
- User Stories
¸
- Prototyping
¸
¸
¸
¸
¸
¸
¸
¸
- Paired Programming
RUP-based
- Use-Case Modeling
¸
¸
- Prototyping
¸
¸
¸
¸
Table 2 Possible Approaches/Techniques for MABS Projects.
In the paragraphs that follow a discussion of the techniques listed in table 2 is
presented. This is preceded by figure 2 below which links the contents of table 2 to the
various phases of MABS projects. The faster, iterative and prototyping character of XP
combined with the more thorough techniques of RUP for software modelling may prove
useful in delivering simulations in shorter than accustomed to cycles within MABS
15
projects. At present most of the techniques shown in figure 2 are being tried out within
the Simweb (MABS) initiative with some positive preliminary results.
Some
Suggested
Techniques:
_Brainstorming
_Scenario Workshops
_JRP Workshops
_Stakeholder
Interviews
_Prototyping
_User Stories
_Use-case Modelling
etc.
_User Co-design
_JAD Workshops
_Prototyping
_Use-case Modelling
etc.
_Prototyping
_Paired
Programming
Research
questions/
Observations/
Literature
Conceptualisation
Performance/
Usability
Prototypes
_User Requirements
_Key Features
_Constraints
_Evaluation Criteria
Design
Pilot Models/
Components
Library
_Functional
Design
_Technical Design
_Unit, System &
User Test Cases
Construction
& Verification
etc.
Preliminary
Models/Tools
_Brainstorming
_Scenario
Workshops
_User Panels
etc.
_Test Results
_Tech/User
Documentation
Evaluation
& Validation
Enhanced
Models
End of Project
16
_User Feedback
_ Publications
Figure 2 Proposed Generic Approach to MABS Projects.
8.1
Potentially Useful Techniques for MABS Projects
Brainstorming and Scenario Workshops
The first step in the process of scenario analysis is the identification of key issues or
questions relevant to the organisation(s) (or project) and the time frame associated with
the focal issue(s). This is followed by, brainstorming exercises to surface ideas associated
with the relevant issues. The exercise is meant to be creative, and for this reason, rules
such as that no idea is immediately disparaged or discarded are applied. The involvement
of decision-makers in the scenario creation and exploration process may be limited to a
single interview, but it can also involve participating in several workshops that may run
for several days at a time. These ‘scenario workshops’ may or may not involve the use
of software (e.g. prototypes) as a facility for group support (see van Asselt et al. 2001).
Those authors offer guidelines for arriving at scenarios during these workshops. They
also recommend that participants in these workshops include people with a thorough
knowledge of the organisation(s) concerned and/or the issues to be addressed, and often
people from different levels of the organisations’ hierarchy if possible. Those authors
recommend as a follow up to the workshops (or interviews) a period of reflection,
writing up the scenarios and exploring their implications.
The use of scenario analysis has traditionally been for planning and/or strategic
decision support purposes (van Asselt et al., 2001). Therefore, it is envisaged that the
process of scenario creation and exploration would be most suitable during the
conceptualisation and evaluation phases of MABS projects (like Simweb). During
conceptualisation, scenario analysis may be used for the purposes of refining (and
scoping) the definition of the problem and user requirements, for example, the planned
European seminar on ‘Practice and trends in the digital contents market’ may be
considered an instance of a ‘scenario workshop’. During evaluation, scenario analysis
may be used in the form of round–table discussions with users for example, in order t o
help them elucidate plausible, innovative alternative futures based on the results of many
simulation runs.
Co-design with User Community
Participatory modelling approaches and techniques are said to stem from system
dynamics, where the modelling part functions as a tool in a broader group process. The
idea behind it is that people have difficulty viewing the ‘whole’. A system’s point of
view is helpful to ‘lift’ team members to the system’s level and to create a holistic view
in a team (van Asselt et al. 2001). Participatory modelling also recognises that model
building is an inherently ‘subjective’ process. As such, soliciting input from all the
interested parties involved and reaching consensus are seen as essential components in
‘group-model-building’ processes.
Costanza and Ruth (1998) cited in van Asselt et al. (2001) suggest a three-step
modelling process to ensure that the user community co-design crucial choices in the
model:
17
a) To develop the basic model structure and to make functional connections about
the variables. Here consensus building and involving a broad representation of
stakeholder groups affected by the problem, is essential.
b) To make more detailed and realistic attempts to replicate relevant dynamics of
the system. Stakeholder involvement and interaction at this stage is still critical
and takes place through the exchange of models and with regular workshops and
meetings to discuss model progress and results.
c ) The production of scenarios and management options based on the earlier
scoping and research models.
Within Simweb, for example, it is envisaged that the business organisations involved
will play a significant role as day-to-day co-designers of the online news and online music
sector models during the design phase. The use of software prototypes to aid
communication between users and developers and to speed up the software
implementation of the models, is also expected.
End-user Workshops and Stakeholder Interviewing
The field of software engineering and more recently the sub-field of object oriented
analysis and design offer extensive guidelines/techniques for the elicitation and sharing of
relevant information amongst stakeholders involved in software/systems projects. Two
techniques that may be useful for MABS projects are JRP (Joint Requirements Planning)
and JAD (Joint Application Design). These are group-based workshops carried out during
the software conceptualisation and design phases, respectively. The use of prototypes
for the purposes of accelerating results is actively encouraged in the literature. Both JRP
and JAD stress the importance of a skilled facilitator (the person who runs them).
Amongst other things, facilitators are expected to have excellent communication skills,
be impartial, unbiased and neutral, good at conducting meetings, and good also at
negotiating skills, sensitive to politics and diplomatic.
JAD workshops typically last three to five days. JRP workshops vary in length
depending on the complexity or newness of the requirements. They typically range from
one to three days. Guidelines on how to set-up and conduct JRP and JAD sessions,
including sample agendas/questions for meetings are explained in detail in Martin and
Odell (1996). When issues come up during the workshops that cannot be resolved, those
authors recommend that the problem is declared an open issue, and that a scribe (or
note-taker) should note the following: issue number, issue name, person assigned t o
resolve the issue; date for resolution and description.
The above authors also offer detailed guidelines (including sample questions) for the
purposes of face-to-face stakeholder interviewing. These interviews are carried out
mainly for requirements elicitation. But, whatever route is chosen (i.e. stakeholder
interviewing or group-based requirements and design workshops, or both), the emphasis is
on involving relevant people early on in the development process as this is expected t o
increase the chances of project success.
User Stories
This technique would appear suitable for the conceptualisation phase of MABS projects.
User stories are said to serve the same purpose as use cases (in RUP) but are not the
same. They are used to create time estimates and also as substitutes for large
requirements documents. They tend to be written by end-users/customers as things that
the system needs to do for them. They are in the format of about three sentences of
18
text written in the customers’ terminology. As such a further difference between stories
and a lengthy requirements document is, as the XP advocates claim, a focus on user
needs. That is, details of specific technology, data base layout, and algorithms tend to be
avoided as stories focus on user needs and benefits (as opposed to specifying GUI layouts
and other technical requirements, for example). User stories are also used to drive the
creation of test specs for user acceptance testing.
Use-Case Modeling
A use-case represents one way in which the system (or software) can be used by an actor.
An ‘actor’ can be anything that interacts with the system: a human user, another
computer system, a dumb terminal, a sensor, a device to be controlled, etc. (Hunt, 2000).
The collection of all the use cases for a system defines the functionality of that system.
Use cases possess: a) a sequence of actions performed; b) an optional set of one or more
alternative sequence(s) of actions; c) a brief description of the purpose of the use case; d)
communications with one or more actors, and e) constraints on their use (see Hunt,
2000).
This technique is recommended during the initial stages of software development. In
Simweb, these would correspond to the conceptualisation and design phases. RUP offers
powerful visual modelling tools such as the Rational Rose software product for these
purposes. For projects which cannot afford such tools, the related Unified Software
Process (of which RUP is a variant) literature, and the Unified Modeling Language
(UML) literature offer a wealth of examples and advice.
Prototyping
Prototyping is a technique for building a quick and (if need be) rough version of a desired
system or parts of a system. The prototype illustrates the system to users and designers
and also allows them to see flaws and invent ways to improve it (Martin and Odell,
1996). This technique exists in various guises in software methods. In XP for example it
is called ‘architectural spike’ or ‘spike’. In RUP it is referred to as ‘executable
architectural prototype’. In object-oriented approaches it is recommended that
prototyping be used in JAD workshops with users, and so on. But, in essence the majority
all of the approaches included in table 2 encourage the use of prototyping throughout the
project life cycle.
In Simweb, it is envisaged that an initial prototype will be required during
conceptualisation for the purposes of selecting the appropriate software platform for
the project (see State-of-the-art of software tools for agent-based simulation document
at: http://www.simdigital.com). The construction of the simulation software will be done
in incremental stages and with considerable user input. That may imply that the initial
prototypes could evolve into the final simulation software.
Paired Programming
This technique forms part of the overall philosophy of ‘collective code ownership’
within the XP methodology. Paired programming may be useful during the construction
phase of MABS depending on resources available. Paired programming is explained in
Wells (2001) as follows: “All code to be included in a production release is created by
two people working together at a single computer. Pair programming increases software
quality without impacting time to deliver. It is counter intuitive, but 2 people working at
a single computer will add as much functionality as two working separately except that it
19
will be much higher in quality. With increased quality comes big savings later in the
project. The best way to pair program is to just sit side by side in front of the monitor.
Slide the keyboard and mouse back and forth. One person types and thinks tactically
about the method being created, while the other thinks strategically about how that
method fits into the class. It takes time to get used to pair programming so don't worry
if it feels awkward at first”.
User Panels, Video-recording, De-briefing
The Freshwater Integrated Resource Management with Agents (FIRMA) project (see
http://www.cpm.mmu.ac.uk/firma) has used panels of stakeholder representatives t o
evaluate design proposals and this is a technique that may also be useful for many MABS
efforts. Potential users of the simulation software are gathered around a table and the
software is demonstrated to them. The panel is then asked to discuss it, and the resulting
interaction is videotaped for later analysis. The approach is similar to using a focus
group (and the procedures for running the panel are also similar), but the difference that
the group is responding to the software as a ‘stimulus’ for their discussion. A similar
format can be used for de-briefing sessions when several users have tried the software – it
is better to have group de-briefing sessions than individual ones.
It is envisaged that this technique may be useful during the evaluation phase of MABS
projects because the comments from users are likely to be much more revealing and
helpful than could be obtained from, for example, a structured evaluation form.
9
Conclusion
This paper has offered an initial set of techniques and ideas for the development of
agent-based social simulation. It has done this by drawing on the extensive literature on
methodologies to be found within the field of software engineering and on the much rarer
accounts of how existing social simulation models were developed. The proposals in the
paper must, however, be regarded at this stage as hypotheses: it seems plausible that
adopting some of these techniques could enhance the quality and effectiveness of social
simulation models, but we as a community do not yet have enough experience and have
not yet devoted sufficient effort to recording and synthesizing that experience to be sure
that these techniques do work as we might expect. In this respect, this paper is merely a
start and much remains to be done if we are to understand clearly how to build agentbased models so that we are able to pass on our expertise to those who come after.
20
10
References
Agresti, W. (1986). The Conventional Software Life-cycle Model: Its Evolution and Assumptions. In
Agresti W. (Ed.). New Paradigms for Software Development, Tutorial, IEEE Computer Society Press, pp. 2-5.
Ambler, S.W. (2002). Agile Modeling: Effective Practices for Extreme Programming and the Unified
Process. Wiley, New York.
Avgerou, C. and Cornford, T. (1993). A Review of the Methodologies Movement. Journal of Information
Technology, Vol. 8, No. 4, pp. 277-286.
Axelrod, R. (1997). Advancing the Art of Simulation in the Social Sciences. In Conte, R., Hegselmann, R.
and Terna, P. (Eds.). Simulating Social Phenomena, Lecture Notes in Economics and Mathematical Systems,
pp. 21-40.
Bach, J., Janning, F. and Schulz-Schaeffer, I. (2000). Multi-Agent Systems in Hybrid Organizations. A Case
Study on the Design of Information Systems in Hospitals, a t : http://www.informatik.huberlin.de/~bach/publication/Sozionik1.pdf.
Barreteau, O., Bousquet, F. and Attonaty, J-M. (2001). Role-playing Games for Opening the Black Box of
Multi-agent Systems: Method and Lessons of its Application to Senegal River Valley Irrigated Systems.
Journal of Artificial Societies and Social Simulation, Vol. 4, No. 2, pp. 1-14.
Bergenti, F., Shehory, O. and Zambonelli, F. (2002). Agent Oriented Software Engineering Methodologies.
In: 4th European Agent Systems Summer School, EASSS, Bologna, Italy, 8-12 July 2002.
Birta, L. and Ozmizrak, F. (1996). A Knowledge-based Approach for the Validation of Simulation Models:
The Foundation. ACM Transactions on Modeling and Computer Simulation, Vol. 6, No. 1, pp. 76-98.
Boehm, B. (1988). A Spiral Model for Software Development and Enhancement. Computer, Vol. 21, No. 5,
pp. 61-72.
Bonabeau, E. and Meyer, C. (2001). Swarm Intelligence: A Whole New Way to Think About Business.
Harvard Business Review, Vol. 79, No. 5, pp. 107-114.
Bourge, C. Artificial Societies May Make Real Policy at: http://www.upi.com/print.cfm?StoryId=10052002045657-6167r
Checkland, P. and Scholes, J. (1990). Soft Systems Methodology in Action. John Wiley & Sons, Chichester.
Conte, R., Hegselmann, R. and Terna, P. (1997). Social Simulation – A New Disciplinary Synthesis. In Conte,
R., Hegselmann, R. and Terna, P. (Eds.). Simulating Social Phenomena, Lecture Notes in Economics and
Mathematical Systems, pp. 1-17.
Conte, R., Gilbert, N. and Sichman, J. (1998). MAS and Social Simulation: A Suitable Commitment. In
Sichman, J., Conte, R. and Gilbert, N. (Eds.). Multi-Agent-Based Simulation, First International Workshop,
MABS 1998, Paris, France, pp. 97-107.
Conte, R., Edmonds, B., Moss, S. and Sawyer, R. (2001). Sociology and Social Theory in Agent Based Social
Simulation: A Symposium. Computational & Mathematical Organization Theory, 7, pp. 183-205.
D’Aquino, P., Barreteau, O., Etienne, M., Boissau, S., Aubert, S., Bousquet, F., LePage, C. and Dare, W. (2002).
The Role of Playing Games in an ABM Participatory Modeling Process: Outcomes from Five Different
Experiments Carried out in the Last Five Years, at:
http://www.iemss.org/iemss2002/proceedings/pdf/volume%20due/192_daquino.pdf
David, N., Sichman, J. and Coelho, H. (2002). Towards an Emergence-Driven Software Process for AgentBased Simulation. In Sichman, J., Bousquet, F. and Davidsson, P. (Eds.). Multi-Agent-Based Simulation,
MABS 2002, Bologna, Italy, pp. 31-42.
21
Davidsson, P. (2000). Multi Agent Based Simulation: Beyond Social Simulation. In Moss, S. and
Davidsson, P. (Eds.). Multi-Agent-Based Simulation, Second International Workshop, MABS 2000, Boston,
M.A., pp. 97-107.
Doran, J. (1997). Foreword in Artificial Societies. In Conte, R., Hegselmann, R. and Terna, P. (Eds.).
Simulating Social Phenomena, Lecture Notes in Economics and Mathematical Systems, pp. 457-467.
Edmonds, B. (2000). The Use of Models – Making MABS More Informative. In Moss, S. and Davidsson, P.
(Eds.). Multi-Agent-Based Simulation, Second International Workshop, MABS 2000, Boston, M.A., pp. 1532.
Ericsson, M. (2000). Developing Large-Scale Systems with the Rational Unified Process at:
http://www.rational.com.
Eymann, T. (2000). Markets without Makers – A Framework for Decentralized Economic Coordination i n
Multiagent Systems. In: Electronic Commerce, Proceedings of the Second International Workshop
WELCOM 2001, Heidelberg, Germany.
Florez-Mendez, R. (1999). Towards the Standardization of Multi-Agent System Architectures: An Overview.
In ACM Crossroads, Special Issue on Intelligent Agents, Association for Computer Machinery, Issue 5.4,
pp. 18-24.
Foner, L. (1993). What’s An Agent, Anyway? A Sociological Case Study. Agents Memo 93-01, Agents
Group, MIT Media Laboratory, Cambridge, M.A. pp. 1-40.
Gilbert, N. (1996). Simulation as a Research Strategy. In Troitzsch, K.G., Mueller, U., Gilbert, N. and Doran,
J.E. (Eds). Social Sciences Microsimulation, Springer, Berlin, 1996, pp. 448-454.
Gilbert, N. and Bankes, S. (2002). Platforms and Methods for Agent-based Modeling, at:
www.pnas.org/cgi/doi/10.1073/pnas.072079499
Gilbert N. and Doran, J. (1994). Simulating Societies. UCL Press, London, 1994.
Gilbert, N. and Troitzsch (1999). Simulation for the Social Scientist. Open University Press, Buckingham,
U.K.
Gilbert, N. Maltby, S. and Asakawa, T. (2002). Participatory Simulations for Developing Scenarios i n
Environmental Resource Management. (forthcoming).
Goldspink, C. (2002). Methodological Implications of Complex Systems Approaches to Sociality:
Simulation as a Foundation for Knowledge. Journal of Artificial Societies and Social Simulation, Vol. 5,
No. 1, pp. 1-13.
Huhns, M. (2000). Agent Teams: Building and Implementing Software. IEEE Internet Computing, Vol. 4, No.
1, IEEE Computer Society, Los Alamitos, C.A. pp. 93-95.
Huhns, M. (2002). Agent Societies: Magnitude and Duration. IEEE Internet Computing, Vol. 6, No. 1, IEEE
Computer Society, Los Alamitos, C.A. pp. 79-81.
Hunt, J. (2000). The Unified Process for Practitioners: Object-oriented design, UML and Java. SpringerVerlag, London, UK.
Iglesias, C.A., Garijo, M. and Gonzalez, J.C. (1999). A Survey of Agent-Oriented Methodologies. In Muller,
J.P, Singh, M.P. and Rao, A. (Eds.). Intelligent Agents V (ATAL’98), LNAI 1555, Springer-Verlag, Berlin,
Germany, pp. 317-330.
Irvine, S., Levary, R. and McCoy, M. (1998). The Impact of Judgmental Biases on the Validation of
Simulation Models. Simulation and Gaming, Vol. 29, No. 2, pp. 152-164.
Jager, W. and Janssen, M. (2002). How to Develop Artificial Agents that are Useful in Improving
Understanding the Behaviour of Real Agents? In Sichman, J., Bousquet, F. and Davidsson, P. (Eds.). MultiAgent-Based Simulation, MABS 2002, Bologna, Italy, pp. 63-70.
22
Jennings, N. (1999). Agent-Oriented Software Engineering. In Proceedings of the 12th International
Conference on Industrial and Engineering Applications of AI, Cairo, Egypt, pp. 4-10.
Kearney, P. and Merlat, W. (1999). Modelling Market-based Decentralised Management Systems. B T
Technology Journal, Vol. 17, No. 4, pp. 145-156.
Kruchten, P. (1996). A Rational Development Process. Crosstalk, Vol. 9, No. 7, pp. 11-16.
Lansing, J. (2002). ‘Artificial Societies’ and the Social Sciences. Santa Fe Institute. Working Paper 02-03011, at: http:// www.santafe.edu/sfi/publications.
Laufmann, S.C. (1999). Toward Agent-Based Software Engineering for Information Access Applications.
AOIS’99 Position Paper at: http://www.aois.org/laufmann.html
Luck, M., Marik, V., Stepankova, O. and Trappl, R. (Eds.), (2001). Multi-Agent Systems and Applications.
Lecture Notes in Artificial Intelligence, 2086, Springer-Verlag.
Marietto, M., David, N. Sichman, J. and Coelho, H. (2002). Requirements Analysis of Multi-Agent-Based
Simulation Platforms: State of the Art and New Prospects. In Sichman, J., Bousquet, F. and Davidsson, P.
(Eds.). Multi-Agent-Based Simulation, MABS 2002, Bologna, Italy, pp. 92-103.
Martin, J. and Odell, J. (1996). Object-oriented Methods: Pragmatic Considerations. Prentice Hall, New
Jersey, U.S.
Moss, S. (1998). Social Simulation Models and Reality: Three Approaches. In Sichman, J., Conte, R. and
Gilbert, N. (Eds.). Multi-Agent-Based Simulation, First International Workshop, MABS 1998, Paris, France,
pp. 45-60.
Moss, S. (2000). Messy Systems - The Target for Multi Agent Based Simulation. In Moss, S. and Davidsson,
P. (Eds.). Multi-Agent-Based Simulation, Second International Workshop, MABS 2000, Boston, M.A., pp. 114.
Owen, M., Lee, L., Sewell, G., Steward, S. and Thomas, D. (1999). Multi-agent Trading Environment. BT
Technology Journal, Vol. 17, No. 3, pp. 33-43.
Parker, C. and Swatman, P. (1999). An Internet-mediated Business Simulation: Developing and using
TRECS. Simulation and Gaming, Vol. 30, No. 1, pp. 51-69.
Parunak, H., Savit, R. and Riolo, R. (1998). Agent-Based Modeling vs. Equation-Based Modeling: A Case
Study and User’s Guide. In Sichman, J., Conte, R. and Gilbert, N. (Eds.). Multi-Agent-Based Simulation, First
International Workshop, MABS 1998, Paris, France, pp. 10-25.
Penrose, R. (1989). The Emperor’s New Mind: Concerning Computers, Mind and the Laws of Physics.
Vintage, London.
Pressman, R. (1994). Software Engineering: A Practitioner’s Approach. European Adaptation. Third
Edition. McGraw-Hill International, Maidenhead, UK.
Petrie, C. (2001). Agent-Based Software Engineering. In Agent-Oriented Software Engineering, Lecture
Notes in AI, Springer-Verlag 1957, pp. 58-76.
Purnomo, H., Priyadi, H., Yasmi, Y., Yuliani, L. and Prabhu, R. (2002). Development of Multi-stakeholder
Scenarios of Forest Management: A Multiagent System Simulation Approach. Participatory Modeling
Symposium, Harare, Zimbabwe, 13-15 February 2002.
Ramanath, A.M. (2000). The Role of Information Systems Development Methods in Interorganisational
Systems Development, unpublished PhD thesis, Brunel University, UK.
Rational Software (1998). Rational Unified Process White Paper: Best Practices for Software Development
Teams at: http://www.rational.com.
Smith, J. (2001). A Comparison of RUP and XP. Rational Software White Paper at: http://www.rational.com
Sterman, J.D. (1988). ‘A Skeptic’s Guide to Computer Models’. In Richardson, G. P. (Ed.), Modelling for
Management, Volume I, Aldershot, Dartmouth, U.K.
23
Suleiman, R., Troitzsch, K.G. and Gilbert, N (2000) Tools and Techniques for Social Science Simulation.
Heidelberg: Physica-verlag.
Sycara, K. (2002) Multi-Agents Systems at: http://www.aaai.org/AITopics/html
Terna, P. (1998). ABCDE: Agent Based Chaotic Dynamic Emergence. In Sichman, J., Conte, R. and Gilbert, N.
(Eds.). Multi-Agent-Based Simulation, First International Workshop, MABS 1998, Paris, France, pp. 79-94.
Thesen, A. and Travis, L.E. (1995). Simulation for Decision Making. PWS Publishing Company, Boston.
M.A.
van Asselt, M., Mellors, J., Rijkens-Klomp, N., Greeuw, S., Molendijk, K., Beers, P. and van Notten, P. (2001).
Building Blocks for Participation in Integrated assessment: A Review of Participatory Methods. ICIS
working paper I01-E003 ICIS, Maastricht, The Netherlands.
Walsham, G. (1993). Interpreting Information Systems in Organisations. John Wiley & Sons, Chichester.
Wells, D. (2001). Extreme Programming: A Gentle Introduction at: http://www.extremeprogramming.org.
Wickenberg, T. and Davidsson, P. (2002). On Multi Agent Based Simulation of Software Development
Processes. In Sichman, J., Bousquet, F. and Davidsson, P. (Eds.). Multi-Agent-Based Simulation, MABS 2002,
Bologna, Italy, pp. 104-113.
Wooldridge, M. and Decker, K. (2000). Agents on the Net: Infrastructure, Technology, Applications. IEEE
Internet Computing, IEEE Computer Society, Los Alamitos, C.A. pp. 46- 48.
Wooldridge, J. and Jennings, N. (1999). Software Engineering with Agents: Pitfalls and Pratfalls. IEEE
Internet Computing, IEEE Computer Society, Los Alamitos, C.A. pp. 20-27.
Wooldridge, J., Jennings, N. and Kinny, D. (1999). A Methodology for Agent-Oriented Analysis and Design.
In Proceedings of the 3rd International Conference on Autonomous Agents (AA’99), ACM Press, N.Y. pp. 6976.
24