Диссертация (1137084), страница 28
Текст из файла (страница 28)
Despite its promisingflexibility and convenience, in practice it is generally easier to use conventional method invocations,because the API exposed by the plug-in manager is a bit unintuitive. Furthermore, direct methodscalls ensure more readable code. Because of these reasons, the direct methods call are preferredin our tool and used wherever possible. For example, the model in Figure 3.5 visualized by aninstance of the standard Petri net visualizer called from the PetriNets package4 .The framework allows users to take an advantage of reusing previous executions of plug-ins viamechanism of so-called connections.
In fact, connection is an object which holds a number of dataobjects in the weak hash map. A connection can be reached after its registration in frameworkcontext by any other plug-ins using the connection manager. It takes one argument and searches4This package is available in the repository: https://svn.win.tue.nl/repos/prom/Packages/PetriNets/118for all the connections which hold specific parameter. The mechanism of connections allows us toprocess data outputted from one plug-in by another one.The core part of a typical ProM 6 processing plug-in is a Java class which contains atleast one public method. This method must have a special annotation which registers it in theProM 6 framework as a plug-in.
The name, input and output parameter lists are listed inside thisannotation. A particular plug-in context of current ProM 6 session has to be among the otherparameters of the method.The tool — which implements the modular repair technique presented in this work — is builtas a plug-in for the ProM 6 Framework. Therefore, an architecture of the tool fulfils all theaforementioned requirements for ProM 6 plug-ins. We decided to use such an approach becausethe framework already has plug-ins which take care of discovery of Petri nets, import and exportof event logs, conformance checking as well as log decomposition plug-ins, and provides furtheropportunities to work with the resulting data.Modular Strategies for Process Analysis and Scientific Workflow AutomationThe key component of the presented repair technique is its modularity.
Modular strategiesalready have been applied in process mining. This section gives a short review with main referencesto related papers.Recently, modular approaches has been considered by S. Shershakov [174, 175], R. Mans et al.[176], W. van der Aalst et al. [177] The idea of providing a way to chain executions of several plugins or algorithms in a handy way is also similar to a concept of scientific workflow systems [178].Two of such systems capable of dealing with process mining are considered here.The first one — RapidProM 5 [176,177] — is a ProM extension for RapidMiner 6 , a tool for dataanalysis automation.
It allows users to build plug-in chains in a visual way. Quite a number ofProM Plug-ins are available in this extension, however not all of them. It can easily be installedvia RapidMiner Marketplace. This instrument has been developing rapidly in recent years.The second system is called DPMine/P framework [174] and is based on DPMine WorkflowLanguage 7 [175]. It provides a new modelling language which natively supports notion of execution.Implementation of the ideas defined in the language are written in C++ with usage of Qt library.Process models can be constructed using convenient graphical user interface.
Furthermore, thesolution is intended to be easily extended by adding plug-ins. The advantage of using C++ ispossibility to utilize resources in more effective and flexible way and provide better performance,which is of high importance in the era of Big Data, but the downside is that it cannot be integratedwith ProM, so it is deprived of algorithms the ProM system offers.5RapidProM page: http://www.rapidprom.org/RapidMiner page: https://rapidminer.com/7DPMine page: https://pais.hse.ru/research/projects/dpmine6119Yet another tool emerged in 2017. BupaR 8 is an open-source set of eight packages for Rprogramming language [179]. This tool is rather young but fast-growing and convenient.
However,due to its youth, it lacks in algorithms available for user.All these tools have their advantages, the main of each is flexibility. However, all of themlose ProM in a number of available plug-ins. In particular, alignment-based conformance checkingalgorithms were not implemented in these instruments at the time of our study. Thus, the modularrepair prototype has been implemented as a ProM plug-in.Tool ArchitectureNow, let us look under the hood of a plug-in that implements the modular repair technique.The plug-in has several building blocks connected with strong links, which follow the general repairscheme from Section 2.2. There are place-holders in it where a user can put one of the appropriatealgorithms.
Place-holder blocks are the following: (1) conformance checking, (2) decomposition,(3) selection, (4) repair, (5) composition, (6) final evaluation.A conformance checking block is used to evaluate current progress of the repair process andindicate whether a current log-model conformance is sufficient. Moreover, the algorithm placedin this place-holder is used to select model fragments which will be repaired. An algorithm ina decomposition block is responsible for dividing an entire model into smaller parts.
A repairblock can be either a process discovery algorithm or some enhancement algorithm, although forgeneralization reasons we call them repairers. Once the decomposed parts are repaired they oughtto be merged in order to form a single model. It is done by a composition algorithm. An algorithmlocated in a final evaluation block is executed after completion of the entire repair task. At thisstep several metrics are measured in order to assess the characteristics of the repaired model. Thestep may be skipped.At the first step, the tool checks whether a model and a log conform to each other. Thesecond step is one of the model decomposition methods that allows for splitting the model intosub-models [180]. At the third step, our tool selects conforming and non-conforming sub-modelsusing a conformance checking method with each sub-model, obtained at the second step, and asub-log built by the projection of the complete event log onto a set of activities correspondingto this particular sub-model.
The fourth step is model repair. At this step, our tool applies therepair algorithm that can be, for example, a basic discovery algorithm. By applying it the toolsynthesize a new sub-model from the sub-log corresponding to a non-conforming fragment of theinitial model. At the fifth step, the tool composes all sub-models into the final model using thespecified method. The sixth step is the final evaluation of the repaired model.One of the main requirements for the tool architecture is to be as straightforward andcomprehensive as possible, though ensure that it is flexible. In addition, we want to reuse asmuch of the existing solutions as possible.8BupaR Official page: https://www.bupar.net/120The tool is build to be supportable and expandable. That is why it supports a wider set ofalgorithms than has been described in Chapter 2. Experiments with some of them is a subject ofthe future work.Fortunately, many process discovery and conformance checking algorithms were alreadyimplemented in ProM 6 before the beginning of our project.
We separated plug-ins, which weintended to use, into three following groups according to their coupling with ProM and thesimplicity of their reuse.I. Plug-ins whose execution needs requesting via the plug-in manager of ProM 6. Hence, in orderto call them we supply plug-in name, a list of required parameters and types of expected output.Then the plug-in manager seeks the requested plug-in and executes it. Examples of such plug-insare Alpha miner [42] and ILP Miner [24].II. Plug-ins whose execution can be initiated via usual Java method calls without need todelegate this task to the ProM 6 plug-in manager. Genetic miner [43,72] and Heuristics miner [65]can be placed in this group of plug-ins.III. Plug-ins whose architecture follows the MVC pattern [181]. They are characterized by clearseparation of the actual algorithm and ProM-specific parts.
Such plug-ins are more desirablebecause their usage and extension requires less time and effort. Unfortunately, Inductive miner [23]is the only discovery plug-in which completely falls into this category.The study of the plug-ins showed that most of them require setting of the parameters via sometype of GUI. The Alpha miner is the only one that does not show GUI, whereas others do butmost of them have a single screen with settings, which allows for significant simplification of theresulting design decisions.The situation with existing decomposition plug-ins is a bit easier despite some nuances. Firstof all, they are highly-sensitive to the input data. Event logs may include a lot of information inorder to simplify further log analysis.
ProM 6 plug-ins responsible for projecting a net on an eventlog log are aware of this information and try to make full use of it while projecting a net. Despiteits high purpose, it is prone to produce rather unexpected outcome. A projection gives a correctpredictable result if an event log contains information only about event names. Concerning thisissue, it is absolutely essential to apply some kind of model and event log preprocessing techniquesbefore trying to decompose a model.
Furthermore, model decomposition is typically not a one-stepprocess — it requires a number of consequent plug-in calls.On the other hand, all decomposer plug-ins may be executed without showing GUI. In fact, onlySESE Decomposer [105] has one. Moreover, we implemented Maximal Decomposer (see Section 2.3for the algorithm) to be usable within the tool.121The tool abstracts from specific implementation details, and provides a common interface forusing these plug-ins. Each of three plug-in types (a model repairer, a model decomposer, and aconformance checker) has its own interface, unique for its specific nature.
To use a plug-in withinour tool, one has to write a so-called wrapper interface and the corresponding wrapper class. Awrapper is understood as a class that defines a common interface and hides the details of howactual plug-in is invoked. In fact, the concept of the Adapter pattern [182] is exploited.
The toolworks only with such wrappers without knowledge how inter-plug-in communication is carriedout. Furthermore, wrappers apply an idea of using Java annotations, which allows for completedeliverance from dependencies of the tool on wrappers and, hence, on external plug-ins. Thisapproach also facilitates extension of the tool: those who are willing to incorporate new algorithmsdo not need gaining access to the source code of the tool. The only thing that has to be doneis to create a Java class that extends either IskraDecomposer or IskraRepairer interface, andmarked by the corresponding annotation (either @IskraDecomposer or @IskraRepairer).
If so,ProM 6 Framework will detect this class and our tool will add it to the list of available algorithms.The one important technical constraint is that wrappers must have an empty constructor. If awrapper does not have it, the wrapper will not be available.<<Interface>>AbstractIskraPlugin<<Interface>>IskraRepairer+repair(PluginContext, Log): Petrinet+getSettingsComponent(): JComponent+saveSettings(): voidInductiveRepairerILPRepairerFigure 4.2: Repairer classes hierarchyFigures 4.2 and 4.3 depict the design of repairers and decomposers correspondingly. A classAbstractIskraPlugin is a common superclass for all implemented wrappers.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
