Eine der Schwierigkeiten des neuen Börsenspiels lag in der in kurzen Zeiträumen auftretenden hohen Anzahl von Zugriffen auf den "Börsen-Server", zum Beispiel während Halbzeitpausen. Bereits während der Entwicklung testeten die Beteiligten laufend die Server-Belastung bei hohen Zugriffszahlen. Ein Ziel war, pro CPU etwa 1500 aktive Sitzungen parallel zu verwalten. So konnten die Entwickler entscheiden, wie viele Application-Server für die gesamte Anwendung in der Produktivumgebung unter der prognostizierten Volllast erforderlich sind. Von Anfang an definierten sie Whitebox-Tests, um die Geschäftslogik in den einzelnen Paketen automatisiert zu überprüfen. Auf diese Weise vermieden sie frühzeitig, dass sich bei Änderungen Fehler in verbundenen Komponenten ergeben.
Entwicklerteam geht in Klausur
Die Implementierung erfolgte letztendlich neben der J2EE-Technologie auf Basis von Oracle Stored Procedures (PL/SQL) und wurde in einem kleinen Team von fünf Personen umgesetzt. Das versammelte sich in einer "Arche" in Madrid - abgeschottet vom operativen Tagesgeschäft. Der Zeitrahmen bis zur Fußball-EM war mit sechs Wochen sehr knapp bemessen. Aufgrund der Prämissen führten die Entwickler nach einer einwöchigen Analysephase einen so genannten "Feature Freeze" durch. Trotz des kurzen Zeitraums der Funktionsdefinition war die Komplexität der umzusetzenden Realtime-Börsensimulation sehr hoch: Margin-Berechnung, offenes Orderbuch sowie Aussetzung des Handels bei zu hoher Volatilität mit anschließender Auktionsphase.
Refactoring als Retter
Mittels Refactoring gelang es dem Team, den engen Zeitplan einzuhalten. Diese Vorgehensweise stammt aus dem Konzept des "Extreme Programming": Eine lauffähige Lösung wird sehr rasch implementiert und in mehreren Iterationen überarbeitet. Martin Fowler, einer der Autoren des Konzepts, bezieht Refactoring hauptsächlich auf die Implementierung selbst. Im Börsenspielprojekt behielten die Entwickler dagegen den Quellcode weitgehend bei und modifizierten in erster Linie die Architektur.
Aus dem Prototyp extrahierten sie in einer ersten Stufe des Refactoring HTML- und Java-Code und überführten diese in Java Server Pages (JSP). Die Vermischung von HTML-Darstellung und Geschäftslogik verringert zwar die Entwicklungszeiten drastisch. Die Applikation wird dadurch aber unübersichtlich und schwer wartbar.
Umstellung von ISP auf Javabeans
In einer zweiten Phase lagerte das Team die Business-Logik in Javabeans aus. Durch die Trennung von Quellcode und Benutzeroberfläche konnten sie die Anwendung strukturieren: Für Anwendungsentwickler blieb die Business-Logik wiederverwendbar, während sich Frontend-Gestalter und Grafik-Designer auf das Layout konzentrieren konnten.
Die dritte Stufe umfasste die Verbesserung des Softwaredesigns. Mit Hilfe des Tools "Together J" generierten die Entwickler Unified-Modeling-Language-(UML-)Diagramme. Zugleich deckten sie Schwächen in der Klassenhierarchie auf und beseitigten diese. Beispielsweise führten sie bei der Login- und Session-Verwaltung das Dispatcher-Pattern ein. Durch diese zusätzliche Abstraktionsschicht werden eingehende Anfragen zentral verwaltet und so redundante Implementierungen der Zugriffssteuerung in einzelnen JSPs vermieden.
Die nächste Phase stand im Zeichen des Wechsels von JSP zu XSL Transformations (XSLT). Dies ermöglichte den Anschluss unterschiedlicher Clients an das System. Die Entwickler schufen nämlich neben dem HTML- auch ein WML-Frontend für Motorola- und Nokia-Mobiltelefone. Auf diese Weise können Anwender ihre Transaktionen auch über WAP (Wireless Application Protocol) tätigen. Dabei musste das Team bei der Implementierung die Stolpersteine eines frühen und unausgereiften Standards umgehen.
Bei einer letzten Iteration wurde die Geschäftslogik von Javabeans in Enterprise Javabeans (EJB) übertragen, um die Skalierbarkeit zu erhöhen. Somit ist gewährleistet, dass die Applikation auf mehrere Server verteilt werden kann. Ein weiterer positiver Effekt ergab sich dadurch, dass durch die Kapselung der Geschäftslogik in Stateless Session Beans eine physische Trennung zur Benutzungsoberfläche erzielt wird und die Speicherbelastung durch die Frontend-Servlets zurückgeht. Zum Einsatz kam dabei der EJB-Server "BEA Weblogic".
Die einzelnen Iterationszyklen waren aus Sicht der Entwicklung bei einem Aufwand von drei bis zehn Personentagen sehr kurz. Auf diese Weise konnte das Projektteam Fehler bei der Überführung in die Produktivumgebung schon früh erkennen und beheben.
Fazit
Eine wesentliche Voraussetzung für den Einsatz von Refactoring besteht darin, dass die Anforderungen an Funktonalität und Prozessablauf zu einem definierten Zeitpunkt ausgesetzt werden (Feature Freeze). Dies erwies sich auch für die White-Box-Tests als vorteilhaft, weil sie deshalb nur einmal definiert werden mussten. Um Refactoring effizient zu gestalten, sollte das Entwicklungsteam klein gehalten werden.
Lautet die Aufgabe, Applikationen beziehungsweise Komponenten so weit zu entwickeln, dass sie als Produkte mehrfach verwendet werden können, ist Refactoring ein adäquates Verfahren. Das Vorgehen ist jedoch nicht generell zu empfehlen. Es eignet sich nur dann, wenn der Zeitplan so eng gesetzt ist, dass ein suboptimales Design aus wirtschaftlichen Gesichtspunkten wie beispielsweise Time-to-Market temporär akzeptabel ist, langfristig jedoch auf eine standardisierte und erweiterbare Systemarchitektur Wert gelegt wird. Gerade J2EE-Architekturen eignen sich also dazu, vorhandenen Source-Code auf unterschiedlichen Schichten neu zu verteilen: JSP, Javabeans, EJB.
*Christian Wehrfritz und Dr. Benno Schmitzer sind Mitarbeiter der 100world.com AG.
Aufgaben und Bedingungen
Anlässlich der Fußball-Europameisterschaft 2000 beauftragten die Consors Discount Broker AG und das ZDF 100world, die Börsensimulation "Gevex" zu veranstalten. Dabei galt es, virtuelle Optionen auf teilnehmende Mannschaften und Spieler zu handeln. Die Zuschauer konnten die jeweils aktuellen Kurse unmittelbar sowohl im Internet als auch bei der Fernsehübertragung mitverfolgen. Die Optionen wurden bei Eintritt der entsprechenden Wettbewerbssituation (zum Beispiel: Deutschland wird Gruppenletzter) in einen bestimmten Spielgeldbetrag gewandelt und ausgezahlt.
Eine wichtige Forderung bestand darin, einen Großteil der xetra-Börsenregeln umzusetzen. In über 500000 getätigten Transaktionen spekulierten mehr als 30000 Fußball- und Börsenfans kostenlos auf den potenziellen Europameister und die erfolgreichsten Spieler. Aufgrund der hohen Beteiligung ging direkt im Anschluss das ebenfalls von 100world AG entwickelte Tour-de-France-Börsenspiel online.
Literaturempfehlung
Kent Beck, eXtreme Programming Explained: Embrace Change, New York 1999
Kent Beck, Martin Fowler, Planning Extreme Programming, New York 2000
Martin Fowler, Refactoring, New York 1999
Abb: Architektur der Börsenspiel-Anwendung
Quelle: 100world.com