Leitung: Florian Brieler
Priv.-Doz. Dr. Lothar Schmitz
Herbsttrimester 2006

Inhalt: [Allgemeines] [Betreuer] [Personen] [Phasen, Dokumente, Termine] [Beobachtungen] [Software und Tools] [Literatur] [Programmierpraktikum 2005]

 

Letzte Änderung dieser Seite: 20.11.2006
Aktuelle Änderungen werden immer rot und fett hervorgehoben, um besser kenntlich zu sein.

 

Allgemeines

Die in den Übungen zur Einführung in die Informatik I und II sowie OOP 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 nun lernen, in Teams von etwa 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 und Tests.

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

Außerdem steht Ihnen mit dem Frameworks SalesPoint und WebPoint jeweils 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.

Wichtig dabei: jedes Team wird genau eines der beiden Frameworks nutzen! Die folgenden Absätze beziehen sich meist nur auf SalesPoint, sind aber für WebPoint sinngemäß gleich.

[Übersicht]

 

Worauf der Betreuer achtet

Die Situation der 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 SalesPoint-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 mittel- und langfristig.

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 übersetzten Bibliotheken bereitgestellt.

Um die Koordination für den Betreuer zu erleichtern, wird auch die zu verwendende Software und Tools obligatorisch vorgegeben. Das sind (natürlich neben dem Framework und Java als Entwicklungssprache) Moodle, Eclipse, JUnit, SVN und Together. Weitere Informationen zu dieser Software sind weiter unten zu finden.

Zur Termintreue

Wie unten ausführlich dargestellt, zerfällt die Projektentwicklung in fünf aufeinanderfolgende Phasen, 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 Moodle-Seiten dokumentiert werden, so dass alle Änderungen so rasch wie möglich sichtbar werden (jeweils wenigstens einmal unter der Woche und jeweils 24 Stunden vor jeder Präsenation muss das Material zur aktuellen Phase eingestellt sein).
  • regelmäßig mündlich Bericht erstattet werden, und zwar wöchentlich zu den festgelegten Terminen. Details hierzu unter dem nächsten Punkt.

 


 

Zu den Präsentationen

Bei den wöchentlichen Zwischenpräsentationen und bei der Abschlusspräsentation soll jedes Teammitglied eingebunden sein und den eigenen Beitrag kurz vorstellen und ggfs. Fragen dazu kompetent beantworten. Sourcecode soll, mit Ausnahme von Phase 2, nur auf Anfrage gezeigt werden. Die Dauer einer Präsentation (mit Ausnahme der Abschlusspräsentation) sollte etwa 15 Minuten betragen, danach wird der Praktikumsleiter noch Fragen stellen und eigene Anmerkungen machen, sodass insgesamt etwa 30-45 Minunten pro Termin gerechnet werden können.

Bei den einzelnen Terminen geht es nicht darum, eine PowerPoint-Präsentation zu zeigen. Vielmehr soll anhand der Moodleseite (auf die natürlich zugegriffen werden kann) die Arbeit der letzen Woche dargestellt werden. Weitere Medien (wie Bilder o.Ä.) dürfen gerne benutzt werden, allerdings ist das erfahrungsgemäß nicht notwendig.

Ab Phase 2 entsteht in jeder Phase ein ausführbares Programm. Dieses muss immer gezeigt werden. Dabei empfiehlt es sich, die identifizierten Szenarien direkt am Programm nachzustellen, damit ein anschaulicher Eindruck vermittelt wird.

Die Abschlußpräsentation am Ende des Praktikums dauert eine Stunde je Team und dient der Abnahme der fertigen Arbeit. Die Teilnahme an allen Präsentation (wöchentlich und am Ende) ist für jedes Teammitglied verbindlich. Hierzu gibt es grundsätzlich keine Ausnahmen. Bei Nichtbeachtung erfolgt u.U. ein Ausschluss aus dem Praktikum.

Alle Präsentationen (die Endabnahme, die Zwischenberichte und die Phasenabschlüsse) sind von den Teams sorgfältig vorzubereiten. Insbesondere ist sicherzustellen, dass auf dem Vorführrechner im Electronic Classroom alles vor Beginn der Präsentation ablaufbereit vorliegt (ausführbares Programm!). Kennung und Passwort für diesen Rechner werden vom Praktikumsleiter zusammen mit den Lizenzschlüsseln für Together verschickt (siehe unten).

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öchten wir 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!

Die ersten Präsentationen finden ab der Woche vom 16. Oktober statt, danach wöchentlich bis zum Ende des Praktikums.

