Vorlesung Software-Reengineering ¨Uberblick I - Informatik - FB3 ...

Vorlesung Software-Reengineering
Prof. Dr. Rainer Koschke
Arbeitsgruppe Softwaretechnik
Fachbereich Mathematik und Informatik
Universität Bremen
Wintersemester 2013/14
Überblick I
Einführung
Statische Programmanalyse
Dynamische Analyse
Program Slicing
Metriken
Klonerkennung
Refactoring
Codetransformation

Überblick II
Software-Visualisierung
Einführung in das Software-Reengineering I
Einführung
Administrativa
Lernziele
Motivation
Wichtige Begriffe
Wartung
Reverse Engineering
Restrukturierung
Reengineering
Wrapping
Business Process Reengineering
Ziele und Aufgaben
Unterschiede zur Vorwärtsentwicklung
4 / 437

Organisatorisches
Vorlesung:
montags, 10:30 – 12:00 Uhr, MZH 1450
donnerstags, 14:00 s.t. – 15:30 Uhr, MZH 1450
Erreichbar: TAB 2.57, Telefon 218-64481, koschke@tzi.de
Sprechstunde nach Vereinbarung
Video im Netz http://mlecture.uni-bremen.de
bitte bei Stud.IP anmelden unter
https://elearning.uni-bremen.de/
Buch zur Vorlesung bei Stud.IP
Literatur: Folien zur Vorlesung und verwendete Artikel
http://www.informatik.uni-bremen.de/st/
lehredetails.php?id=&lehre_id=313
5 / 437
Scheinbedingungen
Modulprüfung: 30 min mündliche Prüfung
ansonsten
1 erfolgreiche Bearbeitung von praktischen Aufgaben (1-2
Personen): Eclipse-Plugins für
1 Abhängigkeitsanalyse
2 Metrikberechnung
3 Implementierung zweier Refactorings
2 Fachgespräch (einzeln, benotet; zählt zu einem Drittel)
6 / 437

Übersicht über diese Vorlesung
Statische
Programmanalysen und
-repräsentationen
Dynamische Analysen
Program-Slicing
Refactoring und
Transformationen
Software-Produkt-
Metriken
Erkennung duplizierten
Codes und anderer Bad
Smells
Software-Visualisierung
Analyse und
Restrukturierung von
Vererbungshierarchien
Merkmalsuche
(Feature-Location)
Software-Clustering, Architekturrekonstruktion
und -validierung
Reengineering-Projekte
7 / 437
Wegweiser
Was versteht man unter Reengineering genau?
Welche Gebiete des Reengineerings gibt es?
Was ist der Unterschied zur klassischen
Vorwärtsentwicklung?
8 / 437

Lehman und Beladys (1980) Hypothesen
Software-Evolution
Gesetz des fortgesetzten Wandels
Gesetz der ansteigenden Komplexität
. . .
⇒ ständige Anpassung erforderlich
⇒ Komplexität muss kontrolliert und begrenzt werden
11 / 437
Wunsch
Gewählte Lösung antizipiert mögliche Änderungen.
Änderungen werden auf der adäquaten Ebene vorgenommen.
Dokumentation wird mitgeführt.
12 / 437

Wirklichkeit
Die Zukunft lässt sich nur begrenzt vorhersagen.
Ursprüngliche Systemstruktur wird ignoriert.
Dokumentation ist unvollständig oder obsolet.
Mitarbeiter verlassen das Projekt (und mit ihnen verschwindet
das ganze Wissen).
13 / 437
Legacy System
Legacy:
“A sum of money, or a specified article, given to another
by will; anything handed down by an ancestor to a
predecessor.”
– Oxford English Dictionary
Definition
Legacy System: Software-System, das geerbt wurde und einen
Wert darstellt.
14 / 437

Staged Software Life Cycle Model
Initial Development
First running version
Loss of evolvabilty
Evolution
Servicing
Evolution Changes
Servicing Patches
Servicing discontinued
Switch−off
Phase−Out
Close−Down
– Rajlich und Bennett (2000)
15 / 437
Versioned Staged Model (Rajlich und Bennett 2000)
First running version
Initial Development
Version 1
Evolution Changes
Servicing
Servicing Patches
Phase−Out
Version 2
Close−Down
Evolution Changes
Servicing Patches
Servicing
Phase−Out
Close−Down
16 / 437

Begriffe
Software-Wartung
Software-Evolution
Reengineering
Software-Reengineering
Business-Process-
Reengineering
Renovation
Reclamation
Refactoring
Reverse Engineering
Restrukturierung
Wrapping
18 / 437
Software-Wartung
ANSI/IEEE Standard 729-1983:
“Modification of a software product after delivery to
correct faults, to improve performance or other attributes,
or to adapt the product to a changed environment.”
Häufiger Sprachgebrauch: Änderungen am System nach dessen
Auslieferung.
Schließt Anpassungen an neue Anforderungen ein.
Besserer Begriff hierfür: Software-Evolution.
19 / 437

Aufwand für Software-Wartung
korrektiv
22%
12%
perfektiv
adaptiv
25 %
41%
erweiternd
– Lientz und Swanson (1980)
20 / 437
Lientz und Swanson (1980) haben den Aufwand für verschiedene
Wartungsarten anhand von 487 Software-Organisationen näher
untersucht und festgestellt, dass ca. 80% der so genannten Wartung
tatsächlich Erweiterungen sind (neue Funktionalität bzw. Anpassungen
an neue Hardware- oder Software-Plattformen).

Aufwand im Software-Lifecycle
Verstehen 40%
Spezifikation
20% Entwickeln 20%
Test
40%
Entwurf
20%
Kodierung
20%
Ändern 40%
Boehm (1981) Fjeldstad und Hamlen (1979)
21 / 437
Eine typische Verteilung des Aufwands für Aktivitäten in der
Erstentwicklung wurde von Boehm (1981) anhand groß angelegter
empirischer Studien erhoben.
Der Aufwand für die Erstentwicklung ist jedoch vergleichsweise gering,
wenn man ihn mit dem Aufwand für Wartung vergleicht. Arthur (1988)
hat insgesamt sechs Untersuchungen aus den Siebzigern zum Anteil der
Wartung am Software-Lifecycle zusammen getragen. Der Aufwand liegt
in diesen Untersuchungen zwischen 60 und 80 Prozent. Die Garnter
Group, eine große Unternehmensberatung, sagt für die Zukunft sogar
einen ansteigenden Aufwand voraus, der bis zu 95% der Gesamtkosten für
Software einnehmen wird (Moad 1990).
Fjeldstad und Hamlen (1979) haben den Aufwand für die einzelnen
Wartungsaktivitäten empirisch näher untersucht und dabei heraus
gefunden, dass Wartungsprogrammierer ca. 50% ihrer Zeit allein mit der
Analyse beschäftigt sind, bevor sie eine Änderung tatsächlich vornehmen
und testen können. Bei korrektiver Wartung (also Fehlerbeseitigung) liegt
der Aufwand für die Analyse gar bei 60%.

Aufwand für Software-Evolution
US Air Force System (Boehm, 1975):
$ 30 / Statement bei Erstentwicklung
$ 4000 / Statement in der Wartung
22 / 437
Jahr-2000-Problem
Beseitigung des Jahr-2000-Problems (geschätzt von Cassell, 1997)
500.000.000.000 - 1.000.000.000.000 DM
23 / 437

Reverse Engineering
License Restrictions:
“Customer may not reverse engineer, disassemble,
decompile, or translate the Software, or otherwise
attempt to derive the source code of the Software.”
“To me the flow of time is irrelevant. You decide what
you want. I then merely make sure that it has already
happened.”
– The Hitch Hiker’s Guide to the Galaxy
24 / 437
Reverse Engineering (Chikofsky und Cross II. 1990)
Definition
Reverse Engineering: Identifikation der Systemkomponenten und
deren Beziehungen mit dem Ziel, das System in einer anderen
Form oder auf höherem Abstraktionsniveau zu beschreiben.
Forward
Engineering
Anforderungen Entwurf Code
Reverse
Engineering
26 / 437

Architekturrekonstruktion
Definition
Architekturrekonstruktion: Reverse Engineering mit dem Ziel,
eine Beschreibung der Architektur des Systems zu erstellen.
Anforderungen Entwurf Code
Architecture
Reconstruction
27 / 437
Restrukturierung (Chikofsky und Cross II. 1990)
Definition
Restrukturierung: Transformation einer Repräsentation in eine
andere auf derselben Abstraktionsebene, ohne Änderung der
Funktionalität des Systems.
Anforderungen Entwurf Code
Restrukturierung
28 / 437

Reengineering (Chikofsky und Cross II. 1990)
Definition
Reengineering: Untersuchung (Reverse Engineering) und
Änderung des Systems, um es in neuer Form zu implementieren.
Synonyme: Renovation, Reclamation.
Forward
Engineering
Anforderungen Entwurf Code
Restrukturierung
Reverse
Engineering
29 / 437
Reengineering-Varianten
Reines Reengineering:
das System soll lediglich restrukturiert werden
keine Funktionalität kommt hinzu / wird geändert
Erweiterndes Reengineering:
System wird zunächst analysiert und/oder restrukturiert, um
dann Funktionalität zu ändern oder hinzuzufügen
30 / 437

Wrapping
Das System erhält eine neue Schnittstelle, bleibt aber ansonsten
unangetastet.
Interimslösung, wenn System bald ausgewechselt werden soll.
Notwendig, wenn das System Subsystem per Subsystem
geändert werden muss.
Oft eingesetzt, um zeichenorientierte Anwendungen mit einer
graphischen Benutzerschnittstelle zu versehen.
Organisatorische Gründe:
altes“ Wartungspersonal behält Kontrolle über Wartung
”
ihres“ Systems
”
” junges“ Wartungspersonal hat ” moderne“ Sicht 31 / 437
Business Process Reengineering
“Business process reengineering is the search for, and the
implementation of, radical change in business process to
achieve breakthrough results.”
– T.A. Stewart, Fortune Magazine’93.
32 / 437

Business Process Reengineering
Etwas sachlicher:
Wiedergewinnung der tatsächlichen Abläufe der
Geschäftsprozesse (Workflow) (z.B. Bestellungswesen,
Auftragsabwicklung etc.)
Überarbeitung und Neudefinition der Abläufe
33 / 437
Ziele des Reverse Engineerings
Kontrolle der Komplexität
Gewinnung alternativer Sichten
Wiedergewinnung verlorener Information
Erkennung von Seiteneffekten
Schaffung höherer Abstraktionen
Unterstützung von Wiederverwendung
34 / 437

Häufige Reengineering-Aufgaben
Plattformanpassung
Änderung der Programmiersprache
neuer Standard, neue Sprache, neues Paradigma
Benutzerschnittstelle zeichenorientiert hin zu graphisch
orientiert
Mainframe hin zu Client-Server-Architektur
Datenbankumstellung
Präventive Maßnahmen, wie z.B. Verbesserung des Information
Hidings oder Remodularisierung, sind eher selten.
35 / 437
Mass Changes
Änderungen, die weite Teile des Codes bzw. sehr viele Systeme
betreffen.
Einführung des Euros
Legacy to Internet Interoperability (Electronic Commerce)
Änderung von Repräsentationsformen:
Y2K Problem
Erweiterung des Bar-Codes
Unix-Datum
→ Wunsch nach hohem Automatisierungsgrad
36 / 437

Reengineering in der Praxis
Gegenwärtig zur Verfügung stehende Werkzeuge:
grep
symbolische Debugger
Cross-Reference-Tools (fertige Parser, die Basisinformationen
extrahieren; z.T. mit Visualisierung durch Graphen)
UML-CASE-Tools, die Klassendiagramme extrahieren
programmierbare Analyse- und Transformationsumgebungen
basierend auf abstrakten Syntaxbäumen (z.B. Refine von
Reasoning Systems, DMS von Semantic Designs, RainCode)
37 / 437
Software Engineering
“Software engineering is reengineering on
the empty system.”
“Is it?”
38 / 437

Unterschiede Forward Eng. / Reengineering
Forward Engineering auf
grüner Wiese
Problem noch unklar
Aussagen über Aufwand,
Dauer, Zuverlässigkeit etc.
sind schwierig
System existiert nicht
Entwurf hat viele
Freiheiten
im sauberen Entwurf gibt
es keine versteckten
Abhängigkeiten
Reengineering
Problem weitgehend klar
Idealerweise: Daten aus der
Vergangenheit existieren, die
Grundlage für Schätzungen
darstellen
System existiert
Genaue Struktur/Qualität
bekannt?
Lösung ist durch
existierendes System
beschränkt
Änderungen können
globale Auswirkungen
haben (viele versteckte
Abhängigkeiten)
39 / 437
Software Engineering & Reengineering
Reengineering beginnt oft bereits während der Erstentwicklung:
neue Anforderungen treffen ein
Missverständnisse und Unklarheiten werden sichtbar
der Entwurf hat sich als unzureichend erwiesen
Integration anderer Komponenten macht Umstrukturierungen
notwendig
40 / 437

Weiterführende Literatur
Chikofsky und Cross II. (1990): “Reverse Engineering and
Design Recovery: A Taxonomy”, IEEE Software
definiert Terminologie; ist die begriffliche Grundlage
Baumöl u. a. (1996): “Einordnung und Terminologie des
Reengineering”
führt z.T. deutsche Begriffe ein
41 / 437
Bücher I
Demeyer u. a. (2002) stellen eine Reihe von Vorgehensweisen
bei typischen Problemen des Reengineerings vor
Müller (1997) bietet eine Einführung in verschiedene Aspekte
des Reengineerings (Programmverstehen, Metriken,
Sprachkonversion, Restrukturierung, Wiederverwendung,
Migration zu objektorientierten Systemen,
Managementaspekte)
obwohl meine Vorlesung 1999 in völliger Unkenntnis dieses
Buches entstanden ist, ist doch eine große Überlappung der
Inhalte festzustellen (das Buch beschreibt aber weniger die
konkreten Techniken)
Fowler (2000) beschreibt so genannte Bad Smells
(Code-Anomalien) und zugehörige Refactorings, um sie zu
beseitigen
42 / 437

Bücher II
Seacord u. a. (2003) beschreiben Methoden zur
Modernisierung von Anwendungssystemen; in erster Linie
Prozess- und Managementfragen werden erläutert
Simon u. a. (2006) beschreiben, wie man die Wartbarkeit von
Systemen messen kann; das Ergebnis ist eine Einstufung in
Analogie zu CMMI jedoch für die innere Produktqualität
Sneed u. a. (2005) beschreiben organisatorische Aspekte und
verschiedene Prozesse für die Wartung und Weiterentwicklung
von Software
Masak (2006) diskutiert verschiedene Aspekte der Wartung
und Evolution, insbesondere Beobachtungen, Metriken,
Anti-Patterns und Management
Pigoski (1996) behandelt Probleme und Managementlösungen
der Software-Wartung
Lehner (1989) beschreibt Probleme und Managementlösungen
der Software-Wartung
43 / 437
Statische Programmanalyse I
Statische Programmanalyse
Compiler versus Reengineering-Werkzeug
Lexikalische Ebene
Syntaktische Ebene
Abstrakte Syntax
Traversierungen von ASTs
Quellennahe Repräsentation
Kontrollfluss
Kontrollabhängigkeit
Datenabhängigkeit
Datenflussanalyse: Bestimmung von Set
Static Single Assignment Form
Aliasing
Analysemöglichkeiten
Wiederholungsfragen
44 / 437

Wegweiser
Kontext
Am Anfang steht die Analyse:
statische Analyse
dynamische Analyse
Welche Informationen kann man wie aus
Programmen statisch extrahieren?
Welche Formen der statischen
Programmrepräsentationen und -analysen gibt
es?
Worin unterscheidet sich die Programmanalyse
im Compilerbau von der im Reengineering?
45 / 437
Compiler-Struktur
Programmtext
mit
Makros
Präprozessor
Lexer
Programmtext
Tokenstrom
Parser
abstrakter
Syntaxbaum
semantische
Analyse
annotierter
abstrakter
Syntaxbaum
Front-End
Zwischensprachengenerator
Zwischendarstellung
Analysen u.
Optimierungen
optimierte
Zwischendarstellung
Middle-
End
Codegenerator
Code
Back-End
46 / 437

Analysator- und Transformator-Struktur
Programmtext
Programmtext
mit
Makros
Präprozessor
Lexer
Tokenstrom
Parser
abstrakter
Syntaxbaum
semantische
Analyse
annotierter
abstrakter
Syntaxbaum
Front-End
Zwischensprachengenerator
Zwischendarstellung
Analysen
Transformationen
annotierte
Zwischendarstellung
Middle-
End
Unparser Programmtext Back-End Wissensbasis
47 / 437
Phasen eines Compilers
• Wissen über das Programm nimmt zu
– syntaktische Dekomposition
– semantische Attributierung
– Namensbindung
– Kontrollflussinformation
– Datenflussinformation
• Abstraktion nimmt ab
– abstrakter Syntaxbaum
– maschinennahe einheitliche Zwischensprache, z.B. Register
Transfer Language (RTL) von Gnu GCC
– Maschinensprache

Unterschiede Compiler / Analysator
lokal ↔ global
optimistisch ↔ pessimistisch
quellennah ↔ sprachenunabhängig
48 / 437
Token (Lexem)
Definition
Ein Token (auch: Lexem) ist die kleinste unteilbare Einheit, die in
einer Programmiersprache von Bedeutung ist:
Schlüsselwörter
Bezeichner
Literale (Zahlen, Zeichenketten, einzelne Zeichen)
Operatoren
Trennzeichen (z.B. ;)
50 / 437

Üblicherweise keine Tokens:
• Whitespace
• Kommentare
Übliche Attribute:
• Typ (meist codiert als Zahl oder Aufzählungswert)
• Quellcodeposition (Dateiname, Zeile, Spalte)
• Wert (textuelle Repräsentation)
Der Tokenstrom
1 { i n t x ;
2 i n t y ;
3 y = 0 ;
4 x = y + 1 ;
5 }
Zeile Spalte Typ-Code Typ Wert
1 1 15 ’{’ {
1 2 5 INT int
1 6 4 ID x
1 7 17 ’;’ ;
2 2 5 INT int
2 6 4 ID y
2 7 17 ’;’ ;
3 2 4 ID y
3 4 18 ’=’ =
3 6 6 NUMBER 0
3 7 17 ’;’ ;
4 2 4 ID x
4 4 18 ’=’ =
4 6 4 ID y
4 8 19 ’+’ +
4 10 6 NUMBER 1
4 11 17 ’;’ ;
5 1 16 ’}’ }
51 / 437

Reguläre Grammatik
1 // R e g u l a r e x p r e s s i o n s to be used i n token d e f i n i t i o n s
2 fragment SPACE : ’ ’ | ’ \ t ’ ;
3 fragment LETTER LOWER : ( ’ a ’ . . ’ z ’ ) ;
4 fragment LETTER UPPER : ( ’A ’ . . ’Z ’ ) ;
5 fragment DIGIT : ( ’ 0 ’ . . ’ 9 ’ ) ;
6 fragment LETTERS : (LETTER LOWER | LETTER UPPER) ;
7
8 // Whitespace to be i g n o r e d
9 NEWLINE : ( ’ \ r ’ ? ’ \ n ’)+ { $ c h a n n e l = HIDDEN ; } ;
10 WHITESPACE : SPACE+ { $ c h a n n e l = HIDDEN ; } ;
11 COMMENT : ’ // ’ . ∗ ’ \ n ’ { $ c h a n n e l = HIDDEN ; } ;
12
13 // Token d e f i n i t i o n s
14 NUMBER : DIGIT +;
15 INT : ’ i n t ’ ;
16 ID : (LETTERS | ’ ’ ) ( LETTERS | DIGIT | ’ ’ )∗ ;
52 / 437
Generierung des Lexers
Reguläre Grammatik
// R e g u l a r e x p r e s s i o n s to be used i n token d e f i n i t i o n s
fragment SPACE : ’ ’ | ’ \ t ’ ;
fragment LETTER LOWER : ( ’ a ’ . . ’ z ’ ) ;
. . .
INT : ’ i n t ’ ;
ID : (LETTERS | ’ ’ ) ( LETTERS | DIGIT | ’ ’ )∗ ;
⇓
Lexergenerator: antlr, (f)lex, javaCC, . . .
⇓
Lexer (z.B. in C, C++, Java, Ada, . . . )
53 / 437

Verwendung des Lexers (AntLR)
1 F i l e R e a d e r r e a d e r = new F i l e R e a d e r ( a r g s [ 0 ] ) ;
2 ANTLRReaderStream i n p u t = new ANTLRReaderStream ( r e a d e r ) ;
3 SATLexer l e x e r = new SATLexer ( i n p u t ) ;
4 r e a d e r . c l o s e ( ) ;
5 CommonTokenStream tokenStream = new CommonTokenStream ( l e x e r ) ;
6
7 f o r ( Object o b j : tokenStream . getTokens ( ) ) {
8 CommonToken token = ( CommonToken ) o b j ;
9 i f ( token . g e t C h a n n e l ( ) != CommonToken . HIDDEN CHANNEL) {
10 System . out . p r i n t f
11 ( ”%d:%d token : %d name : %s v a l u e ( t e x t ) : %s \ n” ,
12 token . g e t L i n e ( ) ,
13 token . g e t C h a r P o s i t i o n I n L i n e ( ) + 1 ,
14 token . getType ( ) ,
15 SATParser . tokenNames [ token . getType ( ) ] ,
16 token . getText ( ) ) ;
17 }
18 }
54 / 437
Syntaxanalyse
Grammatiken definieren Programmiersprachensyntax mit Regeln
(BNF oder EBNF)
Grammatikregel
α 0 : α 1 α 2 . . . α n ; α i ∈ Σ ∪ Ω
Definition
Nichtterminale Ω: Symbole, die auf linker Seite einer Regel
auftreten
Definition
Terminale Σ: Symbole, die auf keiner linken Seite einer Regel
auftreten
→ Tokens
56 / 437

• es gibt verschiedene Grammatikklassen (LALR(k), LL(k), LR(k),
. . . )
• nicht für jede Programmiersprache gibt es eine offizielle Grammatik
(z.B. VisualBasic 6)
Beispielgrammatik in EBNF
1 b l o c k : ’ { ’ d e c l s stmts ’ } ’ ;
2
3 d e c l s : d e c l ’ ; ’ d e c l s | ;
4 d e c l : t y p e ID ;
5 t y p e : INT ;
6
7 stmts : stmt o p t s t m t s ;
8 o p t s t m t s : stmts | ;
9
10 stmt : ID ’= ’ e x p r ’ ; ’
11 | b l o c k
12 ;
13
14 e x p r : term ( ( ’+ ’ | ’− ’ ) term )∗ ;
15 term : p r i m a r y ( ( ’ ∗ ’ | ’ / ’ ) p r i m a r y )∗ ;
16 p r i m a r y : NUMBER
17 | ID
18 | ’ ( ’ e x p r ’ ) ’
19 ;
57 / 437

