Towards an Implementation of Data and Resource Patterns in

Constraint-based Process Models

Stefan Sch

onig, Lars Ackermann and Stefan Jablonski

Institute for Computer Science, University of Bayreuth, Bayreuth, Germany

Keywords:

Constraint-based Processes, Flexible Processes, Workﬂow Patterns, Process Execution.

Abstract:

A Process-Aware Information System (PAIS) is a system that executes processes involving people, appli-

cations, and data on the basis of process models. Two representations for processes can be distinguished:

procedural models prescribe exactly the execution order of process steps. Declarative process models allow

ﬂexible process executions that are restricted by constraints. Especially in application areas of knowledge

driven processes, this ﬂexibility is required. Foundations of declarative approaches have been extensively dis-

cussed in research. From a practitioner’s point of view, however, an open question still remains: is it possible

to implement established functionality in contemporary declarative PAIS, especially data and resource han-

dling? In this paper, we tackle this open research question by introducing the declarative process modelling

and execution framework DPIL that covers resource and data modelling. Expressiveness and functionality of

the framework are evaluated by means of the well-known Workﬂow Data and Resource Patterns.

1 INTRODUCTION

A Process-Aware Information System (PAIS) is a

software system that manages and executes business

processes involving people, applications, and data on

the basis of process models (Reichert and Weber,

2012). Processes can be modelled using a variety

of languages and different concepts. State of the art

technology distinguishes between two principle ap-

proaches: procedural concepts prescribe exactly the

execution order of process steps. Declarative, i.e.,

constraint-based processes on the other hand allow

ﬂexible process executions that are restricted by con-

straints (Fahland et al., 2009). Especially in applica-

tion areas of knowledge driven processes this ﬂexibil-

ity is required since the exact ﬂow of activities can-

not be fully determined at design time (Reichert and

Weber, 2012). Here, the execution sequence heavily

depends on human participants, their decisions and

expert knowledge (Fahland et al., 2009). Recent re-

search has shown that declarative approaches are best

suited for supporting ﬂexible, knowledge driven pro-

cesses (Fahland et al., 2009; Vacul

ın et al., 2011).

Independent from the modelling paradigm

processes can be seen from different perspec-

tives (Jablonski and Bussler, 1996). The behavioural

perspective describes activities and their execution

ordering, e.g., task sequences or parallelism. The data

perspective deals with process data and documents.

Business documents and other objects which are

used within activities as well as local variables of

the process, may reﬂect pre- and post-conditions of

activity execution. Typically, process data is passed

into and out of applications through interfaces,

allowing manipulation of the data. The resource

perspective manages the involvement of resources in

processes, e.g., it provides an anchor to the process in

the form of human roles responsible for activities.

Theoretical foundations of declarative approaches

have been extensively discussed in research with

a strong focus on behavioural aspects (Montali,

2010; Pesic, 2008) and conceptually extensions for

data (Westergaard and Maggi, 2012; Montali et al.,

2013; Burattin et al., 2015). From a practitioner’s

point of view, however, an open question still re-

mains (Reijers et al., 2013): is it possible to im-

plement established functionality in contemporary

declarative PAIS, in particular data and resource han-

dling? Answering this question is essential for using

declarative approaches in practice.

In this paper, we tackle this open research ques-

tion by introducing the declarative process modelling

and execution framework DPIL that covers in par-

ticular resource and data modelling. Expressiveness

and functionality of the framework are evaluated by

means of the well-known Workﬂow Data and Re-

Schönig, S., Ackermann, L. and Jablonski, S.

Towards an Implementation of Data and Resource Patterns in Constraint-based Process Models.

DOI: 10.5220/0006533502710278

In Proceedings of the 6th International Conference on Model-Driven Engineering and Software Development (MODELSWARD 2018), pages 271-278

ISBN: 978-989-758-283-7

271

source Patterns

, a systematically speciﬁed catalogue

of desired functionality of PAIS. The set of work-

ﬂow patterns covers recurring requirements focusing

on data interaction (Russell et al., 2005a) and re-

source involvement (Russell et al., 2005b). We give

concrete model excerpts that implement frequently

needed functionality. Examplary real-life processes

that include these patterns can be executed with the

DPIL Navigator at http://navigator.kppq.de. The con-

tribution of this work is to show that existing declar-

ative PAIS are ready to use for practical applications.

The remainder of this paper is structured as follows:

in Section 2 we introduce the syntax and grammar of

