Diplomarbeit. Demonstration der Dynamik in Logistik- und Produktionsnetzwerken anhand des Beer Distribution Game in einer Online-Version

Transkript

1 Diplomarbeit Demonstration der Dynamik in Logistik- und Produktionsnetzwerken anhand des Beer Distribution Game in einer Online-Version Betreuer: Dipl.-Wi.-Ing. Jörg Nienhaus Zürichbergstrasse 18 CH-8028 Zürich Institut für Informationssysteme: Prof. Dr. C.A. Zehnder ETH Zentrum, IFW CH-8092 Zürich Logistik und Informationsmanagement: Prof. Dr. Paul Schönsleben ETH-Zentrum für Unternehmenswissenschaft Zürichbergstrasse 18 CH-8028 Zürich

2 1 Abstract / Management Summary Das Beer Game wurde entwickelt als Einführung in die Konzepte der Systemdynamik. Gespielt werden dürfte es hauptsächlich von Studenten oder an Seminaren für Firmen. Die Spieler machen die Erfahrung, eine Rolle in einem komplexen System zu spielen und sehen anschliessend die Auswirkungen ihres Handelns. Das Ziel des Spiels ist die Minimierung der Kosten für eine gegebene Supply-Chain. Die Spieler erleben den sogenannten Bullwhip-Effekt die Bestellmengen vervielfachen sich über die Länge der Lieferkette, da die Spieler jeweils nur die Bestellinformationen des jeweiligen Vorgängers kennen. Die Aufgabe dieser Diplomarbeit war es, das bestehende klassische Brettspiel auf eine Online- Variante abzubilden. Dazu wurde eine Client-Server Architektur aufgesetzt. Umgesetzt wurde der Client als Java-Applet und der Server als Java-Programm. Die Kommunikation wird über eine Socket Connection abgewickelt. Als Erweiterung zum klassischen Beergame kann auch der Computer einzelne (oder alle) Rollen übernehmen und nach gewissen vorgegebenen Strategien spielen. Die Auswertung erfolgt in zahlreichen Charts, welche entweder einzelne oder überlagerte Kurven enthalten, welche den Spielverlauf sehr schön aufzeigen. In der Auswertung ist es auch möglich, sich jede einzelne Runde (mit den Zahlen und Graphen aller Mitspieler) nochmals anzusehen. Die Spieler werden über ihre (weltweit eindeutige) adresse identifiziert. Jeder Spieler hat die Möglichkeit, sein eigenes neues Spiel mit verschiedenen Parametern zu kreieren und danach andere Spieler einzuladen oder selbst einem anderen bestehenden Spiel beizutreten. Das Spiel wurde so programmiert, dass ein einzelner Spieler ein laufendes Spiel nicht blockieren kann. Dazu wird eine fixe Zeit pro Bestellrunde vorgegeben läuft diese ab, übernimmt der Computer die Bestellung. Fällt ein Client ganz aus, wird dessen Rolle ebenfalls an den Computer übertragen. Die beendeten Spiele werden auf dem Server gespeichert. Den Spielern steht jederzeit die Möglichkeit offen, die Auswertung ihrer beendeten Spiele wieder anzusehen. Dies ist sinnvoll, falls das Spiel zu einer späteren Zeit (ev. in einer Vorlesung) besprochen werden soll. Der folgende Bericht liegt in vier Hauptteilen vor. Im ersten Teil folgt eine Auseinandersetzung mit theoretischen Grundlagen des Spieles sowie eine Situationsanalyse zu bereits bestehenden Varianten. Im zweiten Teil wird auf die Wahl der Entwicklungsumgebung eingegangen und im dritten Teil dann das Objektmodell und die Programmstruktur erläutert. Dazu gehört eine Kurzbeschreibung aller Klassen sowie deren wichtigsten Methoden. Abschliessend im vierten Teil folgt dann die Spielbeschreibung selbst mit verschiedenen Screenshots. Seite 2/76

3 2 Vorwort Als ich auf der Suche nach einer möglichen Diplomarbeit war, bin ich auf der Homepage der Professur für Logistik- und Informationsmanagement von Herrn Prof. Dr. Schönsleben auf diese Aufgabe gestossen. Die Problemstellung hat mich vom ersten Moment an fasziniert und die Faszination hat bis zum Schluss nicht mehr losgelassen. Mit freundlicher Unterstützung von meinem Diplomprofessor - Herrn Prof. Dr. Zehnder (Institut für Informationssysteme) - war es dann möglich, diese bereichsübergreifende Arbeit in Angriff zu nehmen. Neben der eigentlichen Aufgabe bestand die Motivation vor allem in der Herausforderung, mich einmal mit einer modernen Programmiersprache intensiv auseinandersetzen zu können (ich hatte zuvor weder in Java noch in einer anderen objektorientierten Sprache programmiert). Es war eine sehr interessante und spannende Erfahrung und das Projekt hat vom Anfang bis zum Ende Spass gemacht. An dieser Stelle muss ich meinem Freund Simon Zweifel einen herzlichen Dank aussprechen, da er mir als Informatiker während der ganzen Arbeit online als kompetenter Ratgeber in Programmierfragen zur Seite gestanden ist. Ohne ihn wäre diese Arbeit bei weitem nicht so weit fortgeschritten. Herzlich zu Dank verpflichtet bin ich auf meinen Eltern Karl und Ruth Duijts, welche die Korrekturlesung übernommen haben sowie Nina Reiser für die spanische Übersetzung. Im Laufe des Projektes wurde aus der Arbeit eher ein Hobby - Probleme wurden in zahlreichen Nachtschichten und Wochenendeinsätzen gelöst. Auch Schreckensmomente fehlten natürlich nicht; zum Beispiel ist in der Abgabewoche mein Laptop ausgestiegen, auf dem sowohl das gesamte Programm als auch dieser Bericht gespeichert war (selbstverständlich gab es Sicherheitskopien aber eben...). Glücklicherweise stellte sich heraus, dass bloss das Netzteil defekt war ein paar Stunden später war mein sonst so zuverlässiges Mac-PowerBook wieder einsatzfähig. Mit dieser Arbeit schliesse ich nun mein Studium ab. Wenn ich zurück blicke, darf ich sagen, dass es mir sehr gefallen hat und dass ich dasselbe Studium wieder wählen würde. Ich freue mich nun aber auch auf eine neue Herausforderung im Berufsleben. Zürich, Seite 3/76

4 Inhaltsverzeichnis 1 Abstract / Management Summary 2 2 Vorwort 3 3 Aufgabenstellung 6 4 Das Beer Distribution Game Die Entstehung Das traditionelle Beer Game Theoretische Grundlagen der Bullwhip Effekt 9 5 Situationsanalyse Existierende Varianten des Beer Games Brettspiel Klassische Variante Computerized Beer Game Simple ++ Variante Beurteilung 15 6 Umsetzungskonzept Pflichtenheft / Leitlinien für die Umsetzung Auswahl der Programmiersprache, Entwicklungsumgebung Java offene Probleme Java Support Unterschiede in der Java Implementation Lösungsansätze für die Implementierung Ausschliessliche Verwendung von JDK 1.1.x und früher Installieren von nicht Kern Java Klassen auf den Clients Unterstützung für nur einen Browsertyp Verwenden des Java Plug-in Verwenden von Java Web Start Zusammenfassung der Lösungsansätze Die Wahl 20 7 Diskussion und Auswahl der Architektur Umsetzungsentscheid Programmarchitektur Der Client Der Server Kommunikationskonzept http-requests (request/response) Socket connection RMI Remote Method Invocation Umsetzungsentscheid 22 8 Die Umsetzung Kurzübersicht über die Packages und ihre Klassen Das Package beergame.server Das Package beergame.client Das Package beergame.client.images Das Spielkonzept 28 Seite 4/76

