Download Survey and Evaluation of Agent Oriented Software Engineering

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
Others
KADS with
ZEUS
DESIRE
ROADMAP
Aalaadin
Cassiopeia
SODA
MASCommonKADS
CoMoMAS
Publishing
percentage of
each method in
AOM approach
50
40
30
20
10
0
Gaia
Figure 1:
Percentage
Methodology occurency percentage
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
Methodologies
based
on
Object-Oriented
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
Figure 2:
Publishing
percentage for
methods of OOM
approach
Persentage
80
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.
Methods
Criteria
Software
Engineering
evaluation
Software agents
characteristics
evaluation
Preciseness
Accessibility
Expressiveness
Modularity & Objectiveness
Complexity Management
Executability
Refinability
Analysability
Openness & Portability
Formalization
Autonomy
Complexity
Adaptability
Concurrency
Distribution
Communication Richness
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.
AOM
(Gaia)
OOM
(MaSE)
*
+
*
NS
NS
NS
+
*
*
NS
NS
-
*
+
*
+
+
+
*
+
+
*
NS
NS
*
-
Extension of
OOSE
(AUML)
+
+
*
*
+
+
+
+
*
+
*
*
-
Legend:
+ : Good
* : Satisfactory
- : Dissatisfactory
NS: Not Supported
Table 1: Methodologies and modelling techniques evaluation summary
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 158113-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 ECommerce 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