the DPIL modelling and execution framework. Sec-

tion 3 describes the implementation of Data and Re-

source Patterns in DPIL. In Section 4 we discuss re-

lated work and the paper is concluded in Section 5.

2 MODELLING WITH DPIL

In this section, we introduce the framework we use

to implement the workﬂow patterns. The Declara-

tive Process Intermediate Language (DPIL) is a multi

perspective and multi modal process modelling lan-

guage on a textual basis. Unlike other declarative

languages it allows for representing several perspec-

tives, namely, behaviour, data and resources and their

crosscutting relations. It is multi modal, meaning

that both mandatory and recommended actions are

speciﬁed. The DPIL framework offers a rich toolset

for modelling and executing declarative process mod-

els: (i) DPIL models can be deﬁned using a textual

editor the DPIL Modeller. The modeling tool sup-

ports users through syntactic, semantic and qualitative

model analysis based on the Xtext framework

. DPIL

models can be (ii) executed by the declarative exe-

cution engine, the DPIL Navigator. Both tools have

been published in demo papers (Sch

onig and Zeising,

2015; Sch

onig et al., 2017). DPIL allows for deﬁning

reusable templates (macros) in order to keep the re-

sulting model concise. Macros can be deﬁned to the

modellers’ needs using all concepts of DPIL.

2.1 The DPIL Language

Hereafter a concrete syntax is described that is used

to represent a DPIL model textually. The concrete

syntax is described using the Antlr conform extended

Backus-Naur form (EBNF).

Information at http://www.workﬂowpatterns.com

http://www.eclipse.org/Xtext/

2.1.1 Models

In the model head the used identities, groups and re-

lation types from the organizational model are enu-

merated to make them available and referable by their

names. Additionally connection properties to CMIS

compatible ECM systems

can be speciﬁed to de-

scribe source and target of data objects. To avoid

redundancy one can additionally deﬁne macros or

global rules in this section of the model. Conse-

quently, a model might lack any process informa-

tion but instead can be used to form a library model

by just enumerating elements of the organizational

model, deﬁnes macros or connections to ECM sys-

tems. Models can reference other models and, thus,

can make use of, for instance, this library model.

Model: Identity* Group* RelationType* Repository* Macro*

GlobalRule* Process?

Identity: ’identity’ ID

Group: ’group’ ID

RelationType: ’relationtype’ ID

Repository: ’repository’ ID ’{’

’url’ STRING

’user’ STRING

’password’ STRING

’id’ STRING ’}’

2.1.2 Structural Elements

A process can consist of activities, data objects and

process rules. Activities and data objects must have

an identiﬁer (ID) and can be named. An activity is,

in turn, a process, a human task or an operation. An

operation omits the name and only consists of an iden-

tiﬁer and a body. Additionally it is possible to assign

actual arguments to the operation’s dummy arguments

as well as a data object to store the return value (to).

Data objects can either be variables or documents.

Both can be multi-valued (collection) and documents

must be further speciﬁed by a query for the default

value and a repository connection identiﬁer (at).

Process: ’process’ ID STRING? ’{’

Activity*

DataObject*

ProcessRule* ’}’

Activity: Process | Task | Operation

Task: ’task’ ID STRING?

Operation: ’operation’ ID STRING

(’{’ Parameter (’,’ Parameter)* ’}’)?

(’to’ ID)

Parameter: ID ID

DataObject: Variable | Document

Variable: ’variable’ ’collection’? ID STRING?

Document: ’document’ ’collection’? ID STRING?

CMIS = Content Management Interoperability Ser-

vices, ECM = Enterprise Content Management

MODELSWARD 2018 - 6th International Conference on Model-Driven Engineering and Software Development

272

(’default’ STRING)?

’at’ ID

2.1.3 Rules

Below the concrete syntax for structural elements is

complemented by the rule syntax. To focus on a de-

scription that makes the rule part of the language us-

able we omit a detailed discussion of the abstract syn-

tax. Global rules can be either mandatory (ensure) or

just recommendations (advise). A process rule can be

supplementary a milestone. Rules can have an identi-

ﬁer and a description which have to be separated from

the body using a colon. Macros must have an iden-

tiﬁer and can make use of dummy parameters. The

macro’s body is separated from the head using the iff

keyword.

GlobalRule: GlobalRuleType (ID? STRING? ’:’)? Expression

GlobalRuleType: ’ensure’ | ’advise’

ProcessRule: ProcessRuleType (ID? STRING? ’:’)? Expression

ProcessRuleType: ’ensure’ | ’advise’ | ’milestone’

Macro: ID (’(’ ID (’,’ ID)* ’)’)? ’iff’ Expression

According to the metamodel a rule expression is

a tree structure whereby its nodes are either unary or

binary expressions. This nesting has to be considered

in the grammar draft. For all operators the grammar

realises an inﬁx notation, i.e., the operator is always

located between its operands. Furthermore, the gram-

mars stipulates an operator priority ranking which, for

instance, assigns the highest priority to parentheses,

negations etc. and the lowest to the implication. The

universal quantiﬁer (forall) stipulates, based on the

objects matched by the ﬁrst pattern, all further pat-

terns. A predicate reference consists of the ID of the

referenced predicate (macro or rule) and a list of its

actual parameters. Object selectors can select objects

either using their identiﬁer (ObjectReference) or using

any other arbitrary property (ObjectConstraint). The

selection result can be assigned to a variable using the

colon operator and the variable identiﬁer.

Expression: Implies

Implies: Or (’implies’ Or)*

Or: And (’or’ And)*

And: Unary (’and’ Unary)*

Unary: ’(’ Expression ’)’

| ’not’ Unary

| ’exists’ Unary

| Forall

| PredicateReference

| ObjectSelector

Forall: ’forall’ ’(’ ObjectSelector ObjectSelector+ ’)’

PredicateReference: ID (’(’ LiteralOrReference

(’,’ LiteralOrReference)* ’)’)?

ObjectSelector: ObjectConstraint | ObjectReference

ObjectReference: Type ID (’:’ ID)?

ObjectConstraint: Type (’(’ ConstraintExpression ’)’)?

(’:’ ID)?

Type: ’task’ | ’operation’ | ’process’ | ’start’ |

To select objects by properties not by their identi-

ﬁer but instead by other properties one has to provide

an ObjectConstraint with a corresponding Constraint-

Expression. This again is formed by a tree structure of

unary and binary subexpressions. Operators are again

realised using the inﬁx notation with the same oper-

ator prioritization like the operators of rule expres-

sions. The properties may either be bound to variables

(PropertyBinding). or be compared to other variables

or constants (PropertyRestriction).

ConstraintExpression: ConstraintOr

ConstraintOr: ConstraintAnd (’or’ ConstraintAnd)*

ConstraintAnd: ConstraintUnary (’and’ ConstraintUnary)*

ConstraintUnary: PropertyBinding

| PropertyRestriction

| ’(’ ConstraintExpression ’)’

PropertyBinding: PropertyReference ’:’ ID

PropertyReference: PropertyKey RQID?

PropertyKey: ’this’ | ’of’ | ’by’ |

PropertyRestriction: PropertyReference Operator?

LiteralOrReference

Operator: ’=’ | ’!=’ |

LiteralOrReference: STRING | NUMBER | ID

2.2 Execution

Some of the elements of a DPIL process model un-

dergo a life cycle composed of events that is managed

by the engine. A human task, e.g., can be started and

completed while a data object can be read or writ-

ten. The current state of a process is then the series

of past events. Besides the static elements like human

tasks and data objects, a process model may specify

rules constraining that series of events. It may, e.g.,

claim that some data object may only be written after

some task has been started. These rules may be hard

to reﬂect, e.g., the legal framework or soft to reﬂect,

e.g., good practice. When the model is executed, the

engine simulates one event ahead for every model el-

ement and evaluates the resulting series of events on

the basis of the rules. Each simulated event that does

not violate any hard rule is related to an action that

engine interprets immediately. A simulated start of a

task by a certain participant, e.g., is interpreted as the

assignment of this task to the participant. If the start

event violates a soft rule, the action is marked as not

recommended.

After generating the events the engine has all

events for one process instance that might occur in

this instance available. The generation of these events

does not consider the modelled process rules. Thus

the innovative core of the execution is ﬁrst to eval-

uate these events based on the process rules and to

narrow them afterwards. For this purpose each pos-

sible event is combined with the former course of

Towards an Implementation of Data and Resource Patterns in Constraint-based Process Models

273

events of the current instance and for each of these

combined courses the engine decides to what extent

it conforms to the process rules. Hence, it must be

decided whether a simulated event and, consequently,

an enabled action in the process is forbidden, non-

recommended, neutral or recommended. The engine

itself imposes only few requirements on a rule-based

model. From the perspective of the engine a pro-

