process-flexibility.com

Change Patterns

Change Patterns (30)

PAISs supporting instancespeci c adaptations (cf. Feature F2), should be able to cope with concurrent changes. For example, two users might want to apply di erent ad-hoc changes to a particular process instance at the same time. If this is done in an uncontrolled manner, errors or inconsistencies (e.g., deadlock-causing cycles) can occur (Design Choice F7[1]). Or, the execution of an instance proceeds (i.e., the state of the instance may change) while an ad-hoc change is concurrently applied to it. Here we have to ensure that the state change does not violate state constraints required for the correct application of the ad-hoc change (or at least the ad-hoc change has to be prohibited in such cases). The easiest way to avoid respective con icts is to prohibit concurrent changes in general (Design Choice F7[2]). This can be achieved, for example, by holding exclusive locks on a
process instance when changing its structure or state (e.g., an instance must not proceed while applying an ad-hoc change to it). Although this approach is easy to implement, it is usually too restrictive due to the long-term locks required (e.g., when a change is de ned interactively by a user this might block instance execution for a while). A more exible approach would allow for concurrent changes of the structure or state of a process instance, and further ensure that this does not lead to errors or inconsistencies afterwards (Design Choice F7[3]). Both, pessimistic and optimistic techniques can be applied in this context to control such concurrent instance changes and to ensure their correctness. Pessimistic locking is an approach where the process instance to be modi ed is locked until the change is accomplished. In contrast, optimistic concurrency control does not put a lock on the process instance, but checks for con icts when commiting changes.

Finally, we have to deal with "concurrent" changes at the process type and the process instance level. For example, assume that an instance-speci c change is applied to process instance I , which was originally created from process schema S. Assume further that later process schema S evolves to S 0 due to a change at the process type level. Then, the challenging question is whether the process type change can be propagated to I as well. Although I has undergone an instance-speci c change this should not mean that it must not migrate to the new schema version S' (particularly not if I is long-running). Note that respective considerations only have to be made for systems supporting both changes at the process type and the process instance level (Design Choice F7[4]).

Sunday, 04 August 2013 21:23

Change Support Feature FF6: Change Reuse

In the context of unplanned instance changes "similar" deviations (i.e., combinations of one or more adaptation patterns) can occur more than once. As it requires signi cant user experience to de ne changes from scratch, change reuse has to be supported. For this, changes should be annotated with contextual information (e.g., about the reasons for the deviation) and be memorized (Change Feature F4[2]). This contextual information can be used for retrieving similar problem situations. This approach ensures that only changes relevant in the current situation are presented to the user. Regarding patterns for changes in prede ned regions, reuse can be supported by making historical cases available to the user and by saving frequently re-occurring instances as templates.

The support of change patterns leads to increased process exibility. This, in turn, imposes security issues as the PAIS becomes more vulnerable to misuse [59,60]. Therefore, the application of changes at the process type and the process instance level must be restricted to authorized users (Design Choice F5[1]). Access control features di er signi cantly in their degree of granularity. In the simplest case, changes are restricted to a particular group of people (e.g., to process engineers). More advanced access control components allow users to de ne restrictions at the level of single change patterns (e.g., a certain user is only allowed to insert additional activities, but not to delete existing ones) (Design Choice F5[2]). In addition, authorizations may depend on the object to be changed (e.g., the concrete process schema or a process instance) (Design Choice F5[3]).

For adaptation patterns, applied changes have to be stored in a change log as change patterns or primitives. Regarding patterns for changes in prede ned regions, an execution log is usually suf- cient to enable traceability (Design Choice F4[1]). In addition, logs can be enriched with semantical information, e.g., about the reasons and the context of the changes (Design Choice F4[2]). Finally, change mining allows for the analysis of changes and resulting schema variants, for example, to support continuous process improvement (Design Choice F4[3]).

The application of change patterns must not lead to run-time errors (e.g., activity program crashes due to missing input data, deadlocks, or inconsistencies due to lost updates or vanishing of instances). In particular, di erent criteria have been introduced to formally ensure that process instances can only be updated to a new schema if they are compliant with it. In addition, depending on the used process meta model constraints of the respective formalism (e.g., concerning the structuring of process schemes) have to be taken into account as well when applying process changes to a particular process schema.

To deal with exceptions PAISs must support unplanned changes (Design Choice F2[1]) at the process instance level either through high-level changes in the form of patterns or through low-level primitives. To deal with uncertainty, PAISs must further allow process modelers to keep parts of the model unspeci ed during build-time and to defer the concretisation of the respective part to run-time (Design Choice F2[2]). The e ects resulting from instance-speci c changes can be permanent or temporary. A permanent instance change remains valid until completion of the instance (unless it is undone by a user). By contrast, a temporary instance change is only valid for a certain period of time (e.g., the current iteration of a loop).

FF02

To support changes at the process type level, version control for process schemes is needed. In case of long-running processes, in addition controlled migration of already running instances from the old to the new process schema version is often required when conducting a schema change at the process type level. If no version control is provided, either the process designer will have to manually create a copy of the process schema to be changed or the original schema will be overwritten. In the latter case, running instances can either be withdrawn from the run-time environment (Design Choice F1[1]) or they remain associated with the modi ed schema (Design Choice F1[2]). Depending on current instance execution state and on how changes are propagated to instances progressed too far, missing version control can lead to inconsistent states and in the worst case to deadlocks or severe other run-time errors. Schema S has been modi ed by adding activities X and Y. Regarding instance I1 this change is uncritical as I 1 has not yet entered the changed region. However, instance I 2 would be in an inconsistent state afterwards as instance schema and execution history do not match.

FF01 1

By contrast, if a PAIS provides explicit version control three support features can be di erentiated: running process instances remain associated with the old schema version, while new instances will be created based on the new schema version. This approach leads to the co-existence of process instances belonging to di erent schema versions. Alternatively, for a (selected) collection of already running process instances a controlled migration to the new process schema version is supported.

FF01 2

Design Choice F1[3] is shown in Fig. 18b where already running instances I1, I 2 and I 3 remain associated with schema S1, while new instances (I 4, I 5) are created from schema S 0 (co-existence of process instances of di erent schema versions). By contrast, Design Choice F1[5] illustrates the controlled migration of selected instances. Only those instances (I1 and I 2) are migrated to the new schema version which are compliant with S0. Thereby, I1 can be migrated without any state adaptations, whereas for I 2 the newly inserted Activity X has to be enabled instead of Activity B. Instance I 3 remains running according to S since it is non-compliant with S0. If instance migration is accomplished in an uncontrolled manner (i.e., it is not restricted to compliant process instances) inconsistencies or errors will result (Design Choice F1[4]). Nevertheless, we treat the uncontrolled migration of process instances as a separate design choice since this functionality can be found in existing systems.

FF01 3

Friday, 14 June 2013 10:06

Change Features in Practice

Written by

Pattern / Feature

Academic 

Commercial

ADEPT2 /
CBRFlow

CAKE2 HOON MOVE PoF WASA2 WIDE

YAWL +
Worklets/
Exlets

Flower Staffware

Built-In Flexibility

Patterns for Changes in Predefined regions

PP1 – Late Selection of Fragments

A[1,2], B[1,2],
C[2]

    –   

A[1,2], B[1,2],
C[2]

 

A[1,2], B[1,2],
C[2]

PP2 – Late Modeling of Fragments

A[q], B[1],
C[2,3], D[1} 

 

A[1], B[1],
C[3], D[1,2]

A[1,2], B[2],
C[2], D[1,2]

–         
PP3 – Late Composition of Fragments       –         
PP4 – Multi-Instance Activity         –         

Change Features 

F1 – Schema Evolution, Version Control and Instance Migration  F1[3, 5] F1[1] F1[1] F1[1] F1[1] F1[3, 5]

F1[3, 5]

