Programmierpraktikum

Dr. Lothar Schmitz
Herbsttrimester 2001


Das Praktikum beginnt

    am Montag, den 1.10.2001, um 13.15 Uhr
    in Geb. 33 / HS 0401

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

Inhalt dieser Seite:

1. Worum geht es?
2. Worauf achten die Betreuer?
3. Die beteiligen Personen
4. Phasen, Dokumente und Termine
5. Wichtige Informationen


 

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 zwei Tage 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. eine Viertelstunde 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.
 

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 beteiligen Personen

 

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

 

a) 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 ggfs. redaktionell überarbeitet, verlinkt, versioniert und sichert.

Die insgesamt 10 (Inf) + 2 (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.

Die WWW-Seiten der Gruppen:

 

  •  
    •  
        • Von den folgenden Aufgaben können Sie unter den ersten zwölf 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!!!.

      •  

      b) Die Betreuer

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

      Jens Ferchland (Gruppen 1 und 9)

      Dirk Grambow (Gruppen 5 und 7)

      Robert Koch (Gruppen 3 und 6)

      Mirko Pracht (Gruppen 4 und 10)

      Tom Triebsees (Gruppen 2 und 8)

      Daniel Volk (Gruppen 11 und 12)

      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 !

      Als Ansprechpartner für technische Fragen betreffend das Framework und Java fungiert Herr

      Stephan Moritz

      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 Herrmann

      c) Der Praktikumsleiter

      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.

       

      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!

       

      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 Montag Ende am Freitag
      1: Einarbeitung 01.10. 19.10.
      2: Analyse 22.10. 02.11.
      3: Design & Prototyp 05.11. 16.11.
      4: Implementierung 19.11. 30.11.
      5: Wartung 03.12. 14.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-Framework vertraut zu machen. Dazu soll die kleine Beispiel-Applikation "Videoverleihautomat" aus dem Tutorial durchgearbeitet und etwas modifiziert werden. Jede Gruppe soll andere Modifikationen durchführen; entsprechende Vorgaben finden Sie im Home-Verzeichnis Ihrer Gruppe.

      Verwenden Sie die erste Woche, 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
      In der zweiten und dritten Woche 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!). Sobald Sie das Beispiel bis einschließlich der "Rückgabe der Videos" bearbeitet haben, soll der Prototyp präsentiert werden (spätestens am 12.10.). Bis zum Phasenende sind die restlichen Abschnitte zu bearbeiten.

      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 es, das gestellte Thema vollständig zu durchdringen, seine Möglichkeiten auszuloten und die Anforderungen des Auftraggebers zu erkennen.

      Gehen Sie wie folgt vor:

       

       

       

       

      1. Identifizieren Sie anhand der Themenbeschreibung einige wichtige Anwendungsfälle.
      2. Spielen Sie konkrete Szenarien zu diesen Anwendungsfällen durch (mitprotokollieren!) und stellen Sie dabei CRC-Karten auf (ebenfalls aufschreiben).
      3. Suchen Sie nach Aspekten, die in der Aufgabenstellung nur angedeutet sind oder ganz fehlen könnten. Behandeln Sie diese analog.
      4. 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.
      5. 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;
        • zu den kompliziertesten 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.

      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).
      In dieser Phase fallen folgende Ergebnisse an:
      • Ergebnis des Abgleichs: Klassenbeschreibungen und statisches Klassendiagramm;
      • 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;
      • 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.
      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.

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

      Framework:

      Sämtliche Informationen zum Framework SalesPoint sind über diese Seite zugänglich.

      Drei einander ergänzende 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. das Tutorial, 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.
      Alle drei 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 kurzem verfügen wir über wir über eine Together-Campuslizenz. Die Sekretäre interessierter Gruppen mögen sich bitte an Herrn Aschenbrenner 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.
       

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

       

      SalesPoint Framework v3.0

      Fragen und Anregungen zu dieser Seite bitte an

      Dr. Lothar Schmitz

      Last modified: 01.10.2001