Teil 1: Architektonische Überlegungen für die Entwicklung eines Tippspiels

Der Ball ist rund

Thilo Frotscher

Die Fußball-Europameisterschaft steht vor der Tür und Millionen deutscher Nationaltrainer diskutieren, wie hoch der Sieg gegen Holland wohl ausfallen wird. Weil da jeder so seine eigene Meinung hat und man vorher eben nie genau weiß, wie’s am Ende ausgeht, sind Tippspiele so ungemein beliebt. Höchste Zeit also, endlich mal eines zu programmieren – ganz nebenbei kann man dabei eine Menge über J2EE und Patterns lernen.

Wer selbst schon einmal ein Tippspiel gestartet hat, kennt das Problem nur zu gut: Viele Teilnehmer wollen Ihre Tipps erst im letzten Moment vor einem Spieltag abgeben – es könnte ja sein, dass sich ein wichtiger Spieler noch kurz vorher verletzt. Also klingelt das Telefon des Tippspielverwalters kurz vor dem Anpfiff ununterbrochen, obwohl dieser es sich doch eigentlich schon mit Popcorn und Apfelschorle vor dem Fernseher bequem gemacht hat. Kaum ist ein Spieltag dann zu Ende, müssen die Punktzahlen der Teilnehmer ausgerechnet werden. Bei einer großen Tippgemeinschaft kann es dabei schon mal vorkommen, dass sich der Tippspielverwalter im Zahlendschungel verirrt und verrechnet. Und dann der ganze Zettelwust nein, im Zeitalter allgegenwärtiger IT muss da eine andere Lösung her.Natürlich könnte man ein Excel-Sheet einsetzen. Dies würde Abhilfe beim Ausrechnen der Punktestände schaffen und die Zettelwirtschaft wäre auch nicht mehr notwendig, aber der Tippspielverwalter müsste weiterhin die Tipps per Telefon annehmen und kurzfristige Tippänderungen und Punktestandabfragen beantworten. Außerdem ist die Erstellung der Formeln für ein komplett automatisch auswertendes Excel-Sheet nicht unbedingt trivial. Viel besser wäre dagegen eine Webanwendung. Sie müsste so beschaffen sein, dass Mitspieler ihre Tipps bis kurz vor Anpfiff bequem mithilfe ihres Browsers eingeben oder ändern können und dass der aktuelle Punktestand jederzeit eingesehen werden kann. Die Arbeit des Tippspielverwalters beschränkt sich somit nur noch darauf, die Tippgemeinschaft und alle Mitspieler initial anzulegen, die Ergebnisse der einzelnen Spiele einzugeben und gegebenenfalls dafür zu sorgen, dass die Anwendung stabil läuft.In einer kleinen Artikelreihe soll anhand dieses anschaulichen Beispiels erläutert werden, wie eine solche Tippspiel-Anwendung mit J2EE implementiert werden kann. Es soll dabei nicht in allen Fällen der hundertprozentig beste oder perfekte Lösungsansatz gewählt werden, sondern manchmal auch einfach der pragmatischste oder derjenige, der das beste Verhältnis zwischen Aufwand und Nutzen vorweist. Ganz so, wie in einem richtigen Projekt eben. Auf der anderen Seite sollen Features aufgenommen werden, die vielleicht gar nicht so wichtig erscheinen, aber unbedingt in der Webanwendung enthalten sein müssen, weil ein Entscheider diese Funktionalität gern haben möchte. Auch dieses Phänomen ist Entwicklern aus vielen Projekten bestens bekannt. So soll die Tippspiel-Anwendung neben einer interaktiven, browserbasierten Schnittstelle auch eine Web Service-Schnittstelle besitzen, die es zum Beispiel ermöglicht, beliebigen anderen Tippspiel-Anwendungen die eigene Geschäftslogik zur Verfügung zu stellen. Diese könnten sich dann darauf beschränken, eine eigene Benutzungsoberfläche zu entwickeln – unter Umständen etwa eine für .NET. Weiterhin soll die Webanwendung so offen gestaltet werden, dass sie später einmal dahingehend erweitert werden kann, Tippspiele für beliebige Sportwettbewerbe durchzuführen. Denn die WM 2006 ist nicht mehr fern und vielleicht möchte ja auch jemand ein Tippspiel für die Basketball-Bundesliga oder seine wöchentliche Kegelrunde einführen. Hierzu muss eine Möglichkeit geschaffen werden, mit der ein Tippspielverwalter gegebenenfalls zu allererst den Spielplan eines neuen Sportwettbewerbs eingeben kann.Zunächst ist aber nur eine Implementierung für die Fußball-EM in diesem Jahr vorgesehen. Jedermann soll sich anmelden und eine Tippgemeinschaft gründen können. Der Gründer einer solchen Tippgemeinschaft ist dann der Tippspielverwalter für diese Gemeinschaft. Nachdem eine Tippgemeinschaft eingerichtet ist, kann der Tippspielverwalter zusätzliche Mitspieler anlegen und bestimmen, ob alle Spiele der EM getippt werden sollen oder nur eine Teilmenge. Jeder eingerichtete Mitspieler hat anschließend die Möglichkeit, für die vom Tippspielverwalter ausgewählten Spiele seinen Tipp abzugeben. Er kann sich jedoch mit der Abgabe seines Tipps auch bis kurz vor Beginn eines Spiels Zeit lassen, wenn er verhindern möchte, dass sich andere Mitspieler nach seinem Tipp richten, oder wenn er – wie eingangs erwähnt – abwarten möchte, ob sich nicht noch kurzfristig jemand verletzt. Ebenso ist es möglich, einen abgegebenen Tipp nachträglich zu ändern. Erst wenn die Anstoßzeit eines Spiels erreicht ist, können keine Änderungen am Tipp mehr vorgenommen werden. Für jedes genau richtig getippte Ergebnis erhält ein Mitspieler drei Punkte. Stimmt immerhin die Tordifferenz, werden zwei Punkte vergeben. Hat der Mitspieler dagegen nur auf den richtigen Sieger oder richtigerweise auf ein Unentschieden getippt, so erhält er einen Punkt. Gewonnen hat am Ende – klar – der Mitspieler mit den meisten Punkten.Welche Use Cases werden für die Webanwendung benötigt? Es können zwei verschiedene Akteure identifiziert werden: Tippspielverwalter und Mitspieler. Der Tippspielverwalter muss Tippgemeinschaften verwalten (anlegen, löschen), Mitspieler verwalten (anlegen, löschen), Spielergebnisse des Wettbewerbs eingeben, sowie Wettbewerbe und Spielpläne verwalten (optional). Ein Mitspieler möchte Tipps eingeben oder editieren, den aktuellen Punktestand des Tippspiels einsehen sowie die Spielergebnisse des Wettbewerbs betrachten. Beide müssen sich grundsätzlich zuvor anmelden. Abpictureung 1 veranschaulicht diese Use Cases.

Abb. 4: Architektur des Tippspiels mit Web Service-Schnittstelle
Geschrieben von
Thilo Frotscher
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.