Plug-in Workflow patterns miner dans ProM

Les outils de découverte utilisent généralement diérents formats pour collecter ou lire les

traces d'exécutions et présentent leurs résultats dans diérents modèles de procédés. Ceci rend

dicile la (re)utilisation de diérents outils pour le même ensemble de traces d'exécutions et la

comparaison des résultats de découverte. Par ailleurs, certains de ces outils mettent en application

des concepts qui peuvent être très utiles pour d'autres outils, mais il reste dicile de les combiner

et les réutiliser dans des environnements indépendants. En conséquence, les chercheurs travaillant

sur des nouvelles techniques de découverte se retrouvent à construire une infrastructure de

dé-couverte à partir de zéro et à examiner leurs techniques d'une façon isolée, se déconnectant des

applications courantes. Pour répondre à ces diérentes issues, nous avons choisi d'implanter notre

approche de découverte comme un plug-in nommé Workflow patterns miner dans la

plate-forme ProM qui fédère un grand nombre d'outils et de techniques de découverte de procédés et

permet à ces plug-ins de coopérer d'une manière normalisée. Notons que le développement de ce

plug-in s'inscrit dans le cadre d'une collaboration inter-universitaires entre ECOO Nancy-france

et TU/e

34

Eindhoven-Hollande, supportée par le projet européen NoE-Interop

35

.

ProM est une plateforme extensible qui supporte une grande variété de techniques de

décou-verte de procédé sous forme de plug-ins. ProM ore une certaine exibilité sur le format d'entrée

et de sortie grâce à un ensemble d'outils de conversion. Il est également assez ouvert pour tenir

compte d'une réutilisation facile du code pour l'implantation de nouvelles technique de découverte

de procédé. Un autre dispositif important dans la plateforme ProM est qu'elle permet l'interaction

entre un grand nombre de plug-ins de traitement de traces d'exécutions, de conversion de modèles

de procédés, de découverte de workow, etc.

ProM est implanté en Java et contient plus de 90 plug-ins disponibles traitant de la

décou-verte de procédés, la vérication des modèles de procédés, la vérication des formules linéaires

logiques, la conformance entre le modèle de procédés et ses traces d'exécutions, et l'analyse de

performances. ProM supporte aussi l'importation et la conversion de plusieurs langages de

mo-délisation de procédé tels que : les réseaux de Petri (PNML, TPN), les graphes de transitions

états, YAWL, etc. Les plug-ins de découverte couvrent la découverte de ot de contrôle (Alpha

algorithme, découverte génétique, découverte multi-phase, ...), l'analyse de la perspective

orga-nisationnelle (Social Network miner, the Sta Assignment miner, ...) et la perspective données

(the Decision miner, ...). ProM est libre source, sous une licence publique commune, et peut être

téléchargé gratuitement

36

.

Comme nous l'avons indiqué, la base pour toutes les techniques de découverte de procédé est

les traces d'exécutions. ProM a développé un format générique XML de taces d'exécutions. Ce

format se base sur une comparaison complète des besoins d'entrée de divers outils de découverte

existants et les traces d'exécutions typiquement produites par les workows. Il supporte un grand

34Technische Universiteit Eindhoven

35www.interop-noe.org

nombre de ltres de traces d'exécutions, qui sont un outil nécessaire pour une structure de traces

d'exécutions commune. Ce composant peut traiter une grande variété de traces d'exécutions.

ProM est un environnement complètement pluggable. L'ajout de plug-ins dans ProM peut

être fait avec une facilité relative. Une fois le plug-in prêt et archivé dans un .jar spécique,

il peut être ajouté à la plateforme en modiant principalement quelques lignes aux chiers de

