Entwicklung eines Werkzeugs zur grafischen Definition von Regeln in einem Expertensystem

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 aller­dings 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 Inte­resse ausschließlich auf allgemeinen Problemlösungsmethoden lag, hat sich die ent­scheidende 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 kon­ventionellen 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 inner­halb kurzer Zeit und wird somit ungültig bzw. fehlerhaft. Des Weiteren kann nicht er­wartet 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 unver­meidbar sind. Entscheidend für den erfolgreichen Einsatz von Expertensystemen ist so­mit die Bereitstellung einer Softwarekomponente, die es ermöglicht, eine Wissensbasis aufzubauen sowie den Wissensbestand von im Einsatz befindlichen Systemen zu ver­größ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 Kommunika­tion mit Fachleuten Wissen aneignet und dieses dann für ein Expertensystem formali­siert. Diese indirekte Form des Wissenserwerbs ist nicht nur teuer, sondern wegen der inhärenten Verständigungsprobleme beider Parteien auch fehleranfällig. Wenn man be­denkt, 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 aller­dings bisher auf Grund des Fehlens einer geeigneten Softwarelösung, die es einem Ex­perten 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 Wis­sensbasis nicht von den Personen durchgeführt wird, die für die Realisierung des Sys­tems verantwortlich waren, sondern vom Experten selbst. Diese Konstellation kann zu Schwierigkeiten führen, die die Effizienz des Expertensystems in Frage stellen. Gleich­zeitig 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 Werk­zeug zu entwickeln, welches in einer Weise komfortabel und problemadäquat gestaltet ist, dass ein Experte selbstständig und ohne weitere Unterstützung von anderen Perso­nen sein Wissen erfassen, ändern und testen kann. Solche Werkzeuge würden den Um­gang mit Wissen in den verschiedensten Anwendungsbereichen fundamental ändern, da das bisher weitgehend private Wissen von Experten, das darüber hinaus nur über lang­jährige Praxiserfahrungen erworben werden kann, dann in Programmen explizit darge­stellt 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 Di­agnosen. 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 ver­schiedensten Anwendungsgebieten einsetzbar sein. Dies impliziert, dass das Werkzeug bei verschiedenen Organisationen und innerhalb dieser von mehreren Experten gleich­zeitig genutzt werden kann. Ein weiterer Teil dieser Arbeit befasst sich mit den Mög­lichkeiten zur Erweiterung des umgesetzten Systems. Diese werden auf Grund be­grenzter Ressourcen nur theoretisch behandelt.

Eine umfassende Dokumentation ist ein integraler Bestandteil der Software-Entwick­lung 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 voran­gegangen 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 Ka­pitel 2 die für die weiteren Betrachtungen relevanten theoretischen Grundlagen bezüg­lich 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 Kon­kretisierung der daraus hervorgehenden funktionalen und nichtfunktionalen Anforde­rungen, welche das zu entwickelnde Softwareprodukt erfüllen muss bzw. solche, die vom Anwender als wünschenswert zu betrachten sind. Hinsichtlich der technischen Re­alisierung wird aufgezeigt, welche Software-Systeme und Hardware-Komponenten zum Einsatz kommen und unter welchen organisatorischen Bedingungen die Software einge­setzt 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. Server­komponente und deren Kommunikation sowie die Distribution der Software. Insbeson­dere wird auf die mit der Kommunikation und Softwareverteilung verbundenen Sicher­heitsaspekte näher eingegangen. Anschließend erfolgt eine Modellierung der zu spei­chernden Daten, welche sowohl in einer relationalen Datenbank als auch in Dateien ab­gelegt werden. Da Letztere die grundsätzliche Art und Weise der Speicherung darstellt,

werden insbesondere dessen Struktur und Funktionsweise detailliert beschrieben. In ei­nem weiteren Abschnitt wird auf die wichtigsten für eine Umsetzung benötigten Klas­sen 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 Da­tenerfassung diskutiert.

Da auf Grund der begrenzten Ressourcen eine vollständige Implementierung aller iden­tifizierten 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 kon­krete Lösungsmöglichkeiten aufgezeigt.

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

2 Regelbasiertes Expertensystem

