Declarative Versus Imperative Business Process Languages

A Controlled Experiment

Nat´alia C. Silva, C´esar A. L. de Oliveira, Fabiane A. L. A. Albino and Ricardo M. F. Lima

Center for Informatics (CIn), Federal University of Pernambuco, Recife, PE, Brazil

Keywords:

Flexible Business Processes, Controlled Software Experiment, Comparative Study, Declarative Languages.

Abstract:

It has been argued that traditional workﬂows lack the ﬂexibility to cope with complex and changing envi-

ronments found in several business domains. The declarative approach surged with the aim of enabling more

ﬂexible business process management systems. Processes are designed in terms of activities and rules that con-

strain their execution. As such, declarative models are less rigid and prescriptive than workﬂows, since this

approach focus on modeling what must be done and not how. Despite these arguments, there is no quantitative

evidence that the beneﬁts provided by current declarative approaches outperform the features of traditional

workﬂows. In this work, we present the results of a controlled experiment conducted to empirically compare

Workﬂow and Declarative approaches to business process modeling. A set of test cases is proposed to the

participants to test their capacity to cope with unexpected situations. Our ﬁndings do not show signﬁcative

differences from adopting one process modeling approach or the other.

1 INTRODUCTION

Workﬂow technology is a popular approach for the

automation of business processes (Jeston and Nelis,

2006) (Coalition, 1995). Workﬂows describe each

activity that must be performed during the execu-

tion of a business process, the order in which they

need to be executed, the participants that execute each

one, and the ﬂow of information between them (zur

Muehlen, 2002). The Workﬂow approach is widely

used by business process practitioners. Business pro-

cess automation provides higher efﬁciency, less co-

ordination effort, and higher quality to business pro-

cesses (H. Reijers and van der Aalst, 2003).

However, the Workﬂow approach assumes that the

process modeler knows in advance everystep that will

be necessary during the process execution for pro-

ducing the speciﬁed output. Due to this prescriptive

nature, many researchers argue that Workﬂow mod-

els suffer from excessive complexity and that this ap-

proach undermine the capacity of companies to deal

with unforeseen situations (Pesic, 2008)(Weber et al.,

2009)(Dadam et al., 2008)(Nurcan, 2008). As the en-

vironment where the business processes execute in-

creases in complexity, the Workﬂow models become

less effective in handling the incoming cases. They

often are either too simple, thus unable to handle the

variety of situations that occur, or too complex, trying

to model every imagined possible situation but being

hard to maintain. In both cases they may cause several

problems to the company.

Declarative business processes surged from the

necessity for supporting the execution of processes

in complex or changing environments (Pesic, 2008).

The declarative approach uses descriptive modeling.

Business processes are described by means of busi-

ness rules that tell what one can, can not, or should

do to produce the desired output. It tells what has

to be done, but not how. The Declarative approach

promises to be able to support a large variety of situ-

ations with models that are small and concise (Pesic,

2008).

Despite such arguments in favour of Declarative

models over Workﬂows, no controlled experiment has

been presented to empirically demonstrate their va-

lidity. In this paper, our interest is to compare these

two different process modeling approaches – Work-

ﬂow and Declarative – in real-world business do-

mains. To accomplish this, a formal experiment was

conducted to quantitatively measure the beneﬁts of

each approach in face of unstable environments. In

this experiment, a group of students had the task of

modeling a set of requirements of a real software de-

velopment company. We measured the effort required

by them to model the process and to adapt it in face

of unexpected situations. Contrary to the claims that

394

C. Silva N., A. L. de Oliveira C., A. L. A. Albino F. and M. F. Lima R..

Declarative Versus Imperative Business Process Languages - A Controlled Experiment.

DOI: 10.5220/0004896203940401

In Proceedings of the 16th International Conference on Enterprise Information Systems (ICEIS-2014), pages 394-401

ISBN: 978-989-758-029-1

 2014 SCITEPRESS (Science and Technology Publications, Lda.)

declarative models are better to cope with these situa-

tions, the results showed no statistically relevant indi-

cations that declarative models can outperform work-

ﬂow when dealing with unexpected situations.

This paper is structured as follows: Section 2 pro-