cess model M consists of model elements E and rules

R, i.e., M = (E, R). Model elements are entities for

which events might happen like, for instance, activ-

ities and data objects. A rule r is a logic propo-

sition that can be fulﬁlled or violated. The set of

rules R of a process model can be separated into

hard rules R

, soft rules R

and milestones R

, i.e.,

R = R

∪R

. A process instance I is a set of ma-

terialized events within one process. For the engine

these events do not have to be ordered. An instance

is considered to be completed as soon as all deﬁned

milestones are fulﬁlled. If no milestones are deﬁned

it cannot be determined when the corresponding pro-

cess is completed. In this case, for the engine, a pro-

cess instance can never be completed and is aborted

with the termination of the DPIL Navigator platform.

In order to simplify the subsequent deﬁnitions the

change δ of a set L to a different set R is deﬁned. A

change is a tuple consisting of the set of removed and

the set of added elements, i.e., δ(L,R) = (L\R, R\L).

For the change of the set {a, b} to the set {b, c} one

has: δ({a, b}, {b, c}) = ({a}, {c}).

2.2.1 Event Evaluation

An evaluation ρ is, in general, a set of violated rules of

R. Hence, it always pertains: ρ ∈ R. The event evalua-

tion ρ(I ∪ e) is the evaluation of an instance I after the

occurrence of an event e. The event is considered to

be forbidden if an evaluation after its occurrence over-

laps with the set of hard rules R

. It is considered to

be permitted if the intersection is empty.

f orbidden(e) ← ρ(I ∪ e) ∩ R

allowed(e) ← ρ(I ∪ e) ∩ R

(1)

An event is treated as ﬁnal if milestones are de-

ﬁned and the evaluation of the event does not overlap

with them. Thus, with the occurrence of the event all

milestones are fulﬁlled.

f inal(e) ← R

0 ∧ ρ(I ∪ e) ∩ R

0 (2)

2.2.2 Change of Instance Evaluation

The instance evaluation change ∆ρ

is the change of

the evaluation of an instance I with the occurrence of

an event e. Hence, it describes the repercussions of

the event on the instance.

∆ρ

(e) = δ(ρ(I), ρ(I ∪ e)) (3)

An event is considered to be neutral if the instance

evaluation change is empty, i.e. the event does not

have any repercussion on the instance.

neutral(e) ← ∆ρ

(e) = (

0) (4)

An event e is treated as recommended, if it is permit-

ted and if it leads to an abolition of previous violations

P of soft rules or milestones and no other rules are vi-

olated in consequence of this event.

recommended(e) ← ∆ρ

(e) =

(P,

0) ∧ P ∩ (R

∪ R

) 6=

(5)

Conversely it is non-recommended if it is permitted

but leads to new violations Q of soft rules or mile-

stones.

notRecommended(e) ← ∆ρ

(e) =

(P, Q) ∧ Q ∩ (R

∪ R

) 6=

(6)

2.2.3 Change of Event Evaluation

The event evaluation change ∆V

is the change of

the event evaluation regarding the previous execution

step:

∆ρ

(e) = δ(ρ(I ∪ e)

t−1

, ρ(I ∪ e)

) with

ρ(I ∪ e)

0 f or t < 0

(7)

Thus an event is considered to be changed if its event

evaluation change set is not empty or if the event de-

notes the ﬁrst time step.

changed(e) ← ∆ρ

(e) 6= (

0) ∨t = 0 (8)

An event is considered to be newly permitted if it was

forbidden in the previous time step and if it is permit-

ted in the current time step. Additionally it is treated

as newly permitted if it is permitted in the current time

step and if it denotes the ﬁrst time step and, by asso-

ciation, the ﬁrst event after the start of the process

instance. In this case no previous events exist.

newlyAllowed(e) ← ∆ρ

(e) =

(P, Q) ∧ Q ∩ R

0 ∧ (P ∩ R

0) ∨t = 0

(9)

An event is considered to be newly forbidden if it was

permitted in the previous time step but is forbidden in

the current one. Like in the previous paragraph it is

also treated as newly forbidden if it is forbidden in the

current time step and if it is the ﬁrst time step.

newlyForbidden(e) ← ∆ρ

(e) =

(P, Q) ∧ Q ∩ R

0 ∧ (P ∩ R

0) ∨t = 0

(10)

MODELSWARD 2018 - 6th International Conference on Model-Driven Engineering and Software Development

274

3 WORKFLOW PATTERNS

In this section, we evaluate the expressiveness of the

framework by describing how Data and Resource Pat-

terns can be implemented in DPIL. Therefore, we pro-

vide a brief description of the patterns as well as DPIL

model excerpts that reﬂect the desired behaviour. The

set of control ﬂow patterns (van Der Aalst et al., 2003)

mainly describes functionality stemming from classi-

cal procedural PAIS, i.e., traditional elements of pro-

cedural languages like BPMN. Therefore, they are

only conditionally applicable for declarative process

modelling and are not considered in this paper.

3.1 Workﬂow Data Patterns

The way in which process data is structured and in-

cluded in the process is described in the workﬂow data

patterns (Russell et al., 2005a). The patterns are struc-

tured in visibility of data, interaction with data, data

transfer and data-based routing.

3.1.1 Visibility

A data variable is visible within the selected process

instance (WDP5) and within the corresponding sub-

processes (WDP2). In order to limit the visibility of

a data object to certain activities (WDP1), read and

write events can be constrained in the following way.

local(task, object) iff

read(of object at :tr) implies start(of task at < tr at :ts)

and not complete(of task at > ts at < tr)

task CalculateFlightPath

variable WorkingTrajectory

ensure local (CalculateFlightPath, WorkingTrajectory)

This way the data object WorkingTrajectory is

only visible within the activity CalculateFlightPath.

The lifespan of variables and its values, however, is

equal to the duration of the process instance. Access

to data objects can be dependent on the correspond-

ing process instance (WDP6). The following code

shows how it is possible to access different collections

of documents in activity AccessFolder, depending on

which folder has been selected in SelectFolder:

task SelectFolder

task AccessFolder

document collection FolA default "/A" at Local

document collection FolB default "/B" at Local

variable FolderName

ensure produces (SelectFolder, FolderName)

ensure sequence(SelectFolder, AccessFolder)

ensure read(of FolA) implies write(of FolderName value "A")

ensure read(of FolB) implies write(of FolderName value "B")

In order to make environment data accessible by

the system, it has to be read by means of an operation

method and written in a variable. This is explained

by the following model that loads the current temper-

ature to a variable Temperature.

operation GetTemperature "http://service.org/temperature"

to Temperature

task CheckTemperature

variable Temperature

ensure start(of CheckTemperature) implies

return(of GetTemperature)

3.1.2 Interaction

Data objects are visible for all activities of the case.

Their values can be communicated between these ac-

tivities as well (WDP9). Since data objects are also

visible for all subprocesses of a process case, val-

ues can also be passed to them implicitely (WDP10)

and reused (WDP11) by them. Since multi instance

activities are not supported in DPIL, it is also not

possible to pass data values between them (WDP12,

13). Data interaction between several parallel process

cases (WDP14) can be implemented by means of ex-

ternally managed documents, i.e., a CMIS compatible

document management system. As shown above, en-

vironment data can be passed (WDP15) and queried

(WDP16) by means of operations, i.e., script calls.

Data objects can be implicitely received during activ-

ity execution (WDP17) by means of externally man-

aged and changed documents. This way data objects

can also be returned (WDP18). Since data objects are

visible for all tasks of a process this also holds for a

complete instance (WDP21, 22).

In case that only externally managed documents

are used within the process, data values of corre-

sponding process cases are synchronized with the

connected document management system. The states

of process cases is therefore visible to the environ-

ment. Furthermore, data values can be pushed from

cases to the environment by means of a correspond-

ing operation call at the end of a case (WDP19). In

any case data can be passed from the environment to

running cases by means of externally managed docu-

ments (WDP20). The DPIL Navigator supports pro-

cess oriented indicators like the number of completed

cases of a process. These numbers can be transfered

to the environment regularly (WDP23) or offer them

upon request (WDP26).

Towards an Implementation of Data and Resource Patterns in Constraint-based Process Models

275

3.1.3 Transfer

Access to data objects generally happens by reference

(WDP30). Locking mechanisms can be implemented

by means of constraints on write and read events

(WDP31). The transformation of values (WDP32, 33)

can be handled by means of service operations:

operation FromKmhToMph "http://service.org/kmhToMph"

with SpeedKmh to SpeedMph

task ReviewSpeed

variable SpeedKmh

variable SpeedMph

ensure start(of ReviewSpeed) implies return(of FromKmhToMph)

ensure invoke(of FromKmhToMph) implies write(of SpeedKmh)

3.1.4 Data-based Routing

Pre- and postconditions for activities can be imple-

mented by constraining start and compete events of

activities. Events can depend on the existence of a

value or on a concrete value (WDP34-37). Both pat-

terns are highlighted in the following example:

consumes(t, d) iff start(of t) implies write(of d)

produces(t, d) iff complete(of t) implies write(of d)

task RocketInitiation

variable Countdown

variable IgnitionData

ensure consumes(RocketInitiation, Countdown)

ensure start(of RocketInitiation) implies

write(of Countdown value 2)

ensure produces(RocketInitiation, IgnitionData)

Activities can be triggered by the environment

(WDP38):

task Shutdown

operation MonitorAlarm "org.example.Alarm.monitor()" to Alarm

variable Alarm

ensure start(of Shutdown) implies return(of MonitorAlarm)

Activities can also be triggered by certain data val-

ues (WDP39):

task RebalancePortfolio

variable LoanMargin

ensure start(of RebalancePortfolio) implies

write(of LoanMargin value > 0.85)

Data-based routing (WDP40) in declarative mod-

els corresponds to an exclusive split (WCP4) or a

multi choice branch (WCP6), respectively.

3.2 Workﬂow Resource Patterns

Patterns concerning the organizational aspects of a

process are summarized in (Russell et al., 2005b)

where participants are referred to as resources. They

are divided into patterns that refer to the design phase

of the process (creation), to the systems perspective

(push), to the participants perspective (pull), to excep-

tional situations (detour), to event- or context-based

execution (auto-start), to visibility and to multiple

participants working on the same task. DPIL assumes

a simple organizational metamodel where identities

and groups can be interconnected by relations of a

certain relation type. The information is taken from

a central organizational model like, e.g., an LDAP

service and is only referenced within the DPIL pro-

cess model. Human participation in a DPIL pro-

cess is implemented using the task type of activity.

From the engines viewpoint, a task may be started

and completed. The task management service of the

DPIL platform extends the life cycle of a task by re-

serve/release and suspend/resume states.

The simplest method of distribution is the direct

allocation of a participant to a task at design time

(WRP1). Besides this, tasks may be distributed on

the basis of roles (WRP2), capabilities (WRP8) or or-

ganizational relationships (WRP10). The following

example process contains each of these patterns:

use identity Fred

use group Manager

use group Engineer

use relationtype hasRole

use relationtype hasJob

use relationtype isManagerOf

direct(t, i) iff start(of t) implies start(of t by i)

role(t, r) iff start(of t by :i)

implies relation(subject i predicate hasRole object r)

process Organisation {

task FixBentley

task ApproveTravelRequisition

task AirframeExamination

task ClaimExpenditure

task AuthoriseExpenditure

advise direct(FixBentley, Fred)

advise role(ApproveTravelRequisition, Manager)

advise start(of AirframeExamination) implies

start(of AirframeExamination

by :i by.servicingExperienceInYears >= 10)

and relation(subject i predicate hasJob object Engineer)

advise start(of ClaimExpenditure by :claimer)

and start(of AuthoriseExpenditure by :authoriser)

implies relation(subject authoriser

predicate isManagerOf

object claimer)

}

The above model references the identity Fred, two

groups and three relation types. The task FixBentley

should only be performed by Fred (WRP1). The rule

MODELSWARD 2018 - 6th International Conference on Model-Driven Engineering and Software Development

276

is soft (type advise) so that the assignment to Fred

is recommended but not mandatory, i.e., other partic-

ipants are allowed to perform the task but they are

advised not to do so. The task ApproveTravelRequisi-

tion should be performed by a participant having the

role of a Manager (WRP2). The AirframeExamina-

tion should be performed by an Engineer having at

least ten years of servicing experience (WRP8). Fi-

nally, AuthoriseExpenditure should be performed by

the manager of the participant who has performed

ClaimExpenditure (WRP10). DPIL supports the sep-

aration (WRP5) and the binding (WRP7) of duties for

activities. The following model shows how different

tasks are performed by the same and by different re-

sources:

separate(a, b) iff

start(of b by :ib) implies start(of a by != ib)

retain(a, b) iff

start(of b by :ib) implies start(of a by ib)

process Organisation {

task UmpireMatch

task PrepareMatchReport

task PrepareCheque

task CountersignCheque

advise retain(UmpireMatch, PrepareMatchReport)

advise separate(PrepareCheque, CountersignCheque)

}

