Local Process Models - Local Process Model Discovery

5.3 Local Process Model Discovery

5.3.2 Local Process Models

Chapitre 5

Introduction

Dans ce chapitre, nous traitons des travaux de la littérature en process mining relative à la modélisation de processus, et détaillons plus particulièrement les variantes qui se rapportent à notre problématique.

Les techniques de Process Discovery peuvent être classées selon différents critères. Cer- taines de ces techniques produisent des modèles de processus utilisant des notations avec une sémantique formelle, dans lesquels les comportements autorisés par le modèle sont formellement définis. A l’inverse, d’autres techniques construisent des modèles de processus qui ne possèdent pas ce formalisme. Conjointement, les techniques de process discovery peuvent aussi être classées en techniques "globales" (ou "end-to-end") qui construisent des modèles représentant les observations présentes dans le log du début à la fin, et en techniques "locales" (ou "pattern-based"), qui produisent des modèles de processus décrivant les comportements observés dans le log seulement de manière partielle.

Technique Sémantique formelle Global/Local Fuzzy Miner [Günther and van der Aalst, 2007] Global Language-based regions [Bergenthum et al., 2007] 3 Global ILP miner [van der Werf et al., 2008] ₃ Global Declare Miner [Maggi et al., 2011] ₃ Global Inductive Miner [Leemans et al., 2013] 3 Global SUBDUE patterns [Diamantini et al., 2013] Local Episode Miner [Leemans and van der Aalst, 2014] Local MINERful [Ciccio and Mecella, 2015] 3 Global LPM Discovery [Tax et al., 2016b] ₃ Local Instance graphs [Diamantini et al., 2016b] Local Behavioral PM [Diamantini et al., 2016a] Local DPIL Miner [Schönig et al., 2016a] ₃ Global TBDeclare Miner [Di Ciccio et al., 2016] ₃ Global Split Miner [Augusto et al., 2017] 3 Global Tableau 5.1 – Classification d’une sélection de techniques de process discovery.

Il existe une pléthore de techniques de process discovery [van der Aalst, 2016]. Nous en présentons un aperçu représentatif dans le Tableau 5.1. Les techniques produisant un modèle avec une notation formelle sont annotées du symbole₃. Les techniques sont aussi réparties en fonction de leur périmètre global ou local.

La majeure partie des techniques de process discovery génère des modèles globaux, mais surtout procéduraux (aussi appelés impératifs). Un modèle procédural spécifie explicitement l’ordre des activités du début à la fin du processus. Lorsque le processus est flexible ; i.e., il autorise beaucoup d’ordres entre les activités, les techniques de process discovery qui produisent des modèles de processus procéduraux tendent à produire soit des modèles avec une généralisation trop élevée autorisant trop de comportements, soit des modèles de processus "en spaghetti" ; i.e., des modèles très complexes et peu compré- hensibles. Nous avons pu démontrer cela dans la première partie de ce manuscrit.

L’objectif de ce chapitre est de présenter des types de modèles alternatifs pour résoudre ce problème : les modèles locaux et les modèles déclaratifs. Contrairement aux modèles habituellement générés qui représentent les processus de bout en bout, les modèles locaux modélisent des fragments de comportements fréquents. Les modèles déclaratifs sont des

Section 5.2

modèles dont l’exécution n’est pas explicite, mais encadrée par un ensemble de règles. Ces deux types de modèles font l’objet des deux premières sections de ce chapitre.

Parmi les différentes techniques présentées, certaines sont plus adaptées pour répondre à nos problématiques. Dans la section,5.3, nous présentons la LPM Discovery, la technique de laquelle nous nous inspirons pour développer notre nouvelle approche.

5.1 Construction de modèles locaux

Les modèles locaux représentent une partie de processus. Dans la suite de cette section nous détaillons différentes façons de les représenter.

