Term Paper Compare and Contrast five major Agent Oriented Software Engineering methodologies in the areas of Cooperation & Interaction, Organization/Organizational Design, Communications
Download 48.12 Kb.
|
- Navigate this page:
- CIS 890 – Dr. Scott Deloach
- “Agent Oriented Analysis using MESSAGE/UML”
| Term Paper
Compare and Contrast five major Agent Oriented Software Engineering methodologies in the areas of Cooperation & Interaction, Organization/Organizational Design, Communications, Collaboration & Coordination Submitted by Padmaja Havaldar CIS 890 – Dr. Scott DeloachAbstract: Software agents provide a new way of analyzing, designing, and implementing complex software systems. Currently, the agent-oriented approach to software development is gaining recognition outside of the research phase and is being widely used in the development of large-scale industrial applications. The need then arises for systematic methodologies to guide and support developers through the various stages of software development. Many agent-oriented methodologies have been proposed which attempt to solve the complexity of multi agent systems, but this diversity of methodologies may hinder progress if they are not well understood. This paper presents an analysis of five agent oriented software engineering methods, namely, MaSe, AgentUML, MESSAGE, Gaia, and SODA in terms of their conceptual foundations. Each method is described explaining their role in cooperation and interaction between agents, their organizational design, communications, collaboration and coordination. We consider how these various methodologies compare to each other.
AOSE Methodologies are an organized, documented set of procedures and guidelines for one or more phases of the software life cycle. They provide a language or notation and a step-by-step approach to agent based software. In this paper I will present an overview of five agent oriented software engineering methodologies. The focus is on comparing these methodologies on the basis of their organizational design, communications, collaboration, coordination, cooperation and interaction between agents. Section 2 of this paper briefly describes these concepts. The rest of the paper is organized as follows: Section 3 describes the Gaia methodology and it’s conceptual framework, section 4 describes the MaSe methodology. In section 5 and 6, we will look at the MESSAGE and SODA methodologies in terms of their conceptual foundations and in section 7, I will describe the AgentUML methodology. Section 8 deals with comparison between the methodologies and section 9 summarizes the paper in the conclusion. 2. About the conceptual framework: In a multi-agent system, agents come together to form a kind of abstract society; hence their interaction, coordination, cooperation, collaboration and communication play an important role in solving problems that no single agent can handle on its own. This paper analyses the above-mentioned methodologies in terms of these concepts along with their organizational design. I will briefly explain the motives of these concepts. An interaction occurs when two or more agents are brought into a dynamic relationship through a set of reciprocal actions. This action may be direct through other agents or through the environment [5]. Interaction is a necessary element for the development of social organizations. In Cooperation, the goals of agents are compatible and the chances of one of the agents surviving are enhanced by the other agent. The agents cooperate among themselves to reach their goals even though there is a competition over who gets to reach their goals. Since the agents cooperate, tasks have to be allocated. This forms the essence of collaboration. When we allocate tasks, the need arises to coordinate the agent’s actions in order to avoid conflicts. There are various coordination protocols to ensure efficient conversation between agents. An organizational design is an arrangement of relationships between components that produce a system with qualities and capabilities beyond those of the individual components [5]. We can look at it like a class of organizations. There are specific roles assigned to the agent classes and there is a set of relationships between the roles. Communications form the basis of interaction between agents in muti agent systems. It is carried out in the form of signals between agents and both the agents should comprehend these signals. 3. The Gaia Methodology: Wooldridge, Jennings and Kinny [3] present the Gaia methodology for agent-oriented analysis and design. Gaia is a general methodology that supports both the micro-level (agent structure) and macro-level (agent society and organization structure) of agent development. The motivation behind Gaia is that existing methodologies fail to represent the autonomous and problem-solving nature of agents; they also fail to model agents' ways of performing interactions and creating organizations. Using Gaia, software designers can systematically develop an implementation-ready design based on system requirements. The first step in the Gaia analysis process is to find the roles in the system, and the second is to model interactions between the roles found. Roles, in the organization, consist of four attributes: responsibilities, permissions, activities and protocols. Responsibilities are of two types: liveness properties - the role has to add something good to the system and safety properties - prevent and disallow that something bad happens to the system. Permissions represent what the role is allowed to do, in particular, which information it is allowed to access. Activities are tasks that a role performs without interacting with other roles. Protocols are the specific patterns of interaction, e.g. a seller role can support different auction protocols, e.g. ``English auction''. Gaia has formal operators and templates for representing roles and their belonging attributes; it also has schemas that can be used for the representation of interactions. In the Gaia design process, the first step is to map roles into agent types, and then to create the right number of agent instances of each type. The second step is to determine the services model needed to fulfill a role in one or several agents, and the final step is to create the acquaintance model for the representation of communication between the agents. It identifies possible communication bottlenecks but does not define messages or when they are sent. 4. The MaSe Methodology: The Multi agent Systems Engineering (MaSe) methodology, builds upon the work of many agent based approaches for analyzing, designing and building multi agent systems and combines them into a complete end-to-end methodology.[6] MaSE is similar to Gaia with respect to generality and the application domain supported, but in addition MaSE goes further regarding support for automatic code creation through the MaSE tool. The motivation behind MaSE is the current lack of proven methodology and industrial-strength toolkits for creating agent-based systems. The goal of MaSE is to lead the designer from the initial system specification to the implemented agent system [2]. The MaSE methodology is divided into seven sections (phases. Capturing goals, the first phase, transforms the initial system specification into a structured hierarchy of system goals. This is done by first identifying goals based on the initial system specification's requirements, and then ordering the goals according to importance in a structured and topically ordered hierarchy. Applying Use Cases, the second phase of the organizational design, creates use cases and sequence diagrams based on the initial system specification. A use case presents the logical interaction paths between various roles in and the system itself. Sequence diagrams are used to determine the minimum number of messages that have to be passed between roles in the system. The third phase is refining roles; it creates roles that are responsible for the goals defined in phase one. In general each goal is represented by one role, but a set of related goals may map to one role. Together with the roles, the agents collaborate by creating set of tasks; the tasks define how to solve goals related to the role. The fourth phase, creating agent classes, maps roles to agent classes in an agent class diagram. This diagram resembles object class diagrams, but the semantic of relationships is high-level conversation as opposed to the object class diagrams' inheritance of structure. The fifth phase, constructing conversations, defines a coordination protocol in the form of state diagrams that define the conversation state for interacting agents. In the sixth phase, assembling agent classes, the internal functionality of agent classes is created. The final phase, system design creates actual agent instances based on the agent classes and the final result is presented in a deployment diagram [2]. A system must be arranged in a Deployment Diagram before it can be implemented in code. This is due to the differences between agents and agent classes. An agent requires information such as a hostname or address to participate in a multiagent system. A Deployment Diagram also offers another opportunity for the designer to tune the system. Agents can be arranged among various machine configurations in order to better use available processing power of network bandwidth. A final element to consider is automatic code generation. The MaSE methodology is concerned with actually engineering agent systems. As such, all of the steps of the methodology work toward that end. Code generation is not a part of MaSE at this time, but is assumed to happen just after this phase [6]. MaSE aims at providing completely automatic code generation based on the deployment diagram in the future. 5. AgentUML: As Agent oriented software engineering is becoming popular in the industry it is necessary to relate it to the object oriented technology, which is already accepted by the industry. The UML (Unified Modeling language) is an object-oriented graphical modeling language with well-defined syntax and semantics. It helps you specify, visualize, and document models of software systems, including their structure and design, in a way that meets all of these requirements. The UML is an extensible language, which allows new constraints to be added to address new issues in software development without changing the original syntax and semantics. Therefore it is extended to support the distinctive requirements of multi-agent systems giving rise to the Agent UML methodology. AUML has extended UML’s interaction diagrams to handle agent interaction protocols. The AUML protocol description represents an interaction, a set of messages exchanged among different agent roles within collaboration to affect a desired behavior of other roles or agent instances. An agent interaction protocol (AIP) describes a communication pattern as an allowed sequence of messages between agents and the constraints on the content of those messages, for example: the FIPA contract net protocol. Elements of protocol diagrams:
In UML, role is an instance focused term. In the framework of agent oriented programming by Agent-role a set of agents satisfying distinguished properties, interfaces, service descriptions or having a distinguished behavior are meant. Agents can perform various roles within one interaction protocol.
The agent lifeline in protocol diagrams defines the time period during which an agent exists, represented by dotted vertical lines. The lifeline starts when the agent of a given agent role is created and ends when it is destroyed.
Because protocols can be codified as recognizable patterns of agent interaction, they become reusable modules of processing that can be treated as first-class notions.
The main purpose of protocols is the definition of communicative patterns, i.e., patterns of messages sent from one agent role to another.
Nested Protocols can be defined either within or outside a protocol diagram where it is used or outside another protocol diagram. The input parameters of nested protocols are threads of interaction which are carried on in the nested protocol and messages which are received from other protocols.
The purpose of protocol templates is to create reusable patterns for useful protocol instances. UML’s dynamic models are useful for expressing interactions among agents. Interaction diagrams capture the structural patterns of interactions among objects. Sequence diagrams are one member of this family; collaboration diagrams are another. The two diagrams contain the same information [8]. Figure 1depicts some basic elements for agent communication. The rectangle can express individual agents or sets (i.e., roles or classes) of agents. The basic format for the box label is agent-name/role: class. The rectangular box can also indicate a general set of agents playing a specific role. To specify that the role is to be played by a specific class of agent, the class name would be appended. 
Fig 1: Basic format for agent communication in AUML AUML provides tools for specifying agent interaction protocols, representing the internal behavior of an agent, representing role specification, packages with agent interfaces, and deployment diagrams indicating mobility 6. The SODA (Societies and Infrastructures in the Analysis and Design of Agent-based Systems) Methodoloy: The notion of society should play a central role in agent-oriented soft-ware engineering as a first-class abstraction around which complex systems can be designed and built as multi-agent systems. Agents are not simple software components to be first built, then combined: they are goal-driven individuals, who assume to live and interact with other individuals within a society. An effective agent-oriented methodology was needed for the analysis and design of agent societies. The SODA agent-oriented methodology for the analysis and design of Internet-based systems is based on the core notion of task. SODA promotes the separation of individual and social issues, and focuses on the social aspects of agent-oriented software engineering Since it intentionally does not address intra-agent issues, SODA is not a complete methodology, and focuses instead on the social aspects of agent-oriented software engineering, by exploiting coordination models and technologies [ 9]. Agents in a multi-agent system interact by living and working within their environment, and by relating with other agents. We cannot analyze social organizations without accounting for interactions. Correspondingly, inter-agent aspects in multi-agent systems basically amount to two strongly related issues: the social and the environment one. In the organizational design, the SODA analysis phase exploits three different models:
achieved, which are associated to roles and groups
available, which are associated to abstract resources
modeled in terms of interaction protocols, expressed as information required and provided by roles and resources, and interaction rules, governing interaction within groups. In all, the results of the SODA analysis phase are expressed in terms of roles, groups, and resources. SODA just concentrates on inter-agent issues, like the engineering of societies and infrastructures for multi-agent systems. Since this conceptually covers all the inter-actions within an agent system, the design phase of SODA deeply relies on the notion of coordination model [9] The SODA design phase is based on three strictly related models:
to topological abstractions. In all, the results of the SODA design phase are expressed in terms of agent classes, societies of agents, and infrastructure classes [9]. 7. The MESSAGE (Methodology for Engineering Systems of Software Agents) methodology: MESSAGE is an AOSE methodology, which builds upon current software engineering practices covering analysis and design of Multi Agent Systems, which is appropriate for use in mainstream software engineering departments. MESSAGE aims to combine the best features on agentUML and Gaia and to define an agent-oriented methodology that encompasses requirements analysis and design It has well defined concepts and a notation that is based on UML whenever appropriate. MESSAGE extends UML by contributing agent knowledge level concepts, and diagrams with notations for viewing them. The diagrams extend UML class and activity diagrams. The MESSAGE modeling language shares a common metamodelling language (meta-metamodel) with UML. It extends the UML metamodel with ’knowledge level’ agent-oriented concepts. The MESSAGE methodology consists of applicability guidelines, a modeling notation, and a process for analysis and design of agent systems [10] Knowledge-level concepts: MESSAGE concepts and describes different views on the analysis. Most of the MESSAGE knowledge level entity concepts fall into the main categories: Agent: An Agent is an atomic autonomous entity that is capable of performing some (potentially) useful function. Organization: An Organization is a group of Agents working together to a common purpose. Role: The distinction between Role and Agent is analogous to that between Interface and (object) Class: a Role describes the external characteristics of an Agent in a particular context. An Agent may be capable of playing several roles, and multiple Agents may be able to play the same Role. Resource: Resource is used to represent non-autonomous entities such as databases or external programs used by Agents. Standard object-oriented concepts are adequate for modeling Resources. Task: A Task is a knowledge-level unit of activity with a single prime performer. A task has a set of pairs of Situations describing pre- and post-conditions. If the Task is performed when a precondition is valid, then one can expect the associated post condition to hold when the Task is completed. Interaction and Interaction Protocol: The MESSAGE concept of Interaction borrows heavily from the Gaia methodology [6]. An Interaction by definition has more than one participant, and a purpose which the participants collectively must aim to achieve. The purpose typically is to reach a consistent view of some aspect of the problem domain, to agree terms of a service or to exchange results of one or more services. An Interaction Protocol defines a pattern of Message exchange associated with an Interaction. Goal: A Goal associates an Agent with a Situation. If a Goal instance is present in the Agent’s working memory, then the Agent intends to bring about the Situation referenced by the Goal. MESSAGE defines a number of views that focus on overlapping sub-sets of entity and relationship concepts. Organization view (OV) – This shows ConcreteEntities (Agents, Organizations, Roles, Resources) in the system and its environment and coarse-grained relationships between them (aggregation, power, and acquaintance relationships). Goal/Task view (GTV) – This shows Goals, Tasks, Situations and the dependencies among them. Agent/Role view (AV) – This focuses on the individual Agents and Roles. For each agent/role it uses schemata supported by diagrams to its characteristics such as what Goals it is responsible for, what events it needs to sense, what resources it controls, what Tasks it knows how to perform, etc. Interaction view (IV) – For each interaction among agents/roles, shows the initiator, the collaborators, the motivator (generally a goal the initiator is responsible for), the relevant information supplied/achieved by each participant, the events that trigger the interaction, other relevant effects of the interaction. Domain view (DV) – Shows the domain specific concepts and relations that are relevant for the system under development 8. Comparison between methodologies: The Gaia methodology requires that inter-agent relationships (organization) and agent abilities are static at run-time. But with comparison to MaSe, domain restrictions of MaSE are similar to those of Gaia's, but in addition it requires that agent-interactions are one-to-one and not multicast. MaSe is more detailed than the Gaia methodology. Both Gaia and MaSe are based on roles. Mase uses goals and use cases while Gaia provides no help in defining roles. MaSe provides detailed description of the actual communication patterns and data in the conversation diagrams while in Gaia, the acquaintance model defines the lines of communication between agents. I observed that so far no empirical tests have been carried out to evaluate the benefits of the AGENT UML framework. But we see two concrete advantages of these extensions: Firstly, they make it easier for users who are familiar with object-oriented software development but new to developing agent systems to understand what multiagent systems are about, and to understand the principles of looking at a system as a society of agents rather than a distributed collection of objects. Secondly, the time spent for design can be reduced by a minor amount, which grows with the number of agent-based projects. GAIA represents an extension of the software engineering approach and has a solid social foundation. AUML on the other hand, represents the pure software engineering approach and is an extension of the standard software engineering approach - UML As far as SODA is concerned, the main reference for the development of SODA is represented by the pioneering work on Gaia [3]. Gaia was the first agent-oriented software engineering methodology that explicitly took into account societies (there, mainly referred to as organizations) as first-class entities, by providing a coherent conceptual framework for the analysis and design of multi-agent systems. Even though at an early stage of its development, SODA addresses some of the shortcomings of Gaia, which does not suit well open systems, In addition, SODA is the first agent-oriented methodology to explicitly take the agent environment into account, and provide engineers with specific abstractions and procedures for the design of agent infrastructures. While applying existing software engineering concepts, AgentUML (AUML) for example defines extensions to UML with notations suited for agent concepts. Although this notation is useful and has been adopted within MESSAGE, it does not have the concept of agent at its centre, i.e. specifying an object’s behavior in terms of interaction protocols does not make it an agent. These methodologies define a number of models for analysis and design such as. The Gaia methodology has two analysis models and three design models. While the analysis models are based on well-defined concepts, these only represent a subset of the concepts required for agent-oriented analysis. MESSAGE combines the best features of the above approaches. 9. Conclusion: This paper presented five agent oriented software engineering methodologies and discussed their conceptual foundations like interaction, cooperation, collaboration, organizational design etc wherever applicable. A comparison of the methodologies can be made, which was the intent of the paper, to come up with a better understanding of the methodologies. Section 1 was the introduction to this paper, section 2 explained briefly the conceptual framework on which the methodologies were discussed in the paper, section 3 described the Gaia methodology, section 4 and 5 explained the MaSe and AgentUML methodologies respectively, section 6 described SODA methodology and section 7 discussed the MESSAGE methodology. A comparison between methodologies was discussed in Section 8. References: 1.LindJ. “Issues in Agent-Oriented Software Engineering” The First International Workshop on Agent-Oriented Software Engineering (AOSE 2000), 2000. 2.TveitAmud;“A survey of Agent-OrientedSoftwareEngineering” [www.jfipa.org/publications/AgentOrientedSoftwareEngineering 3.Wooldridge M. J., Jennings N. R. and Kinny D; “The Gaia methodology for agent-oriented analysis and design”. Autonomous Agents and Multi-Agent Systems ,3(3):285312, September 2000. 4.Andrea Omicini :”SODA: Societies and Infrastructures in the Analysis and Design of Agent-based Systems)” 5. Dr. Deloach’s 890 lecture notes:”www.cis.ksu.edu/~sdeloach/890” 6. Mark F. Wood Scott A. DeLoach, “An Overview of the Multiagent Systems Engineering Methodology” 7. Bernhard Bauer, Jörg P. Müller, James Odell + Siemens; “Agent UML: Formalism for Specifying Multiagent Interaction” 8. James J. Odell* H. Van Dyke Parunak† Bernhard Bauer‡; “Representing Agent Interaction Protocols in UML” 9. Omicini Andrea; “SODA: Societies and Infrastructures in the Analysis and Design of Agent-based Systems” 10. Giovanni Caire, Francisco Leal, Paulo Chainho, Richard Evans: “Agent Oriented Analysis using MESSAGE/UML”Download 48.12 Kb. Share with your friends:
|