Vorlesung Software-Reengineering

Transkript

1 Vorlesung Software-Reengineering Prof. Dr. Rainer Koschke Arbeitsgruppe Softwaretechnik Fachbereich Mathematik und Informatik Universität Bremen Wintersemester 2005/06 Überblick I 1 Klonerkennung

2 1 Klonerkennung Hintergrund Definitionen und Beispiele Ansätze zur Klonerkennung Verfahren nach Baker Verfahren nach Baxter Verfahren nach Mayrand et al. Vergleich von Wiederholungsfragen Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2005/ / 49 Klonerkennung Lernziele Varianten der Klonerkennung (Erkennung duplizierten Codes) Bezug zu Abstraktionsebenen von Programmdarstellungen Kontext Beseitigung von Redundanz auf Codierungsebene erleichtert nachfolgende Reengineering-Aktivitäten Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2005/ / 49

3 Software-Redundanz Duplikation von Quelltext durch Copy&Paste (Code Cloning) Nummer 1 auf Beck und Fowlers Stink Parade of Bad Smells Konsistente Änderungen an Klonen schwierig erhöhter Wartungsaufwand Gegenmaßnahme Abstraktion durch Funktionen oder Makros Code wird kürzer, klarer und besser wartbar! Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2005/ / 49 Software-Redundanz for (i = 1; i < MAX; i++) { x = func() * y + x; } for (i = 1; i < MAX; i++) { x = func() * y + x; } for (j = 1; j < MAX; j++) { x = func() * y + x; } foo.c bar.c fred.c for (i = 1; i < MAX; i++) { x1 = func() * y1 + x1; } for (i = 1; i < MAX; i++) { x2 = func() * y2 + x2; } Typisch: 5 30 % des Codes sind redundant... Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2005/ / 49

4 Software-Redundanz foo.c bar.c fred.c set_coordinate (&x, y); set_coordinate (&x, y); set_coordinate (&x, y); void set_coordinate ( float *x, float y) { int i; for (i = 1; i < MAX; i++) { *x = func() * y + *x; } } set_coordinate (&x1, y1); set_coordinate (&x2, y2);... und können abstrahiert werden Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2005/ / 49 Copy&Paste-Programmierung Szenario 1: Neue Funktionalität soll hinzugefügt, die ähnlich ist zu einer existierenden. Auswirkungen sind nicht bekannt: Wer benutzt die existierende Funktionalität bereits? Was benutzt die existierende Funktionalität alles? Häufige Folge: Funktion wird kopiert und leicht modifiziert. Szenario 2: Wegen unzureichender Versionskontrolle existieren mehrere Versionen derselben Funktion im selben Code oder in verschiedenen Systemen. Szenario 3: Programmiersprache unterstützt keine Vererbung und keine generischen Einheiten. Compiler bietet kein Inlining. Folge: Code wird dupliziert Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2005/ / 49

5 Folgen der Copy&Paste-Programmierung Die Folgen sind duplizierter Code und damit höherer Aufwand für Wartung, Verstehen und Test: Schwierigere Fehlerkorrektur Quelle subtiler Fehler Höherer Aufwand beim Verstehen Mehr Daten zu analysieren und visualisieren Änderbarkeit leidet = Untersuchungen: 5 30 % Code sind redundant. Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2005/ / 49 Arten von Klonen Die Kopie eines Programmfragments wird Klon genannt. Typ 1 Exakte Kopie Keinerlei Veränderung an der Kopie (bis auf White Space und Kommentaren). Z.B. Inlining von Hand. Typ 2 Kopie mit Umbenennungen (parametrisierte Übereinstimmung) Bezeichner werden in der Kopie umbenannt. Z.B. Wiederverwendung einer Funktion, generische Funktion von Hand Typ 3 Kopie mit weiteren Modifikationen Code der Kopie wird abgeändert, nicht nur Bezeichner. Z.B. Erweiterung einer Funktion. Typ 4 Semantische Klone Verschiedene Implementierungen desselben Konzepts. Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2005/ / 49

