An integrated approach for the development and

7 downloads 0 Views 285KB Size Report
the MAS under development before its actual deployment and execution. ...... iii variables, action chains (aci), and support methods illus- trated in Figure 8 are ...
Comput Syst Sci & Eng (2005) 4: 259–271 © 2005 CRL Publishing Ltd

International Journal of

Computer Systems Science & Engineering

An integrated approach for the development and validation of multi-agent systems Giancarlo Fortino, Alfredo Garro and Wilma Russo D.E.I.S.,Università della Calabria, Via P. Bucci, cubo 41C, 87036 Rende (CS), Italy. Email: {g.fortino,a.garro,w.russo}@unical.it

In this paper, an integrated approach for the development and validation through simulation of multi-agent systems is proposed and exemplified through a case study concerning with an agent-based consumer-driven e-Marketplace. The approach centres on the instantiation of a software development process by using the method engineering paradigm. As a distinctive feature this process specifically includes a simulation phase which makes it possible the validation of a multi-agent system under development before its actual deployment and execution. In particular, the integrated approach uses the Gaia methodology for the analysis and the design, the Agent UML and the Distilled StateCharts for the detailed design, the MAO Framework for the neutral-platform implementation of software agents, and a Java-based discrete-event simulation framework for the simulation. Keywords: multi-agent systems, method engineering, event-driven simulation, Distilled StateCharts

1.

INTRODUCTION

Recently the agent-oriented approach [1] has been recognized as very suitable for the development of complex software systems. In particular: • the agent-oriented decomposition is an effective way of partitioning the problem space; • the key abstractions of the agent-oriented mindset (agents, interactions, and organizations) are a natural means of modelling; • the agent-oriented paradigm for modelling and managing organizational relationships is appropriate for dealing with existing dependencies and interactions. However, the development of complex software systems by using the agent-oriented approach requires suitable agentoriented modelling techniques and methodologies which provide explicit support for the key abstractions of the agent paradigm. Several methodologies supporting analysis, design and

vol 20 no 4 july 2005

implementation of Multi-Agent Systems (MAS) have been proposed in the context of Agent Oriented Software Engineering (AOSE) [2]. Some of the emerging methodologies are Gaia [3], MaSE [4], Prometheus [5], Tropos [6], Message [7], Passi [8], and Adelfe [9]. These notable efforts basically provide a top-down iterative approach for the modelling and the development of agent-based systems. Although, from the software development life-cycle point of view, such methodologies fully cover requirements capture, architectural design and detailed design, the implementation phase is currently not well supported [10]. In fact, it is difficult to map design models onto different target agent platforms since a seamless translation process is usually not provided. Furthermore, none of these methodologies supports validation through simulation of the MAS under development before its actual deployment and execution. Validation through simulation or through formal methods can demonstrate that a MAS correctly behaves according to its specifications. In particular, discrete-event simulators are highly required for evaluating how complex MAS work on scales much larger than those

259

G FORTINO ET AL

2.1

achievable in real testbeds [11]. Indeed, some research efforts, which have been currently devoted to defining a development process for MAS which explicitly integrates a simulation phase, do not adopt simulation for the validation of MAS as a whole but only for the validation of specific aspects such as agent coordination and interaction protocols [12–13]. This paper proposes an integrated approach for the modelling and validation through simulation of MAS. The approach centres on the instantiation of a software development process which specifically includes a simulation phase that makes it possible the validation of a MAS before its actual deployment and execution. In the proposed approach, the requirements capture is supported by a goal-oriented approach [6], the analysis and design phases are supported by the Gaia methodology [3], the detailed design phase is supported by the Agent-UML [14] and the Distilled StateCharts [15], the implementation phase is supported by the MAO Framework [15], the simulation phase is enabled by a Java-based event-driven framework [16], and the deployment phase is supported by the MAAF framework [15]. The proposed approach is exemplified by defining and validating through simulation a consumer-driven e-Marketplace model which offers mobile agent-based services for searching and buying goods. The remainder of the paper is organized as follows. In Section 2, the proposed integrated approach is presented. Section 3 describes the case study and details the work products outcoming from the development phases. In Section 4, after a brief discussion about some related work, conclusions are drawn.

2.

Requirements capture

