Entwurf und Implementierung eines webbasierten

Transkript

1 F Entwurf und Implementierung eines webbasierten Frameworks zur automatischen Bewertung von Software Design and Implementation of a Web-Based Framework for Automated Software Assessment Bachelor-Abschlussarbeit Betreuer: Prof. Dr. rer. nat. Rainer Oechsle Thiemo Morth Temmels,

2 Kurzfassung Die Bewertung von Software ist ein zeitaufwändiger Prozess, wobei viele verschiedene Aspekte eines Software-Produkts berücksichtigt werden müssen. Aussagen über die Eigenschaften der Software lassen sich zum Beispiel durch das Testen der Software oder durch Berechnung von Software-Metriken treffen. Hierzu existieren bereits zahlreiche Werkzeuge. Ziel dieser Arbeit ist die Entwicklung und Realisierung eines Rahmenwerks zur automatischen Bewertung von studentischer Software. Dabei soll die bereits vorhandene Funktionalität zur Bewertung der Software in Form der zahlreichen Tools wiederverwendet werden. Alle zeitaufwändigen, ständig wiederkehrenden Aufgaben sollen automatisiert werden, so dass es nur noch nötig ist die Ergebnisse einzusehen und zu beurteilen. Sobald ein Programm eines Studenten vorliegt, wird dessen Bewertung automatisch gestartet. Die eigentliche Berechnung wird dabei im Hintergrund durchgeführt, so dass der Benutzer die Anwendung weiter nutzen kann. Die Ergebnisse aller Bewertungen werden schließlich übersichtlich in einer Gesamt-Ansicht dargestellt. Ergebnis der Arbeit ist eine Web-Anwendung, die die gesteckten Ziele erfüllt. Die Anwendung erlaubt es beliebige Programme hochzuladen und als Werkzeuge zu integrieren. Es können Aufgaben definiert werden, denen die integrierten Tools zugeordnet werden können. Sobald eine konkrete Lösung zu einer Aufgabe hochgeladen wurde, wird jedes der Aufgabe zugeordnete Tool automatisch für die Lösung ausgeführt und die Ergebnisse gespeichert. Bei Änderungen der Tools oder der Aufgaben werden alle betroffenen Ergebnisse automatisch neu berechnet bzw. gelöscht, damit das System konsistent bleibt. Die Ergebnisse für ein spezielles studentisches Software-Produkt werden alle übersichtlich auf einer Seite dargestellt.

3 Inhaltsverzeichnis 1 Einleitung Aufgabenstellung und Zielsetzung Software-Metriken Umfangs-Metriken Halstead-Metriken McCabe-Metrik Metriken für OO-Programmierung Ant Überblick und Grundkonzept Grunddesign Benutzer und Rollen Benutzerhandbuch Inhalt Systemvoraussetzungen Installation und Start Benutzung des Programms Benutzung durch Studenten Benutzung durch Professoren Benutzung durch Administratoren Konfiguration der Web-Anwendung Entwurf Modell Automatische Lösungs-Bewertung Funktionen der Web-Anwendung Registrierung Interne Benutzer-Startseite Ändern des Benutzer-Profils Benutzerverwaltung Toolverwaltung Aufgabenverwaltung

4 Inhaltsverzeichnis III Hochladen einer Lösung Anzeigen der Tool-Bewertungen Abmeldung Implementierung und Test Zugriffsschutz Datenbank-Zugriff Datei-Upload Datei-Download Ausführung eines Tools Verwendung von JSP-Templates Test Statische Analyse Systemtest Zusammenfassung und Ausblick Literaturverzeichnis

5 Abbildungsverzeichnis 3.1 Beispiel - Halstaed - Quellcode Beispiel - McCabe - Kontrollflussgraph Beispiel - OO - Klassendiagramm ASB - Startseite ASB - Registrierung ASB - Registrierung ASB - Authentifizierung ASB - Hauptseite Studenten ASB - Lösung hochladen - Aufgabensammlung auswählen ASB - Lösung hochladen - Aufgabensammlung anzeigen ASB - Lösung hochladen - Aufgabe auswählen ASB - Lösung hochladen - Überschreiben bestätigen ASB - Lösung hochladen - Datei auswählen ASB - Bewertungen anzeigen - Übersicht ASB - Bewertungen anzeigen - Datei herunterladen ASB - Bewertungen anzeigen - Standardausgabe ASB - Hauptseite Professoren ASB - Benutzerverwaltung Professoren ASB - Toolverwaltung - Übersicht ASB - Toolverwaltung - neues Tool installieren ASB - Aufgabenverwaltung - Übersicht Aufgabensammlungen ASB - Aufgabenverwaltung - Übersicht Aufgaben ASB - Aufgabenverwaltung - neue Aufgabe erstellen ASB - Bewertungen anzeigen - Student auswählen ASB - Bewertungen anzeigen - Übersicht ASB - Hauptseite Administrator ASB - Benutzerverwaltung Administrator Konfiguration des Anwendungs-Kontexts Konfiguration der Web-Anwendung Konfiguration der Web-Anwendung Konfiguration der Web-Anwendung Entity-Relationship-Diagramm - Datenmodell Klassendiagramm - Automatische Lösungs-Bewertung

6 Abbildungsverzeichnis V 7.3 Kontrollflussdiagramm - Registrierung Kontrollflussdiagramm - Interne Benutzer-Startseite Kontrollflussdiagramm - Ändern des Benutzer-Profils Kontrollflussdiagramm - Benutzerverwaltung Kontrollflussdiagramm - Toolverwaltung Kontrollflussdiagramm - Aufgabenverwaltung Kontrollflussdiagramm - Hochladen einer Lösung Kontrollflussdiagramm - Anzeigen der Tool-Bewertungen Kontrollflussdiagramm - Anzeigen der Tool-Bewertungen Kontrollflussdiagramm - Anzeigen der Tool-Bewertungen Kontrollflussdiagramm - Abmeldung web.xml - security-constraints web.xml - login-config web.xml - servlet-mapping web.xml - resource-ref Quellcode - Referenz auf Datenbank Quellcode - alle Professoren anzeigen Quellcode - Student in Datenbank speichern Quellcode - Transaktion Quellcode - Lösung hochladen Quellcode - Sitzungs-Listener Quellcode - Kontext-Listener web.xml - Listener Quellcode - Zugriff auf Datei Quellcode - execcommand() Template - standardpage.jsp JSP-Dokument - welcome.jsp

