Blog of Joos Buijs

About personal things, process mining and the rest in life.

Posts Tagged ‘GUI

ProM 5 versus ProM 6

with 6 comments

About Precisely a week ago I read the ‘How to Get Started With Prom‘ blog post on the Fluxicon Blog (err, ‘Capacitor‘). In this blog post Anne explains how an event log can be constructed, using Nitro in this case, then inspected and finally how a process model can be mined and animated using ProM. Overall, the blog post is very nice, as are all posts at the Fluxicon Blog.

There is however one thing I noticed when I was half-way the post: they use ProM 5! At first I thought, why? I mean, ProM 6 is ProM 6 after all, it’s not 4.5, it’s not 5.3, it’s 6! Therefore, it should be better than 5. Furthermore, Fluxicon, especially Christian, had a great influence in the development of ProM 6: Christian designed the new slick user interface of ProM 6 and also developed XES, the new event log standard on which ProM 6 is based (with backward compatibility with MXML which is used in ProM 5). Furthermore, ProM 6 uses ‘packages’ to wrap plug-ins. Packages can be installed and updated independently of the framework therefore allowing plug-ins to be updated by the authors independently of the release cycle of ProM 6.

So, I wondered, why explain new users how ProM 5 works? Shouldn’t you point them to ProM 6? Let them use the newest process mining tool, the state-of-the-art, with all its improvements. I’m not saying that ProM 5 is bad, of course not, but ProM 6 is better. Or is it?

Of course, I could have emailed Anne this question and I would have received a reply but I want to make this a public discussion. Why/when would you use ProM 5 instead of ProM 6?

Well, I can give a couple of reasons but I would sure like to know yours. And, of course, especially Anne’s reasons for introducing ProM 5 to our new process miners instead of ProM 6.

So, in summary, I believe that the benefits of ProM 6 compared to ProM 5 are:

  • Better graphical interface which is nicer than the one of ProM 5. The main new feature of the GUI of ProM 6, in my opinion, is that it’s object based. A plug-in requires certain object (types) and produces certain others. This allows for dynamic ‘chaining’ of plug-ins, each plug-in taking the analysis one step further;
  • Separation between plug-in and ProM 6 framework. You can choose which plug-ins / packages to install and updates can be made more frequent and independent of the ProM 6 framework updates;
  • Support for the new XES event log format but also still supporting the well-known MXML format;
  • Separation of GUI and execution, if a plug-in crashes the framework keeps running in most cases. Furthermore, it also allows for easier ‘grid deployment’ than ProM 5;

However, at the moment, ProM 5 has more (how much more?) plug-ins to offer. Each ProM 5 plug-in needs to be updated by the author (or a student) in order to run in ProM 6. So if you plan to do sophisticated analysis you might want to keep ProM 5 installed.

To conclude, I think that new process miners should be introduced to ProM 6. The usability is better than that of ProM 5 although for both you need a learning period.
For those more advanced in process mining it is necessary to switch between ProM 5 and ProM 6, depending on the type of analysis you want to perform. Hopefully most of the ProM 5 plug-ins will find their way, some with improvements, to ProM 6.

But, that’s only my opinion, what do you think? Do you think ProM 6 can replace ProM 5 yet? Do you point a new process miner to ProM 5 or ProM 6? And did I miss any (dis)advantages???
Let me know either in a comment on this post, the post at the Fluxicon Capacitor or maybe in a dedicated discussion on LinkedIn.

Looking forward to your opinions!!!

Joos

Advertisements

Written by Joos Buijs

November 22, 2010 at 14:36

The preliminary results are in…

leave a comment »

…and it looks good 🙂

The first preliminary results are those of my intermediate presentation of December 15. It went well, although there is always room for improvement of course. I managed to have a working version of my application by then so that was nice to show. Furthermore, there were actually people there besides my supervisor, tutor and third committee member.

The other preliminary results are the first XES event logs generated by my application. Although generated from a ‘single table source’ using a rather straight forward mapping, it is promising and rewarding to see your event log being loaded in ProM (version 6) and everything works.

Enough work remains to be done, some small (e.g. change some texts in the user interface) others larger (e.g. ordering of events in the event log and automatically linking those tables used in the mapping). But on the other hand, I still have more than a week to implement those functions and completely test my application. For comparison: I needed 2 weeks to build my user interface and update my domain model accordingly. Another 2 weeks where needed to get as far as I am now.

Since the GUI is rather stable I think I can show it to you. So, here it is:

Basic user interface of the XES mapper appication

As you can see, it consists of three main parts: The bottom part is for the ‘general mapping settings’ such as a name and description, the connection settings to the data source, managing the XES extensions (shown in the screen shot), console output and executing the mapping. The top left part is for navigating the mapping definition, here you can select the element (log, trace, event or attribute with ‘children’) you want to edit. The top right part allows you to add, edit and delete attribute definitions (shown in the screen shot), define some mapping properties and for the log specify the event classifiers (you probably have no clue why you want those but don’t worry, you’ll learn in the documentation of the new XES version).

Also, I think that, now I know the application is likely to be born without complications and is likely to survive, I can think of a (nick)name for my baby… I have a nice one in mind but I won’t announce it just yet, you’ll see it at the release.

So, the next week(s) I will add some more functionality to the application, test it thoroughly on test data and eventually on case data. And I will also work on the most exciting part: the thesis! I don’t mind working on the thesis, it is probably the most prominent result of my labor but its not, well, exciting… Programming is nicer, there you can hunt bugs, search for performance improvements and play with your creation. A thesis is just a thing that sits there and you can look at it. Luckily I’m writing it in LaTeΧ so I can still have compiling errors and won’t have to fight with a Word processor.

Well, for now I wish you all a nice Christmas holiday and a very nice New Year in case I don’t blog in the next 2 weeks.

ttfn!

Joos

Written by Joos Buijs

December 18, 2009 at 16:50