# Risk-aware business process management using multi-view modeling: method and tool

Rafika Thabet, Dominik Bork, Amine Boufaied, Elyes Lamine, Ouajdi Korbaa, Hervé Pingaud

► To cite this version:

Rafika Thabet, Dominik Bork, Amine Boufaied, Elyes Lamine, Ouajdi Korbaa, et al. Risk-aware business process management using multi-view modeling: method and tool. Requirements Engineering, 2021, 26 (3), pp.371-397. 10.1007/s00766-021-00348-2. hal-03202277

HAL Id: hal-03202277

https://imt-mines-albi.hal.science/hal-03202277

Submitted on 19 Apr 2021

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# Risk-aware business process management using multi-view modeling: method and tool

Rafika Thabet<fnref n="1" />,<fnref n="2" /> ID · Dominik Bork<fnref n="3" />,<fnref n="4" /> ID · Amine Boufaied<fnref n="1" /> · Elyes Lamine<fnref n="5" />,<fnref n="6" /> · Ouajdi Korbaa<fnref n="1" /> · Hervé Pingaud<fnref n="2" />

Received: 25 March 2020 / Accepted: 20 January 2021

© The Author(s) 2021

## Abstract

Risk-aware Business Process Management (R-BPM) has been addressed in research since more than a decade. However, the integration of the two independent research streams is still ongoing with a lack of research focusing on the conceptual modeling perspective. Such an integration results in an increased meta-model complexity and a higher entry barrier for modelers in creating conceptual models and for addressees of the models in comprehending them. Multi-view modeling can reduce this complexity by providing multiple interdependent viewpoints that, all together, represent a complex system. Each viewpoint only covers those concepts that are necessary to separate the different concerns of stakeholders. However, adopting multi-view modeling discloses a number of challenges particularly related to managing consistency which is threatened by semantic and syntactic overlaps between the viewpoints. Moreover, usability and efficiency of multi-view modeling have never been systematically evaluated. This paper reports on the conceptualization, implementation, and empirical evaluation of e-BPRIM, a multi-view modeling extension of the Business Process-Risk Management-Integrated Method (BPRIM). The findings of our research contribute to theory by showing, that multi-view modeling outperforms diagram-oriented modeling by means of usability and efficiency of modeling, and quality of models. Moreover, the developed modeling tool is openly available, allowing its adoption and use in R-BPM practice. Eventually, the detailed presentation of the conceptualization serves as a blueprint for other researchers aiming to harness multi-view modeling.

**Keywords** Risk-aware business process management · Meta-modeling · Multi-view modeling · Consistency

## 1 Introduction and motivation

The integration of risks on business process level is a research topic that has been investigated by several research groups and has introduced many challenges for Risk-aware Business Process Management (R-BPM), which is considered a new management paradigm [37, 46, 69, 72]. Some

of the most fundamental challenges relate to the decision of introducing either a pure modeling approach or a pure management approach for R-BPM [56]. Most of the existing R-BPM approaches aim to extend the risk integration beyond the functional view in order to capture other process elements that can be affected by risks. This integration consequently results in very complex meta-models that require

<footnote>Rafika Thabet
rafika.thabet@inp-toulouse.fr</footnote>

<footnote>Dominik Bork
dominik.bork@tuwien.ac.at</footnote>

<footnote>Amine Boufaied
boufaied.amine@gmail.com</footnote>

<footnote>Elyes Lamine
elyes.lamine@univ-jfc.fr</footnote>

<footnote>Ouajdi Korbaa
ouajdi.Korbaa@centraliens-lille.org</footnote>

<footnote>Hervé Pingaud
herve.pingaud@univ-jfc.fr</footnote>

<footnote n="1">¹ ISITCom, MARS Research Lab, University of Sousse, Route G.P.1, 4011 Hammam Sousse, Tunisia</footnote>

<footnote n="2">² INP, CNRS, LGC, University of Toulouse, 31432 Toulouse Cedex 04, France</footnote>

<footnote n="3">³ Business Informatics Group, TU Wien, Vienna, Austria</footnote>

<footnote n="4">⁴ Faculty of Computer Science, University of Vienna, Vienna, Austria</footnote>

<footnote n="5">⁵ ISIS, Institut National Universitaire Champollion, University of Toulouse, Rue Firmin-Oulès, 81104 Castres, France</footnote>

<footnote n="6">⁶ Department of Industrial Engineering, IMT Mines Albi, Route de Teillet, 81013 Albi Cedex 9, France</footnote>
the simultaneous consideration of risk and business process aspects. Modeling these aspects is thus too of increasing complexity and the different stakeholders involved in R-BPM are likely overwhelmed.

Separation of concerns [23] in general and multi-view modeling in particular are well-established principles by means of which it is possible to tackle meta-model complexity. Multi-view modeling favorably partitions a meta-model into multiple viewpoints, each of which only focusing on individual aspects of the system under study. Consequently, the complexity of the meta-model can be reduced and individual stakeholders with their concerns can be supported by a tailored fraction of the overall meta-model (i.e., a viewpoint) when creating a model (i.e., a view). However, keeping these views consistent is inherently difficult because of the syntactic and semantic overlaps [7, 12, 18, 55, 57].

Indeed, multi-view modeling is a widely accepted methodology toward reducing complexity [7, 11, 18, 55]. By using a multi-view approach, multiple structural and behavioral aspects can be represented using different, interdependent viewpoints. In this context, it is interesting to note, that the majority of existing R-BPM approaches so far did not consider the way a modeler should interact with and navigate through multiple viewpoints and how consistency between these viewpoints is managed. This research gap establishes the motivation for our work.

To address this research gap, this paper introduces a multi-view modeling framework in which all risk and business process concepts are unified and kept consistent at all times. Instead of starting from scratch, we build our contribution on top of our previous works [46, 64–66, 72]. In these works, we introduced the Business Process-Risk management—Integrated Method (BPRIM). BPRIM follows a mere management approach focusing on how risk management should be considered during the business process management lifecycle. As most R-BPM approaches, also BPRIM originally considered the multiple viewpoints in isolation and did not consider consistency management.

The paper at hand describes the necessary fundamental extensions to BPRIM in order to conceptualize multi-view support: (1) taking a behavioral perspective on consistency management in multi-view R-BPM modeling, we define a multi-view modeling procedure for BPRIM; (2) using an established formalism, we formally specify the BPRIM modeling language in order to identify semantic viewpoint overlaps; and (3) using the open meta-modeling platform ADOxx, we implement a free modeling tool that features mechanisms & algorithms to manage consistency in multi-view e-BPRIM views. Together, these extensions form e-BPRIM, a multi-view modeling method for R-BPM.

For realizing e-BPRIM, our research follows the five core phases of the Agile Modeling Method Engineering (AMME) lifecycle [39] which are mapped to the generic

Design Science Research methodology [78]. In order to evaluate the quality of our contribution, we conducted case study experiments with two groups. One group used our new multi-view e-BPRIM tool whereas the other group, the control group, used a modeling tool that was identical instead of having no multi-view support at all. We will refer to this latter category as diagram-oriented modeling in the following. The evaluation shows, that multi-view modeling outperforms diagram-oriented modeling by means of usability and efficiency of modeling, and quality of models. Thus, this research establishes first theoretical contributions toward design guidelines for multi-view modeling methods and tools. Besides, the developed tool is publicly available, thereby contributing to open science in general [1] and the practice of R-BPM in particular.

This paper is structured as follows: Sect. 2 provides the necessary foundations. A survey of recent risk-aware business process management approaches is then presented in Sect. 3, pointing to inadequacies and research gaps that act as a motivation for our research. The core contribution of this paper is then presented in Sect. 4 where the e-BPRIM approach is discussed in detail following the Agile Modeling Method Engineering lifecycle. We report on an evaluation of e-BPRIM in Sect. 5 before we conclude with lessons learned and an outlook to future research directions in Sect. 6.

# 2 Foundations

## 2.1 The research domain of R-BPM

The main concerns of Business Process Management (BPM) is to analyze “how work is performed in an organization to ensure consistent outcomes and to take advantage of improvement opportunities.” [24, p. 1] Traditional BPM systems usually do not properly address the risks that organizations face in their day-to-day operations. Risk is part of every business activity and therefore part of every business process. If a risk occurs it may cause decreased quality, increased costs, time delays, complaints, and legal problems [15]. In the healthcare domain a risk can even cause serious and permanent damages up to death [5]. Such risks need to be managed by applying principles, frameworks, and activities, commonly known as Risk Management (RM).

The Risk-aware Business Process Management (R-BPM) paradigm has recently emerged, aiming to integrate the two traditionally separated fields of risk management and business process management [37, 69]. R-BPM promotes risks consideration in all stages of BPM and enables robust and efficient BPM within an uncertain environment. The importance of this integration has been confirmed in the research community [53], in industry guidelines [21], and in many studies [46, 69, 72]. Furthermore, this integration is

<figure><img src="image_2.png" /></figure>
a strategic objective of the European Network and Information Security Agency and the European Commission in ICT Trust and Security [74]. Nevertheless, research and practice of R-BPM is still limited and requires highly specialized knowledge in conceptual modeling methods, multi-view modeling, and consistency.

## 2.2 Conceptual modeling methods

Conceptual modeling reduces complexity of a certain domain by applying abstraction for a specific purpose. Conceptual models consequently only comprise those aspects of a domain that contribute value to a specific purpose. According to [40], a conceptual modeling method contains three building blocks: a modeling language, a modeling procedure, and mechanisms & algorithms. A modeling language can be further decomposed into its constituting parts, i.e., the syntax—the concepts provided by the language and the rules for combining them; the semantics—specifying the meaning of the language concepts; and notation—the graphical representation of each modeling language concept. At the heart of any conceptual modeling language is the syntax which determines the expressiveness and also the utility of the modeling language. Syntactic aspects are commonly specified using a meta-model [14]. The modeling procedure optionally defines the steps to be applied while creating valid models. These steps can be related to modeling actions in one model, or in a wider scope, to the sequence of creating and working with multiple models. Eventually, mechanisms & algorithms realize the automatable steps of the modeling procedure (e.g., model transformation) or provide means of processing the knowledge codified in the models (e.g., simulation).

## 2.3 Multi-view modeling

When the complexity of a system to be modelled exceeds a certain threshold, it is common to refer to multi-view modeling [12]. By doing so, the overarching model is decomposed into smaller models, representing views, that focus only on certain aspects while ignoring everything else. Each view has a corresponding modeling language, i.e., a viewpoint, which naturally only comprises a subset of the concepts necessary for the overarching model. "Multi-view modeling enables humans and machines to interact from multiple semantically or syntactically dependent perspectives with different views of a modeled artifact" [11, p. 94].

The standard ISO/IEC/IEEE 42010:2011 [35] differentiates between viewpoint and view as follows: "A view is governed by its viewpoint: the viewpoint establishes the conventions for constructing, interpreting and analyzing the view to address concerns framed by that viewpoint. Viewpoint conventions can include languages, notations, model kinds,

<figure><img src="image_3.png" /><figcaption>Fig. 1 Terminological foundations of view, viewpoint, model, and meta-model</figcaption></figure>

design rules, and/or modeling methods, analysis techniques and other operations on views" [35].

On this basis, Fig. 1 illustrates the terminological foundations this paper adheres to. We consider the viewpoint concept as a partitioning or restriction of concerns in a system. According to the Model-Driven Engineering (MDE) paradigm [67], it corresponds to a subset of the meta-model. The view concept is then the instantiation of a given viewpoint for a given case. The view is described by a model. Hence, a view and a viewpoint are always related to each other by means of an instantiation relationship. Similarly, each model is an instance of the language meta-model. A view is represented by a model whereas a viewpoint is represented by the subset of the language meta-model.

Multi-view modeling is not exclusively applied in the enterprise modeling [10, 26, 34] and enterprise architecture [35, 45] domains, but also in requirements engineering [79]. In the context of this paper, we employ integrated multi-view modeling by relating model-based risk management with model-based business process management. The aim of the multiple viewpoints is to reduce the complexity of the domain and to separate the different concerns of stakeholders involved in the different phases of the R-BPM lifecycle.

## 2.4 Multi-view consistency

As the different viewpoints in multi-view modeling represent the same system to be modeled, requirements for managing consistency amongst the views are inherent. Different kinds of viewpoint relationships can be differentiated. In the following, we will refer to the relationship classification proposed in [55]: **Orthogonal/Independent:** No direct semantic or syntactic relationships exist between two viewpoints. **Syntactic:** Two viewpoints share at least one syntactic concept whereas they also have mutually exclusive concepts. **Semantic:** Two viewpoints have a semantic relationship between each other, but this relationship is not based on a shared syntactic concept. **Refinement/Abstraction:** One viewpoint can be considered a more abstract and generalized representation of a different viewpoint. Thus, one viewpoint
<figure><img src="image_4.png" /><figcaption>**Fig. 2** Viewpoint relationships in multi-view models [55]</figcaption></figure>

