当前位置:首页 >> >>

From modeling to simulation of multi-agent systems an integrated approach and a case study

From Modeling to Simulation of Multi-Agent Systems: an integrated approach and a case study
Giancarlo Fortino, Alfredo Garro, and Wilma Russo
D.E.I.S. - Università della Calabria, Via P. Bucci, cubo 41C 87036 Rende (CS), Italy {fortino, garro, russow}@deis.unical.it

Abstract. In this paper, an integrated approach for the modeling and the validation through simulation of multi-agent systems is proposed. The approach centers on the instantiation of a software development process which specifically includes a simulation phase which makes it possible the validation of a multiagent system before its actual deployment and execution. The 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 discreteevent simulation framework for the simulation. The proposed approach is exemplified by defining and simulating a multi-agent system concerning with an agent-mediated consumer-driven e-Marketplace which offers mobile agentbased services for searching and buying goods.

1 Introduction
Recently, several methodologies supporting analysis, design and implementation of Multi-Agent Systems (MAS) have been proposed in the context of Agent Oriented Software Engineering (AOSE) [17]. Some of the emerging methodologies are Gaia [22], MaSE [7], Prometheus [19], Tropos [1], Message [5], Passi [4], and Adelfe [2]. These notable efforts basically provide a top-down and iterative approach for the modeling and the development of agent-based systems. Although, from the software development life-cycle point of view, such methodologies fully cover the requirements, architectural design and detailed design, the implementation phase is not well supported [6]. In fact, the design models are hard to map to different target agent platforms since a seamless translation process is usually not provided. Furthermore, none of them 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 to evaluate how complex MAS work on scales much larger than the scales achievable in real testbeds [21]. This paper proposes an integrated approach for the modeling and the validation through simulation of MAS. The approach centers on the instantiation of a software development process which specifically includes a simulation phase which makes it

possible the validation of a MAS before its actual deployment and execution. In the proposed approach, requirements capture is supported by a goal-oriented approach [1], the analysis and design phases are supported by the Gaia methodology [22], the detailed design phase is supported by Agent-UML [3] and the Distilled StateCharts formalism [11], the implementation phase is supported by the MAO Framework [9, 11], and the simulation phase is enabled by a Java-based event-driven framework [10]. 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 e-Marketplace consists of a set of stationary and mobile agents, which provide basic services such as secure access to the eMarketplace, discovery of vendors of a given product, selling of products, and product payment through e-cash. In particular, two models of mobile consumer agents, namely itinerary and parallel, which are able to search for and buy products on behalf of users, were defined. 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. Finally, conclusions are drawn and directions of future research delineated.

2 An integrated approach for modeling and simulating MultiAgent Systems
In this section an integrated approach which allows to fully and seamlessly support the modeling and simulation of MAS is proposed. The approach centers on the instantiation of the process, shown in Figure 1 using the SPEM notation [20], which completely covers the development of MAS. An instance of the process can be obtained by exploiting in each phase a methodology or a methodology fragment chosen from agent-oriented methodologies proposed in the literature [22, 7, 19, 1, 5, 4, 2] or ad-hoc defined.

Simulation Work Product

Requirements Statement

Analysis Work product

Design Work Product

Detailed Design Work Product

Implementation Work Product


Requirements Capture



Detailed Design


Deployment Work Product


Fig. 1. The reference development process