Konkreter Syntaxbaum
Definition
Konkreter Syntaxbaum (auch: Ableitungsbaum oder
Parsebaum): Herleitung einer Eingabe anhand angewandter
Grammatikregeln.
Innere Knoten: Nichtterminale der angewandten Regeln
Blätter: Terminale oder das leere Wort ɛ
⇒ Links-Rechts-Traversierung mit Ausgabe der Blätter liefert das
Originalprogramm
58 / 437
Beispiel für konkreten Syntaxbaum
1 { i n t x ;
2 i n t y ;
3 y = 0 ;
4 x = y + 1 ;
5 }
Tokenstrom:
’{’
INT
ID (“x”)
’;’
INT
ID (“y”)
’;’
ID (“y”)
’=’
NUMBER (“0”)
’;’
ID (“x”)
’=’
ID (“y”)
’+’
NUMBER (“1”)
’;’
’}’
60 / 437

Beispiel eines konkreten Syntaxbaums
61 / 437
Der Parser
Grammatik
1 b l o c k : ’ { ’ d e c l s stmts ’ } ’ ;
2
3 . . .
4 p r i m a r y : NUMBER
5 | ID
6 | ’ ( ’ e x p r ’ ) ’
7 ;
⇓
Parsergenerator: AntLR, yacc, bison, cocktail95, JavaCC, . . .
⇓
Parser
62 / 437

Verwendung des Parsers (AntLR)
1 tokenStream = new TokenRewriteStream ( l e x e r ) ;
2 SATParser p a r s e r = new SATParser ( tokenStream ) ;
3
4 SATParser . b l o c k r e t u r n r = p a r s e r . b l o c k ( ) ;
5 CommonTree c t = ( CommonTree ) r . g e t T r e e ( ) ;
6
7 System . out . p r i n t l n ( ”#l e a v e s : ” + c t . g e t C h i l d C o u n t ( ) ) ;
8 System . out . p r i n t l n ( c t . t o S t r i n g T r e e ( ) ) ;
63 / 437
Datenstrukturen für konkreten Syntaxbaum
1 p u b l i c a b s t r a c t c l a s s Node { }
2
3 p u b l i c a b s t r a c t c l a s s D e c l s e x t e n d s Node { }
4
5 p u b l i c c l a s s D e c l s 1 e x t e n d s D e c l s {
6 p r i v a t e Decl d e c l ;
7 p r i v a t e CommonToken s e m i c o l o n ;
8 p r i v a t e D e c l s d e c l s ;
9
10 p u b l i c D e c l s 1 ( Decl d e c l , CommonToken s e m i c o l o n , D e c l s d e c l s ) {
11 t h i s . d e c l = d e c l ;
12 t h i s . s e m i c o l o n = s e m i c o l o n ;
13 t h i s . d e c l s = d e c l s ;
14 }
15 }
16
17 p u b l i c c l a s s D e c l s 2 e x t e n d s D e c l s { }
64 / 437

Abstrakter Syntaxbaum
Definition
Abstrakter Syntaxbaum (engl. Abstract Syntax Tree AST) ist
eine strukturerhaltende (homomorphe) Abstraktion des konkreten
Syntaxbaums.
65 / 437
Wovon abstrahiert wird, ist anwendungsspezifisch.
Einfache Abstraktionen:
• Vermeidung von Ketten
• Sequenzen ersetzen Links- und Rechtsrekursionen
• irrelevante Terminale
Weitergehende Abstraktionen:
• ”
charakteristische“ Blätter werden zu inneren Knoten
• Normalisierungen (z.B. a != b wird zu !(a==b))
• Unifizierungen (s.u.)

Beispiel eines abstrakten Syntaxbaums
1 { i n t x ;
2 i n t y ;
3 y = 0 ;
4 x = y + 1 ;
5 }
decls
block
1:1
stmts
0:0
0:0
var_decl y
var_decl x
=
=
1:6
2:6
3:4
4:4
int
int
id y
literal 0
id x
+
1:2
2:2
3:2
3:6
4:2
4:8
id y
4:6
literal 1
4:10
66 / 437
Abstrakter Syntaxgraph (Attributierung des AST)
Definition
Syntaktische Kanten repräsentieren syntaktische Dekomposition
(bilden Baum).
Definition
Semantische Kanten: alle ergänzenden Kanten, die semantische
Verweise auf andere Knoten repräsentieren.
Z.B. Namensverwendung → Deklaration
Definition
Abstract Syntax Graph (ASG): syntaktische + semantische
Kanten
67 / 437

Beispiel eines abstrakten Syntaxbaums
block
1:1
decls
stmts
0:0
0:0
var_decl y
var_decl x
=
=
1:6
2:6
3:4
4:4
decl
decl
int
1:2
int
2:2
decl
id y
3:2
literal 0
3:6
id x
4:2
+
4:8
id y
literal 1
4:6
4:10
68 / 437
Abstrakte Syntax definiert Struktur aller ASTs
Decls
Node
Seq
# children : list of Node
Stmts
Type
Int
Expr
Binary
+ left : Expr
+ right : Expr
Plus
Minus
Atomic
Literal
+ value : int
Unary
+ operand : Expr
ID
+ decl : Decl // semantic
+ name : string
Stmt
Assign
+ lhs : Expr
+ rhs : Expr
Decl
Var_Decl
+ name : string
+ type : Type
Block
+ decls : Decls
+ stmts : Stmts
69 / 437

Traversierungen des ASTs
Definition
Explizite Traversierungen: Besuchsreihenfolge wird vom
Programmierer selbst festgelegt bzw. ist vordefiniert.
Tiefensuche
Postorder
Preorder
Breitensuche
→ z.B. Entwurfsmuster Visitor
Definition
Implizite Traversierungen: Besuchsreihenfolge ergibt sich aus der
Berechnung.
→ z.B. Attributgrammatiken
70 / 437
Visitor Pattern
Problem: ein Algorithmus soll alle Knoten im AST besuchen und
behandeln. Beispiel: Unparse.
Anforderungen:
alle Knoten im AST müssen besucht werden
jeder Knotentyp muss individuell behandelt werden können
die Besuchsreihenfolge kann variieren
weitere solche Algorithmen sollen einfach hinzugefügt werden
können, ohne dass die Klassen der AST-Knoten geändert
werden müssen
Lösung: Visitor-Pattern
71 / 437

AST Visitor Pattern
...
Visitor
+visit_stmts()
+visit_var_decl()
+visit_plus()
...
+visit_block()
Simple_Visitor
+visit_stmts()
+visit_var_decl()
+visit_plus()
...
+visit_block()
+visit_stmts()
+visit_var_decl()
+visit_plus()
...
+visit_block()
Node
visits
* * +accept(visitor)
Unparse_Visitor
Seq
# children : list of Node
Type
Expr
Stmt
Int
Binary
+ left : Expr
+ right : Expr
Atomic
Unary
Decls
+ operand : Expr
Assign
+ lhs : Expr
+ rhs : Expr
+ accept(visitor)
Decl
Block
Stmts
+ accept(visitor v)
+ decls : Decls
+ stmts : Stmts
+ accept(visitor)
+ accept(visitor v)
+ accept(visitor v)
Plus
+ accept(visitor v)
Minus
+ accept(visitor v)
Literal
+ value : int
+ accept(visitor)
ID
+ decl : Decl // semantic
+ name : string
+ accept(visitor)
Var_Decl
+ name : string
+ type : Type
+ accept(visitor)
v.visit_minus(this)
v.visit_plus(this)
72 / 437
Beteiligte:
• AST-Knoten
– werden besucht
– deklarieren eine accept-Operation, die die entsprechende
visit-Operation aufrufen
• Visitor (Interface):
– Schnittstelle für alle Visitors
– deklariert eine visit-Operation für jeden konkreten
AST-Knotentyp
• Simple-Visitor
– implementiert Visitor
– Standardimplementierung mit fester Besuchsreihenfolge
• konkreter Visitor
– leitet von Simple-Visitor ab
– überschreibt ererbte visit-Operation abhängig von Aufgabe

Unparse mit Visitor: besuchbare AST-Knoten
1 p u b l i c a b s t r a c t c l a s s Node {
2 p r i v a t e i n t l i n e ;
3 p r i v a t e i n t column ;
4 p u b l i c a b s t r a c t v o i d a c c e p t ( V i s i t o r v i s i t o r ) ;
5 }
6
7 p u b l i c a b s t r a c t c l a s s Expr e x t e n d s Node { }
8
9 p u b l i c a b s t r a c t c l a s s B i n a r y e x t e n d s Expr {
10 p u b l i c Expr l e f t ;
11 p u b l i c Expr r i g h t ;
12 }
13
14 p u b l i c c l a s s P l u s e x t e n d s B i n a r y {
15 p u b l i c v o i d a c c e p t ( V i s i t o r v i s i t o r ) {
16 v i s i t o r . v i s i t p l u s ( t h i s ) ;
17 }
18 }
73 / 437
Unparse mit Visitor: Visitor-Interface
1 p u b l i c i n t e r f a c e V i s i t o r {
2
3 p u b l i c v o i d v i s i t m i n u s ( Minus node ) ;
4 p u b l i c v o i d v i s i t p l u s ( P l u s node ) ;
5
6 . . .
7
8 p u b l i c v o i d b e f o r e m u l t ( Mult node ) ;
9 p u b l i c v o i d b e f o r e p l u s ( P l u s node ) ;
10
11 . . .
12 p u b l i c v o i d a f t e r m i n u s ( Minus node ) ;
13 p u b l i c v o i d a f t e r p l u s ( P l u s node ) ;
14 }
74 / 437

Unparse mit Visitor: Standardimplementierung
1 p u b l i c c l a s s S i m p l e V i s i t o r implements V i s i t o r {
2
3 p r i v a t e v o i d v i s i t b i n a r y ( B i n a r y node ) {
4 node . g e t L e f t ( ) . a c c e p t ( t h i s ) ;
5 node . g e t R i g h t ( ) . a c c e p t ( t h i s ) ;
6 }
7 p u b l i c v o i d v i s i t m i n u s ( Minus node ) {
8 b e f o r e m i n u s ( node ) ;
9 v i s i t b i n a r y ( node ) ;
10 a f t e r m i n u s ( node ) ;
11 }
12 p u b l i c v o i d v i s i t p l u s ( P l u s node ) {
13 b e f o r e p l u s ( node ) ;
14 v i s i t b i n a r y ( node ) ;
15 a f t e r p l u s ( node ) ;
16 }
17 . . .
75 / 437
Unparse mit Visitor: Standardimplementierung
1 . . .
2 p u b l i c v o i d b e f o r e m i n u s ( Minus node ) { }
3 p u b l i c v o i d b e f o r e p l u s ( P l u s node ) { }
4 . . .
5 p u b l i c v o i d a f t e r m i n u s ( Minus node ) { }
6 p u b l i c v o i d a f t e r p l u s ( P l u s node ) { }
7 . . .
76 / 437

Unparse mit Visitor: Unparse-Implementierung
1 p u b l i c c l a s s Unparser e x t e n d s S i m p l e V i s i t o r {
2
3 p r i v a t e v o i d v i s i t b i n a r y ( B i n a r y node , S t r i n g op ) {
4 node . l e f t . a c c e p t ( t h i s ) ;
5 System . out . p r i n t ( op ) ;
6 node . r i g h t . a c c e p t ( t h i s ) ;
7 }
8
9 p u b l i c v o i d v i s i t m i n u s ( Minus node ) {
10 v i s i t b i n a r y ( node , ” − ” ) ;
11 }
12
13 p u b l i c v o i d v i s i t p l u s ( P l u s node ) {
14 v i s i t b i n a r y ( node , ” + ” ) ;
15 }
16 . . .
77 / 437
Attributgrammatiken
Probleme des Visitor-Musters:
Visitor ist programmatisch und erfordert viel Kodieraufwand
Visitor reicht nur für einfache Aufgaben aus
Attributgrammatiken für den Syntaxbaum:
beschreiben Berechnung von Knotenattributen
Berechnung ist deklarativ
Traversierungsreihenfolge ergibt sich aus
Berechnungsvorschrift
automatische Code-Generierung ist möglich
78 / 437

Attributgrammatiken
Definition
Eine Attributgrammatik besteht aus:
Beispiel:
Attributen für Grammatiksymbole (Nichtterminal und
Terminal) bzw. Baumknoten
deklarativen Regeln zur Berechnung der Attribute
1 e x p r r e t u r n s [ Expr t r e e ] :
2 t=term o= ’+ ’ e=e x p r { $ t r e e = new P l u s ( $t . t r e e , $e . t r e e ) ; }
3 | t=term o= ’− ’ e=e x p r { $ t r e e = new Minus ( $t . t r e e , $e . t r e e ) ; }
4 | t=term { $ t r e e = $t . t r e e ; }
5 ;
79 / 437
Arten von Attributen
Definition
Ein Attribut eines Nichtterminals ist synthetisiert, wenn es nur
von Attributen von Symbolen der rechten Seite seiner Regeln
abhängt.
1 e x p r r e t u r n s [ Expr t r e e ] :
2 t=term o= ’+ ’ e=e x p r { $ t r e e = new P l u s ( $t . t r e e , $e . t r e e ) ; }
3 | t=term o= ’− ’ e=e x p r { $ t r e e = new Minus ( $t . t r e e , $e . t r e e ) ; }
4 | t=term { $ t r e e = $t . t r e e ; }
5 ;
80 / 437

Arten von Attributen
Definition
Ein Attribut eines Nichtterminals ist ererbt, wenn es nur von
Attributen von Symbolen
der linken Seite und
von ”
Geschwistersymbolen“
der Regeln abhängt, in denen das Symbol auf einer rechten Seite
auftritt.
Ein ”
Geschwistersymbol“ ist ein Symbol, das auf der selben
rechten Seite auftritt.
81 / 437
Arten von Attributen
1 e x p r r e t u r n s [ Expr t r e e ]
2 : t=term e=e x p r c o n t i n u e d [ $t . t r e e ] { $ t r e e = $e . t r e e ; }
3 ;
4
5 e x p r c o n t i n u e d [ Expr i n h ] r e t u r n s [ Expr t r e e ]
6 : o= ’+ ’
7 t=term
8 e=e x p r c o n t i n u e d
9 [ new P l u s ( $o . l i n e , $o . column , $inh , $t . t r e e ) ]
10 { $ t r e e = $e . t r e e ; }
11 | o= ’− ’
12 t=term
13 e=e x p r c o n t i n u e d
14 [ new Minus ( $o . l i n e , $o . column , $inh , $t . t r e e ) ]
15 { $ t r e e = $e . t r e e ; }
16 | { $ t r e e = $ i n h ; }
17 ;
82 / 437

Datenfluss zwischen Attributen
expr
tree
term
tree
expr_continued
inh
tree
+ term expr_continued
tree
inh
tree
− term expr_continued
tree
ɛ
inh
tree
83 / 437
Anforderungen an Zwischendarstellungen
möglichst quellennah ↔ möglichst vereinheitlicht
84 / 437

widersprüchliche Anforderungen:
1. möglichst quellennah, da Informationen an Wartungsprogrammierer
ausgegeben werden sollen bzw. tatsächlicher Code wieder generiert
werden soll
⇒ alle spezifischen Konstrukte müssen dargestellt werden
2. möglichst vereinheitlicht, um das Schreiben von Programmanalysen
für verschiedene Programmiersprachen zu vereinfachen
⇒ möglichst wenige, allgemeine Konstrukte
Quellennahe Betrachtung
while P loop
A;
end loop;
cond
P
while
A
body
85 / 437

Einfache allgemeine Konstrukte
while P loop
A;
end loop;
ist äquivalent zu:
loop
if P then
A;
else
exit;
end if;
end loop;
P
loop
body then
if
cond else
A
exit
86 / 437
Vereinigung der Sichten
P
loop
body then
if
cond else
A
exit
cond
P
while
A
body
inheritance
hierarchy:
loop
is a
for while
is a loop
real body
cond while
body A
then
P
cond if
else exit
syntaktische Kante
Annotation
87 / 437

Kontrollflussinformation
main
entry
intraprozedural: Flussgraph
Knoten: Grundblöcke
Kanten: (bedingter/unbedingter)
Kontrollfluss
interprozedural: Aufrufgraph
Multigraph
Knoten: Prozeduren
Kanten: Aufruf (eine für jede
Aufrufstelle); Schleifen → Rekursion
t
a = 1;
b = 2;
a>0 f
exit
main
c = f(c);
f
89 / 437
Intraprozeduraler Kontrollfluss ergibt sich aus syntaktischer Struktur und
etwaigen Gotos, Exits, Continues etc.
Interprozeduraler Kontrollfluss ergibt sich aus expliziten Aufrufen im
Programmcode sowie aus Aufrufen über Funktionszeiger

Intra- und interprozeduraler Kontrollfluss
main
int f (int p)
entry
entry
t
a>0 f
c→ p
r = 0;
x = p;
a = 1;
b = 2;
c = f(c);
f
x>0
exit
r→ c
t
r = r + p;
x = x - 1;
exit & return r
90 / 437
Fragestellungen zum Kontrollfluss
Was wird garantiert vorher ausgeführt?
Was wird garantiert nachher ausgeführt?
91 / 437

• Fragestellungen:
– Welche Prozeduren sind lokal zueinander?
Genauer: Gibt es eine Prozedur D, über nur die ein Aufruf von
N erfolgt?
– Welcher Block D im Flussgraph muss in jedem Falle passiert
werden, damit Block N ausgeführt werden kann?
→ Antwort: D ist der Dominator von N
Dominanz
Definition
Ein Knoten D dominiert einen Knoten N (D dom N), wenn D auf
allen Pfaden vom Startknoten zu N liegt.
Ein Knoten D dominiert N strikt, wenn D dom N ∧ D N .
Ein Knoten D ist der direkte Dominator von N (idom(N)=D),
wenn
1 D ist ein strikter Dominator von N: D dom N (D N) und
2 alle weiteren Dominatoren von N dominieren D:
∀D ′ dom N : (D ′ dom D ∨ D ′ = D)
92 / 437

Dominanz
Graph
4
2
5
9
1
3
6
7
8
Dominanzbaum
1
2 5 10 3
4 9 6 7
10
11
12
8 11 12
93 / 437
Postdominanz
Definition
Ein Knoten D postdominiert einen Knoten N, wenn jeder Pfad
von N zum Endknoten den Knoten D enthält (entspricht
Dominanz des umgekehrten Graphen).
Graph
1
Postdominanzbaum
2
3
exit
4
5
9
6
7
8
1 11 10 3 6
12 9 2 4 7
10
exit 11
12
8
5
94 / 437

Kontrollabhängigkeit
Definition
Knoten X ist kontrollabhängig von Bedingung B, wenn B
entscheiden kann, ob X ausgeführt wird:
1 B muss mehrere direkte Nachfolger haben und
2 B hat einen Pfad zum Endknoten, der X vermeidet (d.h. B
kann nicht von X postdominiert werden) und
3 B hat einen Pfad zu X, d.h. insgesamt hat B mindestens zwei
Pfade:
einer führt zu X
einer umgeht X
95 / 437
Kontrollabhängigkeit
Definition
Ein Knoten X ist direkt kontrollabhängig von einem Knoten B
genau dann, wenn
1 es einen nicht-leeren Pfad von B nach X gibt, so dass X jeden
Knoten auf dem Pfad (ohne B) postdominiert und
2 entweder X = B oder X postdominiert B nicht
B
a
X
für alle a:
X postdominiert a
B=X
a
für alle a:
X postdominiert a
exit
exit
transitiver Kontrollfluss
96 / 437

Kontrollabhängigkeit
Definition
Ein Knoten X ist direkt kontrollabhängig von einer Kante (B, S)
genau dann, wenn
1 es einen nicht-leeren Pfad beginnend mit (B, S) nach X gibt,
so dass X jeden Knoten auf dem Pfad (ohne B) postdominiert
und
2 entweder X = B oder X postdominiert B nicht
B
S
X
B=X
a
a
S
für alle a:
X postdominiert a für alle a:
X postdominiert a
exit
exit
transitiver Kontrollfluss
direkter Kontrollfluss
97 / 437
Kontrollabhängigkeit
1 f u n c t i o n CD ( (B, S ) : Edge ) r e t u r n s e t o f nodes
2 b e g i n −− c o n t r o l dependency
3
4 depends := ∅ ;
5 X := S ;
6
7 w h i l e X pdom (B) l o o p
8 depends := depends ∪ {X } ;
9 X := pdom (X ) ;
10 end l o o p ;
11
12 r e t u r n depends ;
13 end CD;
98 / 437

Kontrollabhängigkeit
Beispiel für Kontrollabhängigkeit
KFG
if (b1) {
do {
a;
} while
(b2);
}
f
b1
t
a
b2
f
exit
t
Postdominanz
exit
b1 b2
a
(b1, a)
(b1, exit)
(b2, a)
(b2, exit)
99 / 437
(b1, a) a, b2
(b1, exit) –
(b2, a) a, b2
(b2, exit) –

Kontrollabhängigkeit
Für strukturierte Programme: eine Anweisung ist kontrollabhängig
von der Bedingung der nächstumgebenden Schleife oder bedingten
Anweisung.
1 w h i l e ( a ) {
2 i f ( b ) {
3 x = y ; // k o n t r o l l a b h ä n g i g von b
4 }
5 z = 1 ; // k o n t r o l l a b h ä n g i g von a
6 do {
7 z = z + 1 ;
8 }
9 w h i l e ( z < 10)
10 }
100 / 437
N.B.: Bedingungen in repeat-Schleifen sind von sich und dem
umgebenden Konstrukt abhängig (siehe voriges Beispiel).

Repräsentation der Kontrollabhängigkeit
b1
t
t
f
t
t
a
t
t
b2
f
exit
101 / 437
Datenabhängigkeiten
Datenflussrelevante Operationen:
Set = Setzen eines Wertes
Use = Verwendung eines Wertes
Datenabhängigkeiten
Set-Use (Datenabhängigkeit)
Use-Set (Anti-Dependency)
Set-Set (Output-Dependency)
103 / 437

• Set-Use Beziehung (Datenabhängigkeit)
A setzt den Wert, der von B verwendet wird
• Use-Set Beziehung (Anti-Dependency)
A liest den Wert und B überschreibt ihn danach
• Set-Set Beziehung (Output-Dependency)
der von A gesetzte Wert wird von B überschrieben
Codetransformationen müssen diese Beziehungen erhalten.
Datenabhängigkeit (Set-Use)
a := 10;
b := a + 1;
a := 2 * a;
c := a + b;
104 / 437

Wichtigste Beziehung: Set-Use
Zwischen der 2. und 3. Anweisung besteht eine ”
Use-Set“, zwischen der
1. und 3. Anweisung eine ”
Set-Set“-Beziehung.
Datenflussprobleme
Gültige Definitionen (Reaching Definitions)
. . . beantwortet die Frage, welche Definition einer Variablen (d.h.
Zuweisungen an diese Variable) welche Verwendungen der selben
Variablen erreichen.
Definition
Eine Definition D erreicht einen Punkt P, falls es einen Weg von
D nach P gibt, auf dem keine weitere Zuweisung an die in D
gesetzte Variable V erfolgt.
105 / 437

Beispielprogramm
1 v o i d printSum ( f l o a t a [ ] ) {
2 i n t i ;
3 f l o a t s ;
4 f l o a t v ;
5
6 i = 0 ;
7 s = 0 . 0 ;
8 v = 0 . 0 ;
9
10 w h i l e ( i < a . l e n g t h ) {
11 v = a [ i ] ;
12 i = i + 1 ;
13 s = s + v ;
14 }
15
16 p r i n t ( ”sum” , s ) ;
17 }
106 / 437
Grundlage Kontrollflussgraph
B0
entry
B1
6: i = 0
7: s = 0.0
8: v = 0.0
B2
B4
10: i < a.length
16: print("sum", s)
f
t
B3
11: v = a[i]
12: i = i + 1
13: s = s + v
B5
exit
107 / 437

Zuweisungen im Kontrollflussgraph
I. Allg.: Konservative Annahme:
Jeder Aufruf einer unbekannten Methode liest und ändert alle
Referenzparameter sowie das betroffene Objekt und liest alle
Werteparameter.
Im Beispiel:
Anweisung zugewiesene Variablen (Set) gelesene Variablen (Use)
6 i
7 s
8 v
10 i, a
11 v i, a
12 i i
13 s s, v
16 s
108 / 437
Lokale Datenflussanalyse
Lokale Information pro Grundblock B:
GEN(B) = Menge aller Zuweisungen in B, die das Ende von
B erreichen (lokale Analyse im Grundblock).
KILL(B) = Menge aller Zuweisungen im gesamten
Kontrollflussgraphen (KFG), deren Variable in B neu gesetzt
wird und nicht in GEN(B) enthalten ist (flussinsensitive
Analyse im KFG).
Im Beispiel:
Block GEN KILL
B0
B1 6,7,8 11,12,13
B2
B3 11,12,13 6,7,8
B4
B5
109 / 437

Globale Datenflussanalyse über Kontrollflussgraph
Grundblock hängt von seinen Vorgängern ab:
in(B) = Definitionen, die den Eingang von B erreichen
out(B) = Definitionen, die den Ausgang von B erreichen
Datenflussgleichungen:
in(B) =
⋃
B ′ ist Vorgänger von B
out(B ′ )
out(B) = (in(B) − KILL(B)) ∪ GEN(B)
110 / 437
→ rekursives Problem
→ gesucht ist der kleinste Fixpunkt

Iterative Lösung der Gleichungen
1 f o r each b l o c k B l o o p
2 out (B) := GEN(B ) ;
3 end l o o p ;
4
5 s t a b l e := f a l s e ;
6 w h i l e ¬ s t a b l e l o o p
7 s t a b l e := t r u e ;
8 f o r each b l o c k B l o o p
9 i n (B) := ⋃ B ′ →B out(B′ ) ;
10 o l d o u t := out (B ) ;
11 out (B) := ( i n (B) − KILL (B) ) ∪ GEN(B ) ;
12 i f out (B) o l d o u t then
13 s t a b l e := f a l s e ;
14 end i f ;
15 end l o o p ;
16 end l o o p ;
111 / 437
Iterative Lösung der Gleichungen mit Worklist
N = Menge aller Grundblöcke im Kontrollflussgraph
1 f o r each b l o c k B l o o p
2 out (B) := GEN(B ) ;
3 end l o o p ;
4 wl := N − {entry} ;
5
6 l o o p
7 B := f i r s t ( wl ) ;
8 wl := wl − {B} ;
9 e f f e c t := ∅ ;
10 f o r each P ∈ P r e d e c e s s o r s (B) l o o p
11 e f f e c t := e f f e c t ∪ out (P ) ;
12 end l o o p ;
13 i f i n (B) e f f e c t then
14 i n (B) := e f f e c t ;
15 out (B) := ( i n (B) − KILL (B) ) ∪ GEN(B ) ;
16 wl := wl ∪ S u c c e s s o r s (B ) ;
17 end i f ;
18 e x i t when wl = ∅ ;
19 end l o o p ;
112 / 437

Beispiel
B wl B1 B2 B3 B4
gen kill gen kill gen kill gen kill
6-8 11-13 ∅ ∅ 11-13 6-8 ∅ ∅
in out in out in out in out
– B1,B2,B3,B4 ∅ 6-8 ∅ ∅ ∅ 11-13 ∅ ∅
113 / 437
Beispiel für Worklist-Algorithmus
B wl B1 B2 B3
gen kill gen kill gen kill gen
6-8 11-13 ∅ ∅ 11-13 6-8 ∅
in out in out in out in
– B1,B2,B3,B4 ∅ 6-8 ∅ ∅ ∅ 11-13 ∅
B1 B1,B2,B3,B4 ∅ 6-8 ∅ ∅ ∅ 11-13 ∅
B2 B2,B3,B4 ∅ 6-8 6-8,11-13 6-8,11-13 ∅ 11-13 ∅
B3 B3,B4 ∅ 6-8 6-8,11-13 6-8,11-13 6-8,11-13 11-13 ∅
B4 B4,B2 ∅ 6-8 6-8,11-13 6-8,11-13 6-8,11-13 11-13 6-8,11-13
B2 B2 ∅ 6-8 6-8,11-13 6-8,11-13 6-8,11-13 11-13 6-8,11-13

Terminierung des Algorithmus
Der Algorithmus terminiert, weil
wenn keine Menge mehr wächst, ist Abbruchbedingung erfüllt
ansonsten: eine Menge wird größer
die Mengen wachsen monoton
die Mengen sind nach oben begrenzt (durch alle Definitionen
der Methode) und können nicht beliebig wachsen
114 / 437
Repräsentation der Datenabhängigkeit
x < 0
a := 1; y > 0
a := 2; a := 3;
z < y
. . . := a;
. . . := a;
. . . := a;
115 / 437

Repräsentation der Datenabhängigkeit
Definition
Ein Programm ist in der Static Single Assignment Form (SSA),
wenn jede Variablenverwendung (Use) nur eine Definition (Set)
hat.
116 / 437
Wunsch nach einer kompakteren Darstellung: Nur eine Definition für jede
Verwendung.
Wird erreicht durch eingeführte künstliche Zuweisungen, sogenannte
φ-Knoten:
• am Anfang der Grundblöcke, an denen Kontrollflüsse
zusammenlaufen,
• auf denen verschiedene Definitionen der gleichen Variablen liegen.

Static Single Assignment Form
x < 0
a := 1; y > 0
a := 2; a := 3;
a := φ(a,a)
z < y
a := φ(a,a)
. . . := a;
. . . := a;
. . . := a;
117 / 437
Beispiel der SSA
1 x , y , z : T; x 0 := i n i t ; y 0 := i n i t ; z 0 := i n i t ;
2 i f cond1 then
3 y 1 := 4 ;
4 x 1 := 5 ;
5 e l s e
6 y 2 := 3 ;
7 end i f ;
8 x 2 := φ( x 0 , x 1 ) ; y 3 := φ( y 1 , y 2 ) ;
9 w h i l e z 1 := φ( z 0 , z 5 ) ; cond2 l o o p
10 i f y 3 > 0 then
11 z 2 := x 2 + z 1 ;
12 end i f ;
13 z 3 := φ( z 1 , z 2 )
14 i f y 3

Beispielanwendung
Problem: Finde alle potenziell lokal uninitialisierten Variablen
Lösung mit SSA:
für jede initiale Definition D:
propagiere D längs der Use-Kanten und markiere alle dabei
erreichten Verwendungen von Variablen
jede markierte Verwendung einer Variablen ist potenziell
undefiniert
119 / 437
Einfügepunkte für φ-Knoten
φ-Knoten werden eingefügt . . .
am Anfang der Grundblöcke, an denen Kontrollflüsse
zusammenlaufen,
auf denen verschiedene Definitionen der gleichen Variablen
liegen.
→ Wie lassen sich diese Punkte effizient algorithmisch bestimmen?
121 / 437

Einfügepunkte für φ-Knoten (Cytron u. a. 1991)
entry
1: a = init
b
2: a = 1
. . .
3: a = 2
b ′
c 1 ¬b dom c 1
b dom c 1
′ b ′ dom c 2
′
c 1
′ c 2
′
→ c 1 , b ′ ∈ Dominanzgrenzen({entry, b, b ′ })
122 / 437
Dominanzgrenzen
Definition
Die Dominanzgrenze (engl. Dominance Frontier) DF (B) eines
Blocks B ist die Menge aller Blöcke C wie folgt:
1 B dom C ′ ∧ C ′ ist unmittelbarer Vorgänger von C im
Kontrollflussgraph und
2 entweder B = C oder ¬B dom C
(d.h. B ist kein strikter Dominator von C)
123 / 437

Anschaulich: Dominanzgrenze enthält alle Blöcke, die aus dem
Dominanzteilbaum mit der Wurzel B (exklusive B selbst) heraus führen.
Dominanzgrenzen
b0
b0
b1
b2
b3
b5
b4
b3
b2
b1
b4
b5
b6
b0
b1
b2
b3
b4
b5
b6
DF
∅
b1, b6
b2, b5
b2, b5
b3
b1, b6
∅
b6
dom
control
124 / 437

0
b1
b2
b3
b4
b5
b6
DF
∅
b1, b6
b2, b5
b2, b5
b3
b1, b6
∅
SSA-Aufbau
1 f o r V ∈ Variables l o o p
2 wl := {B|B contains Set(V )} ∪ {entry}
3 done := ∅
4 w h i l e wl ∅ l o o p
5 s e l e c t any B ∈ wl
6 wl := wl − {B}
7 f o r B ′ ∈ DF (B) l o o p
8 i f B ′ done then
9 n := #p r e d e c e s s o r s (B ′ )
10 i n s e r t ”V ← φ(V , . . . , V )” i n t o B ′ with n arguments
11 wl := wl ∪ { B ′ }
12 done := done ∪ { B ′ }
13 end i f
14 end l o o p
15 end l o o p
16 end l o o p
125 / 437

• für jedes Set(V) in einem Block B müssen φ-Knoten in allen
Blöcken B ′ ∈ DF (B) eingefügt werden
• φ-Knoten sind auch Zuweisungen
Varianten von Set
Sicherheit der Überschreibung:
Starke Aktualisierung (must-set): v = 1;
Schwache Aktualisierung (may-set):
p = &v; if (foo()) p = &w; *p = 1;
Umfang der Überschreibung:
Vollständige Aktualisierung: v = 1;
Teilweise Aktualisierung: a[i] = 1;
126 / 437

Wichtige Mengen beim Aufbau von SSA
Anweisung A:
Must-Set (A)
May-Set (A)
May-Use (A)
1 a 1 = 1 ; // Must−Set ( 1 ) = { a }
2 f (&a ) ; // May−Set ( 2 ) = { a } , May−Use ( 2 ) = { a }
3 a 2 = φ(a 1 , a f ) // a f r e p r ä s e n t i e r t den Wert aus f
4 . . . a 2 . . . // May−Use ( 4 ) = { a }
127 / 437
• Must-Set (A):
Menge von Variablen, die sicher von A verändert werden
→ identifiziert die Definitionen
• May-Set (A):
Menge von Variablen, die möglicherweise von A verändert werden
→ hier muss ein φ-Knoten eingefügt werden, um schwache
Aktualisierung zu repräsentieren
• May-Use (A):
Menge von Variablen, die möglicherweise von A verwendet werden
→ bei allen Verwendungen müssen Verweise auf Definition
eingetragen werden
N.B.: May-Set und Must-Set sind disjunkt.

Probleme beim Aufbau von SSA
1 a := 1 ;
2 b := 2 ;
3 c := a + b ;
128 / 437
Was ist der Wert von c?

Probleme beim Aufbau von SSA
Definition
Aliasing: Zwei Namen sind Aliase, wenn sie auf überlappende
Speicherbereiche verweisen.
1 y := 5 ;
2
3 i f . . . then
4 x := 6 ;
5 end i f ;
6 . . .
7 . . . = y ;
1 y := 5 ;
2
3 i f . . . then
4 x := 6 ; −− i f I s A l i a s ( x , y ) then y := x ; end i f ;
5 end i f ;
6 . . .
7 . . . = y ;
1 y := 5 ;
2
3 i f . . . then
4 x := 6 ; −− i f I s A l i a s ( x , y ) then y := x ; end i f ;
5 end i f ;
6 . Problem: . . y := φ( y , y ) ;
7 . x . .:= = ...;– y ; falls Alias(x,y), dann ist Zuweisung an x auch Zuweisung an
y
1 1 := 5 ;
2
3 i f . . . then
4 x 1 := 6 ; −− i f I s A l i a s ( x , y ) then y 2 := x 1 ; end i f ;
5 end i f ;
6 . . . y 3 := φ( y 1 , y 2 ) ;
7 . . . = y 3 ;
129 / 437

Aliasing-Varianten
parameter-induziertes Aliasing durch Referenzparameter
p (x, x) (bzw. p(&x, &x) in C und C++)
p (g), wobei g eine globalere Variable ist und in p verwendet
wird
Arraykomponenten
a [2 * i] und a [ j ]
130 / 437
• parameter-induziertes Aliasing durch Referenzparameter
– Lösung: Propagierung der Alias-Info über den Call-Graphen
– (Ansonsten konservative Annahme: zwei Referenzparameter
bzw. globale Variable/Referenzparameter sind Aliase; eventuell
kann Typinformation helfen)
• Arraykomponenten
– Lösungsansatz: Löse Gleichung 2*i = j
– Ansonsten: Modelliere Zuweisungen an Teilkomponente als
Zuweisung an gesamtes Array: Partial Update/Read m.a.W.
konservative Annahme, dass jeder Index sich auf alle
Array-Elemente beziehen kann.

Aliasing-Varianten
stack-gerichtete Zeiger
p := &x;
heap-gerichtete Zeiger
p := new T; q := new T; q.next = p;
131 / 437
• stack-gerichtete Zeiger
– Lösungsansatz: Points-To-Analyse
– Konservative Annahme: *p könnte jede statische Variable
betreffen, deren Adresse genommen wird.
• heap-gerichtete Zeiger
– Lösungsansatz: ”
Shape-Analyse“
– Konservative Annahme: *p kann jedes Element des Heaps
betreffen.

Probleme beim Aufbau von SSA
Aufrufe von Unterprogrammen (Staiger u. a. 2007b, a)
1 x := 1 ;
2 f ( a , b ) ;
3 −− hat x noch den Wert 1?
132 / 437
Welchen äußeren Effekt haben Unterprogrammaufrufe?
• Lösung: Globale Analysen auf Seiteneffekte (aber: Problem von
Bibliotheksroutinen, deren Quell-Code nicht vorhanden ist)
• Ansonsten konservative Annahme: Aufruf eines Unterprogramms U
verändert alle globalen Variablen (nicht nur jene im
Sichtbarkeitsbereich von U) sowie jeden Referenzparameter
• optimistische Annahme: . . . verändert nur seine Referenzparameter
und über sie erreichbare Variable

Phasenspezifische Analysen (Abstraktionsebenen) I
Programmtext mit Makros
Suche nach Zeichenketten (einschließlich Makros)
Programmtext nach Makro-Expansion
Suche nach Zeichenketten (ohne Makros)
Token-Strom
Zeichenketten sind klassifiziert
Suche nach Tokens
abstrakter Syntaxbaum
gibt syntaktische Dekomposition wieder
Suche nach syntaktischen Mustern; evtl. auch spezialisierte
Attributberechnungen
133 / 437
Phasenspezifische Analysen (Abstraktionsebenen) II
attributierter abstrakter Syntaxbaum
Namensbindung und Typinformation verfügbar
Cross-Reference-Information
Suche nach spezifischen Variablen möglich
Kontroll- und Datenflussinformation
Kontrollflussgraph
Aufrufgraph
explizit
Aufrufe über Funktionszeiger
Explizite Darstellung von Datenabhängigkeiten
Alias-Information
Points-To-Information
134 / 437

Wiederholungs- und Vertiefungsfragen I
Warum normalisiert gcc viele Anweisungen des Quellcodes?
Warum sind diese Art Modifikationen für RE nicht
wünschenswert?
Wie kann man Quellennähe erreichen?
Was ist ein abstrakter Syntaxbaum?
Gegeben ist die folgende Grammatik. . . Geben Sie hierfür eine
abstrakte Syntax an.
Wie erreicht man sowohl Quellennähe als auch
Vereinheitlichung?
Selbe Frage mit konkretem Beispiel für Case-Anweisung in der
Programmiersprachen Ada mittels if-Anweisung.
Funktioniert die Umsetzung analog für C-Switch?
Abstrakter Syntaxbaum gibt nur syntaktische Dekomposition
wieder. Wie kann Kontrollfluss explizit dargestellt werden?
135 / 437
Wiederholungs- und Vertiefungsfragen II
Wie ergibt sich Kontrollabhängigkeit aus dem Flussgraphen
(grob skizziert)?
Lässt sich Kontrollflussabhängigkeit auch direkt aus der
Syntax ermitteln?
Wie können Datenabhängigkeiten explizit repräsentiert
werden? Datenabhängigkeitskanten (SSA)
Welche Eigenschaft hat die SSA?
Wie wird diese Eigenschaft erreicht?
Wo werden φ-Knoten eingefügt?
Welche weiteren Datenabhängigkeiten gibt es?
Warum sind diese Abhängigkeiten für das RE überhaupt
interessant?
Wo werden Set / Use und Kontrollabhängigkeiten im RE noch
benutzt?
136 / 437

Literatur
Muchnick (1997): gutes Lehrbuch zu Compilerbau
Morgan (1998): Zwischendarstellungen sowie Kontroll- und
Datenflussanalysen; enthält eine bessere Beschreibung der
SSA als Muchnick (1997)
Koschke u. a. (1998): Zwischendarstellung für das Reverse
Engineering und dessen spezielle Anforderungen
Plödereder (2008): Folien, Skript und Übungen zur Vorlesung
Programmanalysen und Compilerbau an der Universität
Stuttgart
Staiger u. a. (2007b, a): interprozedurale SSA-Form
137 / 437
Dynamische Analyse I
Dynamische Analyse
Probleme statischer Analysen
Information durch dynamische Analyse
Testfälle
Instrumentierung
Instrumentierung mit Aspect/J
Probleme der Instrumentierung
Weiterverarbeitung dynamischer Information
Anwendungsbeispiele
Vergleich mit statischer Analyse
Wiederholungsfragen
138 / 437

Probleme statischer Analysen
Bisher: statische Analyse
Aliasing
Polymorphismus und dynamisches Binden
Reflection
verteilte Systeme
Laufzeitinstanzen versus statischer Einheiten (z.B. Klassen)
→ viele Entscheidungen erst zur Laufzeit
→ statische Analyse problematisch
139 / 437
statisch = ruhend, unbeweglich – bezieht sich hier auf den Quellcode.
Dieser ändert sich nicht während der Analyse.
dynamisch = ändert sich – hier ändert sich der Zustand des Programms
(d.h. des Arbeitsspeichers etc.) mit jeder ausgeführten Anweisung.
Aliasing: mehrere Zeiger auf das gleiche Objekt. Problem: Erst zur
Laufzeit ist wirklich bekannt, auf welches Objekt der Zeiger konkret zeigt.
Polymorphismus: auch hier entscheidet sich erst zur Laufzeit durch den
Typ des Objekts, welche Methode konkret aufgerufen wird.
Reflection is the ability of a running program to examine itself and its
software environment, and to change what it does depending on what it
finds.
Verteiltes System: Menge interagierender Prozesse ohne gemeinsamen
Speicher, d.h. mit Kommunikation untereinander.

Dynamische Analyse
Definition
Dynamische Analyse: Analyse der Eigenschaften eines laufenden
Programms.
Ablauf:
1 Ausführen des Programms
2 Beobachtung der Ausführung
3 Analyse der Ergebnisse
Notwendig:
1 Wahl der Testfälle
2 Instrumentierung oder Interpretation
3 Analysemethoden/-werkzeuge
140 / 437
Eine dynamische Analyse hat jeder schon verwendet: Testen. Auch dabei
wird das Programm ausgeführt, das Verhalten des Programms während
der Ausführung beobachtet und aus den Beobachtungen Rückschlüsse
gezogen (ist die Spezifikation erfüllt oder nicht?).
Auch beim Testen ist die Wahl der Testfälle entscheidend: Möglichst alle
Teile des Programms sollen in allen Varianten mindestens einmal
ausgeführt worden sein. Eine hohe Testabdeckung ist also
wünschenswert. Genauso ist es bei den meisten dynamischen Analysen.
Für weitergehende Analysen ist in der Regel ein Blick in den inneren
Zustand des Programms notwendig. Daher müssen Vorkehrungen
getroffen werden, um diesen Zustand zugreifbar zu machen. Zum Beispiel
müssen evtl. Variablenwerte ausgegeben oder das Passieren bestimmter
Punkte erfasst werden. Dazu ist eine Instrumentierung notwendig.

Was messen/beobachten?
Beobachtung der Ausführung / Messen
Codeabdeckung oder Häufigkeit
Anweisungen, Zweige, Pfade, Aufrufe, . . .
berechnete Werte
Laufzeit, Speicherverbrauch
Reihenfolge von Operationen
. . .
141 / 437
Heisenbergsche Unschärfe bei der Beobachtung
Problem
Messung ändert Verhalten
142 / 437

Wahl der Testfälle
Testsuite bestimmt
Kosten (Zeit und Raum)
Genauigkeit (was wird nie ausgeführt)
Problem
Vollständige Testabdeckung im Allgemeinen nicht zu erreichen.
143 / 437
Vollständige Testabdeckung ist im Allgemeinen nicht erreichbar, sobald
ein Programm Schleifen enthält, die beliebig oft durchlaufen werden
können. Dann müsste es unendlich viele Testfälle geben.

Instrumentierung
Source code
Parser
Analyzer
Intermediate
representation
Preprocessor
cpp
Transformation
Source code
Unparser
Intermediate
representation
Compiler
gprof
Object code
Byte code
BCEL
Soot
Libs
Linker
VM Execution
JDI
Executable
Instrumented artefact
VM Execution
Valgrind
gdb/mi
Instrumenting instance
144 / 437
gprof Gnu Profiler der GNU Compiler Collection (gcc)
BCEL Byte Code Engineering Library zur Analyse und
Transformation von Java-Byte-Code
Soot Framework zur Analyse und Transformation von
Java-Byte-Code
JDI Java Debugger Interface
Valgrind : Werkzeugkasten für Debugging und Profiling von
Linux-Programmen
gdb/mi zeilenbasierte, maschinenorientierte und textuelle
Schnittstelle zu gdb, dem Debugger der GNU Compiler
Collection (gcc)

Instrumentierung
Performanz?
Debug-Schnittstelle i.d.R. langsam
Profiler schnell
Aufwand?
Profile-, Coverage-Information umsonst
automatisierbar?
Bezug zum Quellcode?
schwierig bei Maschinencode
unabhängig von Compiler/Prozessor?
Unabhängig von Programmiersprache?
145 / 437
Instrumentierung mit Aspect/J
1 p u b l i c a s p e c t A c c e s s L o g g e r {
2
3 p r o t e c t e d s t a t i c P r i n t S t r e a m stream = System . out ;
4
5 /∗ ∗
6 ∗ P r i n t s a ” r e a d ” message .
7 ∗/
8 p u b l i c s t a t i c v o i d t r a c e R e a d ( f i n a l S t r i n g s t r ) {
9 stream . p r i n t l n ( ”R ” + s t r ) ;
10 }
11
12 /∗ ∗
13 ∗ P r i n t s a ” w r i t e ” message .
14 ∗/
15 p u b l i c s t a t i c v o i d t r a c e W r i t e ( S t r i n g s t r ) {
16 stream . p r i n t l n ( ”W ” + s t r ) ;
17 }
146 / 437

Instrumentierung mit Aspect/J
1 /∗ ∗ ∗ A p p l i c a t i o n c l a s s e s − E v e v e r t h i n g w i t h i n package s o o t .
∗/
2 p o i n t c u t myClass ( ) : w i t h i n ( s o o t . ∗ ∗ ) ;
3
4 /∗ ∗
5 ∗ Every r e a d
6 ∗/
7 p o i n t c u t myGetter ( ) : myClass ( ) && g e t (∗ ∗ ) ;
8
9 /∗ ∗
10 ∗ Every w r i t e
11 ∗/
12 p o i n t c u t mySetter ( ) : myClass ( ) && s e t (∗ ∗ ) ;
147 / 437
Instrumentierung mit Aspect/J
1 /∗ ∗
2 ∗ P r i n t s t r a c e messages b e f o r e r e a d i n g a f i e l d .
3 ∗/
4 b e f o r e ( ) : myGetter ( ) {
5 t r a c e R e a d ( ” ” + t h i s J o i n P o i n t S t a t i c P a r t . g e t S i g n a t u r e ( ) ) ;
6 }
7
8 /∗ ∗
9 ∗ P r i n t s t r a c e messages b e f o r e w r i t i n g a f i e l d .
10 ∗/
11 b e f o r e ( ) : mySetter ( ) {
12 t r a c e W r i t e ( ” ” + t h i s J o i n P o i n t S t a t i c P a r t . g e t S i g n a t u r e ( ) ) ;
13 }
14 }
148 / 437

Datenmenge
Problem
Häufig zu viele Daten.
Lösungen:
selektive Instrumentierung
sofortige Verarbeitung (online)
Umkodierung
verlustfreie Kompression
Filterung
Vorverarbeitung (Trace Summarization)
149 / 437
Auswertung
Aggregation
Statistiken
Inferenz: Ableitung neuen Wissens
maschinelles Lernen
Visualisierung
je online/offline möglich
150 / 437

Beispiel: Profiling
Ziel: Performance-Engpässe finden
Techniken:
Messen der Zeiten
Zeit vor/nach Ausführung
Mitzählen, Summieren
PC Sampling
% cumulative self self total
time seconds seconds calls ms/call ms/call name
33.34 0.02 0.02 7208 0.00 0.00 open
16.67 0.03 0.01 244 0.04 0.12 offtime
16.67 0.04 0.01 8 1.25 1.25 memccpy
16.67 0.05 0.01 7 1.43 1.43 write
...
151 / 437
PC sampling: in festen Zeitintervallen (z.B. alle 10ms) wird ermittelt,
worauf gerade der Programmzähler (PC) zeigt. Der Zähler für die
entsprechende Anweisung (oder die Funktion, zu der die Anweisung
gehört) wird um eins erhöht. Dies wird über den gesamten Programmlauf
wiederholt. Funktionen, in denen sehr viel Zeit verbracht wurde, haben
damit am Ende einen hohen Zählerstand und können somit als
Performance-kritisch identifiziert werden.
Vorteil: wesentlich geringerer Overhead als beim Merken der Zeiten bei
jedem Funktionseintritt/-austritt.

Beispiel: Dynamisches Slicing (Agrawal und Horgan 1990)
a = 5;
if (x) {
a++;
}
print(a);
Statisches Slicing: Erreichbarkeit im
System-Dependency-Graph
Dynamisches Slicing: Verfolgen von Werten zur Laufzeit
152 / 437
Zur Laufzeit ist immer bekannt, ob x true oder false war, d.h. ob bei
print a=5 oder a=6 ist.
Jeder Wert wird annotiert:
• wo wurde er berechnet?
• aus welchen Werten?
Dann: Rückwärtsverfolgung der Verweise

Beispiel: Collaborations (Richner und Ducasse 2002)
Aufzeichnen von Methodenaufrufen
Aufrufer, Aufgerufener (Klasse,
Instanz), Methode
Pattern-Matching
Suchen ähnlicher Muster
Klassen, Instanzen, Methoden,
Struktur
Auswahl über Klassen/Methoden
Collaboration Browser
Object A
methodCall()
return
Object B
Visualisierung als
Sequenzdiagramm
153 / 437
Beispiel: Invariantenerkennung (Ernst 2000)
public class StackAr {
Object[] theArray;
int topOfStack;
...
}
Invarianten:
theArray != null
theArray.getClass() == java.lang.Object[].class
topOfStack >= -1
topOfStack

Beispiel: Invariantenerkennung (Ernst 2000)
Betrachtung aller Variablen
auch abgeleitete Variablen
sum, min, max
first, second, last
s[i], s[i-1], Teilsequenzen s[0..i], s[0..i-1]
Anzahl Aufrufe einer Funktion
Instanziierung und Testen aller potentiellen Invarianten
Filterung der übrigen Invarianten
hinreichend signifikant?
155 / 437
Object Process Graph (Quante und Koschke 2006)
void main () {
int i = 0;
Stack s1 = new Stack();
Stack s2 = Stack.read();
reverse(s2, s1);
do {
s1.pop();
i = i + 1;
} while (!s1.empty());
}
void reverse(Stack from,
Stack to) {
while (!from.empty())
to.push(from.pop());
}
main
i=0
s1 = new S()
s2 = S.read()
call
s1.pop()
i = i+1
s1.empty()
F
T
reverse
from.empty()
T
F
from.pop()
to.push()
156 / 437

• Rekonstruktion des Kontrollflussgraphen
• Projektion auf ein Objekt
• Instrumentierung von
– Verzweigungen
– Routinenaufrufen
– Operationen auf Objekt
Beispiel: Dynamic Object Process Graph
select()
Call irc_io
Call connect_to_server
read()
main loop
select()
Call
do_server
Call irc_do_a_screen
Call
connect
Call
dgets
fcntl()
Call
login_to_server
Call
p_channel
Call
send_line
setsockopt()
socket()
Start
send()
Call
parse_command
Final
close()
fcntl()
Call
irc_exit
send_to_server
and its call sites
command dispatching
through function pointers
157 / 437

Statische Analyse von Programmverhalten
Analyse des Codes
Modell des Programmzustands erstellen
Mögliches Verhalten folgern
abstrakte Ausführung
Abstrakte Ausführung:
meist Datenflussanalyse
Transferfunktion für jede Anweisung
Änderung des abstrakten Zustands?
Beispiel: y = x++;
158 / 437
Wahl der abstrakten Domäne
Domäne: {even, odd, either}
y = x++;
y = x++;
Domäne: {prime, nonprime, anything}
y = x++;
Domäne: Menge von möglichen nat. Zahlen
y = x++;
Domäne: symbolische Auswertung
y = x++;
159 / 437

Wahl der abstrakten Domäne
Abstraktion bestimmt
Kosten (Zeit und Raum)
Genauigkeit (Informationsverlust)
160 / 437
Statisch vs. Dynamisch
Statisch
abstrakte Domäne
aufwändig wenn genau
konservativ
wegen Abstraktion
vollständig (plus mehr)
da konservativ
begrenzte Sichtweite
eher lokal
Abstraktion bestimmt
Kosten, Genauigkeit
Dynamisch
konkrete Ausführung
kann aufwändig sein
präzise
keine Abstraktion
unvollständig
nicht verallgemeinerbar
kann entfernte Beziehungen
aufdecken
Testsuite bestimmt
Kosten, Genauigkeit
161 / 437

Statisch vs. Dynamisch
x = input();
y = f(x);
if (y < 0)
y = -y;
statisch
dynamisch
wirklich
dynamisch: zu konkret, nicht
verallgemeinerbar → Teilmenge
statisch: zu abstrakt, daher
ungenau → Obermenge
y ∈ {0, 2, 7, 79}
0 ≤ y ≤ MAX INT
Wahrheit liegt (meist) dazwischen 0 ≤ y ≤ 100
162 / 437
Kombination
dynamisch → statisch: Übergeneralisierung erkennen
statisch → dynamisch: gezielte Instrumentierung
163 / 437

Beispiele – Übersicht
Anwendung dynamisch statisch
Typprüfung × ×
Speicherzugriffsprüfung × ×
Slicing × ×
Merkmalsuche × ×
Protokollerkennung × ×
Protokollverifikation × ×
Metriken Verhalten Struktur
- Profiling × —
- Testabdeckung × —
Finden toten Codes — ×
Klonerkennung — ×
Zeigeranalyse leicht schwierig
164 / 437
Wiederholungs- und Vertiefungsfragen I
Nennen Sie Vor- und Nachteile dynamischer Analyse
gegenüber statischer Analyse
Was kann durch dynamische Analyse alles erfasst werden?
Wie kann dynamische Analyse durchgeführt werden?
Welche Probleme hat die Instrumentierung?
Nennen Sie Beispiele für Anwendungen dynamischer Analyse.
165 / 437

Program Slicing I
Program Slicing
Das tägliche Brot des Wartungsprogrammierers
Was ist ein Slice?
Slicing-Technik
Intraprozedurales Slicing
Interprozedurales Slicing
Summary-Edges im SDG
Slicing-Varianten
Anwendungen von Slicing
Wiederholungsfragen
166 / 437
Program Slicing
Lernziele
Verständnis von Slicing-Varianten einschließlich ihrer
Berechnung und Anwendbarkeit
Kontext
Erste unmittelbare Anwendung von Compilerbau-Technologie
zur Unterstützung des Programmverstehens
Program Slicing ist Basis-Technologie für viele weitere
Reengineering-Techniken
168 / 437

Das tägliche Brot des Wartungsprogrammierers
1 r e a d ( n ) ;
2 i := 1 ;
3 sum := 0 ; −− Was b e e i n f l u s s t d i e s e Anweisung ?
4 p r o d u c t := 1 ;
5 w h i l e i

Wie kommt es zu diesem Wert?
Backward Slice (write (product)):
1 r e a d ( n ) ;
2 i := 1 ;
3 sum := 0;
4 p r o d u c t := 1 ;
5 w h i l e i

Was wird durch diese Answeisung beeinflust?
Forward Slice (sum := 0):
1 read (n);
2 i:= 1;
3 sum := 0; −− Was b e e i n f l u s s t d i e s e Anweisung ?
4 product := 1;
5 w h i l e i

Slicing-Technik
Idee und erste Technik des Slicings stammt von Weiser (1984).
Moderne Slicing-Techniken basieren auf Abhängigkeitsgraphen
Program Dependency Graph (PDG) (Ottenstein und
Ottenstein 1984) für intraprozedurales Slicing
System Dependency Graph (SDG) für interprozedurales Slicing
(Horwitz u. a. 1990)
PDG-basiertes Slicing:
Kanten A → B im PDG: B ist daten- bzw. kontrollabhängig
von A
Forward Slicing: Graph-Traversierung in Richtung der
Kontroll- und Datenabhängigkeitskanten
Backward Slicing: Graph-Traversierung in umgekehrter
Richtung der Kontroll- und Datenabhängigkeitskanten
175 / 437
Program Dependency Graph (PDG) nach Ottenstein und
Ottenstein (1984)
PDG = gerichteter Multigraph für Daten- und
Kontrollflussabhängigkeiten.
Knoten repräsentieren Zuweisungen und Prädikate
zusätzlich einen speziellen Entry-Knoten
zusätzlich φ-Knoten zur Reduktion der
Datenabhängigkeitskanten
(sowie einen Initial-Definition-Knoten für jede Variable, die
benutzt werden kann, bevor sie gesetzt wird)
Control-Kanten repräsentieren Kontrollabhängigkeiten
Startknoten jeder Kontrollabhängigkeitskante ist entweder der
Entry-Knoten oder ein Prädikatsknoten
Flow-Kanten repräsentieren Set-Use-Abhängigkeiten
177 / 437

Program Slicing mit PDG
Kontrolleinfluss
Set−Use
entry
read(n )
i := 1
sum := 0
product := 1
i

Program Slicing mit PDG/SSA
entry
Kontrolleinfluss
read(n )
1
i := 1
1
sum
1:= 0
product := 1
1
i
3

System Dependency Graph (SDG) nach Horwitz u. a.
(1990)
PDG stellt Abhängigkeiten innerhalb einer Funktion dar
System Dependency Graph (SDG) stellt globale
Abhängigkeiten dar:
PDGs für verschiedene Unterprogramme werden vernetzt über
interprozedurale Kontroll- und Datenflusskanten
Aufruf: Call-Knoten
aktuelle Parameter: actual-in / actual-out-Knoten
(copy-in/copy-out-Parameterübergabe vorausgesetzt)
formale Parameter: formal-in / formal-out-Knoten
transitive Abhängigkeiten via PDG: Summary-Edges
183 / 437
Modellierung von Prozeduraufrufen
1 Add ( x , y ) ⇔
2
3 a in := x 0 ;
4 b in := y 0 ;
5 Add ;
6 x 1 := a out ;
7 y 1 := b out ;
a in := x 0
call Add
1 p r o c e d u r e Add
2 ( x : i n out I n t e g e r ;
3 y : i n out I n t e g e r ) i s ⇔
4
x 1 := a out
5 p r o c e d u r e Add i s
6 b e g i n
7 a 0 := a in ; b 0 := b in ;
8 . . .
9 a out := a 1 ; b out := b 1 ;
10 end A ;
y 1 := b out
b in := y 0
184 / 437
Entry Add
a 0 := a in
b 0 := b in
a out := a 1bout
:= b 0

Naives Slicing: Folge allen Flow- und Control-Kanten
sum 0 := initialState(sum)
i 0 := initialState(i)
sum 1 := 0
i 1 := 1
Entry Main
while i 3 < 11
call A
FinalUse(sum 3 )
FinalUse(i 3 )
i 3 := φ(i 1 , i 2 )
sum 3 := φ(sum 1 , sum 2 )
x in := sum 3 y in := i 3 sum 2 := x out i 2 := y out
Entry A
x 0 := x in y out := y 2
y 0 := y in
x out := x 1
call Add
call inc
y
a in := x 1 := b out
0
z in := y 1
y 2 := z out
x 1 := a out
Entry Add
Entry inc
one 0 := 1
z 0 := z in
a 0 := a in a z out := z 1
out := a 1bout call Add
b 0 := b in := b 0
one 1 := b out
a 1 := a 0 + b 0 a in := z 0 b in := one 0 z 1 := a out
b in := y 0
185 / 437
Problem: Formale in-Parameter können mehrere Vorgänger haben,
formale out-Parameter mehrere Nachfolger.

Summary-Edges
Summary-Edges sind spezielle Flow-Kanten und beschreiben die
Abhängigkeit der aktuellen out-Parameter von den aktuellen
in-Parametern im Aufrufkontext.
a in := x 0
call Add
x 1 := a out
y 1 := b out
b in := y 0
186 / 437
Entry Add
a 0 := a in a out := a 1bout
b 0 := b in := b 0
a 1 := a 0 + b 0
sum 0 := initialState(sum)
i 0 := initialState(i)
sum 1 := 0
i 1 := 1
Entry Main
while i 3 < 11
call A
FinalUse(sum 3 )
FinalUse(i 3 )
i 3 := φ(i 1 , i 2 )
sum 3 := φ(sum 1 , sum 2 )
x in := sum 3 y in := i 3 sum 2 := x out i 2 := y out
Entry A
x 0 := x in y out := y 2
y 0 := y in
x out := x 1
call Add
call inc
y
a in := x 1 := b out
0
z in := y 1
y 2 := z out
x 1 := a out
Entry Add
Entry inc
one 0 := 1
z 0 := z in
a 0 := a in a z out := z 1
out := a 1bout call Add
b 0 := b in := b 0
one 1 := b out
a 1 := a 0 + b 0 a in := z 0 b in := one 0 z 1 := a out
b in := y 0
187 / 437

Interprozedurales Slicing (Traversierung)
Backward-Slicing (Prozedur P, Statement S):
Phase 1: Folge rückwärts Parameter-In-Kanten, Control- und
Flow-Kanten (inklusive Summary-Kanten) ausgehend von S.
Identifiziert Knoten in Prozeduren, die P (transitiv) aufrufen
und von denen S abhängt.
Da Parameter-Out-Edges ausgenommen sind, werden nur
aufrufende Prozeduren besucht.
Die Effekte nicht-besuchter Prozeduren werden aber nicht
ignoriert, da Summary-Edges traversiert werden.
188 / 437
Interprozedurales Slicing (Traversierung)
Backward-Slicing (Prozedur P, Statement S):
Phase 2: Folge rückwärts Parameter-Out-Kanten, Control- und
Flow-Kanten (inklusive Summary-Kanten) ausgehend von allen
Knoten, die in Phase 1 identifiziert wurden.
Identifiziert Knoten in Prozeduren, die von P (transitiv)
aufgerufen werden und von denen S abhängt.
Da Parameter-In-Edges ausgenommen sind, werden nur
aufgerufene Prozeduren besucht.
Es gilt wieder: Die Effekte nicht-besuchter Prozeduren werden
nicht ignoriert, da Summary-Edges traversiert werden.
190 / 437

Forward-Slicing ist analog zum Backward-Slicing mit dem folgenden
Unterschied:
• Phase 1 folgt vorwärts Control-und Flow-Kanten einschließlich von
Parameter-Out-Kanten, aber nicht Parameter-In-Kanten
• Phase 2 folgt vorwärts Control-und Flow-Kanten einschließlich von
Parameter-In-Kanten, aber nicht Parameter-Out-Kanten
Summary-Edges
repräsentieren (transitive) Abhängigkeiten der aktuellen Inund
Out-Parameter an einer gegebenen Aufrufstelle
helfen während des Slicings, unnötige Abstiege in aufgerufene
Prozeduren zu vermeiden
werden in zwei Schritten ermittelt:
direkte Abhängigkeiten zwischen den formalen Parametern
innerhalb der aufrufenden Prozedur
indirekte Abhängigkeiten, die sich transitiv durch Aufruf
anderer Prozeduren ergeben
werden hergeleitet mit bekannten Techniken zu
Abhängigkeiten in Attributgrammatiken.
191 / 437

Herleitung von Summary-Edges (1)
(1) Für jedes Unterprogramm UP:
Ermittle alle transitiven Abhängigkeiten zwischen formalen
Parameter-Knoten innerhalb des PDGs von UP (liefert
intraprozedural induzierte Abhängigkeiten).
Für jede eingefügte Kante (a, b) zwischen Parametern von UP
füge eine unmarkierte Summary-Edge zwischen a und b ein.
192 / 437
Herleitung von Summary-Edges (2)
(2) Solange eine unmarkierte Summary-Edge (a, b) eines
Unterprogramms UP existiert:
Markiere (a, b)
Für jeden Aufruf von UP innerhalb eines Unterprogramms
UP’:
Füge eine Kante zwischen den zu a und b korrespondierenden
aktuellen Parametern in UP’ ein.
Bilde die transitive Hülle in UP’ (liefert interprozedural
induzierte Abhängigkeiten).
Für jede eingefügte Kante (a’, b’) zwischen aktuellen
Parametern in UP’ füge eine unmarkierte Summary Edge
zwischen a’ und b’ ein, sofern sie noch nicht existiert.
194 / 437

Slicing-Variante: Chopping (Jackson und Rollins 1994)
Abhängigkeiten zwischen zwei Punkten
1 read (n);
2 i:= 1;
3 sum := 0;
4 product := 1;
5 w h i l e i

Slicing-Variante: Amorphes Slicing (Harmann u. a. 2003)
−− O r i g i n a l −− g e s t a l t e r h a l t e n d e s S l i c e
i f p = q then i f p = q then
x := 1 8 ; x := 18;
e l s e
e l s e
x := 1 7 ; x := 1 7 ;
end i f ; end i f ;
i f p /= q then i f p /= q then
y := x ; y := x ;
e l s e
e l s e
y:= 2 ; y:= 2 ;
end i f ; end i f ;
put (y);
put (y);
196 / 437
In diesem Beispiel wird ein besonders intelligentes Slicing durchgeführt,
das auch noch die Prädikate auswertet. Die Zuweisung y := x im
Originalprogramm findet nur statt, wenn p=q gilt. Wenn aber p=q gilt,
dann findet die Zuweisung x := 18 nicht statt und kann deshalb
vernachlässigt werden.
Die Berücksichtigung von Prädikaten für Slicing ist nicht spezifisch für
amorphes Slicing. Zumindest für einfache Fälle könnte man das auch
beim Slicing, wie wir es bisher kennen gelernt haben, einbauen.

Slicing-Variante: Amorphes Slicing (Harmann u. a. 2003)
−− O r i g i n a l −− T r a n s f o r m a t i o n −− amorphes S l i c e
i f p = q then i f p = q then i f p = q then
x := 1 8 ; x := 1 8 ; y := 2 ; x := 18; y := 2 ;
e l s e e l s e e l s e
x := 1 7 ; x := 1 7 ; x := 17;
end i f ; y := x ; y := 17 y := x ;
i f p /= q then end i f ; end i f ;
y := x ;
e l s e
y:= 2 ;
end i f ;
put (y); put (y); put (y);
197 / 437
Amorphes Slicing ist die Kombination von Slicing mit automatischen
Code-Transformationen, die zum Ziel haben, das resultierende Slice zu
vereinfachen. Die Transformationen können vor dem Slicing durchgeführt
werden oder hinterher. In diesem Beispiel findet die Transformation
vorher statt.
Eine Analyse hat erkannt, dass man das Originalprogramm, wie in der
zweiten Spalte gezeigt, vereinfachen kann (wieder auf Grund der Analyse
der Prädikate der beiden aufeinander folgenden Bedingungen).
Anschließend wird das transformierte Programm ”
gesliced“. Die
Zuweisung x := 18 fällt wie vorher heraus. Die Zuweisung x := 17 ist
relevant und gehört eigentlich zum Slice. Allerdings kann man in diesem
Falle eine weitere Code-Transformation durchführen. Die so genannte
Konstantenpropagierung ersetzt alle Variablen, die als konstant erkannt
wurden, mit ihrem konstanten Wert. Die Zuweisung der Konstante kann
dann entfallen.
In diesem Beispiel finden also Code-Transformation vor und nach dem
Slicing statt.

Slicing-Varianten
Backward-/Forward-Slicing, Chopping
ausführbare Slices/nicht-ausführbare Slices
statisches/dynamisches Slicing
gestalterhaltendes (syntax-preserving)/amorphes Slicing
amorph: Slicing mit vereinfachender Transformation
198 / 437
Anwendungen von Slicing
Programmverstehen
Reduzierung des Codes auf das für das Verständnis notwendige
Maß
Änderungsanalyse
alle von einer Änderung betroffenen Stellen
Regressionstesten
Reduktion des zu testenden Codes
Restrukturierung
z.B. Aufteilung von Unterprogrammen, die mehrere logisch
verschiedene Funktionen implementieren Bewertung der
Änderbarkeit (und somit der Wartbarkeit) eines Systems
Messung von Kohäsion
200 / 437

Software-Metriken I
Metriken
Softwaremetriken
Größenmetriken
Komplexitätsmetriken
Kopplung und Kohäsion
Objektorientierte Metriken
Einsatz von Metriken
Grenzen von Metriken
Zielorientiertes Messen
Wiederholungsfragen
202 / 437
Fragen
Wie lassen sich Bad Smells mit Metriken finden?
Wie lassen sich Wartbarkeitsaspekte
quantifizieren?
203 / 437

Software-Metrik
Definition
Metric: A quantitative measure of the degree to which a system,
component, or process possesses a given variable.
– IEEE Standard Glossary
204 / 437
Klassifikation nach Fenton und Pfleeger (1996)
Software−Metriken
Prozess−Metriken
Produkt−Metriken
Ressourcen−Metriken
intern
extern
Größe
Länge
Funktionalität
Komplexität
Struktur
Kontrollfluss
Datenfluss, Modularität
OO−Metriken
Datenstrukturen
205 / 437

Prozessmetriken - intern: Zeit, Aufwand, Anzahl gef. Fehler, . . .
Prozessmetriken - extern: Qualität, Kosten, Stabilität, . . .
Ressourcenmetriken - intern: Personal (Alter, Lohn),
Teamgröße/-struktur, Hardwareausstattung, Büroeinrichtung, . . .
Ressourcenmetriken - extern: Produktivität, Erfahrung, . . .
Produktmetriken - extern: Verläßlichkeit, Verständlichkeit,
Benutzerfreundlichkeit, Wartbarkeit, . . .
Metriken
Halstead
NOC DIT
?
LOC NOP
WMC
SLOC
LCOM
CBO
NOM
RFC
NCO
Fan−In
Fan−Out
McCabe
Extended
McCabe
. . . und alle möglichen Kombinationen, z.B. NOC/Package als
High-level Structuring
Messen kann man viel. Aber wie findet man das Angemessene?
206 / 437

Größenmetriken:
• LOC - Lines of Code
• SLOC - Source Lines of Code (ohne Leerzeilen/Kommentare)
• Halstead - Größe unabhängig von Layout
• McCabe - Anzahl der Bedingungen + 1
• Extended - Wie McCabe aber mit Zählung von Operanden von and
und or
• NOP - Number of Packages
• NOC - Number of Classes
• NOM - Number of Methods
Kopplungsmetriken
• Fan-In: Anzahl eingehender Abhängigkeiten
• Fan-Out: Anzahl ausgehender Abhängigkeiten
OO-Metriken (Chidamber 1994; Chidamber und Kemerer 1994):
• WMC - weighted methods per class
Größenmetriken – LOC
• DIT - depth of inheritance tree
• NOC - number of children
• CBO - coupling between objects (uses, used-by)
• RFC - response for a class (#own + #called methods)
Lines • LCOM of code - lack (LOC) of cohesion in methods
+ relativ einfach messbar
+ starke Korrelation mit anderen Maßen
– ignoriert Komplexität von Anweisungen und Strukturen
– schlecht vergleichbar
207 / 437

Größenmetriken – LOC
int main(int argc, char **argv) {
printf("Hello World."); }
208 / 437
Größenmetriken – LOC
/*
* This program prints the message
* "Hello World." to stdout.
*/
int main(int argc,
char **argv)
{
}
printf("Hello World.");
209 / 437

Wie wird gezählt?
• Leerzeilen
• Kommentare
• Daten
• mehrere Anweisungen pro Zeile
• generierter Code
• lange Header usw.
⇒ Leerzeilen und Kommentarzeilen bei LOC nicht mitzählen, dafür
Kommentarzeilen CLOC einzeln zählen; dann kann z.B. die
Kommentardichte ermittelt werden als CLOC/LOC.
Nützlich zum Vergleichen von Projektgrößen, Produktivität, Entwicklung
der Projektgröße, Zusammenhang mit Anzahl Fehler
Zählen per Modul, per Funktion, . . .
Größenmetriken – LOC
/*
* This function should be documented.
*
* Author:
* Date created:
* Date modified:
* Version:
*
*/
int main(int argc, char **argv)
{
printf("Hello World.");
}
210 / 437

Größenmetriken – Halstead
Halstead (1977)
Länge N = N 1 + N 2
Vokabular µ = µ 1 + µ 2
Volumen V = N · log 2 µ
Program Level L est = (2/µ 1 ) · (µ 2 /N 2 )
Programmieraufwand E est = V /L est
mit µ 1 , µ 2 = Anzahl unterschiedlicher Operatoren, Operanden
N 1 , N 2 = Gesamtzahl verwendeter Operatoren, Operanden
+ komplexe Ausdrücke und viele Variablen berücksichtigt
– Ablaufstrukturen unberücksichtigt
211 / 437
Operanden = Variablen, Konstanten, Literale
Operatoren = Aktionen, bzw. alles andere außer Daten (+, *, while, for,
. . . )
Program Level = Größe der minimalen Implementierung / Größe der
tatsächlichen Implementierung
abgeleitete Halstead-Metriken umstritten.
Halstead: Zeitaufwand T = E / 18 Sekunden

i n t i , j , t ;
i f ( n < 2 ) r e t u r n ;
f o r ( i = 0 ; i < n−1; i ++ ) {
f o r ( j = i + 1 ; j < n ; j ++ ) {
i f ( a [ i ] > a [ j ] ) {
t = a [ i ] ;
a [ i ] = a [ j ] ;
a [ j ] = t ;
}
}
}
< = > - , ; ( ) [ ] { } + ++ for if int return
3 5 1 1 2 9 4 4 6 6 3 3 1 2 2 2 1 1
0 1 2 a i j n t
1 2 1 6 8 7 3 3
µ 1 = 18, µ 2 = 8, N 1 = 56, N 2 = 31
⇒ V = N · log 2 (µ) = 87 · log 2 (26)
212 / 437
Wie werden Operanden + Operatoren definiert?
z.B. Operator = Token, Operand = Literal und Bezeichner

Größenmetriken – weitere
weitere:
Anzahl Module
Anzahl Operatoren, Operanden, Schlüsselworte
Anzahl Parameter
Anzahl/Umfang von Klonen
durchschnittliche Länge von Bezeichnern
. . .
213 / 437
Strukturmetriken
Eigenschaften des Kontrollflussgraphen
Eigenschaften des Aufrufgraphen (Größe, Tiefe, Breite)
Modulkohäsion, Modulkopplung (Abhängigkeiten)
OO-Metriken
Daten, Datenstrukturen
214 / 437

Strukturmetriken – Kontrollflussgraph
Eigenschaften des Kontrollflussgraphen
Anzahl Knoten
Anzahl Kanten
maximale Tiefe
abgeleitete Maße
215 / 437
Komplexitätsmetriken – McCabe
Zyklomatische Komplexität nach McCabe
(1976): maximale Anzahl unabhängiger
zyklischer Pfade in stark verbundenen
Graphen.
V (G) = #Kanten − #Knoten +1 a
oder einfacher:
V (g) = #Binärverzweigungen +1
+ einfach zu berechnen
– Komplexität von Anweisungen
unberücksichtigt
a Kontrollflussgraphen werden erst zu stark verbundenen Graphen durch eine
künstliche Kante von Exit zu Entry → #Kanten = tatsächliche Kanten + 1
216 / 437

Zyklomatische Komplexität: maximale Anzahl unabhängiger zyklischer
Pfade in stark verbundenen Graphen (strongly connected graphs).
Stark verbundener Graph: Jeder Knoten ist von jedem anderen Knoten
erreichbar.
Wir nehmen an, jede Kante hat eine eindeutige Nummer. Jeder Pfad in
einem Graph mit e Kanten kann durch ein e-Tupel (i 1 , i 2 , . . . , i e )
repräsentiert werden, bei dem der Index i j angibt, wie oft die j-te Kante
im Pfad vorkommt.
Ein Pfad p ist eine Linearkombination von Pfaden p 1 , . . . , p n , wenn es
ganze Zahlen a 1 , . . . , a n gibt, so dass p = ∑ a i p i ist, wobei die Pfade wie
oben kodiert sind.
Eine Menge von Pfaden ist linear unabhängig, wenn kein Pfad eine
lineare Kombination der anderen Pfade in der Menge ist.
Die Basismenge von Zyklen ist die maximal große Menge von linear
unabhängigen Zyklen. Jeder Pfade eines zyklischen Graphen lässt sich als
Linearkombination von Pfaden der Basismenge beschreiben.
Die Basismenge ist nicht notwendigerweise eindeutig. Allerdings ist die
Kardinalität der Menge eindeutig. Sie wird zyklomatische Komplexität
genannt und beträgt: e − n + 1.
Komplexitätsmetriken – McCabe
Kontrollflussgraphen sind keine stark verbundenen Graphen, können
jedoch leicht in einen solchen umgewandelt werden, indem der
Exit-Knoten mit dem Entry-Knoten verbunden wird. Damit erhöht sich
dieiAnzahl n t i , der j , Kanten t ; um eins, so dass die zyklomatische Komplexität
e −i n f + ( 2n beträgt. < 2 ) r e t u r n ;
f o r ( i = 0 ; i < n−1; i ++ ) {
f o r ( j = i + 1 ; j < n ; j ++ ) {
i f ( a [ i ] > a [ j ] ) {
t = a [ i ] ;
a [ i ] = a [ j ] ;
a [ j ] = t ;
}
}
}
217 / 437

V (g) = 4 + 1 = 5
McCabe-Beispiele
c a s e A i s
when ’A ’ => i := 1 ;
when ’B ’ => i := 2 ;
when ’C ’ => i := 3 ;
when ’D ’ => i := 4 ;
when ’E ’ => i := 5 ;
end c a s e ;
S : a r r a y ( 1 . . 5 ) o f C h a r a c t e r := ( ’A ’ , ’B ’ , ’C ’ , ’D ’ , ’E ’ ) ;
i := 1 ;
l o o p
e x i t when S ( i ) = A ;
i := i + 1 ;
end l o o p ;
o = new . . . ;
. . .
o . mymethod ( ) ; // Verzweigung
218 / 437

Strukturmetriken – Kopplung und Kohäsion
starke Kopplung
schwache Kohäsion
schwache Kopplung
starke Kohäsion
219 / 437
Strukturmetriken – OO
OO-Metriken (Chidamber 1994; Chidamber und Kemerer 1994):
WMC - weighted methods per class
DIT - depth of inheritance tree
NOC - number of children
CBO - coupling between objects (uses, used-by)
RFC - response for a class (#own + #called methods)
LCOM - lack of cohesion in methods
Metriken pro Klasse
220 / 437

WMC: Anzahl Klassenmethoden, optional gewichtet nach Größe oder
Komplexität
DIT: Länge des Weges von der Wurzel bis zur Klasse (tiefe Hierarchie ist
fehleranfällig)
NOC: Anzahl direkter Unterklassen, hohe Zahl ist Indikator für gute
Wiederverwendung
CBO: Anzahl Klassen, mit denen eine Klasse gekoppelt ist (per uses,
used-by); hoher Kopplungsgrad ist fehleranfällig, niedriger Kopplungsgrad
fördert die Wiederverwendbarkeit
RFC: Anzahl Methoden, die potentiell ausgeführt werden können, wenn
das Objekt auf eine eingehende Nachricht reagiert; RFC = #methods in
the class + #remote methods directly called by methods in the class;
bevorzugt: rekursiv
hoher RFC führt zu mehr Fehlern, deutet auf hohe Komplexität und
schlechte Verständlichkeit hin
LCOM: hoher Wert heißt, Klasse führt mehrere Funktionen aus; deutet
auf schlechtes Design, hohe Komplexität und hohe
Fehlerwahrscheinlichkeit hin; Klasse sollte möglicherweise überarbeitet
werden; niedriger Wert deutet auf gute Kapselung hin
Sei C eine Klasse. Der Zusammenhalt a(m 1 , m 2 ) zweier Methoden, m 1
und m 2 von C sei definiert als die Anzahl der Attribute ihrer Klasse, die
sie zusammen benutzen (lesend oder schreibend). LCOM1 ist dann wie
folgt definiert: LCOM1 = max(|P| − |Q|, 0), wobei P die Menge von
Paaren von Methoden aus C ist, die keine Attribute gemeinsam
benutzen: {(m 1 , m 2 )|m 1 , m 2 ∈ C ∧ a(m 1 , m 2 ) = 0} und Q die Menge von
Paaren von Methoden aus C ist, die mindestens ein Attribut gemeinsam
benutzen: {(m 1 , m 2 )|m 1 , m 2 ∈ C ∧ a(m 1 , m 2 ) > 0}.
LCOM2 = 1 - sum(mA)/(m*a) mit m=#Methoden, a=#Attribute,
mA=#Methoden die Bein Attribut ansprechen A D
LCOM3 = (m-sum(mA)/a)/(m-1)
0 = hohe Kohäsion, 1 = keine Kohäsion, +m1() > 1 = Attribute werden nicht
benutzt
+m2()
Strukturmetriken – OO
C
E
+m3()
+m4()
F
G
H I J
221 / 437

CBO(A) = 4
RFC(A) = 4, RFC(B) = 0, RFC(C) = 1
LCOM
M2
M1
M3
A2
A3
M9
A1
A4
M4
M8
A6
A5
M7
M6
M5
A
Attribut
M
Methode
Referenz
222 / 437

Einsatz von Metriken
Regelbasiertes Qualitätsmodell
Benchmarking
Visualisierung
einer Version
zeitlicher Verlauf
Vorhersage von Qualitätseigenschaften
223 / 437
Regelbasierte Qualitätsmodelle
Beispiel
Gottklasse
benutzt viele Attribute anderer Klassen
hohe funktionale Komplexität
geringe Kohärenz (innerer Zusammenhalt)
Metriken (Lanza und Marinescu 2006):
Access to Foreign Data (ATFD): Anzahl von Attributen
anderer Klassen, die direkt oder mittels Zugriffsmethoden
verwendet werden
Weighted Methods per Class (WMC): gewichtete Anzahl von
Methoden
Tight Class Cohesion (TCC): relative Anzahl von
Methodenpaaren einer Klasse, die gemeinsam auf mindestens
ein Attribut derselben Klasse zugreifen
224 / 437

Regelbasierte Qualitätsmodelle
Feste Schwellwerte:
ATFD > 5 ∧ WMC ≥ 800 ∧ 0 ≤ TCC ≤ 8
Relative und feste Schwellwerte:
ATFD > few ∧ WMC ≥ very high ∧ TCC ∈ P 30 (TCC)
very high = (AVG + STDEV ) × 1.5
few = 5
Perzentil P n (f ) = Menge der ersten n % Prozent der
Elemente, die nach Werten von f geordnet sind
225 / 437
30-Perzentil P 30
Anzahl
20
25
5
10
30 %
15
10
5 5 5
f
226 / 437

Benchmarking: Code Quality Index (Simon u. a. 2006)
Aufwand
Bauchgefühl
Code−Quality−
Index
manuelles
Review
Objektivität, Genauigkeit
Quality-Benchmark-Level auf Basis eines statisch ermittelten,
objektiven Code-Quality-Index:
52 Qualitätsindikatoren (Typen von Bad Smells)
Häufigkeitsverteilung für mehr als 120 industrielle Systeme
geschrieben in C++ und Java → ”
Industriestandard“
227 / 437
Visualisierung von Metriken (Lanza 2003)
Kombination von Metriken und
Software-Visualisierung
Graph-Repräsentation
Bis zu fünf Metriken
bestimmen die Visualisierung
der Knoten:
Größe (1+2)
Farbe/Farbton (3)
Position (4+5)
Element
X-Koordinate Relation
Y-Koordinate
Farbton Höhe
Breite
228 / 437

Polymetrische Sichten
229 / 437
Polymetrische Sichten über die Zeit
Definition
Pulsar: wiederholte Änderungen, die Element größer und kleiner
werden lassen.
→ System-Hotspot: Jede neue Version verlangt Anpassungen.
230 / 437

Polymetrische Sichten über die Zeit
Definition
Supernova: Plötzlicher Anstieg. Mögliche Gründe:
massive Restrukturierung
Datenspeicher für Daten, die plötzlich hinzugekommen sind
Schläfer: Stumpf, der mit Funktionalität gefüllt wird
231 / 437
Trend-Analyse: Kommentierung
232 / 437

Visualisierung: Cockpits
233 / 437
Qualitätseigenschaften: 1. Lernen
...
McCabe
LOC
Halstead
...
20
100
40
...
25
200
86
...
45
180
22
...
29
100
33
...
22
77
11
...
13
222
87
...
...
...
...
...
19
85
22
...
Fehler ja ja nein nein ja nein ... ja
Lernverfahren
20 ≤ McCabe ≤ 25
Modell
LOC ≥ 100
McCabe > 25
∨ McCabe < 20
LOC < 100
50 % 86 % 32 % 20 %
25 % 50 %
40 % 50 %
234 / 437

Qualitätseigenschaften: 2. Vorhersage
A B C D E F G H I
McCabe
LOC
Halstead
...
20
130
44
...
30
210
55
...
24
230
15
...
44
110
45
...
12
88
13
...
67
95
44
...
23
35
56
...
87
35
44
...
33
95
22
...
20 ≤ McCabe ≤ 25
Modell
LOC ≥ 100
McCabe > 25
∨ McCabe < 20
Fehlerwahr−
scheinlichkeit
LOC < 100
50 % 20 % 40 % 80 % 23 % 57 % 60 % 90 % 45 %
90 % 80 % 60 % 57 % 50 % 45 % 40 % 23 % 20 %
H D G F A I C E B
50 % 86 % 32 % 20 %
25 % 50 %
40 % 50 %
235 / 437
Vorhersage von Qualitätseigenschaften: Beispiele
Studie von Ostrand u. a. (2005):
Metriken bewerten Module
die ersten 20 % der Dateien der Bewertungsordnung enthalten
80 % der Fehler
die ersten 20 % der Dateien der Bewertungsordnung enthalten
70 % des Codes
Studie von Mende und Koschke (2009):
simple Ordnung nach Größe liefert vergleichbar gute
Ergebnisse
Studie von El Emam u. a. (2001):
OO-Metriken können Fehler vorhersagen
OO-Metriken, die auf LOC normalisiert werden, können Fehler
nicht vorhersagen
→ Bewertung muss Test- und Fehlerfolgekosten einbeziehen
(Mende und Koschke 2010)
236 / 437

Komplexitätsmetriken – McCabe
Empirische Untersuchungen über Zusammenhang zyklomatische
Komplexität (ZK) und Wartungsaufwand:
(Fenton und Ohlsson 2000): Korrelation von Fehlern und ZK
vor Release (nicht jedoch nach Release)
(Grady 1994): Korrelation von Änderungshäufigkeit und ZK;
schlägt ZK ≤ 15 als Qualitätsziel vor
237 / 437
SEI-Kategorisierung
Cyclomatic Complexity Risk Evaluation
1-10 a simple program, without much risk
11-20 more complex, moderate risk
21-50 complex, high risk program
> 50 untestable program (very high risk)
http:
//www.sei.cmu.edu/str/descriptions/cyclomatic_body.html
Einsatz z.B. bei Qualitätssicherung für Software des Zugtunnels
England-Frankreich schreibt für Prozeduren ZK ≤ 20 und LOC ≤
50 vor (Bennett 1994).
238 / 437

Empirische Studien
Maintainability Index (Coleman/Oman, 1994):
MI 1 = 171 − 5.2 · ln(V ) − 0.23 · V (g ′ ) − 16.2 · ln(LOC)
MI 2 = MI 1 + 50 · sin √ 2.46 · perCM
V = average Halstead Volume per module
V (g ′ ) = average extended cyclomatic complexity per module
LOC = average LOC per module
perCM = average percent of lines of comment per module
MI 2 nur bei sinnvoller Kommentierung
MI < 65 ⇒ schlechte / MI ≥ 85 ⇒ gute Wartbarkeit
239 / 437
nicht sinnvolle Kommentierung: wenn Kommentare nicht zum Code
passen oder viel Code auskommentiert ist oder große Kommentarblöcke
ohne relevante Informationen vorhanden sind.
Liso (2001): statt konstantem Faktor 2.46 abhängig von
Programmiersprache wählen
Extended Cyclomatic Complexity: zusammengesetzte logische Ausdrücke
werden berücksichtigt, AND und OR erhöhen die ECC jeweils um 1

Empirische Studien
Maintainability model (Muthanna u. a. 2000):
SMI = 125 − 3.989 · FAN − 0.954 · DF − 1.123 · MC
FAN: average number of external calls from the module
DF : total number of outgoing and incoming data flow for the
module
MC: average McCabe for the module
240 / 437
Empirische Studien – OO
Wartbarkeit korreliert mit (Dagpinar und Jahnke 2003)
TNOS - total number of statements
NIM - number of instance methods
FOUT - fan out, number of classes directly used
nicht Vererbungshierarchie
nicht Kohäsion
nicht indirekte Kopplung
nicht Kopplung über used-by Beziehungen
241 / 437

Empirische Studien – OO
Testbarkeit korreliert vor allem mit (Bruntink und van Deursen
2004):
LOCC - lines of code per class
FOUT - fan out, number of classes directly used
RFC - response for class
242 / 437
Vorhersage von Qualitätseigenschaften
es gibt viele Studien über Zusammenhänge von Metriken
(Code, Änderungen, Entwickler, Checkin-Zeitpunkt, . . . ) und
Qualitätseigenschaften
die Untersuchungen haben kein einheitliches Bild geboten
Vorsicht ist bei den Details der Evaluation angebracht
dennoch werden Metriken in der Praxis benutzt (z.B.
Code-Quality-Index, Wartbarkeitssiegel von TÜV/Nord)
243 / 437

Metriken: Grenzen
Metriken sind Information, nicht Wissen
Metriken müssen interpretiert werden
Metriken sind starke Vereinfachungen, Details gehen verloren
jede Metrik kann unterlaufen werden
244 / 437
Metriken richtig einsetzen: Zielorientiertes Messen
GQM (Goal-Question-Metric) nach Basili und Weiss (1984):
Nicht das messen, was einfach zu bekommen ist,
sondern das, was benötigt wird
1 Ziele erfassen.
2 Zur Prüfung der Zielerreichung notwendige Fragen ableiten.
3 Was muss gemessen werden, um diese Fragen zu beantworten?
245 / 437

Zielorientiertes Messen
G
Effektivität der Codierrichtlinien bestimmen
Q
Wer benutzt
den Standard?
Wie ist die
Produktivität
der Programmierer?
Wie ist die Qualität
des Codes?
M
Anteil der
Programmierer, die
Standard benutzen
Aufwand
Code−Größe
Fehler
Erfahrung der Programmierer
mit Standard/Sprache/Umgebung
246 / 437
Freie Tools:
Tool Sprachen Metriken
clc (Perl) C/C++ LOC, Comments, #Statements
cccc C++, Java LOC, McCabe, OO, . . .
Metrics C LOC, Comments, Halstead, McCabe
MAS-C4 C LOC, Comments, Halstead, McCabe,
Nesting, Fan-In/-Out, Data Flow, . . .
JMT Java OO-Metriken
Eclipse Plugins Java LOC, McCabe, OO, . . .
Kommerzielle: z.B. Axivion Bauhaus Suite, McCabeQA, CMT,
TAU/Logiscope, SDMetrics, CodeCheck, Krakatau Metrics, RSM,
Together, . . .

Wiederholungs- und Vertiefungsfragen I
Was ist eine Software-Metrik?
Welche Produktmetriken kennen Sie (für die Größe,
Komplexität und die Struktur)?
247 / 437
Techniken zur Klonerkennung I
Klonerkennung
Hintergrund
Folgen
Übersicht zu den Ansätzen zur Klonerkennung
Lexikalische Verfahren
Syntaxbasierte Verfahren
Metrikbasierte Verfahren
Vergleich von Techniken zur Klonerkennung
Wiederholungsfragen
248 / 437

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
251 / 437
Klonerkennung
Lernziele
Varianten der Klonerkennung (Erkennung duplizierten Codes)
Bezug zu Abstraktionsebenen von Programmdarstellungen
Kontext
Beseitigung von Redundanz auf Codierungsebene
erleichtert nachfolgende Reengineering-Aktivitäten
255 / 437

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)
256 / 437
Klontypen: Typ 1
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 }
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 }
257 / 437

Klontypen: Typ 2
1 r e t u r n TRUE ;
2 }
3
4 /∗ r e a d operand #0 ( a l w a y s p r e s e n t ) ∗/
5
6 thisOp −>op [ 0 ] . t y p e
7 = v a a r g ( ap , a 3 a r g u m e n t t y p e ) ;
8
9 i f ( ( thisOp −>op [ 0 ] . t y p e == oCFLOAT ) | |
10 ( thisOp −>op [ 0 ] . t y p e & 1 6 ) ) // i n d e x e d
11 {
12 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 ) ;
13 thisOp −>op [ 0 ] . v a l . f [1]= v a a r g ( ap , INT32 ) 12 ; thisOp −>op [ 2 ] . v a l . f [1]= v a a r g ( ap , INT32 ) ;
14 }
15 e l s e
16 thisOp −>op [ 0 ] . v a l . l = v a a r g ( ap , INT32 ) 15 ; thisOp −>op [ 2 ] . v a l . l = v a a r g ( ap , INT32 ) ;
17
18 /∗ r e a d operand #1 ( sometimes p r e s e n t ) ∗/
19
20 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 {
13 }
14 e l s e
16 }
17 e l s e
18 thisOp −>op [ 2 ] . t y p e = oNONE ;
258 / 437
Klontypen: Typ 3
1 r e t u r n FALSE ;
2 }
3
4 i f ( ! parse ( ) )
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 fclose( fp ) ;
11
12 i f ( d e b u g f l a g )
13 {
14 p r i n t f ( ” result of parser ” ) ;
15 i f ( ! p r i n t t r e e ( FALSE ) )
16 {
17 p r i n t e r r o r ( s t d o u t , 0 ) ;
18 r e t u r n FALSE ;
19 }
20 }
21
22 i f ( v e r b o s e f l a g | | d e b u g f l a g )
23 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 {
259 / 437

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
. . .
260 / 437

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
. . .
261 / 437
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)
263 / 437