6 Beispiele i = l e n g t h ( l ) ; i f ( i < 3) {... } i = l e n g t h ( l ) ; i f ( i < 3) {... } i = l e n g t h ( l ) ; i f ( i < 3) {... } i = l e n g t h ( l ) ; i f ( i < 3) {... } i = l e n g t h ( l ) ; i f ( i < 3) {... } k = l e n g t h ( j ) ; i f ( k < x ) {... } k = l e n g t h ( j ) ; i f ( j < 3) {... } k = l e n g t h ( j ) ; f ( ) ; i f ( k < x ) {... } Typ 1 Typ 2 zwei Typ 2 bzw. ein Typ 2 mit inkonsistenter Umbenennung Typ 3 x = x + 1 ; x++; primitiver Typ 4 Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2005/ / 49 Granularität der Klone Das Ziel der Klonerkennung bestimmt Granularität. Je feiner die Granularität, desto höher der Aufwand. Sequenzen von Anweisungen Beseitigung von manuellem Inlining. Kapselung von Operationen in Unterprogrammen. Unterprogramme und Datenstrukturen Identifikation von Kandidaten für die Einführung generischer Konzepte. Vereinigung von Varianten. Objektifizierung Pakete Wie oben, jedoch im größeren Stil. Säuberung nach gescheiterter Versionskontrolle. Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2005/ / 49

7 Ansätze zur Klonerkennung Die Ansätze unterscheiden sich in Granularität des berücksichtigten Wissens Anweisungssequenzen Funktionen Pakete und der Abstraktionsebene der Analyse Text Token-Ebene Syntax quantifizierbare Merkmale Programmabhängigkeiten Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2005/ / 49 Existierende Ansätze Anzahl unterschiedlicher Zeilen des Unix-Diff-Programmes Pattern Matching auf Ebene der Lexeme (Baker) Matching auf dem abstrakten Syntaxbaum (Baxter et al.) Vergleich quantifizierter Merkmale (Metriken) des Codes (Mayrand et al.) Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2005/ / 49

8 Probleme bei der Erkennung Jede Zeile/Funktion/Datei muss mit jeder anderen Zeile/Funktion/Datei verglichen werden: Wie kann quadratischer Aufwand vermieden werden? Wie kann von Bezeichnern geeignet abstrahiert werden? Soll die Umbenennung konsistent sein? Typ-3-Klone: Geklonte Codefragmente können zu größeren Klonen zusammengefasst werden. Codefragmente müssen nicht direkt zusammenhängend sein. Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2005/ / 49 Verfahren nach Baker (1995) Verfahren basiert auf Lexemen. Vermeidung des quadratischen Aufwands: quasi-parallele Suche in einer Programmrepräsentation, die jedes mögliche Anfangsstück des Programms enthält. Abstraktion von Bezeichnern: Bezeichner werden auf relative Positionen abgebildet. Typ-3-Klone: Separater Schritt am Ende Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2005/ / 49

9 Parameter-String Für jede Codezeile wird eine Zeichenkette aus Parametersymbolen und Nichtparametersymbolen generiert (so genannter Parameter-String oder P-String): Struktur der Zeile wird auf eindeutiges Nichtparametersymbol abgebildet (Funktor) Bezeichner werden in Argumentliste erfasst Ergebnis ist: (Funktor Argumentliste) Beispiel: x = x + y (P = P + P; x,x,y) α x x y Die Konkatenation der P-Strings aller Codezeilen repräsentiert das Programm. j = l e n g t h ( l ) ; i f ( j < 3) {x = x + y ; } α j length l β j 3 x x y Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2005/ / 49 Prev-String Kodierung prev(s) jedes P-Strings s: Erstes Vorkommen eines Bezeichners erhält Nummer 0. Jedes weitere Vorkommen erhält den relativen Abstand zum vorherigen Vorkommen (Funktoren mitgezählt). Beispiel: α j length l β j 3 x x y α β Abstraktion der Bezeichner, jedoch nicht ihrer Reihenfolge. S ist ein P-Match von T genau dann, wenn prev(s) = prev(t ) Beispiel: x = x + y und a = a + b sind ein P-Match wegen γ010 = γ010 Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2005/ / 49

