freytag@dhbw-karlsruhe.de, andreas@eckleder.de
f r die nanzielle und logistische Unters tzung der Ausrichtung. f r Nachwuchswissenschaftler(innen), Erfahrungen bei einer wissenschaftlichen
(DHBW). Veranstalter ist wie immer die Fachgruppe Petrinetze und verwandte nach 1996 in Karlsruhe statt, erstmals an der Dualen Hochschule Baden-W rttemberg die Vortr ge eine gute Grundlage f r rege Diskussionen bieten. (AWPN) ein gemeinsames Forum f r Entwickler und Anwender petrinetzbasierter
prozess fand wie auch in den vergangenen Jahren nicht statt. Wir ho en, dass
III
Performance and Qos Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Net Agents for Activity Handling in a WFMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Pro ling Services with Static Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Nodes in Work ow Nets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Decomposition into open nets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Modellierung und Mining Kollaborativer Learn ows . . . . . . . . . . . . . . . . . . . . . . . . . 1
Emphasizing the Early Design Phases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Modellierung und Mining Kollaborativer Learnflows Robin Bergenthum, Jo¨rg Desel, Andreas Harrer, Sebastian Mauser
Fachgebiet Informatik, Katholische Universita¨t Eichsta¨tt-Ingolstadt
vorname.name@ku-eichstaett.de Zusammenfassung Basierend auf Ideen aus dem Bereich der Gescha¨ftsprozessmodellierung werden zwei Ansa¨tze zur Modellierung kollaborativer learnflows entwickelt und es wird gezeigt wie sich entsprechende Lernprozessmodelle automatisch aus Protokolldateien von Lernsystemen erzeugen lassen. 1
Einleitung
Wa¨hrend sich die Repra¨sentation, Verarbeitung und Computerunterstu¨tzung von
Gescha¨ftsprozessen etabliert hat und methodisch gereift ist, werden hingegen auf dem
verwandten Gebiet fu¨r Lehr- / Lernprozesse erst in den letzen Jahren versta¨rkte
Anstrengungen unternommen. Aus diesem Anlass diskutierten wir in [
Von besonderem Interesse ist dabei, wie kollaborative Arbeit bzw. Lernen
geeignet repra¨sentiert werden ko¨nnen und welche Rollen bzw. Gruppenzusammensetzungen
fu¨r einzelne Aktivita¨ten notwendig bzw. erwu¨nscht sind. Dabei sind insbesondere die
Spezifika von kollaborativen Lehr- / Lernprozessen gegenu¨ber Gescha¨fts- prozessen
zu beru¨cksichtigen, was eine direkte Nutzung existierender Ansa¨tze aus dem Bereich
der Gescha¨ftsprozessmodellierung (z.B. [
Im Folgenden werden wir aufbauend auf den Konzepten der
Gescha¨ftsprozessmodellierung aus [
Einen ersten entsprechenden Modellierungsansatz haben wir schon in [
Da die Akteure und insbesondere deren Rollenwechsel bei der Lernprozessmodellierung eine zentrale Rolle spielen, schlagen wir hier vor diesen Ansatz zu verfeinern, indem wir die dynamische Rollenbelegung der Akteure explizit durch ein Zustandsdiagramm modellieren (natu¨rlich lassen sich hier auch hierarchische Rollenbeziehungen darstellen). Ein Akteur kann seine Rolle, i.e. seinen Zustand, a¨ndern, wenn er eine Aktivita¨t durchfu¨hrt. Rollenwechsel finden also durch Synchronisation der U¨ berga¨nge der Zustandsdiagramme mit Aktivita¨ten des Prozessmodells statt.
In einem zweiten Modellierungsvorschlag gehen wir noch einen Schritt weiter,
indem wir den globalen Akteurspool auflo¨sen und die Zustandsdiagramme, welche die
Akteure repra¨sentieren, als Marken in den Kontrollfluss des Prozessmodells einbetten.
Dadurch la¨sst sich insbesondere der Fortschritt der Akteure innerhalb des
Lernprozesses durch ihre ”Aufenthaltsorte“modellieren. Bei diesem Ansatz haben wir uns von
den existierenden Ideen zur Modellierung mit ”Netzen in Netzen“inspirieren lassen.
Insbesondere gibt es Arbeiten (z.B. [
Die zwei Modellierungsansa¨tze fokussieren auf die Repra¨sentation dynamischer Rollen und beru¨cksichtigen (Lern-) Gruppen nur implizit durch kollaborative Aktivita¨ten. Wir geben daher anschließend einen Ausblick auf Erweiterungen der zwei Ansa¨tze zur expliziten Modellierung von Gruppen.
Zusa¨tzlich zu den Modellierungsansa¨tzen diskutieren wir die Mo¨glichkeiten und das
Vorgehen fu¨r eine automatisierte Synthese von solchen Modellen aus realen
Protokollinstanzen als Ansatz zum collaboration flow mining. Hierbei erweitern wir die in [
In Kapitel 2 stellen wir die neuen Modellierungsansa¨tze an einem Beispiel, welches
schon in [
Modellierungsansa¨ tze
Als Beispiel betrachten wir im Folgenden Gruppen von je drei Schu¨lern, die unterstu¨tzt
durch das Tool FreeStyler (www.collide.info) lernen, wie sich verschiedene Faktoren
(z.B. Lichtverha¨ltnisse, CO2-Gehalt, ...) auf das Wachstum von Pflanzen auswirken (fu¨r
Details vgl. [
Erstes Modell: Das Lernprozessmodell in Abbildung 1 stellt den Prozessaspekt des Beispiels dar, der durch einen Zustandsautomaten, der ein Rollendiagramm repra¨sentiert, in Abbildung 2 erga¨nzt wird. Eine Aktivita¨t im Prozessmodell kann nur dann durchgefu¨hrt werden, falls die an der Transition angeschriebene Anzahl von Rollen im globalen Akteurspool vorhanden ist: beispielsweise erfordert die kollaborative Aktivita¨t Planung (Pl) 2 Akteure in der Rolle Schu¨ler. Beim Schalten der Transition werden fu¨r die betreffenden Akteure Rollenvera¨nderungen vorgenommen, die im Automatenmodell einem Zustandswechsel mit dem Transitionsnamen als Eingabezeichen entsprechen; in unserem Beispiel gehen also durch die Planungsaktivita¨t beide Schu¨ler in die Rolle Modellierer u¨ber. Als Konvention zur Vereinfachung des Zustandsautomaten setzen wir voraus, dass bei Aktionen, die im Diagramm nicht explizit einen Rollenwechsel verursachen, die bisherige Rolle erhalten bleibt: Die Aktivita¨t Modellierung (Mo) fu¨hrt fu¨r einen Akteur, der sich in der Rolle Modellierer befindet, keinen Rollenwechsel herbei und kann deshalb im Diagramm entfallen.
3 Schüler
Ei 2 Schüler
Pl
Fr Schüler Abbildung 1. Erstes Modell: Prozessfluss repra¨sentiert als Stellen-Transitions-Petrinetz mit Rollenbeschriftungen
Der Lernfortschritt und die Lernhistorie einzelner Akteure werden bei diesem Modellierungsansatz in das
Rollendiagramm einkodiert: Beispielsweise wird durch Pl Model ierer E1,E2,Da Modl iererEx Ausfu¨hren von Experiment1 (E1) ein Lernfortschritt durch einen Rollenwechsel erreicht, der ein Ausfu¨hren Schüler von Experiment2 (E2) und Daten (Da) verhindert. DieFr Protokol ant E1,E2,Da Protokol antEx se Repra¨sentation fortschrittsabha¨ngiger Aspekte wird im folgenden alternativen Modellierungsansatz eleganAbbildung 2. Erstes Modell: ter adressiert.
Rollendiagramm repra¨sen- Zweites Modell: Die Abbildungen 3 und 4 stellen tiert als Zustandsautomat in a¨hnlicher Form den Prozessaspekt und den Rollenaspekt im alternativen Modellierungsansatz dar. Hierbei wird fu¨r die Prozessrepra¨sentation ein hierarchisches Petrinetz verwendet, bei dem die Marken selbst Rollenautomaten sind, die jeweils einen Akteur repra¨sentieren, dessen Rolle durch seinen aktuellen Zustand dargestellt wird und dessen Fortschritt im Lernprozess durch die Platzierung im Netz erkennbar ist. In a¨hnlicher Weise wie im ersten Modellierungsansatz wird eine Aktivita¨t durchgefu¨hrt, sofern mindestens soviele Akteure in Rollen, wie an der Transition angeschrieben, vorhanden sind, allerdings mu¨ssen diese Akteure nun lokal im Vorbereich der Transition vorhanden sein. Die Kantengewichte geben hierbei an wieviele Akteure aus welcher Stelle beno¨tigt werden und in welche Stellen wieviele Akteure fortschreiten (dabei muss die Anzahl der Akteure fu¨r jede Transition erhalten bleiben: ”Ma¨nnchenerhaltungssatz “). Fu¨r den Kontrollfluss darf das Modell zusa¨tzlich auch Stellen mit schwarzen Marken enthalten (wie zwischen den Transitionen Planung und Modellierung).
Durch die Lokalisation jedes Akteurs als Marke im Prozessnetz sind fortschrittsabha¨ngige Aspekte bereits explizit im Petrinetz repra¨sentiert. Deshalb ist nun beispielsweise ein Rollenwechsel beim Ausfu¨hren von Experiment1 (E1) nicht mehr no¨tig, was
2 2 2 Modellierer+Protokollant sich im Rollenautomaten von Abbildung 4 gegenu¨ber demjenigen in Abbildung 2 widerspiegelt. U¨ berga¨nge im Rollenautomaten werden wie bereits im ersten Ansatz durch feuernde Transitionen als Eingabezeichen ausgelo¨st.
Zusammenfassend la¨sst sich festhalten, dass beide vorgeschlagenen Modellierungsansa¨tze dynamische Rollen, kollaborative Aktivita¨ten und den Fortschritt im Lernprozess geeig
Modellierer net repra¨sentieren ko¨nnen. Allerdings unterscheiden sich die Pl beiden Ansa¨tze bezu¨glich der Eindeutigkeit und semantischen Schüler Klarheit der Modellierung, wobei kein Ansatz dem anderen Fr eindeutig u¨berlegen ist: Der erste Ansatz trennt die ModellieProtokollant rung von Prozess und Rollen weitgehend voneinander und verwendet einfache anonyme Marken im Petrinetz, wohingegen Abbildung 4. Zwei- der zweite Ansatz komplexe Marken verwendet, die jeweils tes Modell: Rollen- einen Rollenautomaten mit einem aktuellen (Rollen-)Zustand diagramm repra¨sen- repra¨sentieren, was zudem gegebenfalls die optische Lesbartiert als Zustandsau- keit des graphischen Modells erschwert (vergleiche Abbilduntomat gen 1 und 3). Andererseits repra¨sentiert im zweiten Ansatz der
Rollenautomat ausschließlich semantisch klar definierte Rollen und U¨berga¨nge, was im ersten Ansatz eventuell durch fortschrittsabha¨ngige PseudoRollen modelliert werden muss, falls die Lernhistorie beru¨cksichtigt werden soll. Dies zeigt sich klar im Vergleich der Abbildungen 4 und 2, in dem der zweite Ansatz wesentlich klarer die notwendigen Rollen darstellt.
Explizite Gruppenmodellierung: Gruppen sind in den zwei Modellen implizit u¨ber kollaborative Aktivita¨ten beru¨cksichtigt. Zur expliziten Gruppenmodellierung bieten die zwei Modellierungsansa¨tze zwei Mo¨glichkeiten. Zum einen lassen sich Gruppen durch verschiedene Prozessinstanzen repra¨sentieren. Hier fehlen allerdings noch Konzepte zur Modellierung von Abha¨ngigkeiten zwischen Prozessinstanzen um dynamische Gruppenumformierungen darstellen zu ko¨nnen. Andererseits lassen sich Gruppen auch analog zu Rollen explizit in den Zustandsdiagrammen der Akteure modellieren. Bei Gruppen ist es aber im Gegensatz zu Rollen wichtig die Gesamtgruppendynamik darzustellen, welche sich dann nur implizit u¨ber die Gruppenzugeho¨rigkeiten der einzelnen Akteure ergibt. Daher wa¨ren hier Erweiterungen der Modellierungsansa¨tze interessant, welche zu jedem Zeitpunkt explizit die Lerngruppen darstellen, z.B. geeignete Gruppierungen der Zustandsdiagramme im Akteurspool.
Collaboration Flow Mining In diesem Kapitel zeigen wir einen Ansatz zum Auffinden eines Lernprozessmodells der ersten Form aus Protokollinformationen, d.h. es soll ein Lernprozessmodell erzeugt werden, welches entweder das aufgezeichnete (dem Dozenten evtl. unbekannte) Lernverhalten der Sch u¨ler oder durch entsprechendes Filtern auch das erw u¨nschte Lernverhalten der Sch u¨ler wiedergibt. Wenn ein Akteur unterst u¨tzt von einem Informationssystem eine Aktivita¨t ausf u¨hrt, entstehen Ereignisse und durch Aufzeichnung der Ereignisse Protokollinstanzen. Jede Aufzeichnung eines Ereignisses soll Informationen u¨ber den zugeh o¨rigen Prozess, die zugeho¨ rige Prozessinstanz, den Name der Aktivita¨t, den Zeitpunkt ihrer Ausf u¨hrung und die ausfu¨ hrenden Akteure (mehrere bei kollaborativen Aktivita¨ten – u.U. m u¨ssen diese noch aus mehreren Ereignissen mit dem selben Zeitstempel zusammengesetzt werden) enthalten. Die Ereignisse werden erst nach Prozess und Prozessinstanz und innerhalb einer Prozessinstanz in der Reihenfolge ihres Ausfu¨ hrungszeitpunktes geordnet. Damit ergibt sich f u¨r jede Prozessinstanz eine Folge von Aktivita¨ten mit zugeordneten Akteuren. Diese Abla¨ufe lassen sich als Ausgangspunkt fu¨ r verschiedene Mining Algorithmen verwenden, um Prozessmodelle zu erzeugen. Derart erzeugte Prozessmodelle k o¨nnen zur Verifikation, Analyse oder zur Steuerung des operationalen Prozesses durch ein Informationssystem benutzt werden.
Das Tool Freestyler zeichnet die Aktivita¨ten der Sch u¨ler als Ereignisse auf. Abbildung 5 zeigt einen Auszug aus einem Beispielprotokoll von Freestyler f u¨r den betrachteten Lernprozess. Darunter zeigt Abbildung 5 einen sich aus dem Beispielprotokoll ergebenden Ablauf von Aktivita¨ten mit zugeordneten Akteuren. Der Dozent hat die M o¨glichkeit die Menge der Lernabla¨ufe zu filtern, indem er nach gewissen Kriterien (z.B. nachtra¨glich gemessener Lernerfolg) unerw u¨nschte Lernabla¨ufe entfernt und speziell erw u¨nschte Lernabla¨ufe zusa¨tzlich vorgibt. In diesem Fall wird dann durch mining ein Modell f u¨r einen erw u¨nschten Lernprozess erzeugt, wa¨hrend ohne Filterung durch den Dozenten ein Modell f u¨r den tatsa¨chlich von den Sch u¨lern durchgefu¨ hrten Lernprozess generiert wird.
Protokoll-Datei
Prozess Prozessinstanz Aktion Schu¨ler Zeit Photosynthese Gruppe A Einfu¨hrung Andi, Basti, Robin 10:03:12 Photosynthese Gruppe A Fragestellung Robin 10:06:43 Photosynthese Gruppe B Einfu¨hrung Bert, Caro, Hans 10:07:33
... ... ... ... ...
Lernabla¨ufe Gruppe A (Einfu¨hrung; Andi,Basti,Robin), (Fragestellung; Robin), (Planung; Andi,Basti), (Modellierung; Andi,Basti), (Hypothese; Andi,Basti,Robin), (Experiment1; Andi), (Experiment2; Robin), (Daten; Basti), (Analyse; Andi,Basti,Robin), (Pra¨sentation; Andi,Robin) ...
Abbildung 5. Beispielprotokoll.
Wir nehmen im Folgenden ein vollsta¨ndiges Protokoll fu¨r den im letzten Kapitel
modellierten Lernprozess an, d.h. wir betrachten die Menge aller bzgl. dieses
Lernprozesses mo¨glichen Lernabla¨ufe. Vernachla¨ssigt man in dieser Menge von
Lernabla¨ufen die Akteure, so la¨sst sich aus der resultierenden Menge von Aktivita¨tsfolgen
mit bekannten mining-Verfahren [
Zuerst betrachten wir fu¨r jeden Lernablauf und jeden an dem Ablauf beteiligten Schu¨ler die Folge von Aktivita¨ten, die der Schu¨ler in dem Ablauf durchfu¨hrt. Abbildung 5 illustriert diese Projektionen der Lernabla¨ufe auf die Lernenden fu¨r den betrachteten Ablauf. All diese Folgen von Aktivita¨ten werden nun in einem deterministischen Zustandsdiagramm in Baumform zusammengefasst. Die Zusta¨nde sind dann durch die in der Vergangenheit durchgefu¨hrten Aktivita¨ten eindeutig bestimmt und werden entsprechend benannt. Fu¨r unser vollsta¨ndiges Protokoll ergibt sich das Diagramm in Abbildung 6, welches schon ein erstes Rollenmodell darstellt. Jede Rolle ergibt sich also durch die in einer bestimmten Reihenfolge bisher durchgefu¨hrten Aktivita¨ten. Um diese Rollen konsistent als Beschriftungen im Petrinetz zu verwenden, muss in jedem Lernablauf jeder Akteursname durch die Rolle, die den Aktivita¨ten entspricht, welche der Akteur in der Vergangenheit der betrachteten Aktivita¨t in dem Ablauf durchgefu¨hrt hat, ersetzt werden (siehe Abbildung 5 unten). Die Rollenbeschriftung einer Aktivita¨t im Petrinetz ergibt sich nun aus allen Rollen bzw. bei kollaborativen Aktivita¨ten Rollenkombinationen, die in irgendeinem Lernablauf zusammen mit der Aktivita¨t vorkommen.
- Ei Ei
Pl EiPl Fr
Mo EiFr
Hy Hy
E1 EiPlHy E2 EiPlHyE2 An EiPlHyE2An Pr EiPlHyE2AnPr Da
EiPlMo Hy EiPlMoHy E2
Da
E1 EiFrHy E2 EiFrHyE2 An EiFrHyE2An Pr EiFrHyE2AnPr Da
Abbildung 6. Rollendiagramm mit feinster Granularita¨t.
Fu¨r den betrachteten Modellierungsansatz la¨sst sich zeigen, dass aus einer vollsta¨ndigen Ablaufmenge eines Modells mit diesem mining-Verfahren immer ein verhaltensa¨quivalentes Modell erzeugt wird. Insbesondere ist das aus dem Beispiel generierte Modell a¨quivalent zu dem Lernprozessmodell aus Abbildung 1. Allerdings entsteht hier eine sehr feine Rollenaufteilung, die auf der vollsta¨ndigen Aktivita¨tshistorie eines Akteurs basiert.
Im Weiteren ist nun das Ziel das Rollenmodell zu vereinfachen, indem bestimmte Rollen zusammengefasst werden. Hierzu haben wir die folgenden Vereinfachungsregeln fu¨r Rollendiagramme entwickelt. Die Petrinetzbeschriftungen mu¨ssen jeweils konsistent abgea¨ndert werden.
– Rollenu¨berga¨nge, durch Aktionen an denen alle in einer Prozessinstanz vorkommenden Akteure beteiligt sind, ko¨nnen weggelassen werden. – Rollen, die dieselben Folgerollen (bzw. keine Folgerollen) mit denselben U¨ bergangsaktivita¨ten haben (ersichtlich aus Abbildung 6), ko¨nnen zusammengefasst werden, falls sie fu¨r jede ausgehende Aktivita¨t in der Gesamtheit der Lernabla¨ufe genau mit denselben Rollen zusammen vorkommen (ersichtlich aus Abbildung 5 unten). Dabei du¨rfen U¨ berga¨nge zwischen den zu verschmelzenden Rollen vernachla¨ssigt werden. – Als letzte Reduktion ko¨nnen einmalig Rollen ohne Ausga¨nge entfernt werden.
Aus Platzgru¨nden ko¨nnen wir diese Regeln hier nicht na¨her erla¨utern und illustrieren. Es la¨sst sich zeigen, dass diese Regeln unter der Vollsta¨ndigkeitsannahme des Protokolls wieder zu einem a¨quivalenten Modell fu¨hren. In unserem Beispiel ergibt sich ein Rollendiagramm, welches isomorph zu dem in Abbildung 2 ist. Damit la¨sst sich bis auf die Rollennamen, welche in einem Protokoll aber auch nicht auftauchen, das urspru¨ngliche Lernprozessmodell aus einem vollsta¨ndigen Protokoll reproduzieren. Die Rollennamen mu¨ssten daher nachtra¨glich vom Dozenten vergeben werden.
Typischerweise muss davon ausgegangen werden, dass nicht alle mo¨glichen Abla¨ufe eines Prozesses aufgezeichnet werden und damit Protokolle unvollsta¨ndig sind. Fu¨r solche Protokolle sind Anpassungen der mining-Verfahren no¨tig. Hier sind Heuristiken interessant um auf im Protokoll ”fehlende “Abla¨ufe zu schließen und diese in das Prozessmodell zu integrieren. Fu¨r die Kontrollflussperspektive wurden hierzu im Bereich des process mining etliche Verfahren vorgeschlagen. Die Rollendiagramme betreffend sehen wir Mo¨glichkeiten zur Anwendung von Verfahren der strukturellen A¨ quivalenz und der verallgemeinerten Blockmodellierung.
Literatur Kolja Markwardt, Daniel Moldt, and Thomas Wagner
University of Hamburg - Department of Informatics
http://www.informatik.uni-hamburg.de/TGI Abstract. Work ow Management Systems (WFMS) are used to organize work processes between di erent people within an organization or between organizations. In this paper we will describe an agent-based WFMS, built with Petri nets, to utilize the formal soundness of Petri nets and the exibility of multi-agent systems to enhance the usefulness of a WFMS. The focus of this paper lies in the way activities are handled in the WFMS. We will rst discuss the way this works in the system as of now. Then we will go on and describe a way to use Activity Agents to add a further exibility to the activity handling of the system. These Activity Agents will be responsible for providing the functionality, including materials and user interface associated with an activity. 1
Work ow Management Systems (WFMS) are used regularly within companies.
In research and practice the question of coupling the di erent WFMS of
cooperating organizations arises, leading to inter-organizational WFMS. Agent-based
WFMS are one answer in this eld. In [
In this contribution we will explain in Section 2 the technological basics of our WFMS. Section 3 explains our current agent-based WFMS. Then Section 4 provides the information about the tool and material approach and its adaptation to our agent-based approach. On top that the central idea, the Activity Agent is introduced. How to implement the afore mentioned Activity Agent concept is described in Section 5. The paper concludes with a short summary and outlook in Section 6. 2
The technological foundation for this contribution are the Mulan and Capa
agent architectures. Mulan stands for Multi-agent nets, which is also the main
idea behind it. It was described in [
Capa (Concurrent Agent Platform Architecture) is an extension of
Mulan, which was introduced in [
Within the WFMS work ows are modelled using a variation of the work ow
nets described in [
The three transitions model the request of a work item and the cancellation or con rmation of an activity. 3
An Agent-Based WFMS In its current version the system supports basic WFMS functionality. It provides the means to administrate the system, add and edit work ow de nitions and instantiate and execute work ow instances.
The functionality of the WFMS is provided by a number of di erent agent types. The system's core is made up of a trio of agents, which provide the internal function of the WFMS. These agents are the Work ow Engine agent (WFEngine agent), the Work ow Enactment Service agent (WFES agent) and the Workitem Dispatcher agent (WiDi agent). The WFEngine agent is responsible for ring the internal transitions of the tasks and for initiating the work ow instances. The WiDi agent distributes work items and activities to the users, if they are eligible for them. The WFES agent is located between the other two agents. It manages di erent work ow instances on the work ow engine. These three agents interact with each other to organize the functionality to provide work items and activities to the user. For each user a user agent exists, which manages the interactions between the WFMS and the user's GUI. Its main responsibility lies in invoking interactions upon actions of the user within the GUI and in initiating display updates within the GUI. The other agent types o er the functionality to manage and authenticate logged in users as well as access to the database.
Currently the WFMS supports two kinds of tasks. Simple tasks can only be accepted and then be marked as completed or canceled. They represent actions, which have to be completed outside of the functionality the WFMS o ers. The other kind of tasks is form tasks. When a form task is assigned to a user, a form window is opened, in which the user enters the necessary information. Forms can consist of an arbitrary number of labels, text boxes, check boxes and radio buttons. When the form task is completed the data entered into a form is read into the system and can be used in later form tasks.
The subject of this contribution concerns the the way activities are handled within the system. Because of this it is important to give a description of the way activities are assigned in the current version.
While work ow instances are active within the system, eligible users can request the work items, which are currently activated in the work ow nets. When a user wishes to request a work item he initiates the associated interaction. If this interaction is successful the WFEngine agent res the internal request transition of the task and creates the activity.
When any changes in a work ow net occur a decision component (DC) net, a special part of the WFEngine agent, is automatically informed. This listener DC net contains a cycle, which is responsible for handling reported changes in the set of activities and is always repeated when a new change occurs. The cycle checks which activities have changed and need to be updated. The cycle ends with the initiation of the UpdateActivityList interaction. The UpdateActivityList updates the internal lists of the WFEngine agent, the WFES agent and the WiDi agent.
After the UpdateActivityList interaction has been completed, the O erActivityList interaction is started, in which the WiDi agent informs all user agents connected to him about the previously updated status of their activities. These updated activities are then displayed for the user and can be executed. 4
Tool- and Activity-Agents In this paper we propose a new way of handling activities in the WFMS by using a special kind of Tool Agents, called Activity Agents. We will rst describe the notion of Tool Agents and how they can be used to build exible tool-based applications. Then we will describe the special incarnation of Activity Agents and the way they will be integrated into the WFMS architecture. 4.1
Tool Agents
Tool Agents are a way to use multi-agent systems to build tools for supporting
individual users work as well as collaborative e orts. This follows the notions of
the tools and materials approach [
Overview The main idea about the tool agent concept is that each user controls
a user agent (UA), which can be enhanced by di erent tool agents (TA) as shown
in [
Material agents (MA) are used to represent and encapsulate the materials or work objects that are currently worked on, like an insurance claim or a text
le. Materials are manipulated by tools and can be created, deleted and moved between workplaces. Tools and materials populate the workspace of the user.
An agent called the Tool Factory is used to manage the di erent types of tool agents known to the system. It is called by the user agent to create a ne instance of a tool agent to use. Figure 1 shows how these agents work together. The de nition of a work ow can contain any number of di erent types of tasks for a user to perform. In the current systems, all these tasks have to be de ned in advance and the user needs to know how to handle them. It seems clear that in this way the user can be a real bottleneck in the deployment of new work ows, if these contain new types of tasks.
Tool Agents already provide a way to enhance the functionality of a User Agent. Therefore, an adaptation of Tool Agents for WFMS will provide a way to handle this problem, this adaptation is called an Activity Agent.
Like any Tool Agent it can be used to manipulate materials, but in this case the material and the context for its manipulation is provided by the work ow.
An Activity Agent is not requested by the User to perform some task but it is rather assigned to it by the work ow engine to handle an activity. Once it is connected to the User however, it functions like another Tool Agent. It only needs a way to determine that the work on the activity is done, so that it can return the material and feedback on activity completion back to the work ow engine, for example a \ nish" or \abort \ button in the GUI.
The Activity Agent in the Activity handling process Activity Agents represent activities within the running WFMS. When a user successfully request a work item available to him, the system will automatically start a new Activity Agent. This Activity Agent will be responsible for this activity alone, and will only be active while the activity is being executed by the user. During the execution of the activity the user will exchange information with the Activity Agent, in order to work on the activity. When the activity has been nished, the Activity Agent will transmit the relevant data back to the work ow engine and terminate. 5
Design and Implementation In this section we will describe our proposed way to implement the Activity Agent. The Activity Agent will be started after the listener DC net of the WFEngine has detected that a new activity has been created. Before the UpdateActivityList interaction is started the listener will check if the activity is agged as an Activity Agent activity. If the activity is to be executed by an Activity Agent, a new DC net is entered. The purpose of this new DC will be to start the new Activity Agent and add the agent's information to the activity, so that the executor's user agent knows how to interact with the Activity Agent. After this is done, the listener DC net can continue and start the UpdateActivityList interaction. Within The UpdateActivityList and O erActivityList interactions only the internal lists have to be modi ed, in order to incorporate the added information.
While the Update- and O erActivityList will not have to be changed much, the handling of activities in general and within the user GUI require changes.
Concerning the handling of activities changes have to be made, because in the proposed version the actual handling of the activity will be done by the Activity Agent. In the current version the activities are manipulated within the GUI and then passed to the user agent, who, upon completion of the activity, sends them to the WFEngine agent. In the new version the user agent will not directly communicate with the WFMS's core in this matter, but will only communicate with the Activity Agent in order to manipulate materials involved in the activity (e.g. forms). When the user has nished his work on the activity he will inform the Activity Agent, who then informs the WFMS's core.
The reason for changes to the GUI is, that in the current version tasks are simply displayed in a list (simple tasks) or a generic form window is opened (form tasks). In both cases, the interface to complete the activity is embedded into the general GUI. Since the Activity Agent is designed to be able to o er arbitrary functionality with a possibly specialized GUI, this GUI has to be o ered by the agent itself, because otherwise the main user GUI has to be changed and enhanced, whenever a new type of task is added. In order to support this, the GUI has to be changed so that selecting an activity will contact the Activity Agent who will in turn invoke his own GUI. 6
Summary and Outlook
We have proposed in this paper a way of enhancing an Agent-based WFMS
with exible activity-handling procedures. Specialized agents will be used to
plug into the users' system and provide them with the functionality needed to
perform their tasks within the work ow process. The underlying Petri nets allow
rst of all an appropriate modelling of the system and its processes. In addition
the agents and their behaviour become a well de ned semantics. Following our
Paose approach (see [
Activity agents will directly be used in our next version of our distributed and no longer centralized agent-based WFMS. There it will take care in a quite generic way of activities of the work ows, the core of work ows in general.
Parametric Petri Net Model for Ethernet Performance and Qos Evaluation
Dmitry A. Zaitsev1 and Tatiana R. Shmeleva2
Department of Communication Networks, Odessa National Academy of Telecommunications,
Kovalska, 1, Odessa 65029, Ukraine Web1: http://www.geocities.com/zsoftua, E-mail2: tishtri@rambler.ru Abstract. Parametric model of switched Ethernet in the form of a colored Petri net is presented. The model is invariant regarding the structure of the network; it has fixed number of nodes for any given tree-like network. Special measuring fragments, which accomplish the model, provide the evaluation of the network throughput and the frame delivery time directly in the process of simulation. The anomaly of Ethernet switches’ mutual blocking has been revealed.
Keywords: switched Ethernet, colored Petri net, parametric model, delivery time, throughput, mutual blocking. 1 Introduction
At present Ethernet technology dominates the sector of local area networks.
Moreover, 1Gb and 10Gb standards allow positioning Ethernet as a universal networking technology, because providers widely apply «Ethernet over DWDM» solutions in backbone networks. Design of effective local and backbone networks requires reliable estimations of throughput and the quality of service. Recently the model driven development of telecommunication networks and devices becomes prospective. It is based on express-evaluations of characteristics obtained in the shortest time for new project decisions that determine the relevance of the present research.
Colored Petri Nets [
The mentioned papers are based mainly on the modular approach to the telecommunication networks models construction: a model of a network is composed of DTE (workstation, server) and DCE (switch, router) submodels, which were built earlier. The essential disadvantages of this approach are the following: the necessity of the model rebuilding for each new structural scheme of the network, great number of used Petri net elements that considerably delay the processes of models construction and analysis.
The parametric model of switched Ethernet presented in [
The definite structure of a network is an input in the form of packed matrices as the
marking of corresponding Petri net places. However, in [
Emphasizing the Early Design Phases
Sebastian Mauser, Robin Bergenthum, Jo¨rg Desel, Andreas Klett Department of Applied Computer Science, Catholic University of Eichsta¨tt-Ingolstadt sebastian.mauser, robin.bergenthum, joerg.desel,
andreas.klett@ku-eichstaett.de
Abstract. This paper proposes an approach to formal business process
modeling emphasizing the early design phases. That means, the focus is on gathering
requirements of a business process in an informal environment. First, methods to
systematically elicit all requirements are discussed. Then, it is suggested to
formally model and validate the elicited requirements before integrating them to a
formal business process model and verifying the model w.r.t. the formal
requirements. The approach is inspired by techniques which have proven successful in
the area of software requirements engineering. The key technique is the
application of scenarios to bridge the gap between the informal view on the process by
practitioners and the formal business process model.
1 Introduction
Business process modeling is an important part of many software development projects
[
Business process modeling and management has attracted increasing attention going
beyond software engineering in recent years [
Business process models are also applied as input to workflow systems to control and monitor the proper execution of work items.
In this context, it is very important that the models are valid, i.e. that they correctly and completely represent the relevant aspects of the underlying real-world business process. However, although the need for valid process models increases, there usually is little effort on guaranteeing validity in practice. Mostly, process models are constructed ad hoc – usually in workshops – without detailed documentation of the different requirements of the users involved. Also in theory, most approaches to business process design and according tools assume validity of models and concentrate on analysis (e.g. soundness tests) and optimization issues. But analysis and optimization of invalid models is useless and decisions based on invalid models or execution of invalid models will cause errors.
We faced the problem of generating valid process models in a recent industrial project with the purchasing department of the AUDI AG. Correct modeling of processes is very important for AUDI, because in the recent years documentation of business processes more and more became a major part of the requirements for a TU¨ V (short for Technischer U¨ berwachungs-Verein, Technical Inspection Association in English) certification for German automobile manufacturers. The increasing importance of valid business process models caused AUDI to ask for our academic support in modeling.
The practical problems in such a large company make the modeling of valid business processes really difficult. The processes are typically inter-divisional such that the processes of the purchasing department have impact on the whole company. They are supported by a heterogeneous system landscape and include many media breaks. Within our project we developed an approach of how to come to valid process models in such a complex setting.
To design valid business process models significant attention should be paid to early phases of business process design, i.e. to the question how to systematically gather information about a business process in an informal environment. This part of business process modeling has not yet been sufficiently considered in the literature. But we claim that similar problems have been tackled in the field of requirements engineering for software systems. Therefore, the core idea of our approach is to adopt findings of requirements engineering to the area of business process modeling, in particular w.r.t. the early phases of the design process.
In requirements engineering, scenario based specifications proved to be a successful starting point. Consequently, our approach also starts with elicitation of scenarios which are single process instances of a business process model. Our approach suggests to then formalize and validate the process instances up to a level of preciseness and completeness such that formal methods can be applied in the follow-up steps of integrating the scenarios to a formal process model, e.g. an Event-Driven Process Chain (EPC) or a work flow Petri net, and of verifying the model w.r.t. the scenarios.
The approach is developed within our industrial project but we claim that in principle it can be applied for business process modeling in general. We want to present a first proposal for a respective modeling approach in this workshop paper. Still, we are collecting further experiences in the ongoing project.
The paper is structured as follows: The following section provides a rough survey on the state-of-the-art of requirements engineering in software development, with a particular focus on scenarios. In the sequel, some of these ideas are adopted to early phases of business process modeling. Section 3 provides a comparative study of literature concerning the early phases of business process modeling. Section 4 describes our modeling approach. It is structured in several subsections, referring to the different phases of our approach. Finally, Section 5 provides some concluding remarks. 2
Software Requirements Engineering: A Short Review
In software engineering, significant attention has been paid to conceptual modeling
bridging the gap between informal information about the information system to be
implemented and the final implementation. Main approaches have been structured analysis
and structured design, developed in the late 1970’s, and object-oriented analysis and
design, starting in the late 1980’s [
Information system analysts discovered that faulty requirements analysis was a
major reason for project failure or unsatisfactory software systems and that the costs of
errors grows exponentially with progressing time in the development process, see e.g.
[
In early stages of requirements engineering, user oriented specification models are
desired to describe the required behavior of a complex system from the user’s
viewpoint while for implementation of the system, integrated state-based system models are
necessary [
Thus, starting with scenarios helps to gather system specifications which are valid, i.e.
they faithfully reflect the real system requirements. Important advantages of using
scenarios at the beginning of the requirements engineering process include the view of
the system from the viewpoint of users, the ease of understanding (by different groups
of stakeholders), the possibility to write partial specifications and to incrementally
extend specifications, easy abstraction possibilities, short feedback cycles, the possibilities
to directly derive test cases, the documentation of user-oriented requirements and the
possibility to derive scenarios from log files recorded by information systems [
However, scenarios cannot capture the entire desired behavior of a system in a
structured fashion [
In the literature the topic of modeling software systems by means of scenarios has
received much attention over the past years, see e.g. [
Having finally modeled the requirements of a system by scenarios, the next
challenge is to come from the scenario view of a system to a state-based system model,
which is closer to design and implementation. Also for this problem several
methodologies have been proposed, see e.g. [
Requirements Engineering in Business Process Modeling
there are several helpful strategies and assisting procedures supporting the elicitation of
information about a process, e.g. the papers [22–26] apply the user view of scenarios
in the context of business process design, many papers such as [27, 28] discuss how
to formally integrate different views on a process, the surveys [
The approach is inspired by the concepts of scenario-based requirements engineering, i.e. we suggest focusing on scenarios of a business process before designing an integrated process model. Looking at scenarios to specify the behavior of a business process has similar advantages as for the software engineering domain, in particular user-oriented intuitive modeling is supported. The starting point of our approach is distributed knowledge about a business process in an informal real-life environment. The aim is to first develop a comprehensive formal specification of the business process by scenarios and some other types of requirements artifacts. The single formal artifacts can easily be checked for correctness according to the real-life requirements ensuring a valid specification. Then the artifacts are integrated into a business process model given by some modeling language and the generated process model is verified w.r.t. the artifacts. It is important to mention that integration and verification heavily benefit from having a valid formal specification, because this allows (semi-) automatic generation of a process model from the specification, e.g. by Petri net synthesis [24, 26] or merging procedures [27, 28], and formal verification whether a process model fulfills the specification is possible. Altogether, the construction of complex process models behaving valid according to the requirements is supported.
Besides the influences from the requirements engineering domain mentioned in
Section 2, our methodology adopted several ideas from the articles on business
process modeling cited in Section 3, in particular, from the highly related work of [
But in contrast to [
Our approach is divided into the five phases elicitation, formalization, validation,
integration and verification (see Figure 1) and the additional orthogonal phase of
information management. The first three phases are inspired by the three dimensions of
requirements engineering and the respective requirements engineering activities
suggested in [
formalisation integration validation
verification information management
Fig. 1. An approach for business process modeling.
The focus in the elicitation phase is on gathering information. The main problem is to relate and combine the information collected from different information providers in an informal environment into a valid database of knowledge. Therefore, an elicitation plan which determines appropriate strategies for the elicitation procedure has to be assembled. The information collected according to the elicitation plan has to be filtered and documented, yielding a collection of pieces of information. The pieces have to be formalized to information artifacts in the next phase. This enables validation in a followup feedback phase. The valid information artifacts document the process requirements which can be integrated into a process model. The process model is finally verified w.r.t. the documented requirements. During all these five phases, it is necessary to manage the progress of information retrieval and to organize all gathered information in the orthogonal phase of information management.
Remark that, while we describe our approach as a sequence of five phases together with one parallel phase, for applying the approach we do not suggest to adhere strictly on the given sequential ordering of phases. On the one hand it is not always possible to generate a process model in one run, such that phases have to be iterated, i.e. it is necessary to repeat phases when information is missing. On the other hand, sometimes it is helpful to move to a next phase, in particular having elicited certain information items, it can be useful to directly formalize and validate them before further proceeding with the elicitation phase.
Next we explain each of these six phases. Thereby, we concentrate on the elicitation,
formalization and validation phases and discuss them in more detail. Figure 2 shows all
necessary steps of these phases together with the resulting objects. The first two lines
refine the elicitation phase, the third line refines the formalization phase and the last
line refines the validation phase. The model incorporates ideas from different domains
concerned with information retrieval (e.g. [
Fig. 2. Steps in the elicitation, formalization and validation phase. 4.1
Elicitation The first three steps at the very beginning of the elicitation phase are the basis of the next six core elicitation steps. When modeling a business process, the starting point is to define scope and aim of the project. It is necessary to set up the project framework which surely influences all decisions made in later steps. Next, the outline of the process has to be defined. This clarifies the border of the process together with the environment and its interfaces. Now, that the business process is set to its context, a first rough structure of the process including aims, related organizational structures and involved documents and systems has to be identified, preferably with the help of a domain expert having a high level view on the process. This helps to get an overview of the information which has to be elicited, i.e. the information needs, and on potential information sources. To actually set up an elicitation plan, it is important to gather more detailed knowledge about available information providers and existing documents describing the process. Such a plan organizes the choice of people or documents which may provide detailed information about parts of the process. For each information to be collected the elicitation plan contains a list of information providers and documents.
Gathering information often leads to the following specific problems: the information contains redundancies and repetitions, homonyms and synonyms, exceptional cases to be handled, implicit information or confusions between schema and instance level. To tackle these problems, an adequate elicitation method together with a harmonized documentation method has to be chosen. Since this is an important decision to be made, we will provide a suggestion for both. After these choices have been made, the next step is to gather and record all the information according to the specified elicitation methods. This normally leads to a large set of loosely arranged information pieces, collected in different kinds of documents, which have to be filtered in the next step of the elicitation process. Filtering corrects all the above listed problems identified in the collected set of information items. The last step integrates and classifies the collected knowledge, i.e. the loose pieces of filtered information are merged and ordered in a structured way according to the chosen documentation method. This concludes the elicitation phase.
Before describing the follow-up formalization phase, we tackle the problem of
choosing an appropriate elicitation and documentation method. Often there exist several
kinds of documents to be considered, such as working instructions, already existing
process models, intra-net information or even theses about parts of the process. Also, exist
a lot of methods for elicitation of requirements from the information providers such as
interviews, monitoring, logging, rollplays, discussing, questionnaires, meetings, etc [
We found it very helpful to shortly introduce the concept of scenarios before the actual interview, because information given by the information provider then was much better structured. Introducing already existing process models to illustrate the sort of the aspired model has similar positive effects. After that, firstly, single scenario instances or even real live examples should be elicited and documented as structured text. Together with the information provider, then a scenario schema is deduced from the scenario instances and documented in a precast scenario form. These forms include entries such as name, description, information provider, activities, events, ordering relation, variations and exceptional cases, pre- and post-conditions, goals and results, success factors and responsibilities. Having filled out such a scenario form, we ask for details about single important activities, events, involved systems, business objects or actors and document them in similar precast forms as well. Although our suggestion here is to focus on scenarios, sometimes it is helpful to discuss whole process fragments which can be done in a similar way. Process fragments are scenarios containing alternatives or loops. Some information providers experienced in modeling may find it easier to describe complex process structures directly in terms of such process fragments. Generally, within the interviews it is important to always mind completeness and clarity of each information recorded and to accomplish the interviews in an appropriate intensity (see e.g. [31]).
The precast forms are already part of our documentation method. We not only use the forms in the interviews, but each type of form defines a template for storing information. As far as possible we insert each gathered information to such a form and port the forms into a database. This yields one table in the database for each type of template.
Information not fitting any template is stored in an additional table of the database as structured text together with general specifications such as information provider. Such an organization of information allows to generate different perspectives on the stored requirements through different database queries and search functionalities. It is also possible to automatically produce requirements documents following certain standards.
The main building blocks of a process model are activities, events and different kinds of objects. Therefore, to prepare the requirements for process modeling, we classify the information collected in the tables of the database in a similar way as described in the ARIS [21] methodology. Each information has to be classified into one out of three different views described in Figure 3 (the ARIS methodology suggests the views organization, data, function and one control view relating the first three). Every information about activities or events is stored in a process view. Information about objects is divided into a data and an organizational view. Resource and data objects as well as systems and applications are assigned to the data view and objects concerned with responsibilities and access rights are assigned to the organizational view. Each kind of template naturally belongs to one of these views. Scenarios, activities and events belong to the process view, business objects and systems to the data view and actors to the organizational view. Each information stored in the general purpose table explicitly has to be assigned to a view. Note that in our approach the process view is the dominant one and the relations between the views are naturally included within the process view (instead of a separate control view), e.g. by systems or roles associated to activities (as already given by the templates).
objects events activities
responsibilities data objects process view data view
organizational view
Fig. 3. Three different views to formalize data.
Additionally to the requirements database, we suggest to build a dictionary (similar
to an approach described in [
Formalization The next two steps depicted in Figure 2 are allocated in the formalization phase. This phase is necessary to get precise requirements of the intended process model. Using informal or semiformal models instead of formal ones for specifying requirements can lead to misunderstandings between author and recipient of a model.
There is a rich variety of different formalisms to choose from. The choice may depend on the documentation method, the target process modeling language or surrounding conditions in the enterprize. Generally, graphical modeling languages should be preferred. The structured pieces of information gathered in the elicitation phase can be translated in an appropriate formal representation. Each formal model of a requirement is called information artifact. The formal models should be linked with the respective documented information.
Our suggestion is to formalize scenarios similar to instance EPCs [32, 22], but allow both events and activities (functions) which not necessarily strictly alternate. That means, it is possible to specify any ordering between activities and events such that any kind of scenario specification can be regarded. In particular, it is possible to consider partial orders of activities called runs or partial orders of events called lifelines.
Process fragments (if elicited) can be formalized similarly by adding alternatives to the scenarios. To express process fragments it is also possible to already use the target process modeling language or to simply specify a respective set of scenarios for each fragment. The other way round, having a highly related set of scenarios, it may be helpful to directly fuse them to one process fragment, if that is easy, in order to account for their strong connection. Additionally, we use formalization concepts for pre- and postconditions, relations between activities or events, invariants or behavioral restrictions (which might be derived from elicited business rules) and triggers in the process view.
For the data view we use ER-diagrams and related concepts within the UML, and for the organizational view organigrams or group and role concepts are applied. 4.3
Validation After some information artifacts have been prepared, their validation is started. This is done in three steps. Before we take a closer look at them, we discuss some basics about validation. Validation of the formalized requirements is a necessary phase in our approach because it is easier to check the requirement artifacts than checking a whole process model. When the validation phase takes place at an early stage of the whole modeling procedure, mistakes recognized at such a stage can be clarified with less effort. As a consequence, validation is a task that also takes place in the first two phases of elicitation and formalization, e.g. the preparative high-level model, the elicitation plan and the filled out precast forms have to be validated (using the same methods applied in our actual validation phase). But the main validation phase of our approach, which we discuss in this subsection, is accomplished using the information artifacts after the phases of elicitation and formalization. This is because at this stage the requirements have to be correct and complete to allow a reasonable further processing in the integration phase. Therefore, a validation-quality-goal which has to be passed by every single information is applied.
The first step of validation, called analysis, solely deals with the documented information not involving any information provider. In this analysis step the unambiguous formal representation of the information artifacts enables to check for inconsistencies (e.g. some precondition never appears as a postcondition), conflicts (only occurs when there are more than one information provider for specific information) and similar problems in the requirements. Concerning conflicts, it is important to identify, analyze and solve them in this early stadium. They are documented because it might be that the same controversial subject reappears later on. Concerning inconsistencies, even automated or semi-automated analysis methods are applied for analyzing formal artifacts, e.g. matching preconditions and postconditions, checking every artifact if it is formalized with a correct syntax or analyzing patterns. Besides examining the formal representations, we also investigate the applied precast forms. These have to be checked to contain no empty fields and that the content of the fields has the right form. Altogether, in this first step of validation we discover problems and lack of clarity within the information artifacts. But the problems and unclear parts can only be resolved with additional information from the information providers. That is the reason why the analysis takes place before the other two steps of validation, namely validation w.r.t. correctness and validation w.r.t. completeness (see Figure 2). Within these two steps, one returns to the information providers, now knowing further points to discuss.
In the step of validation w.r.t. correctness, besides trying to resolve conflicts,
inconsistencies and similar problems, it is checked in detail whether the artifacts faithfully
model the intended requirements. The main goal of this step is to eliminate mistakes
coming from misunderstandings during the elicitation phase and mistakes coming from
a faulty transfer from informal requirements to formal artifacts during the formalization
phase. Therefore, the information artifacts are discussed with the corresponding
information provider, i.e. it is asked if they express exactly what the provider meant. For
the discussion, we lean on standard validation techniques from software engineering
[
If necessary, the artifacts can be discussed with different information providers
(having different perspectives on one topic) or even external specialists, so that the final
information artifacts can really be regarded as correct. This part of the validation w.r.t.
correctness is performed in collaborative meetings or one-on-one interviews. As
assisting techniques for this step of validation we first use perspective based reading (the
information provider has to concentrate on a special point of view or role while reading
an artifact) to reveal problems [
The last step in the validation phase is the validation w.r.t. completeness. This step
should not be seen independently from the former validation step. That means, often
both validation steps take place together, e.g. within the same discussions with
information providers, and often the same validation techniques, e.g. discussion techniques, are
applied. But, nevertheless, we have distinguished this part of validation from validation
w.r.t. correctness, because there is a different focus, namely to test whether the gathered
information are not yet complete. We use the following validation techniques specially
tailored to find missing information: First, examining existing scenarios, process
fragments or prototypes as well as unfolding process fragments or prototypes yields hints
or inspirations towards additional scenarios. Second, matching equal states of different
scenarios or finding structural dependencies between different scenarios indicate that
other combinations of parts of the scenario should be considered. Third, it is important
to check if every single context aspect is taken care of, e.g. if all interfaces,
stakeholders and objects of the environment are covered by and fit to the specified scenarios. In
addition to these three techniques, one also has to simply ask the information providers
if they can suggest further providers which might contribute additional information.
4.4 Information Management
Parallel to the five other phases depicted in Figure 1, there is an information
management phase, providing the necessary infrastructure for storing, relating and updating
all the documents and data, as well as monitoring the progress of the steps described
above. Regarding the infrastructure, an appropriate tool management, data management
and file system has to be established. Concerning the monitoring of the progress of the
activities (note that this task is sometimes also considered a part of validation [
The rows can be taken directly from the elicitation plan. The columns should not only contain the main activities elicitation, formalization, validation, integration and verification, but also more precise steps like “make appointment”, “prepare appointment”, “filter information”, and “classify information” are very useful. In particular for the validation phase, a detailed consideration of the progress, even regarding a subdivision of the different applied validation techniques, is necessary. Using such a to-do list concept we suggest to not only keep quantity aspects in mind, since this could mislead to just superficially perform the activities such that they can be marked in the list as done.
A respective list has a quality meaning as well. So, when marking a task as done one
should check the quality of its execution and of its results. For certain tasks, it is even
helpful to supplement the main to-do list by additional detailed checklists [
In the verification phase reliable formal requirements are a basis to apply verification methods which check whether the process model correctly reflects the specified requirements such as testing methods to check the executability of specified scenarios, unfolding methods to check wether the process model has additional non-specified behavior and model checking methods for the verification of formalized business rules.
Besides, there are specification independent correctness criteria for process models, such as the absence of deadlocks, certain soundness criteria or structural properties, which also have to be checked by formal methods in the verification phase. 5
Conclusion The described approach of emphasizing the early design phases of business process modeling together with a consequent documentation and formalization of the information gathered has many benefits. Most important is that as explained throughout the paper the approach heavily supports the generation of valid models in an informal environment. Furthermore, the elicited requirements are documented in such a way that it is possible to get a detailed understanding of them at any time, e.g. if the business process has to be changed or expanded one can build on the existing requirements. Especially, in the case that the business process model is for statutory warranties, its requirements have to be traceable. Moreover, the formal approach enables reliable validation of the information collected and verification and testing of the constructed process model.
Formal requirements also support the application of formal methods such as synthesis in the integration phase.
By now, within the AUDI project, we followed our modeling approach for example business processes and found the results most promising. We also developed and applied prototype tools supporting the early phases in our process modeling approach.
From the experiences of our project we in particular discovered that in practice there are several difficulties that have to be regarded. There are legal constraints, e.g. it can happen that information providers are not allowed to be stored together with the given information, and organizational constraints, e.g. information providers are often not available. Most important is the factor of time and cost such that a tradeoff between the invested effort made in the early phases of process modeling and the related cost has to be found. Still, as learned from software engineering for important process models we think that emphasizing early design phases always pays off.
The integration and verification phases of our process modeling approach still have to be elaborated. This is the focus of our further theoretical research. In particular, we plan to support the integration phase by adjusting methods known from Petri net synthesis and to develop verification methods by adapting the theories of testing executability of scenarios and calculating unfoldings of Petri nets (algorithms in all these areas are implemented in our toolset VipTool [24, 25], see http://viptool.ku-eichstaett.de). Concerning further practical work, we plan a comprehensive evaluation of the modeling approach going beyond our current industrial project. 16. Salbrechter, A., Mayr, H.C., Kop, C.: Mapping Pre-Designed Business Process Models to
UML. In: IASTED Conf. on Software Engineering and Applications 2004, IASTED/ACTA
Press (2004) 400–405 17. Holten, R., Striemer, R., Weske, M.: Vergleich von Anstzen zur Entwicklung von Workflow
Anwendungen. In: Software Management 97. (1997) 258–274 18. Weske, M., Goesmann, T., Holten, R., Striemer, R.: A Reference Model for Workflow Ap
plication Development Processes. In: WACC, ACM (1999) 1–10 19. Castela, N., Tribolet, J.M., Guerra, A., Lopes, E.R.: Survey, Analysis and Validation of
Information for Business Process Modeling. In: ICEIS, Ciudad Real (2002) 803–806 20. Scheer, A.W.: Architecture of Integrated Information Systems: Foundations of Enterprise
Modeling. Springer (1992) 21. Scheer, A.W., Nu¨ttgens, M.: ARIS Architecture and Reference Models for Business Process
Management. In: BPM 2000, LNCS 1806, Springer (2000) 376–389 22. Dongen, B., Aalst, W.: Multi-Phase Process Mining: Aggregating Instance Graphs into
EPC’s and Petri Nets. In: 2nd Workshop on Applications of Petri Nets to Coordination,
Workflow and Business Process Management, Petri Nets 2005, Miami (2005) 35–58 23. Desel, J.: From Human Knowledge to Process Models. In: UNISCON 2008, LNBIP 5,
Springer (2008) 84–95 24. Bergenthum, R., Desel, J., Lorenz, R., Mauser, S.: Synthesis of Petri Nets from Scenarios
with VipTool. In: Petri Nets 2008, LNCS 5062, Springer (2008) 388–398 25. Desel, J., Juha´s, G., Lorenz, R., Neumair, C.: Modelling and Validation with Viptool. In:
BPM 2003, LNCS 2678, Springer (2003) 380–389 26. Bergenthum, R., Desel, J., Mauser, S., Lorenz, R.: Construction of Process Models from
Example Runs. In: ToPNoC, Springer (to appear in 2009) 27. van Hee, K.M., Sidorova, N., Somers, L.J., Voorhoeve, M.: Consistency in model integration.
Data Knowl. Eng. 56(1) (2006) 4–22 28. Mendling, J., Simon, C.: Business process design by view integration. In: BPM Workshops,
LNCS 4103, Springer (2006) 55–64
29. Recker, J.: Process Modeling in the 21st Century. BPTrends 3(5) (2006) 1–6
30. Bernhard, J., Jodin, D., Ho¨mberg, K., Kuhnt, S., Schu¨rmann, C., Wenzel, S.:
Vorgehensmodell zur Informationsgewinnung Prozessschritte und Methodennutzung, Technical
Report 06008. Sonderforschungsbereich 559, Modellierung großer Netze in der Logistik,
Universita¨t Dortmund (2007)
31. Ho¨mberg, K., Jodin, D., Leppin, M.: Methoden der Informations- und Datenerhebung,
Technical Report 04002. Sonderforschungsbereich 559, Modellierung großer Netze in der
Logistik, Universita¨t Dortmund (2004)
32. Scheer: IDS Scheer: ARIS Process Performance Manager. http://www.ids-scheer.com.
of the coloring algorithm applied to a single AND-split/join handle.
o w > 1 for any given pair of nodes, that pair is marked as a matching operator
node. Once all matching operator pairs of a given worko w net are detected,
can be done in analogy to the approach described in [
and thus control-o w errors in worko w nets. Our implementation therefore also more existing clusters than palette color entries. can clearly distinguish from each other is fairly limited. A possible solution for the amount of distinguishable handle clusters for complex worko w nets with colors (e. g. hatched, striped or plaid). Such patterns could be used to extend
to allow its application to the generalized problem of detecting PT/TP-handles One shortcoming of our approach is the fact that the number of colors a human replaces the structural worko w net analysis functionality of WoPeD, allowing