Hochschule Wismarcleve/vorl/projects/da/Master-Meinke.pdf · der Hochschule Wismar eingereicht von: Gritje Meinke, geb. Düsing geboren am 04. April 1983 in Wismar Studiengang Master

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

- II -

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.


- III -

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


- IV -

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


- V -

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


- VI -

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


- VII -

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


- VIII -

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


- IX -

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


- X -

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


- XI -

Abkürzung Bedeutung

TMS Truth Maintanence System

UML Unified Modelling Language

V&V Verifikation & Validierung

WITS Workshop on Information Technologies and Systems

XML eXtensible Markup Language

YAWL Yet Another Workflow Language


- 1 -

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


- 2 -

Allerdings können auch in einer graphischen Modellierung Fehler auftreten. Der Fokus dieser Master Thesis liegt in der Identifikation und Analyse von Anomalien, die Symptome möglicher Modellierungsfehler beschreiben. Anomalien in diagnostischen Flüssen sollen durch Recherche in klassischer und aktueller Literatur sowie anhand praktischer Experimente mit DiaFlux erkannt und aufgezeigt werden. Die gefundenen Anomalien werden strukturiert und gegebenenfalls auf DiaFlux übertragen. Die Recherchen bewegen sich im Bereich der Prozess- und Workflow-Modellierung, da mittels DiaFlux Problemdiagnostiken als Flussdiagramme modelliert werden. Die Flussdiagramme bilden diagnostisches Wissen zu Problemlösungsprozessen ab. Dies kann von einfachen Alltagsproblemen bis hin zu medizinischen Therapieszenarien reichen.

Ein weiterer Schwerpunkt der Arbeit ist die prototypische Implementierung eines Detektionsalgorithmus’ für eine DiaFlux-Anomalie im Rahmen der kontinuierlichen Integrationsumgebung für Tests von KnowWE. Darüber hinaus wird ein Visualisierungskonzept für in einer Modellierung detektierte Anomalien diskutiert.

Die aus der Arbeit resultierenden Qualitätsmethoden werden zukünftig die kontinuierliche Qualitätskontrolle der Wissensbasen in KnowWE ergänzen und den industriellen Einsatz der Modellierung mit DiaFlux unterstützen.

1.2 Related Work

Die Modellierung von Wissen in Flussdiagrammen, deren Ausführung zu einer Diagnose führt, kann in den Bereich der Prozessmodellierung und Modellierung von Workflows eingeordnet werden. Im Rahmen der Verifikation von Petri- oder Workflow-Netzen wird in der Literatur auf die Identifikation und Detektion von Anomalien eingegangen. Van der Aalst unterteilt in [Aal00] die Modellierung von Workflows unter anderem in eine Kontrollfluss- und eine Datenfluss-Perspektive. Diese Perspektiven liegen der Master Thesis zu Grunde, da ein DiaFlux-Flussdiagramm in prozeduraler (Fluss) und deklarativer (Daten) Form Wissen darstellt und verarbeitet. Van der Aalst et al. analysieren in [TAS09] Muster in Datenflüssen, die zu Fehlern führen können. Auch Sadiq et al. beschreiben in [SZN05] und [SOSF04] Validierungsprobleme und Anomalien wie redundante oder inkonsistente Daten innerhalb des Datenflusses von Workflows. Bi und Zhao stellen in [BZ03] eine formale Klassifikation von Prozessanomalien auf, die beispielsweise die falsche Verknüpfung von Knoten in einem Netz und andere Aspekte bezüglich Prozessgraphen beschreiben.

Die Evaluierung gerade wissensbasierter Systeme wird besonders durch Preece et al. in [PS94] und [Pre98] untersucht. Dabei wird auf die Validierung und Verifikation dieser Systeme sowie Probleme wie Redundanzen oder Inkonsistenzen in Wissensbasen eingegangen.

Diese Arbeit aggregiert die angesprochene und weitere Literatur, um die Fehlerquellen der Modellierung und ihrer unterschiedlichen Perspektiven auf die Modellierungsnotation DiaFlux zu übertragen. Dabei erhebt die Arbeit nicht den Anspruch, vollständig alle möglichen Anomalien gefunden zu haben und alle Perspektiven zu betrachten. Sie bildet die


- 3 -

Grundlage für weitere Analysen oder eine Implementierung der vollständigen Erkennung aller Modellierungsanomalien in einem DiaFlux-Flussdiagramm.

1.3 Übersicht über die nachfolgenden Kapitel

Im nächsten Kapitel werden die Grundlagen für das Verständnis der weiteren Inhalte der Master Thesis dargelegt. Dabei wird zunächst auf den Begriff „Wissen“ und die unterschiedlichen Modellierungsmöglichkeiten von Wissen wie Regeln, Ontologien oder semantische Wikis eingegangen. Letztere werden eingehender betrachtet, da es sich bei KnowWE um ein solches Wiki handelt. Anschließend werden KnowWE und die Notation DiaFlux zur graphischen Wissensmodellierung erläutert und die Arbeitsweise von KnowWE und DiaFlux im Zusammenspiel anhand eines Beispiels dargestellt. Im weiteren Verlauf des zweiten Kapitels werden die Perspektiven eines Workflows und verschiedene Arten der Prozess- und Workflow-Modellierung beschrieben, bevor abschließend auf die Verifikation im Kontext von Wissensbasen und deren Modellierung eingegangen wird.

Das dritte Kapitel klassifiziert die nach der Literaturrecherche identifizierten Anomalien der graphischen Modellierung von Prozessen bzw. Workflows. Dabei werden fehlende Daten, Redundanz, Inkonsistenz, Auffälligkeiten und Anomalien im Kontrollfluss – sogenannte Prozessanomalien – unterschieden und ihre Auswirkungen auf eine Wissensmodellierung skizziert.

Mit Hilfe von Experimenten mit KnowWE und DiaFlux und den darin gesammelten Erfahrungen werden im vierten Kapitel die analysierten Anomalien anhand von Beispielmodellierungen auf DiaFlux übertragen. Darüber hinaus werden weitere DiaFlux-spezifische Anomalien betrachtet.

Im fünften Kapitel wird erläutert, wie Detektionsalgorithmen für Anomalien in die Testumgebung von KnowWE integriert werden können. An dieser Stelle wird außerdem auf die Visualisierung der Testergebnisse eingegangen. Ein einfacher Beispielalgorithmus zur Erkennung von Knoten ohne eingehende oder ausgehende Kanten in einem Flussdiagramm rundet das Kapitel ab.

Die Arbeit schließt mit einer zusammenfassenden Übersichtstabelle der Anomalien, Schlussfolgerungen und einem Ausblick.


- 4 -

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


- 5 -

Die Sprache, die zur Repräsentation von Wissen angewendet werden soll, muss in der Lage sein, das Wissen auch darzustellen. Nicht jede Repräsentationsform ist für jede Art von Wissen geeignet. Vages Wissen kann beispielsweise nicht über reine aussagenlogische Formeln repräsentiert werden.1

Es können unter Anderem folgende Formen der Wissensrepräsentation unterschieden werden:

• Aussagenlogik – WAHR oder FALSCH, 2

• Prädikatenlogik – Erweiterung der Aussagenlogik um Objekte und deren Eigenschaften3

• Regelbasiert – Regeln der Form WENN DANN4

• Fuzzy Logik – Darstellung von vagem Wissen5

• Semantische Netze – Darstellung eines Netzes mit Klassen und Objekten sowie deren Eigenschaften und Relationen6

• Frames – textuelle Beschreibung von Objekten durch ihre Eigenschaften7

• Wissensnetze – graphische Darstellung basierend auf semantischen Netzen und Frames8