In the following, the proposed approach is illustrated by describing each phase along with the adopted methodology. Requirements Capture. The requirements are captured using a goal oriented approach [1] and reported in a Requirements Statements document which represents the work product of this phase. Analysis. The analysis phase, which is aimed at developing an understanding of the system and its organization, is supported by the Gaia methodology [22]. The work products of this phase (the Prototypical Roles Model, the Interactions Model and the Roles Model) are obtained in the following steps: 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 to each role to capture the recurring patterns of inter-role interaction (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 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 across all states of execution. Permissions are the rights associated with a role and identify the resources that are available to that role in order to realize its responsibilities. Protocols defines how a role can interact with other roles. Finally, the Activities of a role are computations associated with the role that may be carried out by the agent without interacting with other agents. Design. The aim of the design phase is to transform the analysis models into a design which is concerned with the cooperation in a society of agents and the services offered by each individual agent to realize 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, so forming an agent type hierarchy and establishing how many agent instances could be instantiated for each type (Agent Model). 2. Identification of the main Services that are required to realize the agent's role by examining activities, protocols, and safety and liveness properties of roles (Services Model). A service is a coherent block of activity in which an agent will engage. Inputs, outputs, pre-conditions, and post-conditions are to be identified for each service.

3. Documentation of the relationships of communication between the different agent types (Acquaintance Model). The Acquaintance Model does not define what messages are sent or when messages are sent, it simply indicates that communication pathways exist. Detailed Design. The objective of this phase is to obtain a detailed specification, seamlessly translatable into code, of the behaviors of the Agent Types 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 [3] to thoroughly specify the patterns of interaction between the Agent Types of the Agent Model (Agent Interactions Model); 2. The Distilled StateCharts (DSC) formalism [11] to specify the dynamic (proactive, active and reactive) behavior of each Agent Type (Agent Behaviors Model) on the basis of the design work product and the Agent Interactions Model. DSC were derived from Statecharts [15] and allow to model the behavior 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 [12]. Implementation. The aim of the implementation phase is to obtain the code of the agent behaviors 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 [9] by which a DSC specification can be seamlessly translated into a composite object (called “MAOBehavior object”) representing an agent behavior and into a set of event objects (or simply Events) representing interactions. The obtained code, before its deployment and execution, should be adapted to the target agent platform. The adaptation can be carried out by means of the customization of the Mobile Agent Adaptation Framework (MAAF) [11] for a given agent platform. In [11] the customization for the Voyager ORB system is reported. Simulation. The strategic goal of the simulation phase is the validation of the MAS under-development before its actual deployment by providing, as work product, both qualitative and quantitative information about correctness and efficiency. This information can be exploited for the reformulation, modification and/or refinement of some choices carried out in the previous phases of the development process. The simulation phase is supported by a Java-based, discrete-event simulation framework [10] for stationary and mobile agents. Using this framework, an agent-based complex system can be easily validated and evaluated by defining suitable test cases and performance measurements. In particular, the simulation engine of the framework allows for the: (i) execution of agents by interleaving their event processing, (ii) exchange of events among agents, (iii) migration of agents, and the (iv) clustering of

agents into agent servers 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 a stationary or a mobile agent and including a pair of objects: <MAOId, MAOBehavior>, where MAOId is the agent identifier and MAOBehavior incorporates the dynamic behavior 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 AgentsServer is mapped; the UserAgent, which is an object representing a user. A UserAgent, which is directly connected to an AgentServer and can create, launch and interact with Agents; the UserAgentGenerator, which is an object modeling the process of generation of UserAgents.

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 environments which offers new channels and business models for buyers and sellers to effectively and efficiently trade goods and services over the Internet [16]. A consumer-driven e-Marketplace is an e-Marketplace in which the exchange of goods is driven by the consumers that wish to buy a product [18]. The consumer browses the e-Marketplace, evaluates the vendors’ offers, contracts with the vendors the product price and decides to buy the product from a selected vendor. The case study is based on the application scenario presented in [23]. 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 identifies a set of product parameters (product description, maximum price PMAX, etc), log into the eMarketplace 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 their requests can be accepted. If a user request is accepted the Consumer Assistant System (CAS) of the eMarketplace 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 to which vendors register to advertise the products they offer. In 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. 3. Contracting & Evaluation. The CAS interacts with the found vendors to request an offer (Poffer) for the desired product, evaluates the received offers, and selects an offer, if any, for which the price is acceptable (i.e., PofferLPMAX) according to the following buying policies: Minimum Price (MP): the CAS first interacts with all the vendors to look for the vendor 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 an acceptable price; then, it buys the product; Fixed Trials (FT): the CAS interacts with a given number of vendors and buys the product from the vendor which offers 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 Roles Model. On the basis of the process-oriented description of the system functionalities obtained during the Requirements Capture phase (see Sect. 3.1), the following key roles were identified: User Assistant, which involves assisting a user in looking for and buying a specific product that meets her/his needs; MPEntryPoint, which involves granting the access to the services of the eMarketplace; Consumer, which involves searching and buying of goods; Directory, which involves the management and the provision of a catalogue of vendors of specific products;

Vendor, which involves selling of goods; Bank, which involves the management of e-cash transactions. According to the Gaia methodology each role was represented using a Role Schema. As an example, the Role Schema for the Consumer is reported in Fig. 2.
Role Schema: CONSUMER Description: This role involves searching and buying of goods Protocols and Activities: SearchForVendor,VendorListConstruction, ContractingForProduct, OfferEvaluation, ProductPayment, BuyingResultReport Permissions: reads supplied userInformation, supplied productParameters, supplied vendors, supplied offers generates vendorList changes userCredit Responsibilities Liveness: + + CONSUMER=(SearchForVendor"VendorListConstruction) (ContractingForProduct"OfferEvaluation) ProductPayment " BuyingResultReport Safety: - vendorList not empty; userCredit >0

Fig. 2. The Role Schema for the Consumer

The Interactions Model. The identified interaction patterns are reported in Table 1. Using such patterns the protocols associated to the Roles were defined. For example, the SearchForVendor protocol (see Fig. 2) associated to the Consumer role, is obtained by composing the VendorListQuery and the VendorListResponse interactions.
Table 1. Interaction patterns among roles
INITIATOR ROLE User Assistant MPEntryPoint Consumer Directory Vendor Bank INTERACTION BuyingRequest MPAccessGranting VendorListQuery PriceQuery PayFor BuyingResultReport VendorListResponse PriceQueryResponse BillVerifyRequest BillVerifyResponse RESPONDER ROLE MPEntryPoint User Assistant Directory Vendor Vendor User Assistant Consumer Consumer Bank Vendor COMMUNICATIVE ACT Task Execution Request Request Notification Information Request Information Request Task Execution Request Result Notification Result Notification Result Notification Task Execution Request Result Notification

3.3 The Design phase The Agent Model. The defined Agent Model is shown in Fig. 3a. There is a one-toone correspondence between the roles defined in the Roles Model and the identified Agent Types: User Agent (UA), Access Point Agent (APA), Mobile Consumer Agent (MCA), Yellow Pages Agent (YPA), Vendor Agent (VA), and Bank Agent (BA). Each agent type can be instantiated one or more times at run time.

The Acquaintance Model. The communication links existing between the agent types defined in the Agent Model are shown in Fig. 3b.
User Agent












User Agent



User Assistant MPEntryPoint Consumer Directory Vendor Bank





Fig. 3. The Agent Model and the Acquaintance Model

The Services Model. A Services Model for each role was specified. Because of space limitations only the Services Model for the Consumer role is reported (Table 2).
Table 2. The Services Model for the Consumer role
SERVICE Searching for vendors Contracting and evaluation offers Payment of goods Reporting the buying result INPUTS OUTPUTS PRE-CONDITION true POST-CONDITION true true

productParameters vendorList selectedVendor paymentResult

vendorList selectedVendor paymentResult

vendorList not empty

selectedVendor available userCredit -= Poffer userCredit >= Poffer
true true

3.4 The Detailed Design phase The Agent Interactions Model is reported in Fig. 4. The interactions in the Searching and the Contracting & Evaluation phases (see Sect. 3.1) are not detailed in the figure since they depend on the behavior model of the MCA agent which is employed. The Agent Behaviors Model is composed of a set of DSC specifications which are associated to each Agent Type. In particular, in the following, only the behavior models of the MCA agents are discussed. Mobile Consumer Agent models. A behavior model for the MCA agent can be defined on the basis of a tuple: <SP, BP, MD>, where SP is a searching policy in {ALL, PA, OS}, BP is a buying policy in {MP, FS, FT, RT}, 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 mobile agents in parallel. The MCA agent is able to generate a set of children (generically called workers) and to dispatch them to different locations; the workers can, in turn, spawn other workers.

An MCA model is chosen by the APA agent when it accepts a user input request. The DSC specification of the defined Parallel Consumer Agent (PCA) model is detailed in the following. The defined Itinerary Consumer Agent (ICA) model can be seen as a particular case of the PCA model.
User Agent





Submit(Prod_Params):delegation_request refuse [Refused] agree [Agreed and notification necessary] <<create>> (Prod_Params,YPAId,UAId) [Agreed] Request Input Phase:


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 Payment Phase: agree refuse [Refused] Verify(Bills): request [Agreed] refuse [Refused] agree [Agreed and notification necessary] failure inform-done inform-result [Agreed]

[Agreed and notification necessary]

failure Report Phase: inform-done

[Agreed] inform-result

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

Fig. 4. The Agent Interactions Model

A Parallel Consumer Agent model. The DSC specification of the PCA agent is reported in Fig. 5. With reference to Fig. 5, it is worth pointing out that: 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 is fully completed);

