Meta-models for Building Multi-Agent Systems Jorge J. G 6 m e z - S a n z Dep. Sistemas Inform/Jticosy Prog Universidad Complutense Madrid Avda. Complutense s/n 28040 Madrid, Spain +34 91 394 70 69
Juan Pav6n Dep. Sistemas Inform~ticos y Prog Universidad Complutense Madrid Avda. Complutense s/n 28040 Madrid, Spain +34 91 394 70 69
[email protected]
[email protected]
ABSTRACT
Francisco Garijo Telefonica I+D . Emilio Vargas 6 28043 Madrid, Spain +34 91 337 42 35
[email protected]
verification of communication pmtucols, or task execution. Another difficulty is the scale o f application o f these methodologies and their ability to be incorporated in common sot~vare engineering practices. In most o f the cases the engineer, the end user of the methodology, needs to acquire further eJtpertise from what is required at his position in order to successfully apply the methodology.
This paper reports the experience of using meta-models for improving analysis and design activities in multi-agent system engineering. Four recta-models describing different views of the MAS such as organization view, agent, goals/tasks, and interactions are presented. Meta-models are described in UML MOF which makc them compatible with current software engineering formalisms. Engineers may iustantiate the metamodels to produce the entities that may appear in concrete MAS. These recta-models have been derived from several experimentations in MAS, which are briefly described in the paper. Engineering experience in using the recta-models for building M_AS applications is also re~orted in the conclusions.
As an integrating approach, the MESSAGE project [7][10][15] proposes a methodology for developing multi-agent systems (MAS) that uses UML as notation, the Rational Unified Process [14] as a lifecycle model for the development of agent software, end a set of meta-models that are defined using the OMG's MetaObject Facility (MOF) [18], each dealing with a different viewpoint o f the MAS, in order to guide analysis and design activities. This paper extends MESSAGE methodology in two aspects: more integration in analysis and design stages, and a more coherent model o f the different viewpoints o f the MAS, which is centered in the relationships among agents, tasks, and goals. The idea behind the whole process is to reduce the costs of building a MAS application by starting from an abstract specification o f the MAS (result of the analysis by using the metamodels), and generating the final system by means of transformations o f this specification into computational entities.
Categories and Subject Descriptors D.2.1 [Software gagineer/ng]: Requirements/Specifications methodologies
General Terms Documentation, Design, Experimentation
Keywords Multi-agent systems, software engineering, methodology, metamodel, MOF.
The paper describes each o f the~meta,-modeh and theist appli~tioa to analysis and design in Section 2. These meta-models have been derived from several experimentations, which are briefly described in Section 3. Finally, some open issues and conclusions are discussed in Section 4.
1. I N T R O D U C T I O N Different proposals in the field of Agent-Oriented Software Engineering (AOSE) try to integrate results from agent research with engineering practices, some from the perspective of agent theory (e.g., KAO$ [3], Vowel Engineering [4], or GAIA [19]), some as an evolution of object-oriented systems (e.g., Kendall [13]), others as task execution models (e.g. Desire [1]), or from a knowledge-based systems approach (e.g., TROPOS [2], MASCommonKADS [12]). Although they start from valid scientific assumptions, their application to real problems is still challenging because they only address specific phases of the soil"ware lifecycle, or concrete issues, such as goal extraction, definition and
2. M E T A - M O D E L S F O R M A S SPECIFICATION The general approach to specify MAS is to divide the problem in more concrete aspects to generate different views o f the system. This idea already appears in the work of Kendall [13], Vowc[ Engineering [4], MAS-CommonKADS [12], and later in GAIA [19]. The difference of our proposal with respect to the above is in the definition of the views and their integration in the development o f the MAS. The definition o f the views is based in the specification of meta-models by using OMG's Meta-Object Facility (MOF) [1S].
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or dis~buted for profit or commercial advantage and that copies bear this notice and the full citation on the fwst page. To copy otherwise, or republish, to post on serves or to rcdistrilmte to lists, requires prier specific permission and/or a fee.
Meta-models are useful as a kind o f templates for generating agent models. They describe what any MAS should have. The mission of the engineer is to instantiate them to define the entities that may appear in concrete MAS. Instantiation means that for each generic entity in the meta-model (e.g., recta-classes) the engineer must look for specific types of entities (e.g. classes) in the current
•DIC 2002. Madrid, Spain.
© 2002 ACM 1-59113-445-2/02/03...$5.00.
37
agents (WFPlays). This clarifies the potential collaboration among agents and the functional dependencies at this level.
problem domain that share the features specified in the metamodel (relationships with other entities and related attributes). The final result is a view o f the system under development, which is consistent with the high-level specification o f what has to be in a MAS.
Organization structures support another level o f structuring in the organization. The idea is similar to departmental organization (department as organization strucun~) in enterprises (organizations). This idea appears first in [8] and has been adapted and extended for mcta-modeling in [10]. For the analyst, the organization meta-model provides a high level view o f the M_AS, and should be the starting point when developing a MAS application, as it allows result integration from the other views. It identifies and places MAS tasks, responsible agents, available resources, and the relationships among all o f them. In the design, the organization model provides a high-level view o f the system architectxtre and drives the pr(w.~ss for building the MAS. Furthermore, the organization recta-model shows in a graphical way the relationships that exist among the different entities and associates semantics to them. The knowledge o f the existence o f these relationships and their meaning constitutes the social knowledge o f the agent. In this way, an agent will obey other i f and only i f there is an instance o f a subordination relationship between them.
FiEure 1. O r e a n i z a t l o n mete-model Mcta-models are applied during the analysis when looking for a first description o f the MAS. In this sense, a meta-model acts as a guideline for the analyst helping to identify which entities exist. During design, the recta-model is refined, by identifying new components and relationships among them, in order to achieve the appropriate level o f detail. In parallel, the components o f the m e t a - m o d e l are translated into computational entities whose specification, design and implementation are already well known. At the end of the process there is a specification o f the MAS with a design that is based on concrete and implementable entities.
2.2 Agent meta-model The agent meta-model defines everytldn~g that is necessary to define an agent by itself. This identification is made in an ordered way following the meta-model, generating instances that constitute a sequence o f views of each agent in the system. These views represent high-level specification o f each o f the agent types in the MAS.
The meta-models presented below are the result o f the experience gained in several projects: MESSAGE (Eurescom 1)907 [7]), Communications Management Process Integration Using Software Agents (Eurescom P8 ! 5 [6]), and Intelligent and Mobile Agents and their Applicability to Service and Network Management (Eurescom P712 [5]). These meta-models allow defining the architecture o f the MAS (organization recta-model), key features o f agents (agent recta-model), agent co-operation (interaction meta-model), and goals and tasks of the M_AS (goal/task model). Information elements that represent domain specific information do not require the definition o f a specific recta-model, as they can be modeled following a classical objectoriented methodology and arc specific to the application.
Fiw,ure 2. Meta-model for the anent The agent concept underlying this meta-model is the one defined
2.1 O R G A N I Z A T I O N M E T A - M O D E L
by Newell [16]. An agent is a program that exists at the lmowledge level. It has a physical body with which it can act in the environment, a knowledge body which contains whatever the agent ]lOWS at some time, and a set o f goals. Also, an agent behaves according to the principle o f rationaliW which says i f an agent has a lmowlcdge that one o f its actions will lead to one o f its goals, then the agent will select that action. Following this definition, an agent has goals and there should be some association type between agent tasks and goals.
An organization in MAS characterizes a group of agents that work together towards a common goal (purpose). The organization may consist o f only one agent or several groups o f co-operating agents, which form part o f organizational structures that establish relationships among them. The organization recta-model (figure 1) intends to structure agents in the system and reflect the goals o f the system, the ways to achieve them (resources and tasks), which agents have responsibilities and their role in the global process.
The agent recta-model (figure 2) identifies the tasks that the agent has to execute (relationship WFResponsible)and how the result o f these tasks affects existing mental entities (relationship GTAffects). The result o f one task may affect to the agent's mental state. Satisfying a goal (GTSatisfies) means that the result o f one task implies that a goal has been reached. GTFailsmeans that the result o f one task implies that a goal is considered as unreachable.
In the organization, workflows specify dependencies among tasks in terms of data flow (WFRequires, WFProduces), decomposition o f tasks (and WFDecomposes), use of resources (WFUses), agents responsible for performing each tasks (WFResponsible), relationships among agents (ARelationship), and roles performed by
38
On the other side, the agent plays roles in several workflows in the system. The association of an agent to a role (WFPlays) means that the agent acquires all the properties and responsibilities assigned to the role (goals and interactions in which the rule participates). The agent has a mental state which is used to decide what to do next (MentalStateProcessor). This mental state is managed by the MentalStateManager. This entity is in charge of adding/removing knowledge as well as consistence maintenance. Agent's mental state (figure 3) consists of control entities and information entities. Control entities specify what is expected Figure 4. Relationships between goals and tasks found in the structure of packages that represent the organization in the design. With respect to the mental state, there should be an entity that is responsible to interpret it and an appropriate representation for it. In the methodology such entity is called knowledge processor. This entity brings together the results of the agent model (sought goals) with those from the interaction model (interactions that occur when performing tasks to satisfy the goals). Its construction can vary from a simple state machine, an inference engine with production rules, or neural networks.
Fiuure 3. Mental State soecilication of the Auent from the agent, whilst information entities describe the state of the world as seen by the agent. From these entities, the most fundamental is the objective, which represents a goal for the agent. The objective is an entity with a state that specifies whether it has been satisfied, will never be satisfied, or is in process of being satisfied (solving).
2.3 T A S K / G O A L S M E T A - M O D E L The task/goal meta-model (figure 4) describes relationships among goals, which state the purpose of the entities in the system, and tasks, which are responsible of making the system progress towards these goals.
The agent meta-model supports the analyst for the identification of three components: roles played by the agent, tasks associated to the agent, and its mental state. Roles indicate capabilities and are associated to the agent as instances of the recta-relationship WFPlays. An association with a role implies to acquire the goals associated with the role, participate in the interactions in which the role participates, and be able to perform the tasks that the role executes. At this [~vel, the analyst has to be conscious of the imptications of the association WFPlays. Consequences at the level of agent implementation are left to the design stage.
Tasks produce effects when executed (relationship WFProduce) that can be translated into the modification of the agent's mental state in the form of a change of the objective's state (relationships GTSatisfoctionRequires, GTFailureRequires) or generation of new knowledge about the state of the world. There are also relationships among tasks and goals. In the rectamodel of figure 4 there is only the decomposition relationship, although there may be others, such as precedence in execution time (WFPrecedes), non satisfactibility of two goals simultaneously (GTIncompatibiliO,), or concurrence of tasks
The first tasks that appear in the analysis are those related with the organization, in the context of the organization workflows. When assigned to an agent, it implies that these tasks must be in the model for this type of agent, and that the agent has some objective that will be affected by their execution (instances of the relationship GAffects).
(WFConcurrent). During the analysis, the goal/task meta-model identifies the goals sought by the MAS and its constituents, the agents. Similarly, it identifies also the tasks of the MAS and its agents, in the context of the goals that they try to achieve. In order to do this, it should be specified what is needed to consider that guals are satisfied (instances of the relationship GSatisfactionRequires), which has influence in the results that a ~ produced by tasks (instances of the relationship WFProduce). Once identified, there is a structuring of the results. This is done with instances of structural relationships GTDescomposes and WFDescomposes. At the end of the analysis there is a taxonomy of tasks and goals, a tree of goals, and a tree of tasks, and relationships between them.
Agent's mental state does not need to be detailed during analysis. According to experimentation of the methodology, it suffices with a relation of the goals and compromises that may exist as a consequence of the associations with roles. There are other sources of goals, such as definition of the organization purpose. During the design stage there is a need to choose an architecture for the agent, as a computational representation of the agent. The development of this methodology has been experimented with the architecture described in [10] and [11], which was already used in [6] and [7]. This architecture organizes, agent components in several layers: resources, perception, application domain, and conrail.
Goals arc considered fundamental entities when designing the control of the agent. The purpose of this control is to provide the impression to an external observer that the agent behaves as pursuing goals.
Roles are represented by packages, which group associated goals and tasks, and interfaces, which indicate to the developer what functions have to b¢ implemented. The place of the roles has to be
There may be different' types of conlrol structure. We have experimented with cognitive agents, which are guided by an
39
inference engine, and reactive agents, which are guided by finite state machines. For cognitive agents, goals are represented in a declarative way, with goal trees and resolution rules. The trees are instances of relationship GDecomposes, whilst the resolution rules are instances of the relationships GSatisfactionRequires and GFailureRequires. For reactive agents, there are representations of finite state machines, where relationships GSatisfactionRequires and GFailureRequires are conditions of transitions, and goals are the set of final states.
to get (goal) from their participation. This is represented with instances of relationships WFPursues and IUExecutes. It is not necessary for the analyst at this level to detail interaction messages, hut it should at least describe briefly how they should look like. With this recta-model it is possible to express, for instance, that the interaction should follow the FIPA-Request protocol and the agents participate in the context of a concrete task needed to get satisfaction of some goal. Interactions in the design have to be as much detailed as possible. This means, in the case of protocols, who plays each role in the protocol, and in the case of messages, which is their exact content and addressee.
Tasks can be represented by using the Task-Session model defined by OMG [17], which fits well in the proposed agent metamodel, and is already quite complete, allowing also the specification of workflows. In this context, task decomposition can be seen as a workflow that needs to access resources and produce results'.
i
Interactions can be represented with the concept of session. A session defines the context for an interaction or a set of interactions. The state of the session determines which communication actions an agent can perform at a given time, and what can be expected. There is a session manager in charge of creating, monitoring, and destroying sessions. With the session and session manager is easy to maintain several interactions in parallel with one or several agents. Each session can be developed independently from each other, by using different communication techniques. The only requirement is that what is sent is in accordance with the specification of the interaction.
Cnntn~Hnml
Figure 5. Interaction meta-model
2.4 I N T E R A C T I O N M E T A - M O D E L The interaction meta-model (figure 5) provides the concepts needed to define interactions. Each interaction seeks a concrete goal (relationship IPursues), but in order to get it has to execute tasks and declare explicitly who are responsible for them (relationship IUExecutes).
(a)
Co)
Figure 6. (a) Interaction units definition and Co) Mental State Patterns On top of the session is agent control. This c0ntml is in charge of dispatching tasks. The session provides high-level information (in which state is the communication), which has to be complemented with the agent's mental state information. With those data, the agent control decides whether it has to execute or not a specific action. Given the representation of the control, the action will be activated by a production rule or as a state transition.
Looking for generality, the roles participating in the interaction are associated with the concrete entities that compose the interaction. In a FIPA protocol based specification, one valid instance of interaction unit would be, for example, a FIPARequest. In a message-based specification, the valid instance would be a single message. A particular case of message-based specification is when the message is a call to a remote procedure (e.g., using CORBA or RMI).
3. E X P E R I M E N T A T I O N The proposed methodology is the result of experimenting in the development of MAS prototypes along several Emeseom projects. The agent architecture was defined in [5] were agents provided telecommunications management ser¢ices. This architecture was refined in [6], where the task/goal model was developed, and applied to build personal assistants for supporting a workflow management system. Finally, the meta-models were established in MESSAGE [7] as the core component to define the methodology for analysis and design of MAS. These meta-models have been refined as shown hcre, and applied to thc development of a MAS that provides notification and information services on flights. The most significant in this development has been the definition of the organization mcta-model, and its driving character, especially in the analysis process [10].
The interaction units are detailed in figure 6. The composition of interaction units following a determined order lead to the specification of the execution of the interaction. Similar to interactions, an interaction unit also describes who initiates (IUlnitiates), who collaborates (IUCoilaborates) and which tasks are executed (IUExecutes). Note that there exist optional associations with mental state patterns which denote collaboration and initiation conditions in terms of mental state entities. During analysis, the interaction m©ta-model is useful to highlight what co-operations are important in the actual use case, and how do they affect to the purpose of the system. These interactions can appear from the requirements specification or from instances of the organization meta-model. Anyway, it should be specified which roles participate in the interaction, and what do they expect
Results from experimentation confirm the usefulness of rectamodels to guide the analysis and design processes. In analysis, the
40
concepts from MESSAGE and the meta-models described using MOF allow the analyst to define the architecture and functionality for the MAS with rignur, ease, and comprehensibility. This is consequence of the support of high-level ~'rns for analysis such as organization, agent, resource, goal, task, etc. The definition of these terms with MOF allows to develop design patterns that simplify and shorten the development time for a MAS. During the development of the MAS prototype for flight assistance several architectural patterns were reused for both cognitive and reactive agents. The use of these patterns has implied a reduction of shout 50 to 70 per cent in the implementation of the application components.
4. CONCLUSIONS The availability of a set of meta-models to drive the analysis and design of a MAS eases the task of the developers of this kind of systems, as it offers, from the very beginning, a set of views of the system and a taxonomy of concepts for their definition. As a complement, there is a set of architectural patterns for the construction of this type of systems from a practical viewpoint. In this sense, it is a novelty to present the organization meta-model, which al-lows the engineer to obtain a high level specification of the sysl~n. The experience gained with the prototyping using meta-models, views and architectural patterns in the design shows that these concepts and notations are easy to assimilate in cur-rent engineering practices. The use of a standard such as UML and the application of MOF contribute to this.
[4] Demazeau, Y.: From interactions W collective behaviour in agent-based systems. In European Conference on Cognitive Sciences, 1995. [5] Euresenm P712. Intelligent and mobile agents and their
applicability" to
service
and
network
management.
http://www.euros¢om.de/pfiblic/pmj ects/P700series/P712/P712.htm [6] Eurescom P815. Communications Management Process
Integration
Using
Software
Agents.
http://www.eurescom, de,/public/p rojects/P 800series/P815/P8 ! 5.him [7] Eui'escom P907. MESSAGE Methodology, Initial Version. July, 2000. http ://www.eurescom.d e/,-publicwebspace/P900-series/P907/index.htm [8] Ferber, J, Gutkuecht, O.: A Meta-Model for the Analysis and
Design
of
Organizations in
Multi-Agent
Systems.
Proceedings oflCMAS 98. [9] Garijo, F. et al.: Development of a Multi-Agent System for cooperative work with network negotiation capabilities. In Intelligent Agents for Telecommunication Applications. LNAI 1437. Ed. Springer Ver-lag. Pages 204-219. 1998. [10] Garijo, F., Gomez-Sanz, J.J., Pav6n, J.: Multi-Agent System Organization. An Engineering Perspective. Proceedings of MAAMAW 2001. [11] Garijo, F., Gomez-Sanz, J.J., Pav6n, J.: Intelligent Interface Agents Behaviour Modelling. In LNAI 1793, pp. 598-609. Springer Verlag, 2000.
The meta-models defined so far are not definitive. There are some issues under evaluation, more concretely in the agent and interaction mete-models. For the agent meta-modal we are studying if it is enough to represent any type of agent, such as real-time agents, or how to include leaming capabilities. For the interaction meta-model we are trying to include planning and enoperation techniques, and algorithms for conflict resolution.
[12] Iglesias, C.,
Garijo, M., Gonzalez J., and Velasco J.:
Analysis and design of multiagent systems using MASCommonl(JIDS. In M. P. Singh, A. Kan, and M. J. Wueldridge, editors, Intelligent Agents IV (LNAI Volume 1365), pp.313-326. Springer-Verlag, 1998. [13] Kendall E.: A Methodology for Developing Agent Based Systems for Enterprise Integration. IFIP Working Conference of TC5 Special Interest Group on Architectures for Enterprise Integration, Queensland, Australia, November 1995.
Finally, it is important to mention that there is a need to provide a more detailed and explicit view of the environment. Currently, the environment is present as organization resources, and we consider that the meta-models should offer more complex representations to model the environment.
5. A C K N O W L E D G E M E N T S
[14] Kruchten, P.: The Rational Unified Process. Wesley, 1999.
This work is sponsored in part by the Spanish Committee for Science and Technology (CICYT, TIC2000-0737-C03-02).
[15] Massonet, P. et al.: MESSAGE: Engineering Agent b~stems with UML. Proceedings of AOSE 2001.
6. REFERENCES
[16] Newell A.: The knowledge level. Artificial Intelligence, 18 (1982) pp. 87-127.
[1] Brazier, F.M.T. ; Keplicz, B. Dunin; Jennings, N.; Trenr, J. Desire: Modelling multi-agent systems in a compositional formal framework. International Journal of Cooperative Information Systems, 6:67--94, .1997.
[17] Object Management Group. Task and Session Specification. Version 1.0. April 2000.
CBOs
[18] Object Management Group. Meta Object Facility (MOF) Specification, V. 1.3. formal/2000-04-03. http://www.omg.org
[2] Brnsciani, P.;Perini, A.;Giorgini, P.;Giunchiglia, F.; John Mylopoulns, J.. A Knowledge Level Software Engineering Methodology for Agent Oriented Programming. Proceedings of AOSE 2001. [3]
Addison-
Jennings N., Kinny D.: The Gala Methodology for Agent-Oriented Analysis and Design.
[19] Wooldridge M.,
Journal of Autonomous Agents and Multi-Agent Systems, 3, 2000, pp. 285-312.
Dardene, A.;van Lamsweerde, A.;Fickas, S.: Goal-Directed Requirements Acquisition. Science of Com-puter Programming. Vol 20, North Holland, 1993, pp. 3-50
41
