1.1 Survey s scope and motivation

Evaluation of Agent Oriented Software Engineering Main Approaches Salaheddin J. Juneidi, George A. Vouros Department of Information and Communication Systems Engineering School of Sciences University of the Aegean {jneidi,georgev}@aegean.gr Abstract Agent Oriented Software Engineering (AOSE) is occupying major domain in research field, motivated by at least two main fields in computer science, Software Engineering (SE), and Artificial Intelligence (AI) more precisely Distributed Artificial Intelligent (DAI) presented as Agent Base Computing. Even though their wasn t a concrete relation between these two main fields in the past years, SE and agent base computing start to interact seeking an appropriate methodology and modeling technique for modeling and applying software agents into software development process. This article offers gaudiness and evaluation for the main approaches toward AOSE methodologies and modeling techniques for analysis and design phases and helps the researchers and practitioners to have a general and overall view of different approaches with judgment procedure 1.0 Introduction Software engineering is crucial to the industrial and commercial applications, as today's and tomorrow's standard software systems are required to operate in increasingly complex distributed, large, open, dynamic, unpredictable, heterogeneous, and highly interactive application environments. Agent based computing appears to be very promising and natural to build these systems in terms of agent and multiagent technology. Thus agent orientation can serve as a useful paradigm in software engineering which has been referred to as agent-oriented software engineering (AOSE). The core phases of software engineering are analysis and design phases, these two phases are mostly affected with evolution of software engineering paradigm. We attested a massive development in SE when object oriented programming came up, as a result UML Unified Modelling Language was establish to represent not only system analysis and design but also system requirements specifications and functionality. Agent Oriented Software Engineering (AOSE) is being described as new paradigm [1] for the research field of Software Engineering, consequently robust methodologies and tools have to be developed to model software agents into software developing process. What is an Agent or at least as much as we concerns about software agent or an intelligent agent, it is a piece of autonomous software [2] or an autonomous entity that can interact with its environment [3]. Common classification scheme of agent has some properties [4] (autonomy) agents have their own will, (social ability) able to interact with environment or other agents,(pro-activity) they take initiative, (adaptive/reactive) responds to a stimulus, (mobility)can move around in environment from platform to other (characteristic) own personality and emotional state and beliefs(learning) changes its behaviour based on its previous experience(intelligence) has beliefs, goals, assumptions and plans, interact with other agents using symbolic language. 1.1 Survey s scope and motivation Developments in agent-based computing and software engineering have revealed a significant potential and urgent demand for a close interaction among these disciplines. This article provides guideness and judgment for both researchers and practitioners in navigating and investigating through, and becoming acquainted with available methodologies on AOSE. Creating such a guideness and judgment challenging process for four major reasons: AOSE represents a very young field with overwhelming and some times overlapping methodologies and modeling techniques. Final and complete methodology for this matter has not been realized yet. AOSE constitutes an interdisciplinary field from different fields, that means the related work in boarder disciplinary fields (software engineering and agent-based computing ) is quite enough to affect the main stream that runs AOSE research. AOSE research field evolves very rapidly. For that reason after one year for example this article can not be guaranteed to provide pointers to all work AOSE. The article categorizes each work according to its main idea and orientation toward applying agency properties in software system. Before Performing evaluation and judgment procedure, we must establish and agree on appropriate evaluation criteria, which joins evaluation criteria for both software engineering and agent base computing. Well, it is understood that none of the evaluated approaches has been presented in a final stage, though giving such judgment can anticipate the weaknesses and the strength for future enhancements. The article depicts three different major approaches toward that support at least analysis and design phases of software development process. These approaches represented in 1

methodologies and modeling techniques, concluded in three major categories: Agent and Multiagent Oriented Methodologies (AOM) Approaches based on Object-Oriented Methodologies. Extending of Object -Oriented modeling techniques (UML) into AUML This article doesn t go through the details of the presented methodologies or modeling technique, each of which been referenced for further interest. In the case of the first two approaches, there are a quite number of proposed methodologies and modeling techniques, a selection process for the most prominent methodology is applied to be identified for discussion and evaluation. The selection procedure carried out on the most known publishing internet locations and digital libraries within the past ten years, taking percentage for publishing frequency for each, with error factor 1.5 %. This article is structured as follows. Section 2 discusses the main approaches of AOSE, starts from section 2.1 Agent and Multiagent Oriented Methodologies (AOM) and according to the publishing frequency, Gaia [5] is chosen for evaluation. Section 2.2 MaSE [6] is selected for evaluation on the behalf of the second approach based on Object-Oriented Methodologies. Section 2.3 discusses the proposed extensions in UML diagrams to represent software agents. Section 3 establishes evaluation criteria for AOSE with aspects software engineering and agency characteristics. Finally, Section 4 conducts an evaluation process according to setup criteria for the selected methodologies and modeling technique. 2.0 Main approaches for AOSE AOSE must have the ability to model agent component into software, as mentioned in survey s scope section, three main approaches propose analysis and design phases, that include assumption toward broad engineering techniques in AOSE, to fit any kind of software entities (agents and non-agents), each approach has its own independent view of AOS, a special purpose and tailor methodologies for specific applications are not counted as AOSE methodology. 2.1 Agent and Multiagent Oriented Methodologies (AOM) This approach doesn t explicitly expressed as a Software Engineering for a software that merge agents entities within, but proposed as a methodology for building an agent oriented software system with its main phases analysis and design, this approach incorporate a revolutionary attitude on classical software engineering, and specially the most resent Object Oriented Software Engineering (OOSE), and argue that OOSE is not adequate to model AOSE, consequently, it has a distinct view of AOS that concentrates on Multi Agent System ( MAS) Modelling. Gives emphasis to agentify software entities, Agentify is an expression used to turn software components agents and non-agents into an agent entity that interact and performer one or more roles into MAS. Because of the great interest in using (Multi Agent System) MAS in a wide variety of applications in recent years, agent oriented methodologies and related modelling techniques have become a priority for the development of large scale agent-base system [7], although recent years have witnessed a great number of theoretical and practical projects in the field of MAS, the development of such system still poses many challenges and remain open field, the main challenge is coordination [8] between people working on this field, some taking a bottom-up view ( bases on goals and roles [9]) other going top-down view ( starting from hierarchical assignments of responsibilities and shared ontology s used in human organizations [10]). Another problem is the lack of standardization in MAS platform and environment. What successful MAS technology needs, among other things, is a rigorous methodology covering the various phases of MAS development process, the following are among other methodologies for MAS modelling as an approach of AOSE: Gaia ( Generic Architecture for Information Availability ) [5]. This is a methodology that distinguishes between analysis and design phases and associates deferent models with these two phases. Gaia focuses on organizational aspects in terms of concepts such as roles, interactions, and acquaintances. Within this article a detailed discussion for Gaia coming next. CoMoMAS [11] focuses on knowledge engineering issues arising in multiagent contexts, proposes also an extension to CommonKADS for MAS. It has a very interesting extension to(cooperation Modeling Language) CML for MAS and a good redefinition of the expertise model. It also defines a new model for cooperation MAS-CommonKADS (Multi-Agent System CommonKADS") [12]. This is another extension of CommonKADS that supports analysis and design of agentoriented systems. MAS-CommonKADS adds objectoriented methods such as the Object Modelling Technique (OMT), Object Oriented Software Engineering (OOSE) and Responsibility Driven Design (RDD) as well as protocol engineering methods such as the Specification and Description Language (SDL) and Message Sequence Charts (MSCs). SODA ( Societies in Open and Distributed Agent spaces ) [13]. This is another method that concentrates on the social (inter-agent) aspects of agent systems and that employs the concept of coordination models Cassiopeia [14]. This is a design method that distinguishes three levels of behavior -elementary, relational, and organizational - and aims at capturing both structural and dynamic aspects of the target system. Aalaadin [15]. This is a general framework that has its focus on the organizational level of multi-agent systems and is built on the three core concepts of agents, groups, and roles. ROADMAP [16][17], which is a modification on Gaia for complex and open and large-scale system by introducing explicit knowledge based models and an interaction model based on UML interaction diagrams. 2

Methodology occurency percentage Figure 1: Publishing percentage of each method in AOM approach Percentage 50 40 30 20 10 0 Gaia CoMoMAS MAS- CommonKADS SODA Cassiopeia Aalaadin ROADMAP DESIRE KADS with ZEUS Others Methods DESIRE [18] is a formal framework for multi-agent modeling, which mainly consists of agent and expertise models. It could be suitable for specifying the design and implementation after the analysis phase. KADS with ZEUS [19] to develop Multi-Agent for Electronic Commerce applications. Figure 1, displays that Gaia occupies the first position in terms of publications and research interests, Gaia presented by M. Wooldridge, N. Jennings, and D. Kinny [8]. 2.2 Approaches based on Object-Oriented Methodologies Unlike the upper approach, this approach provides an engineering process based on objectify the software system components, that models agent and non-agent components with same level of abstraction, the assumption is that an agent entity is basically an object that capable to perform a task, in other words, each agent component is a special form of object that can do some thing. There are several approaches to develop an agent-oriented software systems that as their starting point. Prototypical examples of such approaches are MaSE (Multiagent Systems Engineering") [20]. This method covers design and initial implementation through two languages called AgML (Agent Modeling Language") and AgDL (Agent Definition Language) and builds upon OMT and UML. KGR [21]. This is a design and specification method for a particular class of agents, namely, BDI agents [22]. KGR extends the object modeling technique (OMT) and considers two viewpoints { external and internal { of agent systems. MASSIVE (MultiAgent Systems Iterative View Engineering") [23]. This method covers analysis, design and code generation, and combines standard software engineering techniques such as multi-view modeling, round-trip engineering, and iterative enhancement. AOAD (Agent-Oriented Analysis and Design") [24]. This analysis and design method proposes the use of extended class responsibility cards (CRCs) and the use of both the Object Modelling Technique (OMT) and the Responsibility Driven Design (RDD) method known from object-oriented development MASB (Multi-Agent Scenario-Based") [25]. MASB is an analysis and design method that covers issues of both objects and agents via behavior diagrams, data models, transition diagrams, and object Figure 2, displays that MaSE methodology have the first position in term of publication and research interests. 2.3 Extending of Object - Oriented modeling techniques This AOSE approach give emphasis on extending modeling techniques developed for Object Oriented software engineering, specifically Unified Modeling Language (UML) to be extended for the next generation of Agent Oriented software engineering (AUML). Presented by J. Odell, B. Bauer, J. Muller, [26,27]. UML has wide acceptance for representation of artificats in object-oriented software. Extending UML modeling techniques has recently increasingly gains interests in the research field, as a result, cooperation has been established between the Foundation of Intelligent Physical Agents (FIPA www.fipa.org ) and the Object Management Group (OMG www.omg.org ). For extending UML into AUML. This approach doesn t suggest pre-assumption toward agent and non-agent software s entities. but as UML is presented as the most dominant modeling technique for Object Oriented Software Engineering (OOSE), it argues that AOSE is a natural evolution of its ancestor OOSE. Compassing software agents characteristics, calls for extending UML into Agent UML... 3

Methodology occurrency persentage 80 Figure 2: Publishing percentage for methods of OOM approach Persentage 60 40 20 0 MaSE KGR MASSIVE AOAD MASB Others Methods..To employ agent base software, a specification technique must support the whole software engineering process from planning, through analysis and design, and finally system construction, transition, and maintenance. To preserve agency properties, AUML proposed the main modification can occurs on the following,: Dynamic model: [26] developing UML modeling techniques as interaction diagrams (sequence, collaboration and state diagram) and generate AUML interaction protocols Static model:[27] to capture the physicality and state of an agent and its communications with conceptual and implementation models, by creating Agent class diagram and package diagram. 3.0 Evaluations criteria From the fact that AOSE combines SE and Agency theory, it is necessary to establish evaluation criteria concurrent with SE objectives as well as preserves Agents characteristics, which enables us to give a judgment on these methodologies and theirs modeling techniques, actually, a numerous criteria for evaluating the quality of modeling techniques of a generic Software Engineering has been published. In this article the selection of criteria of software engineering methodologies and modeling techniques concentrates on specification should be naturally existed and supported by a given methodology, to represent (model) very generic software system. Based on the criteria [28] [29]: Preciseness: the semantics of a modeling technique must be unambiguous in order to avoid misinterpretation of the models (of the modeling technique) by those who use it. Accessibility: a modeling technique should be comprehensible to both experts and novices. Expressiveness (and applicable to multiple domains): a modeling technique should be able to present: The structure of the system; The knowledge encapsulated within the system; The data flow within the system; The control flow within the system; The interaction of the system with external systems. Modularity& objectiveness: a modeling technique should be expressible in stages. That is, when new specification requirements are added, there is no need to modify pervious parts, and these may be used as part of the new specification. Complexity Management: a modeling technique should be expressed, and then examined, at various levels of detail. Sometimes, high-level requirements are needed, while in other situations, more detail is required. Examination and development of all levels should be facilitated. Executability (and testability): either a prototyping capacity or a simulation capacity should be associated with at least some aspects of the modeling technique. That is, the modeling technique has related tools that allow (possibly inefficient) computation for sample input. These should demonstrate possible behaviors of the system being modeled, and help developers determine whether the intended requirements have been expressed. Refinability : a modeling technique should provide a clear path for refining a model through gradual stages to reach an implementation, or at least for clearly connecting the implementation level to the design specification. Analyzability: A methodology or, preferably, an associated tool is available to check the internal consistency or implications of the models, or to identify aspects that seem to be unclear, such as the interrelations among seemingly unrelated operations. Such tools encourage both consistency and coverage. Openness & portability: a modeling technique should provide a good basis for modeling AO systems without coupling them to a specific architecture, infrastructure or programming language. Formalization: The modeling constructs should be complete and enough to Instruct or even generate implementation. The number of such constructs Should be small, the composition rules should be straightforward. Yet another facet of evaluating -a software that holds Agents within- (AOSE) must be examined with the capability of representing such entities (Agents) in the system. Accordingly, the need is obvious for additional evaluation criteria for modeling software system which has agents within, this criteria must generated from agency characteristics to be checked in a given methodology and its modeling techniques. The following criteria of evaluation is based agent s software characteristics [30, 31, 32, 33] to check how much each methodology can represents these characteristics: Autonomy: unlike objects, agents may be active and are responsible for their own activities: the agent has control over both its reactive and proactive behaviors. The modeling technique should support the capability of describing an agent's self-control feature. 4

Complexity: AO systems are basically having sets of components (agents) that interact with each other in order to achieve their goals. These systems may consist of decision making mechanisms, learning mechanisms, reasoning mechanism and other complex algorithms. Modeling complex algorithms and mechanisms requires strong expressive power and many layers of details. A modeling technique should support such expressiveness in order to model the functionality of AO systems. Moreover, the complexity feature requires that modeling technique should be modular, support complexity management and describe the complex nature of an agent. Adaptability: AO systems have to be flexible in order to adjust their activities to the dynamic environmental changes. The adaptability feature may require that a modeling technique be modular and that it can activate each component according to the environmental state. Concurrency: an agent may need to perform several activities/tasks at the same time. The concurrency feature raises the requirement that some AO systems must be designed as parallel processing systems. This requires ability to express parallelism and concurrency in the design and implementation/deployment stages. Distribution: multi-agent systems are sometimes working on different hosts and should be distributed over a network. This requires ability to express distribution in the design and implementation/deployment stages. Communication richness: a basic definition of an agent consists of its autonomous activity. As such, the agent must establish communication with its environment. The environment may include other agents and information sources. The communication is characterized by its type (either inter-agent communication or intra-agent communication), its content and its architecture (e.g. clientserver, peer-to-peer). This requires that a modeling technique should be able to express the communication characterization in order to produce agent communication command or sentences during the implementation stage. 3.0 Evaluation of the main approaches of AOSE. Section 3 and its subsection give an overview of the main approaches with supported example. This section will apply the criteria set for software engineering and criteria to model the agency characteristics in software. 3.1 Agent-Oriented Methodologies AOM (Gaia) Software Engineering evaluation Preciseness & clarity: mostly textual representations, the liveness and safety properties, which are used for depicting the functionality of a role in a formal way (i.e., for each text and notation there is a clear meaning and interpretation), makes Gaia prevents misinterpretation of the modeled functionality. Accessibility: Gaia is easy to understand and use due to its simple models and their clarity. Understanding and usage of Gaia can be achieved by following the description of its models. Expressiveness: Gaia is expressive and can handle a large variety of systems due to its generic structure. However, Gaia is mostly suitable for small and medium scale systems. This is because of its flatness, which limits the ability to model large amount of details. The structure of the system, the encapsulated knowledge, the data and control flows are not presented explicitly within Gaia. Modularity & objectiveness: Gaia is mostly modular due to its design with some building blocks such as roles, protocols, activities and agent types. In Gaia, one can assign new roles to agents and remove ones with no effect on the internal model of the roles. However, changes within the protocol might cause changes within the internal structure of the role. These result in changes in permissions of the role, thus limits the modularity of Gaia. Complexity Management: in Gaia, there is no hierarchical presentation or any other mechanism for complexity management. The system description is flat depicted in the Role Schema with no any hierarchy or distribution. Executability: this issue is not dealt with within Gaia. Refinability: this issue is not dealt with within Gaia. Analyzability: this issue is not dealt with within Gaia. Openness and portability: Gaia provide role oriented architecture, without coupling to a certain infrastructure or programming language. It leaves the implementation issue open for the programmer to deal with. And do not specify a programming paradigm support. Formalization: the impact of textual representation, retunes more than one meaning for a text, or at least, not grantee to have a unique role model for the same role and different prospective. Software agents characteristics Autonomy: in Gaia the autonomy is expressed by the fact that the role encapsulates its functionality (i.e., it is responsible for it). This functionality is internal and is not affected by the environment, thus represents the role's autonomy. In addition, in Gaia one can model alternative computational paths, which gives the role (and agents that consist of this role) the autonomy in making decisions. Complexity: in Gaia one can describe the agent's complexity by integrating several models: the role model, the acquaintance model and the agent model. However, it is difficult to model some procedural processes and complex computation in Gaia, agent learning, reasoning, and decision support algorithms are not supported. Adaptability: adaptability in Gaia can be expressed by the liveness properties. The liveness property operators within Gaia symbolize optional execution, thus expresses the potential adaptability of the agent to environmental changes (although the changes are not described explicitly). Concurrency: this issue is not dealt with within Gaia. Distribution: Gaia allows the expression of distribution via the acquaintance model, where each role can be performed on any 5

host or processor. Yet, it does not explicitly address the distribution issue. Communication richness: the communication aspects that are dealt within Gaia are the protocols and the communication paths between agents. However, the content of a message and the communication architecture are not expressed in any of the Gaia models. 4.2 Multiagent Software Engineering (MaSE) Software Engineering evaluation Preciseness: MaSE provide graphical and textual representations, with a hierarchy structure for goals, nondirected and directed nodded graphs for role model, for agent model, with textual declaration for each structure or node. The structures and graphs have precise meanings. Accessibility: The structural form of MaSE offers simplicity as well as understandable view for average users of this methodology, it moves smoothly from one step to another. Expressiveness: MaSE, naturally support goal hierarchy structure modeling of software, data and control flow performed by Agent Class Diagram and Concurrent Task diagram. Knowledge encapsulation partially represented within Rule Container in Class Architecture. Modularity and objectiveness: MaSE highly based on goal structure (modularity), then it assigns agents to perform a group of goals, the goal is represented by at least one module, changing in goals like creating or deleting will call a restructuring for that part of the goal hierarchy. Complexity Management: MaSE manage complicity with the hierarchical structure it offers, complex goals divided into more simple sub-goals, and then assign adjacent sub goals into roles to be carried out by an appropriate agent. Executability: AgentTool is prototyping tool presented to model the software system developing process using MaSE, through all phases of development. Refinability: MaSE provide a clear path from system design to implementation, the outcome of MaSE design phase supports the object-oriented view of programming, even though, it started with its analysis phase with goal structural hierarchy attitude. Analyzability: AgentTool can be used a CASE tool for constancy and coverage of the models. Openness and portability: system designed in MaSE could be implemented in several different ways from the same design. Independent from specific architecture, and programming language. Formalization: MaSE presented as full cycle of software engineering proves, with formal diagrams, that enough defined to be implemented. Software agents characteristics Autonomy: this agent s characteristic in not supported into MaSE, agents in general have reactive behaviour. Complexity: with Agent Class Architecture with the rules container and Communication Class Diagram of MaSE represent pre-planed reasoning and Decision support algorithms, learning algorithms is not sustained. Adaptability: not supported in MaSE, each agent mapped with pre-assigned role/roles, and every role contains a group of goals, any changing on environments appeals to restructuring of the goal hierarchy. Concurrency: MaSE does not sufficiently support concurrency; as for each role consist of one or more tasks to satisfy its goal, time management in Concurrent Task Diagram manages the concurrent tasks in a given tasks of a role not between roles in general. Distribution: represented by Deployment Diagram of MaSE. Communication Richness: communication between agents and environment in MaSE are restricted with initiator, responder, scenario, and binary conversation exchange between two agents through a directed finite state machine represented in Communication Class Diagram. 4.3 Object Oriented modeling extension (AUML) Software Engineering evaluation Preciseness: emphasis on symbolic representations, with less textual definition each symbol has an obvious meaning, the out come is generally diagrams. Accessibility: must study and understanding the meaning of the AUML diagrams and symbols, then it would be easy to depict the meaning from these diagrams. Expressiveness: with AUML diversity of diagrams to represent the static and dynamic structure, provide a wealthy range of representing the software development of all phases with data control and data flow, the knowledge encapsulation is limited, can be represented by Statechart Diagram and Agent Class Diagram. Modularity and objectiveness: by its nature as object oriented descendent, AUML supports objectiveness, the modules represented as methods in those objects. Modules carried out by objects (or Agents), creating new module must assigned with that object or agent, with no changing in software components. Complexity Management: AUML express the software with multiple levels of details from Use-Case functional representation, and collaborative (sequence, activity) diagrams and even for single activity by statechart diagram. Excutability: AUML provide prototyping and sampling for software, transfer prototyping into coding (e.g. Rational Rose software ), which can represent the software behavior before even start coding. Refinability: Diagrams in AUML reflects the final system design and then comes coding or implementations by Object Oriented language (with a prospective of agent support libraries). Analyzability: consistency can be checked with formal semantic of AUML diagrams using many CASE tools that supports UML modeling techniques. Openness and portability: AUML supports agent and object oriented architecture, without coupling to a certain infrastructure or programming language. Likely to be implemented by any Object with Agents programming (OOP, AOP) paradigm. 6

Formalization: the symbols and diagrams in AUML support full-life cycle of Software Engineering have one and only one formal meaning that could be straightforward transformed into implementation. Software agents characteristics Autonomy: can be expressed by AUML potential class diagram within capabilities, service description and constrains parts. These parts are not affected by environment, but represent agent s mentality; the proposed knowledge representation used for this matter is not fully set yet [34]. Complexity: AUML relatively support agent system complexity for multi-agent collaboration by developing Agent Interaction Protocol (AIP) connected to Agent Class diagram though Communication Acts Protocol into Agent - head automata, these diagrams support reasoning algorithms, but learning and decision support algorithms are not enough supported. Adaptability: Adapting changes in dynamic environment is limited into AUML, which is lacking to knowledge representation about the environment [46], an Agent Class Diagram may activate one of outgoing Communication acts based on incoming Communication Act Protocol. Concurrency: concurrencies represented by Agent Interaction Protocol with the possibility of layer, nested, or interleave protocol types. Distribution: dealt with by the Deployment Diagram of AUML, which is the same Deployment Diagram in Object UML [see any reference of UML]. Communication Richness: can be represented by incoming and outgoing Communication Acts, and more elaborated in Agent Interaction protocol, but these communication mostly the message contents and architecture are represented by preplaned scenarios. Software Engineering evaluation Software agents characteristics evaluation Criteria Methods AOM (Gaia) OOM (MaSE) Extension of OOSE (AUML) Preciseness * * + Accessibility + + + Expressiveness * * * Modularity & Objectiveness - + * Complexity Management - + + Executability NS + + Refinability NS * + Analysability NS + + Openness & Portability + + * Formalization - * + Autonomy * NS - Complexity - - - Adaptability * NS - Concurrency NS - * Distribution NS * * Communication Richness - - - Table 1: Methodologies and modelling techniques evaluation summary Legend: + : Good * : Satisfactory - : Dissatisfactory NS: Not Supported Conclusion An over view of the evaluation summary results (table 1), shows that Gaia need enhancement in Software Engineering domain criteria, specially with aspects concerning design and implementation, however, provides a little better results with agent characteristics domain criteria compared to others. MaSE has good results in the Software Engineering parts of analysis,design and implementation, but with a shortage in terms Agent characteristics modelling criteria, no wonder because agent in this methodology is dealt with as a special case of object, that provides great limits on agency properties. AUML has great results concerning Software Engineering criteria, some of agent characteristic are satisfactorily represented. Conceivably, the people work with AUML development in FIPA a ware of this deficiency, and they set up technical groups to develop suitable augmentation into AUML to encounter agency properties. References: [1] Shari Lawrence Pfleeger: Software Engineering,The Product of Quality Software, Second Edition, Macmillan Publishing 1991 [2] H. Van Dyke Parunak, Jemes J. Odell, ERIM, : Representation Social Structure in UML, ERIM 2001 [3] Jemes Odell, FIPA publication : Agents, August 1998 [4] R. Jennings, On Agent-Based Software Engineering, Artificial Intelligence, 117 (2), 2000, 277-296. [ 5] Michael Wooldridge, Nicholas Jennings, David Kinny, Autonomous Agent and Multi- Agent System, 3, 285-312,2000 : The Gaia Methodology for Agent-Oriented Analysis and Design. 2000 Kluwer Academic Publisher [6]12 Scott A. Deloachm Mark Wood, Intelligent Agent VII,LNAI,pp. 46-60,2001: Developing Multiagent Systems with agenttool, Springer-Verlag Berlin Heidelberg 2001 7

[7] 6 Arsene Sabas, Mourad Badri & Sylvain Delisle : A Multidimentional Framework for the Evaluation of Multiagent System Methodologies, Canda 2001 [8]Virginia Dignum, John Jules Mayer, Hans Weigand, Frank Dignum : An Organizational Oriented Model for Agent Societies, Netherlands 2002 [9]avid Kinny, Michael Georgeff, and Anand Rao. A methodology and modelling technique for systems of BDI agents. In W. van der Velde and J. Perram, editors, Agents Breaking Away: Proceedings of the Seventh European Workshop on Modelling Autonomous Agentsin a Multi-Agent World MAAMAW 96, (LNAI Volume 1038). Springer-Verlag: Heidelberg, Germany 1996 [10]acques Ferber: Multi-Agent Systems An Introduction to Distributed Artificial Intelligence pp 31-33, Addison Wesley Longman 1999. [11] N. Glaser. Contribution to Knowledge Modelling in a Multi-agent Framework. PhD thesis, University Henry Poincar_e, Nancy, France, 1996. [12] C. Iglesias, M. Garijo, J.C. Gonzales, and J.R. Velasco. Analysis and design of multi-agent systems using MAS-CommonKADS. In M.P. Singh, A. Rao, and M.J. Wooldridge, editors, Intelli-gent Agents IV. Proceedings of the Fourth International Workshop on Agent Theories, Architec-tures, and Languages (ATAL-97), Lecture Notes in Artificial Intelligence Vol. 1365, pages 313{326.Springer-Verlag, 1998. [13] 30L. Chung, B.A. Nixon, E. Yu, and J. Mylopoulos. Nonfunctional requirements in software engineering. Kluwer Academic Press, Boston et al., 2000. [14 ]. Omicini. SODA : Societies and infrastructures in the analysis and design of agent-based systems. In P. Ciancarini and M.J. Wooldridge, editors, Agent-oriented software engineering. Proceedings of the First International Workshop (AOSE-2000), Lecture Notes in Artificial Intelligence, Vol.1957, pages 185{194. Springer-Verlag, 2001. [15] A. Drogoul and A. Collinot. Applying an agent-oriented methodology to the design of artificial organizations: a case study in robotic soccer. Autonomous Agents and Multi-Agent Systems,1(1):113{129, 1998. [16] 14 Thomas Juan, Leon Sterling, Michael Winikoff : Assembling Agent Oriented Software Engineering Methodologies from Features, Kluer Online, Electronic Commerce Research 2003. [17] omas Juan Adrian Pearce Leon Sterling Copyright 2002 ACM 1-58113-480-0/02/0007: ROADMAP: Extending the Gaia Methodology for Complex Open Systems AAMAS 02, July 15-19, 2002, Bologna, Italy. [18] M. T. Brazier, B. M. Dunin-Keplicz, N. R. Jennings, and Treur J. DESIRE: Modelling multi-agent systems in a compositional formal framework. Int Journal of Cooperative Information Systems, 1(6):67 94, January 1997. [19] Darryl N. Davis, Yuan Luo, Kecheng Liu, Electronic commerce research : Combining KADS with ZEUS to Develop a Multi-Agent E- Commerce Application, Kluwer Academic Publishers 2003. [20] D. Kinny, M. George, and A. Rao. A methodology and modelling technique for systems of BDI agents. In W. van der Velde and J. Perram, editors, Agents Breaking Away: Proceedings of the Seventh European Workshop on Modelling Autonomous Agents in a Multi-Agent World (MAAMAW-96), Lecture Notes in Artificial Intelligence Vol. 1038, pages 56{71. Springer-Verlag, 1996. [21] M. Wood and S.A. DeLoach. An overview of the multiagent systems engineering methodology. In P. Ciancarini and M.J. Wooldridge, editors, Agent-oriented software engineering. Proceedings of the First International Workshop (AOSE-2000), Lecture Notes in Artificial Intelligence, Vol. 1957, pages 207{222. Springer-Verlag, 2001. [22] M.P. George_ and A.S. Rao. BDI agents: From theory to practice. In Proceedings of the First International Conference on Multi-Agent Systems (ICMAS-95), pages 312{319, 1995. [23] J. Lind. Iterative software engineering for multiagent systems: The MASSIVE method. Lecture Notes in Computer Science, Vol. 1994. Springer-Verlag, Berlin u.a., 2001. [24] B. Burmeister. Models and methodology for agent-oriented analysis and design. In K. Fischer, editor, Working Notes of the KI96 Workshop on Agent-oriented Programming and Distributed Systems. DFKI Dokument D-96-06, 1996. [25] B. Moulin and M. Brassad. A scenario-based design method and an environment for the development of multiagent systems. In D. Luckose and C. Zhang, editors, Proceedings of the FirstAustralian Workshop on DAI, Lecture Notes in Artificial Intelligence, pages 216{296. Springer-Verlag, 1996. [26] Jorg P. Muller, Barhard Bauer, Jemes Odell, Agent UML : A formalism for Specifying Multiagent Interaction, Springer verlag, Berlin, pp. 91-103, 2001 [27] Barnhard Bauer, Siemens AG, Corporate Technology, Information and Communications : UML class Diagrams Revisited in the Context of Agent- Based Systems, Germany 2002 [28] Katz, Draft of Formal Specification Method Book, http://www.cs.technion.ac.il/~cs236368/,2000. [29] M. A. Ardis, J. A. Chaves, L. J. Jagadeesan, P. Mataga, C.Puchol, M. G. Staskauskas and J. Von Olnhausen, AFramework for Evaluating Specification Methods for ReactiveSystems, Experience Report, Proc. of 17th Intl. Conf. onsoftware Engineering, 1995.967, 47-62, Springer, 1995. [30] N. R. Jennings, On Agent-Based Software Engineering, Artificial Intelligence, 117 (2), 2000, 277-296 [31] Jacques Ferber: Multi-Agent Systems An Introduction to Distributed Artificial Intelligence pp 31-33, Addison Wesley Longman 1999. [32] Shehory and A. Sturm, Evaluating Agent-Based System Modeling Techniques, Technical Report TR-ISE/IE-003-2000, Faculty of Industrial Engineering and Management Technion. [33] R. Jennings and M. Wooldridge, Agent-Oriented Software Engineering, Handbook of Agent Technology (ed. J.Bradshaw) AAAI/MIT Press, 2000 [34] Private Speech Mr. James Odell through e-mail 8