Local Process Model (LPM) Discovery [Tax et al., 2016b] est une technique qui construit de façon itérative un ensemble de modèles de processus locaux, les Local Process Models (LPMs) ; i.e., des fragments de processus décrivant des comportements fréquents. Ces modèles "partiels" ont un grand pouvoir d’expression, et sont capables de modéliser les choix, les parallélismes ou encore les boucles.

L’Episode Miner [Leemans and van der Aalst, 2014] est une technique à mi-chemin entre l’episode mining et le process mining. Cette technique extrait un ensemble d’épisodes, un épisode étant un ensemble d’events partiellement ordonnés, depuis un event log. Ce- pendant, un épisode est un type de construction dont le pouvoir d’expression ne permet pas de modéliser les boucles ou les choix exclusifs. De plus, cette technique ne permet pas d’être facilement adaptée pour considérer ces comportements non pris en compte.

Après avoir transformé chaque trace d’un log en Instance Graph [Diamantini et al.,

2016b] ; i.e., une représentation par graphe qui montre quelles activités sont exécutées

séquentiellement ou en parallèle ; le Behavioral PM [Diamantini et al., 2016a] est une technique qui effectue un graph clustering pour extraire les sous-graphes fréquents. Ce- pendant, les graphes ont un pouvoir d’expression limité aux séquences et aux parallélismes, et sont donc incapables de modéliser des situations de choix ou de boucles.

SUBDUE [Diamantini et al., 2013] est une technique un peu similaire qui, à partir d’un ensemble de modèles de processus transformés en graphes, extrait des comportements fréquents. Cependant, dans beaucoup de cas, soit il n’existe pas de modèles de processus a priori, soit ces modèles ne sont pas structurés.

De cette première catégorie de techniques, la LPM Discovery est à notre connaissance la seule qui génère des modèles ayant un pouvoir d’expression assez complet pour modéliser tous les comportements observables. De plus, cette technique utilise un event log comme donnée d’entrée. Par conséquent, de toutes les techniques citées qui génèrent des modèles "locaux", nous la considérons comme étant la technique la plus adaptée pour répondre à notre problématique. Dans la sous-section suivante, nous abordons les modèles déclaratifs et les comparons avec les modèles partiels construits par la technique de LPM Discovery.

5.2 Construction de modèles déclaratifs

Pour éviter la génération de modèles de processus "en spaghetti", il existe aussi les techniques qui construisent des modèles déclaratifs. Ces techniques de process discovery spécifient un ensemble de règles auxquelles les différentes exécutions du modèle doivent adhérer. Pour définir ces règles, elles utilisent un langage tel que Declare [Pesic and Van der

Chapitre 5

Aalst, 2006,Pesic et al., 2007,van der Aalst et al., 2009a], DPIL [Zeising et al., 2014] ou

SCIFF [Alberti et al., 2008]. Les modèles déclaratifs se distinguent des modèles procédu- raux dans le sens où ces derniers modélisent explicitement les comportements autorisés. De plus, ils sont très proches des modèles partiels construits par la technique de LPM Discovery.

Un exemple de contrainte est Response(a, b), indiquant que si l’activité a est exécutée, alors l’activité b peut éventuellement être exécutée. Les approches existantes (Declare, DPIL et SCIFF) utilisent un ensemble prédéfini de contraintes, et extraient les relations entre activités pour lesquelles ces contraintes sont respectées, d’après un seuil de support. Cela signifie que les comportements qui intéressent un analyste doivent être spécifiées a priori, avant que la construction du modèle n’ait lieu. Cette particularité différencie ces techniques de celle de LPM discovery, dans laquelle des relations unaires sont étendues en relations binaires, puis ternaires, et puis itérativement en relations n-aires plus complexes tant que le seuil de support minimum est respecté.

Certaines variantes de DPIL et SCIFF autorisent la définition de contraintes complexes, qui spécifient des relations n-aires arbitraires entre activités ; les contraintes "stan- dards" utilisées traditionnellement consistant en relations unaires et binaires, ne spécifiant pas de contraintes composées de plus de deux activités. Généralement, il faut combiner plusieurs contraintes pour spécifier une relation concernant plus de deux activités.

