The Analysis of Data-Flow and Control-Flow in Workﬂow Processes

Using Maude

Oana Otilia Captarencu

Faculty of Computer Science, ”Alexandru Ioan Cuza” University, Iasi, Romania

Keywords:

Workﬂow Processes Veriﬁcation, Data Flow Errors, Petri Nets, Model Checking, Rewriting Logic, Maude.

Abstract:

A business process consists of coordinated tasks that take place inside an organization in order to achieve a

speciﬁc business objective. The process also involves data, that can be used/produced by tasks or used to

control the execution of tasks. A workﬂow is the automation of a business process. Veriﬁcation of workﬂow

correctness usually focuses on the control-ﬂow of workﬂows (which regards the tasks and their order of execu-

tion). Data anomalies can prevent the correct execution of the process, even if it is correct at the control-ﬂow

level, or can produce undesired results. Thus, data information plays an important role in workﬂow analy-

sis. In this paper we propose an analysis technique for workﬂows with data, based on Petri nets and on the

rewriting logic based language Maude: we use a special class of Petri nets, workﬂow nets with data, to model

workﬂow processes with data and propose a translation of workﬂow nets with data into rewrite theories in

Maude. This will allow the application of model checking techniques to detect data errors, verify speciﬁc

properties regarding data and verify the correctness of the workﬂow.

1 INTRODUCTION

Information systems that allow the design, manage-

ment, optimization and automation of business pro-

cesses are critical to the success of businesses and

organizations. A business process consists of a set

of coordinated tasks organized to achieve a speciﬁc

business objective. The process also involves re-

sources necessary for executing the tasks and data:

data used/produced by tasks or data used to control

the execution order of tasks. A workﬂow is deﬁned as

the automation of a business process. A large body of

research has been dedicated to the formal modelling

and veriﬁcation of workﬂow processes. One aspect

that has been intensively studied is the veriﬁcation

of the control-ﬂow of workﬂows, which refers to the

tasks and their order of execution. As a result, several

notions of workﬂow correctness have been proposed

(Aalst et al., 2010). The data aspect (the data-ﬂow)

is an important part of the workﬂow process: even if

the process is correct at the control-ﬂow level, data-

ﬂow anomalies can prevent the correct execution of

the process or can produce undesired results. Most

of the research regarding the data-ﬂow aims either at

deﬁning and detecting data-ﬂow errors in workﬂow

processes or at extending the notion of correctness

in order to capture the interplay between the control-

ﬂow and data-ﬂow in workﬂows, but do not offer anal-

ysis techniques to do both. The current approaches

assume the workﬂow uses a set of data elements and

consider a set of data operations that can be performed

on data elements during the execution of tasks (read,

write, delete). Some approaches also consider data

dependent predicates that are used to control the exe-

cution order of tasks in the workﬂow.

In many research approaches that try to identify

the data ﬂow errors, the workﬂow process has vari-

ous restrictions: it contains only simple loops (Sun

et al., 2006), it considers only the read/write opera-

tions (M

ulle et al., 2019; von Stackelberg et al., 2014;

Eshuis, 2006), it does not consider data dependent

predicates for controlling the task execution (Eshuis,

2006; Sun et al., 2006; Meda et al., 2007; Liu et al.,

2020; Xiang et al., 2017; Xiang et al., 2021a). Even

in the approaches in which the process has no such

restrictions (Zhao et al., 2022; Xiang et al., 2021b),

only some data ﬂow errors are considered or the cor-

rectness of the workﬂow with data restrictions is not

studied.

The approaches that discuss the correctness of the

workﬂow with data (Kheldoun et al., 2017; Sidorova

et al., 2011; Fan et al., 2007; He et al., 2018) usually

do not address the identiﬁcation of data ﬂow errors.

cka et al. (Tr

cka et al., 2009) use temporal logic to

Captarencu, O.

The Analysis of Data-Flow and Control-Flow in Workﬂow Processes Using Maude.

DOI: 10.5220/0011844800003467

In Proceedings of the 25th International Conference on Enterprise Information Systems (ICEIS 2023) - Volume 2, pages 373-384

ISBN: 978-989-758-648-4; ISSN: 2184-4992

 2023 by SCITEPRESS – Science and Technology Publications, Lda. Under CC license (CC BY-NC-ND 4.0)

373

describe a set of data-ﬂow errors and a notion of cor-

rectness for the workﬂow. They propose a Petri Net

model - workﬂow nets with data (WFD-nets), they de-

ﬁne an unfolding of WFD-nets into classical Petri nets

and use it to apply model-checking techniques to ver-

ify the existence of data-ﬂow errors and the correct-

ness of the workﬂow. This solution does not allow

the explicit representation of data elements and suf-

fers from the state explosion problem, due to the size

of the unfolded net.

The existing correctness notions do not impose

any conditions on data when the workﬂow terminates,

although workﬂow processes are often required to

produce speciﬁc data that should be available at the

end of the process. In this paper we propose notions

of correctness that permit the speciﬁcation of data el-

ements that should be present when the process starts

and when the processes terminates. It will be possi-

ble to specify that all data elements from a given set

should be present or at least one element from a given

set should be present when the process terminates.

Our approach uses the WFD-nets deﬁned in

(Tr

cka et al., 2009) as a model for workﬂow pro-

cesses with data and proposes the speciﬁcation of

WFD-nets as rewrite theories in Maude, providing a

formal semantics for WFD-nets. Maude is a declar-

ative programming language and high-performance

system based on rewriting logic. Rewriting logic is a

computational logic that can naturally deal with state

and concurrent computations and it has been used

as a semantic framework for a wide range of lan-

guages and models of concurrency, including Petri

nets (Meseguer, 1992). This approach will allow us

to use temporal logic and the efﬁcient Maude model

checking tool to verify the existence of data anoma-

lies, speciﬁc data properties and correctness proper-

ties for workﬂow processes with data.

2 PRELIMINARIES

This section reviews the terminology and notations re-

lated to Petri nets and workﬂow nets. For details, the

reader is referred to (Reisig, 1985), (Aalst, 1998).

A Petri net is a triple N = (P, T, F), where P is

a ﬁnite set of places, T is a ﬁnite set of transitions

(P ∩ T =

0), F ⊆ (P × T ) ∪ (T × P) is a set of arcs

(ﬂow relation).

For x ∈ P∪T , the preset of x is •x = {y|(y, x) ∈ F}

and the postset of x is x• = {y|(x, y) ∈ F}. The state

(or the marking), is a function: m : P → N (N denotes

the set of natural numbers). A marking can be seen as

a multiset of places.

A transition t is said to be enabled (in a marking

m) iff: m(p) ≥ 1, ∀p ∈ •t. If an enabled transition

t ﬁres, it changes the marking m into m

′

: m

′

(p) =

m(p) −1, ∀p ∈ •t and m

′

(p) = m(p) + 1, ∀p ∈ t•. We

write m[t⟩m

′

If σ = t

. . .t

∈ T

∗

is a set of transitions such

that m

⟩m

⟩. . . [t

⟩m

, we also write m

[σ⟩m

(or

[∗⟩m

). Marking m

is said to be reachable from

marking m

. If (N, m

) is a marked Petri net, the set

of reachable markings of N is denoted by [m

⟩. Let

(N, m

) be a marked Petri net. A transition t is quasi-

live (not dead) in (N, m

) if ∃m ∈ [m

⟩ such that m[t⟩.

Workﬂow nets (WF-nets) are are widely used Petri

net model for workﬂow processes, introduced in

(Aalst, 1998).

A Petri net WF=(P,T,F) is a WF-net iff: (1) PN has

a source place i and a sink place o such that •i =

and o• =

0 and (2) if we add a new transition t

∗

to PN

such that •t

∗

= {o} and t

∗

• = {i}, then the resulting

Petri net is strongly connected.

The marking m with m(i) = 1 and m(p) = 0, ∀p ̸=

i represents the beginning of the process (the initial

marking, denoted by i). The marking m with m(o) = 1

and m(p) = 0, ∀p ̸= o , represents the termination of

the process (the ﬁnal marking, denoted by o).

A notion of soundness was deﬁned for WF-nets,

expressing the minimal conditions a correct workﬂow

should satisfy (Aalst, 1998).

A workﬂow net W F = (P, T, F) is sound iff:

(1) the ﬁnal marking o can be reached from ev-

ery reachable marking m (termination condition):

(∀m)((i[∗⟩m) =⇒ (m[∗⟩o)); (2) all the transitions in

W F are quasi-live:(∀t ∈ T )(∃m, )(i[∗⟩m[t⟩).

3 WORKFLOW NETS WITH

DATA

Workﬂow Nets with Data (WFD-nets) have been in-

troduced in (Tr

cka et al., 2009). WFD-nets extend

WF-nets with data elements, three possible operations

on data elements (read, write, delete) and guards for

transitions.

If D denotes the set of data elements, a predicate is

an expression of the form P(d

, . . . , d

), where P is the

predicate name, n ≥ 0, d

∈ D, ∀i ∈ 1 . . . n. We refer to

a predicate P(d1, . . . , d

) simply by P and we denote

by vars(P) the data elements the predicate depends on

(i.e., vars(P) = {d

, . . . , d

}).We denote by Preds the

set of predicates. A guard for a transition is a pred-

icate or the negation of a predicate (over D). The

following deﬁnition introduces Workﬂow Nets with

Data (WFD-nets):

A WFD-net is a tuple

W FD = (P, T, F, D, G, Read,W rite,Delete, Guard)

ICEIS 2023 - 25th International Conference on Enterprise Information Systems

374

c = client application data

le = loan estimate

chr = report based on credit history

f = client mortgage file

rn = rejection notice

cd = closing documents

ple

------------

r:{c}

w:{le}

------------

r:{c}

cch

------------

r:{c}

w:{chr}

srn

------------

r:{chr}

w:{rn}

[!okCH(chr)]

pmf

------------

r:{c,chr}

w:{f}

[okCH(chr)]

rmf

------------

r:{f}

w:{f}

rja

------------

r:{f,chr}

w:{rn}

dl:{f,chr}

[!okData(chr,f)]

scd

------------

r:{f,chr}

w:{cd}

dl:{f,chr}

[okData(chr,f)]

Figure 1: An example of a WFD-net.

• (P, T, F) is a WF-net (the underlying WF-net);

• D is the set of data elements;

• G is the set of guards over D: G = {P|P ∈

Preds} ∪ {!P|P ∈ Preds} ;

• Read : T → 2

the data elements read by each

transition in T

• W rite : T → 2

the data elements written by the

transitions in T

• Delete : T → 2

the data elements deleted by the

transitions in T

• Guard : T → G is a partial function which assigns

guards to transitions in T

The set of data elements used by a transition t is

vars(t) = Read(t) ∪ vars(Guard(t)). A transition t in

a WFD-net can ﬁre if it is enabled in the marking of

the underlying WF-net, if all the data elements it uses

(data elements from vars(t)) are deﬁned and its guard

is true. If some data element is written by a transition,

it becomes available /deﬁned. A data element that is

deleted by a transition becomes undeﬁned. If a transi-

tions performs all the operations on a data element d,

the order of operations is: read, write, delete.

A conﬁguration of a WFD-net is : < M, DS, σ >,

where M is the marking of the net, DS is the set of

deﬁned data elements, σ : Preds → {true, f alse} is a

function that describes the value of every predicate.

In our approach we will allow the speciﬁcation of

a set of data elements available/deﬁned when the pro-

cess starts. Thus, the initial conﬁguration is

< i, DS, σ >, where DS is a set of initial data ele-

ments and σ(P) = f alse, ∀P ∈ Preds.

The function de f ined : Preds × 2

→ Bool is

deﬁned such that for any P ∈ Preds and DS ⊆ D,

de f ined(P, DS) is true iff vars(P) ⊆ DS.

Function de f inedPreds : 2

Preds

× 2

→ Bool is

the extension of de f ined to sets of predicates.

The example in Figure 1 depicts a WFD-net

modelling the processing of a mortgage applica-

tion in a bank. The data elements involved are:

D = {c, chr, f, le, rn, cd}. The data element avail-

able (deﬁned) when the process starts is the client

application data (c) - which includes the client per-

sonal information, property information, client debts,

income etc; Transition ra (receive application) per-

forms a read operation on c. Afterwords two actions

will be executed in parallel: ple (provide loan es-

timate) - the client is provided with a loan estimate

(the data element le is written) which details the es-

timated closing costs and the monthly payment; cch

(check credit history): the loan ofﬁcer will check the

clients’ credit history, providing a report (chr). After

cch, if predicate okCHR(chr) is false, a rejection

notice is sent to the client (srj), explaining the rea-

son for the rejection of the application. The data ele-

ment rn (rejection notice) is written. If okCHR(chr)

is true, pmf (prepare mortgage ﬁle) is executed: a

loan ofﬁcer veriﬁes all the information provided by

the client, adding additional information (title search,

tax transcripts etc) and prepares a ﬁle: the data ele-

ment f is written and r, chr are read. The next action,

rmf (review mortgage ﬁle), is performed by another

employee who reviews the ﬁle (f is read) and updates

it with additional data (f is written again). The ac-

tion scd (send closing documents) will be executed

if the predicate okData(chr, f) is true (the loan is

approved). In this case, a set of closing documents

(cd), will be written and sent to the client for signing

and the workﬂow terminates. Data elements f and

chr are deleted, as they are no longer needed. If the

predicate is false, the action rja (reject application)

is performed: a rejection notice (rn) is written and f

and chr are deleted.

4 SPECIFICATION OF

WORKFLOW NETS WITH

DATA IN MAUDE

Maude is a high-level language and an efﬁcient sys-

tem based on rewriting logic. Rewriting logic is a

computational logic that can naturally deal with state

and express both concurrent computations and logical

deduction (Meseguer, 1992).

A concurrent system can be speciﬁed in Maude as

a rewrite theory (Σ; E ∪ A; R) in the rewriting logic.

(Σ;E ∪ A) is a theory in the equational membership

logic, which speciﬁes the static part of the system (its

states) and R is the set of possibly conditional rewrite

rules describing the dynamic part of the system - the

The Analysis of Data-Flow and Control-Flow in Workﬂow Processes Using Maude

375

transitions between the states.

Σ, called the signature, speciﬁes the type structure:

sorts, subsorts, kinds, and operators. E is the col-

lection of memberships and equations between terms

and A is the collection of equational attributes (assoc,

comm, and so on) declared for the different operators.

The (possibly conditional) rewrite rules have the

form t → t

′

if C where t and t

′

are terms in Σ and C is

a condition. A rule t → t

′

can be seen as a local state

transition, stating that if a portion of a system’s state

matches the pattern described by t, then that portion

can change to the corresponding instance of t

′

. The

rule can be applied only if the condition C is satis-

ﬁed. Furthermore, such a local state change can take

place concurrently with any other nonoverlapping lo-

cal state changes. Rewriting logic is therefore a logic

of concurrent state change.

A Maude program containing only a theory in the

membership equational logic is called a functional

module. Computation in a functional module is ac-

complished by using the equations as rewrite rules:

each step of rewriting is a step of replacement of

equals by equals until a canonical form is found.

A Maude program containing the speciﬁcation of

a rewrite theory is called a system module. Computa-

tion in such a module is rewriting logic deduction, in

which rewriting in the membership equational logic

with the axioms E ∪ A is combined with rewriting

computation with the rules R.

A concurrent system can be speciﬁed using a func-

tional module which contains the equational theory

describing its states and a system module which in-

cludes the functional module and speciﬁes the set of

rewrite rules describing the transitions between states.

In order to specify WFD-nets in Maude, we will

ﬁrst describe the structural aspects of a WFD-net, as

well as the markings and conﬁgurations of a WFD-net

using a theory in the equational logic.

The sorts of the equational theory are: Places

(the sort that represents the places of a WFD-net);

Transitions (the sort that represents the transitions

of the net); Marking (the markings of a WFD-net);

Config (the conﬁgurations of a WFD-net); Data

(the set of data elements); DataOp represents a set

of operations on data elements (for any d ∈ Data,

DataOp will contain elements w(d), r(d), dl(d)

which correspond to the possible data operations on

d); PredValue (a set of predicate values).

We will also use a predeﬁned data type in

Maude - a parametrized set, in order to rep-

resent sets of Data elements (Set{Data}), sets

of predicates (Set{Preds}), sets of data opera-

tions (Set{DataOp}) and sets of predicate values

(Set{PredValue}).

We deﬁne the subsort relation:

subsort Places < Marking (which describes

that any element of Places is also an element of

Marking).

The set of operators related to the sort Marking

are declared in Maude as follows:

op null : -> Marking .

op __ : Marking Marking -> Marking

[ctor assoc comm id: null] .

According to this declaration, null is a constant (rep-

resenting the empty marking). A union operator con-

structs a marking from two existing markings. The

attribute ”assoc” (resp. ”comm”) is used to declare

that the operator is associative (resp. commutative).

The constructor operators w, r and dl, with the do-

main sort Data and the result sort DataOp, construct

the elements of DataOp:

ops w r dl : Data -> DataOp [ctor] .

The operator { : } is used to construct pred-

icate values which can be assignments of the

form {P : value}, where P is a predicate and

value ∈ {true, false}:

op {_:_} : Preds Bool -> PredValue [ctor] .

We also deﬁne operators that will describe several

functions on the data types (together with equations

that will deﬁne their semantics) and a constructor op-

erator for conﬁgurations:

op vars : Preds -> Set{Data} .

op defined : Preds Set{Data} -> Bool .

op definedPreds : Set{Preds} Set{Data}

-> Bool .

op changeValues : Set{PredValue} Set{Preds}

-> Set{PredValue} .

ops readOps writeOps deleteOps : Set{Data}

-> Set{DataOp} .

ops read write delete dops : Transitions

-> Set{Data} .

var Pr : Set{PredValue} .

var b : Bool .

vars W pn : Preds .

var pset : Set{Preds} .

var DS : Set{Data} .

var E : Data .

eq defined(pn,DS) = intersection(vars(pn),DS)

== vars(pn) .

eq definedPreds(empty,DS) = false .

eq definedPreds(pn,DS) = defined(pn,DS) .

eq definedPreds ((pset,pn), DS) =

definedPreds(pset,DS) and defined(pn,DS) .

eq changeValues(empty, pset) = empty .

eq changeValues (Pr, empty) = Pr .

eq changeValues((Pr,{W : b}), W) =

Pr,{W : not b} .

eq changeValues ((Pr,{W : b}), (pset,W) ) =

changeValues(Pr,pset),{W : not b} .

ICEIS 2023 - 25th International Conference on Enterprise Information Systems

376

eq changeValues (Pr, pset) = Pr [owise] .

eq readOps(empty) = empty .

eq readOps(E) = r(E) .

eq readOps ((DS,E)) = readOps(DS),r(E) .

eq writeOps(empty) = empty .

eq writeOps(E) = w(E) .

eq writeOps ((DS,E)) = writeOps(DS),w(E) .

eq deleteOps(empty) = empty .

eq deleteOps(E) = dl(E) .

eq deleteOps ((DS,E)) = deleteOps(DS),dl(E) .

var t : Transitions .

eq dops(t) = readOps(read(t)),

writeOps(write(t)),

deleteOps(delete(t)) .

op <_,_,_,_> : Marking Set{Data}

Set{PredValue}

Set{DataOp} -> Config [ctor].

op initConfig : -> Config .

The operators vars, defined and definedPreds

will be used to describe the functions with the same

name deﬁned in section 3.

The operator changeValues will describe a

function which, given a set of elements from

PredValue (a set {{P : value}|P ∈ Preds}) and

a set of predicate names PSet, will produce the

following set: {{P : value}|P ∈ Preds \ PSet} ∪

{{P : ¬value}|P ∈ PSet} (the value of the predicates

from PSet will be changed).

The operators readOps, writeOps and

deleteOps will produce a set of DataOp ele-

ments corresponding to the data elements in the

argument (DS): readOps(DS) = {r(d)|d ∈ DS},

writeOps(DS) = {w(d)|d ∈ DS},

deleteOps(DS) = {dl(d)|d ∈ DS}.

The operators read, write and delete will

describe the data elements read, written or

deleted by a transition. The operator dops will

produce the set of data operations for a given

transition: dops(t) = {r(d)|d ∈ Read(t))} ∪

{w(d)|d ∈ Write(t)} ∪ {dl(d)|d ∈ Delete(t)}.

The conﬁguration of a WFD-net is given by the

sort Config, deﬁned using the constructor operator

op <_,_,_,_> : the ﬁrst three arguments of the op-

erator correspond to the elements from the deﬁnition

of a conﬁguration from section 3, while the forth ar-

gument will be a set of data operations performed in

the conﬁguration. The constant operator initConfig

will describe the initial conﬁguration.

Places of a WFD-net will be deﬁned as con-

stants of sort Places, transitions as constants of sort

Transitions, data elements as constants of sort

Data and predicates as constants of sort Preds. The

sets of variables used by each predicate are described

using equations. An equation will describe the initial

conﬁguration of the net.

For the example in Figure 1, we have the follow-

ing constant deﬁnitions and equations (we only in-

cluded the equations for transition rja):

ops i o p1 p2 p3 p4 p5 p6 : -> Places .

ops cch ple pmf ra rja rmf scd srn :

-> Transitions .

ops c chr cd le rn f : -> Data .

ops okCH okData : -> Preds .

eq vars(okCH) = chr .

eq vars(odData) = chr , f .

eq read(rja) = f, chr .

eq write(rja) = rn .

eq delete(rja) = f,chr .

.....................

eq initConfig = <i, (c), ({ okCH : false },

{ okData : false }),empty > .

In what follows we will describe the behavior of

WFD-nets using a rewrite theory in a system module

of Maude. Every rewrite rule will describe the dy-

namic part of WFD-nets, i.e. when a transition t is

enabled in a given conﬁguration and the resulted con-

ﬁgurations after the ﬁring of t.

Let depPreds(t) be the set of predicates which

depend on data elements that are written by t:

depPreds(t) ={P ∈ Preds|

vars(P) ∩ Write(t) ̸=

The ﬁring of a transition t in a conﬁguration can po-

tentially produce a set of conﬁgurations:

[

S∈2

depPreds(t)

{< M

′

, DS

′

, σ

′

, DO

′

>|σ

′

(P) = ¬σ(P),

P ∈ S, σ

′

(P) = σ(P), P ̸∈ S}

Each conﬁguration in this set has the same marking,

data elements and data operations, but can have dif-

ferent values for predicates. This set describes all the

ways in which the write operations of t could inﬂu-

ence the value of the dependent predicates. For each

transition t a set of rewrite rules is introduced to de-

scribe all possible resulting conﬁgurations. The sys-

tem module includes the functional module which de-

scribes the types and the static aspects of the WFD-net

and also deﬁnes the following variables:

var M : Marking .

var DS : Set{Data} .

var PS : Set{PredValue} .

var DO : Set{DataOp} .

For each S ∈ 2

depPreds(t)

, S ̸=

0 a conditional rewrite

rule will be added:

crl[label] : C

=> C

if condition

Such a rule has a unique label and will describe when

transition t is enabled in conﬁguration C

and a re-

sulting conﬁguration C

, assuming that the write op-

erations of t change the values of the predicates in set

The Analysis of Data-Flow and Control-Flow in Workﬂow Processes Using Maude

377

Table 1: Rewrite rules corresponding to transition cch.

crl[cch1]: <M p1, (DS,c), PS, DO> => <M p3, (DS,c,chr), changeValues(PS, okData), dops(cch)>

if definedPreds(okData, (DS,c,chr)).

crl[cch2]: <M p1, (DS, c), PS, DO> => <M p3, (DS,c,chr), changeValues(PS, okCH), dops(cch)>

if definedPreds(okCH, (DS,c,chr)).

crl[cch3]: <M p1, (DS,c), PS, DO> => <M p3, (DS,c,chr), changeValues(PS, (okCH,okData)),

dops(cch)> if definedPreds((okCH,okData), (DS,c,chr)).

rl[cch4]: <M p1, (DS,c), PS, DO> => <M p3, (DS,c,chr), PS, dops(cch)>

S. The left side of the rule is:

=< M inPlaces, DS, rData, prValues, DO >

M, DS, DO are the variables deﬁned in the module;

inPlaces is the set of all the input places of t;

rData = vars(t) (the set of data elements read by

t or involved in the guard of t); prValues is vari-

able PS if the transition has no guard, otherwise the

set (PS, {P : value}), where P is the predicate in the

guard of t and value is false if the guard is the

negation of predicate P, otherwise true; C

is:

=< M outPlaces, (DS, outData),

changeValues(prValues, S), dops(t) >

outPlaces is the set of all the output

places of t and M outPlaces represents

the new marking of the underlying WF-net;

outData = Read(t) ∪ Write(t) \ Delete(t) (the

set of data elements available after the operations in

t have been performed); (DS, outData) represents

the new set of deﬁned data elements: the union

between the set represented by the variable DS (the

existing data elements before the transition ﬁres) and

the data elements produced by the execution of t;

changeValues gives the new predicate values after

the execution of the transition, it has as arguments the

previous values, prValues, and the set of predicates

that will change their value. dops(t) is the set of

data operations performed by t.

The condition of the rule (condition) is

definedPreds(S, (DS, outData)): all the predicates

that could potentially change their value (S) must have

all the dependent data deﬁned in the new data conﬁgu-

ration (the set (DS, outData)). Otherwise, the change

of values would be useless (a predicate with undeﬁned

variables is considered false, because its transition

cannot execute anyway due to missing data).

One additional un-conditional rewrite rule will de-

scribe the situation in which all the predicate values

remain unchanged after the write operations of t are

performed:

rl[< label >] : C

=> C

is obtained as in the case of conditional rules. The

right side of the rule, C

, is:

=< M outPlaces, (DS, outData),

prValues, dops(t) >

The only difference from the conditional rules is that

operator changeValues is not needed, as the predi-

cate values are not changed by the execution of t.

In the WFD-net in Figure 1,

Preds = {okCH, okData}.

Transition ra (receive application) does not have

any write operation, so it has one corresponding

rewrite rule in Maude:

rl[ra] : < M i, (DS,c), PS, DO > =>

< M p2 p1 , (DS,c), PS, dops(ra) > .

In order to obtain the conditional rules for tran-

sition cch (check credit history), we compute

modifiedPreds(cch) = {okData, okCH} (the val-

ues of these predicates could be changed by the write

operation). All the rules have the same left side (see

Table 1). The right side differs only in the arguments

for changeValues and in the condition of the rule.

For instance, rule cch3 models the case in which

the write operation changes the values of both okCH

and okData. This rule applies only if both predicates

have all the data elements deﬁned in the resulting con-

ﬁguration.

In the example in Figure 1, the initial conﬁgura-

tion is:

< i, c, ({okCH : false}, {okData : false}),

empty >

The rewrite rule rl[ra] can be applied: the term

Mi can be matched with i (variable M in the rule

will be matched to the empty set null) and i will

be rewritten to p2 p1. (DS, c) will be matched to

c (variable DS will be matched to the empty set,

empty); PS in the left-side of the rule can be matched

to the term ({okCH : false}, {okData : false}); DO

in the rule can be matched with empty and this term

will be rewritten to r(c) (representing the operations

performed). After using with this rule, the resulting

conﬁguration is:

< p2 p1, c, ({okCH : false}, {okData : false}),

r(c) >

The rewrite with rule cch1 is not possible because

definedPreds(okData, (DS, c, chr)) is false (data

element f, on which okData depends, is not deﬁned

ICEIS 2023 - 25th International Conference on Enterprise Information Systems

378

in the data set (DS, c, chr), as DS is matched to the

empty set). The same holds for rule cch3. The rewrite

with rule cch2 changes the conﬁguration into:

< p2 p3, c, ({okCH : true}, {okData : false}),

r(c), w(chr) >

The complete Maude modules for the example in

Figure 1 can be found at:

https://github.com/cylonx/WFDtoMaudeExample.

5 VERIFICATION OF DATA

FLOW ERRORS AND

SOUNDNESS IN MAUDE

In this section we will formalize some common data-

ﬂow errors and the correctness properties using tem-

poral logic (LTL and CTL temporal logic) (Clarke

et al., 1999). The LTL properties can than be veriﬁed

using the LTL Model Checker in Maude, while the

CTL properties can be veriﬁed using the umaudemc

utility for Maude (Rubio et al., 2021).

The LTL model checker in Maude allows to as-

sociate a Kripke structure to the rewrite theory R =

(Σ, E ∪ A, R) speciﬁed by a Maude system module M,

if one speciﬁes the intended kind k of states in the

signature Σ, and the relevant state predicates, that is,

the relevant set AP of atomic propositions. In our

case, we declare the intended states and the state pred-

icates in a separate system module which protects the

functional module where the data types and the struc-

ture of net are speciﬁed and includes the Maude pre-

deﬁned module SATISFACTION. For the example in

Figure 1, this module will be called wfd-preds.

The subsort declaration subsort Config <

State ensures that the states of the Kripke struc-

ture are the conﬁgurations described by the sort

Config. The state predicates are declared as oper-

ators having the sort Prop (a predeﬁned sort in the

module SATISFACTION). Module wfd-preds has the

following structure:

mod wfd-preds is

protecting wfd-nettypes .

including SATISFACTION .

subsort Config < State .

ops enabledTrans predTrans : Transitions

-> Prop .

op concurrentlyFireable : Transitions

Transitions

-> Prop .

ops final availableData : Set{Data} -> Prop .

ops read deleted written : Data -> Prop .

var M : Marking .

vars DS DS1 : DataSet .

var PS : PredSet .

var DO : DataOps .

var C : Config .

var P : Prop .

var x : Data .

--- equations

endm

The semantics of the state predicates is deﬁned using

equations eq config |= proposition = true.

Given a set of data elements DS, the proposition

final(DS) is satisﬁed in any conﬁguration in which

the ﬁnal marking is the ﬁnal marking of the WF-net,

o, and the set of deﬁned data elements includes DS.

This is described in Maude using the equation:

eq <o, (DS1,DS), PS, DO> |= final(DS) = true .

If t is a term of sort Transitions (representing

a transition t of the WFD-net), enabledTrans(t) is

satisﬁed in a conﬁguration, if t is enabled at the mark-

ing of the net, i.e. the input places of the t belong to

the multiset representing the marking:

eq < M input_places , DS , PS , DO > |=

enabledTrans(t) = true .

For instance, in the example in Figure 1, the equa-

tion for the state predicate corresponding to transition

rja (reject application) is:

eq < M p4 p6 , DS , PS , DO > |=

enabledTrans(rja) = true .

If t is a term of sort Transitions and represents a

transition which has in its guard a predicate P, then

predTrans(t) is satisﬁed in a conﬁguration, if the

guard of t is true in that conﬁguration:

eq <M, DS, (PS,{P : value}), DO> |=

predTrans(t) = true .

P is a constant (representing an actual predicate in

a guard for the given net). Term (PS, {P : value})

means that predicate P must appear with the value

value in the conﬁguration (PS represents the set of

predicate values for the other predicates). value

is false if the predicate P appears negated in the

guard and true otherwise. For example in Figure 1,

the equation for the state predicate predTrans(rja),

corresponding to transition rja (reject application) is:

eq < M , DS , (PS , {okData : false}) , DO >

|= predTrans(rja) = true .

If transition t has no guard, the following equation is

used (C is a variable of sort Config):

eq C |= predTrans(t) = true .

If DS is a set of data elements, the proposition

availableData(DS) is true in a conﬁguration, if DS

is included in the set of deﬁned/available data ele-

ments in the conﬁguration:

The Analysis of Data-Flow and Control-Flow in Workﬂow Processes Using Maude

379

eq < M , (DS1,DS) , PS , DO > |=

availableData (DS) = true .

If t1 and t2 are two transitions of the net,

concurrentlyFireable(t1, t2) is true in a con-

ﬁguration if: t1 and t2 are concurrently enabled at

the marking of the net (i.e. the multisets of input

places of the transitions are included in the current

marking of the conﬁguration), all data elements read

by both t1 and t2 are available (i.e. they are included

in the set of deﬁned data elements of the conﬁguration

and the guards of both transitions are true:

eq <M input_places, (DS,read_data),

(PS,predicates), DO>

|= concurrentlyFireable(t1,t2) = true .

M input places is the current marking in the con-

ﬁguration, where input places represents the mul-

tiset containing the input places of the transitions;

(DS, read data) is the set of deﬁned data elements in

the conﬁguration and read data is the set of data ele-

ments read by the two transitions; predicates is the

set of predicate values that make the guards of both

the transitions true.

For instance, in order to describe that transitions

pmf and scd are concurrently ﬁreable in a certain con-

ﬁguration, we use the equation:

eq <M p3 p4 p6, (DS,chr,f,c),

(PS,{okData : true},{okCH : true}), DO>

|= concurrentlyFireable(pmf,scd) = true .

The proposition written(x) is satisﬁed in any con-

ﬁguration in which a write operation has been per-

formed (i.e. the set of operations contains w(x)):

eq <M, DS, PS, (DO,w(x))>

|= written(x) = true.

Similar equations are introduced for read(x) and

delete(x).

We will deﬁne a system module (for the example

in Figure 1, it will be called wfd-check), in which we

introduce the formulas that describe the data errors we

need to check. This formulas are operators with the

sort Prop.

mod wfd-check is

including wfd-preds .

including MODEL-CHECKER .

including LTL-SIMPLIFIER .

op enabledWithData : Transitions Data

-> Prop .

ops notmissing notredundant notoverwritten

consistentData delwrite access : Data

-> Prop .

ops fireable : Transitions -> Prop .

ops end : -> Prop .

var t : Transitions .

var x : Data .

var s: Set{Data}

eq enabledWithData(t,s) = enabledTrans(t) /\

predTrans(t) /\ availableData (s) .

eq fireable (t) = enabledWithData(t,read(t)) .

.....

Proposition fireable(t) is satisﬁed in a conﬁgura-

tion iff transition t is ﬁreable in that conﬁguration.

Next we will present and formalize the most com-

mon data ﬂow errors that can occur in workﬂows with

data, even if the underlying WF-net is sound. These

data-ﬂow errors are also called anti-patterns (Tr

cka

et al., 2009).

The data ﬂow errors can be described using for-

mulas in CTL

∗

temporal logic, whose negations are

formulas in the LTL logic. The temporal operator F is

denoted by <> in Maude notation, G is denoted by [],

¬ by ∼, the next operator (X) is denoted by O.

The missing data anti-pattern describes the situ-

ation where some data element needs to be accessed

(used in the guard, read or deleted), but either it has

never been written or it has been deleted without hav-

ing been written again. Let Data(t) be the data ele-

ments read, deleted or used in a guard by t. A con-

ﬁguration in which a data element d needs to be ac-

cessed is a conﬁguration < M, DS, PS, DO > such that

there exists a transition t with d ∈ Data(t) and M[t⟩.

If d ̸∈ DS, then we have a missing data error.

Using the atomic proposition enabledTrans(t),

we deﬁne formula access(d), which is

satisﬁed in any conﬁguration in which

the data element d needs to be accessed:

access(d) =

{t|d∈Data(t)}

enabledTrans(t).

The following CTL

∗

formula describes a missing

data error:

EF(access(d) ∨ ¬availableData(d))

The negation of this formula is a LTL formula, which

can be described in Maude as:

eq notmissing(d) =

[] ˜(access(d) /\ ˜availableData(d))

A data element is lost if there is an execution se-

quence in which, after the element is written, it is

deleted or written again without being read ﬁrst. In

the example in Figure 1, if we remove the read oper-

ation on data element f for transition rmf, we would

obtain a lost data error: in the execution sequence (ra,

cch, pmf,rmf) the data element f is overwritten.

Let delwrite(d) = deleted(d) ∨ written(d).

In CTL

∗

, the formula for lost data would be:

EF(written(d) ∧ ¬end ∧

X (¬read(d)U(delwrite(d) ∧ ¬read(d))))

Proposition end is satisﬁed when the workﬂow exe-

cution is completed.

The corresponding LTL formula for the negation

of the CTL

∗

formula above is described by the fol-

lowing equation in Maude:

ICEIS 2023 - 25th International Conference on Enterprise Information Systems

380

eq notlost(x) = [] ˜(written(x) /\ ˜end /\

O (˜read(x) U (delwrite(x) /\ ˜read(x)))) .

The semantic of proposition end is given by the

equation:

eq end = final(empty) .

A data element is redundant if there is some ex-

ecution scenario in which it is written but never read

before the workﬂow execution is completed. In the

example in Figure 1, the data element le is redun-

dant (after the ﬁring of ple, no other transition reads

this data element). This behavior does not always rep-

resent an error (in our example, le is not read by any

other transition because it is a document for the client,

it needs to appear in the ﬁnal data of the workﬂow).

The CTL

∗

formula for checking this property is:

EF(written(d) ∧ X(¬read(d)U(final ∧ ¬read(d))

The LTL formula describing the negation of this for-

mula can be expressed by the following equation in

Maude:

eq notredundant(x) = [] ˜(written(x) /\

O (˜read(x) U (end /\ ˜read(x)))) .

Inconsistent data: A data element d is incon-

sistent if some transition t that writes or deletes d

and some transition t

′

that uses d (reads, has d in its

guard, writes or deletes d) can be executed concur-

rently. In the example in Figure 1, all data elements

are consistent. If we modify the example such that

Write(ple) = {le, chr}, since transitions cch and

ple can be executed concurrently, the data element

le would be inconsistent.

Let Changing(d) be the set of transitions that

write or delete d:

Changing(d) = {t|d ∈ Write(t) ∪ Delete(t)}

Let Using(d) be the set of transitions that write,

delete or use d in a predicate:

Using(d) = Changing(d) ∪ {t|d ∈ Vars(t)}.

If Changing(d) =

0, then d is consistent.

The CTL

∗

formula for checking this property is:

EF(

∈Changing(d)

∈Using(d)

concurrentlyFireable(t

, t

))

As in the previous case, we can obtain an LTL for-

mula in Maude (consistentData(d)) for the nega-

tion of the CTL

∗

formula above, by replacing EF with

the Maude operators []˜.

The complete wfd-preds and wfd-check mod-

ules for the example in Figure 1 can be found at

https://github.com/cylonx/WFDtoMaudeExample.

The LTL formulas can be checked directly in the

Maude environment. For the example in Figure 1,

checking if data element le is not redundant, lost and

missing, can be done using the Maude LTL model

checker, as in Figure 2.

In order to describe the correctness of workﬂows

when both the control-ﬂow and the data-ﬂow are con-

sidered, we deﬁne two variants of soundness. The

properties we propose in this paper extend the clas-

sical soundness deﬁned in (Aalst, 1998) with infor-

mation about data. A workﬂow with data is sound if:

(1) there are no dead transitions: for any transition t,

there exists a conﬁguration reachable from the initial

conﬁguration such that t is ﬁreable in that conﬁgura-

tion ; (2) the proper termination condition holds.

We can check if a transition t is dead using the

following LTL formula: [] ˜fireable(t).

We deﬁne two possible termination conditions:

given an initial conﬁguration and a set of ﬁnal

data elements, Df, from any conﬁguration reachable

form the initial conﬁguration, a ﬁnal conﬁguration

< o, DS, PS, DO > can be reached and:

1. Termination with optional data:

DS should contain at least one element from Df;

2. Termination with mandatory data:

DS should contain all the elements from Df;

The two properties can be expressed in the CTL tem-

poral logic with the following formulas:

1. A GE F(

d∈Df

final(d))

2. A GE F(

d∈Df

final(d))

The CTL formulas can be checked using the uni-

ﬁed Maude model-checking utility, umaudemc, which

is a uniform command-line, graphical, and program-

ming interface to different model checkers operating

on Maude speciﬁcations.

For instance, for the example in Figure 1, the

soundness with optional data, if the set of ﬁnal data

is Df = {cd, rn} can be expressed with the following

formula in umaudemc:

A [] E <> final(cd) \/ final(rn)

Soundness with the set of optional data Df = {cd, rn}

is satisﬁed: it is always possible to get to a conﬁgura-

tion in which the marking is o and either the closing

documents (cd) or the rejection note (rn) is deﬁned.

The mandatory soundness with the data set

Df = {cd} does not hold for our example, but manda-

tory soundness holds with Df = {le, c} (the loan es-

timate is always provided and the initial client data is

always available, as no action deleted it).

Our approach permits the veriﬁcation of proper-

ties regarding data elements that cannot be speciﬁed

directly in other approaches that do not model data

explicitly (Tr

cka et al., 2009):

• a data element is deﬁned in all possible executions

of the workﬂow:

[] availableData(d)

The Analysis of Data-Flow and Control-Flow in Workﬂow Processes Using Maude

381

Figure 2: Veriﬁcation of data-ﬂow errors in the Maude environment.

• a certain data element is never written during the

execution of the workﬂow:

[] ˜written(d)

• a data element is deleted at least once - the nega-

tion of this property is:

[] ˜deleted(d)

6 RELATED WORK

There exist several approaches that study the correct-

ness of the workﬂow process in the case when both

data-ﬂow and control-ﬂow are considered, but do not

focus on data-ﬂow errors: Fan et al. (Fan et al.,

2007) introduces dual workﬂow nets in order to model

the workﬂow process with data and extends the no-

tion of classical soundness deﬁned in (Aalst, 1998)

for these nets; In (Sidorova et al., 2011) workﬂow

processses are modelled using Workﬂow Nets with

Data. Two notions of soundness (may-soundness and

must-soundness) are deﬁned for these nets and hyper-

transition systems are used to characterize these prop-

erties; In (Kheldoun et al., 2017), Kheldoun et al.

transform BPMN models of business processes into

to Recursive ECATNets (RECATNets) and use the

Maude LTL model checker to check the proper ter-

mination of a process. The authors in (He et al.,

2018) propose Workﬂow Nets with Data Constraints,

in which data constraints are represented by propo-

sitional formulas, and verify the may-soundness and

must-soundness for this model.

Most of the approaches that focus on detecting

data-ﬂow errors in workﬂows do not discuss a no-

tion of correctness: in (Sun et al., 2006; Meda et al.,

2007), the authors propose an extended UML notation

for describing workﬂow processes and present veri-

ﬁcation algorithms for some of the data ﬂow errors.

Eshuis (Eshuis, 2006) proposes model checking tech-

niques to detect violations of data consistency con-

straints of workﬂows modelled by UML activity di-

agrams. In (Liu et al., 2020; Xiang et al., 2021a),

the authors propose extensions of Petri Nets for mod-

elling workﬂow processes with data and introduce al-

gorithms for detecting data-ﬂow errors. Xiang et al.

(Xiang et al., 2017) use unfolding techniques to detect

data inconsistency in workﬂows modelled by work-

ﬂow nets with data operations. None of these ap-

proaches allows the modelling of complex workﬂow

processes in which the execution of tasks is condi-

tioned by guards.

In (Xiang and Liu, 2020), the authors deﬁne a a

guard-driven reachability graph (CRG) of a workﬂow

net with data and use it to detect data-ﬂow errors.

Zhao et al. (Zhao et al., 2022) detect data-ﬂow er-

rors by analyzing all the transition sequences in a state

space of a WFD-net, but the inﬂuence of the write op-

erations on the guards of transitions is not considered

when computing the states.

In (von Stackelberg et al., 2014), the authors pro-

pose a tool that maps BPMN 2.0 process models

into Petri nets and detect data-ﬂow anti-patterns using

model-checking techniques. Data deletion is not per-

mitted in this approach. Also, in order to model the

complex data usage scenarios in BPMN 2.0, the pro-

posed approach produces very large Petri Net mod-

els, which will lead to the state explosion problem.

In order to solve this problem, the authors in (M

ulle

et al., 2019) propose reduction techniques to obtain a

reduced Petri net model. Although these techniques

preserve the data-ﬂow properties of the model, they

can affect the study of the proper termination of the

process, when both the control-ﬂow and the data-ﬂow

are considered.

In (Tr

cka et al., 2009), WFD-nets are introduced

in order to describe conceptual workﬂows with data.

The authors describe the most common data-ﬂow er-

rors and the correctness property using CTL

∗

formu-

las. The authors use the reachability graph of an un-

folding of the WFD-net (which is also a Petri net) in

order to obtain the Kripke structure used for model

checking. Due to the size of this unfolding, the pro-

posed technique suffers from the state space explosion

ICEIS 2023 - 25th International Conference on Enterprise Information Systems

382

problem. No speciﬁc implementations exists for this

approach. (Xiang et al., 2021b) proposes a tool which

allows the detection of data inconsistency of work-

ﬂow processes based on unfolding techniques simi-

lar to the ones in (Xiang et al., 2017). The authors

use the guard-driven reachability graph from (Xiang

and Liu, 2020) to apply model-checking techniques

for detecting deadlocks and proper-termination, but

no other data-ﬂow errors are detected. Because the

conﬁguration graph does not take into consideration

all the possible values of guards, incorrect results can

be obtained regarding the proper termination.

Our approach uses the WFD-net proposed in

(Tr

cka et al., 2009), allowing read, write, delete op-

erations and guards for transitions. Instead of trans-

forming a model of the process into Petri nets in or-

der to apply model-checking techniques (as in (Tr

cka

et al., 2009; von Stackelberg et al., 2014; M

ulle et al.,

2019)), we provide a formalization of workﬂows with

data in Maude, by specifying WFD-nets as theories in

the rewriting logic. This approach permits the speciﬁ-

cation of conﬁgurations as states of the Kripke struc-

ture that will be used by the LTL checker in Maude.

The proposed conﬁguration embeds all the data infor-

mation needed to describe the data anti-patterns.

The existing approaches do not permit the speciﬁ-

cation of data in the initial state of the process or the

speciﬁcation of conditions on data when the workﬂow

terminates, as we propose in this paper.

7 CONCLUSIONS

In this paper we have proposed the speciﬁcation of

workﬂow nets with data in Maude, providing a for-

mal semantics for WFD-nets. We have introduced

two notions of soundness to describe the correctness

of workﬂows with data. Unlike other notions of cor-

rectness deﬁned for workﬂows with data, in which

the termination condition only requires that the ﬁnal

marking (o) should be reached, these properties re-

quire that at least one data element or all data ele-

ments from a given set should be present when the

workﬂow terminates. We have formalized these cor-

rectness properties using the CTL temporal logic. We

have also formalized the data-ﬂow errors (redundant

data, missing data, lost data and inconsistent data) us-

ing the LTL temporal logic. The veriﬁcation of prop-

erties can be done using the LTL model checker from

Maude and the umaudemc utility for Maude.

In ongoing work, we plan to identify and formal-

ize other data ﬂow errors, study soundness with other

types of termination requirements and also consider

the modelling of security constraints over data ele-

ments. We intend to develop a tool for editing WFD-

nets, that will also automate the transformation from

WFD-nets to Maude speciﬁcations and will permit the

veriﬁcation of properties.

REFERENCES

Aalst, W. M. P. (1998). The application of Petri nets to

workﬂow management. Journal of Circuits, Systems

and Computers, 08(01):21–66.

Aalst, W. M. P., Hee, K. M., Hofstede, A. H. M., Sidorova,

N., Verbeek, H. M. W., Voorhoeve, M., and Wynn,

M. T. (2010). Soundness of workﬂow nets: classiﬁ-

cation, decidability, and analysis. Formal Aspects of

Computing, 23(3):333–363.

Clarke, E. M., Grumberg, O., and Peled, D. A. (1999).

Model checking. MIT Press, London, Cambridge.

Eshuis, R. (2006). Symbolic model checking of UML ac-

tivity diagrams. ACM Trans. Softw. Eng. Methodol.,

15(1):1–38.

Fan, S., Dou, W., and Chen, J. (2007). Dual Workﬂow Nets:

Mixed control/data-ﬂow representation for workﬂow

modeling and veriﬁcation. In Advances in Web and

Network Technologies, and Information Management,

pages 433–444, Berlin, Heidelberg. Springer Berlin

Heidelberg.

He, Y., Liu, G., Xiang, D., Sun, J., Yan, C., and Jiang, C.

(2018). Verifying the correctness of workﬂow systems

based on workﬂow net with data constraints. IEEE

Access, 6:11412–11423.

Kheldoun, A., Barkaoui, K., and Ioualalen, M. (2017). For-

mal veriﬁcation of complex business processes based

on high-level Petri nets. Information Sciences, 385-

386:39–54.

Liu, C., Zeng, Q., Duan, H., Wang, L., Tan, J., Ren, C.,

and Yu, W. (2020). Petri net based data-ﬂow error de-

tection and correction strategy for business processes.

IEEE Access, 8:43265–43276.

Meda, H. S., Sen, A. K., and Bagchi, A. (2007). Detect-

ing data ﬂow errors in workﬂows: A systematic graph

traversal approach. In Workshop on Information Tech-

nology & Systems (WITS-2007).

Meseguer, J. (1992). Conditional rewriting logic as a uniﬁed

model of concurrency. Theoretical Computer Science,

96(1):73–155.

ulle, J., Tex, C., and B

ohm, K. (2019). A practical data-

ﬂow veriﬁcation scheme for business processes. In-

formation Systems, 81:136–151.

Reisig, W. (1985). Petri Nets: An Introduction. Springer-

Verlag, Berlin, Heidelberg.

Rubio, R., Mart

ı-Oliet, N., Pita, I., and Verdejo, A. (2021).

Strategies, model checking and branching-time prop-

erties in Maude. Journal of Logical and Algebraic

Methods in Programming, 123:100700.

Sidorova, N., Stahl, C., and Tr

cka, N. (2011). Soundness

veriﬁcation for conceptual workﬂow nets with data:

Early detection of errors with the most precision pos-

sible. Information Systems, 36(7):1026–1043. Spe-

The Analysis of Data-Flow and Control-Flow in Workﬂow Processes Using Maude

383

cial Issue: Advanced Information Systems Engineer-

ing (CAiSE’10).

Sun, S. X., Zhao, J. L., Nunamaker, J. F., and Sheng, O.

R. L. (2006). Formulating the data-ﬂow perspective

for business process management. Info. Sys. Research,

17(4):374–391.

cka, N., van der Aalst, W. M. P., and Sidorova, N.

(2009). Data-ﬂow anti-patterns: Discovering data-

ﬂow errors in workﬂows. In van Eck, P., Gordijn, J.,

and Wieringa, R., editors, Advanced Information Sys-

tems Engineering, pages 425–439, Berlin, Heidelberg.

Springer Berlin Heidelberg.

von Stackelberg, S., Putze, S., M

ulle, J. A., and B

ohm,

K. (2014). Detecting data-ﬂow errors in BPMN 2.0.

Open J. Inf. Syst., 1:1–19.

Xiang, D. and Liu, G. (2020). Checking data-ﬂow er-

rors based on the guard-driven reachability graph of

wfd-net. COMPUTING AND INFORMATICS, 39(1-

2):193–212.

Xiang, D., Liu, G., Yan, C., and Jiang, C. (2017). Detecting

data inconsistency based on the unfolding technique

of Petri nets. IEEE Transactions on Industrial Infor-

matics, 13(6):2995–3005.

Xiang, D., Liu, G., Yan, C., and Jiang, C. (2021a). A

guard-driven analysis approach of workﬂow net with

data. IEEE Transactions on Services Computing,

14(6):1650–1661.

Xiang, D., Zhao, F., and Liu, Y. (2021b). DICER 2.0: A

new model checker for data-ﬂow errors of concurrent

software systems. Mathematics, 9(9).

Zhao, F., Xiang, D., Liu, G., Jiang, C., and Zhu, H. (2022).

Detecting and repairing data-ﬂow errors in WFD-net

systems. Computer Modeling in Engineering & Sci-

ences, 131(3):1337–1363.

ICEIS 2023 - 25th International Conference on Enterprise Information Systems

384