key: cord-0513054-xfk76f6m
authors: Guerreiro, S'ergio; Sousa, Pedro
title: A framework to semantify BPMN models using DEMO business transaction pattern
date: 2020-12-17
journal: nan
DOI: nan
sha: b673589873b9562f43e38357d2a7f170ecb0d7db
doc_id: 513054
cord_uid: xfk76f6m

BPMN is a specification language widely used by industry and researchers for business process modeling and execution. It defines clearly how to articulate its concepts, but do not provide mechanism to represent the semantics of the produced models. This paper addresses the problem of how to improve the expressiveness of BPMN models, proposing a definition for the semantics of a business process within a BPMN model, and improving the completeness of the models in a systematic manner, so that models can describe far more situations with few extra managed complexity. We conceive a framework based on the business transaction patterns available in the enterprise ontology body of knowledge to prescribe the foundations of semantic BPMN models. A tool has been developed to automate the framework. Then, two industrial proof-of-concepts are used to measure its coverage, both positive and negative, and to argue about our proposal's usefulness. After that, the proposal is compared with others using a systematic literature review. A full BPMN pattern is proposed encompassing the happy flow, the declinations, the rejections and the revocations, without adding any new element to the BPMN specification. A software tool has been developed, and made publicly available, to support the automatic generation of the BPMN models from the proposed patterns. Our semantified BPMN pattern allowed the identification of a large amount of implicit, and other not implemented, situations in both proof-of-concepts. It is concluded that the usage of a semantic solution, grounded on a sound pattern, allows the systematic enrichment of the BPMN models with a bounded effort. Moreover, to simplify the BPMN executable models' implementation, its elements could be classified as implicit, explicit, or not implemented yet. Finally, related work indicates that this work is demanded, but no full solutions are available.

A business process is a collection of events, activities, and decisions that brings value to the customers of an organization [1] . The use of graphical notations to express business processes is a common approach to achieve a more concise and precise description. The Business Process Model and Notation (BPMN [2]) is the de facto standard used by industry and researchers for business process modeling and execution. Beyond modeling discussion, the business process models could also be extended to be used as executable ones. In fact, BPMN specification offers the following three sub-classes as an alternative to full mod-sidered to be formal if both its syntax and semantics can be precisely defined. When the semantics is formally defined, sentences in the language then have a unique interpretation", this property does not hold in BPMN models. In fact, it is on the modeler's responsibility side to interpret the meaning of a given BPMN model. Conversely, any other modeler could interpret the same model differently, e.g., uBPMN [6] extends BPMN with more notations to deal with ubiquitous computing technologies alleging that BPMN do not offer support for this domain. The study in [7] corroborates this problem statement and reinforces it when remote environments are imposed, e.g., due to COVID-19 pandemic.

On the other hand, the business processes expressed by customers usual refers only to the "happy flow" and disregards some other forms of exception handling [8] . This option is not acceptable in business process models under scenarios subject to uncertainty [9] Therefore, real business processes implementations usually relies on those incomplete semantic models, and then, this problem is further propagated, and amplified, to the implementation of the correspondingly BPMN executable process models.

The implications of this problem within organizations are manifold (i) misunderstanding in business process modeling, reflecting in implementation failures, and (ii) inconsistent design in the business process models, reflecting in time consuming tasks for implementation, re-engineering and knowledge dissemination due to an higher learning curve.

To address this problem we propose a framework that enforces the patterns available in Enterprise Ontology [10] onto BPMN models 1 . The usage of patterns is also corroborated in the literature. [11] shows that many publications discuss their patterns in isolation, and no embracing pattern exists for the many business process modeling patterns proposals available. We stress that our goal is to study solutions to improve the BPMN models expressiveness using knowledge available from other semantic-based approach, and not to change the BPMN language itself.

The main contributions of this paper are (i) the increase in BPMN models completeness by adding patterns, with a reduced, and thus managed, increase in complexity. This has major impact on executable models maintenance, reuse and testing; (ii) the standardization of communications between pools according to Enterprise Ontology; (iii) the exemplification of the solution applied to two proof-ofconcepts; (iv) an extensive literature review to assess our work with the available knowledge in this domain; and (v) a public tool to facilitate the generation of the semantified BPMN models.

The paper is organized as follows. Firstly, Section 2 details the background concepts related with BPMN and DEMO. Afterwards, Section 3 proposes a mapping be-tween the DEMO complete pattern onto BPMN models. Then, Section 4 presents two proof-of-concepts of the solution and discusses the obtained results. After that, in Section 5 the literature is surveyed to elate our proposal with others. Finally, Section 6 concludes the paper and identifies future work.

This section presents the background used throughout the paper. Firstly, the Business Process Model and Notation (BPMN) foundations are introduced, then the Design & Engineering Methodology for Organizations (DEMO) theory and constructs are explained.

A business process is commonly perceived as the sequencing of activities and resources that organizations use to produce value to their clients. The graphical representation of activities, in particular their sequence, is an effective way of modeling processes. The BPMN specification [1, 2] is a graphic process modeling notations used for this purpose. Initially proposed by the Business Process Management Initiative, it is now under the scope of Object Management Group, 2 and the ISO 19510 standard 3 . BPMN is focused on modeling the articulation activities, resources, flows, gateways, events, messages and data objects that occur in a business process.

An high-level BPMN meta model proposed by [1] is depicted in Figure 1 . The most relevant concepts for this paper are the following. An event which is defined as "something that "happens" during the course of a Process. These Events affect the flow of the Process and usually have a cause or an impact" [2, p. 83]. An activity which is defined as "work that is performed within a Business Process'. Activities represent points in a Process flow where work is performed. They are the executable elements of a BPMN Process" [2, p. 151]. A pool which is defined as "the graphical representation of a Participant in a Collaboration. A Participant can be a specific PartnerEntity (e.g., a company) or can be a more general PartnerRole (e.g., a buyer, seller, or manufacturer)." [2, p. 112]. This definition is particularly important due to the relation with the forthcoming concept of the DEMO actor role and also due to its separation of a participant by a different pool within the scope of a collaboration. A lane which is defined as "a sub-partition within a Process (often within a Pool)" [2, p. 120]. BPMN supports a detailed specialization of activities, events, and gateways leading to over 100 graphic symbols. Despite such high amount of symbols, BPMN can lead to disparate model interpretations concerning the two core concepts of any BP: resource and activity. In this context, [12] Figure 1 : BPMN metamodel as proposed by [1] .

of overlapping language concepts and lacks state concept to ensure a more sound semantics.

Dietz and Mulder [13] define the notion of Enterprise Ontology (EO) as a set of capabilities to deal with the essential aspects of process-based organizations. DEMO aims at understanding the organization using the essential models to represent organizational design and operation. [14] show a broad usage of DEMO by the industry, reinforcing the idea that EO is able to capture the essence of the organization while offering abstraction from implementation details. Among other aspects, DEMO prescribes a pattern for the communication and production of acts and facts that occur between actors in the scope of a business transaction. A business transaction is defined in [13] as: "a sequence of coordination-acts 4 /facts 5 , within the transaction pattern, concerning some product. It involves two actors, one in the role of initiator and one in the role of executor. An actor is a subject in filling an actor role". On industrial implementations this pattern is used as an element within a network of transactions. Therefore, to enforce these principles it is of core importance to understand its structure and dynamics.

Similarly with other approaches [16, 17, 18] , a DEMO business transaction model has two distinct worlds: (i) transition space and (ii) state space. DEMO's transition space is grounded in a theory named Ψ-theory (PSI), where the standard pattern of a transaction includes two distinct actor roles: the Initiator and the Executor. These two actor roles are considered the minimal conditions to perform communication within a business transaction: the actor role that requires a new product and the actor role that is able to offer the new product. The transaction pattern is performed by a sequence of coordination and 4 Accordingly with [13] , the coordination acts (or C-acts for short) are communicative acts in Habermas' category of regulativa [15] . 5 A facts is considered to exist in the objective world. 

Figure 2: DEMO standard pattern of a transaction between two actors with separation between communication and production acts (from source [13] ). production acts that leads to the production of the new production fact. In detail, it encompasses: (i) order phase that involves the acts of request, promise, decline and quit; (ii) execution phase that includes the production act of the new fact itself; and (iii) result phase that includes the acts of declare, reject, stop and accept. Firstly, when a Customer desires a new product, he requests it. After the request for the production, a promise to produce is delivered by the Producer. Then, after the production, the Producer declares that the production is available. Finally, the Customer accepts the new fact produced. DEMO's basic transaction pattern aims at specifying the transition space of a system that is given by a set of allowable sequences of transitions (see Figure 2 ).

Besides the sequence of request, promise, declare and accept (also named as the happy path), cf. Figure 2 , the Coordination-acts of decline and reject are negative options that actor roles can take during the course of a business transaction execution. A decline corresponds to an impossibility of promising the production of a new product, by the executor role, e.g., due to lack of raw-material stock. In that situation it is a decision of the initiator actor to finish the business transaction communicating with a quit, or insisting with the request. This conversation could drive to a deadlock situation. The deadlock is avoided with common sense between the actors.

Symmetrically, a reject could be issued by an initiator role after the new product had been declared, e.g., if the declared product is defective. In that situation, the executor role decides if the rejection is acceptable, and if so, a stop is emitted. Otherwise, a declare is re-emitted to the initiator. The difference to the declination situation is that, now, the new product already exists in the world, and its production involved costs. Therefore, the cost has to be assigned to one of the two actors involved. Usually, if the cost is incurred by the executor actor then a stop is issued and the business transaction execution ends.

DEMO complete transaction pattern also includes the possibility to cancel any of the previous executed act. A revoking act is the consequence of a posteriori dissatisfaction, regret, etc., about a fact or act occurred in the past. Moreover, any revocation event can occur at any time during the execution of a business transaction. Four different revocation events could occur: revoke a request -when the initiator actor abort his/her initial request of a product, e.g., I do not want a pizza anymore; revoke a promise -when the executor actor realizes that has no conditions to proceed with a previous promise, e.g., the no longer have ingredients to produce the promised pizza; revoke a declare -when the executor role calls off the declared product, e.g., return me the delivered pizza because that is not yours; and revoke a accept -when the initiator actor realizes that the previously accepted product is not in good conditions, e.g., reject the delivered pizza because there is a fly on it. The consequence of a revocation event is one of the following: (i) allow, when the initiator allows a revoke promise or a revoke declare, or when the executor allows a revoke request or a revoke accept; (ii) refuse, when the initiator refuses a revoke promise or a revoke declare, or when the executor refuses a revoke request or a revoke accept. In the case of a refuse the revocation can always be re-triggered.

To better visualize this explanation, Figure 3 depicts the flow that is executed for each one of these four revocation events distinguished by different colors. In general, each revocation encompasses the following sequential phases: (i) first actor role triggers revocation and sent it to the second actor role, (ii) second actor role decides to allow or refuse the revocation, (iii) if allowed then all the previous executed transaction steps in both actor role are rollbacked 6 and the transaction is re-positioned in the correspondingly target transaction step, and (iv) otherwise, refuse is emitted, revocation ends and business transaction proceeds as initially. Whenever a revocation event is allowed, the recovery flow to be executed depends on the specific event that has been issued. In detail, for each revocation, and with increasingly complexity. Regarding the revoke accept, the rollback of accept is performed and then reject is emitted. In this situation, the business transaction is relocated in a state similar to a rejection of a declare. Regarding the revoke declare, the rollback of accept, declare and execute is performed and then a promise reemitted. In this situation, the initiator knows that his/her request will be re-executed and re-notified by a declare with production finish. Regarding the revoke promise, the rollback of accept, declare, execute and promise is performed and then a decline is emitted. In this situation, the business transaction is relocated in a state similar to a decline of a request. Finally, regarding the revoke request, the rollback of all acts need to be performed: accept, declare, execute, promise and request. In this situation, the business transactions is fully rollbacked. As could be verified, revocation complexity increases when we cancel the steps closer to the beginning of the transaction.

As a summary, the full list of coordination-acts are the following: request, promise, declare, accept, decline, reject, revoke request, revoke promise, revoke declare, revoke accept, allow, refuse and stop. The only production-acts is the execute.

This section is grounded in the previous concepts introduced on section 2, and to better explain the conceptualization beneath DEMO Ψ-theory an example is used. Therefore the DEMO principles are used but expressed in 6 corresponding to the inverse execution of each transaction step BPMN notation. The objective is to combine a well-known notation (BPMN) with a comprehensive business process semantics definition (DEMO).

Considering a single business transaction of producing a product; at least two business actors need to be considered: the transaction initiator (TI) and the transaction executor (TE). Considering that both actors are located on two different organizations, then two BPMN pools are considered (cf. Figure 4) . Withal, this option is also aligned with the BPMN pool definition. The first initiates the transaction and the second executes it. Moreover, the second only starts production in reaction to an explicit request from the first one. When TI decides to request a product, the task of Request product is executed resulting in (i) the emission of a communication act (C-act) with the purpose of Requesting a product to the TE, and (ii) the creation of a new communication fact (C-fact) in the world. This double outcome is repeated in all the business transaction steps, except on the Execute product step where no C-act is expected but a P-act is. Figure 5 expands all the business transaction steps included in a DEMO standard pattern, clarifying how the sequence of states originate a new Pfact in the world. Whenever an actor role is expecting a C-act from the other, then a BPMN interrupting message intermediate event is used. All the business transactions respect this pattern, even when some acts or facts are not observable. In that situation, the acts or facts are considered implicit in the execution of the business transaction.

A more detailed pattern is presented in Figure 6 . This time, the disagreements between actors are considered, namely declining to produce a product and the rejection of a produced product. If a business actor disagrees with another, then a decision point is achieved. In case of declination, it is up to the TI to issue a new request; on the contrary, in case of rejection, the TE needs to evaluate the rejection arguments before deciding between stopping or re-declaring the product. Both situations can lead to a deadlock situation; it is the context of social norms that prevents a situation of an eternal deadlock. On the one hand, the C-act decline corresponds to an impossibility of producing a product (e.g., due to stock shortage) and triggers the TE end of process flow. On the other hand, TI upon the reception of a declination could decide to emit a new request or also to stop his/her process flow. The rejection C-act is symmetric with decline. Whenever a TI receives a C-act declare then a product check is performed. If TI do not agree with the delivered product then a C-act of rejection is emitted. Understanding that P-fact already exists in the world, is on the TE responsibility to decide if the rejection is valid or not. If so, a stop C-act is emitted and the TI and TE process flow ends. Otherwise, the declare C-act is re-emitted and the loop is restarted. Again, a possible deadlock could occur, and in the limit can only be solved using litigation. The synchronization between both BPMN pools is assured using the event-based gateway. This gateway permits the process sequence to evolve accordingly with the act communicated by the other pool (cf. its definition on [2, p. 297] "Basically, the decision is made by another Participant, based on data that is not visible to Process, thus, requiring the use of the Event-Based Gateway". Whenever any event defined in an event-based gateway is triggered, then the outgoing path will be used and all the remaining paths will no longer be valid [2, p. 298].

Whenever an actor role, within the scope of any business transaction, need to revoke a previous executed transaction step, the revocation pattern is triggered. As defined in Figure 3 , DEMO complete transaction pattern offers the four following revocations differentiated by color: revoke a request, revoke a promise, revoke a declare and revoke a accept. Figure 7 depicts all the possible revocations using the same colors: revoke request, revoke promise, revoke declare and revoke accept. The mapping of DEMO revocations onto BPMN requires the addition of two BPMN elements to the model presented in Figure 6 : the multiple start event and the compensation event.

Multiple start events are necessary because while the normal flow of a process executes a revocation act could happen. In other words, the triggering of the transaction start or one of the four revocations are independent events. For that reason, in TI, a start event is placed before a parallel gateway (named in the model as INITIAL GATE-WAY ) that triggers two distinct branches: the normal flow corresponding to the DEMO transaction pattern and an event-based gateway catching all the message events related with the revocations. The same applies to TE, except that the start event is replaced by a message start event corresponding to a communication received from TI. This solution allows the triggering of any revocation anytime. Then, a communication with the other actor role is established to assert if the revocation could be acceptable, e.g., a request revoke is triggered in TI, sent to TE and decided by TE. If TE agrees, then communicates positively with TI (which by its turn will rollback the transaction steps of its competence, namely, rolling back the accept P-act) and then rollbacks the P-acts of declare, execute and promise. In this request revoke example, both pools also trigger the terminate event to end all running process instances. In the opposite, if TE do not agree with the revocation, then a refuse is communicated to TI and the normal flow continues. All the remaining revocations are modeled in Figure 6 in alignment with Figure 3 .

Moreover, when a revocation of a non-started transaction is triggered it is on the other actor's responsibility to reject it. For instance, when a TI revokes an accept of a transaction that has not been even started. This situation could be considered as a deception attempt and rejected.

Compensation events are the native mechanism in BPMN to trigger a new compensation flow, which is defined as: Figure 6 : The DEMO standard pattern of a transaction between two actors with separation between communication and production acts, and presenting the disagreements, represented in BPMN. "the flow that defines the set of activities that are performed while the transaction is being rolled back to compensate for activities that were performed during the normal flow of the process" [2, p. 500]. Our solution relies on compensation events classified with the name of the revocation act to be performed.

Finally, the possibility of revocation recurrence is studied. The recurrence of revocations only make sense in a revoke declare situation where the transaction is reverted to the promise step and resumed from there. For the remaining situations the following behavior is expected. In the case of a revoke request the transaction is ended. In the case of a revoke promise the transaction is declined. In the case of a revoke accept the transaction is rejected.

In real environments, the business transactions are defined within a network of actors and transactions, e.g., a Payment transaction succeeds a Production transaction. Applied scenarios of these situations are detailed in Section 4.

A composition pattern occurs whenever an executor actor role assumes the responsibility of initiating another transaction. Figure 8 exemplifies a dependency between the "happy flow" of two business transactions using the request after promise (RaP) pattern. It is noted in this example the actor role B assumes the role of Transaction 1 TE and Transaction 2 TI. The coordination between them is performed by the correspondingly BPMN process. For model simplification, the declination, the rejection and the revocations are not designed in the model. However, the dependency is exactly the same. transactions using the RaP as dependency pattern. Transaction 1 is declared when Transaction 2 is accepted, and consequently, Transaction 2 is declared only after Transaction 3 has been accepted. This pattern is usual used when the production responsibility need to be assigned to other actor role, e.g., outsourcing. Figure 10 shows a Actor Role A -Initiator TK1

Request product -TK1

Accept product -TK1

Actor Role B

Executor TK1 Promise product -TK1

Declare product -TK1

Execute product -TK1

Request product -TK2

Accept product -TK2

Actor Role D -Executor TK3

Promise product -TK3

Execute product -TK3

Declare product -TK3

Actor Role C Initiator TK3

Executor TK2 Promise product -TK2

Declare product -TK2

Execute product -TK2

Accept product -TK3

Request product -TK3 multiple, and concurrent, invocation of transactions. After Transaction 1 had been promised, then Transaction 2 and Transaction 3 are requested. Conversely, Transaction 1 is only declared after the declaration of Transaction 2 and Transaction 3. In this example, it is noted that an actor is assigned with three roles, e.g., Actor Role B is Transaction 1 TE, Transaction 2 TI and Transaction 3 TI. In Figure 11 is depicted a pattern where the second transaction is started only after the execution of the first: the request after execution (RaE). This pattern is useful whenever a synchronous sequence between transactions is required. When asynchronous sequence is expected the pattern request after declare (RaD) could be used (cf. exemplified in Figure 12 ). Summarizing, DEMO Ψ-theory specifies the principles to assign semantic meaning to the structure and dynamic of business transactions, encompassing the actors, the communications, the productions and all its dependencies. On the contrary, BPMN does not prescribe any semantic for the business process model; it only provides a set of constructs that could be combined accordingly with a specification. The following core concerns were taken in consideration to map the DEMO complete pattern onto BPMN: (i) each actor role is autonomous, therefore, a BPMN pool per each one is required, (ii) all the communication acts between actors are fully specified considering the supporting gateways and events that are required, and (iii) the DEMO business transaction pattern is repeated recurrently where the patterns are key to integrate complex business transactions networks. From a practical perspective, the required inputs to semantify business processes are: 

This section applies the mapping of DEMO complete pattern onto BPMN models on two different networks of business processes and discusses the achieved results. Both proof-of-concepts (PoC) are based on documentation that reflects the discussion and understanding between the stakeholders referring to a) a process of payment approval and b) a process of budgetary change request. However, both are poorly documented in BPMN, containing syntax and semantic errors, and different assumptions exists between them. These models were implemented on a BPM engine with a specification far beyond from their initial specification, leaving an untraceable link between the process model and its implementation. This has an immediate impact on testing and acceptance of current process implementation, but also on future changes and/or adaptations. In this context, our proposal reveals many hidden or implicit steps in the original BPMN model, mitigating the gaps between the model and its implementation. A key issue in the the proof-of-concepts, relies on the fact that the process engine has a couple of pre-existing features that an actor can do on every task of the process instance: (i) cancel current task and redo previous task, and (ii) stop the process (abort). Such options are not in the original BPMN model, but are used in practice to support, e.g., decline decisions. Since they do not require any new code to be developed, because it is supported natively by the process engine (unless explicitly disabled), they are implicitly assumed. However, such implicit decline possibilities has an major impact on process model, testing, and overall present and future understanding.

The goal of this section is to show the usefulness of our proposal, measuring the coverage, both positive and negative, of the mapping of DEMO complete pattern onto the PoCs' BPMN models.

The following steps were applied to both PoCs.

1. Firstly, the available documentation from each PoC was reviewed. Each one has a requirement specification document resulting from the interactions with each customer (named as (doc.a)). In addition, a (doc.b) containing a simplified BPMN model designed from (doc.a) was reviewed.

2. Afterwards, (doc.c) that is a spreadsheet with business objects containing details about some BPMN tasks and further technological integration details was reviewed. Due to the introduction of unnecessary complexity for our paper, (doc.c) is not considered.

3. Then, the actor roles are identified, using (doc.a) and (doc.b). After that, the DEMO business transactions and correspondingly expected results are identified. For each transaction the actor role was classified as either initiator or executor. Then, the dependencies between transactions (namely RaP, RaD or RaE) are identified.

4. From previous step and using the proposal explained in Section 3, a semantified BPMN model is produced.

After that, a matrix identifying the explicit DEMO pattern coverage is produced as an outcome of the PoC. The (doc.b) specifies an incomplete "happy flow", therefore only a partial coverage is obtained in this step in both PoCs.

6. To enrich the previous matrix with the implicit DEMO pattern coverage, we used interviews with the BPM engine experts. Implicit corresponds to the transaction steps and communication acts that were not modeled, but, are assumed as existing during BPM engine implementation. This duality between explicit and implicit parts of a model has already been referred in the literature [19] [20].

The context of PoC 1 is collected from a public institution and consists in one business process with the goal of operating a budget transfer between business units. For that end, the SOC Department business unit solicits the budget transfer need, and then, a four-level validation chain is executed by the following sequence of business units: SPFP, SPFP Coordinator, Financial Department Director, and Governing Board Representative. Each business unit is represented as an actor role and are described in Table 1 .

When the SOC Department initiates the solicitation of a budget change, SPFP is the actor role responsible to execute this transaction (TK01). In the end of TK01, a new transaction result is expected in the world: the [budget] that has been changed. Meaning that the product kind budget has been changed accordingly with the initial solicitation. Since SPFP depends on the validation of the SPFP Coordinator, then TK02 is initiated. The expected result of this new transaction, provided by the SPFP Coordinator, corresponds to the [budget change] has been validated by second level. Afterwards, TK03 and TK04 are initiated sequentially by SPFP Coordinator and Financial Department Director, respectively. The execution' responsibility is assigned, correspondingly, to the actor roles of Financial Department Director and Governing Board Representative. The expected transaction results are the [budget change] has been validated by third level, and the [budget change] has been validated by fourth level. This set of transaction kinds are presented in Table 2 .

Then, Table 3 specifies the dependencies between business transaction. From (doc.a) and (doc.b) we obtained that TK02 is initiated by TK01 after its promise (RaP), and TK03 is initiated by TK02 after validation execution (RaE), and the same applies to TK04 that is initiated by TK03 after validation execution (RaE). Those dependencies defines how should the business transactions be connected in a chain to operate the desired business process.

This PoC' network of business transactions is then designed targeting the full usage of the DEMO complete pattern. However, few details exists explicitly in (doc.a) and (doc.b) specification, to design an informed semantified BPMN. The explicit definitions are represented in black color in Figure 13 , and as it could be noticed only the executions, validations, one archive, one initial request and one accept are depicted. Therefore, using the semantifying BPMN tool 8 , we enrich the PoC 1 model with the semantified BPMN pattern to fill the missing gaps. With this solution, a more complete model is depicted in the overall of Figure 13 . Yet, for presentation simplification, the declinations and rejections are exemplified, but the revocations are not.

The proof-of-concept 2 consists in the business process of payment authorization and execution. It is operated in the same public institution as introduced in PoC 1. 

Executor of the first validation and creator of a budget transfer proposal.

Executor of the second validation of the budget transfer.

Executor of the third validation of the budget transfer.

Executor of the fourth validation of the budget transfer. business unit is represented as an actor role and are described in Table 4 . The Financial Department Registrar starts by soliciting a payment authorization (TK01), which is executed by the Financial Department Expense Control, delivering the result: the [authorization] has been satisfied. To fulfill this result, the Financial Department Expense Control triggers TK02 with a dependency RaP (of TK01) and, later, will initiate TK06 with dependency RaE (of TK01). Financial Department Coordinator is the responsible for TK02 execution and the expected transaction result is that [payment requirement] has been validated. If this result is achieved, then TK03 is initiated with a RaE dependency. TK03 verifies the amount to be authorized. If it is below 5ke then it could be authorized, otherwise TK04 or TK05 will be initiated accordingly with the amount between >= 5ke and < 30ke, or >= 30ke. TK03, TK04 and TK05 are all related with the [payment] authorization result, but differ in the amount considered. When one of the TK03, TK04 or TK05 are completed, then the control is back to TK03 and afterwards to TK01 that initiates TK06 to reach the desired result of [payment] has been executed.

This set of transaction kinds are presented in Table 5 , and the dependencies between transactions are in Table 6 .

As explained in PoC 1, the PoC2 network of business transactions is designed using the explicit details available in (doc.a) and (doc.b) and represented in black color in Figure 14 . Again, only a small amount of elements are depicted. Enriching this model with the semantified BPMN pattern (including declinations and rejections) offered the representation of the orange elements in the same Figure. 

Both BPMN models (cf. Figures 13 and 14) were presented, and explained, to the BPM engine experts during one interview and by email. Then, the experts were asked to identify which acts are implemented, and which are not, within the BPM engine. In specific, we inquired if the semantifed BPMN complete pattern is implemented or if some parts could be considered as implicit. Otherwise, it was considered as not implemented. The result of this assesment is summarized in Tables 7 and 8 . They display a matrix with all transaction kinds related with all the possible production and communication acts. Black dots represent the acts that were explicitly modeled since the initial BPMN specified in (doc.b). In orange dots are the acts that were found implemented but not modeled, and an empty dot the acts that are neither implemented nor modeled.

Therefore, relating the produced semantified BPMN model with the two sources of (doc.b) and experts knowledge, allows the completeness asessment of the existing models and its correspondingly implementation. Moreover, it could be used to identify which parts of the model is not covered, and then generate it automatically and afterwards to establish an enrichment plan to the BPM engine.

Finally, it has been identified that the BPM engine implementation can only support revocations when the actor role owns the execution of the act itself. Therefore, we consider that this is too restricting to enforce the full revocation patterns, and thus, it is considered as not implemented. To summarize, in the context of this specific BPM engine, we pose the following two questions.

Autorization payment solicitator.

Executes the public administration payment requirements.

Validate the public administration payment requirements and solicits the payment authorization.

Payment authorization for amount < 5ke. A05 -Governing Board Representative Payment authorization for amount between >= 5ke and < 30ke. A06 -Governing Board Payment authorization for amount >= 30ke.

Executes previous checked and authorized payments. What are the communication and production acts that are explicitly modeled and at the same time implemented in the BPM engine?. Execution is the consensual act that is modeled and implemented. Also, an initial request, that triggers the business process, could be found in both PoCs and implemented. Then, depending in the PoC, an accept and a decline is found in the model and also explicitly implemented. Experts were queried about this and it was found that different teams of modelers and developers were involved in the projects, therefore different criteria was applied. This paper advocates that the usage of a semantified pattern can facilitate the normalization of criteria between projects involving different teams. The accept is a communication act that is considered only once in PoC2. Accordingly with the experts, this was a requirement not sought often by customers.

What coverage of the semantified BPMN pattern has been identified implicitly in the PoCs?. In terms of implicit acts many exists in the BPM engine (request, promise, Transaction kinds   Communication  and  Production  acts   TK01  TK02  TK03  TK04  TK05 declare, decline and reject) what could be considered as an oversimplification of the BPMN models that could bias the project' understanding and the communication with customers. For instance, since revocation are not implemented, they could be confused with the remaining implicit acts. Under the lens of a explicit business process model, it is not possible to distinguish between an implicit act or a not implemented act.

This section assesses the innovation of our proposal performing a systematic review of the knowledge available in the literature related to the topics of BPMN patterns and BPMN semantic. To that end, a search has been conducted using the Web of Science Core Collection (WOS), KCI-Korean Journal Database (KJD), Russian Science Citation Index (RSCI), Current Contents Connect (CCC), SciELO Citation Index (SCIELO), and MEDLINE ® databases, considering the following topic search: TS = ("BPMN AND (semantic OR pattern)"), until 2020 (included). Due to the large number of hits returned, the search has been filtered as depicted in Figure 15 : including only articles; excluding non-related categories and including only A-ranked CORE/ERA or Q1 scimago ranked journals. For easier reference, the full list of bibliographic references obtained with the search is presented in Table 10 and the distribution by year is presented in Table 9 . The quality of this retrieved TS is given by the total number of citations (excluding auto-citations) of 664, the average citations per item of 19.26 and the h-index of 10. After reading the papers' abstracts, one was excluded because it was out of the scope of our interest.

Year Records % of 34 Table 11 shows a list of applications that are understood from this set of related papers, and Table 12 presents a list of the modeling languages that are referred. We remark that BPMN 2.0 is broadly used what reinforces the importance of finding semantic pattern to be used by practitioners and industry. Petri nets are used often to formalize their proposals. The remaining modeling languages used are residual. Next, the papers are divided in two groups: semantic-and syntactic-based approaches.

An overview is depicted in Table 13 . Concerning ontologies, only two papers using UFO [52] and OWL [53] are directly related (cf. Table 14 ).

In [3] the authors state that the mix of constructs found in BPMN makes it possible to create models with semantic errors. Such errors could be propagated to the later phases of systems development which are referred among the most costly and hardest to correct. The paper proposes a mapping between a large subset of BPMN to petri nets to define a formal semantics. A tool has been developed and tested with 13 models available from BPMN Wikipedia and detected errors in 3 models. [43] proposes a data-flow verification scheme for business processes. To reduce the state-space of a model, a high-level representation based in the notion of relevance. Both [3] and [43] could be used to improve the correctness of user defined happy-path models.

Our approach does not provides a formal way to prevent errors, but do lead to a reduction of errors because users tend to focus on the happy path, which due to its simplicity yields fewer errors. The more complex handling of declinations and revocations are generated from the patterns and thus are error free.

The alignment between business processes and services layer is studied in [44] . A solution based on the semantic extraction of the BPMN elements is tested. We consider that this alignment could be better achieved if the BPMN models include the correct, and complete, semantics from business, as offered by our proposal. Moreover, semantic cannot be directly extracted from BPMN elements, but rather from a business definition as presented in section 4 of our paper.

Authors in [32] propose a solution to restructure the structure of a business process model using semantic infor-mation based on data from a social network, hierarchical clustering and graph optimization. Nonetheless the importance that AI solutions have today, our solution offers a more robust output since it fully describe how a network of business processes should be designed, even if some parts of it are, at a specific instant in time, considered as implicit. The outcome of this paper always depends on the quality delivered by the heuristic and on the set of rules defined. In the scope of process-aware information systems, [33] propose a set of patterns related with resources with an workflow management system. This approach is narrower than our which allows the application to all the context of a business transaction. [21] proposes the formalization of each model element using ontology to cope with misinterpretations. Authors state that this approach allows the model querying and its validation. This approach allows a broader application to models, but leaves the details open to the ontology definition. Therefore, it is less focused in the specific semantics of business processes dynamics when compared with our proposal.

