Nachverfolgbarkeit von Modellelementen in Versionshistorien

Inhaltsverzeichnis

1 Einleitung und Motivation

2 State-of-the-Art

3 Das Framework
3.1 Präsentation
3.2 Anwendungsfälle
3.3 Korrespondenzberechnung
3.4 Datenbank

4 Praktische Anwendungsfälle
4.1 Kontext eines Anwendungsfalles
4.2 Ausgewählte Anwendungsfälle
4.2.1 Global Tracks
4.2.2 Bug Tracing
4.2.3 Dependency Analysis
4.2.4 Day Flies
4.3 Weitere Anwendungsfälle
4.3.1 Stable/Instable Model Elements
4.3.2 Growth Analysis
4.3.3 Revision Degree
4.3.4 Undone Changes
4.3.5 Simultaneous vs. Subsequent Changes .

5 Evaluierung
5.1 Empirische Studie
5.1.1 Allgemeines
5.1.2 Phase 1: Bekannte Historie
5.1.3 Phase 2: Fremde Historie
5.1.4 Persönliche Beurteilung der technischen Lösung
5.2 Performanz
5.3 Speicherverbrauch

6 Zusammenfassung und Ausblick

A Empirische Studie
A.1 Fragebogen
A.2 Differenzierte Ergebnisaufbereitung
A.2.1 Phase 1: Bekannte Historie
A.2.2 Phase 2: Fremde Historie
A.2.3 Persönliche Beurteilung der technischen Lösung

B Hinweise zur Benutzung

C Eine support/confidence Tabelle

Literaturverzeichnis

Abbildungsverzeichnis

3.1 Architektur des entwickelten Frameworks

3.2 Graphische Komponenten

3.3 Model-View-Controller Konzept in GEF

3.4 Umsetzung der Model-View-Controller Architektur

3.5 Datenmodell der Use Case-Schicht

3.6 Datenmodell des SiDiff -Ansatzes

3.7 ER-Diagramm der Database-Schicht

4.1 Visualisierung des Anwendungsfalles Global Tracks

4.2 Dialog zur Parametereingabe

4.3 Visualisierung des Anwendungsfalles Bug Tracing

4.4 Bestimmung von Abhängigkeiten auf Basis globaler und lokaler Stränge

4.5 Visualisierung des Anwendungsfalles Dependency Analysis

4.6 Visualisierung des Anwendungsfalles Day Flies

4.7 Visualisierungsbeispiel des Anwendungsfalles Revision Degree

4.8 Bildung von Sehnen-Strängen zwischen Entwicklungszweigen

5.1 Übersicht gemäß Erfahrung der Testpersonen

5.2 Präferenz bei bekannter Historie

5.3 Zeitersparnis aggregiert

5.4 Präferenz (gesamt)

5.5 Bewertung der graphischen Interaktion

5.6 Relevanz (gesamt)

5.7 Persönlicher Anwendernutzen

5.8 Performanzuntersuchung an der Historie ”SiDiff Test History”

5.9 Performanzuntersuchung an der Historie ”Basic Package”

5.10 Break-Even-Point bei additiver Berechnung

5.11 Speicherverbrauch bei Visualisierung einer Historie

A.1 Geschwindigkeitsvorteile der technischen gegenüber der manuellen Ausführung

A.2 Korrektheit der Erkenntnisse

A.3 Zeitersparnis bei einzelnen Anwendungsfällen

A.4 Präferenz gemäß Erfahrung der Testpersonen

A.5 Relevanz gemäß Erfahrung der Testpersonen

B.1 Anlegen einer .visualization Datei über den Wizard

B.2 Die neue View und eine .visualization Datei

B.3 Kontextmenü einer .visualisaztion Datei

B.4 Spezifizierung der zu analysierenden Historie

B.5 Einstellen eines Filters über das Kontextmenü des Editor

B.6 Die Beispielhistorie sample History

Tabellenverzeichnis

3.1 Vergleichskriterien für Elemente des Typs ”Klasse”

4.1 Bestimmung von support und confidence mittels SQL

4.2 Ermittlung der day flies mittels SQL

5.1 Übersicht der Testpersonen

5.2 Gründe der Präferenz eines Verfahrens

5.3 Gründe der Präferenz (gesamt)

5.4 Hilfreiche graphische Funktionen

5.5 Verbesserungsmöglichkeiten / vermisste Funktionalitäten

C.1 Beispiel einer gelieferten support/confidence Tabelle

Zusammenfassung

Modellbasierte Software-Entwicklung wird als die neue Form der Entwicklung von Software-Systemen gepriesen. Die Evolution des Software-Systems findet auf der abstrakten Ebene der Modelle statt. Diese erlaubt, analog zu den klassischen Quellcode-Dateien, das Ablegen von Zwischenständen in Versionen.

Fragestellungen an eine aus einzelnen Versionen entstandene Historie gibt es viele. An die Analysemöglichkeit ist jedoch die Voraussetzung geknüpft, dass die Nachver- folgbarkeit einzelner Modellelemente über diese Historie hinweg gewährleistet sein muss.

An dieser Stelle setzt die vorliegende Diplomarbeit an. Im Rahmen dieser wird die Nachverfolgbarkeit einzelner Modellelemente auf Basis von Differenzwerkzeugen realisiert. Ferner wird durch ein eigens konzipiertes Framework die Möglichkeit ge- boten, eine Historie zu erfassen und aus unterschiedlichen Fragestellungen heraus analysieren zu können. Als Anwendungsfälle verstanden, umfasst die Arbeit die De- finition und die detaillierte Betrachtung von neun Analysemöglichkeiten.

Eine praktische Umsetzung des Frameworks erfolgt mit dem Fokus auf vier re- präsentativen Anwendungsfällen in Form eines Werkzeugprototypen. Als Plug-in für die Eclipse IDE entworfen, stellt er eine graphische Visualisierungskomponente und Benutzerschnittstelle bereit und wurde im Rahmen einer empirischen Studie an potentiellen Anwendern hinsichtlich der Praxistauglichkeit und Anwenderakzeptanz evaluiert.

