Introduction

Process mining [1] aims to optimize business processes by using event data to discover and analyze process models. As processes become more digitized, they include not only structured production applications but also flexible knowledge-intensive fields [2], diversifying their event data. Therefore it is not enough to analyze only the imperative, procedural, perspective of your business process, one needs to also consider the declarative, rule-based, perspective. Declarative ICPM 2024 Tool Demonstration Track, October 14-18, 2024, Kongens Lyngby, Denmark Envelope slaats@di.ku.dk (T. Slaats); vco@di.ku.dk (V. P. Cosma); hulo@dtu.dk (H. A. López) GLOBE http://lopezacosta.net (H. A. López) Orcid 0000-0001-6244-6970 (T. Slaats); 0000-0001-8022-6402 (V. P. Cosma); 0000-0001-5162-7936 (H. A. López) process models can capture unstructured processes more concisely than imperative models and have been proven to capture better process insights for knowledge-intensive processes [2], achieving greater levels of optimization via process mining. Process mining tools1 aim to easily onboard practitioners and researchers, increase the dissemination of new ideas, and speed up the adoption of emerging techniques. Furthermore, as process mining positions itself as the bridge between data science and process science it also increases demand for tool interoperability concerning process modeling, verification, machine learning, and statistical analysis.

Dynamic Condition Response (DCR) Graphs [3] are a relatively new modeling notation that belongs to the declarative paradigm. From its core definition, DCR Graphs have evolved to include six relation types as well as hierarchy, through nestings [4], and to capture other process dimensions, such as time [5] and roles [3]. In addition, recent work on process discovery [6,4], conformance checking [7], and transformation to Petri Nets [8] has made the DCR notation practically interesting. However, tool support for DCR either covers broad functionality with closed source software [9] or provides open source code showcasing narrow functionality coded in a variety of programming languages and lacking continuous maintenance and support.

This paper proposes DCR4Py as the first broad functionality open source Python library developed as a seamless extension to the popular PM4Py (Process Mining for Python) project [10] using the same code structure and licenses. DCR4Py is an up-to-date implementation of DCR Graphs complete with process discovery, rule and alignment-based conformance checking, and a transformation to Petri Nets. Additional functionality includes execution semantics, visualization, and import/export capabilities via XML files compatible with both the DCR Solutions Portal [9] and the DCR-js modeling tool [11]. By extending a mature well-established library we enable users already familiar with PM4Py to get started with process mining with DCR graphs. As the library is open source it encourages the community to develop new extensions and algorithms for DCR Graphs. Being an extension of PM4Py, it allows for the reuse of the same installation requirements, automatic documentation generation, and testing.

Related work Tool support for declarative notations already exists in PM4Py for DECLARE [2,12] and Log-Skeletons [13]. In addition DECLARE benefits from dedicated software which exposes a wide range of features, such as RUM [12] and Declare4Py [14]. PromTools [15] offers a no-code alternative to PM4Py where plug-ins for DECLARE [16] and Log-Skeletons [13] exist. Unlike DECLARE, DCR Graphs have been adopted commercially through the DCR Portal [9]. However, while freely available for academic use, the portal is closed source. Some open-source implementations for process mining techniques in DCR Graphs exists [6,7,4,8], but each repository is narrow in scope, and not all are actively maintained. For example, the original DisCoveR repository written in Java lacks the newer extensions for nestings and roles. DCR-js [11] allows users to model DCR Graphs.

The remainder of the paper is structured as follows: Section 2 briefly defines DCR Graphs. In Section 3 we present the new features DCR4Py. Next in Section 4 we discuss the tool's maturity. We conclude in Section 5.

What is a DCR graph?

The DCR Graphs [3] modeling notation represents events as nodes and relations as edges in a directed graph. Events can be atomic, or part of a hierarchy (nestings or subprocesses), and can be associated with roles. Events have a notion of state through a three-tuple binary marking (included, executed, pending). Directed relations either constrain or affect events in the direction of the edge. The condition (→•) and milestone (→ ♦ ) relations between two events 𝐴 and 𝐵 limit the execution of 𝐵 based on the marking of 𝐴. The include (→+), exclude (→%), response (•→) and no-response (•→×) effect relations change the marking of 𝐵 after the execution of 𝐴. An event is enabled if it is included, all conditions have been executed and all milestones are not pending. The effect of executing an enabled event is that its marking becomes executed and all effect relations from that event apply their changes to the marking of the target event. Finally, we say that a DCR Graph is accepting when none of its events are both included and pending. The condition and response relations can also be timed with delays on conditions (

𝑘 →•)

and deadlines on responses ( 𝑑 •→). Figure 1 shows a prototypical DCR graph. Event logs are defined as a set of traces and a trace is a finite sequence of events. A trace is a run of a DCR Graph if only enabled events are executed, and at the end of the trace, the DCR Graph is accepting. If all log traces are accepting then the DCR Graph perfectly fits the log.

Overview of DCR4Py Features

A brief overview of the library can be seen in Figure 2. DCR4Py supports the main process mining tasks of conformance checking and process discovery for DCR Graphs. They include implementations of alignment [7], a new rule-checking algorithm, and the DisCoveR algorithm [6]. The DisCoveR algorithm is extended with the mining of nestings [4], roles, time [5], and initially pending events. The latter 3 are new contributions. The objects component exposes the existing conversion of DCR Graphs to Petri Nets [8] and new Python object definitions of DCR Graphs, execution semantics, and import/export capabilities. Finally visualizations for DCR Graphs are implemented through reuse of the existing PM4Py functionality.

DCR Graph class variants. The core DCR Graph class, based on the original definition from [3], consists of events, markings, and the include, exclude, condition, and response relations. Four main variants inherit from the core object. The Distributed variant covers the distributed definition [3], the Extended variant covers new relation extensions [17], the Hierarchical one covers nestings [4], and the Timed variant covers the time perspective [5]. Execution semantics are also extended for the Distributed, Extended, and Timed DCR Graphs classes. Hierarchical DCR Graphs map to Extended DCR Graphs, therefore do not have execution semantics.

Process Discovery. Process discovery for core DCR Graphs in DCR4Py consists of the Dis-CoveR algorithm [6]. The algorithm is called via the pm4py.discover_dcr method. Additional post-processing can be called using the post_process parameter. Roles, pending, and time enhance the richness of the discovered graphs, while nestings improve their simplicity. Roles are mined by associating events with the org:resource attribute of event logs. Pending events are mined to discover graphs with a non-accepting initial marking. Time is mined as delays and deadlines, according to the execution semantics of conditions and responses respectively.

Rule and Alignment-based Conformance checking. DCR4Py implements both rulebased and alignment-based conformance [7]. Rule-based conformance checking for DCR Graphs performs a replay of traces in a given event log. The algorithm utilizes the execution semantics to determine deviations. If any deviations occur, the algorithm notes the deviation and what caused it. The implementation utilizes a handleChecker, that determines the kind of DCR Graphs, to allow for correct notation of deviations, and currently supports core and distributed DCR Graphs. The algorithm is called via the pm4py.conformance_dcr method. DCR4Py also features the optimal alignment algorithm proposed in [7]. Alignment-based conformance checking directly connects deviations between the expected process flow, as per the DCR Graph, and the actual execution, as recorded in the logs. The TraceAlignment class aligns each trace in the log with the paths in the DCR graph. The computation of the alignment is performed by the Alignment class. The Performance class, calculates fitness as one minus the ratio of the optimal alignment cost to the worst-case alignment cost. The alignment algorithm is called via the pm4py.optimal_alignment_dcr method.

Conversion, visualization, import/export. The conversion to Petri Nets [8] is exposed via the pmpy.convert_to_petri_net function when passing a DCR Graph object. Visualizations of DCR Graphs, as shown in fig. 1, are provided via the pm4py.view_dcr and pm4py.save_vis_dcr functions. Finally, DCR4Py provides import/export capabilities for DCR Graphs to maintain interoperability with the existing DCR-js [11] and DCR Portal [9] modeling tools. Detailed instructions can be found in the notebook dcr_tutorial.

Maturity of the tool

Benchmarks. We compare the runtime of DCR4Py against the existing DECLARE, Log Skeletons, Petri Net, and DFG implementations in PM4Py. We selected logs in Knowledge Intensive Processes, including Sepsis [18], Road Traffic [19], BPIC13i [20] and the Dreyers Fond [21]. For process discovery, we see in fig. 3a that DCR4Py is the fastest overall, with DECLARE being the slowest on Road traffic. For conformance checking we take 10% of the log to discover a model and run the full log through the checker. For the rule checker, we see in fig. 3b that DCR4Py is, on average the slowest, and slowest overall on the Road traffic log. A similar pattern is seen in fig. 3c for the alignment checker. Installation, testability, and reuse. DCR4Py uses the same installation steps and requirements as PM4Py and unit tests and regression tests guarantee the testability of the new features and the integrity of the existing functionality. Automatic documentation generation is supported through the reuse of existing PM4Py functionality. As an academic tool, subsets of DCR4Py were successfully used to showcase new research, student projects, and in the classroom setting.

Conclusion

We introduced DCR4Py, an extension of the process mining library PM4Py supporting process discovery, conformance-checking, visualization, conversion and I/O capabilities for DCR Graphs. By extending PM4Py's API we lower the entry barrier for declarative process mining for researchers and practitioners. In future work, we will look at adding subprocesses, at multithreaded conformance checking to improve performance and object-centric mining of DCR Graphs.