7 1 Einleitung Das Bewerten der Qualität von Software ist eine komplexe Aufgabe, die besonders bei größeren Projekten viel Zeit in Anspruch nimmt. Doch gerade diese Zeit ist meistens nicht vorhanden, wenn es um die Beurteilung von Software-Produkten geht, die im Rahmen von Projekt- und Abschlussarbeiten an einer Hochschule entstehen. Die Bewertung der Gesamtarbeit beschränkt sich zumeist auf die Bewertung der Dokumentation, der entwickelten Software im laufenden Betrieb, sowie stichprobenartiger Inspektionen des Quellcodes. Qualitätsmerkmale wie Skalierbarkeit, Änderbarkeit und Erweiterbarkeit können dabei nur unzulänglich betrachtet werden, da die verfügbare Zeit für eine komplette Inspektion des Quellcodes nicht ausreicht. Mit dieser Motivation entstand die Idee für die vorliegende Arbeit: Die Bewertung von studentischer Software zu automatisieren. Zur Beurteilung der Qualität ist die Bestimmungen von vielen verschiedenen Merkmalen der Software nötig. Einzelne Merkmale, wie beispielsweise die Anzahl der Quellcode- Zeilen pro Methode oder die Vererbungstiefe, reichen nicht aus um die Qualität der untersuchten Software beurteilen zu können. Die Auswertung einer Kombination von mehreren Merkmalen macht es erst möglich Rückschlüsse auf ein bestimmtes Qualitätsmerkmal zu ziehen. Eine Möglichkeit zur Bestimmung solcher Merkmale ist die Berechnung von Software-Metriken. Diese messen jeweils ein bestimmtes Merkmal und spiegeln diese Eigenschaft der Software in einer numerisch, quantitativen Form wieder, indem sie dem Merkmal eine Kennzahl zuordnen. Es existieren bereits Software-Metriken für die Berechnung vieler verschiedener Merkmale, sowie Tools, die diese für ein konkretes Software- Produkt berechnen. Ein weitere Möglichkeit zur Bestimmung von Software-Merkmalen ist das Testen. Durch Simulation geeigneter Test-Szenarien lassen sich ebenfalls Aussagen über konkrete Eigenschaften der Software treffen. Auch hierfür existieren bereits zahlreiche Tools zur Ausführung konkreter Test-Szenarien. Diese Arbeit befasst sich mit der Entwicklung und Implementierung einer Web- Anwendung, die es ermöglicht die Bestimmung der verschiedenen Software-Merkmale zu automatisieren und die Ergebnisse in einer kompakten, übersichtlichen Form darzustellen. Dabei wird die Berechnung konkreter Merkmale von externen Tools übernommen, die in die Anwendung eingebunden werden können. Das ermöglicht die Nutzung der bereits vorhanden Tools und gewährleistet einen hohen Grad an Änderbarkeit und Erweiterbarkeit. Zur Erweiterung der Funktionalität der Anwendung ist lediglich die Entwicklung und Einbindung neuer Tools notwendig. Die Anwendung stellt sicher, dass die Berechnung der Software-Merkmale durch die Tools automatisch gestartet wird, sobald ein zu bewertendes Software-Produkt vorliegt und die Ergebnisse in einer Datenbank verwaltet

8 1 Einleitung 2 werden. Die Interpretation der konkreten Ergebnisse und das Schließen auf die Qualität des Software-Produktes liegt allerdings weiterhin beim Benutzer der Anwendung. Die genaue Aufgabenstellung dieser Arbeit wird in Kapitel 2 beschrieben. Hier werden die konkreten Ziele definiert, die es zu erreichen gilt, sowie eine detaillierte Anforderungsanalyse an die zu entwickelnde Software erstellt. Das folgende Kapitel 3 gibt eine kurze Einführung in das Thema der Software-Metriken und führt einige Beispiele für spezielle Metriken an. In Kapitel 4 wird das Werkzeug Ant kurz vorgestellt. Das Tool ist ein Quasi-Standard in der Java Programmierung und wurde auch zum Compilieren dieser Anwendung eingesetzt. Einen Überblick über die entstandene Anwendung vermittelt Kapitel 5. Ebenfalls werden hier die wichtigsten Konzepte vorgestellt. Das Benutzerhandbuch der Anwendung findet sich in Kapitel 6. Hier wird die Installation und Konfiguration der Web-Anwendung erläutert. Des Weiteren werden alle Funktionen vorgestellt und deren Verwendung detailliert beschrieben. Das Kapitel 7 widmet sich dem Entwurf der Anwendung. Hier wird sowohl der relationale Datenbankentwurf als auch der objektorientierte Entwurf der eigentlichen Anwendung vorgestellt. Der Entwurf folgt dem Model-View-Controller-Konzept, wonach die eigentlichen Daten, die Repräsentation der Daten, sowie die Steuerung des Kontrollflusses von jeweils unterschiedlichen Komponenten behandelt werden. In Kapitel 8 werden einige spezielle Programmteile beschrieben, deren Implementierung besonders problematisch oder interessant ist. Das Kapitel schließt mit einer Beschreibung der Tests dieser Anwendung. Schließlich fasst das Kapitel 9 noch einmal die Ergebnisse dieser Arbeit zusammen und gibt einen Ausblick auf die zukünftige Verwendung und Weiterentwicklung der entstandenen Web-Anwendung.

9 2 Aufgabenstellung und Zielsetzung Die Qualität eines Software-Produktes richtet sich nach einer Vielzahl von Merkmalen. Je nach dem, welches Qualitätsmerkmal untersucht werden soll, müssen verschiedene Merkmale der Software bestimmt werden. Ein Maß für die Merkmale eines Software-Produkts sind beispielsweise Software-Metriken oder die Ergebnisse von Test-Szenarien der Software. Um nun ein bestimmtes Qualitätsmerkmal zu untersuchen, müssen mehrere verschiedene Software-Metriken berechnet oder mehrere Test-Szenarien simuliert werden. Hierfür existiert bereits eine Vielzahl von Tools, die diese automatisch berechnen. Zur Bewertung der Qualität eines konkreten Software-Produks kann dieses also mit einigen dieser Programme untersucht werden und durch die Interpretation der Ergebnisse auf gewisse Qualtitätsmerkmale der Software geschlossen werden. Dabei ist allerdings für jede Bewertung eines konkreten Produkts ein manueller Aufruf der entsprechenden Tools und das Zusammensuchen der erzeugten Ergebnisse erforderlich. Wenn zudem noch mehrere Versionen der Software zu bewerten sind, muss dieser Prozess für jede einzelne Version wiederholt werden. Das ist ein unnötiger Aufwand, den es zu beheben gilt. Dieser unnötige Aufwand kommt besonders dann zum Tragen, wenn man sich die Situation eines Professors an einer Hochschule vorstellt, der eine Aufgabe stellt, deren Lösung ein Software-Produkt ist. Er bekommt von jedem Studenten, der die Aufgabe löst, eine Version der Software und soll alle diese Lösungen bewerten. Für eine detaillierte Inspektion des Quellcodes ist meistens keine Zeit und die Berechnung von Metriken und die Simulation von Testfällen nehmen auch viel Zeit in Anspruch. Die Aufgabe dieser Arbeit besteht nun darin, den Prozess zur Berechnung der einzelnen Merkmale zu automatisieren und dadurch den unnötigen Aufwand zu eliminieren. Dazu soll eine Anwendung entwickelt werden, die es ermöglicht verschiedene externe Tools einzubinden. Diese Tools übernehmen die Bestimmung der konkreten Eigenschaften. Dadurch werden die bereits bestehenden Tools wiederverwendet und ebenfalls ein hohes Maß an Änderbarkeit und Erweiterbarkeit erzielt, da die Funktionalität für die Berechnung der einzelnen Merkmale bei den speziellen Tools liegt. Die Benutzer der Anwendung lassen sich in zwei Gruppen einteilen: Professoren und Studenten. Die Hautpaufgabe der Professoren besteht hier darin Aufgaben zu stellen und die Lösungen der Studenten zu beurteilen. Um die Vielzahl der Aufgaben besser organisieren zu können, sollen die Aufgaben in Sammlungen zusammengefasst werden. Des Weiteren müssen Professoren Tools in die Anwendung integrieren können und sie den einzelnen Aufgaben zuordnen, damit diese automatisch für alle Lösungen der Aufgabe ausgeführt werden. Dabei sollen alle installierten Tools von jedem Professor verwendet werden können. Um die Ergebnisse der Lösungs-Bewertungen gut erfassen zu können ist es

10 2 Aufgabenstellung und Zielsetzung 4 nötig, dass alle Bewertungen einer Lösung von einer zentralen Übericht aus erreichbar sind. Schließlich müssen die Professoren noch die Möglichkeit haben einen Kommentar zu der Lösung abzugeben. Hier kann eine Gesamtbewertung der Lösung sowie eine Erläuterung von Schwachstellen und Verbesserungsmöglichkeiten angegeben werden. Die Professoren müssen jederzeit Zugriff auf alle Lösungen zu den von ihnen erstellten Aufgaben haben. Die Hauptaufgabe der Studenten besteht darin Lösungen zu den Aufgaben zu erstellen und diese in die Anwendung zu integrieren. Sobald die Lösung vollständig in der Anwendung vorliegt, werden alle Tools, die der entsprechenden Aufgabe zugordnet sind, automatisch mit der Lösung als Eingabe gestartet und die Ergenisse gespeichert. Des Weiteren sollen Studenten die Möglichkeit haben, sich die Ergebnisse der Bewertungen ihrer eigenen Lösungen anzusehen. Je nach dem, wie diese ausfallen, kann die Lösung dann noch einmal überarbeitet werden und eine neue Version in der Anwendung veröffentlicht werden. Das Veröffentlichen von Lösungen und das Ersetzen durch eine neue Version ist nur bis zu einem fest vorgegeben Zeitpunkt möglich, danach können nur noch die erstellten Lösungen und deren Bewertungen angesehen werden. Der genaue Zeitpunkt kann von dem Ersteller der Aufgabe festgesetzt werden. Studenten haben ausschließlich Zugriff auf die selbst erstellten Lösungen und deren Bewertungen. Des weiteren werden noch folgende Anforderungen an die Anwendung gestellt: Um eine größtmögliche Verfügbarkeit und Erreichbarkeit sowohl für Professoren als auch für Studenten zu erzielen, soll die Anwendung als Web-Anwendung realisiert werden. Das heißt, dass die Anwendung über eine web-basierte Benutzerschnittstelle verfügt. Damit kann die Anwendung mit jedem Standard-Browser bedient werden und ist in einem Netzwerk, bei entsprechender Konfiguration, von jedem Rechner aus erreichbar. Zur Realisierung soll die plattform-unabhängige Technologie Java Servlets von Sun Microsystems genutzt werden. Die Lösungen der Studenten sollen auf den Server hochgeladen werden und durch die Studenten sowie die Professoren wieder auf den lokalen Rechner herunter geladen werden können. Um eine hohe Flexibilität zu erhalten, soll jedes Programm, das auch auf dem zugrundeliegenden Betriebssystem ablauffähig ist, als Tool in die Anwendung eingebunden werden können. Die Bearbeitung der Software-Produkte durch die Tools soll im Hintergrund erfolgen. Das heißt, dass der Benutzer nicht warten muss, bis die Bearbeitung durch die Tools beendet ist, bevor er etwas anderes machen kann. Im Gegenteil, er soll sofort mit der Anwendung weiter arbeiten können, sobald die Bearbeitung durch die Tools gestartet wurde, ohne etwas von der Bearbeitung im Hintergrund zu merken. Die Anwendung muss dafür sorgen, dass alle anfallenden Daten permanent und konsistent gespeichert werden. Diese Konsistenz muss auch bei der Änderung und Entfernung von installierten Tools und erstellten Aufgaben gewährleistet werden. Die Web-Anwendung sollte eine gute Ergonomie besitzen. Anordnung und Funktionsweise der Bedienelemente sollten dem aus anderen Web-Anwendungen üblichen Aufbau entsprechen. Der Anwender sollte Elemente und Strukturen vorfinden, die ihm bekannt sind, um eine schnelle und intuitive Bedienung zu garantieren.

