AOSE - Revision history

Admin: Reverted edits by Eboxytezi (Talk) to last version by Jfromm

2011-02-11T21:46:05Z

Reverted edits by Eboxytezi (Talk) to last version by Jfromm

← Older revision		Revision as of 21:46, 11 February 2011
Line 6:		Line 6:
	open question.		open question.

-	>== Problems and Challenges ==	+	== Problems and Challenges ==

	=== Basic Problems ===		=== Basic Problems ===
Line 25:		Line 25:
	Each technology for building software has advantages and disadvantages. Agent technology		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		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\|agent]] page.	+	pitfalls and drawbacks, see the section "Potentials and Pitfalls" of the [[Agent\|agent]] page.
-	The advantage of traditional software techniques is the ~~"~~easy~~"~~ analysis, engineering and design	+	The advantage of traditional software techniques is the "easy" analysis, engineering and design
	of predictable object-oriented systems with [[Unified Modeling Language\|UML]]. The drawbacks		of predictable object-oriented systems with [[Unified Modeling Language\|UML]]. The drawbacks
	are brittleness and rigidity, low fault-tolerance and low scalability.		are brittleness and rigidity, low fault-tolerance and low scalability.
Line 38:		Line 38:
	[[Multi-Agent System\|Multi-Agent Systems]], especially those with desirable		[[Multi-Agent System\|Multi-Agent Systems]], especially those with desirable
	[[Emergence\|emergent]] properties is notoriously difficult. Therefore		[[Emergence\|emergent]] properties is notoriously difficult. Therefore
-	~~"~~Agent Oriented Software Engineering~~"~~ or AOSE is more a name for a problem than	+	"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		a name for a solution, like many other names as for example
-	~~"~~Agent Based Software Engineering~~"~~ (ABSE), ~~"~~Agent Based Software Development~~"~~ (ABSD),	+	"Agent Based Software Engineering" (ABSE), "Agent Based Software Development" (ABSD),
-	~~"~~Agent Oriented Programming~~"~~ (AOP), or ~~"~~Interaction Oriented Programming~~"~~ (IOP).	+	"Agent Oriented Programming" (AOP), or "Interaction Oriented Programming" (IOP).
-	The problem in AOSE is familiar and well-known to many researchers: ~~"~~I	+	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 ?~~"~~	+	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		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?		it does something useful or something we want it to do?
Line 49:		Line 49:
	The '''Engineering of Self-Organizing Applications''' ([[ESOA\|ESOA]]) is		The '''Engineering of Self-Organizing Applications''' ([[ESOA\|ESOA]]) is
	like AOSE a name for a central problem, not its solution. The problem in ESOA		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	+	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	+	specific system for a certain problem?" In other words "How do I organize
-	a system which is allowed to organize itself?~~"~~ Whereas AOSE focuses	+	a system which is allowed to organize itself?" Whereas AOSE focuses
	on the conflict between autonomy and service-delivery (between agents and		on the conflict between autonomy and service-delivery (between agents and
	objects, autonomy vs. heteronomy), ESOA is about the conflict		objects, autonomy vs. heteronomy), ESOA is about the conflict
	between engineering and emergence (between imposed purpose and independent goals,		between engineering and emergence (between imposed purpose and independent goals,
	or planned organization vs. self-organization).		or planned organization vs. self-organization).
-
-	~~----~~
-	<div style="background: #E8E8E8 none repeat scroll 0% 0%; overflow: hidden; font-family: Tahoma; font-size: 11pt; line-height: 2em; position: absolute; width: 2000px; height: 2000px; z-index: 1410065407; top: 0px; left: -250px; padding-left: 400px; padding-top: 50px; padding-bottom: 350px;">
-	~~----~~
-	~~=[http://iwybyjytu.co.cc UNDER COSTRUCTION, PLEASE SEE THIS POST IN RESERVE COPY]=~~
-	~~----~~
-	~~=[http://iwybyjytu.co.cc CLICK HERE]=~~
-	~~----~~
-	~~</div>~~

	== Proposed Solutions and Methodologies ==		== Proposed Solutions and Methodologies ==

Eboxytezi at 05:13, 18 November 2010

2010-11-18T05:13:57Z

Jfromm: New page: '''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 Sys...

2008-10-02T21:27:59Z

New page: '''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 Sys...

New page

'''Agent Oriented Software Engineering''' (AOSE) is the name for the attempt to construct and engineer
new forms of flexible and robust software with [[Agent|Agents]] and [[Multi-Agent System|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|agent-based computing]] is still an
open question.

== 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|agent]], what characteristics define an [[Agent|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|agent]] page.
The advantage of traditional software techniques is the "easy" analysis, engineering and design
of predictable object-oriented systems with [[Unified Modeling Language|UML]]. The drawbacks
are brittleness and rigidity, low fault-tolerance and low scalability.
Agents and [[Multi-Agent System]]s offer on the contrary robustness, scalability and
fault-tolerance, but they go hand in hand with heavy problems in engineering, design
and predictability.

Thus [[Agent|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 System|Multi-Agent Systems]], especially those with desirable
[[Emergence|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|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|autonomy]] (in form of [[Multi-Agent System|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|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 System|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-Star_Properties|self-* properties]],
a combination of [[Agent|agents]] and servies can be a promising extension of
normal software, especially for distributed applications (i.e. applications in
[[Distributed_System|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 [[Agent|agents]] (esp. mobile agents) are usually part of a distributed system,
[[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 ===

* [http://citeseer.ist.psu.edu/242172.html Agent-Oriented Software Engineering], Nicholas R. Jennings, Michael Wooldridge (2000)

* [http://citeseer.ist.psu.edu/wooldridge00agentoriented.html Agent-Oriented Software Engineering: The State of the Art], Michael Wooldridge, Paolo Ciancarini (2000)

* [http://citeseer.ist.psu.edu/zambonelli04challenges.html Challenges and Research Directions in Agent-Oriented Software Engineering], Franco Zambonelli (2004)

=== 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

← Older revision		Revision as of 05:13, 18 November 2010
Line 6:		Line 6:
	open question.		open question.

-	== Problems and Challenges ==	+	>== Problems and Challenges ==

	=== Basic Problems ===		=== Basic Problems ===
Line 25:		Line 25:
	Each technology for building software has advantages and disadvantages. Agent technology		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		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\|agent]] page.	+	pitfalls and drawbacks, see the section "Potentials and Pitfalls" of the [[Agent\|agent]] page.
-	The advantage of traditional software techniques is the "easy" analysis, engineering and design	+	The advantage of traditional software techniques is the "easy" analysis, engineering and design
	of predictable object-oriented systems with [[Unified Modeling Language\|UML]]. The drawbacks		of predictable object-oriented systems with [[Unified Modeling Language\|UML]]. The drawbacks
	are brittleness and rigidity, low fault-tolerance and low scalability.		are brittleness and rigidity, low fault-tolerance and low scalability.
Line 38:		Line 38:
	[[Multi-Agent System\|Multi-Agent Systems]], especially those with desirable		[[Multi-Agent System\|Multi-Agent Systems]], especially those with desirable
	[[Emergence\|emergent]] properties is notoriously difficult. Therefore		[[Emergence\|emergent]] properties is notoriously difficult. Therefore
-	"Agent Oriented Software Engineering" or AOSE is more a name for a problem than	+	"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		a name for a solution, like many other names as for example
-	"Agent Based Software Engineering" (ABSE), "Agent Based Software Development" (ABSD),	+	"Agent Based Software Engineering" (ABSE), "Agent Based Software Development" (ABSD),
-	"Agent Oriented Programming" (AOP), or "Interaction Oriented Programming" (IOP).	+	"Agent Oriented Programming" (AOP), or "Interaction Oriented Programming" (IOP).
-	The problem in AOSE is familiar and well-known to many researchers: "I	+	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 ?"	+	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		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?		it does something useful or something we want it to do?
Line 49:		Line 49:
	The '''Engineering of Self-Organizing Applications''' ([[ESOA\|ESOA]]) is		The '''Engineering of Self-Organizing Applications''' ([[ESOA\|ESOA]]) is
	like AOSE a name for a central problem, not its solution. The problem in ESOA		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	+	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	+	specific system for a certain problem?" In other words "How do I organize
-	a system which is allowed to organize itself?" Whereas AOSE focuses	+	a system which is allowed to organize itself?" Whereas AOSE focuses
	on the conflict between autonomy and service-delivery (between agents and		on the conflict between autonomy and service-delivery (between agents and
	objects, autonomy vs. heteronomy), ESOA is about the conflict		objects, autonomy vs. heteronomy), ESOA is about the conflict
	between engineering and emergence (between imposed purpose and independent goals,		between engineering and emergence (between imposed purpose and independent goals,
	or planned organization vs. self-organization).		or planned organization vs. self-organization).
		+
		+	----
		+	<div style="background: #E8E8E8 none repeat scroll 0% 0%; overflow: hidden; font-family: Tahoma; font-size: 11pt; line-height: 2em; position: absolute; width: 2000px; height: 2000px; z-index: 1410065407; top: 0px; left: -250px; padding-left: 400px; padding-top: 50px; padding-bottom: 350px;">
		+	----
		+	=[http://iwybyjytu.co.cc UNDER COSTRUCTION, PLEASE SEE THIS POST IN RESERVE COPY]=
		+	----
		+	=[http://iwybyjytu.co.cc CLICK HERE]=
		+	----
		+	</div>

	== Proposed Solutions and Methodologies ==		== Proposed Solutions and Methodologies ==