Process view framework for artifact centric business processes

Sira Yongchareon and Chengfei Liu

Faculty of Information & Communication Technologies

Swinburne University of Technology, Australia

A Process View Framework for Artifact-Centric Business Processes

CoopIS’10 on 25-29 October 2010, Crete, Greece

CoopIS’10, 27-29 October 2010, Crete, Greece Sira Yongchareon and Chengfei Liu 2

Introduction & Motivation to View Related Work & Problems Process View Framework

View definition View construction View consistency rules

Conclusion

Outline


The traditional Task (Process)–centric (workflow) approaches

Tasks / Activities – Which work is required to be accomplished Control flow – How those work are ordered (sequence, split, parallel)

Key disadvantages of this approach? Strictly glued by control flows The steps to complete the process Hard to modify and inflexible - if a change needed, then

How to ensure that the after-process can achieve the goal ? To achieve some states of objects involved in the process

How to preserve the integrity and consistency of data effected by the change?

The key point is the “objects” behind the processes

Introduction : Processes modelling

A BC

DE


The key components Business artifacts or entities –

constitute concrete information chunks that the business creates and maintains, i.e., business records, documents

have life cycles that capture the end-to-end processing of a specific artifact, from creation to completion and achieving

Tasks/Services – used to create/update artifacts and move the state of artifacts from creation to completion and

achieving

Associations – associate tasks with artifacts services in a process make changes to artifacts in a manner that is

restricted by a family of constraints e.g., Business rule On what condition, a task is performed (on which

artifact)

Introduction : Artifact-centric models


Introduction : Business artifacts Artifacts and their lifecycle – Selling process example

The ordering process starts when a customer places an order to the retailer for a particular product and ends when the customer pays the invoice.

The shipping process starts when the retailer creates a shipment and ends when the item arrives to the customer


Introduction : Associations Business rules – to associate artifacts and tasks


Introduction : Framework 4-Dimensional Framework for Artifact-Centric Business

Process Modeling (Hull, 2008)


Introduction : Why artifact-centric?Process-Centric Artifact-Centric

Focus Activities and control dependencies

Data, Business entity and lifecycle

Process dimension Behavioural and individual (informational) context of activity

behavioural andcomplete context of process

Specification approach

What should be doneHow to achieve goals

What can be doneWhat is required to achieve goals

Language / Schema Procedural, DAG-based Declarative, Rules-based

Flexibility / Adaptability

Low, Integrity and dependency checking of data is required

High, Easy to modify and verify

Process Consolidation

Difficult, need to agree on the unified model

Easy, the specification is operational and goal-oriented


Motivation to Process views Vertical vs. Horizontal dimensions


Motivation to Process views Business Artifacts in the enterprise/collaborative processes

Vertical dimension – involved in single functional business unit/department Horizontal dimension – involved in various functional units or even cross-

organizational boundary What are the concerns?

Different level of privacy, authority, access in both vertical and horizontal dimensions Different level of detail/interest for different stakeholder

The need of customization of views of artifacts and process information


Motivation to Process views A framework that enables a customization of views for artifact-

centric business processes – to support different level of details based on role, authority control, or privacy requirements

Three-layered architecture


Related work Artifact-centric business processes

Conceptual framework - BALSA (Richard Hull, 2008) Formal model and Analysis (Kamal Bhattacharya et al., 2007) Specification language and static verification (Cagdas E.

Gerede et al., 2007) Automatic verifications (Alin Deutsch et al., 2009) Workflow generation (Christian Fritz et al., 2009, Guy Redding et

al., 2007, Jochen M. Kuster et al., 2007)

Facilitating Workflow Interoperation Using Artifact-Centric Hubs (Richard Hull et al., 2009) - Introduce a concept of View, Window, and CRUD for individual and independent artifacts


Current issues and challenges? View approach for process-centric model (graph-based

abstraction/aggregation) different to artifact-centric model Views of a single artifact or multiple artifacts? What about views of business rules, and processes?

Current artifact-centric view concept still very superficial While traditional concept of view for database only focuses on

attribute of entities only not behavior of entities Context of processes not considered

Associations – Rules, services and artifacts Dependencies/ synchronizations / interactions between artifacts

No validation approaches to view construction


Problem definitions Given Artifact-Centric Process (ACP) model

How to define views for the underlying process model Which part an artifact is visible/invisible to which role

How to construct views – of artifacts and processes Not only artifacts but also business rules that govern the changes

(behaviour) of artifacts and the flows of processes An artifact may be involved in multiple processes

How to validate constructed views against its underlying business process model


View Framework : Artifacts Individual artifact – Artifact Life-cycle and State tree

Artifact lifecycle – a variant of state machine

Artifact state tree


View Framework : 2 types of view Operational view vs. abstract (role-based) view

Sale viewSale view Accounting viewAccounting view

Operational viewOperational view


View Framework : Definitions Definition (Artifact class). An artifact class C is a tuple (A, S)

where, A is a finite set of attributes of a scalar-typed value (string and real

number) or an undefined value S is a finite set of states

Definition (Artifact schema). An artifact schema Z contains a set of artifact classes

Example Order = ({orderID, customerID, grandTotal}, {open_for_item,

ready_for_shipping, in_shipping, shipped, billed, closed}) Shipment = ({shipID, customerID, shipDate, shipCost}, {open_for_shipitem,

ready_to_dispatch, in_shipping, completed}) OrderItem = ({orderID, productID, shipID, qty, price}, {newly_added, on_hold,

ready_to_ship, added_to_shipment, in_shipping, shipped}) Invoice = ({invoiceID, ordereID, invoiceDate, amountPaid}, {unpaid, paid})


View Framework : Definitions (cont.) Definition (Business Rule). On what pre-condition, a

task is performed and the post-condition holds. Business rule r can be defined as tuple (, , v) where,

and are a pre-condition and post-condition, respectively, of quantifier-free first-order logic formula. The formula contains two types of proposition over schema Z:

state proposition

attribute proposition (with scalar comparison operators)

v is a task/service to be performed. A service may involve with several artifacts of classes


View Framework : Definitions (cont.) Example of business rules


View Framework : Definitions (cont.) Definition (Artifact-Centric Process Model or ACP

model). Let denote an artifact-centric process model, and it is tuple (Z, V, R) where,

Z is an artifact schema contains a set of artifact classes

V and R are sets of services and business rules over Z, respectively.


View Framework : Definitions (cont.) Definition (Artifact view). Given artifact class C, we denote

for a view of C for role l, and it is tuple (Al, Sl, pc) Sl is a set of states defined in a hierarchal tree structure pc Sl × Sl is a finite set of parent-child relations

Definition (ACP view). Given role l and ACP model = (Z, V, R), we denote for the ACP view of for role l, and it is tuple (Zl, Vl, Rl), where

Zl, Vl, Rl and is a set of views of artifact classes for role l, services, and business rules over Zl, respectively,

such that for every view ClZl of artifact class C then CZ

For artifact view, sy: {s1, s2, .., sx} denotes composite state sy together with its nested states {s1, s2, .., sx}


View Framework : Definitions (cont.) Revisiting Operational view vs. Role-based view

OrderSale = {created : {init, open_for_item}, ready_for_shipping, in_processing : {delivering : {in_shipping, shipped}, billed}, closed}


View Framework : Definitions (cont.) Definition (Artifact Lifecycle Model). Given ACP model = (Z,

V, R) and artifact class Ci = (Ai, Si ) where Ci Z, an artifact lifecycle modelfor Ci, denoted as LMCi, can be defined as tuple (Ci, T), where

T Ci.S R Ci.S is a 3-ary transition relation. A transition t = (s1, rx, s2)T means that the state of the artifact will change from s1 to s2 if the pre-condition of business rule rx holds.

