Programmierpraktikum

Dipl.-Inform. Volker Renneberg
Herbsttrimester 2003

Das Praktikum beginnt

am Montag, den 6.10.2002, um 13:00 (s.t.!!!) Uhr
in Geb. 33 / HS 3331 (gemäß Stundenplan)

mit einer Einführung, bei der u.a. die Teameinteilung endgültig festgelegt werden soll.

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

0. News

Datum	News

6.11.2003	Aktualisierung der Phasendokumentation, insbesondere Herausstellung der Wichtigkeit der zu erstellenden Dokumentation
	Damit die Dateien durch den WWW-Server erreichbar sind, müssen die Rechte ordentlich eingetragen sein. Dieses kann in der Shell für Dateien folgendermaßen gesetzt werden(rw-r--r--): chmod 644 dateien Für Directories reicht folgender Befehl(rwx-r-xr-x): chmod 755directories

1. Worum geht es?

Die in den Übungen zur Einführung in die Informatik I - III behandelten Programmieraufgaben lassen sich wie folgt charakterisieren:

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.

Im Programmierpraktikum sollen Sie lernen, in Teams von 6 - 7 Studenten praxisnahe Aufgaben systematisch anzugehen. Diese Aufgaben sind

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.

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

abwickeln sollen. Damit die Projekte trotz dieser schwierigen Rahmenbedingungen erfolgreich durchgeführt werden können, sind die folgenden Regelungen unbedingt einzuhalten!

Zum Framework

Aus folgenden Gründen ist die möglichst weitgehende Verwendung des Frameworks bindend vorgeschrieben:

Durch das Framework ist eine Grundarchitektur vorgegeben. Das erleichtert den für Unerfahrene schwierigen OO Entwurf.
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.
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.

Zur Termintreue

Wie unten ausführlich dargestellt, zerfällt die Projektentwicklung in fünf aufeinanderfolgende Phasen (Einarbeitung, Analyse, ..., 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.

Ein Unterschreiten des Zeitplans ist erlaubt, sogar erwünscht!

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ß

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äsentation muß das Material zur aktuellen Phase eingestellt sein);
regelmäßig mündlich Bericht erstattet werden, und zwar am Freitag zum Phasenende und genau eine Woche vorher, jeweils ca. 20 Minuten 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 genauen Präsentationstermine sind mit den Betreuern und der Praktikumsleitung rechtzeitig abzustimmen. 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. Für die Vorträge bietet sich die Verwendung von PowerPoint an.

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&oouml;sungen zu verwenden. Wichtigstes Ziel ist es, daß alle möglichst viel lernen - und dies bei den Pr%auml;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)! Als Vorbild für den Inhalt nehmen Sie bitte die Ergebnisse des letzten Jahres, insbesondere die Gruppe 6 und 10 (inhaltlich) und für das Layout Gruppe 11.

3. Die beteiligten Personen

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

a) Der Praktikumsleiter (Auftraggeber) (Volker Renneberg)

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.

Meine Kommentare und Hinweise werde ich in der Regel über die Betreuer an die Teams weitergeben lassen.

b) Die Betreuer

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

Tobias-Uwe Kuhn (Gruppen Inf-4(4) und Inf-5(5))
Martin Fuchs (Gruppen Inf-3(3) und Inf-6(6))
Daniel Schakols (Gruppen Inf-7(7) und Inf-8(8))
Michael Dunker (Gruppen WInf-1(10) und WInf-2(11))
Michael Rapp (Gruppen WInf-3(12))
Volker Förster (Gruppen Inf-1(1) und Inf-2(2))
Florian Brieler (Gruppen Inf-9(9))

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.

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 6 - 7 Studenten, die alle als Entwickler arbeiten und einzeln für bestimmte Programmteile, deren Entwicklung und Dokumentation verantwortlich sind. Das Team ordnet dreien 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 &uubml;berarbeitet, verlinkt, versioniert und sichert.

Die insgesamt 9 (Inf) + 3 (Winf) 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. Hier finden Sie die aktuelle, mit dem Jahrgangsältesten abgestimmte Gruppeneinteilung.