Nächster Abschnitt
Wie können Klone gefunden werden?
264 / 437
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
265 / 437

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ß?
266 / 437
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
95 ... ...
27 124 67 12 42
a a b x y a a b z ...
267 / 437

Dot-Plot:
file2.c file1.c
1
2
3
4
5
6
7
8
9
10
11
12
1
2
3
4
5
6
7
8
file1.c
file2.c
1 2 3 4 5 6 7 8 9 10 11 12 1 2 3 4 5 6 7 8
Wie können Klone gefunden werden?
Vergleich von . . .
Tokens
Type-1/-2-Klone: Suffixbaum für parametrisierte Zeichenketten
pro Zeile (Baker 1995)
Type-3: Zusammenfassung von Typ-1/2-Klonen mit Lücken
(Baker 1995).
pro Token mit Normalisierung des Tokenstroms (Kamiya u. a.
2002)
lexikalische Klone, die vollständig in syntaktischen Einheiten
enthalten sind:
lexikalisches Postprocessing (Higo u. a. 2002)
lexikalisches Preprocessing (Synytskyy u. a. 2003; Cordy u. a.
2004)
268 / 437

Suffixbaum:
a
a b
b
x y a a b $
$
x y a a b $
$
b
x y a a b $
$
x y a a b $
y a a b $
$
Wie können Klone gefunden werden?
Vergleich von . . .
Metriken (Mayrand u. a. 1996; Kontogiannis 1997)
Anweisungen durch Data-Mining-Techniken (Wahler u. a.
2004; Li u. a. 2004)
269 / 437

Wie können Klone gefunden werden?
Vergleich von . . .
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)
seq
if
if
if
+
=
=
id =
=
id =
=
id id
id id
id call
id id
id literal
id id
id id
id
270 / 437
Wie können Klone gefunden werden?
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
272 / 437
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
273 / 437

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
274 / 437
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 ) = $
α0
β0α0α2$
$
β2α0α2$
$
α2$
275 / 437

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
276 / 437
Typ-3-Erkennung
Gefundene P-Matches werden, wenn möglich,
zusammengefasst:
A
A
d
1
B
d 2
B
Modi:
nur wenn d 1 = d 2
wenn max(d 1 , d 2 ) ≤ Θ
277 / 437

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)
278 / 437
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:
if (a > 1) {x = 1;} if (a > 1)
{x = 1;}
gleiche Teilausdrücke:
if (sp > 0) if (sp > 0 && s[sp] != a)
279 / 437

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 :=
=
call :=
left
right
lhs
rhs
left
right
lhs
rhs
a b x y z q t s
280 / 437
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.
281 / 437

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-Klonerkennung: h ignoriert Parameter
Nur Bäume T mit mass(T ) ≥ Θ m werden betrachtet
(mass = Anzahl von Knoten, Θ m = benutzerdefinierter
Schwellwert).
282 / 437
Basis-AST-Matching: Typ-1- und Typ-2-Klone
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 I s E q u a l ( s , t ) 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 ;
283 / 437

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.
284 / 437
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 ;
285 / 437

