A statecharts-based software development ... - Semantic Scholar

Information and Software Technology 46 (2004) 907–921 www.elsevier.com/locate/infsof

A statecharts-based software development process for mobile agents Giancarlo Fortinoa,*, Wilma Russoa, Eugenio Zimeob b

a DEIS, Universita` della Calabria, Via P. Bucci, cubo 41C, 87036 Rende (CS), Italy RCOST, Department of Engineering, Universita` del Sannio, Corso Garibaldi, Benevento, Italy

Received 5 December 2003; accepted 4 April 2004 Available online 28 May 2004

Abstract Although mobile agents and their supporting infrastructures have been extensively developed, it is still an emerging technology. A wider acceptance of mobile agents would be facilitated with the exploitation of suitable methodologies and tools which fully support their development lifecycle. This paper proposes a Statecharts-based development process for mobile agents, which allows for a seamless transition from the specification of mobile agent behaviour to its implementation and adaptation to target mobile agent systems. In particular, modelling of the mobile agent behaviour is visual and its coding is seamlessly supported by the Mobile Active Object Framework. The coded agent behaviour can be adapted to platform-specific mobile agents by means of the Mobile Agent Adaptation Framework thus enabling re-use of existing mobile agent systems. q 2004 Elsevier B.V. All rights reserved. Keywords: Statecharts; Mobile agents; Design patterns; Frameworks; Java

1. Introduction Mobile agents paradigm and technology is emerging as a powerful tool for engineering highly dynamic, reconfigurable distributed systems and applications in heterogeneous environments. The potential of mobile agents [26] has been applied in several areas of application ranging from e-commerce to network management, and from information retrieval to multimedia. Although, a host of Mobile Agent Systems (MAS) constituting a mature technological substratum which support the construction of mobile agentbased applications and systems is currently available [18], mobile agents are still under-used. Wider acceptance and exploitation of mobile agents would depend both on the secure integration of mobile agents into currently available commercial software infrastructures [15] and, notably, on the availability of methodologies and tools which fully support the mobile agent development lifecycle [28]. Recently, in the context of Agent Oriented Software Engineering (AOSE) [11,27], several high-level methodologies, design methods, and tools have been proposed for * Corresponding author. Tel.: þ 39-0984-494063; fax: þ 39-0984494713. E-mail addresses: [email protected] (G. Fortino), [email protected] (W. Russo), [email protected] (E. Zimeo). 0950-5849/$ - see front matter q 2004 Elsevier B.V. All rights reserved. doi:10.1016/j.infsof.2004.04.005

supporting the analysis, design and implementation of applications which are based on agents. Indeed although mobility is considered an additional property of an agent according to a stronger notion of agency [35], mobile agents per se differ from agents both in nature and in purposes [25]. In fact, in almost all of the currently available MAS, the programming abstractions of mobile agents more closely resemble active objects featured by mobility rather than agents capable of migration. To date, few authors have investigated software development processes which specifically address the development of mobile agents and which seamlessly cover modelling, design and implementation. This paper presents and exemplifies a Statecharts-based development process for mobile agents which allows for a seamless transition from the specification of mobile agent behaviour to its implementation and subsequent adaptation to existing MAS. In particular the proposed process addresses single-threaded mobile agents (‘lightweight mobile agents’) which are provided by the majority of the currently available MAS. It is formed by the following steps and related activities (see Fig. 1): 1.

modelling: the behaviour of a lightweight mobile agent is specified by using the Distilled StateCharts formalism [13], purposely derived from Statecharts [19],

908

G. Fortino et al. / Information and Software Technology 46 (2004) 907–921

Fig. 1. A schema of the Statecharts-based development process for mobile agents.

2.

3.

which rigorously specifies the dynamic behaviour of event-driven single-threaded software components; object-oriented design: the Distilled StateCharts-based behaviour of a lightweight mobile agent is translated into an object-oriented design by means of the Mobile Active Object (MAO) Framework providing the rules to obtain an object-oriented design which can be seamlessly translated into code; implementation: the implementation of a lightweight mobile agent is carried out by: 3.1. prototyping the object oriented design into code by using a specific implementation of the MAO Framework. In particular, Java was adopted as the target language in order to exploit the multitude of currently available Java-based MAS; 3.2. adapting the code to target Java-based MAS, which provide a well-established execution environment along with creation, coordination and migration mechanisms, by using the Mobile Agent Adaptation Framework (MAAF).

The proposed process fully supports the detailed design of a lightweight mobile agent, viewed as a component of a mobile agents-based application, along with its coding for a target platform. Thus, it can be usefully employed for driving the implementation phase of an agent-oriented software engineering methodology which also includes the following phases: enterprise modelling, domain analysis, requirement analysis, design and testing [11]. The remainder of the paper is organized as follows. Section 2 introduces the Distilled StateCharts formalism

and describes how the lightweight mobile agent behaviour is specified using a reference example. Section 3 presents the object-oriented design of a lightweight mobile agent behaviour by means of the MAO Framework. Section 4 describes the Java-based implementation of lightweight mobile agents obtained using the Java-based MAO Framework and a concrete instantiation of the MAAF for the Voyager ORB system. Section 5 analyses the proposed development process by discussing the benefits and drawbacks stemming from the exploitation of the process. Section 6 discusses related work. Finally, conclusions are drawn and directions of further work elucidated.

