Monitoring open multi-agent systems: An aspect-oriented programming based approach

Abstract

In Open Multi-Agent Systems (Open MAS), no central authority can control all the agents. The agents share some features like: heterogeneity, different aims and objectives, autonomy, self-interested that conflicts individual goals and limited trust. Also, agents, in Open MAS, can enter and leave a system at any time. In order to ensure that the system carries out its goals, it must be observed and controlled. For that, it is necessary to define monitoring mechanisms for: (1) understanding and analyzing the system behavior, and (2) helping developers to review and examine, at run-time, agents’ communications and other different events (agents’ lifecycle, agent requested roles, performed actions by a given agent, etc.) generated during the system execution. In this paper, an AOP-based approach for monitoring Open MAS is proposed. The proposed approach is supported by RT-MTOMAS (Real-Time Monitoring Tool for Open Multi-Agent Systems), a new tool we developed for dealing with Open MAS monitoring issues. RT-MTOMAS provides, also, a behavioral model in order to illustrate agents’ interactions. The developed tool is illustrated through a concrete case study. We outlined its integration with MaDKit agent platform.

Keywords

Open MAS AGR (agent group role)AGR-based open MAS Run-Time Monitoring AOP (Aspect Oriented Programming)MaDKit

1. Introduction

In Multi-Agent Systems (MAS), agents interact together to coordinate their behavior and often cooperate to achieve some collective goals [22]. However, in Open MAS, agents’ members are developed by different parties and serve different, often competing, interests [1, 2]. Furthermore, the internal aspects of agents, in Open MAS, are inaccessible. The only accessible information about agents is their observable behavior from the exchange of agent’s messages [40]. In addition, the behavior of an agent cannot be predicted in advance [8]. Also, complex communications between agents can change dynamically [39]. It is important, in this case, to provide techniques and tools for monitoring, analyzing and understanding Open MAS’ behaviors for both agent and system levels.

In this context, several monitoring tools have been developed. We cite among others: Agent Spotter Call Graph [9]: a profiling tool for Agent Factory platform [38]; ZEUS agent platform [18] that contains a “society tool” that visualizes the interactions between agents; JADE [13] sniffer agent that is responsible for tracking messages exchanged between agents, using a notation similar to UML Sequence Diagrams. Unfortunately, these tools suffer from some limitations when used to monitor Open MAS. Also, observing some specific features in Open MAS is not considered. For example: tracking agents that enter and leave system and tracking exchanged messages between internal and unknown agents. In the context of this work, internal agents are those who have already been launched once the system starts. However, unknown agents (i.e., heterogeneous agents) will be launched during execution (i.e., after system starts). Tracking, also, the accountability [3] which means the list of actions performed by a given agent.

In this work, we assume that an Open MAS is implemented based on an organizational model. An organization provides a way for partitioning a system, each partition (or group) constitutes a context of interaction for agents [22]. AGR (Agent/group/role) [20, 21, 30, 41] is one of the most popular and widely organizational model used in the literature. The adoption of AGR model is motivated by the fact that the implementation of internal agent structure is unspecified which strongly coincides with the concept of heterogeneity in open systems (i.e., heterogeneity at the agent level). Also, agents can enter in (and/or leave) groups and play specific roles. Groups in AGR model are considered as black boxes (i.e., heterogeneity at the group level) where what happens in a group cannot be seen from agents that do not belong to that group [41].

In this paper, we deal with the monitoring problem of AGR-based Open MAS. This choice is motivated by the fact that using monitoring oriented tools to observe the behavior of agents can avoid the risk of chaos and undesirable situations in which Open MAS may be become. For example, some exchanged messages incoming from unknown agents may affect negatively the expected system state. Hence, “openness without control may lead to chaotic behavior”, as cited in [28]. This also guarantees that agents will interact collaboratively in order to achieve their own goals and the overall system goal [7]. Several techniques may be used for software monitoring. We can cite, among others, the AOP (Aspect-Oriented Programming) [11, 17]. By definition, AOP provides a band new modularization technique by encapsulating crosscutting concerns into aspects. The most common AOP implementation for Java is AspectJ [16]. It was originally developed by Kiczales et al. at the Xerox Paolo Alto Research Center, but later contributed to the Eclipse Foundation [26]. AspectJ has been used for profiling in many research works like [4, 12, 14, 31, 37].

This study is devoted to addressing the issue of Open MAS monitoring. Also, dynamic interactions in Open MAS must be observed in order to track exchanged messages. This last can affect system behavior and an undesirable situation can take place. Similarly, actions that had been performed by an agent should be monitored in order to break agent heterogeneity and make possible such a transparency about agent lifecycle. Also, provide a support for Open MAS developers by a software tool for understanding at real time what happens in their programs in terms of agent specific properties (communication, agent’s lifecycle).

This paper extends our previous work [33], by proposing an AOP-based approach for monitoring AGR-based Open MAS. The proposed approach is supported by RT-MTOMAS (Real Time Monitoring Tool for Open Multi-Agent System), a monitoring tool based on AOP, designed especially for Open MAS AGR-based model. RT-MTOMAS provides a support for profiling Open MAS specific features discussed previously. It gives, at any time, an overview of current system state. One more feature outlined in RT-MTOMAS is the generation of Dynamic Agent Sequence Diagrams, which we call in our work RT-MTOMAS DASD.1 This last, illustrates agent conversations, which makes easy to track messages incoming and/or upcoming from unknown agents. Also, RT-MTOMAS extends MaDKit agent Platform [34] with a visualization tool that helps developers to summarize the execution context related to their MaDKit applications.

The remainder of this paper is organized as follows: Section 2 provides some related works about MAS monitoring and profiling tools; in Section 3, AGR (Agent, Group, Role) model is introduced and some related works are described; in Section 4, we discuss the MAS profiling with AspectJ as Aspect Oriented programming language; in Section 5, a general view about Monitoring AGR-based Open MAS is presented and projected on the proposed approach; in Section 6, we present RT-MTOMAS architecture; in Section 7, we give an overview of RT-MTOMAS user interface and its components; Section 8 illustrates the use of RT-MTOMAS with a concrete case study. Finally, some concluding remarks and future research directions are outlined in Section 9.

2. Literature review

In [39], a support for modeling complex, concurrent and dynamic interactions between agents in terms of conversations was proposed for open multi-agent systems. In this work, conversations can be dynamically modified in order to adapt the agent behavior to new requirements without restarting the system. Consequently, a conversation modeling support was provided at agent level and was integrated as framework into the Magentix Multi-Agent Platform (MAP) [23, 24] for defining conversations by means of interaction protocols (IPs).

In [9, 10], a MAS specific profiler is developed under AgentSpotter name. AgentSpotter offers two tools for profiling and analyzing MAS applications that are implemented under Agent Factory platform [38]. The first tool is named Agent-Oriented Call Graph that illustrates agent communications as a tree view. It is based on a very specific metric called message impact time, which indicates the impact of such message on the rest of actions performed by receiver agent. However, the main drawback of this metric is that there is no provable causal link between the receipt of messages and the execution of actions. Thus, the second tool represents an agent-oriented performance analyzer deployed under the name: space-time diagram. The most important feature of space-time diagram is the Agent timeline, which displays all the performances and communication events that occur during a profiling session. It should be noted that AgentSpotter is considered as off-line dynamic analysis tool.

In [28], an infrastructure named AMELI is devoted to support the computational realization of Electronic Institutions (EI) implemented based on ISLANDER [29]. Also, AMELI, mediates and facilitates agents’ interactions while enforcing the institutional rules. A monitoring tool that depicts all the events occurring at run-time for an EI execution, among others features, AMELI permits the distributed execution of agents. This is important as agents must be running at different places. An innovative feature of AMELI is that it is of general purpose in which any institution specification can be interpreted.

In [35], a conversion model and a prototype tool for adopting the MAS design and analysis models into standard UML models have been proposed. Also, agents are considered as high-level objects that interact with other agents by exchange messages. These methods are ad-hoc and need domain expert to make critical decisions.

In [32], a new dynamic approach for investigating empirically the effect of aspect refactoring [16] on MAS applications has been presented. It focuses, particularly, on the effect of AspectJ constructors on agent behavior in terms of communication. We used specific MAS evaluation criteria: message impact time and messages quantification. The results showed clearly that AspectJ affects negatively the communication concern in MAS by increasing the message impact time due to overhead imposed by AspectJ weaving phase. Nevertheless, this overhead is not significant. The drawback of such evaluation approach is the limited number of used AspectJ constructors (only three constructors have been used), and it focuses, only, on communication as an evaluation criterion.

Although the majority of proposed approaches outline the organizational model in Open MAS and address the communication issue in Open MAS, they did not adopt Open MAS which were designed and implemented based on AGR model. Also, the used monitoring techniques are not clearly described expect [9, 10, 28] in which Open MAS applications are profiled based on JAVA code instrumentation. To the best of our knowledge, our work is the first that profiles Open MAS applications using AOP paradigm.

3. Preliminaries

3.1 Agent-Group-Role model

The AGR model (Fig. 1) has been introduced for the first time in [20]. After that, it takes more attention in many research works, among others [22, 21, 27, 30, 41]. According to [22]: an agent is an active, communicating entity playing roles within groups. A group is used as a context for a pattern of activities. Also, a group is defined as a set of agents sharing some common characteristics. A role is the abstract representation of a functional position of an agent in a group. An agent must play a role in a group, but an agent may play several roles.

Figure 1.

Simplified UML model for AGRS [41].

Table 1 summaries some research works that deal widely with AGR model.

Table 1

Summary of many research works around AGR model

Paper	Contribution to AGR model
[20]	AGR model was introduced for the first time.
[22]	AGR model has been meta-modeled for supporting concepts relating to Organization Centered Multi-Agent System (OCMAS).
[21]	An extension of AGR model called AGRE (AGR $+$ Environment) was proposed to support the concept of environment, this latter encompasses both physical (i.e., geometrical) and social notions.
[41]	AGR model has been extended under the name: AGRS (Agent Group Role and Services) for supporting Open MASs by defining new concepts like: services and agentInRole (Fig. 1).
[30]	An adaptive organizational model based on AGR model for the analysis and design of multi-agent organizations was proposed and has been formally specified and verified using the model checker SMV.
[27]	A formal specification of AGR model is introduced based on rewriting logic.

Therefore, MaDKit (Multi-agent Development Kit) platform [34, 36], is rooted in AGR model. Also, the choice of MaDKit in our case is motivated, according to their designers: “…by the need to provide a generic, highly customizable and scalable agent platform. The goal was to build a foundation layer for various agent models, and to make the basic services fully extensible and replaceable”.

3.2 Profiling with AspectJ

AspectJ [5] is a practical aspect-oriented extension for Java programming Language. AspectJ has been proposed, mainly, for improving separation of crosscutting concerns and support improved reusability and maintainability. However, some works use it for profiling java applications, like [11].

AspectJ has demonstrated, sufficiently, a flexible integration to support java profiling. Furthermore, AspectJ defines: aspects, advices, join points, pointcuts and inter-type declarations.2 As indicated in [6, 11, 32], these constructors bring some insignificant overhead when typical aspects are used in typical java programs. Also, according to [6]: “As a percentage of the total execution time, the cost of advice is therefore insignificant in such applications”. However, around pointcut shows a significant amount of boxing and unboxing between java program, especially code that deals with communication agent primitives (sendMessage, receiveMessage, etc.), and aspects to convert arguments to the right form. To this end, AspectJ developers are strongly invited to understand the implications of using aspects on the behavior of their programs.

4. The proposed approach

In literature, a software monitor is defined as: “A software tool that executes concurrently with another program and provides detailed information about the execution of the other program” [19]. We aim in this paper to propose an AOP-based approach that deals, mainly, with AGR-based Open MAS’s features discussed previously.

The main purpose of our approach (Fig. 2) is to endow AGR-based Open MAS with a set of AspectJ aspects in order to intercept several requirements in which monitoring is made for. Therefore, AspectJ aspect will be injected in the monitored Open MAS based on a so-called weaving mechanism. This last is responsible for composing the classes and aspects [16]. In other words, Aspects and classes are woven together by AspectJ weaver.

Figure 2.

The methodology of the proposed approach.

Figure 3.

RT-MTOMAS mediation via MaDKit.

In regards to AGR related information, a profiling phase consists of gathering relevant information. Also, profiling will be done permanently as system execution go on. Our approach is supported by a software tool named RT-MTOMAS (Real Time Monitoring Tool for Open Multi-Agent System). RT-MTOMAS provides a support for reviewing and analyzing AGR-based Open MAS’s behavior. Also, RT-MTOMAS reports a summary of execution context in terms of: behavioral model that describes agents’ interactions, AGR-related events (i.e., requested/rejected roles, created/destroyed groups), exchanged AGR-based messages (i.e., sender agent, receiver agent, messages content, received and lost messages), agent performed actions (i.e., agent lifecycle). Similarly, RT-MTOMAS is dedicated, specially, for monitoring MaDKit based applications. In contrast, RT-MTOMAS can be defined as a middleware that mediates at runtime MaDKit and monitored Open MAS. Also, RT-MTOMAS is designed mainly for dealing with any agent platform that incorporates AGR model in which agents enter and leave an Open MAS (Fig. 3), request and leave groups that are dynamically created and destroyed, moving among groups, and act by performing several acts.

5. Architecture of the developed tool

The proposed approach is supported by a software tool we developed, baptized RT-MTOMAS (Real-Time Monitoring Tool for Open Multi-Agent Systems). RT-MTOMAS is a monitoring tool designed specifically for gathering and displaying relevant AGR-based Open MAS’s information. Figure 4 gives an abstract architecture that is independent to any agent platform.

Figure 4.

RT-MTOMAS architecture.

Aspect engine is a set of aspects that deal, each one, with agent-related features like: agent communication, agent lifecycle, agent actions and AGR-related information. Practically, aspect engine formulates a set of requests for intercepting calls or execution of AGR-related primitives, messaging primitives and agent lifecycle primitives. Monitoring Messaging Aspect is responsible for gathering information about MaDKit messaging like: conversationID, agentSender (Caller), agentReceiver (Called), lineCodeNumber, messageContent and methodSignature. It is also responsible for saving them in a specific data structure to calculate, thereafter, the number of sent, received and lost messages, and to display it in Agent Messaging GUI. Monitoring Agent Communications module is implemented, essentially, to generate Dynamic Agent Sequence Diagram (DASD) and gives an overview of current system state at any time.

In order to illustrate concretely the role of Monitoring Agent communications module, Table 2 summarizes, to name but a few, sendMessage MaDKit primitives for expressing message sending (one to one mode). Particularly, RT-MTOMAS instruments monitored applications for one of eleven (11) different versions of sendMessage primitive. In contrast, broadcastMessage, broadcastMessageWithRole and broadcastMessageWithRoleAndWaitFor Replies MaDKit primitives are not considered yet in the current version of RT-MTOMAS.

As well, sendMessageWithRoleAndWaitForReply has four (4) versions: (Table 2, lines 4–7). The difference between them is the timeOut argument. This last, describes a time to wait for, before getting a response from receiver. Similarly, sendMessage and sendMessageAndWaitForReply have two versions each.

Table 2

Summary of AGR-based messages in MaDKit

Prefix	Method	N ${}^{\circ}$	Signature
sendMessage	sendMessage	1	sendMessage (AgentAddress receiver, Message messageToSend)
		2	sendMessage (String community, String group, String role, Message message)
	sendMessageWithRole	3	sendMessageWithRole (String community, String group, String role, Message message, String senderRole)
	sendMessageWithRoleAnd WaitForReply	4	sendMessageWithRoleAndWaitForReply (AgentAddress receiver, Message messageToSend, String senderRole)
		5	sendMessageWithRoleAndWaitForReply (AgentAddress receiver, Message messageToSend, String senderRole, int timeOutMilliSeconds)
		6	sendMessageWithRoleAndWaitForReply (String community, String group, String role, Message messageToSend, String senderRole)
		7	sendMessageWithRoleAndWaitForReply (String community, String group, String role, Message messageToSend, String senderRole, int timeOutMilliSeconds)
	sendMessageAndWait ForReply	8	sendMessageAndWaitForReply (AgentAddress receiver, Message messageToSend)
		9	sendMessageAndWaitForReply (AgentAddress receiver, Message messageToSend, int timeOutMilliSeconds)
		10	sendMessageAndWaitForReply (String community, String group, String role, Message messageToSend)
		11	sendMessageAndWaitForReply (String community, String group, String role, Message messageToSend, int timeOutMilliSeconds)

Figure 5.

Intercepting call to sendMessageWithRoleAndWaitForReply MaDKit primitive.

Monitoring Agent’s communications module studies and tracks each sendMessage version separately. Figure 5 shows a piece of code of an aspect that intercepts calls to sendMessageWithRoleAndWaitForReply version (Table 2, N ${}^{\circ}$ 7).

Also, a particular pointcut called observeMessagingV11 (Fig. 5, line 4) intercepts calls related to sendMessageWithRoleAndWaitForReply primitive and getting, after that, related arguments: community, group, role, msgToSend, senderRole and time (Fig. 5, line 6).

After that, each agent conversation will be saved in a specific list (Fig. 5, line 12) in order to use it for, among others, drawing RT-MTOMAS DASD. This last represents the equivalent of JADE Sniffer agent [42] for MaDKit. Furthermore, our work, to the best of our knowledge, is the first that discusses the dynamic generation of behavioral model for MaDKit based on Aspect-Oriented Programming.

In the next section, we will clarify some basics of agent lifecycle in order to illustrate the role of: Monitoring Agent Lifecycle and movement modules. As indicated in FIPA specification [15], agents during their lifecycle go through different sections. Also, a MaDKit agent [34] executes, usually, three methods:

•

Activate (): this method can be seen as a constructor in the agent world. Habitually, MaDKit developers use this primitive to create groups, request some roles in a specific group. Also, all agent initialization should be done in activate () method.

•

Live (): contains all instructions that correspond to the agent’s life. Usually, live method contains an infinite loop that agent execute for waiting new messages, process the last message in mailbox or eventually reply to a message.

•

End (): contains some code which is executed when an agent is terminating (either because it finishes its behavior or because it is killed).

Thus, Monitoring Agent Lifecycle and movement module has double tasks: intercepting agent lifecycle primitives and observing entrance and/or departure of agents in/from the system respectively. For that, a specific aspect (Fig. 6) is responsible for intercepting lives’ method.

Figure 6.

Following agent movement by intercepting live method.

Moreover, a particular aspect is responsible for intercepting the launch of MaDKit. We list three possible launching methods (Fig. 7, lines 1–3): main (), new () or executeThisAgent ().

Figure 7.

Intercepting MaDKit launching.

In order to keep the maximum independence between RT-MTOMAS and monitored applications, RT-MTOMAS will be launched, concurrently, with monitored application (Fig. 7, line 5), this explains the fact that RT-MTOMAS is designed to maximize compatibility with any type of AGR-based platform.

One more feature in RT-MTOMAS is Monitoring Agent’s Actions module. Table 3 summarizes MaDKit primitives related to AGR model.

Table 3

MaDKit AGR primitives

Agent actions’ methods extracted from MaDKit Agent Class and AbstractAgent (superClass)
AGR	Agent	Group	Role
Actions	launchAgent	createGroup	requestRole
	executeThisAgent	createGroupIfAbsent	leaveRole
	killAgent	leaveGroup	bucketModeRequestRole
	getAgentWithRole	destroyGroup	destroyRole
	getAgentsWithRole	bucketModeCreateGroup
	getDistantAgentWithRole
	getExistingCommunities
	getExistingGroups
	getMyGroups
	getMyRoles
	getExistingRoles
	checkAgentAddress
	destroyCommunity
	launchXmlAgents
	Reload

Monitoring Agent Actions Aspects, Groups Aspects and Roles Aspects have a similar task for intercepting actions related to agents, groups and roles respectively. In order to elucidate how do they work, we take for example MaDKit role related primitive named: requestRole (Fig. 8) that describes an explicit request past from an agent who wants to get in system.

Also, the requestRole method returns the following values (Table 4).

Table 4

Return values for requestRole method [34]

Return value	Signification
1	Operation success;
$-$ 1	Access denied;
2	The role is already handled by this agent;
3	The group does not exist;
4	The community does not exist.

Figure 8.

MaDKit requestRole method signature.

For getting information about agents playing roles effectively. Figure 9 shows a piece of AspectJ code in which a specific pointcut (Fig. 9, line 1) is responsible for tracking requestRole calls. Thereafter, it maintains several data collectors (Fig. 9, lines 7, 12 and 16) for saving agent’s address, roles being fulfilled, rejected roles and the reason of rejection, etc.

Figure 9.

Intercepting requestRole primitive.

Figure 10 shows some AspectJ markers (mentioned with red rectangle) which explain that AspectJ advices are successfully integrated into java code.

Figure 10.

AspectJ markers.

Aspects that monitor AGR-related actions report, also, a significant information about: Total Agent Number, Included Agent Number (Agents that getting in the system), excluded Agent Number (Agents hat getting out system), number and names of accepted role per Group, number and names of rejected roles per Group (i.e., roles that have been requested in non-existing groups for example), etc. This information will be illustrated with a graphical manner using bars and pies chart Also, a statistical summary will be generated once monitored application terminated.

The last module in aspect engine package is: Aspect manager module, which is responsible for managing precedence between different parts of RT-MTOMAS in order to make such a priority and simplifying data collection.

Dynamic agent sequence diagram package implements real-time agent sequence diagram generation (i.e., drawing agents’ life lines, exchanged messages, etc.). More features of this package and, also, for RT-MTOMAS GUI will be illustrated in detail in the next section.

6. The user interface of the developed tool

RT-MTOMAS screenshots are illustrated in Fig. 11. The elements numbered 1, 2, 3 and 4 are related to: System overview, AGR relevant statistics, Agent messaging and RT-MTOMAS DASD respectively. In the following sections, we will detail the role of each one.

Figure 11.

RT-MTOMAS screenshots.

System overview (screen n ${}^{\circ}$ 1): in this screen of RT-MTOMAS, a real-time summary of AGR-related events are created. Also, relevant information is gathered such as: requested role, group names of requested roles, community name of requested group and MaDKit response to such event. More additional information about MaDKit exception handling (Table 6) will be clarified in case study section.

Additionally, a quick overview in the bottom of event list (indicated with a red rectangle in Fig. 12) shows: (i) the number of agents playing a role, (ii) the number of created groups, (iii) the number of accepted and rejected roles and (iv) the number of created and excluded groups in the community.

Figure 12.

Quick overview of accepted/rejected roles and created/excluded groups.

AGR-relevant statistics (screen n ${}^{\circ}$ 2): a bar chart, and pie chart are created and edited automatically to illustrate more details about the number and the percentage of role acceptance and rejection in each group respectively.

Agent messaging (screen n ${}^{\circ}$ 3): this screenshot shows information about agent conversations like: agent caller, agent called, conversationID, message content, MaDKit messaging primitive used and the primitive line code number, as we discussed in Section 6.

RT-MTOMAS DASD (screen n ${}^{\circ}$ 4): in RT-MTOMAS DASD, the visualization is completely interactive and can be controlled using the mouse. Possible interactions include scrolling, zooming in and out. Also, agents’ life line which has the same color are, in fact, doing roles in the same group. Messages arrows are labeled with: the conversationID (indicated with red circle in Fig. 13) concatenate with message content (indicated with red rectangle in Fig. 13).

MaDKit developers can take the conversationID and browse agent messaging table (described in the previous item), to get messages that matches with the conversationID. After that, we take primitive line number in the source code. This trick help developer for an eventual code updating or modification of some parts of code. Finally, users can save a diagram as JPEG or PNG image file.

By clicking on getCurrentSystemState button in screen n ${}^{\circ}$ 1, a statistical summary and AGR relevant information about current monitored application will be created as xml file in the application directory.

Table 5 summarizes RT-MTOMAS technical specification.

Table 5

RT-MTOMAS technical specification

Tool	Used version
MaDKit version	5.0.5.2
Eclipse	Luna release (4.4.0) Build id:20140612-0600
AJDT	Ajdt release for eclipse 44x Build id:20150610-1600
jFreeChart	1.0.13
Appropriate screen resolution	1366*768

Figure 13.

RT-MTOMAS DASD conversations.

7. Case study

In order to demonstrate the use of RT-MTOMAS as a monitoring tool for Open MAS, we study a MaDKit-based benchmark which is a simplification of the well-known “travel agency”, a simplified but mode general e-commerce example [22].

As explained in [22], when an agent enters a client group (Fig. 14), the client talks to the broker and asks for a product. The broker (the same agent that plays the two ‘brokers’ role in the client and the provider group) sends a call for proposal to providers. The proposals are presented to the client, which decides which proposal to choose (this could lead to more interactions, asking the providers to revise their proposal). Finally, a contract group is created with both the client and the chosen provider, taking the respective role of ‘Buyer’ and ‘Seller’.

Figure 14.

The organizational structure diagram of an e-commerce example [22].

Initially, we launch the application with: 3 brokers, 2 clients and 7 providers. Once a client possesses its ticket, it leaves a client group, before that, it launches 4 new client instances with launchAgent primitive. Figure 15, shows that client (5@) has sent 4 messages with sendMessage WithRoleAndWaitForReply primitive (ConversationID n ${}^{\circ}$ 28 and n ${}^{\circ}$ 25) asking broker about product named: “train”, and as this last is, already, busy by requesting provider for other products, the time out specified in sendMessageWithRoleAndWaitForReply was elapsed. Also, client (5@) has requested broker (@3) in another conversation (conversationID n ${}^{\circ}$ 30) about the same product, and as it did not have a response again, it asked the previous broker in conversationID n ${}^{\circ}$ 33.

Figure 15.

Sent, received and lost messages.

Rejected or lost messages shows clearly that providers are overloaded by processing last coming requests from clients. In other words, providers take, always, the last message, in their mailbox using purgeMailBox primitive and handle it after that. This is why some sent messages will not have answers before time out was elapsed. These conversations are qualified as lost, we count in this sample session: 67 lost messages. RT-MTOMAS DASD (Fig. 16) distinctly illustrates this scenario.

Figure 16.

Lost messages due to agents overloading.

In addition, agent under MaDKit, can be launched using two different ways. A specific agent who launches other agents when system starts, or a particular agent launch one or more agents when he wants to get out system. In the first case, all agents launched concurrently with the system are considered as internal agents. However, they are considered as unknown agents in the second case. This is why tracking agent’s conversations, according to [40], is the only way to monitor unknown agents.

Figure 17 shows that four (4) groups have been created, four green bar charts have been drawn and named successively: 201317685073549, 201311884989959, travel-providers and travel-clients, in which two groups were created initially when system starts, travel-providers and travel-clients. This means that agents: client and provider executed one of two versions of createGroup primitives, createGroup or createGroupIfAbsent (Table 3). As a consequence, MaDKit creates requested groups without any exceptions for the three first groups (201317685073549, 201311884989959, travel-providers) and reject some requesting role requests (red bar chart) in the last group (travel-clients).

Figure 17.

Number of played roles in each created group for a sample execution session.

In other words, there is no requesting groups in non-exist community. Knowing that, in AGR-based systems, a community is composed of a set of groups. Also, no requests for group creation using createGroup primitive, in which, these groups have been already created. Accordingly, MaDKit developers are invited to use createGroupIfAbsent primitive instead the simple createGroup. This avoids exceptional situations when groups were already created by other agents.

In the case of travel-clients group, we notice that there is, four rejected roles among six (i.e., 57%) and three accepted roles among six (i.e., 43%). This means that clients requesting roles are addressed to non-existent groups, secured groups or these clients are, already, handling those roles in these groups. For tracking the possible reasons of rejection in that situation, Table 6, summarizes some responses in such situation, this make a support for developers for understanding better precisely their codes.

Table 6

Some MaDKit responses for a request rejection

Return code	Exception reason
NOT_COMMUNITY	Group does not exist
NOT_GROUP	Role does not exist
NOT_ROLE	The agent is not in a group
NOT_IN_GROUP	Agent already has the requested role
ROLE_ALREADY_HANDLED	Requesting a role in a secured group fails
ACCESS_DENIED	Agent does not have a role that it is supposed to have doing a particular action, e.g.
	sendMessageWithRole
ROLE_NOT_HANDLED	Group already exists
NO_RECIPIENT_FOUND	Request Role or CreateGroup is used in activate and that the agent has been launched
	using launchAgentBucket

We remark, as well, that there are no groups named travel-broker (i.e., groups that reflects their role). However, brokers created groups named with a large number (201317685073549 and 201311884989959) which represents the contract number elaborated temporarily between client and provider. This is why contract groups contain at most two roles, one agent playing client role, and another plying provider role. It should be noted that the number of roles per group must be changed (increase or decrease) at any time. This is motivated by the fact that agents’ number who get in system by executing requestRole will be increased. However, agents getting out system by executing leaveGroup (or leaveRole) will be decreased.

RT-MTOMAS offers, in addition, the possibility to check the list of agents in a given group by clicking on “Go” button (mentioned in red rectangle in Fig. 17). Figure 18a shows that group: 185601156729792 contains two roles, each one is played with a single agent. Agent (8@831) playing provider role, and agent (5@831) plying client role. It’s possible to find in some situations different agents who playing a same role. Figure 18b shows three agents: 2@832, 4@832 and 3@832 plying a sub role of provider role, one agent (7@832) plying train-provider role (i.e., providers who offers trains), and the last one plying, also, bus-provider role.

Figure 18.

a: Role played by single agent. b: Same role played by different agents.

Once the monitoring session finished, RT-MTOMAS summarizes the system state (Fig. 19a) in terms of agent actions, created and destroyed groups in community, requested and rejected roles in each group, role state in terms of acceptance (success) or rejection (failure) in each group (Fig. 19b). The summary of monitored system is generated under and XML file by clicking on get current system state button, as mentioned in Section 7.5.

In Fig. 19a, the agent named client-5 just entered to the system by executing activate MaDKit primitive. Also, it executes createGroupIfAbsent (Fig. 19a, line 10) that means a request to MaDKit kernel to check if that group is not already created. In this case, it creates it, or executes the next action: requestRole (Fig. 19a, line 11). However, Client-10 executes, in living section (i.e., when executing live () primitive), a multiple sendMessageWithRoleAndWaitForReply primitive and wait after each one for a moment specified as argument in such primitive until it has an answer.

Figure 19.

a: Summary of agents actions. b: Created groups and role requested for each group.

Regarding RT-MTOMAS DASD, Fig. 20 illustrates agent conversations using UML sequence diagram notation. The main contribution of RT-MTOMAS DASD is mentioned, firstly, in agent life line, when the name of agent in RT-MTOMAS DASD is composed of two parts, the first one is reserved for the name of agent, and the second part concern the role played by this agent. For example: (4@863:broker) and (2@863:broker) are two agents that plying the same role broker. Secondly, messages in RT-MTOMAS DASD are labeled with conversationID concatenated with message content. The aim of this notation is to help developers for code refactoring, as indicated in Section 7.4, in the case of lost messages or message response timeout. Thirdly, RT-MTOMAS DASD will be generated dynamically and concurrently with monitored application This explains that the number of illustrated agents’ lifeline change automatically when agents get in and/or get out system. Fourth, in RT-MTOMAS DASD we opt for differentiate agents that belongs in the same group with the same color compared to agents that belong to author groups. We remark in Fig. 20 that there are several groups (agents’ lifeline with pink, green or gray color are members of the same group).

Figure 20.

RT-MTOMAS DASD.

Figure 21.

Current system state XML file.

We find, also, a single agent colored with two different colors, this means that this agent is member in two different groups and play the same role in these groups. For example, broker agent (5@867:broker) play the broker role in bus-providers group (pink color) and play the same role in clients group (green color).

In this simple MaDKit-based benchmark, a surprising result is found when observing execution context through RT-MTOMAS DASD. We find some alone agents without any conversations (agent life line with no arrow incoming neither outgoing), the case of broker agent (5@879 with pink color) in bus-provider group. Also, broker role is based, mainly, on communication between clients and providers. However, the same agent communicates normally in the group of clients (agent: 5@879 with gray color), noting that three brokers’ agents are launched initially. Alone agents without any communications are observed when a given agent play the same role in several groups (5@879 agent play broker role in both clients and providers’ groups).

Our analysis in such a situation, after a thorough verification of the RT-MTOMAS source code, confirms that this problem is coming from agent platform (MaDKit in our case). When an agent plays the same role in different groups a multiple copies of this agent are created (same agent copy per group). The other agents in the system communicate directly with the last created copy of this agent. In other words, when broker agent executes requestRole for plying broker role in clients’ group, and executes, also, requestRole for plying broker role in providers group. We observe, ideally, that clients communicate with broker agent (first agent copy) that belongs to clients’ group, and providers communicate with the same broker agent (the second copy) that belongs to providers group. However, RT-MTOMAS DSAD shows clearly that the two brokers copies are, effectively, created, the first one with pink color, and the second one with gray color. But agents that belong to clients and providers group communicate only with the second created copy of broker and the first one remains inactive. In contrast to technical specifications of MaDKit 5.0 which states that an agent who wants to communicate with another must be in the same group.

Table 7

Summary of MAS’s monitoring approaches

	Agent	Gathering	Messages	MAS	AGR-related	Runtime	Action	Profiling	Behavioral
	platform	MAS	exchange	performance	events	monitoring	performance	technique	model
		specific
		information
RT-MTOMAS	MaDKit	$\surd$	$\surd$	–	$\surd$	$\surd$	$\surd$	AOP instrumentation	Dynamic agent sequence
									diagram
AgentSpotter [9, 10]	Agent	$\surd$	$\surd$	$\surd$	–	–	$\surd$	Java instrumentation	Agent-oriented call graph
	factory
Esteva et al. [28]	JADE		$\surd$	–	–	$\surd$	$\surd$	–	–
Mani et al. [35]	–	–	$\surd$	–	–	$\surd$	–	–	UML sequence diagrams
Sniffer JADE [42]	JADE	–	$\surd$	–	–	$\surd$	–	Java instrumentation	UML sequence diagrams
Zeus toolKit [18]	ZEUS	–	$\surd$	–	–	$\surd$	$\surd$	Java instrumentation	Video tool

RT-MTOMAS DASD additional features are, in fact, inspired from AGR model. In other words, we tried, through RT-MTOMAS DASD, to create a behavioral model when AGR-related concepts were incorporated with a simplified way. Consequently, RT-MTOMAS DASD is an AGR-based version of traditional agent sequence diagram. RT-MTOMAS provides, also, a statistical summary (Fig. 21) that represents a collection of all relevant information about current system state in XML file. This last will be used, in our context, for comparing target system state with the current one during the control stage, that represents the subject of our future work.

In order to address limitations and advantages of our approach, Table 7 shows an overview of the most relevant works on MAS monitoring compared with our proposal with respect to these requirements. In particular, the environment in which MAS has been launched (Agent platform). This feature is taken into consideration because some existing agent platforms incorporate tools for monitoring, analyzing and visualizing MAS’s behavior such as: ZEUS, JADE and agent factory. With regards to the type of monitoring in which these proposals are based on, they are classified, globally, into two parts: monitoring tools that provide a way for (Gathering MAS specific information) like: exchanged messages and action performance. This last means the possibility of observing actions performed by agents (i.e., agent lifecycle) and agent entrance or departure. Also, the possibility of profiling (MAS performance) in which the amount of resources’ usage (i.e., CPU overload, memory consumption, etc.) will be calculated.

In some works, monitoring is made at runtime (Runtime Monitoring). This means that MAS specific information are gathered in the same time when monitored MAS is running. In regard to profiling techniques used for gathering relevant information, we found that most works use JAVA code instrumentation instead AspectJ profiling. Also, many tools provide a (behavioral models) expressed, generally, in terms of UML sequence diagrams for visualizing exchanged messages. Finally, we put an important feature related to AGR model (AGR-related events) which consists of reporting AGR relevant information like: roles, groups, agents that playing a given role, AGR-based messages in which agents communicate according to their roles. In other words, agent must indicate its role in the sent message (i.e., sendMessageWithRole MaDKit primitive).

In light of these comparison results described above, we can conclude that RT-MTOMAS takes a remarkable place between existing MAS monitoring tools. This is justified by the fact that RT-MTOMAS is implemented entirely based on AOP technique. Also, there is no existing MAS monitoring tools in literature that is benefit the advantages of AOP for profiling MAS specific information expect RT-MTOMAS. Similarly, RT-MTOMAS provides, exclusively, a way for MaDKit developers for monitoring their AGR-based Open MAS. In contrast, RT-MTOMAS does not take into account the issue related to Open MAS performance in which information about resources’ usage (i.e., CPU overload, memory consumption …) are collected. We believe that such information may lead to an undesirable situation during system execution and deadlock problem can take place. Similar to Mani et al. work in [35], deadlock detection in AGR-based Open MAS presents a good research axe that will be addressed in futures works.

8. Conclusion and future work

In this paper, an AOP-based approach for monitoring AGR-based Open MAS has been presented. The proposed approach is supported by a software tool called RT-MTOMAS (Real Time Monitoring tool for Open MAS). RT-MTOMAS takes its place between classic profilers by the fact that is designed, mainly, for dealing with any agent platform that incorporates AGR model. Current version of RT-MTOMAS is dedicated, particularly, for MaDKit developers. Thus, RT-MTOMAS reports a significant result about AGR-related information in terms of: monitoring agents’ communications, performed actions for a given agent, tracking agents’ lifecycle, created and destroyed groups in a running session and requested and rejected roles in a given group, etc. However, RT-MTOMAS suffers from drawbacks caused by online profiling in terms of system performance degradation: CPU overload, memory space consumption, etc. Online profiling reports a monitoring overhead. This last defines, “the amount of additional usage of resources by a monitored execution of a program compared to a normal (not monitored) execution of the program” [26]. But a serious issue can be resolved when we deal with systems subjected to time constraints, this is why we opt for the enhancement MAS performance in future works.

RT-MTOMAS DASD presented in this work extends traditional Agent sequence diagram by providing concepts related to AGR model. Agent lifeline name is extended by role name and colored in a way to identify agents that belong in the same group. However, this extension needs to be meta-modeled. An AGR-oriented sequence diagram should take into account several notions underlined in AGR model. Also, RT-MTOMAS DASD shows clearly dynamic conversations between internal and unknown agents. This allows identifying suspect communications by tracking messages in source code. Although, it’s contribution for understanding and analyzing dynamic agent behavior, it’s necessary to extend current RT-MTOMAS DASD to support concurrent threads of interaction (logical AND, inclusive OR and exclusive OR) as mentioned in [25].

Additionally, to the main reason in which AOP is come from, this work, demonstrates effectively that AOP can be used as a reliable technique for profiling and monitoring Open MAS. Also, AspectJ is mainly used for tracking and gathering AGR-related information. Based on new notions brought by AOP, we can treat the impact of accountability problem [3]. To the best of our knowledge, using AspectJ advices for intercepting AGR-based primitives is the most appropriate way.

This work represents a concretization of the first step of our previous work [33]. The second step consists of providing a support for norms-based control for Open MAS based on results provided by RT-MTOMAS.

Footnotes

For the rest of this paper we use RT-MTOMAS DASD acronym instead RT-MTOMAS Dynamic Agent Sequence Diagram.

For more explanation of these terms, the reader is invited to read the book of: Ramnivas Laddad named: AspectJ in Action: Enterprise AOP with Spring Applications.

Authors’ Bios

	Mohamed sedik Chebout is an Assistant Professor at the University of Oum El Bouaghi, Algeria. He is a member of the research team “DISE” (distributed-intelligent systems engineering) at Oum el Bouaghi University in Algeria. He received his Magister in Computer Science (artificial intelligence and image processing) in 2014 from university of Oum el Bouaghi, Algeria. Currently, he is a PhD student at the University of Oum El Bouaghi. His research is focused on software monitoring, aspect-oriented refactoring techniques for multi-agent systems.
	Farid Mokhati is a professor of Computer Science at the Department of Mathematics and Computer Science of the University of Oum El-Bouaghi in Algeria. He holds a University accreditation (Habilitation Universitaire) in Computer Science (Distributed Artificial Intelligence) awarded by BADJI Mokhtar University (Annaba) in Algeria. Currently, he is the head of ReLa(CS)2 (Research laboratory on computer science complex systems) Laboratory and the head of DISE (Distributed-Intelligent Systems Engineering) team. His main areas of interest include object and agent-oriented software engineering and formal methods.
	Mourad Badri is a full professor at the Department of Mathematics and Computer Science of the University of Quebec, Trois-Rivières, Québec, Canada. He is also the director of the Software Engineering Research Laboratory. He holds a PhD in computer science (software engineering) from the National Institute of Applied Sciences in Lyon, France. His main areas of interest include object and aspect-oriented software engineering, software quality attributes, software quality assurance, software maintenance and evolution as well as aspect mining and refactoring.
	Mohamed Chaouki Babahenini is a researcher and head of real-time rendering group at LESIA Laboratory. He is also a full professor at the Department of Computer science of the Biskra University in Algeria, where he received a Ph.D. in 2006. His current research interests are real-time rendering, 3D reconstruction, point-based rendering and data mining. He has co-authored many papers in these fields.

References

Artikis

, Dynamic specification of open agent systems, Journal of Logic and Computation 22(16) (2012), 1301–1334.

Artikis

Sergot

Pitt

Busquets

and Riveret

, Specifying and Executing Open Multi-agent Systems, In: Aldewereld

Boissier

Dignum

Noriega

Padget

, eds, Social Coordination Frameworks for Social Technical Systems, Law, Governance and Technology Series, Vol. 30, 2016, pp. 197–212.

García-Camino

Noriega

and Rodríguez-Aguilar

J.A.

, Implementing norms in electronic institutions, in: Proc. of the 4th Int. Joint Conf. on Autonomous Agents and Multi-Agent Systems, Utrecht, The Netherlands, Vol. 2, 2005, pp. 667–673.

Nusayr

and Cook

, Using AOP for detailed runtime monitoring instrumentation, in: Proceedings of the Seventh International Workshop on Dynamic Analysis (WODA), Chicago, Illinois, 2009, pp. 8–14.

AspectJ, https://www.eclipse.org/aspectj/.

Dufour

Goard

Hendren

de Moor

Sittampalam

and Verbrugge

, Measuring the Dynamic Behaviour of AspectJ Programs, in: Proceedings of the ACM Conference on Object-Oriented Programming, Systems, Languages and Applications, BC, Canada, Vol. 39, No. 110, 2004, pp. 150–169.

Felicíssimo

Chopinaud

Briot

J.-P.

Seghrouchni

A.E.F.

and Lucena

, Contextualizing normative open multi-agent systems, in: Proceedings of 23rd Annual ACM Symposium on Applied Computing (SAC 2008), Ceará, Brazil, 2008, pp. 52–59.

Hewitt

, Open information systems semantics for distributed artificial intelligence, Artificial Intelligence 47(11-3) (1991), 79–106.

Van Bien

Lillis

and Collier

R.W.

, Call Graph Profiling for Multi Agent Systems, in: Dastani

El Fallah Segrouchni

Leite

Torroni

, eds, Languages, Methodologies, and Development Tools for Multi-Agent Systems, LADS 2009, Lecture Notes in Computer Science, Vol. 6039, 2010, pp. 153–167.

10.

Van Bien

Lillis

and Collier

R.W.

, Space-Time Diagram Generation for Profiling Multi Agent Systems, in: Braubach

Briot

J.P.

Thangarajah

, eds, Programming Multi-Agent Systems, ProMAS 2009, Lecture Notes in Computer Science, Budapest, Hungary, Vol. 5919, 2010, pp. 170–184.

11.

Pearce

D.J.

Webster

Berry

and Kelly

P.H.J.

, Profiling with AspectJ, Software – Practice & Experience 37(17) (2007), 747–777.

12.

Bodden

and Havelund

, Effective race detection using AspectJ, in: Proceedings of the 2008 International Symposium on Software Testing and Analysis (ISSTA), Seattle, WA, USA, 2008, pp. 155–166.

13.

Bellifemine

Poggi

and Rimassa

, Developing Multi-agent Systems with JADE, in: Castelfranchi

Lespérance

, eds, Intelligent Agents VII Agent Theories Architectures and Languages, ATAL 2000, Lecture Notes in Computer Science, Vol. 1986, 2001, pp. 89–103.

14.

Chen

and Roşu

, Java-MOP: A Monitoring Oriented Programming Environment for Java, In: Proceedings of the 11th International Conference on Tools and Algorithms for the Construction and Analysis of Systems (TACAS), Edinburgh, U.K, 2005, pp. 546–550.

15.

FIPA, Multi-agents system standard specifications, 2002.

16.

Kiczales

Hilsdale

Hugunin

Kersten

Palm

and Grisw

W.G.

, An Overview of AspectJ, in: Knudsen

J.L.

, eds, ECOOP 2001 – Object-Oriented Programming, ECOOP 2001, Lecture Notes in Computer Science, Vol. 2072, 2001, pp. 327–354.

