ESProNa - Eine Constraintsprache zur multimodalen Prozessmodellierung und navigationsgestützten Ausführung

Universität Bayreuth Lehrstuhl für Angewandte Informatik IV Datenbanken und Informationssysteme ESProNa Eine Constraintsprache zur multimodalen Prozessmodellierung und navigationsgestützten Ausführung Dissertation zur Erlangung des akademischen Grades Doktor der Naturwissenschaften (Dr. rer. nat.) vorgelegt von Dipl.-Inform. Michael Igler Bayreuth - 2011 Erstgutachter: Prof. Dr.-Ing. Stefan Jablonski, Universität Bayreuth Zweitgutachter: Prof. Dr. Marc Erich Latoschik, Universität Würzburg Einreichung: 03.11.2011 Kolloquium: 31.07.2012 Verfasst unter der Betreuung von/Thesis written under supervision (advisor) of Prof. Dr.-Ing. Stefan Jablonski Professor am Lehrstuhl für Angewandte Informatik IV, Universität Bayreuth Verfasst unter der Begutachtung von/Thesis written under supervision (co-advisor) of Prof. Dr. Paulo Moura Assistant Professor at the Dep. of Computer Science, University of Beira Interior, Portugal „Damit das Mögliche entsteht, muss immer wieder das Unmögliche versucht werden.“ Hermann Hesse „To achieve the possible, you must try to achieve the impossible.“ Hermann Hesse Zusammenfassung Deklarative Prozessmodellierungssprachen erfreuen sich aufgrund ihrer Ausdrucksstärke und der kompakten Prozessmodelle einer immer größer werdenden Beliebtheit. Ziel dieser neuen Art der Modellierung ist es, Geschäftsprozesse einfacher und effizienter aufnehmen zu können. Ein bekanntes Konzept aus den deklarativen Programmiersprachen, die strikte Trennung zwischen Problemstellung und Lösung, wird auf den Bereich der Prozessmodellierung übertragen. Somit wird eine Vereinfachung der zu modellierenden Geschäftsprozesse erreicht. Um die Prozesse in ihrer Gesamtheit zu erfassen, wird das Konzept der perspektivenorientierte Prozessmodellierung (POPM) verwendet. Weiterhin werden neben den Anforderungen an eine Prozessmodellierungssprache zusätzliche Konzepte erarbeitet, die für eine effiziente Modellierung von Geschäftsprozessen sinnvoll sind. Die im ersten Kapitel der Arbeit angesprochenen Probleme aktueller Prozessmodellierungssprachen werden in den nachfolgenden Kapiteln aufgegriffen und gelöst. Neue Forschungsergebnisse, wie etwa die entwickelte Prozessnavigation zur navigationsgestützten Ausführung der erstellten Geschäftsprozesse oder das Modellieren von subjektiven Empfehlungen, werden ebenfalls behandelt. Durch letzteres Konzept kann das empirische Verhalten der Geschäftsprozesse modelliert und zum Zeitpunkt der Ausführung präsentiert werden. Es wurden nicht nur die Konzeptionen und Lösungen der Problemstellungen erarbeitet, sondern auch gezeigt, wie diese implementiert und verwendet werden können. Alle Ergebnisse der vorliegenden Arbeit sind in der deklarativen Prozessmodellierungssprache ESProNa umgesetzt. Abstract Declarative process modeling languages enjoy an increasing popularity in research through its expressiveness and brief process models. One of the goals of this new technique is to simplify the layout of business processes. As a result of that style, based on the separation of concerns between problem and solution, a simplification of the desired process models can be achieved. The ultimate goal of our research is the accurate and consistent representation of business processes. This is achieved by using a Perspective-Oriented Process Modeling (POPM) technique. The exploration presents concepts which recognize the previously mentioned goals. Beside the elaborated requirements on a process modeling language, different additional concepts are developed which are useful for efficient modeling of business processes. Within the first chapter complications are mentioned that are discussed and solved in succeeding chapters. The newly developed process navigation has proven to support proper execution of business processes. By using the concept of modeling recommendations the empirical behavior of business processes can be modeled and presented at runtime. Concepts and solutions have proven to show a beneficial use in achieving business processes. ESProNa is the business process language that has come from this study. 16 Problemstellung „Viele Wege führen nach Rom“. Dieser Satz wird häufig verwendet, um auszudrücken, dass es mehrere Lösungen zu einem Problem gibt und diese sehr vielfältig und individuell sein können. Auch wenn es unter der Menge der verschiedenen Lösungen „bessere“ und „schlechtere“ gibt, so haben doch alle Lösungen das gleiche Ziel vor Augen: einen „Weg nach Rom“ zu beschreiben. Ein weiterer Gesichtspunkt neben der Vielzahl an Wegen ist die in dieser Aussage assoziierte Entscheidungsfreiheit des „Reisenden“. Es bleibt ihm überlassen, welchen Weg er wählen möchte, solange er das Ziel „Rom“ beibehält. Die Entscheidungen können dabei von vielen Kriterien und Gegebenheiten abhängen und von Person zu Person unterschiedlich sein. Für den einen ist das Kriterium Benzinverbrauch wichtig, für einen anderen die Zeitdauer der Reise, für eine dritte Person sind es die Sehenswürdigkeiten entlang der Route. Weiterhin können sich diese Kriterien auch situationsbedingt ändern, das heißt, bei schlechtem Wetter nimmt man lieber die direkte Route, bei schönem die mit den meisten Sehenswürdigkeiten. Insgesamt hat der Reisende sehr viele Möglichkeiten sich zu entscheiden, um seinen individuellen Weg auszuwählen und zu gehen. Andererseits sind aber bestimmte Regeln zu beachten: Es müssen zum Beispiel Straßen vorhanden sein oder aber die Verkehrsregeln auf dem Weg zum Ziel berücksichtigt werden. Weiterhin können bei bestimmten Routen Mautgebühren anfallen, die natürlich vor Antritt der Reise bekannt sein sollten. Doch solange all diese Regeln eingehalten werden, steht der Individualität und Kreativität des Reisenden prinzipiell nichts im Wege. Ganz ähnlich wie bei der „Reise nach Rom“ verhält es sich auch bei der Prozessmodellierung und der Ausführung. Situationsbedingt muss es möglich sein, unterschiedliche Entscheidungen an bestimmten Punkten eines Prozesses bzw. Workflows treffen zu können. Dieses empirische Verhalten findet sich auch in unserem alltäglichen Leben wieder, sodass es auch in Prozessmodelle mit integriert werden muss. Damit die Entscheidungsfreiheit in einem Workflow zur Verfügung gestellt werden kann, muss sie allerdings auch in das Prozessmodell mit aufgenommen werden. Der Begriff Agilität, der unser alltägliches Handeln im Alltag in seiner Flexibilität und Individualität zusammenfasst, umschreibt dieses Konzept sehr treffend. Das nächste Unterkapitel zeigt, warum aktuelle PMS Probleme damit haben. 1.2 Probleme aktueller Modellierungssprachen Das angeführte Beispiel „Viele Wege führen nach Rom“ dient dabei als Motiv für den Forschungsbereich PMS. Fakt ist, dass nach menschlichen Erfahrungswerten Dinge oft auf verschiedene Art und Weise erledigt werden können. Diese Individualität ist erlaubt, solange keine Regeln verletzt werden. Ob nun die eine oder die andere Lösung die bessere oder schlechtere ist, sei vorerst einmal dahingestellt. Es geht im Wesentlichen zunächst darum, unser menschliches und individuelles Verhalten (in Bezug auf die Abläufe in Unternehmen) möglichst gut abbilden zu können. Und genau darin liegt das Problem der aktuellen PMS, das sich zum einen in sehr komplexen Prozessmodellen äußert und zum anderen darin, dass nicht der ganze Sachverhalt abgedeckt wird. Diese beiden Kritikpunkte gilt es zunächst genauer zu erläutern. 1.2.1 Komplexität bei agilen Prozessmodellen „Was nicht explizit erlaubt ist, ist verboten“. Diesem Grundgedanken folgen die meisten kommerziellen PMS. Für die zugrunde liegenden Geschäftsprozesse bedeutet dies, dass 1.2. Probleme aktueller Modellierungssprachen 17 jeder mögliche Ablauf (das heißt, jeder „Weg nach Rom“) explizit im Prozessmodell durch einen bestimmten Ablaufpfad modelliert werden muss. Für sehr strikte Prozessabläufe, das heißt, es wird explizit gewünscht, dass es nur genau einen möglichen Ablauf geben kann, stellt dies kein Problem dar. Für sehr agile Unternehmensabläufe allerdings ist dieser restriktive Ansatz ein Problem: Nicht alle Abläufe von Ausführungspfaden können explizit modelliert werden. Die Anzahl der einzelnen Pfade ist einfach zu groß. Als Beispiel [8] seien hier drei Prozesse (einfachheitshalber A, B und C genannt) gewählt, bei denen B zwischen einund dreimal (1..3) durchgeführt werden kann. Alle drei Prozesse müssen nacheinander und in genau dieser Reihenfolge ablaufen. Der Freiraum besteht nun darin, es dem Prozessausführenden zu überlassen, wie oft er Prozess B ausführen möchte. Allerdings muss diese Entscheidung vor der Ausführung von Prozess C getroffen werden. Transferiert auf das Prozessmodell bedeutet dies, dass darin sechs explizite Ausführungspfade aufgenommen werden müssten. Abbildung 1.1 zeigt das erstellte Prozessmodell mit den verschiedenen Ablaufszenarien; es verschleiert aber die eigentliche Prozessbeschreibung, das heißt, die Semantik der Prozesse ist nicht mehr erkennbar. Unter Bezug auf den Grundsatz „Was nicht explizit erlaubt ist, ist verboten“ bedeutet dies, dass, falls nicht jeder dieser Abläufe modelliert wird, er während der Ausführung auch nicht zur Verfügung steht. Somit ist der Modellierer gezwungen, jedes noch so kleine Stückchen Flexibilität explizit zu modellieren. Oft ist dies aber aufgrund der Tatsache, dass die resultierenden Prozessmodelle zu komplex und vor allem auch zu zeitaufwendig in der Erstellung werden, nicht möglich. Außerdem muss dabei beachtet werden, dass die Flexibilität, die zur Modellierungszeit nicht mit in das Prozessmodell aufgenommen wurde, konsequenterweise zur Ausführungszeit auch nicht zur Verfügung steht. Daraus folgt während der Abarbeitung von Prozessmodellen, dass eine softwaregestützte Prozessausführung diese Agilität auch nicht zur Verfügung stellen kann, da sie im Prozessmodell nicht definiert wurde. A B AND BBB AND Merge C AND BB AND Start Ende XOR Abbildung 1.1: Drei Prozesse in bestimmter Ausführungskomposition Möchte der Prozessmodellierer aber die Freiheit lassen, die Ausführungsreihenfolge einzelner Prozessschritte selbst zu wählen, so ergibt sich ein ähnliches Problem, das folgendes Beispiel verdeutlicht: Auszugehen ist wieder von den drei Prozessschritten A, 18 Problemstellung B und C. Jeder Schritt wird diesmal nur genau einmal durchgeführt, und während seiner Abarbeitung darf kein anderer Prozess parallel ablaufen, das heißt, jeder Prozess besitzt exklusive Ausführungsrechte. Die Flexibilität besteht hier darin, dass A, B und C in beliebiger Reihenfolge abgearbeitet werden können. B C XOR B C C B A C C A B A A B A XOR XOR XOR XOR XOR XOR XOR Start Ende Abbildung 1.2: Drei Prozesse in beliebiger Ausführungsreihenfolge Im Prozessmodell in Abbildung 1.2 ist diese Ausführung umgesetzt. Bei den drei genannten Prozessen ergeben sich 3! mögliche Abläufe (= 6 Lösungswege), die alle explizit im Modell abgebildet wurden. Nimmt man nun beispielsweise 5 verschiedene Prozessschritte an, so ergeben sich bereits 5! (= 120) mögliche Lösungswege, die alle im Modell untergebracht werden müssten. Das ist für den Modellierer eine sehr zeitaufwendige und müßige Arbeit, nur um auszudrücken, dass die Prozesse in beliebiger Reihenfolge ausgeführt werden können! Dieses Problem ließe sich umgehen, wenn man benutzerdefinierte Modellierungskonstrukte einführt und diese mit einer konkreten Bedeutung für zum Beispiel die Ausführungsreihenfolge belegt. Als Beispiel sei hier ein gestrichelter Pfeil gewählt, der, genau wie der bisherige durchgezogene Pfeil, zwei Prozesse miteinander verbindet. Allerdings wird seine Bedeutung gegenüber dem durchgezogenen Pfeil insoweit abgeändert, als nun die Ausführungsreihenfolge der miteinander verbundenen Prozesse beliebig ist. Das Prozessmodell aus Abbildung 1.3 zeigt, wie durch die Verwendung des neuen Modellierungskonstrukts, das Prozessmodell aus Abbildung 1.2 stark vereinfacht werden kann. Der Prozessausführende kann nun mit einem der drei Prozesse A, B oder C beginnen, alle drei sind also direkt ausführbar. Die Modellierung des komplexen Ablaufverhaltens vereinfacht sich. Nur noch ein Weg muss modelliert werden, der aber den vielen Wegen aus Abbildung 1.2 semantisch äquivalent ist. Wäre es also möglich, die PMS so zu erweitern, dass benutzerdefinierte Modellierungskonstrukte möglich sind, dann könnte der Prozessmodellierer dieses Konzept nutzen, um neue Konstrukte semantisch zu definieren und somit die Pfadkomplexität zu reduzieren oder ganz zu umgehen. ABC Start Ende Abbildung 1.3: Vereinfachung der Komplexität durch neues Modellierungssymbol 1.2. Probleme aktueller Modellierungssprachen 19 Konsequenzen Fazit ist, dass Flexibilität prinzipiell zwar mit aktuellen PMS modelliert werden kann (siehe auch Kapitel 10), allerdings die erstellten Modelle dann extrem komplex werden. Folgende Erfahrungen, die sich durch fehlende Ausführungsflexibilität ergeben, sind im klinischen Umfeld gemacht worden: Der Nutzer des Workflowsystems fühlt sich in seiner Entscheidungsfreiheit stark eingeschränkt. Ausnahmen oder Abweichungen vom Standardverhalten ergeben sich aber in der Realität nur allzu oft und müssen dementsprechend auch handhabbar sein. Aktuelle WMS werden jedoch den Anforderungen in dieser Hinsicht nicht gerecht und werden deshalb nicht oder nur ungern eingesetzt. 1.2.2 Schwache Ausdrucksfähigkeit Ein weiteres Problem aktueller PMS ist ihre schwache Ausdrucksfähigkeit. Darunter versteht man, wie gut bestimmte gedankliche Vorstellungen mit einer Sprache (im vorliegenden Fall der PMS) umgesetzt bzw. modelliert werden können, hier also die detaillierten Geschäftsabläufe, die der Prozessmodellierer in ein Modell umsetzen möchte. Jedes Konzept, das sich der Modellierer vorstellt und das für den Anwendungsbereich wichtig ist, muss (effizient) modellierbar sein. Hierbei unterscheidet man nun zwei Fälle: Der erste Fall ergibt sich aus dem Problem, dass die Konzepte, die der Modellierer umsetzen möchte, mit der PMS nicht umsetzbar sind. Der zweite Fall tritt auf, wenn das erstellte Modell nur eine Approximation des realen Unternehmensablaufs darstellt. Beide Probleme müssen genauer erläutert werden. Nicht realisierbare Konzepte Als Beispiel dienen zwei Prozessschritte, wovon der erste von einem beliebigen Mitarbeiter eines Unternehmens ausgeführt werden kann; der nachfolgende Prozessschritt muss aber von dessen Vorgesetztem umgesetzt werden. Die Umsetzung genau dieser Restriktion ist mit den meisten kommerziellen PMS nicht möglich, da die benötigten Modellierungskonstrukte fehlen. In diesen PMS kann zum einen keine Beziehung zwischen den Ausführenden der beiden Prozesse hergestellt werden, und zum anderen ist die hierarchische Relation (Vorgesetztenrolle) zwischen beiden Personen in der Modellierungssprache nicht abbildbar. Als Beleg für diese These dient die Evaluierung verschiedener PMS aus [8]. Das gewählte Beispielprozessmodell wird dort als „Pattern No. 4“ bezeichnet und beschreibt den obigen Anwendungsfall der Autorisierung. Tabelle 1.1 zeigt, dass nur die Sprachen COSA und FLOWer das Konzept der Autorisierung unterstützen (durch +gekennzeichnet). Alle weiteren Mainstream-Sprachen wie etwa BPMN, jBPM oder Oracle BPEL unterstützen dieses Konzept nicht (durch -gekennzeichnet). In den gegenwärtigen PMS gibt es also bis auf die zwei genannten Ausnahmen keine Möglichkeit, die Rolle des Vorgesetzten in Abhängigkeit von einem vorangegangenen Prozess darzustellen. Und dies ist nur ein sehr einfaches Beispiel. Weitere könnten sein, dass immer der Dienstälteste oder der Außendienstmitarbeiter mit dem zugeordneten Kundenkontakt den Prozess ausführen soll. Sind diese Konzepte in der gewählten PMS nicht implementiert, so entsteht für den Modellierer ein Problem. Wäre die PMS aber an die obigen Anforderungen des Unternehmens individuell anpassbar, wäre das Problem gelöst. Der Modellierer könnte die Sprache nach den Bedürfnissen des Unternehmens ausrichten, das heißt, er könnte die obigen Rollenbeziehungen 20 Problemstellung Modellierungssprache Version unterstützt Staffware 9 - Websphere MQ Workflow 3.4 - FLOWer 3.0 + COSA 4 + iPlanet 3.1 - BPMN 1.0 - UML 2.0 - Oracle BPEL 10.1.2 - jBPM 3.1.4 - OpenWFE 1.7.3 - Enhydra Shark 2 - Tabelle 1.1: Sprachbezogene Umsetzung des Autorisierungspatterns zwischen den Personen selbst in die PMS integrieren. Somit könnten auftretende Probleme durch eine Anpassung der Sprache seitens des Modellierers gelöst werden. Allerdings entscheiden die Entwickler einer Modellierungssprache, was genau in ihr umgesetzt wird und was nicht. Der Modellierer muss damit auskommen. Durch die Evaluierung in [8] bekommen die Entwickler der jeweiligen Sprache zwar Feedback seitens der Community, welche Pattern und Modellierungskonstrukte benötigt werden, jedoch obliegt deren Umsetzung allein ihnen. Konsequenzen Die Konsequenz ist, dass obige Rollenbeziehungen nicht ins Prozessmodell mit aufgenommen werden können. Als Folge davon entstehen unpräzise Modelle, die nicht deckungsgleich mit den realen Geschäftsprozessen sind. Sie stellen nur eine Annäherung an die komplexen Sachverhalte dar. Neben der Modellierung darf man nicht vergessen, dass die entstandenen Prozessmodelle auch im Nachhinein wieder aufbereitet und verstanden werden müssen. Zu einem vorhandenen Prozessmodell möchte man den empirischen Unternehmensablauf wieder extrahieren und verstehen lernen. Dies kann zu einem späteren Zeitpunkt durch den Autor des Modells erfolgen, aber auch eine andere Person, die das Modell vorher noch nie gesehen hat, kann es benutzen, um den Unternehmensablauf zu verstehen. Allerdings ist der aus dem Prozessmodell wiedergewonnene Ablauf oft sehr unpräzise oder sogar falsch, das heißt, er ist nicht identisch mit dem, den man zum Zeitpunkt der Modellierung festhalten wollte. Zusammenfassend ergibt sich also, dass bei mangelnder Ausdrucksfähigkeit von PMS die Gefahr besteht, dass die zu modellierenden Geschäftsabläufe ungenau modelliert sind und im Nachhinein nicht korrekt reproduziert werden können. Die aus dem Modell gewonnene Information ist nicht dieselbe, die der Modellierer zum Zeitpunkt des Erstellens einbringen wollte. So entsteht ein Informationsverlust. 1.3 Ziele Aus den aufgezeigten Problemen lassen sich nun Konzepte entwickeln, die eine PMS für den Modellierer und Prozessausführenden mitbringen muss, um eine breitere Akzeptanz 1.4. Lösungsansatz 21 zu finden. Der Prozessmodellierer soll in der Lage sein, die PMS individuell den Gegebenheiten im Unternehmen anpassen zu können. Die für den Modellierer optimale PMS muss also zum einen so erweiterbar sein, dass agile Unternehmensabläufe mit der darin enthaltenen semantischen Komplexität präzise in ein Modell umgesetzt werden können, zum anderen aber auch soweit an die flexiblen Veränderungen der Geschäftsabläufe anpassungsfähig sein, dass neue Modellierungskonzepte einfach zu integrieren sind. Ein weiteres Ziel ist die Bereitstellung eines WMS, um eine Hilfestellung während der Prozessausführung zu ermöglichen. Bei der Zuteilung der Prozesse zu der Aufgabenliste der Nutzer ist es wichtig, eine effektive Auslastung zu gewährleisten. Grundvoraussetzung hierfür ist, eine flexible und agile PMS zu benutzen, die den Anwender in der Ausführung eines Prozesse nur dann einschränkt, wenn es nötig ist. Auch werden Prozessmodelle referenziert, um den semantischen Kontext von Unternehmensabläufen aus einem Prozessmodell zu extrahieren. Für diesen Punkt ist es wichtig, übersichtliche Prozessmodelle zu haben, aus denen man den semantischen Kontext einfach wiedergewinnen kann. Die gewählte PMS muss dazu einen Spagat zwischen der Inklusion aller flexiblen Abläufe und einer geringen Pfadkomplexität schaffen, also klar strukturierte und verständliche Prozessmodelle gewährleisten. Nur so ist sichergestellt, dass modellierte Geschäftsabläufe im Nachhinein auch korrekt wieder reproduziert werden können. 1.4 Lösungsansatz Blickt man auf die aktuellen Modellierungssprachen, so erkennt man darin einen sehr starken imperativen Charakter, der dem Konzept „Was nicht explizit erlaubt ist, ist verboten“ folgt. Imperativ bedeutet in diesem Kontext, dass jeder nächstmögliche Prozessschritt im Prozessmodell genau vordefiniert ist [9]. Hierbei spricht man von Determinismus. Um nun die angesprochenen Probleme aktueller PMS zu lösen, ist es notwendig, dieses sehr strikte und imperative Konzept zu ändern. 1.4.1 Von der imperativen zur deklarativen Problemformulierung Die grundlegende Idee für den Wechsel von der imperativen zur deklarativen Problemformulierung macht ein grafisches Beispiel (Abbildung 1.4) deutlich: Hier werden vom Start (links) zum Ziel (rechts) verschiedene Wege explizit modelliert. Der Ablauf eines Weges verläuft immer von links nach rechts und spiegelt jeweils einen möglichen Lösungspfad wider. Möchte man nun einen zusätzlichen Lösungsweg hinzufügen (gepunktete Linie), so muss dieser explizit beschrieben und hinzugefügt werden. Start Ziel Abbildung 1.4: Explizite Lösungswege bei imperativen Modellierungssprachen Abbildung 1.5 beschreibt die deklarative Welt als Gegensatz zu den expliziten Pfadangaben der imperativen Welt. Die grauen, rechteckigen Gebilde beschreiben die Zonen, 22 Problemstellung die verboten sind. Man kann sich also auf der weißen Fläche frei bewegen, darf aber keine der grauen Zonen betreten. Das Hinzufügen des gepunkteten Weges muss bei dieser Art der Modellierung nicht explizit erfolgen, da er, wie Abbildung 1.6 zeigt, schon enthalten und somit bereits implizit aufgenommen ist. Start Ziel Abbildung 1.5: „Verbotene Zonen“ bei deklarativen Modellierungssprachen Start Ziel Abbildung 1.6: Zusätzliche Pfade sind bereits enthalten Ähnlich wie in diesem grafischen Beispiel verhält es sich auch mit dem Wechsel von der imperativen zur deklarativen Prozessmodellierung. In Abbildung 1.4 kann man sich nur auf den gekennzeichneten Pfaden bewegen, das heißt, „Was nicht explizit erlaubt ist (der Weg), ist verboten“. Möchte man weitere Wege zulassen (gepunktete Linie), so muss man diese explizit hinzufügen. Abbildung 1.5 stellt den konträrer Ansatz dar: „Was hier nicht (durch die grauen Inseln) verboten ist, ist erlaubt.“ Flexibilität ist also nativ gegeben. Der gepunktete Lösungsweg muss, neben vielen weiteren alternativen Pfaden, nicht explizit modelliert werden, da er bereits enthalten ist. Deklarative Programmiersprachen bilden in der Informatik eine Sprachgruppe, bei der die Beschreibung des Problems im Vordergrund steht [10] [11]. Sie stellen einen Kontrast zu den imperativen Programmiersprachen dar. Man gibt die Spielregeln vor, nach denen gespielt wird, sowie den Ausgangspunkt und das Ziel. Der Lösungsweg wird automatisch berechnet. Nimmt man wieder das Beispiel des „Weges nach Rom“, so gibt man in diesem Fall also nur Start, Ziel und Zwischenstationen an sowie die Verkehrsregeln und die vorhandenen Straßen. Sudoku ist ein gutes Beispiel für die Anwendung einer deklarativen Programmiersprache und wird oft als Paradebeispiel dafür in Vorlesungen benutzt (Kapitel 3.1). Der Grundgedanke dabei ist, dass man nur die Regeln beziehungsweise Constraints des Spiels angibt sowie die Ausgangssituation, das heißt, die teilweise mit Zahlen belegte Matrix. Die Programmiersprache setzt nun sogenannte freie Variable an die unbesetzten Stellen der Sudoku-Matrix und versucht, die Werte der Variablen so zu belegen, dass sie zusammen mit den vorgegebenen Werten eine Lösung gemäß den Spielregeln bilden. Dieses Binden von Werten an die Variablen geschieht automatisch. Der Anwender oder Programmierer muss sich also nicht explizit um die Lösungsfindung kümmern, sondern programmiert lediglich die Constraints des Spiels. 1.4. Lösungsansatz 23 A #= 1 B C 1..3 #= 1 Start Ende Abbildung 1.7: Deklarative Formulierung des Prozessmodells 1.1 Bezogen auf das Prozessmodell aus Abbildung 1.1, bei dem der Prozess B zwischen einmal und dreimal ausgeführt werden kann, muss also im deklarativen Fall nur dieses Constraint modelliert werden („1..3“ im Prozess B in Abbildung 1.7). Die Regeln innerhalb der Prozesse markieren, wie oft diese ausgeführt werden dürfen. Das ist bei Prozess B auf den ersten Blick bereits klar. Der Leser muss nicht erst die einzelnen Pfade im Modell nachverfolgen, um das extrahieren zu können. Man stelle sich nun vor, man müsste die beiden imperativen Prozessmodelle aus den Abbildungen 1.1 und 1.2 kombinieren. Zum Prozessmodell aus Abbildung 1.1 kommt hinzu, dass die Prozesse A, B und C in beliebiger Reihenfolge ausführbar sind. Mit dem neuen Modellierungssymbol des gestrichelten Pfeils ist dies kein Problem mehr. Zusammen mit dem Constraint in Prozess B, das die mögliche Anzahl an Ausführungen wiedergibt, erhält man das in Abbildung 1.8 dargestellte, sehr kompakte Prozessmodell. Die imperative Variante hingegen würde aus 48 expliziten Pfadangaben bestehen und ist aus Platzgründen hier nicht aufgeführt. A #= 1 B C 1..3 #= 1 Start Ende Abbildung 1.8: Deklarative Komposition der Prozessmodelle aus den Abbildungen 1.1 und 1.2 1.4.2 Agilität und Erweiterbarkeit durch Prozessconstraints Das in Kapitel 1.4.1 erläuterte Konzept aus dem Bereich der deklarativen Programmiersprachen dient nun als Vorbild, um eine deklarative PMS zu entwickeln. Dabei soll die Handhabung dem Prozessmodellierer soweit erleichtert werden, dass er sich in erster Linie nur noch um die Problemstellung kümmern muss, also das WAS, das heißt, er muss nicht mehr die expliziten Lösungswege dafür im Prozessmodell angeben, sondern nur noch die Constraints zu den einzelnen Prozessen. Eine Fokussierung auf den eigentlichen Prozess während der Umsetzung von Unternehmensabläufen steht dabei im Vordergrund. Dies erleichtert die Arbeit des Prozessmodellierers, da die expliziten Lösungen, das heißt, WIE die Prozessregeln umgesetzt werden können, nicht mehr modelliert werden müssen. Durch dieses Modellieren der Prozessconstraints erreicht er einen Konzeptwechsel von „Was nicht explizit erlaubt ist, ist verboten“ zu „Was nicht verboten ist, ist erlaubt“. Die Prozessabläufe sind nur dann noch in ihrer Ausführung eingeschränkt, wenn eine bestimmte Voraussetzung nicht erfüllt ist und ein Constraint diese als Notwendigkeit vorgibt. Wird allerdings kein Constraint eines Prozesses verletzt, so steht dessen Ausführung nichts im Wege. 24 Problemstellung Durch das in Abbildung 1.3 erstmalig neu eingeführte Modellierungssymbol (gestrichelter Pfeil) lässt sich erkennen, wie durch eine Erweiterung der Sprache um neue Modellierungskonstrukte die Prozessmodelle vereinfacht werden können. Die Grundlage für die Definition dieses Modellierungssymbols bilden die Prozessconstraints. Auf Basis dieser Regeln ist es möglich, die Semantik eines neuen Modellierungskonstrukts klar zu definieren. 1.4.3 Navigation bei der Prozessausführung Durch die neu hinzugekommene Agilität der Prozessmodelle kann das Problem entstehen, dass der Prozessausführende durch die vielen Auswahlmöglichkeiten an manchen Stellen überfordert ist. Dies soll durch das Navigationskonzept kompensiert werden, das in der im Rahmen dieser Dissertation entwickelten PMS auch realisiert wurde. Es ist nun möglich, Abläufe beziehungsweise Pfade zu ganz bestimmten Punkten im Prozessmodell oder Unternehmensablauf zu berechnen. Ist der Prozessausführende an einem Punkt mit zu vielen Entscheidungsmöglichkeiten überfordert, so kann er in der Navigationskomponente das Ziel angeben, zu dem er im Prozessmodell navigieren möchte. Als Ergebnis bekommt er einen Arbeitsplan berechnet, den er abarbeiten muss. Somit ist das Problem der zu vielen Entscheidungsmöglichkeiten kompensiert. Kommen nun noch Ausnahmesituationen hinzu, die einen gewünschten Prozessablauf verhindern, so kann dies ebenfalls ein Grund dafür sein, dass der Mitarbeiter bei der Ausführung der Prozesse schnell die Übersicht verliert. Ein ähnliches Problem ist aus dem Straßenverkehr geläufig: In bekannter Umgebung findet man sich gut zurecht, das heißt, man weiß bei auftretenden Problemen (zum Beispiel Straßensperrungen), welchen anderen Weg man nehmen kann, um an das Ziel zu kommen (ohne dass man eine Straßenkarte benötigt). In unbekannter Umgebung ist dies allerdings kaum möglich. Ähnlich verhält es sich bei den Prozessen: Alltägliche Prozessabläufe kennt man im Detail, und bei hier auftretenden Problemen kann man schnell Lösungen finden. Allerdings sieht es bei unbekannten Prozessmodellen anders aus. Ein unerfahrener oder neuer Mitarbeiter kann hier den Überblick bei Ausnahmesituationen verlieren, und es hilft ihm ungemein, ein Navigationssystem zur Hand zu haben. Durch die integrierte Flexibilität der PMS wird der Nutzer bei Ausführung der Prozesse nur noch dann eingeschränkt, wenn ein Constraint die Ausführung eines Prozesses verbietet. Dies stellt sicher, dass sich der Anwender gemäß den Unternehmensrichtlinien verhält und die Validität des gesamten Prozessablaufes im Unternehmen garantiert ist. Weiterhin wird er bei Ausnahmesituationen unterstützt, um schnellstmöglich ein Lösung zu einem Problem finden zu können. Durch eine zusätzliche multimodale Gewichtung der Prozessconstraints während der Modellierung können Empfehlungen durch den Modellierer mit ins Prozessmodell aufgenommen werden. Hierdurch erreicht er eine gewisse Einflussnahme auf die Ausführung, ohne aber den Ausführenden in seinen Entscheidungen einzuschränken. 1.5 Umsetzung Engine for Semantic Process Navigation, kurz ESProNa, ist der Name der deklarativen PMS, die im Rahmen dieser Dissertation entwickelt wurde. Diese constraintbasierte [12] PMS beinhaltet außerdem ein WMS, um eine Ausführung der modellierten 1.6. Aufbau der Dissertation 25 Prozessmodelle zu ermöglichen. ESProNa selbst wurde als Applikation in der logischobjektorientierten Programmiersprache Logtalk [13] verfasst und muss in der Ausführungsumgebung SWI-Prolog [14] geladen werden. Logtalk ist eine Erweiterung der Programmiersprache Prolog [15][16] und fügt dieser objektorientierte Konzepte [17][18] hinzu. Durch die Beschreibungssprache OWL [19] (Kurzform für Web Ontology Language) ist es möglich, Unternehmensstrukturen wie beispielsweise die in Kapitel 1.2.2 genannte Vorgesetztenrelation festzuhalten. Die dabei erstellten Ontologien und deren Strukturen können durch eine Referenzierung im Prozessmodell benutzt werden. Hierdurch erreicht man ein modulares Design, mit dem die Erweiterbarkeit der PMS sichergestellt ist. Zusätzlich zur Sprache OWL wird das Modellierungswerkzeug Protégé [20] eingesetzt, mit dem die Unternehmensstrukturen grafisch modelliert werden können. Aus architekturbezogener Perspektive kann ESProNa als zentrale Bibliothek für Prozessmodellierungsapplikationen und WMS angesehen werden. Das implementierte Prozessnavigationssystem kann nicht nur während der Prozessausführung als Hilfestellung dienen, sondern auch in der Modellierungsphase zur Verifikation der möglichen Prozessabläufe. Der Prozessmodellierer kann somit unerwünschte Nebeneffekte rechtzeitig erkennen und vermeiden. ESProNa ermöglicht zusätzlich eine Unterscheidung zwischen notwendigen und empfohlenen Prozessconstraints. Der Modellierer kann dadurch Empfehlungen in sein Prozessmodell mit aufnehmen. So können die Entscheidungen des Prozessausführenden beeinflusst werden, ohne ihn aber darin zu stark einzugrenzen. 1.6 Aufbau der Dissertation Die Arbeit gliedert sich in insgesamt elf Kapitel. Das vorliegende erste hat sich mit der Problemstellung beschäftigt und die Notwendigkeit der Implementierung neuer PMS und WMS gezeigt. Das zweite Kapitel zeigt die Architektur der am Lehrstuhl entwickelten Applikationen auf und gibt einen Überblick über die Modellierung und Ausführung von Prozessmodellen. Das dritte Kapitel widmet sich der Konzeption von ESProNa und zeigt, wie deklarative Prozesse und Prozessconstraints modelliert werden. Kapitel Vier zeigt anhand eines klinischen Anwendungsfalls, wie die Beschreibung eines Geschäftsprozesses in ein deklaratives und constraintbasiertes Prozessmodell umgesetzt werden kann. Die Validierung von modellierten Prozessen zur Ausführungszeit wird im fünften Kapitel besprochen und gezeigt wie die einzelnen Prozessperspektiven Einfluss auf diese nehmen. Kapitel Sechs zeigt auf, wie die PMS ESProNa erweitert werden kann: Zum einen werden dort neue Modellierungssymbole definiert, um anderen an einem Beispiel eine neue POPM-Perspektive implementiert. Prozessnavigation bildet den Inhalt des siebten Kapitels. Hier werden der Zustand eines Prozessmodells sowie die Zustandsübergangsrelationen im Detail erklärt, die für die Prozessnavigation wichtig sind. In Kapitel Acht wird gezeigt, wie der Prozessmodellierer Empfehlungen in Form von speziellen Prozessconstraints mit ins Prozessmodell aufnehmen kann. Kapitel Neun gibt einen Überblick über die Implementierung von ESProNa und beschreibt die Ordnerstruktur sowie das Zusammenspiel der beteiligten Objekte. Related Work wird im zehnten Kapitel behandelt, das einleitend aufführt, welche Argumente für eine Analyse mit ähnlichen PMS wichtig sind. Es teilt sich anschließend in einen Vergleich zwischen imperativen und deklarativen Modellierungssprachen auf. Kapitel Elf zieht ein Resümee der Ergebnisse dieser Dissertation und zeigt anhand eines Ausblicks, welche nachfolgenden Arbeiten auf diesem Forschungsgebiet noch möglich und notwendig sind. 32 Architektur Kapitel 3 Konzeption Ziel dieses Kapitels ist es, die Konzeption der deklarativen PMS ESProNa genauer zu erläutern. Das Grundkonzept, zum einen native Flexibilität zu gewährleisten und zum anderen eine Trennung zwischen der Problemstellung und der Lösung des Problems zu erreichen, steht dabei an oberster Stelle. Wie bereits in Kapitel 1.4 erwähnt, soll dabei unter anderem ein Konzeptwechsel von „Was nicht explizit erlaubt ist, ist verboten“ zu „Was nicht verboten ist, ist erlaubt“ erreicht werden. Nur falls eine Regel die Ausführung explizit verbietet, wird diese unterbunden. Somit ist sichergestellt, dass sich der Endnutzer an die Regeln des Unternehmens hält und keine davon verletzt, trotzdem in seiner Entscheidungsfreiheit aber nicht eingeschränkt wird. Eine weitere Vorgabe ist, dass strikte Ausführungsreihenfolgen (es gibt an jedem Punkt immer nur genau eine weitere Entscheidungsmöglichkeit für den Endnutzer) genauso modelliert werden können wie auch flexible Ablaufszenarien. Diese Breite ist notwendig, um eine Akzeptanz der Modellierungssprache für verschiedenste Unternehmensgegebenheiten zu erreichen. 3.1 Deklaratives Programmieren Der Einstieg in die Welt der deklarativen Programmierung erfolgt beispielhaft anhand des Logikrätsels Sudoku, das hier als Anwendung in der deklarativen Sprache Prolog verfasst ist. Wichtig dabei ist, dem Leser die strikte Trennung zwischen den Regeln des Spiels und dem Lösen des Problems zu verdeutlichen. Aus diesem Beispiel heraus erfolgt die Konzeption für die Modellierung von deklarativen Geschäftsprozessen. Eine klare Trennung der Prozessperspektiven wird ebenso definiert wie die Trennung von Prozess und Zustand. Des Weiteren werden feingranulare Kategorisierungsmöglichkeiten der Prozessregeln eingeführt. In der Informatik beschreiben Algorithmen allgemein die Lösungen zu ganz bestimmten Problemen. Nach der Definition in [15] ist ein Algorithmus die Kombination aus Logik und Kontrolle (Algorithm = Logic +Control). Oft wird in diesem Kontext die Logik mit der Problemstellung assoziiert, also WAS ist das Problem. Die Kontrolle wird mit der Umsetzung bzw. Lösung des Problems gleichgesetzt, dem WIE. In imperativen Programmiersprachen sind beide Konzepte miteinander vermischt, sodass keine explizite Trennung zwischen dem WAS (Logik) und dem WIE (Kontrolle) zu erkennen ist. Im Kontext von deklarativen Programmiersprachen wird nur das WAS, also die Regeln des Spiels, angegeben. Die Lösung des Problems (das WIE) übernimmt der Interpreter der Programmiersprache. Um die explizite Trennung zwischen der Problemstellung und der 33 34 Konzeption 5 5 5 3 3 6 6 6 6 9 9 9 9 8 8 8 1 1 1 4 4 2 2 6 7 7 3 7 8 8 5 5 5 3 3 3 6 6 6 6 9 9 9 9 8 8 8 8 8 1 1 1 4 4 2 2 6 7 7 7 A3 A4 A6 A7 A8 A9 B7 B8 B9 G4 G5 G6 H1 H2 H3 I1 I2 I3 B2 B3 D2 D3 E2 E3 F2 F3 D7 D8 E7 E8 F7 F8 H7 H8 C4 C5 C6 C1 C7 C9 D4 D6 E5 F4 F6 G1 G3 G9 I4 I6 I7 Abbildung 3.1: Sudoku-Beispiel (links) mit ungebundenen Variablen A bis I (rechts) Lösung an einem konkreten Beispiel aufzuzeigen, wird hierfür – wie oben bereits erwähnt - das Spiel Sudoku herangezogen. Sudoku (im Japanischen bedeutet das in etwa so viel wie „Isolieren Sie die Zahlen“) ist ein Logikrätsel und ähnelt den „Magischen Quadraten“. Ausgangspunkt ist ein Gitter, in dem bereits mehrere Ziffern vorgegeben sind. Das Rätsel wurde von Howard Garns, einem Amerikaner, entwickelt. 1979 unter dem Namen „NumberPlace“ erstmals in einer Rätselzeitschrift veröffentlicht, wurde es ab 1986 zuerst in Japan populär, wo es auch seinen heutigen Namen Sudoku erhielt. Abbildung 3.1 zeigt ein solches Sudoku-Rätsel, das hier im weiteren Verlauf benutzt und gelöst werden soll. Man erkennt in der Abbildung die teilweise gefüllte 9×9-Matrix mit den 3×3-Unterquadraten. Die Regeln sind einfach zu beschreiben: Ziel ist es, das 9×9-Gitter mit den Ziffern 1 bis 9 so zu füllen, dass jede Ziffer in jeder Spalte, in jeder Zeile und in jedem Block (dick umrandete 3×3-Unterquadrate) nur genau einmal vorkommt. 1?- sudoku( 25, 3, A3,A4, 7, A6,A7,A8,A9, 36, B2,B3, 1, 9, 5, B7,B8,B9, 4C1, 9, 8, C4,C5,C6,C7, 6, C9, 58, D2,D3,D4, 6, D6,D7,D8, 3, 64, E2,E3, 8, E5, 3, E7,E8, 1, 77, F2,F3,F4, 2, F6,F7,F8, 6, 8G1, 6, G3,G4,G5,G6, 2, 8, G9, 9H1,H2,H3, 4, 1, 9, H7,H8, 5, 10 I1,I2,I3,I4, 8, I6,I7, 7, 9). 11 12 A3 = 4, A4 = 6, A6 = 8, A7 = 9, A8 = 1, A9 = 2, 13 B2 = 7, B3 = 2, B7 = 3, B8 = 4, B9 = 8, 14 C1 = 1, C4 = 3, C5 = 4, C6 = 2, C7 = 5, C9 = 7, 15 D2 = 5, D3 = 9, D4 = 7, D6 = 1, D7 = 4, D8 = 2, 16 E2 = 2, E3 = 6, E5 = 5, E7 = 7, E8 = 9, 17 F2 = 1, F3 = 3, F4 = 9, F6 = 4, F7 = 8, F8 = 5, 18 G1 = 9, G3 = 1, G4 = 5, G5 = 3, G6 = 7, G9 = 4, 19 H1 = 2, H2 = 8, H3 = 7, H7 = 6, H8 = 3, 20 I1 = 3, I2 = 4, I3 = 5, I4 = 2, I6 = 6, I7 = 1. Listing 3.1: Aufruf und Ergebnis des Algorithmus Im rechten Teil der Abbildung sind an den freien Plätzen der Matrix ungebundene Variablen platziert (grün markiert). Ziel ist es nun, an die jeweiligen Variablen eine 3.1. Deklaratives Programmieren 35 Zahl aus der Zahlenmenge 1..9 so zu binden, dass alle Belegungen zusammengenommen eine Lösung ergeben. Listing 3.1 zeigt, wie man den in Listing 3.2 abgebildeten Programmcode aufrufen kann (Zeilen 1 bis 10). An die Stelle der unbelegten Plätze wandern freie Variablen (A1-A9, B1-..., I1-I9), die im Quellcode fett markiert sind. An diese werden dann die Lösungen gebunden. Alles, was der Programmierer zu tun hat, ist die Regeln des Spiels zu modellieren. In Listing 3.2 ist der Prolog-Quellcode abgebildet, der den Logikteil (das WAS) der Problemstellung darstellt. Es sind sehr viele Regeln enthalten (jede Spalte, jede Zeile und jeder Block wird durch eine Regel modelliert); der Code könnte wesentlich effizienter dargestellt werden, jedoch ist er auf diese Weise gerade für Neulinge im Bereich der deklarativen bzw. logischen Sprachen einfacher zu verstehen. Die Zeilen 1 bis 10 geben den sogenannten Kopf des Prädikates an. Durch diese Signatur wird festgelegt, wie man dieses Prädikat aufrufen kann. Die Variablen werden teilweise vorbelegt, nämlich mit den Werten des vorgegebenen Rätsels (siehe Listing 3.1). So wird beispielsweise an die Variable A1 der Wert 5 gebunden, an die Variable A2 der Wert 3, an die Variable A5 der Wert 7 etc. Die ungebundenen Variablen (A3, A4, A6, ...) werden seitens des Prolog-Interpreters automatisch so durchprobiert, dass sie eine Lösung gemäß den angegebenen Regeln ergeben. Die Zeilen 12 bis 20 des Listings 3.1 spiegeln das Ergebnis wider, das der Prolog-Interpreter ausgibt. 1sudoku( A1,A2,A3,A4,A5,A6,A7,A8,A9, 2B1,B2,B3,B4,B5,B6,B7,B8,B9, 3C1,C2,C3,C4,C5,C6,C7,C8,C9, 4 5D1,D2,D3,D4,D5,D6,D7,D8,D9, 6E1,E2,E3,E4,E5,E6,E7,E8,E9, 7F1,F2,F3,F4,F5,F6,F7,F8,F9, 8 9G1,G2,G3,G4,G5,G6,G7,G8,G9, 10 H1,H2,H3,H4,H5,H6,H7,H8,H9, 11 I1,I2,I3,I4,I5,I6,I7,I8,I9) :- 12 13 /*Alle Zahlen pro Zeile sind verschieden */ 14 all_vars_different([A1,A2,A3,A4,A5,A6,A7,A8,A9]), 15 all_vars_different([B1,B2,B3,B4,B5,B6,B7,B8,B9]), 16 ... 17 all_vars_different([I1,I2,I3,I4,I5,I6,I7,I8,I9]), 18 19 /*Alle Zahlen pro Spalte sind verschieden */ 20 all_vars_different([A1,B1,C1,D1,E1,F1,G1,H1,I1]), 21 all_vars_different([A2,B2,C2,D2,E2,F2,G2,H2,I2]), 22 ... 23 all_vars_different([A9,B9,C9,D9,E9,F9,G9,H9,I9]), 24 25 /*Alle Zahlen pro 3x3-Block sind verschieden */ 26 all_vars_different([A1,A2,A3,B1,B2,B3,C1,C2,C3]), 27 all_vars_different([A4,A5,A6,B4,B5,B6,C4,C5,C6]), 28 ... 29 all_vars_different([G7,G8,G9,H7,H8,H9,I7,I8,I9]). 30 31 32 all_vars_different(L) :- 33 length(L,9), 34 Lins 1..9, 35 all_different(L). Listing 3.2: Modellierte Regeln des Sudoku-Rätsels in der Sprache Prolog 36 Konzeption 5 5 5 3 3 3 6 6 6 6 9 9 9 9 8 8 8 8 8 1 1 1 4 4 2 2 6 7 7 7 1 7 2 4 1 1 1 1 1 2 2 2 2 2 2 4 4 4 4 4 4 7 7 7 7 7 3 3 3 3 3 3 5 5 5 5 5 5 6 6 6 6 9 9 9 9 8 8 9 8 8 Abbildung 3.2: Lösung des Sudoku-Beispiels In den Zeilen 14 bis 17 des Listings 3.2 werden die Regeln für jede Zeile des Spiels einzeln modelliert. Die Zeilen 20 bis 23 geben die Regeln für die Spalten an und die Zeilen 26 bis 29 die Regeln für die 3×3-Blöcke. Das Prädikat all_vars_different wird von allen Regeln aufgerufen. Es überprüft, ob die übergebene Liste an Variablen (gebundene und ungebundene zusammen) die Länge neun hat und sichert in Zeile 34 zu, dass alle Werte, die bereits gebunden sind oder noch gebunden werden, im Wertebereich von 1 bis 9 liegen. Das Prädikat all_different ist eine systeminternes Prädikat der clpfdBibliothek, das nun die ganze Arbeit erledigt, das heißt, alle Variablen so durchprobiert, dass sie zusammengenommen alle verschieden sind und eine Lösung ergeben. Wie der Algorithmus des Prolog-Interpreters genau funktioniert, soll hier jedoch nicht näher erläutert werden. Dem interessierten Leser sei [15] empfohlen, wo sich ein sehr guter, mit vielen Beispielen untermauerter Einstieg in die Sprache Prolog findet. 3.2 Deklarative Prozesse Wie in Kapitel 1 bereits erwähnt, steht das Beschreiben der Problemstellung im Vordergrund. Zu diesem Zweck wählt man einen deklarativen Ansatz zur Darstellung der Unternehmensabläufe. Die Grundidee hierbei ist, die Problemstellung von der Lösung zu separieren. Bezogen auf die Unternehmensprozesse bedeutet dies, dass man in erster Linie die Prozesse und deren Zusammenhänge untereinander beschreibt. Genau wie bei dem angeführten Sudoku-Beispiel soll man sich bei der Prozessmodellierung nur auf die Regeln konzentrieren und sich nicht mehr um eine explizite Lösung dafür bemühen müssen. 3.2.1 Prozess und Perspektiven Bei der Modellierung von Geschäftsprozessen wird in ESProNa ein klarer Fokus auf den Prozess, der in Form eines abgerundeten Rechtecks dargestellt wird, gelegt (vgl. Abbildung 3.3). Dies geschieht durch die regelbasierte Modellierung von Unternehmensabläufen. Die erstellten Regeln werden direkt in den Prozess selbst geschrieben. In Abbildung 3.3 ist der schematische Aufbau eines solchen Prozesses grafisch verdeutlicht: Er gliedert sich in einen Kopfteil, der die Bezeichnung (Prozessname) enthält, und die einzel- 3.2. Deklarative Prozesse 37 nen Perspektiven. Jeder Prozessschritt hat zusätzlich zur sprachlichen Kurzbeschreibung einen Prozessidentifikator PID, der zum einen sicherstellt, dass jeder Prozess eindeutig identifiziert werden kann, und zum anderen als Kurzreferenz in den Regeln dient. Im unteren Teil sind die einzelnen Perspektiven [24] eines Prozesses aufgelistet. Pro Prozess können mehrere Perspektiven (gekennzeichnet durch verschiedene Symbole in den gestrichelten Unterteilungen) modelliert werden. Alle Perspektiven zusammengenommen repräsentieren den Prozess in seiner Gesamtheit. Mit Hilfe dieses Konzeptes werden die Prozessregeln kategorisiert, und es wird eine klare Strukturierung erzielt. Durch das erweiterbare und modulare Konzept können neue Perspektiven einfach und schnell hinzugefügt werden. Prozessname PID: Prozess-ID Funktionale Perspektive Verhaltensbezogene Perspektive Organisatorische Perspektive Datenbezogene Perspektive Operationale Perspektive Abbildung 3.3: Schematischer Aufbau eines Prozesses Insgesamt können aktuell in ESProNa pro Prozess fünf Perspektiven modelliert werden. Im Einzelnen sind dies: •Funktionale Perspektive (Klemmbrettsymbol): beschreibt die individuelle Sicht auf den Prozess selbst. Hier werden Aussagen getroffen, die nur den Prozess selbst betreffen. •Verhaltensbezogene Perspektive (quer liegendes USB-Symbol): beschreibt den speziellen Zustand anderer Prozesse, die für die Ausführung des aktuellen Prozesses wichtig sind. Durch die Auswertung der verhaltensbezogenen Perspektive aller Prozesse ergeben sich der Kontrollfluss bzw. die möglichen Ablaufszenarien eines Prozessmodells. •Organisatorische Perspektive (Personensymbol): beschreibt Personen bzw. allgemein Agenten, die den Prozess ausführen können. Man spricht von Agenten, da auch eine Softwareapplikation einen Prozess ausführen kann. •Datenbezogene Perspektive (Registratursymbol): beschreibt, welche Daten für den Prozess zur Ausführung benötigt werden bzw. welche Daten der Prozess während der Ausführung produziert. •Operationale Perspektive (Werkzeugschlüsselsymbol): beschreibt, welche Programme, Maschinen, etc. im Prozess benötigt werden. 38 Konzeption Bei der Validierung bezüglich der Ausführbarkeit eines Prozesses erfolgt eine logische UND-Verknüpfung aller Perspektiven. Abbildung 3.4 zeigt dies schematisch. Dabei werden, wie in der Abbildung unten rechts zu sehen ist, verschiedene Ergebnisse berechnet. Das Ergebnis der funktionale Perspektive sagt aus, ob eine weitere Instanz des Prozesses ausgeführt werden kann, und wird in Abbildung 3.4 durch das Klemmbrettsymbol symbolisiert. Das zweite Symbol von links symbolisiert das Ergebnis der verhaltensbezogenen Perspektive. Auch hier wird durch Auswertung von speziellen Prozessregeln überprüft, ob aus Sicht dieser Perspektive der Prozess ausgeführt werden kann. Das Personensymbol beschreibt das Ergebnis aus der Validierung der organisatorischen Perspektive. Hier wird der Agent ermittelt, der für die Ausführung des Prozesses zuständig ist. Mit dem Registratursymbol wird die datenbezogene Perspektive assoziiert. Es beschreibt die für den Prozess benötigten Daten. Das Symbol des Werkzeugschlüssels definiert allgemein die Applikation, mit der ein Prozess auszuführen ist. Funktionale Perspektive Verhaltensbezogene Perspektive Organisatorische Perspektive Datenbezogene Perspektive Operationale Perspektive + Abbildung 3.4: Auswertung aller Perspektiven Eine Erweiterung der PMS mit neuen Perspektiven ist ohne größeren Aufwand möglich. Abbildung 3.5 zeigt schematisch, wie eine neue Perspektive zur Validierung mit eingebunden wird. In Kapitel 6.2 wird dies auf technischer Ebenen genauer erläutert. Es sei vorweggenommen, dass die neu hinzugekommene Perspektive lediglich implementiert und in die Prozessbeschreibung importiert werden muss. Das dadurch neu hinzugekommene Konzept (symbolisiert durch den Stern) wird bei bei der Validierung, wie in Abbildung 3.5 dargestellt, mitberechnet. 3.2.2 Detaillierter Aufbau eines Prozesses In Abbildung 3.6 ist der detaillierte Aufbau eines Prozesses dargestellt. Innerhalb der Perspektiven sind nun im Gegensatz zu Abbildung 3.3 zusätzliche Constraints schematisch abgebildet. Ein Constraint kann zum einen ein Tatsache repräsentieren, also zum Beispiel angeben, wie oft ein Prozess ausgeführt werden kann oder welche Person einen Prozess ausführen muss. Es kann sich aber auch auf andere Prozesse beziehen, das heißt, es modelliert beispielsweise, dass der Agent des Prozesses der Vorgesetzte des Agenten eines anderen Prozesses sein muss. Zum anderen kann es auch eine Regel repräsentieren, 3.2. Deklarative Prozesse 39 Funktionale Perspektive Verhaltensbezogene Perspektive Organisatorische Perspektive Datenbezogene Perspektive Operationale Perspektive Neue Perspektive + Abbildung 3.5: Hinzufügen einer neuen Perspektive mit Auswertung des neuen Konzepts also eine Wenn-Dann-Beziehung darstellen. In diesem Fall bezieht man sich auf einen bestimmte Situation (Wenn), und abhängig von dieser Situation müssen bestimmte Dinge eintreten (Dann). Eine Regel könnte etwa lauten: Wenn der Prozess mehr als dreimal abgebrochen wurde, so kann er nur noch vom Vorgesetzten der Abteilung wieder ausgeführt werden. Die genaue Syntax der Constraints der entsprechenden Perspektiven ist in Anhang C spezifiziert. Auf der rechten Seite der Grafik in Abbildung 3.6 erkennt man, welche Perspektive Einfluss auf welche Konzepte des Prozesses nimmt. Die Ausführung eines Prozesses wird immer als Prozessinstanz bezeichnet. Wie viele Instanzen es geben kann, wird in der funktionalen Perspektive spezifiziert. Durch die Auswertung der Constraints in dieser Sektion werden die genauen Instanzen eines Prozesses ermittelt, die ausgeführt werden können. Die verhaltensbezogene Perspektive beeinflusst den Kontrollfluss der Ausführung eines Prozessmodells. Durch Auswertung der organisatorischen Perspektive werden der Agent beziehungsweise die Agenten ermittelt, die den Prozess ausführen können. In der datenbezogenen Perspektive werden die Daten zusammengefasst, die zum einen zur Ausführung benötigt werden, zum anderen durch Abarbeitung des Prozesses erzeugt werden. Das Werkzeug hierzu wird durch die operationale Perspektive beschrieben. 3.2.3 Trennung von Prozess und Zustand Um die eingangs erwähnte strikte Trennung zwischen Logik (WAS) und Kontrolle (WIE) zu erreichen, ist es wichtig, den Zustand eines Prozesses explizit auszuweisen, also vom Prozess zu entkoppeln. Dies hat den Vorteil, dass hierdurch die in Kapitel 7 angesprochene Prozessnavigation sehr einfach umzusetzen ist. Ein weiterer Vorteil betrifft die Kommunikation mit dem ProcessNavigator. Durch den ausgelagerten Zustand eines Prozesses ist jede Anfrage vom ProcessNavigator an ESProNa in sich geschlossen, das heißt, sie beinhaltet alle Informationen über den Anwendungszustand. Hierdurch werden Client/Server-Anfragen zwischen den Systemen effizienter, da etwa zusätzliche Transportschichten wie SOAP [25] oder Sitzungsverwaltungen über HTTP-Cookies [26] nicht nötig sind. 40 Konzeption Prozessname PID: Prozess-ID Agent Werkzeug Funktionales Constraint 1 Funktionales Constraint 2 ... Funktionale Perspektive Verhaltensbezogenes Constraint 1 Verhaltensbezogenes Constraint 2 ... Verhaltensbezogene Perspektive Organistaorisches Constraint 1 Organistaorisches Constraint 2 ... Organisatorische Perspektive Datenbezogenes Constraint 1 Datenbezogenes Constraint 2 ... Datenbezogene Perspektive Operationales Constraint 1 Operationales Constraint 2 ... Operationale Perspektive Daten Kontrollfluss Prozessinstanz Abbildung 3.6: Deklarativer Prozess im Detail In den einzelnen Zuständen der im Modell enthaltenen Prozesse werden Informationen über deren Historie gespeichert. Diese beinhaltet Informationen darüber, welche detaillierten Aktionen auf einen Prozess ausgeführt worden sind. Die Struktur dieser Informationen gliedert sich wieder nach den POPM-Perspektiven; Instanz, Agent, Daten und verwendete Werkzeuge spiegeln sich also darin wider. Durch diese detaillierte Speicherung können Prozessconstraints modelliert werden wie etwa „Jede zweite Ausführung eines Prozesse muss vom Vorgesetzten erledigt werden“. Um den Vorgesetzten zu ermitteln, ist es wichtig zu wissen, welche Instanz gerade ausgeführt wird und wer die vorangegangene ausgeführt hat. All diese Informationen sind in der Historie abgespeichert. 3.3 Kategorisierung von Prozessconstraints Pro Perspektive können beliebig viele Constraints eingetragen werden. Um eine möglichst detaillierte Abbildung der Unternehmensabläufe zu bekommen, hat sich eine Kategorisierung der Prozessregeln nach POPM-Perspektiven [24], Prozesshandlungen und Prozesszuständen als essentielles Konzept erwiesen. Das wird in den nachfolgenden Abschnitten näher erklärt. 3.3.1 POPM-Perspektiven Die verschiedenen Prozessregeln, die zusammengenommen die Definition eines Prozesses ausmachen, werden primär nach den einzelnen POPM-Perspektiven kategorisiert. In der organisatorischen Perspektive beispielsweise werden nur Regeln abgebildet, die den Agenten betreffen, der den Prozess ausführen kann. In der operationalen Perspektive ist es sinnvoll, Regeln anzugeben, die das Werkzeug spezifizieren, mit dem man den Prozess ausführen möchte. Dieses Konzept der perspektivenorientierten Kategorisierung hat 3.3. Kategorisierung von Prozessconstraints 41 zum einen Vorteile bei der Lesbarkeit der Prozessmodelle, zum anderen können aber auch ganze Perspektiven ausgeblendet werden. Dies kann nötig sein, wenn beispielsweise in einem Unternehmen gewünscht wird, keine operationale Perspektive zu modellieren. In diesem Fall würde man sie einfach dadurch weglassen, dass keine Regeln in dieser Perspektive modelliert werden. Es kommt manchmal vor, dass der Modellierer Regeln angeben möchte, die zwei oder mehrerer Perspektiven betreffen. Eine davon könnte - in sprachlicher Form ausgedrückt - etwa lauten: „Der Chefarzt der chirurgischen Abteilung wird die Erstellung des Operationsplans selbst durchführen, wenn die Daten des Patienten zeigen, dass dieser privat versichert ist“. Diese Regel betrifft übergreifend zwei verschiedene Perspektiven. In diesem Fall hat der Modellierer die Möglichkeit, die Regel entweder der organisatorischen oder der datenbezogenen Perspektive zuzuordnen. 3.3.2 Prozesshandlungen Prozesshandlungen wurden bisher immer unter dem Begriff „Aktion“ geführt und ein Prozess immer „ausgeführt“. Eine genauere Differenzierung ist dabei bisher aber vermieden worden. Ab jetzt können ganz individuell verschiedene Aktionen auf einen Prozess definiert werden. Das „Ausführen“ wird in verschiedene Aktionen aufgeteilt. Grundlegende Handlungen, etwa das Starten, Abschließen oder auch das Abbrechen eines Prozesses, werden in der funktionalen Perspektive des Prozesses als Constraint modelliert. Abbildung 3.7 zeigt dies grafisch. Prozessname PID: Prozess-ID Funktionale Perspektive Verhaltensbezogene Perspektive Organisatorische Perspektive ... ... start, finish, suspend, abort Constraint 1(start) Constraint 2(abort) ... Constraint 1(start) Constraint 2 (finish) ... Abbildung 3.7: Definition der möglichen Handlungen eines deklarativen Prozesses Die Liste der Handlungen kann von Unternehmen zu Unternehmen verschieden sein, sodass es ein grundlegendes Ziel bei der Entwicklung von ESProNa war, sie dynamisch zu gestalten. Dabei ging man sogar noch einen Schritt weiter: Die Menge an möglichen Handlungen pro Prozess kann individuell eingeschränkt werden. Ein Grund für diese Konzeption war, dass es zum Beispiel bei einem Prozess Sinn machen kann, ihn zu suspendieren, sozusagen „schlafenzulegen“, bei einem anderen Prozess aber nicht. Als Konsequenz aus dieser Tatsache erlaubt ESProNa, pro Prozess eine Liste von Handlungen anzugeben, die auf den Prozess ausgeführt werden können. In Abbildung 3.7 sind vier 48 Modellierung kann, ein Assistenzarzt sein muss: Agent org:plays clinic:Assistenzarzt. Subjekt ist in diesem Falle der Agent, Prädikat ist ein “Spielen der Rolle” (org:plays), und das Objekt bildet die Assistenzarztrolle (clinic:Assistenzarzt). Mit dieser Regel, die gleichzeitig auch als Suche in der klinischen Organisationsstruktur genutzt wird, kann man den Agenten in diesem Fall auf diejenigen Personen einschränken, die Assistenzärzte sind. Das Subjekt Agent stellt in diesem Kontext eine Variable dar (siehe Sudoku-Beispiel in Kapitel 3.1), und es werden alle Personen daran gebunden, die die Rolle des Assistenzarztes ausüben. Bei der Auswertung einer Regel der organisatorischen Perspektive wird immer wenigstens ein Agent ermittelt. Es können aber auch mehrere Agenten sein, die als Kandidaten für die Ausführung des Prozesses in Frage kommen. Es sind diejenigen Personen, die sich später einmal am ProcessNavigator mit ihren Zugangsdaten anmelden, um den entsprechenden Prozessschritt auszuführen. In Prozessschritt P1 (Operationsplan vorbereiten) findet man die gleichen Regeln wie im Prozess P0, man sucht also für die Ausführung zum einen nach Assistenzärzten, schränkt dies mit der zweiten Regel jedoch weiter ein: Die gefundenen Assistenzärzte müssen noch zusätzlich in der Abteilung Chirurgie arbeiten. Beide Regeln werden zusammen als logische UND-Verknüpfung gesehen, es wird also die Schnittmenge aus der durch die erste Regel ermittelten Agentenmenge mit der aus der zweiten Regel gebildet. Neben der UND-Verknüpfung von Regeln (die standardmäßig eingestellt ist und nicht explizit angegeben werde muss) sind auch andere logische Verknüpfungen möglich, die jedoch explizit modelliert werden müssen. In Prozessschritt P2 ist vorgegeben, dass der Prozess vom Supervisor, also dem Vorgesetzten derjenigen Person ausgeführt werden muss, die den Prozessschritt P1 (Operationsplan vorbereiten) ausgeführt hat. In einem klinischen Umfeld sind dies für die Assistenzärzte in der Regel die Oberoder Chefärzte einer Abteilung. In dem angegebenen Constraint sollen allerdings nicht die spezifischen Personen ermittelt werden, sondern diese sollen ungebunden bleiben. Mit anderen Worten, es ist nur wichtig, dass hier ein Vorgesetzter den Operationsplan überprüft, nicht jedoch, ob dieser nun ein Oberoder Chefarzt ist. Konsequenterweise gibt es bei mehreren Vorgesetzten auch mehrere Möglichkeiten, welche Person den Schritt ausführen kann. Dies ist ein Beispiel für die integrierte Flexibilität in ESProNa, ohne dass diese durch mehrere explizite Prozessschritte implementiert werden muss. Durch das in Klammern vor das nachfolgende Constraint gestellte Prefix (abort) wird sichergestellt, dass, falls der Prozessschritt Operationsplan genehmigen abgebrochen werden muss, dies von einem Chefarzt ausgeführt wird. 4.2.4 Datenbezogene Perspektive Die datenbezogene Perspektive, symbolisiert durch das Registratursymbol, beschreibt zum einen, welche Daten ein Prozess zur Ausführung benötigt, zum anderen aber auch, welche Daten durch die Ausführung produziert werden. Ähnlich der organisatorischen Perspektive basiert auch diese auf einer Ontologie und beschreibt Daten anhand des bereits erwähnten SPO-Konstrukts. Die praktische Umsetzung der datenbezogenen Perspektive ist allerdings noch in einem sehr frühen Stadium. Hier muss noch sehr viel an Forschungsarbeit geleistet werden: Die Betriebssysteme und deren Applikationen müssen auf die Nutzung einer datenbezogenen Ontologie vorbereitet werden. Nur so kann sichergestellt werden, dass die erzeugten Daten auch interpretiert und vom ProcessNavigator weiterverarbeitet werden können. 4.3. Constraintbasierte Umsetzung 49 4.2.5 Operationale Perspektive Das Werkzeugschlüsselsymbol stellt die operationale Perspektive dar und beschreibt, welche Werkzeuge, also Programme, Maschinen etc., für die Ausführung des Prozessschrittes benötigt werden. Genau wie die organisatorische und die datenbezogene Perspektive wird zur Beschreibung der verschiedenen genannten Entitäten und deren Relationen untereinander eine Ontologie verwendet. Es sei hier noch angemerkt, dass sich die verschiedenen Ontologien auch gegenseitig referenzieren können. Dies ist zum Beispiel der Fall, wenn man beschreibt, welches Programm welche Dateien öffnen kann. Hier nutzt man bei der Beschreibung des Programmes den sogenannten Datentyp (zum Beispiel einfache .txtDatei, ein Microsoft Word-.docx-Dokument etc.). Die Beschreibung des Typs obliegt allerdings der datenbezogenen Ontologie und wird auch dort gespeichert. 4.3 Constraintbasierte Umsetzung Das nachfolgende Unterkapitel widmet sich speziell dem Thema, wie das Prozessmodell aus Abbildung 4.1 übersetzt werden kann, das heißt, wie die modellierten Prozesse und deren Constraints in ESProNa abgebildet werden können. Das daraus resultierende Prozessmodell besteht nur aus Prozessobjekten und darin enthaltenen Prozessconstraints. Alle anderen grafischen Notationen aus iPM2sind bei der Übersetzung durch die semantische Modelltransformation in Constraints umgewandelt worden. Anhand des Quellcodes in Listing 4.1 wird das Ergebnis aus dieser Transformation für den Prozess Anamnese durchführen aufgezeigt. Die Zeilen 1 bis 2 und die Zeile 59 markieren dabei Beginn und Ende des Prozesses. In dieser Objektdefinition wird als Argument eine Komposition aus der ID des Prozessmodells und dem Prozessidentifikator abgespeichert, um den Prozess Anamnese durchführen eindeutig identifizieren zu können (set_up_surgery_plan#pid_0). Zeile 4 definiert den Prozess als dynamisch, um das Entladen des Prozesses zu ermöglichen. Dies ist notwendig, damit ein geladenes Prozessmodell zur Laufzeit durch ein anderes Modell ersetzt werden kann. Hierzu müssen alle Prozessobjekte löschbar sein, was durch das Attribut dynamic ausgedrückt wird. Die Zeilen 6 und 8 speichern Titel und Beschreibung des Prozesses in Textform. Diese Information wird in der Ausführungsumgebung benötigt, um den Prozess grafisch für den Endnutzer zu kennzeichnen. Zeile 10 zeigt die Zugehörigkeit zum entsprechenden Modell, in dem der Prozess modelliert wurde. 4.3.1 Funktionale Constraints Ab Zeile 12 beginnt der Block, in dem die Constraints der funktionalen Perspektive abgespeichert werden. Die Handlungen, die auf den Prozess Anamnese durchführen ausgeführt werden können, sind in Zeile 16 als Liste codiert: start,finish und abort. In den Zeilen 20 und 21 wird der Wertebereich angegeben, in dem sich der Zähler für erfolgreiche Prozessausführungen befinden darf. Im Prozessmodell aus Abbildung 4.1 wurde für den Prozessschritt Anamnese durchführen angegeben, dass dieser genau einmal ausgeführt werden darf. Dies muss nun in eine syntaktische Form übersetzt werden, die von ESProNa verstanden werden kann; sie wird als clpfd-Domänenbereich codiert. clpfd [27] [28] ist eine Bibliothek für SWI Prolog [14], mit der es möglich ist, Einschränkungen auf ganzzahlige Wertebereiche logisch zu beschreiben und auszuwerten. Für das Prozessmodell aus Abbildung 4.1 werden die Constraints #= 1,1..*und #= P1 an clpfd übergeben. 50 Modellierung 1:- object(’set_up_surgery_plan#pid_0’(_), 2extends(process)). 3 4:- dynamic. 5 6process_title(’Anamnese durchführen’). 7 8process_description(’Der Prozess Anamnese umfasst die ...’). 9 10 contained_in_process_model(set_up_surgery_plan). 11 12 /*--------------------------------------------------------------- 13 SECTION FUNCTIONAL PERSPECTIVE CONSTRAINTS 14 ---------------------------------------------------------------*/ 15 /*Deklaration der möglichen Prozesshandlungen */ 16 process_actions([start, finish, abort]). 17 18 /*Deklaration des Wertebereichs für die Anzahl der 19 möglichen Prozessausführungen*/ 20 process_domain([], (PID_0 #= 1)) :- 21 parameter(1, PID_0). 22 23 /*Prozesshandlung kann nur ausgeführt werden, wenn 24 keine der handlungsspezifischen Regeln verletzt wird. */ 25 functional_constraint([Action], State,Instance, 26 ( 27 pid_0(_)::actions_applicable(State,Action,Instance) 28 )). 29 30 /*--------------------------------------------------------------- 31 SECTION ORGANIZATIONAL PERSPECTIVE CONSTRAINTS 32 ---------------------------------------------------------------*/ 33 /*Der Prozess muss von einem Arzt ausgeführt werden. */ 34 organizational_constraint([start, finish, abort], _, _, [Agent], 35 ( 36 instantiates_class(Agent, ’org#Person’), 37 Agent::’org#plays’(’clinic#Arzt’) 38 )). 39 40 /*--------------------------------------------------------------- 41 SECTION DATA PERSPECTIVE CONSTRAINTS 42 ---------------------------------------------------------------*/ 43 /*Prozess produziert die Patientenakte */ 44 data_production([start], _, _, [Data], 45 ( 46 instantiates_class(Data, ’clinic:Patientenakte’) 47 )). 48 49 /*--------------------------------------------------------------- 50 SECTION OPERATIONAL PERSPECTIVE CONSTRAINTS 51 ---------------------------------------------------------------*/ 52 /*Prozess wird mit Hilfe des HIS-Systems ausgeführt */ 53 operational_constraint([start, finish, abort], _, _, [Tool], 54 ( 55 instantiates_class(Tool, ’op:Software’), 56 Tool::’op:labeled’(software:HIS’) 57 )). 58 59 :- end_object. Listing 4.1: Prozess P0, modelliert in ESProNa 4.3. Constraintbasierte Umsetzung 51 1?- PID_0 #= 1, PID_1 #>= 1, PID_2 #= PID_1. 2PID_0 = 1, 3PID_1 =PID_2, 4PID_2 in 1..sup. Listing 4.2: Wertebereiche mit Ergebnis, formuliert in clpfd-Syntax Listing 4.2 zeigt in einer Prolog-Session, wie diese Wertebereiche berechnet werden, die für die angegebenen Prozesse gültig sind. In Zeile 1 ist die Anfrage mit den codierten Wertebereichen der Prozesse abgebildet. Da der Prozess Operationsplan vorbereiten beliebig oft ausgeführt werden kann (1..*), gibt es unendlich viele Kombinationsmöglichkeiten zwischen den Prozessen. Dies erkennt man nochmals an der Ausgabe (Listing 4.2) in Zeile 4. sup wird hier als die Abkürzung von Supremum benutzt und bezeichnet plus unendlich (+∞). Die Ergebnisse aus dieser Berechnung werden durch ESProNa im Hintergrund abgespeichert, da sie für die Auswertung der weiteren funktionalen Constraints sehr wichtig sind. Die nachfolgend besprochenen Constraints ab Zeile 25 in Listing 4.1 weisen alle die gleiche Struktur auf. Diese Konzeption hat sich als vorteilhaft erwiesen, da bei einer Erweiterung der Sprache die Änderungen am Code minimal bleiben und Übersetzungspattern bei der Modelltransformation wiederverwendet werden können. Der erste Parameter eines Constraints schränkt dessen Wirkungsbereich auf ganz bestimmte Handlungen ein, die in Form einer Liste übergeben werden. Nur bei der Validierung der Handlungen, die in der Liste vorkommen, wird das Constraint ausgewertet. Der zweite Parameter ist immer die gebundene Variablen State, die den aktuellen Zustand des Prozessmodells speichert (vgl. Kapitel 7.1.1, wo der genaue Aufbau der Zustandsvariablen erläutert wird). Durch Angabe dieses State ist es möglich, wie in Kapitel 3.2.3 besprochen, den Wirkungskreis der Regel auf einen ganz bestimmten Zustand einzuschränken. Der dritte Parameter ist die sogenannte Prozessinstanz (Instance). Sie kann sowohl gebunden als auch ungebunden verwendet werden. Durch die erstere Form, in diesem Fall wird eine konkrete Instanz spezifiziert und an die Variable gebunden, schränkt man den Wirkungsgrad des Constraints genau auf diese Instanz ein. In der ungebunden Variante (es wird keine spezielle Instanz angegeben) wirkt das Constraint für alle Instanzen des Prozesses. In den Zeilen 25 bis 28 von Listing 4.1 wird ein funktionales Constraint spezifiziert, das speziell die Handlungen des Prozesses einschränkt. Die Semantik des Constraints besagt, dass die Handlung, die ausgeführt werden soll, auch grundsätzlich ausführbar sein muss. Zwei Regeln schränken diese Ausführbarkeit ein. Die erste Regel betrifft das Starten des Prozesses. Sie besagt, dass es nur möglich ist, einen Prozess zu starten, wenn eine neue Instanz erzeugt werden kann. Die zweite Regel betrifft die restlichen Handlungen, also im obigen Fall finish und abort. Ein Prozess kann nur dann beendet oder abgebrochen werden, wenn es eine gestartete Instanz gibt. Die Überprüfung der Regeln bei entsprechender Handlung übernimmt das Prädikat actions_applicable/3 in Zeile 27. Die Spezifikation /3, die an den Namen des Prädikats angehängt wird, sagt aus, wie viele Parameter bei Aufruf übergeben werden. ESProNa erhält seitens der Ausführungsumgebung unter anderem den aktuellen Zustand (State). Basierend darauf erfolgt die Auswertung der Constraints; sie wird in Zeile 27 an das Prädikat applicable/3 weitergegeben. Eine Auswertung des Prädikates actions_applicable/3 (Listing 4.3) bei geladenem Prozessmodell sieht wie folgt aus: In Zeile 1 wird der initiale Zustand (Variable State) durch das Prädikat initial_state/1 im Objekt process_planning erzeugt 52 Modellierung (auf dieses Prädikat wird in Kapitel 7.1.1 noch genauer im Zusammenhang mit der Planung bzw. Navigation von Prozessen eingegangen). Im erzeugten Zustand ist noch kein Prozess ausgeführt worden, das Modell befindet sich im Prozess Start (Abbildung 4.1). Dieser Zustand wird dann an das Prädikat actions_applicable/3 in Zeile 27 in Listing 4.1 weitergegeben. Bei der Auswertung des Prädikats wird versucht, an die ungebundenen Variablen Action und Instance valide Werte zu binden. Für den obigen initialen Zustand, bei dem noch keine Prozessinstanz gestartet wurde, sind dies die Werte start für Action und 1für Instance. Jede Instanz wird fortlaufend durchnummeriert, ähnlich einem atomaren Primärschlüssel in der Datenbanktechnologie. Wird eine neue Instanz gestartet, so inkrementiert der alte Zähler um eins. Dies passiert aber nur, wenn der Wertebereich des Prozesses dies zulässt. Bei Anamnese durchführen wurde modelliert, dass der Prozess genau einmal ausgeführt werden kann. Somit gibt es nur eine Instanz, die gestartet werden kann. Bei Prozess Operationsplan vorbereiten ist dies anders: Hier kann es unendlich viele Prozessinstanzen geben (Wertebereich 1..*). Das Prädikat actions_applicable/3 prüft nun automatisch, ob eine neue Instanz des Prozesses gestartet werden kann. Im initialen Zustand (es wurde bisher noch keine Instanz gestartet) validiert dieses Prädikat erfolgreich. An die Variable Action kann im Initialzustand keine der Handlungen finish oder abort gebunden werden, da die zweite Handlungsregel verletzt wurde: Eine Instanz kann nur beendet oder abgebrochen werden, wenn es bereits eine gestartete gibt. Dies ist im übermittelten Zustand nicht der Fall, und somit validiert die entsprechende Regel auch nicht. 1?- process_planning::initial_state(set_up_surgery_plan, State), 2pid_0(_)::actions_applicable(State,Action,Instance). 3 4State = [ (pid_0, [], 0), (pid_1, [], 0), (pid_2, [], 0)], 5Action = start, 6Instance = 1. Listing 4.3: Aufruf des Prädikats actions_applicable/3 4.3.2 Verhaltensbezogene Constraints Ein verhaltensbezogenes Constraint ist im Prozess Anamnese nicht vorhanden. Deshalb soll an dieser Stelle das verhaltensbezogene Constraint aus dem Prozess P1 herangezogen werden: Es spezifiziert, dass für das Starten der Prozess Anamnese durchführen bereits gestartet sein muss. Das in der ESProNa-Sprache codierte Constraint ist in Listing 4.4 abgebildet. 1behavioral_constraint([start], State, _, 2( 3pid_0(_)::exists_instance(State, start, _) 4)). Listing 4.4: Verhaltensbezogenes Constraint im Prozess P1 4.3. Constraintbasierte Umsetzung 53 Im ersten Parameter der Prozessregel ist zu erkennen, dass das Constraint nur bei der Evaluierung der Handlung start ausgewertet wird. Im zweiten Parameter ist der aktuelle Zustand der laufenden Prozessausführung an die Variable State gebunden. Eine spezielle Instanz ist für dieses Constraint nicht von Bedeutung, somit wird an die Stelle der Instanzvariablen das Wildcardsymbol (_) eingesetzt. In Zeile 3 wird nun anhand des Prädikates exists_instance/3 überprüft, ob es vom Prozess P0 im übermittelten Zustand State eine gestartete Instanz gibt. Beim dritten Parameter des Prädikats wäre es möglich, eine bestimmte Instanz zu binden, um zu überprüfen, ob sie gestartet wurde. Diese Information kann nachfolgend für weitere Restriktionen im Constraint benutzt werden. Somit ist das Prädikat exists_instance/3 in vielerlei Hinsicht einsetzbar. Im obigen Fall dient es lediglich der Existenzquantifizierung: Es prüft, ob es eine gestartete Instanz gibt; ist dies der Fall, so validiert das gesamte Constraint erfolgreich. 4.3.3 Organisatorische Constraints Ein Constraint der organisatorischen Perspektive ist in Listing 4.1 von Zeile 34 bis Zeile 38 spezifiziert. Das Constraint betrifft die Handlungen start,finish und abort, wie im ersten Parameter des Constraints spezifiziert. Der zweite Parameter ist durch eine Wildcard (_) ersetzt worden. Hierdurch wird ausgedrückt, dass das Constraint unabhängig von einem Zustand ist und somit für alle möglichen Zustände des Prozesses Anamnese durchführen gilt. Das gleiche Prinzip wird auch bei der Instanz angewandt, das heißt, es gilt auch für alle möglichen Instanzen des Prozesses. Der vierte Parameter des Constraints ist eine Liste, die die ungebundene Variable Agent enthält. Sie wird verwendet, da man manche Prozesse soweit einschränken möchte, dass sie von mehreren Personen gleichzeitig ausgeführt werden müssen. In diesem Fall werden mehrere ungebundene Variablen in diese Liste eingefügt. Folgendes Szenario sei als Beispiel angeführt: Ein Prozess muss immer von einem Angestellten und seinem Vorgesetzten gleichzeitig ausgeführt werden. Man nennt dieses Konzept das n-Augenprinzip. In diesem Fall würde die Liste in Parameter 4 aus zwei Agentenvariablen bestehen. An die erste Variable wird der Angestellte und an die zweite der Vorgesetzte gebunden. Im fünften Parameter des Constraints wird nun der Agent ermittelt, der den Prozess ausführen kann. Im Prozessmodell aus Abbildung 4.1 wurde dieser auf einen Arzt eingeschränkt. In den Zeilen 36 bis 37 werden nun diejenigen Personen ermittelt, die an die Variable Agent gebunden werden können. Dabei werden die Daten aus einer Ontologie ermittelt und alle Personen, Rollen, Beziehungen etc., die im Prozessmodell referenziert sind, darin abgespeichert. Bei der Ermittlung des Agenten, der den Prozess ausführen kann, werden zwei Teilschritte nacheinander ausgeführt: In einer ersten Anfrage (Zeile 36) werden alle entsprechenden Personen aus der Ontologie ermittelt und an die Variable Agent gebunden. In einem zweiten Verfeinerungsschritt (Zeile 37) werden diese Personen nochmals eingeschränkt: Die Person muss gleichzeitig auch ein Arzt sein (org:plays clinic:Arzt). Um zu verdeutlichen, wie eine Suche in einer klinischen Ontologie aussehen kann, zeigt Abbildung 4.2, wie klinische Strukturen codiert werden können. Die abgebildete Ontologie stellt nur einen kleinen Auszug aus einer weitaus größeren klinischen Ontologie dar, allerdings ist sie für die Erklärung der Auswertung der organisatorischen Constraints ausreichend. Im linken Teil der Grafik ist die chirurgische Abteilung (clinic:Chirurgie) zu sehen, die vom Typ org:Abteilung ist, genau wie die kardiologische Abteilung (clinic:Kardiologie) auf der rechten Seite. Beide Abteilungen haben Mitarbeiter 54 Modellierung clinic:Kardiologie :Jacob :Hugo :Jack :Kate org:supervises org:supervises org:Rolle org:Person org:Abteilung org:supervises org:plays org:plays org:plays org:plays :Charles :Peter :John :Claire org:Personorg:Abteilung org:plays org:plays org:plays org:plays org:member org:member clinic:Chefarzt clinic:Oberarzt clinic:Arzt clinic:MTA clinic:Chirurgie Abbildung 4.2: Auszug aus einer klinischen Ontologie (org:member), die vom Typ Person sind (org:Person). In der chirurgischen Abteilung sind dies Charles,Peter,John und Claire, in der kardiologischen Abteilung Jacob, Hugo,Jack und Kate. Jede Person hat eine gewisse Rolle in der ihr zugeordneten Abteilung. Dies wird durch eine Relation (org:plays) zwischen der Person und der Rolle modelliert. Chefarzt, Oberarzt, Arzt und MTA (Medizinisch-technische/r Angestellte/er) sind Beispiele für Rollen, die man in einem Krankenhaus vorfindet. Charles wäre im vorliegenden Beispiel der Chefarzt (clinic:Chefarzt) der chirurgischen und Jacob der der kardiologischen Abteilung. Im organisatorischen Constraint aus dem codierten Prozessmodell in Listing 4.1 werden in einer ersten Anfrage alle Personen ermittelt (Zeile 36). Diese Personen werden nun in einer zweiten Anfrage auf den Kreis der Ärzte eingeschränkt (Zeile 37). Mit Bezug auf die klinische Beispielontologie sind John und Jack Kandidaten, also diejenigen Personen, die den Prozess Anamnese durchführen ausführen können. 4.3.4 Datenbezogene Constraints In der datenbezogenen Perspektive ist primär eine Unterscheidung zwischen der Datenproduktion und der Datenabhängigkeit zu treffen. Erstere spezifiziert, welche Daten der Prozess bei der Ausführung erzeugt. Dies wird im Prozess Anamnese durchführen durch ein Faktum in Zeile 44 bis 47 (Listing 4.1) deklariert: Beim Starten des Prozesses wird die sogenannte Patientenakte angelegt. Ein bestimmter Zustand (Parameter 2 des Constraints) oder eine bestimmte Instanz (Parameter 3) werden in diesem Beispiel nicht referenziert. Eine Datenabhängigkeit ist im Prozess nicht vorhanden, weshalb an dieser Stelle das Constraint aus dem Prozessschritt Operationsplan vorbereiten referenzieren wird. Listing 4.5 zeigt den Codeausschnitt der Datenabhängigkeit. Hier ist spezifiziert, dass die im Prozessschritt Anamnese durchführen erzeugte Patientenakte benötigt wird. Dies ist wiederum unabhängig von einem bestimmten Zustand (Parameter 2) oder einer bestimmten Instanz (Parameter 3). Das Constraint betrifft alle Handlungen, die auf den Prozess ausgeführt werden können (Parameter 1). 4.3.5 Operationale Constraints Im Prozessmodell in Listing 4.1 ist von Zeile 53 bis Zeile 57 ein operationales Constraint modelliert. Es ist auf die Handlungen start,finish und abort (Parameter 1) 4.4. Zusammenfassung 55 1data_constraint([start, finish, abort], _, _, [Data], 2( 3instantiates_class(Data, ’clinic:Patientenakte’) 4)). Listing 4.5: Modellierte Datenabhängigkeit im Prozess P1 fokussiert, spezifiziert aber keinen bestimmten Zustand oder keine bestimmte Instanz (Wildcards in Parameter 2 und 3). In einem ersten Schritt wird in der Ontologie nach allen Software-Applikationen gesucht (Zeile 55), was dann auf die HIS-Anwendung eingeschränkt wird (Zeile 56). 1instantiates_class(Tool, ’op:Software’), 2instantiates_class(DataType, ’data:data_type’), 3DataType::’data:has_label’(’RTF’), 4Tool::’software:can_read’(DataType). Listing 4.6: Ermittlung aller .rtf-fähigen Textverarbeitungsprogramme Das Werkzeug, mit dem der Prozess bearbeitet werden kann, muss nicht unbedingt auf ein einziges eingeschränkt werden. So kann man beispielsweise auch eine Anfrage an die operationale Ontologie starten, die alle Applikationen herausfindet, mit denen man ein Datei von Typ .rtf (Rich Text Format) öffnen kann. Ein Constraint in ESProNa ist in Listing 4.6 abgebildet. Durch die Anfrage werden mehrere Programme ermittelt. Der Prozessausführende kann sich dabei aus der Liste der ermittelten Applikationen diejenige aussuchen, mit der er am besten zurechtkommt. 4.4 Zusammenfassung Ziel dieses Kapitels war es, aufzuzeigen, wie die constraintbasierte Modellierung von Prozessen mit ESProNa erfolgen kann. Anhand eines Anwendungsfalls wurde die verbale Beschreibung eines klinischen Ablaufes zuerst in ein grafisches Prozessmodell und nachfolgend in Prozessconstraints umgesetzt. Mit Hilfe dieser Spezifikationen kann im nachfolgenden Kapitel gezeigt werden, wie die Validierung eines Prozesse erfolgt, um zur Laufzeit zu entscheiden, ob dieser ausgeführt werden kann oder nicht. 56 Modellierung Kapitel 5 Validierung Ziel dieses Unterkapitels ist es, einen Überblick zu geben, wie die Auswertung der in den ESProNa-Modellen enthaltenen Prozessconstraints erfolgt. Danach wird erklärt, wie dem ProcessNavigator mitgeteilt wird, welche Prozesse durch den Benutzer ausgeführt werden dürfen und welche nicht. 5.1 Auswertung der POPM-Prozessconstraints Bei der Überprüfung, ob ein Prozess zur Laufzeit ausführbar ist oder nicht, erfolgt eine Validierung über alle Perspektiven hinweg. Jede der einzelnen Regeln in den jeweiligen Perspektiven muss erfolgreich validieren. Aus logischer Sicht erfolgt zuerst eine UND-Verknüpfung der einzelnen Regeln. Durch die Auswertung dieser konjunktionalen Verbindung von Prozessconstraints werden die ausführbare Prozessinstanz (funktionale Perspektive), der Agent (organisatorische Perspektive), die benötigten Daten (datenbezogene Perspektive) sowie das Werkzeug (operationale Perspektive) ermittelt, mit denen der Prozess ausgeführt werden kann. Die verhaltensbezogene Perspektive liefert in diesem Zusammenhang keine Daten, sondern überprüft den Zustand der anderen Prozesse. Der Kontrollfluss eines Prozessmodells, also die verschiedenen Ausführungsund Entscheidungsmöglichkeiten für den Endnutzer, ergibt sich aus der Gesamtheit aller Perspektiven. Im Folgenden soll nun die Auswertung der Prozessregeln durch ESProNa untersucht werden. Für die einzelnen Handlungen, die auf einen Prozess ausgeführt werden, müssen gewisse Voraussetzungen (sie sind in den Prozessregeln codiert) erfüllt sein. Um die Auswertung dieser Voraussetzungen genauer zu erläutern, ist ein chronologisches Vorgehen sinnvoll: Es wird angenommen, das Prozessmodell aus Abbildung 4.1 soll ausgeführt werden, und seitens des ProcessNavigators wird ESProNa aufgefordert, es zu laden. Nachdem die Syntaxprüfung erfolgt ist und keine Fehler festgestellt wurden, liefert ESProNa der Ausführungsumgebung den initialen Zustand des Prozessmodells zurück. Dieser Initialzustand spiegelt den Zustand im Start-Prozess des Modells wider und wird zusammen mit einer ersten Anfrage an ESProNa übermittelt. Weiterhin kann dieser Zustand abgespeichert werden (Dateisystem, Datenbank, etc.), um zum Beispiel eine Sicherung bei noch nicht abgeschlossenen Prozessmodellen am Ende eines Arbeitstages zu erstellen. Als nächstes kann die Ausführungsumgebung bei ESProNa abfragen, welche Prozesse, basierend auf dem übermittelten Zustand, gestartet werden können. Dabei werden alle Handlungen, basierend auf den modellierten Constraints des jeweiligen Prozesses, über57 64 Validierung Kapitel 6 Erweiterbarkeit Eines der in Kapitel 1 angesprochenen Probleme ist die mangelnde Erweiterbarkeit und die fehlende Anpassbarkeit der bisherigen PMS an die Ansprüche des Prozessmodellierers. Ziel dieses Kapitels ist es zu zeigen, wie die deklarative PMS ESProNa erweitert werden kann. Es wird dabei im Detail erklärt, wie die Implementierung neuer Modellierungskonstrukte erfolgen kann, und auch darauf eingegangen, wie die semantische Bedeutung der neuen Symbole in deklarative Constraints übersetzt werden können. Des Weiteren wird gezeigt, wie eine neue POPM-Perspektive in ESProNa hinzugefügt werden kann, um die Ausdrucksstärke der Sprache zu erweitern. 6.1 Neue Modellierungskonstrukte Durch die Erweiterung einer Modellierungssprache um individuelle und mächtige Symbole kann die Komplexität eines Prozessmodells verringert werden [29]. Bevor jedoch ein neues Konstrukt verwendet werden kann, muss zuerst eine klare semantische Definition des Modellierungssymbols erstellt werden. Diese semantische Beschreibung wird in iPM2erstellt, da die Symbole auch dort bei der Modellierung verwendet werden. Das in Kapitel 3.3 verwendete Konzept zur Kategorisierung der Prozessconstraints nach POPM-Perspektiven, Prozesshandlungen, Prozesszuständen und Prozessinstanzen kann auch hier mit eingebracht werden. Bei der Neukonstruktion eines Modellierungskonstruktes muss man sich zunächst die Frage stellen, ob das Symbol eine oder mehrere POPM-Perspektiven betreffen soll. Der in imperativen PMS verwendete durchgezogene Pfeil, der zwei Prozesse miteinander verbindet, fokussiert alleine die verhaltensbezogene Perspektive. Doch können bei der Definition eines neuen Konstrukts auch mehrere Perspektiven von dessen semantischer Bedeutung betroffen sein. Eine weitere Frage ist, ob das neue Modellierungssymbol als prozessverbindendes oder als prozessübergreifendes Symbol kategorisiert werden muss. Ersteres verbindet zwei Prozesse miteinander und wird im nachfolgenden Abschnitt 6.1.1 genau erklärt. Ein Beispiel für ein prozessübergreifendes Symbol wird in Abschnitt 6.1.2 gezeigt. Beide Konzepte können auch miteinander kombiniert werden, wie in diesem Unterkapitel ebenfalls gezeigt wird. Die Frage, ob es neben diesen beiden Konzepten noch weitere grundlegende Arten an Verbindungstypen gibt, muss an dieser Stelle offen gelassen werden. Im Zuge der geleisteten Forschungsarbeiten und der erwünschten Vereinfachung von Prozessmodellen reichten Modellierungssymbole aus den beiden genannten Kategorien aus, um die gewünschten Ziele zu erreichen. 65 66 Erweiterbarkeit 6.1.1 Prozessverbindende Symbole Beschreibt man den durchgezogenen Pfeil in seiner Bedeutung für den Kontrollfluss eines Prozessmodells, so sagt dieser aus, dass der Prozess B, bei dem der Pfeil eingeht, erst nach dem Prozess A, von dem der Pfeil ausgeht, ausgeführt werden kann. Für den Prozess B ergibt sich folglich eine Abhängigkeit von Prozess A. Da die aktuellen kommerziellen PMS einem imperativen Stil folgen, das heißt, jeder Schritt genau vordefiniert ist, lässt sich für die Bedeutung des durchgezogenen Pfeils eine weitere Frage bezüglich der semantischen Definition ableiten. Bisher wurde er so definiert, dass der Prozess, bei dem der durchgezogene Pfeil eingeht, unmittelbar nach dem Prozess, von dem der Pfeil ausgeht, ausgeführt wird. Doch kann es durchaus sein, dass - zeitlich gesehen - dazwischen auch andere Prozesse ausgeführt werden. Das gewünschte Verhalten muss bei der Definition des Symbols beachtet werden und führt zum Gedanken, ein zweites und modifiziertes Konstrukt zuzulassen. Zuvor soll allerdings der Vollständigkeit halber noch ein weiteres Modellierungskonstrukt, der gestrichelte Pfeil, erwähnt werden. Dieser hat sich erst während der vorliegenden Forschungsarbeiten auf dem Gebiet der deklarativen Prozessmodellierung entwickelt. Seine Bedeutung ist sehr einfach, denn er verbindet lediglich zwei Prozesse miteinander, ohne eine Wirkung auf den Kontrollfluss zu haben. So können die zwei Prozesse, die durch einen gestrichelten Pfeil verbunden sind, in beliebiger Reihenfolge ausgeführt werden. Weiterhin hat man durch dieses Modellierungskonstrukt die Möglichkeit, einen gewissen Standardablauf zu modellieren, ohne jedoch die Flexibilität des Prozessmodells einzuschränken. Abbildung 6.1 gibt einen Überblick über die bisher definierten Modellierungssymbole. Sie finden anschließend im nachfolgenden Prozessmodell in Abbildung 6.2 Verwendung. A B A B A B ! TIME Abbildung 6.1: Übersicht über die bisher definierten Modellierungssymbole Mit Blick auf das Prozessmodell in Abbildung 6.2 stellt sich die Frage, welcher Kontrollfluss sich aus den Prozessen A bis D ergibt. Aus der Definition des ersten Pfeiles leitet sich ab, dass Prozess B den vorangehenden Prozess A benötigt, also dass dieser abgeschlossen sein muss. Die Definition verbietet allerdings nicht, dass zwischen der Ausführung beider Prozesse noch ein anderer Prozess abgearbeitet werden darf. Genauso können auch vor der Ausführung von A noch andere Prozesse durchgeführt werden. Da Prozess D an den Prozess C durch den gestrichelten Pfeil lose gekoppelt und für diesen Pfeil keine Ablaufreihenfolge definiert ist, kann Prozess D somit noch vor Prozess A ausgeführt werden. Bei der Verbindung zwischen B und C wurde durch den Zusatz !TIME spezifiziert, dass Prozess C unmittelbar auf B folgt und dass dieser abgeschlossen sein muss. Fasst man all diese Informationen zusammen, so ergibt sich für das Modell aus Abbildung 6.2 eine Ablaufsemantik wie in Abbildung 6.3 dargestellt. Man kann - wie bereits 6.1. Neue Modellierungskonstrukte 67 Start Ende DA B C ! TIME Abbildung 6.2: Verwendung der definierten Modellierungssymbole erwähnt - nach dem Starten der Ausführung des Prozessmodells auch mit dem Prozess D beginnen. Dies wird durch den gestrichelten Pfeil dargestellt. Oder aber man beginnt mit Prozess A und entscheidet sich danach, ob man dem Fluss des Prozessmodells folgen möchte, um mit Schritt B weiterzumachen (mittlerer Pfad), oder aber man schiebt Prozess D dazwischen, bevor man mit Prozess B weitermacht (linker Pfad). Man erkennt allerdings in der Abbildung 6.3, dass, nachdem Prozess B ausgeführt wurde, Schritt C immer sukzessiv folgt, das heißt, unmittelbar danach ausgeführt wird. Dies verdeutlicht das zusätzliche !TIME-Symbol auf dem Pfeil in Abb. 6.2. Start Ende A D D B B C C D A B C Abbildung 6.3: Mögliche Abläufe des Prozessmodells aus Abbildung 6.2 6.1.2 Prozessübergreifende Symbole Als weiteres Beispiel für die Vereinfachung eines Prozessmodells durch ein neues Modellierungssymbol wird das Prozessmodell aus Abbildung 6.4 herangezogen. Um die Prozesse A, B und C ist ein Rechteck (im Folgenden als Box bezeichnet) modelliert, das eine verhaltensbezogene Aggregation der drei Prozesse ermöglicht. Es modelliert eine Abhängigkeit zwischen allen Prozessen in der Box und dem Prozess D. Dieses Prozessmodell mit dem neuen Box-Konstrukt ist ein Beispiel dafür, dass eine neues Modellierungssymbol nicht auf das Konzept der Pfeile eingeschränkt sein muss. Im initialen Zustand kann mit Prozess A, B oder C begonnen werden. Alle Prozesse sind über den gestrichelten Pfeil miteinander verbunden. Somit bestehen keinerlei Ab- 68 Erweiterbarkeit Start Ende #= 1 B #= 1 A #= 1 D #= 1 C Abbildung 6.4: Prozessmodell mit verhaltensbezogener Aggregation hängigkeiten zwischen den Prozessen A, B und C. Der Prozess D allerdings benötigt alle drei vorhergehenden Prozesse. Deshalb ist er auch über einen durchgezogenen Pfeil mit der Box verbunden. Benötigt ein Prozess also mehr als einen anderen Prozess, so macht es - wie im obigen Modell gezeigt - Sinn, diese Prozesse in einer Box zu aggregieren und über einen durchgezogenen Pfeil zu verbinden. Man erspart sich hierdurch mehrere Pfeile und macht das Modell übersichtlicher. In Abbildung 6.5 ist erneut die Ablaufsemantik wiedergegeben, wie sie in einer ähnlicher Form in einem imperativen Prozessmodell definiert werden müsste. Start Ende A C B C D B B C A C A B C A B A Abbildung 6.5: Ablaufsemantik des Prozessmodells aus Abbildung 6.4 6.1.3 Übersetzung nach ESProNa Die in Abschnitt 6.1.1 und 6.1.2 erwähnten Symbole Pfeil und Box müssen bei der semantischen Modelltransformation in Prozessconstraints übersetzt werden. Dies ist notwendig, da sich ESProNa rein auf Prozessconstraints stützt. Für den in Abbildung 6.1 enthaltenen gestrichelten Pfeil müssen bei der Übersetzung nach ESProNa keine Constraints angegeben werden. Die Flexibilität dieses Pfeils ist im Grundkonzept von ESProNa bereits enthalten. Der durchgezogene Pfeil (ohne das !TIME-Symbol) wird auf ein verhaltensbezogenes Constraint im Prozess B abgebildet. Listing 6.1 zeigt den Quellcode der verhaltensbezogenen Perspektive des Prozesses B. In Zeile 3 wird überprüft, ob es im Prozess A eine Instanz gibt, die im aktuellen Zustand auch beendet ist. Im Prozess A, von dem der durchgezogene Pfeil ausgeht, müssen keine Constraints modelliert werden. 6.1. Neue Modellierungskonstrukte 69 1:- object(pid_b(_), 2extends(process)). 3... 4behavioral_constraint(necessity, [start], State, _, 5( 6pid_a(_)::exists_instance(State, finish, _) 7)). 8... 9:- end_object. Listing 6.1: ESProNa-Constraint im Prozess B für den durchgezogenen Pfeil Der durchgezogenen Pfeil mit dem auf der Verbindung abgebildeten !TIME-Symbol verlangt, dass nach der Ausführung von Prozess B unmittelbar der Prozess C ausgeführt wird (siehe Abbildung 6.2). Dies bedeutet, dass zwischen der Ausführung von B und C keine anderen Prozesse ausgeführt werden dürfen. Um dieses Verhalten abbilden zu können, muss in allen anderen Prozessen des Prozessmodells ein Constraint eingefügt werden, dass dies sicherstellt. Angenommen, der Prozess B wurde ausgeführt, so muss die Überprüfung, ob neben Prozess C noch andere Prozesse ausgeführt werden, fehlschlagen. Um dies zu realisieren, wird in den anderen Prozessen ein spezielles Constraint in der verhaltensbezogenen Perspektive eingefügt. Listing 6.2 zeigt dies für den Prozess D, der, wie in Abbildung 6.2 dargestellt, nach Prozess C kommt. Das Constraint wird bei der Überprüfung, ob der Prozess C gestartet werden kann, ausgewertet (der zweite Parameter start des Constraints in Zeile 4 spezifiziert dies). Das Prädikat in Zeile 6 überprüft, ob der Prozess B ausgeführt, also beendet (finish) wurde. Ist dies der Fall, so muss auch der Prozess C beendet sein (Zeile 7), sonst wird die Auswertung gezielt fehlschlagen (Zeile 9), da ja vorher erst C ausgeführt sein muss. 1:- object(pid_d(_), 2extends(process)). 3... 4behavioral_constraint(necessity, [start], State, _, 5( 6pid_b(_)::exists_instance(State, finish, _) -> 7pid_c(_)::exists_instance(State, finish, _) 8; 9fail 10 )). 11 ... 12 :- end_object. Listing 6.2: ESProNa-Constraint im Prozess D Die Box drückt eine verhaltensbezogene Abhängigkeit zwischen dem Prozess D und allen in ihr enthaltenen Prozessen aus. Somit müssen in Prozess D drei Prozessconstraints codiert werden, die diese verhaltensbezogene Abhängigkeit ausdrücken. Listing 6.3 zeigt den Quellcode der verhaltensbezogenen Perspektive für den Prozess D aus Prozessmodell 6.4. Von Zeile 3 bis 5 wird bei Auswertung des Constraints überprüft, ob für die drei Prozesse A, B und C beendete Instanzen existieren. Bei der Definition neuer Modellierungssymboliken in iPM2ist eine genaue Abbildung zwischen der Semantik des Symbols und den Constraints wichtig. ESProNa stellt eine Reihe an vordefinierten Prädikaten zur Verfügung, die zur Definition der Prozessconstraints benutzt werden können. Darüber hinaus können eigene Prädikate hinzugefügt 70 Erweiterbarkeit 1behavioral_constraint(necessity, [start], State, _, 2( 3pid_a(_)::exists_instance(State, finish, _), 4pid_b(_)::exists_instance(State, finish, _), 5pid_c(_)::exists_instance(State, finish, _) 6)). Listing 6.3: ESProNa-Code für Prozess D werden, um ESProNa an die individuellen Bedürfnisse der Modellierungsumgebung anzupassen. 6.2 Implementierung neuer Perspektiven ESProNa wurde mit dem Ziel konzipiert, die Sprache für neue Konzepte erweiterbar zu gestalten. Es sei angenommen, dass eine weitere Perspektive implementiert werden soll, die sich mit Quality of Service (QoS) in einem Unternehmen beschäftigt [30]. Durch die Nutzung dieses Konzeptes sollen QoS-Parameter modellierbar sein, sodass zur Laufzeit Aufgaben nur ganz bestimmten Agenten zugewiesen werden, die diesen Anforderungen entsprechen. Es soll an dieser Stelle weniger auf die Details der Perspektive eingegangen, sondern lediglich aufgezeigt werden, wie grundsätzlich neue Perspektiven in ESProNa implementiert werden können. 6.2.1 Anpassung der Prädikate Um das genannte QoS-Konzept zu aktivieren, muss das Prädikat validate_action/3 in Listing 6.4 in der Signatur (Zeile 1) um einen weiteren Parameter (QoSParameter) ergänzt werden. In Zeile 9 wird ähnlich zu den bereits existierenden Perspektiven eine Verknüpfung mit dem Prädikat conform/4 der neu hinzugekommenen Perspektive angelegt. Hierdurch werden bei Evaluierung des Prädikates validate_action/3 alle Constraints der neu hinzugekommenen Perspektive mit ausgewertet und die darin berechneten QoSParameter dem Prädikat zur Verfügung gestellt. 1validate_action(Action, State, Instance-Agents-Data-Tools-QoSParameter) :- 2::process_actions(ActionList), 3list::member(Action, ActionList), 4::functional_constraints_conform( Action, State, Instance), 5::behavioral_constraints_conform( Action, State, Instance), 6::organizational_constraints_conform( Action, State, Instance, Agents), 7::data_constraints_conform( Action, State, Instance, Data), 8::operational_constraints_conform( Action, State, Instance, Tools), 9::qos_constraints_conform( Action, State, Instance, QoSParameter). Listing 6.4: Prädikat validate_action/3 Neben der Verlinkung der Perspektive mit dem Prädikat validate_action/3 muss die Perspektive noch in ESProNa implementiert werden. Hierzu wird sie, wie alle anderen Perspektiven auch, als sogenannte category angelegt (Listing 6.6), die dann nachfolgend in den Prozess importiert wird (Listing 6.5). Durch dieses Importverfahren wird das Prozessobjekt zum Kompositum aus allen POPM-Perspektiven. Weiterhin muss in der neuen Perspektive bei der Implementierung 6.2. Implementierung neuer Perspektiven 71 1:- object(process, 2imports(functional_constraint, behavioral_constraint, organizational_constraint, 3data_constraint, operational_constraint, qos_constraint)). 4... Listing 6.5: Import der einzelnen Perspektiven in den Prozess des Objekts das Prädikat qos_constraints_conform/4 hinzugefügt werden. Es stellt die Schnittstelle zwischen dem Prozess und der Perspektive dar. Listing 6.6 zeigt die Definition der neu hinzugekommenen QoS-Perspektive. Das Prädikat ist nach dem gleichen Prinzip aufgebaut wie in allen anderen Perspektiven auch. Es sammelt die im Prozessmodell spezifizierten Constraints ein (Zeilen 4 bis 9) und wertet diese aus. Dabei wird bei der Auswertung (Zeile 11) die für die Perspektive charakteristische Variable (hier der QoSParameter) an die berechneten Werte gebunden. Durch dieses generische Prinzip ist der Code zur Integration der bestehenden und auch neuen Perspektiven sehr kompakt. Neben dem qos_constraints_conform/4-Prädikat können zusätzlich Hilfsprädikate zum Code in Listing 6.6 hinzugefügt werden. Diese Prädikate stehen dann bei der Spezifikation der Prozessregeln im Prozessmodell zur Verfügung. Sie tragen unter anderem dazu bei, die Constraints prägnanter, übersichtlicher und modularer zu gestalten. Ein Beispiel hierfür ist in Listing 4.1 im Constraint der funktionalen Perspektive zu sehen (Zeile 27). Dort wird das Prädikat actions_applicable/3 verwendet. Der Code für die Überprüfung, ob die Handlungen im übergebenen Zustand und für die spezifizierte Instanz auch anwendbar sind, wurde in die funktionale Perspektive ausgelagert und wird hier nur referenziert. 1:- category(qos_constraint). 2... 3qos_constraints_conform(Action,ModelState,Instance,QoSParameter) :- 4bagof( Constraints, 5( ::qos_constraint(necessity, ActionList,ModelState,Instance, 6QoSParameter,Constraints), 7list::member(Action,ActionList) 8), 9List 10 ), 11 meta::map({call}, List). 12 ... 13 :- end_category. Listing 6.6: Auszug aus dem Quellcode der neuen QoS-Perspektive Neben validate_action/3 muss im Prozessobjekt noch das in Kapitel 5.2 erwähnte Prädikat perform_action/4 angepasst werden. Dieses Prädikat ist dafür zuständig, dass Informationen über die Ausführung des Prozessschrittes in die Prozesshistorie eingetragen werden. Listing 6.7 zeigt den Quellcode des Prädikates, die geänderten Stellen sind hervorgehoben. Das Eintragen der Informationen in die Historie des Prozesses wird über das Prädikat update_model_state/3 realisiert. In Zeile 5 (Listing 6.7) wird der neue QoS-Parameter lediglich an den Term im zweiten Parameter des Prädikats angehängt. Der Code des Prädikats update_model_state/3 ist so generisch gehalten, dass keine weiteren Änderungen notwendig sind. 72 Erweiterbarkeit 1perform_action(Action, ModelState, Instance-Agents-Data-Tools-QoSParameter, 2NextModelState) :- 3... 4::id(PID), 5ModelState::update_model_state(PID, Instance-Action-Agents-Data-Tools-QoSParameter, 6NextModelState). Listing 6.7: perform_action/4 mit neuer QoS-Perspektive 6.2.2 Schritte der Anpassung Die Erweiterung ESProNa’s um eine neue Perspektive gliedert sich in folgende Teilschritte: •Erweiterung des dritten Parameters des Prädikats validate_action/3 um den Parameter des neuen Konzepts. •Implementierung des neuen Konzepts als category und Speicherung dieser Datei mit der Endung .lgt in einem neuen Ordner qos_perspective im übergeordneten Ordern popm. •Import der neu erstellten category in das zentrale process-Objekt. •Anpassung des Prädikates perform_action/4 im process-Objekt durch Hinzufügen des neuen Parameters an den vierten Parameter des Prädikates. Die einzelnen Schritte müssen nicht in genau dieser Reihenfolge ablaufen, sondern können beliebig sein. Wichtig ist allerdings, dass bevor die neue Kategorie in die loaderDatei von ESProNa eingebunden wird, alle Arbeiten abgeschlossen sind. Sonst würden beim Starten von ESProNa Fehlermeldungen erscheinen und diesen unterbinden. In Anhang A wird gezeigt, wie ESProNa installiert werden kann und wie es durch Aufruf der loader-Datei gestartet werden kann. Listing 6.8 zeigt einen Ausschnitt aus der veränderten loader-Datei mit der neu hinzugefügten Perspektive. 1... 2logtalk_library_path(op_perspective, popm(’operational_perspective/’)). 3logtalk_library_path(qos_perspective, popm(’qos_perspective/’)). 4... 5write(’+++ Loading POPM Operational Perspective definitions...’), 6logtalk_load(op_perspective(operational_constraint)), 7... 8write(’+++ Loading POPM QoS Perspective definitions...’), 9logtalk_load(qos_perspective(qos_constraint)), 10 ... Listing 6.8: Angepasste loader-Datei Zeile 3 macht den neuen Ordner für ESProNa bekannt, und in Zeile 9 wird die neu erstellte Perspektive geladen. Eine weitere und optionale Aufgabe ist die Ergänzung der qos_category.lgt-Datei um individuelle Prädikate, die in den Constraints zu dieser Perspektive verwendet werden können. 6.3. Zusammenfassung 73 6.3 Zusammenfassung In diesem Kapitel wurde gezeigt, wie ESProNa durch die Definition von neuen Modellierungssymbolen erweitert werden kann. Durch dieses Konzept wird dem Modellierer die Möglichkeit gegeben, die PMS den individuellen Gegebenheiten des Unternehmens anzupassen. Durch das Hinzufügen von neuen Modellierungssymbolen mit unterschiedlichen Semantiken kann die Pfadkomplexität eines Prozessmodells deutlich verringert werden. Modellierte Geschäftsprozesse, die dieses Konzept verwenden, haben den Vorteil, dass die erstellten Modelle wesentlich übersichtlicher werden. Durch den modularen und generischen Ansatz ist die Sprache zudem leicht erweiterbar, wie am Beispiel der QoS-Perspektive gezeigt wurde. 80 Prozessnavigation pid_0: [], pid_1: [], pid_2: [], ModelDoneCode: 0 pid_0: [1-start-[org#Jack]-[]-[software#HIS]] pid_1: [] pid_2: [] ModelDoneCode: 0 Action: start, Process/Instance: pid_0/1, Agent: [org#Jack], Data: [], Tool: [software#HIS] pid_0: [1-start-[org#Jack]-[]-[software#HIS],1-finish-[org#Jack]-[clinic#Patientenakte]-[software#HIS]] pid_1: [] pid_2: [] ModelDoneCode: 0 Action: finish, Process/Instance: pid_0/1, Agent: [org#Jack], Data: [clinic#Patientenakte], Tool: [software#HIS] pid_0: [1-start-[org#Jack]-[]-[software#HIS],1-finish-[org#Jack]-[clinic#Patientenakte]-[software#HIS]] pid_1: [1-start-[org#John]-[]-[software#HIS]] pid_2: [] ModelDoneCode: 0 Action: start, Process/Instance: pid_1/1, Agent: [org#John], Data: [], Tool: [software#HIS] pid_0: [1-start-[org#Jack]-[]-[software#HIS],1-finish-[org#Jack]-[clinic#Patientenakte]-[software#HIS]] pid_1: [1-start-[org#John]-[]-[software#HIS],1-finish-[org#John]-[clinic#Operationsplan]-[software#HIS]] pid_2: [] ModelDoneCode: 0 Action: finish, Process/Instance: pid_1/1, Agent: [org#John], Data: [clinic#Operationsplan], Tool: [software#HIS] pid_0: [1-start-[org#Jack]-[]-[software#HIS],1-finish-[org#Jack]-[clinic#Patientenakte]-[software#HIS]] pid_1: [1-start-[org#John]-[]-[software#HIS],1-finish-[org#John]-[clinic#Operationsplan]-[software#HIS]] pid_2: [1-start-[org#Charles]-[]-[software#HIS]] ModelDoneCode: 0 Action: start, Process/Instance: pid_2/1, Agent: [org#Charles], Data: [], Tool: [software#HIS] Action: finish, Process/Instance: pid_2/1, Agent: [org#Charles], Data: [clinic#Operationsplan_OK], Tool: [software#HIS] pid_0: [1-start-[org#Jack]-[]-[software#HIS],1-finish-[org#Jack]-[clinic#Patientenakte]-[software#HIS]] pid_1: [1-start-[org#John]-[]-[software#HIS],1-finish-[org#John]-[clinic#Operationsplan]-[software#HIS]] pid_2: [1-start-[org#Charles]-[]-[software#HIS],1-finish-[org#Charles]-[clinic#Operationsplan_OK]-[software#HIS]] ModelDoneCode: 1 Abbildung 7.2: Lösungsweg für das klinische Prozessmodell vom Initialzum Endzustand spezifische Änderungen am Quellcode konnten die Suchalgorithmen für die Implementierung eines Prozessnavigationssystems verwendet werden. ESProNa kommuniziert mit den Suchalgorithmen über eine fest definierte Schnittstelle, in der festgelegt wird, welche Prädikate implementiert werden müssen. Wie schon der Name „Breitensuche“ sagt, wird bei diesem Verfahren zuerst in der Breite gesucht; dabei werden primär alle möglichen Verzweigungen weiterverfolgt. Für jede dieser Verzweigungen wird wieder parallel weitergesucht, bis eine Lösung gefunden wird. Abbildung 7.1 zeigt den Grundgedanken der parallelen Verarbeitung im Ansatz. Wendet man diese Suche auf das klinische Prozessmodell an, so müssen sehr viele Zustände durchlaufen werden, um einen Lösungsweg zum Ziel zu finden. Listing 7.6 zeigt einen Aufruf der Breitensuche (Zeile 4) mit generiertem Initial- (Zeile 2) und Finalzustand (Zeile 3). Durch das Einbinden einer Performanzanalyse (Zeilen 1 und 5) ist es möglich, detaillierte Informationen über den Verlauf der Suche zu erhalten. Die Lösung ergibt 7.1. Konzeption 81 sieben Prozessschritte (Zeile 7), allerdings müssen dazu beim Suchverfahren Breitensuche sehr viele Zustände bzw. Zustandsübergänge generiert und untersucht werden (Zeile 8). Das bedeutet aber für den Nutzer eine relativ lange Wartezeit, bis er eine Antwort auf seine Navigationsanfrage bekommt. Die lange Laufzeit von 3,7 Sekunden (Zeile 10), die für das relativ kleine Prozessmodell mit drei Schritten durch den Report gemessen wird, wird von dem Verhältnis zwischen der Anzahl an untersuchten Zuständen und der Lösungslänge in Zeile 9 untermauert. Dieser Quotient ist mit 0,0025 sehr niedrig und deutet darauf hin, dass bei der Suche zum Ziel oft in Pfade verzweigt wird, die nicht zur Lösung beitragen. 1?- performance::init, 2process_planning::initial_state(set_up_surgery_plan, IS), 3process_planning::goal_state(set_up_surgery_plan, GS), 4esprona_breadth_first(6)::solve(process_planning, IS,GS,Path), 5performance::report. 6... 7solution length: 7 8state transitions (including previous solutions): 2800 9ratio solution length / state transitions: 0.0025 10 time: 3.7 sec Listing 7.6: Aufruf und Performanzreport der Breitensuche Die Charakteristik der abgebildeten Tiefensuche aus Listing 7.7 ist konträr zur Breitensuche. Bei diesem Suchalgorithmus wird ein bestimmter Weg immer weiter in die Tiefe verfolgt, bis eine bestimmte Grenze oder eine Lösung gefunden wurde. Im Performanzreport in Listing 7.7 ist zu erkennen, dass das Verhältnis zwischen der Lösung und den untersuchten Zuständen (Zeile 9) wesentlich besser ist als bei der Breitensuche. Auch ist die Suchzeit mit 0,03 Sekunden um ca. den Faktor 123 kürzer als die bei der Breitensuche. Der Vorteil hieraus ergibt sich für den Nutzer des ProcessNavigators. Deutlich verkürzte Wartezeiten bei Navigationsanfragen machen die Nutzung dieses Features wesentlich angenehmer. 1?- performance::init, 2process_planning::initial_state(set_up_surgery_plan, IS), 3process_planning::goal_state(set_up_surgery_plan, GS), 4esprona_depth_first(6)::solve(process_planning, IS,GS,Path), 5performance::report. 6... 7solution length: 7 8state transitions (including previous solutions): 23 9ratio solution length / state transitions: 0.304 10 time: 0.03 Listing 7.7: Aufruf und Performanzreport der Tiefensuche Wenn man nun allerdings vermutet, dass die Tiefensuche den am besten geeigneten Algorithmus darstellt, so trifft das nicht zu. Die Laufzeit des Algorithmus hängt auch sehr viel von dem im ersten Parameter übermittelten Grenzwert ab, der bei der Suche mit übergeben wird: esprona_depth_first(6). Bei größeren Prozessmodellen muss dieser angepasst werden. Des Weiteren darf man nicht die kombinatorische Komplexität vergessen, die man bereits bei der Breitensuche erkennen konnte: 2800 generierte Zustandsübergänge bei einem Prozessmodell mit lediglich drei Prozessschritten! Aus die- 82 Prozessnavigation sem Grund beschäftigt sich das folgende Kapitel 8 mit den heuristischen Verfahren, die auf einer Erweiterung des Prädikates next_state/2 aufbauen. 7.2 Navigation zwischen beliebigen Zuständen Für die spezielle Art der Navigation, bei der Pfade zwischen beliebigen Zuständen gefunden werden sollen, wird das Prädikat navigate/4 verwendet. Es ermittelt bei Input eines gegebenen Zustands und Bedingungen für den gesuchten Zielzustand den Pfad dorthin. Dabei muss dieser Zielzustand nicht bekannt sein, sondern er wird automatisch durch das Verfahren mitberechnet. Das Prädikat versucht dabei unter Zuhilfenahme der Suchalgorithmen einen Pfad zum Zielzustand zu ermitteln, in dem die spezifizierten Bedingungen gelten. Diese müssen sich nicht nur alleine auf den Zielzustand beziehen, sondern dürfen auch Einschränkungen auf dem Pfad dorthin modellieren. Ähnlich dem Navigationssystem im Auto, bei dem man zum Beispiel die „schnellste Route“ als Option wählen kann, kann dies auch für die Prozessnavigation interessant sein. Listing 7.8 zeigt detailliert den Aufbau des Prädikates navigate/4. Der erste Parameter FromState repräsentiert den Zustand, in dem sich der Prozessausführende gerade befindet. Der Zustand ToState (zweiter Parameter) entspricht dem gesuchten Zustand, in dem bestimmte Bedingungen gelten sollen. Diese werden durch die Variable Conditions repräsentiert, die im vierten Parameter angegeben wird. Dieser Zustand wird normalerweise als ungebundene Variable an das Prädikat übergeben. Die spezifizierten Bedingungen des vierten Parameters markieren Restriktionen, die im Zustand ToState gelten müssen. Diese Einschränkungen müssen angegeben werden und sind in der mode-Direktive nochmals codiert: +term(conditions). Der Code des Prädikates ist sehr einfach und besteht lediglich aus zwei Zeilen. Liest man die Zeilen 7 und 8, so darf man diese nicht als aufeinanderfolgenden Ablauf verstehen, in dem zuerst das Problem durch den Aufruf des Prädikates solve/4 gelöst und nachfolgend die Bedingungen aufgerufen werden. Vielmehr wird durch das in Prolog implementierte Konzept des Backtrackings versucht, beide Bedingungen zu erfüllen. Dabei werden alternierend so lange Suche (Zeile 7) und Überprüfung der Bedingungen (Zeile 8) durchgeführt, bis entweder eine Lösung gefunden wurde oder die Suche fehlgeschlagen ist. Die Lösung wird im Erfolgsfall an die Variable Path gebunden und dem Nutzer mitgeteilt. Sie entspricht einer Worklist, die abgearbeitet werden muss, um zum gewünschten Zustand zu kommen. 1:- public(navigate/4). 2:- mode(navigate(+list(state), ?list(state), ?list(path), 3+term(conditions)), 4zero_or_more). 5 6navigate(FromState,ToState,Path,Conditions) :- 7esprona_depth_first(6)::solve(process_planning, FromState,ToState,Path), 8{Conditions}. Listing 7.8: Navigation zwischen bestimmten Prozesszuständen In Listing 7.9 ist der Code für eine Beispielanfrage einer Suche zwischen zwei bestimmten Zuständen abgebildet. In Zeile 1 ist der Ausgangszustand zu sehen, in dem sich der Prozessausführende befindet: Der Prozess P0 wurde von John gestartet. Ausgehend von diesem Zustand möchte man nun zu einem Zustand ToState navigieren, in dem der Prozess P2 von einem Agenten der chirurgischen Abteilung ausgeführt werden 7.2. Navigation zwischen beliebigen Zuständen 83 kann. Dies ist im Listing 7.9 in den Zeilen 8 und 9 als Bedingungen codiert. Insofern das Prädikat erfolgreich terminiert, also ein Pfad gefunden wurde, wird dieser an die Variable Path des dritten Parameters gebunden. Durch den ProcessNavigator wird das Ergebnis aufbereitet, das bedeutet, der Pfad in eine ansprechende Worklist umcodiert und dem Nutzer präsentiert. Dieser kann sich dann entscheiden, ob er sie abarbeiten will, um zum gewünschten Zustand ToState zu gelangen, oder nicht. 1?- InState = model_state( 2[process_state(pid_0, [1-start-[’org#John’]-[]-[’software#HIS’]]), 3process_state(pid_1, []), 4process_state(pid_2, [])], 50), 6process_planning::navigate(InState,ToState,Path, 7( 8pid_2(_)::validate_action(start, ToState,Instance, [Agent], _, _), 9’org#SurgeryDepartment’::’org#member’(Agent) 10 )). 11 12 Instance = 1, 13 Agent = ’org#Charles’ 14 15 Instance = 1, 16 Agent = ’org#Peter’ Listing 7.9: Aufruf der Navigation in ESProNa Als Ergebnis werden unter anderem die in den Bedingungen ungebundenen Variablen an valide Werte gebunden. Nachdem im Prozessmodell aus Abbildung 4.1 modelliert wurde, dass der Prozess P2 vom Vorgesetzten derjenigen Person ausgeführt werden muss, die den Prozess P1 gestartet hat, können nur Charles oder Peter den Prozess in diesem Zustand (ToState) starten. Die Ausgabe der Path-Variablen ist in Abbildung 7.3 grafisch aufbereitet: Der oberste Zustand markiert den Ausgangszustand. Die Zustandsübergänge ¶bis ºmarkieren die verschiedenen Handlungen, die nach und nach ausgeführt werden müssen, um zum doppelt umrandeten Zielzustand zu kommen. Er entspricht dem an die Variable ToState gebundenen Zustand, der im Prädikat navigate/4 spezifiziert wurde. Dort gelten die aus der im vierten Parameter der Anfrage angegebenen Bedingungen: Der Prozess kann in diesem Zustand von einem Agenten aus der chirurgischen Abteilung gestartet werden. Sieht man sich die einzelnen Abfolgen genauer an, so fällt auf, dass zum Beispiel bei ¸eine unnötige Handlung ausgeführt wird: Eine zweite Instanz des Prozesses Operationsplan vorbereiten wird gestartet. Auch in ¹wird eine weitere Instanz gestartet. Diese beiden Handlungen sind jedoch nicht nötig, denn eine gestartet Instanz des Prozesses P1 hätte alleine auch schon genügt, damit der Prozess P2 gestartet werden kann. Somit sind die Zustandsübergangsrelationen ¸und ¹überflüssig. Es ergibt sich daraus die Frage, inwieweit man den im Prädikat navigate/4 benutzten Suchalgorithmus so beeinflussen kann, dass dieser erkennt, dass die beiden genannten Handlungen unnötig sind. Die Antwort darauf wird im folgenden Kapitel 8 beschrieben. Dort wird gezeigt, wie man mit Priorisierung und heuristischen Verfahren den Suchalgorithmus so beeinflussen kann, dass unnötige Ausführungen bei der Navigation nicht mehr berechnet werden. Es sei nur soviel vorweggenommen, dass der dritte Parameter des Prädikates next_state/3 die Empfehlung einer Ausführungsmöglichkeit widerspiegelt. Bei der heuristischen Suche wird lediglich der nächste Zustand mit der besten Empfehlung 84 Prozessnavigation weiterverfolgt, alle weiteren möglichen Zustandsübergänge mit geringeren Gewichtungen aber nicht. Dadurch verläuft die Pfadsuche zum Zielzustand wesentlich schneller ab. pid_0: [1-start-[org#Jack]-[]-[software#HIS]] pid_1: [] pid_2: [] ModelDoneCode: 0 pid_0: [1-start-[org#Jack]-[]-[software#HIS],1-finish-[org#Hugo]-[clinic#Patientenakte]-[software#HIS]] pid_1: [] pid_2: [] ModelDoneCode: 0 Action: finish, Process/Instance: pid_0/1, Agent: [org#John], Data: [clinic#Patientenakte], Tool: [software#HIS] pid_0: [1-start-[org#Jack]-[]-[software#HIS],1-finish-[org#Hugo]-[clinic#Patientenakte]-[software#HIS]] pid_1: [1-start-[org#John]-[]-[software#HIS]] pid_2: [] ModelDoneCode: 0 Action: start, Process/Instance: pid_1/1, Agent: [org#Hugo], Data: [], Tool: [software#HIS] pid_0: [1-start-[org#Jack]-[]-[software#HIS],1-finish-[org#Hugo]-[clinic#Patientenakte]-[software#HIS]] pid_1: [1-start-[org#John]-[]-[software#HIS],2-start-[org#John]-[]-[software#HIS]] pid_2: [] ModelDoneCode: 0 Action: start, Process/Instance: pid_1/2, Agent: [org#John], Data: [], Tool: [software#HIS] pid_0: [1-start-[org#Jack]-[]-[software#HIS],1-finish-[org#Hugo]-[clinic#Patientenakte]-[software#HIS]] pid_1: [1-start-[org#John]-[]-[software#HIS],2-start-[org#John]-[]-[software#HIS], 3-start-[org#John]-[]-[software#HIS]] pid_2: [] ModelDoneCode: 0 Action: start, Process/Instance: pid_1/3, Agent: [org#John], Data: [], Tool: [software#HIS] pid_0: [1-start-[org#Jack]-[]-[software#HIS],1-finish-[org#Hugo]-[clinic#Patientenakte]-[software#HIS]] pid_1: [1-start-[org#John]-[]-[software#HIS],2-start-[org#John]-[]-[software#HIS], 3-start-[org#John]-[]-[software#HIS],1-finish-[org#John]-[clinic#Operationsplan]-[software#HIS]] pid_2,[] ModelDoneCode: 0 Action: finish, Process/Instance: pid_1/1, Agent: [org#John], Data: [clinic#Operationsplan], Tool: [software#HIS] 1 2 3 4 5 Abbildung 7.3: Zustandsraum der Navigation zwischen bestimmten Prozesszuständen 7.3 Interaktion mit dem Nutzer Die angesprochenen Prädikate und Algorithmen dienen als Grundlage für die visuelle Navigation, die dem Nutzer des ProcessNavigators präsentiert wird. Die in Kapitel 2.3.1 eingeführte Worklist, die dem Nutzer die als nächstes anstehenden Aufgaben und Auswahlmöglichkeiten anzeigt, kann jetzt durch die Navigation erweitert werden. Mögliche Ideen hierzu wurden bereits in einem Paper veröffentlicht [33]. Dort werden der Worklist weitere Spalten hinzugefügt, die eine Art Simulation der zukünftigen Abläufe bei vorausgewähltem Prozessschritt ermöglichen. Konkret bedeutet dies, dass der Nutzer des ProcessNavigators einen der nächstmöglichen Schritte anklickt, ihn aber noch nicht ausführt. Basierend auf dieser Information berechnet ESProNa weitere Daten, die für den 7.3. Interaktion mit dem Nutzer 85 Nutzer auf dem Weg zum Zielzustand interessant sein könnten. Anhand eines einfachen Prozessmodells wird das Konzept der erweiterten Worklist in Abbildung 7.4 verdeutlicht und dargestellt. Start Ende #= A..3 B #= 1..2 A #= 1 D #= 1 C Abbildung 7.4: Prozessmodell zur Verdeutlichung der Navigationsinteraktion Das Modell besteht aus vier Prozessen (A bis D) wobei hier nur die funktionalen Perspektiven als Constraints modelliert sind. Die verhaltensbezogene Perspektive wird mittels der in Kapitel 6 neu eingeführten Symbolen definiert. Weitere Perspektiven sind nicht modelliert, um das Beispiel zu vereinfachen. Im Initialzustand berechnet ESProNa, dass mit den Prozessen A, C oder D begonnen werden kann. B ist der einzige Prozess, der nicht direkt ausgeführt werden kann, da er den Prozessschritt A benötigt. Sobald der Nutzer einen der Prozessschritte auswählt, berechnet ESProNa die möglichen Konsequenzen. Würde sich der Prozessausführende für den Prozess C entscheiden und diesen auswählen, so würden Informationen wie in Abbildung 7.5 berechnet werden. Worklist danach zukünftige Schritte A B D nicht mehr ausführbar CA D Worklist A C D Abbildung 7.5: Informationsausgabe bei Vorauswahl von Prozess C Das Rechteck um den Prozess C in der Worklist (linke Spalte in Abbildung 7.5) zeigt, dass der Nutzer diesen Prozess vorausgewählt hat. Dabei werden die restlichen Spalten neu berechnet. In der zweiten Spalte wird darüber informiert, welche Prozesse in der nachfolgenden Worklist auftauchen würden, falls Prozess C ausgeführt wird. Prozess B ist hier noch nicht mit aufgelistet, da Prozess A noch nicht ausgeführt wurde. In der Spalte „zukünftige Schritte“ werden alle Prozesse aufgelistet, die nach Ausführung von Prozess C irgendwann später noch möglich sind. Da Prozess C nur einmal ausgeführt werden kann, erscheint er in der vierten Spalte. Dort werden alle Prozesse gelistet, die nach der Ausführung des vorausgewählten Prozesses nicht mehr durchführbar sind. Würde der Nutzer jetzt auf den Prozess B in der Spalte der „zukünftige Schritte“ klicken, so öffnet sich ein kleines Informationsfenster, das anzeigt, dass vor Prozess B erst Schritt A ausgeführt werden muss; Abbildung 7.6 zeigt das. Insgesamt kann also die Simulation von Ausführungen dazu benutzt werden, um dem Prozessausführenden Informationen zu geben, die eventuell seine Entscheidungen im aktuellen Zustand beeinflussen. So könnte die Information, dass der Prozess C nach einer einmaligen Ausführung nicht mehr erneut ausgeführt werden kann, den Nutzer eventuell davon abhalten, ihn zuerst durchzuführen. 86 Prozessnavigation A B D Zuerst: A zukünftige Schritte Abbildung 7.6: Informationsausgabe beim Anklicken von Prozess B 7.4 Verzögerte Validierung Als nächstes soll an dieser Stelle die verzögerte Validierung eingeführt werden. Sie ergänzt die Validierung aus Kapitel 5.2 um das Konzept der verzögerten Auswertung und wurde bereits in einem Paper [34] auf der Konferenz CollaborateCom [35] veröffentlicht. Die Idee hinter diesem Verfahren lässt sich am besten an einem Beispiel erklären: Abbildung 7.7 zeigt dazu ein minimales Prozessmodell. Es modelliert lediglich die funktionale, verhaltensbezogene und organisatorische Perspektive, was für die Erklärung des Prinzips aber völlig ausreichend ist. Der durchgezogene Pfeil zwischen den beiden Prozessen Operationsplan vorbereiten und Operationsplan genehmigen modelliert eine verhaltensbezogene Abhängigkeit zwischen den Prozessen, die dazu führt, dass der Prozess P2 erst nach dem Prozess P1 ausgeführt werden kann. Des Weiteren bezieht sich das im Prozess P2 spezifizierte Constraint der organisatorischen Perspektive auf die ausführende Person des Prozesses P1. Es modelliert nämlich, dass der Agent in P2 ein Vorgesetzter des Agenten aus P1 sein muss. Nach der Ausführung des Prozesses Operationsplan vorbereiten wird anhand der Historie und Ontologie diejenige Person ermittelt, die Vorgesetzter des Agenten aus P1 ist. Es sei angenommen, das Prozessmodell verwende die in Kapitel 4 aufgezeigte klinische Ontologie aus Abbildung 4.2, und John ist der Agent, der den Prozess Operationsplan vorbereiten ausgeführt hat. Als Agenten für den Prozess Operationsplan genehmigen kommen Peter und Charles in Frage, da sie die Vorgesetztenrolle erfüllen. PID: P1 Agent org:plays clinic:Assistant Doctor PID: P2 #= 1 start, finish, abort #= 1 start, finish, abort Agent org:supervisorOf P1.executedBy() Start Ende Operationsplan vorbereiten Operationsplan genehmigen Abbildung 7.7: Klinisches Minimalbeispiel mit durchgezogenem Pfeil Doch was würde passieren, wenn der durchgezogenen Pfeil in Abbildung 7.7 durch einen gestrichelten Pfeil (Abbildung 7.8) ersetzt wird? Er modelliert jetzt keine Abhängigkeit mehr, sodass aus verhaltensbezogener Sicht mit beiden Prozessen begonnen werden kann. Was bedeutet dies aber für die organisatorische Perspektive? ESProNa verfährt nun so, dass die Agenten, die für den Prozess P2 in Frage kommen, Vorgesetzte sein müssen. Diejenige Person, die den Prozessschritt Operationsplan genehmigen durchführen darf, muss ein Vorgesetzter einer anderen Person sein. An dieser Stelle soll 7.5. Zusammenfassung 87 jetzt nicht der Prozess P1 als erstes ausgeführt werden, sondern es wird angenommen, dass Hugo den Prozess P2 als erstes abgearbeitet hat und P1 noch nicht ausgeführt wurde. Welche Personen für den Prozessschritt Operationsplan vorbereiten nachfolgend in Frage kommt, muss zuerst anhand der Ontologie ermittelt werden. Das Ergebnis der Anfrage spezifiziert, dass Hugo Vorgesetzter von Jack und Kate ist. Somit können nur noch diese beiden Agenten den Prozess P1 ausführen, damit das gesamte Szenario noch valide bleibt. Da es zwischen den Abteilungen keine Vorgesetztenbeziehungen gibt, können Agenten aus der chirurgischen Abteilung nicht mehr in Frage kommen. An diesem Beispiel wird das Prinzip der „Verzögerung“ deutlich. Die Auswertung der für den Prozess P1 (Abbildung 7.8) in Frage kommenden Agenten kann auch noch nach Ausführung des Prozesses P2 erfolgen, allerdings mit gewissen Einschränkungen. Deshalb wird die Validierung als „verzögert“ bezeichnet. PID: P1 Agent org:plays clinic:Assistant Doctor PID: P2 #= 1 start, finish, abort #= 1 start, finish, abort Agent org:supervisorOf P1.executedBy() Start Ende Operationsplan vorbereiten Operationsplan genehmigen Abbildung 7.8: Klinisches Minimalbeispiel (vgl. 7.7) mit gestricheltem Pfeil 7.5 Zusammenfassung In diesem Kapitel wurde gezeigt, wie sich das in Kapitel 1 erwähnte Konzept der Prozessnavigation in ESProNa integriert und wie mit Hilfe des expliziten Zustands eines Prozessmodells sowie mit verschiedenen Suchalgorithmen die Navigation umgesetzt und genutzt werden kann. Durch die Simulation von Prozessschritten wurde deutlich, wie die Information dem Nutzer des ProcessNavigators helfen kann, seine Entscheidungen zu optimieren. Der letzte Abschnitt hat gezeigt, wie flexibel und vielfältig ESProNa bei der Validierung der Prozessconstraints eingesetzt werden kann. Kleine Änderungen an der Semantik eines Prozessmodells können große Wirkung auf die Ausführungsmöglichkeiten haben. 88 Prozessnavigation Kapitel 8 Modellierung von Empfehlungen Ziel dieses Kapitels ist es, zu klären, wie in ESProNa Empfehlungen durch den Modellierer ins Prozessmodell mit integriert, wie durch multimodale Logik eine Kategorisierung und Gewichtung der Prozessconstraints erzielt werden kann und welche Auswirkungen dieses Konzept auf die Prozessnavigation hat. Basierend auf dem Modell der Gewichtungen wird ein Kostenmodell für heuristische Suchverfahren abgeleitet und gezeigt, wie die Antwortzeiten der Suchalgorithmen beschleunigt werden können. 8.1 Prozessbezogene Empfehlungen Prozessbezogene Empfehlungen sollen dem Modellierer die Möglichkeit geben, dem Prozessmodell aus seiner Sicht sinnvolle Vorschläge hinzuzufügen, um den Ausführenden der Prozesse in seinen Entscheidungen zu beeinflussen. Wichtig dabei ist, dass diese sogenannten Soft Constraints die Flexibilität des Nutzers nicht einschränken, sondern dass lediglich eine Gewichtung der möglichen Entscheidungen erfolgt. Möchte der Modellierer also an bestimmten Stellen eines Prozesses eine Empfehlung hinzufügen, so kann er dies in Form eines speziell markierten Constraints tun. Dieses Prozessconstraint wird bei der Validierung, ob ein Prozess ausgeführt werden kann, nicht evaluiert. Es wird erst bei der Präsentation der flexiblen Entscheidungsmöglichkeiten im ProcessNavigator evaluiert, wenn es darum geht, die multiplen Entscheidungsmöglichkeiten zu gewichten. Bevor im Detail erklärt wird, wie die Soft Constraints modelliert werden können, soll ein Exkurs in die modale Logik [36] die Idee und das Konzept der Entwicklung prozessbezogener Empfehlungen zeigen. 8.1.1 Multimodale Logik „Modallogiken sind eine Erweiterung der klassischen Logik um die Konzepte ’Zustände’ und ’Zustandsübergänge’. Während Prädikatenlogik davon ausgeht, dass – bezüglich einer gegebenen Interpretation – eine Aussage entweder wahr oder falsch ist, erlaubt Modallogik, dass die Interpretation einer Aussage, also ihr Wahrheitswert, sich ändern kann.“ Weiter heißt es in [37]: „In der einfachsten Modallogik gibt es zusätzlich zu den üblichen logischen Verknüpfungen und Quantoren ¬,∧,∨,⇒,⇔die beiden einstelligen Operatoren 2und 3. Traditionell wird der 2-Operator als der notwendig-Operator und der 3-Operator als der möglich-Operator bezeichnet. Etwas ist notwendigerweise wahr, wenn es in allen vorstellbaren Welten wahr ist.“ Diese Aussage wurde erstmals durch Gottfried Wilhelm Leibniz bereits Anfang des 18. Jahrhunderts formuliert. Basierend 89 96 Modellierung von Empfehlungen zwar nicht verhindert werden, aber eben nicht bei der Präsentation im ProcessNavigator an oberster Stelle gleichwertig mit allen anderen Handlungen stehen sollte. Die zweite Regel minimiert die Instanzen eines Prozesses. Wurde in der funktionalen Perspektive eines Prozess ein Wertebereich für die möglichen Ausführungen eines Prozess modelliert, der beispielsweise zwischen zwei und fünf Ausführungen liegen kann, so ist das Ziel, den Prozess nur zweimal auszuführen, also zwei Instanzen zu erzeugen. Diese Direktive bezieht sich wiederum alleine auf die Navigation. Möchte der Nutzer zwei oder mehr Instanzen starten (maximal bis zu fünf), so kann er natürlich auch dies tun. Der Grund für die Entwicklung dieser Regeln liegt auch darin begründet, die Suchalgorithmen der Prozessnavigation zu beschleunigen, wenn keine Empfehlungen durch den Modellierer angegeben werden. In diesem Fall würden bei größeren Prozessmodellen mit mehr als zehn Prozessschritten die Antwortzeiten bei der Berechnung von Navigationsanfragen mehr als drei Sekunden betragen und zu unangenehmen Verzögerungen führen. Genau wie bei den prozessbezogenen Empfehlungen werden diese Regeln ebenfalls auf ein Kostenmodell abgebildet und zusammen mit den Soft Constraints für die heuristische Suche genutzt. Listing 8.4 zeigt einen Beispielaufruf des Prädikates next_state/3 in einem Zustand, in dem der Prozess Anamnese durchführen vom Assistenzarzt Jack gestartet wurde. In den Zeilen 4 und 5 sind die Kosten für die Handlungen finish und abort abgebildet. Die Kosten für die funktionale Perspektive sind im Listing fett markiert. Das Abbrechen des Prozesses verursacht höhere Kosten (Kosten = 2) als ein Beenden (Kosten = 1). Da der Prozess Anamnese nur einmal ausgeführt werden kann, ist in Listing 8.4 die Handlung start nicht aufgeführt. Es sei jedoch angemerkt, dass die Kosten bei einem erneuten Starten eines Prozesses, der bereits eine gestartete Instanz besitzt, 1 sind und unterhalb der Kosten für das Abbrechen liegen. 1?- process_planning::initial_state(set_up_surgery_plan, IS), 2process_planning::next_state(IS,NS,Costs). 3... 4finish process pid_0 with costs: 0(FU) + 0(BE) + -3(ORG) + 0(DATA) + 0(OP) = -3 5abort process pid_0 with costs: 2(FU) + 0(BE) + -3(ORG) + 0(DATA) + 0(OP) = -1 Listing 8.4: Aufruf der Zustandsübergangsrelation next_state/3 8.3.2 Verhaltensbezogene Perspektive Die Kalkulation der Kosten der verhaltensbezogenen Perspektive beruht auf den Abhängigkeiten zwischen den Prozessen. Oft benötigen Prozesse bestimmte andere Prozesse, speziell deren Zustand, um ausgeführt werden zu können. Die Grundidee ist nun, diese Prozesse, die von vielen anderen Prozessen benötigt werden, schneller abzuarbeiten. Die Abarbeitung eines Prozesses, der in vielen anderen Prozessen referenziert wird, hat geringere Kosten als ein Prozess, der kaum bis gar nicht referenziert wird. Somit entscheidet sich der heuristische Algorithmus bei der Auswahl zwischen mehreren möglichen Prozessen für denjenigen, der am häufigsten von anderen Prozessen benötigt wird. Als Beispiel dient hier das etwas modifizierte Modell aus Abbildung 6.4 (Kapitel 6), das in Abbildung 8.6 dargestellt ist: Um die Prozesse A, B und C wurde ein Rechteck modelliert, das eine verhaltensbezogene Aggregation der drei Prozesse ermöglicht, es modelliert also eine Abhängigkeit zwischen allen Prozessen im Rechteck und dem Prozess D, der erst ausgeführt werden 8.3. Prozessübergreifende Empfehlungen 97 Start Ende #= 1 B #= 1 A #= 1 D #= 1 C Abbildung 8.6: Modifiziertes Prozessmodell aus Abbildung 6.4 kann, wenn A, B und C abgearbeitet sind. Im initialen Zustand kann mit Prozess A und Prozess C begonnen werden. C ist mit B durch einen gestrichelten Pfeil verbunden, somit bestehen für Prozess C keine verhaltensbezogenen Abhängigkeiten, und er kann im Initialzustand direkt gestartet werden. Prozess B hingegen benötigt Prozess A und kann erst nach dessen Abarbeitung erfolgreich validiert werden. In Abbildung 8.7 ist in der linken Hälfte der Abhängigkeitsgraph der verhaltensbezogenen Perspektive dargestellt, der durch ESProNa berechnet wird. Die Prozesse A und C, die im Initialzustand ausgeführt werden können, sind durch zusätzliche, gestrichelte Kreise markiert. Durch die eingehenden Kanten im Prozess A ist zu erkennen, dass dieser von B und D benötigt wird. Des Weiteren hängt die Ausführung des Prozesses D von B und C ab. Die Kosten der verhaltensbezogenen Perspektive werden nun - basierend auf den eingehenden Kanten - berechnet. Prozess A beispielsweise hat zwei eingehende Kanten und ist derjenige Prozess im Modell, der am meisten referenziert wird. Somit sollte er vor Prozess C abgearbeitet werden, da dieser im Abhängigkeitsgraphen nur eine eingehende Kante aufweist. Listing 8.5 zeigt die ermittelten Kosten für die Ausführung von Prozess A (Zeilen 1, 2) und Prozess C (Zeilen 4, 5). ESProNa empfiehlt aus Sicht der verhaltensbezogenen Perspektive, den Prozess A vor Prozess C auszuführen. A B C D A B C D Abbildung 8.7: Abhängigkeitsgraph im Initialzustand (links) und nach erfolgreicher Ausführung von Prozess A (rechts) 12 ?- behavioral_heuristic::costs_do_process(pid_a(_), start, _, _, _, Costs). 2Costs = 0. 3 43 ?- behavioral_heuristic::costs_do_process(pid_c(_), start, _, _, _, Costs). 5Costs = 1. Listing 8.5: Ermittlung der Ausführungskosten der Prozesse A und B im Initialzustand In einem Zustand, in dem der Prozess A bereits ausgeführt wurde, verändern sich die Abhängigkeitsverhältnisse. Im rechten Teil der Abbildung 8.7 ist der neue Abhängigkeitsgraph abgebildet. Prozess A wird nicht mehr für die Auswertung hinzugezogen, da er 98 Modellierung von Empfehlungen bereits als erledigt markiert wurde. B und C sind diejenigen Prozesse, die jetzt ausführbar sind (markiert durch die gestrichelten Kreise). Für beide Prozesse sind die Kosten gleich 0, und somit werden beide Prozesse gleich gewichtet. Mit Blick auf das Prozessmodell in Abbildung 6.4 erkennt man, dass der Prozessmodellierer allerdings den Prozess B vor Prozess C gestellt hat. Somit zeigt sich eine gewisse Präferenz dafür, dass Prozess B vor Prozess C ausgeführt werden sollte. Diese Präferenz wird durch ESProNa erkannt und auch berechnet. Als Konsequenz daraus erhält der Prozess B geringere Kosten als Prozess C. 8.4 Korrigiertes Suchverhalten Am Ende des Kapitels 7 wurde bereits der durch die Tiefensuche berechnete Ablauf erläutert und zum einen das Problem erkannt, dass bestimmte unnötige Prozessschritte aufgeführt wurden (siehe Abbildung 7.3). Die Zustandsübergänge ¸und ¹waren dort überflüssig. Zum anderen besteht bei der Verwendung der Tiefenund Breitensuche das Problem der längeren Wartezeiten bei Navigationsanfragen mit größeren Prozessmodellen. Durch die prozessbezogenen sowie globalen Empfehlungen zusammen mit heuristischen Suchalgorithmen können aber die bestehenden Probleme gelöst werden. pid_0: [1-start-[org#Jack]-[]-[software#HIS]] pid_1: [] pid_2: [] ModelDoneCode: 0 pid_0: [1-start-[org#Jack]-[]-[software#HIS],1-finish-[org#Jack]-[clinic#Patientenakte]-[software#HIS]] pid_1: [] pid_2: [] ModelDoneCode: 0 Action: finish, Process/Instance: pid_0/1, Agent: [org#Jack], Data: [clinic#Patientenakte], Tool: [software#HIS], Costs: -2 pid_0: [1-start-[org#Jack]-[]-[software#HIS],1-finish-[org#Jack]-[clinic#Patientenakte]-[software#HIS]] pid_1: [1-start-[org#John]-[]-[software#HIS]] pid_2: [] ModelDoneCode: 0 Action: start, Process/Instance: pid_1/1, Agent: [org#John], Data: [], Tool: [software#HIS], Costs: 0 pid_0: [1-start-[org#Jack]-[]-[software#HIS],1-finish-[org#Jack]-[clinic#Patientenakte]-[software#HIS]] pid_1: [1-start-[org#John]-[]-[software#HIS],1-finish-[org#John]-[]-[software#HIS]] pid_2: [] ModelDoneCode: 0 Action: finish, Process/Instance: pid_1/1, Agent: [org#John], Data: [], Tool: [software#HIS], Costs: 0 1 2 3 -2 0 0 Abbildung 8.8: Heuristische Navigation unter Vermeidung unnötiger Ausführungen 8.5. Zusammenfassung 99 Abbildung 8.8 zeigt den Ablauf, den eine heuristische Suche, basierend auf dem Empfehlungskonzept dieses Kapitels, berechnet. Ausgangspunkt ist - wie auch in Kapitel 7 - der Zustand, in dem der Prozess Anamnese durchführen von Jack gestartet wurde. Dies entspricht auch der Empfehlung, die der Modellierer gegeben hat. In der durch die heuristische Suche berechneten Zustandsübergangsrelation ¶wird den Empfehlungen des Prozessmodellierers (Listing 8.2, Zeilen 30 bis 33) ebenfalls Folge geleistet, und der Prozess wird von Jack beendet. Als nächstes ·wird eine Prozessinstanz PID 1 durch John gestartet und auch wieder durch ihn beendet ·. Der aus dieser Handlung resultierende Endzustand (doppelt umrandet) ist zugleich auch der Zustand, der das Ziel der Navigation ist: Eine Person der chirurgischen Abteilung, die zugleich die modellierten Prozessregeln erfüllt (Vorgesetzter von John), kann jetzt den Prozess ausführen. Die in der Tiefensuche noch unnötigerweise berechneten Zustandsübergänge ¸und ¹sind in der heuristischen Suche nicht mehr enthalten. 8.5 Zusammenfassung In diesem Kapitel wurde gezeigt, wie prozessbezogene Empfehlungen durch den Modellierer mit in das Prozessmodell aufgenommen werden können. Zusammen mit den globalen Empfehlungen konnten beide auf ein Kostenmodell abgebildet werden, das als Input für heuristische Suchverfahren verwendet werden kann. Diese Suchalgorithmen beschleunigen Navigationsanfragen bei größeren Prozessmodellen, und es werden keine unnötigen Schritte mehr berechnet. 100 Modellierung von Empfehlungen Kapitel 9 Implementierung ESProNa wurde als Applikation in der logisch-objektorientierten Programmiersprache Logtalk verfasst. Logtalk ist eine Erweiterung der Programmiersprache Prolog und fügt dieser objektorientierte Konzepte hinzu. Logtalk ist mit verschiedenen Prolog-Interpretern kompatibel (siehe [42]) und kann als Applikation in diesen geladen werden. Durch die Unterstützung sowohl eines prototypbasierten als auch eines klassenbasierten Ansatzes deckt Logtalk alle Vererbungshierarchien ab [43]. Um Anfragen im objektorientierten Stil an OWL-Ontologien zu ermöglichen, wurde der Quellcode des Thea2-Projektes [44] in die ESProNa-Bibliothek mit aufgenommen und modifiziert. Somit werden aus den Ontologien Objekte erzeugt, die in Logtalk geladen und zur weiteren Verarbeitung abgefragt werden können. Da Thea2 die semweb-Bibliothek aus SWI-Prolog [14] [45] benötigt, kann ESProNa momentan nur in SWI-Prolog ausgeführt werden. YAP-Prolog [46] plant zwar die Portierung der semweb-Bibliothek, allerdings war dieses Vorhaben während der Implementierung ESProNas noch nicht abgeschlossen. Somit bleibt SWI-Prolog zum aktuellen Zeitpunkt der einzige Interpreter, in dem ESProNa geladen und ausgeführt werden kann. Zum Zeitpunkt der Veröffentlichung von ESProNa wurde SWI-Prolog in Version 5.11.25 zusammen mit Logtalk in Version 2.43.0 benutzt. 9.1 Strukturelle Übersicht Der Quellcode, der die Implementierung beinhaltet, gliedert sich in die in Abbildung 9.1 gezeigte Baumstruktur. Die blau gekennzeichneten Ordner markieren die Top-levelEbenen. contributions beinhaltet externe Projekte wie etwa das für ESProNa angepasste Thea2 oder den Programmcode zur Messung der Performanz verschiedener Suchalgorithmen. Der Ordner debug enthält den Programmcode zur detaillierten Ausgabe der Zustandsübergangsrelationen auf die Konsole. Im Ordner doc wird die automatisch generierte Dokumentation abgelegt und ist dort in Form von .htmlund .pdf-Dokumenten verfügbar. Der Quellcode des ESProNa-Kerns befindet sich in library. Im Ordner planning befinden sich die Definitionen für den Prozesszustand, die Schnittstellen zu den Suchalgorithmen (diese befinden sich im Unterordner solvers) sowie der Programmcode zur Visualisierung des berechneten Zustandsraumes (Ordner visualize). Im Ordner process liegt der Programmcode der Prozessobjekte sowie ein Unterorder popm mit den Definitionen zu den einzelnen POPM-Perspektiven. Diese werden in das Prozessobjekt importiert. In state sind die Objekte des Zustandsraumes gespeichert. utilities beinhaltet ein Objekt, das verschiedene Prädikate zur Visualisierung zur Verfügung stellt. 101 102 Implementierung contributions debug performance thea2 doc library process_models planning process solvers visualize popm behavioral_perspective data_perspective functional_perspective operational_perspective organizational_perspective state utilities unit_tests Abbildung 9.1: Ordnerstrukturen in ESProNa Der Ordner process_models enthält weitere Unterordner mit Prozessmodellen. In jedem Ordner befindet sich unter anderem das Prozessmodell mit den Definitionen und Constraints der einzelnen Prozesse. Weiterhin sind hier die Ontologien der organisatorischen, datenbezogenen und operationalen Perspektive abgelegt. In einer weiteren loader.lgt-Datei werden diese Ontologien beim Laden eines Prozessmodells übersetzt, sodass sie in den Prozessconstraints benutzt werden können. Im Unterordner der Prozessmodelle ist außerdem das grafische Modell als PDF gespeichert. Im Ordner unit_tests befinden sich Testobjekte, mit denen die Konsistenz von ESProNa nach diversen Änderungen am Code überprüft werden kann. 9.2. Zusammenhänge der einzelnen Komponenten 103 9.2 Zusammenhänge der einzelnen Komponenten Abbildung 9.2 zeigt eine Sichtweise auf das ESProNa-Projekt, in der die Zusammenhänge zwischen den einzelnen Objekten dargestellt sind. Alle POPM-Perspektiven werden, wie bereits in Kapitel 6.2 beschrieben, in das Prozessobjekt importiert, sodass neue Konzeptionen einfach implementiert werden können. Zwischen dem Prozessobjekt in Abbildung 9.2 und dem process_model-Objekt, das die Definitionen aller Prozesse des Prozessmodells beinhaltet, besteht eine 1:N-Beziehung. Durch eine prototyp-basierte Instanziierung der Prozessobjekte im Prozessmodell können ohne explizite Instanziierungsanweisungen Prozesse mit entsprechenden Prozessconstraints spezifiziert werden (siehe Listing 4.1). Da ein Prozessmodell in der Regel mehrere Prozessdefinitionen (N) enthält, ist ein prototyp-basierter Ansatz hier von Vorteil. Das Laden der Prozessmodelle (Aufruf siehe Listing 9.1) erfolgt über die loader-Datei, die sich in jedem Ordner eines Prozessmodells befindet. Listing 9.2 zeigt den detaillierten Aufbau dieser Datei, die das Laden des klinischen Prozessmodells im Ordner set_up_surgery_plan übernimmt. Die Ontologien der einzelnen Perspektiven werden in den Zeilen 1 bis 3 eingelesen. Danach werden sie in Klassen (Zeile 4) und Instanzen (Zeile 5) übersetzt. Vor dem abschließenden Laden des Prozessmodells in Zeile 9 werden noch temporäre Daten zurückgesetzt (Zeile 6). 1?- logtalk_load(set_up_surgery_plan(loader)). Listing 9.1: Laden eines klinischen Prozessmodells 1owl2_to_logtalk:load_axioms(’organization.owl’), 2owl2_to_logtalk:load_axioms(’tools.owl’), 3owl2_to_logtalk:load_axioms(’data.owl’), 4owl2_to_logtalk:save_axioms_ontology(’popm_objects.lgt’, owlpl, [no_base(_)]), 5owl2_to_logtalk:save_axioms_individuals(’popm_individuals.lgt’, owlpl, [no_base(_)]), 6owl2_to_logtalk:cleanup, 7logtalk_load(popm_objects, [unknown(silent)]), 8logtalk_load(popm_individuals, [unknown(silent)]), 9process_model_loader::load(process_model). Listing 9.2: Laden des klinischen Prozessmodells im Detail Nun können Anfragen an das Prozessmodell nach dessen Laden erfolgen. Für den Prozessausführenden ist zum Beispiel interessant, welche Prozesse ausführbar sind (siehe Listing 9.3). 1?- extends_object(Process, process), 2process_planning::initial_state(set_up_surgery_plan, IS), 3Process::validate_action(start, IS,Instance-Agents-Data-Tools). Listing 9.3: Welche Prozesse sind im Initialzustand IS ausführbar? In der unteren Hälfte der Architektur (Abbildung 9.2) sind die Komponenten der Prozessnavigation abgebildet. process_planning instanziiert den heuristischen Zustandsraum, der eine Spezialisierung des Zustandsraumes state_space darstellt. Im Objekt process_planning sind somit neben den Zustandsübergangsrelationen next_state/2 104 Implementierung operational_constraint organizational_constraint Operational Perspective Data Perspective data_constraint Organizational Perspective POPM Perspectives imports imports imports behavioral_constraint functional_constraint Behavioral Perspective Functional Perspective imports imports process_planning specializes instantiates esprona_blind_search esprona_heuristic_search has specializes esprona_depth_first esprona_breadth_first esprona_hill_climbing instantiates instantiates references references specializes specializes contains definitions 1 N process library/process library/process/popm model_state library/state heuristic_state_space library/planning/solvers state_space library/planning/solvers library/planning esprona_search_strategy library/planning/solvers library/planning/solvers library/planning/solvers library/planning/solvers library/planning/solvers library/planning/solvers process_model process_models/.../ functional_heuristic behavioral_heuristic organizational_heuristic data_heuristic operational_heuristic uses :- object(pid_0(_), extends(process)). :- dynamic. process_title('Anamnese'). ... :- end_object. :- object(pid_1(_), extends(process)). ... Heuristics library/process/popm process_state library/state 1 N contains references 1 1 esprona_best_first library/planning/solvers instantiates instantiates Abbildung 9.2: Architekturübersicht ESProNa 9.3. Zusammenfassung 105 und next_state/3 noch die Prädikate navigate/4 bzw. navigate/5 enthalten sowie heuristic/2 zur Abschätzung der Kosten vom aktuellen Zustand zum Zielzustand. Da alle notwendigen Constraints immer die Kosten 0 haben, können bei einer Ausführung, die keine Empfehlungen beachtet, die Gesamtkosten mit 0 abgeschätzt werden. Beide Zustandsräume referenzieren das sogenannte model_state-Objekt, das den Zustand des geladenen Prozessmodells beschreibt. Es besteht aus einer Liste von einzelnen Prozesszuständen (process_state) sowie dem Flag ModelDoneCode. Diese Variable kann die Werte 0 (Prozesse noch nicht abgearbeitet) oder 1 (Prozesse sind abgearbeitet) annehmen. Die Objekte der Prozesszustände speichern im Einzelnen für jeden Prozess die Prozess-ID sowie die Ausführungshistorie des Prozesses. Der Zustandsraum state_space wird von der esprona_search_strategy spezialisiert. Diese Suchstrategie ist wiederum eine Abstrahierung für die sogenannten blinden Suchalgorithmen wie Tiefenund Breitensuche (esprona_depth_first,esprona_breadth_first), aber auch für die heuristische Suche (esprona_hill_climbing). 9.3 Zusammenfassung In diesem Kapitel wurde der strukturelle Aufbau ESProNas gezeigt. Die Beziehungen zwischen den einzelnen Objekten wurden ebenfalls behandelt. Anhand der Architekturübersicht in Abbildung 9.2 wurde nochmals aufgezeigt, wie die einzelnen POPMPerspektiven in das Prozessobjekt importiert werden. Der Zustand eines Prozessmodells und seine Bedeutung für die Navigation wurde ebenfalls nochmals grafisch verdeutlicht. 112 Related Work Activities that have type place order,accept order,reject order and ship order must not be performed in parallel.1 Das Beispiel besagt, dass die Prozessschritte Bestellung durchführen (place order), Bestellung akzeptieren (accept order), Bestellung zurückweisen (reject order) und Bestellung verschicken (ship order) nicht parallel ausgeführt werden dürfen. Wie an diesem Beispiel zu erkennen ist, werden Schlüsselwörter unterschiedlich gekennzeichnet. Durch diese spezielle Kennzeichnung ist es möglich, ausgewiesenen Textpassagen eine formale Bedeutung zuzuordnen, die dann durch EM-BrA2CE ausgewertet werden kann. Im Einzelnen sind dies: •Nominale Konzepte werden grün markiert und unterstrichen. •Verbale Konzepte werden blau markiert. •Die Markierung von linguistischen Teilen, die eine zusammengesetzte Aussage bilden, ist rot. Ausdrucksstärke, das heißt, die Umsetzung aller erwähnten POPM-Perspektiven, ist in EM-BrA2CE nur zum Teil vorhanden. Die Dokumentation [61] erklärt ab Kapitel 5.4, wie verhaltensbezogene, datenbezogene und organisatorische Perspektiven umgesetzt werden können. Eine funktionale und eine operationale Perspektive sind im Handbuch nicht explizit ausgewiesen, können aber sicherlich in EM-BrA2CE implementiert werden. In 5.4.15 der Dokumentation wird ein Beispiel für ein Autorisierungsconstraint angeführt. Durch Regeln, zusammen mit dem verbalen Konzept der has function, können Agenten bestimmte Rollen zugewiesen werden. Somit ist es in EM-BrA2CE möglich, Unternehmensstrukturen abzubilden und in den Prozessbeschreibungen zu verwenden. Im Gegensatz zu ESProNa werden diese Konzepte nicht in Ontologien, sondern ebenfalls in SBVR modelliert. Flexibilität kann in EM-BrA2CE beschrieben und umgesetzt werden. In manchen Passagen tauchen in den angegebenen Beispielregeln Textelemente wie It is necessary that (siehe 5.4.15) oder It is not advisable that (siehe 5.4.16) auf. Hierdurch erreicht man in EM-BrA2CE eine modale Kategorisierung der Regeln in notwendig und empfehlenswert, die für eine Einflussnahme bei einer Navigation benutzt werden könnten. ESProNa verwendet im Gegensatz dazu eine multimodale Gewichtung der Constraints, wodurch die Empfehlungen ein zusätzliches Ranking erhalten. Eine Prozessnavigation bei der Ausführung von Prozessbeschreibungen ist in EM-BrA2CE nicht gegeben. 10.4 Zusammenfassung In diesem Kapitel wurde ESProNa mit anderen Modellierungssprachen und Ausführungsumgebungen verglichen. Der erste Abschnitt des Kapitels zeigte die Konzepte auf, mit denen PMS und WMS aus Industrie und Forschung verglichen wurden. In Tabelle 10.1 sind nochmals alle Modellierungssprachen aufgelistet. Weiterhin wird dort gezeigt, wie gut diese Sprachen die Konzepte aus der Tabelle umsetzen können. Folgende Abkürzungen dafür verwendet: 1Unterschiedliche farbliche Kennzeichnungen sowie Textstile tragen zur Kategorisierung der verschiedenen Schlüsselwörter bei. 10.4. Zusammenfassung 113 •Ausdrucksstärke einer PMS mit Bezug auf die Umsetzung aller POPM-Perspektiven (AS) •Erweiterbarkeit einer PMS durch das Hinzufügen neuer Modellierungskonstrukte und Perspektiven (EW) •Prozessnavigation zur Unterstützung des Nutzers bei der Prozessausführung (PN) •Modellierung von subjektiven Empfehlungen des Prozessmodellierers zur Beeinflussung des Prozessausführenden (EM) Ein +bei der entsprechenden PMS und Konzeption bedeutet, dass es in der entsprechenden Sprache umgesetzt ist. Ein -zeigt, dass es nicht vorhanden ist. Modellierungssprache AS EW PN EM BPMN - - - - YAWL - - - - DECLARE - + - - EM-BrA2CE + + - + Tabelle 10.1: Bewertung der verglichenen PMS 114 Related Work Kapitel 11 Resümee und Ausblick Die Konzeption und Implementierung ESProNas bietet die Möglichkeit, die im ersten Kapitel angesprochenen Probleme und Anforderungen an eine PMS zu lösen bzw. ihnen gerecht zu werden. Durch den Konzeptwechsel von der imperativen hin zur deklarativen Problemformulierung wird ein sehr kompakter und effizienter Modellierungsstil ermöglicht. Hier werden nun die in Kapitel 1 angesprochenen Probleme nochmals aufgegriffen und die Konzepte, die zu ihrer Lösung beigetragen haben, kurz rekapituliert: •Das Problem der Komplexität bei agilen Prozessmodellen (Kapitel 1.2.1) wurde durch einen Konzeptwechsel von „Was nicht explizit erlaubt ist, ist verboten“ hin zu „Was nicht verboten ist, ist erlaubt“ erreicht. Die Ausführung eines Prozesses wird somit nur noch dann eingeschränkt, wenn die Validierung einer der Prozessperspektiven, genauer gesagt, mindestens einer der Prozessconstraints fehlschlägt. •Lösungspfade müssen nicht mehr explizit modelliert werden. Einschränkungen auf Prozessen, realisiert über die sogenannten Prozessconstraints, sind nun direkt in diesen selbst und nicht mehr in Abläufen codiert. Der Prozessmodellierer kann sich auf die Problemstellung konzentrieren (das WAS) und muss sich nicht mehr explizit um die Lösung der Probleme bemühen (das WIE). Dies erleichtert ein Verständnis der Prozessmodelle durch dritte Personen, die die Geschäftsprozesse später nachvollziehen möchten. •Pfadkomplexität (siehe Abbildung 1.2) konnte durch das Einführen neuer und semantisch angereicherter Modellierungssymbole gelöst werden (siehe Abbildung 1.3). Der Prozessmodellierer erhält somit die Möglichkeit, die PMS individuell den Gegebenheiten des Unternehmens anpassen zu können. Die neu zu definierenden Modellierungskonstrukte müssen lediglich auf Prozessconstraints abgebildet werden, um deren Bedeutung exakt und formal festhalten zu können (siehe hierzu Kapitel 6). •Das in Kapitel 1.2.2 angesprochenen Problem der schwachen Ausdrucksfähigkeit aktueller PMS und die daraus resultierenden Probleme, dass gewisse Konzepte aus den realen Geschäftsprozessen nicht ins Modell mit aufgenommen werden können, wurde durch die Verwendung von Ontologien gelöst. Hierdurch konnten die Perspektiven soweit flexibel gehalten werden, dass neue Konzepte, wie etwa die Vertretungsrolle (siehe Kapitel 1.2.2), durch Anpassung der Ontologie nachimplementiert werden können. Das angesprochene Problem, dass gewisse Konzepte nicht 115 116 Resümee und Ausblick umsetzbar waren, sowie die Konsequenz ungenauer Prozessmodelle konnte somit behoben werden. •Das Sekundärproblem der zu vielen Entscheidungsmöglichkeiten bei zu großer Flexibilität konnte durch das Navigationskonzept kompensiert werden. Hierdurch erhält der Prozessausführende die Gewissheit, bei der Ausführung in allen Situationen stets den Überblick zu behalten. Ausnahmesituationen können in die Navigation zum Ziel mit einbezogen werden, sodass sie für den Ausführenden keine Schwierigkeiten mehr darstellen. •Durch das Konzept der Empfehlungen ist dem Modellierer die Möglichkeit gegeben, positive und negative Empfehlungen mit in das Modell aufzunehmen, um die Entscheidungen des Prozessausführenden zu beeinflussen. Dieser hat bei deren Befolgung die Gewissheit, sich stets konform den Richtlinien des Unternehmens verhalten zu können. Trotzdem kann er aber auch von diesen Empfehlungen abweichen, um in bestimmten Situationen, die während der Erstellung des Modells nicht vorhersehbar waren, entsprechend reagieren zu können. Durch die vorliegende Forschungsarbeit ist der Grundstein für eine flexible und ausdrucksstarke PMS sowie ein unterstützendes WMS gelegt. Durch die Integration in die Modellierungsumgebung iPM2und in die Ausführungsumgebung ProcessNavigator erhalten Modellierer und Prozessausführender die Möglichkeit, ESProNa anhand von alltäglichen Geschäftsprozessen zu evaluieren. Offene Forschungsarbeiten Zukünftige Forschungsarbeiten bzw. offene Fragen, die sich aus dieser Dissertation ergeben haben, gibt es noch bei folgenden Punkten: •Integration der in den Perspektiven verwendeten Ontologien in das Betriebssystem (datenbezogene und operationale Perspektive). Nur durch die Zusammenarbeit zwischen Betriebssystem und ProcessNavigator auf Basis einer Ontologie können die benötigten Daten und Werkzeuge semantisch umfassend beschrieben und verwaltet werden. •Die Applikationen für die Organisation des Personals eines Unternehmens müssen einen Export in OWL2-Ontologien unterstützen, um sicherzustellen, dass die Beziehungen zwischen Personen und Rollen in ESProNa ausgewertet werden können. Weiterhin müssen diese Konzepte auch in iPM2Verwendung finden um eine semantisch korrekte Anbindung zwischen beiden Systemen implementieren zu können. •Durch die Möglichkeit der Erweiterbarkeit von ESProNa können neue Perspektiven in die Prozessmodellierungssprache sehr einfach integriert werden. Sie können die Spezifikation eines Prozesses so erweitern, dass zukünftige Unternehmenskonzepte in ESProNa als Constraints abgebildet werden können. •An der Konzeption neuer Modellierungssymbole zur Vereinfachung der Prozessmodelle kann noch zusätzliche Forschungsarbeit geleistet werden. Diese Symbole können nachfolgend in iPM2implementiert und in Prozessconstraints übersetzt werden. Hierdurch erreicht man eine Vereinfachung der erstellten Prozessmodelle, was 117 zu einem vereinfachten Verständnis und einer verbesserten Übersichtlichkeit der Modelle beiträgt. Obige Liste ist sicherlich nicht vollständig, und es werden im Laufe der Zeit und Forschung sicherlich noch mehr offene Punkte hinzukommen. Des Weiteren können sicherlich noch mehr konzeptionelle Arbeiten entstehen, beispielsweise im Bereich der POPMPerspektiven. Hier können zusätzliche Sichtweisen auf den Prozess entwickelt werden, um ihn an die sich veränderten Unternehmensstrukturen und Geschäftsprozesse anzugleichen. ESProNa stellt hierfür die Strukturen und die generelle Möglichkeit der Erweiterbarkeit zur Verfügung, wie bereits in Kapitel 6 gezeigt wurde. Abschließend bleibt zu sagen, dass ESProNa durch seine Erweiterbarkeit, seine Ausdrucksstärke, sein Navigationskonzept und die Möglichkeit zur Modellierung von Empfehlungen viele Features mitbringt, sodass die Anforderungen an heutige Geschäftsprozesse effizient umgesetzt werden können. 118 Resümee und Ausblick Anhang A Installation 1___________ ___________________ _______ 2\_ _____// _____/\______ \_______ ____ \ \ _____ 3| __)_ \_____ \ | ___/\_ __ \/ _ \ / | \\__ \ 4| \/ \ | | | | \( <_> ) | \/ __ \_ 5/_______ /_______ / |____| |__| \____/\____|__ (____ / 6\/ \/ \/ \/ 7+++ Modeling, Execution and Navigation of Declarative Business Processes +++ 8 9+++ Loading (modified) OWL2 parser Thea2... 10 +++ Loading state-space definitions... 11 +++ Loading debugging tools... 12 +++ Loading performance measurement tools... 13 +++ Loading heuristics and solvers... 14 +++ Loading helper predicates / utilities... 15 +++ Loading POPM Functional Perspective definitions... 16 +++ Loading POPM Behavioral Perspective definitions... 17 +++ Loading POPM Organizational Perspective definitions... 18 +++ Loading POPM Data Perspective definitions... 19 +++ Loading POPM Operational Perspective definitions... 20 +++ Loading process and constraint predicates definitions... 21 +++ Loading planning components... 22 +++ Loading visualization (dot-export)... 23 +++ Loading the process model instantiation / destruction engine... 24 25 % (0 warnings) 26 1 ?- Listing A.1: Terminalausgabe nach erfolgreichem Laden von ESProNa Für die Ausführung von ESProNa sind SWI-Prolog und Logtalk zwingende Voraussetzungen. Beide sind kostenlos erhältlich und können unter [45] bzw. [42] geladen werden. Wie diese Programme installiert werden, findet sich in der jeweiligen Dokumentation. Bei der Erstellung vorliegender Dissertation wurden die jeweils aktuellen Versionen SWI-Prolog 5.11.25 und Logtalk 2.43.0 verwendet. Des Weiteren muss vor der Nutzung noch eine Umgebungsvariable gesetzt werden, damit die erzeugte Dokumentation im richtigen Ordner abgelegt wird. Dies geschieht unter Linux, Unix und Mac durch den Befehl export ESProNa=/Folder/to/ESProNa, der noch dem Pfad der installierten ESProNa-Umgebung angepasst werden muss. Den Befehl kopiert man am besten in die lokale .profile-Datei (Mac/Unix) bzw. .bash_profile-Datei (Linux). Unter Windows muss die Umgebungsvariable ebenfalls in den Computereinstellungen (System Properties) als benutzerdefinierte Variable hinzugefügt werden. Variablenname 119 120 Installation ist ESProNa, und der Wert ist der Pfad zum geladenen Quellcode. Nach dem Entpacken der ESProNa-Quelldateien muss eine Shell (Unix Terminal bzw. MS-DOS Eingabeaufforderung) geöffnet und in das Verzeichnis mit den geladenen Dateien gewechselt werden. Dort wird mit Hilfe des Befehls swilgt -g ”{loader}” eine SWI-Session geöffnet, wodurch ESProNa automatisch geladen wird. Nach erfolgreichem Laden und Übersetzen aller Quelldateien sollte die Ausgabe im Terminal dem Listing A.1 entsprechen. 1?- logtalk_load(set_up_surgery_plan(loader)). 2 3--------------------------------------- 4Loading process model: Surgery plan confirmation 5--------------------------------------- 6+++ Transforming ontologies used within process model... 7+++ Loading transformed ontologies... 8+++ Loading process model... 9 10 % (0 warnings) 11 true. Listing A.2: Terminalausgabe nach erfolgreichem Laden des klinischen Prozessmodells Das Laden eines bestimmten Prozessmodells mit allen referenzierten Ontologien geschieht durch den Befehl logtalk_load(set_up_surgery_plan(loader))., der in die gestartete ESProNa-Session kopiert und bestätigt wird. Hierdurch wird die loader.lgtDatei im Ordner des Prozessmodells geladen. Die Ausgabe hierzu befindet sich in Listing A.2. In Zeile 4 ist zu erkennen, welches Prozessmodell geladen wurde. Es entspricht im vorliegenden Falle dem in dieser Dissertation verwendeten klinischen Ablaufmodell. In den Zeilen 6 und 7 werden die verwendeten Ontologien übersetzt und geladen. Abschließend erfolgt das Kompilieren des eigentlichen Prozessmodells mit den darin enthaltenen Constraints (Zeile 8). Wie in Kapitel 9 angemerkt, befinden sich die Prozessmodelle im Unterordner process_models. Jedes Prozessmodell mit allen dazugehörigen Dateien wie etwa Ontologien, PDF des grafischen Modells, Ausgabe der visualisierten Zustandsräume etc. ist nochmals in einem eigenen Ordner gespeichert. Des Weiteren enthält dieser Ordner auch die oben verwendete loader.lgt-Datei. Schließlich erfolgt durch das Abarbeiten dieser Datei das Laden der Prozessconstraints, die im Prozessmodell process_model.lgt codiert sind. Beispielanfragen, wie etwa die Visualisierung des Zustandsraumes oder die Navigation, sind ebenfalls im jeweiligen Ordner eines Prozessmodells enthalten und befinden sich in der Datei EXAMPLE_QUERIES.lgt. Listing A.3 zeigt eine Anfrage aus dieser Datei, mit der eine Visualisierung des partiellen Zustandsraumes erreicht werden kann. 1?- performance::init, 2process_planning::initial_state(set_up_surgery_plan, IS), 3process_planning::goal_state(set_up_surgery_plan, GS), 4graphviz::start_export(’./process_models/set_up_surgery_plan/partial_state_space.dot’), 5esprona_hill_climbing(6)::solve(set_up_surgery_plan, process_planning, IS,GS,Path, 6Costs), 7graphviz::finish_export(GS,Path, ’"#0066FF"’, ’"#0066FF"’), 8performance::report. Listing A.3: Visualisierung des partiellen Zustandsraumes 121 Der durch die heuristische Suche generierte Zustandsraum ist im dot-Dateiformat gespeichert. Die erzeugte Datei des partiellen Zustandsraumes partial_state_space.dot wird im Ordner set_up_surgery_plan des Prozessmodells abgelegt. Zur Anzeige bzw. Konvertierung dieser Datei in das PDF-Format muss die Software Graphviz installiert sein. Mehr Informationen hierzu finden sich unter [63]. Mit Ausführung des Befehls dot -Tpdf partial_state_space.dot > partial_state_space.pdf kann in einer Unix-Shell die erzeugte dot-Datei in ein vektorbasiertes und allgemein lesbares PDF umgewandelt werden. 128 Quellcode des klinischen Prozessmodells Anhang C Sprachdefinition C.1 Funktionale Constraints Eine Übersicht an funktionalen Constraints, die in den Prozessobjekten angegeben werden können, zeigt Listing C.1. process_title/1 und process_description/1 erwarten als Input eine Zeichenkette (String). one in der mode-Direktive eines Constraints besagt, dass es bei dessen Evaluierung genau ein Ergebnis zurückliefert. Das Constraint process_actions/1 erwartet als Eingabe eine Liste mit spezifizierten Handlungen: +list(actions). Auch dieses Constraint darf im Prozess nur einmal vorkommen, genau wie process_domain/2. Letzteres erwartet als ersten Parameter eine Liste mit abhängigen Prozessen. Wird zum Beispiel in einem Prozess Bspezifiziert, dass dieser genauso oft ausgeführt werden muss wie Prozess A, dann ist diese Abhängigkeit hier anzugeben, da sie bei der Unifikation der Domänenvariablen benötigt wird. Als Beispiel dient wieder der Prozess Operationsplan genehmigen (PID 2) aus dem klinischen Beispielprozessmodell von Abbildung 4.1. Dort wurde modelliert, dass der Prozess genauso oft ausgeführt werden soll wie der Prozess Operationsplan vorbereiten (PID 1). Demnach müssen also genauso viele Operationspläne genehmigt werden wie erstellt wurden. Listing C.2 gibt die Spezifikation des Constraint aus dem Prozess PID 2 wieder. 1:- public(process_title/1). 2:- mode(process_title(+var(string)), one). 3 4:- public(process_description/1). 5:- mode(process_description(+var(string)), one). 6 7:- public(process_actions/1). 8:- mode(process_actions(+list(actions)), one). 9 10 :- public(process_domain/2). 11 :- mode(process_domain(+list(dependencies), +term(clpfd_domains)), one). 12 13 :- public(functional_constraint/4). 14 :- mode(functional_constraint(+list(actions), 15 +list(state), 16 -instance_identifier, 17 +callable), 18 zero_or_more). Listing C.1: Constraint-Signaturen der funktionalen Perspektive 129 130 Sprachdefinition 1process_domain([’set_up_surgery_plan#pid_1’(PID_1)], (PID_2 #= PID_1)) :- 2parameter(1, PID_2). Listing C.2: Spezifikation abhängiger Wertebereiche zweier Prozesse Der erste Parameter des process_domain/2-Constraints wird als Liste mit Einträgen der Form Prozess-ID(Prozess-Variable) gefüllt. Die ermittelte Prozessvariable wird im zweiten Parameter des Constraints für die Spezifikation des clpfd-Wertebereichs benötigt. Durch (PID_2 #= PID_1) wird ausgedrückt, dass der Prozess PID 2 genauso oft ausgeführt werden muss (#=) wie der Prozess PID 1. Mehrere Ausdrücke können logisch miteinander verknüpft werden. Der Wertebereich eines Prozesses mit festen Grenzen (2..4) kann beispielsweise wie in Listing C.3 definiert werden. 1process_domain([], (PID_2 #>= 2, PID_2 #=< 4)) :- 2parameter(1, PID_2). Listing C.3: Spezifikation des Wertebereichs eines Prozesses Nachdem im zweiten Parameter des Prozesses keine Referenz auf einen anderen Prozess erfolgt, kann die Liste des ersten Parameters leer bleiben. Die Tabellen C.1 und C.2 geben eine Übersicht der möglichen Ausdrücke und Operatoren der clpfd-Bibliothek an, die bei der Deklaration der Prozess-Domains benutzt werden können. Ausdruck Grammatik Bedeutung int int Ganzzahl var var Prolog-Variable expr expr ::= var | int expr ist Variable oder Ganzzahl Tabelle C.1: Ausdrücke der clpfd-Bibliothek C.2 Verhaltensbezogene Constraints Verhaltensbezogene Constraints beziehen sich auf den Zustand anderer Prozesse. In Listing C.4 ist die Signatur der verhaltensbezogenen Perspektive spezifiziert. Der erste Parameter ist eine Liste mit Handlungen, für die das Constraint gilt. Der zweite Parameter ist der aktuelle Zustand des ausgeführten Prozessmodells. Basierend auf diesem Zustand werden die im vierten Parameter angegebenen Prädikate ausgewertet. Es ist möglich, im dritten Parameter eine bestimmt Instanz des Prozesses anzugeben, sodass bei der Evaluierung nur diese in Betracht gezogen wird. Wird keine Instanz gebunden und der dritte Parameter durch das Wildcard-Symbol ersetzt (_), so gilt das Constraint für alle Instanzen des Prozesses. Am Prefix +der jeweiligen Parameter erkennt man, dass sie alle immer gebunden sein müssen. Im vierten Parameter des Constraints können nun diverse Prädikate referenziert werden, die durch ESProNa zur Verfügung gestellt werden. Im Prozess Operationsplan vorbereiten (Listing 4.4, Zeile 3) wurde das Prädikat exists_instance/3 bereits aufgeführt. Es wertet bei übergebenem Zustand (erster Parameter) aus, ob eine bestimmte Handlung (zweiter Parameter) auf eine Prozessinstanz (dritter Parameter) bereits ausgeführt wurde. C.3. Organisatorische Constraints 131 Logische Operatoren Assoziativität Notation Bedeutung expr, expr binär infix UND-Verknüpfung expr; expr binär infix ODER-Verknüpfung Arith. Operatoren Assoziativität Notation Bedeutung -expr unär prefix Negation expr + expr binär infix Addition expr-expr binär infix Subtraktion expr *expr binär infix Multiplikation expr / expr binär infix Ganzzahldivision expr ^ expr binär infix Exponentialoperator min(expr, expr) binär prefix Minimum zweier Ausdrücke max(expr, expr) binär prefix Maximum zweier Ausdrücke expr mod expr binär infix Modulo-Operator abs(expr) unär prefix Betrags-Operator Vergleichsoperatoren Assoziativität Notation Bedeutung expr #>= expr binär infix größer gleich expr #=< expr binär infix kleiner gleich expr #= expr binär infix gleich expr #\= expr binär infix ungleich expr #> expr binär infix echt größer expr #< expr binär infix echt kleiner Tabelle C.2: Operatoren der clpfd-Bibliothek 1:- public(behavioral_constraint/4). 2:- mode(behavioral_constraint(+list(actions), 3+list(state), 4+instance_identifier, 5+callable), 6zero_or_more). Listing C.4: Constraint-Signatur der verhaltensbezogenen Perspektive Ein weiteres Prädikat ist in_domain/1. Es wird mit Bezug auf einen bestimmten Prozess aufgerufen, um zu überprüfen, ob er abgearbeitet wurde. Einen Beispielaufruf zeigt das Constraint in Listing C.5, wo überprüft wird, ob der Zähler des Prozesses pid_0 im aktuellen Zustand (State) im angegebenen Wertebereich liegt. Im Prozessmodell in Listing 4.1 wurde im Prozess Anamnese spezifiziert, dass dieser genau einmal ausgeführt werden muss. Der Wertebereich ist entsprechend 1..1. Ist der Zähler des im Constraint referenzierten Prozesses pid_0 innerhalb des Wertebereichs 1..1, so validiert das aufgerufene Prädikat in_domain/1 erfolgreich. C.3 Organisatorische Constraints Der Aufbau eines organisatorischen Constraints (siehe Listing C.6) ist ähnlich dem der verhaltensbezogenen Perspektive: Die Signatur der ersten drei Parameter ist identisch, das heißt, eine Liste mit bestimmten Handlungen, der aktuelle Zustand und eine Instanz 132 Sprachdefinition 1behavioral_constraint([start], State, _, 2( 3’set_up_surgery_plan_extended#pid_0’(_)::in_domain(State) 4)). Listing C.5: Verhaltensbezogenes Constraint in_domain/1 werden übergeben. Der vierte Parameter, eine Liste mit Agentenvariablen, kann frei oder gebunden sein. Im ersteren Fall wird bei Auswertung des fünften Parameters derjenige Agent ermittelt, der den Prozess ausführen kann. Im Falle des n-Augenprinzips werden mehrere Agenten eruiert und an die verschiedenen Variablen in der Liste des fünften Parameters gebunden. Nach der Auswertung des Constraints mit gleichzeitiger Ermittlung der Agenten werden diese an das Prädikat validate_action/3 weitergereicht. Im zweiten Fall, wenn also an die Variable Agent ein bestimmter Wert gebunden ist, wird überprüft, ob das angegebene Constraint erfolgreich validiert. Man kann also das Constraint auf zweifache Art und Weise benutzen: zum einen zur Ermittlung, zum anderen aber auch zur Verifikation von Agenten. 1:- public(organizational_constraint/5). 2:- mode(organizational_constraint(+list(actions), 3+list(state), 4+instance_identifier, 5?list(agents), 6+callable), 7zero_or_more). Listing C.6: Constraint-Signatur der organisatorischen Perspektive Im Prozessmodell in Listing 4.1 sind in Zeile 36 und 37 zwei Anfragen an die Ontologie gerichtet, um diejenigen Agenten zu ermitteln, die den Prozess ausführen können. Das organisatorische Constraint des Prozessmodells validiert dabei zweimal, das heißt, es wird zuerst Jack an die Variable Agent gebunden und bei der zweiten Auswertung John. Listing C.7 zeigt eine Anfrage mit den beiden von ESProNa ermittelten Ergebnissen. In der ersten Zeile wird der Ausgangszustand für die Anfrage erzeugt, der für den Aufruf und die Auswertung des Prädikates validate_action/3 in Zeile 2 benötigt wird. Nach erfolgreicher Validierung werden zwei Ergebnisse zurückgeliefert, die in Zeile 4 und 5 aufgelistet sind. 1?- process_planning::initial_state(set_up_surgery_plan, State), 2pid_0(_)::validate_action(start, State, _-Agent__). 3 4Agent = [’org#Jack’] 5Agent = [’org#John’] Listing C.7: Ermittlung der Agenten Listing C.8 zeigt den Aufruf der Constraintvalidierung mit einem bestimmten Agenten. An die Variable Agent wurde die Identifikation der Person Jack gebunden. Somit ist es möglich, für eine bestimmte Person zu überprüfen, ob sie den Prozess ausführen darf. Das Ergebnis der Auswertung des Prädikates wird in Zeile 4 zurückgegeben: true. Dies bedeutet, dass Jack den Prozess pid_0 (Anamnese) ausführen darf. C.4. Datenbezogene Constraints 133 1?- process_planning::initial_state(set_up_surgery_plan, State), 2pid_0(_)::validate_action(start, State, _-[’org#Jack’]- __). 3 4true. Listing C.8: Validierung eines bestimmten Agenten (1) Lässt man nun noch die Handlung ungebunden, ersetzt also den ersten Parameter start des Prädikates validate_action/3 durch eine ungebundene Variable (Action), so wird neben der Validierung, ob Jack den Prozess überhaupt ausführen kann, noch ermittelt, welche Handlungen er genau ausführen darf. Listing C.9 zeigt das erwartete Ergebnis. Die Handlungen finish und abort werden nicht an die Variable Action gebunden, da diese Handlungen im initialen Zustand noch nicht möglich sind (siehe funktionales Constraint). 1?- process_planning::initial_state(set_up_surgery_plan, State), 2pid_0(_)::validate_action(Action,State, _-[’org#Jack’]- __). 3 4Action = start Listing C.9: Validierung eines bestimmten Agenten (2) C.4 Datenbezogene Constraints Bei der datenbezogenen Perspektive verhält es sich weitgehend ähnlich wie bei der organisatorischen. Statt der Agenten werden hier diejenigen Daten ermittelt, die zum Ausführen des Prozesses benötigt werden (siehe Listing C.10). Die ermittelten Daten werden als Liste im ungebundenen vierten Parameter (?list(required_dataitems)) zurückgegeben. Genau wie bei der organisatorischen Perspektive kann der vierte Parameter auch gebunden (mit bestimmten Werten vorbelegt) sein, um zu überprüfen, ob die in der Liste angegebenen Daten für eine Validierung ausreichend sind. 1:- public(data_constraint/5). 2:- mode(data_constraint(+list(actions), 3+list(state), 4+instance_identifier, 5?list(required_dataitems), 6+callable), 7zero_or_more). Listing C.10: Constraint-Signatur der datenbezogenen Perspektive C.5 Operationale Constraints Operationale Constraints modellieren Werkzeuge und Applikationen die zur Ausführung eines Prozess benötigt werden. Sie verwenden das gleiche Muster wie organisatorische und datenbezogene Prozessconstraints. Durch ihre Auswertung werden Werkzeuge bzw. Applikationen anhand der eingesetzten Ontologie ermittelt, mit denen der Prozess ausge- 134 Sprachdefinition führt werden kann (siehe Listing C.11). Genau wie bei der organisatorischen und datenbezogenen Perspektive kann der vierte Parameter bidirektional verwendet werden, das heißt, zur Ermittlung, aber auch Verifikation von Werkzeugen. 1:- public(operational_constraint/5). 2:- mode(operational_constraint(+list(actions), 3+list(state), 4+instance_identifier, 5?list(tools), 6+callable), 7zero_or_more). Listing C.11: Constraint-Signatur der operationalen Perspektive Anhang D Signaturen der ESProNa-Objekte Auf den folgenden Seiten sind die Signaturen der einzelnen Objekte aufgelistet. Sie beinhalten neben den mode-Direktiven auch eine Übersicht über die in den Objekten enthaltenen Prädikate. operational_constraint organizational_constraint Operational Perspective Data Perspective data_constraint Organizational Perspective POPM Perspectives imports imports imports behavioral_constraint functional_constraint Behavioral Perspective Functional Perspective imports imports process_planning specializes instantiates esprona_blind_search esprona_heuristic_search has specializes esprona_depth_first esprona_breadth_first esprona_hill_climbing instantiates instantiates references references specializes specializes contains definitions 1 N process library/process library/process/popm model_state library/state heuristic_state_space library/planning/solvers state_space library/planning/solvers library/planning esprona_search_strategy library/planning/solvers library/planning/solvers library/planning/solvers library/planning/solvers library/planning/solvers library/planning/solvers process_model process_models/.../ functional_heuristic behavioral_heuristic organizational_heuristic data_heuristic operational_heuristic uses :- object(pid_0(_), extends(process)). :- dynamic. process_title('Anamnese'). ... :- end_object. :- object(pid_1(_), extends(process)). ... Heuristics library/process/popm process_state library/state 1 N contains references 1 1 esprona_best_first library/planning/solvers instantiates instantiates 135 functional_constraint This perspective is conform when the given functional constraints evaluate to true. author:Michael Igler ([email protected]) version: 0.8 date: 2010/4/19 compilation: static, context_switching_calls (no dependencies on other files) Public interface functional_constraint/4 Contains the POPM constraints of the functional perspective. compilation: static mode - number of solutions: functional_constraint(+list(actions),+modelstate,-instance_identifier, +callable) - zero_or_more functional_constraint/5 Contains the POPM constraints of the functional perspective. compilation: static mode - number of solutions: functional_constraint(+modal_prefix,+list(actions),+modelstate,- instance_identifier,+callable) - zero_or_more functional_constraints_conform/3 This predicate expects: instantiated Action(+var), instantiated ModelState(+list) and a free or instantiated Instance(?var). compilation: static mode - number of solutions: functional_constraints_conform(?action,+modelstate,?instance_identifier) - zero_or_more counter_increasable/1 Verifies if the counter can be increased by 1. The current counter has to be smaller than supremum of the counter_interval. compilation: static mode - number of solutions: counter_increasable(+var) - zero_or_one interval_supremum/1 Retrieves the interval supremum of a process. compilation: static mode - number of solutions: interval_supremum(?var) - zero_or_one interval_infimum/1 Retrieves the interval infimum of a process. compilation: static mode - number of solutions: interval_infimum(?var) - zero_or_one counter_interval/1 Retrieves the interval of a process. compilation: static mode - number of solutions: counter_interval(-interval) - one_or_more correlated_to_other_processes/1 Checks if the counter_interval of the process is dependent/correlated to other processes. compilation: static mode - number of solutions: correlated_to_other_processes(+modelstate) - zero_or_one exists_instance/3 Verifies if a certain instance has been executed in the given model state. compilation: static mode - number of solutions: exists_instance(+modelstate,?action,?instance_identifier) - zero_or_more actions_applicable/3 Checks of the actions are applicable in the given model state. compilation: static mode - number of solutions: actions_applicable(+modelstate,?action,?instance_identifier) - zero_or_more in_domain/1 Checks if process counter is in the domain interval in a given model state. compilation: static functional_heuristic Predicates for heuristic searching and planning algorithms of the functional perspective. author:Michael Igler ([email protected]) version: 0.8 date: 2011/4/6 compilation: static, context_switching_calls implements: public heuristic_protocol Public interface (see related entities) Protected interface (see related entities) Private predicates costs_do_process/4 Calculates the costs for executing a given process ID. compilation: static mode - number of solutions: costs_do_process(+process_object,+modelstate,+var(action),-number) - zero_or_one behavioral_heuristic Predicates for heuristic searching and planning algorithms of the behavioral perspective. author:Michael Igler ([email protected]) version: 0.8 date: 2011/4/6 compilation: static, context_switching_calls implements: public heuristic_protocol Public interface set_up_graph/2 Sets up a graph representing the dependencies between the different processes. compilation: static mode - number of solutions: set_up_graph(+var(action),-graph) - one Protected interface (see related entities) Private predicates (see related entities) organizational_heuristic Predicates for heuristic searching and planning algorithms of the organizational perspective. author:Michael Igler ([email protected]) version: 0.8 date: 2011/4/6 compilation: static, context_switching_calls extends: public heuristic_perspective Public interface (see related entities) Protected interface (see related entities) Private predicates (see related entities) data_heuristic Predicates for heuristic searching and planning algorithms of the data perspective. author:Michael Igler ([email protected]) version: 0.8 date: 2011/4/6 compilation: static, context_switching_calls extends: public heuristic_perspective Public interface (see related entities) Protected interface (see related entities) Private predicates (see related entities) operational_heuristic Predicates for heuristic searching and planning algorithms of the operational perspective. author:Michael Igler ([email protected]) version: 0.8 date: 2011/4/6 compilation: static, context_switching_calls extends: public heuristic_perspective Public interface (see related entities) Protected interface (see related entities) Private predicates (see related entities) process Describes the process object as a composition of all POPM perspectives. author:Michael Igler ([email protected]) version: 0.8 date: 2011/3/3 compilation: static, context_switching_calls imports: public functional_constraint public behavioral_constraint public organizational_constraint public data_constraint public operational_constraint Public interface process_title/1 The title of the process. compilation: static mode - number of solutions: process_title(-atom) - one process_description/1 The description of the process. compilation: static mode - number of solutions: process_description(-atom) - one contained_in_process_model/1 Stores in which process model this process is contained. compilation: static mode - number of solutions: contained_in_process_model(-process_model) - one process_actions/1 Declaring the actions that can be performed on the process. compilation: static mode - number of solutions: process_actions(+list(actions)) - one process_domain/2 The domain of the process is stored here. compilation: static mode - number of solutions: process_domain(+list(dependencies),+term(clpfd_domains)) - one highest_positive_recommendation_degree/1 ... compilation: static mode - number of solutions: highest_positive_recommendation_degree(-number) - one highest_negative_recommendation_degree/1 ... compilation: static mode - number of solutions: highest_negative_recommendation_degree(-number) - one validate_action/3 ... compilation: static mode - number of solutions: validate_action(?var(action),+modelstate,+compound_term(concept_identifiers)) - zero_or_more perform_action/4 ... compilation: static mode - number of solutions: perform_action(+var(action),+modelstate,+compound_term(concept_identifiers),? list(state)) - zero_or_one id/1 Returns the process identifier. Example query: pid_1(_)::id(MyID). compilation: static mode - number of solutions: id(?var(process_identifier)) - zero_or_one Protected interface (see related entities) Private predicates (see related entities) process_state(A,B) Represents the state of a process containing Process_ID, Process_History_List, Process_Status. author:Michael Igler ([email protected]) version: 0.8 date: 2010/4/19 compilation: static, context_switching_calls (no dependencies on other files) Public interface get_highest_instance_id/1 Retrieves the highest instance-ID of the process. compilation: static mode - number of solutions: get_highest_instance_id(-number) - one update_process_state/2 Updates a process state. compilation: static mode - number of solutions: update_process_state(+compound_term(concept_identifiers),-process_state) - one instance_successtype_agents_data_tools/5 Retrieves information about a certain execution. compilation: static mode - number of solutions: instance_successtype_agents_data_tools(+instance_identifier,+action,+agent, +data,+tool) - zero_or_one instance_successtype_agents_data_tools_counter/6 Counts the executions by a certain person with certain data and tools. compilation: static mode - number of solutions: instance_successtype_agents_data_tools_counter(+instance_identifier,+action, +agent,+data,+tool,-number) - zero_or_one print/0 Prints some informations about the state. compilation: static mode - number of solutions: print - one print/1 Prints some informations about the process state to a stream alias. compilation: static mode - number of solutions: print(+var) - one Protected interface (none) Private predicates (none)