2. Modelling the dynamic behaviour of lightweight mobile agents Mobile agents are executing software components which can migrate within a logical network of execution environments or agent servers to fulfil a goal-oriented task. They are characterized both by reactiveness and proactiveness, i.e. they do not simply act in response to stimuli produced by their execution environment, but they are also able to exhibit goal-directed behaviour by taking the initiative [35]. The goal-directed behaviour of mobile agents is carried out through phases of computation, interaction and migration. Although numerous frameworks and programming environments [18,22,29] are available for programming the behaviour of mobile agents, few are based on welldefined executable specification languages that support


the modelling of the dynamic behaviour of mobile agents, thus enabling rapid prototyping. The Distilled StateCharts (DSC) formalism has therefore been proposed to model the dynamic behaviour of lightweight mobile agents as a set of consistent states and transitions, driven by events, to which specific actions are associated. Lightweight mobile agents are single-threaded mobile agents whose migration is transparent and can be either autonomous (i.e. triggered by the agent itself) or passive (i.e. enforced by the system or induced by other agents) [13]. A DSC specification is an executable object [20] which can be easily analysed using either a semantic framework or a simulation framework and for which the actual implementation can be seamlessly and automatically synthesized, as will be demonstrated in Section 3.

† default entrances indicate the substate of a composite state which is to be entered in absence of history; † timing and delay constraints. In order to (i) appositely specify the behaviour of eventdriven, single-threaded agents that evolve by executing a chain of atomic actions and (ii) establish the basis for the consistency of the agent state with respect to migration, the DSC were obtained by means of a distillation process of Statecharts which involved: †

†

2.1. Distilled StateCharts DSC [13] were derived from Statecharts [19], a visual formalism that gained valuable success in the Software Engineering community mainly due to their appealing graphical features and the means they offer for the modelling of complex software systems. Statecharts, formerly introduced by Harel, were included in UML [33] and currently are the most used formalism for modelling the behaviour of object systems. A statechart is a higraph consisting of rounded rectilinear blobs representing states, linked together with transitions. A state can contain preemptable activity and entry/exit actions. A typical transition can be labelled by an event, a guard (i.e. a boolean expression) and a list of atomic actions (called ‘action chain’): EVENT [GUARD ]=a1 ; a2 ; …; an : A transition fires by executing the action chain when the event which labels the transition occurs and the guard, if any, is true. Statecharts extend these basic notions, which are applicable to traditional Mealy-Moore Finite State Machines (FSMs), with the following peculiar characteristics: † OR decomposition of states in hierarchies of states. The enclosing state is called composite state and the enclosed states are called substates; † AND decomposition of states into orthogonal components which may execute concurrently and/or independently; † inter-level state transitions that can originate from or lead to nested states on any level of the hierarchy; † event propagation and broadcasting for communication and synchronization of concurrent state behaviour; † history entrances, represented by the connectors H and H* ; which allow entering the substate which was most recently visited. With respect to the composite state on which the history connector appears, H indicates that history is applied only at the level of the composite state (shallow history) whereas H* applies the same rule recursively to all levels of the state hierarchy of the composite state (deep history);

909

inheriting only the following peculiar characteristics from Statecharts: OR-decomposition, inter-level state transitions, default and history entrances; imposing the following constraints on Statecharts: – states must be empty, i.e., they do not include activity, entry and exit actions; – transitions (apart from default and history entrances) are always labelled by an event; – each composite state has a default entrance which can only be labelled by an action chain for initialisation purposes; – events can only be asynchronous; – ‘run-to-completion’ execution semantics adhere to those of the UML state machines [33]: an event can be processed only if the processing of the previous event has been fully completed.

DSC as well as Statecharts describe both internal behaviour and coordination through the asynchronous reception and generation of events. Events [13] are classified into: † †

Internal, which are sent by the agent to itself to proactively drive its activity; External, which are sent by the agent to either another agent or the agent server. External events can be further specialized in: – Local or Remote Coordination events, which are used in interactions between agents (e.g. transmission and reception of messages); – Management events, which are used for requesting services from the agent server (e.g. creation of agents).

Events are themselves entities of a DSC, and can be organized according to a generalization/specialization hierarchy. In order to enable asynchronous event signalling, the language of the actions of DSC is extended with the primitive generate (, E . (, param . )), where E is an event instance and param is the list of formal parameters of E including the event sender, the event target, and (possibly) a list of specific event parameters. An event is first created using a creation primitive offered by

910


the language of the actions, and then signalled using the primitive generate. 2.2. A DSC template for transparent migration In order to enable transparent migration of lightweight mobile agents, the DSC template (Fig. 2) was defined which is a FIPA-compliant [12] Distilled Statechart upon which the dynamic behaviour of a lightweight mobile agent should be built. In particular, the ACTIVE composite state represents the active behaviour of a mobile agent, i.e. the state in which the agent performs its computations and interactions when it is executing within an agent server. The TRANSIT state is a transitory state in which an agent remains until its migration is completed. The other states and their related transitions should be self-explanatory [12]. The Move event brings an agent from ACTIVE to TRANSIT and the Execute event returns the agent to ACTIVE . ACTIVE is always entered through the deep history entrance ðH* Þ which ensures that the agent is restored to the substate prior to migration. The Move event is Internal if generated by the agent itself for autonomous migration or External if generated by another software component (GUI, agent server or another agent) for passive migration. The constructor signature of the Move event is: Move (Id, Location), where the formal parameters represent the identifier of the event target agent and the location of the destination agent server, respectively. Every dynamic agent behaviour is forged according to the DSC template which is to be refined by introducing an Active Distilled StateChart (ADSC) within the ACTIVE state. The properties of the DSC (particularly, empty states and run-to-completion semantics) and the structure of the template assure that the execution environment of a lightweight mobile agent is reactivated exactly to the same conditions it was prior to migration. The migration, which can occur in any substate of the ACTIVE state, is therefore, transparent.

Fig. 2. The Distilled StateChart template for agent mobility.

2.3. A reference example In order to provide a pragmatic understanding of the DSC specification language, the dynamic behaviour of a lightweight mobile agent is described and is used as the reference example throughout the remainder of the paper. The ADSC of the reference example is portrayed in Fig. 3 with the state variables, events and supporting methods explained in Table 1. Java was chosen as the language for actions and guards since Java was used here as the target implementation language.

Fig. 3. The ADSC of the reference example.

G. Fortino et al. / Information and Software Technology 46 (2004) 907–921 Table 1 The state variables, events and methods of the reference example Var

Description

N

Number of requests the agent issues to the interacting agents List of agent servers to be visited List of identifiers of the interacting agents Collector of the data coming from the replying agents Identifier of the owner agent Index of the last visited agent server Number of replies received in a monitoring cycle Temporary integer variable Reference to the last received event instance

Itinerary Recipients Data Owner Next Count i e Event Step DataRequest DataReply Reply Process Request Interact Continue Report

Method Process Enough Self

Internal event pacing the DataRequests Coordination event sent by the agent to its interacting agents for requesting data Local coordination event sent by an interacting agent for replying to DataRequest Internal event indicating data gathering completion Coordination event enabling a forced processing Internal event activating a monitoring cycle Internal or coordination event bringing the agent back to its owner location Coordination event sent by the agent owner to restart the monitoring process of the agent Internal or coordination event. In the former case it drives the agent to report to its owner; in the latter the event containing reported data is sent by the agent to its owner. Specific method for processing data which returns true if the processing was successful Specific method for evaluating if there are enough data for processing Method which returns the identifier of the agent

The overall goal of the mobile agent is that of moving across a set of agent servers according to a predefined itinerary, furnished by the agent owner, for monitoring a distributed process (e.g. a measurement and control process or a distributed workflow) and finally reporting to its owner. In order to fulfil this goal the mobile agent, on each agent server to be visited, alternates between the following phases in the MONITOR state: † DATA ACQUISITION , which is performed by generating DataRequest coordination events to N local stationary agents which produce data, e.g. by sensing the physical environment or by externalising specific data of a workflow process. Once the data are collected (i.e. after the reception of all the DataReply coordination events), the Reply internal event is generated. † PROCESSING , which is performed upon reception of the Reply internal event and realized by means of the process method. It can also occur upon reception of

911

a Process coordination event if there are enough data (i.e. the guard g holds); otherwise the agent returns to the most recently abandoned substate of REQUEST . If the processing phase is successfully completed, the agent autonomously migrates to the next agent server according to its itinerary; otherwise, the monitoring process is re-executed. Finally, interaction with the owner is performed after processing the Interact event. Such an event can be generated either by the agent owner or by the agent itself after all the agent servers have been visited. The agent interacts with its owner by moving to the owner location to visualize the obtained results. The owner can thus decide either to restart the agent by optionally providing it with a new itinerary or to terminate the agent.

3. Object-oriented design A DSC-based specification of the behaviour of a lightweight mobile agent obtained from the modelling step, can be translated into a design object called MAO Behavior, from which the final code can be seamlessly obtained. The translation is based on the MAO Behavior Pattern, a specialization of the DSC Pattern, which was purposely defined for designing the state-based behaviour of lightweight mobile agents (see Ref. [14] for an extended and pattern-like presentation of both patterns). In order to facilitate the coding phase, a framework which supports the seamless generation of code was defined. In fact, frameworks, which are partially complete software systems or subsystems that are intended to be instantiated [8], are extensively used to facilitate code-writing during software development since they force both the use of well-known design patterns and the reuse of code. The defined framework, namely the MAO Framework, is a partial implementation of the MAO Behavior Pattern, and therefore it enables the reuse of both design and code during the implementation of the behaviour of lightweight mobile agents. 3.1. Design of the behaviour of lightweight mobile agents To design the behaviour of a lightweight mobile agent, its state must be encapsulated into separate classes which correspond to the states defined in the FIPA compliant DSC template (Fig. 2). The overall design is specified by the MAO Behavior Pattern, whose structure is reported in Fig. 4. MAOBehavior is a subclass of DSC. The generate method is offered to asynchronously generate event objects. MAOStateTemplate class represents the FIPA compliant DSC template, which is composed of a composite state class (MAOActiveState) and four simple state classes (MAOWaitingState, MAOSuspendedState, MAOTransitState, and MAOInitiatedState).

912


Fig. 4. Class diagram of the participants of the DSC Pattern and the MAO Behavior Pattern.

