AbstractIn this paper, we provide a detailed overview of existing researches in the field of software restructuring and model refactoring, from a formal as well as a practical point of view. We propose a possible taxonomy for the classification of several existing and proposed model refactoring approaches. The taxonomy is described with a feature model that makes the different design choices for model refactoring explicit. 1 INTRODUCTIONRefactoring is a technique to improve the maintainability of software systems by changing the internal structure of software without altering its external behavioral properties [Opdyke92]. Especially when automated by a tool, refactoring is an easy, quick and safe way to improve software systems at the code level, and to assist to identify errors. In addition, lightweight development methods, such as eXtreme Programming (XP) [Succi01], have promoted refactoring as a core development practice. Considering the model-driven engineering [MDA06] which is an approach of software engineering where the primary focus is on models, as opposed to source code. Model transformation [RFP02] is considered to be the heart of model-driven engineering. We can apply the refactoring as a model transformation. We transform an input model needing a design improvement to a target model using behavior-preserving transformations. There exist several classifications of model transformations like classification in “exomorphic”, “endomorphic” and “creational” transformations [Czarnecki03]. As presented in figure 1, we are interested only on endomorphic transformation. It deals with models represented at the same level of abstraction, and where source and target models are instances of the same metamodel. Usages of endomorphic transformations are numerous. Typical example of this kind of transformation is refactoring.
Figure 1: Model refactoring process The remainder of the paper is structured as follows. Section 2 presents the code refactoring researches. Section 3 presents the model refactoring states of the art. Section 4 gives the model refactoring taxonomy. Section 5 discusses the different classification features. Section 6 and 7 are reserved for related works and conclusion, respectively. 2 CODE REFACTORING: STATE OF THE ARTThis section presents the most relevant works on code refactoring , we try to give an indicative list of such works. William Opdyke’s PhD thesis [Opdyke92] was the first major written work using the refactoring term. He considered refactorings for object-oriented software. For these refactorings, he described the design prerequisites and automatic program restructurings required to guarantee preservation of behavior. An important consequence of Opdyke’s work was the later development of a refactoring tool for Smalltalk. Roberts [Roberts99] extended Opdyke’s work by providing a more formal basis for composing refactorings and examined the use of dynamic information in refactoring. Graph transformations [Corradini02] [Engels96] [Ehrig00] represents another way to deal with restructuring: the software is represented as a graph, and restructuring corresponds to the transformation rules .In [Jahnke97], authors suggest the use of graph transformation in order to replace occurrences of poor design patterns in a legacy program by good design patterns. In [Lakhotia98], the author present a transformation called tuck for restructuring programs by decomposing large functions into small functions. Tuck consists of three steps: Wedge, Split, and Fold. A wedge (i.e. a subset of statements in a slice) contains computations that are related and that may create a meaningful function. The statements in a wedge are split from the rest of the code and folded into a new function. In [Snelting98], Snelting et al. present a framework for detecting and remediating the imperfect design of a class hierarchy based on concept analysis. Authors analyzes the class hierarchy along with a set of applications that use it, and constructs a lattice that provides valuable insights into the usage of the class hierarchy in a specific context and then generate a restructured class from the lattice. In the works of Marticorena et al. [Marticorena06], we find another way to deal with refactoring which is software metrics. At first, authors propose a set of additional criteria to classify bad smells (define in an informal way code flaws, in order to suggest refactorings). Then they link the concept of bad smells with the concept of metric features. The aim of this work is to propose a method to evaluate the suitability of the tools assisting bad code smell detection, as well as the selection and the implementation of metrics linked with bad code smells. In [Melton06], H. Melton and E. Tempero present a tool (Jepends) that analyses the source code of a system in order to identify classes as possible refactoring candidates. The tool analysis is based on the identification of the dependency cycles among classes. After that authors show how dependency cycles detected by the Jepends tool can be used as the starting point for refactoring. Another refactoring approach is proposed in [Hadar06]. The Composition Refactoring Triangle (CRT) unified approach for handling multiple changes across complex environments. The CRT is a combination of three pillars: the CR Process (CRP); the CR Management Tool (CRMT); and the code complexity management procedure and version control, using External and Internal Composition Refactoring (ECR/ICR) XML markers. The external ones are linked to external visible features or software requirement changes, and the Internals are a set of uniquely defined refactoring primitives. Authors propose a practical method for the resolution of the problem, evaluating and estimating the time and effort required for the refactoring. The approach is assisted by techniques and tools, allowing the development team in handling multiple changes using combination of primitive refactorings. 3 MODEL REFACTORING STATE OF THE ARTA recent trend is to apply the concepts of refactoring to higher levels of abstraction. Consequently, model refactoring is emerging as a desirable means to improve models design using behavior-preserving transformations. Although it exists many researches on code refactoring, works on model refactoring are still young. This section presents the most relevant researches on model refactoring. In [Biermann06], Enrico Biermann et al. propose to use the Eclipse Modeling Framework (EMF), a modeling and code generation framework for Eclipse applications based on structured data models. They introduce the EMF model refactoring by defining a transformation rules applied on EMF models. EMF transformation rules can be translated to corresponding graph transformation rules. If the resulting EMF model is consistent, the corresponding result graph is equivalent and can be used for validating EMF model refactoring. Authors offer a help for developer to decide which refactoring is most suitable for a given model and why, by analyzing the conflicts and dependencies of refactorings. This demarche is closed to the model driven architecture (MDA) paradigm [MDA06] since it starts from the EMF metamodel applying a transformation rules. Another work on model refactoring is proposed in [Zhang05], based on the Constraint-Specification Aspect Weaver (C-SAW)1, a model transformation engine which describes the binding and parameterization of strategies to specific entities in a model. Authors propose a model refactoring browser within the model transformation engine to enable the automation and customization of various refactoring methods for either generic models or domain-specific models. The transformation proposed in this work is not based on any metamodel, it is not an MDA approach. In [Rui03] Rui, K. and Butler, apply refactoring on use case models, they propose a generic refactoring based on use case metamodel. This metamodel allows creating several categories of use case refactorings, they extend the code refactoring to define a set of use case refactorings primitive. This refactoring is very specific since it is focused only on use case model, the issue of generic refactoring is not addressed, and these works do not follow the MDA approach. R. Marticorena affirms that on one side, all tools such as (IntelliJ IDEA, Eclipse, Refactoring Browser, JRefactory...) approach the implementation and execution of refactorings from the scratch, with a solution based on customized libraries, not supporting reuse to compose and run refactorings on other languages with similar features. On the other side, the modern software systems often require different modules developed in different languages. As solution, he proposes in [Marticorena05] an independent language refactoring based on MOON [Marticorena03] a minimal notation to support most of the abstract concepts included in a big family of strongly typed object-oriented languages. Author analyze and define a refactoring catalog based on MOON, he try to obtain a formal support to the definition of refactoring that can be achieved with language independence preserving the behavior of the software. This work proposes a measure the software quality improvement, resulting from the refactoring operations. This approach is very closed to the MDA paradigm since they start from the MOON as the equivalent of the MOF, but MOON is not a standard, as matter of fact, it cannot offer a generic and extensible approach. Using MOON we are faced to an interoperability problem when moving to another meta-metamodel. In the line of language independent refactoring and metamodelling, Sander et al. [Tichelaar00], study the similarities between refactorings for Smalltalk and Java, and build the FAMIX model. It provides a language-independent representation of object-oriented source code. It is an entity-relationship model that models object-oriented source code at the program entity level, with a tool to assist refactoring named MOOSE. FAMIX [Tichelaar99a] [Tichelaar99b] does not take account neither complex features in strongly typed languages (this point have been discussed in [Marticorena05]), nor aspects of advanced inheritance and genericity. This approach is not really independent from language since the refactoring transformation is achieved directly on the original code. This alternative forces to implement transformers of specific code for each language. These code transformers use an approach based on text using regular expressions. Based on their experience of the FAMIX metamodel Pieter Van Gorp et al. propose in [Gorp03] an extension of the UML metamodel for resolving inconsistency problems that arise when performing a model refactoring. This inconsistency occurs between a design model and the corresponding code. Typical MDA tools using the UML metamodel consider the whole method body as implementation specific, and when performing a model refactoring, we do not pay attention to the implementation level to increase the abstraction level. Consider the simple Rename Class refactoring primitive, at implementation level the type casts and exceptions, will not be updated accordingly to the new name. The solution proposed in [Gorp03] is an extension of the UML metamodel for refactoring with aims of relating a method body to its contained statements and then leverage the profile mechanism to model language specific features such as conditionals, exceptions, type casts... as cross-language abstractions that express strictly the information needed by the refactoring catalog in use. As result, they propose the GrammyUML metamodel, which reuse UML 1.4 action entity, it contains arguments and introduces the SingleTargetAction relating the action to its target. Finally they apply an UML profile for refactoring developed on top of the GrammyUML metamodel. This approach is not closed to the MDA paradigm, it does not define a meta-metamodel level and there is no evaluation of the extension proposed with the MOF or any other meta-metamodel. Another model refactoring is presented in [Kempen05], based on SAAT (Software Architecture Analysis Tool). It allows calculating metrics about UML models the metrics are then used to identify the flaws or anti-patterns. Authors represent the structure using class diagrams, and the behaviour of each class using statecharts. After that they examine the metrics for refactoring a centralized control structure into one that employs more delegation they use csp-based formalism (Communicating Sequential Processes) to guarantee the behaviour preservation. This work deal with a particular problem of centralized control structure, it is not based on any metamodel. In the next section other works on model refactoring are referenced. 4 DESIGN FEATURES OF MODEL REFACTORING APPROACHESBased on the state of the art defined in the section 3 we identified various properties of the model refactoring domain. Indeed, we elaborated a manual classification which puts back the main characteristics presented in a unified way. This presentation allows to highlight the common points between each approach and to consider a variety of potential combinations over them. Czarnecki et al, proposes a possible taxonomy for the classification of several existing and proposed model transformation approaches. Considering the refactoring as a model transformation problem, we extend the feature diagrams resulting from a domain analysis of existing model transformation approaches presented in [Czarnecki03]. The taxonomy for the classification of model transformation is valid for model refactoring but not sufficient. We enlarge this taxonomy by adding new concepts, specific to the model refactoring domain. Every concept is then detailed and followed by a comparative table relating the presence of the concept in the works presented above.
Figure 2: Features diagram for model refactoring Figure 2 presents the model refactoring taxonomy. The part in box represents the model transformation taxonomy proposed by Czarnecki et al [Czarnecki03]. We add the new features related to the model refactoring domain. Behaviour preservationA model refactoring must preserve the observable behaviour of the model it is transforming. In order to achieve this, we need a precise definition of “behaviour” in general, and for models in particular.
Figure 3: Features of behaviour preservation As presented in figure 3, existing refactoring works has generally relied on either a semi-formal demonstration of behaviour preservation (e.g. approach based on contracts : pre, postconditions and invariants [Marticorena05] ), or indeed no demonstration of behaviour preservation at all [Biermann06] [Zhang05]. In practice, full behaviour preservation is very difficult to prove. It may be some tolerance for changing behaviour as long as we are able to identify precisely how a given model transformation modifies it.
Table 1: The comparison of the various approaches with regard to the properties of behaviour preservation Refactoring opportunitiesThe figure 4 presents the refactoring opportunities which contain the possibilities of detection of the design defects and the possible improvements, this property is crucial for the creation of automatic refactorisations. The refactoring strategy includes the detection whether the refactoring needs in a source model. Users can specify the refactoring needs, as response for specific changes. This is a reactive approach, the programmer detects the suitable refactoring (e.g. the work presented in [Tichelaar00] do not indicate where apply a refactoring it only explain how apply a model refactoring primitive). It can also be detected automatically from a proactive approach (inference), in this case, the system detects the refactoring opportunities by analyzing the design defects. Design defects are poor design choices that hinder the maintenance of programs. They include bad solutions to recurring problems in object oriented design, such as antipatterns [Brown98] (as opposed to design patterns [Larman02]), defects related to design and code smells [Fowler99] (symptoms of design defects).
Figure 4: Features of refactoring opportunities Refactoring opportunities can be identified by analyzing bad smells (e.g. in [Marticorena05] authors apply a refactoring inference based on metric values and bad smells) or antipatterns (e.g. in [Kempen05] metrics are used to identify the anti-patterns). Symptoms serve to detect the model elements susceptible to be refactored, as well as bad smells. It exist other solution not covered by this classification. As example, in [Moha08], authors propose an automated approach for suggesting defect-correcting refactorings using relational concept analysis (RCA). In [Moha06], authors combine the effectiveness of metrics with formal concept analysis to detect design defect. This approach is not independent from the language and therefore it can not be generic.
Table 2: The comparison of the various approaches with regard to the properties of refactoring opportunities Opportunities detectionAs presented in figure 5, in case when the detection of model refactoring opportunities is achieved automatically from a proactive approach, it then necessities a prerequisite analyze. We distinguish two analyzing ways, the first one is focused on code level and then applied on model (e.g. [Tichelaar00] [Moha08] [Moha07] ) , the second one perform analysis on model (e.g. [Kempen05] [Straeten06] [Straeten03]).
Figure 5: Features of opportunities detection This approach is more difficult since model level contains less information to analyze than the code level, although it has the advantage to offer a generic and reusable refactoring independent from any platform.
Table 3: The comparison of the various approaches with regard to the properties of opportunities detection SynchronizationThe Model refactoring operation must guarantee the consistency between a design model and the corresponding code.
Figure 6: Features of synchronization We decompose in figure 6 the maintaining model consistency feature in two orthogonal aspects: horizontal consistency must be maintained between design diagrams like UML static and dynamic diagrams (e.g. [Straeten06] [Straeten03]) and vertical consistency between model and code. Model transformation is based on the metamodel level, and the whole method body is considered in the MDA paradigm as implementation specific related to the code level. Therefore, when model is refactored it can cause an inconsistency problem. Consider the simple Rename Class refactoring: class names may be used within protected areas like in type declarations, type casts and exceptions, and the new name will not be updated accordingly [Gorp03], since this information are not stored in model level. Face to this problem we can adopt two strategies, the first one is to try to relate the model to its code and then apply the profile mechanism to model the language specific features such as conditionals, exceptions, and type casts, (e.g. [Gorp03] ). Her we have a compromise between maintaining consistency and the reusability, since relating model to code offer a specific solution not applicable to other platforms. The second one is related to the MDA process which starts from model arriving to the code by automated transformations. Performing a model refactoring is done at Platform Independent Model (PIM) or Platform Specific Model (PSM) levels and then code will be regenerated reflecting the new features on the refactored model. This approach is based on both model-to-model and model-to-code transformations and offer a generic and reusable refactoring independent of any platform.
Table 4: The comparison of the various approaches with regard to the properties of refactoring strategy Refactoring strategyAs presented in figure 7, although model refactoring can be done manually using any graphical tool. It is possible to do that for small applications, but when we move to large systems this operation will be hardest and time consuming, needing effort and experience. Works presented in this paper try to resolve this problem by offering an automated and a semi automated refactoring.
Figure 7: Features of refactoring strategy Automated refactoring, deal with the automated detection and correction of design defects. The programmer has just to execute the refactoring (e.g. [Straeten06]). Semi-automated refactoring relay on the interaction with programmer. We can propose a list of model refactoring primitives, and user can apply any primitives depending on his preferences (e.g. [Sunye01]). Markovic in [Markovic04] presents a set of refactoring rules that can be checked, reused and composed. Author offer an algorithm to compute the description of sequentially composed transformations allowing users to check if a sequence of transformations is successfully applicable for a given model.
Table 5: The comparison of the various approaches with regard to the properties of refactoring strategy 5 DISCUSSIONAlthough there are satisfactory solutions for the code refactoring, (such as IntelliJ IDEA, Eclipse, Refactoring Browser, JRefactory), the models refactoring still in the stage of research and development. In this context, several propositions emerge, certain try to supply a structured demarche, the others propose ad-hoc solutions. Our study aims to classify these various approaches to be able to compare them, possibly to combine them she also allows to identify future challenges. According to the analysis of the various tables presented in the section 3 we notice that for the properties of:
6 RELATED WORKCzarnecki et al. propose in [Czarnecki03] a classification of model transformation approaches. This classification is applicable for model refactoring since model refactoring is an endomorphic model transformation. Although, model refactoring introduces new concepts not covered in such taxonomy. This taxonomy is based on a set of features identified from the model transformation domain analysis. Tom Mens et al. offer in [Mens05] another taxonomy of model transformation based on the discussions of a working group on model transformation of the Dagstuhl Seminar on Language Engineering for Model Driven Software Development. The two works are relatively similar since we find the same concepts. Mens et al. focuses on helping the developer choosing a particular transformation language by answering crucial questions for model transformation they proposes. In [Mens03] Tom Mens propose a list of the most important challenges in model refactoring that could be investigated. Although, this works surround the model refactoring area, it is necessary to define a well established classification of model refactoring approaches this paper provide a set of classes in which we can catalogue each work dealing with model refactoring. 7 CONCLUSIONModel refactoring is a young area, although it is related to and builds upon the more established fields of program transformation and meta-programming. Many approaches to model refactoring have been proposed over the last years, but little experience is available to assess their effectiveness in practical applications. In this respect, we are still at the stage of exploring possibilities and eliciting requirements. In this paper we presented the most relevant works on model refactoring based on our intuition and the application examples published together with each approach. We classified the existing model refactoring approaches relating to refactoring features we proposed. A depth comparison based on benchmark problems would be the next step to evaluate each approach.Footnotes1 Additional information about C-SAW is available at: http://www.cis.uab.edu/gray/Research/C-SAW. REFERENCES[Corradini02] Corradini A., H. Ehrig, H.-J. Kreowski and G. Rozenberg, editors,”Graph Transformation” Lecture Notes in Computer Science 2505, Springer-Verlag, 2002. [Sunye01] Gerson Sunye, Damien Pollet, Yves Le Traon, and Jean-Marc Jezequel, “Refactoring UML Models”, In Proceedings of UML 2001, Volume 2185. Springer Verlag, 2001. [Straeten06] Ragnhild Van Der Straeten, Maja D’Hondt “Model Refactorings through RuleBased Inconsistency Resolution”, SAC’06 Dijon, France 2006. [Straeten03] Ragnhild Van Der Straeten, Jocelyn Simmonds “Detecting Inconsistencies between UML Models Using Description Logic”, International Workshop on Description Logics, Rome, Italy September 5-7, 2003. [RFP02] Request for Proposal: MOF 2.0 Query /Views /Transformations RFP, OMG Document: ad/2002-04-10. [Rui03] Rui K. and Butler, G. (2003). “Refactoring Use Case Models : The Metamodel”. In Proc. Twenty-Sixth Australasian Computer Science Conference (ACSC2003), Adelaide, Australia. CRPIT, 16. Oudshoorn, M.J., Ed. ACS. 301-308. [Tichelaar00] Sander Tichelaar, Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz. “A Meta-model for Language-Independent Refactoring”, published in the proceedings of ISPSE 2000. [Tichelaar99a] Sander Tichelaar, Serge Demeyer and Patrick Steyaert. Famix 2.0 – the famoos information exchange model. URL: http://www.iam.unibe.ch/ famoos/FAMIX/, 09 1999. [Tichelaar99b] S. Tichelaar, FAMIX Java language plug-in 1.0, Technical, Report, University of Berne, September 1999. [Demeyer02] S. Demeyer, S. Ducasse, and O. Nierstrasz, Object-Oriented Reengineering Patterns, Morgan Kaufmann and DPunkt, 2002. [Markovic04] Slavisa Markovic, “Composition of UML Described Refactoring Rules, OCL and Model Driven Engineering”, Lisbon, Portugal, October 12, 2004. [Snelting98] Snelting G. and F. Tip, “Reengineering class hierarchies using concept analysis”, in: Proc. Foundations of Software Engineering (FSE-6), SIGSOFT Software Engineering Notes 1998. [Mens03] Tom Mens, First international workshop on refactoring : achievements, challenges, and effects, 2003. [Mens05] Tom Mens, Krzysztof Czarnecki, and Pieter Van Gorp, “A Taxonomy of Model Transformations”, Dagstuhl Seminar Proceedings, 2005. [Opdyke92] William F. Opdyke. “Refactoring Object-Oriented Frameworks”. PhD dissertation, University of Illinois at Urbana-Champaign, Department of Computer Science, 1992. [Brown98] William J. Brown, Raphael C. Malveau, William H. Brown, Hays W. McCormick III, and Thomas J. Mowbray. Anti Patterns: “Refactoring Software, Architectures, and Projects in Crisis”. John Wiley and Sons, 1st edition, March 1998. [Zhang05] Zhang J., Lin, Y. and Gray, J. (2004) “Generic and Domain-Specific Model Refactoring using a Model Transformation Engine”, Model-driven Software Development – Research and Practice in Software Engineering, accepted for publication in 2005. About the authors
Maddeh Mohamed, Mohamed Romdhani, Khaled GHEDIRA: “Classification of model refactoring approaches”, in Journal of Object Technology, vol. 8, no. 6, September-October 2009, pp. 121-126 http://www.jot.fm/issues/issue_2009_09/article3/ |
||||||||||||||||
