Process Mining and Petri Net Synthesis

Ekkart Kindler, Vladimir Rubin, and Wilhelm Schafer

Software Engineering Group, University of Paderborn,Warburger Str. 100, D-33098 Paderborn, Germany

{kindler, vroubine, wilhelm}@uni-paderborn.de

Abstract. The theory of regions and the algorithms for synthesizing aPetri net model from a transition system, which are based on this theory,have interesting practical applications in particular in the design ofelectronic circuits. In this paper, we show that this theory can be alsoapplied for mining the underlying process from the user interactions witha document management system. To this end, we combine an algorithmthat we called activity mining with such Petri net synthesis algorithms.We present the basic idea of this approach, show some rst results, andcompare them with classical process mining techniques. The main benetis that, in combination, the activity mining algorithm and the synthesisalgorithms do not need a log of the activities, which is not available whenthe processes are supported by a document management system only.

1 Introduction

Today, there is a bunch of techniques that help to automatically come up withprocess models from a sequence of activities that are executed in an enterprise[1]. Typically, such sequences come from the log of a workow managementsystem or some standard software which is used for executing these processes.There are many dierent algorithms and methods that help to obtain faithfulprocess models; some techniques come up with an initial model quite fast andthe process models are incrementally improved by new observations [2]. All thesetechniques can be summarized by the term process mining.

Our interest in process mining came from the area of software engineering.Software engineering processes are often not well-documented, though good en-gineers have the processes in their minds. In the Capability Maturity Model(CMM), this level of maturity of a software company is called repeatable [3].Therefore, we looked for methods for automatically mining these process mod-els from the observed work. The main source for observing the work of softwareengineers are the logs of the version management systems and document manage-ment systems that are used in the development process. The problem, however,is that these systems are aware of documents only and not of the underlying ac-tivities. Basically, they see the creation, modication, and checkin of documents,but they are not aware of the activities and to which activity these events belongto. Therefore, the standard mining algorithms do not work; we must identify theactivities from the event logs of the document management systems before: wecall this activity mining. By activity mining, we get more information on the

J. Eder, S. Dustdar et al. (Eds.): BPM 2006 Workshops, LNCS 4103, pp. 105116, 2006.c Springer-Verlag Berlin Heidelberg 2006

106 E. Kindler, V. Rubin, and W. Schafer

process than just a sequence of activities. In order to exploit this information,we developed an algorithm for obtaining the process models [4].

Having a closer look to the results of activity mining algorithms revealed thatwe could easily obtain a transition system for the underlying processes, wherethe transitions are the activities of the processes. So, basically, deriving a processmodel from the result of the activity mining algorithm means deriving a Petri netfrom a transition system, which is a well-known area of Petri net theory calledPetri net synthesis. It was established by the seminal paper by Ehrenfeucht andRozenberg [5] on regions and later extended and elaborated by other authors[6,7,8]. In this paper, we show that our activity mining algorithm in combinationwith the tool Petrify [9] can be used for faithfully mining process models fromlogs of document management systems and version management systems. Thefocus of this paper is on the use of synthesis algorithm; for details on the activitymining algorithms, we refer to [4].

2 Related Work

There is much research in the area of process mining [1]. People from dierentresearch domains, such as software process engineering, software congurationmanagement, workow management, and data mining are interested in derivingthe behavioural models from the audit trails of the standard software.

The rst application of process mining to the workow domain was pre-sented by Agrawal et al. in 1998 [10]. The approach of Herbst and Karagian-nis [11] uses machine learning techniques for acquisition and adaptation ofworkow models. The seminal work in the area of process mining was presentedby van der Aalst et al. [12,13]. In this work, the causality relations between activ-ities in logs are introduced and the -mining algorithm for discovering workowmodels is dened. The research in the area of software process mining startedin the mid 90ties with new approaches to the grammar inference problem pro-posed by Cook and Wolf [14]. The other work from the software domain is inthe area of mining from software repositories [15]. Our approach [4] aims atcombining software process mining with mining from software repositories; itderives a software process from the logs of software conguration managementsystems.

