A Semiautomatic Process Model Veriﬁcation Method based on Process

Modeling Guidelines

Valter Helmuth Goldberg J

unior

, Lucineia Heloisa Thom

, Jos

e Palazzo Moreira de Oliveira

Marcelo Fantinato

and Diego Toralles Avila

Department of Informatics, Federal University of Rio Grande do Sul, Porto Alegre, Brazil

School of Arts, Sciences and Humanities, University of S

ao Paulo, S

ao Paulo, Brazil

Keywords:

Business Process, BPMN, Ontology, Process Model Quality, Modeling Guidelines.

Abstract:

Designing comprehensible process models is a complex task. Process analysts must rely on the experience

of expert systems managers to achieve process models with high comprehensibility, also known as pragmatic

quality. In the literature, this is portrayed as process modeling guidelines that help modelers to avoid common

issues which hinder the comprehension of the process model. In this paper, we propose a method for the semi-

automatic veriﬁcation of business process models according to process modeling guidelines. This method

uses the BPMN Ontology and the ontology editor Prot

e to assist the modeler with validation of the process

model’s syntax before certifying its pragmatic quality. The validation of the developed method was applied to

a collection of 31 process models and the results show that 23 process models of the collection contain at least

one guideline violation.

1 INTRODUCTION

Business Process Management (BPM) is a disci-

pline that provides a systematic approach to manage

an organization’s work by modeling, analyzing, im-

proving and controlling its business processes (here-

after called processes, for simpliﬁcation). BPM con-

tributes to the increase of productivity and reduction

of costs through more effective, more efﬁcient and

more adaptable processes (van der Aalst, 2013).

With BPM, organizations continually seek to im-

prove the quality of their processes. However, stud-

ies analyzing models of industry processes reveal that

many process models contain issues that harm its

quality, such as control ﬂow errors, badly designed

structures and layouts or incorrect labeling (Mendling

et al., 2008; Leopold et al., 2016). With the process

modeling being a key part of BPM, it is important to

prevent these issues if we expect processes of better

quality.

It is widely accepted that modeling a process is a

difﬁcult task (Mendling et al., 2010). This is usually

due to the complexity of the modeling notation, its

many different elements and their respective seman-

tics (Leopold et al., 2016). Choosing the appropri-

ate design to represent the real world process depends

upon the expertise or the guidance of an experienced

modeler, which may greatly inﬂuence the quality of

the resultant process model. It is necessary to con-

sider that, while the use of process modeling tools can

help in this regard, they cannot guarantee a process

model’s correctness nor its comprehensibility.

One way to solve this challenge and help the

beginner modelers is to consolidate the knowledge

of experienced modelers in process modeling guide-

lines, whose purpose is to help the user to reduce

the complexity and the number of errors in a pro-

cess model through the restriction of undesirable con-

structs. Many guidelines have been proposed by

both practitioners (Silver, 2009; White and Miers,

2008; Allweyer and Allweyer, 2010) and researchers

(Becker et al., 2000; Mendling et al., 2007; Vander-

feesten et al., 2008; Correia and Abreu, 2012). Once

it is veriﬁed that a process model is following a set of

guidelines, we can presume that it has good compre-

hensibility.

However, using guidelines to verify a process

model does not make sense if the model is not syn-

tactically correct. Any knowledge extracted from an

incorrect process model has its validity compromised

as at the same time that the model is readable some

doubt may exists about the modeler intended repre-

sentation (Reijers et al., 2015). Therefore, it is nec-

essary to verify if a process model is correct before

274

Júnior, V., Thom, L., Oliveira, J., Fantinato, M. and Avila, D.

A Semiautomatic Process Model Veriﬁcation Method based on Process Modeling Guidelines.

DOI: 10.5220/0006316602740281

In Proceedings of the 19th International Conference on Enterprise Information Systems (ICEIS 2017) - Volume 3, pages 274-281

ISBN: 978-989-758-249-3

considering its comprehensibility.

It is possible to verify the correctness of process

models in different ways. One of these is by the

means of ontologies. Ontology is the study of the na-

ture of being, which pursues to represent the world

as entities, categories and relations (Guizzardi, 2012;

Mendling, 2008a). In a more practical description, an

ontology provides an approach to deﬁne types, prop-

erties and relations. It is possible to use an ontology to

represent BPM process models as a meta-model with

inference capability to verify a process model’s cor-

rectness.

Following this approach, the objective of this pa-

per is to show how the use of ontologies may assist

in the identiﬁcation of problems that reduce a process

model’s comprehensibility. To perform this valida-

tion, it is necessary to represent a process model as

a process model ontology and use the ontology infer-

ence processor to verify a set of guidelines for process

modeling, pointing out any problems that can be im-

proved.

This paper is organized as follows: Section 2

presents a short review of previous works related to

the veriﬁcation of process models. Section 3 shortly

introduces the basic concepts used in this paper. Sec-

tion 4 explains the context chosen to work with and

the method developed. Section 5 presents the applica-

tion study and the results. Section 6 closes the paper

with conclusions.

2 RELATED WORKS

The veriﬁcation of process models is nothing new, in

fact, numerous researches addressed this subject. The

difference is that most of these researches are con-

cerned with issues of correctness of a process model.

In Mendling (2008a), for example, the author pro-

poses two different approaches to verify the sound-

ness of a process model draw using Event-Process-

Chains.

Evaluating and reducing the complexity of a pro-

cess model is harder to achieve. It is not possible

to measure a process complexity directly and, as a

consequence, many metrics have been proposed that

try to solve this problem indirectly (Vanderfeesten

et al., 2007; Mendling, 2008b; Gruhn and Laue, 2006;

anchez-Gonz

alez et al., 2012). The validity of these

metrics is evidenced through statistical experiments,

where process models are judged both by the metrics

and by people with varying levels of modeling experi-

ence (Cardoso, 2006; S

anchez-Gonz

alez et al., 2008).

As it was mentioned, many authors proposed

guidelines for modeling processes, with repeated

guidelines that had already been proposed, with only

few small variations in the details. In Moreno-Montes

de Oca and Snoeck (2014), these repeats were gath-

ered from a systematic review about business process

modeling quality from over a 100 proposed in the lit-

erature and turned into 27 uniﬁed guidelines.

Some of the existing BPMN tools try to pro-

vide some support for creating good process models.

Based on the guidelines found in the referred article, a

study (Snoeck et al., 2015) was performed to test how

extensive was, at the time, the support of the popular

BPMN tools in creating good process models. From

this analysis, it is possible to learn that the Signavio

modeler tool provides the best support for modeling

processes using guidelines.

While the referenced works are build upon impor-

tant process modeling concepts, none of them provide

a complete approach to certify the comprehensibility

of process models. The present work explains the de-

velopment of a method and how to adapt each concept

for an ontological approach that allows the veriﬁca-

tion of the process models in a semi-automatic way.

3 BACKGROUND

The modeling task of BPM is often done using

the Business Process Model and Notation (BPMN).

BPMN was developed by the Object Management

Group (OMG), with the purpose of consolidating the

many existing notations for process models in a sin-

gle standard. This standard should provide an easy to

understand notation to all stakeholders (OMG (Object

Management Group), 2015).

Most BPMN elements are labeled, to identify the

parts of the process they constitute. BPMN also has

many different types of elements to represent a pro-

cess, each with a different purpose. There are ﬁve

main types covered in this paper :

• Activities represent tasks that may need to be

performed (e.g., ”Print daily report”) or sub-

processes, that contains multiple elements of the

process inside a single element.

• Events correspond to things that happen instanta-

neously (e.g. ”Purchase order received”). Events

may be start, intermediate or end events.

• Sequence Flows link two elements together,

forming the paths that may be taken during the

execution of the process.

• Gateways serve to split or join the ﬂow of ac-

tions performed in the process. There are differ-

www.signavio.com

A Semiautomatic Process Model Veriﬁcation Method based on Process Modeling Guidelines

275

Figure 1: The SIQ Framework, adapted from Reijers et al.

(2015).

ent types of gateways: AND gateways for concur-

rency, XOR gateways for exclusive choices and

OR gateways for inclusive choices.

• Pools group together elements that happen in a

single organization (e.g., a university). Swimlanes

may divide these pools to identify different re-

sources of that organization (e.g., departments)

Although these types are useful in the modeling of

processes, BPMN does not teach modelers how to use

them to create simple and expressive process models.

The consequence of this is that it is hard to achieve a

good level of quality in BPMN process models.

This difﬁculty motivated the creation of many

frameworks that try to deﬁne what is the quality of a

process model and classify the different quality types

that compose it. Examples of these efforts are the SE-

QUAL Framework (Krogstie, 2012), the Guidelines

of Modeling (GoM) (Schuette and Rotthowe, 1998)

and, more recently, the SIQ framework (Reijers et al.,

2015), in which we base the present work, due to

its simplicity and its widespread use in the literature

surrounding the quality of process models. The SIQ

framework deﬁnes process model quality as made of

three basic quality types:

• Syntactic Quality identiﬁes if a process model

conforms to the rules deﬁned by the notation uti-

lized to create it. In other words, if a process

model follows the syntax and the vocabulary of

its modeling language, then it is possible to verify

that process model and afﬁrm it to be correct. To

do so, the veriﬁcation must check the static propri-

eties of a process model - how different types of

elements are used and combined - and its behav-

ioral proprieties - the process modeled should not

reach a deadlock and must be completed properly,

i.e., the process model is sound.

• Semantic Quality bears the connection between

a process model and the real world process that

it is supposed to represent. To check a process

model’s semantic quality is to guarantee it is valid

- all elements of the process model correctly rep-

resent the real world - and complete - there are

no real world process parts that are missing from

the process model. This check is called validation

and, if it passes, the process model is ascertained

to be true.

• Pragmatic Quality characterizes the comprehen-

sibility of a process model. It is the certiﬁcation

that a user’s interpretation of a process model is

equal to the real world process. If done, the pro-

cess model is said to be understood.

Syntactic quality is the basis for the other two

qualities. As mentioned before, it is not reasonable

to consider the comprehensibility of a process model

if it is not syntactically correct. The same concern

must be expressed on its semantic quality. The ver-

iﬁcation of a process model must be done before its

validation or certiﬁcation. As previously explained, it

is possible to do this veriﬁcation using an ontology.

More speciﬁcally, we can use an ontology design to

serve as a meta-model for a process modeling nota-

tion. In the case of BPMN exists the BPMN Ontology

(Rospocher et al., 2014), which supports the mapping

of a BPMN process model into elements of the on-

tology, while preserving the relations and structures

between the BPMN elements. Using this ontology, it

is possible to apply an inference engine to verify the

mapped process model, checking if the static prop-

erties of BPMN model, i.e., its structure, is correct

according to the BPMN syntax.

Finally, assuming the process model is indeed cor-

rect, we can try to ensure its pragmatic quality, which

is done by checking it via the use of process modeling

guidelines. In Mendling et al. (2010, pag. 3), seven

process modeling guidelines (7PMG) have been pro-

posed that are ”thought to be helpful in guiding users

towards improving the quality of their models, in the

sense that these are likely (1) to become comprehen-

sible to various stakeholders and (2) to contain few

syntactical errors”. These guidelines have been built

upon empirical insights and, as such, provide a short

but meaningful set of rules, which encouraged their

use at an academic level to teach beginner modelers

about quality of process models. They are as follows:

G1 Use as Few Elements in the Model as Possible.

The larger a process model is, the more difﬁcult it

is to understand and the more likely it is for syn-

tactical errors to exist in it.

ICEIS 2017 - 19th International Conference on Enterprise Information Systems

276

G2 Minimize the Routing Paths per Element.

These paths are the sum of the incoming and the

outgoing arcs for each element. A high number of

paths in a single element makes the model harder

to understand.

G3 Use One Start and One End Event. Models that

satisfy this requirement are easier to understand

and are less likely to have errors.

G4 Model as Structured as Possible. A process

model is structured if for each gateway that splits

the ﬂow of the process model there is another

gateway of the same type that joins the ﬂow.

Ideally, a structured model is like a math for-

mula with balanced brackets, i.e., every opening

bracket has a corresponding closing bracket of the

same type. Structured models tend to be easier to

understand and to have less errors

G5 Avoid OR Routing Elements. The behavior of

OR gateways are more difﬁcult to comprehend

and limiting their use reduces the likelihood of

misinterpretations.

G6 Use Verb-object Activity Labels. There are

many different labeling styles for process models.

According to the literature, the verb-object style

is less ambiguous and more useful than the oth-

ers, like action-noun.

G7 Decompose a Model with More than 30 El-

ements. Like G1, a high number of elements

makes the process model less understandable and

more error-prone. After 30 elements, it is rec-

ommended to split the process model into smaller

models, either by creating new models or by gath-

ering a group of process model elements and re-

placing them with a sub-process.

It is important to note that these guidelines do

not concern with the semantics of the process model.

Whether a model of a speciﬁc process follows or not

these guidelines this characteristic should not imply in

a change of the behavior of the modeled process. All

that the 7PMG rules change is the comprehensibility

of the process model and the reduction of possibility

that modeling errors exist in it (Mendling et al., 2010).

4 GUIDELINE-DRIVEN PROCESS

MODEL VERIFICATION

To fulﬁll the objective of this paper, it is necessary

to specify a series of steps that, with the assistance

of an ontology, allows us to certify a process model’s

pragmatic quality by checking whether it follows the

seven process modeling guidelines.

Table 1: Indicators tested for each guideline from 7PMG.

7PMG Indicators and comparisons

G1 Number of elements > 30

G2 Maximum connector degree > 5

Number of start events > 1

Number of end events > 1

G4 Number of splits 6= Number of joins

G5 Number of OR gateways > 0

G6 Wordnet

G7 Number of elements > 30

To start with the development of the framework

it is necessary to decide about the form of how the

process models will be represented. A few different

notations for process models exist and each notation

has different ways of how the process model is coded

within a ﬁle. The notation used in this work is BPMN

2.0. Models using this notation may be exported to

the interchangeable format deﬁned by OMG, which

is a XML ﬁle with a speciﬁc schema and a .bpmn ex-

tension (OMG (Object Management Group), 2015).

From this ﬁle, it is possible to map elements from the

process model in an ontology, via the BPMN Ontol-

ogy.

Secondly, it is necessary to establish how to check

whether a guideline is being followed or not by a pro-

cess model. They must be expressed in a binary yes

or no question. To allow this, each guideline must

be associated to a process model indicator that may

be measured and compared against optimal thresh-

olds. Previous works (Mendling, 2008a; Recker,

2011; Mendling et al., 2012; S

anchez-Gonz

alez et al.,

2012) have studied process model indicators to pro-

duce empirically validated thresholds for each guide-

line, allowing a modeler to be alerted when there is a

issue that affects the process model’s comprehensibil-

ity. The table 1 presents the indicators and the optimal

thresholds used to check if the process model violates

each guideline. Based on these, two guidelines show

problems: G1 and G6.

G1, the guideline for encouraging the use of fewer

elements when modeling, becomes redundant with

G7, which determines when a process model should

be decomposed. This occurs because the indicator

used for G1 is the same one employed for G7. There-

fore, we need to choose which guideline is more ap-

propriate for the proposed method. Since G1 is more

suited to be applied when a process model is being

developed and the modeler can refrain from introduc-

ing new elements, instead of when the modeling is

ﬁnished, the guideline G7 is the most suited.

G6, which tells us to label activities in the verb-

object style, presents a problem related to the com-

plexity of checking the language of each label. This

A Semiautomatic Process Model Veriﬁcation Method based on Process Modeling Guidelines

277

Table 2: BPMN ⇒ Ontology Mapping.

BPMN Ontology Example

Element type OWL class Activity, gateway

Element instance Individual named Task 1: Submit report

Attribute Object property Label=”Name”

Attribute value Data property Name:String=”Task 1: Submit report”

Table 3: Recommended Actions for each tested guideline.

7PMG Recommended action

G2 Reduce the number of sequence ﬂows

connected to a single element

G3 Restructure the process model to re-

duce the number of Start and End

events

G4 Restructure the process model to have

the same number of Split and Joins

G5 Restructure the process model to re-

move the OR Gateways

G7 Decompose the process model

exceeds the scope of this work, since it requires the

use of Natural Language Processing to identify the

words of each label and compare them and their

use against a thesaurus to deﬁne the label’s context

(Gassen et al., 2014). Therefore, we are ignoring this

guideline.

Finally, it must be determined how an ontology

will be loaded and edited. We chose to use the on-

tology editor Prot

. Prot

e not only can verify

the integrity of ontologies using an inference engine,

it can also be extended using plugins. Much of our

method was built using this extensibility.

Having made these decisions, we speciﬁed a

method to certify the pragmatic quality of process

models based on the seven process modeling guide-

lines, verifying a process model syntax using the on-

tology and its associated inference engine.

The ﬁrst step of the method is conﬁgure Prot

for instantiating BPMN models. The BPMN ontology

is loaded to support the mapping of elements from

BPMN to the ontology by serving as the meta-model

containing the structuring rules of BPMN. Following

this activity, the individual elements from the BPMN

models can be extracted and instantiated into the on-

tology by a Java plugin which reads the .bpmn ﬁle of

the process models and extracts its tasks, gateways,

sequence ﬂows and messages. After the same plugin

uses the OWL-API to create individuals for each el-

ement, mapping and instantiating them according to

each type described by the BPMN Ontology. The ta-

ble 2 shows the mapping.

Once the entire process model has been instanti-

http://protege.stanford.edu/

ated in the ontology, the Prot

e veriﬁes if the pro-

cess model is syntactically correct. Using Prot

e in-

ference engine, we can verify the ontology’s integrity

and, if this is successful, it can be assumed that the

structure of the BPMN model is syntactically cor-

rect, since any syntactical error in the process model’s

structure would violate the ontology’s integrity ac-

cording to the BPMN Ontology.

The ﬁnal steps of this method are checking the

process model according to the seven process mod-

eling guidelines and recommending modeling alter-

natives based upon the results. Another Java Plugin

checks the process model’s indicators and, for each

violated guideline, recommends actions according to

the table 3.

The entire series of steps are (ﬁgure 2):

1. Load the BPMN Ontology in Prot

2. Extract each individual element from a BPMN

model.

3. Instantiate each extracted element in Prot

e via

OWL-API and using the BPMN Ontology.

4. Use Prot

e’s inference engine to verify the in-

tegrity of the new ontology.

5. Check if the process model’s indicators obey the

limits deﬁned by the modeling guidelines.

6. Recommend modeling alternatives to the process

model for each guideline not followed (table 3).

5 APPLICATION STUDY AND

RESULTS

To validate our method, it was applied to a collection

of 31 BPMN models. These models represents the

processes of a university, created by BPM students,

veriﬁed and corrected by their adviser and semanti-

cally validated by the process stakeholders. To create

these models, the students used the Bizagi

Modeler

tool, which does not offer support for the guidelines

we test (Snoeck et al., 2015).

For each guideline used in the method, the associ-

ated indicators were extracted for a statistical analysis

http://www.bizagi.com

ICEIS 2017 - 19th International Conference on Enterprise Information Systems

278

Figure 2: Steps to verify process models based on process modeling guidelines.

Table 4: Statistics for the indicators related to the guidelines G2, G3, G5, G7.

Maximum

connector degree

Start events N

End events N

OR gateways N

Elements

Average 3.7097 1.871 1.9355 0.2903 23.4194

Std. Deviation 0.9379 0.8848 0.892 0.8638 13.458

Minimum 2 1 1 0 6

Maximum 6 4 4 4 76

Median 3 2 2 0 21

Table 5: Statistics for the indicators related to the guideline

G4.

Splits - Joins difference

AND XOR OR

Average 0.129 0.4839 -0.0968

Std. Deviation 0.3408 1.3873 0.3962

Minimum 0 -2 -2

Maximum 1 4 0

Median 0 0 0

(as seen in tables 4 and 5). Based on these statistics,

we tried to predict whether the process models of this

collection follow or not the process modeling guide-

lines.

For example, in the statistics for maximum con-

nector degree , associated with guideline G2, we see

that the highest value found was 6, which is above the

recommended value of 5 for this guideline. However,

if we look at the average of 3.7097 and the standard

deviation of 0.9379, it is possible to perceive that it is

unlikely, assuming a normal distribution, that a ran-

dom process model picked from our collection will

have more than the recommended threshold for this

guideline, which is ﬁve. Consequently, we can antic-

ipate that the high majority of process models from

the collection will follow the guideline. G5 is similar,

since the average number of OR gateways is low, but

not zero, and the standard deviation is almost 1, im-

plying that a few process models do use OR gateways,

up to the maximum of 4. For this reason, we suppose

that a few process models violate this guideline, and

our method shows this.

For G3, on the other hand, we see the opposite sit-

uation, as the number of both start and end events has

the high average (almost 2), compared to the recom-

mended use of 1 event of each. This implies that most

process models from the collection have multiple start

and end event and, therefore, they do not follow G3.

Analysis for guideline G4 is more complicated,

since we deﬁne whether the process model is or not

structured as the measure of the difference between

the indicators of the number of splits and the num-

ber of joins. Not only that, it is also necessary to

measure the difference for each each type of gateway.

This balance means that the closer to zero is the av-

erage difference and the lower is the standard devia-

tion then it is more likely that the process models are

structured. We recognize the opposite, however, since

there is an imbalance of the number of XOR splits

versus the number of XOR joins according to the av-

erage of 0.4839 for that indicator. Also, the high stan-

dard deviation of 1.3873 shows for the XOR gateway

indicates that most process models in the collection

are not structured. Therefore, we predict that many

A Semiautomatic Process Model Veriﬁcation Method based on Process Modeling Guidelines

279

Table 6: Number of violations per guideline.

Total violations Percent of total

G2 1 3.23%

G3 1 3.23%

G4 22 70.97%

G5 4 12.90%

G7 6 19.35%

process models of this collection infringe the guide-

line G4.

Finally, the statistics for G7 are slightly vague.

The high, but not unreasonable, average for the mea-

sure of the number of elements suggest that the guide-

line is followed. Yet, the high standard deviation

shows a hint that at least some process models do have

more than 30 elements.

With all this information in mind, our expecta-

tions are that most process models violate guidelines

G3 and G4, while following guidelines G2 and G5.

Lastly, guideline G7 will a have a few violations.

Comparing these conclusions with the results of

the applied method (as show in table 6) shows that the

predictions for guidelines G2, G4, G5 and G7 match

the results. The results for guideline G3, however, is

unexpected. After further analysis, we found a reason

for this behavior. Many process models of the col-

lection have multiple pools or sub-processes, both of

which require, according to the notation, a new start

and a new end event, causing a distortion in the num-

