Software Refactoring using New Architecture of Java Design Patterns

Software Refactoring using New Architecture of Java Design Patterns Norddin Habti, Prashant 1, 1 Departement d informatique et de recherche operationnelle, Universite de Montreal, Quebec, Canada (Dated: 11 décembre 2006) This project is an attempt to study and analyze software refactoring and see how it can be improved using common Design Pattern solutions. Design patterns have been extensively studied in the literature as patterns of proven solutions to problems in given context. They are abstractions of the solutions that occur frequently in software and hence can be used to a commonly occurring problem in software design. We propose a new architecture of a more efficient approach of using design patterns to improve refactoring and predict its utility over approaches using Eclipse and JEdit to give a better control and command over refactoring and explore new ideas in future scope of work. 1. PROJECT OBJECTIVE The objective of the project is to propose software refactoring using a new architecture of Java design patterns with integration of Expert Systems to automate the process and make it more efficient. We also propose the protocol to be adopted in the new architecture and predict its future comparison with other approaches like Eclipse and Jedit if the architecture is fully implemented with all functionality. Use of Artificial Intelligence techniques in such a scenario is emphasized. 2. PROJECT MOTIVATION AND SCOPE The motivation of the project to take software refactoring and design patterns stems from the following points : 1. To study and analyze software refactoring and design patterns and there use and drawbacks in Software Engineering. 2. To propose a new architecture and protocol for Java design patterns use and predict its utility and improvement over other tools qualitatively and quantitatively. 3. Explore a possible connection between artificial intelligence and software refactoring to automate and make the procedure efficient. The scope of the project is to study the basics of sofware refactoring and design patterns. We implement a refactoring tool to understand basic concepts of software refactoring and propose a new architecture of the use of design patterns and speculate the use of Expert Systems and Decision Support systems as artificial intelligence constructs in the application of design patterns to the code. 3. PROBLEM STATEMENT The problem which lead to the present work is summarized in following points : 1. The software changes frequently, so it becomes increasingly difficult to add new features and preserve the meaning of the modified code. 2. Restructuring often leads to loss of meaning of code, effort and time of the work. 3. So, there is need of reusing common patterns of design, where the implementations vary for refactoring purposes. In our case we defined an architecture to address above problems by using Expert Systems and Decision Support Systems. 4. INTRODUCTION Software refactoring has gained familiarity and popularity in recent times in the software engineering community. Due to the need to preserve the behavior of the code still to be able to maintain, modify, control and extend the code refactoring approaches has gained importance. Refactoring stems from a more general field of restructuring and re-engineering approaches with the basic aim of revitalizing the meaning, readability, comprehensibility and maintenance of the code keeping its behavior consistent. The modern approach of software refactoring originated from Opdyke s PhD thesis[1] where it is formally defined as the process of changing a [objectoriented] software system in such a way that it does not alter the external behavior of the code, yet improves its internal structure. In this project we propose to enhance the ability of software refactoring in an object oriented environment of Java technology using the common design patterns available in Java and propose to improve it to scale over present approaches in an architecture proposed for future work. A design patterns is a proven solution to a problem in a context and represent solutions to problems that arise when developing software within

2 a particular context. Although numerous tools related to refactoring exist, some apply design patterns in refactoring. Even these tools do not clearly specify where refactoring can be applied and when to apply appropriate design patterns[2]. This project studies briefly the ideas of software refactoring and design patterns individually and then proposes to use the best of both methods for effective code maintainability, understanding and effective reuse. The report is divided as follows : section 5 deals briefly about common concepts and reviews of software refactoring field, section 6 deals with a brief review of design patterns and their use in recent times in software engineering circles, section 7 deals with our proof of concept refactoring tool called Jtool which applies common Java design patterns called command patterns to refactor a test code, section 8 deals with limitations and scope of the tool with analysis of its functioning, section 9 deals with scope of future improvement of the tool and research work which can be taken in this regard and section 10 gives conclusion to the work. 5. BRIEF REVIEW OF SOFTWARE REFACTORING The field of software refactoring has sprung up since the early 90 s from the Phd thesis of Opdyke s [1] as discussed briefly in introduction. Refactoring is the process of rewriting a computer program or other material to improve its structure or readability, while explicitly preserving its meaning or behavior. Software in modern times are amenable to complexities beyond the capability of simple maintenance tasks hence there is a constant need for incremental improvement in the internal software quality keeping the behavior invariant under refactoring techniques[3]. Refactoring generally leads to extensibility, modularity, reusability, complexity, maintainability, efficiency of the code. In software engineering, the term refactoring means modifying source code without changing its external behavior, and is sometimes informally referred to as cleaning it up [4]. To focus on the structures in the software which need refactoring Beck has coined the term bad smells which are structures in the code that suggest (sometimes scream for) the possibility of refactoring[5] an example of a bad smell can be code duplication in a software which needs to be removed during the refactoring process. Fig 1. An example of refactoring in Visual Studio [9] An important primitive in any restructuring or refactoring process is not altering the behavior of the software. The original definition of behavior preservation as suggested by Opdyke [1] states that, for the same set of input values, the resulting set of output values should be the same before and after the refactoring. But behavior is too sensitive and subjective topic to be defined formally hence there have been attempts in literature to define behavior based on the problem in context in a domain specific way. But it is important to realize that the consistency of behavior is an important primitive to be kept unchanged in a refactoring or restructuring attempt. The use of preconditions and invariants has been suggested repeatedly in research literature as a way to address the problem of behavior preservation when restructuring or refactoring software artifacts. A typical software refactoring involves preconditions and post conditions phase. The basic idea of these conditions is to ensure the behavior preservation of the code in the best way possible. So preconditions and post conditions define the expectation from the code after refactoring and hence are in some sense responsible for behavior preservation. Refactoring has been seen as graph transformations also in literature.[6] Thus with a rich field of refactoring literature we set on to see how design patterns and refactoring can be clubbed together to improve and evolve the comprehensibility and use of software code. 6. BRIEF REVIEW OF DESIGN PATTERNS Formally design patterns are defined as patterns that express solutions to recurring software design problems in terms of objects and interfaces [8]. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects

3 that are involved. Algorithms are not thought of as design patterns, since they solve computational problems rather than design problems. Christopher Alexander has defined design patterns as a three part rule given by :[7] 1. Context- the environment and the situation where the problem has occurred in the software design. 2. Problem- the problem which demands for the solution in a given context. 3. Solution- a ready made solution already existing for a similar kind of a problem. Hence a design pattern can be seen as a problem.solution pairs in a given context. The concept of design patterns originates from the works of Ward Cunningham and Ken Beck who were working with Smalltalk and designing Graphical Use Interfaces back in 1987. Design patterns was made famous by the gang of four[gamma, Helm, Johnson and Vlissides] known in software community as Go4. Design pattern use a consistent documentation approach and are granular and applied at different levels such as frameworks, subsystems and sub-subsystems. Design patterns can speed up the development process by providing tested, proven development paradigms. Effective software design requires considering issues that may not become visible until later in the implementation. Reusing design patterns helps to prevent subtle issues that can cause major problems and improves code readability for coders and architects familiar with the patterns. Often, people only understand how to apply certain software design techniques to certain problems. These techniques are difficult to apply to a broader range of problems. Design patterns provide general solutions, documented in a format that doesn t require specifics tied to a particular problem. Fig. 2 : Generic Design Pattern architecture. [10] The concept of a Pattern Language is also forwarded in the literature to document a collection of related patterns to solve a large scale problem. Pattern language derives itself from pattern catalogue which is a collection of patterns based on types. For large scale problems pattern languages can prove effective in solving problems. Patterns are also grouped together in Pattern Family of the same type. When a change occurs on a pattern it is checked for a change of family. Changes can be characterized as micro evolution and macro evolution. Fig.3 : A generic Pattern evolution mechanism Developers use the design pattern by introducing in their designs prototypical micro-architecture, which means that micro-architectures in their designs will have structure and organization similar to the chosen design motif. In addition, patterns allow developers to communicate using well-known, well understood names for software interactions. Common design patterns can be improved over time, making them more robust than ad-hoc designs. Design patterns come with there share of problems and criticisms that centers briefly on following points : 1. Targets the wrong problem- The need for patterns results from using computer languages or techniques with insufficient abstraction ability. Under ideal factoring, a concept should not be copied, but merely referenced. But if something is referenced instead of copied, then there is no pattern to label and catalog. 2. Lacks formal foundations- The study of design patterns has been excessively ad hoc, and some have argued that the concept sorely needs to be put on a more formal footing. 3. No reuse is possible- A pattern must be programmed anew into each application that uses it. Some authors see this as a step backward from software reuse as provided by components. 4. Inefficient solutions- The idea of a design pattern is an attempt to standardize what are already accepted best practices. In principle this might appear to be beneficial, but in practice it often results in the unnecessary duplication of code. With this brief review of design patterns we emphasize here that not withstanding the criticisms of design patterns we believe that they provide an effective way to solve problems which repeat in all phases of software development.

