Programmierpraktikum HT07

Leitung: Dipl. Inform. Daniel Volk

Die Projektphasen

[Analyse] [Einarbeitung] [Design] [Implementierung] [Wartung]

Die Analysephase

Ziel:

Ziel dieser Phase ist es, das gestellte Thema vollständig zu durchdringen, seine Möglichkeiten auszuloten sowie die Anforderungen des Auftraggebers zu erkennen und letztendlich aus diesen Informationen ein stabiles Analysemodell zu erstellen. Wichtig ist auch zu beachten, dass die Arbeit und die Ergebnisse in dieser Phase domänenspezifisch und damit unabhängig von der Technik (Framework) sind.

Vorgehensweise:

Die Reihenfolge der Arbeitsschritte, mit denen Sie sich der Aufgabe nähern ist nicht unerheblich, da jeder Schritt auf den Ergebnissen und dem Wissen des vorangegangenen Schrittes aufbaut. Deswegen ist es auch elementar, die unten angegebenen Artefakte in genau dieser Reihenfolge auszuarbeiten. Als Hilfestellung kann Ihnen auch die erste Übung (v.a. auch das Beiblatt!) der Vorlesung zur Objektorientierten Programmierung dienen.

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 auch ihren realen Benutzern zu.
Spielen Sie auf Basis von CRC-Karten (Papier-Version!) konkrete Szenarien zu diesen Anwendungsfällen durch und protokollieren Sie diese mit. Die Szenarien sollen hierbei konkrete, vorstellbare Abläufe innerhalb des Programms widerspiegeln, also z.B. "Nicht registrierter Kunde sendet Photoauftrag per Post ein". Jedes Szenario beschreibt also so detailliert wie möglich, welche Schritte zur Erfüllung einer spezifischen Aufgabe notwendig sind und welche Objekte an diesem Ablauf teilhaben.
Iterieren Sie nun so lange über Schritt 1 und 2, bis sich ein stabiles Analysemodell herauskristallisiert (sie also merken, dass keine neue Funktionalität mehr hinzu kommt).
Erst wenn Sie alle möglichen Aspekte in den bisher angegeben Schritten behandelt haben, ordnen Sie die gefundene Funktionalität in einer aus Anwendersicht(!) priorisierten, vorläufigen MUSS-SOLL-KANN-Liste (MSK-Liste) an, wobei Sie hier entscheiden sollten,
- was das zu erstellende Programm auf jeden Fall leisten muss
- was es darüber hinaus leisten soll
- 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 jedoch beim Auftraggeber mit einem konkreten Vorschlag Erwartungen weckt, sollte man zumindest prinzipiell deren Umsetzbarkeit durchdacht haben. Aus Auftraggebersicht sollte der Plan zudem ein attraktives Produkt mit abgerundeter Funktionalität skizzieren. Das ein oder andere geplante "Highlight" zeigt dem Kunden zusätzlich, dass 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.
Extrahieren Sie nun Klassendiagramme, welche die statischen Aspekte der bisherigen Ergebnisse beschreiben. Dokumentieren Sie die Zusammenhänge und vernachlässigen Sie die Prozesssicht im UML-Klassendiagramm - relevant ist hier die Organisation der Informationen.
Extrahieren Sie mit Sequenz- und Aktivitätsdiagrammen die dynamischen Aspekte der komplizierteren Anwendungsfälle. Erstellen Sie aber bitte keine Dokumentation zum Selbstzweck - anhand der Diagramme sollte auch etwas vermittelt werden!
Erstellen Sie auf der Basis der bisherigen Ergebnisse ein vorläufiges Testhandbuch, welches die bis dato ersichtlichen Fehlerquellen (siehe Use-Cases und Szenarien) im Programmablauf sowie die kritischen funktionalen Anforderungen aufzeigt.
Weiterhin erstellen Sie ein ein vorläufiges, aber ausführliches Benutzerhandbuch, welches den anskizzierten Funktionsumfang textuell aus Anwendersicht beschreibt.
Überarbeiten Sie anhand der zusätzlichen Dokumente Ihre Prioritätenliste und legen Sie alles nochmals dem Auftraggeber zur Zustimmung vor.

Produkte:

Zwischenpräsentation: Use-Cases, CRC-Karten (in eingescannter Form!), Szenarien (in einfacher Textform, aber mit Einrückungen), vorläufige MSK-Liste
Endpräsentation: Klassen-, Sequenz-, Aktivitätsdiagramme, Benutzer- und Testhandbuch, "endgültige" MSK-Liste

Hinweise:

Binden Sie in den oben genannten Schritten auf jeden Fall ihren Auftraggeber ein (v.a. auch bei den CRC-Kartensitzungen) - nur so können Sie Aspekte abzuprüfen, welche in der Aufgabenstellung nur angedeutet sind, oder noch ganz fehlen könnten!
Die Dokumentation dieser Phase muss für den Kunden (d.h. für Laien) lesbar sein. Technische Termini sind demzufolge nicht zulässig - verwenden Sie einfach die Sprache des Anwendungsbereichs (z.B. bei Klassennamen).
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!
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 auch Funktionen an, die Sie leicht implementieren können.

Die Einarbeitungsphase

Ziel:

Ihnen steht mit dem Frameworks SalesPoint und WebPoint jeweils bereits 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. Dementsprechend ist es Ziel der Einarbeitungsphase, Ihnen die Gelegenheit zu geben, sich sowohl mit dem SalesPoint/ WebPoint-Framework, als auch mit den Entwicklungswerkzeugen im Allgemeinen vertraut zu machen.

Vorgehensweise:

Um Ihnen den Einstieg in die Materie zu erleichtern bzw. um Ihnen einen Überblick über die genutzten Entwicklungswerkzeuge zu geben, finden am Anfang der Einarbeitungsphase von Seiten der Tutoren Einführungsvorträge statt. Die genauen Örtlichkeiten und Termine werden rechtzeitig bekanntgegeben - die Teilnahme an den Veranstaltungen ist Pflicht!
Im nächsten Schritt sollten Sie sich nun einen Überblick über die zwei zur Verfügung stehenden Frameworks verschaffen und im Teamrahmen auswählen, welches der beiden sie nutzen möchten.
Nach dieser Entscheidung, sollten Sie sich zunächst intensiv mit der jeweiligen Framework-Dokumentation auseinandersetzen. Die entsprechenden Dokumente finden Sie auf der SalesPoint- bzw. WebPoint-Seite. Für das SalesPoint-Framework wird empfohlen, sich zunächst den "technischen Überblick" und dann den "Großen Beleg" im Dokumentations- Bereich anzusehen; einen Überblick über das WebPoint-Framework bieten am ehesten die beiden zugehörigen Studienarbeiten.
Arbeiten Sie nun im nächsten Schritt das jeweilige Tutorial der "Videoverleihautomat" Beispiel-Applikation durch, welches Ihnen erste praktische Einblicke in das Framework gibt und Sie Schritt für Schritt an die genutzte Technik heranführt.
Danach soll nun der "Videoverleihautomat" überarbeitet werden. Gehen Sie dabei analog zum jeweiligen Tutorial vor, wo auch alle benötigten Techniken beschrieben sind. Dokumentieren Sie die entsprechenden Schritte auf ihren Web-Seiten (laufend!). Die Aufgabenstellungen für beide Frameworks finden Sie im Dokumentenbereich des Praktikums.

Produkte:

Lösungen zu den Aufgabenstellungen, detailliert dargestellt und mit Java-Code versehen (siehe hierzu auch Java2HTML).
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 (und funktionstüchtige!) Programm als JAR bzw. WAR sowie die JavaDoc-Dokumentation der modifizierten Quellen als ZIP-Archiv und in einer Online-Version.

Hinweise:

Die Einarbeitungsaufgaben können zwar gleichmäßig auf alle Teammitglieder aufgeteilt werden, es wird aber trotzdem erwartet, dass die Lösungen von allen nachvollzogen und verstanden wurden (entsprechende Fragen sind bei der zugehörigen Präsentation zu erwarten).

Die Designphase

Ziel:

Ziel dieser Phase ist es, die initiale Gesamtstruktur der Implementierung zu entwerfen. Hierzu wird das nichttechnische Analysemodell der ersten Phase in die technische Welt übertragen - es entsteht ein auf dem jeweiligen Framework aufbauendes, technisches Designmodell.

Vorgehensweise:

Es ist zunächst 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 an Ergänzungen notwendig ist, und wie diese einzubinden sind

Hinsichtlich der Verantwortlichkeiten der in der Analysephase gefundenen Klassen müssen dabei solchen Klassen des Frameworks identifiziert werden, die eben dies schon leisten, oder solche anwendungsspezifische 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, sowie die anschauliche Modellierung komplexer Abläufe mit Hilfe von Sequenzdiagrammen

Dokumentieren Sie hierbei ausführlich die Gründe für Ihre Auswahl- und 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.

Produkte:

das Ergebnis des Abgleichs mit der Analysephase: Klassenbeschreibungen und Klassendiagramme einschließlich textueller Dokumentation (Konzepte, Zusammehänge) - dies ist ein sehr wichtiges Ergebnis und muss dementsprechend ausführlich dargestellt werden sein.
Zustandsübergangsdiagramme zu den erstellten Prozessen (jedes Gate soll hierbei als Zustand dargestellt werden, jede Transition als Pfeil. Knöpfe werden durch Trigger modelliert) und Sequenzdiagramme zu komplexen Abläufen.
ein aktualisiertes Testhandbuch, welches nun neben allgemeinen Fehlerquellen der Programmnutzung (aus der Analysephase) mögliche Unzulänglichkeiten der technischen Umsetzung (primär auf Ebene von Funktionsblöcken) aufdeckt und beschreibt, wie die Software hierauf abzuprüfen ist. Hierbei ist zu bedenken, dass vor allem jede zusätzliche Funktionalität angemessen zu testen ist!
Falls sich bereits Modellierungsänderungen gegenüber der Analysephase ergeben sollten, so sind diese ausführlich zu begründen und zu dokumentieren. Vor allem aber sind jegliche Anpassungsmaßnahmen des genutzten Frameworks sowie zusätzliche Anteile zu dokumentieren. Dies kann bereits in die obigen Dokumente einfließen, muss aber auch textuell begründet werden.

Die Implementierungsphase

Ziel:

Das Ziel der Implementierungsphase ist die iterative Umsetzung des Designmodells in ein funktionierendes Programm.

Vorgehensweise:

Entsprechend der in der MSK-Liste festgelegten Priorisierung wird nun schrittweise das anskizzierte Programm implementiert. Hierbei werden in dieser Phase 2-3 Iterationen durchlaufen, welche in den Zwischenpräsentationen vorgestellt werden. Der erste Durchlauf umfasst diesbzgl. mind. den MUSS-Anteil, der zweite Durchlauf mind. den SOLL-Anteil. Die Iterationen ihrerseits folgen dabei dem Zyklus Implementierung, Evaluation und Re-Design, wobei die Evaluation sowohl das Testen auf technischer Ebene (funktioniert das Programm?), als auch die Nutzertests (entspricht das Programm den Erwartungen?) umfasst. Das Re-Design bezieht sich auf Modellanteile, deren Design sich im Laufe der Implementierung noch anpasst - dies lässt sich auch mit intensiver Designphase nicht ganz vermeiden und muss dokumentiert werden.

Produkte:

Zwischenpräsentationen:

ein Arbeitsplan, aus welchem ersichtlich ist, welcher Entwickler für welche Klassen zuständig, und wann der Termin für die Fertigstellung ist (kann in die MSK-Liste integriert werden)
die Quellen als ZIP-Archiv, das übersetzte (und funktionstüchtige!) Programm als JAR bzw. WAR
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 Web-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
ein aktualisiertes Testhandbuch (welches nun auch die Funktionstests der einzelnen Klassen umfasst) sowie Testprotokolle und ggfs. Testklassen der bereits durchgeführten Tests
die aktualisierte Modellanteile der vorherigen Phase - die Darstellung und Erläuterung der Änderungen genügt hier

Zusätzlich Endpräsentation: Das fertige Benutzerhandbuch zum Programm

Hinweise:

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"

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.

Die Wartungsphase

Ziel:

Ziel dieser Phase ist die Korrektur noch verbliebener Programmfehler (so gut wie immer), das Einarbeiten von Ergänzungs- oder Änderungswünschen des Auftraggebers (häufig) und die Umsetzung evtl. notwendiger Optimierungsmaßnahmen (selten).

Vorgehensweise:

Die Wartungsphase ist jedoch im eigentlichen Sinne nicht als Phase des Entwicklungsprozesses zu verstehen, sondern entspricht eher einer weiteren Implementierungsiteration bzw. einem erneuten Durchlaufen aller Phasen (mit Ausnahme der Einarbeitung). Die genaue Ausgestaltung der Wartung ist hier schlicht abhängig von der Art der Änderung. Im Falle kleinerer Implementierungsfehler wird eine kurze, zusätzliche Phase der Implementierung meist ausreichend sein, ist der Fehler tiefgreifender wird ein Re-Design notwendig, handelt es sich dagegen um größere Änderungswünsche von Seiten des Kunden (bzw. um Analysefehler), ist ein vollständiges Durchlaufen aller Phasen angezeigt. Kurzum ist der Fehler umso dramatischer, je früher er passiert ist - arbeiten Sie deswegen insbesondere in der Analyse- und Designphase besonders umsichtig, um sich in der Wartungsphase Arbeit zu ersparen!

Produkte:

Die Artefakte dieser Phase sind abhängig von ihrer Ausgestaltung und entsprechen mind. der Implementierungs-, evtl. auch der Design- und Analysephase.

Hinweise:

Durch Erfüllen zusätzlicher Anforderungen des Auftraggebers wird u.a. auch nachgewiesen, dass das erstellte Programm so entworfen und implementiert wurde, dass Änderungen ohne großen Aufwand möglich sind (bedenken Sie dies bitte in der Designphase).

zurück