Erweiterung von BugzillaMetrics zur Auswertung von...

127

Transcript of Erweiterung von BugzillaMetrics zur Auswertung von...

Page 1: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

Erweiterung von BugzillaMetrics zurAuswertung von Daten ausVersionskontrollsystemen

Diplomarbeit

Autor: Christoph Lischkowitz

Abgabedatum: 05.12.2008

Gutachter: Prof. Dr. rer. nat. Horst LichterZweitgutachter: Prof. Dr.-Ing. Manfred Nagl

Betreuer: Dipl.-Inform. Holger Schackmann

Erstellt am Lehr- und Forschungsgebiet Informatik 3:Prof. Dr. rer. nat. Horst LichterRWTH Aachen

Page 2: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

2

Hiermit versichere ich, dass ich die Arbeit selbständig verfasst und keine anderenals die angegebenen Hilfsmittel benutzt habe.

Aachen, 5. Dezember 2008

Page 3: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

Inhaltsverzeichnis

1 Einführung 7

1.1 Motivation des Themas . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.2 Übersicht über diese Arbeit . . . . . . . . . . . . . . . . . . . . . . . 8

2 Vorstellung der beteiligten Systeme 9

2.1 Change Request Management-Systeme . . . . . . . . . . . . . . . . . 9

2.1.1 Bugzilla . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.1.2 Mantis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.2 Versionsmanagementsysteme . . . . . . . . . . . . . . . . . . . . . . 10

2.2.1 Concurrent Versions System (CVS) . . . . . . . . . . . . . . . 11

2.2.2 Subversion (SVN) . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2.3 Vergleich von CVS und Subversion . . . . . . . . . . . . . . . 12

2.2.3.1 Gemeinsamkeiten . . . . . . . . . . . . . . . . . . . 12

2.2.3.2 Unterschiede . . . . . . . . . . . . . . . . . . . . . . 12

2.3 SCMBug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.4 BugzillaMetrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.5 Überblick über die beteiligten Systeme . . . . . . . . . . . . . . . . . 18

2.6 Überblick über existierende Ansätze in der Literatur . . . . . . . . . 19

3 Anforderungsanalyse 25

3.1 Grundlegende Anforderungen . . . . . . . . . . . . . . . . . . . . . . 25

3.1.1 Funktionale Anforderungen . . . . . . . . . . . . . . . . . . . 26

3.1.2 Nicht-funktionale Anforderungen . . . . . . . . . . . . . . . . 26

3.2 Funktionsumfang existierender Werkzeuge . . . . . . . . . . . . . . . 26

3.3 Erweiterungen in BugzillaMetrics . . . . . . . . . . . . . . . . . . . . 28

3.3.1 Funktionale Anforderungen . . . . . . . . . . . . . . . . . . . 28

3.3.1.1 BaseFilter . . . . . . . . . . . . . . . . . . . . . . . 29

3.3.1.2 Events . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.3.1.3 Weights . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.3.1.4 E�zienz: Zeitverhalten . . . . . . . . . . . . . . . . 32

3.3.1.5 BugzillaMetrics Frontend . . . . . . . . . . . . . . . 32

3.3.2 Nicht-funktionale Anforderungen . . . . . . . . . . . . . . . . 33

3.4 SCM-Integration von BugzillaMetrics im Kontext der beteiligten Sys-teme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3

Page 4: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

4 INHALTSVERZEICHNIS

4 Datenbankentwurf 354.1 Anforderungsanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.1.1 Begri�snetz . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.2 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.2.1 Datenbankstruktur . . . . . . . . . . . . . . . . . . . . . . . . 38

4.2.1.1 SCM_Revision_Activity_History . . . . . . . . . . 38

4.2.1.2 BranchActivity, TagActivity . . . . . . . . . . . . . 39

4.2.1.3 FileActivity . . . . . . . . . . . . . . . . . . . . . . . 39

4.2.1.4 FolderActivity . . . . . . . . . . . . . . . . . . . . . 40

4.2.1.5 Developer . . . . . . . . . . . . . . . . . . . . . . . . 40

4.2.1.6 SCM_Branch, SCM_Tag . . . . . . . . . . . . . . . 41

4.2.1.7 SCM_Folder . . . . . . . . . . . . . . . . . . . . . . 41

4.2.1.8 SCM_File . . . . . . . . . . . . . . . . . . . . . . . 42

4.3 Verwendung der Datenbank im BugzillaMetrics-Kern . . . . . . . . . 42

5 Test-Framework 455.1 Anforderungsanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.1.1 Test des erweiterten Kerns (Bugzilla-Test) . . . . . . . . . . . 45

5.1.2 Test des Datenimports in die SCM-Datenbank (Import-Test) 45

5.2 Testaufbau aus Benutzersicht . . . . . . . . . . . . . . . . . . . . . . 47

5.2.1 Bugzilla-Test . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

5.2.2 Import-Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

5.3 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

5.3.1 Problembeschreibung . . . . . . . . . . . . . . . . . . . . . . . 50

5.3.2 Designbeschreibung . . . . . . . . . . . . . . . . . . . . . . . 51

5.3.2.1 JUnit Testsuites . . . . . . . . . . . . . . . . . . . . 51

5.3.2.2 JUnit TestCases . . . . . . . . . . . . . . . . . . . . 52

5.3.2.3 Setupaktivitäten . . . . . . . . . . . . . . . . . . . . 54

5.3.3 Aktivitäten zum Ergebnisvergleich . . . . . . . . . . . . . . . 58

5.3.3.1 BugzillaTest: Überprüfung des Metrikergebnisses . . 58

5.3.3.2 ImportTest: Überprüfung des SCM-Datenbankinhalts 58

5.3.4 TearDown-Aktivitäten . . . . . . . . . . . . . . . . . . . . . . 58

5.3.4.1 Beispiel einer Import-Testdurchführung . . . . . . . 59

6 Datenimport 616.1 Anforderungsanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

6.1.1 Funktionale Anforderungen . . . . . . . . . . . . . . . . . . . 61

6.1.1.1 Allgemeine funktionale Anforderungen . . . . . . . . 61

6.1.1.2 Funktionale Anforderungen der SCM-Systeme . . . 62

6.1.2 Nicht-funktionale Anforderungen . . . . . . . . . . . . . . . . 62

6.1.2.1 Allgemeine nicht-funktionale Anforderungen . . . . 62

6.1.2.2 Nicht-funktionale Anforderungen der SCM-Systeme 63

6.1.3 Datenstrukturen der SCM-Ausgaben . . . . . . . . . . . . . . 63

6.1.4 CVSImport-Überblick: . . . . . . . . . . . . . . . . . . . . . . 63

Page 5: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

INHALTSVERZEICHNIS 5

6.1.5 SVNImport - Überblick: . . . . . . . . . . . . . . . . . . . . . 64

6.2 Designbeschreibung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

6.2.1 Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

6.2.2 Allgemeine Datenstruktur für alle SCM-Systeme . . . . . . . 66

6.2.3 Organisation des Imports . . . . . . . . . . . . . . . . . . . . 67

6.2.3.1 CVS-Import . . . . . . . . . . . . . . . . . . . . . . 67

6.2.3.2 SVN-Import . . . . . . . . . . . . . . . . . . . . . . 68

6.2.3.3 Designgründe . . . . . . . . . . . . . . . . . . . . . . 71

6.2.4 Loader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

6.2.4.1 CVS-Loadermodule . . . . . . . . . . . . . . . . . . 73

6.2.4.2 SVN-Loadermodule . . . . . . . . . . . . . . . . . . 74

6.2.4.3 SCMBug-Loadermodul . . . . . . . . . . . . . . . . 74

6.2.5 SCM-Objekte . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

6.2.5.1 Systemspezi�sche Datenobjekte . . . . . . . . . . . 75

6.2.5.2 Systemunabhängige Datenobjekte . . . . . . . . . . 75

6.2.6 Parser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

6.2.7 ScmRepositoryObjectLinker: Referenzen zwischen Ordnern undDateien herstellen . . . . . . . . . . . . . . . . . . . . . . . . 84

6.2.8 ScmEventChecker: Suche nach Aktivitäten in Ordnern undDateien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

6.2.9 AssociationBuilder: Vorbereitungen zum Sichern der Daten indie Datenbank . . . . . . . . . . . . . . . . . . . . . . . . . . 89

6.2.9.1 CvsAssociationBuilder . . . . . . . . . . . . . . . . . 89

6.2.9.2 SvnAssociatonBuilder . . . . . . . . . . . . . . . . . 90

6.2.10 DatabaseVisitor . . . . . . . . . . . . . . . . . . . . . . . . . . 91

6.3 Benutzerschnittstelle des SCM-Imports . . . . . . . . . . . . . . . . . 91

6.4 Einbindung externer Programme . . . . . . . . . . . . . . . . . . . . 91

6.4.1 Problembeschreibung . . . . . . . . . . . . . . . . . . . . . . . 91

6.4.2 Anforderungsanalyse . . . . . . . . . . . . . . . . . . . . . . . 92

6.4.3 Designbeschreibung . . . . . . . . . . . . . . . . . . . . . . . 92

6.4.4 Designgründe . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

7 Erweiterungen im BugzillaMetrics-Kern 95

7.1 Datenrepräsentation . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

7.2 BaseFilter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

7.3 Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

7.3.1 Problembeschreibung . . . . . . . . . . . . . . . . . . . . . . . 97

7.3.2 Designbeschreibung . . . . . . . . . . . . . . . . . . . . . . . 97

7.4 EventFilter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

7.5 DataSources und EventSources . . . . . . . . . . . . . . . . . . . . . 99

7.6 Weights . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

7.6.1 Problembeschreibung . . . . . . . . . . . . . . . . . . . . . . . 101

7.6.2 Designbeschreibung . . . . . . . . . . . . . . . . . . . . . . . 101

7.7 Erweiterung des Frontends, Installation der SCM-Integration . . . . 102

Page 6: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

6 INHALTSVERZEICHNIS

8 Evaluierung 1038.1 Bewertung der Software . . . . . . . . . . . . . . . . . . . . . . . . . 103

8.1.1 Funktionalität . . . . . . . . . . . . . . . . . . . . . . . . . . 103

8.1.2 Zuverlässigkeit . . . . . . . . . . . . . . . . . . . . . . . . . . 104

8.1.3 Verwendbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . 105

8.1.4 E�zienz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

8.1.5 Wartbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

8.1.6 Portabilität . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

8.2 Beispielauswertung verschiedener Importvorgänge . . . . . . . . . . . 110

8.2.1 Ergebnisbewertung . . . . . . . . . . . . . . . . . . . . . . . . 111

8.3 Metrikergebnisse von BugzillaMetrics . . . . . . . . . . . . . . . . . . 113

8.3.1 Bemerkenswerte Eigenheiten der Metrikspezi�kationen . . . . 113

8.3.2 Beispiel eines Metrik-Graphen . . . . . . . . . . . . . . . . . 114

8.4 Einordnung der Arbeit in die Menge anderer Ansätze der Fachliteratur114

8.5 Vergleich der realisierten Funktionen mit denen von StatCVS undEclipse Dash . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

9 Zusammenfassung und Ausblick 117

A Verwendete Software 123

B XML-Elemente zur SCM-Spezi�kation 125B.0.1 Übersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

B.0.2 Beschreibung der Attribute . . . . . . . . . . . . . . . . . . . 126

Page 7: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

Kapitel 1

Einführung

Seit Anfang 2007 wird am Lehr- und Forschungsgebiet Informatik 3 das Software-Entwicklungstool BugzillaMetrics entwickelt. Hiermit können Metrikberechnungenauf Grundlage eines Datenbestandes des Bug-Tracking Systems Bugzilla durchge-führt werden.

Das Thema dieser Diplomarbeit ist es nun, den Datenbestand, auf den Bugzilla-Metrics für Berechnungen zurückgreifen kann, zu erweitern und damit auch dieMöglichkeiten bei der Erstellung von Metrikspezi�kationen zu erweitern.Hierbei wird es nicht darum gehen, den bestehenden Datenbestand von Bug-Trackernzu ergänzen, sondern den neuen Themenbereich Versionsmanagementsysteme einzu-bringen.

Es geht also um die Einbindung verschiedener Versionsmanagementsysteme und dieVerarbeitung der damit in Verbindung stehenden Datenbestände, welche sich auseinem solchen System extrahieren lassen.

1.1 Motivation des Themas

In einem Software-Entwicklungsprojekt werden Metriken zur quantitativen Erfas-sung relevanter Attribute verwendet. Software-Entwicklungs Metriken sind Abbil-dungen von einer Software oder einem Prozess der Software-Entwicklung auf eineskalare oder vektorielle Gröÿe. Metriken, die sich auf Versionsmanagementsystemebeziehen, beschreiben u.a. Attribute von Dateien, Ordnern oder Entwicklern. Mankönnte sich zum Beispiel für die Entwicklung des Dateibestandes im Laufe der Ent-wicklungszeit oder für den Arbeitsanteil eines bestimmten Entwicklers am Projektinteressieren.Auf der anderen Seite gibt es Metriken, die sich auf Attribute von Bugs einer Soft-ware beziehen. Für einen Projektleiter kann es interessant sein, wie sich die Anzahlan Bugs in einer Software entwickelt oder wie lange es dauert, bis ein Bug behobenwurde.BugzillaMetrics, das im Abschnitt 2.4 näher beschrieben wird, konzentriert sichhierbei auf Metriken, welche Attribute zu Bugs in der Software auf skalare Gröÿenabbildet. Die Datenbasis stammt hierbei aus dem Bug-Tracking-System Bugzilla.Dieses wird in Abschnitt 2.1.1 vorgestellt.Diese beiden Bereiche für Metriken lassen sich auch verknüpfen: Der Grund für eineÄnderung einer Stelle in der Software kann darin liegen, dass hiermit ein Bug be-hoben werden soll. Dies kann der Entwickler, welcher den zugehörigen Commit imVersionsmanagementsystem (siehe Abschnitt 2.2) absetzt, im Commit-Kommentarexplizit machen, indem er die zugehörige Nummer des Bugs im Bug-Tracker angibt.

7

Page 8: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

8 KAPITEL 1. EINFÜHRUNG

Auch im Bug-Tracker kann der Entwickler in einem Kommentar eines Bugs in-haltliche Angaben zu den Aktivitäten machen, die zur Behebung des Bugs beitragensollen. Dies kann beispielsweise eine Liste der Dateien sein, die er hierfür modi�zierthat. Entsprechend kann ein Attribut des Bugs lauten: Anzahl der Dateien, die vomBug betro�en sind. Ein anderes Beispiel wäre: Anzahl der von Entwickler für dieBehebung von Bug x gelöschten Codezeilen.Beides lässt sich in einer Metrik auf eine skalare Gröÿe abbilden, was theoretischvon BugzillaMetrics berechnet werden könnte.An dieser Stelle setzt das Thema der Diplomarbeit an. In der Arbeit wird dieseErweiterung von BugzillaMetrics sowie die Bereitstellung der dazu benötigten Da-ten realisiert. Hierzu wird das Integrationstool SCMBug verwendet. Es stellt dieVerbindung zwischen Versionsmanagementsystemen und Bugzilla dadurch her, dassalle Bug-Referenzen in einem Commit - Kommentar als Kommentar im zugehöri-gen Bug im Bugzilla-System eingetragen werden. Dieses Tool wird im Abschnitt 2.3näher vorgestellt.

1.2 Übersicht über diese Arbeit

In der Motivation der Diplomarbeit ist erkennbar, dass an diesem Thema vieleSoftwaresysteme beteiligt sind. Im Kapitel 2 werden diese zunächst einzeln unddarauf die bestehenden Abhängigkeiten und Schnittstellen zwischen den Syste-men vorgestellt. Am Ende dieses Kapitels folgt eine Übersicht über die zu diesemThemenbereich schon existierenden Ansätze.Das Kapitel 3 beschäftigt sich dann mit den Anforderungen an die Software, diewährend der Diplomarbeit erstellt wurde. Hierzu wurden zwei der existierendenTools dahingehend untersucht, welche Funktionalität sie bieten. Die Erkenntnissedaraus bilden dann die Grundlage für die Anforderungsanalyse, welche sich im wei-teren Verlauf des Kapitels anschlieÿt.Die Erweiterungen im BugzillaMetrics-Kern stellt die Grundlage für alle weiterenAnforderungen an die Integration, also die Art des Datenimports von den Ver-sionsmanagementsystemen, die Art der Datenspeicherung und das Vorgehen beimSystemtest, dar. Deshalb beschäftigt sich das Kapitel nur mit den allgemeinenAnforderungen und den Anforderungen des Kerns. Die Analysen für die anderenTeilbereiche be�nden sich dann zur Verbesserung der Übersichtlichkeit in den ent-sprechenden Kapiteln.Es ergeben sich vier Teilbereiche der Arbeit, mit denen sich die folgenden Kapitelbeschäftigen. Jedes dieser Kapitel geht auf das entsprechende Softwaredesign einund mit Ausnahme der schon analysierten BugzillaMetrics-Erweiterung auch aufdie Anforderungsanalyse.Zunächst wird im Kapitel 4 die Datenbank, welche den oben angesprochenen er-weiterten Datenbestand aufnimmt, vorgestellt.Um sicherstellen zu können, dass die Software qualitativ den Anforderungen gerechtwird, wurde ein eigenes Test-Framework entwickelt. Dies wird im Kapitel 5 vor-gestellt.Das Kapitel 6 beschäftigt sich dann mit dem Softwareteil, der die für die Metrik-berechnungen interessanten Daten der Versionsmanagementsysteme importiert.Damit diese zusätzlichen Daten auch im Programmkern von BugzillaMetrics ver-wendbar sind, musste dieser Kern erweitert werden. Die Beschreibung dazu �ndetsich in Kapitel 7.Die Evaluierung der Arbeit folgt in Kapitel 8. Den Abschluss bildet dann Kapitel9 in Form einer Zusammenfassung und einem Ausblick.

Page 9: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

Kapitel 2

Vorstellung der beteiligten

Systeme

Die folgenden Abschnitte, in denen die in der Motivation erwähnten Software-systeme vorgestellt werden, beschränken sich neben der groben Vorstellung derFunktionalität auf die Angabe der für das Thema relevanten Aspekte. Für einegenaue Beschreibung sei auf die entsprechende Literatur verwiesen.

2.1 Change Request Management-Systeme

Bei der Verwendung und auch schon in der Entwicklungsphase eines Software-systems kommt es ständig zu neuen oder geänderten Anforderungen.

Eine neue Gesetzgebung beein�usst beispielsweise eine Steuer-Software, die Neuaus-richtung eines Unternehmens erfordert die Unterstützung neuer Aspekte der Do-mäne, in der das Unternehmen aktiv ist oder die Entdeckung eines Fehlverhaltensder Software führt zu einem Korrekturwunsch.

Diese und weitere Wünsche der Anwender oder Entwickler einer Software, die sichimmer auf Fehler, Erweiterungen oder auch Änderungen beziehen, müssen doku-mentiert werden. Erst hierdurch werden sie explizit und damit bekannt. Nähereszum Change Management �ndet sich beispielsweise unter [13].

Systeme, die sich mit der Verwaltung solcher Änderungsanträge oder auch Pro-blemmeldungen beschäftigen, sind z.B. Bugzilla oder auch Mantis. Die allgemeineBezeichnung für Problemmeldungen oder Änderungsanträge ist hier Bug. Beide Sys-teme werden deshalb als Bug-Tracker bezeichnet. Sie ermöglichen die Beobachtungvon Bugs von ihrer Entstehung über die Verfolgung der mit dem Bug in Verbindungstehenden Änderungsmaÿnahmen an der Software bis hin zur Behebung des Bugs.

BugzillaMetrics unterstützt, wie der Name schon andeutet, seit Beginn dessen Ent-wicklung den Bug-Tracker Bugzilla, ist aber so ausgelegt, dass auch Erweiterungenfür andere Bug-Tracker möglich sind. Während der Arbeit an dieser Diplomarbeitwurde mit der zusätzlichen Unterstützung von Mantis begonnen. Die in dieser Ar-beit umgesetzte Erweiterung beschränkt sich auf Bugzilla.

Beide Systeme werden nun kurz vorgestellt, wobei der Schwerpunkt bei Bugzillaliegt.

9

Page 10: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

10 KAPITEL 2. VORSTELLUNG DER BETEILIGTEN SYSTEME

2.1.1 Bugzilla

Bugzilla ist ein Bug-Tracking System, welches von der Mozilla Organisation alsOpen Source Projekt entwickelt wird.

Der Nutzer eines Bugzilla-Systems ist in der Lage, alle Change Requests zu einemSoftwareprojekt und speziell zu einer bestimmten Komponente des Projekts zu ver-walten.

Neben Informationen, wie z.B. in welchem Zustand ein Bug ist oder welche Hard-ware bzw. welches Betriebssystem vom Bug betro�en ist, kann der im System re-gistrierte Nutzer Kommentare zu einem Bug abgeben.

Wie schon in Abschnitt 1.1 angesprochen, ist der Kommentar die einzige Stelle inBugzilla, an der eine Referenz zum Versionsmanagementsystem, das den Quellcodedes betrachteten Projekts verwaltet, möglich ist.

Dieses Feature ist gleichzeitig der einzige Punkt, der in dieser Arbeit indirekt vonBedeutung ist. Direkt wird Bugzilla hier nicht betrachtet. Die Integration benötigtlediglich die Angabe der Bugnummer im Kommentar des Commits. Das in Ab-schnitt 2.3 vorgestellte Tool SCMBug stellt zwar eine Referenz zum Versionsman-agementsystem innerhalb der Bugzilla-Kommentare her, die Integration macht sichaber nur die von SCMBug durchgeführte Konsistenzüberprüfung beider Welten zuNutze.

Aus diesem Grund wird Bugzilla hier nicht mehr näher beschrieben. Für detail-liertere Informationen sei auf den Bugzilla Guide (siehe [20]) verwiesen.

2.1.2 Mantis

Mantis ist ein web-basiertes Bug-Tracking System, das mit PHP geschrieben wird.Es steht unter der GNU General Public Lizenz und existiert sein 2002 als Pro-jekt, das von Kenzaburo Ito initiiert wurde. Ziel der Entwickler ist es, ein leicht-gewichtiges und einfaches Bug-Tracking System zu schreiben. Es weist viele Ähn-lichkeiten mit Bugzilla auf und wird nun auch von BugzillaMetrics unterstützt.Weitere Informationen �nden sich unter [11].

2.2 Versionsmanagementsysteme

Das Thema der Arbeit macht keinerlei Einschränkungen bezüglich des konkretenVersionsmanagementsystems. Prinzipiell könnten alle existierenden Systeme unter-stützt werden. Dies sind nach Frank Budzuhn [1] beispielsweise:

• CVS (Concurrent Versions System):Basiert auf dem Versionsmanagementsystem RCS ( Revision Control System).Eine genauere Beschreibung folgt im Abschnitt 2.2.1.

• Subversion:Subversion wurde von der Firma CollabNet entwickelt. Im Abschnitt 2.2.2folgt eine genauere Beschreibung.

• Visual Source Safe:Ein Versionsverwaltungssystem auf Dateiebene, das von Microsoft entwickeltwird und sich vor allem auf die Entwicklung von Produkten für Windowskonzentriert.

Page 11: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

11

• ClearCase:Ein kommerzielles Versionsmanagementsystem das vom Hersteller Rationalentwickelt wurde und seit 2004 zum Produktportfolio von IBM gehört. EineBesonderheit von Clear Case ist, dass es in bestehende Dateimanager, wie denMicrosoft Explorer, integriert wird.

• Perforce:Ähnelt CVS, ist aber schneller und vermeidet einige Schwächen von CVS.

• BitKeeper :Kleiner und schneller CVS - Ersatz, der zeitweise bei der Entwicklung desLinux - Kernels eingesetzt wurde.

Aufgrund der Tatsache, dass CVS und Subversion die bekanntesten Vertreter vonVersionsmanagementsystemen sind und eine Betrachtung weiterer Systeme zeitlichnicht möglich war, beschränkt die Diplomarbeit sich auf die Unterstützung dieserbeiden Systeme, welche in den folgenden beiden Abschnitten vorgestellt werden.

2.2.1 Concurrent Versions System (CVS)

Das Versionsmanagementsystem CVS existiert seit 1986. Die erste Version wurdevon Dick Grune verö�entlicht und basiert auf dem Versionsmanagementsystem RCS(Revision Control System). Es ist ein Open Source-Projekt und steht unter derGNU Public Licence. Im Gegensatz zu RCS können mehrere Entwickler gleichzeitigan der selben Datei arbeiten, indem jeder Entwickler eine lokale Arbeitskopie desEntwicklungsprojekts verwendet und Änderungen dem System durch sog. Commitsmitteilt. Ein Commit ist die Verö�entlichung aller seit der letzten Verö�entlichungvorgenommenen Änderungen in der lokalen Arbeitskopie. Das Versionsmanagement-system wird dazu veranlasst, den für alle Entwickler o�ziellen Projektzustand aufdem Systemserver mit den Änderungen des Commits zu aktualisieren. Im Anschlusskönnen alle anderen Entwickler diese Änderungen durch ein Update ihrer lokalenArbeitskopien erhalten.

CVS kümmert sich darum, dass die Inhalte verschiedener Entwickler zusammenge-fügt werden. CVS verwendet das Konzept desModuls. Ein Modul stellt eine Verwal-tungseinheit in Form eines Verzeichnisses dar, das Dateien und Unterverzeichnissebeinhalten kann.Leider besitzt CVS einige nachteilige Eigenschaften, welche in dieser Arbeit relevantsind:

• Es werden Dateien, aber keine Verzeichnisse unter Versionskontrolle gestellt.

• Beim Umbenennen oder Verschieben von Dateien verliert CVS die Änderungs-historie der Datei. Für das System gehört alles, was sich bis zum Umbenennenoder Verschieben in der Datei ereignet hat, zu einer gelöschten Datei. DieEreignisse nach der Umbenennung oder Verschiebung gehören zu einer neuenDatei. Logisch beschreiben beide die selbe Datei, verwaltungstechnisch zweivöllig unabhängige.

Weitere Informationen zu CVS �nden sich im Abschnitt 2.2.3, in dem CVS mit demanderen hier verwendeten Versionsmanagementsystem Subversion verglichen wird.Für Informationen darüber hinaus wird auf [1] verwiesen.

Im nächsten Abschnitt folgt eine Beschreibung des SCM-Systems Subversion.

Page 12: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

12 KAPITEL 2. VORSTELLUNG DER BETEILIGTEN SYSTEME

2.2.2 Subversion (SVN)

Subversion wurde von der amerikanischen Software�rma CollabNet als Ersatz fürCVS entwickelt. Der Beginn der Arbeit war im Jahr 2000, die Version 1.0 wurdeam 23.02.2004 verö�entlicht. Die Gründe für diese Neuentwicklung waren die schonangesprochenen Schwachstellen von CVS.Eine weitere Schwachstelle ist das veraltete Softwaredesign von CVS. Subversionwurde modular geschrieben und besitzt für jede der Funktionen, wie z.B. Zugri�s-methode oder Datensicherung, mehrere alternative Bausteine. Beispielsweise könnendie Daten der Repository im Dateisystem oder in einer Datenbank liegen.SVN verwaltet neben Dateien auch Verzeichnisse und ist für viele Plattformen, wiez.B. Windows, UNIX und Mac OS X, verfügbar.Im folgenden Abschnitt wird Subversion mit CVS verglichen.

2.2.3 Vergleich von CVS und Subversion

Die beiden Versionsmanagementsysteme CVS sowie Subversion weisen zwar Gemein-samkeiten auf, jedoch gibt es in bestimmte Bereichen viele Unterschiede.

In diesem Abschnitt werden alle grundlegenden bzw. für diese Arbeit relevantenGemeinsamkeiten und Unterschiede zusammengestellt.

2.2.3.1 Gemeinsamkeiten

Entwicklungskonzept

Jeder Entwickler besitzt eine lokale Arbeitskopie. Änderungen werden den anderenEntwicklern durch Commits zugänglich gemacht. Diese können den Inhalt ihrerlokalen Repositories durch ein Update mit dem der globalen Repository abgleichen.

Kommandozeilenbefehle

Das Design der Kommandozeilenbefehle von Subversion orientiert sich an den Be-fehlen von CVS, um es Entwicklern zu erleichtern, von CVS zu Subversion zu wech-seln. Es gibt also viele Übereinstimmungen bezüglich der Namensgebung und derParameterauswahl.

2.2.3.2 Unterschiede

Inhalt der lokalen Arbeitskopie

Subversion hält in der lokalen Arbeitskopie zu jeder Datei eine Historie, in derInformationen zu allen existierenden Versionszuständen der Datei gesichert sind.Viele Entwickleranfragen, wie einige di� Operationen, können hiermit, anders alsbei CVS, lokal beantwortet werden und benötigen keinen Zugri� auf den Server.

Revisionsnummern

CVS vergibt für jede Datei separate Revisionsnummern. Bei SVN gehört eine Revi-sionsnummer zu einem Zustand der Repository. Demnach gehört zu jedem Commiteine Revisionsnummer.

Diese Nummern sind bei SVN natürliche Zahlen, bei CVS mehrere natürliche Zahlen,die durch Punkte getrennt sind. Hierdurch werden verschiedene Branches unter-schieden. Diese Informationen können Revisionsnummern von SVN nicht liefern.

Page 13: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

13

Verzeichnisse

SVN unterstützt eine vollständige Versionskontrolle für Verzeichnisse. Diese könnenhinzugefügt, umbenannt, verschoben oder gelöscht werden. Bei CVS ist all dies nichtmöglich. Hier existiert ein Verzeichnis ab dem Zeitpunkt, zu dem sich eine Dateidirekt oder indirekt in einem Unterordner im Verzeichnis be�ndet. Verzeichnissebleiben dauerhaft in der Repository und können nicht gelöscht werden.

Commits

CVS führt für jede Datei einen einzelnen Commit aus, egal ob der Entwickler eineoder n Dateien committen wollte. Unter SVN können mehrere Dateien bzw. Ver-zeichnisse committet werden.

Tags und Branches

Dieser Punkt wird bei CVS und SVN völlig unterschiedlich gehandhabt. Aus diesemGrund geht dieser Abschnitt zunächst auf die generelle Bedeutung von Branches undTags ein und beschreibt darauf, wie CVS und SVN dies realisieren.

Tags Tags dienen grundsätzlich dazu, ein Release anzulegen. Wenn also der Zu-stand einer Datei oder einer Menge von Dateien in einer bestimmten Revisiongesichert werden soll, bekommen alle betro�enen Dateien einen textuellen Bezeich-ner, der den Namen des Releases enthält und sich merkt, wie der Zustand in deraktuellen Revision ist. Diese Dateien können danach modi�ziert und später wiederin den Releasezustand zurückversetzt werden.

CVS CVS unterscheidet zwischen tag, rtag und Sticky Tag. Die ersten bei-den bewirken grundsätzlich das gleiche, aber �tag arbeitet auf Dateien der lokalenArbeitskopie und rtag auf ganzen Modulen im Repository�[1]. rtag setzt also dieTags direkt in der Repository, tag zunächst, also bis zum nächsten Commit, nurlokal. Sticky Tags werden in der lokalen Arbeitskopie dazu verwendet, ein Updateauf eine neuere Version einer Datei zu unterbinden. Wenn eine Datei ein Sticky

Tag mit der Revisionsnummer 4.5 hat, dann bleibt diese lokal in der Version 4.5,bis das Sticky Tag wieder entfernt wird.Alle drei Tag-Varianten sind also nur lokal zu unterscheiden, in der Repositorydemnach nicht von Bedeutung.

SVN Unter SVN gibt es keinen Unterschied zwischen Tags und Branches. Beideswird im folgenden Absatz zu Branches beschrieben.

Branches Diese werden verwendet, wenn z.B. aus experimentellen Gründen oderbei der Verwaltung von Fehlerkorrekturen mehrere Versionen des Quellcodes parallelexistieren sollen.

CVS Unter CVS werden Branches mittels tag oder rtag und der Option -d

angelegt. Alle Dateien, die z.B. den Tag �Verzweigung1� haben, gehören zu einemgemeinsamen Branch. Im Repository existieren dann zwei unterschiedliche Dateien,die von der selben Ursprungsdatei abstammen, aber unabhängig weiterentwickeltwerden können. Später können diese dann mittels Merge wieder zusammengefasstwerden.Erzeugt man einen Branch, so werden die betro�enen Dateien in der eingeführten

Page 14: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

14 KAPITEL 2. VORSTELLUNG DER BETEILIGTEN SYSTEME

Verzweigung festgehalten. Der erzeugte Tag ist im Falle eines Branches also einSticky Tag. Dies spiegelt sich in der Revisionsnummer wieder.Die Datei erhält eine erweiterte Revisionsnummer, welche die alte Nummer (z.B.1.8) enthält, gefolgt von einer geraden Zahl gröÿer 0. Diese drückt die Nummerdes Branches aus (z.B. für den ersten Branch, der für die Datei in Revision 1.8erzeugt wird eine 2, für den zweiten eine 4 etc.). Weitere Revisionen der verzweigtenDatei werden dann durch eine vierte Zahl beschrieben (Die erste Revision der neuverzweigten Datei hat dann die Nummer 1.8.2.1, die zweite 1.8.2.2 etc.).

SCMBug meldet einen neuen Branch erst dann, wenn in diesem ein Commit er-folgt ist.

SVN Unter SVN ist die Erstellung sowohl eines Branches als auch die Erstel-lung eines Tags aus der Sicht des Entwicklers mit dem vollständigen Kopieren derQuellrevision in ein anderes Verzeichnis gleichzusetzen. Das Verzeichnis, in dem dieHaupt-Entwicklungslinie liegt, ist standardmäÿig trunk. Alle Neben-Entwicklungs-linien werden standardmäÿig im Verzeichnis branches gehalten. Tags liegen stan-dardmäÿig im Verzeichnis tags. Alle drei Namen können auch anders lauten. DieseBezeichnung wird aber als Konvention empfohlen.Intern legt SVN lediglich einen Link vom �Branchverzeichnis� bzw. �Tagverzeich-nis� zum Trunkverzeichnis an. Die Änderungen an einer Datei, die sich in mehrerenEntwicklungslinien be�ndet, werden in einer gemeinsamen History vermerkt. [3]

Die History trennt also die Branches, Tags und die Trunk-Entwicklungslinien nichtvoneinander, sondern setzt in der History zu jeder Datei entsprechende Markierun-gen. Die Trennung wäre auch nicht möglich, da Subversion die unterschiedlicheBedeutung von Branches, Tags und Trunk nicht kennt, sondern alle drei Arten alsnormale Verzeichnisse in der Repository verwaltet.

Unter SVN wird die Erstellung von Verzeichnissen mit den Namen branches undtags zwar empfohlen, aber nicht erzwungen. In der Kon�gurationsdatei glue.conffür den SCMBug-Glue einer Repository können die gewählten Namen für Branchesund Tags aber angegeben werden:

# This applies only to Subversion. It is recommended that tags

# are stored in the 'tags' directory, and branches in the

# 'branches' directory.

label_directories => [ 'tags', 'branches' ],

# This applies only to Subversion. It is recommended that the

# main trunk work is stored in the 'trunk' directory.

main_trunk_directories => [ 'trunk' ],

Der SCMBug-Glue wird im Abschnitt 2.3 beschrieben. BugzillaMetrics kann alsonicht davon ausgehen, dass jede SVN-Repository die Verzeichnisse trunk, branches

und tags besitzt, aber über die SCMBug-Schnittstelle werden diese trotzdem richtigidenti�ziert. (Voraussetzung: Die Schnittstelle ist richtig kon�guriert.)

Informationsgehalt der Kommandozeilenbefehle CVS und Subversion bie-ten zwar grundsätzlich den gleichen Informationsgehalt in den Ausgaben der Kom-mandozeilenbefehlen, wie beispielsweise cvs /svn log, diff oder annotate, diesesind jedoch z.T. anders aufgeteilt. SVN bietet mehr Befehle, die aber jeweils wenigerInformationen liefern. Relevant ist dies hier für den Informationsgehalt von cvs log,dessen Ausgabe grundlegende Informationen zu den existierenden Dateien und Re-visionen enthält. Um gleiche Informationen auch für SVN zu erhalten, muss neben

Page 15: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

15

Listing 2.1: cvs log - Informationen

sudo cvs −d : l o c a l : / usr / l o c a l / cvs roo t l ogcvs l og : Logging .RCS f i l e : / . . . / Bugz i l l aMet r i c s / Tes tdate i . java , vWorking f i l e : Tes tdate i . javahead : 1 . 3branch :l o ck s : s t r i c ta c c e s s l i s t :symbol ic names :

BugzillaMetrics_RELEASE_3−0−0: 1 . 1keyword s ub s t i t u t i o n : kvt o t a l r e v i s i o n s : 1 ;s e l e c t e d r e v i s i o n s : 1d e s c r i p t i o n : −−−−−−−−−−−−−−−−−−−−−−−−−−−−r e v i s i o n 1 .1date : 2008−06−12 17 : 08 : 42 +0200; author : c h r i s ; s t a t e : Exp ;commitid : R0St9RaAnHcpFF6t ;I n i t i a l r e v i s i o n================================================

svn log zusätzlich auch svn info für jede Revision einzeln abgefragt werden. DieTabelle 2.1 stellt die verfügbaren Informationen und die jeweilige Quelle zusammen.

Information / SCM-System CVS

cvslog

SVN

svnlog

svninfo

Speicherort der RCS-Datei√ √

- - -TRUNK / Head

√ √ √ √

Alle symbolischen Namen (tags)√ √ √ √

Branches√ √ √ √

Anzahl an Revisionen√ √ √ √

Für jede Revision...Revisionsnummer

√ √ √ √

Datum√ √ √ √

Autor√ √ √ √

Anzahl an Zeilen (added/deleted)√ √ √ √

Commit-ID√ √ √

1√

Log-Kommentar (inkl. Bug ID)√ √ √ √

Tabelle 2.1: Überblick über den Informationsgehalt der cvs log, svn log und svn

info Ausgaben

CVS liefert über cvs log viele Informationen, die sich auch über Parameter einzelnabfragen lassen.Die Log-Abfrage in Listing 2.1 liefert beispielhaft alle über cvs log zugänglichenInformationen und die von CVS verwendete Syntax. Alle Datum- und Zeitangabenbeziehen sich immer auf die lokale Zeit des Client-Systems und können über dieUmgebungsvariable $TZ formatiert werden.

Unter SVN ist es etwas unübersichtlicher, Informationen zusammenzutragen, da eskeinen Kommandozeilenbefehl gibt, der alle Informationen liefert, die cvs log zurVerfügung stellt.svn log listet alle Commits plus der direkt damit in Verbindung stehenden In-

Page 16: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

16 KAPITEL 2. VORSTELLUNG DER BETEILIGTEN SYSTEME

Listing 2.2: svn log - Informationen

svn log−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−r5 | root | 2008−06−12 17 : 53 : 19 +0200 (Do , 12 Jun 2008) | 2 l i n e s

bug3 : Dies e r t s e l l t e inen Branch Branch_RELEASE_1−0−0 in SVN−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−r4 | root | 2008−06−12 17 : 23 : 35 +0200 (Do , 12 Jun 2008) | 2 l i n e s

Commit der Tes tdate i von SVN aus−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−r3 | root | 2008−06−12 17 : 16 : 59 +0200 (Do , 12 Jun 2008) | 2 l i n e s

Import−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

Listing 2.3: svn info - Informationen

$ svn i n f o Bugz i l l aMet r i c sPfad : Bugz i l l aMet r i c sURL: f i l e : /// usr / l o c a l / svnroot / trunkBas i s des Pro j ek ta r ch i v s : f i l e : /// usr / l o c a l / svnrootUUID des Pro j ek ta r ch i v s : a3537a91−9da5−46b8−8395−8 e f 2 83 e5 e c0 fRev i s ion : 3Knotentyp : Ve r z e i chn i sPlan : normalLe t z t e r Autor : rootLetzte geänderte Rev : 3Le t z t e s Änderungsdatum : 2008−06−12 17 : 16 : 59 +0200 ( . . . )

formationen auf. Dies lässt sich auch nach Dateien und Verzeichnissen �ltern. EinBeispiel zeigt Listing 2.2. Es ist mit dem Parameter --verbose zwar möglich, allePfade zu erhalten, die beim Commit verändert wurden, aber die Ausgabe liefertkeine Informationen dazu, ob es sich beim Pfad um eine Datei oder um einen Ord-ner handelt. Wie eine Ausgabe von cvs info aussehen könnte, zeigt Listing 2.3.Ein groÿer Vorteil von SVN gegenüber CVS ist die Möglichkeit, viele Ausgaben inXML zu formatieren. Dies erleichtert das automatische Auslesen deutlich.

Weitere Details zu besonderen Eigenschaften von CVS und Subversion, die an dieserStelle nicht relevant sind, �nden sich beispielsweise unter [16] und [3].

2.3 SCMBug

�SCMBug ist ein System, das Software-Kon�gurationsmanagement-Systememit Bug-Trackern integriert. Es wurde in Perl implementiert und läuftauf UNIX und Windows Systemen.� ([21])

SCMBug ist als Client-Server - System aufgebaut.

Der Client ist in Form einer Glue-Komponente realisiert. Diese Komponente bestehtaus verschiedenen Hooks, welche in allen Repositories installiert werden, welche vonSCMBug kontrolliert werden sollen. Hooks erfassen Aktivitäten in der Repository,wie z.B. Commits, und melden diese an den Daemon, welcher alle in einem Systemvorhandenen Glues bedient.

Page 17: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

17

Der Daemon ist wiederum mit den vorhandenen Bug-Trackern verbunden, in dieer die erfassten Aktivitäten in Form von Kommentaren zum referenzierten Bugintegriert. Diese Kommentare enthalten neben dem Kommentar zur SCM-Aktivitätdie Pfade zu den Dateien, welche von der Aktivität betro�en sind und den Branchoder Tag, zu dem diese vorliegen.

Neben der eigentlichen Integration ist SCMBug auÿerdem in der Lage, verschiedeneVeri�kations-Checks durchzuführen. Beispielsweise können reguläre Ausdrücke ange-geben werden, welche vom Kommentartext gematcht werden müssen, es kann er-zwungen werden, dass eine referenzierende Bug-ID im Kommentar angegeben wirdoder die Namen von Tags bzw. Branches einen regulären Ausdruck matchen, dereine Namens-Konvention beschreibt.Misslingt der Veri�kations-Check, bricht SCMBug die zugehörige Aktivität in derSCM-Repository ab.

Die Architektur von SCMBug ist in Abbildung 2.1 dargestellt.

Abbildung 2.1: SCMBug-Systemarchitektur (Quelle: [21, 22])

Wie in Abbildung 2.1 erkennbar, unterstützt SCMBug sowohl diverse Versions-managementsysteme als auch verschiedene Bug-Tracker. Unter anderem gilt diesauch für die schon vorgestellten Bug-Tracker Bugzilla und Mantis.

Neben der reinen Integration von Commit-Kommentaren mit Bug-Referenz undder Angabe, welche Dateien beim Commit manipuliert wurden, ist SCMBug auchin der Lage eine Verbindung zwischen den Entwicklernamen im SCM-System mitden entsprechenden im Bugzilla-System herzustellen. Ein Entwickler, der unter CVSbeispielsweise thomas heiÿt und unter Bugzilla den Login - Namen [email protected] verwendet, kann von SCMBug als ein und die selbe Person iden-ti�ziert werden. Dies ist auf drei verschiedene Arten möglich:

• Mapping unter Verwendung von LDAP2

• Mapping durch reguläre Ausdrücke

• 1:1 - Mapping durch Angabe einer Liste von SCM-Entwicklernamen inklusiveder zugehörigen Bugzilla-Namen.

Die SCM-Integration für BugzillaMetrics unterstützt alle drei Varianten.

2.4 BugzillaMetrics

BugzillaMetrics ist ein Werkzeug zur Berechnung von Metriken auf der Datenbasisvon Bugzilla. Es wurde 2007 im Rahmen der Diplomarbeit von Lars Grammel er-

2Lightweight Directory Access Protocol (LDAP): Anwendungsprotokoll, das Abfragen undModi�kationen von Informationen eines Verzeichnisdienstes erlaubt.

Page 18: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

18 KAPITEL 2. VORSTELLUNG DER BETEILIGTEN SYSTEME

stellt und wird seitdem ausgebaut, wie auch mithilfe dieser Arbeit.Das Tool verarbeitet Metrikspezi�kationen in Form von XML-Dateien und greifthierfür auf die SQL-Datenbank von Bugzilla zu. Das Ergebnis ist eine Zeitreihe,welche auf verschiedene Arten visualisiert werden kann. Möglich ist ein Graph, derals JPEG-Bilddatei ausgegeben wird oder auch die Ausgabe der Werte z.B. imxsc-Format. BugzillaMetrics verarbeitet also Metriken, die auf einen skalaren Wertabbilden. Dieser bildet den Wert für die y-Achse des Graphen, wobei die x-Achsefür jede Metrik die Zeit beschreibt.

Die Metrikspezi�kationen enthalten vier Kernbestandteile:

• BaseFilter: Ermöglichen die Auswahl bestimmter Bugs aus Bugzilla. Bugswerden in BugzillaMetrics als Cases3 bezeichnet.

• Events: Sie beschreiben Zeitpunkte, die mit einem bestimmten Ereignis inVerbindung stehen, welches einen Case betri�t. (Beispiel: create ist ein Eventzum Bug x und sagt aus, dass Bug x zum Zeitpunkt des Events erzeugt wurde.x ist hier eine natürliche Zahl.)

• Weights: Um aus der Metrikspezi�kation einen Graphen berechnen zu können,muss der Funktionswert zum Zeitpunkt eines Events de�niert werden. Diesgeschieht mittels Weights. Sie gewichten die Cases, zu denen der Event gehört,nach einem bestimmten Kriterium (Beispiel: Alter des Cases zum Eventzeit-punkt).

• Case Value Calculators: Es ist möglich, nur solche Events bei der Berechnungzu berücksichtigen, die bestimmte Eigenschaften haben. Diese Selektion er-folgt durch Event-Filter.Mit diesen Filtern ist es auÿerdem möglich, weiterführende Selektionen vorzu-nehmen. Beispielsweise kann die Metrikberechnung auf diejenigen Events re-duziert werden, die zeitlich vor einem bestimmten Event liegen.

2.5 Überblick über die beteiligten Systeme

Die bis hier beschriebenen Systeme sind alle über Schnittstellen miteinander ver-knüpft. Einen Überblick dazu liefert Abbildung 2.2.

Die Schnittstellen zwischen den Systemen sind:

• Bugzilla ←→ MySQL-Datenbank:Bugzilla benötigt Lese- und Schreibzugri� auf die bugzilla Datenbank. Hierbeiwerden die Daten, welche bei der Verwaltung der Bugs anfallen, in Tabellengeschrieben und gelesen.

• BugzillaMetrics ←→ MySQL-Datenbank:BugzillaMetrics schreibt nicht in die bugzilla-Datenbank, sondern benötigtnur einen Lesezugri�. Hierbei werden Datenbankanfragen über die Standard-schnittstelle zu MySQL, also Kommandozeilenbefehle, gestellt. Alle verwen-deten Daten bilden die Grundlage für Metrikberechnungen. Welche Datengelesen werden, hängt von der zu berechnenden Metrikspezi�kation ab.

• SCMBug ←→ Bugzilla:Da Bugzilla keine ö�entliche SCM-Schnittstelle liefert, greift SCMBug über

3In dieser Arbeit wird der Begri� Bug verwendet. Der Begri� Cases wird nur dann verwendet,wenn die Objekte der BugzillaMetrics Architektur, welche Cases modellieren, zur Sprache kommen.

Page 19: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

19

Abbildung 2.2: Übersicht über die Zusammenhänge zwischen den beteiligten Soft-waresystemen

Perl-basierte Bugzilla-Bibliotheken auf Bugzilla zu [22]. Es erfolgt also keinZugri� über eine Standardschnittstelle. Nach [22] soll es aber in zukünftigenVersionen von Bugzilla eine SCM-Schnittstelle geben, welche die Verwendungder Bibliotheken unnötig macht.SCMBug verwendet die Schnittstelle, um die Integration der SCM-Daten inden Bestand der Bug-Verwaltungsdaten durchführen zu können.

• SCMBug ←→ SCM:SCMBug überwacht CVS und Subversion, indem es Hooks in den SCM-Repositories installiert. Diese erfassen Aktivitäten in den Repositories, wiez.B. Commits. Die in den verwendeten Bug-Tracker zu integrierenden Daten,wie z.B. Kommentar oder Bug-Referenz werden hierüber gelesen. Auch einEingreifen in das SCM-System ist über diese Schnittstelle möglich: Falls einVeri�kations-Check fehlschlägt, kann die Aktivität, die von den Hooks erfasstwurde, abgebrochen werden.

2.6 Überblick über existierende Ansätze in der Lit-eratur

In diesem Abschnitt wird es darum gehen, anhand von [12] (im Folgenden: Sur-vey) einen Überblick über die existierenden Ansätze für die Analyse von Software-Repositories zu geben. Anhand dessen soll diese Arbeit eingeordnet werden.

Das Ziel des Surveys ist es, diejenige Literatur zu sichten, die sich mit der Un-tersuchung von evolutionären Änderungen von Software beschäftigt, was auch aufdiese Arbeit zutri�t. Themen, die nur eine einzige Softwareversion untersuchen, wer-den nicht betrachtet. Hierbei wurde die Literatur einbezogen, die bis August 2006verö�entlicht wurde.

Das Paper beschreibt die Ansätze anhand von vier Dimensionen:

1. Typ der untersuchten Repositories (Was wird untersucht?)

Page 20: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

20 KAPITEL 2. VORSTELLUNG DER BETEILIGTEN SYSTEME

Es gibt drei grundlegende Repository-Typen, die hier von Bedeutung sind.Dies sind Versionsmanagementsysteme (z.B. CVS), Bug-Tracker (wie Bugzil-la) und verschiedene Kommunikationsmittel, die in der Lage sind, Korrespon-denzen zu archivieren (beispielsweise E-Mail).

Alle drei können den Enwicklungsverlauf in einem Softwareprojekt dokumen-tieren. Dies können die verschiedenen Quellcodeversionen, die Verwaltung vonChange Requests oder auch Diskussionen der Entwickler sein.Die grundlegende Informationseinheit hierbei ist die Softwareänderung, da sieden Unterschied zwischen zwei Versionen, also die Evolution der Software,beschreibt. Alle weiteren Informationen dienen nur zum Verständnis oderManagement der Software. Entsprechend gibt es drei Kategorien, die für dieRepository-Analyse von Bedeutung sind:

• Softwareversionen

• Unterschiede zwischen Versionen (z.B. in Form von Zeilenunterschiedenin Dateien)

• Metadaten zur Softwareänderung (Liefern Informationen zur Semantikvon Softwareänderungen, wie Commit-Kommentare, Zeitpunkt der Än-derung, Bug-Reports, etc.)

2. Zweck der Untersuchung (Warum und wofür wird untersucht?)

Entwickler, die Repositories untersuchen, tun dies, um Antworten auf be-stimmte Fragen zu erhalten. (Z.B. Systemwachstum, Wiederverwendung oderBeziehungen zwischen Komponenten) Diese Fragen teilen sich in zwei Kate-gorien auf:

• Warenkorb - Fragen: Wenn etwas Bestimmtes passiert, was passiert dannin der Regel noch?

Der Name ist durch ein Beispiel entstanden, das diesen Fragetyp be-schreibt: Beim Einkaufen gibt es Mengen von Artikeln, die typischerweisegemeinsam gekauft werden. Ein Kunde, der einen Nassrasierer in seinenEinkaufswagen legt, wird wahrscheinlich auch Rasierschaum kaufen undkeinen Trockenrasierer. Bezogen auf Software-Untersuchungen kann mansich nach der Erstellung eines Bugs die Frage stellen, wann dieser oderwelche anderen Bugs durch diesen entstanden sind.

• Metriken oder boolesche Anfragen:Dies sind Abbildungen von der Software in skalare oder vektorielle Gröÿenbzw. boolesche Werte. Beispiele wären die Anzahl von Paketen im Pro-jekt oder die Frage, ob es zyklische Abhängigkeiten zwischen Paketengibt.

3. Verwendete Untersuchungsmethode (Wie wird untersucht?)

Hat man eine Frage zu einer bestimmten Repository, dann muss die Antwortdazu auf irgend eine Weise berechnet oder auf sonst eine Art bestimmt werden.Hierzu gibt es zwei grundlegende Ansätze:

• Bestimmung von Änderungen der Eigenschaften der Repository:

Externe Messung und Analyse der Software-Evolution: Bestimme oderberechne die Antwort für jede Softwareversion einzeln und vergleichedann die verschiedenen Ergebnisse miteinander. Es geht in diesem Ansatz

Page 21: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

21

also darum, bestimmte Eigenschaften von Versionen miteinander zu ver-gleichen. Die Aktivitäten, die dazu führen, dass ein Objekt von einerVersion zur nächsten wechselt, sind also hier uninteressant.

Beispiel: Interessiert man sich dafür, wie schnell ein Softwareprojektwächst, kann man die Anzahl der Codezeilen zunächst für jede Projekt-version separat berechnen und später dann diese Zahlen miteinander ver-gleichen.

• Bestimmung von Änderungen der Repository-Objekte:

Interne Messung und Analyse der Software-Evolution: Hier interessiertman sich für die Änderungen eines Objekts, die dafür verantwortlich sind,dass das Objekt seine Version ändert. Man untersucht also die Mecha-nismen und Tatsachen, die dazu führen, dass ein Objekt, wie z.B. eineDatei, von einer Version zur nächsten wechselt.

Beispiel: Anstatt, wie im vorigen Beispiel die Codezeilen der Versionenzu zählen, kann man alternativ auch die Änderungen in den Codezeilenanalysieren und anhand der hinzugefügten und gelöschten Zeilen dasWachstum des Projekts bestimmen. Ein klassischer Weg, dies bei Ver-sionsmanagementsystemen zu tun, ist die Verwendung von cvs di� oderauch svn di�.

4. Verwendete Bewertungsmethode (Qualität der Untersuchung?)

Der Sinn aller Tools zur Analyse von Softwareprojekten ist die Verbesserungder zukünftigen Projekt-Entwicklung. Die Analyse selbst ist wertlos, wennsie keine Fehler, Mängel im Entwicklungsprozess oder andere Verbesserungs-möglichkeiten aufdeckt. Demnach kann ein Analysetool dadurch bewertet wer-den, inwiefern es eine Verbesserung fördert.Ein gängiges Beispiel für die Bewertung eines Ansatzes, der in irgend ein-er Form Prognosen zum Entwicklungsprozess erstellt, ist die Anwendung desAnsatzes auf die erste Hälfte der schon vorliegenden historischen Projekt-daten. Nur wenn die resultierende Prognose die zweiten Hälfte der Datenhinreichend genau beschreibt, ist die Qualität des Ansatzes hoch.

Das Survey beschreibt über 80 Ansätze. Aufgrund der groÿen Zahl können diesehier nicht alle detailliert beschrieben werden. Dieser Abschnitt dient auch nichtdazu, allein das Survey zu beschreiben, sondern verwendet das oben vorgestellteBewertungsschema, um eine Einordnung dieser Diplomarbeit in die Menge allerAnsätze dieses Themenbereichs zu ermöglichen. Das Survey ordnet die Ansätzenach den verwendeten Analysemethoden.

Diejenigen Ansätze, welche inhaltlich zu dieser Diplomarbeit passen, also auf ir-gend eine Art und Weise Bug-Tracker mit Versionsmanagementsystemen verbinden,werden nach dieser Ordnung nach Analysemethoden in Kürze vorgestellt. Zusätz-lich wurden die beiden Analysetools StatCVS und Eclipse Dash, die in der An-forderungsanalyse dieser Arbeit eine Rolle spielen werden, aufgenommen.

Die Diplomarbeit selbst wird dann im Kapitel 8 in diese Menge von Ansätzen ein-geordnet.

• Metadatenanalyse

Metadaten bilden die erste Wahl bei der Repositoryanalyse, da sie direktzugänglich sind. Dies kann beispielsweise über eine cvs log-Abfrage geschehenoder über die Analyse der Bugzilla-Datenbank.Deshalb ist dies die Methode, die von den meisten Ansätzen verwendet wird.

Page 22: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

22 KAPITEL 2. VORSTELLUNG DER BETEILIGTEN SYSTEME

◦ Bug-Fix Änderungsanalyse:Sliwerski et al. [18] untersucht Softwareänderungen, die zur Behebungeines Bugs durchgeführt werden.Hierzu wird der zugehörige Commit-Kommentar aus der Ausgabe von cvslog gelesen und mit Hilfe von regulären Ausdrücken mit der textuellenBeschreibung von Bugs aus Bugzilla gematcht.

◦ Vorhersage von Softwaredefekten und -fehlern:Ostrand und Weyuker [15] entwickelten ein Fehler-Vorhersagemodell aufder Basis von Metadaten aus Bug-Trackern. Die Nutzer dieses Modellserhalten eine Liste von fehleranfälligen Dateien, die im nächsten Releaseder untersuchten Software möglicherweise wieder zu Fehlern führen kön-nten. Beispielsweise eine Liste von Dateien, die für mindestens 5 % derFehler verantwortlich sein werden.

• Statische Quellcodeanalyse

Die statische Quellcodeanalyse macht sich die Fähigkeit von Quellcode-Reposi-tories zu Nutze, nicht nur Code zu einem Release, sondern zu jeder Code-version liefern zu können, die in der History der Entwicklung existiert hat. Sieanalysiert den Quellcode selbst, um bestimmte Informationen zu extrahieren,ihn zu parsen oder auch für einen bestimmten Zweck auszuführen.

◦ Bugs �nden und beheben:Williams und Hollingsworth stellen in [23, 24] einen Ansatz zur automa-tischen Bug-Erkennung über die Analyse des Quellcodes vor. Sie konzen-trieren sich hier auf Bugs, die den Return-Wert von Funktionen betre�en.

• Quellcodeunterscheidung und -analyse

Versionsmanagementsysteme bieten bei der Frage, wie sich zwei Versioneneiner Datei unterscheiden Funktionen, die auf Codezeilenebene arbeiten (wiebeispielsweise cvs di�). Es gibt bei der Analyse von Software-RepositoriesAnsätze, welche versuchen, die Beschreibung der Unterschiede nicht anhandvon Codezeilen, sondern über die Syntax oder Semantik durchzuführen. Dieskann beispielsweise in Form von Quellcode-Modellen geschehen. Alle Ansätze,die dies verfolgen, gehören zu dieser Kategorie.

◦ Semantische Unterscheidung: Raghavan et al. beschreiben in [17] das ToolDex. Dieses spürt syntaktische und semantische Änderungen in Software-Repositories auf und ordnet diese Änderungen einer Beschreibung derÄnderung auf höherer Ebene, wie z.B. Bugs, zu.

• Softwaremetriken

Ansätze in dieser Kategorie verwenden Software-Metriken im Kontext derAnalyse von Software-Repositories. Sie bilden die zu analysierenden Reposi-tories auf skalare oder vektorielle Gröÿen ab.

◦ StatCVS: In [5] wird das Kommandozeilentool StatCVS beschrieben. Eserstellt Statistiken zu CVS-Repositories. Hierbei analysiert es verstärktdas Verhalten der am Projekt beteiligten Entwickler. Beispielsweise kön-nen die Commit-Aktivitäten pro Entwickler stundengenau dargestelltwerden.

◦ Eclipse Dash: Freeman Benson ist der Hauptentwickler des Eclipse-Plug-ins Eclipse Dash [9]. Es be�ndet sich noch in einer frühen Entwick-lungsphase. Thematisch geht es um Analysen von Softwareprojekten auf

Page 23: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

23

Codezeilenebene und um die Anzahl der dabei getätigten Commits unddie Zahl der beteiligten Entwickler.

• Visualisierung

Die Ansätze dieser Kategorie beschäftigen sich mit der visuellen Repräsenta-tion von Daten welche aus Software-Repositories stammen.

• Klon-Entdeckungsmethoden

Quellcode-Klone sind solche Code-Entitäten, die eine ähnliche textuelle, struk-turelle oder semantische Komposition besitzen. Ansätze dieses Abschnittsbeschäftigen sich mit der Suche nach solchen Klonen im Kontext der Analysevon Software-Repositories.

• Suche nach häu�g auftretenden Mustern

Ziel bei diesen Ansätzen ist es, nach Entitäten zu suchen, die sich häu�ggemeinsam ändern, weil sie gleiche Muster verwenden. Hierbei werden Item-set mining und sequential-pattern mining, also die Suche nach Inhalten, diehäu�g gemeinsam vorkommen bzw. die Suche nach sequenziell vorkommendenMustern in Entitäten, verwendet. Dies alles im Kontext der Analyse vonSoftware-Repositories.

• Methoden zur Informationswiedergewinnung

Diese Ansätze beschäftigen sich mit der Klassi�kation von Texteinheiten nachbestimmten Ähnlichkeitskonzepten. Diese Texteinheiten stellen in diesem Kon-text die Metadaten aus Versionsmanagement-Logs, textuelle Beschreibungenvon Bug-Reports und E-Mails dar.

◦ Klassi�kation nach dem Grund der Codeänderung:Mockus und Votta stellen in [14] einen Ansatz zur automatischen Klassi-�kation von Schlüsselwerten in textuellen Beschreibungen von Bugs oderCommit-Kommentaren vor. Hierbei konzentrieren sie sich auf die dreiÄnderungstypen: adaptive, corrective und perfective.

◦ Änderungsvorhersage:Auch Canfora und Cerulo nutzen in [2] textuelle Beschreibungen zuBugs und Commit-Kommentaren. Sie konzentrieren sich hierbei auf dieVorhersage von Codeänderungen. Der Ansatz ist hier der, dass die textuelleBeschreibung eines neu erstellten Bugs analysiert wird und hierzu eineMenge von Dateien geliefert wird. Diese Dateien müssen aufgrund desneuen Bugs bzw. zur Behebung des Bugs wahrscheinlich geändert wer-den.

◦ Unterstützung für neue Entwickler:Die Paper [7, 8] von Cubranic et al. stellen das Tool Hipikat vor, dasneu hinzugekommenen Entwicklern in einem schon einige Zeit beste-henden Projekt helfen, sich besser zurecht zu �nden. Es analysiert E-Mails, Quellcode und Bug-Reports und ermittelt Zusammenhänge. Diesgeschieht u.a. auch dadurch, dass Bug-Referenzen in Commit-Kommen-taren die Verbindung zum entsprechenden Bug liefern.Letztendlich steht dem neuen Entwickler eine Übersicht über die bisheri-gen Projekt-Aktivitäten zur Verfügung.

• Klassi�kation mit unterstütztem/überwachtem Lernen (Machine Learning)

Machine Learning lässt sich in der Analyse von Software-Repositories anwen-den, um Klassi�kations- und Vorhersagemodelle zu erstellen.

Page 24: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

24 KAPITEL 2. VORSTELLUNG DER BETEILIGTEN SYSTEME

• Social - Network Analyse

Diese Analysetechnik dient dazu, unsichtbare Beziehungen zwischen Personenzu ermitteln. Bei der Analyse von Software-Repositories lässt sich diese Ana-lysemethode anwenden, um Entwicklern bestimmte Rollen zuzuordnen, sowiezu ermitteln, wer in welchen Bereichen Beiträge leistet und welche Entwickler-Gemeinschaften bestehen.

Schon an dieser Stelle lässt sich sagen, dass keine der hier angesprochenen Ansätzegenau das Thema dieser Arbeit aufgreifen. Viele nutzen den Zusammenhang zwis-chen Bug-Trackern und Versionsmanagementsystemen, aber beides wird nicht imBezug auf Software-Metriken verwendet.

Nach der Vorstellung dieser Arbeit wird sie im Kapitel 8 zunächst auf Grundlageder vier oben angesprochenen Dimensionen bewertet und dann in eine der obigenKategorien eingeordnet.

Page 25: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

Kapitel 3

Anforderungsanalyse

Dieses Kapitel befasst sich mit den Anforderungen an die Software, welche im Rah-men dieser Diplomarbeit erstellt wurde. Sie realisiert die Integration von SCM-Systemen in BugzillaMetrics.

Zunächst liefert Abschnitt 3.1 einen Überblick über die grundlegenden Anforderun-gen an die Software.Der Funktionsumfang der Software orientiert sich an existierenden Analysetools, dieauf Versionsmanagementsysteme spezialisiert sind. Abschnitt 3.2 stellt einige dieserTools vor, bevor in 3.3 die daraus übernommenen Funktionen die Grundlage für dieAnforderungen an Erweiterungen im BugzillaMetrics-Kern gestellt werden.Die sich daraus ergebenden Anforderungen an die externen Schnittstellen von Bugzil-laMetrics werden im Abschnitt 3.4 vorgestellt.

3.1 Grundlegende Anforderungen

Der Funktionsumfang von BugzillaMetrics ohne die hier besprochene SCM-Integra-tion deckt Metrikberechnungen auf Grundlage des Datenbestandes von Bugzilla ab.Hier ist es also möglich, Metriken rund um Change Requests zu spezi�zieren undvon BugzillaMetrics berechnen zu lassen.

Analysetools, die sich auf die Berechnung von Metriken auf Grundlage der Daten-bestände von Versionsmanagementsystemen konzentrieren, können dies folglich nicht.Sie liefern die Funktionalität, Metriken rund um Objekte zu berechnen, die von Ver-sionsmanagementsystemen verwaltet werden.

Durch die Integration von SCMBug ist es nun möglich, beide Welten zu verbinden.Theoretisch könnten nun Metriken spezi�ziert werden, die Eigenschaften von ChangeRequests, von Objekten aus Versionsmanagementsystemen oder aber auch Eigen-schaften, die sich aus der Integration beider Welten ergeben, auf eine skalare Gröÿeabbilden.

Die Frage, die nun in diesem Kapitel zu beantworten ist, lautet: Welche Funktion-alitäten von Versionsmanagement-Analysetools können sinnvoll in das zunächst nurvon Change Requests geprägte Design von BugzillaMetrics integriert werden?

Analysefunktionen, die zwar isoliert für Versionsmanagementsysteme ihre Berech-tigung haben, passen möglicherweise nicht in das Konzept von BugzillaMetrics, dasie sich nicht in einer Zeitreihe darstellen lassen. Ein Beispiel hierzu wäre die Fragenach Dateien, Verzeichnissen oder auch Entwicklern, die besondere Eigenschaftenhaben. Die Frage nach dem aktivsten Entwickler ist zwar interessant, lässt sich abernur schlecht in einer Zeitreihe darstellen.

25

Page 26: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

26 KAPITEL 3. ANFORDERUNGSANALYSE

Ein anderer Punkt ist der Bezug zu Change Requests. Die Berechnung der zykloma-tischen Zahl zu einer Methode ist zwar interessant, aber mit Blick auf die Integrationmit Change Requests ist die Bestimmung dieses Wertes von nachrangiger Bedeu-tung. Es muss also eine Menge von Funktionen gewählt werden, die von Bugzil-laMetrics berechnenbar ist und sich gut für Metrikspezi�kationen eignet, die imHinblick auf die Integration erstellt werden.

Zur Zielgruppe der Software ist zu sagen, dass sie sich prinzipiell an alle Soft-wareentwickler und Projektleiter richtet, die daran interessiert sind, sehr �exibleMetrikberechnungen bezogen auf zusammenhängende Daten von Bug-Trackern undVersionsmanagementsystemen durchzuführen.

Die meisten Anwender der Integration sind wahrscheinlich schon mit BugzillaMet-rics vertraut und möchten sich nicht an grundsätzlich neue Aspekte bei der Spezi-�kation von Metriken gewöhnen. Deshalb sollte sich die Integration möglichst naht-los in die bestehende Software einfügen.

Die wesentliche Voraussetzung für die Funktionstüchtigkeit der SCM-Integration istdie Verwendung aller in der Einleitung beschriebenen Komponenten, also besondersBugzilla, CVS oder Subversion und SCMBug.

3.1.1 Funktionale Anforderungen

Diese Anforderungsanalyse orientiert sich an bestehenden Versionsmanagement--Analysetools, die in 3.2 vorgestellt werden.

Allgemein muss die SCM-Integration die Daten aus dem verwendeten SCM-Reposi-tory dem Berechnungsalgorithmus von BugzillaMetrics zur Verfügung stellen kön-nen. Auÿerdem muss BugzillaMetrics so erweitert werden, dass spezi�sche Frage-stellungen zu SCM-Systemen in Form von Metrikspezi�kationen ausdrückbar sind.

3.1.2 Nicht-funktionale Anforderungen

Bugzilla ist in Java geschrieben und läuft als Web-Applikation, kann also auf vielenPlattformen eingesetzt werden. Für die SCM-Integration soll gleiches gelten, alsoeine möglichst weitgehende Betriebssystemunabhängigkeit bestehen.

Das schon existierende Test-Framework von BugzillaMetrics sichert die Qualität derSoftware. Damit die Qualität auch für die Erweiterung sichergestellt werden kann,muss das Framework erweitert werden.

Zusätzlich gelten allgemeine Anforderungen, die nicht nur speziell an diese Soft-ware gestellt werden. Darunter fällt die Beachtung bekannter Entwurfsprinzipien,wie beispielsweise Modularisierung, Kapselung oder Separation of Concerns. Diesewerden hier nicht näher erläutert.

3.2 Funktionsumfang existierender Werkzeuge

Die Entwicklung der SCM-Integration stützt sich nicht auf konkrete Anforderun-gen eines Kunden, der die Software zu einem bestimmten Zweck einsetzen möchte.Es geht vielmehr um die Frage der prinzipiellen Realisierbarkeit einer solchen In-tegration. Trotzdem soll die Software einen Funktionsumfang haben, der möglichstvielen Nutzern sinnvolle Anwendungsmöglichkeiten bietet. Aus diesem Grund stütztsich die Anforderungsanalyse auf die existierenden Metrikwerkzeuge StatCVS undEclipse Dash. Diese konzentrieren sich ausschlieÿlich auf Versionsmanagementsys-teme, lassen also die in dieser Arbeit betrachteten Zusammenhänge mit dem Kon-

Page 27: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

27

�gurationsmanagement auÿen vor. Nach einer kurzen Vorstellung der Tools liefertdie Tabelle (3.1) einen Überblick über den Funktionsumfang der beiden Tools.

StatCVS ist ein Kommandozeilen-Statistikwerkzeug für CVS Repositories.Es liefert diverse Arten gra�scher Statistiken, wie Balkendiagramme, Graphen,Tabellen oder Baumstrukturen. Im Vergleich zu Eclipse Dash analysiert es ver-stärkt das Verhalten der am Projekt beteiligten Entwickler. Es ist z.B. möglich,die bevorzugten Arbeitszeiten oder die Gewohnheiten der Entwickler bezüglichCommit-Häu�gkeit zu analysieren. Auÿerdem liefert es viele Statistiken auf Datei-und Verzeichnisebene. Weitere Informationen können unter [5] gefunden werden.

Eclipse Dash ist ein Plugin für die Entwicklungsumgebung Eclipse.

Die Zielgruppe lautet: �Tools for Committers and members� [9]. Das Plugin konzen-triert sich hauptsächlich auf die Anzahl von Commits und Entwicklern und analysiertDateien auf Codezeilenebene.

Beide Tools setzen also Schwerpunkte, besitzen jedoch auch gemeinsame Aspek-te. Alle Aspekte kann man den Kategorien Commits, Dateien, Entwickler, Kom-mentare, LOCs und Verzeichnisse zuordnen. Die Tabelle (3.1) stellt die Funktionenbeider Tools zusammen.

Kategorie Gesichtspunkt zur Kategorie StatCVS

Eclipse

Dash

Commits Verhältnis: Korrektur- und Erweiterungscommits√

Entwicklungsaktivität nach Tageszeit√

Entwicklungsaktivität nach Wochentag√

Anzahl aller Commits√

Anzahl an Commits pro Entwickler√

Dateien Durchschnittliche Dateigröÿe (allgemein)√

Anzahl an Dateien√

Dateitypen√

Gröÿenanteil von Dateitypen im Projekt√

Durchschnittliche Dateigröÿe (typenbezogen)√

gröÿte Datei√

Datei mit den meisten Revisionen√

Entwickler Anzahl Entwickler√ √

Arbeitsanteil eines Entwicklers√

Entwickler mit dem meisten Arbeitsanteil√

aktivster Entwickler√

(in)aktive Entwickler√

Kommentare Anzahl Kommentare√

Anzahl Kommentatoren√

LOC Codezeilen√ √

Anteil der geänderten LOC√ √

Durchschnittliche LOC pro Commit√

Anteil eines Entwicklers an den geänderten LOC√

Verzeichnisse Ordnergröÿe√

Ordneränderungen√

Tabelle 3.1: Funktionsumfang: StatCVS und Eclipse Dash

Page 28: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

28 KAPITEL 3. ANFORDERUNGSANALYSE

Genau wie Eclipse Dash und StatCVS wird auch die SCM-Integration Schwerpunktesetzen müssen. Durch die Verbindung mit Bugs auf der einen Seite und die weniger�exible Ergebnisausgabe von BugzillaMetrics in Form von Graphen auf der anderenSeite ergeben sich Einschränkungen. Diese werden im Abschnitt (3.3) auf Grundlageder hier zusammengestellten Funktionen erläutert.

3.3 Erweiterungen in BugzillaMetrics

3.3.1 Funktionale Anforderungen

Die in Abschnitt (3.2) zusammengestellten Funktionen bilden nun die Grundlagefür die Überlegung, welche Möglichkeiten BugzillaMetrics bezogen auf den Datenbe-stand von SCM-Systemen bieten soll. Allgemein ist zu bedenken, dass sich alleBerechnungen in BugzillaMetrics auf Cases beziehen. Es ist also nicht möglich, einebestimmte Datei, einen Entwickler oder ein Verzeichnis isoliert zu betrachten.

Die Integration von SCMBug ordnet einem Commit genau einen Bug in Bugzilla,also einen Case in BugzillaMetrics zu. Entsprechend kann der Entwickler, welchereinen Commit absetzt, mit dem entsprechenden Case assoziiert werden. Er ist indiesem Fall ein im Case aktiver Entwickler. Analog verhält es sich bei Dateien,Verzeichnissen, Branches und Tags. Sie sind alle von einem Case betro�en, wenn siein einem Commit enthalten sind, der diesem Case zugeordnet wurde.

Man kann Cases also dahingehend �ltern, dass nur diejenigen betrachtet werden, indenen eine bestimmte Datei bzw. ein bestimmtes Verzeichnis betro�en ist oder indenen ein bestimmter Entwickler aktiv ist.

Die sich aus einem Commit ergebenden Aktivitäten in Objekten, wie z.B. Datei-änderungen, können als Events in den Cases, von denen sie betro�en sind, inter-pretiert werden. Demnach sind alle möglichen Aktivitäten in einer SCM-RepositoryEvents in BugzillaMetrics.

Die Attribute der Objekte, wie z.B. Codezeilen einer Datei oder Anzahl der Unter-verzeichnisse in einem Verzeichnis, lassen sich in vielen Fällen auf eine skalare Gröÿeabbilden und auch als Funktionswerte in einer Zeitreihe verwenden. Sie sind alsofür die Gewichtung von Events geeignet. In den Fällen, in denen dies nicht möglichist, wie z.B. bei einem Branch-Namen, können sie möglicherweise zur Filterung vonCases eingesetzt werden.

Die Funktionalität der oben genannten Analysetools lässt sich also auf drei derKernbestandteile von BugzillaMetrics abbilden:

1. BaseFilter: Cases können nach Attributen von SCM-Objekten ge�ltert wer-den, die vom Case betro�en sind oder die im Case aktiv sind.

2. Events: Aktivitäten in einer Repository sind über die SCMBug-Integrationbestimmten Cases zugeordnet. In BugzillaMetrics stellen sie also Events dar.

3. Weights: Viele Attribute von SCM-Objekten, die von Aktivitäten in der SCM-Repository beein�usst werden, können für die Gewichtung von Events verwen-det werden.

Anhand dieser Punkte werden nun die nötigen Erweiterungen zusammengestellt,welche die Berechnung der in Tabelle (3.2) aufgelisteten Gesichtspunkte ermöglichen.

Page 29: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

29

3.3.1.1 BaseFilter

Es bieten sich Suchschlüssel an, die direkt eine Menge von Cases identi�zieren kön-nen:

• Developer: Filtert alle Cases heraus, in denen der gesuchte Entwickler aktivist. Da der Nutzer der Integration sowohl die Bugzilla- als auch die SCM-Entwicklernamen in Betracht ziehen könnte, muss es möglich sein, sowohlnach dem Namen eines Entwicklers im SCM-System als auch unter Bugzillazu suchen. Entsprechend muss es die Filter bugzillaDeveloper und scm-

Developer geben.Diese beiden Filter ermöglichen Selektionen, welche für die Fragestellungender Kategorie Entwickler nötig sind.

• filetype: Filtert alle Cases heraus, die mindestens eine Datei betre�en, welcheden gesuchten Typ besitzt. Der Filter bietet sich in den Kategorien Datei undLOC an.

• file: Filtert alle Cases heraus, welche die gesuchte Datei betre�en. Auchdieser Filter passt in die Kategorien Datei und LOC.

• folder: Filtert alle Cases heraus, welche das gesuchte Verzeichnis selbst be-tre�en oder mindestens eine Datei betre�en, die sich im gesuchten Verzeichnisbe�ndet. Der Verzeichnis�lter ist in der Kategorie Verzeichnisse verwendbar.

• revisionID: Filtert alle Cases heraus, die während des Commits, welcher zurgesuchten Revision gehört, referenziert wurden. Um in der Kategorie Commitsbestimmte Revisionen betrachten zu können, ist dieser Filter sinnvoll.

Die unter Punkt zwei geforderten Events legen die Betrachtung von Branches undTags nahe. Dadurch sind entsprechende Filter nützlich:

• branch: Filtert alle Cases heraus, die eine Datei oder einen Ordner betre�en,die / der zum gesuchten Branch gehört.

• tag: Filtert alle Cases heraus, die eine Datei oder einen Ordner betre�en, die/ der zum gesuchten Tag gehört.

3.3.1.2 Events

Betrachtet man Aktivitäten im SCM-System, die sich auf einen Case beziehen,sind das diejenigen, die im Rahmen eines Commits ausgeführt werden. Commitsbeinhalten immer Aktivitäten zu Dateien, Verzeichnissen, Branches und Tags. Diesimpliziert für den zweiten Punkt die Verwendung folgender Events:

• Event zum Commit selbst: RevisionEvent

• Events zu Dateien: FileCreationEvent, FileChangeEvent, FileRenameEvent,FileMoveEvent, FileRemoveEvent

• Events zu Verzeichnissen: FolderCreationEvent, FolderChangeEvent, Folder-RenameEvent, FolderMoveEvent, FolderRemoveEvent

• Events zu Branches: BranchCreationEvent, BranchRemoveEvent

• Events zu Tags: TagCreationEvent, TagRemoveEvent

Page 30: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

30 KAPITEL 3. ANFORDERUNGSANALYSE

3.3.1.3 Weights

Die im dritten Punkt angesprochenen Weights ermöglichen es nun, viele der inTabelle (3.1) aufgelisteten Gesichtspunkte zu realisieren.

Sie greifen diejenigen Objektattribute auf, die als Funktionswert der Zeitreihe ver-wendbar sind und von einem der oben vorgestellten Events beein�usst werden. Des-halb sind sie nach Event-Typen sortiert.

Weights zu RevisionEvents

• default: Das schon existierende Weight default liefert die Konstante 1 fürjeden Event zurück. Sie ermöglicht die Berechnung der folgenden Gesichts-punkte:

◦ Anzahl aller Commits

◦ in Kombination mit der Granularität der Zeit, welche in der Metrik-spezi�kation de�niert werden kann: Entwicklungsaktivität nach Wochen-tag und Tageszeit

◦ in Kombination mit dem BaseFilter developer: Anzahl an Commits proEntwickler

• numberOfFolderEvents: Events gehören immer zu einem Commit. DiesesWeight liefert die Anzahl der Events, die zur Revision gehören und sichauf Verzeichnisse auswirken. Dies ermöglicht die Berechnung von Ordner-änderungen.

Neben Aktivitäten in Verzeichnissen, deren Analyse durch numberOfFolderEvents

über den Gesichtspunkt Ordneränderungen angeregt wurden, bieten sich zu denBereichen Branch, Tag und File weitere Weights dieser Art an:

• numberOfBranchEvents: Dieses Weight liefert die Anzahl der Events, die zurRevision gehören und sich auf Branches auswirken.

• numberOfFileEvents: Dieses Weight liefert die Anzahl der Events, die zurRevision gehören und sich auf Dateien auswirken.

• numberOfTagEvents: Dieses Weight liefert die Anzahl der Events, die zurRevision gehören und sich auf Tags auswirken.

Weights zu FileEvents

• default / numberOfFiles1: Diese beiden Weights liefern für jede Datei, diezu einem File Event gehört, eine Konstante 1. Dies ermöglicht es, die Dateian-zahl zu bestimmen.

• loc: Dieses Weight berechnet die Anzahl der Codezeilen einer Datei.

Da Versionsmanagementsysteme mit Hilfe der Di�-Funktion nicht nur die Anzahl,sondern auch die Eigenschaften der Codezeilen in Bezug auf die durchgeführten Än-derungen darstellen können, bieten sich zusätzlich folgende Spezialfälle des Weightsloc an:

1Man beachte, dass Weights für bestimmte Event - Arten zu grobgranular sein können. ImExtremfall macht es überhaupt keinen Sinn, ein Weight in Verbindung mit einer Event-Art zuverwenden. Die Tabelle 3.2 stellt alle Kombinationsmöglichkeiten zusammen.

Page 31: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

31

• changedLoc: Dieses Weight berechnet die Anzahl der Lines of Code einerDatei, die sich seit dem letzten Event (der vorigen Revision) inhaltlich geän-dert haben. Es ermöglicht die Bestimmung von:

◦ Anteil der geänderten LOC

◦ Anteil eines Entwicklers an den geänderten LOC

• addedLoc: Dieses Weight berechnet die Anzahl der Lines of Code einer Datei,die seit dem letzten Event (der vorigen Revision) hinzugekommen sind.

• deletedLoc: Dieses Weight berechnet die Anzahl der Lines of Code einerDatei, die seit dem letzten Event (der vorigen Revision) gelöscht wurden.

Nicht nur die Eigenschaften im Bezug auf die durchgeführten Änderungen sind er-mittelbar, sondern auch die Anzahl der Entwickler, die etwas zu einer Datei beige-tragen haben.

• numberOfDevelopers: Berechnet die Anzahl der Entwickler, die mindestenseine Codezeile zur Datei beigetragen haben.

Weights zu FolderEvents

• numberOfFiles: Eine Aktivität innerhalb eines Verzeichnisses kann sich durchHinzufügen oder Löschen von Dateien ergeben. Mit diesem und dem nächstenEvent kann die Gröÿe eines Ordners ermittelt werden.

• numberOfSubfolder: Eine andere Möglichkeit für eine Verzeichnis-Aktivitätbildet das Hinzufügen oder Löschen von Unterverzeichnissen.

• numberOfFiletypes: Dieses Weight berechnet die Anzahl der verschiedenenDateitypen, die sich zum Eventzeitpunkt im Ordner be�nden. Hiermit kannfolgendes ermittelt werden:

◦ Dateitypen

◦ Gröÿenanteil von Dateitypen im Projekt

Aufgrund der Kombinationsmöglichkeiten von BaseFiltern, Events und Weights

in Metrikspezi�kationen, ergeben sich aus den bis hier geforderten Erweiterungenviele zusätzliche Berechnungsmöglichkeiten. Die Tabelle (3.2) liefert hierzu einenÜberblick. Sie grenzt insbesondere die sinnvollen von den zwar möglichen, aberunsinnigen Kombinationen ab.

Ein N besagt, dass das Weight für den Event-Typ einen Wert aus den natürlichenZahlen berechnet. Eine 0 oder 1 markiert eine konstante Funktion, wobei Nullendarauf hinweisen, dass die Kombination von Event und Weight keine sinnvollenErgebnisse liefern kann. Der Rückgabewert ist immer 0. Die 1 weist auf trivialeBerechnungen hin, wie z.B. die logische Tatsache, dass bei einem FileChangeEventeine Datei betro�en ist. Hier ist der Rückgabewert immer 1.

Neben den funktionalen Anforderungen an die Erweiterungen im BugzillaMetrics-Kern gibt es einen zweiten wesentlichen Bereich in der SCM-Integration: Der Daten-import vom Versionsmanagementsystem.

Hier stellt sich die Frage, wie dieser realisiert werden soll. Es gibt prinzipiell zweiMöglichkeiten:

• Ein Import vor jeder Metrikberechnung.

• Regelmäÿige manuelle Importvorgänge unabhängig vom BugzillaMetrics-Kern.

Die Antwort darauf ergibt sich aus einer nicht-funktionalen Anforderung:

Page 32: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

32 KAPITEL 3. ANFORDERUNGSANALYSE

Event / Weight Default

LOC

addedL

OC

changedL

OC

deletedL

OC

numberOfDevelopers

numberOfFiles

numberOfFiletypes

numberOfSubfolder

numberOfFileEvents

numberOfFolderEvents

numberOfBranchE

vents

numberOfTagEvents

RevisionEvent N 0 0 0 0 1 0 0 0 N N N NFileCreation N N N 0 0 N 1 1 0 1 0 0 0FileChange N N N N N N 1 1 0 1 0 0 0FileRename N N 0 0 0 N 1 1 0 1 0 0 0FileMove N N 0 0 0 N 1 1 0 1 0 0 0FileRemove N N 0 0 0 N 1 1 0 1 0 0 0

FolderCreation N 0 0 0 0 0 0 N N 0 1 0 0FolderChange N 0 0 0 0 0 N N N 0 1 0 0FolderRename N 0 0 0 0 0 N N N 0 1 0 0FolderMove N 0 0 0 0 0 N N N 0 1 0 0FolderRemove N 0 0 0 0 0 0 N N 0 1 0 0

BranchCreation N 0 0 0 0 0 0 0 0 0 0 1 0BranchRemove N 0 0 0 0 0 0 0 0 0 0 1 0

TagCreation N 0 0 0 0 0 0 0 0 0 0 0 1TagRemove N 0 0 0 0 0 0 0 0 0 0 0 1

Tabelle 3.2: Überblick über die sinnvollen Kombinationen für SCM-Metrikspezi�kationen

3.3.1.4 E�zienz: Zeitverhalten

Die in [10] de�nierte maximale Berechnungsdauer einer Metrik von einer Minutesoll auch von der SCM-Integration eingehalten werden.Die vollständige Analyse einer gröÿeren SCM-Repository (beispielsweise: 1000 Da-teien unter Versionskontrolle) kann unmöglich in einer Minute durchgeführt werden.Aus diesem Grund muss die Analyse von der Metrikberechnung getrennt werden.

Es muss also eine unabhängige Importkomponente geben, die alle vom Kern be-nötigten Daten vom verwendeten SCM-System importiert und für die o.g. An-forderungen im Kern verarbeitet und speichert.Um eine einheitliche Datenbasis in BugzillaMetrics zu scha�en, sollte die Importkom-ponente die eingelesenen Daten analog zur Datenbasis von Bugzilla in der MySQL-Datenbank bugzilla ebenfalls in einer MySQL-Datenbank speichern.

Die konkreten Anforderungen an die Importkomponente hängen einerseits von denspeziellen Versionsmanagementsystemen und andererseits von der Datenbankstruk-tur ab. Aus diesem Grund wird die Anforderungsanalyse zur Importkomponentezusammen mit deren Designbeschreibung erst im Kapitel 6 vorgestellt und zuvorim Kapitel 4 zum Datenbankentwurf die Datenbankstruktur beschrieben.

3.3.1.5 BugzillaMetrics Frontend

Die von der SCM-Integration zur Verfügung gestellte Funktionalität muss ins Front-end integriert werden.

Page 33: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

33

Hier muss es eine Möglichkeit geben, die SCM-Funktionen einzubinden und auchwieder zu entfernen, je nach dem, ob der Anwender die Integration nutzt oder nicht.

3.3.2 Nicht-funktionale Anforderungen

Nun zu den nicht-funktionalen Anforderungen an die Erweiterungen im Bugzilla-Metrics-Kern.Die SCM-Integration soll kein fester Bestandteil der Software sein, sondern einenErweiterungspunkt darstellen. Dies impliziert diverse Anforderungen an die Ar-chitektur:

• Keine Änderungen an der Architektur im Kern: Der Berechnungsalgorithmusund die Art der Datenrepräsentation im Kern soll nicht geändert werden. Diehat zur Folge, dass der Kern lediglich eine breitere Palette an Datenstrukturenzur Verfügung haben soll. Von der Herkunft der Daten soll abstrahiert werdenund auch die Bearbeitung dieser Daten soll möglichst unabhängig davon sein,ob es sich um Daten aus Bugzilla, CVS oder Subversion handelt.

• Unabhängigkeit des Kerns (lose Kopplung): Es muss möglich sein, Bugzilla-Metrics ohne SCM-Integration zu verwenden.

• Einbindung durch Unterklassenbildung und Implementierung von Interfaces:Die Realisierung des Erweiterungspunktes innerhalb des Kerns soll durchUnterklassen und Interfaces umgesetzt werden.

• Verwendung separater Quellcode-Pakete: Hierdurch soll auch eine Trennungdes Codes der SCM-Integration vom Quellcode des Kerns erreicht werden. EinNutzer von BugzillaMetrics, der nicht an der SCM-Integration interessiert ist,installiert nur die Core-Pakete. Ansonsten installiert er auch die Pakete zurIntegration.

• Erweiterung des Frontends in Form von Kon�gurationsdateien: Abhängig da-von, ob die Integration verwendet wird oder nicht, muss die zusätzliche Funk-tionalität dem Nutzer im Frontend angeboten werden oder nicht. Dies solldurch angepasste Kon�gurationsdateien geschehen, die alternativ verwendbarsind. Beispielsweise also eine Dateiversion mit und eine Version ohne SCM-Funktionalität.

3.4 SCM-Integration von BugzillaMetrics im Kon-text der beteiligten Systeme

Die SCM-Integration in BugzillaMetrics, also das Thema dieser Diplomarbeit, fügtsich in das in Abschnitt 2.5 angesprochene Schema wie in Abbildung 3.1 ein.

Die Integrationskomponente ist Teil von BugzillaMetrics und beinhaltet zwei Teil-komponenten:

1. Erweiterungen des BugzillaMetrics-Kerns.

2. Komponente, die für den Import von SCM-Daten zuständig ist.

Folgende Anforderungen ergeben sich bzgl. Systemschnittstellen:Die Schnittstelle zwischen SCM-Integration und SCM-System bildet dessen Mengevon Kommandozeilenbefehlen. Darüber hinaus greift die Integrationskomponenteauf die Namens-Match-Funktion von SCMBug zu und verwendet die Datenbankscm. Hier benötigt sie Lese- und Schreibzugri�srechte.

Page 34: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

34 KAPITEL 3. ANFORDERUNGSANALYSE

Abbildung 3.1: Die SCM-Integration im Kontext der beteiligten Softwaresysteme

Page 35: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

Kapitel 4

Datenbankentwurf

Falls die SCM-Integration verwendet wird, greift BugzillaMetrics zusätzlich zurBugzilla-Datenbank auch auf die Daten zu, welche aus einem Versionsmanagement-system importiert wurden. Diese stehen in der SCM-Datenbank zur Verfügung.Zunächst werden die funktionalen Anforderungen an diese Datenbank vorgestellt.Im Anschluss folgt die Beschreibung der Objekte, welche gespeichert werden müssenund das sich daraus ergebende Design.

4.1 Anforderungsanalyse

Da die SCM-Datenbank eine Schnittstelle zwischen dem BugzillaMetrics-Kern undverschiedenen SCM-Systemen darstellt, muss sie den Anforderungen beider Seitengerecht werden. Einerseits muss die Datenbankstruktur so bescha�en sein, dass beimLaden der Daten in den Kern nur wenige Tabellen-Joins erforderlich sind. Die Struk-tur muss also mit der Datenstruktur im BugzillaMetrics-Berechnungskern kompati-bel sein. Auf der anderen Seite steht die Struktur der Quelldaten vom SCM-System.Auch hier muss eine möglichst einfache Abbildung von der Quelldatenstruktur in dieDatenbankstruktur gefunden werden, damit die Abbildung durch die Importkom-ponente e�zient realisiert werden kann.

SCM-Systeme verwalten Objekte, wie z.B. Dateien und Ordner, und sichern durchdie Änderungshistorie diverse Aktivitäten auf diesen Objekten.Gleiche Begri�e haben aber bei verschiedenen SCM-Systemen mitunter verschiedeneFunktionen. Beispielsweise sind Tags unter SVN strukturell das gleiche wie Branchesund Trunk. Sie sind normale Ordner in der Repository. Allgemein kann der Adminis-trator einer SVN-Repository auch völlig andere Namen und Bedeutungen festlegen.Bei CVS sind Tags immer Markierungen für Dateien.Ordner werden mit SVN unter Versionskontrolle gestellt, bei CVS gilt dies nicht.

Da eine Erweiterung von BugzillaMetrics um neue SCM-Systeme denkbar ist, mussdie Datenbankstruktur nicht nur von CVS und SVN abstrahieren können, sondernauch die Unterstützung diverser anderer SCM-Systeme möglichst leicht umsetzbarmachen.

Der Berechnungskern von BugzillaMetrics kennt alle diese Objekte und Unterschiedenicht. Hier gibt es nur BaseFilter, Events und Event-Weights. Mit diesen dreiKomponenten müssen also alle SCM-Informationen, die sich zur Berechnung vonMetriken eignen, modelliert werden.

Neben den Anforderungen von BugzillaMetrics und SCM-Systemen gibt es nochweitere Anforderungen:

35

Page 36: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

36 KAPITEL 4. DATENBANKENTWURF

• Funktionale Anforderungen:

◦ Nachvollziehbarkeit:Es gehört zum normalen Entwicklungsprozess, dass Dateien und Ordnerwährend ihrer Entwicklungsgeschichte hinzugefügt, verschoben, umbe-nannt oder gelöscht werden. Diese Veränderung ist bei vielen Metrik-berechnungen ein wichtiger Bestandteil und darf nicht verloren gehen.

• Nicht-funktionale Anforderungen:

◦ Testbarkeit:Das Core - Test-Framework muss beim Setup neben der Bugzilla- auchdie SCM-Datenbank befüllen. Dies soll auf Grundlage einer Kon�gura-tionsdatei geschehen. Diese Datei kann nur dann übersichtlich und fürandere Tester nachvollziehbar aufgebaut sein, wenn die Datenbankstruk-tur diese beiden Kriterien erfüllt.

◦ Erweiterbarkeit:Im Rahmen dieser Arbeit kann aus Zeitgründen nur ein Teil des Infor-mationsgehalts einer SCM-Repository genutzt werden. Es ist also denkbar,dass in Zukunft Metrikberechnungen zu anderen Aktivitäten und Objek-ten interessant werden. Die dazu erforderliche Erweiterung der Daten-bank sollte keine grundlegende Neugestaltung der Struktur erzwingen.

4.1.1 Begri�snetz

In einer SCM-Repository gibt es eine Vielzahl an Begri�en, die zum einem starkmiteinander und zum anderen mit Begri�en anderer Systeme, wie z.B. Bugzilla,verknüpft sind. Das Begri�snetz in Abbildung 4.1 beinhaltet diejenigen Begri�e,welche in dieser Arbeit relevant sind. Die Begri�e und besonders deren Verknüpf-ungen dienen als Grundlage für das Design der Datenbank.

In der Mitte der Abbildung be�nden sich die in der Anforderungsanalyse für die Er-weiterungen von BugzillaMetrics schon für BaseFilter verwendeten SCM-Reposi-tory Objekte Datei, Verzeichnis, Branch und Tag wieder. Die linke Seite stellt dieBegri�ichkeiten von Versionsmanagementsystemen auf einer höheren Ebene, wieRepository und Projekt, zusammen.Die rechte Seite beschreibt die SCM-Aktivitäten, die hier nach den Objekten sortiertsind, welche von den Aktivitäten manipuliert werden. Sie entsprechen den im vorigenKapitel vorgestellten Events.Im oberen Teil be�ndet sich die Verbindung zwischen Versionsmanagement undBug-Trackern über Commits und die am System beteiligten Personen. Dies sindEntwickler und Anwender.Innerhalb der Begri�s-Objekte be�nden sich diejenigen Attribute der zugehörigenObjekte, welche für die Weights und BaseFilter benötigt werden.

Insgesamt sind also alle Kernkomponeneten, die für die Erweiterung von Bugzilla-Metrics benötigt werden, in diesem Begri�snetz enthalten. Das folgende Designder Datenbankstruktur muss nun also diese Komponenten so aufnehmen, dass dieoben gestellten allgemeinen Anforderungen erfüllt werden und die Zusammenhängezwischen den Begri�en explizit bleiben.

Page 37: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

37

Abbildung 4.1: Begri�snetz zu SCM-Systemen und deren Umfeld

Page 38: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

38 KAPITEL 4. DATENBANKENTWURF

4.2 Design

Wenn man untersucht, an welcher der drei Kernkomponenten BaseFilter, Eventund Weights sich die Struktur der Datenbank orientieren soll, wird schnell klar, dassdies Events sein müssen. Sie stellen die Verbindung zwischen Cases und den SCM-Objekten her, in denen die Attribute stehen, welche für Weights und BaseFilterbenötigt werden.

Innerhalb der Events gibt es ebenfalls eine Rangfolge. Alle Datei-, Verzeichnis-,Branch- und Tag-Events werden im Rahmen eines RevisionEvents ausgeführt. Zuder Revision gibt es allgemeine Attribute, wie Revisionsnummer und Kommentarzum Commit, die auch für die darin enthaltenen Aktivitäten gelten. Beispielsweisebezieht sich ein Commit-Kommentar unter anderem auch auf eine Dateiänderungs-Aktivität, die zum Commit gehört.

Die Datei-, Verzeichnis-, Branch- und Tag-Events beein�ussen selbst wieder spezielleAttribute von Dateien, Tags und so weiter. Da sich diese Attribute, wie z.B. geän-derte Codezeilen in einer Datei, von Revision zu Revision ändern können, ist essinnvoller, diese Werte zusammen mit der Aktivität zu sichern und nur diejenigenAttribute zusammen mit dem Objekt selbst zu sichern, die revisionsinvariant sind.

Es ergibt sich also eine Baumstruktur aus Aktivitäts-Tabellen, wobei die Tabelle mitRevisions-Aktivitäten die Wurzel des Baums darstellt. Alle revisionsvarianten Ob-jektattribute werden zusammen mit den jeweiligen Aktivitäten im Tabellen-Baumgespeichert. Die Repräsentation der SCM-Objekte, welche von den Aktivitätenmanipuliert werden, erfolgt in separaten Tabellen. Die sich aus dem Begri�snetzergebenden Referenzen werden in entsprechenden Tabellenspalten explizit gesetzt.

4.2.1 Datenbankstruktur

Aus den Überlegungen ergeben sich nun die folgenden Tabellen:

4.2.1.1 SCM_Revision_Activity_History

Die �Wurzeltabelle� heiÿt SCM_Revision_Activity_History und besitzt folgendeSpalten:

• Bezeichnung der Revision / des Commits.

• Referenz zum Entwickler, welcher die Revision erstellt hat.

• Typ der ausgeführten Aktivität und Referenz zu entsprechenden Aktivitäts-tabelle.

• Zeitpunkt des Commits.

• Kommentar zum Commit.

• Referenz zur zugehörigen Bug-Nummer aus Bugzilla.

In der SCM_Revision_Activity_History liegen also diejenigen Informationen, welchejede Aktivitätsausprägung aufweist. Es sind im Grunde Detailinformationen zumCommit, innerhalb dessen die beschriebene Aktivität in die Repository des SCM-Systems aufgenommen wird.Jeder Eintrag beschreibt genau eine Aktivität. Deshalb gehören zu jedem Commitn Einträge in dieser Tabelle, wobei n die Anzahl der Operationen darstellt, welcheder Entwickler in seiner lokalen Arbeitskopie durchgeführt und mit dem Commit

Page 39: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

39

verö�entlicht hat.In dieser Tabelle liegt einer von zwei Verknüpfungspunkten zwischen SCM-Systemenund Bugzilla: Die Referenz von einem Commit zum zugehörigen Bug in Bugzilla.Eine separate Abfrage dieser Tabelle ist für Metrikberechnungen verwendbar, dienach Revision-Events �ltern.

Eine Baumebene tiefer liegen die Aktivitätstabellen, in denen sich objektspezi�scheInformationen be�nden. Die Trennung erfolgt also nicht nach Auswirkung der Ak-tivität, wie beispielsweise ADD oder REMOVE, sondern nach dem Objekttyp, dermanipuliert wird. Es gibt vier Aktivitätstabellen:

4.2.1.2 BranchActivity, TagActivity

Diese beiden Tabellen sind ähnlich aufgebaut und enthalten neben der ID:

• Typ der Aktivitätsausprägung (Codiert in einer Zi�er)

• Referenz zum Branch bzw. Tag

Ob es sich bei einer Aktivität um das Hinzufügen oder Entfernen eines Branches /Tags handelt, ist also anhand der Zi�er erkennbar.

4.2.1.3 FileActivity

Hier existieren folgende Spalten:

• ID

• Typ der Aktivitätsausprägung (Codiert in einer Zi�er)

• Referenz zur Datei

• Anzahl der Codezeilen

• Referenz zum Entwickler, der mindestens eine Codezeile zur Datei beiträgt.

• Anzahl der Codezeilen, die vom Entwickler stammen.

• Anzahl der vom Entwickler in der aktuellen Aktivität ...

◦ hinzugefügten

◦ entfernten

◦ geänderten

Codezeilen.

• Referenz zur Vorgängerdatei

Analog zur Branch- und TagActivity beschreibt die Codezi�er den Typ der Aktivi-tätsauswirkung für die verlinkte Datei.An einer Datei können mehrere Entwickler beteiligt sein. Aus diesem Grund gibtes für n aktive Entwickler an Datei d auch n Einträge zu d. Die Anzahl der bei-gesteuerten Codezeilen ist also für jeden dieser Einträge mindestens 1, da ein Ent-wickler, der keine Codezeile beigesteuert hat, für die Datei nicht relevant ist. Dieaktuell hinzugefügten, gelöschten oder geänderten Codezeilen sind allerdings nur fürmaximal einen Eintrag pro Aktivität gröÿer als 0. Der mit einem solchen Eintrag

Page 40: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

40 KAPITEL 4. DATENBANKENTWURF

verlinkte Entwickler ist derjenige, welcher die Aktivität durchgeführt hat.Es gibt unter anderem die beiden Aktivitäten MOVE und RENAME, welche dieeigentlich über Revisionsnummern hinweg unveränderlichen Attribute einer Dateiändern. Anstatt diese anzupassen, bleibt der Eintrag, der zur Datei mit den altenAttributwerten gehört, bestehen und es kommt ein weiterer Eintrag mit den neuenAttributwerten hinzu. Um nun die Zusammengehörigkeit zwischen diesen Einträgen,die noch immer die selbe Datei beschreiben, nicht zu verlieren, wird der alte Eintragmit der zugehörigen Aktivität verlinkt.

Designbegründung: Mehrere Einträge für eine DateiDie Information, wie lang beispielsweise eine Datei ist, gehört zu derRevision, in der dieser Wert korrekt war. Dies gilt auch für den Dateina-men oder Speicherort zur Zeit dieser Revision. Eine einfache Anpassungdes Datenbankeintrags würde zum Verlust des alten Werts führen. Einegemeinsame Darstellung beider Werte innerhalb nur eines Eintrags istbei Datenbanken nicht praktikabel.Aus diesem Grund wurde die Variante mit mehreren Einträgen gewählt.Durch die sich bildende doppelt verkettete Liste bleibt die Entwicklungs-geschichte einer Datei immer nachvollziehbar.

4.2.1.4 FolderActivity

Die letzte Tabelle für Aktivitäten bezieht sich auf Ordneraktivitäten. Die Spaltenbeinhalten:

• ID

• Typ der Aktivitätsausprägung (Codiert in einer Zi�er)

• Referenz zum Ordner

• Anzahl der ...

◦ Dateien,

◦ Dateitypen,

◦ Unterordner,

die zum Aktivitätszeitpunkt im Ordner enthalten sind.

• Referenz zum Vorgängerordner.

Diese Tabelle ist ähnlich aufgebaut, wie die FileActivity. Hier gibt es allerdingskeine Informationen zu Codezeilen. Für Ordner sind die darin enthaltenen Dateien,Dateitypen und Unterordner zum Aktivitätszeitpunkt relevant.

Zu allen oben genannten Referenzen zu Dateien, Ordnern, Branches, Tags und Ent-wicklern gibt es jeweils eine Tabelle, die sich dadurch auszeichnet, dass sie aktivi-tätsinvariante Informationen enthält bzw. ein bestimmtes Zeitintervall beschreibt:

4.2.1.5 Developer

Enthält einen Eintrag für jeden Entwickler, der irgendwann einmal in der Repositoryaktiv war. Es gibt folgende Spalten:

• ID

Page 41: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

41

• Name des Entwicklers im SCM-System.

• Name des Entwicklers in Bugzilla.

Neben der Bug - Referenz in der SCM_Revision_Activity_History gibt es hiereinen zweiten Verknüpfungspunkt zwischen SCM-Systemen und Bugzilla. Ein Map-ping der Entwicklernamen von einer Systemwelt in die andere.

4.2.1.6 SCM_Branch, SCM_Tag

Beide Tabellen bestehen lediglich aus dem Namen des Branches / Tags und einerSpalte Enabled, die de�niert, ob der zugehörige Branch / Tag aktuell noch im Systemexistiert.

4.2.1.7 SCM_Folder

Die Tabelle für Ordner beinhaltet:

• ID

• Typ - ID der Entwicklungslinie (Branch, Tag, Trunk)

• Referenz zur Entwicklungslinie (Branch, Tag)

• Name des Ordners

• Pfad zum Ordner

• Name des Projekts, in dem der Ordner liegt.

• Information, ob Ordner im System noch existiert (enabled).

Prinzipiell kann es zwei verschiedene Ordner geben, die sowohl den gleichen Namen,als auch den gleichen Pfad haben. Den Unterschied macht dann die Zugehörigkeitzu einem Branch / Tag / zum Trunk aus. Aus diesem Grund gibt es eine Referenzzum betre�enden SCM_Branch - oder SCM_Tag-Eintrag.Die Enabled - Spalte hat auch hier, wie überall, die gleiche Bedeutung wie beiSCM_Branch und SCM_Tag.

Designbegründung:Warum ist hierdurch die Abstraktion von SCM-Systemen mit unter-schiedlichen Bedeutungen von Branches und Tags realisiert?

Ob diese Struktur wirklich in der Lage ist, von den Unterschieden allerSCM-Systeme abstrahieren zu können, kann der Autor mangels Kennt-nis aller Systeme nicht behaupten. Für die vorliegenden Systeme CVSund SVN ist dies aber der Fall:Ein SVN-Branch oder -Tag kann mittels Referenz zur entsprechendenTabelle und der Angabe des Entwicklungslinientyps (Branch oder Tag)gespeichert werden. Falls ein Ordner zum Trunk gehört, wird der Typ(Trunk) und keine Referenz gesetzt. Es gibt nur einen Trunk, sodasskeine Zusatzinformationen nötig sind.Falls der SVN-Administrator einen Sonderweg geht, wie z.B. zusätzlicheUnterordner in der Repository mit besonderer Bedeutung (wie es fürBranches etc. der Fall ist), könnten die zusätzlichen Entwicklungslinien-typen in SCM_Branch oder SCM_Tag vermischt werden oder man fügt

Page 42: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

42 KAPITEL 4. DATENBANKENTWURF

neue Tabellen nach dem bestehenden Schema hinzu.Unter CVS liegen alle Branches inklusive HEAD in der SCM_Branch-Tabelle und werden wie oben beschrieben mit den Ordnern verlinkt.Tags tauchen beim Referenzieren der Ordner nicht auf.In der vorliegenden Datenbankstruktur sind Tags auch von Dateienisoliert. Bei einer möglichen Weiterentwicklung wäre es aber problemlosmöglich, Dateien mit Tags zu referenzierten, wie es hier schon bei Ord-nern der Fall ist. Der SVN-Import würde in diesem Fall die Referenzenzwischen Dateien und Tags einfach nicht verwenden.

4.2.1.8 SCM_File

Die letzte Tabelle beinhaltet revisionsinvariante Informationen zu Dateien:

• ID

• Name der Datei.

• Typ der Datei.

• Referenz zum Ordner, in der die Datei liegt.

• Information, ob Datei im System noch existiert (enabled).

Die Referenz einer Datei zum Vaterordner de�niert auch implizit die Zugehörigkeitzu einer bestimmten Entwicklungslinie.

Die Abbildung 4.2 zeigt eine Übersicht über die gesamte Datenbankstruktur.

4.3 Verwendung der Datenbank im BugzillaMetrics-Kern

Bei jeder Berechnung einer Metrik müssen die erforderlichen Daten aus der SCM-Datenbank in die einzelnen DataSources bzw. Events gelesen werden. Hierzu istdie Verwendung von Joins nötig.Dies erfolgt aber weitgehend einheitlich für alle DataSources:

• RevisionDataSource: Ausschlieÿlich SCM_Revision_Activity_History.

• DeveloperDataSource: Join von SCM_Revision_Activity_History und De-veloper.

• Branch-, Folder- und TagDataSource: Join von SCM_Revision_Activity_-History, der jeweiligen ***Activity - Tabelle und der SCM_*** Tabelle.

• FileDataSource: Join von SCM_Revision_Activity_History, FileActivity,SCM_File, SCM_Folder und Developer.

Diese Joins verlaufen meist auf einem Pfad durch die oben angesprochene Baum-hierarchie. Eine Ausnahme bildet dabei die FileDataSource, die zusätzliche Joinsmit Developer und SCM_Folder benötigt.Einige Referenzen, wie z.B. die Referenz zwischen SCM_Branch und SCM_Folderwerden im Rahmen dieser Arbeit nicht verwendet. Da sie nach dem Importvorgangvorliegen, verlinkt der AssociationBuilder diese gleich mit. Bei einer eventuellenErweiterung der SCM-Integration könnten sie möglicherweise nützlich sein.

Page 43: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

43

Abbildung 4.2: Die Struktur der SCM-Datenbank

Page 44: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

44 KAPITEL 4. DATENBANKENTWURF

Page 45: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

Kapitel 5

Test-Framework

Dieses Kapitel beschreibt den Aufbau des Test-Frameworks. Zunächst werden in Ab-schnitt 5.1 die Anforderungen, welche für einen sinnvollen Test der SCM-Integrationbestehen, beschrieben. Darauf wird der Aufbau der Tests aus Benutzersicht er-läutert. Der letzte Abschnitt 5.3 beschäftigt sich dann mit der Architektur.

5.1 Anforderungsanalyse

Es gibt zwei grundlegende Stellen in BugzillaMetrics, an denen eine systematischeTestunterstützung nötig ist:

1. Test der SCM-Integration im BugzillaMetrics-Kern (im Folgenden: erweiterterKern).

2. Test des Datenimports in die SCM-Datenbank.

In Abbildung 5.1 sind diese beiden Stellen im bekannten Schaubild zum Systemkon-text markiert.

5.1.1 Test des erweiterten Kerns (Bugzilla-Test)

Ein Test-Framework für den erweiterten Kern muss aufgrund der Unabhängigkeitvon BugzillaMetrics von der SCM-Integration auch herkömmliche Tests ohne SCM-Daten unterstützen. In beiden Fällen muss es möglich sein, sowohl die Bugzilla- ,als auch die SCM-Datenbank mit Testdaten zu füllen.Die Menge der Testfälle muss die Verwendung aller SCM-spezi�schen BaseFilter,Events und Weights einzeln und für einige Beispielfälle in Kombination abdecken.

5.1.2 Test des Datenimports in die SCM-Datenbank (Import-Test)

Für diesen Testtyp gibt es prinzipiell zwei verschiedene Ansatzpunkte.Zum einen wäre die Verwendung von SCM-Dummies denkbar. Ein Versionsmanage-ment-Dummy, also eine Simulation der Schnittstelle zu den Log-Ausgaben vonCVS bzw. Subversion, wäre zwar möglich, aufgrund der statischen Rückgabe abernachteilig.

Ein veränderter Zugri� auf die Schnittstelle, wie z.B. spezielle Parametrisierungen,würde bei jeder Änderung eine Erweiterung des Dummies nötig machen.

45

Page 46: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

46 KAPITEL 5. TEST-FRAMEWORK

Abbildung 5.1: Lokalisierung der Stellen, an denen systematische Tests durchgeführtwerden müssen.

Auÿerdem wäre eine groÿe Auswahl an Log-Ausgaben, wie z.B. cvs log oder cvsannotate für jede Datei in jeder Revision und cvs diff für alle möglichen Revisions-vergleiche einer Datei nötig.Die andere und sinnvollere Variante ist die Verwendung realer SCM-Systeme. Dieseführt nicht nur zu kompakteren Testfällen, sondern zusätzlich auch zu realitäts-naheren Testabläufen mit uneingeschränkter Schnittstellenfunktionalität.

Um die korrekte Abfrage der Versionsmanagement-Logs zu ermöglichen, muss al-so für jeden Test ein reales SCM-System zur Verfügung stehen, wobei der Testerdie Möglichkeit haben muss, ein spezielles System (hier CVS / CVSNT bzw. Sub-version) auswählen zu können. Um reale Bedingungen zu scha�en, ist ein installierterSCMBug Glue erforderlich.

Damit spezielle Inhalte in der Repository als Grundlage für den Test erzeugt werdenkönnen, muss das Testsetup entsprechende Kon�gurationsmöglichkeiten bieten. Allewesentlichen Aktivitäten in einer Repository müssen simuliert werden können.

Die Syntax der Aktivitätsbeschreibung sollte vom verwendeten Versionsmanagement-system möglichst abstrahiert werden, um Kon�gurationen universell verwendbar zumachen.

Eine weitere Frage ist, ob für alle Tests die selbe Repository verwendet werden kannoder nicht. Da für verschiedene Tests auch verschiedene Repository-Inhalte erforder-lich sein könnten, müsste man die Repository für jeden Test anpassen. Aufgrund derTatsache, dass die History der Versionsmanagementsysteme solche Veränderungen

Page 47: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

47

des Inhalts speichert, wären die Tests nicht unabhängig voneinander. Deshalb mussdas Framework für jeden Test eine neue Repository mit angepasstem Inhalt zurVerfügung stellen.

Die Menge der Testfälle muss alle Aktivitäten, die in SCM-Systemen auftreten kön-nen, abdecken. Auÿerdem sind Tests für syntaktische Sonderfälle, wie z.B. Datei-namen etc. nötig, um die Parsevorgänge zu überprüfen. Beispielsweise könnte einParser eine Datei, deren Name keinen Punkt enthält, als Ordner erkennen oderder Typ einer Datei, deren Name mehrere Punkte enthält, falsch gesetzt werden.Beispiele für andere potentielle Fehlerquellen sind Verzeichnisnamen, die Leerstellenenthalten oder auch Kommentare mit Sonderzeichen, welche bei der Sicherung indie MySQL-Datenbank zu Syntaxfehlern führen können.

5.2 Testaufbau aus Benutzersicht

Wie schon in der Anforderungsanalyse angesprochen, benötigt jedes Test-Setup ver-schiedene Kon�gurationsdateien, welche die Datenbank- oder Repository-Inhaltefestlegen. Zusätzlich ist die De�nition eines Soll-Resultats für jeden Test obliga-torisch.

Dieser Abschnitt beschreibt, wie diese Dateien aufgebaut sind. Es handelt sich alsohier um eine Beschreibung des Testaufbaus aus der Sicht des Benutzers.

5.2.1 Bugzilla-Test

Der Bugzilla-Test unterstützt die Überprüfung des erweiterten Kerns bei der Ver-wendung der erweiterten Datenbasis, bestehend aus den Datenbanken für Bugzillaund SCM. Da das bisherige Test-Framework diese Aufgabe für die alleinige Verwen-dung der Bugzilla-Datenbank schon erfüllen kann, wird es erweitert.

Testsetup

Die schon aus dem Test-Framework ohne SCM-Unterstützung vorhandene XML-Syntax wird um ein zweites Element scmdb erweitert. Dieses enthält analog zumbugzilladb-Element für jeden Tabelleneintrag in der SCM-Datenbank ein Kind-element. Der Name eines Elements entspricht dabei dem der Zieltabelle. Zu jederSpalte der Tabelle gibt es ein gleichnamiges Attribut.

Eine genauere Beschreibung der Tabellen und der vorhandenen Spalten �ndet sichin 4.2.

Testspezi�kation einer Metrik

Die Metrikspezi�kation entspricht der normalen Syntax und bietet den vollständigenFunktionsumfang.

Der BugzillaMetrics Guide ([4]) beschreibt die Syntax der Spezi�kation und im darinenthaltenen Kapitel zur SCM-Integration die SCM-spezi�schen Events, Weightsund BaseFilter.

Ergebnisvergleich

Diese XML-Datei entspricht der Syntax des Test-Frameworks ohne SCM-Unterstützung.

Page 48: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

48 KAPITEL 5. TEST-FRAMEWORK

5.2.2 Import-Test

Die Überprüfung des Datenimports wird durch den Import-Test realisiert. Diesersetzt reale SCM-Systeme voraus. Aufgrund dessen ist ein zweites Test-Frameworknötig, das lediglich die Grundfunktionalität des Bugzilla-Test Frameworks über-nimmt und in der Lage ist, sowohl ein variables Szenario der SCM-Repository herzu-stellen als auch eine Überprüfung des korrekten SCM-Datenbankinhalts durchzu-führen.

Testsetup

Würde man die Informationen zur Initialisierung der Bugzilla-Datenbank, CVS undSVN getrennt in verschiedenen Dateien liefern, wäre die Gefahr groÿ, schnell denÜberblick über Informationen, die eigentlich zusammen gehören, zu verlieren. Des-halb werden die Informationen für die SCM-Initialisierung in einem XML-Schemaintegriert. Dieses enthält folgende Hauptelemente:

• Inhalt der Bugzilla-Datenbank

• Informationen für das SCM-Szenario (CVS(NT) und/oder Subversion)

Der Inhalt der Bugzilla Datenbank wird wie beim Bugzilla-Test in einem bugzilladb

Element mit Kindelementen, welche die Tabelleneinträge spezi�zieren, de�niert.

Das SCM-Szenario wird für ein spezielles Versionsmanagementsystem de�niert.Hierzu gibt es die Elemente cvs und svn. Innerhalb dieser können Aktivitätenin der Repository - mit erforderlichen und optionalen Attributen - de�niert wer-den. Hierbei beschreibt jedes Element eine einzelne Operation. Eine Au�istung dermöglichen Aktivitäten �ndet sich im Anhang (B).

Diese Aktivitäten werden in der Reihenfolge der gewünschten Ausführungsabfolgein das Elternelement (cvs bzw. svn) geschrieben. Ausnahme bildet das import-Element. Dieses darf höchstens einmal in der Kon�gurationsdatei enthalten seinund wird, unabhängig von der Position in der Datei, als erstes ausgeführt.

Bei der Spezi�kation einer CVS-Repository ist, anders als bei Subversion, ein Importobligatorisch. Ansonsten initialisiert CVS die Repository nicht und verhindert damitdie Verarbeitung der folgenden Aktivitäten. Das Import-Element kann allerdingsauch leer sein.

Optional besteht die Möglichkeit, zu einer Aktivität den Zeitpunkt der Ausführungzu de�nieren: time="yyyy-mm-dd hh:mm:ss"

Die Zeitde�nition sollte nur bei Testfällen verwendet werden, die eine genaue Zeit-de�nition unbedingt erfordern. Ansonsten sollte keine Zeit de�niert werden, da fol-gende Probleme auftreten (können):

• Eine De�nition verursacht die Änderung der Systemzeit. Hierzu sind Admin-istratorrechte erforderlich.

• Die Systemzeit ist nach Testdurchführung möglicherweise nicht mehr korrekt.

• Die Enwicklungsumgebung könnte abstürzen (z.B. unter Eclipse).

• Das Dateisystem könnte inkonsistent werden und eine Überprüfung beim Sys-temstart erzwingen (z.B. beim Linux-ext3 Dateisystem).

Page 49: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

49

Die o.g. Kon�guration der Repository ist unabhängig vom Versionsmanagementsys-tem. Falls also der gleiche Testfall für CVS und SVN geprüft werden soll, muss dieKon�guration nur einmal geschrieben werden.Ist beispielsweise ein identischer Datenbankinhalt für zwei Szenarien unter CVSbzw. Subversion zu erwarten, können beide Szenarien in einer gemeinsamen Dateide�niert werden. Der Test erfolgt nacheinander und wird dann mit dem gleichenReferenzergebnis (s.u.) verglichen.

Eine Setupdatei könnte wie in Abbildung 5.2 aussehen.

<testConf><cvs>

<import comment="bug1 : Kommentar zum Datei import " >< f i l e name="F i l e 1 . java " l o c a t i o n=""

ta rge tLoca t i on="sub" targetName="F i l e 1 . java " /></import><add sourceLocat ion="" sourceFileName="F i l e 1 . java "

ta rge tLoca t i on="sub1"targetFi leName="F i l e 1 . java " />

<add sourceLocat ion="" sourceFileName="F i l e 2 . java "ta rge tLoca t i on="" targetFi leName="F i l e 2 . java " />

<commit comment="bug1 : Kommentar zum Commit" /></cvs>

</testConf>

Abbildung 5.2: Beispiel einer XML-Kon�gurationsdatei eines Import-Tests

Ergebnisvergleich

Der Import-Test startet einen Importvorgang auf der Basis eines Versionsmanagement-systems mit dem oben de�nierten Szenario.Ein Ergebnisvergleich �ndet dann auf Datenbankebene statt. Dies geschieht mit Hil-fe eines Datenbank-Exports in Form einer XML-Datei. Diese Ausgabe enthält nebeneiner Strukturbeschreibung der SCM-Datenbank auch die erwarteten Tabellenein-träge (Abbildung 5.3). Zu jedem Testergebnis wird ebenfalls ein Datenbank-Exporterzeugt und die Tabelleneinträge inhaltlich miteinander verglichen. Es erfolgt alsokein Datei-Di�.

Da sich bei der Testdurchführung zwangsläu�g inhaltliche Unterschiede ergeben,werden folgende Einträge ignoriert:

• Einträge des Typs TimeStamp: Werte abhängig von der Systemzeit.

• Revision_ID in der SCM_Revision_Activity_History-Tabelle: Da CVS fürjeden Commit eine ID generiert, ist diese nicht vorhersagbar.

• Namen der Entwickler in der Developer-Tabelle. Der Name entspricht immerdem des am Betriebssystem angemeldeten Nutzers.

Page 50: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

50 KAPITEL 5. TEST-FRAMEWORK

<?xml ve r s i on="1.0"?><mysqldump xmlns : x s i="http ://www.w3 . org / . . . " ><database name="scm">( . . . )<table_data name="BranchActiv ity">

<row><f i e l d name="ID">1</ f i e l d ><f i e l d name="Type_ID">1</ f i e l d ><f i e l d name="SCM_Branch_ID">1</ f i e l d >

</row><row>

<f i e l d name="ID">2</ f i e l d ><f i e l d name="Type_ID">1</ f i e l d ><f i e l d name="SCM_Branch_ID">2</ f i e l d >

</row></table_data>( . . . )</database></mysqldump>

Abbildung 5.3: Beispiel einer XML-Kon�gurationsdatei eines Datenbank-Exports

Der inhaltliche Vergleich ist zwar �exibler als eine einfaches File-Di�, hat aber auchNachteile:

• Eine strukturelle Änderung der Datenbank führt dazu, dass alle Testsfehlschlagen. Dies gilt jedoch nicht für eine Erweiterung um neue Tabellenspal-ten, da der Vergleich nur vom aktuellen Ergebnis zum Referenzergebnis erfolgtund nicht umgekehrt.

• Zwei Tabellen, die die gleichen Einträge in unterschiedlicher Reihenfolge ent-halten, werden als verschieden angesehen.

5.3 Design

Dieser und die weiteren Abschnitte zum Design stellen das Grundproblem zunächstunter Problembeschreibung vor und gehen dann auf das Design selbst ein. Die Be-gründung, warum ein bestimmtes Design gewählt wurde, wird in den abgesetztenTextabschnitten Designgründe innerhalb der Beschreibung geliefert.

5.3.1 Problembeschreibung

Das in BugzillaMetrics vorhandene Test-Framework (s. [10]) beschränkt sich auf dieUnterstützung von Testfällen für den Systemkern. Die einzige externe Informations-quelle ist eine SQL Datenbank, welche Daten aus Bugzilla enthält.Die Integration von SCM-Systemen macht es erforderlich, beim Test auch derenFunktionalität und Informationsmöglichkeiten zur Verfügung zu stellen.Gleichzeitig muss sichergestellt werden, dass die bestehenden Testfälle auch im er-weiterten Framework ohne Änderung lau�ähig sind. Der Grund liegt darin, dassdie SCM-Integration nicht zwangsläu�g Teil des Systems sein muss, sondern einErweiterungspunkt ist.

Page 51: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

51

Vielleicht kommen in Zukunft weitere SCM-Systeme und andere Testfallarten hinzu.Die Architektur sollte eine Erweiterung so einfach wie möglich gestalten.

5.3.2 Designbeschreibung

Das Design des Frameworks basiert auf der des CoreTests ohne SCM-Integration(s. [10]). Da BugzillaMetrics darauf ausgelegt ist, auch andere Bug-Tracker zu un-terstützen, wurden die CoreTests umbenannt. Sie nennen sich nun BugzillaTests.

Grundlage sind JUnit Testcases. Wie schon in [10] angemerkt, sind die Tests aufSpezi�kationsebene abstrahiert. Es werden folgende Spezi�kationsdateien verwendet(vgl. 5.2.1 und 5.2.2):

• Bugzilla-Test: Setupkon�guration, Metrikspezi�kation, Metrikresultat

• Import-Test: Setupkon�guration, Datenbank-Referenzinhalt

Designgründe: Kon�gurationsdateien

Würde man die Informationen zur Initialisierung der Bugzilla Daten-bank, CVS und SVN getrennt in verschiedenen Dateien liefern, wäre dieGefahr groÿ, schnell den Überblick über Informationen, die eigentlichzusammen gehören, zu verlieren.So kann das Test-Framework beim Testablauf erkennen, welche der bei-den SCM-Systeme für den aktuellen Test relevant sind und diese dannnacheinander mit derselben Metrik-Datei testen. Es wird also vermieden,Tests redundant zu speichern und damit eine unnötig groÿe Testmengevorliegen zu haben.Die Verwendung von systemunabhängiger Syntax für Repository Opera-tionen, also Abstraktion von CVS bzw. SVN, führt zu einer verbessertenWiederverwendbarkeit und Wartbarkeit der Testfälle.

5.3.2.1 JUnit Testsuites

Abbildung 5.4:Übersicht: Testklassen

Die beiden JUnit Tests BugzillaTest und ImportTest

haben starke inhaltliche Überschneidungen. Deshalbwurden gemeinsame Methoden in einer abstrakten Ober-klasse AbstractMetricsTest ausgelagert. Diese enthältu.a. Template Methods.

Um auch eine Trennung von Bugzilla-Tests ohneSCM-Verwendung von denen mit SCM-Inhalt zu er-reichen, liefert die Klasse BugzillaTest eine Unter-stützung reiner Bugzilla-Metriken und die UnterklasseBugzillaWithSCMTest eine zusätzliche Unterstützungder SCM-Integration (Abbildung 5.4).

Inhaltlich wird das als Konstante ROOT_DIRECTORYangegebene Testverzeichnis rekursiv nach Testsuitendurchsucht. Eine Testsuite ist ein Unterordner im Test-verzeichnis, dessen Name mit der Angabe in der Kon-stante TESTSUITE_SUFFIX endet und in weiterenUnterordnern die Spezi�kationsdateien bzw neue Test-suites enthält:

• BugzillaTest / BugzillaWithSCMTest

Page 52: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

52 KAPITEL 5. TEST-FRAMEWORK

◦ db: Setupkon�guration

◦ metric: Metrikspezi�kation

◦ result: Metrikresultat

• ImportTest

◦ db: SCM-Szenariobeschreibung

◦ result: Datenbank-Referenzinhalt

Jede dieser Suiten kann mehrere Testfälle enthalten. Ausschlaggebend ist der In-halt im result-Unterordner. Im BugzillaTest muss eine Resultdatei wie folgt be-nannt werden: <Name der Kon�gurationsdatei>.<Name der Metrikspezi�kation>.Im ImportTest wird die gleiche Syntax erwartet, der Teil hinter dem Punkt kannjedoch frei gewählt werden.

Testfälle der drei verschiedenen Typen können nicht vermischt werden, denn jedeTestsuite darf nur einen Test-Typ enthalten.

Designgründe: Trennung der drei Testarten

Es müssen zwei Komponenten des Systems getestet werden, welche gemäÿAnforderungsanalyse unabhängig voneinander sind. Die SCM-Integrationist ein Erweiterungspunkt und kein fest integrierter Bestandteil vonBugzillaMetrics. Hierdurch wäre eine Vermischung der Testfälle für einenEntwickler, der kein Versionsmanagementsystem verwenden möchte, pro-blematisch. Auf der anderen Seite benötigt ein Entwickler der SCM-Integration keine Unterstützung für Kernsystemtests. Eine inhaltlicheTrennung der Tests ist also die beste Lösung.Ein völlig unterschiedliches Test-Framework mit einer anderen Testab-straktion wäre sowohl für Wartungsarbeiten als auch für die Einar-beitungszeit des Entwicklers nachteilig.Deshalb werden die Kernklassen des Frameworks gemeinsam genutztund inhaltliche Unterschiede in Unterklassen realisiert.Die zusätzliche Unterscheidung von Bugzilla-Tests mit und ohne SCM-Integration ist das Resultat einer Neugestaltung der Testarchitektur,nicht nur aufgrund der SCM-Integration, sondern auch im Hinblick aufdie Unterstützung des Bug-Trackers Mantis.

5.3.2.2 JUnit TestCases

Aus den o.g. Angaben wird eine Menge von TestCase-Objekten erzeugt. Von diesengibt es verschiedene Ausprägungen, die in Abbildung 5.5 zusammengestellt sind.

AbstractMetricsTestCase

Abstrakte Oberklasse aller TestCases. Liefert die Testfunktionalität welche für alleTestfälle gleichermaÿen gilt:

• setup: Kon�gurationseinstellungen für den BugzillaMetrics-Kern

• run: Metrikkalkulation ausführen, diverse Soll-Ist Vergleiche

• tearDown: TestSQLLogger der SQLFacade zurücksetzen

Page 53: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

53

Abbildung 5.5: Überblick über TestCases

BugzillaTestCase

TestCase Objekte für den Bugzilla-Test.

• setup: Auslesen und Anwenden der Kon�gurationsdatei für das Datenbank-setup

ScmTestCase

Abstrakte Oberklasse aller Import-Tests. Alle ScmTests de�nieren den Inhalt derBugzilla-Datenbank, überprüfen den Inhalt der im Test erzeugten SCM-Datenbankund müssen nach der Testdurchführung das verwendete Versionsmanagementsystementfernen.

• setup: Bugzilla-Datenbank initialisieren und füllen.

• assert: Methoden zum Laden und Überprüfen der MySQLdump-Ausgabe.

• tearDown: Versionsmanagementsystem und alle zugehörigen temporären Ver-zeichnisse entfernen.

CVSTestCase

Objekte für die Durchführung eines Import-Tests auf Basis eines CVS- bzw. CVSNT-Systems.

• setup: Bereitstellen eines CVS-Versionsmanagementsystems und herstellen einesSzenarios unter Verwendung der SCM-Szenariobeschreibung.

SVNTestCase

Objekte für die Durchführung eines Import-Tests auf Basis eines Subversion-Systems.

• setup: Bereitstellen eines Subversion-Versionsmanagementsystems und Her-stellen eines Szenarios unter Verwendung der SCM-Szenariobeschreibung.

Page 54: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

54 KAPITEL 5. TEST-FRAMEWORK

Die Entscheidung, welcher ScmTestCase zur Kon�gurationsdatei passt bzw. obmöglicherweise beide TestCases erzeugt werden müssen, da die Kon�gurationsdateisowohl für CVS als auch für Subversion Szenarien enthält, wird in der FactoryklasseScmTestCasesFactory getro�en. Diese wird vom ImportTest aufgerufen.

Designgründe: Unterscheidung verschiedener TestCase-Aus-prägungen

Alle TestCases haben eine gemeinsame Schnittmenge an Methoden. Sieunterscheiden sich mehr oder weniger stark in den nötigen Setup-, Tear-Down-, und Assert-Methoden. Dies legt eine Vererbungshierarchie na-he, welche zusätzlich eine Systemerweiterung um ein neues SCM-Systemoder einen völlig neuen Testaspekt erleichtert.

5.3.2.3 Setupaktivitäten

Es gibt drei grundlegende Aufgaben während des Setupvorgangs:

• Füllen der Datenbanken mit denen in den Kon�gurationsdateien enthaltenenDaten.

• Erstellen temporärer Verzeichnisse.

• Initialisieren der Versionsmanagementsysteme und Herstellen der Szenarien,welche in den Szenariobeschreibungen de�niert sind.

Datenbanksetup

Für jede Datenbank existiert eine eigene Setup-Klasse, d.h. BugzillaDBSetup undScmDBSetup, welche vor allem eine Methode zur Leerung der Tabellen zur Verfü-gung stellen.Die Methoden zur Übertragung der Einträge in eine MySQL Datenbank sind unab-hängig von der jeweiligen Datenbank und liegen in einer gemeinsamen OberklasseDBSetup.Die Information, welche Tabellenspalten �xe Werte enthalten sollen und die In-halte welcher Spalten in der Kon�gurationsdatei de�niert werden müssen, wird ge-trennt vom Setup in TableConfigurations angegeben. Es gibt die beiden KlassenBugzillaTableConfigurations und SCMTableConfigurations, die jeweils das In-terface DatabaseTableConfigurations implementieren. Diese Klasse enthält eineMap, in der alle einzelnen Kon�gurationen des Typs TableConfiguration, liegen(Siehe Abbildung 5.6).

Temporäre Verzeichnisse

Die Import-Tests benötigen verschiedene Verzeichnisse für die temporäre Sicherungvon Dateien. Diese können in der settings.xml angepasst werden. Es gibt folgendeHauptverzeichnisse:

Page 55: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

55

Abbildung 5.6: DBSetup-Architektur

Nr. Inhalt Bezeichnung in settings.xml

1. Wurzelverzeichnis absoluteWorkingDirecoryPath

2. Zwischenspeichern v. Dateien 1/relativeWorkingDirectoryTmpPath3. Zwischenspeichern v. Logs 1/relativeWorkingDirectoryLogPath

4. globale SCM-Repository scmRootPath5. lokale SCM-Arbeitskopien 1/relativeWorkingDirectoryCheckoutPath6. Projekt - Checkout 1/5/projectName

7. Test-Kon�gurationsdateien 1/relativeTestCon�g�lesPath

Die Zi�ern vor den Ordnerbezeichnungen weisen darauf hin, in welchem Vaterordnersich der betre�ende Ordner be�ndet.

SCM-Setup

In der Anforderungsanalyse wurde bereits erläutert, dass für jeden Test eine neueRepository mit de�nierbarem Inhalt erzeugt werden muss.Falls die Kon�gurationsdatei sowohl ein Szenario für CVS als auch für Subversionenthält, wird dieser eine Test kopiert und in einer Instanz als CVS-Test und in deranderen als Subversion-Test ausgeführt. Die für beide Varianten gleichen Methodenstehen in der abstrakten Klasse SCMSetup. Die variablen Teile erben von SCMSetup

in CVSSetup bzw. SVNSetup (siehe Abbildung 5.7).

Weder CVSSetup noch SVNSetup übernehmen die Ausführung der einzelnen SCM-Operationen, welche in der Kon�gurationsdatei stehen, selbst. Sie rufen sog. Scm-ActivityExecutionDelegator-Objekte auf, welche ihrerseits atomare Operationenan ActivityExecutioner delegieren.

Page 56: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

56 KAPITEL 5. TEST-FRAMEWORK

Abbildung 5.7: SCMSetup-Vererbungshierarchie

Ein ActivityExecutionDelegator erhält vom CVS- bzw. SVNSetup ein XML-Element, welches eine Aktivität beschreibt, und delegiert die Ausführung an einenpassenden ActivityExecutioner.Zu jedem Versionsmanagementsystem gibt es einen speziellen ActivityExecution-

Delegator. Eine Übersicht über die Zusammenhänge zwischen Delegator und Exe-cutioner be�ndet sich in Abbildung 5.8.

Die Delegator-Instanzen verwalten jeweils eine Liste, in der diejenigen Activity-

Executioner enthalten sind, welche die für das Versionsmanagement zur Verfügungstehenden Aktivitäten ausführen können.Wenn vom ActivityExecutionDelegatormittels delegateExecutionOf(Elementelement) eine neue Aktivität ausgeführt werden soll, durchläuft der Delegator dieListe und fragt jeden Executioner durch die Methode accept(Element element),die einen booleschen Wert zurückgibt, ob sie die vorliegende Aktivität ausführenkann. Falls ein Executioner mit true antwortet, führt der Delegator dessen start-

Activity(Element element) Methode aus. Diese führt die Aktivität dann so aus,wie es das jeweilige Versionsmanagement verlangt.Einen Sonderfall bei der Ausführung bildet das import-Element (falls vorhanden).Da die Importaktivität als erste ausgeführt werden muss, wird sie vor dem erstenAufruf eines Delegators aus der Liste herausgelesen, aus dieser entfernt und danndirekt durch den Cvs- bzw. SvnImportActivityExecutioner ausgeführt.

Die Syntax der XML-Elemente wird innerhalb der o.g. Vererbungshierarchie derExecutioner festgelegt (Siehe 5.8).

Die eigentliche Ausführung der Aktivitäten ist vom verwendeten Versionsmanage-mentsystem abhängig.

Page 57: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

57

Abbildung 5.8: Architekturübersicht: ExecutionDelegator

Designgründe: Delegator und Executioner

Um die relativ groÿe Menge an verschiedenen Aktivitäten übersichtlich,leicht erweiterbar und wartbar zu halten, wurde eine Vererbungshierar-chie erstellt.Sie kapselt die einzelnen Arbeitsschritte einer Aktivität von den anderenab und stellt gleichzeitig durch die De�nition der XML-Elemente inner-halb dieser Vererbungshierarchie sicher, dass die verschiedenen SCM-Ausführungen einer Aktivität die selbe XML-Syntax verwenden.Mit leichten Einschränkungen bei Tag- und Branch-Aktivitäten kön-nen die Aktivitäten bei der Testfallerstellung somit vom verwendetenVersionsmanagementsystem abstrahiert, und damit universell verwen-det werden.Um die Einbindung einer neuen Aktivität so einfach wie möglich zugestalten, implementiert der zugehörige Executioner lediglich die beidenMethoden accept und startActivity und wird in die Liste des Dele-gators geschrieben. Dieser verwendet die Methoden dann durch Poly-morphie, muss also nichts über den neuen Executioner wissen.

Sämtliche Setupaktivitäten, welche in diesem Abschnitt angesprochen wurden, laufenfür jeden Test automatisch ab. Der generelle Ablauf dieses SCM-Setups wird im Fol-genden nochmal zusammengefasst:

Page 58: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

58 KAPITEL 5. TEST-FRAMEWORK

1. Testverzeichnisse erstellen

2. Systemzeit nach time-Attributwert im XML-Element import der Kon�gura-tionsdatei setzen (falls angegeben)

3. Repository initialisieren mittels:

• CVS: cvs init

• Subversion: svnadmin create, Tag- und Branchverzeichnisse erstellen

4. SCMBug Glue installieren.

5. Import der Dateien aus dem import Element der Kon�gurationsdatei (cvsbzw. svn import)

6. Checkout des neuen Projekts.

7. Ausführen der gewünschten Aktivitäten, die jeweils in Elementen de�niertwerden (siehe 5.2.2 für eine detaillierte Beschreibung der Elemente)mit vorangehender Manipulation der Systemzeit.

(falls time-Attribut angegeben)

5.3.3 Aktivitäten zum Ergebnisvergleich

Zum Ende jedes Tests muss das Ergebnis mit dem Soll-Resultat verglichen werden.Da bei Bugzilla-Tests ein Metrikergebnis und bei Import-Tests ein Datenbankinhaltvorliegt, ist dieser Vergleich unterschiedlich zu handhaben.

5.3.3.1 BugzillaTest: Überprüfung des Metrikergebnisses

Der Vergleich des Metrikergebnisses mit dem Referenzergebnis aus dem result-Verzeichnis der Testsuite erfolgt durch einen einfachen Stringvergleich der Datei-Inhalte. Dieses Vorgehen wurde vom CoreTest aus [10] übernommen.

5.3.3.2 ImportTest: Überprüfung des SCM-Datenbankinhalts

Das Referenzergebnis bei Import-Tests stellt eine Datenbankausgabe im XML- For-mat dar. Da sich die Struktur der Datenbank beim Test nicht ändert, werden nurdie table_data-Elemente miteinander verglichen.Da die Datenbanktabellen miteinander verlinkt sind, ist es mit diesem Ansatz nichtmöglich, eine veränderte Reihenfolge korrekter Tabelleneinträge zu erkennen. Esmüsste in diesem Fall eine semantische Überprüfung der Referenzen geben, was abernicht der Fall ist. Eine Änderung im Importalgorithmus, die sich auf die Reihenfolgeder Datenbankoperationen auswirkt, kann also zu falsch-negativen Testergebnissenführen.

5.3.4 TearDown-Aktivitäten

Um sicherzustellen, dass folgende Tests unabhängig vom Vorgänger durchgeführtwerden können, sind sowohl die SCM-Datenbank als auch die Temporärverzeichnissezu löschen. Bugzilla-Tests benötigen nur Datenbanken. Hier muss also die Bugzilla-Datenbank für beide Bugzilla-Tests, die SCM-Datenbank nur für diejenigen mitSCM-Integration, gelöscht werden.

Page 59: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

59

5.3.4.1 Beispiel einer Import-Testdurchführung

Der genaue Testablauf und die dabei verwendeten Kommandozeilenbefehle inkl.Parameter sind in der Abbildung 5.10 angegeben.

Da aus Platzmangel nicht alle Kommandozeilenbefehle aller Aktivitäten vorgestelltwerden können, beschreibt das Aktivitätsdiagramm den Testablauf für die Spezi-�kation in Abbildung 5.9. Es wird lediglich eine einzige Datei im Root-Verzeichnisdes Projekts gesichert.

<scm><bugz i l l adb></bugz i l l adb>

<cvs><import comment="bug1 : Kommentar f u e r den Datei import " ></import><add sourceLocat ion="" sourceFileName="Tes tF i l e1 . java "

ta rge tLoca t i on="" targetFi leName="Tes tF i l e1 . java " /><commit comment="bug1 : Kommentar f u e r den commit" />

</cvs></scm>

Abbildung 5.9: Beispiel einer Testspezi�kation

Page 60: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

60 KAPITEL 5. TEST-FRAMEWORK

Abbildung 5.10: Ablauf des SCM-Testsetups

Page 61: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

Kapitel 6

Datenimport

In diesem Kapitel wird der Softwareteil vorgestellt, der für den Import der Daten ausdem SCM-System für die Metrikberechnungen im BugzillaMetrics-Kern zuständigist. Zunächst folgt in Abschnitt 6.1 eine Beschreibung der Anforderungen an diesenSoftwareteil. Im Anschluss daran folgt das Design des Imports.

6.1 Anforderungsanalyse

Vor der Berechnung einer Metrik zu SCM-Inhalten muss der Datenbestand derRepository in die SCM-Datenbank importiert werden. Hierzu ist es notwendig, dieheterogenen Schnittstellen zum SCM-System mit systemnahen Methoden einzule-sen, diese zu sortieren und systemunabhängig in der Datenbank zu speichern.Hierbei sind die Eigenschaften der SCM-Systeme und das Design der Datenbankdie Hauptgründe für die gestellten Anforderungen. Zusätzlich gibt es allgemeineAnforderungen an das Design.

Diese Punkte werden nun, sortiert nach funktionalen und nicht-funktionalen An-forderungen, zusammengestellt.

6.1.1 Funktionale Anforderungen

6.1.1.1 Allgemeine funktionale Anforderungen

• Automatischer Ablauf des Importvorgangs

• Sammlung aller Dateien, Ordner, Entwickler, Branches und Tags in der Re-pository

• Detailanalyse der Dateien bis auf Codezeilenebene für loc - Weights.

• Erkennen aller Datei-, Ordner-, Branch- und Tagaktivitäten, um Betrachtungvon Events zu ermöglichen.

• Erkennen der Beziehungen zwischen Ordnern und Dateien für numberOfSub-folder und numberOfFiles - Weights.

• Die Datenbank sollte nicht vollständig neu befüllt, sondern ergänzt werden.

61

Page 62: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

62 KAPITEL 6. DATENIMPORT

6.1.1.2 Funktionale Anforderungen der SCM-Systeme

Zwei unterschiedliche Algorithmen für die Bearbeitung der Dateien undOrdner Da Revisionen bei SVN direkt die Reihenfolge der Dateiversions-Zuständebeschreiben, sollten diese linear für alle Dateien und Verzeichnisse abgearbeitet wer-den. Die Revision 123 ist de�nitiv der Vorgänger von 124 und alle Beziehungen, diesich damit für Dateien und Verzeichnisse beider Revisionen ergeben, sind somit le-icht zu ermitteln. Unter CVS ist dies nicht möglich. Eine Datei in Revision 1.1 hatsowohl inhaltlich als auch zeitlich nichts mit einer anderen Datei in Revision 1.1 zutun. Deshalb muss hier ein anderer Algorithmus entworfen werden.

Verzeichnisaktivitäten unter SVN vollständig erfassen und unter CVSgenerieren Die Integrationskomponente muss die indirekt beschriebenen Add-Verzeichnisaktivitäten unter CVS explizit machen, um diese Informationen in Bugzil-laMetrics verfügbar machen zu können. Wie schon in der Anforderungsanalyse ange-sprochen, unterstützt CVS keine Versionskontrolle für Verzeichnisse. Ein Verzeichnisexistiert ab dem Zeitpunkt zu dem sich eine Datei in diesem be�ndet. Die Aktivi-täten Move, Rename und Delete können deshalb, anders als bei SVN, nicht explizitgemacht werden. Sie sind nicht möglich.

Commits Der Importalgorithmus muss so bescha�en sein, dass er sowohl dieMöglichkeit von Subversion, mehrere Aktivitäten in einem Commit durchzuführen,als auch die Trennung von Aktivitäten in einzelne Commits, wie es bei CVS derFall ist, verarbeiten kann.

Inhalt der lokalen Arbeitskopie SVN ist in der Lage, viele Anfragen aufGrundlage der lokalen Arbeitskopie zu beantworten. Dies soll möglichst oft genutztwerden, um die länger dauernde Abfrage der externen Repository zu umgehen.

Branches in der internen Datenstruktur sauber voneinander trennenDie Integrationskomponente muss während der Analyse der Repositoryinhalte beiCVS und SVN völlig unterschiedlich vorgehen, um Branches und Tags korrekt iden-ti�zieren zu können.

Informationsgehalt der Kommandozeilenbefehle Beim Laden der SVN-Da-ten muss die Integrationskomponente eine andere Folge von Kommandozeilenbe-fehlen ausführen als bei CVS. Der Parsevorgang der Daten gestaltet sich unter SVNleichter als bei CVS, da die Möglichkeit besteht, diese im XML-Format ausgebenzu lassen. CVS liefert ausschlieÿlich reine Textausgaben, was die Verwendung vonregulären Ausdrücken für die Daten�lterung erzwingt.

6.1.2 Nicht-funktionale Anforderungen

6.1.2.1 Allgemeine nicht-funktionale Anforderungen

• Leichte Erweiterbarkeit des Imports, um zusätzliche Versionsmanagementsys-teme unterstützen zu können.

• Modulares Design, mit dem Ziel:

◦ Möglichst viele Teile des Imports für alle SCM-Systeme verwenden zukönnen.

Page 63: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

63

◦ Um Änderungen lokal zu halten bei:

� Wechsel der Schnittstelle zum SCM-System

� Syntaxänderung der Log-Ausgaben

� Verwendung eines anderen Datenspeichers (Andere Datenbank, Datei-system, etc.).

◦ Anwendung allgemeiner Entwurfsprinzipien, um z.B. die Wartbarkeitdurch Kapselung in Modulen zu unterstützen, die Komplexität des Im-portalgorithmus zu beherrschen etc.

• Die Anzahl systemnaher Komponenten sollte möglichst klein sein.

• Es muss möglich sein, neben den beiden unterstützten Betriebssystemen Win-dows XP / Vista sowie Linux auch weitere zu unterstützen.

• Die Dauer einer Metrikberechnung lag bisher bei maximal 1 Minute (vgl.Evaluation in [10]). Dieser Wert sollte nicht überschritten werden. Ein Daten-import, der die Analyse eines vollständigen Projekts erfordert, kann deshalbalso nicht vor jeder Metrikberechnung erfolgen. Aus diesem Grund muss derImport von Zeit zu Zeit manuell durchgeführt werden können.

6.1.2.2 Nicht-funktionale Anforderungen der SCM-Systeme

Kommandozeilenbefehle einheitlich abstrahieren Sowohl CVS als auch Sub-version können über Kommandozeilenbefehle abgefragt werden.

Um die Unterschiede bei der Betrachtung von verschiedenen SCM-Systemen mög-lichst klein zu halten, besteht hier die Anforderung, diese Schnittstelle einheitlichzu abstrahieren und von externen Systemen vollständig zu abstrahieren.

6.1.3 Datenstrukturen der SCM-Ausgaben

Obwohl CVS und SVN ähnliche Kommandozeilenbefehle zur Abfrage des Reposi-tory-Inhalts anbieten, liefern sie unterschiedliche Datenstrukturen. CVS ist datei-orientiert und SVN revisionsorientiert. Dieser Abschnitt stellt die zur Verfügungstehenden Datenstrukturen vor. Im Abschnitt zum Design muss dann eine ein-heitliche Datenstruktur gefunden werden.

6.1.4 CVSImport-Überblick:

Ansatzpunkt beim CVSImport ist die cvs log-Ausgabe. Zentrales Objekt ist hierdie Datei. Alle existierenden Dateien werden nacheinander aufgelistet und zu jederDatei die Menge der Revisionen, in der sie vorliegt, aufgeführt. Die Analyse derLog-Ausgabe führt also zu einer Dateimenge und einer Revisionsmenge, wobei Re-ferenzen von den Dateien zu Revisionen existieren. Die Mengen können jeweils alsgeordnete Listen betrachtet werden.

Nun fehlen noch Details zu den Dateien, die sich von Revision zu Revision ändern.Zunächst der absolute Arbeitsanteil verschiedener Entwickler an einer Datei proRevision, der sich aus der cvs rannotate-Ausgabe ermitteln lässt. Diese Datenkönnen den Revisionen zugeordnet werden, die von den Dateien referenziert wurden.

Es folgt die Ermittlung der Codezeilenänderungen relativ von Revision zu Revision,die aus der cvs diff-Ausgabe stammt. Auch diese Daten sind ein Teil der von denDateien referenzierten Revisionen.

Page 64: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

64 KAPITEL 6. DATENIMPORT

Da Verzeichnisse von CVS nicht direkt unter Versionskontrolle gestellt werden,müssen diese aus den Pfaden der existierenden Dateien generiert werden. Es ergibtsich eine Liste aller Verzeichnisse.

Die Abbildung 6.1 stellt die sich letztendlich ergebende Datenstruktur der CVS-Quelldaten vor.

Abbildung 6.1: CVS-Datenstruktur

6.1.5 SVNImport - Überblick:

Auch unter SVN ist die svn log-Ausgabe der Startpunkt beim Importieren. Dasich die Inhalte der Ausgaben von denen unter CVS unterscheiden, ist hier eineandere Vorgehensweise nötig.

Die svn log-Ausgabe liefert nur Daten zu den existierenden Revisionen. Es ergibtsich heraus eine Liste von Revisionen, in der noch keinerlei Informationen zu Dateienoder Verzeichnissen existieren.

Um die Verbindung zu Dateien und Verzeichnissen herstellen zu können, kann diesvn info-Ausgabe für jede Revision einzeln angefordert werden. Diese enthält dieMenge der Dateien und Verzeichnisse, welche zum Revisionszeitpunkt existieren.Die Ausgabe enthält aber keine Detailinformationen zu den Inhalten von Dateienund Verzeichnissen.

Die fehlenden absoluten und relativen Details für Dateien können aus den svn diff-und svn annotate-Ausgaben ermittelt werden.

Dies führt zur Datenstruktur in Abb. 6.2.

Es ist zwar möglich, durch svn log mit dem Parameter --verbose auch eine Listeder in der Revision geänderten Objekte anzeigen zu lassen, die Bestimmung desObjekttyps, also Ordner oder Datei, müsste aber aus einer anderen Log-Ausgabeermittelt werden, da dies nicht in der svn log-Ausgabe steht. Da svn info dieseTyp-Information liefert, wird der hier vorgestellte Weg gewählt.

Um die einheitliche Datenstruktur begründen zu können, gibt der folgende Ab-schnitt zunächst einen Überblick über das Design.

Page 65: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

65

Abbildung 6.2: SVN - Datenstruktur

6.2 Designbeschreibung

6.2.1 Überblick

Es gibt eine Reihe von Einzeloperationen, die nötig sind, um von Quelldaten zueinheitlich strukturierten Datenbankeinträgen zu gelangen. Zunächst müssen dieQuelldaten geladen werden. Im Anschluss müssen diese Daten ausgelesen und diedaraus gewonnenen Informationen miteinander assoziiert werden. Zum Schluss folgtdie Sicherung in der SCM-Datenbank.

Jeder dieser Arbeitsschritte wird von einer Menge von Modulen übernommen.Es gibt für jedes SCM-Kommando, das Informationen bereitstellt, ein eigenes Loader-modul. Die geladenen Daten, welche mehr oder weniger komplexe Strukturen be-sitzen, werden von Parsermodulen eingelesen, die jeweils auf eine einzige Teilstruk-tur spezialisiert sind.

Wenn alle Daten vorliegen, folgen zwei Analyseschritte, welche Informationen zu denDaten explizit machen, die bis zu diesem Zeitpunkt nur implizit erkennbar sind. Diesist einmal die Verzeichnisstruktur im Projekt. Jede Datei besitzt einen Pfad und zujedem Ordner in diesem Pfad existiert ein Ordner-Objekt. Der Ordner selbst ken-nt seinen Inhalt allerdings noch nicht. Dies wird mit ScmRepositoryObjectLinkernbehoben.

Ein groÿes Problem von CVS ist die Unfähigkeit, Datei- und Ordnerverschiebun-gen zu erkennen. In der History von CVS existieren hier zwei getrennte Dateien /Ordner. Dies ist nicht korrekt und führt bei Metrikberechnungen zu falschen Ergeb-nissen. Auch unter SVN kann der Nutzer solche Umbenennungen oder Verschiebun-gen vor der History verstecken, indem er manuell eine Datei löscht und diese danndurch Copy - Paste wieder hinzufügt. Deshalb gibt es sogenannte ScmEventChecker,welche die Aktivitäten im Projekt analysieren und versuchen, die o.g. Fälle aufzu-spüren und tatsächliche Aktivitäten explizit zu machen.

Da alle Daten inhaltlich miteinander in Verbindung stehen, müssen diese vor derSicherung in der Datenbank miteinander assoziiert werden. Dies übernehmen Asso-

ciationBuilder.

Page 66: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

66 KAPITEL 6. DATENIMPORT

Sobald ein Tabelleneintrag in die Datenbank geschrieben werden kann, delegierendie AssociationBuilder diese Arbeit an einen DatabaseVisitor.

Die Organisation all dieser Module übernehmen sogenannte Import-Klassen, welchehierarchisch aufgebaut sind. Es existiert für jedes spezielle SCM System ein globa-les Import Objekt, welches Importvorgänge auf niedrigeren Ebenen, wie z.B. derImport einer Di�-Abfrage, an speziellere Import Objekte delegiert usw.

Die Abbildung 6.3 soll während der folgenden Vorstellung des Designs einen Ori-entierungspunkt liefern, zu welchem Arbeitsschritt des Imports der jeweilige Ab-schnitt gehört. Wie oben schon angesprochen, gibt es die groben Bestandteile Laden,Parsen, Assoziieren und Füllen der Datenbank.

Diese Abbildung suggeriert eine einfache sequentielle Abarbeitung der Arbeits-schritte. Dies ist natürlich nicht der Fall, da z.B. die beiden Punkte Laden undParsen mehrfach und auf verschiedenen Ebenen des Imports ausgeführt werden.

Abbildung 6.3: Überblick über den Datenimport

Im folgenden wird zunächstdie für CVS und Subver-sion einheitliche Datenstruk-tur vorgestellt. Es folgen dieImport-Klassen für CVS undSubversion und zum Schluss

alle verwendeten Module. Diese sind nach den Arbeitsschritten aus Abb. 6.3 geord-net.

6.2.2 Allgemeine Datenstruktur für alle SCM-Systeme

Die einzelnen Log-Ausgaben von CVS und Subversion müssen zu einer gemeinsamenDatenstruktur verbunden werden, um möglichst früh Daten vorliegen zu haben, diesystemunabhängig abzuarbeiten sind.

Nun stehen unter CVS und SVN grundsätzlich die gleichen Daten zur Verfügung.Die Unterschiede sind:

• CVS ist dateiorientiert und SVN revisionsorientiert.

• SVN verwendet durchgängige Revisionsnummern, CVS unterscheidet verschie-dene Branches.

In beiden Datenstrukturen gibt es keine ...

1. Referenzen zwischen Ordnern und Dateien.

2. Genaue Identi�kation von Aktivitäten.

3. Trennung der Branches vom HEAD / Trunk.

zu 1.: Um möglichst einfach Referenzen herstellen zu können, bieten sich globaleDatei- und Ordnerlisten an.

zu 2.: Die Di�-Ausgaben weisen zwar auf ADD-, REMOVE- und CHANGE-Aktivi-täten hin, aber eine angebliche REMOVE-Aktivität, gefolgt von einer ADD-Aktivitätkönnte sich auf die selbe Datei / den selben Ordner beziehen, die / der verschobenoder umbenannt wurde.

SVN kann zwar solche Aktivitäten erkennen, CVS (und vielleicht weitere, noch nichtunterstützte SCM-Systeme) kann (können) dies nicht.Da Aktivitäten sich als Revisionswechsel bemerkbar machen, sind zusätzliche Datei-

Page 67: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

67

und Ordnerlisten für jede einzelne Revision sinnvoll. Dies vereinfacht die Identi�ka-tion der tatsächlichen Aktivitäten.

zu 3.: Unter SVN sind Branches, Tags und Trunk nur dadurch zu erkennen, dass siein verschiedenen Unterordnern liegen. Referenzen zwischen Dateien und Ordnern,die zu verschiedenen Entwicklungslinien gehören, sind also logisch nicht möglich.Da auch an der Revisionsnummer kein Hinweis auf bestimmte Entwicklungsliniengegeben wird, muss in der Datenstruktur keine Anpassung erfolgen.Für CVS gilt dies nicht. Hier müssen sowohl die verschiedenen Revisionen als auchdie Verzeichnishierarchien voneinander getrennt werden.

Diese drei Punkte führen zu folgender systemunabhängiger Datenstruktur:

Abbildung 6.4: Systemunabhängige Datenstruktur

Diese Struktur stellt die Grundlage für alle Datenimporte dar.

Im Folgenden werden nun die CVS- und SVN- Importalgorithmen vorgestellt.

6.2.3 Organisation des Imports

Die eigentliche Organisation des Datenimports übernehmen verschiedene Import-Klassen. Ihre Hauptaufgabe ist die Delegation der Arbeitsschritte an Module, diespäter noch detailliert vorgestellt werden.

6.2.3.1 CVS-Import

Die Beschreibung des Imports erfolgt zunächst durch eine informelle Zusammenfas-sung des Algorithmus. Das Sequenzdiagramm in 6.5 greift dies dann noch einmalmit Blick auf die Zusammenarbeit zwischen den beteiligten Modulen auf.

Page 68: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

68 KAPITEL 6. DATENIMPORT

1. Iteration über alle existierenden Dateien:

(a) Lese cvs log-Kopf für eine Datei und erstelle Dateiobjekt mit revisions-invarianten Daten.

(b) Iteriere über alle Revisionen der Datei:

i. Lese Revisionsinformationen ein.

ii. Lese cvs rannotate für aktuelle Datei in aktueller Revision ein.

A. Lese Ausgabe zeilenweise ein.

B. Ermittle Arbeitsanteile von Entwicklern an Datei.

iii. Lese cvs diff für aktuelle Datei in aktueller Revision ein.

A. Lese Ausgabe zeilenweise ein.

B. Bestimme alle Stellen, an denen sich Änderungen ergeben habenund ermittle dazu Änderungstyp und -inhalt

iv. Kopiere Tags der Datei in globaler Liste aller Tags.

v. Sichere Datei in einem Revisionsobjekt, das die aktuelle Revisionmodelliert. Sichere das Revisionsobjekt, sortiert nach Branch in einemDatencontainer.

vi. Generiere Verzeichnisobjekte auf Grundlage des Dateipfades undsichere diese im aktuellen Revisionsobjekt und dieses sortiert nachBranch in einem Datencontainer.

(c) Identi�ziere Events, welche Dateien und Ordner betre�en.

(d) Bestimme Referenzen zwischen Dateien und Ordnern.

(e) Assoziiere Daten zur Vorbereitung der Sicherung in der Datenbank.

(f) Sichere alle Daten in der Datenbank.

Der Algorithmus wird in der Klasse CVSImport umgesetzt. Hierbei werden die meis-ten Aufgaben an die unten beschriebenen Module delegiert. Die genaue Abfolge derArbeitsschritte in Form eines Sequenzdiagramms stellt sich wie in Abbildung 6.5dar.

Die beiden untergeordneten Importklassen CvsRAnnotateImport und CvsDiff-

Import arbeiten nach dem gleichen Schema (siehe Abb. 6.6 und 6.7)

Die genaue Beschreibung der angesprochenen Objekte folgt in den unteren Ab-schnitten.

6.2.3.2 SVN-Import

Die Beschreibung des Imports erfolgt auch hier zunächst durch eine informelleZusammenfassung des Algorithmus. Das Sequenzdiagramm in 6.8 greift dies dannnoch einmal mit Blick auf die Zusammenarbeit zwischen den beteiligten Modulenauf.

1. Iteration über alle existierenden Revisionen.

(a) Lese svn log-Informationen für eine Revision ein.

(b) Datei- und Ordnersuche

i. Iteriere über alle svn info-Ausgabeelemente:

A. Erstelle das zum Ausgabeelement passende Datei- und Ordner-objekt.

Page 69: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

69

Abbildung6.5:Sequenzdiagram

mzum

CVSImport

Page 70: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

70 KAPITEL 6. DATENIMPORT

Abbildung 6.6: Sequenzdiagramm zum CvsRAnnotateImport

Abbildung 6.7: Sequenzdiagramm zum CvsDi�Import

B. Sichere dieses Objekt für die aktuelle Revision in einem Daten-container.

2. Suche nach Dateiaktivitäten.

3. Suche nach Ordneraktivitäten.

4. Lese Datei-Details ein.

(a) Lese die svn annotate-Ausgabe für die aktuelle Revision.

i. Bestimme die Arbeitsanteile von Entwicklern an einer Datei.

(b) Lese die svn diff-Ausgabe für die aktuelle Revision.

i. Bestimme pro Datei die Stellen, an denen sich Änderungen ergebenhaben und ermittle dazu Änderungstyp und -inhalt.

5. Bestimme Referenzen zwischen Dateien und Ordnern.

(a) Suche alle Ordner heraus, welche Wurzelordner von Branches oder Tagssind. Sichere sie in einer separaten Liste.

6. Assoziiere Daten zur Vorbereitung der Sicherung in der Datenbank.

7. Sichere alle Daten in der Datenbank.

Page 71: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

71

Dieser Algorithmus wird in der Klasse SVNImport umgesetzt. Die Abfolge der Ar-beitsschritte stellt die Abbildung 6.8 in Form eines Sequenzdiagramms dar. Diegenaue Beschreibung der angesprochenen Objekte folgt in den unteren Abschnit-ten.

Die drei untergeordneten Importklassen SvnInfoImport, SvnAnnotateImport undSvnDiffImport sind ähnlich aufgebaut wie die beiden CVS Imports für rannotateund diff. Sie werden hier deshalb nicht detailliert beschrieben.

6.2.3.3 Designgründe

Um eine Erweiterung für neue Quelldaten leicht möglich zu machen und gleichzeitigso früh wie möglich systemunabhängige Komponenten einsetzen zu können, ist eineTrennung der Arbeitsschritte die naheliegendste Lösung. Gleichzeitig führt dieseTrennung der Zuständigkeiten zu einem lesbareren und wartungsfreundlicheren Code.Da auch sehr unterschiedliche Quellen möglicherweise gleiche Teilstrukturen habenkönnten, besteht die Möglichkeit, sich in verschiedenen Anwendungsfällen z.B. Loa-der oder AssociationBuilder, in Zukunft nach dem Baukastenprinzip zusammen-zustellen.Der gesamte Updatevorgang ist für jede Datenquelle einzeln möglich und mit nureinem Methodenaufruf ( executeUpdate() ) ausführbar. Im Codeteil, welcher einUpdate triggert, muss also keinerlei Wissen über Interna vorhanden sein.

Laden

Alle Loader nutzen den OSCommandProvider (siehe 6.4). Sie müssen also vom Typdes Betriebssystems und Art der Kommandoausführung nichts wissen. Da die Da-ten aus vielen verschiedenen Quellen stammen, haben die Objekte nur einheitlicheMethodensignaturen und gleiche Hilfsmethoden. Deshalb gibt es kein Interface, son-dern eine abstrakte Oberklasse.

Parsen

Da alle Quelldaten aus einheitlich aufgebauten Teilstrukturen bestehen, ist ein hi-erarchischer Aufbau der Parser sinnvoll. Die Parser der obersten Ebene teilen dieQuelldaten in die jeweiligen Teilstrukturen auf und delegieren den Auslesevorgangan spezielle Parser, welche keinerlei sonstige Funktionalität besitzen. Die grobeAufteilung innerhalb der Daten wird also vom speziellen Auslesevorgang getrennt.Die Verwendung von RegExpParser-Klassen dient der Übersichtlichkeit des Codesinnerhalb des Parsers. So sind alle regulären Ausdrücke lokal an einem Ort zusam-mengefasst und können bei einer möglichen Syntaxänderung des Quellcodes leichtangepasst werden.

Assoziieren

Gleiche Informationen können nicht immer in vergleichbaren Quelldaten gefundenwerden, sondern sind möglicherweise verstreut. Z.B. liefert svn log deutlich wenigerInformationen als cvs log (vgl. 6.2.6). Würde man die Daten sofort in Tabellenob-jekte schreiben, wäre dieser Arbeitsschritt über alle Parser auf unterschiedlichenEbenen verstreut. Übersichtlicher ist es, die eingelesenen Daten in Objekten zuspeichern, welche die Quelldatenstruktur modellieren. Diese Objekte können danngesammelt und gemeinsam neu organisiert werden.Die Verwendung von Tabellenobjekten ermöglicht es, zukünftig nicht mehr auf eine

Page 72: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

72 KAPITEL 6. DATENIMPORT

Abbildung

6.8:Sequenzdiagram

mzum

SVNIm

port

Page 73: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

73

(langsamere) Datenbank angewiesen zu sein, sondern direkt aus den Objekten lesenzu können.

6.2.4 Loader

Die Loader - Objekte greifen alle auf externe Datenquellen zu. Dies sind in der RegelKommandos der SCM-Systeme.

Diese Kommandozeilentools bieten die Möglichkeit, anhand von Parametern eineSelektion von bestimmten Informationstypen vorzunehmen, was hier aber nichtverwendet wird. Die Inhalte der Kommando-Ausgaben werden im Abschnitt 6.2.6zusammen mit den Parsern vorgestellt.

Zusätzlich werden auch Anfragen an ein kleineres Perl-Script, das Entwicklernamenaus SCM-Systemen mit den entsprechenden aus Bugzilla matcht, oder kleine UnixTools, wie di�, verwendet.

Der Zugri� auf externe Programme erfolgt immer über OSCommandProvider, sodassder gesamte Importvorgang betriebssystemunabhängig ist.OSCommandProvider abstrahieren von Kommandozeilenbefehlen für die verschiede-nen externen Systeme und auch vom verwendeten Betriebssystem, sodass im Importkeinerlei systemspezi�sche Inhalte liegen. Eine Beschreibung der OSCommandProvider�ndet sich unter 6.4.

Alle Quellen erzeugen Ausgabedateien. Diese sind in der Regel einfache Textdateienoder xml-Dateien, die von der Standardausgabe der Kommandozeilenprogrammegelesen werden. Sie werden dann von den Loadern in String- oder JDOM-Objekteumgewandelt und an die aufrufende Importklasse weitergeleitet.Da die Quellen, von denen benötigte Daten angefordert werden, je nach SCM-System deutliche Unterschiede aufweisen, gibt es spezielle Loadermodule für CVS,SVN und SCMBug, die nun vorgestellt werden.

6.2.4.1 CVS-Loadermodule

Für CVS existieren folgende Module:

CvsLogLoader Dieses Modul macht eine cvs log-Abfrage, welche alle hier mög-lichen Informationen anfordert. Ausgabe: Stringobjekt

CvsRAnnotateLoader Ausgeführt wird ein cvs rannotate für eine Datei ineiner bestimmten Revision. Ausgabe: Stringobjekt

CvsDi�Loader Dieses Modul bietet zwei verschiedene Funktionalitäten:

• Vergleich von zwei Revisionen einer Datei. Dies erfolgt durch eine einfachecvs diff Abfrage.Diese Funktion wird bei der Analyse von Dateiänderungen im Laufe der Ent-wicklung verwendet.

• Vergleich von zwei verschiedenen Dateien. Hierbei werden die beiden Dateiennacheinander durch ein cvs checkout geladen und dann mit dem Unix Tooldiff verglichen. Grund: cvs diff bietet diese Möglichkeit nicht.Diese Funktion ist für die Suche nach Dateiäktivitäten durch den EventChecker(vgl. 6.2.8 ) nötig.

Page 74: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

74 KAPITEL 6. DATENIMPORT

6.2.4.2 SVN-Loadermodule

Für SVN existieren folgende Module:

SvnLogLoader Dieses Modul fordert eine svn log-Ausgabe an. Sie enthält eineListe aller existierender Revisionen. Sie wird als XML - Datei zurückgegeben.

SvnInfoLoader Dieses Modul macht eine svn info-Abfrage für eine Datei ineiner bestimmten Revision. Zurückgegeben wird ein Element Objekt, das aus derXML-Ausgabe von SVN erzeugt wird.

SvnAnnotateLoader SVN bietet eine deutliche Vereinfachung für die Parser-module gegenüber CVS: Die Ausgabe kann als XML-Datei erfolgen. Der Svn-

AnnotateLoader nutzt diese Möglichkeit und gibt die XML-Ausgabe von svn anno-

tate als Element Objekt zurück. Es enthält die Informationen für eine Datei in einerbestimmten Revision.

SvnDi�Loader Dieses Modul bietet genau wie der CvsDiffLoader zwei ver-schiedene Funktionalitäten:

• Vergleich von zwei Revisionen einer Datei. Dies erfolgt durch eine einfachesvn diff Abfrage.

• Vergleich von zwei verschiedenen Dateien. Da SVN diese Funktionalität eben-falls über svn diff anbietet, ist hier kein umständliches Laden der Dateienmit anschlieÿendem di� nötig, wie es unter CVS der Fall ist.

Beide Varianten verwenden jedoch nicht das SVN eigene Di� Tool, sondern dasUnix Tool diff. Dies liegt einmal daran, dass die Unix-Variante deutlich leichter zuparsen ist und zum anderen, dass CVS dieses Tool standardmäÿig verwendet undkein externes Tool akzeptiert. Der andere Grund ist, dass dadurch für CVS undSVN das selbe Parsermodul verwendet werden kann.Das Unix Tool steht auch Windows-Nutzern zur Verfügung. Diese können UnxUtils,ein Sourceforge-Projekt, verwenden [19].

6.2.4.3 SCMBug-Loadermodul

SCMBugNameMatchLoader Dieses Modul verwendet ein Perl Script, das vonHolger Schackmann aus dem SCMBug Code extrahiert wurde. Das Script erwartetden SCM-Namen des Entwicklers und die Kon�gurationsdatei des SCMBug Dae-mons (in der Regel: daemon.conf). Rückgabe ist der Bugzilla Entwicklername alsString.

An dieser Stelle kommt das Singleton-Muster zum Einsatz:Da eine wiederholte Abfrage des selben Namens unnötige Rechenzeit kostet, wird imSingleton eine HashMap mit allen bisherigen Anfrageschlüsseln zusammen mit denErgebnissen des Perl-Scripts gesichert. Bei einer neuen Anfrage wird dann zunächstüberprüft, ob das Ergebnis schon in der HashMap steht. Nur wenn dies nicht derFall ist, delegiert das Modul die Anfrage an das Script.

Page 75: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

75

6.2.5 SCM-Objekte

Bevor auf die Parser selbst eingegangen wird, folgt hier eine Zusammenstellungeiniger Datenobjekte. Diese Objekte nehmen die eingelesenen Daten solange auf, bisdiese vom DatabaseVisitor (vgl. 6.2.10) in der SCM-Datenbank gesichert werdenkönnen.

6.2.5.1 Systemspezi�sche Datenobjekte

Einige wenige Objekte modellieren Teilstrukturen der Log-Ausgaben. Sie sind in derRegel nur innerhalb der Importklassen verwendbar und werden möglichst frühzeitigdurch systemunabhängige Datenobjekte ersetzt:

CvsLogEntrySource Enthält die noch nicht ausgelesene cvs log-Ausgabe füreine einzelne Datei in Form von Strings. Die Ausgabe wird nach ihren Bestandteilengetrennt gesichert:

• Kopf der Logausgabe

• Liste der Revisionen

CvsLogHead Dies ist ein Datenobjekt, welches alle im Kopf einer cvs log-Ausgabe für eine einzelne Datei (s.o.) zur Verfügung stehenden Informationen auf-nehmen kann.

CVSRAnnotateLine Die cvs rannotate-Ausgabe enthält für jede der Code-zeilen neben dem Inhalt der Zeile auch Informationen zum Autor, zum Änderungs-datum und zur Revision, in der die letzte Änderung stattfand. Dieses Objekt nimmtletztere drei Daten auf.

6.2.5.2 Systemunabhängige Datenobjekte

Nun folgen Datenobjekte, welche sowohl für CVS- als auch für SVN - Importvorgängeverwendbar sind. Sie zeichnen sich dadurch aus, dass sie - mit Ausnahme einzel-ner systemspezi�scher Objekte - vom verwendeten SCM-System abstrahieren. Sienehmen die gesamte benötigte SCM-Datenmenge auf. Dies führt dazu, dass ein Teildes Quellcodes für die Datenanalyse systemunabhängig geschrieben werden konnteund damit mehrfach verwendbar ist.

Das Schema in Abbildung 6.9 veranschaulicht zunächst die bestehenden Zusammen-hänge:

Es gibt also drei grundlegende Bereiche:

• Datencontainer : Nehmen alle Objekte einer Repository (Dateien, Ordner,Branches, Tags, Revisionen) geordnet auf.

• Repository-Objekte: Revisionsinvariante Informationen zu Dateien, Ordnernund Branches (implizit als Ordner) sowie Revisionen.

• Detailinformationen für eine Revision: Enthalten die sich von Revision zu Re-vision ändernden, also revisionsvarianten Eigenschaften von Repository Ob-jekten.

Im Anschluss folgt nun eine inhaltliche Beschreibung der Objekte. Zunächst werdendie Container vorgestellt und nach und nach die damit in Verbindung stehendenObjekte.

Page 76: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

76 KAPITEL 6. DATENIMPORT

Abbildung 6.9: Übersicht über Datenobjekte und ihre Zusammenhänge

DevelopmentLine(s)Container Einzelne Verzeichnisstrukturen werden einheit-lich als DevelopmentLine angesehen. SVN verwaltet Branches, Tags und Trunk ineiner gemeinsamen Verzeichnisstruktur. Die Revisionsnummern werden unabhängigdavon herauf gezählt, ob es sich um eine Revision für einen Branch, Tag etc. handelt.Deshalb be�ndet sich der gesamte Verzeichnisbaum in einem einzigen Development-LineContainer.Unter CVS müssen die Verzeichnisstrukturen aller Branches und die Struktur desHEAD getrennt werden. Die Revisionsnummern sind getrennt und der Ordner Xunter HEAD hat nichts mit dem Ordner X im Branch 1.2.3 zu tun. Aus diesemGrund verwendet der CVSImport einen DevelopmentLinesContainer, welcher dieexistierenden Branches und die HEAD-Entwicklungslinie getrennt verwaltet. Hier-bei werden sowohl die Branches als auch HEAD einheitlich in DevelopmentLine-

Page 77: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

77

Containern gesichert.Jeder dieser Container verfügt über drei Listen:

• Dateiliste: Enthält alle ScmFile Objekte, die zur DevelopmentLine gehören.

• Ordnerliste: Enthält alle ScmFolder Objekte, die zur DevelopmentLine ge-hören.

• Revisionsliste: Enthält alle Revision Objekte, die zur DevelopmentLine ge-hören.

ScmFile ScmFile Objekte enthalten sämtliche Informationen, die für eine Dateiin einer DevelopmentLine relevant sind. Dies sind auf oberster Ebene Informa-tionen, welche von Revision zu Revision unveränderlich bleiben. Wichtig sind vorallem der Dateiname, Typ, Pfad zur Datei, der Typ der Entwicklungslinie (Branch,Tag, Trunk / HEAD) und ihr Name.Alle Informationen, welche sich nur auf einen bestimmten Revisionsstand beziehen,liegen in untergeordneten Datentypen. Diese Typen sind am Namenssu�x �...De-tails� erkennbar (s.u.) und in der Abbildung 6.9 rechts zu �nden. Es gibt also eineTrennung der revisionsinvarianten von den revisionsvarianten Daten. Dies vermeideteine redundante Datenrepräsentation, welche nötig wäre, wenn zu jeder Dateiver-sion ein vollständiger Datensatz existieren würde.Da Dateien nicht ständig in der SCM-Repository präsent sein müssen, sondern auchentfernt werden können, besitzen sie zwei Zustände. Diese Dateien sind, solange sieexistieren, enabled und disabled nach einem möglicherweise auftretenden Löschvor-gang. Falls ein Dateiname geändert oder die Datei verschoben wurde, wechseltdas ScmFile- Objekt ebenfalls vom Zustand enabled zu disabled und ein neuesScmFile-Objekt wird erzeugt. Das erste Objekt beschreibt dann die Dateioperatio-nen, welche während des Zeitintervalls mit dem alten Dateinamen im alten Pfadausgeführt wurden und das zweite Objekt die Operationen unter neuem Namenbzw. im neuen Pfad. Beide Objekte sind durch die Attribute successorName undsuccessorLocation bzw. previousName und previousLocation miteinander ver-linkt.Der wichtigste untergeordnete Datentyp, der Informationen zu bestimmten Re-visionszuständen beinhaltet, ist für eine Datei der Datentyp ScmFileRevision-

Details:

ScmFileRevisionDetails Dieses Objekt fasst alle veränderlichen Eigenschaften(relativ zum vorigen Revisionsstand oder auch absolut) zusammen. Dies sind:

• absolut: Codezeilen, Arbeitsanteil von Entwicklern in Codezeilen

• relativ: hinzugefügte Codezeilen, geänderte Codezeilen, gelöschte Codezeilen,geänderte Stellen in der Datei

Die Anzahl der Codezeilen X, welche vom Entwickler Y in die Datei geschriebenwurden, also sein Arbeitsanteil an der Datei, ist im Datenobjekt DeveloperFile-Contribution gekapselt, genau dann, wenn dieser Arbeitsanteil gröÿer Null ist.Sämtliche DeveloperFileContributions werden in einer Liste in den ScmFile-

