Regelbasierte Expertensysteme am Beispiel des Jassens
Samuel Burri (Jg. 85) und Jonas Wagner (Jg. 85) Wettbewerbsarbeit Schweizer Jugend forscht“ ” Bern 2004
Mathematisch- Naturwissenschaftliches Gymnasium Bern-Neufeld Vorwort
Sehr geehrte Leserin, sehr geehrter Leser
Diese Arbeit ist im Jahr 2003 als Maturaarbeit unter der Leitung von Herrn Tobias B¨aum- lin am Gymnasium Bern-Neufeld entstanden. Ziel war es, einen Uberblick¨ uber¨ Exper- tensysteme zu liefern und diese anhand eines Beispielprogramms zum Thema Jassen zu erl¨autern. Falls Sie Anmerkungen, Lob oder Kritik zu dieser Arbeit haben oder einen Fehler bemerken, wurden¨ wir uns freuen, von Ihnen zu h¨oren.
Diese Arbeit kann ebenfalls im Internet unter http://www.acid-code.ch bezogen wer- den. Dort l¨asst sich stets die aktuellste Version und Zusatzmaterial wie zum Beispiel ein grafisches Frontend fur¨ das Jassprogramm finden.
Wir m¨ochten allen Personen danken, die uns unterstutzt¨ haben, insbesondere Herrn Tobi- as B¨aumlin fur¨ seine Hilfe als betreuende Lehrkraft dieser Arbeit. Die grosse Hilfe und die Zustimmung fur¨ das etwas ausgefallene Maturaarbeitsthema sind nicht selbstverst¨andlich. Ein Dank auch den Entwicklern von St¨ock Wyys Stich“, die in ihr Programm viele at- ” traktive Features eingebaut haben. Es diente uns als Referenz zum Testen der Spielst¨arke unseres Expertensystems. Schliesslich danken wir dem AGM AGMuller-Verlag¨ (Neuhau- sen). Er hat uns die Jasskartenbilder in dieser Arbeit zur Verfugung¨ gestellt.
Samuel Burri, Jonas Wagner
2 Vorwort zur sjf-Ausgabe
Sehr geehrte Leserin, sehr geehrter Leser
Ganz ehrlich: Mit einem so grossen Feedback hatten wir nie gerechnet, als wir uns an diese Arbeit machten. Inzwischen sind seit der Abgabe der Arbeit mehr als neun Monate vergangen und wir haben das ehrwurdige¨ Gymnasium Bern-Neufeld verlassen und sind zum Dienst am Vaterland“ eingeruckt.¨ ” Nun der Reihe nach die Stationen auf dem Weg zum Wettbewerb Schweizer Jugend ” forscht“. Zwischen der Abgabe der schriftlichen Arbeit und der mundlichen¨ Pr¨asentation haben wir erfahren, dass unsere Arbeit in die Auswahl der besten Maturaarbeiten aufge- nommen wurde und deshalb besonders begutachtet wurde. So war bei der Pr¨asentation im Dezember 2003 ein Kommitee der Schule anwesend, welches die Qualit¨at der Arbeit zu beurteilen hatte. Die Arbeit wurde schliesslich mit der Bestnote ausgezeichnet.
Im neuen Jahr wurden wir angefragt, ob wir bereit w¨aren, unsere Arbeit im Rahmen einer schweizweiten Pr¨asentation von Maturaarbeiten an der ETH Zurich¨ auszustellen. Wir sagten zu, stellten unsere Arbeit aus und hatten einige interessante Gespr¨ache. Ein wenig sp¨ater wurde unsere Arbeit im Rahmen der Maturfeier unserer Schule mit dem Maturaarbeitspreis 2004“ ausgezeichnet. ” Wenig sp¨ater bekamen wir Post von der Stiftung Schweizer Jugend forscht“. Man schrieb ” uns, unsere Arbeit sei bei der Ausstellung an der ETH Zurich¨ speziell aufgefallen und fragte uns, ob wir bereit w¨aren, beim Wettbewerb von Schweizer Jugend forscht“ mit- ” zumachen. Wir beschlossen, dass dieses Projekt – als Ablenkung – gut in die Milit¨arzeit passen wurde¨ und so meldeten wir uns an.
Nun wunschen¨ wir auch Ihnen, liebe Leserin, lieber Leser, viel Spass beim Lesen dieser zweiten Ausgabe unserer Arbeit Regelbasierte Expertensysteme am Beispiel des Jassens“. ” Samuel Burri, Jonas Wagner
3 Inhaltsverzeichnis
Inhaltsverzeichnis
Vorwort 2
Vorwort zur sjf-Ausgabe 3
Inhaltsverzeichnis 4
1 Einleitung 7
2 Expertensysteme 9 2.1 Allgemeines ...... 9 2.1.1 Wissen ...... 9 2.1.2 Implementierung ...... 10 2.1.3 Anwendungsgebiete ...... 10 2.2 Aufbau ...... 11 2.2.1 Ablauf einer Probleml¨osung ...... 13 2.3 Verschiedene Arten von Expertensystemen ...... 13 2.3.1 Constraintbasierte Expertensysteme ...... 13 2.3.2 Objektbasierte Expertensysteme ...... 14 2.3.3 Fallvergleichende Expertensysteme ...... 14 2.3.4 Diagnose-Expertensysteme ...... 15 2.3.5 Konstruktions-Expertensysteme ...... 16 2.3.6 Simulations-Expertensysteme ...... 16 2.4 Regelbasierte Expertensysteme ...... 16 2.4.1 Verkettung der Regeln ...... 17 2.4.2 M¨achtigkeit der Regelsprache ...... 18 2.4.3 Beliebtheit von Regeln ...... 18
3 Kurze Einfuhrung¨ ins Jassen 20 3.1 Der Schieber ...... 20 3.1.1 Die Karten ...... 21 3.1.2 Die Kartenwerte ...... 21 3.1.3 Trumpf ...... 21 3.1.4 Das Spiel ...... 22 3.1.5 Spieltipps ...... 23
4 Inhaltsverzeichnis
4 Das Projekt 25 4.1 Allgemeines ...... 25 4.2 Vorgehen ...... 25 4.2.1 Die Planung ...... 25 4.2.2 Die Programmierung ...... 26 4.2.3 Regeln und Facts ...... 26 4.3 Aufbau ...... 27 4.3.1 Der Protokollinterpreter ...... 27 4.3.2 Die Geschichte ...... 27 4.3.3 Das Wissen ...... 27 4.3.4 Der Regelinterpreter ...... 28 4.3.5 Der Parser ...... 28 4.3.6 Die Erkl¨arungskomponente ...... 29 4.3.7 Und der ganze Rest ...... 29 4.4 Funktionsweise ...... 29 4.4.1 ladeSkript ...... 30 4.4.2 geber ...... 31 4.4.3 karten ...... 31 4.4.4 trumpfe ...... 31 4.4.5 spieleKarte ...... 32 4.4.6 Parsen von Ausdrucken¨ ...... 32 4.4.7 Erkl¨arungskomponente ...... 34 4.5 Resultat ...... 35 4.5.1 Spielst¨arke ...... 35 4.5.2 St¨arken und Schw¨achen des Skripts ...... 37 4.5.3 Theorie und Praxis ...... 37
5 Folgerungen 39
6 Zusammenfassung 41
7 Quellen und Autorenbezeichnung 42 7.1 Autorenbezeichnung ...... 42 7.2 Literatur ...... 42 7.3 Internetadressen ...... 43 7.4 Computerprogramme ...... 43
5 Inhaltsverzeichnis
A Spezifikation des Kernprogramms 44 A.1 Grunds¨atzliches ...... 44 A.2 Protokoll ...... 44 A.2.1 Formatierung ...... 44 A.2.2 M¨ogliche Kommandos ...... 46 A.2.3 Beispielrunde ...... 51 A.3 Arbeitsweise ...... 52 A.3.1 Speichern der Spielsituation ...... 52 A.3.2 Berechnen eines Zuges ...... 53 A.3.3 Variablen und Konstanten ...... 56 A.3.4 Erkl¨arungskomponente ...... 56
B Die Skriptsprache 58 B.1 Kommentare ...... 58 B.2 Bereiche ...... 58 B.2.1 Konstanten ...... 59 B.2.2 Trumpfen ...... 59 B.2.3 Spielen ...... 59 B.3 Regeln ...... 59 B.3.1 Kernbedingungen ...... 61 B.3.2 Aktionen ...... 61 B.4 Elemente der Ausdrucke¨ ...... 61 B.4.1 Konstanten ...... 61 B.4.2 Variablen ...... 63 B.4.3 Wildcards ...... 63 B.4.4 Facts ...... 64 B.4.5 Spezielles ...... 66 B.5 Zusammenfassung ...... 67 B.6 Das einfachste Skript ...... 67
6 1 Einleitung
1 Einleitung
Das Thema dieser Arbeit kam folgendermassen zu Stande: Wir wollten zusammen ein Spiel analysieren und mit einem Computerprogramm l¨osen. In Betracht gezogen wurde Vier ” Gewinnt“, doch dieses Spiel schien zu einfach und als Thema einer Maturaarbeit schon zu oft gebraucht. So fiel die Idee auf das Jassen. Dieses Spiel war speziell: In der Schweiz be- liebt, der Welt und der Wissenschaft aber weitgehend unbekannt. Und Jassen ist ein Spiel mit unvollst¨andigen Informationen, im Gegensatz zu Spielen wie Vier Gewinnt, Schach oder Muhle.¨ Dort sind alle M¨oglichkeiten des Gegners bekannt, und ein Computer kann das Spiel gewinnen, indem er tausende von m¨oglichen Spielzugen¨ im Voraus berechnet. Beim Jassen hingegen sind nur die eigenen und die bereits ausgespielten Karten bekannt. Das Spiel l¨asst sich also nur schwer durch reine Rechenkapazit¨at knacken, sondern es ver- langt nach einer wissensbasierten L¨osung. Solche Programme heissen Expertensysteme, und damit stand der Titel dieser Arbeit fest.
Die Ziele dieser Arbeit sind:
Als praktischer Teil soll ein Programm entstehen, das einen Schieber nach offiziellen Schweizer Turnierregeln jassen kann. Das Programm soll ausserdem gut jassen k¨onnen, denn schliesslich hat ein Computer gegenuber¨ einem menschlichen Spieler gewisse Vorteile: Er vergisst zum Beispiel keine schon gespielte Karte. Das Wissen zum Jassen soll in Form von Regeln in einem Skript gespeichert sein. Dieses Skript wird vom Programm ausgewer- tet. Das Programm soll sowohl unter Windows wie auch unter Linux ohne Anpassungen funktionieren.
Der theoretische Teil der Arbeit soll die Grundlagen der Expertensystemtechnik behan- deln, Informationen zum Jassen liefern und den praktischen Teil erkl¨aren.
Die folgende Grafik zeigt in ganz groben Zugen¨ die Entstehung der Arbeit:
7 1 Einleitung
Abbildung 1: Stationen der Arbeit von 2002 bis 2005
8 2 Expertensysteme
2 Expertensysteme
2.1 Allgemeines
Expertensysteme sollen ein Problem l¨osen, indem sie das Wissen eines Experten darauf anwenden. Das Ziel ist die Simulation eines Experten. Im Gegensatz zu herk¨ommlichen Programmen, die einen Algorithmus implementieren und damit das Problem l¨osen, sind beim Expertensystem Wissen und Implementierung getrennt.
Viele Informationen in diesem Kapitel sind dem Buch Einfuhrung¨ in Expertensysteme“ ” von Frank Puppe entnommen. Das Buch ist als weiterfuhrende¨ Lekture¨ sehr empfehlens- wert.
Damit der Zusammenhang zwischen Theorie und Praxis sichtbar wird, gibt es in diesem Kapitel viele Verweise zu Kapitel 4, in dem der praktische Teil der Arbeit (Codename REaBJ ) erkl¨art wird.
2.1.1 Wissen
Das Wissen beschreibt, wie man ein Problem l¨osen kann.
Wissen kann in vielen verschiedenen Formen vorliegen. Die Art der Wissensrepr¨asentation ist eines der Unterscheidungsmerkmale von Expertensystemen. Die h¨aufigsten Formen von Wissen in Expertensystemen sind Regeln, Constraints, Objekte und Datenbanken mit Vergleichsf¨allen. Sie werden im Abschnitt Verschiedene Arten von Expertensystemen“ auf ” Seite 13 beschrieben.
Es gibt drei Arten von Wissen, n¨amlich theoretisches Wissen, praktisches, aus Erfahrung gewonnenes Wissen und Allgemeinwissen. Theoretisches Wissen l¨asst sich leicht weiterge- ben und ist damit recht gut fur¨ ein Expertensystem geeignet. Praktisches Wissen ist oft unbewusst. Es fuhrt¨ zu intuitiven Entscheidungen, bei denen sich die Grunde¨ nur schwer angeben lassen. Entsprechend schwierig ist es, einem Expertensystem praktisches Wis- sen zu vermitteln. Einem Expertensystem Allgemeinwissen beizubringen, ist sehr schwer. Deshalb sind Expertensysteme gegenuber¨ Experten im Nachteil, denn ihr Wissen ist klar abgegrenzt.
Das Wissen stammt meistens von einem Experten. Bei grossen Systemen wird der Ex- perte von einem Wissensingenieur unterstutzt.¨ Dieser gewinnt das Wissen vom Experten
9 2 Expertensysteme und wandelt es in die fur¨ das Expertensystem geeignete Form um. An kleinen Systemen wie REaBJ sind nur wenige Personen beteiligt, die dafur¨ Experte, Wissensingenieur und Programmierer zugleich sind. Zur Gewinnung von Wissen gibt es folgende M¨oglichkeiten:
• Der Experte kann sein Wissen einfach erz¨ahlen oder aufschreiben. Das klappt vor allem bei theoretischem Wissen.
• Der Experte kann ein Problem l¨osen und dabei laut denken. So lassen sich die Grunde¨ fur¨ eine Handlung ermitteln.
• Per Interview kann der Wissensingenieur recht gezielt Wissen vom Experten ermit- teln.
• Fur¨ gr¨ossere Expertensysteme gibt es Entwicklungsumgebungen, sogenannte Exper- tensystem-Shells, die ein bequemes Eingeben des Wissens erm¨oglichen sollten.
• Ein bis jetzt noch unerreichtes Ziel sind selbstlernende Expertensysteme. Diese soll- ten sich ihr Wissen selbst aneignen, indem sie z. B. eine Reihe von F¨allen, die ein Experte bereits erfolgreich gel¨ost hat, analysieren.
2.1.2 Implementierung
Die Aufgabe der Implementierung ist es, das Wissen anzuwenden. Die Implementierung h¨angt sehr stark von der Wissensrepr¨asentation ab. Es gibt einige speziell auf Exper- tensysteme zugeschnittene Programmiersprachen wie KL-ONE. Ausserdem eignen sich die allgemeinen Programmiersprachen Lisp und Prolog speziell gut fur¨ Expertensysteme. Grunds¨atzlich kann aber jede Programmiersprache fur¨ ein Expertensystem verwendet wer- den.
2.1.3 Anwendungsgebiete
Expertensysteme werden h¨aufig dort angewendet, wo nur unvollst¨andige Informationen vorhanden sind. Beim Jassen sind zum Beispiel die Karten der anderen Spieler nicht bekannt, so dass ein Berechnen von sehr vielen m¨oglichen Spielsituationen (wie es z. B. beim Schach gemacht wird) sehr aufw¨andig w¨are. Expertensysteme werden auch h¨aufig fur¨ Probleme eingesetzt, fur¨ die es keine bekannten Algorithmen zur L¨osung gibt. Wo eine L¨osung nicht auf mathematischem oder algorithmischem Weg erreicht werden kann, kann das Anwenden von Erfahrungswissen eines Experten ein guter Ansatz sein. Am h¨aufigsten werden Expertensysteme bis jetzt in der Medizin angewendet.
10 2 Expertensysteme
2.2 Aufbau
Abbildung 2: Aufbau eines typischen Expertensystems
Ein Expertensystem besteht typischerweise aus mindestens folgenden Komponenten:
• Wissensinterpreter. Als Hauptteil des Expertensystems wendet er das Wissen auf das Problem an.
• Wissen
• Geschichte. In ihr wird die Problemsituation gespeichert.
• Erkl¨arungskomponente. Dank ihr kann der Benutzer nachsehen, aufgrund von wel- chem Wissen das Expertensystem auf eine L¨osung gekommen ist.
• Schnittstelle zur Eingabe des Wissens und des Problems
• Schnittstelle zur Ausgabe der L¨osung
In Abbildung 2 sind die Komponenten und ihre Beziehungen untereinander dargestellt. Das Wissen ist dort als ein Teil des Wissensinterpreters dargestellt. Das ist m¨oglich, solange das Wissen immer noch separat bearbeitet werden kann und nicht von der Im- plementierung der anderen Komponenten abh¨angt, denn es ist ja eines der Merkmale von Expertensystemen, dass das Wissen vom restlichen System getrennt ist.
11 2 Expertensysteme
Abbildung 3: Ablauf einer Probleml¨osung
12 2 Expertensysteme
2.2.1 Ablauf einer Probleml¨osung
Um zu beschreiben, wie die einzelnen Komponenten zusammenwirken, wurde ein typischer Ablauf einer Probleml¨osung in Abbildung 3 dargestellt. Dabei wurden die Komponenten, die w¨ahrend einem bestimmten Schritt aktiv sind, grau hinterlegt. Die Pfeile zeigen, welche Komponente die Kontrolle uber¨ die Programmausfuhrung¨ hat.
Auch REaBJ folgt diesem Ablauf. Deshalb finden Sie im Abschnitt 4.4 uber¨ dessen Funk- tionsweise ein detailliertes Beispiel zu diesem Thema.
2.3 Verschiedene Arten von Expertensystemen
Expertensysteme werden nach der Art ihrer Wissensrepr¨asentation oder nach der Art der Problemstellung in verschiedene Kategorien eingeteilt.
Vier h¨aufige Wissensformen sind Regeln, Constraints, Objekte und Datenbanken mit Ver- gleichsf¨allen. Regelbasierte Expertensysteme werden in Abschnitt 2.4 beschrieben, denn das Wissen daruber¨ ist fur¨ das Verst¨andnis des praktischen Teils besonders wichtig. Den anderen drei Typen ist weiter unten je ein Unterabschnitt gewidmet.
Aufgrund der Problemstellung teilt man Expertensysteme in diagnostische, konstruierende und simulierende Systeme ein. Details gibt es in den Abschnitten 2.3.4 bis 2.3.6.
2.3.1 Constraintbasierte Expertensysteme
Constraints sind logische Aussagen oder Gleichungen wie Cleo und David sehen immer √ ” zusammen fern.“ oder h = pq“. Der Wissensinterpreter versucht, die Geschichte in ” einen Zustand zu bringen, in dem alle Constraints erfullt¨ sind. Dabei kann er oft fehlende Daten durch Anwenden von Constraints ausrechnen. Zum Beispiel kann in der obigen Gleichung eine Variable ausgerechnet werden, wenn die anderen zwei bekannt sind. Es kann aber vorkommen, dass die vorhandenen Daten nicht ausreichen. Dann muss der Wissensinterpreter versuchen, fur¨ einige Datenelemente alle Werte durchzuprobieren, bis das System aufgeht und alle Constraints erfullt¨ sind.
M¨ogliche Anwendungsgebiete fur¨ Constraints sind die Erstellung von Stundenpl¨anen oder die beliebten Logicals. 1
1Die obige Beispielaussage stammt aus folgendem Logical:
13 2 Expertensysteme
2.3.2 Objektbasierte Expertensysteme
Objektbasierte Expertensysteme speichern Wissen in Form von Objekten, die sich gegen- seitig beeinflussen. Jedes dieser Objekte hat bestimmte Eigenschaften, und jede dieser Eigenschaften beeinflusst andere Objekte auf eine bestimmte Weise. Beispielsweise k¨onn- te die Eigenschaft Regen“ eines Objekts Wetter“ sich auf die Eigenschaft N¨asse“ ei- ” ” ” nes anderen Objektes Strasse“ auswirken, was die Eigenschaft Eignung“ eines Objektes ” ” MichelinReifen“ um 20% senkt und diejenige eines Objektes GoodYearReifen“ um 20% ” ” erh¨oht.
Eine Besonderheit von Objekten ist die Vererbung. Das bedeutet, dass sich neue Objekte von Alten ableiten lassen. Das neue Objekt ist dann eine Spezialisierung des Elternob- jekts. Es erg¨anzt das Alte mit neuen Eigenschaften. Im obigen Beispiel wurde¨ zuerst ein Objekt Reifen“ erstellt, das die allgemeinen Eigenschaften von Reifen zusammenfasst. Die ” beiden Klassen MichelinReifen“ und GoodYearReifen“ wurde¨ man von Reifen“ ableiten ” ” ” und ihnen nur noch die herstellerspezifischen Eigenschaften anfugen.¨ Durch mehrfache Vererbung k¨onnen Wissensingenieure ganze Vererbungshierarchien aufstellen, die dann von der eher abstrakten Basisklasse bis zur hochspezialisierten Kindklasse reichen.
2.3.3 Fallvergleichende Expertensysteme
Das Wissen eines fallvergleichenden Expertensystems besteht aus einer Datenbank, in der eine Reihe von erfolgreich gel¨osten F¨allen zusammen mit deren korrekter L¨osung gespei- chert ist. Ein fallvergleichendes Expertensystem funktioniert ganz einfach: Es vergleicht das Problem mit den F¨allen in der Datenbank und findet eine Reihe von F¨allen, die zu dem vorliegenden ¨ahnlich sind. Die L¨osungen dieser ¨ahnlichen F¨alle kombiniert das Expertensystem zu einer neuen, an das Problem angepassten L¨osung.
Mit funf¨ Aussagen sollen diejenigen Personen herausgefunden werden, die fernsehen. a) Wenn Arnold fernsieht, dann nur mit Betty.
b) Entweder sehen David, Emily oder beide zusammen fern.
c) Entweder Betty oder Cleo sehen fern, aber nie beide zusammen.
d) Cleo und David sehen nur zusammen fern.
e) Wenn Emily fernsieht, schauen auch Arnold und David zu.
(Aus: Pieter von Delft, Jack Botermans (1980): Denkspiele der Welt, 15. Auflage (1997), ISBN 3-88034-087-0, Heinrich Hugendubel Verlag, Munchen¨ 1980)
14 2 Expertensysteme
2.3.4 Diagnose-Expertensysteme
Ein Diagnose-Expertensystem w¨ahlt die Probleml¨osung aus einer Menge von m¨oglichen L¨osungen aus. Der Begriff Diagnose“ stammt ursprunglich¨ aus der Medizin, er wird aber ” allgemein fur¨ diesen Typ der Probleml¨osung verwendet. Beispiele fur¨ Problemstellungen, die gut mit einem diagnostischen Ansatz zu l¨osen sind:
• Die Diagnose von Krankheiten (Das hat diesem Typ von Problemen den Namen gegeben). Hier besteht die Menge von L¨osungen aus den Krankheiten, welche die vom Expertensystem verstandenen Symptome ausl¨osen k¨onnen. Die beste L¨osung ist diejenige Krankheit, die am meisten Symptome erkl¨art und am wenigsten fehlen- de Symptome (Solche, die bei dieser Krankheit typischerweise auftreten, aber vom Patienten nicht gezeigt werden) aufweist. Ein beruhmtes¨ Expertensystem auf diesem Gebiet ist MYCIN2, das bakterielle Infek- tionskrankheiten diagnostiziert. Es wurde in den Siebzigerjahren an der Universit¨at von Stanford entwickelt und gilt als Vater aller Expertensysteme.
• Die Erkennung von Objekten wie z. B. Pilzen. Zur Eingabe geh¨oren Merkmale des Pilzes wie z. B. Farbe und Form des Sch¨osslings, ausgegeben wird der Name des Pil- zes. Auch kann man die Bestimmungsschlussel¨ von Botanikbuchern¨ mit den Regeln von Diagnose-Expertensystemen vergleichen.
• Jassen: Wie bei anderen Diagnose-Systemen macht hier eine Aufteilung der L¨osung in Grob- und Feindiagnosen Sinn: Die Grobdiagnose (z. B. Ausspielen, Leihalten oder Trumpfen) wird zuerst festgelegt. Dazu genugt¨ es manchmal schon, korrekt (also nach den Spielregeln)zu spielen. Danach wird die Grobdiagnose durch Feindia- gnosen verfeinert, zum Beispiel kann Ausspielen unterteilt werden in:
– Trumpf ziehen – Bock spielen – Tiefe Karte spielen, um das Spiel an den Partner zu ubergeben¨
Erst wenn die Feindiagnose feststeht, wird bestimmt, welche Karte gespielt werden soll. Analog wird in der Medizin zuerst Art der Krankheit, dann das verantwortliche Bakterium, dann das zu verordnende Antibiotikum bestimmt.
2Einen guten Artikel uber¨ MYCIN gibts unter http://www.cee.hw.ac.uk/˜alison/ai3notes/chapter2 5.html
15 2 Expertensysteme
Das einzige auf diesem Gebiet bekannte Expertensystem stammt von Samuel Burri und Jonas Wagner und entstand im Rahmen dieser Arbeit.
2.3.5 Konstruktions-Expertensysteme
Die Aufgabe von Konstruktions-Expertensystemen besteht darin, eine optimale L¨osung aus vielen Bestandteilen zusammenzusetzen. Im Gegensatz zur Diagnose ist bei der Kon- struktion die Menge der m¨oglichen L¨osungen zu gross, um davon die richtige auszuw¨ahlen. Konstruktionsprobleme sind im Alltag recht verbreitet und uberall¨ dort anzutreffen, wo ein Produkt aus Komponenten zusammengesetzt wird. So w¨ahlt z. B. ein Veloh¨andler ge- m¨ass den individuellen Anforderungen seiner Kunden an ihr neues Bike die Komponenten Rahmen, Schaltung, Bremsen, Federung, Sattel, Reifen usw. aus.
Ein beruhmtes¨ Expertensystem auf diesem Gebiet ist XCON3. Es erstellte Baupl¨ane von VAX-Computern der Firma DEC gem¨ass den Wunschen¨ der Kunden.
2.3.6 Simulations-Expertensysteme
Simulation bedeutet, aus einem gegebenen Zustand die nachfolgenden Zust¨ande m¨oglichst genau zu berechnen. Der Unterschied zu anderen Problemstellungen ist, dass die Simula- tion kein Ziel in Form eines Endzustandes erreichen soll, sondern das Ziel darin besteht, eine m¨oglichst hohe Genauigkeit beim Berechnen der Folgezust¨ande zu erreichen.
Beispiele fur¨ Simulationsprobleme sind die Wettervorhersage (Gegeben sind Bew¨olkung, Wind, Temperatur und eine Vielzahl weiterer Klimafaktoren; Gesucht ist der Verlauf des Wetters in der n¨achsten Zeit), das Vorhersagen von Aktienkursen, in der Automobil- und Aviatikindustrie die Simulation des Luftwiderstand oder des Verhaltens eines Ver- kehrsmittels bei Zusammenst¨ossen, die Vorhersage des Resultats von chemischen oder physikalischen Experimenten und viele mehr.
2.4 Regelbasierte Expertensysteme
Eine Regel ist eine Anweisung, die aussagt, was in einem bestimmten Fall zu tun ist. Sie hat folgende Form: Wenn etwas erfullt¨ ist, dann fuhre¨ etwas aus. Der erste Teil der Regel (nach dem wenn), enth¨alt Bedingungen. Sind diese alle erfullt,¨ werden die Aktionen im
3Siehe z. B. http://www.cwa.mdx.ac.uk/bis2040/lect6ES2/xCon.html
16 2 Expertensysteme auf dann folgenden Teil der Regel ausgefuhrt.¨ In der Fachsprache heisst das, die Regel ” feuert“. Alle der in Abschnitt 2.3 genannten Typen von Expertensystemen k¨onnen mit Regeln realisiert werden.
2.4.1 Verkettung der Regeln
Es gibt zwei Methoden, um mit einer Menge Regeln zu einem Ziel zu gelangen, n¨amlich Vorw¨arts- und Ruckw¨ ¨artsverkettung. Bei der Vorw¨artsverkettung versucht man, von der Ausgangslage zu einem Resultat zu gelangen. Gegeben ist die vollst¨andige Ausgangslage, gesucht ist eine Schlussfolgerung und die dazugeh¨origen Zwischenresultate.
Der Regelinterpreter sucht zuerst die Regeln, deren Bedingungen durch die Ausgangslage erfullt¨ sind. Er w¨ahlt eine davon aus und feuert sie. Dadurch ergibt sich eine neue Aus- gangslage. Nun beginnt der Regelinterpreter von vorne, sucht neue passende Regeln und fuhrt¨ sie aus. Das tut er so lange, bis er sein Ziel erreicht hat oder bis sich eine Situation ergibt, in der keine Regel mehr greift.
Bei der Ruckw¨ ¨artsverkettung sind die Ausgangslage und ein m¨ogliches Ergebnis (eine Annahme) gegeben. Das System uberpr¨ uft,¨ ob es fur¨ die Ausgangslage korrekt ist. Die Ruckw¨ ¨artsverkettung geht vom Ergebnis aus und wertet nur die relevanten Regeln und Informationen aus. Deshalb muss die Ausgangslage nicht vollst¨andig bekannt sein. Mit Ruckw¨ ¨artsverkettung k¨onnen fehlende Informationen entweder gezielt vom Benutzer er- fragt oder selbst hergeleitet werden. Das ist zum Beispiel sinnvoll, wenn einige Informatio- nen nur durch aufw¨andige Messungen bestimmt werden k¨onnen. In diesem Fall bestimmt das Expertensystem, ob diese Informationen uberhaupt¨ gebraucht werden.
Ruckw¨ ¨artsverkettung funktioniert folgendermassen: Zuerst werden alle Regeln gesucht, deren Aktionen unmittelbar das gegebene Ergebnis bewirken. Von dieser Menge Regeln werden der Reihe nach alle uberpr¨ uft.¨ Hat eine Regel eine unerfullte¨ Bedingung, scheidet sie aus. Sind auf diese Weise alle Regeln aus der Menge ausgeschieden, ist das Ergebnis falsch, denn es kann nicht aus der Ausgangslage hergeleitet werden. Die Bedingungen der verbleibenden Regeln werden weiter uberpr¨ uft.¨ Kann bei einer Bedingung nicht ent- schieden werden, ob sie erfullt¨ ist, so fehlt eine wichtige Information. Entweder kann der Benutzer nach dieser Information gefragt werden, oder das Expertensystem versucht, sie selbst herzuleiten. Dazu wird sie zu einem Zwischenergebnis erkl¨art und – wieder per Ruckw¨ ¨artsverkettung – hergeleitet.
Weil die Regeln nacheinander bearbeitet werden, spielt ihre Reihenfolge eine wichtige
17 2 Expertensysteme
Rolle. Wenn sie sinnvoll geordnet werden, zum Beispiel nach H¨aufigkeit des Feuerns, kann das Expertensystem um einiges effektiver arbeiten.
2.4.2 M¨achtigkeit der Regelsprache
Die Effizienz eines regelbasierten Expertensystems h¨angt stark davon ab, wie m¨achtig die Regelsprache ist, d. h. wie komplizierte F¨alle eine Regel abdecken kann.
Es gibt vier Stufen der M¨achtigkeit. Eine h¨ohere Stufe beinhaltet alle tieferen Stufen und kann kompliziertere F¨alle ausdrucken.¨ Tabelle 2 zeigt die vier Stufen zusammen mit je einem Beispiel. Im Beispiel geht es um Baukl¨otze, die auf einem Tisch stehen.
Fur¨ die meisten Anwendungen reichen Rechnen oder Pattern Matching aus. REaBJ ar- beitet mit einer beschr¨ankten Art Unifikation, bei der die Farbe einer Karte, aber nicht deren St¨arke variabel sein kann. Eine Diskussion der Regelsprache von REaBJ finden Sie in Anhang B.
2.4.3 Beliebtheit von Regeln
Regeln sind die h¨aufigste Wissensrepr¨asentation in Expertensystemen. Folgende Grunde¨ erkl¨aren diese Beliebtheit.
• Regeln sind uns gel¨aufig. Sie kommen auch im Alltag h¨aufig vor und sind fur¨ uns Menschen leicht verst¨andlich.
• In vielen Fachgebieten gibt es schon Wissen in Form von Regeln. Es ist ausserdem nicht schwer, bestehendes Wissen in Regelform auszudrucken.¨
• Regeln eignen sich fur¨ alle drei Problemtypen Diagnose, Konstruktion und Simula- tion.
18 2 Expertensysteme
Stufe Beschreibung Beispiel Einfaches Die unterste Stufe erm¨oglicht einfache Abfra- Ist Klotz Nr. 1 rot? Nachschlagen gen der Datenbasis. Rechnen Auf der zweiten Stufe sind arithmetische Ope- Ist Klotz Nr. 1 mindes- rationen und Rechnen erlaubt. tens doppelt so gross wie Klotz Nr. 2? Pattern Mat- Es k¨onnen variable Ausdrucke¨ benutzt wer- Ist der gr¨osste Klotz ching den, die aber eindeutig sein mussen.¨ Im Bei- auf dem Tisch rot? spiel bezeichnet Der gr¨osste Klotz“ eindeu- ” tig einen Klotz auf dem Tisch. Dieser wird aber nicht mehr durch seine Nummer, sondern durch eine Eigenschaft angesprochen. Auch ist es nicht immer der selbe Klotz, da Kl¨otze vom Tisch weggenommen werden k¨onnen. Unifikation Variable Ausdrucke¨ mussen¨ nicht mehr ein- Gibt es einen runden deutig sein. Im Beispiel geht es um einen Klotz, der rot ist? ” Klotz“, der die zwei Eigenschaften rund“ und ” rot“ hat. Eventuell gibt es sogar mehrere run- ” de rote Kl¨otze. Um einen passenden zu fin- den, muss der Regelinterpreter entweder die runden Kl¨otze nach einem roten durchsuchen oder umgekehrt.
Tabelle 2: Die vier M¨achtigkeitsstufen einer Regelsprache
19 3 Kurze Einfuhrung¨ ins Jassen
3 Kurze Einfuhrung¨ ins Jassen
Da REaBJ lediglich den Schieber spielt, beschr¨ankt sich auch dieses Kapitel darauf. Fur¨ Informationen zu weiteren Jassarten halten Sie sich bitte an die Literatur im Verzeichnis, die uns auch die Quellen zu diesem Kapitel geliefert hat.
3.1 Der Schieber
Der Schieber ist ein Partnerspiel. Es spielen immer 2 Spieler zusammen, die jeweils gegen- uber¨ sitzen. Zu Beginn wird ein Spieler als Spielgeber bestimmt. Dieser verteilt nach dem Mischen und Abheben die 36 Karten in 3 Umg¨angen zu je 3 Karten pro Spieler. Jeder Spieler erh¨alt somit 9 Karten. Gespielt wird ublicherweise¨ – in der Schweiz jedenfalls – im Gegenuhrzeigersinn.
Abbildung 4: v. o. n. u. Schaufel, Ecken, Kreuz, Herz, jeweils vom Ass zur Sechs (Karten- bilder mit freundlicher Genehmigung des AGMuller¨ Verlags Schaffhausen)
20 3 Kurze Einfuhrung¨ ins Jassen
3.1.1 Die Karten
Der Schieber wird mit 36 Spielkarten gespielt, die sich auf vier Farben zu je neun Werten verteilen. Die vier Farben sind Herz, Ecken, Kreuz und Schaufel. Die Werte sind von oben nach unten: Ass, K¨onig, Dame, Bauer, Zehn, Neun, Acht, Sieben, Sechs. In Abbildung 4 sehen Sie die Karten abgebildet. Auf die Beschreibung deutschen Karten4, die vorallem in der Innerschweiz verwendet werden, wird hier verzichtet. Im Kanton Bern haben sich die franz¨osischen Karten durchgesetzt.
3.1.2 Die Kartenwerte
Damit man um etwas spielen kann, haben die Karten einen Gesamtpunktwert von 152. Dazu kommen noch funf¨ Punkte fur¨ die Gewinner des letzten Stichs, was ein Total von 157 Punkten ergibt. Wie sich die Punkte auf die einzelnen Karten verteilen, entnehmen Sie der nachfolgenden Tabelle.
Kartenst¨arke Punkte als Trumpffarbe Normale Punkte Ass 11 11 K¨onig 4 4 Dame 3 3 Bauer 20 2 Zehn 10 10 Neun 14 0 Acht 0 0 Sieben 0 0 Sechs 0 0
3.1.3 Trumpf
Der Spieler rechts des verteilenden Spielers – Vorhand in der Fachsprache – hat die M¨og- lichkeit, die Trumpffarbe zu bestimmen. Die Karten der Trumpffarbe schlagen die Karten der anderen Farben. Die Reihenfolge bei den Trumpfkarten ist etwas anders. Die h¨ochste Karte ist der Trumpfbauer, gefolgt von der Neun, dem Nell. Danach schliessen sich die restlichen Karten in der normalen Reihenfolge an.
4Schelle, Schilte, Rose und Eichel.
21 3 Kurze Einfuhrung¨ ins Jassen
Will oder kann Vorhand nicht trumpfen, so hat er die M¨oglichkeit zu schieben. Mit der Aussage Ich schiebe.“ gibt er das Recht, die Trumpffarbe zu bestimmen, an seinen ihm ” gegenuber¨ sitzenden Partner ab. Dieser ist darauf gezwungen, die Trumpffarbe zu bestim- men. Er muss eine der vier Farben trumpfen.
3.1.4 Das Spiel
Vorhand beginnt das Spiel mit dem Ausspiel der ersten Karte zum ersten Stich. Danach geben die Mitspieler im Gegenuhrzeigersinn ihre Karten dazu, bis alle eine Karte gegeben haben. Der Spieler, der die h¨ochste Karte gespielt hat, nimmt den Stich und damit die Punkte an sich. Das Spielen der Karten wird zum Gluck¨ durch einige Regeln beschr¨ankt:
Leihalten
Als Leihalten“ bezeichnet man die Tatsache, dass man nur Karten der ausgespielten ” Farbe spielen darf. Hat man Karten in der ausgespielten Farbe, so muss eine dieser Karten gespielt, oder aber mit Trumpf eingestochen werden. Untertrumpfen (siehe ubern¨ ¨achster Abschnitt) ist jedoch nicht gestattet, es sei denn man hat nur noch Trumpfkarten.
Trumpfbauer
Der Trumpfbauer bildet bezuglich¨ dem Leihalten“ einen Sonderfall. Er braucht nicht ” gespielt (leigehalten) zu werden.
Untertrumpfen
Wurde ein Stich nicht mit der Trumpffarbe begonnen, aber ein Spieler hat bereits mit Trumpf eingestochen, so ist es den folgenden Spielern verboten, einen tieferen Trumpf zu spielen. Wenn der Spieler jedoch nur noch Trumpfkarten hat, darf er eine beliebige Karte spielen.
Beispiele
Herz ist Trumpf. Spieler 1 spielt die Schaufel Dame aus. Spieler 2 hat nur das Schaufel As und keine Trumpfe.¨ Er muss also das Schaufel As spielen. Spieler 3 hat die Schaufel Acht,
22 3 Kurze Einfuhrung¨ ins Jassen den Schaufel Bauer und die Herz Dame. Er hat die Wahl zwischen den 3 genannten Karten, da Trumpf auch bei anderen Farben gespielt werden darf. Spieler 4 hat keine Schaufel, aber die Herz Acht und einige weitere Karten. Er darf die Herz Acht nur spielen, wenn Spieler 2 nicht die Herz Dame gespielt hat. Ein Untertrumpfen ist nicht gestattet. Er muss stattdessen eine Karte einer anderen Farbe spielen. Spieler 2 gewinnt den Stich, sofern Spieler 3 und Spieler 4 nicht einstechen. Spielt Spieler 3 die Herz Dame gewinnt er den Stich. Kann Spieler 4 die Herz Acht spielen, gewinnt er.
Herz ist Trumpf. Spieler 1 spielt den Herz Bauern aus. Die weiteren Spieler mussen¨ nun Herz geben, sofern sie haben. Ansonsten k¨onnen sie irgendeine Karte spielen.
Herz ist Trumpf. Spieler 1 spielt das Ecken As aus. Spieler 2 sticht mit der Trumpf Zehn ab. Spieler 3 hat nur noch die Trumpf Dame und die Trumpf Sechs. In diesem Fall ist ein Untertrumpfen gestattet. Spieler 3 bleibt nichts anderes ubrig,¨ als eine seiner Trumpfkarten zu spielen. Er hat jedoch die Wahl zwischen der Dame und der Sechs, wobei er hoffentlich die Dame spielt.
3.1.5 Spieltipps
Die Tipps stammen zu grossen Teilen aus den in dieser Hinsicht identischen Buchern¨ Puur, N¨all, As“ und Schweizer Jass-Fuhrer“¨ ” ”
• Vorhand macht selbst Trumpf mit Bauer zu viert, Nell oder As zu funft¨ oder Bauer und Nell und As oder Bauer und Nell und 2 Assen in fremden Farben.
• Er spielt den h¨ochsten Trumpf zum ersten Stich.
• Sind nach dem ersten Stich nur noch 2 Trumpfe¨ ausstehend (die restlichen Trumpfe¨ sind bei Vorhand), wird nur mit guten Bockkarten 5 nochmal Trumpf gezogen. Damit wird vermieden, dass dem Partner unn¨otig ein Trumpf gezogen wird. Vorhand soll in diesem Fall seine st¨arkste Farbe spielen.
• Ein einzelner ausstehender Trumpf wird nur gezogen, falls sicher ist, dass der Gegner diesen besitzt.
• Gibt ein Gegner bereits im ersten Stich keinen Trumpf, wird nicht weiter Trumpf gezogen. Nur bei guten Bockkarten wird weiter Trumpf gespielt.
5Als Bockkarten werden Karten bezeichnet, die nur durch Trumpf geschlagen werden k¨onnen. Beispiels- weise Asse. K¨onige werden zu Bockkarten, nachdem die betreffenden Asse gespielt wurden.
23 3 Kurze Einfuhrung¨ ins Jassen
• Steht nur noch die (nun) h¨ochste Trumpfkarte aus, wird nicht mehr weiter Trumpf gezogen. Besitzen die Gegner diese, werden sie damit auf jeden Fall einen Stich machen.
• Damit der Partner weiss, wo sein Mitspieler stark ist, verwirft dieser Karten von schwachen Farben. Hat Vorhand seine Bockkarten gespielt, wird er eine Karte der Farbe spielen, die sein Partner nicht verworfen hat, um diesen damit ins Spiel zu bringen.
• Besitzt Vorhand den Trumpfbauer solo, so spielt er eine tiefe Karte seiner st¨arksten Farbe, also Sechs bis Neun.
• In allen anderen F¨allen spielt er den h¨ochsten Trumpf.
• Bei einem geschobenen Spiel hat Vorhand so bald als m¨oglich das Spiel seinem Partner zu uberlassen.¨
• Fur¨ weitere Tipps und Taktiken halte man sich an die im Anhang aufgefuhrten¨ Literaturquellen.
• Es erscheint selbstverst¨andlich, dass bei einem Stich, der sicher dem Partner geh¨ort, m¨oglichst eine Karte von hohem Wert gespielt werden sollte (Schmieren in der Fachsprache).
24 4 Das Projekt
4 Das Projekt
Nun endlich zum wichtigsten Teil, dem Kernstuck¨ dieser Arbeit. Das Ziel war es, ein Programm zu schreiben, das mit Hilfe eines regelbasierten Expertensystems den Schieber jasst. Um es nicht allzu kompliziert werden zu lassen, haben wir uns schliesslich darauf beschr¨ankt, das Programm nur einzelne Spiele spielen zu lassen. Unn¨otiges, wie Weise und St¨ocke6, haben wir weggelassen. Trotzdem spielt REaBJ den Schieber nach aktuellen Turnierregeln. Dort werden solche Gluckspunkte¨ n¨amlich ebenfalls nicht gez¨ahlt.
4.1 Allgemeines
Wie bereits anget¨ont spielt das Programm den Schieber mit Turnierregeln. Das vereinfacht durch das wegfallende Weisen und die einfachere Z¨ahlweise den Aufwand enorm. REaBJ ist ein Programm auf Konsolenbasis, welches durch seine Standardkonformit¨at ohne Pro- bleme auf jede Plattform portiert werden kann, fur¨ die ein C++-Compiler vorhanden ist. Das Programm kommuniziert mittels eines dafur¨ entworfenen Protokolls auf Textbasis mit dem Benutzer oder sogar mit anderen Programmen, wie beispielsweise grafischen Fron- tends. Durch das Wegfallen der Entwicklung einer GUI7 konnten wir uns besser um den eigentlichen Kern, die KI8, in Form eines regelbasierten Expertensystems kummern.¨
4.2 Vorgehen
Dieser Abschnitt beschreibt, wie wir beim Planen und Programmieren dieser Arbeit vorge- gangen sind. In der Einleitung k¨onnen Sie an der Zeitleiste die Reihenfolge der wichtigsten Punkte nachsehen, deshalb wird hier nur auf Spezielles eingegangen.
4.2.1 Die Planung
Die Planung kommt zuerst. Der erste Teil der Planung bestand darin, die F¨ahigkeiten des Programms festzulegen und eine Vorstellung daruber¨ zu erhalten, wie diese realisiert werden sollten. Danach fing die Programmierung an, doch wir kamen nicht weit. Der Code
6Weis / St¨ocke: Gluckspunkte“¨ fur¨ spezielle Kartenkombinationen. Besitzt ein Spieler z. B. drei aufein- ” anderfolgende Karten einer Farbe, erh¨alt er 20 Punkte 7Graphical User Interface, Grafische Benutzerschnittstelle 8Kunstliche¨ Intelligenz
25 4 Das Projekt wurde verworfen und es wurde noch mal geplant. Diesmal wurden die Anforderungen an das Programm genau dokumentiert.
4.2.2 Die Programmierung
Zuerst schrieb Jonas eine erste Version des Protokollinterpreters. Danach erstellte Samuel innerhalb einer Woche die restlichen unbedingt notwendigen Komponenten des Systems, in dieser Reihenfolge:
• Regelinterpreter (RI) mit (zun¨achst wirkungslosen) Funktionen zum Spielen und Trumpfen
• Funktionen zum Laden eines Skripts
• Parser zum Auswerten der Regeln
Parallel zu den anderen Klassen wurde die Geschichte programmiert, und schliesslich wurden weitere Komponenten wie die Erkl¨arungskomponente hinzugefugt.¨
4.2.3 Regeln und Facts
Dem bisherigen Programm fehlte aber noch der entscheidende Teil: Die sinnvollen Regeln, um das Programm dazu zu bringen, dass es nicht wahllos mit Karten um sich wirft, son- dern dass es vernunftig¨ Jassen kann. Dazu braucht es Regeln. Es stellte sich nun die Frage, wie die Regeln aus dem Skript auf dem Programm bekannte Tatsachen zugreifen k¨onnen. Hier kommen die Facts ins Spiel. Facts stellen die Schnittstelle zwischen der Geschichte und dem Skript her. Facts sind einfache Funktionen, die Ganzahlparameter annehmen k¨onnen und eine Ganzzahl als Ergebnis zuruckliefern.¨ Ein Fact nimmt zum Beispiel eine Farbe als Argument und liefert die Anzahl der Handkarten der entsprechenden Farbe. Alle dabei beteiligten Konstanten werden zur Auswertung in Ganzzahlen verwandelt. Weiter stehen dem Skript eine Reihe von Programmkonstanten (Werte fur¨ Karten und Farben) und Wildcards9 zur Verfugung,¨ die ein angenehmeres Programmieren erm¨ogli- chen, indem zum Beispiel nicht jede Farbe einzeln gepruft¨ werden muss. Die Regeln und Facts entstanden am Schluss des Programmierprozesses. Wir uberlegten¨ die Regeln, und wenn wir fur¨ die Verwirklichung Facts brauchten, wurden diese fortlaufend implementiert. 9Ein Wildcard ist ein Wert, der fur¨ verschiedene Dinge stehen kann. Beispielsweise passt BAUER1 auf jeden Bauern, aber zugleich passt BAUER2 nur auf einen anderen Bauern. Ausfuhrlichere¨ Erkl¨arungen liefert die Dokumentation zur Skriptsprache im Anhang B.
26 4 Das Projekt
4.3 Aufbau
Beim Aufbau des Expertensystems kommen in weiten Teilen die Elemente aus Abbildung 2 wieder zum Vorschein. Durch die objektorientierte Programmierung schlagen sich diese Elemente in den verschiedenen Klassen nieder. Anschliessend eine kurze Erkl¨arung zu den wichtigsten Komponenten.
4.3.1 Der Protokollinterpreter
Der Protokollinterpreter, kurz PI, stellt die Schnittstelle zum Menschen vor der Maschine dar. Er kummert¨ sich um Ausgaben auf die Konsole und um die Eingaben des Benut- zers. Der PI interpretiert das gesammte Protokoll, leitet die eingegebenen Befehle an die zust¨andigen Module ( meistens an den Regel-Interpreter (RI)), weiter und sorgt fur¨ die Darstellung der Ausgabe. S¨amtliche Ein- und Ausgabe l¨auft uber¨ den PI mit dem dafur¨ entwickelten Protokoll ab. Die Spezifikationen des Protokolls finden sich im Anhang A.
4.3.2 Die Geschichte
In der Geschichte werden alle zum Spielablauf notwendigen Daten gespeichert. Dazu ge- h¨oren neben der Trumpffarbe und dem Geber des aktuellen Spiels auch Dinge wie die etablierten Diagnosen und die vom Skript deklarierten Variablen. Daneben wird in der Geschichte der ganze Spielablauf gespeichert. (Zum Beispiel: Wer welche Karte wann ge- spielt hat und ob geschoben worden ist.) Die Geschichte hat Methoden, die es erlauben, neue Karten einzufugen.¨ Die Karten werden dabei automatisch an der richtigen Stelle eingefugt¨ und wenn n¨otig wird der n¨achste Stich vorbereitet. Auf die Geschichte wird von fast allen Komponenten des Expertensystems zugegriffen.
4.3.3 Das Wissen
Das Wissen des Expertensystems befindet sich in einer Datei, die Regeln in Textform ent- h¨alt. Dazu wurde im Rahmen dieser Arbeit eine einfache Programmiersprache entworfen, die vom Programm interpretiert werden kann. Die Regeln werden aufgeteilt in Trumpfre- geln (Regeln, um den Trumpf zu bestimmen) und Spielregeln (Regeln, um eine Karte zu spielen). Jede Regel besteht aus folgenden Teilen:
• Titel Der Titel der Regel wird unter anderem in Fehlerbeschreibungen verwendet.
27 4 Das Projekt
• Beschreibung Die Beschreibung wird in der Erkl¨arungskomponente gebraucht.
• Priorit¨at Jede Regel hat eine Priorit¨at. Kleine Priorit¨aten werden zuerst ausgewer- tet.
• Grobdiagnosen Die Konfiguration der Grobdiagnosen. Teil der Bedingungen fur¨ das Ausfuhren¨ der Regel.
• Feindiagnosen Die Konfiguration der Feindiagnosen. Ebenfalls Teil der Bedingun- gen fur¨ das Ausfuhren¨ der Regel.
• Kernbedingungen Die Kernbedingungen. Sie k¨onnen unter anderem Facts enthal- ten. Sie werden zu einem logischen Ausdruck ausgewertet, der den letzten Teil der Bedingungen fur¨ das Feuern der Regel darstellt.
• Aktionen Die Aktionen, die ausgefuhrt¨ werden, wenn die Regel feuert. Sie k¨onnen auch die Regel fur¨ die laufende Auswertung abschalten.
Neben den Regeln k¨onnen im Skript noch Konstanten definiert werden. Die Spezifikationen der Skriptsprache finden sie im Anhang B.
4.3.4 Der Regelinterpreter
Der Regelinterpreter (RI) bildet den Kern des Expertensystems. Er ist zust¨andig fur¨ das Laden des Skriptes und fur¨ das Auswerten der Regeln. Der RI l¨adt die Regeln aus der Datei und pruft¨ dabei, ob das Skript korrekt ist. Es wird aber keine inhaltliche Analy- se durchgefuhrt,¨ sondern lediglich versucht, die Regeln zu lesen und zu speichern. Wird dabei bereits ein Fehler bemerkt, bricht der RI das Laden mit einer entsprechenden Feh- lermeldung ab. Die Konstanten und Priorit¨aten der Regeln werden bereits w¨ahrend des Ladens der Regeln ausgewertet. Diese Daten mussen¨ also bereits feststehen. Der RI besitzt Methoden, um das Skript zur Bestimmung des Trumpfes oder zum Spielen einer Karte auszuwerten.
4.3.5 Der Parser
Der Parser ist eigentlich Teil des RI. Er wurde wegen seiner betr¨achtlichen Zahl an Me- thoden in eine eigene Klasse ausgelagert. Der Parser ist dazu da, Ausdrucke¨ unserer Re- gelprogrammiersprache auszuwerten. Im Wesentlichen sind das mathematische Ausdrucke¨
28 4 Das Projekt mit einigen Spezialit¨aten, wie zum Beispiel Facts und Variablen. Der Parser leistet die Hauptarbeit im Expertensystem. Er wird fur¨ das Auswerten der Kernbedingungen wie auch fur¨ das Ausfuhren¨ der Aktionen gebraucht. Eine weitere Aufgabe des Parsers ist es, Fehlermeldungen zu erstellen, falls fehlerhafte Skriptstucke¨ angetroffen werden. Der Par- ser arbeitet mit rekursivem Abstieg. Dazu gibt es mehr Informationen im Kapitel 4.4.6 uber¨ die Funktionsweise.
4.3.6 Die Erkl¨arungskomponente
Die Erkl¨arungskomponente (EK) bildet den letzten gr¨osseren Teil des Expertensystems. Sie kann den Ablauf des gesamten Spiels und der Auswertung der Regeln aufzeichnen und sp¨ater in eine Datei schreiben oder auf dem Bildschirm ausgeben. Sie kann unter anderem speichern, welche Grobdiagnosen etabliert, welche Regeln gefeuert und welche Karten gespielt wurden. Dazu besitzt die Erkl¨arungskomponente einige Methoden zum Eingetragen der Ereignisse. Uber¨ Flags kann man den Detailgrad der Ausgabe praktisch beliebig einstellen, um die Informationen den eigenen Bedurfnissen¨ anzupassen.
4.3.7 Und der ganze Rest
Neben den Hauptkomponenten geh¨oren naturlich¨ einige Helferklassen und Funktionen genauso zu einem Expertensystem. Das sind haupts¨achlich Klassen, welche kleinere Dinge kapseln (Diagnosen zum Beispiel) oder reine Speicherklassen, um die Informationen besser verwalten zu k¨onnen. Auch unz¨ahlige Hilfsfunktionen geh¨oren dazu. Der Grossteil dieser Funktionen dient dazu, die Bits und Bytes des Computers in Schriftstucke¨ zu verwandeln, die von Menschen verstanden werden, und entsprechend um die Eingaben in eine fur¨ den Computer einfachere Form, in Zahlenform, zu bringen.
4.4 Funktionsweise
In diesem Abschnitt geht es um die Funktionsweise der verschiedenen Komponenten und wie diese zusammenarbeiten. Ein Lesen dieses Abschnitts ist fur¨ das Verst¨andnis des Quellcodes sehr hilfreich. Der Abschnitt wurde so geschrieben, dass er auch fur¨ Personen mit wenig bis keiner Programmiererfahrung verst¨andlich sein sollte. Trotzdem werden einige Fachbegriffe nicht zu vermeiden sein.
29 4 Das Projekt
Die Beschreibung der Funktionsweise wird einem normalen Ablauf des Programms folgen. Damit ist sichergestellt, dass man weiss, wie der Code durchlaufen wird. Es wird damit einfacher, die Funktionsweise selber nachzuvollziehen.
Der Einstiegspunkt findet sich in der Hauptdatei jassexpert.cpp. Mit der Abarbeitung der Funktion main beginnt die Ausfuhrung¨ des Programms. Das einzige, was dort ge- schieht, ist das Aufrufen der Methode run der Klasse des Expertensystems, eS. Damit befindet sich die Programmausfuhrung¨ in unserem das Expertensystem repr¨asentierenden Objekt. Dieses Objekt beinhaltet s¨amtliche Teile des gesamten Expertensystems.
Von dieser Methode wird das Geschehen noch eine Ebene nach unten verlagert, n¨amlich in die Methode run des Protokollinterpreters, pI.
In dieser Funktion schliesslich befindet sich die Hauptschleife, die auf Eingaben wartet und, sobald diese gelesen wurden, die Antworten berechnet und ausgibt. Wurde eine komplette Zeile eingegeben, wird diese zuerst von uberfl¨ ussigen¨ Leerzeichen ges¨aubert. Danach wird die Zeichenkette bei der Klammer getrennt und in Befehlsname und Parameter aufgeteilt. Geht alles glatt, so werden anschliessend die verschiedenen Kommandos unterschieden und behandelt. Ansonsten wird bereits vom PI eine Fehlermeldung zuruckgeliefert.¨ Wurde das Kommando fertig behandelt und die Antwort ausgegeben, f¨angt der Zyklus beim Einlesen einer Zeile wieder an. Nachfolgend werden die Kommandos und ihre Wirkungen in ihrer naturlichen¨ Reihenfolge n¨aher erl¨autert.
4.4.1 ladeSkript
Auf diesen Befehl hin uberpr¨ uft¨ der PI, ob nicht bereits ein Skript geladen wurde. Wenn das nicht der Fall ist, wird in einer anderen Funktion des PI namens ladeSkript der Parameter analysiert. ladeSkript verlangt wenn n¨otig den Dateinamen vom Benutzer. Dann wird die Aufgabe des Ladens an den Regelinterpreter weitergereicht, genauer gesagt an die Funktion ladeSkript des RI.
In dieser Funktion schliesslich wird die Datei ge¨offnet, der Inhalt gelesen und nach Entfer- nen der Kommentare in einem String zwischengespeichert. Dann beginnt die eigentliche Arbeit, das Analysieren des Inhalts. Jedes Skript beginnt mit einem begin, auf das ein Bezeichner fur¨ einen Bereich folgt. Diese Bereiche werden alle separat behandelt.
Der Bezeichner Konstanten sorgt dafur,¨ dass in die Methode leseKonstanten verzweigt wird, wo die Konstanten gelesen werden. Diese Funktion kehrt erst zuruck,¨ wenn das Ende des Bereichs Konstanten gelesen wurde. In leseKonstanten werden die Konstanten eine
30 4 Das Projekt nach der anderen gelesen und ausgewertet. Als Erstes wird der Bezeichner der Konstanten gelesen, danach kommt ein Gleichheitszeichen und danach der Wert in Form eines ma- thematischen Ausdrucks, der nur andere Konstanten erhalten darf. Zur Auswertung des Wertes wird der Parser gebraucht, dessen Funktionsweise im Abschnitt 4.4.6 erkl¨art wird.
Fur¨ die zwei anderen Bezeichner Trumpfregeln und Spielregeln wird die selbe Funktion aufgerufen, da sich nur der Speicherort der Regeln unterscheidet. Es wird die Funktion leseRegeln des RI aufgerufen. Dort werden die Regeln bis zum Ende des Bereichs ein- gelesen und gespeichert. Die einzelnen Teile der Regeln werden sequenziell gelesen und verarbeitet. Die Priorit¨at wird vom Parser ausgewertet und kann Konstanten erhalten, die Diagnosen werden mit dem zugeh¨origen Status (etabliert oder nicht etabliert) gespeichert und die Kernbedingungen und Aktionen werden als Zeichenketten gespeichert.
Ist das Lesen der Regeln ohne Fehler vonstatten gegangen, wird eine entsprechende Er- folgsmeldung ausgegeben, ansonsten eine passende Fehlermeldung.
4.4.2 geber
Mit diesem Befehl wird der Geber des Spiels und damit auch der trumpfmachende Spieler ermittelt und das Ergebnis in der Geschichte eingetragen.
4.4.3 karten
Auf diesen Befehl hin liest das Programm seine Karten ein und speichert sie in der Ge- schichte.
4.4.4 trumpfe
Nach diesem Befehl uberpr¨ uft¨ das Programm, wer am Trumpfen ist. Ist es nicht das Programm, so wird die Trumpffarbe eingelesen, andernfalls wird vom RI die Trumpffarbe erfragt. Dazu wird die Funktion trumpfe des RI aufgerufen.
Dort werden als erstes die Variablen und Diagnosen gel¨oscht und alle Trumpfregeln ak- tiviert. Danach werden immer wieder die Regeln durchlaufen, bis der Trumpf feststeht. Dazu werden als Erstes die Regeln zum Trumpfen uberpr¨ uft¨ und eine anwendbare Regel gesucht. Eine Regel ist anwendbar, wenn die bereits etablierten Diagnosen mit den For- derungen der Regel ubereinstimmen¨ und die Kernbedingungen erfullt¨ sind. Um das zu
31 4 Das Projekt uberpr¨ ufen,¨ wird die Funktion bedingungErfuellt des Parsers fur¨ diese Regel aufgeru- fen. Der Parser analysiert die Bedingungen und wenn sie zu wahr ausgewertet werden, ist die Regel anwendbar. Die erste anwendbare Regel, das heisst die anwendbare Regel der h¨ochsten Priorit¨at, wird daraufhin ausgewertet.
4.4.5 spieleKarte
Der Befehl spieleKarte wird ¨ahnlich wie der Befehl trumpfe verarbeitet. Zuerst wird festgestellt, ob das Programm oder ein anderer Spieler am Zug ist. Ist ein anderer Spieler am Zug, wird dessen gespielte Karte verlangt. Ansonsten wird die Funktion spieleKarte des RI aufgerufen.
In dieser Funktion wird wie in der Funktion trumpfe zuerst eine anwendbare Regel gesucht (diesmal aus den Regeln zum Spielen), und dann die Regel ausgewertet. Dieser Vorgang wird wiederholt, bis das Ergebnis, die zu spielende Karte, feststeht. Sollte einmal keine Regel anwendbar sein, so gibt der RI eine entsprechende Fehlermeldung aus.
4.4.6 Parsen von Ausdrucken¨
Unter Parsen versteht man das Auswerten eines in einer bestimmten Sprache vorliegen- den Ausdrucks. Hier soll nun erkl¨art werden, wie dies funktioniert. Bei REaBJ mussen¨ Ausdrucke¨ ausgewertet werden, welche die Kernbedingungen und die Aktionen der Regeln ausmachen.
Das Grundprinzip soll an einem Parser erkl¨art werden, der nur Zahlen, die Addition sowie die Multiplikation verarbeiten kann. Wichtig ist dabei, dass selbstverst¨andlich die Rangfolge der Operatoren beachtet werden soll. Man kann also nicht, wenn man auf einen Operator trifft, die Zahlen links und rechts lesen und dann verknupfen.¨ Der Ausdruck 10 + 2 ∗ 3 wurde¨ sonst zu 12 ∗ 3 und weiter zu 36 ausgewertet. Richtig ist jedoch 16. REaBJs Parser arbeitet nach dem Prinzip des rekursiven Abstiegs. Dies soll jetzt am oben genannten Beispiel erkl¨art werden. Ausdrucke¨ in dieser einfachen Sprache kann man auch einfach rekursiv definieren nach dem folgenden Schema:
Ausdruck −→ Summand [+Summand] Summand −→ Faktor [∗Faktor] Faktor −→ Zahl
32 4 Das Projekt
Fur¨ jede Ebene existiert nun eine Funktion, welche diese Ebene auf die n¨achsttiefere Ebene zuruckf¨ uhren¨ kann. Wir nennen diese Funktionen folgendermassen:
• Summe
• Produkt
• Zahl
Zum Auswerten wird nun der Ausdruck in seine Bestandteile (in diesem Fall Operatoren und Zahlen) zerlegt und die Funktion Summe wird aufgerufen.
Da zu Beginn der Auswertung keine Summe gebildet werden kann, wird die Funktion Produkt aufgerufen und diese ruft aus demselben Grund die Funktion Zahl auf. Zahl liest das aktuelle Token10 und wandelt es in den entsprechenden Zahlenwert um. Danach ist die Arbeit von Zahl getan und die Funktion kehrt zuruck¨ zu Produkt.
Produkt uberpr¨ uft,¨ ob das nun aktuelle Token ein ∗ ist und somit ein Produkt berechnet werden musste.¨ Wir nehmen an, das aktuelle Token sei ein + und die Funktion kehrt zuruck.¨
Die Funktion Summe sieht das + und beginnt folglich mit der Auswertung der Addition. Der erste Summand wurde bereits von Zahl uber¨ Produkt geliefert und wird gespeichert. Der zweite Summand kann laut unserer Definition aus einem Faktor bestehen. Folglich wird die Funktion Produkt aufgerufen.
Produkt hat noch keinen ersten Faktor, also wird Zahl aufgerufen. Zahl wandelt das Token um und kehrt zuruck.¨ Produkt sieht das nun auszuwertende ∗ und liest dieses ein. Durch einen Aufruf von Zahl wird der zweite Faktor umgewandelt. Produkt verknupft¨ nun die beiden Faktoren und kehrt, da kein weiteres ∗ mehr vorhanden ist, zuruck.¨
Jetzt gelangt der Programmfluss wieder zu Summe, welches auf den zweiten Summanden wartete. Jetzt k¨onnen die beiden Summanden addiert werden und da kein weiteres + folgt, wird das Ergebnis dem Aufrufer zuruckgeliefert.¨
Der Ausdruck wurde also von links nach rechts unter Beachtung der Rangfolge der Ope- ratoren ausgewertet. Zum besseren Verst¨andnis noch eine kleine Grafik zur Illustration:
10Als Token wird eine untrennbare Einheit eines Ausdrucks bezeichnet. Hier also Zahlen und Operatoren
33 4 Das Projekt
Abbildung 5: Ablauf eines einfachen Parsingvorgangs
Weitere Operatoren werden ihrer Rangfolge entsprechend in diese Kette eingefugt.¨ Fur¨ eine Klammer zum Beispiel wird bei jedem Auftreten die Auswertung neu bei der niedrigs- ten Priorit¨at begonnen. Kehrt die Auswertung dann zuruck,¨ muss der ganze Ausdruck in der Klammer berechnet worden sein und die schliessende Klammer aufs Auslesen warten.
Der Parser in unserem Expertensystem bearbeitet alle in Tabelle 3 dargestellten Opera- toren entsprechend ihrer Rangfolge. Konstanten, Variablen und Facts (Funktionen mit Ausdrucken¨ als Parametern) werden wie Zahlen behandelt und entsprechend umgewan- delt. Alle Zahlenwerte werden intern mit 32 Bit Ganzzahlen dargestellt. Das entspricht einem Wertebereich von ca. -2’000’000’000 bis +2’000’000’000.
4.4.7 Erkl¨arungskomponente
Bei allen fur¨ die Erkl¨arung wichtigen Ereignissen wird die Erkl¨arungskomponente uber¨ eine Memberfunktion informiert. Die Erkl¨arungskomponente kann dann ihre gespeicherten Informationen uber¨ den Befehl eKSpeichern in eine Datei schreiben oder mit eKAusgeben auf dem Bildschirm ausgeben.
34 4 Das Projekt
() Klammern ! ~ Negation bzw. bitweises not + - Vorzeichen */% Multiplikation, Division, Modulo + - Addition, Subtraktion << >> bitweises Shifting < <= > >= Vergleichsoperatoren == != gleich, ungleich & bitweises and ^ bitweises xor | bitweises or && logisches und || logisches oder = += -= *= /= %= (kombinierte) Zuweisungsoperatoren <<= >>= |= &= ^=
Tabelle 3: Die vom Parser verarbeiteten Operatoren
4.5 Resultat
Ein Ziel des Projekts war, ein Computerprogramm zu schreiben, das den Schieber jasst. Dieses Ziel wurde erreicht, und dabei entstand eine erste Erkenntnis: Das Projekt musste so einfach wie m¨oglich bleiben und klar auf seine Ziele fokussiert sein, um uberhaupt¨ realisiert werden zu k¨onnen. Deshalb spielt REaBJ den Schieber, und nur den Schieber. Alle zus¨atzlichen Regeln wurden weggelassen.
4.5.1 Spielst¨arke
Eine gute Spielst¨arke zu erreichen, war ein weiteres Ziel. Wurde es erreicht? Dazu ein paar Bewertungen:
REaBJ spielt uber¨ dem Niveau eines gehobenen Anf¨angers“ ” Aus der Laudatio zum Maturaarbeitspreis 2004
REaBJ verliert gegen St¨ock Wyys Stich auf Stufe schwer mit durchschnittlich 73.67 zu 83.23 Punkten.
35 4 Das Projekt
Die Spielst¨arke muss verbessert werden. Das Programm macht viele Fehler.“ ” Peter Hammer, Experte von SJf
Wie man sieht, ist eine objektive Bewertung der Spielst¨arke sehr schwierig.
Ein wichtiger Aspekt ist, dass REaBJ immer gleich spielt. Seit Februar 2005 ist es zwar m¨oglich, im Skript aus mehreren Alternativen zuf¨allig eine auszuw¨ahlen, doch bis jetzt macht noch kein Skript davon Gebrauch. Menschliche Gegner durchschauen deshalb nach einigen Spielen die Eigenheiten des Skripts und k¨onnen dadurch z. B. Ruckschl¨ usse¨ auf die Karten des Programms ziehen. Ausserdem macht Jassen so auch weniger Spass.
Nicht ins Gewicht f¨allt dies bei anderen Computerprogrammen als Gegner. Um da einen objektiven Vergleich anstellen zu k¨onnen, wurden 1000 automatisierte Spiele gegen das Programm St¨ock Wyys Stich durchgefuhrt.¨ St¨ock Wyys Stich eignet sich durch seine transparente Programmierung und die vielen Einstellm¨oglichkeiten recht gut dazu.
Abbildung 6: Punkteverteilung des trumpfenden Teams
Wie aussagekr¨aftig sind 1000 Spiele? Das h¨angt vor allem davon ab, wie stark die Punkte gestreut sind, das heisst wie viele Punkte von den zuf¨allig verteilten Karten abh¨angen. Um das herauszufinden, wurden 10’000 Spiele zwischen gleich starken Jassprogrammen durchgefuhrt¨ und die Punkteverteilung fur¨ das trumpfende Team analysiert. Abbildung 6 zeigt, dass die Punkte beim Jassen sehr stark gestreut sind. Durchschnittlich erreicht das trumpfende Team rund 108 Punkte, in ca. 5% aller F¨alle gibt es einen Match. Die Standardabweichung der Punkte betr¨agt ca. 30. Diese Angabe ist jedoch mit Vorsicht zu geniessen, da es sich nicht um eine Normalverteilung handelt. Trotzdem kann man daraus schliessen, dass die Abweichung vom korrekten Resultat bei 1000 Spielen noch h¨ochstens 2 Punkte betr¨agt.
36 4 Das Projekt
Das Resultat zeigt, dass St¨ock Wyys Stich auf Stufe schwer deutlich mit 83.3 zu 73.7 Punkten gewinnt. Der auff¨alligste Unterschied in der Spielweise ist, dass REaBJ nur in einem Drittel aller Spiele selbst trumpft, w¨ahrend dies bei St¨ock Wyys Stich immerhin bei 44% der Spiele der Fall ist.
4.5.2 St¨arken und Schw¨achen des Skripts
REaBJ spielt nicht in allen Bereichen des Schiebers gleich gut. Das h¨angt vor allem damit zusammen, was fur¨ eine Art von Wissen besonders ben¨otigt wird.
Gut beherrscht das Programm die Bestimmung der Trumpffarbe. Fur¨ dieses Problem braucht man nur auf die eigenen Karten zu achten; es gibt keine schon gespielten Karten oder Karten des Gegners, die eine wichtige Rolle spielen. Ausserdem l¨asst sich das Wissen dank den Wildcards (Unifikation, siehe Abschnitt 2.4.2) einfach ausdrucken.¨
Weniger gut beherrscht das Programm den Umgang mit den Zehnern. Durch deren hohen Wert bei geringer St¨arke entstehen viele Spezialf¨alle. Als sehr schwierig herausgestellt hat sich der Umgang mit den Trumpfkarten. Hier muss das Programm gut absch¨atzen, wer noch Trumpfe¨ hat und wann ein Stich wertvoll genug ist zum Abstechen.
Recht gut geht das Programm mit Bockkarten um: Der Computer erledigt das Z¨ahlen der schon gespielten Karten, also weiss das Programm, welche Karten Bock sind. Um damit auszuspielen oder einen Stich zu nehmen, genugt¨ es, den Stich fur¨ sich zu betrachten. Anders beim Zusammenspiel mit dem Partner: hier muss das Programm zuruckschauen,¨ welche Farben der Partner angespielt oder verworfen oder laufen gelassen hat. Das ist im Skript recht kompliziert und wird vom Programm nicht so gut gemacht.
4.5.3 Theorie und Praxis
Das dritte Ziel der Arbeit war, in in einem theoretischen Teil einen Uberblick¨ uber¨ Ex- pertensysteme zu vermitteln und den praktischen Teil zu erkl¨aren. Ruckblickend¨ stellt man fest, dass REaBJ erstaunlich genau den theoretischen Prinzipien eines Expertensys- tems folgt: Alle typischen Komponenten eines Expertensystems findet man als Klassen im Quellcode wieder. Das Wissen in Form von Regeln ist getrennt vom restlichen System und fur¨ alle Benutzer einsehbar. Der Regelinterpreter arbeitet die Regeln nach der klassischen Vorw¨artsverkettung ab.
37 4 Das Projekt
Ein grosses Gluck¨ war, dass sich die Problemstellung so gut fur¨ ein Expertensystem eigne- te. Dies liess sich am Anfang noch schlecht absch¨atzen – auch wegen fehlender Erfahrung auf dem Gebiet. Doch auch da findet man viele der Kriterien fur¨ Expertensysteme aus der Theorie in der Problemstellung dieser Arbeit wieder.
38 5 Folgerungen
5 Folgerungen
Naturlich¨ haben wir nicht nur viel Spass mit der Verwirklichung dieses Projekts gehabt, sondern auch einiges gelernt. Was das gewesen ist, daruber¨ soll Sie dieses Kapitel infor- mieren.
W¨ahrend wir am Anfang nur sehr wenig uber¨ Expertensysteme wussten, haben wir inzwi- schen einiges mehr uber¨ sie erfahren. Ein Expertensystem ist ein Hilfsmittel, um Entschei- dungen zu treffen, wo herk¨ommliche Algorithmen versagen oder sie zu aufw¨andig sind. Aber auch Expertensysteme lassen sich nicht fur¨ alles einsetzen. Das Wissen, wie man ein Problem l¨ost, muss bereits vorhanden sein. Die Schwierigkeiten bei der Entwicklung eines Expertensystems bestehen also nicht darin, Algorithmen zu finden, sondern in der Implementierung des bereits vorhandenen Wis- sens. Dem Computer muss beigebracht werden, wo er das Wissen finden kann und wie es anzuwenden ist. Das ganze Wissen ist unbrauchbar, wenn es dem Computer nicht auch beigebracht werden kann.
Dieser Punkt, dem Computer das Wissen beizubringen, stellt eine der gr¨osseren Schwie- rigkeiten bei der Entwicklung eines Expertensystems dar. Ein Computer arbeitet (noch) nicht wie ein menschliches Gehirn. Das Wissen muss in eine fur¨ ihn verst¨andliche Form gebracht werden. Da der Computer nur mit Zahlen rechnen kann, muss das Wissen ir- gendwie sinnvoll in Zahlenform gebracht werden.
Der zweite Knackpunkt ist die Aufgabe, dem Computer verst¨andlich zu machen, wie das nun vorliegende Wissen zu interpretieren ist. Der Computer muss wissen, wo er die Antwort auf die gestellte Frage finden kann. Auch das Problem muss fur¨ den Computer zun¨achst verst¨andlich gemacht werden. Schliesslich muss der Computer das Ergebnis noch weitergeben k¨onnen, sei es an eine weitere Maschine oder an den Menschen. Soll die Antwort von einem Menschen verstanden werden, muss sie auch von der Zahlenform des Computers in eine fur¨ den Menschen verst¨andliche Form umgewandelt werden. Kann man diese Aufgaben bew¨altigen, ist man in der Lage, ein uberaus¨ leistungsf¨ahiges Computerprogramm zu entwickeln. Das Durchrechnen von unz¨ahligen M¨oglichkeiten, wie es manche klassische Algorithmen (zum Teil auch sinnvoll) machen, entf¨allt. Ein Exper- tensystem geht bei der Suche nach der L¨osung gezielt vor. Durch das im Expertensystem vorhandene Wissen ist es unn¨otig, alles durchzurechnen. Man braucht nur das Wissen nach L¨osungen fur¨ das vorgelegte Problem abzusuchen.
39 5 Folgerungen
Dieser Vorteil gegenuber¨ normalen Algorithmen macht ein Expertensystem, wenn ver- nunftig¨ implementiert, zu einem unglaublich leistungsf¨ahigen System. Dem Expertensys- tem stehen Anwendungsbereiche offen, die herk¨ommliche Algorithmen nicht erschliessen k¨onnen.
Zu den Nachteilen eines Expertensystems z¨ahlt ohne Zweifel die Tatsache, dass das Wis- sen klar begrenzt ist. Expertensysteme sind noch nicht in der Lage, selbstst¨andig Wissen zu erwerben. Was nicht einprogrammiert wurde, ist dem System unbekannt. Lernende Systeme sind allenfalls sehr primitive vorhanden. Um zu lernen, ben¨otigen sie gel¨oste F¨alle in einer fur¨ sie verst¨andlichen Form oder die Aufsicht eines echten Experten, der ihnen sagt, was richtig und was falsch ist. Diese Methode des Wissenerwerbs ist aber auch nur dann m¨oglich, wenn das Feld der Ausgangssituationen und der L¨osungen bekannt ist. Diese Methode eignet sich beispielsweise, um Expertensystemen das Spielen von einfa- chen Brettspielen oder das Erkennen von Handschriften beizubringen. Diese Systeme sind aber bei weitem nicht so elegant wie von Hand erstellte Systeme. H¨aufig wird bei diesen Systemen zu viel unnutzes¨ Wissen gesammelt und gespeichert.
Damit ein Expertensystem mit einem echten Experten konkurrenzieren kann, fehlt aber noch mehr. Ein Expertensystem ist zwar unter Umst¨anden sehr brauchbar auf dem Gebiet, fur¨ das es entworfen wurde. Daruber¨ hinaus versteht es aber gar nichts. Zum echten Experten fehlt nicht nur das Allgemeinwissen, sondern h¨aufig auch die F¨ahigkeit, minime Unterschiede in der Situation zu erkennen und auch die Umwelt zu beachten.
Dies kann aber auch ein Vorteil sein. Entscheidet doch das Expertensystem immer v¨ollig unvoreingenommen, so wie es programmiert wurde. Es kann h¨ochstens durch den Wissens- ingenieur vorg¨angig beeinflusst worden sein.
Bei der Arbeit an unserem System stellte sich schliesslich das Erstellen der Regeln als am aufw¨andigsten heraus. Die Schwierigkeit lag also darin, unser Wissen genau genug in die von unserem Programm verstandene Textform zu bringen. Das Programmieren stellte sich zuletzt als nicht sehr aufw¨andig heraus. Die Schwierigkeiten lagen vor allem bei der Fehlersuche. Der Fehler musste immer im Skript und auch im Programm gesucht werden. Ein gutes Skript nutzt¨ nichts, wenn es vom Programm falsch verstanden wird.
Aber aller Hurden¨ zum Trotz haben wir das Programm fertig gestellt und am Ergebnis kann zweifelsfrei festgestellt werden, dass ein Expertensystem in der Lage ist, uberdurch-¨ schnittlich zu jassen. Und wer die Spielst¨arke nicht annehmbar findet, dem steht es frei sie zu verbessern. Die Trennung von Wissen und Implementation machts m¨oglich.
40 6 Zusammenfassung
6 Zusammenfassung
In dieser Zusammenfassung werden wir nochmals kurz berichten, was wir im Rahmen dieser Arbeit alles gemacht haben.
Das Ziel bestand darin, ein Expertensystem zu entwerfen, das den Schieber jassen kann. Zuerst haben wir geplant, noch Dinge wie das Weisen und mehr Trumpfarten (Unde- nufe, Obenabe) zu integrieren. Wir sahen aber, dass das dann wohl doch einen Tick zu aufw¨andig, wenn auch nicht unl¨osbar geworden w¨are.
Wir begannen dann damit, uns allgemein uber¨ Expertensysteme zu informieren und Li- teratur zum Thema zu beschaffen, um den theoretischen Teil uber¨ Expertensysteme zu erarbeiten. Praktisch zeitgleich begann auch die Planungsarbeit am Computerprogramm, da wir hier schon eine recht genaue Vorstellung hatten, was wir machen wollten.
Nachdem die Planungsarbeit abgeschlossen war, begannen wir, die Aufgaben zu verteilen. Jeder bekam mindestens einen gr¨osseren und einen oder mehrere kleine Teile zu schreiben und zu programmieren. Beim Programmieren war es dann auch so, dass der Eine arbeitete, w¨ahrend der Andere in den Ferien war. Dadurch kam es nicht zu Konflikten. In der Schlussphase, als es auch ans Erstellen der Regeln ging haben wir uns zusammen vor einen Computer gesetzt und gemeinsam am Programm gearbeitet.
Da wir zu zweit arbeiteten, gab es auch weniger Fehler. Man musste immer daran denken, dass der Partner den Code und den Text auch verstehen muss. Durch das gegenseiti- ge Durchlesen des Textes und des Codes konnten auch viele Fehler korrigiert werden. Als Team motivierten wir uns gegenseitig. So erg¨anzten wir uns immer wieder sehr gut. Mindestens einer wusste immer, was gerade zu tun war.
Nun ist die Arbeit fertig und man darf die Ergebnisse begutachten. Unser Ziel haben wir erreicht, wie man dieser Arbeit und dem Programm entnehmen kann. Das Programm wurde fertig gestellt. Nicht zuletzt hatten wir w¨ahrend der Arbeit an diesem Projekt auch eine Menge Spass. Das gleiche wunschen¨ wir Ihnen, wenn sie mal gegen unser Programm spielen oder wenn Sie es sogar es als Partner einsetzen.
Am Programm wird von uns nach Lust und Laune weitergearbeitet. Die Internetseite des Projekts auf http://www.acid-code.ch wird Sie uber¨ Neuerungen informieren.
41 7 Quellen und Autorenbezeichnung
7 Quellen und Autorenbezeichnung
7.1 Autorenbezeichnung
Bei einer Maturaarbeit, die von mehreren Personen verfasst wird, muss bei jedem Teil klar sein, wer ihn verfasst hat. In der folgenden Tabelle finden Sie deshalb diese Angaben.
Kapitel Autor Vorwort Jonas Wagner Vorwort zur sjf-Ausgabe Samuel Burri 1 Einleitung Jonas Wagner 2 Expertensysteme Jonas Wagner 3 Kurze Einfuhrung¨ ins Jassen Samuel Burri 4 Das Projekt Samuel Burri 4.5 Resultat Jonas Wagner 5 Folgerungen Samuel Burri 6 Zusammenfassung Samuel Burri 7 Quellen und Autorenbezeichnung Samuel Burri und Jonas Wagner A Spezifikation des Kernprogramms Jonas Wagner B Die Skriptsprache Samuel Burri
7.2 Literatur
In der n¨achsten Tabelle finden Sie die von uns fur¨ diese Arbeit verwendeten Werke.
• G¨opf Egg (1969): Puur N¨all As: Offizielles Schweizer Jassreglement, 8. Auf- lage (2002), ISBN 3-905219-96-4, AGM AGMULLER,¨ Bahnhofstrasse 21, CH-8212 Neuhausen am Rheinfall
• Hans Reutemann (1983): Schweizerisches Jassreglement, 10. Auflage (2002), ISBN 3-85898-002-9, Schweizer Wirteverband Fachverlag, Gotthardstrasse 61, CH- 8027 Zurich¨
• Ernst Marti (1995): Schweizer Jass-Fuhrer¨ , 1. Auflage (1995), ISBN 3-259-03290- 8, Hallwag Kummerly+Frey¨ AG, Grubenstrasse 109, CH-3322 Sch¨onbuhl¨
42 7 Quellen und Autorenbezeichnung
• Frank Puppe (1991): Einfuhrung¨ in Expertensysteme, 2. Auflage (1991), ISBN 3-540-54023-7, Springer Verlag (Studienreihe Informatik), Berlin Heidelberg New York
7.3 Internetadressen
Auch das Internet hat uns bei der Informationsbeschaffung geholfen.
• http://www.ai-depot.com Ein Portal fur¨ kunstliche¨ Intelligenz.
• http://www.cee.hw.ac.uk/˜alison/ai3notes/chapter2 5.html Ein Skript von Alison Cawsey zu ihrer Vorlesung uber¨ Expertensysteme
7.4 Computerprogramme
Nachfolgend die Angaben zu den in unserer Arbeit erw¨ahnten Computerprogrammen:
• Christoph Wirth, Ambros Marzetta, Matthias Muller¨ und Ralph Gasser (1997): St¨ock Wyys Stich Gold, ISBN 3-907485-12-2, Optobyte AG, Wohlen
• Michael Gasser (2003): Swiss Jass!!, http://www.swissjass.ch
43 A Spezifikation des Kernprogramms
A Spezifikation des Kernprogramms
A.1 Grunds¨atzliches
Dies sind die Spezifikationen des Kernprogramms der Maturaarbeit von Samuel Burri und Jonas Wagner zum Thema Regelbasierte Expertensysteme am Beispiel des Jassens“. ” Das Kernprogramm soll einen einzelnen Spieler simulieren. Das Programm spielt nur ein- zelne Runden. Dazu erh¨alt es neun Karten und bekommt seine Position am Tisch relativ zum Spielgeber mitgeteilt. Das Programm geht davon aus, dass die Eingaben korrekt sind. Danach wartet das Programm auf Anweisungen vom Benutzer. Die Anweisungen werden auf Konsistenz mit dem Status des Programms gepruft¨ und bei Nichtubereinstimmung¨ wird ein Fehler ausgegeben.
Die Interaktion mit dem Benutzer l¨auft nach dem Client-Server-Prinzip. Das Programm nimmt Befehle entgegen und gibt anschliessend eine Statusmeldung aus. Der Benutzer ist also der Client, der befiehlt. Das Programm selbst erteilt keine Befehle.
Das Programm interagiert uber¨ die Konsole mit dem Benutzer. Es benutzt ein festgelegtes Protokoll. Dieses ist dafur¨ ausgelegt, dass es sowohl fur¨ den Benutzer verst¨andlich ist, aber auch die Umleitung von Standardein- und Ausgabe erm¨oglicht, also die Bedienung durch ein anderes Programm erlaubt.
A.2 Protokoll
A.2.1 Formatierung
Grunds¨atzlich benutzt das Protokoll nur Zeichen mit ASCII-Werten 32 - 127, um Imple- mentierungsproblemen vorzubeugen.
Kommandos
Die Syntax der Kommandos gleicht sich an die Syntax der Skriptsprache an: Kommandos werden grunds¨atzlich wie C++-Funkionsaufrufe geschrieben. Allf¨allige Parameter werden in die Klammern nach dem Befehlsnamen geschrieben. Konstante Parameter wie z. B. Kartennamen werden komplett in Grossbuchstaben geschrieben. Ein Kommando wird mit einem Strichpunkt abgeschlossen. Wird eine Zeile durch endl“ abgeschlossen, wird ”
44 A Spezifikation des Kernprogramms der Befehl ausgewertet und eine Reaktion ausgegeben. Es ist nur ein Befehl pro Zeile erlaubt.
Antworten
Die Antwort besteht aus einer Textzeile, abgeschlossen durch ’\n’. Die ersten drei Zei- chen der Antwort bestehen aus einem Statusindikator, einem Doppelpunkt und einem Leerzeichen. Danach folgt die eigentliche Antwort. In Ausnahmef¨allen kann die Antwort aus mehr als einer Textzeile bestehen; in diesem Fall wird das durch einen Statusindikator angedeutet.
Statusindikator
Jede Antwort hat als erstes Zeichen einen Statusindikator. Dieser kann folgende Werte annehmen:
• +: Dieses Zeichen leitet eine Best¨atigungsnachricht ein. Diese Nachricht besagt lediglich, dass das Programm alles verstanden hat, was eingegeben worden ist. Sie muss eigentlich nicht beachtet werden.
• -: Mit diesem Zeichen wird eine Fehlermeldung eingeleitet. Das heisst, das Pro- gramm hat irgendwas nicht verstanden, ein Parameter war falsch oder einer war zuviel, oder es gab sonst ein Problem.
• !: Dieses Zeichen zeigt an, dass das Programm etwas ausgefuhrt¨ hat. Es hat zum Beispiel eine Karte gespielt oder die Trumpffarbe gew¨ahlt. Der Rest der Zeile zeigt an, was das Programm genau gemacht hat.
• |: Dieser Indikator leitet eine mehrzeilige Antwort ein. Die ersten Zeilen einer solchen Antwort beginnen mit diesem Statusindikator, die letzte Zeile zeigt dann mit einem der obenstehenden Indikatoren die Art der Meldung an. Mehrzeilige Ant- worten sollten eigentlich nur bei fatalen Fehlern oder klar bestimmten Befehlen vorkommen.
Allgemeine Antworten
• -: Ungueltiger Befehl:
45 A Spezifikation des Kernprogramms
wenn er falsch geschrieben worden ist oder mit einem Grossbuchstaben beginnt. Eventuell versuchte der Benutzer, einen Parameter einzugeben, als das Programm schon wieder einen Befehl erwartete.
• -: Ungueltiger Parameter:
• -: Ungueltiger Parameter: Ich bin am Zug. Ein spieleKarte-Befehl wurde fur¨ einen Spieler eingegeben, der nicht an der Reihe ist. Es ist nicht erlaubt, vorzuspielen oder zwei Karten zu spielen.
• -: Befehl
A.2.2 M¨ogliche Kommandos ladeSkript
Parameter: Name der zu ladenden Datei (in Anfuhrungszeichen,¨ sofern n¨otig)
Antworten:
• +:
• -: Konnte Datei
• |: Fehler im Skript. -:
Beispiele:
• B: ladeSkript(/home/jassfan/jassexpert/skript.in); P: +: 58 + 60 Regeln geladen.
• B: ladeSkript(C:\Pfad\MeinSript.skript); P: -: Konnte Datei C:\Pfad\MeinSript.skript nicht oeffnen
46 A Spezifikation des Kernprogramms geber
Beschreibung: Mit diesem Befehl wird dem Programm angegeben, wer die Karten ver- teilt. Das Programm berechnet danach die Position des trumpfenden Spielers und den Spieler, der jeweils am Zug ist.
Parameter: Der einzige Parameter ist die Position des Gebers. Diese kann LINKS, PRO- GRAMM, RECHTS oder GEGENUEBER sein.
Antworten:
• -: Ungueltige Position:
• +: Spieler LINKS gibt aus, ich bestimme den Trumpf.
• +: Ich gebe aus, Spieler RECHTS bestimmt den Trumpf.
• +: Spieler
Parameter: Neun Karten. Eine Karte wird folgendermassen angegeben. Der Erste Buch- stabe bezeichnet die Farbe: H = Herz, K = Kreuz, E = Ecken und S = Schaufel. Die Fol- genden 1 bis 2 Zeichen stehen fur¨ den Wert der Karte: 6 bis 10, B = Bauer, D = Dame, K = K¨onig, A = As.
Antworten:
• +: Alle Karten erhalten.
• -: Ungueltige Karte:
Falls eine Fehlermeldung ausgegeben wird, mussen¨ alle neun Karten noch einmal einge- geben werden.
47 A Spezifikation des Kernprogramms trumpfe
Beschreibung: Dieser Befehl ubergibt¨ dem Programm die Trumpffarbe. Wenn das Pro- gramm am trumpfen ist, fordert der Befehl das Programm auf, jetzt den Trumpf zu bestimmen.
Parameter: Der erste Parameter ist die Trumpffarbe. Die kann sein: HERZ, SCHAUFEL, KREUZ oder ECKEN. Der Parameter darf nicht angegeben werden, wenn das Programm den Trumpf bestimmt.
Antworten:
• +: Spieler
• +: Spieler
• !: Ich trumpfe
• !: Ich trumpfe GESCHOBEN.
• -: Ungueltige Trumpffarbe:
• -: Ungueltige Trumpffarbe: Zwei mal GESCHOBEN
• -: Ungueltiger Parameter. Ich trumpfe. spieleKarte
Parameter: Der einzige Parameter ist die Karte, die der Spieler, der am Zug ist, spielt. (Zum Format der Karten siehe Abschnitt A.2.2) Wenn das Programm am Zug ist, muss der Parameter fehlen. Stattdessen gibt das Programm als Antwort die Karte, die es spielt.
Antworten:
• +: Spieler
• !: Ich spiele
• -: Ungueltige Karte:
• -: Ungueltiger Parameter. Ich bin am Zug.
48 A Spezifikation des Kernprogramms eKSpeichern
Parameter: Als Parameter erwartet eKSpeichern einen Dateinamen, wenn n¨otig in An- fuhrungszeichen.¨ In diese Datei wird der Inhalt der Erkl¨arungskomponente gespeichert.
Antworten:
• +: Erklaerungskomponente in
• -: Fehler beim Oeffnen der Datei! eKAusgeben
Dieser Befehl erwartet keine Parameter. Als Antwort gibt er den Inhalt der Erkl¨arungs- komponente aus. setzeEKFlags
Parameter: Als Parameter werden beim Befehl setzeEKFlags die Flags fur¨ die Erkl¨a- rungskomponente angegeben. Sie werden durch Leerzeichen getrennt. Die Flags geben den Detailgrad an, der bei der Ausgabe der Erkl¨arungskomponente verwendet wird. M¨ogliche Flags sind:
• GEFEUERTE_REGELN Die gefeuerten Regeln werden ausgegeben.
• DIAGNOSEN Alle etablierten und gel¨oschten Diagnosen werden ausgegeben.
• SPIELVERLAUF Infos zum Spielverlauf wie gespielte Karten und die Trumpffarbe werden ausgegeben.
• REGEL_BESCHREIBUNG Von allen gefeuerten Regeln wird zus¨atzlich zum Titel (wenn GEFEUERTE_REGELN gesetzt ist) noch die Beschreibung ausgegeben.
Standardm¨assig sind die ersten zwei Flags gesetzt.
49 A Spezifikation des Kernprogramms
Antworten:
• +:
• -: Ungueltiges Flag:
Im letzten Fall werden - falls mehrere Flags angegeben worden sind - alle gultigen¨ Flags gesetzt, die vor dem ungultigen¨ angegeben worden sind. loescheEKFlags
Parameter: Wie beim Befehl setzeEKFlags.
Antworten
• +:
• -: Ungueltiges Flag:
Im letzten Fall werden - falls mehrere Flags angegeben worden sind - alle gultigen¨ Flags gel¨oscht, die vor dem ungultigen¨ angegeben worden sind. quit
Beschreibung: Beendet das Programm.
Antworten:
• +: Bye!
50 A Spezifikation des Kernprogramms
A.2.3 Beispielrunde
Dies ist eine Beispielrunde, die zeigt, wie das Protokoll eingesetzt wird. Alle mit B: be- ginnenden Zeilen sind Eingaben des Benutzers, alle mit P: beginnenden Zeilen Ausgaben des Programms.
B: hallo(); P: -: Ungueltiger Befehl: hallo() B: ladeSkript(skript1.in); P: +: 25 + 47 Regeln geladen. B: geber(GEGENUEBER); P: +: Spieler GEGENUEBER gibt aus, Spieler LINKS bestimmt den Trumpf. B: karten(H7 KA KK K7 ED SB S10 S9 S8); P: +: Alle Karten erhalten. B: trumpfe(ECKEN); P: +: Spieler LINKS trumpft ECKEN. B: spieleKarte(EB); P: +: Spieler LINKS spielt EB. B: spieleKarte(E7); P: +: Spieler GEGENUEBER spielt E7. B: spieleKarte(EA); P: +: Spieler RECHTS spielt EA. B: spieleKarte(E6); P: -: Ungueltiger Parameter: Ich bin am Zug. B: spieleKarte(); P: !: Ich spiele ED. B: spieleKarte(E9); P: +: Spieler LINKS spielt E9. ...
Bemerkungen In den beiden Zeilen 1 und 17 wurden Fehleingaben gemacht, um die Reaktionen des Programms zu demonstrieren.
51 A Spezifikation des Kernprogramms
A.3 Arbeitsweise
A.3.1 Speichern der Spielsituation
Geschichte
Die aktuelle Runde wird in einer Geschichte (History) gespeichert. Sie enth¨alt
• Alle Karten, die das Programm in der Hand hat
• Die Trumpffarbe
• Die Karten, die gespielt worden sind
• Vom Benutzer deklarierte Variablen
• Etablierte Zwischendiagnosen
• Benutzerkonstanten
Die Geschichte muss dem Programm folgendes erlauben:
• Die Spielsituation einzugeben
• Auf die einzelnen Variablen zuzugreifen
• Neue Variablen zu setzen
• Zwischendiagnosen einzufugen¨
• Konstanten zu setzen
Facts
Der Zweck der Facts ist, die Daten in der Geschichte vorzuinterpretieren, das heisst eine Form der Daten bereitzustellen, die besser fur¨ die Bearbeitung durch die Regeln geeignet ist. Zum Beispiel kann ein Messwert in eine Kategorie wie zu hoch, hoch, normal etc. eingeteilt werden. Oder ein Fact berechnet aus den gespielten Karten die Anzahl der schon gespielten Trumpfe.¨ Die Facts mussen¨ folgende Anforderungen erfullen:¨
• Sie berechnen, auf der Geschichte aufsetzend, neue Werte
• Diese Werte mussen¨ vom Programm aus den Regeln heraus abgefragt werden k¨on- nen.
52 A Spezifikation des Kernprogramms
A.3.2 Berechnen eines Zuges
Die Zuge,¨ die das Programm spielt, werden von einem regelbasierten Expertensystem berechnet. Dafur¨ ist der Regelinterpreter (RI) zust¨andig. Er l¨adt zu Beginn ein Skript mit Regeln. Danach geht er diese Regeln durch, bis feststeht, welche Karte gespielt werden soll. Details dazu weiter unten im Abschnitt.
Regelinterpreter
Der Regelinterpreter interpretiert verschiedene Gruppen von Regeln, um Aufgaben wie z. B. die Bestimmung der Trumpffarbe oder das Spielen einer Karte zu l¨osen. Er ist ein Diagnose-Regelinterpreter, da er eine L¨osung (z. B. die Trumpffarbe) aus vielen m¨oglichen L¨osungen ausw¨ahlt.
Vorw¨artsverkettung
Die Regeln werden nach dem Prinzip der Vorw¨artsverkettung interpretiert. Das funktio- niert folgendermassen:
1. Der Regelinterpreter sucht alle Regeln, deren Bedingungen erfullt¨ sind.
2. Von diesen Regeln wird gem¨ass einer Konfliktl¨osungsstrategie (Siehe n¨achster Ab- schnitt) eine ausgew¨ahlt. Daraufhin werden alle Aktionen dieser Regel ausgefuhrt.¨
3. Danach beginnt der Regelinterpreter wieder von vorne, das heisst er sucht wieder nach zutreffenden Regeln, feuert eine davon usw. Das tut er so lange, bis entweder
a) Von keiner Regel mehr die Bedingungen erfullt¨ sind. In diesem Fall ging bei der Definition der Regeln etwas schief, da es n¨amlich einen Fall gibt, der von keiner Regel abgedeckt wird. Das Expertensystem hat also eine Wissenslucke.¨ b) Die L¨osung des Problems feststeht. Dies kann die Karte sein, die gespielt wird, oder die Farbe, die getrumpft wird. Der Regelinterpreter muss naturlich¨ mer- ken, wann er aufh¨oren muss. Das wird mit sogenannten abschliessenden Aktio- nen implementiert. Diese Aktionen sind trumpfen und spielen einer Karte.
53 A Spezifikation des Kernprogramms
Konfliktl¨osungsstrategie
Es existieren diverse M¨oglichkeiten fur¨ eine Konfliktl¨osungsstrategie:
• Eine der einfachsten M¨oglichkeiten ist, einfach die erste Regel zu feuern, deren Be- dingungen erfullt¨ sind. Dadurch hat eine Regel, die weiter vorne im Skript steht, automatisch die h¨ochste Priorit¨at.
• Jede Regel besitzt eine Priorit¨at. Der Interpreter fuhrt¨ dann die Regel mit der h¨ochsten Priorit¨at aus.
• Der Regelinterpreter fuhrt¨ die Regel aus, die die Spielsituation am genauesten wie- dergibt. Das ist meistens die Regel mit den meisten Bedingungen.
• Diejenige Regel wird ausgefuhrt,¨ die am aktuellsten ist, das heisst deren Bedingun- gen erst seit kurzer Zeit erfullt¨ sind. Diese Form der Konfliktl¨osung ist aber recht aufw¨andig zu implementieren.
• Es gibt auch noch die M¨oglichkeit, die Regeln so zu designen, dass immer nur von einer Regel gleichzeitig die Bedingungen erfullt¨ sein k¨onnen.
Unser einfaches Expertensystem verf¨ahrt nach der zweiten Konfliktl¨osungsstrategie. Je- de Regel enth¨alt also eine Priorit¨at. Bei gleichen Priorit¨aten ist die Reihenfolge nicht bestimmt.
Regeln
Die Regeln sind eines der wichtigsten Elemente am regelbasierten Expertensystem. Grund- s¨atzlich bestehen die Regeln aus Bedingungen und Aktionen. Wenn von einer Regel die Bedingungen erfullt¨ sind, sollen die Aktionen ausgefuhrt¨ werden. Die Aussagekraft und Effizienz der Bedingungen und Aktionen tr¨agt viel zur Effizienz des gesamten Experten- systems bei. Es gibt verschiedene Stufen der M¨achtigkeit einer Regelsprache.
1. In der untersten Stufe sind bei den Bedingungen einfache Abfragen der Datenbasis erlaubt. Die Regel kann nur uberpr¨ ufen,¨ ob etwas wahr ist.
2. Die zweite Stufe erlaubt zus¨atzlich das Rechnen mit arithmetischen Operationen.
54 A Spezifikation des Kernprogramms
3. Sogenanntes Pattern Matching. Eine Aktion k¨onnte dann lauten: Spiele die h¨ochste Karte der Farbe Herz. Der Regelinterpreter hat dann die Aufgabe, herauszufinden, welche der Handkarten genau gemeint ist.
4. Die h¨ochste Stufe ist die Unifikation (Variablen, die nicht mit einer Konstanten initialisiert werden mussen)¨
Siehe Abschnitt 2.4.2 der Maturaarbeit fur¨ mehr Infos betreffend der M¨achtigkeit der Regelsprache.
Unser Expertensystem implementiert Stufe 3 (Pattern Matching). Patterns sind als Facts implementiert. Ausserdem wird eine beschr¨ankte Form von Unifikation mit Wildcards implementiert. Fur¨ mehr Infos siehe die Beschreibung der Skriptsprache in Anhang B.
Folgendes sind die Anforderungen an Regeln. Regeln enthalten:
• Eine Liste von Bedingungen
• Eine Liste von Aktionen
• Einen Titel
• Eine Beschreibung (fur¨ die Erkl¨arungskomponente. Siehe Abschnitt A.3.4)
• Eine Priorit¨at
Zwischendiagnosen
Zwischendiagnosen sind Mittel, um das Problem in kleinere Schritte zu zerlegen und um die Regeln zu strukturieren. Die meisten Regeln sind nur gultig,¨ wenn eine oder mehrere bestimmte Zwischendiagnosen etabliert sind. Anhand der Zwischendiagnosen sieht man den aktuellen Stand der Berechnungen. Zwischendiagnosen bleiben bis zum Ende der Berechnung der zu spielenden Karte gultig,¨ ausser sie werden explizit in einer Aktion gel¨oscht.
Bedingungen
Eine Regeln enth¨alt Bedingungen. Die Anforderungen an die Bedingungen sind:
55 A Spezifikation des Kernprogramms
• Bedingungen mussen¨ zu einem Wahrheitswert ausgewertet werden k¨onnen. Ein Wert ungleich null bedeutet wahr, null bedeutet falsch.
• Sie k¨onnen arithmetische Operationen und Ausdrucke¨ wie die h¨ochste Karte“ ent- ” halten (Wie im Abschnitt Regeln beschrieben).
• Sie k¨onnen auf Konstanten und Variablen des Skripts sowie auf Facts zugreifen.
Aktionen
Aktionen werden ausgefuhrt,¨ wenn von einer Regel alle Bedingungen wahr sind. Regeln k¨onnen mehrere Bl¨ocke mit Aktionen haben, die jeweils mit einer bestimmten Wahrschein- lichkeit ausgefuhrt¨ werden. Aktionen k¨onnen:
• Variablen setzen und ver¨andern,
• Diagnosen etablieren und l¨oschen,
• arithmetische Funktionen und Pattern Matching brauchen,
• Funktionen, z. B. zum Spielen einer Karte, aufrufen.
A.3.3 Variablen und Konstanten
Siehe auch den entsprechenden Abschnitt in der Beschreibung der Skriptsprache auf Sei- te 63. Variablen und Konstanten werden intern in einer map
A.3.4 Erkl¨arungskomponente
Die Erkl¨arungskomponente dient dazu, das Resultat des Regelinterpreters zu dokumen- tieren. Sie ist einfach ein Verlauf, in den alle gefeuerten Regeln und alle etablierten Zwi- schendiagnosen eingetragen werden. Die Eintr¨age werden vom Regelinterpreter und vom Protokollinterpreter gemacht. Der Inhalt der Erkl¨arungskomponente kann sp¨ater ausgege- ben oder in ein Logfile geschrieben werden. Anforderungen an die Erkl¨arungskomponente:
56 A Spezifikation des Kernprogramms
• Aktionen mussen¨ eingetragen werden k¨onnen.
• Der Interpreter muss eintragen k¨onnen, wann welche Diagnosen gesetzt und wieder gel¨oscht worden sind.
• Der Verlauf muss ausgegeben werden k¨onnen.
• Verschiedene Verbose-Level sollten unterstutzt¨ werden, so dass man z. B. von einer Regel nur den Namen oder den Namen und die Beschreibung ausgeben kann.
57 B Die Skriptsprache
B Die Skriptsprache
An dieser Stelle finden Sie die Dokumentation zu der Skriptsprache unseres Experten- systems furs¨ Jassen. Mit Hilfe dieser Dokumentation sollte es Ihnen m¨oglich sein selber Regeln fur¨ das Expertensystem zu verfassen und dem System damit das Jassen erst bei- zubringen.
Die Regeln sollen alle in einer einfachen Textdatei nach bestimmten Regeln abgelegt sein. ASCII-Zeichen gr¨osser als 127 sollten aus Kompatibilit¨atsgrunden¨ vermieden werden. Der Aufbau dieser Datei ist Thema dieser Dokumentation.
B.1 Kommentare
Die Datei kann an jeder Stelle Kommentare enthalten. Sogar mitten in Bezeichnern. Wie Sie selbst damit zurechtkommen ist allerdings nicht mein Problem. Kommentare werden wie in C++ geschrieben. Es gibt folglich zwei Arten von Kommentaren:
• Mit // wird ein Einzeilenkommentar eingeleitet. Jeder Text nach diesem Zeichen bis zum Ende der Zeile wird als Kommentar angesehen. Der Kommentar kann nicht wieder aufgehoben werden.
• Alle zwischen /* und */ eingeschlossenen Teile werden als Kommentare angesehen. Dieser Kommentar kann sich uber¨ mehrere Zeilen erstrecken.
B.2 Bereiche
Die eigentlichen Daten des Skripts mussen¨ in drei Bereiche eingeteilt werden. Diese sind:
• Konstanten In diesem Bereich k¨onnen Konstanten initialisiert werden, die im ganzen Skript Gultigkeit¨ haben.
• Trumpfen Die Regeln zum Trumpfen werden in den Bereich Trumpfen geschrieben.
• Spielen In den Bereich Spielen kommen die Regeln, die fur¨ das Spielen der Karten verantwortlich sind.
58 B Die Skriptsprache
Die Bereiche werden eingeleitet mit begin [Bereichsname] und abgeschlossen mit end [Bereichsname]. [Bereichsname] steht dabei fur¨ einen der drei Bezeichner Konstan- ten, Trumpfen und Spielen. Was die Bereiche enthalten k¨onnen, steht in den n¨achsten Abschnitten.
B.2.1 Konstanten
Im Abschnitt Konstanten werden fur¨ das ganze Skript gultige¨ Konstanten definiert. Diese Sektion enth¨alt Einheiten der Form KonstantenBezeichner = Wert; wobei Wert eine Zahl, eine andere Konstante oder ein arithmetischer Ausdruck sein darf. Der Ausdruck darf allerdings nur andere zuvor definierte Konstanten und Zahlen enthalten.
B.2.2 Trumpfen
In diesem Abschnitt durfen¨ nur Regeln stehen. Die Regeln mussen¨ bei ihrer Auswertung einen gultigen¨ Trumpf zuruckliefern.¨ Endlosschleifen sollten vermieden werden.
B.2.3 Spielen
Fur¨ diesen Abschnitt gilt das gleiche wie fur¨ den Abschnitt Trumpfen“. Vermieden werden ” sollte das mehrfache Spielen derselben Karte oder das Spielen einer nicht vorhandenen Karte. Entsprechende Versuche werden vom Interpreter mit einem fatalen Fehler im Skript bestraft.
B.3 Regeln
Hier folgt die Beschreibung wie eine Regel aufgebaut ist. Jede Regel beginnt mit begin Regel gefolgt von einem Regelnamen und schliesst mit end Regel. Dazwischen befinden sich die sechs Hauptelemente einer Regel. Diese sind:
• Beschreibung: Hier sollte eine sinnvolle Beschreibung der Regel stehen. Diese Be- schreibung kann in die Erkl¨arungskomponente eingetragen werden.
• Prioritaet: Fur¨ die Priorit¨at einer Regel gelten die gleichen Beschr¨ankungen wie fur¨ die Konstanten. Eine kleine Zahl steht fur¨ eine hohe Priorit¨at. Garantiert wird
59 B Die Skriptsprache
das korrekte Auswerten fur¨ Priorit¨aten zwischen -19 und 19. Jedoch sollten in der Praxis alle Integerwerte funktionieren.
• Grobdiagnosen: Hier mussen¨ alle relevanten Grobdiagnosen fur¨ die Regel aufgez¨ahlt werden. Diagnosen die nicht gesetzt sein durfen¨ muss ein ! vorangestellt werden.
• Feindiagnosen: Hier dasselbe fur¨ die Feindiagnosen.
• Kernbedingungen: Zu den Kernbedingungen geh¨ort alles, das nicht von dien Dia- gnosen abgedeckt wird. Sie bestehen aus arithmetischen Ausdrucken¨ und k¨onnen Konstanten, Variablen, Wildcards und Facts enthalten. Einzelne Bedingungen k¨on- nen mit ;“ getrennt werden. Nur wenn alle so getrennten Bedingungen wahr sind ” gilt die gesamte Bedingung als wahr.
• Aktionen: Die Aktionen k¨onnen die gleichen Elemente wie die Kernbedingungen enthalten. Dazu kommen noch einige spezielle Elemente die eine Auswertung ab- schliessen. Dazu geh¨oren das Spielen einer Karte wie auch das Setzen des Trumpfs. Eine Regel kann mehrere Bl¨ocke von Aktionen enthalten, die mit jeweils bestimmter Wahrscheinlichkeit ausgefuhrt¨ werden.
Der allgemeine Aufbau einer Regel sieht also folgendermassen aus: begin Regel Ein Name Beschreibung: Eine Beschreibung fuer die Regel Prioritaet: 0 Grobdiagnosen: !trumpfspiel nichtLeihalten Feindiagnosen: schmieren Kernbedingungen: habeKarte( karte( HERZ, ZEHN ) ); Aktionen: Karte( karte( HERZ, ZEHN ) ); end Regel //hier ist nichts Dies stellt eine korrekte Regel dar, die ausgefuhrt¨ wird, wenn die Grobdiagnose nicht- Leihalten und die Feindiagnose schmieren gesetzt und die Grobdiagnose trumpfspiel nicht gesetzt sind und wenn wir die Herz 10 haben. Als Folge wird die Herz 10 gespielt. Jede Regel muss alle diese Elemente enthalten. Sie mussen¨ jedoch nicht angegeben werden. Keine Kernbedingungen anzugeben ist also zul¨assig.
Diagnosenbezeichner mussen¨ mit einem Buchstaben beginnen und durfen¨ danach nur Buchstaben und Zahlen enthalten. Gultige¨ Bezeichner sind zum Beispiel: trumpfen, hallo, test123, nichtLeihalten. Ungultig¨ sind 1zahl, diag!o und weitere absurde Konstrukte.
60 B Die Skriptsprache
B.3.1 Kernbedingungen
Die Kernbedingungen bestehen aus einzelnen durch Semikolons getrennten Ausdrucken.¨ Diese Ausdrucke¨ werden zu einem Wahrheitswert ausgewertet. Ein Ausdruck kann Zahlen, Konstanten, Variablen, Wildcards und Facts enthalten. Auf Variablen darf nur zugegriffen werden wenn sie durch eine Zuweisung initialisiert worden sind. Sind alle Teilbedingungen, die einzelnen Ausdrucke¨ wahr, gilt die Bedingung als erfullt.¨
B.3.2 Aktionen
Die Aktionen bestehen aus durch Semikolons getrennten Ausdrucke.¨ Sie werden im Ge- gensatz zu den Kernbedingungen nicht zu einer Zahl ausgewertet sondern nur ausgefuhrt.¨ Sie k¨onnen zus¨atzlich zu den Elementen der Bedingungen noch endgultige¨ Anweisungen enthalten, die die Auswertung der Regeln beenden. Eine Aktion kann eine Wahrschein- lichkeit fur¨ die Ausfuhrung¨ enthalten. Diese wird in Tausendstel direkt nach Aktionen“ ” eingefugt.¨ Bsp: Aktionen 300: Karte( karte( HERZ, ZEHN ) ); Aktionen 400: Karte( tiefste( HERZ ) ); Aktionen: Karte( tiefste( trumpffarbe() ) ); In diesem Beispiel wird mit einer Wahrscheinlichkeit von dreihundert Tausendsteln die Herz Zehn gespielt, in vierhundert von tausend F¨allen wird die tiefste Karte von Herz gespielt und in den anderen F¨allen wird die tiefste Trumpfkarte gespielt.
B.4 Elemente der Ausdrucke¨
In den nachfolgenden Abschnitten werden die Elemente der Ausdrucke¨ n¨aher bestimmt.
B.4.1 Konstanten
Zu den Konstanten z¨ahlen naturlich¨ auch die vom Benutzer definierten Konstanten. Da- neben gibt es aber auch von der Umgebung her einige Konstanten. Diese sind in Tabelle 6 auf der n¨achsten Seite aufgelistet.
61 B Die Skriptsprache
Karten H6 E6 K6 S6 H7 E7 K7 S7 H8 E8 K8 S8 H9 E9 K9 S9 H10 E10 K10 S10 HB EB KB SB HD ED KD SD HK EK KK SK HA EA KA SA
Werte SECHS SIEBEN ACHT NEUN ZEHN BAUER DAME KOENIG AS
Farben HERZ ECKEN KREUZ SCHAUFEL GESCHOBEN
Positionen PROGRAMM RECHTS GEGENUEBER LINKS Tabelle 6: Umgebungskonstanten
62 B Die Skriptsprache
B.4.2 Variablen
Im Skript k¨onnen frei Variablen definiert werden. Vor dem Zugriff mussen¨ sie allerdings mit einer Zuweisung initialisiert werden. Am besten wird dies von einer Regel mit hoher Priorit¨at erledigt die dann abgeschaltet wird. Es gibt statische Variablen, die uber¨ mehre- re Ausfuhrungen¨ des Skripts erhalten bleiben. Mit static(VARIABLE) wird der Wert der statischen Variable abgefragt. Werte zuweisen kann mit static(VARIABLE, AUSDRUCK). Dabei wird der Ausdruck ausgewertet und das Ergebnis der statischen Variablen zugewie- sen.
B.4.3 Wildcards
Wildcards sind Bezeichner bei welchen die Farbe nicht fest ist. Die Wildcards werden mit s¨amtlichen Permutation ausgewertet. Ein Wildcard steht w¨ahrend der gesamten Aus- wertung fur¨ dieselbe Karte oder Farbe. Wildcard SECHS1 bezeichnet eine andere Sechs als Wildcard SECHS2. Die verfugbaren¨ Wildcards sind in Tabelle 8 auf dieser Seite aufgelistet.
Wildcards fur¨ Karten SECHS1 SECHS2 SECHS3 SECHS4 SIEBEN1 SIEBEN2 SIEBEN3 SIEBEN4 ACHT1 ACHT2 ACHT3 ACHT4 NEUN1 NEUN2 NEUN3 NEUN4 NEUN1 NEUN2 NEUN3 NEUN4 ZEHN1 ZEHN2 ZEHN3 ZEHN4 BAUER1 BAUER2 BAUER3 BAUER4 DAME1 DAME2 DAME3 DAME4 KOENIG1 KOENIG2 KOENIG3 KOENIG4 AS1 AS2 AS3 AS4
Wildcards fur¨ Farben FARBE1 FARBE2 FARBE3 FARBE4 Tabelle 8: Wildcards
63 B Die Skriptsprache
B.4.4 Facts
Facts stellen die Schnittstelle zur Geschichte her. Sie sind ¨ahnlich wie Funktionen. Auf den Namen des Facts folgt eine Klammer und danach von Kommas separierte Parameter. Die Parameter werden zu einem Integer ausgewertet und dem Fact ubergeben.¨ Ein Fact liefert als Ergebnis einen Integerwert zuruck.¨ Die Facts sind in der nachfolgenden Tabelle aufgelistet. Parameter in eckigen Klammern sind optional.
Fact Parameter Ruckgabewert¨ meisteKarten keine Die Farbe, in welcher noch am meisten Karten vorhanden sind. wenigsteKarten keine Farbe von der am wenigsten noch nicht gespielte Karten vorhanden sind. anzSpielbare keine Anzahl der spielbaren Karten. anzFarbe Farbe Die Anzahl der noch vorhandenen Karte in der entsprechen- den Farbe. anzGrobdiagnosen keine Die Anzahl der etablierten Grobdiagnosen. anzFeindiagnosen keine Anzahl der etablierten Feindiagnosen. stichPunkte [Stichnummer] Der Wert des aktuellen (bezeichneten) Stichs. totalPunkte keine Anzahl der bisher gespielten Punkte anzBoecke keine Die Anzahl der Bockkarten. anzBoeckeNaechste keine Die Anzahl der Boecke im n¨achsten Stich. anzFarbeGespielt Farbe Die Anzahl der in dieser Farbe gespielten Karten. anzAusstehende Farbe Die Anzahl der ausstehenden Karten. geschoben keine Wahr wenn geschoben wurde. stichPos [Stichnummer] Die Position im aktuellen (bezeichneten) Stich. (0 = Aus- spieler, 3 = Letzter Spieler) stichKarte Position Die Karte, die der Spieler X gespielt hat. (0 = Ausspieler, 3 = Letzter Spieler) trumpffarbe keine Die aktuelle Trumpffarbe. ausgespielteFarbe keine Die im aktuellen Stich ausgespielte Farbe. stich keine Die Nummer des aktuellen Stichs. (0 = erster Stich, 8 = letzter Stich) geber keine Den Geber im aktuellen Stich. trumpfspieler keine Den Trumpfspieler im aktuellen Spiel farbeGespielt Farbe Wahr, wenn die Farbe mind. einmal ausgespielt wurde. stichGehoert keine Der Spieler, dem der Stich momentan geh¨ort.
64 B Die Skriptsprache
Fact Parameter Ruckgabewert¨ gewinnendeKarte keine Die den aktuellen Stich gewinnende Karte. stichNummer Karte Den Stich, in dem die Karte gespielt wurde. (0-8; -1) gespieltVon Karte Den Spieler, der die Karte gespielt hat. habeKarte Karte Wahr, wenn wir die Karte haben. spielbar Karte Wahr, wenn die betreffende Karte gespielt werden kann. wert Karte Punktwert der Karte. erstBeste keine Eine spielbare Karte. bisBock Karte Wieviele st¨arkere Karten es noch gibt. bisBockNaechste Karte Wie bisBock, nur wird der aktuelle Stich auch betrachtet. bock Karte Wahr, wenn die Karte bock ist. bockNaechste Karte Wahr, wenn die Karte im n¨achsten Stich bock ist. karteGespielt Karte Wahr, wenn die Karte gespielt wurde. karte Farbe, Wert Den Kartenbezeichner der entsprechenden Karte. hoechste Farbe[, nte] Die (nt-)h¨ochste spielbare Karte in der betreffenden Farbe. tiefste Farbe[, nte] Die (nt-)tiefste spielbare Karte der betreffenden Farbe. wertloseste Farbe[, nte] Gibt die (nt-)wertloseste Karte dieser Farbe zuruck.¨ wertvollste Farbe[, nte] Gibt die (nt-)wertvollste Karte dieser Farbe zuruck.¨ staerke Karte Den Wert der Karte. farbe Karte Die Farbe der Karte. hoechsteAusstehende Farbe[, nte] Die (nt-)h¨ochste ausstehende11 Karte. einBock keine Eine Bockkarte. hoechsterBock [n] Die (nt-)h¨ochste Bockkarte. tiefsterBock [n] Die (nt-)tiefste Bockkarte. staerker 2 Karten Wahr, wenn die erste Karte im aktuellen Stich die zweite schl¨agt. ausstehend Karte Wahr, wenn die Karte ausstehend ist. spielerGab Position, Farbe Wahr, wenn der Spieler die betreffende Farbe spielte, oder sie noch nicht ausgespielt wurde. spielerGabNicht Position, Farbe Wahr, wenn der Spieler bei dieser Farbe nicht leigehalten hat. gegnerGaben Farbe Wahr, wenn die Gegner die Farbe gespielt haben, oder sie noch nie ausgespielt wurde. gegnerGabenNicht Farbe Wahr, wenn die Gegner bei der Farbe nicht leigehalten ha- ben.
65 B Die Skriptsprache
Fact Parameter Ruckgabewert¨ spielerVerwarf Position, Farbe Wahr, wenn der Spieler die Farbe verworfen hat. gegnerVerwarfen Farbe Wahr, wenn beide Gegner die Farbe verwarfen. partnerVerwarf Farbe Wahr, wenn der Partner die Farbe verwarf. spielerSpielteAn Position, Farbe Wahr, wenn die farbe vom Spieler angespielt wurde. partnerSpielteAn Farbe Wahr, wenn die Farbe vom Partner angespielt wurde. nichtVerworfen keine Eine Farbe die der Partner nicht verworfen hat.
B.4.5 Spezielles
Ein Diagnoseexpertensystem verlangt noch einige spezielle Befehle mit welchen es gesteu- ert wird. Diese Befehle sollen hier aufgelistet werden.
• Karte( [Kartenbezeichner] ) Mit diesem Befehl wird das Expertensystem ver- anlasst eine Karte zu spielen. Offensichtlich ungultige¨ Karten (nicht vorhandene, sonst ungultige)¨ werden mit einer Ausnahme zuruckgewiesen.¨ Nach der Auswertung dieser Aktion wird die Auswertung der Regeln beendet. Der Befehl Karte ist nur in Regeln zum Spielen einer Karte zugelassen.
• Trumpf( [Farbenbezeichner] ) Mit diesem Befehl wird die Trumpffarbe gesetzt. Nach der Auswertung dieser Aktion wird die Auswertung der Regeln beendet. Der Befehl Karte ist nur in Regeln zum Trumpfen zugelassen.
• setzeGrobdiagnose( [Diagnosenbezeichner] ) Mit diesem Befehl wird eine Grob- diagnose gesetzt.
• loescheGrobdiagnose( [Diagnosenbezeichner] ) Mit diesem Befehl wird die bezeichnete Grobdiagnose gel¨oscht.
• setzeFeindiagnose( [Diagnosenbezeichner] ) Mit diesem Befehl wird eine Fein- diagnose gesetzt.
• loescheFeindiagnose( [Diagnosenbezeichner] ) Mit diesem Befehl wird die bezeichnete Feindiagnose gel¨oscht.
11Ausstehend sind Karten, die sich bei den Gegnern befinden k¨onnen.
66 B Die Skriptsprache
• disable() Mit disable() wird die Regel fur¨ den aktuellen Auswertungslauf deak- tiviert.
• remove() Mit remove() wird die Regel fur¨ das ganze Spiel ausgeschaltet.
B.5 Zusammenfassung
Ein Skript besteht aus einer einfachen Textdatei mit ASCII-Zeichen kleiner als 128. Ein- zeilenkommentare werden mit // eingeleitet, andere Kommentare werden von /* und */ eingeschlossen.
Die Datei enth¨alt drei Typen von Bereichen. Bereiche fur¨ Konstanten, Trumpfregeln und Spielregeln. Diese werden mit begin [Bereich] ge¨offnet und mit end [Bereich] ge- schlossen.
Der Bereich Konstanten enth¨alt Anweisungen der Form Konstantenbezeichner = [kon- stanter Ausdruck]; mit welchen Konstanten definiert werden.
Die Bereiche Trumpfen und Spielen enthalten die Regeln zum Trumpfen respektive zum Spielen.
Eine Regel besteht aus den Elementen begin Regel [Titel], Beschreibung: [Beschrei- bung], Prioritaet: [konstanter Ausdruck], Grobdiagnosen: [Grobdiagnosenkon- figuration], Feindiagnosen: [Feindiagnosenkonfiguration], Kernbedingungen [Aus- druck], Aktionen [Ausdruck] und end Regel.
B.6 Das einfachste Skript
Hier ein sinnloses Skript zum abgucken: begin Trumpfen begin Regel Trumpfe sofort Beschreibung: Trumpft die Farbe mit den meisten Karten Prioritaet: 0 //Normale Prioritaet Grobdiagnosen: Feindiagnosen: Kernbedingungen: Aktionen: Trumpf( meisteKarten() );
67 B Die Skriptsprache end Regel end Trumpfen begin Spielen begin Regel Spiele Sofort Beschreibung: Spielt irgendeine Karte Prioritaet: 0 //Normale Prioritaet Grobdiagnosen: Feindiagnosen: Kernbedingungen: Aktionen: Karte( erstBeste() ); end Regel end Spielen
68