Entwicklung eines Werkzeugs zur grafischen Definition von Regeln in einem Expertensystem

  TiRex Tool zur Visualisierung von Regeln in einem Expertensystem  

Inhaltsverzeichnis

1  ZIELSETZUNG UND AUFBAU  1

1.1  ZIELSETZUNG DER ARBEIT  2

1.2  AUFBAU  3

2  REGELBASIERTES EXPERTENSYSTEM  5

2.1  CHARAKTERISIERUNG UND ARCHITEKTUR VON EXPERTENSYSTEMEN  5

2.2  WISSENSREPRÄSENTATION UND STRATEGIEN DER WISSENSVERARBEITUNG  10

2.3  METHODEN DES WISSENSERWERBS  12

3  SOLLKONZEPTION  13

3.1  FUNKTIONALE ANFORDERUNGEN  13

3.2  NICHTFUNKTIONALE ANFORDERUNGEN  16

3.3  TECHNISCHE PRODUKTUMGEBUNG  18

4  ENTWURF UND IMPLEMENTIERUNG DER IDENTIFIZIERTEN  

  ANFORDERUNGEN  20

4.1  ORGANISATION DES GESAMTSYSTEMS  20

4.1.1  Softwaredistribution  22

4.1.2  Sicherheitsaspekte  25

4.1.3  Pakethierarchie  27

4.2  DIALOGUNTERSTÜTZTE ERFASSUNG VON DATEN UND WISSEN  29

4.2.1  Strukturierte Erfassung  31

4.2.2  Menüstruktur  36

4.2.3  Daten- und Wissenserfassung  37

4.3  DATENANALYSE UND DATENMODELLIERUNG  47

4.3.1  Datenbank  47

4.3.2  XML-Dateien  48

I

  TiRex Tool zur Visualisierung von Regeln in einem Expertensystem  

4.4  KLASSE-N UND FUNKTIONSENTWURF  53

4.4.1  Server  54

4.4.2  Client  54

5  POTENZIELLE WEITERENTWICKLUNGEN  57

6  MANAGEMENT SUMMARY  58

ANHANG A:  PFLICHTENHEFT  61

ANHANG B:  FALLSTUDIE  73

  QUELLENVERZEICHNIS  85

  ABKÜRZUNGSVERZEICHNIS  87

II

TiRex - Tool zur Visualisierung von Regeln in einem Expertensystem

1 Zielsetzung und Aufbau

„Ein Weiser gibt nicht die richtige Antworten. Er

Claude Levi-Strauss.

Wissensbasierte Systeme stehen heute nicht mehr so stark im Blickpunkt von Forschung und Praxis wie es noch vor zehn oder fünfzehn Jahren der Fall war. Dies bedeutet allerdings nicht, dass die Entwicklung solcher Systeme zu einem Routineprozess geworden ist, der für beliebige Problemstellungen nach einem festen Schema abläuft. Vielmehr ist die Konzeption, Entwicklung und insbesondere die Wissensbasispflege mit immensen Schwierigkeiten verbunden [HERR97, S. 1]. Während vor einigen Jahren noch das Interesse ausschließlich auf allgemeinen Problemlösungsmethoden lag, hat sich die entscheidende Bedeutung der Erfassung detaillierten Expertenwissens für die Entwicklung leistungsfähiger Programme herausgestellt. Die Notwendigkeit dieses Umdenkens wird um so deutlicher, wenn man bedenkt, dass Expertensysteme typischerweise für schlecht strukturierte Anwendungsgebiete eingesetzt werden, was eine Entwicklung eines konventionellen Algorithmus schwierig oder gar unmöglich macht.

Nicht nur ist das Wissen in den Köpfen der Experten schwer zugänglich, meist fehlt es den Fachleuten an Zeit und Motivation, ihr Know-how weiterzugeben. Erschwerend kommt die dem Wissen innewohnende Dynamik hinzu. Wissen ändert sich oft innerhalb kurzer Zeit und wird somit ungültig bzw. fehlerhaft. Des Weiteren kann nicht erwartet werden, dass das Wissen bei der Wissensbasisinitialisierung vollständig erfasst wird. Nicht berücksichtigte Fälle zeigen sich häufig erst beim praktischen Einsatz des Systems. Konsequenz ist, dass regelmäßige Korrekturen an der Wissensbasis unvermeidbar sind. Entscheidend für den erfolgreichen Einsatz von Expertensystemen ist somit die Bereitstellung einer Softwarekomponente, die es ermöglicht, eine Wissensbasis aufzubauen sowie den Wissensbestand von im Einsatz befindlichen Systemen zu vergrößern und vorhandene Lücken bei bereits bestehenden Problemen zu schließen. Der bisher dominierende Lösungsansatz zur Wissensbasiserstellung und -pflege besteht im Berufsbild des sog. Wissensingenieurs, welcher sich vor allem durch Kommunikation mit Fachleuten Wissen aneignet und dieses dann für ein Expertensystem formalisiert. Diese indirekte Form des Wissenserwerbs ist nicht nur teuer, sondern wegen der

TiRex - Tool zur Visualisierung von Regeln in einem Expertensystem

inhärenten Verständigungsprobleme beider Parteien auch fehleranfällig. Wenn man bedenkt, dass die Wissensbasis einer ständigen Erweiterung und Modifikation unterliegt, wird der indirekte Wissenserwerb mit zwei Gruppen von hoch bezahlten Spezialisten auf Dauer zu kostspielig. Der Übergang zum direkten Wissenserwerb scheiterte allerdings bisher auf Grund des Fehlens einer geeigneten Softwarelösung, die es einem Experten ermöglicht, sein Wissen selbstständig zu erfassen und zu pflegen [PUPP90, S. 3 und HERR97, S. 6f.]. Ansätze findet man bereits beim Expertensystem-Shell-Baukasten D3, der es einem Experten erlaubt, weitgehend selbstständig leistungsfähige Systeme zu entwickeln. Allerdings beschränken sich diese auf Diagnosesysteme [PUPP96, S. 13].

1.1 Zielsetzung der Arbeit

Expertensysteme werden meist von externen Software-Häusern entwickelt und dann vom jeweiligen Anwender implementiert. Interessant dabei ist, dass die Verantwortung zur Erweiterung und Modifikation des Systems ab einem bestimmten Zeitpunkt an den eigentlichen Anwender übertragen wird. Daraus ergibt sich, dass die Pflege der Wissensbasis nicht von den Personen durchgeführt wird, die für die Realisierung des Systems verantwortlich waren, sondern vom Experten selbst. Diese Konstellation kann zu Schwierigkeiten führen, die die Effizienz des Expertensystems in Frage stellen. Gleichzeitig wird deutlich, wie wichtig eine systematische Unterstützung für alle Prozesse bei der Wissensbasisinitialisierung und -pflege ist [HERM97, S. 12].

Während die auf dem Markt befindlichen Werkzeuge zur Wissensakquisition noch die Hilfe von Wissensingenieuren erfordern, die Experten befragen und das gewonnene Wissen in geeigneter Form formalisieren, muss es mittelfristiges Ziel sein, ein Werkzeug zu entwickeln, welches in einer Weise komfortabel und problemadäquat gestaltet ist, dass ein Experte selbstständig und ohne weitere Unterstützung von anderen Personen sein Wissen erfassen, ändern und testen kann. Solche Werkzeuge würden den Umgang mit Wissen in den verschiedensten Anwendungsbereichen fundamental ändern, da das bisher weitgehend private Wissen von Experten, das darüber hinaus nur über langjährige Praxiserfahrungen erworben werden kann, dann in Programmen explizit dargestellt und in Folge dessen leichter erlernt, angewendet und getestet werden kann [PUPP88, S. 7].

