Repository-Integration fur die¨ Kooperationsplattform CURE · 2013. 7. 17. · Fernuniversit¨at in Hagen Universit¨atsstr. 1 58084 Hagen Repository-Integration fur die¨ Kooperationsplattform

Fernuniversitat in HagenUniversitatsstr. 158084 Hagen

Repository-Integration fur die

Kooperationsplattform CURE

Masterarbeit

vonMarkus TauchnitzMatrikel 7085427

angefertigt am

Lehrgebiet Praktische Informatik VI- Kooperative Systeme -

Prof. Dr. Jorg HaakeFernUniversitat Hagen

BetreuerDr. Till Schummer

Mai 2007

Erklarung

Ich erklare hiermit, dass ich diese Masterarbeit selbstandig verfasst, nochnicht anderweitig fur andere Prufungszwecke vorgelegt, keine anderen alsdie angegebenen Quellen und Hilfsmittel benutzt sowie wortliche und sinn-gemaße Zitate als solche gekennzeichnet habe.

Munchen, den 1. Mai 2007—————————————— ————————Ort, Datum Markus Tauchnitz

Zusammenfassung

Im Zuge der verstarkten Globalisierung werden komplexe Softwaresystemeimmer haufiger in raumlich und zeitlich verteilten Umgebungen realisiert.Wenn man die verschiedenen Projektteilnehmer, wie z.B. Benutzer, Analys-ten, Softwarearchitekten, Designer, Entwickler oder Tester betrachtet, so istfestzustellen, dass unterschiedliche Betrachtungsweisen des Produktes exis-tieren und deshalb andere Anforderungen an die Werkzeugunterstutzunggestellt werden. Um qualitativ hochwertige Software zu erstellen, mussen je-doch alle Projektteilnehmer effizient zusammenarbeiten. Heutzutage werdendazu eine Vielzahl an Werkzeugen genutzt um Kommunikation, Kooperati-on und Koordination zu unterstutzen. Besser ware es an dieser Stelle einezentrale Kollaborationsplattform zu schaffen, welche entwicklungsunterstut-zend eingesetzt werden kann.Im Rahmen dieser Arbeit werden die Planung, der Entwurf und die Imple-mentierung einer Repository-Anbindung fur die Kooperationsplattform CU-RE1 beschrieben. Es geht dabei darum, die Inhalte eines CVS2-Repositoriesvon CURE aus zugreifbar zu machen.Es wird aufgefuhrt, warum die Notwendigkeit dieser Anbindung besteht undwelche Anforderungen an die Losung gestellt werden. Weiterhin wird unter-sucht, ob diese Anforderungen von bestehenden Losungen erfullt werdenkonnen oder welche Funktionalitaten von diesen Losungen bereit gestelltwerden. Im Anschluss daran werden die wichtigsten Eigenschaften des De-signs und der Implementierung der Repository-Anbindung beschrieben.

1 Abk. Collaborative Universal Remote Education2 Abk. Concurrent Versions System

Inhaltsverzeichnis

Abkurzungsverzeichnis 2

Abbildungsverzeichnis 4

Tabellenverzeichnis 5

1 Einfuhrung 61.1 Motivation der Problemstellung . . . . . . . . . . . . . . . . . 61.2 Definition des Problems . . . . . . . . . . . . . . . . . . . . . 81.3 Ubersicht uber die folgenden Kapitel der Arbeit . . . . . . . . 10

2 Anforderungsanalyse 112.1 Detaillierte Untersuchung des Problembereichs . . . . . . . . 11

2.1.1 Kooperative Softwareentwicklung . . . . . . . . . . . . 112.1.2 CURE . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.1.3 Versionsverwaltung . . . . . . . . . . . . . . . . . . . . 25

2.2 Herleitung von anwendungsspezifischen Anforderungen . . . . 272.2.1 Allgemein . . . . . . . . . . . . . . . . . . . . . . . . . 282.2.2 Szenarien . . . . . . . . . . . . . . . . . . . . . . . . . 28

2.3 Zusammenfassung der Anforderungen . . . . . . . . . . . . . 31

3 Stand der Technik 323.1 Darstellung existierender Ansatze . . . . . . . . . . . . . . . . 32

3.1.1 Universitare Kollaborationsplattformen fur Software-projekte . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.1.2 Kommerzielle bzw. freie Kollaborationsplattformen furSoftwareprojekte . . . . . . . . . . . . . . . . . . . . . 41

3.1.3 CVS-Anbindungen . . . . . . . . . . . . . . . . . . . . 473.2 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . 51

4 Losungsansatz 534.1 Losungsidee . . . . . . . . . . . . . . . . . . . . . . . . . . . . 534.2 Uberblick uber die Losung . . . . . . . . . . . . . . . . . . . . 54

4.2.1 Erstellung einer Repository-Anbindung . . . . . . . . 544.2.2 Arbeit mit dem Repository . . . . . . . . . . . . . . . 55

1

INHALTSVERZEICHNIS 2

4.2.3 Gruppenbewusstsein . . . . . . . . . . . . . . . . . . . 584.3 Realisierung der Anforderungen . . . . . . . . . . . . . . . . . 59

4.3.1 Funktionale Anforderungen . . . . . . . . . . . . . . . 594.3.2 Nichtfunktionale Anforderungen . . . . . . . . . . . . 64

5 Details der Losung 655.1 Softwarearchitektur . . . . . . . . . . . . . . . . . . . . . . . . 66

5.1.1 Model . . . . . . . . . . . . . . . . . . . . . . . . . . . 675.1.2 View . . . . . . . . . . . . . . . . . . . . . . . . . . . . 675.1.3 Controller . . . . . . . . . . . . . . . . . . . . . . . . . 695.1.4 Repository-Anbindungen . . . . . . . . . . . . . . . . 705.1.5 James-Anbindung . . . . . . . . . . . . . . . . . . . . 725.1.6 Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

5.2 Besondere Implementierungsdetails . . . . . . . . . . . . . . . 735.2.1 Sichere Kommunikation mit dem CVS-Server . . . . . 735.2.2 Erweiterbarkeit fur andere Versionierungswerkzeuge . 745.2.3 Anbindung an den Mailserver James . . . . . . . . . . 765.2.4 Benachrichtigung der Benutzer uber Aktualisierungen 77

6 Erweiterte Anwendungsmoglichkeiten 796.1 Asynchrone Softwareinspektion . . . . . . . . . . . . . . . . . 796.2 Benachrichtigung uber Fertigstellung eines Artefakts . . . . . 806.3 Codesuche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 806.4 Abbilden von Beziehungen im Entwicklungsprozess . . . . . . 80

7 Zusammenfassung 827.1 Bewertung der Ergebnisse . . . . . . . . . . . . . . . . . . . . 837.2 Erfahrungen mit dem Prototyp . . . . . . . . . . . . . . . . . 857.3 Erweiterungspotenzial . . . . . . . . . . . . . . . . . . . . . . 86

7.3.1 Repository-Anbindung . . . . . . . . . . . . . . . . . . 867.3.2 CURE als Kollaborationsplattform . . . . . . . . . . . 89

Literaturverzeichnis 90

Abkurzungsverzeichnis

AES . . . . . . . . . . . . . Advanced Encryption StandardAJAX . . . . . . . . . . . Asynchronous JavaScript and XMLCASE . . . . . . . . . . . Computer-Aided Software DesignCDE . . . . . . . . . . . . . Collaborative Development EnvironmentCHIME . . . . . . . . . . Columbia Hypermedia IMmersion EnvironmentCMS . . . . . . . . . . . . Content Management SystemCSCW . . . . . . . . . . . Computer Supported Cooperative WorkCSS . . . . . . . . . . . . . Cascading Style SheetsCURE . . . . . . . . . . . Collaborative Universal Remote EducationCVE . . . . . . . . . . . . . Collaborative Virtual EnvironmentsCVS . . . . . . . . . . . . . Concurrent Versions SystemDES . . . . . . . . . . . . . Data Encryption StandardDRES . . . . . . . . . . . Distributed Requirements Engineering SystemFLECSE . . . . . . . . . FLexible Environment for Collaborative Software Engi-

neeringGENESIS . . . . . . . . GEneralised eNvironment for procEsS management in

cooperatIve Software engineeringGNU . . . . . . . . . . . . Gnu is Not UnixHTML . . . . . . . . . . . HyperText Markup LanguageIDE . . . . . . . . . . . . . Integrated Development EnvironmentJ2EE . . . . . . . . . . . . Java 2 Enterprise-EditionMAPPER . . . . . . . Model-based Adaptive Product and Process Enginee-

ringMVC . . . . . . . . . . . . Model View ControllerOPHELIA . . . . . . . Open Platform and Methodologies for Development Tools

Integration in a Distributed EnvironmentRSH . . . . . . . . . . . . . Remote ShellSDI . . . . . . . . . . . . . . Single Document InterfaceSE . . . . . . . . . . . . . . . Software EngineeringSSH . . . . . . . . . . . . . Secure SHellUML . . . . . . . . . . . . Unified Modeling LanguageXML . . . . . . . . . . . . Extensible Markup Language

3

Abbildungsverzeichnis

2.1 Unterstutzung von kooperativer Softwareentwicklung durchGroupware (angelehnt an [TSB95]) . . . . . . . . . . . . . . . 15

2.2 Modell einer Kollaborationsplattform (entnommen aus [BB03]) 182.3 Ein Raum in CURE . . . . . . . . . . . . . . . . . . . . . . . 212.4 Modell von CURE (entnommen aus [HSB+04]) . . . . . . . . 22

3.1 Architektur von CHIME (entnommen aus [Dos01]) . . . . . . 333.2 Benutzeroberflache von CHIME (entnommen aus [Dos01]) . . 343.3 Grundgedanke von OPHELIA (entnommen aus [GT04]) . . . 363.4 Architektur von OPHELIA (entnommen aus [GT04]) . . . . . 373.5 Beispielimplementierung ORPHEUS (entnommen aus [GT04]) 383.6 Modell von GENESIS (entnommen aus [BCG+03]) . . . . . . 393.7 Architektur von GENESIS (entnommen aus [GP02]) . . . . . 403.8 Funktionalitaten von SourceForge Enterprise Edition (ent-

nommen aus [SOU07a]) . . . . . . . . . . . . . . . . . . . . . 423.9 Architektur von CodeBeamer (entnommen aus [COD07a]) . . 453.10 Einbindung von externen Repositories in CodeBeamer . . . . 463.11 TortoiseCVS in der Anwendung (entnommen aus [TOR07]) . 483.12 ViewVC Erweiterung beim Einsatz auf SourceForge.net . . . 50

4.1 Erstellen einer Repository-Seite . . . . . . . . . . . . . . . . . 544.2 Ansicht eines Repositories . . . . . . . . . . . . . . . . . . . . 554.3 Ansicht eines Artefakts . . . . . . . . . . . . . . . . . . . . . . 564.4 Versionsansicht eines Artefakts . . . . . . . . . . . . . . . . . 574.5 Suche innerhalb von Artefakten . . . . . . . . . . . . . . . . . 584.6 Schaltflachen zum Zugriff auf die Versionshistorie . . . . . . . 604.7 Unterschiede zwischen Artefakten . . . . . . . . . . . . . . . . 614.8 Informationsseite der Repository-Anbindung . . . . . . . . . . 624.9 Tagesbericht mit Anzeige der Veranderungen . . . . . . . . . 624.10 Assoziation mit dem Repository aus einer Wiki-Seite . . . . . 64

5.1 Strukur der Pakete innerhalb der Repository-Anbindung . . . 675.2 Klassendiagramm des Modell-Pakets . . . . . . . . . . . . . . 685.3 Klassenstruktur des View-Pakets fur die RepositoryFilePage . 685.4 Klassenstruktur des View-Pakets fur die RepositoryPage . . . 69

4

5.5 Klassenstruktur des View-Pakets fur die zusatzlichen Ansich-ten der Klasse RepositoryPage . . . . . . . . . . . . . . . . . 70

5.6 Klassenstruktur des Clientplugin-Pakets . . . . . . . . . . . . 725.7 Klassenstruktur des James-Pakets . . . . . . . . . . . . . . . 725.8 Sequenzdiagramm zur Einbindung der Klasse ExtConnection 745.9 Anbindung an den Mailserver James . . . . . . . . . . . . . . 775.10 Benachrichtigung der Benutzer uber Aktualisierungen . . . . 78

6.1 Assoziationen zwischen Implementierung und Dokumentation 81

7.1 Komponenten einer Kollaborationsplattform (entnommen aus[BB03]) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

Tabellenverzeichnis

2.1 Anforderungen an die Repository-Anbindung . . . . . . . . . 31

3.1 Bedeutung der Symbole in Tabelle 3.2 . . . . . . . . . . . . . 513.2 Ubersicht uber die untersuchten Losungen . . . . . . . . . . . 52

7.1 Vergleichende Bewertung der Repository-Anbindung . . . . . 84

5

Kapitel 1

Einfuhrung

1.1 Motivation der Problemstellung

Die notwendigen Voraussetzungen fur die wirtschaftliche und professionelleErstellung qualitativ hochwertiger Softwareprodukte betreffen nicht alleindie technischen Aspekte, sondern vor allem auch den Prozess der Aufteilungder Entwicklungsaufgaben innerhalb eines Projektteams und den Aufbauvon Kommunikations- und Koordinationsbeziehungen [AP99].[Alt98] stellt fest, dass in Forschungsansatzen oder kommerziellen Losungengruppenunterstutzende Aspekte unterreprasentiert sind oder oft nicht denAnforderungen an eine effiziente Unterstutzung der Kommunikation und Ko-ordination genugen.Auf der einen Seite existieren integrierte Entwicklungsumgebungen1. DieseUmgebungen verfugen in der Regel uber integrierten Texteditor, Compilerbzw. Interpreter, Linker, Debugger und eine Quelltextformatierungsfunk-tion. Weiterhin werden oft CASE2-Tools integriert, welche den Entwick-lungsprozess unterstutzen. Beispielsweise fallen in diese Kategorie graphischePlanungs-, Analyse- und Design-Tools, Werkzeuge zur Anforderungsanaly-se, User-Interface-Designer und Datenmodellierungswerkzeuge. Es existie-ren zwar auch Werkzeuge zur Unterstutzung der Gruppenarbeit in Softwa-reprojekten (E-Mailsysteme, Projektmanagementlosungen und Gruppene-ditoren), diese sind aber meist nicht integraler Bestandteil einer Entwick-lungsumgebung. Diese Erkenntnis hat bereits Erweiterungen wie TUKAN[Sch99] oder Jazz [HCRP04] hervorgebracht, welche direkt Kooperation undKommunikation innerhalb von Entwicklungsumgebungen unterstutzen. Lei-der unterstutzen diese Werkzeuge vorrangig Entwickler. Andere am Ent-wicklungsprozess beteiligte Personen konnen nicht partizipieren. Es mussendaher immer eine Fulle von unterschiedlichen Tools genutzt werden um zumgewunschten Ergebnis - dem Softwareprodukt - zu kommen. [HF94] stellte

1 engl. IDE - Integrated Development Environment2 Abk. Computer-Aided Software Engineering

6

KAPITEL 1. EINFUHRUNG 7

bei einer empirischen Untersuchung von Softwareprojekten fest, dass geradeder Aufwand fur Abstimmungsprozesse bei ca. 40% des gesamten Projekt-aufwandes liegt. Je starker die Tatigkeiten verschiedener Projektmitarbeitervoneinander abhangen, desto intensiver mussen diese miteinander kooperie-ren, sich untereinander informieren und gegenseitig auf dem aktuellen Standhalten.Auf der anderen Seite existieren bereits umfangreiche Losungen, welche ver-teilte Gruppen u.a. in Kommunikation und Koordination unterstutzen. Eshandelt sich hierbei um so genannte CSCW3-Systeme. Diese Anwendungenstellen Mechanismen zur synchronen Kommunikation (z.B. Videokonferen-zen, Chat-Systeme), aber auch zur asynchronen Kommunikation (z.B. E-Mailsysteme, Newsgroups) und zur Koordination (z.B. Terminkoordination,Projektmanagementwerkzeuge) zur Verfugung. Existierende CSCW-Systemebieten jedoch in der Regel keine zufrieden stellende Unterstutzung fur diekooperative Softwareentwicklung, weil sie meist eine unzureichende konzep-tionelle und technische Integration von Prozess- und Produktsicht zur Ver-fugung stellen. Auch hier gibt es Ausnahmen wie beispielsweise CodeBeamer[COD07a] oder SourceForge Enterprise Edition [SOU07a], deren Funktions-umfang in Kapitel 3.1.2 untersucht wird.Der Grundgedanke, dass man den unterschiedlichen Projektteilnehmern ei-ne zentrale Kollaborationsplattform zur Unterstutzung von Kommunikationund Koordination bereitstellt, wird bereits heute schon von vielen Unter-nehmen genutzt [KL05]. Als Grundlage hierfur konnten bestehende CSCW-Systeme verwendet werden. Diese mussten jedoch punktuell erweitert wer-den, um den besonderen Anspruchen im Laufe des Softwareentwicklungs-prozesses zu genugen.Diese Anwendungsmoglichkeit von CSCW-Systemen wird ebenso in [PG95]und [BS98] genannt. Die Funktionalitaten einer Kollaborationsplattform las-sen sich in drei Kategorien gruppieren: Wissensaustausch, Kommunikations-und Koordinationsunterstutzung im Rahmen des Softwareentwicklungspro-zesses [CKI98]. Grundsatzlich gelten diese Anforderungen auch fur allgemei-ne CSCW-Systeme, jedoch werden in einer Kollaborationsplattform auchspezielle Anforderungen gestellt, welche in Kapitel 2.1 untersucht werden.

3 Abk. Computer-Supported Collaborative Work


1.2 Definition des Problems

Wie bereits angedeutet ist es von besonderem Interesse CSCW-Systeme alsKollaborationsplattformen fur die kooperative Softwareentwicklung einzu-setzen. Ziel dieser Arbeit soll es sein die Kooperationsplattform CURE umeinen Teilaspekt dieses Aufgabenbereichs zu erweitern.

CURE besitzt bereits einige Eigenschaften um die kooperative Entwicklungzu unterstutzen. So ist es beispielsweise moglich die Aktivitaten von Ko-operierenden uber gemeinsames Material zu steuern. Dazu steht ein ver-einfachtes Dokumentenmanagementsystem4 mit integrierter Versionsverwal-tung zur Verfugung. Im Bereich Kommunikation unterstutzt CURE denNachrichtenaustausch durch unterschiedliche synchrone und asynchrone Werk-zeuge. Kollaboration wird in CURE ebenso durch synchrone (z.B. Integra-tion von Microsoft Netmeeting) als auch durch asynchrone Moglichkeiten(Gruppeneditor, Wiki-Seiten) unterstutzt. Eine genauere Untersuchung derEigenschaften der Kooperationsplattform CURE findet im Abschnitt 2.1statt.

Das Ziel von Softwareprojekten ist es ein lauffahiges Programm zu erstellen.Dieses Programm wird reprasentiert von einer Menge von Quelltexten. Ineiner Kollaborationsplattform ist es notwendig Zugriff auf diese Artefakte5

zu haben. Dazu gehoren neben den Quelltexten auch Dokumente, die demProjektmanagement dienen oder Spezifikationen, welche als Ausgangspunktder Entwicklung dienen. Eine Entwicklungsumgebung ware fur diese Auf-gabe nicht geeignet, da am Entwicklungsprozess auch andere Personen, wieProjektmanager oder Tester teilnehmen. Die Kollaborationsplattform dientdeshalb dazu, dass sich die verschiedenen Projektteilnehmer in einer gemein-samen Umgebung mit dem Produkt auseinandersetzen konnen.

In aktuellen Softwareprojekten wird die Verwaltung von Artefakten von Ver-sionsverwaltungslosungen ubernommen. Dabei werden insbesondere alle An-derungen an den Artefakten erfasst und Versionsstande in einem Repository6

gesichert. Besonders hervorzuheben sind in diesem Zusammenhang die Versi-onsverwaltungen CVS, Subversion und Rational ClearCase. Im Rahmen die-ser Arbeit soll nun das CSCW-Portal CURE dahingehend erweitert werden,dass ein Zugriff auf Repositories ermoglicht wird. Die Vielzahl der bestehen-den Versionsverwaltungswerkzeuge und deren unterschiedliche Zugriffsme-thoden erschweren jedoch eine Anbindung an beliebige Losungen. Es wurde

4 engl. CMS - Content Management System5 Ein Artefakt reprasentiert einen Arbeitsgegenstand im Entwicklungsprozess. Dabei

kann es sich sowohl um Dokumente des Entwicklungsprozesses wie z.B. Quellcode alsauch um Ergebnisse wie ausfuhrbare Dateien handeln [Alt98].

6 Archiv


daher im Vorfeld dieser Arbeit festgelegt, dass die Repository-Anbindungeinen Zugriff auf ein CVS-System ermoglicht. Dies ist auf die große Verbrei-tung und die universelle Verfugbarkeit des Systems zuruckzufuhren [BF03].Wunschenswert ist jedoch eine erweiterbare Losung, welche eine einfacheIntegration von anderen Versionsverwaltungslosungen ermoglicht.

Die Benutzer von CURE sollen in der bereitzustellenden Losung auf belie-bige Repositories zugreifen konnen. Die Repositories konnen sich dabei aufanderen Rechnern, auch außerhalb eines lokalen Netzes befinden.Die Elemente des Repositories sollen direkt in die Plattform eingeblendetwerden. Der Benutzer soll nur mit den von der Plattform zur Verfugung ge-stellten Moglichkeiten mit dem Repository arbeiten konnen. Es wird dement-sprechend Wert auf eine hohe Integration hinsichtlich Design und Interakti-onsmoglichkeiten in die Plattform gelegt.Der Benutzer soll innerhalb der Losung direkt durch die Struktur des Re-positories navigieren konnen. Es muss sowohl ein Zugriff auf die Artefakteals auch ihre Versionshistorie gewahrleistet werden. Der Benutzer muss sichuber die Inhalte der Artefakte informieren konnen und soll auch Anderungenan ihnen nachvollziehen konnen. Dazu ist es notwendig, dass er auf der einenSeite Inhalte miteinander vergleichen kann und auf der anderen Seite Zugriffzu den mit der Anderung verknupften Daten, wie z.B. Anderungskommentarbzw. ausfuhrender Benutzer hat.Besonderes Augenmerk liegt auf der Realisierung des Gruppenbewusstseins7.Die Benutzer der Plattform sollen jederzeit uber die Aktivitaten der anderenBenutzer informiert werden. Dazu ist es notwendig, dass die Repository-An-bindung die Benutzer explizit uber Veranderungen im Repository benach-richtigt. Sollte ein Mitglied einer Arbeitsgruppe auf die Fertigstellung einerTatigkeit angewiesen sein, so kann er sich nun automatisch von CURE dar-uber informieren lassen. In diesem Zusammenhang sollte auch sichergestelltwerden, dass die Benutzer automatisch Zugriff auf die aktuellsten Versionender Artefakte haben. Die Repository-Anbindung muss dementsprechend eineSynchronisation mit dem CVS-System bereitstellen.Die Einbindung der Inhalte in die Kooperationsplattform CURE soll es er-moglichen sich mit den Artefakten mit Hilfe eines einfachen Browsers aus-einanderzusetzen. Um Kommunikation und Kooperation mit den Artefaktenzu ermoglichen, muss man sich auf die Artefakte beziehen konnen. Es sollteermoglicht werden, dass der Benutzer innerhalb der Kooperationsplattformbeliebig auf die verwalteten Artefakte im CVS-System verweisen kann. Essollen folglich Assoziationen von anderen Elementen aus CURE mit denArtefakten ermoglicht werden.

7 engl. awareness


1.3 Ubersicht uber die folgenden Kapitel der Ar-beit

Diese Arbeit gliedert sich in sieben Kapitel. Anschließend an diese Ein-fuhrung wird im Kapitel zwei eine Untersuchung des Begriffs kooperativeSoftwareentwicklung vorgenommen. Hierbei wird besonderen Wert auf dieWerkzeugunterstutzung in diesem Bereich gelegt.Aus denkbaren Anwendungsszenarien der Repository-Anbindung und be-stehender Literatur zum Thema Kollaborationsplattformen werden Anfor-derungen bestimmt. Das Kapitel endet mit einer Ubersicht uber die Anfor-derungen an die Losung.

Kapitel drei untersucht den Stand der Technik im Bereich Projektunterstut-zung fur die kooperative Softwareentwicklung. Es werden sowohl universitareForschungsansatze als auch kommerzielle Ansatze vorgestellt. Hierbei wirdbesonders untersucht, wie der Zugriff auf externe Repositories unterstutztwird, wie man uber Aktualisierungen informiert wird und wie Assoziationenmit den Artefakten realisiert werden. Das Kapitel endet mit einer Ubersicht,wie die Anforderungen an diese Arbeit in den einzelnen Losungen umgesetztwurden.

Kapitel vier beschreibt den Losungsansatz dieser Arbeit. Das Kapitel be-ginnt mit der Vorstellung der Losungsidee. Daraufhin wird die Anwendungaus Benutzersicht vorgestellt. Dabei wird insbesondere diskutiert, wie dieAnforderungen umgesetzt wurden.

Kapitel funf erortert die technische Realisierung der Anwendung. Es werdenhierbei die Softwarearchitektur und einige besondere Implementierungsde-tails vorgestellt.

Kapitel sechs beschreibt weitergehende Einsatzmoglichkeiten der Arbeit. Eswerden vorstellbare Anwendungsszenarien aufgezeigt, welche durch die In-tegration der Repository-Anbindung in die Kooperationsplattform CUREmoglich werden.

Das letzte Kapitel fasst die wichtigsten Punkte der Arbeit zusammen undbewertet das Ergebnis. Es wird uber erste Erfahrungen mit dem Prototy-pen berichtet und mogliche Verbesserungs- bzw. Erweiterungsmoglichkeitendiskutiert.

Kapitel 2

Anforderungsanalyse

Im folgenden Kapitel werden die Anforderungen, welche an die Reposi-tory-Anbindung gestellt werden, beschrieben.Das Kapitel beginnt mit einer Untersuchung des Problembereichs kooperati-ve Softwareentwicklung und erlautert grundlegende Begriffe. Weiterhin wirduntersucht, welche generellen Eigenschaften von der Repository-Anbindunggefordert werden, damit diese kunftig entwicklungsunterstutzend eingesetztwerden kann. Dazu werden Merkmale aufgefuhrt, welche fur die Gruppen-arbeit in Softwareprojekten von Werkzeugen bereitgestellt werden mussen.Letztendlich werden Szenarien aufgefuhrt, die wahrend der Arbeit mit Repo-sitories innerhalb von CURE denkbar waren. Aus diesen Szenarien werdenweitere Anforderungen hergeleitet.

2.1 Detaillierte Untersuchung des Problembereichs

Im Folgenden wird dargestellt, was unter kooperativer Softwareentwicklungzu verstehen ist und wie dieser Bereich durch Werkzeuge unterstutzt werdenkann. Im Anschluss daran werden zwei CSCW-Systeme vorgestellt, welchedirekt mit der Aufgabenstellung in Verbindung stehen. Es handelt sich dabeium die Kooperationsplattform CURE, in welche die Repository-Anbindungintegriert werden soll und das Versionsverwaltungswerkzeug CVS, auf dasdie Anbindung zugreifen soll.

2.1.1 Kooperative Softwareentwicklung

Softwareentwicklung bezeichnet nach [ZR06] die Gesamtheit aller Akti-vitaten, die zu einem Softwaresystem im Einsatz fuhren. [Som04] bezeich-net Softwareeentwicklung als ”eine Menge von Aktivitaten und damit zu-sammenhangenden Ergebnissen, die zur Herstellung eines Softwareproduktsfuhren“. Der komplexe Softwareentwicklungsprozess kann strukturiert wer-den, indem die zusammengehorigen Aktivitaten zu so genannten Phasen

11

KAPITEL 2. ANFORDERUNGSANALYSE 12

gebundelt werden. Die folgenden wesentlichen Ablaufe sind in den meistenSoftwareentwicklungsprozessen vorhanden:

• Analyse,

• Entwurf,

• Implementierung,

• Validierung,

• Softwareeinfuhrung und Wartung.

Um umfangreiche Softwareprojekte zu bewaltigen bzw. zu koordinieren, sindneben den genannten traditionellen Phasen auch phasenubergreifende Akti-vitaten wie Projekt-, Konfigurations- und Qualitatsmanagement notwendig,die prozessbegleitend die Entwicklung unterstutzen [Bal98].In der Literatur zur Softwarewareentwicklung wird stets betont, dass essich dabei vorrangig um eine teamorientierte Tatigkeit handelt (vgl. z.B.[Som04]). Dies ist darauf zuruckzufuhren, dass durch die wachsende Kom-plexitat zunehmend eine Arbeitsteilung notwendig wird, welche mit einerintensiveren Zusammenarbeit einhergeht. Kommunikations- bzw. Koordina-tionsbedarf besteht zwischen den Projektmitgliedern wahrend des gesamtenarbeitsteiligen Entwicklungsprozesses. [AP99] bezeichnet den Softwareent-wicklungsprozess per se bereits als ”zeitlich und raumlich verteilten, koope-rativen Arbeitsprozess“.In der softwaretechnischen Literatur werden im Zusammenhang mit der Zu-sammenarbeit immer haufiger auch die Begriffe Kollaboration und Ko-operation verwendet, um arbeitsteilige Vorgange zu beschreiben. Kollabo-ration liegt laut [Dud06] der lateinische Begriff collaborare, co- ”zusammen“,labor ”Arbeit“ zu Grunde. Unter einer Kooperation versteht [Dud06] ”dasZusammenwirken von Handlungen zweier oder mehrerer Lebewesen“. DerWortstamm kommt ebenfalls aus dem Lateinischen von cooperatio: ”Zusam-menarbeit, Mitwirkung“. Die Begriffe ahneln sich sehr, so dass im Deutschenbeide Begriffe synonym fur Zusammenarbeit verwendet werden.Die zunehmende Aufteilung der Aufgaben und intensive Zusammenarbeitzwischen den Beteiligten machen komplexere Koordinationsmechanismennotwendig, welche die Erreichung gemeinsamer Zielsetzungen sicherstellensollen. Unter Koordination versteht [Dud06] u.a. die gegenseitige Abstim-mung von Tatigkeiten oder von Befugnissen. Bezogen auf die Softwareent-wicklung ”umfasst es alle Tatigkeiten, die zur Abstimmung von arbeitsteili-gen Aufgaben [...] notwendig sind“ [AP99]. Koordinationsmechanismen sol-len also den Benutzer bei der Planung der gemeinsamen Tatigkeiten un-terstutzen. Der Austausch von Informationen wahrend der Koordinationwird als Kommunikation bezeichnet. ”Kommunikation bildet als Prozess


der Ubermittlung und des Austausches“ die Grundlage fur jegliche Koope-ration und Koordination [Alt98]. Kommunikation ist in diesem Zusammen-hang entscheidend fur den Erfolg des Projekts. [Ver02] unterstreicht dies undnennt in seiner Analyse zu Problemen in der Softwareentwicklung ”mangeln-de Kommunikation im Projekt“ als eine der Ursachen fur die Softwarekrise.Dies sei eventuell darauf zuruckzufuhren, dass traditionelle Softwaretechni-ken Kommunikations- und Koordinationsbeziehungen zwischen den Projekt-teilnehmern nicht oder nur in unzureichenden Umfang unterstutzen.Die Kooperative Softwareentwicklung beinhaltet deshalb zusatzlich ”dieAbdeckung der Kommunikations- und Koordinationsbedarfe innerhalb ei-nes Softwareentwicklungsprozesses, die fur die Planung, Durchfuhrung undAbstimmung aller aufgabenbezogenen, zeitlich und raumlich verteilten Ak-tivitaten erforderlich sind“ [AP99]. Es werden zwei Formen der kooperativenUnterstutzung der Softwareentwicklung unterschieden [BMK95]:

• strukturierte KommunikationDamit ist die Verwaltung, Bearbeitung und der Austausch von struk-turierten Dokumenten oder Dateien gemeint.

• informelle KommunikationDamit ist der spontane und flexible Austausch von moglicherweise un-strukturierten Informationen gemeint. Dies konnten z.B. E-Mails oderChat-Nachrichten sein.

Im Zuge der fortschreitenden Globalisierung der Wirtschaft, durch inter-nationale Partnerschaften und weltweit agierende Konzerne wird auch einverteiltes Entwickeln von Software unumganglich [Kar99]. Die Unterstut-zung informeller Kommunikation ist fur verteilte Teams besonders wichtig,da es den Mitgliedern hilft eine gemeinsame Grundlage aufzubauen, welchenotwendig fur Konversationen und Kooperation ist [KP05]. Im Vergleich zurdirekten Kommunikation fallen hier wichtige Informationen fur die Einzel-person weg, da sich die Personen nicht in einem Raum befinden und somitschon einige der menschlichen Sinne nicht genutzt werden konnen. Haufigist z.B. der Stand des Projekts, die Tatigkeiten der Mitarbeiter oder derenVerfugbarkeit nicht direkt einzusehen.Diese Informationen werden in der Literatur als Awareness Informationenoder Gruppenbewusstsein bezeichnet. Die gebrauchlichste Definition von Awa-reness findet sich bei [DB92]: ”Awareness is an understanding of activitiesof others, which provides a context for your own activity.“ Awareness er-moglicht es dementsprechend dem Individuum, aktuelle Informationen oderEreignisse, die durch Anwesenheit oder Aktivitaten von Personen und Ver-anderungen an Objekten ausgelost werden, wahrzunehmen und das eigeneHandeln darauf abzustimmen.Das fehlende Gruppenbewusstsein in einer verteilten Arbeitswelt muss da-her als Nachteil angesehen werden [Sch05]. Die Projektteilnehmer konnen


nur uber Hilfsmittel miteinander kommunizieren, wodurch eine vollig an-dere Wahrnehmung entsteht. Diese Wahrnehmungsprobleme mussen durchbesondere Werkzeugunterstutzung bestmoglich kompensiert werden, damitdie Verteilung nicht kontraproduktiv wirkt.

Werkzeugunterstutzung

In der Forschung und am Markt existieren bereits eine Vielzahl von Ansat-zen, wie Zusammenarbeit auf Projektebene unterstutzt werden kann. Fol-gende Kategorien von Werkzeugen werden in diesem Abschnitt voneinan-der abgegrenzt: Groupware, Integrierte Entwicklungsumgebungen und Kol-laborationsplattformen. Diese Einteilung der Werkzeuge wurde ebenso in[HRH06] gemacht.Als Groupware bezeichnet man eine Software zur Unterstutzung der Zu-sammenarbeit in einer Gruppe uber zeitliche und/oder raumliche Distanzhinweg. Anfangs wurden in Softwareprojekten Groupware-Systeme in Ver-bindung mit Editoren, Compilern und Versionsmanagementsystemen vonden Entwicklern genutzt. Wobei anzumerken ist, dass es sich hierbei jeweilsum separate Werkzeuge handelte. Integrierte Entwicklungsumgebun-gen hingegen versuchen dem einzelnen Entwickler eine einheitliche Ober-flache und Arbeitsumgebung fur die Softwareerstellung zu prasentieren unddadurch mehr Produktivitat zu gewahrleisten. Erweiterte Koordinations-und Kommunikationsfunktionen fur die synchronen und asynchrone Zusam-menarbeit von raumlich verteilten Entwicklern und Entwicklungsgruppenbieten so genannte Kollaborationsplattformen, wie sie im Rahmen vonOpen-Source-Projekten bereits haufig erfolgreich eingesetzt wurden [KL05].

Groupware ”Groupware sind Anwendungssysteme, welche die rechnerge-stutzte Zusammenarbeit von Gruppen nicht nur ermoglichen, sondern auchproduktiv unterstutzen“ [SSU01]. Laut [BS98] ist Groupware die Umsetzungder theoretischen Grundlagen, welche im Rahmen von CSCW spezifiziertwurden, in eine konkrete Anwendung. Der Begriff Groupware wurde vonPeter und Trudy Johnson-Lentz [JLJL94] eingefuhrt. CSCW-Systeme undGroupware werden in der Literatur haufig als synonyme Begriffe verwendet.Die moglichen Einsatzgebiete sind vielfaltig, wobei auch in der Literatur oftdas Einsatzgebiet Softwareentwicklung hervorgehoben wird [PG95].Bei der Unterstutzung im Bereich kooperativer Softwareentwicklung durchCSCW-Systeme wird innerhalb dieser Arbeit anlehnend an [TSB95] zwi-schen Kommunikations-, Koordinations- oder Kooperationshilfen unterschie-den:

• KommunikationswerkzeugeKommunikationssysteme unterstutzen raumlich und zeitlich verteilte


Projektgruppen bei der Verwaltung und dem Austausch von Informa-tionen.

• KoordinationswerkzeugeDiese Systeme dienen der Abstimmung von aufgabenbezogenen Akti-vitaten im Rahmen der Gruppenarbeit.

• KooperationswerkzeugeKooperationswerkzeuge unterstutzen direkt die Zusammenarbeit zwi-schen den Projektteilnehmern, welche ein gemeinsames Ziel verfolgen.Dies bedeutet im Wesentlichen die Bearbeitung von Artefakten.

Wahrend sich die Einsatzgebiete noch relativ einfach beschreiben lassen, istdie Zuordnung in den meisten Fallen nicht so einfach. Die Ursache dafurist die Tatsache, dass die Werkzeuge mehrere Arbeitsbereiche gleichzeitigunterstutzen. Abbildung 2.1 verdeutlicht diesen Sachverhalt. Die Ecken desDreiecks bestimmen die Zuordnung zu einem Themengebiet.

Abbildung 2.1: Unterstutzung von kooperativer Softwareentwicklung durchGroupware (angelehnt an [TSB95])

Es wird dargestellt, dass es Werkzeuge gibt, welche nur Kommunikation wiez.B. Newsgroups/Foren, nur Kooperation wie z.B. Gruppeneditoren odernur Koordination wie z.B. ein elektronischer Kalender unterstutzen. Es exis-tieren aber auch themenubergreifende Hilfsmittel. Ein besonderes Beispieldafur ist ein Versionsverwaltungssystem. Es unterstutzt sowohl die Koor-dinierung des gemeinsamen Zugriffs als auch gleichzeitige Entwicklung aneinem Artefakt.Ein weiteres universelles System ist ein Wiki [EGH05]. Ein Wiki ist einegemeinschaftlich bearbeitete Webseite, die oft aus tausenden Einzelseitenbesteht. Es wird ermoglicht, dass jeder Leser dem Text etwas hinzufugen,


andern oder loschen kann. Grundlage der Wiki-Konzepts ist, dass auch Per-sonen ohne Erfahrung diese Seiten direkt im Browser verandern und spei-chern konnen. Dazu stellt eine Wiki-Seite in der Regel ein einfaches Ein-gabefenster zur Verfugung, in dem der Text des Artikels bearbeitet werdenkann. Wie bei Webseiten ublich, sind die einzelnen Seiten und Artikel einesWikis durch Querverweise miteinander verbunden. Ein bekanntes Beispielfur ein Wiki ist Wikipedia [WIK07].Der Einsatz von Groupware allein verspricht jedoch keine Verbesserungen imSoftwareentwicklungsprozess. Das Problem ist, dass durch die vielen Werk-zeuge die Produktivitat eher sinkt, da man sich mit der Anwendung derWerkzeuge immer wieder vertraut machen muss. Es gibt daher Initiativen di-verse Eigenschaften von CSCW-Anwendungen in Entwicklungsumgebungenzu ubernehmen. Dazu zahlen vor allen Dingen die Integration eines Gruppen-bewusstseins und von Kommunikationsmoglichkeiten (vgl. TUKAN [Sch99],FLECSE [SSU01] oder eine Eclipseerweiterung namens Jazz [CHRP03]).

Integrierte Entwicklungsumgebung Eine Integrierte Softwareentwick-lungsumgebung oder IDE ist eine Sammlung von aufeinander abgestimmtenSoftware- und Hardwarewerkzeugen, die zusammenarbeiten und eine um-fassende Unterstutzung fur den Softwareerstellungsprozess bieten [Som04].Im Idealfall sollte eine solche Umgebung durch die Integration von Metho-den und Verfahren, sowie deren Automatisierung, Unterstutzung fur samt-liche Phasen und Aktivitaten des Softwarelebenszyklus bieten [Bal98]. IDEswerden als eine Kombination von Groupware-Anwendungen gesehen, diefur einen speziellen Anwendungsbereich, die Softwareentwicklung, bestimmtsind [Piw02].Integrierte Entwicklungsumgebungen unterstutzen zwar die kooperative Soft-wareentwicklung, eignen sich jedoch weniger um alle Projektbeteiligten, ins-besondere Tester oder Projektmanager, in Kooperation und Kommunikationzu unterstutzen. Es wird daher auf eine tiefergehende Untersuchung verzich-tet.

Kollaborationsplattformen Um den speziellen Anforderungen der Teil-nehmer eines Softwareprojekts Rechnung zu tragen, ist zusatzlich zur Werk-zeugunterstutzung der einzelnen Phasen eine zentrale Kollaborationsplatt-form zur Projektkoordination notwendig. ”Kollaborationsplattformen furdie Softwareerstellung stellen eine Erweiterung von serverbasierten CSCW-Losungen speziell fur das SE1 dar“ [HRH06]. [BB03] argumentieren, dasssich die grundlegenden Funktionalitaten einer Kollaborationsplattform indie Kategorien Koordination, Kollaboration und Community Building un-terteilen lassen. Sie meinen, dass eine Kollaborationsplattform ein virtuellerOrt ist, in dem alle Projektteilnehmer - unabhangig von Ort oder Zeit -

1 Abk. Software Engineering


zusammen am Projekt arbeiten konnen. Eine eher pragmatische Definitioneiner Kollaborationsplattform geben [Kai04]. Dort heißt es, eine Kollabo-rationsplattform stellt zentral fur ein Projekt Zugang zu Versionierungs-systemen, Wissensmanagement, Diskussionslisten, Bug-Tracking-Systemenund Benutzersupport bereit. [Wu03] stellt fest, dass es bei verteilter Soft-wareentwicklung oft vorkommt, dass die jeweiligen Teams unterschiedlicheWerkzeuge benutzen und verschiedene Ablaufe befolgen, um ihre Aufgabezu erfullen. Es kann dabei passieren, dass die Kommunikation mit anderenGruppen nur erschwert moglich ist. Eine Kollaborationsplattform dient des-halb dazu allen eine gemeinsame Sicht auf das Produkt zu vermitteln. DerZugriff auf diese Plattform sollte deshalb mit moglichst einfachen Mitteln -wie z.B. einem Webbrowser - moglich sein sollte, damit kein spezielles Werk-zeug genutzt werden muss, welches eventuell nicht zur Verfugung steht.Kollaborationsplattformen werden in der Literatur auch als CDE2 [BB03],[FB05] oder CVE3 [CS01] bezeichnet. Die Funktionalitaten einer kollabora-tiven Umgebung lassen sich laut [HRH06], wie bereits angedeutet, in dreiKategorien gruppieren: Wissensaustausch, Kommunikations- und Koordina-tionsunterstutzung. Es wird dort auch festgestellt, dass Kollaborationsplatt-formen sehr haufig in der Entwicklung von Open-Source-Software eingesetztwerden. Dies wird darauf zuruckgefuhrt, dass die Entwicklung bei dieser Artvon Projekten oft nur raumlich und zeitlich verteilt stattfindet. Dabei sinddie Entwickler besonders auf Werkzeugunterstutzung im Bereich Kommuni-kation, Koordination und Kooperation angewiesen.

Laut [BB03] soll eine kollaborative Entwicklungsumgebung webbasiert, ar-tefaktorientiert und multidimensional sein. Es wird hier ebenfalls betont,dass die verschiedenen Projektteilnehmer unterschiedliche Anforderungenan Werkzeuge haben und nicht alle die gleichen Artefakte bearbeiten mus-sen. Daher muss eine Kollaborationsplattform multidimensional, d.h. an dieverschiedenen Bedurfnisse angepasst bzw. anpassbar sein. Unter dem Be-griff Artefaktorientierung wird die Bedeutung des Zugriffs auf die Artefaktedes Entwicklungsprozesses hervorgehoben. Der Zugriff auf alle notwendigenDokumente sollte gewahrleistet werden, damit Kommunikation und Koordi-nation immer mit Bezug zu den Artefakten gefuhrt werden kann. Abbildung2.2 verdeutlicht das geschilderte Modell.

2 Abk. Collaborative Development Environment3 Abk. Collaborative Virtual Environments


Abbildung 2.2: Modell einer Kollaborationsplattform (entnommen aus[BB03])

Die folgende Auflistung stellt eine Zusammenfassung der Anforderungen aus[CS01], [BB03], [Kai04] und [FB05] dar, welche generell an Kollaborations-plattform gestellt werden:

• gemeinsamer ArbeitsbereichDer Zweck eines gemeinsamen Arbeitsbereichs besteht in der Bereit-stellung und konsistenten Verwaltung von prozess- und produktbezo-genen Artefakten. Die Organisation des Arbeitsbereiches umfasst dieFestlegung der dazugehorigen Mitarbeiter, der Arbeitsmaterialien undder Werkzeuge, die fur die Zusammenarbeit verwenden werden kon-nen.

• Gruppenorientierte Sicht auf den ArbeitsprozessDie Aktivitaten innerhalb eines Projekts werden in der Regel auf ver-schiedene Projektmitarbeiter aufgeteilt. Aufgrund der Aufgabenver-teilung benotigen die Projektteilnehmer eine individuelle Sicht auf dieentstandenen Artefakte. Es mussen daher abgetrennte Bereiche ge-schaffen werden konnen, die das jeweilige Arbeitsgebiet widerspiegeln.

• Bereitstellung von DokumentenVordefinierte Dokumente helfen den Projektteilnehmern Sachverhalteeinheitlich zu erfassen und zu strukturieren. Ein zentraler Aspekt da-bei ist die Bereitstellung, ubersichtliche Darstellung und Verwaltunggemeinsam benutzter Dokumente.

• Forderung eines GruppenbewusstseinsDer Aufbau eines Gruppenbewusstseins erfordert, dass fur alle Pro-


jektteilnehmer die Struktur und der Fortschritt des Entwicklungspro-zesses ersichtlich gemacht wird.

Dies setzt einen Ereignis- bzw. Benachrichtigungsdienst voraus, derdie Projektteilnehmer uber Aktivitaten informiert und die Orientie-rung uber die Aktivitaten der Kooperationspartner in einem Projektermoglicht [Alt98].

• expliziter und impliziter InformationsaustauschExpliziter Informationsaustausch zwischen Softwareentwicklern erfolgtdurch das Versenden von Nachrichten, das Anfertigen von Dokumenta-tionen oder beispielsweise durch Entwicklungsbesprechungen. Als Me-dien konnen dazu E-Mailsysteme, Chats, Newsforen und Dokumenten-managementsysteme eingesetzt werden.

Impliziter Informationsaustausch soll dann erfolgen, wenn Anderun-gen an Artefakten vorgenommen werden. Diese Anderungen sollte dasWerkzeug automatisch in der gemeinsamen Arbeitsumgebung hervor-heben. Es sollten dementsprechend von der Losung verschiedene Kom-munikationsmoglichkeiten bereitgestellt werden, um sowohl zeit- undortsunabhangige als auch synchrone Kommunikation zu gewahrleisten.

• ProduktorientierungDie wichtigsten Artefakte in der Softwareentwicklung sind Quellco-dedateien. In einer Kollaborationsplattform ist der Zugriff auf dieseDokumente bereitzustellen. In diesem Zusammenhang ist es beson-ders wichtig, dass sich die Benutzer der Losung mit den Artefaktenauf unterschiedliche Weise auseinandersetzen konnen. Dies bedeutetnicht nur, dass sich die Benutzer uber die Inhalte informieren, sondernauch beliebig innerhalb der Losung auf die Artefakte verweisen konnenmussen. Weiterhin ist es sinnvoll die Artefakte nicht nur innerhalb derLosung zur Verfugung zu stellen, vielmehr sollte der Benutzer auchoffline darauf zugreifen konnen, damit er sie mit Werkzeugen seinerWahl weiter bearbeiten kann.Die Speicherung von Quellcodedateien erfolgt bei grossen Software-projekten innerhalb von Versionierungswerkzeugen. Diese ermoglichenbereits eine zentrale Ablage von Artefakten und die Speicherung derAnderungshistorie. Es ist somit nicht erforderlich, dass man innerhalbvon Kollaborationsplattformen eine eigene proprietare Losung schafft.Vielmehr ist es notwendig, dass man von den Kollaborationsplattfor-men auf diese Versionierungswerkzeuge geeignet zugreifen kann.

• Transparenz der ProzessgeschichteWahrend des Entwicklung entsteht eine Prozessgeschichte, die entspre-chend dokumentiert und fur einen spateren Zugriff den Projektbetei-ligten verfugbar gemacht werden muss. Die Dokumentation soll z.B.


Informationen uber die durchgefuhrten Aktivitaten, Abhangigkeitenzu anderen Aktivitaten und spezielle Erkenntnisse, welche im Laufedes Projekts gesammelt wurden, bereitstellen. Dies verbessert das Ge-samtverstandnis und gewahrleistet eine effiziente Problemlosung durchWiederverwendung von Erfahrungswissen der Projektmitarbeiter. ImSoftwareentwicklungsprozess ist es deshalb nicht nur wichtig, Doku-mente und Programmcode bereitzustellen, vielmehr sollte die gesamteVersionshistorie zugreifbar sein.

• Rollen- bzw. RechtesystemOftmals ist es innerhalb einer Projektgruppe so, dass die Teilnehmernicht alle Tatigkeiten ausfuhren durfen. Die Projektteilnehmer habenaufgrund ihrer unterschiedlichen Aufgaben verschiedene Berechtigun-gen. Es wird in diesem Zusammenhang von einer Rolle gesprochen.Aus technischer Sicht sind Rollen Klassifizierungen von Benutzern,uber deren Zuordnung den Benutzern bestimmte Rechte eingeraumtwerden konnen. Es ist daher wichtig diese Rollen auch geeignet in derKollaborationsplattform abbilden zu konnen.

2.1.2 CURE

Im folgenden Abschnitt soll die Kooperationsplattform CURE vorgestelltwerden. Nach der Vorstellung folgt eine Untersuchung, welche der genanntenAnforderungen die Kooperationsplattform bereits erfullt und welche nochumgesetzt werden mussen.

Das CSCW-System CURE [HSB+04] wird seit 2002 an der Fernuniversitatin Hagen entwickelt. Es wird zur Unterstutzung der Lehre an der Fernuni-versitat bereits erfolgreich eingesetzt. Dabei ermoglicht es CURE uber einenComputer mit anderen Fernstudenten und Betreuern der Fernuniversitatgemeinsam an Lerninhalten zu arbeiten [Haa07].CURE basiert auf der Metapher der virtuellen Raume ([GR98], [PWBW+98]),die haufig zur Strukturierung von Arbeitsgemeinschaften eingesetzt wird.Hierbei dient ein Raum der Reprasentation eines virtuellen Orts fur dieZusammenarbeit. Raume konnen miteinander verbunden werden. So kannuber einen Einstiegsraum und eine hierarchisch organisierte Raumstruktureine komplette virtuelle Universitat abgebildet werden. Ein Beispiel fur dieDarstellung eines Raumes in CURE ist in Abbildung 2.3 zu sehen.Inhalte von Raumen werden in Form von Seiten modelliert. Eine Seite kannhierbei im einfachsten Fall nur Text enthalten. Ein weiterer Seitentyp, dieBinarseite, ermoglicht die Ablage von beliebigen Dokumenten z.B. Bildernoder Tabellenkalkulationen. Seiten konnen von allen Nutzern mit den no-tigen Zugriffsrechten innerhalb eines Raumes nicht nur angesehen, sondernauch editiert werden. Hierdurch ermoglicht CURE die kollaborative Arbeit


Abbildung 2.3: Ein Raum in CURE

einer Gruppe an gemeinsamen Artefakten. CURE-Seiten stellen daher nichtstatische Inhalte dar, sondern konnen als kontinuierlich in Bearbeitung ste-hende Dokumente betrachtet werden. Um zu verhindern, dass bei Ande-rungen die ursprunglichen Inhalte verloren gehen, sind CURE-Seiten versio-nierbar. Es wird daher jeweils eine neue Seite mit dem geanderten Inhaltgespeichert, wahrend altere Versionen weiterhin erreichbar bleiben.Der Inhalt von Textseiten kann unter Verwendung einer leicht erlernbarenFormatierungssprache, einer sogenannten Wiki-Syntax, formatiert und mitQuerverweisen auf andere Seiten, sowie externe Quellen versehen werden.Um die Zusammenarbeit im Arbeitsbereich zu unterstutzen, werden die an-wesenden Benutzer in einem Raum angezeigt. Weiterhin ist es moglich, sichuber die Aktionen der anderen Benutzer informieren zu lassen (Awareness).Dazu steht eine besondere Seite zur Verfugung, in der man sich die Aktivita-ten eines Raumes auflisten lassen kann. Es ist auch moglich sich mit Hilfe sogenannter Tagesberichte uber alle Veranderungen benachrichtigen zu lassen.Es werden synchrone bzw. asynchrone Kommunikationsmedien unterstutzt.CURE besitzt ein integriertes E-Mail-System, mit dem Nachrichten zwi-schen internen und externen Benutzern ausgetauscht werden konnen. Es istmoglich Nachrichten an Raume zu schicken, welche an alle Benutzer diesesRaumes weitergeleitet werden. Weiterhin steht ein raumbezogener Chat zurVerfugung. An einem Chat konnen alle Benutzer eines Raumes teilnehmen.Sowohl in Mails als auch in Chatnachrichten konnen Verweise auf internebzw. externe Inhalte platziert werden. Diskussionen konnen somit immermit Kontextbezug gefuhrt werden. Als weitere Kommunikationsmoglichkeitkonnen die Wiki-Seiten angesehen werden. Damit wird die Moglichkeit be-reitgestellt Fragen zu stellen, eigene Erganzungen anzubringen oder Erfah-rungen mit anderen Benutzern zu teilen.Die beschriebenen Elemente der Kooperationsplattform werden noch einmal


in Abbildung 2.4 zusammengefasst.

Abbildung 2.4: Modell von CURE (entnommen aus [HSB+04])

Der Zugriff auf den Inhalt von Raumen wird passend zum Raumkonzeptdurch das Konzept virtueller Schlussel [HSB+04] geregelt. Schlussel konnenvom Erzeuger eines Raumes an berechtigte Personen vergeben werden. Da-bei kann nicht nur das Recht zum Betreten eines Raumes zugewiesen werden,vielmehr werden dabei auch detailliertere Rechte z.B. zum Erzeugen neuerUnterraume, zum Bearbeiten bzw. Betrachten von Inhalten, zur Nutzungvon Kommunikationswerkzeugen sowie zur eigenstandigen Weitergabe undErzeugung von Schlusseln zugeteilt. Dieses Konzept erlaubt eine weitgehen-de Selbstorganisation von Arbeitsgruppen, da die Gruppenbildung durch dieVergabe von Schlusseln und deren detaillierte Konfigurierbarkeit dynamischgestaltet werden kann.

CURE als Kollaborationsplattformen

Ausgehend von den Anforderungen an eine Kollaborationsplattform in Ab-schnitt 2.1.1 soll nun CURE daraufhin untersucht werden, welche Eigen-schaften bereits fur dieses Einsatzgebiet genutzt werden konnen und welchenoch realisiert werden mussen. Dabei werden nur die Eigenschaften von CU-RE dargestellt, welche fur eine Kollaborationsplattform in Softwareprojek-ten von Vorteil sind.

Gemeinsamer Arbeitsbereich CURE basiert wesentlich auf dem Raum-konzept. Ein Raum dient dabei als ein Knotenpunkt fur zusammengehorigeMaterialien im Sinne eines Wissens- bzw. Kooperationsraumes und als einzentraler Ort fur Kommunikation und Koordination. Im Mittelpunkt derArbeit mit Raumen steht der Gruppenkontext. Sobald ein Benutzer einenRaum betritt, findet er einen gemeinsamen Arbeitsbereich vor. Der Benutzerkann diesen Arbeitsbereich selbst mit Inhalten fullen. Dazu kann er verschie-dene Seiten anlegen bzw. Dokumente zur Verfugung stellen.

Gruppenorientierte Sicht auf den Arbeitsprozess Der Benutzer kanneinen Raum in Kooperation mit den anderen Projektteilnehmern an das


jeweilige Aufgabengebiet anpassen. Im Laufe der Zeit entsteht somit einBereich, in dem alle Artefakte zur Verfugung stehen, welche der Projekt-teilnehmer zur Arbeit benotigt. Sollte der Benutzer Mitglied in mehrerenArbeitsgruppen sein, so gewahrt man ihm Zugriff auf mehrere Raume. Imjeweiligen Raum der Arbeitsgruppe findet er die benotigte Umgebung vorund hat somit eine optimale Sicht auf den Arbeitsprozess der Gruppe.

