Inductive visual Miner(IvM)

Inductive visual Miner

Inductive Visual Miner (IvM) [5] will businessProcess discoveryversusConsistency checkTogether, it provides users with easy-to-use process mining and exploration tools.

Given an event log, Inductive Visual Miner will automatically discover a process model, compare the model with the event log, andVisualizationSome enhancements, such as performance measurement, queue length and animation. All steps are automated: if you change any parameters or change any filters, IvM will automatically update all necessary content.

IvM can be started by loading the event log into ProM and applying the plug-in "mine with Inductive visual miner". Or, if you already have a process tree and want to compare it with the event log, use the plugin "Visualise2".

"Deviation on the Process Tree" can start IvM without mining controls and options, but with route, deviation, animation, and highlight filters.

Process tree

Six types of nodes:
1.

• xor means itsOne of the descendants needs to be executed. For example, the process tree in Figure 1 indicates that a "check claim" or "payment" must be executed.

2.

• sequence means itsAll children need to be executed in order. For example, Figure 2 shows that first is "check claim", and then "pay" must be executed.

3.

• interleaved means needExecute all its children, But these implementationsCannot overlap in time. For example, Figure 3 indicates that "check claim or "pay" must be executed, but it must be completed before another can be started.

4.

• concurrent said itsAll children need to be executedAnd theyMay overlap in time. For example, the process tree in Figure 4 indicates that "check claim" or "payment" must be executed independently of each other.

5.

• or meansAt least one of its children needs to be executed. If multiple children are executed, they areMay overlap in time. For example, Figure 4 indicates that "check claim" or "payment" or both must be executed. If the "check claim" and "payment" are executed at the same time, then these executions are independent. Belong to inclusive choice

6.

• loop meansMust perform the first child. After executing the first sub-item, you can choose to terminate or execute the second sub-item again, then execute the first sub-item, and then make the same choice again. For example, the process tree in Figure 6 indicates that "check claim" is always executed. After that, "pay" followed by "check claim" may be executed repeatedly

Controller and parameters

Active slider

Active slider control appliedDiscover the active part contained in the event log of the algorithm. In other words, the event log will be filtered before discovery . The position of the slider (between 0 and 1) is determined to show that many activities remain in the filtered event log. For example, the log [<a, b, c>, <a, b>, <a >] has a frequency table [a3, b2, c], if the activity slider is set to 0.4, all events corresponding to the occurrence of activities exceed 0.4 times the most frequent event. In the example, the filtered event log will be [<a,b> 2,< a >], and the discovery algorithm will be applied to this filtered event log.

In fact, it is to delete the event of insufficient activity.

Please note that this only affects the discovery, that is, all other parts of IvM (including alignment and animation) are not affected by this slider. Set it and the ``paths'' slider (described below) to 1.0 , And set the miner selector to IMf guarantees fitness. However, if the event log contains a complete lifecycle transition, it may also show deviations.

Path slider

Path slider control appliedNumber of noise filters: If set to 1, no noise filtering will be applied; when set to 0, maximum noise filtering will be applied. Technically speaking, the slider sets the input of the discovery algorithm to 1-slider. The default value is 0.8, which corresponds to IMf, IMflc and IMfa noise filtering with 1-f = 0.2. Push the two sliders all the way to 1.0 and set the miner selector to IMf guarantees Fitness. However, the alignment of IvM always considers life cycle information, so there may still be deviations.

Category selector

Classifier selector controlFactors that determine event activity: Events in the XES log can have multiple data attributes [3], and the selector determines which of these data attributes determines the type of activity. You can use the checkboxes to select any combination of event attributes.

Filter switch before excavation

The pre-mining filter switch opens a panel to set the pre-mining filter. The pre-mining filter will not change the alignment, performance indicators or animations, but will filter the logs used to discover the model . To activate the pre-filter, select its check box. For example, the pre-filter "tracking filter" allows only customers who spend more than 10,000 to discover models.

Digger selection

Digger selector allowsChoose the mining algorithm to use. The default is IMf , and other options included are life cycle algorithms IMflc, IMfa, and dirrectly-follows miner. We limit the user's choice: In the evaluation of [4], these algorithms proved to be most suitable for real-world event logs .

Edit model

The Edit Model switch will open a panel to manually edit the discovered model as described below. If the result is not satisfactory, this allows the user to correct the discovery algorithm and try the effects of different custom models on the same event log.

Visual mode selector

• paths : default mode, display model; activities and numbers on the side indicate the total number of executions of each activity
• Path and deviation display model : The number in the activity represents the total number of executions of each activity. In addition, the red dashed edge indicates the result of the alignment: Figure 6b shows the model movement, indicating that the activity record was skipped once in the event log, and the model said it should have been executed. Figure 6c shows a log movement indicating that 9 events in the event log occurred in the event log after the execution of activity b, and this event should not occur according to the model.
• Path and queue length : shows the model and represents the length of the queue before each activity, that is, the number of cases waiting for this activity to start. If the event log contains two events with enqueue and start life cycle information, then the queue length is accurate. Otherwise, use the method described in [6] for estimation. As the animation progresses, the queue size will be updated.
• Path and stay time : display the model and use the average stay time of the activity to represent each activity. Use completion events to calculate dwell time. No dwell time is estimated, that is, if two required completion events do not occur simultaneously and there is no time stamp, then the active instance is excluded from the average. You can also check the performance indicators by placing the mouse cursor on the activity: a pop-up window will display the performance indicators and histogram. After applying any log filtering, performance indicators will be updated automatically
• Route and service time : display the model, and represent each activity with the average service time of each activity. Use start and finish events to calculate service time. The service time is not estimated, that is, if the start event and the completion event do not exist at the same time and there is no time stamp for an active instance, the active instance is not considered as an average value.

ctrl+dkeyi change the direction of the model