Vorlesung Software-Reengineering - Informatik - Universität Bremen

Vorlesung Software-Reengineering 

Prof. Dr. Rainer Koschke 

Arbeitsgruppe Softwaretechnik 

Fachbereich Mathematik und Informatik 

Universität Bremen 

Wintersemester 2009/10

Überblick I 

1 Klonerkennung

Techniken zur Klonerkennung 

Techniken zur Klonerkennung I 

1 Klonerkennung 

Hintergrund 

Folgen 

Übersicht zu den Ansätzen zur Klonerkennung 

Textuelle Verfahren 

Lexikalische Verfahren 

Metrikbasierte Verfahren 

Syntaxbasierte Verfahren 

PDG-basierte Verfahren 

Lexikalische Verfahren 

Syntaxbasierte Verfahren 

Metrikbasierte Verfahren 

Vergleich von Techniken zur Klonerkennung 

Wiederholungsfragen 

Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2009/2010 3 / 63


No two parts are alike in software. . . 

Software entities are more complex for their size than perhaps 

any other human construct because no two parts are alike (at 

least above the statement level). If they are, we make the two 

similar parts into a subroutine — open or closed. In this 

respect, software systems differ profoundly from computers, 

buildings, or automobiles, where repeated elements abound. 

– by Frederick P. Brooks, Jr: No Silver Bullet: Essence and Accidents of 

Software Engineering 



Klonerkennung 

Lernziele 

Varianten der Klonerkennung (Erkennung duplizierten Codes) 

Bezug zu Abstraktionsebenen von Programmdarstellungen 

Kontext 

Beseitigung von Redundanz auf Codierungsebene 

erleichtert nachfolgende Reengineering-Aktivitäten 



Softwareredundanz 

Duplikation von Quelltext durch Copy&Paste (Code Cloning) ist häufig: 

Nummer 1 auf Beck und Fowlers ” Stink Parade of Bad Smells“ 

Forschung: 

% System Zeilen Referenz 

19 X Windows ≥ 30 Baker (1995) 

28 3 subs. of process-control sys. ? Baxter u. a. (1998) 

59 payroll system ≥ 10 Ducasse u. a. (1999) 

Klone länger als 25 Zeilen sind selten (Baxter u. a. 1998) 



Klontypen: Typ 1 

PRIVATE UINT16 t y p l e n g t h ( a t n t y p e ∗node ) 

{ i f ( node−>tag == REF ) 

node = node−>t r e e . r e f t y p e ; 

s w i t c h ( node−>tag ) 

{ 

c a s e INTEGER : r e t u r n 4 ; 

c a s e REAL : r e t u r n 8 ; 

c a s e BOOLEAN : r e t u r n 1 ; 

c a s e STRING : r e t u r n 4 ; 

c a s e ARRAY : 

r e t u r n t y p l e n g t h ( node−>t r e e . a r r a y . t y p e ) 

∗ ( node−>t r e e . a r r a y . upb 

− node−>t r e e . a r r a y . lwb +1); 

c a s e REF : r e t u r n 4 ; 

d e f a u l t : 

l o g e r r o r (ERR FATAL , SYSTEM ERROR, 

E ILLEGAL TAG , ” t y p e ” , 0 ) ; 

} 

r e t u r n 0 ; 

} 

1 PRIVATE UINT16 t y p l e n g t h ( a t n t y p e ∗node ) 

2 { i f ( node−>tag == REF ) 

3 node = node−>t r e e . r e f t y p e ; 

4 

5 s w i t c h ( node−>tag ) 

6 { 

7 c a s e INTEGER : r e t u r n 4 ; 

8 c a s e REAL : r e t u r n 8 ; 

9 c a s e BOOLEAN : r e t u r n 1 ; 

10 c a s e STRING : r e t u r n 4 ; 

11 c a s e ARRAY : 

12 r e t u r n t y p l e n g t h ( node−>t r e e . a r r a y . t y p e ) 

13 ∗ ( node−>t r e e . a r r a y . upb 

14 − node−>t r e e . a r r a y . lwb +1); 

15 c a s e REF : r e t u r n 4 ; 

16 d e f a u l t : 

17 l o g e r r o r (ERR FATAL , SYSTEM ERROR, 

18 E ILLEGAL TAG , ” t y p e ” , 0 ) ; 

19 } 

20 r e t u r n 0 ; 

21 } 




} 

r e t u r n TRUE ; 

/∗ r e a d operand #0 ( a l w a y s p r e s e n t ) ∗/ 

thisOp−>op [ 0 ] . t y p e 

= v a a r g ( ap , a 3 a r g u m e n t t y p e ) ; 

i f ( ( thisOp−>op [ 0 ] . t y p e == oCFLOAT ) | | 

( thisOp−>op [ 0 ] . t y p e & 1 6 ) ) // i n d e x e d 

{ 

thisOp−>op [ 0 ] . v a l . f [0]= v a a r g ( ap , INT32 ) ; 11 thisOp−>op [ 2 ] . v a l . f [0]= v a a r g ( ap , INT32 ) ; 

} 

e l s e 

thisOp−>op [ 0 ] . v a l . f [1]= v a a r g ( ap , INT32 ) ; 

thisOp−>op [ 0 ] . v a l . l = v a a r g ( ap , INT32 ) ; 

/∗ r e a d operand #1 ( sometimes p r e s e n t ) ∗/ 

i f ( ( s t a t t y p e != A3 GOTO ) && 

1 /∗ r e a d operand #2 ( b i n a r y op o n l y ) ∗/ 

2 i f ( ( s t a t t y p e == A3 BINARY OP ) | | 

3 ( s t a t t y p e == A3 COND ) ) 

4 { 

5 thisOp−>op [ 2 ] . t y p e 

6 = v a a r g ( ap , a 3 a r g u m e n t t y p e ) ; 

7 

8 i f ( ( thisOp−>op [ 2 ] . t y p e == oCFLOAT ) | | 

9 ( thisOp−>op [ 2 ] . t y p e & 1 6 ) ) 

10 { 

12 thisOp−>op [ 2 ] . v a l . f [1]= v a a r g ( ap , INT32 ) ; 

13 } 

14 e l s e 

15 thisOp−>op [ 2 ] . v a l . l = v a a r g ( ap , INT32 ) ; 

16 } 

17 e l s e 

18 thisOp−>op [ 2 ] . t y p e = oNONE ; 




r e t u r n FALSE ; 

} 

i f ( ! parse ( ) ) 

{ 

} 

p r i n t e r r o r ( s t d o u t , 0 ) ; 


fclose( fp ) ; 

i f ( d e b u g f l a g ) 

{ 

p r i n t f ( ” result of parser ” ) ; 

i f ( ! p r i n t t r e e ( FALSE ) ) 

{ 

p r i n t e r r o r ( s t d o u t , 0 ) ; 


} 

} 

i f ( v e r b o s e f l a g | | d e b u g f l a g ) 

p r i n t f ( ” s e m a n t i c a n a l y s i s \n” ) ; 

1 i f ( v e r b o s e f l a g | | d e b u g f l a g ) 

2 p r i n t f ( ” t y p e c h e c k i n g \n” ) ; 

3 

4 i f ( ! type check ( ) ) 

5 { 

6 p r i n t e r r o r ( s t d o u t , 0 ) ; 

7 r e t u r n FALSE ; 

8 } 

9 

10 i f ( d e b u g f l a g ) 

11 { 

12 p r i n t f ( ” result of type check ” ) ; 

13 i f ( ! p r i n t t r e e ( TRUE ) ) 

14 { 

15 p r i n t e r r o r ( s t d o u t , 0 ) ; 

16 r e t u r n FALSE ; 

17 } 

18 } 

