Towards a Model Driven Process forMulti-Agent System

Tarek Jarraya1 and Zahia Guessoum2

1 I3S RAINBOW Team, University of NicePoly’tech Nice, 930 route des Colles BP145 06903 Sophia Antipolis, France

jarraya@i3s.unice.fr2 LIP6 OASIS Team, Univ. of Pierre and Marie Curie104 avenue du Prsident Kennedy 75016 Paris, France

zahia.guessoum@lip6.fr

Abstract. We propose a new multi-agent development method, namedMDAD (Model Driven Agent Development). It is based on the MDA(Model Driven Architecture) paradigm. The aim of MDAD method is toreduce the cost of building MAS applications by starting from abstractspecification of system thanks to MAS meta-models, and producing thefinal system by means of transformations of this specification into com-putational entities. We present in this paper the application of MDAD tothe INAF framework. First we give an overview of MDA approach andits application to MAS. Thus, several abstraction levels are determinedand a set of meta-models is introduced. Then, we give the transforma-tion rules used to produce INAF compliant models. MDAD method isillustrated with the timetable management benchmark.

1 Introduction

In the present state of research and development in the multi-agent area, we findcontributions on development tools for multi-agent implementation [10] [1], onorganizational models [8], and on methodologies for agent-oriented analysis anddesign [4]. However, most existing methodologies do not provide a complete de-velopment process (analysis, design, implementation, deployment...). Moreover,they do not rely on existing agent architectures and existing agent-based de-velopment tools. Recent research introduces meta-models to represent the mainconcepts and relationships of the proposed MAS methodologies. Moreover, anunification of these meta-models has been proposed by the AgentLink TFGAOSE [2].

This paper aims to bridge the gap between existing agent architectures anddevelopment tools. Our idea is to start from existing architectures and tools andto elaborate meta-models in order to formulate the necessary knowledge aboutthe development process. Thus, unlike most existing methodologies which arebased on a top-down approach, our design is bottom up. This new approach isinspired by the Model-Driven Architecture (MDA), proposed by OMG, whichaims at separating application logic from the underlying technologies to improve

H.-D. Burkhard et al. (Eds.): CEEMAS 2007, LNAI 4696, pp. 256–265, 2007.c© Springer-Verlag Berlin Heidelberg 2007

Towards a Model Driven Process for Multi-Agent System 257

reusability and development process [7]. The idea is that business knowledgeshould be permanent, whereas technical concerns are generally short-lived andlimited to a given technology.

This paper shows the use of MDA to define a new MAS development processnamed MDAD which is based on a library of agent and organization meta-models. These meta-models may be used by the designer to easily describe themulti-agent models which are automatically transformed to generate an oper-ational MAS. To illustrate our approach we present in this paper the differentsteps and models needed to develop the timetable management benchmark [3].This application corresponds to a distributed MAS that helps at defining thetimetable of professors and student groups. Each user has a personal assistantagent which manages his timetable. This agent interact with other agents toreserve a time slots for needed sessions. We present thus models introduced bydeveloper and the ones generated by MDAD process.

This paper is organized as follow: The section 2 presents MDAD method.The section 3 presents the different meta-models used to represent the MASindependently from the platform level. The section 4 describes the meta-modelof the INAF framework. The section 5 gives the required transformation rulesbetween the two previous levels. The section 6 gives the generation code rulesapplied to PSM to obtain the MAS code.

2 MDAD: Model Driven Agent Development

The main idea of our approach is to reduce the cost of building a MAS ap-plication by starting from abstract specification of the MAS resulting from themethodology designing level, and generating the final system by means of trans-formations of this specification into computational entities.

MDAD aims to provide a set of meta-models and a set of knowledge-basedsystems that represent the transformation rules. These meta-models are used todescribe models which can be considered as an operational specification of thesystem and as such they constitute the useful basic stones for the building of anoperational MAS. The latter may be obtained by a succession of transformationswhich can be done automatically or semi-automatically. Some transformationsrequire therefore some preliminary inputs from the designer. For instance, theagent meta-models are often sufficient to generate operational agents. However,the MAS deployment is seldom automatic.

2.1 Meta-models

Four abstract levels have thus been identified, from the most platform-specificto the most abstract:

– Infrastructure level: represents the components of the MAS at the implemen-tation level (code); it includes the domain implementation, the generatedagent implementation and the MAS deployment,

258 T. Jarraya and Z. Guessoum