F1[3] F1[1, 2, 3] F1[3, 4]
F2 – Support for Instance-specific Changes F2[1a,b] F1[1b, 2b] F2[2a] F2[2a

F2[2b]

F2[1b]

F2[2b]

F2[1a,b, 2a,b] F2[1b, 2b] F2[2b]
F3 – Correctness of Changes + + + +  + + +    
F4 – Traceability & Analysis F4[1, 2, 3] F4[1, 2] F4[1] F4[1] F4[1] F4[1]

F4[1]

F4[1]  F4[1] F4[1]
F5 – Access Control for Changes F5[1, 2, 3]   F5[1, 2, 3]

F5[1, 3]

F5[1, 2, 3] F5[1] F5[1, 3] F5[1, 2, 3] F5[1, 2, 3]*  F5[1, 2, 3]
F6 – Change Reuse + +     +        
F7 – Change Concurrency Control F7[3, 4] F7[3] F7[3] F7[3] F7[3] F7[2]

not
applicable

F7[3] F7[2] F7[3]

(*) Flower supports Option 2 and 3 of feature F4 only for process instance changes, but not for process type changes

Primitive / Pattern

Academic 

Commercial

ADEPT2 /
CBRFlow

CAKE2 HOON MOVE PoF WASA2 WIDE

YAWL +
Worklets/
Exlets

Flower Staffware

Process Adaption

Change Primitives

PR1 – Add node + –             
PR2 – Remove Node              
PR3 – Add Edge              
PR4 – Remove Edge                
PR5 – Move Edge                  

Adaption Patterns 

AP1 – Insert Fragment  A[1, 2], B[1,2,3], C [1, 2]

AP2 – Delete Fragment A[1, 2], B[1,2,3]          

  A[2],B[1]   
AP3 – Move Fragment A[1, 2], B[1,2,3], C[1,2]                  
AP4 – Replace Fragment            

A[1], B[1]     
AP5 – Swap Fragment                    
AP6 – Extract Fragment  A[1,2], B[3]                  
AP7 – Inline Fragment  A[1,2], B[2]                  
AP8 – Embed Fragment in Loop   A[1,2], B[1,2,3]                  
AP9 – Parallelize Activities   A[1,2], B[1,2,3]                  
AP10 – Embed Fragment in Conditional Branch             

 

     
AP11 – Add Control Dependency  A[1,2]                  
AP12 – Remove Control Dependencies A[1,2]         –         
AP13 – Update Condition  A[1,2]                
AP14 – Copy Fragment                    

Primitive / Pattern

Academic 

Commercial

ADEPT2 /
CBRFlow

CAKE2 HOON MOVE PoF WASA2 WIDE

YAWL +
Worklets/
Exlets

Flower Staffware

Process Adaption

Change Primitives

PR1 – Add node +
PR2 – Remove Node
PR3 – Add Edge
PR4 – Remove Edge  
PR5 – Move Edge                

Adaption Patterns 

AP1 – Insert Fragment  A[1, 2], B[1,2,3], C [1, 2]

A[2], B[1],
C[1,2] 

AP2 – Delete Fragment A[1, 2], B[1,2,3]          

A[2], B[1]

     
AP3 – Move Fragment A[1, 2], B[1,2,3], C[1,2]                  
AP4 – Replace Fragment            

A[2], B[1]

     
AP5 – Swap Fragment                    
AP6 – Extract Fragment  A[1,2], B[3]                  
AP7 – Inline Fragment  A[1,2], B[2]                  
AP8 – Embed Fragment in Loop   A[1,2], B[1,2,3]                  
AP9 – Parallelize Activities   A[1,2], B[1,2,3]                  
AP10 – Embed Fragment in Conditional Branch             

A[2] 

     
AP11 – Add Control Dependency  A[1,2]                  
AP12 – Remove Control Dependencies A[1,2]         –         
AP13 – Update Condition  A[1,2]           A[2]      
AP14 – Copy Fragment                    
Page 1 of 3
 

Get the Book!

book cover small