An approach to modelling and applying mobile agent design patterns

An Approach to Modelling and Applying Mobile Agent Design Patterns

Emerson F. A. Lima, Patrıcia D. L. Machado, Flavio R. Sampaio and Jorge C. A. FigueiredoDepartamento de Sistemas e Computacao, Universidade Federal de Campina Grande

Campina Grande, Paraıba, Brazile-mail: {emerson,patricia,ronison,abrantes}@dsc.ufcg.edu.br

Abstract

Mobile agent design patterns represent solutions to specificproblems of implementing mobile agent-based applicationsthat have evolved over time. The use of design patterns canincrease productivity, promote reuse and reduce complexitywhen developing applications. However, most of the mobileagent design patterns presented in the literature are difficultto apply in practice due to the lack of a suitable approach toidentify, document and apply them. Also, they are usuallyrelated to a specific mobile agent platform. We present anapproach for modelling and applying patterns independentlyof specific platforms along with their counterparts in specificplatforms. Also, we show that an adequate platform inde-pendent view can be constructed to be used as a guide toimplement the pattern in different platforms.

Introduction

The widespread use of the Web along with the continueddevelopment of mobile computing technology give rise to anew scenario where services are offered by applications thatcan be dynamically configured according to different userprofiles in a global and heterogeneous environment.

Mobile computing extends the conventional notion of dis-tributed computing. Devices can be moved from a networkto the other dynamically (physical mobility) and programscan interrupt their execution in a host and migrate to othersto fulfil a task (virtual mobility). The goal is to give moreflexibility to mobile users by reducing the need for keepingactive expensive and/or instable connections.

However, mobility introduces further problems: adversecommunication circumstances and resource managementconstraints. Mobile computing can be seen as the worst sce-nario in a distributed system where the environment topol-ogy is dynamic and communication and disconnection rep-resent a definite challenge [6, 4].

Mobile agents is a promising approach to developing dis-tributed applications that addresses these problems in a mo-bile computing environment. Particularly, the growing inter-est in agent technology has been motivated by its potentialuse in a number of application areas including electronic com-merce, information gathering and dissemination, telecommu-nication systems, customisable services and monitoring sys-tems [17, 10].

Nevertheless, mobile agents technology has limitations andchallenges that need to be overcome: the lack of agentsand execution environment security and the need for estab-lished methodologies of developing mobile agent-based ap-

plications.

Some approaches toward a methodology of developingmulti-agent systems focusing on patterns of interaction andcooperation have already been proposed [18]. But, mobilityhas not yet been appropriately considered, although someimportant attempts have already been made [20, 4, 3, 9, 16].The approach presented in [13] focus on modelling mobileagent systems using an extension of UML. In [9], a method-ology of developing mobile agent-based applications is intro-duced. This is based on the ideas presented by Tahara et al[20] on the designing of mobile agent-based applications byapplying design patterns according to specific architecturallevels, where, to maximise reuse, higher levels are indepen-dent of specific agent platforms.

Design patterns have been widely applied in object-oriented design since they can improve productivity, flexi-bility and reuse. Without meaningful technology patterns,applications development entails high costs. This is morecritical in the development of mobile agent-based applica-tions due to the inherited complexity of constructing suchapplications. However, most of the mobile agent design pat-terns presented in the literature are difficult to apply due tothe lack of a suitable approach to identify, document and ap-ply them. Also, they are mainly related to a specific mobileagent platform and there is a lack of substantial case studies.

Motivated by the approaches presented in [20, 9], we intro-duce an approach of modelling and applying mobile agentsdesign patterns. We present design pattern models, usingthe UML notation, at two different abstract levels: platformindependent and platform dependent. For the lack of space,only one design pattern is considered as example.

We show that modelling patterns independently of spe-cific platforms promotes their use, since platform dependentmodels can be refined from the independent ones to han-dle specific details of a given platform. Current platformspresent significant differences that justify a platform depen-dent design effort. Furthermore, we hope the ideas presentedin this paper can contribute to future development in the the-ory and practice of documenting and applying mobile agentdesign patterns to develop applications.

