How to Choose the Right Methodology for Agent-
based Systems
Ehsan Alirezaei
Tehran, Iran
ehsan_alirezaii@ut.ac.ir
Ahamd A...
methodologies like ASPECS, ADELFE, INGENIAS and
PASSI are using iterative process model. TROPOS has
proposed evolutionary ...
development approach (Object Oriented, Knowledge
Engineering, Requirement Engineering), and guidelines. For
assessment of ...
Table I. Methodologies pragmatism Evaluation
Feature
Methodology
Unambiguity
Precisely
Expressiveness
Consistency
Notation...
IV. GUIDELINE FOR CHOOSING THE RIGHT METHODOLOGY
In the following lines, there is need to clarify how
evaluation result ca...
there is agile PASSI too. It is suitable for low risk systems that
have few changes in future.
PROMETHEUS attempted to cov...
inbound contact centers with skills-based routing, impatient
customers, and retrials , 2007.
Upcoming SlideShare
Loading in …5
×

How to choose right agent based methodology

435 views

Published on

how to choose right agent oriented methodology

Published in: Software, Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
435
On SlideShare
0
From Embeds
0
Number of Embeds
14
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

How to choose right agent based methodology

  1. 1. How to Choose the Right Methodology for Agent- based Systems Ehsan Alirezaei Tehran, Iran ehsan_alirezaii@ut.ac.ir Ahamd Abdollahzadeh Barfourosh Amirkabir University, AIS lab Tehran, Iran ahmad@aut.ac.ir Abstract-Today many Agent Oriented Methodologies have been introduced. Choosing the right methodology is a hard job to do. For evaluate the effectiveness of introduced methodologies, there is need to quantitatively assessment framework and techniques. Assessment framework in this paper will show any part of methodology with measurements. Based on proposed framework, the guideline presented for choosing the right methodology. In the new frame, benchmarks have six issues: Definition (concept), Feasibility (pragmatic), Modeling language, Process, Tool and Support criteria. In the benchmark has been showed effect of the metrics and evaluation on choosing the right methodology base on project characteristics. For evaluation it is considered nine methodologies: ADELFE and ASPECS as mature, ROADMAP, MASE and GAIA as general-purpose, INGENIAS, PASSI, PROMETHEUS as suitable for short time delivery projects and TROPOS with strong Requirement Engineering basis. All measurements are by checklists that created by study of software industry. Keywords-Methodology I. INTRODUCTION Agent Oriented Software Engineering (AOSE) methodologies as guidelines supported with tools are of interest to developers and researchers in developing agent- based systems. Each methodology has methods and processes, which will determine its application in certain areas [1]. There is a gap for agent-oriented methodologies in theory and industrial use; there are many well-defined methodologies in theory and examples but software companies do not using them. Cause of this problem is: AO methodologies processes due to being newer than Object-Oriented methodologies are not complete as Capability Maturity Model (CMM) levels. For filling the gap, it is helpful using guideline for choosing right methodology. It seems that the use of a specific methodology for solving problems affects on producing the desired AO system. Some methodologies are appropriate for special projects, so for each project characterization needs appropriate methodology fragments for creating suitable methodology for organization. Evaluating methodologies is helpful for two main works: first for choosing the right methodology by providing guidelines and second selecting suitable method fragment to creating new project-specific methodology. Using disproportionate frameworks for methodology evaluation, such as using object-oriented assumptions, can lead to problems such as inability to express the agent- oriented concepts, Therefore new framework must includes agent concepts. Based on our new frame users can consider which methodology is appropriate for the AO system categories. Proposed methodologies in this paper have been selected from those that have enough details in papers and well known in the community of Software Engineering. Proposed methodologies are: MASE [2], GAIA [3], TROPOS [4], ADELFE [5], INGENIAS [6], PASSI [7], PROMETHEUS [8], ROADMAP [9] and ASPECS [10]. In the second part, proposed methodologies and their specifications, aspects of language, notations, and the process have been introduced. In the third section, new framework and result of evaluation base on frame are presented. In the fourth part of paper, guideline for choosing the right methodology base on evaluation is mentioned; finally in the fifth section, conclusion and future works are presented. II. METHODOLOGIES In this section some of agent-oriented methodologies that are presented based on four layers: A quality focus, Process, Method and Tool [11]. Methodology quality focus comes from functional and non-functional requirement management aspects. All methodologies have processes for achieving the quality focus, that these processes in practice must show their strengths. In each process, methodologies are defined many methods to achieving the quality goal with support of tool. Definitions presented in these four layers for each methodology. These nine methodologies have been selected because they are well known and accepted in AOSE society with introduced many examples and papers. Agent oriented methodologies have differences in given aspects such as process, process model, life cycle, supporting tools and characteristics. Some latest methodologies considered in this paper like (ASPECS from PASSI), (ROADMAP from GAIA) have new processes or many change, so they are categorized in separate methodology not as extension. Selected methodologies have differences in the quality focus. MASE and TROPOS are using requirement engineering and goals for achieving system quality. GAIA, ASPECS and ROADMAP are using organizational aspects to achieving quality. Some of methodologies need extension for achieving quality in implementation. Some of methodologies like GAIA, MASE, PROMETHEUS and ROADMAP are using waterfall process model with support of some phases of lifecycle. Other
  2. 2. methodologies like ASPECS, ADELFE, INGENIAS and PASSI are using iterative process model. TROPOS has proposed evolutionary process model. In lifecycle phases each methodology had guideline for achieving artifacts (method). Each method affect on final quality and some of them are supporting by tools. Some of Methodologies for achieving the system quality proposed tools and modeling language. E.g. INGENIAS are using INGENIAS Development Kit (IDK)[6] for modeling and JADE [12] for implementing systems. Methodologies have differences based on the time they are introduced, changes in their definitions and characteristics. Today agent specifications are complete and there are methodologies that cover some aspects of lifecycle and agents concepts, but it is a long way to introduce mature methodology. In the first step to find what to do there is need to new frame for founding effectiveness of methodologies quantitatively. III. ASSESSMENT FRAMEWORK AND METHODOLOGIES EVALUATION All aspects of quantitative evaluation and adoption for methodologies assessment are presented in this section. In the second subsection new assessment framework is presented and there is a study about it. In the last subsection evaluation results are presented with nine methodologies based on new frame and quantitative approach. A. Quantitative assessment Researchers presented many standard frameworks for evaluating different methodologies, e.g. DESMET [13]. DESMET method introduced quantitative approach, so in our new frame we adopted its ranking table for evaluating methodologies. New method uses values from 0 to 5 for mapping quality assessment to quantitative evaluation as is shown below: • The feature is not supported nor referred in methodology document is equal to Zero (No support). • Indirectly support of some features is equal to One (Low support). • Properties listed in the document supported and mentioned with tools but does not support some aspects is equal to Two (Support some aspects). • All aspects mentioned are supported with tools but experience of user is important is equal to Three (Strong support). • All aspects are fully supported with tools is equal to Four (Very strong support). • In addition to full support with tools there is aided scenarios is equal to Five (Full support). For creating mature framework for AOSE methodologies and identifying characteristics of framework we used the context of methodologies and other evaluation frameworks by researchers [14,15,16]. The aim of this assessment framework is to creating quantitative measurement for methodologies. Prior frameworks had qualitative assessment to methodologies or some of them had some of features that specify in this framework, so this frame is complement to other and quantitative. In some cases in new frame answering questions is only possible with Yes/No, because of the nature of a features that is not quantifiable. B. Assessment framework Presented framework in this paper is based on agent oriented methodologies specifications and it is an evolution of introduced frameworks in other papers [14-19]. A problem that we try to cover in new frame is that researchers assessment frameworks are limited to some aspects of qualification evaluation. Another problem that has been tried to cover is supporting evaluation with guideline to choose right methodology. Presented assessment framework in Fig. 1 includes the concept, modeling language, process, pragmatic, support aspects and development tools. In addition to the above issues, each part has a subsection, which all questions related to topic is categorized based on their specification. Each part of the framework has some aspects, in concepts we checked properties like autonomy, re-activeness, social ability, pro-activeness and other features. Furthermore there must be some test on methodology for factors such as belief, desire, intention, message, norm, organizations, protocol, role, service, community, and etc. For each subsection of existing aspects in framework there are questions that must be answered to have the right evaluation. Each aspect with its questions is available in a checklist with references to three parts: developers of methodology, other research assessment, and our assessment. Presented final evaluation is based on reviews on this three assessment in checklists. Comparison of agent oriented concepts based on Fig.1, needs to propose questions about features like: architecture independency, consistency, autonomy, reactivity, pro-activity, interaction language, and intention. In comparison modeling language needs to propose questions about features like representation type, Meta model, relation among models and their dependency, notation evaluation, environment support, concurrency, transparency, modularity, and methodology extendibility. Figure 1. Assessment Framework In the process section some features are considered like process model, covering the lifecycle, development methods and context, application domain, the basic element of models,
  3. 3. development approach (Object Oriented, Knowledge Engineering, Requirement Engineering), and guidelines. For assessment of lifecycle we categorized it into seven phases as requirement elicitation, requirements analysis, architecture design, detail design, implementation, verification and test, and deployment. The cause of this classification is the support volume and guidance that is provided by a methodology in each part difference and should be carefully investigated. In comparison to pragmatism, methodologies should have features like no ambiguity, accuracy, consistency, notation simplicity, model refinement ability, documentation, suitability architecture language, samples, applicative in domain, and models expressively. The other section presents: supported aspects, features like support of open systems, security, support of ontology, organization, dynamic organization, knowledge modeling, and scalability. Some assumptions like knowledge modeling are not part of agent- oriented methodologies, but support of them can show strength of the target methodology. Development tools for methodologies are categorized in modeling tools and implementation tools. Having tool is strength for methodology; also it is important to the designer and developer. Some aspects in tools are important like code generation from design, testing ability, platform independency, and support agent concepts. C. Comparison of methodologies The cause for selecting these nine methodologies for comparison is that they have features such as supporting tools, many different researches, or available standard language for them. We tried choosing methodologies from the different time intervals that targeted methodologies had many citations. In comparing the methodologies also we look at previous evaluation that have been performed in this field [14-19]. All evaluations are provided with comparison tables for the proposed framework. In contrast of this paper, some of tables are presented in these sub sections. 1) Process aspect evaluation The process and life cycle comparison are presented in [20]. According to this comparison, we can say methodologies like MASE and GAIA are using waterfall process model and there are other methodologies that make use of iterative and evolutionary process model that it affects their uses on projects and organizations. In requirement elicitation phase, TROPOS and ADELFE are better in comparison feature with the other methodologies and it is due to the use of I* framework. In requirements analysis and architecture design phases there are good guidelines and supports with tools for all methodologies but GAIA, INGENIAS, and PASSI just support some aspects of requirement analysis. In the detail design GAIA and ROADMAP only support some aspects and are weaker than others, although there is extension of GAIA (ex-GAIA) that it is trying to cover this weakness [21]. These two methodologies finish their works in detail design. In implementation phase there are tools for supporting the methodology guidelines except for ADELFE, in this phase experience of developers is important for using methodologies guidelines. ROADMAP and ASPECS are the two methodologies that strongly support verification and validation phase, but MASE only supports requirements validation. Support of deployment is another feature in table and considered phases that provided by three methodologies in some aspects. All mentioned methodologies have Object- Oriented (OO) base and Requirement Engineering (RE) affects some of them. ROADMAP and GAIA does not have any guidance for the reusability, while ADELFE and ASPECS have strong reusability criteria based on their metamodel. 2) Agent concepts coverage evaluation As shown in [20], in contrast to the concepts associated with the implementation of Multi-Agent Systems, we can say that all the methodologies in this field have documentations and guidelines. In autonomy all methodologies have enough attention to support of tools. GAIA has low support of mental aspects while TROPOS supports this aspect very strongly. ADELFE and MASE have very strong supporting for the concurrency. For adaptive systems ADELFE has the best solutions and the aim of its development is to support the adaptive agent-based systems. GAIA and ROADMAP don’t have any guidelines for communication language and communicability. In order to face with transient conditions and dealing with failures, ADELFE is operating accurately. In comparing the methodology Intentions (purposes), those methodologies that have lower ranks, like MASE, they can be used for broad categories of projects and other that have higher ranks are suitable for special-purposes; like ADELFE that is suitable for adaptive systems, but methodology projects-independency (suitability for broad category of projects/organizations) does not mean that they are general purpose. Reactivity is the aspect that has been mentioned in all methodologies but ASPECS has scenarios for it so it is has strong support for it. Pro-activity shows the importance of goals in methodology, as you can see in methodologies like PASSI, in which the goals are not as important as the goals in TROPOS. Other aspects can be considered in [20]. 3) Methodologies pragmatism evaluation As shown in Table I, Methodologies that are older than others have better situation in pragmatism. The reason is that, these methodologies are equipped with more documentation and examples. GAIA and ROADMAP are so weak for covering pragmatism aspects. All methodologies have been good in terms of not being ambiguous. PASSI and ASPECS are very strong in this term. In refining aspect, TROPOS, ADELFE, and INGENIAS have very strong support. There is much documentation for older methodologies, because of those new methodologies such as ASPECS, which have low rating. In number of examples, most methodologies do not provide a lot of work, or those have examples are not accessible. All in all, in comparing pragmatism we can say MASE, TROPOS, INGENIAS and ADELFE have good support of aspects provided in table I.
  4. 4. Table I. Methodologies pragmatism Evaluation Feature Methodology Unambiguity Precisely Expressiveness Consistency Notationsimplicity Refinement Documentation Examples MASE 2 2 2 3 3 1 4 4 GAIA 2 2 1 1 1 0 4 0 TROPOS 2 2 2 3 2 4 4 2 ADELFE 1 3 3 5 2 4 3 1 INGENIAS 3 1 2 2 4 4 2 1 PASSI 4 2 3 2 3 2 2 1 PROMETHEUS 2 3 3 2 2 2 3 3 ROADMAP 3 2 2 1 2 0 2 0 ASPECS 4 3 3 1 2 1 1 0 4) Modeling language evaluation Cause the nature of questions for aspects in Modeling Language; questions could answers by Yes/No. Features like modularity and type of representations are supported by all methodologies. Designing models in languages in different phases are independent for four methodologies as you can consider in table. GAIA has no support for transparency. MASE methodology does not support concurrency in modeling language, also it does not have Meta model. Considering environment aspects and interaction with that is another comparison feature, and it has not been supported in MASE and PASSI and another four methodologies as presented in table are supporting work and interact in dynamic environments. MASE in modeling language has weaker support in comparison with other methodologies and ASPECS due to its features like: independency between models, multiple abstraction layers for enterprise hierarchy, and agent decomposition ability has good modeling language coverage. 5) Tools evaluation In this section we only presented development tools assessment table. For modeling tools, methodologies have dealt with one or more tools. According to documentation of ASPECS, it is using UML language and it doesn't have specific tool yet. There is a new tool for GAIA, called GAIA4E [22], that its representation is formal and still does not have any guidelines for some features. There is a strong tool for supporting ADELFE with all features, named OpenTool. In Table II, development tools are presented for methodologies. Methodologies with star above them have guidelines for specific Tool and there are not developed specifically for that those methodologies. The Tool that is called BOGOR doesn't have IDE for programming; instead, it provides an environment for concurrent processes. In comparing programming tools, there is JACK [23] and JADE tools, which are java base and are common with using intelligent agents. Downloading and using of JADE is free but for using JACK must be paid. JANUS is a new tool that is specifically for ASPECS methodology. There is no implementation tool for ADELFE. 6) Comparison of support Aspects According to Table III, for support aspects, ASPECS methodology provides full support with initial features in its workflow and lowest support belongs to PROMETHEUS methodology. These three methodologies, MASE, PASSI, and ASPECS, have support for ontology from the base and with ontology it is possible to model domains. Only ASPECS has support for organization dynamics and change of organization in different situations. All methodologies are scalable and security support in definition is available for MASE, TROPOS, ADELFE, and ASPECS. Table III. Comparison of support aspects Support aspects Methodology Open systems Security Scalability Ontology Organization Dynamic Organization Knowledge Model MASE No Yes Yes Yes Yes No Yes GAIA Yes No Yes No No No Yes TROPOS No Yes Yes No No No No ADELFE Yes Yes Yes No No No No INGENIAS No No Yes No No No Yes PASSI No No Yes Yes Yes No Yes PROMETHEUS No No Yes No No No No ROADMAP Yes No Yes No Yes No Yes ASPECS Yes Yes Yes Yes Yes Yes Yes Table II. Implementaion Tools Assessment Tool name Methodology Tool specification BOGOR MASE Environment model, controlling JACK TROPOS, PROMETHUS* Platform independency, Environment model, controlling, debugging, special systems JADE MASE*, GAIA*, INGENIAS, PASSI*, ROADMAP* Platform independency, Environment model, controlling, debugging, special systems, free JANUS ASPECS Platform independency, Environment model, controlling, debugging
  5. 5. IV. GUIDELINE FOR CHOOSING THE RIGHT METHODOLOGY In the following lines, there is need to clarify how evaluation result can be used to reach guideline. Agent oriented approaches represent software engineering concepts for solving industrial complicated problems. Considering this fact, it is quite obvious that the role of agent-oriented methodologies is important. In the last step by applying the evaluation results, we try to have guidelines for choosing the right methodology. Software engineering projects also agent-oriented projects are categorizing based on their size, cost, and type. Some methodologies have better guidelines for specific category of projects and organizations, there is needed to specify a matrix for both projects and methodologies for selecting and ease of use. Project size is measured in overall investment and agent numbers estimation [24,25]. For increasing the size of the projects, numbers of stakeholders grow up from 1 to n. The system complexity is growing for agents and stakeholders communication and interaction increment. In AOSE, the aim of the methodologies is to dealing with medium to high complexities, that there is different number of people involved in the project and geographical or cultural distribution affects on project communications. Choosing right methodology is the responsibility of Project management office (PMO). In the table IV, guideline is presented for choosing the methodology that using agent-oriented approaches. According to mentioned assessment and Table IV. MASE methodology covers all life cycle stages. MASE is suitable for enhancement to medium-scale closed systems, due to its waterfall process model and specification of MASE that acts in closed systems it is efficient for projects that have medium. GAIA does not cover the entire life cycle, it moves forward till the architecture design phase. This methodology is suitable for developing enhancement to small projects in both project types that have low risk in close environments. Ex- GAIA is efficient in developing open systems till medium or large scale. TROPOS covers life cycle till implementation phase and has strong support of requirement engineering phase this methodology is effective in developing open and complex systems. ADELFE covers life cycle methodology till implementation and has strong support of requirement engineering. This methodology is for developing adaptive systems that they deal with changing environment and agent must cooperate to achieve new goals in this environment. INGENIAS covers analysis, design and implementation phases. It is applicative in all domains and can be used for variety of projects sizes. But since there is no guideline in requirement elicitation, it is suitable for projects low risk. PASSI covers all life cycle phases except the requirement phases. It is a methodology for closed and small systems and Table IV. Guideline for uses of methodologies according categories of projects (Business-B, Information Technology-IT) Methodology Project risk Project size and system type Description MASE Low or medium Enhancement to medium (B, IT) Waterfall process model, applicable to closed systems, prototyping can be used, change management maybe required GAIA Low or medium Enhancement to medium (IT, social) Waterfall process model, applicable to closed and open systems, prototyping can be used, short time delivery TROPOS Medium to high Medium to very large (B, IT) Evolutionary process model, applicable to open systems, governance important, focuses on business value ADELFE High Large to very large (Adaptive) Iterative/incremental process model, applicable to open systems, crucial systems, change management very important, customer involvement is high INGENIAS Low or medium Enhancement to large (B, IT) Iterative/incremental process model, applicable to closed systems, artifacts are important, project time frame about 6 month PASSI Low Enhancement to small (IT) Iterative process model, applicable to closed systems, also Agile PASSI available, prototyping can be used, short time delivery PROMETHEUS Medium or low Enhancement to small (academic, B, IT) Waterfall process model, applicable to closed systems, deliver in short time, requirement not change ROADMAP Medium or low Small to large (IT, social) Waterfall process model, applicable to open systems, requirement not change, governance involvement ASPECS Medium to high Large and very large (B, IT) Iterative process model, applicable to open systems, inter-team communications, governance overhead, challenging and failing risks available
  6. 6. there is agile PASSI too. It is suitable for low risk systems that have few changes in future. PROMETHEUS attempted to cover life cycle but it does not support deployment phase. It is suitable for those people with no previous experience like student and academic users. It is also applicable in small size industry. ROADMAP covers life cycle till detailed design phase. It supports knowledge modeling so that it is a good point. This methodology is suitable in social open systems for variety of sizes from small to large because mentioned specifications in evaluation. ASPECS covers life cycle phases completely. It is one of strong methodologies that some of its remarkable points come from other methodologies like PASSI. It is recommended for complex open systems in large scales. All methodologies that are applicable to open systems are applicable to closed systems and environment too. FIPA made efforts for methodologies standardization, for instance we can mention some output of FIPA like Agent Communication Language (ACL) and ASPECS methodology. V. CONCLUSION In this paper we have reviewed nine AOSE methodologies, then we presented a quantitative evaluation framework that can be used in other assessment researches for AOSE methodologies. In thirds section, we evaluated methodologies for illuminating their strengths and weaknesses. Based on the evaluation result, we had a conclusion and proposal guideline for choosing the right methodology on specific domain and projects categorizes based on their sizes. it cannot be recommend a specific methodology for specific project and problem; hence there is need a methodology that complies with the terms of that problem. So researches embark on introducing unified methodology or using method engineering. In methods engineering instead of selecting an appropriate methodology, methodology is designed by methods that developed and extracted from current methodologies. In future works we are going to propose new framework for engineering new methodology from current methodologies based on current assessment, and proposal an fast way to fragment extraction and choosing methodologies. We are also working on decreasing the cost of method engineering for global use with introducing unified method engineering language. REFERENCES [1] C. Ghezzi, M. Jazayeri, D. Mandrioli, “Fundamentals of software engineering”, Upper Saddle River, N.J: Prentice Hall, 2th edition 2002. [2] S. A. DeLoach,"Analysis and Design using MaSE and agentTool ", Midwest Artificial Intelligence and Cognitive Science Conference, 2001. [3] M. Wooldridge, N. R. Jennings, D. Kinny, "The Gaia Methodology for Agent-Oriented Analysis and Design", Autonomous Agents and Multi-agent Systems - AAMAS , vol. 3, no. 3, pp. 285-312, 2000. [4] P. Bresciani, A. Perini, P. Giorgini, F. Giunchiglia, J. Mylopoulos,"Tropos: An Agent-Oriented Software Development Methodology ",Autonomous Agents and Multi-agent Systems - AAMAS , vol. 8, no. 3, pp. 203-236, 2004. [5] C. Bernon, M. P. Gleizes, S. Peyruqueou, and G. Picard, "ADELFE: A Methodology for Adaptive Multi-agent Systems Engineering," Engineering Societies in the Agent World - ESAW, 2002. [6] J. Pavón, J. J. Gómez-sanz,"Agent Oriented Software Engineering with INGENIAS", International Workshop of Central and Eastern Europe on Multi-Agent Systems - CEEMAS , pp. 394-403, 2003. [7] M. Cossentino, and C. Potts. "PASSI: a Process for Specifying and Implementing Multi-Agent Systems Using UML." 2002. [8] L. Padgham, M. Winikoff, "Prometheus: a methodology for developing intelligent agents ", Autonomous Agents &Multiagent Systems/Agent Theories, Architectures, and Languages - ATAL , pp. 37-38, 2002. [9] T. Juan, A. R. Pearce, L. Sterling,"ROADMAP: extending the gaia methodology for complex open systems ", Autonomous Agents &Multiagent Systems/Agent Theories, Architectures, and Languages - ATAL , pp. 3-10, 2002. [10] M. Cossentino, N. Gaud, V. Hilaire, S. Galland, and A. Koukam, "ASPECS: an Agent-oriented Software Process for Engineering Complex Systems," Autonomous Agents and Multi-agent Systems, Vol. 20, No. 2, pp.260-304, 2010. [11] R. S. Pressman, “Software engineering: A Practitioner’s Approach” , Mc Graw Hill, 7th edition, 2010. [12] F. Bellifemine, A. Poggi, and G. Rimassa, “Developing Multi- agent Systems with JADE “,springer 2000 [13] B. Kitchenham. DESMET: a method for evaluating software engineering methodsand tools. Technical Report TR96-09, University of Keele, U. K. , 1996. [14] D. Isern, D. Sánchez, A. Moreno, Organizational structures supported by agent-oriented methodologies, Journal of Systems and Software 84(2):169-184 (2011) [15] K. H. Dam, M. Winikoff: Evaluating an Agent-Oriented Approach for Change Propagation. AOSE 2008: 159-172 [16] F. Bergenti, M.Gleizes, F. Zambonelli, METHODOLOGIES AND SOFTWARE ENGINEERING FOR AGENT SYSTEMS The Agent-Oriented Software Engineering Handbook,Springer, Jun 30, 2004 [17] A. Sturm and O. Shehory, "A Framework for Evaluating Agent- Oriented Methodologies,"Agent-Oriented Information Systems, 2003. [18] Ingrid Nunes, Elder Cirilo, Carlos José Pereira de Lucena, Jan Sudeikat, Christian Hahn, Jorge J. Gómez-Sanz: A Survey on the Implementation of Agent Oriented Specifications. AOSE 2009: 169-179 [19] A. Susi, Anna Perini, John Mylopoulos, PaoloGiorgini: The Tropos Metamodel and its Use. Informatica (Slovenia) 29(4): 401-408 (2005) [20] E. Alirezaei and A. A. Barfroosh,” Evaluation of Agent Oriented Methodologies”, 4th IKT , 2012. [21] P. Jain, D. Dahiya: Knowledge Management System Design using Extended Gaia. CoRR abs/1102.2114: (2011) [22] Luca Cernuzzi, Franco Zambonelli: Gaia4E: A Tool Supporting the Design of MAS using Gaia. ICEIS (4) 2009: 82-88 [23] M. Winikoff: JACK™ Intelligent Agents: An Industrial Strength Platform. Multi-Agent Programming 2005: 175-193 [24] Project classification for requirements, software education requirement methodology pack, published by cutter consortium, January 2008. Note in: www.softed.com [25] S. Helber and K. Henken :Profit-oriented shift scheduling of
  7. 7. inbound contact centers with skills-based routing, impatient customers, and retrials , 2007.

×