advertisement

Sadiq

50 %
50 %
advertisement
Information about Sadiq
Education

Published on May 8, 2008

Author: Heather

Source: authorstream.com

advertisement

Modeling Control Objectives for Business Process Compliance:  Modeling Control Objectives for Business Process Compliance Shazia Sadiq, Guido Governatori, Kioumars Naimiri1 School of Information Technology & Electrical Engineering Brisbane, Australia Telephone (61-7) 3365 3984, Facsimile (61-7) 3365 4999 shazia@itee.uq.edu.au www.itee.uq.edu.au 1SAP Research Centre CEC Karlsruhe, SAP AG, Vincenz-Prießnitz-Str.1 76131 Karlsruhe, Germany kioumars.namiri@sap.cpm What is Compliance:  What is Compliance Regulatory Basel II Sarbanes-Oxley OFAC (USA Patriot Act) OSFI “blocked entity” lists HIPAA Graham-Leach-Bliley Standards Best practice models SAP solution maps ISO 9000 Medical guidelines Contracts Service Agreement Customer Contract Warranty Insurance Policy Business Partnership A consequence of non-compliance?:  A consequence of non-compliance? Acknowledgements: Prof. Michael Ward, School of Medicine, UQ Compliance Examples from Healthcare:  Compliance Examples from Healthcare In patient processes  Data completeness compliance Pathology product distribution  Time compliance General practice  Data protection compliance Acute disease management  Monitoring compliance Outsourcing  Blocked entities compliance Post-op care  Medical guidelines compliance - Scope of Consideration - Evidence of Compliance can be found (or created) in IT Systems! Compliance Pipeline:  Compliance Pipeline Internal (Governance) or External (Regulations/Standards/Contracts) generate compliance requirements Consultants define Control Objectives to fulfill compliance obligations Control Objectives analyzed in terms of risk and necessary internal controls required for “effective and efficient” implementation of control objectives Proposed internal controls are built into business processes / transactions Operational practices are monitored for deviation from prescribed internal controls e.g. prevent unauthorized use of purchase order process e.g. unauthorized creation of purchase orders and payments to non-existing suppliers e.g. the creation and approval of purchase orders must be undertaken by two separate purchase officers Compliance by Design Detection of non-compliance Holistic Compliance Regimen A Methodology for Compliance by Design:  A Methodology for Compliance by Design Controls Directory Management Ontological Alignment Modeling Control Objectives Process Model Enrichment Event Monitoring Methodology:  Methodology Controls Directory Management Ontological Alignment Modeling Control Objectives Process Model Enrichment Event Monitoring Methodology:  Methodology Controls Directory Management Ontological Alignment Modeling Control Objectives Process Model Enrichment Event Monitoring Methodology:  Methodology Controls Directory Management Ontological Alignment Modeling Control Objectives Process Model Enrichment Event Monitoring Formal language based on deontic logic to represent and analyze normative positions stemming from compliance requirements Methodology:  Methodology Controls Directory Management Ontological Alignment Modeling Control Objectives Process Model Enrichment Event Monitoring purchase-to-pay scenario Process Model Enrichment through Control Tags:  Process Model Enrichment through Control Tags Control Tags provide a means of annotating control objectives (and constituent internal controls) on a business process model, thus providing a clear separation from business objectives Flow Tag: A flow tag represents a control objective that would impact on (the flow of) the business activities, e.g. approval of leave must occur before payment for travel. Data Tag: A data tag identifies the data retention and lineage requirements, e.g. a medical practice must retain the time of commencement of pathology tests. Resource Tag: A resource tag represents controls relating to access, role management and authorization, e.g. persons performing cash application and bank reconciliation must be different as it allows differences between cash deposited and cash collections posted to be covered up. Time Tag: A time tag identifies controls for meeting time constraints such as deadlines and maximum durations, e.g. a water leakage complaint must be investigated within 12 hours of lodging. Process Model Enrichment tag identification:  Process Model Enrichment tag identification Process Model Enrichment tag visualization:  Process Model Enrichment tag visualization Methodology:  Methodology Controls Directory Management Ontological Alignment Modeling Control Objectives Process Model Enrichment Event Monitoring complete implementation of the BPM lifecycle may not exist deviations may exist even in the presence of compliance aware process designs Operational practices are monitored for deviation from prescribed internal controls Ref: Compliance Pipeline Summary:  Summary What next?:  What next? Analysis of enriched process models Creation of tag views What next?:  What next? Analysis of enriched process models Measurement of compliance distance Formal Contract Language (FCL) :  Formal Contract Language (FCL) Compliance is a relationship between processes and “normative/regulatory” documents/specifications FCL is a combination of an efficient non-monotonic formalism and a deontic logic of violations offering the right trade off between expressive power and computational complexity. The aim of FCL is to capture and reason with the normative notions needed to capture, model and implement processes. Deontic logic of violation to reason with obligations, permissions, prohibitions, violations (and reparations) Non-monotonic logic (Defeasible logic) to express normative exceptions FCL Basics:  FCL Basics FCL is a rule based formalism FCL expressions (rules) are built from ¬ (negation), O (obligation) P (permission) and  (violation operator) r: A1, …, An  O B1  O B2  …  O Bm Violation/reparation chains GoodShipmentNotice  OsSendGood1Day  OsRefund2days  PpChargePenalty Expressing exceptions r: surgery  O consent s: emergency, unconscious  P ¬ consent s > r FCL Reasoning Phases:  FCL Reasoning Phases Merging normative clauses Making implicit conditions explicit Remove redundancies Detect conflicts Derive conclusions FCL Tools (prototype):  FCL Tools (prototype) Integrated rule editor and engine (the engine can handle 100.000+ rules) What next?:  What next? Empirical testings for FCL Pilot study based on FDA process for IND – Investigational New Drug Application Coversheet Encoding of Clause 67 of FIDIC (Project Contract Management Standard) Related Publications:  Related Publications Process Variance as a Corporate Resource Ruopeng Lu and Shazia Sadiq (2007)  On the Discovery of Preferred Work Practice through Business Process Variants. 26th International Conference on Conceptual Modeling (ER 2007) Nov 05-09, 2007. Auckland, New Zealand. Ruopeng Lu, Shazia Sadiq (2006) Managing Process Variants as an Information Resource.  4th International Conference on Business Process Management (BPM2006), Vienna, Austria, 2006 Ruopeng Lu, Shazia Sadiq, Guido Governatori (2006) Utilizing Successful Work Practice for Business Process Evolution. 9th International Conference on Business Information Systems (BIS2006), Klagenfurt, Austria, May 31 -June 22, 2006   Shazia Sadiq, Wasim Sadiq, Maria Orlowska (2005) A Framework for Constraint Specification and Validation in Flexible Workflows. Information Systems Volume 30, Issue 5, July 2005. Process Data Quality Shazia Sadiq, Xiaofang Zhou, Maria Orlowska (2007) Data Quality – The Key Success Factor for Data Driven Engineering. In Frontiers of Data Driven Engineering (FDDE2007) at IFIP International Conference on Network and Parallel Computing. Sep 18-21, 2007. Dalian, China.  Shazia Sadiq, Maria Orlowska, Wasim Sadiq (2007) Induction of Data Quality Protocols into Business Process Management. Proceedings of the 9th International Conference on Enterprise Information Systems (ICEIS2007), Funchal-Madeira, Portugal. Shazia Sadiq, Maria Orlowska, Wasim Sadiq, Cameron Foulger (2004) Data Flow and Validation in Workflow Modeling. The Fifteenth Australasian Database Conference Dunedin, New Zealand, January 18 -- 22, 2004. Ruopeng Lu, Shazia Sadiq, Guido Governatori (2007) Compliance Aware Business Process Design. 3rd International Workshop on Business Process Design (BPD'07). In conjunction with the 5th International Conference on Business Process Management, 24-28 September 2007. Brisbane Australia. Shazia Sadiq, Guido Governatori, Kioumars Namiri (2007) Modeling Control Objectives for Business Process Compliance. 5th International Conference on Business Process Management, 24-28 September 2007. Brisbane Australia. Guido Governatori, Zoran Milosevic, Shazia Sadiq (2006),  Compliance checking between business processes and business contracts,  Proc. The 10th IEEE Conference on Enterprise Distributed Object Computing (EDOC2006), Hong Kong, 16-20 Oct 2006. Miao Wang and Guido Governatori (2007). A Logic Framework of Normative-based Contract Management. Formal Methods in Electronic Commerce 2007. Stanford University, Palo Alto, CA. June 4, 2007. Vineet Padmanabhan, Guido Governatori, Shazia Sadiq, Robert Colomb and Antonino Rotolo. Process Modelling: The Deontic Way. In Markus Stumptner, Sven Hartmann and Yasushi Kiyoki, editors, Database Technology 2006, CRPIT 53. Australian Computer Science Association, ACS, 16-19 January 2006. Zoran Milosevic, Shazia Sadiq, Maria Orlowska (2006) On Deriving Process Models from Business Contracts. 4th International Conference on Business Process Management (BPM2006), Vienna, Austria, 2006 Zoran Milosevic, Maria Orlowska, Shazia Sadiq (2006) Linking contracts, processes and services: an event-driven approach. IEEE International Conference on Services Computing. SCC 2006, Chicago, USA. Sep 2006. Generation of Business Process Models for Object Life Cycle Compliance:  Generation of Business Process Models for Object Life Cycle Compliance Jochen M. Küster Ksenia Ryndina Harald Gall (University of Zurich) 5th International Conference on Business Process Management September 2007 Presentation outline:  Presentation outline Problem statement Object life cycles are used to standardize object behavior Business processes are required to be compliant with object life cycles Q1: When is a process compliant with a given object life cycle? Q2: How can we achieve compliance? Tool support and validation Conclusion and outlook Object flow in business process models:  Object flow in business process models A business process model captures: coordination of tasks performed to achieve a business goal flow of data as objects exchanged between tasks evaluate claim notify refusal Process model for Claim Handling process make payment close claim receive claim granted rejected UML2 Activity Diagram Objects and object life cycles:  Objects and object life cycles An object or a business object is a discrete entity that plays a role in business processes of an organization Objects can be associated with a number of distinct states Objects and their states are standardized using data reference models, such as ACORD in insurance Object life cycles model allowed state transitions, initial and final states Reference object life cycles represent an established way of manipulating objects in a particular industry, e.g. IBM Insurance Application Architecture Problem statement:  Problem statement Compliance with reference object life cycles is required to ensure: consistency within processes of one organization interoperability between industry partners for correct execution of processes that span several organizations compliance with policy requirements, such as legal regulation, embodied in reference object life cycles Q1: When is a process compliant with a given object life cycle? Q2: How can we achieve compliance? compliance Presentation outline:  Presentation outline Problem statement Object life cycles are used to standardize object behavior Business processes are required to be compliant with object life cycles Q1: When is a process compliant with a given object life cycle? Object life cycle compliance notions Q2: How can we achieve compliance? Tool support and validation Conclusion and outlook Q1: Object life cycle compliance:  evaluate claim notify refusal Process model for Claim Handling process [granted, rejected] [granted] [rejected] [rejected] [granted, rejected] [paid in full, aborted] [granted, rejected, cancelled] [closed] [granted] [rejected] [registered] [registered] Induced transitions: registered to granted and registered to rejected Induced transitions: granted to rejected make payment close claim receive claim Q1: Object life cycle compliance Induced transitions: granted to closed and rejected to closed Last states: closed and rejected, paid in full and aborted First state: registered First states: paid in full and aborted Q1: Object life cycle compliance:  Conformance: all induced transitions, first states and last states in process model have corresponding elements in object life cycle Coverage: all transitions, target states of initial transitions and final states in object life cycle must have corresponding elements in process model Q1: Object life cycle compliance registered granted rejected settled closed register settle close close grant reject Induced transition: rejected to closed Induced transition: granted to rejected Last state: rejected Q2: Approaches to achieving compliance:  Q2: Approaches to achieving compliance 2. Resolution of violations 1. Compliance checking 1. Process model generation 2. Customization 3. Compliance checking 4. Resolution of violations Presentation outline:  Presentation outline Problem statement Q1: When is a process compliant with a given object life cycle? Object life cycle compliance definition Q2: How can we achieve compliance? Generation of process models from object life cycles Tool support and validation Conclusion and outlook Generation from one object life cycle:  For each event labeling a state transition in object life cycle, a task is generated with appropriate input/output pins and object states Order of tasks is based on matching input/output object states Control nodes are added for correct control flow Conformance and coverage are ensured Generation from one object life cycle Generation from a set of object life cycles:  Generation from a set of object life cycles synchronization Identification of synchronization events (manual step) Composition of object life cycles Process model generation: Task generation Object state relation for tasks Process fragment generation Connection of process fragments 1. Identification of synchronization events:  1. Identification of synchronization events A synchronization event is an event that triggers state transitions in more than one object life cycle Identifying synchronization events is necessary given several object life cycles, to ensure that invalid composite states cannot be reached created authorized refused paid in full partially paid create pay all pay all authorize refuse stopped pay installment stop stop pay installment I2 Object life cycle for Payment object type registered granted rejected settled closed Object life cycle for Claim object type register settle close close grant reject I1 grantC | createP grantC | createP settleC | pay allP settleC | pay allP settleC | pay allP 2. Composition of object life cycles:  2. Composition of object life cycles registerC (I1C,I2P) registeredC I2P rejectedC I2P closedC I2P grantedC createdP grantedC refusedP grantedC authorizedP grantedC stoppedP grantedC partially paidP settledC paid in fullP closedC paid in fullP rejectC closeC grantC | createP refuseP authorizeP stopP settleC | pay allP settleC | pay allP stopP closeC pay installmentP pay installmentP closedC refusedP closedC stoppedP 3. Process model generation:  3. Process model generation Transition and first state conformance with respect to both object life cycles are satisfied, but last state conformance is not All coverage conditions are satisfied here, but this is not guaranteed rejectC closeC refuseP stopP settleC | pay allP registerC grantC | createP authorizeP pay installmentP Tool support and validation:  Tool support and validation Our prototype extends IBM WebSphere Business Modeler: conformance and coverage checking generation of a process model from one or several object life cycles semi-automatic resolution of selected compliance violations extraction of object life cycles from a process model Come to tomorrow’s Demo Session for a live demo… Initial validation performed with IBM Insurance Application Architecture reference models Conclusion and outlook:  Conclusion and outlook Contributions: object life cycle conformance and coverage notions that can serve as a basis for further refined compliance notions technique for process model generation facilitates achieving compliance with reference object life cycles contribution to bridging the gap between process and object modeling Future work: extension of conformance and coverage notions (too strict, too relaxed) generation of “better” business process models generation technique (identification of parallelism and structure) user-support for pre-processing of object life cycles (synchronization identification) and post-processing of process models (compliance-preserving customization) case studies object life cycle compliance scenario other top-down and bottom-up scenarios Questions?:  Questions? Backup slides:  Backup slides Related work:  Related work Object life cycles in object-oriented and database design: object life cycle specialization [Kappel91], [Schrefl02], [Stumptner00] integration of object life cycles as views [Frank98], [Preuner98] Synthesis of behavioral models: synthesis of state machines from scenarios [Uchitel03, Whittle00] Business process compliance: process mining [vanderAalst05] Sarbanes-Oxley compliance [Agrawal06] contract compliance [Governatori06] Data flow analysis – Compiler theory [Aho86], [Muchnick97]:  Data flow analysis – Compiler theory [Aho86], [Muchnick97] Basic idea: data flow equations defined for each node in the control flow graph evaluated repeatedly by calculating output from input for each node until a fixpoint is reached Forward flow analysis: block’s exit state is a function of its entry state entry state is a function of exist states of block’s predecessors Can be easily adapted for analyzing objects states in process models without loops, each task will have to be visited only once with reverse postorder a node is visited before its successors, unless the successor is reached with a back edge Generation from one object life cycle:  register settle close close reject grant evaluate reject [registered] [rejected] grant [registered] [granted] settle [granted] [settled] register [registered] close [closed] [settled, rejected] <<datastore>> Claim Generation from one object life cycle For each event labeling a state transition in object life cycle, a task is generated with appropriate input/output pins and object states Order of tasks is based on matching input/output object states Control nodes are added for correct control flow Conformance and coverage are ensured Synchronization of object life cycles:  Synchronization of object life cycles Synchronization events, synchronized automata (Our work) Explicit communication among life cycles via signals [Redding et al, 2007] “External” state transitions between life cycles [Müller et al, 2007] Implemented in actions associated with state transitions [Nandi and Kumaran, 2005] Highly Dynamic Adaptation in Process Management Systems through Execution Monitoring:  Highly Dynamic Adaptation in Process Management Systems through Execution Monitoring Massimiliano de Leoni, Massimo Mecella and Giuseppe De Giacomo {deleoni,mecella,degiacomo}@dis.uniroma1.it Dipartimento di Informatica e Sistemistica SAPIENZA – Università di Roma The Rationale / 1:  The Rationale / 1 Process Management systems, a.k.a. Workflow Management Systems, are traditionally used in many business scenarios, such as government agencies, insurances, banks, etc. Besides this static scenario, it is more and more spreading their use in very dynamic scenarios. For instance in mobile scenarios in order to coordinate the interventions of on-field teams for disaster management. During war battles to carry on more effective attacks or defences. The Rationale / 2:  The Rationale / 2 In these highly-dynamic scenarios, the execution environment can change over the time in any way. For instance, involved actors may change in the time Actors provide specific (possibly unique) capabilities which are required to carry on processes. Some tasks may require skills which no actor provides any longer. X For instance, in Mobile scenarios: Devices may run down or break, causing actors fall down. New devices can come in anytime Actors equipped with mobile devices can move around to perform assigned tasks, causing disconnections from the others or path changes A many many others, mostly unforeseeable! The Rationale / 3:  The Rationale / 3 In these scenarios, high dynamicity yields to many events which can change the context, avoiding the process’ progressing. Of course, ignoring deviation is not feasible! new situation might be such that the PMS is no more able to carry out the process instance. So adaptation is needed in several scenarios!! Scenario (Just an example):  Scenario (Just an example) Museum Precarious Bell-Tower Building Church Affected Area Picture Store Operator Operator Team Leader Photo-Camera He has got installed the PMS! Slide52:  A typical cooperative process Adaptive Process Management:  Adaptive Process Management Museum Precarious Bell-Tower Building Church Operator Bridge Team Leader Photo-Camera Affected Area Picture store Slide54:  New activity for disconnection management Two ways for adapting… :  Two ways for adapting… Anticipating all possible discrepancies. Most APMSs currently use this approach. Feasible and valuable in static context, where there are a few exceptions. In such very dynamic scenarios, too many exceptions would be to consider. Like the try/catch construct of Java: try { task1; task2; task3 || subProcess(); } catch(Disconnection) { … } catch(Devices Down) { … } catch(Exception1) { … } catch(Exception2) { … } catch(Exception3) { … } catch(Exception4) { … } ... The list of all expected exceptions. What if any unexpected happens? Two ways for adapting…:  Two ways for adapting… Devising a general recovery method. This method should be able to handle any kind of event, even unexpected. The process is defined as if exogenous actions cannot occur (the try block). Whenever discrepancies are detected leading the process not to be terminable, the control moves to the only catch block. It activates a general recovery method It modifies the old process P in a process P0 terminable in the new environment and achieving all P’s goals Like the try/catch construct of Java: try { task1; task2; task3 || subProcess(); } catch(Any Exception) { The generic method! } It analyses the changed environment and automatically adapts Execution Monitoring:  Execution Monitoring Techniques for monitor of anomalies: “sensing” of the real world and aligning of the internal virtual reality. Possibly predicting misalignments before they actually happen. Techniques for identification of corrective actions. Techniques for automatic process restructuring. < P, C > < P, C1 > e Process P is terminable in the context C Process P is NO MORE terminable in the context C1 < P1, C1 > Process P1 is terminable in the context C1 AND P1 pursues all P’s goals Adaptation 1 2 and 3 The Architecture of our Adaptive PMS:  The Architecture of our Adaptive PMS Process Engine GUI for process design Execution Monitor Sensor External World Initial process initial context Task assignment Input & Output Data Changes in process and in mental context Adapted Process Alignment of mental context with sensed data It’s the interface used by designers to define the process schema The APMS modules assigning tasks to actors, considering context and actors’ capability For each execution step, it aligns the mental world in “PMS” mind with reality and data retrieved from external world by sensors, possibly adapting the process to unforeseen exogenous events Sensors are intended as any software and/or hardware component able to get contextual information from the external world. Domain-independent predicates and actions:  Domain-independent predicates and actions Some first-order logic domain-independent predicates denote various objects in the framework: service(a): a is a service, i.e. an actor (humans, softwares or robots) performing tasks. task(x): x is a task of a workflows. capability(b): b is a capability provide(a; b): the service a provides the capability b require(x; b): the task x requires the capability b We define four domain-independent actions: Assign(a; x): the task x is assigned to a service a Start(a; x; p): the service a is notified to perform the task x on input p Stop(a; x; q): the service a acknowledges the successful termination of x with output q Release(a; x): the service a is released with respect to the task x Environment Definition / 1:  Environment Definition / 1 We define anytime the situation si as the formal specification of the environment after the i-th action. The predicate si+1 = do (t,si ) the situation after the t action on the situation si . Situation calculus relies on fluents representing properties of the world, such as: free(a;s): the actor/service a is not busy (no task assigned) in the situation s. It’s defined as: available(a;s): the actor can get another task assigned. It is true the following but not the vice versa: Environment Definition / 2:  Environment Definition / 2 The fluent available(a;s) is domain-dependent. For instance, in mobile scenarios, an actor is available if and only if it is not busy and it is connected through multi-hops to the team leader. We define preconditions as axioms on such fluents. For instance, the condition stating an actor a must be available in order to get a task x assigned is as follows: Of course, specific tasks may require some stricter conditions: That means actors needs provide a GPRS connection in order to perform the task SendDataByGPRS Definition of schemas:  Definition of schemas In our framework Process schema are defined by CONGOLOG programs. Nevertheless, everything works also through any formal specification language, such as Petri Nets. CONGOLOG is a logical language allowing actions’ concurrence widely used to describe robot plans. Actions are the basic building blocks. Here a sub-program is any CONGOLOG program A CONGOLOG Example:  A CONGOLOG Example Choose an available service/actor a0 for all required capabilities by Compile Here, 1 assignment for two tasks to force them to the same service/actor, that must provide all required capabilities for both Adaptation :  Adaptation As soon as actions are executed, the CONGOLOG program counter progresses. It is equivalent to say that, after every action, the process δ evolves in δ’, which is obtained from δ by removing the already executed action. Let be δ’: the process after each action s’: the supposed world state (virtual reality) s’’: the real world state as monitored through sensors. δ’’: the adapted process executable in s’’ If the differences between s’ and s’’ are not relevant δ’ = δ’’ otherwise δ’’ is an “adapted” version of δ’. Relevant means δ’ can be carried out even in s’’. Formal definition:  Formal definition Formally: Let The predicate SameConfig (δ’,s’, δ’’, s’’) holds if and only if δ’, performed in the situation/environment s’, is bisimilar to δ’’, performed in the context/environment s’’. The predicate Recovery(δ’,s’,s’’,δ’’) is formally as follows: Recovery (δ’,s’,s’’,δ’’) “returns” the adapted process δ’’ Relevant (δ’,s’,s’’) states if the change from s’’ to s’ is such that δ’ can’t be carried out If we use the special bisimulation SameConfig(δ’,s’, δ’’,s’’) δ’ = δ’’  SameState(s’,s’’), then we have reduced the problem to the classical AI problem of finding a plan to achieve the formula SameState Many planners already exist LinearProgram (δ) states δ to have no fork! Do (δ,s,s’) states δ, when starting in s, can terminate and it does in s’ An example…:  An example… Let’s suppose that, while going to Location for taking some photo, the actor is going to disconnect. That is violated the predicate Connected It wasn’t supposed to happen! No predefined rule to handle it APMS analyses every possible action, every task from the predefined set. It decides that another node should move to the location x where disconnecting actor is That restores the predicate! Graphically Conclusion:  Conclusion This is a general approach for automatic process adaptation in highly dynamic scenarios. Based on AI techniques, which are widely used in Robot Planning Proved correctness and completeness We are going to implement it through the IndiGolog developed by the Cognitive Robotics Group at Toronto University and Intelligent Agents group at RMIT University, Melbourne The APMS will be then used in the European project WORKPAD in the context of disaster management. We are working on improving this approach in defining how assigning properly tasks to actors, giving more evidence to those more “urgent”. Of course, we have to define how to prioritize (which parameters to take into account) Slide68:  Version Management in the Business Process Change Context Xiaohui Zhao and Chengfei Liu Swinburne University of Technology Australia BPM’07, Brisbane 24-27 September Contents:  Introduction to workflow version management Version management methodology Version preserving graph Rules for version numbering Dynamic modification operations Advantages Related work Review Contents Motivating Example:  Motivating Example Increase production Under maintenance Technical upgrade After maintenance Motivating Example (cont’d):  Motivating Example (cont’d) Technical upgrade Increase production Under maintenance After maintenance Workflow Evolvement:  Workflow Evolvement Workflow evolvement Process improvement Consecutive and non-returnable Temporary adaptation Ad hoc and returnable Issues of Workflow Evolvement:  Issues of Workflow Evolvement Version representation Single version vs multiple versions Single model vs multiple models Version transformation Forward only vs (reasonably) free transformation Version compatibility Exclusive existence vs co-existence Version Numbering:  Version Numbering Numbering versions Version priority list ( denoting the distance of version relevance by descending order) for version x.y.z x.y.z; u.v.z (u  x or v  y); x.y; x.v (v < y, v is the closet to y); u.v (u < x, u is the closet to x, or v is the largest if u is the same); Rules for Version Numbering:  Rules for Version Numbering Horizontal evolvement rule An evolvement from version x.y1.z to version x.y2.z (y1  y2) can be projected to an evolvement from x.y1 to x.y2; Vertical evolvement rule For two evolvements from version x.y to x.y.z and from x1.y1 to x1.y1.z1 (z, z1  null, x  x1 or y  y1), respectively: z = z1, if the two evolvements are caused by the same temporary change; otherwise z  z1. Version Preserving Graph (VPG):  Version Preserving Graph (VPG) A VPG for a workflow process p, can be defined as a tuple ( N, A, V, f, R ), where, N is the set of nodes, and each node v  N, represents a workflow task of p. A is the set of arcs, and each arc a  A, represents a link connecting two workflow tasks of p; V is the set of version numbers, such as “1.1”, “1.2”, “1.2.2” etc.; f : NUA→V is a mapping, which assigns proper version number to each node and arc in the graph; R is a binary relation { ( a1, a2 ) | a1, a2  A  a1 and a2 are in the exclusive relation }. Node Modification Operations:  Node Modification Operations Arc Modification Operations:  Arc Modification Operations VPG Evolvement:  VPG Evolvement Related Work:  Related Work ADEPTflex Project Rinderle, Reichert and Dadam (JIIS 1998, CoopIS 2004) Workflow Modification Language (WFML) Casati et al., (DKE 1998) Self-Adaptive Recovery Net (SARN) Hamadi and Benatallah, (WISE 2004) Specification and Validation of Process Constraints for Flexible Workflows Sadiq and Orlowska, (Info Sys 2005) Advantages:  Advantages Dynamic updating Modifications without suspending running instances Multiple version compatibility A single workflow process navigates instances of different versions Co-existence of different versioned workflow instances Compact model Lightweight graph model for representing workflow evolvements Brief review:  Brief review Introduction of version management Version preserving graph model Run time workflow modification operations Related work Advantages Q & A:  Q & A Thank you Runtime Version Management ( 1 ):  Runtime Version Management ( 1 ) Workflow Extraction Strategies Backward assembling strategy Top-down exploration strategy x.y.z; u.v.z (u  x or v  y); x.y; x.v (v < y, v is the closet to y); u.v (u < x, u is the closet to x, or v is the largest if u is the same); chain reactions involve irrelevant nodes ver 1.2.2 Runtime Version Management ( 2 ):  Runtime Version Management ( 2 ) ignores irrelevant nodes x.y.z; u.v.z (u  x or v  y); x.y; x.v (v < y, v is the closet to y); u.v (u < x, u is the closet to x, or v is the largest if u is the same); Workflow Extraction Strategies Backward assembling strategy Top-down exploration strategy ver 1.2.2

Add a comment

Related presentations

Related pages

SadiQ | Facebook

SadiQ. Gefällt 152.553 Mal · 502 Personen sprechen darüber. AKpella-Album vorbestellen iTunes: www.umgt.de/x3fs9i BOX-SET Amazon: www.umgt ...
Read more

SadiQ – Wikipedia

SadiQ (* 11. Mai 1988 in Kabul; bürgerlich Sadiq Zadran) ist ein deutscher Rapper mit afghanischen Wurzeln.
Read more

SadiQ Free - YouTube

SADIQ / AKPELLA ALBUM / AB 30.12.2016 ERHÄLTLICH! Das Album jetzt vorbestellen auf www.sadiqfree.com
Read more

Ja'far al-Sadiq - Wikipedia, the free encyclopedia

Birth and early life. Ja'far al-Sadiq was born in Medina either in 80/699–700 or 83/703–704. On his father's side he was a great-great grandson of Ali ...
Read more

SadiQ - Headshot - YouTube

SadiQ - Headshot SadiQ Free. Subscribe Subscribed Unsubscribe 36,791 36K. ... SadiQ - Thug Life - Meine Stadt "Frankfurt" (Part 66) - Duration ...
Read more

Umar Sadiq - Wikipedia

Personal information; Full name: Umar Sadiq Mesbah: Date of birth (1997-02-02) 2 February 1997 (age 19) Place of birth: Kaduna, Nigeria: Playing position
Read more

Narkotic - Sadiq & Dú Maroc: Amazon.de: Musik

Amazon.de/musik: Sadiq & Dú Maroc – Narkotic jetzt kaufen. Bewertung 4.7, . Rap & Hip-Hop, Import-Eu, Rap, Rap/Hip
Read more

TrafiQ - SadiQ: Amazon.de: Musik

Seit langer Zeit verfolge ich SadiQ seine Karriere, mich hat damals ein Lied von ihm sehr berührt. Seitdem bin ich Fan von ihm. Auch in den Interviews ...
Read more

Home - Raphael Saadiq

Raphael Saadiq joined Band of Skulls at LA’s “Who Shot Rock and Roll”, featured now on RollingStone.com. Click here to read more.
Read more