Sometimes I get ideas I don’t have to time to execute. Instead of just abandoning them, I thought I’d write a notice about them and let them be up for grabs.
One such idea is a plug-in for automatic log-extraction from CPN models in ProM. There already is a library supporting this, but it requires quite tedious annotation, use of the quite antiquated ProMimport tool, has a large start-up cost (as you have to add a lot of annotations just to get an initial log), and it is very difficult to create logs with different perspectives.
For these reasons, I created a quick-and-dirty plug-in for extracting logs from CPN models in ProM. It looks like this:
We can change some simulation options, such as the number of steps to execute for the model and how many times to repeat simulation. We can also give a mapping from model-time to wall-clock time by giving an offset and a granularity. Executing this model using these settings but with 50 repetitions, we obtain a log like this one:
We see that we have some log, but that a lot of the properties are not really too sensible. For example, for, it would make more sense to map the instance to the package sequence number and map the resource to sender or receiver instead of the transition. Also, the start and complete transitions are not too sensible, as the start event should occur at the model-time where the transition is executed and the completion time should (probably) be the time-stamp on the transition itself.
So, my suggestion is to create a more generic plug-in for this. The plug-in should make it very easy to make a log quickly without cluttering the model.
The plug-in should first let a user choose the transitions to keep visible. This is not essential, as the log can subsequently filtered, but still a nice to have.
If the model is timed, it should be possible to select a timing model. Transitions could be mapped to start events, complete events or both.
Then a user should be able to choose a mapping from model properties to log properties. This includes common XES properties, like resource, instance, name, and so on. These should be possible to choose from transition names, transition instance names, variables around a transition, and constant values. This is by far the most complex task. It should be possible to choose among different heuristics for the entire model (e.g., mapping the name of an event to the transition name or mapping resources to the “most sensible” variable), but also to choose properties individually from each transitions. A sensible default should be automatically selected.
Here are some suggested mockups. First, the transition selection screen:
Inspired by the selection screen from the log filter. Only selected transitions here are used on the following screens. Next, the timing options screen:
We set offset and granularity, e.g., as in my current plug-in, but also has control over whether to create start/complete events or both. We may also need some options for choosing how complete events are generated if both start and complete events are chosen (otherwise the time-stamp would just be the time of transition execution using the granularity and offset). The mapping screen:
This has options to save and load the mappings so a user only has to make a mapping once. The idea is that of a table where the columns are event properties and the rows are transition instances. The table headers are drop-downs that allows to set a property for all transition instances:
The drop-down contains entries for (at least) transition name, transition path (unique for each transition instance), a constant value, and a transition variable. If the latter is chosen, the most appropriate variable is automatically chosen for all transition instances (e.g., using string similarity, so for the property “resource” a variable “r” or “res” would be preferred over “n” and “task”). Constant would prompt for a constant value and use that. These drop-downs could also act just on a selected subset of the table. Each cell of the table also contains drop-downs:
We would have the same options, except we would get a full list of variables. We could also be allowed to select only parts of variables, e.g., the first entry of a pair or the “resource” entry of a record. The types can be known to the plug-in.
Alternatively, all of this could be combined to a single screen:
The idea is the same as for the previous mapping screen, except now, if neither start or complete is chosen for an event, it is just not shown. The start/complete columns could be merged to a single column for setting the lifecycle:transition property, having options none, start, complete, both). We would probably still need a way to specify timing offset/granularity.
This is just an idea of something that would be useful and not too difficult to make. I’m sure a lot of other useful options can be envisioned.
Time person of the year 2006, Nobel Peace Prize winner 2012.