Results 1 - 10
of
151
A survey of software refactoring
- IEEE Transactions on Software Engineering
, 2004
"... Abstract—This paper provides an extensive overview of existing research in the field of software refactoring. This research is compared and discussed based on a number of different criteria: the refactoring activities that are supported, the specific techniques and formalisms that are used for suppo ..."
Abstract
-
Cited by 299 (10 self)
- Add to MetaCart
Abstract—This paper provides an extensive overview of existing research in the field of software refactoring. This research is compared and discussed based on a number of different criteria: the refactoring activities that are supported, the specific techniques and formalisms that are used for supporting these activities, the types of software artifacts that are being refactored, the important issues that need to be taken into account when building refactoring tool support, and the effect of refactoring on the software process. A running example is used throughout the paper to explain and illustrate the main concepts. Index Terms—Coding tools and techniques, programming environments/construction tools, restructuring, reverse engineering, and reengineering. 1
A taxonomy of model transformation
- Proc. Dagstuhl Seminar on "Language Engineering for Model-Driven Software Development". Internationales Begegnungs- und Forschungszentrum (IBFI), Schloss Dagstuhl
, 2005
"... This report summarises the results of the discussions of a working group on model transformation of the Dagstuhl Seminar on Language Engineering for Model-Driven Software Development. The main contribution is a taxonomy of model transformation. This taxonomy can be used to help developers in decidin ..."
Abstract
-
Cited by 181 (2 self)
- Add to MetaCart
This report summarises the results of the discussions of a working group on model transformation of the Dagstuhl Seminar on Language Engineering for Model-Driven Software Development. The main contribution is a taxonomy of model transformation. This taxonomy can be used to help developers in deciding which model transformation approach is best suited to deal with a particular problem.
Detection strategies: Metrics-based rules for detecting design flaws
- In Proc. IEEE International Conference on Software Maintenance
, 2004
"... In order to support the maintenance of an objectoriented software system, the quality of its design must be evaluated using adequate quantification means. In spite of the current extensive use of metrics, if used in isolation metrics are oftentimes too fine grained to quantify comprehensively an inv ..."
Abstract
-
Cited by 105 (6 self)
- Add to MetaCart
(Show Context)
In order to support the maintenance of an objectoriented software system, the quality of its design must be evaluated using adequate quantification means. In spite of the current extensive use of metrics, if used in isolation metrics are oftentimes too fine grained to quantify comprehensively an investigated design aspect (e.g., distribution of system’s intelligence among classes). To help developers and maintainers detect and localize design problems in a system, we propose a novel mechanism – called detection strategy – for formulating metrics-based rules that capture deviations from good design principles and heuristics. Using detection strategies an engineer can directly localize classes or methods affected by a particular design flaw (e.g., God Class), rather than having to infer the real design problem from a large set of abnormal metric values. We have defined such detection strategies for capturing around ten important flaws of object-oriented design found in the literature and validated the approach experimentally on multiple large-scale case-studies.
Using Origin Analysis to Detect Merging and Splitting of Source Code Entities
, 2005
"... Merging and splitting source code entities is a common activity during the lifespan of a software system; as developers rethink the essential structure of a system or plan for a new evolutionary direction, so must they be able to reorganize the design artifacts at various abstraction levels as seems ..."
Abstract
-
Cited by 96 (3 self)
- Add to MetaCart
Merging and splitting source code entities is a common activity during the lifespan of a software system; as developers rethink the essential structure of a system or plan for a new evolutionary direction, so must they be able to reorganize the design artifacts at various abstraction levels as seems appropriate. However, while the raw effects of such changes may be plainly evident in the new artifacts, the original context of the design changes is often lost. That is, it may be obvious which characters of which files have changed, but it may not be obvious where or why moving, renaming, merging, and/or splitting of design elements has occurred. In this paper, we discuss how we have extended origin analysis [1], [2] to aid in the detection of merging and splitting of files and functions in procedural code; in particular, we show how reasoning about how call relationships have changed can aid a developer in locating where merges and splits have occurred, thereby helping to recover some information about the context of the design change. We also describe a case study of these techniques (as implemented in the Beagle tool) using the PostgreSQL database system as the subject.
Analysing Refactoring Dependencies Using Graph Transformation
- SOSYM MANUSCRIPT
"... Refactoring is a widely accepted technique to improve the structure of object-oriented software. Nevertheless, existing tool support remains restricted to automatically applying refactoring transformations. Deciding what to refactor and which refactoring to apply still remains a difficult manual pr ..."
Abstract
-
Cited by 55 (12 self)
- Add to MetaCart
Refactoring is a widely accepted technique to improve the structure of object-oriented software. Nevertheless, existing tool support remains restricted to automatically applying refactoring transformations. Deciding what to refactor and which refactoring to apply still remains a difficult manual process, due to the many dependencies and interrelationships between relevant refactorings. In this paper, we represent refactorings as graph transformations, and we propose the techniques of critical pair analysis and sequential dependency analysis to detect the implicit dependencies between refactorings. The results of this analysis can help the developer to make an informed decision of which refactoring is most suitable in a given context and why. We report on several experiments we carried out in the AGG graph transformation tool to support our claims.
An Empirical Study on the Maintenance of Source Code Clones
- EMPIRICAL SOFTWARE ENGINEERING (EMSE)
"... Code cloning has been very often indicated as a bad software development practice. However, many studies appearing in the literature indicate that this is not always the case. In fact, either changes occurring in cloned code are consistently propagated, or cloning is used as a sort of templating str ..."
Abstract
-
Cited by 54 (0 self)
- Add to MetaCart
Code cloning has been very often indicated as a bad software development practice. However, many studies appearing in the literature indicate that this is not always the case. In fact, either changes occurring in cloned code are consistently propagated, or cloning is used as a sort of templating strategy, where cloned source code fragments evolve independently. This paper (i) proposes an automatic approach to classify the evolution of source code clone fragments, and (ii) reports a fine-grained analysis of clone evolution in four different Java and C software systems, aimed at investigating to what extent clones are consistently propagated or they evolve independently. Also, the paper investigates the relationship between the presence of clone evolution patterns and other characteristics such as clone ra-
DECOR: A method for the specification and detection of code and design smells
- IEEE TRANSACTIONS ON SOFTWARE ENGINEERING
, 2010
"... Code and design smells are poor solutions to recurring implementation and design problems. They may hinder the evolution of a system by making it hard for software engineers to carry out changes. We propose three contributions to the research field related to code and design smells: 1) DECOR, a meth ..."
Abstract
-
Cited by 53 (13 self)
- Add to MetaCart
(Show Context)
Code and design smells are poor solutions to recurring implementation and design problems. They may hinder the evolution of a system by making it hard for software engineers to carry out changes. We propose three contributions to the research field related to code and design smells: 1) DECOR, a method that embodies and defines all the steps necessary for the specification and detection of code and design smells, 2) DETEX, a detection technique that instantiates this method, and 3) an empirical validation in terms of precision and recall of DETEX. The originality of DETEX stems from the ability for software engineers to specify smells at a high level of abstraction using a consistent vocabulary and domain-specific language for automatically generating detection algorithms. Using DETEX, we specify four well-known design smells: the antipatterns Blob, Functional Decomposition, Spaghetti Code, and Swiss Army Knife, and their 15 underlying code smells, and we automatically generate their detection algorithms. We apply and validate the detection algorithms in terms of precision and recall on XERCES v2.7.0, and discuss the precision of these algorithms on 11 open-source systems.
Using History Information to Improve Design Flaws Detection
- CSMR 2004: 8TH EUROPEAN CONFERENCE ON SOFTWARE MAINTENANCE AND REENGINEERING
, 2004
"... As systems evolve and their structure decays, maintainers need accurate and automatic identification of the design problems. Current approaches for automatic detection of design problems are not accurate enough because they analyze only a single version of a system and consequently they miss essenti ..."
Abstract
-
Cited by 43 (9 self)
- Add to MetaCart
(Show Context)
As systems evolve and their structure decays, maintainers need accurate and automatic identification of the design problems. Current approaches for automatic detection of design problems are not accurate enough because they analyze only a single version of a system and consequently they miss essential information as design problems appear and evolve over time. Our approach is to use the historical information of the suspected flawed structure to increase the accuracy of the automatic problem detection. Our means is to define measurements which summarize how persistent the problem was and how much maintenance effort was spent on the suspected structure. We apply our approach on a large scale case study and show how it improves the accuracy of the detection of God Classes and Data Classes, and additionally how it adds valuable semantical information about the evolution of flawed design structures.
New frontiers of reverse engineering
- in: 2007 Future of Software Engineering, IEEE Computer Society
, 2007
"... interests include software maintenance and reverse engineering, service oriented software engineering, and experimental software engineering. He has co-authored more than 100 papers published in international journals and referred conferences and workshops. He was an associate editor of IEEE Transac ..."
Abstract
-
Cited by 36 (1 self)
- Add to MetaCart
(Show Context)
interests include software maintenance and reverse engineering, service oriented software engineering, and experimental software engineering. He has co-authored more than 100 papers published in international journals and referred conferences and workshops. He was an associate editor of IEEE Transactions on Software Engineering and he currently serves on the Editorial Board of the Journal of Software Maintenance and Evolution. He is a member of
Discovering faults in idiom-based exception handling.
- In Proceedings of the 28th International Conference on Software Engineering, ICSE ’06,
, 2006
"... ABSTRACT In this paper, we analyse the exception handling mechanism of a state-of-the-art industrial embedded software system. Like many systems implemented in classic programming languages, our subject system uses the popular return-code idiom for dealing with exceptions. Our goal is to evaluate t ..."
Abstract
-
Cited by 34 (1 self)
- Add to MetaCart
(Show Context)
ABSTRACT In this paper, we analyse the exception handling mechanism of a state-of-the-art industrial embedded software system. Like many systems implemented in classic programming languages, our subject system uses the popular return-code idiom for dealing with exceptions. Our goal is to evaluate the fault-proneness of this idiom, and we therefore present a characterisation of the idiom, a fault model accompanied by an analysis tool, and empirical data. Our findings show that the idiom is indeed fault prone, but that a simple solution can lead to significant improvements.
