Диссертация (1137084), страница 29
Текст из файла (страница 29)
It encapsulates plugin’s name and indicates that it is a plug-in. Then, there are two abstract classes IskraRepairerand IskraDecomposer which provide a common interfaces respectively for repairers anddecomposers. The tool uses only links to these classes, not to their subclasses. The architecturehas been implemented and proved to be viable.
Classes InductiveRepairer, ILPRepairer,MaximalDecomposer, PassageDecomposer [183] are examples of actual (not abstract) algorithm122wrappers. In order to save space and make a picture more comprehensible only these classes areshown, however half a dozen of others adhere to the architecture and available in the tool.<<Interface>>AbstractIskraPlugin<<Interface>>IskraDecomposer+decompose(PluginContext, Model): DecomposedModel+getSettingsComponent(): JComponent+saveSettings(): voidMaximalDecomposerPassageDecomposerFigure 4.3: Decomposer classes hierarchyThe typical scenario of using wrappers is as follows:1. the method getSettingsComponent is invoked;2.
if the value returned after the invocation of getSettingsComponent is not null, then thereceived GUI is displayed to a user;3. a GUI component means having to save setting by invoking the saveSettings method;4. at this point, a plug-in is properly configured, and is ready to be used; the only one thingleft to get result — to invoke either (repair) or decompose method correspondingly.It must be mentioned that steps 1-3 are arbitrary. If a user is either satisfied with default settingor does not want to show GUI then according to the contract, a wrapper supplies default settingsto a corresponding plug-in.
If a plug-in does not have any graphical component for settings, thengetSettingsComponent returns null and steps 2-3 are skipped. In case of repair, an object oftype DecomposedModel is returned. It holds sub-models and corresponding sub-logs.A number of algorithms for conformance checking is limited by two in this thesis (seeSection 1.2.2): the first algorithm that uses model replay, and the second one using alignments.Moreover, only an alignment-based algorithm has been used to conduct experiments.
Thus, thereis no urgent need to provide very flexible solution. Implementations of both these algorithmsare present in the tool. The alignment-based algorithm [22] is used as a primary conformancechecking algorithm. In order to allow convenient and user-friendly usage of this algorithm, thecorresponding plug-in has been modified slightly. We partly separate it from ProM 6 in order to123ensure plug-in’s robustness. Moreover, parameters of the plug-in include information on a modelwhich is about to be used and the original parameter creation mechanism does not permit to createit silently, without showing GUI.
Because of that reason, we supplemented parameter classes withcopy constructors which take a new model and copy an existing parameter adhering it to the newmodel.All discussed cells are parts of the abstraction called repair chain. It represents the very natureof the decomposed repair approach.
Each chain implies algorithms which correspond to the blocktypes, then it makes plug-in calls in the specified order ensuring the work of the tool. The goalof designing repair chains is to make a good level of abstractions from which algorithms are used,how they are used, in which order; and to execute every chain with different models without needto reconstruct the chain. In order to achieve these objectives, the idea of dependency injectionsis heavily exploited in the tool.
Decomposition and repair plug-ins are supplied via constructorinjection, whereas a model, a conformance checking algorithm and its parameters are providedas a method parameters. This discrepancy has rather ordinary explanation. Decomposition andrepair algorithms represent something stable which can be reused over and over again withdifferent models in a handy manner. In contrast, a model, a conformance checking algorithmand conformance checking parameters are volatile and tightly coupled.Introducing a new data type that encapsulates blocks tend to make the tool more flexible andeasier to modify, maintain, and extend because of the following reasons.Using abstract data types and dependency injection during the development ensured that eachparticular chain may be implemented in a way which differs a lot from others.
For instance, repairchains may use different triggers to decide when a repaired model is good enough 9 , although themain reason for having separate repair chains is a fact that there are a few of possible strategies ofhow to choose a model fragment to be repaired. Some strategies are straightforward — just takea part with the worst fitness, whereas others may use sophisticated techniques, preprocessing andmore intelligent choice. However, different repair chains are possible and that the tool providescapability of introducing new repair chains.A user may create several chains with different algorithms used in blocks, and then run all ofthem at a time. This feature makes an experiment with several algorithms and their parametersagainst the same process model easier. The plug-in Iskra chain generator is responsible for creatingrepair chains — one selects desired repair chains, algorithms and their parameters.
In contrast witha main Iskra plug-in that creates a chain, and then immediately executes it, the chain generatorreturns a list of configured chains to the ProM 6 resource pool rather than execute them. At themoment when all desired chains are built, one may supply them to Iskra chain runner plug-in.This plug-in takes an arbitrary number of repair chains, a model, and a corresponding event log.9Note that our tool supports threshold levels for desired fitness or precision of the repaired model. In case, auser specify 1 threshold, the plug-in works according to the scheme that has been described in Section 2.2, andprovides the repaired model with perfect fitness.
However, our plug-in allows for a more practical approach, whenwe need the fitness level higher than the specified threshold level, but less than 1. Currently, this is an experimentalmode of the plug-in. It will be evaluated and fully developed in the future.124After that, the plug-in configures settings of conformance checking, and sequentially executes eachchain. This functionality has already been implemented, although it needs some refinement andimprovements.In order to have flexible chains, a mechanism of annotations and reflective calls is introduced,as used for decomposition and repair wrappers.
It enriches our tool with the ability to load repairchains dynamically. Moreover, it lets other developers and researchers to develop new chains,and incorporate them in the tool. A Java class which implements a repair chain has to extendRepairChain interface, and to be annotated with @Chain.This section described a prototype tool for the modular process repair technique. The toolis implemented as several plug-ins for ProM 6 Framework. The way the tool is written allowsfor its improvement and enhancement.
The tool can be found at the page of this project: http://pais.hse.ru/research/projects/iskra. Besides, it is open-source and its code is availableat the page: The next section describes experiments conducted with the modular process repairwhich were conducted using presented Iskra tool.As it has already been mentioned, process mining is a practical and an empirical field withinthe larger area of data analysis, specifically devoted to the event data. This practical nature leadsto a need of experimental evaluation in addition to theoretical proofs.
In the remainder of thischapter, we describe an experimental evaluation of the process model repair technique that hasbeen described in Chapter 2.4.2Description of the Experiment and Input DataThe goal of experimental evaluation is to apply a prototype implementation of an algorithmto test samples, and measure the characteristics of repaired models. These results may showadvantages and disadvantages of an algorithm when it is applied to samples with particularproperties. Chapter 2 described three following model repair techniques which are based on thesame general scheme: basic, improved, and greedy algorithms. Each of these techniques should beevaluated.A natural way to test or evaluate repair technique is as follows.
Take a correct (serviceable)object , introduce artificial inconsistencies in it ( ), and then try to repair it using theevaluated/tested technique. If is works as expected, then the repaired object should work(service) as the initial object does. Otherwise, the test is failed. The result of such a repair canbe evaluated using suitable measuring tools. Results of different experiments may be compared.In this section, we follow exactly the same way to evaluate the modular process model repair.Figure 4.4 shows an experimental scheme used to evaluate the repair techniques.To evaluate desired properties of repair algorithms, sample models and corresponding eventlogs need to be carefully selected.
Therefore, it is more preferably to use fine-tuned process models125Sample ModelEvent LogGeneratorEventLogProcess ModelRepairChangedModelRepairedModelEvaluationResultsFigure 4.4: Scheme of the experimentmanually broken in a way to contain local and non-local inconsistencies, and artificially generatedevent logs. Real-life examples with suitable characteristics can hardly be found.Two artificial workflow nets are selected as samples: SM1-CM (see Figure 4.510 ) and LM2-CM(see Figure 4.6). These workflow nets represent basic process patterns: sequential tasks, loops,alternative choice, and concurrency. Models are sufficiently large to be compared with real-lifeprocess models11 , especially LM2-CM model.Figure 4.5: Sample model SM1-CMModels have the following characteristics.SM1-CM consists of 19 places, 21 transitions, 46 arcs.
We also calculated the four metrics for amodel: Extended Cardoso Metric (ECaM ), Extended Cyclomatic Metric (ECyM ), Density (Dens),10This and other figures in high quality, and corresponding Petri nets are available at the page of this project:http://pais.hse.ru/research/projects/iskra.11For example, both models are larger than most models from above-mentioned Signavio models collection.126and Structuredness (Struct) [184].
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