Kapitel 1

Einleitung und Motivation

In der modellbasierten Software-Entwicklung (MDE) werden Softwaresysteme in der Praxis durchgängig mit Hilfe von Modellen beschrieben. Die Modelle sind eine abstrakte Darstellung der Software. Sie sind auch für Nicht-Entwickler verständlich und können in konkretere Modelle oder Programmcode transformiert werden. Wie bei klassischem Programmcode, besteht auch bei Modellen die Möglichkeit der Versionierung, um Zwischenstände der Entwicklung zu speichern.

Mit zunehmenden Einsatzbereichen werden oftmals neue Varianten einer Software entwickelt, um Anforderungen zu realisieren, die nicht in das eigentliche Produkt einfließen sollen. Es werden beispielsweise neue Ansätze erprobt oder der Fokus liegt einzig auf Wartungsarbeiten. Deshalb wird innerhalb der Versionsverwaltung ein eigener neuer Entwicklungszweig (engl. branch)¹ erzeugt. Dieser enthält eine Kopie der bisherig entwickelten Softwaremodelle, die anschließend weiterbearbeitet und neu versioniert werden. Dies führt im Laufe der Zeit dazu, dass die Modelle des Hauptproduktes und aller Nebenprodukte weitgehend unabhängig von einander weiterentwickelt werden. Dadurch entstehen u.a. folgende Probleme:

- Erweiterungen in einem Entwicklungszweig lassen sich nur schwer auf andere Entwicklungszweige übertragen
- Es entstehen Dubletten in verschiedenen Entwicklungszweigen, die zu weiteren Wartungsproblemen führen
- Fehlerkorrekturen werden in einem Entwicklungszweig durchgeführt, in einem anderen aber ausgelassen, weil der Zusammenhang unbekannt ist.

Die Ursache für diese Probleme ist, dass die Historie einzelner Elemente nicht nachverfolgbar ist.

Zielsetzung

Ziel dieser Diplomarbeit ist es, Nachverfolgbarkeit von Modellelementen auf Ba- sis von ermittelten Korrespondenzen [Kel06] in Versionshistorien zu ermöglichen.

Es soll der Prototyp eines Werkzeuges (nachfolgend Prototyp genannt) entwickelt werden, der die Versionshistorie aus den einzelnen Versionen der Softwaremodel- le erfasst und eine weitere Verwendung innerhalb eines Frameworks ermöglicht. Die Konzeption eines solchen Frameworks ist ebenfalls Gegenstand dieser Arbeit und soll neben der Möglichkeit, eine Historie untersuchen zu können, zusätzlich eine Visua- lisierungskomponente umfassen, die als interaktive Schnittstelle zu dem Anwender verstanden wird.

Aufbauend auf der Nachverfolgbarkeit der Modellelemente, werden verschiedene Analysemöglichkeiten der Historie entwickelt und deren Aussagekraft in Bezug auf die oben genannten Probleme untersucht.

Das Werkzeug richtet sich in seinem Aufbau und den behandelten Analysemöglichkeiten vorrangig an folgende Anwendertypen:

1. Verantwortliche Entwickler, denen die Historie der Softwaremodelle bekannt ist,
2. Reverse Engineers, die sich in ein fremdes System einarbeiten müssen und
3. Projektmanager, die weniger an einzelnen technischen Fragen interessiert sind, als vielmehr an aggregierten Informationen, die das Gesamtprojekt betreffen.

Aufbau der Arbeit

Kapitel 2 liefert einen Überblick über vorhandene Ansätze in der Literatur, die sich mit ähnlichen Fragestellungen befassen.

Im Anschluss daran folgt in Kapitel 3 die Vorstellung des konzipierten und in Form des Prototypen umgesetzten Frameworks.

Kapitel 4 beschreibt den Schwerpunkt dieser Diplomarbeit: die entwickelten Analysemöglichkeiten innerhalb des Frameworks. Die Vorstellung der Analysemöglichkeiten erstreckt sich von der Zielsetzung über die konkrete oder eine mögliche Umsetzung, bis hin zur Form der Visualisierung.

In Kapitel 5 wird der entwickelte Prototyp sowohl hinsichtlich technischer Funk- tionalitäten als auch in Bezug auf Praxistauglichkeit und Anwenderakzeptanz hin evaluiert. Basis hierfür bildet eine zu diesem Zweck durchgeführte empirische Stu- die, in der Testdaten aus realen Systemen und potentielle Anwender im Mittelpunkt stehen.

Kapitel 6 fasst die Arbeit in ihren wesentlichen Zügen zusammen und gibt einen Ausblick über mögliche Erweiterungen und aufbauende Arbeiten.

Kapitel 2

State-of-the-Art

Die Evolution eines Software-Systems stellt unterschiedlichste Informationen hin- sichtlich Wachstum und Methodik während des Entwicklungsprozesses bereit. Die Bestrebungen, eine vorhandene Versionshistorie dahingehend zu analysieren, beste- hen schon seit geraumer Zeit. Die Fragen sind dabei so vielfältig, dass es eine eben- so lange Reihe an Lehren daraus gibt, die zu einer Ansammlung von Gesetzen zu Software-Evolution, den Lehman’s laws [LRW+97] geführt haben. Lag deren Anzahl in den 70er Jahren noch bei drei, ist sie bis in die 90er Jahre auf acht gestiegen. Die Lehren dieser Gesetze basieren auf empirischen Untersuchungen der Evolution kommerzieller Software-Systeme. Jüngere Arbeiten wie [RAGBH05] untersuchen die Gültigkeit dieser Gesetze auch bei freier oder open source Software. Dabei steht be- sonders Lehmans 4. Gesetz im Fokus, welches besagt, dass der Grad der Entwicklung eines Systems über die Zeit hinweg annähernd konstant und unabhängig von den verwendeten Ressourcen ist. Ausgehend von der Annahme, dass freie/open source Software anders als kommerzielle Software entwickelt wird, da das jederzeitige Ein- steigen fremder Entwickler ermöglicht wird und auch die Bildung von Communities ein fester Bestandteil ist, untersucht diese Arbeit die Richtigkeit der Annahme an- hand der Evolution des Linux-Kernels sowie 18 weiterer freier Software-Projekte.

Beispiele von durchgeführten Analysen auf einer vorhandenen Software-Historie mit dem Ziel, Design-Entscheidungen in den weiteren Entwicklungsphasen zu be- einflussen, finden sich bereits in [GJKT97]. Darin wurde eine Historie aus Produkt- releases auf Module hin untersucht, die im Laufe der Entwicklung oft erweitert worden sind und daher sinnvollerweise neu strukturiert werden sollten. Die Analy- sen, die Module mit strukturellen Mängeln aufdecken sollten, beschränkten sich auf die Auswertung der Größe, der Änderungsrate und der Wachstumsrate der jeweili- gen Module und erstreckten sich über eine Menge von Informationen, die zu jedem Release parallel zur Entwicklung in einer Datenbank gepflegt worden sind.

Die Mehrzahl der in der Literatur beschriebenen Verfahren stützen sich bei der Bereitstellung der zu untersuchenden Versionen auf Konfigurationsmanagementsys- teme (KMS), i.d.R. Concurrent Versions System (CVS). Dieses operiert dateibasiert, was bedeutet, dass ein Software-Element einer Konfiguration (configuration item) immer eine Datei ist, entweder mit textuellem oder mit binärem Inhalt. So verwen- det beispielsweise Zimmermann et al. in [ZZWD05] eine aus einem CVS-Repository extrahierte Versionshistorie, um mittels der Technik der Assoziationsregeln aus dem Data Mining [HK06] Abhängigkeiten¹ zwischen einzelnen Elementen aufzudecken. Dazu werden zeitlich nahe Änderungen zu Transaktionen zusammengefasst, die als Basis für Assoziationsregeln dienen. Das Verfahren wird durch den implementier- ten Prototypen ROSE² als Eclipse³ Plug-in bereitgestellt. Der Ansatz operiert auf Quellcode-Ebene, ist jedoch nicht auf eine Programmiersprache beschränkt. Die Quellcode-Dateien werden eingelesen und aus Zeilenabschnitten im Quellcode wer- den Entitäten erzeugt. Die Entitäten bilden das Grundkonzept des Ansatzes und werden durch ein Tripel aus Name der betroffenen Datei, der syntaktischen Ka- tegorie (die Granularität, welche über Klasse und Methode bis hin zu Variablen geht) und dem Identifier (Name) des betroffenen Elementes beschrieben. Ermittelte Abhängigkeiten beziehen sich auf Entitäten.

Teilweise ähnliche Fragestellungen zu Zimmermann et al. finden sich auch bei Bouktif et al. in [BGA06]. Dieser Ansatz unterscheidet sich dahingehend vom erst- genannten, dass er eine Technik zur Mustererkennung verwendet. Auf Basis von Dynamic Time Warping (DTW) werden symmetrische Distanzen zwischen den His- torien der Dateien (vorhanden in einem CVS-Repository) berechnet und zu einem Cluster hinzugefügt, sofern die Distanz einen vorgegebenen Schwellenwert unter- schreitet. Es wird das grundlegende Konzept der Änderungsmuster definiert und mit dem Synchrony ein erstes Muster vorgestellt, welches gemeinsam zu ändernde Dateien als solche hervorhebt. Ein Änderungsmuster bezieht sich auf ein vorgege- benes Zeitfenster, welches entweder über eine maximale Zeitspanne (z.B. nicht älter als ein Jahr) oder über die Anzahl der getätigten Änderungen einer Datei (z.B. die letzten zehn Änderungen) definiert werden kann. Während der Evaluierung des An- satzes, konnten verbesserte Ergebnisse zu denen von Zimmermann et al. [ZZWD05] erzielt werden.

In [OMW05] entfernt man sich von den Restriktionen von CVS und stellt mit Odyssey-VCS ein flexibles KMS vor. Dieses unterscheidet sich von üblichen Konfi- gurationsmanagementsystemen dahingehend, dass es eine speziell auf die Struktur eines Diagramms der Unified Modeling Language (UML) abgestimmte Versionierung ermöglicht, welche für jedes Software-Projekt individuell konfiguriert werden kann. In der aufbauenden Arbeit [DMW05] wird solch ein versioniertes UML-Repository verwendet, um mittels Assoziationsregeln Änderungsmuster zwischen Modellele- menten zu bestimmen. Die Intention liegt darin, bei einer eingespielten Änderung abhängige Elemente lokalisieren und parallel aktualisieren zu können. Dies kann innerhalb der gleichen Abstraktionsschicht erfolgen (intra-model-traces) oder zwi- schen mehreren Abstraktionsschichten (inter-model-traces), wie beispielsweise Ana- lyse, Design oder Code. Der Anwender soll zu jeder ermittelten Abhängigkeit nach- vollziehen können, welche parallel erfolgten Änderungen zu dieser Assoziationsregel geführt haben und unter welchen Umständen diese zustande gekommen ist. Dazu liefert das zugrunde liegende Odyssey-VCS Antworten auf die 6W (Wer?, Wann?, Wie?, Was?, Warum? und Wo?).

