Understanding Agent Oriented SoftwareEngineering Methodologies

Jorge J. Gomez-Sanz, Ruben Fuentes-Fernandez, Juan Pavon

GRASIA Research Group,Universidad Complutense de Madrid,

Avda. Complutense, 28040 Madrid, Spain{jjgomez,ruben,jpavon}@fdi.ucm.es

Abstract. This paper introduces software engineering concepts to ob-tain a new perspective on the work done in agent oriented methodologies.Software engineering relies on a body of knowledge that is not availablein the agent research community, yet. A transfer of knowledge from thisbody can clarify what a methodology is for and what it is necessary todefine one. The paper concludes that current agent oriented methodolo-gies are still to evolve. This evolution will be possible due to the generaladoption of meta-modeling techniques; the interest in covering more de-velopment phases; and the growing number of development examplesavailable to the community.

1 Introduction

There has been little discussion of what an agent oriented methodology is. Thissurprises when considering there is no standard definition. This may have causedan abuse of the term leading to an increasing number of research works claimingto be a methodology. Researchers working in evaluation frameworks [SS03] haveraised this issue in the past, though this has not conducted to a self-criticismof the agent oriented software engineering community. As a result, some pa-pers claim to have a methodology just by introducing a modeling language orenumerating a few development activities.

We will start with a simple hypothesis: agent oriented methodologies are theresult of a transfer of knowledge from software engineering. As agent researchers,we are the experts to tell if a methodology X does capture the essential ofthe agent concept. Nevertheless, to assess the capability of a methodology foreffectively assisting developers, the experts to ask should be software engineers.Trying to look for answers in this direction, this paper proposes to revisit softwareengineering basics and draw some conclusions on the current state and directionsof agent oriented methodologies.

To do so, the paper first introduces basic concepts of software engineeringin section 2. Then, section 3 reformulates the software engineering definitionsincluding, when necessary, the agent orientation. With this definition in mind,some aspects of current methodologies are regarded and their current status as-sessed. Continuing with the ideas extracted from the software engineering review,some perspectives about the future of methodologies are declared in section 4.

81

2 Software Engineering and Methodologies

Software engineering is defined by the IEEE glossary [IEE90] as follows:

(1) The application of a systematic, disciplined, quantifiable approachto the development, operation, and maintenance of software; that is, theapplication of engineering to software. (2) The study of approaches as in(1).

The term software engineering appears in 1968 and was the name of a con-ference [NR68] sponsored by the North Atlantic Treaty Organization (NATO),where scientists and professionals acknowledged several problems affecting thesoftware industry. These problems crystallized into the software crisis, i.e., theinability to conclude development projects before the deadlines, within the initialbudget, and satisfying the client demands. Reasons like the complexity of thesoftware were expected to be handled by advances in programming languages andgood programming practices, a position defended by Dijkstra [Dij72], but therewere other issues that were clearly human like the coordination of working teamsand the organization of the development activities, a position illustrated in theknown book from Brooks [Bro95]. Both were right, and as a result, the trainingof a software engineer today is a multidisciplinary one. This is illustrated in thecurricula recommendations for Software Engineering promoted by the ACM andIEEE that can be found for undergraduate http://sites.computer.org/ccseand master level http://www.gswe2009.org courses.

Knowing software engineering today, means, at least, being familiar withthe Software Engineering Book of Knowledge (SWEBOK) [ABD+04]. This is aninitiative promoted, among others, by the IEEE computer society and part ofthe software industry. It pursues collecting relevant works, even ISO/IEEE stan-dards, addressing all the issues a developer may find while developing software.SWEBOK introduces eleven Knowledge Areas, each one focusing in a concretesubject like software design, software testing, or software quality.

In what respect to the topic of this paper, agent oriented methodologies,SWEBOK has a Knowledge Area named Software Engineering Tools and Meth-ods. Tools and methods appear together because they are highly coupled. Quot-ing the SWEBOK:

Tools are often designed to support particular software engineeringmethods, reducing any administrative load associated with applying themethod manually. Like software engineering methods, they are intendedto make software engineering more systematic, and they vary in scopefrom supporting individual tasks to encompassing the complete life cycle.

This does not mean that a method is unfeasible without tools, but, it makes theengineering tasks more challenging and inefficient. About the methods, SWE-BOK says:

Software engineering methods impose structure on the software en-gineering activity with the goal of making the activity systematic and

82

ultimately more likely to be successful. Methods usually provide a no-tation and vocabulary, procedures for performing identifiable tasks, andguidelines for checking both the process and the product. They varywidely in scope, from a single life cycle phase to the complete life cycle.The emphasis in this Knowledge Area is on software engineering meth-ods encompassing multiple life cycle phases, since phase-specific methodsare covered by other Knowledge Areas.

A method, according to the SWEBOK, can be either heuristic, formal, or pro-totyping. Heuristic methods can be either structured (e.g. a top-down approachwhere functions are successively refined), data oriented (e.g. being guided by thedata structures the problem needs), or object oriented (the system is viewed asa collection of objects instead of data structures or functions). Formal methodsare based on mathematics and focus mainly to specification languages (model-oriented, property-oriented, or behavior-oriented), specification refinement (howto bring it closer to the implementation), and verification of properties. Proto-typing methods distinguish between the prototyping style (e.g. if the prototypeis going to be thrown away or if it will evolve towards the final system), pro-totyping target (e.g. if it is going to prototype the user interface or the systemarchitecture), and the prototyping evaluation techniques (referring to the waythe results of the prototyping activity are going to be used).

A method concerns as well the software life cycle and the software life cycleprocesses. The software life cycle is the period of time that begins when a soft-ware product is conceived and ends when the software is no longer available foruse [IEE90]. The second refers to the process by which user needs are translatedinto a software product [IEE90], though the SWEBOK tries to adopt a widerapproach. It admits there could be several processes involved in a software lifecycle, or a single one, from the perspective of a whole organization performingthe development. In any case, the SWEBOK assumes a process usually follows asoftware life cycle model, which provides a high-level definition of the phases thatoccur during the development, e.g. a spiral model or waterfall. A process can bedefined, implemented, measured, and assessed. A software life cycle processes ora software life cycle model definition can be constructed using different notations(natural language, state-charts, petri nets, and others), though there are stan-dards available as well, like the Software & Systems Process Engineering Meta-model Specification (SPEM) [Obj08] or the Software Engineering Metamodel forDevelopment Methodologies (SEMDM) ISO/IEC 24744 [HSGP08]. It should benoted that SEMDM intends to capture the notion of methodology, conceivingit as the specification of the process to follow as well as the work products to begenerated, plus consideration of the people and tools involved, during a softwaredevelopment effort [GPHS05]. This is slightly different from the definitions givenin the IEEE Glossary and the SWEBOK, as introduced here, though it shouldbe still possible to use SEMDM to define a process.

This is just a rough approach to the problem of engineering software systems,but gives an idea of how challenging is to define a development method.

83

3 Agent Oriented Methodologies from a SoftwareEngineering perspective

Using as starting point the review of work in software engineering from section 2,some conclusions can be drawn to AOSE. From the categorization of methodsin section 2, an agent oriented method could be labeled as an heuristic methodwhere the system is viewed as a collection of agents. This would make sensein most cases, though the integration with formal methods and/or prototypingtechniques, may complicate the issue. In any case, this method should aim formaking the activity systematic and ultimately more likely to be successful. Themethod will provide with notation and vocabulary, procedures for performingidentifiable tasks, and guidelines for checking both the process and the product.The scope of the method will be from a single life cycle phase to the completelife cycle. This scope allows to talk about agent oriented analysis, which wouldfocus on how to determine which agents are necessary to provide the systemfunctionality; or agent oriented implementation, which would address the waya system specification, regardless of its agent orientation, can be implementedusing agent oriented solutions, e.g. an agent oriented programming language oran agent oriented framework. The concrete phase or process is defined separately,and can be an ad-hoc process or be derived from some software life cycle model.Clearly, the process or the affected phase will be biased by the use of agent relatedconcepts, since the expected products of the engineering activities necessarilyneed to refer to those concepts. Finally, there should be support tools that assistin the execution of the different activities addressed by the method.

The value of these conclusions is that they are derived from what an actualsoftware development demands, according to the software engineering practices.For the researcher, it serves as a guideline of the elements to be included ina methodology and helps to focus the contribution in specific phases of thedevelopment. For the developer, knowing in advance what is covered by themethodology will permit to be more efficient and applying the methodology inthe context it was intended to.

It should not be deduced that what has been published as agent orientedmethodologies is wrong. Revisiting the survey from Iglesias et al. [IGCG98], itcan be read that a methodology is something whose role is to assist in all thephases of the life cycle of an agent-based application, including its managementand that extends some known existing development solutions for X. Extensionwas not trivial and required altering existing solutions in different ways, tryingto be coherent with whatever was made with X. These extensions, or recycledmethodologies as referred in Muller [M97], had to be validated in some way.These extensions were focused in adapting the different existing products, and,in some cases, the involved activities. Assuming that the original methodologiesincluded the above-mentioned elements, which is true in most cases, and thattheir agent oriented extension were coherent with the inclusion of new elements,it should be assumed that the resulting methodology did provide the requestedelements.

84

It is harder to ensure this when the candidate for agent oriented methodologyis built from the scratch. Two big groups of proposals can be found. In one, thereis a methodology that first tries to build a notation and vocabulary to addresssome specific development phases. In the other, notation and vocabulary areembedded in a tool that permits to move from the analysis and design to theimplementation.

In the first group, there are works that were introduced as methodologiesat that time, but they should be more accurately introduced as phase specificmethods. This is the case, in our opinion, of GAIA [WJK00, ZJW03], highlyreferenced and widely regarded as an agent oriented methodology. It provides anotation and vocabulary, but it is focused on the analysis and design activities.Also, GAIA is not making the MAS construction systematic and disciplined,since it only addresses a part of the life cycle. Hence, it makes more sense to talkabout the GAIA agent oriented analysis method and the GAIA agent orienteddesign method, since those are the software life cycle phases which are beingstructured. Similarly, MESSAGE/UML [CCG+02] was introduced as an agentoriented software engineering methodology covering analysis and design. Again,it should have been more accurate to regard this as agent oriented orienteddesign and analysis method.

In the second group, works are built around a powerful tool support cover-ing an important part of the life cycle. This was the case of ZEUS [NNLC99]methodology and MaSE [WD00]. It has been objected that ZEUS methodologywas not such, since it was about the use of a tool, but, from the perspective ofthis paper, it is rather the opposite. ZEUS was a great tool that allowed a de-veloper go from requirements gathering to system deployment rather efficiently,though it presented some bugs. MaSE and its agentool allowed the executionof similar tasks but with a better documentation of the process to follow, andenabling formal verification of some properties of the defined protocols. Bothworks have evolved little to the extent ZEUS was discontinued and MaSE hadto build new tools to deal with new concepts, the agenttool III which is a pluginfor the Eclipse platform.

Time has passed and these two groups have merged. Today, it is expectedfrom candidate methodologies to have tool support similar to the one providedby ZEUS or agenttool, and regard more of the software life cycle than the ances-tors. As a result, the number of methodological proposals addressing more partsof the software life cycle has increased. AOSE methodologies such as INGENIAS,PASSI, ADELFE, or Prometheus, have grown up including more standard devel-opment phases, concretely, requirements gathering, implementation, and testing.As more phases are incorporated, the closer to a competitive industrial grademethodology it is.

Therefore studying software life cycle processes is relevant to understand thescope of the method and apply it correctly. Nevertheless, this part is usuallylightly acknowledged in the AOSE community with some exceptions [SCG08].Frequently, activities tend to be too simplified, to the extent that they are intro-duced as some items in a short numbered list. The connection with the process

85

itself is missing or non-relevant in the context of the research contribution. Inthe other extreme, there are methodologies that either propose new software lifecycle processes, such as PASSI, ADELFE, or Prometheus, or stick to an exist-ing software life cycle model, like INGENIAS. Understanding the importance ofprocesses is something the IEEE FIPA Design Process Documentation and Frag-mentation Working Group (DPDF WG) http://www.fipa.org/subgroups/

DPDF-WG.html is contributing enormously. There are complete specifications ofprocesses for PASSI, SODA, GORMAS, and INGENIAS http://www.pa.icar.

cnr.it/cossentino/fipa-dpdf-wg/docs.htm. For more information about therole of processes in AOSE, it is recommended to read the survey from Massimoet al. [CGMO11].

There has been an important progress in what refers to how AOSE method-ologies address the notation and vocabulary. Formal specifications are reviewedin the survey written by El Fallah-Seghrouchni et al. [EFSGSS11]. The formalrepresentation methods addressed in the survey can be labeled either as first-order logic, temporal logics, process algebras, or automata based. Solutions foundin these categories are all tool supported, with a special focus in the verification ofproperties. Despite the interest in formal notations, AOSE seems to be more fondof semi-formal approaches such as visual modeling languages specified throughmeta-models. It could be said it all started with the work of Ferber [FG98] onthe use of UML to specify a meta-model for MAS based in the concept of orga-nization and role. This contribution had no specific tool support, so it trusteddevelopers used existing UML vendor tools in the way the notation demanded.MESSAGE/UML [CCG+02] was the next step. It was the first to actually applythe meta-modeling approach as we know it today, using Graph-Object-Property-Relationship-Role (GOPRR) to express the syntax of the modeling languageand a meta-modeling tool, MetaEdit+, to provide custom editors. This pathhas been followed by most methodologies today, as Argente et al. [ABFF+11]show in a survey on current agent modeling languages, though using differentmeta-modeling languages. One meta-modeling approach attracting most of theattention is the Eclipse Modeling Framework (EMF). As a consequence, knownmethodologies like Tropos, MaSE (which now is o-MaSE) and Prometheus, aremigrating towards this platform, with TAO4ME [BDM+06], in the case of Tro-pos, Agentool III [SCDS09], in the case of o-MaSE, PDT [STP10], in the case ofPrometheus. INGENIAS has used this pure meta-modeling approach since thebeginning [PGS03], publishing its meta-model as an XML file in its sourceforgedistribution site http://ingenias.svn.sourceforge.net/viewvc/ingenias/

trunk/metamodel/. As a contribution to the community, INGENIAS team re-cently released to the public the meta-editor framework that was used internallyto maintain INGENIAS. Its name is INGENME, which can be downloaded fromhttp://ingenme.sf.net, and provides similar functionality to the Eclipse Mod-eling Framework, but more user friendly.

Progress in the construction of modeling languages have been encompassedwith advances in techniques for implementing specifications. A review of themcan be found in Nunes et al. [NCdL+11]. From the review it is outstanding

86

the growing number of automatic translations of specifications into code. Mostof them reuse facilities from the Eclipse platform, like the already mentionedTAO4ME, Agentool III or PDT. This approach is the dominant now, with someexceptions where implementation has to be done manually. There are precedentsin this kind of manual transition from specification to code. It can be done ina disciplined way, as suggested by Kendall [Ken99], where developers have theassistance of guidelines like design patterns.

4 Perspectives for Agent Oriented Methodologies

None of the existing methodologies can be considered perfect. They need to beused again and again; and this will surely make current methodologies evolve.This evolution will be probably directed towards addressing new developmentactivities and increment the scope of the methodology; a general improvementin the tool support; and an increase of the number of developments that availthe possibilities of each methodology.