The requirements, captured using a goal oriented approach, are reported in a Requirements Statements document which represents the work product of this phase. In particular, the requirements analysis is supported by the Tropos methodology [6] and is structured in the following steps: 1. Identification of the stakeholders and their intentions (goals). Stakeholders are modelled as social actors specifying the dependencies existing among them in relation to the goals to be achieved, the plans to be performed and the resources to be furnished (Early Requirements analysis); 2. Extension of the conceptual model defined in the Early Requirements analysis step by including a new actor, representing the system, and a number of dependencies with other actors which are part of the environment. These dependencies define all the functional and non-functional requirements of the system to be developed (Late Requirements analysis).

2.2

Analysis

The analysis phase, which is aimed at developing an understanding of the system and its organization, is supported by the Gaia methodology [3]. Gaia can be thought of as a process of incremental development of detailed models of the system to be constructed. Therefore, in each phase, Gaia produces as work products one or more models that will be refined in the successive phase. The work products of the analysis phase are the Prototypical Roles Model, the Interactions Model and the Roles Model; these models are obtained in the following steps:

AN INTEGRATED APPROACH FOR THE MODELLING AND SIMULATION OF MULTI AGENT SYSTEMS

1. Identification of the roles in the system to build a list of the key roles that occur in the system, each of them with an informal, unelaborated description (Prototypical Roles Model); 2. Identification and documentation of the protocols associated with each role to capture the recurring patterns of inter-role interactions (Interactions Model); 3. Full elaboration of the roles in the Prototypical Roles Model on the basis of the Interactions Model (Roles Model). The Roles Model documents the Roles occurring in the system, their Responsibilities and Permissions, and the Protocols and Activities in which they participate. Responsibilities are the key properties associated with a role and are divided into two types: (i) Liveness Properties which describe those

The approach centres on the instantiation of the process, shown in Figure 1 using the SPEM notation [17–18], which completely covers the development of MAS from requirements capture to deployment. An instance of the process can be obtained, according to the method engineering paradigm [19], by exploiting in each phase a methodology or a methodology fragment (method fragments) chosen from agent-oriented methodologies proposed in the literature [3–9] or defined ad-hoc. In the following, the proposed approach is illustrated by describing each phase along with the adopted methodology and the traceability among the phases.

Simulation Work Products

Requirements Statement

Requirements Capture

Analysis

Analysis Work products

Design

Design Work Products

Detailed Design

Detailed Design Work Products

Implementation Work Products

Implementation

Simulation

Deployment Work Products

Deployment

Figure 1 The reference development process

260

computer systems science & engineering

AN INTEGRATED APPROACH FOR THE DEVELOPMENT AND VALIDATION OF MULTI-AGENT SYSTEMS

states of affairs that an agent must bring about, given certain environmental conditions; (ii) Safety Properties which are invariants and state that an acceptable state of affairs is maintained throughout all the states of execution. Permissions are the rights associated with a role and identify the resources that are available to that role in order to fulfil its responsibilities. Protocols define how a role can interact with other roles. Finally, Activities of a role are computations associated with the role that may be carried out by the agent without interacting with other agents.

2.3

Implementation

The aim of the implementation phase is to obtain the code of the agent behaviours from the Agent Behaviors Model. This code, which represents the work product of this phase, can be used both in the simulation phase and in the deployment phase. The implementation phase is supported by the Mobile Active Object (MAO) Framework [16] by which a DSC specification can be seamlessly translated into a composite object (called MAOBehavior object) representing an agent behaviour and into a set of event objects (or simply Events) representing interactions. The MAO Framework is currently implemented in Java.

Design

The aim of the design phase is to transform the analysis models into a design which is concerned with the cooperation of agents in a society and the services offered by each individual agent to achieve the system-level goals. The work products of this phase, which is also supported by the Gaia methodology, are the Agent Model, the Services Model and the Acquaintance Model. This phase is structured in three main steps: 1. Aggregation of roles into Agent Types, definition of an agent type hierarchy, and establishment of how many agent instances could be instantiated for each type (Agent Model). 2. Identification of the main Services that are required to realize each role by examining Activities, Protocols, and Liveness and Safety Properties of the role. Inputs, outputs, pre-conditions, and post-conditions are to be identified for each service (Services Model). 3. Documentation of the relationships of communication between the agent types (Acquaintance Model). The Acquaintance Model does not define what messages are sent or when messages are sent, as it only indicates the existence of communication pathways.

2.4

