A view framework for modeling and change validation of artifact centric inter-organizational business processes

Contents lists available at ScienceDirect

Information Systems

Information Systems 47 (2015) 51–81

http://d0306-43

E-mcliu@swxiaohui

journal homepage: www.elsevier.com/locate/infosys

A view framework for modeling and change validationof artifact-centric inter-organizational business processes

Sira Yongchareon a, Chengfei liu b, Yu Jianc, Xiaohui Zhao d

a Department of Computing, Unitec Institute of Technology, Auckland, New Zealandb Faculty of Science, Engineering and Technology, Swinburne University of Technology, Victoria, Australiac School of Computer and Mathematical Sciences, Auckland University of Technology, New Zealandd Faculty of Business, Government and Law, University of Canberra, Canberra, Australia

a r t i c l e i n f o

Article history:Received 27 November 2012Received in revised form13 June 2014Accepted 21 July 2014Available online 1 August 2014

Keywords:Business process modelingArtifact-centric workflowsInter-organizational business processesProcess viewsProcess abstractionModel verification

x.doi.org/10.1016/j.is.2014.07.00479/& 2014 Elsevier Ltd. All rights reserved.

ail addresses: [email protected] (S. Yongchain.edu.au (C. liu), [email protected] (J. Yu),[email protected] (X. Zhao).

a b s t r a c t

Over the past several years, more efficient approaches have been on increasing demandsfor designing, modeling, and implementing inter-organizational business processes. In theprocess collaboration across organizational boundaries, organizations still stay autonomic,which means each organization can freely modify its internal operations to meet itsprivate goals while satisfying the mutual objectives with its partners. Recently, artifact-centric process modeling has been evidenced with higher flexibility in process modelingand execution than traditional activity-centric modeling methods. Although some effortshave been put to exploring how artifact-centric modeling facilitates the collaborationbetween organizations, the achievement is still far from satisfaction level, particularly inaspects of process modeling and validating. To fill in the gaps, we propose a viewframework for modeling and validating the changes of inter-organizational businessprocesses. The framework consists of an artifact-centric process meta-model, public viewconstructing mechanism, and private view and change validating mechanisms, whichare specially designed to facilitate the participating organizations to customize theirinternal operations while ensuring the correctness of the collaborating processes. We alsoimplement a software tool named Artifact-M to help organizations to automaticallyconstruct a minimal and consistent public view from their processes.

& 2014 Elsevier Ltd. All rights reserved.

1. Introduction

Recently, service-oriented architecture (SOA) has become apredominant IT tool for facilitating businesses to meet thechanging requirements of themarket. SOA particularly enablesthe business collaboration across organizations by composingWeb services to achieve a mutual business goal withoutcomprising the autonomy of participating organizations. The

reon),

further application of SOA in facilitating business collaborationcalls for efficient approaches for designing, modeling andimplementing inter-organizational business processes [50].Recently, work by Desai et al. [20], Ghattas, Montali et al.[63] and [83] shows that the quality of coordinating organiza-tions in a service-oriented collaboration relies on three majorrequirements, viz., compliance, flexibility, and autonomy. Com-pliance requires all parties must provide the services as theyhave promised in the collaboration commitment, such as aservice level agreement. Flexibility allows each party to ownthe freedom of changing and implementing its own process inthe collaboration. Lastly, autonomy indicates each participatingorganization acts independently and is not obliged to reveal its

www.sciencedirect.com/science/journal/03064379

www.elsevier.com/locate/infosys

http://dx.doi.org/10.1016/j.is.2014.07.004



http://crossmark.crossref.org/dialog/?doi=10.1016/j.is.2014.07.004&domain=pdf



mailto:[email protected]





S. Yongchareon et al. / Information Systems 47 (2015) 51–8152

own private information (or process) to other parties.Although service choreography defines common collaborationbehaviors and keeps the flexibility and autonomy of eachparticipant, actual choreography modeling approaches andrelated modeling languages mainly describe the collaborationfrom a procedural perspective, and focus on control-flow,message sequencing, etc., instead of from a data perspective.As such, flexibility and autonomy is still limited by the natureof choreography modeling languages. The work on declarativespecification of service choreographies has been proposed byMontali et al. [63], on the basis of DecSerFlow language [84],to overcome such limitations and support dynamic andcomplex inter-organizational process specifications. Prior tothe emergence of service choreography, process view has beenadopted to address the flexibility and autonomy issues inbusiness collaborations, and the improvement has beenextensively evidenced in work by Van Der Aalst and Basten[81], Liu and Shen [51,52], Schulz and Orlowska [77], Chiuet al. [16,17], Chebbi et al. [14], Eshuis and Grefen [10], Zhaoet al. [100,101], Jiang et al. [40] and Eshuis et al. [27].Originally, a public-to-private view approach has been intro-duced by [85] and van der Aalst et al., [82] to resolve theprivacy and autonomy issues as well as to support changemanagement in dynamic collaboration. Most recently, [83]have proposed a multiparty process-oriented contract tosupport service choreography based on the concepts ofpublic/private views and accordance along with operatingguidelines [61,57]. However, all of above works follow thetraditional activity-centric business process modeling para-digm and thereby inherit the limitations in data management,process integration, and process modification, because tradi-tional modeling approaches lack adequate supports of auto-mated tools for business process inter-operation and processschema reuse [38,39].

In the past few years, a new modeling approach has emer-ged, i.e., artifact-centric (operational) business process model-ing [68]. Instead of control flows of a business process, businessdocuments and their evolution through a business processbecome the main modeling objects. This approach depicts abusiness process in four dimensions, viz., business artifacts,lifecycle of artifact, services, and associations between artifactsand services [34]. The lifecycle of an artifact is defined in termsof “business stages” and the possible evolution of the artifact.The evolution of an artifact and operations of related servicesare specified in terms of their associations, which can beexpressed in a declarative manner, e.g., using ECA rules.As an emerging tool Guard–Stage–Milestone meta-modelis becoming a new declarative approach to modelingartifact lifecycle based on a variant of state machines[35,36,21,22,80]. With the efforts of numerous academicresearchers and industrial practitioners, artifact-centricmodeling approach has been extensively recognized tobe with higher level of robustness and flexibility for describ-ing process specification compared to traditional activity-centric approaches. Artifact-centric process modelingreceives comprehensive contributions in terms of businesstransformation practices [6,7,13], foundations [5,59], designmethodologies [8,19,56,64,65,73,74,86], model specifica-tion, construction, and verification [54,30,31,44,25,29,102,103,21], workflow realization/execution [18,53,66,91,67,88],and monitoring/conformance supports [55,28]. Up to present,

artifact-centric approach has been applied to several indus-try domains such as healthcare (e.g., PHILharmonicFlowsframework [45,15]), insurance (e.g., in [44]), and finance (e.g., IBM Global Financing [13]). However, compared withtraditional activity-centric approaches, further research issought after in the area of business collaboration.

By now two main approaches have been proposed forartifact-centric inter-organizational processes. The initialattempt uses artifact-centric interoperation hub to facilitateand support inter-organizational workflows (in an orchestra-tion perspective) among multiple autonomous stakeholders[37]. Recently, this work has been brought forward to an EU-funded project called Artifact-Centric Service Interoperation(ACSI) [3]. It is promised to support a large number of servicecollaboration by using artifact-centric inter-operations and toachieve dramatic savings over conventional approaches. Onthe other hand, the artifact-centric choreography approachhas defined interacting artifact-centric processes [58,79].Although flexibility is naturally deemed as one of the benefitsfrom artifact-centric modeling approaches, a comprehensivestudy on supporting organizations to achieve all the threecollaboration requirements is still missing. Based on literatureand practices, we have observed that view-based approachesto inter-organizational business process management canprovide a promising and efficient way of process modelingand change management to address such requirements;nevertheless, it has not been yet much explored in the contextof artifact-centric inter-organizational business processes.Therefore, in this article, we are to explore the idea of processview in an artifact-centric perspective and develop a frame-work that can help organizations to meet the aforementionedrequirements in a collaboration environment. We summarizeour contributions as follows:

�
We propose a formal artifact-centric view frameworkbased on LTS (Labeled Transition System). This frame-work consists of three parts: (1) an artifact-centric Metamodel for inter-organizational business processes, (2)notion of private view for capturing local processes ofparticipating organizations, and (3) notion of public viewfor serving as an agreed contract of the collaboration.With public/private views, organizations are able toautonomously participate in the collaboration whilebeing free to change their local processes.
�
We design an algorithm for automatically constructing aconsistent, minimal public view based on local pro-cesses of an organization. To the best of our knowledge,this is the first algorithm for automatically constructinga collaboration contract that takes into account interac-tion behaviors of artifacts.
�
We develop a verification mechanism for artifact-centricprocesses that allows organizations to change their localprocesses, through the use of private views, whilepreserving the correctness and consistency of the over-all collaboration. As the verification is performed locally,our mechanism does not suffer from the state explosionissue that may occur in global verification approaches.
The remainder of this article is organized as follows:Section 2 introduces the motivation of our artifact-centric

S. Yongchareon et al. / Information Systems 47 (2015) 51–81 53

approach and the concept of process views. Section 3presents our view framework for artifact-centric businessprocesses. Sections 4 and 5 address how to create publicviews and private views as well as how to ensure viewconsistency and validate local process changes, respec-tively. Section 6 discusses an implemented prototype forthe proof-of-concept purpose. Section 7 reviews the relatedwork. Finally, conclusion and future work are given inSection 8.

2. Motivating example

In this section, we use a purchasing process in the supplychain collaboration domain as an example to illustrate andmotivate the artifact-centric approach to modeling inter-organizational business process collaboration. In Fig. 1, acomplete purchasing process model in the collaboration isillustrated based on an artifact-centric perspective, whichinvolves three roles of participating organizations: Buyer,Supplier, and Logistics. We initiate the discussion of thisexample by identifying involved business artifacts anddescribing how they are modeled in this collaboration.

At the beginning stage, all parties identify and modeltheir required business artifacts of their local processes.This step includes defining organization-owned artifacts(called local artifacts) that are internally used/managed byindividual party as well as their commonly agreed artifacts(called shared artifacts) that are used for the coordinationbetween parties in the collaboration. We consider that thelifecycle of a shared artifact should represent its agreedbusiness stages and possible steps towards the completionof the process. In other words, shared artifacts should beused as a mutual point of interest of all parties; therefore,the coordination occurs at some points where they are

Buyer (L1) SupplPurchase Order (PO)

Picking List (PL)

readFilled order

checking

Quote (Q)

created approving

approved

In s

Invoice (IV)cleared

created confirmedL1

closed billingL2

canceled

accepted

acquiringL2L2

L2

Out of stock

L2

L1

issuedsentL2

L2

Payment (P)

createdapproving

sent

unpaid

L1

L1

rejected

L1on hold

L1

clearingL2

Fig. 1. A complete artifact-centric inte

processed. In the implementation, these shared artifacts actas messages that are sent and received by these organiza-tions. Based upon the current processing state of the sharedartifact, a responsible organization that has received thisartifact will invoke a specific service according to a corre-sponding business rule defined by that organization. Thisservice will then read or update the shared artifact andother local artifacts defined in the specification.

In Fig. 1, we can see that the inter-organizational processconsists of Purchase Order (PO), Shipping Order (SO), andInvoice (IV) as shared artifacts. Apart from them, Buyer,Supplier, and Logistics have Quote (Q) and Payment (P),Picking List (PL) and Delivery Note (DN), and Shipping List(SL) as their local artifacts, respectively. In the figure, wealso use dashed line to depict the synchronization depen-dencies between artifacts (local-local, shared-shared, orlocal-shared).

Next we briefly describe the process in Fig. 1 from anartifact-centric perspective. At the beginning of the process,a buyer initiates the creation of the Quote and the POdocuments/artifacts. Once the quote is approved, the PO isconfirmed and sent to a selected supplier. When thesupplier receives the PO, it creates a PL document for thepurpose of acquiring goods for that PO. If the goods run out,then the supplier rejects to supply them and then cancelsthe PO. Otherwise, the goods are filled, and then thesupplier generates an internal DN document and creates aSO document for the designate logistics company. Once theSO is received, the logistics company creates a SL documentthat is used for picking up the goods from the supplier’sshipping point and also delivers the goods to the buyer.After that, the supplier creates an IV document and sends itto the buyer. Sometime later, the buyer clears the totalamount owing in the IV, consequently, the supplier marksthe PO as closed. This purchasing process completes when

ier (L2) Logistics (L3)

y to fill

tock

Shipping Order (SO)

In transit

arrived

Shipping List (SL)

Queued

pickedcompleted

L2

filled

delivering

L2

ready to shipL2

L3created

L2

Delivery Note (DN)

prepared

transferring

L3scheduled

dispatched

L3

r-organizational purchasing process


the PO is in the closed state, the SO is in the arrived state,and the IV is in the cleared state.

In the context of inter-organizational process collabora-tion, some concerns—including change flexibility, changeverification, and privacy—raised in the traditional activity-centric approach (e.g., in [85,32]) should also be consideredin an artifact-centric setting as discussed below.

First, organizations prefer to keep the freedom of mod-ifying their internal processes without revealing their localchanges to other participating parties. In other word, oncethey have agreed on the overall process, they should have,possibly, the highest level of flexibility to modify their ownlocal processes while remaining autonomous in the colla-boration [85,82,83]. For example, Supplier may modifysome processing steps of its PL artifact, and such changeshould not be exposed to Buyer and Logistics. Apart fromthe change of existing local artifacts, they should beallowed to add new local artifacts to their process causedby process expansion/improvement. For instance, Suppliermay need to incorporate Inventory List (IL), which is usedfor inventory management, to their process. The IL artifactneeds to interact with existing local artifact PL. It alsoimplies that IL indirectly contributes to the part of sharedartifact PO through PL. In order to support the change oflocal processes, organizations need to know what theywant to modify and how such modification can be applied.

Second, stemmed from the first reason, the change toany local process should not affect the behavior of theoverall collaboration. This implies that a local processshould always comply with the contract agreed by allparties, and the change made to local processes shouldnot affect the overall process. Therefore, all parties mustensure that their local changes do not violate the collabora-tion contract. For example, if Supplier changes their PLartifact by removing a transition ready_to_f ill-f illed_order, then this may affect the transition acquiring -

f illed of PO; consequently, Logistics is not able determinewhether the goods are ready to be picked for delivery. Inaddition, all participating parties should also be aware ofthe local changes that will propagate and eventually affectthe overall process. For instance, if there are some changesmade on IL artifact, then they directly affect the PL artifactand eventually affect the PO artifact. This raises the issue ofhow we can guarantee that local changes made by anindividual party do not lead to incorrect behavior of theoverall collaboration. In other words, organizations mustensure that changes in their local processes are in compli-ance with what they have promised to provide.

Last, organizations concern about their privacy. In thecollaboration, it is necessary for the participating organiza-tions to reveal certain details of their internal processesamong themselves at an adequate level of visibility as toestablish an overall picture of the collaboration, which isused as a process agreement or contract among them. Inour artifact-centric inter-organizational process modelingapproach, the level of visibility can be determined based onthe type of artifacts. In other words, details of local artifactsshould be kept invisible to external parties as much aspossible while they also support the overall process bymeans of dependency associations with some processingpart (lifecycle) of the shared artifact(s). Consider the DN

artifact in Fig. 1 for instance. The DN is privately used bySupplier; however, we can see that it has dependencyassociations with the sub-lifecycles of the PO (f illed-ready_to_ship - dispatched) and SO (�-created-scheduled- in_transit), which are shared artifacts. Simi-larly, both Quote and PL artifacts are used to support someprocessing steps of the PO artifact. To achieve privacy, if aprocessing step of a shared artifact is exclusively controlledby the local artifact(s) of one party, then that step shouldnot be visible to other parties. For example, the ready_to_ship state and its related transitions of PO should be keptinvisible to external parties because DN is a local artifactof Supplier. Apart from that, we can see that the stepcreated-scheduled of SO can be hidden to external partiesas well. In order to support the privacy requirement, anorganization needs to have a mechanism to identify anartifact and/or its parts that can be invisible to the otherparties. This brings up in the question of to what extent of alocal process can be kept private while not affecting thesuccessful establishment of the collaboration.

The three major concerns discussed above call for anapproach to efficient modeling and change management ofartifact-centric inter-organizational business processes. Aspreviously discussed, in this article, we study how organi-zations can apply the concept of view to support andfacilitate the modeling of their collaborating businessprocesses in an artifact-centric paradigm. Particularly, weborrow the idea of public and private views approach tointer-organizational workflows which is originally studiedin activity-centric business process modeling approaches[85,82,83], and then explore it in the context of artifact-centric processes.

3. View framework for artifact-centric inter-organizational processes

In this section, we introduce and discuss our viewframework for artifact-centric inter-organizational businessprocesses. In Section 3.1, we overview our view frameworkthat aims at addressing the aforementioned requirementsfor efficient inter-organizational business processes colla-boration. Then in Section 3.2, we formally define the viewframework and discuss how to use it to model inter-organizational business processes followed by the discus-sion of behavior properties in Section 3.3.

3.1. Overview

We start this section by introducing our view frame-work for modeling artifact-centric inter-organizationalbusiness processes - which is influenced by the process-oriented contract approach proposed for service choreo-graphy [83]. Our artifact-centric view framework consistsof the following four parts: (1) Artifact-Centric businessProcess model for inter-organizational business processes(ACP-i model), (2) public view and its construction method,(3) process change mechanism, and (4) process changevalidation. Fig. 2 depicts the overall picture of the frame-work by taking our motivating purchasing processes as anillustrative example.

ACP-i

ACP ACP ACP

ACP-i (modified)

ACP ACP ACP

PUBLIC VIEWpa(ACP-i)

private view change validation

public view construction2

4

inter-org process construction1

changes in local processes

Purchase Order

Shipping Order

Invoice

Buyer Supplier Logistics

Picking ListQuote

Shipping List

Payment

Deliver Note3

′

Fig. 2. Our view framework for artifact-centric inter-organizational business processes.