A methodology aims to increase the chances of building successfully the sys-tem. Consequently, a methodology needs to be applied and assessed. If a softwarecompany is contracted to develop a system, the client should be sure that thecompany is capable of building the correct system before the agreed deadlineand without exceeding the budget. A way to rate the capability for success isthe Capability and Maturity Model (CMM) [PCCW93] and its evolution theCapability Maturity Model Integration (CMMI) [CMM02]. These models iden-tify a number of key areas that need to be studied, like the technical skills ofdevelopers, the degree of adoption of software processes, the existence of eval-uation procedures to assess the work done, or the training of personnel withinthe company, to mention some. Our methodologies are not there, yet. Only apiece of these elements are covered actually by existing methodologies. Never-theless, knowing more about how methodologies are expected to be applied inthe real world serves to advance the future needs. Most likely, management ac-tivities will be the next to be considered, after testing is more deeply studied.One of the basic management activities consists in foreseeing how much effort aMAS development will take [GSPG05] so that a realistic development plan canbe devised.

Tool support will be improved in all the activities the methodology is in-volved. A basic improvement will be being capable to enrich a methodology usingpast experiences. Notations like UML have changed along the years because theapplication experience of UML told there were things that could be made better.Similarly, the processes applied in the development and the notation proposedby our methodologies should be able to improve. This requires having customiz-able tools, capable of adapting to the new processes or notations. Thanks tothe adoption of meta-modeling techniques by the current methodologies, thiskind of tools will be possible with a reduced effort. Changes in the meta-modelsdescribing the modeling language or the process will be automatically processedto produce a new tool set adapted to the new meta-models.

87

Finally, there will be a higher demand of evidences proving the methodol-ogy works. These evidences will be complete developments availing the capa-bility of the methodology. There has been intents to develop the same systemwith Prometheus, O-MaSE, Tropos, and the Multi-Agent Systems Unified Pro-cess [LP08]. This can be useful to show the pros and cons of each approach anddemonstrate the benefits. Also, some methodologies maintain a list of devel-opments that can be used for testing the methodology and learn what it cando. Tropos maintains a list of papers introducing empirical application of themethodology in http://www.troposproject.org/node/304. INGENIAS doesthe same but provides the code instead in http://ingenias.svn.sourceforge.

net/viewvc/ingenias/trunk/IDK/iaf/tests/. These developments are actu-ally used as regression tests to verify that code generation capabilities of INGE-NIAS are not altered, i.e., that the same specification can be transformed in thefinal system as initially devised.

5 Conclusions

This paper has tried to clarify a pending issue in the AOSE community, whichit is the definition of an agent oriented methodology. It was studied using asoftware engineering perspective based on standards and reference material inthe software engineering community. This has permitted to enumerate elementsthat a methodology should incorporate, and aspects it should address. The workis not finished yet, since other issues in the provided definitions have not beencompletely explored. For instance, the way a method is expected to describe aprocedure and guidelines, and which ones could be meaningful.

Acknowledgements

This paper has been funded by the the project Agent-based Modelling and Simu-lation of Complex Social Systems (SiCoSSys), supported by Spanish Council forScience and Innovation, with grant TIN2008-06464-C03-01, by the Programa deCreacion y Consolidacion de Grupos de Investigacion UCM-Banco Santander forthe group number 921354 (GRASIA group), and by the Project for Innovationand Improvement of Teaching (Proyectos de Innovacion y Mejora de la CalidadDocente) number 127 from the UCM.

References

[ABD+04] Alain Abran, Pierre Bourque, Robert Dupuis, James W. Moore, andLeonard L. Tripp. Guide to the Software Engineering Body of Knowledge- SWEBOK. IEEE Press, Piscataway, NJ, USA, 2004 version edition,2004.

[ABFF+11] Estefanıa Argente, Ghassan Beydoun, Ruben Fuentes-Fernandez, BrianHenderson-Sellers, and Graham Low. Modelling with agents. In Marie-Pierre Gleizes and Jorge Gomez-Sanz, editors, Agent-Oriented Software

88

Engineering X, volume 6038 of Lecture Notes in Computer Science, pages157–168. Springer Berlin / Heidelberg, 2011.

[BDM+06] Davide Bertolini, Loris Delpero, John Mylopoulos, Aliaksei Novikau,Alessandro Orler, Loris Penserini, Anna Perini, Angelo Susi, and Bar-bara Tomasi. A tropos model-driven development environment. In NacerBoudjlida, Dong Cheng, and Nicolas Guelfi, editors, CAiSE Forum, vol-ume 231 of CEUR Workshop Proceedings. CEUR-WS.org, 2006.

[Bro95] Frederick P. Brooks. The Mythical Man-Month: Essays on Software En-gineering, Anniversary Edition (2nd Edition). Addison-Wesley Profes-sional, anniversary edition, August 1995.

[CCG+02] Giovanni Caire, Wim Coulier, Francisco J. Garijo, Jorge Gomez, JuanPavon, Francisco Leal, Paulo Chainho, Paul E. Kearney, Jamie Stark,Richard Evans, and Philippe Massonet. Agent oriented analysis usingmessage/uml. In Revised Papers and Invited Contributions from the Sec-ond International Workshop on Agent-Oriented Software Engineering II,AOSE ’01, pages 119–135, London, UK, UK, 2002. Springer-Verlag.

[CGMO11] Massimo Cossentino, Marie-Pierre Gleizes, Ambra Molesini, and AndreaOmicini. Processes engineering and aose. In Marie-Pierre Gleizes andJorge Gomez-Sanz, editors, Agent-Oriented Software Engineering X, vol-ume 6038 of Lecture Notes in Computer Science, pages 191–212. SpringerBerlin / Heidelberg, 2011.

[CMM02] CMMI Product Team. Capability maturity model integration (cmmism),version 1.1. Technical report, Carnegie Mellon, Software Engineering In-stitute, 2002.

[Dij72] Edsger W. Dijkstra. The humble programmer. Commun. ACM,15(10):859–866, 1972.

[EFSGSS11] Amal El Fallah-Seghrouchni, Jorge Gomez-Sanz, and Munindar Singh.Formal methods in agent-oriented software engineering. In Marie-PierreGleizes and Jorge Gomez-Sanz, editors, Agent-Oriented Software Engi-neering X, volume 6038 of Lecture Notes in Computer Science, pages213–228. Springer Berlin / Heidelberg, 2011.

[FG98] Jacques Ferber and Olivier Gutknecht. A meta-model for the analysisand design of organizations in multi-agent systems. In Yves Demazeau,editor, ICMAS, pages 128–135. IEEE Computer Society, 1998.

[GPHS05] Cesar Gonzalez-Perez and Brian Henderson-Sellers. Templates and re-sources in software development methodologies. Journal of Object Tech-nology, 4(4):173–190, May 2005.

[GSPG05] Jorge J. Gomez-Sanz, Juan Pavon, and Francisco J. Garijo. Estimatingcosts for agent oriented software. In Jorg P. Muller and Franco Zam-bonelli, editors, AOSE, volume 3950 of Lecture Notes in Computer Sci-ence, pages 218–230. Springer, 2005.

[HSGP08] Brian Henderson-Sellers and Cesar Gonzalez-Perez. Standardizingmethodology metamodelling and notation: An iso exemplar. In RolandKaschek, Christian Kop, Claudia Steinberger, and Gunther Fliedl, editors,UNISCON, volume 5 of Lecture Notes in Business Information Process-ing, pages 1–12. Springer, 2008.

[IEE90] IEEE standard glossary of software engineering terminology. IEEE Std610.12-1990, 1990.

[IGCG98] Carlos Angel Iglesias, Mercedes Garijo, and Jose Centeno-Gonzalez. Asurvey of agent-oriented methodologies. In Jorg P. Muller, Munindar P.

89

Singh, and Anand S. Rao, editors, ATAL, volume 1555 of Lecture Notesin Computer Science, pages 317–330. Springer, 1998.

[Ken99] Elizabeth A. Kendall. Role modeling for agent system analysis, design,and implementation. In ASA/MA, pages 204–218. IEEE Computer Soci-ety, 1999.

