Game of Life. Aufgabenstellung zur Hausarbeit Softwaretechnologie: Java I im Fach Informationsverarbeitung Wintersemester 2008/2009

Transkript

1 Game of Life Aufgabenstellung zur Hausarbeit Softwaretechnologie: Java I im Fach Informationsverarbeitung Wintersemester 2008/2009 Stephan Schwiebert Jürgen Hermes

2 Inhaltsverzeichnis Allgemeine Informationen...2 Game of Life...2 Implementation...3 Dateiformate... 3 Inversion of Control und die graphische Benutzeroberfläche... 4 Vorschlag zur Vorgehensweise...5 Rückmeldung...6 Design... 6 Dokumentation... 6 API Docs...6 Externe Dokumentation... 7 Abgabe...7 Noch Fragen?...7 1

3 Allgemeine Informationen Die Hausarbeit besteht aus 3 Teilbereichen: 1.) Implementation des Programms gemäß den Anforderungen dieser Beschreibung, Abgabe auf CD. 2.) Interne Dokumentation aller Klassen, Attribute und Methoden mit JavaDoc - Evtl. zusätzlich notwendige Dokumentation innerhalb von Methodenkörpern 3.) Externe Dokumentation ausgedruckt, der Form einer wissenschaftlichen Arbeit entsprechend (siehe Webseite). Kennzeichnen Sie CD und Dokumentation mit Ihrem Namen, Ihrer Matrikelnummer sowie Ihrer -adresse. Das Programm kann sich an den Vorschlägen in diesem Dokument orientieren, Sie können jedoch auch eine völlig unabhängige, eigene Lösung programmieren. In diesem Fall sollten sie jedoch bei der Dokumentation besonders sorgfältig sein und Abweichungen zu den Vorschlägen begründen, zudem müssen die Anforderungen, die an das Programm gestellt werden, erfüllt werden. Gruppenarbeit ist möglich, allerdings mit maximal 2 Teilnehmern und lediglich bei der Programmierung, nicht bei der internen und externen Dokumentation. Sie sollten mit dieser Arbeit beweisen, dass Sie der Sprache Java mächtig sind und in der Lage sind, Anforderungen wie die hier gestellten zu erfüllen. Sollte dies nicht möglich sein, weil Ihre Arbeit der eines/r Kommilitonen/in zu sehr ähnelt, werden Sie (beide) zu einer mündlichen Prüfung geladen, in der Sie Ihr Programm erläutern müssen. Game of Life Das Spiel des Lebens ist eine Simulation einer einfachen, zweidimensionalen (und unendlich großen) Welt, die von einfachen Lebensformen bevölkert wird. Diese Lebensformen kennen lediglich zwei Zustände lebendig oder tot zwischen denen sie im Laufe der Zeit, und unter Berücksichtigung verschiedener Regeln, wechseln können. Ausgehend von einer zufälligen Population auf dem Spielfeld lassen sich mit Hilfe von vier Regeln zukünftige Populationen berechnen: Hat ein Lebewesen zwei oder drei Nachbarn, so lebt es weiter. Hat es weniger als zwei Nachbarn, stirbt es an Einsamkeit. Hat es mehr als drei Nachbarn, verhungert es. Hat ein unbelebtes Feld genau drei lebende Nachbarn, so wird dort ein neues Lebewesen geboren. Das ursprüngliche Game of Life mit den oben genannten Regeln wurde 1970 von J. Conway entworfen sein Ziel (das er auch erreichte) war es, eine von John von Neumann entworfene, hypothetische Maschine, die sich selbst reproduzieren konnte, zu 2