• Ontologien – formale Spezifikation eines Gegenstandsbereichs durch Domänenexperten9

Für tiefer gehende Informationen zu dieser Thematik sei auf [LC08] verwiesen.

In Zeiten des Web 2.0 wird Wissen oft kollaborativ erfasst und von den Autoren selbständig verwaltet. Diesem Zwecke dienen Wiki-Systeme. Ein Wiki (wie z.B. Wikipedia) kann eine schier unüberschaubare Menge an Wissen beinhalten. Um Wissen in dieser Form effektiv nutzen zu können, muss eine Volltextsuche möglich und Übersichtsseiten zur Navigation vorhanden sein. Eine andere, weitaus interessantere Möglichkeit, ist der Einsatz von Meta-Informationen in einem Wiki. Meta-Informationen in Form von semantischen Annotationen zur formalen Wissensrepräsentation erweitern ein einfaches Wiki zu einem so genannten

1 Vgl. [LC08], S. 33

2 Vgl. [LC08], S. 35 ff.

3 Vgl. [LC08], S. 54 ff.

4 Vgl. [LC08], S. 69 ff.

5 Vgl. [LC08], S. 89 ff.

6 Vgl. [LC08], S. 83 ff.

7 Vgl. [LC08], S. 85 ff.

8 Vgl. [LC08], S. 87 ff.

9 Vgl. http://www.enzyklopaedie-der-wirtschaftsinformatik.de/wi-enzyklopaedie/lexikon/daten-wissen/Wissensmanagement/Wissensmodellierung/Wissensreprasentation/Semantisches-Netz/Ontologien/index.html/?searchterm=ontologie, 13.02.2011, 10:55 Uhr


- 6 -

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


- 7 -

– 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


- 8 -

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


- 9 -

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


- 10 -

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


- 11 -


Testknoten

Durch diese Art Knoten wird eine Aktivität ausgeführt – z.B. das Durchführen eines Tests, das Abfragen eines Wertes vom Benutzer oder Gerät. Bei der Abfrage eines Wertes kann zwischen ask und always ask unterschieden werden. Im ersten Fall wird der Wert einmal abgefragt, wenn er noch nicht bekannt ist. Im zweiten Fall wird der Wert jedes Mal erfragt, wenn der Knoten aktiviert wird.

Der Knoten kann auch verwendet werden, um einen Wert im Flussdiagramm zu berechnen oder festzulegen. Ein solcher Knoten wird auch Abstraktionsknoten genannt.

Fork Knoten Durch diesen Knoten kann der Programmfluss in parallele Pfade verzweigt werden.

Testknoten mit mehreren Ausgangskanten

Join Knoten Durch diesen Knoten werden parallele Pfade wieder zusammengeführt. (Alternativ kann ein paralleler Zweig auch durch einen Endknoten beendet werden. Die anderen parallelen Zweige laufen dann weiter ab.)

Testknoten mit mehreren Eingangskanten

Diagnoseknoten Dieser Knoten symbolisiert die Herleitung einer Problemlösung – konkret einer gefundenen Diagnose.

Snapshot-Knoten Mit einem Snapshot-Knoten werden die bisher erfassten Daten als unveränderbar angenommen und im Blackboard schreibgeschützt. Das TMS kann somit nichts vor diesem Knoten rückgängig machen oder manipulieren. Alle aktiven Knoten auf eingehenden Pfaden werden deaktiviert (ohne ihre Rücknahme), um eine erneute Ausführung zu ermöglichen.40

Kompositionsknoten Dieser Knoten wird zum Einbinden eines anderen Flussdiagramms genutzt. Der Startknoten des eingebundenen Unterdiagramms kann im Knoten ausgewählt werden.

40 Vgl. [HBBP11], S. 5 f.


- 12 -


Warteknoten Durch diesen Knoten wird eine Wartezeit in das Flussdiagramm integriert, die die Ausführung pausiert, bis sie abgelaufen ist.

