Inhalt dieser Seite:

0. News
1. Worum geht es?
2. Worauf achten die Betreuer?
3. Die beteiligten Personen (zu den Gruppenlinks)
4. Phasen, Dokumente und Termine
5. Wichtige Informationen, Werkzeuge, Links
6. Literatur

Nützliche Links: [ProgPrak HT04] [Gruppenlinks] [Belegungsplan EC]

0. News

1. Worum geht es?

• relativ klein: innerhalb einer Woche zu bearbeiten;
• präzise beschriebene Problemstellung, häufig mit angedeutetem Lösungsweg;
• in verlangter Programmiersprache formulierter Code ist wesentliches Ergebnis.

• umfangreicher: beschäftigen ein Team ein Trimester lang;
• nur vage formuliert: Ihre erste Aufgaben wird sein, das gestellte Problem zu analysieren und in Verhandlung mit dem Auftraggeber die konkrete Aufgabe auszuhandeln;
• Entwicklungsaufgaben, die in vorgegebenen Phasen durchgeführt werden müssen. Ebenso wichtig wie das zu erstellende Programm sind die während der Entwicklung anfallenden Dokumente und Tests.

Von Nutzen wird Ihnen dabei alles sein, was Sie in der Einführungsvorlesung unter dem Thema "Objektorientierte Programmierung" gelernt haben über Java und seine Klassenbibliotheken, Wiederverwendung, CRC-Karten, UML-Diagramme, Muster und Frameworks.

Außerdem steht Ihnen mit dem Framework SalesPoint eine "Halbfertiglösung" zur Verfügung, die Sie "nur noch" zu einer vollständigen Lösung ausbauen müssen - sobald die eigentliche Aufgabenstellung erarbeitet ist. Leider haben auch hier die Götter den Schweiß vor den Erfolg gesetzt: Bevor man das Framework nutzen kann, muß man es verstehen. Mit einer neuen verbesserten Version des Frameworks und einer ausführlichen Dokumentation haben wir uns bemüht, Ihnen den Einstieg so einfach wie möglich zu machen.

2. Worauf achten die Betreuer?

Die Situation der Praktikum-Betreuer ähnelt der von Projektleitern in einem kleinen Softwarehaus, die einen Kundenauftrag

• unter Einbeziehung des Firmen-Know-Hows (gegeben in Form eines Frameworks und seiner Dokumentation)
• mit relativ unerfahrenen Entwicklern
• termingerecht

Zum Framework

1. Durch das Framework ist eine Grundarchitektur vorgegeben. Das erleichtert den für Unerfahrene schwierigen OO Entwurf.
2. Einarbeitung in bestehende Programmsysteme gehören zum Arbeitsalltag des Software-Entwicklers. Das Framework ist durch die ausführliche Beschreibung und die flexible Anpassungsschnittstelle vergleichsweise gut zugänglich.
3. Es soll Wiederverwendbarkeit bewußt eingeübt werden. Unerfahrene Entwickler neigen dazu, laufend das Rad neu zu erfinden. Auf diese Weise entstehen unkontrollierte Code-Doubletten, die - weil nicht zusammenhängend - nicht systematisch gewartet (verbessert oder an neue Gegebenheiten angepaßt) werden können. Im Gegensatz dazu erfordert die Wiederverwendung von Bausteinen deren laufende Anpassung und führt dadurch zu immer flexibleren und verläßlicheren Komponenten: die Qualität steigt, die investierte Mühe lohnt sich mittelfristig.

Neben dem zweckgemäßen Einsatz des Frameworks werden daher auch Beiträge zu dessen Verbesserung (neue, universell einsetzbare Bausteine, oder überarbeitete alte) besonders positiv gewertet.

Um Wildwuchs zu vermeiden, soll das Framework nicht im Quelltext von den Anwendungsentwicklern modifiziert werden. Es werden daher nicht die Quellen, sondern nur die übersetzte Fassung des Frameworks bereitgestellt.

Zu JUnit

Zu BSCW

• pdf
• html

• Das JAVA-Applet JUploader unterstützt beim Hochladen mehrerer Dateien. Ordnerstrukturen werden _nicht_ unterstützt!
• Mithilfe des WebDAV-Protokolls kann die BSCW-Struktur z.B. unter Windows in den Explorer integriert werden. Damit können ganze Ordnerstrukturen hin und her verschoben werden. Eine Anleitung zum Einrichten der entsprechenden Netzwerkverbindung gibt es hier.

Zur Termintreue

Wie unten ausführlich dargestellt, zerfällt die Projektentwicklung in fünf aufeinanderfolgende Phasen (Analyse, Einarbeitung, ..., Wartung), die zu festgelegten Zeitpunkten mit schriftlichen Ergebnissen und mündlicher Präsentation abgeschlossen werden. Auf Termintreue wird besonderer Wert gelegt. Bei  Nichteinhaltung eines Termins setzt der Betreuer dem Team eine Nachfrist von 2 - 3 Tagen. Teams, die auch am Ende der Nachfrist kein zufriedenstellendes Phasenergebnis vorgelegt haben oder die mehr als zwei Nachfristen benötigen, scheiden aus dem Praktikum ohne Schein aus. Vor dem Ausscheiden oder bei Terminüberschreitungen aus nicht von den Teilnehmern zu verantwortenden Gründen findet eine Konsultation zwischen Team, Tutor und Praktikumsleiter statt.

Teams, die vorzeitig fertig werden, können sich früher auf die DVP-Vorbereitung konzentrieren.

Zur Transparenz

Die Betreuer und der Projektleiter müssen den Projektfortschritt kontinuierlich beobachten, um bei Fehlentwicklungen so früh wie möglich korrigierend eingreifen zu können. Bei den Ergebnispräsentationen am Ende einer Phase ist es dafür meist schon zu spät. Aus diesem Grund muß

1. der Projektfortschritt laufend in Form der aktuellen Fassungen der geforderten Dokumente und Programme auf den gruppeneigenen WWW-Seiten dokumentiert werden, so daß alle Änderungen so rasch wie möglich sichtbar werden (spätestens am Ende der ersten Praktikumswoche und danach jeweils einen Tag vor der ersten Präsenattion muß das Material zur aktuellen Phase eingestellt sein);
2. regelmäßig mündlich Bericht erstattet werden, und zwar wöchentlich zu den festgelegten Terminen (jeweils ca. 15 Minuten Bericht, anschließend Fragen) von jedem Team im Electronic Classroom der Fakultät, der dafür bereits reserviert ist. Dabei soll jedes Teammitglied seinen aktuellen Arbeitsbeitrag vorstellen und ggfs. Fragen dazu kompetent beantworten.

Die Abschlußpräsentation am Ende des Praktikums dauert eine Stunde je Team und dient der Abnahme der fertigen Arbeit.

Präsentationen wie die Endabnahme, die Zwischenberichte und Phasenabschlüsse sind von den Teams sorgfältig vorzubereiten. Insbesondere ist sicherzustellen, daß auf dem Vorführrechner im Electronic Classroom alles vor Beginn der Präsentation ablaufbereit vorliegt.

Während oder nach den Zwischenberichten und Phasenabschlüssen können noch Verbesserung eingefordert werden, da die Ergebnisse teilweise nicht in der gewünschten Ausführlichkeit vorhanden sind. Da es hierbei immer wieder zu Missverständnissen bezüglich der Anmerkungen gibt, möchte ich noch einmal auf folgendes hinweisen: Kritik wird meist nur an einigen Beispielen (fehlende Dokumentation an einem UML-Diagramm, fehlende Javadoc-Beschreibung der Klasse XYZ etc.) geäußert. Verstehen Sie dieses jedoch nicht nur als Aufforderung, das angesprochene Objekt zu ändern, sondern als Anweisung gemäß den am Beispiel gestellten Anforderungen die gesamte Dokumentation der Phase zu überarbeiten!

Zum "geistigen Eigentum"

Die offene Darstellung aller Zwischenergebnisse auf WWW-Seiten soll bewußt ein Klima der Kooperation auch über Teamgrenzen hinweg fördern (ganz im Sinne des Internet): Es ist ausdrücklich erlaubt, gute Ideen von anderen Gruppen sinngemäß für die eigenen Lösungen zu verwenden. Wichtigstes Ziel ist es, daß alle möglichst viel lernen - und dies bei den Präsentationen und durch die Qualität der eigenen Produkte nachweisen.