11 3 Software-Metriken Um die Entwicklung von Software steuern zu können, muss man die Eigenschaften eines Software-Produkts und den Fortschritt des Entwicklungsprozess in irgend einer Form messen können. Software-Metriken sind hier ein Hilfsmittel, das es ermöglicht diese Eigenschaften in einer greifbaren Form darzustellen. Dabei definieren die Software-Metriken, wie eine Kenngröße eines Software-Produkts oder Software-Prozesses gemessen wird. Für den Entwicklungsprozess können Kenngrößen für den Ressourcenaufwand, wie z.b. verfügbare Mitarbeiter, Zeit und Kosten, ermittelt werden. Diese Größen sind sehr wichtig für die Planung des Gesamtprojekts und können zur Optimierung der Ressourcenverteilung genutzt werden. Des Weiteren kann man den Kommunikationsaufwand im Projektteam und die Art und Häufigkeit von aufgetretenen Fehlern messen. So weißt beispielsweise ein sehr hoher Kommunikationsaufwand auf ein zu großes Projektteam oder auf eine schlechte Infrastruktur hin. Die Kenngrößen für ein Software-Produkt spiegeln die konkreten Merkmale der Software wieder. Der Begriff Software-Produkt bezeichnet hier nicht nur das fertige Programm, sondern alle bei der Entwicklung entstanden Dokumente, darunter unter anderem die Dokumentation und den Quellcode. Für ein Software-Produkt können eine Vielzahl von Kenngrößen ermittelt werden. So kann man den Umfang des Quellcodes und die Komplexität der einzelnen Funktionen messen. Diese Größen geben z.b. Hinweise auf die Fehlerwahrscheinlichkeit in bestimmten Modulen. Dadurch ist schließlich auch ein gezielteres Testen der Software möglich. Weitere Größen geben Hinweise auf die Qualität von Entwurf und Produkt. So kann beispielsweise eine Größe für die Kopplung von unterschiedlichen Modulen untereinander bestimmt werden. Für viele Größen existieren Grenzwerte, die man einhalten sollte um eine gute Qualität und Produktivität zu erzielen. Dabei ist zu beachten, dass diese Werte keine absoluten Grenzen darstellen, sondern eher als Richtwerte zu verstehen sind. Die Werte stammen meist aus Erfahrungswerten und können von Projekt zu Projekt variieren. Ebenso existieren keine universellen Standards für Metriken, die sich für jedes Projekt eignen, sondern die Metriken müssen stets an das jeweilige Einsatzgebiet angepasst werden. Dabei sollte aber jede Metrik die folgenden Gütekriterien erfüllen[zel03]: Objektivität: Die Messung sollte nicht von subjektiven Einflüssen des Messenden beeinträchtigt werden. Zuverlässigkeit: Bei einer Wiederholung der Messung und unveränderter Ausgangssituation sollte die Messung die gleichen Ergebnisse als bei der vorherigen Messung liefern.

12 3.1 Umfangs-Metriken 6 Normierung: Es gibt eine Skala für Messergebnisse und eine Vergleichbarkeitsskala. Vergleichbar: Die gemessene Größe sollte man mit anderen Maßen in Relation setzen können. Nützlichkeit: Die Messung hat einen praktischen Nutzen. Ökonomie: Die Kosten für die Messung werden durch den Nutzen für den Gesamtprozess gerechtfertigt. Validität: Die Messergebnisse ermöglichen einen Rückschluss auf die tatsächliche Eigenschaft. Dieses Kriterium ist oft nur schwer zu erfüllen. Für diese Arbeit sind nur die Produkt-Metriken von Interesse, da zum Zeitpunkt der Bewertung durch die zu entwickelnde Anwendung keine Daten über den gesamten Zeitraum des Entwicklungsprozesses vorliegen. Die Kenngrößen des Software-Produkts können dagegen alle ermittelt werden, sobald das zu bewertende Produkt der Anwendung vorliegt. Nachfolgend werden einige gängige Software-Metriken vorgestellt und anhand von konkreten Beispielen verdeutlicht. Die beschriebenen Metriken ermitteln typische Kenngrößen des Quellcodes und des Entwurfs. 3.1 Umfangs-Metriken Umfangs-Metriken sind die einfachsten und ältesten Metriken zur Bestimmung der Größe und Strukturierung von Software-Produkten. Zur Bestimmung der Kennzahlen werden die Programmzeilen im Quellcode gezählt. Hier ergeben sich unterschiedliche Maße durch die Art der gezählten Zeilen. Daher ist es wichtig, dass vor einer Messung genau definiert wird, was gezählt wird und was nicht. Gängige Maße sind: LOC(Lines Of Code) Die Anzahl aller Zeilen einer Quelldatei. NCSS (Non-Commented Source Statements) Die Anzahl aller Zeilen einer Quelldatei ohne Leerzeilen und Zeilen, die nur aus einem Kommentar bestehen. Das Verhältnis von der Anzahl effektiver Programmzeilen (NCSS) und der Anzahl von Zeilen, die nur aus einem Kommentar bestehen. Allgemeine Grenzwerte für diese Maße sind nur schwer festzulegen, da die Anzahl der benötigten Programmzeilen für eine bestimmte Funktion von Programmiersprache zu Programmiersprache stark variieren kann. Für ein in Java geschriebenes Programm lassen sich folgende Aussagen machen: Eine Funktion sollte zwischen 4 und 40, eine Datei zwischen 4 und 400 Programmzeilen haben. Dateien, die über 400 Zeilen haben, sind in der Regel zu lang, um als Einheit verstanden zu werden. Der Anteil der Kommentarzeilen sollte zwischen 30 und 75 Prozent liegen. Die Vorteile von Umfang-Metriken liegen darin, dass sie extrem einfach zu messen sind und garantiert auf jede Art von Programm anwendbar sind. Die Nachteile sind die Sprachabhängigkeit und die geringe Aussagekräftigkeit. So kann man z.b. nicht annehmen, dass ein Mitarbeiter, der viele lines of code erstellt, automatisch sehr produktiv ist, denn besser strukturierte Programme können einen deutlich geringeren Umfang haben[jk04].

13 3.2 Halstead-Metriken Halstead-Metriken Die Halstead-Metriken messen die Komplexität des Software-Produktes anhand der textuellen Komplexität des Quellcodes. Dazu wird der Quellcode in Operatoren (Symbole, die den Wert und die Anordnung eines Operanden beeinflussen) und Operanden (Konstanten und Variablen) aufgeteilt. Nun wird die Gesamtzahl der Operatoren und Operanden (N 1 und N 2 ) sowie die Anzahl der verschiedenen Operatoren und Operanden (η 1 und η 1 ) in der vorliegenden Implementierung gemessen. Aus diesen Basisgrößen lassen sich weitere Größen ableiten: Größe des gesamten Vokabulars Länge der Implementierung η = η 1 + η 1 (3.1) N = N 1 + N2 (3.2) Die Schwierigkeit (difficulty) ein Programm zu verstehen. Dabei gibt N 2 /η 2 das durchschnittliche Auftreten jedes Operanden an D = η 1 2 N 2 η 2 (3.3) Der Umfang (volume) bzw. der Informationsgehalt der Implementierung in Bits, in Abhängigkeit von der verwendeten Programmiersprache V = N log 2 η (3.4) Der Aufwand (effort) um das gesamte Programm zu implementieren oder zu verstehen E = D V (3.5) Die Zeit (time), die nötig ist, um das Programm zu implementieren in Sekunden. Der Wert ist proportional zum Aufwand zum Implementieren des Programms. Die Kalibrierung dieses Wertes kann mit Hilfe empirischer Experimente erfolgen. Halstead fand heraus, dass eine Division des Aufwands durch 18 eine gute Annäherung an die tatsächliche Zeit zum Implementieren des Programms liefert T = E/18 (3.6) Durch Volumenmessungen für Dateien, deren Programmzeilenanzahl und Cyclomatic Number 1 an den empfohlenen Grenzen liegen, ergeben sich für das Halstead-Volumen V folgende Richtwerte: V sollte für eine Funktion zwischen 20 und 1000 liegen. Bei Volumen über 1000 macht die Funktion zu viele Dinge. Das Volumen V einer Datei sollte zwischen 100 und 8000 liegen. Die Halstead-Metriken sind einfach zu berechnen und für jede Programmiersprache einsetzbar. Zudem belegen Experimente, dass die Halstead-Metriken ein gutes Maß für 1 siehe Kap. 3.3