Le Target-Branched Declare (TBDeclare) [Di Ciccio et al., 2016], une variante de Declare, est une exception à cela dans la mesure où cette technique permet de définir des contraintes concernant plus de deux activités. Par exemple, Response(a, {b, c}) indique que si l’activité a est exécutée, l’activité b ou bien l’activité c peut éventuellement être exécutée. L1 h..., a, ..., b, ..., c, ...i40 h..., a, ..., b, ..., d, ...i50 (a) L2 h..., a, ..., b, ..., c, ...i5 h..., a, ..., b, ..., d, ...i5 h..., a, ..., b, ...i40 h..., b, ..., c, ...i40 h..., b, ..., d, ...i50 (b)

Figure 5.1 – Exemples de log pour évaluer les différences entre combinaisons de contraintes Declare et un LPM.

Cependant, une combinaison de contraintes n’est pas équivalente à un LPM composé des mêmes activités en termes d’informations véhiculées. Le Figure 5.2 illustre cette dif- férence. Considérons L1 et L2 les deux logs présentés dans la figure 5.1. ha, bix signifie

que l’exécution des activités de a puis b s’est produite x fois dans le log. En utilisant un support minimum de 0,7, la règle Response(a, b) serait extraite depuis L1 et L2, puisque

dans chaque log toute exécution de l’activité a est éventuellement suivie de l’exécution de l’activité b. De plus, la règle Response(b, {c, d}) serait aussi extraite depuis les deux logs selon le même support minimum, puisque toutes les exécutions de l’activité b sont suivies soit de l’exécution de l’activité c soit de l’activité d dans L1 et 100 exécutions de l’activité

b sur 140 sont suivies soit de l’exécution de l’activité c soit de l’activité d dans L2. Nous

présentons la combinaison des contraintes Response(a, b) et Response(b, {c, d}) dans la Figure 5.2c.

Section 5.2

a

90/90

_90/90b

c

40/40

d

50/50

(a) Support : 90

a

10/50

_10/140b

c

5/45

d

5/55

(b) Support : 10 a b Response Response c d (c)

Figure 5.2 – (a) Un LPM construit à partir de L1, (b) un LPM construit à partir de L2

et (c) une combinaison de deux contraintes TBDeclare construites à partir de L1 et L2.

Contrairement à une combinaison de contraintes, le support d’un LPM est évalué pour l’ensemble du LPM. Prenons le LPM présenté dans la Figure 5.2b. Un LPM est modélisé par un réseau de Petri dont les transitions sont représentées sous la forme (actX/Y ), avec act le label de l’activité modélisée, Y le nombre d’events dans le log ayant exécuté act, et X le nombre d’events de Y rejouables dans le LPM. Par exemple dans le LPM de la Figure 5.2b, la première transition représente l’activité a. Y = 50 car il y a 50 exécutions de l’activité a dans L2, et X = 10 car sur les 50 exécutions totales, seulement

10 sont rejouables dans le LPM (les traces h..., a, ..., b, ..., c, ...i et h..., a, ..., b, ..., d, ...i). Pour l’instant, considérons que le support d’un LPM est le nombre de fois que les exécutions possibles du LPM apparaissent dans le log. Les LPMs seront formellement définis dans la section suivante.

La méthode d’évaluation des LPMs est la raison du faible support de ce LPM. Construit à partir de L2, il indique que les exécutions de l’activité b qui suivent les exé-

cutions de l’activité a ne sont pas les même exécutions qui précèdent les exécutions des activités c et d. Ce LPM contraste donc le LPM présenté dans la Figure5.2a et construit à partir de L1, qui lui indique que les exécutions de l’activité b qui suivent les exécutions

de l’activité a sont bien celles qui précédent les exécutions des activités c et d. Nous constatons donc qu’un LPM ne porte pas les mêmes informations que la combinaison de contraintes TBDeclare composée des mêmes activités.

Dans les travaux présentés dans ce manuscrit, nous nous intéressons à l’utilité des relations extraites. Une variante de la construction de modèles déclaratifs est la construction de modèles déclaratifs dit "data-aware" ; i.e., qui prennent en compte les différents attributs disponibles dans les events. MP-Declare [Burattin et al., 2016] étend Declare dans ce sens. Dans [Maggi et al., 2013], les auteurs proposent une technique pour construire un modèle MP-Declare depuis un event log. A partir de différents types de conditions, MP-Declare se concentre sur une analyse exploratoire, dont l’objectif est d’extraire des relations fortes entre le "control-flow" ; i.e., l’enchaînement des activités dans le processus, et les attributs. La différence avec la problématique à laquelle nous voulons répondre est que cette technique ne prend pas en compte un besoin métier. A l’inverse, nous voulons proposer une approche dont l’objectif est de donner la possibilité à un utilisateur d’inter- roger un log à la recherche de fragments de comportements qui répondent spécifiquement

Chapitre 5

à une question métier qui l’intéresse.

Nous venons de présenter les modèles locaux et déclaratifs pour modéliser les processus peu structurés. Parmi les techniques présentées, la LPM Discovery est celle qui possède les caractéristiques adéquates pour répondre à notre problématique. D’une part, elle est capable de prendre en charge des processus complexes par la modélisation de fragments de comportements, et ce dans une notation possédant une sémantique formelle. D’autre part, elle génère des modèles avec un fort pouvoir d’expression, capable de modéliser un grand nombre de constructions. Ce sont pour ces raisons que nous avons choisi de nous inspirer de la technique de LPM Discovery pour développer la seconde partie de nos travaux.

5.3 Local Process Model Discovery

Dans cette partie, nous présentons la technique de LPM Discovery, que nous utilisons dans la suite de ce manuscrit.

La technique de LPM Discovery utilise les réseaux de Petri et les process trees pour re- présenter les LPMs. Grâce à leur structure, les process trees sont utilisés pour la construction des LPMs, et le formalisme des réseaux de Petri pour l’évaluation et la représentation des LPMs.

Après avoir présenté les réseaux de Petri dans la sous-section 5.3.1, nous définissons dans la sous-section 5.3.2 les Local Process Models (LPMs), et présentons comment la technique de LPM Discovery génère un ensemble de LPMs.

La technique de LPM Discovery, introduite dans [Tax et al., 2016b], génère des process trees dont la structure est légèrement différente de celle présentée par la Dé- finition13. D’une part, la procédure d’expansion utilisée a pour effet de ne construire que des process trees dont les nœuds-opérateurs ont exactement 2 enfants ; contre 2 ou plus dans la définition originale. Cela a pour effet de voir la contrainte stipulant qu’un nœud-opérateur de type Boucle doit avoir trois enfants (le do, le redo et la sortie) à n’avoir que le do et le redo comme enfants. L’activité de sortie est posi- tionnée sur un nouveau nœud du process tree. Par conséquent, la condition selon laquelle un nœud-opérateur ne pouvait être enfant d’un nœud-opérateur du même type est aussi relâchée.

D’autre part, pour des raisons de complexité algorithmique lors de l’évaluation des LPMs, les auteurs ont volontairement exclu l’opérateur de choix inclusif OR (∨) des opérateurs disponibles pour étendre un LPM. Cela restreint donc le pouvoir d’expression des LPMs. Cependant, la structure des LPMs et la modularité de la procédure d’expansion permettent très facilement d’inclure tout nouveau type d’opérateur.

Formalisation des Process Trees dans les LPMs

5.3.1 Les réseaux de Petri

Pour rappel, les Réseau de Petri sont des modèles composés de places représentés par des cercles, de transitions représentés par des carrés (ou des rectangles) et d’arcs orientés liant places et transitions. Une transition peut représenter une activité et lorsqu’elle est déclenchée elle consomme un jeton (représenté par un point noir) dans chacune de ses

Section 5.3

places d’entrée, et produit un jeton dans chacune de ses places de sortie. De cette façon, la distribution des jetons entre les différentes places représente les états du modèle, appelés marquages. Les activités silencieuses (τ ) sont représentées par des rectangles noirs, et les marquages initial et final indiquent dans quel état le processus doit commencer et finir.

Nous définissons formellement un Réseau de Petri labellisé comme suit.

Définition 30 - Réseau de Petri labellisé :

Un Réseau de Petri labellisé N =hP, T, F, ΣM, li est un tuple où P est un ensemble fini de

places, T est un ensemble fini de transitions tel que P ∩ T = ∅, F ⊆ (P × T ) ∪ (T × P ) est un ensemble d’arcs orientés, ΣM est un ensemble fini de labels représentant des activités,

et l : T 9 ΣM est une fonction qui affecte un label à chaque transition. Il existe aussi des

transitions non labellisées, appelées τ -transitions ou transitions silencieuses τ ∈ T avec τ /∈ dom(l).

Pour un nœud n ∈ P ∪ T , nous utilisons •n et n• pour désigner respectivement l’ensemble des nœuds d’entrée et de sortie de n, défini comme suit : •n={n0|(n0_{, n) ∈ F }}

et n • ={n0|(n, n0_{) ∈ F }.}

L’état d’un Réseau de Petri est défini par son marquage M ∈ NP, qui est un multi- ensemble de places. Un marquage est graphiquement représenté par le fait de placer M (p) jetons dans chaque place p∈P . Le réseau de Petri change d’état au cours des différents déclenchements de transitions. Une transition t est franchissable dans un marquage M si chaque place en entrée p∈ • t contient au moins un jeton. Une fois qu’une transition est déclenchée, un jeton est retiré de chaque place en entrée de t et un jeton est ajouté dans chaque place en sortie de t, résultant dans un nouveau marquage M0=M − •t + t•. Le déclenchement d’une transition passant d’un marquage M à un marquage M0 est noté M → Mt 0_{. M}

1 σ

→ M2 indique que le marquage M2 peut être atteint depuis le marquage

M1 en déclenchant la séquence de transitions σ∈T∗.

Souvent, il est utile de considérer un réseau de Petri combiné à un marquage initial et un ensemble de marquages finaux. Cela permet de définir le langage du réseau de Petri et de vérifier si un comportement fait partie des comportements autorisés par le réseau de Petri.

Définition 31 - Réseau de Petri marqué avec marquages finaux :

Un Réseau de Petri marqué avec marquages finaux est un 3-uple AP N = (N, M0, M F )

où N est un Réseau de Petri Labellisé, M0 ∈ NP représente le marquage initial de N , et

M F est l’ensemble des marquages finaux possibles, tels que ∀M1, M2 ∈ M F, M1 * M2.

Nous appelons une séquence σ ∈ T∗ une trace du réseau de Petri marqué avec marquages finaux APN si M0

→ Mf pour un marquage final Mf ∈ M F . Le langage d’un réseau de

Petri marqué avec marquages finaux, noté L(AP N ), est l’ensemble de toutes les séquences de labels appartenant à ses traces ; i.e., si σ est un trace de APN, alors l(σ) ∈ L(AP N ).

Nous présentons dans la Figure5.3a un exemple de réseau de Petri marqué avec marquages finaux. Les places qui appartiennent au marquage initial contiennent un jeton chacune, et les places qui appartiennent au marquage final ont un label fi avec i comme iden-

tifiant, ou sont simplement représentée par le symbole dans le cas où il n’existe qu’un seul marquage final. Le langage de ce réseau de Petri marqué avec marquages finaux avec ΣM={A, B, C}, est {hA, B, Ci, hA, C, Bi hA, B, B, Ci, hA, B, C, Bi, hA, B, B, B, Ci, ...}.

Nous définissons le langage n-limité d’un LPM, noté Ln(LP M ), comme étant le langage