the received events can be asynchronously generated by the agent itself (internal events) or by other agents (external events) through the primitive generparam is ate(<mevent>(<param>)), where mevent is an event instance and 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.
SEARCHING / ac1 SQuery / ac2 SEARCH PList / ac4 WAIT4MS WAIT4LIST List / ac3 CreatedMS ANALIZE EVALUATE Contract WAIT4CMA Eval / ac11 CONTR&EVAL / ac5 PPrice / ac6

Pay UReport / ac9 PAYFOR / ac7 PAYING PaymentDone / ac8 NotifyUA / ac10 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<ypaList.size(), i++) generate(new Create(self(), “SSMA”, ypaList.elementAt(i))); generate(new CreatedMS(self())); sa3 : generate(new UReport(self())); sa4 : generate(new Contract(self())); ac4 : PList reply = (PList)mevent; res = processMSReply(reply); if (res.contract()) sa4() else if (res.noVendors()) sa3(); ac5: ac5 for (int i=0; i<vaList.size(), i++) generate(new Create(self(), “CMA”, vaList.elementAt(i))); ac6 : PPrice offer = (PPrice)mevent; eval = evaluateOffer(offer); if (eval.buy()) generate(new Eval(self())); else if (eval.noBuy()) sa3(); ac7 : bills = prepareBills(price); generate(new PayFor(self(), VATarget, bills)); ac8 : nbills = nbills – eval.price(); generate(new SReport(self())); ac9 : generate(new Move(self(), self().getHomeLocation())); generate(new NotifyUA(self())); ac10: reportTR(); c10 ac11: ac11 generate(new Move(self(), VATarget.getCurrLocation())); generate(new Pay(self()));

Fig. 5. The DSC specification of the PCA agent.

The PCA agent fulfills the searching phase in the SEARCHING state. In particular, as soon as the PCA agent is created, it moves (ac1) to the first YPA location 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 are processed. In particular, a 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 and rooted at the PCA agent. If a SSMA agent interacts with a YPA agent which has already been visited by a SSMA agent belonging to the same spawning tree, the YPA agent notifies the

SSMA agent which comes back to its parent; directly pass into the contracting phase if the YPS organization is of the Centralized type; report an unsuccessful search to the UA agent. The contracting phase accomplished in the CONTRANDEVAL state involves the creation 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 UA agent.

MAO Framework Core SimpleState MAOActiveState CompositeState

-owner; -vaListQuery; -vaList; -VATarget; -bills; -nbills; -ac9()

-ac10() -reportTR() +handler(Event):void

-ac7(); -ac8() -prepareBills() +handler(Event):void

- sa3() +handler(Event):void

SearchingState PayingState

-ac5(); -ac6(); -ac11(); -evaluateOffer() +handler(Event):void


- nextYPATarget; -YPATarget; -ypaList; -ac1(); -ac2(); -ac3(); -ac4() -sa1(); -sa2(); -sa4() -processInitialYPAReply() +handler(Event):void



-processMSReply() +handler(Event):void




Fig. 6. Class diagram of the PCA agent behavior

3.5 Implementation phase Each agent behavior defined in the previous phase has been seamlessly translated into Java code using the MAO Framework [9, 11] so obtaining a set of classes which represent the behaviors of the agent types and the inter- and intra-agent interaction events which are associated to the behaviors. In Fig. 6 the simplified UML class diagram of the PCA agent behavior is reported. 3.6 Simulation phase The primary goal of the simulation phase which was performed was to validate (i) the behavior 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 of the performed simulation phase was to better understand the effectiveness of the simulation for evaluating MAS performances. To this purpose, the evaluation of the completion time of the buying task of the ICA agent and the PCA agent was carried out. Such evaluation also allowed to validate an analytical model proposed in [23] regarding the sequential and parallel dispatching of mobile agents. The simulation and analysis parameters are presented in Table 3. The simulated eMarketplace was set up as follows: each stationary agent (UA, APA, YPA, VA, BA) executes on a different agent server; the agent servers are mapped onto different network nodes which are completely connected through network links which have the same characteristics. The network link delay (U) is modeled as a lognormally distributed random variable with a mean, ?, and standard deviation, W [8]; each UA agent is connected to only one APA agent at the same time; the price of a product, which is uniformly distributed between a minimum (PPMIN) and a maximum (PPMAX) price, is set in each VA agent at initialization time and is never changed; thus the VA agents adopt a fixed-pricing policy to sell products; each YPA agent manages a list of locations of VA agents selling available products. a UA agent searches the e-Marketplace for a desired product which always exists and is willing to pay a price PMAX for it which can be any value uniformly distributed between PPMAX and (PPMAX+PPMIN)/2. In order to analyze e-Marketplaces having different structures and dimensions, the simulations were run by varying the organization of YPS (Centralized, 1-Neighbour and 2-Neighbour organized as a binary tree), the number of the YPA agents in the range [5..40] and the number of VA agents in the range [5..640]. These ranges were chosen for accommodating small as well as large e-Marketplaces.

Table 3. Simulation and Analysis parameters

Number of VAs Number of YPAs Yellow Pages Organization type: {Centralized, 1-Neighbour, 2Neighbour} Link delay between two adjacent nodes for transmitting a message Link delay between two adjacent nodes for transmitting a mobile agent Service time of VA Service time of YPA Service time of APA Service time of BA Completion time of the MCA, where TCREATION is the time of the MCA creation and TREPORT is the time of the MCA report




The performance evaluation focused on the <ALL, MP, *> MCA models (see Sect. 3.4) since they are the only MCA models which guarantee both a successful purchase and the best purchase since they are successful at identifying the VA selling the desired product at the minimum price. The results obtained for the <ALL, MP, *> MCA models over an YPS organization of the binary tree 2-Neighbour type are reported in Fig. 7. The results shown in Fig. 7a were obtained with NYPA=10 and by varying NVA, whereas, the results shown in Fig. 7b were obtained with NVA=80 and by varying NYPA. In agreement with the analytical model reported in [23], the PCA agent, due to its parallel dispatching mechanism, outperforms the ICA agent when NVA and NYPA increase.
800 700 600 Tc [t.u.] ICA PCA
Tc [t.u.]

160 140 120 100 80 60 40 20 0 ICA PCA

500 400 300 200 100 0 5 10 20 40 80 160 320 640 N VA










Fig. 7. Performance evaluation of the <ALL, MP, *> MCA models for an e-Marketplace with YPO=2-Neighbour of the binary tree type: (a) NYPA=10 with variable NVA, (b) NVA=80 with variable NYPA

4 Conclusions
Flexible processes, methodologies and tools for the modeling and the simulation of agent-based systems are highly required to effectively support agent-oriented software development in emerging and complex application domains such as e-Commerce, e-Learning, and e-Science.

This paper has proposed an integrated approach which supports the modeling and simulation of MAS. The efficacy of the proposed approach has been highlighted through a case study concerning with an agent-based consumer-driven e-Marketplace. The distinctive features of the proposed approach are: 1. Integration. The integrated use of existing methodologies, method fragments and tools for driving the software development phases of MAS is now widely recognized also in the ‘Agents’ research area as it is witnessed by the fervent activity in the Modeling and Methodology Technical Committees of FIPA; 2. Seamless code generation and adaptation. The detailed design is seamlessly translatable into a platform-neutral code by means of the MAO Framework. The obtained code can be used for feeding both the simulation phase and, notably, the deployment phase after adaptation of the code to the target agent platform; 3. Simulation. The use of the simulation to validate the modeled MAS before its actual deployment and execution, is strategic. In fact, the simulation, particularly if event-driven, is the only viable means for the validation of large-scale and complex MAS. Current research efforts are devoted to: improving the integration among the phases of the proposed approach and, in particular, between the design phase and the detailed design phase. The chosen technique is based on the extraction of methodology fragments and on the representation of these fragments using a SPEM-based common notation. In particular, the extraction and representation of fragments of the Gaia methodology is an on-going activity in the context of the Methodology TC of FIPA [13]; simulating agent-mediated e-Commerce scenarios more complex than the scenario of the presented case study for the purpose of (i) validating and evaluating new business models, strategies, and systems and (ii) gaining insights into how different market mechanisms and business models might play out in real e-Marketplaces [14].

1. P. Bresciani, P. Giorgini, F. Giunchiglia, J. Mylopoulos and A. Perini. TROPOS: An Agent-Oriented Software Development Methodology, Journal of Autonomous Agents and Multi-Agent Systems, 8(3):203-236, 2004. 2. C. Bernon., M.P. Gleizes, G. Picard, and P. Glize. The Adelfe Methodology For an Intranet System Design. In Proc. of the Fourth International Bi-Conference Workshop on AgentOriented Information Systems (AOIS), Toronto, Canada, 2002. 3. B. Bauer, J.P. Muller, and J. Odell. Agent UML: A Formalism for Specifying Multiagent Interaction. In Paolo Ciancarini and Michael Wooldridge, editors, Agent-Oriented Software Engineering, pages 91-103. Springer-Verlag, Berlin, 2001. 4. M. Cossentino, P. Burrafato, S. Lombardo, and L. Sabatucci. Introducing Pattern Reuse in the Design of Multi-Agent Systems. In Ryszard Kowalczyk, J?rg P. Müller, Huaglory Tianfield, Rainer Unland, editors, Agent Technologies, Infrastructures, Tools, and Applications for E-Services, LNAI 2592, pages 107-120. Springer-Verlag, Berlin, 2003.