4 7. JAVA DESIGN PATTERNS IN SOFTWARE REFACTORING 7.1 Related Work We summarize some approaches to relating pattern design to refactoring below : 1. Automated Application of Design Patterns This approach in the literature explores a methodology which introduces design patterns in refactoring in the following manner : Select the pattern to be used. Identify a precursor. Decompose the pattern into minipatterns. Define the minipatterns in terms of ministransformations, reusing minitransformations. Define the high-level transformation as a composition of minitransformations 2. Composite Refactorings for Java Programs This approach is explained as below : High-level refactorings made up of smaller, simpler low-level refactorings. If the precondition holds, the refactoring may be applied safely. If this is done correctly the postcondition will hold and the programs behaviour will be preserved. 3. Elbereth : Tool for Refactoring Java Programs Refactoring tool based on the notion of star diagrams. A star diagram provides a structured view of a programs source code as a network of nodes. These approaches have limitations as there was more focus on project development rather than refactoring in them, no focus on control flow analysis and refactoring inter-dependencies and refactoring and design patterns were considered completely different with having no common link. 7.2 Our New Architecture proposed Having studied the limitations and approaches of the previous works of design patterns in refactoring solutions we aim to propose and discuss a new architecture for using Design Patterns in refactoring and how it can score over present approaches. Here is the architecture : Fig 6. Proposed new architecture We chose to develop our new architecture over Java programs and refactoring of Java code though it is a general framework for design patterns. In summary the architecture deals with taking as input Java code and identify which part of the code in terms of methods, classes or variables needs to be reviewed and refactored. Here is the protocol according to which we propose the tool can function : 1. Choose a package or class of Java programs in need of refactoring. 2. Choose an appropriate candidate spot where to apply refactoring. 3. An expert decision which could be manual or automated is done to choose suitable candidate strategy to be applied to the bad smell part of the code. 4. Choose the candidate strategy in terms of appropriate design pattern to be applied to the code. 5. Check for pre and post conditions so that it ensures consistency and invariance of the behavior of the code body. 6. Apply the design pattern to the code manually or automatically. 7. Do a feedback check by comparing the behavior and quality of the original code and refactored code. In the step 1 and 3 where Expert Decision is required to choose the appropriate code which contains bad smells and is in need of refactoring we propose to use the concepts of Expert Systems and Decision Support Systems which are artificial intelligence constructs as automated expert decision in the implementation. We also propose to use adjacency matrix approach where a matrix of class interdependencies can be made to find how are the classes and methods interrelated in terms of cohesion so that we can see how the code can change as refactoring is applied and take corrective actions to keep the behavior intact. The important point to be noted is

5 that we here try to employ expert system and adjacency matrix to optimally find the best design pattern required in a given bad smell and then make a rule base to automate it in the expert system. Thus this optimally finding an appropriate design pattern would be important for making the rule base and training the expert system. Here is a brief summary of these artificial intelligence constructs : Expert Systems- These are artificial intelligence primitive model where a rule base is previously defined and accordingly the system chooses the rule and applies on the given code or program and there is a feedback mechanism by which the efficiency of the decision can be judged. Decision Support Systems- These are high level abstractions of the system specifically coded for effective decision making in a problem context. These systems can combine other constructs like Expert Systems, Fuzzy Logic, Artificial Neural networks for better decision support in mission critical applications. As we notice that in any refactoring situation, the choice of the appropriate code to be refactored is the single most important step in the whole process as it determines the number of bad smells in the code. In contemporary approaches expert decision is usually manual based on the coders instincts. We here propose to automate this process in the following way : 1. We can employ the use of Expert Systems to make a rule base of the characteristic properties of bad smells in the code. 2. We can train the expert system over a trial run of the code to be refactored. 3. Then we can fully integrate this expert system with the refactoring tool to automate the process of parts of code in urgent need of refactoring attention. In a similar way Decision Support Systems can be integrated with the new architecture at the initial phase for better choice of bad smell code. Also for preconditions of the architecture described we can use XML formatted forms where the expert can see what are the class interdependencies and accordingly modify the preconditions while preserving code behavior. XML can also be used in the feedback stage where the expert compares the refactored code with original code. The basic idea of using XML in these steps is to automate those steps and make them user friendly so that they can be made efficient. Using such stringent specifications we hope to find the optimal solution of design pattern which can be applied to the particular bad smell. With the proposed architecture and the proposed protocol to be used we hope it would make an improvement in the use of design patterns to restructuring the code and would give a better functionality to the code. Having described the new architecture, the complexity of implementation of the approach is obviously difficult in its full implementation so we chose instead to develop a proof of concept tool to demonstrate a simple refactoring in Java language. We believe that this tool can be further improved keeping its advantages to score more among similar tools like Eclipse and JEdit. 7.3 Design of Refactoring Tool We proposed a new model of design patterns in refactoring in the Java environment and also added the possibility of artificial intelligence constructs, which can be integrated with it. We propose in this section to give the design of the tool, with usual preprocessing and post processing checks involved in it. Fig 4. Proposed Design of tool Salient features of the approach and tool developed are summarized in following points : 1. Increases Maintenance Speed - Our refactoring processing tool is efficient than refactoring manually since it is light weight and provides functionality of design pattern choice to be embedded in the code by optimally finding the best design pattern to a given bad smell. 2. Increases reusability of code, as it follows Java design specifications specifically command patterns and hence all the merits of Java such as reusability, maintainance and modularity are imported in the tool. We also propose an improvement of this approach in section 9 where it can score over other approaches. 7.4 Limitations of Approach There are obvious limitations to our tool since it is a proof of concept tool to demonstrate the utility of design patterns use in software refactoring. There has been more sophisticated tools in the literature on refactoring but seldom are tools proposed for design patterns use in refactoring. Our tool is a simple proof of concept refactoring tool. It is novel in the sense of its new architecture,

6 software design and functionality. It can be further improved or used as a module in some future sophisticated tool using the present approach of design patterns use. Even automated software refactoring tools can be developed with this tool as a module to enhance the refactoring ability of the code without changing the behavior of the software. We also predict in the light of section 7.2 about the performance of the proposed architecture over existing approaches on Eclipse and JEdit in the following table : 7.5 Our Contribution in the project Here we summarize the salient points we concentrated on in the study : 1. Having studied the previous approaches we highlighted their drawbacks. 2. We proposed a new architecture for better integration of design patterns with refactoring. 3. We also proposed the possibility of integrating artificial intelligence constructs like Expert Systems and Decision Support Systems to automate the choice of code with bad smells. 4. We also proposed analysis of class interdependencies using adjacency matrix and how it can be used to make an effective rule base in expert system for better identification of bad smell code and appropriate design pattern to be used. 5. We study the limitations of the approach with a prediction of its utility over approaches like Eclipse and JEdit in terms of functionality and also performance if fully implemented. We hope to have taken a small step in a new direction to the idea of refactoring and design patterns by proposing the above concepts and predicting their utility in any future implementation of the concepts. It is really interesting and viable to use artificial intelligence constructs in refactoring and design patterns for better automation in their implementations and see the choice of bad smells and appropriate design patterns to correct them as an optimization problem. 9. SCOPE FOR FUTURE WORK There is always a scope of future work and our study has left a lot of loose ends to be tightened and new approaches to be experimented with. We propose that there is a lot of scope of improvement in the functionality of the tool and also to integrate automated systems with refactoring, in our case it was Expert Systems and Decision Support Systems. Here we compare the efficacy of our approach if implemented in totality to score over present approaches using Eclipse and JEdit. Fig 7. Prediction of our approach to others Though we concentrate on using artificial intelligence to automate the initial phase of choosing appropriate code to be refactored and corresponding design pattern, we hope that other phases can also be automated like pre and post conditions. Also the refactored code and the original code can be compared using a manual expert and he can suggest improvements in the rule base to make the application of expert system more efficient. 10. CONCLUSION In conclusion we would like to say that this project was a small attempt to address a new paradigm of reviewing and proposing the use of design patterns and software refactoring to enhance the ability of code comprehensibility, understanding without changing the behavior. In the process of analysis and study of the related concepts there has been a knowledge gain in the related areas of work and new ideas and concepts could be developed in the nascent areas of design patterns and refactoring. Acknowledgements Authors of the project deeply acknowledge Prof. Yann Gael Gueheneuc for being a constant support during the project and also we learnt a lot from him in software engineering and in life in general. REFERENCES [1]W.F. Opdyke, Refactoring : A Program Restructuring Aid in Designing Object-Oriented Application Frameworks, PhD thesis, Univ. of Illinois at Urbana- Champaign, 1992. [2]J Rajesh, D Janakiram, JIAD : A Tool to Infer Design Patterns in Refactoring by at PPDP04, August 2426, 2004, Verona, Italy. [3]Tom Mens, Tom Tourwe, A Survey of Software Refactoring in IEEE Transactions on Software Engineering, Vol. 30, No. 2, February 2004. [4] Design Patterns in http ://en.wikipedia.org/wiki/

7 [5] M. Fowler, Refactoring : Improving the Design of Existing Programs. Addison-Wesley, 1999. [6] R. Heckel, Algebraic Graph Transformations with Application Conditions, MS thesis, TU Berlin, 1995. [7] Alexander, Christopher, et al (1977). A Pattern Language : Towns, Buildings, Construction. New York : Oxford University Press. [8] Erich Gamma, Richard helm, Ralph, John, Design Patterns, Elements of reusable OO Software Addison Wesley 1994. [9]http ://images.google.com [10]Mikio Aiyoma, Evolutionary Patterns of Design and Design Patterns IEEE 2001. Electronic address: prashant@iro.umontreal.ca, habtinor@iro.umontreal.ca