In die gleiche Richtung, jedoch mit anderem Fokus, zielen die Bemühungen in [RL06] ab. Gemein ist die Ansicht, dass die Informationen, bereitgestellt aus Kon- figurationsmanagementsystemen wie CVS oder Subversion⁴, nicht ausreichend sind, um qualitative Wachstumsanalysen einer Software-Historie betreiben zu können. Das liegt zum einen an der dateibasierten und auf Momentaufnahmen gestützten Be- trachtungsweise der meisten Konfigurationsmanagementsysteme, zum anderen dar- an, dass die Zeitintervalle, in denen Änderungen in das KMS eingecheckt werden, oftmals sehr groß sind. Das kann dazu führen, dass die Differenz eines Elementes zu seinem Vorgänger derart gravierend ist, dass eine Nachverfolgbarkeit nicht mehr herbeigeführt werden kann. Neben dem Ziel der Differenzberechnung verfolgt die- ser Ansatz - ähnlich dem Grundgedanken der vorliegenden Arbeit - das Bestreben, das Evolutions-Werkzeug in die Integrated Development Environment (IDE) des Anwenders zu integrieren, um es in seinem täglichen Arbeitsablauf zu etablieren. Benötigte Informationen werden dadurch direkt aus der IDE statt aus dem KMS bezogen. Das bringt den Vorteil mit sich, dass weniger Änderungen verloren gehen, weil deren Erfassung nicht mehr von dem Zeitintervall bis zum nächsten Einchecken in das KMS abhängt. Da jede IDE in irgendeiner Form Ereignisse unterstützt, kann auf jede noch so kleine Änderung des Entwicklers reagiert werden. Tritt dieser Fall ein, werden first-class change objects erzeugt, die die Semantik der ausgeführten Ak- tion enthalten. Diese Änderungsobjekte speichern lediglich program-level differences, was dazu führt, dass jeder beliebige Zeitpunkt des Systems wiederhergestellt werden kann. Vereinfacht gesagt, realisiert dieser Ansatz, der Änderungen auf Code-Ebene erfasst, eine Art Monitoring des Systems und bietet dem Anwender eine interaktive Visualisierung der Historie.

Neben der Arbeit an Verfahren zur Ermittlung verdeckter Informationen aus Ver- sionshistorien, wird auch an einigen Stellen über die Visualisierung dieser Informa- tionen nachgedacht. D’Ambros und Lanza vermitteln in [DL06] mit dem Evoluti- on Radar einen Eindruck davon, wie Informationen über zeitliche Entwicklungen und Zusammenhänge dem Anwender sowohl im Detail als auch als ”big picture” präsentiert werden können. Das Evolution Radar visualisiert Abhängigkeiten zwi- schen Dateien und Gruppen von Dateien, beispielsweise Module oder Subsysteme. Ein aktuell betrachtetes Modul befindet sich in der Mitte des Radars, während die anderen Module durch Sektoren repräsentiert werden, deren Größe von der Anzahl der enthaltenen Dateien bestimmt wird. Der Radius, in dem sich diese vom be- trachteten Modul aus befinden, wird durch die Stärke der Abhängigkeit bestimmt. Zur Ermittlung der Abhängigkeiten werden - ähnlich wie bei Zimmermann et al. - aus vorhandenen CVS Informationen über ein Zeitfenster (Sliding Time Window ) [ZW04] Transaktionen rekonstruiert. Der Wert der Abhängigkeit zweier Dateien ergibt sich aus der Anzahl der Transaktionen, in die beide Dateien gemeinsam in- volviert sind. Die Umsetzung der Visualisierung bietet die drei Funktionen Moving through Time, Tracking und Spawning an. Vor dem Hintergrund, dass ein Radar zeit- bezogen ist, es somit Abhängigkeiten anzeigt, die nur innerhalb einer bestimmten Zeitspanne gültig sind, realisiert Moving through Time die Möglichkeit, sich mehre- re Radare generieren zu lassen, die alle ein anderes Zeitintervall abdecken. Tracking bewirkt, dass eine Datei in allen verfügbaren Radaren hervorgehoben wird, wenn sie in der Visualisierung selektiert worden ist. Die dritte Funktion Spawning erlaubt es, diejenigen Dateien, die die stärkste Abhängigkeit zu dem fokussierten Modul haben, zu einem Pseudomodul zusammenzufassen und als neues fokussiertes Modul in ei- nem separaten Radar genauer zu untersuchen. Auf diese Art wird ermittelt, welche Dateien des zuerst fokussierten Moduls im Einzelnen eine starke Abhängigkeit zu den gefundenen Kandidaten haben.

Ansätze zur Visualisierung einer Software-Historie beschränken sich nicht nur auf 2D-Modelle. Gall et al. erweitern in [GJR99] die graphische Darstellung um eine 3. Dimension, auf welcher die Zeit abgebildet wird. In dieser interaktiven 3D- Präsentation ist es möglich, durch die Struktur des Software-Systems zu navigieren und einzelne Versionen der Historie genauer zu überprüfen.

Unter der gleichen Zielsetzung, Nachverfolgbarkeit zwischen Versionen einer OO- Software zu ermöglichen, stützt sich der Ansatz von Antoniol et al. [ACL99] auf die Abstract Object Language (AOL). Diese Beschreibungssprache für OO-Design wur- de in [AFC98] erstmals vorgestellt und eigens dafür entwickelt, um OO-Konzepte

- unabhängig von der verwendeten Programmiersprache oder der Werkzeuge - for- mal zu erfassen. Nachdem zu Beginn das Design einer Version aus dem zugrunde liegenden C++ Code in eine AOL Repräsentation extrahiert worden ist, werden die Ähnlichkeiten ermittelt sowie zusätzlich Software-Metriken über Klassen und Funktionen gesammelt. Ähnlichkeitswerte werden auf Basis des string edit distance Algorithmus berechnet. Die Ermittlung einer Korrespondenz zwischen zwei Objek- ten und die Bestimmung einer optimalen Übereinstimmung (Match) zwischen zwei Versionen erfolgt anschließend anhand des maximum match algorithm und des maxi- mum flow algorithm [CLR90], jeweils auf einem bipartiten Graph. Zur Visualisierung sowohl der Differenzergebnisse als auch der Metriken werden für jedes Versionenpaar separate HTML-Seiten generiert.

Ganz auf die Berechnung von Ähnlichkeitswerten verzichtet der Ansatz von Egyed [Egy01]. Das Verfahren unterscheidet sich etwas von den übrigen vorgestellten, da es auf die Problematik des requirements traceability eingeht. Betrachtet man die Fachliteratur zu diesem Thema, so stellt man schnell fest, dass das Verständnis davon sowie die Ansätze und Ziele zur Lösung des Problems untereinander sehr stark differieren. Obwohl sich keine einheitlichen Definitionen oder Standards hierzu finden lassen, soll die folgende Beschreibung ein erstes klares Bild darüber liefern, was unter dem Problemfeld requirements traceability verstanden werden kann:

”Requirements traceability refers to the ability to describe and follow the life of a requirement, in both a forwards and backwards direction (i.e., from its origins, through its development and specification, to its subsequent deployment and use, and through all periods of on-going refinement and iteration in any of these phases).” [GF94]

Die Ausgangslage bei Egyed wird bestimmt durch die Aussage, dass ein System auf verschiedene Weisen modelliert wird (Flow Chart, Class Diagram, Use Case Dia- gram etc.), die Korrespondenzen zwischen Elementen eines Modells zu den Elemen- ten eines anderen Modells jedoch unklar sind. Ebenfalls unklar ist die Antwort auf die Frage, auf welche Stellen im Code diese Elemente abgebildet worden sind. Der Ansatz versucht, iterativ auf Basis laufender Testszenarien Nachverfolgbarkeit (tra- ces) zu erzielen. Hierzu unterscheidet das Verfahren vier Arten von traces⁵. Solche zwischen:

1. Szenarien und System (Code-Stellen)
2. Modellelementen und System (Code-Stellen)
3. Szenarien und Modellelementen
4. Modellelementen und Modellelementen

Benötigte Informationen werden gesammelt, indem Testszenarien auf dem System ausgeführt werden (acceptance test scenarios, module test cases etc.), durch die in- terne Abläufe des Systems beobachtet und aufgezeichnet werden. Dies impliziert die Notwendigkeit vorhandener Monitoring-Werkzeuge, um das System während der Ausführung oder Simulation detailliert beobachten zu können. Durch iterative Ge- winnung der Nachverfolgbarkeit und der Überprüfung gefundener Korrespondenzen in einer Graphübersicht (footprint graph), werden bestehende Hypothesen verifiziert bzw. entkräftet.

Die meisten Parallelen zu dem in dieser Arbeit beschriebenem Framework fin- den sich in [XS05]. Darin wird der Prototyp JDEvAn (Java Design Evolution and Analysis) vorgestellt, welcher aufeinander folgende Versionen von JAVA Quellcode- Dateien miteinander vergleicht und die Unterschiede visualisiert. Den Kern des als Eclipse Plug-in realisierten Werkzeuges bildet UMLDiff ; ein Verfahren zur Analyse der Evolution des Designs eines Software-Projektes. Die zu untersuchenden Modelle werden in einem ersten Schritt aus Quellcode-Dateien extrahiert. Jede extrahierte Programmentität (in dem extrahierten Graph entspricht diese einem Knoten) hat beschreibende Attribute (Typ, Name, Sichtbarkeit etc.). Die Kanten des Graphen re- präsentieren die Verbindungen zwischen zwei Knoten, abgebildet als Tupel (relation, program entity1, program entity2 ). Während der Ähnlichkeitsberechnungdurchläuft der Algorithmus den extrahierten Graphen top-down und vergleicht Entitäten des gleichen Typs anhand a) name-similarity heuristic oder b) structure-similarity heu- ristic. Als sicherer Indikator dafür, dass zwei Entitäten miteinander korrespondie- ren, wird die Übereinstimmung des Namens angesehen. Bei einer Historie werden alle Versionen paarweise miteinander verglichen, wobei die Sequenz der ermittelten Änderungen als audit trail der Evolution des Systems bezeichnet wird. Die Pfade (trails) werden in der Form ausgewertet, dass Profile (system-evolution profile und class-evolution profile) für jede einzelne Klasse bzw. Interface gebildet werden. An- hand dieser Profile wiederum lassen sich unterschiedliche Phasen und Arten in der Evolution des Systems bzw. der Klassen erkennen; auch lassen sich Klassen iden- tifizieren, die sich gemeinsam entwickelt haben. In [XS04] stellen beide Autoren drei Analysearten vor, die - auf system-evolution profiles angewendet - Rückschlüsse auf die Entwicklungsmethodik und -phasen des Software-Systems zulassen. Anhand von phasic analysis, gamma analysis und optimal matching analysis wird aus der Sequenz der Änderungen ein Entwicklungsstil (evolution style) abgeleitet. Dies ge- schieht dadurch, dass in einem ersten Schritt deskriptive Statistiken, Streuungsmaße und Mittelwerte für die baumartig zusammengefassten Änderungen berechnet wer- den. Das statistische Zahlenmaterial wird in die Bereiche ”High”, ”Medium” und ”Low” eingeteilt. Eine Kombination dieser Werte liefert eine fünfstufige Klassifikati- on an Änderungsaktivitäten (Entwicklungsarten): Active, Rapid developing, Restruc- turing, Slow developing und Steady-going. Durch unterschiedliche Konstellationen dieser Entwicklungsarten über den Entwicklungszeitraum eines Software-Projektes hinweg, lassen sich einzelne Entwicklungsstile ableiten.

Wenn man die oben beschriebenen Ansätze betrachtet, so fällt auf, dass zwar alle in gewisser Art und Weise die Historie eines Software-Projektes untersuchen - manche sogar eine Visualisierung und Benutzerinteraktion bereitstellen - der Fo- kus jedoch meist auf einer zentralen Fragestellung liegt. Dies schränkt einen Ansatz hinsichtlich weiterer Analysemöglichkeiten ein. Hinzu kommt, dass in den meisten Fällen zusätzlich Restriktionen in Bezug auf den Typ (z.B. Quellcode-Dateien) und die Quelle (standardisiertes oder proprietäres KMS) der unterstützten Dokument- typen gemacht worden sind. Um diese Einschränkungen aufzubrechen, ist in dieser Diplomarbeit ein Framework entwickelt worden, welches einen generischen Ansatz sowohl hinsichtlich der Analysemöglichkeiten, als auch der unterstützen Dokument- typen liefert. Im nachfolgenden Kapitel wird das Framework im Detail vorgestellt.

Kapitel 3

3 Das Framework

In dem folgenden Kapitel wird das entwickelte Framework und dessen Komponen- ten vorgestellt. Das Framework umfasst die vier Schichten ”Präsentation”, ”Anwen- dungsfälle”, ”Korrespondenzberechnung” und ”Datenbank”. Eine Gesamtübersicht der zugrunde liegenden Architektur liefert Abbildung 3.1. Die Verwendung zwei- er Schriftfarben soll eine Unterscheidung konzeptioneller Aspekte von Aspekten der konkret gewählten Umsetzung innerhalb des Prototypen bewirken. Aus der Überlegung heraus, den Nutzen und die Verfügbarkeit des Werkzeuges für den An- wender zu steigern, wurde der Prototyp als Eclipse Plug-in entwickelt, um auf diesem Weg besser in den operativen Tagesablauf integriert werden zu können.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.1: Architektur des entwickelten Frameworks

3.1 Präsentation

Die oberste Schicht des Frameworks bietet die Möglichkeit der interaktiven Kom- munikation mit dem Anwender. Hierfür werden die graphischen Komponenten der Eclipse IDE genutzt und an einigen Stellen erweitert. Das führt dazu, dass durch das bekannte look-and-feel eine gewohnte Arbeitsumgebung beibehalten werden kann.

An dieser Stelle steht weniger die Bedienung der graphischen Oberfläche im Mittelpunkt, als vielmehr eine grobe Vorstellung der verwendeten Konzepte vermittelt werden. Konkrete Beispiele der Visualisierung finden sich bei der detaillierten Vorstellung der einzelnen Anwendungsfälle. Zusätzlich dazu, enthält Anhang B eine umfassende Beschreibung zur Bedienung der Benutzerschnittstelle.

Für die Visualisierung wurde auf IDE-eigene Komponenten wie den Editor, die Outline oder eine View zurückgegriffen. Die zentrale Funktionalität liegt beim Edi- tor, in dem eine aktuelle Historie ganzheitlich visualisiert wird. Der Editor bietet nicht nur den Vorteil, dem Anwender durch die baumartige Repräsentation eine schnelle bildhafte Vorstellung über die Evolution zu verschaffen, sondern vielmehr während der Phase der Implementierung das Einhaken in vorhandene unterstützende Mechanismen schnell und unkompliziert zu ermöglichen. Hierzu zählen beispiels- weise die Ereignisverarbeitung, die Kontextmenüs oder die Zoom-Funktionalität. Bei der Darstellung der Historie und den Erkenntnissen aus den jeweiligen Anwen- dungsfällen, wurde Wert darauf gelegt, diese dem Anwender gegenüber möglichst intuitiv zu gestalten. Ferner wurde die Bereitstellung eines ”big picture” angestrebt, damit auch externe Anwender, beispielsweise Projektmanager, die ermittelten In- formationen schnell einordnen und leicht verstehen können. Bei der Visualisierung kommt die Historie mit drei graphischen Komponenten aus: a) einem Rechteck samt Label, welches eine Version und ihre Versionsnummer abbildet, b) einer gerichteten Kante, welche die zeitliche Entwicklung einer Version zur nächsten angibt und c) einem Kreis, der innerhalb eines Rechtecks angeordnet wird und ein Modellelement repräsentiert. Abbildung 3.2 veranschaulicht die Komponenten.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.2: Graphische Komponenten

Für die Realisierung dieser Form der Darstellung bietet Eclipse das Graphical Editing Framework (GEF) [Fou07a] an, welches höherwertigere Komponenten als an- dere graphische Frameworks zur Verfügung stellt [Dau06]. Das Framework setzt auf die Graphikschicht Draw2D auf und nutzt die darin befindlichen graphischen Objek- te zur Implementierung des Model-View-Controller (MVC) Musters [GHJV95]. GEF

3.1 Präsentation

stellt hinsichtlich der MVC-Architektur nur die Unterstützung für die Realisierung der Viewer und Controller bereit - das Modell muss von der jeweiligen Anwendung bereitgestellt werden. Alle graphischen Objekte aus Draw2D basieren auf der Klas- se Figure, beschrieben durch das Interface IFigure. Controller - in GEF EditPart genannt - bilden die Verbindung zwischen einem Objekt des Modells und der graphi- schen Repräsentation und kümmern sich zusätzlich um die Editiermöglichkeiten. Das Datenmodell wird bei der Darstellung im Editor mit Hilfe eines GraphicalViewers, bei der Darstellung in der Outline durch die Klasse TreeViewer angezeigt. In bei- den Fällen gilt die Voraussetzung, dass vorher für den Viewer eine EditPartFactory registriert worden sein muss. Diese fertigt zu jedem Objekt des Datenmodells eine korrespondierende GraphicalEditPart- respektive eine TreeEditPart-Instanz an. Abbildung 3.3 veranschaulicht diese Struktur.

Abbildung in dieser Leseprobe nicht enthalteng

3.3: Model-View-Controller Konzept in GEF (Quelle: [Fou07a])

Anzumerken sei an dieser Stelle noch, dass es sich zwischen den MVC-Kompo- nenten nicht immer um ein 1:1 Mapping handeln muss. Mehrere Datenmodell- Objekte können auch durch ein gemeinsames Controller-Objekt versorgt werden. Je- de EditPart-Instanz liefert über die Operation getModel() das zugeordnete Objekt aus dem Datenmodell. Möchte man die entsprechende graphische Repräsentation ansprechen, erfolgt dies je nach Art des Viewers entweder über die Operation getFigure() oder die beiden Operationen getImage() und getText(). EditParts weisen - oftmals ähnlich dem Datenmodell - eine hierarchisch organisierte Struktur auf, die sie an die View-Sicht weitergeben. Dies führt als Konsequenz dazu, dass sich drei hierarchisch aufgebaute Datenstrukturen ergeben, die gemäß dem MVC- Muster einander entsprechen. Abbildung 3.4 liefert die konkrete Umsetzung dieser Architektur, wie sie in der Präsentationsschicht des Prototypen zum Zuge kommt.