2.5

Detailed design

The objective of this phase is to obtain a detailed specification, seamlessly translatable into code, of the behaviours of the Agent Types which have been defined in the Agent Model. The work products of this phase are the Agent Interactions Model and the Agent Behaviors Model. This phase is carried out by means of: 1. Agent-UML interaction diagrams [14] to thoroughly specify the patterns of interaction between the Agent Types of the Agent Model (Agent Interactions Model); 2. The Distilled StateCharts (DSC) formalism [16] to specify the dynamic (proactive, active and reactive) behaviour of each Agent Type (Agent Behaviors Model) on the basis of the Agent Interactions Model and the work products of the design phase. DSC were derived from Statecharts [20] and allow for the modelling of the behaviour of lightweight agents, i.e. event-driven, single-threaded, capable of transparent migration, and executing chains of atomic actions. A DSC specification of an agent is done according to the template of a FIPA agent [21]. vol 20 no 4 july 2005

2.6

Simulation

The goal of the simulation phase is the validation of the MAS which is under development before its actual deployment. This phase can provide, as work product, both qualitative and quantitative information about correctness and efficiency. This information can then be exploited for reformulating, modifying and/or refining some choices of the previous phases of the development process. The simulation phase is supported by a Java-based, discrete-event simulation framework for stationary and mobile agents [16]. On the basis of this framework, a complex agent-based system can be easily validated and evaluated by implementing a simulator program. The simulation framework only provides a trace file which contains the history of the timed events generated and received by the agents; the analysis of the trace file can be used to validate the correctness of the agent interactions and behaviours. Hence, any application-specific test case along with related performance measurements can be programmed ad-hoc. It is worth noting that the simulation phase is not meant to completely substitute the testing phase but to facilitate it since testing must nonetheless be carried out by applying the defined test cases (or a part of them) to the deployed and running system. The simulation engine of the framework allows for: (i) the execution of agents by interleaving their event processing, (ii) the exchange of events among agents, (iii) the migration of agents, and (iv) the clustering of agents into agent servers which are connected by a logical network. The basic simulation entities offered by the framework are: • the AgentServer, which is an object representing the agent server hosting mobile and stationary agents; • the Agent, which is an object representing either a stationary agent or a mobile agent, including a pair of objects: , where MAOId is the agent identifier and MAOBehavior incorporates the dynamic behaviour of an agent type obtained in the implementation phase; • the MAOEvent, which represents an event object; • the VirtualNetwork, which represents the logical network of hosts on which an AgentServer is mapped; • the UserAgent, which is an object representing a user. A UserAgent is directly connected to an AgentServer and can create, launch and interact with Agents; • the UserAgentGenerator, which is an object modelling the arrival process of new UserAgents. In particular, the UserAgentGenerator is able to create and start UserAgents 261

G FORTINO ET AL

Acquaintance Model

Prototypical Roles Model

Agent Interactions Model

Roles Model

Requirements Statement

Services Model

Agent Classes

Interactions Model

Analisys

- Trace File - Analysis Parameters

Agent Behaviors Model

Agent Model Requirements Capture

Simulator Program

Detailed design

Design

Implementation

Simulation

Figure 2 Dependencies among work products

according to a given statistical distribution. A simulator program can be constructed according to the following steps: 1. creation of the VirtualNetwork object which is constructed as a set of server nodes completely connected through network links; 2. creation of the AgentServer objects and mapping of these objects onto distinct server nodes of the VirtualNetwork object; 3. creation of the UserAgent object, which can, in turn, dynamically create specific Agent objects at run-time. The UserAgent object can be bounded to one or more AgentServer objects through network links. The creation of UserAgent objects can be made automatic by creating a UserAgentGenerator object for each type of UserAgent object; 4. creation of the stationary Agent objects and mapping of these objects onto the specific AgentServer objects to which the UserAgent object is bound; 5. creation of Invoke events (i.e. the events needed to start the behaviour of an Agent object) directed to the created UserAgent and Agent objects, and insertion of such events into the event queue of the simulation engine; 6. initialisation of the discrete-event clock and start of the simulation engine.

2.7

Deployment

