It has been broadly assumed that code clones are inherently bad and that eliminating clones by refactoring would solve the problems of code clones. To investigate the validity of this assumption, we developed a formal definition of clone evolution and built a clone genealogy tool that automatically extracts the history of code clones from a source code repository. Using our tool we extracted clone genealogy information for two Java open source projects and analyzed their evolution.Our study contradicts some conventional wisdom about clones. In particular, refactoring may not always improve software with respect to clones for two reasons. First, many code clones exist in the system for only a short time; extensive refactoring of such short-lived clones may not be worthwhile if they are likely diverge from one another very soon. Second, many clones, especially long-lived clones that have changed consistently with other elements in the same group, are not easily refactorable due to programming language limitations. These insights show that refactoring will not help in dealing with some types of clones and open up opportunities for complementary clone maintenance tools that target these other classes of clones.
In this paper we present a method of code implementation that works in conjunction with collaboration and responsibility based analysis modeling techniques to achieve better code reuse and resilience to change.Our approach maintains a closer mapping from responsibilities in the analysis model to entities in the implementation.In so doing, it leverages the features of flexible design and design reuse found in collaboration-based design models to provide similar adaptability and reuse in the implementation.Our approach requires no special development tools and uses only standard features available in the C++ language.In an earlier paper we described the basic mechanisms used by our approach and discussed its advantages in comparison to the framework approach. In this paper we show how our approach combines code and design reuse, describing specific techniques that can be used in the development of larger applications.
We present an approach that eases the design and evolution of integrated environments by increasing independence among components.
Parnas' seminal 1972 paper, "On the Criteria To Be
The field of program analysis has made significant improvements recently, but still faces some major obstacles. In this talk I argue that considering analysis as applying longitudinally across the multitude of versions created during a program's lifetime -rather than to a given instance of a program - shows significant promise in overcoming some of these obstacles. I focus on identifying a set of opportunities that arise when this shift in outlook is taken.Most program analysis techniques have focused on questions of the form "Does program P satisfy a given property A?" or "What program points in P satisfy a given property A?" Type-checking is the classic example of the first form, while lexical, syntactic, and semantic analyses are examples of the second form. The key point (with respect to this talk) is that a single program P is being analyzed.Some analyses expand this view and explicitly consider a pair of programs, P and P', where P' represents a modified version of P. Test selection and prioritization techniques are among the best examples of this approach: the idea is to analyze the delta between P and P', and to use that information to determine which test cases must be re-run (for test selection) or should be re-run (for test prioritization). (There are dozens of results in these areas; Harrold et al.'s empirical study is one recent example of test selection [1], and the recent work at Microsoft Research is an example of test prioritization [2].There are at least three ways in which a longitudinal approach could improve analysis.Second, we can use previously computed information to better inform analysis on a newer version. One recent example of this is the work by Kim and Porter that uses historical information about the application of tests of a set of versions as a basis for test prioritization algorithms [3].Third, we can imagine applying otherwise "intractable" analyses over the lifetime of (multiple versions of) a program, as opposed to the (much more limited) time available to analyze a specific version. In essence, there is an opportunity to compute the analysis in stages, with the goal of completing the analysis by specific important points in the program lifetime (e.g., external releases). Work on vertical staging of analyses for runtime compilation is one place to look for ideas and techniques for this kind of "horizontal" staging [4].The traditional view of software evolution says that (to accommodate needed change) program structure degrades and program size increases [5][6]; this in turn tends to increase the difficult of analysis. I propose here some opportunities for viewing time and change as potential benefits with respect to analysis, rather than as roadblocks. This provides potential for significantly improving software dependability over time.
scite is a Brooklyn-based organization that helps researchers better discover and understand research articles through Smart Citations–citations that display the context of the citation and describe whether the article provides supporting or contrasting evidence. scite is used by students and researchers from around the world and is funded in part by the National Science Foundation and the National Institute on Drug Abuse of the National Institutes of Health.
hi@scite.ai
10624 S. Eastern Ave., Ste. A-614
Henderson, NV 89052, USA
Copyright © 2024 scite LLC. All rights reserved.
Made with 💙 for researchers
Part of the Research Solutions Family.