1 Introduction

The Business Process Model and Notation (BPMN 2.0) [15] is a widely accepted language for modelling business processes, which has been standardised by the Object Management Group in 2011. A BPMN model, like any other process model, should be easy to understand [4] and correct [5] to maximise its usefulness and uptake. Specifically, a process model is correct if it does not exhibit structural issues, such as disconnected nodes, or behavioural ones, such as soundness, safeness and other, possibly domain dependent, behavioural anomalies. In particular, recognising correctness problems as soon as possible helps to avoid negatively impacting effects before the process model is deployed. This is particularly important if the model is intended to be executed on top of a Business Process Management system, where undetected problems may lead to expensive manual interventions to rectify business operations (e.g. aborting an inconsistent order, recovering a double payment, or restoring a loan application that got stuck). Several properties have been defined to guarantee process correctness such as the ones reported in [9, 18, 19].

A prominent correctness property is that of soundness. Informally, a model is sound if and only if it satisfies the following three rules: (i) Option to complete: requiring that a process instance should always complete, once started; (ii) Proper completion: requiring that when a process ends there should not be any other activity still running; (iii) No dead activities: requiring that a process does not contain activities that will never be executed.

Safeness is another relevant property that can be verified over business process models. If safeness is verified, this guarantees that no activity in a process model will ever be executed in more than one instance concurrently. Indeed a multiple concurrent execution of the same activity is perceived as a bad behaviour that could lead to unwanted effects such as e.g. multiple payments or multiple deliveries of the same product.

Additionally, more specific properties can be defined in order to ensure the conformance of the model to specific behavioural patterns. For example, this may be useful to check the correct exchange of messages as well a proper evolution of process activities (we will refer to them in this paper as domain dependent properties).

Armed with the objective of building high-quality BPMN models through an easy to use modelling and analysis environment, we have developed a novel tool for Business Process Verification (BProVe) [5, 6] packaged as a RESTful web service. In this paper, we present the integration of BProVe into ApromoreFootnote 1 [11], an open-source process analytics platform developed by the BPM community. Apromore was originally conceived as a process model repository, but over time it evolved into a BPM platform that offers various types of analytics, along the various phases of the BPM lifecycle (discovery, analysis, redesign, implementation and monitoring). The platform is based on a service-oriented architecture, and deployed as a Software as a Service. Apromore has been conceived has an easy extensible framework, where new plugins can be added to an ecosystem of advanced business process analytics capabilities. BProVe’s ability to perform a comprehensive correctness check of BPMN models, together with the possibility of highlighting the elements that led to the violation of a given correctness property, make BProVe a valuable addition to the Apromore platform. In particular, this integration enables Apromore users to increase their trust on the quality of the models stored in the platform’s repository.

Existing tools for process model verification mostly focus on Petri nets/Workflow nets (e.g. WoPeD) or offer support for the core set of BPMN elements only (i.e. excluding elements with non-local semantics such as OR-joins). The latter is achieved via an internal transformation into Petri nets (e.g. ProM 5.2) or other formalisms, though these transformations are only partial in nature, often limited by the target language such as Petri net. In addition, these tools are typically available offline. An exception is Signavio Academic Initiative, which provides basic correctness checking for single-pool BPMN models. In contrast, our tool potentially supports the full BPMN language as it relies on a direct semantics rather than on an internal transformation, and is available online, as a Software as a Service.

The rest of this paper is organised as follows. Section 2 provides an overview of BProVe with details on the BProVe architecture, its features, and discusses the results of a large experiment against several thousand models. Section 3 describes the integration of BProVe into Apromore, with a focus on the user interface. Finally, Sect. 4 provides links to a screencast and to the tools’ Web pages.

2 BProVe - Business Process Verifier

BProVe - Overview. BProVe allows to automatically verify relevant properties for business process models. Differently from similar tools, BProVe is based on a native BPMN semantics [8] defined according to a Structural Operational Semantics style [16], which makes it suitable for a MAUDE implementation [2]. MAUDE is a programming language that models systems, and the actions within those systems. It can be used to define executable formal models of distributed systems, and it provides analysis tool to formally analyse the models. In MAUDE, a distributed system is formalised as a rewriting logic theory [3, 12]. Implementing the BPMN Operational Semantics in MAUDE has the great benefit of ensuring the faithfulness of the implemented semantics with respect to its theoretical definition, as operational rules are directly implemented as MAUDE rewriting rules. In addition, due to its direct BPMN Operational Semantics, BProVe re-conducts verification results to the original model, so that diagnostic information can be easily reported on the model in a way that is understandable by process stakeholders. This is especially useful when many parties with different background need to quickly interact based on models.