10 P-Suffix-Baum Sei S i = s i s i+1... s n $ das i te Suffix von S ($ ist das Endezeichen). Der P-Suffix-Baum von S enthält alle prev(s i ) zu den Suffixen des P-Strings S. Beispiel: S = αyβyαxαx prev(s 1 ) = α0β2α0α2$ prev(s 2 ) = 0β2α0α2$ prev(s 3 ) = β0α0α2$ prev(s 4 ) = 0α0α2$ prev(s 5 ) = α0α2$ prev(s 6 ) = 0α2$ prev(s 7 ) = α0$ prev(s 8 ) = 0$ prev(s 9 ) = $ Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2005/ / 49 P-Suffix-Baum Klone lassen sich im Baum durch Verzweigungen identifizieren. (Benutzer legt die Mindestzeilenlänge der Klone fest; entspricht der Anzahl von Funktoren). Gefundene P-Matches werden, wenn möglich, zusammengefasst: Modi: nur wenn d 1 = d 2 wenn max(d 1, d 2 ) Θ Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2005/ / 49

11 Bewertung des Ansatzes von Baker Bakers Klonerkennung ist lexem-basiert und damit sehr schnell: lineare Zeit- und Speicherkomplexität Plattform: SGI IRIX 4.1, 40 Mhz R3000, 256 MB Hauptspeicher System: 1,1 Mio LOC, mindestens zusammenhängende 30 LOC/Klon nur 7 Minuten Analysezeit Der Ansatz ist invariant gegen Einfügung von Leerzeichen, Leerzeilen und Kommentaren. Der Ansatz ist weitgehend programmiersprachen-unabhängig (nur Regeln für Bezeichner/Tokens notwendig). Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2005/ / 49 Bewertung des Ansatzes von Baker Allerdings entgehen dem Ansatz: äquivalente Ausdrücke mit kommutativen Operatoren: x = x + y x = y + x gleiche Anweisungsfolgen, die verschieden umgebrochen wurden: if (a > 1) {x = 1;} if (a > 1) {x = 1;} gleiche Teilausdrücke: if (sp > 0) if (sp > 0 && s[sp]!= a) Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2005/ / 49

12 AST-Matching Ansatz basierend auf abstrakten Syntaxbäumen (ASTs): vergleiche jeden Teilbaum mit jedem anderen Teilbaum auf Gleichheit Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2005/ / 49 Verfahren nach Baxter u. a. (1998) Verfahren basiert auf ASTs Vermeidung des quadratischen Aufwands: Partitionierung der zu vergleichenden Bäumen. Abstraktion von Bezeichnern: Partitionierung und AST-Vergleich ignoriert Bezeichner. Typ-3-Klone: Vergleich auf Ähnlichkeit statt Gleichheit. Separater Schritt am Ende. Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2005/ / 49

13 Skalierungsproblem und Erkennung der Klontypen Bäume werden durch Hash-Funktion partitioniert. Nur Bäume innerhalb einer gemeinsamen Partition werden verglichen. Hash-Funktion gleich wie bei Erkennung von gemeinsamen Teilausdrücken durch optimierende Compiler: h : nodetype arg 1 arg 2... arg n integer Typ-1-Klonerkennung: h liefert genaue Partitionierung Typ-2/3-Klonerkennung: h ignoriert Bezeichner Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2005/ / 49 Skalierungsproblem und Erkennung der Klontypen Bäume werden auf Ähnlichkeit verglichen (nicht auf Gleichheit): Similarity(T 1, T 2 ) = 2 Same(T 1, T 2 ) 2 Same(T 1, T 2 ) + Difference(T 1, T 2 ) Similarity muss über benutzerdefiniertem Schwellwert Θ S liegen: Similarity(T 1, T 2 ) Θ S Nur Bäume T mit mass(t ) Θ m werden betrachtet (mass = Anzahl von Knoten, Θ m = benutzerdefinierter Schwellwert). Bei kommutativen Operatoren werden wechselseitig beide Teilbäume verglichen. Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2005/ / 49

14 Probleme (und Lösungen) des AST-Matchings Skalierung Vermeidung unnötiger Vergleiche Nicht nur Typ-1-Klone sollen erkannt werden. Abstraktion von Bezeichnern. Die Teilausdrücke müssen nicht gleich sein, sondern nur ähnlich genug. Klone sind Teil anderer Klone (geschachtelte Konstrukte). Klone, die Teil eines anderen Klons sind, werden ignoriert, d.h. zusammengesetzte Klone subsumieren ihre Teile. Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2005/ / 49 Basis-AST-Matching (Schritt 1) C l o n e s := ; f o r each s u b t r e e t l o o p i f mass ( t ) Θ m then hash t to bucket ; end i f ; end l o o p ; f o r each s u b t r e e s and t i n the same bucket l o o p i f S i m i l a r i t y ( s, t ) Θ S then f o r each s u b t r e e s o f s and f o r each s u b t r e e t o f t and Is Member ( s, t, C l o n e s ) l o o p Remove Clone Pair ( s, t, C l o n e s ) ; end l o o p ; A d d C l o n e P a i r ( s, t, C l o n e s ) ; end i f ; end l o o p ; Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2005/ / 49

15 AST-Matching von Sequenzen (Schritt 2) Sequenzen von Bäumen (z.b. Anweisungsfolgen): v o i d f ( v o i d ) { x = 0 ; a = a + 1 ; b = b + 2 ; c = c + 3 ; w = g ( ) ; } v o i d g ( v o i d ) { y = 2 x ; a = a + 1 ; b = b + 2 ; c = c + 3 ; i = h ( ) 3 ; } Basis-Matching-Algorithmus identifiziert nur die gleichen Zuweisungen, ignoriert aber Gleichheit der beiden Anweisungsteilfolgen als Ganzes. Nächster Schritt identifiziert maximal lange gemeinsame Teilfolgen zweier Sequenzen, mit einer benutzerdefinierten Mindestlänge. Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2005/ / 49 Erkennung von Klonsequenzen (Schritt 2) f o r k i n Min Length.. Max Length l o o p p l a c e a l l s u b s e q u e n c e s o f l e n g t h k i n t o b u c k e t s ; f o r each s u b s e q u e n c e i and j i n same bucket l o o p i f Compare Sequence ( i, j, k ) Θ S then Remove Sequence Subclones Of ( i, j, k, C l o n e s ) ; A d d S e q u e n c e C l o n e P a i r ( i, j, k, C l o n e s ) ; end i f ; end l o o p ; end l o o p ; Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2005/ / 49

16 Erkennung zusammengesetzter Klone (Schritt 3) Gemeinsame Anweisungsfolgen wurden möglicherweise erst im zweiten Schritt nach dem Basis-AST-Matching erkannt. Durch neu erkannte Klone könnten Konstrukte, die diese Klone umfassen, nunmehr doch ähnlich sein. s = 0 ; x = y ; w h i l e ( x > 0) { s = s + x ; x = x 1 ;... } p = 0 ; a = b ; w h i l e ( a > 0) { p = p x ; a = a 1 ;... } D.h. Vaterknoten der als Klone erkannten Teilbäume müssen noch einmal evaluiert werden. Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2005/ / 49 Erkennung zusammengesetzter Klone (Schritt 3) C l o n e s T o G e n e r a l i z e := C l o n e s ; w h i l e C l o n e s T o G e n e r a l i z e l o o p Remove Clone Pair ( s, t, C l o n e s T o G e n e r a l i z e ) ; i f Compare Clones ( Parent ( s ), Parent ( t ) ) Θ S then Remove Clone Pair ( s, t, C l o n e s ) ; A d d C l o n e P a i r ( Parent ( s ), Parent ( t ), C l o n e s ) ; A d d C l o n e P a i r ( Parent ( s ), Parent ( t ), C l o n e s T o G e n e r a l i z e ) ; end i f ; end l o o p ; Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2005/ / 49

17 Bewertung des Ansatzes von Baxter AST-Matching ist syntax-orientiert und deshalb aufwändiger als lexem-basierter Ansatz, da Parsing notwendig ist beim lexem-basierten Ansatz müssen nur Schlüsselworte und Trennzeichen erkannt werden was aber bei manchen Programmiersprachen eben doch Parsing voraussetzt, z.b. PL/1: IF IF = ELSE THEN ELSE := THEN ELSE IF := ELSE dafür aber genauer: kommutative Operatoren werden berücksichtigt syntaktische Einheiten werden verglichen, statt einzelner Code-Zeilen übereinstimmende Teilausdrücke werden erkannt Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2005/ / 49 Verfahren nach Mayrand u. a. (1996) Verfahren basiert auf Metriken des Codes. Vermeidung des quadratischen Aufwands: im Prinzip immer noch quadratisch, Vergleich ist aber relativ billig. Abstraktion von Bezeichnern: Bezeichner werden von Metriken ignoriert. Typ-3-Klone: durch Toleranz der Metriken bzw. ihrer Zusammenfassung. Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2005/ / 49