Ziel dieser Arbeit ist die Analyse, Konzeption und Implementierung eines Werkzeugs, welches einem Experten bei der grafischen Definition und Manipulation von Regeln in einem Expertensystem unterstützt. Der Fokus liegt bei der Entwicklung auf der Bereit-

2

TiRex - Tool zur Visualisierung von Regeln in einem Expertensystem

stellung einer komfortablen und benutzerfreundlichen Modellierungsebene, mit deren Hilfe der Anwender Objekte einer Wissensbasis visualisieren, miteinander verknüpfen und bestehende Verkettungsregeln manipulieren kann. Voraussetzung hierfür ist die strukturierte und dialogunterstützte Erfassung von Objekten, wie z. B. Fragen und Diagnosen. Dabei soll es dem Anwender möglich sein, selbstständig und ohne Hilfe eines Wissensingenieurs diese Objekte zu erfassen und zu pflegen. Die zu entwickelnde Software soll dabei unabhängig vom zu modellierenden Problem und somit in den verschiedensten Anwendungsgebieten einsetzbar sein. Dies impliziert, dass das Werkzeug bei verschiedenen Organisationen und innerhalb dieser von mehreren Experten gleichzeitig genutzt werden kann. Ein weiterer Teil dieser Arbeit befasst sich mit den Möglichkeiten zur Erweiterung des umgesetzten Systems. Diese werden auf Grund begrenzter Ressourcen nur theoretisch behandelt.

Eine umfassende Dokumentation ist ein integraler Bestandteil der Software-Entwicklung und stellt meist eine Herausforderung für die Systemanalytiker und Programmierer dar. Sie bildet die Voraussetzung für die Wartung und Weiterentwicklung des Systems. Eine leichte Einarbeitung bei Personalwechsel ist somit möglich [BALZ01, S. 1075]. Demnach muss es das Ziel sein, eine vollständige Systembeschreibung zu erstellen. Diese beinhaltet vor allem relevante Informationen der Soll-Konzeption, das Einfügen von Kommentaren im Code und die Erstellung von Hilfen, wie z. B. einem Benutzer-handbuch.

1.2 Aufbau

Die vorliegende Arbeit beschreibt die Konzeption und Implementierung der im vorangegangen Kapitel aufgezeigten Zielsetzung. Zwischenergebnisse werden dabei kritisch diskutiert. Einen Überblick des schrittweisen Vorgehens zeigt Abbildung 1-1.

Nachdem in Kapitel 1 die Zielsetzung der vorliegenden Arbeit erläutert wird, stellt Kapitel 2 die für die weiteren Betrachtungen relevanten theoretischen Grundlagen bezüglich regelbasierter Expertensysteme dar. In komprimierter Form werden solche Systeme charakterisiert und auf deren Architektur und potenzielle Einsatzgebiete eingegangen. Des Weiteren erfolgt eine Betrachtung der verschiedenen Wissenserwerbsarten sowie die Art und Weise der Wissensrepräsentation und -verarbeitung.

Im Rahmen von Kapitel 3 erfolgt eine Präzisierung der Einsatzkriterien und die Konkretisierung der daraus hervorgehenden funktionalen und nichtfunktionalen Anforderungen, welche das zu entwickelnde Softwareprodukt erfüllen muss bzw. solche, die

TiRex - Tool zur Visualisierung von Regeln in einem Expertensystem

vom Anwender als wünschenswert zu betrachten sind. Hinsichtlich der technischen Realisierung wird aufgezeigt, welche Software-Systeme und Hardware-Komponenten zum Einsatz kommen und unter welchen organisatorischen Bedingungen die Software eingesetzt werden soll.

Abbildung 1-1: Aufbau der Arbeit