5 9 Klassen des Package beergame.server BeergameServer.java HelloThread.java SendThread.java ListenThread.java PlayerId.java Game.java Strategy.java Klassen des Package beergame.client BeergameClient.java ClientListener.java ClientSender.java GameLogic.java OrderPerformedTransition NextRoundTransistion ServerMessage.java Res.java Ref.java PnlStatistics.java DlgNewGame.java DlgJoinGame PnlStock.java, PnlGoodsReceiving.java und PnlTranport.java mögliche Erweiterungen des Spieles Spielbeschreibung Die Anmeldung Der Welcome-Screen Ein neues Spiel erzeugen Beitreten zu einem Spiel Spielstart Das Spiel Die Auswertung Auswertung einer Computer Simulation Animationen Anhang Übersicht über die Klassen und ihre Abhängigkeiten Der Server Start Prozess / Start of a socket connection The Invitation Process a three way handshake Literaturverzeichnis 76 Seite 5/76

6 3 Aufgabenstellung Herrn Herbstweg Zürich Dipl.-Wi.-Ing. Jörg Nienhaus Zürichbergstrasse 18 CH-8028 Zürich Tel , Fax Joerg.Nienhaus@ethz.ch Zürich, 6. September 2001 Diplomarbeit Arbeitsbeginn: 22. Oktober 2001 Abgabetermin: 21. Januar 2001 (60 Werktage) Demonstration der Dynamik in Logistik- und Produktionsnetzwerken anhand des Beer Distribution Game in einer Online-Version Das zu Beginn der 60er Jahre in der System Dynamics Group am Massachusetts Institute of Technology (MIT) entstandene Beer Distribution Game veranschaulicht den in Logistik- und Produktionsnetzwerken auftretenden Bullwhip-Effekt: Ein Unternehmen macht die Anzahl der beim Zulieferer zu bestellenden Komponenten von den Bestellungen des ihm im Netzwerk vorgelagerten Unternehmens (und nicht von denen des Endkunden) abhängig. Deshalb schwanken die Bestellmengen umso stärker, je mehr Stufen im Netzwerk zwischen einem Unternehmen und dem Endkunden liegen. Die steigende Variabilität der Bestellmengen erfordert bei den Zulieferern mit zunehmender Tiefe im Netzwerk immer höhere Sicherheitsbestände, damit sie ihre Lieferfähigkeit gewährleisten können. Diesen Effekt vollziehen beim Beer Distribution Game vier Teilnehmer nach, indem sie ein Logistik- und Produktionsnetzwerk bestehend aus Lieferant, Produzent, Grosshändler und Einzelhändler simulieren. Im Rahmen der Diplomarbeit sollen Sie ein Konzept für eine Online-Version der Simulation erstellen und es anschliessend umsetzen. Eine solche Online-Version erlaubt Teilnehmern an beliebigen Standorten auf der Welt, sich zu einer vorher verabredeten Zeit auf einer Webseite zu treffen und am Beer Distribution Game teilzunehmen. Ferner kann die sonst manuell vorzunehmende Auswertung der Ergebnisse wie bei einer am ETH-Zentrum für Unternehmenswissenschaften (BWI) bereits vorhandenen Version in Simple++ automatisch erfolgen. Seite 6/76

7 In einem ersten Schritt machen Sie sich mit den Regeln des Beer Distribution Game und der dieser Simulation zugrunde liegenden Theorie vertraut. Zeigen Sie anschliessend, welche Anforderungen sich aus den Regeln für die Umsetzung in eine Online-Version ergeben. Berücksichtigen Sie dabei, dass die Simulation beim klassischen Beer Distribution Game in Runden getaktet erfolgt. Schlagen Sie Varianten und Erweiterungen der Regeln vor, die durch die erweiterten Möglichkeiten einer Online-Version möglich sind, und wählen Sie die aus Ihrer Sicht besonders geeigneten aus. Denken Sie daran, dass Sie für die Teilnehmer Möglichkeiten vorsehen müssen, sich zu einer verabredeten Zeit zum Spiel zu treffen. Ferner sind für nicht besetzte Positionen die Bestellungen automatisch anhand eines Bestellmusters zu generieren. Nachdem Sie Anforderungen an die Online-Version des Beer Distribution Game spezifiziert haben, wählen Sie die zur Umsetzung des Konzeptes geeignete Informationstechnologie. Beziehen Sie Java (für Client und Server), sowie Perl und PHP (für den Server) als Programmiersprachen in die Evaluation ein. Prüfen Sie auch, ob der Einsatz von Corba sinnvoll ist. Berücksichtigen Sie bei der Evaluation, dass die Simulation eingebettet in eine Webseite mit gängigen Browsern verwendbar sein soll. Abschliessend erstellen Sie ein geeignetes Objektmodell und nehmen die Implementation vor. Wir erwarten von Ihnen u.a.: ein angemessenes Studium von Fachliteratur und Webseiten einen strukturierten Quellcode Ihres Programmes eine sorgfältige Dokumentation Ihrer Arbeit 1 eine Vorgehensweise nach den Grundsätzen wissenschaftlichen Arbeitens Herr Prof. Dr. Paul Schönsleben und Herr Jörg Nienhaus vom ETH-Zentrum für Unternehmenswissenschaften (BWI) werden Sie in die Thematik einführen und Ihre Arbeit begleiten. Die Beurteilung der Arbeit nimmt Herr Prof. Carl August Zehnder vom Institut für Informationssysteme vor. Zürich, 2. Oktober 2001 Prof. Dr. Paul Schönsleben Jörg Nienhaus, Assistent 1 Als Basis für die formale Gestaltung Ihres Berichtes sowie für eine allgemeine Einführung in die Methodik des wissenschaftlichen Arbeitens empfehlen wir: Theisen, Manuel René: Wissenschaftliches Arbeiten, 8. Aufl., München: Verlag Franz Vahlen, 1997 Seite 7/76

8 4 Das Beer Distribution Game 4.1 Die Entstehung 2 Das traditionelle Beer Distribution Game entstand in den Anfängen der systems dynamic in den sechziger Jahren. Seit drei Jahrzehnten wird das Spiel, welches einen äusserst einfaches, modellhaftes Produktions- und Distributionswerkzeug nachbildet, verwendet als eine Einführung in das Systemdenken in verschiedensten Schulungen, sowie bei Aus- und Weiterbildungskursen. 4.2 Das traditionelle Beer Game 3 Unter dem traditionellem Beer Game wird das ursprüngliche Brettspiel verstanden. Vier Spieler bzw. Teams sitzen in einer Reihe und verkörpern eine Lieferkette, nämlich die Fabrik (Factory), das Distributionszentrum (Distribution), den Grosshändler (Wholesaler) und den Einzelhändler (Retailer). Jeder Spieler bestellt bei seinem Lieferanten die notwendigen/vermuteten Bedarfe und versucht gleichzeitig, die Bedarfe seiner Kunden zu decken. Dabei hat er keine Kenntnisse über die Bestellvorgänge ausserhalb seines Bereiches. Die Endkundenbestellungen (externe Nachfrage) werden durch einen verdeckten Kartenstapel vor dem Einzelhändler erzeugt. Die Bestände an Lager, im Wareneingang und auf Transport werden durch Spielsteine (meist eben Bierdeckel) verkörpert. Durch die Felder Wareneingang und Transport werden die Verzögerung durch den Transport und die Warenannahme simuliert. Jeder Spielstein an Lager erzeugt in jeder Spielrunde Lagerkosten von $0.50. Jeder Bestellrückstand (Backlog Unfähigkeit, dem Bedarf seines Kunden nachzukommen) ergibt pro Spielrunde Kosten von $1. Die Gesamtkosten pro Spielstation setzen sich somit wie folgt zusammen: Gesamtkosten = Σ (Lagerbestände * $0.50) + Σ (Bestellrückstände* $1.00) Das Ziel des Retailers, Distributors, Wholesalers und der Factory ist die Gesamtkosten zu minimieren, entweder individuell oder für das ganze System Zu beachten ist, dass Bestellrückstände doppelt so hoch bestraft werden wie Lagerbestände. Der Moderator des Spiels achtet darauf, dass unter den Spielern keine Informationen (ausser Bestellungen) ausgetauscht werden und veranlasst die Spieler synchron zu spielen. Sämtliche Vorgänge (Bestände, Lieferungen, Bestellrückstände und Bestellungen) werden durch jeden Teilnehmer auf einem Statistikblatt festgehalten. Der Moderator führt die anschliessende Diskussion und Auswertung der Statistikblätter und fasst gewonnene Erkenntnisse zusammen. Die Verblüffung der Spieler während der Besprechung der Ergebnisse besteht im Normalfall darin, dass die externe Nachfrage (Kartenstapel bei Einzelhändler) durchs ganze Spiel hindurch konstant war mit der einzigen Ausnahme von einem Sprung von vier auf acht Einheiten zwischen der vierten und fünften Spielrunde. 2 Vgl: Sterman D Vgl: Burkhalter P Seite 8/76

9 4.3 Theoretische Grundlagen der Bullwhip Effekt Das Ziel des Beer Games ist es den Teilnehmern den sogenannten Bullwhip Effekt (auch bekannt als whiplash oder whipsaw ) Effekt auf eine einfache und eindrückliche Art zu demonstrieren 4. Der Bullwhip Effekt ist nichts anderes als eine Verstärkung der Variabilität der Nachfrageamplitude über die Stufen einer Supply Chain Kette. Der Grund lässt sich finden in der fehlenden (globaler) Information der tatsächlichen Nachfrage beim Endverbraucher. Oder anders ausgedrückt: Die Bestellmuster teilen eine gemeinsame Eigenschaft. Die Variabilität in der Bestellung für den Lieferanten (upstream) sind immer grösser als die Bestellungen des eigenen Kunden (downstream). Allgemeine Symptome solcher Variabilitäten können übermässige Lagerbestände, schlechte Produktionsvorhersagen, ungenügende oder überhöhte Kapazitäten, schlechter Kundenservice aufgrund von nicht verfügbaren Produkten oder lange Rückstände in der Lieferung sein. Abbildung 1: Zunahme der Variabilität der Nachfrage in der Supply Chain In der Literatur (Lee, Simchi-Levi) werden vier Hauptgründe für die Entstehung des Bullwhip Effekt aufgeführt, welche sich aber schliesslich immer auf die (lokal) fehlende globale Information der Verbrauchsmenge des Endkunden zurückführen lässt. Die Gründe sind: 1. Demand forecast updating Die Vorhersage für die kommenden Bestellmengen wird mangels Informationen oft aus vergangenen Bestellungen des direkten Kunden abgeleitet (und nicht von der tatsächlichen Nachfrage des Endkunden). Diese Vorhersagen werden laufend angepasst und dann an den eigenen Lieferanten weitergegeben. Da die Vorhersagen nicht nur den wahren Verbrauch, sondern auch die jeweiligen Sicherheitsbestände beinhalten, sind die Fluktuationen der 4 Vgl: Lee H.L. et al: 1997 Seite 9/76

10 Bestellmengen über die Zeit oft viel grösser als die tatsächliche Nachfrage. Je länger die Supply Chain ist, desto grösser werden die Fluktuationen. 2. Lead Time Die Durchlaufzeit hat einen signifikanten Einfluss auf die Variabilität der Bestellungen. Gründe lassen sich finden in der Erhöhung der Sicherheitsbestände und somit der Bestellmengen. 3. Batch Ordering Aus Gründen der Kosteneffizienz (Bestell- und Transportkosten) wird oft in Batches (Losen) bestellt. Dabei werden hereinkommende Bestellungen des eigenen Kunden nicht sofort an den eigenen Lieferanten weitergegeben sondern zuerst gesammelt. Die Auslösung einer Bestellung kann zum Beispiel wöchentlich oder monatlich erfolgen oder dann, wenn ein full truck load erreicht wird. Genau dies führt aber zu einer massiven Steigerung der Variabilität der Nachfrage zwischen Kunde und Lieferant und führt zum Bullwhip Effekt. 4. Price fluctuation Bestellungen werden oft nicht kontinuierlich ausgelöst sondern dann getätigt, wenn die Ware gerade günstig gekauft werden kann (Währungsschwankungen, Mengenrabatte, Spezielle Aktionen usw.). Dieses sogenannte forward buying widerspiegelt offensichtlich die tatsächliche Nachfrage nicht und zeigt sich direkt im Bullwhip Effekt wieder. 5. Inflated Orders (Rationing and shortage gaming) Wenn der Lieferant in Verzug ist und die Bestellmengen die Kapazitäten überschreiten, müssen die Lieferungen rationiert werden. Dies geschieht oft so, dass die Kunden nur einen Teil (z.b. 50%) der bestellten Ware erhalten. Ist bekannt, dass Lieferschwierigkeiten auftreten können, bestellen Kunden oft die mehrfache Menge und/oder bei verschiedenen Lieferanten. Diese Reaktion führ zwar zu einem lokalen Optimum (der Kunde erhält schnellstmöglich seine 100%), doch global gesehen führt dies zu einer massiven Überschätzung des Kundenbedarfs. Sobald sich die Lage beruhigt, verschwinden die Bestellungen plötzlich und Bestellannullierungen häufen sich. Lösungsansätze zur Vermeidung des Bullwhip Effekts Natürlich lassen sich die Symptome teilweise auch lokal bekämpfen, indem zum Beispiel Preise stabil gehalten werden (Every day low price EDLP), Strafen für Annulationen eingeführt werden, die Durchlaufzeiten reduziert oder externe Logistikpartner (kleinere Losgrössen, economy of scale) zugezogen werden. Die einzige Möglichkeit, den Bullwhip Effekt längerfristig zu vermeiden oder zumindest einzuschränken, bleibt aber, die Information über die Nachfrage des Endkunden auf der gesamten Lieferkette global verfügbar zu machen. Dies entspricht grundsätzlich einer Weitergabe der jeweiligen Absatzdaten. Genau dies soll mit dem Beer Game veranschaulicht werden. Seite 10/76

11 5 Situationsanalyse 5.1 Existierende Varianten des Beer Games Brettspiel Klassische Variante 5 Beim klassischen Brettspiel werden die Funktionen Retailer, Wholesaler, Distributor und Factory von je einem Mitspieler oder einem Mitspielerteam übernommen. Kundenbestellungen liegen anhand eines vorbereiteten, verdeckten Kartenstapels vor. Die Auswertung erfolgt von Hand, ev. durch Nachführen einer Excel Tabelle mit anschliessender graphischer Auswertung. Exemplarisch ist unten das Ergebnis eines Spiels beim Lieferantentag eines Schweizer Maschinenbau-Unternehmens zu sehen. Die Fotos dieser Seite wurde ebenfalls bei diesem Anlass aufgenommen. Bestellungen 45 Abbildung 2: Lieferantentag eines Schweizer Maschinenbau- Unternehmens Kunde EinzelhŠndler Grossist Verteiler Produzent Woche Lagerbestand EinzelhŠndler Grossist Verteiler Produzent Woche Abbildung 3: Das Beer Distribution Game Brettspiel 5 Vgl. Sterman J. D. Seite 11/76

12 Diese Variante liegt anhand einer Windowsapplikation vor. Im Gegensatz zum klassischen Brettspiel kann jedoch nur ein menschlicher Mitspieler daran teilnehmen, die restlichen Funktionen werden vom Computer übernommen. Als Erweiterung zum klassischen Beer Game wurden drei weitere Modi eingeführt: Global Information Mode: Lagerbestände und Bestellungen der gesamten Lieferkette sind global verfügbar. Dies erlaubt dem Mitspieler die Bestellungen besser zu planen und die Dynamik der Logistikkette besser zu verstehen. Short Lead Time Mode: Die zweistufige Verzögerung durch den Transport und den Wareneingang wird um eine Stufe reduziert. Dies führt zu einer schnelleren Reaktion auf Bestellungen und führt somit normalerweise zu einem kleineren Backlog. Centralized Mode: Dem Spieler sind alle Informationen verfügbar. Die Bestellungen werden direkt in der Factory platziert und werden so schnell wie möglich durch das System zum Retailer gesendet (es werden keine Lager ausser beim Retailer selbst geführt). Zudem ist es möglich die Bestellstrategie der Computermitspieler festzulegen. Folgende Optionen sind pro automatischem Mitspieler möglich (s, S, Q und M können als Variablen für jede Stufe festgelegt werden): s-s: Sobald der Lagerbestand unter s fällt, wird vom System eine Bestellung platziert, um das Lager wiederum auf die Menge S zu bringen 6 Vgl: Simchi-Levi 2000 (mit beiliegender CD) Seite 12/76

13 s-q: Sobald der Lagerbestand unter s fällt, wird eine Bestellung der Menge Q ausgelöst. Order to S: In jeder Spielrunde platziert das System eine Bestellung so, dass der Lagerbestand wiederum auf S gebracht wird. (direkte Weitergabe der Bestellung vom Kunden an den Lieferanten). Order Q: Das System bestellt in jeder Runde konstant Q Einheiten. Update s: Wenn der Lagerbestand unter s fällt, wird bestellt, bis s erreicht wird. Die maximale Bestellmenge beträgt S. Die eigene Bestellung wird aus dem Schnitt und der Standardabweichung früherer Bestellungen errechnet. Echelon: Sobald der Lagerbestand unter s fällt, wird bestellt bis s erreicht wird unter Einhaltung der maximalen Bestellmenge von S. s wird für jede Station in der Lieferkette nach einer modifizierten Version der Standard Echelon Formel berechnet. Die Auswertung des Spiels erfolgt anhand einer einfachen Graphik (vgl. unten) und einer Anzeige der Bestellmenge des Spielers über die einzelnen Spielperioden. Ausserdem lässt sich von allen Stationen den Durchschnitt und die Standardabweichung der Bestellungen anzeigen. Abbildung 4: Graph Auswertung des Computerized Beer Games Seite 13/76

14 5.1.3 Simple ++ Variante 7 Diese Variante wurde entwickelt in einer Studienarbeit am Betriebswissenschaftlichen Institut der ETH Zürich. Es ging darum, verschiedene Bestellstrategien im Beer Game zu testen und auszuwerten. Aus diesem Grund ist wiederum (maximal) nur ein Mitspieler zugelassen, die restlichen Stationen werden interaktiv vom Computer mit der ihm zugeteilten Strategie bedient. Diese Version bietet zudem die Möglichkeit, die Bestellmengen eines gespielten klassischen Beer Games in entsprechende Tabellen einzugeben und danach eine Auswertung dieses Spiels durchzuführen. Folgende Strategien wurden implementiert: Nachspielen: Ein klassisches Beer Game wird nachgespielt (Eingabe der jeweiligen Bestellmengen in Tabellen) Interaktiv: Einem Mitspieler wird ermöglicht, die eigene Strategie im Wettbewerb mit den verbleibenden Spielstationen und den ihnen zugeteilten Bestellstrategien zu testen. Bestellbestand: Die Losgrösse wird anhand der klassischen Andler Formel 8 bestimmt. MRP (Material Requirements Planning): Hierzu müssen die Bedarfe der Kunden bekannt sein. Diese Strategie macht aus Sicht dieser Arbeit jedoch wenig Sinn, da es im Beer Game genau darum geht, dass diese Informationen nicht vorhanden sind, as den zu demonstrierenden Bullwhip Effekt 9 ja auslöst. Between Sobald der Lagerbestand unter eine bestimmte Menge (m) fällt wird, eine Bestellung ausgelöst berechnet aus einer Lagerbestandsobergrenze minus die noch an Lager vorhandenen Menge (inkl. Backlog). Sensitiv Wie Between, ausser, dass für den Lagerbestand auch noch die Bestände in Arbeit (Transport, Wareneingang) berücksichtigt werden. Random1X Spezifikation der Parameter Random_min, Random_max sowie Orderstop. 7 Vgl. Burkhalter J.P Vgl Schönsleben P Vgl. Lee H.L Seite 14/76

15 Strategie1X Es wird grundsätzlich die Bestellmenge des Kunden direkt an den Lieferanten weitergegeben. Variationen werden gemacht im Umgang mit dem Backlog. Strategie2X Bestellmenge errechnet sich durch die Mittelung der letzten y Bestellungen (moving average). Variationen liegen wiederum im Umgang mit dem Backlog. Eine ausführliche Beschreibung der einzelnen Strategien sowie deren Auswertung kann in der Studienarbeit nachgelesen werden. 5.2 Beurteilung Das Ziel dieser Arbeit ist es in erster Linie, eine Variante des Spiels zu implementieren, welche es vier Mitspielern ermöglichen sollte, gleichzeitig miteinander online über das Internet im selben Spiel zu spielen. Diese Anforderung wird in keiner der bereits vorhandenen Lösungen erfüllt. Die vorliegende Arbeit soll nun genau diese Lücke schliessen. Seite 15/76

16 6 Umsetzungskonzept 6.1 Pflichtenheft / Leitlinien für die Umsetzung Aus der Aufgabenstellung lassen sich folgende vier Hauptanforderungen herauslesen: 1. Es soll über das Internet gespielt werden können. Mehrere Spieler sollen an einem Spiel teilnehmen können und gleichzeitig sollen mehrere Spiele gleichzeitig stattfinden können. 2. Das Spiel soll mit möglichst vielen Clients (Betriebssystemen und Browsern) direkt kompatibel sein. Eine hohe Benutzerfreundlichkeit soll angestrebt werden. 3. Die Spieler sollen sich das Spiel, an welchem sie teilnehmen, selber auslesen können. Dies ermöglicht es mit bestimmten Teilnehmern zu einer verabredeten Zeit zu spielen. 4. Die Auswertung der Resultate soll automatisch vorgenommen werden Drei weitere Anforderungen erscheinen sinnvoll: 5. Der Computer soll nicht besetzte Rollen übernehmen können oder Spieler ersetzen, welche ausgefallen sind, damit das Spiel nicht unterbrochen wird. 6. Es soll eine Zeitlimite pro Spielrunde eingeführt werden, damit ein einzelner Spieler nicht das ganze Spiel blockieren kann. Bei Ablauf dieser Zeitlimite übernimmt der Computer die Bestellung für den betreffenden Spieler 7. Die Spielsprache soll englisch oder mehrsprachig sein, da auch Spieler, bzw. Institute aus der Westschweiz (EPFL Lausanne) Interesse an diesem Spiel bekundet haben. 6.2 Auswahl der Programmiersprache, Entwicklungsumgebung In Absprache mit dem Betreuer haben wir uns auf die Programmiersprache Java festgelegt. Als Entwicklungsumgebung wurde der JBuilder (5) von Borland gewählt. Der Client soll demnach in Form eines Java-Applets umgesetzt werden. Es hat sich gezeigt, dass Skriptsprachen wie Perl, PHP, ASP und Javascript für die obigen Anforderungen wenig geeignet sind. Gründe sind unter anderem: Zuwenig/nicht Interaktiv (z.b. für bewegte Abläufe/Animationen oder clientseitige Validierung von Eingabeparametern) Code wird bei grossen Programmen schnell unübersichtlich Programmiersprachen haben diese Nachteile weniger. Insbesondere Java hat sich geradezu angeboten für die Umsetzung dieser Aufgabe. Zudem wird bei Java die Möglichkeit geboten, eine ausgewachsene Entwicklungsumgebungen zu verwenden. Seite 16/76

17 6.3 Java offene Probleme 10 Um ein Applet sauber zum laufen zu bringen müssen viele Feinheiten beachtet werden. Zum Beispiel variieren die verschiedenen Browser (wie zum Beispiel der Internet Explorer oder Netscape) im Level der Unterstützung des JDK und jeder Browser verfolgt einen anderen Ansatz in der Implementation von Java Java Support Ein verbreitetes Problem ist, dass das JDK mit welchem das Applet entwickelt wurde nicht kompatibel sind mit den Virtual Machines (VM) der verschiedenen Browser. Viele Benutzer verwenden noch alte Browser, welche JDK1.1.5 oder frühere Versionen benutzen. Swing wird erst in JDK eingeführt. Es ist sogar so, dass Java 2 welches Swing voll unterstützt teilweise nicht einmal in der neusten Browsergeneration implementiert ist. Folgende Browser unterstützen das JDK 1.1: Netscape 4.06 (und höher) Internet Explorer 4.01 (und höher) Unterschiede in der Java Implementation Es gibt zwar Richtlinien und Spezifikationen welche (Java-) Funktionen von den Browsern unterstützt werden müssen, die Implementation derselben sowie aller Erweiterungen bleibt jedoch den Herstellern überlassen. Ein Unterschied liegt zum Beispiel in der Implementation des Security Managers sowie der Security Levels. So wird Medium Security in verschiedenen Browsern verschieden interpretiert und verschiedene Aktionen werden zugelassen oder eben nicht. Ausserdem werden von den Herstellern sogar Anpassungen in der Kernfunktionalität von Java gemacht, inklusive der vollständigen Auslassung bestimmter Eigenschaften. Dies führt zu unterschiedlichen (Fehl-) Verhaltensweisen der Applets in verschiedenen Browsern. Es ist praktisch unmöglich, immer um alle diese Fehler herumzukodieren. Ein weiterer Unterschied ist festzustellen beim Verhalten der Applets auf verschiedenen Betriebssystemen desselben Browsers. Beispielsweise können multi-threaded applets auf einer Plattform laufen, auf einer anderen aber nur sequentiell ausgeführt werden aufgrund von Problemen des Threading Models. (Macintosh zum Beispiel unterstützt das Multitasking erst ab System OSX vollständig). Diese Unterschiede machen ein ausgedehntes Testen und Debuggen unumgänglich. 10 Vgl: Web Application Developer s Guide, Borland Software Corporation Seite 17/76

18 6.4 Lösungsansätze für die Implementierung Ausschliessliche Verwendung von JDK 1.1.x und früher Programmieren der Applets in JDK 1.1.x und früheren Versionen beinhaltet eine Limitation auf die Funktionalität (und Bugs) dieser Versionen. Die meisten Browser unterstützen nun JDK 1.1.5, nicht aber die Swing Komponenten, welche in JDK eingeführt werden. Wenn Applets mit modernen Entwicklungsumgebungen (basierend auf Java2) geschrieben werden, muss streng darauf geachtet werden, dass nur AWT Komponenten verwendet werden und nicht von den neuen Komponenten Gebrauch gemacht wird. Der grösste Nachteil in der Verwendung von JDK 1.1.x und früher liegt darin, dass die komfortablen, erweiterten Funktionen von Java2 nicht genutzt werden können. Zudem muss Rücksicht auf die Umsetzung in den verschiedenen Browsern und Betriebssystemen genommen werden Installieren von nicht Kern Java Klassen auf den Clients Wenn nicht Kern Java Klassen auf den Clients installiert werden, kann unter Anpassung des Classpath ein download umgangen werden für Klassen, welche vom Applet verwendet werden. Dies ist jedoch grundsätzlich nur in einer Intranet-Umgebung möglich Unterstützung für nur einen Browsertyp Wenn das Applet für nur eine Version eines bestimmten Browsers programmiert wird, kann der Aufwand für speziellen Code und Unterhalt sowie umfangreichem Debugging minimiert werden. Dies in Kombination mit einer Implementation in JDK 1.1.x würde viele Probleme verhindern. Dies ist jedoch wiederum nur in Intranet Umgebungen möglich, welche durch eine IS policy geregelt werden Verwenden des Java Plug-in Die meisten Browserprobleme können durch die Verwendung des Java Plug-in von Sun umgangen werden. Dieses Plug-in ist derzeit die einzige Möglichkeit, allen Browsern dieselbe Version des JDK zur Verfügung zu stellen. Ein grosser Vorteil dieser Lösung zeigt sich ausserdem darin, dass auch die Swing Klassen (Java2) unterstützt werden. Wird von einem Browser zum ersten Mal eine plug-in enabled HTML Seite aufgerufen, erfolgt automatisch die Aufforderung, das Plug-in herunterzuladen. Einmal installiert hat die Client Maschine die offizielle Virtual Machine von Sun und das aktuellste JDK (inklusive Swing) lokal installiert. Der grösste Nachteil bei dieser Variante ist die Notwendigkeit eines einmaligen Downloads von etwa 5MB. 11 Vgl: Web Application Developer s Guide, Borland Software Corporation Seite 18/76

19 6.4.5 Verwenden von Java Web Start 12 Java Web Start ist eine neue Applikationsentwicklungstechnologie von Sun Microsystems, welche das Ausführen beliebiger Applets oder ausgewachsener Java Applikationen von einem Link auf einer Webseite im Browser ermöglicht. Wenn das Programm nicht bereits auf dem Computer vorhanden ist, werden alle nötigen Daten heruntergeladen und lokal in einem Cache gespeichert, so dass sie auch zu einem späteren Zeitpunkt wieder ausgeführt werden können. Sicherheit wird gewährleistet durch die Ausführung der Programme in einer sogenannten Sandbox, welche vergleichbar ist zur Sandbox, in welcher die herkömmlichen Applets ausgeführt werden. Ausserdem ermöglicht es Java Web Start die neuste Java 2 Technologie zu verwenden mit jedem beliebigen Browser. Diese Variante kombiniert die Vorteile einer Java Applikation mit einer sicheren Umgebung. Der Nachteil besteht darin, dass Java Web Start sehr neu ist und noch kaum auf einem Computer installiert ist. Der Download (full package international) hat eine Grösse von 8.7MB. 6.5 Zusammenfassung der Lösungsansätze Lösungsansatz Verwendung von... maximal sjdk 1.1.x Java Plug-in Java Web Start Vorteile Kein Download nötig - Technologie wird von den meisten gängigen Browsern unterstützt Dasselbe JDK für alle Betriebssystem und Browser Hochgradig kompatibel Unterstützt alle Funktionalitäten von Java 2 (inklusive Swing) Java Applikationen (und Applets) können übers Internet in einer sicheren Umgebung ausgeführt werden. Hochgradig kompatibel Unterstütz alle Funktionalitäten von Java 2 (inklusive Swing) Nachteile Es werden verschiedene JDKs verwendet welche zu Inkompatibilitäten führen können. Eine Beschränkung auf bestimmte Browserversionen ist notwendig Neuere Features (Swing...) werden nicht unterstützt. Download des Java Plug-in 1.3 notwendig (einmalig ca. 5 MB) Java Web Start muss lokal installiert sein (einmaliger Download von 8.7 MB) 12 Vgl: Seite 19/76

20 6.6 Die Wahl Obwohl sowohl das Plug-in als auch Java Web Start grosse Vorteile in Bezug auf plattformübergreifende Kompatibilität aufweisen, wurde zusammen mit dem Betreuer die Lösung der ausschliesslichen Verwendung des JDK 1.1.x gewählt. Der Grund, welcher den Ausschlag gegeben hat liegt in der Benutzerfreundlichkeit. Ein Download wird so nicht vorausgesetzt und jedermann hat direkten Zugriff auf das Spiel. Diese Lösung schliesst jedoch die Verwendung von Swing aus. Zudem wird ein umfangreiches Testen für die verschiedenen Betriebssysteme und Browsern notwendig. Seite 20/76

21 7 Diskussion und Auswahl der Architektur Eine Client-Server Architektur zeigte sich bald als ideal für die Umsetzung dieses Spieles. Dies aus mehreren Gründen: 1. Applets können aus Sicherheitsgründen nur mit dem Server kommunizieren, von dem sie heruntergeladen worden sind. Eine direkte Kommunikation zwischen Applets ist nicht möglich. 2. Der Server kann alle Spielstände halten bei Ausfall eines Clients gehen somit keine Informationen verloren. 3. Der Server kann beendete Spiele speichern und für Auswertungen weiterverwenden oder zu einem späteren Zeitpunkt wieder zugänglich machen. Punkt 1 könnte zwar umgangen werden, indem nicht Applets, sondern Java Applikationen auf den Clients verwendet werden. Diese Lösung bietet dem Spielteilnehmer aber die grossen Vorteile der Sicherheit der Applets nicht mehr und kommt aus diesem Grund nicht in Frage. Zudem würde sich eine Client-Server Architektur auch ohne diese Einschränkung geradezu anbieten. 7.1 Umsetzungsentscheid Programmarchitektur Der Client Der Client wird in Form eines Java Applets umgesetzt. Der Client erhält alle relevanten Daten zum Spiel direkt vom Server und kommuniziert ausschliesslich mit diesem. Das GUI besteht aus obgenannten Gründen (vgl. Umsetzungskonzept) ausschliesslich aus AWT Komponenten Der Server Der Server selbst ist eine Java Applikation, welche die gesamte Spiellogik beinhaltet. Neben der Zuweisung der verschiedenen Clients zu den Spielen hat er auch die Aufgabe, verschiedene nicht besetzte Rollen selbst zu übernehmen. Zudem hat er die Aufgabe, beendete Spiele abzuspeichern, um sie zu einem späteren Zeitpunkt wieder abrufen zu können. Seite 21/76

22 7.2 Kommunikationskonzept In Java gibt es drei Möglichkeiten über das Internet zu kommunizieren. Diese werden nachfolgend kurz besprochen: http-requests (request/response) Der Vorteil von http-requests ist, dass diese Methode sehr einfach ist. Zudem benutzt sie nur den Port 80 und hat somit keine Probleme mit Firewalls. Http-requests funktionieren aber nur unidirektional, das heisst, der Server kann von sich aus nicht kommunizieren und die Verbindung bleibt nicht dauerhaft bestehen. Da nur über einen Port kommuniziert wird, muss die Benutzer-ID jedem request mitgegeben werden. Ein Broadcast von Nachrichten oder nur schon das Versenden einer Nachricht von Client-Server-Client ist schwierig und setzt ein regelmässiges Abfragen des Servers durch alle Clients voraus. Dies würde für unser Spiel zwangsläufig einen recht hohen Kommunikations-Overhead erzeugen Socket connection Die Socket connection bietet eine sehr schlanke und effiziente Kommunikation: Die Verbindung ist bidirektional, das heisst, Client und Server können kommunizieren und die Erkennung der Clients erfolgt über die Portnummern. Die Nachteile dieser Kommunikationsart liegen in der komplexeren Umsetzung ein eigenes Kommunikationsprotokoll muss implementiert werden. Zudem wird eine Rekonfiguration eventueller Firewalls notwendig, da weitere Ports neben dem Port 80 für die Kommunikation benötigt werden. In unseren Tests mit den interessierten Instituten der EPFL und der UNI Bern zeigten sich aber keinerlei Probleme RMI Remote Method Invocation RMI ermöglicht wie die Socket Connection eine bidirektionale Kommunikation. RMI ist sehr elegant, da die Kommunikation über direkte Methodenaufrufe von Server auf Client und umgekehrt erfolgt. RMI ist objektorientiert. Die Nachteile liegen wiederum in der komplexen Umsetzung es werden spezielle Stub und Skeleton Klassen benötigt. Zudem ist eine RMI Registry notwendig. Leider hat diese bei Internetverbindungen (noch) oft Schwierigkeiten. Zudem wird eine RMI Verbindung von den meisten HTTP-Proxyservern nicht zugelassen. Dies bedeutet, dass RMI via http getunnelt werden muss, was über die Anbindung an einen beliebigen Port passiert. Eine Rekonfiguration eventueller Firewalls ist auch hier unumgänglich Umsetzungsentscheid Für die Umsetzung dieses Spiels haben wir uns für die Socket Connection entschieden. Der Grund liegt vor allem in der bidirektionalen, sauberen und effizienten Kommunikation. Die Socket Connection ist ausserdem weniger problematisch als RMI. Seite 22/76

23 8 Die Umsetzung Für die Umsetzung wurde je ein Package für den Server und eins für den Client erstellt. Im Folgenden werden die einzelnen Packages (alphabetisch) mit ihren Klassen kurz vorgestellt. Eine ausführlichere Beschreibung der wichtigeren Klassen befindet sich in den Kapiteln 9 und Kurzübersicht über die Packages und ihre Klassen Das Package beergame.server BeergameServer.java Das eigentliche Programm mit der main() Methode. Beim Aufstarten liest er die gespeicherten PlayerId s und initialisiert das Spiel. Während der Laufzeit verwaltet er die Spiel- und Spielerlisten. Als Parameter kann die Anzahl zugelassener Verbindungen (resp. Spieler) übergeben werden Diese Klasse sollte in das Startup-Verzeichnis des hostenden Servers aufgenommen werden. (Ausführliche Beschreibung: Abschnitt 9.1, Seite 29) Game.java Die Spiellogik. Verwaltet und steuert das jeweilige Spiel. Hier werden Spiel- und Spielermodi, alle Stati, Namen, Bestellungen, Lagerbestände usw. gespeichert. Ebenso sind alle Methoden enthalten, welche für die Spielsteuerung zuständig sind. Pro Spiel wird eine Instanz dieser Klasse erzeugt. Wird ein Spiel regulär abgeschlossen, wird das jeweilige Objekt auf die Festplatte in den Ordner Saved Games ausgeschrieben. Dies ermöglicht es später, auch bei einem Server-Shutdown wieder auf die Spiele zuzugreifen. (Ausführliche Beschreibung: Abschnitt 9.6, Seite 34) HelloThread.java Der Thread welcher für den Verbindungsaufbau verantwortlich ist. Er hört auf einem vorgegebenen baseport, welcher die Applets auch kennen. Sobald ein Applet gestartet wird, teilt dieser Thread der neuen Verbindung einen fest zugewiesenen Port zu, auf dem die zukünftige Kommunikation dann stattfindet (Ausführliche Beschreibung: Abschnitt 9.2, Seite 30) Seite 23/76

24 ListenThread.java PlayerId.java SendThread.java Strategy.java Pro neue Verbindung wird ein ListenThread erzeugt. Dieser wartet auf Nachrichten des entsprechenden Clients und leitet diese weiter. (Ausführliche Beschreibung: Abschnitt 9.4, Seite 33) Die Spielerverwaltung. Enthält die Spielerlisten und pro Spieler einen Vektor der bereits gespielten Spiele. Enthält auch die Methoden um gespeicherte Spiele von der Festplatte auszulesen. Diese Klasse wird in regelmässigen Abständen auf Veränderungen geprüft und auf die Festplatte ausgeschrieben. (Ausführliche Beschreibung: Abschnitt 9.5, Seite 33) Pro Verbindung wird ein SendThread eröffnet. Dieser sendet die Servernachrichten an den ihm zugehörigen Client. Der SendThread enthält für den jeweiligen Spieler auch alle relevanten (spielerspezifischen) Informationen. (Ausführlich Beschreibung: Abschnitt 9.3, Seite 30) Diese Klasse enthält die verschiedenen Strategien, welche den Computerspielern zugeteilt werden können. Dazu werden unter anderem Methoden zur Verfügung gestellt, um den Moving-Average sowie die Standardabweichung über beliebige Datensätze zu berechnen. (Ausführliche Beschreibung: Abschnitt 9.7, Seite 37) Seite 24/76

25 8.1.2 Das Package beergame.client Das Package beergame.client enthält folgende Klassen (in alphabetischer Reihenfolge): BeergameClient.java ClientListener.java ClientSender.java DlgGameStart.java DlgJoinGame.java DlgJoinRequest.java DlgLogon.java DlgNewGame.java Das Applet selbst, welches für den Verbindungsaufbau mit dem Server verantwortlich ist zudem vor allem das GUI mit den Action Listeners enthält. (Ausführliche Beschreibung: Abschnitt 10.1, Seite 39) Ein Thread, welcher auf dem zugewiesenen Port auf Messages vom Server wartet, diese dann verarbeitet und weiterleitet (Ausführliche Beschreibung: Abschnitt10.2, Seite 42) Ein Thread, welcher Nachrichten über eine Socket Connection vom Client an den Server verschickt (Ausführliche Beschreibung: Abschnitt 10.3, Seite 43) Ein Dialog, der vor dem Spielstart aufgerufen wird und abfragt, ob die Spieler bereit sind. Ein Dialog, der das Interface zur Verfügung stellt, einem Spiel beizutreten. Er stellt die Funktionen zur Verfügung, die gewünschte Rolle auszuwählen und enthält Infos zum Spiel. Bei Änderungen (z.b. eine Rolle wird an einen anderen Spieler vergeben) wird er automatisch aktualisiert. (Ausführliche Beschreibung: Abschnitt 10.12, Seite 56) Ein Dialog der den Spielinhaber um Zutrittserlaubnis für andere Spieler anfragt. Ein Dialog, der beim Aufrufen der Beergame Homepage erscheint und den Benutzer nach seinem Namen und adresse (=ID) abfragt. Ein Dialog, welcher dem Spieler die Möglichkeit bietet ein neues Spiel zu kreieren. Unter anderem können hier der Spielmodus, die Computerspieler sowie verschiedene Spielparameter festgelegt werden. (Ausführliche Beschreibung: Abschnitt 10.11, Seite 55) Seite 25/76

26 GameLogic.java ListData.java ModalParent.java NextRoundTransition OrderPerformedTransition.java PnlGoodsReceiving.java PnlImage PnlSignal.java Methoden, welche die eigentliche Spiellogik des Clients enthalten und den gesamten Spielablauf sowie den Status des Clients festhalten und steuern. (Ausführliche Beschreibung: Abschnitt 10.4, Seite 43) Eine kleine Klasse, welche (ursprünglich) die vom Server empfangenen Listen identifiziert. Die Klasse wird kaum mehr gebraucht, da der grösste Teil der Listen mittels Arrays und Vectors versandt wird. Ein Interface, welches bei Dialogen die Parent-Klasse auf Modal stellt (Browser unterstützen keine modalen Dialoge im Moment). Ein Thread, welcher an die Klassse gamelogic.java angehängt ist. Er ist u.a. verantwortlich für die Animationen nachdem eine neue Runde gestartet hat (Ankunft Lastwagen, Ankunft der neuen Bestellung) (Beschreibung: Abschnitt 10.6, Seite 48) Eine Thread, welcher an die Klasse gamelogic.java angehängt ist. Er ist verantwortlich für die Animationen. Unter anderem verschiebt er die Fässer und lässt den Lastwagen fahren. (Beschreibung: Abschnitt Error! Reference source not found., Seite Error! Bookmark not defined.) Ein Panel, welches in BeergameClient.java importiert wird und die Graphik und Animation des Wareneingangs zur Verfügung stellt. (Beschreibung: Abschnitt 10.13, Seite 57) Eine allgemeine Klasse, welches die Klasse Panel um die Funktion erweitert ein Bild an einer beliebigen Stelle zu platzieren., Ein Panel, welches das Lichtsignal zur Verfügung stellt, welches den Status der einzelnen Spieler anzeigt. Die Lichter können einzeln angesteuert werden. Seite 26/76

27 PnlStatistics.java PnlStock.java PnlTransport.java Ref.java Res.java Ein Panel, in dem die verschiedenen Auswertungscharts gezeichnet werden. Es werden umfangreiche Funktionen zur Verfügung gestellt um einen oder mehrere Graphen pro Chart zu zeichnen und dynamisch zu aktualisieren. Die Achsen können automatisch den übergebenen Werten angepasst werden. (Ausführliche Beschreibung: Abschnitt 10.10, Seite52) Ein Panel, welcher die Graphik sowie die Animation für das Lager zur Verfügung stellt. (Beschreibung: Abschnitt 10.13, Seite 57) Ein Panel, welcher die Graphik sowie die Animation für den Transport zur Verfügung stellt. (Beschreibung: Abschnitt 10.13, Seite 57) Eine Klasse, welche Referenzen (wie Spielerstati, Spielmodi, usw.) auf Integers abbildet, um den Kommunikationsaufwand klein zu halten. Diese Klasse wird auch vom Server importiert. (Ausführliche Beschreibung: Abschnit 10.9,Seite 52) Eine Klasse, welche alle String Ressourcen enthält. Dies ermöglicht es, den Client in mehreren Sprachen anzubieten. Dieses Klasse wird auch vom Server importiert. (Ausführliche Beschreibung: Abschnitt 10.8, Seite 51) ServerMessage.java Die Klasse, welche die verschiedenen Formate der ServerMessages (Stings, Integers, Arrays, Vectors) definiert sowie alle ServerMessages als Referenz enthält um Programmierfehlern vorzubeugen. (Ausführliche Beschreibung: Abschnitt 10.7, Seite 50) Das Package beergame.client.images Dies ist ein Sub-Packge von beergame client und enthält die Bildressourcen für das Spiel. Seite 27/76

28 8.2 Das Spielkonzept Wie bereits erwähnt können die Applets aus Sicherheitsgründen untereinander nicht kommunizieren. Die Clients in der obigen Darstellung haben also keine direkte Verbindung untereinander. Um die verschiedenen Clients im Server unterscheiden zu können wird pro Client ein Send- und ein Listen- Thread erzeugt, welcher die Applets eindeutig identifiziert. Somit entsteht im Server eine virtuelle Abbildung der Clients, welche es den realen Cients ermöglicht quasi direkt miteinander zu kommunizieren. Wird eine Message einem Send Thread mittels der Methode addmsg übergeben, sendet dieser diese Message automatisch an seinen Client weiter. Umgekehrt, wenn der Listen Thread des Servers eine Message von seinem Client erhält, hängt dieser dessen Id an die Nachricht an. Danach wird die Message-Id angeschaut und die Message mit den Message-Parametern an die entsprechende Methode weitergeleitet, welche sich entweder im eigenen SendThread, in einem anderen SendThread oder direkt in der Klasse Game befindet. Eine Identifizierung des Clients im Server ist möglich, da pro Client-Server-Verbindung eine eigene Portnummer verwendet wird und somit jeder ListenThread nur Messages seines eigenen Clients erhält. Seite 28/76

29 9 Klassen des Package beergame.server 9.1 BeergameServer.java 13 Die Klasse BeergameServer ist die main( ) Klasse des Servers. Um den Server zu starten wird also diese Klasse aufgerufen. Sinnvollerweise sollte diese Klasse automatisch gestartet werden durch ein Bootscript auf dem jeweiligen hostenden Server. Als Argument kann die Anzahl zulässiger gleichzeitiger Verbindungen übergeben werden. Dies java classpath... beergame.server.bergameserver connections=50 entspricht genau der Anzahl Ports, welche im Server reserviert werden. Standardmässig ist 200 eingestellt. public class BeergameServer extends Thread { public final static int baseport = 8890; static Hashtable playerlist = new Hashtable(); static Hashtable gamelist = new Hashtable(); static boolean availableport[]; static int maxconnections = 200; private static boolean shutdown = false; private static int warningtime = 60; //minutes private static int socketnum ;... Als Basis Port ist 8890 eingestellt. Dies bedeutet, dass die erste Verbindung den Port 8890 zugeteilt bekommt, für jede weitere Verbindung wird ein Port höher oder ein freigewordener Port dazwischen verwendet. Der HelloThread, welcher für den Verbindungsaufbau zuständig ist, hört immer auf dem Basisport minus 1, in diesem Fall also auf Weiter verwaltet die Klasse BeergameServer zwei Hashtables und zwar eine für die Spieler- und eine für die Spielliste. Die Spielerliste enthält die Namen aller Spieler, die Online sind. Damit die Spieler und Spiele auch eindeutig identifiziert werden können, müssen die Namen jeweils eindeutig sein. Sobald ein Spieler sich aber abmeldet oder ein Spiel beendet wurde, steht der Name wieder zur Verfügung. Ein sauberer Shutdown kann vollzogen werden, indem im Verzeichnis, in dem sich auch das Package beergame.server befindet, ein (leeres) Textfile erzeugt oder abgelegt wird mit dem Namen shutdown.txt. Dies wird am besten automatisch durch den hostenden Server vollzogen durch einen Eintrag im Shutdown-script. Die Klasse BeergameServer prüft mittels eines Threads periodisch (jede Minute), ob sich ein File dieses Namens in dem oben erwähnten Verzeichnis befindet. Falls ja, wird allen Clients eine Meldung geschickt, dass der Server in einer bestimmten Zeit (=warningtime) abgeschaltet wird. Gleichzeitig werden keine neuen Verbindungen mehr akzeptiert. Standardmässig ist hier eine Stunde eingestellt. Diese Zeit sollte genügen, dass alle Spiele noch zu Ende gespielt werden können. 13 Diese Klasse wurde in Anlehnung an das Musterbeispiel des JBuilder programmiert. Vgl. JBuilder 5 Professional, Samples, Chess Seite 29/76