18 Vergleich auf Basis von Kennzahlen Hoffnung: Code 1 = Code 2 Kennzahlen(Code 1 ) = Kennzahlen(Code 2 ) Granularität üblicherweise Funktionsebene, da hierfür viele Metriken existieren Aspekte nach Mayrand u. a. (1996): Namen Layout Anweisungen Kontrollfluss Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2005/ / 49 Vergleichsmetriken (Mayrand u. a. 1996) Name relative Anzahl gemeinsamer Zeichen Layout Anzahl Zeichen von Kommentaren (Deklarationsteil, Implementierungsteil) Anzahl mehrzeiliger Kommentare Anzahl nicht-leerer Zeilen (inklusive Kommentare) durchschnittliche Länge der Bezeichner Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2005/ / 49

19 Vergleichsmetriken (Mayrand u. a. 1996) Anweisungen gesamte Anzahl von Funktionsaufrufen Anzahl verschiedener Aufrufe durchschnittliche Komplexität der Entscheidungen in der Funktion Anzahl der Deklarationen Anzahl ausführbarer Anweisungen Kontrollfluss Anzahl der Kanten im Kontrollflussgraphen (KFG) Anzahl der Knoten im KFG Anzahl der Bedingungen im KFG Anzahl der Pfade im KFG Komplexitätsmetrik über dem KFG Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2005/ / 49 Zusammenfassung der Metriken Zwei Funktionen f 1 und f 2 sind in Bezug auf einen Aspekt: gleich gleiche Metrikwerte ähnlich alle Metrikwerte liegen in einer gewissen Bandbreite (spezifisch für jede individuelle Kennzahl definiert), sind aber nicht gleich verschieden mindestens ein Metrikwert liegt außerhalb einer Bandbreite Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2005/ / 49

20 Klassifikation Exakte Kopie Funktionen sind in jedem Aspekt gleich (Typ-1-Klon) Ähnliches Layout Ähnliches Layout und ähnliche Namen, gleiche Anweisungen und Kontrollfluss ( Typ-2-Klon) Ähnliche Ausdrücke Name und Layout sind verschieden, Anweisungen und Kontrollfluss sind gleich ( Typ-2-Klon) Verschieden Alle Aspekte sind verschieden. Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2005/ / 49 Bewertung des Ansatzes von Mayrand u. a. (1996) Aspekte sind nicht unabhängig. Definition der Bandbreite ist notwendig. Klassifikation ist unvollständig. Präzision: Code 1 = Code 2 Kennzahlen(Code 1 ) = Kennzahlen(Code 2 ) Code 1 Code 2 Kennzahlen(Code 1 ) Kennzahlen(Code 2 ) Kennzahlen(Code 1 ) = Kennzahlen(Code 2 ) Code 1 = Code 2? Kennzahlen(Code 1 ) Kennzahlen(Code 2 ) Code 1 Code 2??? Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2005/ / 49

21 Vergleich von Klonerkennungstechniken (Bellon 2003) Teilnehmer Referenz Ansatz Brenda S. Baker (Baker 1995) Suffix-Tree, tokenbasiert Ira D. Baxter (Baxter u. a. 1998) Subtree-Matching im AST Toshihiro Kamiya (Kamiya u. a. 2002) Eingabetransformation, Suffix-Tree, tokenbasiert Jens Krinke (Krinke 2001) Program Dependence Graph Ettore Merlo (Mayrand u. a. 1996) Funktions-Metriken + Token-Vergleich Matthias Rieger (Ducasse u. a. 1999) Pattern Matching auf Dotplots (textuell) Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2005/ / 49 Untersuchte Software-Systeme Projekt Sprache Größe Kandidaten Referenzen (SLOC) weltab C 11K cook C 80K snns C 115K postgresql C 235K netbeans-javadoc Java 19K eclipse-ant Java 35K eclipse-jdtcore Java 148K j2sdk1.4.0-javax-swing Java 204K Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2005/ / 49

