VTMine for Visio: A Graphical Tool for Modeling in Process Mining

Process-aware information systems (PAISs) is a special class of information systems intended to support the tasks of initialization, end-to-end management, and completion of business processes. During their operation such systems accumulate a large amount of data that are stored in the form of event logs. Event logs are a valuable source of knowledge about the actual behavior of a system. For example, they include (i) information about the discrepancy between the real and prescribed behavior of the system, (ii) information for identifying the bottlenecks and performance issues, and (iii) information for detecting the antipatterns of building a business system. These problems are studied in the discipline called process mining. The practical application of the process mining methods and practices is carried out using specialized software for data analysts. The subject area of the process analysis involves the work of an analyst with a large number of graphical models. Such work can be more efficiently with a convenient graphical modeling tool. This paper discusses the principles of designing a graphical tool VTMine for Visio for process modeling, based on the widespread application Microsoft Visio for business intelligence. The features of the architecture design of the software extension for application in the process mining area are presented along with the features of integration with existing libraries and tools for working with data. The usage of the developed tool for solving various types of tasks in modeling and analysis of processes is demonstrated on a set of experimental schemes.


INTRODUCTION
In recent years information systems (ISs) have been actively developed and reach all areas of human activity.This is related with the increased processing power of machines, decreased cost, appearance of novel tools and approaches to developing ISs, and development of the brain market of information technology (IT) specialists.
All this implies acceleration of the business processes around us and increases the amount of data associated with them.To support such processes, a large number of ISs were developed that generated a separate class, called process-aware information systems (PAISs).They comprise complicated distributed software complexes intended for initialization, end-to-end support, and termination of business processes.In the course of functioning, such systems accumulate a large amount of side data stored in logs.Logs may be considered from the technical point of view (system logs) or from the point of view of traces of system behavior concerning the events of the business process (event logs).The latter are a valuable source of knowledge about the real behavior of the system.By comparing the real behavior and the anticipated one, we can detect a huge amount of useful information, such as any discrepancy between the real and desired behavior of the system, bottlenecks and performance issues, and antipatterns of the business system design.
Studying these problems is the main task of the process mining (PM) discipline [1].The stakeholders of this discipline are business analysts, process owners, and data analysts.Its main objects are business processes.Processes are represented by various abstractions in the form of statistical, graphical, and other models and by particular process cases recorded in event logs.

Existing Solutions
The software tools related with the process mining area most frequently mentioned in the literature [8,9] and the software tools developed recently may be divided into conventional groups in the following manner.
Among the ones presented above, only two tools support graphical management of work-flow: RapidProM and DPMine/P.Both are add-ons to the ProM tool.
The remaining part of this article is organized as follows.In Section 1, we consider an object model of MS Visio tool and its features that allow extending this tool for process mining tasks.In Section 2, we discuss the peculiarities of the design architecture of the application for graphical modeling with allowance for specific attributes of process modeling.In particular, in Subsection 2.2, we take a look at the subsystem of experimental modeling DPMine, based on the eponymous graphical language.In Section 3, we present examples of experimental models implemented using the developed tool.Finally, in Conclusions, we summarize the work done and consider directions of future work.