ber of events of each process model. Therefore, we

must take this distortion into account for the statisti-

cal analysis.

6 CONCLUSION

Process models that follow the guidelines of process

modeling are more likely to be understood by the pro-

cess stakeholders. With the help of process modeling

tools that support those guidelines, modelers can rep-

resent and communicate the mechanisms of a process

through the models, achieving higher levels of model-

ing quality that improve the work of an organization.

Through the application study, we perceived the

difﬁculty that beginner modelers experience in cre-

ating process models following the modeling guide-

lines. Most process models in the collection have at

least one aspect that is inefﬁcient for the their compre-

hension (table 7). It is observable that beginners need

help in ﬁnding these inefﬁciencies and that this help

may only be accomplished if more support is provided

by the modeling tools.

In this paper, it was shown that it is possible to

semi-automatically verify process modeling guide-

Table 7: Number of process models per quantity of viola-

tions.

Number of models

No violations 8

One violation 13

Two violations 9

Three violations 1

lines with the assistance of the BPMN ontology. This

procedure analyzes the process models and recom-

mends solutions to increase their pragmatic quality.

The plugin developed based on this procedure identi-

ﬁes modeling inefﬁciencies that violate the seven pro-

cess modeling guidelines and we hope that it may

contribute in helping beginner modelers to identify

possible modeling inefﬁciencies in regard with the

comprehensibility of process models.

One limitation that must be acknowledged is re-

lated with the use of the BPMN ontology to check

the syntax of the process model. While it is possi-

ble to verify the static proprieties of a process model,

the BPMN ontology is not suited to specify a process

model’s dynamic behavior (Rospocher et al., 2014).

Therefore, we were not able verify a process model’s

entire syntactic quality.

While the method is by no means complete, as

there are more guidelines in the literature beyond

those applied here, we hope that this work brings at-

tention to the necessity of accurate tool support for

creating process models with high comprehensibility.

We also believe that our work will provide a basis for

future works in this area.

REFERENCES

Allweyer, T. and Allweyer, D. (2010). BPMN 2.0 : intro-

duction to the standard for business process modeling.

Books on Demand GmbH.

Becker, J., Rosemann, M., von Uthmann, C., and Uthmann,

C. V. (2000). Guidelines of Business Process Model-

ing. Business Process Management, 1806:241–262.

Cardoso, J. (2006). Process control-ﬂow complexity metric:

An empirical validation. Services Computing, 2006.

SCC’06. IEEE International . . . .

Correia, A. and Abreu, F. B. e. (2012). Adding Preciseness

to BPMN Models. Procedia Technology, 5:407–417.

Gassen, J. B., Mendling, J., Thom, L. H., and de Oliveira,

J. P. M. (2014). Business process modeling. In Pro-

ceedings of the 32nd ACM International Conference

on The Design of Communication CD-ROM - SIG-

DOC ’14, pages 1–10, New York, New York, USA.

ACM Press.

Gruhn, V. and Laue, R. (2006). Complexity metrics for

business process models. 9th international conference

on business information . . . .

ICEIS 2017 - 19th International Conference on Enterprise Information Systems

280

Guizzardi, G. (2012). Ontological Foundations for Con-

ceptual Modeling with Applications, pages 695–696.

Springer Berlin Heidelberg, Berlin, Heidelberg.

Krogstie, J. (2012). Model-Based Development and Evolu-

tion of Information Systems. Springer London, Lon-

don.

Leopold, H., Mendling, J., and Gunther, O. (2016). Learn-

ing from Quality Issues of BPMN Models from Indus-

try. IEEE Software, 33(4):26–33.

Mendling, J. (2008a). Metrics for Process Models. Metrics

for Process Models, 6(0):103–133.

Mendling, J. (2008b). Metrics for Process Models, vol-

ume 6 of Lecture Notes in Business Information Pro-

cessing. Springer Berlin Heidelberg, Berlin, Heidel-

berg.