conguration (chiers d'extension .ini). Il n'y a aucun besoin de modier la plateforme ProM.

Ainsi, aucun changement du code de la plateforme principale n'est nécessaire, c.-à-d., de nouveaux

plug-ins de découverte peuvent être ajoutés sans recompiltation.

Pour l'implantation de notre plug-in Workflow patterns miner, nous avons pu proter

de plusieurs plug-ins et bibliothèques de la plateforme ProM. Essentiellement, le chargement,

la lecture, la conversion et le traitement des chiers de traces d'exécutions sont pris en charge

par des APIs génériques de ProM. ProM ore aussi un large panel d'outils d'analyse des traces

d'exécutions qui a pleinement simplié l'implantation de nos algorithmes d'analyse statistique

des traces d'exécutions nécessaires à notre approche de découverte de patrons de workows.

Figure 6.8 Le plug-in Workflow patterns miner dans ProM.

La gure 6.8 montre une capture d'écran de notre plug-in Workflow patterns miner dans

ProM. Nous pouvons observer que l'aspect graphique du plug-in suit l'ergonomie de la plateforme.

En eet, ProM recommande un panel graphique pour la visualisation des entrées/sorties du

plug-in. Correctement, au lancement de ProM l'utilisateur fera le choix entre les diérents types de

plug-ins existants. Après le choix des plug-ins de découverte, l'utilisateur fera le choix du chier

de traces d'exécutions à traiter. Notons que cette partie est prise en charge par la plateforme et

est identique à tous les plug-ins. Au lancement du processus de découverte, le plug-in entre en

jeu et prend la main dans un thread diérent.

Dans la gure 6.8, nous pouvons observer en particulier deux frames de notre application : une

qui concerne les traces d'exécutions et l'autre la visualisation du workow découvert. La première

frame sert à xer un certain nombre d'options sur la structure de traces d'exécutions pour dénir

la nature de la structure par le choix des événements traités. Notre choix sera porté sur une

structure simpliée (c.f. section 5.2.3), qui se limite au traitement de l'événement terminé dans

ces traces, si le processus de découverte concerne le ot de contrôle. Par contre, le choix d'une

structure de traces enrichie est nécessaire pour la découverte du comportement transactionnel. Le

deuxième frame concerne le schéma de workow découvert composé par l'ensemble des patrons qui

le constituent. Nous avons utilisé la bibliothèque graphique de visualisation de graphes nommée

Dot [Gra] pour la construction du graphe de workow.

Figure 6.9 Table de dépendances dans Workflow patterns miner.

Il faut également préciser que nous avons entamé un travail d'implantation pour améliorer

l'aspect visuel de notre plug-in pour répondre au besoin d'interaction avec l'utilisateur. Ce dernier

point est important parce que la re-ingénierie de procédés est souvent un processus interactif où

l'interprétation humaine est une connaissance additionnelle importante et peut être employée

pour améliorer l'exploitation du résultat du processus de découverte. Pour ce faire, nous avons

ajouté un bouton dans le deuxième frame de découverte pour la visualisation de diérentes

informations sur chaque activité concernant la fréquence des activités qui la précédent ou qui la

suivent, les activités qui lui sont parallèles et la taille de sa fenêtre de concurrence (c.f. gure

6.9).

L'implantation du plug-in Workflow patterns miner dans la plateforme ProM, nous a

per-mit de mener une étude comparative avec les autres techniques de découverte qui sont dans leur

majorité implantés dans ProM. Cette étude comparative a été la base du tableau comparatif que

nous avons présenté dans le chapitre précédent (c.f. tableau 5.8). Notons que notre comparaison

était d'ordre qualicatif, ne traitant que des aspects concernant certaines qualités et

caractéris-tiques des entrées/sorties. Une étude comparative d'ordre quantitative qui concerne la rapidité

et la complexité des algorithmes de découverte est erronée puisque les algorithmes de découverte

ne possèdent pas généralement les mêmes entrées/sorties qui sont une caractéristique nécessaire

à une étude comparative quantitative.

6.4.3 Synthèse

Dans cette section, nous avons présenté deux solutions logicielles que nous avons développées

pour la validation de nos techniques de découverte de patrons de workows. La première solution

consiste au développement du prototype Workflowminer qui se base sur des prédicats de Prolog

pour l'analyse des traces d'exécutions et la découverte de patrons de workows. Ce prototype

propose aussi un composant d'analyse de performances. Nous avons aussi implanté le plug-in

Workflow patterns miner dans la plate forme ProM. Ce plug-in a été sujet d'un ensemble de

tests de validation dans l'annexe D, où un panel d'exemples de workows ont été simulés et leurs

traces d'exécutions récupérées comme entrée test pour notre plug-in.

6.5 Conclusion

Dans ce chapitre, nous avons abordé plusieurs aspects pour la validation de notre approche

de modélisation et de découverte de workows transactionnels. Nous avons proposé, dans le cadre

d'un outil de modélisation de workow transactionnel, une extension du système de gestion de

workow Bonita pour l'intégration du comportement transactionnel. Par la suite, nous avons

proposé des outils pour la validation de nos techniques de découverte de workows. Ainsi, nous

avons présenté des outils pour la collecte de traces d'exécutions simulées ou réelles. Et, nous avons

implanté notre algorithme de découverte de patrons de workows dans deux environnements

diérents : le prototype Workflowminer qui est un environnement indépendant et autonome et

le plug-in Workflow patterns miner dans la plateforme commune ProM de découverte de

workows.

Néanmoins, notre approche pour la re-ingénierie de procédés par l'analyse des traces

d'exé-cution nécessite un eort d'implémentation supplémentaire pour intégrer particulièrement les

diérentes règles d'amélioration et de correction que nous avons proposées dans le chapitre

pré-cédent. Ainsi nous visons l'implantation d'un plug-in dont le rôle sera d'exploiter les résultats de

découverte pour proposer des suggestions d'amélioration et de correction aux concepteurs d'une

manière interactive. Cependant le dés majeur auquel nous faisons face an de répondre à cet

objectif est l'acquisition de cas d'utilisation réels contenant des anomalies conceptuelles causant

des échecs d'exécutions variés. En eet, l'exploitation de traces d'exécution simulées pour la

vali-dation de ce plug-in est loin d'être susante pour tirer les conséquences et percevoir les avantages

de l'utilisation notre approche de re-ingénierie de procédés par l'analyse des traces d'exécutions.

Bilan et perspectives

L'objectif de ce travail de thèse était d'assurer une (re)conception continue par l'analyse

des traces d'exécutions qui répond aux problèmes de abilité et d'évolution des procédés

métiers. Concrètement, nous nous sommes intéressés à développer une approche de abilisation

des exécutions de procédés métiers à travers une approche originale de découverte de workow.

Dans ce chapitre, nous voulons résumer notre travail de recherche par la présentation de notre

contribution, sa motivation, et son originalité (c.f. section 7.1). Ensuite, nous présentons quelques

perspectives à nos travaux de recherche (c.f. section 7.2).

7.1 Travail réalisé et contributions

Les approches actuelles de modélisation de procédés métiers se sont principalement inspirées

des (i) MTA en ce qui concerne la coordination transactionnelle et (ii) de l'approche traditionnelle

workow en ce qui l'ordonnancement des tâches. Or ces deux approches présentent des limites

pour intégrer les trois dimensions de exibilité, de correction et d'adéquation aux procédés

métiers. D'une part, les MTA assurent un bon niveau de correction au détriment des dimensions

exibilité et procédés métiers. D'autre part, les systèmes de workow classiques assurent un

bon niveau de exibilité et s'adaptent bien aux contextes de procédés métiers. Cependant, ils

ignorent relativement la dimension de correction.

Ayant ces trois dimensions comme principes directeurs, nous avons proposé un modèle de

workow transactionnel (WfT) qui permet (i) d'enrichir la description du modèle de workow

pour mieux exprimer les propriétés transactionnelles des activités et les dépendances

transac-tionnelles entre les activités et (ii) de modéliser des mécanismes de recouvrement en cas d'échec

d'exécution pour assurer des exécutions ables. Nous avons distingué en particulier entre le flot

de contrôle et le flot transactionnel d'un workow transactionnel. Le flot de contrôle,

qui est décrit à travers les patrons de workow, dénit l'ordre d'invocation des activités

com-posantes. Le flot transactionnel, qui est décrit à travers les propriétés transactionnelles des

activités et les dépendances transactionnelles entre les activités, dénit les mécanismes de

recou-vrement en cas d'échecs.

L'originalité de notre modèle de workow transactionnel est qu'il a pu réconcilier les

sys-tèmes de workow et les MTA. D'une part, un WfT peut être considéré comme un modèle de

workow classique qui reprend les patrons de workow les plus communs. D'autre part, il peut

être considéré aussi comme une transaction structurée où les activités composantes sont les

sous-transactions et les interactions sont les dépendances transactionnelles. Par rapport au modèle

de workow classique, notre modèle permet d'intégrer le flot transactionnel, un concept qui

a été (relativement) ignoré. Par comparaison aux MTA, notre modèle ore plus de exibilité et

d'adéquation aux procédés métiers.

Par ailleurs, les approches classiques de conception de procédés prennent généralement comme

point de départ les perceptions et les suppositions des concepteurs et sourent d'un manque

d'implication des utilisateurs tant dans la conception que la vérication. En plus, elles manquent

de mécanismes de correction permettant d'optimiser la structure du workow initialement conçue

du fait qu'elle analyse un modèle gé et ne traite pas du besoin d'évolution pendant la phase

d'exécution. An de répondre au besoin d'évolution et d'adaptation du schéma du workow suite

à des nouvelles contraintes d'exécution ou à des besoins d'évolution exprimés par l'utilisateur

après l'établissement du procédé, nous avons spécié une nouvelle étape d'amélioration et/ou de

correction du comportement transactionnel du workow par l'analyse des traces d'exécutions.

Une analyse statistique des traces d'exécutions à été être eectuée pour fournir l'entrée pour une

nouvelle phase de (re)conception dans le cadre d'une re-ingénierie du procédé.

Concrètement, nous avons utilisé les traces d'exécutions de workows dans une approche

ori-ginale de découverte de workow transactionnels qui dérive le modèle de workow eectif avec

aussi peu d'information que possible. Notre approche de découverte de workow transactionnel se

rapporte à des méthodes d'analyse statistique des traces d'exécutions. Nous avons commencé par

la découverte du flot de contrôle en décrivant un algorithme dynamique qui bâtit le résultat

nal (le workow nal) à partir de résultats locaux (les patrons de workow). Par la suite, nous

avons découvert le flot transactionnel du workow en capturant les dépendances

transaction-nelles intra-activité et inter-activités décrivant respectivement les propriétés transactiontransaction-nelles des

activités et les dépendances transactionnelles entre les activités.

Les résultats découverts sont utilisés par la suite pour améliorer et/ou corriger les mécanismes

de recouvrement du schéma de workow initialement conçu. La comparaison entre le modèle de

workow a posteriori (initialement conçu) au modèle a priori (découvert) nous a permis de

procéder à une Delta analyse relevant les disparités entre la conception bâtie dans la phase de

conception et l'exécution réelle enregistrée dans la phase d'exécution. Ces disparités peuvent être

synonyme d'un besoin d'évolution du schéma conceptuel du workow. En nous basant sur ces

disparités, nous avons proposé un ensemble de suggestions corrigeant et améliorant le schéma

du workow pour coller au mieux à la réalité de la phase d'exécution. Ces suggestions

res-pectent les caractéristiques sémantiques de notre modèle de workow transactionnel. De plus,

elles tiennent compte des besoins spéciques des concepteurs. En eet, les corrections induites

par ces suggestions ne sont pas faites d'une façon automatique mais plutôt interactive avec les

concepteurs pour qu'ils puissent préciser leurs besoins spéciques.

L'avantage majeur de cette approche, qui est d'une base théorique solide, est sa capacité de

coller au mieux à la réalité exprimée dans la phase d'exécution en reproduisant le modèle

dé-couvert comme base pour une nouvelle phase de (re)conception. Ainsi, nous pouvons détecter et

corriger les erreurs de la phase antérieure de conception et satisfaire les nouveaux besoins

d'évo-lution du procédé. En eet, notre approche comporte une méthodologie conceptuelle originale qui

repose sur des faits réels et non sur des hypothèses qui peuvent ne pas coïncider avec la réalité.

Elle facilite ainsi le diagnostic du procédé, dans le sens qu'en utilisant des cas réels les

concep-teurs peuvent proposer des corrections ou/et améliorations du comportement transactionnel du

workow pour un meilleur alignement avec la réalité.

Nous nous sommes attelés à mettre en ÷uvre et à valider nos propositions à travers le

déve-loppement et l'utilisation d'un certain nombre d'outils et d'applications. D'une part, nous avons

étendu le système de gestion de workows Bonita pour supporter notre modèle de workow

tran-sactionnel. D'autre part, nous nous sommes intéressés à la la validation de nos techniques de

dé-couverte de workows. Ainsi, nous avons présenté et développé des outils pour la collecte de traces

d'exécutions simulées ou réelles. Finalement, nous avons implanté notre algorithme de découverte

de patrons de workow dans deux environnements diérents : le prototype Workflowminer et le

plug-in Workflow patterns miner.

Dans le document La Découverte de Workflow<br />Transactionnel pour la Fiabilisation des<br />Exécutions (Page 147-154)