A
PLANNING AND SCHEDULING PERSPECTIVE FOR DESIGNING
BUSINESS PROCESSES FROM DECLARATIVE SPECIFICATIONS
Irene Barba and Carmelo Del Valle
Departamento de Lenguajes y Sistemas Inform
´
aticos
Universidad de Sevilla, Avda Reina Mercedes s/n, 41012, Seville, Spain
Keywords:
Planning, Scheduling, Business Processes Management.
Abstract:
Usually, business process models are manually achieved by business analysts and most of current modelling
languages are of imperative nature. As a consequence, non-optimized or faulty models can be obtained. This
work proposes a planning based approach to give business analysts assistance for the process models gene-
ration. This approach entails the selection and the order of the activities to be executed (planning), and the
resources allocation involving temporal reasoning (scheduling), both considering function optimization. The
process information is specified in a declarative way, that is translated into the standard planning language
PDDL. A friendly graphic language is used (ConDec-R, an extension of ConDec).
1 INTRODUCTION
In the past few years, most of the organizations need
to adapt to the new commercial conditions as well as
to respond to competitive pressures, so there exists
an increasing interest in the effective management
of business processes (BP). BP Management (BPM)
supports BP using methods, techniques, and software
to design, enact, control and analyze processes in-
volving humans, organizations, documents and other
sources of information (van der Aalst et al., 2003).
Scheduling problems (Brucker and Knust, 2006)
entails the suitable generation of execution plans
for a set of tasks related by temporal and resource
constraints, optimizing some functions. In a wider
perspective, in Artificial Intelligence (AI) planning
(Ghallab et al., 2004), the tasks to be executed are not
established a priori, so it is necessary to select a suita-
ble set of actions that must be executed in a correct or-
der, generally optimizing some objectives. In the past
years, there is an increasing interest in the applica-
tion of AI P&S techniques to automate the production
and execution of BP (Kearney et al., 2003; Gonz
´
alez-
Ferrer et al., 2009; Barba and Del Valle, 2010).
In BPM systems, in general, a user specifies the
model through a modelling language, such as BPMN
(White and et al., 2004). In order to design a suita-
ble model, the user must deal with several aspects,
such as the resource allocation, the tasks properties
or the relations between them, possibly optimizing
some functions. In most cases, the BP information is
provided to the system through imperative modelling
languages. In this work, it is proposed a declarative
language for the BP information. The work (Fahland
et al., 2010) analyzes the differences between impera-
tive and declarative process modelling languages with
respect to build-time modifications (maintainability).
Several works concerning BP based on Linear
Temporal Logic, LTL (Clarke Jr. et al., 1999), can
be found. (Pesic and van der Aalst, 2006; van der
Aalst and Pesic, 2006) propose a graphic tool for
modelling the processes through some templates that
can be translated to LTL formulas. ConDec (Pesic
and van der Aalst, 2006) is a declarative language
to specify dynamic BP models using a graphical no-
tation which can be mapped to formulas in LTL. In
this work, an extension of ConDec, named ConDec-
R (Sect. 2), has been defined since ConDec does not
allow reasoning about resources directly.
The Planning Domain Definition Language
(PDDL) (Ghallab and et al., 1998) is a (standard)
language for the specification of planning problems
and solutions, so that any generic planner that sup-
ports PDDL is capable to solve a wide scope of pro-
blems of different nature specified through this lan-
guage. PDDL 2.2 (Hoffmann and Edelkamp, 2005)
also allows handling of numeric values, durative ac-
tions, plan objective functions, derived predicates and
timed initial literals.
In Fig. 1, a graphical representation of the current
562
Barba I. and Del Valle C..
A PLANNING AND SCHEDULING PERSPECTIVE FOR DESIGNING BUSINESS PROCESSES FROM DECLARATIVE SPECIFICATIONS.
DOI: 10.5220/0003149005620569
In Proceedings of the 3rd International Conference on Agents and Artificial Intelligence (ICAART-2011), pages 562-569
ISBN: 978-989-8425-40-9
Copyright
c
2011 SCITEPRESS (Science and Technology Publications, Lda.)
Declarative Process Information
(ConDec-R)
Resource
Availability
Name: N1
Role: R1
PDDL 2.2 Specification
translate
P&S
Planner
PDDL 2.2 Plan
Business
Analyst
Business
Process Model
Workflow
Engine
give assistance
Domain Problem
AI Planning and Scheduling
BPM System
Name: N2
Role: R2
(define (problem travelCompany)
(:domain ConDec) (:objects Receive ... Credit-card -
act Secretary
BookManager - role S1 BM1 BM2 - res)
(:init (= (n-times-receive) 0)
metric minimize (total-time))
(:goal (and (forall (?act - activity) (not (forced ?act)))
(define (domain ConDec)
(:types act res role - object)
(:predicates (forced ?a - act) (locked ?a - act)
(:functions (duration ?act - act) (n-times-receive) ...
(:durative-action Act-Credit-card
:parameters (?r - res ?rol -role)
:duration (= ?duration (duration Credit-card))
0.001: (ACT-RECEIVE S1) [2.0000]
2002: (ACT-HOTEL BM1) [4.0000]
2.003.: (ACT-AIRLINE BM2) [3.0000]
5.004: (ACT-BOOKED-AIRLINE BM2)
[3.0000]
6.005: (ACT-BOOKED-HOTEL BM1) [4.0000]
10.006: (ACT-CREDIT-CARD S1) [3.0000]
13.007: (ACT-NOTIFY-BOOKED S1) [2.0000]
Business
Analyst
Figure 1: An AI-based approach for the generation of business process models.
approach is shown. First, the business analyst pro-
vides the declarative process information through a
ConDec-R specification, that is translated to a PDDL
2.2 specification to be used as input of a planner
for obtaining a feasible optimized BP execution plan.
Lastly, this PDDL 2.2 plan gives the business analyst
assistance for the BP model generation. The main
contributions of this paper can be summarized as:
• An application of an AI-based approach for sol-
ving the planning and scheduling of the tasks in-
volved in the BP model through automatic plan-
ners, in order to generate BP execution plans.
This approach considers task properties, resources
allocation and the optimization of some functions.
• A translation from a formal and widely used lan-
guage (LTL) to PDDL 2.2 of several templates re-
lated to BP definitions.
• An extension of a graphic declarative language for
BP, including resources treatment.
The paper is organized as follows: Sect. 2 ex-
plains the proposed declarative language, Sect. 3 de-
tails the translation from the declarative specification
to PDDL 2.2, Sect. 4 shows a case of study, and Sect.
5 presents some conclusions and future work.
2 DECLARATIVE
SPECIFICATION OF BP
In this work, the user must provide the process in-
formation to the system in a declarative way. In or-
der to do this, an extension of ConDec (ConDec-R)
is used, including information about the resources re-
quired for the execution of the activities. ConDec
(Pesic and van der Aalst, 2006) is a graphical lan-
guage based on declarative specifications for mode-
lling and enacting dynamic BP. For the definition of
relationships between activities, ConDec proposes an
open set of constraints based on LTL. One impor-
tant difference when modelling with ConDec is that
a ConDec-activity represents multiple executions of a
P&S-activity, so that a ConDec-activity can be execu-
ted several times.
The main contribution of ConDec-R regarding to
ConDec, is the reasoning about resources. Unlike
ConDec, in ConDec-R the activities execution re-
quires resources of a specific role, and there are se-
veral resources with the competences defined by a
role. This information can be easily added to ConDec.
A ConDec-R problem specification must include (an
example can be seen in Sect. 4):
• As in ConDec, the tasks that can be executed in
the BP enactment. In some cases, constraints
about the number of times that one activity must
be executed are specified (it appears above the
associated activity in the graphical representa-
tion).
• The role of the required resource and the esti-
mated duration of each task, which are specified
on the left side of the task (extension of ConDec).
• Available resources with the competences of a
role (extension of ConDec).
• As in ConDec, the relations between activi-
ties through constraint templates (parameterized
graphical representations of LTL formulas).
3 TRANSFORMATION FROM
CONDEC-R TO PDDL 2.2
PDDL (Ghallab and et al., 1998) is a (standard) lan-
guage for the specification of planning problems and
solutions, so that any generic planner that supports
PDDL is capable to solve a wide scope of problems
A PLANNING AND SCHEDULING PERSPECTIVE FOR DESIGNING BUSINESS PROCESSES FROM
DECLARATIVE SPECIFICATIONS
563
of different nature specified through this language.
PDDL 2.2 (Hoffmann and Edelkamp, 2005) specifi-
cations include a domain file and a problem file.
3.1 Domain Description
A PDDL 2.2 domain contains the following items:
Predicates: They represent the properties of ob-
jects that can be true or false. Several predicates have
been considered for the BP execution plan generation
(Table 1). Different predicates for the temporal locks
of the activities are used in order to differentiate be-
tween the reasons of the lock.
Functions (Fluents): They represent values, that
can vary over time, associated to objects, allowing
handling of numeric values. We have used two kind
of fluents:
(duration ?act)
, that is the constant du-
ration of the activity
act
; and
(n-times-activity)
that represents the number of times that an activity has
been executed until the current state.
Actions/Operators (Durative): They allow the
evolution of the system by means of state changes.
For the BP execution plan generation, there exists one
durative action representing the execution of each ac-
tivity. In the proposed approach, there exists a PDDL
2.2 durative action associated to each ConDec-R ac-
tivity, since both are durative and, also, can be exe-
cuted several times. Furthermore, all the actions have
a base specification (Fig. 2) that is extended through
preconditions and effects depending on the relations
in which the concerning activity is involved (Sect.
3.3). For the execution of an activity (Fig. 2), two
conditions
(:condition)
must be satisfied: it must
not be locked for any reason, and there must exist a
free resource with the role required by the activity.
The predicates
forced
and
locked
are used in order
to ensure the feasibility of the constraints established
by the ConDec-R templates. After the activity execu-
tion, some effects
(:effect)
are given: the
n-times
function is increased; the activity becomes not forced
to execute; and the required resource becomes busy
(only) during the activity execution.
3.2 Problem Description
A PDDL 2.2 problem contains the following items:
Objects: They represent the things in the world
that are noteworthy for the specified problem. In the
current proposal, three kinds of objects can be distin-
guished:
activity
,
resource
and
role
.
Initial State: Initially, all the resources are consi-
dered free and the number of times one activity has
been executed is 0 (fluent
(n-times-activity)
).
Also, it is necessary to include the predicates
(role
(:durative-action Activity
:parameters (?r - res ?rol - role)
:duration (= ?duration (duration Activity))
:condition (and (at start (not (locked Activity)))
(at start (and (free ?r)
(resources Activity ?rol)
(role ?r ?rol))))
:effect (and (at end (done Activity))
(at end (increase (n-times-activity) 1))
(at end (not (forced Activity)))
(at start (not (free ?r)))
(at end (free ?r))))
Figure 2: PDDL 2.2 base specification for the
Activity
actions.
Resource Role)
and
(resource Activity Role)
for the related objects that present these relations,
together with the corresponding value for the fluent
(duration Activity)
.
Goal: Things that must be true at the end of the
plan. There is a base goal specification, that is ex-
tended depending on the relations between the activi-
ties (Sect. 3.3). The goal is reached when there are
no activities to be executed (
(:goal (and (forall
(?act - activity) (not (forced ?act)))))
).
Objective Function: Plan quality measures (me-
trics). In the current proposal, the minimization of
the total time of the plan is pursued:
(:metric
minimize (total-time))
.
3.3 Transformation from ConDec-R
Templates to PDDL 2.2
ConDec-R considers the same templates than ConDec
(van der Aalst and Pesic, 2006). For a specific prob-
lem, the relations between the activities can extend
the base durative action specification (Fig. 2); and the
base goal for the problem specification. As follows,
the considered relations are described, together with
the effect they have in the PDDL 2.2 specification:
I) Existence constraints:
1. EXISTENCE N(A):
A
must be executed
more or equal than
N
times. The goal
(>=
(n-times-A) N)
is added.
2. ABSENCE N(A):
A
must be executed less
than
N
times. The goal
(< (n-times-A) N)
is added.
3. EXACTLY N(A):
A
must be executed
N
times exactly. The goal
(= (n-times-A)
N)
is added.
II) Relation constraints:
1. RESPONDED EXISTENCE(A,B): If
A
is
executed, then
B
also must be execu-
ICAART 2011 - 3rd International Conference on Agents and Artificial Intelligence
564
Table 1: Predicates for the automatic generation of optimized BP execution plans.
Predicate Description
(forced ?act - activity)
The activity
act
has to be executed before the end of the plan.
(locked-temp ?act - activity) act
is temporarily locked to be executed due to
alternate
and
responded absence
relations (Sect. 3.3).
(locked-chain ?act - activity) act
is temporarily locked to be executed due to
chain
relations
(Sect. 3.3).
(locked-perm ?act - activity) act
can not be executed anymore.
(locked ?act - activity)
Derived predicate that is defined as the disjunction of
locked-temp
,
chain
and
perm
.
(resources ?act - activity ?ro - role) act
requires a resource with the role
ro
to be executed.
(role ?r - resource ?ro - role)
There exists a resource
r
that presents the role
ro
.
(free ?r - resource)
The resource
r
is free.
(done ?act - activity)
The activity
act
has been executed.
ted. The goal
(or (= (n-times-A) 0) (>
(n-times-B) 0))
is added.
2. CO-EXISTENCE(A,B): The execution of
A
forces the execution of
B
, and vice
versa. The goal
(= (> (n-times-A) 0)
(> (n-times-B) 0))
is added.
3. RESPONSE(A,B): After the execution of
A
,
B
must be executed always. It leads to add an
effect to the durative-action associated to
A
:
(at end (forced B))
.
4. PRECEDENCE(A,B): Before
B
,
A
must have
been executed. It leads to add a condition
to the action associated to
B
:
(at start
(done A))
.
5. SUCCESSION(A,B): Relations
Response(A,B)
and
Precedence(A,B)
must hold.
6. ALTERNATE RESPONSE(A,B): After the
execution of
A
,
B
must be executed, and be-
tween each two executions of
A
, there must
be at least one execution of
B
. It leads to add
two effects to
A
:
(at end (forced B))
and
(at start (locked-temp A))
; and one
effect to
B
:
(at end (not (locked-temp
A)))
.
7. ALTERNATE PRECEDENCE(A,B): Before
the execution of
B
,
A
must have been execu-
ted, and between each two executions of
B
,
A
must be executed. It leads to add: a condition
to
B
:
(at start (done A))
; an effect to
B
:
(at start (locked-temp B))
; and an
effect to
A
:
(at end (not (locked-temp
B)))
.
8. ALTERNATE SUCCESSION(A,B): Re-
lations
Alternate Response(A, B)
and
Alternate Precedence(A,B)
must hold.
9. CHAIN RESPONSE(A,B): Straight after
A
,
B
must be executed. It leads to add one
effect to
A
for each activity
C
that does
not match with
B
:
(at end (locked-chain
C))
; and one to
B
for each activity
C
that does not match with
B
:
(at end (not
(locked-chain C)))
.
10. CHAIN PRECEDENCE(A,B): Straight be-
fore
B
,
A
must be executed. It leads to add an
effect to
A
:
(at end (not (locked-chain
B)))
; and an effect to all the activi-
ties different from
A
(even
B
):
(at start
(locked-chain B))
.
11. CHAIN SUCCESSION(A,B): Relations
Chain Response(A,B)
and
Chain Precedence(A,B)
must hold.
III) Negation constraints:
12. RESPONDED ABSENCE and NOT
CO EXISTENCE(A,B): If
B
is execu-
ted, then
A
can not be executed, and vice
versa. It leads to add an effect to
A
:
(at
start (locked-perm B))
; and one to
B
:
(at start (locked-perm A))
.
13. NEGATION RESPONSE, NEGATION
PRECEDENCE, NEGATION SUCCES-
SION(A,B): After the execution of
A
,
B
can
not be executed. It leads to add an effect to
A
:
(at start (locked-perm B))
.
14. NEGATION ALTERNATE RES-
PONSE(A,B): Between two executions
of
A
,
B
can not be executed. It leads to add
an effect to
B
:
(at start (when (done A)
(locked-perm A)))
.
15. NEGATION ALTERNATE PRECE-
DENCE(A,B): Between two executions
of
B
,
A
can not be executed. It leads to add
an effect to
A
:
(at start (when (done B)
(locked-perm B)))
.
16. NEGATION ALTERNATE SUC-
CESSION(A,B): Relations
Negation
A PLANNING AND SCHEDULING PERSPECTIVE FOR DESIGNING BUSINESS PROCESSES FROM
DECLARATIVE SPECIFICATIONS
565
Alternate Response(A,B)
and
Negation
Alternate Precedence(A, B)
must hold.
It leads to add one effect to
B
:
(at start
(when (done A) (locked-perm A)))
;
and one to
A
:
(at start (when (done B)
(locked-perm B)))
.
17. NEGATION CHAIN RESPONSE, NEGA-
TION CHAIN PRECEDEN- CE, NEGA-
TION CHAIN SUCCESSION(A,B):
B
can
not be executed straight after the execution
of
A
. It leads to add an effect to
A
:
(at
start (locked-chain B))
; and an effect
to all the activities but
A
:
(at start (not
(locked-chain B)))
.
The set of templates can be extended (van der
Aalst and Pesic, 2006). One extension is the rela-
tion
mutual substitution
(van der Aalst and Pesic,
2006), establishing that, at least, one of two activities
should occur. Another extension corresponds to the
branched constraints (van der Aalst and Pesic, 2006)
from one source activity to several sink ones, so the
relation is given between the source and, at least, one
of the sinks; or from several source activities to one
sink, so the relation is given between, at least, one
of the sources and the sink (examples in Sect. 4).
When the branched constraint has only one source ac-
tivity, non-deterministic effects are given for such ac-
tivity. The inclusion of non-deterministic effects can
be treated by stochastic planners (Dean et al., 1995).
To the best of our knowledge, at present there is not
an available planner able to treat with all the fea-
tures required: durative actions, simultaneous action
execution, non-deterministic effects and optimization.
In order to overcome this problem, in this work, the
non-deterministic ConDec-R problem is automatica-
lly translated to a set of deterministic ones following
the algorithm 1, so generic planners can automatically
solve the different deterministic problems.
The basic idea of Alg. 1 is explained as follows:
each non-deterministic relation ndr(r,A,B,C), where
r is the given relation, A is the source and B,C are
the sinks, means that, at least, one of relations r(A, B)
or r(A,C) must be given. In order to treat both pos-
sibilities, two deterministic problems are solved, one
considering the deterministic relation r(A,B), and the
other one considering r(A,C). It is necessary to con-
sider both possibilities each time the source activity is
executed, leading to a limitation in the ConDec-R pro-
blems to be treated with the proposed approach: the
maximum cardinality of the activities that are source
of a non-deterministic relation, must be specified in
the ConDec-R problem in order to generate the cor-
responding deterministic problems in a suitable way.
Let n be the number of non-deterministic relations
Algorithm 1: Deterministic ConDec-R problems.
input : a non deterministic problem
NDP < DR, NDR >
output: a set of deterministic problems
DP < DR >
Probs ← {};
n ← number of non-deterministic relations
considering the source maximum cardinality;
for i ← 0 to 2
n−1
do
Prob ← NDP.DR ∪
DFromND
(i,NDP.NDR);
Probs ← Probs ∪ Prob;
return Probs;
Function:
DFromND(
int i, set NDR
)
.
s ← {};
foreach ndr(r,A,B,C) in NDR do
rem = i%2;
if rem == 0 then
s ← s ∪ dr(r, A,B);
else
s ← s ∪ dr(r, A,C);
i = i/2;
return s;
taking into account the maximum cardinality of the
activities that are source of a non-deterministic rela-
tion. Then, in general, 2
n
deterministic problems can
be generated in order to deal with all the possibilities.
In Alg. 1, the input is a ConDec-R non-deterministic
problem (NDP), composed by a set of deterministic
relations (DR), and a set of non-deterministic ones
(NDR). As a result, a set of deterministic problems
(DP), is obtained. Probs is a set that contains 2
n
de-
terministic problems at the end of the algorithm. The
function (
DFromND
) is in charge of generating diffe-
rent combinations of deterministic relations for each
problem from the set NDR.
4 AN EXAMPLE
The Acme Travel Company problem is an adaptation
of the one presented in (Snell, 2002), that was speci-
fied through DecSerFlow language in (van der Aalst
and Pesic, 2006). As follows, the considered problem
is described:
1. Acme Travel receives an itinerary from Karla, the
customer.
2. After checking the itinerary for errors, the process
determines which reservations to make, simulta-
ICAART 2011 - 3rd International Conference on Agents and Artificial Intelligence
566
Receive
Request
1
S
2
Hotel
Search
BM
4
Compe
nsation
0..1
BM
2
Airline
Search
BM
3
Receive
Failed
Hotel
BM
1
Receive
Failed
Airline
BM
1
Notify
Failure
0..1
S
2
Book
Airline
BM
2
Book
Hotel
BM
2
Notify
Booked
0..1
S
2
Credit
Card
0..1
S
3
not-response
precedence
response
precedence
not-response
p
r
e
c
e
d
e
n
c
e
r
e
s
p
o
n
s
e
precedence
succession succession
precedence
precedence
not co-existence
not
co-existence
precedence
not
co-existence mutual
substitution
response
response
succession
not-response not-response
Resource
Availability
Name: BM1
Role: BM
Name: BM2
Role: BM
Name: S1
Role: S
11
Figure 3: ConDec-R specification for Acme Travel Company.
neously asking for information to the appropriate
airline and hotel agencies to make the appropriate
reservations.
3. If any of the two reservation tasks fails, the
itinerary is cancelled by performing the ”compen-
sate” activity and Karla is notified of the problem.
4. Acme Travel waits for confirmation of the two
reservation requests.
5. Upon receipt of confirmation, Acme Travel noti-
fies Karla of the successful completion of the pro-
cess and sends her the itinerary details.
6. Once Karla is notified of either the success or fai-
lure of her requested itinerary, she may submit
another travel request.
The activities in (van der Aalst and Pesic, 2006) are
modelled as web services. Conversely, in this work,
the activities are tasks that need to use some shared
resources to be executed. Two roles are considered:
Book Manager (BM) and Secretary (S). Also, it is es-
timated that two resources with role Book Manager
(BM1 and BM2), and one with role Secretary (S), will
be available for the BP enactment. Considering that
only one instance is executed at the same time, the to-
tal time of the resulting plan must be minimized. In
Fig. 3 the ConDec-R model of the problem is shown.
As can be seen, eleven activities are presented:
Receive Request: A Secretary must attend the client
request. This activity will be done exactly once.
Hotel Search: A BM asks for information to seve-
ral hotel agencies to make the appropriate reser-
vation. After the execution of Receive Request,
it must be executed always, and before its exe-
cution, Receive Request must have been executed
also (relation succession).
(define (domain
ConDec)
(:requirements :adl :fluents :durative-actions)
(:types act res role - object)
(:predicates (forced ?a - act) (locked ?a - act)
(locked-temp ?a - act)... (done ?a - act)
(role ?r - res ?ro - role) (free ?r - res)
(resource ?a - act ?ro - role))
(:functions (duration ?act - act) (n-times-receive) ...
(n-times-credit-card))
(:durative-action Act-Credit-card
:parameters (?r - res ?rol - role)
:duration (= ?duration (duration Credit-card))
:condition (and (at start (not (locked Credit-card)))
(at start (and (free ?r) (resources Credit-card ?rol)
(role ?r ?rol)))
(at start (and (done Book-hotel) (done Book-airline))))
:effect (and (at start (and (not (forced Credit-card))
(not (free ?r))))
(at end (and (done Credit-card)
(increase (n-times-credit-card) 1)
(free ?r)))
(at end (forced Notify-booked))
(at end (and (locked-perm Hotel)
(locked-perm Airline)
(locked-perm Notify-failure)))))
Figure 4: PDDL 2.2 domain specification for the Acme
Travel Company.
Book Hotel: A BM must book the appropriate reser-
vation. Hotel Search has to be executed before it
(precedence).
Receive Failed Hotel: A BM must receive the fai-
lure notification in the case it happens. Hotel
Search has to be executed before it (precedence).
On the other hand, after Hotel Search, one of the
activities Book Hotel or Rec. Failed Hotel must be
executed (branched response). Lastly, only one
of Book Hotel and Receive Failed Hotel can be
A PLANNING AND SCHEDULING PERSPECTIVE FOR DESIGNING BUSINESS PROCESSES FROM
DECLARATIVE SPECIFICATIONS
567
(define (problem travelCompany)
(:domain ConDec)
(:objects Receive... - act Secretary BookManager - role
S BM1 BM2 - res)
(:init (= (n-times-receive) 0)...(= (duration Credit-card) 3)
(free S)...(role S Secretary)
(resources Receive Secretary)...
(resources Credit-card Secretary)
(:metric minimize (total-time))
(:goal (and (forall (?act - activity) (not (forced ?act)))
(= (n-times-receive) 1) (< (n-times-compensation) 2)
(< (n-times-notify-failure) 2)
(< (n-times-notify-booked) 2)
(< (n-times-credit-card) 2)
(or (> (n-times-credit-card) 0)
(> (n-times-notify-failure) 0)))))
Figure 5: PDDL 2.2 problem specification for the Acme
Travel Company.
executed (not co-existence).
Airline Search: A BM asks for information to seve-
ral airline agencies to make the appropriate reser-
vation. As Hotel Search, it presents a succession
relation to Receive Request.
Book Airline: A BM must book the appropriate
reservation (previously detected in Airline
Search). Airline Search has to be executed before
it (precedence).
Receive Failed Airline: A BM must receive the fai-
lure notification in the case it happens. It is in-
volved in the same relation that Receive Failed
Hotel, but regarding the airline activities.
Compensation: A Secretary must study the compen-
sation for the client. This activity has to be pre-
ceded for at least one of Receive Failed Hotel or
Airline (branched precedence relation). It can not
be executed after neither Hotel Search nor Airline
Search (not response).
Notify Failure: A Secretary must report the failure.
It has to be preceded by Compensation.
Credit Card: A Secretary proceed to make the pay-
ment. One of Book Hotel or Book Airline has to be
executed before it (branched precedence). Also,
after Book Hotel and Book Airline, it must be exe-
cuted (response relations). One and only one of
Notify Failure and Credit Card must be executed
(not co-existence and mutual substitution). Also,
after Credit Card, neither Hotel Search nor Airline
Search can be executed (not response).
Notify Booked: A Secretary must report the infor-
mation about the book to the client. After the exe-
cution of Credit Card, it must be executed always,
and before its execution, Credit Card must have
been executed also (succession).
BPMN Elements
Exclusive
Data-Based
Gateway
Start Event End Event
Parallel
Gateway
Figure 6: Some BPMN elements.
For this example, a part of the PDDL 2.2 domain
is shown in Fig. 4, including all the aspects except
that only a representative activity (Credit Card) is spe-
cified as an example. Also, the PDDL 2.2 problem
specification is shown in Fig. 5. Taking the PDDL
2.2 specification as input, the planner solves the prob-
lem generating the optimum execution plan: allocat-
ing the available resources and temporarily assigning
the start and the end times for the activities execution.
This plan can be used to guide the BP model design.
The Business Process Modelling Notation
(BPMN) (White and et al., 2004) is a standard for
modelling BP flows and web services, and provides
a graphical notation for specifying BP in a Business
Process Diagram (BPD). The BPD is composed, be-
tween others, by events, gateways (Fig. 6), activities
and swimlanes. An event represents something that
happens during the enactment of a BP and affects its
execution flow, specifically the start event initiates
the flow of the process, while the end event finishes
this flow. Gateways are in charge of controlling
how sequence flows interact as they converge or
diverge within a process, specifically the exclusive
data-based gateway can be used as a decision point
or as a way to merge several sequence flows into one;
while the parallel gateway provides a mechanism
to fork and synchronize the flows. Swim lanes are
graphic ways of organizing and categorizing the BP
activities, specifically pools represent the participants
in a BP, and lanes are used to organize the activities
within a pool according to roles or resources.
Taking into account the PDDL 2.2 solutions, an
optimized and feasible BPMN can be designed (Fig.
7). It is composed by a pool named Travel Company
that contains three lanes, BM1, BM2 and S. In Fig. 7,
RFA is a boolean that represents a fail given during
the booking of the airline, while RFH represents the
same for the hotel booking.
5 CONCLUSIONS AND FUTURE
WORK
This work proposes a PDDL 2.2 model for the op-
timal BP execution plan generation when specifying
the process information in a declarative way, apply-
ICAART 2011 - 3rd International Conference on Agents and Artificial Intelligence
568
Travel Company
Receive
Request
Hotel
Search
Airline
Search
Failed
Hotel
Book
Hotel
RFH
!RFH
Book
Airline
Failed
Airline
!RFA
RFA
Credit
Card
Compen
sation
Notify
Booked
Notify
Failure
RFH
BM1BM2 S
Figure 7: BPMN for the Acme Travel Company.
ing an AI-based planning and scheduling approach to
consider resources allocation and the minimization of
the plan duration. The BP information is provided
through a friendly graphic language (ConDec-R).
As future work, it is intended to develop a tool
for the automatic generation of process models from
PDDL 2.2 plans. Furthermore, the use of different
AI-based approaches to generate process models from
declarative specifications will be analyzed.
ACKNOWLEDGEMENTS
This work has been partially funded by the Con-
sejer
´
ıa de Innovaci
´
on, Ciencia y Empresa of Junta
de Andaluc
´
ıa (P08-TIC-04095) and by the Span-
ish Ministerio de Ciencia e Innovaci
´
on (TIN2009-
13714) and the European Regional Development
Fund (ERDF/FEDER).
REFERENCES
Barba, I. and Del Valle, C. (2010). Planning and schedul-
ing of business processes in run-time: A repair plan-
ning example. In Proceedings of the 19th Interna-
tional Conference on Information Systems Develop-
ment (ISD 2010). Springer (in press).
Brucker, P. and Knust, S. (2006). Complex Scheduling
(GOR-Publications). Springer-Verlag New York, Inc.,
Secaucus, NJ, USA.
Clarke Jr., E., Grumberg, O., and Peled, D. (1999). Model
Checking. The MIT Press.
Dean, T., Kaelbling, L. P., Kirman, J., and Nicholson, A. E.
(1995). Planning under time constraints in stochastic
domains. Artif. Intell., 76(1-2):35–74.
Fahland, D., Mendling, J., Reijers, H., Weber, B., Wei-
dlich, M., and Zugal, S. (2010). Declarative versus
imperative process modeling languages: The issue of
maintainability. Lecture Notes in Business Informa-
tion Processing, 43 LNBIP:477–488.
Ghallab, M. and et al. (1998). Pddl - the planning domain
definition language. Technical report, CVC TR-98-
003/DCS TR-1165.
Ghallab, M., Nau, D., and Traverso, P. (2004). Automated
Planning: Theory and Practice. Morgan Kaufmann,
Amsterdam.
Gonz
´
alez-Ferrer, A., Fern
´
andez-Olivares, J., and Castillo,
L. (2009). Jabbah: A java application framework for
the translation between business process models and
htn. In International Competition on Knowledge En-
gineering for Planning ICKEPS.
Hoffmann, J. and Edelkamp, S. (2005). The determinis-
tic part of ipc-4: an overview. J. Artif. Int. Res.,
24(1):519–579.
Kearney, P., Borrajo, D., Cesta, A., Matino, N.,
and Mehandjiev, N. (2003). Planet work-
flow management r&d roadmap. http://
scalab.uc3m.es/∼dborrajo/planet/wm-tcu/Roadmap-
WM-phase-II.pdf.
Pesic, M. and van der Aalst, W. M. P. (2006). A declarative
approach for flexible business processes management.
In Business Process Management Workshops, pages
169–180. Springer.
Snell, J. (2002). Automating business processes and
transactions in web services: An introduction to
bpelws, ws-coordination, and ws-transaction. http://
www.ibm.com/developerworks/webservices/library/
ws-autobp/.
van der Aalst, W. M. P. and Pesic, M. (2006). Decserflow:
Towards a truly declarative service flow language. In
LNCS 4184, pages 1–23.
van der Aalst, W. M. P., ter Hofstede, A. H., and Weske, M.
(2003). Business process management: A survey. Int.
Conf. BPM 2003, Proceedings, pages 1–12.
White, S. and et al. (2004). Business Process Modeling
Notation (BPMN), Working draft, Version 1.0.
A PLANNING AND SCHEDULING PERSPECTIVE FOR DESIGNING BUSINESS PROCESSES FROM
DECLARATIVE SPECIFICATIONS
569