[37] uses an enterprise' incident patterns to propose a querying solution based on business experts perspectives instead of a classical approach of ETL/data warehousing solution. Similarly with our proposal, we emphasize the need to find patterns to empower the knowledge from business directly to the business processes.

The work of [47] use ontological description and BPMN to capture the semantic modeling of requirements. However, the connection between both is not detailed.

To optimize the model' efficiency the proposal of [42] grounds on formalized domain knowledge and structured service wrapped with semantic annotation that is considered a BPMN enrichment.

Also corroborating the need to strengthen the knowledge of business processes and its importance, in [27] authors uses knowledge of business processes to optimize the event pattern matching used in BAM or SLAs platforms. Despite the different application it is worth noticing that giving meaning to business process allows a more precise (with less computational effort) operational monitoring. [24] state that business processes models and web engineering models are enough to support the semi-automatic semantic extractions and thus produce rich web applications. Nevertheless, models need to be complete and therefore our approach also applies in to improve their proposal.

In [8] authors distinguish between the normative desirable behaviour that is sometimes referred to as the "happy path" with the deviations from that happy path as exception handling. A set of exceptions patterns are proposed in the paper and its existence is evaluated. From the models considered, results suggest that the proposed exception handling patterns were instances of the patterns from the catalogue.

In addition, the authors of [40] that use BPMN to derive a common information model. We note that these approaches are only possible if the supporting BPMN models are semantically correct. Therefore, we see our work as an enabler to validate the semantic correctness.

The work in [29] uses process mining to retrieve legacy business processes using a static analysis of source code. The core idea is to preserve the business knowledge. This study corroborates the importance of the semantics of business, yet do not limit multiple interpretations of the same business processes.

[7] studies the problem of multiple interpretation between stakeholders in the specific context of remote collaborations. Here the problem is more complex and drives to mode coordination problems. This study corroborates our initial problem statement and reinforces it when remote environments are imposed, e.g., off-shore and near-shore development.

In [46] authors point to existing limitations in the communications between collaboration specifications on business process collaborations. To solve this problem, a data flow-error detecting based on a complete data model of all BPMN elements is required. Our proposal inherits the DEMO communication pattern avoiding modeling errors. [31, 30] introduce the concern of business rules along with business process design. The concept of Decisionaware Business Processes is used as a refinement of the concept of decision having the goal of optimizing the monitoring time of each decision.

Authors in [35] use description logic and automated reasoners to validate if the goals that are extracted from requirements are designed in the activities within business processes. Two inconsistencies are identified: orchestration and choreography. The solution is able to validate, but do not specify how to produce the models. Thomas & Fellmann [21] Gailly et al. [38] Mazzola et al. [42] Driss et al. [47] OWL [53] UFO [52] 

A summary of the syntactic-based contributions is summarized in Table 15 . Authors of [22, 23] defines a formal syntactic approach using process algebra CSP, and property specification language PL, applied to a subset of BPMN specification to ensure precise business specification and to assist developers in implementing the correct business processes. Yet, the formalism, and subsequent patterns, are done at the BPMN constructs levels, instead of our approach that considers the business transaction as the basic construct. In opposite, other authors extract semantic from BPMN models to produce artifacts, e.g., [41] propose a BPMN extension to model the context of wireless sensor networks. The goal is to facilitate the generation of source-code from the business models for this specific domain.

[26] studies the error patterns that are induced in industrial business processes obtained from syntactic analysis. Though the semantic has not been considered, it is showed by empirical evidences that an high percentage of errors exist implying a need to improve business process design.

Authors in [25] propose a new notation for BPMN alleging that BPMN notation is misunderstood by business stakeholders. And, that factor is considered as an impediment to the correct expressiveness of business processes semantic. Despite the fact that we agree with such claim, our approach do allow business stakeholders to understand BPMN models because they only need to design the happy path. Also, [34] extends BPMN with more notations to deal with ubiquitous computing technologies alleging that BPMN do not offer support for this domain. [49] is focused on the syntactic analysis of the process model to solve the open problem to define dead-pathelimination for cyclic workflows. This solution is directly applicable to workflow engines. Those recommended patterns in [49] could be beneficial to assess whether the business processes generated by our solution, in specific when a huge network of transactions exists, are syntactically correct in BPMN. [38] corroborates the different interpretations of a given business process that could be conflicting and propose a semantic repository to inter-operate models. However, the repository is based on the syntax of BPMN and not on the semantic of business process. This approach could be beneficial if applied to our semantic pattern to offer a recommendation between multiple business processes options.

The work of [39] applies the function-points analysis solution to BPMN business processes to evaluate them. The syntax of each business process is assessed directly by experimental studies. This is a different approach from ours, where we aim to automate the design of business process with a given semantic.

In [48] authors present a solution to control the time during the life-cycle of a BPMN activity, named as a durationaware model. This work assures time constraints which is absent in BPMN specification. The integration of time constraints with our proposal allows the fine-grained control of DEMO acts within the execution of complex networks of transactions.

Authors in [51] introduce the business processes patterns from the point view of resource and data with formalized description. In comparison with our proposal, the patterns are presented but its implementation is not further detailed.

The paper [50] refers that the semantics of BPMN control flow is enforced by user. Starting on this premise a syntactic analysis is performed to optimize the model' execution efficiency concerning the maximization of concurrency. In relation with our proposal, the DEMO patterns are used as the basis for a business process. Then, the specific activities that are performed in each transaction act may benefit from optimization.

The work in [28] propose an enrichment to BPMN choreography in a similar way with our proposal. However, only a request/response pattern is used and do not specify how to enforce in BPMN collaborations. Our proposal is more complete due to the DEMO complete theory that underlies the implementation.

Similarly with [31] , the paper in [36] studies the problem of decoding the decisions designed in a BPMN model. A set of patterns is proposed to capture the possible representations of data in a BPMN model.

In [45] is stated that literature appears to have few support for understanding the quantitative aspects in the business process design. Therefore, authors propose an executable specification of BPMN using a stochastic approach that analyses time and branching constructs. This approach could beneficial to analyze the results offered by our proposal.

This paper proposes a framework that maps the DEMO complete pattern onto BPMN oferring a semantified BPMN pattern to model business processes. The pattern encompasses the ability to express both the communication and the production acts, as well as, the ability to systematically prescribe revocations. Moreover, the pattern can be combined in a network offering the ability to design and implement within a controlled managed complexity environment.

The main contributions of this paper are (i) the increase in BPMN models completeness by adding patterns, with a reduced, and thus managed, increase in complexity. This has major impact on executable models maintenance, reuse and testing; (ii) the standardization of communications between pools using the Enterprise Ontology body of knowledge; (iii) the application to two proof-of-concepts; (iv) an extensive literature review to assess our work with the available knowledge in this domain; and (v) a tool to generate the mapping, whose besides model analysis, the BPMN file output could be used to execute BPMN processes in an engine.

From here, several endeavours for future work follows. Firstly, the propagation of revocations within a network of transactions. Secondly, develop the ability to produce views of the BPMN model produced. The idea is to filter complexity, e.g., allowing the definition of a view vector, for each transaction, specifying which acts or revocations are required. Thirdly, the development of a tool to generate the test cases that support the verification and validation of the BPMN model.

Fundamentals of business process management

Semantics and analysis of business process models in BPMN

An empirical investigation of intuitive understandability of process diagrams

Business process modeling languages: Sorting through the alphabet soup

ubpmn: A bpmn extension for modeling ubiquitous business processes

Design and evaluation of virtual environments mechanisms to support remote collaboration on complex process diagrams

Exception Handling Patterns for Process Modeling

Generating optimized configurable business process models in scenarios subject to uncertainty

Enterprise Ontology: A Human-Centric Approach to Understanding the Essence of Organisation

Business process model patterns: state-of-the-art, research classification and taxonomy

Construct redundancy in process modeling grammars: Improving the explanatory power of ontological analysis

Enterprise ontology: A Human-Centric Approach to Understanding the Essence of Organisation

What does demo do? a qualitative analysis about demo in practice: founders, modellers and beneficiaries

The theory of communicative action

A short comparison of business process modelling methods under the perspective of structure and behaviour

Modeling of business systems using som

Bridging the gap from a multi-view modelling method to the design of a multi-view modelling tool, Enterprise Modelling and Information Systems Architectures

Using business transactions to analyse the consistency of business process models

Ontology construction: Representing dietz "process" and "state" models using bpmn diagrams

Semantic Process Modeling -Design and Implementation of an Ontology-based Representation of Business Processes

Formalisations and applications of BPMN

Property specifications for workflow modelling

Model-driven design and development of semantic Web service applications

SBPMN -An easier business process modeling notation for business users

An Empirical Study of Error Patterns in Industrial Business Process Models

Optimizing Event Pattern Matching Using Business Process Models

Automating data exchange in process choreographies

A family of case studies on business process mining using MARBLE

A method for generation and design of business processes with business rules

Introducing decisionaware business processes

A methodology for the semantic and structural restructuring of BPMN models

Defining the resource perspective in the development of processesaware information systems

Toward uBPMN-Based Patterns for Modeling Ubiquitous Business Processes

Validation of user intentions in process orchestration and choreography

From BPMN process models to DMN decision models

Querying Workflow Logs

Recommendation-Based Conceptual Modeling and Ontology Evolution Framework (CMOE plus )

Business process point analysis: survey experiments, BUSI-NESS PROCESS

Khaparde, Business Process Model for Deriving CIM Profile: A Case Study for Indian Utility

Simplifying the Integration of Wireless Sensor Networks into Business Processes

Smart Process Optimization and Adaptive Execution with Semantic Services in Cloud Manufacturing

A practical data-flow verification scheme for business processes

Aligning Business Processes With the Services Layer Using a Semantic Approach

Stochastic analysis of BPMN with time in rewriting logic

Detecting Data Flow Errors Across Processes in Business Process Collaboration

Servicing Your Requirements: An FCA and RCA-Driven Approach for Semantic Web Services Composition

A modular approach to the specification and management of time duration constraints in BPMN

Dynamic skipping and blocking, dead path elimination for cyclic workflows, and a local semantics for inclusive gateways

Maximizing control flow concurrency in BPMN workflow models through syntactic means

Service Pattern: An Integrated Business Process Model for Modern Service Industry

Towards ontological foundations for conceptual modeling: The unified foundational ontology (ufo) story

The authors state that this work was supported by the European Commission program H2020 under the grant agreement 822404 (project QualiChain) and by national funds through Fundação para a Ciência e a Tecnologia (FCT) with reference UIDB/50021/2020 (INESC-ID).