157 research outputs found
Class movement and re-location: An empirical study of Java inheritance evolution
This is the post-print version of the final paper published in Journal of Systems and Software. The published article is available from the link below. Changes resulting from the publishing process, such as peer review, editing, corrections, structural formatting, and other quality control mechanisms may not be reflected in this document. Changes may have been made to this work since it was submitted for publication. Copyright @ 2009 Elsevier B.V.Inheritance is a fundamental feature of the Object-Oriented (OO) paradigm. It is used to promote extensibility and reuse in OO systems. Understanding how systems evolve, and specifically, trends in the movement and re-location of classes in OO hierarchies can help us understand and predict future maintenance effort. In this paper, we explore how and where new classes were added as well as where existing classes were deleted or moved across inheritance hierarchies from multiple versions of four Java systems. We observed first, that in one of the studied systems the same set of classes was continuously moved across the inheritance hierarchy. Second, in the same system, the most frequent changes were restricted to just one sub-part of the overall system. Third, that a maximum of three levels may be a threshold when using inheritance in a system; beyond this level very little activity was observed, supporting earlier theories that, beyond three levels, complexity becomes overwhelming. We also found evidence of âcollapsingâ hierarchies to bring classes up to shallower levels. Finally, we found that larger classes and highly coupled classes were more frequently moved than smaller and less coupled classes. Statistical evidence supported the view that larger classes and highly coupled classes were less cohesive than smaller classes and lowly coupled classes and were thus more suitable candidates for being moved (within an hierarchy)
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
Do internal software quality tools measure validated metrics?
Internal software quality determines the maintainability of the software
product and influences the quality in use. There is a plethora of metrics which
purport to measure the internal quality of software, and these metrics are
offered by static software analysis tools. To date, a number of reports have
assessed the validity of these metrics. No data are available, however, on
whether metrics offered by the tools are somehow validated in scientific
studies. The current study covers this gap by providing data on which tools and
how many validated metrics are provided. The results show that a range of
metrics that the tools provided do not seem to be validated in the literature
and that only a small percentage of metrics are validated in the provided
tools
Effects of Test-Driven Development : A Comparative Analysis of Empirical Studies
Test-driven development is a software development practice where small sections of test code are used to direct the development of program units. Writing test code prior to the production code promises several positive effects on the development process itself and on associated products and processes as well. However, there are few comparative studies on the effects of test-driven development. Thus, it is difficult to assess the potential process and product effects when applying test-driven development. In order to get an overview of the observed effects of test-driven development, an in-depth review of existing empirical studies was carried out. The results for ten different internal and external quality attributes indicate that test-driven development can reduce the amount of introduced defects and lead to more maintainable code. Parts of the implemented code may also be somewhat smaller in size and complexity. While maintenance of test-driven code can take less time, initial development may last longer. Besides the comparative analysis, this article sketches related work and gives an outlook on future research.Peer reviewe
Zones of pain:Visualising the relationship between software architecture and defects
Substantial development time is devoted to software maintenance and testing. As development resources are usually finite, there is a risk that some components receive insufficient effort for thorough testing. Architectural complexity (e.g. tight coupling) can make effective testing particularly challenging. Software components with high architectural complexity are more likely be defectâprone. The aim of this study is to investigate the relationship between established architectural attributes and defectâproneness. We used the architectural attributes: abstractness, instability and distance to measure the architectural complexity of software components. We investigated the ability of these attributes to discriminate between defective and non-defective components on four open source systems. We visualised defectâproneness by plotting architectural complexity and defectiveness using Martinâs âZones of Painâ. Our results show that architecture has an inconsistent impact on defectâproneness. Some architecturally complex components seem immune to defects in some projects. In other projects architecturally complex components significantly suffer from defects. Where architectural complexity does increase defectâproneness the impact is strong. We recommend practitioners monitor the architectural complexity of their software components over time by visualising potential defectâproneness using Martinâs Zones of Pain
Comparing Static and Dynamic Weighted Software Coupling Metrics
Coupling metrics that count the number of inter-module connections in a software system
are an established way to measure internal software quality with respect to modularity. In addition to
static metrics, which are obtained from the source or compiled code of a program, dynamic metrics
use runtime data gathered, e.g., by monitoring a system in production. Dynamic metrics have been
used to improve the accuracy of static metrics for object-oriented software. We study weighted
dynamic coupling that takes into account how often a connection (e.g., a method call) is executed
during a systemâs run. We investigate the correlation between dynamic weighted metrics and their
static counterparts. To compare the different metrics, we use data collected from four different
experiments, each monitoring production use of a commercial software system over a period of four
weeks. We observe an unexpected level of correlation between the static and the weighted dynamic
case as well as revealing differences between class- and package-level analyses
Evaluating code complexity triggers, use of complexity measures and the influence of code complexity on maintenance time
- âŠ