Sollte ich Hinweise bekommen oder auf Präsentationen den Eindruck bekommen, daß einzelne Teammitglieder ihren Beitrag nicht leisten, dann werde ich (nach Rücksprache mit dem Teamchef und Betreuer) diese Studenten abmahnen und ggfs. aus dem Praktikum ausschließen.
Ein solches Verhalten empfinde ich als äußerst unkameradschaftlich, da es Kommilitonen Zusatzarbeit aufbürdet. Teamchefs dürfen dies im Interesse der anderen Teammitglieder nicht dulden!

Die WWW-Seiten der Gruppen:

Gruppe 1 (Inf-1) (Aufgabe: GoKart-Bahn, Tutor: Volker Förster)
Gruppe 2 (Inf-2) (Aufgabe: Börse, Tutor: Volker Förster)
Gruppe 3 (Inf-3) (Aufgabe: Fitnessstudio, Tutor: Martin Fuchs)
Gruppe 4 (Inf-4) (Aufgabe: Film- und Regieunterstützung, Tutor: Tobias-Uwe Kuhn)
Gruppe 5 (Inf-5) (Aufgabe: Bauernhof mit Landwirtschaft, Tutor: Tobias Uwe-Kuhn)
Gruppe 6 (Inf-6) (Aufgabe: Campingplatz, Tutor: Martin Fuchs)
Gruppe 7 (Inf-7) (Aufgabe: Zeit- und Spesenerfassungssystem, Tutor: Daniel Schakols)
Gruppe 8 (Inf-8) (Aufgabe: Glücksspiel, Tutor: Daniel Schakols)
Gruppe 9 (Inf-9) (Aufgabe: Mensa, Tutor: Florian Brieler)
Gruppe 10 (WInf-1) (Aufgabe: Bulletin-Boards, Tutor: Michael Dunker)
Gruppe 11 (Winf-2) (Aufgabe: Berghütte, Tutor: Michael Dunker)
Gruppe 12 (Winf-3) (Aufgabe: Photogeschäft, Tutor: Michael Rapp)

Weitere Links sind im folgenden zu finden:

Die Raumplanung des EC's für Vorführungen hat dieses Jahr Ronny Trautsch übernommen.
Von den folgenden Aufgaben können Sie in Absprache mit mir eine auswählen. Wer zuerst mit der Einführungsphase komplett fertig ist und das von mir bestätigt bekommen hat, "mahlt" zuerst. VORSICHT: Änderungen möglich!!!

d) Die Ansprechpartner für die Technik

Als Ansprechpartner für technische Fragen betreffend das Framework fungieren Herr Philipp Appelhoff und Herr Michael Rapp. Bei Fragen zu Java können Sie sich auch an Ihre Tutoren wenden.

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

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

Phase	Beginn am	Ende am
1: Einarbeitung	1.10.	17.10.
2: Analyse	18.10.	31.10.
3: Design & Prototyp	1.11.	14.11.
4: Implementierung	15.11.	28.11.
5: Wartung	29.11.	12.12.

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.

Nun zu den einzelnen Phasen:

Phase 1: Einarbeitung

Ziel der Einarbeitungsphase ist es, sich mit dem SalesPoint/EPoint-Framework vertraut zu machen. Dazu soll das Tutorial und die kleine Beispiel-Applikation "Videoverleihautomat" (SalesPoint), bzw. "TicketService" (EPoint) durchgearbeitet und etwas modifiziert werden. Die Vorgaben für die Modifikationen am Videoverleihautomten finden Sie hier (pdf) und die für den TicketService sind hier zu finden.

Für beide Frameworks gibt es Dokumentation. Die des SalesPoint-Frameworks (hier) ist bereits sehr ausgereift, die des EPoint-Frameworks (hier) ist in den ersten Versionen vorhanden. Letztere wird in näherer Zukunft überarbeitet und ausgebaut. Da die Struktur des EPoints stark an die des SalesPoints, was Cataloge, Prozesse und GUI angeht, angelehnt ist, sollten sich die Nutzer des EPoints erst einen groben Überblick des SalesPoint-Frameworks verschaffen.

