Keywords

1 Introduction

Infusing flexibility in process-aware information systems is widely recognised as a key challenge in business process management (BPM) and information systems engineering [17]. Within the flexibility spectrum, flexibility by design advocates that process modelling languages themselves need to offer modelling primitives that provide freedom to process executors when deciding how to execute the process. The question then becomes how such languages help in finding a suitable trade-off between flexibility and control. Declarative approaches tackle this problem in an extreme way: the model indicates what the relevant temporal/dynamic constraints that have to be respected during process execution enforce, leaving the executors free to decide how to unfold the concrete executions.

After seminal papers on the topic were published between 1998 and 2003 within BPM and neighboring fields [5, 18, 19], the community started investigating declarative process modelling more systematically starting from 2006, when Pesic and van der Aalst proposed to apply temporal logic patterns [8] to declaratively capture process constraints [20], eventually leading to the Declare language and system [16] and to the definition of a variety of reasoning tasks thanks to different logic-based formalisations [14, 15]. This interest was further fueled by the introduction of other declarative approaches, most prominently Dynamic Condition-Response Graphs [11].

A well-known issue with declarative approaches is that while they enjoy flexibility, they typically do not explicitly indicate how the execution has to be controlled. In other words, conforming executions are only implicitly described as those that satisfy all the given constraints. Constraints, in turn, may be quite diverse from each other (e.g., indicating what is expected to occur, but also what should not happen). At the same time, constraints implicitly and mutually affect each other (a phenomenon referred to as hidden dependencies in the cognitive dimension framework used to evaluate the characteristics of notations [6, 9, 15]). This notoriously challenges understandability and interpretability of declarative process models [10], and calls for toolkits providing continuous support to the end users [9]. One such toolkit is RuM [2], which addresses some of the above-mentioned issues by providing a unified user interface for declarative process mining algorithms.

2 Declarative Process Mining with RuM

RuM [2] is the first software platform natively designed for declarative process modelling and process mining. RuM is based on the well-known modelling language Declare [16] and its multi-perspective extension MP-Declare [3], that is, Declare extended with data and time perspectives.

The following sections give a brief overview of RuM. Further information and the download link can be found in [2] and at https://rulemining.org/. To illustrate RuM’s functionality, we use the Sepsis treatment process and event log described in [13].

Automated Process Discovery. RuM includes multiple algorithms for automatically discovering a process model. As usual for Declare, the discovered models consist of a set of constraints where each constraint describes one specific aspect of the process (i.e., constrains the behaviour of the process in a specific way).

In general, a constraint describes either the cardinality of an activity (i.e., the number of occurrence thereof in a trace) or a relation between two activities (i.e., how the occurrence of an activity requires or disables the occurrence of another one). For example, \(\textsc {Exactly1}(\textit{ER Triage})\) means that activity ER Triage will occur exactly once in each trace. \(\textsc {ChainResponse}(\textit{ER Registration},\textit{ER Triage})\) means that when activity ER Registration occurs then ER Triage will occur immediately after.

The discovered model is by default visualised using the standard Declare notation (Fig. 1). Alternatively, it is possible to represent the model procedurally as an equivalent deterministic finite state automaton (Fig. 2). Finally, it is possible to represent the entire model as a set of natural language sentences, e.g., “When ER Registration occurs, then ER Triage occurs immediately afterwards”.

Fig. 1.
figure 1

An example of a Declare model represented as a map.

Full size image
Fig. 2.
figure 2

An automaton representation of the Declare model in Fig. 1.

Full size image
Fig. 3.
figure 3

Conformance checking approaches

Full size image

Conformance Checking and Monitoring. RuM provides two conformance checking approaches. The first one detects constraint fulfilments and violations (Fig. 3a), which pinpoint both the events that occur as specified in the model and those events that contradict it. The second approach is based on log alignments (Fig. 3b), as it identifies the event insertions and/or deletions that would make the event log conforming with the Declare model.

The conformance checking results are provided at different levels, i.e., per event log, per trace, and per constraint. The latter is especially useful since it allows for clear insights and overall explainability of the conformance checking results with respect to specific process constraints. Additionally, RuM provides a monitoring functionality, which allows the user to interactively replay the traces one event at a time. During replay, RuM visualises the state of each constraint in the model (possibly/permanently satisfied and possibly/permanently violated) as the events of the trace are occurring.

Model Editing. RuM provides model editing capabilities through a fully MP-Declare compliant model editor, which supports the different representations discussed for process discovery above (cf., Figs. 1 and 2). These representations are updated and the inputs are validated on the fly as the model is being edited. In addition to editing the constraints directly, it is also possible to specify constraints and data conditions by using natural language speech and written text. This functionality is implemented as a simple chatbot named Declo [1].