Our view framework is developed based on the notionof private view and public view proposed by [85]. A privateview is used to capture the local processes of each individualorganization, while a public view of a particular collabora-tion process is an abstract representation of the overallprocess that is necessary for the coordination and hides thedetails of the private processes of each organization asmuch as possible. Organizations can achieve an efficientcollaboration (regarding the three requirements) based onthe public–private views approach by the following foursteps as illustrated in Fig. 2.

(1)
Construct a complete artifact-centric model specifica-tion of inter-organizational business process
(2)
Create a public view that is served as a mutual agree-ment, i.e., contract, of the collaboration.
(3)
Each organization can change and validate their localprocesses, via the use of private view, without the needfor global verification.
First, all participating parties specify a complete speci-fication of their inter-organizational business process as toachieve their goal of the collaboration. As previously dis-cussed, the coordination among them can be specified bydefining all shared artifacts and their interactions with localartifacts (from each party). We call the Artifact-CentricProcess model of the complete inter-organizational processan ACP-i model. Once all participating organizations haveagreed on the complete model of the artifact-centriccollaboration process, they construct an agreed public viewof such process. This public view reveals only the necessaryinformation of artifacts that is required to be used for thecoordination among parties. In the perspective of artifact-centric process modeling, a public view should only containshared artifacts and should not reveal any local artifact orthe part of a shared artifact that is supported by localartifact(s).

Once the public view is built as a contract, eachparticipating party has the responsibility to ensure that

its local processes (i.e., responsible parts of shared artifactsand their local artifacts) can provide what has beenspecified in the contract to other parties involved in thecollaboration. The most important things are as follows: (1)the constructed public view must be sound and consistentwith its base process; and, (2) when an organizationmodifies its own parts of both types of artifacts used inthe collaboration, it must guarantee that such local changesdo not compromise the correctness of the overall collabora-tion. We will discuss the construction of a public view andchange management in a local process in detail in Section 4and 5.

3.2. Syntax for ACP-i model

Here, we formally define the artifact-centric processmodel for inter-organizational business processes, or ACP-imodel, which is an extended version of the ACP modelpresented in our previous works [97,98,95,96,94]. An ACP-imodel consists of four main components: roles, artifacts, tasks,and business rules. Roles define a set of participating organiza-tion roles in the collaboration. An artifact is a business entityor an object involved in inter-organizational business pro-cesses. A task is owned by one organization in the collabora-tion and is used to perform read/update operations on artifact(s). A business rule is defined by a family of constraints ina Condition-Action style to describe which service is in-voked and which state of an artifact is changed under whatcondition.

Definition 1. (Artifact class). An artifact class abstracts agroup of business artifacts with their attributes and states.Artifact class C (or artifact if the context is clear) is a tuple(A; S; sinit ; Sf ) where,

�
A ¼ fa1; a2; …; axg; aiAAð1r irxÞ is a name-valuepaired attribute variable,
�
S ¼ fs1; s2; …; syg; siASð1r iryÞ is a state, � sinit =2 S denotes the pseudo initial state, � Sf S is a set of final states.

Table 1An example of business rules for our purchasing process.

r1: Buyer approves Quote q to confirm Purchase Order po for a selected supplierPre-condition instate(q, approving) 4 instate(po, on_hold) 4 defined(po, OrderID) 4 defined(po.SupplierID)Task approve(q, po)Post-condition instate(q, approved) 4 instate(po, confirmed) 4 defined(po.SubmitDate)

r2: Supplier accepts Purchase Order poPre-condition instate(po, confirmed) 4 defined(po, OrderID) 4 defined(po.SupplierID)Task acceptPO(po)Post-condition instate(po, accepted)

r3: Supplier creates Shipping Order so from Delivery Note dnPre-condition instate(dn, prepared) 4 defined(dn.ShipperID) 4 instate(so, init)Task createShipping (dn, so)Post-condition instate(dn, transferring) 4 instate(so, created) 4 defined(so.ShippingID)

r4: Supplier dispatches goods for Purchase Order po that to be shipped by Shipping Order so,and simultaneously issues Invoice iv to the Buyer

Pre-condition instate(po, ready_to_ship) 4 instate(dn, transferring) 4 instate(so, scheduled) 4 instate(iv, init)Task dispatchGoods(po, dn, so) issueInvoie(po, iv)Post-condition instate(po, delivering) 4 instate(dn, dispatched) 4 instate(so, in_transit) 4 instate(iv, issued)

4 defined(iv.InvoiceID) 4 defined(iv.OrderID)


Definition 2. (Artifact schema). An artifact schema,denoted as Z, contains a set of artifact classes, i.e., Z ¼fC1; C2; :::; Cxg where CiAZð1r irxÞ is an artifact class.

We also define some basic predicates over schema Z to beused for defining business rules as follows:

�
def inedðC; aÞ iff attribute aAC:A of artifact of class C isdefined;
�
instateðC; sÞ iff state sAC:S of artifact of class C is active.
Next, we define a business rule to express the controllogic of a business process.

Definition 3. (Business Rule). A business rule regulateswhich task can be invoked under what pre-condition. Theconditional effect is also defined to what post-conditionneeds to be satisfied after performing such task. Businessrule r is triple ðλ; β; vÞ where

�
λ and β are the pre-condition and the post-condition,respectively. Both conditions may contain the followingtwo types of propositions over schema Z: (1) stateproposition (the instate predicate) and (2) attributeproposition (the def ined predicate). To make the targetstate decidable, we do not allow the post-condition toinclude disjunction in state propositions.
�
vAV is a task or a composite task (i.e., more than oneatomic task); V ¼ fv1; v2; :::; vxg is a set of tasks ofwhich performs operations on some artifacts C1, C2,…,Cy where CjAZð1r jryÞ.
In order to maintain the existence of valid and explicitstate changes of an artifact in business rule r, we requirethat there exists a couple of instate predicates of thatartifact in both the pre-condition and the post-condition

of r, i.e., we have states sx; syAC:S such that instateðC; sxÞexists in r:λ and instateðC; syÞ exists in r:β. The state changerefers to either a transition from one state to another state,or to itself. Table 1 lists some business rules used in ourpurchasing process in Fig. 1.

We also classify business rules into two types based onthe existence of the instate predicate in the pre- and post-conditions of a business rule. The first type only changesthe state of one single artifact, while the second typesimultaneously changes the states of multiple artifacts, i.e., more than one pair of instate predicates (one pair for oneartifact) must appear in the pre- and post-conditions of asingle business rule. We call the second type synchroniza-tion (sync) rules as they are used for expressing synchroni-zation between artifacts.

Definition 4. (Sync rule). Business rule r is a sync rule forartifact Cx and artifact Cy if there exists instate ðCx ; siÞ andinstate ðCy ; smÞ in r. and instateðCx ; sjÞ and instateðCy ; snÞ inr:β, where si; sjACx:S and sm; snACy:S.

As mentioned above, a single sync rule can be used tosynchronize more than two artifacts.

Example 1. In Table 1, we can see that business rules r2 isused to express only the state change of the PO artifact(conf irmed-accepted), while business (sync) rule r1 is usedto simultaneously change states of local artifact Quote(approving-approvedÞ and shared artifact PO (on_hold-conf irmedÞ. Similarly, business (sync) rule r3 is used for thesynchronization of DN and SO; and sync rule r4 is used forsynchronizing four artifacts PO, DN, SO, and IV (where twotasks are defined in its action).

Next, we define ACP-i model to capture the completespecification of a particular inter-organizational businessprocess in the collaboration. As discussed in Section 2,shared artifacts should be used as coordination means ininter-organizational business processes. However, a sharedartifact cannot be completely modeled solely by a single

Picking List (PL)

Purchase Order (PO)confirmed

acquiring

accepted filled

canceled

ready to fillFilled order

checking In stock

Out of stock

delivering

ready to ship

Delivery Note (DN)

prepared

transferring

dispatched

closed billing

Shipping Order (SO)In transitcreated scheduled

Invoice (IV)cleared

issuedsent

unpaid

clearing

Fig. 3. A local ACP model for Supplier.


organization due to its sharing nature. Therefore, all parti-cipating organizations must agree on both the structure(data model) and the behavior (lifecycle) of the sharedartifacts in order to define the ACP-i model. It is worthnoting that in order to maintain the integrity of a sharedartifact together with all the involved tasks and business,we assume that the name of its state and attribute must beuniquely identified for the same mean across collaboratingorganizations.

Definition 5. (Organization Role). We denote L¼fl1; l2; …; lxg for a set of organization roles, whereliALð1ixÞ is a role of organizations that participate in aninter-organizational business process.

Definition 6. (ACP-i model). Given a set of organizationroles L involved in a collaboration, we define an ACP-imodel, denoted as Π̂¼ ðZ; V ; R; L; γÞ, for their inter-organizational business process where

�
Z is an artifact schema, V is a set of tasks, and R is a set ofbusiness rules,
�
L is a set of participating organization roles, � γ: Z [ V [ R -2L is a role mapping function from an
artifact class, a business rule, or a task onto an organiza-tion role(s) as follows:(c) γðCÞ returns a set of roles fl1; l2; …; lxg, where

liALð1r irxÞ is a role that can access (read/write)artifact CAZ and the owner of C must be amongroles γðCÞ. Note that a shared artifact C implies thatjγðCÞj41, and if C is a local artifact then jγðCÞj ¼ 1.

(c) γðvÞ returns role lAL of organization who owns taskvAV . Note that a task can perform read/writeoperations on either local artifact or shared artifactor both.

(c) γðrÞ returns role lAL of organization who ownsbusiness rule rAR.

In addition, we define two auxiliary functions overbusiness rules R and artifact schema Z in Π̂

�
function pre_sðr; CÞ returns a set of states {s1; s2; :::; sxgwhere for some business rule rAR, statesiAC:Sð1r irxÞ occurs in at least one instate predicateof the pre-condition of r; and,
�
function post_sðr; CÞ returns a set of states of artifact Cappearing in the post-condition of r.
Given an ACP-i model, we can derive a local ACP modelfor an organization's local process. Note that in a localprocess of an organization, the attributes and states of itsshared artifact can be obtained from the ACP-i model if theyare specified in the business rules of local process.

Definition 7. (local ACP model). Given Π̂¼ ðZ; V ; R; L; γÞbe an ACP-i model, a local ACP model of role lAL can bederived from Π̂, which is defined as Π̂

l ¼ ðZl; Vl; RlÞ where,

�
Zl ¼ fCAZ j lAγðCÞg is a local artifact schema, such thateach shared artifact in Zl contains a state s if and only if
instateðsÞ appears in the pre- or post-condition of abusiness rule in Rl, i.e.,

8CAfCAZl j lAγðCÞ 4 γðCÞ�� 41g; 8sAC:S; (rARl;

sApre_sðr; CÞ [ post_sðr; CÞ;

�
Vl ¼ fvAV j γðvÞ ¼ lg is a set of local tasks, � Rl ¼ frAZ j γðrÞ ¼ lg is a set of local business rules.
Example 2. Fig. 3 shows the Supplier's local ACP modelwhich is derived from the ACP-i model of the purchasingprocess illustrated in Fig. 1. We can see that the sharedartifacts PO and SO represent only the parts that belong tothe Supplier's local process, e.g., some processing steps ofPO (before the confirm state) and SO (after the in_transitstate) that belong to Buyer and Logistics, respectively, arenot captured in the Supplier’s local ACP model.

Next, we discuss the behavior properties of artifact-centric inter-organizational business processes. In general,it is important that the behavior of inter-organizationalbusiness processes must be sound in order to guarantee thereachability of desired goals of the collaboration andparticipating local processes [83,58,42].

3.3. Behavior properties of ACP model and its artifacts

We classify behavioral properties of artifacts in ACP-imodel into intra-behavior and inter-behavior. The intra-behavior of an artifact describes how an artifact changesits state throughout its lifecycle. Here, we adopt LabelTransition System (LTS) to capture the lifecycle of anindividual artifact. Second, the inter-behavior describeshow the lifecycle of one artifact depends on the counter-part of another artifact, and it can be represented assynchronization dependency between artifacts, i.e., a syncrule.

Here, we generalize ACP-i model Π̂ to ACP model,denoted as Π¼ ðZ;V ;RÞ, by disregarding the roles of orga-nizations and role mapping of Π̂.

Definition 8. (Lifecycle of artifact, )n). LetCi ¼ ðAi; siniti ; Si; S

fi Þbe an artifact class in ACP model Π.

Fig. 4. An example of lifecycle composition (taken from [96]).


A lifecycle of Ci, denoted as ℒCi, can be defined as a tuple

ðS; sinit ; )Þ where,

�
set of states S ¼ Si, initial state sinit ¼ siniti , � state transition relation ) DS Ri Gi S where � RiD Π:R is a set business rules that are used to induce
state transitions of artifact Ci such that,

8rAΠ:R; (sx; syACi:S; sxApre_sðr; CiÞ 4sy

Apost_sðr; CiÞ- rARi;

�
Gi (guards) is a union set of state preconditions of eachbusiness rule in Ri such that each precondition refer-ences to a state of other artifact in ∏, i.e.,Gi ¼ [jΠ:Zj
j ¼ 1 fCj:sj(rARi; (CjAΠ:Z; sApre_sðr; CjÞ4CjaCig ;

We also denote )n for a reflexive transitive closure of) . We write si)nsj if state sj can be reached from statesi by some sequence of business rules in Π:R.

We write transition ss)r½g�

st to mean that the state of theartifact will change from source state ss to target state st if
business rule r is fired and guard g (state pre-condition of r)holds. Note that in a clear context, we may use shorthandss ) st without its superscription, and may use termartifact for the mean of lifecycle of artifact.
Based on Definition 8, given ACP model∏, we can derivea lifecycle corresponding to an artifact in ∏ from a set ofcorresponding business rules that are used to trigger thestate transitions of the artifact. We can obtain the lifecycleof an entire process by composing all artifacts in the model.Here, we define ACP lifecycle for describing the behavioralaspect of an ACP model consisting of synchronized life-cycles of artifacts. We adapt a state machine compositiontechnique presented in [49] for generating the lifecycle ofACP. Similar technique for process model generation basedon (object) lifecycle composition is also present in [46].

Definition 9. (Lifecycle composition, composed lifecycle,�). Let ℒi ¼ ðSi; siniti ; )iÞ, and ℒj ¼ ðSj; sinitj ;)jÞ be twoartifact lifecycles in ACP model ∏. Lifecycle composition(i.e., synchronized product) of ℒi and ℒj is denoted asℒc ¼ℒi � ℒj ¼ ðSc; sinitc ;)cÞ where,

�
ScDℒi:S ℒj:S is a set of composed states, � sinitc ¼ ðℒi:sinit ;ℒj:sinitÞ is the initial state, � —)cD Sc Π:R Gc Sc is a transition relation where Gc is a
set of guards (state propositions).

Now, let g½sxℒi=stateðℒi; sxÞ� denote that state sxℒi

inguard g is substituted (denoted by symbol /) by true orf alse (of state predicate) depending on whether the local

state of ℒi is sx. We can formulate transition relation )c ofcomposed lifecycle ℒc , by using the following three infer-ence rules.

ðsxℒi; r; g1; s

yℒiÞA)i

ððsxℒi; sxℒj

Þ; r; gc; ðsyℒi; sxℒj

ÞÞA)c; gc ¼ g1½sxℒj=stateðℒj; sxÞ�

ð3:1Þ

ðsxℒj; r; g2; s

yℒjÞA)j

ððsxℒi; sxℒj

Þ; r; gc; ðsxℒi; syℒj

ÞÞA)c; gc ¼ g2½sxℒi=stateðℒi; sxÞ�

ð3:2Þ

ðsxℒi; r; g1; s

yℒiÞA)i4 ðsxℒj

; r; g2; syℒjÞA)j

ððsxℒi; sxℒj

Þ; r; gc; ðsyℒi; syℒj

ÞÞA)c; gc ¼ g1½sxℒj=stateðℒj; sxÞ� 4g2ðsxℒi

=stateðℒi; sxÞÞ

ð3:3ÞRule (3.1) and Rule (3.2) are applied when business rule r isfired on only individual lifecycle ℒi and ℒj, respectively.Rule (3.3) is applied when sync rule r is fired on bothlifecycles ℒi and ℒj. As the three inference rules applythe substitution of state conditions of two lifecycles in thecomposition, references to external lifecycle are notreplaced.

Example 3. Fig. 4 shows the composition between thelifecycle of artifact C1 and the lifecycle of artifact C2. Thelabel ri½g� attached to a transition means that the transitionis fired when both the attribute proposition in the pre-condition of business rule ri holds and all state propositions(of external lifecycles) in g hold. We denote the counterstate condition of C:sx by symbol � C:sx in the guard. Wecan also see that state conditions referencing to artifacts C3

and C4 remain in the composed lifecycle but in differentforms, which depend on the transition they belong.

Now, we can define the lifecycle of ACP by using lifecyclecomposition.

Definition 10. (ACP lifecycle). Given ACP model ∏, a (ACP)lifecycle of ∏, denoted as ℒΠ, can be generated by itera-tively performing lifecycle composition of every artifact in∏.

Note that lifecycle composition is associative and com-mutative, i.e., ℒi � ℒj � ℒk ¼ ℒi � ðℒj � ℒkÞ ¼ ðℒi �ℒjÞ � ℒk and ℒi � ℒj ¼ℒj � ℒi. Therefore, the finalresult of the composition of a set of lifecycles is notimpacted by their composition order.

Next, we define soundness property to describe a desiredand correct behavior of artifact lifecycle and the process.

Definition 11. (Safe, goal-reachable, and sound lifecycle).Given ACP model ∏ and lifecycle ℒ¼ ðS; sinit ; )Þ, we


define a set of lifecycle states S ¼ ℒ:S [ fsinitg and a set offinal states Sf S. Lifecycle ℒ is said to be:

�
safe iff there exists business rule rAΠ:R such that rinduces one and only one transition in ℒ, i.e.,Π:R; ðsx; r; g; syÞA
) ðsm; r; g; snÞ=2 )

�
goal-reachable iff, for every non-final state s of ℒ, s canbe reached from the initial state and s can reach one ofthe final states of ℒ, i.e.,
8sAS Sf ; (sf ASf ; sinit)n s s)n sf

�
sound iff ℒ is safe and goal-reachable.
Note that the goal-reachability property impliesdeadlock-free and connected lifecycle of an artifact (or aprocess).

Now consider the case of a shared artifact defined in alocal ACP model. It is always true that the local ACP modelis not goal-reachable as the lifecycle of shared artifact ispartially modeled and can be non-terminated. However,when integrating all the different parts of a shared artifactfrom each organization, the complete lifecycle must begoal-reachable.

In this article, we do not focus on the task-levelinformation, i.e., the specification of task is omitted. How-ever, the specification of task in artifact-centric processmodeling approach can be defined in the spirit of sematicweb-services specified in OWL-S proposal [2003]—that is ina form of Input, Output, Pre-condition, and Effect (IOPE).The pre-condition and conditional effect of a task shouldconform to the pre-condition and post-condition, respec-tively, of the business rule that specifies the task in itsaction. A detailed discussion of semantic web-servicestogether with the use of business rules (e.g., SBVR [69])for modeling artifact-centric business process can be foundin [5,19]. We also restrict our soundness discussion only onthe lifecycle behavior of artifacts while discussions andformal approaches to data verification of artifact-centricbusiness processes (some call artifact systems) can befound in several existing literatures, e.g., [54,31,29,25,21].

4. Behavior-consistent public view construction

In this section, we first introduce the definition of publicview and discuss the behavior consistency between acreated view and its base ACP-i model. Following that, wepresent an abstraction method to construct public viewspreserving the behavior consistency, and discuss howsynchronization dependency between artifacts is affectedby such abstraction. Finally, we propose a technique forconstructing the minimal public view for a given collabora-tion and formalize it into an algorithm of protecting theinformation (i.e., local processes) of every organization atthe highest level of privacy and autonomy during viewconstruction.

4.1. Public view construction and behavior consistency

Generally speaking, constructing a public view of aparticular collaboration should take into account all inter-action between participating organizations, particularlythe processing and exchanges of shared artifacts. As life-cycle is the main mechanism of an artifact for specifyingits dynamic behaviors, and the association/coordinationbetween artifacts is also based on the states inside life-cycles, we take it necessary to construct public views basedon lifecycles by blinding off the private part while preser-ving the global coordination. We propose our abstractiontechnique to help organizations reveal only their necessarysteps that are required to complete the collaboration.Shared artifacts are the main concern as they are used bymore than one organization. This requirement raises thequestion of how to decide which processing part of ashared artifact should be abstracted such that theabstracted part does not affect the coordination. Based onthis requirement, we observe that the part of a sharedartifact interacting with local artifact(s) and a processingstep of the shared artifact owned by a single organizationshould be abstracted. As discussed in Section 3.1, this isbecause such part is deemed as local processing of theshared artifact and it should not be revealed to otherparties (out of interest and privacy concern). As such, aconstructed public view should have all local artifacts ofevery organization hidden, and have all parts of sharedartifacts that interact with local artifacts abstracted.

Next, we discuss the ACP abstraction method for con-structing public views that derive from an underlying ACP-imodel. The method is discussed based on the following twopoints:

�
Abstraction of non-synchronized part of lifecycle. It is easyto understand that a part of the lifecycle (called lifecyclefragment or fragment) is converted into either a singlestate or a single transition during the lifecycle abstrac-tion. In Section 4.2, we will introduce a general techni-que for state/transition abstraction that can be applieddirectly to a lifecycle fragment of individual artifact.
�
Abstraction of synchronized part of lifecycle. Apart fromthe isolated abstraction, we also consider how multiplesynchronized fragments (via sync rules) of differentartifact lifecycles can be abstracted. We observe thatthe abstraction of one synchronized end calls for theabstraction of the corresponding end due to consistencypreservation. Both abstracted fragments of two life-cycles must still somehow be either correctly synchro-nized or none. If an entire lifecycle synchronizing with afragment of another lifecycle is to be abstracted, theformer is totally unsynchronized and should be consid-ered as an embedded fragment of the abstracted life-cycle of the latter. Section 4.3 discusses this issue inmore detail.
Based on an ACP-i model of inter-organizational pro-cesses, organizations can construct their public view byabstracting their shared artifacts and their local artifacts.

Purchase Order (PO)

deliveringclosed

confirmed

Shipping Order (SO)

In transitarrived

Invoice (IV)

unpaidcleared

billing

approving

canceled

filledsupplying

issued


We define a public view by applying the abstraction func-tion to map a complete ACP-i model to its public view.

Definition 12. (Public view and ACP abstraction). GivenACP-i model Π̂¼ ðZ; V ; R; L; γÞ, paΠ̂ ¼ ðZp; Vp; Rp; Lp; γpÞdenotes a public view of Π̂, where Zp; Vp; Rp; Lp; γp aresets of abstract artifacts, abstract services, abstract businessrules, organization roles, and role mapping function of thepublic view, respectively. ACP abstraction function is definedas pa: Zp [ Vp [ Rp [ Lp [ γp- Z [ V [ R [ L [ γwhich maps paΠ̂ to Π̂. pa is a total mapping function withthe following conditions:

Fig. 5. An example of an agreed public view based on the process in
� Fig. 1.
paΠ̂ and Π̂ have identical sets of organization roles,
� paΠ̂ contains every abstract shared artifact, i.e.,
8CAZ; (CiAZp; γðCÞ�� 41-ðpaðCiÞ 4 γpðCiÞ

�� 41Þ

�
each abstract shared artifact in paΠ̂ has an identical roleset to its corresponding concrete artifact in Π̂, i.e.,8CiAZp; (CAZ; paðCiÞ ¼ C - 8 lAγpðCiÞ; lAγðCÞ
�
every rule and task defined in Π̂ must be projected tosome abstract rule and abstract task, respectively, definedin paΠ̂, i.e.,8riAR; (rARp; paðrÞ ¼ ri 4 8viAV ; (vAVp; paðvÞ ¼ vi
�
if an entire local artifact in Π̂ is hidden in paΠ̂ then thefollowing holds:instate
�
role mapping γp for abstract artifacts, tasks, and businessrules holds8CiAZp; γpðCiÞDL4 8viAVp; γpðviÞAL4 8riARp; γpðriÞAL
Example 4. Fig. 5 illustrates an example of an agreedpublic view that can be constructed from the purchasingprocess introduced in Fig. 1. We can see that the publicview is achieved by abstracting three shared artifacts PO,SO, and IV and removing all local artifacts of each organiza-tion. It is possible that, due to aiming to achieve higherlevel of abstraction, abstract states may be introduced inthe public view, e.g., approving, supplying, unpaid areabstract states in Fig. 5.

Note the labeling of abstract state is done manually afterlifecycle abstraction. Participating organizations shouldagree on choosing a reasonable name of an abstract statein their public view. Once a public view is constructedbased on its underlying ACP-i model, it is very important toensure the validity of the public view. As already men-tioned, in this article we only focus on the behaviorperspective of ACP models, and thus we define the validityof public views in term of the behavior consistencybetween a view and its base model. In our recent work[96], we have proposed a behavior consistency checkingapproach called B-consistency to check whether a specia-lized process derived from the base process is consistentlyobservable. Here, we use the B-consistency notion to checkwhether the behavior of a public view is consistent with itsunderlying model.

Let ℒy be the lifecycle of a public view constructed byabstracting its base ACP-i lifecycle ℒx. We are to checkwhether abstract lifecycle ℒy has consistent behaviors withits base lifecycle ℒx. Intuitively, if each firing sequence oftransitions in ℒx, disregarding states and transitions in anabstracted L-fragment, is observable as the same sequenceas ofℒy,ℒy is said to be behavior consistentwithℒx. Our B-consistency relation between two lifecycles is defined withthe help of bi-simulation equivalence in process algebra [9].By abstracting a lifecycle fragment into a silent (τ) action,we can apply weak bi-simulation between a lifecycle andits abstracted one.

Definition 13. (B-consistent, C). Let ℒx ¼ ðSx; sinitx ;)xÞand r:be two lifecycles and Sx\y ¼ Sx \ Sy be a set of statesthat commonly exist in ℒx and ℒy. ℒy and ℒx are said tobe B-consistent (denoted as ℒyCℒx) iff,

�
8si; sjASx\y; (ðsi; r; g; sjÞA)x; 8skASy Sx\y; si)nysk-sk)n
ysj
� 8si; sjASx\y; ∄ðsi; r; g; sjÞA)x; 8skASy Sx\y;:ðsi)n
ysk - sk)nysjÞ

Note that as definition of B-consistency is generalized, itcan be used for checking any type of a lifecycle (i.e., ACPlifecycles, artifact lifecycles, or composite lifecycles).

Example 5. The lifecycle in Fig. 6(a) is not B-consistentwith the lifecycle in Figure (b), i.e., . This is because,in some firing sequences of transitions in the lifecycle inFig. 6(b), state a can reach state c(through state x2) withoutpassing state b; and, state a can reach itself via state x4without passing state b. In contrast, we can see thatℒaCℒc andℒaCℒd in Fig. 6(c) and Fig. 6(d), respectively.

4.2. Abstraction of non-synchronized lifecycle

Next, we introduce notion of lifecycle fragment (calledL-fragment) for capturing the part of an artifact lifecycle tobe abstracted in the public view. Once an L-fragment isidentified in a lifecycle, we apply the abstraction functionto map L-fragment to a specified abstract state or abstracttransition(s) in an abstract ACP model (i.e., a public view).

Definition 14. (Lifecycle fragment or L-fragment,Π̂¼ðZ; V ; R; L; γÞ, f ind_Lf ). Given ACP model ∏, L-fragmentγðCÞ of lifecycle ℒx is a nonempty connected sub-lifecycle ofℒx. It can be defined as ℓℒx ¼ ðS;); )in; )outÞ where,

a b

c

d a b

c

dx

xx

a b

c

d

x x

x

x x

x

a

c

dxx

x

l1

l2l3

l4

Fig. 6. Examples of abstract lifecycle (a), its base lifecycles (b), (c) and (d) (taken from [96]).


�
SDℒx:S fsinitg [ Sf is a non-empty set of states of ℓℒx ,where Sf is a set of final states of ℒx,
�
) DS RℒxGℒxSDℒx: ) is a set of transitions of ℓℒx ,where Rℒx and Gℒx are subsets of business rules andguards, respectively, defined in ℒx,
�
)in ¼ℒx: ) \ððℒx:S SÞRℒx GℒxSÞÞ is a set of entry tran-sitions into ℓℒx ,
�
)out ¼ℒx: ) \ðS RℒxGℒx ðℒx:S SÞÞ is a set of exit transi-tions from ℓℒx .
We denote ℓ!ℒc (or ℒcgℓ) if ℓ is an L-fragment oflifecycle ℒc of artifact C. In addition, we also definefunction f ind_Lf ðC; SÞ to return L-fragment ℓ if ℓ consistsof a set of states S of artifact C such that ℓ:S¼ S and ℓ!ℒc;otherwise, return null if such an L-fragment cannot befound.

Notice that, given a valid input set of states of an artifact,there is only one case that f ind_Lf returns null – that iswhen the set contains only an init state and final state(s) ofthat artifact.

To ensure L-fragment ℓℒx is correctly formed by aconnected sub-lifecycle of its entire lifecycleℒx, we confinethat for each state s in ℓℒx :S, there exists a sequence oftransitions from an entry transition in ) in to s and from sto an exit transition in ) out. soundness property can alsobe applied to L-fragment providing that any L-fragment is asub-lifecycle of its entire lifecycle.

Note that based on the condition of entry and exittransitions of L-fragment, an entry/exit transition must befired from/to a state inside the L-fragment. However, thereis no restriction on the number of entry states and exitstates of L-fragment.

Next, we identify a specific type of L-fragment based onits atomicity property which is restricted by means ofsingle-entry-single-exit (SESE) fragment of lifecycle. How-ever, we adapt it to our L-fragment definition by allowingthe structure of multiple-entry transitions and multiple-exit transitions instead of single entry and single exit states.Here, we define such L-fragment as Atomic L-fragment.

Definition 15. (AL-fragment, NAL-fragment). Given L-fragment ℓℒx ¼ ðS;); )in; )outÞ of lifecycle ℒx, ℓℒx iscalled an AL-fragment iff, all entry transitions in ) in havethe same source state and all exit transitions in ) out havethe same target state. Otherwise, ℓℒx is classified as NAL-fragment (non-atomic L-fragment).

Example 6. Fig. 7 shows examples of different types of L-fragments. In Fig. 7(a), L-fragments ℓ1 and ℓ2 have single

entry state s1 and single exit state s4; therefore, both ℓ1 andℓ2 are AL-fragments. We can see that L-fragments ℓ3, ℓ4,and ℓ5 in Fig. 7(b) are NAL-fragments as ℓ3 has multipleexit states, and both ℓ4 and ℓ5 have multiple exit states andmultiple entry states.

Based on above notion of L-fragment, given a completeACP-i model we can use these two abstraction mechanismstogether with L-fragments to construct an abstract ACP-imodel which can be used to represent the public view of itsbase model. Next, we discuss the two output types of anabstraction operation: abstract transition and abstract state.

In most cases, an abstraction operation should yield anabstract transition as the transition represents an atomicand uninterruptable step from one state to another state inthe lifecycle. However, in some cases, we may see that anabstract state is yielded instead. For instance, consider thePO artifact in the purchasing process shown in Fig. 1 andcompare it with its public view in Fig. 5, we can see that theapproving state in the public view is an abstract state of alifecycle fragment consisting of states created and on_hold.There are two possible underlying reasons supporting thiscase. First, an abstract state is specified in the design of anorganization or in the mutual agreement of the collabora-tion. Second, a fragment cannot be abstracted into a singleabstract transition—this is because the fragment is notatomic (i.e., NAL-fragment). The result of multiple abstracttransitions for L-fragment makes it difficult to decide ondrawing a projection from a part of the fragment to anabstract transition. Therefore, a possible solution is to usean abstract state to remove the ambiguity of what isabstracted in such transitions. Here, we show differentcases of L-fragment abstraction in Fig. 8.

Example 7. Fig. 8(a) and Fig. 8 (b) show the abstractionsfor abstract transition of L-fragments in artifact A1 andartifact A2, respectively, while Fig. 8(c) shows a case ofabstraction for abstract state of artifact A2. We can see thatboth L-fragments in A1 and A2 are AL-fragments. However,consider the L-fragment of artifact A3 in Fig. 8(d) which isan NAL-fragment (due to multiple exit states s4 and s5), itsabstraction does not result in a single abstract transition. Asalready discussed, multiple abstract transitions are ambig-uous. Therefore, to tackle this issue, the abstraction needsto result in an abstract state instead, which is shown inFig. 8(e). Note that we discuss this abstract state in detail inDefinition 17 with an example in Fig. 9.

Next, we define lifecycle abstraction mapping function tomap an abstract element in abstract lifecycle onto a state ortransition in the base lifecycle, which is shown in Definition

C1s1

s4

s2 s3

C2s1

s4

s2 s3

C4s1

s4

s2

s6

s5l1 l2 l4

C3s1

s4 s5

s3

l3

C5s1

s4

s2 s3

s6

s5

l5s2 s3

Fig. 7. Examples of L-fragments and NAL-fragments.

A’2s1

s4

A2s1

s4

s2 s3

A’’2s1

s4

A2s1

s4

s2 s3 sx

A’’3s1

s4

A3s1

s4

s2 s3 sx

s5 s5

A’1s1

s4

A1s1

s4

s2 s3

A’3s1

s4

A3

s5 s5

s3

s1

s4

s2

Fig. 8. Abstractions for abstract transitions and abstract states.

A1 A’1s1

s4

sx

s6

s5

A1

s0

s7

A1

s0

s7

syOR

s1

s2 s3

s5

s0

s7

s4 s6

A

B

Fig. 9. An abstraction on an expanded NAL-fragment.


16. Then in Definition 17, we define two abstraction func-tions that are used to construct an abstract lifecycle. Thesefunctions are based on the preferred output of the abstrac-tion—that is abstract state or abstract transition.

Definition 16. (Lifecycle abstraction (la)). Let artifact life-cycle le ℒ0

Cx¼ ðS0; sinit ; )0Þ in an abstract ACP model ∏0be

an abstract lifecycle of artifact lifecycle ℒCx ¼ ðS0; sinit ; )Þin a base ACP model ∏. We define lifecycle abstractionmapping function laΠ0-Π

ℒ0Cx-ℒCx

: S0 [ )0 -S[ ), wherelaΠ0-Π

ℒ0Cx-ℒCx

is a total function that maps an abstract transition

in )0 and an abstract state in S0 onto a state and atransition in ℒCx . We write la without its superscriptionor its subscription if a context is clear.

Definition 17. (Abstraction functions for abstract transi-tion (la_tran) and for abstract state (la_state)). Let L-fragment ℓCx of artifact lifecycle ℒCx ¼ ðS; sinit ; )Þ to beabstracted. We can abstract ℓCx into a set of abstracttransitions and an abstract state (if applicable) in abstractlifecycle ℒ0

Cx¼ ðS0; sinit ; )0Þ via the two following abstrac-

tion construction functions:

�
function la_tranðℒCx ; ℓCx Þ returns ℒ0
Cxby abstracting ℓCx

into a single abstract transition,
� function la_stateðℒCx ;ℓ
Cx ; s0Þ returns ℒ0Cx

by abstractingℓCx into single abstract state s0 and correspondingabstract transitions related to s0.

Functions la_tran and la_state can be expressed bylifecycle abstraction mapping laℒ0

Cx-ℒCx

as follows.

(a)
Let ℓCx be an AL-fragment with entry state si and exitstate sj. ℓCx can be abstracted into abstract transition


si)0Sj by applying function la_tran. We haveℒ0

Cx¼ la_tranðℒCx ; ℓ

Cx Þ such that,� la sið Þ ¼ si 4 la sj

