Leseprobe
Gliederung
0. Abkürzungsverzeichnis
1. Einleitung
1.1. Motivation
1.2. Zielstellung
2. Aufbau der Dialoggestaltung und Auswahl von Projektkomponenten
2.1 Aufbau der Dialoggestaltung
2.1.1. Aufgabenangemessenheit
2.1.2. Selbstbeschreibungsfähigkeit
2.1.3. Steuerbarkeit
2.1.4. Erwartungskonformität
2.1.5. Fehlertoleranz
2.1.6. Individualisierbarkeit
2.1.7. Lernförderlichkeit
2.1.8. Fazit ISO
2.2. Wahl der Anzeigform beim Nutzer
2.3. Wahl der Scriptsprache
2.4. Wahl der Datenbank
2.5. Wahl des Webservers
3. Realisierung des Projektes
3.1. Erstellung der Datenbank
3.2. Das Tabellensystem des Projektes Fussballtippspiel
3.2.1. Tabelle für die Nutzerverwaltung
3.2.2. Tabelle für Login-Daten
3.2.3. Tabellen zum Speichern der Spielinformationen
3.2.4. Datenverwaltungstabellen
3.2.5. Tabelle für die Punkte der Nutzer
3.2.6. Tabelle für Nutzer-Teams
3.2.7. Weitere Tabellen
3.2.8. Primär- und Fremdschlüssel
3.3. Das Cookie-Konzept
3.3.1. Das Cookie-Konzept in der Theorie
3.3.2. Das Cookie-Konzept in der Praxis
3.3.2.1. indexd.php – Login
3.3.2.2. slogind.php – Loginüberprüfung & Cookie setzen
3.3.2.3. introd.php – Cookieüberprüfung und Verlängerung
3.4. Möglichkeiten von PHP und SQL
3.5. Administrator.php und choice.php – komfortables Adminstrieren
3.5.1. Auswahlpunkt 1: user
3.5.2. Auswahlpunkt 2: cuser
3.5.3. Auswahlpunkt 3: Teams
3.5.4. Auswahlpunkt 4: enter games – Spielansetzungen eintragen
3.5.5. Auswahlpunkt 5: enter results
3.5.6. Auswahlpunkt 6: show results
3.5.7. Auswahlpunkt 7: Show Comments
3.5.8. Auswahlpunkt 8: show latest logins
3.5.9. Auswahlpunkt 9: show used browsertypes
3.5.10. Auswahlpunkt 10: Nichttipper-Emailadressen
3.5.11. Auswahlpunkt 11: SQL-Query
3.6. Dateien des Nutzerinterface
3.6.1 betd.php – Tippabgabe
3.6.2. gespunkted.php – Anzeige der Gesamtpunkte
3.6.3. compared.php – Vergleich der Nutzertipps mit realen Spielausgang
3.6.4. optionsd.php – Einstellmöglichkeiten der Nutzer
3.6.5. overtopd.php – Anzeige der Highscore
3.6.6. singled.php – Anzeige eines bestimmten Nutzers
3.6.7. singled.php – Anzeige eines bestimmten Nutzers
3.6.8. suserd.php – Anzeige der Tipps eines bestimmten Nutzers
3.6.9. tovertopd.php – Teamgesamtwertung
3.6.10. tovertopsingled.php – Anzeige d. Teammitglieder u. Teamgesamtwertung
3.6.11. tweektopd.php – Wochenteamwertung
3.6.12. tweektopsingled.php – Teamaufstellung am Spieltag
3.6.13. statistikd.php – Wie wird getippt ?
3.6.14. statresd.php – Wie wurde getippt
3.7. Realisierung der Zweisprachigkeit
4. Fazit
5. Anlagen
6. Literaturverzeichnis
7. Thesen
0. Abkürzungsverzeichnis
Abbildung in dieser Leseprobe nicht enthalten
1. Einleitung
1.1. Motivation
Im Jahre 2006 wird in Deutschland die Fußballweltmeisterschaft stattfinden. Doch nicht erst dann werden sich Leute für Fußball interessieren. Denn seit es in Deutschland Fußball gibt, wird über Ergebnisse, Taktiken und Fouls kräftig diskutiert. Genau dieses geschieht auch in den Mittweidaer Studentenwohnheimen. Anfangs wurde nur auf dem Papier gewettet. Doch einigen Kommilitonen war dies nicht komfortabel genug. Sie entwickelten deshalb zur Fußballweltmeisterschaft in Südkorea ein manuelles Tippsystem, welches aber auf Grund seiner Architektur sehr zeitaufwändig für den Administrator war und für den User wenig Komfort aufwies [4]. Aus den Fehlern dieser Arbeit kann man unbedingt ersehen, wie sehr Nutzungswunsch und tatsächlicher Nutzen sich voneinander unterscheiden. Während eines Auslandssemesters in Schottland konnte ich dann auf Grund einer vorgeschriebenen Projektarbeit die Möglichkeit nutzen, mich mit dem Thema Fußballtippspiel auseinanderzusetzen.
1.2. Zielstellung
Wie bereits in Kapitel 1 dargestellt, gibt es viele sich untereinander sehr stark unterscheidende Möglichkeiten zur Lösung der Aufgabenstellung. Mit einfachstem Aufwand ist sicherlich das einfache Aufschreiben der Wetten möglich. Über verschiedene Möglichkeiten der Auswertung - sprich Punkte/Gewinnaufteilung - wird auf Grund der Irrelevanz für die Erfüllung der Aufgabenstellung keine Diskussion geführt. Die Auswertung bei der erstgenannten Möglichkeit gestaltet sich insofern als kompliziert, als das jeder einzelne Tipp manuell ausgewertet werden muss. Außerdem ist die Tippabgabe ja dann auch nur persönlich, allerhöchstens noch über ein Briefkastensystem möglich. Sehr wohl kann dieses System zwar für einzelne Wetten im Freundeskreis verwendet werden. Doch auf Grund seiner technischen Unausgereiftheit und seines nicht vorhandenen Bedienerkomforts kann es nicht für diese Arbeit in Betracht gezogen werden.
Bei dem in Mittweida bereits zur Fußball-WM 2002 stattgefundenen Fußballtippspiel wurde eine externe Applikation eingesetzt, um die Ergebnistipps einzusammeln. Die Tipps wurden in eine Textdatei mit einer non-web-Anwendung ausgewertet. Diese mussten dann wieder manuell in eine bestehende Web-Applikation eingebunden werden. Neben der Tatsache, dass der Administrator sehr viel Arbeitsaufwand hat, ist der Komfort für den User sehr gering, die Interaktionsmöglichkeit nach Abgabe des Tipps gleich Null.
Als weitere weit verbreitete Möglichkeit Fußballtippspiele zu realisieren, gibt es bereits seit langem die TOTO-Auswahlwette. Bei der Betrachtung dieses Systems ist nur die Online-Version der Sächsischen LOTTO-GmbH relevant. Diese hat sich dazu entschieden, ihren Webauftritt mit Hilfe eines JAVA-Applets zu realisieren [3]. Für die sichere Übertragung von Informationen wird der SSL verwendet. Für die Nutzung des Applets wird die aktuelle Version der JAVA Virtual Machine benötigt. Gerade bei älteren Systemen ist zu erwarten, dass die betreffende VM erst aktualisiert werden muss. Der Einsatz des SSL ist aufgrund der Übertragung von Bankdaten als notwendig zu erachten. Die Verwendung des Java-Applets ist eine sehr sichere Variante, jedoch mit den Nachteilen der großen Ladezeit beim Start. Allgemein ist die mangelnde Schnelligkeit der größte Nachteil der JVM. Die Datenbankanbindung ist nicht bekannt.
Das ausgereifteste Fußballtippspiel befindet sich auf der Seite des Mitteldeutschen Rundfunks, des MDR [5]. Dieses Tippspiel benutzt eine im Web relativ ungebräuchliche Sprache, nämlich CFML, die Cold Fusion Markup Language. Diese hat gegenüber anderen serverseitigen Scriptsprachen den eindeutigen Vorteil der einfachen Erlern- und Bedienbarkeit. Durch die Kompilierung des Programmcodes hat CFML zusätzlich einen Geschwindigkeitsvorteil gegenüber interpretierten PHP- oder ASP-Skripten. Der gravierende Nachteil von CFML ist jedoch die Lizenzpflicht. Die 1299 US$ teure Lizenz macht den durch die einfache Nutzbarkeit gemachten Vorteil gegenüber kostenfreien Sprachen wie PHP und Perl zunichte. Die Datenbankanbindung wird über eine JDBC/ODBC-Bridge gewährleistet. Als Datenbank wurde bei MDR MySQL gewählt.
Ziel dieses Projektes ist nun die Darstellung der Entwicklung und Erstellung eines solchen Mehr-Nutzer-Online-Spieles am Beispiel des Fussballtippspiels www.sb22.de . Dabei soll beachtet werden, das geringe beziehungsweise keine Finanzmittel zur Verfügung stehen. Die Einfachheit der Administrierung, die Möglichkeit Betrug auszuschließen und eine hohe Attraktivität des Angebotes sollen ebenfalls eine wichtige Rolle bei der Entwicklung spielen.
Dabei soll im Kapitel 2 auf die grundsätzlichen Sachverhalte zum Thema eingegangen werden. Ein Vergleich verschiedener Software, mit der sich das Projekt realisieren ließe, gehört ebenso dazu wie die Anwendung der Grundsätze der Dialoggestaltung. Im Kapitel 3 schließlich werden der Aufbau der Datenbank, das Konzept „Cookie“ und wichtige Aspekte aus dem funktionellen Aufbau des Quelltextes erklärt. Dabei wird vom Administratorentool ausgehend und zum Spielquelltext hingehend Schritt für Schritt über wichtige Aspekte und gemeisterte Schwierigkeiten informiert. Im Fazit schließlich werden Projektauftrag und das erhaltene Resultat miteinander verglichen und eine Bewertung über das Gelingen des Projektes abgegeben.
2. Aufbau der Dialoggestaltung und Auswahl von Projektkomponenten
2.1. Aufbau der Dialoggestaltung
Auf Grund der Vielzahl an möglichen Realisierungen des gegebenen Projektes musste eine objektive Bewertung der einzelnen Wahlmöglichkeiten vorgenommen werden.
Der erste zu betrachtende Punkt betraf die Auswahl des Übertragungsmediums der Tipps. Hierfür wurden klassische Medien wie Post sowie persönliche Übergabe außer Acht gelassen. Das einzig für den Nutzer bequeme Medium ist das Internet. Es ermöglicht die – abgesehen von Onlinekosten - kostenfreie Übertragung der Informationen. Viel wichtiger jedoch ist die zeitlich unbegrenzte Verfügbarkeit dieses Mediums. Dennoch gibt es auch im Internet wieder verschiedene Möglichkeiten, ein Fußballtippspiel umzusetzen. Eine Möglichkeit ist der Einsatz einer extra dafür entwickelten Applikation, die unabhängig von anderer Software läuft. Dies ist jedoch insofern problematisch, als das der User ein extra Programm zu installieren hätte. Hinzu kämen noch dafür notwendige Downloadzeiten, welche gerade User mit Modemanbindung vom Nutzen des Angebotes abhalten würden. Stattdessen kann man als viel einfachere nahe liegendere Lösung das Spielangebot über eine Website laufen lassen. Der Aufruf geschieht dann ganz einfach durch einen Browser, wie z.B. den Internet Explorer von Microsoft oder den Netscape Navigator. Auch bei dieser Lösung gibt es nun wieder verschiedene Möglichkeiten der Realisierung. Diese lassen sich unterscheiden in nutzerrelevante Aspekte wie Darstellungsform im Browser, Wahl eventueller Plugins sowie in betreiberrelevante Aspekte wie Wahl der serverseitigen Scriptsprache sowie die gewählte Datenbank. Als oberstes Gebot für die Darstellungsform für den Nutzer sprechen als erstes die simple Handhabbarkeit sowie die schnelle und sichere Verfügbarkeit von Informationen. Als Bewertungsmodell hat sich die ISO Norm 9241 „Ergonomische Anforderungen für Bürotätigkeiten mit Bildschirmgeräten“ empfohlen. Im Teil 10 charakterisiert sie „Grundsätze der Dialoggestaltung“, welche bei der Erstellung des Userinterfaces auch zur Hilfe genommen wurden. Diese Bewertung beschreibt Maßnahmen zur Aufgabenangemessenheit, Selbstbeschreibungsfähigkeit, Steuerbarkeit, Erwartungskonformität, Fehlertoleranz, Individualisierbarkeit und Lernförderlichkeit.
2.1.1 Aufgabenangemessenheit
"Ein Dialog ist aufgabenangemessen, wenn er den Benutzer unterstützt, seine Arbeitsaufgabe effektiv und effizient zu erledigen."
Ein Dialog gilt als angemessen der Aufgabe entsprechend, wenn er dem User nur die Informationen zuteil werden lässt, die er für die Lösung der Aufgabe benötigt. Dieser Aspekt wird beim Userinterface dahingehend berücksichtigt, als nur die relevanten Informationen eingeblendet werden. Im unten abgebildeten Beispiel befindet sich der User im Menü „Tippen“. Die dargebotenen Informationen beziehen sich nur auf den abzugebenden Tipp. Diese wären die Zeit, die er noch tippen darf, die Nummer des Spieltages sowie die zu tippenden Spiele mitsamt Eingabefeld. Zuletzt erscheint unter dem jeweiligen Spieltag der „Eintragen-Button“. Alle diese Information sind für Erfüllung der Tippabgabe notwendig. Überflüssige Informationen und auch gestalterisch sicherlich schön wirkende Graphiken würden nur von der eigentlichen Abgabe des Tipps abhalten und damit der Aufgabenangemessenheit abträglich sein.
Abbildung in dieser Leseprobe nicht enthalten
2.1.2. Selbstbeschreibungsfähigkeit
"Ein Dialog ist selbstbeschreibungsfähig, wenn jeder einzelne Dialogschritt durch Rückmeldung des Dialogsystems unmittelbar verständlich ist oder dem Benutzer auf Anfrage erklärt wird."
Dieser Punkt spricht das Maß an Intuition an, mit welchem der User den Dialog steuern kann. Durch die Benutzung von Frames in der Darstellung kann der User auf den ersten Blick erkennen, mit welchem Menüpunkt er welche Aktion erreichen kann. Beim Start des Tippspiels bekommt er automatisch den Menüpunkt „Überblick“ präsentiert. Alle weiteren Menüpunkte sind ebenfalls unter einem einzigen zusammenfassenden selbsterklärenden Wort dargestellt. Eine Ausnahme macht der Menüpunkt Statistiken, unter welchem sich alle einzelnen Statistiken verbergen. Die Aufnahme aller Unterpunkte hätte nicht zur Übersichtlichkeit beigetragen, deswegen wurde ein Untermenü erstellt.
2.1.3. Steuerbarkeit
"Ein Dialog ist steuerbar, wenn der Benutzer in der Lage ist, den Dialogablauf zu starten sowie seine Richtung und Geschwindigkeit zu beeinflussen, bis das Ziel erreicht ist."
Auf Grund der linearen Abarbeitung des Dialogprozesses sind größere Maßnahmen zur Steuerbarkeit der einzelnen Prozesse nicht notwendig. Dies soll jedoch nicht heißen, dass der Nutzer keinen Einfluss auf die Anzeige hat. Im Statistikteil besteht zum Beispiel für den User die Möglichkeit, die einzelnen Ranglisten nach verschiedenen Kriterien wie Gesamtpunkte, Höchstpunktzahl oder Durchschnittspunktzahl sortieren zu lassen. Trotzdem sind nach dem erfolgreichen Login nur maximal 2 Klicks nötig, um auf ein bestimmtes Menü zugreifen zu können.
2.1.4. Erwartungskonformität
"Ein Dialog ist erwartungskonform, wenn er konsistent ist und den Merkmalen des Benutzers entspricht, z.B. seinen Kenntnissen aus dem Arbeitsgebiet, seiner Ausbildung und seiner Erfahrung sowie den allgemein anerkannten Konventionen."
Dieser Punkt spricht die Erwartung des Users an, bei bestimmten Eingaben bestimmte Resultate zu erhalten. Wie bereits bei Punkt 2.1.2. beschrieben, sind die Menüs ansprechend benannt und im Menü „tippen“ erhält der User natürlich auch die entsprechende Eingabemaske. Ein weiteres Beispiel für die Erwartungskonformität ist die Darstellung aller Links in hellgrüner Farbe. Diese hebt sich vom blauen Hintergrund optimal ab. Die Verwendung von Grün ausschließlich für Links gewährleistet dem User, dass er Links sofort erkennt und diese auch optimal zur Navigation nutzen kann.
2.1.5. Fehlertoleranz
"Ein Dialog ist fehlertolerant, wenn das beabsichtigte Arbeitsergebnis trotz erkennbar fehlerhafter Eingaben entweder mit keinem oder mit minimalem Korrekturaufwand seitens des Benutzers erreicht werden kann.“
Fehlertoleranz zählt zu den wichtigsten Punkten der ISO Norm 9241-10. Ein System gilt dann als fehlertolerant, wenn es falsche Eingaben nicht toleriert und dem Nutzer die Korrektur einfach macht. Im unten aufgeführten Beispiel des Anmeldeprozesses wurde beispielhaft die Emailadresse falsch eingegeben. Der Nutzer bekommt - durch Java-Script gesteuert - eine Fehlermeldung präsentiert und erhält die Möglichkeit, seine Eingabe zu korrigieren. Die bereits vorhandenen korrekten Eingaben bleiben bestehen und brauchen nicht noch einmal eingegeben werden.
Abbildung in dieser Leseprobe nicht enthalten
2.1.6. Individualisierbarkeit
"Ein Dialog ist individualisierbar, wenn das Dialogsystem Anpassungen an die Erfordernisse der Arbeitsaufgabe sowie an die individuellen Fähigkeiten und Vorlieben des Benutzers zulässt."
Ein Dialog gilt dann als individualisierbar, wenn er zum Beispiel Anpassung an individuelle Vorlieben des Benutzers zulässt. Dies lässt sich für das gewählte Beispiel Menüstruktur anwenden. Ein User ist nicht genötigt, in die Tiefen der Statistiken einzudringen. Wenn er dies jedoch möchte, ist es ganz leicht zu erreichen. Es ist und bleibt allein dem User überlassen, welche Teile des Fußballtippspiels er in Anspruch nimmt. Es könnte sogar sein, dass sich ein User nur anmeldet, um die Statistiken anzuschauen, selber aber nicht spielt.
2.1.7. Lernförderlichkeit
"Ein Dialog ist lernförderlich, wenn er den Benutzer beim Erlernen des Dialogsystems unterstützt und anleitet."
Der Dialog mit dem Userinterface ist deshalb lernförderlich, weil er den User durch ein einheitliches Erscheinungsbild dazu animiert, ihn entsprechend seiner Aufgabe zu nutzen. Im Menüpunkt „Regeln & Infos“ wird dem User zusätzlich die Struktur der Website und die Aufgaben der einzelnen Menüpunkte erklärt. Dies hilft neuen Nutzern einfach und ohne fremde Hilfe, das Dialogsystem zu begreifen und zu nutzen.
2.1.8 Fazit ISO
Die ISO Norm 9241 ist keineswegs eine Vorschrift zum Erstellen von Websites. Vielmehr ist sie eine Sammlung von Richtlinien, die dem Autor einer solchen dialoggeprägten Website hilft, den Anforderungen der Nutzer an die Website gerecht zu werden. Sie hilft auch das Angebot effizient zu gestalten, unnötige Informationen auszusparen und das Angebot an sich attraktiver für den möglichen Nutzer zu machen. Allen sieben Richtlinien der ISO 9241 wurde in diesem Projekt entsprochen.
2.2. Wahl der Anzeigeform beim Nutzer
Um dem User, wie bereits weiter oben beschrieben, die Möglichkeit zur Interaktion nach seinen Wünschen zu geben, wurde als Ausgabeformat die Textbeschreibungssprache HTML -Hypertext Markup Language - benutzt. Der Ausgabeteil wird dem User in drei Frames präsentiert. Im Infoframe wird in dieser Version des Nutzerinterfaces nur ein Logo angezeigt. Man könnte es später auch mit sehr geringem Aufwand in eine Werbeeinblendung ändern, um das Fußballtippspiel zu finanzieren. Das Navigationsframe besitzt - wie schon sein Name sagt - die Aufgabe der Steuerung. Es ist, wie bereits beim Thema ISO 9241 angesprochen, ein wichtiges Element, um Übersichtlichkeit und einfache Bedienung zu garantieren. Im Dialogframe werden schließlich alle notwendigen Informationen angezeigt, die im Navigationsframe ausgewählt wurden. Die Anzeige der Daten verändert das Navigationsframe nicht und erlaubt deswegen dem Nutzer sofort eine neue Seite anzuwählen.
Abbildung in dieser Leseprobe nicht enthalten
Client-Server Architektur
Die Client-Server Architektur ist kennzeichnend für das Internet. Es besteht aus Servern, welche Dienste anbieten, und Clients, die Dienste in Anspruch nehmen. Im WWW - World Wide Web - sind diese Server Webserver mit unterschiedlichen Modulen, um Webseiten anbieten zu können. Die Clients sind die Nutzer, die auf Internetseiten zugreifen möchten. Dieses geschieht meist mit Hilfe eines Browsers, zum Beispiel Microsoft Internet Explorer und Netscape Navigator.
WWW
Diese steuern den Zugriff auf eine Webseite mittels des HTTP. HTTP ist das Hyper Text Transfer Protocol. Die Adressierung der Daten wird mittels so genannter URI’s, den Universal Ressource Indicators, geregelt. Sie stellen eine Verbindung zwischen den leicht merkbaren URL’s wie zum Beispiel www.htwm.de und den dazugehörigen IP-Adressen im World Wide Web dar.
Dynamische Inhalte im WWW
Dem WWW steht mit dem HTTP-Protokoll ein Werkzeug zur Verfügung, um Daten für Webseiten zu transferieren. Doch es ist ebenso eine Anleitung zum Nutzen dieser Daten not-wendig. Diese stellt die Textbeschreibungssprache HTML - Hypertext Markup Language - dar. Sie ermöglicht es dem Browser, mit seinem integrierten HTML-Parser die übertragenen Daten in strukturierten Text umzuwandeln. HTML ist allerdings eine statische Sprache. Mit HTML lassen sich durch den Browser vorher bestimmte Daten präsentieren, die für jeden User gleich angezeigt werden. Eine variable Abarbeitung von Daten-Inputs ist ebenfalls mit HTML nicht möglich.
2.3. Wahl der Scriptsprache
Beim Projekt Fußballtippspiel ist zu beachten, dass Daten serverseitig gespeichert werden müssen. Dies ist zum einen notwendig, um alle Daten für die Statistiken und Auswertungen zur Hand zu haben. Auf der anderen Seite ist die Betrugsprävention ein wichtiges Element. Alle Daten, die nicht auf der Serverseite liegen, sind als unsicher zu betrachten, da diese ja vom User manipuliert werden können. Deswegen müssen sowohl Datenspeicherung als auch Datenaufbereitung serverseitig erfolgen. Auf die Datenspeicherung und den Datenzugriff wird im Kapitel „Wahl der Datenbank“ näher eingegangen. Eine Scriptsprache ist hier nötig, um den Anforderungen der Aufgabenstellung gerecht zu werden.
Scriptsprachen sind im Prinzip einfachere Programmiersprachen, deren Sprachumfang auf ein spezielles Aufgabengebiet (z.B. eben Webanwendungen) zugeschnitten ist. Die Entwicklung geht meist einfacher und schneller als mit "großen" Programmiersprachen. [1]
Schließlich sollen nicht nur statische HTML-Seiten angeboten werden, sondern dynamische Inhalte. Dynamisch meint in diesem Sinne, dass sich die dargestellten Seiten vom User anpassen lassen bzw. sich verändern, wenn bestimmte Eingaben getätigt werden. Wichtig ist auch, dass jeder User nur seine eigenen Tipps angezeigt bekommt. Schlussendlich ist dies nur mit dynamischen Scriptsprachen möglich, da ja bei HTML-Seiten nur schwerlich zwischen den einzelnen Usern unterschieden werden kann.
Für den Anbieter gibt es eine Vielzahl an Scriptsprachen. Um für dieses Projekt die optimale Scriptsprache zu erhalten, findet im Nachfolgenden ein Vergleich einiger wichtiger Sprachen statt.
Zu den ältesten Scriptsprachen gehört Perl und bedeutet Practical Extraction and Reporting Language. Perl steht in engem Zusammenhang mit CGI – dem Common Gateway Interface. CGI bietet eine Möglichkeit für den Webserver Daten zu verarbeiten und sie dem User anzubieten. Die Arbeitsweise von CGI ist aus der unten abgebildeten Grafik ersichtlich. Perl wird in diesem Zusammenhang am häufigsten benutzt. Diese Scriptsprache wird gewöhnlicherweise interpretiert, deshalb werden die aus einfachem Text bestehenden Scriptdateien einfach und schnell ausgeführt. Die weltweit hohe Verbreitung von Perl und die einfache Portabilität auf andere Systeme sprechen für Perl als Scriptsprache. Allerdings ist es für den ungeübten Anwender nicht einfach, Fehler in seinen kompilierten Scripten zu entdecken, da es keine explizite Möglichkeit der Fehleranzeige gibt.
Abbildung in dieser Leseprobe nicht enthalten[6]
Eine weitere noch nicht sehr weit verbreitete Möglichkeit Daten serverseitig zu verarbeiten und anschließend dem Client zu präsentieren, ist Java Servlets. Ein Servlet ist ein Java Programm, das auf einem Webserver läuft und Webseiten ähnlich wie CGI auf Abruf erstellt und verarbeitet. Java Servlets darf man nicht mit Java-Applets verwechseln. Diese laufen auf einem Browser, haben also nur Zugriff auf die Clientseite und sind deshalb für dieses Projekt irrelevant. Die Servlet Engine kann im Webserver integriert laufen oder sich als eigener Prozess darstellen. Ein Beispiel für eine Webserver integrierte Servlet Engine ist der Resin Server von Caucho (www.caucho.com). JRun von Macromedia hingegen ist eine separate Servlet Engine und kommuniziert mit Webserver wie Apache und Microsoft IIS mittels sogeannter Konnektoren. Webserver integrierte Servlet Engines sind auf Grund der nicht nötigen Inter-Prozess-Kommunikation mit einem Geschwindigkeitsvorteil ausgestattet, sind aber dafür weniger fehlertolerant. Im Falle eines Systemfehlers in der Servlet Engine würde bei Benutzung der Webserverintegrierten Servlet Engine auch der Webserver ausfallen. Der Lebenszyklus eines Servlets lässt sich wie folgt beschreiben. Der Webserver lädt den Servletcode und initialisiert ihn mit der init- Methode. Das Servlet kann von da an von Clients in Anspruch genommen werden. Schließlich kann der Webserver den Servlet mittels der destroy- Methode wieder herunterfahren.
Im Vergleich von CGI-Skripten mit Servlets lassen sich verschiedene Vor- und Nachteile herausstellen. CGI-Skripte erstellen bei jeder Anforderung einen neuen Prozess. Dies ermöglicht die Verarbeitung mehrerer Anfragen zur gleichen Zeit, ist aber sehr rechenintensiv. Da die CGI-Skripte dann noch vom Interpreten der angewandten Skriptsprache interpretiert werden müssen, erhöhen sich die Anforderungen an das Webserversystem noch weiter. Servlets dagegen werden in separate Threads aufgeteilt und verfügen deswegen über geringere Anforderungen an das Webserversystem. Hinzu kommt, dass durch das Interpretieren des PERL-Codes für das CGI-Skript ein weiterer Geschwindigkeitsnachteil entsteht. Servlet Code wird zwar ebenfalls interpretiert, ist jedoch auf byte-code Interpretation ausgelegt und deswegen schneller. Das Nutzen gemeinsamer Daten von verschiedenen Instanzen von Servlets kann durch Synchronisationsmechanismen recht gut geregelt werden. Bei Perl-Skripten gestaltet sich das Ganze recht schwierig, da eine Kommunikation zwischen Prozessen hergestellt werden müsste. Der Zugriff auf Dateien wird durch das Entziehen der Schreibrechte für andere Prozesse recht simpel gehandhabt. Für den Datenbankzugriff bietet Java fertige API’s (application programming interface) an. Das bekannteste API ist das JDBC (Java Database Connectivity). Es bietet einen standardisierten Zugriff auf Datenbanken, wobei nur noch einzelne Parameter geändert werden müssen. In Sachen Portabilität verhalten sich sowohl Servlets als auch Perl vorbildlich und bereiten keine Probleme. Bei der Wartung des Quellcodes werden aber wieder große Unterschiede sichtbar. Während Java Code relativ schwierig zu schreiben ist, ist seine Wartung sehr einfach auf Grund der robusten Objektorientierung. Bei Perl verhält es sich genau andersherum. Der Quellcode ist sehr einfach zu schreiben, aber gleichzeitig schwerer lesbar und damit schlechter zu warten. Der Punkt der Zuverlässigkeit spricht eher für CGI, da die Ausführung einzelner Anfragen in Prozessen abgearbeitet wird, die im Problemfall nur zum Ausfall einer Anfrage führen. Der Abbruch eines Threads in den Servlets kann zum Ausfall der Servlet Engine führen. Falls diese im Webserver integriert ist, fällt der ganze Webserver mit aus.
Mit ASP, den Active Server Pages, steuert Microsoft seinen Teil zu den Techniken der Ansteuerung dynamischer Webseiten bei. ASP läuft mit den meisten Scriptsprachen, ist jedoch für VBScript optimiert. Dokumentationen in ausreichendem Umfang sind auch nur für VBScript erhältlich. In der neueren Version ASP.NET wird nun nicht mehr VBScript, sondern Visual Basic .NET und C# als Scriptsprache angeboten. ASP.NET ist jedoch auf Windows 2000 und Windows XP beschränkt, so dass bei Lücken in diesen Betriebssystemen Sicherheitslücken auch im Webbereich auftreten können.
PHP ist der sogenannte Pre Hypertext Processor. Mit dieser Programmiersprache stehen von Start an sehr viele Werkzeuge zur Programmierung zur Verfügung, so dass viele Funktionen sofort übernommen werden können. Auch die einfache Erlernbarkeit der Sprache und die manchmal etwas lässige Deklarationspflicht machen PHP zu einer beliebten Scriptsprache. Doch diese nachlässige Deklarationspflicht – Variablen müssen zum Beispiel nicht deklariert werden – wird PHP manchmal auch zum Verhängnis. Durch unsauberes Programmieren wird PHP schnell noch langsamer, als es ohnehin schon ist. Die vielen kleinen Erleichterungen, die PHP bietet, gehen sämtlich zu Lasten der Geschwindigkeit. Trotzdem ist das sogenannte LAMP-System, bestehend aus Linux, Apache, MySQL und PHP, das am weitesten im Internet verbreitete System. Das liegt daran, dass alle 4 Systeme kostenlos verfügbar sind und ihr Zusammenspiel bewährt ist und von den jeweiligen Programmierern auch erwünscht wird. Hinzu kommt, dass sich MySQL und PHP nicht nur gut ergänzen, sondern auf Grund ihrer Struktur für kleine und mittlere Projekte, wie dieses Fussballtippspiel, am besten geeignet sind. Deswegen fällt die Wahl für PHP recht leicht. Einfache, recht schnell programmierbare Funktionen sind in diesem Projekt genau die richtige Wahl.
2.4 Wahl der Datenbank
Wie auch für die Wahlpunkte Scriptsprache und Webserver gilt es hier zwischen kostenpflichtigen Angeboten und kostenlosen Anbietern zu wählen. Die derzeit umfangreichste Datenbank wird von Oracle angeboten. Aber was ist eigentlich eine Datenbank? Eine Datenbank ist eine lose Sammlung von Daten. Nun könnte man meinen, es wäre relativ einfach, die für das Projekt benötigten Daten einfach in einer Textdatei abzuspeichern. Im einfachsten Fall würden zum Beispiel alle Nutzerdaten in einer Datei abgespeichert werden. Um verschiedene Werte auseinanderhalten zu können, würde man mit einem vereinbarten Trennzeichen, häufig dem Pipe Symbol, arbeiten. Ein neuer Datenwert würde auf einer neuen Zeile hinzugefügt werden. Aber bereits beim gleichzeitigen Zugriff zweier Benutzer auf die Datei würden Probleme entstehen. Sollte der erste Nutzer gerade die Datei geöffnet haben und sie verändern, darf der zweite Nutzer nicht zur selben Zeit die Datei bearbeiten. Grund dafür ist, dass sonst die Veränderung des ersten Nutzers einfach rückgängig gemacht wird, wenn der zweite Nutzer die Datenbankdatei wieder speichert.
Abbildung in dieser Leseprobe nicht enthalten
In der obigen Abbildung sieht man deutlich, dass es einen Konflikt zwischen den beiden Nutzeranfragen des Nutzers A und B gibt. Eine Möglichkeit, dies mittels sogenannter Semaphoren zu regeln, ist aus der nächsten Abbildung ersichtlich.
Abbildung in dieser Leseprobe nicht enthalten
Trotz dieser möglichen Lösung ist die Wahl einer Datenbankdatei immer noch nicht sehr vorteilhaft. Zu schwer wiegen die Nachteile. Es besteht zum Beispiel nicht die Möglichkeit, Datensätze miteinander zu verknüpfen. Dies ist bei relationalen Datenbanken wie der Oracle-Datenbank, der MySQL-Datenbank oder der PostgreSQL-Datenbank leicht zu bewerkstelligen. Das ist der Grund, weshalb dieses Projekt schlussendlich mit einer relationalen Datenbank ausgestattet wird. Kriterien, die es hierbei zu beachten gilt, sind die Handhabbarkeit der Installation, die anfallenden Lizenzen, verfügbare Tools und Schnittstellen sowie die Möglichkeit zur einfachen Datensicherung und die Unterstützung des SQL-Standarts. Bei allen Punkten geschah die Betrachtung unter der Maßgabe, dass nur ein Windows-System zu Testzwecken zur Verfügung stand.
Abbildung in dieser Leseprobe nicht enthalten
ORACLE
Die Kosten von über 15.000 US$ lassen diese Datenbank bei der Wahl zur Projektdatenbank noch vor der eigentlichen Betrachtung der Geeignetheit scheitern. Dennoch soll sie kurz betrachtet werden. Allein die Installation der 4 CD’s umfassenden Datenbanksoftware lässt auf den Umfang der zur Verfügung stehenden Funktionen schließen. Sollten die Anforderungen es nötig machen, die Datenbank auf mehrere Server zu verteilen, ist dies ohne Probleme möglich. Eine vollständige Unterstützung der SQL-99 Standards bringt die Möglichkeit, auch komplexe Abfragen mit nur einem Befehl auszuführen. Die Oracle Datenbank ist eine Datenbank, die erweiterte Ansprüche bei großen Projekten problemlos erfüllt. Für einfache Anwendungen ist die Komplexität eher nicht wünschenswert.
MYSQL
MySQL ist mit einer Verbreitung von 45 % das gängigste Datenbanksystem. Mit 45 % Marktanteil sollte man meinen, dass es für jedes Projekt geeignet erscheint. Doch die nicht vollständige Unterstützung des SQL-92 und des noch umfangreicheren SQL-99 Standards bergen für komplexe Abfragen gewisse Tücken. Um die fehlenden Möglichkeiten zu ersetzen, müssen umständliche und umfangreichere Ersatzanfragen beziehungsweise Ersatzlösungen heran. Diese kosten Ressourcen und gehen auf Kosten der Performance – das System wird langsamer. Die Einfachheit von MySQL hat aber den Vorteil, dass es einfache Anfragen von wenigen Nutzern recht schnell und unkompliziert bearbeiten kann. Die sehr umfangreichen Dokumentationen erleichtern die Arbeit noch um ein erhebliches. Die freie Verfügbarkeit vieler Tools wie dem MyPHPAdmin lassen diese Datenbank endgültig zur Projektdatenbank werden.
POSTGRESQL
Mit dieser freien Datenbank verbindet sich der Versuch, aus einem SQL-fremden System „Ingres“ eine dem SQL-92 Standard folgende Anwendung zu erstellen. PostGres besitzt auch eine gewisse Komplexität, soweit dies für solch ein Open-Source-Projekt möglich ist. Im Vergleich zu MySQL lassen die dürftige Dokumentation und die stark eingeschränkte Möglichkeit, PostGres unter Windows zum Laufen zu bekommen, diese Datenbank nicht als Projektdatenbank in Betracht kommen. Die im Vergleich zu MySQL bessere Geschwindigkeit und bessere Ausstattung mit Funktionen aus dem SQL-Standard sorgen dafür, dass PostGres für relativ komplexe Anwendungen die ideale kostengünstigste Lösung ist.
2.5. Wahl des Webservers
Bei der Wahl des Webservers steht auf der einen Seite die Möglichkeit, aus den unzähligen Angeboten von Webservern zu wählen. Auf der anderen Seite ist der Standort auf dem Webbereich der Hochschule Mittweida vorgegeben. Dies führt dazu, dass als Webserver zwingend Apache vorgeschrieben ist. Nichtsdestotrotz werden nachfolgend einige bekannte Webserver vorgestellt.
Der für den unerfahrenen Nutzer geeigneteste Webserver ist Xitami. Er bietet trotz seines geringen Anspruchs an die Vorkenntnisse des Nutzers vielfältige Einstellungsmöglichkeiten. Dennoch sind bekannte Sicherheitsprobleme [7] und die auf den ersten Blick als sehr hilfreich erscheinende Windows-Oberfläche Minuspunkte. Dass das Administratorenpasswort in Klartext gespeichert [8] wird, erzeugt nicht unbedingt mehr Vertrauen in den wichtigen Punkt der Serversicherheit
Sowohl Apache als auch der IIS bieten dagegen eine reichhaltige Auswahl an Sicherheitsfeatures. Diese beinhalten die Beschränkung des Zugangs, des Loggen der Zugriffe, das Verhindern der Verzeichnisanzeige sowie Zertifikate und Authentifizierung von Nutzern. Dabei gehen Apache und IIS unterschiedliche Wege zur Einstellung der Serveroptionen. Während IIS mit einem guten GUI aufwartet, bietet Apache eine gut dokumentierte Textdatei zur Konfiguration. Dies führt zu einer guten Flexibilität und Erweiterbarkeit. Einer empirischen Studie [10] zum Vergleich von Apache und IIS zufolge, bringt Open-Source dem Apache Webserver einen weiteren Vorteil. Es werden nämlich viel weniger sicherheitskritische Fehler entdeckt und bereits vorhandene schneller beseitigt als beim Closed-Source-Projekt IIS. Der Marktanteil des Apache Webservers mit ca. 67 % [9] lässt vermuten, dass die Zugangsbeschränkung mittels der .htaccess den besten Weg auf diesem wichtigen Gebiet darstellt und die höhere Benutzerfreundlichkeit des IIS wettmacht. Zudem ist der IIS an sich zwar zusammen mit Windows-Betriebsystemen erhältlich, aber für die letztendliche Benutzung fallen dennoch Lizenzgebühren an. Das ist beim Apache Webserver nicht der Fall. Xitami kann bei keinem Feature ein entscheidendes Plus sammeln. So fällt die Wahl des für dieses Projekt genutzten Webservers auf den Apache Server. Dieser ist auch beim Anbieter des Webspace, dem Rechenzentrum der Hochschule Mittweida, vorinstalliert, so dass hier keine Installationsarbeit mehr notwendig ist. Dennoch sind in der Anlage 13 beispielhaft der Installationsprozess sowie weitere wichtige Punkte dieser drei Webserver ausführlich aufgezeigt.
3. Realisierung des Projektes
3.1. Erstellung der Datenbank
Bei der Wahl der Datenbank wurde für dieses Projekt die MySQL-Datenbank gewählt. Zusammen mit dem an der Hochschule Mittweida verfügbaren PHPmyAdmin-Tool ist es recht einfach, eine Datenbank zu erstellen. Das Login erfolgt mit dem normalen Browser, unten einmal beispielhaft für den Internet-Explorer von Microsoft dargestellt.
Abbildung in dieser Leseprobe nicht enthalten
Im nachfolgenden Bild ist die nach dem erfolgreichen Login präsentierte Startseite des PHPMyAdmins zu sehen. Im linken Frame kann zwischen den schon vorhandenen Tabellen hin- und hergewechselt werden. Die Bearbeitung der jeweiligen Tabellen erfolgt dann im rechten Hauptscreen. Auch das Erstellen neuer Tabellen ist einfach möglich.
Abbildung in dieser Leseprobe nicht enthalten
3.2. Das Tabellensystem des Projektes Fussballtippspiel
3.2.1. Tabelle für die Nutzerverwaltung
Persönliche Details, die beim Registrieren des Nutzers für das Spiel notwendig sind, werden in der Tabelle KUSER abgespeichert. Diese Tabelle ist zusätzlich mit einem Primärschlüssel versehen. Der Primärschlüssel ist eine eindeutige Kennung, damit der logische Zusammenhang zwischen verschiedenen Tabellen gewährleistet wird. Dieser Wert muss in jeder Zeile belegt werden und eindeutig sein.
Der Primärschlüssel in dieser Tabelle heißt counter und ist als auto_increment definiert. Dies gibt die Möglichkeit, jedem Nutzer eine Nutzernummer zuzuteilen, die in vielen anderen Tabellen benötigt wird. Da neben der Nutzernummer kein weiterer Primärschlüssel mehr vorhanden sein darf, muss bei der Registrierung eines Nutzers überprüft werden, ob der Nick schon einmal vergeben ist.
Abbildung in dieser Leseprobe nicht enthalten
3.2.2. Tabelle für Login-Daten
In der Tabelle CUSER befinden sich alle relevanten Daten zu vorhandenen Logins. Die Tabelle enthält neben der jeweiligen Nutzernummer, die als Fremdschlüssel enthalten ist, auch noch eine Zufallszahl, welche im Cookie gespeichert wird. Zusätzlich wird natürlich auch die Zeit abgespeichert, welche für den Benutzer noch im erlaubten Bereich liegt. Dazu wird mittels eines SQL-Befehls die momentane Unix-Systemzeit ausgelesen. Diese ist in eine Zahl verschlüsselt, die die Sekunden seit dem 01.01.1970 angibt. Die erlaubte Einloggzeit beträgt 30 Minuten und wird einfach auf die Systemzeit aufaddiert. Bei jedem Seitenaufruf des Nutzers wird dieser Zeitstempel wieder auf die vollen 30 Minuten aufgerechnet. Weitere Informationen dazu im Kapitel Login-Cookie.
3.2.3. Tabellen zum Speichern der Spielinformationen
Die Daten der Spiele, die getippt werden müssen, und die Vorraussagen der Nutzer werden in verschiedenen Tabellen gespeichert. Der Grund dafür besteht darin, dass es sehr bequem und einfach ist, die Tabellen mit den verschiedenen Informationen zu verknüpfen und so Speicherplatz einzusparen. Die erste Tabelle, die in diesem Zusammenhang erstellt wird, ist die Tabelle TEAM. In ihr werden die Teamnamen und die dazugehörigen Teamnummern abgespeichert.
Abbildung in dieser Leseprobe nicht enthalten
Die nächste Tabelle enthält die Ansetzungen. Hierfür werden mindestens 20 Spalten benötigt, da für jeden Spieltag 10 Heim- und 10 Ausswärtsteams gespeichert werden müssen. Hinzu kommt noch eine Spalte für die Nummer des jeweiligen Spieltages. In den 20 Spalten der Teams wird jeweils die Teamnummer eingetragen, die aus der Tabelle TEAM abgeleitet wird. Die Teamnamen könnten auch direkt gespeichert werden. Dies würde aber mehr Speicherkapazität bedürfen. Die Teamnummer ist zweistellig, der Teamname dagegen oft bis zu 20-stellig. Erschwerend wirkt, dass Teamnamen öfter verwendet werden und die im Vergleich zur Teamnummer erhöhte Datenmenge mehrfach gespeichert werden muss. Die Tabelle heißt SPIELTEAMS.
Abbildung in dieser Leseprobe nicht enthalten
Die letzte Tabelle, die direkt in Zusammenhang mit den zu speichernden Spieldaten steht, ist die Tabelle, in die die Ergebnisse eingetragen werden. Diese Tabelle mit den Namen SPIELERG besitzt eine Spalte mehr. Denn zusätzlich zur Spielwoche muss nun noch zwischen den einzelnen Nutzern unterschieden werden. Dafür wird wiederum die Spalte „counter“ eingeführt, in der die Nutzernummern gespeichert werden. Da die Nutzernummern von 1 an aufwärts zählen, ist es recht praktisch, die realen Ergebnisse, aus denen die Punkte berechnet werden müssen, mit der Nutzernummer 0 ebenfalls in dieser Tabelle zu speichern. Auf Grund der geschickt gewählten Tabellenstruktur müssen in dieser Tabelle keinerlei Informationen über die Teamnummern oder Teamnamen gespeichert werden. Diese Tabellenanordnung erlaubt auch, dass keine extra Tabelle für die erreichten Punkte der einzelnen Nutzer angelegt werden muss.
Abbildung in dieser Leseprobe nicht enthalten
3.2.4. Datenverwaltungstabellen
Natürlich müssen auch irgendwo Informationen darüber auftauchen, ob und wie lange noch für einen Spieltag getippt werden darf oder ob ein Spieltag schon vollständig abgeschlossen ist. In der Tabelle BET, die nur aus 2 Spalten besteht, werden die Spieltage definiert, für die noch getippt werden darf. In der zweiten Spalte befindet sich der Zeitpunkt, bis zu dem getippt werden darf. Dies automatisiert das Spiel und stellt einen hohen Komfort für den Administrator bereit. So wird mittels des PHP-Scriptes automatisch der Tipp verweigert, sobald der gesetzte Zeitpunkt erreicht wird. Wird das Script erst zu diesem Zeitpunkt aufgerufen, wird der Tipp gar nicht mehr angeboten.
Abbildung in dieser Leseprobe nicht enthalten
[...]