RevisionDetails gehalten.Ähnliches gilt für die geänderten Stellen in der Datei. Hierfür gibt es eine Liste vonElementen des Datentyps DiffElement.

Page 78: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

78 KAPITEL 6. DATENIMPORT

DiffElement Für jede Stelle in der Datei, an der etwas hinzugefügt, gelöscht oderauch verändert wurde, existiert eine Instanz dieses Objekts. Sie liefert neben demÄnderungstyp zusätzlich die Anzahl der Codezeilen, die von der Änderung betro�ensind und den Inhalt der Änderung als String.

Da Tags unter CVS eine andere Bedeutung haben als unter SVN ( siehe 2.2.3 ), istes nötig, zum ScmFile für CVS-Imports eine Liste der gesetzten Tags zu halten.Die Elemente der Liste sind vom Typ CvsTagRevisionDetails.

CvsTagRevisionDetails Wie oben schon erwähnt, weist �...Details� darauf hin,dass dieser Datentyp sich immer nur auf eine Revision bezieht, in der sich die zubeschreibende Datei be�ndet bzw. einmal befand.Instanzen dieses Datentyps enthalten die Information, dass ein Tag (identi�ziertdurch den Tagnamen) in einer bestimmten Revision der Datei hinzugefügt wurde.

Neben Dateien enthalten Repositories auch Ordner, die hier als ScmFolder-Objektemodelliert sind:

ScmFolder Die Datenorganisation in ScmFolder-Objekten folgt dem gleichenSchema wie dem bei ScmFiles. Alle revisionsinvarianten Informationen be�ndensich im Objekt als primitive Datentypen. Bei Namensänderungen oder Ordnerver-schiebungen wird ein neues ScmFolder-Objekt erzeugt, mit dem alten verlinkt undbeide Objektzustände entsprechend gesetzt. Für die revisionsspezi�schen Teile gibtes den Objekttyp ScmFolderRevisionDetails:

ScmFolderRevisionDetails Dieses Datenobjekt liefert im wesentlichen drei Lis-ten, welche den Inhalt des Ordners zum Revisionszeitpunkt darstellen:

• Dateiliste

• Dateitypliste

• Unterordnerliste

In jeder Liste sind Strings der jeweiligen Namen gespeichert.

Sowohl die Revisionsdetails als auch die Datei- und Ordnerobjekte besitzen gemein-same Informationen, die in Vererbungshierarchien zusammengefasst sind.

Bei ScmFile und ScmFolder gibt es die in der Vererbungshierarchie in Abbildung6.10 dargestellten Gemeinsamkeiten und Unterschiede:

Für ScmFileRevisionDetails und ScmFolderRevisionDetails sind dies vor allemInformationen zu den Revisionen selbst, wie z.B. Bugreferenz oder Kommentar. DieHierarchie hierzu zeigt Abbildung 6.11.

Jede neue Revision ist das Resultat von Aktivitäten. Diese können einzeln und inKombination für eine Datei- oder Ordneränderung verantwortlich sein. Wie schonoben angesprochen, gehört zu einer Änderung jeweils ein ScmRevisionDetail. Diedamit in Verbindung stehende (Kombination von) Aktivität(en) wird in einemActivity-Objekt gekapselt.

Activity Da nicht jede Aktivität zu jedem ScmRepositoryObject passt, gibt esfür jeden ScmRepositoryObjekt-Typ eine eigene Activity-Klasse, die spezielleZustände haben kann. Hierbei werden terminale Aktivitäten von den restlichen Ak-tivitäten (non-terminal) unterschieden. Eine Aktivität ist terminal, wenn sie dazu

Page 79: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

79

Abbildung 6.10: Vererbungshierarchie der ScmRepositoryObject - Klassen

Abbildung 6.11: Vererbungshierarchie der ScmRevisionDetails

führt, dass das betro�ene Objekt aus der Repository gelöscht oder in der Daten-struktur des Imports durch ein anderes Objekt ersetzt wird (vgl. ScmFile). Alleanderen Aktivitäten sind non-terminal.

• non-terminal: Inacitve, Add-Activity, Change-Activity, Rename-Activity,Move-Activity, Add- and Change- Activity

• terminal: Remove-Activity, Disable-Activity

Jede Klasse entscheidet selbst, ob sie ein Standardverhalten annimmt (inactive ->Add-Activity ist möglich) oder aufgrund der speziellen Eigenheiten des betrach-teten ScmRepositoryObjects speziell reagiert. Beispiele:

Page 80: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

80 KAPITEL 6. DATENIMPORT

• Tags können zwar hinzugefügt und gelöscht, aber nicht geändert oder ver-schoben werden.

• inactive kann immer, Remove-Activity oder Disable-Activity jedoch nichtmehr geändert werden.

• Ordner können hinzugefügt und gleich geändert werden, indem etwas eingefügtwird.

• Dateien, die in einer Revision hinzugefügt wurden, können nicht in der selbenRevision geändert worden sein.

Alle Activities liegen in einer Vererbungshierarchie (siehe Abbildung 6.12).

Die interne Repräsentation der Zustände erfolgt über Enum-Klassen. Für die obenangesprochenen Aktivitäten, welche grundlegende Operationen beschreiben, gibtes die Klasse BasicActivity. Die aus der Datenbankstruktur stammende Unter-scheidung der Aktivitäten nach den hierdurch manipulierten Repository-Objektenkann über die Klasse ActivityType ausgedrückt werden. Letztere kommen bei derZusammenstellung der Datenbankeinträge im AssociationBuilder zum Einsatz.

Abbildung 6.12: Vererbungshierarchie der Activity - Klassen

Das letzte Datenobjekt, welches in DevelopmentLineContainern gesichert wird, istRevision.

Revision Dieses Objekt enthält zunächst die Eckdaten einer Revision: Kommen-tar, Bugreferenz, Entwickler, Datum, etc. . Darüber hinaus erfordert der ScmEvent-Checker-Algorithmus (siehe 6.2.8) eine Liste von Dateien und Ordnern, welche ineiner bestimmten Revision geändert wurden. Damit diese Listen nicht aus den Scm-Repository Objekten heraus ermittelt werden müssen, besitzt das Revision-Objektentsprechende Listen.

Page 81: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

81

Zum Schluss folgen noch zwei Hilfsobjekte, die von den Import-Klassen (s.u.) dazuverwendet werden, alle Datenobjekte zu sammeln und diese dann den Association-Buildern zu übergeben:

CVSAssociationSource Enthält eine globale Liste von CvsTagRevisionDetailsund den DevelopmentLinesContainer.

SVNAssociationSource Enthält den DevelopmentLineContainer und eine glo-bale Liste von Ordnern, welche während des Imports als Root-Ordner von Tags oderBranches identi�ziert wurden.

6.2.6 Parser

Die Parsermodule für CVS und SVN gehen weitgehend unterschiedlich vor. Da unterSVN für fast alle nötigen Kommandos eine Ausgabe als XML-Datei möglich ist, be-dienen sich die meisten SVNParser-Module der Methoden der Klasse Element, umDaten geordnet auslesen zu können. Für die CVS-Varianten ist dies nicht möglich.Hier liegen die Rohdaten als Strings vor. Die einzelnen Daten müssen mit Hilfe vonregulären Ausdrücken aus dem gesamten String heraus gesucht werden.Um diese Suche zu vereinfachen, teilen die Import-Klassen die Gesamtstrings inkleinere strukturelle Einheiten auf, die dann von speziellen Parsern ausgelesen wer-den.Alle Parser liegen in einer gemeinsamen Vererbungshierarchie. Gemeinsame reguläreAusdrücke sind in Oberklassen de�niert.

Parser für die cvs log-Ausgabe Die cvs log-Ausgaben enthalten für jedeDatei sowohl einen Kopf als auch eine Liste von Revisionen, in der die Datei geän-dert wurde. Die Informationen im Kopf werden vom CvsLogHeadParser gelesen undsehen beispielsweise wie in Abbildung 6.13 aus:

RCS f i l e : . . . / sub f o l d e r / Tes tF i l e1 . java , vWorking f i l e : s ub f o l d e r / Tes tF i l e1 . javahead : 1 . 1branch :l o ck s : s t r i c ta c c e s s l i s t :symbol ic names :keyword s ub s t i t u t i o n : kvt o t a l r e v i s i o n s : 1 ;s e l e c t e d r e v i s i o n s : 1d e s c r i p t i o n :

Abbildung 6.13: Ein Ausgabekopf aus der cvs log-Ausgabe für ein Datei

Der CvsLogRevisionParser ist für einen einzelnen Revisionseintrag zuständig. EinBeispiel für diese Einträge liefert Abbildung 6.14.

Page 82: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

82 KAPITEL 6. DATENIMPORT

r e v i s i o n 1 .1date : 2008−10−21 12 : 32 : 48 +0200; author : root ; s t a t e : Exp ;commitid : PIjvK6aiiOUIVtnt ;bug1 : Kommentar f u e r den commit

Abbildung 6.14: Inhalt einer cvs log-Ausgabe für eine Revision

<logent ry r e v i s i o n="551"><author>christoph_LW</author><date >2008−11−19T14 : 35 : 55 . 465487Z</date><paths>

<path ac t i on="M">/ bugz i l l a_met r i c s / . . . / SCMSettings . java

</path></paths><msg>bug 1 : Adjustments f o r the SVN − Import .</msg>

</logentry>

Abbildung 6.15: Inhalt einer svn log-Ausgabe für eine Revision

Parser für die svn log-Ausgabe svn log bietet im Vergleich zu CVS einekleinere Informationsmenge. Zu jeder Revision gibt es die in Abb. 6.15 gezeigtenDaten.

Für das Einlesen ist in diesem Fall der SVNLogParser zuständig.

Das Problem bei dieser Log-Ausgabe ist, dass die Bestimmung des Objekttyps, alsoOrdner oder Datei, aus einer anderen Log-Ausgabe ermittelt werden muss.Da svn info diese Typ-Information liefert, wird sie aus dieser Log-Ausgabe gele-sen.Die Liste der in einer Revision veränderten Pfade, welche aus svn log gelesen wer-den kann (siehe 6.15) wird allerdings auch verwendet. Beim Einlesen der Detail-Informationen für Dateien wird diese Liste befragt, um tatsächlich nur diejenigenDetails abzufragen, die sich tatsächlich geändert haben. Dies hat positive Auswirkun-gen auf die Laufzeit des Imports.

Parser für die svn info-Ausgabe Da svn log zu wenige Hinweise auf die in ein-er Revision geänderten Objekte liefert, muss dies mittels svn info einzeln für jedeRevision nachgeholt werden. In der zugehörigen Ausgabe (vgl. Abb. 6.16) stehenalle in einer Revision betro�enen Dateien und Ordner, welche vom SvnFileInfo-

XMLParser gesammelt werden:

<entry kind="d i r " path="trunk/ sub fo ld e r1 " r e v i s i o n="4"><url>f i l e : / / / . . . / trunk/ sub fo lder1 </ur l>( . . . )

</entry>

Abbildung 6.16: Auszug aus einer svn info - Ausgabe

Parser für die cvs rannotate-Ausgabe Um ermitteln zu können, welchen An-teil welcher Entwickler an einer Datei hat, muss die rannotate-Ausgabe eingelesenwerden. Sie enthält für jede Codezeile die Revision, in der die Zeile das letzte Mal

Page 83: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

83

geändert wurde, den Autor der Zeile, das Datum der Änderung und den Inhalt (vgl.Abb. 6.17).

1 .1 ( root 21−Oct−08): pub l i c c l a s s Tes tF i l e1 {

Abbildung 6.17: Inhalt einer Zeile der cvs rannotate-Ausgabe

Der CvsRAnnotateCodeLineParser liest immer genau eine dieser Zeilen ein. Da derInhalt für Metrikberechnungen uninteressant ist, wird dieser ignoriert.

Parser für die svn annotate-Ausgabe svn annotate liefert Daten nach Wun-sch auch als XML-Datei. Dies wird vom SvnAnnotateXMLParser genutzt, um diefehleranfälligeren regulären Ausdrücke zu vermeiden. Der Informationsgehalt ent-spricht bis auf den Inhalt der Codezeilen (siehe Abb. 6.18), der aber nicht benötigtwird, dem der cvs rannotate-Ausgabe.

<entry l i n e−number="1"><commit r e v i s i o n="4">

<author>root</author><date >2008−10−21T10 : 51 : 10 . 664104Z</date>

</commit></entry>

Abbildung 6.18: Auszug aus einer svn annotate-Ausgabe

Ähnlich wie bei der Di�-Untersuchung ist die Annotate-Untersuchung nicht beiallen Dateitypen sinnvoll. In der Settings-Datei besteht deshalb die Möglichkeit,bestimmte Dateitypen zu de�nieren, die relevant sind.

Dieses Einlesen der Codezeilen erfolgt ohne die inhaltliche Analyse der Zeilen. EineKommentarzeile hat das gleiche Gewicht, wie die einer Methode.

An dieser Stelle wäre eine spätere Erweiterung um ein aufwändigeres Analysetoolsinnvoll, um die Analysequalität zu erhöhen.

Parser für die di�-Ausgabe Es gibt zwei Parser, die für das Einlesen von Di�-Ausgaben zuständig sind. Beide lesen immer genau einen Eintrag. Dieser könntewie in Abbildung 6.19 aussehen:

6 ,7 c9 ,10< ∗ Ich bin noch a l t .< ∗ Ich auch !−−−> ∗ Hier bin i ch schon geändert .> ∗ Ich auch ! !

Abbildung 6.19: Beschreibung eines einzelnen Zeilenunterschieds in einer Datei auscvs / svn di�

Die erste Zeile sagt aus, dass es sich hierbei um eine Änderung (c(hange)) handelt.Im alten Dateizustand befanden sich die geänderten Zeilen in Zeile 6 und 7, in derneuen Datei in den Zeilen 9 und 10. Insgesamt wurden also zwei Zeilen geändert.Diese Information liest der ScmDiffTypeParser ein.

Page 84: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

84 KAPITEL 6. DATENIMPORT

Die unteren Zeilen enthalten den Dateiinhalt vor und nach der Änderung. Dies wirdvom ScmDiffContentParser eingelesen.

Da eine Di�-Untersuchung nicht bei allen Dateitypen sinnvoll ist, besteht in derSettings-Datei die Möglichkeit, bestimmte Dateitypen zu de�nieren, welche für dieDi�-Untersuchung relevant sind.

6.2.7 ScmRepositoryObjectLinker: Referenzen zwischen Ord-nern und Dateien herstellen

Damit es möglich ist, in BugzillaMetrics einzelne Aktivitäten in Ordnern nach demInhalt des Ordners zu gewichten, müssen Dateien und Unterordner mit den Ordnern,in denen sie liegen, verlinkt werden. Dies gilt für alle SCM-Systeme, sodass eingenerisches Modul verwendet werden kann, welches sowohl für Ordner als auch fürDateien verwendbar ist.Der grundsätzliche Ablauf:

Durchlaufe die Liste aller Dateien bzw. Ordner (im Folgenden: Objekt) einer De-velopmentLine und gehe für jedes Objekt wie folgt vor:

1. Identi�ziere aus dem Objektpfad den Namen und Pfad des Vaterordners.

2. Suche diesen in der Liste aller Ordner der DevelopmentLine. Ergebnis: Zielord-ner

3. Durchlaufe alle Objekt-Details und überprüfe die Aktivität, welche mit jedemeinzelnen Detail D1 verknüpft ist:

(a) D1 beschreibt ADD- oder MOVE-Aktivität:Verlinke Objekt im ScmFolderRevisionDetailD2 des Zielordners, welch-es zur gleichen Revision gehört, wie D1.Setze die Aktivität von D2 auf CHANGED.

(b) D1 beschreibt eine nicht-terminierende Aktivität auÿer ADD oder MOVE:Verlinke Objekt im ScmFolderRevisionDetail des Zielordners, welcheszur gleichen Revision gehört, wie D1.

(c) D1 beschreibt eine terminierende Aktivität:Setze die Aktivität des ScmFolderRevisionDetails des Zielordners, welch-es zur gleichen Revision gehört, wie D1 auf CHANGED.

Die Unterschiede, die sich bei Referenzen von Dateien und Ordnern ergeben, sind:

• Wird das Objekt in der Dateiliste oder in der Ordnerliste des Zielordnersreferenziert?

• Über welche Liste wird iteriert? Über die aller Dateien oder diejenige, in deralle Ordner gelistet sind?

Diese Unterschiede werden in der Klasse ScmLinkUtilities ausgelagert. Der Scm-RepositoryObjectLinker holt sich die zugehörigen Methoden, indem er dynamischzur Laufzeit zunächst ein ScmFolderLinkUtilities Objekt einbindet und im An-schluss ein ScmFileLinkUtilities Objekt. Beide erben von der abstrakten KlasseScmLinkUtilities.Es ergibt sich also folgender Zusammenhang:

Page 85: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

85

Abbildung 6.20: ScmRepositoryObjectLinker verwenden ScmLinkUtilities

Neben der Unterscheidung zwischen Dateien und Ordnern ergeben sich auch zweikleinere Unterschiede bei verschiedenen SCM-Systemen.Da CVS keine Ordner unter Versionskontrolle stellt, gibt es auch kein REMOVE,MOVE oder RENAME von Ordnern. Deshalb besitzen Ordner zum Zeitpunkt derErstellung der ersten Kind-Datei eine Add-Aktivität und keinerlei weitere Aktivi-täten. Dies macht eine Unterscheidung von 3(a) - 3(c) (siehe Algorithmus) unnötig.Unter CVS werden Ordner also fest nach Punkt 3(b) verlinkt.

Abbildung 6.21: Vererbungshierarchie derScmRepositoryObjectLinker

Aufgrund der fehlenden Verbindungvon ScmFolderRevisionDetailsund Revisionsnummern, wer-den ScmFolderRevisionDetailsunter CVS nach Zeitpunktenund nicht, wie in SVN , nachRevisionsnummern sortiert.Dieser Unterschied führt dazu,dass der ScmRepositoryObject-Linker abstrakt ist und fürCVS und SVN Unterklassenmit Implementierungen für o.g.Unterschiede besitzt.

6.2.8 ScmEventChecker:Suche nach Aktivitätenin Ordnern und Dateien

Um die verschiedenen Events in BugzillaMetrics verarbeiten zu können, ist esnotwendig, diese während des Imports zu identi�zieren. Besonderes Augenmerkmuss dabei auf MOVE und RENAME gerichtet werden, da es sich bei einemAuftreten von REMOVE in Revision x und ADD in Revision x+1 um versteck-te MOVE- oder RENAME-Aktivitäten handeln kann.Da CVS beim Verschieben oder Umbenennen von Dateien deren History verliert, istdie REMOVE-ADD-Folge der einzige an den CVS-Schnittstellen erkennbare Hin-weis auf ein solches Verschieben oder Umbenennen.SVN verliert die History zwar nicht, der Zusammenhang zwischen der Datei amalten Ort / mit altem Namen und der selben Datei am neuen Ort / mit neuemNamen wird aber über die SVN-Schnittstellen trotzdem nicht deutlich.

Page 86: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

86 KAPITEL 6. DATENIMPORT

Ähnlich wie beim ScmRepositoryObjectLinker gibt es bei der Eventsuche unterCVS und SVN viele Gemeinsamkeiten, die in den abstrakten Klassen ScmEvent-

Checker und ScmFileEventChecker liegen.Aufgrund der fehlenden Versionskontrolle für CVS-Ordner gibt es hier nur Add-

FolderEvents beim erstmaligen Auftreten und ChangeFolderEvents, wenn sichihr Inhalt ändert. Die zugehörigen Aktivitäten werden bereits im ScmRepository-

ObjectLinker gesetzt, sodass ein CVSFolderEventChecker unnötig ist.Die Klassenhierarchie für alle EventChecker hat also eine Struktur die in Abbildung6.22 zusammengefasst ist.

Abbildung 6.22: Klassenhierarchie der ScmEventChecker

Der Suchalgorithmus orientiert sich sowohl für CVS als auch für SVN am folgendenAnsatz:

Es werden in jedem Suchschritt jeweils Objektlisten - entweder Dateilisten oderOrdnerlisten - zweier Revisionen verglichen.Unter SVN sind dies zwei Revisionen n und m, welche direkt aufeinander folgen. Esmuss hier jedoch nicht gelten: m = n + 1. Der Administrator eines SVN-Systems hatdie Möglichkeit, in einer einzigen Repository verschiedene Projekte gemeinsam zuverwalten. Dies hat zur Folge, dass es in einem Projekt, welches sich eine Repositorymit anderen Projekten teilt, Lücken in den Revisionsnummern geben kann.

Unter CVS wird immer die Liste zu Revision X.1 mit den Elementen zu X.n ver-glichen, die in der Log-Ausgabe zur Revision X.n als dead markiert sind. Diesentspricht einem (angeblichen ?) REMOVE.

Beim Vergleich wird jeweils eine Liste deletedObjects erstellt, die alle Elementebeinhaltet, welche in der früheren Revisionsliste, aber nicht in der späteren ent-halten sind. Eine weitere Liste addedObjects enthält diejenigen Elemente, für dieumgekehrtes gilt.Ist deletedObjects leer, sind alle Elemente in addedObjects tatsächlich neu und kön-nen in Revision n+1 als ADD markiert werden.Falls addedObjects leer ist, wurden alle Elemente in deletedObjects tatsächlich ge-löscht und werden disabled gesetzt sowie für die Revision n+1 mit REMOVEmarkiert.

Anderes gilt, wenn beide Listen Elemente enthalten. In diesem Fall ist eine ver-

Page 87: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

87

steckte MOVE oder RENAME Aktivität möglich.An dieser Stelle ist die Gefahr groÿ, dass der Algorithmus unnötig viele Vergleichedurchführt, da es mitunter viele Objekte in beiden Listen addedObjects und deleted-Objects geben kann. Besonders ist dies bei CVS der Fall, da hier sämtliche Dateienin der Revision 1.1, mit der immer verglichen wird (s.o.), vorliegen.Diese Menge an Vergleichen wird aber durch folgende Heuristiken ge�ltert:

• Der Zeitpunkt, zu dem das Objekt in addedObjects in der betrachteten Revi-sion vorlag, liegt nie vor dem Zeitpunkt, zu dem das Objekt in deletedObjectsin der entsprechend anderen Revision vorlag. Einfacher: Man kann das Objektnicht schon an neuer Stelle bzw. mit neuem Namen hinzufügen, bevor es analter Stelle bzw. mit altem Namen gelöscht wurde.

• Die Zeitspanne zwischen dem Entfernen des Objekts in alter Version unddem Hinzufügen des selben Objekts in neuer Version ist in der Regel klein.Der Algorithmus erlaubt die Anpassung der Zeitspanne in der settings.xmlDatei.

• Falls die Objekte Dateien sind: Die Dateitypen ändern sich sowohl beim Ver-schieben als auch beim Umbenennen nicht. Beide Objekte müssen also dengleichen Dateityp haben.

• Das Verschieben eines Objekts von einem Branch in einen anderen - beiSVN gilt dies auch für Tags - ist bei der EventChecker-Suche problema-tisch, da es sich bei verschiedenen Branches oder auch Tags um mehr oderweniger ähnliche Kopien handelt. Der Suchalgorithmus würde deshalb sehrviele falsch-positive Befunde liefern. Aus diesem Grund wird die Branch- oderTag-übergreifende Suche verhindert.

Diese Heuristiken führen zu einer deutlichen Einsparung an Rechenzeit.

Vorgehen bei Dateien Die Überprüfung bei Dateien erfolgt über die Berech-nung des prozentualen Zeilenunterschieds auf Grundlage einer di�-Abfrage. Hierdarf der Wert einen maximalen Unterschiedswert MAXDIFFPERCENTAGE , derals Konstante de�niert werden kann, nicht übersteigen. Falls nun gilt

Anzahl der unterschiedlichen ZeilenAnzahl der Zeilen in der neuen Datei > MAXDIFFPERCENTAGE

wurde ein MOVE oder RENAME gefunden. Die alte Dateiversion, die in deleted-Objects lag, wird disabled gesetzt und die beiden Dateien über die Attribute previous-Name / successorName und previousLocation / successorLocation verlinkt.Falls nun die Pfade zur Datei übereinstimmen, wurde die Datei umbenannt. Dieneue Version aus der addedObjects-Liste wird mit RENAME markiert. Wenn diePfade unterschiedlich sind, handelt es sich um ein MOVE. In diesem Fall wird dieneue Version entsprechend mit MOVE markiert.

Falls der Vergleich ergibt, dass die Dateien unterschiedlich sind, werden die Dateienmit REMOVE bzw. ADD markiert.

Vorgehen bei Ordnern Bei Ordnern wird ein prozentualer Unterschied mit Hil-fe der in den Ordnern enthaltenen Dateien und Unterordnern ermittelt.Sowohl für die Dateilisten als auch Ordnerlisten werden diejenigen Elemente er-mittelt, die hinzugekommen bzw. verschwunden sind. Die Berechnung sieht dann

Page 88: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

88 KAPITEL 6. DATENIMPORT

folgendermaÿen aus:

Anzahl der in der neuen Liste nicht mehr vorhandenen DateienGesamtzahl der in beiden Listen enthaltenen Dateien

+ Anzahl der in der neuen Liste hinzugekommenen DateienGesamtzahl der in beiden Listen enthaltenen Dateien

+ Anzahl der in der neuen Liste nicht mehr vorhandenen OrdnerGesamtzahl der in beiden Listen enthaltenen Ordner

+ Anzahl der in der neuen Liste hinzugekommenen OrdnerGesamtzahl der in beiden Listen enthaltenen Ordner

Falls dieser Wert gröÿer als der festgelegte maximale Unterschied ist, handelt es sichwieder um ein MOVE oder RENAME, ansonsten liegt ein REMOVE bzw. ADDvor. Dies wird analog zum Vorgehen bei Dateien markiert.

Abbildung 6.23 zeigt ein Beispiel, welches das Vorgehen nochmals veranschaulichensoll.

Abbildung 6.23: Beispiel für die Tätigkeiten des ScmEventCheckers

Die Unterschiede zwischen CVS und SVN bei den EventCkechern, welche obenbeschriebene Unterklassenbildung erfordern, sind nun:

• Die zu vergleichenden Listen müssen unterschiedlich ausgewählt werden.

• Aufgrund der unterschiedlichen Revisionspaare, die verglichen werden, ergebensich Unterschiede beim Markieren der Objekte.

• Di�-Aufrufe müssen an das jeweilige SCM-System angepasst werden.

Page 89: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

89

6.2.9 AssociationBuilder: Vorbereitungen zum Sichern derDaten in die Datenbank

Da sich die Struktur der eingelesenen Daten von der in der SCM-Datenbank un-terscheidet, müssen die Informationen für Tabelleneinträge gesammelt und einzelneEinträge über ihre ID miteinander verlinkt werden.Diese Aufgabe übernehmen AssociationBuilder. Sie erhalten die eingelesenenDaten vom Import mittels CVSAssociationSource- bzw. SVNAssociationSource-Objekten und delegieren die eigentliche Schreiboperation an einen DatabaseVisitor,der später noch vorgestellt wird. Diese Delegation erfolgt für jeden Tabelleneintragseparat. Falls also alle Spalteninformationen zu einem Eintrag vorliegen, werdendiese Informationen in einem TableEntry-Objekt gekapselt und an den Database-

Visitor übergeben.

Für jede Tabelle in der SCM-Datenbank gibt es eine TableEntry-Klasse. Dies sindDatenobjekte, die alle Spalteninformationen aufnehmen.

Die verschiedenen Datenbankeinträge werden von einem einzigen Association-

Builder in der Reihenfolge ihrer Abhängigkeiten zusammengestellt, wobei es hieraufgrund der unterschiedlichen Bedeutung von Branches und Tags in CVS und SVNunterschiedliche Abläufe gibt.

Generell müssen zunächst die Einträge zu Entwicklern, Branches und Tags geschrie-ben werden, da diese keine Referenzen zu anderen Tabelleneinträgen erfordern. Esfolgen alle Ordner. Diese sind mit den Branches bzw. Tags (nur für SVN) , zu denensie gehören, verlinkt. Erst dann können Dateien geschrieben werden, da diese einenVerweis auf den Ordner, in denen sie liegen, enthalten.Zum Schluss können dann die Branch-, Tag-, File- und FolderActivity-Einträgein beliebiger Reihenfolge geschrieben werden. Zu jedem Activity-Eintrag gehörtein damit in Verbindung stehender Eintrag in der ScmRevisionActivityHistory-Tabelle.

Zu jeder Tabelle, deren Einträge mit anderen Tabelleneinträgen verlinkt sind, gibtes eine HashMap. Diese sammelt die IDs der existierenden Einträge.

Eine Zusammenstellung der genauen Tabelleninhalte �ndet sich im Kapitel 4.2 undwird hier nicht näher beschrieben.Die meisten TableEntry-Objekte sowie ein Groÿteil der Kommunikation mit demDatabaseVisitor ist vom SCM-System, welches als Datenquelle dient, vollkommenunabhängig. Die zugehörigen Methoden liegen in der Klasse AssociationBuilder.Für die SCM-spezi�schen Teile gibt es die Cvs- und SvnAssociationBuilder:

Wie oben schon angesprochen unterscheidet sich die Organisation der Schreib-vorgänge beim CVSImport leicht von der beim SVNImport:

6.2.9.1 CvsAssociationBuilder

Beim Import von CVS-Daten arbeitet der CvsAssociationBuilder wie folgt:

1. Schreibe alle Tags in Scm_Tag-Tabelle.

2. Iteriere über alle Branches.

(a) Schreibe aktuellen Branch in Scm_Branch-Tabelle.

Page 90: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

90 KAPITEL 6. DATENIMPORT

Abbildung 6.24: Vererbungshierarchie zu AssociationBuildern

(b) Ergänze Developer-Tabelle mit allen neuen Entwicklern, die im Branchaktiv sind.

(c) Schreibe alle Ordner in die Scm_Folder-Tabelle.

(d) Schreibe alle Ordneraktivitäten in die FolderActivity-Tabelle mit Ref-erenzen auf die zugehörigen Ordner und erstelle Einträge in der Scm-Revision_Activity_History-Tabelle zu den neuen Aktivitäten.

(e) Schreibe alle Dateien in die Scm_File-Tabelle.

(f) Schreibe alle Dateiaktivitäten in die FileActivity-Tabelle mit Referenzenauf die zugehörigen Dateien und erstelle Einträge in der Scm_Revision_-Activity_History-Tabelle zu den neuen Aktivitäten.

(g) Schreibe Tag Aktivitäten in TagActivity-Tabelle mit Referenzen auf diezugehörigen Tags und erstelle Einträge in der Scm_Revision_Activity_-History-Tabelle zu den neuen Aktivitäten.

(h) Schreibe Branch Aktivitäten in BranchActivity-Tabelle mit Referenzenauf den aktuellen Branch und erstelle Einträge in der Scm_Revision_-Activity_History-Tabelle zu den neuen Aktivitäten.

6.2.9.2 SvnAssociatonBuilder

Der SvnAssociationBuilder geht folgendermaÿen vor:

1. Schreibe alle Entwickler in Developer-Tabelle.

2. Schreibe alle Branches in Scm_Branch-Tabelle.

3. Schreibe Branch Aktivitäten in BranchActivity-Tabelle mit Referenzen aufden zugehörigen Branch und erstelle Einträge in der Scm_Revision_Activity_-History-Tabelle zu den neuen Aktivitäten.

4. Schreibe alle Tags in Scm_Tag-Tabelle.

Page 91: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

91

5. Schreibe Tag Aktivitäten in TagActivity-Tabelle mit Referenzen auf die zuge-hörigen Tags und erstelle Einträge in der Scm_Revision_Activity_History-Tabelle zu den neuen Aktivitäten.

6. Schreibe alle Ordner in die Scm_Folder-Tabelle.

7. Schreibe alle Ordneraktivitäten in die FolderActivity-Tabelle mit Referenzenauf die zugehörigen Ordner und erstelle Einträge in der Scm_Revision_-Activity_History-Tabelle zu den neuen Aktivitäten.

8. Schreibe alle Dateien in die Scm_File-Tabelle.

9. Schreibe alle Dateiaktivitäten in die FileActivity-Tabelle mit Referenzen aufdie zugehörigen Dateien und erstelle Einträge in der Scm_Revision_Activity_-History-Tabelle zu den neuen Aktivitäten.

6.2.10 DatabaseVisitor

Die Sicherung der importierten Daten erfolgt über den DatabaseVisitor.Er kennt die Struktur der Datenbanktabellen und liefert eine Vielzahl an Methodenfür die Datenbankkommunikation. Es handelt sich also hierbei um ein Muster desTyps Visitor.Der Visitor stellt Methoden zum Einfügen neuer Tabelleneinträge zur Verfügung,welche die ID des neuen Eintrags oder eine schon bestehende, falls der Eintragbereits in der Datenbank existiert, zurückgibt. Auÿerden kann eine direkte An-forderung der ID eines Eintrags gestellt werden.

6.3 Benutzerschnittstelle des SCM-Imports

Da der Importvorgang automatisch abläuft, ist ein gra�sches Tool zwar für diebenötigten Einstellungen komfortabel, aber nicht unbedingt erforderlich. Auch auchZeitgründen ist die Schnittstelle deshalb ein Kommandozeilentool, das lediglich denTyp des Versionsmanagementsystems verlangt:

ScmImport [cvs|svn]

Die angesprochenen Einstellungen müssen in der allgemeinen Kon�gurationsdateisettings.xml vorgenommen werden.

6.4 Einbindung externer Programme

6.4.1 Problembeschreibung

Bei der Einbindung von Versionsmanagementsystemen, der Installation des SCM-Bug Daemons und verschiedenen Systemkommandos, wie z.B. Änderung der Sys-temzeit für das TestCase-Setup, besteht eine Plattformabhängigkeit. Bugzilla, CVSund SVN werden üblicherweise auf einem Unix-System laufen, können aber zuTestzwecken auch unter Windows eingesetzt werden. Um den Programmcode nunmöglichst frei von systemabhängigem Code zu halten, ist eine Abstraktion von ex-ternen Programmen nötig.

Page 92: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

92 KAPITEL 6. DATENIMPORT

6.4.2 Anforderungsanalyse

Die im Rahmen dieser Arbeit verwendeten externen Programme können und sollenalle über Kommandozeilenbefehle verwendet werden.

Die Einbindung dieser Programme muss folgenden funktionalen Anforderungengerecht werden:

• Vollständige Abstraktion vom Betriebssystem und von Kommandozeilenbe-fehlen.

• Zusammenstellung einer Menge von Methoden, welche alle vom SCM-Importbenötigten Programmfunktionen anbietet.

• Kontrolle der korrekten Programmterminierung.

• Abfangen aller Fehlermeldungen.

Nicht-funktionale Anforderungen sind:

• Unterstützung von Windows- und Linux-Betriebssystemen.

• Leichte Erweiterungsmögichkeit um weitere Betriebssysteme.

6.4.3 Designbeschreibung

Die diversen CVS- und SVN-Befehle werden üblicherweise über die Kommandozeilegegeben. Demnach kann schon ab der Kommandoebene von systemabhängigen Teilenabstrahiert werden.Dies wird von einer sog. OSCommandProvider-Klasse übernommen. Sie selbst istnicht instantiierbar, sondern enthält abstrakte Methoden, die Kommandozeilenbe-fehle in Form von Strings liefern. Es gibt nun für jede Betriebssystemvariante einekonkrete Unterklasse, welche die Methoden systemspezi�sch implementiert (sieheAbbildung 6.25).

Abbildung 6.25: OSCommandProvider-Struktur

Auf der Verwenderseite kann nun über die Methode getOSCommandProvider() eineInstanz dieser Klasse angefordert werden, welche die für das laufende Betriebssystemeine geeignete �Kommandokollektion� bereitstellt.

Page 93: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

93

6.4.4 Designgründe

• Die Verwendung einer Kommandokollektion stellt eine einfache und kompakteAbstraktion vom System dar.

• Die Befehle sind in nur einem Modul gekapselt, was die Verwendung einerneuen Betriebssystemvariante schnell möglich macht.

• Da die Entscheidung für eine bestimmte Instanz in der Methode getOS-

CommandProvider() getro�en wird, benötigt der Anwender dieser Methodekeine Kenntnis vom verwendeten Betriebssystem.

• OSCommandProvider werden dynamisch zur Laufzeit eingebunden.

• Die Rückgabe aller Output-Daten an das aufrufende Objekt erfolgt einheitlichdurch Text- und XML-Dateien.

Page 94: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

94 KAPITEL 6. DATENIMPORT

Page 95: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

Kapitel 7

Erweiterungen im

BugzillaMetrics-Kern

Die Architektur des Programmkerns von BugzillaMetrics (siehe [10]) wurde vonLars Grammel so entworfen, dass eine Erweiterung um neue Basis�lter, Events undWeights leicht möglich ist, ohne die Architektur zu ändern.Einige wenige Punkte mussten allerdings doch geändert werden. Hierzu zählt dieAbstraktion der SQL-Schnittstelle für verschiedene DataSources und die damit inVerbindung stehende Erweiterung der SQLFacade.Eine weitere Änderung beziehtsich auf die Realisierung des Erweiterungspunktes für die SCM-Integration.

Zunächst wird beschrieben, wie die Daten, welche aus der SCM-Datenbank stam-men, innerhalb des Kerns von BugzillaMetrics repräsentiert werden. Es folgen dieBaseFilter und Events der Integration. Vor der Vorstellung der Weights, die in derAnforderungsanalyse gefordert wurden, wird es um zwei Themenbereiche gehen, dieTeil des Kern-Designs sind und auch für die Integration relevant sind: DataSourcesbzw. EventSources und EventFilter.

Der letzte Abschnitt befasst sich kurz mit der Erweiterung des BugzillaMetricsFrontends und der Installation der SCM-Integration.

7.1 Datenrepräsentation

Die bestehende Datenrepräsentation ist für die Anforderungen der Bugzilla-Datenausreichend, für die SCM-Integration jedoch nicht.

Das wesentliche Datenobjekt heiÿt Field. Ein Field beschreibt den Typ eines Da-tums, welches zu einem bestimmten Case gehört. Beispielsweise kann der Case 123den Status assigned haben. Der Typ dieses Datums ist status, zu dem das Fieldstatus gehört. In diesem Fall mappt Case 123 das Field status nach assigned. DerWert steht also nicht im Field selbst. Fields werden in DataSources bereitgestellt.

Bugzilla hat, bis auf Datentypen zu Flags und Kommentaren, nur solche, welchefür jeden Case genau einen Wert haben. In der SCM-Integration ist dies anders,da z.B. viele Dateien von einem Case betro�en sein können. Aus diesem Grundwurde die Funktionalität von Fields erweitert: Es kann nun single-valued Fields

und multi-valued Fields geben. Diese Entscheidung wird bei der Instantiierung derFields getro�en.

Eine andere Anforderung der SCM-Integration sind Daten, die nicht einen Case,sondern die in ihm enthaltenen Objekte, wie z.B. Dateien, beschreiben. Für diese

95

Page 96: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

96 KAPITEL 7. ERWEITERUNGEN IM BUGZILLAMETRICS-KERN

Daten bietet das BugzillaMetrics-Design keine Unterstützung. Da diese feingranu-laren Daten immer im Rahmen eines Events auftreten, wie die Anzahl der hinzuge-fügten Codezeilen bei einem FileChangeEvent, speichert die SCM-Integration dieseDaten innerhalb der SCM-Events. Dies geschieht durch EventDetail-Objekte.

Diese Erweiterungen beeinträchtigen an keiner Stelle die Funktionalität des bisheri-gen Kerns, da es sich überall um passive Objekte handelt, die von den Verbrauch-ern, CaseFilter und EventWeights nicht verwendet werden. Nur die CaseFilter undWeights der SCM-Integration nutzen diese Funktionalität. Eine Ausnahme bildenFlagFields, die auch im Kern multi-valued sind.

Eine nähere Beschreibung des Designs folgt in den nächsten Abschnitten.

Das Beispiel in Abbildung 7.1 soll die Erweiterung noch einmal veranschaulichen.

Abbildung 7.1: Beispiel zur erweiterten Datenrepräsentation

Zum Case 4 gehört die Datei TestFile, die in den Revisionen 23 und 24 vorliegt.Sowohl die Datei selbst, als auch die beiden Revisionen sind vom Case betro�en,liegen also in den entsprechenden Fields zum Case. Die Fields be�nden sich in denDataSources FileDataSource bzw. RevisionDataSource und sind multi-valued.Für den Wechsel der Datei in Revision 24 gibt es einen FileChangeEvent, der zumCase gehört. Dies wird dadurch ausgedrückt, dass im Event neben dem Datum desEvents auch die ID des Cases gesichert ist. Zum Event gehört hier nicht nur derCase, sondern auch die Datei, die von der Aktivität des Events betro�en ist, unddie Detaildaten, welche zum Eventzeitpunkt aktuell waren.Falls nun eine Metrikspezi�kation alle Cases �ltert, welche die Datei TestFile betref-fen, nutzt der CaseFilter �le das FileField für seine Filteroperation. Er nutzt nichtdie Daten des Events, da er Cases und nicht Dateidetails oder Eventinformationenbenötigt.Eine Metrikspezi�kation, die auf Codezeilenebene geht, nutzt hingegen das Event-Weight loc, was auf die FileDetails innerhalb des Events angewiesen ist.

7.2 BaseFilter

Wie schon in der Anforderungsanalyse festgestellt, ist der Basis�lter um folgendeAspekte zu erweitern:

Page 97: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

97

branch, bugzillaDeveloper, �le, �letype, folder, revisionID, scmDeveloper und tag

Für die hinzuzufügenden BaseFilter bedarf es keiner speziellen Architektur, da dieFilterung von StateFiltern des Kerns durchgeführt wird (siehe [10]). Die Werte,nach denen gesucht wird, stehen in Fields. Bei der BaseFilter-Spezi�kation ein-er Metrik muss der Nutzer dazu den Namen des Fields und den Suchschlüsselangeben. Die Namen der Fields entsprechen den o.g. Bezeichnungen.

Die angesprochenen Fields werden in DataSources gesichert, deren Beschreibungim Abschnitt 7.5 folgt.

Das Vorgehen, bei der Filterung von Cases Fields zu verwenden und diese mitDataSources zu verwalten, wurde von [10] übernommen, um eine einheitliche Ver-waltung der für die Metriken benötigten Daten umzusetzen.

7.3 Events

7.3.1 Problembeschreibung

Wie schon in der Anforderungsanalyse festgestellt, ist das System um folgendeEvents zu erweitern:

• Bezogen auf Revisionen: RevisionEvent

• Bezogen auf Dateien: FileCreationEvent, FileChangeEvent, FileRename-Event, FileMoveEvent, FileRemoveEvent

• Bezogen auf Verzeichnisse: FolderCreationEvent, FolderChangeEvent, Folder-RenameEvent, FolderMoveEvent, FolderRemoveEvent

• Bezogen auf Branches: BranchCreationEvent, BranchRemoveEvent

• Bezogen auf Tags: TagCreationEvent, TagRemoveEvent

7.3.2 Designbeschreibung

Das Design im BugzillaMetrics-Kern lässt keinen Spielraum bei der Gestaltung derEvents zu. Jede der o.g. Eventarten muss eine Unterklasse der gleichnamigen Ob-jektklasse Event sein. Um die Berechnung von Weights zu erleichtern, die z.T.alle Events eines Objekttyps gleich behandeln, existiert für jeden Objekttyp eineübergeordnete Ebene der Vererbungshierarchie (siehe 7.2).

In der Abbildung zeigt sich die in der Anforderungsanalyse geforderte Trennung derSCM-Komponenten von denen des Kerns. Das übergeordnete Paket heiÿt hier scm.Alle SCM-Klassen, die zum Kern gehören, liegen in einem Paket mit dem NamencoreExtensions, dessen innere Paketstruktur der des Kerns entspricht.

Die Attribute der Events liegen in den Eventklassen auf Objektebene, also Branch-,File-, Folder, Revision- und TagEvent. Die Eventklassen, die spezielle Aktivitätenbeschreiben, wie z.B. FileCreationEvent, sind einfache Unterklassen.

Für Branches und Tags wird nur der Name gesichert. In den File- und FolderEventswerden die in 6.2.5.2 angesprochenen Details verwendet. Die Abbildung 7.3 zeigtanhand der FileEventDetails die darin enthaltenen Informationen: Unter File-EventDetails liegen die Informationen, welche die Datei betre�en, zu der derFileEvent eine Aktivität beschreibt. Diese enthält eine Liste der Entwickler, die

Page 98: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

98 KAPITEL 7. ERWEITERUNGEN IM BUGZILLAMETRICS-KERN

Abbildung 7.2: Überblick über Event - Klassen

mindestens eine Codezeile zur Datei beigetragen haben. Zu jedem Entwickler ex-istiert ein FileContributor-Objekt, das neben dem Namen auch die von ihm beige-tragenen Codezeilen enthält. Zur Zeit werden die Detailinformationen zu den Ent-wicklern noch nicht verwendet. Sie ermöglichen aber beispielsweise ein Weight, dasCodezeilen auf Entwicklerebene berechnet.Die RevisionEvent-Klasse hält die Anzahl der mit ihr verbundenen Aktivitätenfest. Dies sind alle Aktivitäten, welche in dem Commit enthalten sind, zu dem derRevisionEvent gehört.

Designbegründung: Struktur der Vererbungshierarchie von Events

Diese Struktur ermöglicht eine einfache Identi�kation der Events übereine instanceOf - Abfrage sowohl auf Objektebene als auch auf derspeziellen Aktivitätsebene. Dies ist bei der Realisierung der Weights,welche teilweise alle Events zu einem Objekttyp gleich, teilweise aberauch unterschiedlich behandeln, hilfreich.

Page 99: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

99

Die Erzeugung eines Events erfolgt in der initValues(Case c, ResultSet sql-

Result)-Methode derjenigen DataSource, in der die zugehörigen Fields der SCM-Objekte verwaltet werden. Beispielsweise werden die FileEvents in der FileData-Source erzeugt. Diese verwaltet gleichzeitig die FileFields.

Abbildung 7.3: Überblick über die Inhaltevon FileEventDetails

Alle Events bleiben solange in derDataSource, bis diese eine Anfragenach einer EventSource erhält. Indiesem Fall wird eine neue EventSourceerzeugt, die nun alle Events aufnimmt.EventSources werden vom Bugzilla-Metrics-Kern für die chronologischeBerechnung der Events benötigt.

7.4 EventFilter

Damit die Verbindung zwischen Event-Objekten im BugzillaMetrics-Kern undder Selektion von Events innerhalbeiner Metrikspezi�kation geknüpft wer-den kann, verwendet der Kern Event-

Filter. Hierzu gibt es zu jedemEvent einen EventFilterReader, derdie Bezeichnung des Events in denMetrikspezi�kationen und den dazuge-hörigen EventFilter de�niert. Der Fil-ter selbst de�niert, welche Fields fürdie Berechnung eines Event-Weightsbenötigt werden und gibt die Klassedes dazugehörigen Events an. Abbil-dung 7.4 beschreibt das Design anhandvon Branches. Das Design ist für alleEventFilter gleich.

7.5 DataSources und EventSources

Nach der Beschreibung der Fields und Events kann an dieser Stelle nun auf dieVerwaltung dieser Objekte eingegangen werden. Das Vorgehen wurde wiederum von[10] übernommen, um eine einheitliche Verwaltung der für die Metriken benötigtenDaten umzusetzen. Aufgrund der zweiten Datenquelle, die SCM-Datenbank, undder Realisierung des Erweiterungspunktes, musste die Architektur leicht erweitertwerden.Die Abbildung 7.5 liefert einen Überblick über Data- und EventSources am Beispielvon Branches. Für die anderen Objekttypen gilt das gleiche.

Die BranchDataSource erbt letztendlich von der Klasse DataSource, welche alleexistierenden BranchFields in einer Map hält. In der Hierarchie zwischen bei-den Klassen be�ndet sich die Abstraktion der Datenquellen, also für die MySQL-Datenbank. Die übergeordnete Klasse heiÿt AbstractSQLDataSource. Sie stellt dieFunktionalität zur Verfügung, die Datenbank-Queries ermöglicht, abstrahiert abervon der speziellen Datenbank. Diese Spezialisierung erfolgt in zwei untergeordnetenKlassen, von denen die AbstractSCMDataSource in der Abbildung zu sehen ist. Sie

Page 100: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

100 KAPITEL 7. ERWEITERUNGEN IM BUGZILLAMETRICS-KERN

Abbildung 7.4: EventFilter am Beispiel von Branches

implementiert die Methode executeQuery(...), welche die Query an die SCM-Datenbank schickt. Für den BugzillaMetrics-Kern gibt es die AbstractBugzilla-

DataSource, welche gleiches auf der Bugzilla-Datenbank ausführt.

Das System besitzt viele verschiedene DataSources für Daten aus Bugzilla undvon SCM-Systemen. Falls der Anwender die SCM-Integration nicht benötigt, ist dieBereitstellung der SCM-DataSources über�üssig und würde nur Ressourcen ver-brauchen. Aus diesem Grund gibt es CoreConfigurations. Für eine Kon�gurationohne Integration existiert die Klasse CoreConfigurationBugzilla, für die Inte-gration die CoreConfigurationBugzillaUsingScm. Letztere ist eine Unterklassevon CoreConfigurationBugzilla, da bei Verwendung der Integration auch dieBugzilla-DataSources geladen werden müssen. Die DataSources melden sich beientsprechenden Instanzen beider Klassen an, was dazu führt, dass diese vor einerMetrikberechnung die erforderlichen Fields bereitstellen.

Die EventSources, die schon im vorigen Abschnitt angesprochen wurden, sind gegendas Interface EventSource implementiert und be�nden sich im gleichen Paket, wiedie DataSources.

Das Paket scmExtensions enthält folgende Sources:

DataSources: BranchDataSource, DeveloperDataSource, FileDataSource, File-typeDataSource, FolderDataSource, RevisionDataSource, TagDataSource

EventSources: BranchEventSource, FileEventSource, FolderEventSource, Re-

Page 101: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

101

Abbildung 7.5: Architektur: DataSources und EventSources

visionEventSource, TagEventSource

Zu Entwicklern und Dateitypen gibt es keine Events, also auch keine EventSources.

7.6 Weights

7.6.1 Problembeschreibung

Wie schon in der Anforderungsanalyse festgestellt, ist das System um folgendeWeights zu erweitern:

loc, addedLoc, changedLoc, deletedLoc, numberOfDevelopers, numberOfFi-

les, numberOfFiletypes, numberOfSubfolder, numberOfBranchEvents, number-

OfFileEvents, numberOfFolderEvents, numberOfTagEvents

7.6.2 Designbeschreibung

Zu jedem dieser Weights gibt es eine Klasse, welche gegen das Interface Weight ausdem core-Paket implementiert ist. Die Klassen enthalten die Methode calculate-

Page 102: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

102 KAPITEL 7. ERWEITERUNGEN IM BUGZILLAMETRICS-KERN

ValueFor(event Event), in welcher der Metrikwert zu event berechnet wird. Ähn-lich wie bei DataSources müssen sich alle Weights anmelden, um verfügbar zu sein.Dies geschieht über eine Instanz von WeightReaderBugzillaUsingScm. Hierzu gibtes auch eine Version ohne SCM-Integration, die WeightReaderBugzilla heiÿt. Hi-er wird also der gleiche Ansatz zur Realisierung des Erweiterungspunkts bzw. zurRessourcenschonung verwendet, wie es auch bei CoreConfiguration der Fall ist.Abbildung 7.6 stellt die angesprochenen Beziehungen anhand von NumberOfFiles-

Weight beispielhaft dar. Für die anderen Weights gilt das gleiche.

Abbildung 7.6: Weights und WeightReaderBugzilla

7.7 Erweiterung des Frontends, Installation der SCM-Integration

BugzillaMetrics wird vom Anwender als Web-Applikation gestartet. Neben einemEditor, der die manuelle Spezi�kation von Metriken in Form von XML-Syntax er-möglicht, kann der Anwender zusätzlich Metrikspezi�kationen generieren lassen.Dies erfolgt durch die Auswahl der benötigten Events, Weights und BaseFilter

mittels gängiger GUI-Elemente.

Die hier beschriebene SCM-Integration verlangt keine Erweiterung dieser gra�s-chen Ober�äche, sondern fügt den existierenden GUI-Elementen in den BereichenBaseFilter, Event und Weights nur zusätzliche Funktionen hinzu.Aus diesem Grund wird an dieser Stelle auf den BugzillaMetrics-Guide (siehe [4] )verwiesen.

Der Erweiterungspunkt für die SCM-Integration in diesem Frontend bildet die Dateisettings.xml. Diese enthält alle Funktionen des Frontends in Form von XML-Elementen, wobei die SCM-Funktionen standardmäÿig auskommentiert sind.

Die Installationsbeschreibung der SCM-Integration be�ndet sich ebenfalls im Bug-zillaMetrics-Guide [4].

Page 103: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

Kapitel 8

Evaluierung

In diesem Kapitel werden alle Bereiche der Diplomarbeit ausgewertet.

Zunächst folgt in 8.1 eine Bewertung der gesamten Software nach ISO 9126-1 [6].

Um die Leistungsfähigkeit und den Ressourcenverbrauch des SCM-Imports beur-teilen zu können, werden in Abschnitt 8.2 acht Importvorgänge analysiert. WelcheEigenheiten bei der Spezi�kation einer Metrik in BugzillaMetrics bestehen und wiedann letztendlich das Metrik-Ergebnis in Form eines Graphen von BugzillaMetricsausgegeben wird, stellt Abschnitt 8.3 vor.

Bevor der Funktionsumfang der SCM-Integration mit dem Funktionsumfang derbeiden Analysetools StatCVS und Eclipse Dash im letzten Abschnitt 8.5 verglichenwird, folgt unter 8.4 die Einordnung dieser Arbeit in das Bewertungsschema von[12].

8.1 Bewertung der Software

Die Bewertung der vorliegenden Software geschieht anhand des Qualitätsmodellsfür externe und interne Qualität nach ISO 9126-1 [6].

8.1.1 Funktionalität

Eignung Der SCM-Import wird mit realen CVS- und SVN-Systemen getestet. Dahierbei alle grundlegenden Möglichkeiten, die ein SCM-System bietet, durch Test-fälle abgedeckt werden, ist sichergestellt, dass der SCM-Import den Anforderungeneines realen Enwicklungsprojekts, das unter Versionskontrolle steht, gewachsen ist.In der Anforderungsanalyse wurden zusätzliche Möglichkeiten für die Spezi�kationvon Metriken mit Fokus auf SCM-Systeme gefordert. Da das Test-Framework fürden BugzillaMetrics-Kern auf Spezi�kationsebene testet und alle, im Vergleich zurreinen Bugzilla-Metrikspezi�kation, zusätzlichen Funktionalitäten durch Testfälleabdeckt, wird sichergestellt, dass auch dieser Teil der Software den Anforderungeneines Nutzers von BugzillaMetrics gewachsen ist.

Genauigkeit Da der SCM-Import die Datenausgabe der SCM-Schnittstellen nichtmanipuliert, sondern nur sortiert, werden die Originaldaten nicht verändert.Der einzige Punkt, an dem interpretiert wird, ist die Identi�kation von versteck-ten MOVE- und RENAME-Aktivitäten in der Repository des zu analysierendenEntwicklungsprojekts. Dies kann zwar die Genauigkeit durch falsch-positive oderfalsch-negative Ergebnisse beeinträchtigen, fördert aber die Verwendbarkeit und

103

Page 104: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

104 KAPITEL 8. EVALUIERUNG

Aussagefähigkeit der Metrikberechnungen. Da der Anwender durch Festlegung einesSchwellenwerts für o.g. Entscheidung die Berechnung beein�ussen kann, hängt dieGenauigkeit der Berechnungen auch von der bedachten De�nition dieses Schwellen-werts durch den Anwender ab. Eine Einstellung, welche die Gewohnheiten der imzu analysierenden Projekt aktiven Entwickler berücksichtigt, führt zu einem quali-tativ hochwertigeren Ergebnis als eine zufällige Wahl der Werte. Wenn die Ent-wickler bei MOVE- oder RENAME-Aktivitäten nicht zusätzlich noch inhaltlicheÄnderungen an den Dateien vornehmen, kann der Wert für die maximale Di�erenzder Inhalte klein gehalten werden und die Gefahr, dass falsch-positive Ergebnissebeim Event-Check auftreten, verringert werden. Auch das maximale Zeitintervallbei der EventChecker-Heuristik kann klein gehalten werden, wenn Entwickler beimVerschieben oder Umbenennen nach dem REMOVE der Datei in der alten Versionnicht zu lange warten, bis sie die neue Version committen.

Grob falsche Einstellungen können dagegen zu unbrauchbaren Ergebnissen führen.

Das verwendete Perl-Script, welches aus dem SCMBug Daemon stammt, wurde in-haltlich nicht verändert. Die Korrektheit der SCMBug-Integration insgesamt kannnicht beein�usst werden. Zusätzlich wurde die Software mit den beiden realen Pro-jekten Viper und BugzillaMetrics des Lehr- und Forschungsgebiets Informatik 3kontrolliert und Berechnungsergebnisse mit denen von StatCVS verglichen.

Kompatibilität Die vorliegenden Erweiterungen um SCM-Funktionen in Bugzil-laMetrics übernehmen die schon im Kern des BugzillaMetrics-Systems erfolgreichangewendeten Schnittstellen zu MySQL-Datenbanken sowie XML-Schnittstellen fürdie Metrikspezi�kation, Systemkon�guration und Testspezi�kation.Zusätzlich wird durch das OSCommandProvider-Konzept (siehe 6.4) eine reibungsloseKommunikation mit SCM-Systemen über Kommandozeilenbefehle sichergestellt.Diese durchgängige Kommunikation über Standardschnittstellen führt dazu, dassan andere Tools und Softwareumgebungen keine besonderen Anforderungen gestelltwerden müssen.

Sicherheit Die SCM-Erweiterung verwendet verschiedene Abfrageschnittstellenzu SCM-Systemen, welche die Repository nicht ändern. Dies erfordert keine Ad-ministratorrechte, so dass geschützte Daten vom normalen Anwender nicht einge-sehen oder manipuliert werden können. Bei einer Testdurchführung, bei der z.B. dieManipulation der Systemzeit möglich ist und Administratoraktivitäten auf SCM-Systemen durchgeführt werden, sind diese Rechte notwendig, sodass nur Systemad-ministratoren dazu in der Lage sind.Der Datenbanknutzer hat nur auf der systemeigenen SCM-Datenbank vollständigeLese- und Schreibrechte, nicht aber auf der Bugzilla-Datenbank. Die von Bugzillaverwalteten Daten können also nicht manipuliert werden.

8.1.2 Zuverlässigkeit

System-Reife Der SCM-Import arbeitet mit Parsern, welche auf die Syntax derAusgaben von SCM-Systemen zugeschnitten sind. Falls in der Anwendungspraxisnicht betrachtete Sonderfälle auftreten oder die Syntax sich grundlegend ändert- beispielsweise beim Versionswechsel eines SCM-Systems - können Importfehlerauftreten.Da der BugzillaMetrics-Kern schon erfolgreich angewendet wird, sind grobe Fehlerbei Metrikberechnungen unwahrscheinlich. Die Funktionalität bezogen auf SCM-Systeme gliedert sich in die bestehende und erprobte Systemarchitektur ein.

Page 105: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

105

Fehlertoleranz Falls sich Probleme beim Import ergeben, führt dies nicht zwangs-läu�g zu einem Abbruch. Die zusammengestellten Daten in der SCM-Datenbanksind in diesem Fall nicht vollständig, jedoch weiterhin konsistent.Der BugzillaMetrics-Kern berechnet jede Anfrage separat, sodass sich Fehler in einerBerechnung nicht auf andere Berechnungen auswirken.

Wiedererlangbarkeit (Recoverability) Beim Import schreibt das System alleErgebnisse in die SCM-Datenbank, es werden jedoch in keinem Fall Datenbankein-träge entfernt. Dies hängt damit zusammen, dass Histories von SCM-Systemen nichtänderbar sind.

Bei einem Abbruch und späteren Neustart des Imports werden nur die Daten-bankeinträge hinzugefügt, die noch nicht in der Datenbank stehen. Schon enthal-tene Einträge werden bei der Datenassoziation eingebunden. Es gehen also keinegesicherten Daten verloren.

Im BugzillaMetrics-Kern werden keine Daten persistent gesichert, sodass bei einemFehler nichts wiederhergestellt werden muss.

8.1.3 Verwendbarkeit

Verständlichkeit und Erlernbarkeit Aufgrund des BugzillaMetrics-Frontendsist es ohne lange Einarbeitungszeit möglich, Metriken zu spezi�zieren und auszu-führen. Eine Verständlichkeitsuntersuchung von BugzillaMetrics bei einer gröÿerenNutzerzahl wurde noch nicht durchgeführt.

Die hier vorliegende Erweiterung des Systems um SCM-spezi�sche Funktionen glie-dert sich nahtlos in das bestehende Konzept der Metrikspezi�kation ein, sodasssich keinerlei zusätzliche Verständnisschwierigkeiten ergeben. Der Import lässt sichüber einen Kommandozeilenbefehl starten und verlangt kein tieferes Verständnisdes Programmablaufs.

Bedienbarkeit Aus der Sicht des reinen BugzillaMetrics-Anwenders ist lediglichein Webbrowser nötig. BugzillaMetrics unterstützt hierbei alle gängigen Browser.

Ein Administrator muss die Voraussetzungen für den Start der Web-Applikationscha�en. Dazu gehört die Anpassung einer Kon�gurationsdatei, die Vorbereitungder SQL-Datenbank und Bereitstellung eines Webservers, wie Apache Tomcat.

Bevor das Import-Programm lau�ähig ist, müssen zusätzliche Einstellungen in derKon�gurationsdatei, bezogen auf das zu importierende Entwicklungsprojekt, vorge-nommen werden.

Zu beiden Punkten gibt es Installationsanleitungen, welche die Vorbereitungen er-leichtern sollen. Der Administrator sollte aber über grundlegende Kenntnisse imBereich Versionsmanagementsysteme, Webserver und Datenbanken verfügen.

Attraktivität Hierzu kann keine Aussage getro�en werden, da noch keine Befra-gung der Nutzer durchgeführt wurde.

8.1.4 E�zienz

Zeitverhalten Die Dauer einer Metrikberechnung, welche die SCM-Daten ver-wendet, ist abhängig von der Gröÿe des SCM-Projekts. Sie hält aber die 1 Minute-Grenze, welche in [10] gefordert wurde, bei Anfragen zu Projekten, die etwa dieGröÿe von BugzillaMetrics haben, ein.

Die Dauer des Datenimports hängt von vielen Ein�ussfaktoren ab:

Page 106: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

106 KAPITEL 8. EVALUIERUNG

• projektspezi�sch

◦ Gröÿe des SCM-Projekts.

◦ Anzahl der Dateien, welche einen Typ haben, der in der settings.xmlals relevant für eine detaillierte Analyse de�niert wurde.

◦ Anzahl der Revisionen, die zu relevanten Dateien existieren.

◦ Anzahl der Objekte, die potentiell umbenannt oder verschoben wurdenund die hierfür verwendete Filterheuristik ( siehe 6.2.8).

• verwendete Hardwareumgebung

◦ Geschwindigkeit der Netzwerkverbindung zur Datenbank und zum SCM-System.

◦ Tra�c auf Datenbank und SCM-System.

Dies hat zur Folge, dass keine einheitlichen Laufzeitwerte angegeben werden können.Ein extrem groÿes Projekt, das nur aus nicht relevanten Dateien besteht, wird imVergleich zu einem kleinen Projekt mit vielen potentiellen MOVE- oder RENAME-Kandidaten und vielen Revisionen pro Objekt vergleichsweise schnell eingelesen.Die in Abschnitt 8.2 vorgestellten Beispielimporte sollen als Orientierungspunktdienen.

Resourcenverbrauch Der SVN-Import benötigt aufgrund der umständlicherenDatengewinnung aus der Repository (siehe 6.1.5) mehr Arbeitsspeicher als der CVS-Import.

Datenbankgröÿe: Die Anzahl der existierenden Tabelleneinträge hängt natürlichvom Projekt ab.Die Anzahl der Einträge in den Tabellen für Dateien, Ordner, Entwickler, Branchesund Tags steht etwa in einem 1:1 - Verhältnis zur Anzahl der entsprechenden Ob-jekte im Projekt.Je öfter Dateien und Ordner umbenannt oder verschoben werden, desto höher istdie Anzahl der Einträge.

Allgemein kann man sagen, dass die SCM-Repository sehr viel gröÿer ist als diezugehörige Datenbank.

Weitere Informationen hierzu �nden sich im Abschnitt 8.2 zu den Beispielimporten.

8.1.5 Wartbarkeit

Analysierbarkeit, Änderbarkeit, Stabilität Die Organisation der Pakete imProjekt ist darauf ausgerichtet, dass alle Klassen zur SCM-Integration von denen an-derer Systembereiche getrennt sind. Sie liegen im Paket org.bugzillametrics.scm.Entsprechend können alle Korrekturen, Verbesserungen oder Anpassungen im SCM-Integrationsteil nur hier statt�nden und wirken sich nicht auf andere Systembereicheaus.Gleiches gilt für Teilbereiche der SCM-Integration.

Beim Design des SCM-Imports dessen Komponenten sich alle im Paket scm.data-Import be�nden, wurde sehr darauf geachtet, dass alle Arbeitsschritte während desImportvorgangs getrennt voneinander in Modulen ablaufen (siehe 6.2.1). Die Koor-dination dieser Module erfolgt nicht durch diese selbst, sie sind bei der Delegationder Arbeit völlig passiv. Sie werden von speziellen Delegator-Klassen aufgerufen.Dies führt dazu, dass Änderungen immer nur lokale Auswirkungen haben können

Page 107: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

107

und jedes Modul problemlos durch ein anderes austauschbar ist. Auch die Delegator-Klassen sind ohne Auswirkungen auf die Module änderbar und austauschbar.Die Komponenten zur Kernerweiterung liegen im Paket scm.coreExtensions undnur dort. In diesem Bereich gab es fast keine strukturellen Freiheiten, sodass dieWartbarkeit hier nicht beein�usst werden konnte. Für eine Beschreibung der Wart-barkeit dieses Programmteils sei auf [10] verwiesen.

Abbildung 8.1 zeigt eine Metrikauswertung des scm-Pakets. Die Maximum-Wertezu Weighted Methods per Class und Anzahl Methoden ergeben sich durch die OS-

CommandProvider, welche eine Vielzahl an Abstraktionen zu Kommandozeilenbe-fehlen anbieten. Eine Aufteilung in mehrere Klassen ist an dieser Stelle nicht zweck-mäÿig, da OSCommandProvider eine sehr einfache Struktur haben. Eine Aufteilungwürde nur zu einer unnötig komplizierten Struktur führen.Die Erweiterung des Test-Frameworks orientierte sich an der bestehenden Architek-tur (siehe [10]). Die Metrikauswertung dieses Pakets �ndet sich in Tabelle 8.2.

Metrik Gesam

t

Durchschnitt

Standardabweichung

Maximum

Codezeilen gesamt 10142Codezeilen in Methoden 5329 4,393 6,283 63

Weighted Methods per Class 1773 9,796 15,096 136Anzahl Methoden (avg / max. per type) 1167 6,448 10,461 104Anzahl Klassen (avg/max per package) 181 5,324 4,1 15

Anzahl Pakete 34

Tabelle 8.1: Metrikauswertung des scm - Pakets (Quelle: Eclipse - Plugin Metrics1.3.6)

Metrik Gesam

t

Durchschnitt

Standardabweichung

Maximum

Codezeilen gesamt 1467Codezeilen in Methoden 716 5,638 6,694 37

Weighted Methods per Class 176 3,321 4,013 25Anzahl Methoden(avg / max. per type) 116 2,189 1,884 10Anzahl Klassen (avg/max per package) 53 8,833 5,786 17

Anzahl Pakete 6

Tabelle 8.2: Metrikauswertung des scm.test - Pakets (Quelle: Eclipse - Plugin Met-rics 1.3.6)

Die Abbildung 8.1 zeigt den Distanzgraphen zum Gesamtprojekt BugzillaMetrics.Hier wurden die Pakete, welche zur SCM-Integration gehören, markiert. Es zeigt

Page 108: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

108 KAPITEL 8. EVALUIERUNG

sich, dass die meisten Pakete unau�ällige Werte besitzen. Die Positionen der Aus-reiÿer hängen mit deren besonderen Eigenschaften zusammen:

• Abstraktion von der SCM-Schnittstelle:

◦ commandProvider : Dieses Paket ist klein und enthält eine abstrakteKlasse, was die horizontale Position begründet. Die Instabilität ergibtsich daraus, dass die enthaltenen Klassen Kollektionen von Kommando-zeilenbefehlen darstellen.

◦ activityExecutioner : In diesem Paket liegen die abstrakten Oberklassender ActivityExecutioner für die Generierung von SCM-Repositoriesfür Import-Tests. Es besteht also eine Abstraktion über die zahlreichenCVS- und SVN-Kommandozeilenbefehle und über die konkreten Exe-

cutioner, welche in Paketen oben links positioniert sind.

◦ parser : Alle Parser bedienen sich für die Zugri�e auf SCM-Systeme beimOSCommandProvider, was die Instabilität begründet.

◦ loader : Auch Loader verwenden OSCommandProvider für den Zugri� aufSCM-Systeme. Im Gegensatz zu Parsern, die den Groÿteil des Einlesevor-gangs selbst realisieren, bedienen sich Parser vor allem bei Methoden ausden abstrakten Oberklassen.

• Datenobjekte:

◦ sql.model / sql.tableEntries: Diese beiden Pakete stellen reine Datenob-jekte dar, welche die AssociationBuilder mit dem DatabaseVisitor

verknüpfen. Sie enthalten Repräsentationen von konkreten Tabellenein-trägen für die SCM-Datenbank und verwenden die Column-Klasse für dieAbstraktionen von Tabellenspalten. Die Datenobjekte werden verwendet,weil sie die Parameterzahl der DatabaseVisitor-Methoden erheblich re-duzieren.

◦ activities: Auch die Klassen in diesem Paket sind Datenobjekte, welchezur einheitlichen Repräsentation von SCM-Aktivitäten verwendet wer-den.

• Erweiterungspunkt:

◦ coreExtensions: Die Lage der SCM-Klassen zur Erweiterung des Bug-zillaMetrics-Kerns ergibt sich zum einen aus dem Design des Kerns, dernur wenig beein�usst werden konnte und der getrennten Sicherung imscm-Paket.

Testbarkeit Die beiden verwendeten Test-Frameworks erlauben eine realitätsna-he Überprüfung der Funktionalität. Der CoreTest arbeitet auf Spezi�kationsebene,der ImportTest auf Grundlage einer realen Systemumgebung. In beiden Test-Frame-works ist es möglich, sämtliche Standard- und Spezialfälle, die in der Realitätauftreten können, im Test zu simulieren.Bei der Entwicklung wurden 160 Tests erstellt. Diese decken alle relevanten Bereicheder Metrikspezi�kation und des SCM-Imports ab.Alle Events, Filter und Weights werden getrennt und z.T. in Kombination über-prüft. Dies geschieht auf Grundlage von mehreren Szenarien in der SCM-Datenbank.Die ImportTests simulieren wesentliche Datei-, Ordner-, Branch- und Tag-Aktivi-täten in der realen Repository.

Beides ermöglicht eine gute und realitätsnahe Validierung von Softwaremodi�ka-tionen.

Page 109: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

109

Abbildung 8.1: Distanzgraph aller Pakete von BugzillaMetrics (Quelle: EclipseCAP-Plugin 1.2.0)

8.1.6 Portabilität

Anpassbarkeit BugzillaMetrics ist eine Web-Anwendung für die Java ServletSpeci�cation 2.3. [10].

Die Software zur SCM-Erweiterung ist ein in Java geschriebenes Kommandozeilen-tool und benötigt Java JRE 1.6.0_03. Hinzu kommt ein installierter SCMBug-Daemon sowie das Unix-Tool di�. Alle drei Komponenten sind für verschiedenePlattformen verfügbar. Die Software selbst ist zur Zeit unter Linux und den ak-tuellen Windows - Versionen XP und Vista lau�ähig. Für andere Plattformen wäreeine Erweiterung um eine neue OSCommandProvider-Klasse nötig. Entsprechend istdie Unterstützung des Tools (noch) nicht für alle Betriebssysteme gegeben, eine Un-terstützung ist aber leicht realisierbar, indem die nötigen Kommandozeilenbefehlefür das Betriebssystem de�niert werden.

Installierbarkeit Neben den schon zum vorigen Punkt angesprochenen Eigen-schaften der Software, welche auch die Installierbarkeit beein�ussen, gibt es nochweitere Eigenschaften, welche die Installation selbst betre�en.

Damit der Anwender von BugzillaMetrics die korrekte Anbindung seiner Installationan die benötigten externen Systeme nicht manuell prüfen muss, gibt es bei jedemStart von BugzillaMetrics einen Server -Check, der sicherstellt, dass BugzillaMetricsZugri� auf die benötigten Systeme hat.

Alle Einstellungen, die vom Administrator selbst vorgenommen werden müssen, sindübersichtlich in einer XML-Datei zusammengefasst.

Koexistenz Die Verwendung gemeinsamer Ressourcen mit anderen unabhängi-gen Systemen ist essentiell für die SCM-Integration, jedoch kann es zu keinenRessourcenkon�ikten kommen:

Page 110: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

110 KAPITEL 8. EVALUIERUNG

• Es erfolgt keine Manipulation der SCM-Repositories, deren Daten in Bugzil-laMetrics importiert werden. Hier sind nur SCM-Operationen nötig, welchekeinerlei Schreibzugri�e auf die Repositories verlangen.

• BugzillaMetrics verwendet die SCM-Datenbank exklusiv.

• Die Kon�gurationsdatei daemon.conf des Integrationstools SCMBug wird nurgelesen, nicht manipuliert.

Ersetzbarkeit BugzillaMetrics verwendet Standardschnittstellen zu den beteiligtenFremdsystemen. Solange es keine wesentlichen Änderungen an diesen Schnittstellenkommt, sollte die Ersetzbarkeit leicht möglich sein.Es gibt allerdings eine Ausnahme: Die Kon�gurationsdatei daemon.conf des SCMBug-Tools ist keine Standardschnittstelle. Falls diese in Zukunft durch eine andere Kon-�gurationsart ersetzt wird, muss ein neuer Weg für das Namens-Matching gefundenwerden.

8.2 Beispielauswertung verschiedener Importvorgänge

Um eine Orientierung zu scha�en, welche Zeit- und Ressourcenanforderungen beimImport eines SCM-Projekts bestehen, werden in diesem Abschnitt acht Beispiel-Importvorgänge vorgestellt. Die analysierten Projekte sind zum einen Teilprojektevon VIPER, einer am Lehr- und Forschungsgebiet Informatik 3 entwickelten Soft-ware, und zum anderen Teile von BugzillaMetrics selbst: sc.viper.ide, sc.viper.gef,bugzilla_metrics und bugzilla_metrics_frontend.

Jedes der Projekte wird nacheinander mit zwei verschiedenen Heuristiken ausge-führt:

• Starke Import-Heuristik (A): Das Zeitintervall beträgt bei dieser Heuristikzehn Minuten und die maximale Di�erenz hat einen Wert von 10 %.

• Schwache Import-Heuristik (B): Sie verwendet ein groÿes Zeitintervall vonzehn Stunden und erlaubt eine maximalen Di�erenz der Objekte von 20 %.

Beide Importvorgänge bedienen sich lokalen Repositories und einer lokalen MySQL-Datenbank. Das CVS-Repository, in dem sich die VIPER-Projekte be�nden, ist einSnapshot vom 23.10.2008. Das SVN-Repository der BugzillaMetrics-Projekte ist einSnapshot vom 19.11.2008.

Alle Importvorgänge wurden mit dem in Tabelle 8.3 beschriebenen System durchge-führt und betrachten bei der Datei-Detailanalyse auf Codezeilenebene ausschlieÿlichJava-Dateien.

Die Tabelle 8.4 liefert einen Überblick über die Ergebnisse.Im oberen Tabellenbereich werden die importierten Repositories grob vorgestellt.In der Mitte folgt dann die Beschreibung des Zeitverhaltens beim Importvorgang.Die CPU-Zeit bezieht sich auf die Dauer der CPU-Nutzung durch den Import-Prozess. Die Werte zur (Datei-)Detailanalyse und zum EventCheck beziehen sichauf die Gesamtzeit der jeweiligen Analysevorgänge. Die Befunde des EventChecksfür Dateien und Ordner werden getrennt aufgeführt.Der untere Teil der Tabelle beschreibt die Anzahl der Tabelleneinträge in der SCM-Datenbank nach dem Import.

Page 111: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

111

Hardware:Prozessoren: 2 * AMD Turion(TM) 64 X2 Mobile Technology TL-60Arbeitsspeicher: 3,0 GB

Software:Betriebssystem: Ubuntu Linux 8.04 LTS (Kernel: 2.6.24-19-generic)Java: 1.6.0_03-b05SCM-Systeme CVS: 1.12.13 (client/server)

SVN: 1.5.1 (r32289)MySQL: 5.0.51a-3ubuntu5.1 (Ubuntu)Pro�ler: YourKit Java Pro�ler 7.5.8

Tabelle 8.3: Die Eckdaten des beim Importvorgang verwendeten Systems

Projekt: sc.viper.ide sc.viper.gef BugzillaMetrics B.M.-Frontend

Projektdaten:SCM-System CVS SubversionDateien 2763 99 6701 2696Verzeichnisse 609 40 1066 455Repository-Gröÿe: 390,9 MB 445,9 KB 42,3 MB 42,3 MB

Importvorgang:Heuristik: A B A B A B A BGesamtdauer: 18:32 19:21 3:32 3:31 1:11:39 1:15:04 20:59 21:49CPU - Zeit: 7:59 8:09 1:02 1:02 34:49 37:17 7:55 7:58Detailanalyse: 4:05 4:02 2:09 2:08 19:00 19:45 8:18 9:05EventCheck: 0:06 0:09 0:33 0:34 9:32 11:37 1:52 1:54Datei-/Ordner-Fund: 0 0 4 6 17/11 53/31 22/2 26/15

Datenbankeinträge:BranchActivity 1 1 0 0 2 2Developer 4 2 3 3 4 4FileActivity 5165 374 10984 11010 4275 4291FolderActivity 1964 144 2807 2802 1144 1140SCM_Branch 1 1 0 0 1 1SCM_File 2763 99 6696 6696 2696 2696SCM_Folder 609 40 1066 1066 455 455SCM_Revision... 9476 1285 15924 15945 6111 6123SCM_Tag 18 0 6 6 6 6TagActivity 18 0 8 8 8 8

insgesamt 20019 1946 37494 37536 14702 14726Datenvolumen: 1,04 MB 134 kB 1,9 MB 1,9 MB 732 kB 733 kBSicherungsdauer: 14:21 15:08 0:48 0:49 18:91 20:04 6:03 6:01

Tabelle 8.4: Ergebnisse der Importvorgänge

8.2.1 Ergebnisbewertung

Aus den Import-Ergebnissen lassen sich folgende Erkenntnisse ziehen:

• Der SVN-Import dauert bei vergleichbaren Repositories ähnlich lange, wieder CVS-Import. Dies ist aus den ähnlichen Werten der sc.viper.ide- und

Page 112: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

112 KAPITEL 8. EVALUIERUNG

bugzilla_metrics_frontend-Imports erkennbar.

• Bei Projekten der Gröÿenordnung von BugzillaMetrics nimmt die Analyseder Datei-Details viel Zeit in Anspruch. Auch die Sicherung der Daten in derDatenbank benötigt relativ viel Zeit.Der Import-Prozess beansprucht relativ wenig CPU-Zeit, muss also oft aufdie SCM-Systeme bzw. MySQL warten. Dies ist in dem Verhältnis von CPU-und Gesamtzeit erkennbar. Der Graph in Abbildung 8.2 veranschaulicht diesam Beispiel vom bugzilla_metrics-Import mit Heuristik B.

• Der ScmRepositoryObjectLinker braucht nicht länger als 1-2 Sekunden.Dieser Wert wurde deshalb nicht in die Tabelle aufgenommen. Hier gibt eskeinerlei Verbesserungsbedarf.

• Im EventChecker wirkt sich die verwendete Heuristik nur marginal auf dieAnalysezeit aus.

• Die Zahl der gefundenen Dateien und Ordner beim EventCheck ist relativklein.

• Das Datenvolumen ist mit z.B. 1,9 MB bei knapp 8000 Dateien und Ord-nern im bugzilla_metrics-Projekt deutlich geringer als das Volumen der Quell-Repository mit 42,3 MB, also akzeptabel. Die Repository enthält allerdingsnoch andere Projekte, wie beispielsweise bugzilla_metrics_frontend.

• Der SVN-Import benötigt aufgrund der umständlicheren Datengewinnung ausder Repository (siehe 6.1.5) mehr Heap-Speicher als der CVS-Import. DieAbbildung 8.3 stellt den Speicherbedarf vom sc.viper.ide-Import dem desbugzilla_metrics_frontend-Imports gegenüber. Die untere Kurve ist in bei-den Graphen jeweils der aktuelle Speicherbedarf, die obere Kurve gibt denaktuell reservierten Speicher an.

• Den geringsten Speicherbedarf hatte der sc.viper.gef-Import mit maximal 59MB. Der höchste Wert trat beim bugzilla_metrics-Import mit maximal 474MB auf.

Abbildung 8.2: CPU-Zeit beim Import von bugzilla_metrics mit Heuristik A.

Page 113: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

113

Abbildung 8.3: Speicherbedarf (Heuristik A): sc.viper.ide-Import (oben),bugzilla_metrics_frontend-Import (unten)

Daraus kann folgendes Fazit gezogen werden:

• Die Schnittstellen zu den SCM-Systemen bzw. zur Datenbank stellen Flaschen-hälse dar.

• Sehr groÿe Projekte (>�> 8000 Repository-Objekte) können zwar theoretischimportiert werden, die Laufzeit des Imports wäre aber sehr lang.

• CVS-Repositories können ressourcenschonender importiert werden als SVN-Repositories.

8.3 Metrikergebnisse von BugzillaMetrics

Die Tatsache, dass sich alle Metrikspezi�kationen für BugzillaMetrics an Cases ori-entieren, führt dazu, dass Ergebnisse auf eine bestimmte Art interpretiert werdenmüssen. Der folgende Abschnitt gibt hierzu einige Hinweise. Im Anschluss daranfolgt die Vorstellung eines Beispiel-Metrikergebnisses in Form eines Graphen.

8.3.1 Bemerkenswerte Eigenheiten der Metrikspezi�kationen

BaseFilter Eine Eigenart dieser SCM-Integration, welche man bei jeder Metrik-spezi�kation beachten muss, ist die Orientierung an Cases.Auch wenn ein developer-BaseFilter verwendet wird, um den Umfang der Mi-tarbeit, also Commit-Anzahl und geschriebene Codezeilen, eines bestimmten Ent-wicklers zu analysieren, erhält man nach der Filterung immer nur die Cases, indenen der Entwickler aktiv ist. Demnach sind im Berechnungsergebnis auch immerdie Arbeitsanteile der anderen Entwickler in den ge�lterten Cases enthalten.Ähnliches gilt für alle BaseFilter: Es wird immer die Menge an Cases ge�ltert,die mit dem Suchschlüssel auf irgend eine Art zusammenhängt und nicht nur dieDaten, die exklusiv zum Suchschlüssel gehören.

Page 114: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

114 KAPITEL 8. EVALUIERUNG

Event Da manche Versionsmanagementsysteme die History von gelöschten Dateiennicht mehr in der Repository sichern, kann es zu verfälschten Ergebnissen beider Analyse von Events kommen. Beispielsweise besteht keine Möglichkeit, denFileCreationEvent einer gelöschten Datei zu erhalten. Zu dieser gibt es lediglichnoch einen FileRemoveEvent.

Weights Wie schon in der Übersichtstabelle der Anforderungsanalyse (siehe 3.2)beschrieben, gibt es sinnvolle und auch völlig sinnlose Kombinationen von Events

und Weights. Der Anwender von BugzillaMetrics sollte sich immer im Klaren sein,dass eine sinnlose Kombination zu keinem Fehler, sondern zu einem Funktions-graphen führt, dessen Werte alle Null sind.

8.3.2 Beispiel eines Metrik-Graphen

Aufgrund der groÿen Zahl an Kombinationsmöglichkeiten bei der Spezi�kation einerMetrik ist es nicht möglich, an dieser Stelle eine umfassende Vorstellung der Ergeb-nisdarstellungen, welche von BugzillaMetrics geliefert werden können, zu liefern.Deshalb beschränkt sich dieser Abschnitt darauf, einen einzelnen Graphen vorzu-stellen.

Der Graph in Abbildung 8.4 ist das Ergebnis einer Metrik, welche das Ziel hat, imProjekt sc.viper.gef den Bug 344 isoliert zu analysieren. Der Graph beinhaltet zweiKurven.

Eine der Kurven zeigt die minimale Anzahl der Dateien, welche gleichzeitig in einemCommit enthalten sind, der Bug 344 referenziert. Diese Bildung des Minimumserfolgt einzeln für jeden Tag.

Die andere Kurve zeigt die Anzahl der Commits, welche am jeweiligen Tag getätigtwurden.

8.4 Einordnung der Arbeit in die Menge andererAnsätze der Fachliteratur

Die Einordnung erfolgt anhand des 4 Dimensionen-Schemas im Survey [12], welchesin 2.6 beschrieben wurde.

1. Die erste Dimension konzentriert sich auf den Typ der untersuchten Reposi-tories. Diese Arbeit verwendet die ersten beiden der drei Repository-TypenVersionsmanagementsysteme, Bug-Tracker und Kommunikationsmittel undanalysiert, sowohl die Inhalte einer Softwareversion, als auch die Unterschiedezwischen Versionen. Diese Analyse geschieht anhand von Metadaten aus Log-Ausgaben der Versionsmanagementsysteme.

2. Zum Zweck der Untersuchung: Dieses Tool kann keine Warenkorb-Fragen oderboolesche Anfragen beantworten, sondern konzentriert sich ausschlieÿlich aufMetriken.

3. Die Untersuchungsmethode ist eine Mischung aus externer und interner Mes-sung und Analyse der Software-Evolution. Für Metrikspezi�kationen, die bei-spielsweise die Anzahl an Dateien, die von einem Case betro�en sind, verlan-gen, wird eine externe Messung durchgeführt. Bei Metrikspezi�kationen aufCodezeilenebene werden die Di�-Funktionen von CVS und Subversion ver-wendet, was einer internen Messung entspricht.

Page 115: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

115

Abbildung 8.4: Beispiel eines Ergebnis-Graphen

4. Eine Bewertung der Analyseergebnisse fand nur im Hinblick darauf statt, obdie Berechnung korrekt durchgeführt wurde. Die dazu verwendeten Software-projekte waren die beiden am Lehr- und Forschungsgebiet Informatik 3 derRWTH Aachen entwickelten Softwareprojekte Viper und BugzillaMetrics.Da die Software noch nicht praktisch angewendet wurde, kann noch nichtsdazu gesagt, werden, wie sehr sie die Verbesserung von Softwareprojektenfördert.

Genau wie viele der im Survey vorgestellten Ansätze, analysiert diese Software aufder Grundlage von Metadaten, passt also in die Kategorie Metadatenanalyse. Da esaber auÿerdem noch eine starken Bezug zu Softwaremetriken gibt, kann sie auch indie Kategorie Softwaremetriken einsortiert werden.

8.5 Vergleich der realisierten Funktionen mit denenvon StatCVS und Eclipse Dash

In der Anforderungsanalyse wurden die SCM-Analysetools StatCVS und EclipseDash betrachtet. Die Tabelle 8.5 stellt die Funktionen der SCM-Integration unddiejenigen beider Vorbilder gegeneinander. Aufgrund der fehlenden Orientierung anBugs durch StatCVS und Eclipse Dash gibt es leichte Unterschiede bei der Inter-pretation der angesprochenen Funktionen. Die bei der SCM-Integration eingeklam-merten Funktionen deuten daraufhin, dass der Bestand an zur Verfügung stehendenDaten diese Funktion ermöglicht, die Erweiterung im BugzillaMetrics-Kern dies ausZeitgründen jedoch noch nicht realisiert.

Die Möglichkeit, die durchschnittliche Dateigröÿe zu berechnen, besteht nur, wenn

Page 116: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

116 KAPITEL 8. EVALUIERUNG

das Projekt von Beginn an die SCMBug-Integration verwendet. Ansonsten ist dasErgebnis aufgrund der teilweise fehlenden Integrationsdaten verfälscht.

Die in die Tabelle aufgenommenen Funktionen orientieren sich ausschlieÿlich anStatCVS und Eclipse Dash. Funktionen, welche nur von BugzillaMetrics beherrschtwerden, wurden aus Platzgründen nicht aufgenommen.

Aufgrund der �exiblen Kombinierbarkeit von BaseFiltern, Events und Weights

sind dies sehr viele zusätzliche Funktionen. Die Tabelle 3.2 aus der Anforderungs-analyse gibt einen Überblick über die Möglichkeiten der SCM-Integration. Hinzukommen noch Kombinationsmöglichkeiten aus Bugzilla- und Versionsmanagement-Daten.

Kategorie Gesichtspunkt zur Kategorie StatCVS

Eclipse

Dash

SCM

-Integration

Commits Verhältnis: Korrektur- und Erweiterungscommits√ √

Entwicklungsaktivität nach Tageszeit√ √

Entwicklungsaktivität nach Wochentag√ √

Anzahl aller Commits√ √

Anzahl an Commits pro Entwickler√ √

Dateien Durchschnittliche Dateigröÿe (allgemein)√ √

Anzahl an Dateien√ √

Dateitypen√ √

Gröÿenanteil von Dateitypen im Projekt√ √

Durchschnittliche Dateigröÿe (typenbezogen)√ √

gröÿte Datei√

Datei mit den meisten Revisionen√

Entwickler Anzahl Entwickler√ √ √

Arbeitsanteil eines Entwicklers√

(√)

Entwickler mit dem meisten Arbeitsanteil√

(√)

aktivster Entwickler√

(√)

(in)aktive Entwickler√

Kommentare Anzahl Kommentare√

Anzahl Kommentatoren√

LOC Codezeilen√ √ √

Anteil der geänderten LOC√ √ √

Durchschnittliche LOC pro Commit√ √

Anteil eines Entwicklers an den geänderten LOC√ √

Verzeichnisse Ordnergröÿe√ √

Ordneränderungen√ √

Tabelle 8.5: Funktionsumfang: Was kann die SCM-Integration realisieren?

Page 117: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

Kapitel 9

Zusammenfassung und

Ausblick

Das Ziel dieser Diplomarbeit war es, das Analysetool BugzillaMetrics um eine In-tegration von Versionsmanagementsystemen zu erweitern.

Die Integration stützt sich auf das Tool SCMBug, das alle Aktivitäten in einerSCM-Repository, die gegen einen bestimmten Bug eines Bug-Trackers committetwurden, in diesen integriert.

Die Betrachtung von Versionsmanagementsystemen wurde auf das Concurrent Ver-sions System (CVS) und Subversion beschränkt. Da BugzillaMetrics während derBearbeitungszeit an dieser Diplomarbeit ausschlieÿlich den Bug-Tracker Bugzillaunterstützt hat, beschränkt sich die Integration ebenfalls auf Bugzilla.

Aus funktionaler Sicht wurden andere Ansätze dieses Themenbereichs zum Vorbildgenommen und diejenigen Funktionen umgesetzt, die zum Konzept von Bugzilla-Metrics passen.

Diese Funktionen bildeten den Ausgangspunkt für die Anforderungsanalyse an dieSoftware. Hinzu kamen viele Anforderungen von BugzillaMetrics selbst, da die In-tegration einen Erweiterungspunkt und keinen festen Bestandteil des Analysetoolsbildet.Weitere Anforderungen stellten sich durch die Problematik, sich zwar auf CVS undSubversion zu konzentrieren, aber gleichzeitig die Erweiterung um andere Versions-managementsysteme möglich zu machen.

Das Resultat dieser Arbeit ist eine zweigeteilte SCM-Integration. Einerseits wurdeein Import-Tool für die Bereitstellung von Analysedaten entwickelt und andererseitsder Kern von BugzillaMetrics um SCM-spezi�sche Komponenten erweitert.

Das Import-Tool ist modular nach Import-Arbeitsschritten aufgebaut. Viele Modulesind unabhängig bzw. weitgehend unabhängig vom zu importierenden SCM-System.Von der Schnittstelle zum Betriebssystem wird vollständig abstrahiert, sodass dieMöglichkeit besteht, neben den schon unterstützten Plattformen Windows und Li-nux auch weitere zu unterstützen.

Um die Qualität der Software zu gewährleisten, wurde ein aufwändiges Test-Frame-work entwickelt, welches reale SCM-Repositories generiert. Der Test der Erweiterungvom BugzillaMetrics-Kern erfolgt durch das Test-Framework, welches schon vor Be-ginn der Arbeit existiert hat und nur leicht abgeändert werden musste.

Um zu testen, ob die Software korrekt arbeitet, wurden Teile der Projekte Viperund BugzillaMetrics selbst importiert und analysiert.

117

Page 118: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

118 KAPITEL 9. ZUSAMMENFASSUNG UND AUSBLICK

Es gibt einige Möglichkeiten, dieses Tool in seiner Funktionalität und Anwender-freundlichkeit zu erweitern:

• Gra�sches Import-Frontend:Das Kommandozeilentool für den SCM-Import ist nur wenig komfortabel.Besonders die Einstellungen in der settings.xml Datei sind nur wenig an-wenderfreundlich. Deshalb wäre es sinnvoll, ein Tool zu entwickeln, welches esdem Anwender erlaubt, alle Einstellungen über eine GUI durchzuführen.

• Verwendung von Threads zur Beschleunigung des SCM-Imports:Im Kapitel zur Evaluierung wurde angesprochen, dass die SCM-Systeme unddie MySQL-Datenbank einen zeitlichen Flaschenhals darstellen. Um die War-tezeit auf Antworten der o.g. Systeme besser ausnutzen zu können, wäre dieVerwendung von Threads sinnvoll. Der Import-Prozess könnte diese Zeit fürAnalysen der schon vorliegenden Daten nutzen.

• Erweiterung des Funktionsumfangs:Die Integration bietet zwar schon einige Funktionen, es sind aber noch detail-liertere Berechnungen und Filter denkbar:

◦ Analyse von Kommentaren:Das Tool StatCVS ist in der Lage, die Anzahl von Kommentaren undKommentatoren zu bestimmen. Dies und weitere inhaltliche Analysenzu Kommentaren, wie z.B. die Klassi�kation von Commits nach adap-tive, corrective und perfective, wie in [14] oder die Untersuchung vonSoftwareänderungen zur Behebung von Bugs über die Analyse von Kom-mentaren, wie beim Ansatz von [18].

◦ Detaillierte Analyse von Branches und Tags:Dieser Punkt wird in der Arbeit nur ober�ächlich behandelt. Es kann nurbeobachtet werden, ob und wann Branches und Tags hinzugefügt odergelöscht wurden.

◦ Erkennung von Refactorings:Es wäre denkbar, beim Import ein Analysemodul zu verwenden, welchesim Quellcode Software-Refactorings aufspürt.

◦ Qualitativ bessere Codezeilenwerte:Diese Arbeit gewichtet alle Codezeilen einer Datei gleich. Es gibt keineUnterscheidung von Kommentarzeilen, leeren Zeilen, etc. Hier wäre dieEinbindung eines Tools zur Codezeilenanalyse bzw. die Entwicklung eineseigenen Analysetools sinnvoll.Dies könnte dadurch realisiert werden, dass die Parser-Module zum Ein-lesen von cvs annotate und svn annotate durch andere Module ersetztwerden.

◦ Erkennung fehlerverursachender Änderungen:Der Zeitpunkt, zu dem ein Bug in Bugzilla eingestellt wird, beschreibtnicht den Zeitpunkt, zu dem der zugehörige Fehler entstanden ist.Um analysieren zu können, wie lange ein Fehler unentdeckt im Programmexistiert bzw. wie er entstanden ist, wäre ein entsprechendes Suchmo-dul eine sinnvolle Erweiterung. Dies könnte in den Import-Algorithmuseingefügt werden. Siehe hierzu auch [18].

• Unterstützung von MantisMetrics:Während der Bearbeitungszeit dieser Diplomarbeit wurde mit der Entwick-lung einer Mantis-Unterstützung von BugzillaMetrics begonnen.Prinzipiell sollte die Unterstützung von Mantis durch diese SCM-Integration

Page 119: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

119

nicht schwer sein, da die Bug-Nummern von Bugzilla die einzige Verbindungzur SCM-Integration darstellen. Dies wird bei Mantis nicht anders sein.

• Unterstützung weiterer SCM -Systeme:Das Softwaredesign dieser Arbeit ist darauf ausgelegt, neben CVS und Sub-version auch andere Versionsmanagementsysteme zu unterstützen.

• Unterstützung weiterer Betriebssysteme:Damit auch Anwender anderer Betriebssysteme als Windows oder Linux dieMöglichkeit haben, BugzillaMetrics inklusive der SCM-Integration zu verwen-den, wäre eine Erweiterung der OSCommandProvider sinnvoll.

Page 120: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

120 KAPITEL 9. ZUSAMMENFASSUNG UND AUSBLICK

Page 121: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

Literaturverzeichnis

[1] F. Budszuhn. CVS - Einfuehrung, Praxis, Referenz. Galileo Press GmbH,2005.

[2] G. Canfora and L. Cerulo. Impact analysis by mining software and changerequest repositories. Proceedings 11th IEEE International Symposium on Soft-ware Metrics (METRICS '05). IEEE Computer Society Press: Los AlamitosCA, pages 29 � 37, 2005.

[3] B. Collins-Sussmann, B.W. Fitzpatrick, and C.M. Pilato. Version Control withSubversion: For Subversion 1.5, 2008.

[4] BugzillaMetrics Contributors. BugzillaMetrics Guide, 2008.www.bugzillametrics.org.

[5] StatCVS Contributors. StatCVS - Kommandozeilentool fuer die Erstellung vonStatistiken zu CVS Repositories, 2008. http://statcvs.sourceforge.net/.

[6] ISO copyright o�ce. Software engineering - Product quality - Part 1: Qualitymodel, 2001.

[7] D. Cubranic and G.C. Murphy. Hipikat: Recommending pertinent softwaredevelopment artifacts. Proceedings 25th International Conference on SoftwareEngineering (ICSE '03). IEEE Computer Society Press: Los Alamitos CA,pages 408 � 418, 2003.

[8] D. Cubranic, G.C. Murphy, J. Singer, and K.S. Booth. Hipikat: A projectmemory for software development. IEEE Transactions on Software Engineering2005, 31(6):446 � 465, 2005.

[9] B. Freeman-Benson. Eclipse Dash (Plugin fuer Eclipse):http://www.eclipse.org/dash/, 2008.

[10] L. Grammel. Development of a tool for the evaluation of change requests.Master's thesis, RWTH Aachen, 2007.

[11] K. Ito, J. Latour, V. Boctor, and J. Fitzell. Manual for Mantis. The MantisTeam: www.mantisbt.org, 2008.

[12] H. Kagdi, M.L. Collard, and J.I. Maletic. A survey and taxonomy of approachesfor mining software repositories in the context of software evolution, volume 19.J. Softw. Maint. Evol.: Res. Pract. 2007; Published online in Wiley InterScience,2007.

[13] J. Ludewig and H. Lichter. Software Engineering - Grundlagen. Menschen,Prozesse, Techniken. dpunkt.verlag, 2007.

121

Page 122: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

122 LITERATURVERZEICHNIS

[14] A. Mockus and L.G. Votta. Identifying reasons for software changes using his-toric databases. Proceedings 16th IEEE International Conference on SoftwareMaintenance (ICSM '00). IEEE Computer Society Press: Los Alamitos CA,pages 120 � 130, 2000.

[15] T.J. Ostrand and E.J. Weyuker. A tool for mining defect-tracking systemsto predict fault-prone �les. Proceedings 1st International Workshop on Min-ing Software Repositories (MSR 2004). University of Waterloo: Waterloo ON,pages 8 � 89, 2004.

[16] D.R. Price. CVS-Concurrent Versions System v1.12.13, 2005.

[17] S. Raghavan, R. Rohana, D. Leon, A. Podgurski, and V. Augustine. Dex: Asemantic-graph di�erencing tool for studying changes in large code bases. Pro-ceedings 20th IEEE International Conference on Software Maintenance (ICSM'04). IEEE Computer Society Press: Los Alamitos CA, pages 188 � 197, 2004.

[18] J. Sliwerski, T. Zimmermann, and A. Zeller. When do changes induce �x-es? In Proceedings of the Second International Workshop on Mining SoftwareRepositories, pages 24�28, May 2005.

[19] K. M. Syring. Portierungen vieler Unix - Tools fÃ×r Windows. Weitere Infor-mationen unter: http://www.weihenstephan.de/ syring/win32/UnxUtils.html,2003.

[20] The Bugzilla Team. The Bugzilla Guide - 3.0.4 Release, 2008.

[21] The Scmbug Team. Scmbug manual RELEASE 0-23-4, 2008.

[22] The Scmbug Team. Scmbug manual RELEASE 0-26-2, 2008.

[23] C.C. Williams and J.K. Hollingsworth. Bug driven bug �nders. Proceedings1st International Workshop on Mining Software Repositories (MSR '04). Uni-versity of Waterloo: Waterloo ON, pages 70 � 74, 2004.

[24] C.C. Williams and J.K. Hollingsworth. Automatic mining of source code repos-itories to improve bug �nding techniques. IEEE Transactions on SoftwareEngineering, 31(6):466 � 480, 2005.

Page 123: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

Anhang A

Verwendete Software

• Betriebssysteme:

◦ Ubuntu 8.04 (Hardy Heron), Kernel: 2.6.24-18

◦ Windows Vista Business mit Service Pack 1

• Systemkontext der SCM-Integration (vgl. 3.1):

◦ Bugzilla, Version: 3.0.0

◦ Versionsmanagementsysteme:

� Concurrent Versions System (CVS)

· Linux-Version: 1.12.13 (client/server)· CVS-NT: cvsnt-2.5.03.2382

� Subversion (SVN)

· Linux-Version: 1.4.6dfsg1-2ubuntu· Windows-Version: 1.5.4 (CollabNet)

◦ SCMBUG, Version: 0.23.4.1 und 0.26.2

◦ MySQL-Datenbanken:

� Linux: Version 14.12 Distribution 5.0.51a, für debian-linux-gnu (i486)using readline 5.2

� Windows: Version 5.0.51b-win32

◦ UnxUtils: Verwendung der Windows-Variante des Unix-Tools di�. DasTool ist Teil des Sourceforge-Projekts UnxUtils. Eine Beschreibung �ndetsich unter [19].

• Software-Entwicklungstools:

◦ DBDesigner 4.0.5.6

◦ Eclipse:

� eclipse-java-europa-winter-win32� eclipse-jee-ganymede-SR1-linux-gtk� Plugins:

· CAP (Code Analysis Plugin): 1.2.0· Checkstyle Plugin· Metrics Plugin for Eclipse: 1.3.6

123

Page 124: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

124 ANHANG A. VERWENDETE SOFTWARE

· Polarion Subversion Plugin: Subversive

· YourKit Java Pro�ler Plugin: 7.5.9◦ Google Web Tools: 1.5.1 (Windows und Linux)

◦ MySQL GUI Werkzeuge: mysql-gui-tools-5.0-r12-win32

◦ YourKit Java Pro�ler 7.5.8

• Programmiersprachen

◦ Java

� Linux: j2sdk1.6-sun

� Windows: Java (TM) 6 Update 7

◦ Perl

� Windows: ActivePerl-5.10.0.1003-MSWin32-x86-285500

� Linux: perl v5.8.8 built for i486-linux-gnu-thread-multi

• Gra�keditoren / -bearbeitungstools

◦ Visual Paradigm:

� Suite Windows 3.3.20080623

� Suite Linux 3.3.20080609

◦ GIMP (GNU Image Manipulation Program): 2.6.1

• Textverarbeitungsprogramme:

◦ OpenO�ce.org 2.4.1 (Windows und Linux)

� Calc, Draw, Impress

◦ TEX:

� LYX Version 1.5.6 (Mon, Jul 27, 2008)

� TEX 3.141592 (Web2C 7.5.6)

� pdfTEX using libpoppler 3.141592-1.40.3-2.2 (Web2C 7.5.6)

� kpathsea version 3.5.6

Page 125: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

Anhang B

XML-Elemente zur

SCM-Spezi�kation

B.0.1 Übersicht

• <add />, <addFolder />:

Verwendbar, um eine Datei in das lokale Projekt aufzunehmen und unterVersionskontrolle zu stellen. Es erfolgt kein commit!

◦ <add sourceLocation="" sourceFileName="" targetLocation="" target-FileName="" time="" />

◦ <addFolder location="" time="" />

• <branch />:

Erstellen eines Projektbranches.

◦ <branch branchName="" comment="" time=""/>

• <checkout />:

Auschecken eines Projekt-Branches oder -Tags.

◦ <checkout branchName="" projectName="" time="" />

• <commit />:

Für einen Commitvorgang.

◦ <commit comment="" time="" />

• <import />:

Zum Import von Dateien direkt nach der Initialisierung.

◦ <import comment="" time="" >

◦ <file />:

Kind-Element von <import />. Beschreibung einer Datei, die beim Im-port berücksichtigt werden soll.

� <�le sourceFileName="" sourceLocation="" targetLocation="" tar-getFileName="" />

125

Page 126: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

126 ANHANG B. XML-ELEMENTE ZUR SCM-SPEZIFIKATION

• <moveFile />, <moveFolder />:

Verschieben einer Datei / eines Ordners im lokalen Projekt. Es erfolgt keinCommit!

◦ <moveFile �leName="" sourceLocation="" targetLocation="" time=""/>

◦ <moveFolder sourceLocation="" targetLocation="" comment="" time=""/>

• <removeBranch />, <removeFile />, <removeFolder />, <removeTag />:

Löschen einer Datei aus dem lokalen Projekt. Es erfolgt kein commit!

◦ <removeBranch branchName="" comment="" time=""/>

◦ <removeFile location="" �leName="" comment="" time=""/>

◦ <removeFolder location="" comment="" time=""/>

◦ <removeTag tagName="" comment="" time=""/>

• <rename />:

Umbenennen einer Datei /eines Ordners im lokalen Projekt. Es erfolgt keinCommit!

◦ <rename location="" oldName="" newName="" comment=""/>

• <replaceFile />:

Ersetzen einer Datei durch eine andere. Verwendbar zur Simulation einerDateiänderung. Es gibt zwei Testdateien, wobei der Inhalt der zweiten Datei,welche die erste ersetzt, das Resultat der Änderung darstellt.

◦ <replaceFile sourceLocation="" sourceFileName="" targetLocation=""targetFileName="" time="" />

• <tag />:

Erstellen eines Projekttags. Subversion erstellt einen Tag für das gesamte Pro-jekt. CVS markiert eine einzelne Datei mit einem Tagnamen.

◦ <tag location="" tagName="" comment="" time=""/>

B.0.2 Beschreibung der Attribute

• branchName: Bezeichnung des zu erstellenden Branches.

• comment: Kommentar zur Aktivität, der bei der Übermittlung zum SCM-System angegeben wird.. Wichtig: Bug-Referenz durch folgende Syntax: �bugX: KOMMENTAR�.

• �leName: Name und Typ der zu verwendenden Datei.

• location: relativer Pfad, eine Hierarchie-Ebene unter der des Projektordners.

• newName: neuer Datei- oder Ordnername.

• oldName: alter Datei- oder Ordnername.

• projectName: Name des Testprojekts.

• sourceFileName: Quelldateiname.

Page 127: Erweiterung von BugzillaMetrics zur Auswertung von …bugzillametrics.sourceforge.net/publications/diploma_thesis_chris... · 5.1.1 estT des erweiterten Kerns (Bugzilla-Test) . .

127

• sourceLocation: relativer Datei- oder Ordner-Quellpfad, eine Hierarchie-Ebeneunter dem Pfad zum Testdatei-Ordner.

• targetFileName: Zieldateiname.

• targetLocation: relativer Pfad, eine Hierarchie-Ebene unter der des Projek-tordners.

• time: Zeitpunkt der Aktivität. (optional)