Beispiel 2

Aufgabenstellung - Memory

Im Rahmen der Entwicklung eines Memory-Spiels soll als Speicherformat XML eingesetzt werden, um den aktuellen Spielstand zu beliebigen Zeitpunkten des Spiels speichern und laden zu können.

Zuerst ist ein XML Schema und ein entsprechendes XML Instanzdokument zu erstellen. Aufbauend darauf ist eine DTD zu erstellen, die soweit wie möglich dieselbe Struktur für das XML Instanzdokument vorgibt wie das XML Schema.

XML Schema

Erstellen Sie im ersten Teil dieser Übung ein XML Schema und ein XML Instanzdokument. Halten Sie sich bei dem Entwurf des Schemas an die folgenden Vorgaben:

Verwenden Sie als Target Namespace des XML Schemas folgenden Namensraum:
- Der URI des Namensraumes soll dabei http://www.dbai.tuwien.ac.at/education/ssd/SS11/uebung/Memory lauten.
- Verwenden Sie im Instanzdokument den Default Namespace, um sich auf diesen Namespace zu beziehen.
- Alle Elemente des Instanzdokumentes sollen in diesem Namespace liegen, während alle Attribute im leeren Namensraum liegen sollen.
Definieren Sie den Typ MemoryCard global:
- Der Typ MemoryCard soll nur Attribute umfassen können.
- Eine MemoryCard ist im Spiel genau einer Zeile und einer Spalte zugeordnet. Definieren Sie dafür die Attribute column und row vom Typ int als verpflichtend.
- Um bestimmen zu können, ob 2 Karten übereinstimmen, soll eine ID verwendet werden. Definieren Sie das Attribut id vom Typ string als verpflichtend.
- Eine MemoryCard wird von allen anderen MemoryCards durch die Kombination der Attribute id, column und row eindeutig unterschieden. Definieren Sie ein Attribut key vom Typ string als verpflichtend. Die Schlüssel im Instanzdokument sollen dabei folgende Form einhalten: id_column_row. Sie müssen die Einhaltung dieser Form aber nicht explizit im Schema sicherstellen.
- Eine MemoryCard kann 2 Zustände annehmen (COVERED - Karte ist verdeckt, UNCOVERED - Karte ist sichtbar). Definieren Sie dafür das Attribut current-state als verpflichtend. Stellen Sie sicher, dass der current-state ausschließlich einen der folgenden 4 Werte annehmen kann: Integer-Werte 0 oder 1, String-Werte COVERED oder UNCOVERED.
- Zusätzlich soll zu einer MemoryCard auch noch gespeichert werden wie oft diese im Spiel bisher aufgedeckt wurde. Verwenden Sie dafür ein Attribut mit dem Namen uncover-count vom Typ int. Der uncover-count soll per default den Wert 0 annehmen.
Definieren Sie den Typ MemoryCardPairs global:
- Der Typ MemoryCardPairs besteht aus beliebig vielen Elementen namens pair. Ein pair soll dabei nur Attribute umfassen können.
- Einem Kartenpaar sind zwei Karten über ihren Schlüssel (das Attribut key) zugeordnet. Definieren Sie dafür die Attribute card1 und card2 vom Typ string als verpflichtend.
- Weiters soll zu einem Kartenpaar noch direkt gespeichert werden, ob die beiden Karten übereinstimmen. Definieren Sie dafür das Attribut is-match vom Typ boolean. Per Default soll hier der Wert false angenommen werden.
Definieren Sie den Typ MemoryPlayer global:
- Ein MemoryPlayer besteht aus einem optionalem Element player-description und einem weiterem optionalem Element uncovered-pairs.
- Das Element player-description wird verwendet um eine kurze Beschreibung der am Spiel teilnehmenden SpielerInnen speichern zu können. Es soll gemischten Inhalt zulassen. Wobei neben Text als einziges Kindelement das Element date vom Typ date beliebig oft vorkommen darf.
- Das Element uncovered-pairs soll den zuvor global definierten Typ MemoryCardPairs verwenden. Es wird dazu verwendet alle bisher von diesem SpielerInnen aufgedeckten Kartenpaare (egal ob diese übereinstimmen oder nicht) zu speichern.
- Ein SpielerInnen wird über seinen Namen eindeutig identifiziert. Definieren Sie dafür ein Attribut name vom Typ string.
- Weiters wird zu einem SpielerInnen noch gespeichert wie lange er in diesem Spiel bisher gespielt hat. Verwenden Sie dafür ein Attribut spent-time vom Typ long. Schränken Sie den Wertebereich auf Zahlen größer oder gleich null ein.
Definieren Sie den Typ MemoryGame global:
- Ein MemoryGame besteht aus folgenden Elementen in beliebiger Reihenfolge: table, players, covered-pairs (optional), uncovered-pairs (optional).
- Das Element table wird verwendet um alle in einem Spiel befindlichen Karten zu speichern. Es besteht aus mindestens 2 Elementen namens card von dem zuvor definiertem Typ MemoryCard.
- Das Element players wird verwendet um alle an einem Spiel teilhabenden SpielerInnen zu speichern. Es besteht aus mindestens einem Element player von dem zuvor definiertem Typ MemoryPlayer.
- Die Elemente covered-pairs und uncovered-pairs werden dafür verwendet alle im Spiel gefundenen bzw. nicht gefundenen Kartenpaare zu speichern. Verwenden Sie für beide Elemente den zuvor definierten Typ MemoryCardPairs.
- Um den SpielerInnen speichern zu können, der derzeit am Zug ist soll ein Attribut current-player vom Typ string optional verwendet werden. Dieses referenziert den Namen eines SpielerInnen, welcher in dem Element players gespeichert ist.
- In einem Spiel kann zu jedem Zeitpunkt keine, eine oder zwei Karten aufgedeckt sein. Definieren Sie dafür die Attribute current-card1 und current-card2 als optional vom Typ string, welche jeweils den Schlüssel einer Karte aus dem Element cards referenzieren.
- Ein Spiel befindet sich zu jedem Zeitpunkt in einem von fünf fest definierten Zuständen (NO_CARD - Aktuell ist keine Karte aufgedeckt, CARD1 - Aktuell ist eine Karte aufgedeckt, CARD2_MATCH - Aktuell sind 2 übereinstimmende Karten aufgedeckt, CARD2_UNMATCH - Aktuell sind 2 nicht übereinstimmende Karten aufgedeckt, GAME_OVER - Das Spiel ist bereits vorbei). Definieren Sie dafür ein Attribut current-state das ausschließlich die Werte 0 bis 4 als Integer oder NO_CARD, CARD1, CARD2_MATCH, CARD2_UNMATCH und GAME_OVER als String annehmen darf.
- Weiters soll noch gespeichert werden, wie viel Zeit seit dem aktuellen Zug vergangen ist (Verpflichtendes Attribut current-turn-started vom Typ long als mit Werten ausschließlich größer oder gleich 0), sowie der Zeitpunkt an dem das Spiel überhaupt gestartet wurde (Optionales Attribut game-started vom Typ date).
Definieren Sie das Wurzelelement game. Verwenden Sie dafür den zuvor definierten Typ MemoryGame
Verwenden Sie die Konstrukte key und keyref um folgendes sicherzustellen:
- Das Attribut name in allen player-Elementen muss eindeutig sein und kann als Schlüssel verwendet werden.
- Das Attribut key in allen card-Elementen muss eindeutig sein und kann als Schlüssel verwendet werden.
- Das Attribut current-player im game-Element muss den Namen eines Spielers/einer Spielerin referenzieren (name Attribut in player-Element).
- Die Attribute current-card1 und current-card2 im game-Element müssen den Schlüssel einer Karte referenzieren (key Attribut in card-Element).
- Die Attribute card1 und card2 in den pair-Elementen müssen den Schlüssel einer Karte referenzieren (key Attribut in card-Element).

Das XML-Dokument soll die unterschiedlichen Möglichkeiten veranschaulichen und daher möglichst viele beschriebenen Einschränkungen abdecken (optionale Elemente, verschiedene Werte für Attribute etc.)

Es bietet sich zudem an, die intendierten Schlüssel (key/keyref), mit gültigen und bezüglich dem Schema ungültigen Instanzdokumenten zu testen.

Beachten Sie, dass Sie alle oben angeführten Vorgaben umsetzen müssen, um die volle Punktezahl erhalten zu können.

Benennen Sie die Schemadatei mit memory.xsd und das Instanzdokument mit memory.xml.

überprüfen Sie Ihre Lösung mit dem Befehl

xmllint --schema memory.xsd memory.xml.

Resultierende Dateien: memory.xsd, memory.xml
Maximale Punkte: 7

Document Type Definition (DTD)

Erstellen Sie im zweiten Teil eine Document Type Definition, die soweit wie möglich dieselbe Struktur für das XML Instanzdokument vorgibt wie das XML Schema, das Sie im ersten Teil erstellt haben.

Beachten Sie:

Einige Funktionalitäten von XML Schema lassen sich mittels einer DTD nur sehr umständlich oder gar nicht umsetzen. Welche Funktionen sind dies? Sie müssen in jedem dieser Fälle beim Abgabegespräch begründen können, warum die Umsetzung in der DTD nicht oder nur unzureichend möglich ist.
Der Typ des Elements game kann in der DTD nur sehr schwer ausgedrückt werden, da der Parser diesen als deterministisch ansehen muss. Hier reicht es, wenn Sie die genaue Elementabfolge ihres Instanzdokumentes als verpflichtend definieren (wobei die Elemente covered-pairs und uncovered-pairs weiterhin optional sein sollen).

Benennen Sie die DTD mit memory.dtd.

Prüfen Sie die DTD gegen das XML-Dokument aus dem ersten Teil mit dem Befehl

xmllint --dtdvalid memory.dtd memory.xml.

Resultierende Datei: memory.dtd
Maximale Punkte: 3

Abgabegespräch

Die Beispiele müssen bis zum Abgabetermin auf unserem Server (bordo.dbai.tuwien.ac.at) im Unterverzeichnis beispiel2 ihres Home-Verzeichnisses verfügbar sein (die Dateien werden automatisch abgesammelt und den Tutorinnen und Tutoren zur Verfügung gestellt).

Insgesamt erstellen Sie also 3 Dateien (1-mal XML Schema, 1-mal XML, 1-mal DTD).

Überprüfen Sie Ihre Abgabe direkt auf dem Server! Die notwendigen Tools sind installiert, und die Tutorinnen und Tutoren prüfen Ihre Abgabe ebenfalls direkt am Server. Laden Sie außer den Abgabedateien keine weiteren Dateien auf den Server!

Bewertung

Für das Beispiel 2 werden maximal 10 Punkte vergeben. Im Rahmen des Kontrollgespräches wird nicht nur die Korrektheit, sondern vor allem das Verständnis der Technologien kontrolliert.

Die volle Punktezahl gibt es nur wenn das Beispiel korrekt gelöst ist und die Lösung erklärt werden kann. Nicht selbstständig gelöste Abgaben werden jedenfalls mit 0 Punkten bewertet!

Home / Kontakt / Webmaster / Offenlegung gemäß § 25 Mediengesetz: Inhaber der Website ist das Institut für Logic and Computation an der Technischen Universität Wien, 1040 Wien. Die TU Wien distanziert sich von den Inhalten aller extern gelinkten Seiten und übernimmt diesbezüglich keine Haftung. Disclaimer / Datenschutzerklärung