[LP08] Michael Luck and Lin Padgham, editors. Agent-Oriented Software En-gineering VIII, 8th International Workshop, AOSE 2007, Honolulu, HI,USA, May 14, 2007, Revised Selected Papers, volume 4951 of LectureNotes in Computer Science. Springer, 2008.

[M97] H. Jurgen Muller. Towards agent systems engineering. Data Knowl. Eng.,23:217–245, September 1997.

[NCdL+11] Ingrid Nunes, Elder Cirilo, Carlos de Lucena, Jan Sudeikat, ChristianHahn, and Jorge Gomez-Sanz. A survey on the implementation of agentoriented specifications. In Marie-Pierre Gleizes and Jorge Gomez-Sanz,editors, Agent-Oriented Software Engineering X, volume 6038 of LectureNotes in Computer Science, pages 169–179. Springer Berlin / Heidelberg,2011.

[NNLC99] Hyacinth S. Nwana, Divine T. Ndumu, Lyndon C. Lee, and Jaron C. Col-lis. Zeus: A toolkit for building distributed multiagent systems. AppliedArtificial Intelligence, 13(1-2):129–185, 1999.

[NR68] Peter Naur and Brian Randell, editors. Software Engineering, report ona conference sponsored by the NATO SCience Committee. NATO, ScienceAffairs Division from NATO, 1968.

[Obj08] Object Management Group. Software and systems process engineeringmetamodel specification (spem), 2008.

[PCCW93] M.C. Paulk, B. Curtis, M.B. Chrissis, and C.V. Weber. Capability matu-rity model, version 1.1. Software, IEEE, 10(4):18 –27, July 1993.

[PGS03] Juan Pavon and Jorge J. Gomez-Sanz. Agent oriented software engineer-ing with ingenias. In Vladimır Marık, Jorg P. Muller, and Michal Pe-choucek, editors, CEEMAS, volume 2691 of Lecture Notes in ComputerScience, pages 394–403. Springer, 2003.

[SCDS09] Carles Sierra, Cristiano Castelfranchi, Keith S. Decker, and Jaime SimaoSichman, editors. 8th International Joint Conference on AutonomousAgents and Multiagent Systems (AAMAS 2009), Budapest, Hungary, May10-15, 2009, Volume 2. IFAAMAS, 2009.

[SCG08] Valeria Seidita, Massimo Cossentino, and Salvatore Gaglio. Using andextending the spem specifications to represent agent oriented methodolo-gies. In Michael Luck and Jorge J. Gomez-Sanz, editors, AOSE, volume5386 of Lecture Notes in Computer Science, pages 46–59. Springer, 2008.

[SS03] Arnon Sturm and Onn Shehory. A framework for evaluating agent-oriented methodologies. In Paolo Giorgini, Brian Henderson-Sellers, andMichael Winikoff, editors, AOIS, volume 3030 of Lecture Notes in Com-puter Science, pages 94–109. Springer, 2003.

[STP10] Hongyuan Sun, John Thangarajah, and Lin Padgham. Eclipse-basedprometheus design tool. In Wiebe van der Hoek, Gal A. Kaminka, YvesLesperance, Michael Luck, and Sandip Sen, editors, AAMAS, pages 1769–1770. IFAAMAS, 2010.

[WD00] Mark F. Wood and Scott A. DeLoach. An overview of the multia-gent systems engineering methodology. In Paolo Ciancarini and Michael

90

Wooldridge, editors, AOSE, volume 1957 of Lecture Notes in ComputerScience, pages 207–222. Springer, 2000.

[WJK00] Michael Wooldridge, Nicholas R. Jennings, and David Kinny. The gaiamethodology for agent-oriented analysis and design. Autonomous Agentsand Multi-Agent Systems, 3(3):285–312, 2000.

[ZJW03] Franco Zambonelli, Nicholas R. Jennings, and Michael Wooldridge. De-veloping multiagent systems: The gaia methodology. ACM Trans. Softw.Eng. Methodol., 12(3):317–370, 2003.

This article was processed using the LATEX macro package with LLNCS style

91