Schleifenknoten Definierte Aktionen werden in einer gewissen Anzahl von Durchläufen wiederholt.

Tabelle 1: DiaFlux Knotentypen

Quelle: Vgl. [HRBP10] S. 7 f., vgl. [HBB09] S. 2 f., Abbildungen: eigene Darstellung

Mit Hilfe dieser Knoten kann modulares, paralleles und zeitorientiertes diagnostisches Prozesswissen modelliert werden.1 Die Ausführung eines modellierten Prozesses beginnt mit der Aktivierung eines Startknotens und vollzieht sich dann durch die Aktivierung der Knoten und Kanten. Der genaue Aktivierungsvorgang kann der nachfolgenden Tabelle entnommen werden:

Element Voraussetzung für die Aktivierung

Aktivierung Deaktivierung

Knoten Eine eingehende Kante ist aktiv / wahr.

Aktion des Knotens wird ausgeführt.

Aktion des Knotens wird rückgängig gemacht.

Kante Die Kante resultiert aus einem Startknoten oder die Bedingung, die an der Kante anliegt, wird wahr.

Der nachfolgende Knoten wird aktiviert, wenn er nicht bereits aktiviert war.

Der nachfolgende Knoten wird deaktiviert, wenn er keine weiteren, aktiven eingehenden Kanten aufweist.

Tabelle 2: Aktivierungszustände der DiaFlux-Knoten und -Kanten

Quelle: Vgl. [HBBP11], S. 8

Welche Kante betreten und welcher Knoten aktiviert wird, wird durch die Dateneingaben im Blackboard determiniert.2

2.2.2.3 DiaFlux Entwicklungsprozess

Der Entwicklungsprozess eines Flussdiagramms mit DiaFlux gestaltet sich wie folgt1:

1 Vgl. [HBB09], S. 5

2 Vgl. [HBBP11], S. 8


- 13 -

• 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


- 14 -

-- 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


- 15 -

• 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


- 16 -

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.


- 17 -

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


- 18 -

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.


- 19 -

Abbildung 12: DiaFlux - Flussdiagramm zur Berechnung der MwSt



- 20 -

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


- 21 -

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


- 22 -

Für die Modellierung von Flussdiagrammen in DiaFlux und die Analyse von Anomalien werden einige dieser Perspektiven außer Acht gelassen. Die Ressourcen- oder Organisationsperspektive spielt inhaltlich keine Rolle, Ressourcen werden nicht in die Modellierung aufgenommen. Auch detaillierte Beschreibungen der einzelnen Tätigkeiten innerhalb von Aufgaben wie in der Aufgaben- und Funktionsperspektive werden nicht vorgenommen. Die Durchführungs- und Anwendungsperspektive wird ebenfalls nicht betrachtet, da die in DiaFlux modellierten klinische Richtlinien in Form von Wissensbasen aus KnowWE exportiert werden und in einem anderen Umfeld, beispielweise in der automatisierten Steuerung eines Medizingerätes, zum Einsatz kommen.

2.3.2 Datenflussperspektive

Modellierungsfehler entstehen oft im Zusammenspiel zwischen Daten- und Kontrollfluss. Daher ist die aufmerksame Modellierung des Datenflusses von großer Bedeutung.1 In der Spezifikation des Datenflusses geht es darum, wie Daten durch Aktivitäten produziert und konsumiert werden.2 Datenelemente können gelesen, geschrieben und zerstört werden.3 Dabei bearbeiten die einzelnen Aktivitäten die Daten und besitzen eingehende (Input-/Eingabe-Daten) und ausgehende (Output-/Ausgabe-Daten) Datenflüsse. Physikalisch werden die Daten nicht weiter geleitet.4

