Integration von Versionsverwaltungssystemen in die kooperative

Integration von Versionsverwaltungssystemen in die kooperative
FernUniversit¨
at in Hagen
Fakult¨at fu
¨r Mathematik und Informatik
Integration von Versionsverwaltungssystemen
in die kooperative Programmierumgebung
XPairtise
als Bachelorarbeit vorgelegt von
Timo Kanera
Iltisweg 5
53842 Troisdorf
(Matrikel-Nr. 6414303)
angefertigt am
Lehrgebiet Praktische Informatik VI
- Kooperative Systeme der FernUniversit¨at in Hagen
Betreut durch
Dr. Till Schu
¨mmer
Juli 2008
Zusammenfassung
Mit XPairtise entstand an der FernUniversit¨at in Hagen ein Plug-in f¨
ur die Entwicklungsumgebung Eclipse, das es r¨aumlich entfernten Entwicklern erlaubt, kooperative
Softwareentwicklung nach dem Prinzip des Distributed Pair Programming durchzuf¨
uhren. Eines der Kernprobleme, die es dabei zu l¨osen gilt, ist die Synchronisation
der ben¨otigten Projektdaten zwischen den beteiligten Entwicklern. Bisher mussten
hierf¨
ur grunds¨atzlich komplette Projektinhalte auf den zentralen XPairtise-Server
u
bertragen
werden, was schnell einen Performance-Engpass darstellen konnte.
¨
Im Zuge dieser Arbeit wird die Konzeption und Implementierung einer Erweiterung
beschrieben, die es XPairtise erm¨oglicht, die Dienste der weit verbreiteten Versionsverwaltungssysteme CVS und Subversion verwenden zu k¨onnen, um das f¨
ur die
Synchronisation anfallende Datenaufkommen zwischen dem XPairtise-Server und
den Teilnehmern einer Pair-Programming-Sitzung zu minimieren. Zus¨atzlich wurde
die F¨ahigkeit hinzugef¨
ugt, in einer einzelnen Sitzung mehrere Projekte verwenden
zu k¨onnen.
iii
Inhaltsverzeichnis
Inhaltsverzeichnis
1 Einleitung
1.1 Aufbau dieser Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . .
2 Grundlagen
2.1 Pair Programming . . . . . . . . . .
2.1.1 Distributed Pair Programming
2.2 Eclipse . . . . . . . . . . . . . . . . .
2.3 Das Eclipse-Plug-in XPairtise . . . .
2.3.1 Die XPairtise-Architektur . .
2.4 Versionsverwaltungssysteme . . . . .
2.4.1 CVS . . . . . . . . . . . . . .
2.4.2 Subversion . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
1
3
. 3
. 4
. 6
. 7
. 8
. 10
. 12
. 13
3 Anforderungsanalyse
15
3.1 Ein Beispielszenario . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2 Betrachtung des Beispielszenarios . . . . . . . . . . . . . . . . . . . 18
3.3 Anforderungskatalog . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4 Stand der Technik
4.1 Status Quo - Synchronisation von Ressourcen in XPairtise
4.2 Verwandte Anwendungen . . . . . . . . . . . . . . . . . . .
4.2.1 XecliP . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.2 Saros . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.3 NetBeans Developer Collaboration . . . . . . . . .
4.3 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . .
5 L¨
osungskonzept
5.1 Erweiterung der bestehenden Architektur . . .
5.2 Integration von Versionsverwaltungssystemen
5.2.1 Die Eclipse Team API . . . . . . . . .
5.2.2 Wahl des Integrationsansatzes . . . . .
5.2.3 Wahl des Subversion-Plug-ins . . . . .
5.3 Umsetzung der Anforderungen . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
23
23
24
24
27
29
31
.
.
.
.
.
.
33
33
35
35
36
39
39
6 Details der Umsetzung
47
¨
6.1 Ubersicht u
¨ber die Implementierung . . . . . . . . . . . . . . . . . . 47
6.1.1 Paket de.fuh.xpairtise.common.network . . . . . . . . . . . . 47
v
Inhaltsverzeichnis
6.2
6.3
6.1.2 Paket de.fuh.xpairtise.common.replication.elements .
6.1.3 Paket de.fuh.xpairtise.common.util . . . . . . . . . .
6.1.4 Paket de.fuh.xpairtise.plugin.core . . . . . . . . . . .
6.1.5 Paket de.fuh.xpairtise.plugin.core.resources . . . . . .
6.1.6 Paket de.fuh.xpairtise.plugin.core.resources.vc . . . .
6.1.7 Paket de.fuh.xpairtise.plugin.core.resources.util . . .
6.1.8 Paket de.fuh.xpairtise.plugin.ui.xpviews.sessiongallery
6.1.9 Paket de.fuh.xpairtise.plugin.ui.util . . . . . . . . . .
6.1.10 Paket de.fuh.xpairtise.server . . . . . . . . . . . . . .
6.1.11 Paket de.fuh.xpairtise.server.xml . . . . . . . . . . .
Subversion-Integration durch separates Plug-in . . . . . . . .
Interaktion der Komponenten . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
48
49
50
50
52
53
55
56
57
58
59
60
7 Fazit
63
7.1 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
7.2 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Literaturverzeichnis
65
A CD-Beilage
67
B Eidesstattliche Erkl¨
arung
69
vi
Abbildungsverzeichnis
Abbildungsverzeichnis
2.1
2.2
2.3
Die XPairtise-Perspektive . . . . . . . . . . . . . . . . . . . . . . . 8
Die XPairtise-Netzwerk-Architektur . . . . . . . . . . . . . . . . . . 9
Revisionsverlauf eines SVN-Projektes . . . . . . . . . . . . . . . . . 14
4.1
4.2
4.3
4.4
4.5
4.6
Die XecliP-Perspektive . . . . . . . . . . . . . . . . . . . . . .
Der XecliP-Playback-View . . . . . . . . . . . . . . . . . . . .
Die Saros-Netzwerk-Architektur . . . . . . . . . . . . . . . . .
Saros in Aktion . . . . . . . . . . . . . . . . . . . . . . . . . .
Die Oberfl¨ache des NetBeans-Developer-Collaboration-Moduls
Sperrung einzelner Regionen im NetBeans-Editor . . . . . . .
.
.
.
.
.
.
25
26
27
28
30
31
6.1
6.2
6.3
6.4
6.5
6.6
6.7
6.8
6.9
6.10
¨
Verteilung der Anderungen
auf die Paketstruktur von XPairtise . .
Klassendiagramm der Verwaltung von Ressourcen auf dem Client .
Commit-Dialog mit automatisch erstellter Kommentarvorlage . . .
Klassendiagramm der Integration von Versionsverwaltungssystemen
¨
Anzeige n¨otiger Anderungen
w¨ahrend der initialen Synchronisation
¨
Anderungen
an der Sitzungs¨
ubersicht . . . . . . . . . . . . . . . . .
Der u
¨berarbeitete Projektauswahldialog . . . . . . . . . . . . . . . .
Dekoration mehrerer Projekte im Package Explorer . . . . . . . . .
¨
Erkennung, Analyse und Versand einer Anderung
. . . . . . . . . .
¨
Empfang und Reproduktion einer Anderung . . . . . . . . . . . . .
48
51
52
53
54
56
56
57
60
61
.
.
.
.
.
.
.
.
.
.
.
.
vii
1 Einleitung
Die Arbeit in r¨aumlich verteilten Gruppen ist auch in der Softwareentwicklung heute
zunehmend der Normalfall. Pair Programming eignet sich in seiner herk¨ommlichen
Form nur sehr eingeschr¨ankt f¨
ur den Einsatz in solchen Gruppen, da sich die
Entwicklerpaare zwingend am selben Ort aufhalten m¨
ussen. Abhilfe k¨onnen hier
Software-L¨osungen zur Durchf¨
uhrung von Distributed Pair Programming schaffen,
die es unter Verwendung moderner Kommunikationsvebindungen auch entfernten
Teilnehmern erlauben, Pair Programming zu betreiben. An der FernUniversit¨at in
Hagen entstand mit XPairtise [XPa08] ein solches Werkzeug in Form eines Plug-ins
f¨
ur die Entwicklungsumgebung Eclipse.
Eine der grundlegenden Aufgaben dieser Werkzeuge ist die Synchronisation der
ben¨otigten Arbeitsdaten zwischen den Teilnehmern. XPairtise beruht auf einem
klassischen Client-Server-Modell. Ben¨otigte Projektdaten mussten bisher grunds¨atzlich komplett auf den zentralen XPairtise-Server u
¨bertragen und bei Bedarf von
dort zu den einzelnen Teilnehmern u
¨bertragen werden. Dieser einheitliche Ansatz
erleichterte zwar die Konzeption und Implementierung, kann sich jedoch schnell
als Flaschenhals herausstellen, wenn Projektgr¨oße und Teilnehmerzahl steigen und
nur begrenzte Bandbreite zur Verf¨
ugung steht.
Software-Projekte, die von verteilten Gruppen entwickelt werden, stehen jedoch in
aller Regel bereits unter Kontrolle eines Versionsverwaltungssystems und werden
von allen Entwicklern aus einem zentralen Repository bezogen. Es bietet sich daher
an, diese bestehende Repository-Anbindung auch in XPairtise zu verwenden, um
das zwischen den Teilnehmern einer Pair-Programming-Sitzung und dem XPairtiseServer f¨
ur die Synchronisation von Projektdaten anfallende Datenaufkommen so
weit wie m¨oglich zu minimieren. Diese Arbeit beschreibt die Konzeption und Implementierung einer solchen Erweiterung von XPairtise. Zus¨atzlich wurde die F¨ahigkeit
implementiert, in einer einzelnen Sitzung mehrere Projekte verwenden zu k¨onnen.
1.1 Aufbau dieser Arbeit
Nach dieser Einleitung gliedert sich der weitere Verlauf dieser Ausarbeitung in
sechs weitere Kapitel:
1
1. Einleitung
¨
• Kapitel 2 gibt zun¨achst einen Uberblick
u
ur diese Arbeit
¨ber einige der f¨
relevanten Themenkomplexe.
• Kapitel 3 besch¨aftigt sich mit der Herleitung und Analyse der Anforderungen,
die der endg¨
ultigen Implementierung zugrunde liegen.
• Kapitel 4 beleuchtet den Stand der Technik anhand einiger verwandter
Anwendungen. Ein Hauptaugenmerk liegt dabei auf den verschiedenen Realisierungen der Synchronisation der ben¨otigten Arbeitsdaten.
• Kapitel 5 beschreibt das gew¨ahlte L¨osungskonzept zur Umsetzung der in
Kapitel 3 herausgearbeiteten Anforderungen.
¨
• Kapitel 6 gibt einen Uberblick
u
ultige Implementierung des in
¨ber die endg¨
Kapitel 5 beschriebenen L¨osungskonzeptes.
• Kapitel 7 fasst die Ergebnisse dieser Arbeit zusammen und gibt einen Ausblick
auf m¨ogliche zuk¨
unftige Erweiterungen.
2
2 Grundlagen
In den folgenden Abschnitten werden zun¨achst die f¨
ur diese Arbeit relevanten
Themenkomplexe vorgestellt.
2.1 Pair Programming
Pair Programming ist eine Entwicklungsmethode, die besonders in agilen Vorgehensmodellen der Softwareentwicklung Verwendung findet. Vor allem durch die
Popularit¨at des Extreme Programming fand es in den vergangenen Jahren zunehmend Beachtung. Pair Programming sieht die Zusammenarbeit in Paaren von
jeweils zwei Entwicklern gemeinsam an einem Rechner vor, den sie im Wechsel
bedienen. Einer der beiden Entwickler programmiert aktiv und erl¨autert dabei
seine Gedankeng¨ange und sein Vorgehen dem anderen Teilnehmer. Diese Rolle
wird u
¨blicherweise als Driver bezeichnet.
Ihm zur Seite sitzt der Navigator, der das Vorgehen des Drivers verfolgt und
¨
seine Anderungen
kontrolliert, ihn auf erkannte Fehler hinweist und konstruktive
Vorschl¨age macht. Die Wahrscheinlichkeit, Probleme im aktuell bearbeiteten Programmausschnitt m¨oglichst fr¨
uh zu erkennen und zu beheben, wird durch diese
fortw¨ahrende Begutachtung stark erh¨oht. Dar¨
uber hinaus besitzt der Navigator eine
globalere Sichtweise auf die Problematik als der Driver, dessen Hauptaugenmerk ja
auf dem aktuellen Programmausschnitt liegt. Der Navigator kann daher auch eher
weitreichendere Gedanken zu gew¨ahlten Probleml¨osungsstrategien direkt in die
Sitzung einfließen lassen. Gest¨
utzt auf Befragungen und kontrollierte Experimente
(vgl. [Wil00]) nennen Cockburn und Williams [CW01] vielf¨altige positive Effekte,
die durch Pair Programming erzielt werden k¨onnen:
Wirtschaftlichkeit: Trotz der doppelten personellen Besetzung ergeben sich im
Schnitt lediglich um 15% gestiegene Entwicklungskosten durch die Umstellung
auf Pair Programming. Dem gegen¨
uber stehen stark sinkende Kosten f¨
ur
Fehlerbereinigung und Tests, da Pair Programming meist zu robusterem
Code f¨
uhrt.
Zufriedenheit: Arbeiten in Paaren wird unter befragten Entwicklern fast durchgehend als angenehmer und erf¨
ullender empfunden als die Einzelarbeit.
3
2. Grundlagen
Entwurfsqualit¨
at: Der kontinuierliche Gedanken- und Ideenaustausch der Teilnehmer (Pair-Think ) f¨
uhrt zu qualitativ ausgereifteren Entw¨
urfen und zu
kompakterem, hochwertigerem Code.
Kontinuierliche Pr¨
ufung: Durch die Arbeit in Paaren unterliegen Entwurf und
Umsetzung st¨andiger Kontrolle (Pair-Reviews). Probleme k¨onnen daher meist
sehr fr¨
uh erkannt und behoben werden.
Probleml¨
osung: Durch wechselseitigen, aufeinander aufbauenden Ideenaustausch
(Pair-Relaying) werden schneller L¨osungen f¨
ur komplexe Probleme gefunden.
Lernen: Die Gruppenmitglieder lernen fortw¨ahrend voneinander (Pair-Learning).
Dies bezieht sich sowohl auf generelles Fachwissen als auch auf Kenntnisse
u
¨ber das aktuelle Projekt. Regelm¨aßiger Wechsel der Paarkonstellationen
erm¨oglicht somit eine Verbreitung der n¨otigen Kenntnisse innerhalb des
Teams auf nat¨
urliche Weise.
Gruppenbildung und Kommunikation: Die Arbeit in wechselnden Paaren verbessert die F¨ahigkeit der Teammitglieder, miteinander zu diskutieren und zu
arbeiten. Informationsfluss und Teamdynamik werden gest¨arkt.
Mitarbeiter- und Projektleitung: Durch wechselnde Paare erhalten alle Teilnehmer Kenntnisse u
¨ber alle Teile der Codebasis. Ein kurzfristiger personeller
Ausfall ist dadurch durch die Teamleitung wesentlich einfacher zu kompensieren.
2.1.1 Distributed Pair Programming
Mit der st¨andig steigenden Verf¨
ugbarkeit und Verbreitung von breitbandigen
Kommunikationsverbindungen wird die M¨oglichkeit der Arbeit in r¨aumlich verteilten Gruppen zunehmend attraktiver. Dies betrifft auch die Softwareentwicklung.
Zahlreiche große Software-Projekte werden seit langem erfolgreich von weltweit
verteilten Teams entwickelt. Eines der besten Beispiele stellt die Open-SourceBewegung dar.
Pair Programming eignet sich in seiner urspr¨
unglichen Form offensichtlich kaum
f¨
ur den Einsatz in solchen verteilten Teams, da die Paare sich w¨ahrend der Arbeit
zwingend am selben Ort befinden m¨
ussen. Diese Einschr¨ankung nennt auch Maurer
[Mau02] als einen großen Nachteil des Extreme Programming in seiner Originalform.
Als zweites Problem sieht er wegen der fast vollst¨andigen Ersetzung klassischer
Projektdokumentation durch direkte Kommunikation eine mangelnde Skalierbarkeit
des Verfahrens f¨
ur die Verwendung in großen Entwicklerteams.
Das Konzept des Distributed Pair Programming (DPP ) stellt die Bem¨
uhung dar,
diesen Einschr¨ankungen entgegenzuwirken. Ziel ist es, auch r¨aumlich verteilten
4
2.1 Pair Programming
Entwicklern unter Verwendung moderner Kommunikationsverbindungen die M¨oglichkeit zu geben, Pair Programming zu betreiben. Stotts et al. [SWN03] fassen
die wichtigsten Vorteile von Distributed Pair Programming zusammen:
• Distributed Pair Programming bietet eine stark erh¨ohte Orts- und Zeitflexibilit¨at. Es ist kein Ortswechsel der Teilnehmer n¨otig, Sitzungen k¨onnen ohne
lange Planung und Anreise sehr spontan durchgef¨
uhrt werden. Die st¨andig
wachsende Verbreitung mobiler Informations- und Kommunikationssysteme
erm¨oglicht außerdem Sitzungen mit mobilen Teilnehmern.
• Die Tatsache, dass alle Teilnehmer u
ugen,
¨ber einen eigenen Bildschirm verf¨
¨
f¨
uhrt zu einer stark verbesserten Ubersichtlichkeit.
• Der Navigator kann seinen Rechner w¨ahrend der laufenden Sitzung f¨
ur
weitere unterst¨
utzende T¨atigkeiten, z.B. die Informationssuche im Internet
verwenden.
• Die Teilnehmer sind gezwungen, digitale Versionen von Ideen und Entw¨
urfen
zu erstellen, die sie in einer herk¨ommlichen Pair-Programming-Sitzung auf
Papier oder einem Whiteboard erstellen w¨
urden. Auf diese Weise entstandene
Inhalte k¨onnen sp¨ater f¨
ur Dokumentationszwecke innerhalb des Teams genutzt
werden.
• Die Teilnehmer neigen weniger zu Abschweifungen in private Konversationen
und bleiben durchgehend auf die Aufgabe fokussiert, da jegliche Kommunikation u
¨ber den Computer abl¨auft.
F¨
ur die Durchf¨
uhrung von Distributed Pair Programming werden Software-Werkzeuge ben¨otigt, die es den Teilnehmern erm¨oglicht, direkt miteinander zu kommunizieren und gemeinsam an einer Datenbasis zu arbeiten.
Hierf¨
ur bietet sich einerseits eine Kombination bestehender Entwicklungs- und
Kommunikationswerkzeuge mit Remote-Desktop-Systemen wie VNC [RSFWH98]
an, die eine Fernsteuerung des lokalen Rechners durch einen oder mehrere entfernte
Teilnehmer erlauben. Dieses Modell zeichnet sich vor allem durch seine hohe Flexibilit¨at aus, da die Teilnehmer v¨ollig frei in der Wahl der in einer Sitzung verwendeten
Programme sind. Da jegliche Aktionen direkt auf dem Host ausgef¨
uhrt werden,
entf¨allt außerdem das Problem des Abgleichs der ben¨otigten Arbeitsdaten zwischen
den Teilnehmern. Dem gegen¨
uber steht meist ein hohes Datenaufkommen durch
¨
die st¨andige Ubertragung des gesamten Bildschirminhaltes des Hosts zu den Teilnehmern, was die problemlose Verwendbarkeit u
¨ber Kommunikationsverbindungen
mit geringer Bandbreite stark einschr¨anken kann.
Stotts et al. [SWN03] evaluierten diesen Ansatz im Zuge zweier Feldversuche
und kommen zu durchaus positiven Ergebnissen. Sie berichten jedoch auch von
zahlreichen kleineren Problemen mit einigen der verwendeten Werkzeuge. Hinzu
5
2. Grundlagen
kommen erh¨ohte Komplexit¨at und Lernaufwand durch die Vielzahl der ben¨otigten
Programme.
Die Alternative bilden speziell f¨
ur die Durchf¨
uhrung von Distributed Pair Programming ausgelegte Werkzeuge, die die f¨
ur eine m¨oglichst komplette Abbildung
des herk¨ommlichen Pair-Programming-Szenarios auf eine verteilte Umgebung w¨
unschenswerten Funktionen direkt unterst¨
utzen. Hierzu geh¨oren neben dem Abgleich
der ben¨otigten Arbeitsdaten und Editor-Inhalten zwischen den Teilnehmern u
¨blicherweise auch integrierte Kommunikationsm¨oglichkeiten sowie die Bereitstellung
eines entsprechenden Rollen- und Sitzungsmodells. Die Auswahl an entsprechenden Werkzeugen ist jedoch heute noch gering. Mit XPairtise (vgl. Abschnitt 2.3)
entstand ein weiteres, das die Grundlage f¨
ur diese Arbeit darstellt.
2.2 Eclipse
Eclipse [ECL08] ist ein Open-Source-Projekt zur Entwicklung einer erweiterbaren
Plattform und eines Frameworks zur Entwicklung von Software jeglicher Art.
Eclipse geht urspr¨
unglich aus der Entwicklungssoftware IBM Visual Age for Java
hervor, deren Quellcode im November 2001 freigegeben wurde. Geleitet wird
das Projekt heute durch die Eclipse Foundation, eine rechtlich eigenst¨andige
gemeinn¨
utzige Genossenschaft, die 2004 durch das durch IBM gef¨
uhrte EclipseKonsortium gegr¨
undet wurde.
Beginnend mit der Version 3.0 erfuhr die Eclipse-Architektur einige grundlegende
¨
Anderungen.
Urspr¨
unglich als vollst¨andige erweiterbare Entwicklungsumgebung
konzipiert, stellt Eclipse seither nur noch den schlanken Kern der Plattform dar.
Jegliche Funktionalit¨at wird durch einzelne Plug-ins bereitgestellt, die durch diesen
Kern hinzugeladen werden. Diese Architektur wird als Eclipse Rich Client Platform
(RCP ) bezeichnet. Sie basiert auf Equinox, einer ebenfalls durch das EclipseProjekt erstellten Implementierung der OSGi-Spezifikation [OSG08]. Dank der Rich
Client Platform eignet sich Eclipse als Grundlage f¨
ur den Aufbau verschiedenster
Werkzeuge.
Auch wenn Eclipse und alle verf¨
ugbaren Plug-ins komplett in Java entwickelt
wurden, m¨
ussen sich auf Eclipse basierende Projekte jedoch nicht auf Java beschr¨anken. So existieren beispielsweise entsprechende Plug-ins, um Eclipse als
Entwicklungsumgebung f¨
ur C/C++ zu nutzen. Die bekannteste Verwendung von
Eclipse ist jedoch nach wie vor die Nutzung als Entwicklungsumgebung f¨
ur Java.
Zu diesem Zweck wird in Form des Eclipse SDK (Software Development Kit) eine
Kombination der Eclipse-Kernplattform mit Werkzeugen f¨
ur die Java-Entwicklung
und die Entwicklung eigener Eclipse-Plug-ins angeboten.
6
2.3 Das Eclipse-Plug-in XPairtise
Die grafische Oberfl¨ache der Eclipse-Komponenten basiert auf dem GUI-Framework
SWT (Standard Widget Toolkit), welches ebenfalls im Rahmen des Eclipse-Projektes
entwickelt wird. SWT bedient sich zur Darstellung seiner Elemente der nativen GUIKomponenten des jeweiligen Betriebssystems, vergleichbar mit dem SUN AWT.
Dies erm¨oglicht ein natives Erscheinungsbild der Applikationen auf verschiedenen
Plattformen und potentielle Geschwindigkeitsvorteile, auf Kosten einer maximalen
Plattformunabh¨angigkeit. Zum Zeitpunkt der Erstellung dieser Arbeit existierten
SWT-Implementierungen f¨
ur Windows, UNIX (GTK 2 und Motif), Mac OS X, sowie
QNX. Die Eclipse-Oberfl¨ache setzt sich aus drei Grundelementen zusammen:
Editoren: Editoren sind Fenster zur Anzeige und Bearbeitung von Inhalten. Der
u
¨bliche Fall sind Text-Editoren zur Bearbeitung von Quelltext in unterschiedlichen Programmiersprachen, wobei es f¨
ur die verschiedenen unterst¨
utzten
Sprachen meist eigene Editor-Varianten gibt. Dar¨
uber hinaus existieren jedoch auch speziellere Editoren, beispielsweise zur visuellen Erstellung von
grafischen Benutzeroberfl¨achen.
Sichten: Bei Sichten (Views) handelt es sich um Fenster zur geordneten oder
gruppierten Anzeige von Informationen und zur Navigation in diesen Informationen. Bekannte Beispiele sind der Package Explorer zur Anzeige
von Dateisystem-Elementen in einer baumartigen Struktur oder Sichten zur
Anzeige von Detailinformationen zu Elementen, die momentan in Editoren ge¨offnet sind. Einzelne Sichten lassen sich sehr flexibel innerhalb der
Eclipse-Oberfl¨ache platzieren.
Perspektiven: Perspektiven definieren Zusammenstellungen und Anordnungen
von Sichten und Editoren innerhalb der Eclipse-Oberfl¨ache. Plug-ins definieren
u
ur sie relevanten Sichten
¨blicherweise eigene Perspektiven, die nur die f¨
enthalten. Diese vorkonfigurierten Perspektiven k¨onnen dann durch den
Benutzer flexibel an die eigenen Bed¨
urfnisse angepasst werden.
2.3 Das Eclipse-Plug-in XPairtise
XPairtise [XPa08] ist ein Eclipse-Plug-in, welches Distributed Pair Programming
auf Eclipse-Basis erm¨oglicht. Entwickelt wurde es im Wintersemester 2006/2007
im Zuge des Fachpraktikums CSCW (Computer Supported Cooperative Work ) im
Lehrgebiet Kooperative Systeme der FernUniversit¨at in Hagen. Zu den gebotenen
F¨ahigkeiten z¨ahlen die Unterst¨
utzung von Benutzerrollen und Benutzergruppen,
schneller Rollenwechsel zwischen Driver und Navigator, eine u
¨bersichtliche Verwaltung von Programmiersitzungen, ein verteilter Editor, der weitgehend unabh¨angig
von der verwendeten Programmiersprache arbeitet, die automatische Synchronisation der ben¨otigten Projektressourcen zwischen den Teilnehmern, eine Chat-Funktion
7
2. Grundlagen
zur direkten Kommunikation zwischen den Teilnehmern sowie ein verteiltes Whiteboard zur gemeinsamen Anfertigung von Entw¨
urfen und Skizzen.
Abbildung 2.1 zeigt die Oberfl¨ache der Eclipse IDE mit den verschiedenen von
XPairtise beigesteuerten Sichten. Zu sehen sind der Editor (gr¨
un umrahmt), das
verteilte Whiteboard (rot umrahmt), die Sitzungs¨
ubersicht (blau umrahmt), die
Benutzer¨
ubersicht (gelb umrahmt), die Chat-Ansicht (lila umrahmt) sowie Kontrollfl¨achen und Anzeigen f¨
ur Verbindungsstatus und Rollenzuweisung (orange
umrahmt).
Abbildung 2.1: Die XPairtise-Perspektive
2.3.1 Die XPairtise-Architektur
XPairtise basiert auf einer klassischen Client-Server-Architektur. Jegliche Kommunikation zwischen Teilnehmern erfolgt u
¨ber den zentralen XPairtise-Server. Als
grundlegender Transportmechanismus wurde der Java Message Service (JMS )
[JMS08], eine von SUN Microsystems entwickelte nachrichtenbasierte Middleware,
gew¨ahlt. JMS deckt viele der von XPairtise ben¨otigten Modelle des Nachrichtenaustausches (beispielsweise asynchrone 1:n Verteilung von Nachrichten) bereits ab.
Da es sich bei JMS lediglich um eine Spezifikation handelt, musste eine konkrete
8
2.3 Das Eclipse-Plug-in XPairtise
Implementierung gew¨ahlt werden. Die Wahl fiel auf das von der Apache Foundation
entwickelte Open-Source-Projekt ActiveMQ (AMQ) [AMQ08].
Die zentrale Komponente von JMS stellt der Nachrichten-Vermittler (Message
Broker ) dar, der f¨
ur die Verteilung der Nachrichten zwischen den einzelnen JMSClients zust¨andig ist. Der XPairtise-Server fungiert in diesem Modell lediglich als
weiterer JMS-Client, der u
¨ber den Broker Nachrichten von Clients empf¨angt (siehe
Abbildung 2.2).
XPairtise−
Client
(Plug−in)
publish
queue
publish
XPairtise−
Server
queue
queue
publish
AMQ−
Broker
queue
queue
XPairtise−
Client
(Plug−in)
publish
queue
XPairtise−
Client
(Plug−in)
Abbildung 2.2: Die XPairtise-Netzwerk-Architektur
Das grundlegende Applikationsmodell von XPairtise stellen replizierte Objekte
dar. Jegliche Inhalte, die zwischen den Teilnehmern ausgetauscht werden, werden
auf entsprechende replizierte Objekte (auch als replizierte Elemente bezeichnet)
abgebildet. Entsprechende Objekttypen repr¨asentieren beispielsweise Benutzerinformationen, Chat-Nachrichten, oder Editor-Kommandos. Diese replizierten
Objekte werden auf dem Server in Listen (replicated lists) organisiert und in
serialisierter Form mit Hilfe von JMS-Objektnachrichten zu den Clients transportiert.
JMS definiert zwei unterschiedliche Modelle des Nachrichtenversands, die beide
von XPairtise genutzt werden:
• Nachrichtenwarteschlangen (message queues) erlauben den gezielten Versand
von Nachrichten an einen festen Empf¨anger, der auf Nachrichten aus der
Warteschlange wartet (n:1-Versand).
9
2. Grundlagen
• Das Anmelde-Versendesystem (publish-subscribe) erlaubt den Versand von
Nachrichten zu einem bestimmten Thema (message topic) an eine Gruppe
von Empf¨angern, die dieses Thema abonniert haben (n:m-Versand).
Nach dem Start meldet der XPairtise-Server zun¨achst eine Warteschlange am
Broker an, die f¨
ur eingehende Nachrichten der Clients genutzt wird. In die Gegenrichtung kann der Server eingehende Nachrichten entweder direkt beantworten
oder separate Nachrichten an einzelne Clients schicken. F¨
ur diesen Zweck wird
eine weitere Warteschlange f¨
ur jeden Client angelegt, die zum Beispiel f¨
ur die
¨
initiale Ubertragung des bisherigen Inhaltes der replizierten Listen nach dem
Verbindungsaufbau genutzt wird. Zur Identifizierung der Teilnehmer durch den
Server wird jedem Client bei der Anmeldung ein eindeutiger Identifikator (session
token) zugeteilt, der dann zur Markierung von Nachrichten an den Server genutzt
wird.
Neben den gezielten Warteschlangen werden durch den Server im Laufe einer
Sitzung außerdem mehrere Topics f¨
ur den Gruppenversand der Updates der verschiedenen replizierten Listen angelegt. In der aktuellen Implementierung schickt
nur der Server selbst Nachrichten an diese Topics. Von Clients stammende Nachrichten nehmen grunds¨atzlich erst den Weg u
¨ber den Server, der die anfallenden
Aktualisierungen in den replizierten Listen vornimmt und repliziert.
2.4 Versionsverwaltungssysteme
Versionsverwaltungssysteme (auch Versionskontrollsysteme) stellen eines der wichtigsten Werkzeuge in der Entwicklung komplexer Software dar. Sie dienen zur
zentralen Verwaltung des Datenbestandes eines Projektes und kontrollieren den
¨
gemeinsamen Zugriff der Entwickler darauf. Alle Anderungen,
die im Laufe des
Entwicklungszyklus am Quelltext des Projektes anfallen, werden erfasst und als
neuer Versionsstand in das Archiv (Repository) aufgenommen. Zusammengefasst
¨
ergeben diese Versionsst¨ande eine Historie u
¨ber den gesamten Anderungsverlauf
¨
des Projektes. Entwickler k¨onnen den Anderungsverlauf
einzelner Dateien nachvollziehen, gezielt auf ¨altere Zwischenst¨ande zur¨
uckgreifen und bei Bedarf fehlerhafte
¨
Anderungen zur¨
ucknehmen.
Die Vielzahl der heute verf¨
ugbaren Versionsverwaltungssysteme unterscheidet sich
in ihrem Funktionsumfang und in den Details der Umsetzung der angebotenen
Funktionen teils recht stark. Die grundlegenden Arbeitsschritte im Umgang mit
den Systemen sind jedoch immer weitgehend die selben (vgl. auch [Bae05]):
10
2.4 Versionsverwaltungssysteme
Import: Um ein Projekt unter die Kontrolle eines Versionsverwaltungssystems zu
stellen, muss es zun¨achst durch einen Import dem Repository hinzugef¨
ugt
werden.
Checkout: Als Checkout wird der Bezug einer lokalen Arbeitskopie des verwendeten Projektes aus dem Repository bezeichnet. Dies ist der grundlegende
Schritt, um mit einem unter Versionskontrolle stehenden Projekt zu arbeiten.
Im Normalfall wird hierdurch die aktuellste Version der Projektdaten bezogen, durch Angabe eines entsprechenden Identifikators (Revisionsnummer
oder Datum) k¨onnen jedoch meist auch gezielt ¨altere Entwicklungsst¨ande
bezogen werden.
¨
Commit: An der lokalen Arbeitskopie des Projektes vorgenommene Anderungen
k¨onnen mittels eines Commits (auch Checkin) an das Versionsverwaltungssys¨
tem u
wird hierbei auch die Angabe eines die
¨bergeben werden. Ublicherweise
¨
Anderungen
beschreibenden Kommentars angeboten, der sp¨ater zusammen
¨
mit Zeitstempel und Benutzerkennung in der Historie des Anderungsverlaufs
mit angezeigt wird.
Add/Remove: Neue Dateien, die dem Versionsverwaltungssystem bisher nicht
bekannt sind, k¨onnen mittels Add nachtr¨aglich dem Repository hinzugef¨
ugt
werden. Entsprechend lassen sich mittels Remove Dateien aus dem Repository
entfernen (ohne jedoch ihre bisherige Historie zu verlieren).
Update: Ist die lokale Projektkopie auf einem ¨alteren Stand als die Projektdaten
im Repository, so l¨asst sie sich mit Hilfe eines Updates auf den aktuellen
Stand bringen.
Neben diesen grundlegenden Schritten sind zwei weitere Eigenschaften zu nennen,
die von nahezu allen aktuellen Versionsverwaltungssystemen unterst¨
utzt werden:
Branches: Branches (Zweige) erlauben die Pflege verschiedener Entwicklungszweige eines einzelnen Projektes. Nach Erstellung eines neuen Zweiges lassen
¨
sich Anderungen
gezielt in diesen Zweig u
¨bernehmen, ohne den Hauptzweig
(Trunk ) zu beeinflussen. Komplette Zweige lassen sich sp¨ater wieder zusam¨
menf¨
uhren oder einzelne Anderungen
eines Zweiges selektiv in einen anderen
u
¨bernehmen (Merge).
Tags: Tags erlauben die Markierung eines projektweiten Zwischenstandes, beispielsweise um eine fertige Version zu definieren. Hierf¨
ur wird dieser Stand
mit einem symbolischen Namen versehen, u
¨ber den sp¨ater jederzeit darauf
zur¨
uckgegriffen werden kann.
Arbeiten mehrere Entwickler an einem Projekt, so ist es Aufgabe des Versionsverwaltungssystems, den gemeinsamen Zugriff aller Benutzer auf die gemeinsame
Datenbasis zu koordinieren. Ziel ist hierbei einerseits, allen Teilnehmern zu erm¨oglichen, m¨oglichst ohne Einschr¨ankungen an beliebigen Teilen des Quelltextes
11
2. Grundlagen
arbeiten zu k¨onnen, andererseits jedoch Konflikte zu vermeiden, die bei gemeinsamer Bearbeitung sich u
¨berschneidender Bereiche durch mehrere Benutzer entstehen
k¨onnen.
Solche Konflikte lassen sich am einfachsten durch eine pessimistische Nebenl¨aufigkeitskontrolle vermeiden, die die Bearbeitung einer Datei zu jedem Zeitpunkt
jeweils nur durch einen Benutzer erlaubt. Dieses Modell liegt einigen ¨alteren Versionsverwaltungssystemen zugrunde, ist allerdings sehr restriktiv und widerspricht
dem Ziel der m¨oglichst uneingeschr¨ankten Nutzung. Moderne Versionsverwaltungssysteme erlauben daher meist die gleichzeitige Bearbeitung einer Datei durch
mehrere Benutzer und l¨osen entstehende Konflikte, so weit m¨oglich, zum CommitZeitpunkt selbst auf oder fordern eine manuelle Aufl¨osung der Konflikte durch den
Entwickler.
Zu den heute am h¨aufigsten verwendeten und auch im Eclipse-Umfeld am besten
unterst¨
utzten Versionsverwaltungssystemen geh¨oren CVS und das daran angelehnte
j¨
ungere Subversion. Auf diesen beiden Systemen lag daher auch das Hauptaugenmerk der in dieser Arbeit vorgestellten Implementierung. Im Folgenden werden
diese beiden Systeme kurz n¨aher vorgestellt.
2.4.1 CVS
Eines der bekanntesten Versionsverwaltungssysteme ist das Concurrent Versions
System (CVS ) [CVS08]. Es entstand urspr¨
unglich im Jahr 1986 in Form einiger
UNIX-Skripte als Front End f¨
ur das Versionsverwaltungssystem RCS. Ziel war es,
RCS um die M¨oglichkeit der Verwaltung mehrerer Dateien gleichzeitig und die
Verwendbarkeit durch mehrere Benutzer gleichzeitig zu erweitern. 1989 wurde diese
Skriptsammlung dann mit erweiterter Funktionalit¨at in die Programmiersprache
C portiert und wird bis heute gepflegt. Zur Datenhaltung wird weiterhin das von
RCS verwendete Format genutzt.
CVS verwendet eine Client-Server-Architektur mit einem zentralen Repository.
CVS-Client-Programme sind heute f¨
ur alle g¨angigen Betriebssysteme verf¨
ugbar.
So existieren neben dem urspr¨
unglichen Kommandozeilen-Programm inzwischen
vielf¨altige grafische Oberfl¨achen sowie eingebettete CVS-Unterst¨
utzung in verschiedenen Entwicklungsumgebungen. Auch die Eclipse IDE verf¨
ugt standardm¨aßig
bereits u
¨ber ein CVS-Plug-in.
Alle im letzten Abschnitt beschriebenen grundlegenden Arbeitsschritte werden von
CVS unterst¨
utzt. Insbesondere war es das erste Versionsverwaltungssystem, welches
das Branch-Konzept implementierte. Leider werden Commits durch CVS nicht
als atomare Transaktionen gehandhabt. Dies kann zu inkonsistenten Zust¨anden
12
2.4 Versionsverwaltungssysteme
der Projektdaten im Repository f¨
uhren, wenn ein Commit fr¨
uhzeitig unterbrochen
wird. CVS unterst¨
utzt zwar auch eine pessimistische Nebenl¨aufigkeitskontrolle
durch einen entsprechenden Sperr-Mechanismus, weitaus u
¨blicher ist jedoch die
Verwendung der optimistischen Nebenl¨aufigkeitskontrolle. Hier werden konkurrie¨
rende Anderungen
der selben Datei durch mehrere Benutzer zugelassen, eventuell
auftretende Konflikte m¨
ussen dabei manuell aufgel¨ost werden.
CVS verwendet eine unabh¨angige Versionierung jedes einzelnen Objektes, nicht
des gesamten Projektes. Versioniert werden dar¨
uber hinaus nur Dateien, keine
Verzeichnisse. Dies hat zur Folge, dass eine konsistente M¨oglichkeit fehlt, eine exakte
Version des Gesamtprojekts zu einem beliebigen Zeitpunkt zu beschreiben. Statt
dessen muss mit expliziten Versionstags oder tempor¨aren Daten-Tags gearbeitet
werden, um auf einen projekt¨
ubergreifenden Zwischenstand zur¨
uckzugreifen.
2.4.2 Subversion
Das seit dem Jahr 2000 entwickelte Open-Source-Projekt Subversion (SVN )
¨
[SVN08] wurde mit dem Hauptziel konzipiert, bei gr¨oßtm¨oglicher Ahnlichkeit
zu CVS dessen Schw¨achen zu u
¨berwinden. Dem entsprechend bietet es weitgehend
mit CVS vergleichbare Benutzung. Ge¨anderte Konzepte wurden nur an den Stellen
eingef¨
uhrt, wo es n¨otig war oder sinnvoll erschien (vgl. auch [WG05]). Vergleichbar
mit CVS gibt es auch f¨
ur Subversion Client-Applikationen f¨
ur alle g¨angigen Plattformen. Der Standard-Client ist auch hier ein einfaches Kommandozeilen-Programm,
¨
dessen Bedienung stark an das CVS-Aquivalent
angelehnt ist. Die Eclipse IDE
bietet standardm¨aßig keine Unterst¨
utzung f¨
ur die Verwendung von Subversion,
jedoch existieren mit Subclipse [SCL08] und Subversive [SVE08] zwei optionale
Plug-ins, die diese Aufgabe u
¨bernehmen (siehe Abschnitt 5.2.3).
¨
Die wohl wichtigsten Anderungen
liegen im Bereich der Versionierung. Die Versionierung in Subversion bezieht sich jeweils auf den ganzen Satz der ge¨anderten
Objekte, wobei nicht nur Dateien, sondern auch Verzeichnisse versioniert sind. Der
¨
durch eine Anderung
entstandene neue Zwischenstand eines Projektes ist dadurch
eindeutig durch eine u
¨bergreifende Revisionsnummer identifiziert. Abbildung 2.3
zeigt diesen Sachverhalt an einem Beispiel. Die Revisionsnummer einer jeden Datei
entspricht der Revisionsnummer des Commits, bei dem sie zum letzten mal ge¨andert wurde. Die Revisionsnummer eines Verzeichnisses entspricht der h¨ochsten
Revisionsnummer aller Inhalte des Verzeichnisses.
Im Gegensatz zu CVS unterst¨
utzt Subversion explizit die Verwaltung von Kopien. Kopien werden nicht wie komplett neue Inhalte gehandhabt und behalten
somit auch die bisherige Historie des Originals. Solang sie nicht ver¨andert werden,
werden diese Kopien intern als leichtgewichtige Verkn¨
upfungen auf das Original
13
2. Grundlagen
6
Branches
2
7
3
1
11
9
8
4
Merges
10
12
14
Trunk
5
Tags
13
Abbildung 2.3: Revisionsverlauf eines SVN-Projektes
implementiert. Verzichtet wurde in Subversion hingegen auf eine eigenst¨andige
Implementierung der Konzepte von Branches und Tags. Statt dessen wird hier
mit Kopien des bestehenden Zweiges gearbeitet, die je nach Verwendung als Tag
oder Branch interpretiert werden k¨onnen. So entspricht die unver¨anderte Kopie
eines Zweiges einem Tag. Werden Modifikationen an der Kopie vorgenommen, wird
daraus eine Branch.
Subversion speichert alle Dateien der lokalen Arbeitskopie in zwei Versionen. Eine
Version bleibt unver¨andert und repr¨asentiert die zuletzt aus dem Repository bezoge¨
ne Basisrevision. Lokale Anderungen
werden an der zweiten Version vorgenommen.
Dieses Konzept reduziert die Zahl der ben¨otigten Zugriffe auf das Repository auf
ein Minimum. Weder f¨
ur die Anzeige der im Vergleich zur Basisrevision vorgenom¨
menen Anderungen (Diff ), noch zur Wiederherstellung der Basisrevision (Revert)
muss das Repository konsultiert werden.
Auch beim Commit ergeben sich durch die zus¨atzliche lokale Speicherung der
Basisrevision aller Projektdaten Vorteile. Sie erm¨oglicht es, bei einem Commit nur
¨
die tats¨achlich anfallenden Anderungen
an den Server u
¨bermitteln zu k¨onnen. CVS
muss bei einem Commit grunds¨atzlich komplette Dateien auf den Server u
¨bertragen.
Dar¨
uber hinaus sind Commits in Subversion atomar. Fr¨
uhzeitig abgebrochene
Commits f¨
uhren also keinesfalls zu einem inkonsistenten Zustand der Projektdaten
im Repository.
14
3 Anforderungsanalyse
XPairtise bietet in seiner urspr¨
unglichen Form keine explizite Integration von
Versionsverwaltungssystemen. So lassen sich Projekte unter Versionskontrolle zwar
seit jeher in einer XPairtise-Sitzung verwenden, die Dienste der Versionsverwaltung
werden durch XPairtise jedoch nicht in Anspruch genommen. Dies hat zur Folge,
dass, unabh¨angig von einer bestehenden Repository-Anbindung, grunds¨atzlich alle
Projektdaten auf den XPairtise-Server u
¨bertragen und von allen Teilnehmern der
Sitzung bei Bedarf von dort bezogen werden m¨
ussen.
Um einzelne Anforderungen an die Integration von Versionsverwaltungssystemen in
XPairtise herausarbeiten zu k¨onnen, wird im Folgenden zun¨achst ein beispielhaftes
Nutzungsszenario skizziert, das die w¨
unschenswerten F¨ahigkeiten dieser Integration
aufzeigt.
3.1 Ein Beispielszenario
Im Zuge eines Fachpraktikums arbeiten die Fernstudenten Karl, Jenny, Peter
und Lisa an einigen Erweiterungen eines bekannten Plug-ins f¨
ur die Entwicklungsplattform Eclipse. Als Entwicklungsmethode wird im Laufe des Praktikums
konsequent auf Extreme Programming gesetzt. Hierf¨
ur verabreden sich die Studenten regelm¨aßig zu verteilten Pair-Programming-Sitzungen, die sie mit Hilfe des
Eclipse-Plug-ins XPairtise abhalten. Zu diesem Zweck wird ein zentraler XPairtiseServer an der Universit¨at bereitgestellt. In Anlehnung an die Eclipse-Philosophie
hat man sich fr¨
uh darauf geeinigt, die Erweiterung in Form einzelner Plug-ins
und Fragmente zu realisieren, die vom Benutzer selektiv geladen werden k¨onnen,
um das Basis-Plug-in zu erweitern. W¨ahrend der Entwicklungszeit werden diese
Komponenten in Form von einzelnen Projekten auf dem CVS-Server der Universit¨at verwaltet. Das Basis-Plug-in hingegen liegt in einem externen SubversionRepository.
Auch an diesem Nachmittag ist eine solche Sitzung angesetzt. Jenny und Peter
treffen als erste auf dem Server ein. Nach kurzer Begr¨
ußung mit Hilfe der ChatFunktion von XPairtise beschließen sie, direkt mit der Arbeit zu beginnen. Zun¨achst
sollen einige in den letzten Tagen erkannte Probleme der UI-Komponente behoben
15
3. Anforderungsanalyse
werden. Jenny schl¨agt vor, zu Beginn die Rolle des Drivers zu u
¨bernehmen, da sie
¨
bereits einen groben Uberblick u
¨ber die bestehenden Probleme hat und ihre lokale
¨
Kopie der Komponente schon einige kleine Anderungen
enth¨alt.
Peter stimmt zu und beginnt eine neue Sitzung indem er den entsprechenden Punkt
im Kontextmen¨
u der Sitzungs¨
ubersicht w¨ahlt. Der erscheinende Dialog fordert
ihn zun¨achst auf, aus einer Liste der Projekte in seiner Eclipse-Arbeitsumgebung
die Projekte zu w¨ahlen, an denen in dieser Sitzung gearbeitet werden soll. Peter
f¨allt auf, dass er die UI-Komponente momentan gar nicht ausgecheckt hat. Er
u
¨berspringt also diesen Punkt, um eine Sitzung ohne zugeordnete Projekte zu
erstellen. Nach Eingabe eines passenden Namens f¨
ur die neue Sitzung beendet er
den Dialog. Die neue Sitzung erscheint in der Sitzungs¨
ubersicht. Nachdem er das
fehlende Projekt aus dem CVS-Repository ausgecheckt hat, f¨
ugt er es u
¨ber die
entsprechende Funktion im Kontextmen¨
u der Sitzungs¨
ubersicht der eben erstellten
Sitzung hinzu und betritt die Sitzung als Navigator.
Jenny tritt der Sitzung als Driver bei. W¨ahrend der automatischen Synchronisation ihrer lokalen Kopie der UI-Komponente mit dem XPairtise-Server wird
sie auf ihre bereits bestehenden Modifikationen hingewiesen. Als Driver kann sie
¨
nun w¨ahlen, ob sie diese Anderungen
verwerfen oder in die bestehende Sitzung
¨
einfließen lassen m¨ochte. Sie entscheidet sich f¨
ur letzteres. Die Anderungen
werden daraufhin auf den Server u
¨bertragen und erscheinen kurz darauf auch bei
Peter.
Kurze Zeit sp¨ater trifft auch Karl auf dem Server ein. Mangels eines freien PairProgramming-Partners entschließt er sich, zun¨achst der bestehenden Sitzung als
Spectator beizutreten. W¨ahrend der initialen Synchronisation seiner Projektdaten
mit dem XPairtise-Server wird er darauf hingewiesen, dass seine lokale Version
des Projektes auf einem zu alten CVS-Stand ist und ein Update n¨otig ist. Karl
best¨atigt den Hinweis, was zu einem automatischen Update des Projektes auf
den n¨otigen Stand f¨
uhrt, bevor der Abgleich mit dem Server fortgesetzt wird.
¨
Nach der Beendigung des Abgleichs wird Karl auf die Anderungen
hingewiesen,
die Jenny bereits in die Sitzung einfließen ließ. Er stimmt dem Einspielen der
¨
n¨otigen Anderungen
in seine lokale Version zu und beendet damit den Beitritt zur
Sitzung.
Im Laufe der n¨achsten Stunde arbeiten Jenny und Peter an L¨osungen der gefun¨
denen Probleme. Jegliche Anderungen
an Ressourcen durch Jenny werden dabei
¨
auch bei den anderen Teilnehmern durchgef¨
uhrt. Eine der Anderungen,
die Jenny
zu Beginn der Sitzung einfließen ließ, stellt sich dabei als problematisch heraus.
Sie nutzt die Revert-Funktion, um die betroffenen Dateien wieder durch ihre Basisrevisionen zu ersetzen, was bei den anderen Teilnehmern zur Durchf¨
uhrung des
gleichen Schrittes f¨
uhrt.
16
3.1 Ein Beispielszenario
Nun trifft auch Lisa auf dem Server ein. Im Chat entschuldigt sie sich f¨
ur die
Versp¨atung und entscheidet sich, der laufenden Sitzung als weiterer Spectator
¨
beizutreten. Da sich in ihrer Projektkopie einige noch nicht ver¨offentlichte Anderungen befinden, nimmt sie das Angebot, vor dem Beitritt eine Sicherheitskopie des
Projektes erstellen zu lassen, an. Mit dem Wissen, auf der sicheren Seite zu sein,
¨
¨
stimmt sie dem Uberschreiben
ihrer lokalen Anderungen
mit den in der Sitzung
g¨
ultigen Inhalten am Ende der initialen Synchronisation zu.
Schneller als erwartet gelingt es Jenny und Peter, die gefundenen Probleme zu
beheben. Peter schl¨agt vor, einem der beteiligten Pakete noch einen sinnvolleren
¨
Namen zu geben. Nach der Zustimmung der anderen nimmt er die Anderung
im
Eclipse-Package-Explorer vor, ohne daran zu denken, dass er nicht Driver der
¨
Sitzung ist. Seine lokale Anderung
wird automatisch r¨
uckg¨angig gemacht, um
weiterhin die Konsistenz der Sitzung zu gew¨ahrleisten. In ihrer Rolle als Driver
nimmt Jenny daraufhin die Umbenennung auf ihrer Seite vor, was die Replikation
¨
der Anderung
zur Folge hat.
¨
Nach einigen weiteren Tests checkt Jenny die Anderungen
ins CVS-Repository
ein. Als Grundlage f¨
ur den Commit-Kommentar verwendet sie eine automatisch
generierte Vorlage, die den Sitzungsnamen sowie Informationen u
¨ber die zuletzt
als Driver und Navigator agierenden Sitzungsteilnehmer bereits enth¨alt. Da Jenny
als Driver agiert, l¨ost die Revisions¨anderung der betroffenen Dateien ihrer Projektversion auch bei den anderen Teilnehmern ein Update auf die aktualisierten
Revisionen aus dem CVS-Repository aus.
Karl nutzt die Gunst der Stunde, um die drei anderen im Chat auf k¨
urzliche
¨
Anderungen einiger Schnittstellen im Basis-Plug-in hinzuweisen, die eventuell
Einfluss auf die eigenen Erweiterungen haben k¨onnten. Peter bittet Karl, ihm
¨
die betreffenden Anderungen
im Basis-Plug-in zu zeigen. Er f¨
uhrt ein Update
seiner Kopie des Basis-Plug-ins auf die aktuellste Subversion-Revision durch und
bittet Jenny um einen Rollenwechsel, um das Projekt der Sitzung hinzuf¨
ugen
zu k¨onnen. Nach dem Rollenwechsel nutzt Peter die entsprechende Funktion
im Kontextmen¨
u der Sitzungs¨
ubersicht, um das zus¨atzliche Projekt der Sitzung
hinzuzuf¨
ugen.
Peter verf¨
ugt nur u
ugte Projekt
¨ber eingeschr¨ankte Bandbreite und das hinzugef¨
ist mehrere Megabyte groß. Da nur die Subversion-Metadaten des Projektes auf
den XPairtise-Server u
ussen, geht das Hinzuf¨
ugen trotzdem
¨bertragen werden m¨
erfreulich schnell. Die anderen Teilnehmer der Sitzung erhalten einen Hinweis
auf das hinzugef¨
ugte Projekt, den sie best¨atigen m¨
ussen, bevor die Synchronisation ihrer lokalen Version des Projektes mit dem XPairtise-Server erfolgt. Da
Jenny bisher noch nicht u
ugten Projektes in ihrer
¨ber eine Kopie des hinzugef¨
Eclipse-Arbeitsumgebung verf¨
ugt, wird auf ihrer Seite, nach Best¨atigung eines
17
3. Anforderungsanalyse
entsprechenden Hinweises, zun¨achst ein automatischer Checkout des Projektes aus
dem Subversion-Repository des Projektes durchgef¨
uhrt.
Nach einem kurzen Blick auf die Neuerungen beschließen die drei, die aktuelle
¨
Sitzung zu einem sp¨ateren Zeitpunkt wieder aufzunehmen, um die n¨otigen Anderungen anzugehen. Da die UI-Komponente davon nicht betroffen ist, schließt
Peter alle Editoren, in denen Dateien des entsprechenden Projektes ge¨offnet waren
und entfernt das Projekt aus der Sitzung u
u der Sitzungs¨
uber¨ber das Kontextmen¨
sicht. Die anderen Teilnehmer erhalten einen Hinweis u
¨ber das entfernte Projekt.
Lisa wird außerdem angeboten, den urspr¨
unglichen Zustand ihres lokalen Projektes aus der zuvor erstellten Sicherheitskopie wiederherzustellen. Sie stimmt dem
zu.
¨
Uber
den Chat verabreden sich die vier f¨
ur n¨achste Woche und verlassen die
Sitzung. Da sie die Sitzung zu einem sp¨ateren Zeitpunkt wieder aufnehmen m¨ochten,
entfernen sie sie zu diesem Zeitpunkt noch nicht.
3.2 Betrachtung des Beispielszenarios
Es gilt nun zu untersuchen, in wie weit das im vorherigen Abschnitt beschriebene
Szenario bereits durch die urspr¨
ungliche Version von XPairtise erm¨oglicht wird.
Als direkte Folge hieraus ergeben sich die wichtigsten Anforderungen an die in
dieser Arbeit behandelten Erweiterungen.
Eine Integration von Versionsverwaltungssystemen fehlt in der urspr¨
unglichen
Version von XPairtise vollkommen. Eventuell bestehende Repository-Anbindungen
lokaler Projekte werden ignoriert. Im Beispielszenario finden sowohl CVS- als auch
Subversion-Projekte Verwendung. Es beschreibt die direkte Verwendung einiger
F¨ahigkeiten dieser Versionsverwaltungssysteme durch XPairtise, die urspr¨
unglich
in dieser Form nicht m¨oglich sind:
¨
• Bei der Ubertragung
eines Projektes auf den Server werden, wenn m¨oglich,
nur die Metadaten der Versionsverwaltung statt der Dateiinhalte u
¨bertragen.
• Es werden automatische Updates auf bestimmte Revisionen einzelner Ressourcen oder ganzer Projekte aus dem Repository durchgef¨
uhrt.
• Es werden automatische Reverts einzelner Ressourcen auf ihre aktuelle Basisrevision durchgef¨
uhrt.
• Ein Projekt wird bei Bedarf komplett aus dem Repository ausgecheckt.
• Es werden automatisch Kommentarvorlagen mit Informationen u
¨ber die
¨
Sitzung erstellt, die bei einem Commit der Anderungen
w¨ahlbar sind.
18
3.3 Anforderungskatalog
Die Erstellung von Sicherheitskopien von Projekten funktioniert in der urspr¨
unglichen Form nicht akzeptabel mit Projekten, die unter Versionskontrolle stehen,
da die Metadaten der Versionsverwaltung beim Erstellen der Sicherheitskopie
ignoriert werden. Im Beispielszenario wird jedoch eine Sicherheitskopie eines
CVS-Projektes erstellt und beim Verlassen der Sitzung erfolgreich wiederhergestellt.
Bei Sitzungsbeitritt bestehende lokale Unterschiede zur in der Sitzung g¨
ultigen
Datenbasis werden in der urspr¨
unglichen Version von XPairtise im Zuge der
initialien Synchronisation unabh¨angig von der Benutzerrolle ohne Gegenfrage
u
¨berschrieben. Im Beispielszenario werden die Teilnehmer jedoch zun¨achst auf die
¨
Unterschiede hingewiesen und m¨
ussen das Uberschreiben
best¨atigen. Erfolgt der
Beitritt als Driver, kann außerdem optional statt dessen der lokale Stand in der
Sitzung g¨
ultig gemacht werden.
Einer Pair-Programming-Sitzung ist in XPairtise urspr¨
unglich genau ein Projekt
zugeordnet. Der Wunsch nach der M¨oglichkeit, einer Sitzung auch mehrere Projekte zuordnen zu k¨onnen, wurde erstmalig auf der SourceForge-Projektseite von
XPairtise [XPa08] genannt. Diese Erweiterung war zwar nicht Bestandteil der
¨
urspr¨
unglichen Aufgabenstellung, wegen weitgehender Uberschneidungen
der von
¨
den n¨otigen Anderungen
betroffenen Komponenten bot sich jedoch an, sie im Zuge
dieser Arbeit ebenfalls zu verwirklichen.
Das Beispielszenario beschreibt eine flexible Zuordnung von Projekten zu Sitzungen,
die in XPairtise urspr¨
unglich so nicht m¨oglich ist:
• Zun¨achst wird eine Sitzung ohne zugeordnete Projekte erstellt.
• Dieser Sitzung werden im weiteren Verlauf mehrere Projekte zugeordnet.
• Eines dieser Projekte wird sp¨ater wieder aus der noch aktiven Sitzung entfernt.
3.3 Anforderungskatalog
Auf der Grundlage dieser Betrachtungen l¨asst sich nun der folgende Anforderungskatalog zusammenstellen:
A01 / Erkennung einer Repository-Anbindung: Projekte unter Kontrolle eines
Versionsverwaltungssystems m¨
ussen als solche erkannt werden.
A02 / Unterst¨
utzung von CVS und Subversion: Sowohl CVS als auch Subversion sollten unterst¨
utzt werden, da dies die momentan am weitesten verbreiteten Versionsverwaltungssysteme sind. Zuk¨
unftige Integration weiterer
19
3. Anforderungsanalyse
Versionsverwaltungssysteme sollte mit m¨oglichst wenig Aufwand m¨oglich
sein.
A03 / Replikation von Revisions- und Synchronisationsinformationen:
Bei
¨
der Ubertragung von Projekten auf den Server sollten von im Vergleich zu
ihrer Basisrevision unver¨anderten Daten nur die Metadaten der Versionsverwaltung u
ussen. Revisions- und Synchronisationsinforma¨bertragen werden m¨
tionen einzelner Ressourcen m¨
ussen also ermittelt werden k¨onnen.
A04 / Replikation von Repository-Informationen: Erweiterte Informationen
u
ussen repliziert werden. Hierzu geh¨oren das verwendete
¨ber Projekte m¨
Versionsverwaltungssystem, die Repository-URL, sowie geeignete globale
Revisionsinformationen.
ussen bei Bedarf aus dem Repository
A05 / Checkout: Komplette Projekte m¨
bezogen werden k¨onnen.
A06 / Update: Updates einzelner Ressourcen oder ganzer Projekte auf bestimmte Revisionen aus dem Repository m¨
ussen erm¨oglicht werden.
uckf¨
uhrung modifizierter Ressourcen auf ihre Basisrevision
A07 / Revert: Die R¨
muss erm¨oglicht werden.
¨
¨
A08 / R¨
ucknahme unzul¨
assiger Anderungen:
Unzul¨assige Anderungen
an Ressourcen durch den Navigator oder einen Spectator sollten, soweit m¨oglich,
mittels der Dienste des verwendeten Versionsverwaltungssystems r¨
uckg¨angig
gemacht werden k¨onnen.
A09 / Persistenz von Metadaten: Die Persistenz von Metadaten der Versionsverwaltung auf dem Server muss gew¨ahrleistet sein, um weiterhin eine Wiederaufnahme von Sitzungen auch nach einem Neustart des Servers zu erm¨oglichen.
A10 / Commit-Kommentarvorlagen: Es sollten automatisch Kommentarvorla¨
gen f¨
ur den Commit von sich in einer Sitzung ergebenden Anderungen
erzeugt
werden, die Informationen u
¨ber die Sitzung widerspiegeln.
A11 / Unterst¨
utzung von Projekten ohne Versionskontrolle:
Die Unterst¨
utzung von Projekten ohne Versionskontrolle muss weiterhin in gewohntem
Umfang gew¨ahrleistet sein.
A12 / Erstellung von Sicherheitskopien: Die Erstellung und Wiederherstellung
von Sicherheitskopien von Projekten sollte auch mit Projekten unter Versionskontrolle zuverl¨assig funktionieren.
¨
A13 / Anzeige n¨
otiger Anderungen:
Bei Sitzungsbeitritt m¨
ussen Benutzer zun¨achst auf Unterschiede zwischen lokalen und in der Sitzung g¨
ultigen Pro¨
jektdaten hingewiesen werden k¨onnen. Der Driver muss lokale Anderungen
noch in die Sitzung einfließen lassen k¨onnen.
20
3.3 Anforderungskatalog
A14 / Projektzuordnung bei Sitzungserstellung: Einer neuen Sitzung sollten
sich mehrere Projekte zuordnen lassen. Auch Sitzungen ohne zugeordnete
Projekte sollten m¨oglich sein.
A15 / Hinzuf¨
ugen von Projekten: Projekte sollten sich auch nachtr¨aglich zu
Sitzungen hinzuf¨
ugen lassen. Dies sollte auch bei momentan aktiven Sitzungen
m¨oglich sein.
A16 / Entfernen von Projekten: Projekte sollten sich aus bestehenden Sitzungen entfernen lassen. Dies sollte auch bei momentan aktiven Sitzungen m¨oglich
sein.
21
4 Stand der Technik
In diesem Kapitel werden einige weitere ausgew¨ahlte Werkzeuge f¨
ur die kooperative
Softwareentwicklung kurz vorgestellt. Im Einzelnen handelt es sich um zwei weitere
Eclipse-Plug-ins und eine Erweiterung f¨
ur das Konkurrenzprojekt NetBeans.
¨
Neben einer groben Ubersicht
u
¨ber den Funktionsumfang der Projekte liegt das
Hauptaugenmerk der Betrachtung dabei jeweils auf Konzept und Eigenschaften
der Synchronisation der ben¨otigten Arbeitsdaten. Als grobe Vergleichsgrundlage
dienen die in Kapitel 3 herausgearbeiteten Anforderungen sowie das urspr¨
ungliche
Synchronisationsmodell von XPairtise, das im Folgenden zun¨achst kurz skizziert
wird.
4.1 Status Quo - Synchronisation von Ressourcen in
XPairtise
Die Replikation von Ressourcen (Dateien und Verzeichnisse) zwischen den Teilnehmern einer Sitzung erfolgt durch XPairtise in Form von replizierten Ressourcen.
Hierbei handelt es sich um spezielle replizierte Elemente, die jeweils den aktuellen
Zustand einer konkreten Ressource beschreiben. Dieser Zustand ist definiert durch
den Pfad der Ressource innerhalb des Projektes und, im Falle einer Datei, eine
eindeutige Pr¨
ufsumme (MD5-Hash) des aktuellen Inhaltes.
Der Inhalt selbst wird ebenfalls auf den Server u
¨bertragen, ist aber im Normalfall
nicht Bestandteil einer replizierten Ressource. Es besteht eine 1:1-Relation zwischen
Ressourcen und replizierten Ressourcen, d.h. jeder konkreten Ressource ist genau
eine replizierte Ressource zugeordnet.
Bei Erstellung einer neuen Pair-Programming-Sitzung wird zun¨achst ein einzelnes
Projekt zur Verwendung in der Sitzung freigegeben. Hierf¨
ur wird der komplette
Inhalt des lokalen Projektes zun¨achst in komprimierter Form auf den Server u
¨bertragen. Auf dem Server werden die u
¨bertragenen Daten im Dateisystem abgelegt
und eine neue replizierte Liste er¨offnet und mit replizierten Ressourcen, die die Ressourcen des Projektes beschreiben, gef¨
ullt. Diese Liste dient anschließend als Basis
23
4. Stand der Technik
f¨
ur die Synchronisation der lokalen Projektdaten der einzelnen Sitzungsteilnehmer
mit dem Server.
¨
Im Laufe einer Sitzung fallen Anderungen
am Datenbestand eines Projektes an.
Ressourcen werden ge¨andert, hinzugef¨
ugt oder gel¨oscht. Zur automatischen Erken¨
nung dieser Anderungen
bedient sich XPairtise der von Eclipse bereitgestellten
¨
Resource Change Listener (vgl. [Art04]). Auf Seite des Drivers erkannte Anderungen werden an den Server gesandt, der daraufhin die betroffenen replizierten
Ressourcen aktualisiert. Bei den u
¨brigen Teilnehmern wird diese automatische
Erkennung hingegen verwendet, um unzul¨assige Modifikationen, die der klaren
Rollenverteilung des Pair Programming widersprechen und die Konsistenz der
Replikation gef¨ahrden w¨
urden, automatisch r¨
uckg¨angig zu machen.
¨
F¨
ur die Ubertragung
von Dateiinhalten vom XPairtise-Server zu den Teilnehmern
werden zwei Varianten geboten:
¨
Push: Der Push-Mechanismus erlaubt die durch den Server ausgel¨oste Ubertragung der w¨ahrend einer laufenden Sitzung anfallenden ge¨anderten Inhalte
zu den Teilnehmern. Zu diesem Zweck bedient sich XPairtise des DekoriererEntwurfsmusters, um die betroffenen replizierten Ressourcen um den tats¨achlichen Inhalt der durch sie beschriebenen Ressourcen zu erweitern.
Pull: Alternativ kann ein Client den Inhalt einzelner Ressourcen gezielt vom
Server beziehen. Hierf¨
ur wird eine synchrone Anfrage an den Server geschickt,
deren Antwort den gew¨
unschten Inhalt enth¨alt. Diese Variante wird zur
Synchronisation einzelner Ressourcen mit dem Server w¨ahrend des initialen
Projektabgleiches oder zur R¨
ucknahme unzul¨assiger Modifikationen durch
den Navigator oder einen Spectator verwendet. Ist das Projekt bei einem
Teilnehmer zum Zeitpunkt des Sitzungsbeitritts noch nicht vorhanden, wird
der komplette Projektinhalt auf diese Weise vom XPairtise-Server bezogen.
4.2 Verwandte Anwendungen
4.2.1 XecliP
Das Eclipse-Plug-in XecliP [Xec08] entstand parallel zu XPairtise ebenfalls im
Zuge des Fachpraktikums CSCW im Wintersemester 2006/2007 im Lehrgebiet
Kooperative Systeme der FernUniversit¨at in Hagen. Die Praktikumsteilnehmer
arbeiteten in zwei Gruppen an zwei unabh¨angigen Eclipse-Plug-ins mit der selben
Aufgabenstellung. Trotz der einheitlichen Zielsetzung ergaben sich einige inter-
24
4.2 Verwandte Anwendungen
essante Unterschiede sowohl bei den Funktionsschwerpunkten als auch bei der
Architektur.
Die grundlegende Benutzerelemente von XecliP sind mit den in Abschnitt 2.3 beschriebenen von XPairtise gebotenen Funktionen weitgehend vergleichbar. So bietet
auch XecliP eigene Sichten zur Anzeige von Benutzern und Programmiersitzungen
sowie eine Chat-Funktion. Unterschiede zu XPairtise bestehen hier haupts¨achlich
in der gew¨ahlten Form der Darstellung der entsprechenden Daten. Lediglich eine
Whiteboard-Funktion fehlt in XecliP. Abbildung 4.1 zeigt die typische Aufteilung
der von XecliP definierten Eclipse-Perspektive.
Abbildung 4.1: Die XecliP-Perspektive
Als besondere Eigenschaft von XecliP ist die F¨ahigkeit zu nennen, komplette
Pair-Progamming-Sitzungen auf dem Server aufzeichnen zu k¨onnen, um sie sp¨ater
erneut abspielen zu k¨onnen. Diese Aufzeichnungsfunktion muss beim Erstellen
einer Sitzung explizit aktiviert werden. Zum Abspielen aufgezeichneter Sitzungen
steht eine komfortable Eclipse-Sicht bereit (siehe Abbildung 4.2).
Die grundlegende Netzwerkarchitektur von XecliP st¨
utzt sich nicht auf eine bestehende Kommunikationsl¨osung. Statt dessen wird mit direkter Socket-Kommunikation u
¨ber ein propriet¨ares Protokoll gearbeitet. Hier wurde also ein grundlegend
25
4. Stand der Technik
Abbildung 4.2: Der XecliP-Playback-View
anderer Weg eingeschlagen als bei XPairtise (vgl. Abschnitt 2.3.1). F¨
ur die Datenhaltung auf dem Server verwendet XecliP mit Apache Derby [Der08] eine
vollwertige, wenn auch sehr schlanke, Datenbankl¨osung, w¨ahrend XPairtise mit
einfachen XML-Dateien arbeitet.
Deutliche funktionale Unterschiede der beiden Plug-ins bestehen bei der Synchronisation von Projektdaten. XecliP wurde ausschließlich f¨
ur die Verwendung von
Projekten unter CVS-Kontrolle konzipiert. Projekte, die nicht unter Versionsverwaltung stehen, werden nicht unterst¨
utzt. Wie in der urspr¨
unglichen Version von
XPairtise ist nur ein Projekt pro Sitzung m¨oglich. Dieses muss bei Erstellung
der Sitzung ausgew¨ahlt werden. Das verwendete Projekt muss bei allen Teilnehmern zu Beginn der Sitzung bereits vorhanden sein. Ein automatisierter Checkout
kompletter Projekte aus dem CVS-Repository wird nicht unterst¨
utzt.
¨
Uber
den XecliP-Server m¨
ussen im Normalfall w¨ahrend der initialen Synchronisation eines Projektes also nur die Daten u
¨bertragen werden, die im Vergleich
zum CVS-Repository modifiziert sind. Alle weiteren Daten k¨onnen aus dem Repository bezogen werden. Eine Ausnahme dieser Regel stellt die Verwendung der
Aufzeichnungsfunktion von Sitzungen dar. Ist diese aktiv, m¨
ussen die kompletten
Projektdaten auf den Server u
ung¨bertragen werden. XPairtise muss in seiner urspr¨
lichen Form hingegen grunds¨atzlich alle Projektdaten auf den Server u
¨bertragen,
der sie dann an alle Teilnehmer verteilt. Das zu u
¨bertragende Datenaufkommen
einer typischen Sitzung ist dort damit deutlich h¨oher als bei XecliP.
Anders als XPairtise beschr¨ankt XecliP die Replikation von w¨ahrend der Sitzung
¨
¨
anfallenden Anderungen
an Projektdaten auf die Anderungen,
die u
¨ber den verteilten Editor vorgenommen werden. Modifikationen, die außerhalb des Editors
durchgef¨
uhrt werden, etwa das Erstellen, L¨oschen oder Umbenennen von Dateien
26
4.2 Verwandte Anwendungen
im Eclipse-Package-Explorer, werden nicht erfasst und k¨onnen daher zu inkonsistenten Zust¨anden der Replikation f¨
uhren. Gleiches gilt f¨
ur u
¨ber den Editor ausgel¨oste
¨
datei¨
ubergreifende Umgestaltungen (Refactorings). Die Verteilung solcher Anderungen zwischen den Teilnehmern muss also außerhalb der Sitzung manuell erfolgen,
beispielsweise u
¨ber das CVS-Repository.
Die CVS-Integration von XecliP war eine der wichtigsten Inspirationen f¨
ur die in
dieser Arbeit vorgestellten Erweiterungen von XPairtise. Trotzdem wurden bei der
Implementierung dieser Erweiterungen einige grundlegend andere Wege gew¨ahlt.
Auf konzeptionelle Unterschiede und die Gr¨
unde daf¨
ur wird in Abschnitt 5.2.2
n¨aher eingegangen.
4.2.2 Saros
Ein weiteres Eclipse-Plug-in f¨
ur Distributed Pair Programming ist Saros [SAR08].
Es entstand 2006 im Zuge einer Diplomarbeit an der Freien Universit¨at Berlin
[Dje06]. Neben einiger abweichender Nutzungskonzepte unterscheidet es sich von
XecliP und XPairtise vor allem dadurch, dass es ohne eigene Server-Komponente
und eigene Benutzerverwaltung auskommt.
Abbildung 4.3: Die Saros-Netzwerk-Architektur (Quelle: [SAR08])
F¨
ur die Kommunikation verwendet Saros das XML-basierte Jabber/XMPP-Protokoll [XMP08]. Die Verbindung erfolgt zu einem beliebigen Jabber-Server, u
¨ber den
ein Großteil der ben¨otigten Nachrichten versendet wird. Lediglich der Dateitransfer
erfolgt aus Performance-Gr¨
unden im Normalfall nicht u
¨ber den Jabber-Server. Statt
27
4. Stand der Technik
dessen finden direkte Peer-to-Peer-Verbindungen zwischen einzelnen Teilnehmern
mit Hilfe einer entsprechenden XMPP-Erweiterung (vgl. [S5B08]) Verwendung.
Abbildung 4.3 skizziert diese Architektur.
Das Saros-Plug-in selbst ist sehr schlank ausgelegt und legt das Hauptaugenmerk auf
die reine Editor-Funktionalit¨at. Dar¨
uber hinaus stellt es lediglich zwei u
¨bersichtlich
gestaltete Eclipse-Sichten zur Verf¨
ugung, auf eine eigene Perspektive wird verzichtet.
Der Roster-View dient zur Kontrolle der Verbindung zum Jabber-Server und zur
Verwaltung von Jabber-Kontakten. Seine Kontakte kann man hier zur Teilnahme
an einer laufenden Pair-Programming-Sitzung einladen oder ihnen Kurznachrichten
senden.
Abbildung 4.4: Saros in Aktion
Die zweite Sicht dient zur Anzeige der an einer laufenden Sitzung teilnehmenden
Benutzer und ihrer aktuellen Rollenzuweisung. Anders als bei XecliP und XPairtise
unterscheidet Saros hierbei zwischen nur zwei Benutzerrollen. Zu einer Sitzung
geh¨oren ein Driver und beliebig viele Observer. Die Rolle des Drivers kann beliebig
an jeden dieser Observer weitergegeben werden. Systembedingt fehlt in Saros eine
¨
Ubersicht
u
¨ber von anderen Teilnehmern erstellte Sitzungen.
28
4.2 Verwandte Anwendungen
Auch in Saros ist einer Sitzung nur ein Projekt zugeordnet. Die Erstellung einer Sitzung erfolgt implizit durch die Freigabe eines selektierten Projektes u
¨ber
einen entsprechenden Men¨
upunkt und die Einladung eines ersten Observers aus
den vorhandenen Jabber-Kontakten. Weitere Teilnehmer m¨
ussen ebenfalls explizit eingeladen werden, um als zus¨atzliche Observer an einer bestehenden PairProgramming-Sitzung teilnehmen zu k¨onnen.
Nimmt ein Teilnehmer eine solche Einladung an, empf¨angt er vom Driver der
Sitzung zun¨achst eine Liste der zum Projekt geh¨orenden Ressourcen, die dann mit
den Inhalten aller lokalen Projekte verglichen wird. Das Projekt mit der gr¨oßten
¨
Ubereinstimmung
dient im Folgenden als Grundlage f¨
ur die Synchronisation der
Projektdaten. Nach der R¨
ucksendung einer Liste der fehlenden Ressourcen werden
diese vom Driver an den neuen Teilnehmer u
¨bertragen. Der neue Teilnehmer
kann nun entscheiden, ob das vorhandene Projekt mit den empfangenen Daten
modifiziert werden soll oder ob mit einer Kopie des Projektes gearbeitet werden
soll.
Ist bei einem neuen Teilnehmer bisher kein verwendbares Projekt vorhanden, muss
das komplette Projekt auf diese Weise u
¨bertragen werden. Um das Datenaufkommen
zu minimieren, ist daher empfehlenswert, dass sich die Teilnehmer bereits vor dem
Zustandekommen der Sitzung auf das zu verwendende Projekt einigen und die
ben¨otigte Version beispielsweise von einem Versionsverwaltungssystem beziehen.
Eine direkte Integration von Versionsverwaltungssystemen in Saros besteht nicht.
Wie in XPairtise werden auch in Saros alle im Verlauf einer Sitzung durch den
¨
Driver durchgef¨
uhrten Anderungen
an den Ressourcen des verwendeten Projektes
repliziert. Der Versuch eines Observers, gem¨aß der klaren Rollenverteilung des Pair
¨
Programming unzul¨assige Anderungen
an Ressourcen durchzuf¨
uhren wird ebenfalls
¨
erkannt und mit einem klaren Warnhinweis quittiert. F¨
uhrt er die Anderungen
trotzdem durch, werden sie, anders als bei XPairtise, hier allerdings nicht automatisch r¨
uckg¨angig gemacht und f¨
uhren somit zu Inkonsistenzen der Synchronisation
der gemeinsamen Datenbasis.
4.2.3 NetBeans Developer Collaboration
In gesunder Konkurrenz zu Eclipse steht das haupts¨achlich von SUN Microsystems entwickelte Open-Source-Projekt NetBeans [NBS08]. Mit dem DeveloperCollaboration-Modul stellt das NetBeans Collaboration Projekt [COL08] eine
Erweiterung zur Verf¨
ugung, die einige fertige Hilfsmittel zur Kooperation zwischen Softwareentwicklern sowie ein Framework zur Entwicklung weiterer solcher
Komponenten direkt in die NetBeans IDE einbettet. Den Kern dieser Technologie
bildet das XML-basierte MOXC-Protokoll (Message-Oriented XML Collaboration
29
4. Stand der Technik
Protocol ), das von verschiedenen darunter liegenden Transport-Protokollen wie
XMPP, JXTA oder SIP abstrahiert. Im Normalfall findet XMPP Verwendung.
Um die bereitgestellten Funktionen verwenden zu k¨onnen, wird ein Benutzerkonto
auf einem zentralen Kooperationsserver ben¨otigt. Ein o¨ffentlicher, frei verwendbarer
Server wird von SUN bereits zur Verf¨
ugung gestellt. Alternativ kann ein eigener
Server verwendet werden. Nach dem Verbindungsaufbau ¨offnet sich zun¨achst eine
Ansicht, die Kontakte und Sitzungen des lokalen Benutzers zusammenfasst. Hier
m¨
ussen Kontakte explizit hinzugef¨
ugt werden, um sie sp¨ater zur Teilnahme an
bestehenden Sitzungen einladen zu k¨onnen.
Wurde eine neue Sitzung definiert, ¨offnen sich weitere Ansichten f¨
ur die zur Verf¨
ugung stehenden Kooperationsfunktionen. Im Normalfall ist dies eine Chat-Funktion
sowie die M¨oglichkeit zur expliziten Freigabe von Dateien und Projekten (siehe
Abbildung 4.5). Die Chat-Funktion ist speziell auf die Bed¨
urfnisse von Softwareentwicklern ausgelegt. So unterst¨
utzt sie neben reinen Textnachrichten auch den
Versand von Java-, XML- oder HTML-Quelltexten unter Beibehaltung jeglicher
Formatierungen. Das Eingabefenster fungiert daf¨
ur bei Bedarf als vollwertiger
Editor.
Abbildung 4.5: Die Oberfl¨ache des NetBeans-Developer-Collaboration-Moduls
Die Freigabe einzelner Dateien oder ganzer Projekte erfolgt intuitiv per Drag
¨
and Drop aus der lokalen Projektliste in eine entsprechende Ubersicht,
die alle
momentan von den verschiedenen Teilnehmern der Sitzung freigegebenen Daten
zusammenfasst. Andere Teilnehmer k¨onnen nun auf die freigegebenen Daten zugrei-
30
4.3 Zusammenfassung
fen und sie bearbeiten, als w¨aren sie Bestandteil eines lokalen Projektes. Da diese
Funktionalit¨at nicht explizit auf die Durchf¨
uhrung von Pair Programming ausgelegt
ist, wird hierbei keine entsprechende Rollenzuweisung vorgenommen. Insbesondere
k¨onnen auch mehrere Benutzer gleichzeitig die selbe Datei editieren, indem nur die
unmittelbare Umgebung der momentan von einem Benutzer bearbeiteten Zeilen
f¨
ur andere Teilnehmer gesperrt und entsprechend markiert wird (siehe Abbildung
4.6).
Abbildung 4.6: Sperrung einzelner Regionen im NetBeans-Editor
Anders als bei den anderen betrachteten Projekten m¨
ussen freigegebene Projektdaten in NetBeans grunds¨atzlich komplett vom freigebenden Benutzer zu allen
anderen Teilnehmern u
¨bertragen werden, wo sie in einer tempor¨aren Umgebung
abgelegt werden. Beim Empf¨anger bereits vorhandene passende Daten, die als
Grundlage f¨
ur eine Synchronisation mit geringerem Datenaufkommen dienen k¨onnten, werden nicht verwendet. Im Gegensatz zum ebenfalls auf XMPP basierenden
Saros erfolgt der Dateiversand hier außerdem komplett u
¨ber den zentralen Server.
Die Freigabe gr¨oßerer Projekte u
¨ber einen externen Server und eine Netzanbindung
mit eingeschr¨ankter Bandbreite ist dem entsprechend zeitaufw¨andig. Die Vorteile dieses Modells liegen also vorwiegend in der einfachen Freigabe ausgew¨ahlter
Dateien, etwa f¨
ur die Durchf¨
uhrung kooperativer Reviews.
4.3 Zusammenfassung
In diesem Kapitel wurden einige verwandte Anwendungen f¨
ur die kooperative
Softwareentwicklung vorgestellt. Das Hauptaugenmerk lag hierbei jeweils auf der
Realisierung der Synchronisation der in einer Sitzung verwendeten Arbeitsdaten.
Aufgrund deutlicher konzeptioneller und funktionaler Unterschiede konnten die
Eigenschaften von XPairtise und die in Kapitel 3 herausgearbeiteten Anforderungen
hierbei nur als grobe Vergleichsgrundlage dienen. Dieser Abschnitt fasst einige der
relevanten Erkenntnisse zusammen.
31
4. Stand der Technik
Von den vorgestellten Projekten bietet lediglich XecliP die direkte Integration der
Dienste eines Versionsverwaltungssystems. Das in einer Sitzung verwendete Projekt
muss hier zwingend unter Kontrolle von CVS stehen und wird bei Sitzungsbeitritt
mit Hilfe des Repositories auf den ben¨otigten Stand gebracht. Ein automatischer
Checkout des kompletten Projektes wird jedoch nicht geboten. Leider verzichtet
XecliP w¨ahrend einer laufenden Sitzung auf die kontinuierliche Replikation jeglicher
¨
Anderungen
an Ressourcen, die nicht im verteilten Editor ge¨offnet sind.
In Saros und NetBeans werden grunds¨atzlich komplette Dateiinhalte zwischen
den Teilnehmern einer Sitzung u
¨bertragen. Eine eventuell bestehende RepositoryAnbindung wird ignoriert. Saros nutzt Peer-to-Peer-Verbindungen zwischen einzelnen Teilnehmern f¨
ur den Dateiversand und reduziert das bei Sitzungsbeitritt zu
u
¨bertragende Datenaufkommen durch einen Abgleich mit beim Empf¨anger eventuell schon vorhandenen Daten. NetBeans verzichtet auf diese M¨oglichkeit, was die
Freigabe gr¨oßerer Projekte in diesem Fall recht teuer gestaltet. Der Dateitransfer
l¨auft in NetBeans außerdem grunds¨atzlich u
¨ber den zentralen Server.
Sowohl XecliP als auch Saros beschr¨anken sich auf ein einzelnes Projekt pro Kooperationssitzung. NetBeans erlaubt zwar prinzipiell auch die Freigabe mehrerer
Projekte, eignet sich aufgrund des vergleichsweise ineffizienten Synchronisationsmodells jedoch eher f¨
ur die Arbeit mit wenigen, ausgew¨ahlten Dateien.
32
5 L¨
osungskonzept
In diesem Kapitel wird das L¨osungskonzept beschrieben, das der endg¨
ultigen
Implementierung der in dieser Arbeit vorgestellten Erweiterungen von XPairtise
zugrunde liegt. Ziel war es, das in Abschnitt 4.1 beschriebene bestehende Modell
der Synchronisation von Ressourcen in XPairtise so zu erweitern, dass alle in
Kapitel 3 herausgearbeiteten Anforderungen erf¨
ullt werden.
5.1 Erweiterung der bestehenden Architektur
Das in Abschnitt 4.1 beschriebene Synchronisationsmodell hat sich bereits bew¨ahrt
¨
und funktioniert zuverl¨assig. Es ist daher erstrebenswert, grundlegende Anderungen daran zu vermeiden, die u
ullung der Anforderungen n¨otigen
¨ber die zur Erf¨
Erweiterungen hinausgehen.
Ein Blick auf den Anforderungskatalog zeigt, dass die Grundarchitektur im Wesentlichen um zwei neue Konzepte zu erweitern war:
• Es wird explizit zwischen Projekten unter Versionskontrolle und solchen, bei
denen dies nicht der Fall ist, unterschieden.
• Einer Sitzung kann eine flexible Zahl von Projekten zugeordnet werden. Diese
Zahl kann sich im Verlauf der Sitzung a¨ndern.
¨
Die zur Einf¨
uhrung dieser Konzepte ben¨otigten Anderungen
lassen sich am u
¨bersichtlichsten in vier Einzelgruppen betrachten:
Replikation: Um Ressourcen unter Versionskontrolle replizieren zu k¨onnen, wird
ein neuer Typ replizierter Elemente verwendet, der die bestehenden replizierten Ressourcen um Felder f¨
ur Revisions- und Synchronisationsinformationen
erweitert.
Urspr¨
unglich war es in XPairtise nicht n¨otig, Informationen u
¨ber den Typ
eines Projektes explizit zu replizieren. Statt dessen wurde lediglich der Name des Projektes als weiteres Feld in die Replikation der Sitzungsdaten
mit einbezogen. Um nun weitere Informationen u
¨ber Projekte replizieren
33
5. L¨osungskonzept
zu k¨onnen, werden eigenst¨andige replizierte Elemente verwendet, die die
beiden m¨oglichen Projekttypen beschreiben. Im Falle von Projekten unter
Versionskontrolle enthalten sie neben dem Projektnamen zus¨atzlich die ben¨otigten Informationen des verwendeten Versionsverwaltungssystems. Die
replizierten Sitzungsinformationen k¨onnen mit mehreren dieser Elemente
versehen werden, um die Zuordnung mehrerer Projekte zu einer Sitzung zu
beschreiben.
ur das Hinzuf¨
ugen von Projekten existierten urspr¨
unglich keine eiNetzwerk: F¨
genst¨andigen Nachrichtentypen. Statt dessen wurden die Projektdaten direkt
in der Nachricht zur Erzeugung einer neuen Sitzung u
¨bertragen. Um die
flexible Zuordnung von Projekten zu Sitzungen zu erlauben, werden die
¨
Sitzungserstellung und die Ubertragung
von Projektdaten nun getrennt und
separate Nachrichtentypen f¨
ur das Hinzuf¨
ugen und Entfernen von Projekten
verwendet. Erstere liegen in zwei unterschiedlichen Varianten f¨
ur die beiden
unterst¨
utzten Projekttypen vor. Außerdem sind weitere neue Nachrichtenty¨
pen f¨
ur den Versand von Anderungen
an Ressourcen unter Versionskontrolle
zust¨andig.
Server: Serverseitig zeichnet sich der ResourceManager verantwortlich f¨
ur die
zentrale Verwaltung aller verteilten Projekte. Hier werden die ben¨otigten
replizierten Listen angelegt, mit replizierten Ressourcen gef¨
ullt und im Laufe
einer Sitzung kontinuierlich aktualisiert. Dies geschieht in einzelnen Methoden,
die in direkter Relation zu den eben beschriebenen Nachrichten stehen. Neue
¨
Methoden erweitern diese Gruppe, um die Behandlung von Anderungen
an
Ressourcen unter Versionskontrolle abzudecken.
Um sp¨atere Aktualisierungen daran durchf¨
uhren zu k¨onnen, werden Referenzen auf alle erzeugten replizierten Listen und Ressourcen in einigen zentralen
Datenstrukturen gespeichert. Die urspr¨
ungliche Organisation dieser Datenstrukturen eignete sich nicht f¨
ur die Verwaltung mehrerer Projekte in einer
einzelnen Sitzung und machte daher entsprechende Anpassungen n¨otig.
Client: Clientseitig erfolgte die Synchronisation der Ressourcen des aktuellen
Projektes urspr¨
unglich komplett im zentralen ClientResourceManager. Zu
den in dieser Klasse implementierten Teilfunktionen geh¨orten die Indizierung
des lokalen Projektinhaltes bei Sitzungsbeitritt, die initiale Synchronisation
dieses Inhaltes mit dem Server, die Modifikation einzelner Ressourcen bei
¨
empfangenen Aktualisierungen sowie der Versand lokal erkannter Anderungen
an den Server.
Der Versuch, diese Klasse lediglich um die neuen Konzepte zu erweitern, h¨atte
die Komplexit¨at dieser Klasse gravierend erh¨oht und Les- und Wartbarkeit
stark beeintr¨achtigt. Die Wahl fiel statt dessen auf eine weiter reichende
¨
Uberarbeitung
der Clientseite, die diese Funktionen auf einzelne Klassen
aufteilt.
34
5.2 Integration von Versionsverwaltungssystemen
Insbesondere wird die Verwaltung der zu einem Projekt geh¨orenden Ressourcen komplett in einer eigenen Klasse gekapselt, deren Instanzen jeweils
einem einzelnen Projekt entsprechen. Die Hauptaufgabe des ClientResourceManager beschr¨ankt sich in diesem Modell lediglich auf die Erzeugung und
Verwaltung dieser Instanzen. F¨
ur die Durchf¨
uhrung von Synchronisationsaufgaben und Modifikationen lokaler Ressourcen sind außerdem eigene Hilfsklassen zust¨andig.
5.2 Integration von Versionsverwaltungssystemen
¨
Nachdem im letzten Abschnitt auf die n¨otigen Anderungen
an der Grundarchitektur
eingegangen wurde, werden im Folgenden zun¨achst einige Fragen der Integration
von Versionsverwaltungssystemen auf Clientseite gesondert behandelt, bevor in
Abschnitt 5.3 auf die L¨osungsans¨atze der herausgearbeiteten Anforderungen im
Einzelnen eingegangen wird.
5.2.1 Die Eclipse Team API
Die Eclipse Team API definiert einheitliche Schnittstellen, die es Plug-ins erm¨oglichen, einige wichtige der von Versionsverwaltungssystemen gebotenen Dienste,
unabh¨angig vom Typ und der internen Implementierung des f¨
ur die Anbindung an
das Repository zust¨andigen Plug-ins, in Anspruch zu nehmen. Die Komponenten
der Eclipse Team API teilen sich in vier Hauptgruppen auf (vgl. [Tea08]):
Repository Provider: Repository Provider stellen die zentrale Komponente der
Anbindung an ein Repository dar. Jedem lokalen Projekt ist h¨ochstens ein
Repository Provider zugeordnet. Diese Zuordnung wird u
¨ber entsprechende
statische Methoden der abstrakten Klasse RepositoryProvider gesteuert.
Ein Repository Provider k¨
ummert sich um die Synchronisation des ihm
zugeordneten Projektes mit dem Repository. Optional kann ein Repository
Provider lokale Modifikationen an den Ressourcen des Projektes kontrollieren.
Durch die Bereitstellung einer entsprechenden Implementierung der IFileModificationValidator-Schnittstelle kann so zum Beispiel pessimistische
Nebenl¨aufigkeitskontrolle erreicht werden.
Ressourcen-Verwaltung: Plug-ins k¨onnen einem Repository Provider Hinweise
u
¨ber spezielle Eigenschaften der von ihm kontrollierten Ressourcen geben. So
lassen sich Ressourcen als team-spezifisch (team-private) markieren, um sie
vor anderen Plug-ins zu verbergen. Sinnvoll ist dies vor allem f¨
ur Dateien, die
das Versionsverwaltungssystem zur Speicherung seiner Metadaten verwendet.
35
5. L¨osungskonzept
Fl¨
uchtige Ressourcen, etwa durch den Compiler erzeugte Objekt-Dateien, lassen sich als abgeleitet (derived ) markieren, um sie von der Versionsverwaltung
auszuschließen.
¨
Synchronisation: Uber
einen Subscriber erhalten Plug-ins Informationen u
¨ber
den Synchronisationsstatus des von einem Repository Provider kontrollierten
Projektes. Der Status einer einzelnen Ressource wird hierbei jeweils durch
ein entsprechendes SyncInfo-Objekt beschrieben, das Auskunft u
¨ber die
¨
lokale Basisrevision und eventuelle Anderungen der Ressource gegen¨
uber dem
¨
Repository gibt. Neben dem Typ einer Anderung beinhaltet dies im u
¨blichen
¨
Fall eines Drei-Wege-Vergleichs auch die Richtung der Anderung.
Integration logischer Modelle: Plug-ins k¨onnen eine Repository-Anbindung in
die Zusammenstellung und Darstellung ihrer logischen Modelle mit einbeziehen. So wird etwa mit Hilfe der File System API die Durchsuchung von
Inhalten im Repository (Remote Browsing) und mit Hilfe der File History
API der Zugriff auf die komplette Historie einzelner Ressourcen erm¨oglicht.
Der Umfang der Team API nimmt regelm¨aßig zu. Die f¨
ur die Anbindung an
Versionsverwaltungssysteme zust¨andigen Plug-ins unterscheiden sich in Bezug auf
die durch sie implementierte Teilmenge der Team API jedoch zum Teil recht
deutlich. Die weitreichendste Unterst¨
utzung ist im CVS-Plug-in gegeben, da dieses
von den Eclipse-Entwicklern selbst gepflegt wird. Dem Eclipse-Jargon folgend
werden diese Plug-ins im Folgenden als Team Provider bezeichnet.
5.2.2 Wahl des Integrationsansatzes
Die vollst¨andige Funktionalit¨at der verschiedenen Versionsverwaltungssysteme ist
nur u
ugbar.
¨ber spezifische Funktionen der entsprechenden Team Provider verf¨
Lediglich eine Teilmenge dieser Funktionen ist dar¨
uber hinaus u
¨ber die generische
Team API verf¨
ugbar. Es stellte sich zun¨achst die Frage, ob diese Teilmenge bereits
ausreicht, um die in Kapitel 3 herausgearbeiteten Anforderungen zu erf¨
ullen. Eine
ausschließlich mit Hilfe der Team API realisierte L¨osung h¨atte vor allem zwei
Vorteile:
• Sie w¨are weitgehend unabh¨angig vom tats¨achlich verwendeten Versionsverwaltungssystem. Dies setzt allerdings voraus, dass der verwendete Team
Provider auch alle ben¨otigten Schnittstellen der Team API implementiert.
• N¨otige Anpassungen der Implementierung beim Wechsel auf neuere Versionen
von Eclipse oder der verwendeten Team Provider w¨aren unwahrscheinlicher,
da die Team API zum ¨offentlichen Teil der Eclipse API geh¨ort und gravierende
¨
Anderungen
der Schnittstellen damit weniger wahrscheinlich sind.
36
5.2 Integration von Versionsverwaltungssystemen
Aus dem Anforderungskatalog (siehe Abschnitt 3.3) sind schnell die Funktionen von
Versionsverwaltungssystemen ersichtlich, die f¨
ur die n¨otigen Erweiterungen relevant
sind. Die folgende Auflistung geht auf diese Funktionen und ihre Realisierbarkeit
u
¨ber die Team API ein.
ussen
• Revisions- und Synchronisationsinformationen einzelner Ressourcen m¨
zur Verf¨
ugung stehen (Anforderung A03). Diese Informationen sind u
¨ber
die im letzten Abschnitt beschriebenen SyncInfo-Objekte problemlos verf¨
ugbar.
• Repository-Informationen m¨
ussen repliziert und f¨
ur den Checkout kompletter Projekte verwendet werden k¨onnen (Anforderungen A04 und A05).
Diese Funktion ließe sich u
¨ber die ProjectSetCapability erreichen. Damit l¨asst sich zu einem unter Versionsverwaltung stehenden Projekt ein
Referenz-String erzeugen, der im wesentlichen die Repository-URL des Projektes enth¨alt. Dieser String ließe sich replizieren, um ihn bei anderen Teilnehmern zum Importieren des Projektes zu verwenden. Intern realisiert
der verwendete Team Provider diesen Import als Checkout des Projektes.
Leider l¨asst sich auf diese Weise nur ein Checkout des letzten Standes eines Projektes erreichen. Die M¨oglichkeit, gezielt ¨altere St¨ande beziehen zu
k¨onnen, ist f¨
ur den Einsatz in XPairtise jedoch w¨
unschenswert. Dies l¨asst
sich nur u
¨ber die spezifischen Funktionen der verschiedenen Team Provider
erreichen.
• Als problematisch erweisen sich Updates einzelner Ressourcen oder ganzer
Projekte auf bestimmte Revisionen (Anforderung A06). Diese Funktion ist
f¨
ur die n¨otigen Erweiterungen essentiell, ist jedoch nur u
¨ber die spezifischen
Funktionen der Team Provider vollst¨andig verf¨
ugbar. Eine direkte Verf¨
ugbarkeit u
¨ber die Team API war zum Zeitpunkt dieser Ausarbeitung nicht
erkennbar.
Mit Hilfe der seit Eclipse 3.2 definierten File History API l¨asst sie sich
zumindest f¨
ur einzelne Ressourcen jedoch wenigstens n¨aherungsweise erreichen. Ist diese API durch den verwendeten Team Provider implementiert, kann u
¨ber die Historie auf beliebige Revisionen einzelner Dateien
und deren Inhalt zugegriffen werden. Mit diesem Inhalt kann dann zwar
die lokale Datei u
¨berschrieben werden, die im Zuge eines regul¨aren Updates durchgef¨
uhrte Aktualisierung der lokal gespeicherten Metadaten des
Versionsverwaltungssystems bleibt jedoch aus. Aus Sicht der Versionsverwaltung stellt diese Vorgehensweise also kein Update auf eine andere Revision dar, sondern eine lokale Modifikation bei gleichbleibender Revision.
Dies h¨atte zwangsl¨aufig Inkonsistenzen der verf¨
ugbaren Revisions- und Synchronisationsinformationen zur Folge, so dass diese nicht mehr ohne weiteres
37
5. L¨osungskonzept
als Grundlage f¨
ur die weitere Synchronisation der betroffenen Ressourcen mit
dem XPairtise-Server dienen k¨onnten. F¨
ur XPairtise erwies sich diese Alternative daher als nicht ausreichend. Hinzu kommt, dass die File History API
bisher nicht von allen Team Providern implementiert wird. Zum Zeitpunkt
dieser Ausarbeitung war dies zwar beim CVS-Plug-in der Fall, bei Subclipse
jedoch noch nicht. Dies soll allerdings im Zuge eines Google-Summer-of-CodeProjektes nachgeholt werden (vgl. [SoC08]).
• Lokal modifizierte Ressourcen sollten sich in ihren Grundzustand zur¨
uckf¨
uhren lassen (Anforderung A07). Auch diese Funktion ist u
¨ber die Team
API nicht direkt verf¨
ugbar. Eine Ann¨aherung daran ist jedoch unproblematischer als im Falle eines Updates, da kein Wechsel der Basisrevision n¨otig ist. Die f¨
ur diese Operation ben¨otigte Basisrevision ist direkt
u
ugbar. Eine Unterst¨
utzung der
¨ber entsprechende SyncInfo-Objekte verf¨
File History API durch den Team Provider ist in diesem Fall nicht n¨otig.
XecliP verwendet einen ausschließlich auf Grundlage der Team API implementierten
Ansatz. Von den soeben besprochenen F¨allen ist in diesem Fall nur das Update
von Ressourcen relevant. XecliP verwendet hier die beschriebene Ann¨aherung
u
¨ber die File History API. Da XecliP die Synchronisation jeder Ressource jedoch
nur einmalig bei Sitzungsbeitritt durchf¨
uhrt (vgl. Abschnitt 4.2.1), kommen die
beschriebenen Folgeprobleme dort allerdings weniger zu tragen. Obwohl es offiziell
ausschließlich f¨
ur die Verwendung mit CVS-Projekten ausgelegt ist, d¨
urfte sich
XecliP demnach auch in Verbindung mit anderen Team Providern verwenden
lassen, sofern sie die File History API implementieren. Dies wurde allerdings nicht
explizit getestet.
Haupts¨achlich aufgrund der geschilderten Probleme im Update-Fall und der deutlichen Unterschiede bei der Vollst¨andigkeit der verschiedenen Implementierungen
der Team API fiel die Entscheidung im Falle von XPairtise jedoch gegen eine
Implementierung, die ausschließlich mit Mitteln der Team API auskommt. Statt
dessen findet ein hybrider Ansatz Verwendung, der nur all die Funktionen mittels
Team API realisiert, bei denen es sinnvoll und problemlos m¨oglich erschien. Dieser
Teil wird in Form einer abstrakten Basisklasse realisiert. Diese wird durch Klassen
erweitert, die die fehlende Funktionalit¨at mit Hilfe der spezifischen Mechanismen
der konkreten Team Provider realisiert. Auf diese Weise kann der volle gew¨
unschte
Funktionsumfang erreicht werden.
Dieses Konzept ist zwar nicht mehr unabh¨angig vom verwendeten Versionsverwaltungssystem, kann aber relativ schnell um Unterst¨
utzung f¨
ur weitere Team Provider
erweitert werden. Zuk¨
unftige Erweiterungen der Team API k¨onnten dies noch
erleichtern, wenn dadurch zus¨atzliche Funktionalit¨at in die Basisklasse verschoben
werden kann.
38
5.3 Umsetzung der Anforderungen
5.2.3 Wahl des Subversion-Plug-ins
Die Entscheidung gegen eine generische Implementierung, die nur auf die Team
API gest¨
utzt ist, macht es n¨otig, eine Auswahl der zu unterst¨
utzenden Team
Provider zu treffen. Die Anforderungen schreiben sowohl CVS- als auch SubversionUnterst¨
utzung vor. Das CVS-Plug-in wird direkt mit der Eclipse IDE ausgeliefert
und ist weitgehend ohne Alternative. Anders verh¨alt es sich mit Subversion. Hier
gibt es einerseits Subclipse [SCL08], das wie Subversion selbst durch CollabNet
entwickelt wird, andererseits das urspr¨
unglich von Pollarion entwickelte Subversive.
Beides sind Open-Source-Projekte und unterscheiden sich in Funktionsumfang
und Bedienung nicht deutlich. Die Wahl fiel auf Subclipse, da es im Zuge der
Entwicklung von XPairtise von allen beteiligten Entwicklern erfolgreich eingesetzt
wird und sich bereits mehr etabliert hat als das j¨
ungere Subversive. So deutet
eine nicht repr¨asentative Web-Recherche darauf hin, dass Subclipse zum Zeitpunkt
dieser Ausarbeitung einen deutlich h¨oheren Verbreitungsgrad besitzt als Subversive.
Dies k¨onnte sich allerdings zuk¨
unftig ¨andern, da Subversive seit November 2007 als
offizielles Eclipse-Projekt weitergef¨
uhrt wird [SVE08]. Eine zuk¨
unftige Erweiterung
um eine zus¨atzliche Implementierung auf Grundlage von Subversive erscheint daher
reizvoll.
5.3 Umsetzung der Anforderungen
Nachdem in den letzten Abschnitten auf einige der konzeptuellen Grundfragen im
Detail eingegangen wurde, werden in diesem Abschnitt nun die L¨osungskonzepte
der in Abschnitt 3.3 zusammengefassten Anforderungen im Einzelnen skizziert.
A01 / Erkennung einer Repository-Anbindung: Um Projekte unter Kontrolle
eines Versionsverwaltungssystems gesondert behandeln zu k¨onnen, m¨
ussen
diese zun¨achst als solche erkannt werden. Dies l¨asst sich leicht mittels entsprechender statischer Methoden der Klasse RepositoryProvider erreichen,
die zu einem gegebenen Projekt den ihm zugeordneten Repository Provider
liefern. Erh¨alt man ein g¨
ultiges Ergebnis, steht das Projekt unter Versionskontrolle. In diesem Fall ist nur noch zu pr¨
ufen, ob der erhaltene Repository
Provider einem der unterst¨
utzten Typen entspricht. Ist dies nicht der Fall,
wird die Repository-Anbindung des Projektes ignoriert und das klassische
Modell der Synchronisation verwendet.
A02 / Unterst¨
utzung von CVS und Subversion: Wie bereits im letzten Abschnitt beschrieben werden die CVS- und Subversion-Unterst¨
utzung mit
39
5. L¨osungskonzept
Hilfe spezifischer Methoden der CVS- und Subclipse-Plug-ins in separaten
Klassen realisiert. Sie erweitern eine abstrakte Basisklasse, die einen gr¨oßtm¨oglichen Teil der ben¨otigten Funktionalit¨at unter Verwendung generischer Team
API implementiert. Der Aufwand f¨
ur die Integration weiterer Versionsverwaltungssysteme beschr¨ankt sich also im Wesentlichen auf die Bereitstellung
einer entsprechenden Erweiterung dieser Basisklasse f¨
ur den neuen Team
Provider.
Die Integration und Initialisierung der f¨
ur die Unterst¨
utzung der verschiedenen Team Provider zust¨andigen Klassen erfolgt mit Hilfe eines entsprechenden
Eclipse-Erweiterungspunktes (extension point). So ist es m¨oglich, Unterst¨
utzung f¨
ur weitere Versionsverwaltungssysteme in Form separater Plug-ins
hinzuzuf¨
ugen, ohne XPairtise selbst modifizieren zu m¨
ussen. Von dieser M¨oglichkeit wird bei der Subclipse-Implementierung Gebrauch gemacht (siehe
Abschnitt 6.2).
A03 / Replikation von Revisions- und Synchronisationsinformationen: Um
¨
bei der Ubertragung
von Projekten auf den Server bei unmodifizierten Ressourcen nur die Metadaten der Versionsverwaltung u
¨bertragen zu k¨onnen,
m¨
ussen diese zun¨achst zur Verf¨
ugung stehen. Wie in Abschnitt 5.2.2 beschrieben, sind die ben¨otigten Synchronisationsinformationen u
¨ber entsprechende
SyncInfo-Objekte verf¨
ugbar. Zur effizienten Verarbeitung gr¨oßerer Mengen
dieser Objekte wird auf das SyncInfoSet-Konzept zur¨
uckgegriffen. F¨
ur die
¨
Ubertragung eines unter Versionskontrolle stehenden Projektes auf den Server
werden nun im Wesentlichen zwei Datens¨atze ben¨otigt:
1. Eine Liste aller Ressourcen des Projektes mit ihrer momentanen Basisrevision.
2. Der Inhalt aller Dateien, die im Vergleich zu ihrer Basisrevision modifiziert (dirty) sind oder die noch nicht unter Versionskontrolle stehen.
Aus diesen beiden Datens¨atzen l¨asst sich auf dem Server der komplette
Zustand des Projektes in Form entsprechender replizierter Ressourcen reproduzieren, ohne daf¨
ur den gesamten Projektinhalt u
ussen.
¨bertragen zu m¨
A04 / Replikation von Repository-Informationen: In Abschnitt 5.1 wurde bereits beschrieben, in welcher Form nun weitere grundlegende Informationen
u
¨ber ein Projekt repliziert werden. Neben dem Namen eines Projektes beinhalten diese Informationen zun¨achst seinen Typ. Hier wird also zwischen
CVS-Projekten, Subversion-Projekten und Projekten ohne Versionskontrolle unterschieden. Bei Projekten unter Versionskontrolle ist zus¨atzlich ihre
Repository-URL und geeignete globale Revisionsinformationen zu erfassen.
Die URL ist u
ugbar. Glei¨ber Methoden der jeweiligen Team Provider verf¨
ches gilt im Falle von Subversion f¨
ur die globale Projektrevision. Bei CVS
existiert eine solche globale Revision jedoch nicht. Um einen bestimmten Versionsstand eines CVS-Projektes aus dem Repository zu beziehen, muss statt
40
5.3 Umsetzung der Anforderungen
dessen mit Tags gearbeitet werden (siehe Abschnitt 2.4.1). Die replizierten
Revisionsinformationen eines Projektes beschreiben im Falle von CVS daher
einen entsprechenden CVS-Tag.
Ist ein solcher Tag beim zu replizierenden Projekt bereits vorhanden, wird
dieser verwendet. Im anderen Fall wird ein Zeitstempel verwendet, aus dem
bei Bedarf ein entsprechender Daten-Tag generiert werden kann. Dieser
Zeitstempel entspricht dem j¨
ungsten Erstellungsdatum der Basisrevisionen
aller Dateien im Projekt. Vor allem bei gr¨oßeren Projekten ist die Suche nach
diesem Zeitstempel nat¨
urlich deutlich ineffizienter als die einfache Abfrage
der globalen Revision im Falle von Subversion. Der so generierte Zeitstempel
wird außerdem mit einer Markierung versehen, die ihn als fl¨
uchtig (transient)
auszeichnet. Der Grund daf¨
ur wird im Folgenden erl¨autert.
A05 / Checkout: F¨
ur den Checkout kompletter Projekte werden die spezifischen
Implementierungen der unterst¨
utzten Team Provider verwendet. Auf diese
Weise ist auch die M¨oglichkeit gegeben, gezielt bestimmte Revisionen eines
Projektes beziehen zu k¨onnen. Im Falle von Subversion kann die replizierte
Revisionsnummer hierf¨
ur direkt verwendet werden, bei CVS sind jedoch
weitere Schritte n¨otig. Zun¨achst muss aus den replizierten Revisionsinformationen ein CVS-Tag generiert werden. Dieser wird dann f¨
ur den Checkout
des Projektes verwendet.
Wird eine CVS-Operation unter Angabe eines solchen Tags durchgef¨
uhrt,
so bleibt der Tag auch weiterhin g¨
ultig (sticky). Dies hat zur Folge, dass
in nachfolgenden Updates nur Daten bezogen werden, die von diesem Tag
auch abgedeckt werden. Insbesondere werden im Falle eines Daten-Tags
alle Daten ignoriert, die neuer als das entsprechende Datum sind. Dieses
Verhalten ist im Falle von XPairtise jedoch unerw¨
unscht. Handelte es sich
bei den replizierten Revisionsinformationen um einen als fl¨
uchtig markierten
Daten-Tag, muss dieser nach erfolgreichem Checkout von allen Ressourcen
des Projektes in einem letzten Schritt wieder entfernt werden, um diese
Folgeerscheinungen zu vermeiden. Bei gr¨oßeren Projekten kann auch dieser
Schritt recht zeitaufw¨andig sein.
A06 / Update: F¨
ur die Durchf¨
uhrung von Updates werden ebenfalls spezifische
Methoden der unterst¨
utzten Team Provider verwendet. Updates k¨onnen sich
auf komplette Projekte, Verzeichnisb¨aume oder einzelne Dateien beziehen.
Fehlt die explizite Angabe einer gew¨
unschten Revision, erfolgt ein Update auf
den letzten Stand (Head ). Im Falle von CVS sind auch hier wieder weitere
Schritte n¨otig, da Updates auf bestimmte Versionsst¨ande ebenfalls mit Hilfe
von Tags durchgef¨
uhrt werden. Die Behandlung dieser Tags entspricht im
Wesentlichen dem bereits f¨
ur die Anforderungen A05 und A06 skizzierten
Verfahren.
A07 / Revert: Die R¨
uckf¨
uhrung von Ressourcen auf ihre Basisrevision wird nur
von Subversion direkt unterst¨
utzt und ist u
¨ber entsprechende Methoden auch
41
5. L¨osungskonzept
in Subclipse verf¨
ugbar. Durch die separate Speicherung der Basisversionen
aller Projektdaten durch Subversion (siehe Abschnitt 2.4.2) ist dieser Vorgang
¨
außerdem sehr effizient m¨oglich und erfordert keine erneute Ubertragung
von
Daten aus dem Repository.
In CVS kann diese Funktionalit¨at u
¨ber ein Replace-Kommando erreicht werden, das mit einem die Basisrevision beschreibenden CVS-Tag durchgef¨
uhrt
wird. Um diese Revision zu beziehen, muss in diesem Fall allerdings das
Repository kontaktiert werden. Nach erfolgreicher Ausf¨
uhrung muss auch
hier der verwendete CVS-Tag explizit wieder entfernt werden.
¨
A08 / R¨
ucknahme unzul¨
assiger Anderungen:
F¨
uhrt der Navigator oder ein
¨
Spectator auf seinem Rechner eigenst¨andige Anderungen an den Ressourcen
eines verteilten Projektes durch, f¨
uhrt dies zu Inkonsistenzen zwischen seiner
Projektkopie und dem offiziellen Zustand des Projektes. XPairtise hat daher
¨
seit jeher die F¨ahigkeit, solche Anderungen
zu erkennen und automatisch
r¨
uckg¨angig zu machen (siehe Abschnitt 4.1).
Die daf¨
ur ben¨otigten Daten wurden bisher ausschließlich u
¨ber entsprechende
Pull-Anfragen u
ber
den
XPairtise-Server
bezogen.
Dies
ist bei der Verwen¨
dung von Projekten unter Versionskontrolle einerseits in diesem Umfang
nun nicht mehr m¨oglich, da ja nur noch die Daten komplett auf dem Server
¨
vorliegen, die Anderungen
gegen¨
uber dem Repository aufweisen, andererseits
bietet sich schon aus Gr¨
unden der Effizienz an, die Dienste des Versionsverwaltungssystems f¨
ur den Großteil dieser Aufgabe zu nutzen. Im Normalfall
wird hierf¨
ur die bereits beschriebene Revert-Funktion verwendet.
Der offizielle Stand aller zu einem Projekt geh¨orenden replizierten Ressourcen wird auf dem Client zwischengespeichert und w¨ahrend der gesamten
Sitzung aktuell gehalten. Auf Grundlage dieser Informationen und dem momentanen tats¨achlichen lokalen Zustand einer Ressource kann entschieden
werden, ob der XPairtise-Server oder das Versionsverwaltungssystem f¨
ur die
Wiederherstellung verwendet wird.
A09 / Persistenz von Metadaten: Einzelne Sitzungen sind in XPairtise beliebig
wiederverwendbar und bestehen bis sie explizit durch einen Benutzer entfernt
werden. Insbesondere sind sie auch nach einem Neustart des XPairtise-Servers
weiterhin verf¨
ugbar. Zu diesem Zweck werden die n¨otigen Informationen u
¨ber
alle aktuellen Sitzungen persistent in einer Sitzungsdatenbank gespeichert,
die beim Start des Servers eingelesen wird und als Grundlage f¨
ur eine Wiederherstellung bestehender Sitzungen dient.
Informationen u
¨ber die Ressourcen der zu den bestehenden Sitzungen geh¨orenden Projekte mussten bisher nicht explizit gespeichert werden, da alle
Projektinhalte komplett auf dem Server vorhanden waren. Beim Start des
Servers sind so lediglich die entsprechenden Verzeichnisse zu durchsuchen
und neue replizierte Ressourcen zu allen gefundenen Dateien und Verzeichnissen zu erzeugen. Bei Projekten unter Versionskontrolle funktioniert diese
42
5.3 Umsetzung der Anforderungen
Vorgehensweise nun nicht mehr, da nur ein Bruchteil der zu einem Projekt
geh¨orenden Ressourcen tats¨achlich auf dem Server vorliegt.
Statt dessen wird ein zus¨atzliches Persistenzmodell f¨
ur die Matadaten aller
Ressourcen verwendet. Die Speicherung erfolgt in Form einfacher XMLDokumente, die mittels JDOM [JDO08] erstellt werden, wie es bereits bei
den bestehenden Sitzungs- und Benutzerdatenbanken der Fall ist. Um die
Implementierung einfach zu halten, erfolgt die Organisation der Daten in nur
einer XML-Datei pro Projekt. Dies erwies sich auch bei sehr großen Projekten
als effizient genug. Die in den einzelnen Elementen dieser Dokumente gespeicherten Daten entsprechen genau den Feldern der entsprechenden replizierten
Ressourcen, was die Wiederherstellung nach einem Neustart des Servers sehr
einfach macht.
A10 / Commit-Kommentarvorlagen: Die Erzeugung von Kommentarvorlagen
¨
f¨
ur den Commit von sich in einer XPairtise-Sitzung ergebenden Anderungen
erfolgt automatisch und unabh¨angig von den einer Sitzung zugeordneten
Projekten. Sie geben Auskunft u
¨ber den Namen einer jeden Sitzung und
die Teilnehmer, die zuletzt die Rolle von Driver und Navigator einnahmen.
¨
Bei jeder Anderung
der Rollen- und Projektzuweisung einer Sitzung werden
sie entsprechend aktualisiert. Zur Registrierung und Aktualisierung dieser
Kommentarvorlagen muss auf spezifische Methoden der beteiligten Team
Provider zur¨
uckgegriffen werden.
A11 / Unterst¨
utzung von Projekten ohne Versionskontrolle: Wie bereits in
Abschnitt 5.1 beschrieben, wurde die bestehende Architektur nicht grundlegend ge¨andert, sondern lediglich um neue Konzepte erweitert. Das gew¨ahrleistet auch, dass die Verwendbarkeit von Projekten, die nicht unter
Versionskontrolle stehen, weiterhin in gewohntem Maße gegeben ist. Dies
wird als wichtig erachtet, um die H¨
urden f¨
ur die Nutzung von XPairtise
m¨oglichst niedrig zu halten und die Verwendung des Plug-ins einer m¨oglichst
großen Zielgruppe zu erlauben.
A12 / Erstellung von Sicherheitskopien: Bevor ein lokales Projekt in einer Sitzung verwendet wird, kann optional eine Sicherheitskopie des urspr¨
unglichen
Projektzustandes erstellt werden. Bei verlassen der Sitzung kann diese bei
Bedarf wieder zur¨
uckgespielt werden, um den Ursprungszustand wiederherzustellen. Eine solche Sicherheitskopie entsprach bisher einem ZIP-Archiv
des kompletten Projektes.
In Verbindung mit Projekten unter Versionskontrolle ist dieser Mechanismus
nicht mehr verwendbar, da die separat gespeicherten Metadaten der Versionsverwaltung nicht Teil des Archivs sind. Werden im Laufe einer Sitzungen
¨
Anderungen
durchgef¨
uhrt, die diese Metadaten ¨andern, f¨
uhrt ein sp¨ateres
Zur¨
uckspielen der Sicherungskopie zu Inkonsistenzen zwischen den Metadaten
und den tats¨achlichen Projektdaten.
43
5. L¨osungskonzept
Daher wird f¨
ur diesen Fall ein alternativer Mechanismus bereitgestellt, der
nicht mehr das gesamte Projekt, sondern nur noch im Vergleich zum Repository ver¨anderte Daten sichert. Zus¨atzlich werden die Repository-URL
und die globale Revision des Projektes in die Sicherheitskopie mit aufgenommen. Das Zur¨
uckspielen dieser Sicherheitskopie besteht nun in der
Entfernung des bisherigen Projektes, einem erneuten Checkout des Projektes aus dem Repository und dem Extrahieren der modifizierten Daten.
¨
¨
N¨otige Anderungen
an der lokalen DatenA13 / Anzeige n¨
otiger Anderungen:
basis wurden w¨ahrend der initialen Synchronisation bisher direkt bei Empfang
der entsprechenden replizierten Ressourcen vorgenommen. Um dem Benutzer
die Unterschiede zwischen dem lokalen und dem in der Sitzung g¨
ultigen
Datenbestand erst zur Best¨atigung anzeigen zu k¨onnen, wird nun statt dessen eine Zwischenspeicherung aller w¨ahrend der initialen Synchronisation
empfangenen replizierten Ressourcen verwendet.
Die empfangenen Daten werden dann mit den lokalen Projektdaten abgeglichen und die Ergebnisse dem Benutzer in einem entsprechenden Dialog
¨
pr¨asentiert. Erst wenn die n¨otigen Anderungen
durch den Benutzer best¨atigt
wurden, werden sie durchgef¨
uhrt. Der Driver hat in diesem Dialog dar¨
uber
¨
hinaus außerdem die Wahl, statt dessen seine lokalen Anderungen
noch in
die Sitzung einfließen zu lassen.
A14 / Projektzuordnung bei Sitzungserstellung: Auf die f¨
ur die Zuordnung
¨
mehrerer Projekte zu einer Sitzung n¨otigen Anderungen an der grundlegenden Architektur wurde bereits in Abschnitt 5.1 eingegangen. Da die
¨
Erstellung einer Sitzung und die Ubertragung
von Projekten auf den Server
auf dieser Ebene nun komplett getrennt werden, ist auch die Unterst¨
utzung
von Sitzungen ohne zugeordnete Projekte kein Problem. Ein umgestalteter
Projektauswahldialog erlaubt dem Benutzer eine entsprechend flexible Auswahl von Projekten bei Sitzungserstellung. Die Anzeige mehrerer Projekte in
einer Sitzung wird durch entsprechende Erweiterungen der Sitzungs¨
ubersicht
erm¨oglicht.
A15 / Hinzuf¨
ugen von Projekten: Die architektonischen Grundlagen f¨
ur das
nachtr¨agliche Hinzuf¨
ugen von Projekten zu bestehenden Sitzungen sind
im Wesentlichen die gleichen, wie bei der Auswahl mehrerer Projekte bei
Sitzungserstellung. Dem Benutzer wird diese F¨ahigkeit u
¨ber einen entsprechenden, u
u der Sitzungs¨
ubersicht erreichbaren,
¨ber das Kontextmen¨
¨
Auswahldialog erm¨oglicht. Uber
diesen lassen sich auch mehrerer Projekte
gleichzeitig zu einer Sitzung hinzuf¨
ugen. Die Verwendbarkeit dieser Funktion h¨angt vom aktuellen Status einer Sitzung ab. Ist noch kein Benutzer
der Sitzung beigetreten, steht es jedem frei, zus¨atzliche Projekte der Sitzung hinzuzuf¨
ugen. Im anderen Fall ist dies nur dem Driver der Sitzung
erlaubt.
44
5.3 Umsetzung der Anforderungen
¨
A16 / Entfernen von Projekten: Uber
einen weiteren Auswahldialog lassen sich
außerdem Projekte aus bestehenden Sitzungen entfernen. Die Verwendbarkeit dieser Funktion h¨angt wiederum vom aktuellen Status einer Sitzung ab.
Ist momentan kein Benutzer der Sitzung beigetreten, ist es jedem erlaubt,
Projekte aus einer Sitzung zu entfernen. Im anderen Fall ist dies nur dem
Driver der Sitzung erlaubt. Hierf¨
ur m¨
ussen zuvor außerdem alle mit den
Projekten assoziierten Editoren geschlossen werden.
45
6 Details der Umsetzung
Nachdem in den letzten Kapiteln die Kernanforderungen hergeleitet und L¨osungsans¨atze daf¨
ur herausgearbeitet wurden, geht dieses Kapitel auf die daraus
resultierende Implementierung der Erweiterungen ein.
¨
6.1 Ubersicht
u
¨ber die Implementierung
Die n¨otigen Erweiterungen wurden direkt an der bestehenden Codebasis von
¨
XPairtise vorgenommen. Abbildung 6.1 gibt einen groben Uberblick
u
¨ber die Paket¨
struktur von XPairtise und die Verteilung der daran vorgenommenen Anderungen.
¨
Die verschiedenen Intensit¨aten dieser Anderungen sind hierbei durch drei Grauabstufungen angedeutet. In den hellen Bereichen waren haupts¨achlich Erweiterungen
bestehender Funktionalit¨at n¨otig, die mittlere Abstufung weist auf weitreichendere
¨
Anderungen
bestehender Funktionalit¨at oder neue Teilkomponenten hin, die dunkel
eingef¨arbten Pakete sind neu hinzugekommen. Die folgenden Abschnitte gehen auf
den relevanten Teil der in den einzelnen Paketen vorgenommenen Erweiterungen
nun detaillierter ein.
6.1.1 Paket de.fuh.xpairtise.common.network
Dieses Paket stellt die f¨
ur die Netzwerkkommunikation zust¨andigen Komponenten
zur Verf¨
ugung. Dies sind im Wesentlichen die Schnittstellen f¨
ur den Versand
verschiedener Nachrichten zwischen Client und Server sowie entsprechende Listener,
um auf Empf¨angerseite auf diese Nachrichten reagieren zu k¨onnen. Im Unterpaket
imp befinden sich Implementierungen dieser Schnittstellen auf Basis von ActiveMQ
sowie f¨
ur den f¨
ur Testzwecke vorgesehenen Loopback-Modus.
Im Zuge dieser Arbeit wurden vor allem die Schnittstellen IServerCommandInterface und IServerCommandListener erweitert. Es wurden neue Nachrich¨
tentypen f¨
ur den Versand von Anderungen
an Ressourcen unter Versionskontrolle
¨
sowie f¨
ur das Hinzuf¨
ugen und Entfernen verteilter Projekte hinzugef¨
ugt. Die Ubertragung von Projekten auf den Server wurde hierbei komplett von der Nachricht
47
6. Details der Umsetzung
¨
Abbildung 6.1: Verteilung der Anderungen
auf die Paketstruktur von XPairtise
f¨
ur die Erstellung einer Sitzung getrennt. Letztere transportiert nun keine Projektinformationen mehr, sondern nur noch einen Indikator, der angibt, wie viele
Projekte direkt im Anschluss u
¨bertragen werden, bevor die Sitzung als erfolgreich
erstellt gilt.
¨
F¨
ur die Ubertragung
von Projekten finden zwei unterschiedliche Nachrichtentypen
Verwendung, abh¨angig davon, ob das betreffende Projekt unter Versionskontrolle
steht oder nicht. Im ersten Fall wird neben dem Namen des Projektes nun seine
Repository-URL, ein globaler Revisionsbezeichner sowie eine Liste aller zum Projekt
geh¨orenden Ressourcen und ihrer Basisrevision u
¨bertragen. Komplette Inhalte
m¨
ussen in diesem Fall nur von den Dateien u
¨bertragen werden, die im Vergleich
zur Basisrevision bereits modifiziert wurden. Steht das zu u
¨bertragende Projekt
nicht unter Versionskontrolle, wird weiterhin der gesamte Inhalt des Projektes
u
¨bertragen.
6.1.2 Paket de.fuh.xpairtise.common.replication.elements
In diesem Paket werden die verschiedenen Typen replizierter Elemente als zentrales
Applikationsmodell von XPairtise definiert. Alle hier definierten Elemente sind
48
¨
6.1 Ubersicht
u
¨ber die Implementierung
Unterklassen der Basisklasse ReplicatedListElement, die ihrerseits die Klasse
ReplicatedObject erweitert.
Das neue replizierte Element ReplicatedVCResource erweitert das bestehende
Element ReplicatedResource um Revisionsinformationen von Ressourcen unter
Versionskontrolle. In Kombination mit der bereits im ReplicatedResource-Element vorgesehenen Pr¨
ufsumme l¨asst sich damit der genaue Synchronisationsstatus
einer Ressource unter Versionskontrolle ableiten. Sind sowohl der Revisionsbezeichner als auch die Pr¨
ufsumme gegeben, wird eine im Vergleich zu ihrer Basisrevision
modifizierte (dirty) Ressource beschrieben. Fehlt die Pr¨
ufsumme, handelt es sich
um eine unmodifizierte Ressource. Fehlt hingegen der Revisionsbezeichner bei
vorhandener Pr¨
ufsumme, existiert die beschriebene Ressource bisher nicht im
Repository. Dar¨
uber hinaus l¨asst sich eine Ressource als remoteOnly markieren.
Dies beschreibt eine Ressource, die zwar im Repository, nicht aber lokal existiert. Das ist vor allem dann der Fall, wenn die beschriebene Ressource lokal
¨
gel¨oscht wurde, diese Anderung
jedoch noch nicht ins Repository u
¨bertragen
wurde.
Wie bereits in Abschnitt 5.1 beschrieben, ist es n¨otig, neben dem Namen eines
Projektes nun auch weitere Informationen u
¨ber seinen Typ replizieren zu k¨onnen. Zu
diesem Zweck wurden die Elemente ReplicatedProjectInfo und ReplicatedVCProjectInfo eingef¨
uhrt. ReplicatedProjectInfo-Elemente beschreiben Projekte
ohne Versionskontrolle. Diese werden weiterhin nur durch ihren Namen beschrieben.
ReplicatedVCProjectInfo ist eine Unterklasse der Klasse ReplicatedProjectInfo und erweitert diese um weitere Felder zur Beschreibung von Projekten unter
Versionskontrolle.
Im einzelnen sind dies der Typ des verwendeten Versionsverwaltungssystems, die
Repository-URL, von der das Projekt bezogen werden kann, und globale Revisionsinformationen. Das bestehende Element ReplicatedXPSession, welches
grundlegende Informationen u
¨ber einzelne Pair-Programming-Sitzungen zusammenfasst, wurde um eine dynamisch ver¨anderbare Liste dieser Elemente erweitert,
um wechselnde Projektzuordnungen zu einer Sitzung replizieren zu k¨onnen.
6.1.3 Paket de.fuh.xpairtise.common.util
Hier finden sich allgemeine Hilfsklassen, die Funktionen bereitstellten, die sowohl
auf Client- als auch auf Serverseite Verwendung finden. Bei der Erstellung von
¨
Sicherheitskopien auf Clientseite und f¨
ur die Ubertragung
von Projektdaten auf
den Server werden Archive im ZIP-Format verwendet. Um Redundanz in der
Codebasis zu reduzieren, wurden die bisher teilweise in ¨ahnlicher Form sowohl auf
dem Client als auch auf dem Server vorhandenen Funktionen zum Erstellen und
49
6. Details der Umsetzung
Extrahieren dieser Archive in flexiblerer Form in der neuen Hilfsklasse SnapshotUtils zusammengefasst.
Die Lokale Sicherheitskopie eines Projektes unter Versionskontrolle muss zus¨atzlich
die Repository-URL und die Revision des Projektes enthalten, um das Projekt
bei einer Wiederherstellung zun¨achst komplett aus dem Repository beziehen zu
k¨onnen (vgl. Abschnitt 5.3, Anforderung A12). Den Funktionen zur Erstellung
eines Archivs kann daher als optionales Argument ein entsprechendes ReplicatedVCProjectInfo-Element u
¨bergeben werden. Dieses wird serialisiert und als erster
Eintrag in das Archiv mit aufgenommen.
6.1.4 Paket de.fuh.xpairtise.plugin.core
Dieses Paket fasst die Klassen zusammen, die die clientseitige Kernfunktionalit¨at
von XPairtise bilden. Als Gegenst¨
uck zur bestehenden Klasse ClientUserManager
wurde die Klasse ClientXPSessionManager eingef¨
uhrt, um anderen Komponenten Informationen u
ugbar zu
¨ber die momentan aktive Sitzung problemloser verf¨
machen. Hierzu geh¨oren der Name und die Identifikationsnummer der Sitzung, die
Liste der teilnehmenden Benutzer, die momentane Zuweisung der Benutzerrollen
¨
und die Liste der zur Sitzung geh¨orenden Projekte. Uber
eine Implementierung der
IReplicatedListEventReceiver-Schnittstelle empf¨angt der ClientXPSession¨
Manager Anderungen
dieser Informationen u
¨ber die zur Verteilung von Sitzungsinformationen verwendete replizierte Liste. Andere clientseitige Komponenten
k¨onnen durch Registrierung einer passenden Implementierung der IClientXP¨
SessionChangeListener-Schnittstelle ebenfalls zeitnah u
¨ber diese Anderungen
informiert werden.
6.1.5 Paket de.fuh.xpairtise.plugin.core.resources
Dieses Paket wurde neu hinzugef¨
ugt, um alle f¨
ur den Umgang mit Ressourcen im
Eclipse-Arbeitsbereich ausgelegten Klassen zusammenzufassen. Die clientseitige
Verwaltung der empfangenen replizierten Ressourcen und die Wahrung der Konsistenz der lokalen Ressourcen mit ihnen wurde in eigenst¨andige Klassen ausgelagert.
Die Schnittstelle ISharedProject definiert die ¨offentlichen Methoden dieser Klassen. Dies sind vor allem Methoden f¨
ur das Hinzuf¨
ugen, Aktualisieren und Entfernen
sowie die Abfrage des Synchronisationsstatus einzelner Ressourcen.
Einen Großteil der ISharedProject-Schnittstelle implementiert die abstrakte
Klasse AbstractSharedProject. Sie verwirklicht insbesondere die gesamte Verwaltungsfunktionalit¨at. Die konkreten Implementierungen SharedProject und
50
¨
6.1 Ubersicht
u
¨ber die Implementierung
SharedVCProject erweitern diese Klasse um die vom Projekttyp abh¨angigen Synchronisationsmechanismen, steuern also die Angleichung der lokalen Ressourcen an
den in der Sitzung g¨
ultigen Stand. W¨ahrend der Initialisierung einer Instanz einer
dieser Implementierungen wird der lokale Inhalt des zugeh¨origen Projektes indiziert
und eine initiale Datenbasis mit Informationen u
¨ber die gefundenen Ressourcen aufgebaut. Diese muss im Folgenden mit den vom Server stammenden Informationen
abgeglichen und n¨otige Modifikationen vorgenommen werden. Um dem Benutzer vor der Durchf¨
uhrung dieser Modifikationen weitere Eingriffsm¨oglichkeiten zu
erlauben, wurde eine Zwischenspeicherung der initial vom Server empfangenen
Ressourcen hinzugef¨
ugt, deren Inhalt mit Hilfe einer entsprechenden Funktion
¨
zun¨achst mit dem lokalen Bestand verglichen werden kann, ohne Anderungen
unmittelbar durchzuf¨
uhren.
ClientResourceManager
+shareProject()
+unshareProject()
+getSharedProject()
1
0..n
«Interface»
ISharedProject
+addOrUpdateResource()
+removeResource()
+hasResource()
«use»
SharedProjectFactory
+createSharedProject()
AbstractSharedProject
«create»
«create»
SharedProject
SharedVCProject
Abbildung 6.2: Klassendiagramm der Verwaltung von Ressourcen auf dem Client
Die zentrale Komponente der clientseitigen Verwaltung von Ressourcen bildet nach
wie vor die Klasse ClientResourceManager. Die einzelne Instanz dieser Klasse
wird gem¨aß dem Singleton-Entwurfsmuster durch die ClientApplication initialisiert. Die Hauptaufgabe dieser Klasse besteht nun allerdings nicht mehr in der
eigenst¨andigen Synchronisation einzelner Ressourcen, sondern in der Erstellung,
Initialisierung und Verwaltung der Instanzen der verschiedenen ISharedProjectImplementierungen. Die Erstellung dieser Instanzen erfolgt mit Hilfe einer stati¨
schen Fabrikmethode der Klasse SharedProjectFactory. Um auf Anderungen
der
Zuordnung von Projekten zur momentan aktiven Sitzung reagieren zu k¨onnen, wird
eine entsprechende IClientXPSessionChangeListener-Implementierung verwen-
51
6. Details der Umsetzung
det. Abbildung 6.2 zeigt ein grobes Klassendiagramm der resultierenden Konstellation.
6.1.6 Paket de.fuh.xpairtise.plugin.core.resources.vc
In diesem Paket befinden sich die f¨
ur die Integration von Versionsverwaltungssystemen zust¨andigen Klassen. Die Schnittstelle IVersionControlClient definiert
die ¨offentlichen Methoden einfacher Clients f¨
ur die Nutzung der Dienste eines
Team Providers. Hierzu geh¨oren Methoden zur Abfrage von Synchronisations- und
Revisionsinformationen, zur Durchf¨
uhrung von Checkout-, Update- oder RevertOperationen sowie zur Registrierung von Kommentarvorlagen f¨
ur den Commit
(siehe Abbildung 6.3).
Abbildung 6.3: Commit-Dialog mit automatisch erstellter Kommentarvorlage
Die abstrakte Klasse AbstractVersionControlClient liefert Implementierungen
all jener Methoden dieser Schnittstelle, die sich ohne gr¨oßere Einschr¨ankungen mit
Hilfe generischer Team API umsetzen ließen. Die fehlenden Methoden wurden mit
Hilfe interner Funktionen der einzelnen Team Provider implementiert, wie bereits in
Abschnitt 5.2.2 angek¨
undigt. Die Klasse CVSVersionControlClient stellt die entsprechende Implementierung auf Grundlage des CVS-Plug-ins bereit. Jede Instanz
52
¨
6.1 Ubersicht
u
¨ber die Implementierung
dieser konkreten Implementierungen der IVersionControlClient-Schnittstelle ist
h¨ochstens einem einzelnen Projekt zugeordnet und wird von der entsprechenden
SharedVCProject-Instanz zur Durchf¨
uhrung anfallender Synchronisationsaufgaben
dieses Projektes mit dem Repository verwendet.
F¨
ur die Erstellung dieser Instanzen zeichnen sich statische Fabrikmethoden der
Klasse VersionControlClientFactory verantwortlich. Die tats¨achlich verf¨
ugbaren IVersionControlClient-Implementierungen werden von dieser Klasse erst zur
Laufzeit u
¨ber die IExtensionRegistry von Eclipse erfragt. Zu diesem Zweck erweitern sie den neu definierten de.fuh.xpairtise.vcClients-Erweiterungspunkt.
Dies erlaubt die flexible Erweiterung um Unterst¨
utzung weiterer Versionsverwaltungssysteme auch in Form eigener Plug-ins. Die Subclipse-Implementierung macht
bereits von dieser M¨oglichkeit Gebrauch (vgl. Abschnitt 6.2). Abbildung 6.4 zeigt
ein grobes Klassendiagramm der resultierenden Konstellation.
SharedProjectFactory
+createSharedProject()
«create»
SharedVCProject
+addOrUpdateResource()
+resetResource()
+isInSync()
1
1
«use»
«Interface»
IVersionControlClient
+isInSync()
+isDirty()
+getLocalRevision()
+update()
+revert()
+checkoutProject()
Team API
VersionControlClientFactory
+getClient()
«create»
AbstractVersionControlClient
CVSVersionControlClient
Provider API
«create»
SubclipseVersionControlClient
Abbildung 6.4: Klassendiagramm der Integration von Versionsverwaltungssystemen
6.1.7 Paket de.fuh.xpairtise.plugin.core.resources.util
In diesem Paket befinden sich Hilfsklassen f¨
ur die Durchf¨
uhrung der verschiedenen anfallenden Aufgaben im clientseitigen Umgang mit Ressourcen. Die Klasse
ResourceUtils bietet Methoden f¨
ur den direkten Umgang mit Ressourcen im lokalen Eclipse-Arbeitsbereich. Hierzu geh¨oren zum Beispiel das Erstellen oder L¨oschen
¨
von Dateien oder Verzeichnissen sowie das Uberschreiben
von Dateien mit neuem
Inhalt. Instanzen dieser Klasse sind jeweils einem einzelnen Projekt zugeordnet
53
6. Details der Umsetzung
und werden sowohl von SharedProject- als auch von SharedVCProject-Instanzen
f¨
ur die Anpassung lokaler Projektinhalte verwendet.
Jede Instanz der Klasse ProjectSynchronizer u
¨bernimmt die Synchronisationsund Kommunikationsaufgaben zwischen dem ihr zugeordneten ISharedProject
und dem XPairtise-Server. Dies betrifft sowohl die initiale Synchronisation des
Projektinhaltes als auch den Empfang und Versand von Aktualisierungen w¨ahrend
der laufenden Sitzung. F¨
ur den Empfang von Aktualisierungen der entsprechenden replizierten Liste wird hierbei die Klasse ResourceReplicationListener als
Implementierung der IReplicatedListEventListener-Schnittstelle verwendet.
¨
Abbildung 6.5: Anzeige n¨otiger Anderungen
w¨ahrend der initialen Synchronisation
W¨ahrend der initialen Synchronisation eines Projektes mit dem Server wird die in
Abschnitt 6.1.5 beschriebene Zwischenspeicherung der eingehenden Replicated¨
an
Resource-Elemente verwendet, um dem Benutzer die n¨otigen Anderungen
den lokalen Projektdaten zur Best¨atigung anzeigen zu k¨onnen. Fungiert der lokale Benutzer zu diesem Zeitpunkt als Driver der Sitzung, besteht alternativ die
54
¨
6.1 Ubersicht
u
¨ber die Implementierung
¨
M¨oglichkeit, statt dessen die lokalen Anderungen
an den Server zu senden (siehe
Abbildung 6.5).
¨
Lokale Anderungen
an Ressourcen werden durch die einzige Instanz der Klasse
ResourceChangeHandler erkannt. Hierf¨
ur verwendet sie eine passende Implementierung der von Eclipse definierten IResourceChangeListener-Schnittstelle. Um
¨
zus¨atzlich Anderungen,
die nicht eine Ressource selbst, sondern nur die zu ihr
geh¨orenden Metadaten der Versionsverwaltung betreffen zu erkennen, wurde diese
Klasse um eine Implementierung der ISubscriberChangeListener-Schnittstelle
erweitert.
Die Klasse LocalResourceModelProvider erweitert die von Eclipse bereitgestellte
Klasse ModelProvider. Ihre Aufgabe ist die Validierung lokal ausgel¨oster Modifikationen an Ressourcen in Hinblick auf die aktuelle Rolle des ausf¨
uhrenden
Benutzers bevor sie tats¨achlich durchgef¨
uhrt werden. Ist der Benutzer nicht Driver
der aktuellen Sitzung wird eine entsprechende Warnung angezeigt. Diese Erweiterung wurde durch einen ¨ahnlichen Mechanismus in Saros inspiriert (vgl. Abschnitt
4.2.2). Wird die Modifikation trotzdem durchgef¨
uhrt, wird sie wie bisher vom
ResourceChangeHandler erkannt, der das entsprechende ISharedProject mit der
R¨
ucknahme beauftragt.
¨
F¨
ur die Ubertragung
von Projekten auf den Server wurde die Klasse ProjectUploader eingef¨
uhrt. Von dieser Klasse existiert ebenfalls lediglich eine einzelne
Instanz, die vom ClientResourceManager erzeugt wird und von diesem bezogen
werden kann.
Die Klasse LocalSnapshot ist f¨
ur die Erstellung und Wiederherstellung von Sicherheitskopien lokaler Projekte verantwortlich. Intern nutzt sie nun weitgehend die in
Abschnitt 6.1.3 beschriebene neue Klasse SnapshotUtils. Die Klasse WorkspaceSpy, u
¨ber die sich verschiedene Informationen u
¨ber Projekte im lokalen EclipseArbeitsbereich erfragen lassen, wurde um die M¨oglichkeit der Erkennung des einem
Projekt zugeordneten Versionsverwaltungssystems erweitert.
6.1.8 Paket de.fuh.xpairtise.plugin.ui.xpviews.sessiongallery
In diesem Paket befinden sich die f¨
ur die Sitzungs¨
ubersicht zust¨andigen Klassen.
Die Klasse XPSessionGallery definiert die entsprechende Eclipse-Sicht. Sie wurde
in Hinblick auf die Unterst¨
utzung mehrerer Projekte pro Sitzung erweitert. So
¨
zeigt die Ubersicht
nun eine variable Anzahl von einer Sitzung zugeordneten
Projekten. Gleiches gilt f¨
ur die u
u zu erreichende Anzeige
¨ber das Kontextmen¨
von Detailinformationen zu einer gegebenen Sitzung. Hier wird neben dem Namen
eines Projektes nun zus¨atzlich sein Typ angezeigt.
55
6. Details der Umsetzung
Das Kontextmen¨
u wurde außerdem um Punkte f¨
ur das Hinzuf¨
ugen und Entfernen
von Projekten erweitert. Die zur Ausl¨osung dieser Aktionen ben¨otigte Logik wurde
der Klasse XPSessionGalleryController hinzugef¨
ugt. Abbildung 6.6 zeigt die
¨
beschriebenen Anderungen an der grafischen Benutzerschnittstelle der Sitzungsu
¨bersicht.
(a) Die erweiterte Sitzungs¨
ubersicht
(b) Sitzungsdetails
¨
Abbildung 6.6: Anderungen
an der Sitzungs¨
ubersicht
6.1.9 Paket de.fuh.xpairtise.plugin.ui.util
Abbildung 6.7: Der u
¨berarbeitete Projektauswahldialog
Hier finden sich Hilfsklassen f¨
ur verschiedene Aspekte der grafischen Benutzeroberfl¨ache von XPairtise. Die Klasse Dialogs definiert einige Dialogtypen, die von
verschiedenen XPairtise-Komponenten verwendet werden. Der f¨
ur die Auswahl
56
¨
6.1 Ubersicht
u
¨ber die Implementierung
von Projekten verwendete Dialog wurde flexibler gestaltet und erlaubt nun die
¨
gleichzeitige Auswahl mehrerer Projekte (siehe Abbildung 6.7). Uberarbeitet
wurde
außerdem der Dialog zur Anzeige der sich durch die initialen Synchronisation von
¨
Projekten ergebenden Anderungen
(siehe Abbildung 6.5).
In der aktuellen Sitzung verwendete Projekte werden im Eclipse-Package-Explorer
sowohl grafisch als auch textuell anschaulich dekoriert. Hierf¨
ur ist die Klasse XPLabelDecorator verantwortlich. Sie wurde angepasst, um mehr als ein Projekt
gleichzeitig entsprechend dekorieren zu k¨onnen. (siehe Abbildung 6.8).
Abbildung 6.8: Dekoration mehrerer Projekte im Package Explorer
6.1.10 Paket de.fuh.xpairtise.server
Dieses Paket enth¨alt die Kernkomponenten des XPairtise-Servers. F¨
ur die serverseitige Verwaltung von Ressourcen ist die Klasse ResourceManager verantwortlich. Hier werden die f¨
ur die Replikation der Projektdaten verwendeten replizierten Listen verwaltet und Aktualisierungen daran vorgenommen. Wie bereits in Abschnitt 5.1 angek¨
undigt, wurden hier haupts¨achlich Anpassungen f¨
ur
die Verarbeitung eingehender Aktualisierungen von Ressourcen unter Versionskontrolle sowie den Umgang mit mehreren Projekten pro Sitzung vorgenommen.
Die Klasse ProjectUploadHandler ersetzt den urspr¨
unglichen CreateSessionHandler. Eine Instanz dieser Klasse ist jeder bestehenden Pair-Programming¨
Sitzung zugeordnet und fungiert als Empf¨anger f¨
ur die Ubertragung
zu dieser
Sitzung hinzugef¨
ugter Projekte. Dieser Vorgang wird hierbei jeweils in eigene
¨
Threads ausgelagert, was auch die gleichzeitige Ubertragung
von Projekten durch
¨
mehrere Teilnehmer einer Sitzung erlaubt. Ist eine Ubertragung
beendet, wird der
empfangene Projektinhalt indiziert und die entsprechenden ReplicatedResourceund ReplicatedVCResource-Elemente erstellt. Diese werden an den ResourceManager u
ullt wird.
¨bergeben, wo eine neue replizierte Liste mit ihnen gef¨
57
6. Details der Umsetzung
6.1.11 Paket de.fuh.xpairtise.server.xml
Hier finden sich Klassen, die die persistente Speicherung aller n¨otigen Sitzungsdaten
erm¨oglichen, um eine Wiederaufnahme von Sitzungen auch nach einem Neustart des
Servers zu erm¨oglichen. Die zentrale Sitzungsdatenbank wird in der Klasse SessionDatabase implementiert. Sie kontrolliert die Erstellung eines einfachen XMLDokumentes, dessen Grundelemente jeweils eine einzelne Sitzung repr¨asentieren.
Diese einzelnen Elemente werden durch Instanzen der Klasse SessionDatabaseEntry gebildet.
Es galt nun, diese Elemente um die flexible Speicherung aller n¨otigen Projektinformationen zu erweitern. F¨
ur diesen Zweck wurde die neue Klasse Sessionugt, deren Instanzen im Wesentlichen den entDatabaseProjectEntry hinzugef¨
sprechenden ReplicatedProjectInfo- und ReplicatedVCProjectInfo-Elementen entsprechen. Mehrere dieser Instanzen k¨onnen einem einzelnen SessionDatabaseEntry zugeordnet werden. Listing 6.1 zeigt das resultierende Format
der Sitzungsdatenbank an einem einfachen Beispiel mit einer einzelnen Sitzung,
der zwei Projekte zugeordnet sind.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE root SYSTEM "XPairtiseSessionDB.dtd">
<XPairtise>
<!--This is the XPairtise session database-->
<session>
<!--Session created on: Sat May 17 15:52:50 CEST 2008-->
<id>5c653f9c5cb6734b</id>
<name>Demo</name>
<group>Test</group>
<project>
<name>TestSVN</name>
<type>Subversion</type>
<location>svn://localhost/testrepo,TestSVN</location>
<rev>11</rev>
</project>
<project>
<name>Test</name>
<type>not version controlled</type>
</project>
</session>
</XPairtise>
Listing 6.1: Beispielhafte Sitzungsdatenbank
Unabh¨angig von der bestehenden Sitzungsdatenbank musste die Persistenz von
Synchronisations- und Revisionsinformationen von Ressourcen unter Versionskon-
58
6.2 Subversion-Integration durch separates Plug-in
trolle erm¨oglicht werden (Anforderung A09). Dies wird von der Klasse VCProjectMetaData u
¨bernommen. Jede Instanz dieser Klasse ist einem einzelnen Projekt
zugeordnet und wird durch den ResourceManager erstellt und aktualisiert. Die
Metadaten aller Ressourcen eines Projektes werden hierbei in einem einzelnen
XML-Dokument mit u
¨bersichtlichem Format gespeichert (siehe Listing 6.2).
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE root SYSTEM "../VCProjectMetaData.dtd">
<MetaData>
<!--Metadata of project "TestSVN"-->
<resource type="file" path=".classpath" revision="4" />
<resource type="file" path=".project" revision="4" />
<resource type="folder" path="src" revision="12" />
<resource type="folder" path="src/test" revision="12" />
<resource type="file" path="src/test/TestClass.java"
remoteOnly="yes" revision="4" />
<resource type="file" path="src/test/TestClass2.java"
revision="12" checksum="419d07d5e745668832c1adc11c512a3e
" />
</MetaData>
Listing 6.2: XML-Format zur Speicherung von Metadaten
6.2 Subversion-Integration durch separates Plug-in
F¨
ur die Subversion-Integration auf Grundlage von Subclipse ist das separate
Plug-in de.fuh.xpairtise.subclipse zust¨andig. Es erweitert den neu definierten
de.fuh.xpairtise.vcClients-Erweiterungspunkt und stellt im Wesentlichen die
Klasse SubclipseVersionControlClient als Subclipse-spezifische Implementierung der IVersionControlClient-Schnittstelle bereit (vgl. Abschnitt 6.1.6).
Die Installation dieses Plug-ins ist optional und muss nur erfolgen, wenn SubversionUnterst¨
utzung ben¨otigt wird. Sie setzt außerdem die Installation des SubclipsePlug-ins (in der zum Ende der Implementierungszeit aktuellen Version 1.4.x)
voraus. Diese direkte Abh¨angigkeit von Subclipse war die Hauptmotivation f¨
ur
die Auslagerung in ein separates Plug-in. Eine sp¨atere zus¨atzliche SubversionImplementierung auf Grundlage von Subversive (siehe Abschnitt 7.2) w¨are ohne
diese Auskopplung außerdem problematisch, da sich Subclipse und Subversive nicht
problemlos gleichzeitig verwenden lassen.
59
6. Details der Umsetzung
6.3 Interaktion der Komponenten
¨
In den letzten Abschnitten wurde eine Ubersicht
u
¨ber die in den einzelnen Pa¨
keten vorgenommenen Anderungen
und Erweiterungen gegeben. Um das Zusammenspiel einiger der wichtigeren beschriebenen Komponenten bei der Synchronisation von Ressourcen zu veranschaulichen, werden in diesem Abschnitt nun
die typischen Abl¨aufe bei der Verbreitung einer Modifikation einer Datei unter Versionskontrolle grob skizziert. Die Abbildungen 6.9 und 6.10 fassen die
clientseitige Teilmenge dieser Abl¨aufe in Form vereinfachter Sequenzdiagramme
zusammen.
¨
Abbildung 6.9: Erkennung, Analyse und Versand einer Anderung
¨
Ein Teilnehmer einer XPairtise-Sitzung f¨
uhrt u
Erkennung der Anderung:
¨ber
den Eclipse-Package-Explorer eine Modifikation an einer Datei unter Versions¨
kontrolle durch. Uber
seine Implementierung der IResourceChangeListenerSchnittstelle wird der ResourceChangeHandler dar¨
uber informiert. Er wendet sich an den ClientResourceManager, um eine Referenz auf das zum betreffende Projekt geh¨orende ISharedProject, in diesem Fall also ein SharedVCProject, zu erhalten. Von diesem erfragt er den Synchronisationsstatus der
60
6.3 Interaktion der Komponenten
¨
Datei. Haben sich Anderungen
zum registrierten Zustand der Datei ergeben,
h¨angt das weitere Vorgehen von der aktuellen Benutzerrolle des Teilnehmers
ab. Ist er der Driver der Sitzung, wird der neue Stand der Datei im SharedVCProject registriert und der zu diesem geh¨orende ProjectSynchronizer
¨
mit dem Versand der Anderung
beauftragt. Im anderen Fall handelt es sich
um eine unerlaubte Modifikation und das SharedVCProject wird mit ihrer
R¨
ucknahme beauftragt.
¨
Der ProjectSynchronizer erfragt beim
Analyse und Versand der Anderung:
dem Projekt zugeordneten IVersionControlClient die aktuelle Basisrevision der Datei und ihren Modifikationsstatus. Ist die Datei im Vergleich zu ihrer
Basisrevision bereits modifiziert, wird u
¨ber das SharedVCProject zus¨atzlich
der tats¨achliche Inhalt der Datei bezogen. Intern bedient sich das SharedVCur einer ResourceUtils-Instanz. Der ProjectSynchronizer
Project hierf¨
sendet die so gesammelten Daten u
¨ber das IServerCommandInterface an
den Server.
¨
Abbildung 6.10: Empfang und Reproduktion einer Anderung
¨
¨
Replikation der Anderung
Nach Ubertragung
u
¨ber das Netzwerk wird auf dem
Server zun¨achst die ServerApplication u
¨ber ihre Implementierung der
IServerCommandListener-Schnittstelle u
ber
die eingegangene Nachricht in¨
formiert. Sie reicht die Nachricht an den ResourceManager weiter, welcher
das die ge¨anderte Ressource beschreibende ReplicatedVCResource-Element
mit den neuen Daten aktualisiert und die n¨otige Aktualisierung an der
61
6. Details der Umsetzung
entsprechenden replizierten Liste (IReplicatedListMaster) vornimmt. Enthielt die Nachricht den kompletten Inhalt der Datei, wird das eingef¨
ugte
Element zus¨atzlich mit Hilfe eines ReplicatedResourceWithContent-Elementes um diesen erweitert. Dar¨
uber hinaus wird die zum Projekt geh¨orende
VCProjectMetaData-Instanz entsprechend aktualisiert.
¨
Empfang und Reproduktion der Anderung:
Auf der Seite des Empf¨angers erf¨ahrt der dem entsprechenden ProjectSynchronizer zugeordnete ResourceReplicationListener u
¨ber seine Implementierung der IReplicatedListEventReceiver-Schnittstelle von der Aktualisierung der replizierten Liste.
Die empfangene replizierte Ressource u
¨bergibt er an das ihm zugeordnete
ISharedProject, in diesem Fall also wieder ein SharedVCProject, welches
die Angleichung der lokalen Datei daran vornimmt. Hat die Basisrevision
der Datei sich ge¨andert, wird mit Hilfe des IVersionControlClient ein
Update aus dem Repository durchgef¨
uhrt. Wurde ein kompletter Dateiinhalt
empfangen, wird die lokale Datei bei Bedarf mit Hilfe der ResourceUtils
mit diesem u
¨berschrieben.
62
7 Fazit
Dieses letzte Kapitel liefert eine kurze Zusammenfassung der Erkenntnisse dieser Arbeit und gibt einen Ausblick auf m¨ogliche zuk¨
unftige Erweiterungen und
Verbesserungen.
7.1 Zusammenfassung
Im Zuge dieser Ausarbeitung wurde die Konzeption und Implementierung einiger
Erweiterungen des Eclipse-Plug-ins XPairtise beschrieben. Das Hauptziel war
eine Integration der Dienste der verbreiteten Versionsverwaltungssysteme CVS
und Subversion, um das f¨
ur die Synchronisation der in einer Pair-ProgrammingSitzung ben¨otigten Arbeitsdaten anfallende Datenaufkommen so weit wie m¨oglich
zu minimieren. Zus¨atzlich wurde die F¨ahigkeit hinzugef¨
ugt, in einer einzelnen
Sitzung mehrere Projekte verwenden zu k¨onnen.
Anhand eines Beispielszenarios wurden in Kapitel 3 zun¨achst die Anforderungen
an diese Erweiterungen ausgearbeitet. Diese dienten als Grundlage f¨
ur das in
Kapitel 5 beschriebene L¨osungskonzept. Die tats¨achliche Implementierung dieses Konzeptes wurde schließlich in Kapitel 6 vorgestellt. Bei der Konzeption der
Erweiterungen wurde Wert darauf gelegt, die bestehende, bereits bew¨ahrte Grundarchitektur der Replikation von Projektdaten in XPairtise so weit wie m¨oglich
¨
beizubehalten. Anderungen
wurden nur dort vorgenommen, wo es n¨otig oder
sinnvoll erschien.
F¨
ur die Integration der Versionsverwaltungssysteme wurde ein Konzept gew¨ahlt,
das f¨
ur die Umsetzung einer Teilmenge der ben¨otigten Funktionalit¨at interne
Funktionen der CVS- und Subclipse-Plug-ins verwendet. Die Wahl fiel damit gegen
eine L¨osung, die ausschließlich mit Mitteln der Eclipse Team API auskommt,
da diese zu hohe Einschr¨ankungen bedeutet h¨atte. Die Implementierung wurde
modular gestaltet und legt Wert auf eine m¨oglichst einfache Erweiterbarkeit, um
zuk¨
unftig auch weitere Versionsverwaltungssysteme einbinden zu k¨onnen. Durch
einen entsprechenden Eclipse-Erweiterungspunkt kann dies auch in Form separater
Plug-ins erfolgen, ohne XPairtise selbst modifizieren zu m¨
ussen.
63
7. Fazit
7.2 Ausblick
Dieser Abschnitt gibt einige Verbesserungsvorschl¨age der hier vorgestellten Erwei¨
terungen. F¨
ur eine Ubersicht
u
¨ber m¨ogliche Erweiterungen in anderen Bereichen
von XPairtise bietet sich die ToDo-Liste des Projektes an [TOD08].
F¨
ur zuk¨
unftige Erweiterungen der vorgestellten L¨osung bietet sich zun¨achst die
Integration weiterer f¨
ur die Anbindung an Versionsverwaltungssysteme zust¨andiger
Team Provider in Form separater Plug-ins an. Reizvoll w¨are hier vor allem eine weitere Subversion-Implementierung auf Basis des Subversive-Plug-ins als Gegenst¨
uck
zur bestehenden Subclipse-Implementierung, um eine Subversion-Unterst¨
utzung
unabh¨angig vom verwendeten Plug-in zu gew¨ahrleisten. Es bleibt abzuwarten, in
wie weit zuk¨
unftige Entwicklungen der Eclipse Team API es erm¨oglichen werden,
weitere Funktionalit¨at mit Hilfe generischer Team API zu implementieren. Dies
w¨
urde den ben¨otigten Aufwand zur Integration zus¨atzlicher Team Provider weiter
reduzieren.
Als problematisch bei der Implementierung der CVS-Unterst¨
utzung erwies sich
das Fehlen projektweiter Revisionsinformationen bei CVS. XPairtise nutzt diese
globale Revision, um projektweite Updates durchzuf¨
uhren sowie gezielt einen
bestimmten in einer Sitzung g¨
ultigen Stand eines Projektes aus dem Repository
auschecken zu k¨onnen. Das u
¨berarbeitete Versionierungsschema von Subversion (vgl.
Abschnitt 2.4.2) erweist sich daher auch in XPairtise als Vorteil. Die momentane
CVS-Implementierung versucht, das Fehlen dieser Revision durch Zeitstempel und
daraus generierte CVS-Tags zu kompensieren (vgl. Abschnitt 5.3, Anforderungen
A04-A07). Dies ist jedoch bei gr¨oßeren Projekten recht ineffizient und nicht immer
zuverl¨assig. Die Suche nach einem alternativen Ansatz k¨onnte sich daher lohnen.
Die Evaluierung der implementierten Erweiterungen erfolgte im Zuge dieser Arbeit
haupts¨achlich in einer speziell f¨
ur diesen Zweck aufgebauten Testumgebung mit
CVS- und Subversion-Repositories im lokalen Netzwerk. Der regul¨are Betrieb
in einer dynamischeren Umgebung mit gr¨oßerer Teilnehmerzahl und externen
Repositories wird zeigen m¨
ussen, ob und an welchen Stellen die Robustheit der
Implementierung noch zu verbessern ist.
Erweiterungen an der grafischen Benutzerschnittstelle wurden im Zuge dieser
Ausarbeitung nur im n¨otigen Maße durchgef¨
uhrt. Denkbar w¨aren in diesem Bereich beispielsweise Verfeinerungen der Anzeige von Projektinformationen in der
Sitzungs¨
ubersicht sowie der bei der initialen Synchronisation von Projekten anfallenden Unterschiede. Die Implementierung der automatischen Erstellung von
Commit-Kommentarvorlagen ist momentan sehr einfach gehalten. Denkbar w¨are hier eine flexiblere Gestaltung, die es dem Benutzer erlaubt, das Format der
generierten Vorlagen selbst zu bestimmen.
64
Literaturverzeichnis
Literaturverzeichnis
[AMQ08]
ActiveMQ Website. http://activemq.apache.org, 05 2008.
[Art04]
Arthorne, J.: How You’ve Changed! Responding to resource changes in the Eclipse workspace. Eclipse Corner Articles,
http://www.eclipse.org/articles, 2004.
[Bae05]
Baerisch, S.: Versionskontrollsysteme in der Softwareentwicklung,
IZ-Arbeitsbericht Nr. 36. Technischer Bericht, GESIS - Gesellschaft
Sozialwissenschaftlicher Infrastruktureinrichtungen e.V., 06 2005.
[COL08]
NetBeans Collaboration Project Website. http://collab.netbeans.
org, 06 2008.
[CVS08]
CVS Website. http://www.nongnu.org/cvs, 06 2008.
[CW01]
Cockburn, A. und L. Williams: The Costs and Benefits of Pair
Programming. The XP Series, Seiten 223–243, 2001.
[Der08]
Apache Derby Website. http://db.apache.org/derby, 06 2008.
[Dje06]
Djemili, Riad: Entwicklung einer Eclipse-Erweiterung zur Realisierung und Protokollierung verteilter Paarprogrammierung. Diplomarbeit, Freie Universit¨at Berlin, 2006.
[ECL08]
Eclipse Website. http://www.eclipse.org, 05 2008.
[JDO08]
JDOM Website. http://www.jdom.org/, 05 2008.
[JMS08]
Java Message Service Website. http://java.sun.com/products/
jms, 06 2008.
[Mau02]
Maurer, Frank: Supporting Distributed Extreme Programming.
In: Proceedings of the Second XP Universe and First Agile Universe
Conference on Extreme Programming and Agile Methods - XP/Agile
Universe 2002, Seiten 13–22, London, UK, 2002. Springer-Verlag.
[NBS08]
NetBeans Website. http://www.netbeans.org, 06 2008.
[OSG08]
OSGi Website. http://www.osgi.org, 05 2008.
[RSFWH98] Richardson, T., Q. Stafford-Fraser, K.R. Wood und
A. Hopper: Virtual Network Computing. IEEE Internet Computing,
2(1), 1998.
[S5B08]
XMPP-Erweiterung: SOCKS5-Bytestr¨
ome. http://www.xmpp.org/
extensions/xep-0065.html, 05 2008.
65
Literaturverzeichnis
[SAR08]
Saros Website. http://dpp.sourceforge.net, 05 2008.
[SCL08]
Subclipse Website. http://subclipse.tigris.org, 05 2008.
[SoC08]
Google Summer of Code 2008, Subclipse Projects. http://code.
google.com/soc/2008/subclipse/about.html, 05 2008.
[SVE08]
Subversive Website.
2008.
[SVN08]
Subversion Website. http://subversion.tigris.org, 06 2008.
[SWN03]
Stotts, D., L. Williams und N. Nagappan: Virtual Teaming:
Experiments and Experiences with Distributed Pair Programming.
Extreme Programming and Agile Methods - XP/Agile Universe,
Seiten 129–141, 2003.
[Tea08]
Eclipse Platform Plug-in Developer Guide, Team Support.
http://help.eclipse.org/help33/topic/org.eclipse.
platform.doc.isv/guide/team.htm, 05 2008.
[TOD08]
XPairtise ToDo-Liste. http://xpairtise.sourceforge.net/todo/
todo.html, 06 2008.
[WG05]
Worth, D.J. und C. Greenough: Comparison of CVS and Subversion. 10 2005.
[Wil00]
Williams, L.A.: The Collaborative Software Process. Doktorarbeit,
The University of Utah, 2000.
[Xec08]
XecliP Sourceforge-Website. http://sourceforge.net/projects/
xeclip/, 05 2008.
[XMP08]
XMPP Website. http://www.xmpp.org, 05 2008.
[XPa08]
XPairtise Sourceforge-Website.
projects/xpairtise, 06 2008.
66
http://www.eclipse.org/subversive/, 05
http://sourceforge.net/
A CD-Beilage
Die dieser Ausarbeitung beigef¨
ugte CD enth¨alt:
• Fertige Pakete von XPairtise in der zum Ende der Bearbeitungszeit dieser
Arbeit aktuellen Version 1.1.0
• Den kompletten Quellcode dieser Version
• Die XPairtise-API-Dokumentation im JavaDoc-Format
• Eine Installationsanleitung sowie das XPairtise-Benutzerhandbuch
• Die PDF-Version dieser Ausarbeitung
N¨ahere Informationen enth¨alt die Readme-Datei im Wurzelverzeichnis der CD.
67
B Eidesstattliche Erkl¨
arung
Hiermit versichere ich, dass ich die vorliegende Arbeit selbstst¨andig verfasst und
keine anderen als die angegebenen Quellen und Hilfsmittel benutzt sowie Zitate
kenntlich gemacht habe.
Troisdorf, im Juli 2008
Timo Kanera
69
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertisement