A Petri Nets Evolution Method that Supports BPMN Model Changes

-e correctness of the business process modelling notation (BPMN) is essential for software success, and the BPMN formalization is the foundation of the correctness verification process. However, dynamically adapting the formalized BPMNmodel to changes in the BPMNmodel and protecting tokens from being lost in the remapping formalization are the main limitations of the BPMN formalization under changing business requirements. To overcome these limitations, an approach for evolving a Petri nets model according to the BPMN changes is proposed in this paper. In this approach, a check algorithm is designed to identify the differences between the original BPMNmodel and the updated BPMNmodel. -en, the evolution rules of the extended Petri nets (EPN) model are defined according to the results of the checking program. Finally, these evolution rules are described in the query/view/transformation operational mapping (QVTo) language and implemented in the Eclipse platform.We demonstrate the effectiveness of the evolution of the BPMN formalization using a case study of the Web Payment business system. Moreover, the dynamic evolution of the BPMN formalization can maintain the consistency between the original model and the updated model, and this consistency has been successfully verified.


Introduction
Business process modelling notation (BPMN) is used as a standard for modelling business processes in the early phase of system development and for instructing the design and development [1]. BPMN2.0 (http://www.omg.org/spec/ BPMN/2.0) offers graph notations that can help business analysts and developers represent the process information of a business system. erefore, the success of software development depends strongly on the correctness of the BPMN model [2,3]. However, it is difficult to evaluate the correctness and ambiguity of the BPMN model because the notation specification does not include the semantics [4].
ere are many initiatives for defining the formal execution semantics [5][6][7][8][9]. ese formal definitions are used to evaluate the correctness, precision enforcement, and consistency of the collaboration of the BPMN model. Currently, the formal execution semantics of the BPMN model can be divided into two categories: those that use pure mathematics to describe the behaviours (such as Communicating Sequential Processes (CSP) [10], Z language, Formal Concept Analysis (https://www.upriss.org.uk/fca/fca.html), and Backus Naur Form (BNF) syntax [9,11]) and those that use Petri nets [12] to formalize the behaviours and business flows [13]. Various workflow modelling languages, such as YAWL [14], which are based on Petri nets, can extend Petri nets to address more complex workflows [15][16][17] and can be directly integrated with JAVA applications [18]. ese features enable that the Petri net to be a good candidate for formally defining the semantics of BPMN models [19] since the BPMN model is also flow-oriented [4].
However, the evolution of software artefacts are ubiquitous [20]. ese artefacts include programs, data [21], requirements [22], documentation [23,24], and modelling languages evolution [20]. Due to the change in requirements and advances in technology, software systems are not immutable. So, the existing systems can be continuously modified, complemented, and improved to be adapted to changes in the external environment by requirements evolution. us, one of the main challenges facing BPMN formalization is the automatic adjustment of the formalized model when the BPMN model is changed. To overcome these limitations, a BPMN formalization approach that supports dynamic evolution is proposed in this paper.
is work makes the following main contributions: (a) a check module is designed to capture and record changes to the BPMN model. ese changes can cause the target model to carry out in-place transformations; (b) an evolution approach is proposed, which includes a set of in-place transformations; and (c) a blackboxing library is designed for detecting the objects that have changed in the source BPMN model, and the in-place transformations have been implemented in the Eclipse framework.
is paper focuses on EPN model evolution when the BPMN model changes. We not only design a check module to capture the changes between the original BPMN model and the updated BPMN model but also develop EPN model evolution operations to represent the BPMN model changes.
e main objective of the EPN model evolution is to avoid model confusion and the loss of the token that is running. e remainder of this paper is organized as follows: Section 2 analyses the main related work that involves the BPMN formalization. Section 3 describes the architecture of the BPMN formalization evolution. e metamodel definitions of the EPN and the EPN model evolution module are described in Section 4. Section 5 demonstrates the EPN evolution using a case study. Additionally, the consistency between the original BPMN model and the updated BPMN model is examined. Finally, we discuss the primary contributions, conclusions, and future work in Section 6.

Related Works
e BPMN 2.0 standard specification [1] describes the complete execution semantics in natural language, which can provide a clear and precise description of the element operations. In the model-driven development (MDD), the BPMN, which is a dominant notation OMG standard, is a popular business process modelling method for the computation-independent model (CIM) level [25][26][27][28][29]. Many researchers have formalized the BPMN model and analysed the semantics using Petri nets theory [4,7,8,[30][31][32][33], CSP [10,34,35], event-B [36], OCL specification [2,37,38], and BNF syntax [3,11,39], among others. Various formal tools based on the Petri nets are used to specify the BPMN semantics for soundness verification [40,41], property verification [42], safety verification [43], validity verification [44], and semantics specification [45]. e verification techniques are important for business process modelling. Corradini et al. [3,11,39] exploited a textual representation to define the BPMN collaboration structure and formalized the well-structuredness, safeness, and soundness properties to check the correctness of BPMN collaborations. Zatout et al. [44] proposed formal orchestration process modelling with adaptation mechanisms and used the checking technique of the Petri nets to verify the validity of the generated models. For the large-scale business process, Dechsupa [33] provided a partitioning technique to verify the hierarchy and composition of the BPMN model.
Mrasek et al. [45] presented an approach for the reduction of a process to enable its verification with model checking based on the colored Petri nets (CPN). Wong and Gibbons [34] used CSP to analyse the behavioural semantics of the BPMN model. By exploiting CSP's refinement orderings, relationships between the timed and the untimed models are clearly defined. To construct behavioural properties of the BPMN model [46], these authors translate behavioural properties into the CSP model for simple refinement verification. Mendoza et al. [10] also used CSP and time constraints to formalize the BPMN model. In particular, the time semantics helps us to understand the consistency of the activity and task information and verify the time information of an exception flow. To enforce model preciseness, Correia and Abreu [2] proposed supplementing the BPMN metamodel with well-formedness rules that are expressed as OCL invariants.
An overview of BPMN formalization studies is presented in Table 1. Although many studies focused on defining the semantics precisely for BPMN [2, 5-8, 10, 34], few methodologies address the dynamic evolution of the BPMN formalization. In terms of the evolution of the Petri nets model, the evolution operations have been discussed in much research [47][48][49][50][51][52]. Hu et al. [47] and Capra and Camilli [49] emphasized on the structural evolution (such as projection, link, difference, and substitution) of the Petri nets. Meantime, due to the adding, removing, or changing features, the platforms evolution of the rule-based Algebraic High-Level net transformations was proposed by [47], and this evolution can be used to obtain an evolution of scenarios. Zhu et al. [53] proposed an algebraic Petri nets (APN) slicing technique that optimizes the model checking of static or structurally evolving APN models. Krishna et al. [52] used process algebra to define the evolution such as conservative, inclusive and exclusive, selective, contextaware, and so on. However, this research focuses on the evolution of the Petri nets itself and generates a new Petri net via structural transformations again.
When formalizing a BPMN model into a Petri net, it is necessary to consider the change of the BPMN model. In this case, we cannot map the BPMN model to the formalized model each time when the BPMN model undergoes a small change because every mapping consumes time and incurs costs. On the other hand, the remapping formalization model would lose the token that is running. However, existing BPMN formalizations that are model-driven typically lack the support of bidirectional incremental synchronization between the source model and the target model [2]. erefore, for in-place transformations, Kolahdouz-Rahimi et al. [54] proposed a systematic evaluation framework for comparing model transformation approaches. A relatively complete refactoring transformation approach was proposed by Einarsson [55], in which query/ view/transformation operational mapping (QVTo) language (https://www.omg.org/spec/QVT/1.3/PDF) is used to refactor the merge and divide operations. For verifying workflow, service orchestration, and choreography engines, Dijkman and Van Gorp [7] used the GrGen framework to develop the BPMN graph rewrite tools. Domínguez et al. [23] proposed an evolution framework in which the XML schema and documents are incrementally updated according to the changes in the conceptual model (expressed as a UML class model). erefore, we can use evolution methods to define an evolution transformation, which can dynamically evolve the BPMN formalization model according to changes to the BPMN model.
In this paper, we propose a BPMN formalization approach that can support dynamic evolution and use the Eclipse framework to develop its transformation plug-in. Compared with previous studies, our approach focuses on changing requirements and designs a check module that identifies the elements to be modified by comparing the original BPMN model and the updated BPMN model. e main advantage of our approach is that the Petri nets formalization model changes dynamically according to the changes in the BPMN model.

BPMN Formalization Evolution Architecture
e formalization evolution function is to maintain the consistency between the BPMN and EPN models when changes occur in a BPMN model. In this way, the EPN model is incrementally updated to avoid repeated mapping of the BPMN model to the EPN model. In addition, this incremental transformation can protect tokens when some place nodes are deleted. e evolution process is described in our transformation architecture (Figure 1), where the modified data of the BPMN model are written into a file and the EPN model is evolved based on this file. e main advantage of this process is that it can support the dynamic evolution of the EPN model. is evolution will involve four models: the BPMN model, the updated BPMN model, the EPN model, and the updated EPN model. e updated BPMN model is based on the BPMN model; the EPN model is mapped by the BPMN model via the BPMN2EPN plug-in; and the updated EPN model is generated by executing the EPN evolution plug-in.
us, in this approach, once the source model has been changed, the evolution plug-in can refine the target model correspondingly through the QVTo engine based on the model modification data.
In this process, we assume that, at each time, evolution transformations are dispatched from only one designer; hence, we do not consider concurrency issues.
is formalization approach differs from that of other researchers because our approach focuses on the dynamic evolution in the formalization transformation process. erefore, our approach can facilitate the adjustment of the system requirements by the business analyst. As the BPMN2EPN plug-in (Figure 1) has been developed in our previous research [25], this paper will just focus on the EPN evolution.

EPN Model Specification.
A condition-event net (CEN), which is a basic Petri net, is composed of a condition (state), an event (transition), and a link (arrow) and is simple and easy to understand in contrast to other Petri nets that are used for process modelling [25,56]. However, it is difficult to represent the gateway of the BPMN model. us, the CEN has been extended and a mapping between the BPMN model and the CEN model has been designed in our previous research [25]. Here, the EPN model is defined formally as follows. (i) P denotes the control flow and the message flow between the activity nodes and represents the execution order of the activity nodes. P consists of a set of finite conditions and is expressed as P � p 1 , p 2 , p 3 , . . . , p n (ii) ST � st 1 , st 2 , st 3 , . . . , st n denotes a set of finite silent transition nodes that represent the business process start/end points and specify the direction of the execution path (iii) BT � bt 1 , bt 2 , bt 3 , . . . , bt n denotes a set of finite behaviour transition nodes that represent the task or event in the BPMN model (iv) IA⊆(P × ST) ∪ (P × BT) denotes a set of input arcs Table 1: Formal methods, objective, dynamic evolution, and implemented tools of BPMN formal studies.

Source
Formal methods Objective Dynamic evolution Implemented tool Wong and Gibbons [34] CSP Behavioural property verification No No Dijkman and Van Gorp [7] Petri nets mapping Semantics specification No Yes Van Gorp and Dijkman [8] In-place transformation Semantics specification No Yes Correia and Abreu [2] OCL invariants Preciseness enforcement No No Mendoza et al. [10] CSP + Time Soundness verification No No Takemura et al. [30] Petri nets mapping Semantics specification No Yes Bryans et al. [36] Event-B Formal verification No Yes Yu et al. [31] Object Petri nets mapping Formal verification No Yes Zhu et al. [53] Colored Petri nets Semantics specification No Yes Dechsupa et al. [33] Colored Petri nets Hierarchical verification No Yes Krishna [52] Process algebra   (2) If ∃p 1 ∈ P and p 1 includes  Definition 3. For a EPN � 〈P, ST, BT, IA, OA, M 0 , SN〉, ∃∀bt 1 , bt 2 ∈ BT, let ρ: bt 1 ⟶ bt 2 denote that bt 1 must be implemented prior to bt 2 , where " ⟶ " expresses an execution order between bt 1 and bt 2 , and ρis a place node that links the two behaviour transition nodes. us, we define two functions, namely, source and target, which represent the predecessor node and the successor node, respectively, of the place node, such that source(ρ) � st 1 and target(ρ) � st 2 .
. . , bt n ∈ BT, ∀p 1 ∈ P, should satisfy the following conditions: (1) According to Definition 2, st 1 is a start operation node and st n is an end operation node. (2) Suppose P(bt 1 × p 1 ) � P(p 1 × bt 2 ), and an execution order has been defined between bt 1 and bt 2 based on Definition 3. A process sequence, which is denoted as Pi � st 1 ⟶ bt 1 ⟶ bt 2 ⟶ bt 3 ⟶ · · · ⟶ st n , consists of the start execution order, the end  Figure 1: Architecture of the evolution process of the extended Petri nets model. execution order, and multiple execution orders (bt 1 ⟶ bt 2 , bt 2 ⟶ bt 3 , bt 3 ⟶ bt 4 , . . .). BT is a set of tasks of the business system.
Based on the above definitions, the main properties of the EPN model transition elements are as follows: (1) A silent transition node that links a place node: this place node has only one output arc, which represents a Petri net starting point. (2) A silent transition node that links a place node: this place node has only one input arc, which represents a Petri net ending point. (3) A silent transition node that links more than one place node represents the path decision in a Petri net. (4) A behaviour transition node that links more than one place node represents the behaviour operation in a Petri net. (5) A subpage node that links more than one place node is a sub-Petri net and can be further specified.  [4][5]. en, for each task in O_Task and N_Task, the algorithm executes the comparison operation: if a task exists in the BPMN_old model but not in the BPMN_new model, then this task is stored in M_Task and its operation label is set as "delete" (lines 9-17); if a task exists in the BPMN_new model but not in the BPMN_old model, this task is stored in M_Task and its operation label is set as "insert" (lines 21-23); and if a task exists in both the BPMN_old and BPMN_new models but the task names differ, then, the name of this task is stored in M_Task and its operation label is set as "modify" (lines 24-29). Next, the remaining elements in BPMN_old and BPMN_new are compared in the omitted part of the check algorithm. e output file is important because the evolution operation that is executed by the evolution component depends on the results in the output file.

EPN Model Evolution.
According to the result of the check algorithm, the modification of the BPMN model involves the task, gateway, intermediate event, end event, and flow. erefore, we defined a set of evolution operations of the EPN model as listed in Table 2. For example, if a task is deleted, created, or modified in the BPMN model, then the EPN model should execute an add, delete, or modify operation correspondingly.
According to Table 2, the EPN model evolution has three types of elements: (1) behaviour transitions, (2) silent transitions, and (3) places. In the following, we will explain the main evolution transformation in detail.

Behaviour Transition Node Evolution
(1) Delete Action. e delete behaviour transition action removes a behaviour transition node in the EPN model. For example, if there is a task that validates the user name, then there is another task that validates the user password. e actions of validating the user name and validating the user password may be merged into a single task (validating the user information) of the client, as illustrated in Figure 2. In this scenario, based on the check algorithm, two behaviour transition nodes that are linked by a place will be merged into one, namely, a behaviour transition node must be deleted.
Two delete scenarios must be distinguished: (1) if the token of a deleted behaviour transition node has just arrived at the input place, which should be linked to the next behaviour transition node, then the token should be transferred to the output place to the next behaviour transition to ensure that the token exists; (2) if the token of a deleted behaviour transition node has not yet reached the input place or has already reached the output place, then this behaviour transition node should be deleted directly. erefore, the steps in the evolution are as follows: (1) Design two queries that obtain the id numbers of the behaviour transition node and place node to be deleted from the blackboxing library. (2) Design a query that obtains the id number of the behaviour transition node to be modified from the blackboxing library. (2) Insert Action. e insert behaviour transition action adds a new behaviour transition node into the EPN model. As illustrated in Figure 3, a task (add to cart) is added in the source BPMN model; thus, in this scenario, the add behaviour transition action should be executed in the EPN model. erefore, the steps in the evolution are as follows: Scientific Programming (1) Design a query that obtains the id number and name of the behaviour transition node to be added from the blackboxing library. (2) Add the behaviour transition node.
(3) Add a place node and corresponding input and output arcs. (4) Set the sources and targets of the new input and output arcs. (5) Modify the output arc that connects the behaviour transition node to be added.
(6) Modify the input arc that connects the behaviour transition node to be added.
(2) Design a query that detects the token's position. If the input place of the deleted node has a token and the deleted node is not an end node, proceed to step 3. Otherwise, proceed directly to step 4.
(3) Modify the connection of the output arc linked input place to protect the token.
(5) Find the place node to be deleted when the source of an arc is the silent transition node to be deleted.
(6) Delete the place node. (7) Delete the output arc that connects the silent transition node to be deleted. (8) Modify the input arc that connects the silent transition node to be deleted.
(2) Insert Action. e insert silent transition action adds a new silent transition node into the EPN model; hence, a new gateway or a new end event is added in the BPMN model. An example is presented in Figure 5. e typical process of web shopping online is to select goods, place an order, and provide payment. However, if the user decides not to buy the selected goods, she can cancel the order and the process should be terminated. Alternatively, if she is indecisive regarding this order and does not perform the next operation, the system will take an action (time out) to address this situation, and the process should be terminated.
In this case, an inclusive gateway and the corresponding actions are added in the source BPMN model. erefore, in the evolution of the EPN model, a silent transition element and its related behaviour transition element will be added based on the check algorithm.
us, the steps in the evolution are as follows: (1) Design a query that obtains the number of gateway paths and clones the original corresponding silent transition.

Place Node Evolution.
e place node in the EPN is related to the sequence flow or message flow element in the BPMN, and the evolution action includes "add," "delete," and "modify" actions. For the add action, the steps in the evolution are as follows: (1) Design a query that obtains the id of the place node from the blackboxing library, and add the corresponding place node (2) Add an input arc for the place node, and set the source node and target node of this input arc (3) Add an output arc for the place node, and set the source node and target node of this output arc For the delete action, the steps in the evolution are as follows: (1) Design a query that obtains the id of the place node to be deleted from the blackboxing library (2) Delete the place node (3) Delete the input arc and output arc that connect the place node to be deleted For the modified action, the steps in the evolution are as follows: (1) Design a query that obtains the id of the place node to be modified from the blackboxing library (2) Modify the output arc that connects the place node to be modified (3) Set the target of the arc to be modified e model evolution proposed in this section mainly considers model element modifications (such as the addition of a transition node, deletion of a transition node, and addition of a place node), in contrast to Hu's [47] proposed evolution, which focuses on using one or more Petri nets models to generate code via structural transformations (such as projection, link, difference, and substitution).

Evolution Implementation.
e QVT language, which is an open model transformation language that is based on the OMG standard, includes the QVT relations, the QVT core, and the QVT operational mappings (QVTo). e QVT language offers a blackbox implementation mechanism that is similar to the JAVA virtual machine, which enables programmers to perform more complex model transformations. us, based on the QVT language, the EPN model evolution in the Eclipse framework (https://projects.eclipse. org/projects/modeling.emf ) is illustrated in Figure 6.

Scientific Programming
Based on the step in which the evolution rule is implemented, a set of actions (Table 3) is designed for implementing the EPN model evolution. ese evolution actions can be activated when the execution result of the check is not null; for instance, the merge action of the behaviour transition is activated when the outgoing flow of a task is removed and the target node of the incoming flow is modified in the modification data file. To perform the merge action, a set of operations (e.g., query getObjectToDelete(), mapping inout deleteBehaviourTransition(), and mapping inout deletePlace()) should be executed. e insert action of the behaviour transition is activated when a new task is added and the target of a sequence flow is modified in the modification data file. us, a set of operations (including query getObjectToAdd(), mapping inout addBehaviour-Transition(), mapping inout addPlace(), map setTarget(), and mapping inout modifyArc()) should be executed for this insert action. e add actions of the silent transition are activated when there are new gateway keywords or end events in the modification data file.
To illustrate this evolution process, a partial view of the EPN model in-place transformation is shown in Figure 7. DeleteBehaviourTransition.qvto conducts the delete evolution of the behaviour transition node when a task node has been deleted in the BPMN model. us, the inout mapping initially defines a guard that determines whether the transition node must be deleted by using the query getObject-ToDelete() (line 91). Query getObjectToDelete() uses the blackboxing method isDeleteObject() to read the modification data file and obtain the delete node. en, the delete transition node operation is executed (line 96). e output arc and the place that is linked by this transition node are also deleted (lines 98-103). Finally, the input arc of the transition node is modified (lines 105-108).

Scenario.
e following scenario (http://www.w3.org/ TR/web-payments-use-cases/) is provided by the W3C organization. We consider a web payment scenario, which is organized into four phases: negotiation of payment terms, negotiation of payment instruments, payment processing, and delivery of product/receipt and refunds.
Negotiation of payment terms phase: a customer browses the items on the online shopping site. She selects the goods and puts them into the shopping cart prior to logging into her account. We define this phase as a Search Service.
Negotiation of payment instruments phase: once the customer has decided to buy these goods, the shopping site accepts a payment, which can be in the form of a credit card, debit card, secured money order, Google wallet, or Apple-Pay. Next, the customer selects a card that is highlighted by default because she used it for a previous purchase and the shopping site asks her to input her zip code and the verification code before the purchase is completed. We define this phase as a Payment Instruments Service.
Payment processing phase: the website receives a message from the customer's device that authorizes the payment. e shopping site submits a message to the financial company that requests a proof of hold for the funds. en, the customer and the shopping site receive proof of payment from the financial company, and the funds are immediately deducted from the customer's line of credit and transferred to the website's bank account. We define this phase as a Payment Service. Finally, the shopping site sends the customer a digital receipt, the website's shipping department packs and delivers the purchased items to the shipper, and the shipper sends them to the customer. We define this phase as a Delivery Service. Figure 8 illustrates the business process model of the web payment case, which consists of a Search Service, Payment Instruments Service, Payment Service, and Delivery Service. ese services are subprocesses in the BPMN model. Here, we use our previous research to map the BPMN model onto the EPN model as illustrated in Figure 9. e BPMN model can be verified by the EPN model using the verification technique that is proposed in [20].

Models.
To promote the shopping service, the online shopping site decides to offer a cash-on-delivery service. So, the cashon-delivery service should be added in the original BPMN model, as shown in Figure 10.
ree new tasks (Select Payment type, Select Cash on Delivery, and Select Online Pay), one exclusive gateway, and one control flows should be added and message flows should be modified or deleted. e consistency of the new business process model is important for the online site. us, the check module is executed to record the modification data between the original BPMN model and the updated BPMN model. en, the EPN model evolution plugin is executed to avoid repeated mapping. Figure 11 shows the result of the EPN evolution action. Using the Petri nets standard verification techniques such as deadlock and livelock analysis [25,26], the updated BPMN model is correct.
In contrast to other BPMN formalization approaches, our proposed approach can ensure the consistency of the business process when its requirements change. More importantly, our proposal can effectively protect the token from being lost during the evolution process. We can use the formalized model to verify the consistency between the original BPMN model and the updated BPMN model (Section 5.3).
is model is essential for protecting the business process model changes that do not affect the entire business system.

Evaluation.
Firstly, we can use the ePNK tool to verify the correctness properties of the evolved EPN model (Figure 11), such as no deadlocks, no closed loops, and no isolated nodes in the evolved EPN model; then, we use the formalized model to verify the consistency between the original BPMN mode and the updated BPMN model and to analyse the behavioural semantic compatibility of these two Petri nets models. us, the original BPMN model and the updated BPMN model are defined as semantically compatible if they perform the same business behaviour. Let the original BPMN model, which is denoted as BP old , be      (1) According to this semantic compatibility analysis, the original BPMN model and the updated BPMN model are partially semantically compatible; namely, tasks, gateways, and control flows have been added in the updated BPMN model ( Figure 10, rounded rectangle filled with blue), and the corresponding silent transitions, behaviour transitions, places, and arcs must be added into the EPN evolution model (Figure 11, grey icon). e internal business process of the online shopping site and the financial company in the original BPMN model are the same as those in the updated BPMN model. us, if the BPMN model is modified, we can verify the consistency between the original BPMN model and the updated BPMN model using the refactoring formalization model.

Conclusions and Ongoing Work
Currently, the development of methodologies that enable the dynamic evolution of the BPMN formalization is one of the main challenges in BPMN model formalization. In the formalization approach that is proposed in this paper, we have designed an evolution module that supports the automatic update of the formalized model and protects the token from being lost when the original BPMN model has been changed.
14 Scientific Programming In this study, we propose a model transformation process that focuses on a BPMN model formalization that supports dynamic evolution. e evolution operation is the core element of the formal model transformation approach that we have proposed. We have demonstrated how we address dynamic evolution using in-place transformations in a case study in which we apply the Eclipse tool. Overall, our proposed approach can completely formalize the BPMN model elements while supporting in-place transformations, which can reduce the transformation costs and maintain the consistency between the BPMN model and the EPN model (the BPMN formalization model).
However, the effectiveness of the check module affects the evolution cost directly: if the BPMN model becomes more complex, the effectiveness of the check module might decrease. us, increasing the execution speed of the check algorithm is necessary, which can help to reduce the evolution costs. In addition, our proposed approach constrains the evolution operation without further refinement. us, the evolution rules, involving artifacts, conversations, resources, and exception event, need to be formulated in our future work.

Data Availability
e data used to support the findings of this study are available from the corresponding author upon request.

Conflicts of Interest
e authors declare that there are no conflicts of interest regarding the publication of this paper.