An assignment can be deferred (WRP3) by assign-

ing the concrete identity that should perform a task at

runtime through the value of a certain data object:

task AssessDamage

variable Performer

advise start(of AssessDamage) implies

variablewrite(of Performer value :p)

and start(of AssessDamage by.id p)

DPIL does not offer any means of referencing ear-

lier process instances (WRP9) and is not able to per-

form any scheduling (WRP15-17). Activities can be

offered without obligation of a single (WRP12) or of

several resources (WRP13) by modelling assignment

constraints as soft rules (advise). A mandatory as-

signment to a certain resource (WRP14) can be speci-

ﬁed by means of hard rules (ensure). Participants can

reserve activities, i.e., tasks are then marked for other

resources (WRP21). Concrete work on tasks can be

started afterwards (WRP22). Activities can, however,

also be started directly as soon as they have been en-

abled (WRP23). Work list items can’t be sorted by the

process model (WRP24), however, by process partici-

pants (WRP25). A resource can perform several tasks

at the same time (WRP42) and decide herself which

task to perform next (WRP26). Tasks can be released

after reservation (WRP29) and marked as interrupted

(WRP32). Activities can be completed directly after

the start, i.e., skipped, if this doesn’t violate a con-

straint (WRP33). Without constraining rules an ac-

tivity can be repeated arbitrary often (WRP34). Rep-

etitions can be constrained if a certain event, e.g., a

milestone, has been reached. Resources can perform

prework (WRP35) by deﬁning certain temporal se-

quences only as recommended instead of obligatory.

Activities are created and assigned at the same time

(WRP36), however, can’t be started directly after an

assignment (WRP37). Further activities can be en-

abled directly after the completion of an activity. As-

signed activities together with their current agent can

be visualized to all resources (WRP41). An activity

is only assigned to a single resource at the same time

(WRP43). Summing up, the DPIL framework sup-

ports 62% of the organizational and 75% of the data

oriented workﬂow patterns. Therefore, the conducted

work shows that the biggest part of workﬂow data and

resource patterns can be implemented by means of

DPIL and the DPIL Navigator platform. Note that to

the best of our knowledge there is currently no com-

parative analysis of other declarative language frame-

works w.r.t. the Workﬂow Patterns.

4 RELATED WORK

The work at hand relates to declarative process man-

agement with a strong focus on practical applicabil-

ity of developed concepts. The Declare framework

was designed for modelling and executing declara-

tive business processes. In its most publicized vari-

ant, a Declare process model is built from a set of rule

templates each of which is mapped to an expression

in Linear Temporal Logic (LTL). The resulting LTL

formula is then converted to an automaton for execu-

tion (Pesic, 2008). Declare only constrains the starts

of activities and interrelates them temporally. Data

oriented aspects and the organizational perspective

are completely missing in Declare. The approach pro-

posed in (Lamma et al., 2007) allow for the speciﬁca-

tion of constraints that go beyond the traditional De-

clare templates. In (Westergaard and Maggi, 2012),

the authors deﬁne Timed Declare, an extension of De-

clare that relies on timed automata. In (Montali et al.,

2013), the authors introduce for the ﬁrst time a data

aware semantics for Declare. In (Burattin et al., 2015)

a general multi perspective LTL semantics for Declare

(MP-Declare) has been presented. Here, Declare is

extented with elements of ﬁrst order logic to refer to

data values in constraints. Data aware as well as gen-

eralized MP-Declare models are currently only sup-

ported in the context of conformance checking (Bu-

Towards an Implementation of Data and Resource Patterns in Constraint-based Process Models

277

rattin et al., 2015) and process discovery (Sch

onig

et al., 2016). A system supported modelling and ex-

ecution is currently not possible. CLIMB (Montali,

2010) is a ﬁrst-order logic declarative language for

the speciﬁcation of interaction models. Here, the De-

clare is also extented with further process perspectives

like data and resources. As for MP-Declare, there

is no system support for modelling and execution of

CLIMB models. The DCR Graph framework (Slaats

et al., 2013) and graphical representation is similar

to the Declare. The DCR Graph model directly sup-

ports execution of the process model based on the

notion of markings of the graph. The framework

lacks system support for data and resource oriented

aspects. The Case Management Model and Nota-

tion (CMMN)

represents recent efforts to standardize

declarative business process modelling. CMMN ne-

glects the organizational perspective. The performer

can only be selected on the basis of a role and the per-

spective is completely missing in the graphical repre-

sentation of CMMN models. System support for data

in CMMN is currently is still not available.

5 CONCLUSIONS

In this paper, we introduced the declarative process

modelling and execution framework DPIL that cov-

ers resource and data modelling. Expressiveness and

functionality of the framework have been evaluated

by means of the Workﬂow Data and Resource Pat-

terns. We described concrete model excerpts that im-

plement frequently needed patterns. Summing up,

the work at hand can serve as an instruction man-

ual for implementing a declarative process manage-

ment solution in practical applications. Based on the

lessons learned the DPIL framework is currently used

in several industry projects to digitally support oper-

ative processes. Future research in this context will

focus on further improving modelling and execution

support for DPIL models, e.g., by a web-based mod-

elling tool. DPIL is currently a textual language that

might be difﬁcult to read and understand by end users.

Therefore, a graphical language and editor is desired.

REFERENCES

Burattin, A., Maggi, F. M., and Sperduti, A. (2015). Con-

formance checking based on multi-perspective declar-

ative process models. preprint arXiv:1503.04957.

Fahland, D., L

ubke, D., Mendling, J., Reijers, H., Weber,

B., Weidlich, M., and Zugal, S. (2009). Declarative

http://www.omg.org/spec/CMMN/

versus imperative process modeling languages: The

issue of understandability. In Enterprise, Business-

Process and Information Systems Modeling, pages

353–366.

Jablonski, S. and Bussler, C. (1996). Workﬂow manage-

ment: modeling concepts, architecture and implemen-

tation.

Lamma, E., Mello, P., Riguzzi, F., and Storari, S. (2007).

Applying inductive logic programming to process

mining. In Inductive Logic Programming, pages 132–

146.

Montali, M. (2010). Speciﬁcation and veriﬁcation of

declarative open interaction models: a logic-based

approach, volume 56. Springer Science & Business

Media.

Montali, M., Chesani, F., Mello, P., and Maggi, F. M.

(2013). Towards data-aware constraints in declare. In

SAC, pages 1391–1396. ACM.

Pesic, M. (2008). Constraint-based workﬂow management

systems: shifting control to users.

Reichert, M. and Weber, B. (2012). Enabling ﬂexibil-

ity in process-aware information systems: challenges,

methods, technologies. Springer Science & Business

Media.

Reijers, H. A., Slaats, T., and Stahl, C. (2013). Declarative

modeling–an academic dream or the future for bpm?

In BPM, pages 307–322. Springer.

Russell, N., Ter Hofstede, A. H., Edmond, D., and van der

Aalst, W. M. (2005a). Workﬂow data patterns: Iden-

tiﬁcation, representation and tool support. In Inter-

national Conference on Conceptual Modeling, pages

353–368. Springer.

Russell, N., van der Aalst, W. M., Ter Hofstede, A. H.,

and Edmond, D. (2005b). Workﬂow resource pat-

terns: Identiﬁcation, representation and tool support.

In CAISE, pages 216–232.

Sch

onig, S., Ackermann, L., and Jablonski, S. (2017). DPIL

Navigator 2.0: Multi-Perspective Declarative Process

Executio. In BPM Demos.

Sch

onig, S., Di Ciccio, C., Maggi, F. M., and Mendling,

J. (2016). Discovery of multi-perspective declarative

process models. In ICSOC, pages 87–103. Springer.

Sch

onig, S. and Zeising, M. (2015). The DPIL Framework:

Tool Support for Agile and Resource-Aware Business

Processes. In BPM Demos.

Slaats, T., Mukkamala, R. R., Hildebrandt, T., and Mar-

quard, M. (2013). Exformatics declarative case man-

agement workﬂows as dcr graphs. In BPM, pages

339–354. Springer.

Vacul

ın, R., Hull, R., Heath, T., Cochran, C., Nigam, A.,

and Sukaviriya, P. (2011). Declarative business arti-

fact centric modeling of decision and knowledge in-

tensive business processes. In EDOC, pages 151–160.

van Der Aalst, W. M., Ter Hofstede, A. H., Kiepuszewski,

B., and Barros, A. P. (2003). Workﬂow patterns. Distr.

and parallel databases, 14(1):5–51.

Westergaard, M. and Maggi, F. M. (2012). Looking into the

future: Using timed automata to provide a priori ad-

vice about timed declarative process models. In OTM,

pages 250–267. Springer.

MODELSWARD 2018 - 6th International Conference on Model-Driven Engineering and Software Development

278