In the following sections, we present a methodology of de-signing mobile agent-based applications that is based on theuse of mobile agent design patterns. Then, an approach formodelling design patterns is introduced. Also, we presentan approach for applying the patterns that is illustrated bya case study. Finally, concluding remarks and pointers forfurther work are given. We assume the reader to be familiarwith basic mobile agent concepts as presented in [8, 14, 6].

1

ACM Software Engineering Notes 1 May 2004 Volume 29 Number 4ACM Software Engineering Notes 1 May 2004 Volume 29 Number 4

A Design Methodology

In this section, we introduce a methodology of designing mo-bile agent-based applications that is based on the develop-ment methodology presented in [9]. As usual, the main goalof the design discipline is to extend and refine analysis mod-els to provide a feasible solution to the system, consideringfunctional and non-functional requirements. This disciplineis divide into three sub-disciplines: platform independent ar-chitectural design, platform independent detailed design andplatform dependent detailed design (Figure 1).

...... ...Platform ADetailed Design

ArchitecturalDesign Detailed Design

Platform Independent

Detailed DesignPlatform B

Design Pattern

Catalogue

Figure 1: Mobile Agent-based Design Model.

Architectural design represents an outline of the system.The system can be decomposed into layers and/or partitions.Agent behaviour is modelled for the main scenarios accord-ing to specific architectural design patterns. Architecturalmobile agent patterns are usually classified as: mobility andtask patterns. Mobility patterns are applied when agentsperform a task while moving in a chain of agencies. The in-tention is to allow for an efficient use of network resources.Task patterns are used to specify how agents should interactin order to perform a task. In general, tasks can be dynami-cally assigned to agents. Also, a given task can be performedeither by a single agent or by a group of agents working inparallel and cooperating.

In the platform independent detailed design, a specifica-tion of a logical design independently of any specific mobileagent platform is produced. Artifacts must reflect how agentbehaviour is implemented according to the architectural pat-terns chosen and the functional and non-functional require-ments. Class diagrams are refined to include design concepts(mainly from patterns chosen) and interaction diagrams arecreated to illustrate sequences of interactions of the systemand show how operation contracts are implemented and ful-fil postconditions. Agents are usually modelled as classes.An extension of UML proposed in [13] for modelling mobileagent-based applications is used. This extension introducesnew elements to represent agencies, regions, agents, migra-tion and cloning.

In the platform dependent detailed design, the logical spec-ification produced in the platform independent design is ex-tended to address design and implementation issues relatedto a specific agent system platform. Platform dependent de-sign patterns are applied and interaction and class diagramsare refined to reflect them. Platform dependent patterns areusually categorised as: (1) refinement of patterns to include

details related to implementing them in the platform and(2) patterns related to issues such as communication, secu-rity and safety.

To support these disciplines, it is important that patternsare documented and added to a catalogue whenever they aresuccessfully modelled and implemented in a given applica-tion. Modifications and experience on the use of the patternsmust be continuously updated in the catalogue.

The division between platform dependent and indepen-dent design is motivated to promote design reuse and alsobecause mobile agent-based applications may be required torun on different platforms. Moreover, due to the complexityof implementing mobile agent-based solutions, a platform in-dependent view of the logical solution being considered canbe staple to make it possible for a global understanding andanalysis of its quality, even if only a single platform is beingconsidered [16]. Also, this can help analysing different logicalsolutions for implementing the application.

Mobile Agent Design Patterns

