Webbasiertes Buchungssystem

Der Segelverein verwaltet derzeit etwa zehn Boote an der Außenalster in Hamburg mittels eines physischen Logbuchs. Das System leidet unter gravierenden Mängeln: Bei gutem Wetter kommt es zu Überbuchungen, da die Bootskapazität begrenzt ist und sich Segler vor Ort eintragen müssen. Dies führt zu Frustrationen bei Vereinsmitgliedern, die vergeblich zur Außenalster kommen, um ein Boot zu mieten. Die Reservierung ist lediglich eine Vormerkung im Logbuch, die nicht garantiert, dass das Boot zum gewünschten Zeitpunkt verfügbar ist, und erfordert immer noch einen persönlichen Besuch am Bootsanleger. Die ineffiziente Verwaltung des Bootsverleihs durch das manuelle System, insbesondere die Unmöglichkeit einer Fernreservierung und der daraus resultierenden Unannehmlichkeiten für die Vereinsmitglieder, zeigen die Notwendigkeit eines digitalen, effizienteren Systems zur Bootsreservierung. Die beschriebenen Ineffizienzen und Unannehmlichkeiten für die Mitglieder des Segelvereins unterstreichen die dringende Notwendigkeit für eine moderne Lösung zur Verwaltung des Bootsverleihs.

DiLog, das digitale Logbuch, bietet eine innovative Lösung für die bestehenden Probleme. Vereinsmitglieder können von zu Hause oder vom Arbeitsplatz aus über einen Webbrowser auf den DiLog-Server zugreifen. Sie geben ihren Wunschtermin und das gewünschte Boot ein und erhalten in Sekundenschnelle eine Auskunft über die Verfügbarkeit. Eine Reservierung erfolgt online und wird sofort per E-Mail bestätigt. Andere Mitglieder sehen die Buchung und wissen, dass das Boot für den gewählten Zeitraum belegt ist. Dieses System, das auf einer modernen Web-Anwendung basiert und eine effiziente Online-Reservierung ermöglicht, bietet gegenüber dem bisherigen manuellen System einen erheblichen Vorteil. Die sofortige Buchungsbestätigung per E-Mail und die Übersichtlichkeit der Belegung für alle Vereinsmitglieder sparen Zeit und verbessern die Benutzerfreundlichkeit deutlich. Die zentrale Verwaltung der Bootsreservierungen sorgt für eine präzise und transparentere Organisation des Bootsverleihs.

Die Wahl von Java als Programmiersprache für DiLog ermöglicht eine hohe Plattformunabhängigkeit. Der Compiler erzeugt Bytecode, der auf verschiedenen Betriebssystemen (Linux, Windows, MacOS, etc.) mit einer Java Virtual Machine (JVM) ausgeführt werden kann. Moderne JIT-Compiler gleichen die geringere Geschwindigkeit des Bytecodes nahezu aus. Die Entscheidung für eine Browser-basierte Anwendung vereinfacht den Zugriff für die Vereinsmitglieder, da die meisten bereits über Internetzugang und Browser verfügen. Das schlichte und intuitive Webdesign sorgt für eine benutzerfreundliche Oberfläche, selbst für weniger versierte Computeranwender. Die Kombination aus Java für die Backend-Entwicklung und einem Browser-basierten Frontend stellt eine plattformunabhängige und leicht zugängliche Lösung für die Mitglieder des Segelvereins dar. Die bewusste Entscheidung für ein einfach zu bedienendes Design erleichtert die Einarbeitung und steigert die Akzeptanz der Software.

DiLog basiert auf dem Model-View-Controller (MVC)-Muster, implementiert mit dem Struts-Framework. Struts vereinfacht die Entwicklung, indem es die Anwendung in drei Schichten (Model, View, Controller) unterteilt. Die View-Schicht, die Benutzeroberfläche, besteht hauptsächlich aus JavaServer Pages (JSPs), die dynamischen HTML-Inhalt generieren. Die Controller-Schicht, implementiert als Servlets, verarbeitet Benutzereingaben und steuert den Datenfluss zwischen Model und View. Das Model umfasst die Geschäftslogik und die Datenzugriffsschicht, welche über JavaBeans und die MySQL Datenbank interagiert. Die anfänglichen Schwierigkeiten mit Struts wurden im Laufe des Projekts überwunden, und das Framework erwies sich als sehr hilfreich für die Entwicklung und Wartung der Anwendung. Die Verwendung von Struts ermöglichte die Wiederverwendung von Code und vereinfachte die Implementierung neuer Funktionalitäten. Die Struts-Konfiguration erfolgt über lediglich zwei XML-Dateien (struts-config.xml und tiles-config.xml), was die Übersichtlichkeit und Wartbarkeit des Systems verbessert.

DiLog verwendet MySQL als relationales Datenbankmanagementsystem (RDBMS) zur Speicherung der Bootsdaten, Benutzerinformationen und Buchungen. Die Datenmodellierung erfolgte unter Berücksichtigung der Normalisierungsregeln, um Datenredundanz zu minimieren und die Datenkonsistenz zu gewährleisten. Die Konfiguration des Systems, beispielsweise die Definition der Boote, erfolgt über XML-Konfigurationsdateien. Diese XML-Dateien werden mit Hilfe der Java API for XML Processing (JAXP) und speziell mit dem DOM-Parser ausgelesen und verarbeitet. Die Wahl von XML ermöglicht eine klare Trennung von Daten und Präsentation, was die Flexibilität und Wartbarkeit der Konfiguration verbessert. Das System nutzt die Vorteile von XML für die Konfiguration und MySQL für die Datenhaltung, um ein robustes und skalierbares Datenmanagementsystem zu gewährleisten. Die Datenintegrität wird durch die Verwendung von Primärschlüsseln und Foreign Keys sichergestellt. Der Import und Export von Daten wird ebenfalls unterstützt, wobei Mechanismen implementiert sind um Datenkonsistenz auch während des Import-/Export-Prozesses zu gewährleisten.

Für das Session-Management setzt DiLog auf Session-Tracking mittels Cookies. Der Servlet-Container generiert eine eindeutige Session-ID, die im Browser-Cookie gespeichert wird. Alternativ wird URL-Rewriting eingesetzt, um die Session-ID in die URL einzubetten, falls der Benutzer Cookies deaktiviert hat. Servlets spielen eine zentrale Rolle in der Verarbeitung von Client-Anfragen und der Generierung der Antwort. Die Methoden doGet() und doPost() der HttpServlet-Klasse werden überschrieben, um auf verschiedene Anfragetypen zu reagieren. Die Sicherheit wird durch die Benutzerauthentifizierung und die Verwendung von Session-IDs gewährleistet. Der Zugriff auf bestimmte Funktionalitäten kann durch die Authrization-Klasse kontrolliert werden. Die Verwendung von Session-Beans ermöglicht die Speicherung von client-spezifischen Daten innerhalb einer Session. Die Implementierung von Session Management mittels Cookies und URL Rewriting sorgt für eine flexible und robuste Verwaltung von Benutzersitzungen.

DiLog verwendet Log4j für das Logging, um Fehlermeldungen und Systemereignisse zu protokollieren. Log4j ermöglicht die Ausgabe von Log-Einträgen auf die Konsole, in Dateien oder in GUI-Komponenten, was die Fehlersuche und -behebung deutlich vereinfacht. Das System integriert außerdem eine Webcam-Funktion, welche den Upload von Bildern ermöglicht. Diese Bilder werden serverseitig im Package webcam.server verarbeitet und gespeichert. Die Software generiert PDFs mit Hilfe der iText-Bibliothek, um Berichte oder andere Dokumente zu erstellen. Die PDFs sind standardisiert und enthalten definierte Header und Footer, sowie optional Verschlüsselung. Die Integration von Log4j, Webcam-Funktionalität, und PDF-Generierung erweitern die Funktionalität von DiLog und verbessern die Benutzerfreundlichkeit und Wartbarkeit der Anwendung. Die Verwendung von Standardbibliotheken und Frameworks ermöglicht eine effiziente Entwicklung und Wartung dieser zusätzlichen Funktionen.

DiLog erfordert eine Benutzerauthentifizierung mittels Benutzerkennung und Passwort. Diese Anmeldedaten können vom Benutzer jederzeit geändert werden. Die Authentifizierung findet beim Login statt. Die Authrization-Klasse prüft, ob ein Benutzer berechtigt ist, bestimmte Aktionen auszuführen. Fehlt die persId in der User-Session, wird der Zugriff verweigert und der Benutzer auf die Login-Seite weitergeleitet. Eine zweite Prüfung in der Authrization-Klasse kontrolliert, ob der Benutzerstatus ausreichend ist, um die gewünschte Seite aufzurufen. Bei fehlerhaften Anmeldeversuchen erhält der Benutzer eine entsprechende Meldung. Nach drei fehlgeschlagenen Versuchen wird er aufgefordert, sich mit den Initial-Anmeldedaten anzumelden. Die Anzahl der Fehlversuche wird pro Benutzer in der Datenbank verfolgt, um Missbrauch zu verhindern. Nach erfolgreicher Anmeldung mit den Initial-Daten muss der Benutzer neue Anmeldedaten festlegen, oder alternativ den Administrator per E-Mail kontaktieren, um neue Initial-Daten zu erhalten. Der Mechanismus der Benutzerauthentifizierung und -autorisierung ist ein wichtiger Sicherheitsaspekt von DiLog.

Angemeldete Benutzer erben alle Funktionen des Gast-Zugangs und erhalten zusätzliche Möglichkeiten. Sie können ihre persönlichen Daten und ihre Logindaten ändern. Die Kernfunktionalität von DiLog, die Buchung von Booten, steht natürlich auch nur für registrierte und authentifizierte Benutzer zur Verfügung. Diese Buchungen können später vom Benutzer bearbeitet werden. Die SessionTimeout-Klasse sorgt für das Aufräumen von Ressourcen am Ende einer Sitzung. Die Benutzerverwaltung umfasst die Möglichkeit zur Änderung von persönlichen Daten und Anmeldedaten, um die Flexibilität und den Komfort für die Benutzer zu gewährleisten. Die Integration dieser Funktionen in die Benutzerverwaltung von DiLog optimiert den Workflow und ermöglicht eine effektive Selbstverwaltung der Benutzerdaten.

DiLog verfügt über zwei Arten von Systemsperren: Eine scharfe Sperre loggt alle Benutzer sofort aus, und zeigt eine entsprechende Meldung beim nächsten Seitenaufruf an. Die freundlichere Variante sperrt nur neue Anmeldungen, lässt aber bereits eingeloggten Benutzern den weiteren Zugriff zu. Der Administrator kann über die Systemdaten die aktuell eingeloggten Benutzer einsehen. Session-IDs werden nach fehlerhaften Login-Versuchen in der Datenbank gespeichert und gezählt. Diese Maßnahmen schützen das System vor Missbrauch und ermöglichen eine kontrollierte Reaktion auf Sicherheitsvorfälle. Die Implementierung unterschiedlicher Sperrmodi ermöglicht es dem Administrator, flexibel auf verschiedene Situationen zu reagieren. Die Protokollierung der fehlerhaften Anmeldeversuche dient der Sicherheitsüberwachung und unterstützt die Identifikation potenzieller Sicherheitsbedrohungen.

DiLog nutzt MySQL als Datenbankmanagementsystem (DBMS). Das Datenmodell wurde normalisiert, um Redundanzen und Anomalien zu vermeiden. Die Normalisierung zielt auf Datenkonsistenz und vereinfachte Wartung ab. Das Schema erfüllt zumindest die zweite Normalform. Eine Ausnahme bildet das Attribut „Straße“, welches Straßenname und Hausnummer kombiniert. Für die Bootskonfiguration wird eine XML-Datei verwendet (boatconf.dilog.xml), welche die Datenstruktur und -beziehungen beschreibt. Das equalBoat-Tag adressiert die Herausforderung, dass ein Boot unter verschiedenen Namen geführt werden kann. Die XML-Datei beinhaltet Attribute wie accessname (für die Access-Datenbank), mysqlname (für die MySQL-Datenbank) und id (Primärschlüssel). Die Datenintegrität wird durch die Vermeidung von mehrfach vergebenen IDs und die Berücksichtigung bestehender Buchungen beim Löschen von Booten sichergestellt. Das Datenmodell ist darauf ausgelegt, die Datenkonsistenz und die einfache Verwaltung zu gewährleisten.

DiLog unterstützt den Import und Export von Daten zwischen MySQL und Microsoft Access. Dieser Prozess wird über ein grafisches Werkzeug gesteuert und ersetzt frühere, rein kommandozeilenbasierte Lösungen. Während des Import-/Export-Zyklus werden die entsprechenden Tabellen in MySQL gesperrt, um die Datenkonsistenz zu gewährleisten. Die Sperrung wird nach Abschluss des Imports automatisch aufgehoben, kann aber auch manuell aufgehoben werden, falls keine Änderungen in Access vorgenommen wurden. Diese Sperrmechanismen schützen die Daten vor Inkonsistenzen, die durch gleichzeitige Bearbeitung in beiden Datenbanken entstehen könnten. Die Möglichkeit des Datenimports und -exports ermöglicht flexible Datenverwaltung und Datenaustausch mit anderen Systemen. Die automatische Sperrung und die Möglichkeit zur manuellen Steuerung dieses Prozesses sind wichtige Maßnahmen, um die Datenintegrität während des Import-/Export-Vorgangs zu garantieren.

Das Datenmodell in DiLog wurde in mehreren Schritten optimiert. Ein unnormalisiertes Modell (Ebene A) zeigt anfängliche Redundanzen auf. Durch die Aufteilung der Tabellen (Ebene B) werden Redundanzen reduziert. Die Einführung einer separaten Tabelle für Boote (Ebene C) behebt das Problem, dass bei jedem neuen Boot die Tabellenstruktur angepasst werden müsste. Diese Optimierung stellt sicher, dass neue Boote hinzugefügt und Segelberechtigungen verändert werden können, ohne den Code zu ändern. Foreign Key Constraints verhindern Dateninkonsistenzen beim Löschen von Booten, indem sie das Löschen verhindern, wenn noch verknüpfte Segelberechtigungen existieren. Die konsequente Anwendung von Normalisierungsregeln und der Einsatz von Foreign Keys führt zu einem robusten und skalierbaren Datenmodell. Dieses verbesserte Datenmodell ermöglicht eine flexible Anpassung an zukünftige Erweiterungen des Systems, ohne die Integrität der Daten zu gefährden.

Die Entwicklung von DiLog erfolgte auf einem Windows-System (Windows XP Home). Als integrierte Entwicklungsumgebung (IDE) wurde Eclipse verwendet. Für die Bearbeitung von Textdateien, inklusive Konfigurationsdateien (Struts, XML, Server), HTML, CSS und JSP-Dateien, diente der Texteditor UltraEdit. Die Erstellung von UML-Diagrammen erfolgte mit der Software Together. Die benötigten Ressourcen erwiesen sich als knapp bemessen: 512 MB Arbeitsspeicher und ein Intel Pentium 3 Prozessor mit 1200 MHz Taktung reichten gerade so für ein flüssiges Arbeiten aus, insbesondere wenn alle benötigten Programme gleichzeitig ausgeführt wurden (Eclipse, Tomcat, Together, IETool, Apache, MySQL, MySQL-Front, MS Access, UltraEdit, Mail-Client, Acrobat Reader). Die Entwicklungsumgebung unter Windows ermöglichte den Einsatz gängiger Software zur Entwicklung und zum Testen der Anwendung. Die beschränkten Ressourcen zeigten die Komplexität des Projekts auf, das weit mehr als einen einfachen Prototypen darstellte.

Während der Entwicklungsphase gab es Schwierigkeiten bei der Installation von Apache 2 unter Windows. Ein Installationspaket mit integriertem SSL-Modul war zu diesem Zeitpunkt nicht auf der Apache-Website verfügbar. Die Alternative, Apache 2 mit C++ unter Windows zu kompilieren, wurde erwogen, aber letztlich fand der Entwickler eine bereits kompilierte Version im Internet. Der Einsatz einer Installation aus unsicherer Quelle wurde als kalkulierbares Risiko eingeschätzt, da es sich lediglich um die Entwicklungsumgebung handelte und keine Gefahr für Produktionsdaten bestand. Die Probleme mit der Apache-Installation zeigen die Herausforderungen, die während der Softwareentwicklung auftreten können und die Notwendigkeit, flexible Lösungen zu finden. Die Entscheidung, eine kompilierte Version aus einer unsicheren Quelle zu verwenden, unterstreicht den pragmatischen Ansatz des Entwicklers in der Entwicklungsumgebung.

Als Produktionsumgebung wird ein virtueller Server (vServer) der BSB Service GmbH (Tochter der intergenia AG) genutzt. Der vServer bietet für 10€ monatlich Root-Zugang, eine feste IP-Adresse, 2 GB Webspace und 50 GB Traffic pro Monat, inklusive einer de-Domain. Der Kunde kann zwischen verschiedenen Linux-Distributionen wählen (Red Hat 9, Fedora Core 1, SuSE Linux 9, Debian 3.1). Da kein X-Window-System installiert ist, erfolgt die Administration und Konfiguration ausschließlich über die Konsole. Für den verschlüsselten Zugriff via SSL werden Programme wie Putty und WinSCP2 verwendet. Die Wahl eines virtuellen Servers bietet Kosteneffizienz und Flexibilität für die Produktionsumgebung. Der Verzicht auf ein grafisches Interface für die Serveradministration spart Ressourcen und vereinfacht die Konfiguration. Die Auswahl an verschiedenen Linux-Distributionen zeigt die Anpassungsfähigkeit an unterschiedliche Anforderungen.

Das Struts-Framework spielte eine zentrale Rolle bei der Entwicklung von DiLog. Anfangs gestaltete sich die Entwicklung mit Struts aufgrund unerwarteter Fehlermeldungen schwierig. Im weiteren Verlauf des Projekts erwies sich Struts jedoch als äußerst hilfreich und vereinfachte die Entwicklung erheblich. Sobald die grundlegenden Abläufe implementiert waren, konnte auf bereits vorhandene Strukturen zurückgegriffen und Code wiederverwendet werden. Die einfache Konfiguration über lediglich zwei XML-Dateien (struts-config.xml und tiles-config.xml) trug wesentlich zur Übersichtlichkeit und zur Effizienz bei. Struts ermöglichte es, neue Funktionalitäten effizient zu implementieren und bereits vorhandenen Code mit minimalen Anpassungen wiederzuverwenden, was den Entwicklungsprozess deutlich beschleunigte und vereinfachte. Die positive Bilanz des Einsatzes von Struts unterstreicht die Bedeutung der Wahl geeigneter Frameworks für die Softwareentwicklung.

Die Entwicklung von DiLog erwies sich als weitaus umfangreicher und komplexer als ursprünglich geplant. Ein funktionierendes Softwaresystem benötigt neben der Kernfunktionalität auch umfassende unterstützende Komponenten wie Administration, Logging, Backup-Strategien, Konfiguration, Testläufe und Dokumentation. Der Aufwand für diese Aspekte wurde unterschätzt, was den gesamten Entwicklungsprozess in Anspruch nahm. Der Entwickler betonte den Unterschied zwischen der Entwicklung eines vollständigen Systems und einer lediglich abgegrenzten Teilfunktionalität oder einer Machbarkeitsstudie. Die Erfahrung zeigt, dass die Planung und der Aufwand für ein vollständiges System deutlich höher sind als anfänglich angenommen. Die Entwicklung eines funktionierenden Gesamtsystems erfordert neben der eigentlichen Software auch ein umfassendes „Rankwerk“ an administrativen und technischen Aufgaben, das nicht unterschätzt werden sollte.