SOFTWARETECHNIK WISE 2018/2019 - UMSETZUNG EINES QWIRKLE-SPIELS
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Softwaretechnik WiSe 2018/2019
Umsetzung eines Qwirkle-Spiels
Product Vision & Vorgaben
Auftraggeber
Eric Bodden, Johannes Geismann, Stefan Krüger, Manuel Benz
Fachgruppe Softwaretechnik, Heinz Nixdorf Institut
Fakultät für Elektrotechnik, Informatik und Mathematik
Universität Paderborn, Fürstenallee 11, 33102 Paderborn
Version 1.0.0
Paderborn, den 9. Oktober 2018Changelog
Inhaltsverzeichnis
Inhaltsverzeichnis
1 Product Vision 1
1.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Nutzergruppen und Funktionalität . . . . . . . . . . . . . . . . . . . . . . . 1
1.2.1 Beobachter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2.2 Spieler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2.3 Ausrichter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Spielregeln . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Organisatorische & Technische Vorgaben 4
2.1 Deliverables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Ablauf des Praktikums . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3 Protokoll-Komitee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4 Praktikumsturnier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.5 Technologien und Entwicklungswerkzeuge . . . . . . . . . . . . . . . . . . 7
II1 Product Vision
1 Product Vision
1.1 Einleitung
Wir, die FG Softwaretechnik beauftragen Sie mit der Entwicklung eines Qwirkle-Spiels, wel-
ches als Software unter Mac OS X, Ubuntu, Windows und Android (Version 5.0.1 und höher)
lauffähig ist.
Dieses Dokument beschreibt unsere Wünsche an das zu entwickelnde Produkt und den Pro-
jektablauf.
1.2 Nutzergruppen und Funktionalität
In diesem Kapitel wird die gewünschte Funktionalität aus Benutzersicht beschrieben. Unter-
schieden wird zwischen Beobachtern, Spielern und Ausrichtern.
1.2.1 Beobachter
Beobachter nutzen einen Beobachter-Client, der sowohl für PC- als auch für Android-Geräte
verfügbar ist. Mit diesem Client melden sich Beobachter an einem Spielserver an, der sich
sowohl im lokalen Netzwerk (LAN) als auch im Internet befinden kann. Auf einem Spielserver
können sich eine unbegrenzte Anzahl von Beobachtern anmelden. Nach erfolgter Anmeldung
befinden sich Beobachter zunächst in einer Lobby. Dort können sie übersichtlich erkennen,
welche Spiele gerade laufen, in Kürze starten und vor Kurzem beendet wurden. Aus dieser
Übersicht heraus können Beobachter jedes der dort gelisteten Spiele betreten, um das Spiel in
Echtzeit nachzuverfolgen. Sämtliche für das Spiel relevanten Aspekte sind sinnvoll erkennbar.
Dazu gehören u.a. die verbleibende Bedenkzeit der Spieler, die bisher gespielten Steine, Art
und Anzahl der Steine auf dem Stapel, und sämtliche Spielsteine auf den Händen aller aktiven
Spieler. Bei Spielende werden die Beobachter über das Ergebnis des Spiels benachrichtigt.
Beobachter haben keine Möglichkeit, das Spiel zu beeinflussen.
1.2.2 Spieler
Spieler können menschliche Spieler und nichtmenschliche Spieler sein.
Menschliche Spieler nutzen einen Teilnehmer-Client, der auf Android-Smartphones oder Desktop-
Computern (Windows, Mac OS X, Ubuntu) lauffähig ist. Mit diesem Client melden sich
menschliche Spieler analog wie die Beobachter am Spielserver an. Nach erfolgter Anmeldung
sehen sie, genau wie die Beobachter, die gerade laufenden Spiele, die in Kürze startenden
Spiele und die vor Kurzem beendeten Spiele. Sie können einem Spiel als Beobachter beitreten
oder einem noch nicht gestarteten Spiel als Teilnehmer beitreten. Alternativ können sie auch
vom Spielserver einem Spiel als Teilnehmer zugeordnet werden. Wenn menschliche Spieler
einem Spiel als Teilnehmer angehören, können sie Spielzüge ausführen.
11 Product Vision
Nichtmenschliche Spieler sind Programme, die anstelle eines menschlichen Spielers Spielzü-
ge berechnen und ausführen. Ein solches Programm heißt Engine-Teilnehmer. Engine-Teil-
nehmer können auf dem PC via Kommandozeile gestartet werden (z.B. durch Aufruf einer
Jar-Datei) und funktionieren ohne grafische Oberfläche. Beim Aufruf wird die IP-Adresse und
der Port des Servers mitgeteilt, bei dem sich angemeldet werden soll. Der Engine-Teilnehmer
enthält einen Algorithmus, der den nächsten Spielzug berechnet und dem Spielserver mitteilt.
Nur wenn ein Teilnehmer in einem Spiel am Zug ist, kann dieser einen gültigen Zug ausfüh-
ren. Der Spielserver stellt sicher, dass Teilnehmer nur die eigenen Spielsteine und die bereits
gespielten Steine sehen können. Spielsteine der gegnerischen Spieler und die des Stapels sind
nicht erlaubt einzusehen. Darüber hinaus prüft er auch, ob der Zug des Spielers den Spielregeln
entspricht. Die Konsequenz eines ungültigen Zugs ist konfigurierbar. Alle Spieler werden vom
Server über jede gültige Spielaktion informiert. Ferner teilt der Spielserver bei jeder punkt-
bringenden Aktion und auch auf Nachfrage durch Clients den aktuellen Punktestand mit. Der
Spieleserver erkennt auch das Spielende, führt dann die endgültige Punktberechnung durch,
legt das Ergebnis fest und teilt die Beendingung des Spiels und das Ergebnis den betreffenden
Clients mit.
Spieler haben eine festgelegte Bedenkzeit zur Ausführung eines Spielzugs. Die Bedenkzeit
eines Spielers beginnt abzulaufen sobald der Spieler am Zug ist. Die Bedenkzeit wird pro
Spiel am Server festgelegt und ist für alle Teilnehmer gleich. Überschreitet ein Spieler seine
Bedenkzeit, hat er verloren. Die Kontrolle der Bedenkzeit obliegt dem Server. Clients erfahren
auf Nachfrage die ihnen verbleibende Bedenkzeit vom Server.
1.2.3 Ausrichter
Ausrichter starten, konfigurieren und bedienen den Spielserver. Folgende Parameter können
Ausrichter am Spielserver mindestens konfigurieren:
• Die Anzahl der Farben u. Symbole (Muss der gleiche Wert sein)
• Die Häufigkeit je Spielstein (Ein Wert für alle Steine)
• Die Bedenkzeit für jeden Spieler pro Spielzug
• Die Zeit für Visualisierung
• Die Konsequenzen für einen regelwidrigen Spielzug. Zur Auswahl stehen: Nichts, Punkt-
abzug, Auschluss vom Spiel (Kick).
Eine einmalig erstellte Spiel-Konfiguration ist wiederverwendbar. Hierzu kann die Konfigura-
tion in einem vom Protokoll-Komitee definierten Format gespeichert werden. Der Ausrichter
kann eine Konfiguration in einer Datei speichern und bei Bedarf aus einer Datei laden. Der
Ausrichter kann jedes Spiel unabhängig von den anderen Spielen konfigurieren. Zum Erstel-
len, Laden und Speichern von Konfigurationen nutzt der Ausrichter eine grafische Oberfläche,
die vom Spieleserver bereitgestellt wird. Nachdem der Ausrichter den Spielserver gestartet
hat, können sich andere Nutzer als Teilnehmer oder Beobachter mit ihren Clients anmelden.
21 Product Vision
Aus der Liste angemeldeter Teilnehmer kann der Ausrichter die Teilnehmer für verschiedene
Spiele auswählen. Der Ausrichter kann entweder selbst oder durch fairen Zufall festlegen, in
welcher Reihenfolge die Teilnehmer ziehen und welcher Teilnehmer zuerst am Zug ist.
Der Ausrichter kann ein Spiel starten, pausieren, fortsetzen und abbrechen. Bei Abbruch des
Spiels entscheidet der Ausrichter über die Wertung des Spiels.
Zur Verwaltung von Turnieren kann der Ausrichter eine Menge von nacheinander auszufüh-
renden Spielen planen und ausführen. Um den Überblick während eines Turniers zu wahren,
zeigt die Oberfläche des Spielservers die Ergebnisse der abgelaufenen Spiele und die aktuelle
Rangfolge der Spieler an.
1.3 Spielregeln
Die Regeln des Spiels sind hier zu finden. Es gibt jedoch folgende Änderungen:
• Die Spielsteine werden von einem zufällig gemischten, verdeckten Stapel gezogen. Der
Stapel wird zu Spielbeginn durch den Server gemischt. Um neue Steine zu ziehen, kön-
nen Spieler eine Anzahl von Steinen beim Server anfordern. Jeder Spieler zieht zu Be-
ginn seines Spielzugs einen oder mehrere Spielsteine vom Stapel bis er wieder sechs
Steine auf der Hand hat.
• Spieler dürfen Spielsteine tauschen. Wenn ein Spieler nicht legen kann, muss er/sie
wenigstens einen Stein tauschen. Die eingetauschten Spielsteine werden an das Ende
des Stapels angehängt. Der/die Spieler/in darf in diesem Zug keine Steine mehr legen.
• Die Anzahl der einzelnen Farben und Symbole ist konfigurierbar und entspricht somit
nicht notwendigerweise der Verteilung in oben angegebener Anleitung.
• Ein Qwirkel (Vervollständigung einer Reihe) ergibt nicht feste sechs Sonderpunkte, son-
dern Punkte in Höhe der Anzahl der Steine dieser Reihe.
32 Organisatorische & Technische Vorgaben
2 Organisatorische & Technische Vorgaben
In diesem Kapitel wird beschrieben, welche organisatorischen und technischen Vorgaben wir
als Auftraggeber an Sie während des Praktikums stellen.
2.1 Deliverables
Im Rahmen des Softwaretechnikpraktikum (SWTPra) entwickeln Sie, entsprechend der Pro-
duct Vision (Kapitel 1), ein netzwerkfähiges Qwirkle-Spiel inklusive entsprechender Clients
für PC und Android. Während des Praktikums wird auf der Webseite der Veranstaltung ein
Abgabeplan veröffentlicht1 . Entsprechend dem veröffentlichten Abgabeplan sind zu den ge-
gebenen Deadlines folgende Dokumente bzw. Implementierungen abzugeben:
• Angebot
• Product Backlog
• Quality-Assurance-Dokument
• Protokoll-Dokument
• DevOps-Dokument
• Endabgabe: Präsentation, Implementierung, Test-Report, Website
Verspätete Abgaben werden sanktioniert. Sämtliche abzugebenden Dokumente können auf
Deutsch verfasst werden. Details zum Inhalt der Abgaben finden Sie auf der Webseite der
Veranstaltung. Der Code selbst und Codekommentare werden auf Englisch verfasst.
Es wird zwei Arten von Teams geben: DS und SD. Die Zuweisung wird nach der Gruppen-
findungsphase zufällig geschehen. Abhängig davon, in welchem Team Sie sind, sind unter-
schiedliche Komponenten zu entwickeln. Da Sie außerdem einige Komponenten im Verlauf
des Projektes von anderen Teams erwerben und erweitern, wird Ihr finales Produkt folgende
Komponenten enthalten:
• Das von allen Gruppen abzugebende Produkt besteht jeweils aus Spielserver, und Engine-
Teilnehmer.
• DS-Teams geben zusätzlich einen PC-Beobachter und einen Smartphone-Teilnehmer
ab.
• SD-Teams geben zusätzlich einen Smartphone-Beobachter und PC-Teilnehmer ab.
Eine zusammenfassende Übersicht über die Bestandteile des zu liefernden Produkts finden Sie
in Abbildung 1.
Um die Kompatibilität zwischen den Komponenten verschiedener Teams zu gewährleisten,
wird das Kommunikationsprotokoll gemeinschaftlich von allen Teams in einem Protokoll-
Komitee spezifiziert. Mehr dazu im Abschnitt 2.3.
1
https://www.hni.uni-paderborn.de/swt/lehre/swtpra/
42 Organisatorische & Technische Vorgaben
Server
Konfiguration Spiel-Server
Netzwerk
Clients
PC- Smartphone- PC- Smartphone- Engine-
Beobachter Beobachter Teilnehmer Teilnehmer Teilnehmer
M M
Legende:
entwickelt durch entwickelt durch entwickelt im M auf Messe
Gruppe DS Gruppe SD Protokoll-Komitee gehandelt
Abbildung 1: Übersicht über das zu entwickelnde Produkt
2.2 Ablauf des Praktikums
Nach Abgabe Ihres Angebots, Product Backlog und des Quality Assurance Dokuments, star-
ten Sie mit der Umsetzung des Produkts (Implementierung, Testen, Dokumentation, Sprint
Planung, etc.). In der Rolle des Kunden behalten wir es uns vor ggf. eine Überarbeitung des
Angebots, Product Backlogs, oder Quality-Assurance-Dokuments vor dem Start der Umset-
zung zu verlangen.
Während der Umsetzungsphase wird eine Messe stattfinden, die zur Präsentation sowie zum
Erwerb bzw. Veräußerung der bisher erstellten Komponenten aller Teams dient.
• Als SD-Team bieten sie den entwickelten Smartphone-Beobachter den DS-Teams zum
kostenlosen Erwerb an.
• Als DS-Team bieten sie den entwickelten PC-Beobachter den SD-Teams zum kostenlo-
ses Erwerb an.
Zusätzlich zur Implementierung stellen Sie dem erwerbenden Team Ihr DevOps-Dokument
bereit, das die Konfiguration und Inbetriebnahme der betreffenden Komponenten beschreibt.
Auch nach der Messe liegt es in Ihrer Pflicht Support für die vertriebenen Komponenten zu
leisten, indem Sie Fehler in Ihrer Software beheben und den Erwerbern neue Versionen zu-
gänglich machen.
52 Organisatorische & Technische Vorgaben
Um ein komplettes Produkt zu erhalten, integrieren Sie die auf der Messe erworbenen Kompo-
nenten in Ihre bisherige Implementierung. Wir empfehlen allen Teams die Weiterentwicklung
des von Ihnen eingekauften Beobachters zu einem Teilnehmer und keine vollständige Neuent-
wicklung.
Nach Fertigstellung Ihres Produkts und der dazugehörigen Dokumente, präsentieren Sie Ihr
Produkt in einer Abschlusspräsentation inklusive einer Live-Demonstration. Die Abschluss-
präsentation schließt die Entwicklung einer Webseite ein, auf der Sie Ihr Produkt und Ihre
Dokumente präsentieren2 .
Am Ende des Praktikums werden wir ein Turnier veranstalten, in dem die Engine-Teilnehmer
der Teams gegeneinander antreten. Durch einen noch festzulegenden Turniermodus wird im
Turnier der beste Engine-Teilnehmer ermittelt. Zusätzlich werden nach dem Turnier die Teams
geehrt, die – unabhängig vom Engine-Teilnehmer– im Verlauf des Praktikums die besten Leis-
tungen gezeigt haben.
2.3 Protokoll-Komitee
Um die Kompatibilität der von unterschiedlichen Teams entwickelten Clients und Server zu
gewährleisten, wird ein geeignetes Kommunikationsprotokoll von Ihnen in einem Protokoll-
Komitee entwickelt. Hierzu entsendet jedes Team einen Protokoll-Beauftragten in das Protokoll-
Komitee. In der ersten Sitzung des Protokoll-Komitees wählen die Protokoll-Beauftragten
einen Vorsitzenden, der das Komitee leitet. Entscheidungen des Komitee müssen mit absolu-
ter Mehrheit beschlossen werden. Enthaltungen sind hierbei nicht möglich. Jede Gruppe muss
also an jedem Entscheidungsprozess teilnehmen. Mutwilliges Enthalten einer Gruppe führt
zu Punktabzug für die gesamte Gruppe. Das Komitee wird durch den Programmierbetreuer
unterstützt.
Die Entscheidungen des Protokoll-Komitees und das Protokoll selbst werden durch das Komi-
tee in einem gesonderten Protokoll-Dokument festgehalten und zu einer separat ausgewiese-
nen Deadline abgegeben. Das festgehaltenen Protokoll dient als Grundlage der Implementie-
rungen aller Teams, um deren Kompatibilität untereinander zu gewährleisten. Sollten während
der Implementierung Änderungen am Protokoll notwendig werden, trifft sich das Komitee er-
neut und veröffentlicht eine neue Version des Protokolls und Dokuments.
2.4 Praktikumsturnier
Am Ende des Praktikums findet ein Turnier statt, in dem die von den Teams entwickelten
Engine-Teilnehmer gegeneinander antreten. Der Server für das Turnier wird entweder von den
Auftraggebern gestellt oder es wird ein von den Teams entwickelter Spielserver ausgewählt.
Bei der Auswahl des PC-Beobachters für das Turnier wird analog verfahren. Die Konfigurati-
on für das Turnier wird erst beim Turnier selbst bekannt gegeben. Daher empfiehlt es sich vor
dem Turnier Ihren Engine-Teilnehmer mit verschiedenen Konfigurationen zu testen.
2
Eine Facebook-Seite oder Profile auf anderen Social-Media-Seiten genügen nicht.
62 Organisatorische & Technische Vorgaben
2.5 Technologien und Entwicklungswerkzeuge
Zur Anfertigung des Product Backlogs ist die Scrum Online-Platform Taiga.io3 einzusetzen.
Nach einer einmaligen Registrierung können Sie die von uns gehostete Taiga.io Instanz unter
der Adresse https://swtpra.cs.upb.de/ erreichen. Bei Fragen und Problemen bzgl.
Taiga.io können Sie sich an die Programmierbetreuung wenden.
Die Implementierung erfolgt unter Benutzung der Programmiersprache Java. Das fertige Pro-
dukt soll unter der aktuellsten Version von Java SE 8 lauffähig sein. Die Android-Apps sollen
ab Android 5.0.1 (API-Level 21) lauffähig sein.
Das Kommunikationsprotokoll zwischen Server und Clients sowie das Dateiformat zur Spei-
cherung der Konfiguration werden auf der Grundlage von JSON umgesetzt.
Zur Entwicklung und Versionsverwaltung im Team werden innerhalb des Praktikums die Git-
Lab https://git.cs.upb.de/ Server der Universität genutzt. Hierzu werden von uns
Git-Repositories für die einzelnen Gruppen angelegt. Um Zugriff auf das Git-Repository ei-
ner Gruppe zu erhalten, wird ein Git-Client benötigt. Git-Clients mit GUI sind zum Beispiel
TortoiseGit4 oder SourceTree5 .
Um verlässliche und reproduzierbare Builds Ihres entwickelten Produkts und der einzelnen
Komponenten zu realisieren, werden Sie die Build-Systeme Maven bzw. Gradle einsetzen.
Einführungen zu Maven 6 und Gradle 7 finden Sie unter den angegebenen Adressen. Zusätzlich
können Sie sich bei Fragen und Problemen an die Programmierbetreuung wenden.
Optional
Zusätzlich zu den Git-Repositories bietet die Universität Paderborn mit GitLab CI ein System
zur kontinuierlichen Integration Ihrer Implementierung. Mithilfe von GitLab CI kann bsw. bei
pushes in den master-branch automatisiert der Build-Prozess und die Testausführung angesto-
ßen werden. Somit bietet es Ihnen die Möglichkeit bei jedem push automatisiert Ihren Code
zu bauen, zu testen, und bei fehlerhaften Commits sofort Benachrichtigungen per E-Mail zu
erhalten. Dies hilft Ihnen bei der kontinuierlichen Qualitätskontrolle und Koordination. Da
Sie in dieser Veranstaltung entsprechend Scrum nach jedem Sprint ein inkrementelles Produkt
Artefakt entwickeln, können Sie diese mit GitLab CI kontinuierlich bauen und testen. Hil-
fe zu GitLab CI finden Sie unter https://git.cs.upb.de/help/ci/README.md.
Zusätzlich können Sie sich bei Fragen und Problemen an den Programmierberater wenden.
3
https://taiga.io/
4
https://tortoisegit.org/
5
https://www.sourcetreeapp.com/
6
https://maven.apache.org/guides/getting-started/maven-in-five-minutes.
html
7
http://www.vogella.com/tutorials/Gradle/article.html
7Sie können auch lesen
