No abstract

Reusing software through copying and pasting is a continuous plague in software development despite the fact that it creates serious maintenance problems. Various techniques have been proposed to find duplicated redundant code (also known as software clones). A recent study has compared these techniques and shown that token-based clone detection based on suffix trees is fast but yields clone candidates that are often not syntactic units. Current techniques based on abstract syntax trees-on the other hand-find syntactic clones but are considerably less efficient. This paper describes how we can make use of suffix trees to find syntactic clones in abstract syntax trees. This new approach is able to find syntactic clones in linear time and space. The paper reports the results of a large case study in which we empirically compare the new technique to other techniques using the Bellon benchmark for clone detectors. The Bellon benchmark consists of clone pairs validated by humans for eight software systems written in C or Java from different application domains. The new contributions of this paper over the conference paper are the additional analysis of Java programs, the exploration of an alternative path that uses parse trees instead of abstract syntax trees, and the investigation of the impact on recall and precision when clone analyses insist on consistent parameter renaming.

Software variants emerge from ad-hoc copying in-the-large with adaptations to a specific context. As the number of variants increases, maintaining such software variants becomes more and more difficult and expensive. In contrast to such ad-hoc reuse, software product lines offer organized ways of reuse, taking advantage of similarities of different products. To re-gain control, software variants may be consolidated as organized software product lines. In this paper, we describe a method and supporting tools to compare software variants at the architectural level extending the reflexion method to software variants. Murphy's reflexion method allows one to reconstruct the module view, a static architectural view describing the static components, their interfaces and dependencies and their grouping as layers and subsystems. The method consists of the specification of the module view and the mapping of implementation components onto the module view. An automatic analysis determines differences between the module view and its implementation. We extend the reflexion method from single systems to software variants. Because software variants share a very large amount of code, we can expect components of one variant to re-occur in the other variant either identically or at least similarly. We use similarity metrics to determine this type of correspondence among implementation components between two variants. Because the similarity metrics are expensive to compute, we use clone detection techniques to reduce the number of candidate pairs of implementation components for which the similarity is computed. The correspondence is then used to transfer as much as possible of the mapping for the analyzed variants to the next variant to be analyzed. Furthermore, we describe how to unify the individual product architectures into a software product line architecture.

Software variants emerge from ad-hoc copying inthe-large with adaptations to a specific context. As the number of variants increases, maintaining such software variants becomes more and more difficult and expensive. In contrast to such ad-hoc reuse, software product lines offer organized ways of reuse, taking advantage of similarities of different products. To re-gain control, software variants may be consolidated as organized software product lines.In this paper, we describe a method and supporting tools to compare software variants at the architectural level extending the reflexion method to software variants. Murphy's reflexion method allows one to reconstruct the module view, a static architectural view describing the static components, their interfaces and dependencies and their grouping as layers and subsystems. The method consists of the specification of the module view and the mapping of implementation components onto the module view. An automatic analysis determines differences between the module view and its implementation.We extend the reflexion method from single systems to software variants. Because software variants share a very large amount of code, we use clone detection techniques to identify corresponding implementation components between variants. The correspondence is then used to transfer as much of the mapping for the analyzed variants to the next variant to be analyzed.