Barbara Weber Univ. of Innsbruck, Austria Manfred Reichert Univ. of Ulm, Germany Presenter: Arghyadip Paul Refactoring Process Models in Large Process Repositories

 Motivation and Process Smells  Process Model Refactorings Refactorings for Process Model Trees Refactoring for Process Variants Refactorings for Model Evolution  Summary Contents

Emergence of large model repositories with increasing adoption of PAIS Process adaptations bear the risk of introducing redundancies.(Over the time new Process Model gets included in the Process Model Repositories) This unnecessary complexity makes changes costly and time consuming and makes errors more probable Maintenance of process models is poorly supported in today’s business process modeling tools Motivation

Refactoring Techniques are widely used in Software Engineering Process Model: Software Programming in Large Process Model Designers are either have to refactor process models manually or not process model refactoring is done at all. This paper proposes a catalogue of process model smells for identifying refactoring opportunities. Set of behavior preserving refactoring techniques.

Motivation We know from software engineering that productivity decreases when no continuous efforts are made to keep the code base simple

Motivation Large case study in the healthcare domain and the automotive domain > 130 process models partially created by different designers at different points in time Observations  redundant process fragments in many process models (e.g., activities for scheduling and planning appointments)  names of activities often not intention revealing  process models often unnecessarily complex

Example of an Automotive Engineering Process

Model trees Motivation A B D C + + E F Generic Process Schema A B D C + + E Delete F Variant V1 A B D C + + E Variant V2 Y Delete F Insert Y after C A B x x D Schema S + C E H G + + I Schema S1 + F J K L Schema S2 Process model family

 Motivation and Process Smells  Process Model Refactorings Refactoring for Process Model Trees Refactoring for Process Variants Refactorings for Model Evolution  Summary Contents

Refactorings are model transformations which are behavior-preserving if certain pre- and post conditions are met  Process schemes must be trace equivalent before and after the refactoring  Differs from model transformation where the entire process model is redefined. Refactoring

M Process Model S Trace Equivalence Example: AND-Split/Join A Atomic Activity + Complex Activity + BCD + EF G (Sub) Process Model S3 X YZ + + BCD EF Process Model S2 L + A M + Process Model S’ (Sub) Process Model S3 X YZ

Transformations between models expressed in different modeling languages Transformations which are altering the execution behavior (e.g., change patterns) What Refactoring is Not

When to refactor?(In SE)  Code smells  Quality metrics How to ensure that the execution behavior remains unchanged?  Formal pre- and post conditions  Testing Refactoring

How refactoring is applied and evaluated

Process Smells This list of process smells are not exhaustive, but rather found empirically by investigating a number of process model repositories in the Healthcare and automotive domain

Examples of PMS PMS1: In Source 1 several activities with same intention found like “Appointment”, “Fix Appointment”, “Fix Day” etc PMS2: Unnecessarily using logic gateways in the process model like AND Join and AND Split repetitively. PMS3: Source 1 has different process models for a women clinic. Many process model contain may redundant process fragments which executes the same control flow logic. PMS4: There are process models found with 800 activities. Empirical data shows that larger the process model size is larger will be the flows and lesser will be the understandability. PMS5: Inclusion of more number of process models with less activities makes the entire process model tree burdensome and difficult to understand. Extreme decomposition is not good. PMS6: 46 process models of source 2 shows significant number of flows in the model which are never executed PMS7:Deviate from the process model defined while execution found in Source 3 PMS8: Leads to enlargement of the process model repository. Despite the large similarity between variants they have been captured as separate process models.

3 categories of refactoring  Refactoring for Process Model Trees Can be applied to a single Process Model or a Process Model Tree.  Refactoring for Process Variants To identify a reference process model closest to a given variant collection.  Refactoring for Model Evolution Refactoring technique which considers history data. Refactoring

Refactoring in this category can be applied to a single model or to entire process model trees RF1: Rename Activity: Name of an activity can be changed if it is not intention revealing RF2: Rename Process Model: enables designers to rename a model S into S1 RF3: Substitute Proces Fragment: a fragment G can be substituted by another fragment G0 with simpler structure, but showing same behavior RF4: Extract Process Fragment: Applying RF4 results in the creation of a new (sub) process model S0 implementing the fragment RF5: Replace Process Fragment by Reference: replace a process fragment by a trace- equivalent subprocess model RF6: Inline Process Fragment: used to collapse the hierarchy of a model by in lining the process fragment RF7: Re-label Collection: : is a composed refactoring for re-labeling a particular activity in all models of a model collection RF8: Remove Redundancies Refactorings for Process Model Trees

Example RF3

Refactorings for Process Model Trees RF4, RF5 and RF7 A B F C x X G Process Schema S DE HI Z F C x X Y Process Schema S1 DE T X + + WV A B G Process Schema S‘ HI F C x X DE Process Schema S2 + S2 Z Y Process Schema S1‘ T X + + WV + S2

Challenge is to maintain Process Model Variants of the same Reference Process Model. In many cases the process variants have to be maintained by their own, and even simple changes acting multiple variants require error-prone, manual re-editing of a large number of related process variants.(Due to new laws and engineering effort) In general, the configuration of new variants or the adaptation of existing ones can be done most effectively if the reference model is kept close to the given variant collection by minimizing the average change distance RF9 - Generalize Variant Changes: enables designers to pull changes, which are common to several variants, up to the reference model Refactoring for Process Variants

x x Distance  (S, V1) = 6Bias(S,V1) = Select Examination Order Examination Inform Patient about Procedure Prepare Patient (ward( Perform Examination Create Medical Report Read/Validate Medical Report Select Examination Order Examination Inform Patient about Procedure Prepare Patient (ward) Second Opinion by other Physician Prepare Patient (exam unit) Perform Examination Create Medical Report Read/Validate Medical Report Call Patient Aftercare for Patient ++ Select Examination Order Examination Inform Patient about Procedure Prepare Patient (ward) Prepare Patient (exam unit) Perform Examination Create Medical Report Read/Validate Medical Report Call Patient Aftercare for Patient Create Summary Read Summary Process Configuration Select Examination Order Examination Register Examination Inform Patient about Procedure Prepare Patient Perform Examination Create Medical Report Read/Validate Medical Report Aftercare for Patient Create Summary Read Summary Call Patient + + Select Examination Order Examination Schedule Examination Inform Patient about Procedure Prepare Patient Perform Examination Create Medical Report Read/ Validate Medical Report Aftercare for Patient Create Summary Read Summary Call Patient Tranport Patient Tranport Patient back Reference Model S Variant V1 Variant V3 Variant V2 Variant V4 Distance  (S, V3) = 5Bias(S,V3) = Distance  (S, V2) = 6Bias(S,V2) = Distance  (S, V3) = 7Bias(S,V4) = ABCDE FG H J K L M N O P Q I J I K I K L M I K L M

++ Select Examination Order Examination Inform Patient about Procedure Prepare Patient (ward) Perform Examination Read/Validate Medical Report Call Patient Schedule Examination Aftercare for Patient Create Medical Report AB C DEF G New Reference Model S* x x Distance  (S*, V1) = 4Bias(S,V1) = Select Examination Order Examination Inform Patient about Procedure Prepare Patient (ward) Second Opinion by other Physician Prepare Patient (exam unit) Perform Examination Create Medical Report Read/Validate Medical Report Call Patient Aftercare for Patient ++ Select Examination Order Examination Inform Patient about Procedure Prepare Patient (ward) Prepare Patient (exam unit) Perform Examination Create Medical Report Read/Validate Medical Report Call Patient Aftercare for Patient Create Summary Read Summary Select Examination Order Examination Register Examination Inform Patient about Procedure Prepare Patient Perform Examination Create Medical Report Read/Validate Medical Report Aftercare for Patient Create Summary Read Summary Call Patient + + Select Examination Order Examination Schedule Examination Inform Patient about Procedure Prepare Patient Perform Examination Create Medical Report Read/ Validate Medical Report Aftercare for Patient Create Summary Read Summary Call Patient Tranport Patient Tranport Patient back Variant V1 Variant V3 Variant V2 Variant V4 Distance  (S*, V3) = 6Bias(S,V3) = Distance  (S*, V2) = 4Bias(S,V2) = Distance  (S*, V3) = 6Bias(S,V4) = H J L M N O P Q J I K L M L M

Remove Unused Branch Pull Up Instance Change Refactorings for model evolution are not behavior-preserving However, all traces on S have to be reproducible on S’ Refactoring for Model Evolution

RF10 - Remove Unused Branches  Enables designers to remove non-executed process fragments from a model S.  RF10 is not automatically applied,  Designers have to ensure that the misalignment between model and log design errors execution log not covering all relevant traces.

Remove Unused Branch Refactorings for Model Evolution A B F C X x G Process Schema S DE Instance 1: A, B, C, G Instance 2: A, B, F, G Instance 3: A, B, C, G Instance 4: A, B, F, G Instance 5: A, B, F, G … Execution Log RemoveUnusedGraph(S, {D, E}) A B F C X x G Process Schema S’

Refactoring for Model Evolution RF11 - Pull Up Instance Change  can be used to generalize frequently occurring instance changes by pulling them up to the process type level  Changes are done by the Process Model owner at the execution level only and not at the Process model definition level.  Similar refactoring RF9 which is done from the Variant level.

X Pull Up Instance Change Refactorings for Model Evolution A B D C E Process Schema S I1: ParallelInsert(S,Y,B), Delete(E) I2: ParallelInsert(S,Y,B) I3: Delete(A) I4: ParallelInsert(S,Y,B), Delete(A) I5: ParallelInsert(S,Y,B) Change Biases Change Distance = 7 A B D C E Process Schema S’ x Y I1: Delete(E) I2: I3: Delete(A), Delete(Y) I4: Delete(A) I5: Change Biases Change Distance = 4

 Motivation  Process Model Refactorings Refactoring for Process Model Trees Refactoring for Process Variants Refactorings for Model Evolution  Summary Contents

11 refactoring techniques for business process models Refactorings applicable to process model trees, but also to process variants Proof-of-concept implementation Summary

Thank You

Prototype Implementation Implemented as an Eclipse RCP application on the top of SecServ platform.

Abstractions: