|
|
|
Softwarepraktikum im Sommersemester 2003
Grundlagen betrieblicher Informationssysteme
Subsections
Zu den Besprechungen sollen immer drei von einer Gruppe kommen, und zwar aus
jedem Zweier-Team einer. Die Zweier-Teams wechseln sich ab, so dass am Ende
jeder ungefähr gleich oft bei einer Besprechung teilgenommen hat.
Für jede Aufgabe gibt es einen bestimmten Abgabetermin. Für manche Aufgaben
auch einen Zwischenabgabetermin. Eine Übersicht findet sich in Abschnitt
6. Ungefähr zwei Tage nach jeder (Zwischen)abgabe wird diese
besprochen.
Die Zwischenabgaben sind nicht bewertet. Mit ihnen soll festgestellt werden, wie
gut das Praktikum bei den einzelnen Gruppen vorangeht. Bei Problemen kann so
rechtzeitig eigegriffen werden. Der Abgabetermin soll eingehalten werden, es ist
natürlich nicht notwendig, zu diesem Zeitpunkt schon vollständige Dokumente zu
haben.
Die Abgaben fließen mit in die Gruppenbewertung ein. Bei einer verspäteten
Abgabe werden 25% der Punkte abgezogen, bei mehr als einem Tag Verspätung 50%,
bei mehr als zwei Tagen 100%.
Alle Dokumente müssen in einem druckbaren Format (Postscript oder PDF) bis zum
Abgabetermin an den jeweiligen Betreuer der Gruppe geschickt werden
(Gruppennumer bei der Abgabe nicht vergessen!).
Nach der Besprechung werden die Abgaben im Web (Uni-intern)
veröffentlicht. Details hierzu finden sich in Abschnitt 3.2.
3.2 Veröffentlichen der Abgaben im Web
Für jede Gruppe wird ein Verantwortlicher bestimmt,
auf dessen Account ein eigenes lokales WWW-Verzeichnis für Dokumentationen
angelegt wird. Die Einstiegsseite wird dann über einen Link auf der zentralen
Seite zugänglich gemacht. Die Seiten können lokal von allen gelesen werden, sind
aber nicht im gesamten WWW verfügbar. Besonders ist darauf zu achten, das
die Dateirechte richtig gesetzt werden. Siehe auch Abschnitt5
Auch das Bereitstellen der Abgaben im Web gehört zum Praktikum!.
Sie sollten, wenn möglich, Design Patterns einsetzen. Einige Beispiele für
Design Patterns sind hier genannt.
- Erzeugungsmuster
- Abstrakte Fabrik (Abstract Factory)
- Erbauer (Builder)
- Singleton
- Strukturierungsmuster
- Adapter
- Fliegengewicht (Flyweight)
- Verhaltensmuster
- Beobachter (Observer)
- Besucher (Visitor)
- Strategie (Strategy)
In Abschnitt 4 sind einige Verweise zu Webseiten über Design
Patterns aufgelistet. Der Aufwand, sich einige Patterns mal anzuschauen lohnt
sich. Es ist besser, schon bekannte und erfolgreiche Lösungen zu
verwenden, als das Rad neu erfinden zu müssen. Ein Hinweis in der Dokumentation
auf die Verwendung eines Patterns wird es anderen Entwicklern sehr erleichtern,
sich in den Code einzuarbeiten.
Es müssen natürlich nicht alle der genannten Muster eingesetzt werden,
und möglicherweise findet man ein nützliches, aber hier nicht aufgeführtes
Muster, das man auch einsetzen kann.
Versuchen Sie, folgender Intention zu folgen:
- Trennung zwischen der Strategie zur Erzeugung und dem Vorgang der
eigentlichen Erzeugung, sowie der tatschlichen Repräsentation von
Objekten,
- Abstraktion von konkreten Tabellen des DB-Schemas und der
Anfragesprache SQL,
- Kapselung der Datenbankschnittstelle, um später auch andere DBS
unterstützen zu können.
Die grafische Benutzerschnittstelle sollte nicht nur die Möglichkeit geben, die
Verarbeitung zu starten, zu beenden und zu unterbrechen, sondern auch
Informationen über deren Fortschritt zur Verfügung stellen. Dazu ist es notwendig,
etwas über den Zustand anderer Klassen, bzw. ihrer Objekte zu erfahren.
Beachten Sie aber die Kapselung der Objekte! Prüfen Sie daher auch die
Einsatzmöglichkeit des Observer-Patterns. Java bietet dafür spezielle
Unterstützung.
Es ist eine Komponente zu erstellen, die den Inhalt der erzeugten Datenbank
visualisiert. Sie kann eingesetzt werden, um die Datenbank gegen die
Anforderungen aus der Spezifikation zu validieren. Hierbei ist zweierlei zu
beachten.
Zum einen soll die Verteilung der Attribute überprüft werden. Es sollte daher
möglich sein, statistische Information über das Minimum, das Maximum, den
Mittelwert, Anzahl der von Null verschiedenen Tupel und Anzahl der
voneinander verschiedenen Werte zu erhalten. Anhand einer entsprechenden
grafischen Darstellung soll ferner gezeigt werden, dass die gewählte
Zufallsfunktion wirklich eine Gleichverteilung der Attributwerte erzeugt, d. h.
jede Ausprägung ist mit ungefähr der gleichen Anzahl vorhanden. Zur Darstellung
sind geeignete Diagramme anzubieten (z. B. Torten-, Linien-, Balken- oder
Blockdiagramme) und dem Benutzer zur Auswahl anzubieten. Da es gilt, eine
sehr große Anzahl von Daten auszuwerten, sind sinnvolle Maßnahmen zur
Skalierung vorzusehen. Auch die Auswahl eines Anzeigebereichs
(Zoom-Funktion) erscheint hier sinnvoll. Stichproben, also die Auswahl eines
zufälligen Tupels aus einer vorgegeben Tabelle, sollten ebenso unterstützt
werden wie die gezielte Auswahl anhand einer ID. Die grafischen Elemente und
Realisierungsaspekte sind dabei allerdings der grafischen Benutzeroberfläche
zuzuordnen.
An verschiedenen Stellen des Systems ist es notwendig, auf Informationen über
das zugrundeliegende Schema zuzugreifen. Beispielsweise soll in der GUI bei der
Visualisierung der Daten bei Auswahl einer Tabelle automatisch eine
Auswahlbox mit den zugehörigen Attributen gefüllt werden. Es hat sich hier als
äußerst praktisch erwiesen, diese Metadaten in einer eigenen Hilfskomponente
bereitzuhalten, die bei Bedarf diese Informationen liefern kann. Da es sich dabei
um Schemainformationen handelt, wird diese Komponente sinnvollerweise der
DB-Komponente angegliedert. Die Implementierung kann in einer recht
primitiven Weise erfolgen, jedoch sollte dabei darauf geachtet werden, dass
Änderungen im Schema nachgezogen werden müssen.
- Verständliche Darstellung
- Dazu gehört eine angemessene Notation und
Struktur, sowie vollständige und konsistente Dokumente.
- Minimale Darstellung
- "`Minimal"' bedeutet in diesem Zusammenhang die
Beschränkung auf das Wesentliche. Wenn z.B. etwas wunderbar in einer
Strichliste dargestellt werden kann, muss man keinen seitenlangen Prosatext
schreiben. Auf der anderen Seite muss natürlich darauf geachtet werden, das
keine wichtigen Punkte ausgelassen werden!
- Modulare Struktur
- Modularisierung sollte in ausreichendem Maße in
den Vorlesungen besprochen worden sein. Zur Erinnerung, nochmal einige
Punkte:
- Divide and Conquer
- Minimale Kopplung von Komponenten
- Maximale Kohäsion von Komponenten
- Beachtung des Geheimnisprinzips
- Vertikale Verfolgbarkeit
- Verschiedene Dokumente unterschiedlichen Abstraktionsgrades müssen
zueinander konsistent sein.
Beziehungen zwischen Anforderungen, Entwurf und Realisierung müssen
klar und explizit dokumentiert werden.
Ein Beispiel sind Variablen- und Klassenbezeichner: in jeder Phase müssen
die gleichen benutzt werden.
- Horizontale Verfolgbarkeit
- Verschiedene Sichten innerhalb einer Abstraktionsebene müssen
nachvollziehbar und konsistent sein. (Beispielsweise muss im
Klassendiagramm und in der Beschreibung des Verhaltens
Namenskonformität herrschen.)
- Dokumentation der Verifikation
- Dokumentation der Verifikation des Entwurfs gegen die
Anforderungen.
- Dokumentation der Verifikation des Programmkodes gegen den
Entwurf.
- Dokumentation der Validation
- Dokumentation der Validation des ausführbaren Systems gegen die
Anforderungsbeschreibung (Spezifikation)
- Es wird ein objektorientierter Entwurf erwartet.
- Es ist ein Klassendiagramm zu erstellen und eine Darstellung nach UML
zu wählen.
- Es sind die Schnittstellen der Klassen zu definieren.
- Es ist die Funktion einer Klasse und das Verhalten ihrer Methoden kurz zu
erläutern.
- Die Abhängigkeiten zwischen einzelnen Komponenten bzw. Klassen sind
zu dokumentieren.
- Die System-Entwurfs-Beschreibung sollte
kurz, aber prägnant sein und alles wichtige enthalten.
Implementierungsdetails haben im Entwurf nichts zu suchen.
Es ist der Quelltext in einer für das Verständnis hinreichenden Art und
Weise zu dokumentieren.
Der Quelltext ist so mit Anmerkungen zu versehen, da mit Hilfe des
JDK-Tools "`javadoc"' automatisch eine Dokumentation in HTML erstellt
werden kann. Diese Dokumentation ist im lokalen WWW-Verzeichnis
dem Betreuer zugänglich zu machen.
Die Dokumentation beschränkt sich nicht nur auf die Signatur, sondern
bezieht sich auch auf Anweisungen innerhalb von Methoden. Es sollen
wichtige Stellen im Quelltext erläutert werden (beispielsweise
Fallunterscheidungen, Schleifen o. ä.), um die Lesbarkeit zu erhöhen.
Die Java Code Conventions (Verweis in Abschnitt 4 geben
Richtlinien vor, wie bei der Formatierung und Dokumentation von Code
vorgegangen werden soll. Es muss sich nicht zwingend an dieses Format
gehalten werden, jedoch soll das Code-Format einer jeden Gruppe konsistent
sein!
In diesem Praktikum wird nach dem Wasserfallmodell vorgegangen, d.h.
Entscheidungen aus früheren Phasen können nicht mehr Rückgängig gemacht werden.
Diese Handhabung ist etwas zu strikt, und kann das weiterkommen unnötig
erschweren, falls ein Fehler entdeckt wird.
Wenn in einer späteren Phase (z.B. Implementierung) schwere Fehler oder
Probleme auftreten, die durch Entscheidungen in einer früheren Phase (z.B.
Entwurf) resultieren, ist es unter Umständen möglich, hier eine Korrektur zu
machen. Diese Korrekturen müssen dokumentiert werden und sind vorher mit dem
Betreuer abzusprechen.
|