T* is reflexive transitive closure of T. s1T*s2 if there exists sequence of transitions from s1 to s2 by some business rules in R.

LMCi can be generated by deriving corresponding business rules that are used to induce state transitions of Ci


View Construction View transformation - by state condensation technique

State composition (sc) State hiding (sh)


View Construction Assume the existence of ACP view set = {, l1,

l2 , …, lx}, where is the operational view of ACP model and li is an ACP View for role

liL(1ix), forms a hierarchal structure having as its root

Definition (View transformation). Given ACP view set for ACP model = (Z, V, R), the view transformation vt = sh sc: × SR+ × SR- is a composite function.

Function vt(, sr+, sr -) returns a role-based view, i.e., , l of ACP model that constructed based on state composition requirement sr+ and state hiding requirement sr - for role l.


View Construction Definition (State composition). Given ACP view set

for ACP model = (Z, V, R), the state composition sc: × SR+ is a bijective function that maps one ACP view onto another ACP view

SR+ is state composition requirement set that define composite states in a state tree for each artifact class in Z


View Construction Definition (State hiding). Given ACP view set for ACP

model = (Z, V, R), the state hiding sh: × SR - is a bijective function that maps one ACP view onto another ACP view

SR - is state hiding requirement set that define hidden states in a state tree for each artifact class in Z

SR - is valid if a parent of each state in SR - is not the root state


View Validation Assume the existence of ACP view set = {, l1,

l2 , …, lx}, where is valid if every view in preserves the view

consistency rules consistency between each view in and its derived view

(including its base process model)


View Validation : Consistency Rules Rules for state tree preservation

Rule 1: (Hierarchy preservation)

Rules for state transition preservation Rule 2: (State ordering relation preservation) Rule 3: (Atomicity of composite state preservation) Rule 4: (Business rule – transitions of multiple artifacts

preservation)

Rules for attribute condition preservation Rule 5: (Attribute condition preservation)


Consistency Rules : State tree Rule 1 (Hierarchy preservation)

To preserve the consistent structure of the state tree after the composition function has applied, i.e., a composite state is correctly inserted and structured in the tree

Let l1 be ACP view for role l1 and l2 = sc(l1 , sr+) be ACP view for role l2 that is constructed based on l1 with state composition requirement sr+.

For any state that belongs to the same artifact class Ci in both l1 and l2 , the set of ancestors S1 of sx in l1 is a subset of the set of ancestors S2 of sx in l2 , and the states in S1 but not in S2 do not exist in l1


Consistency Rules : State tree Rule 1 (Hierarchy preservation) - Example

The set of ancestors of the shipped state for both views Of view [1] is {root}, while of view [2] is {delivering, in_processing, root},

{root} {delivering, in_processing, root}, and {delivering, in_processing } in [2] not appear in [1]

shipped state preserves the hierarchy consistency between [1] and [2] Every state that appears in both [1] and [2] must preserve this consistency

1

2


Consistency Rules : State transition Rule 2 (State ordering relation preservation)

To preserve the consistent order between two states

Let l1 and l2 be ACP view for role l1 and role l2, respectively. For any two states that belong to two views of the same artifact class Ci in both l1 and l2 , the ordering relation between them must be consistent, i.e.,

If sx, sy l1.S l2 .S such that sx < sy in l1, then sx < sy in l2

or if sx, sy l1.S l2 .S such that sx || sy in l1, then sx || sy in l2, where sx || sy ((sx < sy ) (sy < sx))


Consistency Rules : State transition State conditioning modification of business rule

Hiding (sh) any state of an artifact will break up the transition relation between such hidden state and other state

Transition rearrangement is required

Combined diagram of state tree and lifecycle for the OrderSALE view


Consistency Rules : State transition Rule 3 (Atomicity of composite state preservation)

To preserve the existence of transition between hidden state and non-hidden state, and the nonexistence between hidden state and hidden state

If any state under the composite state is hidden, then An entry transition (from non-hidden state to hidden state) must

be rearranged to composite state An exit transition (from hidden state to non-hidden state) must be

rearranged to composite state An inner transition (from hidden state to hidden state) must be

removed

Formal description can be found in the paper


Consistency Rules : State transition Rule 3 (Atomicity of composite state preservation) –

Example

For composite state created,r1 and r2 are inner transitions to be hidden r3 and r11 are exit transitions to be rearranged


Consistency Rules : State transition Rule 4 (Business rule integrity preservation).

To preserve the integrity of a business rule of a hidden transition where the rule is used in multiple artifacts

Let l1 be ACP view for role l1 and l2 be ACP view for role l2 that is constructed based on l1.

If a business rule induces transitions of multiple artifacts and any of these transitions in one artifact is hidden in l2 then such rule and its induced transitions in the other artifacts must be hidden in l2


Consistency Rules : State transition Rule 4 (Business rule integrity preservation) -

Example


Consistency Rules : Attribute condition Attribute conditioning modification of business rule

The loss of specific states when rearranging transition from the concrete state to the composite state.

Attempt to maintain the condition of each business rule that corresponds to the rearranged transition as most specific as possible

What should be the attribute condition of rule r3_ex?- Need to find the condition that the open_for_item state must hold – that is the post-conditions of r1 r2

What should be the attribute condition of rule r3_ex?- Need to find the condition that the open_for_item state must hold – that is the post-conditions of r1 r2


Consistency Rules : Attribute condition Definition (Compensating condition). Given ACP = (Z, V, R) and

artifact lifecycle model LMCi = (Ci , T) for artifact Ci Z, a compensating condition on state sjCi.S, denoted as sj , is the logical disjunction of every attribute proposition of Ci in post-condition of every business rule rR that triggers a transition from any state in Ci.S to state sj


Consistency Rules : Attribute condition Consistency Rule 5 (Attribute condition preservation)

to maintain the condition of each business rule that corresponds to the rearranged transition as most specific as possible

For any rearranged exit transition of a composite state, the attribute condition of the pre-condition of a business rule for such

rearranged transition must hold : pre-condition of the original rule, and compensating condition on the source state of such transition

the post-condition remain unchanged (since the state does not hold the post-condition of any business rule that induces exit transition)

For any rearranged entry transition of a composite state The pre-condition and post-condition remain unchanged (as same

as its original rule)


Consistency Rules : Attribute condition Consistency Rule 5 (Attribute condition

preservation) - Example

Rule r3_ex for the OrderSALE view-pre-condition : open_for_item r3.-post-condition : r3.

Rule r3_ex for the OrderSALE view-pre-condition : open_for_item r3.-post-condition : r3.


View Consistency Rules Rules for state tree preservation

Rule 1: (Hierarchy preservation)

Rules for state transition preservation Rule 2: (State ordering relation preservation) Rule 3: (Atomicity of composite state preservation) Rule 4: (Business rule integrity preservation)

Rules for attribute condition preservation Rule 5: (Attribute condition preservation)

These rules are used to preserve structural and behavioral consistencies between the constructed view and its underlying business process model


Conclusion Artifact-centric approach emerged as a new paradigm of business

process modelling Focus on business entities and their lifecycle Goal-oriented States of business artifacts Flexible Declarative, rule-based language

Artifacts involved and interested by vertical and horizontal (even cross-organizational) dimensions

the need of the customization of views to support different level of detail/interest

A novel process view framework for artifact-centric processes Allow different views of artifact for different role of stakeholders Formal construction approach views of artifacts and processes Formal validation approach a complete set of consistency rules


Conclusion : Future work Given conflict view requirements

View of one artifact violates some views of other artifacts Find the minimal condensation to satisfy every requirement Algorithm & Proof

Relax vs. Strict view requirements


Thank you

Process view framework for artifact centric business processes

Technology

business artifacts artifacts

artifact introduction

ordering process

process example

shipping process

artifactcentric models

process views vertical

underlying process model