     M. Kleyman    michael.kleyman@gmail.com S. Tyszberowicz       tyshbe@tau.ac.il A. Yehudai    amiramy@tau.ac.il                    !   "       # $  %     & $ ’   $      ()*        + $  ,       ) $   $           $ )   $     $  -         .   /01           /0 $     2    2       $              &       $ $"     /0   &     + $         The agile development approach welcomes changing requirements even late in the development process [1]. Refactoring is a major technique used to cope with changes. It is a process and a set of techniques to reorganize code while preserving the external behavior of a working system [2]. Good modularity is characterized by weak coupling and strong cohesion. The object+oriented classes provide good modularity. However, some behavior cannot be localized in a single class, or even in few classes ( ), and some classes handle more than one concern (). Aspect+oriented programming (AOP) [3] has been proposed as a powerful programming paradigm that helps modularize crosscutting concerns (behavior that cuts across the typical divisions of responsibility, such as logging). AOP captures the crosscutting concerns and encapsulates them in a single module ─ an . An aspect contains , which are code fragments that are inserted into other modules using a weaving mechanism. An advice modifies the behavior of the code or adds new behavior. It can be applied to " , points of interest in the flow of a program, such as object instantiation, method call, variable access, etc. An advice code can be specified to be executed before or after the computation defined by a join point, or it even can replace it completely. An expression that specifies a set of join points is called a . AspectJ [3] is the most popular aspect+oriented extension to the Java programming language. AOP greatly improves the programmers' ability to quickly introduce changes to a software system. Sometimes, however, using AOP in production software is avoided, for several reasons. We have developed ACME (acronym for Automated Crosscutting Modification in Eclipse), a prototype tool that implements a refactoring process for cases when the AspectJ code should not remain in the system. It allows a programmer to automatically convert Java source code extended with AspectJ into pure Java code. ACME creates modular and readable Java code, as opposed to the bytecode produced by AspectJ. This paper is organized as follows. The motivation for developing ACME is explained in Section 2. Examples of supported transformations are shown in 2007 IEEE International Conference on Software – Science, Technology and Engineering 0-7695-3021-4/07 $25.00 © 2007 IEEE DOI 10.1109/.7 35 2007 IEEE International Conference on Software – Science, Technology and Engineering 0-7695-3021-4/07 $25.00 © 2007 IEEE DOI 10.1109/.7 35