We propose a formal behavioral model based on the Symbolic Observation Graph (SOG) allowing to find the set of correct process model configuration choices while avoiding the state-space explosion problem. These choices are used to support business analysts in deriving correct variants. Our model takes into account the soundness requirements.

• BPMN input process model: In order to illustrate our approach, we used the process of the Fig.1 modelled using the Configurable Business Process Model and Notation (C-BPMN). This process includes 7 configurable elements (6 connectors and 1 activity) which are highlighted with a thicker border in the model. For instance, activities a1 and a10 are non-configurable, so they should be included in every configured variant. As for the activity a4 and the connector s1, they may vary from one process to another as they are configurable.







• Mapping to CBP2PN : In order to obtain an abstract formal definition of a business process model, we formally map a process in C-BPMN notation into Petri nets, specifically into the Configurable Business Process Petri Nets (CBP2PN). The C-BPMN process of Fig.1 is mapped onto CBP2PN in Fig. 2.







• Building the corresponding SOG : In this work, we propose to build an abstraction of the reachability state graph of the possible configurations using the Symbolic Observation Graph (SOG). This is done by observing the configurable elements of the process (that label the SOG arcs) and hiding non configurable elements inside the aggregates (the SOG nodes). The obtained SOG is depicted by the Fig.3.



• Extracting the deadlock-free configurations : As a result, each path of the SOG starting from the initial aggregate and leading to a final aggregate, represents one correct possible configuration leading to a deadlock-free variant .

As a proof of concept, we have extended the Signavio Process Editor in order to take into account the configuration of a designed configurable process. So first, we developed a plugin that allows to start the configuration procedure by charging an input file including the list of correct configurations. This list is provided by our SOG-based application that computes the corresponding SOG of the designed process and returns the set of its correct possible configurations. An example of this input file is in Fig. 4. In this example, two connectors are configurable: S1 and J2. For each conector's name, different types are defined.

Afterwards, we have particularly extended a function that initially allows to load a list of possible connectors types (default) that may replace a designed connector. This list is charged in the button « wrench » that is represented by the orange icon in Fig. 5.

In our work, we extended this function according to the following algorithm (c.f, Fig. 6). This function is triggered when the designer selects a given connector. It takes as input: (i) the selected connector (i.e., the variable "Element"), (ii) the set of correct configurations that were charged from the SOG file (i.e., the variable "dataMorphs"), and (iii) the connectors configurations that were already applied (i.e., the variable "confs"). As a result, it loads the list of allowed correct configurations in the variable "sogPossibleMorphs".
In this algorithm, we go through the configurations sequences (i.e. "dataMorphs.sequences"), sequence-by-sequence using x (line 9). And we go through the different configurations in each sequence x using id (line 10). Then, using a boolean variable "add", we test that this selected Element's name does exist in the correct configurations ids (i.e., "dataMorphs.sequences[x][id]") (lines 11 and 12). We need also to test if this Element was already configured, than it should have been saved in "confs". In this case, this Element should not be added to the list of configurations (lines 13-18). Otherwise, we add this Element in the variable "sogPossibleMorphs". Finally, the functions EliminateRedundant and Sort allows to eliminate the redundant types and to sort the types list of configurations respectively.

An example

In order to illustrate our algorithm, we take the example of the configurable process in Fig.1. and the "dataMorphs" matrix in Fig.7.

Initially, confs does not contain any configured elements. Then, the designer selects the connector S1 (cf. Fig.8). According to Fig.7, 3 connectors types are possible: OR, XOR and AND.

We propose to choose XOR. Hence, thanks to the test of line 15 in the algorithm 1, the only allowed configurations of the remaining connectors are highlited in the Fig.9. For example, when selecting the S3 configurable connector, we still have 3 possible proposed types: AND, XOR and OR (see Fig. 10). However, when selection J2, there are only 2 possible configurations: OR and XOR (see Fig. 11), and so on.

[1] W. V. D. Aalst, N. Lohmann, and M. L. Rosa. Ensuring correctness during process configuration via partner synthesis. Information Systems, 37(6):574 – 592, 2012.
[2] M. Rosemann andW. V. D. Aalst. A configurable reference modelling language. Information Systems, 32(1):1 – 23, 2007.
[3] Vogelaar, J., et al.: Comparing business processes to determine the feasibility of configurable models: A case study. In: BPM Workshops, France. (2011) 50-61

Authors:
Souha Boubaker (souha.boubaker@telecom-sudparis.eu)
Kais Klai (kais.klai@lipn.univ-paris13.fr)
Hedi Kortas (hedi.kortas@esprit.tn)
Walid Gaaloul (walid.gaaloul@telecom-sudparis.eu)