FLOWLIX: INTEGRATION EINES WORKFLOW-MANAGEMENT- SYSTEMS FÜR EXTRAKTIONSPROZESSE IM PROJEKT INTELLIX

Transkript

1 Fakultät Informatik Institut für Systemarchitektur, Lehrstuhl Rechnernetze Diplomarbeit FLOWLIX: INTEGRATION EINES WORKFLOW-MANAGEMENT- SYSTEMS FÜR EXTRAKTIONSPROZESSE IM PROJEKT INTELLIX Christian Elmer Matrikel-Nr.: Betreut durch: Dipl.-Medien-Inf. Klemens Muthmann Verantwortlicher Hochschullehrer: Prof. Dr. rer. nat. habil Dr. h. c. Schill Eingereicht am 30. September 2011

2

3

4 iv

5 SELBSTSTÄNDIGKEITSERKLÄRUNG Hiermit erkläre ich, Christian Elmer, die vorliegende Diplomarbeit zum Thema: Flowlix: Integration eines Workflow-Management-Systems für Extraktionsprozesse im Projekt Intellix selbstständig und ausschließlich unter Verwendung der im Literaturverzeichnis aufgeführten Informationsquellen verfasst zu haben. Dresden, 30. September 2011 Christian Elmer v

6 vi

7 INHALTSVERZEICHNIS 1 Einleitung Motivation Ziele Aufbau Grundlagen Geschäftsprozessmodellierung Workflow-Patterns Workflow-Management Intellix Mensch-Computer-Interaktion Analyse Stand der Technik Zielgruppe Anforderungen Implementierungsmöglichkeiten Fazit Konzept Intellix Workflows Modellierungswerkzeug Integration Fazit Implementierung Modellierung Integration Fazit Evaluierung Nutzerbefragung Laufzeit und Speicherverbrauch Zusammenfassung und Ausblick Modellierung Integration vii

8 Grafiken 79 Abkürzungsverzeichnis 81 Abbildungsverzeichnis 84 Tabellenverzeichnis 85 viii Inhaltsverzeichnis

9 1 EINLEITUNG 1.1 MOTIVATION Durch die wachsende Anzahl an Geschäftsdokumenten und deren langen Aufbewahrungsfristen ist es für Unternehmen schwer, ohne Rechnerunterstützung diese Dokumente zu verwalten. Aus diesem Grund werden heutzutage ein oder mehrere Dokumenten Management Systeme (DMS) eingesetzt, um eingehende Dokumente zu erfassen und geordnet abzulegen. Damit Dokumente durch Suchanfragen wieder gefunden werden können, müssen die Geschäftsdokumente nach der grafischen oder textuellen Erfassung indexiert werden. Das bedeutet, dass man relevante Informationen aus Dokumenten extrahiert. Die Informationen werden dann zusammen mit den dazugehörigen Dokumenten abgespeichert. Durch diese Indexdaten können sich die Suchzeiten bei Anfragen um bis zu Prozent verringern. [GSSZ02, S. 14] Durch die Ablösung manueller Verfahren zur Indexierung der Dokumente mit automatischen Indexierungsmechanismen können wiederum hohe Kosten in Unternehmen mit großen Dokumentenmengen reduziert werden. Das Gemeinschaftsprojekt Intellix 1, das von der Professur Rechnernetze der TU Dresden und der DocuWare AG Germering entwickelt wird, soll ein verteiltes semi-automatisches Informationsextraktionssystem für DMS entstehen lassen. In diesem Projekt wird eine minimierte manuelle Nachbereitung der Indexdaten angestrebt, die unter anderem durch eine hohe Konfigurierbarkeit der Indexierung erreicht wird. [BSS10, S. 3] Das heißt, dass die Indexierung einzelner Intellix Instanzen auf domänenspezifische Geschäftsdokumente angepasst werden können. Diese Anpassung erfolgt durch die Bearbeitung vordefinierter Extraktionspläne. Die Extraktionspläne wiederum sind gleichbedeutend mit voll automatisierten Arbeitsabläufen. Arbeitsabläufe werden in Unternehmen typischerweise als Geschäftsprozesse dargestellt. Diese Geschäftsprozesse bestehen aus Aktivitäten, Ereignissen und Abfolgen. Die Aktivitäten können sowohl manuelle Aufgaben für bestimmte Personen oder Personengruppen oder automatische computergestützte Aktionen darstellen. Wenn komplexe Geschäftsprozesse modelliert werden müssen, ist es nicht mehr ausreichend Präsentations- oder Grafikprogramme für die Darstellung 1 Intelligente, adaptive Indexierung heterogener Dokumentbasen 1

10 dieser Prozesse zu nutzen. Auch der weitverbreitete UML - Standard mit seinen Aktivitätsdiagrammen eignet sich nur bedingt zur Geschäftsprozessmodellierung, weil diese Modellierungssprache größtenteils auf den Bereich des objektorientierten Softwareentwurfs beschränkt ist. Dieser Mangel an geeigneten Modellierungssprachen für komplexe Geschäftsprozesse gab der Industrie den Anstoß geeignete Standards zu entwickeln. Auch im Bereich der Umsetzung dieser Modelle wird im Unterschied zur Softwareentwicklung Wert darauf gelegt, dass sowohl Entwickler, wie auch Anwender die Modelle verstehen und bedienen können. [Gad08] 1.2 ZIELE Das Ziel dieser Arbeit ist die Integration eines geeigneten Workflow Management Systems (WfMS) in das Extraktionsframework Intellix. Es soll eine Möglichkeit geschaffen werden, mit einem grafischen Modellierungswerkzeug Workflows für das Intellix Framework zu erstellen. Zusätzlich muss ein bestehendes WfMS in das Intellix Framework integriert werden, sodass es möglich ist, die modellierten Workflows auszuführen. Außerdem sollte es eine Möglichkeit geben die Abarbeitung dieser Workflows zu überwachen, damit man sie analysieren und durch Remodellierung optimieren kann. Der Ausgangspunkt der Arbeit des Intellix Frameworks sind Geschäftsdokumente verschiedenster Art. Diese Dokumente können in zwei unterschiedlichen Formen vorliegen. Einerseits als Scan-Ergebnisse aus Papierdokumenten, andererseits als elektronische Dokumente. Abhängig von der Form der Dokumente, wird der Text dieser Dokumente mittels Texterkennung (OCR 2 ) oder Volltextextraktion extrahiert. Durch Dokumenttypklassifikationen und Indexdatenextraktionen werden die Dokumente indexiert. Da es bei dieser Indexierung verschiedene Methoden und Algorithmen gibt, wird das konkrete Vorgehen durch Extraktionspläne spezifiziert. Die Indexdaten sind essenziell für das Wiederfinden der Dokumente und somit ein zentraler Bestandteil jedes DMS. Dieser gesamte Arbeitsablauf des Intellix Frameworks ist in der Abbildung 1.1 dargestellt. Abbildung 1.1: Intellix Konzept als Prozessmodell, Quelle:[BSS10] 2 Optische Zeichenerkennung (engl. Optical Character Recognition) 2 Kapitel 1 Einleitung

11 Der Schwerpunkt dieser Arbeit liegt bei den Extraktionsplänen, welche die Workflows für die Indexierung der Dokumente darstellen. DMS, die auf dieses Framework zurückgreifen, sollen in beliebigen Unternehmen eingesetzt werden. Aus diesem Grund dienen die Extraktionspläne einerseits dazu, die Dokumenttypklassifikation und Indexdatenextraktion den Domänen dieser Unternehmen anzupassen und andererseits um eine verteilte Anwendung dieser Pläne zu ermöglichen. Durch die verteilte Anwendung ist es möglich, dass sowohl lokale, als auch organisationsübergreifende Extraktionspläne genutzt werden können. 1.3 AUFBAU Nach der Einleitung folgen im Kapitel 2 die Grundlagen zum Thema Geschäftsprozessmodellierung und Workflow-Management. Zuerst werden einige Konzepte und Sprachen zur Geschäftprozessmodellierung, sowie ausgewählte WfMS vorgestellt. Außerdem werden Workflow-Patterns beschrieben, die durch die Definition wiederkehrender Muster die Modellierung von Workflows vereinfachen können. Zum Schluss folgen Erläuterungen zu Methoden und Algorithmen aus dem bestehenden Intellix Framework. Darauf aufbauend werden im Kapitel 3 die Struktur der Verarbeitungskomponenten und die aktuellen Methoden, Arbeitsabläufe zu definieren und zu verarbeiten, untersucht. Außerdem werden in diesem Kapitel Anforderungen für das Konzept dieser Arbeit aufgestellt und die Zielgruppe für das fertige Produkt definiert. Infolgedessen findet eine Analyse statt, die die infrage kommenden WfMS anhand der Anforderungen untersucht und ein geeignetes System für die Implementierung auswählt. Das darauf folgende Kapitel 4 ermittelt die Strukturen der Intellix Workflows und erarbeitet ein Konzept für die Implementierung des WfMS in das Intellix Framework. Kapitel 5 beschreibt die Implementierung, die anhand dieses Konzepts umgesetzt wurde. Zum Abschluss wird diese Implementierung im Kapitel 6 mit einer Nutzerbefragung und einer Laufzeitmessung, sowie einer Speicheranalyse evaluiert. 1.3 Aufbau 3

12 4 Kapitel 1 Einleitung

13 2 GRUNDLAGEN In diesem Kapitel werden Grundlagen ausgearbeitet, die zur Bearbeitung des Themas dieser Arbeit notwendig sind. Zunächst wird im Abschnitt 2.1 auf grundlegende Begriffe rund um das Thema Geschäftsprozessmodellierung, Workflow und Workflow-Management eingegangen und einige relevante Modellierungssprachen vorgestellt. Im Abschnitt 2.2 werden Workflow-Patterns vorgestellt, welche, analog zu Entwurfsmustern in der Softwareentwicklung, wiederkehrende Muster in Geschäftprozessen beschreiben. Diese Muster werden in den Modellierungssprachen mehr oder weniger nativ unterstützt. Abschnitt 2.3 gibt einen Einblick in die Thematik Workflow-Management und stellt einige Workflow Management Systeme (WfMS) vor, die für die Implementierung dieser Arbeit in Betracht kommen können. Die Besonderheiten des Intellix 1 Frameworks, im Bezug auf die Thematik Workflow-Management wird im Abschnitt 2.4 näher erläutert. Für die Bewertung einer Implementierung dieser Arbeit wird im Abschnitt 2.5 eine Evaluierungsmethode für Software der Kategorie Mensch-Computer-Interaktion vorgestellt. 2.1 GESCHÄFTSPROZESSMODELLIERUNG Die Aufgabe dieser Arbeit ist es, ein WfMS in das Forschungsprojekt Intellix zu integrieren. Um die Arbeitsweise von WfMS zu verstehen, müssen zuerst grundlegende Verfahrensweisen und Begriffe im Zusammenhang mit diesen Systemen erläutert werden. Abbildung 2.1 zeigt eine Übersicht aller relevanten Begriffe in diesem Zusammenhang und ihre Beziehungen zueinander. Es existieren verschiedene Ansätze zur Geschäftsprozessmodellierung. Der formale Ansatz zur Modellierung von Geschäftsmodellen basiert grundsätzlich auf Petri-Netzen (siehe ). Ein weiterer Ansatz ist die fachlich orientierte Geschäftsprozessmodellierung, welche das Ziel verfolgt möglichst einfach und verständlich zu sein. Das hat den Vorteil, dass kein technisches Hintergrundwissen benötigt wird, um die Prozesse zu modellieren, aber den Nachteil, dass die Modelle 1 Intelligente, adaptive Indexierung heterogener Dokumentbasen 5

14 Hierarchie der wesentlichen Begriffe im Workflow-Umfeld. Quelle Angelehnt an: [ Abbildung 2.1: Beziehungen zwischen den Grundbegriffen, Quelle: [M 06] viel Interpretationsspielraum zulassen und somit nicht direkt von einem WfMS ausgeführt werden können. Reine ausführbare Prozessbeschreibungen hingegen besitzen keine grafische Repräsentation. Sie bieten textuelle Beschreibungen, die es WfMS ermöglichen, Geschäftsprozesse direkt auszuführen. Außerdem gibt es noch den Ansatz eine Notation zu entwickeln die einfach und verständlich ist, aber dennoch direkt von einem WfMS ausgeführt werden kann. Alle Methoden haben die Gemeinsamkeit, dass sie in einer festgelegten Notation verfasst werden. Damit ist es möglich, dass jeder der diese Notation beherrscht, das Modell lesen und analysieren kann Geschäftsprozess Wie man in Abbildung 2.1 sehen kann, ist das zentrale Element in diesem Zusammenhang der Geschäftsprozess. Geschäftsprozesse beschreiben eine Abfolge von Aktivitäten in einem Unternehmen. Die Aktivitäten stellen zusammengesetzte oder einzelne Ereignisse dar. Ein Geschäftsprozess verfolgt immer ein Ziel und kann, beziehungsweise sollte wiederholt werden. In der Literatur findet man viele Definitionen zum Geschäftsprozess, je nach Abstraktionsgrad und Definition des Anwendungsbereichs der gegebenen Unternehmensstrukturen. In einer eher technischen Abhandlung über das Geschäftprozessmanagement ist folgende Definition zu finden. 6 Kapitel 2 Grundlagen

15 Definition 1 (Geschäftsprozess nach Weske) A business process consists of a set of activities that are performed in coordination in an organizational and technical environment. These activities jointly realize a business goal. Each business process is enacted by a single organization, but it may interact with business processes performed by other organizations. [Wes07, S. 5] Ein Geschäftsprozess wird also genau von einer Organisation ausgeführt. Es können aber auch mehrere Prozesse unterschiedlicher Organisationen interagieren. Die Workflow Management Coalition (WfMC) definiert Geschäftsprozesse innerhalb von Organisationen noch genauer. Definition 2 (Geschäftsprozess nach der WfMC) A set of one or more linked procedures or activities which collectively realize a business objective or policy goal, normally within the context of an organisational structure defining functional roles and relationships. [WfM99] Nach der WfMC läuft also ein Geschäftsprozess normalerweise im Kontext einer Organisationsstruktur mit ihren gegebenen Rollen und Beziehungen ab. Einzelne Aktivitäten in diesen Prozessen können sowohl aus manuellen Arbeitsschritten, wie zum Beispiel einer Benutzeraufgabe, wie auch aus automatischen Arbeitsschritten bestehen, die von einem WfMS gesteuert und kontrolliert werden Prozessdefinition Eine Prozessdefinition beschreibt Aktivitäten, ihre Beziehungen zueinander, den Beginn und Abschluss eines Geschäftsprozesses und beinhaltet Informationen zu den einzelnen Aktivitäten. Bei den Aktivitäten kann es sich um automatische Aktivitäten, die durch ein computergestütztes System ohne Zutun des Anwenders ausgeführt werden oder um manuelle Aktivitäten, die mit Personen interagieren, handeln. Die WfMC definiert eine Prozessdefinition wie folgt. Definition 3 (Prozessdefinition nach der WfMC) The representation of a business process in a form which supports automated manipulation, such as modelling, or enactment by a workflow management system. The process definition consists of a network of activities and their relationships, criteria to indicate the start and termination of the process, and information about the individual activities, such as participants, associated IT applications and data, etc. [WfM99] Die Prozessdefinition ist also die formale Repräsentation des Geschäftsprozesses Workflow In dieser Arbeit wird fast ausschließlich von Workflows gesprochen und teilweise synonym mit dem Begriff Prozessdefinitionen verwendet. Es gibt jedoch Unterschiede zwischen diesen beiden Begriffen. Eine Prozessdefinition beschreibt Arbeitsabläufe in einer Organisation und wird eher von Experten der Thematik des 2.1 Geschäftsprozessmodellierung 7

16 Geschäftsprozesses entwickelt. Dagegen beschreiben Workflows ausschließlich ganz oder teilweise automatisierte Prozesse. Die Workflows werden meist von IT- Spezialisten angefertigt, die dabei eine formale Sprache nutzen die für WfMS leicht und eindeutig zu interpretieren ist. Die WfMC definiert Workflows wie folgt. Definition 4 (Workflow) The automation of a business process, in whole or part, during which documents, information or tasks are passed from one participant to another for action, according to a set of procedural rules. [WfM99] Da es sich in dieser Arbeit fast ausschließlich um automatisch ablaufende Prozesse handeln wird, werden oft die Begriffe Workflow und Workflowdefinition verwendet Workflow-Typen Workflows können nach ihrem Strukturierungsgrad in drei Typen unterschieden werden. Der erste Typ ist der Allgemeine Workflow oder Produktionsworkflow. Diese Workflows beschreiben vollständig strukturierte Arbeitsabläufe. Alle Arbeitsschritte sind im voraus definiert und der Nutzer hat keine Möglichkeit in die Ablaufsteuerung einzugreifen. Diese Workflows lassen sich in einem hohen Maße automatisieren. Der zweite Typ, die flexiblen Workflows, haben einen höheren Freiheitsgrad für den Nutzer. Die Nutzer haben stellenweise die Möglichkeit den Ablauf bei diesen Workflows zu beeinflussen oder auch Arbeitsabläufe zu überspringen. Die Workflows sind nicht immer vollständig strukturiert und die Arbeitsschritte sind nur teilweise im voraus definiert. Der letzte Typ sind die Ad hoc Workflows. Diese Workflows lassen sich nicht modellieren, da die Ablauffolge im voraus nicht bestimmt werden kann. Der Bearbeiter solcher Workflows besitzt sehr hohe Freiheitsgrade bei der Ablaufsteuerung. [Gad08, S. 55 ff] Phasen der Prozessmodellierung Die Prozessmodellierung kann man nach Gadatsch in drei Phasen unterteilen. Diese drei Phasen werden in Abbildung 2.2 in einem zweistufigem Life-Cycle-Modell dargestellt. Der erste Teilzyklus umfasst die Modellierung, die Analyse und die Restrukturierung von Geschäftsprozessmodellen. Dieser Zyklus besteht darin, die momentanen Prozesse einer Organisation zu modellieren und diese Modelle anhand einer Geschäftsstrategie, zu analysieren. Durch eine Restrukturierung der Geschäftsprozesse kommt es dann zur Optimierung der Prozesse. Auf die Optimierung wird im nächsten Abschnitt eingegangen. Sind die Geschäftsprozessmodelle mit der Geschäftsstrategie konform, werden diese Modelle in ihrer Struktur so weit verfeinert, bis sie die Anforderungen von Workflowmodellen entsprechen. Somit kann eine automatisierte Ausführung und Analyse auf Simulationsebene stattfinden. Die Analyse und damit einhergehende Optimierung der Workflows ist der Inhalt des zweiten Teilzyklus. Der dritte Teilzyklus besteht aus der Ausführung und der Überwachung (engl. Monitoring) der Workflows durch ein WfMS. Durch das Monitoring können wiederum Analysen im laufenden Betrieb vorgenommen werden und gegebenenfalls zum Teilzyklus eins oder zwei zurückgekehrt werden, um die Modelle zu Optimierungszwecken anzupassen. [Gad08, S. 74 ff] 8 Kapitel 2 Grundlagen

17 Monitoring Ausführung Workflowmodellierung Workflow- Optimierung Simulation und Analyse Geschäftsstrategieentwicklung Geschäftsprozeßrestrukturierung Geschäftsprozeßmodellierung Geschäftsprozeßanalyse Abbildung 2.2: Workflow-Life-Cycle-Modell, Quelle: [Gad08] Optimierung Es sollen hier zwei Methoden zur Optimierung von Geschäftsprozessen betrachtet werden. Eine Methode ist die Geschäftsprozessoptimierung. Bei diesem Verfahren wird versucht, den bestehenden Prozess laufend zu verbessern. Dies kann durch kleine Änderungen an den Geschäftsprozessen erzielt werden. Diese Methode wird meist durch eine formale und detaillierte Beschreibung durchgeführt. Sie ist somit ein Bottom-up Verfahren, da versucht wird, durch Veränderungen im Detail das große Ganze zu verändern. Die zweite Methode ist die Geschäftsprozess- Restrukturierung (engl. Business Process Reengineering). Bei dieser Methode wird ein Top-down Verfahren angewandt. Es wird also versucht, durch eine komplette Neustrukturierung der Primärprozesse, bis hin zu einer völligen Neukonzeption existierender Organisationsstrukturen, eine Verbesserung zu erzielen. Auf eine detaillierte Beschreibung der Prozesse wird dabei verzichtet. Dafür wird aber mehr Wert auf das Prozessverstehen gelegt. [Gad08, S. 11 ff] Prozessmodellierungssprachen Nach Gadatsch werden Methoden zur Modellierung von Prozessen in Kategorien 3 eingeordnet. Einerseits gibt es die Scriptbasierten Methoden und andererseits die Diagrammbasierten Methoden. [Gad08, S. 81] In den nachfolgenden Abschnitten werden einige Notationen zur Prozessmodellierung vorgestellt. Bei den ersten beiden, der hier näher beschriebenen Notationen, der XML Process Definition Language (XPDL) und der Business Process Execution Language (BPEL), handelt es sich um ausführbare Prozessbeschreibungen (engl. Process Execution Language). Sie gehören zu den Scriptbasierten Methoden, haben somit keine grafische Notation und werden von einem WfMS direkt ausgeführt. Ihre Anwendung liegt in der Ausführung automatisch ausführbarer Prozesse. [FG08] Die anderen hier vorgestellten Notationen gehören zu den Diagrammsprachen. Bei diesen Sprachen wird mehr Wert auf die Visualisierung der Geschäftsprozesse gelegt. Die 2.1 Geschäftsprozessmodellierung 9

18 Diagrammsprachen werden in datenfluss-, kontrollfluss- und objektorientierte Methoden eingeteilt. Wobei sich heutzutage hauptsächlich die kontrollflussorientierten Methoden durchgesetzt haben. Zu diesen gehören auch die in den nächsten Abschnitten vorgestellten Notationen der Ereignisgesteuerten Prozesskette (EPK), der Petri-Netze, der Business Process Model and Notation (BPMN) und der Yet Another Workflow Language (YAWL). [Gad08, S. 81] XPDL XPDL ist eine XML - basierte Ausführungssprache und die Referenzimplementierung für die Schnittstelle 1 des WfMC Referenzmodells (siehe 2.3.1). Diese Sprache basiert auf einem Metamodellansatz und unterstützt insbesondere die Interaktion zwischen Geschäftsprozessen verschiedener Teilnehmer. [Wes07] BPEL BPEL ist wie XPDL eine XML - basierte Ausführungssprache, welche zur Orchestrierung von Geschäftsprozessen, die durch einzelne Web Services implementiert sind, dient. Dabei gibt es typischerweise einen zentralen Web Service, der andere Web Services aufruft. Es kann sich sowohl um interne als auch externe Web Services handeln. Anfangs konnte BPEL nur zur Orchestrierung von Web Services genutzt werden. Später wurde eine Erweiterung mit dem Namen BPEL4People geschaffen, mit der es auch möglich ist Benutzerinteraktionen zu modellieren. [FG08] EPK In der fachlich orientierten Geschäftsprozessmodellierung wird häufig die EPK verwendet. In dieser Modellierungssprache lassen sich anschauliche und leicht verständliche Diagramme erstellen, die für technisch nicht versierte, fachliche Experten geeignet sind. Sie sind Bestandteil der Architektur integrierter Informationssysteme (ARIS). Bei einer EPK handelt es sich um einen gerichteten Graphen, mit dem Geschäftsprozessmodelle modelliert werden. Zur Modellierung eines Geschäftsprozesses werden drei Grundelemente genutzt. Ein Element sind die Funktionen, die Aktivitäten repräsentieren. Weiterhin gibt es noch Ereignisse, die eine ablaufrelevante Zustandsausprägung darstellen und zu guter Letzt Konnektoren, die einen nicht-linearen Verlauf eines Prozessmodells beschreiben. Neben diesen Grundelementen gibt es unter anderem noch eine ganze Reihe an weiteren Elementen für die Datensicht, Leistungssicht und Organisationssicht. [BKR08, S. 65 ff] In der Abbildung 2.3 ist eine exklusive Verzweigung in EPK Notation, mit allen drei Elementegruppen, zu sehen. Die EPKs haben eine sehr umfassende Notation und enthalten sowohl Konstrukte für organisatorische als auch informationstechnische Aspekte. Sie sind anwendungsübergreifend, da man sie in verschiedenen Systemen und Unternehmen erstellen, nutzen und austauschen kann. EPKs sind weit verbreitet und auch von nicht technischem Fachpersonal zu verstehen. Sie haben jedoch einen großen Nachteil. Viele Konstrukte sind nicht eindeutig spezifiziert, sodass die Nutzung dieser Modelle in einem WfMS schwierig zu realisieren ist. [All05] 10 Kapitel 2 Grundlagen

19 Abbildung 2.3: Beispiel einer exklusiven Verzweigung in einer EPK Petri-Netz Die Grundlage vieler Modellierungssprachen für Geschäftsprozesse sind von Petri- Netzen (engl. Petri nets) inspiriert. Mit Petri-Netzen ist es möglich, nebenläufige Systeme formal und grafisch darzustellen. Wobei die formale und die grafische Repräsentation von klassischen Petri-Netzen äquivalent sind, weil die Semantik von Petri-Netzen wohl definiert und eindeutig ist. Die formale Definition von Petri- Netzen lautet wie folgt: Definition 5 (Petri-Netz [Wes07]) A Petri net is a tuple (P, T, F) with a finite set P of places, a finite set T of transitions such that T P =, and a flow relation F (P T ) (T P). A place p P is an input place of a transition t T if and only if there exists a directed arc from p to t, i.e., if and only if (p, t) F. The set of input places for a transition t is denoted t. A place p is an output place of a transition t if and only if there exists a directed arc from t to p. i.e., if and only if (t, p) F. The set of output places for a transition t is denoted t. p and p denote the sets of transitions that share p as input places and output places, respectively. Um Geschäftsprozesse darstellen zu können, werden die Petri-Netze zu sogenannten Workflow-Netzen (engl. workflow nets) erweitert und abgewandelt. Im Bezug auf Petri-Netze stellen in Workflow-Netzen die Transitionen Aktivitäten dar, die Stellen repräsentieren Zustände und die Kanten stellen den Kontrollfluss dar. Außerdem wird das klassische Petri-Netz um weitere Elemente erweitert und zwar durch eine ausgezeichnete Eingabestelle i und eine ausgezeichnete Ausgabestelle o, wobei i keine eingehenden und o keine ausgehenden Kanten besitzen darf. Das Verhalten der Prozessinstanzen in Workflow-Netzen wird durch Schaltregeln repräsentiert und das Verhalten der Transitionen kann von den Werten der Eingabetoken beeinflusst werden. Die formale Definitionen von Workflow-Netzen lautet wie folgt: 2.1 Geschäftsprozessmodellierung 11

20 Definition 6 (Workflow-Netz [Wes07]) A Petri net PN = (P, T, F) is called workflow net if and only if the following conditions hold. There is a distinguished place i P (called initial place) that has no incoming edge, i.e., i =. There is a distinguished place o P (called final place) that has no outgoing edge, i.e., o =. Every place and every transition is located on a path from the initial place to the final place. Die Aktivitäten von Workflow-Netzen können durch Trigger gestartet werden. Damit wird die Interaktion mit der Umwelt modelliert. Zum Beispiel kann eine Nutzeraktion, ein externes Ereignis oder der Ablauf eines Timers notwendig sein, um eine Aktivität zu starten. Wenn kein Trigger erforderlich ist, um eine Aktivität zu starten, handelt es sich um eine automatische Aktivität. Es existieren noch zahlreiche Erweiterungen zu den Petri-Netzen, die dann mehr oder weniger in die folgenden populären Modellierungssprachen einfließen BPMN Die BPMN ist eine Spezifikation für eine formale und grafische Beschreibungssprache für Workflows. Die aktuelle Version 2.0 wurde im Januar 2011 von der Standardisierungsorganisation Object Management Group (OMG) 2 veröffentlicht. Workflows werden in der BPMN in grafischer Form als Geschäftsprozessdiagramm (GPD) dargestellt. Diese Diagramme können auch formal in einem XML - basierten Format ausgedrückt werden und somit zwischen verschiedenen Werkzeugen ausgetauscht werden. Seit der Version 2.0 ist es grundsätzlich möglich BPMN-Modelle direkt auszuführen. Man benötigt also nicht mehr den Umweg über eine Ausführungssprache, wie zum Beispiel BPEL. [All09] In GPDs gibt es vier Gruppen von Objekten. Die Flussobjekte repräsentieren die Knoten in Geschäftsprozessdiagrammen, diese Knoten können Aktivitäten, Gateways oder Ereignisse sein. Die Flussobjekte werden mit Verbindungsobjekten verknüpft, man bezeichnet diese Verbindungen als Kanten. Des Weiteren gibt es Pools und Swimlanes. Das sind Bereiche, in denen Aktoren und Systeme dargestellt werden. Dabei stellt ein Pool einen kompletten Workflow dar und Swimlanes unterteilen diesen Pool in unterschiedliche Aktoren. Alle weiteren Objekte werden als Artefakte bezeichnet, dies sind beispielsweise Datenobjekte, Gruppen oder Annotationen, die zur weiteren Dokumentation der Objekte dienen. Abbildung 2.4 zeigt ein Beispiel eines Diagramms in der BPMN Notation. [OMG11] YAWL Die YAWL ist eine, von Wil van der Aalst und Arthur ter Hofstede entwickelte, Prozessbeschreibungssprache. Inspiriert ist die Entwicklung dieser Sprache durch die Kapitel 2 Grundlagen

21 Stelle ausschreiben Fachabteilung Mitarbeiter benötigt Personalabteilung Mitarbeiterbedarf melden Stellenausschreibung verfassen Stellenausschreibung prüfen Stellenausschreibung überarbeiten Nicht okay Okay Stellenausschreibung veröffentlichen Stelle ausgeschrieben Abbildung 2.4: Beispiel eines BPMN Workflows, Quelle: [All09] mangelhafte Unterstützung von Workflow-Patterns (siehe Abschnitt 2.2) in Standards relevanter Prozessbeschreibungssprachen und theoretischen Modellen, wie beispielsweise den Petri-Netzen. [AADH04] YAWL basiert dennoch auf Petri-Netzen, bietet jedoch durch Erweiterungen die Unterstützung für alle Kontrollflussmuster an. Die Workflowbeschreibung erfolgt in XML und zum Informationsaustausch zwischen der Umgebung und der YAWL Engine werden XML-basierte Standards wie XPath und XQuery genutzt. YAWL hat eine umfangreiche Unterstützung für Kontrollfluss-, Ressourcen-, Daten- und Ausnahmebehandlungsmuster. Es erweitert Workflow-Netze mit multiplen Instanzen, zusammengesetzten Tasks, mehrfacher Vereinigung (OR Join), dem Entfernen von Tokens und mit unmittelbar miteinander verbundenen Transitionen. Im Gegensatz zu anderen Modellierungssprachen für Workflowsysteme, welche Splits und Joins über Gateways realisieren, besitzen die einzelnen Tasks in YAWL explizit ein Verzweigungs- und Vereinigungsverhalten. Eine YAWL Workflow-Spezifikation besteht aus ein oder mehreren Extended Workflow Nets (EWNs), welche wie folgt definiert sind: Definition 7 (Extended Workflow Net [Wes07]) 16 An extended workflow net is a tuple (C, i, o, T, F, split, join, rem, nofi), such that C is a set of conditions i C is the initial condition, and o C is the final condition T is a set of tasks, such that C and T are disjoint F (C {o} T ) (T C {i}) (T T ) is a flow relation, such that every node in C T is on a directed path from i to o split : T {And, Xor, Or} is a partial mapping that assigns the slit behaviour of a task join : T {And, Xor, Or} is a partial mapping that specifies the join behaviour of a task rem : T P(T C {i, o}) specifies the subnet of the extended workflow that is cleansed when the task is executed, where P(S) denotes the power set of S nofi : T N N inf N inf {dynamic, static} is a partial function that specifies the number of instances of each task (min, max, threshold for continuation, and dynamic/static creation of instances), where N inf indicates the set of natural numbers plus an infinite value symbol. Eine YAWL Workflow-Spezifikation ist daraufhin wie folgt definiert: 2.1 Geschäftsprozessmodellierung 13

22 Definition 8 (YAWL Workflow-Spezifikation [Wes07]) A YAWL workflow specification S is a tuple (Q, top, T, map), such that Q is a set of extended workflow nets top Q is the top level workflow net T = N Q T N is the set of all tasks. Conditions and tasks of all extended workflow nets are disjoint, i.e., N 1 N 2 = (C N1 T N1 ) (C N2 T N2 ) =, N 1, N 2 Q. map : T Q {top} is a function that maps each composite task onto an extended workflow net. Hence, each task t T for which map(t) is defined is a composite task. For each extended workflow net, except the top-level extended workflow net, there exists a task that maps to it, and for each extended workflow net there exists at most one task that maps to it. Bei Zustandsübergängen, sowohl zwischen den Tasks als auch innerhalb der Tasks, beim Aktivieren, Starten, Erzeugen neuer Instanzen, Fertigstellen der Ausführung und dem Beenden der Tasks werden Prädikate (bindings) definiert, die auf ihren Wahrheitswert geprüft werden. Aufgaben können in YAWL auf Web Services, externe Programme, Java Klassen oder auf Aufgabenlisten für Nutzer verweisen Vergleich Ausführungssprachen, wie XPDL und BPEL eigenen sich nicht für die Verwendung bei der Integration eines WfMS in das Intellix Framework, da mit ihnen keine grafische Bearbeitung von Prozessmodellen möglich ist. Andererseits eignen sich auch keine reinen grafischen Modellierungssprachen wie EPKs, weil diese oft nur zur Veranschaulichung der Geschäftsprozesse dienen und zur automatischen Abarbeitung zu viel Interpretationsspielraum geben. Petri-Netze haben eine eindeutige formale Beschreibung, mit der zugehörigen grafischen Repräsentation. Sie bieten die Grundlage für viele Modellierungstechniken, wie auch in der Geschäftsprozessmodellierung. Moderne Modellierungssprachen, wie BPMN und YAWL verbinden die einfache, fachspezifische Modellierung von Geschäftsprozessen mit der automatischen Ausführung der resultierenden Workflows. YAWL geht noch einen Schritt weiter und bietet zusätzlich noch die umfangreiche Unterstützung der Workflow- Patterns (siehe 2.2) an. 2.2 WORKFLOW-PATTERNS Workflow-Patterns sind, analog zu Entwurfsmustern 3 bei der Softwareentwicklung, Muster, die bei der Arbeit mit Workflows immer wieder auftreten. Sie dienen außerdem dazu, WfMS auf formal inhaltlicher Ebene zu vergleichen. Mithilfe dieser Workflow-Patterns ist es möglich, vor der Erstellung von Prozessbeschreibungen für ein bestimmtes Projekt, Anforderungen zu definieren und eine geeignete 3 Entwurfsmuster sind Beschreibungen zusammenarbeitender Objekte und Klassen, die maßgeschneidert sind, um ein allgemeines Entwurfsproblem in einem bestimmten Kontext zu lösen. [GHJJ11] 14 Kapitel 2 Grundlagen

23 Tabelle 2.1: Vergleich möglicher Modellierungssprachen Eigenschaften XPDL BPEL EPK Petri-Netz BPMN YAWL XML Beschreibung Grafische Bearbeitung Weitreichende Unterstützung von Workflow-Patterns Webservice Integration Aufruf externer Applikationen + Unterstützung - keine Unterstützung Prozessbeschreibungssprache sowie ein geeignetes WfMS zu ermitteln. Van der Aalst, ter Hofstede, Kiepuszewski und Barros unterteilen diese Muster in vier unterschiedliche Perspektiven. Die Kontrollfluss-Perspektive beschreibt Aktivitäten und die Ordnung ihrer Ausführungen von unterschiedlichen Instanzen. Die Daten- Perspektive bringt Geschäfts- und Prozessdaten auf die Kontrollebene. Geschäftsdokumente, Objekte welche sich zwischen Aktivitäten von Prozessen bewegen und Variablen die Vor- und Nachbedingungen von Ausführungen steuern, werden über die Daten-Perspektive beschrieben. Die Ressourcen-Perspektive kümmert sich um das Verhalten und die Verantwortlichkeiten von menschlichen und computergestützten Aufgaben. Die Operations-Perspektive beschreibt die elementaren Operationen, die von Aktivitäten ausgeführt werden. In dieser Perspektive wird die Abbildung von Aktionen auf die darunterliegenden Anwendungen beschrieben. Bei den Workflow-Patterns wird das Hauptaugenmerk auf die Kontrollfluss- Perspektive gelegt. Die nachfolgenden Abschnitte beschreiben die grundlegenden Kontrollflussmuster. Darüber hinaus gibt es noch 15 weitere Kontrollflussmuster. [AHKB03] Basis Kontrollflussmuster Die grundlegenden Kontrollflussmuster stimmen weitestgehend mit den elementaren Kontrollflusskonzepten der WfMC überein und werden prinzipiell von allen WfMS unterstützt. [WfM99] Sequenz Eine Sequenz ist gegeben, wenn eine Aktivität durch das Beenden einer anderen Aktivität aktiviert wird. Die Sequenz wird üblicherweise mit einem unbedingten Pfeil zwischen zwei Aktivitäten dargestellt. Abbildung 2.5 zeigt eine Sequenz in der BPMN Notation. 2.2 Workflow-Patterns 15

24 A B Paralleler Ablauf Abbildung 2.5: Eine Sequenz in BPMN Notation Ein paralleler Ablauf unterteilt sich in zwei Muster, der Parallelen Verzweigung (AND-Split) und der Synchronisation (AND-Join). Eine parallele Verzweigung liegt vor, wenn an einer Stelle im Workflow ein einzelner Thread in mehrere parallele Threads aufgeteilt wird. Wenn diese parallelen Threads wieder zu einem Thread zusammengeführt werden ist das eine Synchronisation. Parallele Verzweigungen werden entweder durch einen speziellen Knoten repräsentiert, welcher mehr als eine ausgehende Transitionen besitzen kann (explizite parallele Verzweigung), oder es können mehrere ausgehende Transitionen an eine Aktivität modelliert werden (implizite parallele Verzweigung). Analog dazu wird die Synchronisation entweder durch eine explizite oder durch eine implizite Modellierung umgesetzt. Abbildung 2.6 zeigt einen parallelen Ablauf in BPMN Notation. In der BPMN Notation wird dieses Muster explizit dargestellt. Der Knoten, der die parallele Verzweigung wie auch die Synchronisation darstellt, ist ein paralleles Gateway. B A D C Abbildung 2.6: Ein paralleler Ablauf in BPMN Notation Bedingter Ablauf Ein bedingter Ablauf unterteilt sich, wie beim parallelen Ablauf, in zwei Muster, der Bedingten Auswahl (XOR-Split) und der Einfachen Zusammenführung (XOR-Merge). Bei der bedingten Auswahl wird in Abhängigkeit einer Bedingung eine von mehreren Verzweigungen ausgewählt. Bei der einfachen Zusammenführung werden zwei oder mehr Transitionen zu einer einzelnen zusammengeführt, wobei keine der Transitionen durch eine parallele Verzweigung entstanden sein darf. Die Darstellung wird analog zum parallelen Ablauf entweder explizit oder implizit modelliert. Abbildung 2.7 zeigt einen bedingten Ablauf in der BPMN Notation. Wie auch bei dem parallelen Ablauf wird dieses Muster in der BPMN Notation explizit dargestellt. Der Knoten, der die bedingte Auswahl wie auch die einfache Zusammenführung darstellt, ist ein exklusives Gateway. 2.3 WORKFLOW-MANAGEMENT WfMS unterstützen die Handhabung mit Workflows auf drei funktionalen Ebenen. Erstens unterstützen sie den Anwender beim Design und der Modellierung von 16 Kapitel 2 Grundlagen

25 B A D C Abbildung 2.7: Ein bedingter Ablauf in BPMN Notation Workflowdefinitionen. Zweitens gibt es ein Steuerungssystem, das zur Laufzeit die Prozessinstanzen (engl. Process Instances) aus den Prozessdefinitionen heraus instanziiert und steuert. Zu guter Letzt überwacht das WfMS die Interaktion mit menschlichen Nutzern bei manuellen Aktivitäten und die Abarbeitung externer Applikationen bei automatischen Aktivitäten. Die WfMC definiert ein WfMS wie folgt. Definition 9 (Workflow-Management-System [WfM99]) A system that defines, creates and manages the execution of workflows through the use of software, running on one or more workflow engines, which is able to interpret the process definition, interact with workflow participants and, where required, invoke the use of IT tools and applications. Für die Modellierung von Workflowdefinitionen bieten WfMS meist einen Editor an, mit dem Prozessmodelle erstellt werden können. Zusätzlich existiert meist ein Modell Repository, welches die Workflowdefinitionen speichert und der Laufzeitumgebung (engl. Workflow Enactment Service) zur Verfügung stellt. Die Laufzeitumgebung besteht aus einer oder mehreren Workflow Engines. Eine Workflow Engine wiederum ist eine Software, die Prozessdefinitionen interpretiert, die daraus resultierten Prozessinstanzen erzeugt, ausführt und terminiert WfMC Referenzmodell Die im letzten Abschnitt genannten Komponenten eines WfMS werden in einem Referenzmodell der WfMC zusammengefasst. Zusätzlich definiert dieses Modell Schnittstellen (engl. Interfaces), über die die Komponenten mit der Laufzeitumgebung des WfMS interagieren. Abbildung 2.8 zeigt dieses Referenzmodell. Die Schnittstelle 1 kümmert sich um den Austausch der Prozessdefinitionen von einem Editor zur Laufzeitumgebung des WfMS. Das Austauschformat für die Prozessdefinitionen ist in der Programmierschnittstelle (API) des WfMS definiert. Das heißt, dass entweder für die Prozessdefinitionen eine Modellierungssprache genutzt wird, die vom WfMS direkt unterstützt wird oder es wird eine Ausführungssprache, wie XPDL oder BPEL genutzt. Die Schnittstelle 2 verbindet die Laufzeitumgebung mit Client Anwendungen. Diese Anwendungen können den Ablauf von Workflows steuern. Beispielsweise werden manuelle Aktivitäten in Applikationen durchgeführt, die über diese Schnittstelle mit der Laufzeitumgebung in Verbindung stehen. Über die Schnittstelle 3 werden externe Applikationen aufgerufen, die für automatische Aktivitäten genutzt werden. Die Schnittstelle 4 definiert die Zusammenarbeit mit anderen Laufzeitumgebungen und Workflow Engines. Die Administration und Überwachung der Laufzeitumgebung mittels Kontrollwerkzeugen 2.3 Workflow-Management 17

26 Process Definition Tools Administration & Monitoring Tools Interface 5 Interface 1 Workflow API and Interchange formats Workflow Enactment Service Workflow Engine(s) Interface 4 Other Workflow Enactment Service(s) Workflow Engine(s) Interface 2 Interface 3 Workflow Client Applications Invoked Applications Abbildung 2.8: Das WfMC Referenzmodell, Quelle: [WfM99] (engl. Monitoring Tools) wird über die Schnittstelle 5 definiert. Diese Kontrollwerkzeuge sollen Möglichkeiten bieten, die laufenden Prozessinstanzen zu überwachen und gegebenenfalls manuell zu steuern Workflow-Management-Systeme In diesem Abschnitt wird es eine Einführung zu konkreten WfMS geben, welche später in der Analyse, im Hinblick auf die Adaptierbarkeit zum Intellix Framework, genauer untersucht werden. Alle hier vorgestellten Systeme basieren auf Java jbpm jbpm ist eine Business Process Management (BPM) Plattform 4, welche sich sowohl an Entwickler als auch an Anwender im Bereich Prozess Management richtet und ist unter der Lesser GPL 5 lizenziert. Die neueste Version jbpm 5 unterstützt die Modellierungssprache BPMN 2.0. Für Entwickler stehen Eclipse Plugins bereit, mit denen Workflows erstellt, getestet und nach Fehlern untersucht werden können. Zusätzlich existiert ein browserbasierter Editor namens Oryx Designer, mit dem BPMN 2.0 Prozessbeschreibungen erstellt, verändert und getestet werden können. Der browserbasierte Editor richtet sich eher an Anwender der jbpm Plattform. Mittels jbpm ist es möglich, sowohl manuelle, als auch automatische Aktivitäten zu modellieren. Die automatischen Aktivitäten werden entweder durch hinterlegte Scripte oder durch den Aufruf externer Applikationen ermöglicht. [Com11] GNU Lesser General Public License 18 Kapitel 2 Grundlagen

27 Activiti BPM Plattform Die Activiti BPM Plattform 6 ist ein leichtgewichtiges WfMS, welche sich an Anwender, Entwickler und Administratoren gleichzeitig richtet. Der Quelltext dieses WfMS steht unter der Apache V2 Lizenz. Für alle drei funktionalen Ebenen des Workflow-Managements wird in der Activiti Plattform, wie in Abbildung 2.9 zu sehen ist, ein eigenständiges, zweckgebundenes Werkzeug angeboten. Abbildung 2.9: Übersicht der Komponenten in Activiti, Quelle:[Act11a] Mit dem Activiti Modeler oder dem Activiti Designer ist es möglich BPMN 2.0 Diagramme zu entwickeln und im Model Repository abzulegen. Der Activiti Explorer dient der Aufgabenverwaltung von manuellen Aktivitäten. Der Activiti Probe richtet sich an Administratoren, die mit diesem Werkzeug die Activiti Engine überwachen, Prozessdefinitionen und -instanzen einsehen und verwalten können. Außerdem gibt es noch ein Kollaborationswerkzeug, namens Activiti Cycle, welches die Zusammenarbeit bei der Entwicklung von Geschäftsprozessen zwischen Anwendern, Entwicklern und Administratoren unterstützt. Bis auf den Activiti Designer sind alle Werkzeuge Web Anwendungen. Der Activiti Designer ist ein Eclipse Plugin und basiert auf dem Eclipse Modelling Framework (EMF). Mit diesem Modellierungswerkzeug ist es möglich BPMN 2.0 Diagramme zu erstellen und in XML- Beschreibungen zu exportieren. [Act11b] UIMA Die automatische Anreicherung von semi- und unstrukturierten Informationen mit Metadaten nennt man Unstructured Information Management (UIM). Diese Metadaten helfen bei der Verwendung dieser Informationen. Dabei werden meist Workflow-Management 19

28 strukturierte Daten aus semi- und unstrukturierten Informationen gewonnen. UIM Anwendungen können verschiedene Technologien im Bereich Information Retrieval und Machine Learning unterstützen. Die Unstructured Information Management Architecture (UIMA) bietet ein Framework, Komponenten und Infrastruktur für die Entwicklung von UIM Anwendungen an. Das Framework ist als Java und als C++ Version verfügbar und steht unter der Apache Lizenz. Es bietet eigenständige, wieder verwertbare Komponenten für Teilaufgaben wie die Named Entity Recognition (NER), Klassifikation, Indexierung mittels regulären Ausdrücken, lexikalische Analyse und viele mehr. Die Architektur des UIMA Frameworks bietet die Möglichkeit diese einzelnen Komponenten zusammen zu schalten und organisiert den Datenaustausch zwischen diesen Komponenten. Außerdem ist es möglich, Komponenten in einer Reihenschaltung, zu einer Verarbeitungspipeline zu verbinden. Mithilfe dieser Verarbeitungspipelines kann ein kontrollflussbasierter Workflow aufgebaut werden. [Uim09] KNIME Der Konstanz Information Miner (KNIME) ist ein modular aufgebautes WfMS zur Datenanalyse und -visualisierung. KNIME besteht aus mehreren Eclipse Plugins und steht unter der GNU Public License (GPL) Version 3. Es bietet eine Vielzahl von Modulen zur Visualisierung von Ein- und Ausgabedaten, sowie zur Datenverarbeitung. Diese Module lassen sich in einem Kontrollflussdiagramm zu einem Workflow zusammenfügen. Außerdem besitzt KNIME eine API um dem System eigene Komponenten hinzufügen zu können. Die KNIME GmbH bietet eine Oberfläche namens KNIME Desktop an, wobei es sich um eine modifizierte Version der Entwicklungsumgebung Eclipse handelt. Für die Modellierung der Workflows wird eine proprietäre Modellierungssprache verwendet. Dies hat zur Folge, dass die Prozessbeschreibungen nur zwischen unterschiedlichen KNIME Installationen ausgetauscht werden können YAWL Software Framework Das YAWL-Software-Framework ist ein Open-Source Workflowsystem, welches eine Arbeitsablaufumgebung, einen grafischen Editor und einen Worklist-Handler beinhaltet. Wie man aus dem Namen heraus erkennen kann, nutzt dieses Framework die im Abschnitt vorgestellte Modellierungssprache YAWL und implementiert somit eine Vielzahl der von der Workflow-Patterns-Initiative 7 spezifizierten Workflow-Patterns (siehe 2.2). In den folgenden Abschnitten wird die Funktionsweise des YAWL Editors erläutert, weil dieser für die Erstellung der Extraktionspläne für das Intellix Framework genutzt werden kann. Außerdem werden die Custom Services erläutert, weil diese Technik für den Aufruf externer Anwendungen genutzt werden kann Kapitel 2 Grundlagen

29 YAWL Editor In YAWL besteht ein atomarer Task aus genau einer Aktion, die zum Beispiel eine externe Anwendung aufruft oder auf eine manuelle Informationseingabe wartet. Ein atomarer Task wird im YAWL Editor als Dekomposition angelegt. In diesen Dekompositionen können Eingangs- und Ausgangsparameter definiert werden. Eingangsparameter bezieht der Task vom sogenannten Netz, und Ausgangsparameter sendet ein Task wiederum an das Netz. Die Netze stellen Prozesse oder Unterprozesse dar. Die Parameter, wie auch die Zusammenhänge zwischen Netz- und Task-Parametern, werden über XPath Ausdrücke in XML - Dokumenten beschrieben. [Ada11] YAWL Custom Service Jeder atomare Task ist mit einem sogenannten Custom Service verbunden. Ein Custom Service wird entweder durch einen Web Service oder ein Worklet Service repräsentiert. Wenn für einen Task kein spezieller Custom Service ausgewählt wurde, erhält dieser implizit den vordefinierten Default Worklist Handler. Custom Services interagieren mit der YAWL Engine, nachdem sie in dieser Engine registriert wurden, über eine Representational State Transfer (REST) basierte Schnittstelle. Der Service erhält eine Nachricht, wenn ein Element auf den Zustand aktiv gesetzt wurde und kann dann dieses Element aus der Engine entnehmen. Ist die Abarbeitung beendet, überträgt der Service das Element wieder zurück zur YAWL Engine und diese setzt den Status des Elements auf beendet. [Ada10] Fazit Die hier vorgestellten WfMS sind alle frei verfügbar und Open Source. Die nachfolgende Tabelle 2.2 gibt noch einmal einen Überblick der spezifischen Merkmale der unterschiedlichen Systeme. Eine detailiertere Analyse der Funktionalitäten dieser Systme folgt im Kapitel 3. Tabelle 2.2: Vergleich möglicher Workflow-Management-Systeme Eigenschaften jbpm 5 Activiti UIMA KNIME YAWL Werkzeuge für Entwickler Werkzeuge für Anwender Unabhängige Prozess Engine Grafische Modellierung XML Export Modellierungssprache BPMN 2 BPMN 2 - proprietär YAWL Aufruf externer Komponenten + vorhanden - nicht vorhanden Workflow-Management 21

30 2.4 INTELLIX Das Forschungsprojekt Intellix hat die Zielsetzung, manuelle Indexierung von geschäftsbezogenen Dokumenten teilweise mittels automatischen Klassifizierungsund Indexierungsmechanismen abzulösen. Ein Teil dieses Projekts ist die Entwicklung eines generisch konfigurierbaren Extraktionsframeworks, das Methoden für die Dokumenttypklassifikation und Indexdatenextraktion für Geschäftsdokumente bereitstellt. [BSS10] In den folgenden Abschnitten werden die aktuell vorhandenen Methoden zur Ermittlung der Dokumenttypen durch Klassifikationsalgorithmen, sowie der Extraktion von Indexdaten durch Extraktionsalgorithmen vorgestellt. Darüber hinaus wird auf die Feedbackverarbeitung des Intellix Frameworks eingegangen Dokumenttypklassifikation Durch die Ermittlung des Dokumenttyps eines bis dato unbekannten Dokuments, können sowohl die klassischen Anwendungen des Information Retrievals, sowie die Indexdatenextraktion unterstützt werden. Die Indexdatenextraktion kann dahin gehend unterstützt werden, indem schon vor der Anwendung geeigneter Extraktionsalgorithmen festgelegt werden kann, welche Indexdaten überhaupt extrahiert werden sollen. Die Dokumenttypklassifikation wird mittels geeigneter Klassifikationsverfahren durchgeführt. Die Klassifikation ist ein maschinelles Lernverfahren, welches Objekte automatisch in eine vordefinierte Menge an Klassen einordet. Bei der Klassifikation von Dokumenten unterscheidet man zwischen der Textklassifikation und dem Textclustering. Bei der Textklassifikation werden Dokumente in vorgegebene Klassen eingeordet und beim Textclustering werden die Dokumente selbstständig gruppiert. [MRS09] Die Methoden zur Dokumenttypklassifikation im Intellix Framework nutzen die Textklassifikation um den Dokumenttyp unbekannter Dokumente zu ermitteln. Abbildung 2.10 zeigt den grundsätzlichen Aufbau einer Textklassifikation. Trainingsdaten inkl. zugehöriger Kategorien Maschinelles Lernverfahren Testdaten Klassifikationsfunktion Richtig klassifizierte Dokumente Falsch klassifizierte Dokumente Abbildung 2.10: Vorgehen Textklassifikation, Quelle: [Ess10] Es handelt sich hier um ein überwachtes Lernverfahren, weil zum Trainieren des Klassifikators Trainingsdaten benötigt werden, welche den zu extrahierenden Dokumenttyp schon beinhalten. Mittels dieser Trainingsdaten wird durch ein maschinelles Lernverfahren eine Klassifikationsfunktion aufgebaut. Auch während der Extraktionsphase kann der Klassifikator noch trainiert werden, indem falsch oder nicht 22 Kapitel 2 Grundlagen

31 klassifizierte Dokumente manuell bestimmt werden und die Klassifikationsfunktion neu berechnet wird. Die Textklassifikation arbeitet typischerweise auf einer Menge von Dokumenten D = {d 1, d 2,..., d n } und einer Menge von Klassen C = {c 1, c 2,..., c n }. Des weiteren gibt es einen Merkmalsvektor X d = (x 1 x 2... x n ) T, der die verschiedenen Merkmale des jeweiligen Dokumentes d beschreibt. Durch die manuelle Zuordnung von Merkmalen und Klassen zu den Dokumenten der Trainingsmenge entsteht eine Klassifikationsfunktion, welche den Merkmalsvektor auf die Klassen abbildet: γ : X C (2.1) Ein Dokument, welches nicht in der Trainingsmenge enthalten ist, kann nun mittels dieser Funktion einer Klasse zugeordnet werden. [MRS09] Da im Intellix Framework Geschäftsdokumente verarbeitet werden, handelt es sich bei diesen Klassen um den Dokumenttyp. Klassische Beispiele für Geschäftsdokumenttypen sind unter anderem Rechnungen, Lieferscheine und Mahnungen. Diese Klassenmenge kann aber auch auf s, Reisekostenabrechnungen, Leistungsnachweise und Ähnlichem erweitert werden k-nearest-neighbor Klassifikator Der k-nearest-neighbor (KNN) Algorithmus ist ein Klassifikationsverfahren, bei dem die Zuordnung zu einer Klasse über den Abstand zu den k nächsten Nachbarn berechnet wird, wobei die Abstandsfunktion nicht festgelegt ist. Wird k gleich 1 festgelegt, entsteht in einem Vektorraum ein sogenanntes Voronoi-Mosaik. In jeder Voronoi-Zelle stellt das Zentrum ein Dokument dar. Der Abstand aller Punkte in dieser Zelle zu diesem Dokument ist kleiner als zu jedem anderen Dokument. Um einer Menge von gleichen Dokumenttypen existiert zusätzlich noch eine Entscheidungsgrenze. Abbildung 2.11 zeigt ein Voronoi-Mosaik mit Entscheidungsgrenzen (doppelte Linien) in einer KNN Klassifikation mit k = 1 und drei Klassen. [MRS09, S. 297] Naive Bayes Klassifikator Um einen Klassifikator mittels eines Naive Bayes Algorithmus anzulernen, wird ein Merkmalsvektor benötigt. Dieser Merkmalsvektor wird mittels spezieller Wörter, wie zum Beispiel Fett und Kursiv gedruckten, aus den Trainingsdaten generiert. Bei der Anwendung des angelernten Klassifikators, also der Ermittlung des Dokumenttyps eines Dokuments, wird der generierte Merkmalsvektor auf die Wörter des Dokuments angewendet und somit der Dokumenttyp mit der höchsten Trefferwahrscheinlichkeit ermittelt. Die Grundlage zum Naive Bayes Klassifikator ist der Satz von Bayes, dieser lautet für zwei Zufallsereignisse A und B wie folgt: P(A B) = P(B A) P(A) P(B) (2.2) 2.4 Intellix 23

32 x x x x x x x x x x x Abbildung 2.11: Voronoi-Mosaik, Quelle: [MRS09] Beim Naive Bayes ist das Ereignis A der Merkmalsvektor und B die Zugehörigkeit eines Objekts zu einer Klasse. In diesem Fall ist das Objekt ein Dokument und die Menge der Klassen alle Dokumenttypen. [MRS09, S. 258 ff] Der Begriff naive im Namen des Klassifikators kommt daher, weil alle Merkmale des Merkmalsvektors konditional voneinander unabhängig sind. Diese Eigenschaft ist zwar bei natürlichsprachlichen Text ungünstig, weil in diesem normalerweise syntaktische, semantische und thematische Abhängigkeiten bestehen, dennoch liefert der Naive Bayes Klassifikator auch dort gute Ergebnisse. [FGG97] Indexdatenextraktion Die Indexdatenextraktion, das Kernstück des Intellix Frameworks, hat zur Aufgabe, möglichst genau relevante Informationen aus unstrukturierten Geschäftsdokumenten zu extrahieren. Durch das Abspeichern dieser Informationen wird ein schnelles Wiederfinden von Dokumenten aus großen Dokumentenbasen erst möglich. Je nach Dokumenttyp (siehe 2.4.1) werden unterschiedliche Indexdaten extrahiert, weil nicht alle Indexdaten in jedem Dokumenttyp vorkommen können. Beispielsweise befindet sich in einer selten ein Geldbetrag, dagegen sollte eine Rechnung immer einen Geldbetrag enthalten. Bei der Wahl der Indizes versucht man möglichst eindeutige Zeichenketten des Textes im Dokument auszuwählen, wie zum Beispiel ein Datum, eine Adresse oder eine Kennnummer. Genau wie bei der Dokumenttypklassifikation werden durch bereits manuell indexierte Dokumente selbstlernende Algorithmen trainiert. Alternativ wird bei der Indexdatenextraktion auch durch definierte Regeln versucht, Indexdaten aus Geschäftsdokumenten zu extrahieren. Die folgenden Abschnitte beschreiben die zurzeit implementierten Extraktionsalgorithmen im Intellix Framework. 24 Kapitel 2 Grundlagen

33 Layoutbasierte Extraktion Die layoutbasierte Indexdatenextraktion verwendet Positionsdaten als Merkmale um Indexdaten in einem Dokument zu ermitteln. Auf der Domäne von Geschäftsdokumenten eignet sich dieser Algorithmus sehr gut, da diese Art von Dokumenten meist durch Vorlagen generiert sind. Relevante Informationen befinden sich somit oft an ähnlichen Positionen im Dokument. Die Arbeitsweise des layoutbasierten Extraktionsalgorithmus teilt sich in zwei Einzelschritte, der Template-Erkennung und der eigentlichen Indexdatenextraktion. Bei der Template-Erkennung wird eine Clusteranalyse durchgeführt, welche Trainingsdokumente in Gruppen ähnlicher Dokumente zusammenfasst. Bei dem darauf folgenden Anlernen des Klassifikators für die Indexdatenextraktion werden die Dokumente in den zuvor eingeteilten Gruppen verarbeitet. Somit werden für jede Dokumentvorlage eigene Extraktionsregeln erstellt. [UEE11, S.8 ff] Textbasierte Extraktion Die textbasierte Extraktion basiert auf einem Wörterbuchansatz ähnlich dem des Naive Bayes Algorithmus. Dieses Wörterbuch wird in der Trainingsphase erstellt und besteht aus n-grammen mit dazugehörigen Wahrscheinlichkeiten für die Indexfelder. Die Wahrscheinlichkeiten für die Zugehörigkeit der n-gramme zu einem Indexfeld wird in der Extraktionsphase wie folgt berechnet: P(Indexfeld, Kandidat) = #ngrams n=1 (relevanz (n, indexfeld)) (2.3) Nach dieser Berechnung wird das Indexfeld mit der höchsten Wahrscheinlichkeit dem Kandidaten zugewiesen. [UEE11, S.7 f] Regelbasierte Extraktion Beim regelbasierten Verfahren werden vordefinierte Regeln, wie beispielsweise reguläre Ausdrücke oder die Anzahl von Wörtern eines Terms genutzt um Indexdaten aus Dokumenten zu extrahieren. Im Gegensatz zu den selbstlernenden Algorithmen steht bei diesem Verfahren das Extraktionsmodell von Anfang an fest und es bedarf keiner Trainingsdatenmenge. Die Regeln sind über ein Editor erweiterbar. Somit ist es möglich die Extraktionsregeln auf bestimmte Domänen anzupassen und dadurch die Extraktionsergebnisse dieses Verfahrens zu verbessern. Die vordefinierten Extraktionsregeln basieren auf Dokumenttypen und der Sprache des Dokuments. Abbildung 2.12 zeigt schematisch die Vorbedingungen für eine regelbasierte Indexdatenextraktion. Das Dokument muss im Intellix Austauschformat vorliegen, damit der regelbasierte Extraktor die Extraktionsregeln anwenden kann. Weiterhin wird noch der Dokumenttyp und die Sprache des Dokuments aus dem Dokument-Objekt ausgelesen. Existiert kein Dokumenttyp soll der Extraktor versuchen alle definierten Indexdaten zu extrahieren. Ist keine Sprache des Dokuments festgelegt, werden nur sprachunabhängige Regeln für die Indexdatenextraktion verwendet. 2.4 Intellix 25

34 Dokumentenklasse Extraktionsregeln, basierend auf Dokumentenklasse und -sprache, werden einer XML-Datei entnommen Dokument Dokumentensprache Regeln Indexdatenextraktion Intellix Austauschformat Abbildung 2.12: Aufbau der regelbasierten Indexdatenextraktion Feedbackintegration Der Feedbackmechanismus ist ein wichtiger Bestandteil des Intellix Systems und wird benötigt, weil man nicht davon ausgehen kann, dass die Dokumenttypklassifikation und die Indexdatenextraktion immer die korrekten Ergebnisse liefern. Der Nutzer eines Intellix Systems hat die Möglichkeit, nach der Ermittlung des Dokumenttyps beziehungsweise der Indexdaten die Ergebnisse der Klassifikation respektive der Extraktion zu verifizieren und gegebenenfalls zu korrigieren. Erst durch die Verifikation eines extrahierten Datums durch den Nutzer, wird dieses Datum als gültiges Datum (engl. valid data) mit dem Dokument verknüpft. Auf Komponentenebene im Intellix Framework unterteilt sich die Feedbackverarbeitung in drei Arten von Komponenten, der Feedbackanalyse, der eigentlichen Feedbackverarbeitung und der Reduzierung der Daten in den Klassifikatoren. In den folgenden Abschnitten wird der gesamte Ablauf eines Feedbackprozesses anhand dieser Komponentenaufteilung erläutert. Feedbackanalyse Die Feedbackanalyse wird für jeden Klassifikator einzeln durchgeführt. Die Analyse gruppiert die Extraktionsfehler, indem die gültigen Indexdaten mit den Extraktionsdaten des Klassifikators verglichen und in vordefinierte Gruppen eingeordnet werden. Diese Analyseergebnisse werden dann im Modell des jeweiligen Klassifikators gespeichert. Klassifikatoranpassung durch Feedback Die Analyseergebnisse werden nun verarbeitet, indem die Klassifikatoren mittels dieser Daten angepasst werden. Datenreduzierung Weil stellenweise die kompletten Dokumente im Modell der Klassifikatoren gespeichert werden, sollten nach der Klassifikatoranpassung nicht mehr benötigte Dokumente aus dem Modell entfernt werden. Dieses Verfahren stellt ein probates Mittel dar, um der Überanpassung eines Klassifikators entgegen zu wirken. 26 Kapitel 2 Grundlagen

35 2.5 MENSCH-COMPUTER-INTERAKTION Interaktionssysteme werden hinsichtlich ihrer Effektivität, Effizienz und Akzeptanz verglichen. Effektivität ist die Genauigkeit und Vollständigkeit, mit der ein Benutzer bestimmte Ziele und Teilziele erreichen kann. Die Effizienz beschreibt das Verhältnis von der Effektivität zum Aufwand, wie zum Beispiel die physische Beanspruchung, benötigte Zeit oder Materialkosten. Die Akzeptanz wiederum unterscheidet sich in objektiv erfassbares Nutzerverhalten (Häufigkeit der Nutzung oder Kauf eines Produkts) und subjektive Reaktion des Nutzers (Zufriedenheit mit dem Produkt). Die subjektive Akzeptanz lässt sich unter anderem mit Fragebögen ermitteln. Dieser Fragebogen sollte messen, ob das Interaktionssystem als hilfreich und vernünftig angesehen wird. [Kra08, S. 110 ff] Methoden LaLomia und Sidowsky [Lal90] unterteilen die Evaluation von Computersystemen in zwei Bereiche, die Nutzerzufriedenheit und die Fähigkeit des Computersystems. In den folgenden Abschnitten wird detailierter auf den Unterschied zwischen subjektiv und objektiv erfassbaren Aspekten detaillierter eingegangen. Subjektiv erfassbare Aspekte Subjektiv erfassbare Aspekte können aus der Akzeptanz oder der sozialen Wirkung gewonnen werden. Die subjektive Akzeptanz des Nutzers kann allgemein durch einen Fragebogen erfasst werden. In diesem Fragebogen können Fragen nach der Kaufentscheidung beziehungsweise nach dem Betrag, der für solch ein Produkt ausgegeben werden würde, enthalten sein. Außerdem könnte das Erscheinungsbild und die Funktionalität des Produktes bewertet werden. Es sind auch Fragen nach ganz subjektiven Empfindungen möglich, wie beispielsweise nach der empfundenen Effizienz, dem eigenen Umgang mit dem Produkt oder dem Vertrauen in das System. Objektiv erfassbare Aspekte Objektiv erfassbare Aspekte können sowohl aus der Akzeptanz, Effektivität und Effizienz gewonnen werden. Die Akzeptanz kann durch das Wahlverhalten des Nutzers (zum Beispiel die Entscheidung für oder gegen eine bestimmte Eigenschaft des Produkts) oder durch psychophysiologische Messungen bestimmt werden. Die Effektivität und Effizienz kann durch die Merkleistung, die Performanz und Aufgabenbewältigung oder durch Messungen der Kaufentscheidung bezüglich der Effizienz als Werbeträger ermittelt werden. Das Verhalten des Nutzers kann beispielsweise durch den Einsatz natürlicher Sprache im Umgang mit dem Produkt oder durch das Registrieren der Aufmerksamkeit gemessen werden. Subjektive und objektive Aspekte sollten parallel erfasst werden, da sich gezeigt hat, dass subjektive und objektive Maße des gleichen Aspekts stark voneinander abweichen können. 2.5 Mensch-Computer-Interaktion 27

36 2.5.2 User Experience Fragebogen Mit dem User Experience Fragebogen (UEQ) wurde von Laugwitz, Schrepp und Held [LSH06] ein Fragebogen entwickelt, welcher eine schnelle Messung verschiedener Kriterien der Softwarequalität erlaubt. Bei der Entwicklung dieses Fragebogens wurde Wert auf eine schnelle Erhebung, einen umfassenden Gesamteindruck und auf Direktheit und Einfachheit gelegt. Er umfasst 26 Items und die Darstellung erfolgt in Form eines siebenstufigen semantischen Differenzials. Die Items sind ausnahmslos Adjektive und können in sechs verschiedene Skalen eingeordnet werden. Sechs der Items gehören zur Skala Attraktivität und jeweils vier Items können den Skalen Durchschaubarkeit, Effizienz, Vorhersagbarkeit, Stimulation und Originalität zugeordnet werden. Diese sechs Skalen können wiederum in drei Oberkategorien unterteilt werden. Durchschaubarkeit, Effizienz und Vorhersehbarkeit wären dabei pragmatische Qualitätsaspekte, welche eine Aussage darüber treffen, ob der Nutzer in der Lage ist sein Zeil effektiv und effizient zu erreichen. Stimulation und Originalität sind den hedonistischen Qualitätsaspekten zuzuordnen, welche eher auf Eigenschaften abzielen, die nicht primär aufgabenbezogen sind. Die dritte Kategorie ist die verbleibende Skala, welche direkt die Attraktivität der Software messen soll. 28 Kapitel 2 Grundlagen

37 3 ANALYSE Das Intellix System soll mittelgroße bis große Unternehmen dabei unterstützen, Dokumente in ein Dokumenten Management System (DMS) einzupflegen und durchsuchbar zu machen. Zentrale Bestandteile des Intellix Frameworks sind unter anderen die Dokumenttyp Klassifikation, Indexdatenextraktion und Feedbackverarbeitung. Diese Vorgänge können mittels verschiedener Algorithmen oder Verfahrensweisen durchgeführt werden. Damit es möglich wird, Algorithmen auszutauschen oder den Arbeitsablauf zu Optimierungszwecken zu verändern, sind die Arbeitsabläufe in Teilaufgaben unterteilt. Im Intellix Framework sind diese Aufgaben Komponenten, welche einzelne Aufgaben in Klassen kapseln. Die Komponenten werden innerhalb von Workflows verarbeitet. Diese Workflows kann man, wie im Abschnitt gezeigt wird, statisch im Quelltext definieren und steuern. Wenn das Intellix System in einem Unternehmen installiert ist, ist dieser Weg der Bearbeitung oder Erstellung von Workflows zu umständlich, weil dafür einerseits der Quelltext des Frameworks verfügbar sein muss und andererseits alle Veränderungen eines Workflows in einer Java Klasse durchgeführt werden müssen. Das Problem daran ist, dass das Definieren von Workflows in einer Java Klasse unübersichtlich und nicht intuitiv ist, im Gegensatz zum Modellieren von Workflows als Prozessdiagramm mittels einer grafischen Spezifikationssprache. In diesem Kapitel werden zunächst im Abschnitt 3.1 die Komponenten des Intellix Frameworks beschrieben und das Verfahren, Workflows im Quelltext des Frameworks zu definieren und auszuführen, erläutert. Danach wird im Abschnitt 3.2 versucht, die Zielgruppe einzugrenzen, welche im Betrieb eines Intellix Systems Umstrukturierungen und Optimierungen an Workflows vornehmen wird. Daraufhin werden im Abschnitt 3.3 Anforderungen erstellt, welche ein Softwareprodukt erfüllen muss, damit die beschriebene Zielgruppe möglichst einfach und übersichtlich Workflows erstellen und bearbeiten kann. Am Ende werden im Abschnitt 3.4 unterschiedliche Möglichkeiten diskutiert, die Anforderungen mittels eines Workflow Management Sys\-tem (WfMS) umzusetzen. 3.1 STAND DER TECHNIK Abbildung 3.1 zeigt einen typischen Intellix Extraktionsvorgang als Aktivitätendiagramm. 29

38 KNN Klassifikation Regelbasierte Extraktion Coloniale Extraktion Modellraum wechseln Ergebnisse validieren Egebnisse kombinieren Abbildung 3.1: Typischer Verlauf einer Extraktion im Intellix System Die Anwendungsfälle in dieser Darstellung entsprechen der Ausführungslogik im Intellix Framework und sind, bis auf das Wechseln des Modellraums, in Komponenten umgesetzt. Die Funktionen einzelner Komponenten werden im Abschnitt näher erläutert. Die Akteure und ihre Assoziationen sind in jedem Intellix Workflow gleich. Zu Beginn eines Workflows wird der ersten Komponente ein Extraktionsauftrag (Job) übergeben, welcher durch alle Komponenten durchgereicht wird. Am Ende wird dem Anwender oder dem aufrufenden Programm dieser Extraktionsauftrag inklusive der erzielten Ergebnisse zurückgegeben. Zunächst wird in den nächsten beiden Abschnitten der Extraktionsauftrag näher beleuchtet und die bestehende Workflowintegration untersucht Extraktionsauftrag Ein Extraktionsauftrag referenziert eine Menge von Dokument-Objekten und einen Modellraum. Die Objekte der Dokumente bestehen unter anderem aus verschiedenen Repräsentationen der eigentlichen Geschäftsdokumente, wie zum Beispiel das Scan-Ergebnis des Dokuments als Rasterbild oder das Ergebnis der Texterkennung in Form eines Austauschformats. Extraktionsergebnisse und Feedbackeinträge werden auch in diesen Dokument-Objekten abgelegt. Im Modellraum werden unter anderem die Klassifikatoren referenziert, wie auch die Trainingsdatenmenge abgespeichert. Die Modellräume sind in einer Hierarchie aufgebaut. Durch diese hierarchische Struktur ist es möglich, dass Modelle zwischen Intellix Instanzen ausgetauscht werden können. Zum Beispiel können die Instanzen von Tochterunternehmen die Modellräume des Mutterunternehmens zur Informationsextraktion ihrer Dokumente nutzen. In der Abbildung 3.1 wird dieses Verhalten durch die Aktivität Modellraum wechseln dargestellt Workflowintegration In der aktuellen Version des Intellix Frameworks existiert ein rudimentäres WfMS. Dieses ist jedoch ziemlich unflexibel, da jede Änderung an einem Workflow, wie beispielsweise das Abschalten einer bestimmten Extraktionskomponente, direkt im Quellcode des Workflows erfolgen muss. Ein Workflow wird mittels einer Java Klasse beschrieben, die von AbstractJobWorkflow abgeleitet sein muss, welche wiederum die Schnittstelle JobWorkflow implementiert. Diese Schnittstelle ist eine Unterklasse der Callable Schnittstelle, wodurch es möglich ist, Workflows parallel 30 Kapitel 3 Analyse

39 java.util.concurrent <<interface>> JobWorkflow addworkflowlistener(listener) setjob(job : Job) <<interface>> Callable<Job> call() : Job <<realize>> AbstractJobWorkflow job : Job listeners : IWorkflowListener call() : Job execute() : Boolean IntellixWorkflow WORKFLOW_IDENTIFIER : String Abbildung 3.2: Workflowintegration im Intellix Framework abzuarbeiten und als Ergebnis einen Extraktionsauftrag (Job) zu erhalten. Abbildung 3.2 zeigt diese Zusammenhänge in einem Klassendiagramm. Die Schnittstelle IWorkflowListener (Workflow Empfänger), die von der Schnittstelle IJobProcessor (Extraktionsauftrags-Prozessor) implementiert wird, überwacht den Status eines Workflows. Da zu einem Workflow mehrere Workflow Empfänger zugeordnet werden können, ist es möglich, dass ein Workflow von mehreren Prozessoren parallel verarbeitet wird. In der Klasse IntellixWorkflow wird nun der Workflow innerhalb der execute() Methode ausgeführt. Das heißt, dass der gesamte Sequenzfluss eines Workflows in dieser Methode gesteuert wird. Abbildung 3.3 zeigt diese Zusammenhänge in einem Klassendiagramm. <<interface>> IJobProcessor addjob(job : Job) schedulejob(id : String,workflowId : String) <<interface>> IWorkflowListener workflowfinished(job : Job) 0..* job : Job listeners AbstractJobWorkflow call() : Job execute() : Boolean notifyworkflowlisteners(job : Job) Abbildung 3.3: Extraktionsauftragsprozessor im Intellix Framework Komponenten Ein Intellix Workflow ist in Komponenten aufgeteilt. Jede dieser Komponenten erfüllt eine Teilaufgabe im Intellix System. Manche Komponenten erfüllen den gleichen Zweck, erzielen ihre Ergebnisse jedoch mit unterschiedlichen Algorithmen. Implementiert werden Intellix Komponenten, indem sie von der abstrakten Klasse AbstractComponent erben, welche wiederum die Schnittstelle IComponent implementiert. In der abstrakten Klasse werden Protokollierungs- und Zeitmessungsmechanismen initialisiert und ausgeführt. In der Schnittstelle wird festgelegt, dass 3.1 Stand der Technik 31

40 jede Komponente eine Methode haben muss, die ihren Namen zurück gibt, sowie eine Methode, welche einen Wahrheitswert über die Verarbeitbarkeit des Extraktionsauftrags zurück gibt. Abbildung 3.4 zeigt diesen Zusammenhang in einem Klassendiagramm. <<interface>> IComponent getname() : String isprocessable() : Boolean Component executecomponent(job : Job) <<realize>> AbstractComponent loggingmanager : LoggingManager execute(job : Job) executecomponent(job : Job) Abbildung 3.4: Klassendiagramm der Komponentenschnittstelle Man kann die Intellix Komponenten unterschiedlich gruppieren. Eine Möglichkeit besteht darin, die Komponenten nach ihren verwendeten Algorithmen zu sortieren, wie es auch in der Paketstruktur im Intellix Framework größtenteils der Fall ist. Zu jedem Algorithmus können dann Trainings-, Extraktions-, Feedbackanalyse-, Feedbackverarbeitungs- und Reduzierungskomponenten existieren. Für jede Möglichkeit, die Klassifikatoren der Klassifikations- und Extraktionsalgorithmen persistent zu halten, kann es zusätzlich noch für jede Komponentenart eine spezielle Implementierung geben. Von den Komponenten, die Klassifikations- und Extraktionsalgorithmen nutzen, abgesehen, gibt es noch weitere Komponenten, die die Daten des Extraktionsauftrags beeinflussen. Diese Komponenten könnte man in die Kategorie Dienstkomponenten einordnen. Eine andere Möglichkeit Intellix Komponenten einzuordnen besteht darin, sie nach den drei Intellix Workflow Arten zu sortieren. Mit dieser Methode erstellt man eine Gruppe für alle Trainingskomponenten, eine für alle Extraktionskomponenten und eine für alle Feedbackkomponenten. Dies hat den Vorteil, dass auch alle Dienstkomponenten in eine der drei Kategorien eingeordnet werden. Die nun folgenden Abschnitte geben einen Überblick der aktuell implementierten Intellix Komponenten Trainingskomponenten Für jeden Dokumenttypklassifizierungs- und Indexdatenextraktionsalgorithmus existiert eine Trainingskomponente, die den jeweiligen Klassifikator mithilfe einer Dokumentenmenge, der Trainingsdatenmenge, trainiert. Diese Dokumente müssen in einem XML - Format vorliegen, welches den Dokumenttyp, beziehungsweise die Indexdaten beinhaltet. Der regelbasierte Extraktionsalgorithmus besitzt zwar auch eine Trainingskomponente, welche jedoch nur die Regeln aus einer Datenquelle einliest. Diese Komponente benötigt also keine Trainingsdatenmenge, erzeugt jedoch auch einen Klassifikator, welcher die Regeln zur Indexdatenextraktion beinhaltet. Die Klassifikatoren werden je nach Komponente in verschiedenen Zwischenspeichern persistent gehalten. Im Moment existieren Komponenten, die die Klassifikatoren auf dem Dateisystem speichern und Komponenten, die die Klassifikatoren in einer Datenbank speichern. Die Algorithmen der Dokumenttypklassifikation und Indexdatenextraktion werden in den Abschnitten und näher erläutert. 32 Kapitel 3 Analyse

41 Klassifizierungskomponenten Die Klassifizierungskomponenten haben die Aufgabe den Dokumenttyp automatisch zu ermitteln. Der Dokumenttyp wird einerseits ermittelt, damit Dokumente an Hand ihres Typs in ein DMS einsortiert und besser wiedergefunden werden können, andererseits können anhand des Dokumenttyps schon vor der Indexdatenextraktion die relevanten Indizes ermittelt werden, die überhaupt aus dem Dokument extrahiert werden müssen. Für die Dokumenttypklassifikation stehen im Moment der k-nearest-neighbor (KNN) und der Naive Bayes Algorithmus zur Verfügung. Die Algorithmen der Klassifikationskomponenten sind im Abschnitt erläutert. Um die Klassifikation durchführen zu können, muss der jeweilige Klassifikator vorher trainiert worden sein. Bei den Klassifizierungskomponenten stehen im Moment genauso wie bei den Trainingskomponenten pro Algorithmus zwei Methoden zur Verfügung um den Klassifikator zu laden, einerseits vom Dateisystem und andererseits aus einer Datenbank. Wenn eine von diesen beiden Methoden verwendet wird, muss auch die jeweilige Trainingskomponente genutzt worden sein, damit der Klassifikator auch in diesem Zwischenspeicher vorhanden ist. Zusätzlich gibt es noch eine Spracherkennungskomponente (LanguageClassifier), die die Sprache der im Extraktionsauftrag befindlichen Dokumente ermittelt Extraktionskomponenten Die Extraktionskomponenten versuchen, je nach Dokumenttyp, Indexdaten aus Dokumenten zu extrahieren. Es ist also hilfreich vor der Indexdatenextraktion eine Dokumenttypklassifikation durchzuführen, damit die für das jeweilige Dokument richtigen Indexdaten extrahiert werden. Im Moment existieren im Intellix Framework drei verschiedene Extraktionsverfahren. Diese Verfahren sind die textbasierte, layoutbasierte und regelbasierte Extraktion. Die Algorithmen dieser Komponenten sind im Abschnitt erläutert. Wie auch bei der Klassifikation müssen die Extraktoren mit den dazugehörigen Trainingskomponenten trainiert worden sein Feedbackkomponenten Feedbackkomponenten verarbeiten alle Daten, die die Nutzer eines Intellix Systems als Reaktion auf Extraktionsergebnisse eingegeben haben. Das sind einerseits Korrekturen von falsch extrahierten Extraktionsdaten und andererseits Bestätigungen von Extraktionsergebnissen. Die Komponenten für die Feedbackverarbeitung unterteilen sich in drei verschiedene Gruppen, die Analysekomponenten, die Feedbackverarbeitung und die Datenreduzierung. Analyse Die Analysekomponenten vergleichen das Nutzerfeedback mit den Extraktionsergebnissen eines bestimmten Algorithmus. Wenn zwischen diesen beiden Daten ein Unterschied besteht, wird dieses Extraktionsergebnis als fehlerhaft markiert und nach bestimmten Typen von Fehlern gruppiert. Die Feedbackfehler werden dann zur Weiterverarbeitung in ein dafür vorgesehenes Feld im Extraktionsauftrag gespeichert. Auch bei den Analysekomponenten existiert für jeden Algorithmus eine eigene Komponente. 3.1 Stand der Technik 33

42 Feedbackverarbeitung Mittels der Feedbackverarbeitungskomponenten werden nun die Klassifikatoren zusätzlich trainiert. Die ermittelten Feedbackfehler der jeweiligen Analysekomponente werden zusammen mit dem ursprünglichen Klassifikator zu einem neuen Klassifikator aktualisiert. Auch die Feedbackverarbeitung wird für jeden Algorithmus unabhängig voneinander durchgeführt. Datenreduzierung Die Datenreduzierungskomponenten bereinigen die Klassifikatoren im Modellraum von nicht mehr benötigten Dokumenten. Typischerweise wird man diese Komponenten direkt nach der jeweiligen Feedbackverarbeitung ausführen. Auch die Datenreduzierung wird für jeden Algorithmus unabhängig von den anderen Algorithmen ausgeführt Dienstkomponenten Dienstkomponenten verarbeiten den Extraktionsauftrag unabhängig von den benutzten Algorithmen. Sie verarbeiten meist die produzierten Daten der Trainings-, Extraktions- oder Feedbackkomponenten, weshalb sie oft nur in bestimmten Arbeitsabläufen eingesetzt werden können. In den folgenden Abschnitten werden die einzelnen Dienstkomponenten genauer beschrieben. Ergebnisse kombinieren Das Intellix Framework bietet für die Dokumenttypklassifikation oder Indexdatenextraktion verschiedene Algorithmen an. Nutzt man mehrere Algorithmen um den Dokumenttyp respektive Indexdaten zu extrahieren, müssen diese vor der weiteren Verarbeitung des Extraktionsauftrags kombiniert werden, damit von gleichen Extraktionsergebnissen mit unterschiedlichen Genauigkeitswerten ein gemeinsamer Wert gebildet werden kann. Diese Aufgabe erfüllt die Kombinierungskomponente (Combiner). Ergebnisse validieren Eine Validierungskomponente (Validation) prüft die Ergebnisse der Klassifikation und der Extraktion. Wenn die Genauigkeitswerte aller extrahierten Daten einen bestimmten Schwellenwert überschreiten, ist die Validierung erfolgreich. Wenn die Validierung nicht erfolgreich ist, versucht diese Komponente den aktuellen Modellraum mit einem nächst höheren Modellraum auszutauschen. Ist ein solcher Modellraum vorhanden, wird der Status des Extraktionsauftrags auf wiederholen gesetzt. Der aufgerufene Workflow muss dann auf diesen Status reagieren und die Extraktion mit dem neuen Modellraum wiederholen. Extraktionsauftrag bereinigen Eine Reinigungskomponente (Cleaner) löscht alle Ergebnisse der Dokumenttypklassifikationen und Indexdatenextraktionen aus allen Dokumenten eines Extraktionsauftrags. 34 Kapitel 3 Analyse

43 3.2 ZIELGRUPPE In Unternehmen wird es bei der Arbeit mit dem Intellix System zwei Gruppen von Anwendern geben. Die erste Gruppe sind Mitarbeiter, die Dokumente einscannen und über eine grafische Oberfläche das nötige Feedback zur Dokumenttypklassifikation und Indexdatenextraktion liefern. Die zweite Gruppe werden Administratoren sein, die das Intellix System installieren, den Betrieb überwachen und Optimierungen vornehmen. Ist diese zweite Gruppe von Mitarbeitern eines Unternehmens für die Installation des Intellix Systems zuständig, kann man davon ausgehen, dass die Berufsausbildung dieser Nutzer einen informationstechnischen Hintergrund hat. Es kann erwartet werden, dass es dieser Nutzergruppe, mit einer geringen Einarbeitungszeit, möglich ist, Workflows mittels einer Entwicklungsumgebung zu erstellen oder zu bearbeiten. Damit Workflows sinnvoll optimiert werden können, sollte ein Administrator des Intellix Systems einerseits die Arbeitsweise des Intellix Frameworks verstehen und andererseits mit der verwendeten Modellierungsnotation für Geschäftsprozesse vertraut sein. Falls das Bearbeiten von Intellix Workflows zu Optimierungszwecken an technisch nicht versierte Mitarbeiter eines Unternehmens delegiert wird, sollte es dennoch möglich sein, dass diese Anwender mit einer angepassten, vereinfachten Version einer Entwicklungsumgebung diese Arbeit durchführen können. 3.3 ANFORDERUNGEN Im Intellix System gibt es einige Arbeitsabläufe (Workflows), die in einer Intellix Instanz für alle Dokumente gleich ausgeführt werden. Durch den Einsatz eines WfMS kann man einerseits die Abarbeitung der Abläufe automatisieren und andererseits diese Arbeitsabläufe in einer standardisierten Notation in einem Diagramm darstellen. Die Darstellungen der Arbeitsabläufe in einem Diagramm haben den Vorteil, dass die Arbeitsschritte des Intellix Systems transparent sind und dass Administratoren eines solchen Systems die Möglichkeit haben diese Arbeitsabläufe durch einfaches Remodellieren zu optimieren. Wenn die Workflows unter allen Umständen und in jeder Intellix Instanz gleich wären, würde es ausreichen, wenn die Entwickler des Intellix Frameworks die benötigten Prozessdefinitionen modellieren und ein System zur Abarbeitung der erzeugten Prozessinstanzen, also eine Workflow Engine, in das Framework integrieren. Da es jedoch Möglichkeiten geben soll, die Ergebnisse der Arbeitsabläufe durch hinzufügen, entfernen oder austauschen von Komponenten zu verbessern oder die Workflows an sich zu optimieren, sollten die Prozessdefinitionen allgemein verständlich sein und in einer standardisierten Form vorliegen. Außerdem sollten Werkzeuge vorhanden sein, die eine einfache nachträgliche Modellierung möglich machen. 3.2 Zielgruppe 35

44 3.3.1 A1 Grundlegende Workflowfunktionalitäten Das verwendete WfMS sollte grundlegende Funktionalitäten zur Abarbeitung von Workflows besitzen, damit Intellix Workflows als Geschäftsprozesse modelliert und als Prozessinstanzen ausgeführt werden können. Die folgenden Abschnitte beschreiben die Basisfunktionalitäten, die das verwendete Modellierungswerkzeug, wie auch das zur Abarbeitung der Workflows verwendete Laufzeitsystem, besitzen sollten. A1.1 Definition einer Abarbeitungsreihenfolge der Komponenten In den Arbeitsabläufen einer Intellix Instanz ist es notwendig, dass Komponenten in einer bestimmten Reihenfolge abgearbeitet werden. Zum Beispiel wird zuerst der Dokumenttyp eines Dokuments ermittelt, bevor die Indexdatenextraktion für dieses Dokument durchgeführt wird, weil für unterschiedliche Dokumenttypen unterschiedliche Indexdaten definiert sind. Im Intellix Framework gibt es auch Komponenten, die nur nach bestimmten anderen Komponenten ablaufen können. Beispielsweise kann eine Kombinierungskomponente erst ausgeführt werden, wenn Ergebnisse mehrerer Dokumenttypklassifikationen oder Indexdatenextraktionen vorhanden sind. A1.2 Modellieren von parallelen Ausführungen WfMS bieten typischerweise drei Möglichkeiten an, mit Verzweigungen (engl. Split) und Zusammenführungen (engl. Join) umzugehen. Bei diesen drei Möglichkeiten handelt es sich um die parallele Abarbeitung (AND), die bedingte Auswahl (XOR) und die unbedingte Auswahl (OR). Im Intellix System wird die parallele Abarbeitung und die bedingte Auswahl benötigt. Die parallele Verzweigung (AND-Split) und Zusammenführung (AND-Join) benötigt man beispielsweise bei der Indexdatenextraktion, weil im Intellix Framework verschiedene Algorithmen zur Verfügung gestellt werden, die das Extrahieren von Indexdaten aus unstrukturierten Dokumenten ermöglichen. Die unterschiedlichen Extraktoren können parallel ablaufen. Für diese parallele Abarbeitung benötigt man bei der Modellierung eine parallele Verzweigung, um mehrere Threads für die einzelnen Extraktoren zu erzeugen und eine Zusammenführung, damit die Ergebnisse wieder synchronisiert werden. A1.3 Änderung des Sequenzflusses bei der Abarbeitung Die Beeinflussung des Sequenzflusses eines Workflows bei der Abarbeitung ist durch verschiedene Verfahren möglich. Eine Möglichkeit besteht darin, eine bedingte Verzweigung (XOR-Split) zu nutzen. Bei der bedingten Verzweigung wird in Abhängigkeit eines Rückgabewerts einer Komponente der Sequenzfluss auf unterschiedliche Weise fortgesetzt. Da jede Komponente im Intellix Framework einen Status zurückliefert, egal ob die Abarbeitung erfolgreich war oder nicht, kann dieser Statuswert an jeder Stelle in der Prozessdefinition für eine bedingte Verzweigung genutzt werden. Eine Möglichkeit ist die Überprüfung dieses Werts nach Validierung der Extraktionsergebnisse (siehe Ergebnisse validieren ). Eine weitere Möglichkeit die bestehenden Sequenzflüsse zur Laufzeit zu beeinflussen besteht darin, Ausnahmebehandlungen eines WfMS beziehungsweise eines Modellierungswerkzeugs zu nutzen. Das Anforderungspaket A1 kann man auch mittels Workflow-Patterns (siehe 2.2) beschreiben. In der folgenden Tabelle 3.1 werden alle benötigten Muster mit den passenden Beispielen dargestellt. 36 Kapitel 3 Analyse

45 Muster Sequenz Parallele Verzweigung Synchronisierte Zusammenführung Exklusive Auswahl Beispiel Indexdatenextraktion sollte nach der Dokumenttypklassifikation ausgeführt werden. Mehrere Indexdatenextraktionen sollten parallel ausgeführt werden. Die Ergebnisse mehrerer parallel ausgeführter Indexdatenextraktionen müssen synchronisiert werden. Wiederholung des Extraktionsworkflows, wenn nicht alle Extraktionsergebnisse eine Mindestgüte besitzen. Tabelle 3.1: Benötigte Workflow Muster für das Anforderungspaket A A2 Einfache Erstellung und Bearbeitung von Workflows Die Erstellung, Bearbeitung und Löschung der Trainings-, Extraktions-, und Feedbackworkflows sollen von Administratoren bestimmter Intellix Instanzen durchgeführt werden. Sie haben keinen Einblick in das Intellix Framework und können somit nicht wissen, welche Komponenten verfügbar sind und wie ein gültiger Workflow aussieht. Die folgenden Anforderungen sollen sicherstellen, dass Administratoren einer Intellix Instanz in der Lage sind eine Prozessdefinition neu zu erstellen und bestehende Prozessdefinitionen bearbeiten zu können, ohne die internen Strukturen des Intellix Frameworks zu kennen. A2.1 Bearbeitung der Intellix Workflows in der Modellierungsphase Dem Nutzer sollte ein möglichst einfaches grafisches Werkzeug zur Verfügung stehen um Intellix Workflows zu erstellen oder zu bearbeiten. Die Modellierungssprache, mit der die Intellix Workflows modelliert werden, sollte eine standardisierte Sprache sein, damit die grafische oder textuelle Repräsentation der Workflows von möglichst vielen Menschen interpretiert werden kann. Außerdem sollte eine Technik existieren, welche die remodellierten Workflowbeschreibungen ohne Zutun des Anwenders in ein Austauschformat exportiert und automatisch in das laufende Intellix System integriert. A2.2 Auflistung aller verfügbaren Komponenten Das Modellierungswerkzeug, das bei der Erstellung oder Bearbeitung der Workflows verwendet wird, sollte dem Anwender Möglichkeiten geben aus allen benötigten Notationselementen und allen verfügbaren Intellix Komponenten auszuwählen und die Workflows frei gestalten zu können. A2.3 Gültigkeitsprüfung für Intellix Workflows Fehler im laufenden Betrieb einer Intellix Instanz kann man vermeiden, indem bearbeitete oder neu erstellte Workflows, vor der Integration in das Intellix System, auf ihre Gültigkeit überprüft werden. Das beinhaltet einerseits die Überprüfung der Workflows auf Modellebene, als auch eine Überprüfung durch eine Testumgebung, in der unter einer möglichst realen Laufzeitumgebung die neuen Workflows getestet werden. 3.3 Anforderungen 37

46 3.3.3 A3 Integration eines Workflow-Management-Systems In das Intellix Framework soll ein WfMS integriert werden, das die modellierten Intellix Workflows instanziiert, steuert und überwacht. In modularen WfMS existiert für die Steuerung von Prozessinstanzen eine Ausführungseinheit und für das Verwalten der Workflowbeschreibungen ein Modell Repository. Auch eine Prozessüberwachung zur Steuerung und Visualisierung von manuellen Aktivitäten ist in den meisten WfMS ein zentraler Bestandteil. Bei den Intellix Workflows handelt es sich nach [McC92] um administrative Workflows, da in diesen Workflows ausschließlich allgemeine, automatisierte Aufgabenträger (engl. Services) eingebunden werden. Somit muss keine Komponente integriert werden, die eine Schnittstelle für Benutzerinteraktionen bietet. Diese Komponente steht in Ad-hoc-Workflows im Vordergrund. Abbildung 3.5 verdeutlicht den Zusammenhang zwischen den Komponenten eines WfMS mit dem Intellix Framework. Prozess Designer Workflow Modellierung Intellix Komponenten Modell Repository Workflow Engine Abbildung 3.5: WfMS in Zusammenarbeit mit dem Intellix Framework A3.1 Integration einer Ausführungseinheit in das Intellix Framework Die Ausführungseinheit (Workflow Engine) eines WfMS sollte sich in das bestehende Intellix Framework integrieren lassen. Sie muss anschließend in der Lage sein, Prozessdefinitionen zu instanziieren und diese Prozessinstanzen zu steuern. In der Literatur wird unterschieden zwischen eigenständigen WfMS, welche mittels Schnittstellen die Kopplung unterschiedlicher Dienste oder Anwendungen anbieten und eingebetteten WfMS, die Systemkomponenten zur Entwicklung neuer Softwaresysteme bieten. [BKR08] Die oben genannte Anforderung lässt sich nur mit dem Einsatz einer eingebetteten Workflow Engine realisieren, weil das Intellix Framework keine Schnittstelle zur Anbindung eines autonomen WfMS bietet. 38 Kapitel 3 Analyse

47 A3.2 Verwaltung von Prozessdefinitionen durch ein Repository Es muss ein System integriert werden, welches bei der Instanziierung eines Intellix Systems Prozessdefinitionen einliest, übersetzt und verwaltet. Auch im laufenden Betrieb sollten geänderte oder neu erstellte Prozessdefinitionen dem Repository hinzugefügt und von der Ausführungseinheit für zukünftige Extraktionsaufträge genutzt werden können. A3.3 Austauschbarkeit der Prozessdefinitionen Die Prozessdefinitionen müssen zwischen einem Modellierungswerkzeug und dem Intellix Framework ausgetauscht werden können. Deshalb sollte, wie schon in der Anforderung A2.1 angesprochen, die Modellierungssprache einem Standard entsprechen, sodass man auf mehrere Modellierungswerkzeuge beziehungsweise Ausführungseinheiten zurückgreifen kann. A3.4 Überwachung von laufenden Prozessinstanzen In der Anforderung A2.1 wurde festgelegt, dass es eine Möglichkeit geben soll, Intellix Workflows zu bearbeiten. Der klassische Grund für die Bearbeitung eines Workflows ist meist die Optimierung des Geschäftsprozesses. Bevor jedoch ein Workflow optimiert werden kann, müssen die vorhandenen Workflowmodelle analysiert werden. Es sollte also eine Möglichkeit existieren, die laufenden Prozessinstanzen mithilfe von Kontrollwerkzeugen zu überwachen. Bei Intellix Workflows gibt es noch weitere Gründe, die es erforderlich machen, die bestehenden Workflowmodelle zu remodellieren. Einerseits durch Veränderungen der verfügbaren Komponenten im Framework oder durch die Anpassung der Extraktionspläne an eine andere Domäne. 3.4 IMPLEMENTIERUNGSMÖGLICHKEITEN In den folgenden Abschnitten werden die im Grundlagenkapitel (siehe 2.3.2) vorgestellten WfMS mit den im letzten Abschnitt ausgearbeiteten Anforderungen verglichen, damit ein geeignetes WfMS für die Aufgaben des Intellix Frameworks bestimmt werden kann. Außerdem wird im Abschnitt die Möglichkeit untersucht, ein dokumentgesteuertes WfMS zu nutzen jbpm Die aktuelle jbpm Software Suite in der Version 5.0 installiert Eclipse in der Version inklusive jbpm spezifischer Plugins, wie auch den BPMN-Editor Drools. Mit diesem Editor kann somit die Anforderung A2.1 erfüllt werden. Das folgende Prozessdiagramm 3.6 zeigt einen einfachen Intellix Extraktionsworkflow, der mit diesem Editor erstellt wurde. Außerdem müssen die in diesem Diagramm enthaltenen Script Task Nodes nach der grafischen Modellierung mit Funktionalitäten erweitert werden. Dies können Java oder MVEL 1 Scripte sein, die entweder in der resultierenden XML-Prozessdefinition ergänzt werden oder in einem vorgesehenen 3.4 Implementierungsmöglichkeiten 39

48 Abbildung 3.6: Intellix Extraktionsworkflow erstellt im BPMN-Editor Drools Feld in der Eigenschaftsansicht (engl. Properties View) der Elemente hinzugefügt werden. Eine einfachere Lösung bieten sogenannte Service-Tasks, die zusätzlich in die Komponentenliste des Editors hinzugefügt werden können, womit die Anforderung A2.2 erfüllt werden kann. Ein Service-Task muss jedoch entweder bei einem WorkItemHandler registriert werden oder seine Funktionalität in ein WorkItem implementieren, bevor die Workflow Engine diesen Service-Task ausführen kann. Somit ist eine umfangreiche Umstrukturierung des Intellix Frameworks nötig, um die Anforderungen A2.2 und A3.1 umzusetzen. Das Anforderungspaket A1 kann vollständig unterstützt werden, da die standardisierte Modellierungssprache BPMN 2.0 verwendet wird. Auch das Arbeitspaket A3 kann, bis auf die Anforderung A3.1, vollständig umgesetzt werden, da alle notwendigen Komponenten und Schnittstellen vorhanden sind Activiti Mittels der Activiti BPM Plattform gibt es mehrere Möglichkeiten Prozessdiagramme zu erstellen und zu bearbeiten. Einerseits über die Web Anwendung Activiti Modeler und andererseits über das Activiti Designer Eclipse Plugin. Beide Editoren basieren auf der Modellierungssprache BPMN 2.0. Die Activiti BPM Plattform ist ein recht neues WfMS. Die erste finale Version wurde erst Ende 2010 veröffentlicht. Der Funktionsumfang des Activiti Designers umfasst noch nicht alle Elemente und Fähigkeiten der BPMN 2.0 Notation. Tabelle 3.2 zeigt eine Auswahl von grundlegeneden BPMN 2.0 Elementen [OMG11], die in der aktuellen Version des Activiti Designer implementiert und noch nicht implementiert sind. Die fettgedruckten Zeilen beinhalten die Elemente aus dem Anforderungspaket A1. Aus der Tabelle kann man herauslesen, dass die aktuelle Version des Activiti Designers in der Lage ist das Anforderungspaket A1 und die Anforderung A2.1 zu erfüllen. Da die textuelle Repräsentation der Prozessdefinitionen in einem XML - Austauschformat gespeichert wird, ist damit auch die Anforderung A3.3 erfüllt. Für den Activiti Designer existiert eine Schnittstelle, die es ermöglicht eine Erweiterung zu programmieren, die die Komponentenliste mit sogenannten Custom Service Tasks ergänzt. Diese Aktivitäten verweisen auf Java-Klassen, welche von der Klasse JavaDelegate aus der Activiti API erben. Da diese Klassen, genau wie die bestehenden Komponenten aus dem Intellix Framework, durch eine Methode namens 1 MVEL ist eine Expression Language für Java-basierte Applikationen 40 Kapitel 3 Analyse

49 Tabelle 3.2: BPMN 2.0 Unterstützung im Activiti Designer Element Diagramm XML Beschreibung Aktivität + + Atomarer Task + + Choreografischer Task - - Expandierter Unterprozess + - Schleifen - - Mehrfach-Instanzen + + Nachrichten - - Transaktionen - - Exklusiver Gateway + + Paralleler Gateway + + Ereignis-basierter Gateway - - Inklusiver Gateway - - Komplexer Gateway - - Unkontrollierter Sequenzfluss + + Bedingter Sequenzfluss + + Standardfluss + + Ausnahmefluss - - Nachrichtenfluss Vorhanden - Nicht Vorhanden execute() ausgeführt werden, ist der Aufwand für die Adaption des Intellix Frameworks an die Activiti API nicht groß. Außerdem kann man über eine Schnittstelle die Komponentenliste modifizieren und damit nicht benötigte BPMN 2.0 Elemente entfernen, womit die Anforderung A2.2 erfüllt wird. Über eine weitere Schnittstelle ist es zusätzlich möglich, eine Gültigkeitsprüfung zum Activiti Designer hinzuzufügen. Mit dieser Erweiterung kann auch die Anforderung A2.3 erfüllt werden. Da in der Activiti BPM Plattform alle für das Anforderungspaket A3 notwendigen Komponenten vorhanden sind, ist es möglich, die verbleibenden Anforderungen dieses Pakets umzusetzen UIMA Unstructured Information Management Architecture (UIMA) ist ein Framework, das zur Verwaltung unstrukturierter Information, also auch Geschäftsdokumenten, verwendet wird. Mit diesem Framework kann man Anwendungen erstellen, in denen verschiedene Komponenten unterschiedliche Aufgaben, wie dem Speichern von Dokumenten oder der Extraktion von Informationen, bearbeiten. Diese Anwendung muss dann die Ausführung und den Datenaustausch zwischen den einzelnen 3.4 Implementierungsmöglichkeiten 41

50 Komponenten steuern. Somit gibt es auch in diesem Framework Möglichkeiten Workflows zu definieren. Jedoch können für UIMA Anwendungen keine Workflows in grafischer Notation erstellt werden, womit das komplette Anforderungspaket A2 nicht erfüllt werden kann. Es fehlen auch grundlegende Workflowfunktionalitäten, wie es im Anforderungspaket A1 gefordert ist. Beispielsweise ist es nicht möglich, Komponenten parallel ausführen zu lassen KNIME Die grundlegenden Anforderungen des Anforderungspakets A1 werden vom Konstanz Information Miner (KNIME) Desktop erfüllt. Man kann Komponenten in einem Sequenzfluss modellieren und parallele, wie auch bedingte Verzweigungen nutzen. Das Anforderungspaket A2 könnte mittels der KNIME API umgesetzt werden, da diese API Schnittstellen anbietet, mit denen dem System neue Komponenten hinzugefügt werden können. Das Anforderungspaket A3 kann jedoch nicht umgesetzt werden, weil es mit der KNIME API nur möglich ist, Komponenten für den KNIME Desktop zu entwickeln, nicht aber die Ausführungseinheit dieses WfMS in ein anderes Framework zu integrieren. Außerdem verwendet KNIME ein proprietäres Format zur grafischen und textuellen Speicherung der Prozessdefinitionen YAWL Das Yet Another Workflow Language (YAWL) Software Framework basiert auf der gleichnamigen Modellierungssprache YAWL (siehe ). Es ist besonders im Wissenschaftsumfeld sehr beliebt, weil die Sprache aus Analysen vielfältiger Modellierungssprachen und Workflowsystemen entstanden ist und viel Wert auf die vollständige Implementierung der Workflow-Patterns (siehe 2.2) legt. Das System wird auch in größeren Unternehmen eingesetzt. [Lie09, S. 6] Das YAWL Software Framework beinhaltet einen Workflow Editor (siehe ), mit dem es möglich ist, mittels der YAWL Notation, Workflows zu erstellen und in ein XML-Format zu speichern. Abbildung 3.7 zeigt einen einfachen Intellix Extraktionsworkflow in der YAWL Notation. Dieser Editor bringt ein Analyse- und Gültigkeitsprüfungswerkzeug mit, sodass bestimmte Fehler schon in der Modellierungsphase beseitigt werden können. Jedoch ist es nicht möglich eine weitere Gültigkeitsprüfung für den Editor zu entwickeln. Somit kann die Anforderung A2.3 nicht erfüllt werden. Abbildung 3.7: Intellix Extraktionsworkflow erstellt im YAWL Editor Die Integration in das Intellix Framework wäre ähnlich komplex, wie die Integration der Ausführungseinheit von jbpm. Es ist zwar möglich sogenannte Custom 42 Kapitel 3 Analyse

51 Services zu modellieren, diese müssen aber auf Webservices oder YAWL interne Worklets verweisen. Die Umsetzung der Anforderung A3.1, also die Änderungen am Intellix Framework, damit die Intellix Komponenten als Custom Services genutzt werden können, würde eine weitreichende Umstrukturierung des Intellix Frameworks bedeuten Dokumentengesteuertes Workflow-Management Wang und Kumar haben in einer Ausarbeitung über die Entwicklung eines Frameworks für ein dokumentengesteuertes WfMS eine Gegenüberstellung dokumentengesteuerter Workflows und kontrollflussgesteuerter Workflows erarbeitet. [WK05] Typischerweise wird in der Geschäftsprozessmodellierung viel Wert auf die Flexibilität des Kontrollflusses gelegt. In bestimmten Anwendungsszenarien können aber auch die Zustände von Dokumenten eine wichtige Rolle spielen. Vor allem in Ad-hoc Workflows (siehe ) kann dies der Fall sein. Tabelle 3.3 zeigt den Vergleich der Eigenschaften von dokumentengesteuerten Workflows und kontrollflussgesteuerten Workflows. [WK05] Tabelle 3.3: Vergleich von dokumenten- und kontrollflussgesteuerter Workflows Dokumentengesteuerter Workflow Dokumente steuern den Prozess. Der Prozess ist sehr flexibel und kann durch Änderungen der Bedingungen den Verlauf verändern. Es existieren keine Verzweigungen oder Vereinigungen, weil es keinen Kontrollfluss gibt. Anwendungsdaten sind vom Prozess getrennt. Geeignet für Ad-Hoc Workflows. Eine Verifikation ist relativ einfach. Benötigt Konfliktlösung in komplexen Workflows. Darstellung des Prozesses ist schwierig. Kontrollflussgesteuerter Workflow Kontrollfluss steuert den Prozess. Der Prozess ist durch die Einschränkungen des Kontrollflusses weniger flexibel, weil alle Instanzen auf das selbe Kontrollflussmuster basieren. Verzweigungen und Vereinigungen werden für den Kontrollfluss genutzt. In den meisten Fällen sind Anwendungsdaten Bestandteil vom Kontrollfluss. Gut für Produktionsworkflows mit voll entwickelten Prozessen und vielen Aufgaben. Verifikation ist möglicherweise schwer. Konfliktlösung wird nicht benötigt. Prozess kann einfach visualisiert werden. Innerhalb der Intellix Komponenten werden immer Dokumente oder Extraktionsergebnisse verarbeitet. Diese mehr oder weniger strukturierten Informationen steuern aber nicht die Intellix Workflows. Somit handelt es sich bei diesen Workflows nicht um Ad-hoc Workflows, sondern um Produktionsworkflows, bei denen die einfache Visualisierung der Geschäftsprozesse mit im Vordergrund steht. 3.4 Implementierungsmöglichkeiten 43

52 3.5 FAZIT Die Untersuchung der infrage kommenden Systeme hat ergeben, dass es mit sehr hohem Aufwand verbunden wäre, die WfMS UIMA, KNIME oder YAWL mit den im Abschnitt 3.3 aufgestellten Anforderungen an das Intellix Framework anzupassen und einzelne Komponenten in dieses Framework zu integrieren. UIMA eignet sich zwar gut um Dokumente mit unstrukturierten Informationen zu verwalten und Informationen daraus zu extrahieren, aber nicht um eine Umgebung für ein intuitives Workflow-Management zu schaffen. KNIME wurde als eigenständiges System entwickelt, um hauptsächlich interaktive Datenanalyse und Datenmanipulation zu betreiben, aber nicht um die vorhandenen Workflowfunktionalitäten in ein anderes System zu integrieren. YAWL ist ein mächtiges Werkzeug um komplexe Aspekte in Prozessdefinitionen zu modellieren, da es vielfältige Workflow-Patterns unterstützt. Durch diese hohe Komplexität ist es aber sehr umständlich die vorhandenen Strukturen des Intellix Frameworks an die API von YAWL anzupassen. Im Gegensatz dazu können sowohl jbpm als auch die Activiti BPM Plattform alle aufgestellten Anforderungen erfüllen. Dabei würde die Integration der Intellix Komponenten in den jbpm Editor Drools und die Integration der jbpm Workflow Engine in das Intellix Framework, im Gegensatz zu Activiti, eine größere Umstrukturierung zur Folge haben. Aus diesem Grund wurde die Activiti BPM Plattform ausgewählt, um das Intellix Framework mit Funktionalitäten eines WfMS zu erweitern. Tabelle 3.4 zeigt noch einmal in einer Übersicht die Unterstützung der Anforderungen durch die einzelnen WfMS. Tabelle 3.4: Anforderungserfüllung der untersuchten WfMS Anforderung jbpm Activiti UIMA KNIME YAWL A A A A A A A A A A umsetzbar - nicht oder umständlich umsetzbar * Nicht untersucht, weil Anforderungspaket A2 nicht umsetzbar ist. ** Nicht untersucht, weil Anforderung A2.3 schwer umsetzbar ist. 44 Kapitel 3 Analyse

53 4 KONZEPT Die Analyse hat ergeben, dass das am besten geeignete Workflow Management System (WfMS) für die Umsetzung der Aufgabenstellung die Activiti BPM Plattform ist. Das System bietet eine umfangreiche API an, mit der es möglich ist, alle aufgestellten Anforderungen (siehe 3.3), mit einer möglichst geringen Umstrukturierung des Intellix Frameworks, umzusetzen. In diesem Kapitel werden zuerst im Abschnitt 4.1 Intellix Workflows entwickelt und Bedingungen an diese geknüpft. Anhand dieser Bedingungen kann eine Gültigkeitsprüfung für Intellix Workflows entwickelt werden. Im Abschnitt 4.2 wird beschrieben, was am Modellierungswerkzeug der Activiti BPM Plattform verändert werden muss, damit möglichst einfach und intuitiv die Workflows für das Intellix System modelliert werden können. Zum Abschluss wird im Abschnitt 4.3 beschrieben, wie die Schnittstellen des Workflow Management Coalition (WfMC) Referenzmodells umgesetzt werden und wie die Activiti BPM Plattform in das Intellix Framework integriert werden kann. 4.1 INTELLIX WORKFLOWS Der gesamte Arbeitsablauf des Extraktionsprozesses in dem Intellix Framework, welcher Dokumente klassifiziert, Indexdaten aus diesen extrahiert und Nutzerfeedback verarbeitet, unterteilt sich in drei unabhängige Workflows: Trainingsworkflow, Extraktionsworkflow und Feedbackworkflow. Diese drei Workflows sind teilweise voneinander abhängig. Zum einen kann der Extraktionsworkflow nur Informationen aus Dokumenten extrahieren, wenn der Trainingsworkflow zuvor Klassifikatoren trainiert hat, zum anderen ist der Feedbackworkflow indirekt vom Extraktionsworkflow abhängig, da er zur Abarbeitung Feedbackeinträge benötigt, welche normalerweise erst entstehen können, nachdem versucht wurde, eine automatische Extraktion durchzuführen. Außerdem ist der Feedbackworkflow von den genannten Feedbackeinträgen bedingt, da er erst ausgeführt werden sollte, wenn der Nutzer ein automatisch extrahiertes Datum korrigiert oder ein nicht automatisch ermittelbares Datum eingegeben hat. Die Abhängigkeit zwischen Nutzereingaben und Verarbeitung dieser Eingaben soll nicht durch das hier verwendete WfMS verarbeitet werden. Das heißt, dass das Intellix System die Nutzereingaben entgegen nimmt und daraufhin das, im Intellix Framework integrierte, WfMS damit beauftragt, diese 45

54 Feedbackeinträge zu verarbeiten. Die Ausführung der Dokumenttypklassifikation und Indexdatenextraktion soll analog zum Feedbackworkflow angesteuert werden. Wenn ein neues Dokument hinzukommt, liegt es am Intellix System, das WfMS damit zu beauftragen, den Extraktionsworkflow zu starten. Die nächsten Abschnitte beschreiben detailliert die einzelnen Intellix Workflows und die Bedingungen, die diese Workflows erfüllen müssen. Zu jedem Workflow wird es ein Diagramm in der BPMN Notation geben. Aus diesem Grund werden in der Tabelle 4.1 alle benötigten BPMN Notationselemente erläutert. Tabelle 4.1: BPMN Notationselemente Element Name Beschreibung Startereignis Endereignis Ein Startereignis kennzeichnet den Beginn eines Prozesses. Ein Endereignes kennzeichnet das Ende einer Prozessbeschreibung Aufgabe Aufgabe Eine Aufgabe ist eine atomare Aktivität. Sequenzfluss Paralleles Gateway Exklusives Gateway Ein Sequenzfluss bestimmt die Reihenfolge von Ereignissen und Aktivitäten. Mit diesem Gateway kann eine parallele Verzweigung oder eine Synchronisation modelliert werden. Mit diesem Gateway kann eine bedingte Auswahl und eine einfache Zusammenführung modelliert werden Trainingsworkflow Damit überhaupt Informationen aus Geschäftsdokumenten mittels Machine Learning Algorithmen oder regelbasierten Verfahren extrahiert werden können, müssen Klassifikatoren trainiert, beziehungsweise aus vordefinierten Regeln erzeugt werden. Für diesen Vorgang ist ein Trainingsworkflow zuständig. Dieser Arbeitsablauf ist von der eigentlichen Dokumenttypklassifikation und Indexdatenextraktion unabhängig zu betrachten, weil die Klassifikatoren nicht vor jeder Klassifikation oder Extraktion neu aufgebaut werden müssen. Typischerweise gibt es eine Trainingsdatenmenge, also eine Menge von bereits indexierten Dokumenten, mit der die Klassifikatoren trainiert werden. Diese Trainingsdatenmenge wird dem Workflow mit einem Extraktionsauftrag (Job) als Argument übergeben. Danach können beliebig viele Klassifikations- und Extraktionsvorgänge durchgeführt werden. Das bedeutet, dass der Extraktionsworkflow mit anderen Dokumenten, die noch nicht indexiert wurden, abgearbeitet wird. Abbildung 4.1 zeigt einen Trainingsworkflow in BPMN Notation. 46 Kapitel 4 Konzept

55 KNN Training DB Rule Based Training Colonial Training DB Abbildung 4.1: Intellix Trainingsworkflow in BPMN Notation Die erste Komponente in diesem Trainingsworkflow (KNN Training DB) trainiert einen Klassifikator zur Klassifikation von Dokumenttypen mittels eines KNN Algorithmus (siehe ) und speichert das Resultat in eine Datenbank. Mittels einer äquivalenten Komponente namens KNN Training FS kann das Modell auch serialisiert auf dem Dateisystem gespeichert werden. Die zweite Komponente Colonial Training DB ist für das Trainieren eines Klassifikators zur Indexdatenextraktion verantwortlich. Diese Komponente speichert das erzeugte Modell in einer Datenbank und nutzt zum Aufbau des Klassifikators den Colonial-Algorithmus (siehe ). Die dritte Komponente Rule-Based Training erzeugt ebenfalls einen Klassifikator für die Extraktion von Indexdaten. Da der regelbasierte Extraktionsalgorithmus keine Machine Learning Komponente besitzt, sondern Indexdaten anhand von vordefinierten Regeln extrahiert, beinhaltet der Klassifikator, nach Beendigung dieser Komponente, nur die vordefinierten Regeln zur Indexdatenextraktion (siehe ). Die, in der Abbildung 4.1 gezeigten, Trainingskomponenten können durch andere Komponenten ersetzt oder ergänzt werden, je nach dem welche Extraktionskomponenten im Extraktionsworkflow zur Anwendung kommen und von welchem persistenten Zwischenspeicher der Klassifikator bezogen werden soll. Die einzelnen Trainingskomponenten können sowohl sequenziell als auch parallel ausgeführt werden, weil der Aufbau der jeweiligen Klassifikatoren voneinander unabhängig ist. Falls die Komponenten parallel ausgeführt werden, müssen sie vor Beenden des Workflows synchronisiert werden, damit sichergestellt wird, dass alle Modelle vollständig aufgebaut sind, bevor der Workflow beendet wird. Bedingungen Für den Trainingsworkflow gibt es kaum strukturelle Bedingungen, die erfüllt sein müssen. Jede Trainingskomponente trainiert unabhängig von anderen Trainingskomponenten einen Klassifikator und speichert diesen in einem Zwischenspeicher. Somit können alle Komponenten parallel abgearbeitet werden. Falls sie parallel abgearbeitet werden, müssen sie auch vor der Beendigung des Workflows synchronisiert werden. Außerdem sollten in einem Trainingsworkflow nur Trainingskomponenten verwendet werden, weil Extraktionskomponenten auf Dokumenten mit vorhandenen Indexdaten keine sinnvollen Auswirkungen haben und für die Feedbackkomponenten die Feedbackeinträge im Extraktionsauftrag fehlen. Tabelle 4.2 zeigt eine Übersicht aller Bedingungen für einen Trainingsworkflow. 4.1 Intellix Workflows 47

56 Bedingung Tabelle 4.2: Bedingungen für Trainingsworkflows Nur Trainingskomponenten im Trainingsworkflow. Beenden aller Trainingskomponenten vor Beendigung des gesamten Workflows. Umsetzung Nur Trainingskomponenten in der Prozessbeschreibung verwenden. Synchronisierte Zusammenführung modellieren, falls mehrere Trainingskomponenten parallel ausgeführt werden Extraktionsworkflow Das Kernstück des Intellix Frameworks ist der Extraktionsworkflow. Im wesentlichen werden in diesem Arbeitsablauf Dokumente klassifiziert und Indexdaten aus ihnen extrahiert. Typischerweise wird in diesem Workflow nur ein einziges Dokument bearbeitet, da der Extraktionsworkflow unmittelbar nach dem Hinzufügen eines Dokumentes in das System angestoßen werden soll. Dieser Arbeitsablauf wird am meisten Spielraum für Optimierungen durch den Anwender geben, da es verschiedene Klassifikations- und Extraktionsalgorithmen gibt, die in diesem Workflow kombiniert werden können. Je nach dem welcher Dokumenttyp ermittelt wurde, müssen unterschiedliche Indexdaten extrahiert werden. Daraus folgt, dass die Indexdatenextraktion nach der Dokumenttypklassifikation folgen sollte. Falls mehrere Klassifikations- oder Extraktionsalgorithmen verwendet werden, müssen die Ergebnisse jeweils kombiniert werden, bevor sie weiter verarbeitet werden. Nach der Klassifikation und der Extraktion folgt eine Überprüfung der Ergebnisse. Diese Überprüfung stuft die Extraktionsergebnisse anhand ihres Konfidenzwertes in vertrauenswürdige und nicht vertrauenswürdige Extraktionsergebnisse ein. Werden alle Ergebnisse durch die Überprüfungskomponente als vertrauenswürdig eingestuft, kann der Workflow beendet werden, andernfalls wird versucht, den Modellraum mit einem hierarchisch höher gelegenem Modellraum auszutauschen. Existiert solch ein Modellraum, wird der Extraktionsworkflow noch einmal wiederholt, ansonsten wird er beendet. Abbildung 4.2 zeigt einen Extraktionsworkflow in der BPMN Notation. KNN Process DB NB Process DB Combiner Index Extraction Process Rule Based Process Colonial Process DB Validation Combiner Abbildung 4.2: Intellix Extraktionsworkflow in BPMN Notation Analog zum Trainingsworkflow (4.1.1) können mehrere Komponenten der Dokumenttypklassifikation respektive Indexdatenextraktion parallel abgearbeitet werden, da sie unabhängig voneinander die Extraktionsergebnisse im Extraktionsauftrag ablegen. Falls sie parallel abgearbeitet werden, müssen sie auch synchroni- 48 Kapitel 4 Konzept

57 siert werden. Nach der Synchronisation oder des Beendens der letzten Komponente der Klassifikation beziehungsweise Extraktion, muss jeweils eine Kombinierungskomponente (Combiner) folgen. Diese Kombinierungskomponente verknüpft die Ergebnisse der unterschiedlichen Algorithmen und versucht durch diesen Vorgang bessere Ergebnisse zu erzeugen. Nach der letzten Kombinierungskomponente sollte eine Validierungkomponente (Validation) folgen, welche die Quallität aller Klassifikations- und Extraktionsergebnisse prüft. Wenn Ergebisse existieren, die als nicht gut genug angesehen werden und zu einem anderen Modellraum gewechselt werden kann, sollte der Workflow mit dem neuen Modellraum wiederholt werden. Falls jedoch alle Ergebnisse als vertrauenswürdig eingestuft werden oder kein weiterer Modellraum existiert, zu dem gewechselt werden kann, wird der Workflow beendet. Diese Verzweigungsentscheidung im Extraktionsworfklow wird durch ein exklusives Gateway realisiert. Dieses Gateway prüft eine Variable, die durch die Validierungskomponente gesetzt wird. Bedingungen Da der Extraktionsworkflow der komplexeste ist, gibt es auch mehr Bedingungen für das Modellieren dieses Workflows. Als Erstes sollte überprüft werden, dass keine Trainingskomponenten modelliert werden. Das Ausführen von Trainingskomponenten würde im Extraktionsworkflow keinen Effekt haben, da im Extraktionsauftrag keine Dokumente mit Indexdaten vorhanden sind. Auch Feedbackkomponenten sollten in einem Extraktionsworkflow nicht modelliert werden, weil im Extraktionsauftrag keine Feedbackeinträge vorhanden sind. Feedbackeinträge werden vom Nutzer erzeugt, in dem dieser auf Extraktionsergebnisse reagiert. Also können keine Feedbackeinträge entstehen, wenn für das jeweilige Dokument noch keine Indexdaten existieren. In einem Extraktionsworkflow können zwei Arten von Klassifikatoren angewendet werden. Zum einen Klassifikatoren für die Dokumenttypklassifikation und zum anderen für die Indexdatenextraktion. Die Dokumenttypklassifikation sollte vor der Extraktion ausgeführt werden, da durch den Dokumenttypen festgelegt werden kann, welche Indexdaten überhaupt durch die Klassifikatoren extrahiert werden sollen. Falls mehrere verschiedene Klassifikatoren für die Klassifikation beziehungsweise Extraktion genutzt werden, können diese Komponenten parallel modelliert werden. Falls sie parallel modelliert werden, müssen sie vor der nächsten Aktivität synchronisiert werden. Außerdem müssen die Ergebnisse mehrerer Klassifikations- oder Extraktionskomponenten, unabhängig vom parallelen oder sequentiellen Verlauf, mit einer Kombinierungskomponente verknüpft werden. Nach einer Validierungskomponente muss eine exklusive Verzweigung folgen, weil diese Komponente dazu da ist, den Kontrollfluss des Workflows zu steuern. Tabelle 4.3 zeigt noch einmal alle zu prüfenden Bedingungen für einen Extraktionsworkflow Feedback Schon in der Vorhabensbeschreibung zum Verbundprojekt Intellix ist von einer semi-automatischen Indexierung die Rede. [BSS10, S. 3] Das heißt, es wird davon ausgegangen, dass die Klassifikatoren bei der Dokumenttypklassifikation und Indexdatenextraktion nicht fehlerfrei arbeiten. Aus diesem Grund muss jedes Extraktionsergebnis von einem Nutzer bestätigt, korrigiert oder ergänzt werden. Diese Eingaben werden unabhängig von den Extraktionsergebnissen mit den jeweiligen Dokumenten verknüpft. Damit nun der Modellraum einer Intellix Instanz von den 4.1 Intellix Workflows 49

58 Bedingung Tabelle 4.3: Bedingungen für Extraktionsworkflows Kein Trainieren von Klassifikatoren. Keine Feedbackverarbeitung. Erst Klassifikation, dann Extraktion. Klassifikationen gemeinsam beenden. Extraktionen gemeinsam beenden. Ergebnisse aus mehreren Klassifikationen kombinieren. Ergebnisse aus mehreren Extraktionen kombinieren. Auswerten der Validierung. Umsetzung Keine Trainingskomponenten modellieren. Keine Feedbackkomponenten modellieren. Klassifikationskomponenten vor Extraktionskomponeten modellieren. Synchronisierte Zusammenführung nach parallel verlaufenden Klassifikationskomponenten. Synchronisierte Zusammenführung nach parallel verlaufenden Extraktionskomponenten. Nach Ausführung mehrerer Klassifikationskomponenten, Kombinierungskomponente modellieren. Nach Ausführung mehrerer Extraxtionskomponenten, Kombinierungskomponente modellieren. Exklusives Gateway nach Validierungskomponente modellieren. Eingaben der Nutzer profitiert, also für zukünftige Extraktionen die Fehlerrate minimiert werden kann, muss das Nutzerfeedback durch das Intellix System verarbeitet werden. Diese Verarbeitung wird im Feedbackworkflow durchgeführt. Prinzipiell werden im Feedbackworkflow die Eingaben der Nutzer nach ihrer Art des Extraktionsfehlers analysiert und dann, für jeden Klassifikator einzeln, verarbeitet. Durch diese Verarbeitung werden die Klassifikatoren so modifiziert, dass ihre Fehlerrate bei zukünftigen Extraktionen verringert wird. Ein Feedbackworkflow wird typischerweise nach einem Extraktionsworkflow ausgeführt, weil innerhalb des Feedbackworkflows Eingaben der Nutzer verarbeitet werden, welche meist Reaktionen auf Extraktionsergebnisse darstellen. Dennoch ist das Nutzerfeedback unabhängig von den Extraktionsergebnissen, da diese Ergebnisse und die Feedbackeinträge in unterschiedlichen Datenfeldern zum Dokument gespeichert werden. Abbildung 4.3 zeigt einen Feedbackworkflow in der BPMN Notation. KNN Document Analyse KNN Feedback DB KNN Reducing DB Colonial Document Analyse Colonial Feedback DB Colonial Reducing DB Abbildung 4.3: Intellix Feedbackworkflow in BPMN Notation Im Feedbackworkflow gibt es drei verschiedene Arten von Komponenten, die alle aufeinander aufbauen. Als erstes gibt es für jeden Klassifikations- oder Extraktionsalgorithmus eine Analysekomponente, die die verschiedenen Feedback- 50 Kapitel 4 Konzept

59 einträge zu Gruppen ähnlicher Extraktionsfehler zusammenfasst. Die daraus folgenden Gruppen von Extraktionsfehlern werden an eine Feedbackverarbeitungskomponente weitergeleitet. Diese Komponente passt nun den jeweiligen Klassifikator eines Algorithmus mithilfe des Nutzerfeedbacks an. Die Modifikation der Klassifikatoren dient dazu, die Fehlerrate der Extraktionsergebnisse zu verringern. Als letztes wird noch, durch die Reduzierungskomponente, eine Reduzierung des Modellraums vorgenommen, in dem nicht mehr benötigte Daten gelöscht werden. Dieser gesamte Feedbackprozess kann für jeden Klassifikations- beziehungsweise Extraktionsalgorithmus parallel durchgeführt werden. Die drei unterschiedlichen Arten von Komponenten müssen jedoch pro Algorithmus sequentiell ausgeführt werden. Bedingungen Auch für den Feedbackworkflow gibt es Bedingungen, die erfüllt werden sollten, damit der Workflow nach der Modellierung fehlerfrei abgearbeitet werden kann. Wie auch beim Extraktionsworkflow, sollten im Feedbackworkflow keine Trainingskomponenten modelliert werden. Die Trainingskomponenten beinhalten Methoden, mit denen Klassifikatoren erstellt werden können und die Feedbackkomponenten modifizieren diese Klassifikatoren mithilfe der Feedbackeinträge. Komponenten zur Dokumenttypklassifikation und zur Indexdatenextraktion sollten in Feedbackworkflows auch nicht zum Einsatz kommen, weil die Extraktionsergebnisse zwischen der Analyse und Verarbeitung der Feedbackeinträge und dem Reduzieren der Klassifikatoren nicht verändert werden sollten. In einem Feedbackworkflow müssen alle drei Phasen des Feedbackprozesses abgearbeitet werden. Es sollte also überprüft werden, dass, wenn für einen Algorithmus eine Komponente ausgeführt wird, auch die zwei dazugehörigen Komponenten modelliert wurden. Da der gesamte Feedbackprozess für unterschiedliche Algorithmen parallel ausgeführt werden kann, muss überprüft werden, ob die Feedbackprozesse bei einer parallelen Verarbeitung vor dem Ende des Workflows synchronisiert werden. Tabelle 4.4 zeigt eine Übersicht aller Bedingungen für die Modellierung eines Feedbackworkflows. Bedingung Tabelle 4.4: Bedingungen für Feedbackworkflows Kein Trainieren von Klassifikatoren. Umsetzung Keine Trainingskomponenten modellieren. Keine Klassifikation oder Extraktion. Keine Klassifikationskomponenten oder Extraktionskomponenten modellieren. Vollständiger Feedbackprozess. Feedbackprozesse gemeinsam beenden. Je eine Analysekomponente, Verarbeitungskomponente und Reduzierungskomponente pro Algorithmus modellieren. Synchronisierte Zusammenführung nach parallel verlaufenden Feedbackprozessen. 4.1 Intellix Workflows 51

60 4.1.4 Allgemeine Bedingungen Alle Intellix Komponenten benötigen einen Extraktionsauftrag (Job), entweder um Daten, wie zum Beispiel Trainingsdokumente, aus diesem Objekt zu nutzen oder um Daten, wie zum Beispiel Extraktionsergebnisse, in dieses Objekt zu schreiben. Zu Beginn der Abarbeitung eines Workflows muss dieser Extraktionsauftrag verfügbar sein, damit dieser jeder Komponente zur Verfügung steht. Vor der Beendigung eines Workflows muss dieser Extraktionsauftrag wieder entnommen werden, damit die Ergebnisse der Workflows verwendet werden können. Das Einlesen des Extraktionsauftrags in den Workflow kann automatisch durch die Activiti Laufzeitumgebung erfolgen. Für die Entnahme jedoch, muss in jedem Workflow eine spezielle Aktivität modelliert werden, welche es ermöglicht den veränderten Extraktionsauftrag vor der Beendigung des Workflows zu entnehmen. Es muss also überprüft werden, ob die jeweils letzte Aktivität in einem Intellix Workflow ein Empfangstask (siehe Tabelle 4.6) ist. Weiterhin sollte überprüft werden, ob jede Komponente vom Startereignis aus erreichbar ist, damit sichergestellt ist, dass eine modellierte Komponente auch abgearbeitet wird. Außerdem sollte jede Komponente auch zu einem Endereignis führen, damit wiederum sichergestellt ist, dass die Ergebnisse der Komponenten am Ende eines Workflows im Extraktionsauftrag enthalten sind. Tabelle 4.5 zeigt in einer Übersicht alle allgemeinen Bedingungen für Intellix Workflows. Bedingung Tabelle 4.5: Allgemeine Bedingungen für Intellix Workflows Entnahme des Extraktionsauftrags vor Beendigung eines Workflows. Extraktionsauftrag sollte vom Startereignis zu jeder Komponente laufen können. Extraktionsauftrag sollte von jeder Komponente zum Endereignis laufen können. Umsetzung Modellierung eines Empfangstask direkt vor jedem Endereignis. Alle Komponenten müssen vom Startereignis erreichbar sein. Das Endereignis muss von jeder Komponente aus erreichbar sein. 4.2 MODELLIERUNGSWERKZEUG Das verwendete Modellierungswerkzeug sollte in der Lage sein, die im letzten Abschnitt ausgearbeiteten Intellix Workflows zu modellieren. Der Activiti Designer kann Prozessdiagramme in BPMN 2.0 Notation erstellen. Dieser Editor hat zwar keine vollständige Unterstützung aller BPMN 2.0 Komponenten, aber wie in der Tabelle 3.2 gezeigt wurde, reichen die vorhandenen Elemente aus, um Intellix Workflows zu modellieren. Der Komponentenliste des Editors sollten die Intellix Komponenten hinzugefügt werden. Im Activiti Designer ist es zwar möglich für jede Intellix Komponente einen Service-Task zu modellieren und diesen mit der jeweiligen Intellix Komponente zu verknüpfen, jedoch muss dafür der vollständige Paketund Klassenname dieser Komponente bekannt sein. Zusätzlich zur allgemeinen Aufgabe der BPMN Notation (siehe 4.1) existieren verschiedene Typen von Aufgaben, je nach der Form der Abarbeitung der beinhaltenden Aktivität. Tabelle Kapitel 4 Konzept

61 Table 10.9 Send Task model associations Attribute Name Description/Usage messageref: Message [0..1] A Message for the messageref attribute MAY be entered. This indicates that the Message will be sent by the Task. The Message in this context is equivalent to an out-only message pattern (Web service). One or more corresponding outgoing Message Flows MAY be shown on the diagram. However, the display of the Message Flows is NOT REQUIRED. The Message is applied to all outgoing Message Flows and the Message will be sent down all outgoing Message Flows at the completion of a single instance of the Task Types of Tasks operationref: Operation This attribute specifies the operation that is invoked by the Send Task. There are different types of Tasks identified within BPMN to separate the types of inherent behavior that Tasks might represent. implementation: The list of Task string types = MAY be This extended attribute along specifies with any corresponding the technology indicators. that will A Task be used which to is send not further and receive the specified ##webservice is called Abstract Task (this Messages. was referred to Valid as the values None Task are "##unspecified" in BPMN 1.2). The for notation leaving of the Abstract implementation Task is shown in Figure technology open, "##WebService" for the Web service technology or a URI identifying any other technology or coordination protocol A Web service is the Service Task default technology. A Service Task is a Task that uses some sort of service, which could be a Web service or an automated application. Receive A Service Task object shares the same shape as the Task, which is a rectangle that has rounded corners. However, there is a graphical marker in the upper left corner of the shape that indicates that the Task is a Service Task (see Figure A 10.11). Receive Task is a simple Task that is designed to wait for a Message to arrive from an external Participant Tabelle 4.6: BPMN Aufgabetypen (relative to the Process). Once the Message has been received, the Task is completed. A Service Task is a rounded corner rectangle that MUST be drawn with a single thin line and includes a marker that Element The distinguishes actual Participant the shape from from other which Task Name the types Message (as shown is in received Figure 10.11). can be identified by connecting Beschreibung the Receive Task to a Participant using a Message Flows within the definitional Collaboration of the Process see Table A Receive Task is often used to start a Process. In a sense, the Process is bootstrapped by the receipt of the Message. In order for the Receive Task to instantiate the Process its instantiate attribute MUST be set to true and it MUST NOT have any incoming Sequence Flow. Service-Task A Receive Task object shares the same shape as the Task, which is a rectangle that has rounded corners. However, there is an unfilled envelope marker (the same marker as a catch Message Event) in the upper left corner of the shape that indicates that the Task is a Receive Task. Figure A Service Task Object A Receive Task is a rounded corner rectangle that MUST be drawn with a single thin line and includes an unfilled envelope The Service marker Task that inherits distinguishes the attributes the and shape model from associations other Task of Activity types (as (see shown Table 10.3). in Figure In addition 10.15). the If following the instantiate attribute constraints is are set introduced to true, the when envelope the Service marker Task looks references like a an Message Operation: Start The Event Service (as Task shown has in exactly Figure one 10.16). inputset and at most one outputset. It has a single Data Input with an ItemDefinition equivalent to the one defined by the Message referenced by the inmessageref attribute of the associated Operation. If the Operation defines output Messages, the Service Task has a single Data Output that has an ItemDefinition equivalent to the one defined by the Message referenced by the outmessageref attribute of the associated Operation. The actual Participant whose service is used can be identified by connecting the Service Task to a Participant using a Message Flows within the definitional Collaboration of the Process see Table Figure A Receive Task Object Empfangstask Ein Service-Task beschreibt eine automatisierte Funktion, wie den Aufruf einer externen Anwendung oder eines Web Services. Ein Empfangstask wartet auf eine Nachricht von einem externen Sender (relativ zum Prozess). Business Process Model and Notation, v zeigt die zwei benötigten Aufgabetypen der BPMN Notation. Neben diesen beiden Aufgabentypen 158 gibt es noch Business Process Model zahlreiche and Notation, v2.0 weitere Typen von Aufgaben. Entweder bei der Modellierung oder der Übernahme der Prozessdefinitionen in das Intellix System sollte eine Überprüfung der im Abschnitt 4.1 aufgestellten Bedingungen durchgeführt werden. Wenn diese Überprüfung gleich durch das Modellierungwerkzeug durchgeführt wird, kann schon während der Modellierung eines Intellix Workflows überprüft werden, ob dieser im Intellix System fehlerfrei arbeitet. 4.3 INTEGRATION In Bezug auf das WfMC Referenzmodell (siehe 2.3.1) liegt der Fokus dieser Arbeit auf den Schnittstellen 1 und 3. Die Workflowmodelle, die über die Schnittstelle 1 dem WfMS zugänglich gemacht werden, sind die Extraktionspläne des Intellix Systems. Die Aufgabe dieser Schnittstelle wird vom Repository Service der Activiti API übernommen. Dieser Service liest die modellierten Workflowsbeschreibungen ein und speichert sie als ausführbare Prozessdefinitionen. Innerhalb der Laufzeitumgebung (engl. Workflow Enactment Service) können dann, durch eine Workflow Engine, Prozessinstanzen dieser Prozessdefinitionen erzeugt werden. Die Schnittstelle 3, welche die Intellix Komponenten aus den Prozessinstanzen heraus aufruft und Ergebnisse von diesen entgegen nimmt, kann implizit durch das Laufzeitsystem der Activiti API gesteuert werden. Für die Schnittstelle 2 steht in der Activiti BPM Plattform die Komponente Activiti Explorer zur Verfügung. Der Explorer bietet ein Aufgabenmanagement an, mit dem manuelle Aktivitäten überwacht und ausgeführt werden können. Da in Intellix Workflows keine manuellen Aktivitäten verwendet werden, muss diese Komponente nicht genutzt werden. Für die Schnittstelle 5, welche Administrations- und Kontrollwerkzeuge mit dem Laufzeitsystem verbindet, gibt es zwei Möglichkeiten der Umsetzung. Entweder kann die Activiti Probe (siehe ) Komponente genutzt werden oder es wird das vorhandene Loggingsystem des Intellix Frameworks zu einem Administrations- und Kontrollwerkzeug ausgebaut. Bei der Dokumenttypklassifikation und Indexdatenextraktion sollen, wenn möglich, auch verteilte Modellräume (siehe 3.1.1) mit anderen Klassifikatoren genutzt werden, um fehlende Indexdaten zu ermitteln. Dieses Vorgehen kann man auf unterschiedliche Weise umsetzen. Eine Möglichkeit wäre, den Extraktionsworkflow 4.3 Integration 53

62 an ein verteiltes System zu delegieren. Diese Methode kann man durch die Umsetzung der Schnittstelle 4 ermöglichen. Eine andere Möglichkeit wäre, den Modellraum von einem verteilten System zu beziehen und den Extraktionsworkflow auf dem aktuellen System zu wiederholen. Das Activiti Laufzeitsystem (runtimeservice) soll in die bestehende Struktur des Intellix Frameworks integriert werden. Im Abschnitt wurden diese Strukturen vorgestellt. Das heißt, dass es weiterhin eine Repräsentation für einen Workflow geben soll, jedoch nur noch eine Klasse für alle Workflows. Diese Klasse steuert die Ausführung der Intellix Workflows mittels des Activiti Laufzeitsystems. Weiterhin soll ein Extraktionsauftragsprozessor analog zum Bestehenden geschaffen werden, der mittels des Activiti Laufzeitsystems und des Modell Repositories, Workflows verwaltet und ausführt. 4.4 FAZIT In diesem Kapitel wurde dargestellt, wie sich das WfMS Activiti in das Intellix Framework integrieren lässt. Mit einer erfolgreichen Implementierung dieses Konzepts sollte es möglich sein, ohne detaillierte Kenntnisse vom Intellix Framework, einen Intellix Workflow mit einem Modellierungswerkzeug der Activiti BPM Plattform zu bearbeiten oder zu verändern. Mit dem Speichern dieses Modells an einem bestimmten Ort, kann dieser erstellte oder geänderte Workflow bei der nächsten Abarbeitung eines Extraktionsauftrags genutzt werden. Eine Web Anwendung oder die Ausgabe von Statusmeldungen kann es dann möglich machen, den Status des Workflows einzusehen und gegebenenfalls zu manipulieren. 54 Kapitel 4 Konzept

63 5 IMPLEMENTIERUNG Die Modellierung der einzelnen Workflowbeschreibungen für das Intellix System erfolgt durch ein Eclipse Plugin, welches BPMN 2.0 Diagramme für die Activiti BPM Plattform erstellen kann. Mit einigen Anpassungen an diesem Plugin können auch Intellix Workflowbeschreibungen mit diesem Designer erstellt und bearbeitet werden. Damit die Workflowbeschreibungen durch das Intellix System verwaltet und aus diesem heraus ausgeführt werden können, werden einzelne Komponenten der Activiti BPM Plattform in das Intellix Framework integriert. Im Abschnitt 5.1 wird zuerst die Anpassung des Activiti Designer Eclipse Plugins beschrieben. Diese Anpassung hat das Ziel Intellix Workflows mit diesem Editor möglichst einfach modellieren zu können. Danach wird im Abschnitt 5.2 auf die Integration der Activiti BPM Plattform in das Intellix Framework eingegangen. Diese Integration hat zum Ziel, dass die Verwaltung der Prozessdefinitionen von einer Activiti Komponente übernommen wird und dass die Instanziierung und Steuerung der Prozessinstanzen ebenfalls von eingebetteten Activiti Komponenten durchgeführt wird. 5.1 MODELLIERUNG Das Activiti BPMN 2.0 Eclipse Plugin 1 (kurz Activiti Designer) ist eine Komponente der Activiti BPM Plattform. Die Funktionen dieses Eclipse Plugins wird im Abschnitt näher beschrieben. Dieses Modellierungswerkzeug stellt grundlegende Methoden bereit, die für die Modellierung von Intellix Workflows gebraucht werden. Es sind jedoch einige Anpassungen nötig, damit Nutzer des Intellix Systems möglichst einfach Workflowbeschreibungen für Intellix Workflows erstellen und bearbeiten können. Im Activiti Designer ist es möglich Service-Tasks zu erstellen und somit Komponenten aus dem Intellix Framework aufzurufen. Diese Methode setzt aber voraus, dass man einerseits den genauen Paket- und Klassennamen dieser Komponenten kennt und dass man andererseits weiß, welche Komponenten im Intellix Framework überhaupt verfügbar sind. Es ist also besser, wenn alle verfügbaren Komponenten im Activiti Designer als Auswahl zur Verfügung stehen. Wie diese Erweiterung dem Activiti Designer hinzugefügt wird, wird

64 im Abschnitt näher erläutert. Eine weitere sinnvolle Anpassung ist die Überprüfung der erstellten, beziehungsweise geänderten Intellix Workflowbeschreibungen. Dies hat den Vorteil, dass die vom Anwender erstellten Workflowmodelle vor dem Export in eine XML-Beschreibung auf ihre Lauffähigkeit überprüft werden. Die Umsetzung dieser Überprüfung wird im Abschnitt näher beschrieben Activiti Designer Erweiterungen Eine wichtige Ergänzung zum Activiti Designer ist die Auflistung aller möglichen Intellix Komponenten bei der Modellierung einer Prozessdefinion, sodass der Nutzer weder den Klassennamen noch die Paketzugehörigkeit einer Komponente kennen muss, um sie in ein Prozessdiagramm einzufügen oder sie gegen eine andere Komponente auszutauschen. Außerdem ist es hilfreich, alle nicht benötigten Modellierungselemente auszublenden. Die Entwickler des Activiti Designers haben eine einfache Methode implementiert, durch sogenannte Custom Service Tasks vordefinierte Service-Tasks der Komponentenliste hinzuzufügen 2. Auch das Entfernen einzelner vorinstallierter BPMN 2.0 Elemente ist mit dieser Methode möglich. Das Hinzufügen von vordefinierten Service-Tasks geschieht durch das Erstellen einer Unterklasse der abstrakten Klasse AbstractCustomServiceTask. Für jede Komponente muss eine eigene Klasse entworfen werden. Die Eigenschaften und Verhaltensweisen dieser Custom Service Tasks wird in dieser Klasse durch Überschreiben von Methoden oder dem Hinzufügen von Annotationen bewerkstelligt. Zum Beispiel wird der Klassenname der auszuführenden Komponente durch das Attribut delegationclass in der festgelegt. Abbildung 5.1 zeigt die benötigten Methoden und Annotationen für die Custom Service Tasks in einem Klassendiagram. Das Verändern der urspünglichen Komponentenliste wird wiederum durch das Erstellen einer Subklasse der Klasse AbstractDefaultPaletteCustomizer erreicht. In dieser Klasse wird eine Methode erstellt, welche eine Liste mit PaletteEntry Objekten zurück liefert. Diese Liste muss alle Elemente enthalten, die in der Komponentenliste ausgeblendet werden sollen. Mit dieser Methode ist es somit möglich, vorhandene BPMN 2.0 Elemente zu entfernen. Am Ende müssen diese Klassen inklusive der Piktogramme für die Custom Service Tasks in ein Java Archive zusammengefasst werden und in einem Eclipse Java Projekt als User Library verfügbar gemacht werden. Wenn keine Piktogramme hinterlegt werden, wird ein Standardpiktogramm für Custom Service Tasks verwendet. Das Ergebnis der Anpassung für das Intellix Framework im Vergleich zur originalen Komponentenliste des Activiti Designers ist in der Abbildung 5.2 zu sehen Kapitel 5 Implementierung

65 designer.integration.servicetask intellix.processing.designer annotation <<interface>> Help displayhelpshort() : String displayhelplong() : String <<interface>> Runtime helper CombinerComponent contributetopalettedrawer() : String getname() : String getorder() : Integer getsmalliconpath() : String delegationclass() : String classification AbstractCustomServiceTask contributetopalettedrawer() : String getname() : String getsmalliconpath() : String getorder() : Integer extraction feedback Abbildung 5.1: Integration von Intellix Komponenten in die Activiti Designer Palette Gültigkeitsprüfung für Intellix Workflows Im Abschnitt 4.1 wurden bezüglich der Intellix Workflows Bedingungen vorgestellt, die erfüllt sein müssen, damit diese sinnvoll und fehlerfrei von einem WfMS abgearbeitet werden können. Nun hat es gewisse Vorteile, wenn diese Bedingungen gleich in der Modellierungsphase, wie es die Anforderung A2.3 (siehe 3.3.2) vorgibt, geprüft werden. Durch das Erstellen eines Eclipse Plugins, welches an das Activiti BPMN 2.0 Eclipse Plugin andockt, kann diese zusätzliche Prüfung für Intellix Workflows erreicht werden. Das Eclipse Plugin für den Activiti Designer muss eine Klasse enthalten, die von der Klasse AbstractProcessValidator abgeleitet ist. In dieser Klasse kann man nun in der Methode validatediagram eine Prüfung des Diagramms durchführen. Diese Prüfung kann dann der Eclipse Anwender in den Einstellungen zum Activiti Designer indirekt aktivieren. Indirekt deshalb, weil es nur möglich ist, Exportmodule und nicht direkt Diagrammvalidierungen im Activiti Designer zu aktivieren. Also muss zusätzlich eine Export-Klasse erstellt werden, welche eine Subklasse der Klasse AbstractExportMashaller sein muss. Von dieser Klasse wird jedoch nicht direkt geerbt, sondern von einer der Unterklassen dieser abstrakten Klasse mit dem Namen BPMN20ExportMarshaller. Somit wird die gleiche XML- Datei erstellt, die auch vom voreingestellten Exportmodul generiert wird. In dieser Export-Klasse kann nun die vorher erstellte Gültigkeitsprüfung aufgerufen werden. Abbildung 5.3 zeigt nochmal die beschriebene Struktur in einem Klassendiagramm. 5.1 Modellierung 57

66 (a) Original (b) Angepasst Abbildung 5.2: Orginale (a) und angepasste (b) Komponentenliste des Activiti Designers Die Prüfung der im Konzept ausgearbeiteten Bedingungen (siehe 4.1) für die Intellix Workflows kann nun durch die Methode validatediagram durchgeführt werden. Trotz dieser Überprüfungen, der vom Intellix Anwender erstellten Prozessdiagramme, können die erzeugten Workflows Fehler beinhalten oder nicht wie erwartet ablaufen. Zum Beispiel kann bei der Modellierung eines Trainingsworkflows eine Komponente genutzt werden, die das Modell in einer Datenbank speichert. Bei der Modellierung des zugehörigen Extraktionsworkflow wird eine Extraktionskomponente modelliert, die das Modell vom Dateisystem beziehen will. Dies wird zwangsläufig zu einem fehlerhaften Verhalten führen, wenn nicht zufällig ein passendes Modell im Dateisystem existiert. Die Prüfung des Activiti Designers soll jedoch den Anwender dabei unterstützen, essentielle Fehler innerhalb einer Prozessdefinition schon in der Modellierungsphase zu entdecken und zu korrigieren. Die folgenden Abschnitte geben einen Überblick, welche Bedingungen in welcher Form umgesetzt wurden. 58 Kapitel 5 Implementierung