Comparison and Evaluation of Clone Detection Tools

Many techniques for detecting duplicated source code (software clones) have been proposed in the past. However, it is not yet clear how these techniques compare in terms of recall and precision as well as space and time requirements. This paper presents an experiment that evaluates six clone detectors based on eight large C and Java programs (altogether almost 850 KLOC). Their clone candidates were evaluated by one of the authors as an independent third party. The selected techniques cover the whole spectrum of the state-of-the-art in clone detection. The techniques work on text, lexical and syntactic information, software metrics, and program dependency graphs

Identifying Refactoring Opportunities for Removing Code Clones with A Metrics-based Approach

Java in Academia and Research (2nd Edition)978-1-922227-010 (Hardcover)978-1-481261-609 (Paperback

Spreadsheet-Fehlermuster

In den Achtzigern begann eine weitgehende Verbreitung von Spreadsheets in der Industrie als Folge davon, das Spreadsheet-Software für den PC erschienen ist, mit der auch nicht-programmiererfahrene Endnutzer Spreadsheets erzeugen und bearbeiten konnten. Heutzutage sind sie in fast allen Unternehmen nicht mehr weg zu denken. Jedoch zeigen viele Studien, dass ein Großteil dieser Spreadsheets Fehler enthalten und dadurch jährlich hohe Schäden verursachen. Obwohl Prüfwerkzeuge für Spreadsheets existieren, sind sie auf Grund von entwurfstechnischen Einschränkung in der Industrie nur in geringem Maße einsetzbar. Deshalb wurde an der Universität Stuttgart in bisher je 2 abgeschlossenen Diplom- und Bachelorarbeiten das Spreadsheet Inspection Framework erstellt. Das Ziel des Spreadsheet Inspection Frameworks ist es durch statische und dynamische Prüfungen, die selber erstellt und konfiguriert werden können, auf Fehler im Spreadsheet aufmerksam zu machen. In dieser Arbeit wurden Fehlermuster entwickelt um die statischen Prüfungen des Spreadsheet Inspection Frameworks zu erweitern. Das Fehlermuster "Einer unter Anderen" erkennt Schemata und davon abweichende Zellen finden. "Separate Mehrfachreferenzierung in Formeln" deckt Fehler beim Erstellen von Funktionen auf. "Eingaben an nicht berücksichtigten Stellen" erkennt sowohl falsche als auch fehlende Referenzierungen. Zudem werden Werte erkannt, die in falsche Zellen gesetzt wurden. Das Fehlermuster "Referenzierung auf null-Werte" durchsucht das Spreadsheet nach Referenzierungen, die sich auf eine leere Zelle beziehen. Das "Wortdistanz" Muster sucht mit Hilfe des Levenshtein Algorithmus nach Tippfehlern.In the 1980s began a wide dissemination of spreadsheets in the industry as a result of the release of spreadsheet-software which allow end-users without programming experience to create and handle spreadsheets. It's inconceivable for most companies to work without spreadsheets. Many studies show that most of these spreadsheets contain errors and as a consequence there are high damages per year. Although there are tools for spreadsheets, they are rarely used in the industry because of conceptual restrictions. Because of that the Spreadsheet Inspection Framework was developed at the University Stuttgart as part of two finished diploma thesis and two finished bachelor thesis. The objective of the Spreadsheet Inspection Framework is it to red-flag errors with the help of static and dynamic tests, which can be developed and configurated on their one. In this Thesis smell patterns were developed to enhance the static inspections of the Spreadsheet Inspection Framework. The smell pattern "Einer unter Anderen" recognizes schemata and cells which goes against it. "Separate Mehrfachreferenzierung in Formeln" shows errors at the creating of formulas. "Eingaben an nicht berücksichtigten Stellen" recognizes false and missing references. Furthermore it perceives values which were set into a false cell. The smell pattern "Referenzierung auf null-Werte" searches for references that point to a null value. The "Wortdistanz" pattern searches on the basis of the Levenshtein algorithm for typing errors

Detecting Semantic Method Clones In Java Code Using Method Ioe-behavior

The determination of semantic equivalence is an undecidable problem; however, this dissertation shows that a reasonable approximation can be obtained using a combination of static and dynamic analysis. This study investigates the detection of functional duplicates, referred to as semantic method clones (SMCs), in Java code. My algorithm extends the input-output notion of observable behavior, used in related work [1, 2], to include the effects of the method. The latter property refers to the persistent changes to the heap, brought about by the execution of the method. To differentiate this from the typical input-output behavior used by other researchers, I have coined the term method IOE-Behavior; which means its input-output and effects behavior [3]. Two methods are defined as semantic method clones, if they have identical IOE-Behavior; that is, for the same inputs (actual parameters and initial heap state), they produce the same output (that is result- for non-void methods, an final heap state). The detection process consists of two static pre-filters used to identify candidate clone sets. This is followed by dynamic tests that actually run the candidate methods, to determine semantic equivalence. The first filter groups the methods by type. The second filter refines the output of the first, grouping methods by their effects. This algorithm is implemented in my tool JSCTracker, used to automate the SMC detection process. The algorithm and tool are validated using a case study comprising of 12 open source Java projects, from different application domains and ranging in size from 2 KLOC (thousand lines of code) to 300 KLOC. The objectives of the case study are posed as 4 research questions: 1. Can method IOE-Behavior be used in SMC detection? 2. What is the impact of the use of the pre-filters on the efficiency of the algorithm? 3. How does the performance of method IOE-Behavior compare to using only inputoutput for identifying SMCs? 4. How reliable are the results obtained when method IOE-Behavior is used in SMC detection? Responses to these questions are obtained by checking each software sample with JSCTracker and analyzing the results. The number of SMCs detected range from 0-45 with an average execution time of 8.5 seconds. The use of the two pre-filters reduces the number of methods that reach the dynamic test phase, by an average of 34%. The IOE-Behavior approach takes an average of 0.010 seconds per method while the input-output approach takes an average of 0.015 seconds. The former also identifies an average of 32% false positives, while the SMCs identified using input-output, have an average of 92% false positives. In terms of reliability, the IOE-Behavior method produces results with precision values of an average of 68% and recall value of 76% on average. These reliability values represent an improvement of over 37% (for precision) and 30% (for recall) of the values in related work [4, 5]. Thus, it is my conclusion that IOE-Behavior can be used to detect SMCs in Java code with reasonable reliability