Fig. 5 illustrates a sequence diagram which shows how a MAOBehavior object is started. At creation time it receives the specific MAOActiveState object, creates the MAOStateTemplate object, and sets the current state to the start state of MAOStateTemplate (i.e. MAOInitiatedState). The constructor of MAOStateTemplate sets the parent and the behaviour references of the MAOSpecificActiveState upon which the buildSubActiveStates method is invoked to construct the complete state object tree. Since the active state of a lightweight mobile agent is modelled through a DSC specification (named ADSC in Section 2.2), its design can be supported by the DSC Pattern, which was derived from the Statecharts Pattern [37] and the State Pattern [16], as shown in the Section 3.1.1.

Fig. 5. Sequence diagram of MAOBehavior creation.


3.1.1. Designing the ADSC By using the DSC Pattern (Fig. 4), an ADSC can be translated into an object-oriented design that encapsulates the active state of an agent into separate classes in which events, guards, and actions are to be distinguished. In particular, DSC is the abstract class that holds the current state of the agent. The handler method is called when the dispatch method is invoked as a consequence of an event occurrence. The current state of DSC is updated by means of the changeState method which is invoked from the source state of a fired transition. AState is the abstract state class that encapsulates the state-driven transition mechanism, implemented in the handler method, which, on the basis of the received Event object, attempts to fire a transition. The actual state transition is performed by the changeState method. The startState method allows for entrance into a state. CompositeState is the abstract class used to collect one or more substates. Its active state is set and returned by the setActiveState and getActiveState methods, respectively. The addState method adds a new substate to the composite state, whereas the getState method returns a given substate. The getDefaultEntrance method supports the entrance in a composite state by returning its default entry state. The shallowHistory and deepHistory methods allow for entrance into the composite state using the shallow and deep history connectors H and H* ; respectively. The default entrances of H and H* are returned by the getDefaultShallowHistoryEntrance and

913

getDefaultDeepHistoryEntrance methods, respectively. In order to actually implement the state hierarchy, the following other types of states are introduced: † TopState is the composite state which contains a group of substates and has no parent. † SimpleState is contained in a composite state and does not have any substates. Event is the abstract class of every event to which the agent behaviour reacts. An instance of a subclass of Event represents a specific event which is able to trigger a transition from the current state to a new state. Actions and guards (if any) associated to transitions can be implemented by methods of an AState subclass. A DSC can be built by using instances of concrete classes which are derived from the abstract classes depicted in Fig. 4. In particular, a client first creates an instance of DSC; then, it creates a set of state classes which take a reference to DSC as a parameter for their initialisation (Fig. 6). State classes can be derived from SimpleState, CompositeState or TopState. If a CompositeState is used, the Composite Pattern [16] is exploited to build a hierarchical structure of states. Each state (Simple or Composite) is inserted in the structure by invoking the addState method of CompositeState. After the creation of a DSC, the current state can be dynamically changed as shown in Fig. 7. In particular, when a client dispatches an event (e1) to the DSC object, the dispatch method, in turn, invokes the handler of the current state. When an event

Fig. 6. Sequence diagram of DSC creation.

914


Fig. 7. Sequence diagram of DSC event handling.

(e1) cannot be handled by a state (s1) of the DSC, it is forwarded to the parent state (s2). The forwarding chain terminates at the top level composite state (s3), which is always a concrete implementation of TopState. On the other hand, when an event is processed, it can change the current state of the DSC. In fact, a new arriving event (e2) is handled by the current state (s1) that performs a state transition bringing the DSC into a new state (s4). 3.2. Seamless transition from design to implementation In order to guide the construction of a MAO Behavior and its seamless translation into code, the MAO Framework was defined on the basis of the MAO Behavior Pattern. The MAO Framework is composed of frozen spots and hot spots. The frozen spots define the overall architecture of the MAO Behavior characterized by the following classes which remain unchanged in any instantiation of the framework: MAOBehavior, MAOStateTemplate, MAOInitiatedState, MAOWaitingState, MAOSuspendedState and MAOTransitState. The hot spots are to be adapted to the needs of the MAO Behavior which is under development. To achieve adaptability and define the specific active behaviour it is necessary to subclass MAOActiveState. The framework makes it available the following classes: MAOActiveState, CompositeState, and SimpleState, which are to be extended to define the specific active state, composite states and simple states, respectively. In particular: † the introduced substate classes are to be linked to one another, using the composition association and according to their hierarchical structure;

† the state variables are to be declared in state classes at the level of the hierarchy according to their scope; † the events labelling transitions are to be defined as classes extending Event; † the action expressions and guards are to be enclosed in methods; † the transitions are to be defined inside the handler method of the specific state from which they originate. In order to exemplify how to use the MAO Framework for designing the behaviour of a lightweight mobile agent, the reference example (see Section 2.2) was translated into the design object of Fig. 8.

4. Java-based implementation The Java implementation of a lightweight mobile agent can be obtained by performing the following steps: 1. Prototyping the MAO Behavior obtained during the object-oriented design phase into Java code by using the Java-based MAO Framework; 2. Adapting the MAOBehavior class to an existing mobile agent system by using the Mobile Agent Adaptation Framework (MAAF). By following this approach, the Java implementation of the behaviour of lightweight mobile agents becomes independent of the specific mobile agent system which is used for supporting their execution, migration and interaction.


915

Fig. 8. Class diagram of the reference example.

4.1. Prototyping MAO Behaviors A MAO Behavior can be easily translated into Java code by exploiting a Java-based framework obtained through the well-defined translation of the MAO Framework into Java code. The framework provides programmers with some Java classes which are grouped in the following packages: † actiware.mao, which provides MAOBehavior and the state classes MAOActiveState, CompositeState, and SimpleState, which are to be extended to define the specific active state, composite states and simple states, respectively; † actiware.maoevent, which offers MAOEvent, which extends Event, along with its basic specialization hierarchy.

Fig. 9 shows the Java class template for implementing a specific composite state. A similar template can be used for the other state classes. 4.1.1. Hierarchical data space The hierarchical state organization allows for the seamless structuring of hierarchical data space whereby a variable is declared in the state class where it is needed (see Fig. 8). The advantage of adopting a hierarchical data space is twofold: since variables are only declared in the states where they are needed, code readability is improved and memory management can be optimised. In particular, if a state is no longer reachable, it can be trimmed along with its local variables. This reduces agent data and code size thus decreasing the latency of agent migration. Moreover, the variables can be declared in action expressions when the scope is limited to the execution of action expressions.

916


Fig. 9. Java class template for a composite state.

In order to obtain easy accessibility within the hierarchical data space, inner or nested Java classes can be used. In particular, the class implementing the specific active state of the MAO Behaviour encloses the classes of directly nested active substates, which recursively enclose the classes of their substates. Indeed, the base classes of the framework (see Fig. 4) already enable access from one state to its upper levels by means of the parentState association. 4.1.2. Implementation of transitions A transition is always embedded in the handler method of the class of its source state. An action expression and/or a guard associated to the transition can be implemented either directly in the handler or as a support method. Fig. 10 reports the programming patterns of the following kinds of transitions: 1. guarded intra-level; 2. unguarded inter-level; 3. unguarded intra-level leading to a deep history connector. 4.2. The Mobile Agent Adaptation Framework The MAAF provides the basic support which allows for the adaptation of a MAOBehavior to a mobile agent class which is made available by a specific Java-based mobile agent platform. The framework structure is portrayed in Fig. 11. The platform-dependent mobile agent class (SpecificMobileAgent) implements the IMobileAgentAdapter interface and is associated with a MAOBehavior, a MAOQueue representing the event queue of the mobile agent, and a MAOId encapsulating the high-level and the low-level mobile agent identifiers which are, respectively,

independent of and dependent on the specific mobile agent platform. IMobileAgentAdapter, MAOQueue, and MAOId are also included in the actiware.mao package. IMobileAgentAdapter declares the following methods for adapting interaction, execution and migration: † receive, which is invoked to pass MAOEvents to mobile agents. Events are inserted into the MAOQueue of the mobile agent for asynchronous processing; † generate, which interprets the MAOEvents generated within MAOBehavior and translates them into calls of platform-dependent methods. For instance, if an event is of the Asynchronous Message-based Coordination type, it is forwarded to its target mobile agent by invoking, by means of the platform-dependent primitive for remote method invocation, the receive method of the target mobile agent; moreover, if an event is of the Creation Management type, a platform-dependent mobile agent is created by means of the platform-dependent creation primitive and the MAOBehavior and MAOId instances contained in the event. † run, which is the method supporting agent execution, by cyclically extracting the next available event from the MAOQueue and dispatching it to MAOBehavior. This is called ‘event processing loop’. The agent migration is handled as follows: after the Move event has brought MAOBehavior into the Transit state, the platformdependent migration mechanism is used to actually migrate the agent; † onDeparture, which is invoked just before the migration initiates; † onArrival, which is invoked after the migration is completed and allows for the insertion of the Execute event into the head of MAOQueue.


917

Fig. 10. Transition programming patterns.

The actual implementation of these methods is carried out by the SpecificMobileAgent class which is to be purposely defined for any given mobile agent system for which its own mobile agents are to be equipped with a MAOBehavior. As an example of customisation, the definition of the SpecificMobileAgent class based on the Voyager ORB system is described in Section 4.2.1. It is worth mentioning that MAAF was also customized for the Ajanta [32], Grasshopper [17]

Fig. 11. The mobile agent adaptation framework.

and Aglets [1] mobile agent systems and is being customized for other mobile agent platforms [29]. The creation and activation dynamics (Fig. 12) of a specific mobile agent are as follows: (i)

creation of the specific MAOBehavior, MAOId and MAOQueue objects; (ii) instantiation of a SpecificMobileAgent object whose constructor takes the created MAOId, MAOBehavior and MAOQueue as parameters; the constructor passes the SpecificMobileAgent object reference to MAOBehavior (by means of

Fig. 12. Creation and activation dynamics of the MAAF.

918


Fig. 13. Interaction and event processing dynamics of the MAAF.

the setMobileAgentAdapter method) making the generate method available; (iii) invocation of the run method to start the event processing loop. The interaction and event processing dynamics (Fig. 13) are as follows. A mobile agent ma1 sends an asynchronous coordination event e1 to a known mobile agent ma2 by invoking the receive method of ma2, which then enqueues e1 in its MAOQueue. When e1 is dequeued, it is dispatched to the MAOBehavior. Upon completion of the reaction, ma2 attempts to dequeue the next available event. 4.2.1. A Voyager-based implementation Fig. 14 portrays the UML class diagram of the SpecificMobileAgent which was implemented atop the Voyager ORB system [34]. The VoyagerMobileAgent class is implemented as a mobile active object since it extends Thread and implements the IMobile interface of the Voyager API which defines the methods preDeparture, preArrival, postArrival, and postDeparture. These methods are automatically invoked, in the aforementioned order, by the source and target Voyager servers during migration of a mobile object. The generate method is implemented so as to interpret and handle asynchronous Coordination events, passive Move events, and Creation events. In particular, the generate method forwards asynchronous Coordination events and passive Move events to local and remote target agents by means of the Oneway.invoke method of the Voyager API; it creates a VoyagerMobileAgent by means of the Factory.create method to which the MAOBehavior and MAOId instances contained in the Creation event are passed as parameters. The migration dynamics (Fig. 15) specific to the VoyagerMobileAgent are as follows. After processing the Move event, the Voyager migration method moveTo(String destination) is invoked to start the migration process which takes place from the source Voyager server (VSsrc) to the target Voyager server (VStgt). Before migrating the agent, the VSsrc calls the preDeparture method which invokes onDeparture, thus stopping the event processing loop. After migration, the VStgt calls the postArrival method which invokes

onArrival. onArrival inserts an Execute event instance into the head of the event queue, updates the currentLocation and the low-level Voyagerdependent identifier of the MAOId, and starts the event processing loop.

5. An analysis of the development process The development process for mobile agents presented in this paper is characterized by the following valuable benefits: † seamless transition from modelling to implementation: it is widely recognized that an increase in the number of discontinuities between successive development phases hinders the achievement of high-level specifications. As the MAO Framework reduces the gaps between modelling and implementation of the mobile agent behaviour and the MAAF allows for a transparent adaptation to available Java-based MAS, the problems caused by such discontinuities are overcome; † visual modelling: as the worldwide adoption of UML [33] has demonstrated, visual modelling increases the productivity of designers and programmers as it facilitates application development. Applying visual modelling for implementing mobile agents is therefore expected to provide this advantage. Moreover the use of a visual language based on Statecharts, which are included in UML, reduces the learning curve for

Fig. 14. The VoyagerMobileAgent class diagram.


919

Fig. 15. Migration dynamics of the Voyager-enabled MAAF.

modelling due to the pervasive exploitation of UML in Industry and Academia. As a consequence, the specification of a DSC is extremely straightforward, as demonstrated by the reference example; † executable specifications: models, which are executable according to operational semantics, are advantageous in that they can be verified prior to their actual implementation. DSC come with well-defined operational semantics, since they inherit the semantics of the UML state machines, which facilitate the validation (formally or through simulation) of DSC models. The dynamics of an entire application composed of interacting DSC-based agents can therefore be analysed before the actual development and deployment; † re-use of the existing MAS: to date, great efforts have been and continue to be devoted to developing robust mobile agent platforms with some already gaining high popularity and commercial worth. The aim of the MAAF is also that of promoting ‘the re-use’ of well-established mobile agents infrastructures avoiding, therefore, the ex-novo implementation of new platforms. Since the proposed process centres on an applicationlevel approach for the development of mobile agents, it may introduce overhead to the target MAS. However, this drawback may be an issue only when the process is applied to mobile agents-based applications which require high performances. Indeed, this is not a significant drawback for Java-based MAS which mainly aim at providing dynamicity and flexibility rather than high performances [22]. In addition, the Statecharts-based software development process deals with lightweight mobile agents, which are single-threaded, and thus does not support the development

of multi-threaded or ‘heavyweight’ mobile agents. Indeed, very few Java-based MAS provide a heavyweight mobile agent as a basic programming abstraction [18]. Finally, since the proposed process is aimed at the development of the dynamic behaviour of mobile agents and its mapping onto target MAS, the process should be integrated into agent-oriented analysis and design methodologies in order to support the development of mobile agents-based applications.

6. Related work As previously discussed, well-defined processes specifically addressing the development of mobile agents have not been yet described in the literature. However, a rich set of related approaches, ranging from agent-oriented methodologies and patterns to Statecharts-based tools and statebased models for agent behaviour, are available. With regard to methodologies, in the framework of AOSE, several agent-oriented methodologies (e.g. MaSE, Prometheus, Tropos, Gaia) [11,36] and modelling languages such as Agent-UML [4] which support the development lifecycle of agent-based applications and multi-agent systems have been proposed. These notable efforts principally have focused on agents without addressing the typical aspects of mobile agents which not only include mobility but also lightweightness and coordination, particularly within open and heterogeneous environments such as the Internet. In particular, only Tropos and Prometheus provide specific support which is comparable with the process proposed in this work regarding the implementation of agents starting from the detailed design of their internal

920


structure. In Tropos [7], the detailed design phase involves defining the specification of agents at micro level. The capabilities and the plans of agents are described using UML activity diagrams whereas the interaction between agents are modelled using Agent-UML [4]. The implementation phase is carried out on the JACK Intelligent Agents platform [9]. In particular, several guidelines and heuristics are given for coding the detailed design diagrams into JACK agents. In Prometheus [31], the detailed design, which involves defining capabilities, internal events, plans and detailed data structure for each type of agent, is also implemented using JACK. However, in both methodologies a well-defined process supporting the transition from the detailed design to the implementation was not provided and the coding phase is too tightly-coupled with JACK. Consequently, the implementation of the detailed design specifications on agent platforms which are different from JACK is a task to be completely defined. Finally, JACK agents are stationary and not able to migrate. With regard to patterns, Aridor and Lange [3] showed several design patterns for mobile agents such as travelling, task and interaction, which are useful for engineering applications and systems based on mobile agents. A more comprehensive approach was presented in [23] which proposed a seven-layer architecture pattern for agents which specifically includes mobility. Although such pattern-driven approaches can be fruitfully applied during the design and implementation of agent-based applications and systems, they are not clearly encapsulated in a software development process. Moreover, their focus was not concerned with the specification of the dynamic behaviour of mobile agents but only on how to structure recurrent design solutions in applications based on mobile agents. Since mobile agents provided by the currently available MAS are more similar to active objects than agents per se, object-oriented methodologies and tools [2] can be exploited to support the development lifecycle of mobile agents. In particular, the Statecharts-based development tools (e.g. [21]) basically allow for the specification of an object by Statecharts and the coding of this object according to a target platform. However, such tools should be specifically enhanced to deal with mobility and applied in the context of MAS. This was the approach undertaken in this paper. To date, Statecharts have only been sparingly used to specify mobile agent behaviours and multi-agent plans [10,30]. However, they have not been employed from modelling to implementation as in the process proposed in this paper, but only as a high level modelling language. With regard to state-based models for agent behaviour, in [24] a visual tool based on Hierarchical State Machines (HSM) which allows for the specification of the behaviour of a FIPA agent and its coding for the JADE agent platform [5] was proposed. Although the tool is able to generate code from an HSM specification, it is only used for producing JADE agents and details were not given regarding the translation process. Finally, it is worth citing that

the behaviour of the mobile agents of the Bond system [6] is modelled using a multi-plane state machine which is functionally similar to Statecharts. However, hierarchy was not considered and a well-defined process seamlessly supporting Bond agents from modelling to implementation has not been reported to date.

7. Conclusions Mobile agents is an emerging technology which can find ample applications once supported by software engineering methodologies and tools which possess a formal basis, embody an appealing and well-established visual modelling language, and are able to fully support the development lifecycle of mobile agents. This paper has presented and exemplified a software development process for lightweight mobile agents. In particular, the Statecharts-based process reported here relies on a variant of the Statecharts formalism-namely the Distilled StateCharts—and related object-oriented tools. A DSC-based specification of the behaviour of a lightweight mobile agent is an executable object which lends itself to translation into code while preserving its semantics. The translation phase is seamlessly supported by the MAO Framework whose Java-based implementation allows for the construction of Java composite objects which represent the behaviours of lightweight mobile agents. Finally the MAAF facilitates the construction of Java-based lightweight mobile agents which are dependent on a specific mobile agent platform. Currently, the framework is customized for the Voyager, Ajanta, Grasshopper, and the Aglets MAS. The proposed process is distinctively characterized by the following valuable benefits: visual modelling, executable specifications, seamless modelling-to-implementation transition, and re-use of existing MAS. To the best of the authors’ knowledge, this paper is the first report of using a Statecharts centred approach which seamlessly covers the development of mobile agents from modelling to implementation. The seamless transition from the modelling of the dynamic behaviour of lightweight mobile agents to its implementation, along with its orthogonal adaptation to existing MAS, makes it possible to rapidly and automatically prototype lightweight mobile agents on heterogeneous MAS. Finally, the results obtained here establish the basis for the construction of a visual toolset based on Java and XML which is able to fully support the Statecharts-based development lifecycle of lightweight mobile agents. Efforts are currently underway to develop such a toolset which allows for: visual sketching of the dynamic behaviour of a lightweight mobile agent, translation into an intermediate XML-based representation, automatic generation of Java code, and mapping of the code onto a target MAS.


References [1] The Aglets Software Development Kit, the Aglets portal, 2003. Documentation and software available from http://aglets.sourceforge.net. [2] J. Arlow, I. Neustadt, UML and the Unified Process: Practical ObjectOriented Analysis and Design, Addison-Wesley, Reading, MA, 2001. [3] Y. Aridor, D.B. Lange, Agent Design Patterns: elements of agent application design, Proceedings of 2nd Int’l Conference on Autonomous Agents’98, 1998, pp. 108–115. [4] B. Bauer, J.P. Muller, J. Odell, Agent UML: A Formalism for Specifying Multiagent Interaction, in: B. Bauer, J.P. Muller, J. Odell (Eds.), Agent-Oriented Software Engineering, Springer, Berlin, 2001, pp. 91– 103. [5] F. Bellifemine, A. Poggi, G. Rimassa, Developing multi-agent systems with a FIPA-compliant agent framework, Software—Practice And Experience 31 (2001) 103 –128. [6] L. Boloni, D.C. Marinescu, A Multi-Plane State Machine Agent Model, Technical Report CSD-TR-99-027, Computer Science Department, Purdue University, 1999. [7] P. Bresciani, P. Giorgini, F. Giunchiglia, J. Mylopoulos, A. Perini, TROPOS: an agent-oriented software development methodology, Journal of Autonomous Agents and Multi-Agent Systems 8 (3) (2004) 203–236. [8] F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, M. Stal, Pattern-Oriented Software Architecture: A System of Patterns, vol. 1, Wiley, London, 1996. [9] P. Busetta, R. Ronnquist, A. Hodgson, A. Lucas, JACK Intelligent Agents—Components for Intelligent Agents in Java, Technical report, Agent Oriented Software Pty. Ltd, Melbourne, Australia, 1998. [10] J. Campbell, A. Esterline, Motion Planning in a Society of Mobile Agents, Proceedings of NASA-URC’98 Conference, Huntsville, AL, 1998. [11] K.H. Dam, M. Winikoff, Comparing Agent-Oriented Methodologies, Proceedings of the 5th Int’l Bi-Conference Workshop on AgentOriented Information Systems (AOIS), Melbourne, Australia, 2003. [12] FIPA Agent Management Support for Mobility Specification, DC00087C, 2002/05/10. http://www.fipa.org. [13] G. Fortino, F. Frattolillo, W. Russo, E. Zimeo, Mobile Active Objects for highly dynamic distributed computing, Proceedings of IEEE IPDPS’02, Workshop on Java for Parallel and Distributed Computing, Fort Lauderdale, FL, 2002, pp. 1– 8. [14] G. Fortino, W. Russo, E. Zimeo, A Framework for Design and Implementation of Mobile Active Objects, Proceedings of IASTED Int’l Conference on Software Engineering and Applications (SEA’03), Acta Press, Marina del Rey, CA, 2003, pp. 635 –640. [15] S. Funfrocken, How to Integrate Mobile Agents into Web Servers, Proceedings of the WETICE’97 Workshop on Collaborative Agents in Distributed Web Applications, Boston, MA (1997) 94–99. [16] E. Gamma, R. Helm, R. Johnson, J. Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software, Addison Wesley, Reading, MA, 1995. [17] Grasshopper 2, IKVþ þ Technologies AG, 2003. Documentation and software available from http://www.grasshopper.de. [18] R. Gray, D. Kotz, G. Cybenko, D. Rus, Mobile Agents: Motivations and State of the Art Systems, in: J. Bradshaw (Ed.), Handbook of Agent Technology, AAAI/MIT Press, Boston, 2004, in press.

921

[19] D. Harel, Statecharts: a visual formalism for complex systems, Science of Computer Programming 8 (1987) 231 –274. [20] D. Harel, E. Gery, Executable Object Modelling with Statecharts, IEEE Computer 30 (7) (1997) 31–42. [21] I-Logix, 2003. Documentation and software available from http:// www.ilogix.com. [22] N.M. Karnik, A.R. Tripathi, Design Issues in Mobile-Agent Programming Systems, IEEE Concurrency 6 (3) (1998) 052–061. [23] E.A. Kendall, P. Krishna, C.V. Pathak, C.B. Suresh, Patterns of Intelligent and Mobile Agents, Proceedings of the 2nd Int’l Conference on Autonomous Agents, ACM Press, New York, 1998, pp. 92 –99. [24] R. Kessler, M. Griss, B. Remick, R. Delucchi, A Hierarchical State Machine using JADE Behaviours with Animation Visualization, Proceedings of the 3rd Int’l Joint Conference on Autonomous Agents and Multi-Agent Systems (AAMAS’04), July, New York, USA, 2004. [25] D.B. Lange, Mobile Objects and Mobile Agents: the future of distributed computing?, Proceedings of the European Conference on Object Oriented Programming (ECOOP’98), Brussels, Belgium, LNCS, 1445, 1998, pp. 1–12. [26] D.B. Lange, M. Oshima, Seven good reasons for Mobile Agents, Communications of the ACM 42 (3) (1999) 88–89. [27] J. Lind, Issues in Agent-Oriented Software Engineering, Proceedings of the 1st Workshop on Agent-Oriented Software Engineering (AOSE-2000), 2000, pp. 45–58. [28] M. Luck, P. McBurney, C. Preist, Agent technology: enabling next generation computing: A roadmap for agent-based computing. AgentLink report, 2003. Available from www.agentlink.org/roadmap. [29] The Mobile Agent List. Available from http://mole.informatik. uni-stuttgart.de/mal/preview/preview.html, 2003. [30] J. Merseguer, J. Campos, E. Mena, A Performance Engineering Case Study: Software Retrieval System, in: Engineering Case Study: Software Retrieval System, in: Performance Engineering State of the Art and Current Trend, LNCS 2047, Springer-Verlag, Berlin, 2001, pp. 317 –332. [31] L. Padgham, M. Winikoff, Prometheus: a methodology for developing intelligent agents, Proceedings of the third International Workshop on Agent-Oriented Software Engineering, at the 1st Int’l Joint Conference on Autonomous Agents and Multi-Agent Systems (AAMAS’02), July, Bologna, Italy, 2002. [32] A. Tripathi, N.M. Karnik, T. Ahmed, R.D. Singh, A. Prakash, V. Kakani, M.K. Vora, M. Pathak, Design of the Ajanta system for mobile agent programming, Journal of Systems and Software 62 (2) (2002) 123–140. [33] OMG Unified Modelling Language Specification (N. formal/03-0301), v. 1.5, Mar. 2003. [34] Voyager ORB, Recursion Software Inc. Documentation and software available from http://www.recursionw.com/products/voyager/ voyager.asp, 2003. [35] M. Wooldridge, N.R. Jennings, Intelligent agents: theory and practice, Knowledge Engineering Review 10 (2) (1995) 115–152. [36] M. Wooldridge, N.R. Jennings, D. Kinny, The Gaia methodology for agent-oriented analysis and design, Journal of Autonomous Agents and Multi-Agent Systems 3 (3) (2000) 285– 312. [37] S.M. Yacoub, H.H. Ammar, A Pattern language of Statecharts, Proceedings of the 5th Annual Conference on the Pattern Languages of Programs, PLoP-98, Allerton-Park, IL, 1998.