6,121 research outputs found
State of Refactoring Adoption: Better Understanding Developer Perception of Refactoring
We aim to explore how developers document their refactoring activities during
the software life cycle. We call such activity Self-Affirmed Refactoring (SAR),
which indicates developers' documentation of their refactoring activities. SAR
is crucial in understanding various aspects of refactoring, including the
motivation, procedure, and consequences of the performed code change. After
that, we propose an approach to identify whether a commit describes
developer-related refactoring events to classify them according to the
refactoring common quality improvement categories. To complement this goal, we
aim to reveal insights into how reviewers decide to accept or reject a
submitted refactoring request and what makes such a review challenging.Our SAR
taxonomy and model can work with refactoring detectors to report any early
inconsistency between refactoring types and their documentation. They can serve
as a solid background for various empirical investigations. Our survey with
code reviewers has revealed several difficulties related to understanding the
refactoring intent and implications on the functional and non-functional
aspects of the software. In light of our findings from the industrial case
study, we recommended a procedure to properly document refactoring activities,
as part of our survey feedback.Comment: arXiv admin note: text overlap with arXiv:2010.13890,
arXiv:2102.05201, arXiv:2009.0927
Invertible Program Restructurings for Continuing Modular Maintenance
When one chooses a main axis of structural decompostion for a software, such
as function- or data-oriented decompositions, the other axes become secondary,
which can be harmful when one of these secondary axes becomes of main
importance. This is called the tyranny of the dominant decomposition. In the
context of modular extension, this problem is known as the Expression Problem
and has found many solutions, but few solutions have been proposed in a larger
context of modular maintenance. We solve the tyranny of the dominant
decomposition in maintenance with invertible program transformations. We
illustrate this on the typical Expression Problem example. We also report our
experiments with Java and Haskell programs and discuss the open problems with
our approach.Comment: 6 pages, Early Research Achievements Track; 16th European Conference
on Software Maintenance and Reengineering (CSMR 2012), Szeged : Hungary
(2012
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
Refactoring Functional Programs
Refactoring is the process of redesigning existing code without changing its functionality. Refactoring has recently come to prominence in the OO community. In this paper we explore the prospects for refactoring functional programs. Our paper centres on the case study of refactoring a 400 line Haskell program written by one of our students. The case study illustrates the type and variety of program manipulations involved in refactoring. Similarly to other program transformations, refactorings are based on program equivalences, and thus ultimately on language semantics. In the context of functional languages, refactorings can be based on existing theory and program analyses. However, the use of program transformations for program restructuring emphasises a different kind of transformation from the more traditional derivation or optimisation: characteristically, they often require wholesale changes to a collection of modules, and although they are best controlled by programmers, their application may require nontrivial semantic analyses. The paper also explores the background to refactoring, provides a taxonomy for describing refactorings and draws some conclusions about refactoring for functional programs
A Systematic Aspect-Oriented Refactoring and Testing Strategy, and its Application to JHotDraw
Aspect oriented programming aims at achieving better modularization for a
system's crosscutting concerns in order to improve its key quality attributes,
such as evolvability and reusability. Consequently, the adoption of
aspect-oriented techniques in existing (legacy) software systems is of interest
to remediate software aging. The refactoring of existing systems to employ
aspect-orientation will be considerably eased by a systematic approach that
will ensure a safe and consistent migration.
In this paper, we propose a refactoring and testing strategy that supports
such an approach and consider issues of behavior conservation and (incremental)
integration of the aspect-oriented solution with the original system. The
strategy is applied to the JHotDraw open source project and illustrated on a
group of selected concerns. Finally, we abstract from the case study and
present a number of generic refactorings which contribute to an incremental
aspect-oriented refactoring process and associate particular types of
crosscutting concerns to the model and features of the employed aspect
language. The contributions of this paper are both in the area of supporting
migration towards aspect-oriented solutions and supporting the development of
aspect languages that are better suited for such migrations.Comment: 25 page
Detecting and Refactoring Operational Smells within the Domain Name System
The Domain Name System (DNS) is one of the most important components of the
Internet infrastructure. DNS relies on a delegation-based architecture, where
resolution of names to their IP addresses requires resolving the names of the
servers responsible for those names. The recursive structures of the inter
dependencies that exist between name servers associated with each zone are
called dependency graphs. System administrators' operational decisions have far
reaching effects on the DNSs qualities. They need to be soundly made to create
a balance between the availability, security and resilience of the system. We
utilize dependency graphs to identify, detect and catalogue operational bad
smells. Our method deals with smells on a high-level of abstraction using a
consistent taxonomy and reusable vocabulary, defined by a DNS Operational
Model. The method will be used to build a diagnostic advisory tool that will
detect configuration changes that might decrease the robustness or security
posture of domain names before they become into production.Comment: In Proceedings GaM 2015, arXiv:1504.0244
A Case Study in Refactoring Functional Programs
Refactoring is the process of redesigning existing code without changing its functionality. Refactoring has recently come to prominence in the OO community. In this paper we explore the prospects for refactoring functional programs. Our paper centres on the case study of refactoring a 400 line Haskell program written by one of our students. The case study illustrates the type and variety of program manipulations involved in refactoring. Similarly to other program transformations, refactorings are based on program equivalences, and thus ultimately on language semantics. In the context of functional languages, refactorings can be based on existing theory and program analyses. However, the use of program transformations for program restructuring emphasises a different kind of transformation from the more traditional derivation or optimisation: characteristically, they often require wholesale changes to a collection of modules, and although they are best controlled by programmers, their application may require nontrivial semantic analyses. The paper also explores the background to refactoring, provides a taxonomy for describing refactorings and draws some conclusions about refactoring for functional programs
Technical Debt Prioritization: State of the Art. A Systematic Literature Review
Background. Software companies need to manage and refactor Technical Debt
issues. Therefore, it is necessary to understand if and when refactoring
Technical Debt should be prioritized with respect to developing features or
fixing bugs. Objective. The goal of this study is to investigate the existing
body of knowledge in software engineering to understand what Technical Debt
prioritization approaches have been proposed in research and industry. Method.
We conducted a Systematic Literature Review among 384 unique papers published
until 2018, following a consolidated methodology applied in Software
Engineering. We included 38 primary studies. Results. Different approaches have
been proposed for Technical Debt prioritization, all having different goals and
optimizing on different criteria. The proposed measures capture only a small
part of the plethora of factors used to prioritize Technical Debt qualitatively
in practice. We report an impact map of such factors. However, there is a lack
of empirical and validated set of tools. Conclusion. We observed that technical
Debt prioritization research is preliminary and there is no consensus on what
are the important factors and how to measure them. Consequently, we cannot
consider current research conclusive and in this paper, we outline different
directions for necessary future investigations
Software model refactoring based on performance analysis: better working on software or performance side?
Several approaches have been introduced in the last few years to tackle the
problem of interpreting model-based performance analysis results and
translating them into architectural feedback. Typically the interpretation can
take place by browsing either the software model or the performance model. In
this paper, we compare two approaches that we have recently introduced for this
goal: one based on the detection and solution of performance antipatterns, and
another one based on bidirectional model transformations between software and
performance models. We apply both approaches to the same example in order to
illustrate the differences in the obtained performance results. Thereafter, we
raise the level of abstraction and we discuss the pros and cons of working on
the software side and on the performance side.Comment: In Proceedings FESCA 2013, arXiv:1302.478
- …