Formal modeling and SMT-based parameterized verification of Data-Aware BPMN

Diego Calvanese, Silvio Ghilardi, Alessandro Gianola, Marco Montali, Andrey Rivkin
Formal Modeling and
SMT-based Parameterized Veriﬁcation
of Data-aware BPMN

Starting Point
BPM Formal veriﬁcation
SMT
data
mgmt
business
artifacts
BPMN*

Starting Point
SMT
data
mgmt
business
artifacts
array-based
systems
relational
artifact
systems
BPMN*

This Paper
SMT
data
mgmt
business
artifacts
array-based
systems
relational
artifact
systems
DAB
BPMN*

This Paper
SMT
data
mgmt
business
artifacts
BPMN*
array-based
systems
relational
artifact
systems
DAB

BPMN standard
case
variables
persistent
storage
x y z
read/write

BPMN standard
case
variables
persistent
storage
x y z
read/write
query
update
insert
delete

BPMN standard
case
variables
persistent
storage
x y z
read/write
query
update
insert
delete
query

case
variables
persistent
storage
x y z
case
variables
persistent
storage
BPMN standard

Integrating BPMN and Data
Data schema maintains (typed) data of interest
Data manipulation logic: data access + update
Process schema: tasks and control-ﬂow
Data
schema
Process
schema
query
update
Data
manipulation
logic

Attacking the dichotomy problem
Modeling & Enactment
e.g. [Meyer et al, BPM13]
BPMN + “full” data
BPMN

Formalisms/Methodologies
& Enactment
• mention approaches,
their key features and
limitations (DB-nets,
RAW-SYS, different PN
extensions with data,
data-aware extensions of
BPMN; conventional
BPMN tools like Bizzagi,
Camunda etc)

Modeling & Enactment
e.g. [Meyer et al, BPM13]
BPMN
Formal analysis
see [Calvanese et al, PODS13]
BPMN
veriﬁable

Verification Setting
1. What do we verify?
•Cases in isolation
•Data injected by external events / tasks
•Unboundedly many tuples can be created
2. Which properties?  
Safety: never reach a bad configuration (control-flow + data)
•With block-structured processes, captures soundness
3. Which initial conditions?
•Token in the start event
•Undefined case data
•Initial DB???

…
…
Fixing the initial DB
B0
B1
B2
……
…
…
Infinite-state TS
Infinite runs
Infinite branches
Unbounded DB

Distinguishing Data
(cf. artifact-centric veriﬁcation school)
Case data Repository Catalog
Access read-write read-write read-only
Type
variables, may
reference catalog
pure relations,
may reference the
catalog
relational DB with
single-column PKs
and FKs
Initially undeﬁned empty ???

SocialSecurity(SSid : ssecurityID, user : userID)<latexit sha1_base64="J+vQn+OkEC2ZIRITIBCB0Zqun9A=">AAACLXicbVDLSgMxFL3js9bXqDvdDLZChVJm3ChdFexCd5XaB3SGkkkzbWjmQZIRytClP+PGXxHBRUXc+hum0yLaeiBwcs69N7nHjRgV0jQn2srq2vrGZmYru72zu7evHxw2RRhzTBo4ZCFvu0gQRgPSkFQy0o44Qb7LSMsdXk/91gPhgobBvRxFxPFRP6AexUgqqatX8/UQU8TqBMecylGhXqe9su0jORBeIsRcvq2Oi3YxiQXh4x93elPGeb6r58ySmcJYJtac5CrHj3lQqHX1V7sX4tgngcQMCdGxzEg6CeKSYkbGWVuNjhAeoj7pKBognwgnSbcdG2dK6RleyNUJpJGqvzsS5Asx8l1VmX500ZuK/3mdWHpXTkKDKJYkwLOHvJgZMjSm0Rk9ygmWbKQIwioVig08QBxhqQLOqhCsxZWXSfOiZJkl687KVcowQwZO4BQKYMElVOAGatAADE/wAhN41561N+1D+5yVrmjzniP4A+3rG7Bdqls=</latexit>
Example: Data in a Hiring Process
A catalog example:
User(Uid : userID, Name : StringName, Age : NumAge)<latexit sha1_base64="vLxJteK1PWm+RSAMGOsGfmX42Eo=">AAACNnicbVDLSgMxFL1TX7W+qu50E2yFCqXMuFG6quhCFxZFR4W2lEyaqcFMZkgyQhm69Ivc+B3uunGhiFs/wUwrPqoHAifn3Ms993oRZ0rb9sDKTExOTc9kZ3Nz8wuLS/nllQsVxpJQl4Q8lFceVpQzQV3NNKdXkaQ48Di99G72U//ylkrFQnGuexFtBbgrmM8I1kZq54+LrqKy5LJOtRlgfa38JDbC0UG/3CzXcUC/5DMtmeimUmrtdb+dehyY71YfFdv5gl2xh0B/ifNJCrW1uyIYnLTzj81OSOKACk04Vqrh2JFuJVhqRjjt55omTITJDe7ShqHCTFetZLh2H20apYP8UJonNBqqPzsSHCjVCzxTOUw67qXif14j1v5uK2EiijUVZDTIjznSIUpviDpMUqJ5zxBMJDNZEbnGEhNtLp0zR3DGV/5LLrYrjl1xTp1CrQojZGEdNqAEDuxADQ7hBFwgcA8DeIYX68F6sl6tt1FpxvrsWYVfsN4/APWcrMk=</latexit>
schemas in Cat, we have that the types of R1.id and R2.id
(foreign keys) for every relation schema R 2 Cat and non-id
with type S 2 Sid, there exists a relation schema R2 2 R
is S; a is hence a foreign key referring to R2.
Example 1. Consider a simpliﬁed example of a job hiring
represent information related to the process we make use of
following relation schemas:
• JobCategory(Jcid:jobcatID) contains the different job c
company (e.g., programmer, analyst, and the like) - we jus
of such categories;
• User(Uid:userID,Name:StringName,Age:NumAge) store
tered to the company website, and who are potentially i
offered by the company.
2 These are called data objects in BPMN, but we prefer to use the t
clashes with the formal notions.
4

A catalog example:
of such categories;
4id types
primitive types

A catalog example:
primary key
of such categories;
4

A catalog example:
foreign key
of such categories;
4

A catalog relation example:
A repository relation example:
Application(Jcid : jobcatID, Uid : userID, Score : NumScore, Eligible : Bool)<latexit sha1_base64="vXeypfeW+EUWjPk7OANBm3PzdAQ=">AAACW3icbVFdS8MwFE07dbN+TcUXfQluwoQxWl8Un+YXqA8y0elgHSPN0hlNm5Kkwih99A/6pA/+FTFrx/DrQODknHu5JzdexKhUtv1umIWZ2bliad5aWFxaXimvrt1JHgtM2pgzLjoekoTRkLQVVYx0IkFQ4DFy7z2djP37ZyIk5eGtGkWkF6BhSH2KkdJSvyyqR5Gek19rl5gODt0AqQfpJ4/c0/LFaVp367D9zYglERP5BnNBpsZVHGRCWodu/YzRIdUxpu4x5yzdrcJ+uWI37AzwL3EmpNLcfKkCjVa//OoOOI4DEirMkJRdx45UL0FCUcxIark6UITwExqSrqYhCojsJdluUrijlQH0udAnVDBTv3ckKJByFHi6Msv52xuL/3ndWPkHvYSGUaxIiPNBfsyg4nC8aDiggmDFRpogLKjOCvEDEggr/R2WXoLz+8l/yd1ew7EbzrVTaR6CHCWwBbZBDThgHzTBOWiBNsDgDXwaRaNkfJgF0zIX81LTmPSsgx8wN74AMJ21ww==</latexit>

foreign key

A case variable example
uid : userID qualif : Bool winner : userID<latexit sha1_base64="rjb08JK3YLoYnfRiM1O3JmzejNM=">AAACUXicbVFNTwIxEB3Wb/zCj5uXRjDxRHa9aDwR9aA3TARMgJButwuN3XZtuxqyIfGX+RM86Mn/4cWDxrJgVHCSJm/eezOdTv2YM21c9zXnzMzOzS8sLuWXV1bX1gsbm3UtE0VojUgu1bWPNeVM0JphhtPrWFEc+Zw2/JvTod64o0ozKa5MP6btCHcFCxnBxlKdQq/UirDp+WGasGBwnCXaJpqqi7NB6/Y2wQH6ttiEs/DHdSIln/TcMyGomupU6hSKbtnNAk0DbwyKle3HmQcAqHYKz61AkiSiwhCOtW56bmzaKVaGEU4H+ZbtHGNyg7u0aaHAEdXtNNvIAO1ZJkChVPYIgzL2d0WKI637kW+d2ZyT2pD8T2smJjxqp0zEiaGCjC4KE46MRMP1ooApSgzvW4CJYnZWRHpYYWLsJ+TtErzJJ0+D+kHZc8vepVesHMMoFmEHdmEfPDiECpxDFWpA4Ane4AM+cy+5dwccZ2R1cuOaLfgTzvIXw3q4wA==</latexit>

