Flexible Heuristics Miner - Visualization; Join/Split Selection; PetriNet Mapping

mardo

Hi,

I have a couple of questions regarding the flexible heuristics miner resp. its implementation in ProM6:

• Can you tell how the selection strategy for the splits/joins in the augmented C-Net is implemented according to http://cms.ieis.tue.nl/Beta/Files/WorkingPapers/wp_334.pdf? Sorry if there's a misunderstanding from my side, but I also did not get how exactly the split/join gateways are derived from the augmented C-Net. Is it as straightforwards as in http://is.tm.tue.nl/staff/aweijters/LNCS3812.pdf (p.5) or more sophisticated? And are the low frequent patterns in the augmented C-net taken into account? If not, what's the threshold?
  
• I saw that a student has already examined mapping heuristics nets to BPMN (http://code.google.com/p/masterthesis-plugins/source/browse/trunk/+masterthesis-plugins/BPMNCorversion/src/org/processminig/plugins/converter/HeuristicsNet2BPMNConverter.java?spec=svn12&r=12), and generally plugins for heuristicsNet to PetriNets already exist. However, from my gut feeling I’d say that you need to put in some additional assumptions for such mappings in order not to produce inconsistent models with AND-XOR / XOR-AND blocks (this is at least what I got in small experiments). Are you aware of any written elaborations on these issues?
• Using ProM6 (nightly build), I’m still not able to reproduce most of the results visualization as documented in http://prom.win.tue.nl:8000/Tracsites/export/5186/public/ProM/Releases/BPM 2010/Test Reports/Package HeuristicsMiner - Test Report Joel Ribeiro.docx and http://cms.ieis.tue.nl/Beta/Files/WorkingPapers/wp_334.pdf , e.g. the “parameters tab” does not appear, the split details cannot be displayed etc.Am I doing something wrong or is this some “not yet public” functionality?
  

thanks

markus

jribeiro

 Hi Markus,

 The splits/joins mining follows exactly the strategy presented in http://cms.ieis.tue.nl/Beta/Files/WorkingPapers/wp_334.pdf. As far as I know, the paper LNCS3812.pdf has nothing to do with this strategy. Currently, every pattern is taken into account. Actually, since split/join pattern tables are ordered by frequency, the low-frequent patterns are useful to check - for instance - whether we have noise or not.

 Can you provide me a small example where you need some assumption to avoid inconsistency? My feeling is that the current converters do not generate the simpler Petri Net (i.e., a lot of redundant hidden places are generated) but the splits/joins are converted well.

 The visualization with annotations (equivalent to the WP334 paper's one) was released last month. Remark that this is not the default visualization. So, after generating the augmented C-Net, just select "Visualize Causal Net with Annotations" in the combo box above the result view.

 I hope my answers are clear. If not, please let me know!

 Cheers,
Joel

mardo

Hi,

thanks for your answer.

I meanwhile got the visualization running. The key was to start -everything- (package manager, prom, ...) in Adminstrator Mode in Windows 7, otherwise some required classes are not found.


I however still have problems understanding the counting and split/join conversion for FHM results from the augmented C-net.
For example, is a trace ABAC counted as A->B A->C; or A->BC A->C; or ...? From the descriptions in the paper I would guess the first one, but I didn't find any explicit mentioning in the paper (sorry again if I missed something).


Second, I have attached an example for one of my mining results (with anonymized tasks). You said in your last post that also the non-frequent patterns are taken into account. So I would expect that the split gateways after A model a behavior as "at least one or both" of B and C. However, from the converted net (right handside) I would tell that C always gets activated by A. Is there any error in my interpretation?


Thanks alot and best

Markus

mardo

please ignore the attached "livelock".png

jribeiro

 Hi Markus,

 That's right! Assuming that the only input of B and C is A, the trace ABAC originates both the A -> B and A -> C split patterns. The pattern A -> BC would be originated by a trace like ABCA (in this case an empty pattern A -> {} for the second A would be originated as well). The idea is that every non-ending activity in the trace has always one split pattern. Let's say that at the beginning the split pattern of an activity (e.g., Abac) is formed by its outputs (A -> BC). Then, for each output in the pattern (B and C), it is necessary to check whether they appear in the trace after the given activity (the first A) and without any other possible input (e.g., any other A) in between the given activity and the output. So, considering the trace ABAC, the first A is followed exclusively by B (i.e., A -> , while the second is followed by C (i.e., A -> C). (the same logic applies to the join patterns)

 Regarding your second question, I think that something is not right with the conversion. I'd expect to see clearly the three patterns (B, C, and BC) in the picture (right-hand side). Maybe you need to check whether the BPMN converter is working properly.

 Cheers,
Joel