84 research outputs found

    Evaluating the relation between changeability decay and the characteristics of clones and methods

    Get PDF
    In this paper we propose a methodology to evaluate if there is a relation between two code characteristics. The methodology is based on relative risk, an epidemiology formula used to analyze the effect of toxic agents in developing diseases. We present a metaphor in which the disease is changeability decay, measured at method level, and the toxic agent is a source code characteristic considered harmful. However, the formula assesses the strength of the relation between any toxic agent and any disease. We apply the methodology to explore cloning as a toxic agent that increases the risk of changeability decay. Cloning is a good agent to analyze given that although there is some evidence of maintainability issues caused by clones, we do not know which clones are harmful, or to what extent. We compare cloning with other possible 'toxic agents', like having high complexity or having high fan-in. We also use the technique to evaluate which clone characteristics (like clone size) may indicate harmful clones, by testing such characteristics as toxic agents. We found that cloning is one of the method characteristics that affects the least changeability decay, and that none of the clone characteristics analyzed are related with changeability decay

    Assessing the effect of source code characteristics on changeability

    Get PDF
    Maintenance is the phase of the software lifecycle that comprises any modification after the delivery of an application. Modifications during this phase include correcting faults, improving internal attributes, as well as adapting the application to different environments. As application knowledge and architectural integrity degrade over time, so does the facility with which changes to the application are introduced. Thus, eliminating source code that presents characteristics that hamper maintenance becomes necessary if the application is to evolve. We group these characteristics under the term Source Code Issues. Even though there is support for detecting Source Code Issues, the extent of their harmfulness for maintenance remains unknown. One of the most studied Source Code Issue is cloning. Clones are duplicated code, usually created as programmers copy, paste, and customize existing source code. However, there is no agreement on the harmfulness of clones. This thesis proposes and follows a novel methodology to assess the effect of clones on the changeability of methods. Changeability is the ease with which a source code entity is modified. It is assessed through metrics calculated from the history of changes of the methods. The impact of clones on the changeability of methods is measured by comparing the metrics of methods that contain clones to those that do not. Source code characteristics are then tested to establish whether they are endemic of methods whose changeability decay increase when cloned. In addition to findings on the harmfulness of cloning, this thesis contributes a methodology that can be applied to assess the harmfulness of other Source Code Issues. The contributions of this thesis are twofold. First, the findings answer the question about the harmfulness of clones on changeability by showing that cloned methods are more likely to change, and that some cloned methods have significantly higher changeability decay when cloned. Furthermore, it offers a characterization of such harmful clones. Second, the methodology provides a guide to analyze the effect of Source Code Characteristics in changeability; and therefore, can be adapted for other Source Code Issues

    Is cloned code older than non-cloned code?

    Full text link
    It is still a debated question whether cloned code causes increased maintenance efforts. If cloned code is more stable than non-cloned code, i.e. it is changed less often, it will require less maintenance efforts. The more stable cloned code is, the longer it will not have been changed, so the stability can be estimated through the code's age. This paper presents a study on the average age of cloned code. For three large open source systems, the age of every line of source code is computed as the date of the last change in that line. In addition, every line is categorized whether it belongs to cloned code as detected by a clone detector. The study shows that on average, cloned code is older than non-cloned code. Moreover, if a file has cloned code, the average age of the cloned code of the file is lower than the average age of the non-cloned code in the same file. The results support the previous findings that cloned code is more stable than non-cloned code. © 2011 ACM

    Code Smells and Refactoring: A Tertiary Systematic Review of Challenges and Observations

    Full text link
    In this paper, we present a tertiary systematic literature review of previous surveys, secondary systematic literature reviews, and systematic mappings. We identify the main observations (what we know) and challenges (what we do not know) on code smells and refactoring. We show that code smells and refactoring have a strong relationship with quality attributes, i.e., with understandability, maintainability, testability, complexity, functionality, and reusability. We argue that code smells and refactoring could be considered as the two faces of a same coin. Besides, we identify how refactoring affects quality attributes, more than code smells. We also discuss the implications of this work for practitioners, researchers, and instructors. We identify 13 open issues that could guide future research work. Thus, we want to highlight the gap between code smells and refactoring in the current state of software-engineering research. We wish that this work could help the software-engineering research community in collaborating on future work on code smells and refactoring

    KUANTIFIKASI PENGARUH KLONING DAN KOMPLEKSITAS KODE TERHADAP CACAT PADA EVOLUSI PERANGKAT LUNAK

    Get PDF
    Kloning adalah hal yang biasa dilakukan oleh seorang pengembang dalam mengembangkan sebuah perangkat lunak. Kloning dapat menyebabkan menurunnya tingkat perawatan (maintainability) sebuah perangkat lunak. Kloning membutuhkan perhatian yang besar, karena kurangnya perhatian terhadap kloning kode akan menimbulkan sebuah kondisi yang tidak konsisten. Kondisi tidak konsisten dapat menimbulkan cacat perangkat lunak. Selain itu, cacat perangkat lunak dapat ditimbulkan oleh atribut-atribut kode, antara lain adalah kompleksitas kode. Tujuan penelitian ini adalah mencari tahu nilai keterkaitan antara kloning kode, kompleksitas kode, dan LOC (Line of Code) terhadap kemungkinan terjadinya cacat (defect) perangkat lunak. Pencarian hubungan antara kloning, kompleksitas kode, dan LOC dengan cacat dilakukan dengan pendekatan statistika. Regresi dan korelasi adalah metode yang digunakan untuk mencari keterkaitan antara beberapa hal. Penelitian ini menyimpulkan bahwa ketiga atribut kode (kloning, kompleksitas dan LOC) mempengaruhi terjadinya cacat pada perangkat lunak dengan nilai yang besar, yaitu 95%. Masing-masing atribut kode (kloning, kompleksitas dan LOC) memiliki pengaruh yang berbeda -beda. Kloning tidak selalu menjadi pencetus terjadinya cacat yang paling besar

    Technical Debt Decision-Making Framework

    Get PDF
    Software development companies strive to produce high-quality software. In commercial software development environments, due to resource and time constraints, software is often developed hastily which gives rise to technical debt. Technical debt refers to the consequences of taking shortcuts when developing software. These consequences include making the system difficult to maintain and defect prone. Technical debt can have financial consequences and impede feature enhancements. Identifying technical debt and deciding which debt to address is challenging given resource constraints. Project managers must decide which debt has the highest priority and is most critical to the project. This decision-making process is not standardized and sometimes differs from project to project. My research goal is to develop a framework that project managers can use in their decision-making process to prioritize technical debt based on its potential impact. To achieve this goal, we survey software practitioners, conduct literature reviews, and mine software repositories for historical data to build a framework to model the technical debt decision-making process and inform practitioners of the most critical debt items

    Technical Debt Decision-Making Framework

    Get PDF
    Software development companies strive to produce high-quality software. In commercial software development environments, due to resource and time constraints, software is often developed hastily which gives rise to technical debt. Technical debt refers to the consequences of taking shortcuts when developing software. These consequences include making the system difficult to maintain and defect prone. Technical debt can have financial consequences and impede feature enhancements. Identifying technical debt and deciding which debt to address is challenging given resource constraints. Project managers must decide which debt has the highest priority and is most critical to the project. This decision-making process is not standardized and sometimes differs from project to project. My research goal is to develop a framework that project managers can use in their decision-making process to prioritize technical debt based on its potential impact. To achieve this goal, we survey software practitioners, conduct literature reviews, and mine software repositories for historical data to build a framework to model the technical debt decision-making process and inform practitioners of the most critical debt items

    Animating the evolution of software

    Get PDF
    The use and development of open source software has increased significantly in the last decade. The high frequency of changes and releases across a distributed environment requires good project management tools in order to control the process adequately. However, even with these tools in place, the nature of the development and the fact that developers will often work on many other projects simultaneously, means that the developers are unlikely to have a clear picture of the current state of the project at any time. Furthermore, the poor documentation associated with many projects has a detrimental effect when encouraging new developers to contribute to the software. A typical version control repository contains a mine of information that is not always obvious and not easy to comprehend in its raw form. However, presenting this historical data in a suitable format by using software visualisation techniques allows the evolution of the software over a number of releases to be shown. This allows the changes that have been made to the software to be identified clearly, thus ensuring that the effect of those changes will also be emphasised. This then enables both managers and developers to gain a more detailed view of the current state of the project. The visualisation of evolving software introduces a number of new issues. This thesis investigates some of these issues in detail, and recommends a number of solutions in order to alleviate the problems that may otherwise arise. The solutions are then demonstrated in the definition of two new visualisations. These use historical data contained within version control repositories to show the evolution of the software at a number of levels of granularity. Additionally, animation is used as an integral part of both visualisations - not only to show the evolution by representing the progression of time, but also to highlight the changes that have occurred. Previously, the use of animation within software visualisation has been primarily restricted to small-scale, hand generated visualisations. However, this thesis shows the viability of using animation within software visualisation with automated visualisations on a large scale. In addition, evaluation of the visualisations has shown that they are suitable for showing the changes that have occurred in the software over a period of time, and subsequently how the software has evolved. These visualisations are therefore suitable for use by developers and managers involved with open source software. In addition, they also provide a basis for future research in evolutionary visualisations, software evolution and open source development
    corecore