The Paose methodology of software engineering uses Multi Agent Systems as its main way of structuring applications. However as systems get larger and more complex, additional layers of abstraction are needed. Therefore we propose the HeRAsystem (short for HElper and Resource Agents) to structure agent systems. In this paper we introduce the main concepts of HeRA and illustrate via a small example the usage of its prototypical implementation.
Petri Nets provide a powerful formalism for modelling and implementing
distributed concurrent systems. The Paose methodology (Petri net based
Agentand Object-Oriented Software Engineering [
When developing larger Multi Agent Systems (MAS) the question needs to be answered what kind of functionality we have to assign to an agent. To ease this, here we propose to use two types of agents to implement in the system. Doing so should give some hints how they should interact in order to achieve the intended goal of the system. We have experienced that having a type of agent eases the modeling of a system.
One way to distinguish elements of an MAS is between active and passive
entities. Usually agents are considered active components. In [
The tools and materials approach (T&M) [
In the following, section 2 will give an overview over the Paose methodology and the Mulan/Capa MAS that is used in the development of the HeRAsystem. Section 3 will then go on to describe the dierent concepts used in the HeRA-system, which types of agents it consists of and how they interact with each other.
Section 4 explains these concepts by means of a simple example application built on HeRA. Finally in section 5 we draw a conclusion and give an outlook on future work. 2
Developing applications with the Paose methodology
The Paose methodology of software engineering uses reference nets [
In Mulan an MAS consists of agent platforms, which are connected with a communication infrastructure. Agents reside on platforms. A platforms manages the creation and deletion of agents and the communication between agents on a platform as well as between platforms. The behaviour of agents is determined by protocols and decision components within the agents. All these components are implemented as reference nets, interacting over synchronous channels.
A number of dierent modelling techniques are used in this approach,
describing the system from a number of dierent yet linked perspectives [
The HeRA-system now aims at further establishing an application-oriented perspective. By focussing on domain objects and supporting the users of the system, we hope to improve the usability and overall quality of software systems. 3
In order to use an MAS application, users can interact with other agents within the MAS. This is often accomplished by means of a user agent, which represents the user within the system and usually provides the user with some kind of user interface that translates his input into agent activity. If new functionality is added to the system, the user agent, too, needs to be augmented, so that the user can access it.
In dynamic distributed systems, where new functionality is added frequently,
this can be quite challenging. And if a typical user only needs a fraction of
the functionality, it is advisable to provide some kind of extension or plug-in
mechanism that allows easy integration of new functionality on demand [
Figure 1 shows the dierent types of agents and platforms in the HeRA-system. A user connects to the system using his two-part user agent. The GUI is used for user interaction, while the agent part represents the user within the MAS. The user agent is connected to a number of helper agents that provide functionality and resource agents that represent resources and documents the user can work with using his helper agents.
The conguration of helper and resource agents a user has on his agent platform represents his personal workplace. He can use helpers to communicate and exchange resources with other users within his greater work environment. Agents can also meet and interact with each other on collaboration platforms, which represent e.g. location, places or groups within the system. Service platforms host agents that provide services, like the helper factory which is used to create new helper agents. Other examples could be a workow management system or a security subsystem. The user agent consists of two parts, the GUI and the agent. The agent part is a Mulan agent that knows all the interactions necessary for handling helper agents and uses an RMI connection to communicate with the GUI part. The GUI can therefore be located on the same or on a dierent computer than the agent part.
The GUI displays to the user a list of available helper agent types in the MAS, which he can choose to request from the helper factory (see below). If a new helper agent is registered with the user agent, it sends a description of his own user interface, which can then be integrated into the user interface of the user agent. That way the generic user interface of the user agent can be enhanced in any way needed to provide the functionality of the helper agent. 3.3
In the T&M approach, users use tools to interact with materials and their environment. HeRA turns these tools into agents, who can actively support a user in their work. This is reected by the name helper agent, which emphasizes the more active role of the agent.
Helper agents are responsible for providing any kind of functionality to the user. They can provide a service all by themselves, encapsulate a legacy application, interact with other helper agents or display and manipulate resource agents. 3.4
The helper factory is an agent used for creating new helper agents. It holds a list of helper agent types which it oers to user agents to choose from. On request it gathers all the information needed for creating the new helper agent and orders the agent management system to create it. The new agent can be customized for the user, for example only including functionality that the user can access according to his user permissions. 3.5
Resource agents represent materials and resources in the work environment of a user. Instead of adding new concepts to the agent platform, resources are modelled as active components as well. A resource agent acts pretty much like an object, which can be handled by a helper agent, but it can also enforce its own rules. For example a material can decide which helper agents can access it or decide conicts in concurrent access.
Helper and resource agents need to understand the same usage patterns, it
is not possible to use a hammer to fasten a screw for example. These usage
aspects represent a m:n mapping between dierent helper and resource types.
As long as a helper understands the usage protocols of a resource, it can use
that resource. Here the work on service manuals [
To illustrate these concepts, we provide an example in the form of a simple whiteboard application. A whiteboard is a common medium used by multiple people to communicate about ideas etc. While multiple people can read the content of the whiteboard, only one person at a time can write on it.
The whiteboard itself is modelled as a resource agent. It manages the content of the board and accepts requests for changes to this content. Helper agents can register with the whiteboard material agent to receive updates on the content whenever it changes.
The whiteboard helper allows a user to use the whiteboard application. The user requests a new whiteboard helper from the helper factory, which creates the agent for him. After registration the user agent loads the GUI extension for the helper (see gure 2) and connects it to the helper agent.
Using the agent by means of the GUI extension, the user can create new whiteboards or access a list of whiteboards already existing in the system and subscribe to them. He can then edit the content of the resource agent, which results in updates to all connected helpers. In some way this supports an event driven perspective.
The whiteboard example illustrates one of the possible arrangements for the collaboration platform in Figure 1. In general resource agents should be placed on such platforms if they do not belong to a single agent. Implicitly these platforms become collaboration platforms if several agents use the resource. 5
Petri net based Multi Agent Systems can be used to structure net-based application development. In this paper we presented further structural elements within MAS by introducing the concepts of helper and resource agents. These concepts provide the possibility to design applications that are more focussed on providing functionality to individual users collaborating within a distributed system. Additionally work objects can be modelled explicitly as rst-order objects within the system.
In [
What has not been discussed here is the possibility of feeding agents with roles, goals, obligations etc. This allows for declarative style of programming which is nicely integrated due to the nature of agents. So also the use of social models that are currently discussed for the organization of agents can be applied to improve the overall architecture. Again this is inherently covered by MAS in general and hence can also be used in our helper and user agents.