Verwenden Sie die erste Tage, um sich intensiv in die Framework-Dokumentation einzuarbeiten (Alles ansehen, besonders gründlich die Überblicksseiten und das Tutorial) und um Organisatorisches zu erledigen:

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

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 und C.5. Alle anderen Aufgaben können zur weiteren Übung auch bearbeitet werden. Die erste Zwischenpräsentation soll am 10.10. stattfinden. Die zu bearbeitende Videomaschine, das Framework, etc. finden unter "Wichtige Informationen".

Die Verteilung der endgültigen Themen zu Beginn von Phase 2 erfolgt nach Fertigstellungstermin (und Qualität) des Ergebnisses von Phase 1. Benachrichtigen Sie daher Ihren Betreuer und den Praktikumsleiter, sobald folgende Entwicklungsdokumente auf Ihren WWW-Seiten abrufbar vorliegen:

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).

Vereinbaren Sie einen Präsentationstermin zur Abnahme des Phasenergebnisses.

Phase 2: Analyse

Die individuellen Themen werden von mir an die Teams ausgegeben, sobald sie die Einarbeitungsphase erfolgreich (einschließlich aller Dokumentation im Netz) abgeschlossen haben. Wer zuerst kommt, hat die grö&szlilg;te Auswahl an Themen!

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 2 auch in der Reihenfolge auszuarbeiten.

Gehen Sie wie folgt vor.

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.
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.
Suchen Sie nach Aspekten, die in der Aufgabenstellung nur angedeutet sind oder ganz fehlen könnten. Behandeln Sie diese analog.
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.
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.
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.
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).
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 englische Bezeichnungen. Halten Sie Ihre Webseite und die darin befindliche Dokumentation allerdings 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 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).

Dokumentieren Sie ausführlich die Gründe für Ihre Anpassungsentscheidungen. Falls sich bereits Änderungen gegenüber der vorigen Phase ergeben, sind diese auch zu erläutern, mit Referenz auf die Ergebnisse der vorigen Phase und einer Begründung der geänderten Struktur.

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;
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.

Ausgiebige Tests mit anschaulichen Testdaten stellen sicher, daß das Programm robust funktioniert (die Daten werden für Vorführungen ohnehin benötigt).

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 (Teilnehmer: das Team, sein Betreuer und der Praktikumsleiter):

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 10 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

Framework:

Sämtliche Informationen zum Framework SalesPoint sind über diese Seite zugänglich. Die einander ergänzenden Beschreibungen sollen Ihnen den Einstieg in das Framework und in seine Verwendung erleichtern:

eine Übersicht , die an den Aufbau, die Komponenten und die Anpassungsschnittstelle heranführt;
die VideoMachine, das die Verwendung anhand des relativ einfachen Beispiels "Videoverleihautomat" im Detail demonstriert und Ihnen als Modell für Ihre eigenen Entwicklungendienen kann;
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.
Eine erweiterte Form der Hooks, die HowTo's finden Sie unter: 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&aauml;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:

Sehr viel Wissenswertes über Java und OO allgemein ist auf folgenden Seiten zusammengetragen worden:

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

Seit einiger Zeit verfügen wir über eine Together-Campuslizenz. Die Sekretäre interessierter Gruppen mögen sich bitte an Frau Beckh wenden! Nachdem Sie sich die Lizenz besorgt haben, können Sie die Software hier herunterladen:

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)

Zum Einloggen in die Homeverzeichnisse

(athene.informatik.unibw-muenchen.de) wird ssh benötigt. Für Windows eignet sich dieser Client, da er neben dem Terminallogin auch eine Dateitransferumgebung bereitstellt. Für Unix-Systeme bietet sich OpenSSH an.

6. Literatur:

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

D. Flanagan: Java (Examples) in a Nutshell. O'Reilly, 1999 (3. Aufl.). Kompetente Einführung in Java, viele Beispiele, systematische Klassenübersicht.
T. Budd: Understanding Object-Oriented Programming with JAVA. Addison-Wesley, 1998. Gute allgemeine Einführung in OOP mit Bezug zu Java (auch viele Beispiele).
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.
N. Wilkinson: Using CRC Cards. SIGS Books, 1995. Ausführliche Darstellung der CRC-Karten und ihrer Verwendung in allen Phasen der Entwicklung.
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.
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).