-Nowadays, Aspect-Oriented programming is used benefits of the latter one, can be a very long and expensive for industrial software systems. However, many useful Object- job. It could also produce human-related mistakes. Therefore, Oriented systems have been developed and are still in use and several approaches have been proposed to assist refactoring apamraadnigumal tpoorAtinspgecotf-Obriigenptreodje(cAtsO)froomne,Ombjaekcitn-Ogrtiehnetemd o(sOtOo)f systems, from detecting the portions of code that need to be Design Patterns (DP), may prove a costly and time-consuming improved [8]-[11], to carry out some transformation on the process. This paper proposes a practical approach for auto- code [12], [13]. Moreover, extensive research work has been matically converting OO code to AO code, specifically for the performed for identifying design patterns [14], [15], which in implementation of DPs. The solution comprises two essential turn can help understand and improve the code. sAtOepsc:odreec.oTghneitnio,ntwoof etxhaemDpPlesinofODOP cSoidnegleatnodn caonndveCrsoimonpoisnittoe This paper proposes to assist finding the portions of code implementations on the Eclipse IDE with Eclipse Java Develop- that can be refactored and to transfom such found portions. ment Tools (JDT) are given. This allows us to save time and reduce errors, requiring human Index Terms-Design Patterns, Aspect-Oriented programming, intervention only for custom DPs. Given a software project, Recognition, Code replace, Separation of concerns our idea would be to have a tool able to:
I. INTRODUCTION
Design Patterns are an essential resource for developing
software systems of any size. The Design Patterns (DPs) are
the result of several years of fieldwork by senior software
engineers. They allow us to save time when designing an
application. However, many DPs have some crosscutting code
(e.g. DP Observer) or inject code in a different concern (e.g.
DP Singleton). Aspect-Oriented programming [
Design Patterns in AO systems [
Unfortunately, carrying out a refactoring from the OO to AO paradigm for medium or large software systems, for having the
Recognise the used DPs; Identify the classes the DP implements; Create the aspects related with the found DP; Delete the DP features from the OO version of the code and make appropriate changes to transform the code.
Therefore, a tool has been implemented with the said goals. The chosen development environment is Eclipse; this choice was motivated both for its widespread use in the enterprise environments and its internal flexible support. This allows building plugins that can easily perform parsing, checking and changing of the existing application code.
The use of aspects, hence the substantial replacement of crosscutting code, helps us to separate the domain concerns (business logic) from non-domain concerns (DP logic). However, some metadata, as Java annotations used to tag the class with the role for a specific DP will be used, as a kind of link for the two parts.
II. BACKGROUND CONCEPTS AND TOOLS
Design patterns are as the developer “utility knives”. They represent a set of best practices conceived by experienced OO software developers; and are solutions for general problems that happen during the software development. DPs describe a given scenario. For example, Singleton DP lets us use a single object in all the application; the developers know this technique with the name Singleton, independently from the language and platform used. Learning DPs helps the unexperienced developers to solve severals problems that otherwise would require the help of a senior software engineer.
IMethod represents a method; IField represents an attribute.
III. DP RECOGNITION AND CONVERSION PROCESS Each DP is described by: 1) name; 2) goal; 3) occurring problem; 4) solution offered; 5) effects.
In 1994 one of the most widespread used DP collection was published by four authors (also called “Gang of Four”).
It describes 23 patterns divided in three categories: Creational,
Structural and Behavioral patterns [
The recognition of design patterns implemented inside a
Java software system is carried out by observing the OO
features of a DP, hence looking for their typical “signature” in
a software system. One of the most used techniques consists
of analysing the classes and finding relationships such as
implements or extends [
The Aspect-Oriented Programming is a programming that of a DP. Every DP has a typical structure and we propose
paradigm that allows crosscutting concerns to be separated into to search for three features. Our recognition algorithm can
modules called aspects [
Eclipse Java Development Tools (JDT) is a tool suite for and DP Abstract Factory: we search an interface that have developing Java applications that can manipulate Java source a method whose return type is another interface. code. For this reason, JDT is a fundamental package of Eclipse Match some attributes and/or methods. Some DPs are IDE, and is used by several Eclipse plugins. characterized by the presence of some specific attributes
JDT package is made of three items: Java Models, Search or properties concerning the methods (or the construcEngine and Abstract Syntax Tree (AST). Our developed tool tors). E.g. DP Singleton has a private constructor, a is a plug-in that uses the Eclipse JDT for recognizing and private static attribute of the same type of the class editing the Java Eclipse projects and the Eclipse UI library for and a static method that returns an object of the same integrating with the IDE (context menu, message box, etc.). type of the class. A similar recognition can be done for
Eclipse UI gave us the project in a Java Model represen- Flyweight, Proxy, Object Pool (with a single Creator, like tation. We then can create the handles that can be attached Singleton). to the context menu in the Package Explorer of Eclipse. The The recognition process can be optimized if, during the handles catch the selected project (as IJavaProject) and pass process, each class will collect all the useful features for it to our (individual) DP converter. identification.
Within the Eclipse JDT library the following main classes More specifically, class SearchPattern has been used to have been used. perform searches. It takes as input a IJavaElement instance, IWorkspace represents Eclipse workspace; (which is an Eclipse supertype for IJavaProject, IMethod, IJavaProject represents a single Java project; IPackageFragment, IPackageFragmentRoot, IType) on which IPackageFragmentRoot represents a collection of re- a search has to be performed, and an int representing the sources (e.g. a folder or a library); matching mode (e.g. we could be searching for the iniIPackageFragment represents a sub-package inside a tialisation of a reference or the use of a reference, in the project; method body). Class SearchRequestor holds found items, and ICompilationUnit represents a file with Java source code; interface IJavaSearchScope define where the search should be IType represents a class; performed.
To convert OO design patterns into AO versions, we proceed in two stages:
Deleting the OO features related to the design patterns and/or reshaping of classes, attributes and methods; Creating the aspects.
After having recognized all the involved different classes of a project in Eclipse IDE, one or more “.aj” files implementing the DP are generated. They customize some different fields by using the class names. We use the Eclipse JDT to realize these stages. It allows us to write aspect code as simple text. Moreover, if we want to change an existing code we will use a more powerful tool that is the Abstract Syntax Tree (AST). This one parses the Java code in a XML tree and vice versa. This allows us to operate directly at the rows where we need the code changes.
IV. PROPOSED TOOLKIT
We created a toolkit that provides us with support for recognizing and converting DPs. The main steps are as follows: Analysis of the existing code and search classes that implements a given DP; Creation of the object that will perform the conversion; Creation of the aspects;
Changing the analysed code.
The toolkit declares the previous steps (abstract methods) and imposes them as a guide to the various refactoring. It applies the appropriate changes to the code.
The following describes the main classes implementing our toolbox. Class AspectPrototype supports the generation of an aspect, and holds the name of the aspects as well as the constituting portions, such as pointcuts, advices, etc., and the name of the file and package holding the code. The main methods for building such portions of code are: addAttribute(), addPointcut(), addAdvice(), addMethod(), and the last three take as input some strings representing name, parameters, and body.
Class AspectDesignerPattern is abstract and defines the methods that have to be implemented to recognise and convert a DP. Such a class holds the name of the classes, package, project, which have to be processed; moreover, it has methods searching features on the code, deleting portions of the found code, and creating portions of the new code. The main steps performed are described in more detail below.
Method createAspect() creates a custom aspect for the found class; uses AspectPrototype class having the internal elements expected for an aspect (pointcuts, advice, attributes, etc.) and writes the code in the .aj file into the indicated package.
Method replaceCode() deletes and/or modify all the portions of code characterizing a given DP in OO paradigm.
Class SingletonModifier is a specialisation for the namesake DP and recognises and convert a Singleton DP from OO to AO version. It holds an instance of AspectPrototype to generate the correspondent aspect; an instance of IMethod represents the constructor and another instance representing the getInstance() method typical of a Singleton. An instance of IField is also representative of the static attribute implemented in a Singleton class. The main methods implement the code for finding an implementation of Singleton within a class, to identify constructor and the static method, and to search and remove the invocation of static methods in classes using the Singleton.
Class SingletonHandler gives the possibility to connect the Eclipse environment with the proposed toolkit. It is an implementation of IObjectActionDelegate interface, having method run(), which will be called upon the click on the selected project. Such a class holds an instance representing the Eclipse shell, so that messages can be shown. The main additional method is responsible to call the methods provided by class SingletonModifier, in order to recognise and convert portions of code.
Class SingletonSearchEngine is a subclass of class AbstractSearchEngine and is used to find the calls to static methods.
Class CompositeModifier recognises and converts DP Composite from OO version to AO version. It mainly holds an instance of AspectPrototype in order to generate and write an appropriate aspect, realising the AO version, a reference to class playing as Component, a list of references for the classes playing as Child (Leaf) and the Composite. The main methods implement the logic to search for application classes implementing Composite DP.
V. RECOGNITION RULES
The Singleton DP is a successful DP and developers are using it regularly. Now, our application will be concerned with the recognition and rewriting of the code, so that the AO version will be produced. In the recognition process, our algorithm consider three features that distinguish the DP Singleton, as follows.
It exists a single private constructor; it exists a public static method that returns some object having the same type as the hosting class; it exists a private static attribute of the same type of the hosting class.
If a class satisfies the previous conditions, this will be represented as an instance of SingletonModifier, which implements the functionality of the abstract class AspectDesignerPattern.
Code in Listing 1 shows the main steps of the identification.
Then, once the class has been identified, it is constructed the relative aspect and replaced its code. In the end, the old parts of a Singleton class are deleted, i.e. the attributes and methods typical of the DP, and then the aj file is written.
After conversion of a Singleton class MyClass, all calls like
MyClass uniqueObject = MyClass.getInstance(); will be replaced by: MyClass uniqueObject = new MyClass();
The client will see MyClass as a usual class (not a Singleton DP), however all the instantiations return the same the interface and all classes recognized will be stored in an } } } } instance of MyClass. public final class SingletonModifier extends
AspectDesignerPattern { private static IMethod getOnlyPrivateConstructor(
IMethod[] methods) throws JavaModelException { int numOfPrivateConstructors = 0; int privateConstructorsIndex = -1; for (int i=0; i < methods.length; i++) if (methods[i].isConstructor() &&
Flags.isPrivate(methods[i].getFlags())) { numOfPrivateConstructors++; privateConstructorsIndex = i; } if (numOfPrivateConstructors != 1) return null; return methods[privateConstructorsIndex]; private static IMethod getInstanceMethod(
IMethod[] methods, String className) throws
JavaModelException { for (int i=0; i < methods.length; i++) if (methods[i].getReturnType().
compareTo("Q"+className+";") == 0 && Flags.isPublic(methods[i].getFlags()) && Flags.isStatic(methods[i].getFlags())) return methods[i]; return null; private static IField getInstanceAttribute( IField[] fields, String className) throws
JavaModelException { for (int i=0; i < fields.length; i++) if (fields[i].getTypeSignature().
compareTo("Q"+className+";") == 0 && Flags.isStatic(fields[i].getFlags())) return fields[i]; return null; class, as a class implementing the Component interface.
As for Singleton recognition, if a group of classes implement a specific interface that satisfies the previous conditions, instance of CompositeModifier.
Code in Listing 2 shows the implementation of the above. public final class CompositeModifier extends
AspectDesignerPattern { public static AspectDesignerPattern[] getDesignerPattern(
IJavaProject prj) { ArrayList<IType> leaves = new ArrayList<IType>(); ArrayList<IType> composites = new ArrayList<IType>(); Vector<Composite> compositeDP = new Vector<Composite>(); Hashtable<IType,IField> c=new Hashtable<IType,IField>(); if (prj == null) return null; ArrayList<IType> listInterface = new ArrayList<IType>(); IPackageFragment[] pks = prj.getPackageFragments(); for (IPackageFragment pack : pks) for (ICompilationUnit jf : pack.getCompilationUnits()) for (IType classStub : jf.getTypes()) if (Flags.isInterface(classStub.getFlags())) listInterface.add(classStub); AspectSearchEngine se = new AspectSearchEngine(prj); for (IType intf : listInterface) { se.search(intf, IJavaSearchConstants.IMPLEMENTORS, SearchPattern.R_ERASURE_MATCH | SearchPattern.R_CASE_SENSITIVE); Reference[] matches = se.getReferences(); if (matches.length == 0) continue; Vector<IType> listType = new Vector<IType>(Arrays.asList(se.getUsingType(matches))); Iterator<IType> listTypeIterator = listType.iterator(); while (listTypeIterator.hasNext()) { IType classStub = listTypeIterator.next(); boolean subjFound = false; IField[] attributes = classStub.getFields(); for (IField a : attributes) if (Composite.isDynamicList(a.getTypeSignature(),
intf.getElementName())) { composites.add(classStub); listTypeIterator.remove(); c.put(classStub, a); subjFound = true; break; } if (!subjFound) { leaves.add(classStub); listTypeIterator.remove(); } } if (leaves.size() > 0) compositeDP.add(new Composite(prj, intf, composites, leaves, c)); } AspectDesignerPattern[] adp = new AspectDesignerPattern[compositeDP.size()]; compositeDP.toArray(adp); return adp; } }
After conversion, the list of Component instances hold
VI. CONCLUSION
After years of research, AOP begins to propose itself as a valid means for developing applications outside the academic context. However, for the last twenty years the development
The Composite DP allows developers to use a set of items as a single object through the implementation of a common interface. Every object can be a node (the element have a pointer to another Composite object) or a leaf (object that implements the concrete operation). For example: the I/O disk operation over folder or file can be processed in the same way (e.g. move, copy and rename). The folder contains one or more folders or files. The client (e.g. the explorer GUI) will Component). tion of DP, we:
As performed for the Singleton DP, our algorithm consider three feature that distinguish the Composite DP. For recogniget all interfaces of a project; handle the folder (Composite) and the files (Leaf) likewise (as inside the Composite class will be removed. for each interface, search all classes that implements it; of software systems has undergone exponential growth that obtained the class list of each interface, search: (i) the does not permit an immediate exchange of technology. Our Composite class as a class that holds a list of type work provides an approach that identifies parts of the code that can be refactored from OO to AO version. The already well-formed and strong applications, thanks to twenty years of experience on DPs, give us the opportunity to pass to the aspect version. It maintains the advantages of the latter and is enriched by the AO modularity.
An important step during refactoring is the recognition of the used DPs and the identification of associated classes. We have identified three categories of recognition based on some typical signatures of DP.
Our future work aims at collecting the features of all DPs at once from the application under analysis and recognise one or more DPs on the basis of the presence of all the characteristics required by the DP. Only after recognition of all the DPs the creation of the aspect code and the replacement of the OO code will be performed.