Einf ührung

Die Semantik eines Modells lässt sich nach Esswein et al. [EGS04] stets in zwei Teile gliedern: in die (in der Regel formal wohldefinierte) Semantik der Modellierungssprache sowie die " konkrete Semantik" jedes einzelnen Modellelements. Bei EPKs wird diese " konkrete Semantik" durch die Beschriftung von Ereignissen und Funktionen in natürlicher Sprache angegeben. Ähnlich unterteilen Pfeifer und Niehaves [PN05] die Bedeutung graphischer Modelle in die Anordnung der formalen Modellierungselemente ( " model element structure") sowie die Bedeutung der Modellelemente in der Sprache der Anwendungsdomäne ( " terminological structure"). Pfeifer und Niehaves unterstreichen, dass eine Validierung eines Modells immer beide genannten Aspekte berücksichtigen muss.

Bisher vorgeschlagene Verfahren zur Validierung von Geschäftsprozessmodellen beziehen jedoch (von wenigen Ausnahmen wie [ADW08] abgesehen) kaum die Beschriftung von

Modellelementen in die Analyse ein. Generell spielen Funktionen und Ereignisse bei den gängigen Validierungsverfahren (siehe etwa [van97,Rum99,Men07]) keine Rolle. Bei diesen Verfahren werden lediglich Kontrollflussfehler (z. B. Deadlocks) betrachtet, die sich aus der Anordnung und den Typen der Konnektoren ergeben.

Beim Auswerten publizierter Modelle fielen uns jedoch mehrfach Fehlermuster auf, die nur bei einer Betrachtung der Beschriftung von Modellelementen -insbesondere Ereignissen -erkannt werden können. Ziel unserer Arbeit war es, auch solche Fehler automatisch zu lokalisieren. Durch eine automatische Erkennung soll insbesondere dem ungeübten Modellierer ein Werkzeug zur Hand gegeben werden, um die Qualität seiner Modelle bereits während des Modellierungsprozesses zu prüfen und zu verbessern.

Zur technischen Validierung unseres Verfahrens wurde unser Algorithmus in das quelloffene Modellierungswerkzeug bflow* Toolbox integriert. Dieses bietet somit neben der Analyse von Syntax-und Kontrollflussfehlern [GL06,GLKK08] auch eine Modellüberprüfung auf die in diesem Beitrag beschriebenen inhaltlichen Fehler.

Die Fehlermuster, die untersucht werden, sind in Abschnitt 2 beschrieben. Anschließend zeigt Abschnitt 3, wie diese Fehler gefunden werden. Das Ergebnis einer ersten Validierung unserer Verfahren enthält Abschnitt 4. Schließlich werden in Abschnitt 5 die Ergebnisse diskutiert und mit anderen Arbeiten verglichen.

Betrachtete Fehlermuster

Bei der manuellen Analyse von Modellen aus der Praxis identifizierten wir einige häufige Modellierungsfehler, die durch gängige Verfahren zur Validierung des Kontrollflusses nicht entdeckt werden können, die jedoch durch einfache Analyse der Beschriftungen von Modellelementen zu identifizieren sind. Diese Muster werden im Folgenden vorgestellt.

Logisch identische Ereignisse vor/nach einem Konnektor

Anfrage entgegengenommen

Ware im Lager suchen

Ware ist gefunden

Ware ist nicht gefunden

Abbildung 4:

Leitet ein OR-oder AND-Split mehrere Kontrollflusszweige ein, so können diese im Modell parallel durchlaufen werden. Insbesondere heißt das, dass mehrere Ereignisse, die auf einen AND-oder OR-Join folgen, gemeinsam eintreten dürfen.

Schließen sich nun zwei auf einen OR-oder AND-Split folgende Ereignisse logisch aus (z.B. " Genehmigung erteilt" / " Genehmigung verwehrt"), so ist davon auszugehen, dass ein Fehler im Modell vorliegt. Dieser besteht meist darin, dass statt eines XOR-Splits fälschlicherweise ein OR-oder AND-Split verwendet wurde.

Eine analoge Aussage gilt für den Fall, dass einander widersprechende Ereignisse direkt vor einem OR-bzw. AND-Join stehen.

Es ist anzumerken, dass sich die beiden Ereignisse auch logisch ausschließen können, wenn nicht eines die Negation des anderen ist. Ein Vorliegen des Musters soll auch erkannt werden, wenn z.B. eine Kombination von Ereignissen wie " Der Wert x hat zugenommen" / " Der Wert x hat abgenommen" gefunden wird, auch wenn außerdem noch der dritte Fall " Der Wert x ist konstant geblieben" möglich wäre.

Ereignis

Kennzahlsystem anwenden

Bedarf für Anwendung kein Bedarf für Anwendung

Änderungsbedarf Kennzahlsystem

Änderungsbedarf Leitungsteam

Abbildung 5: Es tritt stets eines der beiden linken Ereignisse ein.

Einen möglichen durch dieses Muster erzeugten " Fehlalarm" zeigt Abb. 6. Hier entsteht der Eindruck eines Fehlers dadurch, dass die Aussage " CR ist vorhanden und (un)vollständig" verkürzt wurden auf " CR ist (un)vollständig". Für den Leser des Modells dürfte diese verkürzte Schreibweise sogar leichter verständlich sein.

CR ist vollständig CR ist nicht vollständig CR ist nicht vorhanden

Abbildung 6: Fehlalarm bei Muster C In Fällen wie in Abb. 6 ist es kaum möglich, Fehlalarme auszuschließen. Dies gelingt jedoch in einem häufigen Spezialfall, nämlich dann, wenn die Ereignisbeschriftungen A, ¬A und B Entscheidungen der Art " ja" / " nein" / " unter Umständen" beschreiben. Um auch solche Situationen richtig zu behandeln, meldet unsere Mustersuche in den Fällen, in denen B einschränkende Begriffe wie " zum Teil", " eventuell" oder " unter Vorbehalt" enthält, kein Auftreten des.

In den im Rahmen der Validierung untersuchten Praxis-Modellen (vgl. Abschnitt 4) fanden sich die folgenden Kombinationen von Ereignissen nach einem XOR-Split, für die kein Auftreten des Musters gemeldet wird:

• "

Berichte sind in Ordnung" / " Berichte sind nicht in Ordnung" / Berichte sind nur teilweise in Ordnung"

• "

Bestellstatus zurückgewiesen" / " Bestellstatus zugestimmt" / " Bestellstatus teilweise zugestimmt"

Vergessen des Falles "

Gleichheit" beim Vergleich von Werten Muster D Ereignisse nach einem Konnektor beschreiben Größenvergleiche der Form "a < b" / "a > b" oder Größenveränderungen der Form "a ist gestiegen" / "a ist gesunken"

A A B

Es besteht die Möglichkeit, dass bei der Modellierung der Fall der Gleichheit ("a < b") bzw. des Gleichbleibens ("a blieb unverändert") vergessen wurde. Bedarf ist gleich geblieben" eventuell bei der Modellierung vergessen wurde.

AND-oder OR-Split nach einer Entscheidungsfrage

Muster E / j a / n e i n ?

Auf eine Entscheidungsfrage folgt ein AND-oder OR-Split, so dass laut Modell mehrere Ereignisse zugleich auftreten können.

In der Regel sollte nach einer Entscheidungsfrage (also einer Frage, auf die entweder mit "ja" oder mit "nein" geantwortet werden kann), ein XOR-Split folgen. Gleiches gilt für Fragen der Art "Prüfe, ob x oder y". Unser Algorithmus identifiziert Fragen der genannten Art, denen ein AND-oder OR-Split folgt und gibt einen entsprechenden Hinweis aus.

Unser Algorithmus findet z.B. den Modellabschnitt von Abb. 8, bei dem nach der Überprüfung korrekterweise ein OR-Split stehen sollte 3 .

Kunde will kündigen

Überprüfen, ob Kunde noch Filme ausgeliehen hat

Kunde hat noch Filme ausgeliehen

Kunde hat keine Filme mehr ausgeliehen

Abbildung 8: Nach einer solchen Entscheidung sollte immer ein XOR-Split stehen 3 Im gezeigten Modell liegt außerdem Muster B vor; dies muss jedoch nicht immer der Fall sein.

Algorithmus

Wir benutze den in [GL06] eingeführten Ansatz, die in einer ereignisgesteuerten Prozesskette (EPK) enthaltenen Informationen in eine Prolog-Faktenbasis zu übersetzen und durch Abfragen an den Prolog-Interpreter Fehler im Modell zu lokalisieren.

In bisherigen Arbeiten wurde auf diese Weise die syntaktische Korrektheit [GL06], Freiheit von Deadlocks und Kontrollflussfehlern [GLKK08] sowie mögliche Modellvereinfachungen, die zu einer leichteren Erfassbarkeit einer EPK führen [GL09], untersucht.

Die grundsätzlichen Schritte bei einer logikbasierten Analyse sind:

1. Übersetzung der im Modell enthaltenen Informationen in eine Prolog-Faktenbasis. Diese enthält dann Aussagen wie event(i 3) (es gibt ein Ereignis mit der ID i 3) oder elementname(i 3,"Fahrzeug betanken") (das Modellelement mit der ID i 3 ist mit dem Text "Fahrzeug betanken" beschriftet). 2. Überführen der Beschriftungen der Modellelemente in eine Normalform, so dass Beschriftungen gleicher Bedeutung in dieselbe Normalform überführt werden 3. Suche nach den beschriebenen Mustern mittels Abfragen an den Prolog-Interpreter Der Antrag ist genehmigt" und " Dem Antrag wurde zugestimmt" werden zunächst Stoppwörter wie der, die, das, ein, eine u.ä. durch die leere Zeichenkette ersetzt, da sie für die Erfassung der Bedeutung der Zeichenkette verzichtbar sind. Da die Wörter "genehmigt" und "zugestimmt" beide im Synonymkatalog enthalten sind, werden weiterhin beide Zeichenketten in die selbe Normalform "Antrag nf genehmigt" überführt.

Auf die gleiche Weise werden Zeichenketten ersetzt, die zum Antonym-Katalog enthalten sind. In diesem Falle wird außerdem ein Flag gesetzt, das ausdrückt, dass die Normalform das Gegenteil der ursprünglichen Zeichenkette darstellt. Auf diese Weise wird etwa die Zeichenkette "Der Antrag wurde abgelehnt" ebenfalls in die Normalform "Antrag nf genehmigt" überführt. Am gesetzten Flag ist jedoch erkennbar, dass sie das Gegenteil aussagt. Eine besondere Behandlung erfahren Ereignisbeschriftungen der Form x y mit ∈ {<, >, =, ≤, ≥, } sowie Formen wie "x hat sich erhöht", "x verringerte sich", "x ist gefallen", "x ist gestiegen", "x blieb konstant" etc. Auf eine Beschreibung der Details soll an dieser Stelle verzichtet werden. Die folgenden Beispiele illustrieren jedoch, dass als Resultat der Normalformbildung festgestellt werden kann, dass

• "x > 1000" ebenso wie "1000 > x" den Aussagen "x < 1000" oder "x ist gleich1000" widerspricht.

• "x ist gestiegen" und "x hat sich erhöht" die gleiche Aussage darstellen, jedoch im Widerspruch zu "x blieb konstant" und "x verringerte sich" stehen.

• die Aussagen "x ist kleiner als y" und "x ist größer als y" zwei der drei möglichen Falle "größer/kleiner/gleich" beschreiben.

Schritt 3: Abfragen an die Faktenbasis

Aus der Beschreibung der in Abschnitt 2 betrachteten Muster wird deutlich, dass zur Identifikation der beschriebenen Muster die folgenden logischen Abfragen ausreichend sind:

1. Vorgänger-und Nachfolgerbeziehung zwischen Ereignis und Konnektor: Diese wird einfach durch das Vorhandensein eines Kontrollflusspfeiles ausgedrückt, was sich in der Prolog-Repräsentation des Modells durch ein Prädikat arc(x,y) widerspiegelt.

Zwei Ereignisse beschreiben den gleichen Sachverhalt:

Dies führt, wie in Schritt 2 dargestellt, dazu, dass beide Beschriftungen in die selbe Normalform überführt wurden. Eine Meldung zu Problem A wird nur ausgegeben, wenn die Ereignisse nicht eine triviale Beschriftung wie "erledigt" oder "fertig" haben.

Zwei Ereignisbeschriftungen A und B widersprechen einander:

Dies ist der Fall, wenn A und B in die selbe Normalform überführt wurden, jedoch bei der Ersetzung das Flag gesetzt wurde, das auf eine Ersetzung aus dem Antonymkatalog hinweist. Ebenso ist dies der Fall, wenn A aus B hervorgeht, indem eine der negierenden Zeichenketten "un", "nicht" bzw. "nicht-" eingefügt wurde. Schließlich widersprechen sich Ereignisbeschriftungen, wenn sie genau zwei der drei Fälle "kleiner/größer/gleich" oder "verringert/vergrößert/unverändert" darstellen.

Eine Beschriftung weist darauf hin, dass ein Ereignis nur teilweise eintritt:

Dies wird angenommen, wenn die Ereignisbeschriftung bestimmte einschränkende Zeichenketten wie z.B. "möglicherweise", "eventuell", "vielleicht", "möglichenfalls", "unter Umständen", "u.U.", "unter Vorbehalt(en)", "zum Teil", "z.T.", "teilweise", "partiell" oder "unvollständig" enthält. Wir planen, unseren Ansatz in Zukunft um weitere Muster, die mögliche Modellverbesserungen beschreiben, zu erweitern. Forscher und Praktiker sind eingeladen, die im Werkzeug bflow* Toolbox bereits integrierten Tests zu nutzen und zu erweitern. Rückmeldungen und Erweiterungsvorschläge sind herzlich willkommen. Der jeweils aktuelle Entwicklungsstand kann von der Website www.bflow.org4 heruntergeladen werden.

Eine