Another research area, which is discussed in this paper, is the area of Petrinet synthesis and the theory of regions. The seminal paper in this area waswritten by Ehrenfeucht and Rozenberg [5]. It answered a long open questionin Petri net theory: how to obtain a Petri net model from a transition system.Further research in this area came up with synthesis algorithms for elementarynet systems [7] and even proved some promising complexity results for boundedplace/transition systems [6].

First ideas of combining process mining and process synthesis were alreadymentioned in the process mining domain [13,16]. In this paper, we make the nextstep, we present an algorithm that enables us using the Petri net synthesis toolPetrify [9] for process mining.

Process Mining and Petri Net Synthesis 107

Fig. 1. Mining and Synthesis Schema

3 Mining and Synthesis

In this section, we present the overall approach; it combines our mining algo-rithms with Petri net synthesis algorithms in order to discover process modelsfrom versioning logs of document management systems.

The overall scheme of this approach is presented in Fig. 1. It starts with a ver-sioning log as an input; by means of our activity mining algorithm, we derive aset of activities from the log. Using the set of activities, we do transition systemgeneration. From the transition system, we derive a Petri net with the help of thesynthesis algorithm. In this paper, we briey discuss our activitymining algorithm;however, the focus of this paper is on the transition system generation, the use ofthe synthesis algorithm and the process models that can be obtained by it.

3.1 Transition System Generation from Versioning Logs

In this section, we deal with the versioning logs and present the transition systemgeneration algorithm.

Initial Input and Activity Mining. Here, we briey discuss our activitymining algorithm and the structure of the input it needs. This input informationis versioning logs of dierent document management systems, such as SoftwareConguration Management (SCM) systems, Product Data Management (PDM)systems and other conguration and version management systems.

An example of a versioning log is shown in Table 1. The log contains dataon the documents and timestamps of their commits to the system along withdata on users and log comments. The versioning log consists of execution logs(in our example, they are separated by double lines), the structure of whichcan be derived using additional information, not discussed in this paper. Theseexecution logs contain information about the instances of the process. Our smallexample was inspired by the software change process [17]; for this process, thereare dierent executions, in which dierent documents are committed in dierentorder starting with the design and nishing with the review. We groupexecution logs into clusters. A cluster is a set of execution logs, which containsidentical sets of documents. For example, the rst two execution logs make upa cluster, because they both contain design, code, testPlan and reviewdocuments; the third execution log forms another cluster.

From the information about the execution logs and their clusters, the docu-ments and the order of their commits to the system, we derive a set of activities

108 E. Kindler, V. Rubin, and W. Schafer

Table 1. Versioning Log

Document Date Author Commentdesign 01.01.05 14:30 de status: initialcode 01.01.05 15:00 dev status: generatedtestPlan 05.01.05 10:00 qa status: initialreview 07.01.05 11:00 se status: pendingdesign 01.02.05 11:00 de status: initialtestPlan 15.02.05 17:00 qa status: initialcode 20.02.05 09:00 dev status: generatedreview 28.02.05 18:45 se status: pendingdesign 01.02.05 11:00 de status: initialvericationResults 15.02.05 17:00 se status: initialcode 20.02.05 09:00 dev status: generatedreview 28.02.05 18:45 se status: pending

with the help of the activity mining algorithm (for details, see [4]). The resultingset is shown in Table 2. Since we have only information about the documents,we adopt a document-oriented view on the activities: they are dened by theinput and the output documents1. The output documents are derived from thelogs straightforwardly; the challenge of activity mining is deriving the inputs,because this information is not represented explicitly. The input contains all thedocuments that precede the output document in all the execution logs. For eachactivity, we have also shown the clusters from which it was derived; i.e. 1means the cluster with the rst two execution logs, 2 is the cluster with thethird one. For example, activity 1 has s0 as input, design as output and can bederived from clusters 1 or 2.

In general, let us assume, there are n clusters and each cluster is given aunique identier from the set C = {1, . . . , n}. For every subset cl C, there is aset Dcl, which contains the intersection of sets of documents that belong to eachexecution log of this cl: Dcl =

ecl De. So, each activity is a tuple (I,O, cl),

where cl is a set of clusters from which this activity was derived; I and O are thesets of input and output documents resp. In a formal notation, a set of activitiesis dened the following way:

A {(I,O, cl)|I Dcl, O Dcl, cl C} (1)

For each tuple, we dene a . notation, which gives the concrete eld valueby its name. E.g. for activity a1 = ({s0}, {design}, {1, 2}), we have a1.I = {s0},a1.O = {design} and a1.cl = {1, 2}.

1 For technical reason, we include a document s0 to the input of every activityexcept 0 and also add two additional activities that produce e0; it is done formaking the process start and the process end explicit.

Process Mining and Petri Net Synthesis 109

Table 2. Set of Activities

Number Input Output Clusters0 s0 1, 21 s0 design 1, 22 s0, design code 13 s0, design, vericationResults code 24 s0, design testPlan 15 s0, design vericationResults 26 s0, design, code, testPlan review 17 s0, design, code, vericationResults review 28 s0, design, code, testPlan, review e0 19 s0, design, code, vericationResults, review e0 2

Transition System Generation. Dierent clusters, described in the previoussection, correspond to dierent sets of documents and represent an alternativebehaviour, whereas from one cluster we can derive concurrent behaviour. Forexample, activities 4 and 5 in Table 2 belong to dierent clusters, their outputdocuments testPlan and vericationResults belong to the document setsof dierent clusters respectively. Thus, after creating the design, there is analternative either to produce a testPlan or to obtain vericationResults. Butthe activities 2 and 4 belong to the same cluster, thus, after the design, it ispossible both to produce code and then a testPlan or rst a testPlan andthen code, i.e. they are concurrent.

The main goal of the transition system generation algorithm is generating alabelled transition system using a set of activities and modelling the alternativesand the concurrency in it. The transition system consists of states, events and atransition relation between states, which are labelled with events. In our context,a state is a set of activities, which represents the history of the process, i.e. itcontains the activities that were executed. All the activities of the state mustoccur in the same cluster. For example, the system is in a state s1 = {0, 1, 2}when activities 0, 1 and 2 have been executed and, thus, documents s0, de-sign and code have been produced. An event is a document produced by anactivity enabled in a state. An activity is enabled in a state if it does not belongto the state but belongs to the same cluster as the states activities; and the setof the documents produced by the states activities includes the input set of theenabled activity. For example, activity 4 is enabled in state s1, because it doesnot belong to the state, but it belongs to the same cluster as activities 0, 1 and2; and it needs the documents s0 and design as an input, these documentsare a subset of the document set produced by s1. So, when activity 4 is executedin the state s1, it produces a document testPlan and the system goes to anew state s2 = {0, 1, 2, 4}. Thus, there is a transition between states s1 and s2and it is labelled with testPlan. The resulting transition system is shown inFig. 2; for better readability, the states names do not contain the activities butthe names of the produced documents, e.g. s1 is called s s0 design and s2 s design s0 testPlan respectively.

110 E. Kindler, V. Rubin, and W. Schafer

s_s0

s_s0_design

design

s_design_s0_code

code

s_design_s0_testPlan

testPlan

s_design_s0_verificationResults

verificationResults

s_testPlan_design_s0_code

testPlan code

s_design_s0_verificationResults_code

code

s_code_design_s0_testPlan_review

review

s_code_design_s0_verificationResults_review

review

s_code_design_review_s0_testPlan_e0

e0

s_code_design_review_s0_verificationResults_e0

e0

region

Fig. 2. Generated Transition System

Formally, a transition system is a tuple TS = (S,E, T, s0), where S is a set ofstates, E is a set of events, T S E S is transition relation and s0 S is aninitial state. In our case, a state s S is a subset of activities, i.e. s A, whereA is dened in (1). The initial state s0 = {({}, {s0}, C)} contains the activity,which produces s0 and belongs to all clusters. There is a transition s e sbetween two states, if there is an activity a A such that (a = s \s)(a.O = e)and for all b s : a.cl b.cl, i.e. it belongs to the same cluster as the activitiesin s and a.I bs b.O, i.e. it is enabled in s.

We implemented these formal denitions as a set of clauses in SWI-Prolog [18].As output, our algorithm generates a le with the transition system. This le isaccepted by a synthesis tool, see Sect. 3.2, and can be automatically visualizedas shown in Fig. 2.

3.2 Petri Net Synthesis

In this section, we describe the last step of our mining and synthesis approach:synthesis of a Petri Net from a mined transition system. We use the tool Petrify[9] for it.

Petrify, given a nite transition system, synthesizes a Petri net with a reach-ability graph that is bisimilar to the transition system. The synthesis algorithmis based on the theory of regions and was described in the work of Cortadellaet al. [19]. Petrify uses labelled Petri nets and, thus, supports synthesis fromarbitrary transition systems. It supports dierent methods for minimizing thePetri nets and for improving the eciency of the synthesis algorithm. Here, wedo not go into the details of the synthesis algorithm, but give the essential ideaand motivate the relevance of it for the process mining area.

Process Mining and Petri Net Synthesis 111

design

code

testPlan

verificationResultsreview e0

Fig. 3. Synthesized Petri Net

A region is a set of states to which all transitions with the same labels havethe same relations: either they enter this set, or they exit this set or they do notcross this set. For example, in the transition system in Fig. 2, the set of states

{ s code design s0 testP lan review,s code design s0 verificationResults review }

is a region, because all transitions with a label review enter this set and alltransitions with a label e0 exit it. Petrify discovers a complete set of minimalregions for the given transition system and then removes the redundant ones. Aregion corresponds to a place in the synthesized Petri Net; so, Petrify tries tominimize the number of places and to make the Petri net understandable. Forexample, the synthesized Petri net is shown in Fig. 3. A place between Petrinet transitions review and e0 corresponds to the set of states, shown above.In the transition system, dierent transitions correspond to the same event. Anevent in the transition system corresponds to a Petri net transition. For example,for the event review there is a transition with the identical name. There isan arc between a transition and a place in the Petri net, if the correspondingtransition in the transition system enters or exits the corresponding region.

In the context of process mining, the generated Petri net represents the con-trol aspect of the process and models concurrency and alternatives, which wereinitially hidden in the logs. The transitions represent the activities. Since wehave a document-oriented view on the activities, the execution of every activityresults in committing a document to the document management system. By now,activities are named by the names of the committed documents, for example,activity code results in committing the document code to the system.

Since Petrify supports label splitting, it allows us to synthesize Petri netsunder dierent optimization criteria and belonging to dierent classes, such aspure, free-choice, etc. Practically, for big projects, for complex Petri nets, we cangenerate pure or free-choice versions of them, which can be better understandableby managers and process engineers and, therefore, serve communication purposesin the company. For example, for the Petri net shown in Fig. 3, we can generatea pure analog of it, see Fig. 4.

3.3 Other Applications Activity Logs

Along with applying our algorithms to the area of process mining from theversioning logs, we have also dealt with the activity logs as a standard input for

112 E. Kindler, V. Rubin, and W. Schafer

design code

testPlan

verificationResults review

code

e0

Fig. 4. Synthesized Pure Petri Net

Table 3. Activity Log

Execution 1 Execution 2 Execution 3s0 s0 s0doDesign doDesign doDesignwriteCode planTest verifyplanTest writeCode writeCodedoReview doReview doReviewe0 e0 e0

the most of classical mining approaches [13,14]. These logs are usually obtainedfrom the workow management systems or some standard software which is usedfor executing the processes in the company. For activity logs, we have deliberatelychosen an example, which is very similar to the one given for verioning logs in theprevious part of this section; it was done to motivate the generality of the miningand synthesis approach and to improve the readability of the paper. Actually, thealgorithms for dealing with the versioning logs and for dealing with the activitylogs are absolutely dierent and one can not be replaced by the other.

An example of the activity log (event log, as it is often called in literature)is shown in Table 3. It consists of process executions, which represent processinstances (cases); in our example, we have three instances of the process. Everyinstance contains a set of activities and an order of their execution. For example,in the rst instance, activities are executed in the following order: doDesign,writeCode, planTest and then doReview. We add activity s0 to thebeginning of every log and activity e0 to the end of every log to make theprocess start and the process end explicit.

From the activity log, without any preprocessing steps, we can generate atransition system. In this case, a state is again a set of activities. An event isan activity enabled in a state. An activity is enabled in a state when there is aprocess execution, where the activity is executed after the set of the activitiesof the state. For example, the system is in a state s1 = {s0, doDesign}, whenactivities s0 and doDesign have been executed. Since in the Execution 1, anactivity writeCode is executed after the activities of the state s1, an eventwriteCode can occur in this state. When the activity is executed, the systemcomes to a state s2 = {s0, doDesign, writeCode}; so, there is a transition be-tween the states s1 and s2. The resulting transition system is shown in Fig. 5.The Petrify synthesis algorithm generates a Petri net from it, see Fig. 6.

Process Mining and Petri Net Synthesis 113

s_s0

s_s0_doDesign

doDesign

s_s0_doDesign_planTests

planTests

s_s0_doDesign_verify

verify

s_s0_doDesign_writeCode

writeCode

s_s0_doDesign_writeCode_planTests

writeCode

s_s0_doDesign_verify_writeCode

writeCodeplanTests

s_s0_doDesign_writeCode_planTests_doReview

doReview

s_s0_doDesign_verify_writeCode_doReview

doReview

s_s0_doDesign_verify_writeCode_doReview_e0

e0

s_s0_doDesign_writeCode_planTests_doReview_e0

e0

Fig. 5. Generated Transition System

doDesign

planTests

verify

writeCodedoReview e0

Fig. 6. Synthesized Petri Net

In a formal notation, there is a transition s a s between two states, wheres = {a1, . . . , ai1}, a = ai, s = {a1, . . . , ai} and a1, . . . , ai are activities, if andonly if there is a following execution a1, . . . , ai1, ai, . . ..

3.4 Implementation and Evaluation

In this section, we show the rst steps and directions for the evaluation of thepresented algorithms. For making a small ad-hoc comparison with the existingprocess mining approaches, we have used ProM and the -algorithm [13] forgenerating a Petri net from the log presented in Table 3. As a result, we havegot the Petri net shown in Fig. 7. The algorithms provide dierent results, but,for example, for our small activity log, the synthesized Petri net has no dead-locks and it models all the process executions from the activity log, whereas themodel obtained with ProM reaches a deadlock situation after executing activitiesdoDesign and planTests and, thus, does not model the Execution 2.

This shows that our algorithm gives a better result for at least one exam-ple. But there are other benets: First, we are capable of dealing with dierentsources of information: versioning logs and activity logs. Second, our approach is

114 E. Kindler, V. Rubin, and W. Schafer

doDesign

writeCode

planTests

doReview

verify

Fig. 7. Petri Net generated by ProM

Table 4. Execution Times

# of Executions 3 5 7 10Average # of Documents in Execution 4 5 6 10Execution Time (msec) 941 1157 2307 9994

exible and extensible, because improving the initial algorithms (they work withversioning logs) for dealing with the activity logs resulted in: 1) removing clus-tering and activity mining parts, which are specic and necessary for versioninglogs; 2) slightly changing the transition system generation part2. In general, thePetri net synthesis approach assumes having complete transition system with allpossible transitions, which is not always a realistic case; but, for the versioninglogs, the activity mining algorithm has to cope with the defects of the input dataand the transition system generation algorithm remains the same.

Our algorithms were implemented in Prolog, which gives a certain exibilityof the solution and simplies the capabilities of experimenting with it and ex-panding it. We have made several experiments with the algorithms. For theseexperiments, the logs were generated articially but they are based on our ex-perience on real examples. The execution times of all the algorithms (mining,transition system generation and synthesis) are shown in Table 4. The execu-tion time depends on the number of executions (execution log) and the averagenumber of documents in the execution. The columns in the table correspond tothe experiments; the time needed for constructing a Petri net from 10 logs with10 documents in each log is less then 10 seconds, which is a rather promisingresult, since this is an example in the size of a realistic log.

In this section, we have presented the rst steps towards combining the min-ing and the synthesis approaches for discovering process models from both ver-sioning logs and activity logs. Though, the approach is not fully worked out andevaluated yet, we can already see its benets even for the given simple examples.

