## 3 E-barter Case Study
### System Implementation with Model Transformations and Delta Code Development
#### 3.2.1 Model Transformations  
Based on the proposed methodology, M2M transformations are applied for transforming the models designed in SEA_ML as platform independent models and JACK BDI agent and OWL-S models as platform-specific models. A part of generated OWL-S instance model for E-barter system is depicted in Listing 1. In this model the Food service is defined in Lines 7-16, and Electronic Devices service in Lines 17-26 with their interfaces and groundings.  
The M2T rules are applied on platform-specific models (JACK and OWL-S models) for the generation of JACK BDI agent codes and OWL-S documents (including Service, Profile, Process and Grounding documents) corresponding to semantic web agents and semantic web services designedin the system. As an example of the generated code, an excerpt of OWL-S Service file (\"Service.owl\") is shown in Listing 2. This file consists of the definition of the other documents for the service.  
Although the codes generated for the MAS can be executed directly in the JACK environment, additional codes should be added into these generated codes, called delta code, by the developer to have the fully functional system.  
According to the proposed MAS development methodology, the generated code can be modified in the target language environment, JACK editor in the case of our study. JACK environment has a built-in graphical user interface that represents classes and their relations. After model-to-text transformations, JACK Java classes are produced for the customer agent from intermediate models. Apart from creating a Java class for the customer agent, separate Java classes are generated for this agent's capabilities, plans, events, and beliefs. Part of the generated codes demonstrated in the JACK editor is depicted in Figures 5 and 6. In the generated codes, the customer agent has two capabilities, namely Bartering and Searching. There are separate Java classes produced for these capabilities which are interlinked to the generated architecture code. Also, the Java classes that are generated for each capability of the agent, are linked to the plan, event, and belief classes that this capability requires.  
As it is shown in Figure 5, the searching capability has two plans. One of them is AskToMatchmaker plan. This plan handles SeedRequest event and sends MatchRequest event to the Matchmaker agent for getting suitable services list. The HandleMatch plan handles Match event which is sent from the Matchmaker agent. The Match event encapsulates a service list. If the service list is null, it means that there is no suitable service for MatchRequest sent from Customer agent. Otherwise, the HandleMatch plan try to get appropriate agents from the services for bartering. If the  
Figure 5: Searching capability in JACK editor.  
Customer agent finds suitable agents using the HandleMatch plan, it will start negotiation with these agents, if not, it will send a request to Matchmaker agent to register itself in a suitable service.  
Bartering capability (see Figure 6) is responsible for the negotiations between the agents. When StartNegotiating event is posted, the PerformNegotiation plan is executed to handle it. NegotiationProposal event is created and sent to the relevant Customer agent. ProposalEval plan is responsible for evaluating incoming proposals and responding them. If the answer of the proposal is positive, the NegotiationFinalize plan is used to finalize the negotiation between two agents.