5. G. Caire, F. Leal, P. Chainho, R. Evans, F. Garijo, J. Gomez, J. Pavon, P. Kearney, J. Stark, and P. Massonet. Agent Oriented Analysis using MESSAGE/UML. In Proc. of the Second International Workshop on Agent-Oriented Software Engineering (AOSE), LNCS 2222. Springer-Verlag, Berlin, 2002. 6. K.H. Dam and M. Winikoff. Comparing Agent-Oriented Methodologies. In Proc. of the fifth International Bi-Conference Workshop on Agent-Oriented Information Systems (AOIS), Melbourne, Australia, 2003. 7. S. A. DeLoach, M. Wood, and C. Sparkman. Multiagent system engineering. International Journal of Software Engineering and Knowledge Engineering, 11(3):231–258, April 2001. 8. S. Floyd and V. Paxson. Difficulties in simulating the Internet. IEEE/ACM Transations on Networking, 9(4):392-403, 2001. 9. G. Fortino, W. Russo, and E. Zimeo. A Framework for Design and Implementation of Mobile Active Objects. In Proc. of IASTED Internationall Conference on Software Engineering and Applications (SEA), Marina del Rey, CA, pages 635-640. Acta Press, 2003. 10. G. Fortino and W. Russo. A Statecharts Based Methodology for the Simulation of Mobile Agents. In Proc. of the EUROSIS European Simulation and Modeling Conference (ESMC), pages 77-82, Naples, Italy, October 2003. 11. G. Fortino, W. Russo, and E. Zimeo. A Statecharts-based Software Development Process for Mobile Agents. Information and Software Technology, 2004. to appear. 12. Foundation of Intelligent and Physical Agents (FIPA), http://www.fipa.org. 13. A. Garro, P. Turci, and M.P. Huget. Expressing Gaia Methodology using Spem. FIPA Methodology TC, working draft v. 1.0/04-03-15, http://fipa.org/activities/methodology.html. 14. M. Griss and R. Letsinger. Games at Work – Agent-Mediated E-Commerce Simulation. In Proc. of ACM Autonomous Agents, Barcellona, Spain, Jun. 2000. 15. D. Harel and E. Gery. Executable Object Modelling with Statecharts. IEEE Computer, 30(7): 31-42, 1997. 16. R. Kowalczyk, M. Ulieru, and R. Unland. Integrating Mobile and Intelligent Agents in Advanced e-Commerce: A Survey. In Ryszard Kowalczyk, J?rg P. Müller, Huaglory Tianfield, Rainer Unland, editors, Agent Technologies, Infrastructures, Tools, and Applications for E-Services, LNAI 2592, pages 295-313. Springer-Verlag, Berlin, 2003. 17. J. Lind. Issues in Agent-Oriented Software Engineering. In Proc. of the First International Workshop on Agent-Oriented Software Engineering (AOSE), LNCS 1957, pages. 45-58. Springer-Verlag, Berlin, 2001. 18. P. Maes, R.H. Guttman, and A. Moukas. Agents that buy and sell: Transforming commerce as we know it. Communications of the ACM, 42(3): 81-91, 1999. 19. L. Padgham and M. Winikoff. Prometheus: A methodology for developing intelligent agents. In Proc. of the Third International Workshop on Agent-Oriented Software Engineering (AOSE), LNCS 2585. Springer-Verlag, Berlin, 2003. 20. Software Process Engineering Metamodel Specification, Version 1.0, formal/02-11-14. Object Management Group Inc. , November 2002. 21. A.M. Uhrmacher, M. R?hl, and B. Kullick. The Role of Reflection in Simulating and Testing Agents: An Exploration Based on the Simulation System James. Applied Artificial Intelligence (9-10):795-811, October-December, 2002. 22. M. Wooldridge, N. R. Jennings, and D. Kinny. The Gaia methodology for agent-oriented analysis and design. Journal of Autonomous Agents and Multi-Agent Systems, 3(3):285– 312, 2000. 23. Y. Wang, K-L. Tan, and J. Ren. A Study of Building Internet Marketplaces on the Basis of Mobile Agents for Parallel Processing. World Wide Web: Internet and Web Information Systems 5(1): 41-66, 2002.



All rights reserved Powered by 甜梦文库 9512.net

copyright ©right 2010-2021。