Um für die Untersuchungen dieser Arbeit einen wissenschaftlichen Rahmen aufzuzei­gen, 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 nachge­bildet werden sollen [GABL97a, S. 257]. Zentrale Annahme dieses Ansatzes ist, dass sich Problemlösungen aus Einzelkenntnissen zusammensetzen, welche von Experten se­lektiert 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 konse­quente Trennung von anwendungsspezifischem Wissen und der Problemlösungsstrate­gie. In vielen Anwendungsbereichen ist eine solche Trennung möglich und charakteris­tisch 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 ne­ben 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 Vorkennt­nisse.

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 Expertensyste­men 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 zwi­schen Wissen und Problemlösungsstrategien spiegelt sich in den beiden Modulen Wis­sensbasis und Steuersystem wieder.

Die Wissensbasis bildet die Grundlage des Expertensystems. Das darin enthaltene Wis­sen kann auf unterschiedliche Weise klassifiziert werden. Nach der Herkunft des Wis- sens wird zwischen bereichsbezogenem Wissen von Fachleuten, fallspezifischem Wis­sen von Benutzern sowie Zwischen- und Endergebnissen, welche von der Problemlö­sungskomponente hergeleitet worden sind, unterschieden. Je nach Gebrauch des Wis­sens 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 vorgegebe­nen Strategie und generiert hieraus eine Lösung für das vom Benutzer spezifi­zierte Problem.
- Aufgabe der Interviewerkomponente ist es, den Dialog mit dem Benutzer zu len­ken 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 Entscheidungs­unterstü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. Ta­belle 2-2). So ist meist das Ziel von Interpretation, Diagnose und Überwachung, ein be­kanntes 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 wer­den. 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 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 Anwen­dungsbereichs. Von Repräsentation kann aber nur gesprochen werden, wenn neben der Wissensdarstellung auch Angaben über dessen Verwendung erfasst sind. Zur Formali­sierung des Wissens sind verschiedene Methoden entwickelt worden. Die meist ver­wendeten 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 Unsicher­heit, 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 Grund­techniken 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 Wis­sensbasis 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 Kon­sequenz. Sie besitzt die allgemeine Form: „WENN Bedingungsteil DANN Aktion“. In­nerhalb 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 dar­stellt. Die Komplexität der Vorbedingungen reicht dabei vom einfachen Abfragen der Wissensbasis über das Nachschauen und anschließendem Rechnen bis hin zu Muster­vergleichen. 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 Steue­rung. Die beiden grundlegenden Problemlösungsmethoden zur Auswertung der Wis­sensrepräsentation sind Vorwärts- und Rückwärtsverkettung. Bei der Vorwärtsverket­tung werden ausgehend von der vorhandenen Datenbasis Regeln gesucht, deren Vorbe­dingung 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 ei­ne Wissensbasis modular und damit leicht änderbar. Daher sollte im Idealfall jede rele­vante 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 Prob­lemlösung benötigten Wissens. Expertensysteme erleichtern diese Aufgabe im Ver­gleich zu konventionellen Programmen durch die Trennung von Wissen und der Prob­lemlö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 Er­gebnis sind verbale Aufzeichnungen, die anschließend interpretiert und formalisiert werden müssen. Vorherrschende und ergiebigste Erhebungstechnik ist dabei die münd­liche Befragung in Form eines Interviews [PUPP88, S. 115]. Dieses konzentriert sich meist auf nur einen Gesprächspartner, sollte strukturiert werden und nach einer schriftli­chen Vorlage ablaufen [STAH99, S. 254f.]. Hauptproblem dabei ist, dass der Intervie­wer 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, unzurei­chende Motivation unter den Befragten vorherrscht oder Experten Schwierigkeiten ha­ben, Vorgehensweisen zu erklären. Einige dieser Probleme lassen sich durch die Bereit­stellung eines geeigneten Werkzeugs zur Wissensakquisition verringern bzw. eliminie­ren.

Ist ein komfortables Wissenserwerbssystem vorhanden, kann der Experte selbst das Wissen formalisieren. Ein Wissensingenieur als Intermediär wird dann nicht mehr be­nötigt. Für eine komfortable Kommunikation auf einer angemessenen Abstraktions­ebene 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­tene,
- Gleichartigkeit des Eingabe- und Änderungsmodus mit der Möglichkeit der so­fortigen Überprüfbarkeit von Änderungen und
- Bereitstellung und Verwaltung von Testmechanismen.

Anzumerken bleibt, dass ein Wissensakquisitionssystem den Experten um so besser un­terstü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, wel­che Leistungen für das zu entwickelnde System unabdingbar sind, damit es für den vor­gesehenen Einsatzzweck genutzt werden kann. Diese sind ihrer Natur nach vage, un­vollstä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­gen 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 ein­zelnen Rollen Experte, Administrator und Superadministrator deutlich. Dabei ist zu be­achten, dass eine Instanz des spezialisierten Akteurs ebenfalls als Akteur in der verall­gemeinerten Rolle auftreten kann. Ein Experte besitzt die Möglichkeit, der An- und Ab­meldung, 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 in­nerhalb der eigenen Organisation. Da die Nutzung der Software nicht auf eine Institu­tion 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 Defini­tion 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 Endbe­nutzer 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 er­mö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 Ob­jekten muss eine eindeutigen Kurzbeschreibung vergeben werden.

Die Modellierung von Regeln als zweite Kernfunktion soll es dann dem Benutzer er­mö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 darge­stellt 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 vari­ieren sowie Abhängigkeiten aufzuheben. Hilfen in Form von farblichen Markierungen verwendeter Objekte in der Baumhierarchie und der Modellierungsebene, die Möglich­keit zur räumlichen Navigation und zur Anzeige von Detaildaten eines Objekts, das Hinzufügen von Kurzbezeichnungen unterhalb von dargestellten Symbolen sowie Hin­weise 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 In­formation 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 die­nen. 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 Differenzie­rung eine eindeutige Kurzbezeichnung vergeben werden. Zudem muss der Administra­tor einem neuen Benutzer ein Passwort zuweisen und ihm dieses mitteilen, so dass die Software heruntergeladen werden kann und eine Anmeldung möglich ist. Bei Organisa­tionen soll automatisch die Basisordnerstruktur inklusive des Dokuments zur Speiche­rung 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 sol­len 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 In­formationen 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 lo­kal 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 die­nen. Bei Beendigung der Anwendung soll eine Frage zur Speicherung generiert werden, sofern noch nicht alle neu eingegebenen bzw. geänderten Daten auf dem Server abge­legt 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 Testkompo­nente, 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 Simulatio­nen durchführbar sind.

3.2 Nichtfunktionale Anforderungen

An die zu entwickelnde Software müssen neben den funktionalen weitere Anforderun­gen gestellt werden. Dies betrifft bei der vorliegenden Anwendung primär die Gestal­tung der Benutzeroberfläche. Abbildung 3-2 skizziert die identifizierten und zu imple­mentierenden Komponenten. Der Bildschirm ist in drei Bereiche unterteilt. Auf der lin­ken Seite befindet sich eine Baumdarstellung zur strukturierten Verwaltung der erfass- ten Objekte. Die zur Eingabe von Daten notwendigen Formulare und die Model­lierungsebene für die Definition von Regeln werden rechts im Hauptfenster angezeigt. Falls die darzustellenden Informationen innerhalb eines Rahmens den sichtbaren Be­reich überschreiten, soll mittels Bildlaufleisten navigiert werden können. Durch die Implementierung von Reitern im oberen Teil ist es möglich, mehrere Fenster gleichzei­tig geöffnet zu halten, wodurch der Arbeitsfluss beschleunigt wird. Notwendige Kom­mandos 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 er­mö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 Ab­hä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 vorbe­legt 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 Instal­lation 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 Webser­ver benötigt, von welchem alle notwendigen Ressourcen bezogen werden können [SUN03a, o. S.]. Hierzu gehören die Software, Bilder und sog. Dokumenttyp-Definitio­nen (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ög­licht, sondern die für die Java Web Start Technologie notwendige Erweiterung unter­stü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 Serverres­sourcen 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 An­forderungen

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-Klas­sen 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 Com­puter in einem Netzwerk verteilt. Dadurch wird erreicht, dass die im Unternehmen exis­tierenden Anwendungssysteme, Datenbestände und Rechner- bzw. Geräteleistungen gemeinsam genutzt werden können. Bei der Entwicklung neuer Software stellt sich so­mit 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 Be­rücksichtung der sicheren Kommunikation zwischen beiden Teilkomponenten näher be­trachtet 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 Anwen­dungsserver. Ein Kommunikationsserver verwaltet eingehende und ausgehende elektro­nische Post und ermöglicht Netzübergänge zwischen verschiedenen Netzwerken. Die Verwaltung von Druckern und Druckaufträgen wird von einem Druckserver übernom­men und die komplette Anwendungslogik wird durch einen Anwendungsserver reali­siert, 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 Da­tenbankservers.

[...]