14 3.3 McCabe-Metrik 8 die Komplexität sind. Ein Nachteil ist die Tatsache, dass diese Metriken nur die lexikalische bzw. textuelle Komplexität widerspiegeln und moderne Programmierkonzepte wie Namensräume und die Sichtbarkeit nicht berücksichtigt werden. Nachfolgend wird die Berechnung der Halstead-Metriken anhand eines Beispiels demonstriert. Abbildung 3.1 zeigt den Quellcode einer kurzen Funktion. Abb Beispiel - Halstaed - Quellcode Für dieses Beispiel ergeben sich folgende Werte: η = = 26 N = = 36 D = = 6 4 = 24 V = 36 log , 7 = 169, 2 E = , 2 = 4060, 8 T = 4060, 8/18 = 225.6sek = 3.76min 3.3 McCabe-Metrik Die McCabe-Metrik misst, wie auch die Halstead-Metriken, die Komplexität eines Programms. Allerdings beruht die Messung hier nicht auf der textuellen Komplexität des Quellcodes, sondern auf der Komplexität des Kontrollflusses. Als Ausgangspunkt für die Berechnung der so genannten Zyklomatischen Komplexität V (G), dient der Kontrollflussgraph eines Programms. Die Zyklomatische Komplexität misst die Anzahl der linear unabhängigen Wege durch den Kontrollflussgraph. Wenn der Kontrollflussgraph aus e Kanten, n Knoten und p Zusammenhangskomponenten besteht, berechnet sich die Zyklomatische Komplexität wie folgt:

15 3.3 McCabe-Metrik 9 V (G) = e n + 2p (3.7) Ein Knoten besteht dabei aus einem Block sequenzieller Anweisungen, die keine internen Verzweigungen aufweisen und eine Kante bezeichnet einen möglichen Kontrollfluss zwischen zwei Knoten. Als Zusammenhangskomponenten werden unabhängige Programmstrukturen, wie z.b. Prozeduren oder Module, bezeichnet. Ein Programm besteht immer aus mindestens einer Programmstruktur. Deshalb gilt p 1. Wenn p = 1 ist kann man folgende Formel aufstellen: V (G) = π + 1 (3.8) Die Variable π steht hier für die Anzahl der Verzweigungsbedingungen im Programm. Man kann sagen, dass ein Programm mit eine Zyklomatischen Komplexität von mehr als 10 besonders fehleranfällig ist. Weiterhin existiert folgende Faustregel: V (G) Risiko 1 10 einfaches Programm, geringes Risiko komplexeres Programm, erträgliches Risiko komplexes Programm, hohes Risiko > 50 untestbares Programm, extrem hohes Risiko Der Vorteil der McCabe-Metrik liegt darin, dass sie einfach zu berechnen ist. Es genügt ein Parser um die Kontrollflussstruktur zu bestimmen. Ebenfalls eignet sich das Maß besonders gut zur Integration in die Test-Planung, da hieraus beispielsweise Aussagen über den Aufwand für das Erreichen einer Bedingungsüberdeckung gemacht werden können. Des Weiteren zeigen Studien, dass eine gute Korrelation zwischen der Zyklomatischen Komplexität und dem Verstehen einer Komponente existiert. Die Schwächen der Metrik liegen darin, dass nur der Kontrollfluss zur Bestimmung der Komplexität betrachtet wird. Die Komplexität des Datenflusses wird nicht berücksichtigt, obwohl der Datenfluss zwischen den verschiedenen Komponenten durchaus komplex sein kann. Für die objektorientierte Programmierung eignet sich die McCabe-Metrik auch eher schlecht, da hier häufig sehr viele triviale Methoden entstehen. Das folgende Beispiel verdeutlicht die Berechnung der Zyklomatischen Komplexität. Abbildung 3.2 zeigt den Kontrollfluss-Graph der zuvor (siehe Abb. 3.1) eingeführten Beispielfunktion. Für diesen Kontrollflussgraph lassen sich folgende Werte berechnen: e = 7, n = 6, p = 1 V (G) = = 3 π = 2 p = 1 V (G) = = 3

16 3.4 Metriken für OO-Programmierung 10 Abb Beispiel - McCabe - Kontrollflussgraph 3.4 Metriken für OO-Programmierung In objektorientierten Programmen versagt die McCabe-Metrik, da die Kontrollflusskomplexität der meisten Methoden sehr gering ist (V (G) = 1). Metriken für die objektorientierte Programmierung müssen deshalb das Zusammenspiel der Klassen betrachten. Dies geschieht typischerweise anhand des statischen Klassenmodells. Zum Messen der verschiedenen Beziehungen der Klassen untereinander existiert eine Vielzahl von Metriken. Im folgenden wird eine Auswahl beschrieben, die gute Hinweise auf die Fehleranfälligkeit einer Klasse liefern[hol02]: DIT (Depth of Inheritance Tree) Gibt die Anzahl der Oberklassen einer Klasse an. Je größer DIT, desto größer ist die Fehlerwahrscheinlichkeit in der Klasse. NOC (Number of Children of a Class) Gibt die Anzahl direkter Unterklassen an. Je größer NOC, desto geringer ist die Fehlerwahrscheinlichkeit in der Klasse. Eine Ausnahme bilden Klassen der graphischen Benutzeroberfläche. RFC (Response For a Class) Gibt die Anzahl der Methoden an, die potentiell ausgeführt werden können, wenn ein Objekt auf eine eingehende Nachricht reagiert. Je größer RFC, desto größer ist die Fehlerwahrscheinlichkeit in der Klasse. WMC (Weighed Methods per Class) Gibt die Anzahl der in der Klasse definierten Methoden an. Je größer WMC, desto größer ist die Fehlerwahrscheinlichkeit in der Klasse. CBO (Coupling Between Object Classes) Gibt die Anzahl der Klassen an, mit denen eine Klasse gekoppelt ist (auf deren Dienste sie zugreifen kann). Je größer CBO, desto größer ist die Fehlerwahrscheinlichkeit in der Klasse. Folgend werden die beschriebenen Metriken an einem kleinen Beispiel erläutert. Abbildung 3.3 zeigt typische Beziehungen zwischen Klassen, wie sie bei der objektorientierten Programmierung entstehen.

17 3.4 Metriken für OO-Programmierung 11 Abb Beispiel - OO - Klassendiagramm Für dieses Klassendiagramm erhält man folgende Werte: DIT (A) = 0; DIT (G) = 1; DIT (H) = 2 NOC(A) = 2; NOC(B) = 0; NOC(F ) = 3 RF C(A) = 4; RF C(B) = 0; RF C(C) = 1 W MC(A) = 2; W MC(B) = 0; W MC(C) = 1 CBO(A) = 4; CBO(B) = 1; CBO(G) = 0

18 4 Ant Ant 1 (Another Neat Tool) ist ein Java-basiertes build-werkzeug. Mit Hilfe dieses Werkzeugs ist es möglich, die Übersetzung sowie alle damit verbundenen Operationen von komplexen Programmen vollständig zu automatisieren. Es ähnelt ein wenig dem aus der Unix/Linux-Welt bekannten Make. Ein Ziel bei der Entwicklung von Ant war unter anderem, die Schwierigkeiten, die Make mit sich bringt, zu beheben. Neben einer plattformunabhängigen Lösung wurde vor allem eine einfachere Syntax angestrebt. Diese Ziele wurden durch die Kombination von Java und XML erreicht: Java als plattformunabhängige Programmiersprache und XML als systemübergreifendes Dateiformat. Ant arbeitet mit sogenannten build-dateien, die im XML-Format vorliegen. In diesen Dateien werden alle Befehle aufgelistet, die beim Aufruf des Werkzeugs ausgeführt werden. Dabei wird ein solcher Befehl hier task genannt. Gerade für die Entwicklung mit Java stellt Ant eine Reihe nützlicher tasks bereit. So existieren beispielsweise tasks zum Compilieren (javac), zum Ausführen (java), zum Archivieren (jar) und zum Erzeugen einer Dokumentation (javadoc). Daneben gibt es weitere tasks, die den Zugriff auf das Dateisystem ermöglichen. Dazu gehören unter anderem das Kopieren, Verschieben und Löschen von Dateien, das Erzeugen von Verzeichnissen und noch viele weitere nützliche Operationen. Zusätzlich zu den bereits vorhanden tasks können auch Eigene definiert werden, wodurch der Einsatz von Ant in vielen Bereichen möglich ist. Alle einzelnen tasks müssen einer bestimmten Gruppe zugeordnet sein. Eine solche Gruppe fasst alle tasks zusammen, die nötig sind um ein spezielles Ziel zu erreichen. Deshalb werden die Gruppen auch als targets bezeichnet. Zwischen den verschiedenen Gruppen können Abhängigkeiten definiert werden. Zum Beispiel können die.class-dateien erst in einer jar-datei archiviert werden, nachdem die.class-dateien durch das Compilieren des Quellcodes erzeugt wurden. Existiert nun ein target, das fürs Compilieren zuständig ist und ein Anderes, das das Archivieren übernimmt, muss das target zum Archivieren von dem taget zum Compilieren abhängig sein. Um nun ein solches Antskript auszuführen, genügt es, in das Verzeichnis zu wechseln, in dem sich die build-datei befindet und das Kommando ant aufzurufen. Heißt die build-datei build.xml, wird sie automatisch erkannt und ausgeführt. Andernfalls muss dem Kommando der Name der Datei als Argument übergeben werden. Durch den Aufruf dieses Kommandos wird genau das target ausgeführt, das in der build-datei als Standardverhalten angegeben ist. Es ist aber auch möglich ein anderes target aufzurufen. Dazu muss dem Kommando der Name des gewünschten tagets als Argument übergeben 1

19 4 Ant 13 werden. Vor der Ausführung eines bestimmten targets werden zunächst alle eventuellen Abhängigkeiten berücksichtigt und die dazu entsprechenden targets ausgeführt[mor05]. Ant ist ein open-source Projekt von Apache 2 und unter der GNU General Public License frei verfügbar. Weitere Informationen sind auf der Entwicklerseite verfügbar. 2

20 5 Überblick und Grundkonzept Die in dieser Arbeit entstandene Anwendung nennt sich ASB, was für Automatische Software-Bewertung steht. Nachfolgend werden einige grundlegende Überlegungen und Konzepte vorgestellt, die zum Verständnis und der Benutzung des Programms wichtig sind. 5.1 Grunddesign Die Anwendung ist eine Client-Server-Anwendung. Das heißt, der Server stellt eine bestimmte Funktionalität zur Verfügung und der Client kann diese nutzen. In diesem Fall ist der Server ein Servlet-Container, in dem die eigentliche Anwendung als Web-Anwendung installiert wird. Als Client kann jeder übliche Web-Browser genutzt werden, denn die Benutzerschnittstelle bilden HTML-Seiten, die dynamisch von der Web-Anwendung erzeugt werden. Diese Architektur ermöglicht es, dass die eigentliche Anwendung nur zentral auf einem Rechner installiert werden muss und doch von jedem anderen Rechner, in einem entsprechend konfigurierten Netzwerk, genutzt werden kann. Denn ein Web-Browser gehört heute zur Grundausstattung jedes Arbeitsplatz-Rechners. Die gesamte Datenhaltung der Anwendung wird von einer Datenbank übernommen. Dazu kommuniziert die Web-Anwendung mittels eines JDBC-Treibers mit der Datenbank. Durch die Trennung der eigentlichen Funktionalität, in Form der Web-Anwendung, von der permanenten Datenhaltung, in einer Datenbank, entstehen viele Vorteile. So muss in der Anwendung kein eigenes Konzept für die dauerhafte und konsistente Speicherung von Daten erstellt werden, sondern man kann die Mechanismen einer relationalen Datenbank zur Vermeidung von Inkonsistenzen und Redundanz nutzen, die dort ohnehin schon vorhanden sind. Des Weiteren reicht es für eine Datensicherung aus, ein Backup der Datenbank zu erstellen, um alle Anwendungsdaten zu sichern. Mit der Annahme, dass weitere Anwendungen das gleiche DBMS (Data Base Management System) nutzen, genügt ein Backup des DBMS um die Anwendungsdaten aller Anwendungen zu sichern. Ebenfalls ist es möglich die Web-Anwendung und die Datenbank physikalisch zu trennen, indem das DBMS auf einem anderen Rechner installiert ist als der Servlet-Container. Da möglichst jedes Tool in die Anwendung integriert werden können soll, ist der Prozess zum Ausführen eines Tools sehr allgemein gehalten. Das heißt konkret, dass für jede Ausführung eines Tools ein neuer Betriebssystem-Prozess gestartet wird. Damit kann jedes Programm als Tool verwendet werden, das auf dem Betriebssystem des Server- Rechners lauffähig ist. Das Kommando zum Aufruf eines Tools ist gleich dem Kommando,

21 5.2 Benutzer und Rollen 15 welches in einer Kommandoshell zum Aufruf des Programms benutzt wird, obwohl keine Kommandoshell zum Aufruf verwendet wird. Funktionen der Shell, wie z.b. die Ein- und Ausgabestromumleitung (kommando > datei.txt) können also nicht verwendet werden. 5.2 Benutzer und Rollen Die Web-Anwendung wird von unterschiedlichen Personen benutzt, die jeweils unterschiedliche Funktionalitäten benötigen. So muss z.b. ein Professor eine Aufgabe erstellen und ein Student eine Lösung zu der Aufgabe hochladen können. Dementsprechend muss die Anwendung dem Benutzer die jeweils benötigte Funktionalität zur Verfügung stellen und gleichzeitig dafür Sorge tragen, dass der Benutzer kein Zugriff auf Funktionen erhält, für die er keine Berechtigung hat. Um diese Anforderungen zu erfüllen wird eine rollenbasierte Authentifizierung verwandt. Dabei hat ein Benutzer keine speziellen Rechte, sondern die Rechte werden Rollen zugeordnet. Die Rollen werden wiederum den Benutzern zugeordnet, wobei ein Benutzer auch mehrere Rollen haben kann. Um nun zu prüfen, ob ein Benutzer eine bestimmte Berechtigung hat, muss zuerst geprüft werden, ob dieser sich korrekt authentifiziert hat. Ist dies der Fall, muss ihm mindestens eine Rolle zugeordnet sein, die die entsprechende Berechtigung besitzt. ASB verwendet drei verschiedene Rollen: Student, Professor und Administrator. Benutzer, die diesen Rollen entsprechen, stellen alle unterschiedliche Anforderungen an die Anwendung und haben alle ein unterschiedliches Vertrauensniveau. So wird ein Student als am wenigsten vertrauenswürdig angenommen. Professoren wird grundsätzlich vertraut und Administratoren auf jeden Fall. Deshalb wird in dieser Anwendung jedem Benutzer genau eine Rolle zugeordnet. Die Kontrolle der Zugriffberechtigung für eine bestimmte Funktionalität erfolgt mittels der URL, durch die auf die Funktion zugegriffen wird. Eine Funktion der Anwendung kann dabei unter mehreren verschieden URLs erreichbar sein, denn der Aufbau der jeweiligen URL legt die jeweils benötigten Zugriffsrechte fest. Dabei existieren vier verschiedene Sicherheitsbereiche: Eine URL, die nach dem Präfix der Web-Anwendung den Zusatz /intern/ enthält, ist für alle angemeldeten Benutzer zugänglich. Nicht angemeldete Benutzer haben hierauf keinen Zugriff. Enthält die URL nach dem Präfix der Web-Anwendung den Zusatz /intern/stud/, ist diese nur für angemeldete Benutzer in der Rolle eines Studenten zugänglich. Das gleiche gilt entsprechend für die Zusätze /intern/prof/ und /intern/admin/ für Benutzer in den Rollen Professor und Administrator. Soll eine Funktion für mehrere Benutzergruppen verfügbar sein, aber nicht für alle, muss für jede Benutzergruppe eine eigene URL eingerichtet werden, unter der die jeweilige Gruppe die Funktion erreichen kann. So ist z.b. die Benutzerverwaltung unter den URLs /ASB/intern/prof/UserManagement und /ASB/intern/admin/UserManagement erreichbar. Professoren müssen die Erste verwenden und Administratoren die Zweite. Für einen Benutzer in der Rolle eines Studenten gilt noch eine besondere Beziehung. So ist er immer genau einem Professor, seinem Betreuer, zugeordnet. Er muss sich bei diesem registrieren und kann auch nur Lösungen zu Aufgaben dieses Professors hochladen. Wird dieser Betreuer aus dem System gelöscht, so werden auch alle ihm zugeordneten Studenten und deren Daten aus dem System gelöscht.

22 6 Benutzerhandbuch 6.1 Inhalt Die Web-Anwendung ASB wird in drei Versionen ausgeliefert. Die Quellcode-Variante(src), die alle Dateien enthält um das Programm neu zu erzeugen. Zusätzlich zu diesen Dateien enthält die bereits übersetzte Variante(build) die fertige und lauffähige Web-Anwendung. Die dritte Variante(dist) enthält ausschließlich die fertige Web-Anwendung, die in Form einer Web-Archiv-Datei(WAR) vorliegt, und die Dokumentation des Programms. Die einzelnen Versionen befinden sich in unterschiedlichen ZIP-Archiven: 1. ASB-src.zip: enthält alle Quelldateien und verwendeten Bibliotheken; Größe: 5,9 MB 2. ASB-build.zip: enthält zusätzlich die fertig übersetzte Anwendung und die Dokumentation; Größe: 7,1 MB 3. ASB-dist.zip: enthält nur die fertige Web-Anwendung mit allen benutzten Bibliotheken und die Dokumentation; Größe: 6,2 MB Die Quellcode-Variante besteht aus folgenden Dateien und Verzeichnissen: src: dieses Verzeichnis enthält alle Quellcode-Dateien(.java) der Web-Anwendung. web: hier befinden sich alle Dateien der Web-Anwendung, die kein Quellcode sind. Dies sind z.b. einfache HTML-Dateien oder JSP-Dateien. Aber auch Dateien, die für die Konfiguration der Anwendung wichtig sind und alle Bibliotheken, auf die die Anwendung zugreift. docs: in diesem Verzeichnis sind alle Dokumente untergebracht, die zusätzlich zu der mit javadoc erstellten Dokumentation in die Gesamtdokumentation der Anwendung übernommen werden sollen. DBSetup.sql: diese Datei enthält das Skript zum Einrichten der Datenbank mittels SQL. build.xml: das ist das Ant-Skript zum Kompilieren der Anwendung. Darüber hinaus kann die Web-Anwendung hiermit im Servlet-Container installiert werden, sofern der Apache Tomcat 5.5 benutzt wird. build.properties: dies ist die Konfigurationsdatei für das Ant-Skript. license.txt : beinhaltet die Lizenz (GNU General Public License), unter der dieses Programm erhältlich ist. readme.txt : enthält diese Information.

23 6.2 Systemvoraussetzungen 17 Die bereits kompilierte Variante enthält zusätzlich zu dieser Struktur noch ein weiteres Verzeichnis: build: in diesem Verzeichnis befindet sich die übersetzte Web-Anwendung. Die enthaltene Dateistruktur entspricht dem korrekten, standardisierten Aufbau einer Web- Anwendung. Die Variante, die nur die fertige Web-Anwendung enthält, hat folgende Struktur: docs: in diesem Verzeichnis befindet sich die komplette Dokumentation der Web- Anwendung. AutomatischeSoftwareBewertung.war: dieses Archive enthält die gesamte, komprimierte Web-Anwendung. Die meisten Servlet-Container bieten die Möglichkeit eine Web-Anwendung auch in Form eines solchen Web-Archivs zu registrieren. DBSetup.sql: diese Datei enthält das Skript zum Einrichten der Datenbank mittels SQL. license.txt : beinhaltet die Lizenz (GNU General Public License), unter der dieses Programm erhältlich ist. readme.txt : enthält diese Information. 6.2 Systemvoraussetzungen Die Web-Anwendung ASB ist kein eigenständig lauffähiges Programm. Vielmehr benötigt das Programm eine bereits bestehende Infrastruktur, in die es integriert werden muss. Diese Infrastruktur besteht aus einem Servlet-Container, in dem die Web-Anwendung installiert wird, und aus einer relationalen Datenbank, die zur Verwaltung der permanenten Daten verwendet wird. Damit ergeben sich die Systemanforderungen von ASB aus der Summe der jeweiligen Anforderungen, die die einzelnen Komponenten der Infrastruktur an das System stellen. Diese können je nach verwendetem Servlet-Container und Datenbank ganz unterschiedlich ausfallen. Einige Anforderungen sind allerdings in allen Konfigurationen gleich. Zum einen benötigt der Servlet-Container ein JDK (Java Development Kit), das zur Version 1.4 kompatibel ist, um JSP (Java Server Pages) Dokumente zur Laufzeit übersetzen zu können. Steht nur eine JRE (Java Runtime Environment) zur Verfügung, müssen alle JSP-Dateien vorkompiliert werden, bevor sie in den Container installiert werden. Zum anderem muss die Datenbank sowie das System, auf dem sie installiert ist, und das System, auf dem der Servlet-Container läuft, das TCP/IP-Netzwerkprotokoll unterstützen. Des weiteren muss für das verwendete Datenbankprodukt ein JDBC-Treiber (Java Database Connectivity) erhältlich sein, mittels dessen die Anwendung mit der Datenbank kommunizieren kann. Zum Entwickeln und Testen wurde der Servlet-Container Tomcat von Apache in der Version 5.5 benutzt. Dieser verlangt als Mindestanforderung eine J2SE 5 JRE. Das heißt, die Laufzeitumgebung der Java 2 Plattform in der Standard Edition. Um JSP-Dokumente zur Laufzeit übersetzen zu können, ist allerdings das entsprechende JDK nötig. Falls die Java-Laufzeitumgebung nur in der Version 1.4 vorliegt, muss ein zusätzliches Kompatibilitäts-Paket installiert werden. Die Datenbank muss nicht auf dem gleichen System wie der Servlet-Container installiert sein, sondern kann sich auch auf einem anderen Rechner im Netzwerk befinden. In

24 6.3 Installation und Start 18 der Entwicklungsumgebung wurde das frei erhältliche DBMS MySQL in der Version 4.1 verwendet. Dieses stellt folgende Anforderungen an ein Windows-System: Ein Windows- Betriebssystem, wie z.b. 9x, Me, NT, 2000, XP oder Windows Server 2003; ein Werkzeug, das ZIP-Archive extrahieren kann, zum Entpacken der Installations-Datei; genügend Speicherplatz auf der Festplatte, um das System zu installieren und die benötigten Datenbanken anzulegen, ein Minimum von 200 MB wird empfohlen. Die Verbindung zu dem MySQL-Server erfolgt über den Standard-JDBC-Treiber von MySQL, Connector/J in der Version Der Treiber benötigt ein JDK mindestens in der Version Installation und Start Bei den folgenden Ausführungen wird davon ausgegangen, dass der Servlet-Container und die Datenbank bereits installiert sind. Falls dies nicht der Fall ist, entnehmen sie die Installationsanleitung der Dokumentation der jeweiligen Produkte. Des Weiteren wird davon ausgegangen, dass der Tomcat Servlet-Container und die MySQL Datenbank verwendet wird. Bei der Verwendung anderer Produkte kann die Installation von den folgenden Ausführungen abweichen. Bevor die eigentliche Web-Anwendung installiert werden kann, sind zuvor noch einige andere Arbeiten zu erledigen: 1. Installation des JDBC-Treibers: Um die Kommunikation mit dem Datenbank- Server herzustellen muss als erstes ein passender JDBC-Treiber installiert werden. Dazu muss die Datei mysql-connector-java bin.jar in dem Verzeichnis CATALINA_HOME\common\lib platziert werden, wobei CATALINA_HOME das Installationsverzeichnis des Tomcat-Servers bezeichnet. Damit wird die Datei und alle Klassenbibliotheken, die sich in diesem Verzeichnis befinden, in den CLASSPATH aufgenommen und können von dem Servlet-Container und allen Web-Anwendungen benutzt werden. Des Weiteren ist hier noch eine Konfiguration des Servlet-Containers nötig, um die Datenbank als Datenquelle anzulegen. Bei Verwendung des Tomcat-Servers kann dies allerdings in die Konfiguration der Web-Anwendung ausgelagert werden um eine höhere Portabilität zu erhalten. Die Beschreibung folgt in Kapitel Konfiguration des Datenbanksystems: In der Konfiguration des MySQL-Servers muss die maximale Paketgröße einer Anfrage auf den Höchstwert von 16 MB gesetzt werden, damit größere Dateien mit bis zu 16 MB in der Datenbank abgelegt werden können. Dazu muss die Startoption max_allowed_packet gesetzt werden. Die ist beispielsweise durch Einfügen der Zeile max_allowed_packet=16m in der Datei MYSQL_HOME\my.ini möglich. Dabei ist zu beachten, dass die Zeile in dem Bereich der Datei steht, der für die Konfiguration des Servers zuständig ist und mit [mysqld] eingeleitet wird. Nach der Änderung muss der Datenbank-Server neu gestartet werden. 3. Einrichten der Anwendungs-Datenbank: Voraussetzung hierfür ist die Anmeldung bei dem Datenbank-Server als ein Benutzer, der die Rechte hat neue Benutzer anzulegen, diesen Berechtigungen zuzuordnen und neue Datenbanken und Tabellen anzulegen. Dann muss nur noch die Skript-Datei DBSetup.sql ausgeführt werden. Das Skript ist speziell für den MySQL-Server und muss gegebenenfalls bei der Verwendung eines anderen Datenbank-Produkts angepasst werden. In dem Skript wird der Benutzername und das Benutzerpasswort festgelegt, mit dem die Anwendung auf die Datenbank zugreift. Das Passwort lautet standardmäßig ASB_pw und sollte unbedingt geändert werden.