Programmierpraktikum

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 fuer 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:
  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.

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ß

  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äsentation muß das Material zur aktuellen Phase eingestellt sein);
  2. 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 Phasenabschliessen 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übert. 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)! 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 ü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:

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!!!
  • Hier können Sie einen Blick auf die Praktika der vergangenen Jahre werfen.

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öß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.

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

  1. eine übersicht , die an den Aufbau, die Komponenten und die Anpassungsschnittstelle heranführt;
  2. die VideoMachine, das die Verwendung anhand des relativ einfachen Beispiels "Videoverleihautomat" im Detail demonstriert und Ihnen als Modell für Ihre eigenen Entwicklungendienen 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 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ä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:

Seit einiger Zeit verfügen wir über 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:

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

Praktikum: SalesPoint V3.1 Homepage EPoint 1.0 Einführungsvortrag (Praktikumsleiter) Einführungsvortrag I (SalesPoint) Einführungsvortrag II (SalesPoint) Einführungsvortrag (EPoint)
SalesPoint Framework v3.1

Fragen und Anregungen zu dieser Seite bitte an

Volker Renneberg