Vorlesung Software-Reengineering - Informatik - Universität Bremen

Vorlesung Software-Reengineering 

Prof. Dr. R. Koschke 1 D. Simon 2 

1 Arbeitsgruppe Softwaretechnik 

Fachbereich Mathematik und Informatik 

Universität Bremen 

2 Institut für Software Technologie 

Fakultät Informatik, Elektrotechnik und Informationstechnologie 

Universität Stuttgart 

Oktober 2004

Überblick I 

1 Klonerkennung

echniken zur Klonerkennung 

Techniken zur Klonerkennung 

1 Klonerkennung 

Hintergrund 

Definitionen und Beispiele 

Ansätze zur Klonerkennung 

Verfahren nach Baker 

Verfahren nach Baxter 

Verfahren nach Mayrand et al. 

Vergleich von Techniken zur Klonerkennung 

Koschke/Simon (Univ. Bremen/Stuttgart) Vorlesung Software-Reengineering WS 2004/2005 3 / 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 



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. 


• Wegen unzureichender Versionskontrolle existieren mehrere Versionen 

derselben Funktion im selben Code oder in verschiedenen Systemen. 


• Programmiersprache unterstützt keine Vererbung und keine generischen 

Einheiten. Compiler bietet kein Inlining. 

• Folge: Code wird dupliziert 



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–25 % Code sind redundant. 



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. 



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 



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. 



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 

• Semantik 



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



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. 



Verfahren nach Baker 

• 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 



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 



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 I 

• 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 ) = $ 



P-Suffix-Baum II 

• 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 ) ≤ Θ 



Bewertung des Ansatzes von Baker I 

• Bakers Klonerkennung ist lexem-basiert und damit sehr schnell: 

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



Bewertung des Ansatzes von Baker II 

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) 



AST-Matching 

Ansatz basierend auf abstrakten Syntaxbäumen (ASTs): 

• vergleiche jeden Teilbaum mit jedem anderen Teilbaum auf Gleichheit 



Verfahren nach Baxter 

• Verfahren basiert auf ASTs 


• Partitionierung der zu vergleichenden Bäumen. 


• Partitionierung und AST-Vergleich ignoriert Bezeichner. 


• Vergleich auf Ähnlichkeit statt Gleichheit. 

• Separater Schritt am Ende. 



Skalierungsproblem und Erkennung der Klontypen I 

• 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 



Skalierungsproblem und Erkennung der Klontypen II 

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



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 et al. 

• Verfahren basiert auf Metriken des Codes. 


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


• Bezeichner werden von Metriken ignoriert. 


• durch Toleranz der Metriken bzw. ihrer Zusammenfassung. 



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 et al.): 

• Namen 

• Layout 

• Anweisungen 

• Kontrollfluss 



Vergleichsmetriken (Mayrand et al.) 

• 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 et al.) 

• 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 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 



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 et al. 

• 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 ??? 



Vergleich von Techniken zur Klonerkennung 

Teilnehmer 

Brenda S. Baker 

Ira D. Baxter 

Toshihiro Kamiya 

Jens Krinke 

Ettore Merlo 

Matthias Rieger 

Ansatz 

Suffix-Tree, tokenbasiert 

Subtree-Matching im AST 

Eingabetransformation, tokenbasiert 

Program Dependence Graph 

Funktions-Metriken 

Pattern Matching auf visualisiertem Code 



Untersuchte Software-Systeme 

Projekt Sprache Größe Kandidaten Referenzen 

(SLOC) 

weltab C 11K 13901 252 

cook C 80K 27122 402 

snns C 115K 66331 903 

postgresql C 235K 59114 555 

netbeans-javadoc Java 19K 7860 55 

eclipse-ant Java 35K 2440 30 

eclipse-jdtcore Java 148K 92905 1345 

j2sdk1.4.0-javax-swing Java 204K 56262 777 



Beispiel SNNS: Kandidaten 

20000 

15000 

18961 18923 

Typ 3 

Typ 2 

Typ 1 

unbestimmt 

12181 

10000 

8978 

5000 

5212 

0 

903 

1434 

Orakel Baker Baxter Kamiya Kamiya 

(vol.) 

318 324 

Krinke Merlo Merlo 

(vol.) 

Rieger 



Beispiel SNNS: Gefundene Referenzen 

1000 

800 

903 903 

812 812 

Typ 3 

Typ 2 

Typ 1 

600 

601 601 

497 

400 

369 

302 

200 

0 

223 

180 

135 

78 

100 

48 44 49 45 

OK Good OK Good OK OK OK OK OK OK OK 

Good Good Good Good Good Good Good 

Orakel Baker Baxter Kamiya Kamiya 

(vol.) 


(vol.) 

Rieger 



Beispiel SNNS: Recall und Precision 

0.9 

0.8 

0.7 

0.6 

0.5 

0.4 

0.3 

0.2 

0.1 

0 

0.33 

0.65 

0.39 

0.05 

0.09 

0.37 

0.07 

0 

0.84 0.84 0.84 0.84 

0.67 0.67 

0.19 0.19 

Baker Baxter Kamiya Kamiya 

(vol.) 

0.11 

0.03 

0.02 

0.36 

0.09 0.09 

0.05 0.05 0.05 0.05 

0.02 0.03 


(vol.) 

0.56 

0.2 

0.18 

0.07 

Rieger 

Typ 3 

Typ 2 

Typ 1 

insgesamt 

0.9 

0.8 

0.7 

0.6 

0.5 

0.4 

0.3 

0.2 

0.1 

0 

0.808 

0.067 

0.054 

0.034 0.027 0.026 

0.032 0.032 

Baker Baxter Kamiya Kamiya 

(vol.) 

0.008 

0.007 

0.192 0.192 

0.1380.135 0.1390.135 

0.054 0.061 


(vol.) 

0.035 

Rieger 

Typ 3 

Typ 2 

Typ 1 

insgesamt 



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 % 



Baumöl u. a. 1996 Baumöl, Ulrike ; Borchers, Jens ; Eicker, 

Stefan ; Hildebrand, Knut ; Jung, Reinhard ; Lehner, Franz: 

Einordnung und Terminologie des Software Reengineering. In: 

Informatik Spektrum 19 (1996), S. 191–195 

Chikofsky und Cross II. 1990 Chikofsky, Elliot J. ; Cross II., 

James H.: Reverse Engineering and Design Recovery: A Taxonomy. In: 

IEEE Software 7 (1990), Januar, Nr. 1, S. 13–17 

Cytron u. a. 1991 Cytron, Ron ; Ferrante, Jeanne ; Rosen, 

Barry K. ; Wegman, Mark N. ; Zadeck, F. K.: Efficiently Computing 

Static Single Assignment Form and the Control Dependence Graph. In: 

ACM Transactions on Programming Languages and Systems 13 (1991), 

Oktober, Nr. 4, S. 451–490 

Koschke u. a. 1998 Koschke, Rainer ; Girard, Jean-François ; 

Würthner, Martin: An Intermediate Representation for Reverse 

Engineering Analyses. In: Proceedings of the 5th Working Conference 

on Reverse Engineering. Honolulu, HI, USA : IEEE Computer Society 

Press, Oktober 1998, S. 241–250 



Morgan 1998 Morgan, Robert: Building an Optimizing Compiler. 

Digital Press, 1998

Vorlesung Software-Reengineering - Informatik - Universität Bremen

Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.

Template löschen?

Als Template speichern?