Bereitstellung von Dokumenten CURE stellt bereits eine Moglichkeitzur Ablage von Dokumenten zur Verfugung. Diese Ablage konnte nun dazugenutzt werden um die Aktivitaten von Kooperierenden zu steuern. Das Ma-terial konnte z.B. eine Aufgabenliste mit offenen Aktivitaten oder Beschrei-bung des Arbeitsablaufs sein. Die Bereitstellung von gemeinsamen Materialmacht den Zustand des Gesamtsystems fur alle Akteure transparent. Lei-der ist es nur moglich auf die Dokumente zuzugreifen, welche innerhalb derPlattform gehalten werden. Wunschenswert ware aber eine Anbindung anbestehende Versionsverwaltungssysteme, wie z.B. CVS. Dies hatte den Vor-teil, dass sowohl innerhalb von CURE als auch mit Hilfe externer Clientsauf die Inhalte zugegriffen werden kann.Weiterhin ist es moglich, dass die Projektteilnehmer sich kooperativ amSchreiben von Dokumenten betatigen. Dazu steht ihnen bespielsweise derSeitentyp Wiki-Seite zur Verfugung. Die Wiki-Seite stellt eine Art Hyper-text4 dar. Die Einsatzmoglichkeiten von Hypertext reichen von der Unter-stutzung der Kooperation zwischen den an der Entwicklung beteiligten Per-sonen, Dokumentation des Softwaresystems bis hin zu hypertextbasiertenBenutzerdokumentationen.

Forderung des Gruppenbewusstseins Die Benutzer des Systems kon-nen einander wahrnehmen. Dazu informiert CURE welche Personen sich ak-tuell im Raum befinden. Dies wird dadurch realisiert, dass der Name oder so-fern vorhanden ein Bild des anwesenden Benutzers immer sichtbar im Raumangezeigt werden. Weiterhin ist es moglich sich uber die Aktivitaten inner-halb eines Raumes zu informieren. Dazu pflegt CURE Informationen uberalle Seiten des Raumes und den damit verbundenen Aktivitaten, wie dasAnlegen, die Bearbeitung oder das Loschen einer Seite. Personen in einemRaum nehmen somit einander sowie ihre Handlungen wahr und konnen sichso koordinieren. CURE unterstutzt dementsprechend in einigen Teilen diebereits in Kapitel 2.1.1 geforderte ”Forderung eines Gruppenbewusstseins“.Ein Nachteil ist jedoch, dass sich ein Benutzer aktiv uber die Anderungeninformieren muss. Dazu muss er bestimmte Seiten aufrufen, die ihn uberdie Anderungen an den Artefakten innerhalb eines bestimmten Zeitraumes

4 Dies ist eine Organisation von Textdokumenten, deren Struktur durch logische Ver-bindungen (so genannte Hyperlinks) zwischen den einzelnen Wissenseinheiten erwei-tert wird.


informieren. Interessanter ware es, wenn der Benutzer im aktuellen Kontextz.B. uber die Fertigstellung einer Teilaufgabe informiert werden wurde.

Expliziter und impliziter Informationsaustausch CURE stellt Mog-lichkeiten zur synchronen und asynchronen Kommunikation zur Verfugung.Die Werkzeuge wurden bereits im letzten Abschnitt erlautert. An dieser Stel-le soll kurz erlautert werden, wie die verschiedenen Moglichkeiten zur Unter-stutzung des Softwareentwicklungsprozesses eingesetzt werden konnen. DasE-Mail-System der CURE-Plattform konnte als Mailingliste benutzt werdenum Ankundigungen an das gesamte Projektteam zu versenden. Es konntendadurch alle Projektteilnehmer mit einer Nachricht erreicht werden. Der in-terne Chat konnte beispielsweise fur Schnittstellenbesprechungen oder zurBeantwortung von Fragen zur Benutzung von Schnittstellen genutzt werden.Der bereits erwahnte Einsatz von Wiki-Seiten kann ebenfalls als asynchroneKommunikation angesehen werden. Dabei konnten Wiki-Seiten dazu genutztwerden um Fragen zu Quellcodeabschnitten zu stellen und dabei direkt aufdie fragwurdigen Artefakte zu verweisen.

Produktorientierung Der Zugriff auf Quelltexte ist in einer Kollabora-tionsplattform fur Softwareentwicklung unbedingt notwendig. Um die Kom-munikation, Koordination und Kooperation mit Bezug zum Produkt zu er-moglichen, bedarf es eines Zugriffs auf alle Artefakte.Innerhalb von CURE wird dieser Zugriff bisher nicht bereitgestellt. Es wa-re zwar denkbar die Artefakte als Binarseite bereitzustellen. Im Laufe derEntwicklung ware jedoch immer eine manuelle Aktualisierung der Inhaltenotwendig. Dies ware sehr zeitaufwandig und wurde die Entwicklung eherstoren als unterstutzen. Besser ware hier eine werkzeuggestutzte Einbin-dung der Quellcodedateien, welche eine automatische Synchronisation mitden Repositories vorsieht.

Transparenz der Prozessgeschichte In CURE importierte Dokumen-te und erstellte Seiten unterliegen einer Versionskontrolle. Somit ist es imlaufenden Projekt und in der Projektnachbetrachtung moglich die Historieeines Dokuments bzw. einer Seite nachvollziehen zu konnen. Weiterhin lie-gen alle E-Mails bzw. gefuhrten Chats auch zur Nachverfolgung innerhalbder Plattform bereit.Leider ist es derzeit nur moglich auf die Prozesshistorie von Artefakten zu-zugreifen, welche sich innerhalb der Kooperationsplattform befinden. DieRepository-Anbindung soll diesen Nachteil jedoch beheben und den Zu-griff auf die Prozesshistorie von jeglichen Artefakten, welche innerhalb einesCVS-Systems verwaltet werden, ermoglichen.


Rollen- bzw. Rechtesystem CURE unterstutzt diese Anforderung be-reits durch sein Schlusselsystem. Eine Person kann beispielsweise einen Raumnur betreten oder bestimmte Tatigkeiten ausfuhren, wenn sie den dafur not-wendigen Schlussel besitzt.

CURE erfullt bereits viele Anforderungen, welche in Kapitel 2.1.1 gestelltwurden. Diese waren jedoch bisher nicht softwareprozessspezifisch, sondernallgemein. Es gibt bisher wenige Bezugspunkte zum eigentlichen Produktder Softwareentwicklung - dem Quellcode. An dieser Stelle soll mit der hiervorgestellten Arbeit angesetzt werden.

2.1.3 Versionsverwaltung

Da Quellcodeartefakte innerhalb von Versionsverwaltungswerkzeugen gehal-ten werden, soll an dieser Stelle untersucht werden, wie diese Werkzeugedie kooperative Softwareentwicklung unterstutzen und welche Eigenschaf-ten und Schnittstellen sie bereitstellen.

Eine Versionsverwaltung ist ein spezielles CSCW-System, welches vor allenDingen in der Softwareentwicklung zur Versionierung von Artefakten ge-nutzt wird. Bei einem Artefakt unter Versionsverwaltung wird dessen Inhaltbei Anderungen nicht einfach uberschrieben, vielmehr wird eine zusatzlicheVersion erzeugt. Der Zugriff auf die alte Version ist weiterhin moglich.Die Hauptaufgaben eines Versionsverwaltungssystems zeigt die folgende Auf-listung, welche sich eng an [BF03] anlehnt:

• Protokollierungen der AnderungenEs werden Anderungen an den Dokumenten erfasst und alle Versions-stande in einem Archiv mit Zeitstempel und Benutzerkennung gesi-chert. Es kann jederzeit nachvollzogen werden, welche Anderung ein-gebracht wurde.

• Wiederherstellung von alten Standen einzelner ArtefakteIn bestimmten Fallen ist es notwendig auf altere Versionsstande einesArtefakts zuruckzugreifen. Dies kann insbesondere beim Test einer be-stimmten Softwareversion oder beim Entfernen von versehentlich ein-gebrachten Anderungen notwendig sein. Das Versionskontrollsystemmacht es deshalb moglich, dass Anderungen jederzeit wieder ruckgan-gig gemacht werden konnen.

• Archivierung der einzelnen Releasestande eines ProjektsDie Versionsverwaltung kann genutzt werden um alle Releasestande,welche beispielsweise an Kunden ausgeliefert wurden, zu speichern. Eskann daher jeder Auslieferungszustand wieder hergestellt werden umbeispielsweise Fehler nachzuvollziehen.


• Koordinierung des gemeinsamen Zugriffs von mehreren Entwicklernauf die DateienSoftwareprojekte bestehen aus einer Menge von Artefakten, welchedurch mehrere Entwickler bearbeitet werden. Um Inkonsistenzen beimVerandern der Artefakte zu vermeiden, muss der Zugriff koordiniertwerden.

• Gleichzeitige Entwicklung mehrerer EntwicklungszweigeEs ist oftmals notwendig mehrere Entwicklungszweige eines Projektszu pflegen. Dies kann z.B. der Fall sein, wenn eine stabile Releaseversi-on und eine Entwicklerversion mit großeren, nicht getesteten Anderun-gen gepflegt werden mussen. Das Versionsverwaltungssystem verwaltetdabei unabhangige Zweige, auf denen auch separate Anderungen ein-gebracht werden konnen. Es unterstutzt die Entwickler zusatzlich beider Ubernahme von einzelnen Anderungen zwischen den Zweigen.

Es gibt folgende verschiedene Arbeitsweisen einer Versionsverwaltung. DieseArbeitsweisen bestimmen, wie mit dem Werkzeug gearbeitet werden kann.

• Lock Modify Write [BF03]Dies ist die traditionelle Arbeitsweise eines Versionsverwaltungssys-tems und wird auch als Lock Modify Unlock bezeichnet. Die zugrun-deliegende Philosophie wird auch Pessimistische Versionskontrolle ge-nannt. Dabei mussen die Artefakte vor einer Anderung durch den Be-nutzer gesperrt und nach Abschluss der Anderung wieder freigegebenwerden. Wahrend sie gesperrt sind verhindert das System Anderungenanderer Benutzer.

• Copy Modify Merge [BF03]Die zugrundeliegende Philosophie wird hierbei als optimistische Ver-sionskontrolle bezeichnet. Es wurde entwickelt, um die Schwachen desvorherigen Ansatzes, wie z.B. kein gleichzeitiges Verandern der Arte-fakte zu beheben. Ein solches System erlaubt es, dass mehrere BenutzerAnderungen an einer Datei vornehmen konnen.

Bekanntester Vertreter des Copy Modify Merge-Ansatzes ist das ConcurrentVersions System, welches nun kurz vorgestellt werden soll.

Concurrent Versions System - CVS

Das Concurrent Version System, kurz CVS, ist eines der popularsten Versi-onsverwaltungssysteme uberhaupt [BF03]. Die hohe Verbreitung ist nebenseiner Zuverlassigkeit darauf zuruckzufuhren, dass es seit seiner Entstehung,Mitte der 80-er Jahre, kostenfrei fur nahezu jedes Betriebssystem verfugbarist. CVS dient aufgrund seiner Funktionsweise vorrangig fur die Verwal-tung von Textdateien. Es bietet sich daher an Quellcodedateien aus dem


Entwicklungsprozess mit Hilfe von CVS zu verwalten. CVS vereinfacht dieVerwaltung von Quellcode dadurch, dass es alle Artefakte eines Projekts aneiner zentralen Stelle, einem so genannten Repository, speichert. Das Reposi-tory liegt dabei zwar in einem gewohnlichen Dateisystem, der Zugriff auf dieArtefakte soll jedoch nur mit einem speziellen Client getatigt werden. Diessorgt unter Anderem dafur, dass die Datenhaltung konsistent bleibt und alleAnderungen protokolliert werden konnen. Ein Zugriff bzw. eine Anbindungan CVS-Repositories existiert bereits in vielen Entwicklungswerkzeugen.Die Arbeitsweise beim Umgang mit CVS ist, vereinfacht gesehen, folgende:Ein Projektteilnehmer holt sich zunachst den aktuellen Stand aller Artefak-te eines Projekts aus dem Repository. Dies bezeichnet man als auschecken(engl. checkout). Ein Projekt wird innerhalb von CVS auch Modul genannt.Der Benutzer kann aber auch spezifizieren welchen Versionsstand er auswah-len mochte. CVS benutzt hierzu die Begriffe Tag, Revision oder Branchname.Beim Auschecken werden von CVS zusatzliche Daten im lokalen Dateisys-tem angelegt, die es ermoglichen, zu erkennen, welche Versionen der Dateienselektiert wurden. Der Benutzer kann daraufhin beliebig Anderungen an denVersionen vornehmen. Wenn er die Anderungen abgeschlossen hat, spielt erdiese neuen Versionen der geanderten Dateien mit Hilfe des CVS-Clients zu-ruck ins Repository. Der Vorgang wird auch einchecken (engl. checkin) odercommit genannt. Dabei werden die zusatzlichen Daten, welche beim Ausche-cken erzeugt wurden, fur die Synchronisation mit dem CVS-Server genutzt.Probleme konnen sich ergeben, wenn in der Zwischenzeit andere Versionender gleichen Datei eingecheckt wurden. Dabei ist ein Zusammenfuhren derAnderungen (engl. merge) notwendig. Das Zusammenfuhren wird, wenn essich um unterschiedliche Zeilen einer Datei handelt, automatisch von CVSubernommen. Wenn Anderungen an einer Zeile vorgenommen werden, mussder Benutzer diesen Konflikt manuell beheben und entscheiden, welche An-derung ubernommen werden soll.CVS unterstutzt direkt das Gruppenbewusstsein der Entwickler. Dazu istes moglich sich beim CVS-Server fur bestimmte Ereignisse zu registrieren.Sollte das Ereignis auftreten, so wird man per E-Mail daruber benachrich-tigt. So ist es beispielsweise moglich, dass man sich informieren lasst, sobaldeine Veranderung an einem Artefakt vorgenommen wird.

2.2 Herleitung von anwendungsspezifischen Anfor-derungen

Nachdem im letzten Abschnitt die Notwendigkeit der Anbindung an einVersionsverwaltungswerkzeug beschrieben wurde, sollen in diesem Kapiteldetailliertere Anforderungen an diese Anbindung beschrieben werden.Im Anschluss werden jetzt an Hand von denkbaren Benutzerszenarien An-forderungen an die Losung hergeleitet.


2.2.1 Allgemein

Es existieren verschiedene Versionsverwaltungswerkzeuge, welche jeweils an-dere Zugriffsmoglichkeiten bereitstellen. Ein ausfuhrlicher Vergleich von denFunktionsumfangen verschiedener Tools befindet sich beispielsweise unter[Fis07]. Diese Arbeit beschrankt sich aufgrund des geplanten Einsatzgebie-tes auf eine Anbindung an einen CVS-System. Die Losung soll jedoch sokonstruiert werden, dass es relativ einfach ist Anbindungen an andereVersionsverwaltungswerkzeuge hinzuzufugen /NF1/.CURE verfugt uber viele verschiedene, integrierte Werkzeuge. Diese wurdenteilweise in den letzten Kapiteln vorgestellt. Alle Werkzeuge verfugen ubereine konsistente, homogene Benutzeroberflache, was die Arbeit mit der Platt-form vereinfacht. Die Repository-Anbindung soll sich nahtlos in De-sign /NF2/und Interaktionsmoglichkeiten /NF3/ in die Benutze-roberflache von CURE integrieren um den Benutzer ein gewohntes Um-feld zu prasentieren. Weiterhin ist es von besonderem Interesse bestehendeDienste von CURE nachzunutzen bzw. in die Repository-Anbindung zuintegrieren um die Plattform moglichst konvergent aus Benutzersicht wirkenzu lassen /NF4/.

2.2.2 Szenarien

Die gruppenorientierte Sicht auf das Projekt wird innerhalb von CUREdurch Raume realisiert. Innerhalb eines solchen Raumes soll es nun ermog-licht werden auf die Inhalte eines CVS-Repositories zuzugreifen. CVS stelltdem Benutzer eine Menge von Verbindungsmoglichkeiten zur Verfugung,wobei nur die wenigsten Server alle davon auch bereitstellen. Es wird dahergefordert mehrere Zugriffsmoglichkeiten auf den CVS-Server zu rea-lisieren /F1/. Der Zugriff auf Repositories kann in bestimmten Fallen auchuber das Internet erfolgen. In diesen Fallen werden Repository-Inhalte bzw.Authentifizierungsdaten ungeschutzt transportiert. Wenn es sich hierbei umsensible Daten handelt, so kann dies ein Sicherheitsrisiko bedeuten. Es istdeshalb eine gesicherte Kommunikation mit dem Repository vorzu-sehen /F2/. Um auf die Dateien eines Repositories zugreifen zu konnen,mussen spezielle Parameter angeben werden. Diese Parameter sind zum Ei-nem verbindungsspezifisch, d.h. sie charakterisieren wo sich das Repositorybefindet, zum Anderen beziehen sie sich aber darauf, welche Inhalte vomRepository referenziert werden. Es muss dementsprechend moglich sein, einProjekt aus einem bestimmten Repository zu selektieren sowieeinen bestimmten Versionsstand zu wahlen /F3/.

Mit Hilfe der Verbindungsdaten wird eine Verbindung mit dem Repository-Server aufgebaut. Die gesamte Verzeichnisstruktur und die dazuge-horigen Dateien des Repositories mussen nun geeignet abgebildet


werden /F4/. Der Benutzer sollte danach beliebig durch die Struktur na-vigieren konnen. Es muss dabei sowohl der Zugriff auf binare als auch text-basierte Artefakte bereitgestellt werden. Die Inhalte von textbasiertenArtefakten sollen innerhalb der Repository-Anbindung dargestelltwerden konnen /F5/. Von besonderem Interesse ist es Metainfor-mationen zum Artefakt, wie z.B. einen Checkin-Kommentar, dar-stellen zu konnen /F6/. Es soll dadurch gewahrleistet werden, dass derBenutzer sich jederzeit daruber informieren kann, wer welche Anderung, zuwelchem Zeitpunkt getatigt hat. Mit Hilfe des Kommentars ist es zusatzlichmoglich sich uber den Grund der Anderung zu informieren.

Wahrend eines Projekts werden standig Anderungen an den Artefakten vor-genommen. Der Benutzer sollte sich genau uber den Verlauf derVeranderungen informieren konnen und im Stande sein die gesam-te Versionshistorie einzusehen /F7/. Weiterhin muss es auch moglichsein den Inhalt von alteren Versionsstanden einer Datei darzustellen. Hier-bei soll es auch moglich sein Versionen mit der Vorgangerversionzu vergleichen und sich in geeigneter Form uber die Unterschiedezwischen beiden Versionen zu informieren /F8/.

Der Benutzer muss innerhalb von CURE aber auch jederzeit aufdie aktuellsten Versionen Zugriff haben /F9/. Dies ist besonders wich-tig, wenn Anderungen an den Artefakten vorgenommen werden. Es ist da-her ein Mechanismus vorzusehen, der den Zugriff auf die aktuellste Versi-on gewahrleistet. Weiterhin soll der Benutzer uber Anderungen imRepository explizit informiert werden /F10/. Es ist einerseits zu ge-wahrleisten, dass der Benutzer wahrend seiner Arbeit mit dem Repositoryinnerhalb von CURE uber Aktualisierungen informiert wird, andererseitssoll er aber auch Informationen daruber abrufen konnen, welche Artefaktesich in einer bestimmten Periode geandert haben. Dazu mussen Ande-rungen innerhalb von CURE protokolliert werden /F11/. Dies sollgewahrleisten, dass ein Benutzer immer Informationen daruber erhalt, wel-che Arbeitsschritte abgeschlossen sind.

Der Zugriff auf ein Repository soll innerhalb eines Raumes einer gesamtenArbeitsgruppe ermoglicht werden. Dies hat den Vorteil, dass lediglich einBenutzer Berechtigungen fur das Repository benotigt, er aber anderen Per-sonen mit Hilfe der Repository-Anbindung Zugang zu den Artefakten ver-schaffen kann. Die Benutzer sollten jedoch auch einzelne Dateien bzw. dasgesamte Projekt außerhalb von CURE bearbeiten konnen. Es sind daherMoglichkeiten vorzusehen, dass der Benutzer Artefakte herunter-laden kann /F12/. Dies wurde es ermoglichen, dass die Benutzer die zurVerfugung gestellten Inhalte mit Werkzeugen ihrer Wahl weiter bearbeitenkonnen. Ein weiterer Vorteil ist, dass die Benutzer Zugriff auf Inhalte des


Repositories haben konnen, wenn sie nicht mit dem Inter- bzw. Intranet ver-bunden sind.

Besonderes Augenmerk liegt auf der Integration der Repository-Anbindungin die CURE-Umgebung. Um Kommunikation uber die Repository-Inhalte zu ermoglichen, muss es moglich sein, auf diese in geeigne-ter Weise zu verweisen /F13/. Denkbar ist hierbei z.B., dass von einerWiki-Seite auf die Artefakte mittels eines Hyperlinks verwiesen wird. Diesermoglicht es, dass wichtige Artefakte dem Benutzer an einer zentralen Stel-le durch Verweise zuganglich gemacht werden konnen. Es sollen aber auchAssoziationen von anderen Komponenten der Plattform mit den Artefaktenermoglicht werden.Weiterhin muss es ermoglicht werden, dass die Repository-Inhaltenach bestimmten Inhalten durchsucht werden konnen /F14/. DieBenutzer sollen sich dadurch beispielsweise uber die Benutzung von Co-deabschnitten oder realisierte Algorithmen informieren konnen. In diesemZusammenhang ist es wunschenswert, dass ebenso die Suche nachArtefakten ermoglicht wird /F15/.


2.3 Zusammenfassung der Anforderungen

Die folgende Auflistung enthalt die Anforderungen an diese Arbeit in tabel-larischer Form:

1. funktionale Anforderungen

/F1/ Bereitstellung von verschiedenen Verbindungsarten

/F2/ Bereitstellung einer gesicherten Verbindung zum CVS-Server

/F3/ Zugriff auf einen bestimmten Branch/Tag ermoglichen

/F4/ Darstellung der Datei- und Ordnerstruktur eines Projekts

/F5/ Darstellung des Inhalts eines Artefakts aus dem Repository

/F6/ Darstellung von Metainformationen eines Artefakts

/F7/ Zugriff auf die Historie eines Artefakts

/F8/ Visualisierung von Unterschieden zwischen den Versionen

/F9/ automatische Synchronisation mit dem Repository

/F10/ Benachrichtigung uber Veranderungen im Repository

/F11/ Erfassung und Protokollierung von Veranderungen an Repository

/F12/ Bereitstellung eines Artefakts bzw. eines Projekts zum Download

/F13/ Assoziationen mit den Artefakten

/F14/ Suche nach Artefakten ermoglichen

/F15/ Volltextsuche im Inhalt eines Artefakts

2. nichtfunktionale Anforderungen

/NF1/ Bereitstellung einer erweiterbaren Losung

/NF2/ Anlehnung des Designs an CURE

/NF3/ Anlehnung der Interaktionsmoglichkeiten an CURE

/NF4/ Integration mit anderen Komponenten von CURE

Tabelle 2.1: Anforderungen an die Repository-Anbindung

Kapitel 3

Stand der Technik

3.1 Darstellung existierender Ansatze

Dieses Kapitel ist in drei Abschnitte unterteilt. In den ersten beiden Ab-schnitten werden Kollaborationsplattformen auf Ihre Anbindung an Artefakt-Repositories untersucht. Besondere Aufmerksamkeit wird darauf gelegt, wieder Benutzer uber Veranderungen im Repository informiert wird und wie dieInhalte des Repositories innerhalb der Kollaborationsplattform visualisiertwerden. Es wird gepruft, ob und wie die Artefakte fur Kommunikation undKoordination genutzt werden konnen.Im letzten Abschnitt werden existierende CVS-Anbindungen untersucht.Hier liegt der Fokus darauf, wie Benutzer uber Veranderungen im Repo-sitory informiert werden.

3.1.1 Universitare Kollaborationsplattformen fur Software-projekte

Es existieren neben vielen kommerziellen Ansatzen auch eine Vielzahl experi-menteller Plattformkonzepte und Prototypen aus dem universitaren Umfeldund aus Forschungsprojekten. An dieser Stelle sollen die Losungen CHIME[Dos01], OPHELIA [WRS+03] und GENESIS [BCG+03] vorgestellt werden.Die Beurteilungen fur die universitaren Kollaborationsplattformen konntenlediglich mit Hilfe der Literatur erstellt werden. Es war mir nicht moglichdie Losungen an realen Installationen zu testen, da weder Versionen zumHerunterladen noch Testzugange zu den Losungen zur Verfugung gestelltwurden.

CHIME

CHIME 1 ist eine metadatenbasierte Informationsumgebung fur die Unter-stutzung von großen Softwareprojekten. Das Forschungsprojekt wurde 19991 Abk. Columbia Hypermedia IMmersion Environment

32

KAPITEL 3. STAND DER TECHNIK 33

an der Columbia University in New York, USA gestartet.

Vorstellung Das Ziel des Projekts ist es Informationen, welche wahrenddes Softwareentwicklungsprozesses anfallen zu sammeln, zu strukturierenund bereitzustellen. Artefakte werden dabei in ihren ursprunglichen Versio-nierungswerkzeugen oder Datenbanken belassen. CHIME wird dazu benutztum auf diese Artefakte zuzugreifen, durch ihre Struktur zu navigieren unddiese entsprechend zu visualisieren (vgl. Abbildung 3.1).

Abbildung 3.1: Architektur von CHIME (entnommen aus [Dos01])

Innerhalb der Losung werden Metadaten zu den Artefakten gespeichert, sodass eine zentrale Wissensbasis entsteht. Kollaboration wird dadurch er-moglicht, dass CHIME eine virtuelle dreidimensionale Umgebung (vgl. Ab-bildung 3.2) bereitstellt, in der die Benutzer durch Avatare2 reprasentiertwerden. Die Benutzer konnen durch diese virtuelle Welt laufen und mit denArtefakten arbeiten. Artefakte werden dabei als geometrische Formen visua-lisiert.Es ist moglich Artefakte durch Raume zu strukturieren. Sollten mehrereBenutzer ein Artefakt innerhalb von CHIME bearbeiten, so konnen sie bei-spielsweise uber einen Chat miteinander kommunizieren. Fur jede Art desZugriffes auf Artefakte muss ein Adapter bereitgestellt werden, der den Zu-griff beschreibt. Es existieren Adapter fur den Webzugriff und fur viele Ver-sionsverwaltungswerkzeuge.CHIME kennt gemeinsame Arbeitsbereiche, welche als Gruppenraume be-zeichnet werden. Der Gruppenraum beschreibt dabei einen virtuellen Raum,in dem die Zusammenarbeit zwischen den Projektteilnehmern ermoglichtwird. Ein Gruppenraum stellt den Benutzern Artefakte sowie Werkzeugezum Erzeugen und Bearbeiten der Artefakte bereit. Zu den Werkzeugenzahlen innerhalb von CHIME ein Chat-System, ein Annotationssystem zum

2 eine Figur, welche als Stellvertreter einer echten Person in einer virtuellen Welt auf-tritt


Abbildung 3.2: Benutzeroberflache von CHIME (entnommen aus [Dos01])

Hinzufugen von Informationen zu Artefakten (bspw. Hyperlinks), ein Vi-deokonferenzsystem und ein einfacher Editor zum Bearbeiten der Artefakte.CHIME informiert die Benutzer eines Gruppenraumes uber die Aktivitatenanderer Benutzer. So werden z.B. alle Aktionen von Benutzern innerhalbder Plattform aufgezeichnet. Es ist moglich sich daruber zu informieren inwelchem Arbeitsraum sich ein Benutzer befindet oder an was er gerade ar-beitet.

Analyse in Bezug auf die Anforderungen CHIME verfolgt einen in-teressanten Ansatz. Artefakte werden nicht wie ublich unter Kontrolle desSystems gestellt, sondern verbleiben an ihren ublichen Speicherorten. Dieshat den Vorteil, dass man die Artefakte mit beliebigen Werkzeugen ver-andern kann und nicht auf die Werkzeuge von CHIME angewiesen ist. DieLosung erlaubt es auf CVS-Repositories zuzugreifen und deren Ordnerstruk-tur darzustellen /F4/. Der Benutzer kann dabei auf verschiedene Revisionenoder Entwicklungszweige zugreifen /F3/. Da die Artefakte außerhalb derLosung gehalten werden, bezieht sich ein Zugriff immer auf die aktuellsteVersion /F9/. Leider ist es bisher nicht moglich auf Metainformationen wieCheckin-Kommentare oder ausfuhrende Benutzer zuzugreifen.Ein Vorteil der Losung sind die Annotationsmoglichkeiten. Artefakten kon-nen betrachtet /F5/, beliebig annotiert und miteinander verlinkt werden/F13/. Sollte der Benutzer Fragen zu einem Artefakt haben, kann dazu einChat gestartet und uber etwaige Probleme diskutiert werden. Es ist jedochnicht moglich aus dem Chat auf die Artefakte zu verweisen. Ein Nachteilist auch, dass der Benutzer lediglich uber Veranderungen an Artefakten in-


formiert wird, wenn diese mit Hilfe des CHIME -Clients getatigt werden/F10/. Sollten Anderungen durch externe Clients durchgefuhrt werden, sowird der Benutzer nicht daruber informiert. Die Protokollierung der Veran-derungen erfolgt ebenso nur innerhalb von CHIME /F11/. Weiterhin wirdkeine asynchrone Kommunikationsmoglichkeit bereitgestellt. Hierzu stehenlediglich die Annotationsmoglichkeiten zur Verfugung.Alle in diesem und den weiteren Beurteilungsabschnitten nicht erwahntenAnforderungen gelten als nicht erfullt.

OPHELIA

OPHELIA3 ist ein von der Europaischen Gemeinschaft gefordertes For-schungsprojekt. Es wurde 2002 als Kooperation zwischen der Meriot-WattUniversitat Edinburgh, Schottland und der technischen Universitat von Poz-nan, Polen gestartet. Es handelt sich dabei um ein Framework zur Integrati-on mehrerer heterogener Softwareentwicklungswerkzeuge zu einer Kollabo-rationsumgebung mit globaler Sicht auf die unterschiedlichen Artefakte.

Vorstellung Die Feststellung, welche die Entwicklung von OPHELIA ein-leitete, ist, dass in der Softwareindustrie viele verschiedene Werkzeuge ent-wickelt wurden, um die Erstellung von Software zu vereinfachen. Dies hatjedoch auch dazu gefuhrt, dass die Werkzeuge zueinander inkompatible Ar-tefakte erzeugen, welche von anderen Werkzeugen nicht gelesen werden kon-nen und somit nicht bearbeitbar sind. Gerade in der modernen, verteiltenSoftwareentwicklung ist dies jedoch hinderlich, da somit alle am Entwick-lungsprozess beteiligten Personen die gleichen Werkzeuge benutzen mussen.OPHELIA uberlasst deshalb den Projektbeteiligten die Entscheidung, wel-che Werkzeuge genutzt werden.OPHELIA wurde als System geplant, an das vorhandene und neue Ent-wicklungswerkzeuge angebunden werden konnen. Die Kommunikation mitdiesen Werkzeugen ubernehmen so genannte OPHELIA-Module. Es wurdeWert darauf gelegt, dass die spezifizierten Module moglichst den gesamtenSoftwarelebenszyklus abdecken bzw. begleiten (vgl. Abbildung 3.3).

3 Abk. Open Platform and Methodologies for Development Tools Integration in a Dis-tributed Environment


Abbildung 3.3: Grundgedanke von OPHELIA (entnommen aus [GT04])

Die Architektur von OPHELIA wird in Abbildung 3.4 beschrieben. Dort istzu sehen, dass OPHELIA in vier Schichten unterteilt ist. Die obere Schichtwird durch die externen Anwendungen und das OPHELIA-Portal repra-sentiert. Das Portal ist eine Webapplikation, in welcher Informationen zumProjekt und den dazugehorigen Artefakten bereitgestellt werden. Unterhalbdieser Schicht befindet sich die Integrationsschicht. Diese Schicht stellt sogenannte Integratoren bereit, welche den Zugriff auf die Artefakte realisie-ren. Fur jedes Werkzeug muss ein Integrator entwickelt werden, welcher sichbespielsweise in die Oberflache der jeweiligen Applikation integriert. Weiter-hin steht ein Traceability-Modul zur Verfugung, das alle Anderungen an denArtefakten aufzeichnet und diese uber das OPHELIA-Portal den Benutzernzuganglich macht.Unterhalb dieser Schicht befindet sich die Modulschicht. Diese Module uber-nehmen, wie beschrieben, die Kommunikation mit den Werkzeugen. Durchdie Integration der einzelnen OPHELIA-Module bieten sich nun neue Mog-lichkeiten. Das OPHELIA-Metricsmodul ist durch die definierten Schnitt-stellen in der Lage Informationen uber den Zustand der einzelnen Artefakteabzufragen. So konnen uber dieses Modul umfassende Auswertungen, wiez.B. die Anzahl der Klassen oder der jeweilige Projekt- bzw. Prozesssta-tus, erstellt werden. Mit dem Notifications-Modul werden die Benutzer uberVeranderungen an Artefakten informiert. Ein Entwickler kann damit selbstbestimmen uber welche Ereignisse er informiert werden mochte. Er suchtsich dazu Artefakte uber das Portal aus und registriert sich fur bestimmteEreignisse. Von diesem Zeitpunkt an erhalt er Nachrichten, wenn z.B. eineKlasse geandert, Aufgaben neu zugewiesen oder auch neue Anforderungenerfasst wurden.


Abbildung 3.4: Architektur von OPHELIA (entnommen aus [GT04])

Die unterste Schicht regelt die Zusammenarbeit der Module. Hierzu ste-hen Module zur Verfugung, welche die Administration der Benutzer oderdes Projekts erlauben. Weiterhin wird ein Nachrichtensystem bereitgestellt,welches die Kommunikation zwischen den Modulen ermoglicht.Eine Umsetzung des Forschungsprojekts OPHELIA findet beispielsweise durchORPHEUS [WRS+03] statt. ORPHEUS wurde zur Demonstration und Va-lidierung des Konzepts entwickelt. Der Prototyp nutzt eine bestimmte Men-ge an Werkzeugen und integriert diese uber eine Reihe von Modulschnitt-stellenspezifikationen. In der Implementierung des Konzepts (vgl. Abbil-dung 3.5) existieren deshalb Module fur die Anforderungsphase (DRES4

[DRE07]), fur die Modellierung (ArgoUML [ARG07]), fur Projektplanungund Uberwachung (Microsoft Project 2000 [MSP07]), fur die Anbindung anDokumentations- bzw. Wissensdatenbanken (OpenOffice.org [OPE07]) undfur das Bug-Tracking (Bugzilla [BUG07]). Die Kodierungs-, Test- und Ein-fuhrungsphase werden jedoch nicht unterstutzt.

Analyse in Bezug auf die Anforderungen OPHELIA versucht eben-falls Softwareentwicklung in einer verteilten Umgebung zu unterstutzen. DieArtefakte werden dabei an ihren ursprunglichen Speicherorten gehalten. DieModule sind dann fur den Zugriff auf das Artefakt verantwortlich.Diese Architektur wurde es ermoglichen, dass OPHELIA auf Repositorieszugreifen kann. Leider ist OPHELIA nur eine theoretische Architektur. DieImplementierung ORPHEUS (vgl. Abbildung 3.5) unterstutzt leider keineAnbindung zu Versionsverwaltungswerkzeugen. Dabei waren die dadurchentstehenden Moglichkeiten durch die Integration mit den anderen Kompo-

4 Abk. Distributed Requirements Engineering System


Abbildung 3.5: Beispielimplementierung ORPHEUS (entnommen aus[GT04])

nenten ideal. Denkbar ware hier z.B. die Verknupfung von Fehlern, die durchein Bug-Tracking-System gemeldet werden, mit dem Quellcode.Weiterhin kann uber das Portal nicht auf die Inhalte von Artefakten zugegrif-fen werden. Es werden dadurch weitere wichtige Anforderungen nicht erfullt.Zu den erfullten Anforderungen zahlt u.a. die Realisierung einer Suche nachArtefakten/F14/. Ferner werden die Veranderungen an verwalteten Arte-fakten erfasst und protokolliert /F11/ sowie Benutzer uber Veranderungeninformiert /F10/. Es ist jedoch anzumerken, dass kein Zugriff auf Quellco-dedokumente aus einem CVS-Repository ermoglicht wird und deshalb auchkeine Veranderungen an diesen Artefakten protokolliert werden.

GENESIS

Das GENESIS -Projekt5 wurde 2001 an der Universtitat Salerno, Italien ge-startet. Es umfasst ein Workflow- und Artefaktmanagementsystem und bie-tet umfangreiche Koordinations- und Kommunikationsfunktionen. Die Lo-sung unterstutzt Softwareprojekte sowohl prozess- als auch produkttechnisch[BCG+03].

5 Abk. GEneralised eNvironment for procEsS management in cooperatIve Softwareengineering


Abbildung 3.6: Modell von GENESIS (entnommen aus [BCG+03])

Vorstellung Der GENESIS -Ansatz basiert auf der Feststellung, dass beieiner verteilten Softwareentwicklung ein hoheres Maß an Kommunikationund Koordination notwendig ist, als bei Softwareprojekten, welche nur in-nerhalb eines kleinen Teams lokal durchgefuhrt werden. Es wird davon aus-gegangen, dass Projekte arbeitstechnisch aufgeteilt werden, indem Teilauf-gaben auf verschiedene Standorte verteilt werden (vgl. Abbildung 3.6). JederStandort benotigt dabei Artefakte als Eingabe fur die Arbeit und produziertArtefakte als Ausgabe. Diese Artefakte bilden die Basis fur die Kooperationzwischen den Standorten.Die Architektur von GENESIS wird in drei Schichten strukturiert (vgl. Ab-bildung 3.7). Dabei werden Prasentations-, Service- und Datenschicht unter-schieden. Die Prasentationsschicht stellt verschiedene Clients bereit, welchejeweils fur ein spezielles Aufgabengebiet vorgesehen sind. Zu nennen sindhier beispielsweise Workflow-Client und Artefakt-Client. Die Serviceschichtstellt die eigentliche Funktionalitat der Losung dar. Die Kooperation zwi-schen den Standorten wird folgendermaßen unterstutzt:

1. ProzesskontrolleEs wird eine Ressourcenmanagementsystem und ein Workflowmanage-mentsystem bereitgestellt. Es konnen Prozesse, Personen mit Fahig-keiten und Rollen angelegt werden, welche miteinander in Beziehunggesetzt werden konnen. Der Ablauf eines Projekts kann innerhalb derLosung uberwacht werden. Besonders hervorzuheben sind in diesemZusammenhang die umfangreichen Statistiken uber den Projektver-lauf (Metrics-Engine vgl. Abbildung 3.7).

2. BenachrichtigungDas Benachrichtigungssystem informiert die Projektteilnehmer uber


die Fertigstellung von Arbeitspaketen bzw. uber Verzogerungen. Da-durch konnen sich die Teilnehmer jederzeit ein Bild uber den Fort-schritt des Projekts machen. Weiterhin werden Benutzer uber Veran-derungen, welche an den innerhalb von GENESIS verwalteten Arte-fakten getatigt werden, informiert.

3. Bereitstellung eines gemeinsamen DokumentenarchivsBenutzer konnen in einem Projektbereich Artefakte zentral erzeugenund bearbeiten. Die Verwaltung wird von einem Artefaktmanagement-system ubernommen. Dabei werden Berechtigungen unterstutzt, damitdie Dokumente nur fur autorisierte Personen zuganglich sind. Versi-onskontrolle wird in GENESIS dadurch erreicht, dass die Artefaktein einem entsprechenden Werkzeug wie CVS abgelegt werden konnen.Weiterhin ist es moglich die Dokumente mit zusatzlichen Kommenta-ren und Notizen zu annotieren.

4. KommunikationEs werden sowohl formelle als auch informeller Informationsaustauschdurch das Kommunikationssystem ermoglicht. Formelle Kommunika-tion bedeutet in diesem Zusammenhang der Wissensaustausch uberDokumente. Informeller Wissensaustausch wird durch das Annotierenvon Dokumenten ermoglicht.

Die Datenhaltungsschicht dient der Speicherung von Daten. Es werden hierkeine besonderen Anforderungen gestellt.

Abbildung 3.7: Architektur von GENESIS (entnommen aus [GP02])


Analyse in Bezug auf die Anforderungen Fur diese Arbeit inter-essant ist das Artefaktmanagement. Es besteht die Moglichkeit Artefaktein CVS-Repositories abzulegen. GENESIS erlaubt jedoch nicht den Zugriffauf extern, d.h. außerhalb der Losung, verwaltete Repositories. Dies ist je-doch eine explizite Anforderung an diese Arbeit.Der Zugriff auf innerhalb von GENESIS verwaltete Repositories ist jedochmoglich. Dabei wird die Ordnerstruktur des Repositories dargestellt /F4/und der Zugriff auf verschiedene Versionen /F3/ und deren Unterschiede/F8/ ermoglicht. Ebenso besteht der Zugriff auf die Inhalte /F5/, die His-torie eines Artefakts /F7/ und auf Metainformationen wie Kommentar undausfuhrender Benutzer /F6/ moglich. Der Zugriff auf die neueste Versi-on eines Artefakts wird durch das Artefaktmanagementsystem erfullt /F9/.Anderungen werden protokolliert /F11/ und sind somit immer zugreifbar.Weiterhin wird der Benutzer uber Anderungen an den Artefakten informiert/F10/. Die Anderungsmitteilungen konnen jedoch lediglich in der Plattformangezeigt werden, eine E-Mail-Integration besteht nicht. Die Losung hatsich zwar zum Ziel gesetzt, die Kommunikation in verteilten Umgebungenzu unterstutzten, dies wird jedoch nur unzureichend erfullt. Es werden kei-ne synchronen Kommunikationsmittel bereitgestellt. Asynchrone Kommu-nikation wird nur uber den Austausch von Dokumenten und Annotationenunterstutzt. Beziehungen zwischen Artefakten und zwischen Prozessen undArtefakten sind nicht moglich.

Weitere Losungen

Weiterhin existieren Kollaborationslosungen, die sich vor allen Dingen aufEntwicklungstatigkeiten fokussieren. Dazu zahlen beispielsweise Cooperati-on Assistant [AW98], MILOS [MD00], Jazz [HCRP04] und CAISE [CC03].Diese Werkzeuge unterstutzen ebenfalls die kooperative Softwareentwick-lung. Aufgrund der Tatsache, dass es sich dabei jedoch nicht um Kollabo-rationsplattformen im Sinne der Aufgabenstellung handelt, wird an dieserStelle auf eine nahere Untersuchung verzichtet.

3.1.2 Kommerzielle bzw. freie Kollaborationsplattformen furSoftwareprojekte

Zentrale Kollaborationsplattformen kommen verstarkt bei der Entwicklungvon Open-Source-Software zum Einsatz, da sich dieser Bereich primar durchWerkzeugunterstutzung und Ausrichtung auf eine verteilte Internetumge-bung auszeichnet [KL05]. Die bekanntesten Beispiele fur solche Kollabora-tionsplattformen sind SourceForge.net [SOU07b], JavaForge [JAV07d], Sa-vannah [SAV07] und Gforge [GFO07b].SourceForge.net und JavaForge bieten ihre Dienstleistungen nur fur freieEntwicklungsvorhaben kostenlos an. Mit GForge und Savannah existieren


zudem quelloffene Losungen, die durch einzelne Communities selbst betrie-ben und gegebenenfalls im Quelltext modifiziert werden konnen.Der Trend zur Nutzung von Kollaborationswerkzeugen bei Open-Source-Entwicklungen bietet hilfreiche Impulse zur Losung von ahnlichen Proble-men in kommerziellen Projekten. Die starke Verbreitung im Open-Source-Bereich hat zudem dazu gefuhrt, dass solche Plattformen immer haufigerauch erfolgreich in Unternehmen eingesetzt werden [KL05]. Die erfolgreichenPlattformen fur Open-Source-Projekte werden daher auch als kommerzielleProdukte mit zusatzlichen Funktionalitaten weitervertrieben. Beispiele dafursind SourceForge Enterprise Edition von VA Software [SOU07a], CollabNetEnterprise von CollabNet [COL07], GForge Enterprise von GForge Group[GFO07a] und CodeBeamer von Intland [COD07a].Stellvertretend sollen an dieser Stelle die Losungen SourceForge EnterpriseEdition und CodeBeamer naher untersucht werden.Die Beurteilungen fur die kommerziellen Kollaborationsplattformen basierenauf entsprechenden Tests an selbst installierten Evaluationsversionen oderzur Verfugung gestellten Testzugangen. Es wird in den jeweiligen Abschnit-ten beschrieben welche Versionen gepruft wurden.

SourceForge Enterprise Edition

SourceForge Enterprise Edition ist eine Plattform fur die Optimierung einerdezentralen Softwareentwicklung. Sie basiert auf einem zentralen, webba-sierten Ansatz und verbessert Kommunikation, Zusammenarbeit und dieKoordinierung von verteilten Teams (vgl. Abbildung 3.8).

Abbildung 3.8: Funktionalitaten von SourceForge Enterprise Edition(entnommen aus [SOU07a])


Vorstellung Die Basis von SourceForge Enterprise Edition ist eine fle-xibel erweiterbare Java 2 Enterprise-Edition (J2EE6 [J2E07]) Architektur.Wahrend SourceForge.net als frei zugangliche Losung lediglich im Internetgenutzt werden kann, ist die kommerzielle Version lokal installierbar und ver-fugt uber viele zusatzliche Sicherheitsmerkmale. SourceForge.net besteht auseiner Sammlung von heterogenen Open-Source-Applikationen, welche unterder gemeinsamen Oberflache des freien Internetportals zusammenarbeiten,wahrend SourceForge Enterprise Edition vollstandig in Java programmiertwurde.SourceForge Enterprise Edition bietet zahlreiche Funktionalitaten, um dieProjektarbeit effektiver zu gestalten. Anforderungs- und Anderungsmana-gement, Dokumentenmanagement, Versionsverwaltung, Fehlermanagementoder Aufgabenlisten sind nur einige der zahlreichen, integrierten Funktionen.SourceForge Enterprise Edition bietet daruber hinaus die Moglichkeiten be-reits installierte Werkzeuge von Drittanbietern einzubinden. Diese Art derIntegration bietet die freie Losung SourceForge.net nicht. Dort ist der Be-nutzer auf die bereitgestellten Werkzeuge angewiesen.Anders als bei lose integrierten Entwicklungswerkzeugen, ermoglicht die Lo-sung einen webbasierten Zugriff auf alle projektbezogenen Informationenund Aktivitaten. Hierzu gehoren nicht nur Quellcode, sondern auch Doku-mente und andere Projektinformationen sowie Diskussionsbeitrage. Sour-ceForge Enterprise Edition besitzt eine integrierte Suchmaschine, die eineschnelle Suche uber unterschiedliche Dateiformate ermoglicht. Durch daszentrale Repository wird der administrative Mehraufwand reduziert undzusatzlich die Datensicherung erleichtert. Um Missverstandnisse innerhalbverteilter Teams zu vermeiden und kritische Projektentscheidungen zu be-schleunigen, bietet das System zahlreiche Funktionalitaten, welche die Zu-sammenarbeit im Team erleichtern. Zu den kollaborativen Funktionalitatenzahlen unter anderem:

• Diskussionsforen/News,

• Mailinglisten,

• Globales Entwicklungs-Dashboard7 und

• Wikisystem.

SourceForge Enterprise Edition kummert sich um die Verbreitung von Pro-jektinformationen. Das System versendet dazu Benachrichtigungen via E-Mail.

6 Bezeichnung eines Applikationsframeworks fur die Programmiersprache Java7 in diesem Zusammenhang ist eine Visualisierungsform von Informationen in verdich-

teter Form gemeint. Projektteilnehmer konnen sich daruber eine Ubersicht uber denaktuellen Projektstatus verschaffen.


Analyse in Bezug auf die Anforderungen SourceForge EnterpriseEdition wurde in der on-demand8 Variante untersucht. Es handelte sichdabei um die Version SourceForge v4.3 SP1 HOTFIX-05. Dabei konnte le-diglich auf ein intern verwaltetes Subversion Projekt zugegriffen werden. Eskonnen keine externen Server eingebunden und damit /F1/ und /F2/ nichterfullt werden.Der Zugriff auf intern verwaltete Repositories uber die Weboberflache istjedoch vorbildlich umgesetzt /F3/. Es werden deshalb alle Anforderungenvon /F4/ bis /F9/ umgesetzt.Ein sehr interessanter Aspekt sind die Assoziationen innerhalb von Source-Forge Enterprise Edition. Dazu konnen in der Benutzeroberflache Artefak-te per Mausklick ausgewahlt und diese miteinander in Verbindung gesetztwerden. Somit ist es moglich, dass beispielsweise Anforderungen mit derimplementierten Realisierung assoziiert werden konnen. Leider sind jedochAssoziationen mit den Artefakten vom Wiki-Bereich aus nicht moglich. DieAnforderung /F13/ wird daher nur als eingeschrankt umgesetzt gewertet.Die Suche nach Artefakten /F10/,/F11/, Benachrichtigungen uber Veran-derungen /F14/ und Protokollierung von Veranderungen /F15/ wurdendagegen wieder vollstandig umgesetzt.Leider ist es nicht moglich das komplette Projekt herunterzuladen. Es wirddaher ein CVS-Client benotigt um an die Quellen zu gelangen. Anforde-rung /F12/ wird daher nicht umgesetzt. Weitere Nachteile von SourceForgeEnterprise Edition sind vor allen Dingen die fehlende synchrone Kommuni-kationsmoglichkeit, was eine Installation von zusatzlichen Werkzeugen vonDrittanbietern erfordert und das Fehlen eines Planungswerkzeugs fur denProjektverlauf [GHKR06].

CodeBeamer

CodeBeamer ist eine integrierte, webbasierte Kollaborationslosung spezi-ell fur Projektteams in der Softwareentwicklung. Im Mittelpunkt steht diestrukturierte Zusammenarbeit von verteilten Projektteams.Die Kollaborationsplattform basiert ebenso wie SourceForge Enterprise Edi-tion auf der Java 2 Enterprise-Edition (J2EE) Architektur. Die webbasiertePlattform kann ohne großen Installationsaufwand in unterschiedliche IT-Landschaften integriert werden. Unterstutzte Plattformen sind Windows98/NT/2000/XP, Linux sowie SUN Solaris.

Vorstellung CodeBeamer verbindet alle in den Softwareentwicklungspro-zess involvierten Personen und Teams miteinander. Interne und externeEntwickler, Produktmanager, technischer Support, Partner, Testabteilungund Projektmanagement sind stets auf einem gemeinsamen Informations-8 Dabei ist keine Installation notwendig, die Administration der Losung wird von VA

Software ubernommen http://ondemand.sourceforge.com/.

http://ondemand.sourceforge.com/.


und Wissensstand. Konkret liefert CodeBeamer unter anderem Projektma-nagementwerkzeuge, ein Wiki-System, ein Forum, einen Chat, eine Bug-Tracking-Integration, Mailinglisten, eine Benachrichtigungsfunktion, ein in-tegriertes Dokumentenmanagementsystem, eine Suchfunktion sowie eine E-Mail-Integration. Durch die E-Mail-Integration ist es somit auch moglichinnerhalb des Webportals auf E-Mails zuzugreifen. Außerdem besteht dieMoglichkeit externe Versionskontrollsysteme wie z.B. CVS, Subversion oderRational ClearCase einzubinden.Es ist moglich Assoziationen zwischen den in der Plattform gespeichertenArtefakten zu erzeugen. CodeBeamer liefert damit eine wichtige Voraus-setzung fur die Analyse des gesamten Softwareprojekts. Unter Artefaktenwerden Dokumente, Aufgaben, Quellcode und Diskussionen in Foren ver-standen. Beispielsweise wird es ermoglicht Diskussionen, die zu einer wich-tigen Entwurfsentscheidung gefuhrt haben, einer Aufgabe zuzuordnen. DasHinzufugen der Assoziationen kann dabei auf zwei verschiedene Arten erfol-gen. Zum Einen durch das direkte Hinzufugen einer Assoziation zu einementsprechenden Artefakt uber die Benutzeroberflache, zum Anderen durchdas Hinzufugen eines Links mittels einer speziellen Wiki-Syntax.CodeBeamer informiert den Benutzer ebenfalls automatisch uber Verande-rungen an den Artefakten. Der Benutzer kann dabei festlegen, in welcherGranularitat er uber Veranderungen informiert werden mochte.Die Losung lasst sich einfach in existierende Werkzeugumgebungen inte-grieren. Derzeit existieren Anbindungen fur eine Vielzahl an Werkzeugen.Eine vollstandige Liste findet man unter [COD07a]. Abbildung 3.9 vermit-telt einen Uberblick uber bestehende Anbindungen und die Architektur vonCodeBeamer.

Abbildung 3.9: Architektur von CodeBeamer (entnommen aus [COD07a])

Dabei wird deutlich, dass CodeBeamer eine gute Anbindung an Werkzeugevon Drittanbietern bereitstellt. Es werden beispielsweise verschiedene Adap-


ter fur Versionsverwaltungssysteme bereitgestellt. Weiterhin existiert aucheine Erweiterung fur die Entwicklungsumgebung Eclipse [ECL07] namensCBConnector9 [COD07b]. Sie erlaubt es aus der Entwicklungsumgebung aufBug-Tracking-Eintrage innerhalb von CodeBeamer zuzugreifen.

Analyse in Bezug auf die Anforderungen Die hier aufgefuhrten An-merkungen beziehen sich auf Version 4.2.2 der Kollaborationsplattform Co-deBeamer. Es wurde eine Installation der Losung auf einem gewohnlichenPC vorgenommen.Die Losung unterstutzt sowohl das Einbinden externen CVS-Repostitoriesals auch einen eingebauten CVS-Server. Als Verbindungsarten zu externenRepositories stehen dabei die Varianten pserver10, ext11 und local12 zur Ver-fugung. Abbildung 3.10 zeigt die Benutzerschnittstelle zum Einbinden vonRepositories. Dabei kann als Option gewahlt werden, ob die gesamte Historieimportiert werden soll.

Abbildung 3.10: Einbindung von externen Repositories in CodeBeamer

Nach dem erfolgreichen Import wird der Zugriff auf die Artefakte und Me-tainformationen ermoglicht. Mit einem so genannten Source Code Browserkann durch das Projekt navigiert werden. Dabei kann der Benutzer beliebi-ge Revisionen wahlen und sich auch die Unterschiede im Vergleich zu eineranderen Version darstellen lassen. Der Benutzername, welcher den Checkinausgefuhrt hat und dessen Kommentar werden ubersichtlich im Source Co-de Browser angezeigt. Ebenso ist es moglich sich die Inhalte der Artefakteanzeigen zu lassen. Bei der Anzeige wird Syntaxhighlighting fur Quellco-dedateien genutzt um die Ausgabe ubersichtlicher zu gestalten. Auch eineVolltextsuche uber die gesamten Artefakte ist moglich. CodeBeamer sorgtfur eine automatische Synchronisation mit dem Repository.

9 Abk. CodeBeamer Connector10 ungesicherte Zugriffsmethode inklusive Authentisierung beim CVS-Server11 Fur den Zugriff auf den CVS-Server werden externe Applikationen genutzt.12 lokaler Zugriff auf den CVS-Server


Es werden alle Ereignisse an den Artefakten protokolliert. Weiterhin wirdubersichtlich dargestellt wer, wann, welche Anderung getatigt hat. Die Be-nutzer werden automatisch uber Veranderungen im Repository informiert.Dies geschieht uber eine E-Mail-Integration in die Losung. Der Benutzerkann dabei festlegen uber welche Ereignisse er informiert werden mochte. Eswerden daher die Anforderungen /F1/ bis /F11/,/F14/ und /F15/ umge-setzt.Die Verknupfung von Artefakten mit anderen Modulen der Plattform istmoglich. Beispielsweise kann der Benutzer mit Hilfe von Links von Wiki-seiten auf die Artefakte verweisen. Dies ist ebenso aus dem Bug-Tracking-Modul moglich. Leider ist es nicht moglich aus dem Chat oder dem Forumauf Artefakte im Repository zu verweisen. Anforderung /F13/ wird dahernur eingeschrankt umgesetzt.Innerhalb des Kollaborationsportals gab es keine Moglichkeit das kompletteProjekt herunterzuladen. Es wird daher ein CVS-Client benotigt um an dieQuellen zu gelangen. Anforderung /F12/ wird daher nicht umgesetzt.

Weitere Losungen

Einen interessanten Vergleich bestehender Kollaborationsplattformen voll-zieht [GHKR06]. Dort wird angemerkt, dass sich CodeBeamer, SourceForgeEnterprise Edition und CollabNet sowie GForge funktional nur sehr gering-fugig unterscheiden. Im direkten Vergleich weist CodeBeamer jedoch diegroßte Funktionsvielfalt auf.

3.1.3 CVS-Anbindungen

