Sie sind auf Seite 1von 9

Bericht

Zum Projekt: My Awesome Go Game


Im Kurs: M1 Programming

Product Owner Entwicklungsteam ScrumMaster ScrumTeam Management Customer User Zeitraum I Zeitraum II

Manuel Bellersen Manuel Bellersen Manuel Bellersen Manuel Bellersen Manuel Bellersen Manuel Bellersen Manuel Bellersen 24.11.2011 21.12.2011 22.12.2011 25.01.2012

1-9

Inhaltsverzeichnis
Vision....................................................................................................................................................3 Product Backlog...................................................................................................................................4 Software Testing & Test Driven Development.....................................................................................5 Unit Tests.........................................................................................................................................5 Use of existing API ..............................................................................................................................6 Mono................................................................................................................................................6 OpenTK...........................................................................................................................................6 NUnit...............................................................................................................................................6 Benutzung........................................................................................................................................6 Agile Entwicklung................................................................................................................................7 Refactoring...........................................................................................................................................8 Source Code Management & Continous Integration............................................................................9 Sourcecode.......................................................................................................................................9

2-9

Vision
Das zu erstellende Projekt ist mit dem Titel My Awesome Go Game versehen, wodurch ein kleiner Ausblick auf den Inhalt des spteren Produktes entstehen soll. Als Ziel ist angedacht das Brettspiel Go in einer dreidimensionalen virtuellen Umgebung bereitzustellen, wo zwei Spieler im Hot Seat Verfahren gegeneinander antreten knnen. Es ist keine knstliche Intelligenz als Gegenspieler vorgesehen. Um verschiedene Regelwerke zu untersttzen, sind nur die folgenden Regeln zu implementieren: Das Spielbrett besitzt 19 horizontale mal 19 vertikale ( = 361) Linien, auf deren Schnittpunkte die Spielsteine gesetzt werden knnen. Die zwei Kontrahenten platzieren abwechselnd ihre Spielsteine auf die Kreuzungspunkte, wobei der eine Spieler die schwarzen und der andere Spieler die weien Spielsteine hat. Als alternative zum Setzen eines Steines kann ein Spieler auch Passen. Dadurch wird kein Stein gesetzt und der Gegenspieler darf seinen Satz vollziehen. Passen beide Spieler direkt hintereinander, so wird das Spiel beendet. Es existiert eine Gruppe von gleichfarbigen Steinen, wenn diese direkt horizontale und/oder vertikal miteinander verbunden sind. Freiheiten bezeichnet die Anzahl der freien Kreuzungspunkte, die direkt horizontal und vertikal an einem Stein bzw. einer Gruppe von Steinen zu finden sind. Wird durch das Setzten eines Steines die letzte Freiheit einer gegnerischen Gruppe genommen, so gilt diese Gruppe als gefangen und wird vom Feld genommen. Bei dem Setzten des eigenen Steines muss dieser oder eine direkt angrenzende eigene Gruppe mindestens eine Freiheit besitzen, damit dieser Stein gesetzt werden kann. Selbstmord ist nicht erlaubt. Die Gefangennahme wird vor der Analyse der Freiheiten gettigt. Dadurch kann ein Stein, der eigentlich keine Freiheiten htte, zu Freiheiten kommen.

