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 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.
[...]
Inhaltsverzeichnis
1 Zielsetzung und Aufbau
1.1 Zielsetzung der Arbeit
1.2 Aufbau
2 Regelbasiertes Expertensystem
2.1 Charakterisierung und Architektur von Expertensystemen
2.2 Wissensrepräsentation und Strategien der Wissensverarbeitung
2.3 Methoden des Wissenserwerbs
3 Sollkonzeption
3.1 Funktionale Anforderungen
3.2 Nichtfunktionale Anforderungen
3.3 Technische Produktumgebung
4 Entwurf und Implementierung der identifizierten Anforderungen
4.1 Organisation des Gesamtsystems
4.1.1 S oftwaredi stributi on
4.1.2 Sicherheitsaspekte
4.1.3 Pakethierarchie
4.2 Dialogunterstützte Erfassung von Daten und Wissen
4.2.1 Strukturierte Erfassung
4.2.2 Menüstruktur
4.2.3 Daten- und Wissenserfassung
4.3 Datenanalyse und Datenmodellierung
4.3.1 Datenbank
4.3.2 XML-Dateien
4.4 Klassen- und Funktionsentwurf
4.4.1 Server
4.4.2 Client
5 Potenzielle Weiterentwicklungen
6 Management Summary
Anhang A: Pflichtenheft
Anhang B: Fallstudie
Quellenverzeichnis
Abkürzungsverzeichnis
Abbildung in dieser Leseprobe nicht enthalten
1 Zielsetzung und Aufbau
„Ein Weiser gibt nicht die richtige Antworten. Er stellt die richtigen Fragen.“
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 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- 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 Benutzerhandbuch.
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 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 in dieser Leseprobe nicht enthalten
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,
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ösungsstrategie. In vielen Anwendungsbereichen ist eine solche Trennung möglich und charakteristisch für die Architektur von Expertensystemen (vgl. Abbildung 2-1).
Abbildung in dieser Leseprobe nicht enthalten
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 das benutzte Wissen in aufschlussreicher Weise erklärt werden.
Benutzerfreundlichkeit: Expertensysteme bieten einen hochkomfortablen Dialog und erfordern keine programmiersprachlichen Vorkenntnisse.
Flexibilität: Einzelkenntnisse können leicht hinzugefügt, manipuliert und gelöscht werden.
Kompetenz: Eine hohe Problemlösungsfähigkeit im entsprechenden Anwendungsbereich ist gegeben.
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- 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. Kontroll- wissen. Dabei steuert das Ableitungswissen, bspw. in Form von Regeln, den Gebrauch des Faktenwissens. Das Ableitungswissen selbst wird durch das Kontroll wissen (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 in dieser Leseprobe nicht enthalten
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.
- Aufgabe der Interviewerkomponente ist es, den Dialog mit dem Benutzer zu lenken und/oder automatisch erhobene Messdaten einzulesen. Hilfsmittel für eine benutzerfreundliche Gestaltung sind die Verwendung einer natürlichen Sprache sowie grafische Darstellungsformen.
- Ziel der Erklärungskomponente ist es, das Zustandekommen von Ergebnissen transparent zu gestalten. Des Weiteren gibt sie dem Experten die Möglichkeit zu verifizieren, ob das System die Schlussfolgerungslogik korrekt abbildet. Fehler in der Wissensbasis können so lokalisiert und anschließend eliminiert werden.
- Die Wissenserwerbskomponente unterstützt den Experten beim Hinzufügen und bei der Manipulation des in der Wissensbasis vorhandenen Wissens.
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].
Tabelle 2-1: Aufgabenbereiche von Expertensystemen (in Anlehnung an [HAYE83, S. 14])
Abbildung in dieser Leseprobe nicht enthalten
Nutzeneffekte sollen vor allem im administrativen und dispositiven Bereich erzielt werden. Mögliche Effekte umfassen Rationalisierung (z. B. Personalkosteneinsparung
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 Wissensverarbeitung
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 in dieser Leseprobe nicht enthalten
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]
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
UND Anlagedauer < 3 Monate 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].
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 Fortgeschrittene,
- Gleichartigkeit des Eingabe- und Änderungsmodus mit der Möglichkeit der sofortigen Überprüfbarkeit von Änderungen und
- Bereitstellung und Verwaltung von Testmechanismen.
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 Anforderungen 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 Anforderungen 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 eindeutigen Kurzbeschreibung visualisiert. Linien assoziieren Akteure mit Anwendungsfällen [SEEM00, S. 16-18].
Abbildung in dieser Leseprobe nicht enthalten
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-
Struktur erreicht werden. Neben dem Hinzufügen von Fakten muss es dem Benutzer ermöglicht werden, bereits vorhandene Daten zu aktualisieren sowie zu löschen. Um bei diesen Vorgängen Inkonsistenzen zu vermeiden, darf sich ein zu löschender Eintrag nicht in einer Modellierungsebene befinden. Fragen dürfen nur manipuliert werden, falls dies keine Auswirkungen auf die Darstellung einer bereits erstellten Grafik beinhaltet. Weiterhin soll ein Faktum nur einmal angelegt werden. Zur Differenzierung von Objekten muss eine eindeutigen Kurzbeschreibung vergeben werden.
Die Modellierung von Regeln als zweite Kernfunktion soll es dann dem Benutzer ermöglichen, mittels Mausinteraktionen die erfassten Objekte miteinander zu verknüpfen und bestehende Beziehungen zu visualisieren. Als Hilfsmittel soll dabei eine grafische Modellierungsebene dienen, in der die verschiedenen Objekttypen als Symbole dargestellt und Abhängigkeiten zwischen diesen durch Kanten repräsentiert werden. Neben dem Hinzufügen weiterer Elemente zum Regelnetzwerk muss es ebenfalls möglich sein, bestehende Regeln zu verändern, d. h. Symbole zu löschen bzw. deren Position zu variieren sowie Abhängigkeiten aufzuheben. Hilfen in Form von farblichen Markierungen verwendeter Objekte in der Baumhierarchie und der Modellierungsebene, die Möglichkeit zur räumlichen Navigation und zur Anzeige von Detaildaten eines Objekts, das Hinzufügen von Kurzbezeichnungen unterhalb von dargestellten Symbolen sowie Hinweise bei unzulässigen Aktionen, wie z. B. die Modellierung von Schleifen, sollen dem Anwender eine komfortable Modellierung ermöglichen. Es ist darauf hinzuweisen, dass eine Manipulation von Faktenwissen und Regelwissen nur durch den Verfasser der Information gestattet sein soll. Rechte sind somit scharf abgegrenzt und Inkonsistenzen bei der Speicherung können vermieden werden.
Zwei weitere Funktionen sollen der Verwaltung von Organisationen und Benutzern dienen. Dabei ist zu beachten, dass zuerst die Organisation angelegt werden muss, bevor deren Benutzer erfasst werden können, da in den Benutzerstammdaten ein Verweis auf die Organisationszugehörigkeit enthalten sein soll. Des Weiteren soll zur Differenzierung eine eindeutige Kurzbezeichnung vergeben werden. Zudem muss der Administrator einem neuen Benutzer ein Passwort zuweisen und ihm dieses mitteilen, so dass die Software heruntergeladen werden kann und eine Anmeldung möglich ist. Bei Organisationen soll automatisch die Basisordnerstruktur inklusive des Dokuments zur Speicherung der Baumstruktur auf dem Server angelegt werden. Neben dem Erfassen neuer Nutzer muss es möglich sein, Stammdaten zu aktualisieren und vorhandene Einträge zu löschen. Das Löschen von Organisationen soll dabei immer möglich sein. Benutzer sollen aber nur gelöscht werden können, sofern in der Wissensbasis kein Wissen dieses Anwenders hinterlegt ist. Dies soll gewährleisten, dass die Quelle von gespeicherten Informationen immer nachvollzogen werden kann.
Damit alle Anwender innerhalb einer Organisation auf gemeinsame Daten zugreifen können, sollen Stammdaten in einer Datenbank und das Wissen in Extensible Markup Language (XML) Dokumenten auf einem Server abgelegt werden. Diese Zweiteilung beruht auf der Tatsache, dass die Erfassung von Nutzerdaten nur der Verwaltung von Zugangsberechtigungen dienen soll, das Wissen aber unabhängig von einer Datenbank ausgetauscht werden kann. Mit Hilfe der Speicherfunktion soll es möglich sein, das lokal erfasste Wissen auf einem Server strukturiert abzulegen. Dies setzt voraus, dass eine Netzwerkverbindung etabliert und der Server gestartet ist.
Die Funktion Anmelden soll zur Verifizierung von Zugangsberechtigungen und dem Bestimmen der Benutzerrolle sowie dem Laden der zugehörigen aktuellen Daten dienen. Bei Beendigung der Anwendung soll eine Frage zur Speicherung generiert werden, sofern noch nicht alle neu eingegebenen bzw. geänderten Daten auf dem Server abgelegt wurden. Der Verlust von Informationen wird somit vermieden.
Neben den hier vorgestellten Musskriterien, d. h. Anforderungen, die für den Einsatz der Software unabdingbar sind, können in nachfolgenden Versionen weitere Funktionen implementiert werden [BALZ01, S. 115]. Dazu gehören eine Versionsverwaltung, die Erweiterung der Benutzerrollen, die Implementierung einer umfangreichen Testkomponente, der automatische Wissenserwerb oder die Mehrsprachigkeit.
Da Wünsche an ein Produkt im Allgemeinen sehr umfangreich sind und diese leicht formuliert werden können, wird an dieser Stelle noch einmal darauf hingewiesen, dass die zu entwickelnde Software nur den Wissenserwerb für regelbasierte Expertensysteme unterstützen soll, wobei Regeln auf sicheren Ereignissen beruhen und keine Simulationen durchführbar sind.
3.2 Nichtfunktionale Anforderungen
An die zu entwickelnde Software müssen neben den funktionalen weitere Anforderungen gestellt werden. Dies betrifft bei der vorliegenden Anwendung primär die Gestaltung der Benutzeroberfläche. Abbildung 3-2 skizziert die identifizierten und zu implementierenden Komponenten. Der Bildschirm ist in drei Bereiche unterteilt. Auf der linken Seite befindet sich eine Baumdarstellung zur strukturierten Verwaltung der erfass- ten Objekte. Die zur Eingabe von Daten notwendigen Formulare und die Modellierungsebene für die Definition von Regeln werden rechts im Hauptfenster angezeigt. Falls die darzustellenden Informationen innerhalb eines Rahmens den sichtbaren Bereich überschreiten, soll mittels Bildlaufleisten navigiert werden können. Durch die Implementierung von Reitern im oberen Teil ist es möglich, mehrere Fenster gleichzeitig geöffnet zu halten, wodurch der Arbeitsfluss beschleunigt wird. Notwendige Kommandos für den Wissenserwerb befinden sich an gewohnter Stelle im Menü am oberen Bildschirmrand, wobei häufig genutzte Befehle, wie bspw. das Speichern, als Symbole in der Werkzeugleiste angezeigt werden. Weiterhin sollen sog. Pop-Up-Menüs es ermöglichen, durch Betätigen der Maustaste alle Funktionen, die innerhalb des aktuellen Kontexts ausführbar sind, anzuzeigen und auszuwählen [SEEM00, S. 221f.].
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 3-2: Benutzeroberfläche
Alle Eingabemasken sollen den in Abbildung 3-3 skizzierten Aufbau besitzen. In Abhängigkeit des zu spezifizierenden Wertes erfolgt die Eingabe in unterschiedlichen Formaten (Kurztext, Langtext, Auswahlmenü, etc.). Zur weiteren Unterstützung des Anwenders sollen in Abhängigkeit der Benutzerrolle bestimmte Wertebereiche vorbelegt werden. Die Attribut-Wert-Kombinationen für verschiedene Objekte können so systematisch bei einheitlicher Darstellung und Anordnung erfasst werden.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 3-3: Eingabemaske
3.3 Technische Produktumgebung
Im Wesentlichen gibt es zwei Alternativen für die Verteilung einer Anwendung im Netz. Bei der Web-Architektur befindet sich auf dem Client nur ein Browser, der Rest der Anwendung auf einem oder mehreren Servern. Entscheidender Nachteil hierbei ist, dass bei einer Nutzung der Anwendung die gesamte Software geladen werden muss. Reaktionszeiten und Netzbelastung sind damit inakzeptabel. Als Alternative bietet sich die Client/Server-Architektur an, wobei sich der Hauptteil der Applikation beim Client befinden und der Server nur zur Bereitstellung von Ressourcen in Form von Daten und Dokumenten dient [BALZ01, S. 691].
Die Umsetzung der zu entwickelnden Software soll ausschließlich auf Basis von Open- Source-Produkten erfolgen. Hierbei handelt es sich um Softwareprodukte, die zur freien Verfügung stehen und somit keine direkten Kosten verursachen [HANS01, S. 160]. Als Programmiersprache dient Java. Damit eng verbunden sind die Distribution und Installation der Software sowie die Verteilung von Updates. Realisiert werden sollen diese Prozesse mit Hilfe von Java Web Start - einer Technologie, die es erlaubt, Software in einer sicheren Weise über das Internet zu verteilen. Zu diesem Zweck wird ein Webserver benötigt, von welchem alle notwendigen Ressourcen bezogen werden können [SUN03a, o. S.]. Hierzu gehören die Software, Bilder und sog. Dokumenttyp-Definitionen (DTD), auf die im Laufe der Arbeit näher eingegangen wird. Genutzt werden soll der Apache-Server, da dieser nicht nur einen sicheren und effizienten Service ermöglicht, sondern die für die Java Web Start Technologie notwendige Erweiterung unterstützt [APAC03, o. S.]. Zur Gewährleistung einer leistungsfähigen, zuverlässigen, aber einfachen Datenbankanbindung soll das Produkt MySQL verwendet werden [MYSQ03, o. S.]. Die zugrundeliegende Produktumgebung ist in Abbildung 3-4 zusammenfassend dargestellt.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 3-4: Technische Produktumgebung
Für eine Nutzung der Software müssen beim Clientrechner Java Web Start und die Java Virtual Machine installiert sowie eine Netzwerkverbindung zum Server etabliert sein. Vorrausetzungen für den Serverrechner, der eine einfache Arbeitsstation sein kann, sind die dortige Installation der Java Virtual Machine und der Anschluss des Rechners an ein Inter- bzw. Intranet. Weiterhin müssen der Datenbank- und der Webserver sowie die dortige Java-Applikation gestartet sein, so dass deren Dienste in Anspruch genommen werden können. Die Kommunikation zwischen den Clients und dem Server soll durch entfernte Prozeduraufrufe realisiert werden, so dass ein direkter Zugriff auf Serverressourcen durch die Clientanwendung nicht möglich ist und ein sicherer Datenaustausch stattfinden kann [BENG00, S. 110f.]. Schließlich ist für die Ablage aller Dateien eine entsprechende Ordnerstruktur auf dem Serverrechner zur Verfügung zu stellen.
4 Entwurf und Implementierung der identifizierten Anforderungen
Auf der Anforderungsanalyse aufbauend muss ein Produktentwurf konzipiert werden, der die Softwarearchitektur beschreibt und eine Spezifikation der Systemkomponenten enthält. Bestandteile des Entwurfs sind die Verteilung der Anwendung im Netz, die Modellierung von Daten, die Entwicklung der für die Umsetzung benötigten Java-Klassen und Entscheidungen über die konkrete Gestaltung der Benutzeroberflächen [BALZ01, S. 686-688]. Zur Veranschaulichung der hier vorgestellten Konzepte werden Ergebnisse an Hand der konkreten Implementierung vorgestellt.
4.1 Organisation des Gesamtsystems
Viele Anwendungen werden, insbesondere im betrieblichen Bereich, auf mehrere Computer in einem Netzwerk verteilt. Dadurch wird erreicht, dass die im Unternehmen existierenden Anwendungssysteme, Datenbestände und Rechner- bzw. Geräteleistungen gemeinsam genutzt werden können. Bei der Entwicklung neuer Software stellt sich somit die Frage nach der zweckmäßigen Verteilung von Daten und Programmteilen auf die verschiedenen Rechner [BALZ01, S. 703]. Die hier vorliegende Applikation greift auf das Client/Server-Architekturmodell zurück, das nachfolgend unter besonderer Berücksichtung der sicheren Kommunikation zwischen beiden Teilkomponenten näher betrachtet wird.
Ein Client/Server-System besteht aus zwei logischen Teilen: Einem Server, der einen Service oder Daten bereitstellt und auf Anfrage ausführt bzw. sendet und einem oder mehreren Clientrechnern, die die Serverressourcen in Anspruch nehmen [BENG00, S. 29]. Die wichtigsten Serverarten sind Daten-, Kommunikations-, Druck- und Anwendungsserver. Ein Kommunikationsserver verwaltet eingehende und ausgehende elektronische Post und ermöglicht Netzübergänge zwischen verschiedenen Netzwerken. Die Verwaltung von Druckern und Druckaufträgen wird von einem Druckserver übernommen und die komplette Anwendungslogik wird durch einen Anwendungsserver realisiert, wie z. B. bei der Software SAP R/3 [STAH99, S. 148f.]. Die hier vorliegende Software implementiert einen Datenserver in Form eines kombinierten Datei- und Datenbankservers.
[...]
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen.