|
|
I-PROGR3 WS03 - PROGRAMMIEREN3 - Vorlesung mit Übung
|
In dieser Vorlesungen sollen die Überlegungen aus der letzten Vorlesung fortgesetzt werden. Anhand eines Beispiels soll verdeutlicht werden, welche zusätzlichen Überlegungen relevant werden, wenn man ein Verhaltensmodell in ein Designmodell überführen will.
Wie schon in der letzten Vorlesung vermutet, führen die Überlegungen zum Designmodell dazu, dass die vorausgehenden Überlegungen zum Verhaltensmodell zum Teil präzisiert werden müssen. Ausserdem, um das Projekt überschaubar zu halten, müssen einige Vereinfachungen vorgenommen werden.
Bisher wurden in einem Use Case das Zusammenspiel zwischen einem Master und einem User mit einer Welt ('world') angenommen; die Welt wiederum interagierte mit Objekten und Regeln.
Für die weitere Ausarbeitung des Beispiels nehmen wir an, dass es sich bei der Welt um ein Damespiel handelt, das nach deutschen Regeln gespielt wird. Die Regeln lauten wie folgt:
Damebrett mit Figuren;
Spalten von links a-h,
Zeilen von oben 8-1
|
Dame-Spiel: Geschichte und Regeln |
|
Dame: Über das Damespiel wird schon von Autoren des 17. Jahrhunderts mit genauen Spielanweisungen berichtet. Sogar im "Don Quichote" von Cervantes kommt es vor. Der Dichter zitiert die alte spanische Romanze von Don Gaiferos, der über dem Damespiel die eigene Herzensdame vergisst. Gespielt wird mit einem Schachbrett; auch die beim Schach üblichen Bezeichnungen der Felder mit Buchstaben und Zahlen wurden beim Damespiel übernommen. Das Brett wird zwischen den beiden Partnern so auf den Tisch gelegt, dass jeder in der vorderen Reihe links ein schwarzes Eckfeld vor sich hat. Zwölf schwarze und zwölf weiße Spielsteine sind notwendig. Jeder setzt seine Steine auf die schwarzen Felder des Spielbrettes in den drei ihm zugekehrten ersten Reihen. In jeder dieser Reihen stehen also vier Steine. Spielgedanke: Beide Parteien rücken mit ihren Steinen aufeinander los und versuchen, sämtliche Steine des Gegners zu schlagen oder bewegungsunfähig zu machen. Die Steine werden abwechselnd in einem Zug vorwärts bewegt, und zwar nur diagonal, d.h. von einem schwarzen Feld auf das übereck angrenzende nächste schwarze Feld. Auf die weißen Felder darf nicht gezogen werden, ebenso sind Rückwärtsbewegungen verboten (Ausnahme: Dame, siehe weiter unten). Geschlagen wird ebenfalls diagonal. Der schlagende Stein muss den zu schlagenden dabei überspringen, d.h. über ihn hinweg auf ein freies Feld springen. Geschlagene Steine werden aus dem Spiel genommen. Hat ein Stein der eigenen Partei ein Feld der gegnerischen Randreihe erreicht, wobei es keine Rolle spielt, ob er ziehend oder schlagend dorthin gelangt ist, gilt er vom nächsten Zug an als "Dame" und wird mit einem zweiten, ausgeschiedenen Stein "gedoppelt". Die Dame kann sich vor- und rückwärts bewegen, und zwar in der einmal eingeschlagenen Diagonalrichtung beliebig weit. Sie beherrscht also von ihrem Standort aus zwei sich kreuzende Diagonalen und muss jeden Stein schlagen, der sich auf ein Feld dieser Kreuzung wagt - vorausgesetzt, es ist, von der Dame aus gesehen, hinter ihm mindestens ein Feld frei. Die Dame braucht sich nach dem Schlagen nicht auf einem Feld hinter dem geschlagenen Stein niederzulassen, sie darf, wenn weitere freie Felder vorhanden sind, noch beliebig weiterziehen. Steine der eigenen Partei darf die Dame aber nicht überspringen. Wichtige Regeln: Wer einen Stein berührt, muss (wie beim Schach) auch mit ihm ziehen - es sei denn, er erklärt ausdrücklich, ihn nur zurechtrücken zu wollen. Wer die Möglichkeit zum Schlagen einer Dame oder eines Steines (oder auch mehrerer Steine hintereinander) hat, muss sie ausnützen. Tut er das nicht, darf der Gegner den betreffenden Stein "blasen", d.h. einfach vom Brett nehmen. Das Blasen gilt nicht als Zug. Es muss also auch dann geschlagen werden, wenn der schlagende Stein dadurch selbst in eine gefährdete Position gerät. Das Recht des Blasens muss nicht ausgenützt werden. Der betreffende Spieler kann von seinem Gegner auch verlangen, den falschen Zug zurückzunehmen und statt dessen den richtigen zu machen. Hat bei Spielende ein Spieler drei Damen, der andere eine, die auf der Diagonale A1-H8 steht, wird die Partie als unentschieden ("remis") abgebrochen, falls der dreifache Damenbesitzer die Einzeldame nicht beim nächsten Zug schlagen kann. |
Für die nachfolgende Ausarbeitung werden folgende vereinfachende Annahmen gemacht:
Der Master muss nicht modelliert werden, da wir eine Welt im Sinne obiger Regeln annehmen.
Es werden zwei User A und B angenommen; die Simulation eines Users durch das Programm bleibt einer späteren Modellierung vorbehalten.
User A und B ziehen abwechselnd bis entweder einer gewonnen hat oder ein Unentschieden ('Remis') erreicht wurde.
Die Überprüfung eines Zuges durch die Regelmenge wird an dieser Stelle nicht modelliert; sie wird als 'Dummy' behandelt; jeder Zug wird akzeptiert.
Der modifizierte Use Case für die Welt in form eines Damespiels sieht dann wie folgt aus:
Use Case für world1 als Damespiel
Eine Ereignis-Reaktions-Liste könnte wie folgt aussehen:
|
NR. |
EREIGNIS |
REAKTION |
NEXT |
PREVIOUS |
|---|---|---|---|---|
|
1. |
Starte Spiel durch User A |
Anzeige eines Spielbrettes |
2 |
1,6 |
|
2. |
Zug durch Spieler A |
Anzeige der Änderung auf Brett |
3-4,6 |
1,3 |
|
3. |
Zug durch Spieler B |
Anzeige der Änderung auf Brett |
2,4,6 |
2 |
|
4. |
Unterbrechung des Spiels |
Anzeige Unterbrechung |
5 |
2-3 |
|
5. |
Wiederaufnahme des Spiels |
Anzeige aktueller Spielstand |
2-4,6 |
4 |
|
6. |
Stoppen eines Spiels |
Anzeige Ende |
1 |
2-3,5 |
Man kann an dieser Liste erkennen, dass diese Beschreibungen für eine tatsächliche Realisierung noch viel zu vage sind. Das beobachtbare Verhalten muss also noch weiter präzisiert werden.
Bei den Klassen wird zunächst keine Änderung vorgenommen; der Master wird ausgeklammert; die Regelmenge als Dummy behandelt, d.h. die eingaben werden 1:1 in der Ausgabe gespiegelt.:
Klassendiagramm für world1-Dame Anwendung
Das nachfolgende Sequenzdiagramm zeigt nur die verhaltensbasierten Aktionen. Im Falle von Spielunterbrechung und Spielbeendigung wird nur die Variante von spieler A gezeigt.
Sequenzdiagramm für world1-Dame Anwendung
Nach diesen Anpassungen des Verhaltensmodells an das Beispiel des Damespiels (nach deutschen Regeln) soll jetzt versucht werden, das Designmodell zu erzeugen. Die Grundregel lautet, dass all jene Teile der Modellierung zu ergänzen sind, die hinsichtlich einer Implementierung des Verhaltensmodells noch fehlen.
Schon erste Überlegungen zeigen, dass eine Reihe von zusätzlichen Annahmen getroffen werden müssen (die z.T. im Use Case nachzutragen wären). Hier eine Liste von präzisierenden Anforderungen:
Es muss geklärt werden, wie die Anzeige des Spielbrettes zu erfolgen hat. Da Grafik erst später in die Vorlesung einbezogen werden soll, steht nur eine ASCII-Darstellung zur Verfügung. Folgende Vereinbarung soll gelten: weisses Feld := '_' (Unterstrich), schwarzes Feld := '#' (Doppelkreuz) oder besetzt durch einen 'weissen Stein' := 'w' bzw. weisse Königin := 'W' oder durch einen schwarzen Stein := 's' bzw. schwarze Königin := 'S'.
Zugeingabe kann entsprechend ebenfalls nur über Eingabe eines ASCII-Strings erfolgen. Das Format einer Eingabe ist 'STARTFELD:ZIELFELD[,ZIELFELD]*', z.B. 'a3:b4' oder 'a1:c3,a5'.
Als Züge können vorkommen: einfache Positionsveränderung (einfacher Stein oder Dame), Sprung über gegnerische Steine durch einfachen Stein oder Sprung über gegnerische Steine durch Dame; letztere kann sich das Zielfeld auf der Diagonalen frei wählen, sofern es frei ist.
Bei Erreichung des gegnerischen Randes wird ein einfacher Stein beim nächsten Ziehen in eine Dame verwandelt.
Die weitere Umsetzung erfolgt nun anhand des Implementierungsschemas aus Vorlesung 2:
Übersicht Modellierung und Implementierung
Auf der Basis des Sequenzdiagramms und der zusätzlichen präzisierenden Annahmen soll nun ein Aktivitätsdiagramm festgelegt werden, das als Basis für die Usage-Datei dienen soll.
Aktivitätsdiagramm für die Usage-Datei
Um dieses Aktivitätsdiagrtamm umsetzen zu können, werden in einem ersten Schritt möglichst einfache Prototypen aller jener Klassen implementiert, die man benötigt, um eine erste Version der Usage-Datei realisieren zu können. Ausgehend von dieser ersten Usage-Datei werden dann alle weiteren Verfeinerungen vorgenommen.
Wir beginnen mit der Erzeugung der Basisdateien für world.h object.h rule_set.h checker_usage.cpp world.cpp object.cpp rule_set.cpp. Dabei benutzen wir für alle Dateien ausser checker_usage.cpp die automatische Erzeugung von umbrello.
Die erste Datei checker_usage.cpp gibt zunächst nur eine Meldung aus; sonst tut sie noch nichts.
//*****************************
//
// checker_usage.cpp
//
//*******************************
#include "world.h"
#include "object.h"
#include "rule_set.h"
#include <iostream>
int main(){
cout << "WILLKOMMEN ZUR WELT DES DAMESPIELS"<<endl;
return 1;
}
Die Klassendatei world.h legt die Grundstruktur der Klasse 'world' fest; in der Implementierungsdatei world.cpp sind die verlangten Funktionen aber noch leer. Sie 'tun noch nichts'.
/************************************************************************
world.h - Copyright gerd
This file was generated on Mon Okt 27 2003 at 18:56:49
The original location of this file is /home/gerd/public_html/fh/I-PROGR3/I-PROGR3-TH/VL4/world.h
**************************************************************************/
#ifndef WORLD_H
#define WORLD_H
#include <string>
using namespace std;
/**
* class world
*
*/
class world
{
/** Public methods: */
public:
/**
* User kann ein spiel starten
*/
bool world_start_game( );
/**
* Ein User unterbricht ein laufendes Spiel
*/
bool world_pause_game( );
/**
* Ein User setzt ein unterbrochenes Spiel fort
*/
bool world_continue_game( );
/**
* Ein User beendet ein laufendes Spiel
*/
bool world_stopp_game( );
/**
* Ein User nimmt eine aktion vor
*/
bool world_do_action( );
/**
*
* @param world_action_object_name
* Name des Objektes, das eine aktion ausgeführt hat
* @param world_action_action_name
* Name der Aktion, die das Objekt ausführen will
*/
string world_evaluate_action( string world_action_object_name, string world_action_action_name );
/**
*
*/
void show_world( );
};
#endif // WORLD_H
/************************************************************************
world.cpp - Copyright gerd
This file was generated on Mon Okt 27 2003 at 18:56:49
The original location of this file is /home/gerd/public_html/fh/I-PROGR3/I-PROGR3-TH/VL4/world.cpp
**************************************************************************/
#include "world.h"
bool world::world_start_game( )
{
}
bool world::world_pause_game( )
{
}
bool world::world_continue_game( )
{
}
bool world::world_stopp_game( )
{
}
bool world::world_do_action( )
{
}
string world::world_evaluate_action( string world_action_object_name, string world_action_action_name )
{
}
void world::show_world( )
{
}
Die Klassendatei object.h legt die Grundstruktur der Klasse 'object' fest; in der Implementierungsdatei object.cpp sind die verlangten Funktionen ebenfalls noch leer.
/************************************************************************
object.h - Copyright gerd
This file was generated on Mon Okt 27 2003 at 18:56:49
The original location of this file is /home/gerd/public_html/fh/I-PROGR3/I-PROGR3-TH/VL4/object.h
**************************************************************************/
#ifndef OBJECT_H
#define OBJECT_H
#include <string>
using namespace std;
/**
* class object
*
*/
class object
{
/** Public methods: */
public:
/**
* Welt kann aktuellen Zustand eines Objektes anschauen; im Falle von Damesteinen
* ist es der Zustand 'einfacher Stein' oder 'Damestein' sowie die Position im
* Brett
*/
string object_show_status( );
/**
* Welt kann eine Änderung bei einem Objekt anstossen. Im Falle des Damespiels kann
* ein Stein nur in diagonaler Richtung ziehen. Als einfacher stein nur vorwärts,
* als Dame auch rückwärts mit variabler Position in der Diagonalen.
* @param change_input
* change_input kann einen String mit Angaben darüber übernehmen, welche Aktionen
* ausgeführt werden sollen
*/
bool object_change( string change_input = "nil" );
/**
* initAttributes sets all object attributes to its default value
* make sure to call this method within your class constructor
*/
private: void initAttributes();
/**Attributes: */
private:
/**
* Jedes Objekt hat mindestens eine 2D-Gestalt
*/
string object_shape;
/**
* Jedes Objekt hat eine Farbe oder ein Muster
*/
string object_colour;
/**
* Jedes Objekt hat innerhalb seines Typs einen eindeutigen Namen
*/
string object_name;
/**
* Jedes Objekt gehört zu einem Typ einer endlichen Typliste. Im Falle des
* Damespiels gibt es einfache Steine und Damen.
*/
int object_type;
};
#endif // OBJECT_H
/************************************************************************
object.cpp - Copyright gerd
This file was generated on Mon Okt 27 2003 at 18:56:49
The original location of this file is /home/gerd/public_html/fh/I-PROGR3/I-PROGR3-TH/VL4/object.cpp
**************************************************************************/
#include "object.h"
string object::object_show_status( )
{
}
bool object::object_change( string change_input )
{
}
void object::initAttributes( )
{
string object_shape = "circle";
string object_colour = "black";
string object_type = "simple_stone";
}
Schliesslich die Klassendatei rule_set.h mit der Implementierung 'rule_set'.
/************************************************************************
rule_set.h - Copyright gerd
This file was generated on Mon Okt 27 2003 at 18:56:49
The original location of this file is /home/gerd/public_html/fh/I-PROGR3/I-PROGR3-TH/VL4/rule_set.h
**************************************************************************/
#ifndef RULE_SET_H
#define RULE_SET_H
#include <string>
using namespace std;
/**
* class rule_set
*
*/
class rule_set
{
/** Public methods: */
public:
/**
*
* @param world_configuration
* Aktuelle Konfiguration der Welt
* @param actual_move
* Aktueller Zug eines Spielers
*/
int apply_ruleset( string world_configuration, string actual_move );
};
#endif // RULE_SET_H
/************************************************************************
rule_set.cpp - Copyright gerd
This file was generated on Mon Okt 27 2003 at 18:56:49
The original location of this file is /home/gerd/public_html/fh/I-PROGR3/I-PROGR3-TH/VL4/rule_set.cpp
**************************************************************************/
#include "rule_set.h"
int rule_set::apply_ruleset( string world_configuration, string actual_move )
{
}
Um diese Dateien zu kompilieren benützen wir das Werkzeug qmake. Mit qmake kann man aus einer Konfigurationsdatei mit Endung '.pro' automatisch ein Makefile für make generieren. Dieses makefile ist zwar für QtDesigner optimiert, aber man kann die nicht notwendigen Elemente nach Bedarf auch wieder entfernen.
Die Konfigurationsdatei heisst hier 'checker.pro' und sieht folgendermassen aus:
SOURCES = checker_usage.cpp world.cpp object.cpp rule_set.cpp HEADERS += world.h object.h rule_set.h CONFIG += debug
Man sieht, dass in der Konfigurationsdatei eigentlich nur die Dateien aufgelistet werden, aus denen das Projekt besteht. Alles weitere macht qmake:
gerd@kant:~/public_html/fh/I-PROGR3/I-PROGR3-TH/VL4> /usr/lib/qt3/bin/qmake checker.pro
Nach eingabe des Befehls 'qmake checker.pro' erhalten wir das folgende Makefile (schon bereinigt um einige Zeilen, die nur benötigt werden, wenn man --wie es später noch geschehen wird-- qmake benutzt: