Zusammenfassung
Der Prozeß der Entwicklung und Wartung wissensbasierter Systeme wird als ‘Knowledge Engineering’ bezeichnet1. Im Rahmen der Entwicklung wissensbasierter Systeme lassen sich zwei globale Phasen unterscheiden2:
-
Wissensakquisition bezeichnet den Auf- und Ausbau einer Wissensbasis, indem Wissen des relevanten Themenbereichs aus der Literatur oder von Fachleuten erhoben und gesammelt wird.
-
Wissensrepräsentation ist die formale Darstellung des Wissens mit Hilfe der verschiedenen im Bereich der Künstlichen Intelligenz entwickelten Techniken.
This is a preview of subscription content, log in via an institution to check access.
Access this chapter
Tax calculation will be finalised at checkout
Purchases are for personal use only
Preview
Unable to display preview. Download preview PDF.
Anmerkungen zu Kapitel 5
Vgl. Feigenbaum /Art/ 228 ff. und Schmitz /Expertensysteme/ 619 f. Vgl. zu einer anderen Definition Lenz /Expertensysteme/ 26 f.
Vgl. hierzu und zu den folgenden Aussagen Schmitz, Lenz /Abgrenzung/ 506 ff. und Schmitz, Lenz /Glossar ’89/ 1 ff. Vgl. zu einer Zuordnung der Phasen des Software Engineering zu denen des Knowledge Engineering Schmitz, Lenz /Abgrenzung/ 506 ff. Vgl. zu den Hauptabschnitten der Phasen der Systementwicklung Schmitz, Seibt /Einführung 3/ 8 ff.
Vgl. zu einem Überblick über die vorgeschlagenen Vorgehensweisen Karbach, Linster /Wissensakquisition/ 21 ff.; Karbach /Methoden/ 7 ff. und Lenz/Expertensysteme/ 91 ff.
Vgl. Karbach /Wissensakquisition/ 13; Lenz /Grundlagen/ 3 und Schmitz /Expertensysteme/ 620. Detaillierte Vergleiche der beiden Ansätze finden sich in Karbach /Methoden/ 10 ff.; Karbach, Linster /Wissensakquisition/ 9 ff.; Lenz /Expertensysteme/ 91 ff. und Schweneker /Entwicklung/ 4 ff. Neben den beiden grundsätzlichen Ansätzen sind auch Mischformen vorgeschlagen worden, die die Vorteile beider Ansätze kombinieren sollen. Vgl. z. B. Lenz/Expertensysteme/122 ff. und Schweneker/Entwicklung/17 ff.
Vgl. Lenz /Expertensysteme/ 98 ff. und Schmitz /Expertensysteme/ 620. Dem Ansatz des Rapid Prototyping sind z. B. die Vorgehensweisen von Buchanan u. a., von Harmon und King sowie von Hayes-Roth zuzuordnen. Vgl. Buchanan u. a. /Constructing/ 127 ff.; Harmon, King /Expertensysteme/ 218 ff. und Hayes-Roth /Tutorial/ 18 ff. Weitere Ansätze, die sich dem Rapid Prototyping zurechnen lassen, finden sich in Karbach, Linster /Wissensakquisition/ 21 ff.
Vgl. zu weiteren Vor- und Nachteilen Lenz /Expertensysteme/ 98 ff. und Schweneker /Entwicklung/ 7 ff.
Vgl. Lenz /Expertensysteme/ 107 ff. und Schmitz /Expertensysteme/ 620 f. Die ‘modellbasierte Vorgehensweise’ wird z. T. auch als ‘modellorientierter Ansatz’, ‘modellbasierte Systementwicklung’ oder ‘modellgestützte Vorgehensweise’ bezeichnet. Diese Begriffe werden im Rahmen dieser Arbeit synonym verwendet. Dem modellorientierten Ansatz ist z. B. das im Rahmen des europäischen Forschungsprogramms ESPRIT entwickelte ‘Knowledge Acquisition and Design Structuring’ oder ‘Knowledge Acquisition, Documentation and Structuring’ (KADS) zuzuordnen. Vgl. Breuker u. a. /Knowledge Acquisition/ 1 ff.; Breuker, Wielinga /Models/ 265 ff. und Hickman u. a. /Analysis/12 ff. Vgl. zur Beschreibung weiterer modellorientierter Ansätze Nwana u. a. /Development/ 60 ff.
Ohne ein explizites Modell besteht die Gefahr, daß die vom Systementwickler gemachten Prämissen im System verborgen werden und deshalb nur schwer überprüfbar sind. I. d. R. haben auch die Entwickler eines Prototypen ein bestimmtes Modell der Realität ’im Kopf. Der Unterschied zum modellbasierten Vorgehen besteht darin, daß die grundlegenden Annahmen, Prämissen und Denkstrukturen der Entwickler beim Rapid Prototyping erst im Prototypen selbst zum Ausdruck kommen. Dort sind sie für Dritte schwerer zu verifizieren als in einer expliziten Dokumentation außerhalb des Prototypen.
Vgl. Schmitz, Lenz, Nöcker /Dialogbeitrag/ 263
Vgl. zu weiteren Vor- und Nachteilen Lenz /Expertensysteme/ 117 ff. und Schweneker /Entwicklung/ 9 ff.
Vgl. Lutze /Wissensakquisition/ 220 ff. und Heilmann, Simon /Expertensysteme/ 9
Tatsächlich sind in einigen Konzepten, die dem ‘Rapid Prototyping’ zuzuordnen sind, Elemente der konzeptuellen Modellierung enthalten. So stellen z. B. Buchanan u. a. und Hayes-Roth der Phase ‘Implementierung’ die Phasen ‘Identifizierung’, ‘Konzeptualisie-rung’ und ‘Formalisierung’ voran. Vgl. Buchanan u. a. /Constructing/ 127 ff. und Hayes-Roth /Tutorial/ 18 f. Allerdings sind die Modellierungsaspekte nicht in allen Vorgehensweisen zur Entwicklung von Prototypen explizit angelegt. Vgl. z. B. Harmon, King /Expert Systems/135 ff.
Vgl. Schmitz, Lenz, Nöcker /Dialogbeitrag/ 263
Im Rahmen des bereits erwähnten Forschungs- und Entwicklungsprojekts des BIFOA (vgl. Kap. 1.3) wurde auf der Basis eines konzeptionellen Modells, das dem in dieser Arbeit entwickelten Modell sehr ähnlich ist, ein Prototyp erstellt. Durch die Entwicklung dieses Prototypen wurden verschiedene Anregungen gewonnen, die zur Verfeinerung und zur Detaillierung des konzeptionellen Modells führten. Insofern wurde die modellbasierte Vorgehensweise, ähnlich wie von Lenz und Schweneker vorgeschlagen, um das Prototyping ergänzt Vgl. Lenz/Expertensysteme/ 122 ff. und Schweneker/Entwicklung/ 17 ff.
Vgl. Buchanan u. a. /Constructing/ 127 ff. Die im Rahmen dieser Arbeit gewählte Struktur entspricht nicht exakt den Vorschlägen von Buchanan u. a., sondern lehnt sich an diese an.
Die Strukturierung in vier Modelle ist z. B. auch im Rahmen des im ESPRIT-For-schungsprogramms entwickelten ‘Knowledge Acquisition and Design Structuring’ (KADS) gewählt worden. Vgl. hierzu Breuker u. a. /Knowledge Acquisition/ und Breuker, Wielinga /Models/ 265 ff. Allerdings werden die Modellinhalte in KADS anders aufgeteilt und dargestellt, als das im Rahmen dieser Arbeit der Fall ist. Vgl. zu einer weiteren Strukturierungsmöglichkeit der Modelle Lenz /Expertensysteme/ 107 ff.
Die Begriffe ‘konzeptuell’ und ‘konzeptionell’ werden im folgenden synonym verwendet.
In der Abbildung wird von den Überlagerungen der Phasen und den vielfältigen Rückkopplungsprozessen abstrahiert.
Vgl. hierzu die Liste der Gesprächspartner im Anhang zu dieser Arbeit
Das konzeptuelle Modell läßt sich wiederum in verschiedene Teilmodelle unterteilen, die in Kap. 5.2 abstrakt und in Kap. 7 konkret für die Risikoanalyse erörtert werden.
In vielen Fällen werden Projekte zur Entwicklung wissensbasierter Systeme initiiert, weil man glaubt, die entsprechenden Problemstellungen nicht mit konventionellen Verfahren bewältigen zu können. Ist die entsprechende Domäne mit Methoden des Knowledge Engineering strukturiert und aufbereitet worden, so zeigt sich allerdings oft, daß entweder ein großer Teil oder sogar die gesamte Problemlösung konventionell programmiert werden kann. Vgl. zu solchen Erfahrungen z. B. Marioni, Neukom /Expertensystem/ 43
Laske unterteilt dieses Modell weiter in einen ‘allgemeinen’ und einen detaillierten Systementwurf. Vgl. Laske /Probleme/ 5 ff.
In Kap. 7 werden die hier abstrakt dargestellten Teilmodelle für die Risikoanalyse konkretisiert.
Konzeptionelle Modelle sind im Rahmen der seit 1988 stattfindenden ‘Computer Security Risk Management Model Builders Workshops’ vorgestellt worden. Vgl. Bonyun, Jones /Approach/ 203 ff.; Bonyun, Jones /Method/ 1–1 ff.; Browne /Framework/ 3; Hoffman /Prototype/ 135 ff; Katzke /Risk Management/ 3 ff.; Lewis /Risk Analysis/ 35 ff.; Mayerfeld /Framework/ 1 ff.; Mayerfeld /Risk Management/ 25 ff.; Moses, Glover /Risk Analysis/ 243 ff.; Moses, Glover /CRAMM/ 1 ff.; Schmidt /Model/ 89 ff:; Smith /Expert System/ 179 ff.; Smith /LAVA/ 3 und Snow /Model/ 149 ff. Reitenspieß hat die verschiedenen Ansätze übersichtlich zusammengefaßt Vgl. Reitenspieß /Sicherheitsmaßnahmen/ 9 ff.
Gründe für diese Entscheidung werden im folgenden erörtert Vgl. zu einem detaillierten Vergleich verschiedener Analyse- und Darstellungsmethoden Coad, Yourdan /Analysis/ 18 ff.
Vgl. Ferstl, Sinz /Objektmodellierung/ 567 f. und Sinz /ooA/ 457
Vgl. zur objektorientierten Analyse und zum objektorientierten Entwurf z. B. Budde u. a. /Entwurf/ 13 ff.; Coad, Yourdan /Analysis/ 1 ff.; Meyer /Softwareentwicklung/ 54 und Rumbaugh u. a. /Design/ 1 ff.
Vgl. zur Unterscheidung in objektorientierten Entwurf und objektorientierte Programmierung auch Kap. 1.4
Bisher hat sich noch keine einheitliche Entwurfsmethodik im Rahmen des objektorientierten Ansatzes herausgebildet. Vgl. König /Anwendungssysteme/ 210. Die verschiedenen publizierten Ansätze unterscheiden sich in den Schwerpunkten und in der Anzahl der Teilmodelle, umfassen aber im wesentlichen die gleichen Inhalte. Vgl. Coad, Yourdan /Analysis/ 52 ff.; Karbach /Methoden/ 38 f.; Karbach /Wissensakquisition/ 13; Rumbaugh u. a. /Design/ 16 ff. Am sinnvollsten erscheint eine Einteilung des Modells in drei Teilmodelle, mit denen die eher statischen Objekt- bzw. Datenstrukturen, die dynamischen Ablaufstrukturen und die vom System auszuführenden Funktionen beschrieben werden. Vergleichbare Ansätze werden z. B. von folgenden Autoren verfolgt: vgl. Berberich u. a. /Expertensystem/ 34 ff.; Ferstl, Sinz /Objektmodellierung/ 567 ff. und Rumbaugh u. a. /Design/ 16 ff. Seibt bezeichnet die Gestaltungsdimensionen Daten, Abläufe und Funktionen als Teilaspekte der Systemgestaltung. Neben diesen Aspekten müssen weitere Gesichtspunkte erörtert werden. Vgl. Seibt/Informationssystem-Architekturen/ 261 ff. Diese Aspekte gehören jedoch nicht zum konzeptionellen Modell des Softwaresystems im engeren Sinne, sondern zur Modellierung des gesamten Informationssystems. Vgl. zu weiteren wichtigen Aspekten der Systemgestaltung z. B. die Ausführungen zur organisatorischen Einbettung der Systemnutzung in Kap. 8.5 oder zu Möglichkeiten zur Gestaltung der Benutzeroberfläche in Kap. 8.2. Die in dieser Arbeit verwendeten Begriffe lehnen sich an die von Rumbaugh u. a. verwendete Terminologie an. Vgl. Rumbaugh u. a. /Design/ 16 ff.
Die folgenden Ausführungen zur Entwicklung eines Objektmodells lehnen sich an die von Coad und Yourdan entwickelte ‘objektorientierte Analyse’ und den von Rumbaugh u. a. entwickelten Ansatz ‘Object-Oriented Modelling and Design’ an. Vgl. Coad, Yourdan /Analysis/ 1 ff. und Rumbaugh u. a. /Design/ 1 ff. Vergleichbare Ansätze sind z. B. von Ferstl, Sinz und von Stoyan entwickelt worden. Vgl. Ferstl, Sinz /Objektmodellierung/ 566 ff. und Stoyan /Systementwicklung/ 3 ff. Korson und McGregor stellen weitere Ansätze vor. Vgl. Korson, McGregor /Paradigm/ 41
Vgl. Ferstl, Sinz /Objektmodellierung/ 568; Rathke /Wissensrepräsentation/ 52; Rumbaugh u. a. /Design/ 22 und Stoyan /Systementwicklung/ 4.
Vgl. Ferstl, Sinz /Objektmodellierung/ 568; Rathke /Wissensrepräsentation/ 51 und Stoyan, Görz /Programmierung/15
Die Begriffe ‘Objekt’ und ‘Instanz’ sind in der Literatur nicht einheitlich definiert. Coad und Yourdan verwenden beide Begriffe synonym. Vgl. Coad, Yourdan /Analysis/ 53. Rathke unterscheidet zwei Arten von Objekten: Klassen und Instanzen. Vgl. Rathke /Wissensrepräsentation/ 55. Laut Stoyan und Görz ist jeder Gegenstand in einem objektorientierten System ein Objekt. Vgl. Stoyan, Görz /Programmierung/ 10 ff. Als Synonyme für den Begriff ‘Instanz’ werden auch die Begriffe ‘Exemplar’ oder ‘Inkarnation’ verwendet. Vgl. Moser /Programmieren/ 52; Neunast, Helden /Programmentwicklung/ 256 und Stoyan, Görz /Programmierung/ 14
Vgl. Coad, Yourdan /Analysis/ 119 ff.; Rathke /Wissensrepräsentation/ 52 und Rumbaugh u. a. /Design/ 23. Die Attributwerte werden auch als ‘Instanzenvariablen’ bezeichnet. Vgl. Bolkart /Programmiersprachen/ 238
Vgl. Rumbaugh u. a. /Design/ 57 ff.
Sofern für das Verständnis erforderlich, wird zwischen ‘Beziehungstypen’ und ‘Beziehungen’ unterschieden: ‘Beziehungstypen’ sind Verbindungen zwischen Klassen (abstrakte Verbindungen). ‘Beziehungen’ sind Verbindungen zwischen Instanzen (konkrete Verbindungen). Die Klasse ‘Immobilien’ läßt sich beispielsweise über den Beziehungstyp ‘enthält’ mit der Klasse ‘Hardware’ verbinden. Die Instanz ‘Haus xyz’ kann über die Beziehung ‘enthält’ mit der Instanz ‘Rechner 123’ verbunden werden. Wenn aus dem Kontext deutlich hervorgeht, ob ein Beziehungstyp oder eine Beziehung gemeint ist, wird vereinfachend der Begriff ‘Beziehung’ verwendet.
Vgl. Budde u. a. /Entwurf/ 17
Vgl. Wedekind /Objektorientierung/ 84
Vgl. hierzu Wedekind /Objektorientierung/ 84 und Kap. 5.3.2.4
Vgl. Ferstl, Sinz /Objektmodellierung/ 568 und Rumbaugh u. a. /Design/ 36 ff.
Vgl. Wedekind /Objektorientierung/ 84
Sager/Begriffe/38
Vgl. hierzu z. B. Ferstl, Sinz /Objektmodellierung/ 573 f. Laut Coad und Yourdan sind Aggregation und Klassifikation Beziehungen, die i. d. R. auf ganze Klassen wirken. Alle anderen Beziehungen setzen tendenziell an den Instanzen an. Vgl. Coad, Yourdan /Analysis/ 126 ff.
Vgl. hierzu Kap. 7.1.4
Vgl. zu einer ähnlichen Darstellungsform Coad, Yourdan /Analysis/ 37 ff.
Klassifizierende und aggregierende Beziehungen werden grundsätzlich von oben nach unten gelesen. D. h., die Klassen werden in einer Zeichnung oberhalb der Instanzen, die Aggregate oberhalb der Komponenten angeordnet. Deshalb ist es nicht nötig, sie durch Pfeile zu kennzeichnen.
Vgl. Rumbaugh u. a. /Design/ 84 ff.
Vgl. Rumbaugh u. a. /Design/ 123 ff.
Vgl. Schmitz, Lenz /Glossar ’86/ 498. Rich spricht in diesem Zusammenhang von ‘Wissensdarstellung’. Vgl. Rich /KI/ 67 ff.
Vgl. Schmitz /Expertensysteme/ 615 und Schmitz, Lenz /Glossar ’86/ 494. Inferenzverfahren werden deshalb auch als Problemlösungsmechanismen bezeichnet.
Vgl. Schmitz, Lenz /Glossar ’89/ 9. Vgl. zu einer ausführlichen Diskussion des Begriffs ‘Wissen’ Lenz /Expertensysteme/ 33 ff.
Vgl. z. B. Schmitz /Expertensysteme/ 616 ff.
Vgl. Lenz /Expertensysteme/ 50; Rich /KI/ 443 und Schmitz /Expertensysteme/ 617. Z. T. führt der enge Zusammenhang der beiden Wissensarten sogar dazu, daß der Begriff ‘Wissensrepräsentation’ sowohl für die Abbildung von Faktenwissen als auch von Inferenzverfahren verwendet wird. Vgl. Lenz /Expertensysteme/ 4
Vgl. Rich /KI/ 261. Puppe nennt als wesentliche Kriterien für die Auswahl einer Wissensrepräsentationsform die Adäquatheit und die Effizienz. Diese beiden Kriterien beschreiben, wie natürlich der jeweilige Problembereich mit der Repräsentationsform beschrieben werden kann und wie effizient Problemlösungen erzielt werden können. Vgl. Puppe /Einführung/ 18
Vgl. Rich /KI/ 217 f.
Vgl. Lenz /Wissensrepräsentation/ 2; Raulefs /Methoden/ 173 ff.; Rich /KI/ 218 und 258 f.; Schmitz /Expertensysteme/ 616 und Schmitz, Lenz /Abgrenzung/ 502 f. Der Begriff ‘prozedural’ ist mit zwei verschiedenen Begriffsinhalten belegt: Zum einen beschreibt er den imperativen Programmierstil im Rahmen der konventionellen Datenverarbeitung, der einen Programmablauf in Form einer festgelegten Sequenz von Anweisungen darstellt. Dabei wird der Begriff ‘prozedural’ als Abgrenzung zum deskriptiven Programmierstil in wissensbasierten Systemen verwendet. In wissensbasierten Systemen wird ein Problem häufig lediglich beschrieben und die Lösung durch Schlußfolgerungen erschlossen. Zum anderen lassen sich aber auch innerhalb des deskriptiven Programmierstils in wissensbasierten Systemen zwei verschiedene Wissensrepräsentationsarten unterscheiden: die ‘deklarativen’ und die ‘prozeduralen’. Vgl. Karras, Kredel, Pape /Entwicklungsumgebungen/ 33. Im folgenden wird die zweite Bedeutung dieser beiden Begriffe erörtert
Raulefs /Methoden/ 173
Vgl. Schmitz /Expertensysteme/ 616. Vgl. zu einführenden Darstellungen in die Prädika-enlogik Brewka /Techniken/ 17 ff.; Harmon, King /Expert Systems/ 46 ff.; Lenz /Wissensrepräsentation/ 2 f.; Puppe /Einführung/ 16 ff. und Rich /KI/ 147 ff. Vgl. zu Einführungen in semantische Netze Karras, Kredel, Pape /Entwicklungsumgebungen/ 34; Harmon, King /Expert Systems/ 35 ff.; Raulefs /Methoden/ 174 f. und Rich /KI/ 232 ff.
Raulefs /Methoden/ 173
Vgl. Karras, Kredel, Pape /Entwicklungsumgebungen/ 32 f.
Vgl. Schmitz /Expertensysteme/ 616. Viele Autoren sprechen von ‘Produktionssystemen’. Um eine Verwechselung mit Systemen im Bereich der betrieblichen Produktion zu vermeiden, soll hier jedoch von ‘Produktionensystemen’ gesprochen werden. Vgl. hierzu auch Schmitz, Lenz /Glossar ’86/ 496. Die Begriffe ‘Regeln’ und ‘Produktionen’ werden im folgenden synonym verwendet Vgl. zu einer kurzen Darstellung dieser Wissensrepräsentationsform Kap. 5.3.3. Ein anderes Beispiel für die Anwendung prozeduraler Verfahren zur Wissensrepräsentation ist laut Raulefs die Programmiersprache PROLOG, die er als “prozedurale Interpretation der Prädikatenlogik” bezeichnet. Raulefs /Methoden/ 177; Hervorhebungen im Original wurden weggelassen.
Raulefs spricht von ‘passiven Daten’ und ‘anwendbaren Prozeduren’. Vgl. Raulefs /Methoden/ 173
So betonen Schmitz und Lenz z. B., daß in prozeduralen Verfahren die Trennung in Fakten und Verarbeitungstechniken aufgehoben werde; sie seien als ‘prozedurale Einheiten’ zu betrachten. Vgl. Schmitz, Lenz /Abgrenzung/ 502 f. Rich betont, daß deklarative Verfahren zwar tatsächlich den größten Teil des Wissens in Form von Tatsachen darstellen. Die deklarativen Wissenrepräsentationsformen enthalten jedoch in aller Regel auch eine kleine Menge allgemeiner Verfahren für die Bearbeitung dieses Wissens. Vgl. Rich /KI/ 218
Vgl. Rich /KI/ 218 und 258 f.
Vgl. zu Darstellungen frameorientierter Wissensrepräsentation Brewka /Techniken/ 19 ff.; Harmon, King /Expert Systems/ 44 ff.; Minsky /Framework/ 211 ff.; Puppe /Einführung/ 29 ff.; Raulefs /Methoden/ 179 f. und Rich /KI/ 247 ff.
Vgl. zu Darstellungen objektorientierter Wissensrepräsentation Bolkart /Programmiersprachen/ 228 ff; Coad, Yourdan /Analysis/ 30 ff.; Ferstl, Sinz /Objektmodellierung/ 566 ff.; Harmon, Maus, Morrissey /Expertensysteme/ 52 ff.; Korson, McGregor /Paradigm/ 41 ff. und Meyer/Softwareentwicklung/ 2 ff.
Bei objektorientierten Systemen wird die prozedurale Beifügung häufig dadurch erreicht, daß die objektorientierte Darstellung mit Konzepten aus Produktionensystemen kombiniert wird. Vgl. Bechtolsheim, Schweichhart, Winand /Expertensystemwerkzeuge/ 39; Lenz /Expertensysteme/ 64; Marchand /Wissensdarstellung/ 145 ff. und Stoyan /Systementwicklung/ 5. Bei framebasierten Darstellungen können Prozeduren in die Slots eines Frames integriert werden. Vgl. Fikes, Kehler /Role/ 904 ff. und Schmitz /Expertensysteme/ 616
Vgl. zu einem Überblick über die verschiedenen Wissensrepräsentationsformen Brewka /Techniken/ 17 ff.; Harmon, King /Expertensysteme/ 40 ff.; Lenz /Expertensysteme/ 44 ff.; Lenz /Wissensrepräsentation/ 2 ff.; Raulefs /Methoden/ 173 ff.; Rich /KI/ 147 ff.; Schmitz, Lenz /Abgrenzung/ 502 f. und Stoyan /Programmiermethoden 2/ 1 ff. Prinzipiell können die meisten Programmsysteme mit verschiedenen Wissensrepräsentationsformen realisiert werden. Vgl. Raulefs /Methoden/ 173. So ist es z. B. möglich, mit regelbasierten Systemen alle Programme zu realisieren, die auch mit objektorientierten Systemen verwirklicht werden können. Allerdings ist der Realisierungsaufwand je nach Repräsentationsform sehr unterschiedlich. Vgl. Karras, Kredel, Pape /Entwicklungsumgebungen/ 59
Kreutzer /Grundkonzepte/ 213. Vgl. hierzu auch Korson, McGregor /Paradigm/ 46 und Stoyan /Systementwicklung/ 8
Vgl. Marchand /Wissensdarstellung/145
Vgl. Sager /Begriffe/ 39
Grundsätzlich wäre es auch möglich, den framebasierten Ansatz auszuwählen. Der Zusammenhang zwischen der framebasierten und der objektorientierten Wissensrepräsentation wird unterschiedlich interpretiert. Z. T. werden die Begriffe ‘Frame’ und ‘Objekt’ synonym verwendet. Vgl. z. B. Schmitz /Expertensysteme/ 616. Andere Autoren bezeichnen Frames als ‘KI-Repräsentation von Objekten’ (vgl. Bechtolsheim, Schweichhart, Winand /Expertensystemwerkzeuge/ 39) oder als Beispiel für objektorientierte Wissensrepräsentation in wissensbasierten Systemen (vgl. Sinz /ooA/ 455). In jedem Fall kann das Konzept der Frames als verwandtes Gebiet der Objektorientierung bezeichnet werden. Vgl. Rathke /Wissensrepräsentation/ 45 ff. Aus diesem Grund sollen Frames nicht zusätzlich zur objektorientierten Wissensrepräsentation erörtert werden. Die in Kap. 8 erläuterten Gestaltungsempfehlungen für die objektorientierte Wissensrepräsentation lassen sich leicht auf die framebasierte Darstellung übertragen.
Vgl. hierzu besonders Kap. 7.3.2
Werkzeuge, die eine Abbildung objektorientierter Strukturen ermöglichen, greifen häufig zur Realisierung der in den Objekten integrierten Methoden auf Regeln zurück. Vgl. Schmitz /Expertensysteme/ 617. Auch deshalb bietet sich diese Auswahl an.
Vgl. hierzu Kap. 5.2.1
Stoyan /Systementwicklung/ 8
Vgl. Ferstl, Sinz /Objektmodellierung/ 568 und Stoyan, Görz /Programmierung/ 14
Vgl. Coad, Yourdan /Analysis/ 53; Kreutzer /Grundkonzepte/ 215 f. und Stoyan, Görz /Programmierung/ 14
Vgl. zum Begriff ‘Methoden’ Kap. 5.3.2.2
Vgl. zum Begriff ‘Vererbung’ Kap. 5.3.2.4
Rathke/Wissensrepräsentation/ 52
Rathke /Wissensrepräsentation/ 52
Vgl. zu einer ausführlicheren Darstellung des Zusammenspiels von Nachrichten und Methoden Coad, Yourdan /Analysis/ 149; Ferstl, Sinz /Objektmodellierung/ 570 f. und Stoyan, Görz /Programmierung/ 15 ff.
Rathke /Wissensrepräsentation/ 52. Vgl. zu ähnlichen Definitionen Harmon, Maus, Morrissey /Expertensysteme/ 53 und Neunast, Helden /Programmentwicklung/ 255
Rathke /Wissensrepräsentation/ 53
Vgl. Stoyan, Görz /Programmierung/ 11
Rathke /Wissensrepräsentation/ 53
Vgl. Coad, Yourdan /Analysis/ 143 und Rathke /Wissensrepräsentation/ 50. Coad und Yourdan verwenden statt des gebräuchlichen Begriffs ‘Methoden’ den Ausdruck ‘services’ (‘Dienste’).
Vgl. Bolkart /Programmiersprachen/ 242 und Ferstl, Sinz /Objektmodellierung/ 580
Vgl. hierzu auch Kap. 5.3.2.3
Vgl. zu einer ähnlichen Verwendung der Begriffe Stoyan, Görz /Programmierung/ 17 ff.
Der Begriff ‘Kapselung’ ist eine Übersetzung des englischen Begriffs ‘encapsulation’. Vgl. Coad, Yourdan /Analysis/ 14 f. Synonym werden im deutschen auch die Begriffe ‘Einkapselung’ oder ‘Verkapselung’ verwendet. Vgl. Kreutzer /Grundkonzepte/ 212 und Stoyan /Systementwicklung/ 9
Vgl. Coad, Yourdan /Analysis/ 14 f.
Vgl. Coad, Yourdan /Analysis/ 14 f.
Vgl. Coad, Yourdan /Analysis/ 53
Vgl. Coad, Yourdan /Analysis/ 15
Budde u. a. /Entwurf/ 17
Vgl. Budde u. a. /Entwurf/ 16; Ferstl, Sinz /Objektmodellierung/ 568 und Neunast, Helden /Programmentwicklung/ 257
Vgl. Budde u. a. /Entwurf/ 21 und Neunast, Helden /Programmentwicklung/ 257
Vgl. zu einer Einführung in diese Form der Wissensrepräsentation z. B. Brewka /Techniken/ 19 ff.; Harmon, King /Expert Systems/ 38 ff.; Hayes-Roth /Systems/ 922; Karras, Kredel, Pape /Entwicklungsumgebungen/ 34 ff.; Puppe /Einführung/ 21 ff.; Raulefs /Methoden/ 175 ff. und Rich /KI/ 33 ff.
Puppe unterscheidet zwei Arten von Konklusionen: Implikationen bzw. Deduktionen, mit denen der Wahrheitsgehalt einer Aussage festgestellt wird, und Handlungen, mit denen ein Zustand verändert wird. Vgl. Puppe /Einführung/ 21 ff.
Vgl. Lenz /Wissensrepräsentation/ 3 und Rich /KI/ 34
Vgl. Brewka/Techniken/ 19
Vgl. Schmitz /Expertensysteme/ 616
Vgl. Puppe /Einführung/21
Vgl. Karras, Kredel, Pape /Entwicklungsumgebungen/ 39
Vgl. Puppe/Einführung/ 3 und 28
Vgl. Rathke /Wissensrepräsentation/ 56
Rights and permissions
Copyright information
© 1993 Springer Fachmedien Wiesbaden
About this chapter
Cite this chapter
Stelzer, D. (1993). Methodische Grundlagen für die Entwicklung eines wissensbasierten, objektorientierten Beratungssystems. In: Sicherheitsstrategien in der Informationsverarbeitung. Deutscher Universitätsverlag, Wiesbaden. https://doi.org/10.1007/978-3-663-14556-1_5
Download citation
DOI: https://doi.org/10.1007/978-3-663-14556-1_5
Publisher Name: Deutscher Universitätsverlag, Wiesbaden
Print ISBN: 978-3-8244-2038-4
Online ISBN: 978-3-663-14556-1
eBook Packages: Springer Book Archive