Verwaltung und Archivierung mit CVS CVS Einbettung in SNiFF+ Team Software Process

Transkript

1 Verwaltung und Archivierung mit CVS CVS Einbettung in SNiFF+ Team Software Process Seminar PGJEVOX Abgehalten im Freizeitheim Horn Mai 1999 Ausarbeitung von Peter Sklinski Einführung In dieser Ausarbeitung wird dem Leser nahegebracht, was CVS ist und wie er mit CVS umzugehen hat. Es wird anhand eines Beispieles gezeigt, wie CVS mit Versionsunterschieden im REPOSITORY uns auf dem Arbeitsplatz umgeht und die Probleme beseitigt. Desweiteren wird am Beispiel gezeigt, wie CVS in SNiFF+ einbetten wird, damit der Benutzer eine bessere Arbeitsoberfläche bei der Versionsverwaltung zur Verfügung hat. Team Software Proces, das dritte behandelnde Thema, wird eingesetzt um den Ablauf großer Projekte zu managen. Zu Team Software Process werden die einzelnen Phasen erklärt und anhand eines Diagrammes dargelegt. Abschließend wird gezeigt, in CVS und Team Software Process an der Universität Paderborn eingesetzt wird. Inhaltsverzeichnis Einführung 1 I Verwaltung und Archivierung mit CVS 2 I.1 Allgemeines 2 I.1.1 Was ist Versionsverwaltung? 2 I.1.2 Die Idee des CVS 3 I.2 CVS initialisieren und Projekt anlegen 3 I.2.1 REPOSITORY anlegen 3 I.2.2 Projekt anlegen 4 I.3 Projekt bearbeiten 4 I.3.1 Arbeitskopie aus dem REPOSITORY holen 4 I.3.2 Änderungen ins REPOSITORY übernehmen 5 1

2 I.3.3 Löschen von nicht mehr benötigten Dateien aus dem REPOSITORY 6 I.4 Zugriff und Arbeiten mit früheren Versionen 7 I.5 Ändern einer Datei von zwei Programmierern 7 I.6 Anhang zu CVS 10 I.6.1 Wichtigen Befehle auf einen Blick 10 I.6.2 Abkürzungen bei CVS Meldungen 10 II CVS Integration in SNiFF + 11 II.1 Allgemeines 11 II.2 Notwendigen Einstellungen für die Einbettung von CVS in SNiFF+ 11 II.2.1 Einstellungen am CVS 11 II.2.2 Einstellungen am SNiFF+ 12 II.3 Projekt unter CVS Verwaltung stellen 12 II.4 Neue Version aus REPOSITORY auschecken, modifizieren,updaten und commiten 13 III Team Software Process 14 III.1 Was ist und wo wird Team Software Process angewendet 14 III.2 Struktur von Team Software Process 14 III.3 Beschreibung der einzelnen Phasen im TSP Diagramm 14 III.3.1 Planning 14 III.3.2 Main Design 15 III.3.3 Size and Time Estimation 15 III.3.4 Gantt-Chart 15 III.3.5 Design 16 III.3.6 Design-Inspection 16 III.3.7 Implementation 16 III.3.8 Implementation-Inspection 16 III.3.9 Build-In-Test 17 III.3.10 Build 17 III.3.11 End-Test 17 III.4 Wo ist dieses in das CVS der Universität Paderborn eingebunden? 17 IV Zusammenfassung 18 V Literatur 18 I Verwaltung und Archivierung mit CVS I.1 Allgemeines I.1.1 Was ist Versionsverwaltung? Das Concurrent Versions System (CVS) dient zur Archivierung und Versionsverwaltung von mehrstufiger Dateiverzeichnisse, wie sie üblicherweise in größeren Software- oder Konfigurationsprojekten entstehen. 2

