Embed Size (px)
Citation preview
Imperative versus Declarative Process ModelingLanguages: An Empirical Investigation
Paul Pichler1, Barbara Weber1, Stefan Zugal1, Jakob Pinggera1, JanMendling2, and Hajo A. Reijers3
1 University of Innsbruck, [email protected]
barbara.weber|stefan.zugal|[email protected] Humboldt-Universitat zu Berlin, Germany
[email protected] Eindhoven University of Technology, The Netherlands
Abstract. Streams of research are emerging that emphasize the advan-tages of using declarative process modeling languages over more tradi-tional, imperative approaches. In particular, the declarative modelingapproach is known for its ability to cope with the limited flexibility ofthe imperative approach. However, there is still not much empirical in-sight into the actual strengths and the applicability of each modelingparadigm. In this paper, we investigate in an experimental setting ifeither the imperative or the declarative process modeling approach issuperior with respect to process model understanding. Even when tasktypes are considered that should better match one or the other, our studyfinds that imperative process modeling languages appear to be connectedwith better understanding.
Key words: Imperative and Declarative Business Process Models, Cog-nitive Dimensions Framework, Empirical Research.
1 Introduction
At the present stage, formal properties of business process models like livenessand boundedness are quite well understood [1]. In contrast to these aspects, weknow rather little about theoretical foundations that might support the superi-ority of one process modeling language in comparison to another one. There areseveral reasons why suitable theories are not yet in place for language design,most notably because the discipline is still rather young. Only little researchhas been conducted empirically in this area so far, e.g., [2, ?] which relate modelunderstanding to the modeling language and to model complexity.
The lack of empirical research on language quality has contributed to a no-table, continuous invention of new techniques and to the claims on the supposedsuperiority. For instance, Nigam and Caswell introduce the OpS technique inwhich “the operational model is targeted at a business user and yet retains the
2 Paul Pichler et al.
formality needed for reasoning and, where applicable, automated implementa-tion” implying that existing languages fall short on these characteristics [3, p.429]. In a Poplin white paper, Owen and Raj claim a general superiority of onemodeling language over another, i.e., BPMN over UML Activity Diagrams, be-cause “[BPMN] offers a process flow modeling technique that is more conduciveto the way business analysts model” [4, p.4]. As a final example, Smith and Fin-gar state in their book that “BPML is the language of choice for formalizingthe expression, and execution, of collaborative interfaces” [5, p.205]. We do notwant to judge on the correctness of these statements here. Rather, we wish toemphasize that a clear and objective baseline to judge such claims is in demand.
The matter of understanding is well-suited to serve as a pillar for discussingprocess modeling language quality. Insights from cognitive research on program-ming languages point to the fact that ‘design is redesign’ [6]: A computer programis not written sequentially; a programmer typically works on different chunks ofthe problem in an opportunistic order which requires a constant reinspection andcomprehension of the current work context. If we assume that process modelersdesign their models in a similar fashion, we clearly have to accept the importanceof understanding as a quality factor. In other words, characteristics of a processmodeling language presumably facilitate comprehension to differing degrees ina particular context.
To investigate whether process modeling languages actually offer differentlevels of support for sense-making, we will necessarily need to limit our scope.One of the important watersheds that exists between process modeling languagesis the one between imperative and declarative process modeling languages. Forthe recently developed ConDec, a declarative process modeling language, its firstdesign criterion has been that “the process models developed in the language mustbe understandable for end-users” [7, p.15]. While it is claimed in the same workthat imperative languages, in comparison, deliver larger and more complex pro-cess models, only anecdotic evidence is presented to support this. Also, in thepractitioner community opinions are manifold about the advantages of declar-ative and imperative languages to capture business processes, see for example[8, ?,?]. These claims and discussions clearly point to the need for an objective,empirically founded validation of the presumed advantages of the different typesof process modeling languages, which motivates the scope of our research.
The contribution of this paper is that it empirically examines if either imper-ative or declarative process models are superior with respect to understandingmatters. To this purpose, we will test a set of theoretically grounded propositionsabout the differences between the imperative and declarative process modelingapproach. The paper is structured as follows. Sect. 2 provides the background forour research. Sect. 3 describes the experimental definition and planning, coveringthe experimental setup and design. Sect. 4 presents the experimental executionand the analysis of collected data. Furthermore, the results are discussed in thissection. Sect. 5 concludes the paper by providing a summary and an outlook.
Imperative versus Declarative Process Modeling Notations 3
2 Background
The differentiation between imperative and declarative languages has its rootsin computer programming. Imperative programming implies to “say how to dosomething” [9, p.406], whereas declarative programming implies to “say whatis required and let the system determine how to achieve it” [9, p.406]. Similarto imperative programming, imperative process modeling is characterized bya so-called ‘inside-to-outside’ approach. It primarily specifies the procedure ofhow work has to be done. Simply put, imperative modeling languages requireall execution alternatives to be explicitly specified in the model before the exe-cution of the process. All new alternatives must be added to the model duringbuild-time. It is argued that this results in process models being over-specified[7]. Declarative process modeling, by contrast, is referred to as an ‘outside-to-inside’ approach. In contrast to imperative languages, declarative languages donot specify the procedure a priori. Instead of determining how the process hasto work exactly, only its essential characteristics are described. Adding new con-straints to the model limits the number of execution alternatives [7]. This maybe understood as follows: Initially, only the process activities are in the model,allowing every possible execution behavior. By adding constraints to the model,execution alternatives are discarded step by step. Figure 1 shows an example ofa declarative process model consisting of three activities A, B, and C and twoconstraints. The constraint attached to activity C specifies that it has to be exe-cuted at least once. The constraint between activities A and B requires that theexecution of activity B is preceded by activity A. Except for these restrictions,the activities in the model can be executed arbitrarily often and in any order.
A B
C
1..*
Fig. 1. Declarative Process Model
Clearly, the above mentioned claims need to be substantiated in terms ofappropriate theories. The Cognitive Dimensions Framework (CDF) offers a ref-erence for discussing and evaluating various types of notations based on theircognitive effectiveness [10]. Its development is based on the ‘mental operationstheory’ [6], which in essence states that a notation performs better if fewer mentaloperations are required to perform a task. In this way, a “matched pair” betweenparticular, notational characteristics and a specific task gives the best perfor-mance. This view has evolved and matured over the years towards the CDF [10,?], which contains many different characteristics to distinguish notations fromeach other. In particular, the dimensions hard mental operations (to understanda model) and hidden dependencies (between notation elements) directly applyto process modeling understanding [10].
4 Paul Pichler et al.
In line with the CDF, different notations should be judged relatively, i.e.,in terms of their aptitude towards different types of understanding tasks. “Anotation is never absolutely good, therefore, but good only in relation to certaintasks” [10, p.3]. In this vein, it seems appropriate to investigate whether impera-tive languages are better understandable with tasks containing a particular typeof information and declarative languages with tasks containing another type ofinformation [10]. For such a distinction, the classification between sequential andcircumstantial information is relevant.
Sequential information explains how input conditions lead to a certain out-come. An example of a statement containing sequential information is: “ActivityX must be directly preceded by activity Y”. As this example demonstrates, se-quential information often concentrates on what actions could be either next orprevious in a model [6]. In other words, sequential information typically relatesto actions immediately leading to or following from a certain outcome. On theother hand, circumstantial information, given an outcome, relates to the overallconditions that produced that outcome. An example of a statement containingcircumstantial information is: “If activity X or Y has been executed, it is possibleto terminate a process instance by executing at least one additional activity”. Asthis example demonstrates, circumstantial information frequently corresponds towhat (combination of) circumstances will cause a particular outcome or action[6]. In this context, circumstantial information typically relates to conditionsthat have or have not occurred.
Empirical evidence has already been established that imperative program-ming languages display sequential information in a readily-used form, whiledeclarative languages display circumstantial information in a readily-used form[6]. Based on the similarities between software programs and process models, itmay be assumed, therefore, that a similar, relativist viewpoint could also providea theoretical basis for the comparison of imperative versus declarative processmodeling languages [11]. Consequently, the following set of propositions may beadvanced, which are in line with those proposed in an earlier paper [11]:
P1. Given two semantically equivalent process models, establishing sequentialinformation will be easier on the basis of the model that is created with theprocess modeling language that is relatively more imperative in nature.
P2. Given two semantically equivalent process models, establishing circumstan-tial information will be easier on the basis of the model that is created withthe process modeling language that is relatively more declarative in nature.
To test these expectations, we will next describe an experimental design forthat purpose.
3 Experimental Definition and Planning
This section introduces the hypotheses, describes the subjects, objects, factors,factor levels and response variables of our experiment. It will also present the
Imperative versus Declarative Process Modeling Notations 5
instrumentation, data collection procedure, and experimental design. Finally,the parameters we controlled for in our experiment are discussed.
Factor and Factor Levels. The considered factors were model type and tasktype, with two factor levels each. For the model type factor, we considered thefactor levels of imperative and declarative. For the task type factor, we consideredthe factor levels sequential versus circumstantial.
Subjects. Students enrolled in classes on business process management wereparticipating as subjects in the experiment.
Objects. In preparation for the experiment, four semantically equivalent pro-cess model pairs were created4. Semantic equivalence was ensured by testingvalid traces based on both model variants. BPMN was used to create the im-perative models, and ConDec to create the declarative models. Both imperativeand declarative process models were created considering the following criteria:1) Correctness, 2) Executability and 3) Representativeness. Correctness is theprecondition of executability, a characteristic of understandable process modelsdefined by the SEQUAL Framework [12]. For imperative models soundness andstructuredness were considered as correctness notions [13]. For declarative mod-els, in turn, absence of dead activities and conflicts was required [7]. To ensureexecutability we transformed the imperative models to Petri nets allowing us toapply the token game. For declarative models, in turn, we tested executabilityusing the in-built verification functionality of DECLARE [7]. To ensure con-tent validity, i.e., the representativeness of the experimental objects, we ensuredthat the four model pairs covered the core concepts of both the imperative anddeclarative paradigm. Imperative process models covered the five basic controlflow patterns (i.e., sequence, exclusive choice, simple merge, parallel split andsynchronization) [14] as well as loops. Declarative models, in turn, covered allmajor constraint groups (i.e., existence, relation and negation constraints [15]).
Tasks. For each of the model pairs, i.e., a declarative versus an imperativemodel, four sequential and four circumstantial tasks had to be created (compris-ing understandability questions) considering the following criteria: 1) Typicalconstructs, 2) Model parts, 3) Difficulty and 4) Consistency. To maintain con-tent validity it had to be ensured that the experimental tasks cover all relevantaspects of understandability for each modeling language. In [16], the four con-structs order, concurrency, exclusiveness, and repetition are mentioned as beingcrucial for the understanding of imperative process models and were thereforeconsidered for creating the sequential tasks. Circumstantial tasks, in turn, wereadjusted in terms of the constraints groups which determine declarative repre-sentativeness (i.e., existence, relation, and negation constraints).
Sequential information usually affects local parts of a process model [17].Consequently, sequential tasks were formulated with reference to local actions(e.g., next or previous) in the model. Contrary to sequential information, cir-cumstantial information tends to affect the process model rather globally [17].Therefore, circumstantial tasks were formulated such that they ask for (the com-
4 The material used for this study can be downloaded from:http://barbaraweber.org/experiments/2010_Declarative_vs_Imperative.pdf
6 Paul Pichler et al.
bination of) circumstances that caused or will cause a particular action withinthe process. To establish a balanced level of difficulty among the experimentaltasks, and hence avoid that tasks which are either too easy or too difficult impactthe result of the experiment, a pre-test was conducted. To ensure that only theinformation captured by the tasks is of relevance for the experimental outcome,the tasks were formulated consistently in respect of their structure and the useof terms.Response Variables. To compare declarative and imperative modeling lan-guages we defined the following response variables: 1) accuracy as measured bythe number of correctly answered questions (tasks) and 2) speed by measuringthe time needed to complete the tasks. Since four sequential and four circum-stantial tasks had to be completed for each model pair, accuracy values couldrange between 0 and 4 for sequential and circumstantial tasks respectively.Hypotheses. A statistical test with two factors is always associated with threenull hypotheses [18], one for each factor and one for the interaction between thefactors:
– Null Hypothesis H1: There is no significant difference in the performance(in terms of accuracy and speed) of imperative and declarative models.
– Null Hypothesis H2: There is no significant difference in the performance(in terms of accuracy and speed) of sequential and circumstantial tasks.
– Null Hypothesis H3: There is no significant interaction between the factormodel type and the factor task type (in terms of accuracy and speed).
Parameters. In addition to the described factors other variables can affectthe response variables under examination and therefore need to be controlled[19]. For this experiment we considered three main parameters that can influ-ence the understandability of process models, i.e., model characteristics, domainknowledge and personal factors [20]. Model characteristics we controlled involvedvisual layout and structural attributes. To control visual layout we maximizedsymmetry, minimized bends and minimized edge crosses for both model variants(i.e., imperative and declarative), since they are known factors which influencemodel understandability [21]. To control the structural attribute size, which hassignificant impact on model understandability [22], we had to ensure that theimperative and declarative variants have equal size. Consequently, to avoid sizerather than the used modeling paradigm dictating the outcome, the used modelpairs comprised two small and two large models for each factor level. Fig.2 showsan experimental model pair consisting of a small imperative and a small declar-ative model.
To eliminate the influence of domain knowledge, activities of the process mod-els were labeled with random letters. To control personal factors, the selectionof experimental subjects comprised preferably persons with uniform knowledgeregarding business process modeling. Nevertheless, the subjects had to completea questionnaire at the beginning of the experiment allowing us to analyze howpossible variations between the individual modeling knowledge influenced themodel understanding and quantify the distribution of modeling experience be-tween the imperative and declarative modeling approach.
Imperative versus Declarative Process Modeling Notations 7
X +
X X Z XX
X N X
L
+ X R X
Z
init 1
X
1..*
R
0..1
0..1
L
N
Fig. 2. Imperat. BPMN model (left) and equivalent, declarat. ConDec model (right)
Experimental Design. The experimental design is based on the guidelinesfor designing experiments from [19]. Following these guidelines, a randomized2x2 factorial experiment has been designed, which investigates the influence oftwo factors with two factor levels each. The experiment is called randomized,since subjects are assigned to groups randomly. Fig. 3 illustrates the describedsetup: Overall, the experiment comprised four model pairs. Depending on theirgroup, subjects either started with the imperative variant of Model Pair 1 orwith the semantically equivalent declarative variant. For two of the remainingmodel pairs, the levels of factor model type were switched for the two groups,i.e., overall, every subject worked on two declarative and two imperative processmodels. Regarding factor task type every subject worked on both factor levels(i.e., sequential and circumstantial tasks) for each model pair. To ensure inde-pendence of samples, both sequential and circumstantial tasks were presented ina random, and thus unique order to each subject.
Subjects
Group 2
n/2 Subjects
Group 1
n/2 Subjects
Model Pair 1
Experiment
Model P. 2 Model P. 3 Model P. 4
Factor 1
Level
1.2:
Imper.
Level
1.1:
Declar.
Factor 1
Level
1.1:
Declar.
Level
1.2:
Imper.
Factor 1
Level
1.2:
Imper.
Level
1.1:
Declar.
Factor 1
Factor Level 1.2:
Imperative
Factor Level 1.1:
Declarative
Factor 2
Factor Level 2.1:
Sequential
Factor Level 2.2:
Circumstantial
Factor Level 2.1:
Sequential
Factor Level 2.2:
Circumstantial
Objects
Declarative
Process Model
Imperative Process
Model
Fig. 3. Experimental Design
Instrumentation and Data Collection Procedure. The participants con-ducted the experiment using the Cheetah Experimental Platform [23], whichguided them through the experiment. The tool also automatically logged thegiven answers, as well as the time that was needed to accomplish the experimen-tal tasks.
8 Paul Pichler et al.
4 Performing the Experiment
This section deals with the experiment’s execution. Sect. 4.1 covers operationalaspects, i.e., how the experiment has been executed. Then, in Sect. 4.2 data isanalyzed and subsequently discussed in Sect. 4.3.
4.1 Experimental Operation
Experimental Preparation. Four semantically equivalent model pairs werecreated for the empirical test. Additionally, for each model pair a set of foursequential and four circumstantial tasks was developed (cf. Sect. 3). To ensurethe overall understandability of the experimental setup and a balanced degreeof difficulty, a pre-test was conducted.
Experimental Execution. The experiment was conducted in July 2010. Insum, 28 subjects from the Humboldt Universitat zu Berlin and the Universityof Innsbruck participated in this empirical test. Subjects had one week time tocomplete the experiment in an “offline” mode, i.e., they were not constantlymonitored.
Fig. 4 shows the structure of the experiment by means of a complete run: Eachstudent received a PDF file containing the introduction, hints for the experimentand troubleshooting as well as specific instructions on how to download andexecute it.5 Having downloaded the experiment, the subjects had to completethe questionnaire about their personal modeling knowledge and experience. Anexample followed providing the solution as well as the respective explanation toevery test task. During the experimental phase, the subjects had to completeeight tasks (four sequential and four circumstantial ones) for each of the fourmodels. A legend with the used modeling elements was attached to every processmodel.
Introduction Questionnaire Example Model 1 Model 2 Model 3 Model 4
Experiment PhaseIntroduction and Familiarization Phase
Fig. 4. The Structure of the Experiment
Data Validation. Once the experimental study was carried out, the loggeddata were analyzed regarding their consistency and plausibility. Finally, dataprovided by 27 students were used in our data analysis. Data from one studenthad to be removed because it was incomplete.
5 The version of CEP which was used for the experiment including the experimentalworkflow can be downloaded from:http://barbaraweber.org/experiments/2010_Declarative_vs_Imperative.zip
Imperative versus Declarative Process Modeling Notations 9
4.2 Data Analysis
In the following we describe the analysis and interpretation of data.
Descriptive Analysis. To give an overview of the experiment’s data, Table 1shows mean values and standard deviation for accuracy and speed.
Model Type Task Type N AccuracyMean(score)
AccuracyStd. Dev.
SpeedMean(min.)
Speed Std.Dev.
Declarative Sequential 54 2.61 1.14 2.216 1.13Circumst. 54 2.44 1.18 2.79 1.69
Imperative Sequential 54 3.26 0.89 1.91 0.98Circumst. 54 2.87 0.95 2.06 0.80
Declarative 108 2.53 1.16 2.50 1.46Imperative 108 3.06 0.94 1.98 0.89
Sequential 108 2.94 1.07 2.06 1.06Circumst. 108 2.66 1.10 2.43 1.37
Table 1. Descriptive Statistics
Hypotheses Testing. In a next step, the hypotheses introduced in Sect. 3were tested. The empirical test in this work was designed as a two-way factorialexperiment. Accordingly, a two-way factorial research design requires a statisticalanalysis method that allows the interpretation of both factors together (i.e.,(M)ANOVA). Since the requirements for the application of ANOVA were notsatisfied, we applied the Sheirer-Ray-Hare test, a non-parametric alternative forANOVA [18].
First we discuss the result of testing null hypothesis H3, since the effect ofa factor can be interpreted individually only when there is no evidence that itinteracts with another factor [19].
Null Hypothesis H3: With an obtained p-value (=significance value) of 0.45(>0.05), null hypothesis H3 cannot be rejected at a confidence level of 95%for the response variable of accuracy. Also, the results for the response variableof speed turned out to be insignificant (p-value of 0.37, >0.05). Hence, there isno statistically significant interaction between the factors model type and tasktype. Since there is no evidence of a significant interaction, the effect of the fac-tors can be interpreted individually [19].
Null Hypothesis H1: With an obtained p-value of 0.001 (<0.05), null hypothesisH1 has to be rejected for the response variable accuracy at a confidence level of95%. Hence, there is a statistically significant difference between the alternativesof the factor model type: Imperative models have a better performance in termsof accuracy than declarative models, regardless of the factor task type. With an
6 A lower number in terms of response variable “speed” implies a better result
10 Paul Pichler et al.
obtained p-value of 0.002 (<0.05), null hypothesis H1 has to be rejected for re-sponse variable speed. This result indicates that imperative models have a betterperformance in terms of speed than declarative models, regardless of the factortask type.
Null Hypothesis H2: With an obtained p-value of 0.06, which just exceeds the0.05 level, null hypothesis H2 cannot be rejected at a confidence level of 95%,i.e., there is no statistically significant difference between the alternatives of thefactor task type, i.e., sequential or circumstantial tasks, in terms of accuracy.Since there is the possibility that one type of process models is significantly betterperforming with one type of the tasks, and the other type of process models isnot, we additionally analyzed this hypothesis separately for each factor level offactor model type using the Mann-Whitney-U test. With an obtained p-valueof 0.02 (<0.05), a statistically significant difference between the alternatives ofthe factor task type could be established when imperative models are used, i.e.,sequential tasks compared to circumstantial tasks lead to a better performancein terms of accuracy when imperative models are used. For declarative models,in turn, with a p-value of 0.51 >0.05 no statistically significant results couldbe obtained. For the response variable of speed, null hypothesis H2 has to berejected (p-value of 0.01, <0.05): Sequential tasks compared to circumstantialtasks lead to a better performance in terms of speed than circumstantial tasks,regardless of the factor model type.
4.3 Discussion
The objective of this paper has been to investigate if either the imperative or thedeclarative process modeling approach is superior with respect to understandingmatters. The set-up for this investigation has been grounded on insights fromcognitive research on programming languages. Our findings suggest that imper-ative process models are significantly better understandable than declarativemodels, irrespective of the type of tasks involved (sequential vs. circumstantial).
This result, however, must be treated with care, since an ex-post analysis ofthe process modeling experience of our subjects revealed that the experimentalsubjects were rather familiar with imperative process modeling, but at best onlyto a limited extent to declarative modeling. Based on this imbalance, a subse-quent analysis was examined. This revealed that a learning effect for declarativemodels might have occurred during the experiment. Since this affects generaliz-ability of the results, replications regarding this research objective are requiredwith subjects having a more balanced level of familiarity for both modelingparadigms.
In addition to examining imperative versus declarative process models, ourgoal has been to test if the theoretical axioms of the CDF, which were originallyestablished for computer programming as part of extensive cognitive research,also apply to business process modeling. Based on the obtained data it could onlybe confirmed that tasks containing sequential information are better understand-able using imperative process models, but not that tasks containing circumstan-
Imperative versus Declarative Process Modeling Notations 11
tial information are better understandable using declarative models. Regardingthe response variable accuracy, sequential tasks were easier to understand usingimperative models. However, we could not confirm that circumstantial tasks areeasier to understand using declarative models. In terms of the response variablespeed, sequential tasks turned out to be better performing irrespective of thetype of model concerned.
We effectively conducted the experiment with a homogeneous group of stu-dents. Still, further potential limitations must be considered. In particular, therelatively low number of experimental subjects constitutes a limitation as testsconverge towards significant results with more subjects. Moreover, due to thesmall number of participants in the pre-test, it was not possible to conducta statistically significant reliability analysis on the internal consistency of thedifferent understandability tasks. Even though we tried to balance the level ofdifficulty with a pre-test, it cannot be entirely excluded that this issue mighthave influenced the experimental result. Another limitation regarding the gener-alizatbility of our results relates to the fact that our experiment only comparesone concrete modeling language representing each process modeling approach.
5 Summary and Outlook
In this paper, we compared the imperative process modeling approach with thedeclarative approach with reference to understanding based on insights from cog-nitive research on programming. Essentially, imperative process models turnedout to be more comprehensible than declarative process models, irrespective ofthe type of task involved. However, based on the imbalance of subjects’ familiar-ity with imperative and declarative process modeling, this result must be treatedwith care.
A further insight concerns the theoretical axioms of the Cognitive DimensionsFramework, stating that tasks containing sequential information are better un-derstandable using imperative languages, and tasks containing circumstantialinformation are better understandable using declarative languages. This couldbe confirmed partially. Apparently, sequential tasks are better understandable,regardless whether an imperative or declarative process model was used.
The most important direction for future research we identify would be toreplicate the experiment in a situation where the participants’ knowledge of andexperience with both imperative and declarative languages is less skewed. Onecan argue that this may be hard to establish, given the dominant emphasisin many settings on the use of imperative approaches, for example in academicprograms. A step forward here may be taken by involving people with no trainingor background at all in process modeling, who can be provided equal amountsof training time in both paradigms.
References
1. Reisig, W., Rozenberg, G., eds.: Lectures on Petri Nets I: Basic Models Advancesin Petri Nets. Volume 1491 of LNCS. Springer (1998)
12 Paul Pichler et al.
2. Recker, J., Dreiling, A.: Does It Matter Which Process Modeling Language WeTeach or Use? An Experimental Study on Understanding Process Modelling Lan-guages without Formal Education. In: Proc. ACIS ’07. (2007) 356–366
3. Nigam, A., Caswell, N.: Business artifacts: An approach to operational specifica-tion. IBM Systems Journal 42(3) (2003) 428–445
4. Owen, M., Raj, J.: BPMN and Business Process Management: Introduction tothe New Business Process Modeling Standard. Popkin (2003). Technical report,(whitepaper.talentum.com/whitepaper/view.do?id=7050)
5. Smith, H., Fingar, P.: Business Process Management: The Third Wave. Meghan-Kiffer Press (2003)
6. Gilmore, D.J., Green, T.R.: Comprehension and recall of miniature programs.IJMMS 21 (1984) 31–48
7. Pesic, M.: Constraint-Based Workflow Management Systems: Shifting Control toUsers. PhD thesis, TU Eindhoven (2008)
8. Korhonen, J.: Evolution of agile enterprise architecture (April 2006).(http://blog.jannekorhonen.fi/?p=11 (retrieved May 10, 2011))
9. Roy, P.V., Haridi, S.: Concepts, Techniques, and Models of Computer Program-ming. The MIT Press (2004)
10. Green, T.R.: Cognitive dimensions of notations. In: Proc. BCSHCI ’89. (1989)443–460
11. Fahland, D., Mendling, J., Reijers, H.A., Weber, B., Weidlich, M., Zugal, S.: Declar-ative versus Imperative Process Modeling Languages: The Issue of Understandabil-ity. In: Proc. EMMSAD ’09. (2009) 353–366
12. Krogstie, J., Sindre, G., Jørgensen, H.: Process models representing knowledge foraction: a revised quality framework. EJIS 15 (2006) 91–102
13. Mendling, J.: Metrics for Process Models: Empirical Foundations of Verification,Error Prediction, and Guidelines for Correctness. Springer (2008)
14. Russell, N., ter Hofstede, A.H.M., van der Aalst, W.M.P., Mulyar, N.: WorkflowControl-Flow Patterns. A Revised View. BPM Center Report (2006) 6–22
15. der Aalst, W.M.P.V., Pesic, M.: DecSerFlow: Towards a Truly Declarative ServiceFlow Languages. In: Proc. WS-FM’06. (2006) 1–23
16. Melcher, J., Mendling, J., Reijers, H.A., Seese, D.: On Measuring the Understand-ability of Process Models. In: Proc. BPM Workshops ’09. (2010) 465–476
17. Weidlich, M., Zugal, S., Pinggera, J., Fahland, D., Weber, B., Reijers, H.A.,Mendling, J.: The Impact of Sequential and Circumstantial Changes on ProcessModels. In: Proc. ER-POIS ’10. (2010) 43–54
18. Dytham, C.: Choosing and Using Statistics. A Biologist’s Guide. John Wiley &Sons (2003)
19. Juristo, N., Moreno, A.M.: Basics of Software Engineering Experimentation.Kluwer Academics Publisher (2001)
20. Mendling, J., Strembeck, M.: Influence factors of understanding business processmodels. In: Proc. BIS ’08. (2008) 142–153
21. Purchase, H.: Which Aesthetic has the Greatest Effect on Human Understanding?In: Proc. GD ’97. (1997) 248–261
22. Mendling, J., Reijers, H.A., Cardoso, J.: What Makes Process Models Understand-able? In: Proc. BPM ’07. (2007) 48–63
23. Pinggera, J., Zugal, S., Weber, B.: Investigating the process of process modelingwith cheetah experimental platform. In: Proc. ER-POIS ’10. (2010) 13–18
![DECEMBER 2018 Declarative or Imperative Language · Declarative or Imperative Language [Abraham John, Executive Director, AITS] ... declarative languages are typically cleaner, better](https://img.dokumen.tips/doc/110x75/5ec7e462e396e9508e214783/december-2018-declarative-or-imperative-language-declarative-or-imperative-language.jpg)