� �¼ sj,� 8sAℓCx :S; laðsi )0 sjÞ ¼ s,� 8)lAℓCx : ); laðsi )0 sjÞ ¼)l.

(b)

Let ℓCx be an AL-fragment with entry state si and exitstate sj. ℓCx can be abstracted into abstract state s0AS0

with a set of abstract transitions ) 0z by applying

function la_state. We have ℒ0Cx

¼ la_stateðℒCx ; ℓCx ; s0Þ

such that,� 8sAℓCx :S; laðs0Þ ¼ s,� 8)lAℓCx : ) ðℓCx :)in [ ℓCx :)outÞ; laðs0Þ ¼)l,� 8)nAℓCx :)in; laðsi )0 s0Þ ¼)n,� 8)oAℓCx :)out ; laðs0 )0 sjÞ ¼)o.

(c)

Let ℓCx be an NAL-fragment with a set of entry state Sen

and exit state Sex. ℓCx can be abstracted into abstractstate s0AS0 with a set of abstract transitions ) 0

z byapplying function la_state. We have ℒ0

Cx¼

la_stateðℒCx ; ℓCx ; s0Þ such that,

� 8sAℓCx :S; laðs0Þ ¼ s,� 8)lAℓCx : ) ðℓCx :)in [ ℓCx :)outÞ; laðs0Þ ¼)l,� 8smAℓCx :Sen; (snAℓCx :S; sm ) s0 ) 0

z-laðsm ) s0Þ ¼ sm ) sn,� 8soAℓCx :Sex; (spAℓCx :S; s0 ) so ) 0

z-laðs0 ) soÞ ¼ sp ) so.

It is worth mentioning that an abstract business rule,which fires an abstract transition, contains no definedpredicates. If a business rule in a base lifecycle is abstractedin an abstract lifecycle, then any defined predicate in therule should be removed from the abstracted rule to avoidover restriction on artifact attributes that may prohibitfiring the abstract transition.

Example 8. Fig. 8(a) and Fig. 8(b) show the abstracttransitions resulted from applying function la_tran to AL-fragments, while Fig. 8(c) shows the abstract state gener-ated from function la_tran on an AL-fragment. On the otherhand, Fig. 8 (e) shows the abstract state and related abstracttransitions as an output of abstraction by applying functionla_state on a NAL-fragment.

Next, we define B-consistent abstraction based on thelifecycle abstraction mapping, and then we show, inTheorem 1, that applying either function la_tran or func-tion la_state to generate an abstract lifecycle from its baselifecycle always preserves B-consistency.

Definition 18. (B-consistent abstraction, C la). Let artifactlifecycleℒ0

Cx¼ ðS0; sinit ; )0Þ in abstract ACP model∏0 be an

abstract lifecycle of artifact lifecycle ℒCx ¼ ðS; sinit ; )Þ inACP model ∏ based on lifecycle abstraction mapping func-tion laΠ0-Π

ℒ0Cx

-ℒCx. If ℒ0

CxCℒCx , then we say that ℒ0

Cxis a B-

consistent abstraction of ℒCx , denoted as ℒ0CxC laℒCx .

Theorem 1. (Non-synchronized lifecycle b-consistentabstraction). Let lifecycle ℒ0

Cxbe an abstract lifecycle of ℒCx

by abstracting L-fragment ℓCx where ℓCx !ℒCx . Givenℒ0

Cx¼ la_tranðℒCx ;ℓ

Cx Þ, we have ℒ0CxC laℒCx . Correspond-

ingly, ℒ0CxC laℒCx holds for ℒ

0Cx

¼ la_stateðℒCx ;ℓCx ; s0Þ where

s0Aℒ0Cx:S.

We can prove Theorem 1 by applying B-consistencychecking to the comparison between input lifecycle andoutput (abstract) lifecycle based on the three use cases of

those two abstraction functions. Consider the first twocases (a) and (b) in Definition 17. We know that abstractingan AL-fragment always produces a single abstract transitionor abstract state (with single entry transition and single exittransition) that still preserves the atomicity of the fragmentto be abstracted. Thus, the output lifecycle is consistentwith its base. For the third case (c) in Definition 17, wegenerate a single abstract state with the restriction on itsabstract entry transitions and exit transitions. Similar tocase (b), the abstract state represents the internal behaviorof the abstracted fragment and it is atomic.

Please note that, in Definition 17 (c), we use abstractstates to allow the abstraction of NAL-fragments; however,this abstraction has to meet certain conditions for theabstract entry and exit transitions of the abstract state.For instance, consider the abstraction in Fig. 8(e). Entrytransition s1) sx abstracts two original entry transitions ofits fragment (s1) s2 and s1) s3) and exit transition sx) s4abstracts two original exit transitions (s2) s4 and s3) s4).Nevertheless, we can see that exit transition sx) s5 shouldabstract only for one exit transition s3) s5. Alternatively, ifwe do not want to have an abstract state as the result ofabstraction of NAL-fragment to decide the appropriatetrigger conditions for transitions due to the above additionmechanism, then we may expand the NAL-fragment till itsatisfies the condition of AL-fragment (if possible). Thisrequires the modeler to find a possible AL-fragment fromthe expanded-boundary of NAL-fragment. If such anexpanded fragment cannot be found, the modeler maydecide to implement an abstract state for the abstraction.Take two abstractions (A) and (B) in Fig. 9, for examples. Onone hand, abstraction (A) on NAL-fragment consisting ofstates s2 and s3 can result in abstract state sx and fourabstract transitions. On the other hand, with alternativeabstraction (B), the boundary of the fragment keepsexpanding till it satisfies the condition of AL-fragment.We have the expanded fragment that covers all states andtransitions between states s0 and s7. Then, we can abstractthe fragment into either abstraction transition s0) s7 orabstract state sy.

Next, we present an algorithm to find the minimal AL-fragment of an input L-fragment. The algorithm gets aninput fragment and expands its boundary until theexpanded fragment satisfies the condition of AL-fragment(in Definition 15). The output AL-fragment is minimal as inan iteration of the algorithm, it finds the nearest source andtarget states and adds them into the fragment (Lines 8 and10). If the input is already a qualified AL-fragment then thefragment itself is returned (Line 11). Otherwise, if thefunction cannot find a valid AL-fragment, then returns null.

Algorithm 1. (function find_minAL). Finding a minimalAL-fragment from an L-fragment

Input: L-fragment ℓCx of artifact Cx in ACP-i model Π̂.Output: AL-fragment ℓ0Cx if found; otherwise null is returned.1. ℒyℓ0Cx ¼ ℓCx ;2. repeat3. Sen¼a set of entry states of ℓ0Cx ;4. Sex¼a set of exit states of ℓ0Cx ;5. if (jSen j 41 or jSexj 41)6. then7. if jSen j 41 then


8. ℓ0Cx includes all states in Sen and their related exit transitions;9. if jSexj 41 then

10. ℓ0Cx includes all states in Sex and their related entrytransitions;

11. else if (jSen j ¼ 1 and jSex j ¼ 1) then return ℓ0Cx ;12. until Sen ¼∅ and Sex ¼∅13. return null;

Based on Theorem 1 along with the help of f ind_minAL
function for NAL-fragment abstraction, we can construct aconsistent public view of an individual artifact lifecycle byabstracting its non-synchronized part of the lifecycle. Next,we discuss how a fragment of a lifecycle that synchronizeswith a fragment of another lifecycle can be consistentlyabstracted.
4.3. Abstraction of synchronized L-fragments

In this section, we discuss how the synchronization (viasync rules) between two lifecycles can be abstracted indetail. Technically, we need to answer the followingquestions.

�
What is the result of abstracting an L-fragment (or awhole) of one lifecycle synchronized with an L-fragmentof another lifecycle?
�
What is the condition that makes an abstract synchro-nization consistent with its original synchronization?
Here, we use the same L-fragment abstraction methodto abstract the synchronized parts with the considerationof synchronization structure and behavior. However, inorder to capture synchronization dependencies betweenlifecycles, we need to extend the definition of L-fragmentfor a synchronized region (called S-region) which repre-sents synchronized L-fragments between lifecycles (calledSL-fragments). With a target fragment of an artifact and thesync rules used within the fragment, we can identify acounter-synchronized part(s) of the other artifact(s) that itinteracts with.

Definition 19. (Sync rule for synchronized L-fragments, φ).Given ACP model ∏, a set of sync rules that is used withintwo synchronized L-fragments ℓx and ℓy can be defined asfollow:

φðℓx; ℓyÞ ¼ frAΠ:Rj (ðsi; r; g; sjÞA ℓx:) 4(ðsm; r; g; snÞAℓy: )g

It is noted that a sync rule is transitive, i.e.,(rAφðℓx;ℓyÞ \ φðℓy;ℓzÞrAφðℓx;ℓzÞ.

Definition 20. (SL-fragment and S-region). Given ACPmodel ∏, we denote ω¼ ðΓ;Rsync) for a synchronizationregion (S-region) where,

�
a set of synchronized L-fragments Γ ¼ fℓC1 ; ℓC2 ; …;
ℓCx g, ℓCi AΓð1r irxÞ is a synchronized L-fragment,called as SL-fragment, of artifact lifecycle ℒCi

ðCiAΠ:ZÞ,
� !RsyncDΠ:R is a set of sync rules that is used to
synchronize transitions between L-fragments in Γ such

that,8rAΠ:R; (ℓCi ;ℓCj AΓ; 8rAφðℓCi ;ℓCj Þ; rARsync

Example 9. In Fig. 10(a), we have S-region ωa with SL-fragments l1 of artifact A1 synchronized with SL-fragment l2of artifact A2 via sync rules r1 and r2. In Fig. 10 (b), S-regionωb has two SL-fragments l3 and l4 with sync rulesRsync ¼ fr1; r2; r3g. Notice that sync rule r4 is excluded fromωb as it is not used for the synchronization between l3 andl4.

Next, we study the atomicity property of S-region bydetermining the composability of contained SL-fragmentsand the boundness of their synchronization behavior.

4.3.1. Atomicity of S-regionHere, we propose a fragmental composition technique

to check the atomicity of S-region. First we see that thecomposition between two synchronized L-fragmentsresults in a composite L-fragment. Then we can applyatomicity checking to the composite L-fragment. As such,we need to observe the conditions for SL-fragments thatmake the composite L-fragment atomic. Now, we definecomposite S-region based on lifecycle composition (inDefinition 9).

Definition 21. (Composite S-region). Given ACP model ∏,let S-region ω¼ ðfℓCx ;ℓCy g;Rsync) of L-fragment ℓCx of artifactCxAΠ:Z and L-fragment ℓCy of artifact CyAΠ:Z where ℓCx

and ℓCy are synchronized via business rules RsyncRsync. Thecomposite S-region of ω, �ω¼ ℓCx � ℓCy , is tuple ðS;);

)in;)outÞ where each set element in �ω has the samedefinition corresponding to the element of L-fragment, i.e.,in�ω can be considered as an L-fragment (or SL-fragmentif the composite fragment still has some synchronization toother fragment of different artifact).

It is noted that a composite S-region is considered as asub-lifecycle of the composition between two entire life-cycles. To have a (minimal and sufficient) complete view ofthe composition we draw a dashed arrow for a transitionbetween a composite state excluded from the S-region anda composite state that is an entry or exit state of the S-region, as exemplified in Fig. 11. Fig. 11 (a) and (b) show theresults of SL-fragment composition, composite S-regions�ωa and �ωb, for S-regions ωa and ωb in Fig. 10 (a) andin Fig. 10 (b), respectively.

Example 10. In Fig. 11, �ωa has composite state (s2; s5),and (s4; s7) as its entry state and exit state, respectively.Likewise, �ωb has two entry states (s2; s5) and (s9; s6), andtwo exit states (s4; s7) and (s4; s8). Note that compositestate (s1; s5) is out of scope of ωa and ωb, so it is excludedfrom �ωa and �ωb, respectively.

Next, we validate atomicity property of S-region bychecking whether SL-fragments of the S-region can becomposed into an atomic composite S-region. We considerthe property of AL-fragment to define atomic S-region (AS-region), i.e., AS-region must have all entry transition firedfrom the same (composite) source state and all exit transi-tions fired to the same (composite) target state.

A2A1

s1

s2 s4

s3 s5 s7

r1

s6

r2

l1 A2A1s1

s2 s4

s3 s5 s7

r1

s6

r2

s9

s8

l2

l3

l4

a b

r4

r3

ω ω

Fig. 10. An example of S-regions and SL-fragments.

Fig. 11. Composite S-regions of SL-fragments based on Fig. 10.

A1

s1

A3A2

s2

s1

s2

s3 s5

s4s6

l1

s2

s1

l2l3l5


Definition 22. (AS-region and ASL-fragment). Given ACPmodel ∏, let S-region ω¼ ðΓ;Rsync) and ZΓDΠ:Z be a set ofartifacts where of which has its L-fragment defined in Γ.The composition of all SL-fragments in Γ satisfies theproperty of AL-fragment iff, for every ℓCi AΓ,

A4

s3 s4s1 s2 s3 s3
� ℓCi is an AL-fragment, l4 �
Fig. 12. An S-region with sub SL-fragments.

8ℓCx ;ℓCy AΓ; 8rAφðℒCx ;ℒCy Þ; (ssAℓCi :S; ss)rsAℒCi:

) -ss)rsAℓCi : ) 4rARsync

�
8ℓCx ;ℓCy AΓ; 8rAφðℒCx ;ℒCy Þ; (stAℓCi :S; s)rstAℒCi:
) -s)r stAℓCi : ) 4rARsync

�
8ℒCjðCjAΠ:Z ZΓÞ;φðℓCi ;ℒCj
Þ ¼∅.

By holding above conditions, ω can be considered as anAS-region. We also call each L-fragment in Γ as ASL-fragment of ω.

Note that the conditions in Definition 22 are used torestrict two SL-fragments (to be composed for S-region) toinclude every transition and corresponding sync rule thatare used for only the synchronization between L-fragmentsin Γ. If an S-region contains more than two SL-fragments,then, like lifecycle composition for ACP model, we cancheck the AS-region by performing iterative compositionfor each SL-fragment in that S-region. It is also worthmentioning that the composition of SL-fragments for AS-region holds as same characteristics as for the lifecyclecomposition – that is commutative and associative, i.e.,ℓCx � ℓCy ¼ ℓCy � ℓCx and ℓCx � ℓCy � ℓCz ¼ ℓCx � ðℓCy �ℓCz Þ ¼ ðℓCx � ℓCy Þ � ℓCz .

Example 11. In Fig. 10 (a), ωa is an AS-region as bothL-fragments l1 and l2 are AL-fragments with all related syncrules (r1 and r2) residing within them. As such, theresulting fragment from the composition between l1 andl2 is then atomic, as shown in Fig. 11 (a). In contrast, inFig. 10 (b), we can see that L-fragment l4 cannot satisfy theproperty of AL-fragment, and L-fragment l3 does notinclude transition s5)r4s6 where sync rule r4 exits in entrytransition s5)r4 s6 of l4. Therefore, ωb cannot be consideredas AS-region.

Example 12. Now, we illustrate the case that an S-regioncontains more than two SL-fragments where one of whichsynchronized on the (nested) sub-fragment of SL-fragment,as shown in Fig. 12. Assume S-region ω1 for SL-fragments{l1; l2; l3}, ω1 cannot be considered as an AS-region as l1 hassome sync rules that are used for the synchronizationbetween its sub L-fragment l5 and L-fragment l4 of thelifecycle of artifact A4. Therefore, we need to include l1 intothe S-region in order to satisfy the property of AS-region.

In the next section, we discuss about how AS-region canbe used for the abstraction of synchronization.


4.3.2. SL-fragment abstractionHere, we define the abstraction relation of the synchro-

nization between two abstract artifacts in the abstract ACPmodel and the synchronization between two artifacts in itsbase ACP model.

Definition 23. (Synchronization (Sync) abstraction). Letartifact lifecycles ℒ0

Cxand ℒ0

Cyin ACP model ∏0 abstract

artifact lifecycles ℒ0Cx

and ℒ0Cy

in base ACP model ∏ withlifecycle abstraction mappings laℒ0

Cx-ℒCx

and laℒ0Cy-ℒCy

,respectively. We can define sync abstraction mapping func-tion saΠ0- Π

ðℒ0Cx;ℒ0

CyÞðℒCx ;ℒCy Þ :φðℒ

0Cx;ℒ0

CyÞφðℒCx ;ℒCy Þ that is used

to project the abstract sync rule for ℒ0Cx

and ℒ0Cy

onto itsbase sync rule for ℒ0

Cxand ℒ0

Cy.

Note that saΠ0 - Πðℒ0

Cx;ℒ0

CyÞ ðℒCx ;ℒCy Þ is a total function and we

may write sa without its superscription and subscription ina clear context.

Now, we want to perform an abstraction on an L-fragment that synchronizes with other L-fragment(s). Simi-lar to abstraction function for non-synchronized lifecycle,we define sync abstraction function for abstracting AS-regionthat contains synchronized L-fragments.

Definition 24. (Sync abstraction function (sa_f)). GivenACP model ∏, let AS-region ω¼ ðΓ;RsyncÞ to be abstracted inabstract ACP model ∏0, where Γ ¼ fℓC1 ; ℓC2 ; …; ℓCx g andℓCi ð1r irxÞAΓ is an L-fragment of lifecycle ℒCi

in ∏. Wedefine sync abstraction function sa_f ðΠ;ωÞ to return ∏0

with a set of abstract artifact lifecycles L¼ fℒ0C1;ℒ0

C2; ::;ℒ0

Cxg

and an abstract sync rule r0, where ℒ0Cið1r irxÞAL is a

lifecycle of artifact CiAΠ 0:Z such that,

�
for every ℓCi AΓ, ℓCi is abstracted into abstract transi-tions in ℒ0
Ci, i.e.,

ℒ0Ci¼ la_tranðℒCi

; ℓCi Þ;

�
for every sync rule rAΠ:R that is used to synchronizebetween any two L-fragments in Γ, r is abstracted into
A2A1

s1

s2 s4

s3 s5 s7

r1

s6

r2

l1

l2

a

A2A1

s2 s4

s3 s5 s

r1

s6

r2

s9

s

l3r4

r3

s1

ω

Fig. 13. Examples o

r0AΠ 0:R, i.e.,

8ℓCx ;ℓCy AΓ; 8rAφðℓCx ; ℓCy Þ; ( !r0Aφðℒ0Cx;ℒ0

CyÞ;

saðℒ0Cx;ℒ0

CyÞ ðℒCx ;ℒCy Þðr0Þ ¼ r

Abstract sync rule r0 that is used to synchronize allabstract transitions together can be defined as follow. Forevery L-fragment ℓCi ¼ ðS; );)in;)outÞAΓ, we have,

(ss; stAℒCi:S S;ðss)in)n )outstÞ

� ssApre_sðr0;CiÞ4stApost_sðr0;CiÞ

Example 13. In Fig. 13 (a), we can see that AS-region ωa

contains two fragments l1 and l2 with sync rules r1 and r2.When applying sa_f ðΠ;ωa), we have abstract lifecycle ofℒA1 and abstract lifecycle of ℒA2 with abstract sync rule r0.In addition, Fig. 13 (b) shows a case of sync abstraction forAS-region ωb which contains multiple entry transitionsand multiple exit transitions ASL-fragments (both ASL-fragments l3 and l4).

In the above example, we demonstrate the sync abstrac-tion of two synchronized fragments. However, it is possiblethat an AS-region contains more than two ASL-fragments.For wider understanding of sync abstraction, we illustrate async abstraction of more than two SL-fragments in Fig. 14(with artifact A3 extended to the example in Fig. 13 (b)).

Example 14. In Fig. 14, we can see that AS-region ωb

contains synchronized fragments l3 and l4 of artifact A1 andA2, respectively, and l5 of artifact l4. As all three fragmentscan be considered as ASL-fragments in ωb, we can validlyapply function sa_f ðΠ;ωb) and the abstract lifecycles ofartifacts fA0

1;A02;A

03g with abstract sync rules fr0; r″g are

returned.

A’2A’1

s1

s2 s4

s5

s7

r'

7

8

l4

b A’2A’1

s2 s4

s5

s8

r's1

ω

f sync abstraction.

A2A1A3

s10

s11 s2 s4

s3 s5 s7

r1

s6

r2

s9

s8

l3 l4

b

r4s1

r8

r3r7

s13

s14

r6

A’2A’1

s2 s4

s5

s8

r's1

s12

r5l5

A’3

s10

s11 s14

r'’

r8

ω

Fig. 14. An example of an abstraction of two or more ASL-fragments.

A1

s1

A3A2

A4

A’1s1 s6

A’3

s1

s3 s4

s2

s1

s3

s2

s4s1 s2 s3l4

A’4s1 s3

r'z

s3 s5

s4s6

l1

s2

s3

s1

l2l3

A’2

s1

s3

r'x r'yl5

Fig. 15. An example of an abstraction on nested sub-SL-fragments (cf. Fig. 12).


Next, we discuss the case of an AS-region containing SL-fragments with a nested (sub) SL-fragment that synchro-nizes with other lifecycle. Intuitively, the sub SL-fragmentand its synchronized lifecycle should be also taken intoaccount when its super fragment has to be abstracted.Therefore, we need to induce the abstraction to its subfragment together with its counterpart if they both cansatisfy the property of AS-region (which is considered as asub AS-region of the whole). In other words, we can saythat the entire AS-region should contain such counterpartin order to have a valid abstraction. We show an example ofAS-region consisting of sub SL-fragment in Fig. 15.

Example 15. In Fig. 14, we can see that L-fragment l4 is asynchronized fragment of L-fragment l5 which is nestedunder L-fragment l1. The abstraction yields abstract transi-tions with abstract sync rule r0z- that is s1) r0z s3 in thelifecycle of A0

4 and s1) r0z s6 in the lifecycle of A01.

Next, we consider the case that the sync abstractionperforms on an L-fragment of one artifact that synchronizeswith the entire lifecycle of one another artifact. Such wholelifecycle can be considered as fully-embedded externallifecycle in the L-fragment. We say that lifecycle ℒCj

canbe fully-embedded in lifecycle ℒCi

if there exists

L-fragment ℓCi !ℒCithat completely synchronizes the

entire lifecycle ℒCj, i.e., the entry state and the exit state

(s) of ℓCj are the init state and all the final state(s) of ℒCj,

respectively. It can be understood that the abstract lifecycleof artifact Cj containing only abstract transition(s) firingfrom its init state to its final state(s) implies a single steplifecycle and there does not exists any L-fragment within it,i.e., f ind_Lf ðCj;Cj:SÞ ¼ null. The benefit of introducing thistype of lifecycle abstraction is discussed later when takinginto account the construction of public view. It is noted thata lifecycle of one artifact can be considered as fully-embedded external lifecycle of other multiple lifecycles.

Example 16. In Fig. 16 (a), L-fragment l1 synchronizes withL-fragment l2 which represents the whole lifecycle ofartifact A2. Therefore, we have ℒA2 as an fully-embeddedlifecycle of ℒA1 . Similarly, in Fig. 16 (b), we have ℒA3 as afully-embedded lifecycle of both ℒA1and ℒA2 .

Next, we show that sync abstraction function sa_f pre-serves B-consistency of between two synchronized life-cycles of the input and two outputted abstract lifecycles.

Theorem 2. (synchronized fragments b-consistent abstrac-tion). Let ω¼ ðΓ;RsyncÞ be an AS-region in ACP model ∏ thatis to be abstracted in ACP model ∏0 and let L be a set of


abstract artifact lifecycles resulted from applying syncabstraction function sa_f ðΠ;ωÞ. Then the following statementholds.8ℒCi

;ℒCjAfℒjℓ!ℒ4ℓAΓg; (ℒ0

Ci;ℒ0

CjAL;

ℒ0CiC laℒCi

4ℒ0CjC laℒj-ℒ0

Ci� ℒ0

CjCℒCi

� ℒCi

We can prove Theorem 2 by using Definition 21 andDefinition 22 for the B-consistency checking between twoabstract lifecycles and their base lifecycles, and betweenthe composition between the former and the compositionbetween the latter. From Definition 24, sync abstractionsa_f always returns a single abstract transition in eachabstract lifecycle and a single sync rule between twoabstract transitions, so the composition of such abstracttransitions always yields an atomic composite fragment.The composition of ASL-fragments in their base lifecycle isatomic and can entirely be represented by the compositionof abstract transitions.

4.3.3. Finding minimal AS-regionNext, we discuss similar requirements for the need of

NAL-fragment expansion (to AL-fragment). Given an L-fragment of one artifact lifecycle that synchronizes withother artifact lifecycle(s), we can find the minimal AS-region (which contains that L-fragment) and its minimalcounterpart(s) in which they can be used as inputs for syncabstraction function sa_f . Here, we propose two algorithmsto find the minimal AS-region of an L-fragment. Note thatthe synchronized counterparts can be many as the L-fragment can synchronize with multiple lifecycles. Twoproposed algorithms f ind_minASR and f ind_SR are used toexpand the boundary of an L-fragment along with itssynchronized counterpart(s) until all satisfy the conditionof AS-region and ASL-fragment (in Definition 22). If no AS-region can be constructed or an L-fragment has no syn-chronized counterpart of any other lifecycle, then the nullvalue is returned.

Algorithm 2. (function find_minASR). Finding a minimalAS-region from an L-fragment

Input: L-fragment ℓCx in ACP model ∏.Output: AS-region ω¼ ðΓ ;RsyncÞ if found; otherwise null isreturned.

1. ω’ðfℓCx g; ∅);2. ω¼ find_SRðωÞ;3. return ω;

Algorithm 3. (function find_SR). Finding an expandedS-region from an inputted S-region
Input: S-region ω¼ ðΓ ; RsyncÞ in ACP model ∏.
Output: Expanded S-region of ω or null if any SL-fragment in ωcannot satisfy the property of AL-fragment.

1. for each ℓiAω:Γ do2. L-fragment ℓ0