17.

Kiczales

Lamping

Mendhekar

Maeda

Lopes

Loingtier

J.-M.

and Irwin

, Aspect-oriented programming, in: Akşit

Matsuoka

, eds, ECOOP’97 – Object-Oriented Programming, ECOOP 1997, Lecture Notes in Computer Science, Vol. 1241, 1997, pp. 220–224.

18.

Nwana

H.S.

Ndumu

D.T.

Lee

L.C.

and Collis

J.C.

, Zeus: a toolkit for building distributed multi-agent systems, in Applied Artificial Intelligence 13(11-2) (1999), 129–185.

19.

ISO/IEC/IEEE 24765, Systems and software engineering – Vocabulary, 2010.

20.

Ferber

and Gutknecht

, A meta-model for the analysis and design of organizations in multi-agent systems, in: Proceedings of ICMAS’98, IEEE Computer Society Press, Paris, France, 1998, pp. 128–135.

21.

Ferber

Michel

and Baez-Barranco

J.-A.

, AGRE: Integrating Environments with Organizations, in: Weyns

Van Dyke Parunak

Michel

, eds, Environments for Multi-Agent Systems, E4MAS 2004, Lecture Notes in Computer Science, Vol. 3374, 2004, pp. 48–56.

22.

Ferber

Gutknecht

and Michel

, From Agents to Organizations: An Organizational View of Multi-agent Systems, in: Giorgini

Müller

J.P.

Odell

, eds, Agent-Oriented Software Engineering IV, AOSE 2003, Lecture Notes in Computer Science, Vol. 2935, 2004, pp. 214–230.

23.

Alberola

J.M.

Such

J.M.

Espinosa

Botti

and Garcia Fornes

, Magentix: a multiagent platform integrated in linux, in: Proceedings of the Sixth European Workshop on Multi-Agent Systems (EUMAS-2008), Bath, UK, 2008, pp. 1–10.

24.

Alberola

J.M.

Such

J.M.

Botti

Espinosa

and Garcia-Fornes

, A scalable multiagent platform for large systems, Computer Science and Information Systems 10(1) (2013), 51–77.

25.

Odell

Parunak

H.V.D.

and Bauer

, Extending UML for Agents, in: Wagner

Lesperance

, eds, Proceedings of the In: Kilov

Baclawski

, eds, Practical Foundations of Business System Specifications, 2003, pp. 245–270.

26.

Waller

, Performance Benchmarking of Application Monitoring Frameworks, Department of Computer Science, Kiel University, 2014.

27.

Laouadi

M.A.

Mokhati

and Seridi-Bouchelaghem

, A formal framework for organization-centered multi-agent system specification: a rewriting logic based approach, Multiagent and Grid Systems 13(14) (2017), 395–419.

28.

Esteva

Rosell

Rodriguez-Aguilar

and Arcos

, AMELI: an agent-based middleware for electronic institutions, in: Proceedings of the Third International Joint Conference on Autonomous Agents and Multiagent Systems, New York, USA, 2004, pp. 236–243.

29.

Esteva

Cruz

D.D.l.

and Sierra

, ISLANDER: an electronic institutions editor, in: Proceedings of the First International Joint Conference on Autonomous Agents and Multi-agent Systems, Bologna, Italy, 2002, pp. 1045–1052.

30.

Hoogendoorn

and Treur

, An Adaptive Multi-Agent Organization Model Based on Dynamic Role Allocation, in: International Journal of Knowledge-based and Intelligent Engineering Systems, Vol. 13, No. 13, 2009, pp. 119–139.

31.

Richters

and Gogolla

, Aspect-oriented monitoring of UML and OCL constraints, in: Proceedings of the 4th Workshop on Aspect-Oriented Modeling with UML on the 6th International Conference on the Unified Modeling Language, San Francisco, CA, USA, 2003.

32.

Chebout

M.S.

Mokhati

and Badri

, Assessing the effect of aspect refactoring on multi-agent applications: a dynamic analysis, International Journal of Agent Technologies and System 7(13) (2015), 45–66.

33.

Chebout

M.S.

Mokhati

Badri

and Babahenini

M.C.

, Towards Preventive Control for Open MAS: An Aspect-based Approach, in: Proceedings of the 13th International Conference on Informatics in Control, Automation and Robotics (ICINCO), Lisbon, Portugal, Vol. 1, 2016, pp. 269–274.

34.

MaDKit, http://mansour.saber.free.fr/termadkit/site/madkit/doc/devguide/devguide.html.

35.

Mani

Garousi

and Far

B.H.

, Monitoring Multi-Agent Systems for deadlock detection based on UML models, in: Proceedings of Canadian Conference on Electrical and Computer Engineering, 2008, pp. 1611–1616.

36.

Gutknecht

and Ferber

, MadKit: a generic multi-agent platform, in: Wagner

Rana

O.F.

, eds, Infrastructure for Agents, Multi-Agent Systems, and Scalable Multi-Agent Systems, AGENTS 2000, Lecture Notes in Computer Science, Vol. 1887, 2000.

37.

Avgustinov

Bodden

Hajiyev

Hendren

Lhoták

de Moor

Ongkingco

Sereni

Sittampalam

Tibble

and Verbaere

, Aspects for trace monitoring, in: First Combined International Workshops on Formal Approaches to Software Testing and Runtime Verification (FATES/RV), Seattle, WA, USA, 2006, pp. 20–39.

38.

Collier

, Debugging Agents in Agent Factory, in: Bordini

B.H.

Dastani

M.M.

Dix

El Fallah Seghrouchni

, eds, PROMAS 2006, Vol. 4411, 2007, pp. 229–248.

39.

Fogués

R.L.

Alberola

J.M.

Such

J.M.

and García-Fornes

, Towards dynamic agent interaction support in open multiagent systems, in: Proceedings of the 2010 Conference on Artificial Intelligence Research and Development: Proceedings of the 13th International Conference of the Catalan Association for Artificial Intelligence, Amsterdam, The Netherlands, 2010, pp. 89–98.

40.

Paes

Carvalho

Lucena

Alencar

Almeida

and Silva

, Specifying Laws in Open Multi-Agent Systems, in: Agents, Norms and Institutions for Regulated Multiagent Systems – ANIREM, 2005.

41.

Mansour

and Ferber

, Agent Groupe Rôle et Service: Un modèle organisationnel pour les systèmes multi-agents ouverts, in: Journées Francophones Des Systèmes Multi-agents, Carcassonne, France, 2007, pp. 107–116.

42.

SnifferJade, http://jade.tilab.com/documentation/tutorials-guides/sniffer/introduction/.