A case variable example
uid : userID qualif : Bool winner : userID<latexit sha1_base64="rjb08JK3YLoYnfRiM1O3JmzejNM=">AAACUXicbVFNTwIxEB3Wb/zCj5uXRjDxRHa9aDwR9aA3TARMgJButwuN3XZtuxqyIfGX+RM86Mn/4cWDxrJgVHCSJm/eezOdTv2YM21c9zXnzMzOzS8sLuWXV1bX1gsbm3UtE0VojUgu1bWPNeVM0JphhtPrWFEc+Zw2/JvTod64o0ozKa5MP6btCHcFCxnBxlKdQq/UirDp+WGasGBwnCXaJpqqi7NB6/Y2wQH6ttiEs/DHdSIln/TcMyGomupU6hSKbtnNAk0DbwyKle3HmQcAqHYKz61AkiSiwhCOtW56bmzaKVaGEU4H+ZbtHGNyg7u0aaHAEdXtNNvIAO1ZJkChVPYIgzL2d0WKI637kW+d2ZyT2pD8T2smJjxqp0zEiaGCjC4KE46MRMP1ooApSgzvW4CJYnZWRHpYYWLsJ+TtErzJJ0+D+kHZc8vepVesHMMoFmEHdmEfPDiECpxDFWpA4Ane4AM+cy+5dwccZ2R1cuOaLfgTzvIXw3q4wA==</latexit>
foreign key

Verification Parameterized
on Read-Only Data
Infinitely many
infinite-state TS
…
…
B0
B1
B2
……
…
…
……
…
…
B0
B5
B3
……
…
…
……
…
…
B0
B3
B7
……
…
…
……
…

Array-Based Systems
SMT
data
mgmt
business
artifacts
array-based
systems
relational
artifact
systems
BPMN*

SMT and Array-Based Systems
a
Indexes
0
1
…
Index
sort
Element
sort
(string, int, …)
insert “s"
into a

SMT and Array-Based Systems
a
Indexes
0
1
…
Index
sort
Element
sort
(string, int, …)
insert “s"
into a
s
a

(Un)safety via Backward
Reachability
unsafe
conﬁgurations
initial
conﬁgurations

Reachability
unsafe
configurations
initial
configurations
fixpoint….
SAFE!

Reachability
unsafe
conﬁgurations
initial
conﬁgurations
UNSAFE!

Reachability
unsafe
conﬁgurations
initial
conﬁgurations
UNSAFE!
Implemented in the
state-of-the-art
MCMT
model checker

Dealing with Relations
Repository Catalog
Access read-write read-only
Type
pure relational data, may
reference the catalog
relational DB with single-
column PKs and FKs
multiple-entry arrays special DB sorts
(values+ids)

JobCategory
analyst
programmer
User
u1 alice 20
u2 bob 23
u3 dana 22
Jcid Uid EliScore
Indexes
0
1
…
Application

JobCategory
analyst
programmer
User
u1 alice 20
u2 bob 23
u3 dana 22
Jcid Uid EliScore
Indexes
0
1
…
Application
u3 applies as
programmer

JobCategory
analyst
programmer
User
u1 alice 20
u2 bob 23
u3 dana 22
Jcid Uid EliScore
Indexes
Jcid Uid EliScore
0
1
…
Application Application

JobCategory
analyst
programmer
User
u1 alice 20
u2 bob 23
u3 dana 22
Jcid Uid EliScore
Indexes
Jcid Uid EliScore
0
1
…
application
scores 85

JobCategory
analyst
programmer
User
u1 alice 20
u2 bob 23
u3 dana 22
Jcid Uid EliScore
Indexes
Jcid Uid EliScore
0
1
…
Jcid Uid EliScore
Application
85