further abstracts/refines the other. **Association:** Association viewpoints are used to connect two or more other viewpoints with each other.

Figure 2 shows the different viewpoint relationships.

Multi-view consistency has thus far only been considered on a static basis. However, consistency also needs to be considered on a dynamic basis. In [55], the dynamics of multi-view modeling is described by looking at different kinds of modeling operations that can be performed on views: **Composition:** A new view is created by combining the semantics of two or more other views. Specialized composition operations are: **Communication** and **Merging**. The former relates to heterogeneous views that are communicating with each other (e.g., a process view and an organization view), whereas the latter refers to the composition of homogeneous views that might reflect different states of the modeled system. **Projection:** A reduced view is derived by removing (i.e., filtering) syntactic concepts. **Extension:** The opposite of the projection operation, i.e., adding syntactic concepts to a given view. **Analysis:** This operation processes the information contained in a view in order to create an analysis view of the results. A special kind is the **diffing** operation which compares different versions of the same view. **Synthesis:** Synthesizes the information of several views.

## 3 Related works

As previously mentioned, R-BPM integrates risk aspects into business process management in order to increase the risk-awareness of an organization's business processes. An extensive general review of R-BPM approaches can be found in [37, 46, 69, 72].

In this work, we have established a set of specific criteria to guide the selection of relevant related works to be analyzed. As a consequence, a number of related works have been excluded. A brief explanation of the scope and the selection criteria of the search are detailed in Sect. 3.1. Those works that did meet our selection criteria were subsequently grouped and described in Sect. 3.2. Section 3.5 then provides an analysis of the selected works and points to gaps and inadequacies that motivate our research.

### 3.1 Search strategy

As a general rule, in this paper, we consider only R-BPM works. Therefore, works that focus only on risk management aspects and do not demonstrate strong links to business process management are excluded. Examples of risk-management-focused work, which we excluded, are the CORAS method [48], the Committee of Sponsoring Organizations of the Treadway Commission (COSO) Enterprise Risk Management framework [21] and many others (cf. e.g., [6, 16, 25]). Similarly, works that interpret business processes in an isolated sense are excluded. Examples of works in this category include [32, 49, 61].

The need for organizations to comply with legislative regulations has highlighted the need to address risks of regulatory noncompliance. Consequently, research in business process compliance increasingly has been linked to risk management. However, business process compliance is distinct from R-BPM: the former seeks to provide solutions to ensure the compliance of business processes to regulations, while the latter seeks to reason about the likelihood and the impacts of the occurrence of various types of risks, one of which is the risk of business processes violating some legislative regulations. Our search is concerned with the latter, and, thus, we have excluded many works in the core area of business process compliance.

Similarly, information security is another specific risk factor in BPM. In this respect, our search focuses on works that attempt to facilitate the reasoning about security risks in BPM, rather than those that attempt to provide solutions to security management problems. Thus, a large number of works concerning core security management were excluded, such as the Optimised Risk Analysis Method (MONARC) [51].

While all these works may seem relevant, they do not properly attempt to integrate and/or reason about risks in business process management.

In this paper, we concentrate our search on recent R-BPM approaches that concentrate on the *design-time* stage of the BPM life cycle (cf. [46]). Obviously, managing risks in business process starts by a convenient representation of risks and their characteristics in business process models. This representation allows for an understanding of the risk origins in business processes, their impact on these processes, and the control and mitigation strategies in place.

The design-time R-BPM approaches could also be classified into two categories with regard to the risk modeling consideration: (1) those that introduce new risk-related constructs in order to incorporate risk information into the business process model; and (2) those that attempt to reason risks using risk analysis techniques without the introduction of new constructs. In this work, we focus our search on the

<figure><img src="image_5.png" /></figure>
first category, as related approaches do not provide enough
support for design activities.

## 3.2 Analysis framework

In the following, we introduce an analysis framework which
will be used in Sects. 3.3 and 3.4 to analyze current single-
view and multiple-view design-time R-BPM approaches,
respectively. The framework comprises criteria that are
derived from the five core phases (i.e. *create*, *design*, *for-
malize*, *develop*, and *deploy*) of the Agile Modeling Method
Engineering (AMME) lifecycle [39] (AMME will be intro-
duced in detail in Sect. 4.1). The framework aims to elevate
the presentation of the related works toward a less subjec-
tive and more comprehensive level. The analysis framework
comprises the following criteria:

* *Requirements* whether requirements are specified;

* *Requirements format* which requirements specification
format is used;

* *Modeling Language* which modeling language is used to
represent risks and business processes;

* *Meta-Model* whether a meta-model is specified;

* *Modeling procedure* whether the steps for creating mod-
els are specified;

* *Proposed viewpoint(s)* the number of proposed view-
points;

* *Integration formalism* whether the approach uses a for-
malism to specify models and the relationships between
them;

* *Inter-dependencies types* whether inter-dependencies
between models or model elements are defined;

* *Tool support* whether a supporting tool is available.

The benefits of using this analysis framework are threefold.
First, it structures the presentation of related approaches
along a generic modeling method engineering framework
(i.e., AMME). Moreover, it eases the transition from the
comparative analysis of existing approaches (Sect. 3.5) to
the proposal of the multi-view BPRIM extension throughout
Sect. 4 which is also structured along the sequential flow of
the five core phases of AMME. Third, the framework clearly
shows need for conceptualizing multi-view support for our
previous works [46] which we contribute with this paper.

## 3.3 R-BPM approaches with one viewpoint

In [19, 20], a semi-formal extension of risk-related mod-
eling constructs to the Business Process Model and Notation
(BPMN) standard is proposed. The approach uses one view-
point, the extended BPMN. Similarly, in [50], one BPMN-
extended viewpoint for risk handling is proposed. In par-
ticular, identified risks are assigned to affected processes,

sub-processes, or activities by using an extended error event.
The standard BPMN language was furthermore extended
with the modeling construct of *risk factor*, characterizing a
potential risk in terms of type, likelihood, and impact on a
whole business process. Risk factors are assigned to BPMN
sequence flows.

In [3, 4], an extension of BPMN for the IS Security Risk
Management is proposed. The approach expresses assets,
risks, and risk treatment regarding asset confidentiality,
integrity, and availability in one BPMN-extended viewpoint.
Their proposal allows system analysts to design security
requirements to secure important assets.

In [47], an EPC-extended approach for analyzing business
process models using an adaptation of the HAZOP (HA-
Zard OP-erability) method is proposed. Similar to the three
previous approaches, HAZOP neither specifies any require-
ments, nor does it propose a modeling procedure or a sup-
porting modeling tool.

## 3.4 R-BPM approaches with multiple viewpoints

In [80], the Semantic Business Process Modeling Language (SBPML) for banks [8] is extended by a risk viewpoint for modeling and analyzing operational risks. The core constructs of this language are domain-specific process building blocks which connect and integrate a process viewpoint, a business object viewpoint, an organizational viewpoint, and a resource viewpoint. This approach is domain-specific and therefore limited in its applicability to other domains.

In [9], XMLNets, a variant of Petri Nets, are proposed
to model risk-related information in business process mod-
els. This work proposes a procedure comprising four steps:
modeling the original business process; assessing, param-
eterization, and linking of risks to the activities; simulation
of different process variants; and transformation of the most
satisfying process variant into an improved business process
model. A tool supporting the procedure is also proposed.

The Risk-Oriented Process Evaluation (ROPE)
approach [37, 38] proposes three viewpoints to capture risks
within business process models: A business process view-
point that consists of activities; a CARE viewpoint that is
derived by decomposing the activities into their correspond-
ing Condition, Action, Resource and Environment elements;
and a Threat Impact Process viewpoint that captures various
threats that may affect the corresponding CARE viewpoint
elements and the counter measure activities. A novel for-
mal description for modeling threats, detection, counter, and
recovery measures, their inter-dependencies, as well as the
impact on the attributes of affected resources is introduced
in [36, 73]. A simulation process was then described for
assessing the impact of threats on the process activities.
However, these works neither define a meta-model nor do
they specify any formalism or requirements. A tool has been partially implemented.

In [27, 56], the Semantic-based Modeling Framework for Information Systems (SemFIS) is proposed. The authors used semantic annotations for assigning risks from a frame ontology to a business process. The annotated models were processed via Java with JESS rules, enabling the execution of a capacity simulation to assess the impact of risks.

In [30, 68], RiskM, a modeling method for IT risks which is based on the Multi-Perspective Enterprise Modeling method (MEMO) [31], is proposed. RiskM allows to model processes, IT assets, strategies, and goals. The core RiskM modeling procedure comprises two steps. First, the IT-assets are modeled. Second, concrete risks are assigned to affected IT assets. In [30, 68], high-level requirements and key concepts of RiskM are defined which have been further enriched in [31], and prototypically implemented in [10].

In [62, 63], a performance measurement and management framework based on value and risk is proposed. The framework is organized in four phases, each of which is instrumented with different analysis methods. This work proposes four viewpoints: objectives viewpoint, activity viewpoint, risk viewpoint and risk-aware business process viewpoint. To express requirements, the authors propose a value-driven objectives viewpoint reflecting stakeholder expectations. Following the Value-Focused Thinking framework (VFT) [42], the latter provides a structured approach to elicit objectives from higher-levels stakeholder values. Moreover, mathematical theory is used to describe interdependencies between some viewpoint components. No tool support for the framework has been proposed, yet.

In [74, 75], the OPBUS (OPtimization of BUسiness process Security) framework for security-quality requirements in business processes management is proposed. OPBUS includes security issues from design to execution stage of the BPM lifecycle. The framework provides mechanisms for model-based diagnosis and constraint programming to carry out risk assessment and automatic conformance checks of security requirements. A tool supporting the OPBUS framework is proposed, it integrates: (i) a transformation engine that enables risk-extended business process models to be translated into Constraint Satisfaction Problem (CSP) models; (ii) support of various constraint solvers; and (iii) automatic conformance checks by means of CSP executions.

In [59], a risk-extended EPC modeling language is presented. This work depicts a meta-model to specify the modeling language. The proposed approach shows how R-BPM can be formalized on the atomic level of elementary e-EPC functions by extending the Value-Focused Process Engineering (VFPE) formalism [52]. Consequently, a formal specification of: (a) objects (such as goals, functions, events, etc.); (b) inter-dependencies between objects (including assignment and decomposition); (c) relationships between levels of

processes and risk objectives decomposition structures; and (d) guidelines for synchronized movement between levels of the process and risk objectives viewpoints is enabled. Requirements are not explicitly defined and neither a procedure nor a tool exist.

[46, 64–66] introduce and further develop the Business Process-Risk Integrated Method (BPRIM) comprising: a conceptual unification between the business process conceptual-model proposed by the ISO/DIS 19440 and a risk conceptual-model; a modeling language extending the ISO/DIS 19440 constructs with constructs for risk modeling; and a synchronized lifecycle that forms a procedure for integrated business process and risk management. The BPRIM lifecycle phases are supported by eleven viewpoints. A prototypical modeling tool is available [72]. However, this work does neither provide modeling requirements and formalization, nor a complete modeling procedure describing inter-dependencies between the proposed viewpoints.

## 3.5 Comparative analysis and solution overview

Table 1 provides a comparative analysis of the related approaches using the previously introduced criteria. Four out of 13 design-time R-BPM approaches integrate risk and business process concepts in a single viewpoint whereas the other nine approaches propose multiple viewpoints. Most of the latter approaches use two to four viewpoints whereas RiskM [68] with five and BPRIM with eleven viewpoints stand out. None of the analyzed approaches comprises a specification of modeling requirements, a pre-defined modeling procedure, and a formalized specification of viewpoints and their relationships. Only three approaches specify requirements at all, but only on an informal level using natural language (cf [13]). Six approaches have at least prototypical tool support whereas only three tools are freely available. Based on the previous comparative analysis, we identify the following research gaps e-BPRIM aims to address:

a. Only three approaches explicitly specify requirements.

We will address this shortcoming in Sect. 4.2 by formally specifying the requirements of our approach using an i* Strategic Dependency model.

b. Although nine approaches propose multiple viewpoints, these approaches did mostly not specify a modeling procedure and how consistency between these viewpoints is managed.

These shortcomings will be addressed in Sect. 4.3 by precisely specifying the multiple viewpoints, their corresponding modeling languages, and the procedure employed by modelers working with the multiple views. Moreover, Sect. 4.5 describes the implementation of the consistency mechanisms required for efficiently and simultaneously working with multiple views.

