Semi-automatic Refactoring to Aspect-oriented Platform

Transcription

1 Semi-automatic Refactoring to Aspect-oriented Platform Pipík Roman, Ivan Polášek Faculty of Informatics and Information Technology, Slovak University of Technology in Bratislava, Slovakia Refactoring is necessary in large software projects and an aspect-oriented approach can help to maintain concerns in the source code. While tools for object-oriented refactoring are the usual part of development environments, support for aspect-oriented refactoring is minimal. We analyzed objectoriented bad smells applicable for an aspect-oriented approach and propose a method for the detection of crosscutting concerns and consecutive refactoring. I. INTRODUCTION An Aspect-oriented (AO) approach in refactoring can provide better results than an object-oriented (OO) approach due to its centralization of concern behavior. Concerns become separate units to the original code and they are bounded only through the information provided in the aspect. In object-oriented refactoring, concerns can be separated in the form of class but require hardwired binding (through method invocations) at all points of the application of the concern. Current projects are mostly created with OO approach. To provide semi-automatic refactoring from OO to AO platform we have to detect aspects from the code to support their future automated extractions. For this purpose we analyzed bad smells in OO code that can be extracted into an AO program. II. RELATED WORKS A. Manual refactoring Laddad [1] describes specifics of AO refactoring and the aspect effects to concerned parts of a program (method, class, package) through lexical pointcuts within() and withincode(). Binding between aspects and classes should be minimized. Aspect should not use private parts of the classes if not necessary. Refactored aspects should be placed close to affected classes. Aspects should be defined in same source file or package as affected classes. Monteiro [2] analyzed the process of refactoring OO code into AO paradigm and defines the list of transformations required for refactoring. Monteiro describes transformations with a typical situation, recommended action, motivation and mechanism of the transformation. Transformations are used to extract the crosscutting concern, restructure or generalize the aspect. Cole [3] uses a similar approach at a lower level and describes 33 transformations with preconditions. Refactoring of the exception handling is analyzed in [4] and there are some other instructive works [5], [6], [7] in this domain. We have published particular papers about searching smells with the rule based system [22], similarity scoring and bit-vector algorithms [21], about UML model refactoring [20] and tagging information and knowledge in the source code [23] (also about authors, patterns and antipatterns). B. Aspect mining Tonella et al. [9] evaluated approaches to aspect discovery and we summarized it into Table I. Approach Analysis of recurring patterns Formal concept analysis Processing natural language of Detection of unique methods Grouping of related methods Branching analysis Detection of duplicated code Program analysis in time TABLE I. APPROACHES TO ASPECT DISCOVERY Description Evaluates relations between method calls to find common patterns. Repeated patterns can be classified as aspects. Used in DynAMiT [8]. Data mining approach based on finding relations between concepts. Concepts are lexically defined uses naming information to define concept. Used in Dynamo [9] and DelfSTof [10]. Combines formal concept analysis with information from natural language. Uses existing data from natural language concepts to group related concerns in the program. Kellens et al. [11] observe that crosscutting concerns can be implemented as single entities called from different parts of the system. For example logger object representing logging concern. In the beginning every method is in its own group. Evaluates the distance between methods based on metric (name similarity, class) and group methods together. Similar to Formal concept analysis when grouping is based on similar concepts. Marin et al. [12] use metric number of code parts calling method to find scattered concerns Shepherd et al. [13] use a program dependency graph to find duplicated code. Approach is comparable to Analysis of recurring patterns. This approach was not part of Tonellas evaluation. Breu et al. [14] use information of versioning system to find differences between versions. As they describe, one change in the repository often contains crosscutting concern and is realized by calling one method from different parts of code. C. Automatic extraction of aspects Tonella et al. [15] also propose a tool for automatic refactoring as rules in TXL transformation language. The tool should support these rules (refactorings): Extraction of a program at the beginning or end of the method.

