Programmierpraktikum

Dr. Lothar Schmitz
Herbsttrimester 1999

Das Praktikum beginnt

am Montag, den 4.10.99, um 13.00 Uhr
in Geb. 33 / HS 0401

mit einer Einführung, bei der u.a. die Teameinteilung vorgenommen 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 5 -6 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.

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 noch am gleichen Tag erscheinen;
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.

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

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 5 - 6 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 Sekretär 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 8 Teams sollen möglichst leistungsähnlich sein (also nicht Teams aus lauter Starken oder lauter Schwachen). Bitte schlagen Sie mir als Praktikumsleiter möglichst bald eine vollständige Teameinteilung vor. Falls wider Erwarten keine vernünftige Einteilung zustande kommt oder Streitigkeiten entstehen, behalte ich mir Änderungen vor.

Die WWW-Seiten der Gruppen:

Raumplanung EC für Vorführungen

Fehlermeldungen zum Framework

b) Die Betreuer

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

Stephan Gambke (WB 2 / Zimmer 328)
foxtrott@Xterminator.StudFB.Unibw-Muenchen.de
Michael Hesse (WB 2 / Zimmer 303)
micha@Xterminator.StudFB.Unibw-Muenchen.de

Stephan Klaus (WB 2 / Zimmer 104)
anakin@Xterminator.StudFB.Unibw-Muenchen.de

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.

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

Herr Gambke übernimmt noch eine zusätzliche Rolle wahr:

er ist Ansprechpartner für technische Fragen betreffend das Framework und Java. Sollte er eine Frage selbst nicht beantworten können, leitet er sie an den Frameworkentwickler, Herrn Zschaler, weiter, der sich z. Zt. in den USA aufhält.
Informationen zum Framework von Herrn Gambke

c) Der Praktikumsleiter

Als Praktikumsleiter bin ich für die Durchführung des Praktikums verantwortlich. In Vorbereitung des Praktikums haben Herr Zschaler, Herr Gambke, Herr Matznick (im Rahmen ihrer Studienarbeit) und ich das Framework und seine Dokumentation komplett überarbeitet. Durch diese verbesserte Grundlage soll die Bearbeitungszeit während des Praktikums gesenkt werden.

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 ihre Zwischenergebnisse auf den WWW-Seiten, die gezeigte Termintreue und 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	04.10.	22.10.
2: Analyse	25.10.	05.11.
3: Design & Prototyp	08.11.	19.11.
4: Implementierung	22.11.	03.12.
5: Wartung	06.12.	17.12.

Jeweils (allerspätestens!) eine Woche vor Phasenende (also zur Zwischenpräsentation) muß ein wesentlicher Teil erledigt und auf den WWW-Seiten dokumentiert sein. Ein Unterschreiten des Zeitplans ist erlaubt, sogar erwünscht! Zum Schluß erfolgt die Endabnahme.

Nun zu den einzelnen Phasen:

Phase 1: Einarbeitung

Ziel der Einarbeitungsphase ist es, sich mit dem SalesPoint-Framework vertraut zu machen und damit eine kleine Beispiel-Applikation "Gästekonto" zu entwickeln.

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 das "Gästekonto" entsprechend nachfolgener Spezifikation entwickelt werden. Gehen Sie dabei analog zum Tutorial vor, wo auch alle benötigten Techniken beschrieben sind. Erstellen Sie entsprechende Dokumente und legen Sie sie ins Netz (auch schon im halbfertigen Zustand; laufend dort aktualisieren!). In der Präsentation am 15.10. soll ein Prototyp vorgeführt werden, bei dem man Konten einrichten, abfragen und Geld abheben kann. Bis zum Phasenende sollen das Einzahlen, die Änderung des Paßworts, die Protokollierung aller Vorgänge und das Auflösen der Konten ergänzt werden.

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 das fertige Programm und sämtliche Entwicklungsdokumente auf Ihren WWW-Seiten abrufbar vorliegen.

Gästekonto

In Urlaubsgebieten gibt es manchmal Banken, die "Gästekonten" anbieten. Ein solches Gästekonto richtet man ein, indem man am Bankschalter einen Betrag einzahlt und ein Paßwort für das Konto vereinbart. Am Bankautomaten kann man rund um die Uhr - nach Anmeldung mit Name und Paßwort - den Kontostand erfragen und Geld abheben. Ist die Bank geöffnet, dann kann man am Schalter zusätzlich Geld einzahlen und das Paßwort ändern. Es gibt weder Kontogebühren noch Guthabenzinsen.

Ein Konto wird gelöscht:

sobald es kein Guthaben mehr ausweist oder
drei Monate nach seiner Eröffnung; das Restguthaben fällt dann an die Bank.

Den gesetzlichen Vorschriften entsprechend protokolliert die Bank alle Vorgänge mit.

Phase 2: Analyse

Die Verteilung der individuellen Themen an die Teams findet am

Montag, den 25.10. um 15.15 Uhr
im Gebäude 33 / HS 0401

statt.

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:

Identifizieren Sie anhand der Themenbeschreibung einige wichtige Anwendungsfälle.
Spielen Sie konkrete Szenarien zu diesen Anwendungsfällen durch (mitprotokollieren!) und stellen Sie dabei CRC-Karten auf (ebenfalls aufschreiben).
Suchen Sie nach Aspekten, die in der Aufgabenstellung nur angedeutet sind oder ganz fehlen könnten. Behandeln Sie diese analog.
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ß;
- was es darüber hinaus leisten soll;
- welche Dinge es noch leisten kann, wenn dafür die Entwicklungszeit reicht.
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.
Revidieren Sie anhand der zusätzlichen Dokumente Ihre Prioritätenliste und legen Sie alles nochmals dem Auftraggeber zur Zustimmung vor.

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 stehen, 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
- Quellen und übersetzte Programme in zip- bzw. jar-Files.

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

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.

5. Wichtige Informationen

Framework:

Sämtliche Informationen zum Framework SalesPoint sind über diese Seite zugänglich. Bitte lesen Sie dort alles (außer evtl. den Veröffentlichungen) durch, denn es ist gut, die einschlägigen Begriffe und die Motivation hinter dem Framework-Ansatz zu kennen, wenn man sinnvoll damit arbeiten will.

Drei einander ergänzende Beschreibungen sollen Ihnen den Einstieg in das Framework und in seine Verwendung erleichtern:

eine Übersicht (zum Ausdrucken gedacht!), die an den Aufbau, die Komponenten und die Anpassungsschnittstelle heranführt;
das Tutorial, das die Verwendung anhand des ("abgespeckten") Beispiels "FastFood-Restaurant" im Detail demonstriert und Ihnen als Modell für Ihre eigenen Entwicklungen dienen 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.

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

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
Tutorial eine kürzere Einführung in HTML (ausdruckbare Version)

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, 1997 (2. 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.