In diesem Paper wird gezeigt, wie ein Gescha¨ftsprozess mit Hilfe der Unified Modeling Language (UML) so modelliert werden kann, dass daraus die Berechnung von dynamischen Kenngro¨ßen wie Durchfu¨hrungszeit oder Ressourcen-Auslastung mo¨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) pra¨sentiert. Zuletzt werden die Ergebnisse eines Beispiel-Prozesses erla¨utert.
fizieren oder neue Bausteine zu erstellen.
Im Projekt ERIKA1 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 dafu¨r verfu¨gbaren Werkzeugen untersucht werden kann. 2
Die Forderungen in Abschnitt 1 zieht nach sich, dass es zwei Modellsichten gibt: die Sicht auf den Ablauf des Gescha¨ftsprozesses und die Sicht auf das Verhalten der Ressourcen. Der Gescha¨ftsprozess wird vom Prozessmodellierer im Hauptaktivita¨tsdiagramm modelliert, wa¨hrend die Ressourcen vom Ressourcenmodellierer mittels Treiberaktivita¨tsdiagrammen sowie Zustands- und Klassendiagrammen erstellt werden. Diese Ressourcen ko¨nnen mittels definierter Schnittstellen im Hauptaktivita¨tsdiagramm verwendet werden. Zuna¨chst soll das Hauptaktivita¨tsdiagramm anhand des Beispieles in Abb. 1 dargestellt werden. Der zu modellierende Gescha¨ftsprozess wurde dort in vier Teilschritte, die Aktivita¨ten aufgeteilt. Jede Aktivita¨t ist klar von den anderen unterscheidbar und beno¨tigt fu¨r ihre Abarbeitung eine gewisse Zeitdauer. Die Aktivita¨ten sind durch Transitionen miteinander so verbunden, dass Auftra¨ge, die das System am Anfangsknoten start betreten, zum Endknoten end gelangen ko¨nnen. Die Auftra¨ge ko¨nnen unterschiedliche Pfade durch das System nehmen. Bei Entscheidungsknoten wie nach der Aktivita¨t sort orders ko¨nnen Wahrscheinlichkeiten angegeben werden. Parallele Abla¨ufe sind ebenfalls mo¨glich. Zur Durchfu¨hrung von Aktivita¨ten sind normalerweise einige Personen, Hilfsmittel, Werkzeuge u.a¨. erforderlich. Diese werden unter dem Begriff Ressourcen zusammengefasst. Ressourcen werden jedoch nicht direkt verwendet. Stattdessen werden Rollen benutzt. Diese geben an, dass fu¨r die Durchfu¨hrung einer Aktivita¨t eine Ressource der angegebenen Klasse, welche die gewu¨nschte Rolle u¨bernehmen kann, vorhanden sein muss. Durch die Ausfu¨hrung der Aktivita¨t wird der Zustand der Ressource beeinflusst. Welche Zusta¨nde die Ressource vor, wa¨hrend und nach der Durchfu¨hrung der Aktivita¨t einnehmen muss, wird durch die an der Assoziation angegebene Ta¨tigkeit bestimmt. Fu¨r sort orders in Abb. 1 muss ein employee zur Verfu¨gung stehen, der als sorter arbeiten kann. Er soll dabei die Ta¨tigkeit work ausfu¨hren.
Der Prozessmodellierer kann neue Rollen festlegen. Allerdings darf er nur bereits existierende Klassen und die dort definierten Ta¨tigkeiten verwenden. Er kann sich somit auschliesslich auf die Beschreibung des Gescha¨ftsprozesses im Hauptaktivita¨tsdiagramm konzentrieren und benutzt die Ressourcen als ”Black Boxes“ lediglich u¨ber ihre Schnittstellen.
1Das Projekt wird von der Bayerischen Staatsregierung als Teil des Programms: ”Informations- und Kommunikationstechnik” gefo¨rdert. Die anderen Projektpartner sind: Lehrstuhl Wirtschaftsinformatik II der Universita¨t Erlangen–Nu¨rnberg, MID GmbH und BIK mbH.
3
Zur Beschreibung der Zusta¨nde einer Ressource und der mo¨glichen U¨ berga¨nge dazwischen bietet sich das Zustandsdiagramm an. Abb. 2 zeigt die Zustandsdiagramme der Klassen employee und server.
(a) employee
(b) server
Eine Ressource der Klasse employee startet im Zustand idle. Sie wechselt genau dann in den Zustand busy, wenn das Ereignis idle to busy eintritt. Die Namen der Ereignisse werden immer nach dem Muster Startzustand nach Zielzustand gebildet, so dass sie in den Zustandsdiagrammen u¨blicherweise ausgeblendet werden ko¨nnen. In Abschnitt 2 wurde bereits angedeutet, dass die Zustandsu¨berga¨nge der Ressourcen mittels der Ta¨tigkeiten im Aktivita¨tsdiagramm gesteuert werden. Diese werden im Klassendiagramm definiert. Abb. 3 zeigt das Klassendiagramm fu¨r employee. Dort wird eine Assoziation work zwischen den Klassen employee und ActionState angelegt. Dies definiert die Ta¨tigkeit work, die im Hauptaktivita¨tsdiagramm verwendet wurde (siehe Abb. 1). Das Anlegen solcher Assoziationen zu Objekten erweitert das Metamodell der UML-Aktivita¨tsdiagramme (siehe [Gro01], Seite 2-177) . Dies ist notwendig, um Ressourcen und Aktivita¨ten mittels einer Assoziation verbinden zu ko¨nnen.
Jede Ta¨tigkeits-Assoziation besitzt eine gleichnamige Assoziationsklasse mit drei Attributen, die den Zustand der Ressource vor, wa¨hrend und nach der Ausfu¨hrung der Aktivita¨t angeben. Jede Ressourcen-Klasse besitzt genau ein Zustandsdiagramm. Nur dort vorkommende Zusta¨nde du¨rfen in der Assoziationsklasse verwendet werden. In Abb. 3 ist der Klasse employee das Zustandsdiagramm aus Abb. 2(a) zugeordnet. In der Assoziationsklasse von work wird festgelegt, dass employee vor der Ausfu¨hrung einer Aktivita¨t unter Verwendung dieser Ta¨tigkeit im Zustand idle, wa¨hrend im Zustand busy und danach wieder im Zustand idle sein soll.
Wie aus Abb. 3 hervorgeht, ist es mo¨glich, Unterklassen von Ressourcen anzulegen. Dies dient dazu, das Verhalten von Ressourcen abwandeln zu ko¨nnen, ohne das Hauptaktivita¨tsdiagramm anpassen zu mu¨ssen. Die abgeleiteten Klasse employee with sickness kann im Hauptaktivita¨tsdiagramm weiterhin mit der Ta¨tigkeit work verwendet werden. Um dies zu erreichen, muss ein Zustand im Zustandsdiagramm der Unterklasse das gesamte Zustandsdiagramm der Oberklasse als Verfeinerung enthalten. In Abb. 4 ist dies bei dem Zustand well der Fall. Um zwischen den neuen Zusta¨nden well und sick wechseln zu ko¨nnen, wurden die Ta¨tigkeiten get well und get sick erstellt. Diese ko¨nnen nun in Aktivita¨tsdiagrammen verwendet werden.
Abbildung 4: Zustandsdiagramm fu¨r die Klasse employee with sickness Oftmals ist die Verwendung von abgeleiteten Klassen durch den Prozessmodellierer gar nicht gewu¨nscht, weil die neuen Ta¨tigkeiten und die zugeho¨rigen Aktivita¨ten den eigentlichen Gescha¨ftsprozess u¨berfrachten. Das ”Eigenleben“ der Ressource sollte von ihm nicht modelliert werden mu¨ssen, damit er sie weiter als ”Black Box“ betrachten kann. Dem Ressourcenmodellierer hingegen stehen dafu¨r die Treiberaktivita¨tsdiagramme zur Verfu¨gung. Jeder Klasse kann genau ein solches Treiberaktivita¨tsdiagramm zugeordnet werden. Darin kann nur die zugeho¨rige Ressource verwendet werden. Deshalb ist die Verwendung von Rollen hier sinnlos. Im Unterschied zum Hauptaktivita¨tsdiagramm ist ein Endzustand nicht notwendig, wenn die Ressource fortlaufend zyklisch zwischen ihren Zusta¨nden wechseln soll.
Abbildung 5: Treiberaktivita¨tsdiagramm fu¨r die Klasse employee with sickness Im Hauptaktivita¨tsdiagram wird also modelliert, welche Ressourcen in welcher Rolle beno¨tigt werden. In den Klassen-, Zustands- und Treiberaktivita¨tsdiagrammen wird das Verhalten dieser Ressourcen beschrieben. Nun muss noch angegeben werden, welche Ressourcen konkret zur Verfu¨gung stehen und welche Rolle sie u¨bernehmen ko¨nnen. Bei dieser Zuordnung ist es mo¨glich, die im Hauptaktivita¨tsdiagramm angegebene Klasse durch eine ihrer Unterklassen zu ersetzen. Dadurch muss die letztendlich verwendete Klas
Schulze
computer employee employee with sickness employee
server sorter, answerer sorter sorter, processor
se erst bei der Auswertung festgelegt werden. Eine Modifikation des Hauptaktivita¨tsdiagrammes ist dafu¨r unno¨tig. Somit ko¨nnen die Auswirkungen unterschiedlicher Ressourcen ohne großen Aufwand ermittelt werden. In Tab. 1 wurde fu¨r Meier die Unterklasse employee with sickness verwendet.
Ebenfalls ersichtlich ist, dass alle drei Ressourcen der Klasse employee fu¨r die Rolle sorter verwendet werden ko¨nnen. Dies bedeutet, dass die Aktivita¨t sort orders eine Auswahl treffen muss, welche und wie viele Ressourcen sie allokiert.
Normalerweise gilt, dass fu¨r die Durchfu¨hrung einer Aktivita¨t genau eine Ressource in der geforderten Rolle vorhanden sein muss. Ein davon abweichendes Verhalten kann mittels einer Auswahltabelle beschrieben werden, die einer Aktivita¨t zugeordnet werden kann. Dort werden die gewu¨nschten Kombinationen von Rollen und ihre Wirkung auf die Durchfu¨hrungszeit der Aktivita¨t aufgefu¨hrt.
Fu¨r eine Aktivita¨t Fahrzeug beladen werden eine Rampe sowie Gabelstapler mit Fahrer beno¨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 ko¨nnen jedoch nicht verwendet werden, weil die Rampe nicht groß genug ist. 4
Nachdem alle no¨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 zuna¨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 Aktivita¨tsdiagramme werden zuna¨chst getrennt transformiert und dann zu einem einzigen Petrinetz verschmolzen. Fu¨r jede in der Ressourcentabelle aufgefu¨hrte Ressource wird aus dem seiner Klasse zugeordneten Zustandsdiagramm ein Petrinetz erzeugt. Dazu wird das in Algorithmus 1 beschriebene Verfahren verwendet. Dort wird fu¨r jeden Zustand eine Stelle im Petrinetz angelegt. Fu¨r jede Kante wird eine Transition erzeugt, die u¨ber jeweils eine Eingabe- und Ausgabekante mit den Stellen verbunden ist, die ihrem Start- und Zielzustand entsprechen. Bei hierarchischen Zusta¨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. und Zielzustand
eine eine Stelle im od "#$%$&! (’ build input arc ! Transition im
Zusta¨nde do erzeuge fu¨r Zustand
Kanten do erzeuge fu¨r Kante mit Startzustand setzte Multiplizita¨t der neu erzeugten Kante gleich 1 1 for 2 for 3 4 5 6 7 8 od
Algorithmus 1: Transformation eines Zustandsdiagrammes in ein Petrinetz Das untere Petrinetz in Abb. 6 ist auf die erla¨uterte Weise aus dem in Abb. 4 gezeigten Zustandsdiagramm konstruiert worden.
Die Transformation der Struktur von Aktivita¨tsdiagrammen ist unkompliziert, weil sie der Struktur von Petrinetzen sehr a¨hnlich ist. Deshab sei dazu auf [GGW99] und [Kun00] verwiesen. Fu¨r die Verschmelzung mit den Petrinetzen essentiell ist jedoch der Aufbau des Petrinetzes einer einzelnen Aktivia¨t. Dieser muss die drei Phasen: Allokation, Verwendung und Freigabe der Ressourcen ermo¨glichen. Im oberen Petrinetz in Abb. 6 ist der Aufbau einer Aktivita¨t beispielhaft dargestellt. Das Feuern einer der Transitionen zwischen prior und during dient dem Allokieren von Ressourcen. Jede dieser Transitionen allokiert alle fu¨r die Ausfu¨hrung der Aktivita¨t no¨tigen Ressourcen. Die Anzahl der Allokierungs-Transitionen ha¨ngt sowohl von der in der Ressourcentabelle angegebenen Anzahl der verfu¨gbaren Ressourcen als auch von dem in der Auswahltabelle definierten Allokationsmuster ab. Fu¨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 Aktivita¨t angegebenen Zeit entspricht. Das Feuern dieser Transition gibt alle allokierten Ressourcen frei. Um dies korrekt durchfu¨hren zu ko¨nnen, ist noch eine Hilfs-Stelle pro Ressource erforderlich, die in Abb. 6 nicht dargestellt ist.
Wie die Verschmelzung durchgefu¨hrt wird, ist in Abb. 6 angedeutet. Durch die Ta¨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 dafu¨r in Frage kommenden Transitionen der Aktivita¨tsdiagramme verschmolzen worden sind, werden sie entfernt. Nun liegt ein einziges, nicht-hierarchisches Petrinetz vor, welches mit verschiedenen Methoden untersucht werden kann.
Das momentan verwendeten Werkzeug PANDA (siehe [AK00]) ermo¨glicht es, die Warteschlangenla¨nge von Auftra¨gen vor den Aktivita¨ten und die davon abha¨ngende Wartezeit sowie die Auslastung von Ressourcen zu berechnen. Dazu wird der komplette Zustandsraum aufgestellt, in eine Markovkette umgewandelt und fu¨r den stationa¨ren Fall gelo¨st (siehe [MBC 95]).
Um dies um dies durchfu¨hren zu ko¨nnen, sind noch zusa¨tzliche Elemente im Petrinetz no¨tig, die Auftra¨ge mit einer bestimmten Rate in das System senden und sie nach dem Durchlauf entfernen. Ausserdem muss die Anzahl der gleichzeitig im System befindlichen Auftra¨ge beschra¨nkt werden, weil der Zustandsraum sonst unendlich groß werden wu¨rde. Die Wahl der richtigen Anzahl ist einerseits fu¨r die Genauigkeit der Ergebnisse sowie andererseits die Gro¨ße des Zustandsraumes und damit die praktische Berechenbarkeit von Bedeutung. Dies im folgenden verdeutlicht werden.
Fu¨r das in diesem Paper vorgestellte Beispiel wurde zunachst eine Ankunftsrate der Auftra¨ge von 1/h gewa¨hlt und die maximale Anzahl von Auftra¨gen auf 25 gesetzt. Es wurden 5 verschiedene, in Tab. 3 angegebene Varianten fu¨r die Rollen/Ressourcenzuordnung der Klasse employee gewa¨hlt. Die Rolle Server wurde dabei ignoriert. In Abb. 7 sind die Auslastung der jeweils eingesetzten Mitarbeiter sowie die Aktivita¨t, bei der sie jeweils bescha¨ftigt sind, zu erkennen. Der Fall, in dem nur ein employee alle drei Rollen wahrnehmen muss, ist der kritischste und wurde deshalb weiter untersucht. Dabei wurden die Ankunftsraten auf 1/50 min, 1/45 min, 1/40 min, 1/30 min und 1/20 min verwendet.
Abb. 8(a) zeigt die Zeiten, die ein Auftrag im Mittel vor einer Aktivita¨t warten muss. Abb. 8(b) zeigt das Verha¨ltnis von gewu¨nschter Ankunftsrate und der sich durch die Begrenzung der Auftragszahl ergebenden tatsa¨chlichen Ankunftsrate. Fu¨r die Raten 1/20 min, 1/30 min und 1/40 min schwingt sich die errechnete Rate auf 1/45 min ein. Ab 1/50 min besteht U¨ bereinstimmung zwischen gewu¨nschter und errechneter Rate.
0.8 0.7 0.6 0.5 Die Erkla¨rung fu¨r dieses Verhalten besteht darin, dass die maximal mo¨gliche Durchsatzrate des Systems bei 1/45 min liegt. Ho¨here Ankunftsraten ko¨nnen damit nicht zu einem stabilen Systemzustand fu¨hren und das Tool kann somit auch keine sinnvollen Ergebnisse berechen.
Im Bereich zwischen 1/45 min und 1/50 min kommt es zu Verfa¨lschungen des Ergebnisses durch die Beschra¨nkung der Auftragsanzahl im System. Ab 1/50 min ist kaum noch eine Abweichung vorhanden. 6
Die vorgestellte Modellierungsmethode ermo¨glicht es dem Prozessmodellierer, den Gescha¨ftsprozess aus der Sicht des Ablaufes zu modellieren. Er muss sich nicht um Details des Verhaltens von Ressourcen ku¨mmern, sondern kann diese aus einer vorgefertigten Bibliothek auswa¨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-Lo¨sungstool weist prinzipbedingt zwei bekannte Schwa¨chen auf: die Zustandsraumexplosion und die Beschra¨nkung auf exponentiell verteilte Zeiten. Die in Kapitel 5 vorgestellte Begrenzung der Auftra¨ge im System schra¨nkt den Zustandsraum ein, verfa¨lscht aber gleichzeitig die Ergebnisse bei kritischer Belastung. Der Modellierer hat dadurch aber die Mo¨glichkeit, sich systematisch einem akzeptabelen Kompromiss zwischen Genauigkeit und Rechenaufwand anzuna¨hern.
Um leichter verschiedene Auswertetools, welche die erwa¨hnten Schwa¨chen abgemildern bzw. umgehen (z.B. durch Simulation, Phasenverteilungen, effizientere Speichernutzung etc.), leichter anbinden zu ko¨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 Gescha¨ftsprozesse ermo¨glichen. Die Transformationsalgorithmen fu¨r Aktivita¨ts- und Zustandsdiagramme wurden bereits implementiert. Als na¨chste Aufgabe steht die Verschmelzung hierarchischer Zustandsdiagramme an. Diese ko¨nnen dazu verwendet werden, einer Aktivita¨t bereits allokierte Ressourcen wa¨hrend der Ausfu¨hrung zu entziehen, was fu¨r die Modellierung von Sto¨rungen im Gescha¨ftsablauf notwendig ist. [AK00] [GGW99] [Gro01] [JKW00] [KH00] [Kre01] [Kun00]
S. Allmaier and D. Kreische. PANDA — Petri Net ANalysis and Design Assistant Users Guide. Technical report, Institut fu¨r Informatik 3, FAU Erlangen-Nu¨rnberg, 2000. Thomas Gehrke, Ursula Goltz, and Heike Wehrheim. Zur semantischen Analyse der dynamischen Modelle von UML mit Petri-Netzen. In E. Schnieder, editor, Proceedings of The 6th Symposium on Development and Operation of Complex Automation Systems, 1999.
Object Management Group. OMG Unified Modeling Language Specification, 2001. Version 1.4.