Eine Datenfluss-Matrix kann helfen, einen Überblick über den Datenfluss zu erhalten. Dabei werden in zweidimensionaler Form die unterschiedlichen Operationen der Datenelemente d den Aktivitäten v zugeordnet. Wird ein Datum durch eine Aktivität gelesen (R = read), so handelt es sich um einen Eingabewert. Wird ein Datum geschrieben (W = write), ist es der Ausgabewert der Aktivität.5 Die folgende Tabelle zeigt exemplarisch eine solche Datenflussmatrix:

Datenelement / Aktivität v1 v2 v3

d1: Patientenname W R

d2: Geburtsdatum W R

Tabelle 3: Beispiel für eine Datenfluss-Matrix

Quelle: eigene Darstellung in Anlehnung an [SZN05], S. 2919 f.

1 Vgl. [ADL10], S. 1

2 Vgl. [SZN05], S. 2917

3 Vgl. [TAS09], S. 3 f.

4 Vgl. [Gal97], S. 83

5 Vgl. [SZN05], S. 2918 ff.


- 23 -

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 repräsentiert.

• Aktivitäten werden durch Großbuchstaben gekennzeichnet, z.B. ; Instanzen von Aktivitäten mit den korrespondierenden Kleinbuchstaben .

• Folgt eine Aktivität auf , so kann erst starten, wenn terminiert ist.6

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


- 24 -

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 ausgeführt. Der Typ des Prozessmodells ist .2

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


- 25 -

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


- 26 -

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.


- 27 -

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 Möglichkeit die richtige ist, kann nicht entschieden werden.1

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


- 28 -

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.


- 29 -

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


- 30 -

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.


- 31 -

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


- 32 -

Ä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


- 33 -

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


- 34 -

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


- 35 -

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.


- 36 -

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


- 37 -

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.


- 38 -

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


- 39 -

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


- 40 -

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.


- 41 -

• 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


- 42 -

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


- 43 -

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.


- 44 -

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 OR-Join 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


- 45 -

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


- 46 -

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 AND-Split 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 AND-Splits 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


- 47 -

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


- 48 -

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


- 49 -

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


- 50 -

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.


- 51 -

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


- 52 -

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


- 53 -

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


- 54 -

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


- 55 -

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


- 56 -

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.


- 57 -

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.


- 58 -

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



- 59 -

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.


- 60 -

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.


- 61 -

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.


- 62 -

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



- 63 -

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.


- 64 -

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.


- 65 -

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.


- 66 -

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.


- 67 -

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


- 68 -

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.


- 69 -

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



- 70 -

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



- 71 -

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.


- 72 -

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 Build-Verlauf 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.


- 73 -

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-CI4KE-Anomalies. Dieses Plugin erweitert KnowWE um Integrationstests zur Erkennung von Anomalien in DiaFlux und beinhaltet aktuell die folgenden Java-Testklassen zur Anomalie-Erkennung:

• 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


- 74 -

• 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


- 75 -

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.


- 76 -

5.3 Erkennung der Anomalie „Knoten ohne eingehende oder ausgehende Kanten“

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);

...


- 77 -

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.


- 78 -

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).


- 79 -

Zur prototypischen Implementierung der Anomalie-Erkennung wurde eine Eclipse-Entwicklungsumgebung 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.


- 80 -

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

FEHLENDE DATEN

Uninitialisierter Wert Uneingeschränkt übertragbar: Zugriff auf uninitialisierte Variablenwerte durch Abstraktionsknoten möglich.

Fehler

Verzögerte Initialisierung Uneingeschränkt übertragbar: Zugriff auf bisher uninitialisierte Variablenwerte durch Abstraktionsknoten möglich.

Fehler

Unsichere Synchronisation Uneingeschränkt übertragbar: Zugriff auf möglicherweise uninitialisierte Variablenwerte durch Abstraktionsknoten in parallelen Pfaden möglich.

Warnung

REDUNDANZ

Starke Redundanz Uneingeschränkt übertragbar: überflüssige Knoten, unnötige Wiederholung von Werteberechnungen oder -abfragen.

Warnung

Schwache Redundanz Uneingeschränkt übertragbar: berechneter oder abgefragter Variablenwert eines Knotens wird in einigen Pfaden nicht genutzt.

Information

Redundantes Flussdiagramm DiaFlux-spezifisch Information

Redundanter Startknoten DiaFlux-spezifisch Warnung

Redundante Abfrage DiaFlux-spezifisch Information

INKONSISTENZ

Stark verlorene Daten Uneingeschränkt übertragbar: überschriebene Variablenwerte möglich.

Fehler

Schwach verlorene Daten Uneingeschränkt übertragbar: überschriebene Variablenwerte in einigen Pfaden möglich.

Warnung


- 81 -

Multiple Initialisierung Uneingeschränkt übertragbar: mehrfache Initialisierung eines Variablenwertes in parallelen Pfade möglich.

Warnung

Inkonsistente Abfrageart DiaFlux-spezifisch Warnung

Inkonsistente Herleitung DiaFlux-spezifisch Fehler

Konflikt zur Wissensbasis DiaFlux-spezifisch Fehler

PROZESSANOMALIEN

Knoten ohne eingehende oder ausgehende Kanten

Uneingeschränkt übertragbar: jeder Knoten mit Ausnahme des Startknotens 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.

Fehler

Aktivitätsknoten mit mehr als einer Eingangs- oder Ausgangskante

Eingeschränkt übertragbar: Aktivitäts- und Kontrollknoten können nicht explizit unterschieden werden.

Aber: ein Knoten, der als Aktivitätsknoten fungiert (z.B. Warteknoten), sollte nur eine Eingangs- und Ausgangskante aufweisen.

Warnung

Kontrollknoten mit nur einer Eingangs- oder Ausgangskante, Unvollständigkeit der Nachbedingungen

Eingeschränkt übertragbar: Aktivitäts- und Kontrollknoten können nicht explizit unterschieden werden.

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.

Fehler

Sich überschneidende Nachbedingungen

Uneingeschränkt übertragbar: ausgehende Kanten eines Knotens können sich überschneidende Bedingungen aufweisen. Der zu betretende Pfad ist somit nicht eindeutig bestimmt.

Fehler


- 82 -

Fehlender Start- bzw. Endknoten Uneingeschränkt übertragbar: Fehlende Start- oder Endknoten führen zu unausführbaren Pfaden.

Fehler

Mehrere Start- bzw. Endknoten Eingeschränkt übertragbar: Mehrere Start- oder Endknoten können gewollt modelliert sein.

Warnung

Fehlgerichtete Kanten bei Start- und Endknoten

Uneingeschränkt übertragbar Fehler

Verbindungsloser Knoten Uneingeschränkt übertragbar Fehler

Mehrere Kanten zwischen zwei Knoten

Eingeschränkt übertragbar: nur, wenn beide Kanten in dieselbe Richtung verlaufen, handelt es sich um eine Anomalie.

Warnung

Deadlock Uneingeschränkt übertragbar: fehlt in der Formel eines Abstraktionsknotens beispielsweise ein Wert zur Berechnung, da dieser Wert nicht initialisiert ist, kann der Pfad nicht weiter verfolgt werden.

Fehler

Fehlende Synchronisation Eingeschränkt übertragbar: Der erste eintreffende Pfad löst den Knoten aus.

Information

Schleife Uneingeschränkt übertragbar Information

Endlosschleife Uneingeschränkt übertragbar Fehler

Unnötiger Nicht-Determinismus Nicht übertragbar: Ein Knoten mit mehreren eingehenden Kanten wartet nicht. Ein modellierter OR-Join wartet ebenfalls nicht, sondern wird durch den ersten eingehenden Pfad aufgelöst.

Kein Hinweis nötig

Schleife ohne Snapshot-Knoten DiaFlux-spezifisch Fehler

AUFFÄLLIGKEITEN

Unerreichbare Elemente Uneingeschränkt übertragbar: entspricht Knoten ohne eingehende oder ausgehende Kanten bzw. verbindungslosem Knoten

Fehler

Toter Pfad Uneingeschränkt übertragbar Fehler


- 83 -

Fehlende Modellierungsschritte Uneingeschränkt übertragbar Kein Hinweis möglich

Kein automatisch startendes Flussdiagramm

DiaFlux-spezifisch Fehler

Automatisch startendes Flussdiagramm mit mehr als einem Startknoten

DiaFlux-spezifisch Warnung

Rückkopplung DiaFlux-spezifisch Warnung

Unmöglicher Pfad DiaFlux-spezifisch Fehler

Unbenutzte Elemente der Wissensbasis

DiaFlux-spezifisch Information

Konflikt zur Wissensbasis DiaFlux-spezifisch Warnung

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.


- 84 -

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, Addison-Wesley, 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.


- 85 -

[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 (KR4HC-2011) (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 Knowledge-Based 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.


- 86 -

[Spe01] Mario C. Speck: Geschäftsprozessorientierte Datenmodellierung – ein Referenz-Vorgehensmodell 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/medizintechnik/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/wi-enzyklopaedie/lexikon/technologien-methoden/KI-und-Softcomputing/Expertensystem, 13.02.2011, 10:49 Uhr

Enzyklopädie der Wirtschaftsinformatik: Ontologie http://www.enzyklopaedie-der-wirtschaftsinformatik.de/wi-enzyklopaedie/lexikon/daten-wissen/Wissensmanagement/Wissensmodellierung/Wissensreprasentation/Semantisches-Netz/Ontologien/index.html/?searchterm=ontologie, 13.02.2011, 10:55 Uhr

Semantic Media Wiki http://semantic-mediawiki.org/wiki/Semantic_MediaWiki, 13.02.2011, 14:12 Uhr


- 87 -

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.uni-wuerzburg.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.uni-wuerzburg.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/Blutsauerstoff-und-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.uni-wuerzburg.de/Wiki.jsp?page=HowToContinuousIntegrationPlugin#section-HowToContinuousIntegrationPlugin-DocumentationAndHowToForTheCI4KEPlugin, 25.04.2011, 11:49 Uhr


- 88 -

Groovy: dynamische Sprache für Java Plattformen http://groovy.codehaus.org/

Universität Würzburg: KnowWE CI PlugIn http://3webwiki.informatik.uni-wuerzburg.de/Wiki.jsp?page=HowToContinuousIntegrationPlugin, 25.04.2011, 11:49 Uhr


- XII -

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


- XIII -

9 Anlagenverzeichnis

Inhalte der beiliegenden CD

• Abbildungen

- Beinhaltet Abbildungen der Master Thesis (u.a. DiaFlux Flussdiagramme)

• Arbeitsunterlagen

- Gliederungsentwurf, Notizen

• Expose

• Implementierung

- Java-Klassen der prototypischen Anomalie-Detektionsalgorithmen

• KnowWE

- KnowWE Umgebung und Inhalt des erstellten Wikis

• Paper

- Eingereichtes Paper über die Master Thesis

• Quellen

- Literatur (Buchkapitel, Paper, Internetquellen)

• Verteidigung

- Präsentation und Handzettel

• YAWL

- YAWL-Spezifikationen und –Abbildungen

• GMeinke_103186_Thesis.doc / GMeinke_103186_Thesis.pdf


- XIV -

10 Anlage A

10.1 DiaFlux Flussdiagramm

Abbildung 72: DiaFlux Flussdiagramm



- XV -

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;

/**


- XVI -

* 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


- XVII -

} // 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;

}

}

Documents

Hochschule Wismarcleve/vorl/projects/da/Master-Meinke.pdf · der Hochschule Wismar eingereicht von: Gritje Meinke, geb. Düsing geboren am 04. April 1983 in Wismar Studiengang Master