Prior to deployment and execution, the agent classes should be adapted to the target agent platform. The adaptation is carried out by means of customisation of the Mobile Agent Adaptation Framework (MAAF) [15] for a given agent platform. In particular, the MAAF provides the basic support which allows for the adaptation of a MAOBehavior object to a mobile agent class which is made available by a specific Java-based agent platform. In [15] the customisation for the Voyager ORB system is reported. It is worth mentioning that the MAAF has been also customized for the Ajanta, Grasshopper, and the Aglets agent systems and is being customized for other agent platforms.

2.8

Traceability between work products

The work products produced in a given phase might constitute the input for the subsequent phase provided that they 262

contain all the information required for initialising it. If two subsequent phases (P1 and P2) are carried out by using method fragments coming from different methodologies, it is required to elaborate the work products of phase P1 to obtain the information needed to drive the construction of the work products of phase P2. For instance, the work products of the design phase, supported by the Gaia design method fragments, must be elaborated to extract the information for constructing subsequent models of the detailed design phase, supported by the Agent-UML and the Distilled StateCharts. Figure 2 illustrates the inter-dependencies among the work products produced from the Requirements Capture to the Simulation.

3.

A CASE STUDY: AN AGENT-BASED, CONSUMER-DRIVEN ELECTRONIC MARKETPLACE

3.1

Requirements of a consumer-driven e-Marketplace

An e-Marketplace is an e-commerce environment which offers new channels and business models for buyers and sellers to effectively and efficiently trade goods and services over the Internet [22]. A consumer-driven e-Marketplace is one in which the exchange of goods is driven by the consumers who wish to buy a product [23]. The consumer browses the e-Marketplace, evaluates the vendors’ offers, contracts product price with the vendors and decides to buy the product from a selected vendor. The case study is based on the application scenario presented in [24]. The buying process within the e-Marketplace can be described in the following sequence of phases: 1. Request Input. When users wish to buy a product, they identify a set of product parameters (product description, maximum price PMAX, etc), log into the e-Marketplace and submit a request containing the product parameters. The Authentication Authority of the e-Marketplace checks if users are trustworthy (i.e. from a commercial and security viewpoint) and decides if requests can be accepted. If so, the Consumer Assistant System (CAS) of the e-Marketplace starts satisfying the user request. 2. Searching. The CAS obtains a list of locations of vendors by using the Yellow Pages Service (YPS) of the e-Marketplace. The YPS is a federation of autonomous components at which vendors register to advertise their products. In computer systems science & engineering

AN INTEGRATED APPROACH FOR THE DEVELOPMENT AND VALIDATION OF MULTI-AGENT SYSTEMS

Figure 3 The Role Schema of the Consumer role

– – –

– – – 3.



– – –

particular the following YPS organizations were established: Centralized: each YPS component stores a complete list of vendors; One Neighbor Federated: each YPS component stores a list of vendors and keeps a reference to only one other YPS component; M-Neighbors Federated: each YPS component stores a list of vendors and keeps a list of at most M YPS components. Searching can be carried out by adopting one of the following searching policies: ALL: all the reachable YPS components are contacted; PARTIAL (PA): a subset of YPS components are contacted; ONE-SHOT (OS): only one YPS component is contacted. Contracting & Evaluation. The CAS interacts with the found vendors to request an offer (Poffer) for the desired product, evaluates those received, and selects an offer, if any, for which the price is acceptable (i.e. Poffer ≤ PMAX) according to one of the following buying policies: Minimum Price (MP): the CAS first interacts with all the vendors to look for the one offering the desired product at the lowest acceptable price and then purchases the product from this vendor; First Shot (FS): the CAS interacts with the vendors until it obtains an offer for the product at or below PMAX before carrying out the purchase; Fixed Trials (FT): the CAS interacts with a given number of vendors and purchases the product from the vendor offering it at the best acceptable price; Random Trials (RT): the CAS interacts with a random number of vendors and buys the product from the vendor

which offers it at the best acceptable price. 4. Payment. The CAS purchases the desired product from the selected vendor using a given amount of e-cash (or bills). The following steps are performed to execute the money transaction between the CAS and the vendor: (i) the CAS gives the bills to the vendor; (ii) the vendor sends the bills to its bank; (iii) the bank validates the authenticity of the bills, exempts them from reuse, and, finally, issues an amount of bills equal to that previously received to the vendor; (iv) the vendor notifies the CAS. Transactions among the CAS, vendor and bank can be encrypted using public/private keys to avoid bills interceptions. 5. Reporting. The CAS reports the buying result to the user.

3.2

The Analysis phase

The work products of the analysis phase, obtained through the steps described in Section 2.2 are the Roles Model and the Interactions Model. These models are briefly discussed below. 3.2.1 The Roles Model On the basis of the process-oriented description of the system functionalities obtained during the Requirements Capture phase (see Section 3.1), the following key roles were identified: • User Assistant, which assists a user to look for and buy a specific product that meets her/his needs; • MPEntryPoint, which involves granting access to the services of the e-Marketplace;

Table 1 Interaction patterns among roles

Initiator Role

Interaction Name

Responder Role

Communicative Act

User Assistant MPEntryPoint Consumer

BuyingRequest MPAccessGranting VendorListQuery PriceQuery PayFor BuyingResultReport VendorListResponse PriceQueryResponse BillVerifyRequest BillVerifyResponse

MPEntryPoint User Assistant Directory Vendor Vendor User Assistant Consumer Consumer Bank Vendor

Task Execution Request Request Notification Information Request Information Request Task Execution Request Result Notification Result Notification Result Notification Task Execution Request Result Notification

Directory Vendor Bank

vol 20 no 4 july 2005

263

G FORTINO ET AL

• Consumer, which involves the searching and buying of goods; • Directory, which manages a catalogue listing vendors and products; • Vendor, which involves the selling of goods; • Bank, which manages e-cash transactions. Each of these roles was fully described by using, according to the Gaia methodology, a Role Schema. A set of Role Schemas constitutes the Roles Model. A Role Schema draws together the various attributes (Protocols, Activities, Permissions and Responsibilities) discussed in Section 2.2. As an example, the Role Schema for the Consumer (Figure 3) presents the Protocols in which a Consumer is involved (SearchForVendor, ContractingForProduct, ProductPayment, BuyingResultReport), the Activities that it carries out (VendorListConstruction, OfferEvaluation) and the following Permissions with which it is provided: i reading the information about the user represented by the Consumer, the parameters of the product to buy, the vendors of the e-marketplace and the product offers supplied by the vendors; ii generating a list of vendors that sell the product the user wants to buy; iii changing the credit of the user following a product purchase. Regarding to Consumer Responsibilities: • the Liveness Properties are expressed by a Liveness Expression, formalized using the fusion notation [25], which defines the “life-cycle” of the role. The Liveness Expression in Figure 3 indicates that a Consumer: (i) starts its life by performing the SearchForVendor protocol and the VendorListConstruction activity at least once; (ii) exploits the ContractingForProduct protocol and the OfferEvaluation activity for a given number of vendors; (iii) pays for the acquired product (through the ProductPayment protocol) and (iv) reports the buying result to the user (through the BuyingResultReport protocol); • the Safety Properties ensure that a Consumer vendor list will not be empty and that the credit of the user represented by the Consumer will be greater than zero. 3.2.2. The Interactions Model. The identified interaction patterns are reported in Table 1. Using such patterns the protocols associated with the identified roles were defined. For example, the SearchForVendor protocol associated with the Consumer role (see Figure 3), is obtained by composing the VendorListQuery and the Ven-

dorListResponse interactions. In Table 1, the Interaction Name , the Initiator Role (the role which starts the interaction), the Responder Role (the role which responds to the interaction) and the Communicative Act (the action performed by means of the interaction) are specified for each interaction.

3.3

The Design phase

The work products which are obtained in the design phase by performing the steps described in Section 2.3 are the Agent Model, the Services Model and the Acquaintance Model. These models are briefly discussed below. 3.3.1 The Agent Model The Agent Model (Figure 4) was obtained by aggregating the roles identified in the analysis phase into Agent Types. An Agent Type is represented by a tree, in which the leaf nodes correspond to roles and the other nodes correspond to agent types. The Agent Types identified were: User Assistant Agent (UAA), Access Point Agent (APA), Mobile Consumer Agent (MCA), Yellow Pages Agent (YPA), Vendor Agent (VA), and Bank Agent (BA). In this case each Agent Type is associated with a single role. The symbol “+” in the figure indicates multiple instantiation of an Agent Type. 3.3.2 The Services Model Each service associated with a role was documented in the Services Model by describing its inputs, outputs, pre-conditions, and post-conditions. The services provided were derived from the list of Protocols, Activities, Liveness and Safety Properties of the identified roles. For example, the Services associated with the Consumer role are shown in Table 2.