Eine gute Auflistung bestehender Client-Losungen bietet [DMO07]. Der Funk-tionsumfang der bestehenden Losungen ist im Allgemeinen sehr ahnlich.Dies ist darauf zuruckzufuhren, dass CVS schon relativ lange existiert undes sehr wenige Anderungen am Zugriff auf den CVS-Server gab. LediglichNeuentwicklungen unterstutzen nicht den gewohnten Funktionsumfang. BeiWerkzeugen wie jCVS [JCV07], Cervisia [CER07], WinCVS [WIN07] undTortoiseCVS [TOR07] kann darauf vertraut werden, dass der volle Funkti-onsumfang gewahrleistet wird. Eigene Untersuchungen haben ergeben, dasssie sich hochstens in der Visualisierung bzw. in kleineren Funktionalitatenunterscheiden. Diese Unterschiede sind jedoch im Zusammenhang mit dieserArbeit nicht relevant. Es wird deshalb an dieser Stelle nur ein, aus Sicht desAutors, bekannter Client - TortoiseCVS - stellvertretend vorgestellt.Neben den CVS-Clients existiert die Moglichkeit auf dem CVS-Server ei-ne spezielle Erweiterung zu installieren, die es ermoglicht, dass Inhalte derRepositories einfach mit einem Webbrowser betrachtet werden konnen. DerVorteil daran ist, dass der Benutzer nicht mehr auf einen speziellen Cli-ent angewiesen ist. An dieser Stelle soll als Vertreter dieser Art die Losung


ViewVC [VIE07] vorgestellt werden.Die Beurteilungen fur die CVS-Anbindungen wurden nach einer Installati-on der entsprechenden Werkzeuge vorgenommen. TortoiseCVS wurde unterWindows mit Hilfe der Version 1.8.30, ViewCV unter Linux in der Version1.0.4 getestet.

TortoiseCVS

TortoiseCVS ist ein CVS-Client fur Microsoft Windows, welcher unter derGNU General Public License13 freigegeben wurde.

Vorstellung Gewohnliche CVS-Clients arbeiten meist als eigenstandigeApplikation, wahrend sich TortoiseCVS in den Windows Explorer integriert.Nach der Installation des Clients kann uber das Kontextmenu des WindowsExplorers mit den Repositories gearbeitet werden (vgl. Abbildung 3.11).TortoiseCVS hebt die lokalen Kopien aus einem CVS-Repository durch be-sondere Icons hervor. Der Benutzer kann dadurch beispielsweise sofort er-kennen, ob eine Datei lokal verandert wurde oder noch nicht im Repositoryexistiert. Es ist daher nicht notwendig zusatzliche Programme zu starten.

Abbildung 3.11: TortoiseCVS in der Anwendung (entnommen aus[TOR07])

Analyse in Bezug auf die Anforderungen TortoiseCVS stellt ver-schiedene Verbindungsarten zum Repository zur Verfugung /F1/. Dabei

13 eine von der Free Software Foundation herausgegebene Lizenz fur die Lizenzierungfreier Software http://www.fsf.org/licenses/gpl.html

http://www.fsf.org/licenses/gpl.html


wird auch der sichere Zugriff mit Hilfe von SSH ermoglicht /F2/.Mit TortoiseCVS konnen Projekte aus einem Repository importiert werden,dabei ist es auch moglich auf verschiedene Revisionen zuzugreifen /F3/. DieOrdnerstruktur wird durch die Integration in den Windows Explorer direktnach einem Checkout angezeigt /F4/. Es sind alle geforderten Operationenmit den Artefakten moglich /F5/ bis /F8/. Ein Nachteil von TortoiseCVSist, dass Informationen wie z.B. der Benutzername, welcher eine Verande-rung an einem Artefakt durchgefuhrt hat, erst nach zusatzlichen Dialog-schritten angezeigt werden. Die Losung kann jedoch Versionsgraphen anzei-gen und somit graphisch verdeutlichen welche Entwicklungszweige bestehen.Leider ist es mit Hilfe von TortoiseCVS nicht moglich sich uber Veran-derungen im Repository informieren zu lassen /F9/. Es werden weiterhinauch keine Veranderungen durch die Applikation protokolliert /F11/. Tor-toiseCVS synchronisiert sich nicht mit dem Repository, so dass der Benutzererst explizit den lokalen Datenbestand aktualisieren muss, bevor er Zugriffauf die aktuellste Version der Artefakte hat. Anforderung /F10/ wird dahernicht erfullt. Die Suche nach und innerhalb von Artefakten wird nicht durchdie Losung bereitgestellt. Die Integration in den Windows Explorer erlaubtes jedoch dessen Suche zu nutzen.Assoziationen mit oder zwischen den Artefakten werden nicht durch die Lo-sung bereitgestellt. Anforderung /F13/ wird daher nicht erfullt. Um Zugriffauf das Repository zu haben, ist eine Installation von TortoiseCVS not-wendig. Gerade in Netzwerken, in denen nicht die vollen Berechtigungen zurVerfugung stehen, ist dies ein Nachteil. Diese wurde bedeuten, dass eventuellkein Zugriff auf CVS-Repositories moglich ist, da keine zusatzliche Softwareinstalliert werden darf.

ViewVC

ViewVC ist eine Erweiterung fur einen Repository-Server, welche es erlaubt,dass mit Hilfe eines Webbrowsers durch die Inhalte eines Projekts navigiertwerden kann. Die Losung unterstutzt sowohl CVS- als auch Subversion-Repositories.

Vorstellung ViewVC generiert dazu aus der Datei- bzw. Ordnerstrukturund den CVS-Metadaten des Repositories HTML14 Dateien, welche durchTemplates an die jeweiligen Bedurfnisse angepasst werden konnen. Danachist es mit Hilfe eines Browser moglich, durch das Projekt und die verschie-denen Revisionen zu navigieren. Wie bei normalen CVS-Clients konnen dieUnterschiede zwischen einzelnen Revisionen angezeigt werden. Der Vorteilist, dass zum Betrachten des Repositories keine besondere Applikation be-notigt wird.

14 Abk. HyperText Markup Language


ViewVC wird derzeit z.B. bei SourceForge.net (vgl. Abbildung 3.12) einge-setzt, um uber das Projektportal auf die Inhalte eines Repositories zuzugrei-fen.

Abbildung 3.12: ViewVC Erweiterung beim Einsatz auf SourceForge.net

Analyse in Bezug auf die Anforderungen Die Installation von View-CV auf dem CVS-Server hat den Vorteil, dass kein CVS-Client mehr beno-tigt wird um auf die Artefakte zugreifen zu konnen. Der Zugriff auf die Lo-sung kann jedoch nur ungesichert uber HTTP vollzogen werden. Die Anfor-derungen /F1/ und /F2/ werden deshalb nicht erfullt. Ein sicherer Zugriffkann aber durch Erweiterungen des Webservers bereitgestellt werden. Essind danach keine Anderungen an ViewCV notwendig. Die weiteren Funk-tionsfahigkeiten entsprechen denen eines normalen CVS-Clients. Es werdendaher genau wie bei TortoiseCVS die Anforderungen /F3/ bis /F8/ erfullt.Daruber hinaus wird die Anforderung /F9/ erfullt, da die Losung den Zugriffauf die neueste Version eines Artefakts bereitstellt. Als besonderes Merkmalwird zusatzlich Syntaxhighlighting fur Quellcodedateien unterstutzt.Die Anforderungen /F10/ und /F11/ werden nicht erfullt. ViewCV dientlediglich der Visualisierung des Inhalts eines Repositories und protokolliertweder Veranderungen noch benachrichtigt es Benutzer uber Veranderungen.Es kann jedoch der gesamte Inhalt eines Repositories auch uber die Ober-flache von ViewCV heruntergeladen werden /F12/. Leider sind keine Asso-ziationen mit den Artefakten /F13/ und keine Suche nach den Artefakten/F14/, /F15/ moglich.


3.2 Zusammenfassung

Einzig CodeBeamer bietet eine ausreichende Unterstutzung von externenRepositories. SourceForge Enterprise Edition bietet im Prinzip einen ahnli-chen Funktionsumfang, verfugt aber nur uber eingeschrankte Zugriffsmog-lichkeiten auf das Repository. Assoziationen zu den Artefakten konnen Co-deBeamer, SourceForge Enterprise Edition und CHIME herstellen. Die Rea-lisierungen sind jedoch eingeschrankt. So konnen CodeBeamer und CHIMEnicht aus dem integrierten Chat sowie SourceForge Enterprise Edition nuraus dem Wikibereich heraus auf Artefakte verweisen. SourceForge EnterpriseEdition stellt kein synchrones Kommunikationsmittel bereit, was ebenfallsals Nachteil zu werten ist. Die Benachrichtungen uber Veranderungen anden Artefakten werden in CodeBeamer und SourceForge Enterprise Editionsowohl in der Losung angezeigt als auch per E-Mail verteilt. CodeBeamerintegriert daruber hinaus auch E-Mailboxen. Der Zugriff auf die Artefakteist in den Losungen CodeBeamer, SourceForge Enterprise Edition, Tortoi-seCVS und ViewVC vorbildlich. Benutzer konnen verschiedene Revisionenselektieren, Inhalte betrachten, Anderungen nachvollziehen und Metainfor-mation wie z.B. Kommentare sowie ausfuhrender Benutzer abfragen. Tor-toiseCVS und ViewVC konnen den Benutzer nicht uber Aktualisierungeninformieren und bieten keine Assoziationen an. GENESIS und SourceForgeEnterprise Edition ermoglichen lediglich den Zugriff auf intern verwalteteRepositories. OPHELIA und CHIME sind interessante theoretische Ansat-ze. Die Umsetzung von OPHELIA durch ORPHEUS bietet jedoch keinenZugriff auf Repositories und kann damit viele Anforderungen nicht erfullen.Die Umsetzung von CHIME erfullt die Anforderungen ebenso nicht.Tabelle 3.2 bewertet die untersuchten Losungen im Hinblick auf die Anfor-derungen an die Repository-Anbindung. Die verwendeten Symbole werdenin in Tabelle 3.1 erlautert.

Symbol Bedeutung? Die Anforderung wurde umgesetzt.� Die Anforderung wurde teilweise

umgesetzt. In diesen Fallen wird zu-satzlich erlautert, was zu dieser Ab-wertung gefuhrt hat.

- Die Anforderung wurde nicht umge-setzt.

Tabelle 3.1: Bedeutung der Symbole in Tabelle 3.2


CH

IME

OR

PH

EU

S(O

PH

ELIA

)

GEN

ESI

S

SOU

RC

EFO

RG

EEE

Cod

eBea

mer

Tor

tois

eCV

S

Vie

wV

C

/F1/ Bereitstellung von verschiedenenVerbindungsarten

- - -1 -2 ? ? -3

/F2/ Bereitstellung einer gesicherten Ver-bindung zum CVS-Server

- - -1 -2 ? ? -3

/F3/ Zugriff auf einen bestimmten Bran-ch/Tag ermoglichen

? - ? ? ? ? ?

/F4/ Darstellung der Datei- und Ordner-struktur eines Projekts

? - ? ? ? ? ?

/F5/ Darstellung des Inhalts eines Arte-fakts aus dem Repository

? - ? ? ? ? ?

/F6/ Darstellung von Metainformationeneines Artefakts

? - ? ? ? ? ?

/F7/ Zugriff auf die Historie eines Arte-fakts

- - ? ? ? ?4 ?

/F8/ Visualisierung von Unterschiedenzwischen den Versionen

- - ? ? ? ? ?

/F9/ automatische Synchronisation mitdem Repository

? - ? ? ? - ?

/F10/ Benachrichtigung uber Verande-rungen im Repository

? ? ? ? ? ? -

/F11/ Erfassung und Protokollierung vonVeranderungen an Repository

�5 ? ? ? ? ? -6

/F12/ Bereitstellung eines Artefakts bzw.eines Projekts zum Download

- - - - - - ?

/F13/ Assoziationen mit den Artefakten �7 - - �7 �7 - -/F14/ Suche nach Artefakten ermoglichen - ? - ? ? -8 -/F15/ Volltextsuche im Inhalt eines Arte-fakts

- - - ? ? -8 -

1 kein Zugriff auf extern verwaltete Repositories2 Es werden nur von SourceForge Enterprise Edition verwaltete Repositories unter-

stutzt. Wie der Zugriff vom Webserver auf die Repositories erfolgt, ist mir nichtbekannt.

3 muss uber Webserver gewahrleitet werden4 Artefakt liegt bereits lokal vor5 nur Anderungen innerhalb von CHIME6 Informationen stehen im Repository bereit und konnen abgefragt werden.7 nur eingeschrankt moglich (nicht von allen Modulen der Losung)8 wird durch umgebendes Betriebssystem bereitgestellt

Tabelle 3.2: Ubersicht uber die untersuchten Losungen

Kapitel 4

Losungsansatz

Der entwickelte Losungsansatz erweitert die Kooperationsplattform CUREum ein Modul, welches den Zugriff auf CVS-Repositories erlaubt. Es wirdsomit die Arbeit mit den Artefakten eines Repositories innerhalb der Platt-form ermoglicht.Die zentralen Elemente von CURE sind Raume und Seiten. Ein Raum stehteiner Gruppe von Benutzern zur Kollaboration zur Verfugung. Die Infor-mationen in einem Raum werden durch Seiten modelliert. Die Repository-Anbindung ermoglicht es nun, dass innerhalb eines Raumes mit Hilfe einerneuen Seitenart auf das Repository zugegriffen werden kann.

4.1 Losungsidee

Der Benutzer erstellt innerhalb eines Raumes eine neue Seite, welche die An-bindung an den CVS-Server darstellt. Er spezifiziert dabei die erforderlichenParameter fur den Repository-Server.Die Repository-Anbindung ubertragtdaraufhin das Projekt in einen speziellen Bereich auf den CURE-Server. DieDateien, die zugrundeliegende Ordnerstruktur und die Metainformationendes Repositories werden analysiert und entsprechend auf interne Datenstruk-turen abgebildet. Der Benutzer kann nun durch die Ordnerstruktur navigie-ren und die einzelnen Artefakte betrachten. Beim Betrachten der Inhaltewerden zusatzlich Metainformationen angezeigt.Wenn eine Datei im Repository verandert wird, sendet der CVS-Server ei-ne Benachrichtigung1 an CURE. Der lokalte Datenbestand wird daraufhinaktualisiert. Die Benutzer werden umgehend uber diese Aktualisierung in-formiert.Prinzipiell ware auch ein komplett anderer Losungsansatz moglich gewesen,bei dem kein lokaler Datenbestand gepflegt werden musste. Dabei ware esjedoch notwendig gewesen, dass jeder Abruf der Inhalte einem entfernten

1 Dafur sind zusatzliche Einstellungen am Repository-Server notwendig, welche nichtzu der Realisierung dieser Arbeit zahlen.

53

KAPITEL 4. LOSUNGSANSATZ 54

Zugriff entsprochen hatte. Vorteilhaft daran ware gewesen, dass keine red-undante Datenspeicherung angefallen sowie keine Synchronisation mit demRepository-Server notwendig gewesen ware. Jeder Zugriff hatte sich immerdirekt auf das Repository bezogen. Diese Losungsvariante ware jedoch ge-rade beim Betrachten von sehr großen Artefakten zeitlich nicht tolerierbargewesen, so dass von der Realisierung abgesehen wurde.

4.2 Uberblick uber die Losung

Dieser Abschnitt beschreibt die Repository-Anbindung mit Hilfe von Szena-rien und Bildern der Benutzerschnittstelle.

4.2.1 Erstellung einer Repository-Anbindung

Eine wichtige Anforderung der Repository-Anbindung war die nahtlose In-tegration in die CURE Plattform. Es wird deshalb bei der Erstellung einerRepository-Seite auf die gewohnte Erstellung einer Seite zuruckgegriffen. DerBenutzer kann jedoch eine neue Seitenart - die Repository-Seite - wahlen.Die Erzeugung einer Repository-Seite ist ebenfalls aus einer Wiki-Seite her-aus moglich. Dazu erzeugt der Benutzer einen Link, der auf eine Seite ver-weist, welche noch nicht existiert. Beim Speichern der Wiki-Seite erhalt derBenutzer daraufhin die Moglichkeit eine Repository-Seite zu erstellen, wel-che das Ziel dieses Verweises reprasentiert.

Abbildung 4.1: Erstellen einer Repository-Seite

In Abbildung 4.1 ist zu sehen, dass der Benutzer beim Anlegen der Seiteverbindungsspezifische Parameter eingeben muss. Er hat die Moglichkeitsich ungesichert bzw. gesichert mit dem Repository zu verbinden. Weiterhinkann er spezifizieren, ob er einen bestimmten Branch oder eine bestimmteRevision eines Projekts in CURE zur Verfugung stellen mochte und ob er


die gesamte Historie importieren mochte. Die letzte Option ermoglicht esdem Benutzer, dass er bei bestehenden Projekten Zugriff auf den gesamtenProjektverlauf hat. Dieser Zugriff beschrankt sich jedoch auf die Historieeines bestimmten Entwicklungszweiges. Wenn beim Erstellen der Repositorykein Entwicklungszweig spezifiziert wird, so wird fur den Import der Historieder Standardbranch genutzt.

4.2.2 Arbeit mit dem Repository

Nachdem der Benutzer die Seite erstellt hat, beginnt der Download der Arte-fakte und der Metainformationen aus dem Projekt. Der Import eines großenRepositories kann sehr viel Zeit in Anspruch nehmen. Beim Import der Ver-sionshistorie werden dabei zuerst die aktuellen Versionen geladen. Danachkann der Benutzer bereits mit dem Repository arbeiten, wahrend im Hinter-grund die alten Versionen und die Metainformationen noch geladen werden.Der Benutzer wird uber die Fertigstellung informiert. Die Prasentation unddie Interaktionsmoglichkeiten der Ordnerstruktur lehnen sich eng an dieDarstellung aller Seiten eines Raumes an (vgl. Abbildung 4.2).

Abbildung 4.2: Ansicht eines Repositories

Die Struktur des Repositories kann nach dem Import auf der Repository-Seitebetrachtet werden. Die Repository-Seite unterstutzt dabei die gewohntenseitentypischen Interaktionsmoglichkeiten der Plattform. Die Seite kann bei-spielsweise ausgeschnitten, geloscht oder ein Lesezeichen darauf gesetzt wer-den. Das Lesezeichen wird dem Benutzer dann auf der Einstiegsseite desRaumes zur Verfugung gestellt. Der Benutzer kann dadurch oft benutzteSeiten sehr schnell und einfach erreichen.


Zusatzlich kann der Benutzer auf der Repository-Seite eine manuelle Syn-chronisation mit dem Repository herbeifuhren und sich das gesamte Projektgepackt zum Download bereitstellen lassen. Dies hat den Vorteil, dass ledig-lich ein Benutzer Zugang zum Repository haben muss, er den Inhalt abervielen anderen Benutzern zur Verfugung stellen kann.In Abbildung 4.2 ist beispielhaft eine Repository-Seite dargestellt. Es wer-den u.a. der Name des Artefakts und der Benutzer, welcher den Import inCURE vollzogen hat, angezeigt. Der Benutzer kann durch das Projekt navi-gieren, ein Artefakt selektieren und den Inhalt betrachten. Hierbei wird dieAnzeige an einen bestehenden Typ - die Binarseite - angelehnt. Die Interak-tionsmoglichkeiten sind daher auch ahnlich zu der Binarseite. Lediglich eineVeranderung des Artefakts wird nicht unterstutzt. Es ware jedoch denkbardiese Erweiterung einzubringen, so dass Artefakte auch innerhalb von CUREbearbeitet werden konnen.Bei der Anzeige des Artefakts werden Metainformationen wie Revisionsnum-mer, Checkin-Kommentar und ausfuhrender Benutzer aus dem Repositoryubersichtlich dargestellt. Sollte es sich bei der Seite um eine textbasierte Da-tei handeln wird der Inhalt dargestellt. Ein Beispiel fur die Darstellung einerTextdatei enthalt Abbildung 4.3. Fur einige Programmiersprachen steht einSyntaxhighlighting bereit. Dabei werden die Schlusselworte einer Sprachefarblich hervorgehoben, was die Lesbarkeit von großen Textdateien erheb-lich erhoht.

Abbildung 4.3: Ansicht eines Artefakts

Sollten innerhalb von CURE mehrere Revisionen eines Artefakts bereitste-hen, so ist es moglich sich uber die Historie des Artefakts informieren. Dabeiwerden die gleichen Interaktionsmoglichkeiten wie bei einer Binarseite unter-


stutzt. Es ist jedoch nicht moglich einen alteren Versionsstand als aktuellsteVersion zu setzen. Weiterhin kann der Benutzer sich auf einer Ubersichtssei-te uber die vorhandenen Revisionen informieren. Dabei werden die verschie-denen Revisionen eines Artefakts zusammen mit ihren Metainformationenaufgelistet. Abbildung 4.4 zeigt die verschiedenen Versionen eines Beispiel-artefakts.

Abbildung 4.4: Versionsansicht eines Artefakts

Sollte es sich bei dem Artefakt um eine Textdatei handeln, so ist es moglichsich die Unterschiede zwischen zwischen zwei Versionen anzusehen. Dazusteht eine besondere Ansicht zur Verfugung, in der die Inhalte der beidenVersionen verglichen werden konnen. Die Unterschiede werden dabei durchverschiedene Farben reprasentiert, so dass jederzeit nachvollzogen werdenkann, welche Zeilen dem Artefakt hinzugefugt bzw. entfernt wurden oderwelche Zeilen sich geandert haben.Es ist moglich das Repository nach bestimmten Textabschnitten zu durch-suchen. Als Benutzerschnittstelle wird dabei auf die CURE-Suche zuruck-gegriffen. Beim Import der Artefakte werden dazu Inhalte von Textdateienund die Dateinamen der Artefakte indiziert. Es wird dadurch ermoglicht dieganze Plattform uber einer zentralen Stelle zu durchsuchen. Das Ergebnisist eine Auflistung aller zutreffenden Seiten mit einem Textabschnitt, wel-cher die gefundenen Textabschnitte farbig hervorhebt (vgl. Abbildung 4.5).Durch die Integration werden nun auch Repositories innerhalb von CUREdurchsuchbar.


Abbildung 4.5: Suche innerhalb von Artefakten

4.2.3 Gruppenbewusstsein

Die Benutzer der Plattform werden sowohl uber die Fertigstellung des Im-ports als auch uber eine Aktualisierung im Repository informiert. Die Be-nachrichtigung uber die Aktualisierung wird dem Benutzer wahrend der Ar-beit mit dem Repository sofort mitgeteilt. Es wird dadurch sichergestellt,dass ein Benutzer, welcher auf die Fertigstellung eines Artefakts wartet, so-fort benachrichtigt wird, wenn die Arbeit erledigt wurde. Es entstehen keineZeitverluste und der Benutzer muss nicht explizit den Entwicklungsstandnachfragen.Weiterhin werden die Benutzer, welche sich wahrend der Veranderung nichtinnerhalb der Plattform befinden, ebenfalls uber die Aktualisierung in Kennt-nis gesetzt. Dies geschieht mit Hilfe eines Tagesberichts, wobei ebenfalls einvorhandener Dienst von CURE genutzt wird. Er informiert, welche Ande-rung an welchem Objekt, durch wen durchgefuhrt wurde. Der Benutzer kannhierbei wahlen, ob ihm dieser Bericht per E-Mail zugestellt wird und/odernur in der Plattform zuganglich ist. Bei der Betrachtung des Tagesberichtsinnerhalb von CURE kann ein Zeitrahmen angegeben werden, in dem alleprotokollierten Ereignisse aufgelistet werden sollen.


4.3 Realisierung der Anforderungen

Dieser Abschnitt erlautert, wie die Anforderungen an die Repository-Anbindungumgesetzt wurden.

4.3.1 Funktionale Anforderungen

/F1/ Bereitstellung von verschiedenen VerbindungsartenMit der Repository-Anbindung ist es moglich sich uber verschiedene Verbin-dungsarten mit dem CVS-Server zu verbinden. Es stehen dazu eine ungesi-cherte (pserver) und eine gesicherte Verbindungsart (SSH ) zur Verfugung.Diese Verbindungsarten wurden umgesetzt, da sie aus eigener Erfahrung amHaufigsten genutzt werden. Die Repository-Anbindung wurde weiterhin sokonstruiert, dass auf einfache Weise weitere Verbindungsarten hinzugefugtwerden konnen. Die genaue Umsetzung dieser Anforderung wird in Kapitel5.2.2 beschrieben.

/F2/ Bereitstellung einer gesicherten Verbindung zum CVS-ServerEine gesicherte Verbindung mit dem Repository-Server ist uber SSH mog-lich. Es wird dabei die volle Funktionsfahigkeit von SSH2 genutzt. Insbeson-dere konnen folgende Verschlusselungsalgorithmen genutzt werden: Blow-fish, 3-DES, AES-128bit, AES-192bit und AES-256bit. Die Auswahl erfolgttransparent fur den Benutzer jeweils durch die beiden Kommunikationsend-punkte. Dies garantiert, dass die Ubertragung von sensiblen Daten unpro-blematisch uber das Internet erfolgen kann.

/F3/ Zugriff auf einen bestimmten Branch/Tag ermoglichenDer Benutzer kann bei der Erstellung der Repository-Seite beliebige Revi-sionen eines Artefakts wahlen. Er hat ebenfalls die Moglichkeit Entwick-lungszweige zu spezifizieren, von denen der Import erfolgen soll. Dabei wirdjeweils die aktuellste Version eines Artefakts importiert.Die Angabe einer beliebigen Revisionsnummer oder Tags fuhrt dazu, dasskeine Aktualisierungen fur diese Repository-Seite moglich sind.

/F4/ Darstellung der Datei- und Ordnerstruktur eines ProjektsEs wird auf die Ordneransicht der CURE-Plattform zuruckgegriffen. Da-durch wird gewahrleistet, dass der Benutzer ein gewohntes Arbeitsumfeldwiederfindet und er somit schnell und effizient an die gewunschten Informa-tionen gelangt. CURE stellt Seiten und Ordner sowohl textuell als auch inForm von Icons dar. Ein Klick auf einen Seitennamen oder das dazugehori-ge Icon fuhrt zur Ansicht der Datei, ein Klick auf einen Ordner fuhrt zumOffnen des Ordners, d.h. zum Abstieg innerhalb der Ordnerhierarchie. Esstehen auch Icons zum Aufsteigen innerhalb der Hierarchie zur Verfugung,so dass beliebig durch die Struktur navigiert werden kann.


Artefakte des Repositories werden durch Seiten reprasentiert. Der Seitenna-me eines Artefakts wird durch den Dateiname des Artefakts bestimmt. Sei-tennamen mussen innerhalb von CURE eindeutig sein. Sollte ein Seitenamebereits vergeben sein, so wird dem Namen eine Ziffer angehangt, damit dieEindeutigkeit wieder hergestellt wird. Es kann daher vorkommen, dass derSeitenname nicht mit dem Dateinamen des Artefakts ubereinstimmt.

/F5/ Darstellung des Inhalts eines Artefakts aus dem Reposito-ryDie Inhalte der Artefakte aus dem Repository konnen betrachtet werden.Es wird hierfur eine spezielle Seitenansicht zur Verfugung gestellt. Die Dar-stellung erfolgt dabei mit Hilfe eines ”Single Document Interface“2 [SDI07].Diese Form der Darstellung wurde so gewahlt, da die gesamte Kooperati-onsplattform auf dieser Art der Darstellung basiert.

/F6/ Darstellung von Metainformationen eines ArtefaktsWie bereits erwahnt, werden Metainformationen bei der Ansicht eines Ar-tefakts dargestellt. Es war mir sehr wichtig, diese Metainformationen direktbeim Betrachten des Artefakts anzuzeigen. Bei vielen CVS-Clients wie Tor-toiseCVS [TOR07] oder jCVS [JCV07] findet dies keine Berucksichtigung.Sie sind lediglich uber zusatzliche Dialogschritte abfragbar. Das empfindeich als Nachteil, da diese Informationen haufig direkt im Zusammenhang mitden Artefakten benotigt werden. Als Vorbild dient hier die Losung ViewVC[VIE07], welche die Informationen direkt in der Ordnerstruktur anzeigt. Lei-der war es mir nicht moglich dies in der Repository-Anbindung umzusetzen,da hier eine bestehende Ansicht genutzt wurde, welche diese zusatzlichenInformationen nicht darstellen kann.

/F7/ Zugriff auf die Historie eines ArtefaktsDer Zugriff auf die Historie eines Artefakts wird ebenfalls in der Ansicht desDokuments ermoglicht. Es wurde dabei auf eine graphische Darstellung derVersionshistorie verzichtet. Dies ist insofern unnotig, da es bisher nur mog-lich ist Versionen eines Entwicklungszweiges zu importieren. Es entstehensomit keine Versionsbaume, bei denen eine graphische Darstellung der Ver-zweigungen sehr hilfreich sein kann. Abbildung 4.6 stellt die Schaltflachen,uber die der Zugriff auf die verschiedenen Revisionen ermoglicht wird, dar.