vides an overview of workﬂow and declarative ap-

proaches and the arguments for moving from work-

ﬂow models to declarative models. Section 3 details

the experiment settings and methodology employed.

The execution of the experiment is then described in

Sec. 4. Section 5 presents the analysis of the results

obtained. Section 6 discuss related work and the ﬁnal

conclusion is summarized in Sec. 7.

2 BACKGROUND

This section gives an overview on workﬂow and

declarative approaches and describes the modeling

tools employed in the experiment performed.

2.1 Workﬂow and Declarative Processes

Workﬂow Management System (WfMS) technology

has grown in use in the last decades, and has become

a standard technology for the automation and man-

agement of business processes (Coalition, 1995). A

workﬂow describes an algorithm for the execution of

a business process. As such, it requires that the mod-

eler knows in advance every step necessary for pro-

ducing the desired results, for every possible situa-

tion. There are a number of modeling languages cur-

rently in use for business process modeling and au-

tomation through WfMS. Business Process Modeling

Notation (BPMN) (White, 2006), Business Process

Execution Language (BPEL), and XML Process Def-

inition Language (XPDL) (WFMC, 2002) are promi-

nent examples. Several industrial tools are available

for workﬂow modeling and execution. In this work,

we employed the BizAgi free process modeler (Mod-

eler, 2010), which supports Business Process Model-

ing Notation (BPMN) as the modeling language.

Workﬂow Management Systems are considered to

be too rigid because they do not provide ways to cope

with unforeseen situations. Unexpected events must

be handled outside of the system (Pesic and van der

Aalst, 2006). As a response to the demand for more

ﬂexible management systems, a new generation of

adaptive business process management systems has

been proposed (Nurcan, 2008)(Dadam et al., 2008).

Examples of this kind of systems are Case-Handling

Systems (CHS) (Mutschler et al., 2008), Declarative

Business Processes (Pesic, 2008), and systems sup-

porting ad-hoc process change (the ADEPT2 frame-

work) (Dadam et al., 2008).

The focus of this work is on the Declarative ap-

proach, which proposes the use of declarative lan-

guages to deﬁne the business rules that drive the exe-

cution of a business process (Pesic and van der Aalst,

2006). This represents a paradigm shift from tra-

ditional imperative languages that are employed by

other approaches. The key feature of declarative lan-

guages is that they specify “what” must be done but

do not determine “how”. By such means, they allow

the participants of the process to make context-aware

decisions during the business process execution. On

the other side, constraining business rules are deﬁned

to prevent participants from performing activities in a

way that is prohibited or undesired by the company.

The DECLARE framework (Pesic, 2008) is a tool

for modeling and executing declarative business pro-

cess models. DECLARE employs rule templates that

can be used in the construction of business rules.

These templates are mapped into formal expressions

described in Linear Temporal Logic (LTL) and inter-

preted through a reasoning engine to decide which ac-

tivities are required and which are prohibited during

the process execution. A graphical template language,

called ConDec (Pesic and van der Aalst, 2006), is also

available in DECLARE. This language helps in pro-

viding a more intuitive, graphical view of the process.

It is automatically interpreted as LTL expressions by

the DECLARE’s execution engine.

ConDec introduces a number of constructions for

the deﬁnition of the relations between activities in a

business process:

• Existential Templates: express the number of

times an activity can or needs to be executed in

the same process instance;

• Relational Templates: express dependencies be-

tween activities, such as precedence (B cannot be

executed before A), response (B needs to be exe-

cuted after each execution of A), and co-existence

(if A is ever executed, B must also be executed in

the same instance);

• Choice Templates: express decisions. For exam-

ple, mutual exclusiveness (either A or B can be

executed, but not both);

• Negation Templates: a negated version of the re-

lational templates (B cannot be executed after A).

In this work, we employed an alternative interface

based on the DECLARE framework and the ConDec

language (Pesic, 2008). Although we intended to use

DECLARE as a modeling tool, initial tests with a

real business case revealed a number of weaknesses

DeclarativeVersusImperativeBusinessProcessLanguages-AControlledExperiment

395

in the tool that prevented us to employ it in the ex-

periment (for example, LTL suffers from state-space

explosion when the number of rules grows, so mak-

ing DECLARE unsuitable). Therefore, we employed

another tool, called Kinetic Process, that was devel-

oped by our research group. This tool provides an in-

terface for the creation and management of business

rules based on the same templates of DECLARE, but

not relying on LTL for its implementation.

3 EXPERIMENT SCENARIO

The objective of the experiment presented in this pa-

per is to compare workﬂow and declarative approach

in terms of correctness and ﬂexibility of their models.

The main questions we want to answer are:

• How easy is to model a declarative process, when

compared to traditional workﬂow?

• Do declarative models successfully cope with un-

expected situations where the workﬂow fail?

• Are workﬂows better than declarative models in

preventing the execution of wrong paths?

These three questions are conceived in terms of

modeling effort, adaptation effort (effort required to

change the model when it is not able to deal with an

unexpected situation), and excess ﬂexibility. The ef-

fort is measured by the time necessary for executing

the corresponding task. The level of ﬂexibility is cap-

tured through the execution of use cases that address

different degrees of ﬂexibility. Very predictable use

cases do not require ﬂexibility and should be success-

fully executed by both approaches. Use cases that

represent more unexpected situations test for the pres-

ence of ﬂexibility, while use cases that present wrong

paths tests for the excess of ﬂexibility.

The unexpected situations are use cases that are

likely to be foreseen only by experts in the business.

The experiment subjects are students with no previ-

ous experience with business process. Therefore, al-

though these situations were known in advance by

us, there was a large probability of them being un-

expected by the modelers.

3.1 Experiment Design

In the context of controlled experiments design guide-

lines (Wohlin et al., 2000), we set up our experiment

as a single factor (business process requirements)

with two treatments (Workﬂow or Declarative mod-

eling). The experiment was conducted in the second

semester of 2011.

The experiment was designed as follows:

Subjects: the subjects of this experiment are

post-graduating students of the Center for Informatics

(CIn) at Federal University of Pernambuco (UFPE),

Brazil. Forty students from a BPM discipline where

initially selected. These students had no previous ex-

perience with business process modeling. They re-

ceived training in each of the two approaches. Af-

ter the training stage, we evaluate their knowledge in

each approach by tests. The subjects were then split

into two groups based on these tests results.

Object: a single process is implemented by the

subjects. We selected a set of requirements from a

software development company. This is a ﬁeld recog-

nized to be complex and highly uncertain. A group of

three specialists validated the requirements. They an-

alyzed if the requirements are fair enough to be mod-

eled in both approaches. Additionally, ﬁve test cases

were created to verify the degree of ﬂexibility of the

models. The test cases 1, 2, and 3 are obligation sce-

narios, i.e., represent situations which models should

accept. These cases present increasingly degree of un-

expectedness. The last two test cases are prohibition

scenarios, i.e., represent unacceptable situations ac-

cording to the business process requirements.

Metrics: We used three types of metrics to sup-

port the comparison between the approaches. Accord-

ing to Golden and Powell (Golden and Powell, 2000),

ﬂexibility is the property of being able to adapt. This

notion can be explained by two dimensions: 1) time

demanded to adapt to unforeseen situations; 2) range

of options available in responding to environmental

change. We assume that the second dimension im-

pacts the ﬁrst one since models that provide a wider

range of possibilities need less changes, and so, they

are faster to adapt. Therefore, a ﬂexible model can

be described as a model which people can modify in

relatively short order (Leonardi, 2011). Based on this

ﬂexibility concept, we selected the metrics below:

• Correctness Metrics: indicate whether the de-

signed model is suitable or not to the business pro-

cess requirements;

• Modeling Effort Metrics: indicate the effort de-

manded to model the business process;

• Flexibility Metrics: indicate whether the de-

signed model is easy to adapt in order to cope with

unexpected situations (test cases);

Dependent Variables: We measure the efforts re-

quired by each approach in terms of the variables

shown in Table 1. Each variable has two versions, one

for the workﬂow group and other for the declarative

group. When we need to differentiate these groups,

we add a subscripted ’W’ or ’D’ letter to the variable

symbol, referring to Workﬂow values or Declarative

ICEIS2014-16thInternationalConferenceonEnterpriseInformationSystems

396

Table 1: Dependent variables.

Symbol Variable Description

RCT Ratio of

Correct

Require-

ments

Percentage of require-

ments that were cor-

rectly included in each

model.

DT Drafting

Time

Time to study the re-

quirements and create

a draft of the process

model.

MT Modeling

Time

Time to implement the

model using the soft-

ware tool.

Time to

Adapt the

Model to

Test Case

Time to modify the

model if it does not

correctly process the

test case n, where

n = 1, . . . , 5 .

Table 2: Hypotheses.

Null Hypothesis Alternative Hypothesis

: RCT

≃ RCT

: RCT

6= RCT

: DT

≃ DT

: DT

6= DT

: MT

≃ MT

: MT

6= MT

: TA

≃ TA

: TA

6= TA

: TA

≃ TA

: TA

6= TA

: TA

≃ TA

: TA

6= TA

: TA

≃ TA

: TA

6= TA

: TA

≃ TA

: TA

6= TA

values, respectively.

Treatment: The experiment has two treatments:

a) modeling the process using the BizAgi tool, corre-

sponding to the Workﬂow approach; b) modeling the

process using the Kinetic tool, corresponding to the

Declarative approach.

Instrumentation: We used a laboratory with the

tools preinstalled to conduct the experiments. At the

beginning of the experiment, the subjects received

print copies of the requirements. To measure their

performance, the students used a chronometer soft-

ware and an electronic spreadsheet to annotate their

modeling times. Along the experiment, supervisors

observed the correct use of these tools by the students.

Hypothesis Deﬁnition: The hypotheses deﬁned

in Table 2 are being tested in this experiment.

3.2 Threats to Validity

Internal Validity: The participants selected for this

experiment had no previous knowledge on workﬂow

modeling or declarative modeling. They received 12h

of training in each approach. By this way, we avoid

any bias caused by prior experienceswith an approach

or another. After the training, we applied a test to

evaluate the knowledge of the students. We employed

statistical methods to deﬁne two classes of students

according to the approach they performed better in

the test. Firstly, we assigned points to each right an-

swer in the tests, which deﬁned their grade in the test.

Then, we classiﬁed the students into four ranks, ac-

cording to the quartiles of the distribution of their

grades. Finally, we combined the ranks in each ap-

proach and mapped this combined rank to the inter-

val [-1;1]. Students that were equally capable in both

approaches are those who got placed near the point

zero. Students that showed tendency to the declarative

approach got placed over the negative interval, while

students with tendency to the workﬂow approach got

placed over the positive interval. In this process, ap-

proximately50% of the students lied overthe negative

interval and other 50% lied over the positive interval,

showing no predetermined tendency to any of the ap-

proaches. This enabled us to split the subjects into

two highly balanced groups.

External Validity: a concern in the experiment is

that the results may be applicable only to the subjects

that participated in the experiment or for the tools

used. We consider that the results are valid for people

not experienced with process modeling. We cannot

draw conclusions on whether an expert in workﬂow

can outperform an expert in declarative modeling or

vice-versa. Anyway, as the subjects have no previous

experience, we can have a better grasp of the difﬁcul-

ties in modeling processes with one approach or the

other, which could be hidden by the knowledge of ex-

perts.

Construct Validity: we designed the experiment

so that we can separate the task of creating the models

from the task of implementing these models in a mod-

eling tool. This was necessary in order to separate the

effects of using a particular tool for process modeling

from the effects of using the modeling approach itself.

Therefore, we measured drafting time separated from

model implementation time. The drafts were designed

by the subjects using pen and papers and were lim-

ited to the constructs available in each modeling ap-

proach. This also reduces inﬂuences from the ability

of the subjects to manipulate that particular software

tool. Our concern is to assure that only the choice of

approaches is inﬂuencing the results, not the choice

DeclarativeVersusImperativeBusinessProcessLanguages-AControlledExperiment

397

of tools.

Conclusion Validity: we employ well-known t-

test in order to compare the signiﬁcance of the dif-

ferences observed between the variables measured in

each treatment. By this way, we avoid drawing con-

clusions when the data is not statistically signiﬁcant.

4 EXPERIMENT EXECUTION

We explained the scenario of the software develop-

ment company used as source for the requirements.

We explained the process’ objectives and provided

the roles involved. Each student received their own

printed copy of the business requirements. We asked

the students to read the document and then start to

model a draft of the process in paper. The drafting

time (DT) measures the time required to create such

draft model. Each student that ﬁnished the draft was

asked to start modeling the draft in the modeling soft-

ware. The modeling time (MT) measures the time re-

quired to translate the draft model into the modeling

software format.

The experiment continued by giving each student

a printed description of test cases to evaluate their

model. When the model did not pass on a test case,

we measured the time to ﬁx the problem.

4.1 Data Analysis

We computed the mean and standard deviation of the

dependent variables. We employed the t-test with

95% to compare the workﬂow and declarative ap-

proaches and evaluate the hypotheses deﬁned for this

experiment.

5 RESULTS

This section presents the results obtained from this

experiment. We describe the statistical measures col-

lected during the experiment and discuss the results.

5.1 Model Correctness

We extracted fourteen requirements from the business

process description. The number of requirements the

model fulﬁlls deﬁnes its level of correctness. The list

of requirements comprises one initial activity require-

ment (determining which activity should start the pro-

cess), eight obligations and ﬁve prohibitions. To be

100% accurate, a model should fulﬁll all fourteen re-

quirements. The results are as follows:

DeclarativeWorkflow

1,0

0,8

0,6

0,4

0,2

0,0

D W

Draftingtime

(a) Drafting Time

1,0

0,8

0,6

0,4

0,2

0,0

DeclarativeWorkflow

1,2

1,0

0,8

0,6

0,4

0,2

0,0

D W

Modelingtime

(b) Modeling Time

DeclarativeWorkflow

1,0

0,8

0,6

0,4

0,2

0,0

D W

TestCase1adjustingtime

DeclarativeWorkflow

1,0

0,8

0,6

0,4

0,2

0,0

D W

TestCase2adjustingtime

(d) Adjustments for Case 2

DeclarativeWorkflow

1,0

0,8

0,6

0,4

0,2

0,0

D W

TestCase3adjustingtime

(e) Adjustments for Case 3

DeclarativeWorkflow

1,0

0,8

0,6

0,4

0,2

0,0

D W

TestCase4adjustingtime

(f) Adjustments for Case 4

DeclarativeWorkflow

1,0

0,8

0,6

0,4

0,2

0,0

D W

TestCase5adjustingtime

(g) Adjustments for Case 5

Figure 1: Comparison of measures.

ICEIS2014-16thInternationalConferenceonEnterpriseInformationSystems

398

• Workﬂow: the Workﬂow group adequately mod-

eled a number of 9.38 requirements in average, or

67% of total requirements;

• Declarative: the Declarative group correctly

modeled 8.4 requirements in average, or 60% of

total requirements.

Notice that these numbers reﬂect the averagequal-

ity of the models, not the number of correct models.

We compared the distributions of the total number

of correct requirements in each group using the Stu-

dent’s t-test with 95% conﬁdence. The test showed

no statistical difference between the two approaches.

Therefore, the null hypothesis H1

could not be re-

jected. This indicates that no advantage to a partic-

ular approach is observed with respect to the model

correctness analysis.

5.2 Modeling Effort

We measured the modeling effort through the time re-

quired to write the model draft plus the time to trans-

late it into the corresponding software representation.

The results showed no statistically signiﬁcant differ-

ence between the two approaches (see Fig. 1(a) and

Fig. 1(b)). The average time required to write the draft

for the workﬂow model was 12minutes (standard de-

viation of 6 minutes), while the declarative version

had an average time of 15 minutes (standard devia-

tion of 9 minutes). Using the tools, the modeling time

for Workﬂows was of 54 minutes (std. dev.: 28 min.),

while for Declarative models was of 58 minutes (std.

dev.: 28 min.). As the results presented statistical

equivalence both between the drafting times and be-

tween the modeling times, we can infer that the tools

employed by this study had no inﬂuence on the com-

parison. Therefore, hypotheses H2

and H3

were

both accepted with 95% conﬁdence.

5.3 Flexibility

We analyzed the ﬂexibility through the execution of

test cases. These test cases were incrementally ap-

plied, i.e., the next test was applied only after the cur-

rent test case had passed. Hence, it is anticipated that,

while correcting a model in order to pass in a certain

test case, the participant could hasten corrections of

problems that would be found in upcoming test cases.

In this study, we measure ﬂexibility through the

time necessary to adapt the model to deal with un-

expected situations (Leonardi, 2011). Figures 1(c)

through 1(g) show the measures that reﬂect the ef-

fort to adapt the models to each test case imposed

to the subjects. The mean and standard deviation of

these variables are described in Table 3. Among these

ﬁve variables, the TA

is the only one which presents

a statistical difference between workﬂow and declar-

ative approach. The efforts employed by the two

groups to adapt their models to the other test cases

(1, 2, 4,and 5) are not statistically distinguishable.

Regarding the ﬂexibility, hypothesis H4

, H5

, H7

and H8

were accepted. Only hypothesis H6

was

rejected with 95% conﬁdence.

These results indicate that the approach taken has

low inﬂuence on the effort to achieve the process ﬂex-

ibility.

To further investigate the circumstances at which

these results were obtained, let us discuss the tests in

more detail.

We conceived the ﬁve test cases to test different

levels of ﬂexibility. Case 1 is the most predictable

scenario. All models should have equal chance to

successfully process this case. Cases 2 and 3 present

more unpredictable scenarios. Models that success-

fully cope with these two or that require lower efforts

to be adapted to cope with them are considered to be

more ﬂexible. Cases 4 and 5 present wrong scenar-

ios, i.e., scenarios where the process requirements are

violated. Models should not let cases 4 and 5 pass

the test. Models that do let are considered excessively

ﬂexible. They also need to be adapted to correct the

failures that let these wrong scenarios to occur.

Table 3: Flexibility variables measures.

Variable Mean Std. Dev. Hyp.

0:03:21 0:04:04 H4

0:04:07 0:05:35 not rejec.

0:11:39 0:09:08 H5

0:05:50 0:05:01 not rejec.

0:03:03 0:03:12 H6

0:08:30 0:06:34 rejected

0:05:02 0:03:27 H7

0:09:32 0:11:46 not rejec.

0:05:04 0:04:54 H8

0:04:43 0:05:27 not rejec.

Figure 2 shows a graphical comparison of the

number of models that correctly handled the situa-

tions proposed (passing on test cases 1 through 3 and

not letting cases 4 and 5 pass).

Observe that test case 1 tests for a very common

situation in the process. But, as this was the ﬁrst test

of the models, they were expected to show initial er-

rors. Declarative models were more successful at this

stage, with 30% of models being correct, against only

DeclarativeVersusImperativeBusinessProcessLanguages-AControlledExperiment

399

20%

40%

60%

80%

100%

Case1

(default)

Case2

(flexibility)

Case3

(flexibility)

Case4

(excess

flexibility)

Case5

(excess

flexibility)

Numberofmodelsthateffectively

processthetestcases

Declarative

Workflow

Figure 2: Flexibility tests.

11.8% of the Workﬂow models.

Test case 2 presents a situation with higher prob-

ability of being unexpected. This assumption showed

to be true. Although the subjects had adjusted their

models to case 1, most subjects failed to foresee the

scenario of case 2. As a result, the success ratio

dropped off signiﬁcantly, with only 15% of correct

Declarative models and no correct Workﬂow models.

Similar situation occurred for test case 3. But this

time, Workﬂows and Declarative models presented

closer results.

Regarding the excess of ﬂexibility, Figure 2 shows

that the Declarative group also achieved better results

than the Workﬂow group at test cases 4 and 5. As

the Workﬂow group made many adjustments to make

their models more ﬂexible, they also suffered from

excess of ﬂexibility, which is a counter-intuitiveresult

given that Workﬂows are presumed to be too rigid.

Despite the Declarative group showed higher

quality in these tests when compared to the Work-

ﬂow group, all models required adjustments. How-

ever, the efforts required to adjust the models do not

reﬂect the differences perceivedin the accuracy of the

models. Indeed, the efforts were equivalent even if

the Workﬂow models were less adequate to process

the test cases than the Declarative models. In the sin-

gle case where the quality of the models match (test

case 3), the Workﬂows required signiﬁcantly less ef-

fort to adjust than the Declarative models.

These results suggest that Workﬂow models are

easier to adjust than Declarative models.

6 RELATED WORK

Several works discuss the beneﬁts of using alterna-

tive, more ﬂexible approaches to business process

modeling (Pesic, 2008; Lu and Sadiq, 2007; Nurcan,

2008).

Reijers et al. (H. Reijers and van der Aalst, 2003)

perform a comparison between the features provided

by traditional Workﬂows and by Case-Handling Sys-

tems (CHS), which are a data-driven, case centric ap-

proach to business process design. In CHS, the em-

ployees are able to skip and redo activities and only a

preferred execution ﬂow needs to be modeled. After

a thorough review of workﬂow and CHS characteris-

tics, the authors conclude that CHS are not universally

superior to Workﬂows, and that a number of exten-

sions to current workﬂow technology would make it

equate CHS beneﬁts.

Few works conduct experiments for quantitatively

comparing ﬂexible approaches among each other or

against Workﬂow. Mutschler et al. (Mutschler et al.,

2008) present an experiment for comparing CHS

and Workﬂow technologies. The results of their ex-

periment indicate that Workﬂow technology requires

less effort for business process implementation when

compared to CHS. Moreover, subsequent process

changes require signiﬁcantly less effort than the ini-

tial implementation. However, no general conclusion

can be derived about the strengths and weaknesses of

Workﬂow and CHS technologies.

Weber et al. (Weber et al., 2009) conduct an ex-

periment where they measure the capability of end-

users to cope with increasing number of constraints

in declarative process models. Using the Alaska sim-

ulator as the declarative process modeling and exe-

cution tool, they found no evidence of performance

difference when the experiment subjects had to han-

dle substantially varying levels of constraints. Pichler

et al. (Pichler et al., 2011) compare imperative and

declarative languages with respect to process model

understanding. Their study ﬁnds that imperativemod-

eling languages are easier to understand.

7 SUMMARY AND

CONCLUSIONS

This paper describes a controlled experiment con-

ducted to compare two approaches for business pro-

cess modeling: workﬂow and declarative. The sub-

jects had the task of modeling a business process from

a set of requirements obtained from a real company.

A total of 40 students participated in the experiment.

Although proponents of the declarative approach

claim that declarative models are better prepared to

deal with situations not expected by the modeler, no

evidence to support this claim was observed in our ex-

periment. Indeed, Workﬂows showed to require less

effort to adapt to at least one of the test cases proposed

during the experiment.

It is worth notice that related work comparing

other features of ﬂexible business process technolo-

ICEIS2014-16thInternationalConferenceonEnterpriseInformationSystems

400

gies and Workﬂows also did not ﬁnd signiﬁcative dif-

ferences between the approaches (Weber et al., 2009;

Mutschler et al., 2008) or did ﬁnd an advantage in fa-

vor of the imperative approach (Pichler et al., 2011).

A strength of the present study is the high level of

balance between the two groups of subjects that par-

ticipated in the experiment, highly reducing any bias

caused by differences in the expertise of the partici-

pants of each group. Furthermore, we removed bias

from the use of the selected software tools, by asking

the subjects to design the models on a paper before

implementing them on the tool and measuring their

efforts in both tasks.

A limitation of the experimentcan be related to the

size of the scenario. Once the complexity of the sce-

nario is limited, it may be the case that the Workﬂow

approach has not showed its most prominent prob-

lems as argued by ﬂexibility researchers. Neverthe-

less, we noticed that, as the scenario becomes more

complex, both approaches require more maintenance

effort. Students that use the Declarative models of-

ten report difﬁculties in dealing with the growth of

the number of rules, which is something that is likely

to occur in real settings. Thus, we foresee that more

complex scenarios would not beneﬁt the Declarative

approach.

ACKNOWLEDGEMENTS

This work was partly supported by the Brazilian Re-

search Council (CNPq), grants PQ 314539/2009-3

and GD 140512/2009-8.

REFERENCES

Coalition, W. M. (1995). WfMC standards: The workﬂow

reference model, version 1.1.

Dadam, P., Reichert, M., Rinderle, S., Jurisch, M., Acker,

H., G¨oser, K., Kreher, U., and Lauer, M. (2008). To-

wards truly ﬂexible and adaptive process-aware in-

formation systems. In Kaschek, R., Kop, C., Stein-

berger, C., and Fliedl, G., editors, UNISCON, vol-

ume 5 of Lecture Notes in Business Information Pro-

cessing, pages 72–83. Springer.

Golden, W. and Powell, P. (2000). Towards a deﬁnition

of ﬂexibility: in search of the holy grail? Omega,

28:373–384.

H. Reijers, J. R. and van der Aalst, W. (2003). The case

handling case. International Journal of Cooperative

Information Systems, 12(3):365–391.

Jeston, J. and Nelis, J. (2006). Business Process Man-

agement : Practical Guidelines to Successful Imple-

mentations. Elsevier/Butterworth-Heinemann, Ams-

terdam.

Leonardi, P. M. (2011). When ﬂexible routines meet ﬂexible

technologies: Affordance, constraint, and the imbrica-

tion of human and material agencies. MIS Quarterly,

35(1):147–167.

Lu, R. and Sadiq, S. (2007). A survey of comparative busi-

ness process modeling approaches. In In Proceedings

10th International Conference on Business Informa-

tion Systems (BIS), number 4439 in LNCS, pages 82–

94. Springer.

Modeler, B. P. (2010). Bizagi: Bpmn software.

Mutschler, B., Weber, B., and Reichert, M. (2008). Work-

ﬂow management versus case handling: results from a

controlled software experiment. In Proceedings of the

2008 ACM symposium on Applied computing, SAC

’08, pages 82–89, New York, NY, USA. ACM.

Nurcan, S. (2008). A survey on the ﬂexibility requirements

related to business processes and modeling artifacts.

In HICSS ’08: Proceedings of the 41st Annual Hawaii

International Conference on System Sciences, page

378, Washington, DC, USA. IEEE Computer Society.

Pesic, M. (2008). Constraint-Based Workﬂow Manage-

ment Systems: Shifting Control to Users. PhD thesis,

Technische Universiteit Eindhoven, Eindhoven, The

Netherlands.

Pesic, M. and van der Aalst, W. M. P. (2006). A declarative

approach for ﬂexible business processes management.

In Eder, J. and Dustdar, S., editors, Business Pro-

cess Management Workshops, volume 4103 of Lecture

Notes in Computer Science, pages 169–180. Springer.

Pichler, P., Weber, B., Zugal, S., Pinggera, J., Mendling, J.,

and Reijers, H. A. (2011). Imperative versus declara-

tive process modeling languages: An empirical inves-

tigation. In BPM 2011 Workshops, Part I, LNBIP 99.

Springer-Verlag.

Weber, B., Reijers, H. A., Zugal, S., and Wild, W. (2009).

The Declarative Approach to Business Process Exe-

cution: An Empirical Test. In Proc. CAiSE ’09, pages

270–285.

WFMC (2002). Workﬂow management coalition work-

ﬂow standard: Workﬂow process deﬁnition interface

– XML process deﬁnition language (XPDL) (WFMC-

TC-1025). Technical report, Workﬂow Management

Coalition, Lighthouse Point, Florida, USA.

White, S. A. (2006). Introduction to bpmn. Technical re-

port, IBM Software Group.

Wohlin, C., Runeson, P., H¨ost, M., Ohlsson, M. C., Regnell,

B., and Wessl´en, A. (2000). Experimentation in soft-

ware engineering: an introduction. Kluwer Academic

Publishers, Norwell, MA, USA.

zur Muehlen, M. (2002). Workﬂow-Based Process Con-

trolling : Foundation, Design, and Application of

Workﬂow-driven Process Information Systems. Logos

Verlag, Berlin.

DeclarativeVersusImperativeBusinessProcessLanguages-AControlledExperiment

401