Log Generation. Finally, RuM can generate event logs based on a given Declare model [7]. Although, by default, a generated log satisfies all constraints in the model, RuM also allows for the insertion of vacuous traces, i.e., traces that do not activate some constraints, and negative ones, i.e., traces that violate constraints.

3 Considerations About Declarative Process Mining

The constraint-based nature of the declarative approach has various interesting implications and advantages with respect to the traditional, imperative paradigm. For instance, since declarative constraints establish behavioural rules that delimit the possible execution space for processes, they act like norms with which all process runs have to comply with. This characteristic make declarative models open, in that any execution is permitted as long as the expressed rules are not violated, as opposed to the closed scope of imperative models (e.g., Workflow nets, BPMN diagrams, event-process chains), which depict the whole execution space, from start to end [12].

From a mining perspective, declarative process mining aims to establish, measure and validate the rules that best define the behaviour emerging from the traces recorded in event logs – in the closest etymological sense of “defining”, i.e., marking out their boundary. Therefore, exceptional, ad-hoc, or optional variants of process behaviour are fully supported as long as no constraints are expressed that contradict them. By contrast, an imperative model requires an alteration of its structure any time its unfolding does not encompass an alternative path that is evidenced in an event log. Declarative models can be used to represent the distinguishing core rules of event logs exposing high variability as per their stored runs, thereby catering for flexibility.

Fig. 4.
figure 4

A Declare negative constraint.

Full size image

Declarative process rules are exerted over whole runs. Such a global state perspective differs from the imperative approach in which, given a current state, only the next enabled actions are made explicit (local state perspective). This reflects the difference between functional (declarative) and procedural (imperative) approaches to programming. A declarative rule applies any time a situation that triggers it is reached, regardless of the history of actions that led there. Also, the effect can span the whole execution of the process, i.e., at any moment in the future or the past: for instance, \(\textsc {Precedence} (\textit{ER Sepsis Triage}, \textit{IV Antibiotics})\) requires that ER Sepsis Triage must occur at any point in time before the inoculation of antibiotics. In contrast, imperative models dictate what the possible operations are for the next step given a case’s history.

Declarative process models enjoy compositionality based on the conjunction of their constraints: the intersection of permitted behaviour from each rule determines the overall specification [4]. Adding rules restricts the range of acceptable runs. In contrast, the addition of new states and transitions to an imperative model enlarges the execution space. We remark two consequences of this difference. Firstly, more flexible processes may create more cluttered imperative models (the so-called spaghetti models) as declarative specifications would represent the core behavioural rules they are subject to rather than all the possible runs that would comply with them [16]. Secondly, declarative models are better suited for the seamless support of negative rules, i.e., constraints that impose the disablement of task occurrences given a specified condition. For example, \(\textsc {NotSuccession} (\textit{Admission IC}, \textit{IV Antibiotics})\) imposes that after patients are admitted in the intensive care unit, they cannot undergo an inoculation of antibiotics. Adding this constraint to the model depicted in Fig. 1 is straightforward as declarative process models consist of lists of statements dictating the process rules. Graphically, it requires the sole juxtaposition of the constraint illustrated in Fig. 4 to the existing map. Including this constraint in the automaton representation in Fig. 2 requires the addition of numerous states and transitions as illustrated in Fig. 5 though.

To conclude, we remark that as the declarative process specifications dictate the rules that process executions are required to abide by, they can act as a bounding box within which imperative process models need to be defined to represent specific strategies implemented to achieve the goals of the operating organisation, depending on the expertise, resources and context of the latter.

Fig. 5.
figure 5

The automaton representation of the model in Fig. 1 including the constraint in Fig. 4.

Full size image

4 Research Opportunities

Beyond the current state of the art, we foresee several research opportunities in the context of declarative process modelling and mining. From a modelling perspective, a clear opportunity relates to the graphical notation. The original version of the Declare language is known to be difficult to understand [10]. Although some effort has been done in this direction already, an extensive user evaluation to compare the different ways to represent constraints is still missing. Also, an interesting challenge is the analysis of declarative process models mixing crisp and probabilistic constraints, as discovered models often retain constraints that are violated by a set of traces in an event log. Another aspect currently under investigation pertains to the so-called hybrid process models, which consist of both imperative and declarative parts. This is important since real processes often contain both structured and unstructured parts. Finally, a highly promising research direction is the development of declarative modelling and mining instruments to deal with object-centric processes. This problem is also closely related to the assessment of the relevance of a constraint in a given process execution, which can depend on the nature of the actions and of the objects involved in the constraint.