5,864 research outputs found
Are Smell-Based Metrics Actually Useful in Effort-Aware Structural Change-Proneness Prediction? An Empirical Study
Bad code smells (also named as code smells) are symptoms of poor design choices in implementation. Existing studies empirically confirmed that the presence of code smells increases the likelihood of subsequent changes (i.e., change-proness). However, to the best of our knowledge, no prior studies have leveraged smell-based metrics to predict particular change type (i.e., structural changes). Moreover, when evaluating the effectiveness of smell-based metrics in structural change-proneness prediction, none of existing studies take into account of the effort inspecting those change-prone source code. In this paper, we consider five smell-based metrics for effort-aware structural change-proneness prediction and compare these metrics with a baseline of well-known CK metrics in predicting particular categories of change types. Specifically, we first employ univariate logistic regression to analyze the correlation between each smellbased metric and structural change-proneness. Then, we build multivariate prediction models to examine the effectiveness of smell-based metrics in effort-aware structural change-proneness prediction when used alone and used together with the baseline metrics, respectively. Our experiments are conducted on six Java open-source projects with up to 60 versions and results indicate that: (1) all smell-based metrics are significantly related to structural change-proneness, except metric ANS in hive and SCM in camel after removing confounding effect of file size; (2) in most cases, smell-based metrics outperform the baseline metrics in predicting structural change-proneness; and (3) when used together with the baseline metrics, the smell-based metrics are more effective to predict change-prone files with being aware of inspection effort
How Scale Affects Structure in Java Programs
Many internal software metrics and external quality attributes of Java
programs correlate strongly with program size. This knowledge has been used
pervasively in quantitative studies of software through practices such as
normalization on size metrics. This paper reports size-related super- and
sublinear effects that have not been known before. Findings obtained on a very
large collection of Java programs -- 30,911 projects hosted at Google Code as
of Summer 2011 -- unveils how certain characteristics of programs vary
disproportionately with program size, sometimes even non-monotonically. Many of
the specific parameters of nonlinear relations are reported. This result gives
further insights for the differences of "programming in the small" vs.
"programming in the large." The reported findings carry important consequences
for OO software metrics, and software research in general: metrics that have
been known to correlate with size can now be properly normalized so that all
the information that is left in them is size-independent.Comment: ACM Conference on Object-Oriented Programming, Systems, Languages and
Applications (OOPSLA), October 2015. (Preprint
Assessing architectural evolution: A case study
This is the post-print version of the Article. The official published can be accessed from the link below - Copyright @ 2011 SpringerThis paper proposes to use a historical perspective on generic laws, principles,
and guidelines, like Lehmanās software evolution laws and Martinās design principles, in order to achieve a multi-faceted process and structural assessment of a systemās architectural evolution. We present a simple structural model with associated historical metrics and
visualizations that could form part of an architectās dashboard. We perform such an assessment for the Eclipse SDK, as a case study of a large, complex, and long-lived system for which sustained effective architectural evolution is paramount. The twofold aim of checking generic principles on a well-know system is, on the one hand,
to see whether there are certain lessons that could be learned for best practice of architectural evolution, and on the other hand to get more insights about the applicability of such principles. We find that while the Eclipse SDK does follow several of the laws and principles, there are some deviations, and we discuss areas of architectural improvement and limitations of the assessment approach
RePOR: Mimicking humans on refactoring tasks. Are we there yet?
Refactoring is a maintenance activity that aims to improve design quality
while preserving the behavior of a system. Several (semi)automated approaches
have been proposed to support developers in this maintenance activity, based on
the correction of anti-patterns, which are `poor' solutions to recurring design
problems. However, little quantitative evidence exists about the impact of
automatically refactored code on program comprehension, and in which context
automated refactoring can be as effective as manual refactoring. Leveraging
RePOR, an automated refactoring approach based on partial order reduction
techniques, we performed an empirical study to investigate whether automated
refactoring code structure affects the understandability of systems during
comprehension tasks. (1) We surveyed 80 developers, asking them to identify
from a set of 20 refactoring changes if they were generated by developers or by
a tool, and to rate the refactoring changes according to their design quality;
(2) we asked 30 developers to complete code comprehension tasks on 10 systems
that were refactored by either a freelancer or an automated refactoring tool.
To make comparison fair, for a subset of refactoring actions that introduce new
code entities, only synthetic identifiers were presented to practitioners. We
measured developers' performance using the NASA task load index for their
effort, the time that they spent performing the tasks, and their percentages of
correct answers. Our findings, despite current technology limitations, show
that it is reasonable to expect a refactoring tools to match developer code
Using a Combination of Measurement Tools to Extract Metrics from Open Source Projects
Software measurement can play a major role in ensuring the quality and reliability of software products. The measurement activities require appropriate tools to collect relevant metric data. Currently, there are several such tools available for software measurement. The main objective of this paper is to provide some guidelines in using a combination of multiple measurement tools especially for products built using object-oriented techniques and languages. In this paper, we highlight three tools for collecting metric data, in our case from several Java-based open source projects. Our research is currently based on the work of Card and Glass, who argue that design complexity measures (data complexity and structural complexity) are indicators/predictors of procedural/cyclomatic complexity (decision counts) and errors (discovered from system tests). Their work was centered on structured design and our work is with object-oriented designs and the metrics we use parallel those of Card and Glass, being, Henry and Kafura's Information Flow Metrics, McCabe's Cyclomatic Complexity, and Chidamber and Kemerer Object-oriented Metrics
Mutation Testing as a Safety Net for Test Code Refactoring
Refactoring is an activity that improves the internal structure of the code
without altering its external behavior. When performed on the production code,
the tests can be used to verify that the external behavior of the production
code is preserved. However, when the refactoring is performed on test code,
there is no safety net that assures that the external behavior of the test code
is preserved. In this paper, we propose to adopt mutation testing as a means to
verify if the behavior of the test code is preserved after refactoring.
Moreover, we also show how this approach can be used to identify the part of
the test code which is improperly refactored
Does class size matter? An in-depth assessment of the effect of class size in software defect prediction
In the past 20 years, defect prediction studies have generally acknowledged
the effect of class size on software prediction performance. To quantify the
relationship between object-oriented (OO) metrics and defects, modelling has to
take into account the direct, and potentially indirect, effects of class size
on defects. However, some studies have shown that size cannot be simply
controlled or ignored, when building prediction models. As such, there remains
a question whether, and when, to control for class size. This study provides a
new in-depth examination of the impact of class size on the relationship
between OO metrics and software defects or defect-proneness. We assess the
impact of class size on the number of defects and defect-proneness in software
systems by employing a regression-based mediation (with bootstrapping) and
moderation analysis to investigate the direct and indirect effect of class size
in count and binary defect prediction. Our results show that the size effect is
not always significant for all metrics. Of the seven OO metrics we
investigated, size consistently has significant mediation impact only on the
relationship between Coupling Between Objects (CBO) and
defects/defect-proneness, and a potential moderation impact on the relationship
between Fan-out and defects/defect-proneness. Based on our results we make
three recommendations. One, we encourage researchers and practitioners to
examine the impact of class size for the specific data they have in hand and
through the use of the proposed statistical mediation/moderation procedures.
Two, we encourage empirical studies to investigate the indirect effect of
possible additional variables in their models when relevant. Three, the
statistical procedures adopted in this study could be used in other empirical
software engineering research to investigate the influence of potential
mediators/moderators.Comment: Accepted to Empirical Software Engineering (to appear). arXiv admin
note: text overlap with arXiv:2104.1234
Can we avoid high coupling?
It is considered good software design practice to organize source code into modules and to favour within-module connections (cohesion) over between-module connections (coupling), leading to the oft-repeated maxim "low coupling/high cohesion". Prior research into network theory and its application to software systems has found evidence that many important properties in real software systems exhibit approximately scale-free structure, including coupling; researchers have claimed that such scale-free structures are ubiquitous. This implies that high coupling must be unavoidable, statistically speaking, apparently contradicting standard ideas about software structure. We present a model that leads to the simple predictions that approximately scale-free structures ought to arise both for between-module connectivity and overall connectivity, and not as the result of poor design or optimization shortcuts. These predictions are borne out by our large-scale empirical study. Hence we conclude that high coupling is not avoidable--and that this is in fact quite reasonable
- ā¦