Modellierung von Geschäftsprozessen in der Unified Modeling Language und ihre Transformation in Petrinetze DavidKreische Lehrstuhl Für Informatik Universität Erlangen-Nürnberg
Martensstr. 3 D-91058 Erlangen
Modellierung von Geschäftsprozessen in der Unified Modeling Language und ihre Transformation in Petrinetze 4DB412EAEB359B18DE2F7E080A228984 GROBID - A machine learning software for extracting information from scholarly documents

In diesem Paper wird gezeigt, wie ein Geschäftsprozess mit Hilfe der Unified Modeling Language (UML) so modelliert werden kann, dass daraus die Berechnung von dynamischen Kenngrößen wie Durchführungszeit oder Ressourcen-Auslastung möglich ist. Zuerst werden die dazu verwendeten UML-Konstrukte vorgestellt. Dann werden die wichtigsten Elemente eines Algorithmus zur Transformation in ein Generalized Stochastic Petri Net (GSPN) präsentiert. Zuletzt werden die Ergebnisse eines Beispiel-Prozesses erläutert.
Forderungen an die Geschäftsprozessmodellierung

Geschäftsprozessmodelle werden aus mehreren Gründen verwendet. Der momentan wichtigste Grund ist die Dokumentation. Ein übersichtliches, graphisches Modell kann das Verständnis und die Abstimmung aller am Prozess Beteiligten erheblich erleichtern und Missverständnissen vorbeugen. In vielen Bereichen hängt sogar die Auftragsvergabe von der sauberen Dokumentation der Geschäftsabläufe ab.

Wenn einiger Aufwand betrieben wurde, einen existierenden oder geplanten Geschäftsprozess zu modellieren, so ist es wünschenswert, wenn dieses Modell über den reinen Dokumentationszweck hinaus genutzt werden kann. In vorliegenden Paper geht es um die Berechnung von zu Einschätzung und Vergleich von Geschäftsprozessen tauglichen Kenngrößen.

Die Schwierigkeit dabei liegt darin, dass das verwendete Modell formalisiert und präzise genug sein muss, um die Berechnung von Kenngrößen überhaupt erst zu ermöglichen. Die direkte Verwendung von syntaktisch und semantisch wohldefinierten Modelliermethoden wie z.B. Petrinetzen oder Prozessalgebren scheitert gewöhnlich daran, dass sie vom Anwender nicht akzeptiert werden, weil die verwendeten Konzepte ihrer Erfahrung völlig fremd sind. Deshalb muss ein Modellierungstool für Geschäftsprozesse Konstrukte verwenden, die in der Begriffswelt des Anwenders vorkommen.

Solche Bausteine benutzt der Prozessmodellierer, um seinen Geschäftsprozess zu modellieren. Allerdings können nicht für alle denkbaren Fälle vorgefertigte Bausteine existieren. Deshalb muss es einem Komponentenmodellierer möglich sein, diese Bausteine zu modi-fizieren oder neue Bausteine zu erstellen.

Im Projekt ERIKA 1 erfolgt die Eingabe und Darstellung des Modells in einer angepassten Version der Unified Modeling Language (UML). Dieses Modell wird dann in ein generalisiertes stochastisches Petrinetz (GSPN) transformiert, welches mit dafür verfügbaren Werkzeugen untersucht werden kann.