Mobile agent design patterns represent solutions that haveevolved over the time to problems of designing applicationsbased on the mobile agent technology. Such patterns havebeen identified, classified and documented in the literature[1, 19, 20, 5, 21, 12, 11]. However, in general, their docu-mentation and classification do not follow a standard. Somepatterns are described using natural language, whereas oth-ers are presented by UML diagrams. In [16], Petri Nets areused to model mobile agent design patterns for performancecomparison. In addition, it is usually difficult to apply themsince their purposes are not clearly stated or unnecessarily re-lated to a specific platform, even though the main ideas couldbe applied when implementing applications in different plat-forms. In [15], a preliminary catalogue of patterns, classifiedaccording to their applicability, is presented. Patterns doc-umentation includes intent, motivation, applicability, struc-ture (platform independent view), consequences, implemen-tation (platform dependent view), known uses and relatedpatterns. The main categories of patterns are: migration,task, resources, security and communication. Patterns havebeen investigated and implemented in three different agentplatforms. For the lack of space, in this paper, we focus onthe meeting pattern [1]. The master-slave pattern is alsobriefly introduced.

Meeting Pattern. Suggests a way of promoting local in-teractions between agents that are distributed in a network.Two or more agents need to migrate to an agency where themeeting takes place. In the meeting place, there is a meetingmanager responsible for controlling the process of joining andleaving the meeting. The manager is a shared resource thatkeeps a list of participants. Interactions between agents canmake execution of complex tasks possible as well as resultsoptimisation in a distributed effort to undertake a task.

Master-Slave Pattern. A master agent can create slavesthat migrate to remote hosts in order to perform a task.

2

ACM Software Engineering Notes 2 May 2004 Volume 29 Number 4

Figure 2: Meeting Pattern – Platform Independent Sequence Diagram.

When slaves come back with the results produced, the masteragent collect them to conclude the task and may decide todestroy the slaves. This pattern can be useful, for instance,when the master agent has to perform other tasks and needto be freed from the task of monitoring the agents.

Modelling Mobile Agent Patterns

We propose that the documentation of mobile agent de-sign patterns includes both platform independent and de-pendent models. According to the standard presented in[7], the structure section (graphical representation of themain classes in the pattern and possible interactions) canbe composed of platform independent models, both archi-tectural and detailed, whereas the implementation sectioncan be composed of platform dependent models that reflectimplementations issues in a given platform. These modelsare described in the sequel.

Platform Independent Models

The platform independent model presents a general struc-ture of the pattern and its abstract functionality. The goal isto precisely state the proposed solution without consideringspecific details of any agent platform. For this, only featuresof mobile agents usually supported by any platform is consid-

ered such as agent cloning and migration [8, 6]. Main classes,including agents and domain concepts, and interactions areidentified and documented. We construct UML class and se-quence diagrams, since they can represent, in a simple andabstract way, the entities involved in the pattern and theirrelationships.

To follow the description of an independent model of theMeeting Pattern, consider the sequence diagram presentedin Figure 2. Throughout this paper, we use a notation thatis equivalent to the one presented in [13]1. In this notation,an object is used to represent an entity that controls agentsexecution in a given platform2 (creation, migration) and indi-cates their location (SourceAgency and DestinationAgency).Migrations are represented by message passing, labelled asMIGRATING AGENT, from one agency entity to the other.This is requested by an agent sending the move() message.Before migrating, agent execution is interrupted (arrow la-belled as destroy()). Execution is continued in the targetagency (arrow labelled as initialize()).

From Figure 2, MeetingAgent is a mobile agent, in a sourceagency, that has a reference to a Meeting object indicatingthe place and the identification of a meeting. A referenceto a meeting object can be obtained, for instance, in agentsinitialisation or recovered from a repository. From this point,

1Some graphical features differ due to limitations of the edition tool.2This entity represents the agency, but it is not the agency itself.

3


the agent can request the target of the meeting to the Meetingobject, using the getMeetingPlace() method. Then, it canrequest to be moved (move() method) to the meeting place(DestinationAgency).

After migrating, the agent is initialised by the targetagency (initialize() method). Then, the agent calls the readymethod of its Meeting object. This object then calls theaddAgent method of the (MeetingManager) object. Thismethod is responsible for registering an agent in the spec-ified meeting controlled by the meeting manager. As a con-sequence, the manager sends to the agent a list of agentsattending in the meeting (meet method). It also notifiesthe other agents of the arrival of the agent (notifyAll andmeetWith methods). From here, the agent can interact withthe other agents by message passing. When the agent de-cides to leave the meeting, it calls the leave method of theMeeting object. The agent is then removed from the man-ager list (deleteAgent). In the scenario presented in Figure2, the agent migrates to another agency.

