167 research outputs found
A heuristic-based approach to code-smell detection
Encapsulation and data hiding are central tenets of the object oriented paradigm. Deciding what data and behaviour to form into a class and where to draw the line between its public and private details can make the difference between a class that is an understandable, flexible and reusable abstraction and one which is not. This decision is a difficult one and may easily result in poor encapsulation which can then have serious implications for a number of system qualities. It is often hard to identify such encapsulation problems within large software systems until they cause a maintenance problem (which is usually too late) and attempting to perform such analysis manually can also be tedious and error prone. Two of the common encapsulation problems that can arise as a consequence of this decomposition process are data classes and god classes. Typically, these two problems occur together – data classes are lacking in functionality that has typically been sucked into an over-complicated and domineering god class. This paper describes the architecture of a tool which automatically detects data and god classes that has been developed as a plug-in for the Eclipse IDE. The technique has been evaluated in a controlled study on two large open source systems which compare the tool results to similar work by Marinescu, who employs a metrics-based approach to detecting such features. The study provides some valuable insights into the strengths and weaknesses of the two approache
On Preserving the Behavior in Software Refactoring: A Systematic Mapping Study
Context: Refactoring is the art of modifying the design of a system without
altering its behavior. The idea is to reorganize variables, classes and methods
to facilitate their future adaptations and comprehension. As the concept of
behavior preservation is fundamental for refactoring, several studies, using
formal verification, language transformation and dynamic analysis, have been
proposed to monitor the execution of refactoring operations and their impact on
the program semantics. However, there is no existing study that examines the
available behavior preservation strategies for each refactoring operation.
Objective: This paper identifies behavior preservation approaches in the
research literature.
Method: We conduct, in this paper, a systematic mapping study, to capture all
existing behavior preservation approaches that we classify based on several
criteria including their methodology, applicability, and their degree of
automation.
Results: The results indicate that several behavior preservation approaches
have been proposed in the literature. The approaches vary between using
formalisms and techniques, developing automatic refactoring safety tools, and
performing a manual analysis of the source code.
Conclusion: Our taxonomy reveals that there exist some types of refactoring
operations whose behavior preservation is under-researched. Our classification
also indicates that several possible strategies can be combined to better
detect any violation of the program semantics
Recommended from our members
Reflective and relativistic refactoring with feature-awareness
Refactoring is a core technology in modern software development. It is central to popular software design movements, such as Extreme Programming [23] and Agile software development [91], and all major Integrated Development Environments (IDEs) today offer some form of refactoring support. Despite this, refactoring engines have languished behind research. Modern IDEs offer no means to sequence refactorings to automate program changes. Further, current refactoring engines exhibit problems of speed and expressivity, which makes writing composite refactorings such as design patterns infeasible. Even worse, existing refactoring tools for Object-Oriented languages are unaware of configurations in Software Product Lines (SPLs) codebases. With this motivation in mind, this dissertation makes three contributions to address these issues: First, we present the Java API library, called R2, to script Eclipse refactorings to retrofit design patterns into existing programs. We encoded 18 out of 23 design patterns described by Gang-of-Four [57] as R2 scripts and explain why the remaining refactorings are inappropriate for refactoring engines. R2 sheds light on why refactoring speed and expressiveness are critical issues for scripting. Second, we present a new Java refactoring engine, called R3, that addresses an Achilles heel in contemporary refactoring technology, namely scripting performance. Unlike classical refactoring techniques that modify Abstract Syntax Trees (ASTs), R3 refactors programs by rendering ASTs via pretty printing. AST rendering never changes the AST; it only displays different views of the AST/program. Coupled with new ways to evaluate refactoring preconditions, R3 increases refactoring speed by an order of magnitude over Eclipse and facilitates computing views of a program where the original behavior is preserved. Third, we provide a feature-aware refactoring tool, called X15, for SPL codebases written in Java. X15 takes advantage of R3's view rendering to implement a projection technology in Feature-Oriented Software Development, which produces subprograms of the original SPL by hiding unneeded feature code. X15 is the first feature-aware refactoring tool for Java that implements a theory of refactoring feature modules, and allows users to edit and refactor SPL programs via “views”. In the most demanding experiments, X15 barely runs a second slower than R3, giving evidence that refactoring engines for SPL codebases can indeed be efficient.Computer Science
Refactoring Haskell programs
EThOS - Electronic Theses Online ServiceGBUnited Kingdo
Generic Quality-Aware Refactoring and Co-Refactoring in Heterogeneous Model Environments
Software has been subject to change, at all times, in order to make parts of it, for instance, more reusable, better to understand by humans, or to increase efficiency under a certain point of view. Restructurings of existing software can be complex. To prevent developers from doing this manually, they got tools at hand being able to apply such restructurings automatically. These automatic changes of existing software to improve quality while preserving its behaviour is called refactoring. Refactoring is well investigated for programming languages and mature tools exist for executing refactorings in integrated development environments (IDEs).
In recent years, the development paradigm of Model-Driven Software Development (MDSD) became more and more popular and we experience a shift in the sense that development artefacts are considered as models which conform metamodels. This can be understood as abstraction, which resulted in the trend that a plethora of new so-called model-based Domain-Specific Languages (DSLs) arose. DSLs have become an integral part in the MDSD and it is obvious that models are subject to change, as well. Thus, refactoring support is required for DSLs in order to prevent users from doing it manually.
The problem is that the amount of DSLs is huge and refactorings should not be implemented for new for each of them, since they are quite similar from an abstract viewing. Existing approaches abstract from the target language, which is not flexible enough because some assumptions about the languages have to be made and arbitrary DSLs are not supported. Furthermore, the relation between a strategy which finds model deficiencies that should be improved, a resolving refactoring, and the improved quality is only implicit. Focussing on a particular quality and only detecting those deficiencies deteriorating this quality is difficult, and elements of detected deficient structures cannot be referred to in the resolving refactoring.
In addition, heterogeneous models in an IDE might be connected physically or logically, thus, they are dependent. Finding such connections is difficult and can hardly be achieved manually. Applying a restructuring in a model implied by a refactoring in a dependent model must also be a refactoring, in order to preserve the meaning. Thus, this kind of dependent refactorings require an appropriate abstraction mechanism, since they must be specified for dependent models of different DSLs.
The first contribution, Role-Based Generic Model Refactoring, uses role models to abstract from refactorings instead of the target languages. Thus, participating structures in a refactoring can be specified generically by means of role models. As a consequence, arbitrary model-based DSLs are supported, since this approach does not make any assumptions regarding the target languages.
Our second contribution, Role-Based Quality Smells, is a conceptual framework and correlates deficiencies, their deteriorated qualities, and resolving refactorings. Roles are used to abstract from the causing structures of a deficiency, which then are subject to resolving refactorings.
The third contribution, Role-Based Co-Refactoring, employs the graph-logic isomorphism to detect dependencies between models. Dependent refactorings, which we call co-refactorings, are specified on the basis of roles for being independent from particular target DSLs.
All introduced concepts are implemented in our tool Refactory. An evaluation in different scenarios complements the thesis. It shows that role models emerged as very powerful regarding the reuse of generic refactorings in arbitrary languages. Role models are suited as an interface for certain structures which are to be refactored, scanned for deficiencies, or co-refactored. All of the presented approaches benefit from it.:List of Figures xv
List of Tables xvii
List of Listings xix
1. Introduction 1
1.1. Language-Tool Generation Without Consideration Of Time And Space . . . . . 4
1.2. Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.3. Generic Quality-Aware Refactoring and Co-Refactoring in Heterogeneous Model
Environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2. Foundations 15
2.1. Refactoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2. Model-Driven Software Development . . . . . . . . . . . . . . . . . . . . . . . . 16
2.2.1. Levels of Abstraction and Metamodelling . . . . . . . . . . . . . . . . . 17
2.2.2. Model Transformations . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.3. Role-Based Modelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3. Related Work 23
3.1. Model Refactoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.1.2. Literature Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.1.3. Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.2. Determination of Quality-Related De ciencies . . . . . . . . . . . . . . . . . . . 32
3.2.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.2.2. Literature Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.2.3. Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.3. Co-Refactoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.3.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.3.2. Literature Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.3.3. Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4. Role-Based Generic Model Refactoring 51
4.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.2. Specifying Generic Refactorings with Role Models . . . . . . . . . . . . . . . . . 53
4.2.1. Specifying Structural Constraints using Role Models . . . . . . . . . . . 55
4.2.2. Mapping Roles to Language Concepts Using Role Mappings . . . . . . . 57
4.2.3. Specifying Language-Independent Transformations using Refactoring
Speci cations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.2.4. Composition of Refactorings . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.3. Preserving Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
4.4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
5. Suggesting Role Mappings as Concrete Refactorings 73
5.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
5.2. Automatic Derivation of Suggestions for Role Mappings with Graph Querying . 74
5.3. Reduction of the Number of Valid Matches . . . . . . . . . . . . . . . . . . . . . 76
5.4. Comparison to Model Matching . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
5.5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
6. Role-Based Quality Smells as Refactoring Indicator 79
6.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
6.2. Correlating Model De ciencies, Qualities and Refactorings . . . . . . . . . . . . 80
6.2.1. Quality Smell Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
6.2.2. Quality Smell Calculation Repository . . . . . . . . . . . . . . . . . . . . 85
6.3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
6.4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
7. A Quality Smell Catalogue for Android Applications 89
7.1. Quality Smell Catalogue Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
7.2. Acquiring Quality Smells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
7.3. Structure-Based Quality Smells—A Detailed Example . . . . . . . . . . . . . . . 92
7.3.1. The Pattern Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
7.3.2. Quality Smell: Interruption from Background . . . . . . . . . . . . . . . 93
7.4. Quality Smells for Android Applications . . . . . . . . . . . . . . . . . . . . . . 96
7.4.1. Quality Smell: Data Transmission Without Compression . . . . . . . . . 96
7.4.2. Quality Smell: Dropped Data . . . . . . . . . . . . . . . . . . . . . . . . 98
7.4.3. Quality Smell: Durable WakeLock . . . . . . . . . . . . . . . . . . . . . 98
7.4.4. Quality Smell: Internal Use of Getters/Setters . . . . . . . . . . . . . . . 99
7.4.5. Quality Smell: No Low Memory Resolver . . . . . . . . . . . . . . . . . 101
7.4.6. Quality Smell: Rigid AlarmManager . . . . . . . . . . . . . . . . . . . . 101
7.4.7. Quality Smell: Unclosed Closeable . . . . . . . . . . . . . . . . . . . . . 102
7.4.8. Quality Smell: Untouchable . . . . . . . . . . . . . . . . . . . . . . . . . 103
7.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
8. Role-Based Co-Refactoring in Multi-Language Development Environments 105
8.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
8.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
8.3. Dependency Knowledge Base . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
8.3.1. Categories of Model Dependencies . . . . . . . . . . . . . . . . . . . . . 108
8.3.2. When to Determine Model Dependencies . . . . . . . . . . . . . . . . . 110
8.3.3. How to Determine Model Dependencies . . . . . . . . . . . . . . . . . . 111
8.4. Co-Refactoring Knowledge Base . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
8.4.1. Specifying Coupled Refactorings with Co-Refactoring Speci cations . . 114
8.4.2. Specifying Bindings for Co-Refactorings . . . . . . . . . . . . . . . . . . 116
8.4.3. Determination of Co-Refactoring Speci cations . . . . . . . . . . . . . . 118
8.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
8.6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
9. Refactory: An Eclipse Tool For Quality-Aware Refactoring and Co-Refactoring 121
9.1. Refactoring Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
9.1.1. Role Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
9.1.2. Refactoring Speci cation . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
9.1.3. Role Model Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
9.1.4. Refactoring Composition . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
9.1.5. Custom Refactoring Extensions . . . . . . . . . . . . . . . . . . . . . . . 129
9.1.6. Pre- and Post-conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
9.1.7. Integration Into the Eclipse Refactoring Framework . . . . . . . . . . . . 130
9.2. Quality Smell Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
9.3. Co-Refactoring Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
9.3.1. Concrete Syntax of a CoRefSpec . . . . . . . . . . . . . . . . . . . . . . . 138
9.3.2. Expression Evaluation by Using an Expression Language . . . . . . . . . 138
9.3.3. UI and Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
9.4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
10. Evaluation 143
10.1. Case Study: Reuse of Generic Refactorings in many DSLs . . . . . . . . . . . . . 143
10.1.1. Threats to validity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
10.1.2. Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
10.1.3. Experience Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
10.2. Case Study: Suggestion of Valid Role Mappings . . . . . . . . . . . . . . . . . . 147
10.2.1. Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
10.2.2. Evaluation and Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 151
10.3. Proof of Concept: Co-Refactoring OWL and Ecore Models . . . . . . . . . . . . 155
10.3.1. Coupled OWL-Ecore Refactorings . . . . . . . . . . . . . . . . . . . . . 156
10.3.2. Realisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
10.3.3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
11. Summary, Conclusion and Outlook 161
11.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
11.2. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
11.3. Outlook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Appendix 169
A. List of Role Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
B. Comparison to Role Feature Model . . . . . . . . . . . . . . . . . . . . . . . . . 171
C. Complete List of Role Mappings . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
D. List of all IncPL Patterns for Detecting Quality Smells . . . . . . . . . . . . . . . 176
E. Post-Processor of the Extract CompositeState refactoring for UML State Machines 183
F. Speci cation of the Conference Language . . . . . . . . . . . . . . . . . . . . . . 185
List of Abbreviations 187
Bibliography 19
- …