=Paper= {{Paper |id=Vol-1917/paper30 |storemode=property |title=Workflow Flexibility by Deviation by means of Constraint Satisfaction Problem Solving |pdfUrl=https://ceur-ws.org/Vol-1917/paper30.pdf |volume=Vol-1917 |authors=Lisa Grumbach,Ralph Bergmann |dblpUrl=https://dblp.org/rec/conf/lwa/GrumbachB17 }} ==Workflow Flexibility by Deviation by means of Constraint Satisfaction Problem Solving== https://ceur-ws.org/Vol-1917/paper30.pdf

Workflow Flexibility by Deviation by means of
Constraint Satisfaction Problem Solving

Lisa Grumbach, Ralph Bergmann

University of Trier, Department of Business Information Systems II,
54286 Trier, Germany

Abstract. This paper introduces a novel approach for flexible workflow
management by applying constraint satisfaction problem solving. This
enables us to support workflow deviations at runtime, react to upcoming
events or unpredictable circumstances, but still support the user through
worklist suggestions. The developed workflow engine is completely based
on declarative workflow representations, whereas procedural languages
are used for workflow modeling.

1 Introduction

In small and medium-sized enterprises (SMEs) there is a strong demand for
support concerning management of documents, business data, and processes as
well as a need for supervision and control of all running and completed trans-
actions [14]. Especially for employees who are unaware of common processes, a
Process-Aware Information System (PAIS, [1]) would be of advantage, as they
may profit from guidance concerning ideal workflow execution and task sug-
gestion. Additionally, compliance concerning standards and guidelines would be
facilitated, as benefit for the enterprises. However, the use of PAISs has not yet
been broadly established in SMEs. A reason for this is that current PAISs con-
trol process execution by traditional workflow engines in which workflows are
prescribed without providing any flexibility to deviate, if necessary [5, 15]. This
is a particular problem in SMEs as their processes are only slightly standardized
and weakly structured and may vary significantly from case to case [9, 17].
Artificial Intelligence (AI) is a key technology for various support strategies
in Business Process Management (BPM), as it allows for automated decision
making and thus, facilitates the users work. Allowing flexibility requires such
intelligent technologies, as the user should only be guided executing a workflow
and not be burdened with taking difficult decisions that could be automated.
Declarative workflows are a means of implicitly offering flexibility but therefore
require technologies from the field of AI for workflow control. DECLARE [2] is a
tool suite for declarative workflow modeling and enactment. Declarative models
consist of constraints which define undesired behaviour. Constraints are then
transformed to finite-state automata which allow for reasoning about workflow
states. A drawback of this approach is that this transformation process is in-
efficient for more than about 50 constraints [10] and thus runtime support for

Copyright © 2017 by the paper’s authors. Copying permitted only for private and academic purposes.
In: M. Leyer (Ed.): Proceedings of the LWDA 2017 Workshops: KDML, FGWM, IR, and FGDB.
Rostock, Germany, 11.-13. September 2017, published at http://ceur-ws.org
changing circumstances is not provided. With an approach based on constraint
satisfaction problem (CSP) solving we aim at achieving model changes at run-
time efficiently, as constraints can simply be added or retracted without the
need of a transformation. Furthermore with a combination of imperative and
declarative paradigms the presented approach leads to an increased flexibility.
In this paper we present an approach for flexible workflow execution utilizing
CSP solving to handle occurring deviations and to control worklist suggestions.
First, the foundations concerning flexible workflow management are sketched,
followed by the introduction of our new concept for combining imperative and
declarative paradigms for flexible workflow execution. This approach is further
described by algorithms which are based on CSP solving. The paper ends with
a brief outlook on future work.

2 Foundations and Related Work
A workflow is “the automation of a business process, in whole or part, dur-
ing which documents, information or tasks are passed from one participant to
another for action, according to a set of procedural rules” [21]. A Workflow
Management System (WfMS) supports the execution of workflows by a work-
flow engine that interprets the process definitions and interacts with a worklist
handler, which is in charge of assigning work items to users.

Workflow Flexibility Traditional WfMS are rigid and do not allow any devia-
tions from modeled workflows. Users feel restricted and such systems are rapidly
considered as a burden. Thus, users bypass the systems, which is counterpro-
ductive for attaining the expected benefits [5]. Consequently, PAISs that allow
a workflow to flexibly deviate are essential for efficiency in SMEs. Schonenberg
et al. [16] distinguish between four kinds of workflow flexibility: Flexibility by
Design, Change, Underspecification, and Deviation. The first three types re-
quire either complete knowledge about all possible workflow execution paths at
design-time or demand a remodeling of the workflow at run-time. Hence, a flex-
ible reaction to sudden changing circumstances during run-time is prevented, or
actions are required to manually change the process instance, which is impossi-
ble for inexperienced users. “Flexibility by Deviation is the ability for a process
instance to deviate at run-time from the execution path prescribed by the orig-
inal process without altering its process model.”[16]. Although this approach
eliminates the previously mentioned disadvantages, little research exists on how
to implement this approach. Only the system FLOWer [3] implements this idea
to a limited extent by allowing the user to skip, undo, or redo a task or to insert
a new task, but still the user has to intervene manually to obtain flexibility.

Workflow Modeling Paradigms Workflow modeling paradigms range from
imperative (procedural) to declarative [6]. Imperatively modeled workflows ex-
plicitly specify all possible allowed execution paths, for example using a flow-
based modeling language such as BPEL ([4]). Here, the control flow of tasks
as well as the related flow of data items is modeled, which results in a high
complexity and a huge modeling effort. Declarative workflows, however, define
forbidden behavior and states of the workflow. Imperative workflows only de-
scribe a subset of valid procedures, while declarative constructs describe specific
undesired states, leading to the acceptance of every other state [11] and thus,
implicitly providing flexibility concerning workflow execution.
Current declarative workflow approaches such as DECLARE [2], formally
base on Linear Temporal Logic formulae representing constraints, which are fur-
ther transformed into finite-state automata, for constraint validation, as work-
flow engine and for worklist handling. Though there is a differentiation between
mandatory and optional constraints, and optional ones may be violated, a possi-
bility to retract constraints is not specified and therefore no unforeseen situations
can be handled flexibly. The concept of DCR graphs [8] is described as offering
more flexibility, but also has no possibility to restore consistency after devia-
tions. In later work Maggi et al. [10] developed an approach, Mobucon, based
on colored automata, with the ability to detect deviations and in addition to
support continuously through various strategies. A drawback of this approach is
that strategies need to be determined beforehand, and cannot be changed during
runtime, as the construction of a new automaton would take too long [10]. Algo-
rithms developed by Westergaard [20] also solve this issue with efficient runtime
modifications, e.g. models with up to 50 constraints are handled in seconds.
Our approach also aims at achieving efficient automated runtime modifica-
tions and thus requires the ability to react adequately to deviations, even to
undesired situations. A main difference between related work and our approach
is that our workflow control bases on the interpretation of incoming documents
and their semantic information. The identification of semantic information has
a significant impact on workflow control and can be easily defined as logical
constraints. Furthermore constraints can be added or retracted ad-hoc, without
the need of a time-consuming recompilation of the model. Therefore we regard
the identification of executable tasks as constraint satisfaction problem.

3 Concept of the Workflow Engine

With the presented concept we aim to increase the acceptance of users, as the
presented concept does not prescribe, but still guides, if needed. Additionally,
transactions are logged for control and monitoring purposes. The implementation
of the approach of Flexibility by Deviation as presented in this paper is embed-
ded in the SEMAFLEX1 -architecture [7], which semantically integrates flexible
workflow management with knowledge-based document management and will be
developed further in the SEMANAS project. An important characteristic is that
the information about task enactment can either result from a user interaction,
e.g. a manual selection of a task being performed, or due to upcoming docu-
ments, which are analyzed automatically and mapped to a certain task, whose
1
SEMAFLEX is funded by Stiftung Rheinland-Pfalz für Innovation, grant no. 1158
enactment is derived subsequently. These logged task enactments construct the
actually conducted workflow as a sequence of activities that have been per-
formed. While the workflow engine proposes tasks which should be done next,
the user is not forced to follow these suggestions. In principle, the user is able to
do what s/he wants and in which order s/he wants. S/he can either follow the
tasks in the worklist, suggesting the standard course of action, or do something
else and upload documents created as a result of what s/he did. Through both,
explicitly completing a task and uploading documents, the actual workflow is
identified and recorded. Progress in turn affects the worklist handling, including
detected deviations.

3.1 Combination of Imperative and Declarative Paradigms

For a suitable representation of the workflows concerning this concept, we ex-
plicitly differentiate between modeled workflow, de jure workflow, and executed
workflow, de facto workflow [1]. The de facto workflow is an actually enacted
instance derived from a de jure workflow. Thus, it stores the actually conducted
transactions and thus might deviate from the de jure workflow.
In our approach the de jure workflow is modeled procedurally, as it is more
intuitive and comprehensible than declaratively modeled workflows [12]. The
workflow engine, however, is completely based on a declarative representation,
as this paradigm implicitly offers flexibility concerning execution. To reach a
maximum of flexibility, we transform the de jure workflow into declarative con-
straints, which are used to control the suggested execution order of tasks, but
which are not regarded as mandatory and consequently might be violated. Hence,
the de jure workflow is only considered as guidance, but deviations are tolerated.
Nevertheless, some deviations are critical and should never occur, considering
e.g. compliance or safety aspects. For this reason, additional mandatory con-
straints can be modeled manually, to explicitly specify invalid workflow states.
Those are possibly connected with a severity specification, a warning message
or even a proposed corrective measure, in case the constraint is violated. Such
mandatory constraints can refer to the execution order of the tasks within a de
jure workflow or they could be global constraints specifying order constraints
across classes of workflows. Of course those mandatory constraints might actu-
ally be violated by the user, as the workflow engine never prescribes an activity
and thus is not able to actively prevent violations. Nevertheless, the violation of
constraints (including the mandatory ones) can be detected. Depending on the
kind of constraint violation the workflow engine shall be able to react adequately.
If a non-mandatory constraint is violated, the deviation is not considered as crit-
ical, but the workflow engine must reason about the next task to propose. If a
mandatory constraint is violated, a warning is issued or a corrective measure is
performed according to what is specified for the constraint.
3.2 Declarative Workflow Representation
For the declarative workflow representation, we utilize five different constraint
types of the DECLARE language [2], which countervail possible deviations:
– Precedence(ta , tb ): Task tb can only be executed after ta .
– Response(ta , tb ): Task ta requires the enactment of tb .
– Existence(ta ): Task ta is mandatory.
– Not Co-Existence(ta , tb ): Task ta and tb exclude each other.
– Absence(ta , x): Task ta can only be executed x times.
Precedence and Response prevent undesirable skipping, concerning previous or
subsequent tasks. Existence contradicts the undoing of a task. Redoing and
creating additional instances of a task are intercepted by the constraint Absence.
Not Co-Existence avoid invoking undesired task enactments.
Preventing the user from constraint violations in our case can only be achieved,
if the user manually chooses tasks from the worklist, as only such tasks are pro-
posed that lead to a valid workflow state. As non-mandatory constraints might
be violated, the worklist could consider tasks that contradict these constraints
but with lower priority. Mandatory constraints should never be disregarded.
Worklist handling is easy for procedurally modeled workflows, if no deviations
are possible. However, if a deviation occurs, one would not be able to suggest
an appropriate further proceeding. Constraints suit this situation perfectly, as
even if one is violated, it might be retracted, and still valid suggestions can be
computed with the help of remaining constraints. How valid task suggestions are
identified, will be explained in the following section.
A prerequisite for the presented enactment approach is that each construct
of the de jure workflow, modeled imperatively, is automatically transformed into
corresponding declarative expressions.

3.3 Transformation into Declarative Constructs
We consider the essential structures of imperative modeling languages on the
basis of Weske [19]. The transformation rules, as described in Tab. 1, are defined
analogously to [18], who in contrast uses Relation Algebra as formal specification
language. The resulting constraints are used for validating upcoming enactment
states of the workflow and for proposing tasks enabled for execution. The fol-
lowing section describes the algorithm that computes possible task suggestions
on the basis of these declarative constraints.

4 Worklist Handling by means of Constraint Satisfaction
Problem Solving
According to Russell and Norvig [13] a constraint satisfaction problem (CSP)
is defined by a set of decision variables X = {X1 , X2 , ..., Xn } and a set of
constraints C = {C1 , C2 , ..., Cm }. Each decision variable has a domain Di , which
Table 1. Mapping imperative workflow patterns to declarative constructs

Pattern Example Corresponding Constraints

Sequence Precedence(A,B)

Xor-Split Precedence(A,B) and Precedence(A,C)

Xor-Join Precedence(B,D) or Precedence(C,D)
Not Co-Existence(A,C) and
Not Co-Existence(B,C) and
Not Co-Existence(A,D) and
Xor-Sequences Not Co-Existence(B,D)

And-Split Precedence(A,B) and Precedence(A,C)

And-Join Precedence(B,D) and Precedence(C,D)

cf. Xor-Join and Xor-Split w.r.t. single
Cycle instances of tasks

is a nonempty set of possible values for Xi . A constraint Cj is a relation over a
subset of the variables {Xk , ..., Xl }, specifying the set of combination of allowed
values. An assignment of values to some or all of the variables is called state of
the problem, which is denoted as consistent, if it does not violate any constraint.
If values are assigned to every variable, the assignment is named complete. A
consistent and simultaneously complete assignment is called solution. In the
following we formulate the problem of selecting the next tasks for execution in
case of deviation from the de jure workflow as a constraint satisfaction problem.

4.1 Application of CSP Solving
The CSP solving algorithm is applied during workflow execution at the start of
each workflow and after each task enactment. The initial state for the algorithm
is a partially completed workflow, the de facto workflow, and its corresponding
ideal course of events, the de jure workflow. The desired output is the set of
tasks, called worklist, that can be enacted next without violating constraints.
To utilize CSP solving for worklist handling, we regard the workflow tasks
as decision variables X = T . For each task ji ∈ J = {j0 , ..., jn−1 } of the de
jure workflow, a variable tji is created and added to T . Subsequently, T is sup-
plemented with one single variable tend , to be able to determine whether the
workflow has completed. The elements of this set may vary while the workflow
progresses (see Sect. 4.3). The assignment of values to tasks represents a se-
quential order of all tasks, including not only already executed tasks, but also
possible future executions of tasks. Thus, a valid order, determined by ascending
integer values, of tasks is calculated. As the only thing of interest is, which task
may be executed next at a specific point in time, it does not matter if any other
tasks might be or have been executed in parallel. Consequently, the domain for
each decision variable is a set of integer values Di = {0, 1, . . . , n}, with n as the
number of tasks extracted from the de jure workflow including the additional
variable tend .
As the assignment represents a sequential execution order of all tasks, the first
given constraint (see (1)) states that each assigned value of a decision variable
is different from all others. Thus, only a bijective mapping of domain values to
decision variables is a solution to the CSP.

C = {alldifferent (T ) , (1)
ti = ci , . . . (for de facto) (2)
ta < tb , P recedence(ta , tb ) (3)
(tend < ta ) ∨ (ta < tb ) ∧ (tb < tend ), Response(ta , tb ) (4)
ta < tend , Existence(ta ) (5)
(tend < tb ) ∨ (tend < ta ), N ot Co-Existence(ta , tb ) (6)
X n
f (ref (ti ) , ta ) < x, Absence(ta , x) (7)
i=0
(si = a1 ) ⇒ (tend < t2 ), (8)
∧ (si = a2 ) ⇒ (tend < t1 )} (9)

with ref (ti ) returning ( the id of the referenced object of the de jure workflow
1 if ref (ti ) = ta
and f (ref (ti ) , ta ) =
0 otherwise
Second, as we apply the CSP at a specific point in time during execution
of the workflow, some tasks are already enacted and therefore the respective
variables have a fixed assignment ci , which is a constant value specifying the se-
quential execution position in the de facto workflow (see (2)). All additional con-
straints either result from the transformation of imperatively modeled workflow
to declarative language constructs or originate from manually modeled manda-
tory constraints. Each type of constraint has a corresponding formal definition to
be used in the CSP solving algorithm (see (3) to (7)). As some constraint viola-
tion explicitly depends upon workflow completion, tend is used to determine the
termination of a workflow. This is necessary to assert a mandatory enactment
of a task, a required execution of a task after a certain one, or even to assure
that some tasks have not been conducted. Considering the solution of the CSP
every task with a higher integer assigned than tend is regarded as not enacted.
Due to the construction of the CSP, we are also able to influence the control
of the workflow on the basis of semantic information. Control-flow nodes are
additionally considered as constraints to further automate the control process.
On this basis tasks are excluded from enactment proposals. For each xor or
loop construct (cf. Fig. 1) two constraints are included (see (8, 9)). With si
representing a decision variable, which either takes a1 or a2 as value, we are able
to derive which path in the workflow should be followed. For workflow control
the execution of the oppositional path is prevented, e.g. if the information of si
is known to be a1 , task t2 should not be enacted (tend < t2 ).

Fig. 1. Xor and loop construct

Furthermore, considering the importance of data nodes for the presented
approach, additional constraints are generated on the basis of data dependencies.
For example, if data node d1 is output of task t1 and input of t2 , a constraint
P recedence(t1 , t2 ) is inserted in the set of constraints, as it is necessary to enact
task t1 to subsequently process d1 with t2 .
Table 2 shows an example transformation from procedurally modeled work-
flow to constraints to logical formulae, which are then used by the algorithm.

4.2 Worklist Handling Algorithm
To identify all tasks that might be enacted next, a solution to the presented
CSP, on the basis of the previously explained generated constraints, is searched
for (cf. Algo.1). The algorithm takes the sets T and C as input for CSP Solving,
whereas the domains Di are derived from the size of T . The set F , also used as
input, represents the de facto workflow and contains the variables from T , whose
referenced tasks have been enacted. As output the variable result is introduced,
which represents the set of tasks that might be enacted next. The value of the
expected tasks, denoted here as current, is determined by the size of F , as this
is the position which will be occupied by a task executed next. If every solution

Table 2. Example workflow and corresponding constraints

Example workflow Declarative constraints Logical formulae for the CSP
Precedence(A,B), A < B ∧ A < C∧
Precedence(A,C), (B < D ∨ C < D)∧
Precedence(B,D) or (End < B ∨ End < C)∧
Precedence(C,D), (XY = yes) ⇒ (End < C)∧
Not Co-Existence(B,C) (XY = no) ⇒ (End < B)
Input : T, C, F
Output: result: Tasks that might be executed next
1 result = ∅;
2 foreach Di ∈ D do Di = {0, ..., |T | − 1};
3 current = |F |;
4 foreach x ∈ T \ F do
5 if solveCSP (T, D, C ∪ {x = current}) 6= ∅ then
6 result = result ∪ {x}
7 end
8 end
9 return result;

Algorithm 1: Determination of tasks which might be executed next

to the CSP would be computed, this would result in redundant and unnecessary
computations. To accelerate proceedings, we apply the CSP solving algorithm
only once for each decision variable that has not been assigned a value yet, thus,
has not been executed. If the CSP solving algorithm finds a solution, this task
might be executed next and therefore is appended to result. If no solution is
found, the user must not execute the task next and thus, it is not proposed.

4.3 Deviation Detection
If a task enactment occurs, variable assignments are updated and constraints are
validated to analyze the state of the workflow and possibly restore consistency.
Algorithm 2 illustrates this procedure. As input, the enacted task jn of the de
jure workflow is received. First, the length of the de facto workflow needs to be
determined, which identifies the assigned value to the variable of the currently
enacted task within the CSP. The corresponding variable tjn is included in the
de facto workflow F , and constraints are extended with the value assignment
of current to tjn . As this task enactment might result in a constraint violation,
and consequently in an inconsistent workflow state, all constraints need to be
validated. If no solution is found, the violated constraint needs to be identified
and retracted from C to restore consistency. In case a mandatory constraint is
violated, the respective warnings and corrective actions are triggered. After each
task enactment the constraint set is simplified in order to prevent unnecessary
computations. Based on the value assignments due to the de facto workflow,
which will never change for a workflow instance, some constraints will always
resolve to true, while other parts always resolve to false, even without constraint
violations, e.g. disjunctive associated propositions. Assuming that the constraint
set is available in conjunctive normal form C = c1 ∧ ... ∧ cn , clauses ci are
linked conjunctively and each clause represents a disjunction of literals ci =
l1 ∨ ... ∨ ln . The literals mostly result from the transformation of declarative
workflow constructs to logical representations and thus, relate two tasks with
the ordering ”<”. Other literals may be equations, such as t1 = 0, depicting the
de facto workflow, or alldifferent(T) due to the construction of the CSP. The
Input : Task jn
1 current = |F |;
2 F = F ∪ {tjn };
3 C = C ∪ {tjn = current};
4 if !validateConstraints(C) then
5 retractViolated();
6 end
7 simplifyConstraints(tjn );

Algorithm 2: Deviation Detection

literals of interest for CSP simplification are the first ones. If a task enactment
of task ti occurs, all clauses with ti on the left side (e.g. ti < tj ) in one of the
literals are withdrawn, as this clause will resolve to true in any case. Furthermore
single literals, which contain ti on the right side, e.g. tj < ti , can be retracted.
Those will never be fulfilled, but the remaining literals in the clause have to be.
One impact of this simplification strategy after each task enactment is that
violated constraints can be easily determined. A clause consisting of a single
literal, e.g. ti < tj , where the currently enacted task tj is on the right side, is
violated, as ti has not yet been enacted, as otherwise the clause would have been
withdrawn from the constraint set previously.

4.4 Extension of the CSP for Loop Patterns
Until now the approach is limited to a singular execution of tasks and not in-
corporating loop constructs or considering deviations like redoing a task. Thus,
an algorithm is needed which alters the input sets for Algo. 1 in case of these
previously mentioned scenarios. The trigger for this processing (cf. Algo. 3) is
an enactment of task jn of the de jure workflow.
To differentiate between individual task instances in case of a repeated enact-
ment, the decision variables in T are extended with a second index variable l, e.g.
t(jn ,l) , denoting the numbering of task instances referencing one single task, here
jn , of the de jure workflow. This second index also simplifies the validation of
the constraint Absence(ta , n), because n might be compared to the second index
l of the tasks that have already been executed. At first, the variable t(k,l) corre-
sponding to task jn has to be found. The following condition checks whether the
enacted task was the first of a loop construct. If so, the CSP is extended consid-
ering a possible further execution within the loop. Thus, a new decision variable
t(jm ,l+1) , for each task jm in the loop, is included with an increased numbering
variable (l + 1). Domains have to be expanded and constraints considering the
new loop tasks have to be incorporated.

5 Conclusion and Future Work
In this paper we presented a novel concept for workflow flexibility by deviation
that combines procedural and declarative workflow paradigms. Upcoming doc-
Input : Task jn
1 find t(k,l) such that k = jn and t(k,l) ∈ T \ F ;
2 if isF irstT askInLoop(jn ) then
3 foreach jm ∈ loop do
4 T = T ∪ {t(jm ,l+1) }, with m = |T |;
5 foreach Di ∈ D do Di = Di ∪ {|T | − 1};
6 addConstraints with usual loop constraints;
7 end
8 end

Algorithm 3: CSP extension

uments and extracted semantic information are used to determine the current
state of the workflow and for control purposes. In order to react to deviations and
still propose the best way of proceeding with the workflow, constraint satisfac-
tion problem solving is applied. Future work will focus on a detailed elaboration
of the single algorithms and possible improvements to achieve better results.
Subsequently, the implementation will be evaluated against related approaches.
Additionally, the concept will be developed further, as the workflow designer
should be granted more freedom to choose how strict or flexible the constraints
should be treated for worklist handling and, furthermore, which and how coun-
termeasures could be specified.

References
1. van der Aalst, W.M.P.: Business Process Management - A Comprehensive Survey.
ISRN Software Engineering 2013, 1–37 (2013)
2. van der Aalst, W.M.P., Pesic, M., Schonenberg, H.: Declarative workflows: Bal-
ancing between flexibility and support. Computer Science - R&D 23(2), 99–113
(2009)
3. van der Aalst, W.M.P., Weske, M., Grünbauer, D.: Case handling: a new paradigm
for business process support. Data Knowl. Eng. 53(2), 129–162 (2005)
4. Andrews, T., Curbera, F., Dholakia, H., Goland, Y., Klein, J., Leymann, F., Liu,
K., Roller, D., Smith, D., Thatte, S., Trickovic, I., Weerawarana, S.: Business Pro-
cess Execution Language for Web Services, Version 1.1. Tech. rep., BEA Systems,
International Business Machines Corporation, Microsoft Corporation (2003)
5. Dadam, P., Reichert, M., Rinderle-Ma, S.: Prozessmanagementsysteme - nur ein
wenig Flexibilität wird nicht reichen. Informatik Spektrum 34(4), 364–376 (2011)
6. Fahland, D., Lübke, D., Mendling, J., Reijers, H.A., Weber, B., Weidlich, M.,
Zugal, S.: Declarative versus Imperative Process Modeling Languages: The Issue
of Understandability. In: Enterprise, Business-Process and Information Systems
Modeling, 10th International Workshop, BPMDS 2009, and 14th International
Conference, EMMSAD 2009, held at CAiSE 2009, Amsterdam, The Netherlands,
June 8-9, 2009. Proceedings. pp. 353–366 (2009)
7. Grumbach, L., Rietzke, E., Schwinn, M., Bergmann, R., Kuhn, N.: SEMAFLEX -
Semantic Integration of Flexible Workflow and Document management. In: Krestel,
R., Mottin, D., Müller, E. (eds.) Proceedings of the Conference ”Lernen, Wissen,
Daten, Analysen”, Potsdam, Germany, September 12-14, 2016. CEUR Workshop
Proceedings, vol. 1670, pp. 43–50. CEUR-WS.org (2016)
8. Hildebrandt, T.T., Mukkamala, R.R.: Declarative Event-Based Workflow as Dis-
tributed Dynamic Condition Response Graphs. In: Proceedings Third Workshop on
Programming Language Approaches to Concurrency and communication-cEntric
Software, PLACES 2010, Paphos, Cyprus, 21st March 2010. pp. 59–73 (2010)
9. Hoffmann, D.: Schlanke Formen des Geschäftsprozessmanagements Das richtige
BPM-Rezept (February 2013), http://www.it-zoom.de/it-mittelstand/e/das-
richtige-bpm-rezept-5287/
10. Maggi, F.M., Montali, M., Westergaard, M., van der Aalst, W.M.P.: Monitoring
Business Constraints with Linear Temporal Logic: An Approach Based on Colored
Automata. In: Business Process Management - 9th International Conference, BPM
2011, Clermont-Ferrand, France, August 30 - September 2, 2011. Proceedings. pp.
132–147 (2011)
11. Pesic, M.: Constraint-based workflow management systems: shifting control to
users. Ph.D. thesis, Technische Universiteit Eindhoven (2008)
12. Pichler, P., Weber, B., Zugal, S., Pinggera, J., Mendling, J., Reijers, H.A.: Imper-
ative versus Declarative Process Modeling Languages: An Empirical Investigation.
In: Daniel, F., Barkaoui, K., Dustdar, S. (eds.) Business Process Management
Workshops - BPM 2011 International Workshops, Clermont-Ferrand, France, Au-
gust 29, 2011, Revised Selected Papers, Part I. Lecture Notes in Business Infor-
mation Processing, vol. 99, pp. 383–394. Springer (2011)
13. Russell, S.J., Norvig, P.: Artificial Intelligence - A Modern Approach (3. internat.
ed.). Pearson Education (2010)
14. Saam, M., Viete, S., Schiel, S.: Digitalisierung im Mittelstand: Status Quo, aktuelle
Entwicklungen und Herausforderungen (August 2016)
15. Schlecht, M.: Prozessmanagement in der Cloud. ERP Management 4/2013: Be-
triebsformen moderner Systeme 3, 33–36 (2013)
16. Schonenberg, H., Mans, R., Russell, N., Mulyar, N., van der Aalst, W.M.P.: Process
Flexibility: A Survey of Contemporary Approaches. In: Advances in Enterprise
Engineering I, 4th International Workshop CIAO! and 4th International Workshop
EOMAS, held at CAiSE 2008, Montpellier, France, June 16-17, 2008. Proceedings.
pp. 16–30 (2008)
17. Supyuenyong, V., Islam, N., Kulkarni, U.R.: Influence of SME characteristics on
knowledge management processes: The case study of enterprise resource planning
service providers. J. Enterprise Inf. Management 22(1/2), 63–80 (2009)
18. Wedemeijer, L.: Transformation of Imperative Workflows to Declarative Business
Rules. In: Shishkov, B. (ed.) Business Modeling and Software Design - Third Inter-
national Symposium, BMSD 2013, Noordwijkerhout, The Netherlands, July 8-10,
2013, Revised Selected Papers. Lecture Notes in Business Information Processing,
vol. 173, pp. 106–127. Springer (2013)
19. Weske, M.: Business Process Management: Concepts, Languages, Architectures.
Springer (2007)
20. Westergaard, M.: Better Algorithms for Analyzing and Enacting Declarative Work-
flow Languages Using LTL. In: Business Process Management - 9th International
Conference, BPM 2011, Clermont-Ferrand, France, August 30 - September 2, 2011.
Proceedings. pp. 83–98 (2011)
21. Workflow Management Coalition: Workflow Management Coalition Terminology
& Glossary (February 1999)