Figure 3 presents a class diagram illustrating the patternstructure. As mentioned, MeetingAgent is a mobile agent(MobileAgent class). This agent has a Meeting object thatkeeps a meeting location (meetingPlace) and identification(meetingID). The MeetingManager object is responsible forcontrolling the meeting by executing operations on a list ofagents kept by the arrivedAgents attribute.

Figure 3: Meeting Pattern – Class Diagram.

Platform Dependent Models

Platform dependent models refine platform independentmodels to consider specific details of implementing a pat-tern in a given agent platform. The UML extended notationis the same used on the previous section.

In order to conduct our investigation, dependent modelshave been developed based on three mobile agent based plat-forms, chosen according to the following criteria: (1) com-plete and free of charge distribution, (2) portability – run indifferent operating systems, including versions for portabledevices, (3) have JAVA as the main programming language

and (4) have complete documentation available and supportfor community discussion.

The platforms chosen are the following. Aglets [14] isbased on the idea of creating special Java applets, namedaglets, that are able to move from one machine to the other ina network. This is supported by a library named Aglets/API.A protocol named Agent Transfer Protocol (ATP) is used tosupport communication and mobility of agents from one con-text to the other. Contexts are Java Virtual Machine (JVM)abstractions.

The Grasshopper platform [11] is an agent developmentplatform, launched by IKV++, that is compliant to the firstmobile agent standard of the Object Management Group(OMG), the so-called, Mobile Agent System Interoperabil-ity Facility (MASIF) [8]. The platform is based on theJava Language and is built on top of a distributed process-ing environment to achieve interoperability between mobileagent platforms of different manufacturers and also tradi-tional client/server paradigm technology.

JADE (Java Agent DEvelopment Framework) [2] is a plat-form completely implemented in Java that simplifies the im-plementation of multi-agent systems by providing a middle-ware based in the FIPA specifications and a number of toolsto support development of applications. Recently, the virtualmachine has been extended to support execution on portabledevices allowing the use of Java Micro Edition.

The dependent models created for each platform are brieflydescribed in the sequel. Finally, the models are compared.

Aglets Model. The Aglets solution, shown partially inthe sequence diagram of Figure 4, is the simplest one dueto the existence of a package named com.ibm.agletx.patternsthat supports patterns, including the meeting pattern. Thispackage has a class named Meeting that is implemented ac-cording to the independent model presented in the previoussection. An agent has a Meeting object as attribute thatkeeps the meeting place and identification. From Figures2 and 4, it can be noticed that when an agent arrives atthe meeting place, it calls the ready method as usual. Thismethod returns an enumeration of the agents in the meet-ing. Then, the Meeting object sends a notification to theother agents in the meeting, so that they can interact withthe agent by calling the corresponding Agent Proxy.

Figure 4: Sequence Diagram of the Meeting Pattern in theAglets platform (after migrating).

Note that the MeetingManager class and the leave methodin Figure 2 are not used in the Aglets model. MeetingMan-

4


ager is an auxiliary class responsible for maintaining andsharing references to participants of a meeting. This func-tionality is directly supported in Aglets by the AgletCon-text class that it is also the entity responsible for controllingagents execution in a given instance of the platform. Usingthe facilities provided by the AgletContext class, the Meetingobject do the following (ready method): (1) broadcast a mes-sage to the agents in a context whose subject is the meetingidentifier and the content is the identifier of the recently ar-rived agent; and (2) collect the identifiers of the agents thatacknowledge the message and send an enumeration to therecently arrived agent. The leave method is not necessarysince when leaving a context, the agent automatically leavethe meeting. Finally, it is also possible to specify which par-ticipants must receive messages broadcasted to a meeting.An exception is raised if a participant is not in the meeting.

Grasshopper Model. In Grasshopper, special places canbe created to give access to an object that provides resourcesand services to agents. For this, it is necessary to create aninterface, a class that implements this interface and a config-uration file named <special place name>.properties. In oursolution, a special place named MeetingPlace has an interfaceto provide access to the MeetingManager object. This objectis a singleton, since it should only be created once, when thefirst agent arrives at a meeting. In the sequence diagrampartially shown in Figure 5, it can be noticed that when anagent arrives at the meeting agency, the Meeting object ac-cesses the special place interface and gets a reference to theMeeting Manager object. At this point, the Meeting objectcan interact with the MeetingManager to register the agent.Note that the refinement of the independent model is directand intuitive. The main difference is in the way the Meetingobject interacts with the MeetingManager object.

Figure 5: Sequence Diagram of the Meeting Pattern in theGrasshopper platform (after migrating)

JADE Model. Figure 6, presents a partial sequence di-agram of the meeting pattern in JADE. In this platform,the meet and meetWith methods of the MeetingAgent re-ceive as parameters a list of agent identifiers (AID) and thesource agent identifier respectively. This parameters differ

from the ones in the independent model since there is nodirect interaction between agents in JADE. Interactions aredone by message passing where only the identifier is nec-essary. The MeetingAgent has a Meeting object as in theindependent model. But the agent has a cyclic behaviour(CyclicBehaviour) named ReceiveMessageBehaviour that isresponsible for receiving messages. Also MeetingManager isdefined as an agent and has a behaviour named UpdateMeet-ingBehaviour that receives messages and calls the methodsresponsible for updating the meeting.

Note that JADE models have an additional feature relatedto the way agents interact with the MeetingManager object.As explained before, interactions are made by messages thatare received by behaviour objects. Behaviours are a specialfeature of JADE that can be used to define what an agenthas to do in different situations such as receiving messagesand executing specific tasks. The use of behaviours can makemodels look more complex. However, there is a considerablegain in modularity since agents can be modified by locallyaltering specific behaviours rather than the agent class. Itis also important to remark that a message target can be avector of agent identifiers, making broadcast easier.

Comparing Models

The platform independent model of the Meeting Patterngives an abstract view of its functionality, showing entitiesand their relationships and operations that must be imple-mented in general. Note that, even though dependent modelsare refinements of the independent model, there are consid-erable differences in the details presented in the dependentmodels of the platforms considered. Dependent models in-clude details that can make them unsuitable if a more ab-stract understanding is required. On the other hand, a num-ber of issues need to be considered when implementing anindependent model in a given platform and it can be verydifficult to handle them if a design approach is not followedat this level. This clearly justifies the need for independentand dependent models.

Note that MeetingAgent can be mapped directly in eachplatform. On the other hand, the Meeting and MeetingMan-ager objects require a better understanding of platforms spe-cific features. In Grasshopper and JADE, the Meeting objectcan be implemented using the interface suggested in the in-dependent model. However, in Aglets, there is a predefinedimplementation that differs from the independent model in-terface that can be easily mapped to it. The major changeis in the MeetingManager object implementation. In Aglets,this is the AgletContext. In Grasshopper, this is a single-ton accessed through a special place. And in JADE, this ismodelled as an agent.

When evaluating design models, it is important to considermeasures such as scalability, reuse and modifiability. In theMeeting pattern, scalability depends on the way the devel-oper implements the MeetingManager object. Once this ob-ject is concurrently accessed, care must be taken to avoid fail-ures and inconsistencies in managing the meeting. In Aglets,

5


Figure 6: Sequence Diagram of the Meeting Pattern in the Jade platform (after migrating)

this matter is dealt with by the platform. On the other hand,in JADE and Grasshopper, the MeetingManager is fully im-plemented by the programmer. Regarding reuse, except fromthe MeetingAgent that is implemented according to specificapplication requirements, all other entities can be reused. Asfor modifiability, the design approach adopted by the devel-oper is decisive. In other words, developers must make agood use of resources. However, the JADE behaviours canlead to modular designs that make changes easier and saferthan in the other platforms.

