1 / 22

Static Analysis of Business Artifact-centric Operational Models

Static Analysis of Business Artifact-centric Operational Models. Presented by Cagdas Gerede Cagdas Gerede 1 , Kamal Bhattacharya 2 , Jianwen Su 1 1: University of California Santa Barbara 2: IBM T.J. Watson Research Center. Typical Approaches for Business Process Modeling.

lukas
Download Presentation

Static Analysis of Business Artifact-centric Operational Models

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Static Analysis of Business Artifact-centric Operational Models Presented by Cagdas Gerede Cagdas Gerede1, Kamal Bhattacharya2, Jianwen Su1 1: University of California Santa Barbara2: IBM T.J. Watson Research Center

  2. Typical Approaches for Business Process Modeling • Characteristics:[Leymann99, Aalst-JCSC98, Jackson97,Morrison94] • Process-centric: Focus on control and coordination of tasks • Ignore the informational perspective or treat it only within the context of single activities • Case-driven and cases are logically independent • Problems • Lack of flexibility [Wang,Kumar-BPM05], [Aalst et al-DKE05], … • Hard to deal with changes[Casati et al-ER96], [Aalst et al-CSSE00], [Weske et al-HICSS01], … • Integration efforts are hindered [Bhattacharya-07]

  3. Artifact-centric Business Process Modeling • Developed by IBM Research [NigamCaswell-IBMSJ03], [Bhattacharya et al-BPM07], [Liu et al- CAiSE07]… • Centered on Business Artifacts: data objects that capture key information pertinent to business context • Focus on life-cycles of business artifacts • Similarities with data flow diagramming [DeMarco78], flow-based programming [Morrison94] • Applied in practice successfully Insurance, Manufacturing, Pharmaceutical Industries [Bhattacharya et al - IBMSJ05]

  4. Example: High Tech Restaurant Guest Check Kitchen Order Receipt Cash Balance Artifacts Guest Check customerName tableNo paymentDate … data Pending Active Canceled states Payment Completed

  5. Example: High Tech Restaurant Create Add Item Open Guest Check Cash Balance Kitchen Order Receipt Guest Check GCs Pending KOs Prepare & Pending Closed Receipts Test Quality GCs Ready KOs Paid Receipts Deliver Disagreed Receipts Cash Archived Archived Balance Receipts GCs Archived KOs Artifacts

  6. Example: High Tech Restaurant Create Add Item Open Guest Check Cash Balance Receipt RC Guest Check CB Kitchen Order KO GC GCs Prepare Pending Receipt KOs Prepare & Pending Closed Receipts Test Quality GCs Ready Payment Update KOs Paid Cash Balance Receipts Deliver Disagreed Receipts Cash Archived Archived Recalculate Balance Receipts GCs Archived Receipt KOs Artifacts

  7. Example: High Tech Restaurant GC GC Create Add Item Open Guest Check GCs KO Prepare GC KO Pending Receipt KOs RC GC GC KO Prepare & Pending Closed Receipts Test Quality GCs RC GC KO RC Ready Payment RC Update KOs RC Paid Cash Balance Receipts KO RC CB RC GC Deliver Disagreed Receipts KO RC Archived Archived Cash Receipts GCs Balance Recalculate Archived KOs Receipt

  8. Revisit: life cycle properties or Paid Receipts Paid Receipts Receipt Receipt Disagreed Receipts Disagreed Receipts • Location Uniqueness: An artifact should appear only in one location • Persistence: An artifact should never be lost • Arrival: Can an artifact arrive into a repository? Open GuestChecks Archived Guest Checks Guest Check

  9. Related Work • Emphasis on Data Design as well as Control Flow Design • Document Driven Workflow Systems [Wang,Kumar-BPM05] • Case Handling [Aalst et al-DKE05] • Vortex [Hull et al-WACC99], [Fu et al-TACAS01] • INSYDE [King,McLeod-TOIS85], TAXIS[Mylopoulos et al-TODS80], … • Constraints on Life-cycles of Objects • Object Migration [Su-TCS97] • Object Histories [Ginsburg,Tanaka-TODS86] • Object Constraint Language • …

  10. Remainder of the Talk • Formalization of Artifact-centric Business Process Models • Artifacts • Tasks • Operational Models • Analysis of Properties • Location Uniqueness • Persistence • Arrival • Conclusions

  11. Artifact GC Create Open Guest Check GCs Guest Check • An artifact • attributes, • methods, • states • Similar to object-oriented classes augmented with states • Typestate [StromYemini-TSE86] • Method schemas [Abiteboul et al–PODS90] • Method structures [Hull et al–FODO88] • UML OCL, Alloy [Jackson-TOSEM02] customerName tableNo paymentDate data Receipt Order references addOrder(…) setPaymentDate(…) methods Pending addOrder Active Canceled setCancelDate states receiptRequest Payment Completed setPaymentDate

  12. Task KO R1.checkOut(order) reset read(approvedDate) order.setApproved(approvedDate) R2.checkIn(order) ApproveKO Live Orders • A task describes the actions performed on artifacts • has a set of variables • has a guarded state machine • Artifact creation • Artifact check out / check in • Read/Update artifact data via artifact methods • Read from external environment R1Pending Orders R2Live Orders

  13. Operational Model GC GC Create Add Item Open Guest Check GCs KO Prepare GC KO Pending Receipt KOs RC GC GC KO Prepare & Pending Closed Receipts Test Quality GCs RC GC KO RC Ready Payment RC Update RC KOs Paid Cash Balance Receipts KO RC CB RC GC Deliver Disagreed Receipts KO RC Archived Archived Cash Receipts GCs Balance Recalculate Archived KOs Receipt • Operational Model O = (A, R, T) • A: set of artifact types • R: set of repositories • T: set of task types

  14. Semantics • Configuration • A configuration is derivable from another configuration if … • Execution graph of an operational model and a root configuration is a Kripke structure

  15. Location Uniqueness, Persistence • Formalism guarantees location uniqueness and persistence • Location Uniqueness: • Artifact cannot be • checked out by two tasks • checked in two repositories • duplicated • Persistence • An artifact can not be • deleted • overwritten

  16. Checking Arrival C1 Open GuestChecks … C3 C2 … … C4 … … … Ci Archived GuestChecks … • Reachability on execution graph • Example: Does a guest check arrive at the archived guest checks repository?

  17. Arrival is not decidable Theorem: It is not decidable to check if an artifact can arrive into a repository R for an operational model O and a root configuration of O. But …

  18. without Artifact Creation? • Observation • Size of execution graph: Infinite • Domains are infinite • Tasks can read values from infinite domains • Finite abstraction of infinite space • Define an equivalence relation among configurations (similar to region approach [Alur-99])

  19. Abstraction 4 5 4 5 Abstraction 11 5 • Example: - only constant appears in the specification is 10- two scalar variables: cost, amount 14 5 amount cost 11 5 12 5 13 5 … Equivalence class: cost < 10 < amount

  20. Decidable Fragment Theorem: It is decidable to check if an artifact can arrive into a repository R for an operational model O without new artifact creation, and a root configuration of O.

  21. Conclusions • Preliminary results on life cycle properties of business artifacts • Many interesting questions: • More declarative model • Automatic Towards Formal Analysis of Artifact-Centric Business Process Models [Bhattacharya et. al. BPM 2007] • A language for specifying artifact life-cycle properties • Specification and Verification of Artifact Behaviors in Business Process Models [Gerede-07] • Multi-artifact interactions • Automated design and tools • Evolution of models (business rules)

  22. Thanks Questions and Comments

More Related