Softwarepraktikum im Sommersemester 2003
Grundlagen betrieblicher Informationssysteme
Subsections
2 Aufgaben
Die Hauptaufgabe besteht in der Realisierung eines Software-Systems zur
Population der Datenbank laut TPCW-Spezifikation. Konkret sind die
Paragraphen 1 und 4 der Spezifikation zu erfüllen. Paragraph 1 beschreibt die
Anforderungen an das Datenbankschema und die Datenbank-relevanten
Aspekte, während Paragraph 4 die Anforderungen an die zu generierenden
Daten definiert. Eine Datenbank mit entsprechendem Schema ist vorgegeben und
muss nicht modelliert werden.
Abschnitt 4.6.2.19 der TPC-W-Spezifikation wird in diesem Praktikum durch
folgenden Text ersetzt1:
- 4.6.2.19a
- The item title (I_TITLE) must be generated as a random a-string[14..60]. It
must have an embedded substring generated as DigSyl(num, 7). The substring must
start at an offset within the I_TITLE string random within [0..46].
if I_ID <= (NUM_ITEMS / 5)
num = I_ID;
else
num = random within [0..(NUM_ITEMS / 5)];
Example: Given an I_ID of 4628, the embedded substring is generated as
DigSyl(4628, 7). Thus, the I_TITLE corresponding to an I_ID of 4628 would
contain the substring BABABAREATALIN starting at some random offset between 0
and 46.
Comment: The intent of this Clause is to ensure that web interactions that
execute a search based on the content of I_TITLE find a number of matching
records.
- 4.6.2.19b
- The author last name (A_LNAME) must be generated as a random a-string [14..20].
It must have an embedded substring generated as DigSyl(num, 7). The substring
must start at an offset within the A_LNAME string random within [0..6].
if A_ID <= (NUM_AUTHORS / 2.5)
num = A_ID;
else
num = random within [0..(NUM_AUTHORS / 2.5)];
Die für das zu realisierende Software-System relevanten funktionalen
Anforderungen finden sich in Paragraph 4 und müssen erfüllt werden.
Alle Anforderungen in Paragraph 4, die sich nicht direkt auf das zu realisierende
Software-System beziehen, beispielsweise Anforderungen an den Web-Server
etc., können ignoriert werden. Ferner ist es nicht erforderlich den Punkt 4.6.2.13
zu erfüllen. Somit müssen zunächst keine Bilder (Images) oder Verkleinerungen
(Thumbnails) erzeugt werden. Grafische Objekte brauchen nicht unterstützt zu
werden!
Das vorgegebene Lebenszyklusmodell gliedert sich in vier Phasen, welche nach
dem Modell genau einmal durchlaufen werden. Die Durchführung der Aufgabe
orientiert sich an diesen Phasen:
- Anforderungsanalyse
- Systementwurf und Modellierung
- Kodierung
- Integration und Validation
In jeder Phase ist die Bearbeitung zu dokumentieren.
Die eigentliche Anforderungsanalyse entfällt aufgrund der Vorgabe der
TPCW-Benchmark-Spezifikation. Vielmehr ist sich hier in die Spezifikation und
Dokumentation zu vertiefen und eine Strategie zu entwickeln, um eine Datenbasis
schnell, effizient und mit korrekten Daten aufzubauen.
Diese Phase umfasst eine Woche.
- Verteilung der Aufgaben innerhalb der Gruppe,
- Einarbeitung in die Thematik,
- Planung des allgemeinen Vorgehens und der grafischen Benutzerschnittstelle.
Arbeiten Sie die Spezifikation durch und entwickeln Sie eine Strategie, die
beschreibt, wie die benötigten Daten zu erzeugen sind. Erläutern Sie kurz, wie im
Allgemeinen bei der Population der Datenbank vorzugehen ist und wie im
Speziellen Bestellungen behandelt werden müssen. Berücksichtigen Sie dabei die
Abhängigkeiten, die sich durch Fremdschlüsselbeziehungen oder andere
Beziehungen aus dem DB-Schema ergeben und die eventuell lange Laufzeit
eines Generierungsdurchgangs. Überlegen Sie, welche funktionalen
Anforderungen die grafische Benutzerschnittstelle konkret erfüllen muss, und
entwerfen Sie entsprechende Interface-Flow-Diagramme.
Entwickeln Sie jeweils eine Formel für die Abschätzung des Speicheraufwandes
und für die Anzahl der zu erzeugenden Objekte in Abhängigkeit von der Anzahl
der emulierten Browser (EB) und Produkte (Items).
Schätzen Sie den Aufwand für
EB = 1, Items = 1 000 und
EB = 10, Items = 100 000 ab.
System-Anforderungs-Beschreibung, die oben genannte Strategie,
Interface-Flow-Diagramme, Abschätzungen und die interne Gruppenaufteilung.
Im weiteren Verlauf ist ein System zu entwerfen, das den Anforderungen der
Spezifikation genügt. Dabei ist den Prinzipien eines objektorientierten Entwurfs zu
folgen.
Diese Phase umfasst drei Wochen.
- Erstellung eines objektorientierten System-Entwurfs
- Erarbeiten von Testfällen
Architektur, Schnittstellen, Klassen, interne Repräsentation von
Datenbankobjekten und weitere Strukturierung durch Einsatz von Paketen
(respektive Java Packages) sind zu definieren und zu dokumentieren. Entwickeln
Sie für jede Komponente Testfälle. Beschreiben Sie das dabei zu erwartende
Verhalten. Bei der GUI ist z.B. ein Testfall "`SCHLIESSEN Button wird gedrückt"' denkbar.
Das erwartete Verhalten ist das Beenden der Anwendung und Freigabe aller Ressourcen.
System-Entwurfs-Beschreibung (mit Klassendiagramm nach UML)
Testplan (für jede Komponente 10 Testfälle mit Verhaltensbeschreibung)
Bitte besonders die Entwurfshinweise in See Entwurfshinweise beachten!
In dieser Phase ist der Entwurf zu implementieren.
Es wird Java als Programmiersprache verwendet.
Diese Phase umfasst höchstens vier Wochen.
Implementierung der einzelnen Komponenten.
Realisieren Sie den von Ihnen erstellten Entwurf unter besonderer
Berücksichtigung der Einhaltung der Kardinalitäten der zu erzeugenden
Objektmengen. Beschreiben Sie, wie die Kardinalitt der Menge von
Bestellpositionen eingehalten wird. Benutzen Sie für die Datenbankanbindung
die JDBC-Schnittstelle. Für Testläufe sollte die Konfiguration (EB = 1, Items =
1000) genutzt werden.
Benutzen Sie für die Kode-Dokumentation das JDK-Tool "`javadoc"'!
Testen Sie weiterhin Ihre Komponenten mit den von Ihnen beschriebenen
Testfällen und protokollieren Sie alle Abweichungen vom erwarteten Verhalten.
kommentierter Code,
Code-Beschreibung (HTML, mit javadoc erzeugt),
Protokoll Komponententest
Die Komponenten sind zu einem funktionierenden System zu integrieren und erneut zu
testen. Neben dem Funktionstest zur Überprüfung der Zuverlässigkeit ist ferner
das System gegen die Anforderungen zu validieren. Geeignete Testfälle können
aus der Spezifikation direkt abgeleitet werden. Dies geschieht mit Hilfe der
Visualisierungskomponente.
Die Realisierung ist am Ende der Praktikumsaufgabe im Rahmen einer
Systemvorstellung zu präsentieren.
Diese Phase umfasst höchstens drei Wochen.
Integration,
Test, Validation,
Ausführung: Population der Datenbank. EB=10, Item=100000
Fügen Sie alle Komponenten zu einem vollständigen System zusammen. Testen
Sie es zunächst mit der Konfiguration (EB = 1, Item = 1 000) und dann mit der
Konfiguration (EB = 10, Item = 100 000). Messen Sie die Zeit, die zum Fällen der
Datenbank nötig ist. Validieren Sie das System gegen die Anforderungen, indem
Sie geeignete Anfragen an das DBMS stellen und diese visualisieren.
Testen Sie Ihr System mit geeigneten Testfällen. Arbeiten alle Komponenten
fehlerfrei zusammen? Denken Sie über Transaktionskontrolle und Recovery nach!
Was geschieht bei einem vorzeitigen Abbruch der Verarbeitung? Sind Sie
gezwungen, von vorne zu beginnen, oder können Sie einzelne Schritte rückgängig
machen, um in einem konsistenten Zustand die Verarbeitung fortzusetzen.
Welche Möglichkeiten bieten DBVS, um die Anforderungen an die spezifischen
Eigenschaften der Attribute und ihrer Ausprgungen zu gewährleisten?
Abschluss-Dokumentation (Integrations- und Validations-Protokoll mit
Testfällen und Ergebnis),
Dokumentation des Einsatzes der Visualisierungs-Komponente
System-Vorführung
Footnotes
- ... ersetzt1
-
Der Text entspricht den Absätzen 4.6.2.17 und 4.6.2.17 des TPCW-Drafts D 5.1
|