3 Es bietet dabei die Möglichkeit jeden Entwicklungsschritt zurückzuverfolgen und auf jede gesicherte Version jeder zu dem Projekt gehörigen Datei zurückzugreifen. Dabei wird die Entwicklung im Team unterstützt und es ist mehreren Mitarbeitern eines Projekts möglich, gleichzeitig die gleichen Dateien zu bearbeiten. I.1.2 Die Idee des CVS Die Grundidee bei CVS ist, daß es ein zentrales REPOSITORY gibt, in dem der gesamte Dateibaum verschiedener Projekte mit den dazugehörigen Verzeichnissen, Dateien und deren Versionen abgelegt ist. Jeder Programmierer erzeugt mit Hilfe von CVS eine private Arbeitskopie des REPOSITORY, aus welchem alle Dateien des dazugehörigen Projektes in seinen privaten Ordner herauskopiert werden. Auf diese Weise wird das Problem verhindert, daß mehrere Programmierer auf einer Datei arbeiten wollen. In seiner privaten Kopie kann der Programmierer die Dateien nun beliebig ändern, sowie neue Dateien und Verzeichnisse erzeugen oder auch veraltete Dateien und Verzeichnisse entfernen. Nachdem die Änderungen vorgenommen worden sind, müssen diese zunächst mit der Version im REPOSITORY abgeglichen werden. Allerdings nur, wenn in der Zwischenzeit von einem anderem Programmierer Änderungen vorgenommen worden sind und diese mittels seines Zufügens überschrieben werden. Anschließend, nachdem die Konflikte mit den Änderungen anderer Programmierer aufgelöst worden sind, können diese in das REPOSITORY eintragen werden. Nach dem einfügen der neusten Version werden über CVS Benachrichtigungsmails an alle beteiligten Mitarbeiter des Projektes verschickt. In diesen steht, welche Änderungen vorgenommen worden sind, um alle auf dem aktuellstem Stand zu halten. Eine zufällig ausgesuchte Person aus dem Team bekommt zusätzlich eine Inspection Mail, in welcher die Änderungen stehen und nach Fehlern abgesucht werden sollen. Diese korrigierte Mail wird an den Programmierer zurückgeschickt, von Ihm berichtigt und die berichtigte Datei erneut eingecheckt. Erneut werden die Mails verschickt. I.2 CVS initialisieren und Projekt anlegen I.2.1 REPOSITORY anlegen Bevor ein Projekt verwaltet werden kann, muß zunächst das REPOSITORY angelegt werden. Dies geschieht durch das festlegen des Pfades, wo sich das REPOSITORY befindet. Es wird mit dem folgendem Befehl festgelegt: setenv CVSROOT [pfad vom REPOSITORY] Diese Einstellungen sollten in den Systemdateien.cshrc eingetragen werden. Abschließend wird in das REPOSITORY Verzeichnis gewechselt und mit dem Befehl cvs init initialisiert. Dadurch legt das CVS ein CVSROOT Unterverzeichnis im REPOSITORY an, in welchem es die Systemdateien verwaltet. Diese sollten unberührt bleiben, um Fehler vorzubeugen. Nun ist das REPOSITORY initialisiert und dessen Pfad festgelegt. 3

4 I.2.2 Projekt anlegen Wenn ein Projekt unter die Verwaltung von CVS gestellt werden soll, sollte als erstes eine geeignete Verzeichnisstruktur im Projekt vorhanden sein. Es ist zwar möglich aber aufwendig, im Nachhinein Dateien und Verzeichnisse umzubenennen oder zu verschieben. Es gibt zwei Möglichkeiten ein Projekt anzulegen. a) Verzeichnisstruktur mit vorhandenen Dateien anlegen Ist bereits ein Verzeichnisbaum mit allen zugehörigen Dateien vorhanden, welches unter die Verwaltung von CVS gestellt werden soll, so genügt es, in das Hauptverzeichnis des Projekts zu wechseln und den Befehl cvs import [projectname] [person] [date] einzugeben. Dabei steht projektname für den Namen, den das Projekt trägt. Dieser muß nicht gleich sein mit dem im privatem Ordner ist aber empfehlenswert. Bei späteren Arbeiten an dem Projekt wird der Projektname als Hauptverzeichnis gewählt. Person trägt den Namen des Programmierers, der dieses Projekt angelegt hat, und date das Datum des Anlegens. Anschließend überträgt das CVS den kompletten Strukturbaum samt allen darin befindlichen Dateien ins REPOSITORY. b) Nur Verzeichnisstruktur anlegen, die Dateien später einfügen Falls die Dateien erst nachträglich eingefügt werden sollen, falls sie z.b. noch nicht programmiert worden sind, wird zuerst der Verzeichnisbaum des Projektes angelegt und eingefügt und später die erforderlichen Dateien abgelegt. Auf das Einfügen der Dateien wird später genauer eingegangen (I.3.2 Änderungen ins REPOSITORY übernehmen). Es wird ein Verzeichnisbaum für das Projekt erstellt, welcher wie folgt angelegt werden könnte: mkdir project mkdir project/gui mkdir project/pannels... Anschließend wird ins Hauptverzeichnis gewechselt, also project, und der Verzeichnisbaum mit cvs import [projectname] [person] [date] ins REPOSITORY übertragen. Nun kann jeder Programmierer seine Dateien in die entsprechenden Verzeichnisse einfügen (siehe I.3.2 Änderungen ins REPOSITORY hinzufügen (b)). I.3 Projekt bearbeiten I.3.1 Arbeitskopie aus dem REPOSITORY holen 4

5 Um mit einem Projekt arbeiten zu können, muß der Programmierer CVS anweisen, ihm eine Arbeitskopie des Projektes zur Verfügung zu stellen. Der Programmierer führt dazu aus seinem lokalem Verzeichnis die folgende Anweisung aus: cvs checkout [project] Mit diesem Befehl, wird ins aktuelle lokale Verzeichnis der komplette Verzeichnisbaum des Ordners project mit samt allen darin enthaltenen Dateien aus dem REPOSITORY kopiert. Nun kann der Programmierer auf seiner lokalen Arbeitskopie die Dateien ändern, löschen, oder hinzufügen. Dies hat den Vorteil, daß andere Programmiere sich ebenfalls eine Kopie ins lokale Verzeichnis ziehen können, und somit mehrere an der gleichen Datei arbeiten können ohne sich gegenseitig zu stören. Nachdem der einzelne Programmierer seine Änderungen vorgenommen hat, werden diese wieder ins REPOSITORY eingefügt. Das Einfügen ins REPOSITORY wird später behandelt (siehe I.3.2 Änderungen ins REPOSITORY hinzufügen). Dies tritt in den seltenen Fällen auf. In den meisten Fällen muß sich der Programmiere um das Mischen der Änderungen keine Gedanken machen, denn CVS übernimmt dieses Problem für ihn Das Problem, welches hier entstehen kann, und worauf beim Einfügen geachtet werden muß ist, daß mehrere Benutzer an der gleichen Stelle etwas geändert haben. Nur in dieser Situation muß der Programmiere selbst Hand anlegen um dieses Problem zu lösen (siehe I.5 Ändern einer Datei von zwei Programmierern). I.3.2 Änderungen ins REPOSITORY übernehmen a) Geänderte Datei ins REPOSITORY übernehmen Hat der Programmierer Änderungen an einer Datei vorgenommen, die er zuvor aus dem REPOSITORY ausgecheckt hat, muß die aktuelle Version wieder ins REPOSITORY hinzufügen werden, damit alle Mitprogrammierer die aktuellste Version zur Verfügung haben. Bevor der Programmiere die geänderte Datei einfügt, wird mit cvs update d -d mit alle Unterverzeichnissen sein Arbeitsplatz mit dem REPOSITORY abgeglichen, um nicht in der Zwischenzeit von anderen Teammitgliedern vorgenommenen Änderungen an Ihren eingecheckte Dateien unwirksam zu machen. Die Datei muß dann getestet werden, ob sie noch kompilierbar und ausführbar ist, damit die anderen mit dieser noch weiter Arbeiten können. Nach dem erfolgreichem kompilieren, geht der Programmierer in das lokale Verzeichnis, in dem sich die Datei befindet und fügt diese mit dem folgendem Befehl ein: cvs commit m Neue Variable hinzugefügt t 0:30,C [name] -m Kommentar 5

6 -t gebrauchte Zeit in std:min für die Änderungen und Flag, z.b. C für Coding name Dateiname, welche hinzugefügt werden soll Falls name weggelassen wird, werden alle Dateien die zum Projekt gehören aus dem privatem Arbeitsplatz ins REPOSITORY übernommen. Jetzt sind die Änderungen in das REPOSITORY zurückgeschrieben und die Version der geänderten Datei um eins erhöht. b) Neu erstellte Datei hinzufügen, die noch nicht zum Projekt gehört Eine neu geschriebene Datei, die ebenfalls zum Projekt gehören soll, wird nicht durch den commit Befehl automatisch mit ins REPOSITORY übernommen. Als erstes muß dem CVS mitgeteilt werden, daß diese Datei ab jetzt auch zum Projekt dazugehört. Dieses geschieht durch die Anweisung: cvs add [name] Jetzt weiß CVS, daß die Datei name beim nächstem einfügen ins REPOSITORY dazugehört und ihre Änderungen werden aktualisiert. Die Versionsnummer wird erhöht. Das entgültige übernehmen der Änderungen geschieht wieder mit cvs commit m Datei neu hinzugefügt t 2:30,C [name] I.3.3 Löschen von nicht mehr benötigten Dateien aus dem REPOSITORY Ist eine Datei im Projekt überflüssig geworden, sollte sie gelöscht werden. Die Vorgehensweise ist, daß sie als erstes physikalisch aus dem lokalem Arbeitsverzeichnis gelöscht werden, und anschließend dem CVS mitteilt, daß diese Datei nicht mehr zum Projekt gehört. Anschließend wird sie mit dem commit Befehl aus dem REPOSITORY gelöscht. Als Beispiel sei hier angenommen, daß die Datei Tobject.java aus dem Verzeichnisbaum im Ordner project/tmaterials gelöscht werden soll. Der Programmierer wechselt auf seinem lokalem Arbeitsverzeichnis in den Ordner project/tmaterials mit cd project/tmaterial und löscht die Datei Tobject.java heraus. Z.B. mit rm Tobject.java Nun muß noch CVS mitgeteilt werden, daß die Änderungen dieser Datei nicht mehr berücksichtigt werden sollen. Dies geschieht mit cvs remove Tobject.java Abschließend wird mit dem commit Befehl die Datei aus dem REPOSITORY entfernt. cvs commit m Tobject aus dem Project entfernt t 0:10,C Tobject.java 6

7 I.4 Zugriff und Arbeiten mit früheren Versionen In einigen Fällen ist es sinnvoll, eine frühere Version einer Datei zu verwenden, z.b. wenn sie stabiler ist. In so einem Fall wird die aktuelle Version durch die Vorherige ersetzt. Durch den commit-befehl wird für eine veränderte Datei jedesmal ihre Versionsnummer erhöht, so daß für diese im Lauf der Zeit eine Kette von Versionen von CVS mitgeführt wird. Desweiteren wird folgender Verlauf unserer Datei angenohmen: Nach einem normalen update-befehl wird uns immer die aktuellste Version, also 1.4, von CVS zur Verfügung gestellt. Wird nun die 1.2 Version benötigt, da sich z.b. ein Fehler eingeschlichen hat, so können mittels cvs update j 1.4 j 1.2 [name] die Unterschiede zwischen 1.4 und 1.2 wieder aus der aktuellen Version entfernt werden. CVS paßt also die aktuelle Version an Version 1.2 an und legt diese auf dem privatem Arbeitsplatz ab. Nun kann es passieren, daß die falschen Versionen abgeglichen wurde. Dies ist ebenfalls kein Problem für CVS, denn mit cvs update j 1.2 j 1.4 [name] kann die Version 1.4 wieder als die aktuelle wiederhergestellt werden. Gehen wir wieder von der Ausgangssituation der Versionen aus. Nun kann es sein, daß sich der Fehler zwischen den Versionen 1.2 und 1.3 eingeschlichen hat. Hier besteht ebenfalls die Möglichkeit die Änderungen dieser Versionen rückgängig zu machen. cvs update j 1.3 j 1.2 [name] Version 1.4 wird dann entsprechend aktualisiert. Neben der bloßen Angabe der Versionsnummer ist es auch möglich, den Zeitpunkt der Änderung anzugeben, z.b. weil der Versionsverlauf nicht bekannt ist. Angenommen, die letzte Änderung wurde am nach 11:00 Uhr vorgenommen. Falls hier der Fehler vermutet wird, so wird mit cvs update D :00:00 [name] die vorletzte Version ausgecheckt. I.5 Ändern einer Datei von zwei Programmierern Das wesentlich interessante an CVS ist dessen Verhalten bei Konfliktsituationen. Im Verlaufe dieses Kapitels, wird darauf eingegangen, welche Konflikte es gibt, und wie CVS mit ihnen umgeht. Angenommen zwei Programmierer bearbeiten die Datei Tobject.java und wollen diese ins REPOSITORY einchecken. Welcher zuerst eincheckt, ist für CVS nicht von Bedeutung. Sei prog1 der erste Programmierer, welcher die Datei eincheckt und prog2 der zweite. 7

8 Prog1 checkt ohne Konflikte ein, da er als erster eincheckt. Für prog2 ergeben sich nach cvs update nun zwei Varianten, wie sich CVS verhält. In beiden Fällen bricht CVS den commit Befehl mit einer Fehlermeldung ab. a) Konflikt mit selbstständiger Korrektur Prog2 holt sich die aktuelle Version aus dem REPOSITORY mit cvs update -d Folgende Meldung erscheint vom CVS: Merging differences between [Version im Workspace] and [Version im REPOSITORY] into Tobject.java M² Tobject.java In diesem Fall, haben sich die Änderungen von prog1 und prog2 gegenseitig nicht gestört. Es wurde z.b. nicht die selbe Variable eingefügt, oder die Änderung fand nicht in der selben Zeile statt. Nun verknüpft CVS die Versionen aus dem REPOSITORY und dem Arbeitsplatz von prog2 zu der Datei Tobject.java, und legt diese in das dazugehörige Verzeichnis im Arbeitsplatz ab. Anschließend kann prog2 die verknüpfte Version von Tobject.java mit cvs commit m In Tobject neue Variable eingefügt t 0:20,C Tobject.java ins REPOSITORY einbauen. b) Konflikt ohne selbstständige Korrektur Prog2 holt sich die aktuelle Version aus dem REPOSITORY mit cvs update -d Folgende Meldung erscheint vom CVS: Merging differences between [Version im Workspace] and [Version im REPOSITORY] into Tobject.java Rcsmerge: warning: conflicts during merge cvs update: conflicts found in Tobject.java C² Tobject.java In diesem Fall, haben sich die Änderungen von prog1 und prog2 gegenseitig gestört. Nehmen wir an, beide haben zufällig in der selben Zeile eine neue Variable zugefügt. CVS macht nun Folgendes; Es verknüpft beide Versionen aus dem REPOSITORY und dem lokalem ² Siehe Anhang, I.6.2 Abkürzungen bei CVS Meldungen 8

9 Arbeitsverzeichnis und legt diese verknüpfte Tobject.java Datei in das entsprechende Verzeichnis im Arbeitsverzeichnis ab. Die Stellen, welche den Konflikt ausgelöst haben, markiert CVS wie folgt im Quellcode der Datei: <<<<<<< Tobject.java [Änderungen an dem lokalem File] ====== [Änderungen aus der ausgecheckten Datei aus dem REPOSITORY] >>>>>>> [Versionsnummer der Datei aus dem REPOSETORY Über der gestrichelten Linie stehen die Änderungen, welche prog2 vorgenommen hat und unter dem Strich diese, die prog1 gemacht hat. Nun muß der Programmierer entscheiden, wie er die Konflikte auflösen kann, um anschließend die konfliktfreie Tobject.java Datei wie folgt in das REPOSITORY zurückzuschreiben: cvs commit m neue Variable in Tobject eingefügt t 0:45,C Tobject.java Nach dem korrekten lösen des Konfliktes und des commit Befehles steht die aktuelle Tobject.java Version im REPOSITORY und kann weiter von anderen Programmierern im aktuellem Stand verwendet werden. 9

10 I.6 Anhang zu CVS I.6.1 Wichtigen Befehle auf einen Blick cvs import [projectname] [person] [date] Neues Project anlegen. Projectname steht für den Namen des Hauptverzeichnisses des Projektes, person für den Namen dessen, der es angelegt hat und date für das Anlegedatum. cvs add [name] CVS mitteilen, daß die neue Datei name zum Projekt gehört und mit dem nächsten commit übernohmen wird. cvs checkout [project] Projekt aus dem REPOSITORY ins lokale Arbeitsverzeichnis kopieren. Project steht für Projektname. cvs update -d Änderungen aus dem REPOSITORY ins Arbeitsverzeichnis übernehmen (mischen). -d Parameter für Unterverzeichnisse cvs commit m Neue Variable hinzugefügt t 0:30,C [name] Durchgeführte Änderungen an den Dateien ins REPOSITORY zurückschreiben. cvs remove [name] Nachdem die Datei name aus dem lokalem Arbeitsverzeichnis gelöscht worden ist (rd name), CVS mitteilen, daß sie beim nächsten commit nicht mehr aktualisiert werden soll. I.6.2 Abkürzungen bei CVS Meldungen U update Datei aus dem Repository aktualisiert. A add Neue Datei hinzugefügt markiert. R remover Alte Datei gelöscht markiert. M modified Datei modifiziert. C conflict Datei enthält Konflikte.? Diese Datei ist CVS nicht bekannt, wird somit ignoriert. 10

11 II CVS Integration in SNiFF + II.1 Allgemeines Die Beschreibung der Integration in dieser Ausarbeitung wurde mit der CVS Version 1.9 auf UNIX System und CVS Version unter WINDOWS getestet. Es sollte SNiFF oder höher benutzt werden, denn ab diesen Versionen ist das Zusammenarbeiten zwischen CVS und SNiFF+ bereits integriert und muß nur aktiviert werden. Bei älteren Versionen muß zusätzlich der passende Adapter aus dem Internet geladen werden. In diesem Dokument wird davon ausgegangen, daß SNiFF oder höher verwendet wird. II.2 Notwendigen Einstellungen für die Einbettung von CVS in SNiFF+ Um das Zusammenarbeiten von CVS und SNiFF+ zu gewährleisten, müssen entsprechende Initialisierungen an CVS und SNiFF+ vorgenommen werden. Obwohl jeder Benutzer diese vornehmen kann, wird empfohlen einen CVS Administrator im Team auszuwählen. Nur dieser Administrator sollte die Änderungen der Initialisierung vornehmen. Falls ein Initialisierungsfehler vorliegt, muß auf diese Weise nicht mit allen Mitarbeitern in Kontakt getreten werden, um herauszufinden wer für den Fehler verantwortlich ist und wo er gemacht wurde. II.2.1 Einstellungen am CVS Als erstes muß das REPOSITORY vom CVS festgelegt werden. Dies geschieht durch das festlegen des Pfades, wo sich das REPOSITORY befindet. Dies kann folgendermaßen vorgenommen werden: unter UNIX : setenv CVSROOT [pfad] unter WINDOWS : set CVSROOT=:local:[pfad] Diese Einstellungen sollten in den Systemdateien.cshrc unter LINUX, UNIX und autoexec.bat unter WINDOWS eingetragen werden. Abschließend wird in das REPOSITORY Verzeichnis gewechselt und mit dem Befehl cvs init initialisiert. Dadurch legt das CVS ein CVSROOT Unterverzeichnis im REPOSITORY an, in welchem es die Systemdateien verwaltet. Diese sollten unberührt bleiben, um Fehler vorzubeugen. Nun ist das REPOSITORY initialisiert und dessen Pfad festgelegt. Es ist zu beachten, daß das festlegen von CVSROOT nicht erforderlich ist, um CVS über SNiFF+ zu benutzen. SNiFF+ benötigt ebenfalls den Pfad vom REPOSITORY und speichert ihn für sich ab. Diese 11

12 Einstellung ist lediglich erforderlich, falls CVS ohne SNiFF+ verwenden werden soll, sollte aber vollständigkeitshalber vorgenommen werden. II.2.2 Einstellungen am SNiFF+ Um das Zusammenspiel von CVS und SNiFF+ zu ermöglichen, muß in SNiFF+ den Pfad des CVS REPOSITORY s mitgeteilt werden. Anhand der folgenden Erklärung und der Abbildung 1 soll dem Benutzer die Vorgehensweise bei den Einstellungen dargelegt werden. 1. SNiFF+ starten 2. Im Working Environment Fenster ein neues RWE für das CVS REPOSITORY erstellen. Unter Root $CVSROOT eintragen und den Verzeichnispfad für das CVSROOT Verzeichnis setzen. Darauf achten, daß der Pfad vollkommen ausgeschrieben ist. 3. Unter dem Eintrag für das CVSROOT RWE das Verzeichnis festlegen, aus welchem die aktuelle Version des Projektes ausgecheckt werden soll ( SSWE ). 4. Unter CVS SSWE werden die SOWE und PWE festgelegt. So oder ähnlich müssen die Einstellungen aussehen : Abb. 1 : Einstellungen am SNiFF+ für die Einbettung von CVS II.3 Projekt unter CVS Verwaltung stellen Nun wird anhand eines Beispieles erklärt, wie ein neues Projekt mit Hilfe von SNiFF+ unter die Verwaltung von CVS gestellt wird. Es sei angenommen, daß der Mainordner unseres Projektes fujaba ist. 1. Den kompletten Pfad von fujaba in den SSWE oder PWE Ordner kopieren, welcher unter II.2.2 erstellt worden ist. Unter WINDOWS kann der Explorer benutzt werden und unter UNIX z.b. der cp Befehl. 2. Im Working Environment Fenster wähle die SSWE oder PWE 12

13 Arbeitsumgebung und wähle in der Funktionsleiste File, New Project, with Defaults. Wähle dann den Name für dein Mainordner der Projektes (hier also fujaba). 3. In den Attributen des New Project Dialoges, muß General angeklickt werden und sichergestellt werden, daß Create sobproject Tree aktiviert ist. 4. Wähle das Version Control System Feld aus und setzte den VCS Tool auf CVS. 5. Mit dem OK-Button wird das Projekt bestätigt und der Project Editor öffnet sich. 6. Wähle einige Dateien aus um das Benutzer Menue zu aktivieren. 7. Wähle nun CVS Admin, Add SNiFF+ cvsignore entries. Dies ist erforderlich für einen korrekten Import des Projektes. 8. Wähle CVS, Show cvsignore um zu überprüfen, ob das Projekt korrekt hinzugefügt worden ist. 9. Wähle abschließend alle Dateien aus und wähle File, Check in. Eine Dialog-Box mit den standard SNiFF Parametern fürs Einchecken erscheint. Falls CVS keine Fehler beim einchecken anzeigt, wurde das Projekt erfolgreich ins REPOSITORY übertragen. II.4 Neue Version aus REPOSITORY auschecken, modifizieren, updaten und commiten In diesem Abschnitt wird Schritt für Schritt die Vorgehensweise erklärt, wie man mit Hilfe von SNiFF+ die aktuellste Version des Projektes aus dem REPOSITORY auschecken kann; Anschließend wie die Dateien bearbeitet werden könne, vor dem einchecken überprüften werden könne, ob mittlerweile eine aktuellere Version von einem anderem Programmierer im REPOSITORY abgelegt worden ist, um diese mit seiner dann abzugleichen. Schließlich wie die eventuell neuen Version, wieder ins REPOSITORY eincheckt wird. Erstmals muß das Projekt aus dem REPOSITORY in das private Workspace ( PWE ) ausgecheckt werden. Über CVS Modules, Check out module into... wird der Projekt Editor geöffnet, wo dieses vorgenommen werden kann. Um die Datei nun zu modifizieren, muß diese in den Editor laden werden. Dies geschieht über CVS, Edit file. Um sich eventuell einen Überblick zu machen, welche Dateien wann geändert worden sind, um z.b. zu sehen, ob die Schnittstellen noch aktuell sind, kann dieses über CVS, Watch file(s) oder CVS, Show editors of file(s) machen werden. Vor dem einchecken ins REPOSITORY muß ein update durchgeführt werden, um sicher zugehen, daß in der Zwischenzeit kein anderer Programmierer eine neue Version der Datei ins REPOSITORY abgelegt hat. Falls doch, dann bindet dieser Befehl beide Versionen und die Änderungen werden vereinigt. Nun können über CVS Modules, Commit Module, die vorgenommenen Änderungen ins REPOSITORY zurückgeschrieben werden. 13

14 III Team Software Process III.1 Was ist und wo wird Team Software Process angewendet Team Software Process, TSP, wird verwendet um große Projekte, welche sich um den Softwareentwurf drehen, im Voraus zu planen und zu organisieren. In der Regel werden in großen Softwarehäusern die Programme im Team ausgearbeitet. Im Team zu arbeiten bringt jedoch viele Probleme mit sich mit, die vor allem Ablauf-Management Zeit-Management und Organisations-Management betreffen. Um diese drei Punkte gut im Voraus und während des Programmentwurfes unter Kontrolle zu halten, wird Team Software Process eingesetzt. Im weiteren Verlauf dieser Ausarbeitung wird darauf eingegangen, welche Zwischenstationen ein Projekt beinhalten muß, damit dieses in geplantem Rahmen bleibt. Durch den Team Software Process ist es möglich, in jeder Stufe der Zwischenstationen abzuschätzen, ob der Zeitplan Noch eingehalten ist, oder ob Änderungen vorgenommen Werden müssen. III.2 Struktur von Team Software Process Der TSP kann graphisch durch ein Diagramm dargestellt Werden und ist in Abbildung 2 dargestellt. Es hat mehrere Phasen, die im Projekt abgearbeitet werden müssen und kann nur von Phase zu Phase wechseln, wenn die momentan laufende komplett abgeschlossen ist. Anhand der Abbildung wird erklärt, welche Phasen ein Projekt Durchlaufen muß, um richtig fertiggestellt zu werden. III.3 Beschreibung der einzelnen Phasen im TSP Diagramm III.3.1 Planning In dieser Phase werden zwei wichtige Aspekte behandelt. Zu einem der Aspekt, der sich mit den Anforderungen an das Programm befaßt und zum anderem wie die Anforderungen umgesetzt werden können. a) Machbarkeitsstudie Abb. 2 : TSP In der Machbarkeitsstudie wird sich mit der Problembeschreibung beschäftigt und nach der bestmöglichen Lösung des Problems gesucht unter Berücksichtigung diverser 14