4 Conclusion and Future Work

In this paper, we have presented mining and synthesis algorithms, which derivea Petri net model of a business process from a versioning log of a document2 Now, the ProM community has done their own implementation of some regionsalgorithms, which is available as a Region miner plugin for ProM.

Process Mining and Petri Net Synthesis 115

management system. This way, we have opened a new application area for miningwithout activity logs. We have also shown an extension of our approach, whichcan deal with activity logs of workow management systems. The approach usesthe well-developed and practically-applicable theory of Petri net synthesis forsolving a vital problem of process mining. In order to do it, we have developeda transition system generation algorithm, which is the main focus of the paper.

The algorithms which were presented in this paper can deal with concurrencyand alternatives in the process models. By now, we are not dealing with iter-ations. Detecting iterations in the versioning logs is a very important domain-specic and company-specic problem. We will deal with this problem in ourfuture research, even though this problem appears rather seldom, if the conven-tions of using the document management system are introduced and fullled inthe company. Another relevant domain-specic problem is identifying the activ-ities and naming them meaningfully. Both issues belong to the part on activitymining. In the future, we will improve the activity mining algorithm and, pos-sibly, use the interaction with the user for solving these problems. However,activity mining is not the focus of this paper; as soon as it is improved, thetransition system generation algorithm has only to be slightly changed for intro-ducing iterations and activities identiers to the transition systems.

Much work has to be done in applying the mining and synthesis algorithmsto dierent document management systems in dierent application areas andmaking practical evaluation of them both in the area of business process man-agement and software process engineering. Since our approach is also relevantto the area of mining the activity logs, in the future, we should also compare itto the existing approaches in this area. This paper aims at making the rst stepfrom the well-developed theory of Petri net synthesis to the practically relevantresearch domain of process mining.

References

1. van der Aalst, W., van Dongena, B.F., Herbst, J., Marustera, L., Schimm, G.,Weijters, A.J.M.M.: Workow mining: A survey of issues and approaches. Data &Knowledge Engineering 47 (2003) 237267

2. Kindler, E., Rubin, V., Schafer, W.: Incremental Workow mining based on Doc-ument Versioning Information. In Li, M., Boehm, B., Osterweil, L.J., eds.: Proc.of the Software Process Workshop 2005, Beijing, China. Volume 3840 of LNCS.,Springer (2005) 287301

3. Humphrey, W.S.: Managing the software process. Addison-Wesley Longman Pub-lishing Co., Inc., Boston, MA, USA (1989)

4. Kindler, E., Rubin, V., Schafer, W.: Activity mining for discovering software pro-cess models. In Biel, B., Book, M., Gruhn, V., eds.: Proc. of the Software Engi-neering 2006 Conference, Leipzig, Germany. Volume P-79 of LNI., Gesellschaft furInformatik (2006) 175180

5. Ehrenfeucht, A., Rozenberg, G.: Partial (Set) 2-Structures. Part I: Basic Notionsand the Representation Problem. Acta Informatica 27 (1989) 315342

6. Badouel, E., Bernardinello, L., Darondeau, P.: Polynomial algorithms for the syn-thesis of bounded nets. In: TAPSOFT. (1995) 364378

116 E. Kindler, V. Rubin, and W. Schafer

7. Desel, J., Reisig, W.: The synthesis problem of Petri nets. Acta Inf. 33 (1996)297315

8. Badouel, E., Darondeau, P.: Theory of regions. In: Lectures on Petri Nets I: BasicModels, Advances in Petri Nets, the volumes are based on the Advanced Courseon Petri Nets, London, UK, Springer-Verlag (1998) 529586

9. Cortadella, J., Kishinevsky, M., Kondratyev, A., Lavagno, L., Yakovlev, A.: Petrify:a tool for manipulating concurrent specications and synthesis of asynchronouscontrollers. IEICE Transactions on Information and Systems E80-D (1997)315325

10. Agrawal, R., Gunopulos, D., Leymann, F.: Mining Process Models from WorkowLogs. In: Proceedings of the 6th International Conference on Extending DatabaseTechnology, Springer-Verlag (1998) 469483