Abbildung 4.6: Schaltflachen zum Zugriff auf die Versionshistorie

2 SDI - bezeichnet eine Form der Darstellung, bei dem die Inhalte in einem Hauptfensterangezeigt werden.


Die Bedeutung der Schaltflachen ist dabei von links nach rechts: zeige einetabellarische Auflistung der Versionen, zeige die vorherige Version, zeige dienachste Version und zeige die aktuellste Version.

/F8/ Visualisierung von Unterschieden zwischen den VersionenEs ist moglich sich uber die Unterschiede zwischen zwei Versionen zu in-formieren. Bei binaren Dateien werden die Unterschiede lediglich durch dieDateiattribute sichtbar. Bei textbasierten Artefakten wird dabei angezeigt,welche Zeilen in der neuen Version hinzugefugt, geloscht oder verandert wur-den. Abbildung 4.7 zeigt ein Beispiel, bei dem Zeilen geloscht und geandertwurden. Bei einer Anderung einer Zeile wird zusatzlich zur aktuellen Versi-on die Zeile in der Vorversion dargestellt. Die Veranderungen werden dabeifarblich hervorgehoben und erleichtern somit den Vergleich.

Abbildung 4.7: Unterschiede zwischen Artefakten

/F9/ automatische Synchronisation mit dem RepositoryDie Synchronisation erfolgt nach dem Eintreffen einer Benachrichtigung vomRepository-Server automatisch. Damit der Repository-Server Aktualisierungs-nachrichten verschickt, muss eine E-Mailadresse hinterlegt werden. Nahe-re Informationen zu den dafur notwendigen Einstellungen findet man un-ter [BF03]. Die Repository-Anbindung setzt voraus, dass diese Einstellun-gen vorgenommen wurden, da sonst die automatische Synchronisation nichtfunktioniert. Die Empfangeradresse ist fur jede Repository-Seite eindeutig.Sie kann auf der Infomationsseite der Repository-Anbindung nachgeschla-gen werden. Die korrekte Adresse fur die Repository-Seite in Abbildung 4.8)lautet beispielsweise [email protected] genaue Ablauf der Synchronisation wird naher in Kapitel 5.2.3 beschrie-ben.


Abbildung 4.8: Informationsseite der Repository-Anbindung

/F10/ Benachrichtigung uber Veranderungen im RepositoryDie Benutzer werden auf verschiedene Arten uber die Veranderungen imRepository informiert. Benutzer, welche sich auf der Repository-Seite be-finden, werden uber die Beendigung einer Aktualisierung direkt mit Hilfeeines Informationsdialogs informiert. Weiterhin werden die Aktualisierun-gen auch in den Tagesreport aufgenommen, so dass der Benutzer innerhalbder Plattform mit Hilfe der Neuigkeiten-Ubersicht jederzeit Zugriff auf dieVeranderungen hat (vgl. 4.9). Es besteht aber auch die Moglichkeit sich perE-Mail und damit außerhalb von CURE uber Veranderungen im Repositoryinformieren zu lassen.

Abbildung 4.9: Tagesbericht mit Anzeige der Veranderungen

/F11/ Erfassung und Protokollierung von Veranderungen an Re-positoryAnderungen innerhalb des Repositories werden ebenfalls durch die Repository-Anbindung protokolliert. Es wird daher kein CVS-Client benotigt um Zugriffzu diesen Metainformationen zu haben. Diese Informationen sind besonders


wichtig um Projektstatistiken fuhren zu konnen. Zum Abruf dieser Informa-tionen steht die Neuigkeiten-Ubersicht der Kooperationsplattform CUREzur Verfugung. An zentraler Stelle kann sich nun direkt daruber informiertwerden, welche Seiten innerhalb von CURE und welche Artefakte im Repo-sitory, zu welchem Zeitpunkt geandert wurden.

/F12/ Bereitstellung eines Artefakts bzw. eines Projekts zumDownloadAuf der Repository-Seite kann der Benutzer das gesamte Projekt herunter-laden. Es wird dabei die aktuellste Version jeder Datei bereitgestellt. DerBenutzer kann die Dateien daraufhin lokal betrachten und bearbeiten. Nachdem Import wird kein Zugang mehr zum CVS-Repository benotigt. Durchdie Bereitstellung innerhalb von CURE kann nun jedoch die gesamte Ar-beitsgruppe auf die Inhalte zugreifen. Weiterhin hat der Benutzer die Mog-lichkeit einzelne Artefakte aus dem Repository herunterzuladen. Dazu stehtihm in der Ansicht eines Artefakts ein Link zur Verfugung. Sollten die In-halte lokal verandert werden, kann die Repository-Anbindung nicht dazugenutzt werden diese Artefakte wieder in das CVS-Repository zu spielen.Sie ist bisher lediglich fur einen lesenden Zugriff auf das Repository konzi-piert.

/F13/ Assoziationen mit den ArtefaktenDie Losung erlaubt es, dass Assoziationen aus anderen Modulen der Platt-form mit den Artefakten aus dem Repository hergestellt werden konnen. Esist somit moglich innerhalb von E-Mails, aus dem Chat und von Wiki-Seitenauf die Artefakte zu verweisen. Ein Artefakt wurde als normale CURE-Seiterealisiert, damit die Benutzer wie gewohnt auf diese neue Seitenart verwei-sen konnen. Die Syntax fur die Verweise entspricht den Vorgaben fur Linkszu anderen Seiten der Plattform [Haa07], so dass der Benutzer in gewohnterWeise auf die Artefakte im Repository verweisen kann.Abbildung 4.10 verdeutlicht die Erstellung von Assoziationen am Beispieleiner Wiki-Seite.

/F14/ Suche nach Artefakten ermoglichen und /F15/ Volltextsu-che im Inhalt eines ArtefaktsDie Suche der CURE-Plattform kann nun auch genutzt werden um in undnach Artefakten zu suchen. Es ware ebenfalls denkbar gewesen eine Suchenur fur Artefakte zu realisieren, welche direkt in die Repository-Anbindungintegriert ist. Ich habe mich gegen diese Moglichkeit entschieden, da somitunterschiedliche Werkzeuge fur eine Suche benutzt werden mussten. Diesware meines Erachtens nicht intuitiv fur den Benutzer gewesen. Nun stehteine ubergreifende Suche bereit, mit der der gesamte Inhalt der Plattformdurchsucht werden kann. Die Suche berucksichtigt auch die Berechtigun-


Abbildung 4.10: Assoziation mit dem Repository aus einer Wiki-Seite

gen der Benutzer, so dass der Zugriff auf Inhalte auch innerhalb der Sucheverwehrt wird, wenn die dafur notwendigen Leserechte fehlen.

4.3.2 Nichtfunktionale Anforderungen

Die Losung ist so konzipiert, dass sie auf einfache Weise eine Anbindung anandere Repositories ermoglicht /NF1/. Dies wird genauer im Kapitel 5.2.2erlautert. Die nahtlose Integration in die CURE-Plattform wurde bereitsausfuhrlich diskutiert /NF4/. Dies wurde hauptsachlich durch die Nutzungund Erweiterung von bestehenden Komponenten erreicht.Weiterhin lehnen sich Design /NF2/ und Interakionsmoglichkeiten /NF3/eng an die Plattform an. Ebenso wurde die Mehrsprachenunterstutzung derKooperationsplattform auch in der Repository-Anbindung fortgesetzt. DieRepository-Anbindung unterstutzt derzeit die Sprachen Deutsch und Eng-lisch. Sie kann jedoch einfach auf weitere Sprachen erweitert werden, da alleTexte der Benutzeroberflache an zentraler Stelle verandert und erweitertwerden konnen.

Kapitel 5

Details der Losung

Die vorliegende Losung der Repository-Anbindung wurde mit Hilfe der Pro-grammiersprache Java [JAV07a] in der Version 1.5.2 realisiert. Die Program-miersprache war bereits vorgegeben, da die Kooperationsplattform CUREin dieser Sprache programmiert wurde und die Losung in diese Plattformintegriert werden sollte.Als Realisierungsplattform wurde ein SuSE 10.0 [SUS07] genutzt, welchesauf dem Linux Kernel 2.6.13 aufsetzt. Als Entwicklungsumgebung wurdedabei Eclipse 3.2.1 [ECL07] eingesetzt.Als Basis dieser Arbeit diente die CURE-Entwicklungsplattform vom 30.Oktober 2006 auf dem Entwicklungsbranch MAPPER1.Bei der Kooperationsplattform CURE handelt es sich um eine webbasierteLosung. Sie erfordert daher einen Webserver als Ausfuhrungsumgebung. Furdie Entwicklungsumgebung wurde ein Apache Tomcat [TOM07] in der Ver-sion 5.5.7 genutzt. Apache Tomcat nimmt die Benutzeranfragen per HTTP-Anfrage entgegen und leitet sie an spezielle Java-Servlets2, welche innerhalbvon CURE realisiert sind, weiter. Die Java-Servlets sind fur die Interaktionmit dem Benutzer zustandig.Zur Speicherung von persistenten Daten wurde ein MySQL Server [MYS07]in der Version 4.1.13 verwendet. Durch ein einfaches objektrelationales Map-ping werden die Attribute von persistenten Objekten innerhalb von CUREauf Tabellen und Spalten der relationalen Datenbank und wieder zuruckabgebildet. Fur die Datenspeicherung konnen jedoch auch XML-Dateien3

oder andere Datenbanken wie HSQLDB [HSQ07], PostgreSQL [POS07] oderOracle [ORA07] verwendet werden. Die Repository-Anbindung ist auch furdiese Varianten der Datenhaltung vorgesehen.

1 Abk. Model-based Adaptive Product and Process Engineering. Es handelt sich dabeium ein Projekt mit Beteilung der Fernuniversitat Hagen. [MAP07]

2 Als Java-Servlets bezeichnet man Instanzen von Javaklassen, welche innerhalb einesWebservers Anfragen von Clients entgegennehmen.

3 Abk. Extensible Markup Language - eine Auszeichnungssprache zur Darstellung hier-archisch strukturierter Daten

65

KAPITEL 5. DETAILS DER LOSUNG 66

Fur die Prasentation der Daten werden HTML-Seiten genutzt, welche durchCSS-Formatvorlagen4 bereichert werden. Die Erzeugung der HTML-Seitenerfolgt durch einen zweistufigen Prozess. Dabei wird zuerst eine XML-Daten-struktur erzeugt, welche den Seitenaufbau beschreibt. Diese Struktur wirdinnerhalb der Klassen erzeugt, welche fur die Ansicht verantwortlich sind.Die anschließende Umsetzung der XML-Datenstruktur in HTML wird danndurch das CURE-Framework ubernommen. Die Seiten konnen durch Java-script-Code erganzt werden, welcher die Anpassung der Inhalte auf Client-seite ubernimmt.Fur die E-Mailkommunikation wird der Mailserver James [JAM07] in derVersion 2.2.0 eingesetzt. Der Vorteil dieser Integration ist, dass der Mailser-ver ebenfalls in Java geschrieben ist und spezielle Schnittstellen bereitstelltum in die Verarbeitung von E-Mails einzugreifen. Er versendet und empfangtdie E-Mails der Plattform und ist fur die Auslieferung der Tagesreports vonCURE verantwortlich.

5.1 Softwarearchitektur

Die Struktur von CURE und somit auch der Repository-Anbindung folgtdem MVC-Modell5 [Ree78]. Es handelt sich hierbei um ein Entwurfsmus-ter, welches Softwaresysteme in drei Einheiten aufteilt: das Datenmodell,die Prasentation und die Programmsteuerung. Ziel ist es dabei ein flexiblesProgrammdesign zu erreichen, welches es ermoglicht, dass spatere Erweite-rungen relativ einfach integrierbar sind und die Wiederverwendbarkeit dereinzelnen Komponenten erhoht wird. Java-Servlets sind innerhalb von CU-RE als Realisierung der Controller implementiert. Spezielle Ansichtsklas-sen beschreiben den Seitenaufbau mit Hilfe der erwahnten XML-Struktur,welche durch das CURE-Framework in HTML ubersetzt wird. Das Modellder Anwendung stellen spezielle Klassen dar, welche die objektorientierteBeschreibung der Inhalte aus der Datenhaltungsschicht enthalten. Entspre-chend diesem Entwurfsmuster wurden die Komponenten der Repository-Anbindung strukturiert.Abbildung 5.1 verdeutlicht die Strukturierung der Pakete. Das zentrale Pa-ket der Repository-Anbindung ist das Paket de.fuh.csclportal.repositoryclient.Es beinhaltet das Paket clientplugins, welches fur die Kommunikation mitdem CVS-Repository verantwortlich ist, das Datenmodellpaket model, wel-ches die Datenhaltungsklassen enthalt, das Prasentationspaket view, mit denAnsichtsklassen der Anwendung, das James-Paket mit der Anbindung anden Mailserver James und ein Hilfspaket Util mit allgemeinen unabhan-gigen Klassen. Hervorzuheben ist, dass sich der Controller der Repository-

4 Abk. Cascading Style Sheets - eine deklarative Formatierungssprache5 Abk. Model-View-Controller Modell - ein Architekturmuster zur Aufteilung von Soft-

waresystemen


Anbindung außerhalb des Repository-Client-Pakets befindet. Dies ist auf dieenge Anbindung an das CURE-Framework zuruckzufuhren. Der Controllerder Repository-Anbindung heißt RoomServlet und befindet sich im Paketde.fuh.csclportal.webui.

Abbildung 5.1: Strukur der Pakete innerhalb der Repository-Anbindung

5.1.1 Model

Zentrale Elemente im Modell sind die Klassen RepositoryPage, RepositoryFi-lePage und RepositoryFolder (vgl. Abbildung 5.2). Hilfsklasse ist in diesemPaket die Klasse RepositoryLoginData.Die Klasse RepositoryPage dient der Speicherung der Daten einer Reposito-ryseite. Sie ist die Grundlage fur die Ansicht des Repositories. Jede Instanzder Klasse RepositoryPage ist mit genau einer Instanz der Klasse Repository-Folder verbunden, welche das Wurzelverzeichnis des Repositories darstellt.Weiterhin ist jede Instanz der Klasse RepositoryPage mit einer Instanz derKlasse RepositoryLoginData verbunden, welche die Verbindungsdaten zumRepository beinhalten. Die Klasse RepositoryFolder modelliert einen Ordnerinnerhalb eines Repositories. Ein Ordner enthalt eine Menge von Repository-Dateien, welche durch die Klasse RepositoryFilePage reprasentiert werden.

5.1.2 View

Das Paket de.fuh.csclportal.repositoryclient.view der Repository-Anbindungkann in die Bereiche Seiten- und Menuansichten eingeteilt werden. Fur dieKlasse RepositoryFilePage existieren folgende Seitenansichten: PrintRepo-sitoryFilePageView, welche die Druckansicht darstellt und PrintReposito-ryFilePageHTMLRenderer, welche die Ansicht sowohl fur Text- als auch


Abbildung 5.2: Klassendiagramm des Modell-Pakets

Binardateien generiert. Zusatzlich wurde die Menuansicht RepositoryFile-PageMenuBarView entwickelt, welche ein spezielles Menu fur die Reposi-toryFilePage bereitstellt. Beispielsweise wird hier die Schaltflache fur denVergleich zwischen zwei Revisionen bereitgestellt. Die Versionsmenuleisteder Klasse RepositoryFilePage wird durch die Klasse RepositoryFilePage-VersionsMenuBarView bereitgestellt.Die Strukturierung der Klassen zur Anzeige einer RepositoryFilePage wirdin Abbildung 5.3 verdeutlicht.

Abbildung 5.3: Klassenstruktur des View-Pakets fur die RepositoryFilePage

Fur die Klasse RepositoryPage existiert die Ansichtsklasse RepositoryPa-


geHTMLRenderer. Die Klasse stellt den Inhalt der Verzeichnisse des Reposi-tories dar. Als Hilfsklasse wird dazu die Klasse RepositoryFolderContentViewbenutzt. Die Menuleiste der RepositoryPage wird durch die Klasse Reposi-toryPageMenuBarView reprasentiert. Sie stellt spezielle Schaltflachen, wieden Downloadbutton fur das Repository zur Verfugung. Befindet sich derBenutzer nicht im Wurzelverzeichnis der Repository-Seite so wird zur An-zeige der Menuleiste die Klasse RepositoryFolderButtonsView genutzt.Die Strukturierung der Klassen zur Anzeige einer RepositoryPage wird inAbbildung 5.4 verdeutlicht.

Abbildung 5.4: Klassenstruktur des View-Pakets fur die RepositoryPage

Weiterhin existiert eine besondere Seitenansicht - die RepositoryPageHelp-View - fur die Repository-Seite (vgl. Abbildung 5.5). Diese hat die Aufga-be besondere Informationen zur Repository-Seite anzuzeigen, beispielsweisewird hier die E-Mailadresse angezeigt, an die der CVS-Server Aktualisie-rungsnachrichten fur diese Repository-Seite senden muss.Wichtig fur die Realisierung des Gruppenbewusstseins ist die Klasse Reposi-toryActiveview. Sie ermoglicht es, dass die Benutzer uber Aktualisierungenbenachrichtigt werden, wenn sie sich auf einer Repositoryseite befinden. DieBenutzer werden dabei uber die Aktivitaten von anderen Benutzern infor-miert. Die genaue Realisierung wird in Abschnitt 5.2.4 beschrieben.

5.1.3 Controller

Die zentrale Steuerungsklasse fur die Repository-Anbindung ist die Klas-se RoomServlet, welche sich im Paket de.fuh.csclportal.webui befindet. DieseKlasse wurde fur die Arbeit um Methoden zur Interaktionen mit dem Benut-zer im Zusammenhang mit dem Repository erweitert. Dies war notwendig,da es sich bei der Repository-Seite um eine ganz normale CURE-Seite han-


Abbildung 5.5: Klassenstruktur des View-Pakets fur die zusatzlichenAnsichten der Klasse RepositoryPage

delt. Fur die Interaktion im Zusammenhang mit CURE-Seiten ist jedochdie Klasse RoomServlet verantwortlich, so dass hier lediglich eine Erweite-rung in Frage kam. Ein Vorteil dieser Erweiterung ist, dass viele Methodender Klasse RoomServlet nun auch fur die Behandlung von Repository-Seitennachgenutzt werden.

5.1.4 Repository-Anbindungen

Das Paket de.fuh.csclportal.repositoryclient.clientplugins ist fur die Kommu-nikation mit den Repository-Server und fur die lokale Verarbeitung der Ar-tefakte zustandig. Es stellt verschiedene Unterpakete zur Verfugung, derenFunktionalitaten im Folgenden naher erlautert werden.

de.fuh.csclportal.repositoryclient.clientplugins.common In diesemPaket wird ein Interface IRepositoryClient bereitgestellt, welches die Metho-den beschreibt, die notwendig sind damit andere Repository-Anbindungenmoglichst einfach in die Anwendung eingebunden werden konnen. Die Funk-tionsweise des Frameworks und der Integration von anderen Repository--Arten werden im Abschnitt 5.2.2 beschrieben.Weiterhin wird eine Klasse LocalProjectManager bereitgestellt. Sie kummertsich darum die heruntergeladenen Artefakte, welche sich im lokalen Datei-system befinden, in CURE-Objekte abzubilden.

de.fuh.csclportal.repositoryclient.clientplugins.service In diesem Pa-ket werden die Klassen RepositoryCheckoutThread und RepositoryUpdate-Thread bereitgestellt. Es handelt sich hierbei um Dienste, welche im Hinter-grund von CURE laufen. Sie kummern sich um eine Aktualisierung bzw. um


das Herunterladen der Artefakte vom Repository-Server. Diese Klassen wur-den als Thread realisiert, damit wahrend einer Aktualisierung oder wahrenddes Herunterladens keine Beeintrachtigung der Arbeit mit der Plattform be-merkbar ist. Beide Threads unterteilen ihre Tatigkeiten in viele unabhangigeTransaktionen, so dass andere Benutzer weiterhin normal mit der Plattformarbeiten konnen, wahrend die Repository-Anbindung im Hintergrund arbei-tet.

de.fuh.csclportal.repositoryclient.clientplugins.cvsplugin Dieses Pa-ket stellt die Klasse CVSRepositoryClient zur Verfugung. Die Klasse ist furdie Kommunikation mit dem CVS-Server zustandig. Sie sendet die notwendi-gen Anfragen und verarbeitet die Antworten vom Server. Weiterhin speichertsie das ausgecheckte Repository in das Dateisystem des CURE-Servers. Die-ser Bereich wird fur die Synchronisation mit dem Repository genutzt undbleibt bis zum Loschen der Repository-Seite bestehen.Fur die Kommunikation mit dem Server wurde die Bibliothek javacvs [JAV07b]genutzt. Die Bibliothek ist in der Abbildung 5.6 durch das Paketorg.netbeans.lib.cvsclient dargestellt. Die Bibliothek implementiert das CVS-Client-Protokoll vollstandig in Java und stellt eine einfach nutzbare API6 zurVerfugung.Innerhalb dieses Pakets wurden weitere Hilfsklassen entwickelt, welche spe-ziell die Antworten vom CVS-Server verarbeiten. Die Klasse BaseListenerdient als Basis fur die anderen Hilfsklassen und ist fur die Verarbeitungvon Fehlern zustandig. Die Klasse CheckoutListener verarbeitet Nachrich-ten, die beim Herunterladen eines Projekts auftreten. Sie ist hauptsachlichdafur verantwortlich zu protokollieren, welche Dateien heruntergeladen wur-den. Die Klasse IsModuleExistingListener uberpruft, ob ein Projekt existiert.Sie wird beim Aufbau der Verbindung zum CVS-Server benutzt. Die KlasseLogListener ist dafur da die Nachrichten zu verarbeiten, welche auftreten,wenn Metainformationen zu einem Artefakt abgefragt werden. Die KlasseRevisionListener wird benutzt, wenn die Historie eines Artefakts herunter-geladen wird. Sie protokolliert die Metainformationen und reicht sie an dieApplikation weiter. Die Klasse UpdateListener ist fur die Verarbeitung vonNachrichten wahrend einer Aktualisierung notwendig. Sie protokolliert bei-spielsweise, welche Dateien sich verandert haben und reicht diese an dieApplikation weiter.Abbildung 5.6 verdeutlicht die aufgefuhrten Beschreibungen.

6 Abk. Application Programming Interface


Abbildung 5.6: Klassenstruktur des Clientplugin-Pakets

5.1.5 James-Anbindung

Das Paket de.fuh.csclportal.repositoryclient.james (vgl. Abbildung 5.7) stelltdie Anbindung an den Mailserver James dar. Es werden die Klassen Reci-pientIsRepositoryPage, RepositoryJamesUtil und UpdateRepositoryManagerbereitgestellt.

Abbildung 5.7: Klassenstruktur des James-Pakets


Die Klasse RecipientIsRepositoryPage ist dafur zustandig festzustellen, obsich bei einer eintreffenden E-Mail um eine Aktualisierungsnachricht an eineRepository-Seite handelt. Der UpdateRepositoryManager informiert CUREbei einer positiven Ruckmeldung daruber, dass eine Aktualisierung einerRepository-Seite notwendig ist. Die Klasse RepositoryJamesUtil stellt allge-meine, von beiden Klassen genutzte Funktionalitaten bereit.Ein detaillierterer Einblick in die Integration des Mailservers James findetin Kapitel 5.2.3 statt.

5.1.6 Utility

Innerhalb des Pakets de.fuh.csclportal.repositoryclient.util wurde die KlasseRepositoryUtil realisiert. Diese Klasse stellt eine Menge an Konstanten zurVerfugung, welche in der gesamten Applikation genutzt werden. Weiterhinwerden applikationsunspezifische Methoden implementiert, welche auch vonmehreren Klassen genutzt werden.

5.2 Besondere Implementierungsdetails

An dieser Stelle wird darauf verzichtet, die kompletten technischen Detailsder Arbeit wiederzugeben. Es werden lediglich einige wichtige Punkte vor-gestellt. Bei weiterem Interesse wird auf die Dokumentation des Quellco-des nach dem Javadoc-Standard7 [JAV07c] verwiesen. Der Quellcode derRepository-Anbindung ist im CVS-Repository von CURE [CUR] im BranchREPOSITORY CLIENT abgelegt.

5.2.1 Sichere Kommunikation mit dem CVS-Server

Die eingebundene Bibliothek javacvs [JAV07b], welche die Kommunikati-on mit dem CVS-Server ubernimmt, bietet bisher keine eingebettete SSH-Unterstutzung. Bisher musste die sichere Kommunikation uber zusatzlicheexterne Software8 realisiert werden. Eine besondere Anforderung dieser Ar-beit war jedoch die gesicherte Ubertragung der Authentifizierungs- undNutzdaten. Die Abhangigkeit zu externen Programmen war jedoch nichtnotwendig, da bereits native Javaimplementierungen wie z.B. JSch [JSC07]existieren, welche die gesamte Funktionalitat eines SSH-Clients bereitstellen.Ich habe mich deshalb dazu entschlossen, die javacvs Bibliothek um ei-ne Klasse ExtConnection zu erweitern, welche eine gesicherte Kommuni-kation mit dem CVS-Server bereitstellt. ExtConnection benutzt Klassender JSch-Bibliothek um eine SSH-Verbindung auf- und wieder abzubauen.

7 Dokumentationswerkzeug, welches aus Kommentaren in Java-Quelltexten automa-tisch Dokumentationsdateien erstellt

8 uber ein externes Programm wird die Verbindung zum Server hergestellt, z.B. RSHoder SSH


Sie erbt von der Klasse AbstractConnection der javacvs-Bibliothek, imple-mentiert deren abstrakte Methoden und ist dadurch vollstandig in das ja-vacvs-Framework eingebunden. Die Klasse ExtConnection stellt im Prinziplediglich einen Eingabe- und Ausgabestrom zur Verfugung, um mit demCVS-Server zu kommmunizieren. Das javacvs-Framework benutzt diesenMechanismus transparent.Die folgende Abbildung 5.8 verdeutlicht die Einbindung durch ein UML9-Sequenzdiagram. Dabei wird gezeigt, dass innerhalb der Klasse Connection-Factory ein Objekt der Klasse ExtConnection erzeugt wird. Dieses Objektwird fur die Kommunikation mit dem CVS-Server benutzt.

Abbildung 5.8: Sequenzdiagramm zur Einbindung der KlasseExtConnection

5.2.2 Erweiterbarkeit fur andere Versionierungswerkzeuge

Diese Anforderung wurde deshalb aufgenommen, da Softwareprojekte auchmit anderen Werkzeugen wie z.B. Subversion oder Rational ClearCase ver-waltet werden konnen. Es sollte daher mit moglichst wenig Anderungsauf-wand moglich sein einen Client zu integrieren, welcher die Kommunikationmit diesen Servern ubernimmt.

9 Abk. Unified Modeling Language


Um diese Anforderung zu realisieren, wurde das Interface IRepositoryClienteingefuhrt. Die Klassen, welche die Kommunikation mit den anderen Versi-onsverwaltungswerkzeugen ubernehmen, mussen die Methoden der Schnitt-stelle implementieren.Es soll nun kurz die Semantik der bereitgestellten Methoden erlautert wer-den.

• boolean login()Diese Methode soll uberprufen, ob mit den gegebenen Verbindungsda-ten ein Login zum Repository-Server moglich ist. Bei einem erfolgrei-chen Login soll true zuruckgegeben werden, ansonsten false.

• boolean checkout(Collection<String> filePathes)Die implementierende Methode muss einen Checkout eines Projektsvornehmen und die Pfade zu den heruntergeladenen Artefakten liefern.

• boolean update(Collection<String> filePathes)In der abgeleiteten Klasse muss eine Aktualisierung des lokalen Pro-jekts vorgenommen und die Pfade zu den aktualisierten Daten geliefertwerden.

• boolean getCheckinComment(File file, StringBuffer fileComment)Die implentierende Methode soll fur die ubergebene Datei Metainfor-matonen aus dem Repository liefern und diese in die Variable fileCom-ment fullen.

• boolean isModuleExisting()Der Repository-Client muss prufen, ob ein Projekt existiert und dement-sprechend den Ruckgabewert setzen.

• boolean getPreviousRevisionStrings(File currentVersion,HashMap<String,String> revisions)Es sollen fur eine gegebene Version einer Datei alle Metainformationenzu den Vorversionen geliefert werden. Dabei ist die Tabelle revisionsso zu fullen, dass als Schlussel jeweils eine Revision und als Wert diedazugehorige Metainformation gesetzt wird.