Zum "geistigen Eigentum"

Die offene Darstellung aller Zwischenergebnisse auf den Moodle-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, dass 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).

Sehen Sie sich in diesem Zusammenhang auch die Praktikumsseite des Vorgängerjahres an, sowie die Beispielseite Kühlschrankverwaltung, die auf dem Moodle-Server bereitliegt.

[Übersicht]

 

Die beteiligten Personen

Der Praktikumsleiter (Florian Brieler)

Der Praktikumsleiter ist für die Durchführung des Praktikums verantwortlich. Die wichtigste Aufgabe ist dabei die Kontrolle der Arbeitsleistung der Studenten und die entsprechende Vergabe der Scheine. Zu diesem Zweck werden laufend

  • die Zwischenergebnisse auf den Moodle-Seiten,
  • die gezeigte Termintreue und
  • die Arbeitsqualität beobachtet werden, und
  • die Betreuer nach ihrem Eindruck befragt werden.

 

 

Die Betreuer/Auftraggeber

 

 

Acht Studenten des Jahrgangs 2004, die im letzten Herbst selbst das Praktikum erfolgreich absolviert haben, übernehmen die Betreuung der Teams. Alle Betreuer haben gegenüber ihrem Team zwei Rollen:

  • als Vertreter des Auftraggebers handeln Sie mit den Teams die genaue Aufgabenstellung aus und lassen sich laufend über den Arbeitsfortschritt berichten.
  • als Berater stehen Sie den Teams jederzeit mit Rat zur Verfügung, wenn dort technische oder organisatorische Probleme auftreten, die nicht vom Team selbst gelöst werden können. Die Frameworkbeauftragten dienen insbesondere der Beantwortung technischer Fragen zu den Frameworks.

Tipp an die Teams: in Zweifelsfällen lieber frühzeitig die Betreuer fragen, als durch Mißverständnisse wertvolle Arbeitszeit zu verlieren! Es wird sehr empfohlen, dass jedes Team seinen Betreuer wenigstens einmal die Woche trifft, um den Fortschritt zu besprechen und Probleme zu lösen.
 

Die Studenten

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

  • der Chef des Teams koordiniert die Zusammenarbeit im Team und fungiert als Sprecher nach außen, insbesondere gegenüber dem Praktikumsleiter
  • der Stellvertreter des Chefs übernimmt dessen Aufgaben (bei Erkrankungen o.ä.)
  • der Dokumentar des Teams ist zuständig für eine einheitliche Darstellung der Webseiten (was durch Moodle sehr vereinfacht wird), und für die Benutzerhandbücher, die während der Projektentwicklung entstehen. Wichtig dabei ist aber, dass jedes Teammitglied den eigenen Beitrag selbst in Moodle einpflegt, um auch dem Dokumentar Zeit zum Entwickeln zu lassen.
  • der Testentwickler des Teams ist zuständig für die projektbegleitende Testentwicklung. Er arbeitet sich detailliert in das JUnit-TestFramework ein und erstellt zunächst anhand der konzeptionellen, später auch der programmiertechnischen Ergebnisse der einzelnen Phasen die Tests.

Sollten sich Hinweise mehren order auf Präsentationen der Eindruck entstehen, dass einzelne Teammitglieder ihren Beitrag nicht leisten, dann werden (nach Rücksprache mit dem Teamchef und Betreuer) diese Studenten durch den Praktikumsleiter abgemahnt und ggfs. aus dem Praktikum ausgeschlossen werden.
Ein solches Verhalten ist äußerst unkameradschaftlich, da es Kommilitonen Zusatzarbeit aufbürdet. Teamchefs dürfen dies im Interesse der anderen Teammitglieder nicht dulden!
 

Gruppe INF 1

Thema: Fernsehprogramm (SalesPoint)
Tutor: Matthias Kugler
Präsentation: Donnerstag 8:15 (EC)
Links: [Homepage] [SVN]

Gruppe INF 2

Thema: Fahrzeugverleih (SalesPoint)
Tutor: Danilo Ebert
Präsentation: Montag 7:15 (EC)
Links: [Homepage] [SVN]

Gruppe INF 3

Thema: Tierarztpraxis (SalesPoint)
Tutor: Danilo Ebert
Präsentation: Dienstag 7:15 (EC)
Links: [Homepage] [SVN]

Gruppe INF 4

Thema: Studentenparty (WebPoint)
Tutor: Daniel Woithe
Präsentation: Freitag 9:00 (EC)
Links: [Homepage] [SVN]

Gruppe INF 5

Thema: Werkstatt (SalesPoint)
Tutor: Daniel Borkowitz
Präsentation: Donnerstags 9:00 (EC)
Links: [Homepage] [SVN]

Gruppe INF 6

Thema: Online-Pizzabestellung (SalesPoint)
Tutorin: Marianna Schmidt
Präsentation: Montag 13:00 (EC)
Links: [Homepage] [SVN]

Gruppe INF 7

Thema: BSV Sport Frei (WebPoint)
Tutorin: Maria Raabe
Präsentation: Dienstag 18:00 (EC)
Links: [Homepage] [SVN]

Gruppe INF 8

Thema: Panono (WebPoint)
Tutorin: Maria Raabe
Präsentation: Dienstag 18:45 (EC)
Links: [Homepage] [SVN]

Gruppe WINF 1

Thema: Restaurantverwaltung (SalesPoint)
Tutorin: Marianna Schmidt
Präsentation: Montag 13:45 (EC)
Links: [Homepage] [SVN]

Gruppe WINF 2

Thema: Fitnessstudio (WebPoint)
Tutor: Daniel Woithe
Präsentation: Donnerstag 16:00 (EC)
Links: [Homepage] [SVN]

Gruppe WINF 4

Thema: Kino (SalesPoint)
Tutor: Daniel Borkowitz
Präsentation: Donnerstag 16:45 (EC)
Links: [Homepage] [SVN]

Gruppe WINF 5

Thema: Getränkekellerverwaltung (SalesPoint)
Tutor: Torben Hardt
Präsentation: Montag 14:30 (EC)
Links: [Homepage] [SVN]

Gruppe WINF 6

Thema: Pimp and Buy (SalesPoint)
Tutor: Sebastian Schulze
Präsentation: Dienstag 19:30 (EC)
Links: [Homepage] [SVN]

Die Ansprechpartner für die Technik

Für Fragen zu Java: der jeweilige Betreuer der Gruppe

Für Fragen zu SalesPoint: Torben Hardt, Sebastian Schulze und Matthias Kugler

Für Fragen zu WebPoint: Maria Raabe und Daniel Woithe

Bei Fragen zum Zugang zum EC: Christa Beckh

Bei Fragen betreffend den Zugang zu Moodle (Kennungen und Passwörter): Florian Brieler

 


[Übersicht]

 

 

Phasen, Dokumente, Termine

Das Praktikum wird in fünf aufeinanderfolgenden Phasen durchgeführt, wobei für jede Phase maximal zwei Wochen vorgesehen sind. Das Praktikum beginnt mit der Einführungsveranstaltung. Tipp: die Erfahrung aus den letzten Jahren zeigt, dass insbesondere Phase 2 gut geeignet ist, um eine Woche einzusparen.

Jeweils (allerspätestens!) eine Woche vor dem Ende einer Phase muß ein wesentlicher Teil erledigt und auf den Moodle-Seiten dokumentiert sein.

Die Moodle-Dokumentation ist phasenweise organisiert. 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.

Zum Schluß erfolgt noch eine Endabnahme, mit der das Praktikum dann vorbei ist.

Wichtig: Die Ergebnisse, die während der Präsentationen erarbeitet werden, insbesondere die Anmerkungen des Praktikumsleiters, sind mitzuprotokollieren und auf den Moodleseiten zu veröffentlichen. Dabei soll es ein einzelnes Dokument für jede Präsentation geben.

Desweiteren ist für jede Phase ein weiterer Punkt Chancelog auf der Moodle-Seite anzugeben. Hier soll dann in Form eines Textdokumentes für die einzelnen Ergebnisse der jeweiligen Phase aufgelistet werden, wann Änderungen daran durchgeführt wurden (mit Datum, Wochentag und Uhrzeit) und wie weit der aktuelle Bearbeitungsfortschritt ist. Zu den Ergebnissen zählen z.B. Szenarien, Handbuch, JavaDoc, Programmieren, etc. Dabei reicht eine sehr grobe Unterteilung, z.B. in nicht bearbeitet - angefangen - zur Hälfte fertig - fast fertig - fertig aus. Auf der Seite steht dann z.B.
 

  • Donnerstag, 12.10., 16.34Uhr: Drei neue Szenarien hinzugefügt(Kunde anlegen, Kunde bearbeiten, Kunde löschen). Status Szenarien: fast fertig
  • Montag, 16.10., 17:45Uhr: Kapitel 1, 2.2, 2.3 und 4 im Handbuch überarbeitet. Status Handbuch: zur Hälfte fertig
  • etc...


Sinn dieser Einteilung ist es, zum einen ehrlich gegenüber sich selbst den aktuellen Fortschritt zu dokumentieren, und auch dem Praktikumsleiter zu helfen, die präsentierten Zwischenergebnisse besser einschätzen zu können und zu sehen, was sich seit dem letzten Besuch auf der Seite verändert hat.

 

 

Dabei soll das Changelog nur immer verlängert werden. Es ist nicht notwendig oder sinnvoll, Einträge zu löschen.

 

 

Phase 1: Analyse

Zweck dieser Phase ist es, das gestellte Thema vollständig zu durchdringen, seine Möglichkeiten auszuloten und die Anforderungen des Auftraggebers zu erkennen. Die Reihenfolge der Arbeitsschritte, mit denen Sie sich der Aufgabe nähern, ist sehr wichtig, da jeder folgende Schritt auf die Ergebnisse und das Wissen aus dem vorigen Schritt aufbaut. Deswegen ist es von besonderer Wichtigkeit, die unten angegebenen Dokumente der Phase 1 auch in der Reihenfolge auszuarbeiten. Wichtig ist auch zu beachten, dass die Arbeit und die Ergebnisse in dieser Phase unabhängig vom Framework sind, mit dem Sie sich erst später beschäftigen werden.

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 Szenario soll so detailliert wie möglich beschreiben, welche einzelnen Programmeinheiten und -datenstrukturen beteiligt sein werden. Aus der in den Szenarien dokumentierten 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. Moodle bietet dafür entsprechende Funktionalität.
  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, dass die Entwickler seine Interessen im Auge haben.
  5. Legen Sie diese Arbeitsergebnisse (CRC-Karten, Ablaufprotokolle zu Szenarien, Prioritätenliste) dem Auftraggeber vor. Klären Sie mit ihm Zweifelsfälle ab und verhandeln Sie über die Prioritäten,  die am Ende(!) der Analysephase "verbindlich" festgelegt werden - nicht vorher, sonst ist es sinnlos, weiter zu analysieren.
  6. Erstellen Sie auf der Basis der bisherigen Ergebnisse
    • ein vorläufiges, aber ausführliches Benutzerhandbuch (hier kann bisher Vergessenes auftauchen);
    • ein UML-Klassendiagramm, welches die statischen Zusammenhänge der gefundenen Kassen beschreibt; dokumentieren Sie diese Zusammenhänge und vernachlässigen Sie die Prozesssicht in UML-Klassendiagramm. Relevant sind hier die Organisation der Informationen.
    • zu den komplizierteren Anwendungsfällen UML-Sequenzdiagramme bzw. UML-Aktivitätsdiagramme.
    • einen Testplan, der zumindest alle identifizierten Uses Cases sowie kritische funktionale Anforderungen abdeckt.
    Die Dokumentation dieser Phase soll für den Kunden, d.h. für Laien lesbar sein. Vermeiden Sie daher programmiertechnische Termini und verwenden Sie die Sprache des Anwendungsbereichs (z.B. bei Klassennamen).
  7. Revidieren Sie anhand der zusätzlichen Dokumente Ihre Prioritätenliste und legen Sie alles nochmals dem Auftraggeber zur Zustimmung vor.

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

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

Phase 2: Einarbeitung

Ziel der Einarbeitungsphase ist es, sich mit dem SalesPoint/WebPoint-Framework vertraut zu machen. Dazu soll das Tutorial und die kleine Beispiel-Applikation "Videoverleihautomat" durchgearbeitet und etwas modifiziert werden. Verwenden Sie die ersten Tage dieser Phase, um sich intensiv in die Framework-Dokumentation einzuarbeiten (alles ansehen, besonders gründlich die Überblicksseiten und das Tutorial).

Danach soll der "Videoverleihautomat" überarbeitet 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!). Die zu bearbeitende Videomaschine, das Framework, die Aufgabenstellung etc. finden Sie im Abschnitt Software.

