THE MAR&A METHODOLOGY TO DEVELOP AGENT SYSTEMS

Giacomo Cabri, Mariachiara Puviani and Letizia Leonardi

Dipartimento di Ingegneria dell’Informazione, Universit

a di Modena e Reggio Emilia

Via Vignolese 905, 41100 Modena, Italy

Keywords:

Methodology, Infrastructure, SPEM.

Abstract:

In this paper we present a new agent methodology called MAR&A. Its aim is to better connect agent method-

ologies and agent infrastructures, since in the agent development we can ﬁnd a “gap” between them. Our

approach was not to build a new agent methodology from scratch, but to reuse “fragments” of existing method-

ologies. Besides presenting the methodology, we propose its use in a case study, to help readers understand

the exploitation of this methodology and to sketch the connections with agent infrastructures.

1 INTRODUCTION

The agent paradigm has proved to be useful in the

development of today’s systems, in particular those

that exhibit a certain degree of complexity (Jen-

nings, 2001). Nevertheless, the support for developers

shows some lacks and some fragmentations that de-

crease the help that can be concretely provided to de-

velopers. From the one hand, there exist appropriate

methodologies that support in particular the analysis

and the design of agent-based systems; on the other

hand, the agent community has provided agent in-

frastructures to support the implementation of agent-

based systems. The main fragmentation stems from

the fact that these two opposite approaches (one top-

down and the other bottom-up) hardly converge to a

common point: the agent infrastructures often do not

provide abstractions for the outcome of the method-

ologies, while methodologies fail in proposing arti-

facts suitable to be implemented by infrastructures.

This leads to a “gap” between methodologies and

infrastructures. Our aim is to overcome the previ-

ously explained limitations by bridging the gap ex-

isting between agent methodologies and infrastruc-

tures. To this purpose, we have evaluated different

agent methodologies and infrastructures, in particu-

lar considering the connections that exist but are not

so explicit. Exploiting meta-models, we were able to

focus on the entities that are shared between method-

ologies and infrastructures. Of course, some entities

are easy to connect (such as “agent”), while others re-

quire more work. Then, we have evaluated different

possible directions, sketched in this paper, but we felt

that they were not enough.

So, we decided to start building a new agent

methodology, called MAR&A, that focuses on the

main infrastructures’ abstractions. To avoid re-

inventing the wheel, we have not started from scratch,

but we have decided to reuse existing “fragments” of

methodologies; this is possible by means of the SPEM

approach (Object Management Group, 2007), which

decomposes agent methodologies into fragments that

can be composed somehow.

The aim of this paper is to describe the work that

has led to the deﬁnition of MAR&A and to present the

main feature of the methodology, sketching its con-

nections with infrastructures.

2 THE GAP

With regard to methodologies for developing agent

systems, we have evaluated the most spread ones:

ADELFE (Picard and Gleizes, 2004), Gaia (Zam-

bonelli et al., 2003), PASSI (Cossentino et al.,

2004), Prometheus (Winikoff and Padgham, 2004),

SODA (Molesini et al., 2006) and Tropos (Bresciani

et al., 2004).

With regard to the agent infrastructures, the fol-

lowing ones have been considered: CAr tAgO (Com-

mon Artifact for Agent Open environment) (Ricci

et al., 2007), JACK (AOS Autonomous Decition-

Making Software, 2008), JADE (Bellifemine, 1999),

RoleX (Cabri et al., 2003), TOTA (Mamei and Zam-

bonelli, 2005), TuCSoN (Omicini and Zambonelli,

1999).

501

Cabri G., Puviani M. and Leonardi L. (2009).

THE MAR&A METHODOLOGY TO DEVELOP AGENT SYSTEMS .

In Proceedings of the International Conference on Agents and Artiﬁcial Intelligence, pages 501-506

DOI: 10.5220/0001661005010506

 SciTePress

We have considered the chance of integrating

methodologies and infrastructures, evaluating possi-

ble matchings between the concepts described by

their meta-models.

From our study emerges that there is no continu-

ity between the methodologies and the infrastructures,

presenting a gap between analysis and design on the

one hand and implementation on the other hand.

In fact, only few entities can be found in both

methodologies and infrastructures with the same

meaning, while others are present either in method-

ologies or infrastructures. As an example, the goal

entity is signiﬁcantly considered by the methodolo-

gies, but cannot be directly found as an entity in in-

frastructures. Even if this is caused by a “natural” dif-

ference between methodologies and infrastructures,

it could lead to some problems; ﬁrst, resulting in a

fragmented development; but, more important, mak-

ing maintenance very difﬁcult: if a methodology en-

tity has not a corresponding infrastructure entity, its

change requires to ﬁnd out how such an entity was

implemented.

The root of such a gap is likely to derive from

the different origins of methodologies and infrastruc-

tures: from the one hand, the traditional software

engineering approaches follow a top-down direction;

on the other hand, concrete requirements have called

for implementation-oriented solutions providing plat-

forms and frameworks to build agent applications, in

a bottom-up fashion.

3 TOWARD A NEW

METHODOLOGY

To bridge agent methodologies and agent infrastruc-

tures our ﬁrst effort tried to map the existing agent

methodologies’ entities with the existing agent infras-

tructures’ ones. To this purpose, ﬁrst of all we have

evaluated the entities common to the different infras-

tructures. This was useful to extrapolate the “core”

entities, which deserve a support by the methodolo-

gies. We spent an effort to use the meaning of the

entities, in order to map also entities with differ-

ent names but the same meaning. As a concrete

example, we have considered the PASSI methodol-

ogy and the RoleX infrastructure, and we have pro-

duced a mapping based on their meta-models (Cabri

et al., 2008). Molesini et al. have performed a

similar attempt (Molesini et al., 2006), considering

one methodology (SODA) and three infrastructures

(CArtAgO, TuCSoN and TOTA). As another attempt,

we have focused on the role entity, and we have

evaluated how it is dealt with in methodologies and

in infrastructures, in order to map the different ap-

proaches (Puviani et al., 2008b).

The lesson learned from these experiences is that ex-

act mappings (1 to 1) are not enough, and a more

global approach is needed. This is due also to the

fact that a lot of different methodologies and infras-

tructures exist, and point-to-point mappings would be

complex and perhaps not so useful.

So, we decided to propose a new agent method-

ology, which has the infrastructures’ main abstrac-

tions as goal for its outcome. Nevertheless, our aim

was not to deﬁne a completely “new brand method-

ology” because it risks to be “yet another methodol-

ogy”. The trade-off we propose is to create a new

methodology starting from the “fragments” of exist-

ing agent methodologies exploiting SPEM (Software

Process Engineering Metamodel) (Object Manage-

ment Group, 2007), an approach that decomposes the

methodologies in “fragments”, which can be assem-

bled to form new methodologies.

From the evaluation of the infrastructures, we re-

mark that three entities emerge as common: Agent,

Role and Action. Such entities are not only common

to different infrastructures, but also part of their foun-

dation. This makes them the best candidates to be

considered as the outcome of the new methodology;

this also lead the new methodology being developed

using different infrastructures.

4 THE MAR&A METHODOLOGY

In our study about the new methodology, we have fo-

cused on (i) the common processes and entities of

the methodologies and (ii) the entities that enable a

connection with the main entities of the infrastruc-

tures. MAR&A, “Methodology for Agent: Roles and

Actions”, has as main entities the same used in in-

frastructures (as said before), which helps developer

to implement applications developed by this method-

ology. The chosen model is the waterfall one, and

it relies on different important fragments of PASSI,

Gaia and Tropos. We have deﬁned three main phases

of MAR&A: Requirement (Subsection 4.1), Analysis

(Subsection 4.2) and Design (Subsection 4.3), while

the Implementation phase is under deﬁnition. In the

following we brieﬂy explain the exploited fragments.

Note that not all mentioned entities have a corre-

sponding fragment in the ﬁgures.

4.1 Requirement Phase

In the Domain Description Fragment, taken from

Passi, the concepts of goal and actor have been in-

ICAART 2009 - International Conference on Agents and Artificial Intelligence

502

tegrated, to create the Actor Diagram, that it is very

useful in the Analysis Fragment taken from Tropos

(Figure 1). Here some further work has to be done

to convert Tropos Goal Diagram (output of Analysis

Fragment)in a UML one.

Figure 1: Requirement phase.

Very important in this phase is the creation of a glos-

sary that will report all the created entities, and that

has to be updated during all the other phases (and

fragments). Here some important concepts are de-

ﬁned: Requirement - A feature that the System-

to-Be (representing the general environment where

other actors live) must exhibit, it can be functional

or non-functional. Scenario - Represents a concrete

sequence of interactions between the system and the

actors. Actors - Entities that have strategic objectives

(goals) and wishes, in the system. Goals - Actors’

strategic interests. They can be divided in hard or soft

goals, based on their fulﬁlment. Plan - Procedures

that have to be executed to reach goals.

4.2 Analysis Phase

In the Agent Identiﬁcation Fragment, taken from

Passi, the Actor Diagram has been introduced, to help

specifying Agent (Figure 2).Here we have to notice

that the Requirement Doc, is the same as the Require-

ment Statement used in Gaia, so it can be integrated

in a Gaia Fragment without modiﬁcation.

In this phase, we have seen that the way of exploit-

ingIdentify the Role in the System Fragment from

Passi and of Roles Identiﬁcation Fragment from Gaia,

is very similar, so we have mixed together these two

fragments. The only thing that is still missing is a

stronger connection between the Prototypical Role

Model and the Role Identiﬁcation Diagram, that now

remain separated.

Figure 2: Analysis phase.

In this phase the following concepts are identiﬁed:

Agent - An autonomous entity that is composed of

roles and has a knowledge. An agent can be seen

from different levels of abstraction: it is a signiﬁcant

software unit at both the abstract and concrete levels

of design. In this phase, an agent is speciﬁed as an

instance of an agent class. An agent may undertake

several functional roles during interactions with other

agents to achieve its goals. Here we tried to model an

agent that is independent of a speciﬁc platform, and

that can be used in different infrastructures without a

lot of changes. Role - A collection of tasks performed

by agent in pursuing a sub-goal; an agent could play

one or more roles in the system. Each role describes

an aspect of agent life cycle and it is often related to

a service offered by the agent to the society or to the

achievement of one of its goals (Social Role). Action

- The identiﬁcation of activities that an agent may per-

form. Each action is composed of one or more tasks.

Task - A logical unit of individual or interactive

behavior. An agent uses tasks to execute its plan(s).

Each task is an entity that aims to reach a sub-goal.

The term “task” can be used as synonymous of Behav-

ior but with the meaning of atomic part of the overall

agent behavior.

4.3 Design Phase

Here the Create an Agent Model Fragment (from

Gaia) has been changed because it has to consider

Passi-like agents (and not Gaia-like ones), and to be

based on Single Agent Structure Diagram Figure 3).

The deﬁned concepts are: Ontology - An ontology is

composed of concepts, actions and predicates. Com-

munication - An interaction between two agents, de-

scribed in terms of: ontology (related to the part of

knowledge exchanged by the agents), content lan-

THE MAR&A METHODOLOGY TO DEVELOP AGENT SYSTEMS

503

Figure 3: Design phase.

guage and interaction protocol. Message - An indi-

vidual unit of communication between two or more

agents. Messages are based on the standard FIPA

message format.

Some of these different fragments are well inte-

grated, even if they come from different methodolo-

gies, while other fragments have been changed in-

side to match input and output of the different phases.

This work presents some difﬁculties because, as said,

entities with the same name but coming from differ-

ent methodologies cannot be used in the same way

(e.g. the concept of “agent” in ADELFE is adaptive,

in PASSI is FIPA-like and in Prometheus is a BDI

one). In other cases, we have chosen the most suitable

concepts for our scope (e.g., we do not have chosen

ADELFE agent because it needs some concepts, like

skill, aptitude, NCS, etc., which need an ad hoc plat-

form to be implemented, and it is out of our scope).

The implementation and validation of this composed

methodology is still in progress, trying to adjust the

different fragments, in particular in the Design phase.

4.4 Case Study

As case study we exploit a conference organization,

which is a multiphase process that involves different

kinds of people and groups, and can be easily imple-

mented (and used) via Web. For length reasons, in

this paper we report a summary of the application of

MAR&A to the case study; interested readers can ﬁnd

a more complete description in (Puviani et al., 2008a).

Here, the Conference Organization System is

brieﬂy described: during the submission phase, au-

thors send papers, and a submission number is given

back to them when the paper is received. During

the review phase, the Program Committee (PC), com-

posed of a PC Chair and some PC Members, regis-

ters papers reviews: they will contact some reviewer,

asking them to do the review for some papers. With

the compiled review forms, the PC decides if the pa-

per has to be accepted or rejected. During the editing

phase, authors whose paper has been accepted, have

to write a new version of their paper according to the

suggestions of the reviewer. At the end, editors have

to collect the reviewed paper and to print the confer-

ence proceedings. In the following the case study de-

veloped by MAR&A is presented.

Figure 4: Domain Description Diagram.

In the Requirement Phase, system requirements are

described in term of objectives (goals) and actors;

the problem to solve is presented, along with its con-

strains and limits. Here we can see that the concept

of Agent (as used in infrastructures) is introduced us-

ing the concept of Actor. In the Domain Description

Fragment, the system’s requirements are described

using Use Case Diagrams: system goals and actors

are speciﬁed along with their relations. Figure 4 re-

ports an example of Review Phase Domain Descrip-

tion Diagram.

The following step identiﬁes and models Actors

as social actors that depend one to each other con-

sidering goals to reach, tasks to obtain, and resources

to use. The Actor Diagram (Figure 5) underlines ac-

tors and the dependences between them. This phase

is very relevant because it begins to create an interac-

tion map, useful when we need to build this applica-

tion using infrastructures, where usually interactions

are very important and well deﬁned. Another actor

that has to be considered is the System-to-Be, and the

Actor Diagram can be redeﬁned with this actor in an

easy way thanks to the adaptability of the methodol-

ogy. Deﬁning actors is very useful because, unlike

agents, they are always platform independent, and so

they can help developer to build agents in different

infrastructures. Then Actor Diagram is extended with

the relationship taken from systems goals.

ICAART 2009 - International Conference on Agents and Artificial Intelligence

504

Figure 5: Actor Diagram.

Figure 6: Agent Class.

In the Analysis Phase agents are deﬁned as well as

tasks and roles they play, and actions are introduced.

In the Agent Identiﬁcation Fragment, diagrams of the

Requirement Phase are used to analyze actors: agents

can be seen as single Use-Case or as a Use-Case pack-

age: every package deﬁnes agents’ functionalities. In

Figure 6 we can see an example of Agent Classes that

are very useful to be used during agents implementa-

tion in infrastructures.

During the Identify Roles Fragment, a Prototyp-

ical Roles Model is deﬁned: it presents roles along

with their responsibilities (liveness and safety) and

permissions, using Gaia notation. Then, using the

Roles Identiﬁcation Diagram (e.g. Figure 7), inter-

agent communications are well described, deﬁning

every path of the Agent Identiﬁcation Diagram. In the

Task Speciﬁcation Fragment, for each Agent, a Task

Speciﬁcation Diagram is deﬁned: it contains agent’s

tasks on the right and interacting agents on the left. At

the end of this phase, starting from Roles and Tasks,

a preliminary list of Actions is created, to help devel-

opers deal with infrastructures.

During the Design Phase, in the Domain Ontology

Description Fragment, some Domain Ontology Dia-

grams (Class Diagrams) that describe the used on-

tology in terms of concepts, predicate and actions

are built. The Communication Ontology Diagrams

Fragment presents agent interaction along with do-

Figure 7: Role Identiﬁcation Diagram.

main ontology. They are very important because can

help developer map entities between the methodology

and the chosen infrastructure. These diagrams fur-

ther develop actions played by agents. Then, during

the Roles Description Fragment, agents’ life cycle is

modeled, considering roles, collaborations, and con-

versations; the result is a Role Description Diagram,

where each agent is identiﬁed by a package contain-

ing its roles’ classes, and each role is obtained com-

posing different tasks. In this latter diagram, connec-

tions between roles played by the same agent are re-

ported and they can represent role changes.

During the Agent Structure Deﬁnition Frag-

ment, which uses Agent Identiﬁcation Diagram and

the Communication Ontology Diagram as input, a

Single-Agent Class Diagram is built (e.g. Figure 8),

focused on the internal structure of each agent. At the

end, during the Create an Agent Model Fragment, an

Agent Model is deﬁned with a set of roles that can be

mapped by each agent class.

Figure 8: Single-Agent Structure Deﬁnition.

With the help of this case study, we can see that the

composed methodology stressed out the entities rel-

evant for infrastructure, that will help developers in

system implementation using not an a-priori decided

infrastructure. For instance, the implementers can

chose the Jade and the RoleX platforms, and map

the agent artifacts produced by MAR&A onto the

THE MAR&A METHODOLOGY TO DEVELOP AGENT SYSTEMS

505

agent abstraction of Jade; the MAR&A roles onto the

RoleX role descriptors; and the MAR&A actions on

the AgentAction Jade class or to the Action class of

RoleX.

5 CONCLUSIONS

In this paper we have presented MAR&A, a method-

ology that aims at being infrastructure-oriented, in the

sense that it is oriented to the main abstractions of the

existing agent infrastructures, in order to propose a

step toward bridging the gap between agent method-

ologies and agent infrastructures.

The two peculiar aspects of MAR&A are: (i) it

has been built starting from the infrastructures’ ab-

stractions, so to make the passage from the method-

ology design phase to the infrastructure implementa-

tion phase easier; and (ii) it is not a completely new

methodology, but it is “composed” from fragments of

existing agent methodologies.

There are some advantages in exploiting frag-

ments of existing methodologies. First, it is not “yet

another methodology”, because it takes concrete parts

of the other methodologies, not only ideas and con-

cepts; then, the exploited fragments have been tested

by developer for different years and in different sce-

narios; further, there are already related documenta-

tion, case studies, tools and practice; moreover, frag-

ments can be exchanged on the base of the application

needs; ﬁnally, some developers can ﬁnd some parts of

the methodology they are used to.

With regard to future work, we are deﬁning the Imple-

mentation Phase in details, to make it possible to pro-

duce code that can be used by an agent infrastructure.

Of course the methodology must be tested also with

other case studies, to better validate its usability. An-

other important thing that is still missing, but which

we are working on, is the introduction of AMAS Ad-

equacy from Adelfe, and a better speciﬁcation of a

Communication Protocol in the Design Phase.

ACKNOWLEDGEMENTS

Work supported by the Italian MiUR in the frame of

the PRIN project MeNSA. The author thank Cate-

rina Barbieri for her work in the development of the

MAR&A methodology.

REFERENCES

AOS Autonomous Decition-Making Software (2008).

Agent oriented software, jack agent platform.

http://www.agent-software.com/.

Bellifemine, F. (1999). Developing multi-agent systems

with jade. In Proceedings of PAAM 99, London (UK),

pages 97–108.

Bresciani, P., Perini, A., Giorgini, P., Giunchiglia, F., and

Mylopoulos, J. (2004). Tropos: An Agent-Oriented

Software Development Methodology. Autonomous

Agents and Multi-Agent Systems, 8(3):203–236.

Cabri, G., Ferrari, L., and Leonardi, L. (2003). Enabling

mobile agents to dynamically assume roles. In Pro-

ceedings of the ACM Symposium on Applied Comput-

ing, Melbourne (USA), March, pages 56–60.

Cabri, G., Leonardi, L., and Puviani, M. (2008). Method-

ologies and Infrastructures for Agent Society Simula-

tion: Mapping PASSI and RoleX. In Proceedings of

the 19

EMCSR, Wien, March 2008.

Cossentino, M., Sabatucci, L., and Chella, A. (2004). Pat-

terns Reuse in the PASSI Methodology. LNCS, pages

294–310.

Jennings, N. (2001). An agent-based approach for building

complex software systems. Communications of the

ACM, 44(4):35–41.

Mamei, F. and Zambonelli, F. (2005). Programming stig-

mergic coordination with the TOTA middleware. In

Proceedings of the 4

International Conference on

Autonomous Agents and Multi-Agent Systems, New

York, USA, pages 415–422.

Molesini, A., Omicini, A., Denti, E., and Ricci, A. (2006).

SODA: A roadmap to artefacts. Engineering Societies

in the Agents World VI, 3963:49–62.

Object Management Group (2007). SPEM.http://www.omg

.org/technology/documents/formal/spem.htm.

Omicini, A. and Zambonelli, F. (1999). Coordination for

internet application development. Autonomous Agents

and Multi-Agent Systems, 2(3):251–269.

Picard, G. and Gleizes, M. (2004). The ADELFE

Methodology–Designing Adaptive Cooperative

Multi-Agent Systems. Methodologies and Software

Engineering for Agent Systems. Kluwer Publishing.

Puviani, M., Barbieri, C., Cabri, G., and Leonardi, L.

(2008a). A Case Study for MAR&A. Technical Re-

port DII-AG-2008-1, DII, University of Modena and

Reggio Emilia.

Puviani, M., Cabri, G., and Leonardi, L. (2008b). Agent

Roles: from Methodologies to Infrastructures. In Pro-

ceedings of CTS 2008, Irvine, USA, May 2008.

Ricci, A., Viroli, M., and Omicini, A. (2007). CArtAgO:

A framework for prototyping artifact-based environ-

ments in MAS. In Weyns, D., Parunak, H. V. D., and

Michel, F., editors, Environments for MultiAgent Sys-

tems, volume 4389 of LNAI, pages 67–86. Springer.

Winikoff, M. and Padgham, L. (2004). Developing Intelli-

gent Agent Systems: A Practical Guide.

Zambonelli, F., Jennings, N., and Wooldridge, M. (2003).

Developing multiagent systems: The Gaia methodol-

ogy. ACM TOSEM, 12(3):317–370.

ICAART 2009 - International Conference on Agents and Artificial Intelligence

506