UAA

APA

+

+

MCA

User Assistant MPEntryPoint Consumer

UAA APA MCA YPA VA BA

-

YPA

VA

BA

Directory

Vendor

Bank

+

+

+

+

User Assistant Agent Access Point Agent Mobile Consumer Agent Yellow Pages Agent Vendor Agent Bank Agent

Figure 4 The Agent Model

Table 2 The Services of the Consumer role

Service

Inputs

Outputs

Pre-condition

Post-condition

Searching for Vendors Contracting and evaluation offers Payment of goods

productParameters vendorList selectedVendor

vendorList selectedVendor paymentResult

true true userCredit-= Poffer

Reporting the buying result

paymentResult

true vendorList not empty selectedVendor available userCredit >= Poffer true

264

true

computer systems science & engineering

AN INTEGRATED APPROACH FOR THE DEVELOPMENT AND VALIDATION OF MULTI-AGENT SYSTEMS

3.3.3 The Acquaintance Model The Acquaintance Model (Figure 5) derived from the Roles, Interactions and Agent Model is a directed graph, with nodes corresponding to Agent Types and arcs representing communication pathways.

3.4

Detailed design phase

The work products which are obtained in the detailed design phase by carrying out the steps described in Section 2.4 are the Agent Interactions Model and the Agent Behavior Model. Some of these models, particularly those involving the Mobile Consumer Agent, are described below. 3.4.1 Models of Mobile Consumer Agent A model for the MCA agent can be defined on the basis of a triple , where SP is a searching policy in {ALL, PA, OS} (see Section 3.1), BP is a buying policy in {MP, FS, FT, RT} (see Section 3.1), and MD is a task execution model. Two different task execution models were defined: • Itinerary: the Searching and Contracting & Evaluation phases are performed by a single MCA agent which fulfils its task by sequentially moving from one location to another within the e-Marketplace; • Parallel: the Searching and Contracting & Evaluation phases are performed by a set of parallel mobile agents. The MCA agent is able to generate a set of children (generically called workers) and dispatch them to different locations; the workers can, in turn, spawn other workers. An MCA task execution model is chosen by the Access Point Agent (APA) when it accepts a user input request; the choice can depend on the pair selected by the user and on the e-Marketplace characteristics. If the chosen task execution model is of the Parallel type then the MCA is named PCA (Parallel Consumer Agent) otherwise if the chosen task execution model is of the Itinerary type then the MCA is named ICA (Itinerary Consumer Agent). Therefore, a PCA model is defined by a triple whereas an ICA model is defined by a triple . 3.4.2 The Agent Interactions Model The Agent Interactions Model is reported in Figure 6. The AgentUML diagram reports the identified agent types (UAA, APA, YPA, VA, and BA) along with the interactions among them. Such a model, which is an agent oriented version of the UML Sequence Diagram [26], is to be read from left to right and from top down. The interaction involves five phases, which correspond to the phases identified in the requirement phase (see Section 3.1): Request Input, Searching, Contracting and Evaluation, Payment, and Report. In the Request phase, the UAA sends the Submit(Prod_Params) delegation request message to the APA to start searching for the product specified by the Prod_Params, If it agrees, the APA creates the corresponding MCA agent. The interactions of the MCA in the Searching and the vol 20 no 4 july 2005

UAA

APA

VA

MCA

BA

YPA

Unidirectional communication Bidirectional communication Figure 5 The Acquaintance Model

Contracting & Evaluation phases allow for the selection of which VA to buy the product from. In the Payment phase, the MCA proactively moves (through the Move(VA_Location) message) to the location of the selected VA and sends the PayFor(Prod_Desc, Bills) request to the VA. The VA can either refuse or agree to process the received request and, after interacting with the BA, notifies the MCA with either a failure, or an inform-done (i.e. successful notification), or an inform-result (i.e. successful notification with data results). During the interaction between the MCA and the VA, the VA sends the Verify(Bills) request message to the BA. Finally, in the Report phase, the MCA first moves to the APA location (through the Move(APA_Location) message) and then directly informs the UAA about the buying result. The interactions of the MCA in the Searching and the Contracting & Evaluation phases (see Section 3.1) depend on the model of the MCA agent employed. Figure 7 details the interactions performed by the MCA of a PCA type. In particular: • in the Searching phase, the PCA moves to an YPA location and submits the VendorListQuery(Prod_Desc) request message to the YPA. The YPA returns as informresult a list of VA furnishing the products according to Prod_Desc and a list of linked YPA identifiers (YPAIds). Afterwards, the PCA creates an ISMA (Itinerary Searcher Mobile Agent) agent and delegates to it the task of visiting all the linked YPAs to collect other VA identifiers (VAIds). • in the Contracting and Evaluation phase, the PCA creates as many CMA (Contractor Mobile Agent) agents as the collected VAs. Each CMA moves to the location of an assigned VA and sends the PriceQuery(Prod_Desc) request message to the VA. 3.4.3 The Agent Behavior Model This model is composed of a set of DSC specifications (see Section 2.4) which are associated to each Agent Type. In particular only the behaviour model of the PCA agent is discussed below. The DSC specification of the PCA agent is reported in Figure 8. The DSC specification of the ICA agent can be seen as a particular case of the PCA specification. With reference to Figure 8, it is worth pointing out that: 265

G FORTINO ET AL

APA

UAA

YPA

VA

BA

Submit(Prod_Params):delegation_request refuse

Request Input Phase:

[Refused] agree [Agreed and notification necessary]

(Prod_Params,YPAId,UAAId) [Agreed]

MCA

Searching Phase:

Depending on the model of MCA

Contracting & Evaluation Phase:

Depending on the model of MCA

Move(VA_Location) PayFor(Prod_Desc,Bills): request refuse [Refused]

Payment Phase: agree

[Agreed and notification necessary]

Verify(Bills): request [Agreed]

refuse [Refused] agree [Agreed and notification necessary] failure inform-done inform-result

[Agreed]

failure inform-done

Report Phase:

[Agreed] inform-result

failure Move(APA_Location) inform-done [Agreed] inform-result

Figure 6 The Agent Interactions Model

• events are asynchronously received and processed according to a run-to-completion semantics (i.e. an event can be processed only if the processing of the previous event has been fully completed); • the received events can be asynchronously generated by the agent itself (internal events) or by other agents (external events) through the primitive generate ( ()), where mevent is an event instance and param is the list of formal parameters of mevent including the identifiers of the event sender and of the event target, and (possibly) a list of event parameters. The PCA agent fulfils the searching phase in the SEARCHING state. In particular, as soon as the PCA agent is created, it moves (ac1) to the first Yellow Page Agent (YPA) loca-

266

tion and locally interacts (ac2) with the YPATarget by sending it the VAListQuery event. The YPATarget replies to the PCA agent with the List event which can contain a list of VA agents with the linked YPA agents. After processing the reply (ac3), the PCA agent can do one of the following: • create an Itinerary Searcher Mobile Agent (ISMA), which sequentially moves from one YPA location to another, if the YPS organization is of the One-Neighbor Federated type, and pass (ac4) into the contracting phase as soon as a PList event sent by the ISMA agent is received; • create M Spawning Searcher Mobile Agents (SSMAs), if the YPS organization is of the M-Neighbors Federated type, and pass (ac4) into the contracting phase when all the PList events sent by the directly created SSMA agents

computer systems science & engineering

AN INTEGRATED APPROACH FOR THE DEVELOPMENT AND VALIDATION OF MULTI-AGENT SYSTEMS

are processed. In particular, an SSMA agent moves to the assigned YPA agent and, in turn, creates a child SSMA agent for each reachable YPA agent. This parallel searching technique generates a spawning tree, with SSMA agents as nodes, which is rooted at the PCA agent. If an SSMA agent interacts with a YPA agent which has already been visited by an SSMA agent belonging to the same spawning tree, the YPA agent notifies the SSMA agent which then returns to its parent; • directly pass into the contracting phase if the YPS organization is of the Centralized type; • report an unsuccessful search to the UAA agent.

MCA:PCA

YPA

VA

Move(YPA_Location) VendorListQuery(Prod_Desc): request refuse [Refused] agree [Agreed and notification necessary] failure inform-done

[Agreed]

inform-result Searching Phase: (Prod_Params,YPAId)