15 Alternativen. Vorwissen hat dafür wesentlichen Einfluß und spiegelt sich meist in den Kosten für das Projekt wieder. b) Anforderungsanalyse Bei der Anforderungsanalyse wird die Funktionalität und Qualität der Software beschrieben und genau festgelegt. Also, was das Programm leisten soll. III.3.2 Main Design An dieser Stelle des Projektes werden die anstehenden Aufgaben in grobe Teilbereiche aufgeteilt. Die einzelnen Teilbereiche heißen work package. Es sollte beachten werden, daß jedes work package jeweils von nur einem Mitarbeiter bearbeitet wird. Es muß also darauf geachtet werden, daß die packages so aufgeteilt werden, daß sie nicht zu groß sind. Um die Übersicht zu behalten, sollte für jedes work packege ein separates Verzeichnis im CVS angelegt werden. III.3.3 Size and Time Estimation Hier werden die Größen- und Zeitschätzungen jedes Mitarbeiters aufgenommen, die er für sein work package benötigt. So wird anhand der Daten während des Projektes festgestellt, ob die Zeit noch eingehalten ist. Sehr hilfreich für solche Schätzungen ist, falls aus gleichartigen Projekten schon Daten zur Verfügung stehen und diese auf das laufende Projekt übertragen werden können. Bestehen solche Daten, so wird anhand von gegebenen Verfahren die Anzahl Zeilen ermitteln und daraus die benötigte Zeit für jedes work package berechnet. Aus den einzelnen Zeiten entsteht dann ein Bild des Ausmaßes vom ganzen Projekt. Gibt es keine vergleichbaren Daten zur Verfügung, so muß eine eigene Schätzung vorgenommen werden. In solch einem Falle wird eine maximale Zeit für das bearbeiten des packages geschätzt und eine Untergrenze an benötigter Zeit. Der Produktionsfaktor jedes Programms wird ermittelt und anschließend die Kosten geschätzt. III.3.4 Gantt-Chart In den Gantt-Chart werden die geschätzten Daten graphisch dargelegt, so daß anhand dieser die momentane Stelle des Projektes sichtbar ist, und ob der Zeitplan eingehalten wird. Ebenso wird die Abhängigkeit zwischen den einzelnen work packages an den Gantt-Chart sichtbar. Diese bestehen z.b. darin, daß einige Programmteile eher programmiert werden müssen als andere. Dadurch ergibt sich eine bestimmte Reihenfolge der Abarbeitung der packages. Die Gantt-Chart werden laufend aktualisiert. 15

16 III.3.5 Design In dieser Phase wird das Design des Programmes festgelegt. Jeder Programmiere beschäftigt sich mit dem Fein-Design seines work package. Hier zerlegt der Programmiere seinen Teil des Projektes in strukturierte Klasse mit festgelegten Attributen und Funktionen. Die Kommunikation zwischen den einzelnen packages, die Schnittstellen für die Kommunikation der Klassen also, werden hier ebenfalls festgelegt. Der Programmierer hat seine Design-Phase abgeschlossen, falls sein work package komplett ist und sein Design durch die Design-Inspection (siehe III.3.6 Design-Inspection) ohne Bemängelung durchkommt. III.3.6 Design-Inspection Hier werden die ausprogrammierten Klassen eines Mitarbeiters von einer dritten Person überprüft. Obwohl der Programmierer und sein Prüfer anonym und zufällig gewählt sind, hat die Design Inspection Phase einen hohen psychologische Wert. Jeder Programmierer weiß, daß seine Arbeit von einem anderem überprüft wird. Natürlich will jeder gut bei seinen Kollegen aussehen, deswegen achtet er mehr darauf, keine Fehler zu machen. Für den Inspekteur hat es einen guten Lernefekt, denn er bekommt mehr Erfahrung in das Einarbeiten in fremde Teilsysteme und lernt selbst, seinen Programmierstiel zu verbessern, um verständnisvollere Quelltexte zu schreiben. Der Inspekteur bekommt die Arbeit des anderen und sucht diese nach Fehlern ab. Er berücksichtigt sowohl die Tippfehler, als auch schlechte Kommentarsetzung. Nachdem der Programmiere seine Version mit den markierten Fehlern zurück bekommt, muß er die Fehler korrigieren und seine Arbeit erneut unter Test stellen. Es ist nicht zwingend, eher unwahrscheinlich, daß jetzt der selbe Inspekteur diese Arbeit bekommt, da der Prüfer zufällig gewählt wird. Dies ist nur zum Vorteil, denn der erste Prüfer kann einige Fehler übersehen haben. Somit besteht eine hohe Wahrscheinlichkeit, daß nach einer abgeschlossenen Design-Inspection Phase seine Arbeit fehlerfrei ist. Erst in diesem Fall darf der Programmierer in die nächste Phase wechseln. III.3.7 Implementation In der Implementations Phase wird aus der korrigierten Arbeit ein Quelltext generiert. Dieser wird kompiliert und ausführlich getestet. Nachdem der Programmierer der Ansicht ist, daß sein Quelltext fehlerfrei ist, geht er in die Implementation-Inspection Phase (siehe III.3.8 Implementation.Inspection) über. III.3.8 Implementation-Inspection Ebenso wie nach der Design Phase wird nach der Implementation Phase ein Test des Quellcodes durch eine Dritte, zufällig bestimmte und dem Programmierer nicht bekannte Person, durchgeführt (Der Inspekteur ist ebenfalls dem Programmierer nicht bekannt). Dieser Test gilt wieder der Prüfung auf mögliche Programmierfehler, aber auch um Tips, Erfahrungen und Tricks zwischen den Programmieren auszutauschen. 16

17 Der Vorgang ist gleich wie in der Design-Inspection Phase. Der Inspekteur sucht den Quelltext nach Fehlern ab und markiert diese. Der Programmierer muß nun diese Fehler beheben und den Quelltext erneut testen lassen. Dieser Vorgang wird solange wiederholt, bis vom Inspekteur keine Fehlerverbesserung mehr kommt. III.3.9 Build-In-Test Dieser Test muß abschließend durchgeführt werden, damit das work package als fertig implementiert gilt. Dieser Test wird durch eine Person durchgeführt, welche mit dem Projekt nichts zu tun hat. Dies hat den Vorteil, daß durch eine neutrale Person, welche mit einem anderem Blickwinkel das Programm testet, Fehler beseitigt werden können, die durch Projektbeteiligten übersehen worden sind. Nach dem Test wird dem Programmierer das Work Package-Test-Protokoll übergeben. III.3.10 Build Nun, da die einzelnen work packages lauffähig und fehlerfrei sind, werden diese zu einem komplettem Programm zusammengebunden. III.3.11 End-Test Zum Schluß muß noch das komplett gebundene Programm getestet werden. Hier wird das Programm den Anforderungen aus der Planning Phase unterzogen. III.4 Wo ist dieses in das CVS der Universität Paderborn eingebunden? Anhand der Abbildung 3 wird dargelegt, wie TSP bei uns angewendet wird. AUTOR 1. CVS commit CVS 4. Inspection-Report TEAM MITGLIEDER 2. Sent inspection 3. Return Inspection TSP 2.1 copy inspection MANAGER 4.1 copy Inspection-Report Abb. 3 17

18 1. Datei wird eingecheckt 2. und 2.1 Eine Inspection mail wird an ein zufälliges Teammitglied geschickt und an des Manager. 3. Korrigierte Inspection mail zurück. 4. und 4.1 Korrigierte Inspection mail zurück an Autor und eine Kopie an den Manager. IV Zusammenfassung Diese Ausarbeitung soll den Teammitgliedern der PGJEVOX Projektgruppe einen Einblick in CVS und TSP geben, weil diese uns 2 Semester lang begleiten werden. Auf das Einbetten von CVS in SNiFF+ wird in dieser Projektgruppe nicht weiter eingegangen, weil CVS alleine ausreichend ist. Desweiteren läuft die Einbettung in jetziger Version von SNiFF+ nicht ganz stabil. An diesen Problemen wird intensiv von den Entwicklern von SniFF+ gearbeitet, so daß vielleicht dieses bei der nächsten Version nicht mehr auftauchen werden. In diesem Dokument sieht man deutlich unter III.4 das benutzen des Team Software Process durch CVS. Es erleichtert das zusammenarbeiten, denn bei unserer Gruppe ist es nicht einfach Termine zu finden, an denen man sich treffen kann. Ohne CVS würde das bedeuten, daß es einmal die Woche eine aktuelle Version des Projektes geben würde. Bei dem Treffen würde dann vermutlich die meiste Zeit geopfert werden, um die Änderungen an den Dateien zusammenzutragen. Somit ist es eine wirkliche Erleichterung, nicht nur für unsere PGJEVOX. Wie schon erwähnt, wird an CVS und SniFF+ ständig gearbeitet und verbessert, so daß in Zukunft das Arbeiten im Team und die dazugehörigen Probleme leichter zu bewältigen sein werden. Dies ist für uns Programmierer sicherlich eine nützliche Hilfe. V Literatur : Projektverwaltung mit CVS, Internetartikel Kurzeinführung in CVS, ISA Systemverwaltung, Internetartikel Seminarausarbeitung Projektgruppe FUJABA, Dez VII. Versionsverwaltung mit CVS, Ingo Rockel IX. TSP Team Software Process, Jens Mühlenhoff CVS-Kurzanleitung, Kai Helms, Internetartikel Eine kurze Beschreibung von CVS, Stefan Eggers, Internetartikel Gemeinsame Source-Code Verwaltung mit CVS, Siegfried Bublitz, Jan. 1999, Internetartikel Integrating SNiFF+ with CVS, Take Five Software, Internetartikel 18