Visual Construction of Multi-Agent-Systems according to the AgentComponent Approach and the Run-Design-Time Concept

Size: px

Start display at page:

Download "Visual Construction of Multi-Agent-Systems according to the AgentComponent Approach and the Run-Design-Time Concept"

Erick Ray
6 years ago
Views:

1 Visual Construction of Multi-Agent-Systems according to the AgentComponent Approach and the Run-Design-Time Concept Philipp Meier Institute of Computer Science, Ludwig-Maximilians-Universität Abstract During the last years graphical tools have been developed for constructing Multi-Agent-Systems (MAS) [15, 1, 2]. We provide additional concepts for simplifying the visual construction of MAS, namely the AgentComponent approach [13] and the Run-Design-Time concept [12]. The AgentComponent approach combines agent technology and component technology and adds component features like reusability and customizability to agent technology. This approach defines the components an agent is composed of and the services an agent provides for its visual construction. The Run-Design-Time concept provides a visual handle on the running and deployed agents, i.e. running agents can be visually customized according to the AgentComponent approach. Using the Run-Design-Time concept there is no need to stop the running MAS to extend and customize its functionality or structure. In this paper we give a gentle introduction to these additional concepts and we show how MAS can be visually constructed using the AgentComponent Tool which implements both additional concepts. We will guide the reader through a simple example of building a MAS illustrated by screenshots from the AgentComponent Tool. 1. Introduction Agents are autonomously and proactively working software entities which communicate and collaborate using certain protocols (FIPA-ACL, KQML) [8, 9, 11]. As agents are complex software entities the construction of MAS, composed of collaborating and communicating agents, is a difficult task. Visual tools [15, 2, 1] have been developed for simplifying the construction of MAS. We enhance these visual tools by two additional concepts. First we have found the features of software components (reusebility and customizability [3]) as a suitable means to define the sub-components and the services of an agent (AgentComponent). In the second step we have realized that the runtime customization and extension of MAS is not (well) supported in other agent toolkits. Therefore we develop an architecture for agents to support their customization during runtime (Run-Design-Time). We realize both additional concepts in the AgentComponent Tool that will guide the reader through a simple example in Sect. 3. In Sect. 2 we give a short introduction of both concepts (Run-Design-Time and AgentComponent). Sect. 3 describes the visual construction of a simple MAS illustrated by screenshots of the AgentComponent Tool. In Sect. 4 we discuss some related work and the differences to our approach. And finally Sect. 5 concludes the paper. 2. A Gentle Introduction to the AgentComponent Approach and the Run-Design-Time Concept This section gives a gentle inroduction into the basic concepts for the AgentComponent and the Run-Design- Time. The AgentComponent approach and the Run- Design-Time concept are detailly presented in [13, 12]. AgentComponent. In general, the AgentComponent has all agent properties [9, 11] like autonomy, reactivity, proactivity and interaction and adds component features like reusability and customizability (according to the componentifying concept [13]). An AgentComponent is a generic component that consists of default subcomponents and services that every agent must provide in any context. And in this way an AgentComponent can be instantiated/reused for every agent one wants to build. By customizing the default AgentComponent (w.r.t. its subcomponents) it can be adjusted for different contexts. Every AgentComponent includes the following entities for which it provides services (the collection of all AgentComponent services is shown in Fig. 1): A knowledge base, communication slots (holding communication partners), a set of ontologies and a set of Process- Components (behaviours). A user can easily customize an AgentComponent instance for his purpose and for his con-