Das Framework der Repository-Anbindung nutzt diese Schnittstelle folgen-dermaßen: Zu jedem Objekt der Klasse RepositoryPage wird zusatzlich ge-speichert, welche Art von Repository diese Seite referenziert. Diese Art wirddurch einen voll qualifizierten Java-Klassennamen reprasentiert. Es mussdementsprechend veranlasst werden, dass beim Speichern einer Repository-Seite der qualifizierte Klassenname des neuen Repository-Clients hinzuge-fugt wird. Die Klasse RepositoryUtil stellt dazu eine Methode bereit, welche


diese Information nutzt, um mittels der Reflection10-API der Programmier-sprache Java ein Clientobjekt der entsprechenden Repository-Art zu erzeu-gen. Das Framework der Repository-Anbindung erstellt mit Hilfe dieser Me-thode eine Instanz zur Kommunikation mit dem jeweiligen Repository undkommuniziert uber ein Objekt vom Typ der Schnittstelle mit dieser Instanz.Das Framework ruft dann die vorgestellten Methoden auf um an die Infor-mationen zu gelangen. Mit Hilfe dieser Informationen werden die Objekteinnerhalb von CURE erstellt.Es ist dadurch sichergestellt, dass lediglich uber die Realisierung der Schnitt-stelle eine weitere Repository-Art in den Repository-Anbindung integriertwerden kann. Dies stellt eine sehr einfache, aber machtige Erweiterungs-moglichkeit zur Verfugung.

5.2.3 Anbindung an den Mailserver James

Der CVS-Server kann so konfiguriert werden, dass er eine E-Mail verschickt,sobald sich ein Artefakt in einem Projekt verandert. Ein Benutzer des CVS-Systems braucht dann nur eine Datei im Repository zu aktualisieren und derServer verschickt eine E-Mail an alle konfigurierten Adressen. Eine Repository-Seite hat deshalb innerhalb der CURE Plattform eine eindeutige E-Mail-Adresse, an welche diese Information geschickt werden kann. Die Verarbei-tung von eintreffenden E-Mails ubernimmt innerhalb von CURE der Mailser-ver James [JAM07]. Dieser Mailserver stellt mit Hilfe so genannter Matchereine Schnittstelle zum Uberprufen von eingehenden E-Mails zur Verfugung.Diese Matcher konnen in Java geschrieben werden und mussen beim Mailser-ver registriert werden, damit dieser bei der Verarbeitung einer eintreffendenE-Mail auf sie zuruckgreift.Die Repository-Anbindung implementiert daher einen solchen Matcher na-mens RecipientIsRepositoryPage. Die Klasse erbt von der Klasse Generi-cRecipientMatcher um Zugriff auf die E-Mail-Adresse des Empfangers zubekommen.Die folgende Beschreibung stellt eine Erlauterung fur die Abbildung 5.9 dar.Die Ziffern innerhalb der Beschreibung beziehen sich auf die einzelnen Schrit-te der Abbildung.Wird eine Nachricht an den Mailserver James geschickt (1), uberpruft die Re-cipientIsRepositoryPage, ob es sich bei der eintreffenden E-Mail um eine Ak-tualisierungsnachricht an eine bestimmte Repository-Seite handelt (2)+(3).Wenn dies der Fall ist, so informiert die Instanz den Aktualisierungsdienst(4) - RepositoryUpdateThread - der Repository-Anbindung, welcher darauf-hin eine Aktualisierung der Repository-Seite (6)+(7) veranlasst.

10 In der Programmierung bedeutet Reflexion (engl. reflection), dass eine AnwendungKenntnisse uber seine eigene Struktur gewinnen kann.


Abbildung 5.9: Anbindung an den Mailserver James

5.2.4 Benachrichtigung der Benutzer uber Aktualisierungen

Ein Problem bei Webanwendungen ist die Tatsache, dass lediglich Infor-mationen beim Webserver abgerufen werden konnen. Das HTTP-Protokoll,welches den Datenaustausch zwischen Browser und Webserver regelt, istein typisches Request/Response-Protokoll. Es ist nicht vorgesehen, dass derServer den Client unaufgefordert eine Nachricht sendet. Es ware aber wun-schenswert Benutzer sofort uber die Aktualisierung eines Repositories zuinformieren, wahrend sie mit dem Lesen einer Repository-Seite beschaftigtsind.Die Repository-Anbindung nutzt fur die Losung dieses Problem die Ver-teilung von Nachrichten mit Hilfe von ActiveMQ [ACT07] und AJAX11

[AJA07]. Abbildung 5.10 zeigt den vereinfachten Ablauf. Wiederum beziehensich die Ziffern in der Beschreibung auf die einzelnen Schritte der Abbildung.Sobald eine Aktualisierung eines Repositories durch einen CVS-Client abge-schlossen ist, wird eine E-Mail an CURE gesendet. Die Repository-Anbindungaktualisiert daraufhin die lokale Projektkopie (1). Nach einer erfolgreichenAktualisierung wird eine Nachricht an den in CURE integrierten ActiveMQ-Server geschickt (2), welcher das aufgetretene Ereignis fur angemeldete Cli-ents bereithalt. Ein spezielles Servlet - das AjaxServlet - fragt die Nachrich-ten beim ActiveMQ-Server ab und halt sie fur angemeldete Benutzer zumAbruf bereit (3). Wahrenddessen kann der Benutzer unabhangig davon miteiner Repository-Seite arbeiten. Die Seite, welche mit dem Browser abge-rufen wurde, enthalt einen speziellen ActiveMQ-Client Javascriptcode, wel-cher sich per HTTP bei CURE registriert. Weiterhin fragt dieser ActiveMQ-Client in regelmaßigen Abstanden beim Server nach, ob Ereignisse fur ihn

11 Abk. Asynchronous JavaScript and XML


Abbildung 5.10: Benachrichtigung der Benutzer uber Aktualisierungen

bereitstehen (4). Nachdem der ActiveMQ-Server die Benachrichtigung uberdie Aktualisierung eines bestimmten Repositories bekommen hat, kann erden Benutzer daruber informieren (5). Der Benutzer bekommt daraufhin dieNachricht, dass sich das Projekt verandert hat und kann die Seite aktualisie-ren (6). Bei einer Aktualisierung der Seite wird der Datenbestand abgerufen(7) und dem Benutzer wird der aktuelle Inhalt des Repositories prasentiert(8). Dies hat den Vorteil, dass der Benutzer immer mit den aktuellen Datenarbeiten kann.

Kapitel 6

ErweiterteAnwendungsmoglichkeiten

Die Bereitstellung eines Zugriffs auf Repositories innerhalb von CURE er-moglicht es, dass spezielle Tatigkeiten im Lauf der Softwareentwicklungdurch CURE unterstutzt werden konnen. Einige dieser Anwendungsmog-lichkeiten sollen nun vorgestellt werden.

6.1 Asynchrone Softwareinspektion

Obwohl schon eine Vielzahl an Review- bzw. Inspektionstechniken fur Ar-tefakte des Softwareentwicklungsprozesses entwickelt wurden, so hat sichdie Grundlage dieser Tatigkeiten bisher nicht verandert. Dazu gehoren eineMenge von Meetings, in denen die Teilnehmer Anmerkungen bzw. Fragen zuden Codeabschnitten besprechen. Dies bedeutet nicht nur einen hohen zeitli-chen Aufwand und Ablenkung von der eigentlichen Tatigkeit, sondern birgtauch Gefahren, dass in der angegebenen Zeit nicht alle Artefakte besprochenwerden konnen, da man sich eventuell in Details verliert. Die Folge warenzusatzliche Meetings oder das Auslassen dieser Artefakte. Um den Prozesseffizienter zu gestalten ist es notwendig diese synchronen Tatigkeiten durchasynchrone Inspektionen zu ersetzen. Eine ahnliche Argumentation wird in[Sap00] und [MM97] vollzogen.CURE kann nun durch die Repository-Anbindung und die Bereitstellungvon Wikiseiten den asynchronen Reviewprozess unterstutzen. Die Benutzerkonnen von uberall, unabhangig voneinander Quellcodeabschnitte innerhalbvon CURE begutachten und Anmerkungen durch Links zu den Artefaktenbereichern. Dazu wird eine zentrale Wikiseite bereitgestellt, an der die Pruferihre Kommentare zusammentragen konnen. Dies muss nicht mehr synchrongetan werden, so dass jeder Prufer sich die dafur notwendige Zeit selbst ein-teilen kann. Sollte eine synchrone Kommunikation notwendig werden, kannein Chat oder die Netmeeting-Integration von CURE genutzt werden.

79

KAPITEL 6. ERWEITERTE ANWENDUNGSMOGLICHKEITEN 80

6.2 Benachrichtigung uber Fertigstellung eines Ar-tefakts

Bei einer dezentralen Softwareentwicklung ist man oftmals auf die Zuar-beit von anderen Personen angewiesen. Beispielsweise konnte ein Tester aufdie Fertigstellung der Software bzw. ein Entwickler auf die Fertigstellungeines bestimmten Artefakts warten. Wahrend der Wartezeit konnen diesePersonen nun andere Arbeiten innerhalb von CURE erledigen. Sobald dieTatigkeit abgeschlossen ist, auf die sie angewiesen sind, werden sie von derPlattform informiert. Dies hatte den Vorteil, dass keine zusatzliche Kommu-nikation erforderlich ist.

6.3 Codesuche

Laut [SLVA97] und [BNL+06] ist die Codesuche eine der haufigsten Aktivi-taten von Softwareentwicklern. Dabei werden unterschiedliche Motivationenfur die Suche genannt. Zum Einem wird dabei nach Implementierungen ge-sucht. Der Benutzer sucht dabei nach einer bestimmten Funktionalitat. Dieskann z.B. eine Komponente oder ein bestimmter Algorithmus sein. Weiter-hin suchen Entwickler nach der Benutzung von Quellcodeabschnitten. Dabeiwird danach gesucht, wie eine bestimmte Klasse oder Methode benutzt wird.Eine weitere Moglichkeit ist die Suche nach bestimmten Eigenschaften einesCodeabschnitts. Dies kann z.B. die Umsetzung eines Entwurfsmusters sein.CURE kann nun in diesem Zusammenhang besonders fur die Suche nachder Benutzung eines Quellcodeabschnittes angewendet werden. Nach demImport eines Repositories besteht die Moglichkeit nach bestimmten Stich-wortern zu suchen. Das Resultat sind Verweise bzw. Textabschnitte, in de-nen der Benutzer die Benutzung der Komponenten nachschlagen kann. DieseSuche konnte naturlich auch mit Hilfe von Entwicklungsumgebungen erle-digt werden. Dies setzt aber den Zugriff auf den Quellcode voraus. Wennman jedoch nicht in ein Projekt involviert ist, besteht in der Regel kein Zu-griff. Innerhalb von CURE kann anderen Benutzern dieser Zugriff gefahrlosmit Hilfe der Repository-Anbindung bereitgestellt werden. Es besteht keineMoglichkeit die Quellen zu verandern.

6.4 Abbilden von Beziehungen im Entwicklungs-prozess

Im Verlauf eines Softwareprojekts entstehen eine Menge von Artefakten. Zunennen sind hier beispielsweise Entwurfsmodelle, Quelltexte, Testfalle undDokumentationen. Diese Artefakte stehen miteinander in Beziehung. Es han-delt sich hierbei jedoch um implizite Beziehungen, welche nicht unbedingtersichtlich sind.

KAPITEL 6. ERWEITERTE ANWENDUNGSMOGLICHKEITEN 81

Weiterhin werden in vielen Phasen der Entwicklung Entscheidungen getrof-fen. Beispielsweise konnte ein Entwickler die Signatur einer Methode zuandern, weil er einen Parameter nicht mehr benotigt. Diese Entscheidunghat jedoch Einfluss auf abhangige Artefakte. Das fuhrt dazu, dass andereEntwickler sich mit dem Entwickler in Verbindung setzen mussen um dieGrunde fur die Anderung zu erfahren. Konnte er die Entscheidung protokol-lieren und in Zusammenhang mit der Anderung bringen, wurden auch ande-re Personen ohne zusatzliche Kommunikation die Ursache fur die Anderungnachvollziehen konnen. Wikis bieten hierfur die entsprechende Funktionali-tat zur Vernetzung und Kommentierung der Inhalte. Dies erleichtert u.a. dieAnpassung, Wartung und Wiederverwendung des Systems und ermoglichteine schnellere Einarbeitung neuer Projektmitarbeiter.Bisher war es jedoch innerhalb von CURE nicht moglich diese Assoziatio-nen zu erzeugen. Mit der Integration der Repository-Anbindung kann dieseArt der Nachvollziehbarkeit realisiert werden. Ferner konnen innerhalb vonCURE Dokumentation zu den Artefakten erstellt (vgl. Abbildung 6.1) unddirekt mit den Artefakten in Beziehung gesetzt werden. Mit Hilfe dieser Me-chanismen wird es ermoglicht, dass Informationen wahrend des gesamtenProjektverlaufs dokumentiert und mit den entsprechenden Artefakten ver-netzt werden konnen. Die Notwendigkeit dieser Vernetzung wird ebenfallsin [Som04] und [HGK07] genannt.

Abbildung 6.1: Assoziationen zwischen Implementierung undDokumentation

Kapitel 7

Zusammenfassung

Die Realisierung zunehmend komplexer Softwareprojekte erfordert das di-rekte Zusammenwirken einer immer großer werdenden Zahl von Personen.Die dafur benotigte Infrastruktur ist mit der zunehmenden Rechnervernet-zung bereits vorhanden, doch wird ihr Potenzial von herkommlichen Werk-zeugen in der Regel nicht ausgeschopft. Es bestehen Ansatze zur Unter-stutzung der verteilten Softwareentwicklung durch Werkzeuge wie CSCW-Losungen und integrierte Entwicklungsumgebungen. Diese konzentrieren sichjedoch oft direkt auf die Unterstutzung von Entwicklungstatigkeiten wie denSoftwareentwurf und die Implementierung. Kollaborationsplattformen un-terstutzen hingegen direkt Kommunikation und Kooperation zwischen denProjektteilnehmern uber alle Phasen des Entwicklungsprozesses hinweg. Eingrundlegender Aspekt dieser Plattformen ist der Zugriff auf die Artefakteund die Verknupfung der Artefakte untereinander.Nach der eingehenden Analyse des Themenbereichs wurden vorhandene Sys-teme im Hinblick auf die Erfullung der ermittelten Anforderungen unter-sucht. Es wurde gezeigt, dass es bestehende Losungen wie CodeBeamer gibt,welche viele Anforderungen bereits umsetzen. Es wurde jedoch auch festge-stellt, dass gerade die Fahigkeit zur Verknupfung von Artefakten und dieBewusstseinsunterstutzung innerhalb der Losungen bisher nicht im gefor-derten Maße umgesetzt wurden.In der vorliegenden Arbeit wurde deshalb eine Erweiterung fur die Koopera-tionsplattform CURE vorgeschlagen, welche den Zugriff auf Repository-Servererlaubt. Die Losung sollte die Projektteilnehmer uber die Veranderungenan Artefakten informieren und somit das Bewusstsein uber die Tatigkeitenanderer Projektteilnehmer erweitern. Weiterhin sollte es ermoglicht werden,Assoziationen zwischen den Artefakten herzustellen um Kommunikation undKoordination der Projektteilnehmer zu fordern. Innerhalb dieser Arbeit wur-de die Losungsidee sowie die Umsetzung der Anforderungen diskutiert. DieSoftwarearchitektur wurde vorgestellt und auf einige besondere Implemen-tierungsdetails eingegangen. Der letzte Abschnitt bewertet das erreichte Er-

82

KAPITEL 7. ZUSAMMENFASSUNG 83

gebnis und zeigt Ansatze zur Verbesserung bzw. zur Erweiterung auf.

7.1 Bewertung der Ergebnisse

Die Losung erlaubt es auf externe CVS-Repositories zuzugreifen und derenInhalte innerhalb von CURE abzubilden. Der Benutzer wird sofort uberAktualisierungen im Repository informiert und kann Assoziationen mit denArtefakten innerhalb von CURE erstellen.Die Losung ermoglicht die Nachvollziehbarkeit von Anderungen an den Ar-tefakten. Die Implementierung fugt sich sowohl aus optischer als auch austechnischer Sicht in die Kooperationsplattform ein.Es wird deutlich, dass die Anforderungen an diese Arbeit vollstandig reali-siert wurden. Daruber hinaus wurde beispielsweise eine Ansicht integriert,in welcher es moglich ist sich uber die Unterschiede zwischen zwei Versioneneines Artefakts zu informieren. Ebenso wurde Syntaxhighlighting fur einekleine Menge von Sprachen integriert, was die Lesbarkeit von Quelltextenerhoht. Bei der Integration des Syntaxhighlightings wurde darauf geachtet,dass die Losung moglichst einfach erweiterbar ist um die Unterstutzung furandere Sprachen mit moglichst wenig Aufwand hinzuzufugen.Tabelle 7.1 vergleicht die realisierte Losung mit zwei der Kollaborations-plattformen aus Kapitel 3, welche die meisten Anforderungen an diese Arbeitbereits umgesetzt haben. Es handelt sich dabei um die System SourceForgeEnterprise Edition und CodeBeamer. Die Anzahl der Sterne in der Tabellebestimmt die Qualitat der Umsetzung der Anforderungen.Im Vergleich der Losungen fallt auf, dass ein geringerer Funktionsumfangbei der Anforderung /F1/ erreicht wurde. Die Repository-Anbindung stellthier lediglich zwei Verbindungsarten zur Verfugung, wahrend in CodeBea-mer alle gangigen Verbindungsarten zu CVS-Servern unterstutzt werden.Ein weiteres Defizit wird bei den Anforderung /F7/ deutlich. Der Importder Historie eines Projekts bezieht sich nur auf einen bestimmten Entwick-lungszweig. Versionen vor der Erzeugung des Branches oder anderen Ver-zweigungen werden nicht importiert. Nach dem Import der Versionen ei-nes Entwicklungszweigs ist deshalb kein Zugriff auf Versionen außerhalb desBranches moglich. Es werden lediglich aufeinander aufbauende Versionenohne Verzweigungen unterstutzt. Die beiden kommerziellen Plattformen ge-wahrleisten jedoch den Zugriff auf den kompletten Versionsbaum.Die Repository-Anbindung hat jedoch auch Vorteile gegenuber den anderenLosungen, so werden beispielsweise Benutzer synchron uber Aktualisierun-gen informiert, wahrend sie mit dem Browser durch das Repository navigie-ren. Die anderen Losungen informieren den Benutzer nur uber E-Mails oderindem der Benutzer aktiv die Anderungen abfragt. Auch sind Assoziatio-nen mit den Artefakten bei CodeBeamer beispielsweise nicht aus dem Chatmoglich.


SourceForge EE CodeBeamer CURE/F1/Bereitstellung von verschie-denen Verbindungsarten

- ??? ?

/F2/ Bereitstellung einer gesicher-ten Verbindung zum CVS-Server

- ?? ???

/F3/Zugriff auf einen bestimmtenBranch/Tag ermoglichen

??? ??? ???

/F4/ Darstellung der Datei- undOrdnerstruktur eines Projekts

??? ??? ???

/F5/Darstellung des Inhalts einesArtefakts aus dem Repository

??? ??? ???

/F6/ Darstellung von Metainfor-mationen eines Artefakts

??? ??? ???

/F7/Zugriff auf die Historie einesArtefakts

??? ??? ?

/F8/ Visualisierung von Unter-schieden zwischen den Versionen

??? ??? ???

/F9/ automatische Synchronisati-on mit dem Repository

??? ??? ???

/F10/ Benachrichtigung uber Ver-anderungen im Repository

??? ??? ???

/F11/ Erfassung und Protokollie-rung von Veranderungen an Repo-sitory

??? ??? ???

/F12/ Bereitstellung eines Arte-fakts bzw. eines Projekts zumDownload

- - ??

/F13/Assoziationen mit den Arte-fakten

? ?? ???

/F14/ Suche nach Artefakten er-moglichen

??? ??? ???

/F15/ Volltextsuche im Inhalt ei-nes Artefakts

??? ??? ???

Tabelle 7.1: Vergleichende Bewertung der Repository-Anbindung

SourceForge Enterprise Edition stellt kein synchrones Kommunikationsmit-tel zur Verfugung und kann daher nicht wahrend eines virtuellen Gesprachsauf die Artefakte verweisen. Bei der Anforderung /F12/ wurde nur fur dieRepository-Anbindung Punkte vergeben. Hier werden das gesamte Projektals Archiv in der aktuellen und einzelne Artefakte in einer beliebigen Versionzur Verfugung gestellt. Sowohl SourceForge Enterprise Edition und CodeBe-amer stellen keine Moglichkeiten bereit ein Projekt uber die Weboberflache


komplett herunterzuladen.Der Vergleich der realisierten Anforderungen zeigt, dass die entwickelte Lo-sung durchaus Vorteile gegenuber kommerziellen Produkten vorweisen kann.

7.2 Erfahrungen mit dem Prototyp

Wahrend der Endphase der Entwicklung wurde der Quellcode der Repo-sitory-Anbindung in die CURE-Entwicklungsplattform importiert um dasSystem im laufenden Entwicklungsprozess zu testen. Dabei zeigte sich, dassdie Anbindung auch dann schon genutzt werden kann, wenn nur ein Ent-wickler am System arbeitet. Naturlich ist es in diesem Zusammenhang nichthilfreich uber Veranderungen informiert zu werden, wenn diese selbst er-zeugt wurden. Es ist jedoch hilfreich verschiedene Versionen der Artefaktemiteinander vergleichen zu konnen. Dadurch war es beispielsweise moglichden gesamten Entwicklungsfortschritt nachzuvollziehen.Bei diesen impliziten Tests der Gesamtlosung hat sich herausgestellt, dassgerade der initiale Import eines großen Projekts, wie es die TestumgebungCURE zweifellos darstellt, einen langen Zeitraum in Anspruch nimmt. Laut[CRM91] sind zehn Sekunden die maximale Zeit, welche ein Benutzer ohneRuckmeldung der Applikation zugemutet werden sollte. Jede weitere Ver-zogerung fuhrt dazu, dass der Benutzer unsicher uber den weiteren Verlaufder Applikation wird. Diese Erkenntnis hat dazu gefuhrt Anderungen an derLosung vorzunehmen, so dass ein Import nicht die gesamte Arbeit mit derPlattform blockiert. Der Benutzer wird daruber informiert, dass der Importeinen langen Zeitraum in Anspruch nehmen kann, so kann er wahrenddes-sen problemlos mit der Plattform weiterarbeiten. Der Abschluss des Importswird dann auf der Repository-Seite angezeigt.Wahrend der abschließenden Dokumentationsphase wurde das System dannweiterhin erprobt. Die Dokumentation wurde uber einen CVS-Server ver-waltet und gleichzeitig in CURE importiert. Dies hatte den Vorteil, dassdas System dadurch immer zusatzlich getestet werden konnte.Weiterhin wurde zur Validierung der Ergebnisse die Testumgebung Junit[JUN07] genutzt. Es wurde ein Modultest fur die wichtigsten Klassen der An-wendung geschaffen. Dazu zahlen RepositoryCheckoutThread RepositoryUp-dateThread und CVSRepositoryClient. Die dazugehorigen Testklassen sindRepositoryCheckoutThreadTest, RepositoryUpdateThreadTest und CVSRe-positoryClientTest. Die Funktionalitaten der Repository-Anbindung konnendaher ohne Einbeziehung der Benutzeroberflache getestet werden. Der Mo-dultest ist in dem Paket de.fuh.csclportal.repositoryclient.test zu finden. Die-ses Paket wurde jedoch in der Erlauterung der Softwarearchitektur nichtaufgefuhrt, weil es sich nicht um Klassen der Anwendung handelt.Fur den Testrahmen war es notwendig Erweiterungen in die Klassen Repo-sitoryCheckoutThread und RepositoryUpdateThread einzubringen. Dies war


erforderlich, weil es sich bei diesen Klassen um eigenstandige, zyklischeThreads handelt. Sie stellen nun eine Methode bereit, mit der es moglichist, sich bei den Threadobjekten zu registrieren. Nach der Registrierungmelden sowohl RepositoryUpdateThread als auch RepositoryCheckoutThreaddas Ergebnis einer Aktualisierung bzw. eines Checkouts an das angemeldeteObjekt. Die genannte Erweiterung der Anwendungsklassen wurde lediglichan einer Stelle getatigt, so dass es hier nicht zu einer Beeintrachtigung desnormalen Ablaufes kommt.Die entwickelten Testfalle bieten sich fur Regressionstest an, da sie die wich-tigsten Elemente der Anwendung testen.Leider gab es nach der Fertigstellung der Implementierung keine Evaluati-onsphase, in der die Losung durch andere Benutzer bewertet werden konnte.Dies hatte sicherlich neue Erkenntnisse bei der Benutzbarkeit der Losung ge-bracht.

7.3 Erweiterungspotenzial

An dieser Stelle sollen zum Abschluss noch einige Verbesserungsmoglichkei-ten und Ansatzpunkte fur weitere Arbeiten diskutiert werden. Auch wenninnerhalb der Arbeit alle Anforderungen realisiert wurden, so gibt es den-noch Erweiterungsmoglichkeiten speziell fur die Repository-Anbindung oderfur die Aufwertung von CURE zur Kollaborationsplattform im Softwareent-wicklungsprozess.

7.3.1 Repository-Anbindung

Wie bereits erwahnt, gab es leider nach der Fertigstellung des Prototypenkeine Evaluationsphase, in der andere Benutzer ihre Erfahrungen mit der Lo-sung wiedergeben konnten. Die gesammelten Verbesserungsvorschlage stam-men daher aus kritischen Betrachtungen des Systems wahrend der Testpha-se.

Verweise auf bestimmte Versionen eines Artefakts

In der derzeitigen Losung ist es mit Hilfe der Verweise moglich auf ein be-stimmtes Artefakt zu verweisen. Die Anwendungsgebiete dafur wurden be-reits ausfuhrlich diskutiert. Ein Problem besteht jedoch darin, wenn einArtefakt aktualisiert wird. Dann ist es moglich, dass der Kontext, in demsich der Link befindet, nicht mehr zu der Version des Artefakts passt. Bei-spielsweise ware es denkbar die Funktionsweise eines Algorithmus auf einerWiki-Seite zu beschreiben und dazu einen Verweis auf das Artefakt zu plat-zieren. Sollte sich jedoch der Algorithmus und damit das Artefakt andern,die Wiki-Seite jedoch nicht, fuhrt der Link zu einem Artefakt, auf das die-se Beschreibung nicht mehr passt. Es ware demnach sinnvoll, Verweise auf


bestimmte Versionen zu ermoglichen. Es konnte dadurch mit einfachen Mit-teln sichergestellt werden, dass sich eine Beschreibung immer auf die richtigeVersion eines Artefakts bezieht.Der Aufwand fur die Umsetzung dieses Vorschlags ware gering. Die Versio-nen der Artefakte liegen bereits in der Plattform vor, so dass sich lediglicheine Anderung der Adressierung notwendig ware.

Bereitstellung von bestimmten Versionen eines Projekts zum Down-load

Die Repository-Seite stellt die Moglichkeit bereit das gesamte Projekt alskomprimiertes Archiv herunterzuladen. Dies vereinfacht den Zugriff auf dasRepository sehr, da nun von uberall mit einem Browser auf die Inhalte zu-gegriffen werden kann. Leider ist es derzeit nur moglich den aktuellen Stand,welcher sich gerade in der Plattform befindet, zum Herunterladen anzubie-ten. Es gibt jedoch auch Anwendungsfalle, bei denen eine bestimmte Versioneines Projekts gebraucht wird. Beispielsweise ist es denkbar, dass ein Testereine Version des Projekts benotigt, um bestimmte Testfalle damit nachzu-stellen.Die Realisierung dieses Vorschlags ist mit wenig Aufwand moglich, da dieverschiedenen Vorgangerversionen vorhanden sind. Es muss lediglich eineLogik geschaffen werden, dass der Benutzer Vorgangerversionen auswahlenkann, welche sich innerhalb der Plattform befinden. Danach konnten dieseVersionen zum Herunterladen angeboten werden.

Erweiterung um einen Zugriff auf Subversion-Repositories

Die Losung wurde so realisiert, dass mit moglichst wenig Aufwand der Zu-griff auf andere Repository-Arten realisiert werden kann. Dies hatte denVorteil, dass der Zugriff durch die einheitliche Oberflache der Repository-Anbindung vereinfacht werden wurde und der Benutzer nicht zwischen ver-schiedenen Werkzeugen wechseln musste. Eine denkbare Erweiterung warein diesem Bereich der Zugriff auf Subversion Repositories. Laut [Bud06] hatSubversion inzwischen in der Verbreitung zu CVS aufgeschlossen. Weiterhinbietet Subversion unbestritten einige Vorteile gegenuber dem Versionsmana-gement mit CVS, zu nennen sind hier beispielsweise atomare Checkins undder verbesserte Umgang mit Binardateien.Der Realisierungsaufwand ware jedoch etwas großer, da fur den Zugriff aufdie Subversion-Repositories ein neuer Client implementiert werden musste.Die Integration in die Repository-Anbindung wurde jedoch wenig Zeit inAnspruch nehmen, weil bereits ein Framework fur diesen Zweck existiert.