The contracting phase accomplished in the CONTRANDEVAL state involves the creation (ac5) of a Contractor Mobile Agent (CMA) for each VA agent in the vaList. Each CMA agent moves to the assigned VA location, contracts with the VA agent, and finally returns to the PCA location to report the offer. The evaluateOffer method, which embeds the buying policy, evaluates the VA offers (PPrice events) reported by the CMA agents and generates (ac6) a decision about when and from which VA agent to purchase. In the PAYFOR state the PCA agent pays (ac7) the VA agent using the PayFor event which contains the bills. After receiving the PaymentDone event, the PCA agent passes (ac8) to the REPORTING state from where it moves back (ac9) to the original APA location and finally reports (ac10) to its UAA agent.

ISMA

* Move(YPA_Location) VendorListQuery(Prod_Desc): request refuse [Refused] agree [Agreed and notification necessary] failure inform-done [Agreed] inform-result failure inform-done inform-result

*

(Prod_Desc,VAId)

3.5

CMA

The implementation phase

Move(VA_Location)

Each agent behaviour defined in the previous phase was seamlessly translated into Java code using the MAO Framework [15] thus obtaining a set of classes which represent the behaviours of the agent types and the inter- and intra-agent interaction events associated with the behaviours. The simplified UML class diagram of the PCA agent behaviour is reported in Figure 9. The package of the MAOFramework core provides three classes to extend representing a simple state (SimpleState), the active state (MAOActiveState) and a composite state of a DSC-based agent behaviour specification (CompositeState). The PCA agent behaviour was constructed on the basis of such classes. With regard to Figures 8 and 9, it is worth noting that: i the SimpleState and CompositeState classes correspond to the simple and composite states of Figure 8 (see name correspondence); ii events and transitions of Figure 8 are hidden by the event handling system which is incorporated into the handler(Event) method; iii variables, action chains (aci), and support methods illustrated in Figure 8 are declared in the state classes according to the hierarchical state organization; iv the PCAActiveState is the top state which encapsulates the DSC specification of Figure 8.

3.6

The Simulation phase

The primary goal for which the simulation phase was per-

vol 20 no 4 july 2005

PriceQuery(Prod_Desc): request

Contracting & Evaluation phase:

refuse [Refused] agree [Agreed and notification necessary] failure inform-done inform-result

[Agreed]

failure inform-done inform-result

Figure 7 The Searching and Contracting & Evaluation phases of the Parallel Consumer Agent

formed was to validate (i) the behaviour of each type of agent, (ii) the different models of MCA agents on the basis of the different YPS organizations, and (iii) the agent interactions. The second goal for which the simulation phase was performed was to better understand the effectiveness of the simulation for evaluating MAS performances. For this purpose, the time required for the ICA and PCA agent to complete the buying task was evaluated. The simulation and analysis parameters are presented in Table 3. The simulated e-Marketplace was set up as follows: • each stationary agent (UAA, APA, YPA, VA, BA) exe-

267

G FORTINO ET AL

Table 3 Simulation and Analysis parameters

SEARCH&BUY SEARCHING

CONTR&EVAL

/ ac1

SEARCH

WAIT4LIST

Contract

List / ac3

PList / ac4

WAIT4CMA Eval / ac11

PPrice / ac6

/ ac5 SQuery / ac2

CreatedMS WAIT4MS

ANALIZE

EVALUATE

Pay UReport / ac9 PAYFOR / ac7 PAYING

Number of VAs Number of YPAs Yellow Pages Organization type: (Centralized, 1-Neighbour, 2-Neighbour δMSG Link delay between two adjacent nodes for transmitting a message δagent Link delay between two adjacent nodes for transmitting a mobile agent TVA Service time of VA TYPA Service time of YPA TAPA Service time of APA TBA Service time of BA TC=TREPORT–TCREATION Completion time of the MCA, where TCREATION is the time of the MCA creation, TREPORT is the time of the MCA report

NotifyUA / ac10 PaymentDone / ac8

REPORTING SReport / ac9

PAID

ac1 : generate(new Move(self(), YPATarget.getCurrLocation())); generate(new SQuery(self())); ac2 : generate(new VAListQuery(self(), YPATarget, vaListQuery)); ac3 : List reply = (List)mevent; proc = processInitialYPAReply(reply) if (proc.createISMA()) sa1(); else if (proc.createSSMA()) sa2(); else if (proc.noVendors()) sa3(); else sa4(); sa1 : generate(new Create(self(), “ISMA”, nextYPATarget)); generate(new CreatedMS(self())); sa2 : for (int i=0; i