Erkennung von Typ-3-Klonen (Schritt 3)
Schritt 1 erkennt nur Typ-1- und Typ-2-Klone
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 ;
}
Idee: Väterknoten der als Klone erkannten Teilbäume auf
Ähnlichkeit prüfen
286 / 437
Erkennung von Typ-3-Klonen (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 S i m i l a r i t y ( 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 ;
287 / 437

Ähnlichkeit von Teilbäumen
Similarity(T 1 , T 2 ) =
2 · Same(T 1 , T 2 )
2 · Same(T 1 , T 2 ) + Difference(T 1 , T 2 )
Same(T 1 , T 2 ) = Anzahl der korrespondierenden Knoten in T 1
und T 2 , die gleich sind
Difference(T 1 , T 2 ) = Anzahl der Knoten, in denen sich die
Bäume unterscheiden.
288 / 437
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:
syntaktische Einheiten werden verglichen, statt einzelner
Code-Zeilen
übereinstimmende Teilausdrücke werden erkannt
289 / 437

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.
290 / 437
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
291 / 437

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
292 / 437
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
293 / 437

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
294 / 437
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.
295 / 437

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 2 ) √ Kennzahlen(Code 1 ) =
Code 1 ≈ Code 2 ⇒
Kennzahlen(Code 2 ) √ Kennzahlen(Code 1 ) ≈
Kennzahlen(Code 1 ) = Kennzahlen(Code 2 ) ⇒ Code 1 =
Code 2 ?
Kennzahlen(Code 1 ) ≈ Kennzahlen(Code 2 ) ⇒ Code 1 ≈
Code 2 ???
296 / 437
Vergleich von Klonerkennungstechniken (Bellon 2003;
Bellon u. a. 2007)
Teilnehmer
Matthias Rieger
Brenda S. Baker
Toshihiro Kamiya
Ira D. Baxter
Ettore Merlo
Jens Krinke
Ansatz
Pattern Matching auf Dotplots (textuell)
Suffix-Tree, tokenbasiert (zeilenweise)
Suffix-Tree, tokenbasiert (Einzeltoken)
+ Eingabetransformation
Subtree-Matching im AST
Funktions-Metriken + Token-Vergleich
Program Dependency Graph
297 / 437

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 %
298 / 437
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
299 / 437

• McCreight (1976) stellt einen Algorithmus zur Konstruktion von
Suffix-Bäumen für Zeichenketten vor (als Verbesserung von
Weimers Algorithmus), der lineare Zeit und linearen
Speicheraufwand (relativ zur Länge der Zeichenkette) benötigt.
• 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 darstellt, 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.
300 / 437

Refactorings I
Refactoring
Einführung
Kataloge von Bad Smells
Auswirkungen
Integration in den Entwicklungsprozess
Refactoring
Refactorings von Fowler
Pull-Up Field
Extract Method
Wann durchführen?
Evaluation von Refactorings
Kostenschätzung
Portfolio-Analyse
Bewertung Refactorings
Wiederholungsfragen
301 / 437
Übersicht
was ein Bad Smell ist
wie Bad Smells wahrgenommen werden
welche Kategorien von Bad Smells es gibt
welche Auswirkungen Bad Smells haben
wie Bad Smells automatisiert identifiziert werden können
wie man mit Bad Smells umgehen kann
Kompensation
Refactoring
wie man Bad Smells im Entwicklungsprozess integriert managt
302 / 437

Vertrautheit mit Bad Smells
— Yamashita und Moonen (2013)
303 / 437
Umfrage von Yamashita und Moonen (2013):
73 Teilnehmer aus 29 Ländern (davon 12 aus Indien, 10 aus USA, 8 aus
Pakistan, 8 aus Rumänien, sonst 1-3 aus allen anderen Ländern).
Rollenverteilung:
Rolle
Prozent
Angestellter Entwickler 66
Gruppenleiter 18
Architekt 7
Projektmanager 5
Selbstständiger Entwickler 4
Tester 0
Qualitätsmanager 0

Bad Smells
Definition
Bad Smell (Antipattern): wiederkehrender schlechter
Lösungsansatz für ein bestimmtes Problem.
Bad Smells
Code Bad Smells Architecture Bad Smells Process Bad Smells
− duplizierter Code
− Gottklasse
− Architekturverletzungen
− falsch implementierte
oder unpassende
Entwurfsmuster
− hohe Kopplung
− ...
− Analyse−Paralyse
− Design by Committee
− ...
304 / 437
Besorgnis durch Bad Smells
— Yamashita und Moonen (2013)
305 / 437

Besorgnis durch Bad Smells
— Yamashita und Moonen (2013)
306 / 437
Nützlichkeit des Wissens über Bad Smells
— Yamashita und Moonen (2013)
307 / 437

Kataloge von Bad Smells
Aufbläher, z.B. lange Parameterlisten, lange Methoden, lange
Klassen
Verkapsler, z.B. Nachrichtenkette, Mittelsmann
Entbehrliche, z.B. toter Code, faule Klasse, Datenklasse,
duplizierter Code
OO-Schänder, z.B. temporäres Feld, ausgeschlagenes Erbe,
Switch-Anweisungen, parallele Vererbungshierarchien
Koppler, z.B. Feature-Neid, unangebrachte Vertrautheit
andere, z.B. Kommentare
Brown u. a. (1998); Brown und Malveau (2007); Fowler (2000); Mäntylä u. a.
(2004)
308 / 437
Stink Parade of Bad Smells by Fowler (2000)
duplizierter Code
lange Methoden
große Klassen
lange Parameterlisten
divergente Änderung
eine Klasse wird stets geändert in verschiedener Weise und für
unterschiedliche Gründe
Schrotflinten-Chirurgie (Shotgun Surgery)
kleine Änderungen überall
Feature-Neid
sehr viele Attribute einer anderen Klasse werden für eine
Berechnung benutzt
309 / 437

Stink Parade of Bad Smells by Fowler (2000)
Datenklumpen (Data Clumps)
eine Menge von Datenelementen, die häufig gemeinsam
benutzt werden
z.B. Attribute einer Klasse, Parameter in Methodensignaturen
Fixierung aufs Primitive (Primitive Obsession)
einfache Typen werden nicht als Klasse sondern als primitive
Datentypen deklariert
Switch-Anweisungen
händisches dynamisches Binden
Parallele Vererbungshierarchien
Faule Klassen
Klassen, die nichts Nützliches (mehr) tun
. . .
310 / 437
Relevanz nach Entwickleransicht
Rang Bad Smell Punkte
1. Duplizierter Code 19.53
2. Lange Methode 9.78
3. Unnötige Komplexität 8.32
4. Lange Klasse 7.09
5. Exzessive Verwendung von Literalen 3.04
6. Suboptimales Information-Hiding 2.70
7. Faule Klasse 2.33
8. Feature-Neid 2.33
9. Lange Parameterliste 2.31
10. Toter Code 2.25
11. Schlechte (oder Mangel von guten) Kommentaren 1.50
12. Verwendung veralteter Komponenten 1.50
13. Multiple Verantwortlichkeit 1.20
14. Komplexe Bedingungen 1.12
15. Schlechte Benennung 1.12
— Yamashita und Moonen (2013)
311 / 437

Auswirkung von dupliziertem Code (Klone)
13–27 % aller Klone, deren Bezeichner inkonsistent
umbenannt wurden, sind fehlerhaft
11 % aller Klone mit weitergehenden Inkonsistenzen sind
fehlerhaft
7 % aller Änderungen an identischen Klonen im Laufe der
Evolution sind fehlerhaft
Beseitigung von Fehlern in Klonen oft unvollständig
— Li und Shatnawi (2007); Jürgens u. a. (2009); Göde und Koschke (2011);
Harder und Tiarks (2012)
312 / 437
Auswirkungen von Gottklasse, Schrotflinten-Chirurgie und
anderer
höhere Änderungshäufigkeit
höheres Änderungsvolumen
je größer ein System, desto überproportional häufiger
fehleranfälliger
— Olbrich u. a. (2009); Li und Shatnawi (2007); Khomh u. a. (2012, 2009)
313 / 437

Experimente mit Gottklassen
verschlechtert Folge-Design, insbesondere Einsatz von
Vererbung
erschwert Verständnis
erschwert es, Klassenattributen Domänenkonzepte zuzuordnen
— Deligiannis u. a. (2003, 2004); Bois u. a. (2006)
314 / 437
Auswirkungen von Interaktionen von Bad Smells
Interaktion von Blob und Spaghetti Code verursacht Probleme
(Abbes u. a. 2011)
In Klassen, die Wartungsprobleme bereiten, treten mehrere
Bad Smells zugleich auf (Yamashita und Moonen 2013):
Gottmethode, Gottklasse, Mehrzweckvariable, duplizierter
Code, Feature-Neid
Schrotflinten-Chirurgie, ISP-Verletzung
Datenklasse, Datenklumpen
ausgeschlagenes Erbe, falsch platzierte Klasse
315 / 437

Smell versus Bad Smell
Studie von Jbara u. a. (2012):
Einige Quelltextdateien des Linux-Kernels haben hohe
zyklomatische Komplexität
Aber: Entwickler betrachten sie als unproblematisch
Studie von Ratiu u. a. (2004):
Gottklassen und Datenklassen über die Zeit verfolgt
persistent: von Bad Smell zu mind. 95 % ihrer Lebensdauer
betroffen
stabil: wenig Änderungen
circa 20 % der betroffenen Klassen sind stabil und persistent
circa 30 % der betroffenen Klassen sind instabil und nicht
persistent
Studie von Olbrich u. a. (2010):
Junior-Entwickler kommen mit Gottklassen besser zurecht
→ Nicht alle Smells sind wirklich bad, manche Smells sind
tolerierbar.
Wie unterscheidet man Smells und Bad Smells?
316 / 437
Refactorings
Definition
Refactorings: semantikerhaltende, restrukturierende
Code-Transformationen für objekt-orientierte Programme (zur
Verbesserung der Wartbarkeit).
Beschreibung nach Fowler (2000):
Name
Anwendbarkeit
Motivation
mechanische Schritte (die eigentliche Transformation), die von
Hand ausgeführt werden
Beispiel
Sehr viele dieser Refactorings sind genauso auf prozedurale
Programme anwendbar.
317 / 437

Eine Übersicht über den Stand der Wissenschaft zum Thema Refactoring
wurde von Mens und Tourwé (2004) veröffentlicht.
Refactoring-Prozess
Angestoßen von Änderungswunsch.
Prozess (inkrementell, iterativ):
1 Identifikation eines schlechten Geruchs“ (bad smell)
”
2 Refactoring
3 Compile & Test
4 Eigentliche Änderung
5 Compile & Test
318 / 437

70 Refactorings von Fowler (2000)
Methodenzusammensetzung
z.B. Extraktion von Methoden
Eigenschaften zwischen Klassen bewegen
z.B. Verschiebung von Attributen oder Methoden
Organisation von Daten
z.B. Verbergung von Attributen
Vereinfachung bedingter Ausdrücke
z.B. Zerlegung komplexer Bedingungen
Vereinfachung von Methodenaufrufen
z.B. Separierung von bloßem Zugriff von Manipulation
Generalisierungen
z.B. Attribute oder Methoden in der Hierarchie auf- oder
abwärts bewegen
319 / 437
Beispiel: Pull-Up Field
Gleiches Attribut in Unterklassen wird nach Oberklasse verlegt.
Employee
Employee
− Name
Salesman
Engineer
Salesman
Engineer
− Name
− Name
320 / 437

Motivation für Pull-Up Field nach Fowler (2000)
If subclasses are developed independently, or combined through
”
refactoring, you often find that they duplicate features. In
particular, certain fields can be duplicates. Such fields sometimes
have similar names but not always. The only way to determine
what is going on is to look at the fields and see how they are used
by other methods. If they are being used in a similar way, you can
generalize them.“
Doing this reduces duplication in two ways. It removes the
”
duplicate data declaration and allows you to move from the
subclassses to the superclass behavior that uses the field.“
321 / 437
Mechanics für Pull-Up Fields
1 Inspect all uses of the candidate fields to ensure they are used
in the same way.
2 If the fields do not have the same name, rename the fields so
that they have the name you want to use for the superclass
field.
3 Compile and test.
4 Create a new field in the superclass.
5 If the fields are private, you will need to protect the superclass
field so that the subclasses can refer to it.
6 Delete the subclass fields.
7 Compile and test.
8 Consider using Self Encapsulate Field on the new field.
322 / 437

Extract Method
s t a t i c Order o r d e r ;
s t a t i c c h a r name [ ] ;
v o i d p r i n t O w i n g ( ) {
Enumeration e = e l e m e n t s ( o r d e r ) ;
d o u b l e o u t s t a n d i n g = 0 . 0 ;
}
// p r i n t banner
p r i n t f ( ” ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ \ n” ) ;
p r i n t f ( ” ∗ Customer Owes ∗\ n” ) ;
p r i n t f ( ” ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ \ n” ) ;
// c a l c u l a t e o u t s t a n d i n g
w h i l e ( hasMoreElements ( e ) ) {
Order each = nextElement ( e ) ;
o u t s t a n d i n g += getAmount ( each ) ;
}
// p r i n t d e t a i l s
p r i n t f ( ”name %s \ n” , name ) ;
p r i n t f ( ” amount %s \ n” , o u t s t a n d i n g ) ;
323 / 437
Extract Method: parameterlos
// p r i n t banner
v o i d printBanner() {
p r i n t f ( ” ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ \ n” ) ;
p r i n t f ( ” ∗ Customer Owes ∗\ n” ) ;
p r i n t f ( ” ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ \ n” ) ;
}
v o i d p r i n t O w i n g ( ) {
Enumeration e = e l e m e n t s ( o r d e r ) ;
d o u b l e o u t s t a n d i n g = 0 . 0 ;
}
printBanner ( ) ;
// c a l c u l a t e o u t s t a n d i n g
w h i l e ( hasMoreElements ( e ) ) {
Order each = nextElement ( e ) ;
o u t s t a n d i n g += getAmount ( each ) ;
}
// p r i n t d e t a i l s
p r i n t f ( ”name %s \ n” , name ) ;
p r i n t f ( ” amount %s \ n” , o u t s t a n d i n g ) ;
324 / 437

Extract Method: nur Eingabeparameter
// p r i n t d e t a i l s
v o i d printDetails ( d o u b l e o u t s t a n d i n g ) {
p r i n t f ( ”name %s \ n” , name ) ;
p r i n t f ( ” amount %s \ n” , o u t s t a n d i n g ) ;
}
v o i d p r i n t O w i n g ( ) {
Enumeration e = e l e m e n t s ( o r d e r ) ;
d o u b l e o u t s t a n d i n g = 0 . 0 ;
}
p r i n t B a n n e r ( ) ;
// c a l c u l a t e o u t s t a n d i n g
w h i l e ( hasMoreElements ( e ) ) {
Order each = nextElement ( e ) ;
o u t s t a n d i n g += getAmount ( each ) ;
}
printDetails( o u t s t a n d i n g ) ;
325 / 437
Extract Method: mit Ausgabeparameter
// c a l c u l a t e o u t s t a n d i n g
d o u b l e getOutstanding( Enumeration e , d o u b l e o u t s t a n d i n g ) {
}
w h i l e ( hasMoreElements ( e ) ) {
Order each = nextElement ( e ) ;
o u t s t a n d i n g += getAmount ( each ) ;
}
r e t u r n o u t s t a n d i n g ;
v o i d p r i n t O w i n g ( ) {
Enumeration e = e l e m e n t s ( o r d e r ) ;
d o u b l e o u t s t a n d i n g = 0 . 0 ;
}
p r i n t B a n n e r ( ) ;
o u t s t a n d i n g = getOutstanding( e , o u t s t a n d i n g ) ;
p r i n t D e t a i l s ( o u t s t a n d i n g ) ;
326 / 437

Extract Method: weitere Vereinfachung
// c a l c u l a t e o u t s t a n d i n g
d o u b l e g e t O u t s t a n d i n g ( ) {
Enumeration e = e l e m e n t s ( o r d e r ) ;
d o u b l e o u t s t a n d i n g = 0 . 0 ;
}
w h i l e ( hasMoreElements ( e ) ) {
Order each = nextElement ( e ) ;
o u t s t a n d i n g += getAmount ( each ) ;
}
r e t u r n o u t s t a n d i n g ;
v o i d p r i n t O w i n g ( ) {
p r i n t B a n n e r ( ) ;
p r i n t D e t a i l s ( g e t O u t s t a n d i n g ( ) ) ;
}
327 / 437
Wann sollte man Refactorings durchführen?
Refactorings im Kleinen (lokale Änderungen innerhalb weniger
Module)
Wann immer eine Änderung der betreffenden Code-Stellen
ansteht, die ohne Refactoring schwierig ist.
Wenn sich eine Code-Stelle als fehlerträchtig oder unnötig
kompliziert herausstellt.
Wenn eine Code-Stelle permanent auch für verschiedenartige
Kundenwünsche angepasst werden muss.
Refactorings im Großen/Reengineering (massive Änderungen
innerhalb eines Subsystems oder Änderungen in der Architektur)
Wenn eine substantielle Erweiterung geplant ist.
Wenn das Subsystem mit neuen Subsystemen integriert
werden soll.
Wenn die Wartbarkeit stark gesunken ist.
328 / 437

Wie kann Erfolg von Refactorings gemessen werden?
Eigentlich ganz einfach (sei P das Programm vor dem Refactoring
und P ′ das danach):
1 Man wähle geeigneten Satz von Metriken M.
2 Erfolg = M(P ′ ) > M(P)
Aber:
Was sind geeignete Metriken?
Und wie lässt sich M(P ′ ) schätzen, bevor das Refactoring
durchgeführt wird?
Was wird das Refactoring kosten und wie lange wird es
dauern?
329 / 437
Kostenschätzung
Faktoren
Produkt, z.B.
relative Wartbarkeit
Metriken der Größe (LOC, Function Points)
Aufwand des Testens bzw. bisherige Testüberdeckung (für
Regressionstest)
Anzahl gefundener Fehler (im Test/Feld) und deren Kosten
Ressourcen, z.B.
verfügbare Werkzeugunterstützung
inklusive Aufwand für Anpassung bzw. Entwicklung von
Werkzeugen
Erfahrung des Wartungspersonals
Prozess, z.B.
bisheriger Aufwand für Wartung, idealerweise bezogen auf
einzelne Aktivitäten
330 / 437

Kostenschätzung
Ideal: Aus den oben genannten Faktoren und den früheren Kosten
wird mittels statistischer Analysen ein Kostenmodell entwickelt.
331 / 437
Alternative Kostenschätzung nach Sneed (1995)
Gesamtaufwand = Reengineering-Aufwand + Testaufwand
Komplexität×Größe [loc]
durchschn. Produktivität [loc/pm]
RE-Aufwand [pm] =
über alle
Komponenten
Testaufwand = #Testfälle×Durchschnittsaufwand-pro-Testfall
#Testfälle kann aus zyklomatischer Zahl (McCabe) im Falle
der Zweigüberdeckung abgeleitet werden
Gewichtung bezüglich Testbarkeit, Testunterstützung,
Testumgebung
Erfahrungswert: Testaufwand = n × RE-Aufwand für
1 ≤ n ≤ 3
Annahme: Reengineering wird großteils automatisiert.
332 / 437

Wo beginnen? Portfolio-Analyse
Zwei Aspekte:
relative Wartbarkeit
Geschäftswert = Wert der Software
Bestimmung des Geschäftswerts. . .
durch Marktanalytiker
Marktwert
Beitrag zum Profit
Werbewirksamkeit
. . .
und Softwarearchitekt
hängen andere wichtige Systeme davon ab?
333 / 437
Portfolio-Analyse
Vergebe 100 Prozentpunkte pro Wertaspekt. Summiere (eventuell
mit Gewichtung) die Zeilen für jedes System.
System Markwert Profit Werbewert Bewertung
A 10 10 10 30
B 40 30 20 90
C 10 30 20 60
D 10 10 30 50
E 30 20 20 70
Summe 100 100 100 300
334 / 437

Zu sanierende Systeme
relative
Wart−
barkeit
gut −
ausreichend
D
C
schlecht
sekundäre
Reengineering−
kandidaten
A
primäre
Reengineering−
kandidaten
E
B
miserabel
Aufgabe oder
Wrapping
F
Wrapping oder
Neuentwicklung
niedrig
Geschäftswert
hoch
335 / 437
Bewertung Refactorings
Teilweise gut durch Werkzeuge unterstützt:
Refactoring Browser für Smalltalk
Eclipse/JDT für Java
Eclipse/CDT für C/C++
Ansonsten werden die ”
Mechanics“ von Hand durchgeführt
Die Beurteilung, wann und welches Refactoring angebracht
ist, obliegt dem Menschen.
Hinter ”
Compile & Test“ kann sich viel Arbeit verbergen.
Zum Buch von Fowler (2000):
Beschreibung ist zu informell für eine automatisierte
Transformation, aber zumindest eine gute Checkliste.
Die genauen Vorbedingungen sind nicht ausreichend
angegeben.
336 / 437

Wiederholungs- und Vertiefungsfragen I
Welche Schritte sind beim Refactoring durchzuführen?
Was ist ein Bad Smell? Beispiele?
Wie lassen sich Bad Smells erkennen?
Wie kann man die Reihenfolge der zu sanierenden Systeme
festlegen?
337 / 437
Code-Transformationen I
Codetransformation
Vorteile (halb-)automatischer Transformationen
Definition
Transformationssystem
Schritte
Bestandteile
Implementierung
Eigenschaften
Beispiele konkreter Transformationssysteme
Wiederholungsfragen
338 / 437

Wegweiser
Wie kann man Refactorings automatisieren?
339 / 437
(Halb-)Automatische Transformationen
(halb-)automatisch und beliebig wiederholbar
dokumentarisch
Transformation ist Spezifikation der Änderung
kontrollierbar
Transformationen repräsentieren Implementierungswissen
Vor- und Nachbedingungen der Transformationen sind
explizit; sollten automatisch prüfbar sein
Erhalt der Semantik bei einer Transformation lässt sich u. U.
zeigen
340 / 437

Transformation
Eine Transformation ist eine partielle Funktion t:
t: Spezifikation/Programm ↦→ Spezifikation/Programm
Beispiele: Compiler, YACC, Programmrestrukturierer
Transformationen werden oft als Rewrite-Regeln mit
Pattern-Variablen repräsentiert:
r u l e e l i m i n a t e a d d i t i v e i d e n t i t y
r e p l a c e [ e x p r e s s i o n ]
T [ e x p r e s s i o n ] + 0
by
T
end r u l e
Syntax von TXL; siehe www.txl.ca
341 / 437
Transformationssystem
Ein Transformationssystem ist ein System, das semantisch
wohl-definierte (teil-)mechanisierte Programmmodifikationen
ermöglicht.
Source
Code
Parser
Internal
Representation
Unparser
Source
Code
Viewer
focus
reengineering
specialist
Analyzers
Rewrite
Rules
Tranformation
Engine
analyze
/ transform
/ undo request
end user
342 / 437

Schritte einer Transformation
1 Lokation: Identifikation der Stelle, an der Transformation
angewandt werden soll
1 Mustersuche
2 Lokation durch Benutzer
2 Prüfung der Vorbedingungen der Transformation
3 Anwendung, falls Vorbedingungen erfüllt sind
343 / 437
Vorbedingungen von Transformationen
Die Anwendbarkeit von Transformationen ist oft an Bedingungen
geknüpft:
r u l e e l i m i n a t e a d d i t i v e i d e n t i t y
r e p l a c e [ e x p r e s s i o n ]
T1 [ e x p r e s s i o n ] + T2 [ e x p r e s s i o n ]
where
v a l u e (T2) = 0
by
T1
end r u l e
344 / 437

Umsetzung von Transformationen
Ersetzung wird als Prozedur auf dem abstrakten Syntaxbaum
implementiert:
p r o c e d u r e e l i m i n a t e a d d i t i v e i d e n t i t y ( n : i n out node ) i s
b e g i n
i f t y p e ( n ) = p l u s then −− Mustersuche
i f v a l u e ( n . r i g h t ) = 0 −− Bedingung
then
−− E r s e t z u n g
r e p l a c e c h i l d ( p a r e n t ( n ) , from => n , to => n . l e f t ) ;
n . l e f t . p a r e n t := n . p a r e n t ;
d e l e t e t r e e ( n . r i g h t ) ; d e l e t e ( n ) ;
end i f ;
end i f ;
end ;
345 / 437
Eigenschaften von Transformationen
Bestimmte Eigenschaften müssen bei der Transformation
erhalten bleiben, andere Eigenschaften sollen sich ändern:
Performanz
Strukturiertheit
Änderbarkeit
. . .
In vielen (aber nicht allen) Fällen soll die Semantik erhalten
bleiben.
346 / 437

Semantikerhaltende Transformationen
Formale Betrachtung:
Objekt o hat Attribute und ist definiert in einem Kalkül
grundsätzliche Wahrheiten (Axiome) A
Menge von Inferenzregeln i
die Eigenschaften von Objekt o sind dessen Attribute sowie
alle Fakten, die sich aus den Axiomen und Attributen mittels
Inferenzregeln herleiten lassen
Transformation t ist semantikerhaltend genau dann, wenn
für alle Objekte o gilt:
die Eigenschaften von o bleiben durch die Transformation
erhalten: P(o) ⊆ P(t(o))
P(t(o)) ist konsistent (enthält keine Widersprüche)
(alte Eigenschaften bleiben erhalten, neue dürfen
hinzukommen, es ergeben sich keine Widersprüche)
347 / 437
Semantikerhaltende Transformationen
Die Erhaltung der Semantik ist in der Praxis nur sehr schwer
nachweisbar:
Beweis muss nicht nur die Semantik der Programmiersprache,
sondern auch die aller aufgerufenen Betriebssystemfunktionen
u.Ä. einbeziehen, und ist im Allgemeinen schwierig.
Nach Transformationen stets Regressionstests durchführen!
348 / 437

Beispiel eines Transformationssystems
TXL 1 (Queens University, Canada): generisches
Transformationssystem; ausgeprägt für C, C++, Java, Javascript,
Modula, Object Pascal, XML:
konkreter Syntaxbaum wird generiert
funktionale Programmiersprache mit Transformationsregeln
mit ”
native Patterns“:
automatische Traversierung des konkreten Syntaxbaums und
Anwendung der Transformationen, solange dies möglich ist
1 http://www.txl.ca
349 / 437
TXL
r u l e e l i m i n a t e r e d u n d a n t d e c l a r a t i o n s
r e p l a c e [ r e p e a t s t a t e m e n t ]
v a r X [ i d ] : T [ t y p e s p e c ]
R e s t o f S c o p e [ r e p e a t s t a t e m e n t ]
where not
R e s t o f S c o p e [ r e f e r e n c e s X]
by
R e s t o f S c o p e
end r u l e
f u n c t i o n r e f e r e n c e s X [ i d ]
match ∗ [ i d ] X
end f u n c t i o n
350 / 437

Domain Maintenance System (DMS)
Hersteller: Semantic Designs, Austin, Texas, USA
generisches Transformationssystem
parametrisierbar durch so genannte Domains (Grammatiken)
konkrete Instanzen für C, C++, Java, Cobol, Jovial, . . .
abstrakte Regeln für Parse-Baum
Clone-Doctor 2 erkennt Klone (mit dem Verfahren von Baxter
et al.) und beseitigt sie
2 Eingetragenes Warenzeichen von Semantic Designs
http://www.semdesigns.com
351 / 437
DMS-Beispiel
d e f a u l t base domain Java ;
r u l e merge− i f s ( \ c o n d i t i o n 1 ,
\ c o n d i t i o n 2 ,
\ then−s t a t e m e n t s )
=
” i f ( \ c o n d i t i o n 1 )
i f ( \ c o n d i t i o n 2 )
{ \ then−s t a t e m e n t s } ”
r e w r i t e s to
” i f ( \ c o n d i t i o n 1 && \ c o n d i t i o n 2 )
{ \ then−s t a t e m e n t s } ”
;
352 / 437

Raincode
Hersteller: Raincode 3 , Brüssel, Belgien
unterstützte Sprachen: Ada, APS, C, C++, COBOL, CSP,
Delphi, Ideal, Informix 4GL, Java, Natural, PL/1
Skript-Sprache, um Transformationen zu programmieren
Transformation findet auf dem Text selbst statt
3 http://www.raincode.com
353 / 437
Raincode-Beispiel I
PROCEDURE TERMINATE
VAR v a l u e ;
BEGIN
−− scan a l l nodes
FOR exp IN ROOT. SubNodes DO
−− i f i t i s an e x p r e s s i o n t h a t i s not a s i m p l e l i t e r a l
−− and i t has not been m o d i f i e d y e t
IF exp I S NonCommaExpression
AND exp I S NOT L i t e r a l
AND exp [ ” Patched ”]TRUE THEN
−− do e v a l u a t i o n
v a l u e := E v a l ( exp ) ;
−− i f e v a l u a t i o n s u c c e e d s
IF v a l u e VOID THEN
−− r e p l a c e the e x p r e s s i o n by i t s v a l u e
PATCH. ReplaceNt ( exp , v a l u e ) ;
−− r e p o r t something on c o n s o l e
exp . W r i t e E r r o r ( LIST . T o S t r i n g (PATCH. NtImage ( exp )
| | STR . Trim (X) , ” ” ) , ” = ”&v a l u e ) ;
−− add a n n o t a t i o n so we do not p r o c e s s subnodes
354 / 437

Raincode-Beispiel II
FOR IN exp . SubNodes DO
X . Patched := TRUE;
END;
END;
END;
END;
−− s a v e the p r o c e s s e d s o u r c e
PATCH. Save (ROOT. SourceName&” . patched ” ) ;
END;
355 / 437
Wiederholungs- und Vertiefungsfragen
Welche Vorteile haben semi-automatische Transformationen?
Welche wichtige Eigenschaften sollten Transformationen im
RE haben? Warum?
Was sollte man nach der Durchführung einer Transformation
realistischerweise stets tun?
Aus welchen Bestandteilen besteht eine Transformation?
Wie wird ein Rewrite implementiert, wenn als
Zwischendarstellung ein AST benutzt wird?
356 / 437

Software-Visualisierung I
Software-Visualisierung
Über diese Folien
Lernziele
Reengineering-Kontext
Programm-Visualisierung
Statische Programm-Visualisierung
Graphen mit Metriken
Klassenblaupause
Dynamische Programm-Visualisierung
Evolutionäre Aspekte
Zusammenfassung
Wiederholungsfragen
357 / 437
Über diese Folien
Diese Folien entstammen einer Präsentation von Michele Lanza
(Universität Lugano), mit dessen freundlicher Genehmigung.
Die Unterschiede zum Original sind:
Übersetzung ins Deutsche
Kleinere Restrukturierungen und Verkürzungen
Weitere Visualisierungen hinzugefügt
358 / 437

Lernziele und Kontext
Lernziele
Software-Visualisierung in einem Reengineering-Kontext
Statische Code-Visualisierung
Dynamische Code-Visualisierung
Visualisierung von Metriken
Visualisierung der Evolution
Leichtgewichtige Ansätze
Kontext
Reengineering ist meist interaktiv
Große Datenmengen müssen verstanden werden
359 / 437
Definitionen zu Software-Visualisierung
Software Visualization is the use of the crafts of
typography, graphic design, animation, and
cinematography with modern human-computer
interaction and computer graphics technology to
facilitate both the human understanding and effective use
of computer software.
– Price, Baecker and Small, Introduction to Software Visualization
Software is intangible, having no physical shape or
size. Software visualisation tools use graphical techniques
to make software visible by displaying programs, program
artifacts and program behaviour.
– Thomas Ball
360 / 437

SV im Reengineering-Kontext
Ziele: Reduktion der Komplexität
Herausforderungen:
Skalierbarkeit
Aufgabenabhängigkeit der Visualisierung
Art der Visualisierung
Begrenzte Ressourcen
361 / 437
Programm-Visualisierung
Program visualization is the visualization of the
actual program code or data structures in either static or
dynamic form.
– [Price, Baecker und Small]
Gebiete
Statische Programm-Visualisierung
Dynamische Programm-Visualisierung
Aufgaben
Verschiedene Sichten generieren
Inferenzen ermöglichen
Spezifische Probleme (aktives Forschungsgebiet)
Effiziente Ausnutzung des Platzes, Kantenüberschneidungen,
Layout-Probleme, Fokus, Human-Computer-Interaction, . . .
Keine Konventionen (Farben, Symbole, Interpretation, . . . )
Granularität?
Ganze System, Subsysteme, Module, Klassen, Hierarchien,...
Wofür, wie und wann anzuwenden?
362 / 437

Statische Programm-Visualisierung
Visualisierung von Information, die statisch abgeleitet ist.
Hängt von Sprache und Sprachparadigma ab:
objektorientierte Sprachen: Klassen, Methoden, Attribute,
Vererbung, . . .
prozedurale Sprachen: Prozeduren, Aufrufe, . . .
. . .
Mittel:
Quellcode
Bäume
Graphen
Metaphern
363 / 437
Visualisierung von Code: SeeSoft (Eick u. a. 1992)
364 / 437

Bäume: Klassen-Hierarchien
Jun/OpenGL
Smalltalk
Klassenhierarchie
Probleme:
Keine weitere
Bedeutung der Farbe
Überladen
365 / 437
Bäume
Euklidische Kegel
Vorteile:
Nutzen dritte
Dimension
Nachteile:
Mangelnde Tiefe
Navigation
Hyperbolische Bäume
Vorteile:
Fokus ist wählbar
Dynamisch
Nachteile: Copyright
366 / 437

Bäume mit Metriken: Tree Maps
Vorteile:
hierarchisch (m.E.)
100% Raumnutzung
skaliert
Nachteile:
Grenzen
Wirres Bild
Interpretation
Nur Blätter
367 / 437
Treemap für Klone
368 / 437

Bäume mit Metriken: Tree Maps mit Texturen
– Quelle: Danny Holten http://www.win.tue.nl/˜dholten/
369 / 437
Klassendiagramme
370 / 437

Klassendiagramme
(wie von herkömmlichen CASE-Werkzeugen dargestellt. . . )
Vorteile:
Stellen objektorientierte Konzepte dar
Geeignet für kleine Ausschnitte
Nachteile:
Skalieren nicht
Benötigen Filter für relevante Informationen
Nur voreingestellte Sichten
371 / 437
Klassendiagramme mit visuellen Attributen
– Quelle: Alexandru Telea
http://www.win.tue.nl/˜alext/ARCHIVIEW/
372 / 437

Klassendiagramme mit Soft Shapes
– Quelle: Alexandru Telea
http://www.win.tue.nl/˜alext/ARCHIVIEW/
373 / 437
Allgemeine Graphen: Rigi
Entity-Relationship-
Visualisierung
generische Präsentation
durch typisierte Graphen
Probleme:
Filterung
Navigation
Skalierbarkeit
374 / 437

Allgemeine Graphen: Rigi
Entities können gruppiert
werden
Vorteile:
Skaliert besser
generisch
Nachteile:
Wenig Programmiersprachensemantik
375 / 437
Gebündelte Kanten
– Quelle: Danny Holten http://www.win.tue.nl/˜dholten/
376 / 437

Gebündelte Kanten
– Quelle: Danny Holten http://www.win.tue.nl/˜dholten/
377 / 437
Gebündelte Kanten mit Metriken
378 / 437

Graphen mit Metriken (Lanza 2003; Lanza und Ducasse
2003)
Kombination von Metriken und
Software-Visualisierung
Graph-Repräsentation
Bis zu fünf Metriken
bestimmen die Visualisierung
der Knoten:
Größe (1+2)
Farbe/Farbton (3)
Position (4+5)
Element
X-Koordinate Relation
Y-Koordinate
Farbton Höhe
Breite
379 / 437
System Complexity View
380 / 437

Method Efficiency Correlation View
381 / 437
Inheritance Classification View
382 / 437

Added: Ganz neue Methoden.
Overridden: Ererbt und redefinierte Methoden.
Extended: Overridden + Aufruf der gleichen Methode via super
(Smalltalk), d.h. Aufruf zur entsprechenden Methode, die überschrieben
wurde.
Data Storage Class Detection View
383 / 437

Von links nach rechts nach Breite (Number of Methods) geordnet.
Dieselbe Metrik (Number of Methods) wird hier auf dreifache Weise
dargestellt: Breite, Position innerhalb der Ordnung und Farbe. Dadurch
kann ein verstärkender Effekt erzeugt werden.
Innereien und Abhängigkeiten
384 / 437

Klassenblaupause (Ducasse und Lanza 2005)
385 / 437
Die Einteilung hängt etwas von der Ausdruckskraft der
Programmiersprache ab, auch von dem, was der Benutzer tatsächlich
sehen möchte: aus Sicht der Spezifikation bzw. aus Sicht der
tatsächlichen Verhältnisse.
• Initialization: Kontruktoren (soweit die Programmiersprache sie
explizit darstellt, auch: Methoden, die Init und ähnliche
Zeichenketten im Namen enthalten oder solche, die einen
new-Operator für die Klasse enthalten
• Interface: öffentliche Methoden; auch: solche, die tatsächlich von
außerhalb aufgerufen werden (Accessors sind in einer anderen
Kategorie; siehe unten)
• Implementation: versteckte Methoden bzw. solche, die von
außerhalb nicht benutzt werden
• Accessors: Öffentliche Methoden, die nichts weiter tun als ein
Attribut zu setzen bzw. zu lesen
• Attribute: versteckte Attribute

Semantische Information
Kategorisierung von Klassen
Basiert auf
Klassenblaupausen
Zwei Perspektiven:
Einzelne Klasse
Vererbungskontext
Klassenblaupause
für jede einzelne
Klasse
Sind als Baum
angeordnet
386 / 437

Klassenblaupause: Data Storage
Viele Attribute
Kann viele
Zugriffsoperationen haben
(Accessors)
Harmloses Verhalten
387 / 437
Klassenblaupause: Wide Interface
Viele Methoden in der
Schnittstelle
388 / 437

Klassenblaupause: Large Implementation
Geschachtelte
Aufrufstruktur
Viele Methoden
Hohe Komplexität
Breite Schnittstelle
389 / 437
Metaphorische Visualisierung
– Quelle: Richard Wettel
http://www.inf.usi.ch/phd/wettel/codecity-wof.html
390 / 437

Dynamische Programm-Visualisierung
Visualisierung dynamischen Verhaltens
Ausführungs-Trace
Ressourcenverbrauch (Speicher/Laufzeit)
Objekt-Interaktion
. . .
Schritte:
1 Code-Instrumentierung
2 Gewinnung der Laufzeitinformation
3 Auswertung der Laufzeitinformation
4 Visualisierung der Auswertung
391 / 437
Dynamische SV: Probleme
Code-Instrumentierungsproblem
Logging, erweiterte Virtual Machines, Method-Wrapping
Skalierbarkeitsproblem
Fülle der Details
Traces werden sehr schnell enorm groß
Vollständigkeitsproblem
Information gilt nur für betrachtete Szenarien
392 / 437

Beispiel 1: JInsight
(http://www.research.ibm.com/jinsight)
Visualisierung von Ausführungs-Traces
393 / 437
Visualisiert Sequenzdiagramme; jeder vertikale Streifen repräsentiert ein
Objekt; die Farbe des Streifens kodiert die Klasse. Die Zeit schreitet von
oben nach unten fort. Aufrufe sind durch Kanten zwischen Objekten
dargestellt und haben die aufgerufene Methode als Label. Die zeitlichen
Bereiche, in denen ein Objekt tatsächlich aktiv sind (d.h. nicht nur eine
andere Methode aufrufen, sondern tatsächlich selbst rechnen), sind im
Streifen etwas heller dargestellt.
JInsight erlaubt es auch, wiederkehrende Aufrufmuster automatisch zu
erkennen und darzustellen. Ähnliche, aber leicht unterschiedliche Muster
können dabei übereinandergelegt werden, um so die Unterschiede
darzustellen.

Heatmap
394 / 437
Beispiel 2: Aufrufmatrix für Klassen (Heatmap)
einfach
skaliert
reproduzierbar
395 / 437

Inter-Class Call Matrix: This view provides an overview of the
communication between classes. The matrix plots which classes call
which other classes. Classes are arranged along both axes in the order
they are instantiated. The color of the dots indicate the frequency of that
communication.
Evolutionäre Aspekte
Die Gegenwart ist oft verständlicher, wenn man die
Vergangenheit kennt.
Betrachtung von Aspekten des Systems über die Zeit.
Metrikwerte können besser eingeschätzt werden.
Erlaubt, Trends auszumachen.
396 / 437

Evolutionsmatrix
397 / 437
Kategorisierung von Klassen anhand der Evolutionsmatrix
Dargestellte Metriken für Klassen:
NOM (number of methods)
NOA (number of attributes)
Kategorisierung anhand der ”
individuellen Evolution“ und der
” System-Evolution“:
Pulsar
Supernova
Weißer Zwerg
Roter Riese
Dornröschen
Eintagsfliege
Methusalem
398 / 437

Pulsar
Definition
Pulsar: wiederholte Änderungen, die Element größer und kleiner
werden lassen.
→ System-Hotspot: Jede neue Version verlangt Anpassungen.
399 / 437
Supernova
Definition
Supernova: Plötzlicher Anstieg. Mögliche Gründe:
massive Restrukturierung
Datenspeicher für Daten, die plötzlich hinzugekommen sind
Schläfer: Stumpf, der mit Funktionalität gefüllt wird
400 / 437

Weißer Zwerg, Roter Riese, Dornröschen
401 / 437
Eintagsfliege & Methusalem
402 / 437

Fallstudie MooseFinder (38 Versionen)
403 / 437
Spektrograph
x-Achse: Zeit; y-Achse: Softwareeinheit; Farbe: #commits
404 / 437

Courtesy Jingwei Wu, Richard C. Holt, Ahmed Hassan, University of
Waterloo, Canada
Färbung im Spektrograph
• linearer Gradient
• exponentieller Gradient
• Stufen

Evostreets (Steinbrückner 2013)
405 / 437
Quelle der Bilder: Dr. Frank Steinbrückner

Software-Visualisierung (SV) I
SV ist unabdingbar im Reengineering-Kontext
Match-Mismatch-Hypothese:
problem-solving performance depends on
whether the structure of a problem is matched by
the structure of a notation
– Gilmore und Green
Jede SV betont bestimmte Information und vernachlässigt
andere Information.
Geeignete SV ist abhängig von der zu lösenden Aufgabe.
408 / 437
Software-Visualisierung (SV) II
Alphabetismus“ der SV
”
Wie drücke ich es aus?
Wie interpretiere ich es?
Vieles noch in der Forschung, wenig in kommerziellen
Werkzeugen
Software-Wahrnehmung: Andere menschliche Sinne werden
genutzt
409 / 437

Wiederholungs- und Vertiefungsfragen I
Wofür eignen sich Tree Maps und wie sind sie zu
interpretieren?
Welche Probleme gibt es bei der Visualisierung dynamischer
Daten?
Wie lassen sich Metriken visualisieren?
Was ist eine Klassenblaupause?
Wie lassen sich damit Klassen charakterisieren?
Welche zusätzlichen Aspekte lassen sich durch die
Visualisierung evolutionärer Daten gewinnen?
Was sagt die Match-Mismatch-Hypothese (Gilmore und
Green) aus?
410 / 437
1 Abbes u. a. 2011 Abbes, Marwen ; Khomh, Foutse ;
Guéhéneuc, Yann-Gaël ; Antoniol, Giuliano: An Empirical
Study of the Impact of Two Antipatterns, Blob and Spaghetti
Code, on Program Comprehension. In: Proceedings of the
European Conference on Software Maintenance and
Reengineering, IEEE Computer Society Press, 2011, S. 181–190
2 Agrawal und Horgan 1990 Agrawal, Hiralal ; Horgan,
Joseph R.: Dynamic Program Slicing. In: Proceedings of the
Conference on Programming Language Design and
Implementation, ACM Press, Juni 1990, S. 246–256
3 Arthur 1988 Arthur, L.J.: Software Evolution: The Software
Maintenance Challenge. New York, NY : John Wiley & Sons,
1988
4 Baker 1997 Baker, Brenda: Parameterized duplication in
strings: Algorithms and an application to software maintenance.
26 (1997), Oktober, Nr. 5, S. 1343–1362
411 / 437

5 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.):
Proceedings of the 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
6 Basili und Weiss 1984 Basili, R. ; Weiss, D. M.: A
Methodology for Collecting Valid Software Engineering Data. In:
IEEE Computer Society Transactions on Software Engineering
10 (1984), November, Nr. 6, S. 728–738
7 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
412 / 437
8 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.): Proceedings of the
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
9 Bellon 2003 Bellon, Stefan:
Vergleich von Klonerkennungstechniken. Fakultät Informatik,
Universität Stuttgart, Deutschland, Diplomarbeit, 2003
10 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
11 Bennett 1994 Bennett, P.A.: Software Development for the
Channel Tunnel: a Summary. In: High Integrity Systems 1
(1994), Nr. 2, S. 213–220
413 / 437

12 Boehm 1981 Boehm, Barry: Software Engineering Economics.
Englewood Cliffs, NJ : Prentice Hall, 1981
13 Bois u. a. 2006 Bois, B. D. ; Demeyer, S. ; Verelst, J. ;
Mens, T. ; Temmerman, M.: Does god class decomposition
affect comprehensibility? In: Proceedings of the IASTED
Conference on Software Engineering, IASTED/ACTA Press,
2006, S. 346–355
14 Brown u. a. 1998 Brown, W. J. ; Malveau, R. C. ; Brown,
W. H. ; III, H. W. M. ; Mowbray, T. J.: Anti Patterns:
Refactoring Software, Architectures, and Projects in Crisis. 1st
edition. John Wiley and Sons, März 1998
15 Brown und Malveau 2007 Brown, William J. ; Malveau,
Raphael C.: Anti Patterns: Entwurfsfehler erkennen und
vermeiden. zweite überarbeitete Auflage. Mitp-Verlag, 2007
414 / 437
16 Bruntink und van Deursen 2004 Bruntink, M. ; Deursen,
A. van: Predicting Class Testability Using Object-Oriented
Metrics. In: Proceedings of the IEEE International Workshop on
Source Code Analysis and Manipulation, IEEE Computer Society
Press, September 2004
17 Chidamber 1994 Chidamber, S.: Metrics Suite For Object
Oriented Design, M.I.T, Cambridge, Dissertation, 1994
18 Chidamber und Kemerer 1994 Chidamber, S.R. ;
Kemerer, C.F.: A Metrics Suite for Object-Oriented Design.
In: IEEE Computer Society Transactions on Software
Engineering 20 (1994), Juni, Nr. 6, S. 476–493
19 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
415 / 437

20 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
21 Cordy u. a. 2004 Cordy, James R. ; Dean, Thomas R. ;
Synytskyy, Nikita: Practical language-independent detection
of near-miss clones. In: Proceedings of the Conference of the
Centre for Advanced Studies on Collaborative research, IBM
Press, 2004, S. 1–12
22 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
416 / 437
23 Dagpinar und Jahnke 2003 Dagpinar, M. ; Jahnke, J.:
Predicting Maintainability with Object-Oriented Metrics – An
Empirical Comparison. In: Proceedings of the Working
Conference on Reverse Engineering, IEEE Computer Society
Press, 2003
24 Deligiannis u. a. 2004 Deligiannis, I. ; Shepperd, M. ;
Roumeliotis, M. ; Stamelos, I.: An empirical investigation
of an object-oriented design heuristic for maintainability. In:
Journal of Systems and Software 72 (2004), Nr. 2, S. 129–143
25 Deligiannis u. a. 2003 Deligiannis, Ignatios ; Stamelos,
Ioannis ; Angelis, Lefteris ; Roumeliotis, Manos ;
Shepperd, Martin: Controlled Experiment Investigation of an
Object Oriented Design Heuristic for Maintainability. In: Journal
of Systems and Software 65 (2003), Februar, Nr. 2, S. 127–139
26 Demeyer u. a. 2002 Demeyer, Serge ; Ducasse, Stephane ;
Nierstrasz, Oscar: Object Oriented Reengineering Patterns.
Morgan Kaufmann, 2002
417 / 437

27 Ducasse und Lanza 2005 Ducasse, Stephane ; Lanza,
Michele: The Class Blueprint: Visually Supporting the
Understanding of Classes. In: IEEE Computer Society
Transactions on Software Engineering 31 (2005), Januar, Nr. 1,
S. 75–90
28 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
29 Eick u. a. 1992 Eick, Stephen G. ; Steffen, Joseph L. ;
Sumner, Eric E.: Seesoft—A Tool for Visualizing Line Oriented
Software Statistics. In: IEEE Computer Society Transactions on
Software Engineering 18 (1992), November, S. 957–968
418 / 437
30 El Emam u. a. 2001 El Emam, Kalhed ; Benlarbi, Saïda ;
Goel, Nishith ; Rai, Shesh N.: The Confounding Effect of
Class Size on the Validity of Object-Oriented Metrics. In: IEEE
Computer Society Transactions on Software Engineering 27
(2001), Nr. 7, S. 630–650. – ISSN 0098-5589
31 Ernst 2000 Ernst, Michael: Dynamically Discovering Likely
Program Invariants. Seattle, Washington, USA, University of
Washington, Department of Computer Science and Engineering,
Dissertation, August 2000
32 Fenton und Pfleeger 1996 Fenton, N. ; Pfleeger, S.:
Software Metrics: A Rigorous and Practical Approach. 2nd.
London : International Thomson Computer Press, 1996
33 Fenton und Ohlsson 2000 Fenton, Norman E. ; Ohlsson,
Niclas: Quantitative Analysis of Faults and Failures in a Complex
Software System. In: IEEE Computer Society Transactions on
Software Engineering 26 (2000), August, Nr. 8, S. 797–814
419 / 437

34 Fjeldstad und Hamlen 1979 Fjeldstad, R.K. ; Hamlen,
W.T.: Application Program Maintenance Study: Report to our
Respondents. In: Proceedings of the GUIDE 48. Philadelphia,
PA : The Guide Corporation, 1979
35 Fowler 2000 Fowler, Martin: Refactoring: Improving the
Design of Existing Code. Addison-Wesley, 2000
36 Göde und Koschke 2011 Göde, Nils ; Koschke, Rainer:
Frequency and Risks of Changes to Clones. In: Proceedings of
the International Conference on Software Engineering, ACM
Press, 2011, S. 311–320
37 Grady 1994 Grady, R.B.: Successfully Applying Software
Metrics. In: IEEE Computer 27 (1994), September, Nr. 9,
S. 18–25
38 Halstead 1977 Halstead, Maurice: Elements of Software
Science. Elsevier, 1977
420 / 437
39 Harder und Tiarks 2012 Harder, Jan ; Tiarks, Rebecca: A
Controlled Experiment on Software Clones. In: Proceedings of
the International Conference on Program Comprehension, IEEE
Computer Society Press, 2012, S. 219–228
40 Harmann u. a. 2003 Harmann, Mark ; Binkley, David ;
Danicic, Sebastian: Amorphous Program Slicing. In: Journal of
Systems and Software 68 (2003), Nr. 1, S. 45–63
41 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
42 Horwitz u. a. 1990 Horwitz, Susan ; Reps, Thomas ;
Binkley, David: Interprocedural Slicing Using Dependence
Graphs. In: ACM Transactions on Programming Languages and
Systems 12 (1990), Januar, Nr. 1, S. 26–60
421 / 437

43 Jackson und Rollins 1994 Jackson, D. ; Rollins, E.: A new
model of program dependences for reverse engineering. In: Proc.
Symposium on the Foundations of Software Engineering, 1994
44 Jbara u. a. 2012 Jbara, A. ; Matan, A. ; Feitelson, D. G.:
High-MCC functions in the linux kernel. In: Proceedings of the
International Conference on Program Comprehension, IEEE
Computer Society Press, 2012, S. 83–92
45 Johnson 1993 Johnson, J. H.: Identifying redundancy in
source code using fingerprints. In: Proceedings of the
Conference of the Centre for Advanced Studies on Collaborative
research, IBM Press, 1993, S. 171–183
46 Johnson 1994 Johnson, J. H.: Substring matching for clone
detection and change tracking. In: Proceedings of the
International Conference on Software Maintenance, IEEE
Computer Society Press, 1994, S. 120–126
422 / 437
47 Jürgens u. a. 2009 Jürgens, E. ; Deissenböck, F. ;
Hummel, B. ; Wagner, S.: Do Code Clones Matter? In:
Proceedings of the International Conference on Software
Engineering, ACM Press, 2009, S. 485–495
48 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
49 Khomh u. a. 2009 Khomh, Foutse ; Di Penta,
Massimiliano ; Guéhéneuc, Yann-Gaël: An exploratory study
of the impact of code smells on software change-proneness. In:
Proceedings of the Working Conference on Reverse Engineering,
IEEE Computer Society Press, 2009, S. 75–84
50 Khomh u. a. 2012 Khomh, Foutse ; Di Penta, Massimiliano ;
Guéhéneuc, Yann-Gaël: An exploratory study of the impact of
antipatterns on class change- and fault-proneness. In: Journal
Empirical Software Engineering 17 (2012), Nr. 3, S. 243–275
423 / 437

51 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
52 Kontogiannis 1997 Kontogiannis, K.: Evaluation
Experiments on the Detection of Programming Patterns Using
Software Metrics. In: Proceedings of the Working Conference on
Reverse Engineering, 1997, S. 44–53
53 Koschke u. a. 2006 Koschke, Rainer ; Falke, Raimar ;
Frenzel, Pierre: Clone Detection Using Abstract Syntax Suffix
Trees. In: Proceedings of the Working Conference on Reverse
Engineering, IEEE Computer Society Press, 2006, S. 253–262
54 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 Proceedings of the Working Conference
on Reverse Engineering. Honolulu, HI, USA : IEEE Computer
Society Press, Oktober 1998, S. 241–250
424 / 437
55 Krinke 2001 Krinke, Jens: Identifying Similar Code with
Program Dependence Graphs. In: Proceedings of the Working
Conference on Reverse Engineering, 2001, S. 301–309
56 Krinke 2004 Krinke, Jens: Slicing, Chopping, and Path
Conditions with Barriers. In: Software Quality Journal 12
(2004), Nr. 4, S. 339–360
57 Lanza 2003 Lanza, Michele: Object-Oriented Reverse
Engineering - Coarse-grained, Fine-grained, and Evolutionary
Software Visualization. http://www.inf.unisi.ch/faculty/
lanza/Downloads/Lanz03b.pdf, University of Bern,
Dissertation, 2003
58 Lanza und Ducasse 2003 Lanza, Michele ; Ducasse,
Stephane: Polymetric Views—A Lightweight Visual Approach to
Reverse Engineering. In: IEEE Computer Society Transactions
on Software Engineering 29 (2003), Nr. 9, S. 782–795
425 / 437

59 Lanza und Marinescu 2006 Lanza, Michele ; Marinescu,
Radu: Object-Oriented Metrics in Practice: Using Software
Metrics to Characterize, Evaluate, and Improve the Design of
Object-Oriented Systems. Berlin : Springer, August 2006. –
ISBN ISBN-10: 3540244298, ISBN-13: 978-3540244295
60 Lehman 1980 Lehman, Meir M.: Programs, Life Cycles and
Laws of Program Evolution. In: Proceedings of the IEEE,
Special Issue on Software Evolution 68 (1980), September,
Nr. 9, S. 1060–1076
61 Lehner 1989 Lehner, Franz: Nutzung und Wartung von
Software. Carl Hanser Verlag, 1989
62 Li und Shatnawi 2007 Li, Wei ; Shatnawi, Raed: An
empirical study of the bad smells and class error probability in
the post-release object-oriented system evolution. In: Journal of
Systems and Software 80 (2007), Nr. 7, S. 1120 – 1128. –
Dynamic Resource Management in Distributed Real-Time
Systems. – ISSN 0164-1212
426 / 437
63 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
64 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
65 Lientz und Swanson 1980 Lientz, B.P. ; Swanson, E.B.:
Software Maintenance Management. Reading, MA :
Addison-Wesley, 1980
66 Mäntylä u. a. 2004 Mäntylä, M.V. ; Vanhanen, J. ;
Lassenius, C.: Bad smells - humans as code critics. In:
Proceedings of the International Conference on Software
Maintenance, Sept. 2004, S. 399–408. – ISSN 1063-6773
427 / 437

67 Marcus und Maletic 2001 Marcus, A. ; Maletic, J.I.:
Identification of high-level concept clones in source code. In:
Proceedings of the International Conference on Automated
Software Engineering, 2001, S. 107–114
68 Masak 2006 Masak, Dieter: Legacysoftware: Das lange Leben
der Altsysteme. Springer, 2006
69 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
70 McCabe 1976 McCabe, Thomas J.: A Complexity Measure.
In: IEEE Computer Society Transactions on Software
Engineering 2 (1976), Nr. 4, S. 308–320
71 McCreight 1976 McCreight, E. M.: A space-economical
suffix-tree construction algorithm. In: Journal of the ACM 23
(1976), Nr. 2, S. 262–272
428 / 437
72 Mende und Koschke 2009 Mende, Thilo ; Koschke, Rainer:
Revisiting the Evaluation of Defect Prediction Models. In:
PROMISE ’09: Proceedings of the 5th International Conference
on Predictor Models in Software Engineering. New York, NY,
USA : ACM, 2009, S. 1–10. – ISBN 978-1-60558-634-2
73 Mende und Koschke 2010 Mende, Thilo ; Koschke, Rainer:
Effort-Aware Defect Prediction Models. In: Proceedings of the
European Conference on Software Maintenance and
Reengineering, 2010. – submitted for publication
74 Mens und Tourwé 2004 Mens, Tom ; Tourwé, Tom: A
Survey of Software Refactoring. In: IEEE Computer Society
Transactions on Software Engineering 30 (2004), Februar, Nr. 2,
S. 126–139
75 Moad 1990 Moad, J.: Maintaining the Competitive Edge. In:
DATAMATION, 1990, S. 61–66
429 / 437

76 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: Proceedings of the IEEE
Symposium on Software Metrics, 2002, S. 87–94
77 Morgan 1998 Morgan, Robert: Building an Optimizing
Compiler. Digital Press, 1998
78 Muchnick 1997 Muchnick, Steven S.: Advanced Compiler
Design and Implementation. Morgan Kaufmann, 1997
79 Muthanna u. a. 2000 Muthanna, S. ; Kontogiannis, K. ;
Ponnambalam, K. ; Stacey, B.: A Maintainability Model for
Industrial Software Systems Using Design Level Metrics. In:
Proceedings of the Working Conference on Reverse Engineering,
IEEE Computer Society Press, 2000
80 Müller 1997 Müller, Bernd: Reengineering – Eine
Einführung. B.G. Teubner, 1997
430 / 437
81 Olbrich u. a. 2010 Olbrich, S. M. ; Cruzes, D. S. ;
Sjøberg, D. I. K.: Are all Code Smells Harmful? A Study of
God Classes and Brain Classes in the Evolution of Three Open
Source Systems. In: Proceedings of the International Conference
on Software Maintenance, IEEE Computer Society Press, 2010,
S. 1–10
82 Olbrich u. a. 2009 Olbrich, Steffen ; Cruzes, Daniela S. ;
Basili, Victor ; Zazworka, Nico: The evolution and impact
of code smells: A case study of two open source systems. In:
Proceedings of the Empirical Software Engineering and
Measurement, IEEE Computer Society Press, 2009, S. 390–400
83 Ostrand u. a. 2005 Ostrand, T.J. ; Weyuker, E.J. ; Bell,
R.M.: Predicting the location and number of faults in large
software systems. In: IEEE Computer Society Transactions on
Software Engineering 31 (2005), Nr. 4, S. 340–355. – ISSN
0098-5589
431 / 437

84 Ottenstein und Ottenstein 1984 Ottenstein, Karl J. ;
Ottenstein, Linda M.: The program dependence graph in a
software development environment. In: Proceedings of the ACM
SIGSOFT/SIGPLAN Software Engineering Symposion on
Practical Sofware Development Environments, 1984, S. 177–184
85 Pigoski 1996 Pigoski, Thomas M.: Practical Software
Maintenance: Best Practices for Managing Your Software
Investment. John Wiley & Sons, Inc., 1996
86 Plödereder 2008 Plödereder, Erhard: Vorlesung
Programmanalysen und Compilerbau. Vorlesungsskriptum.
Oktober 2008. – URL
http://www.iste.uni-stuttgart.de/ps/Lehre/WS0809/V_
Programmanalysen/skript-CB+ProgAn-08.pdf
87 Quante und Koschke 2006 Quante, Jochen ; Koschke,
Rainer: Dynamic Object Process Graphs. In: Proceedings of the
Proceedings of the European Conference on Software
Maintenance and Reengineering, IEEE Computer Society Press,
März 2006
432 / 437
88 Rajlich und Bennett 2000 Rajlich, Vaclav T. ; Bennett,
Keith H.: A Staged Model for the Software Life Cycle. In: IEEE
Computer 33 (2000), Nr. 7, S. 66–71
89 Ratiu u. a. 2004 Ratiu, Daniel ; Ducasse, Stéphane ;
Gîrba, Tudor ; Marinescu, Radu: Using History Information
to Improve Design Flaws Detection. In: Proceedings of the
European Conference on Software Maintenance and
Reengineering, IEEE Computer Society Press, 2004, S. 223–232
90 Reps und Rosay 1995 Reps, T. ; Rosay, G.: Precise
Interprocedural Chopping. In: Proc. Symposium on the
Foundations of Software Engineering, 1995
91 Richner und Ducasse 2002 Richner, Tamar ; Ducasse,
Stéphane: Using Dynamic Information for the Iterative Recovery
of Collaborations and Roles. In: Proceedings of the Proceedings
of the International Conference on Software Maintenance.
Montreal, Canada : IEEE Computer Society Press, Oktober
2002, S. 34–43
433 / 437

92 Rieger 2005 Rieger, Matthias: Effective Clone Detection
Without Language Barriers, University of Bern, Switzerland,
Dissertation, 2005
93 Seacord u. a. 2003 Seacord, Robert C. ; Plakosh, Daniel ;
Lewis, Grace A.: Modernizing Legacy Systems.
Addison-Wesley, 2003
94 Simon u. a. 2006 Simon, Frank ; Seng, Olaf ; Mohnhaupt,
Thomas: Code-Quality-Management – Technische Qualität
industrieller Softwaresysteme transparent und vergleichbar
gemacht. dpunkt.verlag, 2006
95 Sneed 1995 Sneed, Harry: Planning the Reengineering of
Legacy Systems. In: IEEE Software (1995), January. –
beschreibt die Planung von Reengineering-Projekten
96 Sneed u. a. 2005 Sneed, Harry M. ; Hasitschka, Martin ;
Teichmann, Maria-Therese: Software-Produktmanagement –
Wartung und Weiterentwicklung bestehender
Anwendungssysteme. dpunkt.verlag, 2005
434 / 437
97 Staiger u. a. 2007a Staiger, Stefan ; Vogel, Gunther ;
Keul, Steffen ; Wiebe, Eduard: Interprocedural Static Single
Assignment Form. In: Proceedings of the Working Conference
on Reverse Engineering, IEEE Computer Society Press, Oktober
2007, S. 1–10. – URL http://ieeexplore.ieee.org/xpl/
freeabs_all.jsp?arnumber=4400146
98 Staiger u. a. 2007b Staiger, Stefan ; Vogel, Gunther ;
Keul, Steffen ; Wiebe, Eduard: Interprocedural Static Single
Assignment Form in Bauhaus / Institut für Softwaretechnologie,
Abteilung Programmiersprachen. Universität Stuttgart,
November 2007. – Forschungsbericht. – URL http:
//elib.uni-stuttgart.de/opus/volltexte/2007/3338/
99 Steinbrückner 2013 Steinbrückner, Frank: Consistent
Software Cities Supporting Comprehension of Evolving Software
Systems, Brandenburgische Technische Universität Cottbus,
Dissertation, 2013
435 / 437

100 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
101 Ukkonen 1995 Ukkonen, E.: On-line construction of suffix
trees. In: Algorithmica 14 (1995), S. 249–260
102 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 IEEE
International Workshop on Source Code Analysis and
Manipulation, 2004, S. 128–135
103 Weiser 1984 Weiser, M.: Program slicing. In: IEEE
Transactions on Software Engineering 10 (1984), Nr. 4,
S. 352–357. – In this paper some properties of slices are
presented. It is shown that the use of data-flow analysis is
sufficient to find approximate slices of the generally unsolvable
problem of finding statement-minimal slices
436 / 437
104 Yamashita und Moonen 2013 Yamashita, A. ; Moonen,
L.: Exploring the impact of inter-smell relations on software
maintainability: An empirical study. In: Proceedings of the
International Conference on Software Engineering, ACM Press,
2013, S. 682–691
105 Yang 1991 Yang, Wuu: Identifying Syntactic Differences
Between Two Programs. In: Software–Practice and Experience
21 (1991), Juli, Nr. 7, S. 739–755
437 / 437