19 

20 i f ( g e n c o d e f l a g ) 

21 { 

22 i f ( ( f p = f o p e n ( o u t f i l e n a m e , ”wt”))==NULL) 

23 { 


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.


Warum gibt es Klone? 

Entwicklungsstrategie 

Klone als Vorlage: Templating 

Verzögerte Anpassung 

. . . 

Wartung 

Bewährter Quelltext 

Unabhängigkeit 

. . . 

Einschränkungen 

Architektur 

Zeit 

Mangelnde Kenntnisse 

Programmiersprache 

. . . 



Was sind die Auswirkungen von Klonen? 

Erhöhter Ressourcenbedarf 

Erhöhter Aufwand zum Verstehen 

Erhöhter Aufwand zum Ändern 

Duplizieren von Fehlern 

Unvollständige Anpassung 

Gefahr von inkonsistenten Änderungen 

Erhöhter Testaufwand 

. . . 



Studien zu Auswirkungen von Klonen 

Wissenschaftliche Studien lassen negative Auswirkungen von Klonen 

erkennen: 

höchste Fehlerdichte in Modulen mit besonders langen Klonen 

(Monden u. a. 2002): 

Fehler treten vermehrt auf, wenn Klone vorkommen (Chou u. a. 2001) 

Fehler wegen Klonen, deren Bezeichner inkonsistent umbenannt 

wurden (Li u. a. 2006) 

Fehler durch inkonsistent geänderte Klone (Jürgens u. a. 2009) 



Nächster Abschnitt 

Wie können Klone gefunden werden? 




Granularität 

Klassen, Dateien 

Funktionen 

Anweisungen 

Vergleich von . . . 

Text 

Bezeichnern 

Token 

Syntaxbäume 

Kontroll- und Datenabhängigkeiten 

Verwendete Techniken: 

textual diff 

dotplot 

data mining 

suffix tree 

tree matching 

graph matching 

latent semantic 

indexing 

metric vector 

comparison 

hashing 



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 von Typ 1 und Typ 2 können 

zu größeren Klonen zusammengefasst werden. 

Codefragmente müssen nicht direkt zusammenhängend sein. 

Code muss nicht identisch, nur ähnlich sein: Ähnlichkeitsmaß? 



Textuelle Verfahren 

Vergleich von. . . 

Bezeichner und Kommentare (Information-Retrieval-Techniken) 

Latent Semantic Indexing (Marcus und Maletic 2001) 

text 

Zeichenkettenvergleich (Johnson 1993, 1994) mittels Hashwerten 

zeilenweiser Vergleich über Dot-Plots (Ducasse u. a. 1999; Rieger 

2005) 

42 

27 

124 67 12 

42 

95 ... 

a a b x y a a b z ... 

Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2009/2010 22 / 63 

...

Dot-Plot: 

file1.c 

file2.c 

file1.c 

file2.c 

1 2 3 4 5 6 7 8 9 10 11 12 1 2 3 4 5 6 7 8 

1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

11 

12 

1 

2 

3 

4 

5 

6 

7 

8




Tokens 

Type-1/-2-Klone: Suffixbaum für parameterisierte Zeichenketten pro 

Zeile (Baker 1995) 

x y a a b $ 

a b 

$ 

a 

x y a a b $ 

b 

a a b x y a a b $ 

$ 

b 

x y a a b $ 

$ 

x y a a b $ 

y a a b $ 

$ 

Type-3: Zusammenfassung von Typ-1/2-Klonen mit Lücken (Baker 

Rainer Koschke 1995). (Univ. Bremen) Vorlesung Software-Reengineering WS 2009/2010 23 / 63




Metriken (Mayrand u. a. 1996; Kontogiannis 1997) 

Anweisungen durch Data-Mining-Techniken (Wahler u. a. 2004; Li 

u. a. 2004) 





Syntaxbäumen 

Hashing mit Baum-Matching (Baxter u. a. 1998) 

Baum-Matching mit dynamischem Programmieren (für Dateivergleich) 

(Yang 1991) 

Suffixbaum für serialisierten Syntaxbaum (Koschke u. a. 2006) 

+ 

id id 

if 

= 

id id 

= 

id call 

id 

seq 

if 

id = 

id id 

= 

id literal 

if 

id = 

id id 

= 

id id 




Vergleich von Program-Dependency-Graphs (PDG) (Komondoor und 

Horwitz 2001; Krinke 2001) 

r e a d ( n ) ; r e a d (m) ; 

i = 1 ; s = 0 ; 

p r o d u c t = 1 ; p = 1 ; 

sum = 0 ; f o r ( j = 1 ; j


Verfahren nach Baker (1995) 

Verfahren vergleicht Token-Sequenzen 

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 



Parameter-String 

Für jede Codezeile wird eine Zeichenkette aus Parametersymbolen 

und Nichtparametersymbolen generiert (so genannter 

Parameter-String oder P-String): 

Struktur der Zeile (genauer: Token-Sequenz) 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 



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 

→ α 0 0 0 β 4 0 0 1 0 

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 



P-Suffix-Baum 

Sei Si = sisi+1 . . . sn$ das i’te Suffix von S ($ ist das Endezeichen). 

Der P-Suffix-Baum von S enthält alle prev(Si) zu den Suffixen des 

P-Strings S. 

Beispiel: S = αyβyαxαx 

prev(S1) = α0β2α0α2$ 

prev(S2) = 0β2α0α2$ 

prev(S3) = β0α0α2$ 

$ 

prev(S4) = 0α0α2$ 

prev(S5) = α0α2$ 

prev(S6) = 0α2$ 

prev(S7) = α0$ 

prev(S8) = 0$ 

prev(S9) = $ 

$ 

α2$ 

α0 

β0α0α2$ 

β2α0α2$ 



P-Suffix-Baum 

Klone: Verzweigungen im Suffix-Baum 

Länge: Anzahl der Funktoren 

→ Benutzer kann Mindestlänge festlegen 

Ort: Anzahl Funktoren zum Blatt gibt die Position relativ zum 

Programmende wieder 



Typ-3-Erkennung 

Gefundene P-Matches werden, wenn möglich, zusammengefasst: 

d 

1 

A 

B 

Modi: 

nur wenn d1 = d2 

wenn max(d1, d2) ≤ Θ 

Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2009/2010 32 / 63 

A 

B 

d 2


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). 

Erweiterung von Kamiya u. a. (2002): Normalisierung des 

Tokenstroms (z.B. Entfernen von Qualifier wie static) 



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 umbrochen wurden: 

gleiche Teilausdrücke: 

if (a > 1) {x = 1;} if (a > 1) 

{x = 1;} 

if (sp > 0) if (sp > 0 && s[sp] != a) 



AST-Matching 

Ansatz basierend auf abstrakten Syntaxbäumen (ASTs): 

vergleiche jeden Teilbaum mit jedem anderen Teilbaum auf Gleichheit 

if if 

cond else cond else 

then then 

= call := 

= 

left right 

lhs rhs 

left right 

call 

:= 

lhs rhs 

a b x y z q t s 



Verfahren nach Baxter u. a. (1998) 

Verfahren basiert auf ASTs 


Partitionierung der zu vergleichenden Bäumen. 


Partitionierung und AST-Vergleich ignoriert Bezeichner. 

Typ-3-Klone: 

Vergleich auf Ähnlichkeit statt Gleichheit. 

Separater Schritt am Ende. 



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 × arg1 × arg2 × . . . × argn → integer 

Typ-1-Klonerkennung: h liefert genaue Partitionierung 

Typ-2/3-Klonerkennung: h ignoriert Bezeichner 



Skalierungsproblem und Erkennung der Klontypen 

Bäume werden auf Ähnlichkeit verglichen (nicht auf Gleichheit): 

Similarity(T1, T2) = 

2 · Same(T1, T2) 

2 · Same(T1, T2) + Difference(T1, T2) 

Similarity muss über benutzerdefiniertem Schwellwert ΘS liegen: 

Similarity(T1, T2) ≥ Θ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. 



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. 



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 ; 



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. 



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 ; 



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. 



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 ; 



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 



Verfahren nach Mayrand u. a. (1996) 

Verfahren basiert auf Metriken des Codes. 


im Prinzip immer noch quadratisch, Vergleich ist aber relativ billig. 


Bezeichner werden von Metriken ignoriert. 

Typ-3-Klone: 

durch Toleranz der Metriken bzw. ihrer Zusammenfassung. 



Vergleich auf Basis von Kennzahlen 

Hoffnung: 

Code1 = Code2 ⇔ Kennzahlen(Code1) = Kennzahlen(Code2) 

Granularität üblicherweise Funktionsebene, da hierfür viele Metriken 

existieren 

Aspekte nach Mayrand u. a. (1996): 

Namen 

Layout 

Anweisungen 

Kontrollfluss 



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 



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 



Zusammenfassung der Metriken 

Zwei Funktionen f1 und f2 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 



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. 



Bewertung des Ansatzes von Mayrand u. a. (1996) 

Aspekte sind nicht unabhängig. 

Definition der Bandbreite ist notwendig. 

(Klassifikation ist unvollständig.) 

Präzision: 

Code1 = Code2 ⇒ Kennzahlen(Code1) = Kennzahlen(Code2) √ 

Code1 ≈ Code2 ⇒ Kennzahlen(Code1) ≈ Kennzahlen(Code2) √ 

Kennzahlen(Code1) = Kennzahlen(Code2) ⇒ Code1 = Code2 ? 

Kennzahlen(Code1) ≈ Kennzahlen(Code2) ⇒ Code1 ≈ Code2 ??? 



Vergleich von Klonerkennungstechniken (Bellon 2003; 

Bellon u. a. 2007) 

Teilnehmer Ansatz 

Matthias Rieger Pattern Matching auf Dotplots (textuell) 

Brenda S. Baker Suffix-Tree, tokenbasiert (zeilenweise) 

Toshihiro Kamiya Suffix-Tree, tokenbasiert (Einzeltoken) 

+ Eingabetransformation 

Ira D. Baxter Subtree-Matching im AST 

Ettore Merlo Funktions-Metriken + Token-Vergleich 

Jens Krinke Program Dependency Graph 



Zusammenfassung 

Rieger Baker Kamiya Baxter Krinke Merlo 

Ansatz Text Token Token AST PDG Metrik 

Erkennt Typ 1–3 1, 2 1–3 1, 2 3 1–3 

Klassifiziert – 1, 2 – 1, 2 3 1–3 

Geschwind. ? + + + - - - + + 

Speicher ? + + - + + + 

Recall + + + - - - 

Precision - - - + - + 

Versteckte 31 % 42 % 46 % 28 % 4 % 24 % 



Weiterführende Literatur 

McCreight (1976): Konstruktion von Suffix-Bäumen für 

Zeichenketten in linearer Zeit und mit linearem Speicheraufwand 

(relativ zur Länge der Zeichenkette) 

Ukkonen (1995): wie McCreight, jedoch wird Eingabe von links nach 

rechts verarbeitet (on-line). 

Baker (1997) wie McCreight, jedoch für parametrisierte Zeichenketten 

Kodierung kann sich bei Entfernung des ersten Elements ändern 

→ Distinct Right Context Property ist verletzt 

www.csse.monash.edu.au/~lloyd/tildeAlgDS/Tree/Suffix/ 

und 

http://www.dogma.net/markn/articles/suffixt/suffixt.htm: 

Erklärungen, Beispiele, Referenzen und Algorithmen 

Koschke u. a. (2006) verwenden Suffixbäume für AST-basierte 

Erkennung 


• McCreight (1976) stellt einen Algorithmus zur Konstruktion von Suffix-Bäumen für Zeichenketten vor (als Verbesserun 

von Weimers Algorithmus), der lineare Zeit und linearen Speicheraufwand (relativ zur Länge der Zeichenkette) benötig 

• Ukkonen (1995) beschreibt einen Algorithmus zur Konstruktion von Suffix-Bäumen für Zeichenketten, der die gleiche 

Zeit- und Speicherkomplexität wie der von McCreight aufweist, dafür aber algorithmisch einfacher ist und die Eingabe 

von links nach rechts verarbeitet (deshalb als on-line bezeichnet wird). 

• Baker (1997) erweitert den Algorithmus von McCreight für parametrisierte Zeichenketten (deren Kodierung sich bei 

Entfernung des ersten Elements nämlich ändern kann, was eine Verletzung der Distinct Right Context Property darstel 

die für das korrekte Funktionieren von McCreights Algorithmus Voraussetzung ist). 

• http://www.csse.monash.edu.au/~lloyd/tildeAlgDS/Tree/Suffix/ und 

http://www.dogma.net/markn/articles/suffixt/suffixt.htm geben Erklärungen, Beispiele, Referenzen und 

Algorithmen an.


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 dem Ansatz von Mayrand zu Grunde? 

Diskutiere die Annahme. 



Baker 1997 Baker, Brenda: Parameterized duplication in strings: 

Algorithms and an application to software maintenance. 26 (1997), 

Oktober, Nr. 5, S. 1343–1362 

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. 86–95. – URL 

http://citeseer.nj.nec.com/baker95finding.html 

Baxter u. a. 1998 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. 368–378. – ISBN 

0-7803-5255-6, 0-8186-8779-7, 0-8186-8795-9 



Bellon 2003 Bellon, Stefan: Vergleich von Klonerkennungstechniken. 

Fakultät Informatik, Universität Stuttgart, Deutschland, Diplomarbeit, 

2003 

Bellon u. a. 2007 Bellon, Stefan ; Koschke, Rainer ; Antoniol, 

Giulio ; Krinke, Jens ; Merlo, Ettore: Comparison and Evaluation of 

Clone Detection Tools. In: IEEE Computer Society Transactions on 

Software Engineering 33 (2007), September, Nr. 9, S. 577–591 

Chou u. a. 2001 Chou, Andy ; Yang, Junfeng ; Chelf, Benjamin ; 

Hallem, Seth ; Engler, Dawson R.: An Empirical Study of 

Operating System Errors. In: Symposium on Operating Systems 

Principles, ACM Press, 2001, S. 73–88. – URL 

citeseer.ist.psu.edu/chou01empirical.html 

Cordy u. a. 2004 Cordy, James R. ; Dean, Thomas R. ; 

Synytskyy, Nikita: Practical language-independent detection of 

near-miss clones. In: Conference of the Centre for Advanced Studies on 

Collaborative research, IBM Press, 2004, S. 1–12 



Ducasse u. a. 1999 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), 1999, S. 109–118 

Higo u. a. 2002 Higo, Yoshiki ; Ueda, Yasushi ; Kamiya, Toshihro ; 

Kusumoto, Shinji ; Inoue, Katsuro: On Software Maintenance 

Process Improvement Based on Code Clone Analysis. In: International 

Conference on Product Focused Software Process Improvement 

Bd. 2559, Springer, 2002, S. 185–197. – ISBN ISBN:3-540-00234-0 

Johnson 1993 Johnson, J. H.: Identifying redundancy in source code 

using fingerprints. In: Conference of the Centre for Advanced Studies on 

Collaborative research, IBM Press, 1993, S. 171–183 

Johnson 1994 Johnson, J. H.: Substring matching for clone detection 

and change tracking. In: International Conference on Software 

Maintenance, IEEE Computer Society Press, 1994, S. 120–126 



Jürgens u. a. 2009 Jürgens, E. ; Deissenböck, F. ; Hummel, B. ; 

Wagner, S.: Do Code Clones Matter? In: International Conference on 

Software Engineering, ACM Press, 2009 

Kamiya u. a. 2002 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. 654–670 

Komondoor und Horwitz 2001 Komondoor, R. ; Horwitz, S.: 

Using slicing to identify duplication in source code. In: Proc. Int. 

Symposium on Static Analysis, Juli 2001, S. 40–56 

Kontogiannis 1997 Kontogiannis, K.: Evaluation Experiments on 

the Detection of Programming Patterns Using Software Metrics. In: 

Working Conference on Reverse Engineering, 1997, S. 44–53 



Koschke u. a. 2006 Koschke, Rainer ; Falke, Raimar ; Frenzel, 

Pierre: Clone Detection Using Abstract Syntax Suffix Trees. In: Working 

Conference on Reverse Engineering, IEEE Computer Society Press, 

2006, S. 253–262 

Krinke 2001 Krinke, Jens: Identifying Similar Code with Program 

Dependence Graphs. In: Working Conference on Reverse Engineering, 

2001, S. 301–309 

Li u. a. 2004 Li, Z. ; Lu, S. ; Myagmar, S. ; Zhou, Y.: CP-Miner: A 

tool for Finding copy-paste and related bugs in operating system code. 

In: Operating System Design and Implementation, 2004, S. 289–302 

Li u. a. 2006 Li, Z ; Lu, S ; Myagmar, S. ; Zhou, Y.: Copy-Paste 

and Related Bugs in Large-Scale Software Code. In: IEEE Computer 

Society Transactions on Software Engineering 32 (2006), März, Nr. 3, 

S. 176–192 

Marcus und Maletic 2001 Marcus, A. ; Maletic, J.I.: Identification 

of high-level concept clones in source code. In: International Conference 

on Automated Software Engineering, 2001, S. 107–114 



Mayrand u. a. 1996 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 4–8 1996, S. 244–254. – ISBN 0-8186-7678-7 

McCreight 1976 McCreight, E. M.: A space-economical suffix-tree 

construction algorithm. In: Journal of the ACM 23 (1976), Nr. 2, 

S. 262–272 

Monden u. a. 2002 Monden, A. ; Nakae, D. ; Kamiya, T. ; Sato, 

S. ; Matsumoto, K.: Software quality analysis by code clones in 

industrial legacy software. In: IEEE Symposium on Software Metrics, 

2002, S. 87–94 

Rieger 2005 Rieger, Matthias: Effective Clone Detection Without 

Language Barriers, University of Bern, Switzerland, Dissertation, 2005 

Synytskyy u. a. 2003 Synytskyy, Nikita ; Cordy, James R. ; 

Dean, Thomas: Resolution of static clones in dynamic Web pages. In: 

Proceedings of the Workshop on Website Evolution, 2003, S. 49–56 



Ukkonen 1995 Ukkonen, E.: On-line construction of suffix trees. In: 

Algorithmica 14 (1995), S. 249–260 

Wahler u. a. 2004 Wahler, V. ; Seipel, D. ; Gudenberg, 

Jürgen W. von ; Fischer, G.: Clone detection in source code by 

frequent itemset techniques. In: Proceedings of the Fourth IEEE 

International Workshop on Source Code Analysis and Manipulation, 

2004, S. 128–135 

Yang 1991 Yang, Wuu: Identifying Syntactic Differences Between 

Two Programs. In: Software–Practice and Experience 21 (1991), Juli, 

Nr. 7, S. 739–755

Vorlesung Software-Reengineering - Informatik - Universität Bremen

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?