22 Beispiel SNNS: Kandidaten Typ 3 Typ 2 Typ 1 unbestimmt Orakel Baker Baxter Kamiya Kamiya (vol.) Krinke Merlo Merlo (vol.) Rieger Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2005/ / 49 Beispiel SNNS: Gefundene Referenzen Typ 3 Typ Typ OK Good OK Good OK Good OK Good OK Good OK Good OK Good OK Good OK Good Orakel Baker Baxter Kamiya Kamiya (vol.) Krinke Merlo Merlo (vol.) Rieger Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2005/ / 49

23 Beispiel SNNS: Recall und Precision Baker Baxter Kamiya Kamiya (vol.) Krinke Merlo Merlo (vol.) Rieger Typ 3 Typ 2 Typ 1 insgesamt Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2005/ / 49 Zusammenfassung Baker Baxter Kamiya Krinke Merlo Rieger Ansatz Token AST Token PDG Metrik Token Erkennt Typ 1, 2 1, 2 1, 2, 3 3 1, 2, 3 1, 2, 3 Klassifiziert 1, 2 1, 2 3 1, 2, 3 Geschwind ? Speicher ? Recall Precision Versteckte 42 % 28 % 46 % 4 % 24 % 31 % Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2005/ / 49

24 Wiederholungs- und Vertiefungsfragen I Was versteht man unter Klonen? Welche Typen gibt es? Mit Beispiel. Wie entstehen Klone? Warum sind Klone problematisch? Welche Klassen von Ansätzen zur Erkennung von Klonen gibt es und wie sind diese charakterisiert? Welche Probleme müssen bei der Erkennung bewältigt werden? Wie funktioniert der Ansatz von Baker? Wie ist der Ansatz von Baker zu bewerten? Wie funktioniert der Ansatz von Baxter? Wie ist der Ansatz von Baxter zu bewerten? Wie funktioniert der Ansatz von Mayrand? Wie ist der Ansatz von Mayrand zu bewerten? Welche Grundannahme liegt zu Grunde? Diskutiere die Annahme. Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2005/ / 49 1 Baker 1995 Baker, Brenda S.: On Finding Duplication and Near-Duplication in Large Software Systems. In: Wills, L. (Hrsg.) ; Newcomb, P. (Hrsg.) ; Chikofsky, E. (Hrsg.): Working Conference on Reverse Engineering. Los Alamitos, California : IEEE Computer Society Press, Juli 1995, S URL 2 Baxter u. a Baxter, Ira D. ; Yahin, Andrew ; Moura, Leonardo ; Sant Anna, Marcelo ; Bier, Lorraine: Clone Detection Using Abstract Syntax Trees. In: Koshgoftaar, T. M. (Hrsg.) ; Bennett, K. (Hrsg.): International Conference on Software Maintenance, IEEE Computer Society Press, 1998, S ISBN , , Bellon 2003 Bellon, Stefan: Vergleich von Klonerkennungstechniken. Fakultät Informatik, Universität Stuttgart, Deutschland, Diplomarbeit, 2003 Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2005/ / 49

25 4 Ducasse u. a Ducasse, Stéphane ; Rieger, Matthias ; Demeyer, Serge: A Language Independent Approach for Detecting Duplicated Code. In: Proceedings of the International Conference on Software Maintenance (ICSM99), Kamiya u. a Kamiya, Toshihiro ; Kusumoto, Shinji ; Inoue, Katsuro: CCFinder: A Multi-Linguistic Token-based Code Clone Detection System for Large Scale Source Code. In: IEEE Computer Society Transactions on Software Engineering 28 (2002), Nr. 7, S Krinke 2001 Krinke, Jens: Identifying Similar Code with Program Dependence Graphs. In: Working Conference on Reverse Engineering, Mayrand u. a Mayrand, Jean ; Leblanc, Claude ; Merlo, Ettore M.: Experiment on the Automatic Detection of Function Clones in a Software System using Metrics. In: Proceedings of the International Conference on Software Maintenance. Washington : IEEE Computer Society Press, November , S ISBN Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2005/ / 49