Natürlich ist es nicht erlaubt, fertige Dokumente oder Programmteile von anderen zu übernehmen (außer dem Framework). Begründete Ausnahmen sind mit der Praktikumsleitung im Einzelfall abzusprechen (und auch entsprechend zu kennzeichnen).

Ein Tipp: Sehen Sie sich mal die WWW-Seiten der letztjährigen Praktikumsgruppen an (und versuchen Sie, es noch besser zu machen)!

3. Die beteiligten Personen

Unterschiedliche Personenkreise sollen zum Gelingen des Praktikums beitragen, teilweise sogar in mehreren Rollen.

a) Der Praktikumsleiter (Thomas Triebsees)

Als Praktikumsleiter bin ich für die Durchführung des Praktikums verantwortlich. Meine wichtigste Aufgabe während der Durchführung des Praktikums ist die Kontrolle der Arbeitsleistung der Studenten und die entsprechende Vergabe der Scheine. Zu diesem Zweck werde ich laufend

• die Zwischenergebnisse auf den WWW-Seiten,
• die gezeigte Termintreue und
• die Arbeitsqualität beobachten,
• den Präsentationen beiwohnen und
• die Betreuer nach ihrem Eindruck befragen.

b) Die Betreuer/Auftraggeber

Acht Studenten des Jahrgangs 2004, die im letzten Herbst selbst das Praktikum erfolgreich absolviert haben, übernehmen die Betreuung der Teams:

Team 1:	Falko Knoefler (Frameworkbeauftragter)
	Sebastian Leinhos
Team 2:	Conrad Reisch (Frameworkbeauftragter)
	Torsten Walter
Team 3:	Frank Tietze (Frameworkbeauftragter)
	Oliver Seelige
Team 4:	Frank Grzelke (Frameworkbeauftragter)
	Lena Lutz

Alle Betreuer haben gegenüber ihrem Team zwei Rollen:

• als Vertreter des Auftraggebers handeln Sie im den Teams die genaue Aufgabenstellung aus und lassen sich laufend über den Arbeitsfortschritt berichten;
• als Berater stehen Sie den Teams jederzeit mit Rat zur Verfügung, wenn dort technische oder organisatorische Probleme auftreten, die nicht vom Team selbst gelöst werden können. Die Frameworkbeauftragten dienen insbesondere der Beantwortung technischer Fragen zum SalesPoint/WebPoint Framework. Daher wird von ihnen nur eine Gruppe als Auftraggeber betreut. Die anderen Betreuer sind für jeweils zwei Gruppen verantwortlich.

Tipp an die Teams: In Zweifelsfällen lieber frühzeitig die Betreuer fragen, als durch Mißverständnisse wertvolle Arbeitszeit vergeuden !

c) Die Studenten

Die Projektaufgaben werden von Studententeams weitgehend autonom bearbeitet. Ein Team besteht aus 7 - 8 Studenten, die alle als Entwickler arbeiten und einzeln für bestimmte Programmteile, deren Entwicklung und Dokumentation verantwortlich sind. Das Team ordnet vieren seiner Mitglieder zusätzliche Rollen zu:

• der Chef des Teams koordiniert die Zusammenarbeit im Team und fungiert als Sprecher nach außen;
• der Stellvertreter des Chefs übernimmt dessen Aufgaben (bei Erkrankungen o.ä.)
• der Dokumentar des Teams ist zuständig für die Präsentation auf den WWW-Seiten. Dazu erhält er fertige Beiträge von den Teammitgliedern, die er ggf. redaktionell überarbeitet, verlinkt, versioniert und sichert.
• der Testentwickler des Teams ist zuständig für die projektbegleitende Testentwicklung. Er arbeitet sich detailliert in das JUnit-TestFramework ein und erstellt zunächst anhand der konzeptionellen, später auch der programmiertechnischen Ergebnisse der einzelnen Phasen die Tests.