Folgende Ergebnisse sollen in dieser Phase erzielt werden:

  • Lösungen zu den (Pflicht-)Aufgaben, detailliert dargestellt und mit Java-Code versehen (siehe hierzu auch java2html im Bereich Software).
  • UML-Klassendiagramme zum modifizierten Videoverleihautomaten. Der Übersicht willen muss es mehrere Teildiagramme geben. Hierfür eignen sich z.B. die einzelnen SalesPoints. Ferner soll farbig markiert sein, welche Klassen neu erstellt bzw. verändert wurden.
  • Quellen als ZIP-Archiv, das übersetzte Programm als JAR bzw. WAR.
  • javadoc-Dokumentation der modifizierten Quellen, die online zu Betrachten ist (siehe hierzu auch das entsprechende Kapitel im Moodle-Handbuch).
  • Kurzgefasstes Handbuch, in dem alle Menüpunkte kurz erläutert werden und ein paar Screenshots zur Illustration zu sehen sind.

 

 

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. Dabei ist ein genauer Abgleich zwischen dem Analyseergebnis und der Beschreibung des Frameworks erforderlich, um festzustellen

  • welche der geforderten Funktionen das Framework abdeckt
  • welche weiteren Funktionen es nach Anpassungen abdeckt, und wie diese Anpassungen genau aussehen
  • 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 dabei sind:

  • die Festlegung konkreter Katalogs- und Bestandsklassen
  • die Umsetzung von Anwendungsfällen in Prozessen (Unterklassen von SaleProcess), anschaulich unterstützt durch Zustandsübergangsdiagramme.
  • die Darstellung von Katalogen und Beständen in der grafischen Oberfläche, nebst Sortierung und Filterung
  • die Bereitstellung von Operationen über Menüpunkte und Knöpfe (Buttons), wobei das Benutzerhandbuch entsprechend zu aktualisieren oder neu zu erstellen ist

Dokumentieren Sie ausführlich die Gründe für Ihre Anpassungsentscheidungen. Falls sich bereits Änderungen gegenüber der Analysephase ergeben (was durchaus vorkommen kann), sind diese auch zu erläutern, mit Referenz auf die Ergebnisse dieser Phase und einer Begründung für die geänderte Struktur.
 

Unabhängig von der verwendeten Sprache (deutsch oder englisch) für den Programmcode sind die gängigen Konventionen einzuhalten:

  • Klassennamen beginnen mit einem Großbuchstaben, Paketnamen mit einem Kleinbuchstaben
  • getter und setter werden nicht übersetzt, also z.B. nicht holeName statt getName

 

 

In dieser Phase fallen folgende Ergebnisse an:

 

 

  • das Ergebnis des Abgleichs mit der Analysephase: Klassenbeschreibungen und statisches Klassendiagramm einschließlich textueller Dokumentation (Konzepte, Zusammehänge). Dies ist ein sehr wichtiges Ergebnis und muss dementsprechend ausführlich dargestellt sein.
  • ein Arbeitsplan: welcher Entwickler ist für welche Klassen zuständig, und wann ist der Termin für die Fertigstellung
  • ein aktualisiertes und sehr detailliertes Benutzerhandbuch mit Screenshots und vollständiger Menübeschreibung
  • Zustandsübergangsdiagramme zu den erstellten Prozessen (jedes Gate soll hierbei als Zustand dargestellt werden, jede Transition als Pfeil. Knöpfe werden durch Trigger modelliert)
  • ein aktualisierter Testplan sowie Testprotokolle und ggfs. Testklassen der am Prototypen bereits durchgeführten Tests. Grundsätzlich ist jede nicht durch SalesPoint/WebPoint bereitgestellte Funktionalität angemessen zu testen!
  • Ausführliche javadoc-Dokumentation mit Erläuterungen zur Implementierung (mit Beschreibung von allen Klassen, Attributen, Parametern, Methoden, Rückgabewerten und Ausnahmen). Zusätzlich soll der Zusammenhang zur Aufgabe und zur technischen Dokumentation hergestellt werden, und zwar in Form von HTML-Links in die bestehende Dokumentation auf den Moodle-Seiten (an relevante Stellen des Handbuchs, auf UML-Diagramme, etc). Dadurch werden Querbezüge sichtbar und gleichzeitig Dokumentationsaufwand und Wiederholungen in einem erträglichen Rahmen gehalten
  • die Quellen als .zip Datei das übersetzte Programme als ausführbare .jar Datei bzw. als .war Datei auf dem Tomcat-Server
  • Dokumentation jeglicher Anpassungsschritte an das genutzte Framework. Diese kann in die obigen Dokumente einfließen, beispielsweise im Klassendiagramm durch Oberklassen, soll 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 das Muss der Prioritätenliste erfüllen. Ferner ist darauf zu achten, dass das eigene Programm in sinnvolle Pakete eingeteilt wird (das default-Package darf nicht verwendet werden). Insbesondere die Testklassen sollen in ein eigenes Paket kommen.
 

Phase 4: Implementierung

In dieser Phase wird der Prototyp zum vollständigen Programm ausgebaut. Dabei ist (neben dem Muss aus der vorigen Phase) nun auch das Soll der Prioritätenliste vollständig zu erfüllen.

Die Ergebnisse aus der letzten Phase werden dabei vervollständigt und aktualisiert (in Moodle sollen allerdings nicht nochmals alle Ergebnisse der vorigen Phase wiederholt werden, sondern nur solche Dinge, die verändert wurden oder neu hinzugekommen sind). Bezüglich der Ausführlichkeit der zu erstellenden Dokumentation gelten die gleichen Anmerkungen wie auch zuvor. Durchgeführte Tests gemäß Testplan, sowie korrekte Dokumentation in Testprotokollen, stellem außerdem sicher, dass das Programm robust funktioniert. Erst mit erfolgreich abgeschlossenen Tests kann diese Phase beendet werden.

Phase 5: Wartung

In diese Phase werden verbliebene Fehler ausgemerzt und kleinere Ergänzungswünsche des Auftraggebers erfüllt (z.B. Teile aus dem Kann der Prioritätenliste). Ferner werden alle in der Implementierungsphase noch nicht behobenen Fehler beseitigt, und noch nicht befriedigende Arbeitsergebnisse überarbeitet und vervollständigt.

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

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

Endabnahme

Die Endabnahme ist keine Phase im eigentlichen Sinne, sondern bildet vielmehr den Abschluss des Programmierpraktikums. Folgender Ablauf ist dafür vorgesehen:

  • Zuerst präsentiert das Team gemeinsam in einer 10-15 minütigen Demo das erstellte Programm. Hierbei soll nicht die gesamte Funktionalität gezeigt werden, sondern nur eine kleine Auswahl. Eine Art Rollenspiel, in der die Teammitglieder verschiedene Szenarien nachspielen, ist ideal.
  • Der Teamchef gibt dann anhand der erstellten Dokumente einen Überblick über Entwurf und Implementierung, insbesondere später notwendige Änderungen (5-10 Minuten).
  • Anschließend erläutern die einzelnen Teammitglieder (jeder etwa 5 Minuten lang) ihren Entwicklungsbeitrag, indem sie
    • diesen in den Gesamtentwurf einordnen,
    • interessante Stellen/Probleme herausgreifen und erläutern,
    • und ggf. Fragen zu Entwurf und Programmtext beantworten.
  • In einer abschließenden Manöverkritik werden Erfahrungen ausgetauscht (vor allem konstruktive Verbesserungsvorschläge sind Willkommen!).

Es ist darauf zu achten, sich an die gegebenen Zeitvorgaben zu halten!

[Übersicht]

 

Beobachtungen

Als Praktikumsleiter möchte ich diese Stelle nutzen, um Dinge zu schildern die mir häufig auffallen, entweder während der Präsentationen oder auf den Moodle-Seiten. Auf diese Weise hoffe ich die Qualität der Arbeit der Praktikumsteilnehmer zu verbessern. Entsprechend bitte ich um Beachtung.

  • Bei manchen Gruppen sind die Use-Case-Diagramme nicht durch einen zusätzlichen Text beschrieben. Das ist nicht gut und erschwert das Verständnis. Deshalb soll jedes Diagramm, egal in welcher Phase, mit einer aussagekräftigen Beschreibung versehen werden. Eine Ausnahme bilden die CRC-Karten (wenn man die überhaupt als Diagramm ansehen möchte). Hier gibt es extra ein Feld für die Beschreibung, welches knapp, aber präzise ausgefüllt werden sollte.
  • Zwischen Use-Case-Diagrammen, Szenarien und CRC-Karten bestehen enge Konsistenzen: Jedes Szenario muss auch als Anwendungsfall in einem Use-Case-Diagramm vorkommen, und die Aktoren sind selbstverständlich die gleichen. Genauso muss jeder einzelne Schritt in einem Szenario in der entsprechenden CRC-Karte reflektiert sein. Hier ist daher die Funktion zur Umwandlung der Szenarien in CRC-Karten sehr zu empfehlen.
  • Bei den meisten Gruppen ist die Gesamtfunktionalität nicht in einem Use-Case-Diagramm dargestellt, sondern in mehreren, meist drei oder vier. Die Gruppierung erfolgt anhand zugehöriger Anwendungsfälle, z.B. Benutzerverwaltung, o. ä. Ein Übersichts-Use-Case-Diagramm zeigt dabei genau diese Gruppierungen auf und ist zur Orientierung sehr hilfreich.
    Dieses Vorgehen ist zu empfehlen und sollte von allen Gruppen durchgeführt werden, weil Übersichtlichkeit und Änderbarkeit stark davon profitieren.
  • Immer wieder kommt es zu Tippfehlern auf den Moodle-Seiten. Zu einem kleinen Teil ist das verständlich und unvermeidlich. Trotzdem möchte ich darauf hinweisen, sorgfältig zu arbeiten, um unnötige Fehler zu vermeiden.
  • In den vergangenen Wochen fehlten wegen Urlaubs überraschend viele Teammitglieder bei den wöchentlichen Präsentationen, teilweise sogar ohne sich bei mir abzumelden. Das mittlerweile erreichte Ausmaß kann von mir nicht mehr toleriert werden. Deshalb ist Urlaub in Zukunft kein Grund mehr, den Präsentationen fernzubleiben. Das bisherige Fehlen bleibt dennoch ohne Konsequenzen. Diese Regelung ist gültig ab Montag, den 06.11.
  • Eclipse stellt ja die Möglichkeit zur Verfügung, trotz bestehender Fehler ein Programm auszuführen. Ich empfehle, diese Möglichkeit nicht zu nutzen, sondern lieber die Fehler im Programm zu beseitigen. Außerdem scheint es bei einer Gruppe Probleme zu geben, wenn das Language Pack installiert ist. Hier weigert sich Eclipse, ein Programm mit Fehlern auszuführen.
  • Für die Darstellung von Quelltext gilt folgendes: ab 5 Zeilen wird das ganze mit Java2Html dargestellt, damit die Übersichtlichkeit gewahrt wird. Was ich ab sofort nicht mehr sehen möchte ist die Verwendung von Screenshots um Quelltext darzustellen.

 