OBJECT MODEL OF MS VISIO TOOL
All components of the MS Visio software, including the user interface elements, are represented as COM classes with exported interfaces and are available for interaction with software extensions developed in the form of macros using the interpreted script language Visual Basic for Application (VBA) or in the form of extensions Visio Add-In in the programming languages of the .NET framework (C#, C++/CLI, etc.).
The main components used for representing a Visio document are the classes Document, Page, and Shape1 .An object of the Document class is a single Visio document loaded into memory, which may be a file with a graphical model of picture (extensions .vsdand .vdx), a file with a collection of stencil elements (extensions .vstand .vtx),or a template file (extensions .vstand .vtx).Documents consist of a flat list of pages each of which is represented by an object of the Page class.Each page contains a collection of figures having graphical representation.In the object model, each figure is put in correspondence to an object of the Shape class.The figures are ordered by the z-axis, which determines their overlap of each other.A figure can be grouping (a group of figures), which makes it possible to build the hierarchy of figures.Each group is regarded as a single figure on the page where it lies or inside another group.

Semantic Attributes of Visio Components
All the three key components of a Visio document are attributed; that is, their appearance, behavior, and interaction with other components are determined by a set of attributes assigned to a specific object.The attributes in Visio are given in the form of a special property sheet.At the level of the object model, work with attributes is carried out by recalling the corresponding properties, fields, and methods in dependence on the type of Visio extension and the programming language.Editing particular attributes is available by means of the special visual editor, property sheet editor.
Attributes of figures, pages, and documents are grouped by their functional intent.For instance, the Shape Transform section contains attributes of some figure determining its geometric dimensions and position on the parent component (a page or a group of figures); one or several Geometry X sections determine the set of graphical primitives used for drawing figures; the sections Line Format, Fill Format, and Text Block Format determine such characteristics as color of line, filling, line style, and font parameters.
The value of attributes of an object can be prescribed by constants, numerical or symbolic literals, or by means of formula expressions, including links to other attributes of this or another object.This allows interrelating the values of the attributes without the necessity of software control.In general, a string of a rather large size can serve as an attribute value.Using long strings makes it possible to serialize an object of an arbitrary structure the data type of which is not the basic one (integer or float, Boolean, string, and some others).The attribute values assigned to any object are automatically serialized and stored as a constituent part of the document in the course of its storing in the long-term memory.
Within this work, the following most important sections are of particular interest: Shape Data and User-Defined Cells.These sections allow assigning additional attributes of the given data types to a corresponding object, and these data types will be associated with the object and automatically stored as parts of the document and recovered at its loading.However, in contrast to standard attributes, using these attributes is optional and is determined by a particular software extension.
The difference between the Shape Data and User-Defined Cells sections consists in their intent.The attributes of the Shape Data section are available for referencing via the control element of the user interface Shape Data Pane.Using this pane, a user prescribes the parameter values associated with a specific figure.For this purpose, each attribute described in this section contains, in addition to a unique name, several parameters determining its visual appearance: data type, type of formatting, displaying, etc.The attributes of this type simultaneously combine the elements of model, configuration, and controller at their consideration from the point of view of the design pattern model-view-configuration (MVC).Examples of such attributes would be the attribute's cost, owner, and date, assigned by the figures of the block-scheme model and the attribute's categories and executors of the task block of the BPMN model.
In contrast to the Shape Data section, the User-Defined Cells section contains the set of attributes with no visual representation and corresponding only to the element model of the MVC pattern.Such attributes are determined only by their name and value, the type of which is universal and requires the corresponding interpretation at software reference to it.The attributes of the User-Defined Cells section are not reflected in the standard Shape Data Pane; however, they are available at the software level and via the direct referencing to the property sheet of the corresponding object.The attributes of this type are intended to perform semantic attribution, that is, addition to some object (figure or page) of arbitrary supplementary attributes not defined by the data types of these objects (Shape and Page, respectively).These attributes are used for prescribing such properties of objects the direct access to which by a user is not required or is undesirable.Examples of models mainly using the attributes of the User-Defined Cell section are the models of the UML family available in the Visio standard delivery.Using these attributes, the behavior of such elements of UML models as Class and Relation is controlled.Prescription of the properties of these objects is carried out by means of special visual control windows containing complicated specialized control elements, the combination of whose values is written in the corresponding attribute or set of attributes at the software level or via the corresponding program extension (add-on).
Program referencing of both types of semantic attributes is conducted almost identically using the unique name of the attribute and the prefix determining the section User for attributes of the User-Defined Cells section and Prop for attributes of the Shape Data section.In the following, we refer to them as the user attributes of closed and open types, respectively.
Employment of user attributes allows not only considering a Visio document as a vector figure, but also providing it with semantic properties.In Fig. 1, we depict an example of the well-known dining philosophers problem [23,24] modeled by a Petri net.In this illustration, we see that the model figure includes several images of well-known scientists and philosophers, each of which is a graphical primitive bitmap image of Visio.These graphical primitives are related with other graphical primitives (black elongated rectangles, circles, and squares) via directed connectors.They altogether form the graphical representation of the Petri net in which the circles traditionally denote positions, squares and rectangles denote transitions, and directed connected denote arcs.
The elements of the user properties of these figures contain named attributes determining their semantic intent: PetriNetType prescribes the type of element (position, transition, or arc); PetriNetName determines the unique name within the given model; PetriNetMarking, meaningful only for posi-tions, determines the current labeling in the form of number of tokens, etc.Thus, in addition to attributes themselves determining the graphical representation, each figure includes additional attributes used by the extension for analyzing Petri nets that allows considering the given graphical model as an abstract model of Petri net with some marking.The considered approach is a basis of the software extension VTMine for Visio.For instance, addition of user attributes to the document level enables determining this document as a document of special type: a document of VTMine for Visio.When such a document is imported, the subsystem of the software extension VTMine for Visio is activated, the corresponding elements of the user interface are loaded, etc. Below, we denote these documents by VTMDoc.Addition of user attributes at the page level makes it possible to note that a given page contains not simply a graphical image, but a graphical model (or its part) for interaction with which the corresponding component or subsystem of VTMine for Visio is responsible.Finally, addition of user attributes at the figure level allows determining that this figure is a constituent part of some model.
Thus, development of software extensions of Visio together with the employment of user attributes for key components of the object model enables extending its capabilities to the tool of graphical modeling.

DEVELOPMENT OF THE APPLICATION ARCHITECTURE: TASKS AND FEATURES
When the architecture of VTMine for Visio was developed, we took into account the following requirements and restrictions: • The application is a COM-extension for Visio (that is, it is a plugin) developed in the programming language of the .NET framework.
• The functionality of the software is extended by plugins (the principle of plugins for plugin).
• The software core contains only basic components of interaction with Visio and does not contain any components specific to subject areas (for instance, the model types).
• In order to use the resources rationally, the application is activated only when working with documents of VTMine for Visio.
The developed application VTMine for Visio is a Visio COM Add-On.The main programming language is C#.Technically, the extension is a number of assemblies formatted as dynamic link libraries, manifests, and other auxiliary files.The main file of the extension is the library ru.xidv.vtm4visio.dll.The path to the directory with this library is denoted by the symbol $(VtmAppDir).The structural scheme of the core components of VTMine for Visio is shown in Fig. 2. Below, we consider the intent and peculiarities of designing the most important components with allowance for the requirements given above.

Visio Extension (Add-On) and Framework of the Application
The main class relating the Visio application (the Application class) with the extension is the ThisAddIn class (VTM4Visio Add-On in the figure).The initialization of the extension is performed by transfer of control to the code of extension at appearance of the Startup event.In the handler of the Startup event, there occurs creation and initialization of the main component of the extension core, the Framework object.
The Framework object may appear in different states.The initial Inactive state means that the framework is not initialized.After successful preparation of the main components, its state is changed to Initialized.This state includes loading of all depenencies of the core component (plugins) in the mode of minimum resource consumption.Upon opening a VTMDoc document, all necessary components are activated, the resources are allocated, the necessary elements of the user interface are prepared, and the framework component transits to the Active state.Finally, after closing all VTMDoc documents, the extension transits to the Ready state, which is different from the Initialized in that a part of resources are activated for a quick start at opening the next relevant document and the Initialized state is different from the Ready state in that the high-cost resources are pulled from the memory.
Upon starting initialization of the framework (from the Inactive state to the Initialized state), there occurs creation of the following core components: logger, centralized component of options, adjustment console, document manager, and user interface manager.At the subsequent activation of the framework (from the Initialized state to the Active state), the following components are created and initialized: resource manager, model types manager, and plugin manager.
Successful loading of the extension implies creation of the extension of the Ribbon control element: a new tab page VTMine is added to it which contains several control components for user interaction with the add-on (see Fig. 3).
The framework is connected to an object of the Visio application by subscription of the framework to the application events, including the events of creation, opening, closing of a document, the events of window switchings and changing the active window, the events of adding and deleting a page and a figure, the events of changing the active page and changing the selected components, and so on.The special event MarkerEvent allows centralized processing the activation of the points of user context menu of figures and pages, which is an important element of interaction between the elements of user-developed models and the components of the extension processing such models.
A hierarchical system of event propagation is used in the application.This means that the events generated directly by the object of the Visio application are processed only by the framework that delegates their further processing to the corresponding components or processes them itself.No other components VTM4Visio add-on Visio app of the system are subscribed to the application events, which allows controlling the order of their processing and avoiding the issues related with uncertainty of the order of their processing.The last is extremely important when we take into account the possible presence of other Visio extensions installed.

Document manager.
Management of the active documents of the Visio application is carried out by the Document Manager component.It is the main handler of the following events: creation of a new document, opening of an existing document, and the event before closing of an opened document.When the first two events appear, the document manager checks whether the created or opened document is specially labeled.To do this, it reads its user attribute VTMDocument, which determines the fact whether this document is a VTMDoc document.At first referencing to this type of documents, the framework is activated to the Active state.
Creation of a VTMDoc document has its own peculiarities.Visio has several ways for creating a new document.A user can create a new document on the basis of a template or an empty document.In the first case, the attribute VTMDocument is added to the template, so all documents created with it will also be regarded as VTMDoc.In the case of creating an empty document, setting any user attributes is impossible.To simplify the procedure of creating a VTMDoc document without using a template, there exists a button Create in the tab page VTMine of the ribbon (see Fig. 3).
The usage of semantic attributes allows embedding a great amount of service information relevant to the VTMDoc documents directly into the document file.Nevertheless, in the course of modeling, largesized resources are often created, and their storage via embedding to the document makes no sense.To relate a file of the VTMDoc document with external resources used by it, we developed an approach of representing a VTMDoc document as a solution, as it appears at joining several related files with source codes into a single program project.To this end, the file of a VTMDoc document (with the extension .vsd) is considered to be the main file of the project, which is supplemented by a subdirectory with the extension .datacreated in the directory with the .vsdfile.For instance, for a model.vsddocument, its working directory is named model.data.At activation of the model.vsddocument, this directory is available to all components of the VTMine for Visio, including plugins.

Plugin manager.
One of the requirements imposed on the VTMine for Visio applicaton is the possibility of extending its feature set via dynamically loaded plugins.Because the VTMine for Visio is itself a plugin for Visio, this goal may be achieved via two main approaches: (1) additional modules are loaded as independent extensions Visio Add-On and (2) there exists a single Visio Add-On (VTMine for Visio) which on its own controls loading dynamic extensions.The first approach has several disadvantages related with the necessity of synchronization of separate modules with each other and absent possibility of controlling the order of loading the individual extensions, which creates a number of hardly resolvable issues.The second approach requires developing a subsystem for controlling extensions, but allows centralized controlling them, which avoids several issues and makes it preferable.It is this approach that is implemented in VTMine for Visio.As a result of using a single point of loading dynamic modules for VTMine for Visio, the system of plugins acquires the form given in Fig. 4.
A plugin is a specially formatted program component implementing one or several interfaces and having a unique string identifier.The main interface determining the intent of a component as a VTM plugin is the interface IVTMinePlugin.Each plugin is one of the possible extension objects attached to the type-compatible extension point.Plugins are contained in dynamic link library files (.NET assemblies).One such file can include several plugins, which allows simplifying the distribution of a group of plugins with a common theme.
Plugins may be dependent on each other as do the plugins presented in the UML diagram of components (Fig. 4).Most of the plugins presented in the diagram are dependent on the DPMine Base Plugin.It implements the subsystem DPMine [12,26] in the application VTMine for Visio.Exceptions are the DPMine Base Plugin itself and the Pn Common Plugin.This is determined by the fact that in this configuration most plugins extend the base plugin DPMine by adding new DPModel blocks or (as in the case with Execution Console Plugin) add additional components of user interface (console for executing DPM models) for controlling the DPM models.
One of the most important components of the core of VTMine for Visio is the plugin manager.It controls the loading and initialization of plugins for the VTMine for Visio application.
The plugin manager receives the control from the application core at activation of the latter, that is, at transition to the Active state.Firstly, the manager loads the configurational information stored in the special configuration file plugins.json.
The coupling between the plugins is not prescribed statically, but is determined dynamically at the stage of their loading.This is determined by the fact that several plugins at once can be extension objects for a single extension point.As a rule, only one of such plugins is loaded in a specific configuration, but its identifier is unknown before the instance of loading.This fact does not allow drawing a graph of dependencies between the plugins [27] before their loading and executing the subsequent topological sorting in it in order to determine the optimal order of plugin loading.The algorithm for plugin loading in the simplified form is presented below.
1.The list of all files with unloaded plugins, loading candidates, is generated.2. The plugin annotation is loaded for the next scheduled file from the list of candidates.The annotation includes the subprogram that analyzes the current environment from the point of view of sastifying the plugin dependencies.3. The possibility of loading the current plugin is tested by means of the subprogram of testing the satisfaction of dependencies in the plugin annotation.
4. If the dependencies of the current plugin are satisfied, then it is loaded and the flag of presence of loaded plugins is set.This means that some plugins that cannot be loaded at the previous iterations can be loaded now, because the loading of the current plugin satisfies their dependencies.
5. If there are more candidate plugins not loaded in the current loop iteration, we go to item 2. 6.If (i) all candidates are tested, (ii) there remain unloaded plugins, and (iii) at least one plugin has been loaded during the current cycle, then we go to item 1.
7. If (a) all plugins have been loaded or (b) no plugins have been loaded during the current loop iteration, which means the presence of unresolved dependencies, the algorithm is terminated.
In the worst case, when the sequence of plugins for loading by the algorithm is such that each current plugin depends on the next scheduled one, the complexity of this algorithm is quadratic in terms of the number of plugins.In addition to that, as a result of algorithm execution, the plugins in the current configuration are loaded in some predefined order.If we store this order and use it at the next loading of plugins (under the condition that no new plugins were added and no plugins were deleted), then the plugins will be loaded for a time linearly dependent on the number of plugins.Storage of the optimal order is conducted in the configuration file.
When some plugin is loaded, the plugin manager delegates the control to it by calling the Load-Plugin method with a binary parameter NeedReg.The implementation of the LoadPlugin method is individual for each plugin and allows it to interact with all components of the application, including the core component and other plugins.Interaction with the core components allows the plugin to customize the basic subsystems of the application in that it registers the new types of models (via the model types manager; see Subsection 2.1.4),adds the perspectives and control elements (via the user interface manager; see Subsection 2.1.3),registers the event handlers for documents (via the document manager; see Subsection 2.1.1),etc. Interaction with other plugins makes it possible to extend their functionality by the API provided by them.As an example, we can bring the subsystem of graphical modeling DPMine, which is built completely on plugins and can be extended with other plugins (Section 2.2).
The NeedReg flag is set at the very first loading of this plugin, which can be used for performing the primary operations at registering in the system: copying the necessary files with resources, initializing the configuration parameters, etc.At the subsequent loadings, the registered plugin only executes dynamic operations of extending the corresponding subsystems.
2.1.3.User interface manager.Interaction of the VTMine for Visio with the graphical user interface (GUI) of Visio is carried out via the user interface manager.It includes the abstraction level, which allows describing extension of the Visio GUI by the core components and the plugins of the application with the use of a certain list of components.The main components include perspectives, GUI modifiers, control elements, and control element factories.
The control elements that can be added by the core and plugins of the VTMine for Visio include the user-defined ribbons, control panels, and palletes of components (Fig. 3).Ribbons are used to add new menu/buttons/dropdown lists and other simple control elements through which a user interacts with the application components.In Fig. 3, we show the content of the VTMine ribbon, which is automatically displayed for all documents at initialization of the main add-in components of the application.We also show that in the menu there is another ribbon DPMine available, the selection of which appears only at activation of the model with the DPModel type.The control panels are larger elements of user interface that allow integrating complex dialog windows or scaled panels with lists, hierarchical structures, etc., into the user interface.In the figure, we depict the DPMine Explorer panel, which is activated only for the models of DPModel type as the DPMIne ribbon does.The palettes of components are special type of documents opened in the figure panel and contain the samples of figures prepared to use, the so-called templates or stencils.
Many user control elements depicted at a specific time instance are determined by the currently active perspective.When switching over pages of a document, we also switch over the perpectives prescribed for specific pages, so the set of visible elements varies.The perspective assigned to some page is determined, first of all, by the type of model displayed in this page.This allows depicting exactly the control elements relevant for the given specific model and hiding the others.For instance, the models DPModel are assigned to the perspective including the DPMine ribbon and the DPMine Explorer control panel.
The user interface manager registers one perspective by default; it is displayed for all pages of the document without any other perspective assigned.This perspective includes the VTMine ribbon, including the command for creating a VTMDoc document.Registering other perpectives is performed by plugins.
For this purpose, a special interface of the GUI modifier is specified (IUICustomizer) by implementing which plugin is included to the cycle of controlling the user interface.
Thus, a plugin performing the extension of the user interface registers a component in the user interface component, the GUI modifier, which implements the above-mentioned interface.The manager itself at its activation refers to all registered modifiers by quering the registration of new perspectives and then running the modification of all the registered perspectives.At the first activation of some perspective, the control elements included in it are created by calling the corresponding modifier and then are displayed in the application.
2.1.4.Model types manager.The main purpose of VTMine for Visio is in displaying and editing of graphical models.A Visio document is regarded as a collection of graphical models associated by a common research topic.One model may be placed in one or several pages of a document.In the last case, we mean multipage models, for instance, hierarchical ones.
VTMine for Visio has no fixed set of model varieties.On the contrary, the new types of models may be added to the system using plugins.Controlling model types is carried out by the component of the system core, the model types manager.
A variety (type) of model is described by the model descriptor.The model descriptor is an object implementing the IModelDescriptor interface.Such an object provides for the information about the identifier, name of the model type, component (plugin) registered the descriptor.One of the main purposes of model descriptor is in generating correctly prepared Visio pages.Query to the descriptor about the model creation can be put from the side of the core component (for instance, when a user chooses the corresponding command) or from the side of plugin (for instance, at synthesizing the new model as a result of execution of some algorithm).

DPMine Modeling Subsystem
One of the main extensions of the application VTMine for Visio implemented within this work is the subsystem of supporting the modeling of process mining experiments using the graphical language DPMine [12,26].In this subsection, we present the basic architectural approaches of this extension.We demonstrate the capabilities of VTMine for Visio in integration with the DPModel library [28] and with the LDOPA library of algorithms and data structures for process mining [29][30][31].
In Fig. 4, we present the component diagram of the main plugins referred to the DPMine subsystem.In this diagram, we see that all plugins implement the IVTMinePlugin interface, which they use to register themselves in the plugin manager and interact with the application.The plugins given in the figure have the purposes listed below (in parentheses after the plugin name we mentioned the programming language in which it was developed and the library whose functionality this plugin introduces into the DPMine subsystem).
• DPMine Base Plugin (C#) is the base plugin of the DPMine subsystem and determines its interaction with the application VTMine for Visio.
• Execution Console Plugin (C#) expands the feature set of the base plugin by providing the implementation of the model execution console.The base plugin provides only the extension point for introducing this console leaving the possibility of specific implementation to other plugins.
• SQLite Event Log Plugin (C++/CLI, LDOPA library) adds the definition of the new block of DPModel providing an abstract interface of event log, implemented as the SQLite event log [29], to the DPMine subsystem.
• TS Func Builder Plugin (C++/CLI, LDOPA library) adds the block of DPModel for synthesizing the transition systems in the event log [32] and the definition of the VTMine model type, the transition system with frequency labels.Exemplified by this plugin, we present below the peculiarities of extending the DPMine subsystem.
• TS Reducer Plugin (C++/CLI, LDOPA library) adds the blocks of DPModel for stepwise execution of reduction of the transition system according to the algorithm given in [32].
• TS Visualizer Plugin (C++/CLI) adds the block of DPModel for visualizing the models, transition systems with frequency labels.
• TS Metrics Plugin (C++/CLI, LDOPA library) adds the blocks of DPModel for computing the metrics of transition systems [32].
• Pn Common Plugin (C++/CLI) includes the general components for working with Petri nets and adds the definition of the type of the corresponding model of VTMine.
• Pn Reg Synth Plugin (C++/CLI, LDOPA library) adds the block of DPModel for synthesizing the Petri nets by the transition systems by a modified version of the algorithm of regions [33].
• Pn Visualizer Plugin (C++/CLI) adds the block of DPModel for visualizing the models, the Petri nets.
• Experiments Logger Plugin (C#) adds the block of DPModel for configurated accumulation and registration in the database of calculated values obtained at performing the experiment or executing the DPModel.
• Python Script Plugin (C++/CLI) adds the block of DPModel for executing an arbitrary Python script in the context of execution of the DPModel [31].
All the above-listed plugins depend on the base plugin, DPMine Base Plugin.Testing the satisfaction of this depedence is carried out by the LoadPlugin procedure upon loading the next scheduled plugin.If the base plugin has not been loaded before the instance of loading of the next scheduled plugin, then the loading of the latter is delayed.In addition to the dependency on the base plugin, some of the depicted plugins have another dependencies.For instance, the TS Reducer Plugin, TS Visualizer Plugin, and TS Metrics Plugin depend on the TS Func Builder Plugin, and the Pn Reg Synth Plugin and Pn Visualizer Plugin depend on the Pn Common Plugin (Fig. 4).The character of the plugin interdependency can be different.In some cases the dependent plugins extend the feature set of the parent plugin; the majority of the plugins in the example above extend the feature set of the base plugin.In other cases dependent plugins use some components of the parent plugin; for instance, Pn Common Plugin contains the basic definitions for the models based on Petri nets and the plugins depending on it use them.

DPMine base plugin and its extension.
The principle of extending one plugin by others is considered on the example of the DPMine Base Plugin.The structure of main components included in this plugin is depicted in the class diagram (Fig. 5).In addition to the components of the base plugin, in this diagram we present some related core components, other plugins, and libraries linked to this plugin.The diagram includes only a part of internal and external components that allow illustrating the mechanism of organization of component dependencies and their extension by each other.The components external with respect to the base plugin are enclosed in dashed rectangles and represent the boundaries listed below.
• Visio contains the main components of the application Visio, such as document and page.
• VTM4Visio Core are the core components on which the loaded plugins act.
• Execution Console Plugin is the plugin of the model execution console.In the diagram, we represent it only its main class ExecConsolePlugin.
• DPModel Library is the library of DPModel components [28], including the implementation of the modeling language DPMine and some basic blocks [26].The library is written in C# and is independent of the tool VTMine for Visio.The plugins of the subsystem DPModel of the tool use it as an external dependency.
• LDOPA Library is the library of algorithms and data structures for process mining [29,31].The library is written in the C++ language and is an external dependencies for the application.
• TS Func Builder Plugin is the plugin extending the feature set of the core by adding the new type of models transition system with frequencies (the FreqTsMD component); it also extends the feature set of the base plugin by registering the new type of DPModel block (TsFuncBuilderBlock), which executes the synthesis of transition system with frequencies of the prefix tree by the event log.The plugin performs integration of the component for synthesizing the LDOPA library into the system of modeling experiments DPMine.
The DPMine base plugin includes the following main components: • The DPMine model explorer represented by the DpmExplorer class; it implements the interface of the IUICustomizer core, adds the control element to the perspective of a DPModel, that is, the control panel with hierarchical explorer over the DPMine models registered in the current document (see Fig. 3, to the right).
• The model execution console represented by the IExecConsole interface implements extension of the user interface of the application by adding the control panel displaying the information about the execution of a DPModel.In contrast to the model explorer, the execution console is not a component included in the base plugin.On the contrary, other plugins may provide their specific implementation of the console and connect it to the base plugin.In this case, the ExecConsolePlugin plays a role of such plugin.
• The descriptor of the DPModel block, represented by the IBlockDescriptor interface, is used for registering the type of block in the DPMine subsystem that can be instantiated in a DPModel.The BlockDescriptor class implements the interface of IBlockDescriptor and is the basic feature set for descriptors of most blocks.Examples of blocks and corresponding descriptors registered directly by the base plugin would be DPMineBaseBlock/DPMineBaseBD and DPMineScheme/DPMineSchemeBD.They represent the base block and the scheme block of a DPModel, respectively [12,26].The TS Func Builder Plugin contains the components for synthesizing the transition systems by event logs.The synthesis algorithm is implemented as part of the LDOPA library and is presented in the diagram by the TsBuilder and PrefixStateFunc classes 2 .
In addition to that, the plugin extends the system of block types of DPModel by means of the blocks type descriptor TsFuncBuilderBD, which inherits from the BlockDescriptor class by analogy with the DPMineBaseBD and DPMineSchemeBD descriptors.One of the main tasks imposed on the descriptors of blocks of DPModel is the construction of blocks of nonvisual (object) model of DPModel by their graphical representation given by a figure of Visio (the Shape class).The block constructed so (for the plugin of transition systems synthesis, it is defined by the TsFuncBuilderBlock class) is further added to the model of DPModel and connected by connectors with other blocks, according to the way their visual representation are connected by connectors at the graphical model level.

EXAMPLES OF MODELS FOR PROCESS MINING EXPERIMENTS
In this section, we provide examples of models for process mining experiments reflecting the following operations: work with event log, synthesis of models of processes by event log and other models of processes, visualization of models of processes, calcualtion of model characteristics (metrics), and recording of an arbitrary information in the structured form (DB) for subsequent statistical processing.
The basic principles of organization of models of DPModel are considered in [12,26].The graphical model of DPModel is transferred to the object model and is then executed.The graphical model consists on one or several schemes; each scheme is represented in the form of one page of Visio.In Fig. 3, we present an example of scheme with the ReduceTS2 name placed on the eponymous page (the list of pages is displayed in the lower part of the screen form), which is a main scheme for the Reduce2 model (the list of models is displayed in the model explorer in the right side of the window).
The figure of Visio (an object of the Shape class) representing a block is labeled with the attribute User.DPMine_Type = "block".The attribute User.DPMine_Block_Type determines the specific value of the block type identifier registered in the system by means of the corresponding block type descriptor.
The graphical representation of the block may be any, but the conversion system expects the presence of embedded figures in the block which are attributed in a special way and represent the special elements of the block.In Fig. 6a, we present the block for calculating metrics of transition systems added to the system by the TS Metrics Plugin.The figure of the block includes several embedded figures denoting input and output ports (annotated by attributes User.DPMine_Type = "in" and "out", respectively), execution indicator (annotated by the attribute User.DPMine_Type = "execindicator"), and textual and graphical designations of the block.The block contains several parameters available for editing by user through the tool panel figure data (Fig. 6b).The parameters are prescribed via the switches TRUE/FALSE, which denotes execution or not of the calculation of each of the three metrics.These parameters are associated with the specific figure of the block by means of attributes Prop.calc_simplicity,Prop.calc_precision, and Prop.calc_general.
The list of blocks used in the developed models is given in Table 1.

Model for Synthesis of a Transition System Based on an Event Log
The simplest model of DPModel is the model for synthesis of a transition system based on an event log is given in Fig. 7.The model is represented by a single scheme which consists of three sequentially connected blocks: block of SQLite event log, block of parametric synthesis of transition systems, and block of visualization of the labeled transition system.
The block of event log contains the parameters: the file name of the log (File Name) and string with the configuration SQL expression (Get Config Query; [29]).The block of synthesis of transition systems contains the parameters: the size of window (Wnd Size) and the function used to output the state (State Function).The value as the window size means that it is not bounded, and Prefix as the function for returning the state prescribes the use of prefixes [32,34].This combination of parameters configures 2 It is used to output the state of the transition system by means of prefixes [32,34].

−
the block of synthesis of transition system to construct the prefix tree.Such a configuration is used, for instance, upon visualization of the event log.
When a model is executed, the block of an event log opens the DB of the log and prepares the queries according to the configuration extracted from the log by the configuration query [29].The block of syn-  Access to event log formatted as SQLite EventLog [29].

SQLite Event Log Plugin
Synthesis of transition system based on event log [32].

TS Func Builder Plugin
Construction of condensed transition system (step 2 of reduction algorithm; [32]).

TS Reducer Plugin
Recovery of condensed transition system to reduced one (step 3 of reduction algorithm; [32]).

TS Reducer Plugin
Visualizer of labeled transition system.

TS Visualizer Plugin
Calculation of metrics of transition system [32].

TS Metrics Plugin
Logging of experimental results in SQLite DB.

Experiments Logger Plugin
Synthesis of Petri net using transition system by means of method of regions [33].

Pn Reg Synth Plugin
Visualizer of Petri nets.++Visualize PN pn thesis of transition systems attached by means of connectors by its input port to the output port of the block of the event log synthesizes the transition system [32], which is inputted to the block of visualization of a transition system.This last block creates a new page-model of the application level of VTMine for Visio and draws the synthesized transition system using the annotated figures of Visio.

Pn Visualizer Plugin
The model page itself is annotated in order to add the additional reference information containing the time label of creating the model, the data source for it, the parameters of the synthesis algorithm, etc.An example of a prefix tree and annotation to it synthesized by means of such model is presented in Fig. 8.

Model for Synthesis and Reduction of a Transition System with the Calculation of Metrics
A more complicated version of the experiment model including the synthesis of a prefix tree based on the event log with subsequent reduction and calculation of metrics of the reduced system [32] is presented in Fig. 3.The model for synthesis with reduction is an extension of the model for synthesis (Fig. 7) and includes the following new blocks: block for constructing the condensed system, block for recovering the condensed transition system to the reduced one, the block for computing the metrics of transition system, and the block for logging the results of the BD SQLite experiment (see Table 1 for decrypting the graphical denotations of the blocks).
This model includes the complete cycle of the algorithm for reducing the transition system described in [32].Steps 1-3 of the algorithm are executed in separate blocks that allow varying individual parameters of the synthesis, condensation, and recovery, as well as constructing the graphical representations of intermediate models.For this purpose, the model includes three blocks for visualizing the transition systems attached by connectors to the corresponding output ports of the blocks for synthesis, condensation, and recovery 3 .
When a model is executed, the event log is prepared and the synthesis of the prefix tree is carried out.After that, the condensation block constructing the condensed tree on the basis of the prefix tree becomes active.Both these trees are necessary input parameters for the recovery block; therefore, its input ports are connected to the output ports of the block of synthesis of transition system and condensation block, respectively.The results of operation of the recovery block is the resulting reduced transition system, which is visualized together with two other intermediate trees. 3Different colors, shapes, and line thicknesses of connectors depicted in the model scheme have the same semantic meaning.After performing the complete cycle of synthesis of the reduced transition system, it becomes possible to compute its metrics, which is performed by the block for computing the metrics.It contains three input ports connected with the output ports of the block of the event log (for obtaining some statistical information about the original log), the block of synthesis of transition system (for determining the characteristics of the entire system/prefix tree), and the recovery block: the metrics are computed for the reduced transition system generated by exactly this block.
The last block executed in this model of experiment is the block of logging the results of the experiment.This block may have an arbitrary number of input ports, which must have distinctive names.The logging block is used for extracting control data from the blocks connected to it and storing them to the database accumulating the experimental results for their subsequent analysis.This block has three parameters adjusted by a user (Fig. 9).The DB File Name parameter prescribes the name of the DB file into which the results are written.The Log Query parameters determines the SQL expression adding a single record to the values of the experimental parameters to the DB (in one or several sheets).The Params Mapping parameter contains the configuration string that conducts the relation of the names of ports and objects transferred via them with the parameters of the SQL query.
For the considered model, the SQL query to add a record to the DB looks like INSERT INTO exp2(log_fn, log_acts_num, log_traces_num, …) VALUES (@log_fn, @log_acts_num, @log_traces_num, …).This query performs insertion of one record to the sheet exp2 of attribute values given by the names log_fn, log_acts_num, etc.The values are assigned with the query by means of the corresponding parameters: @log_fn and @log_acts_num.In their turn, these parameters are associated with the outer environment of the block of logging by means of the Params Mapping parameter taking the following value in this example: log_fn = log.name;log_acts_num = log.actsn;log_traces_num = log.tracesn;….
The Params Mapping is a string of pairs "parameter = value" separated by semicolon.The first element of the pair is the eponymous, starting from @, parameter of the above given SQL expression; the second element is the expression describing the relation of the SQL parameter with the input port.For instance, the record log_fn = log.namemeans that the value of the SQL parameter @log_fn is taken from the port named log.
The input ports of the logging block may be connected to the output ports of those blocks that provide for the multiplexed resource.The multiplexed or composite resource is provided by means of the object implementing more than one interface of the resource type.For instance, the block of synthesis of transition system forms the multiplexed resource at its output port, including the following objects: the transition system (via the C++ native type), the event log (via the C++ native abstract type), the function of state output (via the C++ native abstract type), the list of tags (via the C# virtual property), and the receiver of some property (via the C# virtual method).The output port at which the multiplexed resource is formed is also called multiplexed.
The C++ native objects available via the mentioned multiplexed port may be used by other blocks connected by connectors to this port if they can work with native objects (that is, such blocks must be implemented in the C++/CLI language).For instance, the condensation block connected to the output multiplexed port of the block of synthesis extracts the transition system synthesized by it in the form of native object.The list of tags is represented in the form of C# collection of string triples.In this special case, each such string describes some characteristic of some object, which is to be together with the list of tags at the output multiplexed port.In the example, such a list will characterize the synthesized transition system with the following attributes: the time label of model creation, event log on the basis of which this system has been sytnehsized, etc.It is easy to note that exactly this information is output by the block for visualizing the transition system in the form of propreties of the page on which this model is visualized (Fig. 8).
A receiver of the property is declared by the interface of the core level with the IGetProperty name and describes the single method with the C# signature Object GetProperty(Object key).This method receives an arbitrary parameter (for instance, string one) and returns the value related with it.It is this method that is used by the logging block for extracting the infrormation it needs.In the example considered above, in the expression log_fn = log.name, the SQL parameter @log_fn takes its value from the multiplexed port log at which the resource implementing the IGetProperty interface is implemented.The second part of the record log.name (namely, the name) prescribes a string parameter key transferred to the GetProperty() method.The obtained value is transformed to the type compatible with the SQLite DB and is assigned to the parameter log_fn, after which it falls into the DB in the form of the logged value of the experiment.
In this manner, the results of individual experiments are recorded: the characteristics of the event log, the parameters of the algorithm for synthesis and reduction, and the computed metrics of the resulting model.The DB fragment with the experimental results registered by the logging block is given in Table 2.

Model for Petri Nets Synthesis Based on an Event Log by the Method of Regions via Intermediate Transition System
In Fig. 10, we present a model of an experiment that synthesizes the target model, the Petri net by the algorithm of regions [33] via the intermediate transition system constructed based on the event logs.This model is an extension of the model in Fig. 7: in addition to the visualization block, we connect the block of synthesis of the Petri net to the output block of synthesis of the transition system.
The block for visualizing Petri nets works similarly to the block for visualizing transition systems by creating the new page-model and placing the graphical representation of the synthesized Petri net as a set of associated figures.An example of the Petri net synthesized with such model is presented in Fig. 11.TS fBuilder CONCLUSIONS In this work, we considered the principles of developing a graphical modeling tool for the subject area of process mining.We proposed an approach to extending the existing tool for business analytics MS Visio based on semantic attributes of the Visio components.The proposed approach was implemented as an application, MS Visio extension (add-on) and a set of accompanying plugins, which may be seen on the project site https://prj.xiart.ru/projects/vtmine4visio. The work of the tool was demonstrated on the set of experimental schemes for synthesis and analysis of process models.In the provided examples, we considered the capabilities of automatic construction of graphical models of processes and logging the information about the performed experiments in the form of DB for its further processing.
The tool we developed uses the high-performance LDOPA library of process mining algorithms, which allows extending its feature set by including novel blocks of algorithms implemented in this library.Among the direction of the future work, we note widening the range of supported algorithms and model types.

Fig. 1 .
Fig. 1.Graphical representation of a Petri net modeling the dining philosopher problem.
Figure data

Fig. 4 .
Fig. 4. Main VTMine for Visio plugins used in the paper.

•
The descriptor of the type of DPModel is represented by the DPMineMD class, which implements the IModelDescriptor interface.The descriptor of models of DPModel is registered in VTMine for Visio using the model types manager.• A model of DPModel is represented by the DPMineModel class.It is a nonvisual object model into which the graphical model of the experiments composed in Visio with blocks and connectors is transformed.The DPMineModel class extends the feature set of the ModelImpl class defined in the DPModel library and implements the IVTModel interface for models of the application level of VTMine for Visio.

Fig. 5 .
Fig. 5. Components of the DPMine Base Plugin and their interaction with libraries and other plugins (external dependencies are represented by dashed rectangles).
manager of DPModel is represented by the ModelManager class and is used for registration and execution of models of DPModel; it also harmonize the interaction of these models with the environment VTMine for Visio.The models of DPModel are grouped into Visio documents by means of the special component DPModel document profile, which is represented by the DocDpmProfile class.

Fig. 6 .
Fig. 6.(a) Graphic notation and (b) the parameter panel of the graphic block for calculation of transition system metrics.

Fig. 7 .Fig. 8 .
Fig. 7. Model of the synthesis of transition systems based on event logs and their visualization.

Figure
Figure data -Page Timestamp Producer Log info Wnd size

Figure
Figure data -Experim… DB file name Log query Params mapping

Fig. 10 .
Fig. 10.Model for Petri nets synthesis based on event logs by the algorithms of regions using an intermediate transition system.

Fig. 11 .
Fig. 11.A Petri net synthesized by the algorithm of regions using a reduced transition system.

Table 2 .
Database fragment with logged experiment results