Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
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