<figure><img src="image_6.png" /></figure>
<table><caption>**Table 1** Comparative overview of recent R-BPM approaches</caption><thead><tr><th rowspan="2">R-BPM Approaches</th><th colspan="2">Create</th><th rowspan="2">Modeling Language</th><th colspan="3">Design</th><th rowspan="2">Viewpoint(s)</th><th colspan="2">Formalize</th><th rowspan="2">Develop</th><th rowspan="2">Deploy</th></tr><tr><th>Requirements</th><th>Requirements format</th><th>Meta-Model</th><th>Modeling Procedure</th><th>Integration Formalism</th><th>Inter-dependencies types</th></tr></thead><tbody><tr><td>[4, 3]</td><td>☐</td><td>☐</td><td>Extended-BPMN</td><td>☑</td><td>○</td><td>One</td><td>☐</td><td>☐</td><td>☐</td><td>☐</td><td>☐</td></tr><tr><td>[9]</td><td>☐</td><td>☐</td><td>X nets</td><td>☐</td><td>●</td><td>Three</td><td>☑</td><td>Transformation</td><td>☑</td><td>☑</td><td>☐</td></tr><tr><td>[20, 19]</td><td>☐</td><td>☐</td><td>Extended-BPMN</td><td>☑</td><td>○</td><td>One</td><td>☐</td><td>☐</td><td>☐</td><td>☐</td><td>☐</td></tr><tr><td>[27, 56]</td><td>☐</td><td>☐</td><td>SWRL</td><td>☑</td><td>●</td><td>Four</td><td>☑</td><td>InterRefs Generation</td><td>☑</td><td>☑</td><td>☑</td></tr><tr><td>[38, 37, 36, 73]</td><td>☐</td><td>☐</td><td>ROPE</td><td>☐</td><td>●</td><td>Three</td><td>☐</td><td>Decomposition</td><td>☑</td><td>☑</td><td>☐</td></tr><tr><td>[47]</td><td>☐</td><td>☐</td><td>Extended-EPC</td><td>☐</td><td>○</td><td>One</td><td>☐</td><td>☐</td><td>☐</td><td>☐</td><td>☐</td></tr><tr><td>[50]</td><td>☐</td><td>☐</td><td>Extended-BPMN</td><td>☐</td><td>○</td><td>One</td><td>☐</td><td>☐</td><td>☐</td><td>☐</td><td>☐</td></tr><tr><td>[59]</td><td>☑</td><td>Text</td><td>Extended-EPC</td><td>☑</td><td>○</td><td>Two</td><td>☑</td><td>Assignment Decomposition</td><td>☐</td><td>☑</td><td>☑</td></tr><tr><td>[62, 63]</td><td>☐</td><td>☐</td><td>Extended-IDEF3</td><td>☐</td><td>●</td><td>Four</td><td>☑</td><td>Assignment Aggregation</td><td>☐</td><td>☑</td><td>☑</td></tr><tr><td>[65, 66, 64, 72, 46]</td><td>☐</td><td>☐</td><td>Extended-EPC</td><td>☑</td><td>●</td><td>Eleven</td><td>☐</td><td>☐</td><td>☑</td><td>☑</td><td>☑</td></tr><tr><td>[68, 30, 31, 10]</td><td>☑</td><td>Text</td><td>RiskML</td><td>☑</td><td>●</td><td>Five</td><td>☐</td><td>Assignment Decomposition</td><td>☑</td><td>☑</td><td>☑</td></tr><tr><td>[75, 74]</td><td>☑</td><td>Text</td><td>Extended-BPMN</td><td>☑</td><td>●</td><td>Two</td><td>☑</td><td>Transformation</td><td>☑</td><td>☑</td><td>☑</td></tr><tr><td>[80]</td><td>☐</td><td>☐</td><td>Extended-SBPML</td><td>☑</td><td>○</td><td>Four</td><td>☐</td><td>☐</td><td>☐</td><td>☑</td><td>☑</td></tr></tbody></table>

c Most approaches (8 out of 13) did not specify meta-models, viewpoints, and the relationships between viewpoints. Only few of them used formalisms and inter-dependency types for a precise specification.

We will address this shortcoming in Sect. 4.4 by formally specifying all viewpoint relationships.

The identified research gaps offer great potential to advance the R-BPM domain. Our contribution builds upon our previous works on BPRIM [46]. In previous research on BPRIM all eleven viewpoints were treated in isolation and no means of consistency management were in place. Considering this and the gaps identified in related works, the research at hand is guided by the following research objectives: (i) Defining an overarching modeling procedure that frames the multiple e-BPRIM viewpoints along the different R-BPM lifecycle phases and thereby guides the modeler during the modeling process, (ii) Formally specifying the e-BPRIM modeling language and multi-view relationships, and (iii)

Implementing a free multi-view modeling tool that features mechanisms & algorithms to manage consistency.

All these objectives adhere to the overall aim of realizing a multi-view R-BPM approach with high efficiency and usability. The following sections will report on how we addresses these objectives. Eventually, the evaluation will consider to which extend the Extended BPRIM approach fulfills the aim of efficiency and usability.

# 4 Meta-modeling for extended BPRIM

## 4.1 Research methodology

This research generally follows the design science research (DSR) methodology [78]. The artifact we are proposing as a result of the DSR project is the extended BPRIM modeling method and tool (e-BPRIM). In the following, we extend the DSR design phase [54] by the Agile Modeling
<figure><img src="image_7.png" /><figcaption>Fig. 3 Agile modeling method engineering lifecycle [39]</figcaption></figure>

Method Engineering (AMME) lifecycle [39]. AMME includes steps to be performed when conceptualizing a modeling method. The lifecycle comprises five core phases (see Fig. 3), each of which focusing on selected aspects of modeling method conceptualization:

1. *Create*: Concerns the specification of requirements of a modeling method → see Sect. 4.2.

2. *Design*: Design of a meta-model addressing the identified requirements → see Sect. 4.3.

3. *Formalize*: Formally specifying relevant parts of the modeling method → see Sect. 4.4.

4. *Develop*: Actual development of a corresponding modeling tool → see Sect. 4.5.

5. *Deploy*: Deployment of the modeling tool → see Sect. 4.5.

It needs to be noted again, that the following e-BPRIM presentation focuses exclusively on the multi-view modeling aspects. A comprehensive introduction to BPRIM is given in [46] where the requirements and rational for the meta-model and the viewpoints are elaborated in great detail. We therefore concentrate the presentation of all AMME phases on how they relate to the conceptualizing of multi-view modeling for BPRIM.

In a first step of our research, the e-BPRIM framework creation consists on the representation of the modeling requirements. Then, an integrated R-BPM meta-model is designed which describes the multiple viewpoints. The meta-model is represented using a UML class diagram by applying the meta-model slicing technique [14]. In the third step of our research, the formal specification of e-BPRIM meta-model and models is described. The e-BPRIM develop step aims to produce a supporting modeling tool. Eventually, the e-BPRIM deploy step concerns making the developed tool publicly available.

This research methodology enables smooth transitions from informal requirements through semi-formal and formal specifications toward the implementation of a modeling tool [39]. The next sub-sections will follow this step-by-step approach to consecutively and comprehensively

describe not only the resulting e-BPRIM artifact, but also
the process it derived from.

## 4.2 e-BPRIM creation

The first phase of the AMME lifecycle centers the elici-
tation of requirements for a modeling method. Thus, this
section elucidates the requirements for conceptualizing
multi-view modeling for the BPRIM modeling method. It
must be emphasized, that introducing multi-view modeling
to BPRIM not only affects the modeling language. In con-
trast, multi-view modeling thought until the end, also raises
requirements on the modeling procedure, the mechanisms
& algorithms, and the modeling tool of e-BPRIM. We thus
follow a top-down approach for requirements elicitation by
starting with the top-level requirements: *Define multi-view
modeling procedure*, *Specify multi-view modeling language*,
*Design multi-view modeling mechanisms & algorithm*, and
*Realize a multi-view modeling tool*. In a next step, a total of
11 high-level tasks were defined and categorized. Table 2
provides an overview of the e-BPRIM requirements and the
corresponding tasks.

The *Define multi-view modeling procedure* requirement (Rq1) comprises two tasks which are organized in a hierarchical manner. First, sequential and informational ordering of the modeling steps needs to be defined (Task 1.1). In this respect, the Task 1.2 needs to be conducted to identify viewpoints according to the BPRIM phases and steps. By considering the modeling procedure first, one naturally derives at a level of granularity that enables the identification and differentiation of relevant viewpoints.

The Rq2 *Specify multi-view modeling language* require-
ment comprises two tasks. First, the BPRIM modeling
language needs to be decomposed to derive the individual
viewpoint languages (Task 2.1). This decomposition is not
necessarily disjoint, i.e., it is very likely that modeling lan-
guage concepts become part of multiple viewpoints. Thus,
Task 2.2 is concerned with the specification of all overlaps
between meta-models of different viewpoints which are of
pivotal importance for the design and implementation of
consistency.

Rq3 aims at the design of mechanisms & algorithms
to model with multiple views. Task 3.1 is concerned with
the design of view-consistency mechanisms, i.e., concepts
and functionality that help the modeler to simultaneously
work with multiple views (cf. [12]). Another way of work-
ing with multiple views is by enabling navigation operators.
Therefore, Task 3.2 defines references between viewpoints.
Eventually, all modeling operations need to be aligned to the
individual viewpoints (Task 3.3).

Tool support is essential for the utilization and adoption
of e-BPRIM. Therefore, *Realize a Multi-view modeling tool*
requirement (Rq4) comprises four high-level tasks. First, all

<figure><img src="image_8.png" /></figure>
<table><caption>**Table 2** Overview of high-level e-BPRIM multi-view modeling requirements</caption><caption>e-BPRIM multi-view modeling approach</caption><tbody><tr><td>Rq1</td><td>Define multi-view modeling procedure</td><td>Task 1.1 Define sequential &amp; informational ordering<br/>Task 1.2 Identify viewpoints</td></tr><tr><td>Rq2</td><td>Specify multi-view modeling language</td><td>Task 2.1 Specify meta-models of viewpoints<br/>Task 2.2 Specify overlaps between meta-models</td></tr><tr><td>Rq3</td><td>Design multi-view modeling mechanisms &amp; algorithms</td><td>Task 3.1 Design view-consistency mechanisms<br/>Task 3.2 Define references between views<br/>Task 3.3 Define operations on views</td></tr><tr><td>Rq4</td><td>Realize a multi-view modeling tool</td><td>Task 4.1 Implement mechanisms &amp; algorithms<br/>Task 4.2 Implement semantic traceability<br/>Task 4.3 Implement flexible handling<br/>Task 4.4 Assure ease of usability, understandability &amp; learnability</td></tr></tbody></table>

<figure><img src="image_9.png" /><figcaption>**Fig. 4** e-BPRIM multi-view modeling requirements as simplified i* Strategic Dependency model</figcaption></figure>

mechanisms & algorithms for consistency management need to be implemented (Task 4.1). Task 4.2 concerns the implementation of semantic traceability across multiple viewpoints. Task 4.3 and Task 4.4 then consider non-functional aspects of the modeling tool by assuring flexibility, usability, understandability, and learnability.

Table 2 provides an overview of the e-BPRIM requirements and the corresponding tasks. We refer to existing techniques for graphical non-functional requirements specification in order to also specify task relationships. Several works have been proposed to model requirements

such as KAOS [22], MAPS [58], i* framework [83, 84], and the Non-Functional Requirements framework [17]. Due to its simplicity and wide adoption, we will refer in the following to the i* framework [84]. Figure 4 shows an i* Strategic Dependency model of the core e-BPRIM requirements. It can be derived, that *Task 2.1: Specify meta-models of viewpoints* is further decomposed into the *Task 1.2: Identify viewpoints* originating from Rq1 and *Task 2.2: Specify overlaps between meta-models* from Rq2. Explicating and formally specifying these and other
<figure><img src="image_10.png" /><figcaption>Fig. 5 e-BPRIM multi-view modeling procedure</figcaption></figure>

relationships helps deriving at a coherent and comprehensive modeling method specification.

## 4.3 e-BPRIM design

In the second phase of AMME, we concentrate on the design of the multi-view modeling language for e-BPRIM. We will first introduce the e-BPRIM modeling procedure (Sect. 4.3.1) and then derive the requirements for viewpoints, which need to be reflected in the e-BPRIM multi-view modeling language (Sect. 4.3.2). The latter will also consider the specification of viewpoint overlaps.

### 4.3.1 e-BPRIM modeling procedure

The original publication of BPRIM [46] proposes an integration of the two lifecycles of risk management and business process management. The BPRIM lifecycle identifies eleven viewpoints which should be managed in a common repository. Table 3 provides an overview of these viewpoints (Rq1 → Task 1.2). However, BPRIM did not specify in detail the temporal & informational ordering (Rq1 → Task 1.1) between viewpoints.

To fill this gap, we propose in Fig. 5 the e-BPRIM multi-view modeling procedure that illustrates the collaborative process supporting our integration approach with an emphasis on temporal ordering of the proposed viewpoints (Rq1 → Task 1.1). The upper viewpoints are related to the structure of information while the lower ones are more dedicated to business dynamics. The procedure structures viewpoints according to the BPRIM lifecycle phases “Contextualize”,

“Assess”, “Treat & Monitor”. We differentiate two modeling viewpoint relations: a *Precedence relation*, denoting that the second viewpoint contains output data from the first one; and an *Information relation*, denoting that two viewpoints share information. These multi-view relations inevitably lead to overlaps between viewpoint concepts.

The *Contextualize* phase starts with a “Discover” step leading to the definition of the value-added processes of the system under study by means of the “Process Landscape” viewpoint. Next, a model of the organization’s structure is defined in the “Design” step by means of the “Organization Chart” viewpoint which aims to identify roles and expectations, thereby establishing a greater understanding of the organizational environment. In addition, this definition serves to define the business process model by means of the “Business Process” viewpoint, then enabling the analysis of the context by means of the “Context” viewpoint.

The *Assess* phase starts with an “Identify” step that defines and classifies potential risks by means of the “Risk Taxonomy” viewpoint. The latter with the “Business Process” viewpoint assigns previously modeled risks to individual activities of the business process model, thereby identifying activities that are exposed to risks by means of the “Risk-extended Business Process” viewpoint. The “Analyze” step starts with an individual risks assessment by means of two viewpoints: “Risk Analysis” and “Risk”. The former depends on information specified in the “Risk-extended Business Process” viewpoint and the “Context” viewpoint. It includes: underlying risk causes and consequences, risk analysis by risk level calculation, and qualitative/quantitative risk evaluation. Then, critical activities can be identified in
<table><caption>**Table 3** Overview of e-BPRIM viewpoints</caption><thead><tr><th>e-BPRIM viewpoint</th><th>Aims</th><th>Object type</th><th>Relation type</th></tr></thead><tbody><tr><td>VP<sub>PL</sub> Process Landscape</td><td>Overview of the value-added processes of the system under study</td><td>Process</td><td>Composed of</td></tr><tr><td>VP<sub>OC</sub> Organizational Chart</td><td>Organizational structures of involved stakeholders in the process under study. Relationships between organizational units, roles and persons</td><td>Organizational Unit, Organizational Role, Operational Role, Person Profile</td><td>Composed of, Assigned to, Responsible for</td></tr><tr><td>VP<sub>C</sub> Context</td><td>Relationships between the Organizational Chart viewpoint and Values</td><td>Organizational Unit, Organizational Role, Operational Role, Person Profile, Value</td><td>Composed of, Assigned to, Responsible for, Interests</td></tr><tr><td>VP<sub>BP</sub> Business Process</td><td>Business process model describing a set of related and collaborative activities that produce a specific service or product. Organizational elements and data may be added. Provide a comprehensive understanding of the system and enable process improvement</td><td>Event, Activity, Process Interface, Resource, Product, Objective, Operational Role, Capability, Performance Indicator, Or Operator, And Operator, And Operator</td><td>Activates, Supports, Assigned to, Has input/out-put, Evaluated by</td></tr><tr><td>VP<sub>RTA</sub> Risk Taxonomy</td><td>Inventory of potential risks. Risks classification into categories according to various criteria. Semantic relationships between risks and risk classes. Description of static risk characteristics</td><td>Risk, Risk Class</td><td>Classified in, Aggregation, Generalisation</td></tr><tr><td>VP<sub>RA</sub> Risk Analysis</td><td>Risk causes and consequences scenarios. Risk impact on values and stakeholders</td><td>Risk Factor, Risk Situation, Risk Event, Stakeholder, Value, Or Operator, And Operator, And Operator</td><td>Influences, Causes, Impacts, Interests</td></tr><tr><td>VP<sub>R-BP</sub> Risk-extended Business Process</td><td>Assignment of individual activities of the Business Process to potential risks of the Risk Taxonomy. Identification of process activities which are exposed to risks. Identification of most critical process activities</td><td>Event, Activity, Process Interface, Resource, Product, Objective, Operational Role, Capability, Performance Indicator, Risk, Risk Factor, Risk Situation, Or Operator, And Operator, And Operator</td><td>Activates, Supports, Assigned to, Has input/out-put, Evaluated by, Influences, Affects, Leads to</td></tr><tr><td>VP<sub>R</sub> Risk</td><td>Characterization of a risk in its environment. Overview of all existing relationships between risk and other e-BPRIM viewpoints. Risk probability and severity definition</td><td>Activity, Risk, Risk Class, Risk Owner, Risk Indicator</td><td>Affects, Classified in, Responsible for, Evaluated by</td></tr><tr><td>VP<sub>RR</sub> Risks Relationship</td><td>Characterization of relationships between risks like aggregation and generalization</td><td>Risk</td><td>Aggregation, Generalisation</td></tr><tr><td>VP<sub>RM</sub> Risk Mapping</td><td>Two-dimensional risk matrix showing the criticality level of each analyzed risk</td><td>Risk</td><td></td></tr><tr><td>VP<sub>RTF</sub> Risk Treatment</td><td>Treatment scenarios for mitigation of high-level criticality risks regarding the Risk Mapping model</td><td>Activity, Risk, Risk Class, Risk Owner, Risk Indicator, Control</td><td>Affects, Classified in, Responsible for, Evaluated by, Treated by</td></tr></tbody></table>

<figure><img src="image_11.png" /></figure>
the "Risk-extended Business Process" viewpoint, according to risks level to which they are exposed. The "Risk" viewpoint is generated from information specified in the "Risk-extended Business Process" viewpoint and the "Risk Taxonomy" viewpoint. It describes an overview of all existing risk relationships in all viewpoint instances. The risk level is also defined according to information derived from the "Risk Analysis" viewpoint. Based on information flow from individual risks assessment results, risks relationships can be inferred by means of the "Risks Relationship" viewpoint. "Risk-extended Business Process", "Risk Analysis", and "Risk" viewpoints are required to capture the dynamic risks characteristics and generate the "Risks Mapping" viewpoint in the "Evaluate" step. This view is a two-dimensional risk matrix showing the risk level of each analyzed risk.

The *Treat & Monitor* phase aims to identify the most critical risks from the “Risks Mapping” viewpoint and to treat these risks by defining control mechanisms by means of the “Risk Treatment” viewpoint. Once control mechanisms are defined, process changes and improvements may be implied by means of the “Business Process” viewpoint, thereby closing one walk-through of the e-BPRIM multi-view modeling procedure.

### 4.3.2 e-BPRIM meta-model

Along the e-BPRIM modeling procedure, eleven interdependent viewpoints are identified. These viewpoints are described with a common modeling language of both risk and business process, the e-BPRIM modeling language. An integrated meta-model called e-BPRIM meta-model is at the core of a formal specification of the modeling language. It has been built using both literature analysis and experience feedback ($Rq2 \rightarrow$ Task 2.1).

The e-BPRIM meta-model extends the specification in Table 3 by means of the relationship cardinalities and the integration of the different viewpoint meta-models. Figure 6 visualizes the meta-models of eleven e-BPRIM viewpoints. From the figure can be derived, that some viewpoints have syntactic overlaps (e.g., “Value” which is part of the “Context” and the “Risk Analysis” viewpoints) while others have semantic overlaps that cross viewpoints (e.g., the relationship between “Stakeholder” in the “Risk Analysis” viewpoint and “Operational Role” in the “Organizational chart” viewpoint). These overlaps are referred to as “inter-model-references (INTERREFs in short)” in the following ($Rq2 \rightarrow$ Task 2.1 and Task 2.2). Each viewpoint comprises a subset of the e-BPRIM modeling language.

Identification and specification of viewpoint relationships are a prerequisite to the design and implementation of consistency mechanisms ($Rq3 \rightarrow$ Task 3.2 and Task 3.3). Therefore, in the following, we will specify the different e-BPRIM

viewpoint relationships in detail ($Rq2 \rightarrow$ Task 2.1 and Task 2.2) by applying the characterization introduced in [55]:

**Syntactic overlaps:** indicated as blue dotted arrows describe a relationship when a meta-model concept is represented in two different viewpoints by the same syntactic element. For e-BPRIM, we identified twelve syntactic overlaps ($R1$ to $R12$ in Fig. 6).

**Semantic overlaps:** indicated as purple dotted arrows. Semantic overlaps arise when a meta-model concept is represented in two different viewpoints by different syntactic elements but the semantics of the two concepts overlap. In e-BPRIM, we identified four semantic overlaps ($R13$ to $R16$ in Fig. 6).

**Refinement/Abstraction:** indicated as red dotted arrows describe a relationship between viewpoints where one viewpoint is a more abstract representation of the other. In e-BPRIM, we identified two such overlaps ($R17$ and $R18$ in Fig. 6).

**Association:** indicated as green dotted arrows describe a relationship where an association viewpoint is used to connect two or more base viewpoints. This relation either binds the viewpoints together, or constrains the shared semantics. For e-BPRIM we identified one association overlap ($R19$) as shown in Fig. 6.

Table 4 provides a detailed description of each e-BPRIM viewpoint relationship in Fig. 6. The description uses the notion of an overlapping concept 'OC' introduced in [7]. An OC refers to meta-model elements that form part of two or more different viewpoints by either a syntactic or a semantic overlap. For further information about the e-BPRIM viewpoint relationships, we propose in Fig. 7 one example of each kind of them.

### 4.3.3 e-BPRIM mechanisms and algorithms

According to [40], algorithms and mechanisms support the semi-automated steps of the modeling procedure. Moreover, they provide functionalities to use and evaluate views. Based on the defined viewpoint relationships and the e-BPRIM modeling procedure, until now, multi-view consistency has only been considered on a static basis. However, multi-view consistency also needs to be considered on a dynamic basis. To this end, in this section, we propose a new way to describe the dynamics of multi-view modeling by looking at different kinds of modeling operations that can be performed on views ($Rq3 \rightarrow$ Task 3.3). These operations emphasize the e-BPRIM mechanisms and algorithms. All of them are semantics-preserving ($Rq3 \rightarrow$ Task 3.1 and Task 3.2).

Figure 8 together with Table 5 provide a comprehensive overview of the main multi-view modeling consistency operations designed in e-BPRIM. The following description

<figure><img src="image_12.png" /></figure>
<figure><img src="image_13.png" /><figcaption>**Fig. 6** Overview of e-BPRIM multi-view modeling meta-model, highlighting the meta-model of each viewpoint</figcaption></figure>

extends the multi-view modeling operations as introduced in Sect. 2:

* Decomposition ($Op_1$): indicated as red dotted arrows refer to Refinement/Abstraction relationships in Fig. 6. Decomposition deals with breaking down a system into progressively smaller subsystems that are responsible

for some part of the problem domain. With this operation, a new view is considered as a more abstract representation of a given view. Thus, one view further abstracts the other.

* Extension ($Op_2$): indicated as blue dotted arrows refer to some syntactic overlap relationships in Fig. 6. With
<table><caption>**Table 4** Description of e-BPRIM viewpoint relationships by means of Overlapping Concepts</caption><thead><tr><th>Viewpoint relationships</th><th>Description</th></tr></thead><tbody><tr><td>Syntactic overlaps</td><td>R1 All VP<sub>OC</sub> concepts are part of the VP<sub>C</sub>. Then, all VP<sub>OC</sub> concepts form a syntactic OC between the VP<sub>OC</sub> and the VP<sub>C</sub><br>R2 'Operational Role' forms a syntactic OC between VP<sub>OC</sub>, VP<sub>C</sub> and VP<sub>BP</sub><br>R3 All VP<sub>BP</sub> concepts are part of VP<sub>R-BP</sub><br>R4 'Risk' forms a syntactic OC between VP<sub>R-BP</sub> and VP<sub>RTa</sub><br>R5 'Risk Factor' forms a syntactic OC between VP<sub>R-BP</sub> and VP<sub>RA</sub><br>R6 'Risk Situation' forms a syntactic OC between VP<sub>R-BP</sub> and VP<sub>RA</sub><br>R7 'Value' forms a syntactic OC between VP<sub>C</sub> and VP<sub>RA</sub><br>R8 'Risk' forms a syntactic OC between VP<sub>RR</sub> and VP<sub>RTa</sub><br>R9 'Activity' forms a syntactic OC between VP<sub>BP</sub>, VP<sub>R-BP</sub>, VP<sub>R</sub> and VP<sub>RTv</sub><br>R10 'Risk' forms a syntactic OC between VP<sub>R</sub>, VP<sub>RTv</sub> and VP<sub>RTa</sub><br>R11 'Risk Class' forms a syntactic OC between VP<sub>R</sub>, VP<sub>RTv</sub> and VP<sub>RTa</sub><br>R12 All VP<sub>R</sub> concepts are part of VP<sub>RTv</sub>. Then, all VP<sub>R</sub> concepts form a syntactic OC between VP<sub>R</sub> and VP<sub>RTv</sub></td></tr><tr><td>Semantic overlaps</td><td>R13 The 'Organizational Unit' concept of the VP<sub>OC</sub> and the VP<sub>C</sub> have semantic overlaps with the 'Stakeholder' concept of the VP<sub>RA</sub><br>R14 The 'Operational Role' concept of the VP<sub>OC</sub> and the VP<sub>C</sub> have semantic overlaps with the 'Stakeholder' concept of the VP<sub>RA</sub><br>R15 The 'Organizational Role' concept of the VP<sub>OC</sub> and the VP<sub>C</sub> have semantic overlaps with the 'Stakeholder' concept of the VP<sub>RA</sub><br>R16 'Risk' forms a semantic OC between VP<sub>RTa</sub> and VP<sub>RM</sub></td></tr><tr><td>Refinement /Abstraction</td><td>R17 VP<sub>PL</sub> provides an abstraction of the VP<sub>BP</sub>. The latter provides a more detailed description of each 'Process' concept of the VP<sub>PL</sub>. Then, the VP<sub>BP</sub> is a refinement of the 'Process' concept of the VP<sub>PL</sub>.<br>R18 VP<sub>RA</sub> provides a more detailed description of each 'Risk' concept of the VP<sub>RTa</sub>. Then, the VP<sub>RA</sub> is a refinement of the 'Risk' concept of the VP<sub>RTa</sub></td></tr><tr><td>Association</td><td>R19 VP<sub>RM</sub> forms an association viewpoint between VP<sub>R-BP</sub>, VP<sub>RA</sub>, VP<sub>R</sub>, and VP<sub>RTv</sub></td></tr></tbody></table>

this operation, a new view is created by extending an existing view with additional syntactic concepts.

*   **Reuse (Op<sub>3</sub>):** indicated as black dotted arrows refer to some syntactic and/or semantic overlap relationships in Fig. 6. With this operation, a new view is created by reusing one or several syntactic and/or semantic concepts from one or more existing views.

*   **Merging (Op<sub>4</sub>):** indicated as blue solid arrows refer to some syntactic overlap relationships in Fig. 6. With this operation, a new view is created by combining some syntactic concepts of two of more existing views. The provided view can also add new syntactic concepts specific to the viewpoint of the new created view.

*   **Synthesis (Op<sub>5</sub>):** indicated as green dotted arrows refer to Association relationships in Fig. 6. With this operation, a new view is created by gathering the information of several views and then generating a synthesis view. This operation can also integrate different kinds of sub-operations to gather the different knowledge amassed from other views and to structure them in a coherent whole.

*   **Synchronization (Op<sub>6</sub>):** not indicated in Fig. 8 because this operation keeps consistency between all views. This operation ensures the propagation of any modifications (i.e. create, edit or delete) performed on an overlapping concept

in one view to be propagated in semantically equivalent operations that need to be automatically performed on all other views. This operation refers to all relationships presented in Fig. 6.

## 4.4 e-BPRIM formalization

In this section, we introduce a formal specification for the meta-model and selected e-BPRIM multi-view modeling operations.

### 4.4.1 Formal specification of the e-BPRIM meta-model

To comprehensively and unambiguously specify the e-BPRIM meta-model, we introduce some assumptions inspired from the FDMM formalism (Formalism for Describing ADOxx Meta Models and Models) [28, 29].

Let VP be the set of viewpoints of a meta-model MM which can be expressed by:

$$VP = \{VP_1, VP_2, \dots, VP_N\} \qquad (1)$$

<figure><img src="image_14.png" /></figure>
<figure><img src="image_15.png" /><figcaption>Fig. 7 Example of some e-BPRIM viewpoint relationships</figcaption></figure>

Each viewpoint can be then specified by a set of objects and attributes which can be expressed by :

$$O^{VP} = \{O_1, O_2, \dots, O_M\} \qquad (2)$$

$$A^{VP} = \{A_1, A_2, \dots, A_P\} \qquad (3)$$

Based on the previous assumptions, the set of viewpoints of the e-BPRIM meta-model $MM_{e-BPRIM}$ can be then expressed by:

$$VP_{e-BPRIM} = \{VP_{PL}, VP_{OC}, VP_{C}, VP_{BP}, VP_{RTa}, \\ VP_{RA}, VP_{R-BP}, VP_{R}, VP_{RR}, VP_{RM}, VP_{RTf}\} \qquad (4)$$

As outlined in Sect. 4.3.2, e-BPRIM is composed of a large number of viewpoints that are all tightly interconnected. The formal specification presented in the following covers only certain aspects of e-BPRIM to show the expressive power of the formalism on the one hand while respecting the limited added value or showing the complete formal specification in
<figure><img src="image_16.png" /><figcaption>Fig. 8 Overview of the multi-view modeling operations between e-BPRIM views</figcaption></figure>

this paper. We selected four core viewpoints of the e-BPRIM meta-model: Business Process $VP_{BP}$, Risk Taxonomy $VP_{RT}$, Risk-extended Business Process $VP_{R-BP}$, and Risk $VP_{R}$.

The available objects and attributes of the Risk-extended BP viewpoint $VP_{R-BP}$ can be specified as shown in Equation 5 and Equation 6:

$$O_{R-BP}^{VP} = \{Activity, Resource, Product, Event, Risk, LogicalOperator, XOR, AND, OR, ProcessInterface, OperationalRole, PerformanceIndicator, Capability, Objective, RiskFactor, RiskSituation\} \quad (5)$$

$$A_{R-BP}^{VP} = \{Name, Id, Synch_List, Activity_Ref, Process_Interface_Ref, Risk_Ref\} \quad (6)$$

Similarly, the available objects and attributes of the Risk Taxonomy viewpoint $VP_{RT}$ can be then specified as shown in Equation 7 and Equation 8:

$$O_{RT}^{VP} = \{Risk, RiskClass\} \quad (7)$$

$$A_{RT}^{VP} = \{Name, Id, Synch_List, Risk_Ref\} \quad (8)$$

### 4.4.2 Formal specification of e-BPRIM operations

In the same way, we start with introducing some assumptions to present a formal description of selected modeling operations designed in e-BPRIM. As outlined previously, each viewpoint can be represented by views, then each view can be also specified by a set of objects:

$$O^V = \{O_1, O_2, \dots, O_K\} \quad (9)$$

Let $OI_i^V$ be the objects instances set of a view $V_i$ which can be expressed by:

$$OI_i^V = \{OI_1, OI_2, \dots, OI_L\} \quad (10)$$

Then, the instances set of a specific object $O_j$ in a specific view $V_i$ can then be expressed by:

$$I_i^V(O_j) = \{I_1, I_2, \dots, I_X\} \quad (11)$$

Based on these assumptions, we will constrain our focus by exemplifying the formal specification of selected e-BPRIM operations on views that play a central role in enabling consistency. We will show how these operations ensure consistency in the event of: i) generation of a “Risk-extended Business Process View” (Algorithm 1); ii) an attribute value change (Algorithm 2); and iii) an instance deletion (Algorithm 3).
<table><caption>**Table 5** Description of multi-view modeling operations designed in e-BPRIM</caption><thead><tr><th>V<sub>e-BPRIM</sub> Operation</th><th>Description</th><th>OC</th><th>Relationship</th></tr></thead><tbody><tr><td><strong>Decomposition</strong></td><td></td><td></td><td></td></tr><tr><td>V<sub>BP</sub> &larr; Op<sub>1</sub>(V<sub>PL</sub>)</td><td>V<sub>BP</sub> provides a more detailed description of the 'Process' concept of V<sub>PL</sub></td><td>Process</td><td>(R17)</td></tr><tr><td>V<sub>RA</sub> &larr; Op<sub>1</sub>(V<sub>RTa</sub>)</td><td>V<sub>RA</sub> provides a more detailed description of the 'Risk' concept of V<sub>RTa</sub></td><td>Risk</td><td>(R18)</td></tr><tr><td><strong>Extension</strong></td><td></td><td></td><td></td></tr><tr><td>V<sub>C</sub> &larr; Op<sub>2</sub>(V<sub>OC</sub>)</td><td>V<sub>C</sub> extends the existing V<sub>OC</sub> with the 'Value' concept</td><td>all V<sub>OC</sub> concepts</td><td>(R1)</td></tr><tr><td>V<sub>RT<sub>r</sub></sub> &larr; Op<sub>2</sub>(V<sub>R</sub>)</td><td>V<sub>RT<sub>r</sub></sub> extends the existing V<sub>R</sub> with the 'Control' concept</td><td>all V<sub>R</sub> concepts</td><td>(R12)</td></tr><tr><td><strong>Reuse</strong></td><td></td><td></td><td></td></tr><tr><td>V<sub>BP</sub> &larr; Op<sub>3</sub>(V<sub>OC</sub>)</td><td>V<sub>BP</sub> reuses the 'Operational role' concept from the existing V<sub>OC</sub></td><td>Operational Role</td><td>(R2)</td></tr><tr><td>V<sub>R-BP</sub> &larr; Op<sub>3</sub>(V<sub>BP</sub>, V<sub>RTa</sub>)</td><td>V<sub>R-BP</sub> reuses all concepts of V<sub>BP</sub> and the 'Risk' concept from the existing V<sub>RTa</sub></td><td>all V<sub>BP</sub> concepts and Risk</td><td>(R3,R4)</td></tr><tr><td>V<sub>RR</sub> &larr; Op<sub>3</sub>(V<sub>RTa</sub>)</td><td>V<sub>RR</sub> reuses the 'Risk' concept from the existing V<sub>RTa</sub></td><td>Risk</td><td>(R8)</td></tr><tr><td>V<sub>RA</sub> &larr; Op<sub>3</sub>(V<sub>R-BP</sub>, V<sub>C</sub>)</td><td>V<sub>RA</sub> reuses the concepts 'Risk factor' and 'Risk situation' from the existing V<sub>R-BP</sub> and the 'Value', 'Operational role', 'Organizational role' and 'Organizational unit' concepts from the existing V<sub>C</sub></td><td>Risk factor, Risk situation, Value, Stakeholder, Operational role, Organizational role and Organizational unit</td><td>(R5-R7) (R13-R15)</td></tr><tr><td><strong>Merging</strong></td><td></td><td></td><td></td></tr><tr><td>V<sub>R</sub> &larr; Op<sub>4</sub>(V<sub>RTa</sub>, V<sub>R-BP</sub>)</td><td>V<sub>R</sub> provides a merged view of the concepts 'Risk' and 'Risk class' from V<sub>RTa</sub> and the concepts 'Activity' and 'Risk' from V<sub>R-EPC</sub></td><td>Activity, Risk and Risk class</td><td>(R9-R11)</td></tr><tr><td><strong>Synthesis</strong></td><td></td><td></td><td></td></tr><tr><td>V<sub>RM</sub> &larr; Op<sub>5</sub>(V<sub>R-BP</sub>, V<sub>RA</sub>, V<sub>R</sub>, V<sub>RT<sub>r</sub></sub>)</td><td>V<sub>RM</sub> provides a synthesis view of the information about the 'Risk' concept provided by the V<sub>R-BP</sub>, V<sub>RA</sub>, VP<sub>R</sub> and V<sub>RT<sub>r</sub></sub>. For this end, the information about the 'Risk' concept are analyzed, evaluated and then mapped in a two-dimensional risk matrix. The synthesis view V<sub>RM</sub> shows then an overview of the criticality level of all risks</td><td>Risk</td><td>(R19)</td></tr><tr><td><strong>Synchronization</strong></td><td></td><td></td><td></td></tr><tr><td>V<sub>e-BPRIM</sub> &larr; Op<sub>6</sub>(V<sub>e-BPRIM</sub>)</td><td>All e-BPRIM views keep consistent after any modification (i.e. create, edit or delete) on any overlapping concept</td><td>all overlapping concepts in e-BPRIM</td><td>(R1-R19)</td></tr></tbody></table>
**Algorithm 1:** $V_{R-BP} \leftarrow Op_3(V_{BP}, V_{RTa})$
Automated generation of the $V_{R-BP}$ view

**Input**

$OI_{BP}^V$: objects instances set of the BP View $V_{BP}$

NOI: number of $V_{BP}$ objects instances

$I_{RTa}^V(O_{Risk})$: Risks objects instances set of the Risk

Taxonomy View $V_{RTa}$

NR: number of risks

**Output**

BP View extended to Risks $V_{R-BP}$

**Begin**

Create($V_{R-BP}$)

// Create new View of the Risk-extended BP viewpoint

Get($OI_{BP}^V$)

// Get all Business Process objects instances from the
BP View $V_{BP}$

**ForEach object in $OI_{BP}^V$**

$OI_{R-BP}^V \leftarrow OI_{BP}^V$

// Create a new instance in the Risk-extended BP View

$V_{R-BP}$

Copy($OI_{BP}^V, OI_{R-BP}^V$)

// Copy attribute values from instances in the $V_{BP}$ to
the representative instances in the $V_{R-BP}$ view

// Position the created instance in $V_{R-BP}$ using the
x/y coordinates of the object in $V_{BP}$

MapIdToSynchronizationList($OI_{BP}^V, OI_{R-BP}^V$)

// Add the instance id of the newly created instance
$OI_{R-BP}^V$ to the synchronization list attribute

**End ForEach**

Get($I_{RTa}^V(O_{Risk})$)

// Get all Risks objects instances from the Risk Taxonomy View $M_{RTa}$

**ForEach risk in $I_{RTa}^V(O_{Risk})$**

Assign($I_{R-BP}^V(O_{Activity}), I_{R-BP}^V(O_{Risk})$)

