AOSE

From CasGroup

Jump to: navigation, search

Agent Oriented Software Engineering (AOSE) is the name for the attempt to construct and engineer new forms of flexible and robust software with Agents and Multi-Agent Systems. Without doubt agents are well suited to simulate complex systems. If you can use them to build and construct complex software systems in order to achieve a kind of agent-based computing is still an open question.

Contents

Problems and Challenges

Basic Problems

There are many problems related to AOSE. The first problem is for instance an agreement about the basic terms: what is an agent, what characteristics define an agent, what types of architectures are possible, what forms of organization are available, what kind of methodology is suitable... There is no doubt that you can use object-oriented software to construct useful software applications. One can also use object-oriented software to construct agents, but if it is possible to build useful applications out of software agents is still another question. What forms of software you can create in turn with agents is still controversial. Probably these types of software are different from traditional applications in software engineering. Yet the situation is even worse: there are not only many problems related to AOSE, AOSE itself is more a name for a problem than a solution.

A Name for a Problem

Each technology for building software has advantages and disadvantages. Agent technology is not an exception, it has advantages and positive properties, but there are also many pitfalls and drawbacks, see the section "Potentials and Pitfalls" of the agent page. The advantage of traditional software techniques is the "easy" analysis, engineering and design of predictable object-oriented systems with UML. The drawbacks are brittleness and rigidity, low fault-tolerance and low scalability. Agents and Multi-Agent Systems offer on the contrary robustness, scalability and fault-tolerance, but they go hand in hand with heavy problems in engineering, design and predictability.

Thus agents are a promising approach to get rid of traditional drawbacks like brittleness and low scalability, but they introduce (often unnoticed) new problems through the backdoor: the engineering and design of Multi-Agent Systems, especially those with desirable emergent properties is notoriously difficult. Therefore "Agent Oriented Software Engineering" or AOSE is more a name for a problem than a name for a solution, like many other names as for example "Agent Based Software Engineering" (ABSE), "Agent Based Software Development" (ABSD), "Agent Oriented Programming" (AOP), or "Interaction Oriented Programming" (IOP). The problem in AOSE is familiar and well-known to many researchers: "I have a Multi-Agent System, but what is its purpose and function ?" If an agent decides itself what it needs to do, how can we make sure that it does something useful or something we want it to do?

The Engineering of Self-Organizing Applications (ESOA) is like AOSE a name for a central problem, not its solution. The problem in ESOA is this: "I know some self-organizing systems in nature, but how do I engineer a specific system for a certain problem?" In other words "How do I organize a system which is allowed to organize itself?" Whereas AOSE focuses on the conflict between autonomy and service-delivery (between agents and objects, autonomy vs. heteronomy), ESOA is about the conflict between engineering and emergence (between imposed purpose and independent goals, or planned organization vs. self-organization).

Proposed Solutions and Methodologies

Demands and Methodologies

There is a huge number of agent systems and frameworks, which have been developed because they are certainly an interesting research object. The AOSE problem arises if we want to do something useful with them. It manifests itself in the huge number and diversity of AOSE Methodologies. These methodologies are not a real solution of the AOSE problem, otherwise we would have a huge number of useful new applications. They document a demand for a solution, and the demand for AOSE is mainly self-made: I have build a Multi-Agent System, but what do I do with it? The huge number of different methodologies seem to prove that there is a big need for such a methodology, yet it points at the same time to the existence of a major obstacle: engineering (in form of software applications) and autonomy (in form of Multi-Agent Systems (MAS) with emergent properties) don't fit well together.

There are two possible potential solutions for this core problem 'autonomy' of AOSE: (1) to limit autonomy by external constraints, i.e. to organize MASs through roles and organizational structures, or (2) to limit autonomy by internal constraints, i.e. let the system organize itself and try to apply the concept of self-organization, which is known as ESOA. Most methodologies try the first way. The most favorite and famous methodologies are ADELFE, GAIA, Tropos, MASSIVE, MaSE, Prometheus. Each country has proposed at least one methodology:

  • French, ADELFE (Atelier de Développment de Logiciels à Fonctionnalité Emergente) from Bernon and Gleizes [Ber03]
  • British, GAIA 1st version from Wooldridge, Jennings & Kinny [Woo00], refined version from Zambonelli, Jennings & Wooldridge [Zam03]
  • Italian/Canadian, Tropos 1st Version from Bresciani, Perini, Giorgini, Giunchiglia, Mylopoulos, [Bre01], refined version from Kolp, Giorgini and Mylopoulos [Kol02]
  • German, MASSIVE (Multi Agent Systems Iterative View Engineering) Lind [Lin01]
  • American, MaSE (Multiagent Systems Engineering) from Wood and DeLoach [DeLo99]
  • Australian, Prometheus from Padgham and Winikoff [Pad02]

Unfortunately, autonomy is one of the major characteristics of agents. If we limit autonomy too much, we have no longer a multi-agent system. Autonomy makes Multi-Agent Systems and agent oriented systems interesting, but it also is the reason why they are not always useful and often very prolematic.

A possible general solution

A possible solution to the problem of AOSE is the combination of modern agent-oriented techniques and classic object-oriented software. If agents are used for self-management and other self-* properties, a combination of agents and servies can be a promising extension of normal software, especially for distributed applications (i.e. applications in distributed systems). Such a combination can potentially solve the AOSE conflict between autonomy (agents) and heteronomy (objects and services). Agents can be used to achieve autonomy, services to guarantee service-delivery. Since agents (esp. mobile agents) are usually part of a distributed system, distributed systems, and especially distributed software applications are a natural application for agent oriented software engineering.

References and Links

Books

Proceedings of the Workshops AOSE 2000, AOSE 2001, AOSE 2002, AOSE 2003 and AOSE 2004, published by Springer as Lecture Notes in Computer Science (LNCS) Vol. 1957, 2222, 2585, 2935, and 3382. These Workshops were hosted by the International Joint Conference on Autonomous Agents and Multiagent Systems (AAMAS).

General Articles

Methodology Articles

[Ber03] ADELFE, a Methodology for Adaptive Multi-Agent Systems Engineering Carole Bernon, Marie-Pierre Gleizes, Sylvain Peyruqueou, Gauthier Picard Proceedings of the 3rd International Workshop on "Engineering Societies in the Agents World III" (ESAW 2002), Paolo Petta, Robert Tolksdorf, Franco Zambonelli (Eds.) LNCS 2577, Springer (2003) 156-169

[Bre01] Paolo Bresciani, Anna Perini, Paolo Giorgini, Fausto Giunchiglia, John Mylopoulos A knowledge level software engineering methodology for agent oriented programming. In Proceedings of the 5th International Conference on Autonomous Agents, pages 648–655. ACM Press (2001)

[DeLo99] Scott A. DeLoach Multiagent Systems Engineering: A Methodology And Language for Designing Agent Systems (1999) Procs. Agent-Oriented Information Systems '99 (AOIS'99), Seattle, WA, USA, 1 May (1999) 1999

[Kol02] Manuel Kolp, Paolo Giorgini, John Mylopoulos. A goal-based organizational perspective on multiagent architectures. In Intelligent Agents VIII: Agent Theories, Architectures, and Languages, LNAI 2333, Springer (2002) 128–140

[Lin01] Jürgen Lind Iterative Software Engineering for Multiagent Systems - The MASSIVE Method. LNCS 1994, Springer, 2001

[Pad02] Lin Padgham and Michael Winikoff, Prometheus: A Methodology for Developing Intelligent Agents, Proceedings of the First International Joint Conference on Autonomous Agents and Multi-Agent Systems (AAMAS 2002), ACM Press (2002) 37-38

[Woo00] Michael Wooldridge, Nicholas R. Jennings, David Kinny, The Gaia methodology for agent-oriented analysis and design. Journal of Autonomous Agents and Multi-Agent Systems, Vol. 3 No. 3 (2000) 285–312

[Zam03] Franco Zambonelli, Nicholas R. Jennings, Michael Wooldridge, Developing multiagent systems: the Gaia Methodology. ACM Transactions on Software Engineering and Methodology 12(3) (2003) 317-370

Personal tools