Import des ganzen Versionsbaums eines Projekts

Die jetzige Implementierung ermoglicht es lediglich die Historie eines be-stimmten Entwicklungszweigs zu importieren. In der Softwareentwicklungwird jedoch haufig so verfahren, dass sich Fehlerkorrektoren auf bestimmteVersionsstande beziehen und deshalb genau von dieser Version eines Arte-fakts verzweigt muss. Erst wenn diese Fehlerkorrektur verifiziert wurde, fließtsie in die anderen Entwicklungszweige ein. Die so entstehenden Versionsbau-me sind derzeit nicht mit der Repository-Anbindung abbildbar. Der Grunddafur liegt in der Nachnutzung der Verwaltung von Versionen innerhalb vonCURE. Als Erweiterungsmoglichkeit ware deshalb auch der komplette Im-port der Versionshistorie denkbar.Die Realisierung dieser Erweiterungsmoglichkeit ware mit großem Aufwandmoglich. Dazu ist eine grundlegende Anderung der Versionsverwaltung in-nerhalb der CURE Plattform notwendig.

Umsetzung von CVS-Benutzern zu CURE-Benutzer

Bei der derzeitigen Realisierung wird nach einer Aktualisierung eines Arte-fakts der ausfuhrende Benutzername innerhalb von CURE lediglich als Textangezeigt. Es ware vorstellbar den dazugehorigen CVS-Benutzer auf einenCURE-Benutzer abzubilden. In der Ansicht konnten dann direkt Verweisezum ausfuhrenden Benutzer dargestellt werden. Diese Losung hatte den Vor-teil, dass man sich bei Fragen zur Aktualisierung auf einfache Weise direktmit dem Benutzer in Verbindung setzen konnte. Weiterhin steigt dadurchdas Gruppenbewusstsein des Teams.Dieser Verbesserungsvorschlag ist relativ einfach zu realisieren. Der Be-nutzer, welcher die Repository-Anbindung anlegt, mußte eine Moglichkeitbekommen die Abbildung von CVS- zu CURE-Benutzern anzulegen. Beieiner Aktualisierung wird diese Abbildung benutzt um den ausfuhrendenCVS-Benutzer auf einen CURE-Benutzer abzubilden. In der Ansicht derAktualisierung wird dann direkt auf den CURE-Benutzer verwiesen.

Generierung von Dokumentationen

Eine weitere interessante Erweiterungsmoglichkeit ware es, dass automatischaus Dokumentationen, welche intrusiv in den Quellcode-Artefakten enthal-ten sind (Bsp. Javadoc-Tag [JAV07c]), Wiki-Seiten innerhalb von CURE er-zeugt werden. Diese zusatzlichen Seiten werden direkt beim Import erzeugt,mit Links zu den Implementierungen erweitert und konnen somit direkt alsDokumentation genutzt werden.Dieser Verbesserungsvorschlag ist mit geringem Aufwand zu realisieren. Esstehen bereits Java-APIs [JAV07c] zur Verfugung, welche vorhandene Ar-tefakte analysieren und HTML Dateien mit der Dokumentation generieren.


Diese Ausgabe kann nun genutzt werden um Wiki-Seiten fur CURE zu er-zeugen.

7.3.2 CURE als Kollaborationsplattform

Durch die Integration der Repository-Anbindung wurde eine grundlegendeEigenschaft von Kollaborationsplattformen geschaffen auf die wichtigstenArtefakte der Softwareentwicklung - die Quelltextdokumente - zuzugreifen.Die Integration ermoglicht somit die Nachvollziehbarkeit einzelner Prozess-schritte sowie Beziehungen zwischen Artefakten. Daruber hinaus bietet CU-RE verschiedene Kommunikations- sowie Koordinationswerkzeuge und einDokumentenmanagementsystem, welche den Entwicklungsprozess unterstut-zen. Andere nutzliche Erweiterungen wie ein Kalender zur Koordination[Kre03] oder ein Werkzeuge zum kollaborativen Browsen [Gro06] sind be-reits integriert. Kommerzielle Kollaborationsplattformen wie CodeBeamerund SourceForge Enterprise Edition bieten jedoch mehr Moglichkeiten.In [BB03] und [Fou01] werden die wichtigsten Elemente einer Kollaborations-plattform fur die Unterstutzung von Softwareentwicklungsprojekten genannt(vgl. Abbildung 7.1). CURE fehlen bisher im Wesentlichen ein Projekt-bzw. Ressourcenmanagementwerkzeug inklusive einer Moglichkeit der Pro-jektauswertung, eine Anbindung an einen Bug-Tracker und einem Work-flowmanagementsystem. Die vollstandige Umsetzung dieser Anforderungenbenotigt naturlich Zeit und ist daher eher langfristig anzusetzen.Zusammenfassend kann jedoch angemerkt werden, dass die Basis fur dieUnterstutzung von Softwareprojekten geschaffen wurde.

Abbildung 7.1: Komponenten einer Kollaborationsplattform (entnommenaus [BB03])

Literaturverzeichnis

[ACT07] Webseite des Apache Projeks ActiveMQ. http://activemq.apache.org/. 2007. – besucht am 19.03.2007

[AJA07] Erlauterung des Begriffs AJAX auf Wikipedia. http://de.wikipedia.org/wiki/Ajax_(Programmierung). 2007. – be-sucht am 21.04.2007

[Alt98] Altmann, Josef: Kooperative Softwareentwicklung: Rechner-unterstutzte Koordination und Kooperation in Softwareprojek-ten, Johannes Kepler Universitat Linz, Diss., 1998

[AP99] Altmann, Josef ; Pomberger, Gustav: Kooperative Soft-wareentwicklung: Konzepte, Modell und Werkzeuge. In: 4.Internationale Tagung Wirtschaftsinformatik (1999)

[ARG07] Webseite des ArgoUML-Projekts. http://argouml.tigris.org/. 2007. – besucht am 26.04.2007

[AW98] Altmann, Josef ; Weinreich, Rainer: An Environment forCooperative Software Development Realization and Implica-tions. In: HICSS ’98: Proceedings of the Thirty-First AnnualHawaii International Conference on System Sciences-Volume1. Washington, DC, USA : IEEE Computer Society, 1998. –ISBN 0–8186–8233–7, S. 27

[Bal98] Balzert, Helmut: Lehrbuch der Software-Technik. SpektrumAkademischer Verlag, 1998

[BB03] Booch, Grady ; Brown, Alan W.: Collaborative Develop-ment Environments. In: Advances in Computers 59 (2003),S. 2–29

[BCG+03] Ballarini, Daniele ; Cadoli, Marco ; Gaetta, Matteo ;Mancini, Toni ; Mecella, Massimo ; Ritrovato, Pierlu-igi ; Santucci, Guiseppe. Modeling Real Requirements forCooperative Software Development: A Case Study. WorkingPaper. 2003

90

http://activemq.apache.org/

http://activemq.apache.org/

http://de.wikipedia.org/wiki/Ajax_(Programmierung)

http://de.wikipedia.org/wiki/Ajax_(Programmierung)

http://argouml.tigris.org/

http://argouml.tigris.org/

LITERATURVERZEICHNIS 91

[BF03] Bar, Moshe ; Fogel, Karl: Open Source Development withCVS. 3rd. Paraglyph Press, Inc., Scottsdale, Arizona, 2003.– ISBN 1–932111–81–6

[BMK95] Bischofberger, Walter R. ; Matzel, Kai-Uwe ; Klein-ferchner, Christian F.: Evolving a Programming Environ-ment Into a Cooperative Software Engineering Environment.In: Proceedings of CONSEG ’95, Tata McGraw-Hill, 1995

[BNL+06] Bajracharya, Sushil ; Ngo, Trung ; Linstead, Erik ; Dou,Yimeng ; Rigor, Paul ; Baldi, Pierre ; Lopes, Cristina:Sourcerer: a search engine for open source code supportingstructure-based search. In: OOPSLA ’06: Companion to the21st ACM SIGPLAN conference on Object-oriented program-ming systems, languages, and applications. New York, NY,USA : ACM Press, 2006. – ISBN 1–59593–491–X, S. 681–682

[BS98] Borghoff, Uwe M. ; Schlichter, Johann H.: Rechnerge-stutzte Gruppenarbeit - Eine Einfuhrung in verteilte Anwen-dungen. 2rd. Springer Verlag, Heidelberg, 1998. – ISBN3540628738

[Bud06] Budszuhn, Frank: Subversion 1.4. 2nd. Galileo Press, 2006.– ISBN 3898428796

[BUG07] Webseite des Bugzilla-Projekts. http://www.bugzilla.org/.2007. – besucht am 26.04.2007

[CC03] Cook, C. ; Churcher, N.: An extensible framework for col-laborative software engineering. In: APSEC 2003: Proceedingsof the 10th Asia-Pacific Software Engineering Conference, IE-EE Press, 2003, S. 290–299.

[CER07] Cervisia Webseite. http://cervisia.kde.org/. 2007. – be-sucht am 20.04.2007

[CHRP03] Cheng, Li-Te ; Hupfer, Susanne ; Ross, Steven ; Patter-son, John: Jazzing up Eclipse with collaborative tools. In:eclipse ’03: Proceedings of the 2003 OOPSLA workshop oneclipse technology eXchange. New York, NY, USA : ACMPress, 2003, S. 45–49

[CKI98] Curtis, Bill ; Krasner, Herb ; Iscoe, Neil: A field study ofthe software design process for large systems. In: Commun.ACM 31 (1998), Nr. 11, S. 1268–1287. – ISSN 0001–0782

[COD07a] Intland CodeBeamer Webseite. http://www.intland.com/products/codebeamer.html. 2007. – besucht am 12.03.2007

http://www.bugzilla.org/

http://cervisia.kde.org/

http://www.intland.com/products/codebeamer.html

http://www.intland.com/products/codebeamer.html


[COD07b] CodeBeamer Connector Webseite. http://cbconnector.javaforge.com/. 2007. – besucht am 20.04.2007

[COL07] CollabNet Enterprise Webseite. http://www.collab.net/products/. 2007. – besucht am 12.03.2007

[CRM91] Card, Stuart K. ; Robertson, George G. ; Mackin-lay, Jock D.: The information visualizer, an informationworkspace. In: CHI ’91: Proceedings of the SIGCHI confe-rence on Human factors in computing systems. New York,NY, USA : ACM Press, 1991. – ISBN 0–89791–383–3, S. 181–186

[CS01] Churchill, Elizabeth F. ; Snowdon, David N.: CollaborativeVirtual Environments Digital Places and Spaces for Interacti-on. Springer Verlag Berlin, 2001. – ISBN 1–85233–244–1

[CUR] CVS-Repository von CURE. max.fernuni-hagen.de

[DB92] Dourish, P. ; Belotti, V: Awareness and Coordinationin Shared Workspaces.In: Proceedings of CSCW’92 - SharingPerspectives. ACM Press, Toronto, Canada, 1992. – 107–114S

[DMO07] Concurrent Versions System: Clients. http://dmoz.org/Computers/Software/Configuration_Management/Tools/Concurrent_Versions_System/Clients/. 2007. – besuchtam 10.02.2007

[Dos01] Dossick, Stephen E.: A Virtual Environment Frameworkfor Software Engineering, Columbia University Departmentof Computer Science, Diss., November 2001. – PhD Thesis

[DRE07] Webseite des DRES-Projekts. http://sourceforge.net/projects/dres. 2007. – besucht am 26.04.2007

[Dud06] Dudenredaktion: DUDEN - Deutsches Universalworter-buch (DUW). 6th. Mannheim : Bibliographisches Institut,2006

[ECL07] Webseite der Entwicklungsumgebung Eclipse. http://www.eclipse.org/. 2007. – besucht am 21.04.2007

[EGH05] Ebersbach, Anja ; Glaser, Markus ; Heigl, Richard: Wi-kiTools. Springer, Berlin, 2005. – ISBN 3540229396

[FB05] Feinberg, S. ; Batson, L.: Managing collaboration: addingcommunication and documentation environment (CDE) to a

http://cbconnector.javaforge.com/

http://cbconnector.javaforge.com/

http://www.collab.net/products/

http://www.collab.net/products/

http://dmoz.org/Computers/Software/Configuration_Management/Tools/Concurrent_Versions_System/Clients/



http://sourceforge.net/projects/dres

http://sourceforge.net/projects/dres

http://www.eclipse.org/

http://www.eclipse.org/


product development cycle. In: Professional CommunicationConference, IPCC 2005. Proceedings, International Volume,2005, S. 752–758

[Fis07] Fish, Shlomi: Version Control System Comparison. http://better-scm.berlios.de/comparison/comparison.html.2007. – besucht am 03.03.2007

[Fou01] Fournier, Roger: Teamwork is the key to remo-te development. http://www.itworld.com/Career/3651/IW010305tcdistdev/pfindex.html. 2001. – besucht am24.03.2007

[GFO07a] Gforge Enterprise Webseite. http://gforgegroup.com/products/. 2007. – besucht am 12.03.2007

[GFO07b] Gforge Webseite. http://gforge.org/. 2007. – besucht am12.03.2007

[GHKR06] Geisser, Michael ; Hildenbrand, Tobias ; Klimp-ke, Lars ; Rashid, Asarnusch: Werkzeuge zur kol-laborativen Softwareerstellung - Stand der Technik.http://wifo1.bwl.uni-mannheim.de/fileadmin/files/publications/CollaBaWue-KSE-Arbeitsbericht-Stand_der_Technik-Werkzeuge.pdf. 2006. – besucht am 12.03.2007

[GP02] Gaeta, M. ; Pierluigi, R.: Generalised Environment for Pro-cess Management in Cooperative Software Engineering. In:Proceedings of the 26th Annual International Computer Soft-ware and Applications Conference COMPSAC 2002, 2002, S.1049–1053

[GR98] Greenberg, S. ; Roseman, M. Using a Room Metaphor toEase Transitions in Groupware. 1998

[Gro06] Gross, Alexander M.: Kooperative Web-Recherche in CURE,Fernuniversitat Hagen, Diplomarbeit, 2006

[GT04] Geiger, Rolf ; Tuttenuj, Thomas: Ophelia - Integrationvon Entwicklungs-Tools in verteilten Umgebungen. In: JavaMagazin 10.2004 (2004)

[Haa07] Haake, Anja: CURE: Das CSCL-Portal der FernUniver-sitat in Hagen - Benutzungshandbuch. http://www.pi6.fernuni-hagen.de/DocCURE/manual.html. 2007. – besuchtam 18.02.2007

http://better-scm.berlios.de/comparison/comparison.html

http://better-scm.berlios.de/comparison/comparison.html

http://www.itworld.com/Career/3651/IW010305tcdistdev/pfindex.html

http://www.itworld.com/Career/3651/IW010305tcdistdev/pfindex.html

http://gforgegroup.com/products/

http://gforgegroup.com/products/

http://gforge.org/

http://wifo1.bwl.uni-mannheim.de/fileadmin/files/publications/CollaBaWue-KSE-Arbeitsbericht-Stand_der_Technik-Werkzeuge.pdf



http://www.pi6.fernuni-hagen.de/DocCURE/manual.html

http://www.pi6.fernuni-hagen.de/DocCURE/manual.html


[HCRP04] Hupfer, Susanne ; Cheng, Li-Te ; Ross, Steven ; Pat-terson, John: Introducing collaboration into an applicati-on development environment. In: CSCW ’04: Proceedings ofthe 2004 ACM conference on Computer supported cooperati-ve work. New York, NY, USA : ACM Press, 2004. – ISBN1–58113–810–5, S. 21–24

[HF94] Hesse, Wolfgang ; Frese, Michael: Zur Arbeitssituation inder Software-Entwicklung. In: Inform., Forsch. Entwickl. 9(1994), Nr. 4, S. 179–191

[HGK07] Hildenbrand, Tobias ; Geisser, Michael ; Klimp-ke, Lars: Konzeption und Implementierung ei-nes Werkzeugs fur nutzenbasiertes Traceability- undRationale-Management in verteilten Entwicklungsumge-bungen. http://www.collabawue.de/cms/dokumente/HiGK2007-Arbeitspapier-5-2007-TraVis.pdf. 2007. –besucht am 15.03.2007

[HRH06] Hildenbrand, Tobias ; Rothlauf, Franz ; Heinzl,Armin: Ansatze zur kollaborativen Softwareerstel-lung. http://www.collabawue.de/cms/dokumente/Arbeitspapier-2006-06-Kollaboration-HiRH06.pdf.2006. – besucht am 23.02.2007

[HSB+04] Haake, Jorg M. ; Schummer, Till ; Bourimi, Mohamed ;Landgraf, Britta ; Haake, Anja: CURE – Eine Umgebungfur selbstorganisiertes Gruppenlernen. Bd. 3. Oldenbourgh,2004. – 20–26 S. ISSN 1618–162X

[HSQ07] Webseite der Datenbank hsqldb. http://hsqldb.org/. 2007.– besucht am 21.04.2007

[J2E07] Jave Platform, Enterprise Edition Webseite. http://java.sun.com/javaee/technologies/javaee5.jsp). 2007. – be-sucht am 24.04.2007

[JAM07] Webseite des Apache Projeks James. http://james.apache.org/. 2007. – besucht am 19.03.2007

[JAV07a] Webseite der Programmiersprache Java. http://java.sun.com/. 2007. – besucht am 21.04.2007

[JAV07b] Netbeans javacvs Bibliothek Webseite. http://javacvs.netbeans.org/. 2007. – besucht am 12.03.2007

[JAV07c] Javadoc Webseite. http://java.sun.com/j2se/javadoc/.2007. – besucht am 21.04.2007

http://www.collabawue.de/cms/dokumente/HiGK2007-Arbeitspapier-5-2007-TraVis.pdf

http://www.collabawue.de/cms/dokumente/HiGK2007-Arbeitspapier-5-2007-TraVis.pdf

http://www.collabawue.de/cms/dokumente/Arbeitspapier-2006-06-Kollaboration-HiRH06.pdf

http://www.collabawue.de/cms/dokumente/Arbeitspapier-2006-06-Kollaboration-HiRH06.pdf

http://hsqldb.org/

http://java.sun.com/javaee/technologies/javaee5.jsp)

http://java.sun.com/javaee/technologies/javaee5.jsp)

http://james.apache.org/

http://james.apache.org/

http://java.sun.com/

http://java.sun.com/

http://javacvs.netbeans.org/

http://javacvs.netbeans.org/

http://java.sun.com/j2se/javadoc/


[JAV07d] JavaForge Webseite. http://www.javaforge.com. 2007. –besucht am 12.03.2007

[JCV07] jCVS Webseite. http://www.jcvs.org/. 2007. – besucht am20.04.2007

[JLJL94] Johnson-Lenz, Peter ; Johnson-Lenz, Trudy: Groupware:Coining and Defining It / Awakening Technology. 1994. –Forschungsbericht

[JSC07] Webseite des Projekts JSch. http://www.jcraft.com/jsch/index.html. 2007. – besucht am 18.03.2007

[JUN07] Webseite des JUnit-Projekts. http://www.junit.org/index.html. 2007. – besucht am 24.04.2007

[Kai04] Kai, Sunghun K.: WebDAV based Open Source CollaborativeDevelopment Environment. 2004. – besucht am 25.02.2007

[Kar99] Karolak, Dale W.: Global Software Development: ManagingVirtual Teams and Environments. Los Alamitos, CA, USA :IEEE Computer Society Press, 1999. – ISBN 0818687010

[KL05] Koppany, Janos ; Lehnert, Michael: Erfolgreicher Ein-satz des Open-Source-Modells in der unternehmensweitenSoftwareentwicklung. http://www.sigs.de/publications/os/2005/03/koppany_OS_03_05.pdf. 2005. – besucht am12.03.2007

[KP05] Koch, Michael ; Prinz, Wolfgang: Communities undCommunity-Unterstutzung. In: i-com Zeitschrift fur interak-tive und kooperative Medien (2005)

[Kre03] Kreuer, Thorben K.: Terminfindung fur synchrone Grup-penubungen, Fernuniversitat Hagen, Bachelorarbeit, 2003

[MAP07] Webseite des Projekts MAPPER. mapper.troux.com/. 2007.– besucht am 21.04.2007

[MD00] Maurer, Frank ; Dellen, Barbara: A Concept foran Internet-based Process-Oriented Knowledge ManagementEnvironment. http://ksi.cpsc.ucalgary.ca/KAW/KAW98/maurer/. 2000. – besucht am 04.03.2007

[MM97] Murphy, Paul ; Miller, James: A Process for Asynchro-nous Software Inspection. In: STEP ’97: Proceedings of the

http://www.javaforge.com

http://www.jcvs.org/

http://www.jcraft.com/jsch/index.html

http://www.jcraft.com/jsch/index.html

http://www.junit.org/index.html

http://www.junit.org/index.html

http://www.sigs.de/publications/os/2005/03/koppany_OS_03_05.pdf

http://www.sigs.de/publications/os/2005/03/koppany_OS_03_05.pdf

mapper.troux.com/

http://ksi.cpsc.ucalgary.ca/KAW/KAW98/maurer/

http://ksi.cpsc.ucalgary.ca/KAW/KAW98/maurer/


8th International Workshop on Software Technology and En-gineering Practice (STEP ’97) (including CASE ’97). Wa-shington, DC, USA : IEEE Computer Society, 1997. – ISBN0–8186–7840–2, S. 96

[MSP07] Microsoft Office Online Webseite. http://office.microsoft.com/project. 2007. – besucht am 26.04.2007

[MYS07] Webseite des MySQL Projekts. http://www.mysql.de/. 2007.– besucht am 21.04.2007

[OPE07] Webseite des OpenOffice.org Projekts. http://de.openoffice.org/. 2007. – besucht am 26.04.2007

[ORA07] Oracle-Datenbanken Webseite. http://www.oracle.com/lang/de/database/index.html. 2007. – besucht am21.04.2007

[PG95] Pickering, Jeanne M. ; Grinter, Rebecca E.: Software En-gineering and CSCW: A Common Research Ground. London,UK : Springer-Verlag, 1995. – 241–250 S. – ISBN 3–540–59008–0

[Piw02] Piwetz, Christian: Anforderungsbeschreibung fur Groupware-Systeme: ein sichtenorientierter Ansatz. Logos Verlag Berlin,2002. – ISBN 3897229587

[POS07] Webseite der Datenbank PostgreSQL. http://www.postgres.de/. 2007. – besucht am 21.04.2007

[PWBW+98] Pfister, Hans-Rudiger ; Wessner, Martin ; Beck-Wilson,Jennifer ; Miao, Yongwu ; Steinmetz, Ralf: Rooms, proto-cols, and nets: Metaphors for computer supported cooperativelearning of distributed groups. In: Bruckman, Amy S. (Hrsg.); Guzdial, Mark (Hrsg.) ; Kolodner, Janet L. (Hrsg.) ;Ram, Ashwin (Hrsg.): Proceedings of ICLS 98, InternationalConference of the Learning. Charlottesville, VA : Associati-on for the Advancement of Computing in Education (AACE),December 16-19 1998, S. pp. 242–248

[Ree78] Reenskaug, Trygve: MVC XEROX PARC 1978-79. http://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html.1978. – besucht am 21.04.2007

[Sap00] Sapsomboon, Bordin: Shared Defect Detection : The Effectsof Annotations in Asynchronous Software Inspection, Schoolof Information Sciences - University of Pittsburgh, Diss., June2000. – PhD Thesis

http://office.microsoft.com/project

http://office.microsoft.com/project

http://www.mysql.de/

http://de.openoffice.org/

http://de.openoffice.org/

http://www.oracle.com/lang/de/database/index.html

http://www.oracle.com/lang/de/database/index.html

http://www.postgres.de/

http://www.postgres.de/

http://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html

http://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html


[SAV07] Gnu Savannah Webseite. http://savannah.gnu.org/. 2007.– besucht am 12.03.2007

[Sch99] Schummer, Till: TUKAN - Entwicklung einer kooperati-ven Software-Konfigurations-Umgebung, Technische Universi-tat Darmstadt, Diplomarbeit, 1999

[Sch05] Schwitzgebel, Matthias: Realisierung unterschiedlicherAwareness-Formen eines Community-Kooperationsportals,Fernuniversitat Hagen, Masterarbeit, 2005

[SDI07] Erlauterung des Begriffs SDI auf Wikipedia. http://de.wikipedia.org/wiki/Single_Document_Interface. 2007. –besucht am 21.04.2007

[SLVA97] Singer, Janice ; Lethbridge, Timothy ; Vinson, Norman ;Anquetil, Nicolas: An examination of software engineeringwork practices. In: CASCON ’97: Proceedings of the 1997conference of the Centre for Advanced Studies on Collaborativeresearch, IBM Press, 1997, S. 21

[Som04] Sommerville, Ian: Software Engineering. 7th. Harlow, UK: Addison-Wesley, 2004 (International Computer Sciences Se-ries)

[SOU07a] VA Software Sourceforge Webseite. http://www.vasoftware.com/sourceforge/index.php. 2007. – be-sucht am 12.03.2007

[SOU07b] Sourceforge Webseite. http://www.sourceforge.net. 2007.– besucht am 12.03.2007

[SSU01] Schwabe, Gerd (Hrsg.) ; Streitz, Norbert (Hrsg.) ; Un-land, Rainer (Hrsg.): CSCW–Kompendium. Lehr- und Hand-buch zum computerunterstutzten kooperativen Arbeiten. Berlinu. a. : Springer, 2001

[SUS07] Webseite der Betriebssystem SuSE Linux. http://www.novell.com/de-de/linux/. 2007. – besucht am 21.04.2007

[TOM07] Webseite des Apache Projekts Tomcat. http://tomcat.apache.org/. 2007. – besucht am 21.04.2007

[TOR07] TortoiseCVS Webseite. http://www.tortoisecvs.org/index.shtml. 2007. – besucht am 12.03.2007

[TSB95] Teufel, S. ; Sauter, C. ; Bauknecht, B.: Computerunter-stutzung fur die Gruppenarbeit. Addison-Wesley, 1995

http://savannah.gnu.org/

http://de.wikipedia.org/wiki/Single_Document_Interface

http://de.wikipedia.org/wiki/Single_Document_Interface

http://www.vasoftware.com/sourceforge/index.php

http://www.vasoftware.com/sourceforge/index.php

http://www.sourceforge.net

http://www.novell.com/de-de/linux/

http://www.novell.com/de-de/linux/

http://tomcat.apache.org/

http://tomcat.apache.org/

http://www.tortoisecvs.org/index.shtml

http://www.tortoisecvs.org/index.shtml


[Ver02] Versteegen, Gerhard: Software–Management. Beherr-schung des Lifecycles.. Bd. 1. Berlin, Deutschland : SpringerVerlag, 2002. – ISBN 3540425772

[VIE07] ViewVC Webseite. http://www.viewvc.org/. 2007. – be-sucht am 12.03.2007

[WIK07] Wikipedia Webseite. http://en.wikipedia.org/wiki/Wikipedia. 2007. – besucht am 18.04.2007

[WIN07] WinCvs Webseite. http://www.wincvs.org/. 2007. – be-sucht am 20.04.2007

[WRS+03] Wilcox, Pauline ; Russell, Craig ; Smith, Mike ; Smith,Alan ; Pooley, Rob ; MacKinnon, Lachlan ; Dewar, Rick; Weiss, Dawid: A CORBA-Oriented Approach To Heteroge-neous Tool Integration; OPHELIA. In: ESEC/FSE Work-shop on Tool-Integration in System Development, Helsinki,Finland, 2003, S. 1–5

[Wu03] Wu, James: Tools for Collaborative Software De-sign. http://www.cs.queensu.ca/TechReports/Reports/2003-462.pdf. 2003. – besucht am 04.03.2007

[ZR06] Zullinghoven, H. ; Raasch, J.: Softwaretechnik. In: Re-chenberg, P. (Hrsg.) ; Pomberger, G. (Hrsg.): Informatik-Handbuch, Hanser Verlag, 2006, S. 795–835

http://www.viewvc.org/

http://en.wikipedia.org/wiki/Wikipedia

http://en.wikipedia.org/wiki/Wikipedia

http://www.wincvs.org/

http://www.cs.queensu.ca/TechReports/Reports/2003-462.pdf

http://www.cs.queensu.ca/TechReports/Reports/2003-462.pdf

Documents

Repository-Integration fur die¨ Kooperationsplattform CURE · 2013. 7. 17. · Fernuniversit¨at in Hagen Universit¨atsstr. 1 58084 Hagen Repository-Integration fur die¨ Kooperationsplattform