11. Herbst, J., Karagiannis, D.: An Inductive approach to the Acquisition and Adap-tation of Workow Models. citeseer.ist.psu.edu/herbst99inductive.html (1999)

12. Weijters, A., van der Aalst, W.: Workow Mining: Discovering Workow Modelsfrom Event-Based Data. In Dousson, C., Hoppner, F., Quiniou, R., eds.: Proceed-ings of the ECAI Workshop on Knowledge Discovery and Spatial Data. (2002)7884

13. van der Aalst, W., Weijters, T., Maruster, L.: Workow mining: Discovering processmodels from event logs. IEEE Transactions on Knowledge and Data Engineering16 (2004) 11281142

14. Cook, J.E., Wolf, A.L.: Discovering Models of Software Processes from Event-BasedData. ACM Trans. Softw. Eng. Methodol. 7 (1998) 215249

15. MSR 2005 International Workshop on Mining Software Repositories. In: ICSE 05:Proceedings of the 27th international conference on Software engineering, NewYork, NY, USA, ACM Press (2005)

16. Herbst, J.: Ein induktiver Ansatz zur Akquisition und Adaption von Workow-Modellen. PhD thesis, Universitat Ulm (2001)

17. Kellner, M.I., Felier, P.H., Finkelstein, A., Katayama, T., Osterweil, L., Penedo,M., Rombach, H.: ISPW-6 Software Process Example. In: Proceedings of the FirstInternational Conference on the Software Process, Redondo Beach, CA, USA, IEEEComputer Society Press (1991) 176186

18. Wielemaker, J.: An overview of the SWI-Prolog programming environment. InMesnard, F., Serebenik, A., eds.: Proceedings of the 13th International Workshopon Logic Programming Environments, Heverlee, Belgium, Katholieke UniversiteitLeuven (2003) 116 CW 371.

19. Cortadella, J., Kishinevsky, M., Lavagno, L., Yakovlev, A.: Deriving Petri nets fromnite transition systems. IEEE Transactions on Computers 47 (1998) 859882

IntroductionRelated WorkMining and SynthesisTransition System Generation from Versioning LogsPetri Net SynthesisOther Applications -- Activity LogsImplementation and Evaluation

Conclusion and Future Work

/ColorImageDict > /JPEG2000ColorACSImageDict > /JPEG2000ColorImageDict > /AntiAliasGrayImages false /CropGrayImages true /GrayImageMinResolution 150 /GrayImageMinResolutionPolicy /OK /DownsampleGrayImages true /GrayImageDownsampleType /Bicubic /GrayImageResolution 600 /GrayImageDepth 8 /GrayImageMinDownsampleDepth 2 /GrayImageDownsampleThreshold 1.01667 /EncodeGrayImages true /GrayImageFilter /FlateEncode /AutoFilterGrayImages false /GrayImageAutoFilterStrategy /JPEG /GrayACSImageDict > /GrayImageDict > /JPEG2000GrayACSImageDict > /JPEG2000GrayImageDict > /AntiAliasMonoImages false /CropMonoImages true /MonoImageMinResolution 1200 /MonoImageMinResolutionPolicy /OK /DownsampleMonoImages true /MonoImageDownsampleType /Bicubic /MonoImageResolution 1200 /MonoImageDepth -1 /MonoImageDownsampleThreshold 2.00000 /EncodeMonoImages true /MonoImageFilter /CCITTFaxEncode /MonoImageDict > /AllowPSXObjects false /CheckCompliance [ /None ] /PDFX1aCheck false /PDFX3Check false /PDFXCompliantPDFOnly false /PDFXNoTrimBoxError true /PDFXTrimBoxToMediaBoxOffset [ 0.00000 0.00000 0.00000 0.00000 ] /PDFXSetBleedBoxToMediaBox true /PDFXBleedBoxToTrimBoxOffset [ 0.00000 0.00000 0.00000 0.00000 ] /PDFXOutputIntentProfile (None) /PDFXOutputConditionIdentifier () /PDFXOutputCondition () /PDFXRegistryName (http://www.color.org) /PDFXTrapped /False

/SyntheticBoldness 1.000000 /Description >>> setdistillerparams> setpagedevice