Linking Data and BPMN Processes to Achieve Executable Models

CAiSE2017
Linking Data and BPMN Processes
to Achieve Executable Models
Giuseppe De Giacomo,
Xavier Oriol, Montserrat Estañol, Ernest Teniente

CAiSE2017
Content
• Context
• Our Approach
• Overview
• Starting Models
• The Playlists Example
• Achieving Executable Models
• Related Work
• Conclusions

CAiSE2017
 Hardware Retailer in BPMN
Context: A Process Model
Pros:
Intuitive
Straightforward
Clear
!However:
How does the Clerk decide if it is a normal post or requires a
special shipment?
When is extra insurance necessary?
By connecting with data, we would be able to
define precisely what each of the tasks does

CAiSE2017
Context
• Two assets in organizations:
UML Class Diagram BPMN Diagram

CAiSE2017
Context: Linking Data and Processes
• Data-centric approach to process modelling
• Data
• Details of the tasks => necessary to have data available
• Order of execution of the tasks
Achieve an executable process model based on the
data-centric approach
GOAL

CAiSE2017
Starting models
Standard notations
• We have to link them together
• Achieve executability
Data Processes
UML Class Diagram BPMN Diagram
How?

CAiSE2017
Playlists Example
 Process to create playlists from tracks of musical
albums
UML Class Diagram

CAiSE2017
Playlists Example
BPMN diagram
• We have to link them together
• Achieve executability
How?

CAiSE2017
Playlists Example
BPMN diagram
Issues
1. Keeping track of the process variables
2. Knowing what each of the tasks does

CAiSE2017
Playlists Example
1. Adding class
<<artifact>> to the
class diagram
Solution:

CAiSE2017
Playlists Example
2. Defining the tasks in OCL operation contracts
Solution:

CAiSE2017
Achieving Executable Models
 Now we have data and process linked
together…
 How do we achieve executability?

CAiSE2017
Achieving executable models
 How do we achieve executability?
– Translating them to other models
 Translation:
– UML class diagram => Database schema
– BPMN diagram => Petri net
– OCL Op. contracts => Logic rules that derive in SQL
statements

CAiSE2017
 UML Class Diagram to a DB Schema

CAiSE2017
 BPMN diagram to a Petri net

CAiSE2017
 OCL Op. Contracts to Logic Derivation Rules
Issues
OCL is declarative instead of imperative

CAiSE2017
For instance,
ins_P(x̅) :- opName(a), arg0_opName(x̅0), …, argN_opName(x̅n), pre(x̅pre), query(x̅q)
del_P(x̅) :- opName(a), arg0_opName(x̅0), …, argN_opName(x̅n), pre(x̅pre), query(x̅q)
result(x̅) :- opName(a), arg0_opName(x̅0), …, argN_opName(x̅n), pre(x̅pre), query(x̅q)
ins_Playlist(Pl) :- buildplaylist(A), artifactPlname(A,Pl)
ins_TrackIn(Tr, Pl) :- buildplaylist(A), artifactPlname(A,Pl), artifactTrack(A,Tr)

CAiSE2017
1. Determine the effect (ins/del) of the contract by recognizing OCL operations
2. Translate the arguments of the OCL operation into logic queries
Queralt, A., Teniente, E. Validation of UML Conceptual Schemas with Operations
CAiSE 2008

CAiSE2017
INSERT INTO Playlist SELECT plName FROM Artifact
INSERT INTO TrackIn SELECT track, plName FROM Artifact JOIN ArtifactTrack
These rules can be further translated into SQL
1. Determine the effect (ins/del) of the contract by recognizing OCL operations
2. Translate the arguments of the OCL operation into logic queries

CAiSE2017
Executing the framework
 We have implemented a Java library such that:
– Given (at compilation time) the models and a DB connection
– Given (at runetime) an operation name and its arguments
– The library updates the DB according to the specification of the
operation invoked
http://www.essi.upc.edu/~xoriol/opexec

CAiSE2017
 Architecture

CAiSE2017
 What do we have now?
– Execution of 1st order operations in the DB
– Incrementally controlling the consistency of 1st order constraints
– Controlling concurrent invocations of operations
 What do we have to incorporate?
– Current input models are the logic translations, we plan to move
to real UML/OCL models
– Checking the BPMN flow is outside the library

CAiSE2017
Related Work
 Business Process Validation
– Approaches fully based on logics
– Approaches based on formal Graphical Languages
• Guard-Stage Milestones, Artifact union graphs, etc
 Business Process Execution
– BPEL, XML nets (Petri-nets based), YAWL
All of them use formal languages, but our approach uses
standard well-known languages: BPM+UML/OCL, at the
cost of using/defining a formal interpretation for them.
Our approach is aligned with the work of [1], but we aim
here at execution rather than validation
[1] Estañol, M., Sancho, M., Teniente, E.: Verification and validation of UML artifact-centric business
process models. In: CAiSE 2015. Volume 9097 of LNCS., Springer (2015) 434–449

CAiSE2017
Conclusions
 We have proposed a framework for linking data and processes:
– BPMN to define the process
– UML to define data + a UML artifact class to define the process data.
– OCL to define how BPMN activities modify UML data
 The framework is formal enough to be executed:
– BPMN -> Petri Nets
– UML -> SQL tables
– OCL -> Logic Rules -> SQL statements
 We have implemented the framework as a Java library
– It uses an Incremental Integrity Checking mechanism
– http://www.essi.upc.edu/~xoriol/opexec/

CAiSE2017
Thanks for
your attention
Full paper at:
https://doi.org/10.1007/978-3-319-46523-4_11

Linking Data and BPMN Processes to Achieve Executable Models

More Related Content

Similar to Linking Data and BPMN Processes to Achieve Executable Models (20)

Recently uploaded (20)

Linking Data and BPMN Processes to Achieve Executable Models