i ¼ find_minALðℓi);3. if (ℓ0

i ¼ nullÞ then return null;4. else5. ω:Γ ¼ ω:Γ [ fℓ0

ig fℓig;6. end if7. for each ℒjAfℒCj

j CjAΠ̂:Zg do8. states Sj ¼ ∅;9. for each rkAφðℓ0

i ;ℒjÞ do

10. Sj’pre_sðrk ; CjÞ [ post_sðrk; CjÞ;11. if (∄rkAω:RsyncÞ then rkAω:Rsync’ rk;12. end for13. L-fragment ℓj ¼ f ind_Lf ðCj ; SjÞ;14. L-fragment ℓ0

j ¼ find_minALðℓj);15. if(ℓ0

janullÞ16. then17. if ð∄ℓ0

jAω:Γ Þ18. then19. ω:Γ ¼ ω:Γ [ fℓ0

jg;20. ω¼ find_SRðω Þ;21. return ω;22. end if23. else return null;24. end if25. end for26. end for

Here, we use a running example illustrated in Fig. 17 toexplain the algorithms of functions f ind_minASR andf ind_SR.

We begin with Fig. 17 (a) by applying f ind_minASRðl1Þ inthis example. First it takes L-fragment l1 of artifact A2 as aninput and initializes an S-region from l1 and an empty set ofsync rule. Then it finds the possible corresponding S-regionfor l1 (by calling f ind_SR function). Function f ind_SR startschecking whether l1 can satisfy the property of AL-fragment (Line 3). If so, then it continues searching for allsync rules and their related synchronized states that areused to synchronize l1 with any other lifecycle transitions;otherwise, it immediately returns null. In the iteration offinding synchronized part of other artifact, if a set ofsynchronized states is found (Lines 9–12), then a fragmentconsisting of such set is constructed by calling find_Lffunction (defined in Definition 14) – that is L-fragment l2of artifact A1 shown in Fig. 17 (b). Next, l2 is to be checkedwhether it is qualified as AL-fragment. If it satisfies, then itis added into the S-region (Lines 13 -21); otherwise, it hasto be expanded until it can satisfy AL-fragment. Oncequalified, it is added into the S-region (Line 19). After l2 isadded to the S-region, we recursively call function f ind_SRagain with the expanded S-region as an input (Line 20).Fig. 17 (c) shows AL-fragment l02 that is expanded from l2.We can see that l02 introduces new sync rules fr5; r6g thatare not included in the S-region. The recursion will con-tinue until all the SL-fragments in the S-region are AL-fragments and include all the possible sync rules that areused in the S-region. Consequently, l1 is required to expanditself and becomes new AL-fragment l01, as shown in Fig. 17(d). After that, we can see new sync rules fr7; r8g appear inl01. The S-region needs another expansion again to coverthose sync rules – that is L-fragment l3 of artifact A3. Theexit condition of the recursion is when the fragment is null(Line 15 with the exit on Line 23). The final output of thef ind_SR function is an S-region that all the sync rules arediscovered and that contains only AL-fragments. Finally, bycompleting the iteration and recursion with all the condi-tions of AS-region satisfied, the function returns the mini-mal AS-region consisting of ASL-fragments fl01; l02; l3g as theoutput from the provided input L-fragment l1. If the AS-region cannot be constructed then the function returns

A2A1

sa

s1 s3

sa

s1

r1

s2

s6

s5

s4

s6

r4 s5

s2

r3

r2l1

s3r5

A2A1

sa

s1 s3

s2

s6

s5

s4

sa

s1

s6

s5

s2

r1

r4r3

r2

s4

r6

s3r5

s4

r6

l'2 l1

A2A1

sa

s1 s3

s2

s6

s5

s4

sa

s1

s6

s5

s2

r1

r4r3

r2

s3r5

s4

r6

l'2

A2A1

sa

s1 s3

sa

s1

r1l2

s2

s6

s5

s4

s6

r4 s5

s2

r3

r2l1

s3r5

s4

r6

A3s1

s2

s3

r7

r8

A3s1

s2

s3

r7

r8

A3

s1

s2

s3

r7

r8

A3s1

s2

s3

r7

r8

l'1

A2A1

sa

s1 s3

s2

s6

s5

s4

sa

s1

s6

s5

s2

r1

r4r3

r2

s3r5

s4

r6

l'2

A3l'1

s1

s2

s3

r7

r8

l3

Fig. 17. A running example for the f ind_minASR function.

A1 A2A3

s1

sf s4

A’2s1

s3

s4

A’1

s1

s4

A2

A’1

s1

s3

A1s1

s3

s2

s1

s4

s2 s3

s1

s3

s2

l1

l1 l2

sf

A2

sf

r's1

s2r2

r1l2

A’3

sf

Fig. 16. An example of fully-embedded external lifecycles.



false. We can say the resulted AS-region is minimal as thefunction use the f ind_minAL function to guarantee theminimal AL-fragment expansion in the AS-region.

Based on Theorem 2 and the use of the f ind_minASR andf ind_SR functions, we can construct a consistent publicview of synchronized lifecycles by abstracting their syn-chronized parts of the lifecycles.

4.4. Consistent public view construction

Now, we use Theorems 1 and 2 to formulate the B-consistency for the entire artifact-centric inter-organiza-tional business process.

Theorem 3. (b-consistent public view). Let paΠ̂ be a publicview of ACP-i model Π̂ constructed by applying sync abstrac-tion function sa_f and lifecycle abstraction functions la_tranand sa_state. Then paΠ̂ is a B-consistent abstraction of Π̂, i.e.,ℒpaΠ̂

C laℒΠ̂.

Theorem 3 is derived from Theorems 1 and 2.Recall that in the public view, all local artifacts should be

invisible. Only abstract shared artifacts are revealed for thecollaboration. In order to hide those local artifacts of eachparty, the party must ensure that if a local artifact synchro-nizes with a fragment of a shared artifact, then thisfragment must be hidden as well. This hiding propertyrefers to the abstraction of such fragment. However, if theentire lifecycle of a local artifact is abstracted, then it can bevalidly hidden in the public view. In Section 4.3.2, wediscuss the fully-embedding property to capture this kindof lifecycle. In other words, if the lifecycle of a local artifactis a fully-embedded external lifecycle of the shared artifact,then the local artifact can be hidden. As such, the corre-sponding fragment(s) in the shared artifact(s) is alsoabstracted (by using sync abstraction function sa_f ). How-ever, there is a case if that fragment is not an AL-fragment,then the sa_f function cannot be applied due to therequirement of the input that must be AS-region (consist-ing of ASL-fragments of shared artifact(s) and local artifact).To cope with this issue, then we propose to use lifecycleabstraction function la_state to abstract it into an abstractstate. Then the local artifact that synchronizes with thatfragment can be abstracted. Although we can abstract anNAL-fragment into an abstract state, it is hard to decidewhether that abstraction is valid and consistent in terms ofsynchronization behavior. The local artifact that synchro-nizes with any part of such NAL-fragment must be exclu-sively encapsulated in the abstract state. In addition, theabstract state itself is not considered as atomic if it hasmultiple entry and multiple exit transitions from/to differ-ent states. Therefore, we allow having sync abstraction forthe abstract state for the case that the whole lifecycle of thelocal artifact is synchronized within the NAL-fragment. Aspreviously discussed, representing an NAL-fragment in anabstract transition is deemed inconsistent.

Example 17. Revisit our purchasing process example inFig. 1. We can construct a fragment for the PO artifact thatconsists of states fcreated; on_holdg. The fragment is con-sidered as NAL-fragment (due to two exit states). We cansee that it synchronizes with the entire lifecycle of the

Quote artifact, therefore, the abstraction of this fragmentmust yield an abstract state which requires the wholelifecycle of Quote to be abstracted, i.e., fully-embedded –

that is the approving state of abstract PO in the public viewshown in Fig. 5. Similarly, the entire lifecycle of PL artifactcan be abstracted and fully-embedded in the supplyingstate of the abstract PO in the public view.

Next, we propose an algorithm (for a function namedf ind_minPV) to help organizations to automatically find theminimal, consistent public view from their ACP-i model.Due to the inconsistency issue on NAL-fragment abstrac-tion, we do not take NAL-fragments into account in thisalgorithm. After presenting the algorithm, we then showhow it can guarantee the B-consistency.

Algorithm 4. (function find_minPV). Finding the mini-mal, consistent public view of an ACP-i model

Input: ACP-i model Π̂¼ ðZ; V ; R; L; γÞ.Output: the minimal public view of Π̂.1. public ACP-i model Π̂

0 ¼ Π̂;2. for each CiAfCAΠ̂

0Z jγðCÞj ¼ 1g do

3. L-fragment ℓi ¼ f ind_Lf ðCi ; Ci:SÞ;4. AS-region ω¼ find_minASRðℓiÞ;5. i f (ω anull)6. then7. Π̂

0:¼ sa_f ðΠ̂0

; ωÞ;8. artifacts Zl’Ci;9. for each CjAfCAΠ̂

0:Z jγðCÞj ¼ 1g do

10. L-fragment ℓj ¼ f ind_Lf ðCj ;Cj :SÞ;11. if ðℓj ¼ nullÞ then Zl’Cj;12. end for13. remove all artifacts in Zl and their related abstract sync rules

from Π̂0;

14. Zl ¼∅;15. end if16. end for17. return Π̂

0;

Now, we explain the algorithm for the f ind_minPVfunction. First, it initializes a public view as identical toan input ACP-i model. Then, it searches for all local artifactsin the public view (Line 2). For each local artifact found, itattempts to construct an AS-region that consists of suchartifact (Lines 3–4). If it is able to construct the AS-region(Line 5), then abstraction function sa_f is applied on theregion and the artifact is added to the set Zl and all artifactsin Zl will be later removed from the public view (Lines 7–8).As sa_f finds all corresponding ASL-fragments (if construc-tible) that synchronized with the local artifact into accountfor the abstraction, the algorithm also searches for otherlocal artifact that qualifies as fully-embedded external life-cycle to be included in Zl (Lines 9–12). This will eliminatean unnecessary local artifact in the public view; therefore,the number of iterations for finding local artifacts isreduced in the main loop.

From the algorithmwewill get the minimal, B-consistentpublic view of the ACP-i model. However, it does notguarantee that all local artifacts are abstracted. Thisdepends on whether the lifecycle of such artifacts can be


fully-embedded as well as the synchronized part of theshared artifact is an ASL-fragment. In other words, if thefragment is an NAL-fragment, then, as previously discussed,the abstraction of those local artifacts must be achievedmanually – by abstracting each of such fragments into anabstract state instead. This process requires a predefinedabstract state for an abstract shared artifact.

Next, we show in Theorem 4 that our f ind_minPVfunction produces a minimal, B-consistent public view.

Theorem 4. f ind_minPVðΠ̂Þ returns a minimal, B-consistentpublic view of Π̂.

We can prove Theorem 4 as follows. First, we prove thatf ind_minPVðΠ̂Þ returns a correct public view of Π̂. This canbe done by induction over all mapping conditions inDefinition 12. Note that removing local artifact from thepublic view where its entire lifecycle can be abstracted alsoconforms to the definition of public view. Second, we provethat given ACP-i model Π̂, f ind_minPVðΠ̂Þ is guaranteed toreturn minimal public view of Π̂. As we use functionfind_minASR to search for the minimal AS-region that canbe used as an input of the abstraction function sa_f , thenthis statement is naturally satisfied. Last, we prove the B-consistency of the generated public view. Based on Theorem3 and Definition 24, the public view preserves B-consistencyas function sa_f always yields a B-consistent abstract ACPmodel of the inputted ACP model.

We now conclude Section 4. In summary, this section hasdiscussed the public view construction methodology andbehavior consistency and formulates several functions andtheorems that can be used to construct the B-consistent publicview of the collaboration. It also presents our algorithms thathelp organizations automatically generate the minimalabstract public view with the assurance of the B-consistency.

5. Consistent process changes and private views

In this section, we propose a mechanism that allows aparty in the collaboration to change their local (private)process without affecting the correctness and consistencyof the overall process.

5.1. Local process changes

Organizations may need to change their local processesdue to their new (or updated) set of business requirementsor regulations that they have to follow. We observe that inartifact-centric processes, changes to local processes can beclassified into three types based on the three componentsof the ACP model.

�
Changes to artifacts. An organization may modify/delete/add an attribute or a state of its local artifact, which canbe seen as structural changes to the data model of anartifact. In addition, except for changes to existingartifacts, it is possible that an organization may incor-porate a set of new artifacts into the local process.
�
Changes to tasks. Stemmed from service-oriented archi-tecture, an organization may seek to aggregate existinglocal tasks into a composite task (i.e., a service). On the
other hand, a composite task can be decomposed intosmaller tasks. Due to these possible changes to tasks, thespecification of a task, including the input, output, andpre/post-conditions of the task, is subject to reflectingthe changes –.

�
Changes to business rules. Business rules can be changeddue to the structural changes of artifacts, the specifica-tion changes of tasks, and the changes of the processlogic. It is worth noting that a change may affect anexisting interaction behavior between artifacts.
Next, we define three change operators that can be used toexpress what and how the above-mentioned three types ofchange can be achieved. As aforementioned, in this article weonly focus on the behavior aspect of artifact-centric businessprocesses. We restrict our discussion in behavioral changes oflocal processes. Therefore, for simplicity, we assume thatcapturing the change of a business rule can reflect the changeof artifact(s) and task(s) involved in this rule. This makessense as the associations between artifacts and tasks aredefined in the pre/post-conditions and actions, respectively,in business rules. In the case of adding a new artifact to a localprocess, we can derive the lifecycle of the new artifact and itsinteraction from the added business rules that are used toinduce the state transition of the artifact and the sync rulesthat are used to synchronize other existing artifact(s) with it,respectively.

Definition 25. (Change operators). Let Π̂l ¼ ðZl; Vl; RlÞ be

a local ACP model of organization role l in the collaboration.An organization can change its own local process byapplying the following change operators over businessrules Rl.

�
Add operator ðRþ Þ. We write Rþ ðrÞ to mean that newbusiness rule r is added into R, i.e., Rþ ðrÞ ¼ Rl [ frg.
�
Delete operator ðR� Þ. We write R� ðrÞ to mean thatexisting business rule r is deleted from R, i.e.,R� ðrÞ ¼ Rl frg.
�
Replace operator (R%). We write R%ðrx; ryÞ to mean thatexisting business rule rx is replaced by new businessrule ry in R, i.e., R%ðrx; ryÞ ¼ Rl [ fryg frxg.
It is noted that the replace operator identically performsas the combination of the add operator and the deleteoperator; however, it provides better traceability of changesby maintaining the relation for the replacement of an oldbusiness rule with a new business rule.

Definition 26. (Modified local ACP model, process change

function (pc)). Let Π̂l ¼ ðZl; Vl; RlÞ be a local ACP model of

role l. We can obtain modified local ACP model Π̂l0

from Π̂l

by applying process change function pcΠ̂

l : Π̂l � X-Π̂

l0

where

X is a union set of change operations Rþ , R� , and R% thatperform on some business rules in Rl.

Next, we explain the concept of private view and how itcan be used to validate the changes of local process.


5.2. Private views and change validation

In the overall picture, we validate the changes of localprocess by checking whether the B-consistency of themodified inter-organizational business process (after localprocess changes applied) and the agreed public view can bepreserved. A private view of an organization is used tocapture the modified local process for the purpose of locallychecking whether the local process is still able to providewhat promised in the agreed contract, i.e., public view. Weillustrate an overview of process change validation inFig. 18.

Next, we define the private view of a particular organi-zation role in the collaboration based on the agreed publicview. Based on each version of local process changes, eachrole has a corresponding private view that captures its(modified) local ACP model plus abstract shared artifactsdefined in the public view.

Definition 27. (Private view). Let paΠ̂ ¼ ðZp; Vp; Rp; Lp; γpÞbe a public view of ACP-i model Π̂ and Π̂

l ¼ ðZl; Vl; RlÞ be alocal ACP model of role lALp. The private view of role l canbe defined by private view mapping function pv: Zx [ Vx [Rx [ γx-ðZp [ ZlÞ [ Vl [ ðRp [ RlÞ [ Lp [ γp such that thefollowings hold.

�
each abstract shared artifact in Zp exists in Zx, i.e.,8CiAfCAZpj γpðCÞ
�� 41g; (CjAZx; pvðCjÞ ¼ Ci �γxðCjÞ ¼ γp ðCiÞ

�
each local artifact in Zl (not in Zp) exists in Zx, i.e.,8CiAfCAZljjγpðCÞj ¼ 1g; (CjAZx; pvðCjÞ ¼ Ci� γxðCjÞ ¼ l
each task in Vl exists in Vx, i.e.,8viAVl; (vjAVx;pvðvjÞ ¼ vi � γxðvjÞ ¼ l

�
each business rule in Rl exists in Rx, i.e.,
8riARl; (rjARx; pvðrjÞ ¼ ri;

Fig. 18. An overview of private view

each abstract business rule in Rp that is not used for the
� synchronization between an abstract shared artifact inZp and a local artifact in Zl exists in Rx, i.e.,8riAfrARpjl=2γpðrÞg; (rjARx; pvðrjÞ ¼ ri
Note that we may use the term private view for thelifecycle of this private view in an unambiguous context.

Example 18. Fig. 19 depicts the lifecycles of artifacts in theprivate view of the original local process of Supplier

(Π̂Supplier

1 ) which is extracted from the complete purchasingprocess shown in Fig. 1. Such private view can be con-structed based on the public view shown in Fig. 5. Apartfrom the local artifacts PL and DN, compared with thepublic view, we can see local process details (in gray-shaded areas) of shared artifacts PO, SO, and IV.

Example 19. Now, consider the case that if Supplier wantsto change its local process based on the existing one (cf.Fig. 19). The result of changes is illustrated in private view

Π̂Supplier

2 in Fig. 20. Since the IL artifact is added into the localprocess, we can see some synchronization between existingartifact PL and new artifact IL, as well as the change ofstate’s names of PL (from checking to scheduled, from out ofstock to unavailable, and from in stock to picking). Existingbusiness rules that correspond to these changes areaffected and needed to be adjusted accordingly. Obviously,a new set of business rules is needed to express thelifecycle of the added artifact. This set includes sync rulesthat are used for the synchronization between PL and IL.

Next, we define process conformance and its conditionsthat can be used to check whether changes in local processcan be implemented while preserving the correctness andconsistency of the overall process. Basically, we reuse thedefinition of B-consistency to define process conformance for

s and view conformance.

Picking List (PL)


canceled

Out of stock

closed

Shipping Order (SO)In transit

Invoice (IV)

approving

acquiring

accepted filled


checking In stock

Delivery Note (DN)

prepared

transferring

dispatched

billing

issued

cleared

sent

unpaid

clearing

arrived

delivering

ready to ship

created scheduled

Fig. 19. Supplier’s private view Π̂Supplier1 .

Picking List (PL)


canceled

unavailable

closed

Shipping Order (SO)

Invoice (IV)

approving

acquiring

accepted filled


scheduled picking

Delivery Note (DN)

prepared

transferring

dispatched

billing

issued

cleared

sent

unpaid

clearing

Inventory List (IL)

checking

ready to pick

sourcing

canceled

delivering

ready to ship

In transitcreated scheduled arrived

Fig. 20. Supplier’s modified private view Π̂Supplier2 .


consistent local process changes as to satisfy the followingstatements.

�
Changes should not lead to an unsound global process,i.e., the modified global process should be able to reachits goal states as its original global process does, and,
�
Changes should be guaranteed that the B-consistency ofthe modified global process and its original globalprocess is preserved.
As an agreed public view is constructed for the colla-boration which acts like a contract, so we can expressconsistent process changes by means of not breaking the

original public view. In other words, the modified ACP-imodel must be consistent with the agreed public view.Regarding the behavioral equivalence notion in processalgebras [9], we can say that our approach for consistentprocess changes preserves the congruence property of themodified local process and its base local process, i.e., theycan behave interchangeably without affecting the overallprocess.

Definition 28. (Process conformance, F). Let Π̂¼ ðZ;V ; R; L; γÞ be an ACP-i model and paΠ̂ be its public view.

Let pvΠ̂l be a private view of local ACP model Π̂

lfor role lAL.

We say that Π̂lconforms paΠ̂, written as Π̂

lFpaΠ̂, iff the


lifecycle of pvΠ̂l is B-consistent with the lifecycle of paΠ̂, i.e.,

Π̂lFpaΠ̂2ℒpv

Π̂l CℒpaΠ̂

Definition 29. (Consistent process changes, congruent

local processes). Given ACP-i model Π̂ and its public view

paΠ̂, let Π̂lbe a local ACP model for role lAL and Π̂

l0

be a

modified local ACP model of Π̂lwith process change pc

Π̂l . We

say that pcΠ̂l is consistent if Π̂

lFpaΠ̂-Π̂

l'FpaΠ̂. Corre-

spondingly, we have Π̂l'CΠ̂

land C is a congruence for Π̂.

Theorem 5. (process changes b-consistency). Let paΠ̂ be a

public view of ACP-i model Π̂ and Π̂0be a modified ACP-i

model of Π̂ based on a set of process changesPC

Π̂L ¼ fpcΠ̂l1 ; pcΠ̂l2 ; …; pc

Π̂lx g where pcΠ̂li is a process

change applied on local ACP model Π̂li. Then, we have the

lifecycle of Π̂0B-consistent with the lifecycle of paΠ̂ if all

process changes in PCΠ̂L are consistent, i.e.,

8pcΠ̂li APC

Π̂L ;pcΠ̂li is consistent-ℒΠ̂0 CℒpaΠ̂

The proof of Theorem 5 is straightforward as it can bederived from Definitions 28 and 29.

From Theorem 5, we can see that if all organizations inthe collaboration can guarantee that changes in their localprocess are consistent, then such changes do not violate theB-consistency of the global process. It is worthwhile men-tioning that checking local processes via private viewsimplies that a global validation of entire process is notrequired, thus, avoiding the state space exposition problem.The benefit of private views and the local validationmechanism can be seen as a key driver for organizationsto meet the three major requirements of efficient colla-boration discussed in Section 2.

6. Prototype implementation

We have developed a software prototype, which iscalled Artifact-M, to evaluate the applicability and feasibilityof our view framework. The aim of Artifact-M is to facilitateprocess modelers to model, analyze, and visualize artifact-centric business processes with process view (public-viewconstruction) support. The system was implemented basedon Java SE 6.0 with JUNG 2.0.1 (Java Universal Network/Graph Framework) [41] to help visualize artifact lifecyclesin graph format. We implemented our public-view con-struction function f ind_minPV(as shown in Algorithm 4) asone of the main features of the system. As discussed,f ind_minPV reads a specification of an ACP-i model as aninput and automatically generates the minimal, consistentpublic-view, according to Theorem 4.

We implement our motivating example of inter-organizational purchasing process introduced in Section 2as our case study. We defined the specification of theprocess based on our own artifact-centric business process

specification, called APMT (Artifact-Centric Process Modelbased on LTS). An APMT document captures the behavior ofartifact-centric business process based on the definitions oflifecycles of artifacts and their synchronization. It alsosupports inter-organizational roles. The document is basedon XML format and is used as an input of the Artifact-Msystem. The detailed information of our Artifact-M projectincluding the system prototype and the ACP model speci-fication of the inter-organizational purchasing process (inAPMT format) can be found at https://sites.google.com/site/maxsirayongchareon/artifact-m [93].

Fig. 21 demonstrates artifact lifecycles of the originalpurchasing process. A state with no fill refers to a state of ashared artifact, while a state with shade refers to a state of alocal artifact. Here, we have PO (Purchase Order), SO(Shipping Order), and IV (Invoice) as shared artifacts, andQ (Quote), PL (Picking List), SL (Shipping List), P (Payment),and DN (Delivery Note) as local artifacts. A label attached toa transition of a shared artifact identifies a particularorganizational role that is responsible for the transition.Organizational roles defined in our case study are L1(Buyer), L2 (Seller), and L3 (Logistics). Consider the POartifact as an example, we can see that a transition fromPO:init to PO:created is performed by Buyer (L1), and atransition from PO:conf irmed to PO:accepted is controlledby Seller (L2).

Next, we show the generated public-view of the processthat is an output of our system. Once executed, the systemhighlights all the possible abstractable states (in bothshared and local artifacts) based on the use of thef ind_minPV function. Fig. 22 illustrates the information ofa public-view that is automatically generated by the sys-tem. The main screen shows lifecycles of artifacts. A statewith dotted-border is a state that can be automaticallyabstracted – a blue-colored state belongs to a sharedartifact, while the gray-colored state belongs to a localartifact. In contrast, a red-colored state is a state thatcannot be automatically abstracted – i.e., it is a state of anNAL fragment. A pop-up window showing on the right handside of Fig. 22 displays detailed information about abstrac-tion details of each artifact. For example, the PO artifact hasthe ready_to_ship state that can be automatically abstractedbut not the accepted, created, on_hold, and acquiring states.In addition, for local artifacts, only the DN, SL, and Partifacts can be automatically abstracted, while the Q andPL artifacts require a manual abstraction - this is becauseboth are synchronized with some NAL-fragments in the POartifact.

7. Related work and discussion

In this section, we summarize and classify relatedworks, and then discuss and compare them with our work.We first discuss the related work in model specification andverification of artifact-centric business processes in general,and then we discuss the related work in view-basedapproaches for inter-organizational business processes,and finally we discuss the related work in behavior-consistent derivation and behavior compatibility of busi-ness processes.

https://sites.google.com/site/maxsirayongchareon/artifact-m


Fig. 21. A visualization of artifact lifecycles of our inter-organizational purchasing process.

Fig. 22. Artifact lifecycles of the public-view of the purchasing process in Fig. 21.



7.1. Artifact-centric approaches to modeling businessprocesses

We start with the discussion of model specification andverification of artifact-centric processes. [54] formulatednine operational patterns in artifact-centric operationalmodels and transform them into colored Petri Nets forreachability analysis. [31] presented a formal model usingCTL language for artifact-centric business process specifica-tion – where artifact classes are represented by addingobject-oriented classes with states, and guarded finite stateautomata is used to capture the logic of entities that carryout the work in a business model. Similarly, [5] focused onthe evolution of the business process logic by using servicesto model activities and a set of business rules to declara-tively capture and represent a business model with thestudy of necessary properties such as reachability of goalstates, absence of deadlocks, and redundancy of data. In ourwork, we do not consider data verification of businessrules; on the other hand, we focus on the verification ofthe behavior of processes based on the analysis of LTS. It isworth noting that we also provide a discussion on thefragmental behavior analysis of the synchronized artifacts(through the notion of AS-region) and how this analysis isused to provide a behavior-consistent process abstraction(for public views).

Recently, ArtiNet model [43] and Guard-Stage-Milestone(GSM) approach [35,36,23] have been introduced for specifyingbusiness artifact lifecycles and their constraints. The former isdeveloped based on DecSerFlow language [84] while the latteris developed in a state-machine style based on the BusinessEntities with Lifecycles (BEL) framework used in IBM’s ServiceOriented Modeling and Architecture (SOMA) method [78]. Thebehavior specification of a GSM system can be declarativelyexpressed in terms of ECA-like rules with the support forparallelism within artifact instances and modularity throughhierarchical constructs. Our (inter-organizational) ACP modelsare developed in correspondence with these works with aparticular focus on the behavior aspect of business processes.In our model, we distinguish two different types of artifacts,which are local artifacts and shared artifacts, to enable theviews of private processes and public coordination in thecollaboration. In behavioral perspective, we use LTS model tocapture the behavior of both types of artifacts, which is similarto a state machine system. In terms of verification, we use aconventional state composition technique to check the sound-ness of processes, in general. However, stemmed from theconcern of organization’s privacy and autonomy, we proposeda verification technique that performs on the local composition(i.e., private views) instead of on the whole global collaborationprocess; therefore, the problem of state exposition caused byperforming global verification is avoided.

7.2. Public/private view approaches for inter-organizationalbusiness processes

Several works have shown the significance of usingpublic/private views approaches to support and facilitatethe modeling and management of inter-organizationalbusiness processes. Initially, [85] introduced the notion ofpublic and private views with the discussion of how these

views can help the coordination in a dynamic collaboration.The views are used to protect the privacy of collaboratingorganizations while maintaining high level of flexibility andautonomy. Later, [81] formulated the inheritance-preserving transformation rules to support private processchanges. The rules can be used to guarantee that thebehavior of the public process is not affected by localextensions and modifications. This means that the execu-tion of the overall process is actually consistent with theexecution of the process agreed by all parties in thecollaboration in the first place. Influenced by the conceptof public/private views, there are several follow-up workscarried out to support them in both theoretical andpractical aspects, e.g., in [51,52,77,16,17,14,48,10,99,100–103,97,98,40].

Apart from the above works, [92] studied the analysis ofatomicity properties for a set of interacting public processviews that use atomicity spheres [76], and proposed to useaxioms from process algebra for the atomicity-preservingconstruction of public process view from a private process.Recently, [83] proposed to use a public view as a servicecontract for choreographic collaboration along with thenotion of private/public views accordance and operatingguidelines [61,57]. [27] proposed transactional processviews by the construction from an internal business pro-cess annotated with a transactional specification. All of theabove works have been carried out in the context oftraditional activity-centric business processes. Motivatedby their work, we study their techniques for process viewconstruction and validation and apply them in the artifact-centric perspective. Technically, the mechanisms to consis-tently construct and validate views for artifact-centricprocesses are more complicated due to the interactionrelations (i.e., synchronization dependencies) of local andshared artifacts. We also use our notions of B-consistencyand AS-region to support the consistent construction of apublic view and consistent change validation in localprocesses. Based on these notions, we are able to auto-matically derive a consistent and minimal public view fromthe local processes.

There are some works that initiated the study of howviews can be used in the artifact-centric process modelingparadigm. [37] proposed an approach to the interoperationof organizations hubs based on business artifacts. The hubprovides a centralized, computerized rendezvous point,where stakeholders can access data of common interestand check the current status of an aggregate process. Theyproposed three types of access restriction for stakeholders,namely window, view, and CRUD. Window provides amechanism to restrict which artifacts a stakeholder cansee. View provides a mechanism to restrict what parts of anartifact a stakeholder can see. CRUD is used to restrict theways that stakeholders can read and modify artifacts.Compared with our work, we take the dynamic behaviorof both artifacts and processes into account for the con-struction and validation of views while their views considerthe structural and data aspect of artifacts. Our previouswork [94] introduced an artifact-centric process viewframework to allow role-based process abstractionfor different levels of visibility of the artifacts involved inthe processes, with some consideration on attribute


abstraction. This data abstraction can complement to ourcurrent work. However, the previous work discussed localprocess abstraction technique without taking the require-ments for inter-organizational collaboration into account, i.e., different roles see different abstract views of the entireprocess not only their own responsible process.

In contrast to the orchestration perspective, [58] pre-sented an approach for artifact-centric choreographies withthe concept of agents and location-aware artifacts usingPetri-net model with the concepts of agents and locations.They proposed a mechanism for automatic generation of aninteraction model that serves as a contract between theagents ensuring that specified global goal states on theinvolved artifacts can be reached. The concept of theirlocation-aware artifacts is similar to the concept of our sharedartifacts, which has been introduced in [95]. Similarly, [79]proposed a declarative choreography language that concernsdata contents and cardinality on participant instances. How-ever, compared with our work, their work only focused onthe interaction model and did not consider the model of localprocesses, while our approach uses view-based technique toaddress the three choreographies requirements (autonomy,compliance, flexibility) by forming a global process contractbased on shared artifacts together with the validationmechanism for extending and modifying local processeswhile preserving global correctness.

Most recently, [26] proposed a framework that supportssplitting and outsourcing of GSM schemas while preservingthe semantics of the original schema. The framework alsocontains locking protocols that define how the distributedparties should operate, therefore, allowing parties to main-tain private parts of their GSM subschema without affectingthe global execution. They claimed that their frameworkpreserves the behavior of the original GSM schema. Com-pared with our work, their work considers similarapproaches as our work in terms of defining private (local)parts of an artifact schema. However, their approach doesnot consider the dynamic interaction (synchronization)behavior between artifacts, while it is deemed as one ofthe main focuses of our framework. We also proposedalgorithms and a tool support for automatically determin-ing which part of the local/shared artifacts can be hidden(abstracted) without affecting the global process.

7.3. Behavior-consistent derivation and behaviorcompatibility

The studies on behavior consistency between a derivedprocess and its base process are closely related to our work.As a public view is constructed based on the integration oflocal processes (of each party in the collaboration), so it isimportant the execution behavior of public view process isconsistent with the actual collaboration process.

Basten, Van Der Aalst [4] defined protocol inheritance(actions are blocked) and projection inheritance (actionsare hidden) based on LTS and branching bi-simulation.Similarly, [75] studied the consistency criteria of theinheritance of object life cycles based on refinement,extension, and deletion of states/activities in the lifecycle.They distinguished weak and strong invocation con-sistencies and observation consistency, and then proposed

necessary and sufficient rules for checking behavior con-sistency between object lifecycles. Their work correspondsto the inheritance notions proposed in [4]. Later, [81]formulated a set of inheritance-preserving rules for tradi-tional workflow processes. [87] proposed an approach tocompare models based causal footprints representing theabstractions of process behavior. Recently, [89] introducedthe notions of projection and protocol compatibility ofcorrespondences between process models to decide thecompatibility of two business process models based onbehavior inheritance. While all of the above works focusedon the inheritance of single object lifecycle, in our previouswork for artifact-centric process specialization [96] weadopted and extended the study of consistent refinementand projection inheritance to support the inheritance ofmultiple lifecycles and their interactions in the artifact-centric process based on two specialization methods:artifact refinement and artifact extension. Compared withour previous work, this work supports process abstractionby extending the use of the B-consistency notion forbehavior consistency checking.

[33] argued that object-oriented system design shouldincorporate a concept of behavioral inheritance for classesin such way that a system refinement should either pre-serve trace inclusion or simulation for the language buildby the system's protocol – which can be done by using theinheritance notion in [81]. [24] proposed a unified frame-work for behavioral compatibility and consistency of ser-vices in choreography-driven settings. They observed thatinteracting partners only need to agree on a suitablecompatibility instead of the consistency relation as it canbe determined whether a consistency relation is optimalfor the chosen compatibility notion. Based on these works,we analyze the interaction (synchronization) behavior ofartifacts and study how to ensure their consistency in aderived process via the use of atomicity property (of S-region) to preserve the synchronous behavior consistencybetween artifacts in their original process and in thederived process. Our notion of public view (as a contract)can be used to guarantee the weak bi-simulation behaviorconsistency and behavior compatibility of one's local pro-cess and a global process. In a private view, we alloworganizations to extend their local processes by addingartifacts into the processes. The extension is guaranteed toconform to the global process based on our B-consistencyand AS-region notions.

[62] argued that Boolean characteristics of all equiva-lence notions are deemed not very useful for comparingnormative process model with a process model discoveredusing process mining techniques. Thus, they proposednotions of fitness, precision, and recall for the comparisonbetween processes based on their execution sequences thatare retrieved from an event log. Similar issue is alsodiscussed for the evaluation of alignment consistencybetween process models. [90] proposed the concept of abehavioral profile that captures the essential behavioralconstraints of a process model in contrast to the existingnotion of trace equivalence and consistency measures. Theprofile allows the quantified measurement of differencesbetween processes ranging from 0 to 1.0. Although, in ourwork, we do not focus on comparing process models,


further study is required to explore how these concepts cancomplement the consistent change validation of localartifact-centric process models.

In artifact-centric setting, [12] addressed the problem ofcomparing artifact-centric workflows by proposing anotion of dominance between workflows that capturesthe fact that all executions of one workflow can beemulated by another workflow. Their work focused onthe initial and final snapshots of the workflow executionto be compared and did not take the behavior of artifactsand processes into account. [46,11] proposed a techniquefor generating a process model from object lifecycles,which can be used for checking whether a business processmodel is compliant with the reference lifecycles. Our life-cycle composition for generation ACP model is similar totheir approach. However, their approach focuses on acomplete model behavior, while our work applies thelifecycle composition technique to support fragmentalbehavior analysis. Recently, [56] presented an approach toautomatically constructing business process models basedon policies (interdependencies between artifacts) and com-pliance rules, which results in the reduction of compliantbehavior checking in terms of reachability of final states. Anartifact composition technique presented in [58] is used inthis approach for the compliance checking. Compared withour work, the purpose of behavior checking via the use ofthe compliance rules is similar to our B-consistency valida-tion of private view against its public view. However, apartfrom checking overall behavior of a process, we provide thefragmental validation of sub-lifecycles of artifacts and theirsynchronizations (via the use of AS-region).

8. Conclusion and future work

This article presents a view framework for modelinginter-organizational business processes and validating thechanges to them. We formally define a artifact-centricinter-organizational business process meta model, i.e.,ACP-i model, with the notions of public and private viewsto address the requirements for efficient collaboration,namely, compliance, flexibility, and autonomy. Lifecycleabstraction methods to abstract artifacts and their synchro-nization in the public view are introduced along with thenotions of B-consistency and AS-region for checking beha-vioral consistency between concrete processes and theirderived (public/private) views. Based on these two notions,we develop algorithms to automatically find the minimalpublic view for a given inter-organizational business pro-cess. We also illustrate that any change occurred (viachange operations) in a local process can be validated usingprocess conformance to guarantee such changes will notaffect the correctness and consistency of the global process.

Although we provide a comprehensive discussion on theview-based modeling and change validation approach forartifact-centric inter-organizational business processes, thereare some remaining issues open for further investigation.

�
Modeling languages. In our work, we did not develop aparticular modeling language nor link our framework toany existing modeling language. Due to the inherent
nature of artifact-centric modeling approaches, rule-based languages are deemed most suitable to achievehighly-flexible process specifications. Unlike GSMmodelspecification (e.g., in [35,36,23]) which possess a highlydeclarative manner, we introduce our ACP specificationusing simplified condition-action-styled business rulesto define the control logic of business processes. Thiskind of rules can be extended to fully-fledged ECA rulesin a more declarative style with temporal constraints(e.g., CTL [31], TiLe [102,103], and LTL-FO [23]). As ourwork only considers the behavioral aspect of processes,the interpretation of business rules to generating (LTS)lifecycles of artifacts is required (e.g., for our rule syntax,the lifecycle can be constructed from Definition 8).Especially the abstraction of business rules (in a parti-cular language) needs further investigation. In addition,our work currently does not support one-to-manyscenario (1-to-N cardinality between different roles)and it is left for future work.

�
Web service specification and abstraction. As mentionedin Section 3.2, the definition of tasks (or services) inartifact-centric approaches can be naturally described ina semantic manner (based on [71]). For the abstractionof artifacts, we assume that the pre- and post-conditionsof tasks to be abstracted conform to the pre- and post-conditions of business rules that associate such tasks tothe artifacts. Therefore, there is no need to checkwhether such abstraction is valid. However, it is possiblethat the conditions of tasks do not strongly conform tothe conditions of business rules; hence, the conditionsof abstract task and corresponding abstract rule(s) canbe inconsistent. This requires the abstraction to includean additional validation mechanism to handle suchissue. The GSM Splitting approach presented in [26]can be used for further investigation of artifact schemaand ECA rules abstraction.
�
Changes in local processes and conformance. In our notionof private views, changes are captured and validatedusing process conformance with the help of B-consistency to guarantee the conformance to the publicview and restrict the behavior of a post-modified localprocess to be equivalent to the ones of its originalprocess. It is more desirable if we can directly (andpossibly incrementally) validate change operations onlocal process without deriving all artifact lifecycles fromadded/modified business rules. An efficient and auto-matic checking algorithm should be developed for suchvalidation. Based on existing works, operating guide-lines [61,57] and compliance rules [56] can be adoptedto address such requirements and complement ourwork. Moreover, process changes should be generalizedand classified into patterns that address different needs;thus, these patterns can be used to assist in definingchanges specification.
�
Workflow with view realization. For activity-centric appro-aches, [70] proposed a technique of translating BPMN toBPEL for implementing workflows in SOA. However,artifact-centric models require different realization tech-niques. A realization for our ACP-i model can be possiblyachieved by considering two different approaches featuredwith public view definition and private view validation


mechanism. The simple solution is to transform ACPmodels to activity-centric models (e.g., in [53,47]) usingmodel-transformation techniques presented in [46,72],and then realize them on existing workflow systems plusview features (e.g., in [40]). However, this solution seemsnot very promising as the transformation poses severaldrawbacks (as discussed in [67]). [18] presented Seinaprototype that allows users to model business artifactsand process as XML documents. The work on Active XML(AXML) [1,2,60], which extends standard XML withembedded service calls, can be used for implementingartifacts that are accessed within or between organiza-tions in the collaboration. Influenced by these work, weaim to develop a pure artifact-centric process system forrealizing our artifact-centric view framework. Currently,we are developing a prototype based on the realizationframework in [67] with the support of shared/local XML-based artifacts.

In summary, there are several remaining issues to bediscussed for efficient management of artifact-centric inter-organizational business processes. Our work can be seen as thefirst step towards these ultimate goals. In future, we plan totake real-life (industrial) collaboration processes as case studiesand check how our framework can address these issues.

References

[1] S. Abiteboul, O. Benjelloun, T. Milo, The active XML project: anoverview, VLDB J. 17 (2008) 1019–1040.

[2] S. Abiteboul, L. Segoufin, V. Vianu, Static analysis of active XMLsystems, ACM Trans. Database Syst. 34 (4) (2009). (Article 23).

[3] Artifact-centric service interoperation (ACSI), ⟨http://acsi-project.eu/⟩,2011.

[4] T. Basten, W.M.P. van Der Aalst, Inheritance of behavior, J. Log.Algebraic Progr. 47 (2) (2001) 47–145.

[5] K. Bhattacharya, N.S. Caswell, S. Kumaran, A. Nigam, F.Y. Wu,Artifact-centered operational modeling: lessons from customerengagements, IBM Syst. J. (2007) 703–721.

[6] K. Bhattacharya, K. Lyman, F.F. Heath, S. Kumaran, P. Nandi, F.Y. Wu,P. Athma, C. Freiberg, L. Johannsen, A. Staudt, A model-drivenapproach to industrializing discovery processes in pharmaceuticalresearch, IBM Syst. J. 44 (1) (2005) 145–162.

[7] K. Bhattacharya, C. Gerede, R. Hull, R. Liu, J. Su, Towards formalanalysis of artifact-centric business process models, Bus. ProcessManag. (2007) 288–304.

[8] K. Bhattacharya, R. Hull, J. Su, A data-centric design methodology forbusiness processes, Handbook of Research on Business ProcessModeling, , 2009.

[9] B. Bloom, Fundamental study structural operational semantics forweak bisimulations, Theor. Comput. Sci. 146 (1995) 25–68.

[10] R. Eshuis, P. Grefen, Constructing customized process views, DataKnowl. Eng. 64 (2008) 419–438.

[11] C. Cabanillas, M. Resinas, A. Ruiz-Cort´es, A. Awad, Automaticgeneration of a data-centered view of business processes, in:Proceedings of CAiSE, LNCS, vol. 6741, 2011, pp. 352–366.

[12] D. Calvanese, G. De Giacomo, R. Hull, J. Su, Artifact-centric workflowdominance, in: L. Baresi, C.-H. Chi, J. Suzuki (Eds.), ICSOC—ServiceWave,LNCS, vol. 5900, Springer, Heidelberg, 2009, pp. 130–143in: L. Baresi, C.-H. Chi, J. Suzuki (Eds.), ICSOC—ServiceWave, LNCS, vol.5900, Springer, Heidelberg, 2009, pp. 130–143.

[13] T. Chao, D. Cohn, A. Flatgard, S. Hahn, M. Linehan, P. Nandi, A. Nigam,F. Pinel, J. Vergo, F. Wu, Artifact-based transformation of IBM globalfinancing, Bus. Process Manag. 5701 (2009) 261–277. (LNCS).

[14] I. Chebbi, S. Dustdar, S. Tata, The view-based approach to dynamicinter-organizational workflow cooperation, Data Knowl. Eng. 56(2006) 139–173.

[15] C.M. Chiao, V. Künzle, M. Reichert, Object-aware process support inhealthcare information systems: requirements, conceptual frame-work and examples, Int. J. Adv. Life Sci. 5 (1 and 2) (2013) 11–26.

[16] D.K.W. Chiu, K. Karlapalem, Q. Li, E. Kafeza, Workflow view based e-contracts in a cross-organizational e-services environment, Distrib.Parallel Databases 12 (2002) 193–216.

[17] D.K.W. Chiu, S.C. Cheung, S. Till, K. Karlapalem, Q. Li, E. Kafeza,Workflow view driven cross-organizational interoperability in a webservice environment, Inf. Technol. Manag. 5 (2004) 221–250.

[18] D. Cohn, P. Dhoolia, F. Heath III, F. Pinel, J. Vergo, Siena: FromPowerPoint toWeb App in 5 minutes. In: Bouguettaya, A., Krueger, I.,Margaria, T. (Eds.), ICSOC LNCS, vol. 5364, 2008, pp. 722–723.

[19] D. Cohn, R. Hull, Business artifacts: A data-centric approach tomodeling business operations and processes, IEEE Data Eng. Bull.32 (3) (2009) 3–9.

[20] N. Desai, A.K. Chopra, M.P. Singh, Amoeba: a methodology formodeling and evolving cross-organizational business processes,ACM Trans. Softw. Eng. Methodol. 19 (2) (2009). (Article 6).

[21] E. Damaggio, A. Deutsch, R. Hull, V. Vianu, Automatic verification ofdata-centric business processes, Bus. Process Manag. 6896 (2011)3–16. (LNCS).

[22] Damaggio, E., Deutsch, A., Vianu, V., Artifact systems with datadependencies and arithmetic constraints, in: Proceedings of theInternational Conference on Database Theory (ICDT), 2011b,pp. 66–77.

[23] E. Damaggio, R. Hull, R. Vaculin, On the equivalence of incrementaland fixpoint semantics for business artifacts with guard-stage-milestone lifecycles, Bus. Process Manag. 6896 (2011) 396–412.(LNCS).

[24] Decker, G., Weske, M., Behavioral consistency for B2B processintegration, in: Proceedings of CAiSE, LNCS, vol. 4495, 2007,pp. 81–95.

[25] Deutsch, A., Hull, R., Patrizi, F., Vianu, V., Automatic verification ofdata-centric business processes. in: Proceedings of the InternationalConference on Database Theory (ICDT), 2009, pp. 252–267.

[26] R. Eshuis, R. Hull, Y. Sun, R. Vaculin, Splitting GSM schemas: aframework for outsourcing of declarative artifact systems, Bus.Process Manag. 8094 (2013) 259–274. (LNCS).

[27] Eshuis, R., Vonk, J., Grefen, P., Transactional process views, in: OTM,Part I, LNCS, vol. 7044, 2011, pp. 119–136.

[28] D. Fahland, M.D. Leoni, B.F. van Dongen, W.M.P. van der Aalst,Conformance checking of interacting processes with overlappinginstances, Bus. Process Manag. 6896 (2011) 345–361. (LNCS).

[29] Fritz, C., Hull, R., Su, J., Automatic construction of simple artifact-based business processes. in: Proceedings of the InternationalConference on Database Theory (ICDT), ACM, vol. 361, 2009,pp. 225–238.

[30] C.E. Gerede, K. Bhattacharya, Static analysis of business artifact-centric operational models, in: Proceedings of the IEEE InternationalConference on Service-Oriented Computing and Applications(SOCA'07), 2007, pp. 133–140.

[31] C.E. Gerede, Su, J., Specification and Verification of artifact beha-viours in business process models, in: Proceedings of the Interna-tional Conference on Service-Oriented Computing 2007, LNCS,pp. 181–192.

[32] J. Ghattas, P. Soffer, Evaluation of inter-organizational businessprocess solutions: a conceptual model-based approach, Inf. Syst.Front. (2009) 273–29111 (2009) 273–291.

[33] D. Harel, O. Kupferman, On object systems and behavioral inheri-tance, IEEE Trans Softw. Eng. 28 (9) (2002) 889–903.

[34] R. Hull, Artifact-centric business process models: brief survey ofresearch results and challenges, in: On the Move to MeaningfulInternet Systems (OTM), 2008, pp. 1152–1163.

[35] R. Hull, E. Damaggio, F. Fournier, M. Gupta, F. Heath, S. Hobson,M. Linehan, S. Maradugu, A. Nigam, P. Sukaviriya, R. Vaculin,Introducing the guard-stage-milestone approach for specifyingbusiness entity lifecycles, in: WS–FM, LNCS, vol. 6551, 2010,pp. 1–24.

[36] R. Hull, E. Damaggio, R.D. Masellis, F. Fournier, M. Gupta, F. Heath, S.Hobson, M. Linehan, S. Maradugu, A. Nigam, P. Sukaviriya,R. Vaculin, Business artifacts with guard-stage-milestone lifecycles:managing artifact interactions with conditions and events, in:Proceedings of the Fifth ACM International Conference on Distrib-uted Event-Based Systems (DEBS), 2011, pp. 51–62.

[37] R. Hull, N.C. Narendra, and A. Nigam, Facilitating workflow inter-operation using artifact-centric hubs, in: Proceedings of the Inter-national Conference on Service-Oriented Computing—ServiceWave,2009, pp. 1–18.

[38] R., Hull, J. Su, Report on NSF Workshop on Data-Centric Workflows,2012, ⟨http://dcw2009.cs.ucsb.edu/report.pdf⟩.

http://refhub.elsevier.com/S0306-4379(14)00126-4/sbref1




http://acsi-project.eu/
































































http://dcw2009.cs.ucsb.edu/report.pdf


[39] R. Hull, J. Su, R. Vaculin, Data management perspectives onbusiness process management, in: Proceedings of SIGMOD, 2013,pp. 943–947.

[40] P. Jiang, X. Shao, L. Gao, H. Qiu, P. Li, A process-view approach forcross-organizational workflows management, Adv. Eng. Inform. 24(2010) 229–240.

[41] JUNG (Java Universal Network/Graph Framework), version 2.0.1,2010, ⟨http://jung.sourceforge.net⟩.

[42] K. Klai, S. Tata, J. Desel, Symbolic abstraction and deadlock-freenessverification of inter-enterprise processes, Data Knowl. Eng. 70(2011) 467–482.

[43] E. Kucukoguz, J. Su, On lifecycle constraints of artifact-centricWorkflows, in: WS–FM, LNCS, vol. 6551, 2010, pp. 71–85.

[44] S. Kumaran, R. Liu, F.Y. Wu, On the duality of information-centricand activity-centric models of business processes, In: Proceedings ofCAiSE, LNCS, vol. 5074, 2008, pp. 32–47.

[45] V. Künzle, M. Reichert, Philharmonic flows: towards a frameworkfor object aware process management, J. Softw. Maint. Evol.: Res.Pract. 13 (4) (2011) 205–244.

[46] J. Küster, K. Ryndina, H. Gall, Generation of business process modelsfor object life cycle compliance, Bus. Process Manag. 4714 (2007)165–181.

[47] D. Li, Q. Wu, Translating artifact-based business process model toBPEL, Adv. Comput. Sci., Environ., Ecoinform. Educ. 215 (2011)482–489.

[48] D. Lin, Compatibility analysis of local process views in interorgani-zational workflow, in: Proceedings of the 9th IEEE InternationalConference on E-Commerce Technology and the 4th IEEE Interna-tional Conference on Enterprise Computing, E-Commerce andE-Services (CEC-EEE), 2007, pp. 149–156.

[49] J. Lind-Nielsen, H. Andersen, H. Hulgaard, G. Behrmann,K. Kristoffersen, K. Larsen, Verification of large state/event systemsusing compositionality and dependency analysis, Form. MethodsSyst. Des. 18 (1) (2001) 5–23.

[50] C. Liu, Q. Li, X. Zhao, Challenges and opportunities in collaborativebusiness process management, Inf. Syst. Front. (2008) 21.

[51] D. Liu, M. Shen, Workflow modelling for virtual processes: an order-preserving process-view approach, Inf. Syst. 28 (6) (2003) 505–532.

[52] D. Liu, M. Shen, Business-to-business workflow interoperationbased on process-views, Decis Support Syst. 38 (2004) 399–419.

[53] G. Liu, X. Liu, H. Qin, J. Su, Z. Yan, L. Zhang, Automated realization ofbusiness workflow specification, in: A. Dan, F. Gittler, F. Toumani(Eds.), ICSOC/ServiceWave, LNCS, vol. 6275, Springer, Heidelberg,2009,pp. 96–108in: A. Dan, F. Gittler, F. Toumani (Eds.), ICSOC/Service-Wave, LNCS, vol. 6275, Springer, Heidelberg, 2010, pp. 96–108.

[54] Liu, R., Bhattacharya, K., Wu, F.Y., Modeling business contexture andbehavior using business artifacts, in: Proceedings of CAiSE, 2007,pp. 324–339.

[55] R. Liu, R. Vaculín, Z. Shan, A. Nigam, F. Wu, Business artifact-centricmodeling for real-time performance monitoring, in: S. Rinderle-Ma,F. Toumani, K. Wolf (Eds.), BPM, LNCS, vol. 6896, Springer, Heidelberg,2011, pp. 265–280in: S. Rinderle-Ma, F. Toumani, K. Wolf (Eds.),BPM, LNCS, vol. 6896, Springer, Heidelberg, 2011, pp. 265–280.

[56] N. Lohmann, Compliance by design for artifact-centric businessprocesses, Bus. Process Manag. 696 (2011) 99–115. (LNCS).

[57] Lohmann, N., Massuthe, P., Wolf, K., Operating guidelines for finite-state services, in: Proceedings of the ICATPN, LNCS, vol. 4546, 2007,pp. 321–341.

[58] Lohmann, N., Wolf, K., Artifact-centric choreographies, in: Proceed-ings of the International Conference on Service-Oriented Comput-ing, LNCS, vol. 6470, 2010, pp. 32–46.

[59] Maamar, Z., Badr, Y., Narendra, N.C., Business artifacts discovery andmodeling, in: Proceedings of the International Conference onService-Oriented Computing, LNCS, vol. 6470, 2010, pp. 542–550.

[60] Marinoiu, B., Abiteboul, S., Bourhis, P., Galland, A., AXART—Enablingcollaborative work with AXML artifacts, in: Proceedings of the VLDBEndowment, vol. 3, issue no. 2, 2010, pp. 1153–1156.

[61] Massuthe, P., Schmidt, K., Operating guidelines—an automata-theoretic Foundation for the service-oriented architecture, in: Pro-ceedings of the Fifth International Conference on Quality Software(QSIC’05), 2005, pp. 452–457.

[62] A.K.A.D Medeiros, W.M.P. van Der Aalst, A.J.M.M. Weijters, Quantify-ing process equivalence based on observed behavior, Data Knowl.Eng. 64 (2008) 55–74.

[63] M. Montali, M. Pesic, W.M.P. van der Aalst, F. Chesani, P. Mello,S. Storari, Declarative specification and verification of servicechoreographies, ACM Trans. Web 4 (1) (2010). (Article 3).

[64] Müller, D., Reichert, M., Herbst, J., A new paradigm for the enact-ment and dynamic adaptation of data-driven process structures, in:Proceedings of the CAiSE, LNCS, vol. 5074, 2008, pp. 48–63.

[65] Nandi, P., Kumaran, S., Adaptive business objects—a new componentmodel for business integration, in: Proceedings of the InternationalConference on Enterprise Information Systems, 2005, pp. 179–188.

[66] Narendra, N.C., Badr, Y., Thiran, P., Maamar, Z., Towards a unifiedapproach for business process modeling using context-based arti-facts and web services, in: Proceedings of the IEEE SCC, 2009,pp. 332–339.

[67] Ngamakeur, K., Yongchareon, S., Liu, C., A framework for realizingartifact-centric business processes in service-oriented architecture,in: Proceedings of DASFAA, LNCS, vol. 7238, 2012, pp. 63–78.

[68] A. Nigam, N.S. Caswell, Business artifacts: an approach to opera-tional specification, IBM Syst. J. 42 (3) (2003) 428–445.

[69] Object Management Group (OMG), Semantics of Business Vocabu-lary and Business Rules (SBVR), Version 1.0., January 2008.

[70] C. Ouyang, M. Dumas, W.M.P. Van Der Aalst, A.H.M. ter Hofstede,J. Mendling, From business process models to process-orientedsoftware systems, ACM Trans. Softw. Eng. Methodol. 19 (1) (2009).(article 2).

[71] OWL Services Coalition, OWL-S, Semantic markup for web services,2003.

[72] G. Redding, M. Dumas, A.H.M. ter Hofstede, A. Iordachescu, Gen-erating business process models from object behavior models, Inf.Syst. Manag. 25 (4) (2008) 319–331.

[73] Redding, G., Dumas, M., ter Hofstede, A.H.M., Iordachescu, A.,Modelling flexible processes with business objects, in: Proceedingsof the IEEE Conference on Commerce and Enterprise Computing(CEC), 2009, pp. 41–48.

[74] G. Redding, M. Dumas, A.H.M. ter Hofstede, A. Iordachescu, Aflexible, object-centric approach for business process modeling,Serv. Oriented Comput. Appl. 4 (2010) 191–201.

[75] M. Schrefl, M. Stumptner, Behavior–consistent specialization ofobject life cycles, ACM Trans. Softw. Eng. Methodol. 11 (1) (2002)92–148.

[76] H. Schuldt, G. Alonso, C. Beeri, H.-J. Schek, Atomicity and isolationfor transactional processes, ACM Trans. Database Syst. 27 (1) (2002)63–116.

[77] K.A. Schulz, M.E. Orlowska, Facilitating cross-organisational work-flows with a workflow view approach, Data Knowl. Eng. 51 (2004)109–147.

[78] J.K. Strosnider, P. Nandi, S. Kumarn, S. Ghosh, A. Arsanjani, Model-driven synthesis of SOA solutions, IBM Syst. J. 47 (3) (2008) 415–432.

[79] Sun, Y., Zu, W., Su, J., Declarative choreographies for artifacts, in:Proceedings of the International Conference on Service-OrientedComputing, LNCS, vol. 7636, 2012, pp. 420–434.

[80] Vaculin, R., Hull, R., Heath, T., Cochran, C., Nigam, A., Sukaviriya, P.,Declarative business artifact centric modeling of decision andknowledge intensive business processes, in: Proceedings of the15th IEEE International Enterprise Distributed Object ComputingConference (EDOC), August 29–September 2, 2011, pp. 151–160.

[81] W.M.P. van der Aalst, T. Basten, Inheritance of workflows: anapproach to tackling problems related to change, Theor. Comput.Sci. 270 (2002) 125–203.

[82] van der Aalst, W.M.P., Lohmann, N., Massuthe, P., Stahl, C., Wolf, K.,From public views to private views—correctness-by-design forservices, in: WS-FM, LNCS, vol. 4937, 2007, pp. 139–153.

[83] W.M.P. van der Aalst, N. Lohmann, P. Masuthe, C. Stahl, K. Wolf,Multipart contracts: agreeing and implementing interorganizationalprocesses, Comput. J. 53 (1) (2010) 90–106.

[84] van der Aalst, W.M.P., Pesic, M., DecSerFlow: towards a trulydeclarative service flow language, in: WS-FM, LNCS, vol. 4184,2006, pp. 1–23.

[85] van der Aalst, W.M.P., Weske, M., The P2P approach to interorgani-zational workflows, in Proceedings of the CAiSE, LNCS, vol. 2068,2001, pp. 140–156.

[86] W.M.P. van der Aalst, M. Weske, D. Grünbauer, Case handling: a newparadigm for business process support, Data Knowl. Eng. 53 (2)(2005) 129–162.

[87] van dongen, B., Dijkman, R., Mendling, J., Measuring similaritybetween business process models, in: Proceedings of the CAiSE,LNCS, vol. 5074, 2008, pp. 450–464.

[88] J. Wang, A. Kumar, A framework for document-driven workflowsystems, Bus. Process Manag. 3649 (2005) 285–301. (LNCS).

[89] M. Weidlich, R. Dijkman, M. Weske, Deciding behaviour compat-ibility of complex correspondences between process models, Bus.Process Manag. 6336 (2010) 78–94. (LNCS).




http://jung.sourceforge.net
















































































[90] M. Weidlich, J. Mendling, M. Weske, Efficient consistency measure-ment based on behavioral profiles of process models, IEEE Trans.Softw. Eng. 37 (3) (2011) 410–429.

[91] Xu, W., Su, J., Yan, Z., Yang, J., Zhang, L., An artifact-centric approachto dynamic modification of workflow execution, in: OTM, Part I,LNCS, vol. 7044, 2011, pp. 256–273.

[92] C. Ye, S.-C. Cheung, W.K. Chan, C. Xu, Atomicity analysis of servicecomposition across organizations, IEEE Trans. Softw. Eng. 35 (1)(2009) 2–28.

[93] Yongchareon S., Artifact-M: an artifact-centric business processmodeling and analysis tool, version 1.0, 2013, ⟨https://sites.google.com/site/maxsirayongchareon/artifact-m⟩.

[94] Yongchareon, S., Liu, C., Process view framework for artifact-centricbusiness processes, in: OTM Proceedings of the CoopIS, Part I, LNCS,vol. 6426, 2010, pp. 26–43.

[95] Yongchareon, S., Liu, C., Zhao, X., An artifact-centric view-basedapproach to modeling inter-organizational business processes, in:Proceedings of WISE, LNCS, vol. 6997, 2011, pp. 273–281.

[96] S. Yongchareon, C. Liu, X. Zhao, A framework for behavior-consistentspecialization of artifact-centric business processes, Bus. ProcessManag. 7481 (2012) 285–301. (LNCS).

[97] Yongchareon, S., Liu, C., Zhao, X., Kowalkiewicz, M., BPMN processviews construction, in: Proceedings of DASFAA, Part I, LNCS, vol.5981, 2010, pp. 550–564.

[98] Yongchareon, S., Liu, C., Zhao, X., Xu, J., An artifact-centric approachto generating web-based business process driven user interfaces, in:Proceedings of WISE 2010, LNCS, vol 6488, pp.419–427.

[99] X. Zhao, C. Liu, Tracking over collaborative business processes, in:S. Dustdar, J. Fiadeiro, A. Sheth (Eds.), BPM LNCS, vol. 4102, Springer,Heidelberg, 2006, pp. 33–48in: S. Dustdar, J. Fiadeiro, A. Sheth (Eds.),BPM LNCS, vol. 4102, Springer, Heidelberg, 2006, pp. 33–48.

[100] Zhao, X., Liu, C., Sadiq, W., and Kowalkiewicz, M., Process viewderivation and composition in a dynamic collaboration environ-ment, in: Proceedings of CoopIS, 2008, pp. 82–99.

[101] X. Zhao, C. Liu, W. Sadiq, M. Kowalkiewicz, S. Yongchareon, Imple-menting process views in the web service environment, WorldWideWeb 14 (1) (2011) 27–52.

[102] X. Zhao, C. Liu, Y. Yang, W. Sadiq, Aligning collaborative businessprocesses—an organisation-oriented perspective, IEEE Trans. Syst.,Man, Cybern. (TSMC)—Part A 39 (6) (2009) 1152–1164.

[103] Zhao, X., Su, J., Yang, H., Qiu, Z., Enforcing constraints on life cycles ofbusiness artifacts, in: Proceedings of the Third IEEE InternationalSymposium on Theoretical Aspects of Software Engineering, 2009,pp. 111–118.




















