Softwarepraktikum im Sommersemester 2003
Grundlagen betrieblicher Informationssysteme
Subsections
Die Aufgabe des Praktikums im Vertiefungsbereich "`Betriebliche
Informationssysteme"' baut auf Themen des Vorlesungszyklus "`Entwicklung von
Softwaresystemen (I-III)"' auf und soll Fähigkeiten im Umgang mit Inhalten aus
diesem Bereich vertiefen.
Die in den Vorlesungen erlernten Methoden werden bei der Entwicklung eines
größeren Softwaresystems praktisch angewendet und ihre Notwendigkeit
verdeutlicht. Der Bearbeitungsaufwand ist so gewählt, dass die Aufgaben
innerhalb eines Vorlesungszeitraums von einer Praktikumsgruppe (6 Personen)
bewältigt werden knnen. Es werden alle Phasen eines
Software-Entwicklungsprozesses (Anforderungen, Entwurf, Implementierung,
Integration und Validation) durchlaufen.
Im Praktikum soll ein Teil des durch die TPC-W-Spezifikation vorgegebenen
Systems zur Leistungsbewertung von E-Commerce-Servern implementiert
werden.
Die TPC-W-Spezifikation gibt ein System zum webbasierten Buchhandel vor, das
dann auf verschiedenen Hardware/Software-Plattformen implementiert und
getestet werden kann. TPC-W spezifiziert detailliert, welche Funktionalitäten der
Buchhandel haben soll, wie das Verhalten der Besucher des Buchhandels
simuliert werden muss, in welchem Rahmen sich Antwortzeiten bewegen
müssen und nicht zuletzt, wie die Datenbasis aufgebaut ist.
Die Entwicklung eines Systems zur automatischen Generierung dieser
Datenbasis, d.h. Tabellen mit Autoren, Büchern, Kunden, Bestellungen usw. ist
das Ziel dieses Praktikums. Die Datenbasis muss bestimmten Anforderungen
bezüglich Verteilung, Umfang und Struktur der Daten genügen und wird in einem
relationalen Datenbanksystem verwaltet.
Softwareentwicklung im Sinne des Software Engineerings bedeutet die Erstellung
eines Software-Systems ausgehend von einer System-Spezifikation durch ein
Team mittels vorgegebener Techniken, Methoden und Werkzeuge. Bei der
Entwicklung großer, komplexer Systeme sind u. a. folgende Prinzipien für den
Entwurf und die Programmierung elementar:
- Modularisierung (Divide and conquer)
- Explizite Schnittstellen
- Dokumentation
Reale Anwendungsszenarien kann man weiter charakteristisieren.
- Die Software muss Anforderungen Dritter genügen.
- Die Benutzung erfolgt nicht nur durch den jeweiligen Entwickler,
sondern durch eine Vielzahl weiterer Personen.
- Die Entwicklung findet in der Regel in Teams statt, d.h., das
Verhalten der
Komponenten ist ausreichend zu spezifizieren und dokumentieren, um
Integrations- und Koordinationsprobleme zu vermeiden.
Aufgrund dieser Charakteristika wurde der TPC-W Benchmark
http://www.tpc.org
als zentrales Thema dieser Aufgabe ausgesucht. Seine sehr genaue und vor allen
Dingen hinreichend vollständige Spezifikation der funktionalen und
nicht-funktionalen Anforderungen erlaubt eine Fokussierung auf die Anwendung
von Methoden zur Softwareentwicklung und die Verfeinerung von bekannten
Techniken für Modellierung, Entwurf und Programmierung, ohne durch bekannte
Probleme, wie z.B. Mehrdeutigkeiten in der Problembeschreibung oder
Unzulänglichkeiten der Dokumentation, zu verwirren oder aufzuhalten. Das
gesamte Spektrum an Freiheitsgraden während der Realisierung bzw. der
Modellierung des Softwaresystems bleibt erhalten.
Das Teilsystem kann nur durch die Leistung der gesamten Gruppe als Team
realisiert werden, da der Umfang der Aufgaben kein anderes Arbeiten zulässt.
Dies verdeutlicht die Notwendigkeit der Einhaltung oben genannter Prinzipien.
Im Bild ist ein Überblick der Architektur gegeben. Es zeigt die notwendigen
Komponenten und deren Beziehung zueinander. Von diesen Komponenten ist im
Zuge des Praktikums der Loader/Data-Generator (grau unterlegt) zu entwickeln.
Eine RBE-Instanz ist ein das Benutzerverhalten simulierender HTTP-Client
(WWW-Browser-Simulation). Auf der Basis von vorgegebenen
Wahrscheinlichkeiten werden Anfragen generiert, anschließend Antworten
analysiert und daraus wieder entsprechende Anfragen erzeugt. Der RBE ist nicht
nur für die Lastgenerierung, sondern auch für die Messung der Verarbeitungszeit
einer Anfrage verantwortlich.
Zentrale Instanz des Systems ist der HTTP-Server, der Anfragen von
RBE-Instanzen verarbeitet. Zu diesem Zweck muss er auf das Datenbanksystem
zugreifen oder Verarbeitungseinheiten an den Applikationsserver delegieren. Ein
Datenbankzugriff ist immer dann notwendig, wenn Bücherlisten angefordert,
Suchanfragen formuliert oder Bücher geordert werden. Der Applikationsserver
ist auch für die Transaktionsverarbeitung verantwortlich, die unter anderem bei
verbindlichen Bestellungen notwendig wird.
Web-Objekte, wie beispielsweise Bilder, werden gesondert verwaltet. Sie
können in einem Datenbanksystem verwaltet werden und müssen nicht zwingend
in einem Dateisystem gehalten werden.
Das Teilsystem zur Population der Datenbank ist für die Erzeugung der
Datenbasis notwendig. Zur Datenbasis gehören neben anderen Daten:
Autorenverzeichnisse, Bücherkataloge, Bestellinformationen und auch
Web-Objekte, wie beispielsweise Bilder. Dabei sind Vorgaben bezüglich der
statistischen Verteilung der Ausprägungen einzelner Attribute zu beachten. Der
TPC-W macht sehr genaue Angaben bezüglich der Häufigkeit des Vorkommens
einzelner Ausprägungen.
Das zu realisierende System besteht grob aus den nachfolgenden Komponenten,
wobei in der Modellierungs- bzw. Entwurfsphase diese Aufteilung verfeinert
oder durch eine geschicktere Aufteilung ersetzt werden kann. Sie dient hier nur
der Verdeutlichung des Gesamtzusammenhangs. Wichtig bei der Modellierung ist
die explizite Definition und Dokumentation der Schnittstellen, um eine parallele
Entwicklung der entworfenen Komponenten zu unterstützen:
![\includegraphics[width=10cm]{komponenten.ps}](img2.png)
Die DB-Komponente stellt der Generator- und Visualisierung-Komponente eine
Schnittstelle zur Verfügung, die den Datenbankzugriff kapselt und von dem
Datenbanksystem abstrahiert. Es sind verschiedene Abstraktionsgrade denkbar:
beispielsweise kann für jede DB-Operation (wie SELECT, INSERT,
UPDATE, ...) eine
Methode an dieser Schnittelle angeboten werden oder auch für jede Relation
(Buch, Autor, Bestellung, ...) eine Methode zum Schreiben oder Lesen einer
Instanz bzw. einer Menge von Instanzen definiert werden. Auch ein
objektorientierter Ansatz ist vorstellbar, so dass jede Relation in einer eigenen
Klasse gekapselt wird. Der Zugriff auf das Datenbanksystem selber geschieht
mittels der standardisierten Anfragesprache SQL.
Die Generator-Komponente umfasst die Funktionalität zum Erzeugen von
Instanzen unter Beachtung bestimmter statistischer Annahmen in Abhängigkeit
von vorgegebener Anzahl und Struktur. Die benötigten statistischen Funktionen
können eventuell in einer zusätzlichen Komponente modelliert werden.
Die Visualisierung-Komponente dient zur Qualitätssicherung. Sie soll den Inhalt
der Datenbank visualisieren, um die Überprüfung der Einhaltung der
vorgegebenen statistischen Randbedingungen zu ermöglichen (liegen die Werte in
den vorgegebenen Grenzen, sind sie gleichverteilt, usw.). Die hier benutzten
Funktionen zur Überprüfung der Korrektheit von Verteilungen sollten nicht auf die
Funktionen der Generator-Komponente zugreifen, um nicht falsche Ergebnisse
mit gleichen, falschen Annahmen zu verifizieren.
Der Zugriff auf Generator und Visualisierung soll über eine grafische
Benutzeroberfläche ermöglicht werden.
Da die Programmierung in Java erfolgt, wird als Schnittstelle zum
Datenbanksystem JDBC eingesetzt. Als Datenbankverwaltungssystem kommt
der Informix Dynamic Server 2000 zum Einsatz.
Die Durchführung der Aufgabe orientiert sich am Wasserfall-Modell [B.
Boehm]. Dieses Lebenszyklusmodell gliedert sich in vier Phasen, welche nach
dem Modell genau einmal durchlaufen werden. Es eignet sich in diesem Fall sehr
gut, da die Anforderungen zu Beginn vollständig beschrieben werden können und
keine Integrationsprobleme zu erwarten sind:
- Anforderungsanalyse
- Systementwurf und Modellierung
- Implementierung
- Integration und Validation
Am Ende jeder Phase sind von den Gruppen jeweils Dokumente abzugeben, die
die Ergebnisse der Phase zusammenfassen und das weitere Vorgehen beschreiben.
Im Rahmen eines Kolloquiums werden diese Ergebnisse diskutiert und bewertet.
Die eigentliche Anforderungsanalyse entfällt aufgrund der Vorgabe der
TPC-W-Benchmark-Spezifikation. Diese Phase dient vielmehr der Findung der
eigenen Rolle eines jeden Studierenden innerhalb seiner Gruppe bzw. seines
Teams und der allgemeinen Planung und Einarbeitung in die Teilaufgabe des
Praktikums, so dass eine Aufgabenverteilung im Team möglich wird.
Diese Phase umfasst ungefähr eine Woche.
Neben weiterer Vertiefung des Themas und der einzusetzenden API ist ein
Entwurf zu modellieren, der den Anforderungen genügt. Die Anforderungen
ergeben sich aus der Spezifikation. Architektur, Schnittstellen, Klassen, interne
Repräsentation von Datenbankobjekten und weitere Strukturierung durch Einsatz
von Paketen (respektive Java Packages) sind zu definieren und zu
dokumentieren. Weiterhin sind für jede Komponente Testfälle zu entwickeln, die
eine Überprüfung derselben ermöglichen.
Diese Phase umfasst ungefähr drei Wochen.
Die Implementierung des vorgestellten Systementwurfs verfeinert u. a. die
Technik im Umgang mit Java, JDBC und SQL durch die notwendige
Auseinandersetzung mit der Thematik und deren tatsächliche Anwendung.
Diese Phase umfasst ungefähr vier Wochen.
Die Komponenten sind zu einem funktionierenden System zu integrieren und 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
direkt aus der Spezifikation abgeleitet werden. Die Überprüfung geschieht mit
Hilfe der Visualisierungskomponente. Am Ende dieser Aufgabe und zugleich am
Ende des SWPs steht eine Systempräsentation im Rahmen aller Gruppen eines
jeden Betreuers.
Diese Phase umfasst ungefähr drei Wochen.
Eine ausführliche Beschreibung der einzelnen Teilaufgaben befindet sich in Abschnitt
2.
Eine Gruppe besteht aus 6 Teilnehmern.
Die Gruppe wird weiter in drei Zweiergruppen unterteilt. Jede dieser Gruppen ist
für die Umsetzung eines Teils des Gesamtsystems verantwortlich (eine sinnvolle
Aufteilung ist z.B. Visualisierung/GUI, DB-Komponente, Generator).
Insbesondere gelten die beiden Mitglieder der Zweiergruppe als Ansprechpartner
bei Rückfragen zu ihrer Komponente. Die Zweiergruppen werden von der
Gruppe zu Beginn des Praktikums selbst festgelegt und bleiben bis zum Ende
bestehen. Sinn des Pair-Programming ist ein gemeinsames Arbeiten, kein
simples Aufteilen der Aufgaben. Beide Entwickler sollen zusammen an einem
Rechner arbeiten. Bei Nachfragen müssen daher auch beide Entwickler
jederzeit alle Teile der ihnen übertragenen Komponente genaustens kennen. In
der Programmentwicklung erfahrenere Teilnehmer sollen darauf achten, dass ihr
Partner nicht auf der Strecke bleibt.
Bei Besprechungen mit den Betreuern hat jeweils ein Mitglied pro Zweierteam
teilzunehmen; dabei sollen am Ende beide an der gleichen Anzahl Besprechungen
teilgenommen haben.
Nach der Phase des Entwurfs wird ein schriftliches Testat über die bisherigen
Inhalte des Praktikums stattfinden. Nach der Systemintegration wird es weiterhin
ein Kolloquium geben, in dem jeder Teilnehmer in einem kurzen Einzelgespräch
von seinem Betreuer zum Praktikum befragt wird. Diese beiden Noten fließen in
die Individualbewertung ein.
Zu Beginn der Aufgabe werden folgende Dokumente ausgehändigt.
- Die Aufgabenbeschreibung (dieses Dokument).
- Die TPC-W-Spezifikation Version 1.8, Klauseln 0,1 und 4. Mehr ist zur
Bearbeitung der Aufgaben nicht nötig. Um sich einen besseren Überblick zu
verschaffen, können sich Interessierte die komplette Spezifikation auf der
Praktikumsseite als PDF herunterladen.
Weitere Materialien finden sich auf der
Praktikumsseite.
Die Bewertung des Praktikums setzt sich aus einer Gruppen- und einer
Individualnote zusammen. Bei vollständiger Bearbeitung der gestellten Aufgaben
kann eine maximale Punktzahl von 100 Punkten erreicht werden. Nach jeder
Phase des Praktikums werden die Abgaben der Gruppe bewertet, die Summe der
dabei erreichten Punkte ergibt die Gruppenbewertung. Diese macht insgesamt
50% der Punkte aus. Zusätzlich kann jeder Teilnehmer in den Kolloquien
Punkte erringen, die in den Individualanteil einfließen.
Zur Bewertung der Gruppenleistung sind zu vorgegebenen Terminen Dokumente
abzugeben, die die Ergebnisse der vorangegangenen Arbeit dokumentieren und
erläutern. Ferner beinhalten sie Antworten zu Fragen, bzw. Aufgaben, die
zusätzlich zur Hauptaufgabe der Realisierung eines Software-Systems vor oder
während der Praktikumsaufgabe gestellt werden.
Die absolute Mindestanforderung für einen erfolgreichen Abschluss des
Praktikums des Praktikums besteht darin, zum Ende ein lauffähiges System
vorzustellen, das zumindest eine Relation des vorgegebenen DB-Schemas mit
sinnvollen Daten füllt. Als Programmiersprache ist ausschließlich Java (JDK 1.x,
JDBC 1.x) zu verwenden!
Das Praktikum wurde konzipiert, um die in den ersten Semestern vorgestellten
Techniken und Methoden praktisch anzuwenden. Aufgrund der beschränkten
Zeit von 13 Wochen kann natürlich nur ein Teil davon berücksichtigt werden.
Nichtsdestotrotz ist die Aufgabe sehr gut geeignet, um ein Gefühl für die
Probleme bei der Entwicklung eines großen Systems im Team zu entwickeln.
Die benutzten Werkzeuge und die Programmierung in Java sollten (hoffentlich)
schon aus den Übungen zu den Vorlesungen bekannt sein, so dass sich der
Einarbeitungsaufwand hierfür in Grenzen hält.
Und nun: Viel Spaß beim Entwickeln :-)
|