Die insgesamt 12 Teams sollen möglichst leistungsähnlich sein (also nicht Teams aus lauter Starken oder lauter Schwachen). Falls wider Erwarten keine vernünftige Teameinteilung zustande kommt oder Streitigkeiten entstehen, behalte ich mir Änderungen vor.

d) Die Ansprechpartner für die Technik

Bei Fragen im Zusammenhang mit den Gruppenkennungen auf den Institutsrechnern wenden Sie sich bitte an Frau Beckh.

Bei Fragen betreffend die Rechner und Geräte des Electronic Classrooms wenden Sie sich bitte an Herrn Langer.

4. Phasen, Dokumente und Termine

Am 04.10.2005 findet eine detaillierte Einweisung in das Praktikum statt. Raum und Zeit werden rechtzeitig hier bekannt gegeben.

Das Praktikum wird in fünf aufeinanderfolgenden Phasen nach folgendem Zeitplan durchgeführt (vgl. auch Regelungen zur Termintreue):

Jeweils (allerspätestens!) eine Woche vor Phasenende (also zur Zwischenpräsentation) muß ein wesentlicher Teil erledigt und auf den WWW-Seiten dokumentiert sein.

Die WWW-Dokumentation soll phasenweise organisiert sein, damit der Projektfortschritt sichtbar bleibt. An jedem Phasenende soll deshalb die Dokumentation zur Phase "eingefroren" werden. Wird ein Dokument in einer späteren Phase aktualisiert (modifiziert bzw. erweitert), dann sollen diese Änderungen an einer Kopie des Dokuments vorgenommen werden.

ZumSchluß erfolgt die Endabnahme.

• Rollen im Team festlegen
• WWW-Startseite einrichten
• Werkzeuge (wieder?) beschaffen

Nun zu den einzelnen Phasen:

Phase 1: Analyse

Zweck dieser Phase ist es, das gestellte Thema vollständig zu durchdringen, seine Möglichkeiten auszuloten und die Anforderungen des Auftraggebers zu erkennen. Die Reihenfolge der Arbeitsschritte, mit denen Sie sich der Aufgabe nähern ist sehr wichtig, da jeder folgende Schritt auf die Ergebnisse und das Wissen aus dem vorigen Schritt aufbaut. Deswegen ist es von besonderer Wichtigkeit, die unten angegebenen Dokument der Phase 1 auch in der Reihenfolge auszuarbeiten.

Gehen Sie wie folgt vor.

1. Identifizieren Sie anhand der Themenbeschreibung einige wichtige Anwendungsfälle (engl.: Use-Cases). Diese Anwendungsfälle sollen durch kurze Teilsätze (z. B.: "Kunde anlegen", "Photoauftrag im Internet annehmen") beschrieben werden. Die Liste dieser Anwendungsfälle soll alle möglichen durch die Aufgabe implizierten Funktionalitäten des Programms wiedergeben. Ordnen Sie die Anwendungsfälle ihren realen Benutzern zu.
2. Spielen Sie konkrete Szenarien zu diesen Anwendungsfällen durch (mitprotokollieren!) und stellen Sie dabei CRC-Karten auf (ebenfalls aufschreiben). Die Szenarien basieren auf den Anwendungsfällen. Sie sollen konkrete vorstellbare Abläufe innerhalb des Programms wiederspiegeln, z. B. "Nicht registrierter Kunde sendet Photoauftrag per Post ein". Jedes Szenarium soll so detailliert wie möglich beschreiben, welche einzelnen Programmeinheiten und -datenstrukturen beteiligt sein werden. Aus der in den Szenarien dokumententierten Interaktion zwischen diesen Einheiten lassen sich dann die CRC-Karten ableiten. Nutzen Sie dazu auch das Mittel der CRC-Kartensitzungen, um die Szenarien eventuell detaillierter zu gestalten. Dokumentieren Sie Szenarien und CRC-Karten auf der Webseite ausführlich.
3. Suchen Sie nach Aspekten, die in der Aufgabenstellung nur angedeutet sind oder ganz fehlen könnten. Behandeln Sie diese analog.
4. Erst wenn Sie alle möglichen Aspekte in den bisher angegeben Schritten behandelt haben, ordnen Sie die gefundene Funktionalität in einer Prioritätenliste an, wobei Sie aus Anwendersicht (!) unterscheiden sollten,
   • was das zu erstellende Programm auf jeden Fall leisten muß (siehe Schlußsatz zu Phase 3);
   • was es darüber hinaus leisten soll (siehe Phase 4);
   • welche Dinge es noch leisten kann, wenn dafür die Entwicklungszeit reicht.
   Stellen Sie die Prioritätenliste erst auf, nachdem Sie sich gründlich mit der Aufgabenstellung auseinandergesetzt haben (unter 1.-3. beschriebene Aktivitäten)! Natürlich möchte man so bald wie möglich wissen, was insgesamt zu leisten ist. Bevor man beim Auftraggeber mit einem konkreten Vorschlag Erwartungen weckt, sollte man aber deren Umsetzbarkeit prinzipiell durchdacht haben. Aus Auftraggebersicht sollte der Plan ein attraktives Produkt mit abgerundeter Funktionalität skizzieren. Das ein oder andere geplante "Highlight" zeigt dem Kunden, daß die Entwickler seine Interessen im Auge haben.
5. Legen Sie diese Arbeitsergebnisse (CRC-Karten, Ablaufprotokolle zu Szenarien, Prioritätenliste) dem Auftraggeber vor. Klären Sie mit ihm Zweifelsfälle ab und verhandeln Sie über die Prioritäten,  die am Ende (!) der Analysephase "verbindlich" festgelegt werden - nicht vorher, sonst ist es sinnlos, weiter zu analysieren.
6. Erstellen Sie auf der Basis der bisherigen Ergebnisse
   • ein vorläufiges, aber ausführliches Benutzerhandbuch (hier kann bisher Vergessenes auftauchen);
   • ein UML-Klassendiagramm, welches die statischen Zusammenhänge der gefundenen Kassen beschreibt; dokumentieren Sie diese Zusammenhänge und vernachlässigen Sie die Prozesssicht in UML-Klassendiagramm. Relevant sind hier die Organisation der Informationen.
   • zu den komplizierteren Anwendungsfällen UML-Sequenzdiagramme bzw. UML-Aktivitätsdiagramme.
   • einen Testplan, der zumindest alle identifizierten Uses Cases sowie kritische funktionale Anforderungen abdeckt.
   Die Dokumentation dieser Phase soll für den Kunden, d.h. für Laien lesbar sein. Vermeiden Sie daher programmiertechnische Termini und verwenden Sie die Sprache des Anwendungsbereichs (z.B. bei Klassennamen).
7. Revidieren Sie anhand der zusätzlichen Dokumente Ihre Prioritätenliste und legen Sie alles nochmals dem Auftraggeber zur Zustimmung vor.

Anforderung: Verwenden Sie für die von Ihnen entwickelten Klassen, Methoden und alle anderen Programmbezeichner durchgängig entweder englische oder deutsche Bezeichnungen. Halten Sie Ihre Kommentare im Quellcode, Webseite und die darin befindliche Dokumentation allerdings ausschließlich auf deutsch!

Hinweis: Achten Sie darauf, eine realistische, d.h. erfüllbare Anforderungsliste zu erstellen. Lassen Sie sich dabei von groben Aufwandsabschätzungen leiten. Bieten Sie umgekehrt dem Auftraggeber Funktionen an, die Sie leicht implementieren können.

Phase 2: Einarbeitung

Ziel der Einarbeitungsphase ist es, sich mit dem SalesPoint/WebPoint-Framework vertraut zu machen. Dazu soll das Tutorial und die kleine Beispiel-Applikation "Videoverleihautomat" durchgearbeitet und etwas modifiziert werden. Verwenden Sie die ersten Tage dieser Phase, um sich intensiv in die Framework-Dokumentation einzuarbeiten (Alles ansehen, besonders gründlich die Überblicksseiten und das Tutorial). Danach sind die Aufgaben gut zu schaffen. Die Vorgaben für die Modifikationen am Videoverleihautomten finden Sie hier. Die Einarbeitung ins WebPoint-Framework wird durch Torsten Walter koordiniert.