Kapitel 4 befasst sich schließlich mit dem Entwurf der identifizierten Anforderungen und visualisiert Ergebnisse an Hand der konkreten Implementierung. Betrachtet werden dabei die vier Bereiche System, Daten, Funktionen und Dialog. Die Organisation des Gesamtsystems beinhaltet die Verteilung von Aufgaben auf die Client- bzw. Serverkomponente und deren Kommunikation sowie die Distribution der Software. Insbesondere wird auf die mit der Kommunikation und Softwareverteilung verbundenen Sicherheitsaspekte näher eingegangen. Anschließend erfolgt eine Modellierung der zu speichernden Daten, welche sowohl in einer relationalen Datenbank als auch in Dateien abgelegt werden. Da Letztere die grundsätzliche Art und Weise der Speicherung darstellt,

4

TiRex - Tool zur Visualisierung von Regeln in einem Expertensystem

werden insbesondere dessen Struktur und Funktionsweise detailliert beschrieben. In einem weiteren Abschnitt wird auf die wichtigsten für eine Umsetzung benötigten Klassen und charakteristischen Konzepte bei der Realisierung eingegangen. Der Fokus des letzten Abschnitts liegt auf der Gestaltung der Dialogkomponente. Einem allgemeinen Teil zur grundsätzlichen Gestaltung von Benutzerschnittstellen folgend, werden die zu entwickelten Oberflächen aufgezeigt sowie Konzepte und Vorgehensweise bei der Datenerfassung diskutiert.

Da auf Grund der begrenzten Ressourcen eine vollständige Implementierung aller identifizierten Anforderungen nicht möglich ist, bedarf es der Diskussion um potenzielle Weiterentwicklungen. In Kapitel 5 werden daher die zur Erstellung eines integrierten Gesamtsystems notwendigen bzw. wünschenswerten Erweiterungen betrachtet und konkrete Lösungsmöglichkeiten aufgezeigt.

Abschließend erfolgt in Kapitel 6 eine Zusammenfassung der vorgestellten Entwicklung und der daraus gewonnenen Erkenntnisse.

2 Regelbasiertes Expertensystem

Um für die Untersuchungen dieser Arbeit einen wissenschaftlichen Rahmen aufzuzeigen, wird nachfolgend der Begriff „regelbasiertes Expertensystem“ näher betrachtet.

2.1 Charakterisierung und Architektur von Expertensystemen

Expertensysteme sind Programme, mit denen das Spezialwissen eines eng begrenzten Aufgabengebiets, die Erfahrungen und die Schlussfolgerungsfähigkeit qualifizierter Fachleute auf eine Menge formalisierter, maschinenverarbeitbarer Operationen nachgebildet werden sollen [GABL97a, S. 257]. Zentrale Annahme dieses Ansatzes ist, dass sich Problemlösungen aus Einzelkenntnissen zusammensetzen, welche von Experten selektiert und in geeigneter Form kombiniert werden, um so zu einer Lösung zu gelangen. Konsequenterweise muss bei der Implementierung eines Expertensystems das Wissen formalisiert, im Software-System in geeigneter Weise repräsentiert und auf Basis einer Problemlösungsstrategie manipuliert werden.

Das grundlegende Organisationsprinzip von Expertensystemen beinhaltet die konsequente Trennung von anwendungsspezifischem Wissen und der Problemlösungsstrate-

TiRex - Tool zur Visualisierung von Regeln in einem Expertensystem

gie. In vielen Anwendungsbereichen ist eine solche Trennung möglich und charakteristisch für die Architektur von Expertensystemen (vgl. Abbildung 2-1).

Abbildung 2-1: Organisationsprinzip (in Anlehnung an [PUPP88, S. 2])

Von einem Expertensystem kann aber nur gesprochen werden, wenn ein Programm neben den bisher genannten noch weitere essenzielle Eigenschaften besitzt. Dazu zählen: Transparenz: Das Zustandekommen von Problemlösungen kann durch

Benutzerfreundlichkeit:

Flexibilität:

Kompetenz:

Während die einzelnen Merkmale für sich in ihrer Bedeutung vage sind, bietet ihre Kombination doch ein hinreichend klares Bild bzgl. der Definition von Expertensystemen und ermöglicht eine Abgrenzung zu anderen Programmen [PUPP88, S. 2-5]. Die Architektur eines Expertensystems beschreibt die verschiedenen Programmmodule und ihre Beziehung zueinander (vgl. Abbildung 2-2). Die funktionale Trennung zwischen Wissen und Problemlösungsstrategien spiegelt sich in den beiden Modulen Wissensbasis und Steuersystem wieder.

Die Wissensbasis bildet die Grundlage des Expertensystems. Das darin enthaltene Wissen kann auf unterschiedliche Weise klassifiziert werden. Nach der Herkunft des Wis-

6

TiRex - Tool zur Visualisierung von Regeln in einem Expertensystem sens wird zwischen bereichsbezogenem Wissen von Fachleuten, fallspezifischem Wissen von Benutzern sowie Zwischen- und Endergebnissen, welche von der Problemlösungskomponente hergeleitet worden sind, unterschieden. Je nach Gebrauch des Wissens erfolgt eine Unterteilung in Fakten-, Ableitungs- und Steuerungs- bzw. Kontrollwissen. Dabei steuert das Ableitungswissen, bspw. in Form von Regeln, den Gebrauch des Faktenwissens. Das Ableitungswissen selbst wird durch das Kontrollwissen (sog. Meta-Regeln) gesteuert. Während Expertenwissen sowohl aus Fakten- als auch aus Ableitungs- und Kontrollwissen besteht, beschränken sich das fallspezifische Wissen sowie die Zwischen- und Endergebnisse typischerweise auf Faktenwissen [PUPP88, S. 12].

Abbildung 2-2: Architektur eines Expertensystems (in Anlehnung an [BALZ01, S. 708])

Das Steuersystem besteht aus folgenden Komponenten [SCHU86, S. 13]:

• Die Problemlösungskomponente dient der Wissensauswertung. Sie verknüpft die in der Wissensbasis vorhandenen Fakten und Regeln nach einer vorgegebenen Strategie und generiert hieraus eine Lösung für das vom Benutzer spezifizierte Problem.

TiRex - Tool zur Visualisierung von Regeln in einem Expertensystem

Expertensysteme kommen vor allem bei halb strukturierten Aufgaben zur Anwendung, d. h. bei Problemen, welche nicht durch eine eindeutig definierte, endliche Folge von Operationen zu lösen sind. Ungeeignet sind Expertensysteme für Aufgaben, die auch ein Experte nicht lösen kann [GABL97a, S. 259]. Ein Einsatz erfolgt daher in solchen Gebieten, bei denen die Datenerfassung wenig fehleranfällig ist und der Experte die endgültige Entscheidung trifft. Das Expertensystem fungiert dabei als Entscheidungsunterstützung [PUPP88, S. 6]. Tabelle 2-1 fasst die verschiedenen Aufgabenbereiche von Expertensystemen, wie sie von HAYES-ROTH vorgeschlagen wurden, zusammen und gibt eine kurze Beschreibung.

PUPPE reduziert die Aufgabenbereiche auf drei fundamentale Problemlösungstypen mit dem Argument, dass verschiedene Problemtypen Gemeinsamkeiten besitzen, die darauf hinweisen, dass eine Lösung mit derselben Strategie erreicht werden kann (vgl. Tabelle 2-2). So ist meist das Ziel von Interpretation, Diagnose und Überwachung, ein bekanntes Muster zu identifizieren, d. h. ein Objekt, einen Fehler oder einen Alarmzustand wiederzuerkennen [PUPP88, S. 10].

8

TiRex - Tool zur Visualisierung von Regeln in einem Expertensystem

Tabelle 2-1: Aufgabenbereiche von Expertensystemen (in Anlehnung an [HAYE83, S. 14])

Tabelle 2-2: Fundamentale Problemlösungstypen (in Anlehnung an [PUPP88, S. 10])

Nutzeneffekte sollen vor allem im administrativen und dispositiven Bereich erzielt wer-

den. Mögliche Effekte umfassen Rationalisierung (z. B. Personalkosteneinsparung

TiRex - Tool zur Visualisierung von Regeln in einem Expertensystem durch schnellere und/oder bessere Problemlösung), Qualitätssteigerung (z. B. Kontrolle von Problemlösungen, die durch Menschen oder Programme hergeleitet wurden) und organisatorische Verbesserungen im Unternehmen, wie z. B. die Wissensmultiplikation und -konservierung [PUPP90, S. 9f.].

2.2 Wissensrepräsentation und Strategien der Wissensverar-

beitung

Voraussetzung für eine erfolgreiche Problemlösung durch ein Expertensystem ist die adäquate Repräsentation des Wissen, d. h. die Modellierung des betrachteten Anwendungsbereichs. Von Repräsentation kann aber nur gesprochen werden, wenn neben der Wissensdarstellung auch Angaben über dessen Verwendung erfasst sind. Zur Formalisierung des Wissens sind verschiedene Methoden entwickelt worden. Die meist verwendeten Grundtechniken sind dabei Regeln und objektorientierte Darstellungsformen. Des Weiteren kann auf Constraints zurückgegriffen werden, welche Randbedingungen beschreiben, die von der Lösung eingehalten werden müssen. Auf Grund von Unsicherheit, Unvollständigkeit und Zeitabhängigkeit der zu erhebenden Daten gehören zu den Repräsentationsformen auch probabilistisches, nicht-monotones und temporales Schließen. Anzumerken ist, dass die Bedeutung der verschiedenen Grundtechniken für die einzelnen Problemlösungstypen variiert. So ist bspw. probabilistisches Schließen für die Diagnose weitaus wichtiger als für die Konstruktion [PUPP88, S. 11-13]. Abbildung 2-3 zeigt eine grobe Zuordnung von Problemlösungstypen zu den Grundtechniken der Wissensrepräsentation.

Abbildung: 2-3: Zuordnung von Problemlösungstypen zu Grundtechniken der Wissensrepräsentation [PUPP88, S. 11]

10

TiRex - Tool zur Visualisierung von Regeln in einem Expertensystem

Gegenstand dieser Arbeit sind regelbasierte Expertensysteme, d. h. Systeme, deren Wissensbasis Regeln enthält. Im Folgenden wird daher auf Regeln und Strategien zu deren Abarbeitung näher eingegangen.

Eine Regel besteht aus einer Prämisse, welche eine Situation beschreibt, und einer Konsequenz. Sie besitzt die allgemeine Form: „WENN Bedingungsteil DANN Aktion“. Innerhalb des Aktionsteils kann einerseits eine Handlungsanweisung stehen, andererseits kann mit Hilfe einer Implikation oder Deduktion der Wahrheitsgehalt einer Feststellung hergeleitet werden, welcher wiederum den Bedingungsteil einer weiteren Regel darstellt. Die Komplexität der Vorbedingungen reicht dabei vom einfachen Abfragen der Wissensbasis über das Nachschauen und anschließendem Rechnen bis hin zu Mustervergleichen. Ein Expertensystem zur Anlagenberatung könnte bspw. folgende Regeln beinhalten:

Implikation: WENN Vermögen in Aktien > 50 % des Gesamtvermögens

DANN Kunde ist risikofreudig Handlung WENN Anlagesumme > 10.000 Euro

DANN Empfehlung = Termingeld

Ein regelbasiertes Expertensystem besteht aus einer Datenbasis, welche die gültigen Fakten enthält, Regeln zur Herleitung neuer Fakten und dem Regelinterpreter zur Steuerung. Die beiden grundlegenden Problemlösungsmethoden zur Auswertung der Wissensrepräsentation sind Vorwärts- und Rückwärtsverkettung. Bei der Vorwärtsverkettung werden ausgehend von der vorhandenen Datenbasis Regeln gesucht, deren Vorbedingung Gültigkeit besitzen (Konfliktmenge). Die Aktionsteile der gefundenen Regeln werden mittels einer Konfliktlösungsstrategie (z. B. Regel mit der höchsten Priorität schaltet zuerst) ausgeführt. Dieser Prozess wird so lange wiederholt, bis keine Regel mehr anwendbar und damit ein Ergebnis gefunden ist. Bei der Rückwärtsverkettung werden ausgehend von einem Ergebnis nur die Regeln überprüft, deren Aktionsteil das Ziel enthält. Unbekannte Parameter der Vorbedingungen werden vom Benutzer erfragt oder mittels weiterer Regeln hergeleitet.

Die Zergliederung des Gesamtwissens in viele kleine eigenständige Bausteine macht eine Wissensbasis modular und damit leicht änderbar. Daher sollte im Idealfall jede relevante Situation des Anwendungsbereichs durch genau eine Regel abgebildet werden [PUPP88, S. 21-26].

TiRex - Tool zur Visualisierung von Regeln in einem Expertensystem

2.3 Methoden des Wissenserwerbs

Der Wissenserwerb umfasst die Identifikation, Formalisierung und Pflege des zur Problemlösung benötigten Wissens. Expertensysteme erleichtern diese Aufgabe im Vergleich zu konventionellen Programmen durch die Trennung von Wissen und der Problemlösungsstrategie beträchtlich. Dennoch bleibt das Kernproblem bei der Entwicklung von Expertensystemen der Wissenserwerb, dessen Lösungsansätze Qualität und Erfolg bestimmen. Dabei kommen drei Grundtechniken zur Anwendung [PUPP88, S. 110]. Beim indirekten Wissenserwerb befragt ein Wissensingenieur den Experten. Das Ergebnis sind verbale Aufzeichnungen, die anschließend interpretiert und formalisiert werden müssen. Vorherrschende und ergiebigste Erhebungstechnik ist dabei die mündliche Befragung in Form eines Interviews [PUPP88, S. 115]. Dieses konzentriert sich meist auf nur einen Gesprächspartner, sollte strukturiert werden und nach einer schriftlichen Vorlage ablaufen [STAH99, S. 254f.]. Hauptproblem dabei ist, dass der Interviewer mit der unvermeidlichen Unvollständigkeit und Widersprüchlichkeit der Angaben rechnen muss. Ursachen dafür liegen darin begründet, dass Experten oft viele wichtige Faktoren vergessen, da sie diese für selbstverständlich halten, bildhaftes Wissen verbal kaum adäquat beschrieben werden kann, Teile des Wissens unbewusst sind, unzureichende Motivation unter den Befragten vorherrscht oder Experten Schwierigkeiten haben, Vorgehensweisen zu erklären. Einige dieser Probleme lassen sich durch die Bereitstellung eines geeigneten Werkzeugs zur Wissensakquisition verringern bzw. eliminieren.

Ist ein komfortables Wissenserwerbssystem vorhanden, kann der Experte selbst das Wissen formalisieren. Ein Wissensingenieur als Intermediär wird dann nicht mehr benötigt. Für eine komfortable Kommunikation auf einer angemessenen Abstraktionsebene müssen folgende grundlegende Anforderungen erfüllt sein:

• Unterstützung durch Menüs und Grafiken,

• Wissensstandsbezogene Eingabemodi, wie z. B. für Anfänger und Fortgeschrit-

• Gleichartigkeitdes Eingabe- und Änderungsmodus mit der Möglichkeit der so-

• Bereitstellungund Verwaltung von Testmechanismen.

12

TiRex - Tool zur Visualisierung von Regeln in einem Expertensystem

Anzumerken bleibt, dass ein Wissensakquisitionssystem den Experten um so besser unterstützt, je mehr es auf den entsprechenden Anwendungsbereich zugeschnitten ist [PUPP88, S. 116f.].

Da sich die Wissensakquisition trotz komfortabler und problemspezifischer Werkzeuge sehr aufwendig gestaltet, wäre eine (Teil-)Automatisierung äußerst vorteilhaft. Dabei extrahiert das Expertensystem sein Wissen selbstständig aus Falldaten oder verfügbarer Literatur. Einer bestimmten Lernstrategie folgend, konstruiert das System automatisch neues Wissen oder verbessert bereits vorhandenes [HERR97, S. 15f.].

3 Sollkonzeption

Zu Beginn einer Softwareentwicklung ist es entscheidend, alle Produktanforderungen vollständig zu definieren. Anforderungen legen dabei die qualitativen und quantitativen Eigenschaften eines Produkts aus Sicht des Anwenders fest. Es ist zu spezifizieren, welche Leistungen für das zu entwickelnde System unabdingbar sind, damit es für den vorgesehenen Einsatzzweck genutzt werden kann. Diese sind ihrer Natur nach vage, unvollständig und zum Teil widersprüchlich. Aufgabe muss es daher sein, aus diesen An-forderungen ein vollständiges, konsistentes und eindeutiges Produktmodell zu erstellen, das auch die Kriterien enthält, die bewusst nicht erreicht werden sollen [BALZ01, S. 98]. In den folgenden Kapiteln werden daher funktionale und nichtfunktionale An-forderungen sowie die technische Produktumgebung analysiert. Das Pflichtenheft (vgl. Anhang A) gibt eine zusammenfassende Darstellung der hier betrachteten Punkte.

3.1 Funktionale Anforderungen

Eine vollständige Problemspezifikation lässt sich in anschaulicher Weise mit Hilfe der Unified Modeling Language (UML) erstellen. In Abbildung 3-1 sind alle möglichen Arbeitsabläufe aus Sicht der Anwender in Form eines sog. Anwendungsfalldiagramms aufgezeigt. Jeder Anwendungsfall beschreibt dabei einen in sich geschlossenen Teil des Systems, stellt typischerweise eine Interaktion bzw. ein Benutzerziel dar und besteht häufig aus mehreren Einzelschritten. Akteure werden als Strichmännchen dargestellt und beschreiben die einzelnen Rollen innerhalb der Applikation. Das System wird als ein Rechteck und die verschiedenen Szenarien durch Ellipsen inklusive einer eindeuti-

TiRex - Tool zur Visualisierung von Regeln in einem Expertensystem

gen Kurzbeschreibung visualisiert. Linien assoziieren Akteure mit Anwendungsfällen [SEEM00, S. 16-18].

Abbildung 3-1: Anwendungsfalldiagramm

Das Berechtigungskonzept der vorliegenden Software wird aus der Betrachtung der einzelnen Rollen Experte, Administrator und Superadministrator deutlich. Dabei ist zu beachten, dass eine Instanz des spezialisierten Akteurs ebenfalls als Akteur in der verallgemeinerten Rolle auftreten kann. Ein Experte besitzt die Möglichkeit, der An- und Abmeldung, Pflege seiner eigenen Benutzerdaten, Erfassung und Pflege von Fakten sowie Modellierung von Regeln. Ein Administrator hat darüber hinaus die Berechtigungen zur Pflege der ihm zugeordneten Organisation sowie Anlage und Pflege von Benutzern innerhalb der eigenen Organisation. Da die Nutzung der Software nicht auf eine Institution beschränkt sein soll, ist eine Verwaltung aller beteiligten Organisation notwendig. Die Berechtigung hierzu besitzt nur ein Superadministrator.

Zu den beiden Kernfunktionen zählen das Verwalten von Faktenwissen und die Definition von Regeln, deren Ergebnisse auf dem Server als Dokumente abgelegt werden. Die Verwaltung von Fakten dient der Erfassung von Objekten, wie z. B. die an den Endbenutzer gestellten Fragen oder potenzielle Lösungen. Eine strukturierte Erfassung soll unter Zuhilfenahme einer vorher fest definierten Ordnerstruktur in Form einer Baum-

14