This paper presents BPMN2Constraints, a tool that compiles BPMN diagrams into sets of declarative constraints that can then, for example, be used for conformance checking. Notably, BPMN2Constraints does not rely on Petri net replay for generating the constraints; by generating constraints directly from a control flow graph extracted from the BPMN model, the tool avoids indirection. BPMN2Constraints can generate constraints in several languages: DECLARE, finite-trace linear temporal logic, and SIGNAL, a proprietary process querying language.
Instead, it is preferable to extract declarative constraints from the models. These constraints
can then be filtered to exclude the ones that do not carry any relevant business meaning. Also,
constraints of several models can be aggregated, e.g., to identify the most prevalent constraints
across several business process landscapes or collections of best practice models. An additional
advantage of compiling declarative constraint sets without an additional Petri net replay step,
but directly from imperative process models, is that at least some industry-scale process querying
languages use regular expression-based matching as the central abstraction for reasoning about
control flow, which is closer to declarative temporal reasoning. Considering the prevalence
of declarative approaches in large-scale industry applications outside of the process domain,
e.g., in distributed systems [
To achieve our goal of moving from business-level imperative process models directly to
declarative conformance checking constraints, this demonstration paper presents BPMN2Constraints,
a software library that compiles the control flow of BPMN models to constraints in several
declarative languages: finite-trace linear temporal logic ( ), DECLARE [
Given the BPMN model, we can observe the following constraints, for example: i) precedes (DECLARE: (, )); ii) Assuming transitivity, precedes as well ((, )); iii) Either and occur, but not both (ℎ(, ));
Starts with Ends with
DECLARE () () leads to
(, ) OR ℎ(, )
(b | c ) AND
(, ) XOR
ℎ(, ) Loop (, )
SIGNAL ^a a$ (^NOT(a|b)*(a~>b) *NOT(a|b)*$) (^NOT('b'|'c') (('b'ANY'c'ANY*)| ('c'ANY*'b'ANY*)) NOT('b'|'c')$) (^(((NOT('c')*) ('b'NOT('c')*)*) | ((NOT('b')*) ('c'NOT('b')*)*))$) (^NOT('b'|'c')* ('b'NOT('b'|'c')* 'c'NOT('b'|'c')*)* NOT('b'|'c')* $) iv) and occur together, but are not constrained regarding their temporal order ((, )).
To generate the constraints, we parse the BPMN diagram, extract activity relations based on the control flow and instantiate the constraints based on templates that follow DECLARE semantics. Note that we exclude negative constraint templates as well as existence templates to improve readability of the output. Implicitly, there is an (, 1)) constraint for each ∈/ , where is the set of the task labels that occur in the model at hand, which means that we exclude any tasks that are not part of the model1. We treat events and tasks/collapsed sub-processes equally as propositional variables and handle sequence flows, OR, XOR, AND, and event-based gateways for operator generation (interpreting event-based gateways as XORs). All other element types are ignored. 1The full list of DECLARE templates we use as a basis can be found in our repository. 3. Evaluation on Large Process Model Collections In order to assess the robustness of BPMN2Constraints and demonstrate its maturity, we compiled thousands of BPMN models from two large process model collections into DECLARE and SIGNAL constraints and analyzed the results with respect to the following properties. Ability to parse and compile. We check whether the parsing/compilation procedure fails and whether all control flow-relevant elements (events, activities, sequence flows) can be parsed and appear in the output.
Output similarity relative to a Petri net replay-based approach. We compare the DECLARE constraints BPMN2Constraints generates with the output of a Petri net replaybased constraints, measuring: i) precision: how many of the constraints generated by BPMN2Constraints are also generated by the Petri net replay-based tool? ii) recall: how many of the constraints generated by a Petri net replay-based tool are also generated by BPMN2Constraints? Here, it is crucial to note that the constraints generated by the Petri net replay-based tool are not a proper ground truth. In particular, the imperfect definition of BPMN execution semantics does not allow for an unambiguous transformation into Petri nets; the complexity of the standard causes challenges even for mundane tasks such as model interoperability, which is continuously improved by a dedicated working group2. Still, the results can shed light on the extent to which the two approaches are aligned, thus indicating potential directions for future work.
For our evaluation, we used the following two process model collections.
A collection of research and educational BPMN models (SAP-SAM). The SAP Signavio
Academic Models (SAP-SAM) [
From both collections, we excluded models with any of the following properties (heuristics to select diagrams that are either of too low quality or out-of-scope for BPMN2Constraints): i) the model contains five elements or less; ii) the model does not have any task, any start event, or 2See: https://www.omgwiki.org/bpmn-miwg/doku.php, accessed at 10-06-2023. 3This number excludes vendor-provided example processes, duplications of which we excluded. 4See: https://www.signavio.com/products/process-explorer/, accessed at 02-05-2023. any end event; iii) the model fails a syntax check (executed by a commercial process modeling tool); iv) the model has more than one BPMN pool, i.e. it models a cross-organizational process. After filtering, 3,960 SAP-SAM models and 2,196 VBPMN models remained.
Our constraint generator managed to parse and compile 94.13% of the SAP-SAM models and 99.9% of the VBPMN models. The total amount of constraints generated by the SAP-SAM models where 149, 098 for the Petri net replay-based approach, and 142, 982 constraints were generated by BPMN2Constraints. The VBPMN models generated 81, 043 constraints from the Petri net replay-based approach and 81, 956 by our tool. The compiler achieves 64.46% precision and 66.7% recall for the SAP-SAM models and 93.32% precision and 93.57% recall for the VBPMN models. While the results indicate that there is still room for improvement and deeper evaluation, let us highlight that this preliminary study is, to our knowledge unique in its large scope. Also, we expect that many issues can be traced back to the ambiguity of the BPMN standard and the quality of the models in the SAP-SAM dataset, which presumably contains – despite the filtering – a substantial amount of incomplete or intuitively “wrong” models.
We have presented BPMN2Constraints, a tool for extracting control flow from BPMN-based
process models as declarative constraints. We hope that the work can make the relation between
imperative and declarative constraints more tangible. In the future, the tool can be extended,
e.g., to consider constraints beyond process control flow such as roles and responsibilities or to
support the output of additional process query languages such as the Process Query Language
(PQL) [