Für beide Frameworks gibt es Dokumentation. Die des SalesPoint-Frameworks gibts hier zum Downlad. Die WebPoint-Doku ist hier zu finden.

Danach soll der "Videoverleihautomat" überarbeitet werden. Gehen Sie dabei analog zum Tutorial vor, wo auch alle benötigten Techniken beschrieben sind. Erstellen Sie entsprechende Dokumente (s.u.) und legen Sie sie ins Netz (auch schon im halbfertigen Zustand; laufend dort aktualisieren!). Bearbeiten Sie oben zum Herunterladen bereitgestellten Aufgaben. Pflicht sind A.*, B.2, B.4, C.2, C.5. und C.6. Alle anderen Aufgaben können zur weiteren Übung auch bearbeitet werden. Die zu bearbeitende Videomaschine, das Framework, etc. finden unter "Wichtige Informationen".

• UML-Klassendiagramm zum modifizierten Videoverleihautomaten (falls erforderlich, in übersichtliche Teildiagramme aufteilen!)
• Quellen und übersetzte Programme in zip- bzw jar-Files.
• javadoc-Dokumentation der modifizierten Quellen
• Kurzgefasstes Handbuch (alle Menüpunkte kurz (!) erläutern und ein paar Screenshots zur Illustration verwenden).

Phase 3: Design & Prototyp

Ziel dieser Phase ist es, die Gesamtstruktur der Implementierung zu entwerfen sowie wichtige bzw. kritische Funktionen in einem Prototyp zu implementieren und dem Auftraggeber zur Verfügung zu stellen, damit sein Feedback dazu in der nächsten Phase berücksichtigt werden kann.

Ein genauer Abgleich zwischen dem Analyseergebnis und der Beschreibung des Frameworks ist erforderlich, um festzustellen

• welche der geforderten Funktionen das Framework abdeckt;
• welche weiteren Funktionen es nach Anpassungen ("wie genau sehen die aus?") abdeckt;
• was darüber hinaus zu ergänzen und wie einzubinden ist.

Die Verantwortlichkeiten der in der Analysephase gefundenen Klassen müssen dabei solchen Klassen des Frameworks zugeordnet werden, die eben dies schon leisten, oder solchen anwendungsspezifischen Unterklassen von Frameworkklassen, die zwecks Anpassung an die konkrete Problemstellung einzurichten sind. Es entstehen neue Klassenbeschreibungen und ein neues statisches Klassendiagramm. (An diesem Diagramm und dem aus der Analysephase werden die Gemeinsamkeiten und die Unterschiede zwischen Analysemodell und zu implementierendem Modell deutlich.)

Wichtige Anpassungsschritte sind:

• die Festlegung konkreter Katalogs- und Bestandsklassen;
• die Umsetzung von Anwendungsfällen in SaleProcesses (mit Hilfe von Zustandsübergangsdiagrammen, die jetzt auszuarbeiten sind);
• die Darstellung von Katalogen und Beständen (nebst Sortierung und Filterung) in der grafischen Oberfläche; Bereitstellung von Operationen über Menüpunkte und Knöpfe (das Benutzerhandbuch ist entsprechend zu aktualisieren).

In dieser Phase fallen folgende Ergebnisse an:

• Ergebnis des Abgleichs: Klassenbeschreibungen und statisches Klassendiagramm einschließlich textueller Dokumentation (Konzepte, Zusammehänge);
• Arbeitsplan: welcher Entwickler für welche Klassen zuständig ist (wann Fertigstellung?);
• Aktualisiertes Benutzerhandbuch mit vollständiger Menübeschreibung;
• Zustandsübergangsdiagramme zu den Anwendungsfällen, bzw. den erstellten Prozessen;
• Aktualisierter Testplan sowie Testprotokolle und ggfs. Testklassen der am Prototypen bereits durchgeführten Tests. Grundsätzlich ist jede nicht durch SalesPoint/WebPoint bereitgestellte Funktionalität angemessen zu testen!
• Zum erstellten Prototypen:
  • javaDoc-Dokumentation mit Erläuterungen zur Implementierung im Stil der Framework-Dokumentation. Zusätzlich soll der Zusammenhang zur Aufgabe und zur technischen Dokumentation hergestellt werden, und zwar in Form von HTML-Links in die bestehende Dokumentation (an relevante Stellen des Handbuchs, auf UML-Diagramme usw.). Dadurch werden Querbezüge sichtbar und gleichzeitig Dokumentationsaufwand und Wiederholungen in einem erträglichen Rahmen gehalten.
  • Quellen und übersetzte Programme in zip- bzw. jar-Files.
