1 ReSeagent: A Refactoring Tool for Plan Level Refactoring in MAS Development Ali Murat Tiryaki and Oguz Dikenelli Ege University, Department Of Computer Engineering 35100 Bornova, Izmir, Turkey Email: {ali.murat.tiryaki,oguz.dikenelli}@ege.edu.tr In our previous work, Abstract—The need for XP-like agile approaches that facilitate in MAS development, since MASs are built using different flexible evolutionary development has been widely acknowledged abstractions and techniques. So we need to re-define these in the AOSE area. Such approaches improve acceptability of practices for MAS development. agent-technology by the industry. Evolutionary development of multi agent systems-MASs can only be applied successfully, if In [28], we have proposed a refactoring approach that makes designs of the MASs being developed are improved throughout evolutionary MAS development possible. This refactoring ap- the development process.InIn our our previous previous work, work, we have defined a proach follows the route of traditional refactoring and provides refactoring approach that makes evolutionary MAS development some new refactoring patterns for MAS development. The possible. In this paper, we mainly aim to identify a development proposed approach introduces some common problems called approach for MAS refactoring tools. In order to discuss this approach, we developed a refactoring tool called ReSeagent on “bad smells” experienced during the development of MAS the Seagent framework. Although the ReSeagent tool supports systems (such as duplicated behaviour structure and big plan) plan level refactoring patterns that are to be manually applied and maintenance strategies called “refactoring patterns” to by the developers, ideas used in the implementation of this tool overcome these bad smells. Each of the refactoring patterns are generic ideas that provide a base for different refactoring defined in this proposed approach focuses on overcoming types and development artifacts. one or more than one bad smell(s) encountered during MAS development. I. I NTRODUCTION In this paper, we aim to introduce a basic development Based on the experiences on agent-based system devel- approach to produce MAS refactoring tools. Then, we imple- opment, AOSE research community has realized that it is ment a refactoring tool called as ReSeagent on Seagent MAS almost impossible to develop complex systems like multi agent development framework [14], [15] by using the proposed ap- systems - MAS in a sequential manner [33], [7]. The solution proach. This tool supports refactoring on agent plans supported is the iterative approach which has been accepted as one of by almost all MAS development methodologies such as Passi the best practices by software development community and [10], Tropos[5] and MaSe [13]. The tool can be used manually integrated to all recent software development methodologies by developers during MAS development activities. ReSeagent such as Rational Unified Process - RUP [26] and Extreme focuses on refactoring Seagent plans whose meta model is Programming - XP [3]. defined clearly in Seagent. However, software architecture of Managing the continuous evolution of software architecture the tool is generic and it can be used for other planning and related design is one of the key issues in iterative devel- systems whose meta-models are explicitly defined or other opment. XP introduces two critical practices to manage the MAS design artifacts such as role, goal and protocols. evolution of software architectures: test driven development [21] and refactoring [18]. II. R ELATED W ORKS Test driven development produces test code for each class developed during iterations. This test code provides a pro- In the literature, there are some pioneering works which try tection shield against the flaws that can occur as a result to apply agile practices to MAS development. of changes made on the working code by guaranteeing the Knublauch [20] used practices of extreme programming - functional accuracy of this code. The other best practice XP [3], which is the one of the most known agile development refactoring defines a process for improving the structure of processes used for MAS development. Although, this work the software system without altering the external behavior. proves the effectiveness of XP practices in terms of MAS An iterative and incremental development life-cycle ap- development, refactoring is not explained in detail. Since the proach is quite appropriate for developing large scale dis- agent development framework and process meta-model, which tributed and complex systems such as MASs. XP-like agile are used during development, are very simple, refactoring processes, that introduce light-weight practices for iterative operations on agents seem as very simple processes and and incremental development in a controllable way, are needed refactoring practice is applied on agents. However, an agent to improve acceptability of the agent-technology by the indus- that is developed by using a realistic development framework try [7], [33]. However, traditional testing and refactoring ap- can play many roles in MAS and those roles have many goals, proaches and their supporting tools cannot be re-used directly responsibilities and abilities. So, we believe that agents are not 2 small; on the contrary they are too big entities for testing and III. A D EVELOPMENT A PPROACH FOR MAS refactoring. R EFACTORING T OLLS In another important work has been introduced by Chella Refactoring is directly dependent on the executable artifacts et. al. [8], well known Passi methodology is transformed to of the developed system. In AOSE area, it is not possible to Agile Passi. The testing framework developed by the Agile define a set of executable artifacts that can be agreed on, since Passi research team provides an automated testing approach there are several agent architectures such as BDI, re-active, for testing multi-agent systems [6], [11]. Agile Passi approach self-organized and several development approaches such as does not introduce an iterative or evolutionary style for MAS Gaia [32], Tropos [5] and Adelfe [4] that aim to develop development. Therefore, a refactoring approach that makes agents based on these agent architectures. Naturally, Naturely, different agile MAS development possible is not introduced in this emerge based on the used agent executable artifacts may emerged work. architecture and/or development frameworks that support these In [9], an agile methodology for MAS development is architectures. As a conclusion, it is impossible to develop a introduced. This methodology is a generic methodology based refactoring tool that is usable for all kinds of MAS develop- on the practices such as test driven development and refac- ment artifacts. Instead of this, we need a generic approach to toring that come from the agile approaches. The process of develop MAS refactoring tools. This approach can be specified SADAAM consists of four key phases: design, test driven im- for different MAS architectures and/or different artifacts to plementation, release & review and refactor & enhancement, produce a suitable refactoring tool. that are applied iteratively until a finished state is reached. The proposed development approach has three steps listed However, any detailed discussion on how the practices called as follows: test driven development and refactoring are applied during 1) Define the meta-model of the target executable develop- MAS development. Hence, the proposed methodology is a ment artifacts, generic methodology that does not add too many specific 2) Define the bad smells encountered during the develop- ideas to the abstract development process proposed by agile ment of the artifacts specified in the previous step, approaches. To concretize how the proposed methodology 3) Define the refactoring patterns that overcome the bad is used for MAS development, the agile practices in the smells defined for the target development artifact. methodology have to be discussed exhaustively. To illustrate how the proposed approach can be applied to work [30] focuses on to define which and Another working refactoring tool development, we chose the agent plans as how traditional refactoring practice can be used for agent the target development artifact. Agent plan abstraction is based simulation systems on a multi agent simulation systems one of the most common artifacts in MAS development modeling paradigm called MASim. At the end of the working, methodologies. Almost all of the MAS methodologies use a catalog that consists of the refactoring patterns used to plan abstraction (it is named with different terms in different improve the system designs based MASim is introduced. methodologies) to model agents’ internal behaviours. For Moreover, some of the proposed refactoring patterns has been example, in the goal oriented development approach, each implemented and integrated to an agent based simulation agent goal is achieved by one or more agent plan(s). Several platform called SeSam. This working does not introduce a approaches can be used to build plan structures such as HTN general refactoring approach and its main characteristics for [31], [23] based on the agent infrastructure. Developers have MAS development. The proposed refactoring patterns can be to specify the planning approach before they apply first step of used to only the agent systems that have a specific type. To the proposed refactoring tool development approach (defining define the refactoring patterns that can be used during MAS the meta-model of the target artifacts). development, firstly a general refactoring approach based on In our case, we aim to develop a refactoring tool for the the characteristics of these systems has to be defined. Seagent framework that was developed by our research group. In [29], an iterative and incremental development approach So, our refactoring tool called ReSeagent aims to refactor called agent oriented test driven development - AOTDD is agent plans that are directly dependent on the Seagent planning proposed to handle the complexity and continuously changing infrastructure. nature of the requirements in MAS development. In AOTDD, The rest of this section explains how the steps of the developers follow the development cycle with adding the new proposed approach were applied for the plan artifact in the functionalities to the system between iterations, just like all Seagent framework. other agile & iterative development approaches. Also, the life cycle of proposed test driven approach and a testing tool that supports the proposed test driven approach are introduced in A. Define the meta-model of the target executable development this work. Since this work is focused on the testing part of test artifacts driven development, the refactoring step that is very critical Performing a refactoring pattern requires a clear understand- for iterative and incremental development is not discussed in ing of the abstract syntax and semantics of both the source detail. and target models. Meta-modeling is a common technique for These works neither propose a systematic approach for defining the abstract syntax of models and the interrelation- MAS refactoring nor introduce a refactoring tool support for ships between model elements. To identify refactoring patterns these approaches. In this paper, we focus on these two points. and bad smells for an executable design artifact, we have to 3 know the meta-model used to build structures of this type of Similarly, we have to define bad smells for MAS develop- artifacts. ment. Based on our experiences on the MAS development, we In Seagent framework, the hierarchical task network - HTN have identified following bad smells for plan level refactoring: formalism [23], [31] isis used used totobuild buildand andstore storeof agent Duplicated behaviour structure, execution decision in a plan, plans. Hence, the plan level refactoring patterns introduced in big behaviour, incoherent behaviour, redundant task group. this paper are dependent on the HTN formalism. ReSeagent Detailed definitions of all defined bad smells are accessible refactoring tool supports to apply the mechanics of these through the Seagent web site side1 . HTN dependent refactoring patterns on HTN plans that are developed through Seagent. The structure of the HTN meta C. Define the refactoring patterns that overcome the defined model used in the current Seagent version is shown in the bad smells for the target development artifact. figure 1. To develop a refactoring tool that can be used during MAS development, the refactoring patterns that define the order of the mechanics for each refactoring pattern has to be defined by a standard way. Each pattern includes pre-defined mechanics in order to overcome one or more bad smell(s). These mechanics has to be defined by using a machine understandable semantic. The tool uses the pre-defined machine understandable pattern definitions to overcome bad smells. In ReSeagent, we have defined seven refactoring patterns for HTN based plan refactoring. These plan level refactoring patterns that were defined based on our experiences with its initiator bad smell(s) are shown in table I. Figure 1. Seagent HTN Meta Model In HTN formalism, there are two kinds of task; complex task (we call behaviour) and primitive task (we call action). Complex tasks hold the structure of its sub-tasks and links between these tasks. Primitive tasks have directly executable Table I code. Information requirements of tasks are illustrated as pro- R EFACTORING PATTERNS AND THEIR INITIATOR BAD SMELLS IN THE visions. Outcomes are result states of tasks. Data is transferred PLAN LEVEL to other tasks through the several kinds of link. An inheritance link is used to transfer a provision of a parent complex task to a sub task. Disinheritance links are used to transfer outcomes of The detailed definitions of all refactoring patterns defined sub-tasks to parent complex task. And finally, the information are accessible on the refactoring patterns part of the Seagent flow between outcomes and provisions of the tasks in the same web side. level is provided by internal provision links. As an addition of the links come from the HTN formalism, there is one more IV. A H YBRID A PPROACH FOR D EFINITION OF type of link called order link in the Seagent behavioural PSM. R EFACTORING PATTRENS Order links do not pass any information between tasks. They To implement a refactoring tool, firstly the refactoring are used only to order the execution of tasks. techniques supported by the tool have to be defined in a usable form for the tool. We used a hybrid approach based B. Define the bad smells encountered during the development on the mechanisms used for defining transformation rules in of the artifacts specified in the previous step, the Model Driven Enginnering - MDE to define the refactoring tecniques mentioned in the previous section for our refactoring To make decision about applying refactoring patterns on an tool. MDE is a discipline in software engineering that relies on artifact, arfifact, we need to define the common design problems that models as first class entities and that aims to develop, maintain are encountered by developers during the system development and evolve software by performing model transformations process frequently. Fowler named these common problems [22], [25]. This section introduces our hybrid approach that is bad smells in [18] and introduced refactoring patterns to as bed based on the model transformation techniques [19] and used overcome these bad smells in software design. Each of the to define refactoring techniques in ReSeagent refactoring tool. defined refactoring patterns is introduced to overcome one or many bad smell(s). 1 http://etmen.ege.edu.tr/wiki/index.php/refactoring_agent_system 4 From the MDE perspective, a refactoring operation is a Because Becauseof of these thesehandicaps, handicaps,the thedeclerative declerativeapproach approachcannot cannot model transformation between the initial and the improved be be used used alone alone to to define define refactoring refactoring mechanics. mechanics Tosincedefine their models. Model is a structure of design artifacts in the refac- refactoring mechanics handicap mentioned as To above. rules, defineimperative refactoringormechanics hybrid toring context. Like each model transformation has some approaches should be as rules, imperative or used. hybrid approaches should be used. teransformation rules, each refactoring has some mechanics ReSeagent uses a hybrid approach that combines the advan- that achieve main goal of the refactoring by working together. tages of declarative and imperative rule definition approaches. It is is natural to think that the refactoring approaches and tools nature to The declarative side of this approach is achieved by using can be based on the model transformation approaches and Semantic Web Rule Language - SWRL3 . SWRL is a logic techniques. To develop a refactoring tool by using the model based rule language that supports defining rules on OWL transformation techniques, mechanics of refactorings should ontology models. Refactoring mechanics that extend the initial be defined as the transformation rules. In this manner, the models are defined as SWRL rules. Refactoring mechanics refactoring tool operates the refactoring mechanics that are defined using the HTN paradigm forms the imperative side of defined as transformation rules according to the refactoring our hybrid approach[31], [23]. pattern in order. This is not a new idea and there are some In this hybrid approach, each refactoring pattern is defined works about rule based refactoring in the literature such as [2], as an agent plan by using the HTN paradigm and each [24]. All of these works aim to define refactoring operations refactoring mechanic is implemented as an executable action by rules for their own target development sytle. in refactoring plans. Refactoring mechanics that extend the Transformation rules are the focal point for model trans- initial models are implemented as rule actions. Rule actions formation. The techniques and languages that are used to have the responsibility of operating a SWRL rule on the OWL identify these rules specify the maim characteristics of model model of the related Seagent plan. Refactoring mechanics that transformation. There are two main approaches to define change and/or remove the existing element in the initial model trasnformation rules; declarative declerative and imperative approaches are implemented as normal actions. Normal actions implement [12]. Declarative approaches (e.g., [1]) are attractive because change and removal remocal activities by means of Java code that particular services such as source model traversal, traceability handles the ontology explicitly. All of the actions that are management and automatic bidirectionality can be offered by implemented to realize the mechanics of a refactoring pattern an underlying reasoning engine. On the other hand, imperative compose a refactoring plan that achieves the main goal of the approaches (e.g., [27]) may be required to implement trans- refactoring pattern. Sequential execution of these actions is formations for which declarative approaches fail to guarantee controlled by the plan structure. their services. Especially when the application order of a set of Many different methods such as finite state machine can transformations needs to be controlled explicitly, an imperative be chosen to implement the imperative side of our hybrid approach is more appropriate thanks to its built-in notions of rule definition approach. However, defining each refactoring sequence, selection and iteration. pattern as an agent plan by using the HTN paradigm in In Seagent framework, plan models are stored in ontologies ReSeagent has some advantages listed below: that are built by using a description logic based language called • Simplicity: In Seagent, HTN paradigm is used for testing Web Ontology Language - OWL2 . Refactoring operations on and implementation of plans. Defining refactoring pat- these plan models can be considered as model transformations terns by using the same method simplifies the addition between initial plan ontologies and improved plan ontologies. of new refactoring patterns into the refactoring tool. So, a logic based declerative approach looks like appropriate • Reusability: HTN paradigm makes it possible to re- for building rules on the these models. A refactoring tool use other pre-defined plan structures in higher level plan that supports transformation between OWL ontologies using structures. Thanks to this, big refactorings can be simply logic based rules is useful for refactoring Seagent plan mod- implemented by re-using the pre-defined refactoring plans els. However, logic based rules are not enough for defining in a high level refactoring plan. refactoring mechanics because of the two handicaps of logic • Generality: Since the refactoring plans are agent plans based declarative approaches listed belove: like domain dependent user plans, these refactoring plans 1- Almost all of the logic languages such as Prolog have can also be refactored by applying refactoring plan(s) on been developed to extend their target models. By using these these plans. languages, new definitions can be made on the existent ele- The software architecture of ReSeagent that executes the refac- ments in the model. These languages do not support to remove toring patterns defined by our hybrid approach is explained in and change the existent elements in the model. Refactoring the following section. techniques require removing and changing of the existent elements in the model besides extending of the model. 2- Another handicap of the declerative approach for creating V. OVERAL S OFTWARE A RCHITECTURE OF R E S EAGENT transformation rules of refactorings is that the mechanics of ReSeagent refactoring tool was implemented as a plug-in on refactorings should be operate in sequence,. As mentioned the Seagent plan editor in the Seagent Development Environ- above, such a sequence operation can be controlled explictly ment - SDE like the refactoring support of Eclipse. ReSeagent by an imperative approach. gives suport for refactoring the plan models developed using 2 http://www.w3.org/TR/owl-features/ 3 http://www.w3.org/Submission/SWRL/ 5 SDE. The tool applies pre-defined refactoring patterns on the When the developer wants to start a refactoring operation related plan models to fulfill the refactoring requests received on a pre-defined plan model by using the refactoring plug- from Seagent plan editor. in of the Seagent plan editor, the initiator initiates an agent ReSeagent focuses on the refactoring of Seagent plans that plays the refactorer role and then passes the refactoring whose meta-model is clearly defined in Seagent. Additionally, request with its inputs to this refactorer agent. This agent maps since the software architecture of the tool is generic and it the received refactoring request to a suitable refactoring plan can be used for other planning systems whose meta-models situated in the plan library of the refactorer role, passes the are different or for other MAS design artifacts such as role, input values to this plan and executes it. During the plan goal and protocols. To add support for the artifacts that have execution, the input values of the refactoring requests are different meta-models, you have to add new refactoring plans passed to the sub-tasks of the plan via the links in the HTN that work on these meta-models into the refactorer role of structure. Then, these subtasks are executed depending on their ReSeagent, and make some additions to the initiator module order in the HTN structure. At the end of the plan, updated for initiating these new refactoring plans. plan models are returned to the initiator via the outcomes so that the results can be shown to the plan editor user. There can be many plans that realize the same refactoring operation by means of different ways. In such a situation, refactorer agent decides which refactoring plan has to be executed, according to inputs of the refactoring request and its internal state. This ability of the refactorer agent comes from Goal Mapping Engine in Seagent framework [17]. Thanks to this engine, Seagent agents can map a request to most suitable of many plans that achieve same goal in different ways. When this decision is made, some criteria such as inputs and outputs of the goal are considered by the Goal Mapping Engine. To add more than one refactoring plan that can realize the same refactoring operation to Seagent, it is enough to add correct mapping definitions to the knowledge base that are used for goal mapping (called Goal Mapping Ontology in Seagent) by Figure 2. Overal Software Architecture of ReSeagent the refactorer agent . Another responsibility of the initiator is passing the updated plan model(s) to the plan editor. Each refactoring plan has some outcomes that return the plan models that have been SDE has the responsibility of developing executable artifacts changed during the execution of the refactoring plan. There is such as plan models and goal models that can be executed by one outcome for each updated plan model. Initiator listens Seagent. For this purpose, SDE includes a plan and a goal to the planner of the refactorer agent after it initiates this editor for developing plan and goal models. It includes also a agent. When a PlanFinished event is thrown by the planner, testing tool called SeaUnit that verifies the functionalities of the initiator captures the updated plan models returned by the these development artifacts [16]. The overall software archi- outcomes and updates the model(s) in the plan editor. Hereby, tecture of ReSeagent and its dependencies on other modules new structures of the refactored plans are shown to the user. in SDE is shown in figure 2. ReSeagent consist of two sub-packages: refactoring ini- B. The Refactorer Role tiator and refactorer role. Refactoring initiator package was Refactorer role is a special role that has refactoring goals developed as a plug-in on the Seagent Plan Editor like the and refactoring plans that achieve these goals. This role can refactoring support of the well known Eclipse environment. It access plan models and action definitions in the system. This has the responsibilities of capturing the refactoring requests in role has the responsibility of applying plan level refactorings the plan editor, and initiating a refactoring operation for each on plan models during MAS development. of these refactoring requests. On the other hand, refactoring The refactorer role has refactoring goals that aim to apply a role holds the refactoring plans that are defined to provide the specific refactoring pattern on the Seagent plan models. Each mechanics of the refactorings. of these refactoring goals is achieved by one or more than one refactoring plans. So, the plan library of this role has to include at least one refactoring plan for each refactoring A. Refactoring Initiator pattern supported by ReSeagent tool. Refactoring initiator module of ReSeagent has a simple The current version of ReSeagent refactoring tool supports structure. This module has the responsibilities of capturing the following plan level refactoring patterns: Replace Tasks the refactoring requests from the plan editor and the user with a Task, Extract Behaviour, Behaviour to Plan, Extract preferences that are needed to fulfill these requests, and Plan. initiating a refactoring operation that is suitable for each of The detailed definitions of these refactoring plans can be the captured refactoring requests. found on the ReSeagent plans page of the Seagent web site. 6 Also, the OWL ontologies of the plans and Java codes of the to its sub-tasks. The plan has four actions. Each of these actions in these plans are downloadable on this page. actions achieves one of the mechanics of the Replace Tasks To give an an insight inside about the refactoring plans in ReSeagent, with a Task refactoring pattern. These actions which are called one of the refactoring patterns and the refactoring plan devel- ProvideProvisions and LinkOutcomes extend the model of the oped to achieve this refactoring in ReSeagent are explained in target plan structure by adding new links. Hence, each of these the following section. actions operates a SWRL rule to fulfill its responsibility. At the end of the plan execution, updated plan structure is returned Replace Tasks with a Task Refactoring and Its Implementation through an outcome. in ReSeagent VI. C ASE S TUDY Replace Tasks with a Task refactoring can be used in such a case: a functionality achieved by more than one tasks in a plan In this section, we introduce a case study that shows the structure can be achieved by only one task. This refactoring usage of our refactoring approach and ReSeagent refactoring removes these tasks from the plan structure and adds the new tool during the development of an actual MAS application task to the plan structure instead of the removed tasks. which is a conference management system that has been When the Redundant Task Group bad smell is realized in a developed by Seagent group. plan structure, the plan can be made more readable and simpler At the beginning of the development, we did not intervene by replacing the task group with a task that can achieve same the developers and let them to follow a sequential development functionality. process that does not impose evolutionary development. The To apply Replace Tasks with a Task refactoring, the new developers developed some of the goals such as “building the task has to have all of the provisions and outcomes of the program committee”, “sending call for paper” and “initiating tasks in the replaced task group that are linked to other tasks a conference” by applying the activities of their development in the plan structure. process. Mechanics: After developing a few of the system goals, some bad smells emerged in the design of the MAS that was developed: some 1) Remove the task group from the plan and add the new plan structures were duplicated in many plans. Furthermore, task. the developers were disappointed from the unmanageable 2) Find inheritance and provision-outcome links that are structures of the plans developed. attached to the provisions of the replaced tasks and We can give an example for these bad smells on a simple attach such links to the suitable provisions of the new plan structure from the conference management MAS. This task. plan structure achieves the “sending call for paper” goal of the 3) Find disinheritance and provision-outcome links that are “organization” role in this system. The initial HTN structure attached to the outcomes of the replaced tasks and attach of this plan that was obtained at the end of the sequential such links to the suitable outcomes of the new task. development process for “sending call for paper” goal is shown 4) Scan the provision-outcome links whose source or target in figure 4. task(s) is the reference to the replaced tasks. If there are such links, remove these links from the plan structure. Replace Tasks with a Task refactoring plan in ReSeagent refactoring tool is developed to realize the goal of “replacing a task group with a task that can fulfill same functionality” which is the aim of Replace Tasks with a Task refactoring pattern. HTN structure of this refactoring plan that implements the mechanics of Replace Tasks with a Task refactoring pattern is shown in figure 3. Figure 3. HTN structure of the Replace Tasks with a Task refactoring plan in ReSeagent Figure 4. The initial plan structure of the Send_CFP plan whosestructure The plan takes the name of the plan whose structure is is be The simple plan in the figure 4 takes the conference topic as refactored, the list of the tasks that are to be removed from a provision. This provision is passed to the “create suitable re- the plan structure and the task that is to be added into the searcher profile” action through an inheritance link. In this ac- plan structure as provisions, and transfers these provisions tion, a researcher profile object is created, the interested_topic 7 field of this profile is set with the topic that is received as a the conference topic according to the topic provision. The provision and this researcher profile is returned through the FindResearcherAgents plan was simply used in some other “OK” outcome. The other action called ”prepare and send plans in conference management system. The plan structure of query message to DF” takes the researcher profile, creates a our “send CFP” plan after the Extract Behaviour refactoring query message by using this profile and sends this message to is shown in figure 5. directory facilitator - DF. The “evaluate incoming researchers” After the refactoring operations on the developed plan struc- action has an external provision called researcherList. This tures, we obtained more readable and manageable plans for provision includes agent descriptions of the researcher agents the conference management system. Reusable plan structures that are sent by the DF. In this action, the description of the such as FindResearcherAgents obtained during the refactoring researcher agents are filtered according to the preferences and operations simplified to development of other system goals suitable researchers are selected. The final action called “send that include the goals achieved by these plans. CFP to selected researchers” has the responsibility of sending call for paper of the conference to selected researchers using VII. C ONCLUSION the agent descriptions that are received as a provision. Some tasks in the plan structure have a common goal In this paper, we define a development approach for refac- called “finding the suitable researcher agents” that should toring tools that can be used during the development of MASs. be tested independently from the other goals. This goal can To discuss this development approach on a refactoring tool also be part of the other plan structures such as “create implementation, a refactoring tool called ReSeagent has been program committee” in the system. This was a bad smell called implemented on the Seagent framework by following the Duplicated Behaviour Structure. So, we decided to collect process proposed by this approach. This tool supports the the actions called CreateResearcherProfile, SendResearcher- manual application of pre-defined refactoring patterns stored QueryToDFand EvaluateResearcherAgentsinto a new plan as agent plans on Seagent plan models during the development that achieves the common goal by applying Extract Be- activities. So far, ReSeagent refactoring tool was used in the haviourrefactoring on these actions. development of the several MAS applications such as e-barter To initiate anExtract Behaviourrefactoring operation on and conference management systems developed by the Seagent these three actions, we selected these actions and right clicked group. The experiences we obtained during the development of the mouse. In the opened menu, we chose the Refactor — these systems show that ReSeagent refactoring tool facilitates > Extract Behaviour as shown in figure 4. Then, a window evolutionary MAS development by simplifying the refactoring releated with the Extract Behaviourrefactoring appeared on process. the screen. This window had three spaces that had to be set by the input values of the plan. These values were plan name, R EFERENCES tasks list and new task. When we set all of the spaces by values [1] David H. Akehurst and Stuart J. H. Kent. A Relational Approach to and then clicked to the start button, the refactoring operation Defining Transformations in a Metamodel. In The Unified Modeling was initiated. After, a short duration, the improved structure Language: Model Engineeing, Concepts, and Tools, volume 2460 of of the plan appeared in the Seagent plan editor. Lecture notes in computer science. Springer, 2002. [2] Joachim Baumeister and Dietmar Seipel. Verification and refactoring of ontologies with rules. In Steffen Staab and Vojtech Svatek, editors, EKAW, volume 4248 of Lecture Notes in Computer Science, pages 82– 95. Springer, 2006. [3] Kent Beck and Cynthia Andres. Extreme Programming Explained: Embrace Change (2nd Edition). Addison-Wesley Professional, 2004. [4] Carole Bernon, Valérie Camps, Marie P. Gleizes, and Gauthier Picard. Engineering Adaptive Multi-Agent Systems: The ADELFE Methodol- ogy . In Brian H. Sellers and Paolo Giorgini, editors, Agent-Oriented Methodologies, pages 172–202. Idea Group Pub, NY, USA, juin. [5] Paolo Bresciani, Anna Perini, Paolo Giorgini, Fausto Giunchiglia, and John Mylopoulos. Tropos: An agent-oriented software development methodology. Autonomous Agents and Multi-Agent Systems, 8(3):203– 236, 2004. [6] G. Caire, M. Cossentino, A. Negri, A. Poggi, and P. Turci. Multi-agent systems implementation and testing. In From Agent Theory to Agent Implementation, Fourth International Symposium (AT2AI-4), 2004. [7] L. Cernuzzi, M. Cossentino, and F. Zambonell. Process models for agent-based development. Journal of Engineering Applications of Artificial Intelligence, 18 (2), 2005. [8] A. Chella, M. Cossentino, L. Sabatucci, and V. Seidita. From passi to agile passi: Tailoring a design process to meet new needs. In IEEE/WIC/ACM International Joint Conference on Intelligent Agent Figure 5. Final structure of the Send_CFP plan Technology (IAT-04), 2004. [9] Neil Clynch and Rem Collier. Sadaam: Software agent development an agile methodology. In Proceedings of the Workshop of Languages, At the end of the Extract Behaviour refactoring, we obtained methodologies, and Development tools for multi-agent systems, 2007. a new plan called FindResearcherAgents that can be re-used [10] Massimo Cossentino, Luca Sabatucci, and Antonio Chella. Patterns reuse in the passi methodology. In Proceedings of the Fourth Interna- in the other plan structures. This plan has the responsibility tional Workshop Engineering Societies in the Agents World (ESAW’03, of finding agent descriptions of the researchers that work on pages 29–31. Springer-Verlag, 2003. 8 [11] Massimo Cossentino and Valeria Seidita. Composition of a new process to meet agile needs using method engineering. In SELMAS, pages 36– 51, 2004. [12] Krzysztof Czarnecki and Simon Helsen. Classification of model transfor- mation approaches. In OOPSLA-03 Workshop on Generative Techniques in the Context of Model-Driven Architecture, 2003. [13] DeLoach S. A. Multiagent Systems Engineering A Methodology and Language for Designing Agent Systems. In Proc. of Agent Oriented Information Systems, pages 45–57, 1999. [14] Oguz Dikenelli, R. C. Erdur, O. Gumus, E. E. Ekinci, O. Gurcan, G. Kardas, Inanc Seylan, and Ali Murat Tiryaki. Seagent: a platform for developing semantic web based multi agent systems. In AAMAS ’05: Proceedings of the fourth international joint conference on Autonomous agents and multiagent systems, pages 1271–1272, New York, NY, USA, 2005. ACM Press. [15] Oguz Dikenelli, Riza Cenk Erdur, Geylani Kardas, Ozgr Gumus, Inanc Seylan, Onder Gurcan, Ali Murat Tiryaki, and Erdem Eser Ekinci. Developing multi agent systems on semantic web environment using seagent platform. In Engineering Societies in the Agents World VI, volume 3963 of Lecture Notes in Computer Science, pages 1–13. Springer, 2006. [16] Erdem Eser Ekinci, Ali Murat Tiryaki, and Oguz Dikenelli. Goal oriented agent testing revisited. In Agent Oriented Software Engineering 2008. Springer Verlag, 2008. [17] Erdem Eser Ekinci, Ali Murat Tiryaki, Onder Gurcan, and Oguz Dikenelli. A planner infrastructure for semantic web enabled agents. In OTM Workshops, volume 4805 of Lecture Notes in Computer Science, pages 95–104, Vilamoura, Algarve, Portugal, 2007. Springer. [18] Martin Fowler. Refactoring: Improving the Design of Existing Code. Addison-Wesley, Boston, MA, USA, 1999. [19] Anneke Kleppe, Jos Warmer, and Wim Bast. MDA Explained: The Model Driven Architecture–Practice and Promise. Addison-Wesley Professional, April 2003. [20] Holger Knublauch. Extreme programming of multi-agent systems. In AAMAS ’02: Proceedings of the first international joint conference on Autonomous agents and multiagent systems, pages 704–711, New York, NY, USA, 2002. ACM Press. [21] Johannes Link and Peter Frolich. Unit Testing in Java: How Tests Drive the Code. Morgan Kaufmann Publishers Inc., San Francisco, CA, USA, 2003. [22] Tom Mens and Pieter Van Gorp. A taxonomy of model transformation. Electronic Notes in Theoretical Computer Science, 152:125–142, March 2006. [23] Massimo Paolucci, Dirk Kalp, Anandeep S. Pannu, Onn Shehory, and Katia Sycara. A planning component for retsina agents. In Lecture Notes in Artificial Intelligence, Intelligent Agents VI, 1999. [24] Ivan Porres. Rule-based update transformations and their application to model refactorings. Software and System Modeling, 4(4):368–385, 2005. [25] Shane Sendall and Wojtek Kozaczynski. Model transformation: The heart and soul of model-driven software development. IEEE Software, 20:42–45, 2003. [26] Rational Software. The rational unified process, 1998. [27] Jonathan Sprinkle, Aditya Agrawal, Tihamer Levendovszky, Feng Shi, and Gabor Karsai. Domain model translation using graph transforma- tions. In ECBS, pages 159–167. IEEE Computer Society, 2003. [28] Ali Murat Tiryaki, Erdem Eser Ekinci, and Oguz Dikenelli. Refactoring in multi agent system development. Lecture Notes in Artificial Intelli- gence, 5244:183–194, 2008. [29] Ali Murat Tiryaki, Sibel Öztuna, Oguz Dikenelli, and Riza Cenk Erdur. Sunit: A unit testing framework for test driven development of multi- agent systems. In AOSE, volume 4405 of Lecture Notes in Computer Science, pages 156–173. Springer, 2006. [30] Cornelia Triebig and Franziska Klugl. Refactoring of agent-based simulation models. In Multikonferenz Wirtschaftsinformatik, 2008. [31] M. Williamson, K. Decker, and K. Sycara. Unified information and control flow in hierarchical task networks. In Theories of Action, Planning, and Robot Control: Bridging the Gap: Proceedings of the 1996 AAAI Workshop, pages 142–150, Menlo Park, California, 1996. AAAI Press. [32] Franco Zambonelli, Nicholas R. Jennings, and Michael Wooldridge. Developing multiagent systems: The gaia methodology. ACM Trans. Softw. Eng. Methodol., 12(3):317–370, 2003. [33] Franco Zambonelli and Andrea Omicini. Challenges and research directions in agent-oriented software engineering. Autonomous Agents and Multi-Agent Systems, 9(3):253–283, 2004.