Hochschule Wismar

Transcription

Hochschule Wismar

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
Analyse von Anomalien in der graphischen Modellierung von diagnostischem Wissen
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.
- II -
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 - III -
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 - IV -
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 -V-
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 - VI -
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 - VII -
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 - VIII -
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 - IX -
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
-X-
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
- XI -
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
-1-
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 Kontrollflussund 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
-2-
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 DiaFluxspezifische 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.
-3-
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
-4-
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,
•
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
2
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 MetaInformationen 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/SemantischesNetz/Ontologien/index.html/?searchterm=ontologie, 13.02.2011, 10:55 Uhr
-5-
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
-6-
– 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
-7-
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
-8-
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
-9-
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
- 10 -
Knoten
Funktion
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.
Join Knoten
Ausgangskanten
Durch diesen Knoten werden parallele Pfade
Testknoten mit mehreren
wieder zusammengeführt. (Alternativ kann ein
Eingangskanten
paralleler Zweig auch durch einen Endknoten
beendet werden. Die anderen parallelen Zweige
laufen dann weiter ab.)
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),
Ausführung zu
Kompositionsknoten
Testknoten mit mehreren
um
eine
erneute
ermöglichen.40
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.
- 11 -
Knoten
Funktion
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
Aktivierung
Deaktivierung
Eine eingehende Kante
Aktion des Knotens
Aktion des Knotens
ist aktiv / wahr.
wird ausgeführt.
wird rückgängig
die Aktivierung
Knoten
gemacht.
Kante
Die Kante resultiert aus
Der nachfolgende
Der nachfolgende
einem Startknoten oder
Knoten wird aktiviert,
Knoten wird deaktiviert,
die Bedingung, die an
wenn er nicht bereits
wenn er keine
der Kante anliegt, wird
aktiviert war.
weiteren, aktiven
wahr.
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
- 12 -
•
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
- 13 -
-- Alkohol
-- Kleidung
-- Sonstiges
- Bruttopreis incl MwSt [num]
- Nettopreis [num] <abstract>
- MwSt [num] <abstract>
- Faktor [num] <abstract>
@package: Demo
%
Abbildung 4: KnowWE - Fragebaum MwSt
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
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
- 14 -
•
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
- 15 -
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
Das modellierte Wissen wird in einer Wissensbasis zusammengefasst:
%%KnowledgeBase
MwSt-Berechnung
@uses: Demo
%
Abbildung 8: KnowWE – KnowledgeBase
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.
- 16 -
Abbildung 9: KnowWE - QuickInterview
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
Auch die gefundene Lösung wird markiert:
Abbildung 11: KnowWE - etablierte Herleitung / Diagnose für den MwSt-Satz
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
- 17 -
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.
- 18 -
Abbildung 12: DiaFlux - Flussdiagramm zur Berechnung der MwSt
- 19 -
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
- 20 -
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
- 21 -
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-/EingabeDaten) 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
d1: Patientenname
W
R
d2: Geburtsdatum
W
v3
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.
- 22 -
Der Datenfluss in einem Workflow muss die Ein- und Ausgabedaten verwalten, die
Verfügbarkeit der Daten an den entsprechenden Stellen gewährleisten und einen konsistenten
Fluss sicherstellen.1 Er kann explizit oder implizit im Kontrollfluss modelliert werden.2 In der
Arbeit wird der letztgenannte Fall betrachtet, bei dem die Daten über den Kontrollfluss durch
den Workflow „transportiert“ werden.
2.3.3 Kontrollfluss-Muster in der Kontrollflussperspektive (Control Flow Pattern)
Der Kontrollfluss beschreibt die Ablauffolge von Aktivitäten und somit die dynamischen
Aspekte eines Prozesses. Dabei kann zwischen sequentiellen, alternativen oder parallelen
Flussformen unterschieden werden.3
Der Ablauf eines Prozesses weist in jeder Modellierung wiederkehrende Muster auf, die auch
Kontrollfluss-Muster genannt werden. Muster in Kontrollflüssen von Prozessen sind
unabhängig von einer konkreten Modellierungssprache für Prozesse. Sie können direkt am
Prozessmodell erläutert werden. Dabei ist zunächst zu klären, wie der Begriff des
Prozessmodells definiert ist.4
Bei
handelt es sich um ein Prozessmodell, wenn es aus einer Menge von
Knoten ( ) und einer Menge von Kanten ( ) besteht. Dabei verbinden die Kanten einzelne
Knoten und beschreiben den Kontrollfluss durch das Prozessmodell. Knoten werden
unterschieden nach Aktivitätsknoten (
), Ereignisknoten (
) und Gateway-Knoten (
).
Ein Gateway-Knoten steuert den Kontrollfluss und definiert den Typ des Prozessmodells.5
Für die nachfolgende Vorstellung der Kontrollfluss-Muster sollen folgende Festlegungen
gelten:
•
Jedes Muster eines Kontrollflusses wird durch ein Gateway
•
Aktivitäten werden durch Großbuchstaben gekennzeichnet, z.B.
Aktivitäten mit den korrespondierenden Kleinbuchstaben
.
•
Folgt eine Aktivität
auf
, so kann
erst starten, wenn
1 Vgl. [SOSF04], S. 209
2 Vgl. [SOSF04], S. 213
3 Vgl. [Gal97], S. 73
4 Vgl. [Wes07], S. 92
5 Vgl. [Wes07], S. 92
6 Vgl. [Wes07], S.126
- 23 -
repräsentiert.
; Instanzen von
terminiert ist.6
2.3.3.1 Sequenz / Sequence
Die Instanz einer Aktivität
wird nach der Instanz einer Aktivität ausgeführt. kann
erst aktiviert werden, wenn
terminiert ist. Der Typ des Prozessmodells ist
1
.
Abbildung 13: Sequenz
Quelle: [Wes07], S. 127
2.3.3.2 AND Split
Ein AND Split verzweigt von einem einzelnen Pfad in mehrere Pfade, die parallel ausgeführt
werden. Nachdem eine Instanz
terminiert ist, werden die beiden Instanzen
und
2
ausgeführt. Der Typ des Prozessmodells ist
.
Abbildung 14: AND Split / paralleler Split
2.3.3.3 AND Join
Ein AND Join vereint mehrere parallele Pfade wieder zu einem einzigen Ausführungspfad im
Kontrollfluss. Jeder eingehende Pfad wurde dabei genau einmal ausgeführt. Bevor Aktivität
in der nachfolgenden Abbildung aktiviert wird, terminierten zuerst sowohl die Aktivitäten
als auch . Der Typ des Prozessmodells ist
.3
1 Vgl. [Wes07], S. 126 f.
2 Vgl. [Wes07], S. 128 f.
3 Vgl. [Wes07], S. 129
- 24 -
Abbildung 15: AND Join
2.3.3.4 XOR Split
An der Stelle eines XOR Splits wird die Ausführung exklusiv auf nur einen der
nachfolgenden Pfade gelenkt. Nachdem eine Instanz der Aktivität
terminiert ist, wird
entweder eine Instanz der Aktivität
oder eine Instanz der Aktivität
aktiviert, in keinem
Fall aber beide. Der Typ des Prozessmodells ist
.1
Abbildung 16: XOR Split / exklusiver OR Split
2.3.3.5 XOR Join
An der Stelle eines XOR Joins laufen zwei oder mehrere alternative Pfade ohne
Synchronisation zusammen. Diesem Muster wird die Annahme zugrunde gelegt, dass nur ein
alternativer Pfad ausgeführt wurde. Durch das Terminieren einer der beiden Aktivitäten
oder
wird ein einziges Mal die Aktivität
aktiviert. Der Typ des Prozessmodells ist
.2
1 Vgl. [Wes07], S. 130
2 Vgl. [Wes07], S. 130
- 25 -
Abbildung 17: XOR Join / exklusiver OR Join
2.3.3.6 OR Split
An dieser Stelle wird im Prozessmodell eine beliebige Anzahl von Pfaden für die weitere
Ausführung gewählt. Für ein korrektes Verhalten ist mindestens ein Pfad zu bestimmen.
Durch das Terminieren einer Instanz der Aktivität
werden Instanzen der Aktivitäten
oder
oder aber Instanzen beider Aktivitäten angestoßen. Der Typ des Prozessmodells ist
.1
Abbildung 18: OR Split
2.3.3.7 OR Join
In einem OR Join laufen mehrere Ausführungspfade zusammen. Dabei wird angenommen,
dass ein einmal aktivierter Pfad nicht erneut aktiviert werden kann. Wenn alle vorher aktiven
Pfade durchlaufen wurden, findet die Synchronisation statt. Der Typ des Prozessmodells ist
.2
1 Vgl. [Wes07], S. 131
2 Vgl. [Wes07], S. 131 f.
- 26 -
Abbildung 19: OR Join
Der OR Join ist eine problematische Kontrollfluss-Struktur, da ohne zusätzliches Wissen
keine Entscheidung getroffen werden kann, wie lange der OR Join wartet, bevor er die darauf
folgende Instanz aktiviert. Der OR Join hat zwei Möglichkeiten nachdem beispielsweise die
Instanz der Aktivität
terminiert: er kann direkt die Instanz der Aktivität
aktivieren
oder er kann warten, bis die Instanz
der Aktivität
ebenfalls terminiert. Welche
1
Möglichkeit die richtige ist, kann nicht entschieden werden.
Neben den grundlegenden Mustern existieren weitere, die in [Wes07] nachgelesen werden
können.
Komplexe Prozesse mit ihren unterschiedlichen Daten- und Kontrollstrukturen können in
verschiedenster
Art
und
Weise
dargestellt
werden.
Die
wichtigsten
Modellierungsformalismen werden nun vorgestellt.
2.3.4 Techniken zur Modellierung von Prozessen
2.3.4.1 Petri-Netze
Petri-Netze sind eine der bestbekannten Techniken zur formalen und abstrakten Modellierung
von (Geschäfts-)Prozessen. Daher bilden sie eine wichtige Grundlage für weitere
Prozessmodellierungssprachen. Ein Petri-Netz erlaubt es, sowohl die statische Struktur als
auch die dynamischen Abläufe in einem Prozess zu modellieren. Dabei besteht ein solches
Netz aus Stellen, Transitionen und gerichteten Kanten, die beide miteinander verbinden.
Durch das Netz wandern sogenannte Token, die den dynamischen Fluss und aktuellen
Zustand widerspiegeln. Wandert ein Token in eine Transition, wird sie gefeuert. Die
nachfolgende Abbildung zeigt ein Beispiel für ein Petri-Netz, das einen Geschäftsprozess
modelliert. Dabei sind die Stellen kreisförmig, die Transitionen quadratisch dargestellt. Der
Token befindet sich in der ersten Stelle, so dass die nachfolgende Transition „receive order“
gefeuert wird. Feuert beispielsweise die Transition „process order“, werden die
nachfolgenden Stellen mit Token besetzt und die Pfade parallel ausgeführt.2
1 Vgl. [Wes07], S. 133
2 Vg. [Wes07], S. 149
- 27 -
Abbildung 20: Beispiel für ein Petri-Netz
An die Kanten sind Bedingungen aus Daten und Operatoren geknüpft, die die nachfolgenden
Aktivitäten bestimmen.1 Die flussorientierte Natur von Prozessen, die Arbeitsabläufe
repräsentieren, machen Petri-Netze zu einem perfekten Kandidaten für die Modellierung und
Analyse von solchen Arbeitsabläufen (im weiteren Workflows genannt).2
Da Petri-Netze nicht alle Aspekte der Prozessmodellierung abdecken können, wurden sie um
einige Unterarten erweitert, die u.a. in [Wes07] nachvollzogen werden können. Die
modellierte Prozessstruktur ist für Außenstehende meist nur schwer lesbar.3
2.3.4.2 Workflow Netze
Workflow Netze sind eine Erweitung der Petri-Netze, da diese lediglich für einfache Prozesse
geeignet sind. Durch den Einsatz einer formalen Repräsentation wird die einfache Analyse
der Prozesseigenschaften möglich. Außerdem bietet die graphische Darstellung eine gut
verständliche Diskussionsgrundlage für die Domänenexperten. Workflow Netze bilden – wie
auch Petri-Netze – den Kontrollfluss der Prozesse ab. Die Stellen in einem Workflow Netz
repräsentieren Bedingungen, die Transitionen Aktivitäten. Auch die Bildung von Hierarchien
ist möglich. In der folgenden Abbildung wird diese Tatsache durch das Kästchen mit der
doppelten Begrenzung angedeutet, das mehrere Aktivitäten darstellt.4
Abbildung 21: Beispiel für ein Workflow Netz
1 Vgl. [Gal97], S. 74 f.
2 Vgl. [TAS09], S. 425
3 Vgl. [Spe01], S. 95
4 Vgl. [Wes07], S. 169 f.
- 28 -
Allgemeingültig kann festgehalten werden, dass ein Workflow Netz ein Petri-Netz mit einer
eindeutigen Quelle und einer eindeutigen Senke ist.1 Jede Stelle und jede Transition liegt auf
einem Pfad zwischen Quelle und Senke.2
2.3.4.3 Yet Another Workflow Language (YAWL)
Yet Another Workflow Language (YAWL) ist eine Prozessmodellierungssprache, die 2002
von Wil van der Aalst und Arthur ter Hofstede entwickelt wurde. Sie basiert auf Petri- bzw.
Workflow Netzen und ist in der Lage, alle dargestellten Muster des Kontrollflusses
abzudecken. Damit geht sie über die klassischen Petri- und Workflow Netze hinaus.3
2.3.4.4 Ereignisgesteuerte Prozessketten (EPK)
Ereignisgesteuerte Prozessketten (EPK) realisieren eine informelle, fein-granulare
Modellierung aus der Geschäftsperspektive. Sie sollen hauptsächlichedomänenspezifische
Abläufe beschreiben und dabei nicht auf formale Aspekte oder technische Implementierungen
eingehen. EPKs bestehen aus Ereignissen, Funktionen, Konnektoren und Kanten, die den
Kontrollfluss beschreiben.4
Abbildung 22: Elemente der EPK-Modellierung
Sie basieren auf Petri-Netzen, nutzen aber Ereignisse statt Zuständen, die zu Aktivitäten
führen und so den Ablauf des Geschäftsprozesses beeinflussen.5
1 Vgl. [TAS09], S. 428
2 Vgl. [Wes07], S. 170
3 Vgl. [HA10], S.9
4 Vgl. [Wes07], S. 158 ff.
5 Vgl .[Spe01], S. 96
- 29 -
2.3.4.5 Business Process Modelling Notation (BPMN)
BPMN basiert auf graphischen Modellierungssprachen wie Petri-Netzen, UML und EPKs.
Die Notation umfasst alle Abstraktionsebenen von der Geschäftssicht bis hin zur technischen
Implementierung. Die wichtigsten Sprachelemente sind Ereignisse, Aktivitäten, Gateways
und der Kontrollfluss.1 Eine Beispielmodellierung zeigt die folgende Abbildung. Nachdem
ein Abgleich der Bestellung mit dem Lager erfolgt ist, wird entschieden, welcher Pfad
betreten wird. Ist das Produkt vorhanden, wir es zusammen mit der Rechnung verschickt. Ist
es nicht vorhanden, wird es nach dem Einkauf von Rohmaterial und der Erstellung eines
Produktionsplans produziert.
Abbildung 23: Beispiel für BPMN
1 Vgl. [Wes07], S. 205 f.
- 30 -
2.4 Verifikation im Kontext von Wissensbasen und deren Modellierung
Nachdem die Modellierung von Prozessen bzw. Workflows betrachtet wurde, soll nun auf die
Verifikation einer solchen Modellierung eingegangen werden.
Die Begriffe Validierung und Verifikation sind in der Literatur vielfältig beschrieben und in
unterschiedlichster Art und Weise gedeutet. In dieser Arbeit werden die Begriffe wie folgt
verwendet:
„Valiation is building the right system.“1
„Verification is building the system right.“2
Mit der Verifikation wird also überprüft, ob die spezifizierten Anforderungen erfüllt werden.
Unter spezifizierten Anforderungen ist dabei die niedergeschriebene Spezifikation zu
verstehen. Mit der Validierung wird evaluiert, ob die tatsächlichen Anforderungen realisiert
werden. Die tatsächlichen Anforderungen entsprechen dabei den Vorstellungen des
Auftraggebers, die leider nicht immer mit der formalisierten Spezifikation übereinstimmen. In
der Prozessmodellierung bedeutet das konkret, dass ein Modell das Ausführungsverhalten an
den Tag legt, das der Designer beabsichtigt hat. Daher müssen vor einer Validierung die
Struktur des Prozesses und die Anforderungen an die Prozessaktivitäten bekannt sein.3
Während die Validierung also ein „Black-Box-Test“ ist, der das sinnvolle Verhalten des
Systems bewertet ohne Einzelheiten des Systems zu kennen, handelt es sich bei der
Verifikation um die Analyse eines „gläsernen“ Systems in Form eines „White-Box-Testes“.4
Bei der Verifikation sollen durch eine syntaktische Analyse Anomalien gefunden werden, die
auf eine Abweichung von der Spezifikation hindeuten.5 Fehler, die bei der Abbildung eines
Prozessmodells auf einen Workflow modelliert wurden, können mit den unterschiedlichen
Verifikationsmethoden aufgedeckt werden.6
Bei der Modellierung von Prozessen treten oft Fehler auf, da die Domänenexperten kein
Expertenwissen im Bereich der Modellierung aufweisen. Sie arbeiten zwar mit den Designern
der Workflows zusammen, die gemeinsame Schnittmenge an Wissen ist allerdings oft sehr
gering.7 Besonders die Modellierung klinischer Richtlinien gestaltet sich schwierig, da diese
oft vage formuliert, unvollständig und unklar sind. Sie unterliegen außerdem einem ständigen
1 [Pre98], S. 39
2 [Pre98], S. 39
3 Vgl. [SOSF04], S. 208 f.
4 Vgl. [Bau10], S. 6
5 Vgl. [Bau10], S. 11
6 Vgl. [BZ03], S. 206
7 Vgl. [SOSF04], S. 207
- 31 -
Änderungsprozess.1 Der Prozess des Knowledge Engineerings, also des Zusammentragens
und Modellierens von Wissens, ist in diesem Bereich sehr komplex. Das Wissen kann nicht
durch generische Algorithmen implementiert, sondern muss in wissensbasierten Systemen
abgebildet werden. Die vielfältigen Spezialfälle fordern ein solches meist regelbasiertes
System, da die Wissensbasis selbst die Lösungen zu den Problemen herleiten muss und diese
Lösungen nicht vorgegeben oder von vornherein bekannt sind.2
Gängige Verfahren zur Qualitätssicherung sind die Inspektion, die statische Verifikation, der
formale Beweis, die Cross-Reference Verifikation und das empirische Testen. Bei der
Inspektion wird das Wissen manuell durch einen Menschen gelesen und überprüft. Diese
Methode ist nicht sehr zuverlässig. Bei der statischen Verifikation werden logische
Anomalien identifiziert, wobei Redundanzen und Konflikte am häufigsten auftreten. Der
formale Beweis ist eine gründlichere, vollständige statische Verifikation, die in der Praxis
kaum anzutreffen ist, da sie sehr aufwendig ist. Eine Cross-Reference Verifikation ist
möglich, wenn die Beschreibung der Wissensbasis auf unterschiedlichen Ebenen vorliegt. So
ließe sich beispielsweise das Konzept mit dem Design und dieses wiederum mit der
Implementierung vergleichen. Beim empirischen Testen werden Testfälle durchlaufen, die
möglichst alle Pfade des modellierten Systems abdecken. Dabei werden sowohl Testfälle für
die funktionalen (Black-Box-Test) als auch die strukturellen Aspekte (White-Box-Test)
angewendet. Durch die Anwendung all dieser Verfahren kann gewährleistet werden, dass die
modellierte Wissensbasis frei von logischen und strukturellen Fehlern ist und zu den
gewünschten Ergebnissen führt.3
Es ist überdies möglich, die Vollständigkeit und Konsistenz wissensbasiert modellierter
klinischer Richtlinien mit Hilfe von Entscheidungstabellen zu beweisen. Dabei ist eine
klinische Richtlinie vollständig, wenn für jede Kombination unterschiedlicher Werte der
Parameter eine daraus resultierende Aktion definiert ist. Sie ist konsistent, wenn die Regeln
eindeutig und nicht redundant oder konfliktbehaftet sind. Weiterhin können die Beziehungen
zwischen den einzelnen Aufgaben innerhalb der Modellierung betrachtet werden. Die
logische Korrektheit wird über die Hierarchien der Aufgaben und Unteraufgaben sowie die
unterschiedlichen Aktivierungsbedingungen analysiert. Ein korrektes Verhalten ist es
beispielsweise, wenn bei einer AND-Beziehung eine Aufgabe erst ausgeführt wird, wenn alle
ihre Unteraufgaben erfüllt wurden. Bei einer XOR-Beziehung dagegen wird die Aufgabe
ausgeführt, wenn exakt eine der Unteraufgaben erfüllt wurde. Eine klinische Richtlinie ist
vollständig, wenn für die Aufgaben eindeutige Aktivierungsbedingungen definiert sind, die
zu nur einer möglichen Folgeaufgabe führen können (es sei denn, es wird eine Parallelität
beabsichtigt). Um Kohärenz zu gewährleisten, müssen die Unteraufgaben einander durch die
definierten Aktivierungsbedingungen ausschließen. 4
1 Vgl. [DM01], S. 24
2 Vgl. [PGCR98] S. 161 und vgl. [Pre98], S. 38
3 Vgl. [Pre98] 41 f. und vgl. [PGCR98], S. 162 f.
4 Vgl. [DM01], S. 25
- 32 -
Auf eine Standardmethode zur Verifikation wissensbasierter Systeme - die Erkennung von
Anomalien wie zum Beispiel von Redundanzen, Inkonsistenzen oder fehlendem Wissen - 1
wird im nächsten Kapitel näher eingegangen. Dabei wird – anders als durch Preece und
Shinghal in [PS94] definiert2 – nicht nur der deklarative Anteil des Wissens in einer
Wissensbasis betrachtet, sondern vor allem auch der prozedurale, da sich die Analyse auf die
graphische Modellierung des Wissens aus der Wissensbasis in einem Flussdiagramm bezieht.
1 Vgl. [PS94], S. 2 f.
2 Vgl. [PS94], S. 4
- 33 -
3 Anomalien in der graphischen Modellierung
Die Erkennung von Anomalien in der graphischen Modellierung ist ein wichtiges Instrument
zur Verifikation eines Workflows. Zweck dieses Verfahrens ist die Erkennung von
Anomalien in Prozessmodellen zur Designzeit. Dies spart Kosten, die anfielen, wenn ein
Fehler erst zur Laufzeit entdeckt würde. Prozessunterbrechungen und Bearbeitungszeiten des
Fehlers führen außerdem zur Unzufriedenheit des Anwenders. Durch die Überprüfung des
Prozessablaufes und der einzelnen Aktivitäten können potentielle Probleme im Prozessmodell
frühzeitig erkannt werden.1
Bei der Anomalie-Erkennung können drei Stufen unterschieden werden: Anomalien in einer
einzelnen Komponente, Anomalien innerhalb eines Workflows und Anomalien in der
Hierarchie mehrerer Workflows.2 Dabei handelt es sich bei einer Anomalie selbst nicht um
einen Fehler, sondern zuerst einmal um das Symptom für einen möglichen Fehler.3
Durch intensive Recherchen in klassischer und aktueller Literatur wurde eine Vielzahl von
Anomalien identifiziert, die in diesem Kapitel vorgestellt werden. Die folgende Abbildung
zeigt die grobe Klassifizierung, die für die Anomalien der graphischen Modellierung
vorgenommen wurde. Es wird unterschieden zwischen datenorientierten Anomalien wie
fehlenden Daten, Redundanz, Inkonsistenz, Auffälligkeiten und Anomalien im Kontrollfluss
eines Workflows.
Abbildung 24: Überblick der Anomalieklassen
1 Vgl. [ZB03] S. 207, [SZN05], S. 2917 und [SOSF04], S. 208
2 Vgl. [DM01], S. 29
3 Vgl. [PS94], S. 4
- 34 -
Die Darstellung der Anomalien innerhalb dieses Kapitels erfolgt mit Hilfe von YAWL. In
den Abbildungen werden Startknoten, Endknoten, Aktivitätsknoten, Kontrollknoten und
Knoten, die einen Subprozess modellieren, genutzt.
Abbildung 25: genutzte YAWL Elemente
Startknoten repräsentieren den Beginn eines Workflows, Endknoten das Ende. Bei einer
Aktivität handelt es sich um einen Knoten, der genau eine Eingangs- und eine Ausgangskante
aufweist. Aktivitätsknoten sind atomare Einheiten, die manuell oder automatisch ausgeführt
werden. Das Gleiche gilt für den Subprozessknoten, der eine spezielle Art von Aktivität
repräsentiert und mehrere Aktivitäten hierarchisch kapselt. Ein Kontrollknoten kann dagegen
mehrere Eingangs- und Ausgangskanten haben und ist vom Typ AND, OR oder XOR, der die
Art der Verknüpfung der ein- oder ausgehenden Kanten angibt. Kontrollknoten strukturieren
den Workflow und bauen den Kontrollfluss auf.1
In den nachfolgend mit YAWL modellierten Workflow Netzen sind die an den Anomalien
beteiligten Knoten farblich (orange) hervorgehoben.
3.1 Fehlende Daten
Als fehlende Daten werden Datenelemente bezeichnet, auf die zugegriffen wird, die aber nie
erzeugt oder aber bereits zerstört wurden. Unter einem Zugriff wird das Lesen, Schreiben,
Überwachen oder Löschen des Datums verstanden.2 Es handelt sich außerdem um Elemente,
die für Aktivitäten als Eingabewert definiert sind, deren Quelle allerdings unbekannt oder
unspezifiziert ist. Ein solches Element stammt weder von einer ausführenden Entität einer
1 Vgl. [BZ03], S. 208 und [SOSF04], S. 209
2 Vgl. [TAS09], S. 427 f.
- 35 -
Aktivität (z.B. menschliche Eingabe, maschineller Wert) noch von einer vorangehenden
Aktivität im Fluss. Ein Zugriff findet also vor der Initialisierung des Datenelementes statt.1,2,3
Fehlende Daten werden unterteilt in uninitialisierte Werte, verzögert initialisierte Werte und
unsicher initialisierte Werte.
3.1.1 Uninitialisierter Wert
Es wird auf den Wert eines Datenelementes zugegriffen, bevor er initialisiert wurde. Ein nicht
initialisierter Wert wird beispielsweise als Eingabewert für eine Aktivität im Fluss verwendet
oder als Endergebnis eines Flusses erwartet.4
Abbildung 26: Anomalie - uninitialisierter Wert
Die ersten beiden Aktivitäten des Workflow Netzes initialisieren die Datenelemente a und b.
Die dritte Aktivität berechnet die Summe aus a, b und c. c ist an dieser Stelle nicht
initialisiert.
3.1.2 Verzögerte Initialisierung
Eine Aktivität im Fluss greift auf ein Datenelement zu, dessen Wert erst von einer später
folgenden Aktivität initialisiert wird.5
Abbildung 27: Anomalie - verzögerte Initialisierung
1 Vgl. [TAS09], S. 430
2 Vgl. [SOSF04], S. 212
3 Vgl. [SZN05], S. 2919
4 Vgl. [SZN05], S. 2919
5 Vgl. [SZN05], S. 2919
- 36 -
Der Wert des Datenelementes c wird erst durch die vierte Aktivität initialisiert, aber bereits
durch die dritte Aktivität für eine Berechnung genutzt.
3.1.3 Unsichere Synchronisation
Zwei Aktivitäten laufen parallel ab. Eine der beiden benötigt einen Wert, der durch die andere
initialisiert wird. Beim Zugriff auf diesen Wert kann es sein, dass dieser durch den parallelen
Pfad noch nicht initialisiert wurde.1
Abbildung 28: Anomalie - unsichere Synchronisation
Der obere parallele Pfad der Darstellung initialisiert das Datenelement a, der untere Pfad
initialisiert das Datenelement b. Beide Pfade greifen sowohl auf a als auch auf b zu. In
diesem Moment ist nicht sicher, dass der jeweilige Wert aus dem parallelen Pfad verfügbar
ist.
3.2 Redundanz
Unter Redundanz ist die Eigenschaft von Systemkomponenten zu verstehen, die beschreibt,
dass diese aus dem System entfernt werden können, ohne dass das Systemverhalten
beeinflusst wird.2 Es werden beispielsweise Daten erzeugt, die im weiteren Verlauf eines
Workflows nicht wieder genutzt werden und nicht zum Ergebnis beitragen. Eine solche
Modellierung ist ineffizient.3 (Bei redundanten Daten kann allerdings auch der Fall eintreten,
dass diese möglicherweise bewusst für eine externe Nutzung außerhalb des weiteren
Workflows erzeugt und gespeichert werden.4) Außerdem können redundante Verzweigungen
und Pfade in einer Modellierung vorkommen, indem Regeln für das Betreten eines Pfades
doppelt oder fehlerhaft modelliert sind.5
1 Vgl. [SZN05], S. 2919
2 Vgl. [Pre98], S. 44
3 Vgl. [SZN05], S. 2920
4 Vgl. [SOSF04], S. 211
5 Vgl. [PS94], S. 8 f.
- 37 -
3.2.1 Starke Redundanz
Unter starker Redundanz ist das Schreiben bzw. Erzeugen eines Datenwertes zu verstehen,
der weder vor seiner Zerstörung noch vor Ende des Ablaufes des Workflows jemals wieder
genutzt wird.1 Der erzeugte Wert wird von keiner Aktivität als Eingabe genutzt und stellt
auch nicht die Ausgabe des Workflows dar.2
Abbildung 29: Anomalie - starke Redundanz
Der in der Abbildung gelesene Wert für das Datenelement c wird im weiteren Fluss des
Workflow Netzes nicht verwendet.
3.2.2 Schwache Redundanz
Bei der schwachen Redundanz wird ein erzeugter Datenwert nicht in jedem Fall vor seiner
Zerstörung oder vor Ende des Ablaufes des Workflows genutzt.3 Nur bestimmte
Pfadverzweigungen führen zur Verwendung des Wertes.4
Abbildung 30: Anomalie - schwache Redundanz
1 Vgl. [TAS09], S. 430
2 Vgl. [SZN05], S. 2920
3 Vgl. [TAS09], S. 430 f.
4 Vgl. [SZN05], S. 2920
- 38 -
Der in der Abbildung gelesene Wert für das Datenelement c wird im weiteren Fluss des
Workflow Netzes nur in einem der zwei möglichen Pfade – also nur unter einer bestimmten
Bedingung – verwendet.
3.3 Inkonsistenz
In der Modellierung eines Workflows kommt es zu einem Konflikt, wenn aus gültigen
Eingabedaten widersprüchliche Informationen abgeleitet werden können.1 Inkonsistenzen
dieser Art treten auf, wenn beispielsweise mehrere Aktivitäten mit unterschiedlichen Quellen
für die gleichen Daten arbeiten oder Werte genutzt werden, die bereits durch Ablauf einer
gewissen Zeitspanne vor ihrer Verwendung im Workflow ungültig sind.2 Sie werden aber
auch durch das Überschreiben oder parallele Zugreifen auf Datenelemente verursacht. Liest
eine Aktivität einen Wert aus, während eine andere Aktivität diesen Wert schreibt oder löscht,
kommt es zu inkonsistenten Daten.3
3.3.1 Stark verlorene Daten
Der Wert eines Datenelementes wird in jedem Fall erneut gelesen, bevor er genutzt wird.4
Das Überschreiben eines Datums kann auch als redundante Werteabfrage charakterisiert
werden.
Abbildung 31: Anomalie - stark verlorene Daten
In der Abbildung wird das Datenelement b erneut geschrieben, bevor es in einer Berechnung
verwendet wird.
3.3.2 Schwach verlorene Daten
Der Wert eines Datenelementes wird erneut gelesen, bevor er genutzt wird. Dies geschieht
allerdings nicht in jedem Fall. Es kann Pfade geben, in denen der Wert nicht überschrieben
und somit nicht verloren geht.1
1 Vgl. [Pre98], S. 44
2 Vgl. [SOSF04], S. 211
3 Vgl. [TAS09], S. 431
4 Vgl. [TAS09], S. 431
- 39 -
3.3.3 Multiple Initialisierung
Führen zwei Aktivitäten einen Schreibvorgang auf einem Datenelement parallel aus, kommt
es ebenfalls zum Verlust von Daten. Eine Aktualisierung geht verloren, das Datum wird
mehrfach initialisiert.2
Abbildung 32: Anomalie - multiple Initialisierung
Das Datenelement a in der Abbildung wird in beiden Pfaden parallel initialisiert. Die
Datenquellen für a könnten außerdem unterschiedlich sein, was ein weiterer Konfliktursprung
ist.
3.4 Kontrollflussanomalien
Bei Kontrollflussanomalien handelt es sich um Anomalien im Prozessablauf. Der
Kontrollfluss kann nicht nur im Konflikt zum Datenfluss stehen, indem notwendige Daten
nicht an der passenden Stelle ermittelt werden, sondern auch Fehlersymptome aufweisen, die
in der Modellierung der Knoten und Kanten begründet sind.3 Bei dieser Art von Anomalien
kann dem Kontrollfluss der sogenannte Prozessgraph zu Grunde gelegt werden. Ein
Prozessgraph repräsentiert die Möglichkeiten, die Ausführungsreihenfolge der Aktivitäten zu
strukturieren. Wie bereits in Kapitel 2.3.3 beschrieben zählen dazu4:
•
Sequenz (Ausführung von Aktivitäten der Reihe nach)
•
AND-Verknüpfung (alle eingehenden bzw. ausgehenden Kanten werden ausgeführt)
•
OR-Verknüpfung (eine oder mehrere eingehenden bzw. ausgehenden Kanten werden
ausgeführt)
1 Vgl. [TAS09], S. 431
2 Vgl. [SZN05], S. 2920
3 Vgl. [SOSF04], S. 6 f.
4 Vgl. [BZ03], S. 208 f.
- 40 -
•
XOR-Verknüpfung (genau eine eingehende bzw. ausgehende Kante wird ausgeführt)
Ein Prozessgraph ist über die folgenden Eigenschaften definiert1:
•
Er besitzt genau einen Startknoten mit einer ausgehenden Kante.
•
Er besitzt genau einen Endknoten mit einer eingehenden Kante.
•
Er besteht aus Aktivitätsknoten, die genau eine eingehende und eine ausgehende Kante
aufweisen.
•
Er besteht aus Kontrollknoten, die eine oder mehrere Eingans- und Ausgangskanten
aufweisen und vom Typ AND, OR oder XOR sind.
•
Er besteht aus gerichteten Kanten zwischen den Knoten.
Existiert eine Möglichkeit, den Prozessgraphen vom Startknoten zum Endknoten zu
durchlaufen, kann von seiner Korrektheit und somit Anomaliefreiheit ausgegangen werden.2
Die nachfolgend beschriebenen Anomalien verletzen zum Teil diese Definition und stellen
somit mögliche Modellierungsfehler dar.
3.4.1 Knoten ohne eingehende oder ausgehende Kanten
Abbildung 33: Anomalie - Knoten ohne eingehende oder ausgehende Kanten
Dem oberen Knoten fehlt eine Ausgangskante, dem unteren Knoten fehlt eine Eingangskante.
Ein solches Verhalten ist nur bei End- bzw. Startknoten erlaubt und somit eine Anomalie.3
1 Vgl. [BZ03], S. 208
2 Vgl. [BZ03], S. 209
3 Vgl. [BZ03], S. 209
- 41 -
3.4.2 Aktivitätsknoten mit mehr als einer Eingangs- oder Ausgangskante
Abbildung 34: Anomalie - Aktivitätsknoten mit mehr als einer Eingangs- oder Ausgangskante1
Der erste hervorgehobene Aktivitätsknoten weist zwei Ausgangskanten auf, der zweite
hervorgehobene Aktivitätsknoten zwei Eingangskanten.2
3.4.3 Kontrollknoten mit nur einer Eingangs- oder Ausgangskante, Unvollständigkeit der
Nachbedingungen
Abbildung 35: Anomalie - Kontrollknoten mit nur einer Eingangs- oder Ausgangskante
Der Kontrollknoten vom Typ OR-Split hat nur eine ausgehende Kante. Für eine korrekte
Modellierung muss mindestens eine zweite Kante ergänzt werden, um auch eine
Unvollständigkeit der Nachbedingungen zu verhindern.3
3.4.4 Sich überschneidende Nachbedingungen
Modellierte Nachbedingungen, die an ausgehenden Kanten eines Knotens anliegen, dürfen
sich nicht überschneiden. Bei einer Überschneidung wäre der nachfolgend zu betretende Pfad
nicht eindeutig bestimmt, was einen Modellierungsfehler darstellt.
1 YAWL unterbindet das Modellieren eines solchen Workflow Netzes, es wurden mehrere Knoten hintereinander versteckt.
2 Vgl. [BZ03], S. 209
3 Vgl. [BZ03], S. 209
- 42 -
3.4.5 Fehlender Start- bzw. Endknoten oder auch mehrere Start- bzw. Endknoten
Abbildung 36: Anomalie - fehlender Endknoten1
In der Abbildung fehlt der Endknoten. Ein offenes Ende ist in einem Workflow Netz nicht
erlaubt. Ebenso wären ein fehlender Startknoten oder auch mehrere Start- oder Endknoten
fehlerhaft. Auch gänzlich unverbundene, unabhängige Pfade – also zwei Prozessgraphen in
einem – sind als fehlerhaft zu betrachten.2
3.4.6 Fehlgerichtete Kanten bei Start- oder Endknoten
Abbildung 37: Anomalie - fehlgerichtete Kanten bei Start- oder Endknoten
Der Startknoten in diesem Workflow Netz besitzt eine Eingangskante, der Endknoten eine
Ausgangskante. Beide Zustände verstoßen gegen die Definition des Prozessgraphen und
stellen Fehler im Kontrollfluss dar. Besitzt ein Startknoten mehrere Ausgangskanten oder ein
Endknoten mehrere Eingangskanten, handelt es sich ebenfalls um einen
Modellierungsfehler.3
3.4.7 Verbindungsloser Knoten
Abbildung 38: Anomalie – verbindungsloser Knoten
1 YAWL unterbindet das Modellieren eines Workflow Netzes ohne Endknoten. Die Darstellung wurde entsprechend
bearbeitet.
2 Vgl. [BZ03], S. 209
3 Vgl. [BZ03], S. 209 f.
- 43 -
Ein verbindungsloser Knoten hat keine eingehenden oder ausgehenden Kanten und befindet
sich nicht auf einem Pfad durch den Fluss.1
3.4.8 Mehrere Kanten zwischen zwei Knoten
Abbildung 39: Anomalie - mehrere Kanten zwischen zwei Knoten2
Im unteren Pfad existieren zwei Kanten, die aus dem selben Knoten ausgehen und in den ORJoin eingehen. Nach der Definition des Prozessgraphen handelt es sich um eine Anomalie,
wenn zwischen zwei Knoten mehrere Kanten modelliert sind.3
3.4.9 Deadlock
Bei der Anomalie des Deadlocks kann zwischen deterministischem und nicht
deterministischem Deadlock unterschieden werden. In beiden Fällen werden in der
Modellierung Kontrollknoten nicht korrekt eingesetzt. 4
Abbildung 40: Anomalie - deterministischer Deadlock
Der deterministische Deadlock besteht aus einem XOR-Split gefolgt von einem AND-Join.
Durch den XOR-Split ist garantiert, dass nur einer der beiden nachfolgenden Pfade betreten
wird, der andere dagegen nie. Somit kann der AND-Join, der die beiden Pfade
1 Vgl. [BZ03], S. 209
2 Yawl unterbindet das Modellieren eines solchen Diagramms, es wurden mehrere Knoten hintereinander versteckt.
3 Vgl. [BZ03], S. 210
4 Vgl. [BZ03], S. 210
- 44 -
zusammenführt, nie wahr werden und den Workflow zu einem Ende bringen. Es gehen
niemals beide Pfade in ihn ein.1
Abbildung 41: nicht-deterministischer Deadlock
Der nicht-deterministische Deadlock ist eine Situation, in der es nicht zwingend, aber unter
Umständen zu einem Deadlock kommt. Er besteht aus einem OR-Split und einem AND-Join.
Der Ablauf eines Workflows kann dazu führen, dass nur ein dem OR-Split folgender Pfad
ausgeführt wird, der andere nicht. In diesem Fall kann der AND-Join die Pfade nicht
zusammenführen und es kommt zu einem Deadlock. Durch den OR-Split können aber auch
beide ihm folgenden Pfade ausgeführt werden. In den AND-Join gehen dann beide Pfade ein
und er kann den Workflow beenden. Es kommt nicht zu einem Deadlock.2
1 Vgl. [BZ03], S. 210
2 Vgl. [BZ03], S. 210
- 45 -
3.4.10 Fehlende Synchronisation
Abbildung 42: Anomalie - deterministische fehlende Synchronisation
Bei der fehlenden Synchronisation werden Aktivitäten unkontrolliert mehrfach ausgeführt.
Auch dies geschieht durch den fehlerhaften Einsatz von Kontrollknoten – in diesem Fall
konkret durch einen deplatzierten XOR-Join – und kann determiniert oder nicht-determiniert
sein. Die Abbildung zeigt eine deterministische fehlende Synchronisation. Durch den ANDSplit zu Beginn werden in jedem Fall beide ausgehenden Pfade durchlaufen. Je nachdem,
wann ein Pfad seine Ausführung beendet, wird der XOR-Join ausgelöst und führt seinen
ausgehenden Pfad aus. Terminiert zunächst der obere und später der untere Pfad, wird der
nachfolgende Pfad des XOR-Join zweifach betreten. 1
Im Falle einer nicht-deterministischen fehlenden Synchronisation würde anstelle des ANDSplits ein OR-Split modelliert sein. Somit könnte es Fälle geben, in denen nur ein Pfad nach
dem OR-Split betreten wird und der XOR-Join so nur einmal die nachfolgenden Aktivitäten
anstößt.2
3.4.11 Schleife
Abbildung 43: Anomalie – Schleife
Bestimmte Ereignisketten in einem Workflow können zu einer Schleife führen. Dabei wird
auch von Zirkularität gesprochen.3 Schleifen können Fehlerquellen darstellen und sind in
einem klassischen Workflow-Netz nicht erlaubt.1
1 Vgl. [BZ03], S. 211
2 Vgl. [BZ03], S. 211
3 Vgl. [Pre98], S.44
- 46 -
3.4.12 Endlosschleife
Abbildung 44: Anomalie - deterministische Endlosschleife
Eine Endlosschleife führt dazu, dass Aktivitäten im Prozessmodell unendlich oft wiederholt
werden und der Workflow so niemals terminiert. In der Modellierung resultiert die
Endlosschleife meist aus der falschen Nutzung eines Splits. Anstelle des XOR-Splits wird der
AND-Split (deterministisch) oder der OR-Split (nicht-deterministisch) verwendet.2
Die Abbildung zeigt eine deterministische Endlosschleife. Durch den AND-Split wird in
jedem Fall der Pfad zurück zum ersten Knoten aktiviert und das bei jedem Durchlauf durch
den modellierten Prozess.
3.4.13 Unnötiger Nicht-Determinismus
Abbildung 45: Anomalie - unnötiger Nicht-Determinismus
Bei dieser Anomalie handelt es sich um die falsche Nutzung eines OR-Joins anstelle eines
XOR- oder AND-Joins. Bei einem OR-Join ist nicht determiniert, wir viele der eingehenden
Pfade aktiviert sein müssen, damit der OR-Join die weitere Ausführung auslöst. Das Warten
auf eingehende Pfade ist unbestimmt. Die Nutzung eines XOR-Joins oder AND-Joins ist an
dieser Stelle effektiver, da im Modell bekannt sein sollte, ob die weitere Ausführung durch
die Aktivierung eines eingehendes Pfades oder aller eingehender Pfade ausgelöst werden
soll.3
1 Vgl. [BZ03], S. 210
2 Vgl. [BZ03], S. 211
3 Vgl. [BZ03], S. 211
- 47 -
Nachdem in diesem Unterkapitel nun die Anomalien, die den Kontrollfluss betreffen,
aufgezeigt wurden, folgen abschließend einige weitere Auffälligkeiten, die in einer
Modellierung auftreten können.
3.5 Auffälligkeiten
Weitere Design-Anomalien, die durch Mangel an Wissen oder eine unpräzise Modellierung
entstehen, sind die sogenannten Auffälligkeiten.1
3.5.1 Unerreichbare Elemente
Ein unerreichbares Element trägt nicht zur Ablaufsteuerung des Prozessflusses oder zum
Ergebnis des Workflows bei.2 Diese Anomalie wurde bereits im Rahmen der
Prozessanomalien als verbindungsloser Knoten erläutert. Sie sei hier nur der Vollständigkeit
halber erwähnt, da sie auch in diese Kategorie eingeordnet werden kann.
3.5.2 Toter Pfad
Abbildung 46: Anomalie - toter Pfad
Bei einem toten Pfad handelt es sich um einen Bereich im Prozessfluss, der nicht betreten
werden kann. Dies kann folgendermaßen geschehen: an einem Knoten werden ausgehende
Kanten mit Bedingungen modelliert. An einem darauffolgenden Knoten wird eine Bedingung
geprüft, die durch das Betreten des Pfades anhand seiner Eingangsbedingung bereits
ausgeschlossen wurde. An dieser Stelle kann der Pfad also nicht weiter durchlaufen werden.
Diese Anomalie kann auch als eine Art Deadlock bezeichnet werden.
Die Abbildung zeigt, dass nach dem Betreten des oberen Pfades (a=1) die Bedingungen der
darauf folgenden Pfade (a>1, a<1) nicht wahr werden können. Der obere Pfad ist somit tot.
Der AND-Join vor dem Endknoten kann außerdem nie auslösen, so dass ein Deadlock
entsteht.
1 Vgl. [BS10], S. 63
2 Vgl. [PS94], S 10
- 48 -
3.5.3 Fehlende Modellierungsschritte
Es kann der Fall eintreten, dass der modellierte Workflow für eine auftretende Situation nicht
durchlaufen werden kann. Die Eingabewerte sind gültig, es existieren allerdings keine Pfade,
die mit diesen Werten umgehen können. Es fehlen also Elemente in der Modellierung, um
alle Möglichkeiten des Ablaufes zu repräsentieren.1
Im nächsten Kapitel werden die identifizierten Anomalien auf die graphische Modellierung
von diagnostischem Wissen mit der Notation DiaFlux übertragen. Während einige Anomalien
in einer Modellierung mit DiaFlux nicht auftreten können, existieren dagegen weitere,
DiaFlux-sprachspezifische Anomalien, die dargestellt werden.
1 Vgl. [Pre98], S. 44
- 49 -
4 Abbildung von Anomalien der graphischen Modellierung
auf die graphische Notation DiaFlux
Um Anomalien in der graphischen Notation DiaFlux zu identifizieren, wurden zunächst die
Sprachspezifika von DiaFlux analysiert. Anschließend wurden praktische Experimente mit
dieser Sprache in einem zu diesem Zweck aufgesetzten KnowWE-Wiki durchgeführt. Jede
analysierte Anomalie, die in DiaFlux modelliert werden kann, wurde im Wiki dargestellt.
Nachfolgend werden die Anomalien anhand von DiaFlux Beispielmodellierungen aufgezeigt
und bewertet. Die beispielhaften Flussdiagramme wurden dabei recht übersichtlich und
weniger komplex gehalten, um eine verständliche, allgemeingültige Aussage treffen zu
können. Die einzelnen Anomalien werden nicht noch einmal erklärt, da sie im vorangegangen
Kapitel ausführlich beschrieben wurden.
Des Weiteren werden in diesem Kapitel Anomalien beschrieben, die speziell durch die
Spracheigenheiten von DiaFlux und die Einbettung in KnowWE auftreten können.
4.1 Fehlende Daten
4.1.1 Uninitialisierter Wert
Nachfolgendes Beispiel zeigt die Nutzung eines uninitialisierten Wertes der Variablen
"Tausend" innerhalb einer Formel. Aus einem gegebenen Gewicht in Gramm soll das
Gewicht in Kilogramm berechnet werden. Zur Berechnung wird die Variable „Tausend“
verwendet. Diese Variable ist allerdings nicht in einem vorhergehenden Ablaufschritt mit
einem Wert initialisiert worden. (Auf der Wiki-Seite wird der Fehler erkannt und angezeigt.
Daher sind die Komponenten des Flussdiagramms in roter Schrift dargestellt. Beim
Abspeichern des Diagramms im Editor erscheint jedoch kein Hinweis auf einen
Modellierungsfehler.)
Abbildung 47: DiaFlux Flussdiagramm – uninitialisierter Wert (1)
Eine weitere Ausprägung dieser Anomalie wäre der Zugriff auf das Gewicht in Gramm,
obwohl der Wert dieser Variable nicht bekannt ist. Dies zeigt die nächste Abbildung.
- 50 -
Abbildung 48: DiaFlux Flussdiagramm – uninitialisierter Wert (2)
Es kann außerdem vorkommen, dass in einem Flussdiagramm eine Variable genutzt werden
soll, die durch eine Regel mit einem Wert initialisiert wird. Wird diese Regel nicht
angestoßen, ist die Variable im Flussdiagramm nicht initialisiert.
Bewertung: Die Anomalie des uninitialisierten Wertes kann auf DiaFlux übertragen werden.
Es ist möglich, einen Zugriff auf unbekannte Werte zu modellieren.
4.1.2 Verzögerte Initialisierung
In der folgenden Abbildung wird auf den Wert der Variable „GewichtInGramm“ zugegriffen,
obwohl diese erst zu einem späteren Zeitpunkt initialisiert wird.
Abbildung 49: DiaFlux Flussdiagramm – verzögerte Initialisierung
Bewertung: Die Anomalie der verzögerten Initialisierung kann auf DiaFlux übertragen
werden. Es ist möglich, einen Zugriff auf zu einem späteren Zeitpunkt initialisierte Werte zu
modellieren.
4.1.3 Unsichere Synchronisation
Die Anomalie der unsicheren Synchronisation kann sehr gut am Beispiel des
Interdependenzproblems in der innerbetrieblichen Leistungsverrechnung (ibLV) im
Controlling demonstriert werden. Eine Hilfskostenstelle kann ihre Leistungen nicht
kalkulieren, bevor sie weiß, mit welchem Betrag sie von anderen Hilfskostenstellen belastet
wird, deren Leistungen sie selbst in Anspruch nimmt. Die anderen Hilfskostenstellen können
ihre Leistungen aber auch erst abrechnen, wenn sie den Betrag kennen, der ihnen von anderen
Hilfskostenstellen angelastet wird (z.B.: die Reparaturwerkstatt benötigt Strom, die
Stromstelle benötigt Reparaturen).1 Im folgenden Flussdiagramm greifen die Kostenstellen
1 Vgl. [Hab02], S. 125
- 51 -
K1 und K2 parallel auf ihre gegenseitigen Kostenbeträge zu. Dabei kann es vorkommen, dass
der jeweilige Kostenbetrag der anderen Kostenstelle noch nicht initialisiert wurde.
Abbildung 50: DiaFlux Flussdiagramm – unsichere Synchronisation
Bewertung: Die Anomalie der unsicheren Synchronisation kann auf DiaFlux übertragen
werden. Es ist möglich, einen parallelen Zugriff auf möglicherweise unbekannte Werte zu
modellieren.
4.2 Redundanz
4.2.1 Starke Redundanz
In diesem Beispiel geht es um die Berechnung des Body Mass Index (BMI). Der BMI ist eine
Maßzahl zur Bewertung des Gewichtes eines Menschen bezüglich der Körpergröße und
berechnet sich aus dem Gewicht in Kilogramm dividiert durch das Quadrat der Körpergröße
in Metern.1 Anhand des berechneten Wertes ergibt sich eine der Bewertungen
„Untergewicht“, „Normalgewicht“ oder „Übergewicht“. Im folgenden Flussdiagramm wurde
diese Berechung umgesetzt. Es wird allerdings zusätzlich der Wert des Geschlechtes
abgefragt. Dieser wird im weiteren Verlauf des Flusses weder für die Berechnung noch für
die Bewertung verwendet und ist somit stark redundant.
Abbildung 51: DiaFlux Flussdiagramm – starke Redundanz
1 Vgl. https://www.uni-hohenheim.de/wwwin140/info/interaktives/bmi.htm, 20.03.2011, 13:42 Uhr
- 52 -
Eine weitere Form der starken Redundanz wäre, wenn ein Wert in zwei Knoten durch eine
Formel berechnet würde, ohne dass andere Elemente auf dem Pfad zwischen diesen Knoten
die Berechnung beeinflussen. Eine erneute Berechung wäre in diesem Fall also überflüssig.
Bewertung: Die Anomalie der starken Redundanz kann auf DiaFlux übertragen werden.
Elemente, die im weiteren Verlauf nicht verwendet werden, können ohne Weiteres modelliert
werden.
4.2.2 Schwache Redundanz
Das eben vorgestellte Beispiel der BMI-Berechnung wurde erweitert um die Auswertung des
Geschlechtes im Falle der Herleitung von Übergewicht. Bestätigt der Anwender die
Herleitungen „Untergewicht“ oder „Normalgewicht“ wird der Fluss weiterhin beendet und
das abgefragte Geschlecht nicht verwendet. Wird aber die Herleitung „Übergewicht“
bestätigt, wird über das Geschlecht eine genauere Auswertung vorgenommen, da bei einer
weiblichen Person, die schwanger ist, nicht von Übergewicht gesprochen werden kann. In
diesem einen Pfad wird die Variable „Geschlecht“ also verwendet.
Abbildung 52: DiaFlux Flussdiagramm – schwache Redundanz
Bewertung: Die Anomalie der schwachen Redundanz kann auf DiaFlux übertragen werden.
Elemente, die im weiteren Verlauf nur in bestimmten Pfaden verwendet werden, können
durchaus modelliert werden.
4.3 Inkonsistenz
4.3.1 Stark verlorene Daten
Wird im Beispiel der BMI-Berechung das Gewicht zweifach hintereinander abgefragt, wird
der erste Wert in jedem Fall überschrieben und geht somit verloren. Wären die Testknoten
- 53 -
allerdings vom Typ ask, wäre der zweite Knoten redundant, da keine erneute Abfrage eines
bereits bekannten Wertes ausgelöst würde.
Abbildung 53: DiaFlux Flussdiagramm – stark verlorene Daten
Bewertung: Die Anomalie der stark verlorenen Daten kann auf DiaFlux übertragen werden.
Werte von Variablen können überschrieben werden, bevor sie genutzt wurden und gehen
somit verloren.
4.3.2 Schwach verlorene Daten
Wie bereits im Beispiel der schwachen Redundanz in Abbildung 51 betrachtet, kann der
Zugriff auf die Variable „Gender“ stattdessen durch eine erneute Abfrage durch einen
Testknoten der Art always ask ersetzt werden. In diesem Pfad würde der Wert also
überschrieben und das erste Abfrage-Ergebnis ginge verloren. Für eine passende
Modellierung dieser Anomalie sei angenommen, dass das Geschlecht in einem anderen Pfad
genutzt würde, ohne es zu überschreiben.
Bewertung: Die Anomalie der schwach verlorenen Daten kann auf DiaFlux übertragen
werden. Werte von Variablen können in einigen Pfaden überschrieben werden, bevor sie
genutzt wurden und könnten verloren gehen.
4.3.3 Multiple Initialisierung
Die Anomalie der multiplen Initialisierung wird am Beispiel der Bestimmung der
Sauerstoffsättigung in nachfolgendem Flussdiagramm deutlich. Die Sauerstoffsättigung sO2
wird durch die Blutgasanalyse (BGA) und einen nicht-invasiven Sensor (Pulsoxymeter)
bestimmt. Dabei wird ein und derselbe Parameter sO2 parallel initialisiert anstellte der
Nutzung zweier unterscheidbarer Parameter wie z.B. der arteriellen Sauerstoffsättigung SaO2
- 54 -
aus der BGA und der partiellen Sauerstoffsättigung SpO2 ermittelt durch den Sensor.1 In der
weiteren Auswertung der Sauerstoffsättigung ist nun unklar, welcher Wert genutzt wird, da er
zweifach initialisiert wurde. Eine Initialisierung geht dabei verloren.
Abbildung 54: DiaFlux Flussdiagramm – multiple Initialisierung
Bewertung: Die Anomalie der multiplen Initialisierung kann auf DiaFlux übertragen werden.
Variablen können in parallelen Pfaden mehrfach initialisiert werden.
1 Vgl. http://www.netdoktor.de/Diagnostik+Behandlungen/Laborwerte/Blutsauerstoff-und-Sauerstoffs-1070.html,
20.03.2011, 15:02 Uhr
- 55 -
4.4 Prozessanomalien
Prozessanomalien basieren hauptsächlich auf der falschen Nutzung von Aktivitäts- oder
Kontrollknoten. Daher ist zunächst zu definieren, wie diese Knoten in DiaFlux dargestellt
werden können.
Die Testknoten in DiaFlux können sowohl Aktivitäten als auch Kontrollstrukturen darstellen,
je nachdem, ob sie zur Abfrage von Werten mit anschließender Auswertung durch
ausgehende Kanten oder als konstante Handlungsanweisungen modelliert werden. Die bereits
bekannten Kontrollknoten können nur zum Teil implizit genutzt werden.
4.4.1 Splits in DiaFlux
•
XOR-Split: kann in Form einer One-Choice-Frage ([oc]), also einer Frage mit nur einer
Antwortmöglichkeit, dargestellt werden.
•
OR-Split: kann in Form einer Multiple-Choice-Frage ([mc]), also einer Frage mehreren
Antwortmöglichkeiten, dargestellt werden.
•
AND-Split: kann in Form einer Multiple-Choice-Frage ([mc]), also einer Frage mehreren
Antwortmöglichkeiten, dargestellt werden. Dabei müsste jede Antwortmöglichkeit
ausgewählt werden. Dies kann nur durch ein Hilfskonstrukt erreicht werden. Die
nachfolgende Abbildung zeigt ein Beispiel für die Realisierung eines AND-Splits mit
DiaFlux.
Abbildung 55: AND-Split in DiaFlux
Ein Hilfswert „CheckVal“ wird mit Null initialisiert. Bei der Auswahl einer
Antwortalternative der Multiple Choice Frage „MCQ“ wird dieser Wert um Eins
inkrementiert. Anschließend wird überprüft, ob der Wert von „CheckVal“ der Anzahl der
möglichen Antworten von „MCQ“ entspricht. Nur in diesem Fall wird die Durchführung
des Flusses fortgesetzt.
- 56 -
4.4.2 Joins in DiaFlux
Ein Knoten in DiaFlux führt zur weiteren Abarbeitung des Diagrammflusses, wenn eine
Eingangskante wahr wird. Knoten mit mehreren Einganskanten können also als OR-Join oder
XOR-Join betrachtet werden, wobei im Kontext von DiaFlux die Bezeichnung Support zur
Anwendung kommt. Ein wahrer, eingehender Pfad gibt dem Knoten Support. Hat ein Knoten
Support, wird er ausgelöst. Sind mehrere eingehende Kanten wahr, verstärkt sich der Support.
Dies ist vor Allem bei der Herleitung von Lösungen und ihren Wahrscheinlichkeiten
interessant, resultiert aber nicht in einer erneuten Ausführung einer Aktivität.
Explizite AND- und XOR-Joins können nur mit einem Hilfskonstrukt modelliert werden.
Abbildung 56: Joins in DiaFlux
Ein Hilfswert „CheckVal“ wird mit Null initialisiert. Anschließend werden zwei Fragen „A“
und „B“ gestellt und deren Antworten ausgewertet. Im Falle der gewünschten Antwort wird
der Hilfswert inkrementiert. In einer Zusammenführung (Join) wird der Hilfswert
„CheckVal“ überprüft. Die aus dieser Überprüfung folgende Ausgangsbedingung bestimmt
die Kategorie des Joins.
•
AND-Join: der Wert von „CheckVal“ entspricht der Anzahl der Eingangskanten.
•
XOR-Join: der Wert von „CheckVal“ ist genau Eins.
•
OR-Join: der Wert von „CheckVal“ ist Eins oder größer.
Nachdem die Modellierung von Split- und Join-Kontrollstrukturen gezeigt wurde, sollen nun
anhand eines komplexen Beispieldiagramms die Prozessanomalien analysiert werden.
- 57 -
Nachfolgend ist ein Beispielflussdiagramm modelliert, welches verschiedene
Prozessanomalien beinhaltet. Das Diagramm beschreibt den Umgang mit einem ungnädigen
Baby und hilft, die Ursache für sein missmutiges Verhalten zu finden. (Ein korrektes
Diagramm dieser Art befindet sich im Anhang 10.1.)
Abbildung 57: DiaFlux Flussdiagramm – Darstellung verschiedener Prozessanomalien
- 58 -
4.4.3 Knoten ohne eingehende oder ausgehende Kanten
Der Knoten „Bauchweh“ weist keine eingehenden Kanten auf.
Bewertung: Die Anomalie der Knoten ohne eingehende oder ausgehende Kanten kann auf
DiaFlux übertragen werden. Eine Modellierung solcher Knoten ist möglich.
4.4.4 Aktivitätsknoten mit mehr als einer Eingangs- oder Ausgangskante
Da Aktivitäts- und Kontrollknoten in DiaFlux nicht explizit unterschieden werden, ist es
prinzipiell nicht fehlerhaft, Knoten mit mehreren Eingangs- oder Ausgangskanten zu
modellieren. Der Diagnoseknoten „Volle Windel“ kann als Aktivitätsknoten betrachtet
werden und hat zwei eingehende Kanten, die korrekt modelliert wurden. Allerdings kann
auch das Gegenbeispiel modelliert werden: ein Warteknoten sollte niemals mehrere
Eingangs- oder Ausgangskanten aufweisen.
Bewertung: Die Anomalie der Aktivitätsknoten mit mehr als einer Eingangs- oder
Ausgangskante kann auf DiaFlux eingeschränkt übertragen werden. Eine Modellierung
solcher Knoten ist möglich, aber nicht zwingend ein Fehlersymptom.
4.4.5 Kontrollknoten mit nur einer Eingangs- oder Ausgangskante, Unvollständigkeit der
Nachbedingungen
Der Knoten „Zahnt es“ hat nur eine ausgehende Kante für den Wert „weiß nicht“. Als
Kontrollknoten muss er in diesem Beispiel mehrere Ausgangskanten aufweisen. Somit ist
zugleich die Anomalie der Unvollständigkeit der Nachbedingungen aufgezeigt.
Bewertung: Auch diese Anomalien können auf DiaFlux übertragen werden. Eine
Modellierung solcher Knoten ist möglich. Die Unvollständigkeit der Nachbedingungen wird
nicht geprüft, so dass einige Pfade möglicherweise nicht betreten werden können und die
Ausführung des Flusses zum Stehen kommt.
4.4.6 Sich überschneidende Nachbedingungen
Den ausgehenden Kanten des Knotens „Letztes Nickerchen“ sind die Bereiche „>3“ und „<4“
zugewiesen. Liegt das letzte Nickerchen des Babys 3,5 Stunden zurück, überschneiden sich
die Bereiche und der zu betretende Pfad ist nicht eindeutig definiert.
Bewertung: Die Überschneidungsfreiheit der Nachbedingungen ist in DiaFlux nicht
gewährleistet, da keine Überprüfung der Bedingungen an ausgehenden Kanten stattfindet. Die
Anomalie kann also abgebildet werden.
- 59 -
4.4.7 Fehlender Start- bzw. Endknoten oder auch mehrere Start- bzw. Endknoten
Im dargestellten Diagramm existieren zwei Startknoten (in unverbundenen Pfaden) – es
existiert ein zweites, unabhängiges Diagramm im unteren linken Bereich. Außerdem ist der
Pfad um den Knoten „Bauchweh?“ nicht mit dem restlichen Diagramm verbunden. Es wäre
auch möglich, sämtliche Start- und Endknoten aus dem Diagramm zu entfernen, ohne das ein
Modellierungsfehler angezeigt würde.
Bewertung: Fehlende oder mehrere Start- und Endknoten können in DiaFlux modelliert
werden. Startknoten sind für den Ablauf eines Flussdiagramms allerdings unabdinglich, da
ein Flussdiagramm nur ausgeführt werden kann, wenn ein Eintrittspunkt durch einen
Starknoten gegeben ist. Endknoten sind in DiaFlux ebenfalls erforderlich. Ein
Flussdiagramm, das ein weiteres Diagramm aufruft, wartet, bis dieses seinen Endknoten
erreicht, um mit seiner Ausführung fortzufahren. Fehlt der Endknoten, ist eine Fortsetzung
des Flusses nicht möglich. Mehrere Start- und Endknoten ermöglichen den Einstieg in
unterschiedliche Pfade des Diagramms oder unterschiedliche Endzustände und sind daher
eine gewollte Modellierungseigenschaft. Eine Modellierung mehrerer Flussdiagramme in
einem ist technisch möglich, sollte allerdings der Übersichtlichkeit halber vermieden werden.
4.4.8 Fehlgerichtete Kanten bei Start- oder Endknoten
Das Beispiel zeigt mehrere Ausgangskanten und eine Eingangskante im oberen Startknoten.
Außerdem existieren Ausgangskanten an einigen Endknoten.
Bewertung: Fehlgerichtete Kanten bei Start- oder Endknoten können in DiaFlux modelliert
werden. Mehrere Ausgangskanten eines Startknotens stellen nicht unbedingt eine Anomalie
dar, denn es kann auch die Modellierung paralleler Pfade beabsichtigt sein. Mehrere
Eingänge aus unterschiedlichen Diagrammen zu einem Startknoten des aktuellen Diagramms
sind ebenfalls erlaubt. Die Rückkehr zum Startknoten im Diagramm selbst ist allerdings eine
fehlerhafte Modellierung, auf die bereits durch DiaFlux hingewiesen wird. Auch ausgehende
Kanten aus Endknoten sind fehlerhaft und werden markiert. Mehrere Eingangskanten in einen
Endknoten sind dagegen gestattet, denn mehrere Pfade können zu einem Endergebnis führen.
4.4.9 Verbindungsloser Knoten
Der Knoten „Riecht es?“ ist ein weiteres Mal in das Diagramm geraten, ohne eine
Verbindung zu anderen Knoten auszuweisen.
Bewertung: Die Anomalie der verbindungslosen Knoten kann auf DiaFlux übertragen
werden. Knoten können ohne Kanten im Diagramm platziert werden.
4.4.10 Mehrere Kanten zwischen zwei Knoten
Zwischen den Knoten „Maulig und ungehalten?“ und „Letzte Fütterung“ existieren zwei
Kanten.
- 60 -
Bewertung: Mehrere Kanten zwischen zwei Knoten sind in DiaFlux ohne Weiteres
modellierbar. Es handelt sich nur dann um ein Fehlersymptom, wenn beide Kanten in
dieselbe Richtung verlaufen.
Die nachfolgenden Anomalien fallen ebenfalls in die Klasse der Prozessanomalien, verstoßen
allerdings nicht gegen die vormals diskutierte Definition des Prozessmodells, sondern
beschreiben die falsche Nutzung von Kontrollknoten. Zur Illustration dieser Anomalien
wurden gesonderte Beispiele gewählt.
4.4.11 Deadlock
Abbildung 58: DiaFlux Flussdiagramm – deterministischer Deadlock
Die Abbildung zeigt ein Diagramm zur Bestimmung der durchschnittlichen
Sauerstoffsättigung (sO2), in dem zuerst gefragt wird, ob ein Blutgas-Analyse-Gerät zur
Verfügung steht. Ist das der Fall, wird die Sauerstoffsättigung von diesem Gerät erfragt
(SaO2), andernfalls durch ein Pulsoxymeter (SpO2). Nur, wenn beide Werte bekannt sind,
wird daraus die durchschnittliche Sauerstoffsättigung errechnet. Da es sich bei der Frage nach
dem Vorhandensein eines BGA-Gerätes um einen XOR-Split handelt und somit nur einer der
nachfolgenden Pfade betreten werden kann, sind niemals beide Parameter SaO2 und SpO2
bekannt und der folgende Knoten (AND-Join) kann die Berechnung des sO2 nie durchführen.
Es entsteht ein deterministische Deadlock. Eine mögliche Auflösung kann erreicht werden,
indem die Frage nach dem BGA-Gerät losgelöst von der Bestimmung des Wertes durch das
Pulsoxymeter modelliert wird. Ist eines der Geräte nicht vorhanden, könnte der Fluss ohne
die Berechnung der durchschnittlichen Sauerstoffsättigung beendet werden.
Bewertung: Sowohl deterministische als auch nicht-deterministische Deadlocks können mit
DiaFlux durch die ungeeignete Platzierung einer One-Choice- Frage und damit fehlende
Werte modelliert werden.
- 61 -
4.4.12 Fehlende Synchronisation
Abbildung 59: DiaFlux Flussdiagramm - nicht-deterministische fehlende Synchronisation
Das Diagramm in der Abbildung erfragt, worauf der Anwender Hunger hat, um anschließend
seine konkreteren Vorlieben zu ermitteln und den entsprechenden Anbieter anzurufen, um
Essen zu bestellen oder einen Tisch im Restaurant zu reservieren. Der Kontrollknoten mit der
Multiple-Choice-Frage „Worauf haben Sie Hunger?“ ist ein OR-Split: ein oder mehrere
Antworten sind möglich. Dadurch können die unterschiedlichen, ausgehenden Pfade
durchlaufen werden, was dazu führt, dass „Nummer wählen“ mehrfach angestoßen wird.
Diese nicht-deterministische, fehlende Synchronisation kann aufgelöst werden, indem der
Knoten „Worauf haben Sie Hunger?“ in eine One-Choice-Frage – also einen XOR-Split –
umgewandelt wird.
Bewertung: Der zuerst betretene und somit zuerst eingehende Pfad wird den Knoten
„Nummer wählen“ aktivieren. Die danach eintreffenden Pfade würden nur den Support des
Knoten verstärken. Die Anomalie ist also nicht übertragbar, da eine mehrfache Ausführung
eines Knotens ausgeschlossen ist.
4.4.13 Schleife / Endlosschleife
Abbildung 60: DiaFlux Flussdiagramm - Schleife / Endlosschleife
- 62 -
Das dargestellte Diagramm soll die Steuerung der Temperatur durch Kühlung modellieren. Ist
die Temperatur mehr als 50°C hoch, wird die Kühlung verstärkt. Ist die Temperatur kleiner
oder gleich 50°C, wird die Kühlung dagegen verringert. Das Ziel und somit das Ende des
Flusses ist bei einer Temperatur von 50°C erreicht. Eine Temperatur ungleich 50°C führt zu
einem geregelten Schleifenablauf. Der Snapshot-Knoten in Kombination mit der
wiederholten Frage nach der Temperatur durch die Eigenschaft always ask des Knoten
„Temp“ sorgen dafür, dass die Temperatur zurück gesetzt und erneut ermittelt wird. Eine
Temperatur von genau 50°C führt aufgrund der fehlerhaften Modellierung der
Nachbedingung zur Verringerung der Kühlung zu einem nicht vorhersagbaren Verhalten des
TMS, da nicht nur das Flussende, sondern auch die erneute Temperaturmessung ausgelöst
wird. Dies wird durch die grüne Hervorhebung in der Abbildung deutlich, die die
Ausführungsschritte des Flussdiagramms markiert.
Bewertung: Die Modellierung von Schleifen in DiaFlux ist möglich und gewollt, so dass es
sich hierbei nicht um eine Anomalie im Sinne eines Fehlers handelt. Fehlerhafte
Endlosschleifen sind natürlich zu vermeiden.
4.4.14 Unnötiger Nicht-Determinismus
Während man bei einer fehlenden Synchronisation von einer ungewollten
Mehrfachausführung eines Knotens ausgeht, bedeutet ein unnötiger Nicht-Determinismus,
dass ein OR-Join nicht weiß, ob er noch auf eingehende Kanten warten oder die weitere
Ausführung anstoßen soll. In DiaFlux ist es möglich, einen OR-Join zu modellieren, indem
eine Multiple-Choice-Frage gestellt und ausgewertet wird. Abbildung 59 zeigt diese
Anomalie.
Bewertung: Diese Anomalie ist nur eingeschränkt auf DiaFlux übertragbar, da ein Knoten mit
mehreren eingehenden Kanten nicht wartet, sondern bereits nach der ersten wahr werdenden
Kante aktiviert wird. Dabei ist jedoch nicht determiniert, welcher Pfad zuerst wahr wird.
- 63 -
4.5 Auffälligkeiten
Neben den verwaisten Knoten, die unerreichbar und nicht in das Prozessmodell integriert sind
und die bereits im Unterkapitel der Prozessanomalien näher erläutert wurden, gehören auch
der tote Pfad und die fehlenden Modellierungsschritte in diese Kategorie.
4.5.1 Toter Pfad
Abbildung 61: DiaFlux Flussdiagramm - toter Pfad
Die Darstellung zeigt einen toten Pfad zum Endknoten „Exit2“. Dieser Pfad wird betreten,
wenn „B“ einen Wert kleiner oder gleich 1 aufweist. Später wird der Pfad aber nur dann
weiter ausgeführt, wenn „B“ größer ist als 2. Da „B“ sich zwischendurch nicht verändert hat,
kann „B“ nicht größer als 2 sein und der Pfad endet an dieser Stelle.
Bewertung: Die Modellierung eines toten Pfades in DiaFlux kann vorkommen. Sie verhindert
die weitere Ausführung des Flussdiagramms und kann möglicherweise zu einem Deadlock
führen.
4.5.2 Fehlende Modellierungsschritte
Natürlich kann es auch in DiaFlux vorkommen, dass der Designer eines Workflows nicht
alles bedenkt und somit Schritte in der Modellierung vergisst, die nötig wären, um alle
möglichen Eingabeparameter abzudecken.
Bewertung: Im Fall von fehlenden Modellierungsschritten kann es in DiaFlux zu Deadlocks
kommen. Fehlt beispielsweise an einem Kontrollknoten eine Kante mit einer Bedingung für
einen möglichen Eingabewert, kann der Fluss an dieser Stelle möglicherweise nicht
fortgesetzt werden und kommt zum Stillstand. Die Anomalie ist also uneingeschränkt
übertragbar.
4.6 DiaFlux-spezifische Anomalien
In diesem Kapitel werden weitere Anomalien aufgeführt, die speziell in der Notation DiaFlux
zu finden sind.
- 64 -
4.6.1 Redundantes Flussdiagramm
DiaFlux-Flussdiagramme können als Komponenten in einem anderen Flussdiagramm
wiederverwendet werden. Wird ein Flussdiagramm nicht durch ein anderes oder durch einen
automatischen Start aufgerufen, so ist es redundant.
4.6.2 Redundanter Startknoten
Ein Startknoten in einem DiaFlux-Flussdiagramm kann als redundant bezeichnet werden,
wenn er weder durch einen automatischen Start des Diagramms noch durch den Aufruf aus
einem anderen Diagramm heraus aufgerufen wird.
Abbildung 62: DiaFlux Flussdiagramm - Redundanter Startknoten
Das erste Diagramm ruft das zweite Diagramm auf, falls die Frage nach „Hunger“ mit „ja“
beantwortet wurde. Als Eintrittspunkt in das zweite Diagramm ist „Start2“ angegeben. Da das
zweite Diagramm nicht automatisch startet und kein weiteres Diagramm es aufruft, ist der
Startknoten „Start“ (und auch der daraus resultierende Pfad) redundant.
- 65 -
4.6.3 Redundante Abfrage
In DiaFlux ist es möglich, Werte ein einziges Mal (ask) oder aber jedes Mal erneut (always
ask) abzufragen. Bei Werten, die in der Regel konstant bleiben, wird die erste Variante
verwendet, bei Werten, die sich oft ändern, die zweite. Beispiele hierfür wären die Ermittlung
des Geschlechtes (ask) sowie die Abfrage eines Sensorwertes (always ask).
Wird durch Testknoten ein Wert zweimal hintereinander abgefragt und dabei die Methode
ask genutzt, ist die zweite Abfrage redundant, da der Wert bereits bekannt ist und nicht erneut
zugewiesen wird.
4.6.4 Inkonsistente Abfrageart
Wird derselbe Wert zweimal mit den unterschiedlichen Abfragearten ask und always ask
innerhalb eines Diagramms ermittelt, kann es sich um eine fehlerhafte Modellierung handeln.
4.6.5 Inkonsistente Herleitung
Durch den Prozessfluss in einem DiaFlux-Flussdiagramm werden unterschiedliche Diagnosen
bestätigt oder verworfen. Eine Diagnose, die einmal verworfen wurde, darf anschließend
nicht mehr etabliert werden, denn es gab offensichtlich Faktoren, die bereits zu ihrer
Ablehnung führten. (Andersherum ist es allerdings möglich, Diagnosen, die bisher als
bestätigt angenommen wurden, zu verwerfen, wenn neue Aspekte in Betracht gezogen
werden, die zu ihrer Ablehnung führen.)
4.6.6 Schleife ohne Snapshot-Knoten
Wie bereits in Kapitel 2.2.2 beschrieben, tragen Snapshot-Knoten dazu bei, den
Ausführungsstatus eines DiaFlux-Flussdiagrammes zu speichern, so dass vorhergehende
Entscheidungen nicht mehr durch Truth Maintenance rückgängig gemacht werden können,
aber alle vorhergehenden, aktivierten Knoten deaktiviert werden, um ihre erneute Ausführung
zu ermöglichen. Wird eine Schleife ohne einen Snapshot-Knoten modelliert, kann die zweite
Iteration nicht durchgeführt werden, da die Knoten des Pfades bereits durchlaufen und
aktiviert wurden. Eine erneute Aktivierung bereits ausgelöster Knoten ist nicht möglich.
- 66 -
Abbildung 63: DiaFlux Flussdiagramm - Schleife ohne Snapshot-Knoten
Die Abfrage der Temperatur „Temp“ möge einen Wert größer als 50°C ergeben. Die Kühlung
würde somit verstärkt werden. Wäre die Temperatur danach noch immer größer als 50°C,
würde der Knoten zum Verstärken der Kühlung nicht erneut aktiviert werden, da ein
Snapshot-Knoten fehlt, der ihn zuvor deaktiviert hat.
4.6.7 Kein automatisch startendes Flussdiagramm
Damit ein DiaFlux-Flussdiagramm überhaupt ausgeführt werden kann, muss es als
automatisch startend markiert (siehe Abbildung Checkbox „Autostart“) oder von einem
anderen Flussdiagramm aufgerufen werden. Ist in der gesamten Modellierung eines
Sachverhaltes kein einziges automatisch startendes Flussdiagramm vorhanden, kann keines
der Diagramme durchlaufen und somit keine Aktion ausgeführt oder Diagnose hergeleitet
werden. Damit verlieren die Diagramme ihre Funktion.
Abbildung 64: DiaFlux Editor - automatischer Start eines Diagramms
4.6.8 Automatisch startendes Flussdiagramm mit mehr als einem Startknoten
Prinzipiell ist es möglich und nicht fehlerhaft, wenn ein DiaFlux-Flussdiagramm mehrere
Startknoten als Eintrittspunkte aufweist. Dies darf aber nur dann der Fall sein, wenn dieses
Diagramm nicht automatisch startet, sondern die einzelnen Startknoten von anderen
Diagrammen aus aufgerufen werden. Hat ein automatisch startendes Flussdiagramm mehrere
- 67 -
Startknoten, werden alle ausgehenden Pfade betreten und parallel ausgeführt, was in der
Regel nicht Sinn und Zweck der Modellierung sein wird.
4.6.9 Rückkopplung
Werte innerhalb einer Wissensbasis können nicht nur durch Regeln, sondern auch durch
Knoten in einem DiaFlux-Flussdiagramm manipuliert werden. Während Regeln ausgeführt
werden, sobald sich ein Wert ändert, finden Änderungen durch Knoten nur im Moment des
Flussablaufes statt. Ein Knoten kann z.B. durch eine zugrunde liegende Formel einen Wert
ändern. Wird nun ständig ein Wert auf beide Arten angepasst, kann es zu einer unerwünscht
hohen Zahl von Propagierungen des Wertes bis hin zu einer Endlosschleife und dem
flussunabhängigen Überschreiben des Wertes kommen.
4.6.10 Unmöglicher Pfad
Bei einem unmöglichen Pfad handelt es sich um eine TM-Anomalie. Ändert sich ein Wert in
der Wissensbasis, werden alle Aktivierungszustände der Knoten der dazugehörigen
Flussdiagramme entsprechend dem neuen Wert angepasst. Widerspricht der neue Wert einer
zuvor gültigen Kantenbedingung, wird der Prozessfluss bis zu der Stelle des Widerspruchs
rückgängig gemacht. Der Pfad, der den Wert geändert hat, kann unmöglich betreten werden.
Die nachfolgende Darstellung visualisiert diesen Sachverhalt.
Abbildung 65: DiaFlux Flussdiagramm - unmöglicher Pfad
Es wird zuerst eine Frage gestellt, die mit „Ja“ oder „Nein“ beantwortet werden kann. Ist die
Antwort „Ja“, wird das Flussdiagramm über „Exit1“ verlassen. Ist die Antwort „Nein“, setzt
der darauffolgende Knoten den Antwortwert zurück auf „Ja“. Dieses Verhalten ist
inkonsistent. Durch das Setzen dieses neuen Wertes wird die Änderung im Blackboard
propagiert und durch das TMS verarbeitet. Das TMS macht alles bis zur ersten Frage
rückgängig, da aufgrund des Antwortwertes „Ja“ nur der Pfad zu „Exit1“ betreten werden
kann. Der Pfad zu „Exit2“ kann daher unmöglich betreten werden.
- 68 -
4.6.11 Unbenutzte Elemente der Wissensbasis
Im Rahmen der unbenutzten Elemente können zwei Vorkommen unterschieden werden:
•
Bestimmte Elemente der Wissensbasis werden in keinem dazugehörigen Diagramm
verwendet.
•
Einzelne Unterelemente (Diagnosen, Antworten/Verzweigungsoptionen) werden nicht
hergeleitet bzw. werden nicht in der weiteren Verarbeitung ausgewertet.
In der Abbildung wird die Berechnung des BMI erneut dargestellt.
Abbildung 66: DiaFlux Flussdiagramm - BMI-Berechung
Quelle: KnowWE Demo Body-Mass-Index mitgeliefert in der Wiki-Installation
Dem Diagramm liegen die folgenden Werteabfragen und Herleitungen (Diagnosen) zu
Grunde:
Abbildung 67: Teil einer Wissensbasis zur BMI-Berechnung
- 69 -
Aus der Darstellung wird deutlich, dass die One-Choice-Fragen nach dem Geschlecht
„Gender“ und einer Schwangerschaft „Pregnant“ in keinem Fall verwendet werden, die
Diagnose Heavy Overweight, die Bestandteil des Elementes „Weight Assessment“ ist, wird
nicht hergeleitet.
Bewertung: Es ist möglich, DiaFlux-Diagramme zu modellieren, die nicht den gesamten
Umfang der zu Grunde liegenden Wissensbasis nutzen. Auf einen solchen Umstand sollte
zumindest hingewiesen werden, wenngleich er im Einzelfall gewollt ist und es sich nicht um
einen Fehler handeln muss.
4.6.12 Konflikt zur Wissensbasis
Einem DiaFlux-Flussdiagramm liegt immer eine zuvor modellierte Wissensbasis zu Grunde.
Beispielsweise werden weit verzweigte Fragebäume erstellt, die in DiaFlux abgebildet
werden können. Innerhalb der Fragebäume existieren unterschiedliche Verzweigungen und
Schachtelungen, die beim Aufbau eines Diagramms ohne Hinweismeldungen an den
Anwender missachtet werden können.
Die folgende Darstellung beschreibt diese Anomalie. Es wurde eine Frage nach dem
Urlaubsziel erstellt. Je nach Antwort existieren untergeordnete Fragen, die konkret auf das
gewählte Ziel zugeschnitten sind. Das (unvollständig) modellierte Flussdiagramm dagegen
stellt die Fragen in beliebiger Reihenfolge. Es wird zuerst der Zustand der Skiausrüstung
erfragt, obwohl noch nicht bekannt ist, dass das Urlaubsziel ein Skigebiet ist. Ein weiterer
inkonsistenter Zustand ist die Möglichkeit, Unterabfragen zu modellieren, die nicht zur
Antwort der darüberliegenden Frage passen. Die Frage nach der Taucherbrille etwa ist nicht
sinnvoll, wenn das Urlaubsziel ein Skigebiet ist. DiaFlux nimmt an dieser Stelle keine
Rücksicht auf die im Markup des Wikis festgelegten Vorgaben der Wissensbasis.
Abbildung 68: DiaFlux Flussdiagramm (unvollständig) - Konflikt zur Wissensbasis
- 70 -
Abbildung 69: Fragen der Wissensbasis
Im nachfolgenden Kapitel wird nun beschrieben, wie einige der identifizierten Anomalien
algorithmisch erkannt und in KnowWE zur Anzeige gebracht werden.
- 71 -
5 Implementierung von Anomalie-Erkennungsalgorithmen für
DiaFlux
5.1 Integration der Anomalie-Erkennung in KnowWE
KnowWE bietet eine Schnittstelle für die kontinuierliche Integration (Continuous Integration
(CI)) von Tests unterschiedlichster Art – das Continuous Integration for Knowlegde
Engineering Plugin, kurz CI4KE-Plugin. Unter CI ist eine Praktik der Software-Entwicklung
zu verstehen, die es den Mitgliedern eines Entwicklungs-Teams ermöglicht, ihre Arbeit
kontinuierlich auf eine gemeinsame Basis zu stellen und zu integrieren. Bei jeder Integration
werden ein Build der Software erstellt und Tests ausgeführt, so dass Fehler zeitnah erkannt
werden können und jederzeit jedem Entwickler eine fertige Version der Software zur
Verfügung steht. CI ermöglicht nicht nur das manuelle Testen auf Knopfdruck, sondern auch
ein automatisiertes Testen beispielsweise über Nacht.1
Die kontinuierlichen Integrationstests in KnowWE übertragen das CI-Prinzip auf den Bereich
des Knowledge Engineering, indem von der zu Grunde liegenden Wissensbasis ein Build
erstellt wird und automatisierte Tests darauf ausgeführt werden. In KnowWE werden
Wissensbasen verteilt entwickelt, so dass es zwingend notwendig ist, die Qualität bei jeder
Änderung zu erhalten.
Bei dem CI4KE-Plugin handelt es sich um eine Anpassung des frei verfügbaren, in Java
implementierten CI-Werkzeugs Hudson auf den Bereich des Knowledge Engineering, die in
KnowWE zu Einsatz kommt. Hiermit ist es nicht nur möglich, das aktuelle Build der
Wissensbasis zu überprüfen, sondern auch den Status der letzten Builds zu sehen. Der BuildVerlauf wird in Form eines Wetterberichtes visualisiert.2 Hinzu kommt die Anzeige der
Testergebnisse und der überwachten Wiki-Artikel im sogenannten CI-Dashboard.
Abbildung 70: CI Dashboard
1 Vgl. http://martinfowler.com/articles/continuousIntegration.html, 11.05.2011, 16:06 Uhr
2 Vgl. [Och10], S. 32 f.
- 72 -
Diese graphische Benutzerschnittstelle kann über die folgende Syntax in einen Wiki-Artikel
integriert werden:
%%CIDashboard
@name: <test name>
@trigger: <onSave/onDemand>
@test: <testname> <parameters...>
%
Der name ist eine frei wählbare Überschrift für den Test. Unter test werden der Name des
Tests und mögliche Parameter eingetragen. Der Name des Tests entspricht dem Namen der
Java-Klasse, die den Test implementiert. Der trigger bestimmt, wann der Test durchgeführt
wird. Dies kann entweder beim Speichern einer Wiki-Seite (onSave) oder manuell
(onDemand) erfolgen. Letzteres sollte nur bei großen Wissensbasen eingesetzt werden, bei
denen ein Test bei jedem Speichern zu zeitaufwendig wäre.1
5.2 Realisierung der Anomalie-Erkennung
Tests können direkt im Wiki oder als Java-Testklassen innerhalb der Applikation KnowWE
implementiert werden. Die direkte Implementierung im Wiki wird über Groovy2, eine
dynamische Sprache für die virtuelle Maschine von Java, realisiert. Dies hat allerdings den
Nachteil, dass der Code erst zur Laufzeit interpretiert wird und Fehler zu spät erkannt
werden.3 Daher wird der zweite Weg der direkten Implementierung als Java-Klasse innerhalb
von KnowWE gewählt. Außerdem sind die Testklassen so an geeigneter Stelle übersichtlich
zusammengefasst.
In dieser Arbeit wurde KnowWE um ein weiteres Plugin ergänzt: KnowWE-Plugin-CI4KEAnomalies. Dieses Plugin erweitert KnowWE um Integrationstests zur Erkennung von
Anomalien in DiaFlux und beinhaltet aktuell die folgenden Java-Testklassen zur AnomalieErkennung:
•
de.d3web.we.ci4ke.anomalies.AnomalyUnconnectedNode
Prozessanomalie: Knoten ohne eingehende oder ausgehende Kanten
1 Vgl. http://d3webwiki.informatik.uni-wuerzburg.de/Wiki.jsp?page=HowToContinuousIntegrationPlugin#section-
HowToContinuousIntegrationPlugin-DocumentationAndHowToForTheCI4KEPlugin, 25.04.2011, 11:49 Uhr
2 http://groovy.codehaus.org/, 25.04.2011, 11:49 Uhr
3 Vgl. http://d3webwiki.informatik.uni-wuerzburg.de/Wiki.jsp?page=HowToContinuousIntegrationPlugin, 25.04.2011,
11:49 Uhr
- 73 -
•
de.d3web.we.ci4ke.anomalies.AnomalyAutostartFlow
DiaFlux-spezifische Anomalie: automatisch startendes Flussdiagramm mit mehr als
einem Startknoten
•
de.d3web.we.ci4ke.anomalies.AnomalyInconsistentInd
DiaFlux-spezifische Anomalie: inkonsistente Abfrageart
•
de.d3web.we.ci4ke.anomalies.AnomalyUnusedElements
Auffälligkeit: unbenutzte Elemente
Um sich an die CI-Tests anzukoppeln, implementiert jede dieser Java-Testklassen das
Interface AbstractCITest und die Methode call(). Dies ist der notwendige Schritt, um im Wiki
als Test aufgerufen werden zu können.1
public class AnomalyUnconnectedNode extends AbstractCITest {
@Override
public CITestResult call() throws Exception {
...
Der Rückgabewerte der Methode call() muss vom Typ CITestResult sein und spiegelt das
Testergebnis wider.
CITestResult res = new CITestResult(TestResultType.SUCCESSFUL,
": No unconnected nodes detected.");
Dabei kann zwischen SUCCESSFUL, FAILURE und ERROR als Testresultat unterschieden
werden. Nur SUCCESSFUL führt zu einem erfolgreichen Test und somit einer grünen
Statusanzeige für das Build im CI-Dashboard. Als Ergebnis werden außerdem die
implementierten Hinweismeldungen ausgegeben.
Abbildung 71: fehlerfreier Anomalie-Test im CIDashboard
1 Vgl. http://d3webwiki.informatik.uni-wuerzburg.de/Wiki.jsp?page=HowToContinuousIntegrationPlugin#section-
HowToContinuousIntegrationPlugin-DocumentationAndHowToForTheCI4KEPlugin, 25.04.2011, 11:49 Uhr
- 74 -
Die Quelltexte des Plugins und der Testklassen sind auf der beiliegenden CD zu finden. Das
nachfolgende Kapitel beschreibt exemplarisch den Erkennungsalgorithmus für die
Prozessanomalie der Knoten ohne eingehende oder ausgehende Kanten.
- 75 -
5.3 Erkennung der Anomalie
ausgehende Kanten“
„Knoten
ohne
eingehende
oder
Der Erkennung dieser Anomalie liegt ein einfacher Algorithmus zu Grunde, weshalb dieser
als Beispiel der Erklärung einer Implementierung im Kontext von KnowWE und DiaFlux
dienen soll:
Ermittle die Wissensbasis des Artikels
Ermittle alle Flussdiagramme der Wissensbasis
FÜR ALLE Flussdiagramme
Ermittle alle Knoten eines Flussdiagramms
FÜR ALLE Knoten eines Flussdiagramms
WENN der Knoten keine eingehenden Kanten hat UND
WENN der Knoten keine ausgehenden Kanten hat,
DANN füge ihn zur Liste der unverbundenen Knoten hinzu
WENN unverbundene Knoten gefunden wurden,
DANN ist das Testergebnis negativ,
SONST wurde der Test bestanden
Prinzipiell ist es notwendig, die Wissensbasis zu bestimmen, die überprüft werden soll. In
dieser Wissensbasis müssen alle Flussdiagramme untersucht werden. Diese Schritte sind also
für jeden Algorithmus zur Erkennung einer Anomalie erforderlich:
// get the first parameter assigned by Wiki CIDashboard
// = article whose knowledge base should be searched for anomaly
String articleName = getParameter(0);
// get the knowledge base of this article
KnowledgeBase kb =
D3webModule.getAD3webKnowledgeServiceInTopic(
KnowWEEnvironment.DEFAULT_WEB, articleName);
if (kb != null) {
// get all flowcharts of knowledge base
List<Flow> flowcharts = kb.getManager().getObjects(Flow.class);
...
- 76 -
Im Beispiel werden dann alle Knoten der Flussdiagramme durchlaufen und ihre eingehenden
und ausgehenden Kanten überprüft. Hat ein Knoten weder eingehende noch ausgehende
Kanten, so handelt es sich um eine Anomalie innerhalb eines Flussdiagramms und verursacht
ein negatives Testergebnis. Die Namen des Flussdiagramms und des Knotens werden im
Testergebnis angezeigt.
Der vollständige Quelltext dazu ist in Anhang 10.2 zu finden.
- 77 -
6 Bewertung, Zusammenfassung und Ausblick
Um die graphische Modellierungsnotation DiaFlux des semantischen Wikis KnowWE auch
im industriellen Bereich – beispielsweise für die kollaborative Modellierung einer klinischen
Richtlinie zur Erkennung einer Sepsis in einem Medizinprodukt – einsetzen zu können,
müssen hohe Qualitätsansprüche erfüllt werden. Einen wichtigen Grundstein in Richtung der
Qualitätssicherung von DiaFlux legt diese Arbeit, indem sie sich mit der Verifikation von
graphisch modelliertem Wissen und dabei konkret mit dem Erkennen einer Vielzahl von
Anomalien tiefgründig auseinander setzt. Bei Anomalien handelt es sich um Symptome
möglicher Modellierungsfehler.
Grundlage der Analysen bildeten eine ausführliche Recherche und Aggregation sowohl
klassischer als auch aktueller Literatur sowie die Anwendung der Modellierungssprache
DiaFlux in praktischen Experimenten. Bei der Literaturrecherche lag der Fokus auf der
Modellierung von Prozessen bzw. Workflows mit Hilfe graphischer Notationen. Dieser
Schwerpunkt wurde gewählt, da mittels DiaFlux graphisch Flussdiagramme modelliert
werden. Insbesondere wurden die Workflow-Perspektiven Kontrollfluss und Datenfluss
betrachtet.
DiaFlux Flussdiagramme basieren auf einer Wissensbasis, die in KnowWE modelliert ist.
Somit wurden auch Anomalien im Zusammenhang mit den zugrunde liegenden
Wissensmodellierungen untersucht. Zunächst wurden die Anomalien klassifiziert in die
Gruppen:
•
Fehlende Daten,
•
Redundanz,
•
Inkonsistenz,
•
Prozessanomalien,
•
Auffälligkeiten.
Für die praktischen Beispielmodellierungen mit DiaFlux wurde ein KnowWE Wiki
aufgesetzt, indem mit der Sprache experimentiert wurde. Die gesammelten Erfahrungen
ermöglichten die Identifikation weiterer Anomalien, die zum einen in die genannten Gruppen
eingeordnet werden konnten (z.B. das redundante Flussdiagramm), zum anderen sehr
sprachspezifisch waren (z.B. die Anomalie der inkonsistenten Abfrageart).
- 78 -
Zur prototypischen Implementierung der Anomalie-Erkennung wurde eine EclipseEntwicklungsumgebung genutzt, in der Java-Testklassen für einige ausgewählte Anomalien
entwickelt wurden. Die vier Anomalien
•
Prozessanomalie: Knoten ohne eingehende oder ausgehende Kanten,
•
DiaFlux-spezifische Anomalie: automatisch startendes Flussdiagramm mit mehr als
einem Startknoten,
•
DiaFlux-spezifische Anomalie: inkonsistente Abfrageart,
•
Auffälligkeit: unbenutzte Elemente
wurden gewählt, da sie zum einen unterschiedliche Kategorien von Anomalien repräsentieren
und zum anderen relativ leicht verständlich sind, um darauf aufbauend in Zukunft weitere
Algorithmen zu realisieren. Darüber hinaus ist gerade die Erkennung dieser Anomalien
während der Modellierung mit DiaFlux wichtig, da sie zu gravierenden Fehlern führen und
sehr leicht zu übersehen sind.
Ein gesondertes Visualisierungskonzept für erkannte Anomalien wurde nicht erarbeitet, da
die Anomalieerkennung in das Continuous Integration Framework von KnowWE (CI4KE)
integriert wurde, in dessen Rahmen das CI Dashboard zur Verfügung steht, das
Testergebnisse bereits textuell und graphisch visualisiert. Insofern wurde von einer erneuten
Entwicklung einer Visualisierung für Fehlerzustände abgesehen. Allerdings beschränkt sich
die graphische Darstellung auf eine rote (Fehlerfall) oder grüne (Testerfolg) Markierung.
Wünschenswert wäre ein dritter, gelber Status für Anomalien, die zwar falsche
Prozessabläufe begünstigen, aber nicht zu einem Fehler – wie etwa einem Deadlock – führen
müssen.
Die nachfolgende Tabelle fasst inhaltlich alle identifizierten Anomalien zusammen und
bewertet in Kurzform ihre Übertragbarkeit auf DiaFlux. Außerdem werden in dieser Arbeit
die folgenden Fehlerklassen für Anomalien differenziert:
•
Information: Dabei handelt es sich nicht um Fehler, sondern eher um „Bad Smells“1. Die
Modellierung ist beispielsweise schlecht strukturiert, so dass sich im weiteren Verlauf
leicht wirkliche Fehler ergeben können.
•
Warnung: Eine Warnung symbolisiert eine Modellierungsanomalie, die zu
ungewünschtem oder nicht-deterministischem Verhalten führt. Eine solche Modellierung
kann jedoch durch den Designer gewollt sein.
•
Fehler: Hierbei handelt es sich um einen tatsächlichen Modellierungsfehler, der die
korrekte Ausführung des DiaFlux-Flussdiagramms unmöglich macht.
1 Vgl. [Fow99], S. 75 ff.
- 79 -
Diese Unterteilung soll die zukünftige Visualisierung bestimmen. Im Falle einer Information
soll der Test als bestanden gelten und eine grüne Markierung erfolgen. Bei einer Warnung ist
der Test nicht bestanden, eine gelbe Markierung soll angezeigt werden. Tritt ein Fehler auf,
soll eine rote Markierung auf das Scheitern des Tests hinweisen.
Anomalie
Übertragbarkeit
Fehlerklasse
Uneingeschränkt übertragbar: Zugriff auf
Fehler
FEHLENDE DATEN
Uninitialisierter Wert
uninitialisierte Variablenwerte durch
Abstraktionsknoten möglich.
Verzögerte Initialisierung
Fehler
bisher uninitialisierte Variablenwerte
durch Abstraktionsknoten möglich.
Unsichere Synchronisation
Warnung
möglicherweise uninitialisierte
Variablenwerte durch Abstraktionsknoten
in parallelen Pfaden möglich.
REDUNDANZ
Starke Redundanz
Uneingeschränkt übertragbar:
Warnung
überflüssige Knoten, unnötige
Wiederholung von Werteberechnungen
oder -abfragen.
Schwache Redundanz
Information
berechneter oder abgefragter
Variablenwert eines Knotens wird in
einigen Pfaden nicht genutzt.
Redundantes Flussdiagramm
DiaFlux-spezifisch
Information
Redundanter Startknoten
DiaFlux-spezifisch
Warnung
Redundante Abfrage
DiaFlux-spezifisch
Information
Fehler
INKONSISTENZ
Stark verlorene Daten
überschriebene Variablenwerte möglich.
Schwach verlorene Daten
überschriebene Variablenwerte in einigen
Pfaden möglich.
- 80 -
Warnung
Multiple Initialisierung
Uneingeschränkt übertragbar: mehrfache
Warnung
Initialisierung eines Variablenwertes in
parallelen Pfade möglich.
Inkonsistente Abfrageart
DiaFlux-spezifisch
Warnung
Inkonsistente Herleitung
DiaFlux-spezifisch
Fehler
Konflikt zur Wissensbasis
DiaFlux-spezifisch
Fehler
Knoten ohne eingehende oder
Uneingeschränkt übertragbar: jeder
Fehler
ausgehende Kanten
Knoten mit Ausnahme des Startknotens
PROZESSANOMALIEN
muss eine eingehende Kante aufweisen,
um ausgelöst zu werden. Jeder Knoten
mit Ausnahme des Endknoten muss
mindestens eine ausgehende Kante
aufweisen, damit der Fluss fortgesetzt
werden kann.
Aktivitätsknoten mit mehr als
Eingeschränkt übertragbar: Aktivitäts- und
einer Eingangs- oder
Kontrollknoten können nicht explizit
Ausgangskante
unterschieden werden.
Warnung
Aber: ein Knoten, der als Aktivitätsknoten
fungiert (z.B. Warteknoten), sollte nur eine
Eingangs- und Ausgangskante aufweisen.
Kontrollknoten mit nur einer
Eingeschränkt übertragbar: Aktivitäts- und
Eingangs- oder Ausgangskante,
Kontrollknoten können nicht explizit
Unvollständigkeit der
unterschieden werden.
Nachbedingungen
Fehler
Aber: ein Knoten, der als Kontrollknoten
fungiert (z.B. Testknoten zur Abfrage
eines Wertes mit dem Ziel der
anschließenden Überprüfung), muss
i.d.R. mehrere Ausgangskanten
aufweisen, da mehrere Nachbedingungen
existieren können.
Sich überschneidende
Nachbedingungen
ausgehende Kanten eines Knotens
können sich überschneidende
Bedingungen aufweisen. Der zu
betretende Pfad ist somit nicht eindeutig
bestimmt.
- 81 -
Fehler
Fehlender Start- bzw. Endknoten
Uneingeschränkt übertragbar: Fehlende
Fehler
Start- oder Endknoten führen zu
unausführbaren Pfaden.
Mehrere Start- bzw. Endknoten
Eingeschränkt übertragbar: Mehrere
Warnung
Start- oder Endknoten können gewollt
modelliert sein.
Fehlgerichtete Kanten bei Start-
Uneingeschränkt übertragbar
Fehler
Verbindungsloser Knoten
Fehler
Mehrere Kanten zwischen zwei
Eingeschränkt übertragbar: nur, wenn
Warnung
Knoten
beide Kanten in dieselbe Richtung
und Endknoten
verlaufen, handelt es sich um eine
Anomalie.
Deadlock
Uneingeschränkt übertragbar: fehlt in der
Fehler
Formel eines Abstraktionsknotens
beispielsweise ein Wert zur Berechnung,
da dieser Wert nicht initialisiert ist, kann
der Pfad nicht weiter verfolgt werden.
Fehlende Synchronisation
Eingeschränkt übertragbar: Der erste
Information
eintreffende Pfad löst den Knoten aus.
Schleife
Information
Endlosschleife
Fehler
Unnötiger Nicht-Determinismus
Nicht übertragbar: Ein Knoten mit
Kein Hinweis nötig
mehreren eingehenden Kanten wartet
nicht. Ein modellierter OR-Join wartet
ebenfalls nicht, sondern wird durch den
ersten eingehenden Pfad aufgelöst.
Schleife ohne Snapshot-Knoten
DiaFlux-spezifisch
Fehler
Uneingeschränkt übertragbar: entspricht
Fehler
AUFFÄLLIGKEITEN
Unerreichbare Elemente
Knoten ohne eingehende oder
ausgehende Kanten bzw.
verbindungslosem Knoten
Toter Pfad
- 82 -
Fehler
Fehlende Modellierungsschritte
Kein Hinweis
möglich
Kein automatisch startendes
DiaFlux-spezifisch
Fehler
DiaFlux-spezifisch
Warnung
Rückkopplung
DiaFlux-spezifisch
Warnung
Unmöglicher Pfad
DiaFlux-spezifisch
Fehler
Unbenutzte Elemente der
DiaFlux-spezifisch
Information
DiaFlux-spezifisch
Warnung
Flussdiagramm
Automatisch startendes
Flussdiagramm mit mehr als
einem Startknoten
Wissensbasis
Konflikt zur Wissensbasis
Tabelle 4: Zusammenfassung identifizierter Anomalien
Durch die in der Arbeit gewonnenen Erkenntnisse kann die Qualitätskontrolle der
kollaborativen Entwicklung graphisch modellierten Wissens erweitert und verbessert werden.
Erste Erkennungsalgorithmen ermöglichen bereits heute einen industriellen Einsatz von
DiaFlux. Die Arbeit bildet die Grundlage, um weitere Algorithmen zur Detektion von
Anomalien in den modellierten Flussdiagrammen des Wikis zu implementieren. Durch die
praktischen Erfahrungen, die Anwender mit DiaFlux in Zukunft sammeln werden, können
weitere Anomalien erkannt und somit auch in geeignete Tests einbezogen und visualisiert
werden.
- 83 -
7 Literatur
Bücher- und Zeitschriftenquellen:
[Aal00]
W.M.P. van der Aalst: Workflow Verification: Finding Control-Flow Errors
using Petri-net-based Techniques, in: Business Process Management:
Models, Techniques, and Empirical Studies, Volume 1806 of Lecture
Notes in Computer Science, Springer-Verlag, Berlin, 2000, S. 161-183.
[ADL10]
A. Awad, G. Decker, and N. Lohmann: Diagnosing and Repairing Data
Anomalies in Process Models, in: Business Process Management
Workshops, Lecture Notes in Business Information Processing, Volume
43, Part 1, 2010, S. 5-16.
[AH04]
W. van der Aalst, K. van Hee: Workflow Management, Models, Methods, and
Systems, MIT Press, 2004.
[Aki03]
Klaus Akin: Qualitätssicherung in diagnostischen Wissensbasen, Diplomarbeit,
University of Würzburg, Würzburg 2003.
[Bau10]
Joachim Baumeister: Continuous Knowledge Engineering with Semantic Wikis
(Habilitation Summary), Universität Würzburg, Würzburg 2010.
[BRP09]
J. Baumeister, J. Reutelshoefer, F. Puppe: KnowWE: A Semantic Wiki for
Knowledge Engineering, in: Applied Intelligence 2010, S. 1-22.
[BS10]
J. Baumeister, D. Seipel: Anomalies in ontologies with rules, in: Web Semantics:
Science, Services and Agents on the World Wide Web, 2010, 8(1): S.
55–68.
[BZ03]
Henry H. Bi, J. Leon Zhao: A Formal Classification of Process Anomalies for
Workflow Verification, in: Proceedings of the Thirteenth Workshop on
Information Technologies and Systems (WITS 2003), Seattle, WA, USA,
2003, S. 207-212.
[DM01]
G. Duftschmid, S. Miksch: Knowledge-based verification of clinical guidelines
by detection of anomalies, in: Artificial Intelligence in Medicine 22,
2001.
[Doy79]
Jon Doyle: A truth maintenance system, in: Artificial Intelligence, Volume 12,
Issue 3, 1979, S. 231-272.
[Fow99]
Martin Fowler: Refactoring. Improving the design of existing code, AddisonWesley, 1999.
[Gal97]
Jürgen Galler: Vom Geschäftsprozessmodell zum Workflow-Modell, Gabler
Verlag Wiesbaden, 1997.
[HA10]
Arthur ter Hofstede, Michael Adams: YAWL – User Manual, Version 2.1beta,
The YAWL Foundation, 2010.
[Hab02]
Lothar Haberstock: Kostenrechnung I, Erich Schmidt Verlag, Berlin, 2002, S.
125.
- 84 -
[HBB09]
R. Hatko, V. Belli, J. Baumeister: Modelling Diagnostic Flows in Wikis, in:
LWA-2009 Special Track on Knowledge Management, Darmstadt, 2009.
[HBBP11]
Reinhard Hatko, Joachim Baumeister, Volker Belli, Frank Puppe: DiaFlux: A
Graphical Language for Computer-Interpretable Guidelines, erscheint
im Rahmen der Knowledge Representation for Health Care (KR4HC2011) (in conjunction with AIME-2011), 2011.
[HBJ09]
R. Hatko, V. Belli, J. Baumeister: DiaFlux: Diagnostic flows in wikis, in:
FGWM’09: Proceedings of German Workshop of Knowledge and
Experience Management (at LWA’09), 2009.
[HRBP10]
R. Hatko, J. Reutelshoefer, J. Baumeister, F. Puppe: Modelling of diagnostic
guideline knowledge in semantic wikis, in: Proceedings of the Workshop
on Open Knowledge Models (OKM-2010) at the 17th International
Conference on Knowledge Engineering and Knowledge Management
(EKAW), 2010.
[LC08]
Uwe Lämmel, Jürgen Cleve: Künstliche Intelligenz, Hanser Verlag, 2008.
[MD04]
Mersmann, S., Dojat, M.: SmartCaretm - automated clinical guidelines in critical
care, in: ECAI’04/PAIS’04: Proceedings of the 16th European
Conference on Artificial Intelligence, including Prestigious Applications
of Intelligent Systems, Valencia, Spain, IOS Press, 2004, S. 745–749.
[Mül05]
Joachim Müller: Workflow-based Integration – Grundlagen, Technologien,
Management, Springer-Verlag, Berlin, 2005, S. 7-34.
[Och10]
M.-O. Ochlast: Continuous integration in knowledge engineering, Master Thesis,
Universität Würzburg, Würzburg 2010.
[PGCR98]
A. D. Preece, C. Grossner, P. G. Chander, T. Radhakrishnan: Structure-based
validation of rule-based systems, in: Journal Data & Knowledge
Engineering, 1998, 26(2): S. 161-189.
[Pre94]
A. Preece: Validation of Knowledge-Based Systems: The State-of-the-Art in North
America, in: Journal of Communication and Cognition - Artificial
Intelligence, 1994, 11(4): S. 381-413.
[Pre98]
A. Preece: Building the right system right, in: Evaluating V&V Methods in
Knowledge Engineering, Verification and Validation of KnowledgeBased Systems: Papers from the AAAI-98 Workshop, AAAI Press, 1998,
S. 38–45.
[PS94]
A. Preece, R. Shinghal: Foundation and application of knowledge base
verification, in: International Journal of Intelligent Systems, Volume 9,
1994, S. 683–702.
[SBBK07]
Sebastian Schaffert, François Bry, Joachim Baumeister, Malte Kiesel: Semantic
Wiki, in: Informatik-Spektrum, Volume 30, Number 6, 2007, S. 434-439.
[SOSF04]
S. Sadiq, M. Orlowska, W. Sadiq, C. Foulger: Data Flow and Validation in
Workflow Modelling, in: ADC '04: Proceedings of the 15th Australasian
database conference, Volume 27, 2004. S. 207-214.
- 85 -
[Spe01]
Mario C. Speck: Geschäftsprozessorientierte Datenmodellierung – ein ReferenzVorgehensmodell zur fachkonzeptionellen Modellierung von
Informationsstrukturen, Logos Verlag, Berlin, 2001.
[SVOK11]
Frank Schönthaler, Gottfried Vossen, Andreas Oberweis, Thomas Karle:
Geschäftsprozesse für Business Communities – Modellierungssprachen,
Methoden, Werkzeuge, Oldenbourg Wissenschaftsverlag, München,
2011.
[SZN05]
Sherry X. Sun, J. Leon Zhao, Jay F. Nunamaker, Jr.: On The Theoretical
Foundation for Data Flow Analysis in Workflow Management, in:
AMCIS 2005 Proceedings, Paper 188, 2005.
[TAS09]
N. Trcka, W.M.P. van der Aalst, N. Sidorova: Data-Flow Anti-Patterns:
Discovering Data-Flow Errors in Workflows, in: Advanced Information
Systems Engineering, Proceedings of the 21st International Conference
on Advanced Information Systems Engineering (CAiSE'09), Volume
5565 of Lecture Notes in Computer Science, Springer-Verlag, Berlin,
2009, S. 425-439.
[Wes07]
Mathias Weske: Business Process Management: Concepts, Languages,
Architectures, Springer-Verlag, Berlin, 2007.
Internetquellen:
Drägerwerk AG: Konzerndaten
http://www.draeger.com/DE/de/, 06.02.2011, 17:05 Uhr
Drägerwerk AG: Medizintechnik
http://www.draeger.com/DE/de/investoren/draeger_auf_einen_blick/medizintech
nik/index.jsp, 06.02.2011, 17:05 Uhr
Universität Würzburg: KnowWE
http://www.is.informatik.uni-wuerzburg.de/forschung/anwendungen/knowwe/,
06.02.2011, 17:25 Uhr
Enzyklopädie der Wirtschaftsinformatik: KI
http://www.enzyklopaedie-der-wirtschaftsinformatik.de/wienzyklopaedie/lexikon/technologien-methoden/KI-undSoftcomputing/Expertensystem, 13.02.2011, 10:49 Uhr
Enzyklopädie der Wirtschaftsinformatik: Ontologie
http://www.enzyklopaedie-der-wirtschaftsinformatik.de/wienzyklopaedie/lexikon/datenwissen/Wissensmanagement/Wissensmodellierung/Wissensreprasentation/Seman
tisches-Netz/Ontologien/index.html/?searchterm=ontologie, 13.02.2011, 10:55
Uhr
Semantic Media Wiki
http://semantic-mediawiki.org/wiki/Semantic_MediaWiki, 13.02.2011, 14:12 Uhr
- 86 -
Wikipedia: Auto
http://de.wikipedia.org/wiki/Auto, 13.02.2011, 14:03 Uhr
Universität Würzburg: d3Web
http://www.is.informatik.uni-wuerzburg.de/forschung/anwendungen/d3web/,
13.02.2011, 14:55 Uhr
Universität Würzburg: KnowWE
http://www.is.informatik.uni-wuerzburg.de/forschung/anwendungen/knowwe/,
13.02.2011, 15:14 Uhr
Online Enzyklopädie: Truth Maintenance System
http://www.enzyklo.de/Begriff/Truth%20Maintenance%20System, 25.04.2011,
11:12 Uhr
Universität Würzburg: KnowWE Fragen
http://d3webwiki.informatik.uniwuerzburg.de/Wiki.jsp?page=Doc%20Questions, 18.02.2011, 17:10 Uhr
Universität Würzburg: KnowWE Regeln
http://d3webwiki.informatik.uni-wuerzburg.de/Wiki.jsp?page=Doc%20Rules,
18.02.2011, 17:19 Uhr
Universität Würzburg: KnowWE Diagnose-Regeln
http://d3webwiki.informatik.uniwuerzburg.de/Wiki.jsp?page=Doc%20DiagnosisRule, 18.02.2011, 17:03 Uhr
IT Wissen: Workflow
http://www.itwissen.info/definition/lexikon/Workflow-workflow.html,
24.02.2011, 19:13 Uhr
Universität Hohenheim: BMI
https://www.uni-hohenheim.de/wwwin140/info/interaktives/bmi.htm,
20.03.2011, 13:42 Uhr
NetDoktor: BGA
http://www.netdoktor.de/Diagnostik+Behandlungen/Laborwerte/Blutsauerstoffund-Sauerstoffs-1070.html, 20.03.2011, 15:02 Uhr
Martin Fowler: Continuous Integration
http://martinfowler.com/articles/continuousIntegration.html, 11.05.2011, 16:06
Uhr
Universität Würzburg: KnowWE CI PlugIn
http://d3webwiki.informatik.uniwuerzburg.de/Wiki.jsp?page=HowToContinuousIntegrationPlugin#sectionHowToContinuousIntegrationPluginDocumentationAndHowToForTheCI4KEPlugin, 25.04.2011, 11:49 Uhr
- 87 -
Groovy: dynamische Sprache für Java Plattformen
http://groovy.codehaus.org/
Universität Würzburg: KnowWE CI PlugIn
http://3webwiki.informatik.uniwuerzburg.de/Wiki.jsp?page=HowToContinuousIntegrationPlugin, 25.04.2011,
11:49 Uhr
- 88 -
8 Ehrenwörtliche Erklärung
Ehrenwörtliche Erklärung
Ich erkläre hiermit ehrenwörtlich, dass ich die vorliegende Arbeit selbstständig angefertigt
habe. Die aus fremden Quellen direkt oder indirekt übernommenen Gedanken sind als solche
kenntlich gemacht. Es wurden keine anderen als die angegebenen Quellen und Hinweise
verwandt.
Die vorliegende Arbeit wurde bisher keiner anderen Prüfungsbehörde vorgelegt und auch
noch nicht veröffentlicht.
Wismar, _________________
_______________________
Unterschrift
- XII -
9 Anlagenverzeichnis
Inhalte der beiliegenden CD
•
Abbildungen
-
•
Beinhaltet Abbildungen der Master Thesis (u.a. DiaFlux Flussdiagramme)
Arbeitsunterlagen
-
Gliederungsentwurf, Notizen
•
Expose
•
Implementierung
-
•
KnowWE
-
•
Präsentation und Handzettel
YAWL
-
•
Literatur (Buchkapitel, Paper, Internetquellen)
Verteidigung
-
•
Eingereichtes Paper über die Master Thesis
Quellen
-
•
KnowWE Umgebung und Inhalt des erstellten Wikis
Paper
-
•
Java-Klassen der prototypischen Anomalie-Detektionsalgorithmen
YAWL-Spezifikationen und –Abbildungen
GMeinke_103186_Thesis.doc / GMeinke_103186_Thesis.pdf
- XIII -
10 Anlage A
10.1 DiaFlux Flussdiagramm
Abbildung 72: DiaFlux Flussdiagramm
- XIV -
10.2 Algorithmus zur Erkennung der Anomalie „Knoten ohne eingehende
oder ausgehende Kanten“
/*
* Copyright (C) 2011 Chair of Artificial Intelligence and Applied
Informatics
*
Computer Science VI, University of Wuerzburg
*
* This is free software; you can redistribute it and/or modify it
* under the terms of the GNU Lesser General Public License as
* published by the Free Software Foundation; either version 3 of
* the License, or (at your option) any later version.
*
* This software is distributed in the hope that it will be
useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General
Public
* License along with this software; if not, write to the Free
* Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
MA
* 02110-1301 USA, or see the FSF site: http://www.fsf.org.
*/
package de.d3web.we.ci4ke.anomalies;
import java.util.List;
import de.d3web.core.knowledge.KnowledgeBase;
import de.d3web.diaFlux.flow.Flow;
import de.d3web.diaFlux.flow.Node;
import de.d3web.we.basic.D3webModule;
import de.d3web.we.ci4ke.testing.AbstractCITest;
import de.d3web.we.ci4ke.testing.CITestResult;
import de.d3web.we.ci4ke.testing.CITestResult.TestResultType;
import de.d3web.we.core.KnowWEEnvironment;
/**
- XV -
* Anomaly detection: test for unconnected nodes
*
* @author Gritje Meinke
* @created 17.04.2011
*/
public class AnomalyUnconnectedNode extends AbstractCITest {
@Override
public CITestResult call() throws Exception {
CITestResult res = new CITestResult(TestResultType.SUCCESSFUL,
": No unconnected nodes detected.");
Integer numberOfUnconnectedNodes = 0;
StringBuffer buf = new StringBuffer();
// get the first parameter = article whose KB should be searched
// for anomaly
String articleName = getParameter(0);
// get the KB of this article
KnowledgeBase kb =
D3webModule.getAD3webKnowledgeServiceInTopic(
KnowWEEnvironment.DEFAULT_WEB, articleName);
if (kb != null) {
// get all flowcharts
List<Flow> flowcharts =
kb.getManager().getObjects(Flow.class);
// FlowSet set = new FlowSet();
for (Flow flow : flowcharts) {
List<Node> nodes = flow.getNodes();
for (Node n : nodes) {
if (n.getIncomingEdges().isEmpty()) {
if (n.getOutgoingEdges().isEmpty()) {
buf.append("FLOWCHART: " + flow.getName() + " NODE: " +
n.getName() + "\n");
numberOfUnconnectedNodes++;
} // end if
- XVI -
} // end if
} // end for each node
} // end for each flowchart
} // end if KB
if (numberOfUnconnectedNodes > 0) {
res = new
CITestResult(TestResultType.FAILED, ": Anomaly detected - " +
numberOfUnconnectedNodes.toString() +
" unconnected node(s) found: \n" + buf.toString());
}
return res;
}
}
- XVII -

Hochschule Wismar

Transcription

Similar documents

TITEL DER PRÃSENTATION ARIAL 50PT, WEISS, FETT, GROSS

Pumpwerk am Knoten Scharnhorst

Integration von Ursachenerkennung in ein Kontrollzentrum fÃ¼r

Parametrische 3-D Modellierung von Brückenbauwerken mit

TECOLINE Speed - Just in time!

Drahtlose Kommunikationssysteme für den Produktionsbereich

Modellierungskonzept zur integrierten Planung und - E-LIB

Leitlinien zur Strukturierung der Tchibo Prozesslandkartex

Skript - Universität Paderborn

Gärten mit Naturstein. GALA - Franken Baustoff Recycling

Einführung in Graphen und Algorithmen

Genetische Programmierung und Schach