Modellierung der Geschäftsprozesse
Abbildung 1: Hauptaktivitätsdiagramm
Abbildung 2: Zustandsdiagramme
Welche Zustände die Ressource vor, während und nach der Durchführung der Aktivität einnehmen muss, wird durch die an der Assoziation angegebene T ätigkeit bestimmt. Für sort orders in Abb. 1 muss ein employee zur Verfügung stehen, der als sorter arbeiten kann. Er soll dabei die Tätigkeit work ausführen. Der Prozessmodellierer kann neue Rollen festlegen. Allerdings darf er nur bereits existieDie Forderungen in Abschnitt 1 zieht nach sich, dass es zwei Modellsichten gibt: die Sicht auf den Ablauf des Geschäftsprozesses und die Sicht auf das Verhalten der Ressourcen. Der Geschäftsprozess wird vom Prozessmodellierer im Hauptaktivit ätsdiagramm modelliert, während die Ressourcen vom Ressourcenmodellierer mittels Treiberaktivit ätsdiagrammen sowie Zustands-und Klassendiagrammen erstellt werden. Diese Ressourcen können mittels definierter Schnittstellen im Hauptaktivitätsdiagramm verwendet werden. Zunächst soll das Hauptaktivitätsdiagramm anhand des Beispieles in Abb. 1 dargestellt werden. Der zu modellierende Geschäftsprozess wurde dort in vier Teilschritte, die Aktivitäten aufgeteilt. Jede Aktivität ist klar von den anderen unterscheidbar und benötigt für ihre Abarbeitung eine gewisse Zeitdauer. Die Aktivitäten sind durch Transitionen miteinander so verbunden, dass Auftr äge, die das System am Anfangsknoten start betreten, zum Endknoten end gelangen können. Die Aufträge können unterschiedliche Pfade durch das System nehmen. Bei Entscheidungsknoten wie nach der Aktivität sort orders können Wahrscheinlichkeiten angegeben werden. Parallele Abläufe sind ebenfalls möglich. Zur Durchführung von Aktivitäten sind normalerweise einige Personen, Hilfsmittel, Werkzeuge u.ä. erforderlich. Diese werden unter dem Begriff Ressourcen zusammengefasst. Ressourcen werden jedoch nicht direkt verwendet. Stattdessen werden Rollen benutzt. Diese geben an, dass für die Durchführung einer Aktivität eine Ressource der angegebenen Klasse, welche die gewünschte Rolle übernehmen kann, vorhanden sein muss. Durch die Ausführung der Aktivität wird der Zustand der Ressource beeinflusst.-rende Klassen und die dort definierten Tätigkeiten verwenden. Er kann sich somit ausch-liesslich auf die Beschreibung des Geschäftsprozesses im Hauptaktivitätsdiagramm kon-zentrieren und benutzt die Ressourcen als " Black Boxes" lediglich über ihre Schnittstellen.1 Das Projekt wird von der Bayerischen Staatsregierung als Teil des Programms: "Informations-und Kommu-nikationstechnik" gefördert. Die anderen Projektpartner sind: Lehrstuhl Wirtschaftsinformatik II der UniversitätErlangen-Nürnberg, MID GmbH und BIK mbH.
4 Transformation in ein GSPN NachdemRessourcentabelle se erst bei der Auswertung festgelegt werden. Eine Modifikation des Hauptaktivitätsdiagrammes ist dafür unnötig. Somit können die Auswirkungen unterschiedlicher Ressourcen ohne großen Aufwand ermittelt werden. In Tab. 1 wurde für Meier die Unterklasse employee with sickness verwendet. Ebenfalls ersichtlich ist, dass alle drei Ressourcen der Klasse employee für die Rolle sorter verwendet werden können. Dies bedeutet, dass die Aktivität sort orders eine Auswahl treffen muss, welche und wie viele Ressourcen sie allokiert. Normalerweise gilt, dass für die Durchführung einer Aktivität genau eine Ressource in der geforderten Rolle vorhanden sein muss. Ein davon abweichendes Verhalten kann mittels einer Auswahltabelle beschrieben werden, die einer Aktivität zugeordnet werden kann. Dort werden die gewünschten Kombinationen von Rollen und ihre Wirkung auf die Durchführungszeit der Aktivität aufgeführt. alle nötigen Informationen in den UML-Diagrammen und Tabellen vorhanden sind, kann mit der Berechnung von Resultaten begonnen werden. Diese wird nicht auf direktem Wege vorgenommen, sondern das Modell wird zunächst in ein Generalized Stochastic Petri Net (GSPN) transformiert. GSPN sind weit verbreitet und es existiert eine Vielzahl von Tools zu ihrer Untersuchung. Außerdem lagen bereits Erfahrungen bei der Transformation von Zustandsdiagrammen zur Beschreibung technischer Systeme vor [KH00]. Die Zustandsdiagramme der Ressourcen und die Aktivitätsdiagramme werden zunächst getrennt transformiert und dann zu einem einzigen Petrinetz verschmolzen. Für jede in der Ressourcentabelle aufgeführte Ressource wird aus dem seiner Klasse zugeordneten Zustandsdiagramm ein Petrinetz erzeugt. Dazu wird das in Algorithmus 1 beschriebene Verfahren verwendet. Dort wird für jeden Zustand eine Stelle im Petrinetz angelegt. Für jede Kante wird eine Transition erzeugt, die über jeweils eine Eingabe-und Ausgabekante mit den Stellen verbunden ist, die ihrem Start-und Zielzustand entsprechen. Bei hierarchischen Zuständen kommen noch Kanten hinzu, die sicherstellen, dass beim Verlassen des Oberzustandes alle Token in den Stellen des Unterzustandes entfernt werden, bzw. die beim Betreten des Oberzustandes in die Anfangsstelle des Unterdiagramms ein Token ablegen. Zustände ¡ £¢ ¥¤ §¦ ©¨do erzeuge für Zustand ¡ eine Stelle im od 2 for Kanten ©¢ ¥¤ ¦ doRessource KlasseRollenENIACcomputerserverMülleremployeesorter, answererMeieremployee with sickness sorterSchulzeemployeesorter, processor3 4 5 6 7 8 od 9 ¤ " %G IH P RQ ¡ S¢ T¤ §¦ VU ¡ liegt in der obersten HierarchieebeneW erzeuge für Kante mit Startzustand ¡ ! #" %$ '& (" und Zielzustand ¡ ) 10 #2 eine Transition 3 im build input arc 4 5 ! #" %$ 6& 7" 68 (3 @9 setzte Multiplizität der neu erzeugten Kante gleich 1 build output arc 4 %3 8 A 0 CB ED F9 10 put start tokens 4 @¤ " %G #H 9 Tabelle 1: Rampe Gabelstapler Fahrer Zeitfaktor 11 13 funct build input arc 4 @ E8 73 9 X1111171 build input arc 4 5 Ff @8 (3 9 od fi . 2 20.518 20 funct build output arc 4 %3 68 i 9 pX 21 erzeuge neue Kante Y rq im 22 if ¡ hat Unterzustände ¤ s! Id e 23 then for S¡ gf h¢ ¤ t! Cd Fe do 24 if ¡ gf ist Startzustand 25 then build output arc 4 5 Ff 58 (3 9
Tabelle 2: Auswahltabelle für Fahrzeug beladen Für eine Aktivität Fahrzeug beladen werden eine Rampe sowie Gabelstapler mit Fahrer benötigt. Mit der Tabelle aus Tab. 2 wird folgendes Verhalten beschrieben: es wird nie mehr als eine Rampe belegt und ein Gabelstapler muss auch immer einen Fahrer haben. Die Verwendung von zwei Gabelstaplern halbiert die Ladezeit. Mehr als zwei können jedoch nicht verwendet werden, weil die Rampe nicht groß genug ist. 1 for 14 erzeuge neue Kante Y E`mit der Multiplizität a P markb c4 5 9 im 15 if ¡ hat Unterzustände ¤ ! Id e 16 then for S¡ gf h¢ ¤ ! Cd Fe do
fi od fi .26 28 funct put start tokens 4 @¤ 9 X
29for ¡ S¢ ¤
do 30 if ¡ ist Startzustand 31 then legeein Token in die zu ¡ gehörende Stelle F Das untere Petrinetz in Abb. 6 ist auf die erläuterte Weise aus dem in Abb. 4 gezeigten Zustandsdiagramm konstruiert worden. Die Transformation der Struktur von Aktivitätsdiagrammen ist unkompliziert, weil sie der Struktur von Petrinetzen sehr ähnlich ist. Deshab sei dazu auf [GGW99] und [Kun00] verwiesen. Für die Verschmelzung mit den Petrinetzen essentiell ist jedoch der Aufbau des Petrinetzes einer einzelnen Aktiviät. Dieser muss die drei Phasen: Allokation, Verwendung und Freigabe der Ressourcen ermöglichen. Im oberen Petrinetz in Abb. 6 ist der Aufbau einer Aktivität beispielhaft dargestellt. Das Feuern einer der Transitionen zwischen prior und during dient dem Allokieren von Ressourcen. Jede dieser Transitionen allokiert alle für die Ausführung der Aktivität nötigen Ressourcen. Die Anzahl der Allokierungs-Transitionen hängt sowohl von der in der Ressourcentabelle angegebenen Anzahl der verfügbaren Ressourcen als auch von dem in der Auswahltabelle definierten Allokationsmuster ab. Für jede sich daraus ergebende Alternative existiert eine Transition. Nach dem Feuern einer Auswahl-Transition wird auf das Feuern der zeitbehafteten Transition zwischen during und after gewartet. Diese Transition hat eine Feuerrate , die dem Kehrwert der an der Aktivität angegebenen Zeit entspricht. Das Feuern dieser Transition gibt alle allokierten Ressourcen frei. Um dies korrekt durchführen zu können, ist noch eine Hilfs-Stelle pro Ressource erforderlich, die in Abb. 6 nicht dargestellt ist. Wie die Verschmelzung durchgeführt wird, ist in Abb. 6 angedeutet. Durch die Tätigkeit work in Abb. 3 ist festgelegt, dass T2 mit T7 und T1 mit T5 verschmolzen werden muss. Alle Kanten von T2 und T1 werden kopiert und auf T7 bzw. T5 umgelenkt. Wenn die Transitionen der Zustandsdiagramme mit allen dafür in Frage kommenden Transitionen der Aktivitätsdiagramme verschmolzen worden sind, werden sie entfernt. Nun liegt ein einziges, nicht-hierarchisches Petrinetz vor, welches mit verschiedenen Methoden untersucht werden kann. Um dies um dies durchführen zu können, sind noch zusätzliche Elemente im Petrinetz nötig, die Aufträge mit einer bestimmten Rate in das System senden und sie nach dem Durchlauf entfernen. Ausserdem muss die Anzahl der gleichzeitig im System befindlichen Aufträge beschränkt werden, weil der Zustandsraum sonst unendlich groß werden würde. Die Wahl der richtigen Anzahl ist einerseits für die Genauigkeit der Ergebnisse sowie andererseits die Größe des Zustandsraumes und damit die praktische Berechenbarkeit von Bedeutung. Dies im folgenden verdeutlicht werden. Für das in diesem Paper vorgestellte Beispiel wurde zunachst eine Ankunftsrate der Aufträge von 1/h gewählt und die maximale Anzahl von Aufträgen auf 25 gesetzt. Es wurden 5 verschiedene, in Tab. 3 angegebene Varianten für die Rollen/Ressourcenzuordnung der Klasse employee gewählt. Die Rolle Server wurde dabei ignoriert. Die vorgestellte Modellierungsmethode ermöglicht es dem Prozessmodellierer, den Geschäftsprozess aus der Sicht des Ablaufes zu modellieren. Er muss sich nicht um Details des Verhaltens von Ressourcen kümmern, sondern kann diese aus einer vorgefertigten Bibliothek auswählen. Die Ressourcenbibliothek kann durch den Ressourcenmodellierer bei Bedarf leicht erweitert werden. Durch die Verwendung von Rollen wird die Untersuchung des Prozessverhaltens bei verschiedenen Ressourcenkonstellationen erheblich vereinfacht. Das verwendete GSPN-Lösungstool weist prinzipbedingt zwei bekannte Schwächen auf: die Zustandsraumexplosion und die Beschränkung auf exponentiell verteilte Zeiten. Die in Kapitel 5 vorgestellte Begrenzung der Aufträge im System schränkt den Zustandsraum ein, verfälscht aber gleichzeitig die Ergebnisse bei kritischer Belastung. Der Modellierer hat dadurch aber die Möglichkeit, sich systematisch einem akzeptabelen Kompromiss zwischen Genauigkeit und Rechenaufwand anzunähern. Um leichter verschiedene Auswertetools, welche die erwähnten Schwächen abgemildern bzw. umgehen (z.B. durch Simulation, Phasenverteilungen, effizientere Speichernutzung etc.), leichter anbinden zu können, wird das generierte Petrinetz in der Petri Netz Markup Language (PNML) (siehe [JKW00]) gespeichert. Dies soll auch die Verwendung von Tools zur Untersuchung qualitativer Aspekte der Geschäftsprozesse ermöglichen. Die Transformationsalgorithmen für Aktivitäts-und Zustandsdiagramme wurden bereits implementiert. Als nächste Aufgabe steht die Verschmelzung hierarchischer Zustandsdiagramme an. Diese können dazu verwendet werden, einer Aktivität bereits allokierte Ressourcen während der Ausführung zu entziehen, was für die Modellierung von Störungen im Geschäftsablauf notwendig ist.Die Erklärung für dieses Verhalten besteht darin, dass die maximal mögliche Durchsatz-rate des Systems bei 1/45 min liegt. Höhere Ankunftsraten können damit nicht zu einemDas momentan verwendeten Werkzeug PANDA (siehe [AK00]) ermöglicht es, die Warte-schlangenlänge von Aufträgen vor den Aktivitäten und die davon abhängende Wartezeit 0.7 0.8 stabilen Systemzustand führen und das Tool kann somit auch keine sinnvollen Ergebnisse answer process manually sort orders berechen.sowie die Auslastung von Ressourcen zu berechnen. Dazu wird der komplette Zustands-raum aufgestellt, in eine Markovkette umgewandelt und für den stationären Fall gelöst Im Bereich zwischen 1/45 min und 1/50 min kommt es zu Verfälschungen des Ergebnisses 0.6 durch die Beschränkung der Auftragsanzahl im System. Ab 1/50 min ist kaum noch eine(siehe [MBC 95]). Abweichung vorhanden. 0.4 Auslastung 0.50.3 6 Schlussfolgerungen und Ausblick0.20.10e1e1 e2e1 e2e1 e2 e3e1 e2 e3ein employeezwei employeesdrei employeesAbbildung 7: Auslastung der employeesRessource KlasseRollene1employee sorter, processor, answerere1employee sorter, processor, answerere2employee sorter, processor, answerere1employee sorter, answerere2employee processore1employee sorter, processor, answerere2employee sorter, processor, answerere3employee sorter, processor, answerere1employee sortere2employee processore3employee answererTabelle 3: Ressourcentabelle für das BeispielIn Abb. 7 sind die Auslastung der jeweils eingesetzten Mitarbeiter sowie die Aktivität,bei der sie jeweils beschäftigt sind, zu erkennen. Der Fall, in dem nur ein employee alle32 drei Rollen wahrnehmen muss, ist der kritischste und wurde deshalb weiter untersucht. if ¡ F hat Unterzustände ¤ ! Id e 33 Dabei wurden die Ankunftsraten auf 1/50 min, 1/45 min, 1/40 min, 1/30 min und 1/20 min then put start tokens 4 #¤ ! Id e 9 fi fi od . verwendet. (a) Wartezeiten vor den Aktivitäten (b) Auswirkung der BegrenzungAbb. 8(a) zeigt die Zeiten, die ein Auftrag im Mittel vor einer Aktivität warten muss. Abb.Algorithmus 1: Transformation eines Zustandsdiagrammes in ein Petrinetz u Zustandsdiagramm Petrinetz liefert die momentane Anzahl von Marken in der Stelle zurück w (x y 6 E 7 und 1/40 min schwingt sich die errechnete Rate auf 1/45 min ein. Ab 1/50 min besteht Übereinstimmung zwischen gewünschter und errechneter Rate. v 8(b) zeigt das Verhältnis von gewünschter Ankunftsrate und der sich durch die Begrenzung der Auftragszahl ergebenden tatsächlichen Ankunftsrate. Für die Raten 1/20 min, 1/30 min Abbildung 8: Verhalten bei Überlastung des Systems
Abbildung 6: Petrinetz für employee with sickness
PANDA -Petri Net ANalysis and Design Assistant Users Guide SAllmaier DKreische 2000 Institut für Informatik 3 ; FAU Erlangen-Nürnberg Technical report Zur semantischen Analyse der dynamischen Modelle von UML mit Petri-Netzen ThomasGehrke UrsulaGoltz HeikeWehrheim Proceedings of The 6th Symposium on Development and Operation of Complex Automation Systems ESchnieder The 6th Symposium on Development and Operation of Complex Automation Systems 1999 OMG Unified Modeling Language Specification 2001 Version 1.4 The Petri Net Markup Language MJungel EKindler MWeber 7/2000 Proceedings of AWPN 2000 -7thWorkshop Algorithmen und Werkzeuge für Petrinetze SPhilippi AWPN 2000 -7thWorkshop Algorithmen und Werkzeuge für Petrinetze 2000 Institute for Computer Science, University of Koblenz, Germany Research Report UML Extensions for Quantitative Analysis KonstantinosKosmidis GaborHuszerl Proceedings UML 2000 Workshop "Dynamic Behaviour in UML Models: Semantic Questions UML 2000 Workshop "Dynamic Behaviour in UML Models: Semantic Questions Insitut für Informatik 2000 Performance and Dependability in Business Process Modeling DKreische Proc. 5th Int. Workshop on Performability Modeling of Computer and Communication Systems (PMCCS 5) Arbeitsberichte des Instituts für Informatik 5th Int. Workshop on Performability Modeling of Computer and Communication Systems (PMCCS 5)
Erlangen, Germany
 2001 FAU Erlangen-Nürnberg Design und Implementierung einer Komponente zur Transformation von UML-Aktivitätsdiagrammen in stochastische Petrinetze MKunert Studienarbeit 2000 FAU Erlangen-Nürnberg Institut für Informatik 3 Modelling with generalized stochastic Petri nets MAjmone Marsan GBalbo GConte SDonatelli GFranceschinis Wiley, Series in Parallel Computing 1995