Um sich eine Historie und anwendungsfallspezifische Ergebnisse anzeigen zu las- sen, bedarf es eines Input-Objektes für den Editor. Hierfür ist eine Datei mit der Endung .visualization vorgesehen. Der Vorzug gegenüber einem nur zur Laufzeit existierenden Objekt basiert zum einen auf der persistenten Haltung der interak- tiv gefundenen Erkenntnisse. Hier ist die Identifikation der gesuchten Elemente und

Abbildung 3.4: Umsetzung der Model-View-Controller Architektur (Quelle: in Anlehnung an [Fou07a])

deren farbliche Präsentation auf Basis der sich dahinter verbergenden Informatio- nen gemeint, die bei einem erneuten Herangehen nicht abermals zusammengesucht werden müssen. Zum anderen ergibt sich der Vorteil, dass Dateien zwischen Anwen- dern ausgetauscht werden können (shared files). Analyseergebnisse eines Einzelnen können schnell an andere geschickt und von diesen eingesehen werden, ohne dass sie den Aufwand, der für das Erlangen der Erkenntnisse nötig ist, selbst betreiben müssen.

Abschließend soll noch auf vorhandene Alternativen zu dem Graphical Editing Framework eingegangen werden. Vor dem Hintergrund, dass das Framework ur- sprünglich für die Entwicklung von Modellierungswerkzeugen geschaffen worden ist und ihm diese Vergangenheit immer noch etwas nachhängt, weist GEF einige Schwächen auf. Hierunter fällt in erster Linie die Tatsache, dass viele Konzepte nicht generisch genug sind, um für ein breites Anwendungsspektrum einsetzbar zu sein [Dau06]. Das führt dazu, dass eine Verwendung GEFs sehr stark von den An- forderungen der jeweiligen Anwendung abhängt. Betrachtet man jedoch die Alter- nativen in Form des open source Standard Widget Toolkits (SWT) [Fou07b], welches die nativen graphischen Elemente des zugrunde liegenden Betriebssystems nutzt¹, der Swing-Bibliothek oder der Verwendung von SVG (Scalable Vector Graphics), so überwiegen für die graphische Präsentation innerhalb des Prototypen doch die Vor- teile, die GEF mit sich bringt. Diese liegen neben der guten Integration in die Eclip- se-Plattform (was die Verwendung vorhandener IDE-Komponenten sehr erleichtert) in der graphischen Repräsentation beliebiger Datenmodelle durch das MVC-Muster. Gerade die Bereitstellung benötigter Funktionen, wie der Unterstützung für Verbin- dungslinien und deren automatisches Routing, der Zoom-Funktionalität oder der verschiedenen Ebenen (Layer), erleichtert eine praktische Umsetzung in vielerlei Hinsicht.

3.2 Anwendungsfälle

Um aus Historien adäquate Erkenntnisse erzielen zu können, benötigt man Men- gen von Informationen. Genau diese Vielfalt vergrößert das Problem einer Analyse, denn je mehr Versionen zu betrachten sind, desto mehr Daten und Informationen müssen untersucht werden. Steigt die Menge zu untersuchender Daten, werden bes- sere Techniken benötigt, um diese in geeigneter Art und Weise auswerten zu können [Gˆır05]. Zu diesem Zweck wird an dieser Stelle das Konzept der ”Anwendungsfälle” eingeführt.

Die Schicht der Anwendungsfälle (engl. use cases) definiert Analysemöglichkeiten basierend auf Fragestellungen, die im Laufe des Entwicklungsprozesses eines Software-Projektes (oder diesem nachgelagert) zu einer gezielten Analyse der His- torie führen. Ein Anwendungsfall kann in diesem Zusammenhang somit als spezielle Analyse-Sicht auf eine Versionshistorie verstanden werden. Dieser Ansatz ermöglicht eine gezielte Betrachtung und/oder Bewertung einer Historie anhand spezieller Vor- gaben und Zielsetzungen und ist um neue Anwendungsfälle flexibel erweiterbar. Als höhere Abstraktionsebene nutzt diese Schicht die Verfahren zur Korrespondenzbe- rechnung aus der darunter liegenden Schicht, um die Ergebnisse zu den individuellen Fragestellungen zu ermitteln.

Aufgrund der Tatsache, dass ähnliche Ansätze in der Literatur aus der Betrach- tung einer einzelnen Fragestellung heraus entwickelt worden sind (in den meisten Fällen ist es das Aufdecken von logical coupling), ist kein Konzept umgesetzt wor- den, wonach die Art und die Anzahl der Analysemöglichkeiten flexibel erweitert werden können; oft war eine solche Ausweitung weder angedacht noch vorgesehen. Der von Xing und Stroulia in [XS04] vorgestellte Ansatz bildet hierzu in gewisser Weise eine Ausnahme. Auch wenn nicht explizit von einem Konzept ähnlich dem der Anwendungsfälle gesprochen wird, lässt sich dennoch die Intention der Autoren erkennen, eine Historie unter verschiedenen Gesichtspunkten untersuchen zu wollen und dafür benötigte Informationen zur Nachverfolgbarkeit zu verwenden.

Das Datenmodell, welches der Use Case-Schicht zugrunde liegt, kann Abbildung 3.5 entnommen werden. Während die Klasse History darin eine zentrale Stellung einnimmt, umfasst das Datenmodell daneben zusätzlich folgende Klassen und Inter- faces:

IUseCase Das Interface IUseCase muss von allen Anwendungsfällen, die im Hin- blick auf die Historie derzeit analysiert oder zukünftig noch analysiert werden sollen, implementiert werden. Es definiert die Methode analyseHistory(), die den individuellen Ablauf eines jeden Anwendungsfalles umsetzt. Als Stra- tegy-Muster [GHJV95] realisiert, bilden die Anwendungsfälle eine Familie, deren konkrete Algorithmen zur Laufzeit jederzeit austauschbar sind. Über currentCase kennt ein History-Objekt den aktuellen Anwendungsfall, aus dessen Gesichtspunkt heraus es betrachtet wird.

HistoryNodetrack Der zentrale Grundbaustein einer Historienanalyse ist die Fähigkeit, einzelne Modellelemente über diese hinweg nachverfolgen zu

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.5: Datenmodell der Use Case-Schicht

können. Dieser Anforderung wird in dieser Arbeit mit dem Konzept der Stränge begegnet, einem Ansatz, in gewisser Weise ähnlich den trails aus [XS05]. Ein Strang (engl. track ) basiert auf der abstrakten Klasse HistoryNodetrack und repräsentiert eine redundanzfreie Menge an Model- lelementen, welche anhand eines Kriteriums (engl. criterion) gebildet worden ist. Das Kriterium wird durch den Anwendungsfall spezifiziert. Im Rahmen dieser Diplomarbeit kommen zwei Arten von Strängen zum Einsatz: globale (GlobalNodetrack) und lokale Stränge (LocalNodetrack). Diese sowie der im Kontext von globalen Strängen verwendete Begriff Sprung werden nachfolgend kurz definiert:

Definition 1 (Globaler und lokaler Strang, Repräsentant)

1. Ein globaler Strang repräsentiert die Evolution und somit die Historie eines einzelnen Modellelementes, indem er korrespondierende Elemente in verschiedenen Versionen verbindet. Er beinhaltet maximal ein Model- lelement je Version, und ein Modellelement wiederum kann höchstens in einem globalen Strang eines bestimmten Kriteriums enthalten sein. Ein solches Modellelement wird als Repräsentant bezeichnet, da es so- wohl die Version in diesem Strang als auch den Strang in dieser Version

3.2 Anwendungsfälle

repräsentiert. Erstreckt sich ein globaler Strang über eine Versionshistorie bestehend aus mehreren Entwicklungszweigen und enthält er Repräsentanten aus mindestens zwei dieser Entwicklungszweige, stellt er in der bildlichen Anschauung einen Baum dar.

2. Der lokale Strang setzt sich aus einer Menge von Modellelementen aus- schließlich eines Modells zusammen². Dies führt dazu, dass sich ein lo- kaler Strang im Gegensatz zu dem globalen nur innerhalb einer Version erstreckt.

Definition 2 (Sprung) Unter einem Sprung wird die Anzahl aufeinander folgender Versionen verstanden, die keinen Repräsentanten in einem gege- benen globalen Strang besitzen. Sprünge bilden Versionslücken innerhalb eines globalen Stranges und werden von Versionen mit Repräsentant begrenzt. Sie entstehen, wenn zu einem Modellelement in der Nachfolgeversion keine Korre- spondenz ermittelt werden konnte, sondern dies erst in einer späteren Revision erfolgt.

HistorySummary Anwendungsfallspezifisch berechnete Ergebnisse zu einer Histo- rie werden durch eine Instanz der Klasse HistorySummary gesammelt und verwaltet. Hierunter fallen neben den ermittelten Strängen noch zusätzlich zu Analysezwecken benötigte Informationen. Insbesondere kennt ein Objekt dieser Klasse den baumartigen Aufbau ihrer Historie, eine Instanz vom Typ VersionsTree.

VersionsTree Eine Versionshistorie wird intern durch die Klasse VersionsTree ab- gebildet, welche eine Baumstruktur implementiert. Ein jeder Knoten bzw. ein jedes Blatt repräsentiert eine geladene und in die Analyse eingehende Version. Die Wurzel des Versionenbaumes enthält als Ursprung der Historie die initiale Version, das Basisdokument (engl. basic document ). Beim Laden einer Versi- on wird diese gemäß ihrer Versionsnummer in dem Baum platziert. Neben der Versionsnummer speichert jeder Knoten und jedes Blatt für einzelne Anwen- dungsfälle benötigte Informationen ab. Ferner kennt jede Version im Versio- nenbaum ihren Pfad. Hierzu wird eine geordnete Liste der Vorgängerversionen angelegt.

In dieser Arbeit wird davon ausgegangen, dass eine Version höchstens ei- ne Vorgängerversion hat. Diese Betrachtung stützt sich auf die technische Realisierung bei den gängigen Konfigurationsmanagementsystemen wie CVS oder Subversion.

[...]

---

¹ Im Verlauf dieser Diplomarbeit wird der Begriff ”Entwicklungszweig” synonym für den Hauptzweig und die Nebenzweige der Entwicklung verwendet. Insbesondere erfolgt keine be- griffliche Unterscheidung zwischen branch und trunk, wie dies bei gängigen Konfigurationsma nagementsystemen der Fall ist.

¹ In der Literatur werden Abhängigkeiten zwischen Software-Elementen als logical coupling bezeichnet und bilden den größten Teil der Untersuchungen zum Thema Software-Historien.

² ROSE versteht sich als Akronym für Reengineering of Software Evolution; es bestehen keine Verbindungen zu Rationalr Anwendungen

³ http://www.eclipse.org/

⁴ http://subversion.tigris.org/

⁵ Parallelen zu der Zielsetzung in dieser Arbeit finden sich in Punkt 4.

¹ Dies war ausschlaggebend dafür, SWT für die benötigten Dialoge innerhalb des Prototypen zu verwenden.

² Formal betrachtet handelt es sich hierbei um eine unsortierte Menge ohne eine sequentielle Abhängigkeit zwischen den Elementen, was den Begriff ”Strang” als unpassend erscheinen lässt. Nichtsdestotrotz erleichtert diese bildliche Anschauung das Verständnis, was als Rechtfertigung für die Namensgebung ausreichen soll.