// Assign individual activities instances of the $V_{R-BP}$
to the risk and create the corresponding connectors in
the $V_{R-BP}$ model

**End ForEach**

**End**

**Algorithm 2:** $V_{e-BPRIM} \leftarrow Op_6(V_{e-BPRIM})$
After Edit Instance Value

**Input**

EditedInstanceId: Instance id that changed

NewInstanceValue: New instance value

SynchList: Synchronization list

**Output**

Instance value automatically synchronized in all affected
e-BPRIM views

**Begin**

**ForEach view in $V_{e-BPRIM}$**

SearchView(SynchList, EditedInstanceId)

// Search if the current view contains instances affected
by the value change

**IF instances found**

Propagate(NewInstanceValue)

// Update the value of instance to
EditedInstanceValue

**End IF**

**End ForEach**

**End**

Algorithm 1 represents the formal specification of the automated creation of the Risk-extended BP view $V_{R-BP}$ using the Reuse operation ($Op_3$). The algorithm first creates an empty R-BP view and then retrieves all objects of the corresponding BP view $V_{BP}$. Then, for each object in $V_{BP}$, a new instance of the same type in the $V_{R-BP}$ is created, attribute values are copied, and the element is initially positioned with the same x/y coordinates as the object in $V_{BP}$. Moreover, the id of the new instance is stored in a synchronization map that is used later to synchronize attribute value changes (see Algorithm 2). The algorithm then searches for all risks in the Risk view and assigns them in a final step to the corresponding objects in the R-BP view $V_{R-BP}$.

Algorithm 2 describes how consistency is ensured in the event of an attribute value change of an overlapping concept. More particularly, the algorithm shows, how changing the value of an instance in one view triggers change propagation in other affected e-BPRIM views. Starting from the view of the instance with the changed value is modeled in, the algorithm queries the synchronization list in order to identify affected instances in the other views and propagates the new value.

As modeling concepts are used in several views, see Fig. 6, the deletion of an instance in one view might jeopardize the overall consistency of the e-BPRIM views. To prevent such inconsistencies, the deletion needs to be handled appropriately. Algorithm 3 shows the algorithm to handle such scenarios.
**Algorithm 3:** $V_{e-BPRIM} \leftarrow Op_6(V_{e-BPRIM})$
Before Delete Instance

**Input**

*Deleted Instance Id*: Instance id that deleted

*Synch List*: Synchronization list

**Output**

Corresponding instances in affected e-BPRIM views automatically deleted

**Begin**

**ForEach view in** $V_{e-BPRIM}$

*Search View (Synch List, Deleted Instance Id)*

// Search if the current view contains instances affected by the deletion

**IF instances found**

*Delete Instance (Deleted Instance Id)*

// If instances found, delete it from the current view

*Update Synch List (tokdiff (Deleted Instance Id))*

// Remove the deleted instance id from the synchronization list

**End IF**

**End ForEach**

**End**

## 4.5 e-BPRIM development and deployment

The fourth phase of the AMME lifecycle focuses the development of a modeling tool. In the following, we will thus concentrate on the realization of a multi-view modeling tool for e-BPRIM, called ADOBPRIM. For this purpose, we utilize the meta-modeling platform ADOxx [2]. ADOxx provides an integrated development environment for developing graphical modeling tools. A comparative analysis of ADOxx and other meta-modeling platforms can be found in [46, 72, 77]. The decision to choose ADOxx was motivated as follows:

- ADOxx is a multi-user platform that provides a meta-model and model repository based on a relational database.

- ADOxx enables the definition of modeling languages, their graphical representations, and required mechanisms & algorithms without any advanced programming experience. For instance, ADOxx Library Language (ALL) serves the specification of classes, relationclasses and model types defining the meta-models of the modeling languages. The GRAPHREP language serves to define their graphical representation. The ATTRREP language serves the specification of the attribute visualization. Finally, the AdoScript language serves the implementation of mechanisms & algorithms working on the models.

- ADOxx supports the implementation of a multi-view modeling tool by providing features like automated model creation and algorithms for analysis, query, and transformation of models.

- In the past twenty years, tool support for more than 50 domain-specific modeling languages has been successfully realized with ADOxx both in academia (see [41] for an overview) and industrial projects.

To implement the e-BPRIM multi-view modeling tool, the e-BPRIM meta-model as shown in Fig. 6 was first transferred to corresponding ALL specifications and the graphical notations of the e-BPRIM concepts were implemented with the GRAPHREP language. The most challenging part was the realization of the operations between e-BPRIM views (shown in Fig. 8) as executable AdoScript algorithms.

As can be derived from Fig. 9, the Risk concept forms part of three e-BPRIM viewpoints: Risk-Extended BP, Risk, and Risk Taxonomy. Each of these viewpoints is realized as one model type in ADOxx. Depending on the e-BPRIM view the risk has been deleted from, different automatism have been implemented to ensure consistency. Generally, two cases need to be differentiated as shown in Algorithm 3. Either the Risk was deleted in the Risk Taxonomy view, or it has been deleted in the Risk view or the Risk-extended Business Process view. In the former case, all occurrences of the deleted risk need to be deleted in all other e-BPRIM views, and, if existing, a corresponding Risk view for the deleted Risk needs to be deleted. In the latter case, only the synchronization list needs to be updated by removing the instance id of the deleted risk, and, if existing, also a corresponding Risk view needs to be deleted.

A considerable amount of time during the development of the e-BPRIM tool was dedicated to the automated positioning of modeling objects that where created during the execution of multi-view operations. As such, Algorithm 1 in Sect. 4.4.2 exemplified the positioning of the new elements in the target view by copying the x/y coordinates of the corresponding objects in the source view. This copying approach is implemented for all *extension* and *reuse* e-BPRIM operations (see Table 5). In other scenarios, for example, the synthesis of the Risk Model, a meaningful initial positioning is proposed by using default horizontal and vertical offsets for all concepts. Although automated positioning might appear trivial or even unimportant, such functionality has a strong influence on efficiency and ease of use of the modeling tool.

The last phase of the AMME lifecycle focuses the deployment of a modeling tool. In the e-BPRIM case, the prototypical implementation will be transitioned from the
<figure><img src="image_17.png" /><figcaption>Fig. 9 Excerpt of the implemented e-BPRIM modeling language (syntax and notation)</figcaption></figure>

development environment into a stand-alone tool, which will be provided as an installation package through the OMiLAB<fnref n="1" />.

# 5 Evaluation

The following section comprehensively describes the evaluation of the e-BPRIM modeling tool. Section 5.1 first describes the different research questions and maps the corresponding evaluation experiments. The results of the evaluation are then presented in Sects. 5.2 and 5.3. Eventually, threats to validity will be discussed in Sect. 5.4.

It is important to stress that, consistent to the focus of this paper, which is on the conceptualization of multi-view modeling for BPRIM, the following evaluation also focuses on how multi-view modeling compares to diagram-oriented modeling based on aspects of usability, quality of models, and efficiency of modeling<fnref n="2" />. The results gained from this evaluation are primarily significant for BPRIM whereas they also establish a first theoretical contribution toward a generic comparison of the two different ways of working with multiple views.

<figure><img src="image_18.png" /></figure>

<footnote n="1">¹ e-BPRIM project space within OMiLAB [online]: https://austria.omilab.org/psm/content/BPRIM, last visited: 08.10.2020.</footnote>

<footnote n="2">² A comprehensive evaluation of the original BPRIM modeling method can be found in [46, 70, 71].</footnote>
# 5.1 Research questions

Overall, this paper aims to answer the research question *How to conceptualize multi-view modeling for e-BPRIM?* This question is further decomposed into the following three research questions, aiming to justify the use of the multi-view e-BPRIM modeling approach, to compare it with a diagram-oriented approach [12], and to argue about the quality of the created models and the efficiency of their creation. A dedicated evaluation technique has been used for testing each hypothesis. The evaluation is based on a comprehensive modeling case study which was conducted by two groups. One group, comprising 21 participants, used a diagram-oriented e-BPRIM tool without any multi-view modeling support. The second group, comprising 20 participants, used the multi-view e-BPRIM modeling tool as described in the previous sections.

**RQ1 Usability:** Is there a difference in the usability of multi-view modeling tools compared to diagram-oriented modeling tools? To respond to this research question, participants needed to solve a modeling case with the two e-BPRIM tools. Afterward, we used the standardized SUMI (Software Usability Measurement Inventory) questionnaire [43, 60] to compare the usability of both tools.

The hypothesis underlying this RQ is: *H-1: Modeling with the multi-view modeling e-BPRIM tool is perceived more useful compared to using a diagram-oriented one.*

**RQ2 Model Correctness:** Is there a difference in the quality of created models with a multi-view modeling tool compared to a diagram-oriented one? To evaluate whether participants utilizing the multi-view e-BPRIM tool produce models in better quality with respect to correctness, we validated the semantic consistency of the created case study models of both groups independently.

The hypothesis underlying this RQ is: *H-2: Models created with the multi-view e-BPRIM modeling tool have less semantic inconsistencies compared to using a diagram-oriented one.*

**RQ3 Modeling Efficiency:** Is the modeling process with a multi-view modeling tool more efficient compared to a diagram-oriented one? To respond to this research question we measured the time spent by the participants of both experiment groups to solve the exact same case study.

The hypothesis underlying this RQ is: *H-3: Modeling a complex system with the multi-view e-BPRIM modeling tool is more efficient compared to using a diagram-oriented one.*

## 5.1.1 Modeling case study

The Medication-Use Process (MUP) ensures medications are used and secured in the most appropriate manner in complex health care environments [76]. The MUP is a multidisciplinary process, involving numerous practitioners and is composed of several stages (i.e., prescribing, dispensing, administration and medication monitoring). Indeed, it may involve up to 46 activities from the moment a doctor considers prescribing medication to the moment when this medication is actually administered or taken by the patient.

The complexity of this process increases the likelihood and number of occurrences of Medication Error (ME) risks. These risks may occur during any stage of the MUP from prescription to medication administration and can be at the origin of Adverse Drug Event (ADE) with potentially severe clinical consequences for the patient [33]. Due to this complexity and the aim to design the case study in a way that it is complex enough to be expressive with respect to the multi-view aspects while being solvable in approximately 60 minutes, the case study focuses on the *Contextualize* and *Assess* lifecycle phases of e-BPRIM. Participants were asked to create a *Business Process View*, a *Risk Taxonomy View*, a *Risk-extended Business Process View*, and a *Risk View*.

The modeling case study centers the first stage of the MUP, the prescription of medication. The Prescribing stage is the action of a legitimate prescriber to issue a medication prescription/order which can be described as follows: The process begins when a patient comes to a health care system. A legitimate prescriber then performs an assessment that varies in comprehensiveness according to the circumstances and may include a review of the medical history, physical examination, and review of medications. Once a patient assessment is finished, a decision is made to initiate a new medication, change the current regimen, continue therapy as prescribed, and/or discontinue a medication. This decision represents a key transition point in the prescribing stage. Finally, the legitimate prescriber must write a medication prescription/order and an administration plan. The latter will be sent to the care unit and the medication prescription/order will be sent to the pharmacy and subsequently recorded in the patient's medical folder. Lack of knowledge of the prescribed medication, its recommended dose, and of the patient details exemplify only a few risks, the medication prescription process is exposed to [81]. Such risks include the dose, quantity, indication, and prescription of a contraindicated medication.

The modeling case study consists of the following steps (corresponding to an excerpt of the e-BPRIM modeling procedure in Fig. 5):

1. A $V_{BP}$ should be built that corresponds to the medication prescription process. It should describe operational
<figure><img src="image_19.png" /><figcaption>**Fig. 10** Sample Business Process View (a), Risk Taxonomy View (b), Risk-extended Business Process View (c), and Risk View (d) for the modeling case study in the e-BPRIM tool</figcaption></figure>

roles, required data, and a set of related and collaborative activities to prescribe a medication for a patient. A sample solution is provided in Fig. 10a by means of the $VP_{BP}$.

2. A $V_{RTa}$ should be built that provides an inventory and a classification of potential ME risks related to the

medication prescription process. A sample solution of a Medication Errors taxonomy is provided in Fig. 10b by means of the $VP_{RTa}$.

3. A $V_{R-BP}$ should be built that relates the risks introduced in the Risk Taxonomy view to the prescription process described in the Business Process. A sample solution of

<figure><img src="image_20.png" /></figure>
<table><caption>**Table 6** e-BPRIM evaluation results differentiated by type of modeling support</caption><thead><tr><th>Hypothesis and Metric</th><th>Multi-view e-BPRIM</th><th>Diagram-oriented e-BPRIM</th><th>Δ Multi-view v. Diagram-oriented</th></tr></thead><tbody><tr><td rowspan="6">H-1 SUMI (Median)</td><td>Global</td><td>58.5</td><td>41.00 +42.68%</td></tr><tr><td>Efficiency</td><td>58.0</td><td>43.00 +34.88%</td></tr><tr><td>Affect</td><td>62.5</td><td>42.00 +48.81%</td></tr><tr><td>Helpfulness</td><td>50.0</td><td>40.00 +25.00%</td></tr><tr><td>Controlability</td><td>56.5</td><td>49.00 +15.31%</td></tr><tr><td>Learnability</td><td>55.0</td><td>38.0 +44.74%</td></tr><tr><td rowspan="4">H-2 Number of errors</td><td>Average:</td><td>0.315</td><td>5.476 -94.23%</td></tr><tr><td>Max:</td><td>2</td><td>17 -88.23%</td></tr><tr><td>SD:</td><td>0.566</td><td>4.562</td></tr><tr><td>Average:</td><td>0.0</td><td>1.190 -100%</td></tr><tr><td rowspan="2">Number of semantic errors</td><td>Max:</td><td>0</td><td>4 -100%</td></tr><tr><td>SD:</td><td>0.0</td><td>1.258</td></tr><tr><td rowspan="3">H-3 Modeling time in minutes</td><td>Average:</td><td>35.13</td><td>47.57 -26.54%</td></tr><tr><td>Max:</td><td>45.00</td><td>75.00 -40%</td></tr><tr><td>SD:</td><td>6.351</td><td>6.757</td></tr></tbody></table>

a Prescribing process extended to Medication Errors is provided in Fig. 10c by means of the $VP_{R-BP}$.

4. A $V_R$ should be built that describes all relationships of a selected risk in all e-BPRIM views. A sample solution of the Overdosage ME risk is provided in Fig. 10d by means of the $VP_R$.

Figure 10 shows a sample solution to the case study. The solution shows all four models as screenshots of the developed e-BPRIM modeling tool and highlights the syntactic overlap relationships (indicated as blue dotted arrows) identified for the case study. For example, the *Improper Dose Risk Class* forms an OC between the Medication Errors Taxonomy view (b) and the Overdosage view (d). This OC refers to the (R11) syntactic overlap relationship identified in Fig. 6 and described in Table 4. Also, the *Overdosage Risk* forms both an OC between the Medication Errors Taxonomy view (b) and the Prescribing process extended to Medication Errors view (c), referring to the (R4) syntactic overlap relationship and an OC between the Medication Errors Taxonomy view (b) and the Overdosage view (d), referring to the (R10) syntactic overlap relationship.

## 5.2 Evaluation results

Table 6 summarizes the results of our comparison between the multi-view e-BPRIM tool and the diagram-oriented tool. Results show, that the former significantly outperforms the latter in all three evaluation criteria.

With respect to H-1, we can state, that the usability of the multi-view e-BPRIM tool is 42.68% higher in total and

also higher in all five usability subscales of the SUMI questionnaire (see [60, p. 190f.]). Interestingly, the biggest differences are in the subscale *Affect* and *Learnability*. Affect evaluates whether the *general emotional reaction* [60, p. 190] to the e-BPRIM tools whereas *Learnability* evaluates the *speed and facility with which users feel they mastered the system or learned to use new features* [60, p. 190]. The smallest gap, but still a gain of 15.31%, is for the subscale of *Controlability* indicating that participants for both tools felt that they are in control of the software. This is an important aspect, as the multi-view support automates several manual tasks and one could suggest that as a result, inexperienced participants would feel not in control compared to conventional diagram-oriented modeling where every action is triggered by the modeler.

Based on these evaluation results, we can confirm H-1— the multi-view e-BPRIM tool has a higher usability compared to a diagram-oriented e-BPRIM tool. Following the evaluation schema of SUMI, the multi-view e-BPRIM tool is generally performing very well, i.e., significantly above the threshold of 50 in each scale<fnref n="3" /> Thus, even this first prototype of the multi-view e-BPRIM tool is evaluated very positive.

With respect to H-2, the correctness of the models, the authors analyzed the created case study models of each participant individually and compared the results. Two different categories of errors have been differentiated: *modeling errors*, and *semantic errors*. A modeling error is given when a wrong relation type is used or when the direction of a

<footnote n="3">³ SUMI scales range from 10.0 to 73.0. The threshold of 50 is derived by evaluating 150 systems with over 1100 participants [43].</footnote>
relation is wrong. A semantic error on the other hand only concerns the semantics encoded in an e-BPRIM model. Semantic errors are given when two overlapping concepts have different names in different models, or when the R-BP model does not contain all aspects of the underlying business process model it is supposed to extend.

Models created with the multi-view e-BPRIM tool have on average only 0.315 modeling errors compared to 5.476 for the diagram-oriented e-BPRIM tool (a decrease of 94.23%). What concerns the semantic errors, the models created with the multi-view e-BPRIM tool have zero errors, whereas models created with the other tool have on average 1.19 semantic errors. In total, 61.90% of the case study solutions created with the diagram-oriented e-BPRIM tool had semantic errors—a serious deficit with respect to practical readiness of the tool and a limitation regarding the value of the models. The fact, that the multi-view e-BPRIM tool has zero semantic errors shows, that the implemented multi-view support mechanisms & algorithms work correctly.

Based on the evaluation results, we can confirm H-2—the multi-view e-BPRIM tool creates semantically correct models and significantly decreases the number of modeling errors compared to a diagram-oriented modeling approach.

With respect to H-3, the efficiency of modeling, we tracked the time required by the participants to solve the modeling case study with the two tool versions. Looking at the data, we can conclude, that the average modeling time using the multi-view e-BPRIM tool was 35 minutes and 13 seconds whereas participants using the diagram-oriented e-BPRIM tool took in average almost 48 minutes.

Based on the evaluation results, we can confirm H-3—the multi-view modeling decreases the time required for modeling by 26.54% compared to diagram-oriented modeling. This is even more interesting as we recognized that most of the participants using the diagram-oriented tool copy & pasted some of the overlapping concepts.

## 5.3 Qualitative feedback

After the participants finished the case study and concluded the SUMI questionnaire, they were also able to provide some feedback on aspects they liked and disliked the most. Interestingly, more than one fourth (28.57%) of the participants using the diagram-oriented e-BPRIM tool disliked the usability of the provided tool and stressed some linkage between the models or some means of synchronization would be meaningful.

25% of the participants using the multi-view e-BPRIM tool explicitly mentioned the synchronization between the models and the modeling support, e.g., in automated R-BP generation as the things they liked the most. Potentials for further improvement were also provided, e.g., a proper documentation, more informative pop-up messages during the

modeling process, and with the most mentions, 20% stressed they would have liked more modeling languages integrated into the e-BPRIM tool.

## 5.4 Threats to validity

Aside from the multi-view modeling support both tools were identical with respect to the underlying meta-model, the look & feel of the platform, the user interaction etc. Also, the modeling case study and all other parameters potentially threatening the validity of the results were controlled to ensure an identical setup. This research is of course still not free from threats to validity. In the following, we will discuss how we addressed the four generic threats to validity in empirical software engineering research [82].

> "Threats to construct validity refer to the extent to which the experiment setting actually reflects the construct under study." [82, p. 103f.] In order to address this threat, we decided not to design a questionnaire but instead use the standardized and well established SUMI questionnaire for the usability evaluation. The other constructs, i.e., the time as a measurement for efficiency and the number of modeled errors for model correctness are well documented in the literature (cf. [44]) and widely adopted.

> "Factors that impact on the internal validity are how the subjects are selected and divided into different classes, how the subjects are treated and compensated during the experiment, if special events occur during the experiment etc" [82, p. 102] In our experiments, we mostly relied on students (bachelor, master, and PhD) at the institutions the first author is affiliated to. All participants had at least some prior knowledge in process modeling and received a proper introduction to Risk-aware Business Process Management (R-BPM) as well as to e-BPRIM as a methodology. Participation was voluntary and no compensation was provided. Moreover, we used different groups to test the two e-BPRIM tools independently and assigned the participants to the groups randomly. As a last threat to internal validity, we also made sure that the participants of both groups were not aware of the core evaluation focus, i.e., comparing multi-view modeling from diagram-oriented modeling. To omit some language barriers, we provided the SUMI questionnaire in the mother tongue of the participants.

> **External validity** concerns "the ability to generalize experiment results outside the experiment setting." [82, p. 104] In our case, the gained results are based on R-BPM as a domain and e-BPRIM as one concrete method. However, we are confident that some of the evaluation results can be generalized to a level of comparing different types of modeling support—independent from any modeling method. We present the first research, to the best of our knowledge, that empirically evaluates the influence of the type of modeling, i.e., multi-view vs. diagram-oriented modeling, on usability,

<figure><img src="image_21.png" /></figure>
efficiency, and quality of models. Consequently, we believe
our results indicate that multi-view modeling is a very prom-
ising approach toward handling complexity in modeling and
can be applied to other domains, such as requirements engi-
neering and enterprise architecture management, as well.

One threat to the **reliability** of the results is the limited
sample size. We perceive this evaluation as a milestone con-
cluding the first design cycle. Motivated by the positive feed-
back gained, we will continue equipping further e-BPRIM
model views with multi-view support in future design cycles
and also involve more participants in the evaluation.

6 Conclusions

Being one of the fundamental aspects of the R-BPM domain, the integration of risk and business process concepts in models requires a very complex meta-model comprising many concepts to be considered simultaneously. Modeling these aspects is of increasing complexity due to diversity of risk and business process aspects and the different concerns of involved stakeholders. By reverting to multi-view modeling, this complexity can be reduced.

In this paper, we conceptualized a multi-view modeling R-BPM framework based on the BPRIM method, called e-BPRIM. Following the Agile Modeling Method Engineering lifecycle, we reported on the requirements, the design, the formalization, and the development and deployment of a new multi-view modeling method and tool for e-BPRIM. An extensive evaluation was then conducted to assess the quality of our contribution by comparing the multi-view e-BPRIM tool with a diagram-oriented one.

This research theoretically contributes first empirical
insights that indicate, that multi-view modeling could out-
perform diagram-oriented modeling in specific contexts.
Concretely, we show that the e-BPRIM tool outperforms
the diagram-oriented version by means of the efficiency of
modeling, the quality of the created models, and the per-
ceived usability.

We are currently in talks with our practice partners in the
health care sector that also evaluated the previous BPRIM
method and tool [46, 70, 71] in order to involve them in
a comprehensive practical effectiveness evaluation of
e-BPRIM. Furthermore, we aim to generalize the theoretical
contribution toward design guidelines for multi-view mod-
eling methods. The practical contribution of this research
is the developed AdoBPRIM modeling tool which is made
openly available to R-BPM practitioners.

**Acknowledgements** The authors would like to show their gratitude to the Ecole d'ingénieurs d'Informatique et de Sytèmes d'Information pour la Santé (ISIS) de Castres, which is an Engineering Departement of the Institut National Universitaire Champollion, who participated to evaluate the two version of our AdoBPRIM tool. We would also like to

thank OMiLAB members for assistance with the ADOxx platform and
for providing a collaborative space on their OMiLAB portal.

**Funding** Open access funding provided by TU Wien (TUW).

**Open Access** This article is licensed under a Creative Commons Attribution 4.0 International License, which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons licence, and indicate if changes were made. The images or other third party material in this article are included in the article's Creative Commons licence, unless indicated otherwise in a credit line to the material. If material is not included in the article's Creative Commons licence and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder. To view a copy of this licence, visit http://creativecommons.org/licenses/by/4.0/.

References

1. Aalst W, Bichler M, Heinzl A (2016) Open research in business and information systems engineering. Bus Inf Syst Eng: Int J WIRTSCHAFTSINFORMATIK 58(6):375–379

2. ADOxx.org (2020) Official homepage of the ADOxx meta-mod-
eling platform. http://adoxx.org, last visited: 28.01.2020

3. Altuhhov O, Matulevičius R, Ahmed N (2013) An extension of business process model and notation for security risk management. Int J Inf Syst Model Des 4(4):93–113

4. Altuhhova O, Matulevičius R, Ahmed N (2012) Towards definition of secure business processes. In: International conference on advanced information systems engineering, pp 1–15. Springer

5. Amantea IA, Di Leva A, Sulis E (2018) A simulation-driven approach in risk-aware business process management: a case study in healthcare. In: SIMULTECH, pp 98–105

6. Asnar Y, Giorgini P, Mylopoulos J (2011) Goal-driven risk assessment in requirements engineering. Requir Eng 16(2):101–116

7. Awadid A, Bork D, Karagiannis D, Nurcan S (2018) Toward generic consistency patterns in multi-view enterprise modelling. In: Twenty-Sixth European Conference on Information Systems (ECIS’2018), Portsmouth, UK

8. Becker J, Thome I, Weiß B, Winkelmann A (2010) Constructing a semantic business process modelling language for the banking sector-an evolutionary dyadic design science approach. Enterp Model Inf Syst Architect 5(1):4–25

9. Betz S, Hickl S, Oberweis A (2011) Risk-aware business pro-
cess modeling and simulation using xml nets. In: Commerce and
enterprise computing (cec), 2011 IEEE 13th conference on, pp.
349–356. IEEE

10. Bock A, Frank U (2016) Multi-perspective enterprise mod-
eling—conceptual foundation and implementation with adoxx.
In: Domain-specific conceptual modeling, pp 241–267. Springer

11. Bork D (2015) A development method for the conceptual design of multi-view modeling tools with an emphasis on consistency requirements. Ph.D. thesis, University of Bamberg

12. Bork D, Karagiannis D, Pittl B (2020) A survey of modeling language specification techniques. Inf Syst 87:101425

13. Bork D, Buchmann R, Karagiannis D (2015) Preserving multi-view consistency in diagrammatic knowledge representation. In: International conference on knowledge science, engineering and management, pp 177–182. Springer
14. Bork D, Fill HG (2014) Formal aspects of enterprise modeling methods: a comparison framework. In: 2014 47th Hawaii international conference on system sciences, pp 3400–3409. IEEE

15. Boufaied A, Thabet R, Korbaa O (2016) Dynamic delay risk assessing using cost-based fmea for transportation systems. In: 2016 IEEE international conference on systems, man, and cybernetics (SMC), pp 001057–001062. IEEE

16. Cailliau A, van Lamsweerde A (2013) Assessing requirements-related risks through probabilistic goals and obstacles. Requir Eng 18(2):129–146

17. Chung L, Nixon BA, Yu E, Mylopoulos J (2012) Non-functional requirements in software engineering, vol 5. Springer, Berlin

18. Cicchetti A, Ciccozzi F, Pierantonio A (2019) Multi-view approaches for software and system modelling: a systematic literature review. Softw Syst Model 18(6):3207–3233

19. Cope EW, Deleris LA, Etzweiler D, Koehler J, Kuester JM, Ray BK (2014) System and method for creating and expressing risk-extended business process models. US Patent 8,862,491

20. Cope EW, Kuster J, Etzweiler D, Deleris LA, Ray B (2010) Incorporating risk into business process models. IBM J Res Dev 54(3):4–1

21. Coso I (2004) Enterprise risk management-integrated framework. Committee of Sponsoring Organizations of the Treadway Commission 2

22. da Silva AR (2015) Model-driven engineering: a survey supported by the unified conceptual model. Comput Lang Syst Struct 43:139–155. https://doi.org/10.1016/j.cl.2015.06.001

23. Dardenne A, Van Lamsweerde A, Fickas S (1993) Goal-directed requirements acquisition. Sci Comput Program 20(1–2):3–50

24. Dijkstra EW (1982) On the role of scientific thought. In: Selected writings on computing: a personal perspective, pp. 60–66. Springer

25. Dumas M, La Rosa M, Mendling J, Reijers HA (2018) Fundamentals of business process management. Springer, Berlin. https://doi.org/10.1007/978-3-662-56509-4

26. Feather MS, Cornford SL (2003) Quantitative risk-based requirements reasoning. Requir Eng 8(4):248–265

27. Ferstl OK, Sinz EJ, Bork D (2016) Tool support for the semantic object model. In: Karagiannis D, Mayr HC, Mylopoulos J (eds) Domain-specific conceptual modeling, concepts, methods and tools, pp 291–310. Springer, Berlin

28. Fill HG (2012) An approach for analyzing the effects of risks on business processes using semantic annotations. In: ECIS 2012 Proceedings. ESADE/AIS

29. Fill HG, Hickl S, Karagiannis D, Oberweis A, Schoknecht A (2013) A formal specification of the horus modeling language using FDMM. In: Alt R, Franczyk B (eds) Proceedings of the 11th international conference on Wirtschaftsinformatik (WI2013). Merkur-Verlag, pp 1165–1179

30. Fill HG, Redmond T, Karagiannis D (2012) FDMM: a formalism for describing ADOxx meta models and models. In: Maciaszek L, Cuzzocrea A, Cordeiro J (eds) ICEIS 2012—14th international conference on enterprise information systems. SciTePress, http://www.iceis.org, Portugal. http://eprints.cs.univie.ac.at/3472/

31. Frank U (2011) The memo meta modelling language (mml) and language architecture. Tech. rep, ICB-research report

32. Frank U (2014) Multi-perspective enterprise modeling: foundational concepts, prospects and future research challenges. Softw Syst Model 13(3):941–962

33. Gharib M, Giorgini P, Mylopoulos J (2018) Analysis of information quality requirements in business processes, revisited. Requir Eng 23(2):227–249

34. HAS HAdS (2013) Outils de sécurisation et d'auto-évaluation de l'administration des médicaments. HAS, Saint-Denis La Plaine

35. ISO (2006) Iso 19439:2006 enterprise integration-framework for enterprise modelling. International Standards Organization, Geneva, Switzerland

36. ISO (2011) Iso/iec/ieee 42010 systems and software engineering—architecture description

37. Jakoubi S, Tjoa S, Goluch S, Kitzler G (2010) A formal approach towards risk-aware service level analysis and planning. In: 2010 International conference on availability, reliability and security, pp 180–187. IEEE

38. Jakoubi S, Tjoa S, Goluch S, Kitzler G (2010) Risk-aware business process management-establishing the link between business and security. In: Complex intelligent systems and their applications, pp 109–135. Springer

39. Jakoubi S, Tjoa S, Quirchmayr G (2007) Rope: A methodology for enabling the risk-aware modelling and simulation of business processes. In: ECIS, pp 1596–1607

40. Karagiannis D (2015) Agile modeling method engineering. In: Proceedings of the 19th panhellenic conference on informatics, pp 5–10. ACM

41. Karagiannis D, Kühn H (2002) Metamodelling platforms. In: E-Commerce and web technologies, third international conference, EC-Web 2002, Aix-en-Provence, France, September 2-6, 2002, Proceedings, p 182

42. Karagiannis D, Mayr HC, Mylopoulos J (eds) (2016) Domain-specific conceptual modeling, concepts, methods and tools. Springer, Berlin

43. Keeney RL (1996) Value-focused thinking. Harvard University Press

44. Kirakowski J, Corbett M (1993) Sumi: the software usability measurement inventory. Br J Educ Technol 24(3):210–212

45. Krogstie J, Sindre G, Jørgensen H (2006) Process models representing knowledge for action: a revised quality framework. Eur J Inf Syst 15(1):91–102

46. Kruchten PB (1995) The 4+ 1 view model of architecture. IEEE Softw 12(6):42–50

47. Lamine E, Thabet R, Sienou A, Bork D, Fontanili F, Pingaud H (2020) Bprim: an integrated framework for business process management and risk management. Comput Ind 117:103199

48. Lhannaoui H, Kabbaj MI, Bakkoury Z (2014) Analyzing risks in business process models using a deviational technique. In: 9th International conference on software engineering and applications (ICSOFT-EA), pp 189–194. IEEE

49. Lund MS, Solhaug B, Stølen K (2010) Model-driven risk analysis: the CORAS approach. Springer, Berlin

50. Mansour R, Murthy U (2007) Consideration of risks and internal controls in business process modeling

51. Marcinkowski B, Kuciański M (2012) A business process modeling notation extension for risk handling. In: IFIP International conference on computer information systems and industrial management, pp 374–381. Springer

52. Monarc.lu (2020) Official homepage of the Optimised Risk Analysis Method. http://www.monarc.lu/, last visited: 05.10.2020

53. Neiger D, Churilov L (2004) Goal-oriented business process modeling with epcs and value-focused thinking. In: International conference on business process management, pp 98–115. Springer

54. Neiger D, Churilov L, zur Muehlen M, Rosemann M (2006) Integrating risks in business process models with value focused process engineering. In: ECIS, pp 1606–1615

55. Peffers K, Tuunanen T, Rothenberger MA, Chatterjee S (2007) A design science research methodology for information systems research. J Manag Inf Syst 24(3):45–77

56. Persson M, Törngren M, Qamar A, Westman J, Biehl M, Tripakis S, Vangheluwe H, Denil J (2013) A characterization of integrated multi-view modeling in the context of embedded and
cyber-physical systems. In: 2013 Proceedings of the international conference on embedded software (EMSOFT), pp 1–10. IEEE

57. Pittl B, Fill HG, Honegger G (2017) Enabling risk-aware enterprise modeling using semantic annotations and visual rules. In: Proceedings of the 25th European conference on information systems (ECIS). AIS

58. Reineke J, Stergiou C, Tripakis S (2017) Basic problems in multi-view modeling. Softw Syst Model, pp 1–35

59. Rolland C, Prakash N, Benjamen A (1999) A multi-model view of process modelling. Requir Eng 4(4):169–187

60. Rotaru K, Wilkin C, Churilov L, Neiger D, Ceglowski A (2011) Formalizing process-based risk with value-focused process engineering. IseB 9(4):447–474

61. Sauro J, Lewis JR (2016) Quantifying the user experience: practical statistics for user research. Morgan Kaufmann

62. Sequerloo AY, Amiri MJ, Parsa S, Koupae M (2019) Automatic test cases generation from business process models. Requir Eng 24(1):119–132

63. Shah LA (2012) Value-risk based performance evaluation of industrial systems. Ph.D. thesis, Arts et Métiers ParisTech

64. Shah LA, Etienne A, Siadat A, Vernadat F (2017) Process-oriented risk assessment methodology for manufacturing process evaluation. Int J Prod Res 55(15):4516–4529

65. Sienou A (2009) Proposition d'un cadre méthodologique pour le management intégré des risques et des processus d'entreprise. Ph.D. thesis, Institut National Polytechnique de Toulouse

66. Sienou A, Karduck A, Pingaud H (2006) Towards a framework for integrating risk and business process management. IFAC Proc Vol 39(3):647–652

67. Sienou A, Lamine E, Karduck AP, Pingaud H (2008) Towards a semi-formal modeling language supporting collaboration between risk and process manager. In: 2008 2nd IEEE international conference on digital ecosystems and technologies, pp 119–125. IEEE

68. Strecker S, Heise D, Frank U (2011) Riskm: a multi-perspective modeling method for it risk assessment. Inf Syst Front 13(4):595–611

69. Suriadi S, Weiß B, Winkelmann A, ter Hofstede AHM, Adams M, Conforti R, Fidge C, Rosa ML, Ouyang C, Rosemann M, Pika A, Wynn M (2014) Current research in risk-aware business process management - overview, comparison and gap analysis. Communications of the AIS (CAIS) 34(2014)

70. Thabet R, Boufaied A, Lamine E, Bork D, Korbaa O, Pingaud H (2020) Adobprim: towards a new healthcare risk-aware business process management tool. In: 13th International conference on health informatics (HEALTHINF’2020), pp 498–505

71. Thabet R, Lamine E, Boufaied A, Bork D, Korbaa O, Pingaud H (2020) Formal specification, implementation, and evaluation of the AdoBPRIM approach. In: Americas Conference on Information Systems (AMCIS)

72. Thabet R, Lamine E, Boufaied A, Korbaa O, Pingaud H (2018) Towards a risk-aware business process modelling tool using the adoxx platform. In: International conference on advanced information systems engineering, pp 235–248. Springer

73. Tjoa S, Jakoubi S, Goluch G, Kitzler G, Goluch S, Quirchmayr G (2010) A formal approach enabling risk-aware business process modeling and simulation. IEEE Trans Serv Comput 4(2):153–166

74. Varela-Vaca AJ, Gasca RM, Pozo S (2011) Opbus: Risk-aware framework for the conformance of security-quality requirements in business processes. In: Proceedings of the international conference on security and cryptography, pp 370–374. IEEE

75. Varela-Vaca AJ (2016) Opbus: a framework for improving the dependability of risk-aware business processes. AI Commun 29(1):233–235

76. Vest TA, Gazda NP, Schenkat DH, Eckel SF (2019) Practice-enhancing publications about the medication use process in 2017. Am J Health-Syst Pharm

77. Visic N (2016) Language-oriented modeling method engineering. Ph.D. thesis, uniwien

78. Von Alan RH, March ST, Park J, Ram S (2004) Design science in information systems research. MIS Q 28(1):75–105

79. Wang Y, Zhao L (2019) Eliciting user requirements for e-collaboration systems: a proposal for a multi-perspective modeling approach. Requir Eng 24(2):205–229

80. Weiss B, Winkelmann A (2011) Developing a process-oriented notation for modeling operational risks-a conceptual metamodel approach to operational risk management in knowledge intensive business processes within the financial industry. In: System sciences (HICSS), 2011 44th Hawaii International Conference on, pp 1–10. IEEE

81. Williams D (2007) Medication errors. J-R Coll Phys Edinb 37(4):343

82. Wohlin C, Runeson P, Höst M, Ohlsson MC, Regnell B, Wesslén A (2012) Experimentation in software engineering. Springer, Berlin

83. Yu ES (1997) Towards modelling and reasoning support for early-phase requirements engineering. In: Proceedings of ISRE’97: 3rd IEEE international symposium on requirements engineering, pp 226–235. IEEE

84. Yu E (2011) Modelling strategic relationships for process reengineering. Soc Model Requir Eng 11:2011

**Publisher’s Note** Springer Nature remains neutral with regard to jurisdictional claims in published maps and institutional affiliations.