Applying Mobile Agent Patterns

According to the design methodology presented in this paperand the modelling approach proposed, design patterns canbe applied at different abstract levels as follows.

In the platform independent design, independent patternmodels can be combined to compose a possible solution toimplement a given application. This basically consists inmounting class diagrams by combining class templates pro-vided in the pattern documentation with classes in the appli-cation domain. Sequence diagrams are created to illustratethe scenarios based on the combination of sequences of eachpattern used. However, additional classes and interactionscan be identified. For instance, the solution may be alsobased on other paradigms such as client-server. Moreover,when facing new problems that can give rise to new patternsor variants of catalogued patterns. It is important to contin-uously document new patterns and variants in the catalogue.

At platform independent level, different combinations ofpatterns can be tried, so that the most appropriate one canbe chosen according to specific project goals such as perfor-mance. Due to the simplicity of platform independent mod-els when compared to dependent ones, it is usually more

feasible to simulate and check the behaviour of the systemand properties of interest when considering the former [16].

In the platform dependent design, the platform indepen-dent design is refined according to the corresponding depen-dent pattern models provided in the catalogue for the specificplatform chosen to implement the application. In practice,this basically consists in adding concrete classes and imple-mentation issues related to the platform.

To illustrate these ideas and a potential use of the Meetingpattern, consider an electronic-commerce application startedfrom portable devices (PDAs). Features of a given producta client wishes to acquire are specified. The specification istransformed into a number of mobile agents that can migratein the Web in the search of products that meets it. Whilethe search is pursued, the client can disconnect his deviceand/or start other applications. Such devices usually allowonly one operation at a time (mobile phones).

The use of multiple agents can maximise search resultsand reduce the time to perform it. Given the possibility ofdifferent agents visit the same places, collect redundant in-formation and collect information that meets only partiallythe client specification, it would be interesting if they couldmeet in order to exchange information and also synthesisingresults. This can avoid unnecessary traffic in the networkas well as reduce the amount of data to be delivered to theclient. These can be critical in a mobile computing environ-ment where connections are not very trusty and resources inportable mobile devices are constrained.

In the sequel, the design of the application is described.For the lack of space, only class diagrams are shown.Architectural Design. Figure 7 illustrates an archi-tecture of the proposed electronic-commerce application.Clients call for services from the domain provider. Servicesare offered based on a net of ¨market places¨ in the Internet.

To search for a product, a client, possibly disconnect, spec-

6


��

��

Internet

Market Place Market Place

Market PlaceMarket Place

Meeting Place

Agent Enabled Hosts

Create

Result

Domain Provider

Search Agents

Search Manager

Clients

Figure 7: Electronic-Commerce Application Architecture.

ify requirements such as weight, category, brand and price.Then, the resulting query is the sent to the domain providerwhere a manager agent delegates the search task to mobileagents. During the search, the client may remain disconnector performing other tasks. To perform the search task, themobile agents move from one network host to the other, ac-cording to a list of possible market places. Since each agentis independent from the other, it is possible that two agentsvisit the same place. This redundancy is important to copewith network instability and guarantee that all places willbe visit. Therefore, at the end of the search, mobile agentsmeet in a meeting host to synthesise results by applying, forinstance, predefined heuristics.

Platform Independent Design. A class diagram withthe main entities in the platform independent design is shownin Figure 8. Note that two patterns are combined: themeeting and the master-slave pattern [14]. This diagramis basically a combination of the class diagram of the meet-ing pattern presented in Figure 3, the class diagram of themaster-slave pattern and conceptual model of the application[15]. Note that Search Agent is a MeetingAgent as well as aSlaveAgent. Also, SearchManagerAgent is the master agentrunning on the Domain Provider. Finally, CollectorAgent isthe agent running on the client device that is responsible forcollecting and sending the search requirements.

