A Library for Detecting Inconsistencies in Declarative Process Models

Abstract

We present a comprehensive library for detecting and classifying inconsistencies in declarative process models (DPMs) based on inconsistency structures (i.e., recurring patterns with shared characteristics that describe how combinations of constraints become inconsistent). Here, we not only focus on inconsistencies in the classiclogical sense but also on potential inconsistencies that only occur during run-time. Our approach allows for (1) detecting inconsistency cores based on the previously defined structures, (2) identifying design-time and run-time inconsistencies by extending these cores, and (3) classifying and measuring inconsistencies. We demonstrate the applicability of our implementation with real-life datasets.

1. Introduction

2. Preliminaries and Related Work

Definition 1 (Declarative Process Mod1e]l).[ A declarative process model (DPM) is a tuDpPlMe = (T, A, C), whereT is a finite, non-empty set of constraint templaAteis,a finite, non-empty set of activities, anCd is a finite set of constraints that instantiate the tempTl.ates in

CEUR

ceur-ws.org

Generally, we distinguish betweeexnistence (e.g., Init(a), AtLeastOne(a)) andrelation constraints (e.g., Response(a,b), NotChainPrecedence(a,b)). While existence constraints are automatically activated upon the start of a trace, relation constraints are either activated by their first parameter (forwar constraints; e.gA.,lternateResponse(a,b)), their second parameter (backward constraintPsr; eec.ge.-, dence(a,b)) or both parameters (coupling constraintsS;uec.cge.,ssion(a,b)). When a DPM contains contradictory constraints, it immediately becomes unsatisfiable, which is referred to as inconsistent. Definition 2 (Inconsistency7[]). An inconsistency is a tup l=e (, ) , where ⊆ A is the set of activities that minimally activate a set of cons⊆traCinstusch that∪ ⋃∈ AtLeastOne() ⊧ ⊥ . is aminimal inconsistency if there is n o ′ ⊂ or ′ ⊂ such tha(t ′, ′) is an inconsistency. To diferentiate between design-time and run-time inconsistencies, we consider a minimal inconsistency = (, ) a classic inconsistency if ⊧ ⊥ and = ∅ and apotential inconsistency if ⊧ ⊤ . Furthermore, i|f| = 1 we say that a potential inconsistency aisctauanl issue and if|| > 1 it is considered apotential issue [4, 7]. As multiple inconsistencies can share a common underlying problem, we extend the definition by4,[7] and define an inconsistency core. Table1 contains a variety of exemplary cores representing diferent inconsistency types. For instance, the example for POS1 is a classic inconsistency, the one for POS2 an actual issue, and the one for CARD2 a potential issue. Definition 3 (Inconsistency Core7][). An inconsistency core is a tupl e = ( , ) , where ⊆ A is a non-empty set of activities that minimally actaivnadttehus serve as core activations, ⊆andC is a set of constraints. Addition allmy,ust be a minimal classic or potential inconsistency, such that no proper subset( ′, ′) with ′ ⊆ A or ′ ⊂ forms a minimal classic or potential inconsistency. Related works on inconsistency detection focus mainly on LTL8,,e9.g,.1,0[]. For DPMs, most approaches determine unsatisfiability of an entire model by translating constraints into deterministic ifnite automata (DFAs) and constructing a product automaton to assess satis1fia1b].iliWtyhi[le detecting individual, minimal inconsistencies in DPMs using DFAs is theoretically sound, it sufers from severe scalability issues due to the exponential growth in the number of automata product computations required. Moreover, DFA-based techniques are inherently limited to classic inconsistencies and cannot detect potential inconsistencies that depend on specific activity occurrences. As a result, C2o]rea et al. [ have implemented a first approach to detect actual issues in DPMs but only consider limited scenarios (e.g., certain path-based inconsistencies). More recently, Corea and T3]hpimrompo[sed an approach for identifying potential issues, but only based on a small subset of templates. 3. Detection Approach ( 1 ) Preparation. Our library was implemented in Java and accDeepctlsare models in various formats (TXT, JSON, and CSV), which enables seamless integration with the outputs of existing process mining algorithms. To ensure broad applicability, we support a wide raDnegcelaorfe templates and also handle naming variations (eA.gt.,Least1 andParticipation are treated aAstLeastOne) to enable compatibility with diferent tools and datasets. As an optional preprocessing step, we check for redundant constraints based on a subsumption hier1a]r.cRheyd[undant constraints are temporarily removed from the model but are retained for later use, e.g., to assign responsibility (culpability) to constraints or to help guide the selection of appropriate weakening strategies during inconsistency resolution. Although more advanced forms of redundancy exist (e.g., those derived from combinations of constraints), we intentionally delay such checks until after inconsistency resolution, as this might distort inconsistency measurement and significantly change the model. Furthermore, detecting and removing redundant constraints becomes much more feasible after consistency has been restored, as DFAs can be utilized again (which always have an empty language while inconsistencies are present). To improve computational eficiency, we pre-compute and store filtered subsets of constraints to be reused throughout the detection processes. Many inconsistency core detection algorithms rely on graph-based reasoning, which is why we construct multiple graphs using JG1raanpdhTutilize both built-in and custom graph search algorithms. Custom implementations were necessary to incorporate advanced validity checks during the search process, which allowed us to improve eficiency by discarding invalid subtrees early.

( 2 ) Core Detection. We implemented a set of specialized algorithms that are designed to detect cores corresponding to a specific inconsistency structure. These structures are grouped into four categories: position, cardinality, relation, and boundary inconsistencies. An overview of the implemented structures, along with an exemplary core for each, is provided i1n. TEabclhealgorithm is designed to comprehensively capture cores related to its respective structure. Due to space limitations, we refer to our Git repository for additional examples and extended explanations. Depending on the characteristics of a structure, we apply diferent algorithmic strategies. For some structures (e.g., POS1, CARD1) the core can be derived directly from a specific combination of constraints. In contrast, other structures (e.g., ORD1, BOUND2) require graph-based search to identify valid cores.

( 3 ) Inconsistency Detection. Once cores have been identified, we proceed to detect complete inconsistencies by analyzing how these cores can be activated within the model. The detection process is configurable, so users can apply filters to focus on specific types of inconsistencies (e.g., only classic or only potential ones) or restrict the detection to certain structures. First, we detect all valid activat paths for all core activations by identifying activating existence constraints in the model (i.e., existence constraints that imply a minimum cardinality of one) and searching for valid paths in a previously defined activation graph. An activation path is considered valid if it does not result in an additional inconsistency when attached to the core, making the resulting constraint setminnoimlaolnlyger inconsistent. For cores with more than one activation, we additionally must ensure compatibility of all path combinations before generating a respective inconsistency, as incompatible paths (e.g., paths that have an additional activity overlap) also make the resulting inconsistency no longer minimal. Each of these inconsistencies includes the core, its activation paths, and the (optional) existence activations required to trigger the inconsistency. This comprehensive detection process enables us to uncover both design-time (classic) and run-time (potential) inconsistencies across the entire model.

( 4 ) Inconsistency Measurement. Our library also allows basic inconsistency and culpability measurement. This includes measuring the degree of inconsistency of the entire model by, for example, counting the number of cores and/or inconsistencies (optionally categorized by type or structure), as well as measuring culpability of individual constraints, i.e., the number of cores and/or inconsistencies in which the constraint is involved.

4. Usage and Maturity

To enable easy access to our inconsistency detection library, a basic version can be used directly in the browse2r(cf. Figure1). Additionally, the code can be obtained by cloning our Git re3pository and executed locally. The latter also allows a direct integration into existing modeling or mining tools. Additionally, a screencast showcasing our application can be fo4u.nTdo hdeermeonstrate the feasibility of our approach, we evaluated our librarDyeucslianrge models mined from real-life dataset5s. For the considered datasets, we computed all cores and the corresponding inconsistencies. We ran our experiments on MacOS with an M2 chip and 16GB RAM. In T2awbleeprovide an overview of the number of detected cores and inconsistencies, along with the run-times for the core and the inconsistency detection separately. 2https://uni-ko.de/detection 3https://uni-ko.de/detection-git 4https://uni-ko.de/detection-screencast 5https://data.4tu.nl/search?searcha=nbdpihttps://data.4tu.nl/datasets/33632f3c-5c48-40cf-8d8f-2db57f5a6ce7/1

5. Conclusion

In this work, we present a comprehensive library for detecting and classifying inconsisDtecnlcaiersein models. Our approach identifies both classic (design-time) and potential (run-time) inconsistencies by detecting minimal inconsistency cores and exploring their activation paths. The current implementation is based on a predefined set oDfeclare templates. While this ensures compatibility and simplifies implementation, it restricts the analysis to models built using these templates. However, additional templates can simply be added by specifying their activation semantics and linking them to relevant inconsistency structures. As a next step, we aim to develop a dashboard that ofers visualizations of inconsistencies and improved support for model exploration and diagnosis. Moreover, our detection algorithms will be integrated directly into declarative process modeling and rule mining tools. This will allow inconsistencies to be identified and resolved during model design or as part of the mining process, which, in turn, would improve model correctness and reduce the likelihood of run-time issues.

Acknowledgments

This paper was funded by the Deutsche Forschungsgemeinschaft (grant number DE 1983/9-3).

Declaration on Generative AI

During the preparation of this work, the authors used GPT-4o to check grammar and spelling.

References

[1] C. Di Ciccio , M. Montali , Declarative Process Specifications: Reasoning , Discovery, Monitoring, in: Process Mining Handbook, volume 448 , Springer Int. Publishing, 2022 , pp. 108 - 152 .

[2] C. Corea , M. Deisen , P. Delfmann , Resolving Inconsistencies in Declarative Process Models based on Culpability Measurement, in: In Proceedings der 14. Internationalen Tagung der Wirtschaftsinformatik , Siegen, Germany, 2019 .

[3] C. Corea , M. Thimm , Towards Handling Potential Issues in Business Rule Bases , Journal of Applied Logics 11 ( 2024 ) 565 - 592 .

[4] S. Nagel , P. Delfmann , Identification, Abstraction and Classification of Inconsistency Structures in Declarative Process Models , in: ECIS 2023 Research Papers, 2023 .

[5] S. Nagel , P. Delfmann , Exploring Cognitive Efects of Inconsistency Characteristics on Understanding Inconsistencies in Declarative Process Models , in: Proceedings of the 57th Hawaii International Conference on System Sciences (HICSS) , 2024 .

[6] S. Nagel , P. Delfmann , Investigating Inconsistency Understanding to Support Interactive Inconsistency Resolution in Declarative Process Models, in: ECIS 2022 Research-in- Progress Papers , 2022 .

[7] S. Nagel , P. Delfmann , Interactive Resolution of Inconsistencies in Declarative Process Models , in: Proceedings der 19. Internationalen Tagung der Wirtschaftsinformatik (WI 2024 ), 2024 .

[8] A. Ielo , G. Mazzotta, R. Peñaloza , F. Ricca , Enumerating Minimal Unsatisfiable Cores of LTLf formulas , arXiv preprint arXiv:2409.09485 , 2024 .

[9] M. Roveri , C. Di Ciccio , C. Di Francescomarino , C. Ghidini , Computing Unsatisfiable Cores for LTLf Specifications , Journal of Artificial Intelligence Research 80 ( 2024 ) 517 - 558 .

[10] V. Schuppan , Extracting unsatisfiable cores for ltl via temporal resolution , Acta Informatica 53 ( 2016 ) 247 - 299 .

[11] C. Di Ciccio , F. M. Maggi , M. Montali , J. Mendling , Resolving Inconsistencies and Redundancies in Declarative Process Models, Information Systems 64 ( 2017 ) 425 - 446 .