• Dokumentation jeglicher Anpassungsschritte an das genutzte Framework. Diese kann in die obigen Dokumente einfließen, beispielsweise im Klassendiagramm durch Oberklassen, sollen aber auch textuell begründet werden.
• Falls sich bereits Modellierungsänderungen gegenüber der vorigen Phase ergeben sollten, so sind diese ausführlich zu begründen und zu dokumentieren.

Der Prototyp soll im Wesentlichen die Rubrik "muß" der Prioritätenliste erfüllen.

Phase 4: Implementierung

In dieser Phase wird der Prototyp zum vollständigen Programm ausgebaut. Dabei sind in der Regel die Rubriken "muß" und "soll" der Prioritätenliste vollständig zu erfüllen. Abweichungen davon bitte frühzeitig mit Betreuer und Praktikumsleiter absprechen!

Die Ergebnisse aus der letzten Phase werden vervollständigt und aktualisiert. Auch hier gelten die gleichen Anmerkungen bezüglich der Ausführlichkeit der zu erstellenden Dokumentation.

Durchgeführte Tests gemäß Testplan mit korrekter Dokumentation in Testprotokollen stellen sicher, dass das Programm robust funktioniert. Erst mit erfolgreich abgeschlossenen Tests ist diese Phase beendet.

Phase 5: Wartung

In diese Phase werden verbliebene Fehler ausgemerzt und kleinere Ergänzungswünsche des Auftraggebers erfüllt. Es werden also alle in der Implementierungsphase noch nicht behobenen Fehler beseitigt, allgemein noch nicht befriedigende Arbeitsergebnisse überarbeitet und vervollständigt.

Durch Erfüllen zusätzlicher Anforderungen des Auftraggebers soll nachgewiesen werden, daß das erstellte Programm so entworfen und implementiert wurde, daß Änderungen ohne großen Aufwand möglich sind.

Bei entsprechender Zufriedenheit der Auftraggeber kann diese Phase teilweise oder ganz erlassen werden.

Endabnahme

Folgender Ablauf der Endabnahme ist vorgesehen:

• Zuerst präsentiert das Team gemeinsam in einer 10-minütigen Demo das erstellte Programm.
• Der Teamchef gibt dann anhand der erstellten Dokumente einen Überblick über Entwurf und Implementierung, insbesondere später notwendige Änderungen (5-10 Minuten).
• Anschließend erläutern die einzelnen Teammitglieder (jeder etwa 5 Minuten lang) ihren Entwicklungsbeitrag, indem sie ihn
  • in den Gesamtentwurf einordnen;
  • interessante Stellen / Probleme herausgreifen und erläutern;
  • Fragen zu Entwurf und Programmtext beantworten.
• In einer abschließenden Manöverkritik werden Erfahrungen ausgetauscht (vor allem konstruktive Verbesserungsvorschläge sind willkommen!).

5. Wichtige Informationen, Werkzeuge, Links

BSCW:

• pdf
• html

• Das JAVA-Applet JUploader unterstützt beim Hochladen mehrerer Dateien. Ordnerstrukturen werden _nicht_ unterstützt!
• Mithilfe des WebDAV-Protokolls kann die BSCW-Struktur z.B. unter Windows in den Explorer integriert werden. Damit können ganze Ordnerstrukturen hin und her verschoben werden. Eine Anleitung zum Einrichten der entsprechenden Netzwerkverbindung gibt es hier.

Framework:

Sämtliche Informationen zum Framework SalesPoint gibts hier zum Download. Die einander ergänzenden Beschreibungen sollen Ihnen den Einstieg in das Framework und in seine Verwendung erleichtern:

