Resolving Inconsistencies and Redundancies in Declarative Process Models
Download as PPTX, PDF0 likes323 views
This document presents an algorithm for detecting inconsistencies and redundancies in declarative process models mined from event logs. The algorithm represents constraints as automata and uses automata operations like intersection to identify conflicts or redundant constraints. It aims to return minimal and consistent models by removing conflicting or unnecessary constraints. The algorithm is implemented in a tool called Minerful and evaluations show it can improve the quality of mined declarative models. Limitations include the effect of constraint sorting order and performance challenges with large logs. Future work includes user involvement and integration into process mining tools.
![From constraints-based model
to FSA
RespondedExistence(a,b)
RespondedExistence(a,c)
and
Response(a,b)
Response(a,c)
and
…
SEITE 16
[^a]*((a.*b.*)|(b.*a.*))*[^a]* [^a]*(a.*c)*[^a]*
Regular
Expression
Deterministic
Finite
State
Automaton](https://image.slidesharecdn.com/declare-conflireduxemisa2017-170620091502/85/Resolving-Inconsistencies-and-Redundancies-in-Declarative-Process-Models-16-320.jpg)
![To be kept in mind
RespondedExistence(a,b)
RespondedExistence(a,c)
and
Response(a,b)
Response(a,c)
and
…
SEITE 17
[^a]*((a.*b.*)|(b.*a.*))*[^a]* [^a]*(a.*c)*[^a]*
Regular
Expression
Deterministic
Finite
State
Automaton](https://image.slidesharecdn.com/declare-conflireduxemisa2017-170620091502/85/Resolving-Inconsistencies-and-Redundancies-in-Declarative-Process-Models-17-320.jpg)
Resolving Inconsistencies and Redundancies in Declarative Process Models
- 1. Resolving Inconsistencies and Redundancies in Declarative Process Models Claudio Di Ciccio, Fabrizio Maria Maggi, Marco Montali and Jan Mendling 8th International Workshop on Enterprise Modeling and Information Systems Architectures (EMISA 2017) Essen, Germany claudio.di.ciccio@wu.ac.at Di Ciccio, C., Maggi, F. M., Montali, M., Mendling, J. (2017). Resolving inconsistencies and redundancies in declarative process models. Information Systems, 64, 425–446. https://doi.org/10.1016/j.is.2016.09.005
- 2. Foreword (Declarative) process discovery Declarative constraints as automata SEITE 2
- 3. Process discovery SEITE 3 ? Event log Process model
- 5. Declarative process discovery SEITE 5 ? Objective: understanding the constraints that best define the allowed behaviour of the process behind the event log
- 6. Declarative modelling of processes Init(c) c is always the first executed activity End(d) d is always the last executed activity RespondedExistence(a,b) If a is executed, b has to be executed Response(a,b) If a is executed, b has to be executed afterwards ChainResponse(a,b) If a is executed, b has to be executed immediately afterwards Precedence(a,b) If b is executed, a must have been executed beforehand ChainPrecedence(a,b) If b is executed, a has to be executed immediately beforehand NotChainSuccession(a,b) If a is executed, b cannot be executed immediately afterwards SEITE 6 Usage of constraints “Open model” Declare state-of-the-art language
- 7. Subsumption hierarchy of relation Declare templates SEITE 7
- 8. Mining declarative processes: ingredients “Submit draft”, “Write deliverable”, “Organise agenda”, … SEITE 8 a, b, c, … Activities Process alphabet Event log Declarative constraint templates
- 9. Mining declarative processes RespondedExistence(a,b) ? RespondedExistence(a,c) ? … Response(a,b) ? Response(a,c) ? … SEITE 9 • Support: fraction of cases fulfilling the constraint • Confidence: support scaled by fraction of traces in which the activation occurs • Interest factor: confidence scaled by fraction of traces in which the target occurs Support Conf. I.F.
- 10. Mining declarative processes RespondedExistence(a,b) ? RespondedExistence(a,c) ? … Response(a,b) ? Response(a,c) ? … SEITE 10 Support Conf. I.F.
- 11. Mining declarative processes RespondedExistence(a,b) RespondedExistence(a,c) ? … Response(a,b) ? Response(a,c) … SEITE 11 Support Conf. I.F.
- 12. Mining declarative processes RespondedExistence(a,b) RespondedExistence(a,c) ? … Response(a,b) Response(a,c) … SEITE 12 Support Conf. I.F.
- 13. Mining declarative processes RespondedExistence(a,b) RespondedExistence(a,c) ? … Response(a,b) Response(a,c) … SEITE 13 Support Conf. I.F.
- 14. Mining declarative processes RespondedExistence(a,b) RespondedExistence(a,c) … Response(a,b) Response(a,c) … SEITE 14 Support Conf. I.F.
- 15. Mining declarative processes RespondedExistence(a,b) RespondedExistence(a,c) and Response(a,b) Response(a,c) and … SEITE 15
- 16. From constraints-based model to FSA RespondedExistence(a,b) RespondedExistence(a,c) and Response(a,b) Response(a,c) and … SEITE 16 [^a]*((a.*b.*)|(b.*a.*))*[^a]* [^a]*(a.*c)*[^a]* Regular Expression Deterministic Finite State Automaton
- 17. To be kept in mind RespondedExistence(a,b) RespondedExistence(a,c) and Response(a,b) Response(a,c) and … SEITE 17 [^a]*((a.*b.*)|(b.*a.*))*[^a]* [^a]*(a.*c)*[^a]* Regular Expression Deterministic Finite State Automaton
- 18. So far, so good What is the problem? SEITE 18
- 19. While mining a real-life log… Support threshold: 0.85 Confidence threshold: 0.25 Interest factor threshold: 0.25 SEITE 19
- 20. While mining a real-life log… SEITE 20
- 21. Time to challenge the X SEITE 21
- 22. Time to challenge the X Loading… SEITE 22
- 24. The problems 1) inconsistency When support threshold is lower than 100%, constraints can be valid through most of the log, though being in conflict Example: an event log consists of two traces: 1. <a, b, a, b, a, b, c> 2. <a, b, a, b, a, c> Support threshold: 0.7 • a is always the first Init(a) • c is always the last End(c) • In 6 cases over 8 (75%), a and c do not directly follow each other NotChainSuccession(a,c) • In 5 cases over 7 (71.143%), b and c do not directly follow each other NotChainSuccession(b,c) SEITE 24
- 25. The problems 1) inconsistency When support threshold is lower than 100%, constraints can be valid through most of the log, though being in conflict Example: an event log consists of two traces: 1. <a, b, a, b, a, b, c> 2. <a, b, a, b, a, c> Support threshold: 0.7 • a is always the first Init(a) • c is always the last End(c) • In 6 cases over 8 (75%), a and c do not directly follow each other NotChainSuccession(a,c) • In 5 cases over 7 (71.143%), a and b do not directly follow each other NotChainSuccession(b,c) Question: what can be done right before c? inconsistency! SEITE 25
- 26. The problems 1) inconsistency When support threshold is lower than 100%, constraints can be valid through most of the log, though being in conflict How to trust a discovery algorithm that can return inconsistent models? SEITE 26
- 27. The problems 2) redundancy Many constraints may be fulfilled 100% of times yet not add a bit of information to other already discovered ones Example: an event log consists of two traces: 1. <a, b, a, b, a, b, c> 2. <a, b, a, b, a, c> • a is always the first Init(a) • c is always the last End(c) • Before c, a precedes Precedence(a,c) • Before b, a precedes Precedence(a,b) • After a, c eventually follows Response(a,c) • After b, c eventually follows Response(b,c) SEITE 27
- 28. The problems 2) redundancy Many constraints may be fulfilled 100% of times yet not add a bit of information to other already discovered ones Example: an event log consists of two traces: 1. <a, b, a, b, a, b, c> 2. <a, b, a, b, a, c> • a is always the first Init(a) • c is always the last End(c) • Before c, a precedes Precedence(a,c) • Before b, a precedes Precedence(a,b) • After a, c eventually follows Response(a,c) • After b, c eventually follows Response(b,c) SEITE 28 Of course! a is always the first
- 29. The problems 2) redundancy Many constraints may be fulfilled 100% of times yet not add a bit of information to other already discovered ones Example: an event log consists of two traces: 1. <a, b, a, b, a, b, c> 2. <a, b, a, b, a, c> • a is always the first Init(a) • c is always the last End(c) • Before c, a precedes Precedence(a,c) • Before b, a precedes Precedence(a,b) • After a, c eventually follows Response(a,c) • After b, c eventually follows Response(b,c) SEITE 29 Of course! a is always the first Of course! c is always the last Question: can't we avoid stating the obvious? redundancy!
- 30. The problems 2) redundancy Many constraints may be fulfilled 100% of times yet not add a bit of information to other already discovered ones How to reduce the number of unnecessary returned constraints? SEITE 30
- 31. The solution Automata-product monoid SEITE 31 Algebraic structure with composition operator ( ) holding the properties of commutativity associativity and bearing identity element and absorbing element
- 33. Rules of the game SEITE 33 Intersect the product automaton with the newly visited constraints, one at a time Init(a) Participation(b) = Product automaton Init(a) Participation(b)
- 34. Intersect the product automaton with the newly visited constraints, one at a time Rules of the game SEITE 34 ChainPrecedence(a,b) ChainPrecedence(a,b) Init(a) Participation(b) Product automaton
- 35. Exploiting formal properties We take advantage of 1. associativity allows for "storage" of results SEITE 35 Product automaton ChainPrecedence(a,b) Old product automaton =
- 36. Exploiting formal properties We take advantage of 1. associativity allows for "storage" of results 2. commutativity allows for priority sorting of constraints SEITE 36 Product automaton
- 37. Exploiting formal properties We take advantage of 1. associativity allows for "storage" of results 2. commutativity allows for priority sorting of constraints SEITE 37 Product automaton
- 38. Playing the game Newly visited constraints add information to the knowledge on the process model if they reduce the number of possible traces (accepted strings) SEITE 38 Product automaton
- 39. Playing the game Newly visited constraints add information to the knowledge on the process model if they reduce the number of possible traces (accepted strings) SEITE 39 Product automaton
- 40. Playing the game Newly visited constraints add information to the knowledge on the process model if they reduce the number of possible traces (accepted strings) SEITE 40 Product automaton
- 41. Inconsistency! Newly visited constraints add information to the knowledge on the process model if they reduce the number of possible traces (accepted strings) Conflict: SEITE 41 Product automaton
- 42. Inconsistency! Newly visited constraints add information to the knowledge on the process model if they reduce the number of possible traces (accepted strings) Conflict: The product automaton becomes (empty language) SEITE 42 Response(a,b) Response(b,a)
- 43. Inconsistency! Newly visited constraints add information to the knowledge on the process model if they reduce the number of possible traces (accepted strings) Conflict: The product automaton becomes (empty language) SEITE 43
- 44. Inconsistency! Newly visited constraints add information to the knowledge on the process model if they reduce the number of possible traces (accepted strings) Conflict: Remove the constraint, in case SEITE 44
- 45. Redundancy! Newly visited constraints add information to the knowledge on the process model if they reduce the number of possible traces (accepted strings) Redundancy: SEITE 45
- 46. Redundancy! Newly visited constraints add information to the knowledge on the process model if they reduce the number of possible traces (accepted strings) Redundancy: The new product automaton accepts the same strings as before (language inclusion) SEITE 46 Response(a,c) End(c)
- 47. Redundancy! Newly visited constraints add information to the knowledge on the process model if they reduce the number of possible traces (accepted strings) Redundancy: The new product automaton accepts the same strings as before (language inclusion) SEITE 47
- 48. Redundancy! Newly visited constraints add information to the knowledge on the process model if they reduce the number of possible traces (accepted strings) Redundancy: Remove the constraint, in case SEITE 48
- 49. Objectives Remove inconsistencies Minimise redundancies Analyse each constraint once SEITE 49
- 50. The solution: Inconsistency detection Rationale: 1. How to find inconsistencies among constraints? Use the automaton-based model for constraints Does the cross-product automaton recognise the empty language? 2. How to search the inconsistencies? Exploit: a) The product operation between automata b) The sorting of Declare templates Guideline: Preserve the most meaningful constraints The sorting prioritises constraints SEITE 50
- 51. The solution: Redundancy detection Rationale: 1. How to find redundancies among constraints? Use the automaton-based model for constraints Does the cross-product automata recognise the same language as before? 2. How to search the inconsistencies? Exploit: a) The product operation between automata b) The sorting of Declare templates Guideline: Preserve the most meaningful constraints The sorting prioritises constraints SEITE 51
- 52. Conclusion Which were the conflicting constraints in the log? How does the redundancy removal perform? What is more in the paper? Limitations and future work
- 53. SEITE 53
- 54. Which were the conflicting constraints in the log? 1. NotSuccession(send meeting, organize agenda) 2. NotChainSuccession(send draft, send deliverable) 3. Succession(send draft, submit report) SEITE 54
- 55. SEITE 55
- 57. Conclusions, limitations and future work We have presented an algorithm which automatically finds inconsistencies and redundancies in mined Declare models The checks are purely based on operations over automata (remember: monoids) http://github.com/cdc08x/minerful More in the paper: The order in which the constraints are checked deeply affects the returned result Comparative studies prove different sorting strategies to affect computation time fitness of the returned model size Limitations: Performances are heavily affected by the interplay of constraints Future work: Users/analysts involvement http://www.promtools.org/prom6/nightly SEITE 57
- 58. Resolving Inconsistencies and Redundancies in Declarative Process Models Claudio Di Ciccio, Fabrizio Maria Maggi, Marco Montali and Jan Mendling 8th International Workshop on Enterprise Modeling and Information Systems Architectures (EMISA 2017) Essen, Germany claudio.di.ciccio@wu.ac.at Di Ciccio, C., Maggi, F. M., Montali, M., Mendling, J. (2017). Resolving inconsistencies and redundancies in declarative process models. Information Systems, 64, 425–446. https://doi.org/10.1016/j.is.2016.09.005
- 59. Extra slides deck Resolving Inconsistencies and Redundancies in Declarative Process Models Claudio Di Ciccio, Fabrizio Maria Maggi, Marco Montali and Jan Mendling 8th International Workshop on Enterprise Modeling and Information Systems Architectures (EMISA 2017) Essen, Germany claudio.di.ciccio@wu.ac.at Di Ciccio, C., Maggi, F. M., Montali, M., Mendling, J. (2017). Resolving inconsistencies and redundancies in declarative process models. Information Systems, 64, 425–446. https://doi.org/10.1016/j.is.2016.09.005