Hochschule Wismar
Fachbereich Wirtschaft
Master Thesis
Analyse von Anomalien in der graphischen Modellierung
von diagnostischem Wissen
Master Thesis zur Erlangung des Grades eines Master of Sience
der Hochschule Wismar
eingereicht von: Gritje Meinke, geb. Düsing
geboren am 04. April 1983 in Wismar
Studiengang Master Wirtschaftsinformatik, MWI 2009 Betreuer: Prof. Dr.-Ing. Uwe Lämmel
weitere Gutachter: Prof. Dr. rer. nat. Jürgen Cleve
Wismar, den 22. Juni 2011
Vorwort
Diese Master Thesis ist im Rahmen meines Fernstudiums der Wirtschaftsinformatik an der Hochschule Wismar in Zusammenarbeit mit der Julius-Maximilians-Universität Würzburg und der Firma Dräger Medical GmbH in Lübeck entstanden.
An dieser Stelle möchte ich Dank sagen für die konspirative Zusammenarbeit und großartige Unterstützung der Herren Reinhard Hatko, Dr. Joachim Baumeister und Volker Belli der Universität Würzburg.
Weiterer Dank gilt meinem Vorgesetzten bei der Dräger Medical GmbH, Herrn Stefan Mersmann, der mir bei der Themenfindung und -bearbeitung mit Rat und Tat zur Seite stand.
Für die fachliche Betreuung bei der Erstellung dieser Arbeit bedanke ich mich bei den Professoren Dr.-Ing. Uwe Lämmel und Dr. rer. nat. Jürgen Cleve.
Zu guter Letzt möchte ich mich bei meiner Familie bedanken, die sehr viel Geduld aufbringen musste, um mich in der Zeit des Fernstudiums und der Abschlussarbeit zu entbehren und die mir immer eine große Stütze war.
Inhalt
I. ABBILDUNGSVERZEICHNIS ... VI
II. TABELLENVERZEICHNIS ... IX
III. ABKÜRZUNGSVERZEICHNIS ...X
1 EINLEITUNG UND PROBLEMSTELLUNG...1
1.1 PROBLEMSTELLUNG UND MOTIVATION...1
1.2 RELATED WORK...2
1.3 ÜBERSICHT ÜBER DIE NACHFOLGENDEN KAPITEL...3
2 GRUNDLAGEN ...4
2.1 MODELLIERUNG VON WISSEN...4
2.2 KNOWWE UND DIAFLUX...8
2.2.1 Das semantische Wiki KnowWE ...8
2.2.2 Die graphische Notation DiaFlux...8
2.2.3 Anwendungsbeispiel...13
2.3 PROZESS- UND WORKFLOW-MODELLIERUNG...20
2.3.1 Workflow-Konzepte und -Perspektiven...21
2.3.2 Datenflussperspektive ...22
2.3.3 Kontrollfluss-Muster in der Kontrollflussperspektive (Control Flow Pattern) ...23
2.3.4 Techniken zur Modellierung von Prozessen ...27
2.4 VERIFIKATION IM KONTEXT VON WISSENSBASEN UND DEREN MODELLIERUNG...31
3 ANOMALIEN IN DER GRAPHISCHEN MODELLIERUNG ...34
3.1 FEHLENDE DATEN...35
3.1.1 Uninitialisierter Wert...36
3.1.2 Verzögerte Initialisierung ...36
3.1.3 Unsichere Synchronisation ...37
3.2 REDUNDANZ...37
3.2.1 Starke Redundanz...38
3.2.2 Schwache Redundanz...38
3.3 INKONSISTENZ...39
3.3.1 Stark verlorene Daten ...39
3.3.2 Schwach verlorene Daten ...39
3.3.3 Multiple Initialisierung ...40
3.4 KONTROLLFLUSSANOMALIEN...40
3.4.1 Knoten ohne eingehende oder ausgehende Kanten ...41
3.4.2 Aktivitätsknoten mit mehr als einer Eingangs- oder Ausgangskante...42
3.4.3 Kontrollknoten mit nur einer Eingangs- oder Ausgangskante, Unvollständigkeit der Nachbedingungen ...42
3.4.4 Sich überschneidende Nachbedingungen ...42
3.4.5 Fehlender Start- bzw. Endknoten oder auch mehrere Start- bzw. Endknoten...43
3.4.6 Fehlgerichtete Kanten bei Start- oder Endknoten ...43
3.4.7 Verbindungsloser Knoten...43
3.4.8 Mehrere Kanten zwischen zwei Knoten ...44
3.4.9 Deadlock ...44
3.4.10 Fehlende Synchronisation...46
3.4.11 Schleife...46
3.4.12 Endlosschleife ...47
3.4.13 Unnötiger Nicht-Determinismus...47
3.5 AUFFÄLLIGKEITEN...48
3.5.1 Unerreichbare Elemente...48
3.5.2 Toter Pfad ...48
3.5.3 Fehlende Modellierungsschritte ...49
4 ABBILDUNG VON ANOMALIEN DER GRAPHISCHEN MODELLIERUNG AUF DIE GRAPHISCHE NOTATION DIAFLUX ...50
4.1 FEHLENDE DATEN...50
4.1.1 Uninitialisierter Wert...50
4.1.2 Verzögerte Initialisierung ...51
4.1.3 Unsichere Synchronisation ...51
4.2 REDUNDANZ...52
4.2.1 Starke Redundanz...52
4.2.2 Schwache Redundanz...53
4.3 INKONSISTENZ...53
4.3.1 Stark verlorene Daten ...53
4.3.2 Schwach verlorene Daten ...54
4.3.3 Multiple Initialisierung ...54
4.4 PROZESSANOMALIEN...56
4.4.1 Splits in DiaFlux ...56
4.4.2 Joins in DiaFlux...57
4.4.3 Knoten ohne eingehende oder ausgehende Kanten ...59
4.4.4 Aktivitätsknoten mit mehr als einer Eingangs- oder Ausgangskante...59
4.4.5 Kontrollknoten mit nur einer Eingangs- oder Ausgangskante, Unvollständigkeit der Nachbedingungen ...59
4.4.6 Sich überschneidende Nachbedingungen ...59
4.4.7 Fehlender Start- bzw. Endknoten oder auch mehrere Start- bzw. Endknoten...60
4.4.8 Fehlgerichtete Kanten bei Start- oder Endknoten ...60
4.4.9 Verbindungsloser Knoten...60
4.4.10 Mehrere Kanten zwischen zwei Knoten ...60
4.4.11 Deadlock ...61
4.4.12 Fehlende Synchronisation...62
4.4.13 Schleife / Endlosschleife ...62
4.4.14 Unnötiger Nicht-Determinismus...63
4.5 AUFFÄLLIGKEITEN...64
4.5.1 Toter Pfad ...64
4.5.2 Fehlende Modellierungsschritte ...64
4.6 DIAFLUX-SPEZIFISCHE ANOMALIEN...64
4.6.1 Redundantes Flussdiagramm...65
4.6.2 Redundanter Startknoten ...65
4.6.3 Redundante Abfrage...66
4.6.4 Inkonsistente Abfrageart...66
4.6.5 Inkonsistente Herleitung ...66
4.6.6 Schleife ohne Snapshot-Knoten...66
4.6.7 Kein automatisch startendes Flussdiagramm...67
4.6.8 Automatisch startendes Flussdiagramm mit mehr als einem Startknoten ...67
4.6.9 Rückkopplung...68
4.6.10 Unmöglicher Pfad...68
4.6.11 Unbenutzte Elemente der Wissensbasis ...69
4.6.12 Konflikt zur Wissensbasis ...70
5 IMPLEMENTIERUNG VON ANOMALIE-ERKENNUNGSALGORITHMEN FÜR DIAFLUX ...72
5.1 INTEGRATION DER ANOMALIE-ERKENNUNG IN KNOWWE ...72
5.2 REALISIERUNG DER ANOMALIE-ERKENNUNG...73
5.3 ERKENNUNG DER ANOMALIE „KNOTEN OHNE EINGEHENDE ODER AUSGEHENDE KANTEN“ ....76
6 BEWERTUNG, ZUSAMMENFASSUNG UND AUSBLICK...78
7 LITERATUR ...84
8 EHRENWÖRTLICHE ERKLÄRUNG ...XII
9 ANLAGENVERZEICHNIS ... XIII
10 ANLAGE A ... XIV
10.1 DIAFLUX FLUSSDIAGRAMM...XIV
10.2 ALGORITHMUS ZUR ERKENNUNG DER ANOMALIE „KNOTEN OHNE EINGEHENDE ODER
AUSGEHENDE KANTEN“ ... XV
I. Abbildungsverzeichnis
Abbildung 1: Exemplarisches Wissensnetz für Fortbewegungsmittel...6
Abbildung 2: Wiki-Artikel über das Fortbewegungsmittel "Auto" ...7
Abbildung 3: Syntax mit semantischen Annotationen ...7
Abbildung 4: KnowWE - Fragebaum MwSt...14
Abbildung 5: KnowWE - Herleitungen des MwSt-Satz ...14
Abbildung 6: KnowWE - Gewichtung von Herleitungen (Diagnosen) ...15
Abbildung 7: KnowWE – Regeln zur MwSt-Berechnung ...16
Abbildung 8: KnowWE – KnowledgeBase...16
Abbildung 9: KnowWE - QuickInterview ...17
Abbildung 10: KnowWE - angewendete Regeln zur MwSt-Berechnung...17
Abbildung 11: KnowWE - etablierte Herleitung / Diagnose für den MwSt-Satz...17
Abbildung 12: DiaFlux - Flussdiagramm zur Berechnung der MwSt ...19
Abbildung 13: Sequenz ...24
Abbildung 14: AND Split / paralleler Split...24
Abbildung 15: AND Join...25
Abbildung 16: XOR Split / exklusiver OR Split ...25
Abbildung 17: XOR Join / exklusiver OR Join...26
Abbildung 18: OR Split...26
Abbildung 19: OR Join...27
Abbildung 20: Beispiel für ein Petri-Netz...28
Abbildung 21: Beispiel für ein Workflow Netz ...28
Abbildung 22: Elemente der EPK-Modellierung ...29
Abbildung 23: Beispiel für BPMN...30
Abbildung 24: Überblick der Anomalieklassen ...34
Abbildung 25: genutzte YAWL Elemente ...35
Abbildung 26: Anomalie - uninitialisierter Wert ...36
Abbildung 27: Anomalie - verzögerte Initialisierung ...36
Abbildung 28: Anomalie - unsichere Synchronisation ...37
Abbildung 29: Anomalie - starke Redundanz ...38
Abbildung 30: Anomalie - schwache Redundanz ...38
Abbildung 31: Anomalie - stark verlorene Daten ...39
Abbildung 32: Anomalie - multiple Initialisierung ...40
Abbildung 33: Anomalie - Knoten ohne eingehende oder ausgehende Kanten...41
Abbildung 34: Anomalie - Aktivitätsknoten mit mehr als einer Eingangs- oder Ausgangskante ...42
Abbildung 35: Anomalie - Kontrollknoten mit nur einer Eingangs- oder Ausgangskante...42
Abbildung 36: Anomalie - fehlender Endknoten ...43
Abbildung 37: Anomalie - fehlgerichtete Kanten bei Start- oder Endknoten ...43
Abbildung 38: Anomalie – verbindungsloser Knoten...43
Abbildung 39: Anomalie - mehrere Kanten zwischen zwei Knoten...44
Abbildung 40: Anomalie - deterministischer Deadlock...44
Abbildung 41: nicht-deterministischer Deadlock...45
Abbildung 42: Anomalie - deterministische fehlende Synchronisation...46
Abbildung 43: Anomalie – Schleife ...46
Abbildung 44: Anomalie - deterministische Endlosschleife ...47
Abbildung 45: Anomalie - unnötiger Nicht-Determinismus...47
Abbildung 46: Anomalie - toter Pfad ...48
Abbildung 47: DiaFlux Flussdiagramm – uninitialisierter Wert (1) ...50
Abbildung 48: DiaFlux Flussdiagramm – uninitialisierter Wert (2) ...51
Abbildung 49: DiaFlux Flussdiagramm – verzögerte Initialisierung...51
Abbildung 50: DiaFlux Flussdiagramm – unsichere Synchronisation...52
Abbildung 51: DiaFlux Flussdiagramm – starke Redundanz...52
Abbildung 52: DiaFlux Flussdiagramm – schwache Redundanz...53
Abbildung 53: DiaFlux Flussdiagramm – stark verlorene Daten...54
Abbildung 54: DiaFlux Flussdiagramm – multiple Initialisierung ...55
Abbildung 55: AND-Split in DiaFlux ...56
Abbildung 56: Joins in DiaFlux ...57
Abbildung 57: DiaFlux Flussdiagramm – Darstellung verschiedener Prozessanomalien ...58
Abbildung 58: DiaFlux Flussdiagramm – deterministischer Deadlock ...61
Abbildung 59: DiaFlux Flussdiagramm - nicht-deterministische fehlende Synchronisation ...62
Abbildung 60: DiaFlux Flussdiagramm - Schleife / Endlosschleife ...62
Abbildung 61: DiaFlux Flussdiagramm - toter Pfad ...64
Abbildung 62: DiaFlux Flussdiagramm - Redundanter Startknoten...65
Abbildung 63: DiaFlux Flussdiagramm - Schleife ohne Snapshot-Knoten ...67
Abbildung 64: DiaFlux Editor - automatischer Start eines Diagramms...67
Abbildung 65: DiaFlux Flussdiagramm - unmöglicher Pfad ...68
Abbildung 66: DiaFlux Flussdiagramm - BMI-Berechung...69
Abbildung 67: Teil einer Wissensbasis zur BMI-Berechnung...69
Abbildung 68: DiaFlux Flussdiagramm (unvollständig) - Konflikt zur Wissensbasis ...70
Abbildung 69: Fragen der Wissensbasis ...71
Abbildung 70: CI Dashboard...72
Abbildung 71: fehlerfreier Anomalie-Test im CIDashboard ...74 Abbildung 72: DiaFlux Flussdiagramm ...XIV
II. Tabellenverzeichnis
Tabelle 1: DiaFlux Knotentypen ...12
Tabelle 2: Aktivierungszustände der DiaFlux-Knoten und -Kanten...12
Tabelle 3: Beispiel für eine Datenfluss-Matrix ...22
Tabelle 4: Zusammenfassung identifizierter Anomalien ...83
III. Abkürzungsverzeichnis
Abkürzung Bedeutung
AAAI Association for the Advancement of Artificial Intelligence ADC Australasian Database Conference
AIME Artificial Intelligence in Medicine
AMCIS Americas Conference on Informaction Systems ARIS Architektur integrierter Informationssysteme BGA Blutgasanalyse
BMI Body Mass Index
BPMN Business Process Modelling Notation
CAiSE Conference on Advanced Information Systems Engineering CI Continuous Integration
CI4KE Continuous Integration for Knowledge Engineering ECAI European Conference on Artificial Intelligence EKAW European Knowledge Acquisition Workshop EPK Ereignisgesteuerte Prozessketten
ibLV innerbetriebliche Leistungsverrechnung KnowWE Knowledge Wiki Environment
KR4HC Knowledge Representation for Health Care LWA Lernen, Wissen, Adaptivität
MwSt Mehrwertsteuer
OKM Open Knowledge Models OWL Web Ontology Language
PAIS Prestigious Applications of Intelligent Systems SaO2 Arterielle Sauerstoffsättigung
sO2 Sauerstoffsättigung
SpO2 Partielle Sauerstoffsättigung
Abkürzung Bedeutung TMS Truth Maintanence System
UML Unified Modelling Language V&V Verifikation & Validierung
WITS Workshop on Information Technologies and Systems XML eXtensible Markup Language
YAWL Yet Another Workflow Language
1 Einleitung und Problemstellung
1.1 Problemstellung und Motivation
Der global agierende, börsennotierte Konzern Dräger ist ein international führendes Unternehmen im Bereich der Medizin- und Sicherheitstechnik, das bereits in fünfter Generation durch Familienhand geführt wird. Dräger beschäftigt weltweit ca. 11.000 Mitarbeiter in über 190 Ländern.1
Der Unternehmensbereich Medizintechnik entwickelt innovative Geräte und Lösungen entlang der gesamten Prozesskette der Akutmedizin (Notfall-, Intensiv-, Perioperativ- und Perinatalmedizin). Im Bereich Beatmung und Narkose sowie auch in der Überwachung der Vitaldaten von Patienten ermöglichen die Lösungen von Dräger die höchste Therapiequalität.2
In einigen Medizinprodukten werden wissensbasierte Systeme zur intelligenten Steuerung und adaptiven Überwachung der Therapie genutzt - z.B. zur automatischen Entwöhnung eines Patienten von der Beatmung.3 Das Wissen, das diesen Systemen zu Grunde liegt, wurde bisher mit Hilfe einer kommerziellen Software akquiriert und formalisiert. Seit Ende 2010 wird das semantische Wiki KnowWE (Knowledge Wiki Environment)4 und dessen graphische Notation DiaFlux zu eben diesem Zwecke eingesetzt. Als kollaborative Websoftware ermöglicht ein semantisches Wiki die einfache Zusammenarbeit von Wissensingenieuren und Domänen-Experten und vereinheitlicht formelles und informelles Wissen. Trotz der intuitiven Bedienbarkeit eines Wikis ist die Syntax eines semantischen Wikis gerade für den Domänen-Experten nicht immer einfach umzusetzen. Daher bietet KnowWE die Modellierungssprache DiaFlux, die den komplexen Prozess der Wissensmodellierung stark vereinfacht. DiaFlux dient der Abbildung diagnostischer Wissensflüsse und ist somit in der Lage, klinische Richtlinien in Flussdiagrammen mit wenigen, intuitiven Elementen darzustellen. Dadurch wird das modellierte Wissen leichter verständlich und wartbar.
Während KnowWE kontinuierlich Tests zur Sicherung der Qualität der Wissensbasen unterzogen wird, ist die Qualitätssicherung von DiaFlux erst wenig berührt. Für den industriellen Einsatz ist diese jedoch ein essentieller und unabdingbarer Bestandteil des Knowledge Engineering Prozesses. Nur so kann die höchste Therapiequalität in den automatisierten Systemen gewährleistet werden.
1 Vgl. http://www.draeger.com/DE/de/, 06.02.2011, 17:05 Uhr
2 Vgl. http://www.draeger.com/DE/de/investoren/draeger_auf_einen_blick/medizintechnik/index.jsp, 06.02.2011, 17:05 Uhr 3 Vgl. [MD04], S. 745 ff.
4 Vgl. http://www.is.informatik.uni-wuerzburg.de/forschung/anwendungen/knowwe/, 06.02.2011, 17:25 Uhr
Allerdings können auch in einer graphischen Modellierung Fehler auftreten. Der Fokus dieser Master Thesis liegt in der Identifikation und Analyse von Anomalien, die Symptome möglicher Modellierungsfehler beschreiben. Anomalien in diagnostischen Flüssen sollen durch Recherche in klassischer und aktueller Literatur sowie anhand praktischer Experimente mit DiaFlux erkannt und aufgezeigt werden. Die gefundenen Anomalien werden strukturiert und gegebenenfalls auf DiaFlux übertragen. Die Recherchen bewegen sich im Bereich der Prozess- und Workflow-Modellierung, da mittels DiaFlux Problemdiagnostiken als Flussdiagramme modelliert werden. Die Flussdiagramme bilden diagnostisches Wissen zu Problemlösungsprozessen ab. Dies kann von einfachen Alltagsproblemen bis hin zu medizinischen Therapieszenarien reichen.
Ein weiterer Schwerpunkt der Arbeit ist die prototypische Implementierung eines Detektionsalgorithmus’ für eine DiaFlux-Anomalie im Rahmen der kontinuierlichen Integrationsumgebung für Tests von KnowWE. Darüber hinaus wird ein Visualisierungskonzept für in einer Modellierung detektierte Anomalien diskutiert.
Die aus der Arbeit resultierenden Qualitätsmethoden werden zukünftig die kontinuierliche Qualitätskontrolle der Wissensbasen in KnowWE ergänzen und den industriellen Einsatz der Modellierung mit DiaFlux unterstützen.
1.2 Related Work
Die Modellierung von Wissen in Flussdiagrammen, deren Ausführung zu einer Diagnose führt, kann in den Bereich der Prozessmodellierung und Modellierung von Workflows eingeordnet werden. Im Rahmen der Verifikation von Petri- oder Workflow-Netzen wird in der Literatur auf die Identifikation und Detektion von Anomalien eingegangen. Van der Aalst unterteilt in [Aal00] die Modellierung von Workflows unter anderem in eine Kontrollfluss- und eine Datenfluss-Perspektive. Diese Perspektiven liegen der Master Thesis zu Grunde, da ein DiaFlux-Flussdiagramm in prozeduraler (Fluss) und deklarativer (Daten) Form Wissen darstellt und verarbeitet. Van der Aalst et al. analysieren in [TAS09] Muster in Datenflüssen, die zu Fehlern führen können. Auch Sadiq et al. beschreiben in [SZN05] und [SOSF04]
Validierungsprobleme und Anomalien wie redundante oder inkonsistente Daten innerhalb des Datenflusses von Workflows. Bi und Zhao stellen in [BZ03] eine formale Klassifikation von Prozessanomalien auf, die beispielsweise die falsche Verknüpfung von Knoten in einem Netz und andere Aspekte bezüglich Prozessgraphen beschreiben.
Die Evaluierung gerade wissensbasierter Systeme wird besonders durch Preece et al. in [PS94] und [Pre98] untersucht. Dabei wird auf die Validierung und Verifikation dieser Systeme sowie Probleme wie Redundanzen oder Inkonsistenzen in Wissensbasen eingegangen.
Diese Arbeit aggregiert die angesprochene und weitere Literatur, um die Fehlerquellen der Modellierung und ihrer unterschiedlichen Perspektiven auf die Modellierungsnotation DiaFlux zu übertragen. Dabei erhebt die Arbeit nicht den Anspruch, vollständig alle möglichen Anomalien gefunden zu haben und alle Perspektiven zu betrachten. Sie bildet die
Grundlage für weitere Analysen oder eine Implementierung der vollständigen Erkennung aller Modellierungsanomalien in einem DiaFlux-Flussdiagramm.
1.3 Übersicht über die nachfolgenden Kapitel
Im nächsten Kapitel werden die Grundlagen für das Verständnis der weiteren Inhalte der Master Thesis dargelegt. Dabei wird zunächst auf den Begriff „Wissen“ und die unterschiedlichen Modellierungsmöglichkeiten von Wissen wie Regeln, Ontologien oder semantische Wikis eingegangen. Letztere werden eingehender betrachtet, da es sich bei KnowWE um ein solches Wiki handelt. Anschließend werden KnowWE und die Notation DiaFlux zur graphischen Wissensmodellierung erläutert und die Arbeitsweise von KnowWE und DiaFlux im Zusammenspiel anhand eines Beispiels dargestellt. Im weiteren Verlauf des zweiten Kapitels werden die Perspektiven eines Workflows und verschiedene Arten der Prozess- und Workflow-Modellierung beschrieben, bevor abschließend auf die Verifikation im Kontext von Wissensbasen und deren Modellierung eingegangen wird.
Das dritte Kapitel klassifiziert die nach der Literaturrecherche identifizierten Anomalien der graphischen Modellierung von Prozessen bzw. Workflows. Dabei werden fehlende Daten, Redundanz, Inkonsistenz, Auffälligkeiten und Anomalien im Kontrollfluss – sogenannte Prozessanomalien – unterschieden und ihre Auswirkungen auf eine Wissensmodellierung skizziert.
Mit Hilfe von Experimenten mit KnowWE und DiaFlux und den darin gesammelten Erfahrungen werden im vierten Kapitel die analysierten Anomalien anhand von Beispielmodellierungen auf DiaFlux übertragen. Darüber hinaus werden weitere DiaFlux- spezifische Anomalien betrachtet.
Im fünften Kapitel wird erläutert, wie Detektionsalgorithmen für Anomalien in die Testumgebung von KnowWE integriert werden können. An dieser Stelle wird außerdem auf die Visualisierung der Testergebnisse eingegangen. Ein einfacher Beispielalgorithmus zur Erkennung von Knoten ohne eingehende oder ausgehende Kanten in einem Flussdiagramm rundet das Kapitel ab.
Die Arbeit schließt mit einer zusammenfassenden Übersichtstabelle der Anomalien, Schlussfolgerungen und einem Ausblick.
2 Grundlagen
2.1 Modellierung von Wissen
Bevor die Modellierungsmöglichkeiten von Wissen kurz beschrieben werden, soll zuerst definiert werden, was der Begriff „Wissen“ überhaupt bedeutet. Wissen ist die Fähigkeit, Informationen zu benutzen. Informationen spiegeln dabei die Bedeutung von Daten wider, wobei Daten einfache Werte darstellen. Nimmt man beispielsweise die Zahl 5, hat dieses Datum allein keinerlei Aussage. Die Information, dass die Temperatur heute 5°C beträgt, hat mehr Gehalt. Ohne geeignetes Wissen, kann mit dieser Information allerdings nichts erreicht werden. Wissen ist in diesem Beispiel, wenn aus der Information ein Handeln abgeleitet wird - wie zum Beispiel das Tragen winterlicher Kleidung.1
Um Wissen nun für die Verarbeitung durch einen Computer aufzubereiten, muss es formalisiert resp. modelliert werden. Zur Aufbereitung eines Problems für die rechentechnische Interpretation sind die folgenden Schritte erforderlich2:
• Charakterisierung des Problembereichs in einem bestimmten Detaillierungsgrad
• Formale Darstellung durch eine symbolische Repräsentation des Wissens
• Wissenseingabe in der Computer
• Stellen von Fragen
• Interpretieren der Antworten
In Computerprogrammen, die dediziert für die Verarbeitung von Wissen und Problemlösung durch die Anwendung von eingeflossenem Wissen zuständig sind, sind das Wissen und die Verarbeitung des Wissens voneinander getrennt.3 Solche Computerprogramme werden Expertensysteme oder wissensbasierte Systeme genannt. Sie verfügen über das Wissen von Experten in einer bestimmten Domäne (Problembereich) und nutzen dieses Wissen zur Lösung von Problemen.4 Die explizite Wissensbasis kann somit ohne Änderung der Programmlogik angepasst werden und ist transparent.5
1 Vgl. [LC08], S. 30 f.
2 Vgl. [LC08], S. 30 f.
3 Vgl. [LC08], S. 31
4 Vgl. http://www.enzyklopaedie-der-wirtschaftsinformatik.de/wi-enzyklopaedie/lexikon/technologien-methoden/KI-und- Softcomputing/Expertensystem, 13.02.2011, 10:49 Uhr
5 Vgl. [LC08], S. 32
Die Sprache, die zur Repräsentation von Wissen angewendet werden soll, muss in der Lage sein, das Wissen auch darzustellen. Nicht jede Repräsentationsform ist für jede Art von Wissen geeignet. Vages Wissen kann beispielsweise nicht über reine aussagenlogische Formeln repräsentiert werden.1
Es können unter Anderem folgende Formen der Wissensrepräsentation unterschieden werden:
• Aussagenlogik – WAHR oder FALSCH, 2
• Prädikatenlogik – Erweiterung der Aussagenlogik um Objekte und deren Eigenschaften3
• Regelbasiert – Regeln der Form WENN DANN4
• Fuzzy Logik – Darstellung von vagem Wissen5
• Semantische Netze – Darstellung eines Netzes mit Klassen und Objekten sowie deren Eigenschaften und Relationen6
• Frames – textuelle Beschreibung von Objekten durch ihre Eigenschaften7
• Wissensnetze – graphische Darstellung basierend auf semantischen Netzen und Frames8
• Ontologien – formale Spezifikation eines Gegenstandsbereichs durch Domänenexperten9 Für tiefer gehende Informationen zu dieser Thematik sei auf [LC08] verwiesen.
In Zeiten des Web 2.0 wird Wissen oft kollaborativ erfasst und von den Autoren selbständig verwaltet. Diesem Zwecke dienen Wiki-Systeme. Ein Wiki (wie z.B. Wikipedia) kann eine schier unüberschaubare Menge an Wissen beinhalten. Um Wissen in dieser Form effektiv nutzen zu können, muss eine Volltextsuche möglich und Übersichtsseiten zur Navigation vorhanden sein. Eine andere, weitaus interessantere Möglichkeit, ist der Einsatz von Meta- Informationen in einem Wiki. Meta-Informationen in Form von semantischen Annotationen zur formalen Wissensrepräsentation erweitern ein einfaches Wiki zu einem so genannten
1 Vgl. [LC08], S. 33 2 Vgl. [LC08], S. 35 ff.
3 Vgl. [LC08], S. 54 ff.
4 Vgl. [LC08], S. 69 ff.
5 Vgl. [LC08], S. 89 ff.
6 Vgl. [LC08], S. 83 ff.
7 Vgl. [LC08], S. 85 ff.
8 Vgl. [LC08], S. 87 ff.
9 Vgl. http://www.enzyklopaedie-der-wirtschaftsinformatik.de/wi-enzyklopaedie/lexikon/daten- wissen/Wissensmanagement/Wissensmodellierung/Wissensreprasentation/Semantisches- Netz/Ontologien/index.html/?searchterm=ontologie, 13.02.2011, 10:55 Uhr
semantisches Wiki. Unterschiedliche Formalisierungsgrade von Wissen können so in einen Kontext gebracht werden.1 „Semantische Annotationen korrespondieren in der Regel mit einer Ontologie, in der definiert wird, welche Eigenschaften welchen Objekttypen zugeordnet werden können. Die Ontologie wird ebenfalls durch die einzelnen Wiki-Artikel erstellt und gewartet.“2 Semantische Wikis können nicht nur zur Erleichterung der kollaborativen Arbeit an einem Wissensgebiet sondern auch als Werkzeug für die kollaborative Entwicklung von Ontologien dienen.3
Das nachfolgende Beispiel erläutert die Modellierung von Wissen in dem frei zugänglichen semantischen Wiki Semantic MediaWiki4. Als erster Schritt wird der Gegenstandsbereich visualisiert. Die Abbildung zeigt ein Wissensnetz, das einige Fortbewegungsmittel (motorisiert oder nicht motorisiert) darstellt. Diese Fortbewegungsmittel können auch in andere Kategorien wie „Sportgerät“ oder „Maschine“ unterteilt werden. Jedes Fortbewegungsmittel hat die Eigenschaften „Anzahl Räder“, „Anzahl Spuren“ und
„Untergrundbeschaffenheit“. Exemplarisch ist nur das Fortbewegungsmittel „Auto“ mit seinen Eigenschaften dargestellt.
Abbildung 1: Exemplarisches Wissensnetz für Fortbewegungsmittel Quelle: eigene Darstellung
Aus diesem Wissensnetz lassen sich nun semantische Annotationen für ein Wiki ableiten. Die Artikel des Wikis enthalten normalen Text über die genannten Fortbewegungsmittel. Die Syntax umfasst neben Formatierungsanweisungen aber zusätzliche Meta-Daten für Kategorien (z.B. [[Category:motorisiert]]) oder Eigenschaften (z.B. [[NumberOfWheels::4| ]]) der beschriebenen Objekte. Über diese Meta-Daten können später Abfragen abgeleitet werden
1 Vgl. [HRBP10], S. 2 2 [SBBK07], S. 434 3 Vgl. [SBBK07], S. 435 f.
4 Vgl. http://semantic-mediawiki.org/wiki/Semantic_MediaWiki, 13.02.2011, 14:12 Uhr
– wie beispielsweise die Ermittlung aller Fortbewegungsmittel mit 4 Rädern über das gesamte Wiki. Nachfolgend sind der Wiki-Artikel über das Fortbewegungsmittel „Auto“ sowie die dahinterliegende Syntax mit semantischen Annotationen dargestellt.
Abbildung 2: Wiki-Artikel über das Fortbewegungsmittel "Auto"
Quelle: eigenen Darstellung (http://sandbox.semantic-mediawiki.org/wiki/User:Gritti)1
==Auto==
[[NumberOfWheels::4| ]]
Ein Automobil, kurz Auto (auch Kraftwagen, früher Motorwagen), ist ein [[NumberOfTracks::mehrspurig| mehrspuriges]]
Kraftfahrzeug,
das von einem Motor angetrieben wird und zur Beförderung von Personen und Frachtgütern dient.
Es bewegt sich auf dem [[Ground::Boden]].
[[Category:motorisiert]] [[Category:Maschine]]
[[Category:Sportgerät]]
Abbildung 3: Syntax mit semantischen Annotationen
Quelle: eigene Darstellung (http://sandbox.semantic-mediawiki.org/wiki/User:Gritti)
Das semantische Wiki spielt in dieser Master Thesis eine besondere Rolle, da es sich bei KnowWE um ein solches System handelt. Im nachfolgenden Kapitel werden KnowWE und seine graphische Wissensrepräsentationssprache DiaFlux näher erläutert.
1 Text zitiert nach http://de.wikipedia.org/wiki/Auto, 13.02.2011, 14:03 Uhr
2.2 KnowWE und DiaFlux 2.2.1 Das semantische Wiki KnowWE
Das Knowledge Wiki Environment – kurz KnowWE – ist ein semantisches Wiki zur Modellierung von Entscheidungsunterstützungssystemen. Es ermöglicht das verteilte Knowledge Engineering und ist besonders für kleine Gruppen von Anwendern geeignet.
Formale Konzepte können einfach erzeugt, gewartet und durch informelles Wissen in den Wiki-Artikeln dokumentiert und beschrieben werden.1 Neben den Eigenschaften eines semantischen Wikis (semantische Annotationen, Abfragemöglichkeiten etc.) weist es auch eine Problemlösungskomponente auf. Bei dieser Komponente handelt es sich um d3Web, eine open-source Lösung, die anhand von Entscheidungsbäumen oder -tabellen, kategorischen oder heuristischen Regeln, Überdeckungsmodellen oder fallbasiertem Schließen Problemlösungen herleitet. Diese Java-Software kann in beliebige Anwendungen integriert werden und wird aktuell hauptsächlich im Bereich der medizinischen Diagnose oder der technischen Fehlerdiagnose eingesetzt.2
Zur Modellierung des konzeptionellen Wissens in KnowWE wird die Web Ontology Language (OWL), für das Problemlösungswissen ein proprietäres XML-Format von d3Web verwendet.3
Das modellierte Problemlösungswissen wird direkt auf die im Wiki modellierten Ontologien angewendet. Dazu stehen beispielsweise interaktive Interviews auf den Seiten des Wikis zur Verfügung, die Eingaben entgegen nehmen, auswerten und Herleitungen präsentieren.
Einzelne Wiki-Seiten können zu einer gemeinsamen Wissensbasis verknüpft werden.4
Eine ausführliche Dokumentation aller Möglichkeiten, die KnowWE bietet, ist in KnowWE selbst integriert. Einen guten Überblick bieten außerdem Baumeister et al. in [BRP09].
2.2.2 Die graphische Notation DiaFlux
Da es sich bei der Modellierung von Wissen – speziell von diagnostischem Wissen – um eine sehr komplexe und fehleranfällige Aufgabe handelt, wurde die graphische Modellierungssprache DiaFlux entwickelt. Der Name leitet sich aus Diagnostik und Fluss ab.
Diagnostische Flüsse, also Abläufe eines diagnostischen Prozesses zur Lösung eines
1 Vgl. [HRBP10], S. 3
2 Vgl. http://www.is.informatik.uni-wuerzburg.de/forschung/anwendungen/d3web/, 13.02.2011, 14:55 Uhr 3 Vgl. http://semanticweb.org/wiki/KnowWE, 13.02.2011, 15:11 Uhr
4 Vgl. http://www.is.informatik.uni-wuerzburg.de/forschung/anwendungen/knowwe/, 13.02.2011, 15:14 Uhr
Problems basierend auf zugrundeliegendem Wissen, beschreiben Workflows und können auch als generalisierte Entscheidungsbäume betrachtet werden.1
DiaFlux wird besonders zur Modellierung klinischer Protokolle eingesetzt. Klinische Protokolle sind die Implementierung klinischer Richtlinien, die meist in textueller Form vorliegen. Domänen-Experten können mit Hilfe von DiaFlux gemeinsam eine klinische Richtlinie zur Verarbeitung durch KnowWE erstellen. Mit DiaFlux modellierte Protokolle sind leicht verständlich, wartbar und direkt ausführbar.2 Durch die vollständige Formalisierung eines klinischen Protokolls kann dieses elektronisch ausgeführt werden.
Dabei werden die vom Nutzer oder über Schnittstellen (z.B. Gerätesensor) erfassten Daten genutzt, um Problemlösungen herzuleiten und zu präsentieren.3
2.2.2.1 DiaFlux Architektur
Die Architektur von DiaFlux umfasst drei Elemente4:
• Knowledge Base: Die Wissensbasis, die im Wiki abgebildet ist, dient als Grundlage der Modellierung der Flussdiagramme.
• Blackboard: Im Blackboard ist der aktuelle Ausführungsstatus eines Flussdiagramms gespeichert. Es beinhaltet alle aktuellen Werte wie externe Nutzereingaben, interne Berechnungen o.ä. samt deren Zeitstempeln.
• Reasoning Engine: Die Reasoning Engine dient der Ausführung des Flussdiagramms. Ihre Aktivität wird durch die Änderung von Daten im Blackboard ausgelöst.
Die Ausführungsumgebung für die DiaFlux Flussdiagramme enthält ein Truth Maintenance System (TMS).5 Als TMS wird die Komponente eines Expertensystems bezeichnet, die die Konsistenz der Wissensbasis aufrecht erhält, auch wenn der Benutzer Zustände verändert.6 Die Abhängigkeiten zwischen eingegebenem und hergeleitetem Wissen sind im TMS gespeichert, so dass Herleitungen jederzeit begründet und nachvollzogen werden können.
Wird etwas an dem zu Grunde liegenden Wissen verändert, passt das TMS das Netz von Abhängigkeiten entsprechend an und erhält den konsistenten Zustand über alle Daten.7 Das Ändern oder Widerrufen von bereits hergeleiteten Problemlösungen darf allerdings nicht immer möglich sein. Bei flüchtigen Aktionen wie der Anzeige eines Wertes kann das TMS diese rückwirkungsfrei zurück nehmen, bei nicht-flüchtigen Aktionen – wie z.B. dem
1 Vgl. [HBB09], S. 1 2 Vgl. [HRBP10], S. 5 f.
3 Vgl. [HBBP11], S. 7 4 Vgl. [HBBP11], S. 7 5 Vgl. [HBBP11], S. 3
6 Vgl. http://www.enzyklo.de/Begriff/Truth%20Maintenance%20System, 25.04.2011, 11:12 Uhr 7 Vgl. [Doy79], S. 233
Einleiten einer Therapie am Patienten – darf das TMS dies nicht widerrufen, denn in der Realität kann die Aktion nicht rückgängig gemacht werden. Um einen solchen Mechanismus in DiaFlux-Flussdiagrammen abzubilden, existieren so genannte Snapshot-Knoten, auf die im nächsten Unterkapitel eingegangen wird.35
2.2.2.2 DiaFlux Sprachelemente
DiaFlux umfasst eine begrenzte Anzahl intuitiver Sprachelemente, die in einem visuellen Editor zur Verfügung stehen. Dabei basiert die graphische Notation auf Flussdiagrammen und den Ontologien, die im Wiki modelliert wurden. Alle Wissenselemente des Wikis können im Editor zum Erstellen von Flussdiagrammen verwendet werden. Um nun beispielsweise klinische Protokolle zu modellieren, muss sowohl deklaratives als auch prozedurales Wissen spezifiziert werden. DiaFlux realisiert beides, indem deklaratives Wissen aus Fakten und deren Beziehungen (z.B. Diagnosen) – also die Terminologie – und prozedurales Wissen über Sequenzen der auszuführenden Aktionen (z.B. Daten erfassen, überprüfen) in einem Flussdiagramm vereint werden.36 Diese Tatsache erlaubt auch den Rückschluss auf die Betrachtung der DiaFlux-Flussdiagramme in der Daten- und Kontrollflussperspektive nach van der Aalst.37 Das deklarative Wissen repräsentiert die Datenperspektive, das prozedurale Wissen die Kontrollflussperspektive.38
Ein DiaFlux-Flussdiagramm besteht aus Knoten und Kanten. Es existiert nur eine Art von Kante bzw. Zustandsübergang, der bzw. dem aber je nach Ausgangsknoten unterschiedliche Bedingungen anliegen können. Kanten beschreiben die Ausführungsreihenfolge im Flussdiagramm. Knoten repräsentieren Aktionen wie z.B. das Ausführen eines Tests oder das Fragen nach einem Wert. 39 Die folgenden Knotentypen stehen in DiaFlux zur Verfügung:
Knoten Funktion Darstellung in DiaFlux
Startknoten Mindestens ein Startknoten muss in einem Flussdiagramm vorhanden sein, mehrere sind möglich.
Endknoten Jeder mögliche Pfad muss durch einen Endknoten beendet werden.
Kommentarknoten Dieser Knoten kann im Flussdiagramm zum Kommentieren eingesetzt werden.
35 Vgl. [HBBP11], S. 8 36 Vgl. [HBB09], S. 1 37 Vgl. [Aal00], S. 163 f.
38 Vgl. [HBBP11], S. 4 39 Vgl. [HBB09], S. 1
Knoten Funktion Darstellung in DiaFlux Testknoten Durch diese Art Knoten wird eine Aktivität
ausgeführt – z.B. das Durchführen eines Tests, das Abfragen eines Wertes vom Benutzer oder Gerät. Bei der Abfrage eines Wertes kann zwischen ask und always ask unterschieden werden. Im ersten Fall wird der Wert einmal abgefragt, wenn er noch nicht bekannt ist. Im zweiten Fall wird der Wert jedes Mal erfragt, wenn der Knoten aktiviert wird.
Der Knoten kann auch verwendet werden, um einen Wert im Flussdiagramm zu berechnen oder festzulegen. Ein solcher Knoten wird auch Abstraktionsknoten genannt.
Fork Knoten Durch diesen Knoten kann der Programmfluss in parallele Pfade verzweigt werden.
Testknoten mit mehreren Ausgangskanten Join Knoten Durch diesen Knoten werden parallele Pfade
wieder zusammengeführt. (Alternativ kann ein paralleler Zweig auch durch einen Endknoten beendet werden. Die anderen parallelen Zweige laufen dann weiter ab.)
Testknoten mit mehreren Eingangskanten
Diagnoseknoten Dieser Knoten symbolisiert die Herleitung einer Problemlösung – konkret einer gefundenen Diagnose.
Snapshot-Knoten Mit einem Snapshot-Knoten werden die bisher erfassten Daten als unveränderbar angenommen und im Blackboard schreibgeschützt. Das TMS kann somit nichts vor diesem Knoten rückgängig machen oder manipulieren. Alle aktiven Knoten auf eingehenden Pfaden werden deaktiviert (ohne ihre Rücknahme), um eine erneute Ausführung zu ermöglichen.40
Kompositionsknoten Dieser Knoten wird zum Einbinden eines anderen Flussdiagramms genutzt. Der Startknoten des eingebundenen Unterdiagramms kann im Knoten ausgewählt werden.
40 Vgl. [HBBP11], S. 5 f.
Knoten Funktion Darstellung in DiaFlux Warteknoten Durch diesen Knoten wird eine Wartezeit in das
Flussdiagramm integriert, die die Ausführung pausiert, bis sie abgelaufen ist.
Schleifenknoten Definierte Aktionen werden in einer gewissen Anzahl von Durchläufen wiederholt.
Tabelle 1: DiaFlux Knotentypen
Quelle: Vgl. [HRBP10] S. 7 f., vgl. [HBB09] S. 2 f., Abbildungen: eigene Darstellung
Mit Hilfe dieser Knoten kann modulares, paralleles und zeitorientiertes diagnostisches Prozesswissen modelliert werden.1 Die Ausführung eines modellierten Prozesses beginnt mit der Aktivierung eines Startknotens und vollzieht sich dann durch die Aktivierung der Knoten und Kanten. Der genaue Aktivierungsvorgang kann der nachfolgenden Tabelle entnommen werden:
Element Voraussetzung für
die Aktivierung
Aktivierung Deaktivierung
Knoten Eine eingehende Kante
ist aktiv / wahr.
Aktion des Knotens wird ausgeführt.
Aktion des Knotens wird rückgängig gemacht.
Kante Die Kante resultiert aus einem Startknoten oder die Bedingung, die an der Kante anliegt, wird wahr.
Der nachfolgende Knoten wird aktiviert, wenn er nicht bereits aktiviert war.
Der nachfolgende Knoten wird deaktiviert, wenn er keine
weiteren, aktiven eingehenden Kanten aufweist.
Tabelle 2: Aktivierungszustände der DiaFlux-Knoten und -Kanten Quelle: Vgl. [HBBP11], S. 8
Welche Kante betreten und welcher Knoten aktiviert wird, wird durch die Dateneingaben im Blackboard determiniert.2
2.2.2.3 DiaFlux Entwicklungsprozess
Der Entwicklungsprozess eines Flussdiagramms mit DiaFlux gestaltet sich wie folgt1:
1 Vgl. [HBB09], S. 5 2 Vgl. [HBBP11], S. 8
• Sammeln von informellem Wissen in Wiki-Artikeln
• Erstellen eines semiformalen Flussdiagramms lediglich aus Kommentarknoten
• Erstellen eines formalen Flussdiagramms
Schon während dieser schrittweisen Formularisierung sind Test des Modells möglich.2 2.2.3 Anwendungsbeispiel
Die Arbeitsweise mit KnowWE und DiaFlux soll nun anhand eines Beispiels illustriert werden. Die zu modellierende Aufgabe ist die Berechnung des Nettopreises und der Mehrwertsteuer (MwSt) anhand des durch den Nutzer angegebenen Bruttopreises und der Art der Ware. Dabei sind folgende Waren wählbar: Grundnahrungsmittel, außer Getränken und Alkohol, Buch oder Zeitschrift sowie Blumen (bei einem Mehrwertsteuersatz von 7%); Miete kalt, Porto oder Arzthonorar (bei einem Mehrwertsteuersatz von 0%) und Alkohol, Kleidung oder Sonstiges (bei einem Mehrwertsteuersatz von 19%). Anhand der ausgewählten Art der Ware wird der entsprechende Mehrwertsteuersatz (Faktor 0; 0,07 oder 0,19) der Berechnung zu Grunde gelegt.
Der Nettopreis berechnet sich nach folgender Formel:
Die Mehrwertsteuer (MwSt) berechnet sich nach folgender Formel:
In KnowWE wurden nun zuerst die durch den Nutzer auszufüllenden oder automatisch zu generierenden Felder definiert:
%%Question Start #1
- Art der Ware [oc]
-- Grundnahrungsmittel, außer Getränken und Alkohol -- Buch oder Zeitschrift
-- Blumen -- Miete kalt -- Porto
-- Arzthonorar
1 Vgl. [HRBP10], S. 10 2 Vgl. [HRBP10], S. 10
-- Alkohol -- Kleidung -- Sonstiges
- Bruttopreis incl MwSt [num]
- Nettopreis [num] <abstract>
- MwSt [num] <abstract>
- Faktor [num] <abstract>
@package: Demo
%
Abbildung 4: KnowWE - Fragebaum MwSt Quelle: eigene Darstellung
Es handelt sich hierbei um einen sogenannten Fragebaum (%%Question), der mit der ersten Frage (Start #1) beginnen soll (Art der Ware). Fragen und Antwortmöglichkeiten können über die Anzahl der Anstriche hierarchisch geschachtelt werden. Die Frage nach der Art der Ware ermöglicht die Auswahl einer einzelnen Ware ([oc] = one choice). Die Antwortmöglichkeiten sind unterhalb der Frage eingeordnet. Es folgt die Frage nach dem numerischen ([num]) Bruttopreis. Die drei anschließend definierten numerischen Werte Nettopreis, MwSt und Faktor werden nicht durch den Benutzer eingegeben, sondern automatisch durch das System berechnet. Dies wird durch das Schlüsselwort <abstract> deutlich.1
Die möglichen Herleitungen, also die drei unterschiedlichen Steuersätze, die aus den Nutzereingaben abgeleitet werden können, sind unter dem Markup %%Solution definiert.
%%Solution Steuersatz - keine (0%) - ermäßigt (7%) - normal (19%)
@package: Demo
%
Abbildung 5: KnowWE - Herleitungen des MwSt-Satz Quelle: eigene Darstellung
Um nun aus den definierten Werten und Herleitungen tatsächliche eine Berechnung der Mehrwertsteuer und des Nettopreises einer Ware zu erzeugen, sind Regeln zu modellieren.
Die Regeln in KnowWE lassen sich unterteilen in Diagnose-, Abstraktions-, Indikations- und Suppressionsregeln2:
1 Vgl. http://d3webwiki.informatik.uni-wuerzburg.de/Wiki.jsp?page=Doc%20Questions, 18.02.2011, 17:10 Uhr 2 Vgl. http://d3webwiki.informatik.uni-wuerzburg.de/Wiki.jsp?page=Doc%20Rules, 18.02.2011, 17:19 Uhr
• Diagnoseregeln werden genutzt, um Herleitungen festzulegen. Dabei werden Herleitungen Werte zugeordnet (siehe Abbildung 6), die festlegen, wie stark diese zutreffen (P) oder abzulehnen sind (N). Anhand dieser Werte werden die Diagnosen etabliert oder verworfen.
Abbildung 6: KnowWE - Gewichtung von Herleitungen (Diagnosen) Quelle: KnowWE Dokumentation1
• Abstraktionsregeln setzen einen als abstrakt definierten Wert automatisch auf einen bestimmten Wert.
• Indikationsregeln veranlassen die Darstellung weiterer Fragen bzw. Fragebäume.
• Suppressionsregeln sind das Gegenteil von Indikationsregeln und ermöglichen das Unterdrücken bestimmter Fragestellungen.
Im Beispiel der Mehrwertsteuerberechnung werden Diagnoseregeln eingesetzt, um anhand der Nutzereingaben die Herleitung für den Steuersatz festzulegen. Abstraktionsregeln bestimmen dann den Faktor für die Berechnung. Ist der Faktor definiert, kann er in weiteren Abstraktionsregeln zur tatsächlichen Berechnung genutzt werden.
%%Rule
IF "Art der Ware" = "Miete kalt" OR "Art der Ware" = "Porto" OR
"Art der Ware" = "Arzthonorar"
THEN "keine (0%)" = P7
IF "keine (0%)" = ESTABLISHED THEN "Faktor" = (0)
IF "Art der Ware" = "Grundnahrungsmittel, außer Getränken und Alkohol" OR "Art der Ware" = "Buch oder Zeitschrift" OR "Art der Ware" = "Blumen"
THEN "ermäßigt (7%)" = P7
IF "ermäßigt (7%)" = ESTABLISHED THEN "Faktor" = (0.07)
IF "Art der Ware" = "Alkohol" OR "Art der Ware" = "Kleidung" OR
"Art der Ware" = "Sonstiges"
1 http://d3webwiki.informatik.uni-wuerzburg.de/Wiki.jsp?page=Doc%20DiagnosisRule, 18.02.2011, 17:03 Uhr
THEN "normal (19%)" = P7
IF "normal (19%)" = ESTABLISHED THEN "Faktor" = (0.19)
IF "Faktor" > -1
THEN "Nettopreis" = ("Bruttopreis incl MwSt" / (1+"Faktor") )
IF "Faktor" > -1
THEN "MwSt" = ("Bruttopreis incl MwSt") - ("Bruttopreis incl MwSt" / (1+"Faktor") )
@package: Demo
%
Abbildung 7: KnowWE – Regeln zur MwSt-Berechnung Quelle: eigene Darstellung
Das modellierte Wissen wird in einer Wissensbasis zusammengefasst:
%%KnowledgeBase MwSt-Berechnung
@uses: Demo
%
Abbildung 8: KnowWE – KnowledgeBase Quelle: eigene Darstellung
Dies ist dadurch erkenntlich, dass die Wissenselemente Bestandteil des Pakets „Demo“
(@package: Demo) sind. Die Wissensbasis nutzt (@uses: Demo) alle diese Paketinhalte und kann separat aus dem Wiki heruntergeladen werden, um in einer anderen Umgebung, z.B. auf einem Gerät, zum Einsatz zu kommen.
Auch in KnowWE selbst kann das modellierte Wissen direkt ausgeführt werden. Der Nutzer wird mittels eines Kurzinterviews ([{KnowWEPlugin quickInterview}]) auf der Wiki-Seite nach seinen Eingaben gefragt. Die hinterlegten Regeln werden ausgeführt und die Herleitungen und Berechnungsergebnisse direkt angezeigt.
Abbildung 9: KnowWE - QuickInterview Quelle: eigene Darstellung
Die angewendeten Regeln werden farblich hervorgehoben. Aufgrund der Auswahl der Warenart „Kleidung“ wird der normale Mehrwertsteuersatz von 19% etabliert (P7). Dadurch wird der Faktor mit 0,19 belegt. Aufgrund dessen wird die weitere Berechnung der gesuchten Werte durchgeführt.
Abbildung 10: KnowWE - angewendete Regeln zur MwSt-Berechnung Quelle: eigene Darstellung
Auch die gefundene Lösung wird markiert:
Abbildung 11: KnowWE - etablierte Herleitung / Diagnose für den MwSt-Satz Quelle: eigene Darstellung
Der dargestellte Modellierungsaufwand kann um das Regelwerk reduziert werden, wenn die Notation DiaFlux zum Einsatz kommt. Die Abbildung auf der nächsten Seite zeigt denselben
Sachverhalt graphisch modelliert. Durch die Darstellung der Fragen und Herleitungen in der Syntax des Wikis stehen diese im DiaFlux-Editor als Knoten zur Auswahl. Ein Zugriff auf die Elemente der gesamten Wissensbasis ist von hier aus möglich.
Der Startknoten wurde modelliert, aber aus Platzgründen nicht mit in die Abbildung aufgenommen. Das gleiche gilt für den Endknoten. Der erste Knoten stellt dem Nutzer die Frage nach dem Bruttowert. Ist dieser bekannt (known), wird die Art der Ware erfragt. Aus letzterer Angabe wird der Steuersatz hergeleitet. Aus den Diagnoseknoten des Steuersatzes leiten sich direkt die abstrakten Knoten für den Berechnungsfaktor ab. In diese Knoten wird der Wert für den Faktor gesetzt. Danach laufen die alternativen Pfade im Diagramm wieder zusammen, um schließlich die Berechnungen für den Nettopreis und die Mehrwertsteuer auszuführen. Dies geschieht in den letzten beiden Knoten.
Durch die Modellierung eines Flussdiagramms mit DiaFlux vereinfacht sich also die Darstellung des Wissens. Das zugrunde liegende Wissen kann auf einen Blick erfasst werden, die komplexe Regelsyntax wird obsolet.
Abbildung 12: DiaFlux - Flussdiagramm zur Berechnung der MwSt Quelle: eigene Darstellung
2.3 Prozess- und Workflow-Modellierung
Da es sich bei der Modellierung vornehmlich klinischer Leitlinien mit DiaFlux um die Abbildung komplexer Prozesse handelt, wird an dieser Stelle auf die Modellierung eben solcher Prozesse näher eingegangen. Ein passendes Äquivalent zu der Modellierung in DiaFlux ist die Modellierung von Geschäftsprozessen – wenn auch nicht in allen Details.
„Modelle sind vereinfachte Beschreibungen bestimmter Sachverhalte der Realwelt bzw. einer gedachten Welt, mit denen man ein bestimmtes Ziel verfolgt.“1 Sie abstrahieren und reduzieren die Realität. In der Informatik repräsentieren sie unter Anderem algorithmische Problemlösungen und ermöglichen so die vereinfachte Kommunikation zwischen den an der Entwicklung beteiligten Personen. Prozessmodelle nutzen graphische Notationen, um eine gemeinsame Sprache für die Beteiligten zu schaffen.2
Modelle von Geschäftsprozessen spezifizieren bestimmte Aktivitäten und deren Beziehungen zueinander in einem komplexen Geschäftsumfeld.3 Die Aktivitäten werden in Reaktion auf ein geschäftliches Ereignis ausgeführt, um ein bestimmtes Geschäftsziel zu erreichen. Ein Beispiel hierfür kann ein Bestellprozess oder das Management einer Kundenbeschwerde sein.4 Geschäftsprozesse operieren auf Daten und repräsentieren Abhängigkeiten zwischen diesen. Für die Darstellung dieser datenbezogenen Aspekte eigenen sich Workflows.5
Der Begriff „Workflow“ bedeutet übersetzt „Arbeitsfluss“. Ein Workflow beschreibt also einen Arbeitsablauf, einen Prozess. Er unterstützt ihn technisch - gänzlich oder auch teilweise. Je nach Eingabedaten wird ein Workflow nach dem gleichen oder ähnlichen Schema durchlaufen.6 Die einzelnen Vorgangschritte werden in Abhängigkeit von Bedingungen ganz oder teilweise sequentiell, alternativ oder parallel ausgeführt.7 Durch den Workflow wird der Prozess eindeutig modelliert, was natürlich eine vollständige Beschreibung der Prozesssituation voraussetzt.8 Gerade im Zusammenhang mit DiaFlux ist der Begriff der Modellierung eines Workflows passend, da einer der grundlegenden Workflow-Typen, die das internationale Standardisierungsgremium „Workflow Management Coalition“ definiert, der folgende ist: „Der Collaborative Workflow unterstützt das
1 [SVOK11], S. 23 f.
2 Vgl. [SVOK11], S. 24 ff.
3 Vgl. [Wes07], S. 125 4 Vgl. [HA10], S. 28 5 Vgl. [Wes07], S. 98 ff.
6 Vgl. [Mül05], S. 8
7 Vgl. [Gal97], S. 7 nach H. Heimann: Workflow Management, 1994, S. 10.
8 Vgl. http://www.itwissen.info/definition/lexikon/Workflow-workflow.html, 24.02.2011, 19:13 Uhr
gemeinsame Erarbeiten eines Ergebnisses;…“1 In DiaFlux werden gemeinschaftlich durch Wissensingenieure und Domänenexperten Wissensbasen erarbeitet und Prozessabläufe zur Diagnostik modelliert.2
2.3.1 Workflow-Konzepte und -Perspektiven
Bei der Beschreibung von Workflows spielen unterschiedliche Konzepte eine Rolle3:
• Fall / Case: zeitlich limitierter Durchlauf eines Workflows, z.B. Bestellvorgang.
• Aufgabe / Task: logische Arbeitseinheit zum Strukturieren eines Workflows, z.B.
Überprüfung eingegebener Daten. Dabei wird die Ausführung einer Aufgabe als Aktivität bezeichnet.
• Prozess: bestimmte Aufgaben in definierter Reihenfolge.
• Routing: Verfolgen von Pfaden (=Ausführung von Aufgaben) im Workflow. Dabei wird unterschieden in sequentielles, paralleles, selektives oder iteratives Routing.
• Inkraftsetzung / Enactment: Aufgaben, die nicht direkt ausgeführt werden, benötigen Auslöser wie die Initiative einer Ressource, ein externes Ereignis oder ein Zeitsignal.
Ein Workflow kann außerdem aus unterschiedlichen Perspektiven betrachtet werden. Die Kontrollfluss- oder Prozessperspektive definiert, welche Aufgaben in welcher Reihenfolge und entlang welches Pfades im Fluss ausgeführt werden. Die Ressourcen- oder Organisationsperspektive beschreibt die Ressourcen (Menschen, Geräte etc.) und die Beziehungen zwischen Rollen und Gruppen dieser. Dazu zählen beispielsweise Verantwortlichkeiten einzelner Personen. Die Daten- oder Informationsperspektive charakterisiert Kontrolldaten und Produktionsdaten. Kontrolldaten steuern den Durchlaufprozess des Workflows, Produktionsdaten spiegeln die informativen Inhalte (z.B.
Dokumente) wider. In der Aufgaben- oder Funktionsperspektive werden die Aufgaben, die die Ressourcen durchführen, detailliert spezifiziert. Die Durchführungs- oder Anwendungsperspektive umfasst Applikationen, die die Produktionsdaten der Informationsperspektive modifizieren und mit deren Hilfe Aufgaben erfüllt werden können.4 Die Perspektiven ähneln den Sichten des ARIS5-Hauses, das einen Ordnungsrahmen für die Spezifikation eines betrieblichen Informationssystems und dessen Prozessmodellierung bildet.6
1 [Mül05], S. 8 2 Vgl. [HRBP10], S. 1 3 Vgl. [AH04], S.31 ff.
4 Vgl. [Aal00], S. 163
5 ARIS = Architektur integrierter Informationssysteme 6 Vgl. [Gal97], S. 39
Für die Modellierung von Flussdiagrammen in DiaFlux und die Analyse von Anomalien werden einige dieser Perspektiven außer Acht gelassen. Die Ressourcen- oder Organisationsperspektive spielt inhaltlich keine Rolle, Ressourcen werden nicht in die Modellierung aufgenommen. Auch detaillierte Beschreibungen der einzelnen Tätigkeiten innerhalb von Aufgaben wie in der Aufgaben- und Funktionsperspektive werden nicht vorgenommen. Die Durchführungs- und Anwendungsperspektive wird ebenfalls nicht betrachtet, da die in DiaFlux modellierten klinische Richtlinien in Form von Wissensbasen aus KnowWE exportiert werden und in einem anderen Umfeld, beispielweise in der automatisierten Steuerung eines Medizingerätes, zum Einsatz kommen.
2.3.2 Datenflussperspektive
Modellierungsfehler entstehen oft im Zusammenspiel zwischen Daten- und Kontrollfluss.
Daher ist die aufmerksame Modellierung des Datenflusses von großer Bedeutung.1 In der Spezifikation des Datenflusses geht es darum, wie Daten durch Aktivitäten produziert und konsumiert werden.2 Datenelemente können gelesen, geschrieben und zerstört werden.3 Dabei bearbeiten die einzelnen Aktivitäten die Daten und besitzen eingehende (Input-/Eingabe- Daten) und ausgehende (Output-/Ausgabe-Daten) Datenflüsse. Physikalisch werden die Daten nicht weiter geleitet.4
Eine Datenfluss-Matrix kann helfen, einen Überblick über den Datenfluss zu erhalten. Dabei werden in zweidimensionaler Form die unterschiedlichen Operationen der Datenelemente d den Aktivitäten v zugeordnet. Wird ein Datum durch eine Aktivität gelesen (R = read), so handelt es sich um einen Eingabewert. Wird ein Datum geschrieben (W = write), ist es der Ausgabewert der Aktivität.5 Die folgende Tabelle zeigt exemplarisch eine solche Datenflussmatrix:
Datenelement / Aktivität v1 v2 v3
d1: Patientenname W R
d2: Geburtsdatum W R
Tabelle 3: Beispiel für eine Datenfluss-Matrix
Quelle: eigene Darstellung in Anlehnung an [SZN05], S. 2919 f.
1 Vgl. [ADL10], S. 1 2 Vgl. [SZN05], S. 2917 3 Vgl. [TAS09], S. 3 f.
4 Vgl. [Gal97], S. 83 5 Vgl. [SZN05], S. 2918 ff.