Relational Artifact Systems
Backward reachability: extended deal with RAS
Sound and complete:
• When it terminates, produces correct answer
• if RAS is unsafe, it detects this
May not terminate:
• decidable fragments identiﬁed
Implemented in MCMT

The DAB Model
SMT
data
mgmt
business
artifacts
DAB
BPMN*

Process schema
Block-structured BPMN  
(enriched with elements from the data-manipulation logic)

Process schema
Formal Modeling and SMT-Based Parameterized Verification 167
Job posted
[InsJobCat]
App. received
[InsUser]
Stop Stopped
Evaluate
CV
[CheckQual]
qualif =
true
Evaluate
Application
[EvalApp]
qualif =
false
Stopped
Decide
Eligible
Candidates
[MarkE]
Select
Winner
[SelWinner]
Assign
Winner
Make
Offer
Fig. 1. The job hiring process. Elements in squared brackets attach the update speci-
fications in Examples 3 and 4 to corresponding tasks/events.
Block-structured BPMN  
(enriched with elements from the data-manipulation logic)

Data manipulation logic
SQL: UNIONS of SELECT-PROJECT-JOIN queries  
with table ﬁlters
—> includes constrained user inputs
boolean queries over case variables

with table filters
Example 1: “get a user from the catalog”
Example 2: “ask a score from the scale of 1 to 100”
Example 3. We continue the job hiring example, by considering
fications of type insert&set. When a new case is created, the updat
InsJobCat indicates what is the job category associated to the cas
InsJobCat.pre selects a job category from the corresponding cat-
InsJobCat.eff assigns the selected job category to the case variab
InsJobCat.pre getJobType(c) ← JobCategory(c) InsJobCat.eff
When the case receives an application, the user id is picked from t
ing User via the update specification InsUser, where:
InsUser.pre getUser(u) ← User(u, n, a) InsUser.eff S
A different usage of precondition, resembling a pure external choice
specification CheckQual to handle a quick evaluation of the candid
whether she has such a high profile qualifying her to directly get
CheckQual.pre isQualified(q : Bool) ← true CheckQual.eff SE
As an example of insertion rule, we consider the situation where
getUser(u) ← User(u, n, a) InsUser.eff SET uid = u
f precondition, resembling a pure external choice, is the update
kQual to handle a quick evaluation of the candidate and check
uch a high profile qualifying her to directly get an offer:
sQualified(q : Bool) ← true CheckQual.eff SET qualif = q
insertion rule, we consider the situation where the candidate
ly stored in the case variable uid has not been directly judged
then subject to a more fine-grained evaluation via the EvalApp
ting in a score that is then registered in the repository.
pre getScore(s : NumScore) ← 1 ≤ s ∧s ≤ 100
.eff INSERT ⟨jcid , uid , s, undef⟩ INTO Application
n indicates an undef eligibility, since it will be assessed in a
the process. Notice that with the multiset insertion semantics,
y apply multiple times for the same job (resulting multiple

with table filters
Update
Precondition: query data with a guard, pick an answer
Effect: update repository and/or case variables (3 forms)
Example 1: “get a user from the catalog”
Example 2: “ask a score from the scale of 1 to 100”
Example 3. We continue the job hiring example, by considering
fications of type insert&set. When a new case is created, the updat
InsJobCat indicates what is the job category associated to the cas
InsJobCat.pre selects a job category from the corresponding cat-
InsJobCat.eff assigns the selected job category to the case variab
InsJobCat.pre getJobType(c) ← JobCategory(c) InsJobCat.eff
When the case receives an application, the user id is picked from t
InsUser.pre getUser(u) ← User(u, n, a) InsUser.eff S
A different usage of precondition, resembling a pure external choice
specification CheckQual to handle a quick evaluation of the candid
whether she has such a high profile qualifying her to directly get
CheckQual.pre isQualified(q : Bool) ← true CheckQual.eff SE
As an example of insertion rule, we consider the situation where
getUser(u) ← User(u, n, a) InsUser.eff SET uid = u
f precondition, resembling a pure external choice, is the update
kQual to handle a quick evaluation of the candidate and check
uch a high profile qualifying her to directly get an offer:
sQualified(q : Bool) ← true CheckQual.eff SET qualif = q
insertion rule, we consider the situation where the candidate
ly stored in the case variable uid has not been directly judged
then subject to a more fine-grained evaluation via the EvalApp
ting in a score that is then registered in the repository.
pre getScore(s : NumScore) ← 1 ≤ s ∧s ≤ 100
.eff INSERT ⟨jcid , uid , s, undef⟩ INTO Application
n indicates an undef eligibility, since it will be assessed in a
the process. Notice that with the multiset insertion semantics,
y apply multiple times for the same job (resulting multiple

Data manipulation logic: Insert & Set
Job posted
[InsJobCat]
App. received
[InsUser]
Stop Stopped
Evaluate
CV
[CheckQual]
qualif =
true
Evaluate
Application
[EvalApp]
qualif =
false
Stopped
Decide
Eligible
Candidates
[MarkE]
Select
Winner
[SelWinner]
Assign
Winner
Make
Offer
Definition 9. A DAB M is a pair ⟨D, P⟩ where D is a data schema, and P
is a root process block such that all conditions and update effects attached to P
Simultaneous update of repository relations and case
variables (untouched case variables keep their current value)

Example 1 (updating case variables): “when a case receives
an application, load its ID into a case variable”
primary key, upon insertion of a tuple ⃗u in the instance of a repo-relation R,
a fresh primary key is generated and attached to ⃗u. Two insertion semantics
can then be used to characterize the insertion. Under the first semantics of
multiset insertion, the update always succeeds in inserting ⃗u into R. Under the
set insertion semantics, instead, R comes not only with its implicit primary key,
but also with a key constraint defined over a subset K ⊆ R.attrs of its attributes
(by default, coinciding with R.attrs itself); the update is then committed only if
such a key constraint is satisfied. In the case of K = R.attrs, this implies that
the update succeeds only if ⃗u is not already present in R, thus treating R as a
proper set.
Example 3. We continue the job hiring example, by considering update speci-
fications of type insert&set. When a new case is created, the update specification
InsJobCat indicates what is the job category associated to the case. Specifically,
InsJobCat.pre selects a job category from the corresponding cat-relation, while
InsJobCat.eff assigns the selected job category to the case variable jcid :
InsJobCat.pre getJobType(c) ← JobCategory(c) InsJobCat.eff SET jcid = c
When the case receives an application, the user id is picked from the correspond-
InsUser.pre getUser(u) ← User(u, n, a) InsUser.eff SET uid = u
A different usage of precondition, resembling a pure external choice, is the update
Job posted
[InsJobCat]
App. received
[InsUser]
Stop Stopped
Evaluate
CV
[CheckQual]
qualif =
true
Evaluate
Application
[EvalApp]
qualif =
false
Stopped
Decide
Eligible
Candidates
[MarkE]
Select
Winner
[SelWinner]
Assign
Winner
Make
Offer
Formal Modeling and SMT-B
Job posted
[InsJobCat]
App. received
[InsUser]
Evaluate
CV
[CheckQual]
qu
fa
For
Job posted
[InsJobCat]

Example 2 (updating relations): “evaluate a selected
candidate using the scale of 1 to 100”
Job posted
[InsJobCat]
App. received
[InsUser]
Stop Stopped
Evaluate
CV
[CheckQual]
qualif =
true
Evaluate
Application
[EvalApp]
qualif =
false
Stopped
Decide
Eligible
Candidates
[MarkE]
Select
Winner
[SelWinner]
Assign
Winner
Make
Offer
InsJobCat indicates what is the job category associated to the case. Specifically
InsJobCat.pre selects a job category from the corresponding cat-relation, while
InsJobCat.eff assigns the selected job category to the case variable jcid :
InsJobCat.pre getJobType(c) ← JobCategory(c) InsJobCat.eff SET jcid = c
When the case receives an application, the user id is picked from the correspond
ng User via the update specification InsUser, where:
InsUser.pre getUser(u) ← User(u, n, a) InsUser.eff SET uid = u
A different usage of precondition, resembling a pure external choice, is the update
specification CheckQual to handle a quick evaluation of the candidate and check
whether she has such a high profile qualifying her to directly get an offer:
CheckQual.pre isQualified(q : Bool) ← true CheckQual.eff SET qualif = q
As an example of insertion rule, we consider the situation where the candidate
whose id is currently stored in the case variable uid has not been directly judged
as qualified. She is then subject to a more fine-grained evaluation via the EvalApp
specification, resulting in a score that is then registered in the repository.
EvalApp.pre getScore(s : NumScore) ← 1 ≤ s ∧s ≤ 100
EvalApp.eff INSERT ⟨jcid , uid , s, undef⟩ INTO Application

Data manipulation logic: Delete & Set
Job posted
[InsJobCat]
App. received
[InsUser]
Stop Stopped
Evaluate
CV
[CheckQual]
qualif =
true
Evaluate
Application
[EvalApp]
qualif =
false
Stopped
Decide
Eligible
Candidates
[MarkE]
Select
Winner
[SelWinner]
Assign
Winner
Make
Oﬀer
Simultaneous update of case variables and removal of tuples
from repository relations
(useful to transfer from repository to case variables)

Data manipulation logic: Delete & Set
Job posted
[InsJobCat]
App. received
[InsUser]
Stop Stopped
Evaluate
CV
[CheckQual]
qualif =
true
Evaluate
Application
[EvalApp]
qualif =
false
Stopped
Decide
Eligible
Candidates
[MarkE]
Select
Winner
[SelWinner]
Assign
Winner
Make
Offer
Simultaneous update of case variables and removal of tuples
from repository relations
(useful to transfer from repository to case variables)
simultaneously delete ⃗u from R and update some of the case variables – with the
implicit assumption that those not explicitly mentioned in the SET part maintain
their current values.
Finally, a conditional update rule applies, tuple by tuple, a bulk operation
over the content of R. Each tuple in R is reviewed. If the tuple passes the
filter associated to the rule, it is updated according to the THEN part, otherwise
according to the ELSE part.
Example 4. Continuing with our running example, we now consider the update
specification MarkE handling the situation where no candidate has been directly
considered as qualified, and so the eligibility of all received (and evaluated)
applications has to be assessed. Here we consider that each application is eligible
if and only if its evaluation resulted in a score greater than 80. Technically,
MarkE.pre is a true precondition, and:
MarkE.eff UPDATE Application(c, u, s, e)
IF s > 80 THEN Application(c, u, s, true) ELSE Application(c, u, s, false)
If there is at least one eligible candidate, she can be selected as a winner using
the SelWinner update specification, which deletes the selected winner tuple from
Application, and transfers its content to the corresponding case variables (also
ensuring that the winner case variable is set to the applicant id). Technically:
SelWinner.pre getWinner(c, u, s, e) ← Application(c, u, s, e) ∧ e = true
SelWinner.eff DEL ⟨c, u, s, e⟩FROM Application
AND SET jcid = c, uid = u, winner = u, result = e, qualif = false
Example (transfer): “pick an eligible candidate and select it as
a winner”

Data manipulation logic: Conditional Update
Job posted
[InsJobCat]
App. received
[InsUser]
Stop Stopped
Evaluate
CV
[CheckQual]
qualif =
true
Evaluate
Application
[EvalApp]
qualif =
false
Stopped
Decide
Eligible
Candidates
[MarkE]
Select
Winner
[SelWinner]
Assign
Winner
Make
Oﬀer
bulk update of all tuples in a repository relation  
with an IF…THEN…ELSE pattern

Data manipulation logic: Conditional Update
Job posted
[InsJobCat]
App. received
[InsUser]
Stop Stopped
Evaluate
CV
[CheckQual]
qualif =
true
Evaluate
Application
[EvalApp]
qualif =
false
Stopped
Decide
Eligible
Candidates
[MarkE]
Select
Winner
[SelWinner]
Assign
Winner
Make
Offer
bulk update of all tuples in a repository relation  
with an IF…THEN…ELSE pattern
Example (bulk): “assess the eligibility of all received (and
evaluated) applications; application eligible iff score > 80”
If α.eff is a delete&set rule, then the executability of the update is subject
to the fact that the tuple ⃗u selected by the binding and to be removed from
R, is actually present in the current instance of R. If so, the binding is used to
simultaneously delete ⃗u from R and update some of the case variables – with the
implicit assumption that those not explicitly mentioned in the SET part maintain
their current values.
Finally, a conditional update rule applies, tuple by tuple, a bulk operation
over the content of R. Each tuple in R is reviewed. If the tuple passes the
filter associated to the rule, it is updated according to the THEN part, otherwise
according to the ELSE part.
Example 4. Continuing with our running example, we now consider the update
specification MarkE handling the situation where no candidate has been directly
considered as qualified, and so the eligibility of all received (and evaluated)
applications has to be assessed. Here we consider that each application is eligible
if and only if its evaluation resulted in a score greater than 80. Technically,
MarkE.pre is a true precondition, and:
MarkE.eff UPDATE Application(c, u, s, e)
IF s > 80 THEN Application(c, u, s, true) ELSE Application(c, u, s, false)

Translation and Results
data
mgmt
business
artifacts
BPMN*
relational
artifact
systems
DAB

From DAB to RAS
Catalog —> Read-only DB sorts
Repository —> Each relation to a collection of arrays
Case variables —> Arrays of size 1
Lifecycle of Blocks —> treated as additional case vars
Execution semantics of blocks —> operations over arrays

From DABs to RASs
Catalog —> Read-only DB sorts
Repository —> Each relation to a collection of arrays
Case variables —> Arrays of size 1
Lifecycle of Blocks —> treated as additional case vars
Execution semantics of blocks —> operations over arrays 
(rule-based)
MCMT backward reachability algorithm handles
parameterized safety of DABs!
Call this algorithm BackReach…

Technical Results
BackReach is sound and complete

Technical Results
what about termination?

Technical Results
Cond. 1: no foreign key cycles in the catalog

Technical Results
is the repository bounded in size?

Technical Results
BackReach terminates
yes
Cond. 2a: repo as a
bookshelf

Technical Results
BackReach terminates
yes no
Cond. 2a: repo as a
bookshelf
Cond. 2b: “local” DAB 
Each repo-tuple evolves independently

Intuition of Locality
Naive case to avoid: retrieving multiple tuples at once
R S
query query
Tricky case to avoid: avoid implicit comparisons of
multiple tuples over time
repository
repository
case vars
query
In the paper: 
syntactic characterization of “local-preserving data manipulation”

Initial Experiments
MCMT encoding of the hiring example following
the translation rules
Definition of some relevant properties
• Process is “sound”
• Presence of dead activities
• Is it possible to select a bad candidate as a
winner?
• …
Check using MCMT… with encouraging results!
the separated precondition.
Example 8. By considering the data and process schema of the hiring process DAB,
one can directly show that it obeys to all conditions in Theorem 3, in turn guaranteeing
termination of BackReach. For example, rule EvalApp in Example 3 matches point 1
since EvalApp.pre is repo-free. SelWinner from the same example matches instead
point 3, since SelWinner.pre is trivially separated and all case variables appear in the
SET part of SelWinner.e↵. /
prop. time(s)
safe
1 0.20
2 5.85
3 3.56
4 0.03
5 0.27
unsafe
1 0.18
2 1.17
3 4.45
4 1.43
5 1.14
First Experiments with MCMT. We have encoded the job hir-
ing DAB described in the paper into MCMT, systematically follow-
ing the translation rules recalled in Section 3.2, and fully spelled
out in [3] when proving the main theorems of Section 3.3. Run-
ning MCMT Version 2.8 (http://users.mat.unimi.it/users/
ghilardi/mcmt/), we have checked the encoding of the job hiring
DAB for process termination (which took 0.43sec), and against five
safe and five unsafe properties. For example, the 1st unsafe prop-
18

Conclusion
SMT
data
mgmt
business
artifacts
BPMN*
array-based
systems
relational
artifact
systems
DAB
A foundational
and practical
route

Future Work
Tooling and benchmarking
Forall quantiﬁcation in guards 
Loose completeness, but very effective
SMT techniques
Arithmetics 
again, thanks SMT!

Formal modeling and SMT-based parameterized verification of Data-Aware BPMN

Recommended

Recommended

More Related Content

Similar to Formal modeling and SMT-based parameterized verification of Data-Aware BPMN

Similar to Formal modeling and SMT-based parameterized verification of Data-Aware BPMN (20)

More from Faculty of Computer Science - Free University of Bozen-Bolzano

More from Faculty of Computer Science - Free University of Bozen-Bolzano (20)

Recently uploaded

Recently uploaded (20)

Formal modeling and SMT-based parameterized verification of Data-Aware BPMN