In diesem Beitrag nutzen wir den in [GL06] eingef u¨hrten Ansatz, die in einer ereignisgesteuerten Prozesskette (EPK) enthaltenen Informationen in eine PrologFaktenbasis zu u¨bersetzen und durch Abfragen an den Prolog-Interpreter mo¨gliche Modellverbesserungen zu lokalisieren. Dabei werden, anders als in fru¨heren Vero¨ffentlichungen beschrieben, die Beschriftungen von Ereignissen und Funktionen in die Analyse der Modelle einbezogen. Durch Erzeugen einer textuellen Normalform und die Beachtung von Synonymen und Antonymen wird versucht, Beschriftungen mit gleicher Bedeutung und Beschriftungen, die sich widersprechen, zu finden. Auf diese Weise lassen sich bestimmte Klassen ha¨ufig anzutreffender Modellierungsfehler in EPKs automatisch erkennen. Das Verfahren wurde an 1253 deutschsprachigen Modellen getestet. Dabei wurden mehrere Fehler identifiziert, die mit Hilfe herk o¨mmlicher Validierungstechniken unentdeckt bleiben.
AG 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 ko¨nnen. Ziel unserer Arbeit war es, auch solche Fehler automatisch zu lokalisieren. Durch eine automatische Erkennung soll insbesondere dem ungeu¨bten Modellierer ein Werkzeug zur Hand gegeben werden, um die Qualita¨t seiner Modelle bereits wa¨hrend des Modellierungsprozesses zu pru¨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 Modellu¨berpru¨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 entha¨lt Abschnitt 4. Schließlich werden in Abschnitt 5 die Ergebnisse diskutiert und mit anderen Arbeiten verglichen. 2
Bei der manuellen Analyse von Modellen aus der Praxis identifizierten wir einige ha¨ufige Modellierungsfehler, die durch ga¨ngige Verfahren zur Validierung des Kontrollflusses nicht entdeckt werden ko¨nnen, die jedoch durch einfache Analyse der Beschriftungen von Modellelementen zu identifizieren sind. Diese Muster werden im Folgenden vorgestellt. 2.1
A
A
Ein Konnektor hat zwei logisch identische Ereignisse als Vorga¨nger oder Nachfolger.
Folgen die logisch identischen Ereignisse auf einen XORSplit, ist dies ein inhaltlicher Fehler. Andernfalls ist dieses Muster ein Hinweis auf die Mo¨glichkeit, das Modell durch
Weglassen redundanter Elemente zu verkleinern.
Stehen die logisch identischen Ereignisse nach einem XOR-Split, ist dies offenbar stets ein inhaltlicher Fehler, da der XOR-Split ja gerade aussagt, dass nur eines der Ereignisse eintreten kann (und das andere nicht). Ergebnis >= 60% Kurs "nicht erfolgreich" markieren Kurs "nicht erfolgreich" markiert
Abschluss
test absolvieren
Test wiederholt Kurs "nicht erfolgreich" markieren Kurs "nicht erfolgreich" markiert
Ergebnis < 60%
Test wiederholt?
Test nicht wiederholt
Abbildung 1: inhaltlich fehlerhaftes Modell In allen anderen Fa¨llen sind verschiedene Situationen mo¨ glich: Abb. 1 ist ein Modellausschnitt1 aus [GKMZ07]. Hier weist das doppelte Vorkommen des Ereignisses “Kurs ’nicht erfolgreich’ markiert” auf einen Modellfehler hin: Vermutlich ha¨tte im linken Zweig die
In den meisten Fa¨llen jedoch du¨ rfte das doppelte Vorkommen eines Ereignisses lediglich ein Indiz dafu¨ r sein, dass die EPK vereinfacht werden kann. Ein Beispiel zeigt Abb. 2, entnommen einer Diplomarbeit. Eine Modellierung wie im linken Modell von Abb. 2 widerspricht dem Grundsatz, die Zahl der Modellelemente auf das erforderliche Maß zu beschra¨nken. Diese Forderung ist etwa unter der Bezeichnung ”Minimalita¨t“ in [Ron97] zu finden. Becker, Rosemann and Schu¨ tte fordern in den ”Grundsa¨tzen ordnungsgema¨ßer
und zur Wiedergabe der Intention notwendig sind“(zitiert aus [BRS95]). Gesondert zu betrachten sind Ereignissen, die mit trivialen Standardtexten wie ”erfolgreich durchgefu¨ hrt“ oder ”OK“ fu¨ r Ereignisbeschriftungen beschriftet sind. Da hier der Bezug darauf fehlt, was erfolgreich durchgefu¨ hrt wurde, ko¨ nnen Ereignisse trotz gleichlautender 1Die in diesem Beitrag gezeigten Modellbeispiele stellen keine kompletten EPK-Modelle dar, sondern zeigen lediglich unvollsta¨ndige Modellfragmente. kein Anbieter gefunden Irrelevante Anbieter aus Anbieterliste entfernen Anbieterliste leer
Prüfung der potentiellen Anbieter
Referenzen zu
Anbietern erstellen Referenzen erstellt
Referenzierte Anbieter aus Anbieterliste entfernen Referenzierte
Anbieter entfernt Irrelevante Anbieter aus Anbieterliste entfernen Anbieterliste leer
Prüfung der potentiellen Anbieter Referenzen zu
Anbietern erstellen Referenzen
erstellt Irrelevante Anbieter aus Anbieterliste entfernen Anbieterliste leer
Referenzierte Anbieter aus Anbieterliste entfernen Referenzierte
Anbieter entfernt Anbieter gefunden kein Anbieter gefunden
Anbieter gefunden
Abbildung 2: links: Originalmodell, rechts: vereinfachtes Modell Beschriftung verschiedene betriebliche Situationen darstellen. Diese Fa¨lle werden durch unseren Algorithmus, der solche “Trivialereignisse erkennt”, ausgeschlossen. Trotzdem sind gelegentliche “Fehlalarme” wie in dem in Abb. 3 (entnommen aus [K0¨6]) gezeigten Modellfragment mo¨glich.
Weiter ist zu beachten, dass zwei Ereignisse trotz gleichlautender Beschriftung erkennbar verschieden sind, wenn ihnen in einer erweiterten EPK verschiedene Organisationseinheiten zugeordnet sind. Ein Ereignis Pru¨fung erfolgreich“, ausgefu¨hrt von der Buchhaltung, ” ist ein anderes Ereignis als Pru¨fung erfolgreich“, ausgefu¨hrt von der Rechtsabteilung. ”
Baurechtliche
Prüfung Einzelprüfung erfolgt
Bautechnische
Prüfung Einzelprüfung
erfolgt Abbildung 3: Fehlalarm bei Muster A 2.2
/ A
A
Ein Konnektor vom Typ OR oder AND hat zwei Ereignisse, die sich logisch widersprechen, als Vorga¨nger oder Nachfolger. Dies ist ein logischer Fehler im Modell.
Mo¨glicherweise sollte der Konnektor durch einen XOR
Konnektor ersetzt werden.
In dem Modellfragment aus Abb. 4 (das einer Diplomarbeit entnommen wurde), wurde statt des die Situation korrekt beschreibenden XOR-Splits ein OR-Split verwendet. Bei unerfahrenen Modellierern ist eine solche Verwechslung zwischen OR und XOR ein ha¨ufiger Fehler.
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 ko¨nnen diese im Modell parallel durchlaufen werden. Insbesondere heißt das, dass mehrere Ereignisse, die auf einen AND- oder OR-Join folgen, gemeinsam eintreten du¨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 fa¨lschlicherweise ein OR- oder AND-Split verwendet wurde.
Eine analoge Aussage gilt fu¨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 ko¨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“ mo¨glich wa¨re. 2.3
A
A
B
Ein Konnektor vom Typ XOR hat die Ereignisse A, :A sowie ein weiteres Ereignis B als Vorga¨nger oder Nachfolger.
Da stets entweder A oder :A eintritt, ist die Berechtigung des dritten Ereignisses B fraglich (Tertium non datur).
In diesem Muster folgen auf einen XOR-Split ein Ereignis A, dessen Negation :A und mindestens ein weiteres Ereignis B. Da stets eines der Komplementa¨rereignisse A und :A eintreten muss, sollte es eigentlich keine Berechtigung fu¨ r ein drittes Ereignis B geben. Das Modellfragment in Abb. 5 ( entnommen dem Zeitschriftenartikel [GK00]) zeigt ein Beispiel fu¨ r das Auftreten des Musters. In einem solchen Modell leidet zumindest die Versta¨ndlichkeit2: Da offenbar stets genau eines der beiden linken Ereignisse eintritt, ist die Berechtigung der beiden anderen Ereignisse unklar.
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.
der Eindruck eines Fehlers dadurch, dass die Aussage ”CR ist vorhanden und (un)vollsta¨ndig“ verku¨ rzt wurden auf ”CR ist (un)vollsta¨ndig“. Fu¨ r den Leser des Modells du¨ rfte diese verku¨ rzte Schreibweise sogar leichter versta¨ndlich sein.
CR ist vollständig
CR ist nicht vollständig
CR ist nicht vorhanden
Abbildung 6: Fehlalarm bei Muster C In Fa¨llen wie in Abb. 6 ist es kaum mo¨ glich, Fehlalarme auszuschließen. Dies gelingt jedoch in einem ha¨ufigen Spezialfall, na¨mlich dann, wenn die Ereignisbeschriftungen A, :A und B Entscheidungen der Art ”ja“ / ”nein“ / ”unter Umsta¨nden“ beschreiben. Um auch solche Situationen richtig zu behandeln, meldet unsere Mustersuche in den Fa¨llen, 2Den fachlichen Inhalt des Modellausschnitts erlauben wir uns nicht zu beurteilen. in denen B einschra¨nkende Begriffe wie ”zum Teil“, ”eventuell“ oder ”unter Vorbehalt“ entha¨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, fu¨r die kein Auftreten des Musters gemeldet wird: ”Berichte sind in Ordnung“ / ”Berichte sind nicht in Ordnung“ / Berichte sind nur teilweise in Ordnung“ ”Bestellstatus zuru¨ckgewiesen“ / ”Bestellstatus zugestimmt“ / ”Bestellstatus teilweise zugestimmt“ 2.4
Vergessen des Falles ”Gleichheit“ beim Vergleich von Werten
A
A
B
Ereignisse nach einem Konnektor beschreiben Gro¨ßenvergleiche der Form “a < b” / “a > b” oder Gro¨ßenvera¨nderungen der Form “a ist gestiegen” / “a ist gesunken” Es besteht die Mo¨glichkeit, dass bei der Modellierung der Fall der Gleichheit (“a < b”) bzw. des Gleichbleibens (“a blieb unvera¨ndert”) vergessen wurde.
Projektantrag ist zu stellen Auftragswert
prüfen / unterzeichnen Projektantrag
prüfen / unterzeichnen Auftragswert < xxx Euro
Auftragswert >
xxx Euro
Abbildung 7: Vergessen des Falles ”Gleichheit“ beim Vergleich von Werten Als Ereignisse, deren Eintreten u¨ber die weitere Abarbeitung eines EPK-Modells nach einem Konnektor entscheidet, dienen in manchen Fa¨llen Vergleiche von Werten. Im Beispiel von Abb. 7 (entnommen dem Buch [BKR08, Seite 634]) wird der Projektantrag sofort eingereicht, wenn der Auftragswert kleiner als ein bestimmter Betrag ist. Ist er gro¨ßer als der genannte Betrag, muss eine zusa¨tzliche Pru¨fung erfolgen. Im beschriebenen
vergessen hat (vgl. [Amb03], Regel 233).
Unser Werkzeug identifiziert solche Situationen in einem Modell und weist auf ein mo¨gliches Problem hin.
Analog untersuchen wir Aussagen zur Vera¨nderung von Gro¨ßen. Folgen etwa auf einen
ein Hinweis, dass der Fall ”Bedarf ist gleich geblieben“ eventuell bei der Modellierung vergessen wurde. 2.5
j a / n e i n ? /
Auf eine Entscheidungsfrage folgt ein AND- oder OR-Split, so dass laut Modell mehrere Ereignisse zugleich auftreten ko¨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 fu¨r Fragen der Art “Pru¨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 U¨ berpru¨fung korrekterweise ein OR-Split stehen sollte3.
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 3Im gezeigten Modell liegt außerdem Muster B vor; dies muss jedoch nicht immer der Fall sein.
Wir benutze den in [GL06] eingefu¨hrten Ansatz, die in einer ereignisgesteuerten Prozesskette (EPK) enthaltenen Informationen in eine Prolog-Faktenbasis zu u¨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 mo¨gliche Modellvereinfachungen, die zu einer leichteren Erfassbarkeit einer EPK fu¨hren [GL09], untersucht. Die grundsa¨tzlichen Schritte bei einer logikbasierten Analyse sind: 1. U¨ bersetzung der im Modell enthaltenen Informationen in eine Prolog-Faktenbasis.
Diese entha¨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. U¨ berfu¨hren der Beschriftungen der Modellelemente in eine Normalform, so dass
Beschriftungen gleicher Bedeutung in dieselbe Normalform u¨berfu¨hrt werden 3. Suche nach den beschriebenen Mustern mittels Abfragen an den Prolog-Interpreter 3.1
Die U¨berfu¨hrung von EPK-Modellen in eine Prolog-Faktenbasis erfolgt mittels eines XSLTSkripts, dass eine EPML-Datei in Prolog-Regeln u¨berfu¨hrt. Details sind in [GL06] zu finden. 3.2
In Schritt 2 werden die Beschriftungen der Modellelemente in eine Normalform gebracht. Zweck dieser Normalform ist es, dass Beschriftungen gleicher Bedeutung in die gleiche Normalform u¨berfu¨hrt werden. Zu diesem Zwecke werden Stoppwo¨rter, Synonyme und Antonyme beachtet. In unserem prototypischen Werkzeug haben wir 210 Synonyme und 70 Antonyme zu Begriffen aufgenommen, die sich sehr ha¨ufig in Modellen betrieblicher Abla¨ufe finden.
Um die Population des Synonym/Antonym-Katalogs aufzubauen, wurde zuna¨chst untersucht, welche Begriffe in Modellen eines uns vorliegenden EPK-Katalogs am ha¨ufigsten vorkommen. Hierfu¨r wurden insgesamt 1154 deutschsprachige EPKs (darunter die 749 EPKs des deutschsprachigen SAP R/3-Referenzmodells) ausgewertet. Deren Beschriftungen von Ereignissen und Funktionen enthielten insgesamt 66088 Wo¨rter, darunter 7599 verschiedene. Unter den am ha¨ufigsten gefundenen Begriffen wurden, sofern sinnvoll, Wo¨rter zu Gruppen von Synonymen zusammengefasst. Die in einer solchen Gruppe enthaltenen Wo¨rter werden dann bei der Normalformbildung alle durch die selbe Zeichenkette dargestellt. Um die Normalform zu erhalten, bildet unser Algorithmus durch wiederholte Ersetzung von Zeichenketten eine Normalform einer Modellbeschriftung, indem Begriffe mit gleicher Bedeutung in die selbe Zeichenkette u¨berfu¨hrt werden. In den beiden Ereignisbeschriftungen ”Der Antrag ist genehmigt“ und ”Dem Antrag wurde zugestimmt“ werden zuna¨chst Stoppwo¨rter wie der, die, das, ein, eine u.a¨. durch die leere Zeichenkette ersetzt, da sie fu¨r die Erfassung der Bedeutung der Zeichenkette verzichtbar sind. Da die Wo¨rter “genehmigt” und “zugestimmt” beide im Synonymkatalog enthalten sind, werden weiterhin beide Zeichenketten in die selbe Normalform “Antrag nf genehmigt” u¨berfu¨hrt. Auf die gleiche Weise werden Zeichenketten ersetzt, die zum Antonym-Katalog enthalten sind. In diesem Falle wird außerdem ein Flag gesetzt, das ausdru¨ckt, dass die Normalform das Gegenteil der urspru¨nglichen Zeichenkette darstellt. Auf diese Weise wird etwa die Zeichenkette “Der Antrag wurde abgelehnt” ebenfalls in die Normalform “Antrag nf genehmigt” u¨berfu¨hrt. Am gesetzten Flag ist jedoch erkennbar, dass sie das Gegenteil aussagt.
Tabelle 1 zeigt die in unserem Korpus von EPK-Modellen am ha¨ufigsten gefundenen Wo¨rter sowie (falls zutreffend) ihre Ersetzung im Zuge der Normalform-Bildung: Eine besondere Behandlung erfahren Ereignisbeschriftungen der Form x y mit 2 f<; >; =; ; ; g sowie Formen wie “x hat sich erho¨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 erho¨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 gro¨ßer als y” zwei der drei mo¨glichen Falle “gro¨ßer/kleiner/gleich” beschreiben. 3.2.1
Aus der Beschreibung der in Abschnitt 2 betrachteten Muster wird deutlich, dass zur Identifikation der beschriebenen Muster die folgenden logischen Abfragen ausreichend sind:
Diese wird einfach durch das Vorhandensein eines Kontrollflusspfeiles ausgedru¨ckt, was sich in der Prolog-Repra¨sentation des Modells durch ein Pra¨dikat arc(x,y) widerspiegelt.
Dies fu¨hrt, wie in Schritt 2 dargestellt, dazu, dass beide Beschriftungen in die selbe Normalform u¨berfu¨hrt wurden. Eine Meldung zu Problem A wird nur ausgegeben, wenn die Ereignisse nicht eine triviale Beschriftung wie “erledigt” oder “fertig” haben.
Dies ist der Fall, wenn A und B in die selbe Normalform u¨berfu¨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-” eingefu¨gt wurde.
Schließlich widersprechen sich Ereignisbeschriftungen, wenn sie genau zwei der drei Fa¨lle “kleiner/gro¨ßer/gleich” oder “verringert/vergro¨ßert/unvera¨ndert” darstellen.
Dies wird angenommen, wenn die Ereignisbeschriftung bestimmte einschra¨nkende Zeichenketten wie z.B. “mo¨glicherweise”, “eventuell”, “vielleicht”, “mo¨glichenfalls”, “unter Umsta¨nden”, “u.U.”, “unter Vorbehalt(en)”, “zum Teil”, “z.T.”, “teilweise”, “partiell” oder “unvollsta¨ndig” entha¨lt.
Dies wird angenommen, wenn die Beschriftung einer Funktion die Zeichenkette “, ob” entha¨lt (“Pru¨fe, ob der Auftrag ausgefu¨hrt wurde”) sowie wenn die Beschriftung mit einem Fragezeichen endet, jedoch nicht mit einem Fragewort (“wer”, “womit”, etc.) beginnt. Als Entscheidungsfrage wird somit z.B. “Erfolgte der Widerspruch rechtzeitig?” eingestuft, jedoch nicht “Welche Zusatzoptionen werden gewu¨nscht?”. Mit diesen genannten Pra¨dikaten sowie weiteren einfachen Pra¨dikaten, die z.B. bestimmen, ob ein Konnektor Split oder Join ist (siehe auch [GL06]) la¨sst sich z.B. eine Abfrage nach Muster A fu¨r zwei Ereignisse nach einem XOR-Split (was auf einen ernsten Modellierungsfehler hinweist) in Prolog wie folgt formulieren: findemuster(E1,E2) :split(C),type(C,xor), \% C ist ein XOR-Split... arc(C,E1),arc(C,E2), \% von dem aus es Pfeile zu E1 und E2 gibt event(E1),event(E2), \% E1 und E2 sind Ereignisse E1 @< E2, \% bedeutet insbesondere: E1 ungleich E2 elementname(E1,NameE1), \% E1 hat die Beschriftung NameE1 elementname(E2,NameE2), \% E2 hat die Beschriftung NameE2 equivalent(NameE1,NameE2), \% NameE1 und NameE2 sind logisch a¨quivalent not(trivialereignis(NameE1)), \% NameE1 ist kein Trivialereignis not(trivialereignis(NameE2)). \% NameE2 ist kein Trivialereignis
Wir u¨berpru¨ften unser Verfahren an 1253 EPK-Modellen in deutscher Sprache, die wir aus verschiedenen Quellen zusammengetragen haben.
Dabei stammten: 591 EPKs aus dem deutschsprachigen SAP R/3 Referenzmodell 127 EPKs aus Bu¨chern (vornehmlich Lehrbu¨cher zur EPK-Methode oder zu SAP R/3) 48 EPKs aus Dissertationsschriften 70 EPKs aus wissenschaftlichen Vero¨ffentlichungen in Zeitschriften und Konferenzba¨nden 252 aus Bachelor-, Diplom- und Seminararbeiten 84 EPKs aus Praxisprojekten 22 EPKs aus Vorlesungsskripts 13 EPKs aus Software-Handbu¨chern Bei den verbleibenden 37 Modelle handelt es sich um im Internet vero¨ffentlichte EPKs, deren Einordnung in die o.g. Kategorien nicht mo¨glich ist. Durch die Einbeziehung der verschiedenen Quellen ist zu erwarten, dass Modelle von Autoren mit ho¨chst unterschiedlichen Erfahrungen mit der EPK-Modellierungsmethode beru¨cksichtigt wurden. Alle vom Werkzeug gemeldeten Problemmeldungen wurden durch manuelle Pru¨fung der betroffenen EPK untersucht, um zu entscheiden, ob tatsa¨chlich ein Modellierungsproblem vorliegt. Insbesondere bei Muster C war dies nicht immer eindeutig zu entscheiden; in Zweifelsfa¨llen wurde die Fehlermeldung als “unberechtigt” eingestuft. Es ergab sich die folgende Verteilung von gefundenen Fehlern bzw. “Fehlalarmen”: Insgesamt wurden 114 tatsa¨chliche sinnvolle Hinweise in 84 EPKs erkannt. Dem stehen 14 “Fehlalarme” in 13 EPKs entgegen. Die zahlreichen Fehlalarme bei Muster C legen nahe, dass eine Untersuchung dieses Musters in der Praxis nicht unbedingt sinnvoll ist. Bei allen anderen Mustern zeigen die gemeldeten Musterinstanzen fast ausnahmslos tatsa¨chliche Muster Muster A Muster B Muster C Muster D Muster E gemeldete Vorkommen des Musters 71 in 55 EPKs 31 in 19 EPKs 21 in 18 EPKs 3 in 3 EPKs 2 in 2 EPKs davon unberechtigte Fehlermeldungen 1 in 1 EPK 1 in 1 EPK 12 in 11 EPKs keine keine
Tabelle 2: Gefundene Fehler in den einzelnen Fehlerklassen Fehler bzw. Modellierungsprobleme. Dem Modellierer du¨rfte somit geholfen sein, wenn er zur Modellierungszeit eine Ru¨ckmeldung u¨ber Auftreten der genannten Muster und ggf. mo¨glichen Modellverbesserungen erha¨lt.
Bemerkenswert ist der Zusammenhang zwischen den gefundenen Fehlern und der Herkunft der Modelle. So stellt Muster B einen typischen Anfa¨ngerfehler dar - statt eines XOR-Splits wird das umgangssprachlich naheliegende OR verwendet. Wa¨hrend dieser Fehler in den studentischen Arbeiten (wie auch in einem Praxisprojekt aus dem Bereich Medien) recht ha¨ufig auftritt, wurde kein einziges Vorkommen dieses Musters im SAP R/3-Referenzmodell gefunden. Diese Beobachtung zeigt, dass von einem automatischen Erkennen der beschriebenen Fehlermuster hauptsa¨chlich Anfa¨nger profitieren du¨rften. 5
Das im vorangehenden Abschnitt beschriebene Ergebnis belegt, dass sich durch eine Analyse der Beschriftung von Modellelementen eine nennenswerte Zahl von Modellierungsfehlern aufspu¨ren la¨sst. Diese Modellierungsfehler bleiben bei bloßer Betrachtung des Kontrollflusses unentdeckt.
Unser Algorithmus setzt keine Beschra¨nkung der im Modell zu verwendenden Elemente der natu¨rlichen Sprache voraus. Ereignisse und Funktionen ko¨nnen durch beliebigen Freitext beschrieben werden, was der heute meist ga¨ngigen EPK-Modellierungsmethode entspricht. Weit bessere Ergebnisse du¨rften zu erwarten sein, wenn die natu¨rliche Sprache, die zur Beschreibung von Ereignissen und Funktionen verwendet wird, beschra¨nkt wird. Eine Vereinheitlichung der Beschriftungen von Modellierungselementen leistet etwa das Werkzeug Semtalk [FW05], das Ontologien verwendet, um eine einheitliche Verwendung von Substantiven und Verben u¨ber ein oder mehrere Modelle hinweg zu gewa¨hrleisten. Bei Verwendung eines solchen ontologiebasierten Konzeptes ist es auch mo¨glich, echte inhaltliche Pru¨fungen von Gescha¨ftsregeln automatisiert vorzunehmen. Fillies und Weichhardt fu¨hren in [FW03] ein Beispiel an, in dem zwei Gescha¨ftsprozessmodelle ”Bestellungseingang“ und ”Bestellungsbearbeitung“ betrachtet werden. Sie nennen die Gescha¨ftsregel ”Nur besta¨tigte Bestellungen du¨rfen ausgefu¨hrt werden“ als Beispiel einer Regel, die man mit Hilfe solcher ontologiebasierter Modellierung modellu¨bergreifend pru¨fen kann. Ein a¨hnliches Beispiel nennen Thomas und Fellmann. Sie beschreiben in in [TF07] einen Ansatz, Modellierung betrieblicher Abla¨ufe mit EPKs mit Ontologien zu verknu¨pfen. Wir sind davon u¨berzeugt, dass durch die Einbindung von Ontologien in Gescha¨ftsprozessmodellierungsmethoden ma¨chtige Werkzeuge zur Konsistenzpru¨fung und Validierung von Gescha¨ftsprozessmodellen sowie fu¨r Abfragen in Modellkatalogen geschaffen werden ko¨nnen. Vorhandene Ansa¨tze werden beispielsweise in [WHM08] oder [GHSW08] beschrieben.
Wir sind jedoch ebenso davon u¨berzeugt, dass sich in der betrieblichen Praxis solche ontologiebasierte Verfahren schwer durchsetzen werden, da dem Ziel (Verbesserung der Modellqualita¨t) ein zumindest in der Einfu¨hrungsphase erho¨hter Aufwand im Modellierungsprozess entgegensteht. Letzlich sehen die beschriebenen Verfahren vor, eine Doma¨nenontologie zusa¨tzlich zum Modell zu erstellen, was in der Regel per Hand erfolgt (vgl. etwa die Beschreibung zur Erstellung von sog. semantischen EPKs in [FKS08]). Unser Verfahren verzichtet auf eine aufwendige Erstellung einer Doma¨nenontologie. Lediglich die im Standard-Synonym/Antonym-Katalog enthaltenen Begriffe stellen eine einfache Art einer (allerdings unvollsta¨ndigen) Ontologiebeschreibung dar. In der aktuellen Form hat unser Synonym/Antonymkatalog noch einen recht geringen Umfang, so dass wir keinen Anspruch auf vollsta¨ndige Erkennung der untersuchten Problemmuster erheben ko¨nnen. Ebenso gibt es sicher neben den betrachteten ha¨ufigen Problemmustern noch weitere.
Dem Nachteil dieser Unvollsta¨ndigkeit steht der Vorzug der fu¨r den Modellierer einfachen Verfu¨gbarkeit gegenu¨ber. In der Validierung wurde gezeigt, dass sich bereits mit einem kleinen Katalog von Synonymen und Antomymen eine bemerkenswerte Zahl von Modellfehlern finden la¨sst. Im Unterschied zu Verfahren, die eine ontologiebasierte Modellierung verlangen, erha¨lt der Modellierer Informationen zu diesen Fehlern, ohne dass die Modellierungsmethode komplexer wird. Im Werkzeug bflow* Toolbox ist die Mustersuche fest eingebaut und kann “auf Knopfdruck” gestartet werden (siehe Bildschirmfoto in Abb. 9). Dies erweitert die in [GLKK08] beschriebenen Mo¨glichkeiten der bflow* Toolbox, dem Modellierer zur Modellierungszeit Ru¨ckmeldungen u¨ber mo¨gliche Modellverbesserungen zu geben.
Abbildung 9: Integration in die bflow Toolbox, gemeldet werden hier Muster B und Muster E In [ADW08] verwenden Awad et al. Verfahren aus dem Gebiet des Information Retrieval, um ein A¨ hnlichkeitsmaß zwischen Namen von Aktivita¨ten innerhalb eines BPMNDiagramms zu definieren. Dieser Ansatz, der auf die englische Wortschatz-Datenbank WordNet [Fel98] zuru¨ckgreift, kommt ohne Beschra¨nkung des zur Beschreibung von Aktivita¨ten verwendbaren Wortschatzes aus. Er erzielt gute Ergebnisse beim Erkennen gleicher oder a¨hnlicher Aktivita¨ten, auch wenn diese nicht identisch bezeichnet sind. Eine Kombination des in [ADW08] beschriebenen Verfahrens mit dem von der gleichen Forschungsgruppe beschriebenen Validierungsansatz [ADW08] erlaubt auch eine U¨ berpru¨fung inhaltlicher Aussagen wie ”Es darf kein Konto ero¨ffnet werden, bevor die Identita¨t des Inhabers u¨berpru¨ft wurde“.
Einen zu [ADW08] a¨hnlichen Ansatz beschreibt [KO07], hier steht jedoch nicht die Validierung von Modellen sondern das Erkennen von Modellvarianten im Vordergrund. Ein wesentlicher Unterschied zwischen unserem Ansatz und [ADW08] sowie [KO07] besteht darin, dass wir bereits mit einem sehr kleinen Katalog von Synonymen und Antonymen beachtliche Ergebnisse erzielen ko¨nnen. Generell ist jedoch eine Verbesserung der Fehlererkennung zu erhoffen, wenn statt unseres eher einfachen Ansatzes zur Erkennung von identischen bzw. negierten Aussagen ma¨chtigere Verfahren (wie in [ADW08], [KO07] oder [GZ05] beschrieben) verwendet werden.
Ein weiteres Feld fu¨r ku¨nftige Erweiterungen ist die U¨ berpru¨fung der Einhaltung von Modellierungskonventionen fu¨r die Beschriftung von Ereignissen und Funktionen. So sollten Ereignisse etwa durch ein adjektivisch verwendetes Partizip (”Der Antrag wurde genehmigt“) und Funktionen durch den Infinitiv eines Verbs (”Antrag genehmigen“) dargestellt werden. Abweichende Modellierungskonventionen (”Der Antrag ist zu genehmigen“ / ”Der Antrag wird genehmigt“) sind mo¨glich. Bo¨gl et al. zeigen in [BSPW08], wie mit Hilfe von Wortdatenbanken und semantischen Mustern fu¨r Modellbeschriftungen die Einhaltung von Modellierungskonventionen wirkungsvoll u¨berpru¨ft werden kann. Wir planen, unseren Ansatz in Zukunft um weitere Muster, die mo¨gliche Modellverbesserungen beschreiben, zu erweitern. Forscher und Praktiker sind eingeladen, die im Werkzeug bflow* Toolbox bereits integrierten Tests zu nutzen und zu erweitern. Ru¨ckmeldungen und Erweiterungsvorschla¨ge sind herzlich willkommen. Der jeweils aktuelle Entwicklungsstand kann von der Website www.bflow.org4 heruntergeladen werden.
4Das Prolog-Programm befindet sich im Plugin org.bflow.toolbox.prolog, dort findet der interessierte Leser auch die Liste der Synonyme und Antonyme. [Amb03] [BKR08] [BRS95] [DBL07] [EGS04] [Fel98] [FKS08] [FW03] [FW05]
Ahmed Awad, Gero Decker und Mathias Weske. Efficient Compliance Checking Using
BPMN-Q and Temporal Logic. In BPM ’08: Proceedings of the 6th International
Conference on Business Process Management, Seiten 326–341, Berl
Scott W. Ambler. The Elements of UML Style. Cambridge University Press, 2003. J o¨rg Becker, Martin Kugeler und Michael Rosemann. Prozessmanagement. Ein Leitfaden zur prozessorientierten Organisationsgestaltung. Springer-Verlag, 6. Auflage, 2008.
J o¨rg Becker, Michael Rosemann und Reinhard Schu¨ tte. Grundsa¨tze ordnungsgema¨ßer
Modellierung. Wirtschaftsinformatik, 37(5):435–445, 1995.
[BSPW08] Andreas Bo¨ gl, Michael Schrefl, Gustav Pomberger und Norbert Weber. Semantic
Annotation of EPC Models in Engineering Domains by Employ
Proceedings of the Workshop on Semantic Business Process and Product Lifecycle Management held in conjunction with the 3rd European Semantic Web Conference (ESWC 2007), Innsbruck, Austria, June 7, 2007, Jgg. 251 of CEUR Workshop Proceedings, 2007.
Werner Esswein, Andreas Gehlert und Grit Seiffert. Towards a Framework for Model Migration. In Advanced Information Systems Engineering, 16th International Conference, CAiSE 2004, Riga, Latvia, June 7-11, 2004, Proceedings, Jgg. 3084 of Lecture Notes in Computer Science, Seiten 463–476. Springer, 2004.
Christiane Fellbaum, Hrsg. WordNet: An Electronic Lexical Database (Language, Speech, and Communication). The MIT Press, May 1998.
Agata Filipowska, Monika Kaczmarek und Sebastian Stein. Semantically Annotated
EPC within Semantic Business Process Management. In Danilo Ardagna, Massimo
Mecella und Jian Yang, Hrsg., Business Process Management Workshops, Jgg. 17 of
Lecture Notes in Business Information Processing, Seiten 486–497. Spr
Frank Giesa und Herbert Kopfer. Management logistischer Dienstleistungen der Kontraktlogistik. Logistik Management, 2(1):43–53, 2000. [GKMZ07] Guido Grohmann, Wolfgang Kraemer, Frank Milius und Volker Zimmermann. Modellbasiertes Curriculum-Design fu¨ r Learning Management Systeme: Ein Integrationsansatz auf Basis von ARIS und IMS Learning Design. In Wirtschaftsinformatik, Seiten 795–812. Universita¨tsverlag Karlsruhe, 2007.