1. eine Übersicht, die an den Aufbau, die Komponenten und die Anpassungsschnittstelle heranführt;
2. die VideoMachine, welche die Verwendung anhand des relativ einfachen Beispiels "Videoverleihautomat" im Detail demonstriert und Ihnen als Modell für Ihre eigenen Entwicklungen dienen kann;
3. die javaDoc-Beschreibung des Frameworks, in die unter der Rubrik Hooks auch die Beschreibung der Anpassungsschnittstellen und ihrer Verwendung (in Form von "how to"-Rezepten) integriert ist.
4. eine erweiterte Form der Hooks, die HowTo's.

Alle Beschreibungen enthalten technische Anteile, die möglicherweise erst beim wiederholten Lesen oder aufgrund eigener Erfahrungen verständlich werden. Also öfter mal wieder zu Hand nehmen - das könnte sehr nützlich sein!Während die Übersicht und das Tutorial fortlaufend gelesen werden sollten, wird man die javaDoc-Beschreibung zum Nachschlagen und zur Klärung von Zweifelsfällen verwenden.

Werkzeuge und Links:

Es empfiehlt sich, bei der Anwendungsentwicklung die gleichen Werkzeuge einzusetzen, die auch bei der Entwicklung von Framework und Tutorial (und in den Übungen zur Einführungsvorlesung, siehe auch dort angegebene Links!) verwendet wurden:

• Java 2 SDK von Sun (JDK 1.4.2_05)
• Eclipse: eine frei erhältliche Java-IDE

• Java-Tutorials
• Java-Know-How und Links aus der Vorlesung im Frühjahrstrimester
• Umfassende Link-Sammlung für Java

Wenn Sie UML-Diagramme mit CASE-Werkzeugen erstellen und pflegen wollen, finden Sie hier zwei nützliche Systeme:

• Rational Rose Evaluationslizenzen UML-CASE-Tool
• Argo / UML an der University of California at Irvine entwickeltes freies UML-CASE-Tool

Wer WWW-Seiten pflegt, kann dazu den Netscape Composer verwenden oder sich gründlicher mit HTML befassen:

• SelfHTML ausführliche Beschreibung aller Aspekte von HTML
• Anleitung und Download-Seite zu einem nützlichen HTML-Editor (Freeware)

Die JUnit-Homepage ist eine sehr ergiebige Quelle zum Testen mit JUnit.

6. Literatur:

Eine kleine, subjektive Auswahl von Büchern, die für das Praktikum von Nutzen sein können:

1. J. Link: Softwaretests mit JUnit. dpunkt.verlag, 2005 (2.Aufl.). Einfache und gut strukturierte Einführung in das Testen mit JUnit.
2. D. Flanagan: Java (Examples) in a Nutshell. O'Reilly, 1999 (3. Aufl.). Kompetente Einführung in Java, viele Beispiele, systematische Klassenübersicht.
3. T. Budd: Understanding Object-Oriented Programming with JAVA. Addison-Wesley, 1998. Gute allgemeine Einführung in OOP mit Bezug zu Java (auch viele Beispiele).
4. E. Gamma, R. Helm, R. Johnson, J. Vlissides: Design Patterns. Addison-Wesley, 1995. Die Autoren (werden auch als "gang of four" bezeichnet) haben die "Pattern-Bewegung" mit diesem Buch eingeleitet. Das Buch stellt auch die OO Grundbegriffe klar und im Zusammenhang dar.
5. N. Wilkinson: Using CRC Cards. SIGS Books, 1995. Ausführliche Darstellung der CRC-Karten und ihrer Verwendung in allen Phasen der Entwicklung.
6. R. Wirfs-Brock, B. Wilkerson, L. Wiener: Objekt-Orientiertes Software-Design. Hanser-Verlag, 1993. Umfassende Einführung in OO Analyse und verantwortungsbezogenen Entwurf, beschreibt iteratives Vorgehen bei der Entwicklung: insgesamt OO-Vorgehen pur.
7. I. Sommerville: Software Engineering. Addison-Wesley, 1996. Eine prägnante Übersicht über alle Aspekte der Software-Entwicklung und der einschlägigen Techniken (nicht nur aus dem OO Bereich).

Fragen und Anregungen zu dieser Seite bitte an