Gestion de changement et vérification formelle de processus métier : une approche orientée règle

Transcription

1 N d ordre 2010ISAL0016 Année 2010 Thèse Gestion de changement et vérification formelle de processus métier : une approche orientée règle Présentée devant L institut national des sciences appliquées de Lyon Pour obtenir Le grade de docteur Spécialité Informatique École doctorale Infomaths Par Mohamed Boukhebouze Soutenue le xxx devant la Commission d examen Jury MM. Youssef Amghar Aïcha-Nabila Benharkat Jean-Pierre Giraudin Corine Cauvet Ahmed LBATH Selmin Nurcan Zakaria Mamaar Professeur (INSA de Lyon), Directeur de thèse Maître de conférence (INSA de Lyon), Directrice de thèse Professeur (Université Pierre Mendès France), Président Professeur (Université Aix-Marseille), Rapportrice Professeur (Université Joseph Fourier), Rapporteur Maître de conférence (Université Paris 1), Examinatrice Professeur (Université Zayed), Invité Laboratoire de recherche : Laboratoire d Informatique en Image et Systèmesd Information

2

3 Remerciements

4 À ma chère épouse

5 Gestion de changement et vérification formelle de processus métier : une approche orientée règle Résumé Le travail proposé dans cette thèse traite de la flexibilité de la modélisation et la vérification des processus métier. L objectif étant, de permettre, d une part, une modélisation souple qui prend en compte la nature dynamique des éléments d un processus métier ; et d autre part, la vérification du déroulement du processus pour s assurer de son bon fonctionnement. Pour atteindre cet objectif, nous avons entrepris, dans le cadre de cette thèse, des recherches qui visent la construction d un modèle de processus basé sur un nouveau pattern de règles appelé ECAPE-M. Ce modèle permet de décrire un processus métier d une manière déclarative, en utilisant un ensemble de règles ECAPE. Le formalisme ECAPE est considéré dans nos travaux comme une extension du formalisme ECA, initialement défini par Evénement Condition Action, avec une post condition pour contrôler l exécution de l action d une règle et lancer une action de compensation dans le cas ou l exécution n est pas valide et avec un post événement pour décrire explicitement les événements qui seront générés par l exécution de l action de la règle pour construire un graphe d exécution du processus Le modèle ECAPE-M permet non seulement l expressivité de la nature dynamique des différents éléments d un processus métier mais aussi la vérification du bon fonctionnement d un processus. Nous proposons de considérer le modèle ECAPE-M selon trois plans d abstraction: Le plan métier où les processus sont définis par un ensemble de règles ECAPE. Nous proposons ici un nouveau langage, appelé ECAPE-L, qui utilise une syntaxe basée sur XML, pour décrire les éléments des processus métier. Ce nouveau langage déclaratif est proche des langages d exécution impératifs de processus tels que BPEL et XPDL car il peut être exécuté par un moteur de règles qui interprète les différentes instructions. Le plan comportemental où une démarche de gestion du changement d une règle dans le modèle ECAPE-M est mise au point. Cette démarche consiste à définir les relations entre les différentes règles, et traduire l ensemble des règles et relations en un graphe orienté appelé graphe d impact. L analyse de ce graphe permet de déterminer l ensemble des règles impactées par un changement et d estimer le coût de changement d une règle en terme de nombre d opérations de changement.

6 Le plan opérationnel où le modèle d un processus ECAPE-M est traduit en un réseau de Pétri coloré appelé ECAPE-net afin de modéliser la sémantique d exécution du processus. Notre contribution est validée par l élaboration de l architecture d une plateforme de modélisation et d analyse de processus métier appelé BP-FAMA (Business Process Framework for Agility of Modeling and Analysis). Notons qu un prototype simplifié, qui implémente différents composants de la Mots-Clés: modélisation des processus métier règles de gestion, règles métier langages déclaratifs gestion de changement graphe d impacts vérification des processus métier réseau de Pétri. A Rule-based Approach to Manage Change and Verify Flexible Business Processes Abstract Efficient organizations need to ensure that their business processes are flexible so that these processes can easily accommodate changes in regulations and policies. Appropriate techniques to model and verify these processes are required. In this manuscrit, we present a rule-based model, called ECAPE-M, that aims at improving the management of business processes in terms of flexibility and verification. This model extends the Event-Condition-Action (ECA) model and suggests formal tools for verification purposes. In this approach, the logic of a process is defined with a set of business rules that correspond to the policies in the organization. Each business rule is represented using the Event-Condition-Action-Post-condition-post-Event (ECAPE) formalisms. The representation of our rule-based approach requires a new declarative language that will offer the necessary syntax and semantics to describe ECAPE rules and the core elements in a business process. These elements are participants, variables, and activities. For this reason, we propose a new the rule-based business process definition language called ECAPE-L, which has an XML-based syntax to describe business processes in declarative way An advantage of the ECAPE-M is that a process can be easily translated into a graph of rules. This graph is used to first, look into the changes of rules by checking the relationships between the rules and second, estimate cost changes in a process.

7 Another advantage of the ECAPE-M is the translation of a process into a new colored Petri net called ECAPE net. An ECAPE net is used to check if a process satisfies some properties such as no Deadlock, and no Livelock. Finally, we proposed the BP-FAMA as an integration environment of the different elements we proposed. This environment consists of different tools namely:business Rules Definer; Business Rules behavior analyzer and Business Rules simulator Keywords: business processes modeling, business rule, declarative language, rule graph, flexible modeling and business processes verification.

8 Table des matières TABLE DES MATIERES 1 INTRODUCTION Contexte et terminologie Un processus métier La gestion de processus métier (BPM) La modélisation des processus métier La flexibilité de la modélisation Les règles métier Organisation de la thèse 7 PARTIE 1 : ETAT DE L ART 1 2 MODELES ET LANGAGES DE PROCESSUS METIER Introduction Le modèle impératif vs modèle déclaratif du processus métier Les langages impératifs de modélisation le processus métier Les Langages de définition de haut niveau Les Langages d exécution de processus métier La traduction des langages graphiques vers les langages d exécution Les langages déclaratifs de modélisation du processus métier Le paradigme case-handling Le paradigme de la logique temporelle linéaire (LTL) Le paradigme de logique déontique Le paradigme Event-driven process Le paradigme rule based modeling Conclusion 24 3 CARACTERISTIQUES DES MODELES & LANGAGES DE PROCESSUS METIER Introduction L expressivité de la modélisation d un processus métier La dimension fonctionnelle La dimension comportementale La dimension organisationnelle La dimension informationnelle La dimension opérationnelle Synthèse Un exemple d un processus métier La flexibilité de la modélisation des processus métier Les taxonomies de la flexibilité Les caractéristiques des langages de processus Les caractéristiques des langages impératifs Les caractéristiques des langages déclaratifs Conclusion 43

9 Table des matières 4 MODELISATION DES PROCESSUS METIER BASEE SUR LES REGLES Introduction Classification des règles et langages de règles Catégories de règles Les langages de règles La modélisation des processus métier par les règles de réaction Le formalisme ECA Les avantages des règles de réaction Les langages de processus basés sur les règles de réaction Les limites & chalenges des règles de réaction Conclusion 56 5 TECHNIQUES DE VERIFICATION DE PROCESSUS METIER Introduction Les erreurs et exceptions d un processus métier Les erreurs fonctionnelles Les erreurs opérationnelles Les erreurs non fonctionnelles Les techniques de vérification des processus métier La vérification par guides de style de modélisation La vérification par simulation La vérification par modèles formels La vérification par process-mining Synthèse Introduction aux modèles formels et aux réseaux de Pétri Définition Utilisation Classification Les réseaux de Pétri La vérification des processus métier La vérification dans le cas des langages impératifs La vérification dans le cas des langages déclaratifs Conclusion 73 PARTIE 2 : NOTRE CONTRIBUTION 74 INTRODUCTION 75 6 MODELE ECAPE-M Introduction Le formalisme ECAPE Modèle ECAPE-M Exemple illustratif L expressivité du flux de contrôle La séquence de règles Le parallélisme de règles La synchronisation de règles Le choix exclusif de règles La jonction simple de règles La boucle de règles Les différents plans du modèle ECAPE-M Le plan métier Le plan comportemental 88

10 Table des matières Le plan opérationnel Conclusion 89 7 LE LANGAGE ECAPE-L Introduction Les éléments du langage ECAPE-L Le processus Participants Les variables Les activités Les événements Les règles ECAPE Exemple illustratif L expressivité du langage ECAPE-L La représentation graphique du ECAPE-L Conclusion DEMARCHE DE GESTION DU CHANGEMENT D UN PROCESSUS METIER BASEE SUR LES REGLES Introduction Démarche de gestion du changement Les relations entre les règles Les relations de déclenchement Les relations de partage de variables Le graphe d impacts L impact du changement d une règle L ajout d une règle La modification d une règle La suppression d une règle Synthèse Le coût du changement d une règle Le degré de tolérance aux changements d un processus Conclusion VERIFICATION DU PROCESSUS METIER PAR LE ECAPE-NET Introduction Le ECAPE-net Les éléments du ECAPE-net Définition formelle du ECAPE-net Les règles de franchissement des transitions dans le ECAPE-net La construction des événements composés Exemple illustratif La vérification du processus par le ECAPE-net Propriétés du réseau bien structuré Propriétés de sureté Conclusion 171 PARTIE 3 : VALIDATION PLATEFORME BP-FAMA Introduction Architecture générale de BP-FAMA La phase de spécification La phase d exécution 175

11 Table des matières La phase de diagnostic Les outils de développement de BP-FAMA Editeur du langage ECAPE-L Gestionnaire du changement Simulateur d exécution Conclusion 183 PARTIE 4 : CONCLUSION GENERALE CONCLUSION GENERALE Résumé de la contribution Perspectives envisagées 189 BIBLIOGRAPHIE 191 ANNEXE 1 : ETAT DE L ART SUR LA GESTION DES PROCESSUS METIER (BPM) Introduction Terminologie Un processus Un processus métier La gestion des processus métier (BPM) Les racines du BPM L intégration métier Les Workflow Mesurer la performance et maîtriser les processus Le cycle de gestion d un processus La phase de modélisation La phase d exécution La phase de diagnostique Les systèmes de gestion des processus (BRMS) Conclusion 223 ANNEXE 2 : SCHEMA XML DU LANGAGE RBBPDL 225

12 Table des matières LISTE DES FIGURES Figure 2.1 Exemple de la modélisation impérative et de la modélisation déclarative 11 Figure 2.2 L historique des différents langages impératifs 13 Figure 2.3 Une représentation BPMN du processus de traitement de commande 16 Figure 2.4 Le sous processus BPEL de traitement de commande 20 Figure 3.1 Le patron de séquence 28 Figure 3.2 Le Patron de Parallélisme 28 Figure 3.3 Le patron de synchronisation 29 Figure 3.4 Le Patron du choix exclusif 29 Figure 3.5 Le patron de jointure simple 29 Figure 3.6 La Modélisation du Processus de traitement de Commande 34 Figure 3.7 La taxonomie de la flexibilité proposée par Regev 37 Figure 4.1 Les langages de règles aux différents niveaux d'abstraction 48 Figure 5.1 La classification des différents modèles formels 64 Figure 5.2 Le processus de traitement de commande modélisé en RdP 66 Figure 5.3 Les principales démarches de vérification d un processus métier par les RdP 69 Figure 6.0 Le positionnement de notre contribution par rapport aux travaux existants 77 Figure 6.1 La modélisation d un processus en utilisant le modèle ECAPE-M 78 Figure 6.2 La modélisation ECAPE-M du processus de traitement de commande 82 Figure 6.3 La modélisation de séquence de règles par le modèle ECAPE-M 84 Figure 6.4 La modélisation du parallélisme de règles par le modèle ECAPE-M 84 Figure 6.5 La modélisation de la synchronisation de règles par le modèle ECAPE-M 85 Figure 6.6 La modélisation du choix exclusif de règles par le modèle ECAPE-M 86 Figure 6.7 La modélisation la jonction simple de règles par le modèle ECAPE-M 86 Figure 6.8 La modélisation de la boucle structurée de règles par le modèle ECAPE-M 87 Figure 6.9 Les différents plans du modèle ECAPE-M 88 Figure 7.1 Le méta-modèle du langage ECAPE-L 92 Figure 7.2 Un processus métier décrit par le ECAPE-L 93 Figure 7.4 les symboles utilisés dans URML for BP 114 Figure 7.5 Un diagramme UMRL for BP d un sous processus du traitement de commande 115 Figure 8.1 Le démarche de gestion du changement d un processus ECAPE 120 Figure 8.2 La relation de déclenchement en série 122 Figure 8.3 Exemple de deux règles en relation de déclenchement en série 123 Figure 8.3 La relation de déclenchement multiple 124 Figure 8.4 Exemple de règles en relation de déclenchement multiple 125 Figure 8.5 La relation de déclenchement de jointure 126 Figure 8.6 Exemple de règles en relation de déclenchement de jointure 127 Figure 8.7 Exemple de règles en relation de partage de variables Condition-Action 128 Figure 8.8 Exemple de règles en relation de partage de variables Action-Action 129 Figure 8.9 Exemple de règles en relation de partage de variables Action-Post condition 131 Figure 8.10 Le graphe de règle du processus de traitement de commande 133 Figure 8.11 les facteurs qui influencent l impact du changement 134 Figure 8.12 les différents graphes d opérations d ajout et de modification d une règle r i 146 Figure 8.13 le graphe d opérations de suppression de la règle r i 147 Figure 8.14 le graphe d opérations de suppression de la règle r Figure 9.1 Modélisation d une règle ECAPE dans un Pétri ECAPE-net 155 Figure 9.2 Eléments du réseau de Pétri ECAPE-net 156 Figure9.3 Patrons des transitions CANCEL and SKIP 161 Figure9.4 Construction de la conjonction d événements dans ECAPE-net 162 Figure9.5 Construction de la disjonction d événements dans ECAPE-net 162

13 Table des matières Figure9.6 Construction de l événement NOT dans ECAPE-net 163 Figure9.7 Construction d une séquence d événements dans ECAPE-net 163 Figure9.8 Construction d une simultanéité d événements dans le ECAPE-net 164 Figure9.9 La construction d une multi-occurrence d un événement dans ECAPE-net 164 Figure9.10 Construction d un événement ANY dans ECAPE-net 165 Figure9.11 Le ECAPE-net du processus de traitement de commande 166 Figure 10.1 L architecture de la plateforme BP-FAMA 174 Figure 10.2 Le processus GMF de génération d éditeur graphique 178 Figure 10.3 L éditeur graphique du langage ECPAPE-L 179 Figure 10.3 L éditeur graphique du langage ECPAPE-L 180 Figure 10.4 le calcul du coût du changement d une règle 181 Figure 10.5 Le diagramme de transformation du modèle ECAPE-M vers un réseau ECAPE-net _182 Figure 10.6 L interface de l outil PIPE 183

14 Introduction 1 Introduction 1.1 Contexte et terminologie Un processus métier La gestion de processus métier La modélisation des processus métier La flexibilité de la modélisation Les règles de gestion 1.2 Motivation & Problématique 1.3 Contribution 1.4 Organisation de la thèse 1.1 Contexte et terminologie Avec la naissance des nouvelles technologies de l information, les entreprises se voient, aujourd hui, dans l obligation d informatiser l ensemble des activités au tour de leur processus métier. En effet, un fonctionnement efficace des organisations, impose de s appuyer sur des processus métiers robustes, et adaptés à leurs activités. La définition et l exécution des ces processus nécessitent respectivement un modèle et des outils pour permettre la collaboration, la définition, le déploiement, l'exécution, et le contrôle des processus. La gestion des processus appelée BPM (Business Process Management, ou gestion des processus métier) consiste à gérer de bout en bout les processus métiers de l'entreprise pour en avoir une meilleure vue. Il est important de permettre aux décideurs, analystes métiers, équipes fonctionnelles et équipes techniques de collaborer à la définition et l évolutivité des processus métiers via un seul outil agrégeant les différentes visions. Il est également nécessaire d'optimiser ces processus et, tenter de les automatiser au maximum à l'aide d'applications métier. Dans la section qui suit, nous introduisons la terminologie utilisée dans la discipline BPM. Notons que cette terminologie sera détaillée dans l annexe 1. 1

15 Introduction Un processus métier Un «processus métier» ou un «processus d'affaires» (en anglais Business Process) désigne les activités qui s appuient sur un ensemble de tâches et du savoir faire d une entreprise pour produire une valeur ajoutée aux clients. Le Workflow Management Coalition 1 (WfMC) définit un processus métier comme : «un ensemble d'une ou plusieurs procédures ou activités liées entre elles pour réaliser collectivement un objectif ou une politique métier en définissant les rôles et les interactions fonctionnelles au sein d une structure organisationnelle» [WfMC99]. Ces processus sont des processus opérationnels qui décrivent l ordre d exécution des activités principales de l'entreprise en transformant les éléments d'entrée en éléments de rendement pour atteindre un objectif métier ou stratégique. Les processus métier sont le patrimoine de l entreprise. Un processus métier est, donc, considéré comme un ensemble de relations logiques entre un groupe d activités incluant des interactions entre partenaires sous la forme d échange de données pour fournir une valeur ajoutée aux clients La gestion de processus métier (BPM) Van der Aalst et al. définissent le BPM (Business Process Management) comme : «la gestion des processus métier en utilisant des méthodes, des techniques et des logiciels pour modéliser, exécuter, contrôler et analyser les processus opérationnels en s appuyant sur des acteurs qui peuvent être : des êtres humains, organisations, des applications, documents et autres sources d'information» [Van03 a]. En effet, le BPM consiste à gérer les processus métier: (1) sur un plan global en cherchant à prendre en compte les processus de bout en bout, depuis la chaine d approvisionnement jusqu aux activités internes et externes d une entreprise. (2) sur un plan de cycle de gestion en s intéressant aux différentes étapes du cycle de vie des processus depuis la modélisation jusqu à l exécution et le diagnostic. 1 La WfMC regoupe plus de 300 participants académiques et industriels. 2

16 Introduction La modélisation des processus métier La modélisation est une phase primordiale dans la gestion des processus métier, dans laquelle, les concepteurs définissent, d'une manière abstraite ou détaillée, les processus métier ou redéfinissent un processus existant dans le but de l'améliorer. Pour cela, des modèles et des langages sont utilisés afin de permettre de décrire les éléments de base d un processus. En effet, cette phase est composée de trois étapes [Cru03]: (1) la première étape permet de définir un processus de haut niveau, indépendamment des aspects techniques. Le concepteur y décrit seulement la structure, les ressources nécessaires et les interfaces du processus grâce à des langages graphiques comme UML [OMG08] et BPMN [OMG09]. (2) La deuxième étape de la phase de modélisation est la configuration des processus abstraits où les détails fonctionnels du processus sont spécifiés. Le concepteur décrit de nombreuses informations techniques telles que : le format des messages échangés, les protocoles de transport utilisés, les services et les applications invoquées dans le processus. Dans cette étape, des langages d exécution sont utilisés comme XPDL [WfMC08] et BPEL [OASIS07]. (3) La dernière étape de cette phase est l'évaluation du processus exécutable en utilisant les techniques de simulation (BPS : Business Process Simulation) ou de la vérification formelle (comme les réseaux de Pétri) en vue de s assurer du bon fonctionnement du processus avant son exécution. Dans cette étape, le processus peut être optimisé en utilisant les résultats de simulation pour définir des éventuelles améliorations. Le processus est ensuite redéfini et simulé ou vérifié de nouveau La flexibilité de la modélisation La notion flexibilité de la modélisation est utilisée pour désigner la capacité de mettre en œuvre les changements dans un processus métier en ne modifiant que les parties qui ont besoin d'être changées tout en gardant la stabilité des autres parties du processus [Rev06]. Une modélisation de processus est flexible si elle est capable d être modifiée sans la remplacer complètement Les règles métier Selon le groupe BRG (Business Rules Group) les règles métier (ou règles de gestion, ou business rules en anglais) sont des définitions de haut niveau 3

17 Introduction structurées, qui permettent de contraindre, contrôler et influencer un aspect du métier [BRG02]. En effet, elles implémentent la stratégie ou les politiques d une entreprise et elles permettent d'influencer les prises des décisions et contrôler les comportements métiers. 1.2 Motivation & Problématique La gestion de processus métier (BPM) permet, aujourd hui, la définition et l évolutivité des processus métiers via un seul outil agrégeant différentes visions. Cette discipline est née du mariage de plusieurs techniques proposées pour répondre au besoin d intégration métier, d automatisation de flux d information et de gestion de la qualité. Par ailleurs, la discipline BPM a donné naissance à plusieurs challenges de recherche, comme la modélisation des processus métier en prenant en compte le besoin de réingénierie de processus, de la flexibilité, de l adaptation au changement et également de la vérification de bon fonctionnement du processus par des modèles formels ou par simulation. Dans cette thèse, nous nous sommes intéressés à la modélisation des processus métier. L objectif étant, de permettre, d une part, une modélisation souple qui prend en compte la dynamicité des différents éléments de processus métier. D autre part, l objectif est aussi de permettre de vérifier le déroulement du processus exécutable pour s assurer du son bon fonctionnement. Autrement dit, améliorer la gestion des processus en garantissant une adaptation au changement et une facilité d analyse du bon fonctionnement du processus. En effet, dans la littérature on distingue deux approches de modélisation de processus. La première approche, appelée impérative, se focalise sur «quoi faire» en définissant explicitement l'ordre des activités du processus. La deuxième approche, appelée déclarative, se focalise sur «ce qui devrait être fait» en définissant implicitement l'ordre des activités du processus. L approche impérative se concentre sur la définition précise de la façon dont un ensemble d activités doit être effectué (c'est-à-dire, l'ordre des activités est explicitement défini). L'ordre d'exécution est décrit en utilisant les liens (ou connecteurs) entre les activités. Plusieurs langages, basés sur cette approche ont été proposés (exemple BPEL, XPDL). Ces langages impératifs sont maintenant stables et se sont adaptés aux besoins du 4

18 Introduction marché car ils assurent une grande expressivité en permettant de modéliser un bon nombre de patrons de workflow «Workflow patterns» [WPI09, Rus04 a, Rus04 b] et répondent aux difficultés liées à l analyse du bon fonctionnement du processus en utilisant les «model checking» (par exemple les réseaux de pétri [Mar03, Ouy05, Yan05]). Toutefois, l utilisation du modèle impératif dans la définition des processus métier, oblige les concepteurs à décrire explicitement les scénarii d exécution dans la phase de modélisation. Cette pratique rend les processus métier rigides et difficiles à maintenir. La nature dynamique des environnements des organisations, rend les éléments du processus susceptibles d être modifiés ou supprimés. Le fait de définir explicitement, dans la phase de modélisation, la façon dont les processus devraient procéder compromet la dynamicité du modèle. La flexibilité est devenue l intérêt majeur des entreprises et cela pour améliorer leur productivité, et leur rapidité d adaptation aux changements. Dans ce contexte, une deuxième approche de modélisation de processus dite déclarative a été proposée. Cette se concentre sur «ce qui devrait être fait» au lieu de «quoi faire». Pour cela, des contraintes sont utilisées pour restreindre les possibilités d exécution des activités d un processus. En effet, dans un modèle déclaratif tous les chemins d'exécution, qui ne violent pas les contraintes, sont autorisés. Ces contraintes remplacent, donc, les connecteurs entre les activités. Plusieurs langages déclaratifs ont été proposés tels que : PLM flow [Zen02], ConDec [Pes06] et PENELO- PE [Geo06 a]. Dans ces langages, un processus est vu comme un ensemble d états et un ensemble de contraintes qui contrôlent les transitions d un état vers un autre. Plusieurs paradigmes sont utilisés pour représenter les états et les contraintes tels que : case-handlin, la logique temporelle linéaire, la modélisation basée sur les règles. Les langages déclaratifs offrent, d une part, une bonne expressivité. Ils offrent également, une flexibilité de modélisation car en utilisant ces langages, les concepteurs évitent d énumérer explicitement tous les scénarii d'exécution possibles dans une modélisation. Cette énumération est souvent difficile à obtenir et peut conduire à la rigidité de la modélisation. Cependant, le fait de permettre aux scénarii d exécution de rester implicites dans la phase de modélisation du processus, rend la vérification et l analyse du bon fonctionnement du processus plus complexe. Les recherches que nous menons dans ce mémoire de thèse visent à remédier aux lacunes et problèmes liés à la gestion du changement et la vérification du processus métier. Notre objectif est de proposer un modèle de processus basé sur les règles qui permet d offrir une flexibilité à la modalisation et une fiabilité à l exécution du processus. En effet, l utilisation 5

19 Introduction du modèle déclaratif nous semble intéressante. D autant plus, nous sommes convaincus que l utilisation de la modélisation basée sur les règles permet de gagner en flexibilité et en adaptation au changement. Cela permet aussi de définir les règles métiers, d une manière rigoureuse, concise et précise. À partir des ces constats, nous avons dégagé les problèmes suivants : 1- Quel formalisme de règle est le plus adapté pour modéliser un processus métier? 2- Comment peut-on construire un graphe d exécution de processus à partir d un modèle déclaratif? 3- Comment peut-on contrôler l exécution d une règle? 4- Comment peut-on gérer le changement d une règle du processus pour garder la cohérence du processus et pour estimer le coût de ce changement? 5- Comment peut-on mesurer le degré d influence d un processus aux changements de ses éléments? 6- Comment peut-on vérifier formellement un processus défini d une manière déclarative? 1.3 Contribution Notre solution aux problèmes énoncés précédemment se décline en quatre contributions formant une démarche outillée allant de la définition du processus jusqu à sa vérification, à savoir : 1- Nous proposons, un modèle de définition des processus métier basé sur les règles métier. Dans ce modèle, un processus métier est spécifié par un ensemble de règles qui utilisent le formalisme ECAPE (Evènement Condition Action Post condition post Evénements [Compensation ou Evénement d erreurs] (ECAPE-CE abrégé ECAPE). Le formalisme que nous proposons étend le formalisme ECA afin de permettre une description explicite des événements qui seront provoqués par l exécution de l action de la règle pour construire un graphe d exécution du processus (une vue fonctionnelle du processus). Cette extension permet de surcroît, de contrôler l exécution de chaque action d une règle et de lancer des mécanismes de compensation si l exécution n est pas valide. Le modèle que nous proposons se base sur les règles utilisant ce formalisme, est appelé ECAPE-M. 6

20 Introduction 2- En se basant sur les concepts et fonctionnement du modèle (ECAPE-M) que nous proposons dans le chapitre 6, nous définissons un nouveau langage déclaratif de description et d exécution de processus métier appelé ECAPE-L. Ce nouveau langage se base sur les règles métier et permet de garantir une flexibilité de la modélisation, d augmenter l expressivité en héritant la syntaxe des langages impératifs les plus utilisés dans l industrie (BPEL, XPDL). 3- Nous proposons de transformer la définition du processus, décrite par le modèle ECAPE-M, en graphe d impact du changement des règles afin d en estimer le coût. Ce graphe modélise la séquence d exécution des règles ainsi que les relations qui existent entre les règles. En effet, la nécessité de prendre en compte la dynamicité des différents éléments d un processus, nous pousse à mettre l emphase sur la relation entre les règles pour assurer une gestion automatique du changement. De cette façon, nous pouvons déterminer l'ensemble de règles qui doivent être changées après le changement d'une règle dans un processus afin d en estimer le coût. Pour cette raison, nous avons déterminé trois classes de relations entre les règles : relations d activation, relations de partage de variables et relations de cause à effet (voir chapitre 8). 4- Nous proposons de transformer la définition du processus, décrite par le modèle ECAPE-M, en un réseau de Pétri appelé ECAPE net afin de modéliser la sémantique d exécution de l ensemble de règles du processus et pouvoir vérifier formellement le bon fonctionnement du processus. En effet, pour aider le concepteur à trouver les erreurs fonctionnelles dans un processus ECAPE, nous avons opté pour les réseaux de Pétri (RdP) en raison de leur grande capacité à simuler et analyser l exécution des processus métier. 1.4 Organisation de la thèse Ce document est structuré de la manière suivante : - La partie 1 dresse un état de l art des travaux liés à notre problématique. Nous détaillons dans le chapitre 2 les différents modèles et langages de définition des processus métier proposés. Dans le chapitre 3 nous présentons une comparaison entre les modèles et langages de définition des processus en se basant sur deux critères qui sont au cœur de nos préoccupa- 7

21 Introduction tions à savoir l expressivité et la flexibilité. Nous distinguons dans le chapitre 4 les différents formalismes de règles ainsi que les langages de modélisation des processus basés sur les règles proposés. Dans le chapitre 5, nous décrirons les nombreux travaux sur les techniques de vérification des processus métier. - La partie 2 se compose de quatre chapitres qui constituent notre contribution. Le chapitre 6 présente le formalisme ECAPE ainsi que le modèle de définition des processus ECAPE-M en illustrant notre proposition avec un exemple de processus de traitement de commande. Le chapitre 7 détaille comment décrire les différents éléments du processus à l aide du langage ECAPE-L. Dans le chapitre 8 nous présentons notre démarche de gestion du changement de processus. Nous détaillons dans le chapitre 9 le réseau de Pétri ECAPE net qui permet de modéliser la sémantique d exécution du modèle ECAPE-M et de vérifier formellement le bon fonctionnement du processus - La partie 3 constituée de deux chapitres présente dans le chapitre 10, la plateforme BP-FAMA qui permet de modéliser un processus métier en utilisant le modèle ECAPE-M et le langage ECAPE-L. Dans cette partie nous détaillons les différents algorithmes utilisés dans la gestion du changement et la transformation du modèle en réseau de Pétri. Le chapitre 11 termine ce mémoire par une conclusion qui discute les apports de notre travail, ainsi que les perspectives de recherche envisagées. Notons que ce document comporte 2 annexes pour définir avec plus de détails les différentes terminologies utilisées dans ce mémoire (annexe1) ainsi que le schéma XML du langage ECAPE-L (annexe 2). 8

22 Partie 1 Etat de l art

23 Etat de l art / Modèles & langages des processus métier 2 Modèles et langages de processus métier 2.1 Introduction 2.2 Le modèle impératif vs modèle déclarative 2.3 Les langages du modèle impératif Langages impératifs de définition de haut niveau de processus métier Langages impératifs d exécution de processus métier La traduction des langages graphique vers les langages d exécution 2.4 Les langages du modèle déclaratif Le paradigme case-handling Le paradigme logique temporelle linéaire (LTL) Le paradigme logique déontique Le paradigme Event-driven process Le paradigme rule based modeling 2.5 Conclusion 2.1 Introduction La phase de modélisation de processus est primordiale car elle permet de décrire la chaîne de valeur d une entreprise. Pour cela, des modèles et des langages doivent être utilisés pour permettre la définition des processus et la spécification des connaissances métier d une entreprise. En effet, un modèle de processus est une représentation théorique qui décrit la manière dont nous concevons le fonctionnement du processus. Le langage de modélisation du processus métier véhicule le fonctionnement du processus (le modèle) en utilisant une syntaxe qui détermine la bonne construction des expressions représentant les éléments du processus et une sémantique qui détermine la manière dont les expressions du langage doivent être interprétées. Dans ce contexte, plusieurs modèles et langages de processus ont été proposés. Ces modèles et langages diffèrent dans la manière de représenter les éléments du processus ; la manière de modéliser les politiques (les directives définies en interne impliquant les stratégies et les procédures opérationnelles de l entreprise) et les réglementations (les directives imposées de l'extérieur tels que les exigences juridiques, les normes et les contrats) ; et la manière de réduire le temps d'implémentation du processus et optimiser le coût de changement d un processus. En effet, on distingue souvent deux approches de modélisation de processus. La première approche, appelée impérative, se focalise sur «quoi 10

24 Etat de l art / Modèles & langages des processus métier faire» en définissant explicitement l'ordre des activités du processus. La deuxième approche, appelée déclarative, se focalise sur «ce qui devrait être fait» en définissant implicitement l'ordre des activités du processus. Dans ce chapitre nous allons nous intéresser à ces deux modèles de description de processus métier, en présentant les différents langages qui utilisent ces modèles pour définir un processus métier. 2.2 Le modèle impératif vs modèle déclaratif du processus métier Une modélisation des processus métier permet de représenter le fonctionnement d un processus en spécifiant ensemble des activités à exécuter et en définissant l ordre d exécution des ces activités. C'est sur cette définition que les approches de modélisation de processus métier divergent. En effet, dans la littérature, le comportement du processus peut être défini d une manière explicite (l approche impérative) ou d une manière explicite (l approche déclarative). (A) La modélisation impérative (B) La modélisation déclarative Figure 2.1 Exemple de la modélisation impérative et de la modélisation déclarative Selon Schonenberg et al., dans [Sch07], l approche impérative se concentre sur la définition précise de la façon dont un ensemble d activités doit être effectué (c'est-à-dire, l'ordre des activités est explicitement défini). Pour cela, dans la modélisation impérative, l'ordre d'exécution est décrit en utilisant les liens (ou connecteurs) entre les activités. A son tour, l approche déclarative se concentre sur «ce qui devrait être fait» au lieu de «quoi faire». Pour cela, des contraintes sont utilisées pour restreindre les possibilités d exécution des activités d un processus. En effet, dans les langages déclaratifs tous les chemins d'exécution, qui ne violent pas les contraintes, sont autorisés, Ces contraintes remplacent, donc, les connecteurs entre les activités. La figure 2.1 donne un exemple de ces deux approches de modélisation des processus où pour chaque approche, un ensemble de chemins d'exécution possibles est illustré. Notons que l approche déclarative offre beaucoup plus de chemins d'exécution. 11

25 Etat de l art / Modèles & langages des processus métier Modèle impératif Modèle déclaratif Modèle de granularité Centré-processus Centré-activité Description des flux de contrôle Explicite Implicite Définition du scenario d exécution Phase de modélisation Phase d exécution Gestion des événements Evènements simples Evènements complexes Exécution du processus Totalement-spécifiée Partiellement-spécifiée Langages Impératifs Déclaratifs Tableau 2.1 Le modèle impératif vs modèle déclaratif [Sch07] Le tableau 4.1 présente une comparaison entre les deux approches de modélisation de processus. Premièrement, dans la modélisation impérative qui est orientée processus, le concepteur modélise le processus de façon globale. Tandis que la modélisation déclarative est orientée activités où les contraintes qui restreignent les possibilités d exécution des activités sont prises en compte. Par ailleurs, l approche impérative propose souvent d utiliser des événements simples. Contrairement à l approche déclarative qui propose de gérer les événements complexes (composés) car cette manière de modéliser utilise les événements pour déclencher l exécution des activités. Ceci étant, la modélisation impérative exige l exécution des processus totalement spécifiés. A l inverse de la modélisation déclarative qui permet l exécution des processus partiellement spécifiés. Finalement, pour représenter la modélisation impérative en utilisent les langages impératifs (exemple BPEL, XPDL). Tandis que, les langages déclaratifs (exemple ConDec, PLM flow) sont utilisés pour véhiculer les modèles déclaratifs. Dans ce qui suit nous allons nous intéresser aux langages impératifs et aux langages déclaratifs. 2.3 Les langages impératifs de modélisation le processus métier Une première famille de langages de modélisation concerne les langages impératifs (ou langages procéduraux) qui se focalisent sur comment les différentes activités du processus sont exécutées [5] (c.à.d. le scénario d exécution qui représente une suite ordonnée d activités est décrite d une manière explicite). 12

26 Etat de l art / Modèles & langages des processus métier Figure 2.2 l historique des différents langages impératifs [Leu07] Dans cette famille de langages, plusieurs langages impératifs de modélisation des processus métier ont été proposés (voir la figure 2.2). Parmi ces langages, on trouve des langages de modélisation de haut niveau (exemple BPMN, UML), et des langages d exécution (exemple XPDL, BPEL) Les Langages de définition de haut niveau On peut citer UML [OMG08 a], YAWL [Van02], BPMN [OMG09] qui utilisent des notations graphiques permettant de décrire, de façon intuitive, des processus métier. Cette manière conviviale augmente essentiellement la compréhension et la lisibilité des ces processus et permet d évaluer la modélisation et générer ensuite le code exécutable associé Le diagramme d activité d UML UML (Unified Modelling Language) est un standard proposé par OMG (Object Management Group) pour la modélisation graphique utilisé dans le développement orienté objet. Il est devenu un langage incontournable dans le domaine du génie logiciel, et cela parce qu il offre la possibilité d exprimer les besoins et exigences en utilisant plusieurs diagrammes (diagramme de classes, diagramme d activités, etc.) et parce qu il offre aussi plusieurs concepts pour augmenter la sémantique des modèles (stéréotype, profil, etc.). UML est utilisé aussi pour modéliser les processus métier et cela en utilisant le diagramme d activité et le profil dédié à la définition des processus. En effet, le diagramme d activités de la version 2.0 de ce langage a été revu pour être mieux adapté à la modélisation des processus 13

27 Etat de l art / Modèles & langages des processus métier [Rus06 a]. Cependant, l utilisation d un profil dédié peut engendrer une hétérogénéité des profils et cela dans le cas où les partenaires sont modélisés via un autre outil qui a un propre profil différent de celui utilisé pour modéliser le processus métier [Cru03] Le langage YAWL Le langage YAWL 1 (Yet Another Workflow Language) [Van02]. Ce langage est destiné à représenter les processus métier en étendant la syntaxe des réseaux de Pétri pour qu elle supporte tous les patrons de flux de contrôle En réalité, le YAWL est langage à la fois graphique et d exécution, en effet, un moteur d exécution a été implémenté pour ce langage à l inverse des autres langages de définition de haut niveau, tel qu UML, qui sont dédiés à la modélisation graphique des processus et qui doivent être traduits vers un langage d exécution pour que le processus soit implémenté. Le YAWL hérite des réseaux de pétri les mécanismes de vérifications de bon fonctionnement des processus. Une nouvelle version ce langage est récemment proposé dans [Rus09]. Surnommée newyawl, cette nouvelle version tente de couvrir tous les patrons des données «data patterns» et les patrons des ressources «ressource patterns». Bien que plusieurs éditeurs de BPMS s intéressent à ce nouveau langage, ce dernier est encore dans sa phase de recherche et il a besoin un peu de plus de temps pour se stabiliser Le standard BPMN Le langage BPMN (Business Process Modeling Notation) est proposé par le consortium BPMI (Business Process Management Initiative), qui regroupe des entreprises leaders du marché comme IBM, BEA, Siebel,... etc. Il s agit d un standard pour la modélisation de processus qui définit une notation graphique commune à tous les outils de modélisation. Le BPMN permet de représenter un processus métier avec une notation graphique complète (éléments graphiques et diagrammes). Il découple les informations métier des informations techniques et fournit une correspondance vers des langages d'exécution. Il s'agit d'une notation assez proche d'uml appliquée aux processus. D ailleurs, l OMG soutient actuellement le BPMN, et cela depuis sa fusion avec BPMI.org en Aujourd hui, La spécification BPMN est devenue stable et elle est adaptée aux besoins du marché. Plusieurs éditeurs l ont adoptée et introduite dans leurs outils. Pour cela, 1 Le langage YAWL est proposé par la fondation YAWL qui regroupe 25 participants académiques comme l université de technologie d Eindhoven et l université de technologie du Queensland ainsi que des participants industriels comme ATOS Worldline. 14

28 Etat de l art / Modèles & langages des processus métier nous allons, dans la prochaine section, détailler la spécification BPMN en présentant une représentation BPMN du processus de traitement de commande de l exemple vu dans le précédent chapitre Un cas d utilisation de BPMN Pour montrer la puissance du langage BPMN, nous considérons l exemple du traitement de commande d une entreprise présenté dans la section 2.3. Comme illustré dans la figure 2.3 le BPMN modélise les processus métier en utilisant des symboles graphiques. Pour cela, ce langage propose plusieurs classes de symboles : des cercles pour représenter les événements (exemple : événements de réception d un message ou événements de fin de processus); des losanges pour représenter les connecteurs (exemple : le connecteur du choix exclusif basé sur les données (sur les conditions) ou le connecteur du choix exclusif basé sur les événements); les rectangles représentent les activités ; les flèches pleines lient les connecteurs et les activités et les flèches en pointillés représentent les messages échangés entre les processus. Dans le langage BPMN, une colonne représente un processus, tandis qu une sous colonne représente un participant. C est pour cette raison que le diagramme BPMN de la figure représente deux processus qui collaborent pour traiter une commande. 15

29 Etat de l art / Modèles & langages des processus métier Evénement réception de message Connecteur choix exclusif basé sur les données Evénement de début de processus Un flux de message Connecteur parallèle Une activité Evénement de fin de processus Connecteur parallèle Un flux de séquence Connecteur choix exclusif basé sur les événements Evénement réception de message Evénement de fin de processus Evénement timer Evénement de fin de processus Figure 2.3 Une représentation BPMN du processus de traitement de commande 16

30 Etat de l art / Modèles & langages des processus métier Les Langages d exécution de processus métier Les langages d exécution des processus métier permettent de spécifier le déroulement de l ensemble des activités d un processus. Ces langages qui sont interprétés par des moteurs d exécution, utilisent une syntaxe XML pour décrire l implémentation du processus. Ils peuvent être classés, selon leur origine, en deux familles : La première famille est celle des langages de Workflow destinés à modéliser, dans une entreprise, les flux d informations échangés entre les différents acteurs et les activités à accomplir par ces différents acteurs. XPDL [WfMC08], ebxml [OASIS03] sont les langages les plus connus de cette famille de langages Le langage XPDL Le langage XPDL (XML Process Definition Language) est proposé par Workflow Management Coalition qui regroupe plusieurs fournisseurs de système de workflow, il permet de spécifier un processus métier en définissant les activités, les transitions, les partenaires et les interactions entre eux. XPDL est adopté par la plupart des moteurs de workflow Le langage ebxml Le langage ebxml (Electronic Business using extensible Markup Language) est né du besoin d avoir une suite de spécifications pour le projet commun entre OASIS (Organization for the Advancement of Structured Information Standards) et UN/CEFACT (United Nations Centre for Trade Facilitation and Electronic Business) qui vise à définir une plate-forme de commerce électronique. ebxml propose plusieurs spécifications : ebms pour décrire les transmissions de messages, CPPA pour décrire les protocoles de collaborations et ebbp pour décrire les processus métiers. En effet, l ebbp permet de spécifier, en plus des activités du processus, la qualité de services désirée telle que la fiabilité, la sécurité. Cette spécification est adoptée dans plusieurs domaines tels que l e-gouvernement. La deuxième famille des langages d exécution de processus est destinée à orchestrer les services web mis en œuvre au sein d un processus. En effet, un processus métier peut être modélisé par une composition de services web dans le cas où il n utilise que ces derniers comme ressources pour l exécution des ses activités. Ces processus métier peuvent être vus comme un service web dit complexe. 17

31 Etat de l art / Modèles & langages des processus métier En réalité, les langages de cette famille permettent de répondre au manque d information lié à l utilisation du langage de description WSDL (Web Services Description Language, traduit le langage de description des services web). Le WSDL permet de décrire un service basique (par exemple avoir le prix d un produit). Par contre, ce langage n est pas suffisant pour décrire un processus métier qui modélise un service web complexe car il ne supporte pas les flux de contrôle d un processus. De plus, les langages de description de processus permettent de gérer les interactions à mémoire (il s agit de la gestion des états). En effet, un état représente un ensemble de variables d une méthode et leurs valeurs associées. Ce mécanisme, qui n est pas supporté par le WSDL, est utile pour les méthodes qui dépendent des valeurs retournées par les méthodes d un même service par un même client comme par exemple : trouver le prix minimum d une réservation lors de l appel à deux services différents par un service maître [Ram06]. Toutefois, ces langages exploitent les capacités d extension de WSDL [Cru03]. Cela veut dire que l utilisation d un langage d exécution de processus ne remplace pas l utilisation de la description WSDL. En effet, ces langages viennent aujourd hui compléter la description des interfaces exprimées en WSDL. WSFL [Ley01], XLANG [Tha01], et BPEL4WS [OASIS07] sont les langages les plus connus de cette famille de langages Le langage WSFL Le langage WSFL (Web Services Flow Language) est un langage basé sur XML, développé par IBM pour la description de la composition de services Web à deux niveaux : le premier niveau appelé flow models (modèles d activités) spécifie comment réaliser un but métier particulier; typiquement, le résultat est une description d'un processus métier. Le deuxième niveau nommé global models (modèles globaux) spécifie le modèle d'interaction d'une collection de services de Web, dans ce cas, le résultat est une description des interactions globales entre partenaires Le langage XLANG Le langage XLANG (XML Language) est développé par Microsoft pour sa plateforme de gestion de processus BizTalk et cela dans le but de palier les limites du langage de description WSDL. Le XLANG utilise des structures simples tel que les Actions qui correspondent aux opérations WSDL, les éléments de programmation structurée (comme : while, switch, etc), les éléments permettant le parallélisme des éléments de base ou encore les éléments d exécution avec conditions (au sens événementiel et temporel) avec les éléments pick et contexte [Ram06]. Ce langage a vite disparu au 18

32 Etat de l art / Modèles & langages des processus métier profit de la norme connue sous le nom de BPEL (Business Process Execution Language) Le standard BPEL Le consortium BPMI (Business Process Management Initiative) a proposé, en plus de PBMN, la spécification BPEL (Business Process Execution Language). Il s agit d un langage qui combine WSFL (d IBM) et XLANG (de Microsoft). Le nom exact de cette spécification est BPEL4WS (Business Process Execution Language for Web Services). Ce nom pourrait induire en erreur car un processus BPEL ne se réduit pas à l orchestration de Services Web car on peut également inclure des connecteurs transactionnels comme des EJB ou des procédures stockées SQL [Cru03]. L avantage de cette spécification, par rapport à ses prédécesseurs, est qu elle permet de décrire de manière détaillée et précise chaque élément d un processus métier. Elle supporte des mécanismes de compensation qui sont utiles aux transactions longues. BPEL permet aussi de représenter le parallélisme et la synchronisation et supporte les protocoles standards des services web tel que le SOAP, WSDL, UDDI et le protocole WS-Reliable Messaging [OASIS04] des applications réparties qui tolère les pannes de composants, réseaux ou systèmes. Le standard BPEL est maintenant stable. Nous allons détailler cette spécification, dans la prochaine section, en présentant un cas d utilisation du processus BPEL de traitement de commande Un cas d utilisation du BPEL La structure globale d un processus BPEL est décrite par les clauses suivantes : <process> <variables>..les variables du processus.. </variables> <partnerlinks>.. partenaires du processus.. </partnerlinks> <faulthandlers>..activités lancées pour traiter les erreurs d exécution.. </faulthandlers> <compensationhandlers>..code lancé pour exécuter des action de compensation.. </compensationhandlers> [activités]* le bloc d activités exécuté par le processus ( 2 types d activités : élémentaires et structurées) </process> Nous remarquons que BPEL permet de représenter les cinq dimensions processus métier : la partie «Variables» permet de représenter les variables qui sont utilisées par les activités et qui sont utilisées aussi dans la description des comportements du processus (la dimension informationnelle). Ces variables servent aussi à déterminer les types de messages échangés au sein du processus (la dimension opérationnelle). La partie 19

33 Etat de l art / Modèles & langages des processus métier «Partnerlinks» permet de représenter les participants qui ont pour rôle d exécuter les activités du processus (la dimension organisationnelle) et cela en identifiant les différentes opérations utilisées par chaque participant et en définissant les liaisons entre les ensembles d opérations invoquées par le processus BPEL (la dimension opérationnelle). Figure 2.4 Le sous processus BPEL de traitement de commande Comme illustrée dans la figure 2.4, la partie «Activités» est le cœur d un processus BPEL. Cette partie permet de représenter deux types d activités : les activités atomiques et les activités composées. Dans un processus BPEL les activités atomiques sont prédéfinies : comme par exemple la balise <invoke> pour invoquer une opération d un partenaire, la balise <receive> pour attendre un message d une source externe et la balise <reply> pour répondre à une source externe (la dimension fonctionnelle). Les activités composées formées d activités atomiques ou composées permettent de décrire les comportements du processus (la dimension comportementale) par exemple la balise <sequence> pour définir un ordre d exécution, la balise <flow> pour l acheminement parallèle et la balise <switch> pour l acheminement conditionnel. 20

34 Etat de l art / Modèles & langages des processus métier La traduction des langages graphiques vers les langages d exécution Même si le langage BPEL est incontournable pour décrire l implémentation des processus métier, sa syntaxe basée sur XML rend l utilisation et la compréhension d un code BPEL difficile. Il ne fait aucun doute qu une représentation graphique (BPMN, UML) faciliterait le travail de conception, le code BPEL peut être généré par la suite grâce à une traduction automatique. Pour cela, plusieurs auteurs ont proposé des algorithmes de traduction automatique d une modélisation graphique vers un code BPEL comme par exemple l algorithme décrit dans [Ouy06] qui traduit un modèle BPMN en un code BPEL, ou l algorithme [Gar09] qui traduit un modèle exprimé en UML en un processus BPEL ou encore [Van07] qui traduit une modélisation exprimée par une extension de réseau de pétri appelé WorkflowNet en un code BPEL. 2.4 Les langages déclaratifs de modélisation du processus métier La flexibilité est devenue l intérêt majeur des entreprises et cela pour améliorer leur productivité, leur fiabilité et leur rapidité d adaptation aux changements. Dans ce contexte, des langages déclaratifs ont été proposés pour permettre aux scénarios d exécution de rester implicites dans la phase de modélisation du processus. Autrement dit, en utilisant ces langages déclaratifs, les concepteurs évitent d énumérer explicitement tous les scénarios d'exécution possibles dans une modélisation. Cette énumération est souvent difficile à obtenir [Geo07] et peut conduire à la rigidité de la modélisation. Dans la littérature nous avons recensé plusieurs langages déclaratifs tels que : ConDec [Pes06], PENELOPE [Geo06 a], BPTrigger [Chu04] et EM-BrA²CE [Geo07]. En utilisant ces langages, un processus est vu comme un ensemble d états et un ensemble de contraintes qui contrôlent les transitions d un état vers un autre [Geo07]. Pour cela, les langages déclaratifs utilisent différents paradigmes pour représenter les états et les contraintes Le paradigme case-handling Le case-handling est un nouveau paradigme proposé par Van der Aalst et al., dans [Van05 a], pour modéliser d une manière flexible les processus métier. Contrairement à la modélisation impérative, qui utilise des structures de contrôle de processus prédéfinis pour déterminer «ce qui doit être 21

35 Etat de l art / Modèles & langages des processus métier fait» au cours d exécution du processus, le case-handling se concentre sur les «ce qui peut être fait» pour atteindre un objectif métier. Pour cela, ce paradigme se base sur les données du processus (appelés cas) pour permettre aux concepteurs de choisir d exécuter (Execute), de sauter (Skip) ou refaire (Redo) les activités du processus en fonction de la disponibilité des cas. Notons que le paradigme case-handling a été adopté dans un système de gestion de Worflow, appelé FLOWer Le paradigme de la logique temporelle linéaire (LTL) La logique temporelle linéaire (LTL) peut être utilisée pour modéliser, d une manière déclarative, les processus métier. Cette logique est une logique modale où la notion de vérité dépend de l'évolution du temps. C'est-àdire qu'une proposition peut-être, à un moment, fausse puis, plus tard, devenir vraie, etc. Ce paradigme a été utilisé dans un langage ConDec, proposé par Pesic et al. [Pes06]. Ce langage spécifie un processus métier en se basant sur la théorie des automates et la logique temporelle linéaire. Les modèles ConDec peuvent être exécutés par un moteur spécifique Le paradigme de logique déontique La logique déontique peut être utilisée pour modéliser, d une manière déclarative, un processus métier. Cette logique permet de formaliser les variantes possibles d une exécution d une activité métier : l'obligation, l'interdiction, la permission et le facultatif. Cela permet de tenir compte des obligations et des autorisations dans les interactions métier. La logique déontique a été utilisée dans le langage PENELOPE proposé par Goedertier et al. dans [Geo06 a]. Ce dernier se base sur les axiomes temporels et déontiques pour modéliser un processus et en utilisant les agents pour effectuer une activité particulière dans un délai indiqué Le paradigme Event-driven process Le paradigme Event-driven process (processus orienté événements) est proposé pour modéliser et gérer les processus par des événements en utilisant le formalisme émergent CEP (Complex Event Processing). Ce dernier permet de connaître les situations d'un processus métier en sélectionnant ou en agrégeant les événements pour lancer l exécution d une activité spécifique. Ce paradigme est utilisé dans la méthode EPC (Event-driven Process Chains) [ARIS07] pour spécifier un processus métier. Cette méthode est dé- 22

36 Etat de l art / Modèles & langages des processus métier veloppée dans le cadre de l architecture ARIS (Architecture of Integrated Information System). Elle a été adoptée dans les BPMS proposé par l entreprise IDS Scheer. EPC propose des notations graphiques pour représenter les fonctions (activités), les unités organisationnelles (les participants) et les événements qui déclenchent l exécution des fonctions. Pour cela, cette méthode propose des connecteurs logiques pour permettre de construire des événements complexes Le paradigme rule based modeling Le paradigme rule based modeling (modélisation basée sur les règles) propose de modéliser la logique du processus par un ensemble de règles en utilisant des langages déclaratifs. L exécution des ces langages est souvent assurée par des moteurs d inférences de règles qui déterminent l ordre d exécution des activités en fonction de l évaluation des conditions. C est pour cette raison que cette manière de modéliser les processus métier est appelée modélisation basée sur les règles. Le formalise Event-Condition- Action (E-C-A) utilisé dans les systèmes de base de données active dans les années 1990, a été adopté par de nombreux langages de modélisation basés sur les règles. En parallèle, la technologie des agents est souvent utilisée pour modéliser l exécution de ces langages. Un agent représente une entité autonome qui permet de réaliser certaines actions du processus. Un agent coordinateur assure la collaboration entre les agents afin de répondre aux objectifs métiers tracés par le processus. Et cela en utilisant les règles qui régissent le fonctionnement des agents. Un premier exemple de cela est la plateforme AgentWork proposée par Müller dans [Mul04] où les règles ECA sont utilisées pour la gestion temporelle de Workflow. Le travail de Zeng dans [Zen01] propose par ailleurs de voir le processus comme un ensemble de tâches coordonnées entre elles par des règles ECA et d utiliser les agents pour encapsuler les services qui exécutent les tâches du processus. Un troisième exemple est le langage BPTrigger, proposé par Chulsoon et al. dans [Chu04] pour modéliser et exécuter un processus métier complexe dans un environnement distribué et hétérogène en se basant sur le formalisme ECA. Ceci étant, d autres travaux qui utilisent d autres formalises de règles. Un exemple de ces travaux est le travail de Goedertier et al. dans [Geo07] qui proposent le langage EM-BrA²CE basé sur le standard SBVR [OMG08 b] pour modéliser, d une manière déclarative, les processus métier. En effet, le SBVR est un méta-modèle, proposé par l OMG permettant une construction d un vocabulaire métier (les concepts et termes) à utiliser dans la définition les règles métier. Finalement, notons que de nombreux éditeurs ont 23

37 Etat de l art / Modèles & langages des processus métier adopté les langages de modélisation basés sur les règles dans leurs produits comme le JRules d ILOG. 2.5 Conclusion Nous avons présenté dans ce chapitre deux grandes familles de modèles et langages de description du processus : la première famille est celle des modèle et langages impératifs qui se focalisent sur comment les différentes activités du processus sont exécutées. Tandis que, la deuxième famille de modèles et langages utilise un ensemble d états et de contraintes qui contrôlent les transitions d un état vers un autre pour définir un processus. Etant donné que l un de nos objectifs dans cette thèse est d améliorer la modélisation des processus métier pour permettre une gestion de la flexibilité toute en offrant une expressivité qui permet de prendre en compte tous les éléments d un processus métier, nous allons présenter, dans le chapitre suivant, une comparaison entre ces deux familles de langages de définition des processus en se basant sur deux critères qui sont au cœur de nos préoccupations à savoir l expressivité et la flexibilité. 24

38 Etat de l art / Caractéristiques des modèles & langages de processus métier 3 Caractéristiques des modèles & langages de processus métier 3.1 Introduction 3.2 L expressivité de la modélisation d un processus La dimension fonctionnelle La dimension comportementale La dimension organisationnelle La dimension informationnelle La dimension opérationnelle Synthèse Un exemple d un processus métier 3.3 La flexibilité de la modélisation d un processus Les taxonomies de la flexibilité La taxonomie de Regev et al La taxonomie de Schonenberg et al. 3.4 Les caractéristiques des langages de processus Les caractéristiques des langages impératifs L expressivité des langages impératifs La flexibilité des langages impératifs Les caractéristiques des langages déclaratifs L expressivité des langages déclaratifs La flexibilité des langages déclaratifs 3.5 Conclusion 3.1 Introdution La modélisation constitue une phase importante dans le cycle de gestion d un processus métier car elle permet sa définition et la spécification des connaissances métier d une entreprise ainsi que le partage des parties du modèle à des fins de réutilisation [Ros07]. Cette définition consiste en un moyen de dialogue entre les responsables des processus et les équipes fonctionnelles. Plusieurs caractéristiques doivent être prises en compte lors de la modélisation de processus métier, parmi lesquelles nous pouvons citer [Lu07] : 25

39 Etat de l art / Caractéristiques des modèles & langages de processus métier L expressivité : la description complète des différents éléments d un processus (voir [Zur07] et [Jab96]) ; La flexibilité : la capacité d implémenter les changements d'une partie du processus en gardant les autres parties stables (voir [Reg06] et [Sch07]) ; La complexité : la difficulté de modéliser et de vérifier un processus (voir [Car06]) ; L adaptabilité : l habilité à réagir aux exceptions aléatoires (voir [Bou08]); La réutilisabilité : l habilité à partager des parties du modèle pour les réutiliser (voir [Ros07]). Dans cette thèse, nous visons à proposer un modèle de processus expressif et flexible. En effet, les entreprises ont besoin, d un coté, de se baser sur des modèles de processus puissants et flexibles afin de fournir un fort pouvoir d expressivité pour la description des différents éléments et de permettre l application rapide des changements. La maîtrise de processus et ses coûts de maintenance conduisent à accorder une attention plus grande aux questions de l expressivité, la flexibilité des processus. Pour cela, dans ce chapitre, nous allons présenter ces deux caractéristiques en expliquant comment les modèles et langages de processus répondent à ces deux caractéristiques de modélisation que nous retenons comme propriétés essentielles dans le cadre de notre proposition. 3.2 L expressivité de la modélisation d un processus métier La puissance expressive de la modélisation d'un processus est sa capacité à exprimer tous les éléments d un processus métier. En effet, plusieurs éléments doivent être pris en compte dans la définition d un processus. Selon Jablonski et al., dans [Jab96], les éléments clés d un processus métier peuvent être classés en cinq groupes. Chaque groupe représente un aspect ou une dimension qu un processus métier peut posséder. Ces cinq dimensions sont : dimension fonctionnelle, dimension comportementale, dimension organisationnelle, dimension informationnelle et dimension opérationnelle. En parallèle, de nombreux travaux ont été menés afin de proposer des modèles génériques pour décrire certains éléments du processus, en l occurrence les travaux conduits par «the Workflow Patterns initiative» [WPI09], qui regroupe l université technologique d Eindhoven et l université technologique de Queensland, pour proposer des patrons appelés par convention «Workflow patterns». Les patrons proposés permettent de décrire les problèmes récurrents et les solutions proposées pour modéli- 26

40 Etat de l art / Caractéristiques des modèles & langages de processus métier ser les flux de contrôle d un processus métier. En plus, ils peuvent être utilisés comme une base de comparaison entre les différents systèmes de gestion de processus, ou entre les différents langages de modélisation de processus. Nous allons détailler dans la section suivante les dimensions et les patrons utilisés dans une modélisation des processus métier La dimension fonctionnelle La dimension fonctionnelle représente les éléments du processus à exécuter. En effet, ces éléments sont les activités (activités élémentaires) et les sous processus (activités composées). D une manière générale, un processus se compose d un ensemble d'activités qui contribue à la réalisation de l objectif global de ce processus. Selon le Workflow Management Coalition (WfMC) «une activité est une description d'une unité de travail qui forme une étape logique dans un processus» [WfMC99]. En effet, une activité représente un ensemble d actions qui s exécute d une manière indivisible par un participant. Une activité peut être alors soit: l envoi d un message, la réception d un message, l attente d un message, une transformation de données etc. L exécution d une activité peut exiger l intervention humaine, on parle alors d une activité manuelle, ou peut s effectuer par une machine, on parle alors d une activité automatisée. Une activité peut contenir plusieurs autres activités composées ou élémentaires, cette activité est alors appelée un sous processus La dimension comportementale La dimension comportementale représente le flux de contrôle des éléments à exécuter dans un processus. En effet, les flux de contrôle sont les dépendances entre les diverses activités [Van03 b]. Ce sont les relations logiques qui contrôlent l acheminement et l ordre d exécution des activés. Ces relations sont la formalisation des décisions à prendre (quelle branche du processus on doit choisir) et cela en tenant compte du contexte du processus et d un certain nombre de contraintes. Ce sont aussi les règles qui permettent de contraindre, contrôler et influencer l aspect du métier du processus. Ces règles sont appelées les règles métier ou règles de gestion. Le groupe BRG (Business Rules Group) définit les règles métier comme «des définitions de haut niveau structurées, qui permettent de contraindre, contrôler et influencer un aspect du métier» [BRG02]. Ces règles implémentent la stratégie ou les politiques d une entreprise et elles permet- 27

41 Etat de l art / Caractéristiques des modèles & langages de processus métier tent d'influencer les prises des décisions et de contrôler les comportements métiers. Plusieurs travaux se sont intéressés à modéliser les flux de contrôle afin de définir des patrons pour ces éléments. Les premiers travaux ont conclu sur une proposition de vingt «Workflow control flow patterns» pour couvrir tous les flux de contrôles possibles [Van03 b]. Une révision a été faite dans ce travail [Rus06 b] qui a conduit à vingt trois nouveaux patrons. Ces modèles ont été largement utilisés par les éditeurs et les universitaires dans le choix de la conception et le développement des systèmes de gestion des processus. Les patrons de contrôle de base proposés représentent les modèles élémentaires de contrôle d un processus métier. Ce sont les suivants : La séquence Le déclenchement d une activité après la terminaison d une autre activité du même processus. La figure 3.1 illustre une séquence d activités où l activité A se déclenche en premier et après sa terminaison, l activité B et l activité C se déclenchent successivement. Figure 3.1 Le patron de séquence La branche parallèle La divergence d'une branche d un processus en plusieurs branches pour permettre aux activités d être exécutées d une manière simultanée (une concurrence d exécution). La figure 3.2 illustre deux activités qui s exécutent en parallèle (l activité B s exécute en même temps que l activité C). Figure 3.2 Le patron de parallélisme La synchronisation La convergence de plusieurs branches d un processus en une seule branche pour permettre la synchronisation entre les activités. La figure 3.3 illustre une synchronisation entre deux activités où l activité C ne se déclenche que si l activité A et l activité B se terminent. 28

42 Etat de l art / Caractéristiques des modèles & langages de processus métier Figure 3.3 Le patron de synchronisation Le choix exclusif Le choix d une seule branche parmi plusieurs pour permettre à une activité d être exécutée en fonction d une condition. La figure 3.4 illustre le choix (nœud de décision) où soit l activité B soit l activité C s exécute en fonction d une certaine condition La jonction simple Figure 3.4 Le patron du choix exclusif La jointure de plusieurs branches sans synchronisation pour permettre à une instance d un processus, lors de son exécution, de ne passer qu une fois par une jonction unique. La figure 3.5 illustre la jointure de deux activités (nœud de fusion) où le rassemblement de deux flots alternatifs entrants en un seul flot sortant. Figure 3.5 Le patron de jointure simple L énumération complète de ces «Workflow control-flow patterns» est présentée dans [WPI09]. Notons que les décisions à prendre sont modélisées, dans ces patrons, sous forme de connecteurs (quelle branche du processus on doit choisir): Par exemple, on peut noter le connecteur du choix exclusif qui représente le choix d une seule branche (ou une décision à prendre) parmi plusieurs pour permettre à une activité d être exécutée en fonction d une contrainte. On peut noter également le connecteur de jonction simple qui représente la jointure de plusieurs branches sans synchronisation pour per- 29

43 Etat de l art / Caractéristiques des modèles & langages de processus métier mettre à une instance d un processus, lors de son exécution, de passer qu une fois par une jonction unique La dimension organisationnelle La dimension organisationnelle représente les ressources qui ont la responsabilité d exécuter les éléments d un processus. Ces ressources sont appelées participants parce qu elles participent à la réalisation de l objectif global du processus. En effet, un participant est toute personne, application, ou entité qui a le rôle d exécuter une activité. Notons qu un participant peut être aussi un service Web, ainsi l ensemble des services (participants) d un même processus forme une composition de services. En effet, dans la littérature plusieurs papiers (exemple [Ley02], [Leu07] et [Cla06]) considèrent qu un processus métier est exécuté par une composition de services Web. C est pour cette raison que les langages de composition de services sont utilisés pour décrire le déroulement de l ensemble des activités d un processus. Ce point sera détaillé un peu plus loin. Dans le travail de Russell et al., dans [Rus04 a], les auteurs proposent quarante trois patrons pour décrire les différentes manières dont des ressources sont représentées et utilisées dans un processus. Ces «workflow resource patterns» ne dépendent pas d une technologie spécifique ou d un langage de modélisation donné. Un exemple de ces patrons est (Direct Allocation) qui décrit l identité de la ressource qui s occupe de l exécution d une activité donnée ou encore (Random Allocation) qui permet de décrire le choix aléatoire d une identité d une ressource qui s occupe d exécuter une activité donnée. L énumération complète des «Workflow ressource patterns» patrons est présentée dans [WPI09] La dimension informationnelle La dimension informationnelle représente les entités d information qui sont produites ou manipulées par un processus métier. Ces entités peuvent être des données simples (des chaînes de caractères, des dates,..), des données complexes (des ensembles, tableaux) ou des documents. Comme pour les flux de contrôle et les ressources, quarante patrons de données sont proposées dans [Rus04 b] et cela pour modéliser les différentes manières dont les données sont représentées et utilisées dans un processus métier. En effet, ces «Workflow data patterns» peuvent être divisés en quatre groupes : 30

44 Etat de l art / Caractéristiques des modèles & langages de processus métier Groupe de patrons de visibilité de données Ce groupe de patrons concerne la façon avec laquelle les données peuvent être accessibles ou utilisables par les éléments du processus. Comme par exemple le pattern des données d une activité (Task Data) qui décrit les données locales qui sont propres à une activité et le pattern des données d un processus (Workflow Data) qui décrit les données globales qui sont utilisables par toutes les activités de ce processus (voir la section 3.2.7) Groupe de patrons des interactions de données Ce groupe de patrons concerne la façon avec laquelle les données peuvent être échangées entre les éléments d un même processus (échange interne) ou entre les éléments d un processus et l environnement extérieur (échange externe). Comme par exemple le pattern (Task to Task) qui décrit le passage de données entre une activité et une autre activité d un processus, et le pattern (Task to Environment) qui décrit le passage de données entre une activité et une ressource ou un service extérieur (voir la section 3.2.7) Groupe de patrons de mécanisme de transfert de données Ce groupe de patrons concerne les divers mécanismes grâce auxquels les données peuvent être communiquées au processus. Comme par exemple le pattern (Data Transfer by Copy) qui décrit le mécanisme de passage en utilisant les copies de données, et le pattern (Data Transfer by Reference) qui décrit le mécanisme de passage en utilisant les références à des données (voir la section 3.2.7) Groupe de patrons de données basées sur le déroulement Ce groupe de patrons concerne la façon avec laquelle les données peuvent agir l une sur l autre et peuvent influencer ainsi le déroulement du processus. Comme par exemple le pattern (Task Precondition - Data Existence) qui décrit des données basées sur une pré-condition de l existence d une ou de plusieurs données au moment de l exécution (voir la section 3.2.7). L énumération complète de ces «data patterns» se trouve dans [WPI09] La dimension opérationnelle La dimension opérationnelle représente les détails opérationnels d un processus métier. Ces détails représentent, en effet, les informations techniques utilisées lors de l exécution du processus comme : le format des 31

45 Etat de l art / Caractéristiques des modèles & langages de processus métier messages échangés, les protocoles de transport utilisés et le mode d invocation (synchrone ou asynchrone) Synthèse Pour résumer cette section, nous présentons, le tableau suivant qui synthétise les cinq dimensions du processus avec les différents éléments du processus et les principaux patrons de Workflow de chaque dimension : Les dimensions du processus La dimension fonctionnelle La dimension comportementale La dimension organisationnelle La dimension informationnelle La dimension opérationnelle Les principaux éléments Activité Flux de contrôle (connecteur) Participant (ressource) Données Informations techniques : protocoles, langages, Les principaux patrons Activité manuelle Activité automatique La séquence La branche parallèle La synchronisation Le choix exclusif La jonction simple La boucle structurée Annulation d activité Allocation directe Allocation aléatoire Allocation basée sur le rôle Délégation Variable globale d un processus Variable locale d une activité Passage de données activité vers activité Passage de données activité vers extérieur Passage de paramètre par copie Passage de paramètre par référence Pré-condition sur les données d une activité Post-condition sur les données d une activité 32

46 Etat de l art / Caractéristiques des modèles & langages de processus métier Un exemple d un processus métier Pour illustrer quelques éléments d un processus métier, nous allons présenter dans cette section un exemple de processus de traitement de commande. A la réception d une commande d'un client, ce processus lance deux tâches en parallèle : le calcul du prix initial de la commande (le prix sans la livraison) et le choix d un livreur. Les données sont inter échangées entre les deux tâches : le prix de livraison est nécessaire pour le calcul du prix total, la date de livraison est nécessaire pour accomplir le plan de livraison. Quand les deux tâches se terminent, la facture est envoyée au client. Ce dernier a le choix de payer en espèces ou avec une carte de crédit (CB). La facture est finalement enregistrée. La figure 3.6 représente une modélisation graphique du processus de traitement de commande. En effet, les rectangles à coins arrondis représentent les activités du processus. Chacune de ces activités décrit d'une unité de travail qui est exécuté par un participant : les activités «Calculer le prix initial» et «Calculer le prix total» sont exécutées par le service de gestion et commandes tandis que les activités «Choisir un livreur» et «Calculer le prix de livraison» sont exécutées par le service de livraison. Les arcs orientés dans la figure représentent les flux de contrôle qui modélisent les dépendances entre les activités. Pour cela, on retrouve les patrons de base : Un parallélisme pour l exécution concurrente de l activité «Calculer le prix initial» et l activité «Choisir un livreur»; Une séquence d activités pour exprimer que l activité «Calculer le prix de livraison» se déclenche après la terminaison de l activité «Choisir un livreur»; Une synchronisation pour exprimer un point de rendez-vous c.à.d. l activité «Calculer le prix total» ne se déclenche qu après la terminaison de l activité «Calculer le prix initial» et «Calculer le prix de livraison»; Un choix exclusif pour exprimer le déclenchement d une seule activité parmi les deux possibles («Demander le paiement en espèces» et «Demander le paiement par CB») et enfin une jonction pour exprimer le point où les deux branches de ces deux activités se rejoignent, en effet, la terminaison d une des deux activités («Demander le paiement en espèces» et «Demander le paiement par CB») suffit pour passer la jonction. Sachant que des règles métier contrôlent les comportements de ce processus. Ces règles peuvent être des règles de réaction (à la réception d un message lancer deux tâches en parallèle) ou des contraintes (le client le choix de payer en espèces ou avec CB). 33

47 Etat de l art / Caractéristiques des modèles & langages de processus métier Figure 3.6 La modélisation du processus de traitement de commande 34

48 Etat de l art / Caractéristiques des modèles & langages de processus métier Sur la figure 3.6, les colonnes représentent les participants qui ont le rôle d exécuter des activités du processus. Les participants du processus dans cet exemple représentent le service commercial, le service financier et service de livraison. En effet, chacun de ces participants peut être une personne humaine (un acteur), un groupe de personnes (un département), ou une application / services web (exemple : le service de transmission du bon de commande. Pour accomplir l objectif du processus du traitement de commande, les activités utilisent et produisent des données. En effet, ces données peuvent être locales, comme les données temporaires utilisées lors du calcul du prix initial (le pattern Task Data), ou données globales comme les informations de la commande (le pattern Workflow Data). Le transfert de données peut se faire entre deux activités du processus comme le transfert du prix de livraison entre l activité «Calculer le prix de livraison» et l activité «Calculer le prix total» (le pattern «Task to Task»). Pour réaliser ce transfert, on peut utiliser soit des copies de données qui sont sauvegardées dans une base de données (le pattern Data Transfer by Copy), ou l adresse mémoire pour accéder aux données (le pattern Data Transfer by Reference). Finalement, pour pouvoir exécuter l activité «Choisir un livreur», l adresse du client doit être mentionnée dans la commande (le pattern Task Precondition - Data Existence). La figure 3.6, représente une modélisation de haut niveau du processus de traitement de commande. Pour que ce processus soit opérationnel, on doit définir les détails techniques comme par exemple définir un schéma XML pour un échange de messages au format XML. Par ailleurs, la dimension informationnelle et la dimension opérationnelle ne sont pas représentées dans ce modèle graphique. En effet, le langage de modélisation utilisé pour spécifier le processus donné en exemple (le diagramme d activité d UML) n offre pas un moyen simple de description des éléments de ces deux dimensions. Toutefois, une représentation complète des connaissances du métier d une entreprise est nécessaire afin d automatiser et analyser les processus, et cela dépend évidement de la puissance du langage de modélisation utilisé. En plus, le fait de définir explicitement les flux de contrôle, rend le processus rigide et difficile à changer. 35

49 Etat de l art / Caractéristiques des modèles & langages de processus métier 3.3 La flexibilité de la modélisation des processus métier La nécessité de la prise en compte de la dynamicité des différents éléments d un processus nous pousse à faire plus d attention à la flexibilité et la souplesse de la modélisation du processus métier. En effet, la notion flexibilité de la modélisation est utilisée pour désigner la capacité de mettre en œuvre les changements dans un processus métier en ne modifiant que les parties qui ont besoin d'être changées tout en gardant la stabilité des autres parties du processus [Rev06]. Une modélisation de processus est flexible si elle est capable d être modifiée sans la remplacer complètement Les taxonomies de la flexibilité Plusieurs travaux ont été menés pour tenter de proposer une taxonomie générique de la flexibilité des processus métier. Dans ce contexte, deux grandes taxonomies ont été proposées : La taxonomie de Regev et al. La première taxonomie est celle de Regev et al. proposée dans [Rev06] qui s intéresse aux changements qui peuvent survenir durant le cycle de vie d un processus métier (voir la figure 3.7) et comprend trois dimensions de changement : 1- Le niveau d'abstraction du changement qui concerne le niveau d application du changement dans un processus métier. Le changement peut concerner soit la spécification ou l instance du processus. 2- L'objet du changement qui concerne les différents aspects du processus qui sont sujet du changement. Le changement peut concerner les activités du processus (dimension fonctionnelle), les flots de contrôle (dimension comportementale), les données du processus (dimension informationnelle) ou les différents protocoles utilisés dans le processus (dimension opérationnelle). 3- Les propriétés du changement comme : le degré du changement qui peut être partiel pour changer une partie du processus ou total ou radical pour créer un nouveau processus ; la durée du changement qui peut être temporaire ou permanent ; la rapidité d application du changement qui peut être soit immédiate ou en différée ; et l anticipation du changement qui peut être soit planifiée ou ad hoc. 36

50 Etat de l art / Caractéristiques des modèles & langages de processus métier Figure 3.7 La taxonomie de la flexibilité proposée par Regev [Rev06] La taxonomie de Schonenberg et al. Dans son papier [Sch07], Schonenberg et al. proposent une deuxième taxonomie qui s intéresse à la flexibilité du point de vue opérationnel. Pour cela, cette taxonomie distingue : 1- La flexibilité par conception concerne la possibilité d exprimer des chemins alternatifs d exécution dans une modélisation du processus et cela en permettant la possibilité d exprimer le parallélisme entre les activités, le choix de l exécution d une activité parmi plusieurs, l instanciation multiple d une activité dans la même exécution ou encore l annulation de l exécution d une activité. 2- La flexibilité par déviation concerne la possibilité de dévier l exécution d une séquence d une instance du processus de sa définition initiale en permettant par exemple de défaire, de refaire ou de court-circuiter certaines activités. 3- La flexibilité par spécification partielle concerne la possibilité d exécuter un processus partiellement spécifié c.-à-d. la possibilité de définir certaines structures de processus dans la phase d exécution en permettant la sélection tardive d un fragment de processus parmi plu- 37

51 Etat de l art / Caractéristiques des modèles & langages de processus métier sieurs alternatives ou la modélisation tardive pour spécifier des fragments à la volée durant l exécution du processus. 4- La flexibilité par changement concerne la possibilité de modifier la définition du processus dans la phase d exécution en permettant à toutes les instances du processus existantes de migrer vers la nouvelle définition du processus. 3.4 Les caractéristiques des langages de processus Nous avons vu que l expressivité d une modélisation d'un processus est sa capacité à exprimer les différents patrons de modélisation proposés pour chaque dimension du processus. La flexibilité d une modélisation est la capacité de mettre en œuvre les changements dans un processus métier sans toucher à la stabilité des autres parties du processus. Pour cela ces deux caractéristiques doivent être prises en compte par les langages de modélisation et cela afin d offrir aux experts une meilleure maîtrise de ces processus. Cependant, ces différents caractéristiques sont fortement dépendantes les unes des autres. C'est sur ce point que des problèmes surgissent. En effet, selon Cardoso [Car06] la complexité désigne la mesure de la difficulté à modéliser ou à maintenir un modèle et à analyser le processus pour améliorer ou assurer son bon fonctionnement. La complexité et la flexibilité sont des critères fortement couplés. Un processus complexe a tendance à être moins flexible et vice-versa. Dans cette section, nous allons voir de quelle manière les langages de modélisation de processus métier existants répondent à ces caractéristiques Les caractéristiques des langages impératifs L expressivité des langages impératifs Plusieurs travaux ont été menés pour étudier la couverture des patrons des flux de contrôle par les langages impératifs des processus métier (exemple [WPI09, Vas06, Van03 b]). Tous ces langages supportent les patrons de bases (le parallélisme, la synchronisation, le choix exclusif, la jonction simple). Par contre, chaque langage supporte un sous ensemble des patrons restants. XLANG ne supporte pas par exemple la terminaison implicite (le processus se termine lorsqu il ne reste plus d activité à exécuter) et le choix 38

52 Etat de l art / Caractéristiques des modèles & langages de processus métier multiple (la possibilité de choisir une branche parmi plusieurs lancé en parallèle). WSDL et XPDL ne supportent pas le choix différé (la possibilité de choisir une branche parmi plusieurs, après l exécution de l activité de cette branche les autres branches sont alors retirées). Les études menées démontrent que BPEL est avantageux parce qu il supporte le plus grand nombre des ces patrons de flux de contrôle par rapport à ses prédécesseurs. En parallèle, le travail de White dans [Whi03] présente une comparaison des capacités des deux langages graphiques UML et BPMN à exprimer les patrons de flux de contrôles «Workflow control flow patterns». La conclusion de cette comparaison montre que BPMN est le mieux adapté à modéliser les processus métier parce qu il supporte un plus grand nombre de ces patrons que UML. C est pour cette raison que BPMN et BPEL sont les langages les plus adoptés dans l industrie La flexibilité des langages impératifs La nature dynamique des environnements des organisations rend les éléments de processus susceptibles d être modifiés ou supprimés. Selon Goedertier [Goe06 b] l origine de cette dynamicité vient essentiellement du changement fréquent dans les réglementations extérieures que doit respecter l entreprise et aussi le changement de politiques intérieures définies par l entreprise. Ces réglementations et politiques métier sont souvent exprimées sous forme de règles appelées règles métier (voir le chapitre 2). Les règles métier méritent, donc, d être formalisées pour faciliter leurs interactions. Malheureusement, en utilisant les langages impératifs tels que BPMN [OMG09], UML [OMG08], BPEL [OASIS07] et le XPDL [WfMC08], ces règles métier sont mélangées avec le code de la logique du processus. Par conséquent, l implémentation du changement est difficile à faire. En effet, ces langages obligent les concepteurs à définir explicitement les décisions à prendre sous forme de connecteurs. De cette manière, ces langages permettent d utiliser les résultats des décisions (ou les règles métier) pour déterminer le comportement à suivre plutôt que modéliser ces règles (ou décisions). En plus, l utilisation des langages impératifs oblige les concepteurs à décrire explicitement les scénarii d exécution dans la phase de modélisation. Bien que cette pratique permette d exprimer des chemins alternatifs d exécution dans une modélisation du processus (flexibilité par conception selon la taxonomie de Schonenberg et al [Sch07]), elle rend les processus métier rigides et difficiles à maintenir. Le fait de définir explicitement la façon dont les processus devraient procéder compromet la flexibilité du modèle (pas de flexibilité par déviation, ni par spécification partielle, ni flexibilité par changement selon la taxonomie de Schonenberg et al [Sch07]). 39

53 Etat de l art / Caractéristiques des modèles & langages de processus métier L intégration du processus métier et des règles métier est un sujet de plusieurs années de recherche. C est pourquoi la littérature regorge de propositions qui tentent de répondre à cette délicate question. De manière générale, les approches proposées dans ces recherches répondent à la rigidité de la modélisation impérative en essayent d ajouter une dimension de flexibilité aux langages impératifs. Une première catégorie de ces approches tente d'encapsuler les règles métier en tant que services Web. Dans cette orientation, nous pouvons citer l architecture orienté service proposé par Rosenberg et al., dans [Ros05], qui intègre les règles métiers, dans BPEL ou d autre langages de composition de services, sous forme de services générés par des moteurs de règles. Pour cela, plusieurs modules sont définis : un ESB (Entreprise Service Bus) est utilisé comme plateforme de communication par tous les services ; Un moteur de BPEL relié à l'esb par un adaptateur afin de faciliter l invocation des services web ; un broker de règles métier est défini pour unifier l accès aux différents moteurs des règles métiers en utilisant les interfaces des services web ; un service d interception de règles est utilisé comme un pont entre les règles métiers et le processus BPEL en définissant deux types d interception le «avant» l activité et le «après» activité. Un autre travail de cette catégorie, est proposé par Lee et al. dans [Lee07] qui suggèrent un modèle du processus orienté états. En effet, ce modèle permet de modéliser le processus sous forme d état/transition en séparant les règles métier de la logique de processus. Le processus BPEL est ensuite généré en implémentant les règles métier comme des services web à invoquer. La deuxième catégorie de travaux tente d'étendre les langages impératifs pour prendre en compte les règles en modèle de processus. Un exemple des ces extensions est le travail de Charfi et al. dans [Cha04] qui proposent de modéliser les règles métier comme un aspect (en référence à la programmation par aspect). De cette manière, la technique de la programmation orientée aspect peut être utilisée afin de gérer l'intégration des règles métier au sein d'un processus BPEL. Une autre extension est proposée par Van Eijndhoven et al. dans [Van08] suggérant l'utilisation des patrons de flexibilité aux parties variables d un processus métier. Dans cet esprit, Sadiq et al. [Sad05], proposent d utiliser des pockets of flexibility dans la modélisation de processus métier et cela dans le cadre d une plateforme spécifique. En effet, dans cette plateforme, un processus peut contenir, en plus des activités et les flux de contrôles prédéfinis, des sousprocessus, définis d une manière déclarative, appelés poches de flexibilité. Ces poches sont constituées des activités et de plusieurs types de contraintes qui contrôlent l ordre d exécution des ces activités. Un dernier 40

54 Etat de l art / Caractéristiques des modèles & langages de processus métier exemple des extensions des langages impératifs est le travail de Boukhebouze et al. dans [bou08] qui proposent d identifier des règles dans un modèle de processus métier en utilisant l activité «Rule» dans un processus BPEL. Malgré les solutions apportées par ces approches et qui répondent d une certaine manière au problème de flexibilité des langages impératifs, elles ne garantissent pas une flexibilité totale notamment en ce qui concerne l impact du changement d une règle sur le reste du processus. D autant plus que les expériences ont montré que les entreprises expriment leurs politiques et règlementations sous forme de règles en utilisant le langage naturel ou en ajoutant des annotations textuelles dans leurs modèles [Zur07]. Cependant, La formulation des règles métiers doit être rigoureuse, concise et précise pour garantir que ces règles soient non ambiguës, cohérentes, complètes et énoncées avec une terminologie commune au métier Les caractéristiques des langages déclaratifs Dans cette section, nous allons nous intéresser à la question : comment les langages déclaratifs répondent aux trois caractéristiques de modélisation suivantes : l expressivité, la flexibilité et Vérification? L expressivité des langages déclaratifs Selon plusieurs travaux qui ont été menés pour étudier la couverture des patrons des flux de contrôle par les langages déclaratifs, ces derniers supportent, d une manière implicite, les patrons de bases (le parallélisme, la synchronisation, le choix exclusif, la jonction simple). Par contre, chaque langage supporte un sous ensemble des autres patrons. Cela dépend des paradigmes utilisés par les langages déclaratifs pour représenter les états et les contraintes des processus métier. Par exemple, selon «the Workflow Patterns initiative» [WPI09], les langages basés sur le paradigme casehandling, comme celui adopté par le système de gestion de Workflow FLOWer, ne supportent pas, par exemple, le patron des boucles arbitraires (l habilité à représenter les cycles qui ont plusieurs points d entrée ou plusieurs points de sortie). Par contre, la méthode EPC supporte le patron des boucles arbitraires, mais ne supporte pas la jointure multiple (la convergence de deux ou plusieurs branches dans une jonction qui permet, lors de son exécution, de passer plusieurs fois par cette jonction). A leur tour, les langages basés sur les logiques sont un peu plus expressifs que les langages impératifs car ils offrent la possibilité de spécifier les conditions temporelles, en plus des obligations et les autorisations dans les interactions mé- 41

55 Etat de l art / Caractéristiques des modèles & langages de processus métier tier. Cependant l utilisation des ces langages requiert de l expertise car ces derniers possèdent une syntaxe basée sur la logique, ce qui conduit a une complexité de modélisation [Lu07]. Finalement, les langages basés sur les règles sont en mesure de représenter un très grand nombre de patrons de flux de contrôle de bases [Lu07] et [Bry06]. En plus, ces langages sont capables d exprimer les exigences temporelles (comme par exemple les conditions temporelles ou les délais d exécution d une activité). Ce qui est avantageux par rapport aux langages impératifs La flexibilité des langages déclaratifs La nature dynamique des environnements des organisations, rend les différents éléments d un processus métier susceptibles d être changés. Les entreprises ont besoin de langages flexibles capables d implémenter les changements dans un processus métier en modifiant seulement les parties qui doivent être changées tout en gardant les autres éléments du processus. Les langages déclaratifs de modélisation de processus métier ont l avantage d être flexibles car ils permettent de déployer les processus partiellement définis, de modifier de façon ad hoc un modèle de processus en cours d exécution et la possibilité de dévier l exécution d une séquence d une instance du processus. Ces langages offrent la possibilité de définir certaines structures de processus, dans la phase d exécution, en permettant la modélisation tardive pour spécifier des fragments à la volée durant l exécution du processus (flexibilité par spécification partielle selon la taxonomie de Schonenberg et al [Sch07]). La modélisation basée sur les règles, par exemple, permet de déployer une définition partielle d un processus car un moteur de règles détermine, dans la phase d exécution, ce qui doit être exécuté en évaluant l ensemble de règles définies. Les langages déclaratifs offrent également la possibilité de modifier la définition du processus dans la phase d exécution en permettant à toutes les instances du processus existantes de migrer vers la nouvelle définition du processus (flexibilité par changement selon la taxonomie de Schonenberg et al [Sch07]). La modélisation basée sur les règles, par exemple, permet de mettre en œuvre une modification d'un sous-ensemble de règles (par exemple, modifier, insérer et supprimer des règles existantes) sans impacter les instances du processus car, en utilisant ces langages, la logique du processus est externe à de l environnement d exécution. Finalement, les langages déclaratifs offrent la possibilité de dévier l exécution d une séquence d une instance du processus de sa définition initiale en permettant par exemple de défaire, de refaire ou de courtcircuiter certaines activités (flexibilité par déviation selon la taxonomie de 42

56 Etat de l art / Caractéristiques des modèles & langages de processus métier Schonenberg et al [Sch07]), comme le cas des langages qui utilisent le paradigme case-handling. 3.5 Conclusion Dans le cadre de la modélisation de processus d entreprise, il est impératif de s appuyer sur des langages puissants pour permettre l expressivité et la flexibilité de la définition du processus. Les langages impératifs qui se focalisent sur comment les différentes activités du processus sont exécutées, assurent une grande expressivité. Toutefois, l utilisation de ces langages oblige les concepteurs à décrire explicitement les scénarii d exécution dans la phase de modélisation. Cette pratique rend les processus métier rigides et difficiles à maintenir. La nature dynamique des environnements des organisations, rend les éléments du processus susceptibles d être modifiés ou supprimés. Le fait de définir explicitement, dans la phase de modélisation, la façon dont les processus devraient procéder compromet la flexibilité du modèle. La flexibilité est devenue l intérêt majeur des entreprises et cela pour améliorer leur productivité, leur fiabilité et leur rapidité d adaptation aux changements. Dans ce contexte, des langages déclaratifs ont été proposés pour modéliser un processus par un ensemble d états et un ensemble de contraintes qui contrôlent les transitions d un état vers un autre. Cette manière offre une flexibilité de modélisation car en utilisant ces langages, les concepteurs évitent d énumérer explicitement tous les scénarios d'exécution possibles dans une modélisation. Cette énumération est souvent difficile à obtenir et peut conduire à la rigidité de la modélisation. Cependant, l expressivité des ces langages dépend du paradigme utilisé pour modéliser les états et les contraintes du processus. Dans cette thèse nous visons à proposer un modèle du processus qui permet d offrir une flexibilité à la modélisation et une fiabilité à l exécution du processus. Pour cela, l utilisation du modèle déclaratif nous semble intéressante. D autant plus, nous sommes convaincus que l utilisation du paradigme rule based modeling permet de gagner en flexibilité et en adaptation au changement. Cela permet aussi de définir les règles métiers, d une manière rigoureuse, concise et précise. Cependant, nous devons choisir, parmi plusieurs formalismes de règles, le mieux adapté pour représenter un processus. Parce qu il existe de nombreux travaux sur les formalismes de règles et des langages basés sur les règles métier qui utilisent différentes syntaxes, nous avons pensé utile de présenter les forma- 43

57 Etat de l art / Caractéristiques des modèles & langages de processus métier lismes et langages de règles existants et les différents travaux qui ont adapté une approche basée sur les règles pour la modélisation un processus métier. 44

58 Etat de l art / Modélisation de processus basée sur les règles 4 Modélisation des processus métier basée sur les règles 4.1 Introduction 4.2 La classification des règles & langages de règles Les différents types de règles Les règles de dérivation Les règles de production Les règles de réaction Les règles de transformation Les langages de règles Langages du modèle métier indépendant de l'informatisation Langages du modèle indépendant de la plate-forme Langages du modèle spécifique à la plate-forme cible 4.3 La modélisation des processus métier par les règles de réaction Le formalisme ECA Les avantages des règles de réaction Les langages de processus basés sur les règles de réaction Les limites & chalenges des règles de réaction 4.4 Conclusion 4.1 Introduction Les règles jouent un rôle important dans la vie quotidienne. Elles permettent de formaliser une convention ou un principe vérifié comme les règles de la grammaire ou les règles mathématiques. En Informatique, les règles sont utilisées pour contrôler ou décrire le comportement des personnes et des systèmes, à titre d exemple nous pouvons citer les règles qui expriment et contrôlent les politiques d accès aux ressources sur les réseaux. Dans la discipline BPM, les règles métier sont des définitions de haut niveau structurées, qui permettent de contraindre, contrôler et influencer un aspect du métier. Ces règles sont utilisées pour implémenter les stratégies ou les politiques d une entreprise. Elles sont aussi utilisées pour modéliser un processus métier d une manière déclarative. Dans ce chapitre, nous allons nous intéresser aux formalismes de règles existants ainsi qu aux langages de règles proposés dans la littérature pour modéliser un processus métier. 45

59 Etat de l art / Modélisation de processus basée sur les règles 4.2 Classification des règles et langages de règles Dans la discipline BPM, les règles sont utilisées pour spécifier les directives internes impliquant les stratégies et les procédures opérationnelles de l entreprise et aussi pour spécifier les directives imposées de l'extérieur telles que les exigences juridiques, les normes et les contrats. Pour cela, ces règles ont les caractéristiques suivantes : Atomique : une règle ne peut pas être subdivisée. On ne peut pas la scinder sans perdre de l information. Non-ambiguë : La définition d une règle doit être rigoureuse, concise et doit exprimer une connaissance métier valide Cohérente au sein du système global : L ensemble de règles doit fournir une description stable du système Énoncée avec une terminologie commune au métier : Les experts doivent pouvoir valider et enrichir la base de connaissance «knowledge repository» Dans la littérature, plusieurs catégories de règles ainsi que plusieurs langages de règles ont été proposés. Dans cette section, nous allons nous intéresser aux catégories de règles et aux langages de règles les plus connus Catégories de règles Parmi les classifications de règles proposées [Cha04, Zur07], la plus citée est la classification proposée par Wagner dans [Wag05]. En effet, cette classification, distingue cinq catégories de règles métier Les règles d intégrité Il s agit des contraintes ou assertions qui doivent être satisfaites. Exemple : le client doit être enregistré pour satisfaire la commande Les règles de dérivation Il s agit d une ou plusieurs conditions et d une ou plusieurs conclusions. Exemple : Le client fidèle reçoit une remise de 10%. Boukhebouze est un client fidèle. Comme conclusion : Boukhebouze doit recevoir une remise de 10%. 46

60 Etat de l art / Modélisation de processus basée sur les règles Les règles de production Il s agit d une ou plusieurs conditions et d une ou plusieurs actions. Exemple : Si le stock est épuisé, Alors lancer l approvisionnement Les règles de réaction Il s agit des règles qui se déclenchent par des occurrences d événements et qui exigent une satisfaction de conditions pour exécuter des actions. Exemple : à la réception d une commande, si les matières premières sont disponibles alors lancer la production Les règles de transformation Il s agit des règles qui contrôlent le changement d état du système. Exemple : L âge d un employé doit être changé de manière incrémentale Les langages de règles L expérience a montré que les entreprises expriment leurs politiques et réglementations sous forme de règles en utilisant généralement le langage naturel [Zur07]. Toutefois, ces règles doivent être rigoureuse, concises et précises pour garantir que ces règles soient non ambiguës, cohérentes, complètes et énoncées avec une terminologie commune au métier. Pour cela, plusieurs langages de règles ont été proposés pour formaliser la définition des règles métiers. En effet, ces langages utilisent différents formalismes pour définir, d une manière déclarative, les règles métier. Selon Wagner [Wag05], ces langages peuvent être classés en accord avec l'architecture MDA (voir figure 4.1). En effet, cette architecture, permet de définir différents modèles : un modèle métier indépendant de l'informatisation (Computation Independent Model, CIM), un modèle indépendant de la plate-forme (Platform Independent Model, PIM) et enfin un modèle spécifique à la plate-forme cible (Platform Specific Model, PSM). Notons que nous avons complété la classification de Wagner par des nouveaux langages (exprimé en pointillé dans la figure 4.1). 47

61 Etat de l art / Modélisation de processus basée sur les règles Figure 4.1 Les langages de règles aux différents niveaux d'abstraction [Wag05] 48

62 Etat de l art / Modélisation de processus basée sur les règles Langages du modèle métier indépendant de l'informatisation Dans ce niveau d abstraction, des méta-modèles de règles sont proposés dans le but de définir des vocabulaires métier (les concepts et termes) utilisés pour exprimer les règles métier. Pour cela, la définition d un vocabulaire peut être faite de manière textuelle avec une syntaxe imposée comme le standard SBVR (Semantics of Business Vocabulary and Business Rules, traduit : Sémantique du vocabulaire métier et des règles métier) dans [OMG08 b]. Ce standard a été proposé, par l OMG, pour permettre la description du vocabulaire métier séparément des règles métier. Cela permet de partager ce vocabulaire pour une standardisation des structures de données d une entreprise. La définition des règles pourrait se faire, également, en utilisant un modèle formel (par exemple la logique de description) et en projetant la sémantique du vocabulaire sur les éléments de ce modèle (par exemple un prédicat représente un terme). Notons que la définition d un vocabulaire peut être aussi faite d une manière graphique comme les diagrammes de classes UML [OMG08 a] ou d une manière formelle en utilisant la logique des prédicats ou les ontologies comme le langage de règle d OWL [W3C04 a] et le langage RDF [W3C99 a] Langages du modèle indépendant de la plate-forme Dans ce niveau d abstraction, des modèles de règles, supportés par des langages, sont proposés pour formaliser la définition des règles. Les formalismes de règles utilisés dans ces modèles dépendent de la catégorie de règles qu elles représentent. Un exemple de cela, est le langage OCL [OMG08 a] utilisé par UML pour exprimer les contraintes, ou le langage WS-policy [W3C06] qui permet d exprimer les contraintes de sécurité ou les transactions des services web sous forme de politiques, ou encore le langage XSL [W3C99 b] utilisé pour les règles de transformation des document XML. Un autre exemple des langages de règles est le standard PRR (Production Rule Representation) proposé par l OMG, pour exprimer les règles de production [OMG04]. En parallèle, une extension du langage de requêtes SQL est proposée pour exprimer les règles de réaction (Triggers) utilisées dans les base de donnée active. Pour offrir la capacité de représentation des différentes catégories de règles par un seul langage, le RuleML [Sch02] a été proposé par RuleML Initiative, et qui se base sur Datalog/Prolog pour permettre l'échange entre les différents langages de règles issues du web sémantique. C est le cas aussi du langage RIF (Rule Interchange Format) proposé par W3C 49

63 Etat de l art / Modélisation de processus basée sur les règles [W3C09] ou encore le langage SWRL [W3C04 b] et le langage SPARQL [W3C08]. Dans le même esprit, le projet REWERSE [Rew09 a] a été créé pour intégrer tous les types de règles et pour offrir, en plus, leurs visualisation. Le projet REWERSE a permis la proposition de deux langages : le R2ML [Wag05] qui permet la traduction des règles entre les différents systèmes en supportant tous types de règles et l URML [Wag06] qui permet de modéliser graphiquement des règles avec des notations graphiques héritées d UML. Notons une énumération des langages de règles est donnée donne [Rew09b] Langages du modèle spécifique à la plate-forme cible Dans ce niveau d abstraction, des modèles d'exécution de règles sont proposés afin de formaliser la sémantique d exécution des langages de règles. Ces modèles sont exécutés par les moteurs de règles. Un moteur de règles interprète les déclarations des règles et modifie (ou crée) les données et objets métier auxquels la règle s applique. Le moteur de règles peut aussi lancer des actions spécifiées dans une règle comme lancer l approvisionnement. La plupart des moteurs de règles permettent l exécution de règles en cascade [Wag05] : L exécution d une action d une règle peut rendre la condition d une autre règle active et entraîne son exécution. Ainsi, une cascade de règles peut être générée. Ces types de moteurs de règles s appuient souvent sur l algorithme RETE développé par Forgy dans [For79]. Dans la littérature, plusieurs moteurs de règles sont proposés sur le marché. Le plus connu est le JRules proposé par ILOG [ilog09]. Ce moteur permet d interpréter les règles de production de type «si / alors». Des API Java de moteurs de règles ont été également proposées pour faciliter l intégration de ces moteurs avec les applications Java et améliorer l interopérabilité entre les solutions des différents éditeurs. Un exemple de ces API, JRuleEngine qui utilise un format XML pour exprimer les règles ou encore l API Drools qui exécute les règles exprimées en orienté objet. A travers cette étude, nous avons vu que la littérature regorge de langages basés sur les règles qui utilisent différents paradigmes et plusieurs syntaxes. Toutefois, ces langages sont soit très génériques ou définis pour un domaine spécifique et dans les deux cas ces langages ne suffisent pas pour définir un processus métier car ils ne représentent pas tous les aspects du processus. 50

64 Etat de l art / Modélisation de processus basée sur les règles Nous avons, donc, besoin de langages de règles dédiés à la modélisation des processus métier. Cependant, quel formalisme de règle est le mieux adapté pour de tels langages? Dans la section suivante, nous allons examiner cette question et présenter les travaux qui ont utilisé une approche basée sur les règles pour modéliser un processus. 4.3 La modélisation des processus métier par les règles de réaction Selon plusieurs travaux, [Kno00], [Bry06 a], [Wag06] et [Giu06], les règles de réaction (formalisme ECA) sont les mieux adaptées pour décrire la logique du processus par un ensemble de règles. Girrca et al. dans [Giu06], justifient cela par le fait que le formalisme ECA, sur le quel se basent les règles de réaction, permet de spécifier le flux de contrôle d un processus d une manière flexible en utilisant les événements. En plus, ces règles sont faciles à maintenir et permettent d intégrer tous les types de règles (contraintes, déviations, productions, et transformations) [Wag06]. Pour cela, nous allons nous intéresser, dans cette section, au formalisme ECA, en expliquant les avantages de l utilisation de ce formalisme dans la définition d un processus métier, les travaux qui l ont adopté, et limites du modèle du processus ECA Le formalisme ECA Les règles ECA sont des extensions des règles de production à savoir des règles où la partie événement est absente; elles se notent Condition-Action (CA). D une manière générale, une règle ECA se formalise par : ON IF DO <Event> <Condition> <Action> L événement détermine quand une règle doit être évaluée et la condition est un prédicat dont dépend l exécution de l action (elle peut être considérée comme un affinement de l événement). L action, quant à elle, spécifie le code à exécuter si la condition est à vraie. La sémantique attachée à une règle est la suivante : lorsqu un événement se produit, la partie condition est vérifiée. Si la condition est satisfaite, alors la partie action est exécutée en tenant compte des attributs associés à la règle. 51

65 Etat de l art / Modélisation de processus basée sur les règles Notons que d autres formes du formalisme ECA ont été proposées comme ECAP pour ajouter une post condition sur l exécution de la partie action et pouvoir ainsi valider la règle (voir figure 4.1) Les avantages des règles de réaction Selon Bry et al. dans [Bry06 a], une modélisation de processus métier basée sur les règles ECA peut avoir les avantages suivants : - Les exigences politiques et règlementations métier sont souvent exprimées sous forme de règles en utilisant le langage naturel ou formel. En particulier, dans les exigences des processus métier, on trouve souvent des règles ECA comme par exemple : «une demande de carte de crédit (événement) sera accordée (action) si le demandeur a un revenu mensuel de plus de 1500 (condition)». - Les règles de réaction (règles ECA) permettent d intégrer facilement tous les autres types de règles métier : les contraintes, exemple : la contrainte «le client doit être enregistré pour satisfaire la commande» peut être exprimée «Lors d une réception de commande (événement), si le client n est pas enregistré (condition), alors annuler la commande (action)»; les règles de dérivations, exemple : la règle de dérivation suivante «Le client fidèle reçoit une remise de 10%. Boukhebouze est client fidele. Comme conclusion : Boukhebouze reçoit une remise de 10%» peut être exprimée en deux règles «Règle 1 : lors d une facturation (événement), si le client est fidèle (condition), alors remise de 10% (action)»; les règles de production, car les règles ECA sont des extensions des règles de production, exemple : si le état de stock est épuisé (condition), alors lancer l approvisionnement (action) ; les règles de transformation, exemple : la règle de transformations suivante «Le salaire d un employé doit être changé de manière incrémentale» peut être exprimée «Lors d une modification des informations d un employé (événement), si nouveau salaire ancien salaire < 0(condition), alors signaler une erreur (action). - Les règles ECA offrent une flexibilité de modélisation car elles sont faciles à modifier et à maintenir pour s adapter aux changements fréquents dans les réglementations de politiques des entreprises. En plus, en utilisant les règles ECA, la définition du processus peut être complétée «à chaud» sans impacter les instances en cours d exécution car le moteur de règles ECA détermine, dans la phase d exécution, ce qui doit 52

66 Etat de l art / Modélisation de processus basée sur les règles être exécuté en évaluant les événements de l ensemble de règles définies. - La gestion des exceptions est une partie importante dans la définition du processus pour spécifier comment réagir dans le cas où une exception surgit. Pour cela, il faut modéliser les situations imprévues qui surgissent pendant l exécution d un processus, ce qui n est pas toujours évident à élaborer [Geo07]. Puisque, les exceptions peuvent être exprimées par des événements, les règles ECA permettent de traiter ces erreurs opérationnelles de manière native, ce qui rend la gestion des exceptions plus facile. - Dans la modélisation centrée activité du flux de contrôle (modélisation impérative), les activités sont lancées en réaction à l achèvement de la ou des activités précédentes. Cependant, la réaction aux états intermédiaires des activités n est pas supportée dans ce type de modélisation [Car04]. Les règles ECA, qui se basent sur les événements, offrent plus de flexibilité pour spécifier les flux de contrôles en utilisant les événements générés par les activités [Kno00] Les langages de processus basés sur les règles de réaction Dans la littérature, plusieurs travaux ont utilisé la puissance des règles ECA pour modéliser un processus métier. Les principaux travaux peuvent être résumés dans le tableau suivant : 53

67 Etat de l art / Modélisation de processus basée sur les règles Travail Auteurs Résumé Zeng et al. dans [Zen02] La plateforme AgFlow Le processus est vu comme un ensemble de tâches coordonnées entre elles par des règles ECA et d utiliser les agents pour encapsuler les services qui exécutent les tâches du processus. Le langage BPTrigger La plateforme AgentWork Modèle de processus basé sur les règles E-C-A Object-Rule- Role approach Le langage XChange Modélisation des services web par l URML Chulsoon et al. dans [Chu04] Müller dans [Mul04] Knolmayer et al. [Kno00] Kappel et al. [Kap00] Bry et al. [Bry06 b] Wagner et al. [Wag06] Le processus métier complexe est modélisé et exécuté dans un environnement distribué et hétérogène en utilisant un nouveau langage appelé BPTrigger qui se base sur le formalisme ECA. Une plateforme de définition des Workflow est proposée. Cette plateforme, appelée AgentWork, se base sur la technologie des agents pour diagnostiquer les événements aléatoires. La prédiction et la réactivité aux exceptions sont définies en utilisant les règles ECA automatisées par des agents. Les règles ECA sont utilisées, aussi, pour la gestion temporelle de Workflow. Un modèle de processus basé sur les règles ECA est proposé pour pouvoir intégrer les différents langages de modélisation de processus et pourvoir affiner les règles métier Une plateforme de modélisation du Workflow basée sur les règles ECA est proposée pour favoriser la réutilisabilité et la flexibilité d un Workflow en se basant sur les règles ECA qui permettent d allouer les tâches et les ressources dans un Workflow. Le langage XChange, proposé initialement pour modéliser les comportements des applications web distribuées en se basant sur les règles ECA, est utilisé pour modéliser un processus métier. Le langage graphique URML (UML basé sur les règles) est utilisé pour modéliser les services Web. Pour cela, un vocabulaire métier est défini ainsi qu un modèle d événement. 54

68 Etat de l art / Modélisation de processus basée sur les règles Les patrons de flexibilité basés sur les règles ECA Van Eijndhoven et al. [Van08] Ce travail propose d'étendre les langages impératifs pour ajouter une dimension de flexibilité au modèle du processus. Pour cela, les parties les plus variables dans un processus métier sont modélisées en utilisant des patrons de flexibilité basés sur les règles ECA. Tableau 4.1 Les principaux travaux de modélisation de processus basée sur les règles ECA Les limites & chalenges des règles de réaction Malgré les nombreux travaux proposés pour modéliser un processus métier en utilisant le formalisme ECA, ce formalise présente les limites suivantes : - La majeure limite des règles ECA est qu elles ne reflètent pas toujours explicitement l'ordre des activités du processus contrairement aux tendances des concepteurs, qui utilisent souvent une modélisation procédurale (impérative) ou une modélisation orientée objet pour décrire leur programme. De plus, la vérification du processus exige d avoir un scénario d exécution pour tester le bon fonctionnement du processus. Malheureusement, le formalise ECA décrit un scénario d exécution d une manière implicite. Pour analyser le fonctionnement du processus on doit construire un scénario d exécution à partir d un modèle implicite ce qui n est pas toujours évident. - Le formalisme ECA classique ne permet pas de contrôler l exécution de la partie action de la règle. En effet, en cours d exécution d une action, des erreurs sémantiques et exceptions opérationnelles peuvent surgir. Les erreurs sémantiques sont commises par les concepteurs et n'ont aucune incidence sur l'exécution du processus, mais le résultat obtenu n'est pas celui attendu. A leur tour, les exceptions opérationnelles concernent des événements imprévus comme une panne matérielle du système informatique qui peut déstabiliser le fonctionnement du processus métier ou encore une indisponibilité de ressources. Mal- 55

69 Etat de l art / Modélisation de processus basée sur les règles heureusement, le formalisme ECA classique ne prévoit pas de valider l exécution de l action et/ou de lancer un mécanisme de compensation d une exception pour annuler l effet d exécution erronée de l action. - Les langages de règles existants (notamment les langages de règles ECA) se focalisent sur les concepts de règles sans offrir des modèles pour permettre de définir les éléments d un processus, comme les activités métier, les participants etc. - Une modélisation de processus basée sur les règles ECA a besoin des outils qui permettent la visualisation et la maintenance des processus. Ces outils doivent permettre une visualisation de l ensemble des règles pour offrir une vue fonctionnelle du processus. Cependant, à notre connaissance, de tels outils ne sont pas encore implémentés. - Le monitoring des processus métier modélisés par des règles n est pas encore exploré contrairement aux processus modélisés par l approche centrée activités (par exemple les processus BPEL). En effet, dans l approche centrée activités, l état des activités du processus est facilement déductible (activité en cours d'exécution ou en fin d exécution). En revanche, dans l approche basée sur les règles ECA, l état des activités est déduit en analysant l historique des événements, ce qui n est pas toujours facile à faire. 4.4 Conclusion Dans ce chapitre, nous avons vu que les règles métier peuvent être utilisées pour modéliser un processus métier d une manière déclarative. En effet, dans cette approche de modélisation, la logique du processus est décrite par un ensemble de règles. A travers cette étude, nous avons vu que la littérature offre un bon nombre de langages basés sur les règles métier qui utilisent différents formalismes et syntaxes. Toutefois, parmi les différents formalismes de règles existants, le formalisme ECA s avère être le plus adapté pour modéliser un processus car ces règles permettent de spécifier le flux de contrôle d un processus d une manière flexible en utilisant les événements. En plus, les règles ECA sont faciles à maintenir et permettent d intégrer tous les types de règles (contraintes, déviations, productions, et transformations). Pour cela, de nombreux travaux ont été proposés pour modéliser un processus en utilisant le formalisme ECA. 56

70 Etat de l art / Modélisation de processus basée sur les règles Cependant, les règles ECA ont besoin d un mécanisme qui permet de contrôler l exécution de l action et de lancer une compensation dans le cas où l exécution de l action est invalide. D autant plus, la vérification du processus modélisé par les règles ECA est plus complexe, car elle doit être obtenue en construisant un scénario d exécution à partir d un modèle implicite ce qui n est pas toujours évident, comme nous allons voir dans le chapitre suivant. Pour détailler ce dernier point, nous allons décrire dans ce qui suit un état de l art sur les techniques de vérification de processus existantes car la vérification de processus est au cœur également de nos préoccupations. 57

71 Etat de l art / Techniques de vérification de processus métier 5 Techniques de vérification de processus métier 5.1 Introduction 5.2 Les erreurs et exceptions d un processus métier 5.3 Les techniques de la vérification des processus métier Vérification par guides de style de modélisation Vérification par simulation Vérification par modèles formels Vérification par process-mining Synthèse 5.4 Introduction aux modèles formels et les réseaux de Pétri formels Définition Utilisation Classification Les réseaux de Pétri 5.5 La vérification des processus métier La vérification dans le cas des langages impératifs La vérification dans le cas des langages déclaratifs 5.5 Conclusion 5.1 Introduction Les entreprises doivent se baser sur des processus métier robustes et fiables pour mener à bien leurs missions. La fiabilité des processus est une question primordiale car ces derniers automatisent tout ou partie de la chaîne de valeur d une entreprise et capitalise en même temps leur système d information. Un processus erroné peut avoir, pour une entreprise, des conséquences graves sur le plan économique. La fiabilité des processus d'une part et la maîtrise des coûts de maintenance d'autre part conduisent à accorder une attention plus grande aux questions de vérification des processus. En effet, la vérification des processus métier à pour but de montrer que les activités du processus s exécutent en conformité avec son plan de réalisation et qu elles n ont pas introduit des erreurs dans le résultat. Parce que la fiabilité des processus métier est un deuxième objectif de notre contribution, nous décrirons dans ce chapitre les nombreux travaux sur les techniques de vérification des processus métier. 58

72 Etat de l art / Techniques de vérification de processus métier 5.2 Les erreurs et exceptions d un processus métier Une erreur désigne un «Bug» dû à une imprécision de modélisation ou au dysfonctionnement lors de l exécution d'un processus métier. Ces erreurs peuvent concerner des erreurs fonctionnelles, sémantiques ou d exécution. Une erreur d exécution qui caractérise toutes situations imprévues qui surgissent pendant l exécution d un programme, est appelée une exception [Rus06 c]. Dans la littérature, plusieurs travaux sont été conduits pour étudier la nature des erreurs de modélisation et les exceptions survenues dans l exécution des processus métier et cela d une manière indépendante de leurs approches de modélisation et des technologies utilisées pour leur exécution [Rus06 c, Ada05, Bra05, Sub08]. D une manière générale, les erreurs survenues dans un processus métier peuvent être classifiées comme suit : Les erreurs fonctionnelles Les erreurs fonctionnelles concernent la cohérence fonctionnelle du processus métier. L origine de ces erreurs est due à une mauvaise conception comme les boucles infinies (Livelock) qui exprime une situation où l exécution du processus tourne en rond indéfiniment, l inter blocage (deadlock) qui exprime une situation où l exécution du processus est dans une attente infinie, ou encore des activités continuent d être exécutées après la terminaison du processus Les erreurs opérationnelles Les erreurs opérationnelles concernent les événements aléatoires qui sont susceptible d'entraîner des exceptions. En effet, ces événements sont rares et imprévus comme une panne matérielle du système informatique qui peut déstabiliser le fonctionnement du processus métier ou encore les exceptions générées à cause de l indisponibilité d une ou plusieurs ressources au moment où une activité en cours d exécution veut y accéder ou le cas où la ressource ne satisfait plus les critères d allocation qu une activité exige Les erreurs non fonctionnelles Les erreurs non fonctionnelles concernent les erreurs sémantiques qui sont commises par les concepteurs et qui n'a aucune incidence sur l'exécution elle-même du processus, mais le résultat obtenu n'est pas celui attendu. Un 59

73 Etat de l art / Techniques de vérification de processus métier exemple de ces erreurs est de définir une activité non atteignable (dead activity), dans ce cas, l activité définie ne sera jamais exécutée. Un autre exemple est celui de violation de contraintes qui assurent l intégrité et la cohérence métier des processus (effectuer une commande si le stock est épuisé). En effet, ces contraintes peuvent être spécifiées sur les données, les ressources ou sur les comportements de processus. Cependant un conflit de contraintes, par exemple, peut conduire à une situation invalide. 5.3 Les techniques de vérification des processus métier En se référant au cycle de vie d un processus métier, les erreurs peuvent être repérées et gérées dans la phase de modélisation, la phase d exécution ou la phase de monitoring. Pour aider le concepteur à trouver les erreurs, un certain nombre de techniques sont utilisées parmi lesquelles : La vérification par guides de style de modélisation Dans cette technique, des règles sémantiques à respecter sont définies pour détecter les erreurs dans la phase de modélisation (comme interdire l association d une ressource à deux activités métier en même temps). Ces règles sont considérées comme des guides de style de modélisation qui sont utilisés afin de guider le concepteur à éviter les éléments qui peuvent conduire à des erreurs ou les éléments qui représentent une source potentielle d erreurs. Cette technique propose un bon style de modélisation en exigeant aux concepteurs de respecter des règles de modélisation pour minimiser le risque d erreurs. Un exemple de ces règles est proposé par Gruhn et al. [Gru07] pour la vérification du langage EPC (Event-driven Process Chains) et le travail de Van Dongen et al. [Van05 b] qui vérifie les modèles de références MySAP à travers l AGL ARIS La vérification par simulation La vérification par simulation consiste à évaluer et comparer le processus modélisé en utilisant plusieurs scénarii possibles. La simulation fournit ainsi des estimations quantitatives sur l'impact qu'une conception de processus est susceptible d'avoir sur l'exécution de processus [Jan06]. Plusieurs simulateurs de processus métier ont été proposés, ces outils permettent aux entreprises et aux organisations d'analyser rapidement leurs processus métier. 60

74 Etat de l art / Techniques de vérification de processus métier Dans [Jan06], un certain nombre de ces outils sont comparés par rapport à leur applicabilité dans le domaine du BPM et aux modèles utilisés La vérification par modèles formels La technique de vérification par modèles formels exige de formaliser et vérifier la spécification du processus en utilisant un modèle formel donné. L objectif étant de minimiser les risques qu un dysfonctionnement puisse se produire en se basant sur les propriétés de vérification offertes par ses modèles comme l absence de blocage, la propriété d atteignabilité, etc. On peut ainsi détecter les erreurs en tenant compte des propriétés du modèle. Nous avons recensé de nombreux travaux qui utilisent cette technique pour vérifier le bon fonctionnement des processus métiers. D une façon générale, le réseau de Pétri (RdP) est le modèle le plus utilisé [Mar03, Ouy05 a, Ouy05 b, Yan05] et cela parce qu il combine les avantages de la représentation graphique avec l aspect sémantique attribué au comportement du processus modélisé. Le plus grand intérêt d un réseau de Pétri ne se limite pas à sa capacité de modélisation de comportement. En effet, un RdP offre aussi un large éventail de propriétés mathématiques et des outils qui permettent d analyser le bon fonctionnement du système. L algèbre de processus s est imposée aussi dans la vérification des processus [Smi03, Kos04]. Il s agit d un langage basé sur un formalisme mathématique dédié à la description des systèmes concurrents. Ce modèle se base principalement sur les théories de la concurrence et les techniques des algèbres universelles. Ceci étant, d autres approches, se basant sur des modèles différents, ont été proposées. Un exemple de cela est le travail de Pu [Pu05] qui se base sur le model TA (Timed Automata) et qui propose µ-bpel, un nouveau langage basé sur le langage d exécution de processus BPEL et qui définit la sémantique des activités de base et structurée. Un autre exemple, est la plateforme VERBUS [Fis04] qui est une plateforme modulaire extensible qui n est pas liée à un outil de vérification ou à un langage de description de processus spécifique. Notons que Van Breugel recense dans [Van06] les différents travaux proposés pour la vérification des processus métier La vérification par process-mining Dans la phase de monitoring, les erreurs opérationnelles et les erreurs non fonctionnelles sont détectées et cela en analysant le processus exécutable dans le but de mesurer les performances opérationnelles et métier en se basant sur les journaux des événements. Le processus exécutable est analysé, 61

75 Etat de l art / Techniques de vérification de processus métier aussi, afin de reconstruire le processus métier, à partir des informations cumulées lors de la phase précédente. Le processus résultat sera comparé au processus modélisé pour savoir s il s agit du même déroulement de l ensemble des activités, c.-à-d permettre aux analystes métier d assurer que le processus exécutable correspond aux exigences métier Synthèse La technique par simulation utilise des données théoriques et la qualité des estimations fournies dépend fortement de la batterie de tests utilisée. A son tour, la technique de vérification par guides de style ne peut pas remplacer la vérification par les modèles formels car cette technique tente de limiter les erreurs les plus connues, d'autant plus que cette technique ne détecte pas les erreurs produites lors de l implémentation du processus. Par ailleurs, le temps que consomment les algorithmes liés à la technique de vérification par les modèles formels dépend de la complexité des algorithmes de traduction de la définition des processus métier en modèles formels et la complexité des algorithmes de détection des propriétés à vérifier. Malgré cet inconvénient, la technique de vérification par les modèles formels s avère avantageux et cela parce qu elle augmente la certitude qu un dysfonctionnement ne se produira pas. Pour cette raison, nous allons détailler, dans la section suivante, les différents modèles formels utilisés pour la vérification des processus métier. 5.4 Introduction aux modèles formels et aux réseaux de Pétri En utilisant les langages de modélisation des processus métier, les concepteurs ne sont pas à l abri de commettre des erreurs de spécification. Pour cela, les concepteurs ont souvent recours aux modèles formels. Ces modèles exigent de formaliser de processus en utilisant un modèle donné (par exemple réseau de Pétri, algèbre de processus etc.) Définition Un modèle est dit «formel» s il est fondé sur une syntaxe et une sémantique précises, construit sur des bases théoriques. Des raisonnements syntaxique et sémantique sont alors possibles pour démontrer des propriétés d'une spécification. 62

76 Etat de l art / Techniques de vérification de processus métier Utilisation L objectif de l utilisation des modèles formels pour la modélisation de processus est double : fournir, d une part, une description formelle d un processus vis-à-vis de ses exigences en éliminant les contradictions et les ambiguïtés (spécification formelle). D autre part, l objectif est aussi de minimiser les risques qu un dysfonctionnement puisse se produire en se basant sur les propriétés de vérification offertes par ses modèles (vérification formelle) Classification Dans la littérature, de nombreux modèles formels sont proposés. Selon Attiogbé, dans [Att07], Ces modèles peuvent être soit : - orientés opérations pour décrire le fonctionnement du système ou son comportement par des axiomes - orientés données pour décrire les états du système - hybrides qui combinent les deux orientations Pour cela on peut distinguer trois principales approches de méthodes formelles, comme l illustre la figure L approche axiomatique Dans l approche axiomatique on s intéresse aux opérations du système en construisant une axiomatisation qui fournit les propriétés comportementales du système à formaliser en utilisant une approche algébriques ou une approche logique [Att07]. En effet, l approche algébrique permet de définir des types abstraits de données en spécifiant pour chaque opération les types de valeurs de ses paramètres et du résultat, en précisant une expression construite à l aide des opérations et des variables (appelée un terme), et en décrivant les propriétés des opérations sous forme d équivalences entre termes (les axiomes). L application des axiomes à des termes permet d obtenir d autres expressions d équivalence [Tru06]. 63

77 Etat de l art / Techniques de vérification de processus métier Figure 5.1 La classification des différents modèles formels Parmi les langages de spécification algébrique connus nous pouvons citer : OBJ [Gog96], LPG [Ber95] et le langage algébrique standard nommé CASL [Bid04]. A son tour, l approche logique permet d exprimer des systèmes transformationnels en utilisant la logique temporelle pour exprimer des propriétés dynamiques de sûreté et de vivacité des systèmes réactifs. Dans cette approche on s intéresse à la démonstration de programmes en appliquant les théories de la démonstration automatique ou semiautomatique de théorèmes [Tru06]. Parmi les langages de spécification logiques connus nous pouvons citer : PVS [Owr93], Isabelle/HOL [Smi02] ou Coq [Ber04] L approche basée sur les états Dans l approche basée sur les états on s intéresse aux données du système, en construisant, à l aide des concepts de base fournis, un modèle du système à formaliser. Ce modèle doit avoir les propriétés du système. On peut ensuite raisonner sur le fonctionnement du système en utilisant le modèle obtenu. Pour cela, les approches ensemblistes et les approches dynamiques sont utilisées. En effet, les approches ensemblistes (appelés aussi approches par modèle abstrait) permettent de fournir une syntaxe et une sémantique du modèle abstrait en se basant sur la théorie des ensembles, logique du premier ordre, ou la théorie des types. Selon Truong, dans [Tru06], les approches ensemblistes différent des approches algébriques par le fait que les approches ensemblistes utilisent des types abstraits prédéfinis pour modéli- 64

78 Etat de l art / Techniques de vérification de processus métier ser l état du système à construire, chaque opération est spécifiée indépendamment en décrivant son effet sur l état du système. Parmi les langages de spécification ensemblistes connus nous pouvons citer : VDM [Cli86], Z [Att07] et B [Tru06]. A leur tour, les approches dynamiques se basent sur la notion du processus pour spécifier les systèmes de transitions en utilisant les automates, les réseaux de Pétri et les algèbres de processus (comme CSP [Att07]) L approche hybride Dans l approche hybride on complète une axiomatisation par un modèle de données ou bien on complète un modèle de données par une axiomatisation [Att07]. Par exemple LOTOS [Tur07] est considéré comme un langage algébrique car ses expressions de contrôle sont caractérisées par une algèbre dont les termes sont des processus. Cependant, les données sont caractérisées par une algèbre de types abstraits dont les termes sont des expressions fonctionnelles [Tru06]. Le langage CCS [Mil80] et le langage ACT ONE [Cha97] sont les prédécesseurs de LOTOS. D une façon générale, l approche basée sur les états est l approche la plus utilisée pour vérifier, d une façon formelle, un processus métier car cette approche permet un raisonnement sur le fonctionnement d un processus. Spécialement, les réseaux de Pétri (RdP) constituent le modèle le plus utilisé, dans cette approche [Mar03, Hin05, Ouy05 b, Pu05, Yan05] et cela parce qu ils combinent les avantages de la représentation graphique avec l aspect sémantique attribué au comportement du processus modélisé. Pour cette raison, nous allons détailler, dans la section suivante, les réseaux de Pétri Les réseaux de Pétri Les réseaux de Pétri (RdP) ont été introduits par Carl Adam Pétri, en 1962, afin de modéliser et d analyser les comportements des systèmes d une manière graphique en se basant sur un modèle mathématique. Les RdP sont largement utilisés pour la modélisation des processus métier Comme l illustre le RdP de la figure 5.2, un réseau de Pétri est un graphe orienté et biparti c.à.d. qu il a deux types de nœud Place/Transition : Une place modélise une condition ou l état d une ressource du système (exemple : une imprimante est au repos, une commande est effectuée). Une transition modélise un événement ou une action qui se déroule au sein du système (exemple : réception d une demande d impression, traitement d une commande). Les conditions nécessaires pour déclencher une action 65

79 Etat de l art / Techniques de vérification de processus métier sont modélisées par les arcs relient une place aux transitions. Les effets d'une action sur l'état du système sont modélisés par les arcs joignant les transitions aux places. Si une place contient un jeton (ou marque) cela signifie que la condition représentée par cette place est vérifiée (exemple : impression terminée) ou indique la disponibilité d une ressource dans le cas ou on a plusieurs jetons dans la place (exemple : nombre de pièces en stock). On dit que la transition est tirable si les conditions requises (ou les ressources nécessaires) pour déclencher l'action (ou l événement), représenté par cette transition, sont satisfaites (ou disponibles). Figure 5.2 Le processus de traitement de commande modélisé en RdP Formellement, un réseau de Pétri peut être représenté par un triplet R= (P, T, W) défini par: - un ensemble fini non vide des places P = {p1, p2,, pn}, - un ensemble fini non vide de transitions T = {t1, t2,,tn}, - une fonction d incidence W: P T P T N correspondant aux arcs : W(p, t)p P, t T contient la valeur entière associée à l arc allant de p à t ; W(t, p)p P, t T contient la valeur entière associée à l arc allant de t à p ; 66

80 Etat de l art / Techniques de vérification de processus métier dans le cas où une place p ne serait pas reliée à la transition t, nous aurons simplement W(t, p) = 0 et W(p, t) = 0. Le plus grand intérêt d un réseau de Pétri ne se limite pas à sa capacité à modéliser une grande variété de systèmes discrets. En effet, un RdP offre aussi un large éventail de propriétés mathématiques qui permettent l analyse du bon fonctionnement du système. Nous distinguons dans la littérature plusieurs types de propriétés de RdP. Nous présentons ci-dessous une classification des propriétés souvent rencontrées dans les travaux de vérifications des systèmes Propriété d'atteignabilité (Reachability) Une propriété d atteignabilité énonce qu un certain état peut être atteint ou non. Exemples : "On peut entrer dans une section critique", "On ne peut pas atteindre l état Crash" ou "On peut revenir à l état initial" Propriété de sûreté (Safety) Une propriété de sûreté énonce que, sous certaines conditions, quelque chose de non désiré ne se produit jamais. Exemple : "Les deux systèmes ne seront jamais simultanément en section critique ", "Il n y aura jamais de débordement mémoire", "Non blocage" ou "Quelque chose de non souhaité ne se produit jamais". Il faut noter que la négation d'une propriété d'atteignabilité est une propriété de sûreté Propriété de vivacité (Liveness) Une propriété de vivacité énonce, que sous certaines conditions, quelque chose de correct finira par avoir lieu. Nous distinguons dans la littérature plusieurs formes de vivacité, entre autres, la vivacité de progression ou simple et la vivacité bornée. Propriétés de vivacité simple (ou de progression) Ce type de propriété énonce qu un état est toujours atteignable. "Une requête est satisfaite un jour" ou "Le système peut toujours retourner à l état initial" Propriétés de vivacité bornée (ou réponse bornée) Ce type de propriété impose un délai maximal avant lequel la situation souhaitée finira par avoir lieu. Exemples :"Toute requête finira par être satisfaite en au moins de 5 mn", "Le feu passera au vert en au plus 3mn " ou "Le programme se termine en au plus 10s" 67

81 Etat de l art / Techniques de vérification de processus métier Propriété d'absence de blocage (No deadlock) L'absence de deadlock est une propriété particulière qui exprime que le système ne se trouvera jamais dans une situation où il ne peut plus progresser Propriété d'équité (Fairness) Cette propriété énonce que, sous certaines conditions, quelque chose aura lieu (ou n aura pas lieu) un nombre infini de fois. Exemples : "La barrière sera levée infiniment souvent", "Si l on demande l accès à une section critique un nombre infini de fois, alors il sera accordé un nombre infini de fois " Cependant, le réseau de Pétri classique de Adam Pétri présente des lacunes en terme d expressivité comme faire la distinction entre deux jetons ou exprimer la dimension temporelle. Pour augmenter le niveau d expressivité, le réseau de Pétri a connu plusieurs extensions au fil des années. Les extensions les plus connues sont les réseaux de Pétri colorés et les réseaux de Pétri temporels. Dans les réseaux de pétri colorés les jetons sont typés (colorés) pour permettre de représenter les différentes caractéristiques des ressources représentées par ce jeton (exemple : une pièce {type de la pièce, numéro de la pièce, la matière de fabrication}). De cette façon, les pré-conditions de type «que les jetons d une couleur donnée sont tirables» peuvent être supposées (exemple : que les pièces fabriquées en fer peuvent être acceptées). Les réseaux de pétri temporels permettent la prise en compte de l aspect temporel en exprimant combien de temps dure une action et à quel instant une action se déclenche. Ces types de réseaux sont très utiles pour mesurer la performance du processus. Toutefois, Selon Van der Aalst et at., dans [Van02], ces extensions ne permettent pas de modéliser certains patrons du flux de contrôle, comme les patrons d instance multiples (exemple le patron «boucle structurée» qui modélise le sous processus qui s exécute d une façon répétée) ou encore les partons d annulation (exemple le patron «Annulation d activité» qui modélise une annulation d activité ou encore le pattern «Annulation d instances» qui décrit une annulation d une instance en cours d exécution). Malgré ces faiblesses, les RdP restent les modèles les plus utilisés pour décrire et vérifier les processus métier. Plusieurs travaux ont exploité les forces des ces réseaux pour vérifier les erreurs que peut contenir un processus métier. D une façon générale, ces travaux proposent, des outils qui réécrivent la spécification des processus en terme de RdP (des traducteurs), les réseaux obtenus seront analysés par d autres outils (analyseurs) afin de vérifier certaines propriétés comme l absence de blocage, la vivaci- 68

82 Etat de l art / Techniques de vérification de processus métier té du réseau, etc., ils peuvent ainsi détecter les erreurs en tenant compte des propriétés détectées. Cette démarche est résumée dans la figure 5.3. Figure 5.3 Les principales démarches de vérification d un processus métier par les RdP Une panoplie d outils a été proposée pour traduire un processus métier en un réseau de Pétri. Parmi ces outils, nous pouvons citer l'outil BPEL2PNML [Hin05] qui est proposé par l équipe de recherche de l université d Eindhoven, et l outil BPEL2oWFN [Ouy05 b] qui est proposé par une équipe de recherche de l université de Berlin. Le BPEL2PNPL transforme automatiquement un processus métier exprimé par le langage BPEL en un réseau de Pétri exprimé en PNML (Petri Net Markup Language) [Hil09]. Ce dernier, est un langage standard pour décrire les réseaux de Pétri, ce format est accepté par la plus part des analyseurs RdP. Par contre, le BPEL2oWFN traduit un processus BPEL en un Workflow Nets (owfn). Un Workflow Nets est un réseau de Pétri avec une interface c.à.d. deux ensembles de places une place d entrée (input place) et un place de sortie (output place). En plus, ce réseau possède un ensemble fini de marquage. Cependant, un réseau de pétri généré par cet outil est sous format owfn, ce qui présente une limite car il n y a que l analyseur Fiona qui accepte ce format. Le RdP résultant de ces outils peut être vérifié en utilisant l'outil d analyse de réseaux de Pétri. En effet, l'outil LoLA [Sch00] par exemple représente un analyseur de bas niveau, il permet de vérifier les propriétés standards des RdP. Woflan [Ouy05 a] est un autre exemple d outil de vérification basé sur les réseaux de pétri. Il est employé pour vérifier l'exactitude des procédures de Workflow. Il a été intégré à plusieurs systèmes de 69

83 Etat de l art / Techniques de vérification de processus métier gestion de Workflow. PIPE (Platform Independent Petri-net Editor) [Blo03] est un outil open source qui dispose d une interface graphique pour élaborer et analyser des réseaux de Pétri. L avantage de cet outil est qu il permet de visualiser des réseaux de Pétri écrit en PNML. Il est également très facile à utiliser et dispose de plusieurs modules pour effectuer les différents types d'analyse de réseaux de Pétri. Tina (TIme petri Net Analyzer) [Ber06] est un éditeur et analyseur des réseaux de Pétri classique et réseaux de Pétri temporisés. Il dispose d une interface graphique pour éditer graphiquement les RdP, et permet de lire et sauvegarder les RdP sous plusieurs formats. TINA peut effectuer la construction des graphes d'accessibilité qui permet de faire l analyse structurelle des Réseaux de Pétri. Par contre WofBPEL [Ouy05 b] est un outil destiné à n analyser, dans processus métier, que les liens de contrôle (les control links) et les activités qui présentent un conflit de consommation de messages (conflicting messageconsuming activities). Pour cela cet outil s intéresse qu à vérifier la propriété d accessibilité d un RdP. 5.5 La vérification des processus métier La vérification dans le cas des langages impératifs En dépit de leur stabilité, les langages impératifs nécessitent d être vérifiés avant leur implantation. Malheureusement, ces langages se focalisent davantage sur le niveau descriptif du métier, notamment des aspects fonctionnels d un système d information, sans offrir des mécanismes de support à la vérification des spécifications. En effet, les erreurs de spécifications peuvent conduire à des défaillances des systèmes et peuvent avoir des conséquences dramatiques sur le plan économique. Dans le but d'aider le concepteur à trouver les erreurs dans les spécifications lors de la conception, nous souhaitons développer un environnement pour la spécification, la vérification et l implantation de processus métiers. Pour cela nous pouvons nous appuyer sur des méthodes formelles en intégrant une étape de vérification formelle dans les démarches de conception des systèmes. Comme nous l avons vu dans le chapitre 3, il existe de nombreuses méthodes formelles parmi lesquelles les méthodes dérivées de la logique classique pour exprimer des systèmes transformationnels, les logiques temporelles pour exprimer des propriétés dynamiques de sûreté et de vivacité des systèmes réactifs, les méthodes ensemblistes comme Z, VDM et B pour décrire et vérifier des propriétés statiques sur les états des systèmes, les méthodes basées sur 70

84 Etat de l art / Techniques de vérification de processus métier les graphes comme les réseaux de Pétri qui modélisent les systèmes concurrents, les automates temporisés qui modélisent les systèmes temps réels. D une façon générale, le comportement d un processus métier est modélisé formellement suivant les propriétés à vérifier. Ensuite, un outil de vérification contrôlera, par un algorithme de vérification, si ces propriétés sont vérifiées ou non. Le réseau de Pétri (RdP) est le modèle le plus utilisé [Mar03, Hin05, Ouy05 b, Pu05, Yan05] et cela parce qu il combine les avantages de la représentation graphique avec l aspect sémantique attribué au comportement du processus modélisé. Notons que, l algèbre de processus s est également imposée dans la vérification des processus. Il s agit d un langage basé sur un formalisme mathématique dédié à la description des systèmes concurrents. Ce modèle se base principalement sur les théories de la concurrence et les techniques des algèbres universelles. Les algèbres les plus connus sont : CCS [Mil80] (Calculus of Communicating Systems) première algèbre proposé, π-calculus [Mil99] qui fournit une théorie solide pour la description des interactions entre plusieurs threads en concurrences et Lotos [Tur07] (Language Of Temporal Ordering Specification) qui se base sur CCS et qui permet une spécification des systèmes parallèles. Plusieurs auteurs ont utilisé ces algèbres afin de modéliser et vérifier les processus métiers. En effet, les auteurs de [Kos04] ont proposé un langage appelé BPE calcul qui est basé sur les éléments de BPEL et qui est formalisé en utilisant l algèbre CCS. Un outil de vérification et ensuite implémenté pour vérifier un processus BPE calcul. Dans le travail [Sal04] un outil de traduction de BPEL en une algèbre Lotos est proposé, cet outil, appelé CADP (CÆSAR/ALDÉBARAN Development Package), permet aussi la vérification du processus BPEL. Par contre le [Smi02] propose une plateforme de modélisation graphique d un processus métier et la vérification de ce processus est basée sur π-calculus. Ceci étant, d autres approches, se basant sur des modèles différents, ont été proposées. Un exemple de cela est le travail [Pu05] qui propose µ-bpel, un nouveau langage basé sur BPEL et qui définit la sémantique des activités de base et structurée. µ- BPEL est traduit en TA (Timed Automata) et vérifier en utilisant l outil UPPAAL [Beh04] qui permet la vérification des propriétés du réseau de TA. Un autre exemple, est la plateforme VERBUS [Fis04]. C est une plateforme modulaire extensible qui n est pas liée à un outil de vérification ou à un langage de description de processus spécifique. En effet, un modèle formel commun (CMF) est défini et chaque langage de spécification de processus peut être intégré en définissant sa sémantique en termes de CMF, et en implémentant un traducteur associé. Chaque outil de vérification peut être intégré en implémentant un traducteur du CMF en langage d'entrée de 71

85 Etat de l art / Techniques de vérification de processus métier l'outil de vérification. Notons que le papier [Van06] recense les différents travaux proposés pour la vérification des processus BPEL La vérification dans le cas des langages déclaratifs La vérification des processus métier est une question primordiale pour une entreprise car elle permet de montrer que les activités du processus s exécutent en conformité à son plan de réalisation et qu elles n ont pas introduit des erreurs dans le résultat. Dans la littérature, plusieurs travaux ont été menés pour proposer des méthodes de vérification de processus modélisés à l aide d un langage déclaratif. Un exemple est celui de, l utilisation des guides de style de modélisation, dans [Gru07], pour vérifier le langage EPC (Event-driven Process Chains). Ou encore l utilisation du graphe de transition orienté TDG (Transition-Directed Graph), dans le travail de Hwang et al. dans [Hwa06], pour vérifier l ensemble de règles métier d un processus. Pour cela, Hwang et al. ont développé différents algorithmes pour détecter les différents patrons d erreurs possibles dans le graphe TDG, comme : l incohérence, la contradiction, les boucle infinies, la redondance, la subsumption et l incomplétude. Dans ce travail, des algorithmes de correction sont également élaborés pour essayer de corriger les erreurs détectées dans une représentation du processus. Un autre exemple des méthodes de vérification des langages déclaratifs, est l utilisation de la technique test-driven, dans le travail de Paschke et al. dans [Pas06] pour proposer un système d autovérification d un ensemble de règles. En effet, dans ce système, un modèle conceptuel est défini pour permettre la couverture d un large éventail de logiques adéquates pour la représentation des règles. Une méthodologie de validation de règles basée sur le test-driven est développée pour permettre la validation des règles en considérant les tests case comme des contraintes sur l ensemble des modèles possibles. Les nouveaux réseaux de Pétri (RdP) ont été également définis pour vérifier les langages déclaratifs basés sur les règles réactives (ECA) En effet, dans les RdP classiques, lorsque toutes les conditions nécessaires sont satisfaites, la transition peut être tirée mais pas nécessairement. Tandis que dans un système réactif, une transition doit être obligatoirement tirée. Pour cela, Eshuis et al. proposent, dans [Esh03], un RdP réactif qui change la façon dont la transition devrait être tirée en exigeant que la transition est tirée si les conditions sont satisfaites. A leur tour, Li et al. proposent dans [Li04] un nouveau réseau de Pétri coloré, appelé Conditional Colored Petri Net (CCPN) de modéliser les règles ECA dans les systèmes de base de données active. L'originalité de ce réseau de Pétri est la définition 72

86 Etat de l art / Techniques de vérification de processus métier de nouveaux types de places et de nouveaux types de transitions pour permettre la spécification des événements complexes. Malgré les méthodes proposées pour analyser un modèle déclaratif, le processus de vérification est complexe, car il exige d avoir un scénario d exécution, dans la phase de modélisation, pour tester le bon fonctionnement du processus avant de l implémenter. Malheureusement, les langages déclaratifs ne décrivent pas explicitement le scénario d exécution d un processus. En plus, la construction d un scénario d exécution à partir d un modèle implicite n est pas toujours évident [Zur07]. 3.1 Conclusion Dans ce chapitre, nous avons vu que la vérification des processus métier à pour but de montrer que les activités du processus s exécutent en conformité à son plan de réalisation et qu elles n ont pas introduit des erreurs. Pour cela plusieurs techniques sont proposées. Généralement la technique de vérification par réseaux de Pétri est la plus utilisée est cela est dû a leur représentation graphique avec l aspect sémantique attribué au comportement du processus modélisé. Dans ce travail, nous visons à proposer un modèle de description de processus basé sur les règles de réaction (ECA) et cela pour offrir une flexibilité de modélisation. Cependant, la vérification du processus modélisé par les règles ECA est plus complexe, car elle doit être obtenue en construisant un scénario d exécution à partir d un modèle implicite ce qui n est pas toujours évident. Pour cela, force est de constater qu un nouveau formalisme de règles doit être défini pour permettre de s adapter aux changements fréquents dans les réglementations de politiques des entreprises et permettre aussi de déduire automatiquement un graphe d exécution. Cela offrira aux concepteurs une vue fonctionnelle du processus utile pour analyser le processus. Puisque, le formalisme ECA nous semble intéressant, nous allons, dans la deuxième partie de cette thèse, proposer une extension de ce formalisme pour modéliser un processus métier. Ce formalisme permet d offrir une flexibilité à la modalisation et une fiabilité à l exécution du processus. 73

87 Partie 2 Notre contribution

88 Contribution / Introduction INTRODUCTION Dans cette première partie, nous avons vu que la gestion des processus métier (BPM) est une discipline qui consiste à gérer ces processus dans leurs dimensions spatiale (c.à.d. gérer le processus de bout en bout, depuis la chaîne d approvisionnement jusqu à toutes les activités interne et externes d une entreprise), et aussi dans leurs dimensions temporelles (c.à.d. englober la totalité du cycle de vie des processus depuis la modélisation jusqu à l exécution et le diagnostic). D une manière générale, les objectifs annoncés du BPM se résument en trois points : (1) optimiser la chaîne de valeur de l entreprise en permettant de définir, superviser et améliorer les processus métier. (2) capitaliser sur deux actifs-clés de toute entreprise : l organisation (le personnel, son savoir faire) et son système d information. (3) offrir une agilité en gérant les changements d un processus. Les deux premiers objectifs sont assurés par la proposition d un ensemble de travaux (voir chapitre 2,3 et 4). Cependant, le troisième objectif pose toujours problème. En effet, la nature dynamique des environnements des organisations rend les éléments de processus susceptibles d être modifiés ou supprimés. L origine de cette dynamicité vient essentiellement du changement fréquent dans les réglementations extérieures que doit respecter l entreprise et aussi le changement de politiques intérieures définies par l entreprise. Ces réglementations et politiques métier sont souvent exprimées sous forme de règles appelées règles métier (ou règles de gestion). Le groupe BRG (Business Rules Group) définit ces règles métier comme des définitions de haut niveau structurées, qui permettent de contraindre, contrôler et influencer un aspect du métier. Elles implémentent la stratégie ou les politiques d une entreprise et elles permettent d'influencer les prises des décisions et de contrôler les comportements métiers. Malheureusement, en utilisant les langages impératifs tels que BPEL [OASIS07] et le XPDL [WfMC08], ces règles métier sont mélangées avec le code de la logique du processus. Par conséquent, l implémentation du changement est difficile à faire. En effet, ces langages obligent les concepteurs à définir explicitement les décisions à prendre (quelle branche du processus on doit choisir) sous forme de connecteurs tels que : Le connecteur du choix exclusif qui représente le choix d une seule branche (ou une décision à prendre) parmi plusieurs pour permettre à une activité d être exécutée en fonction d une contrainte. De cette manière, ces langages permettent d utiliser les résultats des décisions (ou les règles métier) pour déterminer le comportement à suivre plutôt que modéliser ces règles (ou décisions). 75

89 Contribution / Introduction Afin de répondre à ce problème, l utilisation d une approche basée sur les règles pour modéliser la logique du processus nous semble la plus pertinente. En effet, cette approche permet : - Le déploiement d un processus spécifié partiellement c.à.d. la possibilité d exécuter un processus partiellement défini (ou dont certains sous processus ne sont pas connus dans la phase d exécution). Cela est assuré par les moteurs de règles. - La modification de la définition du processus sans impacter l instance de processus c.à.d. la modification permanente d instance en ajoutant ou supprimant des règles par exemple. En résumé, cette approche offre une meilleure flexibilité de modélisation de processus. En effet, la flexibilité se définit comme la capacité de mettre en œuvre les changements dans un processus métier en modifiant seulement les parties qui ont besoin d'être changées tout en gardant la stabilité des autres parties du processus (donc la flexibilité par spécification partielle, et par changement). Cependant, nous devons répondre à la question suivante : quel formalisme de règle est le mieux adapté pour modéliser d une manière déclarative, un processus métier? Parmi les formalismes de règles existants dans la littérature (voir figure 6.0), nous avons opté pour l utilisation des règles ECA car elles offrent une manière flexible pour spécifier les flux de contrôle en utilisant les événements. En plus ce formalisme est facile à maintenir et permet de couvrir tous les autres types de règles métier. Cependant, le formalisme ECA ne supporte pas le contrôle d exécution de la partie action de la règle. En plus, il ne reflète pas explicitement l'ordre des activités et ne permet pas d avoir une vue fonctionnelle utile pour l analyse du processus. L objectif de notre travail est alors, de permettre, d une part, une modélisation souple qui prend en compte la dynamicité des différents éléments de processus métier. D autre part, on doit permettre de vérifier le déroulement du processus exécutable pour s assurer de son bon fonctionnement. Pour cette raison, nous allons proposer, dans la deuxième partie de cette thèse (chapitre6), un modèle de définition des processus métier basé sur les règles métier. 76

90 Contribution / Introduction Figure 6.0 le positionnement de notre contribution par rapport aux travaux existants Dans ce modèle, un processus métier est constitué d un ensemble de règles qui utilisent une nouvelle extension du formalisme ECA, cette extension appelée ECAPE (Evènement Condition Action Post condition post Evénements [Compensation ou Evénement d erreurs] (ECAPE-CE abrégé ECAPE). Le plus grand avantage du formalisme ECAPE est de permettre une description explicite des événements qui seront provoqués par l exécution de l action de la règle pour construire un graphe d exécution du processus (une vue fonctionnelle du processus). En plus cette extension permet de contrôler l exécution de chaque action d une règle et de lancer des mécanismes de compensation si l exécution n est pas valide. Pour cette raison, le modèle proposé, qui se base sur les règles utilisent ce formalisme, est appelé ECAPE- M. Dans le but de véhiculer le nouveau modèle proposé (ECAPE-M), nous allons proposer, dans le chapitre 6 un nouveau langage déclaratif de description de processus métier appelé ECAPE-L. Ce nouveau langage se base sur les règles métier et permet, en plus de garantir une flexibilité de la modélisation, d augmenter l expressivité en héritant de la syntaxe des langages impératifs les plus utilisés dans l industrie (BPEL, XPDL). Le principal avantage de ce langage modélisation est d offrir une flexibilité en permettant la gestion du changement qui sera détaillée dans le chapitre 7, et de permettre de modéliser la sémantique d exécution du modèle ECAPE-M et la vérification formelle du processus en utilisant un nouveau réseau de Pétri appelé ECAPE net. Ce dernier sera présenté dans le chapitre 8. 77

91 Contribution / Modèle ECAPE-M 6 Modèle ECAPE-M 6.1 Introduction 6.2 Formalisme ECAPE 6.3 Modèle ECAPE-M 6.4 Exemple illustratif 6.5 Expressivité du modèle ECAPE-M La séquence d activité La branche parallèle La synchronisation Le choix exclusif La jonction simple La boucle structurée 6.6 Différents plans du modèle ECAPE-M Le plan métier Le plan comportemental Le plan opérationnel 6.7 Conclusion 6.1 Introduction Le formalisme E-C-A utilisé dans les systèmes de base de données active dans les années 1990, a été adopté par de nombreux langages de modélisation du processus métier basés sur les règles. Cela se justifie par le fait que ce formalisme permet d intégrer tous les types de règles métier (contrainte, dérivation, production, et transformation). En plus, en utilisant le formalisme ECA, la définition du processus peut être changée sans impacter les instances en cours d exécution car le moteur de règles ECA détermine, dans la phase d exécution, ce qui doit être exécuté en évaluant les conditions de déclenchement des règles. Ce qui offre une flexibilité de la modélisation du processus. Cependant, la vérification du processus exige d avoir un scénario d exécution pour tester son bon fonctionnement. Malheureusement, le formalise ECA décrit un scénario d exécution d une manière implicite. Pour analyser le fonctionnement du processus, on doit construire un scénario d exécution à partir d un modèle implicite ce qui n est pas toujours évident. En plus, le formalisme ECA classique ne prévoit pas de valider l exécution de l action pour assurer que le résultat de l exécution correspond à ce que l on attend. Ce formalisme ne prévoit pas, non plus, de lancer un méca- 78

92 Contribution / Modèle ECAPE-M nisme de compensation des exceptions opérationnelles pour annuler l effet d exécution erronée de l action. Pour cela, nous proposons d étendre le formalisme ECA, initialement défini par Evénement Condition Action, par une Post Condition pour contrôler l exécution de l action d une règle et Post Evénements pour décrire les événements déclenchés par l exécution de la partie action d une règle. Dans cette section, nous allons présenter la nouvelle extension, appelée ECAPE, en expliquant comment un processus métier peut être décrit par cette extension. 6.2 Le formalisme ECAPE Dans cette section nous présentons un nouveau formalisme appelé ECAPE pour : Evènement Condition Action Post condition post Evénements [Compensation ou Evénement d erreurs] (ECAPE-CE abrégé ECAPE). Le plus grand avantage de ce formalisme est qu il permet, d un côté, de valider l exécution de l action et lancer une compensation pour remplacer le traitement de l action. D un autre côté il permet de construire automatiquement un graphe d exécution du processus utile pour analyser sont bon fonctionnement. Une règle ECAPE se définit par : L événement détermine quand une règle doit être évaluée. La condition est un prédicat dont dépend l exécution de l action. L action, quant à elle, spécifie le code à exécuter si la condition est à vrai. La post condition est un prédicat dont la validation dépend de la règle. Le post événements est l ensemble d événements déclenchés pendant ou après l exécution de la partie action de la règle. La compensation est l action qui peut être exécutée, comme première alternative, dans le cas ou la partie post condition est non satisfaite. Finalement les événements d erreurs sont l ensemble 79

93 Contribution / Modèle ECAPE-M d événements qui peuvent se déclencher comme seconde alternative, si la post condition n est pas vérifiée. La sémantique attachée à une règle ECAPE est la suivante : lorsqu un événement se produit, la partie condition est vérifiée, si cette partie est satisfaite, alors la partie action est exécutée en tenant compte des attributs associés à la règle. Cette exécution est validée si la post condition est satisfaite. Dans ce cas, les post événements sont déclenchés. Dans le cas contraire (post condition non satisfaite), deux alternatives peuvent être envisagées : (1) un mécanisme de compensation est lancé dans le but de remplacer, si possible, l effet de l action de la règle ; (2) des événements d erreurs sont déclenchés pour indiquer une situation anormale. L originalité de ce modèle est : (1) de permettre la description esplicite des événements qui seront provoqués par l exécution de l action de la règle pour construire un graphe d exécution du processus (une vue fonctionnelle du processus). (2) de permettre la description d une action de compensation si l exécution n est pas valide. (3) de permettre de signaler des exceptions opérationnelles à l aide des événements d erreurs. 6.3 Modèle ECAPE-M L objectif d une approche de modélisation de processus basée sur les règles est de définir, d une manière déclarative, le besoin métier de haut niveau indépendamment de l implémentation du processus et cela en utilisant les règles métier. L enchaînement des ces règles définira le comportement du processus. En effet, l enchaînement des règles représente le flux de contrôle des éléments à exécuter dans un processus, il formalise des décisions à prendre en déterminant l ordre d exécution des activités métier (quelle branche du processus on doit choisir) et cela en tenant compte du contexte du processus. La description de l enchaînement des règles, dans une modélisation de processus basée sur les règles, se fait d une manière implicite. En se basant sur le modèle ECAPE, la logique d un processus métier peut être décrite, d une manière déclarative, par un ensemble de règles ECAPE. En effet, lorsqu un événement se produit, un moteur évalue l ensemble des règles, pour exécuter les activités métier décrites dans la partie d une action en vérifiant certaines conditions. L exécution de l action d une règle peut provoquer un événement qui active une ou plusieurs règles. Ainsi chaque règle peut déclencher une ou plusieurs règles, ce déclenchement permet d exécuter les activités métier en suivant la logique du processus (voir la figure 6.1). 80

94 Contribution / Modèle ECAPE-M Figure 6.1 La modélisation d un processus en utilisant le modèle ECAPE-M 6.4 Exemple illustratif Pour illustrer le modèle ECAPE, nous allons détailler comment nous pouvons décrire le processus de traitement de commande que nous avons vu dans la partie état de l art, à laide du modèle ECAPE-M. Rappelons que ce processus se déclenche lors d une réception d une commande d'un client. En suite, le calcul du prix initial de la commande (prix sans livraison) et le calcul du prix de livraison se lancent en parallèle. La après de ces deux calculs, le prix total est calculé et la facture est envoyée au client. Finalement lorsque le paiement est reçu, le produit est livré et la facture est enregistrée. Deux règles métier sont définies, la première concerne le client qui doit s enregistrer dans la base de données pour pouvoir lancer une commande ; la deuxième règle concerne le règlement de la facture qui doit se faire avant 15 jours de la date de livraison. 81

95 Contribution / Modèle ECAPE-M Figure 6.2 La modélisation ECAPE-M du processus de traitement de commande La figure 6.2 représente le processus du traitement de commande sous forme de règles ECAPE. Par exemple, la règle r 1 exprime la vérification de l enregistrement : lors de la réception d une commande (l événement d activation), si les informations de la commande sont valides 82

96 Contribution / Modèle ECAPE-M (la condition), cette règle vérifie que le client est enregistré dans la base clients de l entreprise (action). L'exécution de cette action est validée si la connexion de base de données est correcte (post-condition est vraie). Dans ce cas, l événement «le client est vérifié» sera déclenché. Ce dernier va activer trois règles à savoir r 2 (calcul du prix initial), r 3 (sélection du livreur), et r 4 (Rejeter la commande quand le client n est pas enregistré). La réalisation des actions de ces règles va provoquer des événements qui vont, à leur tour, activer d'autres règles du processus, et ainsi de suite jusqu'à ce que toutes les règles soient exécutées. Grâce à la description explicite des événements déclenchés après l'exécution de l'action d'une règle (post événements), il est possible de déduire la séquence de règles (un graphe d exécution), qui permet de vérifier le bon fonctionnement du processus. Cela est indiqué par la flèche dans la figure 6.2. La fiabilité des processus est une question primordiale pour une entreprise, donc chaque règle ECAPE prévoit de contrôler, par la post condition, la validation de l exécution de l action et soit lancer une action de compensation soit déclencher des événements d erreurs dans le cas où la post condition n est pas satisfaite. Par exemple, si l exécution de l action de la règle r 3 est erronée (le calcul du prix de la livraison n est pas correct), une action de compensation (trouver un autre livreur) est lancée dans le but remplacer l exécution de l action de cette règle. Un deuxième exemple de contrôle de l exécution de la règle ECAPE, si l exécution de l action de la règle r 1 est erronée (la connexion de base de données n est pas correcte), des événements d erreurs opérationnelles seront déclenchés (échec de la connexion à la base de données et la commande est annulée). Ces événements peuvent à leur tour déclencher un sous ensemble de règles. Grâce à la description explicite des événements d erreurs (errors events), il est possible de déduire la séquence de déclenchement de règles. En plus cela permet la gestion des exceptions en utilisant des règles ECAPE. 6.5 L expressivité du flux de contrôle A travers l exemple précédent, nous avons vu que le modèle ECAPE permet de modéliser, d une manière déclarative, un processus métier en décrivant implicitement les relations logiques qui contrôlent le cheminement et l ordre d exécution des activités. Dans la section suivante, nous allons détailler comment le modèle ECAPE répond les flux de contrôle de base (vu dans le chapitre 3 section 3.2.2) : 83

97 Contribution / Modèle ECAPE-M La séquence de règles (b) (a) (b) Figure 6.3 la modélisation de séquence de règles par le modèle ECAPE-M Pour modéliser une séquence de règles par le modèle ECAPE-M nous devons spécifier une séquence de déclenchement de règles en définissant un post-événement de la règle prédécesseur qui active la règle successeur. La figure 6.3.a illustre une séquence de règles où le post-événement e 2 de la règle r 1 permet d activer la règle r 2. La séquence de règles peut aussi être spécifiée en définissant un événement d erreur de la règle prédécesseur qui active la règle successeur. La figure 6.3.b, illustre un tel exemple où l événement d erreur e 2 de la règle r 1 permet d activer la règle r Le parallélisme de règles (a) (b) Figure 6.4 la modélisation du parallélisme de règles par le modèle ECAPE-M 84

98 Contribution / Modèle ECAPE-M Pour modéliser un parallélisme de règles par le modèle ECAPE-M nous devons spécifier un déclenchement simultané de deux règles en définissant un post-événement d une règle qui permet d activer deux règles en parallèle. La figure 6.4.a illustre le parallélisme de règles où le post-événement e 2 de la règle r 1 permet d activer les règles r 2 et r 3 simultanément. Le parallélisme d action peut aussi être spécifié en définissant un événement d erreur d une règle qui active plusieurs règles en même temps La synchronisation de règles Pour modéliser une synchronisation de règles par le modèle ECAPE-M nous devons spécifier une règle de convergence (règle de RDV) qui s active par une conjonction des post-événements des règles prédécesseurs. La figure 6.5.a illustre une synchronisation de règles où la règles r 2 se déclenche par une conjonction de post-événements e 2 et e 3 des règles r 1 et r 1 respectivement. La synchronisation d action peut être aussi spécifiée en définissant une conjonction des événements d erreur des règles prédécesseurs. Un exemple de cela est illustré dans figure 6.5.b où la règles r 2 se déclenche par une conjonction d événements d erreur e 2 et e 3 des règles r 1 et r 1 respectivement. (a) (b) Figure 6.5 la modélisation de la synchronisation de règles par le modèle ECAPE-M 85

99 Contribution / Modèle ECAPE-M Le choix exclusif de règles (a) (b) Figure 6.6 la modélisation du choix exclusif de règles par le modèle ECAPE-M Pour modéliser un choix exclusif de règles par le modèle ECAPE-M nous devons spécifier deux règles qui ont le même événement d activation avec deux conditions contradictoires. Lors de l activation de ces deux règles, une seule va déclencher un post-événement (ou événement d erreurs) qui active une autre règle. La figure 6.6.a et la figure 6.6.b illustrent un choix exclusif de règles où l événement e 1 permet d activer deux règles r 1 et r 1 qui ont deux conditions contradictoires (c 1 et c 1 respectivement). Une de ces deux règles va déclencher un post-événement (ou un événement d erreur) qui permet d activer une des deux règles r 2 ou r La jonction simple de règles (a) (b) Figure 6.7 la modélisation la jonction simple de règles par le modèle ECAPE-M 86

100 Contribution / Modèle ECAPE-M Pour modéliser une jonction simple de règles par le modèle ECAPE-M nous devons spécifier une règle de convergence qui s active par une disjonction de post-événements d un ensemble de règles. La figure 6.7.a et la figure 6.7.b illustrent une jonction simple de règles où la règle r 2 s active si au moins un des deux post événements (ou événements d erreur) e 2 ou e 3 est détecté La boucle de règles Pour modéliser une boucle de règles par le modèle ECAPE-M nous devons spécifier un ensemble de règles s auto-déclenchant de façon à former une boucle structurée. Deux conditions contradictoires peuvent être spécifiées pour sortir de la boucle. La figure 6.8 illustre une boucle structurée de règles où l ensemble de règles {r 1, r 2, r 3 } forme une boucle. Pour sortir de cette boucle, la condition c 1 de la règle r 1 doit être non satisfaite. Ce qui conduit au déclenchement de r 4. Figure 6.8 la modélisation de la boucle structurée de règles par le modèle ECAPE-M 6.6 Les différents plans du modèle ECAPE-M Dans cette thèse, nous nous préoccupons de la modélisation des processus métier. L objectif étant, de permettre, d une part, de l expressivité et la dynamicité des différents éléments de processus métier. 87

101 Contribution / Modèle ECAPE-M Et d autre part, de la vérification du bon fonctionnement d un processus. Pour cette raison, nous suggérons de voir le modèle ECAPE-M selon trois plans d abstraction (voir figure 6.9): Figure 6.9 Les différents plans du modèle ECAPE-M Le plan métier Dans ce plan, les processus métier sont définis par un ensemble de règles ECAPE. Ces règles sont des énoncés exprimant, de manière déclarative, le domaine métier, les politiques d une entreprise, les règles métier,... etc. Pour cela, nous devons utiliser un langage puissant qui permet de représenter la sémantique du modèle ECAPE ainsi que les différents éléments d'un processus. Pour cette raison, nous proposons un nouveau langage, appelé ECAPE-L, qui utilise une syntaxe basée sur XML, héritée des langages les plus utilisés dans l'industrie (BPEL, XPDL), pour décrire, les éléments des processus métier (voir chapitre 7) Le plan comportemental La définition du processus, sur le plan métier, peut conduire à un graphe de règles qui permet d'analyser le comportement de règles métier pour assurer la flexibilité du processus métier. Ce graphe modélise la séquence d exécution des règles ainsi que les relations qui existent entre les règles. En effet, la nécessité de prendre en compte la dynamicité des différents éléments d un processus, nous pousse à mettre l accent sur la relation entre les règles pour assurer une gestion automatique du changement. De cette façon, nous pouvons déterminer l'ensemble de règles qui doivent être changées après le changement d'une règle dans un processus afin d en estimer le coût. Pour cette raison, nous avons déterminé deux classes de relations entre les règles : relations de déclenchement et relations de partage de variables (voir chapitre 8). 88

102 Contribution / Modèle ECAPE-M Le plan opérationnel La définition du processus, sur le plan métier, peut aussi conduire à un réseau de Pétri appelé ECAPE net afin de modéliser la sémantique d exécution du modèle ECAPE-M et pouvoir vérifier formellement le bon fonctionnement du processus. En effet, pour aider le concepteur à trouver les erreurs fonctionnelles dans un processus ECAPE, nous avons opté pour les réseaux de Pétri (RdP) en raison de leur grande capacité à simuler et analyser l exécution des processus métier (voir chapitre 9). 6.6 Conclusion Nous avons présenté dans ce chapitre le modèle ECAPE qui permet de décrire un processus métier, d une manière déclarative, en utilisant un ensemble de règles ECAPE. Ce modèle étend le formalisme ECA, initialement défini par Evénement Condition Action, par une Post Condition pour contrôler l exécution de l action d une règle et lancer une action de compensation dans le cas ou l exécution n est pas valide et Post Evénements pour décrire explicitement les événements qui seront provoqués par l exécution de l action de la règle pour construire un graphe d exécution du processus (une vue fonctionnelle du processus). Nous avons vu que ce modèle permet de couvrir tous les flux de contrôle de base et permet aussi de voir le processus selon trois plans d abstraction : un plan métier pour décrire le processus à l aide d un nouveau langage appelé ECAPE-L un plan de comportement pour gérer automatiquement le changement du processus et un plan opérationnel pour simuler et vérifier la bonne exécution du processus a l aide d un réseau de Pétri. Dans le reste de cette partie de thèse, nous allons décrire le nouveau langage RbBPDL qui est utilisé pour définir un processus métier en utilisant le modèle ECAPE. Nous allons présenter l approche de la gestion de changement du processus et l estimation du coût de changement d une règle. Finalement, nous allons détailler le réseau de Pétri ECAPE Net qui est utilisé pour vérifier le processus opérationnel. 89

103 Contribution / Le langage ECAPE-L 7 Le langage ECAPE-L 7.1 Introduction 7.2 Les éléments du langage ECAPE-L Le processus Les participants Les variables Les activités métier Les événements Les règles ECAPE L instruction EXECUTE L instruction DISCOVER L instruction CANCEL L instruction SKIP L instruction COPY 7.3 Un exemple illustratif 7.4 L expressivité du langage ECAPE-L 7.5 La représentation graphique du langage ECAPE-L 7.6 Conclusion 7.1 Introduction La modélisation du processus basée sur les règles a l avantage d offrir une flexibilité du processus car elle permet la modélisation tardive pour spécifier des fragments à la volée durant l exécution du processus, en plus elle offre la possibilité de modifier la définition du processus dans la phase d exécution en permettant à toutes les instances du processus existantes de migrer vers la nouvelle définition du processus. Pour cela, il nous faut un langage de règles puissant afin de représenter, d une manière déclarative, les différents éléments du processus. Il existe de nombreux langages basés sur les règles qui utilisent différents paradigmes de règles et plusieurs syntaxes tels que BPTrigger [Chu04], EM-BrA²CE [Geo07] et SBVR [OMG08]. Cependant, ces langages se focalisent sur les concepts de règles sans offrir de modèles pour permettre de définir les éléments d un processus, comme les activités métier, les participants etc. En effet, les langages de règles existants sont soit très génériques soit définis pour un domaine spécifique et dans les deux cas ces langages ne suffisent pas pour définir un processus métier car ils ne 90

104 Contribution / Le langage ECAPE-L représentent pas tous les aspects du processus. Pour cela, nous allons proposer dans ce chapitre un nouveau langage déclaratif basé sur une syntaxe XML appelé ECAPE-L qui permet de définir un processus et cela en utilisant le modèle ECAPE-M. L enchaînement des règles de ce modèle constituera la logique du processus métier. Notons que nous avons baptisé ce langage RbBPRL (Rules based Business Process Definition Language) dans [Bou09 a, Bou09 b, Bou09 c]. L objectif du ECAPE-L est d offrir une expressivité et une facilité d utilisation pour définir les processus métier et cela en héritant des concepts et de la syntaxe des langages impératifs les plus utilisés dans l industrie (BPEL, XPDL) et de permettre une construction automatique des scénarios d exécution à partir de la définition de l ensemble de règles ECAPE. Pour cette raison, ce langage est considéré comme un langage de description et d exécution de processus métier. 7.2 Les éléments du langage ECAPE-L Nous avons proposé dans le chapitre précédant un modèle basé sur les règles ECAPE (appelé ECAPE-M) qui permet de définir un processus d une manière déclarative. Ces règles permettent de décrire explicitement les événements qui sont issus de l exécution de l action d une règle pour déduire automatiquement le graphe d exécution du processus et contrôler l exécution de l action d une règle puis lancer une action de compensation dans le cas ou l exécution n est pas valide. Pour représenter la sémantique du modèle ECAPE-M ainsi que les différents éléments d'un processus nous avons besoin d un langage de règles expressif et puissant. Nous proposons un nouveau langage, appelé ECAPE-L, qui utilise une syntaxe XML, héritée des deux langages les plus utilisées dans l'industrie : BPEL, XPDL et cela afin de décrire, les éléments d un processus métier. En effet, XPDL appartient à la famille des langages de Workflow destinés à modéliser, dans une entreprise, les flux d informations échangés entre les différents acteurs et les activités à accomplir par ces différents acteurs. Le BPEL4WS appartient à la famille de langages destinés à manipuler les services web mis en œuvre au sein d un processus. Ce dernier sera modélisé, dans ce cas, par une composition de services web, où il n utilise que des services comme ressources pour l exécution de ces activités. Ces processus métier peuvent être vus comme un service web dit complexes. 91

105 Contribution / Le langage ECAPE-L En regroupant les deux visions apportées par ces deux familles de langages, le langage ECAPE-L permet d intégrer les éléments clés d un processus métier. Figure 7.1 Le méta-modèle du langage ECAPE-L La figure 7.1 représente le méta-modèle du langage qui prend en compte les cinq dimensions du processus : - La dimension organisationnelle est prise en compte en décrivant les participants qui ont la responsabilité d exécution les éléments d un processus. - La dimension informationnelle est prise en compte en décrivant les variables qui sont produites ou manipulées par un processus métier et en décrivant les événements qui sont utilisés pour déclencher les règles ECAPE - La dimension fonctionnelle est prise en compte en décrivant les activités qui doivent être exécutées dans un processus métier - La dimension comportementale est prise en compte en décrivant les règles ECAPE qui modélisent la logique du processus. - La dimension opérationnelle est prise en compte en décrivant les informations techniques utilisées lors de l exécution du processus comme : les protocoles du transport et les formats de messages utilisés. Dans ce qui suit, nous allons présenter avec plus de détails le métamodèle du ECAPE-L en présentant les parties principales du schéma XML de chaque élément. Notons que le schéma XML complet du ce langage est présenté dans l annexe Le processus Dans le langage ECAPE-L, un processus se résume en un ensemble de règles, chacune est associée à des activités, à des participants, à des conditions et à des événements. Pour cela, ce langage propose de déclarer d abord les éléments qui 92

106 Contribution / Le langage ECAPE-L constituent les règles ECAPE, et d utiliser ces déclarations pour définir l ensemble de règles (voir la figure 7.2). Figure 7.2 Un processus métier décrit par le ECAPE-L La figure 7.2 illustre la structure globale du ECAPE-L : La partie «Participants» permet de représenter les participants qui ont le rôle d exécuter les activités du processus. La partie «Variables» permet de représenter les variables utilisées par les activités et qui seront utilisées. Ces variables servent aussi à déterminer les types de messages échangés au sein du processus. La partie «BusinessActivities» permet de représenter les activités automatiques et manuelles du processus qui seront utilisées pour spécifier les actions et les actions de compensation de chaque règle. La partie «Events» permet de représenter les événements atomiques et composés qui seront utilisés pour spécifier les événements de déclenchement, les post-événements et les événements d erreur de chaque règle. La partie «BusinessRules» est le cœur du langage ECAPE-L. Cette partie permet de représenter l ensemble de règles ECAPE qui modélise un processus. Le schéma XML de la structure global du ECAPE-L est comme suit : 93

107 Contribution / Le langage ECAPE-L <xsd:element name="process" type="tprocess"/> <xsd:annotation> <xsd:documentation> This is the root element for an ECAPE-L process. </xsd:documentation> </xsd:annotation> <xsd:complextype name="tprocess"> <xsd:sequence> <xsd:element ref="participants"/> <xsd:element ref="variables"/> <xsd:element ref="businessactivities"/> <xsd:element ref="events"/> <xsd:element ref="businessrules"/> </xsd:sequence> <xsd:attribute name="name" type="xsd:ncname" use="required"/> <xsd:attribute name="namespace" type="xsd:anyuri" use="required"/> <xsd:attribute name="expressionlanguage" type="xsd:anyuri" default="urn:liris:names:tc:sublang:xpath1.0"/> </xsd:complextype> Les éléments et les attributs de la balise «Process» Participants Variables BusinessActivities Events BusinessRules Name Namespace expressionlanguage Signification Les participants utilisés pour exécuter les activités Les variables manipulées dans le processus Les activités métier utilisées dans les actions de la règle Les événements utilisés pour déclencher les règles L ensemble de règles EACAPE Le mon du processus Un nom symbolique qui permet de désigner l ensemble des variables et des fonctions dans la définition du processus Le langage utilisé pour spécifier les expressions du processus (par défaut le xpath1.0 est utilisé) Participants Dans le langage ECAPE-L, un participant est toute entité qui a pour rôle l exécution d une activité. Il représente une ressource qui a la responsabilité d exécuter les éléments d un processus et qui participe à la réalisation de l objectif global du processus. Le schéma XML de la partie participants de ECAPE-L est comme suit : <xsd:element name="participants" type="tparticipants"> <xsd:annotation> <xsd:documentation> This is the participants of ECAPE-L process. </xsd:documentation> 94

108 Contribution / Le langage ECAPE-L </xsd:annotation> </xsd:element> <xsd:complextype name="tparticipants"> <xsd:sequence> <xsd:element ref="participant" maxoccurs="unbounded"/> </xsd:sequence> </xsd:complextype> <xsd:element name="participant" type="tparticipant"/> <xsd:complextype name="tparticipant"> <xsd:sequence> <xsd:element ref="participanttype"/> <xsd:element ref="description" minoccurs="0"/> </xsd:sequence> <xsd:attribute name="id" type="xsd:ncname" use="required"/> <xsd:attribute name="name" type="xsd:ncname" use="optional"/> </xsd:complextype> Les éléments et les attributs de la balise «Participant» ParticipantType Description Id Name Signification Le type du participant Les descriptions du concepteur qui décrivent le rôle du participant L identifiant du participant dans le processus Le nom du participant Dans le langage ECAPE-L, un participant peut être une personne physique ou une organisation pour exécuter les activités manuelles, et une application (application métier, service web, ) pour exécuter les activités automatiques. Notons que ces applications ou services web peuvent être spécifiés dans la phase de modélisation (on parle alors d un participant de type «SpecificApplication») ou peuvent être découverts automatiquement dans la phase d exécution (on parle alors d un participant de type «DiscoveredApplication»). Les différents types de participants sont définis comme suit : <xsd:element name="participanttype" type="tparticipanttype"/> <xsd:complextype name="tparticipanttype"> <xsd:choice> <xsd:element ref="human"/> <xsd:element ref="organiszationalunit"/> <xsd:element ref=" SpecificApplication "/> <xsd:element ref=" Discovered Application"/> </xsd:choice> </xsd:complextype> 95

109 Contribution / Le langage ECAPE-L Les éléments et les attributs de la balise «ParticipantType» Human OrganiszationalUnit SpecificApplication DiscoveredApplication Signification Une personne physique Un groupe de personnes, un département ou une organisation Une application qui peut être utilisée ou invoquée à distance (comme un service web). Pour cela on doit spécifier : l adresse ou l URL de l application, l opération utilisée, le protocole de communication, etc. Une application (ou un service web) qui doit être découverte automatiquement dans un registre donné (voir la partie ) Les variables Dans ECAPE-L, les variables sont les entités d information qui sont produites ou manipulées par un processus. Elles sont utilisées par les activités et les conditions des règles. Le schéma XML de la partie variables de ECAPE-L est le suivant : <xsd:element name="variables" type="tvariables"> <xsd:annotation> <xsd:documentation> These are variables of R2BPRL process. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:complextype name="tvariables"> <xsd:sequence> <xsd:element ref="variable" maxoccurs="unbounded"/> </xsd:sequence> </xsd:complextype> <xsd:element name="variable" type="tvariable"/> <xsd:complextype name="tvariable"> <xsd:sequence> <xsd:element ref="datatype"/> <xsd:element ref="initialvalue" minoccurs="0"/> <xsd:element ref="description" minoccurs="0"/> </xsd:sequence> <xsd:attribute name="id" type="xsd:id" use="required"/> <xsd:attribute name="name" type="xsd:ncname" use="optional"/> </xsd:complextype> 96

110 Contribution / Le langage ECAPE-L Les éléments et les attributs de la balise «Variable» DataType InitialValue Description Id Name Signification Le type de variable La valeur initiale de la variable Les descriptions du concepteur qui décrivent l utilisation de la variable L identifiant de la variable dans le processus Le mon de la variable Le langage ECAPE-L prend en compte plusieurs types de variables. En effet, les variables d un processus peuvent être de type simple (des chaînes de caractères, des entiers,..), complexes (des ensembles, tableaux), documents (des documents XML) ou un nouveau type déclaré. Les différents types sont définis comme suit : <xsd:element name="datatype" type="tdatatype"/> <xsd:complextype name="tdatatype"> <xsd:choice> <xsd:element ref="basictype"/> <xsd:element ref="declaredtype"/> <xsd:element ref="schematype"/> <xsd:element ref="externalreference"/> <xsd:element ref="recordtype"/> <xsd:element ref="uniontype"/> <xsd:element ref="enumerationtype"/> <xsd:element ref="arraytype"/> <xsd:element ref="listtype"/> </xsd:choice> </xsd:complextype> Les éléments et les attributs de la balise «DataType» BasicType DeclaredType SchemaType ExternalReference RecordType UnionType EnumerationType ArrayType ListType Signification Un type simple : STRING, FLOAT, INTEGER, DATETIME, DATE, TIME ou BOOLEAN Un nouveau type déclaré Un document XML Une référence vers une variable externe Un ensemble de d éléments qui peuvent être de différents types Un ensemble de membres parmi lesquels un seul sera utilisé dans une instance du processus L ensemble de valeurs autorisées pour une variable Un ensemble de données de même type Un ensemble infini d éléments de même type 97

111 Contribution / Le langage ECAPE-L Les activités Dans le langage ECAPE-L, une activité métier est la description d'une unité de travail qui s exécute dans la partie action ou une compensation d une règle ECAPE. En effet, une activité représente un ensemble de tâches qui s exécutent d une manière indivisible par un participant. Pour cela, l exécution d une activité peut exiger l intervention humaine ou une organisation, on parle alors d une activité manuelle, ou peut s effectuer grâce à une application (ou un service web), on parle alors d une activité automatisée. ECAPE-L propose aussi l exécution semi automatique d une activité qui exige une intervention humaine pour valider le résultat de l exécution d une application. Le langage ECAPE-L propose de séparer la définition d une activité métier de l entité responsable de son exécution (Service Web, une application ou un humain). De cette manière, les activités métier sont définies indépendamment de leur implémentation. Cela est utile pour définir des processus métier paramétrables (configurables business process). Ces derniers permettent de décrire des processus génériques qui peuvent être utilisés par plusieurs entreprises. Le schéma XML de la partie activités de ECAPE-L est le suivant : <xsd:element name="businessactivities" type="tbusinessactivities"> <xsd:annotation> <xsd:documentation> These are business activities of ECAPE-L process. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:complextype name="tbusinessactivities"> <xsd:sequence> <xsd:element ref="businessactivity" maxoccurs="unbounded"/> </xsd:sequence> </xsd:complextype> <xsd:element name="businessactivity" type="tbusinessactivity"/> <xsd:complextype name="tbusinessactivity"> <xsd:sequence> <xsd:element ref="formalparameters"/> <xsd:element ref="executiontype"/> <xsd:element ref="executionmode"/> <xsd:element ref="description" minoccurs="0"/> </xsd:sequence> <xsd:attribute name="id" type="xsd:id" use="required"/> 98

112 Contribution / Le langage ECAPE-L <xsd:attribute name="name" type="xsd:ncname" use="optional"/> <xsd:attribute name="priority" type="xsd:anysimpletype"/> </xsd:complextype> Les éléments et les attributs de la balise «BusinessActivity» FormalParameters ExecutionType ExecutionMode Description Id Name Signification Les paramètres d entrée/sortie de l activité Le type d exécution : manuelle, semi-automatique ou automatique. Le mode d exécution : synchrone ou asynchrone Les descriptions de l utilisation de l activité par le concepteur L identifiant de l activité dans le processus Le nom de l activité Les événements Un événement est défini comme un indicateur qui signale qu une situation particulière s est produite et pour laquelle une réaction est nécessaire. L événement est donc l élément activateur de la règle. Il spécifie, quand la règle doit être évaluée. On distingue deux catégories d événements : événements atomiques et événements composés comme l illustre le schéma XML suivant de la partie événements de ECAPE-L: <xsd:element name="events" type="tevents"> <xsd:annotation> <xsd:documentation> These are the events for an ECAPE-L process. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:complextype name="tevents"> <xsd:sequence> <xsd:element ref="atomicevents" maxoccurs="unbounded"/> <xsd:element ref="compositevents" minoccurs="0" maxoccurs="unbounded"/> </xsd:sequence> </xsd:complextype> Les événements atomiques Les événements atomiques (primitifs) décrivent des occurrences élémentaires d une situation prédéfinie dans le système comme par exemple : - Evénements d une activité (début, fin, annulation, erreur) - Evénements d un processus (erreur, trigger) - Evénements temporels (timer) - Evénements externes (réception message, signal) 99

113 Contribution / Le langage ECAPE-L Le schéma XML de la partie événements atomiques de ECAPE-L est le suivant : <xsd:element name="atomicevents" type="tatomicevents"/> <xsd:complextype name="tatomicevents"> <xsd:sequence> <xsd:element ref="atomicevent" maxoccurs="unbounded"/> </xsd:sequence> </xsd:complextype> <xsd:element name="atomicevent" type="tatomicevent"/> <xsd:complextype name="tatomicevent"> <xsd:sequence> <xsd:element ref="eventtype"/> <xsd:element ref="description" minoccurs="0"/> </xsd:sequence> <xsd:attribute name="id" type="xsd:id" use="required"/> <xsd:attribute name="name" type="xsd:ncname" use="optional"/> <xsd:attribute name="eventgroup" type="teventgroup" use="required"/> </xsd:complextype> 100

114 Contribution / Le langage ECAPE-L Les éléments et les attributs de la balise «AtomicEvent» EventType Description Id Name EventGroup Signification Le type d événement qui peut être : EndActivityEvent Un événement de terminaison de l exécution d une activité donnée CancelledActivityEvent Un événement d annulation de l exécution d une activité donnée SkipActivityEvent Un événement d annulation de l exécution d une activité donnée TimeEvent Un événement temporel ErrorEvent Un événement d erreur SignalEvent Un événement de réception d un signal (ou message) TriggerEvent Un événement de déclanchement d une entité GenericEvent Un nouvel événement défini Les descriptions du rôle des d événements par le concepteur L identifiant d événement dans le processus Le nom d événement Le groupe d événement qui peut être : Un événement de début qui StartGroup déclenche l exécution du processus Un événement intermédiaire qui IntermediateGroup se déclenche en cours de l exécution du processus EndGroup Un événement de fin qui cause la terminaison du processus Les événements composés Les événements composés (complexes) sont définis comme une combinaison d événements atomiques et/ou composés et cela en utilisant des constructeurs d événements comme par exemple : - Disjonction (e1, e2) elle permet de spécifier qu au moins l un des deux événements est détecté. - Conjonction (e1, e2) elle permet de spécifier que les deux événements e1 et e2 ont lieu sans tenir compte de leur ordre d arrivée. - Occurrence (e1, nbr_occurence) elle permet de spécifier plusieurs occurrences d un même événement. - Sequence (e1, e2) elle permet de spécifier la succession de deux événements. 101

115 Contribution / Le langage ECAPE-L - After (e1, t) elle permet de caractériser le fait qu un certain temps t s est passé après qu un événement se soit produit - Not (e1, t) elle permet de caractériser le fait qu un événement ne s est pas produit dans un intervalle de temps t. Le schéma XML de la partie événements composés de ECAPE-L est le suivant : <xsd:element name="compositevents" type="tcompositevents"/> <xsd:complextype name="tcompositevents"> <xsd:sequence> <xsd:element ref="compositevent" maxoccurs="unbounded"/> </xsd:sequence> </xsd:complextype> <xsd:element name="compositevent" type="tcompositevent"/> <xsd:complextype name="tcompositevent"> <xsd:sequence> <xsd:element ref="compositexpression"/> <xsd:element ref="description" minoccurs="0"/> </xsd:sequence> <xsd:attribute name="id" type="xsd:id" use="required"/> <xsd:attribute name="name" type="xsd:ncname" use="optional"/> <xsd:attribute name="eventgroup" type="teventgroup" use="required"/> <xsd:attribute name="expressionlanguage" type="xsd:anyuri"/> </xsd:complextype> Les éléments et les attributs de la balise «CompositEvent» Signification CompositExpression L expression de l événement composé Description Les descriptions du concepteur qui décrivent le rôle du d événement Id L identifiant d événement dans le processus Name Le mon d événement EventGroup Le groupe d événement (voir la section ) expressionlanguage Le langage utilisé pour spécifier l expression de l événement composé (par défaut le xpath1.0 est utilisé) Les règles ECAPE Dans le langage ECAPE-L, la logique du processus est modélisée par un ensemble de règles ECAPE. En effet, une règle ECAPE se déclenche lorsqu un événement se produit (<OnEvent>), la partie condition (<PreCondition>) est vérifiée, si cette partie est satisfaite, alors la partie action (<Action>) est lancée en exécutant les différents activités associées en utilisant 102

116 Contribution / Le langage ECAPE-L des instructions préfinies du langage. L exécution de l action est validée si la post condition (<PostCondition>) est satisfaite. Dans ce cas les post événements (<PostEvents>) sont déclenchés. Dans le cas contraire (post condition n est pas satisfaite), un mécanisme de compensation (<CompensateAction>) peut être lancé dans le but remplacer, si possible, l action de la règle. Une deuxième alternative, est le déclenchement des événements d erreurs (<ErrorEvents>). Le schéma XML de la partie règles ECAPE de ECAPE-L est la suivante : <xsd:element name="businessrules" type="tbusinessrules"/> <xsd:complextype name="tbusinessrules"> <xsd:sequence> <xsd:element ref="businessrule" maxoccurs="unbounded"/> </xsd:sequence> </xsd:complextype> <xsd:element name="businessrule" type="tbusinessrule"/> <xsd:complextype name="tbusinessrule"> <xsd:sequence> <xsd:element ref="onevent"/> <xsd:element ref="precondition"/> <xsd:element ref="action"/> <xsd:element ref="compensateaction"/> <xsd:element ref="postcondition"/> <xsd:element ref="postevents"/> <xsd:element ref="errorevents"/> </xsd:sequence> <xsd:attribute name="name" type="xsd:id" use="required"/> <xsd:attribute name="version" type="xsd:anysimpletype"/> <xsd:attribute name="priority" type="xsd:anysimpletype"/> </xsd:complextype> 103

117 Contribution / Le langage ECAPE-L Les éléments et les attributs de la balise «BusinessRule» OnEvent PreCondition Signification L ensemble des événements qui déterminent quand une règle doit être évaluée. Le schéma XML de OnEvent est le suivant: <xsd:element name="onevent" type="teventexpression"/> Les prédicats dont dépend l exécution de l action. Le schéma XML de PreCondition est le suivant : <xsd:element name="precondition" type="tconditionexpression"/> L ensemble des activités à exécuter si la précondition est vraie. Le schéma XML de Action est le suivant: Action <xsd:element name="action" type="taction"/> Pour exécuter les activités de la partie action, un ensemble d instructions est prédéfini (ces instructions seront détaillées un peu plus loin dans ce chapitre) L ensemble des activités à exécuter pour compenser l effet de l action de la règle. L action de compensation est lancée si la post-condition n est pas satisfaite. Le schéma XML de CompensateAction est le suivant: CompensateAction <xsd:element name="compensateaction" type="taction"/> Un ensemble d instructions est prédéfini pour exécuter les activités de l action de compensation (ces instructions seront détaillées un peu plus loin dans ce chapitre) PostCondition Les prédicats dont dépend la validation de la règle. Le schéma XML de PostCondition est le suivant: <xsd:element name="postcondition" type = "tconditionexpression"/> L ensemble des événements déclenchés par l exécution de l ensemble des instructions de la partie action. Le schéma XML de PostEvents est comme suit : PostEvents <xsd:element name="postevents" type="tpostevents"/> <xsd:complextype name="tpostevents"> <xsd:sequence> <xsd:element name="postevent" type = "teventexpression"/> </xsd:sequence> </xsd:complextype> ErrorEvents Name Version Priority L ensemble des événements d erreurs qui peut être déclenchés si la postcondition n est pas satisfaite. Le schéma XML de ErrorEvents est le suivant: <xsd:element name="errorevents" type="terrorevents"/> <xsd:complextype name="terrorevents"> <xsd:sequence> <xsd:element name="errorevent" type = "teventexpression"/> </xsd:sequence> </xsd:complextype> Le nom de la règle La version de la règle La priorité accordée à la règle 104

118 Contribution / Le langage ECAPE-L Pour exécuter les activités métier du processus, le langage ECAPE-L propose un ensemble d instructions qui sera utilisé dans la partie action (et action de compensation) de la règle : L instruction EXECUTE L instruction EXECUTE est utilisée pour exécuter une activité donnée (en définissant le nom de l activité et les différents paramètres d entrée/sortie) par un participant donné (en définissant le nom du participant). Cette instruction peut lancer une opération manuelle qui exige l intervention humaine, ou une opération automatique comme l exécution d une application ou l invocation d un service web. L exécution de l instruction EXECUTE provoque l événement de terminaison de l exécution de l activité en question. Cet événement est décrit explicitement dans la partie PostEvents de la règle. Le schéma XML de cette instruction est le suivant: <xsd:element name="execute" type="texecute"/> <xsd:complextype name="texecute"> <xsd:sequence> <xsd:element ref="operation" minoccurs="0"/> <xsd:element ref="inputvariablename" minoccurs="0" maxoccurs="unbounded"/> <xsd:element ref="outputvariablename" minoccurs="0" maxoccurs="unbounded"/> <xsd:element ref="inputoutputvariablename" minoccurs="0" maxoccurs="unbounded"/> <xsd:element ref="performer" minoccurs="0"/> <xsd:element ref="description" minoccurs="0"/ </xsd:sequence> </xsd:complextype> Les éléments et les attributs de la balise «Execute» Operation InputVariableName OutputVariableName InputOutputVariableName Performer Description Signification Le nom de l activité à exécuter Les variables d entrée Les variables de sortie Les variables d entrée/sortie en même temps Le nom du participant responsable de l exécution de l activité Les descriptions du concepteur qui décrivent cette exécution 105

119 Contribution / Le langage ECAPE-L L instruction DISCOVER L instruction DISCOVER est utilisée pour lancer une fonction de découverte d une ressource donnée (participant est de type DiscoveredApplication, voir la section 7.2.2) dans un registre donné et en spécifiant les qualités de services souhaitées. Cette instruction permet de remplacer les ressources qui ne sont pas disponibles au moment de l exécution du processus. L instruction DISCOVER est principalement utilisée pour substituer des services web en cherchant un service web équivalent, dans un registre UDDI donné, qui correspond aux qualités de services exprimées par le concepteur. Si un service équivalent est trouvé, son adresse URL est recopiée temporairement dans la partie ApplicationReferenceFound du participant. De cette façon, ce participant (service) pourra exécuter une activité métier en utilisant l instruction EXECUTE. L instruction DISCOVER peut être utilisée aussi dans l action de compensation pour remplacer les services qui donnent des exécutions non valides. Le schéma XML de cette instruction est le suivant: <xsd:element name="discover" type="tdiscover"/> <xsd:complextype name="tdiscover"> <xsd:sequence> <xsd:element ref="operation" minoccurs="0"/> <xsd:element ref="performer" minoccurs="0"/> <xsd:element ref="businessregistrylocation" /> <xsd:element ref="qos" minoccurs="0"/> <xsd:element ref="applicationreferencefound" minoccurs="0"/> <xsd:element ref="description" minoccurs="0"/> </xsd:sequence> </xsd:complextype> 106

120 Contribution / Le langage ECAPE-L Les éléments et les attributs de la balise «Discover» Operation Performer BusinessRegistryLocation Signification Le nom de l activité à exécuter par cette découverte Le nom du participant à découvrir L adresse du registre de recherche Les qualités de service de recherche souhaitées. Le schéma XML du QoS est comme suit : QoS <xsd:element name="qos" type="tqos"/> <xsd:complextype name="tqos"> <xsd:sequence> <xsd:element ref="quality" maxoccurs="unbounded"/> </xsd:sequence> </xsd:complextype> Où "Quality" est la qualité souhaitée définie par un nom, un id, une valeur, une unité et une description (voir annexe 2). ApplicationReferenceFound Description L adresse de la ressource trouvée Les descriptions du concepteur qui décrivent cette découverte L instruction CANCEL L instruction CANCEL permet d annuler l exécution de toutes les instances d une activité donnée (ou toutes les activités du processus). Cette instruction peut être utilisée dans l action de compensation pour terminer, d une manière correcte, l exécution du processus. Le schéma XML de l instruction CANCEL est le suivant: <xsd:element name="cancel" type="tcancel"/> <xsd:complextype name="tcancel"> <xsd:sequence> <xsd:element ref="activityname" minoccurs="0"/> <xsd:element ref="description" minoccurs="0"/> </xsd:sequence> <xsd:attribute name="cancelall" default="false" type="tboolean" use="required"/> </xsd:complextype> 107

121 Contribution / Le langage ECAPE-L Les éléments et les attributs de la balise «CANCEL» ActivityName Description CancelAll Signification Le nom de l activité à annuler Les descriptions du concepteur qui décrivent cette annulation L option d annuler toutes les activités du processus (cette option par défaut est à «faux») L instruction SKIP L instruction SKIP permet de sauter l exécution d une activité donnée. La différence entre cette instruction et l instruction d annulation se situe au niveau de l événement déclenché : l instruction SKIP provoque un événement de terminaison d une activité, cela permet au processus de poursuivre son exécution normalement. En revanche l instruction CANCEL provoque un événement d erreur qui conduit l exécution du processus à une déviation. Notons que l instruction SKIP peut être aussi utilisée dans l action de compensation pour sauter l exécution d une activité d un processus. Le schéma XML de cette instruction est le suivant: <xsd:element name="skip" type="tskip"/> <xsd:complextype name="tskip"> <xsd:sequence> <xsd:element ref="activityname" minoccurs="0"/> <xsd:element ref="description" minoccurs="0"/> </xsd:sequence> </xsd:complextype> Les éléments et les attributs de la balise «SKIP» ActivityName Description Signification Le nom de l activité à sauter Les descriptions du concepteur qui décrivent ce saut L instruction COPY L instruction COPY permet de copier les données d une variable vers une autre. Cette instruction est utilisée par exemple pour afficher des messages d erreur ou pour récupérer les données véhiculées avec les événements déclenchés. Le schéma XML de l instruction COPY est comme suit : <xsd:element name="copy" type="tcopy"/> <xsd:complextype name="tcopy"> <xsd:sequence> <xsd:element ref="from"/> 108

122 Contribution / Le langage ECAPE-L <xsd:element ref="to"/> </xsd:sequence> </xsd:complextype> Les éléments et les attributs de la balise «COPY» From To La variable source La variable destination Signification 7.3 Exemple illustratif Pour illustrer le méta-modèle du langage ECAPE-L, nous allons revisiter dans cette section l exemple du processus de traitement de commande vu dans le chapitre précédant. Rappelons que ce processus se déclenche à la réception d une commande d'un client. Ensuite le prix initial et le prix de livraison sont calculés, d une manière parallèle, par le service financier et le service de livraison respectivement et cela à condition que le client soit enregistré dans la base de données de l entreprise. La figure 7.3 représente une partie du processus de traitement de commande exprimée en ECAPE-L. Les différents éléments du processus sont décrits par des balises associées dans lesquelles plusieurs informations, concernant ces éléments, peuvent être spécifiées (1) La figure 7.3.A représente la définition d un participant en utilisant la balise <Participant>. Dans cette balise, le nom du participant (service financier) et son type (application spécifique) sont spécifiés. En fonction du type du participant, d autres informations sont complétées. En effet, si on suppose que le service financier est un service Web spécifique (langage de définition : WSDL et le protocole : SOAP), alors, son adresse est spécifiée. (2) La figure 7.3.B représente la définition d une variable en utilisant la balise <Variable>. Dans cette balise, le nom de la variable (information sur le client) et son type (tableau de chaînes de caractères) sont spécifiés. (3) La figure 7.3.C représente la définition d une activité métier en utilisant la balise <BusinessActivity>. Dans cette balise, le nom de l activité métier (vérification du client), les types de ses paramètres d entrée/sortie et son type d exécution (manuelle) sont spécifiés. (4) La figure 7.3.D représente la définition d un événement atomique et un événement composé en utilisant les balises <AtomicEvent> et 109

123 Contribution / Le langage ECAPE-L <CompositEvent> respectivement. Dans la première balise, le nom de l événement atomique (recevoir une commande), son groupe (groupe de déclenchement de processus) et son type (événement de réception de message) sont spécifiés. Dans la deuxième balise, le nom de l événement composé (événement calcul prix final), son groupe (groupe de déclenchement intermédiaire) et le langage d expression utilisé (XPATH 1.0) sont spécifiés. En effet, cet événement est défini par l expression : Conjonction (événement de la fin du calcul prix initial et événement de la fin du calcul prix de livraison). (5) La balise «Business Rules» est utilisée pour décrire l ensemble des règles ECAPE (voir les figures 7.3.E et 7.3.F). La règle R 1, par exemple, exprime la politique suivie lors de la réception d une commande. En effet, lors d une occurrence de réception une commande, la règle se déclenche (<OnEvent> $Receive_Order </OnEvent>) et s assure que les informations du client sont valides (<PreCondition> $info_costumer!= "" </PreCondition>). Dans le cas où les informations sont valides, l instruction <Execute> de la partie action est exécutée. Cette instruction spécifie qu on doit exécuter une activité métier donnée (<Operation>$Costumer_Verification</ Operation> dans notre exemple) en précisant les paramètres d entrée/ sortie (<InputVariableName> $info_costumer </InputVariableName> et <OutputVariableName> $CostumerRegistration </OutputVariableName>) et en précisant aussi le participant qui a comme rôle d exécuter cette activité (<Performer>$Commercial_Service</Performer>). L exécution de l instruction <Execute> de la règle R 1 va déclencher les événements exprimés dans la partie <PostEvents> (dans notre exemple l événement de terminaison de l activité de vérification du client $End_Costumer_Verification sera déclenché). Finalement la règle R 1 est validée si les prédicats de la partie post condition exprimés dans la balise <PostCondition> sont vrais. A son tour, la règle R 3 exprime la politique du calcul du prix de livraison si le client est enregistré. Pour cela, la partie action de cette règle doit exécuter l activité du calcul du prix de livraison en utilisant le service de livraison. Si on suppose que ce service n est pas spécifié et sera déterminé dans la phase d exécution. Dans ce cas, l instruction <Discover> est utilisée pour trouver un service qui répond aux qualités de service souhaitées (dans notre exemple, le coût de l utilisation du service est moins de 1 / accès). Après l exécution de cette instruction, l adresse du service trouvée est associée temporairement au participant service livraison. Ainsi, l activité métier calcul du prix de livraison pourra être exécutée en utilisant l instruction <Execute>. 110

124 Contribution / Le langage ECAPE-L (A) (B) (C) (D) (E) (F) Figure 7.3 Un sous processus RbBPDL du traitement de commande 111

125 Contribution / Le langage ECAPE-L 7.4 L expressivité du langage ECAPE-L Le méta-modèle du langage ECAPE-L, présenté dans la section précédente, offre une grande expressivité pour modéliser un processus métier en permettant de couvrir un grand nombre de «Workflow patterns». En effet, ces patrons sont proposés par «the Workflow Patterns initiative» dans [WPI09] pour décrire les problèmes récurrents et les solutions proposées pour modéliser les flux de contrôle d un processus métier. Nous allons présenter, dans le tableau suivant, la couverture des principaux patrons de Workflow (patrons du flux de contrôle, patrons de ressources, patrons de données) par le langage ECAPE-L. Notons que le signe (+) est utilisé pour désigner que le patron est couvert par le langage et le signe (-) est utilisé pour désigner que le patron n est pas couvert par le langage. Patrons du flux de contrôle (control flux patterns [ WPI09]) Couverture par ECAPE-L Explication La séquence + La branche parallèle + La synchronisation + Le choix exclusif + La jonction simple + La boucle structurée + Le cycle arbitraire + Annulation d activité + Ce patron est supporté en définissant un postévénement qui active une règle Ce patron est supporté en définissant un postévénement qui d active plusieurs règles simultanément Ce patron est supporté en définissant l événement de d activation d une règle par une conjonction de post-événements de plusieurs règles Ce patron est supporté en définissant un postévénement qui active deux règles qui ont deux conditions contradictoires Ce patron est supporté en définissant l événement de d activation d une règle par une disjonction de post-événements de plusieurs règles Ce patron est supporté en spécifiant un ensemble de règles qui s auto-déclenchent d une façon à ce qu elles forment une boucle structurée (voir chapitre 6) Ce patron est supporté en spécifiant un ensemble de règles qui s auto-déclenchent d une façon à ce qu elles forment un cycle arbitraire avec plusieurs règles d entrée ou plusieurs règles de sortie Ce patron est supporté par l instruction CANCEL avec l option d annuler toutes les activités du processus égale à faux 112

126 Contribution / Le langage ECAPE-L Annulation multiple + Terminaison implicite + Terminaison explicite + Ce patron est supporté par l instruction CANCEL avec l option d annuler toutes les activités du processus égale à vrai Le processus se termine quand il n y a plus de règles à déclencher Le processus se termine quand un événement, qui appartient au groupe des événements de la fin du processus, se déclenche Patrons de ressources (ressources pattern [ WPI09]) Couverture par ECAPE-L Explication Allocation direct + Allocation aléatoire + Ce patron est supporté en associant un participant à une activité métier Ce patron est supporté en définissant un participant qui n est pas spécifié dans la phase de la modélisation et qui sera déterminé dans la phase d exécution en utilisant l instruction DISCOVER. Allocation basée sur le Ce patron est supporté en définissant le rôle de + rôle chaque participant Délégation - La délégation de rôle n est pas supportée Patrons de données (data patterns [WPI09]) Variable globale d un processus Variable locale d une activité Passage de données activité vers activité Passage de données activité vers extérieur Passage de paramètre par copie Passage de paramètre par référence Pré-condition sur les données d une activité Post-condition sur les données d une activité Couverture par ECAPE-L Explication Ce parton est supporté car toutes les variables du processus sont des variables globales Ce parton n est pas supporté car toutes les variables du processus sont globales Ce parton est supporté car le passage de données entre une activité et une autre activité d un processus est possible (en utilisant les mêmes paramètres d entrée/sortie ou en utilisant l instruction COPY) Ce parton est supporté car le passage de données entre une activité et une ressource extérieure est possible (en utilisant l instruction COPY) Ce parton n est pas supporté car le mécanisme de passage en utilisant les copies de données n est pas supporté Ce parton est supporté en utilisant une variable de type référence vers une variable externe Ce parton est supporté en utilisant la condition de la règle Ce parton est supporté en utilisant la post-condition de la règle 113

127 Contribution / Le langage ECAPE-L 7.5 La représentation graphique du ECAPE-L Le langage ECAPE-L décrit formellement les éléments de base qui constituent un processus en respectant une grammaire XML. En dépit des avantages proposés par l utilisation du XML comme syntaxe pour un langage de modélisation (structure arborescente, transformation XSLT, etc.), son écriture est souvent trop verbeuse ce qui rend l utilisation et la compréhension du code une tâche difficile. Pour augmenter la compréhension du processus ECAPE-L, nous proposons un nouveau diagramme basé sur le langage URML (UML- Based Rule Modeling Language) proposé dans [Giu06]. Ce diagramme, appelé URML for BP, facilite la compréhension de la modélisation et permet de générer par la suite le code ECAPE-L associé. Cette manière conviviale augmente essentiellement la compréhension et permet d évaluer de ces processus. Figure 7.4 les symboles utilisés dans URML for BP Le URML for BP propose cinq principaux symboles qui sont illustrés dans la figure 7.4 : (1) Les cercles représentent les règles métier. (2) Les flèches avec doubles têtes entrantes représentent les conditions de l exécution de la partie action de la règle. A leur tour, les flèches avec doubles têtes sortantes représentent les post conditions de la partie action de la règle. (3) Les flèches entrantes au chevron représentent les événements de déclenchement d une règle. Tandis que, les flèches sortantes du chevron représentent les post événements qui sont déclenchés après l exécution de la partie action de la règle. (4) Les chevrons simples représentent les évènements de début du processus, les chevrons avec les frontières doubles représentent les événements intermédiaires, finalement, les chevrons avec des frontières en gras 114

128 Contribution / Le langage ECAPE-L représentent les événements de fin du processus (5) Les rectangles aux coins arrondis représentent les activités métier du processus. (6) Les rectangles modélisent les participants qui ont comme rôle d exécuter des activités données du processus. La figure 7.5 représente un processus de traitement de commande en utilisant le langage graphique URML for BP. En effet, les cercles représentent les règles métier, les rectangles à coins arrondis représentent les activités métier du processus tel que «Calcul de la facture». A leur tour, les chevrons représentent les événements qui définissent un événement qui se déclenche à un moment donné, cet événement peut être, dans notre exemple, une réception de commande ou l envoi de la facture, les flèches avec doubles têtes représentent les différentes conditions des différentes règles. Finalement, les colonnes de la figure modélisent les participants qui ont le rôle d exécuter des activités données du processus. Les participants du processus de notre exemple représentent le service commercial, le service financier et service de livraison. Figure 7.5 Un diagramme UMRL for BP d un sous processus du traitement de commande 7.6 Conclusion Nous avons présenté dans ce chapitre un nouveau langage de modélisation de processus métier basé sur les règles appelé ECAPE-L. Ce langage s appuie sur une syntaxe XML pour décrire la logique du processus métier en utilisant le modèle ECAPE ainsi que les différents éléments du processus. Pour cela, le méta-modèle du ECAPE-L permet de représenter : les participants qui ont le rôle d exécuter les activités du processus (dimension 115

129 Contribution / Le langage ECAPE-L organisationnelle); les variables qui seront utilisées par les activités et qui servent aussi à déterminer les types de messages échangés au sein du processus (dimension informationnelle); les activités métier (automatiques et manuelles) du processus qui seront utilisées pour spécifier les actions et les actions de compensation de chaque règle (dimension fonctionnelle); les événements (atomiques et composés) qui seront utilisées pour spécifier les événements de déclenchement, les post-événements et les événements d erreur de chaque règle (dimension informationnelle) ; l ensemble de règles ECAPE qui est le cœur de ce méta-modèle permet de modéliser un processus. Notons que ce nouveau langage permet également de décrire les informations techniques utilisées lors de l exécution du processus comme : les protocoles du transport et les formats de messages utilisés. En plus, il est en mesure de couvrir les principaux patrons de Workflow (patrons du flux de contrôle, patrons de ressources, patrons de données). Nous considérons que ce nouveau langage déclaratif est au même niveau que les langages d exécution impératifs de processus tels que BPEL et XPDL car il peut être exécuté par un moteur de règles qui interprète les différentes instructions qui exécutent les actions des règles déclenchées. En plus, ECAPE-L peut être associé à un nouveau diagramme graphique appelé URML for BP pour définir un processus abstrait (de haut niveau) qui permet d augmenter la visibilité et la compréhension du processus. URML for BP permet donc une représentation graphique comme les langages de définition de haut niveau de processus métier tels que BPMN comme il est résumé dans le tableau suivant : Langages de définition de haut niveau de processus métier Langages d exécution de processus métier BPMN [OMG09] X BPEL [OASIS07] XPDL [WfMC08] ECAPE-L/ URML for BP X X X X Cependant, la nécessité de la prise en compte de la dynamicité des différents éléments de processus nous pousse à porter plus d attention à la gestion du changement de la modélisation du processus métier. Par exemple, dans le cas du processus du traitement de commande présenté dans la section 7.3, si l'entreprise décide de ne pas livrer ses produits, la r 3 règle sera supprimée du modèle de processus. Par conséquent, un sous ensemble des règles sera impacté par ce changement (comme la règle r 4 qui doit être 116

130 Contribution / Le langage ECAPE-L modifiée). Pour cette raison, l ensemble de règles impactées par un changement mérite d être déterminé et cela afin de maintenir la cohérence du processus et pouvoir estimer le coût de ce changement. Dans le chapitre suivant, nous allons proposer notre approche de gestion du changement d un processus basé sur les règles. 117

131 Contribution / Démarche de gestion du changement d un processus métier basée sur les règles 8 Démarche de gestion du changement d un processus métier basée sur les règles 8.1 Introduction 8.2 Démarche de gestion du changement 8.3 Les relations entre les règles Les relations de déclenchement Les relations de partage de variables Les propriétés des relations 8.4 Le graphe d impacts 8.5 L impacte de changement d une règle 8.6 Le coût de changement d une règle 8.7 La degré de tolérance aux changements d un processus 8.8 Conclusion 8.1 Introduction Dans un contexte concurrentiel, et pour faire face aux phénomènes socioéconomiques comme la mondialisation et la libéralisation, les entreprises ont besoin de plus en plus, de gérer des processus complexes, de s adapter aux changements et d assurer des processus métier fiables pour mener à bien leurs missions. En effet, la nature dynamique des environnements des organisations rend les éléments de processus susceptibles d être modifiés ou supprimés. Selon Goedertier dans [Geo06 b], l origine de cette dynamicité vient essentiellement du changement fréquent dans les réglementations extérieures que doit respecter l entreprise et aussi le changement de politiques intérieures définies par l entreprise. Ces réglementations et politiques métier sont souvent exprimés sous forme de règles appelées règles métiers. Ces règles métier méritent, donc, être formalisées pour faciliter leurs interactions. Malheureusement, en utilisant les langages impératifs tels que BPMN [OMG09], BPEL [OASIS07] et le XPDL [WfMC08], ces règles métier sont mélangées avec le code de la logique du processus. Cela rend les processus 118

132 Contribution / Démarche de gestion du changement d un processus métier basée sur les règles métier rigides, et conduit à un effort de changement coûteux. En effet, pour appliquer un changement sur certaines parties d'un processus métier (par exemple, ajout d'une activité, suppression d une activité, ou modification d'une contrainte), les concepteurs doivent réexaminer tout le modèle du processus alors qu il serait avantageux de ne modifier que les parties qui sont impactées par le changement, tout en conservant stables les autres parties du processus. Dans le chapitre 6, nous avons proposé un nouveau modèle basé sur les règles ECAPE pour décrire la logique d'un processus en utilisant un ensemble de règles de réactions. Cela permet de mettre en œuvre le changement (par exemple, modifier, ajouter ou supprimer des règles existantes) en modifiant uniquement un sous ensemble de règles, ce qui réduit l effort du changement. Cependant, lorsqu il s'agit de processus complexes, il est plus avantageux de gérer l'impact du changement d une règle sur l ensemble des règles qui constituent le processus, en déterminant quelles règles sont impactées par ce changement et en estimant le coût global de ce changement. Cette estimation permet d aider le concepteur lorsque plusieurs alternatives du changement se présentent, et permet aussi d organiser la planification des ressources nécessaires pour implémenter le changement. Dans ce chapitre, nous proposons une approche basée sur les règles pour gérer le changement dans la modélisation du processus métier en déterminant les règles impactées par un changement et en estimant le coût du changement d un processus et son degré de tolérance au changement. 8.2 Démarche de gestion du changement Dans un contexte dynamique, les entreprises ont besoin de se baser sur des modèles de processus flexibles pour permettre la modification des parties qui ont été changées tout en gardant la stabilité des autres parties du processus. Selon la taxonomie de changement de Regev et al. [Reg06] (présentée dans le chapitre 3), tous les éléments du processus sont susceptibles d être modifiés. En effet, le changement peut concerner tous les aspects du processus, on peut ainsi ajouter, modifier ou supprimer des activités, des variables, etc. Cependant, le changement d un élément du processus peut entraîner le besoin de changer d autres éléments qui sont en relation avec l élément modifié afin de conserver la cohérence du processus. Pour cela, l impact du changement d un élément sur le reste du processus mérite d être étudié pour permettre la flexibilité d une modélisation d un processus métier. Dans ce contexte, nous 119

133 Contribution / Démarche de gestion du changement d un processus métier basée sur les règles proposons une approche pour gérer le changement d un processus modélisé par un ensemble de règles ECAPE. Les principales étapes de cette approche sont présentées dans la figure 8.1 : Figure 8.1 Le démarche de gestion du changement d un processus ECAPE 1. La première étape de la gestion de changement consiste à déterminer les relations qui existent entre les règles ECAPE. En effet, les règles impactées par le changement d une règle sont l ensemble de règles qui ont une relation avec la règle changée. Par conséquent, nous avons besoin d étudier les relations entre les règles. 2. La deuxième étape de cette gestion consiste à transformer l ensemble de règles ECAPE qui constituent le processus ainsi que les différentes relations qui existent entre ces règles en un graphe appelé graphe d impacts. Ce dernier va permettre de déterminer les règles impactées par un changement. 3. Lors d un changement d une règle, le graphe d impacts est analysé afin de déterminer toutes les opérations nécessaires pour modifier la règle à changer ainsi que toutes les règles impactées par ce changement, ce qui permet d estimer le coût du changement. 4. En analysant le graphe d impacts, on peut, également, estimer le degré de tolérance aux changements d un processus. En effet, ce degré représente le coût moyen du changement d une règle du processus. 120

134 Contribution / Démarche de gestion du changement d un processus métier basée sur les règles Dans ce qui suit, nous allons détailler ces différentes étapes. 8.4 Les relations entre les règles Le changement d une règle peut obliger le concepteur à changer d autres règles qui sont en relations avec la règle changée et cela afin de maintenir la cohérence du processus. Pour automatiser la gestion du changement d un processus, nous allons nous intéresser, dans cette section, aux relations qui existe entre les règles ECAPE. Pour cela, nous avons déterminé deux grandes classes de relations : relations de déclenchements et relations de partages de variables. Notons que, pour formaliser la définition des différentes relations nous allons utiliser les notations suivantes : - E : un ensemble d événements du processus - V : un ensemble de variable du processus - A : un ensemble d activités métier du processus - e ri : l événement qui déclenche la règle R i tel que e ri E - PsE ri : l ensemble des événements qui se déclenche pendant ou après l exécution de la partie action de la règle R i tel que PsE ri E - ErEri : l ensemble des événements d erreur qui peut se déclencher si la post condition de la règle R i n est pas satisfaite tel que ErE ri E - PsE ri + : l ensemble des post événements tel que PsE ri + = PsE ri ErE ri - A ri : l ensemble des activités métier utilisées par la règle R i tel que A ri A - AC ri : l ensemble des activités de compensation utilisées par la règle R i si la post condition de la règle R i n est pas satisfaite tel que A ri A - V ri : l ensemble des variables utilisées par la règle R i tel que V ri V est constitué des ensembles suivants V cri : l ensemble des variables utilisées par les prédicats C ri (V cri ) de la partie condition de la règle R i tel que V cri V V pcri : l ensemble des variables utilisées par les prédicats PsC ri (V pcri ) de la partie post condition de la règle R i tel que V pcri V ri 121

135 Contribution / Démarche de gestion du changement d un processus métier basée sur les règles input V ari : l ensemble des variables d entrés utilisées par les activités de input input l action A ri ( V ari ) de la règle R i tel que V ari V ri : l ensemble des variables de sorties utilisées par les activités de output output l action Vari A ri () de la règle R i tel que V ari V ri : l ensemble des variables d entrés utilisées par les activités de input input l action A ri ( V acri ) de la règle R i tel que V acri V ri : l ensemble des variables de sorties utilisées par les activités de output l action de compensation Vacri A ri () de la règle R i tel que output V ari input V acri output V acri output V acri V ri Finalement, les constructeurs d événements composés sont utilisés comme suit : (1) e 1 e 2 : permet de spécifier que les deux événements e 1 et e 2 ont lieu sans tenir compte de leur ordre d arrivée. (2) e 1 e 2 : permet de spécifier qu au moins l un des deux événements est déclenché. (3) Seq (e 1, e 2 ) : permet de spécifier une séquence de deux événements. (4) Sim (e 1, e 2 ) permet de spécifier que les deux événements se déclenchent simultanément. (5) any(m, e 1, e 2,, e n ) permet de spécifier que m événements parmi e 1, e 2,, e n se déclenchent Les relations de déclenchement Une relation de déclenchement représente le cas où une ou plusieurs de règles cause l activation (l appel) d une ou plusieurs autres règles. En effet, on distingue plusieurs types de relation de déclenchement: Déclenchement en série (1 :1) Une relation de déclenchement en série (noté S ) représente le cas où une règle cause l activation d une autre règle (voir la figure 8.2). Figure 8.2 La relation de déclenchement en série 122

136 Contribution / Démarche de gestion du changement d un processus métier basée sur les règles En effet, un événement qui déclenche une règle r j peut être provoqué pendant ou après l exécution de l action de la règle r i. Pour cela, nous considérons, le déclenchement d une règle r j par un événement de terminaison de l action de la règle r i, comme un cas particulier de la relation de déclenchement en série que l on nomme relation de cause à effet en série (noté S (CE ) ). Une relation de cause à effet en série représente le cas où une règle exige la terminaison d une autre règle pour se déclencher. Formellement, cela se définit comme suit : Définition 1 : deux règles r i et r j sont en relation de déclenchement en séquence (r i S r j ) si et seulement si : pse ri PsE + ri : pse ri = e rj tel que e rj est l événement qui déclenche la règle r j Si e rj est l événement de terminaison de l action a ri est une relation de cause à effet en série (CE ) S., alors la relation S Dans notre exemple du processus de traitement de commande vu dans le chapitre 6, la règle r 5 (calcul du prix total) est en relation de déclenchement en série avec la règle r 6 (facturation) car la règle le post événement de r 5 (le prix total est calculé) est le même événement de déclenchement de la règle r 6 (voir la figure 8.2). Le déclenchement de série de r 5 S r 6 est une relation de cause à effet, r 5 S (CE ) r 6 car la règle r 6 ne se déclenche que si l action de la règle r 5 est terminée. Figure 8.3 Exemple de deux règles en relation de déclenchement en série 123

137 Contribution / Démarche de gestion du changement d un processus métier basée sur les règles Déclenchement multiple (1 :n) Une relation de déclenchement multiple (noté M ) représente le cas où une règle provoque l activation de plusieurs règles (voir la figure 8.4). Figure 8.3 La relation de déclenchement multiple Notons qu une règle peut déclencher plusieurs règles d une manière séquentielle (déclenchement d une succession de règles sans tenir compte de l ordre), simultanément (déclenchement d un ensemble de règles en parallèle) ou avec choix (déclenchement d un sous ensemble de règles parmi un ensemble). Notons également que nous considérons, le déclenchement de plusieurs règles r 1 r j par un événement de terminaison de l action de la règle r i, comme un cas particulier de la relation de déclenchement multiple M que l on le nomme relation de cause à effet multiple (noté (CE ) ). Une relation de cause à effet multiple représente le cas où plusieurs nécessitent la terminaison d une autre règle pour se déclencher. Formellement, cela se définit comme suit : Définition 2 : La règle r i est en relation de déclenchement multiple avec un ensemble de règle r 1,, r j (r i M r 1,, r j, ) si et seulement si : 1) e r1... e rj + PsE ri 2) e r1... e rj + PsE ri 3) seq ( e r 1,..., e rj ) + PsE ri 4) sim ( e r 1,..., e rj ) + PsE ri + 5) any ( m, e r 1,..., e rj ) PsE ri D 6) pse ri PsE + ri : pse ri = e r1 =... = e rj tel a que e r1 e rj sont les événements qui déclenchent les règle r 1,, r j respectivement. n Si s e { e r 1,... e rj } : e est l événement de terminaison de l action a ri, alors la relation M M est une relation de cause à effet multiple. n 124

138 Contribution / Démarche de gestion du changement d un processus métier basée sur les règles Dans notre exemple du processus de traitement de commande, la règle r 1 (réception de commande) est en relation de déclenchement en parallèle avec les règles r 2 (Calcul prix initial) et r 3 (Calcul prix livraison) car le post événement de r 1 (client est vérifié) est l événement qui déclenche les règles r 2 et r 3 (voir la figure 8.4). Le déclenchement multiple de r 1 M r 2, r 3 est une M relation de cause à effet multiple (r 1 (CE ) r 2, r 3 ) car les règles r 2 et r 3 ne se déclenchent que si l action de la règle r 1 est terminée. Figure 8.4 Exemple de règles en relation de déclenchement multiple Déclenchement synchronisé (n :1) Une relation de déclenchement synchronisé (noté Syn ) représente le cas où plusieurs règles cause l activation d une autre règle (voir la figure 8.5). 125

139 Contribution / Démarche de gestion du changement d un processus métier basée sur les règles Figure 8.5 La relation de déclenchement de jointure Notons que plusieurs règles peuvent déclencher une autre règle d une manière synchronisée (déclenchement d une règle par une succession de règles sans tenir compte de l ordre) ou en jointure multiple (déclenchement d une règle par un sous ensemble de règles parmi un ensemble de règles). Notons également que nous considérons, le déclenchement de la r j par un événement de terminaison de toutes les actions des règles r 1 r i, comme un cas particulier de la relation de déclenchement synchronisé qu on le nomme Sny (CE) relation de cause à effet synchronisé (noté ). Une relation de cause à effet synchronisé représente le cas où une règle nécessite la terminaison de plusieurs règles pour se déclencher. Formellement, cela se définit comme suit : Définition 3 : un ensemble de règles r 1,, r i sont en relation de déclenchement synchronisé avec la règle r j (r 1,, r i Syn r j ) si et seulement si : + 1) pse r1 PsE r1 pseri PsE + ri : e rj = pse r1... pse ri + 2) pse r1 PsE r1 pseri PsE + ri : e rj = pse r1... pse ri + 3) pse r1 PsE r1 pseri PsE + ri : e rj = seq ( pse r1,..., pse ri ) + 4) pse r1 PsE r1 pseri PsE + ri : e rj = sim ( pse r1,..., pse ri ) + 5) pse r1 PsE r1 pseri PsE + ri : e rj = any ( m, pse r1,..., pse ri ) tel que e rj est l événement qui déclenche la règle r j. Si pse { pse r1,... pse ri } : pse est l événement de terminaison de l action a ri, alors la relation Syn est une relation de cause à effet synchronisé Syn. Dans notre exemple du processus de traitement de commande, les règles r 2 (Calcul prix initial) et r 3 (Calcul prix livraison) sont en relation de déclenchement de jointure avec la règle r 5 (calcul du prix total) car l événement de déclenchement de la règle r 5 est la conjonction post événement 126

140 Contribution / Démarche de gestion du changement d un processus métier basée sur les règles de la règle r 2 (prix initial calculé) et du post événement de la règle r 3 (prix livraison calculé) (voir la figure 8.6). Le déclenchement synchronisé de r 2, r 3 Syn Syn r 5 est une relation de cause à effet synchronisé (r 2, r 3 (CE ) r 5 ) car la règle r 5 se déclenche après la terminaison de l exécution des actions des règle r 2 et r 3 Figure 8.6 Exemple de règles en relation de déclenchement de jointure Les relations de partage de variables Une relation de partage de règles représente le cas où une ou plusieurs règles partagent, partiellement ou totalement, de variables avec une ou plusieurs autres règles. En effet, on distingue plusieurs types de relations de partage : Partage de variables Action- Condition Une relation de partage de variables Action - Condition (noté ) représente le cas où des variables de sorties de l action d une règle sont partagées, 127

141 Contribution / Démarche de gestion du changement d un processus métier basée sur les règles partiellement ou totalement, avec le prédicat de la condition d une autre règle. Formellement, cette relation se définit comme suit : Définition 4 : une règle r i est en relation de partage de variables Action condition avec la règle r j (r i r j ) si et seulement si : output v V ari : v V crj Dans notre exemple du processus de traitement de commande, les règles r 1 (réception de commande) et r 2 (Calcul prix initial) sont en relation de partage de variables Action- Condition car la variable de sortie de l action de la règle r 1 (la variable booléenne «client est enregistré») est utilisée par la condition le prédicat de la condition de la règle r 2 (la variable booléenne «client est enregistré» est vrai) (voir la figure 8.7). Figure 8.7 Exemple de règles en relation de partage de variables Condition-Action Partage de variables Compensation- Condition Une relation de partage de variables Compensation - Condition (noté ) représente le cas où des variables de sorties de l action de compensation d une règle sont partagées, partiellement ou totalement, le prédicat de la condition d une autre règle. Formellement, cette relation se définit comme suit : Définition 5 : une règle r i est en relation de partage de variables compensation output Condition avec la règle r j (r i r j ) si et seulement si : v V acri : v V crj 128

142 Contribution / Démarche de gestion du changement d un processus métier basée sur les règles Partage de variables Action - Action Une relation de partage de variables Action-Action (noté ) représente le cas où des variables de sorties de l action d une règle sont partagées, partiellement ou totalement, avec l action d une autre règle. Formellement, cette relation se définit comme suit : Définition 6 : une règle r i est en relation de partage de variables Action - output Action avec la règle r j (r i r j ) si et seulement si : v V ari : v input V arj Dans notre exemple du processus de traitement de commande, les règles r 2 (Calcul prix initial) et r 5 (Calcul prix total) sont en relation de déclenchement de partage de variables Action-Action car la variable (prix initial) est utilisée comme variable de sortie par l action de la règle r 2 et elle est utilisée comme variable d entrée de l action de la règle r 5 (voir la figure 8.8) Figure 8.8 Exemple de règles en relation de partage de variables Action-Action Partage de variables Compensation - Action Une relation de partage de variables Compensation - Action (noté ) représente le cas où des variables de sorties de l action de compensation d une règle sont partagées, partiellement ou totalement, avec l action d une autre règle. Formellement, cette relation se définit comme suit : Définition 7 : une règle r i est en relation de partage de variables Compensation 129

143 Contribution / Démarche de gestion du changement d un processus métier basée sur les règles -Action avec la règle r j (r i r j ) si et seulement si : output input v V acri : v V arj Partage de variables Action - Compensation Une relation de partage de variables Action - Compensation (noté ) représente le cas où des variables de sorties de l action d une règle sont partagées, partiellement ou totalement, avec l action de compensation d une autre règle. Formellement, cette relation se définit comme suit : Définition 8 : une règle r i est en relation de partage de variables Action - Compensation avec la règle r j (r i r j ) si et seulement si : output input v V ari : v V acrj Partage de variables Compensation - Compensation Une relation de partage de variables Compensation - Compensation (noté ) représente le cas où des variables de sorties de l action de compensation d une règle sont partagées, partiellement ou totalement, avec les variables d entrée de l action de compensation d une autre règle. Formellement, cette relation se définit comme suit : Définition 9 : une règle r i est en relation de partage de variables Compensation - Compensation avec la règle r j (r i r j ) si et seulement si : v output input V acri : v V acrj Partage de variables Action Post condition Une relation de partage de variables Action-Post condition (noté ) représente le cas où des variables de sorties de l action d une règle sont partagées, partiellement ou totalement, avec les variables du prédicat de la post condition d une autre règle. Formellement, cette relation se définie comme suit : Définition 10 : une règle r i est en relation de partage de variables Action Post condition avec la règle r j (r i r j ) si et seulement si : output v V ari : v V pcrj 130

144 Contribution / Démarche de gestion du changement d un processus métier basée sur les règles Dans notre exemple du processus de traitement de commande, les règles r 3 (Calcul prix livraison) et r 7 (Facture payée) sont en relation de partage de variables Action-Post condition car la variable (livreur) est utilisée par l action de la règle r 7 et elle est utilisée aussi par le prédicat de la post condition de la règle r 7 (livraison confirmée) (voir la figure 8.9). Figure 8.9 Exemple de règles en relation de partage de variables Action-Post condition Partage de variables Compensation Post condition Une relation de partage de variables Compensation-Post condition (noté ) représente le cas où des variables de sorties de l action de compensation d une règle partage, partiellement ou totalement, avec les variables du prédicat de la post condition d une autre règle. Formellement, cette relation se définie comme suit : Définition 11 : une règle r i est en relation de partage de variables compensation Post condition avec la règle r j (r i r j ) si et seulement si : output v V acri : v V pcrj 8.5 Le graphe d impacts Pour formaliser la gestion du changement d'un processus, la deuxième étape de gestion du changement du processus consiste à transformer l ensemble de règles ECAPE qui définit le processus ainsi que les différentes relations entre ces règles vers un graphe orienté appelé graphe d impacts. En effet, les 131

145 Contribution / Démarche de gestion du changement d un processus métier basée sur les règles sommets de ce graphe représentent les règles ECAPE, et les arcs représentent les relations entre les différentes règles. Pour cela, deux types d'arcs sont identifiés: les arcs de déclenchement qui correspondent aux différentes relations de déclenchements ; et les arcs de partage de variables qui correspondent aux différentes relations de partage de variables (voir la figure 8.10). Le graphe d impacts est défini formellement comme suit : Définition 12 : Un graphe d impacts est un graphe orienté G R = (R, Y) où : - L ensemble de sommets R représente l ensemble fini des règles ECAPE - L'ensemble des arcs Y représente les 11 relations qui existent entre les règles : (1) Y S est un sous ensemble de Y tel que si y S (r i, r j ), alors r i et r j sont en relation de déclenchement en série. (2) Y M est un sous ensemble de Y tel que si y M (r i, r j ), alors r i déclenche un ensemble de règles dont r j fait partie (déclenchement multiple). (3) Y Syn est un sous ensemble de Y tel que si y Syn (r i, r j ), alors r j est synchronisée par un ensemble de règles dont r i fait partie (déclenchement synchronisé). (4) Y A-C est un sous ensemble de Y tel que si y A-C (r i, r j ), alors r i et r j sont en relation de partage de variables Action - Condition. (5) Y CA-C est un sous ensemble de Y tel que si y CA-C (r i, r j ), alors r i et r j sont en relation de partage de variables Compensation - Condition. (6) Y A-A est un sous ensemble de Y tel que si y A-A (r i, r j ), alors r i et r j sont en relation de partage de variables Action - Action. (7) Y CA-A est un sous ensembles de Y tel que si y CA-A (r i, r j ), alors r i et r j sont en relation de partage de variables Compensation - Action. (8) Y A-CA est un sous ensembles de Y tel que si y A-CA (r i, r j ), alors r i et r j sont en relation de partage de variables Action - Compensation. (9) Y CA- CA est un sous ensemble de Y tel que si y CA- CA (r i, r j ), alors r i et r j sont en relation de partage de variables Compensation - Compensation. (10) Y A-PC est un sous ensemble de Y tel que si y A-PC (r i, r j ), alors r i et r j sont en relation de partage de variables Action Post condition. (11) Y CA-PC est un sous ensemble de Y tel que si y CA-PC (r i, r j ), alors r i et r j sont en relation de partage de variables Compensation Post condition. 132

146 Contribution / Démarche de gestion du changement d un processus métier basée sur les règles Figure 8.10 Le graphe de règle du processus de traitement de commande 8.6 L impact du changement d une règle Le changement d une règle peut entraîner le besoin de changer d autres règles qui sont affectées par le changement. Pour cela, la troisième étape de gestion du changement consiste à déterminer les règles impactées par un changement en se basant sur le graphe d impacts. En effet, l analyse de ce graphe permet de déterminer les voisins qui sont éventuellement affectés par un changement d un sommet (une règle). Notons qu un changement dans la logique du processus peut se traduire par le besoin de changer plusieurs règles ECAPE en même temps. Dans cette étape, nous recherchons à déterminer l impact du changement de chacune de ces règles par rapport à l ensemble de règles qui modélisent le processus. Par exemple, dans le processus de traitement de commande (vu dans le chapitre 6), si l entreprise décide de changer la logique du processus pour que les clients fidèles reçoivent un remise de 10 %. Cela se traduit par le besoin de vérifier que le client est fidèle avant la facturation. Ce changement du processus sera implémenté par l ajout d une nouvelle règle r 10 (règle de vérification du client fidèle) et la modification de l événement de déclenchement de la règle r 6 (règle de facturation). Dans ce cas de figure, nous cherchons à déterminer l impact de l ajout d une règle (r 10 ) et l impact de la 133

147 Contribution / Démarche de gestion du changement d un processus métier basée sur les règles modification de l événement de déclenchement de la règle de facturation (r 6 ) et cela afin de maintenir la cohérence du processus. Pour cela, l impact du changement d une règle sur le reste des règles du processus est fonction de trois facteurs (voir la figure 8.11): 1. Le type du changement : l ajout une règle à l ensemble de règles qui décrit le processus, n affecte pas de la même manière les règles existantes selon qu on supprime ou modifie une règle. 2. La partie de la règle ECAPE est l objet du changement. Par exemple la modification de l événement ou post événement d une règle affecte le déclenchement de certaines règles car les événements sont les éléments qui contrôlent le déclenchement des règles différentes du processus. Tandis que la modification de la post condition d une règle affecte les événements d erreurs de la même règle modifiée car ces derniers dépendent de la post condition. 3. La nature des relations avec la règle à changer. En effet, toutes les règles en relation de déclenchement avec la règle modifiée peuvent éventuellement être impactées par un changement si ce dernier porte sur les événements de déclenchements. Par ailleurs, les règles en relations de partage de variables peuvent éventuellement être impactées par un changement si ce dernier porte sur l action ou la compensation de la règle. Figure 8.11 les facteurs qui influencent l impact du changement 134

148 Contribution / Démarche de gestion du changement d un processus métier basée sur les règles Dans ce qui suit, nous allons détailler comment déterminer les règles impactées par un changement en utilisant le graphe d impact. Notons que, pour formaliser la détermination des ces règles impactées, nous allons utiliser les notations suivantes : Soit un graphe d impacts G R = (R, Y) et soit r i une règle telle que r i R k - on note Nrelation ( r i ) l ensemble des successeurs de k sauts où k est le k diamètre du G r à partir du sommet r i tel que rj Nrelation ( r i ), (r i, r j ) Y relation et relation {S, M, Syn, A-C, A-CA, A-PC, CA-C, CA-CA, CA-A, CA- PC}. Sachant qu un diamètre d'un graphe est la plus longue des distances entre deux sommets de ce graphe [Eul09]. Exemple : dans le graphe d impacts du processus de traitement de commande (figure 8.10), NS k ( r 5 ) = { r 6, r 7, r 8, r 9 }. - on note N + relation ( r i ) l ensemble des successeurs direct du sommet r i tel + que r j N relation ( r i ), (r i, r j ) Y relation et relation {S, M, Syn, A-C, A-CA, A-PC, CA-C, CA-CA, CA-A, CA-PC}. Exemple : dans le graphe d impacts du + processus de traitement de commande (figure 8.10), N S ( r 5 ) = { r 6, r 9 } car la règle r 5 est en relation de déclenchement en série avec r 6 et r 9. - on note N relation ( r i ) est l ensemble des prédécesseurs direct du sommet r i tel que r j N relation ( r i ), (r j, r i ) Y relation et relation {S, M, Syn, A-C, A- CA, A-PC, CA-C, CA-CA, CA-A, CA-PC}. Exemple : dans le graphe d impacts du processus de traitement de commande (figure 8.10), N S ( r 9 ) = { r 4, r 5, r 8 } car les règles r 4, r 5, et r 6 sont respectivement en relation de déclenchement en série avec la règle r L ajout d une règle En se basant sur le modèle ECAPE-M, la logique d un processus métier est décrite par un ensemble de règles ECAPE. L exécution d une action d une règle peut provoquer un événement qui active une ou plusieurs règles. Par conséquent chaque règle peut potentiellement déclencher une ou plusieurs autres règles. Ce déclenchement permet d implémenter les flux de contrôle d un processus. Si la logique de processus est modifiée de telle sorte qu une nouvelle règle est ajoutée à l ensemble existant et que l ordre de déclenchement est mis à jour pour qu une règle précédente déclenche la 135

149 Contribution / Démarche de gestion du changement d un processus métier basée sur les règles nouvelle règle et que cette dernière déclenche, à son tour, une autre règle successeur, alors nous considérons que cette mise à jour est implémentée par deux opérations de changement: ( ajouter une règle à l ensemble existant + modifier l ordre de déclenchement des règles existantes). Dans cette section nous nous intéressons à l impact de la première opération de changement, à savoir ajouter une règle. Nous considérons que l ajout d une règle à l ensemble des règles ECAPE n affecte aucune d entre elles car si le concepteur décide d ajouter une règle au processus, il doit spécifier les différents éléments de la règle ajoutée en prenant en compte la définition de règles existantes. La règle ajoutée sera déclenchée par des événements provoqués par les actions des règles existantes ou par des événements externes, et l action de la règle ajoutée pourra, à son tour, provoquer des événements qui déclenchent éventuellement d autres règles du processus. Par conséquent, la définition d une nouvelle règle va compléter les règles existantes plutôt que les impacter. Formellement, cela se définit comme suit : Règle de modification d ajout : Soit le graphe d impacts G R ( R, Y ). Si une règle r i est ajoutée à l ensemble R alors aucune règle ne sera impactée Dans l exemple du processus de traitement de commande (figure 8.10), l ajout d une règle r 10, qui permet de réduire le prix total de la commande de 10 % si le client est fidèle, n affecte aucune règle du processus. Cette règle va être déclenchée par un l événement «le prix total de la commande est calculé» provoquer par la règle r La modification d une règle Parce que les règles ECAPE (Evènement Condition Action Post condition post Evénements [Compensation ou Evénement d erreurs]) coopèrent ensemble en vue de modéliser un processus, la modification d une partie d une règle de cet ensemble peut impacter un sous ensemble des règles. Pour cela, dans cette section nous allons étudier comment la modification de chaque partie d une règle affecte les différentes règles ECAPE. 136

150 Contribution / Démarche de gestion du changement d un processus métier basée sur les règles Modification d événement d une règle L événement est utilisé pour déterminer quand une règle doit être déclenchée. En effet, lorsqu un événement se produit, un moteur évalue l ensemble de règles qui constituent le processus, pour exécuter les actions. L exécution de l action de chaque règle peut provoquer des post événements qui activent une ou plusieurs règles. Ainsi une séquence de déclenchement de règles peut être spécifiée en définissant des post-événements des prédécesseurs qui déclenchent les règles successeurs. Pour cela, si un événement d une règle est modifié, l ordre de déclenchement des règles peut être impacté. Une incohérence peut alors avoir lieu si l ordre de déclenchement se modifie alors que la règle modifiée exige la terminaison de plusieurs règles pour se déclencher. Pour cette raison, dans le graphe d impact, lors d une modification d une règle, si l ordre de déclenchement est modifié, alors le concepteur doit réviser la mise à jour effectuée pour faire en sorte que les règles des prédécesseurs directs de relations cause à effet (S(CE), M(CE), Syn (CE)) déclenchent la règle modifiée. Cela se justifie par la fait que la règle modifiée a besoin de la terminaison de toutes les actions de ces règles prédécesseurs pour se déclencher. Donc la modification de l ordre de déclenchement de la règle modifié et les règles de déclenchement prédécesseurs conduit à une incohérence. Notons que, dans ce cas de figure, une intervention humaine est nécessaire pour décider comment remodifier l événement de la règle pour prendre en compte le déclenchement des règles prédécesseurs de relations cause à effet et cela afin de conserver la cohérence du processus. Formellement, cela se définit comme suit : Règle de modification d événement : Soit le graphe d impact G R ( R, Y ) déduit après la modification de l événement e ri de la règle r i R dans le graphe de règle G R ( R, Y ),pour toutes règle r j R si rj ( NS( CE) ( ri ) NM ( CE) ( ri ) NSyn( CE) ( ri )), k k k r j ( N' S ( CE ) ( ri ) N' M ( CE) ( ri ) N' Syn( CE) ( ri )), alors réviser l événement modifié e de r j. ' ri ' ' Dans l exemple du processus de traitement de commande, si le concepteur décide de modifier l événement de déclenchement de la règle r 10 (ajoutée précédemment) pour devenir «le client est vérifié», alors, la règle r 10 sera déclenchée avant la règle r 5. Or l action de r 10 a besoin du prix total 137

151 Contribution / Démarche de gestion du changement d un processus métier basée sur les règles pour le prix de la commande de 10 % si le client est fidèle. Pour cela, la règle r 5 sera affectée par la modélisation de r 10 car ( N S ( CE) ( r 10 ) = { r 5 }. Donc le concepteur doit réviser l événement de la règle r 10 pour prendre en compte le déclenchement de r 5. Le nouvel événement de r 10 doit être «le prix total est calculé et le client est vérifié» Modification de la partie Condition La condition d une règle est un prédicat dont dépend l exécution de l action. En effet, lorsqu un événement se produit, la partie condition est vérifiée, si cette partie est satisfaite, alors la partie action est exécutée en tenant compte des attributs associés à la règle. Pour cela, la modification de la condition de la règle n affecte aucune autre règle car chaque condition ne concerne que la règle elle-même. Formellement, cela se définit comme suit : Règle de modification d une condition : Soit le graphe d impacts G R ( R, Y ), si une condition c ri de la règle r i est modifiée alors aucune règle ne sera impactée Dans l exemple du processus de traitement de commande, si l entreprise décide de modifier la condition de la règle du choix du livreur (r 3 ) pour prendre en compte les jours ouvrables (la date de livraison souhaitée {jours ouvrables}). Cette modification n a pas de conséquence sur les autres règles du processus car cette condition ne concerne que la règle r Modification de la partie Action L action d une règle spécifie les activités métier à exécuter si la condition est satisfaite. Au cours de cette exécution, des données peuvent être produites et des post événements peuvent être générés. Pour cela, la modification d une action peut impacter la manipulation de données utilisées par les autres parties des autres règles (conditions, actions, compensations ou post conditions des autres règles), et la génération des post événements qui déclenchent plusieurs règles. Pour cette raison, lors d une modification d une action, un concepteur doit réviser les règles qui sont en relation de partage de variables avec la règle modifiée car ces derniers utilisent des données produites par l action modifiée. En plus il doit réviser la post condition, la compensation et les post événements de la même règle et cela pour s assurer que (1) la post condition permet de contrôler l action modifiée, (2) la compensation correspond à une action équivalente à celle modifiée et (3) les post événements correspondent aux 138

152 Contribution / Démarche de gestion du changement d un processus métier basée sur les règles événements positionnés par l action modifiée. Formellement, cela se définit comme suit : Règle de modification d une action : Soit le graphe d impacts G R ( R, Y ), si l action a ri de la règle r i est modifiée alors : + - r j N A C ( r i ), la condition de la règle r j doit être révisée + - r j N A A ( r i ), l action de la règle r j doit être révisée + - r j N A CA ( r i ), la compensation de la règle r j doit être révisée + - r j N A PC ( r i ), la post condition de la règle r j doit être révisée En plus la post condition, la compensation et les post événements de la règle r i doivent être révisés Dans l exemple du processus de traitement de commande, si le concepteur décide de changer le type de la variable de sortie l action de la règle r 1 (règle de vérification de client), cela va impacter les règles r 2, r 3 et r 4 car ces dernières partagent la même variable avec cette action ( r2, r3, r4 N A + C ( r1 )). Le concepteur doit, donc, mettre à jour les conditions de ces règles pour qu elles correspondent au nouveau type choisi. Dans un deuxième exemple, si l entreprise décide d appeler le client par téléphone plutôt que lui envoyer la facture. Cela se traduit par la modification de l action de la règle r 6. Cette modification va affecter la règle r 7 puisque r 7 N A + A( r 6 ). Pour cela, la révision de la règle r 7 est nécessaire, par le concepteur, pour décider comment modifier l action de cette règle pour qu elle corresponde à la mise à jour effectuée. De plus, la post condition, la compensation et les post événements de la règle r 6 doivent être révisés car (1) la post condition de la règle r 6 doit contrôler l action modifiée, (2) la compensation de la règle r 6 doit correspondre à une action équivalente à l action modifiée et (3) les post événements de la règle r 6 doivent correspondre aux événements positionnés par l action modifiée (dans notre exemple le post événement est «client est contacté»). Notons que toute modification nécessaire pour maintenir la cohérence du processus suite à une mise à jour de l action d une règle est considéré comme un nouveau changement ; comme par exemple, la mise a jour de post événement de la règle r 6 suite a la modification de son action traitée comme un nouveau changement (voir modification de post événement d une règle) 139

153 Contribution / Démarche de gestion du changement d un processus métier basée sur les règles Modification de la partie compensation La compensation est lancée si la post condition est non satisfaite afin de défaire ou remplacer l exécution de l action d une règle. Pour cela, la modification de la compensation d une règle est traitée de la même manière que la modification de l action de la règle (vu dans la section précédente). En effet, une mise à jour d une compensation, oblige le concepteur à réviser les règles qui sont en relation de partage de variables avec la règle modifiée car ces derniers utilisent des données produites par l action modifiée. En plus l action, la post condition, et les post événements de la même règle doivent être révisés également afin d assurer la cohérence du processus. Formellement, cela se définit comme suit : Règle de modification d une compensation : Soit le graphe d impacts G R ( R, Y ), si compensation ca ri de la règle r i est modifiée alors : + - r j N CA C ( r i ), la condition de la règle r j doit être révisée + - r j N CA A ( r i ), l action de la règle r j doit être révisée + - r j N CA CA ( r i ), la compensation de la règle r j doit être révisée + - r j N CA PC ( r i ), la post condition de la règle r j doit être révisée En plus l action, la post condition, et les post événements de la règle r i doivent être révisés Modification de la partie Post-condition La post condition est un prédicat qui contrôle l exécution de l action d une règle en permettant de lancer, un mécanisme de compensation ou de déclencher des événements d erreurs et cela dans le cas où ce prédicat est non satisfait. Pour cette raison, la modification de la post condition d une règle oblige le concepteur à revoir la définition de la partie compensation et événements d erreurs de la règle modifiée car ces deux derniers dépendent de la condition de la validation de l action (post condition). Formellement, cela se définit comme suit : Règle de modification d une post condition : Soit le graphe d impacts G R ( R, Y ),si une post condition pc ri de la règle r i est modifiée alors : la compensation et les événements d erreurs de la règle r i doivent être révisés 140

154 Contribution / Démarche de gestion du changement d un processus métier basée sur les règles Dans l exemple du processus de traitement de commande, si l entreprise décide de modifier la post condition de la règle r 3 (choix de livreur) pour vérifier que la date de livraison proposée par le livreur ne dépasse pas la date de livraison exigée par le client. Dans le cas contraire, un nouvel événement d erreur doit s ajouter à la règle r 3 pour signaler ce problème Modification de la partie Post-événements/événements d erreurs Les post événements constituent l ensemble des événements déclenchés pendant ou après l exécution de la partie action de la règle. A leur tour, les événements d erreurs sont les événements qui peuvent être déclenchés pour signaler une anomalie de l exécution de l action d une règle. Ces deux ensembles d événements permettent de déclencher une ou plusieurs autres règles. Pour cela, la modification d un post événement ou d un événement d erreurs d une règle impacte les règles qui sont déclenchées par ces événements. Ces règles impactées correspondent aux règles successeurs direct de relations de déclenchement de la règle modifiée. Formellement, cela se définit comme suit : Règle de modification d une post événements/événements d erreur : Soit le graphe d impacts G R ( R, Y ),si une post événements pe ri ou un événement d erreur de la règle r i est modifié alors : r N r ) N ( r ) N ( r ), l événement de la règle r j doit être révisé j S ( i M i Syn i Dans l exemple du processus de traitement de commande, suite a la modification de l action de la règle r 6 (règle de facturation), le post événement doit être mis à jour pour de la règle prenne en compte les événements déclenchés par la nouvelle action. Suite à cette mise à jour, la règle r 7 et r 8 sont impactées car elles sont en relation de déclenchement avec la règle r 6 ({ r7, r8 } NS + ( r6 )). Pour cela le concepteur doit réviser les événements des ces deux règles La suppression d une règle Dans le modèle ECAPE-M, un ensemble de règles de réaction est utilisé pour modéliser un processus. Pour cela, les différentes règles de cet ensemble produisent des données et provoquent des événements qui déclenchent une ou 141

155 Contribution / Démarche de gestion du changement d un processus métier basée sur les règles plusieurs règles afin d accomplir l objectif du processus. Pour cette raison, la suppression d une règle peut affecter le déclenchement de l ensemble de règles et la production de données utilisées par les parties des autres règles (condition, action compensation, post condition). Par conséquent, si une règle est supprimée, alors le concepteur doit réviser toutes les règles qui sont en relation de partage de variables et en relation de déclenchement avec la règle supprimée. Formellement, cela se définit comme suit : Règle de suppression : Soit le graphe d impacts G R ( R, Y ), si la règle r i est supprimée alors : rj NS ( ri ) NM ( ri ) NSyn( ri ), l événement de la règle r j doit être révisé rj N A C ( ri ) NCA C ( ri ), la condition de la règle r j doit être révisée rj N A A( ri ) NCA A( ri ), l action de la règle r j doit être révisée r j N A CA( ri ) NCA CA, la compensation de la règle r j doit être révisée rj N A PC ( ri ) NCA PC ( ri ), la post condition de la règle r j doit être révisée Dans l exemple du processus de traitement de commande, si l entreprise décide de ne plus livrer ses articles, alors la règle r 3 sera supprimée. Suite à cette suppression l événement de la règle du calcul du prix total ( r5 NM + ( r3 )) doit être révisé pour tenir en compte de ce changement. En plus l action de cette même règle doit être révisée car elle utilise également une variable produite par l action de la règle supprimée r N ( )). ( 5 A + C r Synthèse Dans cette section nous avons présenté la troisième étape de gestion de changement qui consiste à déterminer l impact d une mise a jour d une règle ECAPE sur l ensemble des règles qui modélise un processus métier. En effet, cette détermination est faite en fonction de : Le type du changement (ajout, modélisation, suppression d une règle) ; de l objet du changement (Evénement, condition, action, compensation, post condition, post événements, événements d erreurs d une règle) et en fonction de la nature de relations entre la règle changée et les autres règles (déclenchement ou partage de variables). Le tableau suivant résume cette étape : 142

156 Contribution / Démarche de gestion du changement d un processus métier basée sur les règles 143

157 Contribution / Démarche de gestion du changement d un processus métier basée sur les règles 8.7 Le coût du changement d une règle L étape de détermination du l impact de changement d une règle permet d assister le concepteur dans la recherche des différentes règles qui ont besoin éventuellement d une modification car affectées par un changement. Dans le cas où le concepteur juge qu un changement d une partie est nécessaire pour garder la cohérence du processus, cela sera considéré comme un nouveau changement qui peut a son tour impacterd autres règles. Ainsi de suite jusqu'à effectuer tous les changements nécessaires de toutes les règles impactées. Pour cela, le changement d une règle peut générer une cascade de changements. Dans l exemple du processus de traitement de commande, si l entreprise décide de ne plus livrer ses articles, alors la règle r 3 sera supprimée. Suite à cette suppression l action de la règle r 5 (calcul du prix total) sera modifiée pour prendre en compte que le prix de livraison n est pas inclu dans le prix total. La modification de cette action va solliciter éventuellement d autres modifications pouvant provoquer une cascade de changements. Notons que la cascade de changement n est une conséquence de notre gestion du changement. En effet, tous les changements dans une cascade sont nécessaires pour préserver la cohérence du processus. Cependant, nous proposons, d évaluer l effort nécessaire du changement d une règle en calculant le nombre d opérations éventuelles pour changer toutes les règles de la cascade. On appelle cet effort le coût du changement d une règle. Pour cette raison, la quatrième étape de la gestion du changement consiste à estimer le coût du changement d une règle. Nous considérons ce coût comme le nombre de toutes les d opérations de changements éventuelles causées par le changement d une règle. Cette estimation représente, donc, un coût maximum d un changement d une règle. En effet, il est utile d indiquer au concepteur le coût maximum avant d effectuer un changement car cette indication peut l aider à prendre une décision lorsque plusieurs alternatives du changement se présentent, ou pour organiser la planification des ressources nécessaires pour implémenter le changement. Pour cela, l estimation du coût du changement d une règle se base sur un nouveau graphe d opérations dérivé du graphe d impacts appelé graphe d opérations de changements d une règle r i. Ce graphe est formellement défini comme suit : 144

158 Contribution / Démarche de gestion du changement d un processus métier basée sur les règles Définition 13 : Un graphe d opérations de changements d une G op = (Op, C) est un graphe orienté où : règle r i - L ensemble de sommets Op représente les 3 opérations de changements possibles : - Ajouter (r i ) : opération d ajout d une règle r i à l ensemble R - Modifier (r i, partie) : opération de modification de la partie p i de la + règle r i tel que p i { eri} { cri} Ari ACri { pcri} PsEri - Supprimer (r i ) : opération de suppression d une règle r i de l ensemble R - L'ensemble des arcs C représente la relation de déclenchement éventuelle entre deux opérations tel que : si c (op i, op j ), alors opération op i cause éventuellement l exécution de l opération op j. En effet, les sommets de ce nouveau graphe représentent les trois opérations de changements possibles : - Ajouter (règle r i ) : permet d ajouter une règle r i à l ensemble de règles ECAPE qui décrit le processus. - Modifier (règle r i, partie) : permet de modifier une partie de la règle r i cette permet peut concerner : l événement de déclenchement, la condition, l action, la compensation, la post condition, la post événements et les événements d erreurs d une règles. - Supprimer (règle r i ) : permet de supprimer une règle r i à l ensemble de règles ECAPE qui décrit le processus Notons que la racine de ce graphe est l opération initiale du changement qui impacte un sous ensemble de règles et qui provoque le déclenchement d une série d opérations éventuelles de mise à jour d une cascade de changement. Pour cela, les arcs du graphe d opérations de changements d une règle représentent les relations de déclenchements éventuelles entre deux opérations. En effet, ce déclenchement est déterminé en se basant sur le graphe d impacts et les différentes règles définies dans la section

159 Contribution / Démarche de gestion du changement d un processus métier basée sur les règles Figure 8.12 les différents graphes d opérations d ajout et de modification d une règle r i Par exemple, la modification d une action d une règle r i (opération modifier(règle r i, action)) déclenche éventuellement un ensemble d opérations (voir la figure 8.12 et figure 8.13et section ), comme l opération de modification des conditions des règles qui sont en relation de partage de + variables Action-Condition ( rj N A C ( ri ), Modifier( rj, crj ) ) et l opération de modifications d action des règles qui sont en relation de partage de variables + Action-Action ( rj N A A( ri ), Modifier( rj, arj ) ). Cette dernière opération déclenche, à son tour un ensemble d opérations éventuelles de changement. Ainsi de suite jusqu'à déclencher toutes les opérations de changement de toutes les règles impactées par l opération du changement d une règle (l opération racine du graphe). 146

160 Contribution / Démarche de gestion du changement d un processus métier basée sur les règles Figure 8.13 le graphe d opérations de suppression de la règle r i Notons que, comme l ajout d une règle r i et la modification d une condition d une règle n affectent aucune règle, l opération Ajouter (règle r i ) et l opération modifier (règle r i, condition) ne déclenchent aucune opération. En se basant sur le graphe d opérations de changements d une règle r i, on peut estimer le coût du changement de cette règle en calculant le nombre de sommets de ce graphe. Définition 14 : le coût du changement d une règle est le nombre de sommet du graphe d opérations de changements de cette règle Notons que le coût de changement d une règle s écrit sous forme d un triplet (n ajouts, n modifications, p suppressions) tel que n, m et p sont des nombres naturels. Cela permet de mettre en évidence les natures des opérations éventuelles car l effort nécessaire pour effectuer ces trois opérations n est pas le même. 147

161 Contribution / Démarche de gestion du changement d un processus métier basée sur les règles Figure 8.14 le graphe d opérations de suppression de la règle r 3 Dans l exemple du processus de traitement de commande, le coût de la suppression de la règle r 3, est calculé en se basant sur le graphe d opérations de suppression de cette règle. Pour cela, ce graphe est dérivé du graphe d impacts de ce processus (voir la figure 8.10) et de la règle de suppression vu dans la section En effet, cette suppression (opération supprimer(r 3 )) oblige le concepteur à réviser (et éventuellement modifier) les événements, les actions et les compensations de la règle r 5 car cette dernière et en relation de déclenchement (r 3 S(CE ) r 5 ) et de partage de variables (r 3 r 5 et r 3 r 5 ) avec la règle r 3. L estimation du coût maximum de la suppression r 3 suppose que le concepteur effectue toutes les modifications éventuelles. Pour cette raison, on considère que l opération supprimer(r 3 ) va déclencher trois autres opérations (modifier (règle r 5, événement), modifier (règle r 5, action) et modifier (règle r 5, compensation) ). Ces opérations déclencheront d autres opérations en fonction de la nature de l opération du changement et des relations existant entre les règles. Ainsi de suite jusqu'à construire le graphe d opérations de suppression de la règle r 3 (voir la figure 8.14). Le coût de suppression de la règle r 3 est, donc, le nombre de sommet de ce graphe. Pour cela ce coût est égal : Le coût de suppression de la règle r 3 = (0 ajout, 9 modifications, 1 suppression). 148

162 Contribution / Démarche de gestion du changement d un processus métier basée sur les règles Notons finalement que, le coût idéal d un changement d une règle est égal à une opération car dans ce cas, le changement à effectuer nécessite qu une seule opération qui représente le changement initial, et que cette opération ne déclenche aucune autre opération. 8.8 Le degré de tolérance aux changements d un processus La dernière étape de gestion du changement consiste à estimer le degré de tolérance aux changements d un processus. En effet, cette métrique permet d évaluer le degré de stabilité d un processus, lors d un changement, en estimant à quel point les changements peuvent influencer les différentes règles du processus. Pour cela, ce degré représente le coût moyen des operatons «ajouter», «modifier» et «supprimer» une règle. En se basant sur ce degré de tolérance, un concepteur peut améliorer la modélisation du processus pour que les règles soient moins impactées par un changement. Formellement ce degré de tolérance aux changements d un processus se calcule comme suit : Définition 15 : le degré de tolérance aux changements d un processus modélisé par un ensemble de règles R, noté ζ ( process) est calculé comme suit : ζ ( process) = ( r R i Ajouter(r ) r R i i i, ( r R) ( p i p i Modifier( ri, pri ) { e } { c } A AC { pc } i { e } { c } A AC { pc } ri i ri ri ri ri ri ri ri ri PsE ri + ri PsE r R j + ri j ), r R i Suppression r R i i ( r ) i ) Idéalement, le degré de tolérance aux changements vaut (1 ajout, 1 modification, 1 suppression) car dans ce cas, le changement de chaque règle du processus nécessite qu une seule opération qui représente le changement initial, et cette opération ne déclenche aucune autre opération. Le degré de tolérance aux changements du processus de traitement de commande de l exemple précédant, est égal à (1 ajout, 2.89 modification, 4.33 suppression) car le coût moyen de l ajout d une règle vaut une seule opération; le coût moyen de la modification des différentes parties des différentes règles de ce processus vaut 2.89 opérations ; le coût moyen de la suppression des différentes règles du processus vaut 4.33 opérations. 149

163 Contribution / Démarche de gestion du changement d un processus métier basée sur les règles Ces résultats montrent que notre modélisation du processus de traitement de commande ne tolère pas vraiment le changement, spécialement la suppression des règles. Cela s explique par l existence d un nombre important de relations notamment les relations de partage de variables Action-Action qui conduit à un coût de changement conséquent car la modification d une action peut déclencher plusieurs opérations de mise a jour des sous parties des règles qui sont en relation de partage de variables Action-Action avec la règle changée. Parmi ces sous parties, on trouve l action de l autre règle qui peut déclencher à son tour des opérations de changement des autres sous parties des autres règles...etc. Grace à l analyse du degré de tolérance on peut définir des règles de bonne modélisation d un processus décrit par un ensemble de règles ECAPE. Par exemple minimiser le partage de variables entre les différentes règles spécialement entre les actions des règles. Notons finalement que le coût moyen pour l ajouter d une règle dans un processus est toujours égal à une opération car l ajout d une règle n affecte aucune autre règle (voir la section 8.6.1). 8.9 Conclusion Dans ce chapitre, nous avons présenté une démarche pour gérer le changement d une règle dans le modèle ECAPE-M. Cette démarche consiste à définir les relations entre les différentes règles, et puis traduire l ensemble de règles et relations en un graphe orienté appelé graphe de règle. L analyse de ce graphe permet de déterminer l ensemble de règles impactées par un changement et cela en fonctions de trois facteurs : le type du changement, l objet du changement et la nature des relations qui existent entre la règle à changer et les différentes règles du processus avec les quelles elle est en relation. Dans le but de quantifier l effort maximum pour mettre en œuvre le changement d une règle, nous avons proposé d estimer le coût de changement d une règle en terme de nombre d opérations de changement. Pour cela, un nouveau graphe, dérivé du graphe d impacts, est utilisé pour construire les opérations de mise à jour éventuelles (ajouter, supprimer, modifier) provoquées par un changement d une règle. Finalement, notre démarche de gestion du changement propose une métrique, appelée degré de tolérance aux changements, qui permet d indiquer 150

164 Contribution / Démarche de gestion du changement d un processus métier basée sur les règles le degré de stabilité d un processus vis à vis un changement. Pour cela ce degré est calculé en fonction du coût moyen de changement des différentes règles du processus. Ce qui nous permet d améliorer la modélisation du processus afin de minimiser l impact du changement d une règle sur l ensemble du processus. Parce que, la fiabilité d un processus est une question primordiale pour une entreprise, nous allons présenter dans le chapitre suivant, comment on peut vérifier formellement le modèle ECAPE-M et le langage ECAPE-L par un nouveau réseau de Pétri appelé ECAPE net. 151

165 Contribution / La vérification du processus métier par le ECAPE net 9 Vérification du processus métier par le ECAPE-net 9.1 Introduction 9.2 Le ECAPE-net Les éléments du ECAPE-net Définition formelle du ECAPE-net Les règles de franchissement des transitions dans le ECAPE-net La construction des événements composés Exemple illustratif 9.3 La vérification d un processus par le ECAPE-net Les propriétés du réseau bien structuré Les propriétés de la sureté du réseau 9.4 Conclusion 9.1 Introduction Les entreprises doivent se baser sur des processus métier robustes et fiables pour mener à bien leurs missions. La fiabilité des processus est une question primordiale car un processus erroné peut avoir, pour une entreprise, des conséquences graves sur le plan économique. En effet, en utilisant le modèle ECAPE-M, le concepteur n est pas à l abri de commettre des erreurs fonctionnelles (exemple d erreurs). Pour cela, la vérification formelle de la définition des processus est utile pour s assurer du bon fonctionnement du processus. Pour cette raison, nous avons fait recours aux modèles formels pour détecter les éventuelles erreurs fonctionnelles dans une définition ECPAE-M. L objectif de l utilisation des modèles formels est double : (1) décrire la sémantique d exécution du modèle ECAPE-M en éliminant les contradictions et les ambiguïtés (spécification formelle) et (2) minimiser les risques qu un dysfonctionnement se produise en se basant sur les propriétés de vérification offertes par ses modèles (vérification formelle). Parmi les différents modèles formels proposés dans la littérature, nous avons opté pour les réseaux de Pétri (RdP) en raison de leur grande capacité à modéliser la sémantique de l'exécution des processus métier [Van02]. En outre, le RdP offre une large panoplie de propriétés qui peuvent être utilisées pour 153

166 Contribution / La vérification du processus métier par le ECAPE net analyser le bon fonctionnement d un processus. Cependant, parmi plusieurs RdP proposés [Van98, Ouy05, Yan05, Bou07] quel réseau est le plus apte à modéliser la sémantique de notre modèle ECAPE-M? Comme nous avons vu dans la partie état de l art, chapitre des techniques de vérification de processus métier (voir chapitre 5, section 5.5), les réseaux de pétri classiques (tel que WF-nets [Van98]) et les réseaux de Pétri colorés (tels que le RdP de Yang et al. dans [Yan05] et le RdP de Boukadi et al. dans [Bou07]) ne permettent pas de modéliser le comportement d exécution du modèle ECAPE-M car dans ces derniers réseaux, lorsque toutes les conditions nécessaires sont satisfaites, la transition peut être tirée mais pas nécessairement. Tandis que, dans un système réactif (en l occurrence le modèle ECAPE-M), une transition doit obligatoirement être tirée. Pour répondre à cette limitation, Eshuis et al. proposent, dans [Esh03], un RdP réactif qui change la façon avec laquelle la transition devrait être tirée en exigeant que la transition soit tirée si les conditions sont satisfaites. A leur tour, Li et al proposent dans [Li04] un nouveau réseau de Pétri coloré, appelé Conditional Colored Petri Net (CCPN) permettant de modéliser les règles ECA dans les systèmes de base de données actives. L'originalité de ce réseau de Pétri est la définition de nouveaux types de places et de nouveaux types de transitions pour permettre la spécification des événements composés. Cependant, le RdP réactif d Eshuis et al. ainsi que le réseau CCPN ne suffisent pas pour modéliser notre modèle ECAPE-M car ce dernier s appuie sur le nouveau formalisme de règles ECAPE qui définit de nouveaux éléments tels que les post événements et les compensations. Nous proposons dans ce chapitre, un nouveau réseau de Pétri coloré appelé ECAPE-Net. Ce dernier s inspire des réseaux CCPN construit à base d événements composés, pour permettre de modéliser formellement la sémantique d exécution de notre modèle de processus basé sur les règles, ainsi que la vérification du bon fonctionnement du processus. 154

167 Contribution / La vérification du processus métier par le ECAPE net 9.2 Le ECAPE-net Les éléments du ECAPE-net Le ECAPE-net est un réseau de Pétri coloré qui modélise la séquence d'exécution de l ensemble de règles ECAPE qui décrit la logique d'un processus métier. En effet, dans le ECAPE-net, une règle est représentée comme suit (voir figure 9.1): événement de déclenchement d une règle est représenté par une place d entrée ; événements déclenchés par l exécution d une action ou une compensation d une règle sont représentés une place de sortie. À son tour, l'action et la compensation d une règle sont représentées par les transitions. Finalement, les conditions et post conditions d'une règle sont attachées aux transitions. Figure 9.1 Modélisation d une règle ECAPE dans un Pétri ECAPE-net La sémantique d exécution d un ECAPE-net est la suivante : si une place contient un jeton (une place est marquée) cela signifie que l événement représenté par cette place s est produit. Dans ce cas, la transition qui représente l action d une règle est tirée si la condition attachée à cette transition est satisfaite. Après le franchissement d une transition, si la post condition attachée à la transition tirée est vraie alors, un jeton se positionnera dans la place qui représente le post événement de l action représentée par la transition tirée. En revanche, si la post condition attachée à la transition d action est fausse alors, (1) soit un jeton se positionnera dans la place qui représente l événement d erreur, (2) soit la transition qui représente 155

168 Contribution / La vérification du processus métier par le ECAPE net la compensation est tirée dans le but de remplacer, si possible, l effet de l action de la règle. Après le franchissement de cette transition de compensation, un jeton se positionnera dans la place qui représente le post événement de la compensation. Cependant, dans le modèle ECAPE-M vu dans le chapitre 6, l événement peut être primitif ou composé. De plus, l action et la compensation des règles sont exécutées en utilisant un ensemble d instructions prédéfinies (EXECUTE, DISCOVER, SKIP, etc. voir chapitre7). Pour cette raison, nous avons défini de nouveaux éléments dans notre ECAPE-net pour nous aider à construire les événements composés et les événements primitifs et à modéliser les différentes instructions des actions et compensations. Figure 9.2 Eléments du réseau de Pétri ECAPE-net La figure 9.2 illustre les éléments du ECAPE-net. Ce réseau est composé de cinq types de places, deux types de transitions et de deux types d'arcs: - Place primitive : représente un événement primitif; - Place composée : représente un événement composé; - Place intermédiaire : utilisé spécialement pour le constructeur d événements ANY(m, e 1, e 2,..., e n ) qui permet de spécifier m événement parmi l ensemble {e 1, e 2,..., e n } qui se sont produits ; - Place de début : représente le premier événement qui déclenche l'exécution du processus ; 156

169 Contribution / La vérification du processus métier par le ECAPE net - Place de fin : représente le dernier événement qui provoque la fin de l'exécution des processus ; - Transition composée : utilisée pour générer un événement composé à partir d un événement primitif ; - Transition d action: représente les instructions d une action d une règle; - Transition de compensation : représente les instructions compensation qui remplacent l effet de l action de la règle. - Arc normal: représente le contrôle de flux du processus - Arc Inhibiteur: utilisé spécialement pour le constructeur d événement Not (e 1, t) qui permet de caractériser le fait qu un événement ne s est pas produit dans un intervalle de temps t Définition formelle du ECAPE-net Un ECAPE-net est défini formellement par le 11-tuplets suivants : ECAPE Net = (, P, T, A, C, W, Activity, Cond, PstCond, D, τ ) avec : - est un ensemble fini de types ou encore un ensemble de couleurs (colour sets). Généralement, on utilise la couleur pour les places (une place possède une couleur), et on attribue des types pour les variables du processus. - P est un ensemble fini de places qui modélisent les événements de règles. L ensemble P est composé de trois sous ensembles : P = P prim P comp P inter tel que P prim, P comp et P inter représentent respectivement les ensemble des places primitives, composées et intermédiaires. A leur tour, P star et P end représentent respectivement les ensembles des places de début et les place de fin tel que P star P prim et P end P prim. - T est un ensemble fini de transitions qui est composé de deux sous ensembles : T = T comp T action T compensation tel que T comp, T action et T compensation représentent respectivement les ensembles des transitions d action et de compensation, tu as trois sous-ensembles mais l explication ne porte que sur deux sous-ensembles. A son tour, l ensemble T action T compensation est composé de cinq sous ensembles T action = T Execute T Discover T Skip T Cancel T Copy tel que T Execute, T Discover, T Skip, T Cancel et T Copy représentent respectivement les ensembles des transitions EXECUTE, DISCOVER, SKIP, CANCEL et COPY. - A est un ensemble d arcs qui relie une place à une transition, ou une transition à une place tel que A (PxT) (TxP). L ensemble A est 157

170 Contribution / La vérification du processus métier par le ECAPE net composé de deux sous ensembles : A = A norm A inhi tel que A norm et A inhi représentent respectivement l ensemble d arcs normaux et l ensemble d arcs inhibiteurs. - C est la fonction de couleur permettant d affecter une couleur unique à chaque place. La couleur du jeton d une place p est dénoté C(p). Donc C est défini de P dans tel que : p P, C( p) : C( p) Σ - W est la fonction qui détermine pour chaque arc les jetons qu il consomme ou qu il produit tel que : a A, Type(var( W ( a)) = C( p( a)) où la fonction Type (var( W ( a)) Σ détermine les types de variable dans un arc. En effet, la première partie de cette formule exprime que les types de variables d un arc doivent être compatibles avec les couleurs de la place d entrée ou de sortie. La seconde partie de cette formule exprime que les types de jetons doivent appartenir aux couleurs de ECAPE-net. - Activity est la fonction donnant à chaque transition d action ou de compensation (T action ou T compensation ) un nom. - Cond est une fonction condition qui définie l ensemble de transitions dans (ou vers) une expression booléenne tel que: t T, type( Cond( t)) = boolean ou cond(t) - PstCond est une fonction condition qui est définie de l ensemble de transition d actions dans (ou vers) une expression booléenne tel que: t Taction, type( Cond( t)) = boolean - D est une fonction d'intervalle de temps qui est définie de T comp dans un intervalle de temps [d 1, d 2 ]. - τ est une fonction horloge qui assigne à chaque jeton d une place p l heure correspondant à l occurrence de l évènement possible. τ est exprimée en sous la forme année : mois: jour - heure: minute: seconde. Par exemple, l heure d un jeton = 2009: 02: 06-18: 46: 16. Notons que, dans le ECAPE-net, un jeton est le 4-tuplets (p, c, data, timestamp) où p P, c C(p), data sont les données métier associées au jeton, et timestamp spécifie l'heure de dépôt du jeton dans la place p. Après avoir donné une définition formelle de notre ECAPE-net, nous allons expliquer, dans la section suivante, les règles de franchissement des trois transitions composées, d action et de compensation. Notons finalement que pour formaliser la définition de ces règles de franchissement nous allons utiliser les ensembles et fonctions suivantes : 1. M est la fonction de marquage du réseau, qui est définie de P dans N (ensemble des nombres naturels) pour affecter à chaque place un 158

171 Contribution / La vérification du processus métier par le ECAPE net certain nombre de jetons. On note M 0 le marquage initial (état initial) dans un ECAPE-net. On note M f, le marquage final (état final) de ce réseau. M(p) est la fonction de marquage d une place p définie de P dans N pour spécifier le nombre de jetons dans la place p à l'état donné. L'état du réseau peut changer en fonction du changement du nombre de jetons durant l'exécution du réseau. En effet, un marquage M n à l état n est dit accessible à partir de M 1 (dénoté M1 M * n ) si et seulement s il existe une séquence de franchissement σ = t1 t2... tn 1tel que M1 M σ n 2. Nous définissons les cinq ensembles suivants : - t est l ensemble de places d entrées de la transition t tel que t = { p P : ( p, t) A}. - n t est l ensemble de places d entrée de la transition t qui sont reliées par des arcs normaux avec la transition t tel que nt = { p P : ( p, t) A norm }. - i t est l ensemble de places d entrée de la transition t qui sont reliées par des arcs inhibiteurs avec la transition t tel que i t = { p P : ( p, t) A inhi }. - t est l ensemble de places de sorties de la transition t tel que t = { p P : ( t, p) A}. - p est l ensemble de transitions de sorties de la place P tel que p = { t T : ( p, t) A}. 3. Finalement, dans un ECAPE-net une séquence de nœud n 1, n2,..., nk (dénoté S) est une connexion du nœud n 1 (une place ou transition) jusqu au nœud n k tel que ni, ni+1 A. Notons qu une séquence est appelée élémentaire si chaque nœud est unique Les règles de franchissement des transitions dans le ECAPE-net Les règles de franchissement des transitions composées Une transition composée est utilisée pour générer un événement composé. Pour cela, cette transition est tirée si et seulement si les trois conditions suivantes sont satisfaites : (1) il y a au moins un jeton dans toutes ses places d'entrées, (2) la somme de tous les jetons dans toutes les places d'entrées est plus que l expression des arcs normaux qui relient toutes ces places à la 159

172 Contribution / La vérification du processus métier par le ECAPE net transition composée en question et (3) toutes les conditions attachées à la transition composée sont vraies. Formellement, une transition composée est tirée si et seulement si : 1- p n tcomp, M ( p) 1 2- p P, M ( p) W ( p, tcomp ) 3- Cond(t comp ) = vrai Notons que la transition composée est également tirée quand il n y a aucun jeton, durant l'intervalle de temps [d 1, d 2 ], dans les places d'entrée qui sont connectés avec cette transition par des arcs inhibiteur. Formellement, une transition composée est tirée également si et seulement si: d [ d1, d2], p i tcomp, M ( p) Les règles de franchissement des transitions d action Une transition d'action est utilisée pour représenter les instructions d une action dans une règle. Pour cela cette transition est tirée si les deux conditions suivantes sont satisfaites : (1) il y a au moins un jeton dans toutes ses places d'entrées, et (2) toutes les conditions et post-conditions qui sont attachées à la transition en question sont vraies. Formellement, une transition d'action est tirée si et seulement si: 1- p taction, M ( p) 1 2- Cond(t action ) = PstCond(t action ) = vrai Cependant, les transitions SKIP T Skip et (qui permettent de sauter l exécution d une activité donnée) les transitions CANCEL T Cancel (qui permettent d annuler l exécution de toutes les instances d une activité donnée) ont une sémantique d exécution particulière. En effet, la transition CANCEL est attachée à une transition EXECUTE, cela signifie que si la transition CANCEL est tirée alors, tous les jetons de toutes les places d'entrée de sa transition EXECUTE attachées sont supprimés. De cette façon, la transition CANCEL désactive la transition EXECUTE (voir la figure 9.3). À son tour, la transition SKIP est également attachée à une transition EXECUTE. Si la transition SKIP est tirée alors, tous les jetons de toutes les places d'entrée de sa transition EXECUTE attachée sont supprimés et un jeton est ajouté dans toutes les places de sortie de cette dernière transition d exécution. De cette façon, la transition SKIP saute la transition EXECUTE (voir la figure 9.3). 160

173 Contribution / La vérification du processus métier par le ECAPE net Figure9.3 Patrons des transitions CANCEL and SKIP Les règles de franchissement des transitions de compensation Une transition de compensation est utilisée pour représenter les instructions d une compensation d une règle. Pour cela, cette transition est tirée si toutes les post-conditions qui sont attachées à la transition en question sont fausses. Formellement, une transition d'action est tirée si et seulement si: PstCond(t action ) = faux La construction des événements composés Dans le modèle ECAPE-M, un événement est un élément activateur d une règle. Cet élément est représenté par une place dans le ECAPE-net où un jeton représente l occurrence de l événement. Cependant, dans le modèle ECAPE-M, l événement peut être primitif ou composé et cela afin de pouvoir exprimer toutes les situations qui se sont produites et pour laquelle une réaction est nécessaire. Pour cette raison, nous allons présenter dans cette section, de nouveaux éléments ajoutés dans notre ECAPE-net pour nous aider à construire les événements composés: Construction de la conjonction d événements La conjonction d événements ( e1 e2) exprime que les deux e 1 et e 2 ont lieu sans tenir compte de leur ordre d arrivée. Figure 9.4 illustre la construction d une conjonction d événements en utilisant une transition composée. En effet, cette transition est tirée lorsque les deux places qui représentent e 1 et e 2 sont marquées. Après le tir de la transition composée, la place composée e c est marquée. 161

174 Contribution / La vérification du processus métier par le ECAPE net Figure9.4 Construction de la conjonction d événements dans ECAPE-net Construction de la disjonction d événements La disjonction d événements ( e1 e2) exprime qu au moins l un des deux événements e 1 ou e 2 est détecté. Figure 9.5 illustre la construction d une disjonction d événements en utilisant une transition composée. En effet, une des deux transitions composées est tirée lorsqu une des places e 1 ou e 2 est marquée. Après le franchissement de l'une des deux transitions composées, la place composée e c est marquée. Figure9.5 Construction de la disjonction d événements dans ECAPE-net Construction de l événement NOT L événement e1in[ d1, d 2] caractérise le fait qu un événement ne s est pas produit dans un intervalle du temps [d 1, d 2 ]. Figure 9.6 illustre la construction d un événement NOT en utilisant une transition composée et un arc inhibiteur. En effet, cette transition composée est tirée lorsque la place e 1 n'est pas marquée dans l'intervalle du temps [d 1, d 2 ]. Après le franchissement de la transition composée, la place composée e c est marquée. 162

175 Contribution / La vérification du processus métier par le ECAPE net Figure9.6 Construction de l événement NOT dans ECAPE-net Construction d une séquence d événements Une séquence d événements (seq(e 1, e 2 )) exprime la succession de deux événements tels que l événement e 1 se produit avant l'événement e 2. La figure 9.7 illustre la construction d une séquence d événements en utilisant une transition composée. En effet, cette transition est tirée lorsque les places e 1 et e 2 sont marquées et que la condition τ ( e1 ) < τ ( e2) est satisfaite. Après le franchissement de la transition composée, la place composée e c est marquée. Figure9.7 Construction d une séquence d événements dans ECAPE-net Construction d une simultanéité d événements Une simultanéité d événements (sim(e 1, e 2 )) exprime une succession de deux événements tel que l événement e 1 se produit en même temps que l'événement e 2. Figure 9.8 illustre la construction d une simultanéité d événements en utilisant une transition composée. En effet, cette transition est tirée lorsque les places e 1 et e 2 sont marquées et que la condition τ e ) = τ ( ) est satisfaite. ( 1 e2 163

176 Contribution / La vérification du processus métier par le ECAPE net Après le franchissement de la transition composée, la place composée e c est marquée. Figure9.8 Construction d une simultanéité d événements dans le ECAPE-net Construction de multi-occurrences d un événement Une multi-occurrences d un événement (OCC(n, e 1 ) in[d 1, d 2 ]) exprime que l événement e 1 se produit n fois dans l'intervalle du temps [d 1, d 2 ]. La figure 9.9 illustre la construction d une multi-occurrences en utilisant une transition composée. En effet, cette transition est tirée lorsque la place e 1 est marquée par n jetons dans l'intervalle de temps [d 1, d 2 ]. Après le franchissement de la transition composée, la place composée e c est marquée. Figure9.9 La construction d une multi-occurrence d un événement dans ECAPE-net Construction d un événement ANY L événement ANY (m, e 1, e 2,, e n ) exprime m événements parmi l ensemble {e 1, e 2,..., e n } qui se sont produits tel que m < n. La figure 9.10 illustre la construction d un événement ANY en utilisant n transitions composées et une place intermédiaire. En effet, les n transitions composées sont tirées lorsque les places e 1, e 2,..., e n sont marqués. Chacune de ces n transitions vont marquer la 164

177 Contribution / La vérification du processus métier par le ECAPE net place intermédiaire e i. Cette dernière est limitée par m jetons. Cela veut dire que les m premiers jetons (qui modélisent les occurrences d événements) permettront de tirer la dernière transition composée et de générer, ensuite, l'événement composite e c en marquant sa place. Figure9.10 Construction d un événement ANY dans ECAPE-net Exemple illustratif Pour illustrer la sémantique d exécution d un ECAPE-net, nous présentons, dans cette section le processus de traitement de commande vu dans les chapitres précédents. Rappelons que, les événements de ce processus sont représentés, dans ce réseau, par des places. Les événements composés sont construits en utilisant les transitions composées. À leur tour, les actions et les compensations de chaque règle sont représentées en utilisant les transitions d'action et les transitions de compensation. Enfin, les conditions et les post conditions sont attachées aux transitions d action (voir la figure 9.11). 165

178 Contribution / La vérification du processus métier par le ECAPE net Figure9.11 Le ECAPE-net du processus de traitement de commande A la réception d une commande (événement de déclenchement du processus), un premier jeton se positionne dans la place «réception de commande». Cette place est appelée «place de début» car elle déclenche l exécution du réseau. Après le marquage de cette place de début, la transition 166

179 Contribution / La vérification du processus métier par le ECAPE net d action de la règle r 1 «exécuter la vérification de l enregistrement du client dans la base de données» est tirée et cela si la condition attachée à cette transition «les informations de la commande sont valides» est vraie. Après le franchissement de l action «exécuter la vérification du client», un jeton est positionné dans la place de post-événement de cette action «le client est vérifié» et cela si sa post condition attachée «la connexion à la base est donnée est correcte» est vraie. En revanche, si cette post condition est fausse, un jeton se positionne dans la place d événement d erreur «échec de la connexion à la base de données».ca serait bien d avoir des bouts de ton reseau pour montrer les changements Lorsque la place de l événement «le client est vérifié» est marquée, et si la condition «le client est enregistré dans la base» est vraie, alors les deux transitions d'action, qui représentent respectivement l'action du calcul du prix initial de la règle r 2 et l'action de sélection d un livreur de la règle r 3, sont tirées. En raison de ce franchissement, un jeton est placé dans chaque place de sortie de ces deux transitions d'action et cela si les post condition attachées à ces transitions sont vraies. En revanche, si les post condition attachées à ces transitions sont fausses, alors les transitions de compensation «choisir un autre service de calcul» et «choisir un autre livreur» sont tirées pour remplacer les actions des règles r 2 et r 3. Après le franchissement de ces transitions de compensation, un jeton se positionnera dans chaque place de sortie qui représente le post événement de la compensation. Pour calculer le prix total, l'action du calcul du prix initial et l'action de sélection d un livreur doivent être exécutées. Pour cette raison, la transition du calcul du prix total est tirée lorsque la place qui représente la conjonction de deux événements de fin d exécution du calcul du prix initial et de sélection d un livreur est marquée. Cette place composée est construite en utilisant une transition composée. En effet, cette transition est tirée lorsque les deux places qui représentent l événement «prix initial est calculé» et l événement «livreur est choisi» sont marquées. Après le tir de la transition composée, la place composée «prix initial est calculé livreur est choisi» est marquée. Au fur et à mesure, les transitions d actions (ou de compensation) sont tirées si les places d entrée sont marquées et si les conditions attachées sont vraies. Après le franchissement des ces transitions, des jetons se positionnent dans les places de sortie si les post condition attachées sont vraies. Dans le cas contraire, des jetons se positionnent dans les places d erreurs ou les transitions de compensations sont tirées, ensuite des jetons se positionnent dans les places de sortie de ces transitions de compensation. Les jetons continuent à se 167

180 Contribution / La vérification du processus métier par le ECAPE net déplace dans le réseau jusqu'à arriver à une place de fin qui représente l'événement de fin du le processus. Le ECAPE-net ne se limite pas à modéliser la sémantique d exécution du modèle ECAPE-M. En effet, ce réseau permet vérifier le bon fonctionnement du processus. Pour cette raison, nous expliquons en détail, dans la section suivante, comment vérifier un processus en analysant ECAPEnet. 9.3 La vérification du processus par le ECAPE-net L'objectif de la vérification formelle est d'assurer que la définition du processus ne contient pas d erreurs (la définition est correcte). Dans notre travail, nous proposons de réaliser cette vérification en réécrivant la spécification du processus en utilisant un ECAPE-net. Le réseau obtenu sera analysé afin de vérifier certaines propriétés. On peut ainsi détecter les erreurs en tenant compte des propriétés détectées. Selon Van der Aalst et al. dans [Van98] un réseau de Pétri fonctionne correctement si un ensemble de propriétés specifiques est satisfait. Ces propriétés peuvent être classée en deux grandes catégories : (1) les propriétés liées à la structure d un réseau, on parle alors de propriétés du réseau bien structuré (well structuredness Petri net), et (2) les propriétés liées à l aspect dynamique du réseau de Pétri, on parle alors de propriétés de sûreté d un réseau de Pétri (Soundness Petri net). Dans cette section, nous vérifions un ECAPE-net par rapport a ces deux catégories de propriétés Propriétés du réseau bien structuré Les propriétés du réseau bien structuré est proposée dans le travail [Van98] pour formaliser le besoin d assurer que le réseau de Pétri est bien formé. Comme par exemple, le besoin de vérifier que, dans le WF-net, chaque connecteur du choix (OU, ET, etc) est suivi par le connecteur de jointure correspondant [Van98]. Les propriétés utilisées dans [Deh05] pour vérifier que 168

181 Contribution / La vérification du processus métier par le ECAPE net le diagramme d activité UML et le code BPEL sont bien formés, est un autre exemple de propriétés de réseau bien structuré. Dans notre ECAPE-M, un processus est décrit par un ensemble de règles ECAPE ou chaque règle est définie par un événement, une condition, une action (une compensation), une post condition et un post événement (événement d erreur). L enchainement de ces règles permet de spécifier le comportement du processus. Pour cette raison, les propriétés du ECAPE-net bien structuré est caractérisée par trois propriétés : (1) la propriété du réseau régulier, (2) la propriété du réseau complet et (3) la propriété de la satisfiabilité des conditions Propriété du réseau régulier Un ECAPE-net est régulier si les deux conditions suivantes sont vérifiées : (1) Un ECAPE-net a au moins une place de début p start et au moins une place de fin p end, (2) chaque nœud d un ECAPE-net appartient à une séquence qui commence par une place de début et qui se termine par une place de fin. Formellement, la propriété du réseau régulier est respectée si les deux conditions suivantes sont vérifiées : (1) P start P end Ø (2) n P T, S tel que n S p S p S Propriété du réseau complet Un ECAPE-net est complet si chaque place (ou transition) du réseau est liée à au moins une transition (ou place) à l exception de la place de début et la place de fin. Formellement, la propriété du réseau complet est respectée si les deux conditions suivantes sont vérifiées : (1) p P Pend, t T tel que t p t T, p P P tel que p t (2) start start Propriété de satisfiabilité des conditions La propriété de satisfiabilité des conditions (noté ) suppose que (1) chaque condition (et post condition) attachée à une transition est satisfiable, et (2) la satisfiabilité de la conjonction des prédicats des conditions et des post conditions attachées aux transitions qui forment une séquence dans le réseau. Formellement, la propriété de la satisfiabilité des conditions est définie comme suit : (1) t T, (t) (2) s Sequences, Cond et PstCond (t) end 169

182 Contribution / La vérification du processus métier par le ECAPE net Le ECAPE-net du processus de traitement de commande vu est bien structuré, parce qu il est régulier et complet. De plus, Le réseau de Pétri de ce processus respecte la propriété de la satisfiabilité des conditions, car pour chaque séquence de ce réseau, la conjonction des conditions et post conditions attachées aux transitions d action de la séquence est satisfiable. Comme par exemple la conjonction des conditions et post conditions de la séquence de transitions suivante <t vérification du client, t calcul du prix initial, t composeé, t calcul du prix total > est satisfiable car la conjonction suivante (la commande est validée) (la connexion à la base de données est correcte) (le client est enregistré) (le prix initial est supérieur à zéro) ( τ ( e1 ) < τ ( e2)) (la date de livraison correspond au besoin de client) (le prix total est supérieur à zéro) Propriétés de sureté Les propriétés de la sureté d un réseau de Pétri sont introduite par Van der Aalst [Van98] pour formaliser qu un réseau de Pétri bien structuré ne contient ni de transitions non atteignable (Dead transitions), ni de boucles infinies (Livelock) et ni d inter-blocages (Deadlock). En effet, une transition est non atteignable si elle ne peut pas être tirée car elle est inaccessible. Un ensemble de transitions sont dans une boucle infinie si elles sont tirées d une manière infinie. Finalement, un inter-blocage se produit lorsque le réseau se bloque avant d arriver à la place de fin. Ces propriétés sont assurées si les trois conditions suivantes sont vérifiées : (1) La terminaison du réseau est toujours possible (2) Une fois qu un réseau est terminé, il ne devrait pas exister des jetons dans les places du réseau et (3) Toutes les transitions du réseau sont accessibles. En se basant sur ces définitions, nous pouvons analyser formellement la sureté d un ECAPE-net bien structuré comme suit : - Pour chaque état (marquage) M accessible à partir de l état initial M 0, il existe une séquence de franchissement liant l état M à l état final M f Formellement: M M M ) ( M M ) ( o f - L état final M f est le seul état accessible à partir de l état initial M 0 contenant au moins un jeton dans la place de fin p end. Formellement : M ( M 0 M M 0) ( M = 0) 170

183 Contribution / La vérification du processus métier par le ECAPE net - Il y a pas de transition non atteignable dans le ECAPE-net. ' t ' Formellement : t T M,M M M 0 M Le ECAPE-net du processus de traitement de commande est un processus sûr (sound), car il est d abord bien structuré. Ensuite, en simulant ce réseau, on peut déduire qu il ne contient pas de transitions non atteignables, ni d inter blocage ou de boucle infinie du moment où sa terminaison est toujours possible. En plus, une fois terminé, il n existe aucun jeton dans les places de ce réseau. 9.4 Conclusion Dans le but de modéliser la sémantique d exécution d un processus défini dans notre ECAPE-M et pour pouvoir vérifier formellement le bon fonctionnement de ce processus, nous avons proposé, dans ce chapitre, un nouveau réseau de Pétri coloré appelé ECAPE-net. Dans un ECAPE-N l événement de déclenchement d une règle est représenté par une place d entrée ; les événements déclenchés par l exécution d une action ou une compensation d une règle sont représentés une place de sortie. À son tour, l'action et la compensation d une règle sont représentés par les transitions. Finalement, les conditions et post conditions d'une règle sont attachées aux transitions. L'originalité du ECAPE-net est la définition de nouveaux types de places et de nouveaux types de transitions pour permettre la spécification des événements composés. Finalement, nous avons vu que la vérification de ce nouveau réseau de Pétri est faite en se basant sur deux classes de propriétés : Ces propriétés peuvent être classées en deux grandes catégories : (1) les propriétés du réseau bien structuré liées à la structure d un réseau. (2) les propriétés de sûreté qui sont liées à l aspect dynamique du réseau de Pétri. 171

184 Partie 3 Validation

185 Validation / La plateforme BP-FAMA 10 Plateforme BP-FAMA 10.1 Introduction 10.2 Architecture générale de BP-FAMA La phase de spécification La phase d exécution La phase de diagnostique Les outils du développement de BP-FAMA 10.3 Editeur du langage ECAPE-L 10.4 Gestionnaire de changement 10.5 Simulateur d exécution 10.6 Conclusion 10.1 Introduction Notre contribution, présentée dans la partie 2, est appuyée par la définition d une plateforme de modélisation et d analyse de processus métier appelé BP- FAMA (Business Process Framework for Agility of Modeling and Analysis). L objectif de cette plateforme est d offrir de la flexibilité à la modélisation et de la fiabilité à l exécution du processus. En effet, la BP-FAMA vise à (1) favoriser une modélisation flexible en utilisant le langage ECAPE-L qui se base sur e modèle ECAPE-M pour décrire un processus métier par un ensemble de règles de réaction. (2) Gérer le changement d une règle de processus en estimant le coût du changement. (3) Vérifier le bon fonctionnement du processus en utilisant le réseau de Pétri ECAPE-net. Dans ce chapitre, nous allons présenter la plateforme BP-FAMA en détaillant les différents modules qui constituent son architecture Architecture générale de BP-FAMA Dans cette section nous allons détailler l architecture générale de la plateforme BP-FAMA (Business Process Framework for Agility of Modelling and Analysis). Cette plateforme permet de favoriser la flexibilité, la souplesse de la 173

186 Validation / La plateforme BP-FAMA modélisation et d exécution du processus en utilisant le langage de règles ECAPE-L et de prendre en compte la dynamicité des différents éléments de processus métier (règles métier) en gérant le changement d un processus. Elle permet aussi d analyser le déroulement du processus exécutable pour vérifier s il correspond à ce qui a été modélisé en utilisant le réseau de Pétri ECAPEnet. Autrement dit, améliorer le fonctionnement des BRMS (Business Rules Management Systems) en garantissant une adaptation au changement et une facilité d analyse du bon fonctionnement du processus. L architecture générale de cette plateforme est présentée dans la figure Figure 10.1 L architecture de la plateforme BP-FAMA En effet, des différents composants sont utilisés, dans cette architecture, et cela pour gérer un processus métier tout au long de son cycle de vie des processus depuis la modélisation jusqu à l exécution et le diagnostic. 174

187 Validation / La plateforme BP-FAMA La phase de spécification Dans la phase de spécification, le concepteur définit les éléments qui constituent le processus métier où il redéfinit les éléments d un processus existant dans le but de l améliorer. Cette définition consiste en un moyen de dialogue entre les responsables des processus et les équipes opérationnelles en charge de les exécuter. Dans la plateforme BP-FAMA, un Editeur de règles ECAPE est utilisé pour définir un processus métier d une manière déclarative en se basant sur le modèle ECAPE-M (voir le chapitre 6). Pour augmenter la visibilité et la compréhension du processus, cet éditeur utilise le diagramme URML for BP (voir le chapitre 7) qui permet de faciliter la compréhension de la modélisation et permet de générer par la suite le code ECAPE-L associé. Cette manière conviviale augmente essentiellement la compréhension et la visibilité de ces processus et permet d évaluer le design. Le code ECAPE-L d un processus généré sera transformé en un graphe d impacts et en un réseau de Pétri ECAPE-net, un Gestionnaire du changement calcule l impact et estime le coût du changement d une règle ainsi que le degré de tolérance aux changements d un processus (voir le chapitre 8). A son tour, un Simulateur d exécution vérifie le bon fonctionnement d un processus en analysant le réseau ECAPE-net (voir le chapitre 9) La phase d exécution Dans la phase d exécution, un moteur de règles interprète le déroulement de l ensemble des actions des règles ECAPE qui constituent le processus. Cette interprétation est effectuée en automatisant les interactions entre les participants du processus (les documents, les informations et les tâches). L activation des différentes règles est assurée par un moteur CEP (Complex Event Processing). Ce moteur détecte les événements prédéfinis (primitifs et composes) et alerte le moteur de règles par des messages. Lorsque le moteur de règles reçoit un message de la part du moteur CEP, des règles sont activées selon les événements déclenchés. Finalement, les différents fichiers logs et traces cumulées lors de l exécution d un grand nombre d instances de processus sont stockées dans une base afin d être utilisées dans la prochaine étape. 175

188 Validation / La plateforme BP-FAMA La phase de diagnostic Dans la phase de diagnostic, le processus exécutable est analysé dans le but de mesurer les performances opérationnelles en se basant sur les fichiers logs. Dans la plateforme BP-FAMA, un Processus Mining analyse l ensemble de règles exécutées afin de reconstruire, à partir des informations cumulées lors de la phase précédente. Le processus résultant sera comparé au processus modélisé pour savoir qui s agit du même déroulement de l ensemble des activités Les outils de développement de BP-FAMA Afin de faciliter le processus de développement des différents composants de la plateforme BP-FAMA, nous avons utilisé l environnement de développement et d exécution Eclipse. En effet, Eclipse est un outil open source incontournable de développement de logiciel car il offre une plateforme extensible qui permet l ajout de nouvelles fonctionnalités grâce à des plugins. En plus, cette plateforme est vue comme une collection de projets open sources développés et maintenus par une large communauté de développeurs. Chaque projet a comme but de proposer un ensemble spécifiques de plugins et de toolkits de développement. Parmi ces projets, on peut citer : - Web tools plateforme project [Ecl09 a] : qui vise à proposer un ensemble de plugins et de toolkits de développement Web. - SOA technology project [Ecl09 b] : qui vise à proposer un ensemble de plugins et de toolkits de développement orientés services Web (des éditeurs BPMN, BPEL, un moteur BPEL...etc.) - Eclipse Modeling Project [Ecl09 c] : qui vise à proposer un ensemble de plugins et de toolkits de développement orientés modèle (outils d ingénierie dirigée par les modèle). Dans notre travail, nous nous somme intéressés au Eclipse Modeling Project (EMP) car ce projet inclut les plateformes orientées modèles suivantes : - Eclipse Modeling Framework (EMF) [Ecl09 d] : qui permet la définition d un méta-modèle pivot, appelé Ecore, qui est utilisé par tous les outils 176

189 Validation / La plateforme BP-FAMA orientés modèle. Grace à au méta-modèle Ecore, des transformations de modèles peuvent être effectuées (par exemple, un modèle exprimé en XML peut être transformé en un modèle exprimé en UML). - Graphical Editing Framework (GEF) [Ecl09 e] : qui offre un ensemble de classes qui aide à construire un éditeur pour un modèle donné. - Graphical Modeling Framework (GMF) [Ecl09 f] : qui se base sur les plateformes EMF et GEF pour générer éditeurs graphiques complets d un modèle donné en utilisant de différents (méta-) modèles en entrée (méta modèle du modèle à éditer, modèle de canevas, etc.). - Eclipse Model-to-Model transformation (M2M) et ATLAS Framework [Ecl09 g] : qui permettent de transformer un ensemble de modèles sources vers un ensemble de modèles cibles. Dans ce qui suit, nous allons détailler comment nous avons implémenté les différents composants différents composants de la plateforme BP-FAMA en se basant sur les différentes plateformes du projet EMP Editeur du langage ECAPE-L La plateforme BP-FAMA utilise le langage ECAPE-L pour décrire d une manière déclarative, un processus métier. Ce nouveau langage se base sur les règles ECAPE et permet, en plus de garantir une flexibilité de la modélisation, d augmenter l expressivité en héritant la syntaxe des langages impératifs les plus utilisés dans l industrie (BPEL, XPDL). En effet, ce langage utilise une syntaxe basée sur XML pour modéliser, d une manière déclarative, les différents éléments du processus métier. Pour cela, nous avons implémenté un prototype de l éditeur BP- FAMA du langage ECAPE-L en utilisant la plateforme GMF. En effet, cette plateforme fournit une composante de génération des éditeurs graphiques en utilisant un ensemble de modèles en entrée, comme il est illustré dans la figure

190 Validation / La plateforme BP-FAMA Figure 10.2 Le processus GMF de génération d éditeur graphique [Ecl09 f] - Le modèle du domaine représente le méta-modèle exprimé en Ecore du modèle à éditer. Dans notre prototype, il s agit du méta-modèle du langage ECAPE-L est exprimé en Ecore. - Le modèle graphique décrit les figures, nœuds, arcs, etc. utilisés dans le canevas de l éditeur graphique. Dans notre prototype, un rectangle est utilisé pour représenter une règle et des arcs est utilisés pour représenter différentes relations qui existent entre les règles. - Le modèle palette décrit les éléments utilisés dans la palette de l éditeur graphique. Dans notre prototype, la palette contient des règles et des arcs. - Le modèle de mapping permet de décrire les correspondances entre les trois précédents modèles. - Le modèle de génération décrire le code de l éditeur généré en JAVA - Finalement la plateforme GMF génère un plugin de l éditeur graphique qui sera exécuté dans un environnement Eclipse. La figure 10.3 représente une capture d écran du prototype de l éditeur BP-FAMA du langage ECAPE-L. 178

191 Validation / La plateforme BP-FAMA Figure 10.3 L éditeur graphique du langage ECPAPE-L 10.4 Gestionnaire du changement Le gestionnaire du changement implémente la démarche de gestion du changement d une règle dans le modèle ECAPE-M vue dans le chapitre 8. En effet, cette démarche consiste à définir les relations entre les différentes règles, et puis traduire l ensemble de règles et relations en un graphe orienté appelé graphe d impacts. L analyse de ce graphe permet de déterminer l ensemble de règles impactées par un changement et cela en fonction de trois facteurs : la nature du changement, l objet du changement et la nature des relations qui existent entre la règle à changer et les différentes règles du processus. Pour cela, nous avons utilisé la plateforme Model-to-Model transformation (M2M) du projet EMP pour transformer le modèle source ECAPE-M exprimé en ECAPEL-L (XML), vers un modèle cible du graphe d impact exprimé en XML. Ce graphe est affiché graphiquement dans l interface du gestionnaire du changement en utilisant la librairie JUNG (Java 179

192 Validation / La plateforme BP-FAMA Universal Network/Graph Framework) qui permet la modélisation et la visualisation d un graphe donné (voir la figure 10.4). Figure 10.4 L éditeur graphique du langage ECPAPE-L Cette librairie permet également d analyser un graphe donné. Pour cette raison, elle est utilisée aussi pour estimer le coût de changement d une règle en termes de nombre d opérations de changement. Pour cela, un nouveau graphe, dérivé du graphe d impacts, est utilisé pour construire les opérations de mise à jour éventuelles (ajouter, supprimer, modifier) provoquées par un changement d une règles (voir la figure10.5). 180

193 Validation / La plateforme BP-FAMA Figure 10.5 le calcul du coût du changement d une règle 10.5 Simulateur d exécution Le simulateur d exécution utilise le réseau de Pétri ECAPE-net pour vérifier le bon fonctionnement du processus. En effet, dans ce réseau un événement de déclenchement d une règle est représenté par une place d entrée ; les événements déclenchés par l exécution d une action ou une compensation d une règle sont représentés par une place de sortie. À son tour, l'action et la compensation d une règle sont représentés par les transitions. Finalement, les conditions et post condition d'une règle sont attachées aux transitions. Pour cela, nous avons utilisé la plateforme Model-to-Model transformation (M2M) du projet EMP pour transformer le modèle source ECAPE-M exprimé en ECAPEL-L (XML), vers un modèle de réseau exprimé en PNML (Petri Net Markup Language). En effet, PNML est un langage standard pour décrire les réseaux de Pétri, ce format est accepté par la plus part des analyseurs des réseaux de Pétri [Hil09]. Cette transformation est décrite dans le diagramme de la figure

194 Validation / La plateforme BP-FAMA Figure 10.6 Le diagramme de transformation du modèle ECAPE-M vers un réseau ECAPE-net 182

195 Validation / La plateforme BP-FAMA Pour analyser le réseau ECAPE-net résultat, nous avons opté pour l un outil open source PIPE (Platform Independent Petri-net Editor) [Blo03]. En effet, cet outil dispose d une interface graphique pour élaborer et l'analyse de réseaux de Pétri. L avantage de cet outil est qu il permet de visualiser des réseaux de Pétri écrit en PNML. Il est également très facile à utiliser et dispose de plusieurs modules pour effectuer les différents types d'analyse de réseaux de Pétri (voir la figure 10.7). Figure 10.7 L interface de l outil PIPE [Blo03] 10.6 Conclusion Nous avons présenté dans ce chapitre la plateforme BP-FAMA (Business Process Framework for Agility of Modeling and Analysis) qui utilise langage ECAPE-L qui se base sur e modèle ECAPE-M pour décrire un processus métier par un ensemble de règles de réaction en utilisant un Editeur. Cette plateforme permet de gérer le changement d une règle de processus et 183

196 Validation / La plateforme BP-FAMA d estimer le coût du changement en utilisant le gestionnaire du changement. Finalement, la BP-FAMA permet de vérifier le bon fonctionnement du processus en utilisant un simulateur d exécution basé sur le réseau de Pétri ECAPE-net. Un prototype, implémentant différents composants de la plateforme BP-FAMA, à été également présenté pour montrer la faisabilité du projet. Ce prototype est développé en se basant sur les outils de développement proposés dans le projet EMP de Eclipse. En effet, la plateforme GMF à été utilisé pour développer l éditeur du langage ECAPE-L, la plateforme de transformation M2M à été utilisé pour transformer le modèle ECAPE-M exprimé en ECAPEL- L (XML) vers un graphe d impacts (exprimé en XML) et vers un réseau de Pétri ECAPE-net (exprimé en PNML). Finalement, la librairie JUNG est utilisée pour analyser le graphe d impacts. A leur tous, l outil open source PIPE est utilisé pour analyser le réseau ECAPE-net. 184

197 Partie 4 Conclusion générale

198 Conclusion générale 11 Conclusion générale 11.1 Résumé de la contribution 11.2 Perspectives envisagées 11.1 Résumé de la contribution Le travail proposé dans cette thèse traite de la flexibilité de la modélisation et la vérification des processus métier. L objectif étant, de permettre, d une part, une modélisation souple qui prend en compte la nature dynamique des éléments d un processus métier ; et d autre part, la vérification du déroulement du processus pour s assurer de son bon fonctionnement. Pour atteindre cet objectif, nous nous sommes intéressés aux modèles de processus basés sur les règles qui proposent de considérer un processus comme un ensemble de règles. Cette manière de faire, permet de gagner en flexibilité et en adaptation aux changements dans la mesure où l élément interchangeable du processus est la règle. En outre, elle permet de définir les règles métiers d une manière rigoureuse. A l issu d un état de l art, nous avons constaté qu il existe un bon nombre de langages basés sur les règles métier qui utilisent différents formalismes et syntaxes. Toutefois, parmi les différents formalismes de règles existants, le formalisme de règle ECA s avère être le plus adapté pour modéliser un processus car ce type de règle permet de spécifier le flux de contrôle d un processus de façon modulaire grâce à ses différents composants. Une telle règle est facile à maintenir et permet d intégrer toutes les situations (contraintes, règles de dérivations, règles de production et règles de transformation). Cependant, le besoin d un mécanisme pour contrôler l exécution de l action et de lancer une compensation dans le cas où l exécution de l action est invalide ne semble pas trouver de réponses satisfaisantes. D autant plus que la vérification du processus modélisé par des règles ECA est plus complexe, car elle doit être obtenue en construisant un scénario d exécution à partir d un modèle implicite ce qui n est pas toujours évident. Cela donc pose un double problème de représentation et de vérification de processus métier garantissant la prise en compte de leur changement en phase d exploitation. 186

199 Conclusion générale Pour répondre à cette problématique, nous avons entrepris, dans le cadre de cette thèse, des recherches qui visent la construction d un modèle de processus basé sur un nouveau pattern de règles appelé ECAPE-M. Ce modèle permet de décrire un processus métier d une manière déclarative, en utilisant un ensemble de règles ECAPE. Le formalisme ECAPE est considéré dans nos travaux comme une extension du formalisme ECA, initialement défini par Evénement Condition Action, avec une post condition pour contrôler l exécution de l action d une règle et lancer une action de compensation dans le cas ou l exécution n est pas valide et avec un post événement pour décrire explicitement les événements qui seront générés par l exécution de l action de la règle pour construire un graphe d exécution du processus. Le modèle ECAPE-M permet non seulement l expressivité de la nature dynamique des différents éléments d un processus métier mais aussi la vérification du bon fonctionnement d un processus. Nous proposons de considérer le modèle ECAPE-M selon trois plans d abstraction: Le plan métier où les processus sont définis par un ensemble de règles ECAPE. Nous proposons ici un nouveau langage, appelé ECAPE-L, qui utilise une syntaxe basée sur XML, pour décrire les éléments des processus métier. Ce nouveau langage déclaratif est proche des langages d exécution impératifs de processus tels que BPEL et XPDL car il peut être exécuté par un moteur de règles qui interprète les différentes instructions. De plus, ECAPE-L peut être associé à un nouveau diagramme graphique appelé URML for BP (proche de BPMN) pour définir un processus abstrait (de haut niveau) qui permet d augmenter la visibilité et la compréhension du processus. Le plan comportemental où une démarche de gestion du changement d une règle dans le modèle ECAPE-M est mise au point. Cette démarche consiste à définir les relations entre les différentes règles, et traduire l ensemble des règles et relations en un graphe orienté appelé graphe d impact. L analyse de ce graphe permet de déterminer l ensemble des règles impactées par un changement et cela en fonction de trois facteurs : le type du changement, l objet du changement et la nature des relations qui existent entre la règle à changer et les différentes règles du processus. Dans le but de quantifier l effort maximum pour mettre en œuvre le changement d une règle, nous proposons d estimer le coût de changement d une règle en terme de nombre d opérations de changement. Pour cela, un nouveau graphe, dérivé du graphe d impact, est utilisé pour identifier les opérations de mise à jour éventuelles (ajouter, supprimer, modifier) provoquées par le changement d une règle. Notre démarche de gestion du changement propose également une 187

200 Conclusion générale métrique construite autour d un degré de tolérance aux changements, qui permet d indiquer le degré de stabilité d un processus vis-à-vis d un changement. Pour cela ce degré est calculé par le coût moyen de changement des différentes règles du processus. Ce qui permet d améliorer la modélisation du processus afin de minimiser l impact du changement d une règle sur l ensemble du processus. Le plan opérationnel où le modèle d un processus ECAPE-M est traduit en un réseau de Pétri coloré appelé ECAPE-net afin de modéliser la sémantique d exécution du processus. En effet, dans ce réseau l événement de déclenchement d une règle est représenté par une place en entrée ; les événements déclenchés par l exécution d une action ou une compensation d une règle sont représentés une place en sortie. À son tour, l'action et la compensation d une règle sont représentées par des transitions. Finalement, les conditions et post condition d'une règle sont attachées aux transitions. L'originalité du réseau ECAPE-net est la définition de nouveaux types de places et de nouveaux types de transitions pour permettre la spécification des événements composés. La vérification de ce nouveau réseau de Pétri est faite en se basant sur deux classes de propriétés : (1) les propriétés du réseau bien structuré liées à la structure d un réseau, comme la propriété du réseau régulier, la propriété du réseau complet et les satisfactions des conditions. (2) les propriétés de sûreté liées à l aspect dynamique du réseau de Pétri. Notre contribution est validée par l élaboration de l architecture d une plateforme de modélisation et d analyse de processus métier appelé BP-FAMA (Business Process Framework for Agility of Modeling and Analysis). Notons qu un prototype simplifié, qui implémente différents composants de la plateforme BP-FAMA, à été réalisé. Cette plateforme permet : (1) de favoriser la flexibilité de la modélisation du processus en utilisant le langage ECAPE-L ; (2) de gérer le changement d une règle de processus en estimant le coût du changement ; et (3) de vérifier le bon fonctionnement du processus en utilisant le réseau de Pétri ECAPE-net. Ce prototype comporte un éditeur du langage ECAPE-L, un outil de transformation du modèle ECAPE-M exprimé en ECAPEL-L (XML) vers un graphe d impacts (exprimé en XML) et vers un réseau de Pétri ECAPE-net (exprimé en PNML) et un gestionnaire du changement basé sur le graphe d impacts d un modèle ECAPE-M. 188

201 Conclusion générale 11.2 Perspectives envisagées Les recherches menées dans le carder de cette thèse ont permis de dégager plusieurs perspectives de travail. Une de ces perspectives pourrait être la proposition d une nouvelle méthode de self-healing (auto-reparation) du processus si une exception est survient durant son exécution. En effet, le selfhealing, désigne la capacité de détecter et d'isoler l élément qui cause une exception, réparer ou remplacer cet élément, et enfin, réintroduire l'élément réparé ou remplacé sans perturber l exécution du processus [Bou09 a].pour cela, la stratégie du self-healing peut passer par deux étapes : (1) Détection d exceptions : tente d'identifier tout risque d'exception (des boucles infinies, un inter-blocage ou les activités non atteignable), dans la phase de modélisation, en se basant sur le graphe de déclenchement de règles (un sous graphe d impacts). Grace à ce dernier, des risques d exceptions peuvent être détectées en marquant les parties du processus qui peuvent causer des telles exceptions. Par exemple, une boucle infinie peut être détectée en analysant les circuits dans le graphe de déclenchement. Cependant, nous avons considéré que chaque circuit dans ce graphe est une boucle qui risque d être infinie car en absence d un état de données (dans la phase de modélisation), nous ne pouvons pas savoir si une boucle se termine ou pas. Pour cette raison, nous allons marquer toutes les règles des circuits pour sont surveillés en la phase d exécution. (2) Gestion des exceptions: une gestion des exceptions est lancée sous forme d un démon avec l'exécution du processus pour surveiller les règles qui peuvent conduire à une exception (les règles marquées dans la phase précédente), et réagir dans le cas où ces risques deviennent de véritables exceptions qui déstabilisent le processus en lançant trois alternatives : (a) exécuter un code de compensation prédéfini pour chaque type d exception. Ce code peut être implémenté sous forme d un service Web, et peut être invoqué par le gestionnaire d exception. (b) substitution du service web ou application qui tombe en panne (en utilisant une instruction de type Discover). (c) Roll-backing (retour en arrière) vers la (s) règle (s) qui cause l exception. Notons que, ces trois actions sont injectées automatiquement dans la partie compensation de chaque règle marquée dans la phase détection d exceptions. 189

202 Conclusion générale Une deuxième perspective pourrait porter sur l optimisation de la définition de l ensemble de règles ECAPE en analysant les logs cumulés lors de l exécution de l ensemble de règles. En effet, cette analyse de l audit d exécution des règles permet de déduire que certaines règles ne s exécutent jamais, que deux règles exécutent les mêmes actions, etc. A partir de ces informations on peut améliorer la définition de l ensemble des règles en supprimant des règles, fusionnant des règles ou éclatant des règles. Notons que l amélioration de la définition des règles peut aussi se faire en analysant le graphe d impacts dans le but de redéfinir l ensemble de règles de telle sorte qu on aura moins d arcs possibles c est à dire. redéfinir certaines règles pour minimiser les relations qui existent entre elles. La minimisation de ces relations permettrait de réduire l impact du changement d une règle et réduire ainsi le coût du changement d une règle. 190

203 Bibliographie A [Ada05] [ARIS07] [Att07] Adams, M., Hofstede Arthur, Edmond, D., Van der Aalst, Wil M. P, «Facilitating Flexibility and Dynamic Exception Handling». Dans Workflows through Worklets. In O. Belo, J. Eder, O. Pastor, and J. Falcao Cunha, editors, Proceedings of the CAiSE'05 Forum, volume 161 of CEUR Workshop Proceedings, pages 45-50, Porto, Portugal, FEUP. ARIS, «The Event-driven Process Chain». Dans ARIS Design Platform, Spinger ATTIOGBÉ, J. Christian, «Contributions aux approches formelles de développement de logiciels : Intégration de méthodes formelles et analyse multifacette». Dans HDR, 13 septembre 2007, Université de Nantes, Nantes Atlantique Université B [Baa08] Baazizi M.A., Sebah, S., Hacid M.-S., Benbernou S., Papazoglou M. P., «Monitoring Web Services: A Database Approach». Dans la 1ere European Conference, ServiceWave 2008, Madrid, Spain, December 10-13, [Beh04] Behrmann, G. David, A., Larsen, K.G., «A tutorial on UP- PAAL». Dans Proceedings on the International School on Formal Methods for the Design of Computer, Communication, and Software Systems, volume 3185 of Lecture Notes in Computer Science, pages 200{236, Bertinora, Italy, September Springer-Verlag. [Ber04] Bertot, Y., Castéran, P., «Interactive Theorem Proving and Program Development : Coq'Art: The Calculus of Inductive Constructions».Springer, Series: Texts in Theoretical Computer Science. An EATCS Series 2004, XXV, 469 p., Hardcover, ISBN:

204 [Ber04] Debauche, B. et Mégard, P., «Business Process Management: pilotage métier de l'entreprise». Lavoisier, 2004, ISBN [Ber06] Berthomieu, B., Vernadat. F., «Time Petri Nets Analysis with TI- NA». Dans Third International Conference on the Quantitative Evaluation of Systems - (QEST'06) [Ber95] Bert, D., Echahed, R., Jacquet, P., Potet, M., Reynaud, J., «Spécification, généricité, prototypage : aspects du langage LPG». Dans [Bid04] Bidoit M., Mosses, P., «CASL : User Manual». Dans la revue Springer LNCS 2900 (IFIP Series), 2004 [Blo03] Bloom, J., Clark, C., Clifford, C., Duncan, A., Khan, H., Papantoniou M., «Platform Independent Petri-net Editor». Dans Rapport final du projet PIPE. Department of Computing, Imperial College London. Mars 2003 [Bou07] Boukadi, K., Ghedira, C., Maamar, Z., Benslimane D., «Specification and Verification of Views over Composite Web Services Using High Level Petri-Nets». Dans ICEIS:9th International Conference on Enterprise Information, Madeira, [Bou08] Boukhebouze, M., Amghar, Y., Benharkat, N., «BP-FAMA : Business Process Framework for Agility of Modelling and Analysis». Dans ICEIS:10th International Conference on Enterprise Information, Barcelone, [Bou09 a] [Bou09 b] Boukhebouze M., Amghar, Y., Benharkat, A., Mamaar, Z., «A rule-based modelling for the description of flexible and selfhealing business processes». Dans 12th East European Conference on Advance Databases and Information Systems, 7-10 september, Riga Latvia, Letonie, ADBIS 2009 Boukhebouze M., Amghar, Y., Benharkat, A., Mamaar, Z., «Rule-based modelling and verification of business processes using ECAPE net». Dans Thirteenth IEEE International Enterprise Computing Conference, Auckland, 31 august 4 september, EDOC

205 [Bou09 c] [Bra05] [Bra09] [BRG02] [Bry06 a] [Bry06 b] Boukhebouze M., Amghar, Y., Benharkat, A., Mamaar, Z., «Towards Self-healing Execution of Business Processes Based on Rules». Dans ICEIS:11th International Conference on Enterprise Information, Milan, Brambilla, M., Ceri, S., Comai, S., Tziviskou, C., «Exception handling in workflow-driven web applications». Dans A. Ellis and T. Hagino, editors, Proceedings of the 14th International Conference on World Wide Web (WWW 2005), pages , Chiba, Japan, ACM Press. CCPP99 Brahe, S., Bordbar, B., «A methodology for domain-specific business process modelling and implementation». Dans la revue International Journal of Business Process Integration and Management (IJBPIM), Volume 4 - Issue The Business Rules Group, «Defining Business Rules, What are they really?». Dans July Bry, F., Eckert, M., Pătrânjan, P. L., Romanenko, I., «Realizing Business Processes with ECA Rules: Benefits, Challenges, Limits». Dans 4th International Workshop, PPSWR 2006, Budva, Montenegro, June 10-11, Bry,F., Eckert, M., Pătrânjan, P.L., «Reactivity on the Web: Paradigms and Applications of the Language XChange». Dans Journal of Web Engineering, Volume 5, Number 1, Rinton Press (2006) C [Car04] [Car06] Carter, B.M., Lin, J.Y.C., Orlowska, M.E., «Customizing internal activity behaviour for flexible process enforcement». Dans Australasian Database Conference, Australian Computer Society (2004) Cardoso, J., «Process control-flow complexity metric: An empirical validation». Dans IEEE International Conference on Services Computing (IEEE SCC 06), Chicago, USA, September 18-22, pp , IEEE Computer Society. ISBN:

206 [Car07] [Cas07] [Cha04 ] [Cha97] [Chu04] [Cla06] [Cli86] [Cru03] Cardoso, J. «Complexity analysis of BPEL Web processes». Dans la revue Software Process: Improvement and Practice 12(1): (2007) Castellanos, M., Mendling, J., Weber, B., Weijters, T., «Introduction to the Third Workshop on Business Process Intelligence (BPI 2007)». Dans International Workshops, BPI, BPD, CBP, ProHealth, RefMod, semantics4ws, Brisbane, Australia, September 24, 2007, Revised Charfi, A., Mezini, M., «Hybrid Web Service Composition: Business Processes Meet Business Rules». Dans ICSOC'04, November 15 19, 2004, New York, New York, USA. Charles, N., Bowman, H., Thompso, S., «From ACT-ONE to Miranda, a Translation Experiment». Dans Computer Standards and Interfaces Journal, 19(1), May Chulsoon, P., Injun, C., «Management of business process constraints using BPTrigger». Dans la revue Computers in Industry 55 (2004) Claro, D., Albers, P. H., Jin, K., «Web services composition». Dans le Chapitre 8 de Semantic Web Services, Processes and Applications, Par J.Cardoso, A.Sheth. ISBN: , Springer 2006 Cliff, J., «Systematic Software Development Using V. D. M.» Prentice-Hall ISBN , Crusson, T., «Business Process Management : De la modélisation à l exécution». Dans le rapport technique (Livre Blanc) Intalio, D [Deh03] [Deh05] Dehnert, J., «A Methodology for Workflow Modeling : From business process modeling towards sound workflow specification». Dans thèse de doctorat à l université technique de Berlin, Ecole d informatique, soutenue le Dehnert, J., Zimmermann A., «On the suitability of correctness criteria for business process models». Dans Proc. 3rd Int. Conf. on 194

207 Business Process Management (BPM 2005) Nancy, France, September 2005, pp , 2005 [Deu07] Deutch, D., Milo, T., «Querying Structural and Behavioral Properties of Business Processes». Dans 11th International Symposium, DBPL 2007, Vienna, Austria, , Springer Berlin / Heidelberg, E [Ecl09 a] [Ecl09 b] [Ecl09 c] [Ecl09 d] [Ecl09 e] [Ecl09 f] [Ecl09 g] [Esh03] Eclipse, «Web tools plateforme project». Dans Eclipse, «SOA technology project». Dans Eclipse, «Eclipse Modeling Project». Dans Eclipse, «Eclipse Modeling Framework Project (EMF)». Dans Eclipse, «The Graphical Editing Framework (GEF)». Dans Eclipse, «The Eclipse Graphical Modeling Framework (GMF)». Dans Eclipse, «ATL (ATLAS Transformation Language)». Dans Eshuis.R, Dehnert.J, «Reactive petri nets for workflow». Dans Application and Theory of Petri Nets Pages , Springer, 2003 [Eul09] Euler, «Apprendre et enseigner les mathématique». Dans

208 F [Fis04] [For79] [Fux03] Fisteus, J., A., Fernández L., S., Kloos. C., D., «Formal Verification of BPEL4WS Business Collaborations». Dans Proceedings of the 5th International Conference on Electronic Commerce and Web Technologies (EC-Web '04), Zaragoza, Spain (August 2004). To be published in Lecture Notes in Computer Science. Forgy, C., «On the efficient implementation of production systems». Dans Ph.D. Thesis, Carnegie-Mellon University, Fuxman, A., Liu, L., Pistore, M., Roveri, M., Mylopoulos, J., «Specifying and Analyzing Early Requirements: Some Experimental Results». Dans the 11th IEEE International Requirements Engineering Conference, 8th-12th September 2003, Monterey Bay, California U.S.A., 2003 G [Gar09] [Geo06 a] [Geo06 b] [Geo07] [Giu06] Gardner, T., «UML Modelling of Automated Business Processes with a Mapping to BPEL4WS». Consultable via ce lien : Octobre 2009 Goedertier, S. Vanthienen, J., «Designing compliant business processes with obligations and permissions». Dans BPM 2006 International Workshops, Vienna, AUTRICHE Goedertier, S., Vanthienen, J., «Compliant and flexible business process with business rules». Dans 7th Workshop on Business Process Modeling, Development and Support (BPMDS'06) at CAiSE'06 pages: Goedertier, S., Haesen, R. and Vanthienen, J., «EM-BrA²CE v0.1: A Vocabulary and Execution Model for Declarative Business Process Modeling». Dans rapport de recherche université de technologie Eindhoven, 2007 Giurca, A., Lukichev, S., Wagner, G., «Modeling Web Services with URML». Dans Proceedings of SBPM2006, Budva, Montenegro (11th June 2006), June

209 [Gog96] [Got08] [Gri04] [Gru07] Goguen, J., Grant, M., «Algebraic Semantics of Imperative Programs». The MIT Press (May 22, 1996), ISBN Gottardi, G., Arico, M. R., Piovesana, A., «On the drivers of extended enterprise and the problems of integration and governance». Dans la revue International Journal of Business Process Integration and Management (IJBPIM), Volume 3 - Issue Grigori, D., Casati, F., Castellanos, M., Dayal, U., Sayal, M., Shan, M.C., «Business Process Intelligence». Dans la revue Computers in Industry 53 (2004) , 2004 Gruhn, V., Laue, R., «What business process modelers can learn from programmers». Dans Science of Computer Programming Journal 65 (2007) 4 13, H [Hac09] Hacid, M., Lécué, F., Léger, A., Rey, C., Toumani, F., «Les web services sémantiques, automate et intégration - Introduction, éléments et scénarios, découverte de services web». Dans la revue Dans Technique et Science Informatique 28(2): [Hil09] [Hin05] [Hom04] Hillah, L.M., Kindler, E., Kordon, F., Petrucci, L., Trèves, N., «A primer on the Petri Net Markup Language and ISO/IEC ». Dans Petri Net Newsletter (originally presented at the 10th International workshop on Practical Use of Colored Petri Nets and the CPN Tools -- CPN'09) Hinz, S., Schmidt, K., Stah, C., «Transforming BPEL to Petri nets». Dans Proceedings of the 3rd International Conference on Business Process Management, volume 2649of Lecture Notes in Computer Science, pages 220{235, Nancy, France, September Springer-Verlag. Hommes, L.J, «The Evaluation of Business Process Modeling Techniques». Dans Thèse de doctorat à L université de technologie de Delft, soutenu le 26 janvier

210 [Hwa06] Hwang, Y.F., Rine, D., «Verification framework and algorithms for integrating information distribution systems». Dans la revue Information & Software Technology 48(9): (2006). [ilog09] ilog, dans : I J [Jab96] Jablonski, S., Bussler, C., «Workflow Management: Modeling Concepts, Architecture and Implementation», Itp New Media, 1996, ISBN [Jan06] Jansen-Vullers M.H., Netjes, M., «Business Process Simulation - A Tool Survey». Dans 7eme Workshop and Tutorial on Practical Use of Coloured Petri Nets and CPN Tools, 2006 K [Kap00] Kappel, G., Rausch-Schott, S., Retschitzegger, W., «A framework for workflow management systems based on objects, rules and roles». Dans ACM Computing Surveys (CSUR 2000), [Kno00] [Kno00] Knolmayer, G., Endl, R., and Pfahrer, M., «Modeling Processes and Workflows by Business Rules». Dans Business Process Management, Models, Techniques, and Empirical Studies W. M. Aalst, J. Desel, and A. Oberweis, Eds. Lecture Notes In Computer Science, vol Springer- Verlag, London, 16-29, Knolmayer, G., Endl, R., and Pfahrer, M., «Modeling Processes and Workflows by Business Rules». Dans Business Process Management, Models, Techniques, and Empirical Studies W. M. Aalst, J. Desel, and A. Oberweis, Eds. Lecture Notes In Computer Science, vol Springer- Verlag, London,

211 [Kos04] Koshkina, M., van Breugel, F., «Modelling and verifying web service orchestration by means of the concurrency workbench». Dans ACM SIGSOFT Software Engineering Notes, L [Lee07 ] [Leu07] [Ley01] [Ley02] [Ley99] [Li04] [Lu07] Lee, S., Kim, T., Y., Kang, D., Kim, K., Lee, J., Y., «Composition of executable business process models by combining business rules and process flows». Dans Expert Systems with Applications. Volume 33, Issue 1, July 2007, Pages Leutenmayr, S., «Selected Languages for Web Services Composition: Survey, Challenges, Outlook». Dans thèse de doctorat à Université Louiset-Maximilien de Munich, soutenue le Leymann. F., «Web Services Flow Language (WSFL 1.0)». Dans http ://www-3.ibm.com/software/solutions/webservices/pdf/wsfl.pdf Leymann, F., Roller D., Schmidt, M.T., «Web services and business process management». Dans IBM System Journal Volume 41, Number 2, 2002 Leymann, F., Roller, D., «Production Workflow - Concepts and Techniques». Prentice Hall, 1999, ISBN Li.X. Marín.J.M, «Composite Event Specification in Active Database Systems: A Petri Nets Approach». Dans Proceedings of the Fifth Workshop and Tutorial on Practical Use of Coloured Petri Nets and the CPN Tools, Aarhus, Denmark, October 8-11, 2004, DAIMI PB - 570, pages Lu, R., Sadiq, S., «A Survey of Comparative Business Process Modeling Approaches». Dans 10th International Conference, Bis 2007, Poznan, Poland, April 25-27,

212 M [Maa09] [Mar03] [Mar07] [Mie08] [Mil80] Maamar, Z., Sattanathan, S., Thiran, P., Benslimane, D., Bentahar, J., «An Approach to Engineer Communities of Web Services - concepts, architecture, operation, and deployment». Dans la revue International Journal of E-Business Research (IJEBR) 9(4) Martens, A., «On usability of web services». Dans 4th International Conference on Web Information Systems Engineering Workshops, Italy Markovic, I., Karrenbrock, M., «Semantic Web Service Discovery for Business Process Models». Dans WISE 2007 International Workshops Nancy, France Proceedings, Springer Berlin / Heidelberg, 2007 Mietzner, R., Leymann, F., Papazoglou, M.P., «Defining Composite Configurable SaaS Application Packages Using SCA, Variability Descriptors and Multi-tenancy Patterns». Dans 3eme International Conference on Internet and Web Applications and Services, Athens, Greece, 2008 Milner, R., «A calculus of communicating systems». Dans Lecture Notes in Computer Science, vol. 92, Springer-Verlag, Berlin, [Mil99] Milner, R., «Communicating and Mobile Systems: The π-calculus». Dans Rapport de recherche Cambridge University, Cambridge, UK, [Mri07] [Mul04] Mrissa, M., Ghedira C., Benslimane, D., Maamar, Z., Rosenberg, F., Dustdar S., «A Context-based Mediation Approach to Compose Semantic Web Services». Dans la revue ACM Transactions on Internet Technology 8(1), ACM Association for Computing Machinery Müller, R., Greiner, U., Rahm, E. «AgentWork: a Workflow System Supporting Rule-Based Workflow Adaptation». Dans Data & Knowledge Engineering, Vol. 51(2) (2004)

213 N [Net06] Netjes, M., Reijers, H.A., Van der Aalst, Wil M. P, «Supporting the BPM lifecycle with FileNet». Dans le Workshop EMMSAD, 18th International Conference on Advanced Information Systems Engineering (CAiSE'06) Namur, O [OASIS03] OASIS, «Collaboration-Protocol Profile and Agreement Specification, ebxml Trading-Partners Team Version 1.0». Dans ebxml specification [OASIS04] OASIS, «Web Services Reliable Messaging TC WS-Reliability 1.1». Dans WS-Reliability v1.1 specification [OASIS07] [Ola00] [OMG04] [OMG08 a] [OMG08 b] [OMG09] OASIS, «Business Process Execution Language for Web Services (BPEL4WS 2.0)». Dans le rapport de spécification, Olalla, Marta, «Information technology in business process reengineering». Dans la revue International Advances in Economic Research, Volume 6, Number 3, août 2000 Object Management Group, «Production Rule Representation (PRR) Version 1.0». Dans le rapport de spécification version 1.0, numéro : dtc/ , Object Management Group, «Unified Modeling Language». Dans le rapport de spécification version 2.1.1, numéro : formal/ , Object Management Group, «Semantics of Business Vocabulary and Business Rules (SBVR 1.0)». Dans le rapport de spécification numéro : formal/ , Object Management Group, «Business Motivation Model (BMM 1.2)». Dans le rapport de spécification numéro : formal/ ,

214 [Ouy05 a] [Ouy05 b] [Ouy06] [Owr93] Ouyang, C., Verbeek, E., van der Aalst, W.M.P., Breutel, S., Dumas, M. ter Hofstede, A.H.M., WofBPEL, «a tool for automated analysis of BPEL processes». Dans ICSOC 2005, International Conference of Service-Oriented Computing, Berlin Ouyang, C., Verbeek, E., van der Aalst, W.M.P., Breutel, S., Dumas, M. ter Hofstede, A.H.M., «WofBPEL: a tool for automated analysis of BPEL processes». Dans ICSOC 2005, International Conference of Service-Oriented Computing,Berlin Ouyang, C., van der Aalst, W.M.P., Dumas, M., ter Hofstede, A.H.M., «Translating BPMN to BPEL». Dans le rapport BPM-06 Owre, Sam, Rushby, John, Shankar, Natarajan, «The PVS Specification Language». Dans P [Pas06] [Per03] [Pes06] Paschke, A., Dietrich, J., Giurca, A., Wagner, G., Lukichev, S, «On Self-Validating Rule Bases». Dans 2nd International Workshop on Semantic Web Enabled Software Engineering (SWESE 2006) Perini, A., Pistore, M., Roveri, M., Susi A., «Agent-oriented modeling by interleaving formal and informal specification».dans Agent Oriented Software Engineering (AOSE-2003). Melbourne, Australia - July 15, To be published in Lecture Notes in Computer Science Pesic, M. van der Aalst, W. M. P., «A declarative approach for flexible business processes management». Dans BPM 2006 International Workshops, Vienna, AUTRICHE [Por03] Porter, Michael, «L'avantage concurrentiel». Dunod, Paris, 2003 (Réédition), ISBN [Pu05] Pu, G., Zhao, X., Wang, S., Qiu. Z, «Towards the semantics and verification of BPEL4WS». Dans Proceedings of the International Workshop on Web Languages and Formal Methods, volume 151(2) of Electronic 202

215 Notes in Theoretical Computer Science, pages 33{52, New Castle, UK, July Elsevier. R [Ram06] [Rev06] [Rew09 a] [Rew09 b] [Rim08] Rampacek, S., «Sémantique interactions et langages de description des services web complexes». Dans thèse de doctorat, université de Reims Champagne-Ardenne, 2006 Regev, G., Soffer, P., Schmidt, R., «Taxonomy of Flexibility in Business Processes». Dans Seventh Workshop on Business Process Modeling, Development, and Support In conjunction with CAiSE 06 Rewerse Groupe, dans : Rewerse Groupe, dans : Rimini, Giorgio, Roberti, Paolo, «Business Process Monitoring: BT Italy case study». Dans la revue E-Government Ict Professionalism and Competences Service Science, Volume 280/2008 [Ros05 ] Rosenberg, F., Dustdar, S., «Business Rules Integration in BPEL A Service-Oriented Approach». Dans Proceedings of the Seventh IEEE International Conference on E-Commerce Technology CEC [Ros07] [Rus04 a] [Rus04 b] Rosemann, M., van der Aalst, W.M.P, «A Configurable Reference Modelling Language». Dans la revue Systems Volume 32, Issue 1 (March 2007) Pages 1-23 : 2007 Russell, Nick, Ter Hofstede1 Arthur, Edmond, D., Van der Aalst, Wil M. P, «Workflow Resource Patterns». Dans le rapport interne BETA Working Paper Series, WP 127, Eindhoven University of Technology, Eindhoven, Russell, Nick, Ter Hofstede Arthur, Edmond, D., Van der Aalst, Wil M. P, «Workflow Data Patterns». Dans le rapport interne QUT Technical report, FIT-TR , Queensland University of Technology, Brisbane,

216 [Rus06 a] Russell, N., van der Aalst, Wil M.P., ter Hofstede, A.H.M., Wohed, P., «On the Suitability of UML 2.0 Activity Diagrams for Business Process Modelling». Dans M. Stumptner, S. Hartmann, and Y. Kiyoki, editors, Proceedings of the Third Asia-Pacific Conference on Conceptual Modelling (APCCM2006), volume 53 of CRPIT, pages , Hobart, Australia, ACS. [Rus06 b] Russell, Nick, Ter Hofstede Arthur, Van der Aalst, Wil M. P, Mulyar, Nataliya, «Workflow Control-Flow Patterns : A Revised View». Dans le rapport interne BPM Center Report BPM-06-22, BPMcenter.org, [Rus06 c] [Rus09] Russell, Nick, Van der Aalst, Wil M. P, Ter Hofstede Arthur, «Exception Handling Patterns in Process-Aware Information Systems». Dans le rapport interne BPM-06-04, BPMcenter.org, Russell, N., ter Hofstede, A.H. M., «new YAWL: Towards Workflow 2.0». Dans Book chapite : Transactions on Petri Nets and Other Models of Concurrency II Special Issue on Concurrency in Process-Aware Information Systems. Springer 2009 S [Sad05 ] [Sal04] [Sch00] [Sch02] Sadiq, S. W., Orlowska, M. E., Sadiq, W., «Specification and validation of process constraints for flexible workflows». Dans Information System journal, 30(5): , Salaün G., Ferrara A., Chirichiello A., «Negotiation among web services using LOTOS/CADP». Dans in computer science ECOWS 2004 : European conference on web services, Erfurt, ALLEMAGNE, Schmidt, K., «LoLA : a low level analyser». Dans Proceedings of the 21st International Conference on Application and Theory of Petri Nets, volume 1825 of Lecture Notes in Computer Science, pages , Aarhus, Denmark, June Springer-Verlag. Schroeder, M. and Wagner G., dans le procedure du Workshop on Rule Markup Languages for Business Rules on the Semantic Web., Italy, June CEUR-WS Publication Vol

217 [Sch07] Schonenberg, M.H., Mans, R.S., Russell, N.C., Mulyar, N.A., van der Aalst, W.M.P, «Towards a Taxonomy of Process Flexibility (Extended Version)». Dans le rapport interne BPM Center Report BPM-07-11, BPMcenter.org, [Ser08] Serrour B., Gasparotto D., Kheddouci, H., Benatallah, B. «Message Correlation and Business Protocol Discovery in Service Interaction Logs.». Dans la 20th International Conference on Advanced Information Systems Engineering (CAiSE 08), LNCS 5074, pp , [Smi02] [Smi03] [Son08] [Sub08] Smith, Graeme, Kammüller, Florian, Santen, Thomas «Encoding Object-Z in Isabelle/HOL». Dans la revue Lecture notes in computer science 2002, vol. 2272, pp [Note(s) : XII, 534 p., ] (15 ref.) ISBN ; Smith, H., Fingar, P., «Workflow is just a Pi process». Dans Computer Sciences Corporation report, November Song, Minseok, Van der Aalst, Wil M. P, «Towards Comprehensive Support for Organizational Mining». Dans le revue Decision Support Systems, Volume 46, Number 1, Pages , Dec Subramanian, S., Thiran, P., Narendra, N.C., Mostefaoui G.K., Maamar, Z, «Enhanced BPEL for Self-Healing Composite Web Services». Dans IEEE International Symposium on Applications and the Internet (SAiNT'2008), Turku, Finland, published in IEEE LNCS. T [Tah06] Taher, Y., Benslimane, D., Fauvet, M.C., Maamar, Z., «Towards an Approach for Web services Substitution». Dans IDEAS '06: Proceedings of the 10th International Database Engineering and Applications Symposium, Delhi, India. pp IEEE Computer Society Washington, DC, USA. ISBN ISSN [Tha01] Thatte. S., «XLANG - Web Services For Business Process Design,». Dans http ://

218 [Tru06] [TUE09] [Tun96] [Tur07] TRUONG, Ninh Thuan, «Utilisation de B pour la vérification de spécifications UML et le développement formel orienté objet». Dans la thèse de doctorat en Informatique de l'université Nancy 2, soutenue le vendredi 05 mai 2006 au LORIA à Vandoeuvre. Université technique d Eindhoven, Tumay, K., «Business Process Simulation». Dans le Proceedings de the 1996 Winter Simulation Conference, pages ACM Press, Turner, K., J., «Representing and analysing composed web services using CRESS». Dans Journal of network and computer applications ISSN vol. 30, no2, pp , V [Van02] [Van02] [Van03 a] [Van03 b] [Van05 a] Van der Aalst, ter Hofstede, A.H.M., «Yet Another Workflow Language». Dans le rapport interne QUT Technical report, FIT-TR , Queensland University of Technology, Brisbane, 2002 Van der Aalst, Wil M. P, Van Hee, Kees, «Workflow management: models, methods, and systems», MIT Press, 2002, ISBN: Van der Aalst, Wil M. P, ter Hofstede, Arthur H.M, Weske, Mathias, «Business Process Management: A Survey». Dans BPM 2003, LNCS 2678, pp. 1 12, Springer-Verlag Berlin Heidelberg 2003 Van der Aalst, W.M.P. Dumas, M., ter Hofstede, A.H.M., «Web Service Composition Languages: Old Wine in New Bottles?». Dans la 29th EUROMICRO Conference: New Waves in System Architecture, pages IEEE Computer Society, Los Alamitos, CA, Van der Aalst, W.M.P., Weske, M., Grünbauer. D., «Case Handling: A New Paradigm for Business Process Support». Dans Data and Knowledge Engineering, 53(2): ,

219 [Van05 b] [Van06] [Van07] [Van08 ] [Van98] [Vas06] Van Dongen, B.F., Jansen-Vullers, M.H., «Verification of SAP Reference Models». Dans BPM 2005, 3rd International Conference, France, Van Breugel.F, Koshkina, M., «Models and Verification of BPEL». Dans le Rapport de recherche, université de York. Sptembre van der Aalst, W.M.P., Lassen, K.B, «Translating unstructured workflow processes to readable BPEL: Theory and implementation». Dans Information and Software Technology, Van Eijndhoven.T, Iacob.M.E, Ponisio.M.L., «Achieving Business Process Flexibility with Business Rules». Dans EDOC 2008: Van der Aalst, W.M., «The Application of Petri Nets to Workfow Management». Dans la revue Journal of Circuits, Systems and Computers, 8(1):21{66, Vasko, M., Dustdar, S., «A view based analysis of workflow modeling languages». Dans Proceedings of the 14th Euromicro International Conference on Parallel, Distributed, and Network-Based Processing (PDP 06). W [W3C04 a] [W3C04 b] [W3C06 ] [W3C09] [W3C99 a] W3C, «OWL Web Ontology Language 2.0». Dans W3C Submission REC- REC-owl-features /2004. W3C, «SWRL: A Semantic Web Rule Language Combining OWL and RuleML». Dans W3C Submission SUBM-SWRL /2004. W3C, «Web services policy 1.2. Framework (WS-policy)». Dans W3C Member Submission 25 April W3C, «Rule Interchange Format». Dans W3C Submission REC- REC- RIF-CW-9-09/2009. W3C, «Resource Description Framework (RDF)». Dans W3C Submission REC-rdf-syntax /

220 [W3C99 b] W3C, «Transformations XSL (XSLT) 1.0». Dans W3C Submission REC- REC-xslt /1999. [Wag05] Wagner, G, «Rule Modeling and Markup». Dans Reasoning Web, 3564 ed, N. Eisinger and J. Maluszynski, Eds. Msida, Malta: Springer, 2005, pp [Wag06] [WfMC08] [WfMC99] [Whi03] [WPI09] Wagner, G., Giurca, A., Lukichev S., «Modeling Web Services with URML». Dans proceedings of Semantics for Business Process Management Workshop, Budva, Montenegro, June The Workflow Management Coalition, «Final XPDL 2.1 Specification», dans le Rapport de spécification numéro WFMC-TC-1025-Oct A, The Workflow Management Coalition, «Workflow Management Coalition Terminology & Glossary», Rapport numéro WFMC-TC-1011 Issue 3.0. Février White, S. A., «Process Modelling Notations and Workflow Patterns». Dans Rapport technique IBM, January Workflow Patterns Initiative, juillet Y [Yan05] [Yog98] Yang, Y., Tan, Q. Yu, J., Liu, F. «Transformation BPEL to CP-nets for verifying web services composition». Dans the International Conference on Next Generation Web Services Practices, Korea Yogesh, Malhotra, «Business Process Redesign: An Overview». Dans la revue IEEE Engineering Management Review, vol. 26, no. 3,

221 Z [Zen01] [Zen02] [Zur07] Zeng, L., Ngu, A., Benatallah, B., O'Dell, M. «An Agent-Based Approach for Supporting Cross-Enterprise Workflows». Dans proceedings of the 12th Australasian Database Conference (ADC2001) (2001) Zeng, L., Flaxer, D., Chang, H., Jeng, J.J., «PLM flow-dynamic Business Process Composition and Execution by Rule Inference». Dans Proceedings of the Third International Workshop on Technologies for E- Services Pages: : 2002 zur Muehlen, M., Indulska, M., Kamp G., «Business Process and Business Rule Modeling: A Representational Analysis». Dans 3rd International Workshop on Vocabularies, Ontologies and Rules for The Enterprise (VORTE 2007), Annapolis, Maryland, USA, 15 Octobre,

222 Annexe 1 Etat de l art sur la gestion des processus métier (BPM)

223 Annexe 1 Etat de l art sur la gestion des processus métier (BPM) 1.1 Introduction 1.2 Terminologie Processus Processus métier La gestion des processus métier 1.3 Les origines du BPM (gestion des processus métier) L intégration métier Le Workflow Mesurer de performance et maîtrise de processus 1.4 Le cycle de gestion d un processus La phase de modélisation La phase d exécution La phase de diagnostique 1.5 Les systèmes de gestion des processus (BRMS) 1.6 Conclusion 1.1 Introduction Avec la naissance des nouvelles technologies d information, les entreprises voient, aujourd hui, l obligation d informatiser l ensemble des activités qui au tour de leur processus métier. En effet, un fonctionnement efficace des organisations, impose de s appuyer sur des processus métiers robustes, et adaptés à leurs activités. La définition et l exécution des ces processus nécessitent respectivement un modèle et des outils pour permettre la collaboration, la définition, le déploiement, l'exécution, et le contrôle des processus. La gestion des processus appelée BPM (Business Process Management, ou gestion des processus métier) consiste à gérer de bout en bout les processus métiers de l'entreprise pour en avoir une meilleure vue. Il est important de permettre aux décideurs, analystes métiers, équipes fonctionnelles et équipes techniques de collaborer à la définition et l évolutivité des processus métiers via un seul outil agrégeant les différentes visions. Il est également nécessaire d'optimiser ces processus et, tenter de les automatiser au maximum à l'aide d'applications métier. 211

224 Annexe 1 Dans ce chapitre, nous introduisons la gestion des processus métier en précisant la terminologie, son origine, le cycle de gestion d un processus et les outils de gestion proposés. 1.2 Terminologie Un processus Le terme «processus» peut se traduire par «avancer» et «progresser», il s agit donc d un mouvement dont l auteur connaît l objet, l objectif, le pourquoi. Ce terme est utilisé en Informatique pour décrire plusieurs concepts notamment dans les systèmes d exploitation, pour décrire une tâche d'un programme au cours de l'exécution. Dans l ingénierie des systèmes d information, le terme «processus», désigne un enchaînement partiellement ordonné d exécutions d activités qui, à l aide de moyens techniques et humains, transforment des éléments d entrée en éléments de sortie en vue de réaliser un objectif dans le cadre d une stratégie. D autres termes, liés à la notion de «processus», sont souvent utilisés pour désigner le processus, comme par exemple «procédure» et «procédé». En effet, Debauche et Mégard expliquent, dans leur livre [Ber04], que le terme «procédure» s applique à des processus impliquant des personnes et de l immatériel comme par exemple : les procédures bancaires, les procédures budgétaires, les procédures de justices, etc. Tandis que, le terme «procédé», est plutôt utilisé dans la fabrication de produits à partir de matières premières Un processus métier Un «processus métier» ou un «processus d'affaires» (en anglais Business Process) désigne les activités qui s appuient sur un ensemble de tâches et du savoir faire d une entreprise pour produire une valeur ajoutée aux clients. Le Workflow Management Coalition (WfMC) définit un processus métier comme : «un ensemble d'une ou plusieurs procédures ou activités liées entre elles pour réaliser collectivement un objectif ou une politique métier en définissant les rôles et les interactions fonctionnelles au sein d une structure organisationnelle» [WfMC99]. Ces processus sont des processus opérationnels qui décrivent l ordre d exécution des activités principales de l'entreprise en transformant les éléments d'entrée en éléments de rendement pour atteindre un objectif 212

225 Annexe 1 métier ou stratégique. Les processus métier sont le patrimoine de l entreprise. Un processus métier est, donc, considéré comme un ensemble de relations logiques entre un groupe d activités incluant des interactions entre partenaires sous la forme d échange de données pour fournir une valeur ajoutée aux clients. Le Workflow Management Coalition (WfMC) identifie, dans [WfMC99], plusieurs terminologies et concepts de base associés à un processus métier. Chacun apporte une nuance ou précise certains aspects du processus. La figure 1.1 résume ces concepts en représentant les relations qui existent entre les terminologies. Figure 1.1 Les relations entre les terminologies du processus [WfMC99] En effet, un processus métier est généralement associé à des objectifs opérationnels comme par exemple le processus de réservation de voyage. La définition d un processus métier est la représentation du processus par un réseau d'activités et leurs relations, en indiquant le début et la fin du processus, et en spécifiant des informations sur les activités individuelles, comme les participants, les applications et les données, etc. Un système de gestion Workflow permet de créer et gérer l'exécution des pro- 213

226 Annexe 1 cessus métier grâce à des moteurs de Workflow, capables d'interpréter la définition du processus, d'interagir avec les participants et, si nécessaire, invoquer des outils ou des applications. Nous reviendrons sur ces termes et concepts dans le prochain chapitre La gestion des processus métier (BPM) Debauche et Mégard définissent le BPM (Business Process Management) comme le processus de gestion du processus métier [Ber04]. Van der Aalst et al. définissent le BPM comme : «la gestion des processus métier en utilisant des méthodes, des techniques et des logiciels pour modéliser, exécuter, contrôler et analyser les processus opérationnels en s appuyant sur des acteur qui peuvent être : des êtres humains, organisations, des applications, documents et autres sources d'information» [Van03 a]. En effet, le BPM consiste à gérer les processus métier: (1) sur un plan globale en prenant en compte les processus de bout en bout, depuis la chaine d approvisionnement jusqu à toutes les activités interne et externes d une entreprise. (2) sur un plan de cycle de gestion en intéressant aux différentes étapes du cycle de vie des processus depuis la modélisation jusqu à l exécution et le diagnostic. Figure 1.2 Le positionnement de BPM par rapport au SI de l entreprise L objectif du BPM est de permettre : - L optimisation de la chaine de valeur de l entreprise en définissant, supervisant et améliorant les processus métier ; - La capitalisation sur deux actifs-clés de toute entreprise : son organisation (le personnel, son savoir faire) et son système d information ; 214

227 Annexe 1 - Offrir une agilité au processus c.à.d. des processus adaptables aux changements. Comme illustré dans la figure 1.2, la gestion du processus métier se positionne en amont avec le système d information d une entreprise. En effet, cette gestion permet de capitaliser sur les outils les applications, les services d un système d information et les acteurs de l entreprise afin d augmenter la productivité. Pour cela, un processus métier d une entreprise orchestre : les applications métier utilisées par les acteurs de l entreprise, les outils standard comme les outils de bureautiques (les outils de messageries et les calendriers électroniques), les applications d intégration (EAI), les applications de communication (B2Bi), les bases de données, les middlewares ainsi que les tâches manuelles. Des connecteurs doivent être définis pour permettre au processus d accéder à ces applications, parmi ces connecteurs on trouve le DCOM (Distributed Component Object Model) de Microsoft, CORBA (Common ObjectRequest Broker) de l'omg (Object Management Group), RMI (Remote Method Invocation), et enfin les services web qui utilisent le protocole SOAP pour allier les technologies Internet avec XML et le protocole Web HTTP. Cette dernière solution permet de répondre aux difficultés rencontrées avec les systèmes à objets distribués. De nos jours, les développeurs se tournent de plus en plus vers des solutions plus simples et plus souples basés sur le standard d échange de documents XML. Pour cette raison, les Services Web sont devenus le connecteur standard le plus utilisé pour interconnecter les différentes applications. La gestion des processus métier est, donc, une discipline qui consiste à orchestrer les processus métiers automatiquement en utilisant des technologies de Workflow et de l intégration des applications et données. Pour détailler ce dernier point, nous allons survoler, dans la section suivante, les technologies qui ont conduit au BPM. 1.3 Les racines du BPM Comme illustré dans la figure 1.3, le BPM prend ses racines dans la technologie du Workflow, et l intégration métier qu il s agisse d intégration des applications par flux de données (EAI), intégration par flux de messages (B2Bi) ou progiciels de gestion intégré (ERP). Le BPM prend sa source également dans toutes les expériences de mesure de performance, de la réingénierie du processus et aussi de tous les efforts de standardisation ayant gravité autour de la maîtrise des processus. 215

228 Annexe 1 Figure 1.3 Les racines du BPM [Ber04] L intégration métier Plusieurs approches et architectures ont été proposées afin de permettre à des applications hétérogènes d une entreprise de gérer leurs échanges. Les EAI (Enterprise Application Integration) sont une technologie permettant qui permet de faire communiquer les applications hétérogènes en organisant la circulation d informations entre les différentes applications constituant le système d'information de l'entreprise. L objectif étant d offrir des interfaces liées à un serveur central qui traite et redistribue les flux vers les applications du système, ainsi que des mécanismes de routage de messages en fonction du contexte du système. Cela permet de répondre au souci de réutilisabilité des entreprises en leur permettant de capitaliser sur les applications existantes. Néanmoins, les EAI ne peuvent pas gérer les processus interentreprise. En revanche, les outils de B2Bi, qui visent à définir les processus de collaboration entre entreprises partenaires par flux de messages, palient ce problème. Ces outils permettent de gérer une collaboration entre les partenaires en assurant la sécurité des échanges de messages, de la fiabilité du transport et le support des protocoles d échanges de messages tel que le protocole EDI. Cependant, les outils B2Bi ne gèrent que les processus externes de l entreprise. De ce fait, on aura deux outils différents pour gérer les processus internes et externes (les processus B2B), alors que ces deux types de processus participent, en réalité, à un même processus métier. Une autre façon d intégrer les processus d entreprise c est l utilisation des outils de gestion intégré appelé ERP (Enterprise Resource Planning traduit Progiciel de gestion intégré), ont été proposé afin d intégrer l ensemble des fonctions des processus opérationnels (la gestion des ressources humaines, la gestion comptable et financière, le processus de vente, de distribution, etc.) dans une seule plateforme. Cela permet d assurer une homogénéité des informations et facilite la communication interne et externe dans un système d information. Cependant, le périmètre fonctionnel, proposé par les ERP, sont souvent plus large que les besoins 216

229 Annexe 1 propres de l'entreprise. Cela s ajoute au coût assez élevé de mise en place de l'infrastructure de ces outils intégration. Parce que, les outils EAI et B2Bi ne proposent pas de solution prennent en compte les acteurs qui interviennent dans les processus métier, et les outils ERP imposent, aux entreprises, de s adapter aux processus définis par ces progiciels plutôt que l inverse, les outils BPM se positionnent pour unifier sous un seul outil toutes ces intégrateurs métier en s appuyant sur des standards, en gérant tous les processus métier de l entreprise et en permettant de définir des processus flexibles et sur mesure. Cet objectif ne va pas sans l'exigence de grandes capacités d intégration de l'outil dans le SI de l entreprise. Un exemple d'actualité est celui des Web Services où les éditeurs proposant des solutions concurrentes coopèrent désormais pour la définition des spécifications permettant à leurs outils de communiquer Les Workflow Le terme «Workflow»» est utilisé pour désigner la technologie qui vise l automatisation de la gestion des flux d'information et les tâches à accomplir entre les différents acteurs d'un processus [Jab96]. Le Workflow Management Coalition (WfMC) définit un Workflow comme : «L'automatisation, total ou partiel d'un processus métier, au cours de laquelle les documents, informations ou des tâches sont transmises d'un participant à un autre, en respectant un ensemble de règles» [WfMC99]. Selon Leymann et Roller, dans [Ley99], un Workflow, décrit les étapes qui sont exécutées automatiquement par une machine. A l inverse du processus qui représente le monde réel où il décrit les parties qui sont exécutées par une machine (dans ce cas, le Workflow et le processus sont synonymes), et les étapes qui ne sont pas exécutées par une machine (par exemple, la conversation avec un client). La figure 1.4 illustre cette distinction. Figure 1.4 le Processus et le Workflow [Ley99] La technologie Workflow a connu plusieurs générations au fil des années. La première génération de Workflow est destinée à automatiser la circulation des documents de bureau, comme les documentations ou les fac- 217

230 Annexe 1 tures, les bon de commande, etc. Ce type Workflow assure la coordination, la collaboration, et la co-décision des intervenants humains. L idée est que ce n'est pas l'utilisateur qui invoque le Workflow mais l'inverse. Ce Workflow est appelé Workflow ad-hoc. Afin d automatiser le routage répétitif de formulaires transversaux (demande de congés, demande de notes de frais), une deuxième génération Workflow est proposée. Il s'agit le plus souvent d'automatiser la manipulation de formulaires électroniques pour interagir avec le système d'information. Ce type de Workflow est appelé Workflow administratif. Contrairement aux deux générations précédentes, la troisième génération de Workflow automatise les processus métier d une entreprise en facilitant la définition des dépendances entre les tâches, et l exécution de tâches manuelles ou automatiques. Ce dernier type de Workflow est appelé Workflow de production. Un système de gestion de ce type de Workflow a le rôle d exécuter les processus métier. C est pour cette raison que les parties d'un processus métier qui peuvent être exécutées par un système informatique sont appelé Workflow [Deh03]. Dans la dernière décennie, de nombreuses recherches sur la technologie de Workflow ont été lancées ainsi que de nombreux logiciels de gestion de Workflow ont été développés. Cependant, selon Van der Aalst et al., dans [Van03 a], ces systèmes connaissent un problème fondamental dû au manque d un standard de modélisation des processus métier. En répondant à ce problème, les outils BPM sont considérés comme la prochaine étape après la vague du Workflow des années 90. Figure 1.5 Le positionnement du Workflow par rapport aux éléments d un BPM [Leu07] Comme montre la figure 1.5 la technologie Workflow peut être utilisée, principalement dans la phase d exécution du BPM, pour implémenter un modèle de processus en configurant et automatisant toutes les tâches 218

231 Annexe 1 de ce processus. Néanmoins, actuellement plusieurs éditeurs des systèmes de gestion de Workflow positionnent leurs systèmes comme des BPM en permettant la simulation et la vérification des modèles de processus et en collectant et interprétant, en temps réel, les données issues de l exécution des processus [Van03 a] Mesurer la performance et maîtriser les processus Au cours des années 80-90, plusieurs démarches, techniques, et normes de mesure de qualité des systèmes d information ont été proposées. En effet, les normes ISO 9000 sont décrites pour assurer la qualité et augmenter la satisfaction des clients dans les rapports clients-fournisseurs. La démarche TQM (Total Quality Management) est proposée pour impliquer l ensemble des processus d une entreprise pour mesurer et contrôler la qualité. La méthode Six Sigma est mise en place pour améliorer la qualité des processus de production en identifiant et en éliminant les causes d imperfection et l écart entre le modèle de processus et son exécution. Finalement les outils de BSC (Balanced Scorecard) permettent de mesurer et visionner les performances des activités d'une entreprise en vue de permettre aux managers une compréhension globale de leurs systèmes. Pour cela, ces outils utilisent des indicateurs clé de performance appelés KPI (Key Performance Indicator). Ce sont des métriques qui permettent évaluer les facteurs clés de succès des processus de l'entreprise. Il existe, une approche de réingénierie de processus métier BPR (Business Process Reengineering) qui vise à transformer les modèles des processus d une entreprise d une façon radicale dans le but d améliorer l'efficience et l'efficacité des ces processus. Pour cette raison, les processus existants sont d abord analysés pour identifier les dysfonctionnements (en se basant sur les indicateurs de performances) et des solutions d optimisation et d amélioration sont trouvées, pour finalement implémenter et valider les processus cibles. Les outils BPM viennent aujourd hui pour regrouper ces approches de mesure de performances et réingénierie de processus avec la technologie de l intégration métier et la technologie Workflow pour offrir une seul vision. 1.3 Le cycle de gestion d un processus Plusieurs visions du cycle de gestion d un processus métier ont été proposées (exemple [Van03 a], [Ber04], [Net06] et [Leu07]). D une façon géné- 219

232 Annexe 1 rale, ces visions se résument selon trois axes : la phase de modélisation, la phase d exécution et la phase de diagnostic (voir la figure 1.6). Dans cette section nous allons détailler ces trois phases. Figure 1.6 Le cycle de vie d un processus métier La phase de modélisation Dans cette phase, les concepteurs définissent, d'une manière abstraite ou détaillée, les processus métier ou redéfinissent un processus existant dans le but de l'améliorer. Pour cela, des modèles et des langages sont utilisés afin de permettre de décrire les éléments de base d un processus. En effet, cette phase est composée de trois étapes [Cru03]: (1) la première étape de cette phase, permet de définir un processus de haut niveau, indépendamment des aspects techniques. Le concepteur décrit seulement la structure, les ressources nécessaires et les interfaces du processus. Dans cette étape, des langages graphiques sont utilisés comme UML [OMG08] et BPMN [OMG09]. (2) La deuxième étape de la phase de modélisation est la configuration des processus abstraits où les détails fonctionnels du processus sont spécifiés. Le concepteur décrit de nombreuses informations techniques telles que : le format des messages échangés, les protocoles de transport utilisés, les services et les applications invoquées dans le processus. Dans cette étape, des langages d exécution sont utilisés comme XPDL [WfMC08] et BPEL [OASIS07]. (3) La dernière étape de cette phase est l'évaluation du processus exécutable en utilisant les techniques de simulation (appelé BPS) ou de la vérification formelle (exemple du réseau de Pétri) en vue de s assurer du bon fonctionnement du processus avant son exécution. Dans cette étape, le processus peut être optimisé en utilisant les résultats de simulation pour définir des éventuelles améliorations. Le processus est ensuite redéfini et simulé ou vérifié de nouveau. 220