Chapitre 5

C (a)

event id activity time cost 1 A 26-3-2017 13 :00 100e 2 B 26-3-2017 13 :25 500e 3 X 26-3-2017 13 :27 60e 4 B 26-3-2017 13 :30 400e 5 C 26-3-2017 13 :35 100e 6 C 26-3-2017 13 :42 500e 7 A 26-3-2017 15 :26 300e 8 B 26-3-2017 15 :27 50e 9 C 26-3-2017 15 :47 100e 10 B 26-3-2017 16 :10 250e 11 B 26-3-2017 16 :52 300e 12 X 26-3-2017 16 :59 10e (b) (c) A 2/2 B 5/5 C 2/3 (d)

Figure 5.3 – (a) Exemple de réseau de Petri marqué avec marquages finaux APN1. (b)

Trace σ issue d’un event log L. (c) Segmentation de σ sur APN1. (d) LPM LPM obtenu

en évaluant APN1 sur σ.

5.3.2 Local Process Models

En nous inspirant de [Tax et al., 2016b], nous définissons un Local Process Model comme suit. Un Local Process Model, noté LPM, décrit un fragment de comportement fréquent dans un event log, comportant généralement entre 3 et 5 activités. Au lieu de décrire tout le comportement observé dans les différentes traces, un LPM a pour objectif de représenter une partie de ces traces qui se répète souvent. Un LPM LN représente un comportement défini sur l’ensemble des labels ΣM et possède le langage L(LN ).

La technique de LPM Discovery propose une approche itérative pour construire des LPMs, et consiste en 4 étapes : (1) la génération, (2) l’évaluation, (3) la sélection et (4) l’expansion. Nous représentons ces étapes dans la Figure 5.4.

1. La génération :

L’objectif de la première étape est de générer l’ensemble des LPMs candidats CM1.

Chaque candidat est un process tree initial composé d’un nœud-feuille représentant une activité a appartenant à l’ensemble des activités du log, a ∈ ΣL. Un LPM composé d’une

seule activité est un LPM "initial". Il y a autant de LPMs initiaux candidats que d’acti- vités dans ΣL.

2. L’évaluation :

Dans l’étape d’évaluation, les différents LPM sont évalués selon une liste de mesures. Avant de présenter la liste de mesures utilisées par la technique de LPM Discovery, nous détaillons la méthode d’évaluation d’un LPM.

Pour évaluer un LPM sur un log L, chaque trace σ ∈ L est d’abord projetée sur l’ensemble d’activités ΣM du LPM ; i.e., σ0=σ ΣM.

Chaque trace projetée est ensuite segmentée en γ-segments, les segments de la trace qui sont rejouables dans le LPM, et en λ-segments, les segments de la trace qui ne sont

Section 5.3 (1) Génération initiale (2) Evaluation (3) Sélection (4) Expansion CM_i SCM_i ⊆ CM_i i=i+1 Support Confiance Déterminisme Adéquation Couverture supmin confmin determin adeqmin couvmin

Figure 5.4 – Fonctionnement de la technique de LPM Discovery.

pas rejouables dans le LPM ; i.e., σ0=λ1γ1λ2γ2λnγnλn+1 tel que γi ∈ L(LP M ) et λi ∈/

L(LP M ). Nous définissons Γσ,LP M la fonction qui projette la trace σ sur les activités du

LPM et obtient les segments qui sont rejouables dans le LPM ; i.e., Γσ,LP M=γ1· γ2· · · γn.

Considérons le LPM présenté dans la Figure 5.3a, et la trace présentée dans la Fi- gure 5.3b, avec πactivity(σ)=hA, B, X, B, C, C, A, B, C, B, B, Xi. La projection de σ sur

les activités du LPM donne πactivity(σ){A,B,C}=hA, B, B, C, C, A, B, C, B, Bi. Nous pré-

Dans le document Nouvelles approches pour la détection de relations utiles dans les processus : application aux parcours de santé (Page 159-171)