Durch die Darstellung des Spieles in 3D soll der Blickwinkel auf das Spielbrett variable sein. Hauptschlich soll die einfach per Maus mglich sein. Zur Untersttzung der Spieler ist vorgesehen, dass die gefangen genommenen Steine gemerkt und textuell ausgegeben werden. Des Weiteren soll bei Beendigung des Spieles der aktuelle Brettaufbau und die gefangen genommenen Steine gespeichert werden, sodass dies fr andere Zwecke, wie zum Beispiel der Analyse des Spieles, genutzt werden kann. Es erfolgt keine Angabe darber, wer der Gewinner und wer der Verlierer ist. Das Projekt wird in der Programmiersprache C# erstellt. Durch die Nutzung der alternativen .Net Implementierung Mono wird eine grtmgliche Plattformunabhngigkeit gewhrleistet. Fr die dreidimensionale virtuelle Darstellung wird ber das OpenTK Framework auf OpenGL in der Version 3 zugegriffen. Als Entwicklungsumgebung steht ein Debian Linux System zur Verfgung, auf dem sich die zu benutzenden Technologien in aktuellen Versionen befinden. Bei der Sicherung des Quellcodes kommt Mercurial zum Einsatz. Fr die Qualittssicherung wird das UnittestFramework NUint eingesetzt.

3-9

Product Backlog
Als Spieler kann ich das Spiel einfach starten. Als Spieler finde ich das Spielfeld nach dem Start in einem leeren Zustand. Als erster Spieler habe ich die schwarzen Spielsteine. Als zweiter Spieler habe ich die weien Spielsteine. Als Spieler kann ich den Blickwinkel auf das Go-Brett verndern. Die Vernderung kann durch Bettigung des Mausrades und der Tasten 1,2,3 und Enter geschehen Als Spieler kann ich einen Spielstein auf einen freien Kreuzungspunkt setzen. Das Setzten erfolgt durch das Drcken der linken Maustaste. Das Spielbrett muss dabei in der Draufsicht (Taste 1 oder Enter) zu sehen sein. Als Spieler kann ich passen. Gepasst wird durch das Drcken der rechten Maustaste. Als Spieler kann ich nicht auf bereits besetzte Kreuzungspunkte oder neben das Brett Steine setzen. Als Spieler kann ich nicht aus Versehen Selbstmord begehen. Als Spieler kann ich die Anzahl der gefangenen Steine sehen. Das Spiel erkennt die gefangenen Steine. Das Spiel entfernt die gefangenen Steine. Das Spiel berechnet die gefangenen Steine. Als Spieler kann ich das Spiel beenden, indem ich, nachdem mein Gegner gepasst hat, ebenfalls passe. Als Spieler kann ich das Spiel einfach beenden. Als Spieler kann ich nach Beendigung des Spieles in den letzten Brettaufbau und die Zahl der jeweiligen Gefangenen Einsicht nehmen. 5 6 1 7 7 4 3 1 3 2 5 1 1 2 2 4

4-9

Software Testing & Test Driven Development


Es wurde in diesem Projekt keine testgetriebene Entwicklung vollzogen. Stattdessen kamen die Softwaretests in Form von BlackBox-Test zur Anwendung. Bei einem BlackBox-Test kennt man im Allgemeinen nicht den genauen Inhalt der Methoden die man teste. Stattdessen versucht man die Auswirkungen von Aufrufen mit vorausgesagten Daten zu vergleichen und zu validieren. In diesem Fall wurden Tests in Form von Unit-Tests geschrieben, die die Erstellung von Objekten, sowie deren Vernderungen mittels Aufrufe von Methoden berprften. Als Beispiel sei folgende Klasse gegeben:
public class Foo{ public int i = 0; public void Foo(){} public void setI( int val){ i = val;} }

In dieser Klasse lassen sich drei Dinge testen: die Konstruktion von Foo, die Variable i und die Methode setI. Dafr knnte folgender Testfall angelegt werden:
[TestFixture()] public class TestCases{ [Test()] public void testFoo(){ Foo f = new Foo(); Assert.NotNull( f); Assert.AreEqual( f.i, 0); f.setI( 42); Assert.AreEqual( f.i, 42); } }

Der erste Teil des Tests berprft die Erstellung von Foo. Der Assert-Aufruf nimmt an, dass f nicht null ist und die Konstruktion von Foo entsprechend erfolgreich war. Wrde bei der Erstellung ein Fehler auftreten, kme es zu einer Fehlermeldung und der Test wrde fehlschlagen. Die Nachfolgenden Anweisungen und berprfungen werden dann nicht mehr ausgefhrt. Die zweite berprfung untersucht, ob i von f nach der Konstruktion auch wirklich 0 ist. Anschlieend wird i von f durch den Methodenaufruf auf 42 gesetzt. Diese Methode lsst sich kaum direkt berprfen, da sie keinen Rckgabewert hat. Durch die Mglichkeit des direkten Zugriffs auf i von f kann allerdings jetzt doch die Wirkung der Methode berprft werden. Dies geschieht im dritten Teil. Sollte es passieren, dass bei einem Aufruf eine Exception geworfen wird, oder eine Annahme nicht eintrifft, dann endet der Test und wird als nicht Bestanden markiert. Die vorliegenden Unit-Tests werden alle erwartungsgem erfolgreich ausgefhrt.

Unit Tests
Die Unit-Tests dieses Projektes befinden sich in der folgenden Datei: unitTest.cs http://code.google.com/p/manuel-bellersen/source/browse/two-csharp/two-csharp/unitTest.cs? repo=master-programming

5-9

Use of existing API


Mono
Mono is a software platform designed to allow developers to easily create cross platform applications. It is an open source implementation of Microsoft's .Net Framework based on the ECMA standards for C# and the Common Language Runtime. We feel that by embracing a successful, standardized software platform, we can lower the barriers to producing great applications for Linux. ( http://mono-project.com/What_is_Mono)

OpenTK
The Open Toolkit is an advanced, low-level C# library that wraps OpenGL, OpenCL and OpenAL. It is suitable for games, scientific applications and any other project that requires 3d graphics, audio or compute functionality. ( http://www.opentk.com/)

NUnit
NUnit is a unit-testing framework for all .Net languages. Initially ported from JUnit, the current production release, version 2.6, is the seventh major release of this xUnit based unit testing tool for Microsoft .NET. It is written entirely in C# and has been completely redesigned to take advantage of many .NET language features, for example custom attributes and other reflection related capabilities. NUnit brings xUnit to all .NET languages. ( http://www.nunit.org/)

Benutzung
Die Benutzung von Frameworks ist denkbar einfach. Dies soll hier an Hand eines Beispiels verdeutlicht werden. Dazu wird MonoDevelop in der Version 2.8.6 in deutscher Sprache verwendet. In der Projektmappe findet man das aktuelle Projekt. Standardmig existiert ein Ordner Namens Verweise. Darin sind Verweise auf Pakete von Frameworks zu finden, die man in seinem Projekt benutzen will. Per Rechtsklick auf Verweise und der Auswahl Verweise bearbeiten ffnet sich ein Dialog, mit Hilfe dessen man gesetzte Verweise entfernen und bentigte Verweise setzten kann. Es gibt vier Tabs, durch die man auf die Paketverweise unterschiedlich zugreifen kann. Unter dem Tab Alles lassen sich zum Beispiel die Verweise auf die Pakete nunit.framework, System und System.Drawing finden, die fr dieses Projekt ntig sind. Der Verweis auf das OpenTK Framework befindet sich nicht in dieser Liste und muss per Hand hinzugefgt werden. Dazu geht man in den vierten Tab .NET Assembly. Nun sucht man sich die entsprechende Framework-Datei. Von der Webseite von OpenTK erhlt man eine ZIP-Datei. Entpackt man die, und folgt dem Pfad opentk/Binaries/OpenTK/Release/, findet man die Datei OpenTK.dll. Diese markiert man und fgt sie mit einem Klick auf Hinzufgen zu den ausgewhlten Verweisen hinzu. Nun kann man die ausgewhlten Frameworks benutzen. In der Datei, in der das Framework genutzt werden soll, setzt man am Anfang der Datei eine usingDirektive, wie zum Beispiel using NUnit.Framework;. Damit wei der Compiler, dass nachfolgend dieses Framework mit eingebunden und zur Verfgung gestellt werden soll. Nun geht es an den Code. Die Klasse, in der die Tests ablaufen, wird durch folgenden Vorsatz gekennzeichnet: [TestFixture()] . Die einzelnen Testmethoden werden mit dem Vorsatz: [Test()] markiert. Innerhalb der Methoden kommt die Klasse Assert zur Anwendung. 6-9

Jedes Framework bietet eigene Klassen und Funktionsweisen. Genauere Beschreibungen zur Anwendung dieser erhlt man in der Regel aus deren Dokumentationen, die man sich, vor Benutzung, zu Gemte fhren solle.

Agile Entwicklung
In diesem Projekt kam die Agile Softwareentwicklung in Form von Scrum zur Anwendung. Beim Scrum steht zu Anfangs eine Vision, die das Endprodukt beschreibt. Die Beschreibung ist aus Sicht des spteren Product Owner. In diesem Fall fallen alle im Scrum ttigen Personen und Personengruppe auf eine Person, nmlich mich, zusammen. Aus der Vision lsst sich ein initialer Product Backlog erstellen, der ber die Entwicklung hinweg erweitert werden kann. Im Product Backlog stehen viele kleine User Stories. Diese werden in der Form des spteren Benutzers der Anwendung verfasst. Eine User Story sollte dabei so klein und przise wie mglich gehalten sein, sodass diese einfach bzw. schnell implementiert werden kann. Eine Gruppe von User Stories, welche nach verschiedenen Kriterien ausgewhlt werden, wird als Sprint Backlog zusammen gefasst und in einem Sprint verarbeitet. Am Ende des Sprints soll eine funktionierende Anwendung stehen. ber einen lngeren Zeitraum erfolgen mehrere Sprints, im Prinzip bis keine User Stories mehr vorhanden sind. Die Vision und das Product Backlog mit den einzelnen User Stories zu dem Projekt, welches dieser Bericht beschreibt, befindet sich im Anfang dieses Dokumentes. Die Entwicklung der in diesem Bericht erwhnten Anwendung erfolgte in zwei Sprints. Diese verliefen vom 24.11.2011 bis zum 21.12.2011 und vom 22.12.2011 bis zum 25.01.2012. Dabei wurden alle oben erwhnten User Stories verarbeitet.

7-9

Refactoring
Refactoring bezeichnet in der Software-Entwicklung die manuelle oder automatisierte Strukturverbesserung von Programm-Quelltexten unter Beibehaltung des beobachtbaren ProgrammVerhaltens. Dabei sollen die Lesbarkeit, Verstndlichkeit, Wartbarkeit und Erweiterbarkeit verbessert werden, mit dem Ziel, den jeweiligen Aufwand fr Fehleranalyse und funktionale Erweiterungen deutlich zu senken. ( http://de.wikipedia.org/wiki/Refactoring) Whrend der Entwicklung von Software kommt es hufig zu Refactoring. Beispiel: Verschiebung eines Attributes public class Foo{ public class Foo{ public int bar(){ private const int m_i = 42; const int i = 42; public int bar(){ return i; return m_i; } } } } In diesem Beispiel wird die Variable i aus der Methode heraus operiert und zu einem konstanten statischen Attribut der Klasse gemacht. Dadurch muss nicht bei jedem Aufruf der Methode die Variable neu angelegt werden, sondern befindet sich einmalig einheitlich an einem Platz. Dies verringert die Laufzeit und den Speicherverbraucht. Beispiel: Umbenennung einer Klasse und eines Attributes public class Foo{ public class Math{ public const double m_a = 3.14159; public const int Pi = 3.14159; } } Jegliche Art von Namen von Attributen, Methoden, Klassen, Variablen usw. sollten selbsterklrend sein. Im ersten Fall des Beispiels ist dies nicht der Fall. Unter dem Name m_d des Attributes kann sich im Normalfall keiner etwas vorstellen. Auch ist der Klassenname Foo ohne Aussage. Durch die Umbenennung von beiden ist sowohl die Klasse, als auch das Attribut leicht verstndlich. Beispiel: Extraktion einer Methode public class Foo{ public void f(){ int a = 1, b = 2, c = 3; double ab = (double)a/(double)b; double d = Math.Pow( ab, (double)c); } public void g(){ int a = 1, b = 3, c = 2; double ab = (double)a/(double)b; double d = Math.Pow( ab, (double)c); } } public class Foo{ private double divPow( int a, int b, int c){ double ab = (double)a/(double)b; return Math.Pow( ab, (double)c); } public void f(){ int a = 1, b = 2, c = 3; double d = divPow( a, b, c); } public void g(){ int a = 1, b = 3, c = 2; double d = divPow( a, b, c); } } 8-9

In einigen Fllen bietet es sich an, bestimmte Anweisungen in eigene Methoden zu kapseln. Hier in diesem Beispiel wird die Division und die Potenzierung in eine eigene Methode gepackt. Dadurch werden zweierlei Verbesserungen erreicht. Die entstandene Methode kann an anderen Stellen wiederverwendet werden. Dies ist hier in f und g geschehen. Der Code wird krzer und besser lesbar. Neben dieser Verbesserung wird auerdem eine leichtere Wartbarkeit erreicht. Sollte sich etwas in der Berechnung verndern, dann muss dies nicht in f und in g, wie im linken Feld, geschehen, sondern es reicht die nderung der neuen Methode im rechten Feld. MonoDevelop bietet fr das Refactoring Untersttzung an. Ttigt man einen Rechtsklick auf eine Variable oder Methode, wird zum Beispiel im ersten Punkt Refactoring das Umbenennen angeboten. Unter anderem existieren ebenso Optionen fr: temporre Variable integrieren Methode extrahieren lokale Variable deklarieren Methode erstellen Feld kapseln Member implementieren/berschreiben Konstant einfhren

Source Code Management & Continous Integration


Als Versionsverwaltung kam das dezentrale System Mercurial zum Einsatz. Das entsprechende Repository kann hier gefunden werden: http://code.google.com/p/manuel-bellersen/source/browse/two-csharp?repo=master-programming Hauptschlich diente dieses System diesem Projekt zur Protokollierung von nderungspaketen, sowie der Archivierung dieser nderungen. Damit einher geht auch die Mglichkeit der Wiederherstellung frherer Zeitpunkte, was besonders bei fehlgeschlagenen Experimenten im Sourceode gnstig ist. Der gemeinsame Zugriff und die gemeinsame Bearbeitung des Projektes war in diesem Projekt nicht gegeben, da nur ein Entwickler an der Entwicklung beteiligt gewesen ist. Die Mglichkeit Branches, also Entwicklerzweige, anzulegen, wurde nicht genutzt. Bei der kontinuierlichen Integration soll jeder Entwickler seine nderungen frhzeitig in die Versionsverwaltung einchecken. Anschlieend wird das Gesamtsystem neu gebaut und getestet. Falls es zu Integrationsproblemen kommt, wird der entsprechende Entwickler informiert, sodass dieser sich um die Beseitigung der Fehler kmmern kann. Fr dieses kleine Projekt wurde kein extra Build-Server eingerichtet. Das Neubauen und Testen des Gesamtsystems geschah, um die Lauffhigkeit der Anwendung sicher zu stellen, immer vor dem Einchecken des Codes. Der Checkout jeder Revision enthlt somit immer den Sourcecode einer lauffhigen Anwendung.

Sourcecode
Der Sourcecode zu diesem Projekt ist unter folgender URL zu erreichen: http://code.google.com/p/manuel-bellersen/source/browse/two-csharp?repo=master-programming

9-9