– PSM (platform-specific model) level: represents the components of the MASfrom the platform point of view. This representation makes abstraction ofsome implementation details (language, middleware...). It includes the de-scription of agent classes, meta behaviors building, MAS initialization classesand domain classes diagram,

– PIM (platform-independent model) level: represents the requirements of theMAS at design time, independently of the underlying platforms; MAS orga-nization and meta-behaviors descriptions belong to this level,

– CIM (computation-independent model) level: represents the statements of aproblem in a given domain;

In MDAD, we use UML diagrams to describe PIM and PSM. To represent ourmeta-models, we have defined MAS profiles. We thus have defined two profilesto represent PIM and PSM meta-models.

2.2 MDAD Development Process

The PIM is an abstract representation of the MAS application including mainlythe specification of the MAS organization and agents behavior. The PSMdescribes the components of the MAS from the platform point of view. Thisrepresentation makes abstraction of some implementation details (language, mid-dleware...).

We have defined a set of transformation rules ensuring the crossing from PIMto PSM. These rules express the know-how of a developer knowing the structureof the MAS obtained starting from methodology, as well as, the structure andthe services offered by the implementation platform. These rules are writtenin the QVT language [9]. The obtained PSM by application of transformationrules will be used to generate MAS code. This code contains agent classes, MASinitialization classes, and domain classes.

Thus, the developer needs the following steps to implement its MAS:

1. Defining the PIM by using MAS Profile,2. Applying transformation rules to the PIM to produce the PSM,3. Applying generation code rules to the PSM to obtain the application code.

Our approach is enough generic, it can be applied to different MAS method-ologies and platforms. We present in this paper the application of our approachto a MAS abstract level defined by a set of meta-models and its implementa-tion with INAF framework [11]. The paper gives some meta-models for PIMand PSM, and analyzes their transformation. The aim is to show that MDADfacilitates the development of MAS.

3 Platform Independent Level

Several methodologies have been proposed to develop MAS which propose dif-ferent approaches and models to facilitate this development. The design ofMAS requires often the definition of a domain model, an organizational model,

Towards a Model Driven Process for Multi-Agent System 259

and one or several agent models. Each existing methodology relies on onlyone meta-model. The whole MAS is thus defined as an instance of this meta-model.

However, Demazeau [6] propose in the Vowels methodology to use a set ofmodels to define the multi-agent system. These models concern agent, interac-tion, organization and environment aspects. Thus, several meta-models can betherefore introduced to represent each aspect, and the MAS will be defined as acombination of these models.

Our approach relies on this idea. We propose a library of meta-models fordomain, organizational, and agent aspects. The main advantage of this approachis to provide more flexibility in the specification of the MAS. Thus, the designercan use the more appropriate agent meta-model (for instance the BDI agent)to describe the agents of its MAS application. Being limited by the number ofpage, we describe in this paper only an example of agent meta-model.

Our agent meta-model presents a basic agent representation which is similarto the meta-model given in [5]. The Agent concept has one Goal and executes aset of actions. The agent is defined as Class stereotype, and its behavior can bedescribed by an Activity instance, which is a sequence of actions.

Concerning the Goal concept, we define it as a stereotype of Constraint meta-class. Thus, Goal is defined as a boolean expression that the agent can evaluateduring its activity. This expression is written with OCL language.

Fig. 1. Agent meta-model

At the model level, the developer uses class diagrams to describe the agentstructure, and activity diagrams to represent its behavior. Figure 2a shows theProfessor agent structure. Its goal is to define the meetings of its timetable.Since the attribute neededSession is a list which contains the meetings to todefine, so we can express the Professor Goal by a boolean expression: the listneededSessions is empty.

The Professor agent behavior is represented by an activity diagram, see figure2b. The agent starts by evaluating its Goal. If its goal is not yet reached, then itasks the TimeTableManaging group manager to play the SessionSeeker role, bymeans of the action RequestRole. If the request is accepted, then it defines theneeded meeting attributes. Next it activates the SessionSeeker role. At the endof the role, the agent evaluates again its Goal.

260 T. Jarraya and Z. Guessoum

(a) Professor agent class (b) Professor agent activity

Fig. 2. Professor agent

Fig. 3. INAF meta-model

Towards a Model Driven Process for Multi-Agent System 261

4 Platform Specific Level

The implementation of a MAS involves the implementation of various agentsby choosing the suitable agent architectures. This implementation requires deeptechnical knowledge (component architecture, programming language, middle-ware...). A first abstraction level allows therefore hiding some technical detailsthat can be automatically deduced to simplify the implementation process. Forinstance, the agent engine is often generic. It is not therefore useful to havedetails about this engine to implement the agent.

We describe in this section the INAF framework meta-model [11]. The agentarchitecture model of INAF may be seen as an open model that can be thenenriched by incremental refinement. The agent behavior can be implemented byan ATN or a rule base. For agents interaction, INAF implement FIPA interactionprotocols. The Interaction Role concept is part of the protocol activity, which canbe played by one or more agents during an interaction. The Strategy concept is adecisional action which indicates which action to undertake while being based onthe goals and knowledge of the agent. In INAF, the Service concept correspondsto the interaction object. Any interaction relates to one service whose providingindicates the interaction success or failure.

5 Transformation Process

We present in this section the transformation rules needed to transit from anagent model to an implementation model compliant to the INAF framework.

5.1 Transformation Rules

We give in this section the main transformation rules necessary to implement theAgent concept with INAF framework. So, we start by writing the Agent concepttransformation rules.

Rule 1: For an Agent x, if all its roles were transformed (i.e. the agent playedroles are given in the the organization model), and if its behavior is describedby an Activity g, then:

1. We create an InteractiveAgent y with the name and attributes of x.2. Then, we invoke the rule 4 to transform g into an ATN t.3. Lastly, we attribute t to the attribute behavior of y.

Rule 2: For a Goal g which is associated to a Role r, and r is already trans-formed into an ATNBasedBehavior or an AbstractBehavior c, then we add to ca boolean Operation o with the name of g. The body of this operation is the gOCL body expression.

Rule 3: For a Goal g which is associated to an Agent a and that a is alreadytransformed into one InteractiveAgent i, then we add to i a boolean Operationo named ”isActive”. The body of o is the g OCL body expression.

Rule 4: For an Activity g then:

262 T. Jarraya and Z. Guessoum

1. We create an ATN t with the same name of g.2. Then an interpreter is used to cross g. For each activity element we call the

corresponding transformation rule.

5.2 Timetable PSM

At the beginning of transformation, rule 1 is the only active rule. So, rule 3 isapplied twice to produce two interactive agents: Professor and StudentGroup.Figure 4 shows the Professor class. The transformation of its Goal DefineTTgenerates a boolean operation defineTT() whose body takes the DefineTT OCLexpression. We keep at this transformation level the OCL notation, because PSMconcepts associated to these expressions, are not yet transformed to Java code.

Fig. 4. Professor interactive agent

The invocation of rule 4 generate two ATN of Professor and StudentGroupagents. SendMessage actions are transformed into actions. ReceiveMessage ac-tions are transformed into conditions. The condition takes again the name ofthe action ReceiveMessage. The message related to an action SendMessage orReceiveMessage is taken again on level PSM. Figure 5 shows the model elements(i.e. State, Condition and Transition), which compose ProfessorBehavior.

The know-how needed to transit from the PIM to a PSM compliant to INAF,can be summarized in these points:

1. The agent behavior is implemented by ATN.2. The Goal concept does not have a correspondence in INAF. We propose to

implement it by a boolean operation associated to the agent class.

The PSM obtained after rules execution can be refined in the aim to improvingit and bring it more closer to the operational system.

Towards a Model Driven Process for Multi-Agent System 263

Fig. 5. ProfessorBehavior ATN class

6 Code Generation

The third stage of our method MDAD is to generation platform code, startingfrom PSM. To obtain an operational MAS we must generate the applicationclasses which are platform complaint. These classes are an extension of the plat-form basic classes. We give in what follows rules allowing the generation of INAFclasses. This intermediate model is important for a clear representation the sys-tem structure, Moreover it is more easier to understand than INAF code.

6.1 Generation Rules

Rule 1: For an InteractiveAgent A, we add a new Class c which extends Inter-activeAgent Class.

Rule 2: For an ATN T, and if Agent A which is associated to T, was transformedinto a Class C, then:

1. we add an operation buildATN() to the class C.2. we add the code line : ” ATN atn = new ATN();”3. we cross T starting from its initial state4. For each Transition:

- For each Condition invoke rule 3- For each Action invoke rule 4

Rule 3: For a Condition C of an ATN T then:

264 T. Jarraya and Z. Guessoum

1. We generate code line ” NamedCondition ” + C.name+” = new Named-Condition(”+C.name+”);”.

2. We add a boolean operation O of the name C.name with the class A whichcorresponds to the attribute T.context.

3. If there is a Message M associated with Condition C, then we add to O thecode line: ” return currentMessage.getPerforamtive()=”+ M.name+”;”

Rule 4: For an Action A of an ATN T then:

1. We generate the code line ” NamedAction ” + A.name+” = new NamedAc-tion(”+ A.name+”);”.

2. We add an operation O with the name A.name to C which corresponds toT.context attribute.

6.2 Timetable Code

The application of the rules described previously on model PSM enables us togenerate system classes which are specialization of INAF basic classes. This stepallows to build the InteractiveAgent classes by application of rule 1.

Fig. 6. Professor class

Figure 6 describes the Professor class which extends the InteractiveAgentclass. It implements the static buildATN() method. The Java code of this methodis given in a note associated to Professor class. This code is obtained by appli-cation of rule 2. The methods defineNeededSession and startSessionSeeking areobtained by application of rule 4 to the all actions of ProfessorActivity ATN.The boolean methods cond T1, cond T2 and endSeekerRole are obtained byapplication of rule 3 to the conditions of ProfessorActivity ATN.

7 Conclusion

This paper presented a new approach, named MDAD, for agent oriented softwareengineering. MDAD is based on the MDA approach. It is founded on existing

Towards a Model Driven Process for Multi-Agent System 265

agent technologies and theories. Several meta-models and the needed knowledgeto transform them in an operational MAS have been introduced.

A first implementation of our method is done using the DIMA platform [10]and the MetaGen development tool [12]. MetaGen has been used to define meta-models. Models Editors are automatically generated from meta-models descrip-tion. These editors are used by the designer to describe models. DIMA is there-fore used to run and deploy the generated code.

The first development with MDAD showed that this new method is interest-ing and promising; it improves the multi-agent development process. However,more experiments with real-life applications are needed to validate the proposedapproach. We are therefore currently working on the development of more acomplex example in order to better evaluate our method.

References

1. Bellifemine, F., Caire, G., Trucco, T., Rimassa, G.: Jade Programmer’s guide JADE3.2 (July 2004)

2. Bernon, C., Cossentino, M., Gleizes, M.P., Turci, P., Zambonelli, F.: A study ofsome multi-agent meta-models. In: Agent Oriented Software Engineering Workshophelt at AAMAS’04, pp. 62–77 (2004)

3. Bernon, C., Gleizes, M.-P., Glize, P., Picard, G.: Problme de l’emploi du temps.Technical report, Groupe de travail ASA (2003)

4. Bresciani, P., Perini, A., Giorgini, P., Giunchiglia, F., Mylopoulos, J.: Tropos: Anagent-oriented software development methodology. Autonomous Agents and Multi-Agent Systems 8(3), 203–236 (2004)

5. Cossentino, M., Bernon, C., Pavon, J.: Modelling and meta-modelling issues inagent oriented software engineering: The agentlink aose tfg approach. TechnicalReport Agent Link III, The AgentLink AOSE Technical Forum Group, Ljubljana,Slovenia (February 28, 2005)

6. Demazeau, Y.: Vowels. In: IWDAIMAS‘96. Invited lecture, 1st Ibero-AmericanWorkshop on Distributed AI and Multi-Agent Systems, Mexico (1996)

7. OMG TC Document: Model driven architecture (mda). Technical report, OMG(2001)

8. Ferber, J., Gutknecht, O.: Aalaadin: a meta-model for the analysis and design oforganizations in mutli-agent systems. In: Demazeau, Y. (ed.) ICMAS’98, Paris, pp.128–135 (1998)

9. Object Managment Group: Mof qvt final adopted specification. Technical Reportptc/05-11-01, OMG (Novembre 2005)

10. Guessoum, Z., Briot, J.-P.: From active objects to autonomous agents. IEEE Con-currency 7(3), 68–76 (1999)

11. Jarraya, T., Guessoum, Z.: Reuse interaction protocols to develop interactiveagents. In: Liu, J., Wah, B.W. (eds.) Proceedings of IAT conference, Hong Kong,China, Dcembre 18-22, 2006, IEEE Press, Los Alamitos (2006)

12. Revault, N., Sahraoui, H., Blain, G., Perrot, J.-F.: A metamodeling technique:The mtagen system. In: Beilner, H., Bause, F. (eds.) MMB 1995 and TOOLS1995. LNCS, vol. 977, pp. 127–139. Springer, Heidelberg (1995)