BProVe - Architecture. The architecture of the BProVe toolchain is illustrated in the component diagram of Fig. 1 which consists in a quite standard organisation of components for providing a verification as a service. From the left side of the figure to the right, we can see three main components: Modelling Environment, BProVe WebService, and BProVe Framework. The Modelling Environment component represents the tool used to design BPMN models and to specify which properties of the model the user wants to verify. It is here that the integration with Apromore takes place. Apromore’s BPMN editor is used for the design of BPMN models. By means of a BProVe plug-in for Apromore, a user can pass from the design phase to the verification phase still remaining inside the modelling environment. The BProVe plug-in constitutes what in the diagram is referred with the terms Model Parsing Interface and Property Verification Interface. This is used to reach the BProVe WebService, and to interact with it via HTTP requests. A BPMN model and a property to verify are sent to the WebService, which handles the requests by parsing the BPMN model and the property into the syntax accepted by the BProVe Framework. The parsing of a BPMN model results in a model represented by means of the BPMNOS Syntax while the result of parsing the property is an LTL formula. The BProVe Framework component is based on a running instance of MAUDE loaded with the MAUDE modules implementing the BPMN Operational Semantics and the LTL MAUDE model checker [10].

Fig. 1.
figure 1

Component diagram of the BProVe toolchain.

Full size image

BProVe - Features. BPMN 2.0 is a quite complex modelling notation including around one hundred graphical elements, even though some of them are not really used in practice [14]. BProVe permits to easily handle a wide set of BPMN elements (see [5]). In particular, it is possible to consider BPMN elements that can have non-local effects that are difficult to handle with tools transforming BPMN models to Petri Nets. For instance, the handling of termination end events, that permit to quickly abort a running process, is usually not supported due to the inherent complexity of managing non-local propagation of tokens in Petri Nets; this feature is instead natively supported by the semantics at the base of BProVe. However, extending the framework to include further elements is not particularly challenging (even a problematic element as the OR-join can be conveniently added to our formalisation, see [7]).

Moreover, the main motivation to use Petri Nets encodings is the availability of already developed tools supporting verification [13]. However, such tools generally work well for standard Petri Nets, but they do not support extensions necessary to encode BPMN-specific features such as the management of task state evolution (e.g., enabling, running and complete). BProVe instead is based on an extensible framework that is able to potentially support all the features of BPMN, as the approach permits to apply language extensions to cover new features without affecting the verification phase.

A further advantage of BProVe is its support for BPMN Collaborations. This enables the analysis of inter-organisational correctness, which is still not supported by most of the available tools [1]. Results of checking safeness and soundness over BPMN collaborations differ from results obtained through encodings, which usually introduce a mapping at process level, and then compose the processes in a collaboration by means of an inner transition. This often results in imposing an a priori upper bound on the number of pending messages [17].