[Übersicht]

 

 

Software und Tools

Framework:

Sämtliche Informationen zum Framework SalesPoint gibt es auf der Projekt-Homepage. 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, welche die Verwendung anhand des relativ einfachen Beispiels "Videoverleihautomat" im Detail demonstriert und Ihnen als Modell für Ihre eigenen Entwicklungen dienen kann. Die Einarbeitungsaufgaben für Phase 2 finden Sie hier (SalesPoint).
  • die JavaDoc-Beschreibung des Frameworks, sowie die HowTo's, die weitere Informationen bereithalten.

Alle Informationen zu WebPoint sind hier zu finden, die entsprechenden Einführungsaufgaben für Phase 2 hier.
 

Alle Beschreibungen enthalten technische Anteile, die möglicherweise erst beim wiederholten Lesen oder aufgrund eigener Erfahrungen verständlich werden, daher gilt: öfter mal wieder zur Hand nehmen - das ist sehr nützlich! 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:

Ein unbedingtes Muss ist die Verwendung der gleichen Version von jeder Software für alle Teammitglieder.

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

JUnit sowie Dokumentation ist auf der offiziellen Homepage zu finden. Sogar ein Eclipse-Plugin ist verfügbar, welches allerdings nicht eingesetzt werden muss. Das Testen mit JUnit soll ausführlich dokumentiert werden. Ein kurzes Beispiel ist hier zu finden. Auch auf den Praktikumsseiten der Gruppen des letzten Jahres sind viele gute Testpläne zu finden.
 

Für Subversion gibt es gleichfalls ein Eclipse-Plugin, welches auch zu verwenden ist, weil es die Arbeit mit dem Repository sehr erleichtert. Das Plugin ist auf der Homepage zu finden, und enthält einen vollständigen Client, sodass keine weitere Software benötigt wird.

Für den Betrieb von Moodle ist keine spezielle Software notwendig, ausser einem Browser. Diesen Sommer wurde im Rahmen einer Studienarbeit die Oberfläche von Moodle an das Design der Uni angepasst. Außerdem wurden einige Erweiterungen für das Programmierpraktikum erstellt, insbesondere eine Unterstützung für Szenarien und CRC-Karten. Eine detailierte Beschreibung dazu finden Sie hier (Version 1.2).

Insbesondere in der Einarbeitungsphase kann es notwendig sein, Quelltext auf den Moodle-Seiten zu präsentieren. Damit dieser ordentlich formatiert dargestellt wird, empfiehlt sich sehr der Einsatz von Tools wie Java2Html, die Java-Code in sauber formatierten, eingefärbten Html-Code umsetzen. Es gibt zwei unterschiedliche Varianten von Java2Html:

  • Java2Html.de wandelt einzelne .java Dateien in Html um, und unterstützt dabei auch Java5.
  • Java2Html.com kann ganze Projekte umwandeln und auch verlinken, unterstützt allerdings kein Java5 oder neuer.