2 text in the following ways: 1. Customizing the communication partners of an AgentComponent instance. Each AgentComponent instance has so-called slots that hold information about communication partners. Communication partners can be added to or removed from the slots of AgentComponent instances. 2. Customizing the ontologies of an AgentComponent instance. Ontologies can be registered or deregistered from an AgentComponent instance. 3. Customizing the ProcessComponents of an Agent- Component instance. AgentComponent instances consist of so-called ProcessComponents (PCs) that implement and describe simple or complex behaviours that can be added to or removed from any AgentComponent instance. 4. Customizing the knowledge base of an AgentComponent instance. Each AgentComponent instance includes a knowledge base where instances of ontology concepts can be asserted, retracted and retrieved. provides for inter-agent communication (send and receive). Using these services messages and informations (ontology concepts included in messages) can be sent and received. And finally the IntraAgentWorkflowInterface defines the services on the knowledge base of an AgentComponent (assert, retrieve, retract). These services are also used to control the intra-agent workflow, i.e. to control the workflow of ProcessComponents that have been added to an AgentComponent instance. E.g. a ProcessComponent requires (retrieve) an instance of an ontology concept from the knowledge base, that has been added (assert) to the knowledge base before by another ProcessComponent. Run-Design-Time Concept. The Run-Design-Time concept determines the way how agents can be visually customized using a tool. The goal of the Run-Design- Time (RDT) concept is to give a visual handle on a deployed MAS. I.e. any created and deployed agent can be graphically customized while it is running on a platform. The AgentComponent approach [13] (we have introduced above) provides the underlying customization concepts for the agents (AgentComponent) that we want to visually cutomize according to the RDT concept. Fig. 2 insinuates the parts an AgentComponent is composed of (CommunicationPartners, Ontologies, Behaviours and a Knowledgebase). A deployed AgentComponent instance and its running components are visually represented by AgentMeta- Datas. These AgentMetaDatas represent the visual handle <<AC>> <<Interface>> IntraAgentWFInterface assert retrieve retract <<Interface>> StructuralInterface addac removeac addpc removepc addslot removeslot connectslot disconnectslot addonto removeonto <<Interface>> InterAgentWFInterface send receive System developer / User / PC Figure 1. The services provided by the generic AgentComponent Fig. 1 presents the interfaces w.r.t. the services of the AgentComponent. The interfaces of the AgentComponent are separated into StructuralInterface, InterAgent- WorkflowInterface and IntraAgentWorkflowInterface. The StructuralInterface defines all services for customizing the structure of an AgentComponent instance w.r.t MAS (e.g. adding or removing AgentComponents, ontologies, slots, ProcessComponents). The InterAgentWorkflowInterface describes the services that an AgentComponent instance Figure 2. The Run Design Time concept on the running AgentComponents. I.e. every graphical customization of an AgentMetaData has a direct effect on the represented deployed AgentComponent instance. So e.g. visually adding an CommunicationPartner (see Fig. 2) to an AgentMetaData has the same adding effect on the represented running AgentComponent. The realization of the RDT concept requires an elaborated software architecture. For this purpose we have used well-known object-oriented design patterns, namely the