4 vereinfachen. Unter anderem lässt sich das Game of Life auch als universelle Turingmaschine betrachten, mit der sich jeder Algorithmus lösen lässt. Es beschreibt einen zellulären Automaten, d.h. einen Automaten, bei dem sich der Zustand einer Zelle zu einem Zeitpunkt t aus dem Zustand der Nachbarzellen (und dem der Zelle selbst) zum Zeitpunkt t-1 ergibt. (Quelle: en.wikipedia.org) Implementation Ihre Aufgabe ist es, die fehlende Funktionalität des Programms zu implementieren. Dazu gehört im Wesentlichen: Spielbretter laden, zufällige Population generieren, Population laden und Population speichern. Die konkreten Anforderungen ergeben sich dabei aus den zu implementierenden Interfaces Population, Universe, LifeForm und LifeIO sowie aus den abstrakten Methoden der Klasse AbstractLifeRuntime. Dateiformate Ein Spielbrett entspricht einem Universum im Game of Life neben der Größe und Aussehen des Spielbretts und dem Aussehen der Individuen sind dort auch die Bedingungen, unter denen Lebensformen leben, sterben und geboren werden, festgelegt. Eine Spielbrett-Datei sieht aus wie folgt: rows: 50 columns: 50 min-neighbours: 2 max-neighbours: 3 min-birth: 3 max-birth: 3 background-image: images/space.gif icon-born: images/star-born.png icon-child: images/star-child.png icon-adult: images/star-adult.png icon-dead: images/star-dead.png Eine Population ist ein spielbrett-unabhängiger Schnappschuß einer Bevölkerung. Sie enthält eine Beschreibung, Angaben zur idealen Größe eines Spielbretts und die Angaben darüber, welche Zellen belebt oder unbelebt sind: 3

5 Glider-Rennen rows: 30 columns: 40 OXOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO OOXOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOXOO XXXOOOOOXOOOOOOOOOOOOOOOOOOOOOOOOOOOXOOO OOOOOOOOOXOOOOOOOOOOOOOOOOOOOOOOOOOOXXXO OOOOOOOXXXOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO... Die Struktur der Dateien ist fest definiert, so dass das Einlesen von Dateien erleichtert wird: Einzelne Elemente werden durch Zeilenumbruch markiert, die Reihenfolge der Elemente ist vorgeschrieben (siehe Dateibeispiele oben), und zur Trennung von Bezeichnung und Wert wird stets die Zeichenfolge Doppelpunkt-Leerzeichen verwendet. Populations-Dateien enthalten in den Zeilen, die der columns-angabe folgen, die eigentlichen Populationsdaten: Jede Zeile der Datei entspricht einer Zeile in der Matrix. Das Zeichen X ist als belebt zu interpretieren, während das Zeichen O unbelebte Zellen markiert. Die Anzahl der Zeilen und die Anzahl der Buchstaben pro Zeile muss dabei den Werten, die als rows bzw. columns definiert wurden, entsprechen. Inversion of Control und die graphische Benutzeroberfläche In diesem Kapitel soll erläutert werden, wie die Benutzeroberfläche des Telefons mit Ihrem Programm interagieren kann. Dies geschieht letztlich über die Methoden der Klasse LifeMenu, aber da die Reihenfolge der Methodenaufrufe in diesem Interface nicht ersichtlich ist (und auch nicht sein kann), soll hier das Konzept zunächst einmal vorgestellt werden. Bisher haben Sie meist Programme geschrieben, in denen von Ihrer main-methode ausgehend ein Programm abgearbeitet wurde. Dies ist jedoch für Programme, die mit dem Benutzer interagieren, nicht immer möglich, da unklar ist, was der Benutzer als nächstes machen wird, und es ineffizient wäre, bspw. in einer Schleife auf Benutzereingaben zu warten, da dadurch das komplette Programm blockiert würde. Um dieses Problem zu lösen, werden Benutzereingaben in Java, wie bspw. die Betätigung eines Buttons, als Nachrichten verschickt, die von speziellen Empfängern interpretiert werden. In der Hausarbeit wird dieses Konzept benutzt, jedoch müssen Sie sich um die Details des Versenden und Empfangen nicht weiter kümmern, da dies bereits implementiert ist. Wird bspw. das Menu Spielbrett laden aufgerufen, so wird dieses Ereignis innerhalb der GUI abgefangen und durch den Aufruf einer Methode aus Ihrem Programm weitergeleitet - Ihrem Programm wird sozusagen in einigen Bereichen die Kontrolle entzogen, und es 4