Mendling, J., Neumann, G., and Aalst, W. M. P. V. D.

(2007). On the Correlation between Process Model

Metrics and Errors. 26th international conference on

Conceptual modeling, pages 173–178.

Mendling, J., Reijers, H. A., and van der Aalst, W. M. P.

(2010). Seven process modeling guidelines (7PMG).

Information and Software Technology, 52(2):127–

136.

Mendling, J., S

anchez-Gonz

alez, L., Garc

ıa, F., and La

Rosa, M. (2012). Thresholds for error probability

measures of business process models. Journal of Sys-

tems and Software, 85(5):1188–1197.

Mendling, J., Verbeek, H., van Dongen, B., van der Aalst,

W., and Neumann, G. (2008). Detection and predic-

tion of errors in EPCs of the SAP reference model.

Data & Knowledge Engineering, 64(1):312–329.

Moreno-Montes de Oca, I. and Snoeck, M. (2014). Prag-

matic guidelines for Business Process Modeling.

page 70.

OMG (Object Management Group) (2015). BPMN Speci-

ﬁcation - Business Process Model and Notation.

Recker, J. (2011). Evaluations of process modeling gram-

mars : ontological, qualitative and quantitative anal-

yses using the example of BPMN. Springer.

Reijers, H. A., Mendling, J., and Recker, J. (2015). Business

Process Quality Management. In Handbook on Busi-

ness Process Management 1, pages 167–185. Springer

Berlin Heidelberg, Berlin, Heidelberg.

Rospocher, M., Ghidini, C., and Seraﬁni, L. (2014). An on-

tology for the Business Process Modelling Notation.

In Garbacz, P. and Kutz, O., editors, Formal Ontology

in Information Systems - Proceedings of the Eighth In-

ternational Conference, FOIS2014, September, 22-25,

2014, Rio de Janeiro, Brazil, volume 267, pages 133–

146. IOS Press.

anchez-Gonz

alez, L., Garc

ıa, F., Mendling, J., Ruiz, F.,

and Piattini, M. (2008). Prediction of Business Pro-

cess Model Quality Based on Structural Metrics.

anchez-Gonz

alez, L., Garc

ıa, F., Ruiz, F., and Mendling, J.

(2012). Quality indicators for business process models

from a gateway complexity perspective. Information

and Software Technology, 54(11):1159–1174.

Schuette, R. and Rotthowe, T. (1998). The Guidelines of

Modeling – An Approach to Enhance the Quality in

Information Models. pages 240–254. Springer Berlin

Heidelberg.

Silver, B. (2009). BPMN Method and Style: A levels-based

methodology for BPM process modeling and improve-

ment using BPMN 2.0.

Snoeck, M., Moreno-Montes de Oca, I., Haegemans, T.,

Scheldeman, B., and Hoste, T. (2015). Testing a se-

lection of BPMN tools for their support of modelling

guidelines. In Lecture Notes in Business Information

Processing, volume 235, pages 111–125.

van der Aalst, W. M. P. (2013). Business Process Man-

agement: A Comprehensive Survey. ISRN Software

Engineering, 2013:1–37.

Vanderfeesten, I., Cardoso, J., Mendling, J., Reijers, H. A.,

and van der Aalst, W. (2007). Quality metrics for busi-

ness process models. BPM and Workﬂow . . . , pages

1–12.

Vanderfeesten, I., Reijers, H. A., Mendling, J., Van Der

Aalst, W. M. P., and Cardoso, J. (2008). On a quest for

good process models: The cross-connectivity metric.

Lecture Notes in Computer Science (including sub-

series Lecture Notes in Artiﬁcial Intelligence and Lec-

ture Notes in Bioinformatics), 5074 LNCS:480–494.

White, S. a. and Miers, D. (2008). BPMN Modeling and

Reference Guide.

A Semiautomatic Process Model Veriﬁcation Method based on Process Modeling Guidelines

281