javadoc und jar:

Für javadoc gibt es eine sehr praktische, aber relativ unbekannte Funktion um im eigenen javadoc automatisch auf andere javadocs zu verlinken, z.B. auf das vom SDK oder auf das von SalesPoint bzw. WebPoint. Dafür gibt es den Kommandozeilenparameter -link url. Unter Windows sieht das dann z.B. so aus:

javadoc.exe -d docs -sourcepath src -link http://java.sun.com/j2se/1.5.0/docs/api/ -link http://www2.cs.unibw.de/tools/SalesPoint/v3.2/documentation/javadoc/ -link http://www2.cs.unibw.de/tools/WebPoint/javadoc/ -use org.package1 org.package2

Damit man unabhängig vom eigenen Rechner wird ist es ratsam, auf WWW-Adressen zu verweisen. Das Beispiel hier verweist nun auf das Java SDK, SalesPoint und WebPoint. Verwendet man Eclipse, um das javadoc generieren zu lassen, so muss man im ant-file zwischen die <javadoc>-Tags noch <link>-Tags einfügen. Das sieht dann z.B. so aus:

<javadoc ...>
    <link href="http://java.sun.com/j2se/1.5.0/docs/api/"/>
    <link href="http://www2.cs.unibw.de/tools/SalesPoint/v3.2/documentation/javadoc/"/>
    <link href="http://www2.cs.unibw.de/tools/WebPoint/javadoc/"/>
</javadoc>

Beim Erstellen des javadoc ist eine der beiden Möglichkeiten anzuwenden. Außerdem soll das javadoc immer so erstellt werden, dass alle Informationen sichtbar werden, auch solche, die als private deklariert sind.

Um mit jar ein ausführbares Archiv zu erstellen muss man eine Reihe von Schritten durchführen. Zunächst braucht man ein sog. Manifest. Das ist eine Textdatei beliebigen Namens, z.B. manifest.mf. Da drin steht, vollständig referenziert, die Klasse, in der die main-Methode zu finden ist, gefolgt von einer Leerzeile (wichtig!), z.B.

Main-Class: org.demo.MeinMain
(hier die Leerzeile)

Gehen wir nun davon aus, dass sich alle .class Dateien im Unterverzeichnis bin befinden, dann sieht der notwendige jar-Aufruf unter Windows etwa so aus:

jar.exe cvfm video.jar manifest.mf -C bin .

Wenn man nun noch externe .jar Dateien in seinem Projekt braucht (so wie bei uns SalesPoint oder JUnit), dann muss man diese erst entpacken (das geht mit jar.exe oder einem normalen zip-Entpacker), und die .class Dateien, die darin enthalten sind, auch in bin kopieren (und dabei natürlich deren Ordnerstruktur beibehalten). Am Aufruf für jar.exe ändert sich dadurch nichts.

Together Control Center:

Das Together Control Center ist sehr mächtiges, kommerzielles UML-Modellierungstool. Wir verfügen wir über eine Campus-Lizenz. Der notwendige Lizenz-Schlüssel wird auf Anfrage an den Praktikumsleiter an die Gruppenchefs weitergegeben. Wichtig ist, dass der Lizenz-Schlüssel nur für den Einsatz hier an der Uni gemacht ist, und die Uni auf keinen Fall verlassen darf. Die Weitergabe an Dritte (wozu natürlich keine Studenten hier zählen) ist untersagt.
Die Software kann hier heruntergeladen werden.

Die Bedienung von TCC, insbesondere die Konfiguration, ist teilweise umständlich gelöst. Um beispielsweise einzustellen, wie viele Details in einem Klassendiagramm angezeigt werden, muss man in dem Menü Tools -> Optionen -> Diagram Level unter View Management das Diagram detail level umstellen.
Will man in einem Klassendiagramm Properties nutzen bzw. nicht mehr nutzen (getter-/setter-Methoden werden dann nicht dargestellt, dafür bekommt das Klassensymbol ein kleines Rechteck rechts oben angezeigt), dann kann man das unter Tools -> Optionen -> Default Level unter View Management -> JavaBeans / C++ Properties mit dem Häckchen bei Recognize JavaBeans einstellen.

Vorträge:

Hier finden Sie die Vorträge, die bei der Einführungsveranstaltung gehalten wurden:

 


[Übersicht]

 

 

Literatur

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

  • J. Link: Softwaretests mit JUnit. dpunkt.verlag, 2005 (2.Aufl.). Einfache und gut strukturierte Einführung in das Testen mit JUnit.
  • 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).

 


[Übersicht]