6 muss nicht mehr selbst aktiv werden, sondern auf Anregung von außen nur noch reagieren. Dieses Prinzip, auch als Hollywood-Prinzip bezeichnet ( don't call us, we call you ), nennt sich Inversion of Control. Ein Nachteil des Inversion of Control-Prinzips sind die Stacktrace-Ausgaben, falls ein Fehler auftritt, denn diese beginnen nun in einer Ihnen unbekannten Klasse. Sie können jedoch die Methoden, die nicht von Ihnen stammen, mehr oder weniger ignorieren. Die folgende Tabelle zeigt, welche Methoden von LifeIO und AbstractLifeRuntime bei welcher Aktion (und in welcher Reihenfolge) aufgerufen werden. Aktion Spielbrett laden Population laden Population speichern Zufällige Population Nächste Generation/Start Mausklick auf Lebewesen Beteiligte Methoden LifeIO.loadUniverse() AbstractLifeRuntime.setBoard() LifeIO.loadPopulation() AbstractLifeRuntime.setPopulation() AbstractLifeRuntime.getCurrentGeneration() AbstractLifeRuntime.getCurrentGeneration() LifeIO.storePopulation() AbstractLifeRuntime.createRandomPopulation() AbstractLifeRuntime.getCurrentGeneration() AbstractLifeRuntime.createNewGeneration() AbstractLifeRuntime.getCurrentGeneration() AbstractLifeRuntime.addAnimalAt() oder AbstractLifeRuntime.removeAnimalAt() Vorschlag zur Vorgehensweise Implementieren Sie zunächst die Daten -Interfaces LifeForm, Population und Universe. Anschließend implementieren Sie die Methode, die für das Laden von Spielbrettern verantwortlich ist, sowie entweder die Methode zum Laden von Populationen, oder die Methode zum Erzeugen einer Zufallspopulation. Wenn Sie dies geschafft haben, steht die Basis Ihres Programms, die Sie nun schrittweise um neue Funktionen erweitern können. Grundsätzlich gilt: Überlegen Sie, wie Sie ein Problem lösen können, ruhig auch ohne Computer, sondern mit Zettel und Stift. Versuchen Sie, ein Problem zunächst grob zu umschreiben und versuchen Sie dann, einzelne Teilprobleme darin ausfindig zu machen. Wie lässt sich bspw. für eine einzelne Zelle auf dem Spielfeld berechnen, wie der nächste Zustand sein wird? Was, wenn diese Zelle am Rand des Spielfelds liegt? Unterscheidet sich das Vorgehen, wenn sie belebt/unbelebt ist? Dann können Sie diese Strategie rekursiv auf die Teilprobleme anwenden, bis Sie schließlich feststellen, dass Sie nur eine relativ große Menge von einfachen Problemen lösen müssen. Eventuell ist auch ein Blick in den Wikipedia-Artikel zu Conways Spiel des Lebens ( 5

7 de.wikipedia.org/wiki/conways_spiel_des_lebens) hilfreich der Artikel enthält zahlreiche Abbildungen, die anhand der ursprünglichen Regeln des Spiels erklären, wann ein Lebewesen stirbt oder geboren wird. Rückmeldung Um zu prüfen, ob Ihre Implementation korrekt arbeitet, bietet es sich an, die Ausgabe mit der Ausgabe der Referenz-Implementation zu vergleichen. So ist beispielsweise die Kombination aus Weltall -Spielfeld und Gun -Population sehr gut dazu geeignet, Ihr Programm zu testen. Um zu prüfen, ob es auch mit abweichenden Regeln funktioniert, bietet sich bspw. die Kombination aus Wiese und Hypnose an. Design Vermeiden Sie lange Methoden, oder wiederkehrende, identische Codeabschnitte in Methoden! Wird eine Methode zu lang, so ist sie nicht mehr gut lesbar, und Fehler lassen sich nur schwer finden. Prüfen Sie in diesem Fall, ob sie die Methode in mehrere kleinere Methoden zerschlagen können. Wenn Sie feststellen, dass ein Codeabschnitt mehr als einmal verwendet wird, sollten Sie ihn lieber in einer eigenen Methode implementieren, und diese Methode mehrmals aufrufen. Dokumentation API Docs Die relevanten Klassen der Vorlage sind mit Javadoc kommentiert. Öffnen Sie die Datei index.html im Verzeichnis doc (ziehen Sie sie in einen Browser oder wählen Sie den Punkt Open With->System Editor im Kontextmenu), um zur Übersicht über die Klassen im Projekt zu gelangen. Sie müssen die von Ihnen angelegten Klassen ebenfalls dokumentieren. Evtl. ist es jedoch nicht notwendig, wirklich jede einzelne Methode zu kommentieren beachten Sie jedoch folgende Anforderungen: jede Methode und jede Variable, die nicht als private markiert ist, muss dokumentiert werden, inkl. der Parameter Rückgabewerte oder Exceptions Methoden mit geringerer Sichtbarkeit müssen dokumentiert werden, wenn sich die Funktionalität nicht ohne weiteres erschließt, oder wenn bestimmte Anforderungen an die Parameter gestellt werden (X darf nicht null sein, String darf keine Leerzeichen enthalten o.ä.). Dies bedeutet umgekehrt, dass Sie umso weniger kommentieren müssen, je mehr Methoden und Variablen Sie private deklarieren, und je besser Sie die Namen der Methoden/Variablen wählen. String s muss in jedem Fall dokumentiert werden, String currentline nicht unbedingt. Um die Kommentare als Java API Docs zu exportieren, wählen Sie den Punkt Export im Kontextmenu des Package Explorers, nachdem Sie das Projekt aktiviert haben. Dort können Sie Java->Javadoc auswählen und auf der nächsten Seite einige Einstellungen vornehmen. Evtl. müssen Sie zunächst das Programm javadoc auswählen, das sich 6

8 (unter Windows) i.d.r. In C:/Programme/Java/JDK /bin verbirgt. Zusätzlich sollten Sie die Sichtbarkeit auf protected oder private setzen, damit auch solche Methoden & Attribute in der Dokumentation auftauchen. Externe Dokumentation Die externe Dokumentation soll dazu dienen, Ihre Lösungsstrategie zu erläutern und das Zusammenspiel der von Ihnen implementierten Klassen zu erklären sowie Probleme, Alternativen und Verbesserungsmöglichkeiten zu diskutieren. UML-Klassen- oder Sequenzdiagramme sind dabei hilfreich, jedoch nicht erforderlich. Der Umfang der Dokumentation soll in etwa 3-5 Seiten (zusätzlich Deckblatt, Inhaltsverzeichnis und ggf. Literaturangaben) betragen, bei deren Formatierung die Anleitung unter verbindlich ist. Dokumentationen, die es nicht ermöglichen, Kommentare einzufügen (Ränder zu schmal, kein 1,5-facher Zeilenabstand), werden nicht akzeptiert! Abgabe Die Arbeit muss bis spätestens Donnerstag, , 12 Uhr in der Sprachlichen Informationsverarbeitung abgegeben werden. Achtung: Um sichergehen zu können, dass Sie nicht vor verschlossenen Türen stehen, sollten Sie zur Abgabe nur zu den Geschäftszeiten kommen! Daher auch die Zeitangabe beim spätesten Abgabetermin die Geschäftszeiten während der Semesterferien finden Sie auch auf der Webseite des Instituts. Das Programm muss in einem lauffähigen Zustand vorliegen, d.h. es muss a) ausführbar sein und b) die gestellten Anforderungen weitestgehend erfüllen, andernfalls gilt die Arbeit als nicht bestanden. Sollten einige der weniger relevanten Anforderungen nicht erfüllt sein, so werden Sie (per ! Bitte auf dem Deckblatt der Dokumentation angeben) aufgefordert, die entsprechenden Punkte nachzubessern. Noch Fragen? Sollte Ihnen etwas unklar sein, oder sollten Sie an einer Stelle nicht weiterkommen, wenden Sie sich bitte per Mail an oder 7