Platform Dependent Design – Aglets. From Figure9, CollectorAgent and SearchManagerAgent agents must im-plement the MobilityListener interface, since they are sta-tionary. All agents extend the Aglets class. Note that theMeeting and MeetingManager classes are implemented in theplatform as explained in the previous section.

SearchResult(from Use Case View)

SearchManagerAgent<<stationary agent>>

SearchCriteria(from Use Case View)

SearchAgent<<slave mobile agent>>

1..n

PartialResult

0..n

<<stationary agent>>

CollectorAgent MeetingManagerMeeting

storeList

Figure 8: Platform Independent Class Diagram.



0..n


1..n

<<slave mobile agent>>

storeList

SearchAgent PartialResult

com.ibm.agletxpatterns.MeetingAglet<<stationary agent>>

CollectorAgent

<<interface>>

MobilityListener

Figure 9: Class Diagram in the Aglets Platform.

Platform Dependent Design - JADE. The class di-agram is shown in Figure 10. In this platform, agent func-tionality is implemented in behaviour classes. ReceiveResult-behaviour and ReceiveMessageBehaviour are responsible formessage receiving in the SearchManagerAgent and SearchA-gent respectively. The JobBehaviour is responsible for thesearch task in the SearchAgent agent. Finally, the Update-MeetingBehaviour is responsible for receiving messages fromagents that update a meeting (see Figure 6).

<<stationary agent>>

CollectorAgent



Meeting

<<slave mobile agent>>

storeList

SearchAgent0..n

PartialResult


MeetingManager

1..n

ReceiveMessageBehaviour

UpdateMeetingBehaviourJobBehaviourReceiveResultBehaviour

Figure 10: Class Diagram in the JADE Platform.

From this application, it can be noticed that the use ofdesign patterns can improve productivity and lead to a plat-form independent solution that can be implemented in dif-ferent platforms. Design patterns are key to construct mo-bile agent-based applications due to the complexity of im-plementing such applications. Moreover, its likely that anysolution relies on patterns of agent mobility, communicationand task delegation. On one hand, the platform indepen-dent design gives an abstract view of the solution to be im-plemented. On the other hand, platform dependent design

7


considers detailed issues related to Aglets and JADE. At thisstage, decisions are taken before implementation can effec-tively be started. Finally, the approach to modelling patternspresented in this paper clearly promotes their use. In our ex-ample, both independent and dependent pattern models areessential and useful guides.

Concluding remarks

The use of mobile agent technology in the development ofapplications is highly dependent on the existence of meaning-ful design patterns. This is even more critical in the mobilecomputing setting. We presented an approach to modellingand applying mobile agent design patterns at different ab-stract levels using the UML notation. Patterns have beenconsidered in three different mobile agent platforms. Weshowed that it is important to construct a platform indepen-dent model focusing on abstract features of mobile agentsand platforms. This can promote reuse of the correspondingdesign solution when implementing in different platforms.Also, logical design can proceed independently of specificplatforms. On one hand, it can be faster for an expert userin a particular platform to construct the dependent mod-els directly. However, by developing the independent modelwe get advantages such as reusability and comprehensibilityof the design. This is a realistic approach to deal with theconstantly evolving technology. Once the features of a givenplatform are known, independent models can be easily re-fined towards an implementation. It is important to remarkthat to make maintenance easier, dependent models must berefinements of the correspondent independent model.

As further work, we aim at providing tools to supportdocumentation and refinement of patterns in UML. Also, ex-tensively apply the approach to develop case studies. Fromthem, new patterns and variants can be identified. A cata-logue of patterns is under construction, presenting, togetherwith usual requirements of documenting object-oriented pat-terns, a platform independent and dependent models.

Acknowledgements This work is supported by CNPq– Brazilian Research Council, MOBILE Project (Process552190/2002-0). First author is supported by CAPES.

References

[1] Y. Aridor and D. B. Lange. Agent design patterns: Elementsof agent application design. In Proceedings of the SecondInternational Conference on Autonomous Agents, pages 108–115. ACM Press, May 1998.

[2] F. Bellifemine, G. Caire, T. Trucco, and G. Rimassa. JADEPROGRAMMER’S GUIDE. http://jade.cselt.it/docs,February 2003.

[3] G. Cabri, L. Leonardi, and F. Zambonelli. Engineeringmobile-agent applications via context-dependent coordina-tion. In Proceedings of International Conference on SoftwareEngineering - ICSE’2001, 2001.

[4] L. Cardelli. Abstractions for mobile computation. In Proceed-ings of Secure Internet Programming, volume 1603 of LectureNotes in Computer Science, 1999.

[5] D. Deugo, F. Oppacher, J. Kuester, and I. Von Otte. Pat-terns as a means for intelligent software engineering. In IC-AI-99, School of Computer Science, Carleton University, Ot-tawa, Ontario, Canada,, 1999.

[6] A. Fuggetta, G. P. Picco, and G. Vigna. Understanding codemobility. IEEE Trans. on Software Engineering, 24, 1998.

[7] E. Gamma, R. Helm, R. Johnson, and J. Vlissides. DesignPatterns: Elements of Reusable Object-Oriented Software.Addison-Wesley, 1995.

[8] The Object Management Group. The Mobile Agent SystemInteroperability Facility. The Object Management Group,Framingham, MA, 1997.

[9] F. P. Guedes, P. D. L. Machado, and V. N. Medeiros. Devel-oping mobile agent-based applications. In XXIX ConferenciaLatino Americana de Informatica - CLEI 2003, La Paz, 2003.

[10] Hayzelden and Bigham, editors. Agents for Future Commu-nication Systems. Springer, 1999.

[11] IKV++, Germany. Grasshopper Basics and Concepts.http://www.grasshopper.de.

[12] W. Jansen and T. Karygiannis. Mobile agent security. InNIST Special Publication 800-19, 1999.

[13] C. Klein, A. Rausch, M. Sihling, and Z. Wen. Extension ofthe Unified Modeling Language for mobile agents. In KengSiau and Terry Halpin, editors, Unified Modeling Language:Systems Analysis, Design and Development Issues, chapter 8,pages 116–128. Idea Publishing Group, 2001.

[14] B. D. Lang and M. Oshima. Programming and DeployingJava Mobile Agents with Aglets. Addison Wesley, 1998.

[15] E. F. A. Lima. Formalizacao e analise de padroes de projetopara agentes moveis. Master’s thesis, COPIN - Universi-dade Federal de Campina Grande, 2004. To be concluded inFebruary 2004.

[16] E. F. A. Lima, J. C. A. de Figueiredo, and D. D. S Guerrero.Using coloured petri nets to compare mobile agent designpatterns. Electronic Notes in Theoretical Computer Science,2004. Selected Papers from VI Workshop on Formal Methods- WMF’2003. To appear.

[17] D. Milojicic, F. Douglis, and R. Wheeler, editors. Mobility:process, computers and agents. ACM, 1999.

[18] J. Mylopoulos, M. Kolp, and J. Castro. Uml for agent-oriented software development: The tropos proposal. InM. Gogolla and C. Kobryn, editors, Proceedings of UML2001, volume 2185 of Lecture Notes in Computer Science,pages 422–441, 2001.

[19] A. Silva and J. Delgado. The agent pattern for mobile agentsystems. In European Conference on Pattern Languages ofProgramming and Computig, EuroPLoP’98, 1998.

[20] Y. Tahara, A. Ohsuga, and S. Honiden. Agent system de-velopment method based on agent patterns. In Proceedingsof the 21st international conference on Software engineering,pages 356–367. IEEE Computer Society Press, 1999.

[21] Yasuyuki Tahara, Nobukazu Toshiba, Akihiko Ohsuga, andShinichi Honiden. Secure and efficient mobile agent applica-tion reuse using patterns. In Proceedings of the 2001 sympo-sium on Software reusability, pages 78–85. ACM Press, 2001.

8


Documents

An approach to modelling and applying mobile agent design patterns