BProVe - Maturity. BProVe was already tested, as reported in [5], over 1026 models coming from the BPMN Academic Initiative (http://bpmai.org/). More recently, after some updates aiming at fixing parsing functionalities, we run a new massive verification session over the same dataset with the aim of verifying soundness and safeness properties. We are now able to handle 2569 models (see Table 1).

Table 1. Fraction of models satisfying soundness.
Full size table

The results of the session tell us that out of the 2569: 1745 models respect the Option to Complete property (67% of the total models); 2380 models respect the Proper Completion property (92% of the total models); 1937 models respect the No Dead Activities property (75% of the total models). In conclusion, 1279 models were detected as sound (49% of the total) which means those are the models that respect all the three properties mentioned above. In relation to safeness 94.5% models respect the property.

For a deeper insight of the observed models we refer to data reported in Table 2. The table reports a classification of models based on the number of BPMN elements they present. For each class we reported the total number of models belonging to that class and the percentage of models that satisfy the analysed properties. It is true that the majority of the analysed models are composed of less than 20 elements, and that those models are possibly designed by “junior” practitioners, and they are not coming from industrial organisations. However, one can reasonably argue that if soundness problems emerge with models that have a relatively low and manageable number of elements, they will most certainly emerge with more complex models, which have a higher number of elements.

Table 2. Fraction of models satisfying the considered properties (in class).
Full size table

Then, we collected in Table 3 data on the average time required to verify properties. Overall, we can observe that, as it can be expected, times increase with the dimension of the models even if it is still manageable.

Table 3. Average time (in ms), clustered in classes according to number of elements in the model.
Full size table

Summing up, the extended validation confirms the results we reported in [5], such as it is not seldom to find models that violate relevant behavioural properties, also after their release. In addition the experiments confirm that our approach seems to be applicable in practice to realistic BPMN models.

3 BProVe Plugin for Apromore

The BProVe tool has been integrated into Apromore in the form of a plugin for the “Editor” environment. The Apromore Editor allows users to create and edit BPMN models. Our plugin can verify correctness properties over these models. The result is an integrated editor that hides the complexity of verification to the user, favouring then the habit of verifying models for correctness before their release. In fact, as discussed in the previous section, it is not seldom the case that models are approved and released without much attention in relation to quite basic correctness properties.

When accessing BProVe from the editor, the BProVe Web service is invoked with the BPMN model open in the editor. The editor then waits for the model parsed into the BPMN Operational Semantics Syntax to be returned. At the same time, the “Check model correctness with BProVe” menu pops up. This will enable the selection of the properties to verify, and then to display the results. The properties mainly correspond to a predefined set of LTL templates. This choice was made to ease the usage of verification techniques by non-expert users. That said, one is assumed to be familiar with basic behavioral anomalies of process models, such as deadlocks, livelocks and dead activities, to understand the output provided by our tool. As future work, we envision a couple of improvements: (i) a visual animation of the behavioral anomalies identified by the tool (e.g. a deadlock) to lower the entry bar for non-expert users, and (ii) a second interface to allow expert users to enter arbitrary LTL expressions corresponding to properties of their interest.

A screenshot of the Apromore Editor with the BProVe menu is shown in Fig. 2. The checking menu is mainly divided into three parts described in the following.

Fig. 2.
figure 2

BPMN model correctness checking with BProVe in Apromore.

Full size image

Non-domain Dependent Properties. It reports a drop-down menu which permitting to select properties that will be checked over the process models within the collaboration, as well as on the whole collaboration. This property checking functionality does not require any other specification from the user. The properties are here shortly detailed.

  • “Can a Process Start?” It verifies whether at least a process, in the collaboration, is able to start.

  • “Can a Process End?” It verifies whether at least a process, in the collaboration, is able to reach the end state.

  • “Can All the Processes End?” It verifies whether all the involved processes will eventually reach the end state.

  • “No Dead Activities” It verifies that no Task in any process of the collaboration is dead. A dead task is a task that will never be executed.

  • “Option to Complete” It verifies that all the processes involved in the collaboration will reach the end state, once started.

  • “Proper Completion” It verifies for all the processes in the collaboration, that once a process reaches the end state, it does not have any token still circulating. This allows verifying that no other Task will be executed once the process has reached the end state.

Domain Dependent Properties. It reports several drop-down menus which permit to the user to select specific components of the collaboration (Pools, Tasks, and Messages) and to run verification over those components. This part of the menu can be seen as divided into three sub-parts here shortly detailed.

  • The “Verification of properties over a single Pool” part allows one to select a Pool from a drop-down menu, reporting the list of pools present in the collaboration, and to select one of the, previously described, “Non-Domain dependent properties” that makes sense verifying over a specific Pool. All the properties that can be verified over the entire collaboration can be verified for a specific Pool except for the one that checks whether all the Processes of a collaboration can end.

  • The “Verification of Message exchange” part allows to select Pools and Messages and to check whether a specific Pool will Send a specified Message, or to check whether a specific Pool will Receive a specified Message.

  • The “Verification of Task execution” part allows to select a Task and to check whether it will reach the status “Enabled”, “Running” or “Completed”. It also allows to verify whether the execution of a Task implies the execution of another one, by selecting that task and requesting a check.

Verification Result. It reports a text area used first to display the parsed model from the BPMN notation to the BPMN Operational Semantics Syntax, returned from a first call of the BProVe Web service, then to display the results of each property verification (returned from any other call of the BProVe Web service). The result of a property verification can be “True” or “False” plus the addition of the time, in millisecond, required to process that verification. In addition, a counterexample is available which allows highlighting also in the modelling environment the elements that lead to the property violation (see elements with the red border in Fig. 2).

4 Screencast and Links

A screencast is available at https://youtu.be/lFiS_Y-gygQ. This video illustrates a typical scenario where the user requires to check correctness properties of a BPMN model. BProVe is an open source software; it can be redistributed and/or modified under the terms of the GPL2 License. BProVe source code, as well as instructions for using it, can be found at http://pros.unicam.it/tools/bprove. The BProVe Apromore integration is embedded as a set of OSGi plugins into the online process analytics platform Apromore, which has been used for the screencast (http://apromore.org).