3 Model-View-Controller, Mediator, Interface and Observer [10, 4]. We adjusted these patterns for agent-oriented software development and described them in a catalogue of Agent Implementation Patterns [12, 14]. Using this architecture we realized a prototype tool (AgentComponent Tool) that implements the AgentComponent approach and the Run-Design-Time concept. In the next section we demonstrate by simple exapmles how to visually design and customize a MAS according to the AgentComponent approach and the Run-Design-Time concept. These examples are illustrated by screenshots of the AgentComponent Tool. 3. Visual Construction and Customization of Multi-Agent-Systems In this section we guide the reader through an example of constructing and customizing a MAS. The simple example-mas consists of two AgentComponent instances ( philipp and anna ). We will show how to create these AgentComponent instances, to customize their communication partners, ontologies and ProcessComponents (according to the services in Fig. 1). We will also show how one can visually customize the knowledge base of Agent- Component instances. Moreover we present some features of the AgentComponent Tool that are not covered by the Run-Design-Time or AgentComponent concepts, namely how ProcesComponents can change the structure of an AgentComponent instance and how permissions for every AgentComponent can be set. Before we start with the construction of the example- MAS we need to take a closer look on the AgentComponent Tool which we use to illustrate the example. As we mentioned before the AgentComponent Tool implements on the one hand the AgentComponent approach and on the other hand the Run-Design-Time concept for customizing the running AgentComponents. Moreover this tool supports the distributed construction of MAS, i.e. several Graphical User Interfaces (GUI) can take part in building and customizing MAS. For this purpose the AgentComponent Tool consists of the following parts which are again realized as agents: The Mediator service: The Mediator manages/controls all communication (concerning the services of the AgentComponent, see Fig. 1) between the running AgentComponents and the GUIs that take part in customizing the MAS composed of AgentComponents. The Client GUIs: The Client GUIs can run on different hosts and take part in constructing and customizing a MAS composed of AgentComponents. They provide the visual handle on the MAS. The Mediator, the Client GUIs and the AgentComponent are based on the JADE (Java Agent Development Kit) Framework for MAS [7]. They are all implemented as JADE-Agents (refer to [12] for a detailed information on the design and implementation of the AgentComponent Tool). To run the AgentComponent Tool we have to start the JADE agent platform. Then we start/register the Mediator service that waits for Client GUIs to take part in constructing the MAS. The Mediator is visualized by the MEDIATORGUI that simply shows all messages received from the Client GUIs and the deployed AgentComponent instances. Now we can start Client GUIs. After starting a Client GUI it shows up consisting of three parts (see Fig. 3): The toolbar including agents (AgentComponent) and ProcessComponent which can be added. The agent panel where AgentComponent instances can be inserted and customized. The behaviour panel where the ProcessComponents can be added to an AgentComponent instance and customized. After this short introduction of the tool we begin with our example by inserting/adding two AgentComponent instances to the MAS. Adding AgentComponent instances. Our example- MAS consists of two AgentComponent instances, namely philipp and anna. In this paragraph we create both agents with empty communication slots, an empty ontology slot, an empty ProcessComponent slot and an empty knowledge base. This means we instantiate two default AgentComponents with different names. In the next paragraphs we will show a stepwise refinement of these default AgentComponents by customizing their sub-components and adjusting them for our simple context. To create and add an AgentComponent instance using the Client GUI we choose one of the provided agent buttons on the toolbar (e.g. AC) and drop it on the agent panel. After inserting the AgentComponent s name it appears in the agent panel and is started on the JADE platform (see Fig. 3). The visualized AgentComponent (AgentMetaData) instance provides a list for the communication partner slots, a button for customizing the ontologies and a button for filling created slots with destinations (other agents). Adding and filling communication partner slots. In the next step we want philipp to know anna using the communication slot mechanism. For this purpose we add a communication slot called friends to philipp and fill this slot with anna as destination. In this way we produce a communication path between philipp and anna. Using the Client GUI we create a communication partner

Link Slots button). Fig. 4 fills the created slot friends of philipp with anna as destination. Double clicking on a slot shows up a dialog containing all the entries of the marked slot.

4 Figure 3. Inserting and starting an AgentComponent instance Figure 4. Adding and filling a communication partner slot slot (right click on the slot list and inserting a name for the slot) and fill this slot with other AgentComponent instances as destinations (using the Link Slots button). Fig. 4 fills the created slot friends of philipp with anna as destination. Double clicking on a slot shows up a dialog containing all the entries of the marked slot. Adding ontologies. Ontologies consist of concepts that define a particular context. Instances of such ontology concepts can be sent between agents for collaboration in a certain context. To understand received ontology concepts each participating agent requires a registration of these ontologies. In our example we provide a simple ontology called PaperOntology that defines some concepts for writing a paper for a conference and organzing the authors of that paper. Both philipp and anna need to understand this ontology (we present later how to create instances of these ontology concepts and how to send these instances over a communication slot). Using the Client GUI we have to activate the onto button that shows up the ontology dialog where provided ontologies can be registered to or deregistered from an AgentComponent in-

stance. In Fig. 5 we register the provided ontology Paper- Ontology with the AgentComponent instance philipp. Figure 6. Adding ProcessComponents to AgentComponent instances Figure 5.

These behaviours can be added to or removed from Agent- Component instances like philipp and anna. We provide some example behaviours all listed on the toolbar of the Client GUI.

5 stance. In Fig. 5 we register the provided ontology Paper- Ontology with the AgentComponent instance philipp. Figure 6. Adding ProcessComponents to AgentComponent instances Figure 5. Adding ontologies to AgentComponent instances Adding ProcessComponents. ProcessComponents represent the behaviours of an AgentComponent instance. These behaviours can be added to or removed from Agent- Component instances like philipp and anna. We provide some example behaviours all listed on the toolbar of the Client GUI. We use the simple SendHello and ReceiveHello ProcessComponents to illustrate the way behaviours work. When a ProcessComponent has been added to an AgentComponent instance it starts immediately its workflow. In our example (see Fig. 6) we add the Send- Hello behaviour to philipp, that sends the string Hello, How Are You Doing using the slot friends. And we add the ReceiveHello behaviour to anna that receives the sent message and prints it. In this way we can build up inter-agent workflows, i.e. communication and collaboration between AgentComponent instances. To add a ProcessComponent to an AgentComponent instance using the Client GUI we drop a provided behaviour from the toolbar on to the behaviour panel of an AgentComponent instance (see Fig 6). Creating ontology instances and using the knowledge base. Now we use our example-mas to create instances of ontology concepts, to assert these instances to the knowledge base of the AgentComponent instance and to send them over existing slots to other AgentComponent instances. We use the before registered PaperOntology to illustrate these features. The concept Creates- PaperOrder of the PaperOntology holds some basic information about a conference where the paper should be submitted. We create an instance of this concept, assert it to philipp s knowledge base and send it over the slot friends to anna. Then anna receives the sent CreatesPaperOrder instance and asserts it to her knowledge base. For this purpose we use a special ProcessComponent, Figure 7. Using the Introspector part 1 namely the Introspector. The Introspector is a powerful tool that visualizes the structure of an AgentComponent instance (slots, ontologies, knowledge base). Using this tool one can create instances of provided ontologies and can assert (w.r.t retract and retrieve) them to the knowledge base of the AgentComponent instance. Moreover these ontology instances can be sent and received over existing slots of an AgentComponent instance. Fig. 7 shows how an Introspector working on philipp can be used to create an instance of an ontology concept CreatesPaperOrder ( CreatesPaperOrder is an element of the before registered PaperOntology ). This instance (the class structure of this

instance and the values of the created instance are shown in the tree and the table in the center of the Introspector) can be asserted to the knowledge base (the instances of the knowledge base are

8 shows how an Introspector working on anna can be used to receive an instance of an ontology concept.

6 instance and the values of the created instance are shown in the tree and the table in the center of the Introspector) can be asserted to the knowledge base (the instances of the knowledge base are shown in the list on the left bottom of the Introspector). And finally we send this instance using the before added slot friends. Fig. 8 shows how an Introspector working on anna can be used to receive an instance of an ontology concept. For this purpose we need to indicate (mark) that we want to receive a concept of the PaperOntology. Having marked the PaperOntology and activated the Receive Predicate button the received instance is shown in the list on the right bottom of the Introspector. Now the received instance can be asserted to the knowledge base of anna. Figure 9. Customizing the structure of an AgentComponent instance via a behaviour Figure 8. Using the Introspector part 2 Changing the structure of an AgentComponent instance by ProcessComponents. Besides our example we demonstrate the use of special ProcessComponents, that change the structure of AgentComponent instances. ProcessComponents are able to change the structure of Agent- Component instances and MAS (such as adding or removing AgentComponent instances, slots, ontologies or behaviours). These structural changes are automatically reported to the Client GUIs and presented there. In Fig. 9 we drop the Runtime ProcessComponent on to the behaviour panel of anna. The Runtime behaviour changes the structure in the following way: Adding a slot ( newslot ), an ontology ( PaperOntology ), a behaviour ( ReceiveCompany ) and a new AgentComponent instance called Fritz. These changes in the running MAS are immediately visualized by all participating Client GUIs as indicated in Fig. 9. Setting permissions for AgentComponent instances. Again, besides our example we demonstrate an additional feature of the AgentComponent Tool. As the AgentComponent Tool can be split up in several Client GUIs run- ning on different machines, but working on one MAS, permissions for each AgentComponent instance can be set. Permissions can be set to HIDE (hiding the Agent- Component instance in all other AgentComponent guis), VISIBLE (make the AgentComponent instance visible in all Client GUIs but no customization can be done) and CUSTOMIZE ALL (makes the AgentComponent instance customizable in all existing Client GUIs). Fig. 10 shows two started Client GUIs, where a white-coloured name of the AgentComponent instance indicates that this Client GUI is the administrator (i.e. in this gui the permissions for the AgentComponent instances can be changed) for the AgentComponent instance. In Fig. 10 we choose Figure 10. Setting permissions for Agent- Component instances to HIDE anna in all other existing Client GUIs and

7 immediately anna disappears in the second Client GUI. 4. Related Work DESIRE [6] also describes a component-based design method for agents. In contrast to [6] we have no compositional processes and knowledge, instead we have autonomously working processes (ProcessComponents). Moreover our AgentComponent provides infrastructure services but no workflow control for the processes as proposed by [6]. The AgentComponent concept does also not focus on certain agent types like weak agents, strong agents or BDI-agents. The ProcessComponents can be implemented more or less intelligently, with beliefs, desires and intentions or only with normal task execution functionality. FIPA-OS [5] is a component-oriented multi-agentframework for constructing FIPA compliant agents using mandatory components (i.e. components required by ALL FIPA-OS Agents to execute) and optional components (i.e. components that a FIPA-OS Agent can optionally use). The mandatory parts of an FIPA-OS-Agent are the Agent class which can be extended, the TaskManager that represents the functionality of an agent, the Conversation Manager for protocol-like conversation between agents and the Message Transport Service for sending and receiving messages. ZEUS, agenttool and AGIL [15, 1, 2] are visual agent toolkits for building MAS. Each agent can be visually constructed from different components (e.g. ZEUS uses Ontologies, Tasks, organization structures to represent an agent. AGIL builds their agents from workflow activities). For these visually designed components the correspondent agent code is generated (mostly Java code) and the whole MAS is deployed on a platform. Although the design process for constructing MAS is quite elaborate supported there exists almost no runtime customization functionality as we have proposed with the Run-Design- Time concept. Only the Zeus developers have also seen the need for runtime support of MAS. In [16] they present the Visualizer Tool that consists of several tools mainly for inspecting the state, organization structure, tasks and messages of an agent (society tool, report tool, agentviewer, statistics tool). The Control Tool, that is also included in the Visualizer Tool, is supposed to customize the MAS w.r.t. the single agents during runtime but this feature is not yet supported. 5. Concluding Remarks We have shown in this paper how visual tools can help in building MAS by encapsulating the complexity of agent technology. For this purpose we have introduced additional concepts for simplifying MAS construction and we have shown a visual tool (AgentComponent Tool) based on these concepts. Using the AgentComponent Tool the MAS building process is simplyfied by visualizing the components of an agent and the generic services of each agent (see Sect. 2). Moreover the Run-Design-Time concept advances the visual construction of MAS as it provides a visual handle on the running and deployed agents. In this way running systems can be extended and customized without stopping the whole system. 6. References [1] agenttool Website. sdeloach/ai/agentool.htm. [2] AGIL Website. [3] Desmond Francis D Souza, Alan Cameron Wills. Objects, Components and Frameworks With UML. Addison Wesley, [4] Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides. Design Patterns, Elements of Reusable Object- Oriented Software. Addison-Wesley, [5] FIPA-OS Website. [6] Frances M.T. Brazier, Catholijn Jonker, Jan Treur. Principles of Component-Based Design of Intelligent Agents. Data and Knowledge Engineering, 41:1 28, [7] The JADE Programmers Guide. [8] Jaques Ferber. Multiagentensysteme, Eine Einführung. Addison Wesley, [9] M. Wooldridge and P.Ciancarini. Agent-Oriented Software Engineering: The State of the Art. Agent- Oriented Software Engineering. Springer-Verlag Lecture Notes, 1957, [10] Mark Grand. Patterns in Java. Wiley, [11] Nick R. Jennings et al. Agent-Based Business Process Management. ACM SIGMOD Record 27, pages 32 39, [12] Philipp Meier, Martin Wirsing. Implementation Patterns for Visual Construction of Multi-Agent-Systems, Technical Report. [13] Richard Krutisch, Philipp Meier, Martin Wirsing. The AgentComponent Approach, Combining Agents And Components. In Proceedings of MATES-03, Springer series of Lecture Notes on Artificial Intelligence, to appear, [14] K. Schelfthout, T. Coninx, A. Helleboogh, T. Holvoet, E. Steegmans, and D. Weyns. Agent Implementation Patterns. citeseer.nj.nec.com/schelfthout02agent.html. [15] Zeus Website. [16] The Zeus Agent Building Toolkit, The Runtime Guide.

Use and Reuse of Multi-Agent Models and Techniques in a Distributed Systems Development Framework

Use and Reuse of Multi-Agent Models and Techniques in a Distributed Systems Development Framework Agostino Poggi, Michele Tomaiuolo Dipartimento di Ingegneria dell Informazione Università degli Studi di