2 Extraction of a program used always before or after some called method Extraction of a program with a condition Extraction of a program before a return statement Extraction of an enclosing object III. OUR SOLUTION After analyzing related works we decided to use the detection of duplicated code through a Program dependency graph. This approach requires granularity to manipulate source code for refactoring and it is easy to extract smell into the aspect. Duplicated code is converted into the aspect advice and dependencies are used to construct a point-cut. A. Evaluated bad smells We have evaluated OO bad smells in the code and decided to focus on the smell of Duplicated code and the smell of Double personality. These smells are complementary to each other. Duplicated code can be used to identify scattered concerns in general while Double personality can be used to identify intertwined concerns in general. Thus by refactoring duplicated code we can indirectly solve the additional smells like Long method, Shotgun surgery and the other smells that are caused by scattered concerns. By refactoring double personality we can indirectly solve the additional smells like Long method, Divergent change and the others that are caused by intertwined code. B. Method definition Dependencies can be used in the extraction phase to create required point-cuts. We require the use of Abstract Syntax Tree (AST) to traverse the source code and realize changes in the source code at the level of the statements. A selected approach provides this level of granularity. In the phase of AST initialization we wrap AST provided by the development environment with custom structures. AST and wrapped AST can be traversed through the Visitor pattern. Wrapper structures have the lowest granularity of the statements. C. Finding duplicated code We designed the algorithm based on duplication analysis with the program dependency graph. In the first step we find read and written variables for every local method. This will give us better understanding of dependencies of local methods because local methods can use local values without passing through the method call. Method called on object variable is taken as a read and write operation of the object. In the second step we associate each statement of the program with the value. When every statement has an associated value we use a standard algorithm for finding common sub-trees [16], [17]. Evaluation of the statement contains information associated with the dependencies of the statement. The value of the statement is defined as follows: 1. Value is the array. 2. Array can be concatenated. 3. Each part of an array represents some attribute. For example: value[0] represents a type of statement, value[1] represents the signature of the statement. 4. Value is dependent on the called method names. 5. Value must represent dependencies between the statements and hierarchical dependencies in AST. 6. Value should not depend on variable names. 7. Value should be same for similar statements. For example for and while statements can represent the same logic 8. Value is dependent on the operators in the expressions. In some programming languages, operators are represented as standard methods, so this is similar to the fourth rule. Statement i+=2 and i=i+2 would evaluate into the same value. By evaluating statements we can: Abstract information from the syntax tree. Lower analysis complexity. Enable duplication analysis through overall values. Enable comparing statements by characteristic. In Figure 1 we show the values for the statement, variable and statement dependencies. When the statement dependencies are resolved, we append them to the values. When statement B depends on the code in statement A, we can append the value of statement B to the value of statement A. We call this output (after) dependencies. Appending the value of statement A to the value of statement B is called input (before) dependencies. Appending dependencies cause the accumulation of dependencies at the beginning or end of the method, making identification and extraction of duplicated code harder. Because of this, input dependency is suited to extract code with before execution advice for the method containing statements while output dependency is suited to extract code with after execution advice for the method. Final values are in Figure 1. Counter c = new Counter(0); void count(int i) { if (i < 0) { if par(int) < lit(int), read i { exp par(int) = lit(int), write i i = 0; exp par(int) =par(int)+lit(1), read i, write i i=i+1; exp fld(counter).increment(), read c, write c c.increment(); System.out.println("i="+i+",c="+c); exp System.out.println(lit(String),par(int),lit(String),fl d(counter)) read i,c Figure 1. Statement values (dependency on variables is not part of value yet)

3 Comparing and creating text is demanding on performance and memory requirements. We can optimize performance by replacing text with numeric hash values and replacing concatenation with addition and multiplication. This can cause false positive matches. To remove false positive matches we perform a nonoptimized duplication analysis only for the statements found as duplicates. An example evaluated with hashes is shown at Figure 2. For hashing we reuse a hashing algorithm from Java String object. Counter c = new Counter(0); void count(int i) { if (i < 0) { i = 0; C i = i + 1; ECF26D3C c.increment(); System.out.println("i = " B2DF4E2B + i + ", c = " + c); Figure 2. Evaluation by hash values D. Extracting duplicated code Complexity of duplicated code is increasing with the number of dependencies for the statement. When the statement has no dependencies, it can be extracted with before execution advice for its enclosing method. From Figure 1 we can extract if statement with body and c.increment() statement in this way. When the statement has one dependency - method call, it can be extracted with after call advice for the called method. More complex situations are not extractable now. Parameter names and literal values are ignored and we have to parameterize the resulting advice to use different literals and parameters. When a field is not extracted from a class, it cannot be renamed to match other fields. For example field i from Figure 1 cannot be renamed to real and vice versa. There are various problems: Naming of a field would make no sense in some cases, or a name would be too generalized for other uses in a class. When two duplicated parts are the same but they use a different field in the same class, fields cannot be named the same. This requires uniform access to class fields through a common interface and again parameterization of the resulting advice. Requirements prevent us from creating one point-cut and advice. We have to create parameterized method implementing advice and create point-cut and advice for each duplicated statement. Advice simply calls method implementing advice with parameters specified for its point-cut. Also we have to use inter-type declarations to introduce getters and setters for the fields into classes with duplicated statements. In Figure 3 we show the skeleton of the created aspect. The skeleton contains: 0 A947B2A7 Declaration of a common interface for all classes containing duplicated code. Implementation of an interface for each class. Getters and setters require a name parameter to differentiate use of fields in duplications in the same class. Point-cut for every duplicate obtaining a class as a common interface and other parameters. Advice calling parameterized method specifying what are the real parameter names and real literals for each point-cut. Method implementing parameterized version of advice. public aspect CountingAspect {... private interface { public int getc(string realname); public void setc(string realname, int c); declare parents: EvaluationExample implements ; public int EvaluationExample.getC( String realname) { if (realname.equals("c")) { return this.c; if (realname.equals("real")) { return this.real; throw new AssertionError("Failed to resolve variable" + realname); public void EvaluationExample.setC( String realname, Counter c) { if (realname.equals("c")) { this.c = c; return; if (realname.equals("real")) { this.real = c; return; throw new AssertionError("Failed to resolve variable" + realname); public pointcut pointcut1( execution( void count(..)) && within(evaluationexample) && this(objectwithaspectinterface);

4 ... public pointcut pointcut2( execution( void countsheep(..)) && within(evaluationexample) && this(objectwithaspectinterface); before( pointcut1(objectwithaspectinterface){ adviceimplementation( objectwithaspectinterface, "c" /* other real field names and literal values*/); before( objectwithaspectinterface) : pointcut2(objectwithaspectinterface){ adviceimplementation( objectwithaspectinterface, "real" /* other real field names and literal values*/); Interface with a low score is ignored. The other interfaces are marked as secondary. If the highest score is 1.3 times higher than the second score, we mark the interface as the primary. When the primary interface is found, all secondary interfaces are marked as the smell and should be extracted into the aspect. F. Prototype as an evaluation of the method The Prototype is the plugin into the Eclipse IDE and uses standard features. Code markers are used to show identified smells. Smell can be solved through a quick fix feature. Smells can be searched manually by selecting source file(s) and pushing the analyze source button or automatically with each build by using project natures. private void adviceimplementation( objectwithaspectinterface, String realcname /* other fields and literals*/) { /* Copied implementation from one duplication. Fields and literals are parameterized */ Figure 3. Created aspect skeleton E. Finding double personality Double personality smell can be found by interfaces of a class. Interface with more accesses to class fields is primary to the class. Each interface is assigned a score. The score is calculated by a function score in (1) where: the score is the final score of the interface fieldcount is the number of fields that the interface reads or writes incount is the number of methods with input dependendency on the field incoef is the coefficient for the input dependency outcount is the number of methods with an output dependency on the field outcoef is the coefficient for the output dependency fields are all fields used in the methods of the interface Figure 4. Identified smell with quick fix solution IV. FUTURE WORK Currently we are searching for duplicates only at the class level. No inter class duplication is found. This can be solved by enlarging the evaluated tree through the selection of processed files. Using output dependencies we can extract code with other types of point-cuts. Currently we are using only input dependencies for duplication analysis and extraction. Parameterization of aspect is problematic, since the created aspect is large, contains point-cut and advice for each duplicated code. This can be more problematic than the original duplications. On the other hand with parameterization we generalized the aspect into one advice implementation for different contexts. Also using a point-cut and advice for every duplicated code is consistent when multiple duplications are found in one method and advice should be invoked multiple times. Addition of other contexts is simple. We plan to compare the effectiveness with similar works [18] or interconnect them and use modern and fast algorithms [19] to cluster duplicate code.

5 Extraction of double personality smell has not been defined. It has to use inter-type declarations to introduce and implement secondary interfaces. ACKNOWLEDGMENT This work was partially supported by the grants VG1/1221/12, and it is the partial result of the Research & Development Operational Programme for the project Research of methods for acquisition, analysis and personalized conveying of information and knowledge, ITMS , co-funded by the ERDF. REFERENCES [1] Laddad R., Aspect-Oriented Refactoring, part 1 and 2, The Server Side, 2003, [2] Monteiro M., Refactorings to Evolve Object-Oriented Systems with Aspect-Oriented Concepts, Doctoral thesis, Universidad do Minho, 2005 [3] Cole L., Borba P., Deriving Refactorings for AspectJ, Proceedings of the 4 th international conference on Aspect-oriented software development, 2005 [4] Filho F.C., Garcia A., Rubira C.M.F., Extracting Error Handling to Aspects: A Cookbook, ICSM, 2007, page [5] Rura S., Lerner B., A basis for AspectJ refactoring, GPCE, 2004 [6] Iwamoto M., Zhao J., Refactoring Aspect-oriented programs, 2003 [7] Valente M.T.O., Malta M.N., Object-oriented transformations for extracting aspects, Information and Software Technology Journal vol [8] Breu S., Krinke J., Aspect mining using event traces, Automated Software Engineering (ASE), 2004 [9] Tonella P., Ceccato M., Aspect mining through the formal concept analysis of execution traces, Working Conference of Reverse Engineering (WCRE), 2004 [10] Marin M., van Deuren A., Moonen L., Identifying aspects using fan-in analysis, Working Conference on Reverse Engineering (WCRE), 2004 [11] Kellens A., Mens K., Tonella P., A Survey of Automated Code- Level Aspect Mining Techniques, Transactions on aspect-oriented software development IV, ISBN-10: , ISBN-13: [12] Marin M., van Deuren A., Moonen L., Identifying aspects using fan-in analysis, Working Conference on Reverse Engineering (WCRE), 2004 [13] Shepherd D., Gibson E., Pollock L., Design and evaluation of an automated mining tool, International conference on Software Engineering Research and Practice, 2004 [14] Breu S., Zimmermann T., Linding C., Mining Eclipse for Cross- Cutting Concerns, Proceedings of the international workshop on Mining software, 2006 [15] Binkley D., Ceccato M., Harman M., Ricca F., Tonella P., Automated Refactoring of Object [16] Grossi R., On finding common subtrees, Dipartimento di Informatica, Universita di Piss, Theory of Computer Science vol. 108, page , 1992 [17] Valiente G, Tree Isomorphism and Related Problems, Technical University of Catalonia, c.pdf, [18] Súkeník, J., Lacko, P., Duplicated Code Detection (in Slovak), 7th Workshop on Intelligent and Knowledge Oriented Technologies Proceedings, November 22-23, 2012, STU Bratislava, ISBN , 2012, pp [19] Kovacs, L., Bednarik, L., Parameter optimization for BIRCH preclustering algorithm, 12th International Symposium on Computational Intelligence and Informatics (CINTI 2011), Budapest, Nov. 2011, pp [20] Štolc M., Polášek I., A Visual based Framework for the Model Refactoring Techniques, SAMI 2010, 8th IEEE International Symposium on Applied Machine Intelligence and Informatics, January 28-30, 2010, Herľany, Slovak Republik, IEEE, 2010, ISBN , pp [21] Polášek I., Líška P., Kelemen J., Lang J., On Extended Similarity Scoring and Bit-vector Algorithms for Design Smell Detection, INES 2012, IEEE 16th International Conference on Intelligent Engineering Systems Proceedings, June 13-15, 2012 Lisbon, Portugal, IEEE, 2012, ISBN , pp [22] Polášek I., Snopko S., Kapustík I., Automatic identification of the anti-patterns using the rule-based approach, SISY 2012, IEEE 10th Jubilee International Symposium on Intelligent Systems and Informatics, September 20-22, 2012 Subotica, Serbia, IEEE, 2012, ISBN , pp [23] Polášek I., Ruttkay-Nedecký I., Ruttkay-Nedecký P., Tóth T., Černík A., Dušek P., Information and Knowledge Retrieval within Software Projects and their Graphical Representation for Collaborative Programming, Acta Polytechnica Hungarica, ISSN , Vol. 10, No. 2 (2013), pp