thèses de l'insa de lyon | les thèses de l'insa de lyon - gestion...

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 Professeur (INSA de Lyon), Directeur de thèse

Aïcha-Nabila Benharkat Maître de conférence (INSA de Lyon), Directrice de thèse

Jean-Pierre Giraudin Professeur (Université Pierre Mendès France), Président

Corine Cauvet Professeur (Université Aix-Marseille), Rapportrice

Ahmed LBATH Professeur (Université Joseph Fourier), Rapporteur

Selmin Nurcan Maître de conférence (Université Paris 1), Examinatrice

Zakaria Mamaar Professeur (Université Zayed), Invité

Laboratoire de recherche : Laboratoire d’Informatique en Image et

Systèmesd’Information

Remerciements

À ma chère épouse

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.

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.

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.

Table des matières

TABLE DES MATIERES

1 INTRODUCTION _______________________________________________________________ 1 1.1 Contexte et terminologie ____________________________________________________ 1

1.1.1 Un processus métier ___________________________________________________________ 2 1.1.2 La gestion de processus métier (BPM) _____________________________________________ 2 1.1.3 La modélisation des processus métier ______________________________________________ 3 1.1.4 La flexibilité de la modélisation __________________________________________________ 3 1.1.5 Les règles métier ______________________________________________________________ 3

1.4 Organisation de la thèse ____________________________________________________ 7

PARTIE 1 : ETAT DE L’ART _____________________________________________________________ 1

2 MODELES ET LANGAGES DE PROCESSUS METIER _______________________________________________ 10 2.1 Introduction ___________________________________________________________________ 10 2.2 Le modèle impératif vs modèle déclaratif du processus métier ____________________________ 11 2.3 Les langages impératifs de modélisation le processus métier _____________________________ 12

2.3.1 Les Langages de définition de haut niveau _________________________________________ 13 2.3.2 Les Langages d’exécution de processus métier _____________________________________ 17 2.3.3 La traduction des langages graphiques vers les langages d’exécution ____________________ 21

2.4 Les langages déclaratifs de modélisation du processus métier ____________________________ 21 2.4.1 Le paradigme case-handling ____________________________________________________ 21 2.4.2 Le paradigme de la logique temporelle linéaire (LTL) ________________________________ 22 2.4.3 Le paradigme de logique déontique ______________________________________________ 22 2.4.4 Le paradigme Event-driven process ______________________________________________ 22 2.4.5 Le paradigme rule based modeling _______________________________________________ 23

2.5 Conclusion ____________________________________________________________________ 24

3 CARACTERISTIQUES DES MODELES & LANGAGES DE PROCESSUS METIER _____________________________ 25 3.1 Introduction ________________________________________________________________ 25 3.2 L’expressivité de la modélisation d’un processus métier _____________________________ 26

3.2.1 La dimension fonctionnelle __________________________________________________ 27 3.2.2 La dimension comportementale _______________________________________________ 27 3.2.3 La dimension organisationnelle _______________________________________________ 30 3.2.4 La dimension informationnelle ________________________________________________ 30 3.2.5 La dimension opérationnelle__________________________________________________ 31 3.2.6 Synthèse _________________________________________________________________ 32 3.2.7 Un exemple d’un processus métier _____________________________________________ 33

3.3 La flexibilité de la modélisation des processus métier ________________________________ 36 3.3.1 Les taxonomies de la flexibilité _______________________________________________ 36

3.4 Les caractéristiques des langages de processus _____________________________________ 38 3.4.1 Les caractéristiques des langages impératifs _____________________________________ 38 3.4.2 Les caractéristiques des langages déclaratifs _____________________________________ 41

3.5 Conclusion _________________________________________________________________ 43

Table des matières

4 MODELISATION DES PROCESSUS METIER BASEE SUR LES REGLES __________________________________ 45 4.1 Introduction ____________________________________________________________________ 45 4.2 Classification des règles et langages de règles ________________________________________ 46

4.2.1 Catégories de règles __________________________________________________________ 46 4.2.2 Les langages de règles ________________________________________________________ 47

4.3 La modélisation des processus métier par les règles de réaction _________________________ 51 4.3.1 Le formalisme ECA __________________________________________________________ 51 4.3.2 Les avantages des règles de réaction _____________________________________________ 52 4.3.3 Les langages de processus basés sur les règles de réaction ____________________________ 53 4.3.4 Les limites & chalenges des règles de réaction _____________________________________ 55

4.4 Conclusion ______________________________________________________________________ 56

5 TECHNIQUES DE VERIFICATION DE PROCESSUS METIER __________________________________ 58 5.1 Introduction ____________________________________________________________ 58 5.2 Les erreurs et exceptions d’un processus métier _____________________________ 59

5.2.1 Les erreurs fonctionnelles____________________________________________________ 59 5.2.2 Les erreurs opérationnelles ___________________________________________________ 59 5.2.3 Les erreurs non fonctionnelles ________________________________________________ 59

5.3 Les techniques de vérification des processus métier __________________________ 60 5.3.1 La vérification par guides de style de modélisation ________________________________ 60 5.3.2 La vérification par simulation ________________________________________________ 60 5.3.3 La vérification par modèles formels ____________________________________________ 61 5.3.4 La vérification par process-mining _____________________________________________ 61 5.3.5 Synthèse _________________________________________________________________ 62

5.4 Introduction aux modèles formels et aux réseaux de Pétri ______________________ 62 5.4.1 Définition ________________________________________________________________ 62 5.4.2 Utilisation ________________________________________________________________ 63 5.4.3 Classification _____________________________________________________________ 63 5.4.4 Les réseaux de Pétri ________________________________________________________ 65

5.5 La vérification des processus métier ______________________________________ 70 5.5.1 La vérification dans le cas des langages impératifs ________________________________ 70 6.5.1 La vérification dans le cas des langages déclaratifs ________________________________ 72

3.1 Conclusion __________________________________________________________ 73

PARTIE 2 : NOTRE CONTRIBUTION ____________________________________________________ 74

INTRODUCTION ______________________________________________________________________ 75

6 MODELE ECAPE-M ___________________________________________________________________ 78 6.1 Introduction ____________________________________________________________________ 78 6.2 Le formalisme ECAPE ____________________________________________________________ 79 6.2 Modèle ECAPE-M _______________________________________________________________ 80 6.3 Exemple illustratif _______________________________________________________________ 81 6.4 L’expressivité du flux de contrôle ____________________________________________________ 83

6.4.1 La séquence de règles ________________________________________________________ 83 6.4.2 Le parallélisme de règles ______________________________________________________ 84 6.4.3 La synchronisation de règles ___________________________________________________ 84 6.4.4 Le choix exclusif de règles _____________________________________________________ 85 6.4.5 La jonction simple de règles ____________________________________________________ 86 6.4.6 La boucle de règles ___________________________________________________________ 86

6.5 Les différents plans du modèle ECAPE-M _____________________________________________ 87 6.5.1 Le plan métier _______________________________________________________________ 88 6.5.2 Le plan comportemental _______________________________________________________ 88

Table des matières

6.5.3 Le plan opérationnel __________________________________________________________ 89 6.6 Conclusion ____________________________________________________________________ 89

7 LE LANGAGE ECAPE-L ________________________________________________________________ 90 7.1 Introduction ____________________________________________________________________ 90 7.2 Les éléments du langage ECAPE-L______________________________________________ 91

7.2.1 Le processus ________________________________________________________________ 92 7.2.2 Participants _________________________________________________________________ 94 7.2.3 Les variables ________________________________________________________________ 96 7.2.4 Les activités ________________________________________________________________ 98 7.2.5 Les événements ______________________________________________________________ 99 7.2.6 Les règles ECAPE __________________________________________________________ 102

7.3 Exemple illustratif ________________________________________________________ 109 7.4 L’expressivité du langage ECAPE-L ____________________________________________ 112 7.5 La représentation graphique du ECAPE-L _______________________________________ 114 7.6 Conclusion ______________________________________________________________ 115

8 DEMARCHE DE GESTION DU CHANGEMENT D’ UN PROCESSUS METIER BASEE SUR LES REGLES _____________ 118 8.1 Introduction ___________________________________________________________________ 118 8.2 Démarche de gestion du changement ________________________________________________ 119 8.4 Les relations entre les règles ______________________________________________________ 121

8.4.1 Les relations de déclenchement ________________________________________________ 122 8.4.2 Les relations de partage de variables ____________________________________________ 127

8.5 Le graphe d’impacts _____________________________________________________________ 132 8.6 L’impact du changement d’une règle ________________________________________________ 133

8.6.1 L’ajout d’une règle __________________________________________________________ 136 8.6.2 La modification d’une règle ___________________________________________________ 137 8.6.3 La suppression d’une règle ____________________________________________________ 142 8.6.4 Synthèse __________________________________________________________________ 143

8.7 Le coût du changement d’une règle _________________________________________________ 145 8.8 Le degré de tolérance aux changements d’un processus _________________________________ 150

8.9 Conclusion ______________________________________________________________________ 151

9 VERIFICATION DU PROCESSUS METIER PAR LE ECAPE-NET ___________________________________ 153 9.1 Introduction ____________________________________________________________________ 153 9.2 Le ECAPE-net ___________________________________________________________________ 155

9.2.1 Les éléments du ECAPE-net ___________________________________________________ 155 9.2.2 Définition formelle du ECAPE-net ______________________________________________ 157 9.2.3 Les règles de franchissement des transitions dans le ECAPE-net ______________________ 159 9.2.4 La construction des événements composés ________________________________________ 161 9.2.5 Exemple illustratif __________________________________________________________ 165

9.3 La vérification du processus par le ECAPE-net _________________________________________ 168 9.3.1 Propriétés du réseau bien structuré ______________________________________________ 168 9.3.1 Propriétés de sureté _________________________________________________________ 170

9.4 Conclusion ______________________________________________________________________ 171

PARTIE 3 : VALIDATION ______________________________________________________________ 172

10 PLATEFORME BP-FAMA _______________________________________________________________ 173 10.1 Introduction __________________________________________________________________ 173 10.2 Architecture générale de BP-FAMA ________________________________________________ 173

10.2.1 La phase de spécification ______________________________________________________ 175 10.2.2 La phase d’exécution _________________________________________________________ 175

Table des matières

10.2.3 La phase de diagnostic ________________________________________________________ 176 10.2.4 Les outils de développement de BP-FAMA ________________________________________ 176

10.3 Editeur du langage ECAPE-L _____________________________________________________ 177 10.4 Gestionnaire du changement _____________________________________________________ 179 10.5 Simulateur d’exécution __________________________________________________________ 181 10.6 Conclusion ___________________________________________________________________ 183

PARTIE 4 : CONCLUSION GENERALE __________________________________________________ 185

11 CONCLUSION GENERALE ________________________________________________________________ 186 11.1 Résumé de la contribution _______________________________________________________ 186 11.2 Perspectives envisagées __________________________________________________________ 189

BIBLIOGRAPHIE _____________________________________________________________________ 191

ANNEXE 1 : ETAT DE L’ART SUR LA GESTION DES PROCESSUS METIER (BPM) ___________ 210

1.1 Introduction _________________________________________________________________ 211 1.2 Terminologie ________________________________________________________________ 212

1.2.1 Un processus ___________________________________________________________ 212 1.2.2 Un processus métier ______________________________________________________ 212 1.2.3 La gestion des processus métier (BPM) _______________________________________ 214

1.3 Les racines du BPM ___________________________________________________________ 215 1.3.1 L’intégration métier ______________________________________________________ 216 1.3.2 Les Workflow ___________________________________________________________ 217 1.3.3 Mesurer la performance et maîtriser les processus_______________________________ 219

1.3 Le cycle de gestion d’un processus _______________________________________________ 219 1.4.1 La phase de modélisation __________________________________________________ 220 1.4.2 La phase d’exécution _____________________________________________________ 221 1.4.2 La phase de diagnostique __________________________________________________ 221

1.5 Les systèmes de gestion des processus (BRMS) ______________________________________ 222 1.6 Conclusion __________________________________________________________________ 223

ANNEXE 2 : SCHEMA XML DU LANGAGE RBBPDL ______________________________________ 225

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 r3 __________________________148 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

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

Introduction

1

1 Introduction

1.1 Contexte et terminologie

1.1.1 Un processus métier

1.1.2 La gestion de processus métier

1.1.3 La modélisation des processus métier

1.1.4 La flexibilité de la modélisation

1.1.5 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 entrepri-ses 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 effi-cace des organisations, impose de s’appuyer sur des processus métiers ro-bustes, et adaptés à leurs activités. La définition et l’exécution des ces pro-cessus 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 Mana-gement, 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 fonction-nelles 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.

Introduction

2


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 proces-

sus métier comme : « un ensemble d'une ou plusieurs procédures ou activi-tés liées entre elles pour réaliser collectivement un objectif ou une politi-que 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 va-leur ajoutée aux clients.

1.1.2 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 au-tres 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 entre-prise. (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.

Introduction

3

1.1.3 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 utili-sés afin de permettre de décrire les éléments de base d’un processus. En ef-fet, 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 pro-cessus 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.

1.1.4 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 modi-fiant que les parties qui ont besoin d'être changées tout en gardant la stabi-lité 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ète-ment.

1.1.5 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

Introduction

4

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 politi-ques d’une entreprise et elles permettent d'influencer les prises des déci-sions 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 propo-sé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élisa-tion 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éri-fier le déroulement du processus exécutable pour s’assurer du son bon fonctionnement. Autrement dit, améliorer la gestion des processus en ga-rantissant 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 pro-cessus. 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 pro-cessus.

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 uti-lisant les liens (ou connecteurs) entre les activités. Plusieurs langages, ba-sés sur cette approche ont été proposés (exemple BPEL, XPDL). Ces lan-gages impératifs sont maintenant stables et se sont adaptés aux besoins du

Introduction

5

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éna-rii d’exécution dans la phase de modélisation. Cette pratique rend les pro-cessus métier rigides et difficiles à maintenir. La nature dynamique des en-vironnements 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 change-ments. Dans ce contexte, une deuxième approche de modélisation de pro-cessus dite déclarative a été proposée. Cette se concentre sur « ce qui de-vrait ê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 pro-cessus. 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 rempla-cent, 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 mo-dé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 rigi-dité 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 proces-sus, 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 mo-dalisation et une fiabilité à l’exécution du processus. En effet, l’utilisation

Introduction

6

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 sui-vants : 1- Quel formalisme de règle est le plus adapté pour modéliser un proces-

sus 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 chan-gement ?

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 pro-cessus 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 [Compensa-tion ou Evénement d’erreurs] (ECAPE-CE abrégé ECAPE). Le forma-lisme 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.

Introduction

7

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 ap-pelé 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 uti-lisé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 proces-sus et pouvoir vérifier formellement le bon fonctionnement du proces-sus. En effet, pour aider le concepteur à trouver les erreurs fonctionnel-les 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ésen-tons une comparaison entre les modèles et langages de définition des pro-cessus en se basant sur deux critères qui sont au cœur de nos préoccupa-

Introduction

8

tions à savoir l’expressivité et la flexibilité. Nous distinguons dans le cha-pitre 4 les différents formalismes de règles ainsi que les langages de mo-dé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 contribu-

tion. 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 uti-lisant 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 change-ment 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).

Partie 1 Etat de l’art

Etat de l’art / Modèles & langages des processus métier

10

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

2.3.2 Langages impératifs de définition de haut niveau de processus métier

2.3.3 Langages impératifs d’exécution de processus métier

2.3.4 La traduction des langages graphique vers les langages d’exécution

2.4 Les langages du modèle déclaratif

2.4.1 Le paradigme case-handling

2.4.2 Le paradigme logique temporelle linéaire (LTL)

2.4.3 Le paradigme logique déontique

2.4.4 Le paradigme Event-driven process

2.4.5 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 mo-dè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 impo-sées de l'extérieur tels que les exigences juridiques, les normes et les con-trats) ; 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


11

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 fonction-nement 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 ma-nière explicite (l’approche impérative) ou d’une manière explicite (l’approche 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 lan-gages déclaratifs tous les chemins d'exécution, qui ne violent pas les con-traintes, 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éclara-tive offre beaucoup plus de chemins d'exécution.

(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


12

Le tableau 4.1 présente une comparaison entre les deux approches de modélisation de processus. Premièrement, dans la modélisation impéra-tive 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 ma-niè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 pro-cessus 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éra-tifs 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).

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]


13

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).

2.3.1 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 mo-délisation et générer ensuite le code exécutable associé.

2.3.1.1 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 (dia-gramme 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

Figure 2.2 l’historique des différents langages impératifs [Leu07]


14

[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]. 2.3.1.2 Le langage YAWL

Le langage YAWL1 (Yet Another Workflow Language) [Van02] . Ce lan-

gage 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 con-trô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écem-ment 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.

2.3.1.3 Le standard BPMN

Le langage BPMN (Business Process Modeling Notation) est proposé par le consortium BPMI (Business Process Management Initiative), qui re-groupe 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 informa-tions 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 ap-pliquée aux processus. D’ailleurs, l’OMG soutient actuellement le BPMN, et cela depuis sa fusion avec BPMI.org en 2005. Aujourd’hui, La spécifica-tion 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.


15

nous allons, dans la prochaine section, détailler la spécification BPMN en présentant une représentation BPMN du processus de traitement de com-mande de l’exemple vu dans le précédent chapitre.

2.3.1.4 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 plu-sieurs 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 re-présentent les activités ; les flèches pleines lient les connecteurs et les acti-vité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, tan-dis 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 colla-borent pour traiter une commande.


16

Figure 2.3 Une représentation BPMN du processus de traitement de commande

Evénement de fin de processus

Un flux de séquence

Evénement de début de processus


Evénement timer

Evénement réception de message

Connecteur parallèle

Une activité

Connecteur parallèle

Connecteur choix exclusif basé

sur les données

Evénement réception de message

Connecteur choix exclusif basé sur les événements


Un flux de message


17

2.3.2 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.

2.3.2.1 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éfinis-sant les activités, les transitions, les partenaires et les interactions entre eux. XPDL est adopté par la plupart des moteurs de workflow.

2.3.2.2 Le langage ebXML

Le langage ebXML (Electronic Business using eXtensible Markup Lan-guage) est né du besoin d’avoir une suite de spécifications pour le projet commun entre OASIS (Organization for the Advancement of Structured In-formation Standards) et UN/CEFACT (United Nations Centre for Trade Fa-cilitation 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 proto-coles 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.


18

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]. Toute-fois, 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.

2.3.2.3 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 ser-vices Web à deux niveaux : le premier niveau appelé flow models (modèles d’activités) spécifie comment réaliser un but métier particulier; typique-ment, le résultat est une description d'un processus métier. Le deuxième ni-veau nommé global models (modèles globaux) spécifie le modèle d'inte-raction d'une collection de services de Web, dans ce cas, le résultat est une description des interactions globales entre partenaires. 2.3.2.4 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


19

profit de la norme connue sous le nom de BPEL (Business Process Execu-tion Language). 2.3.2.5 Le standard BPEL

Le consortium BPMI (Business Process Management Initiative) a proposé, en plus de PBMN, la spécification BPEL (Business Process Execution Lan-guage). 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 synchroni-sation 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. . 2.3.2.6 Un cas d’utilisation du BPEL

La structure globale d’un processus BPEL est décrite par les clauses sui-vantes : <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 va-riables qui sont utilisées par les activités et qui sont utilisées aussi dans la description des comportements du processus (la dimension information-nelle). Ces variables servent aussi à déterminer les types de messages échangés au sein du processus (la dimension opérationnelle). La partie


20

« Partnerlinks » permet de représenter les participants qui ont pour rôle d’exécuter les activités du processus (la dimension organisationnelle) et ce-la 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).

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 per-mettent de décrire les comportements du processus (la dimension compor-tementale) 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.

Figure 2.4 Le sous processus BPEL de traitement de commande


21

2.3.3 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 re-présentation graphique (BPMN, UML) faciliterait le travail de conception, le code BPEL peut être généré par la suite grâce à une traduction automa-tique. Pour cela, plusieurs auteurs ont proposé des algorithmes de traduc-tion 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éli-sation 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 chan-gements. 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éclara-tifs, 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éclara-tifs 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éclara-tifs utilisent différents paradigmes pour représenter les états et les con-traintes.

2.4.1 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 struc-tures de contrôle de processus prédéfinis pour déterminer « ce qui doit être


22

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 per-mettre 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.

2.4.2 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 lo-gique 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, de-venir vraie, etc. Ce paradigme a été utilisé dans un langage ConDec, propo-sé 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.

2.4.3 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 va-riantes possibles d’une exécution d’une activité métier : l'obligation, l'in-terdiction, 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éon-tiques pour modéliser un processus et en utilisant les agents pour effectuer une activité particulière dans un délai indiqué.

2.4.4 Le paradigme Event-driven process

Le paradigme Event-driven process (processus orienté événements) est pro-posé pour modéliser et gérer les processus par des événements en utilisant le formalisme émergent CEP (Complex Event Processing). Ce dernier per-met 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é-


23

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 partici-pants) et les événements qui déclenchent l’exécution des fonctions. Pour ce-la, cette méthode propose des connecteurs logiques pour permettre de construire des événements complexes.

2.4.5 Le paradigme rule based modeling

Le paradigme rule based modeling (modélisation basée sur les règles) pro-pose de modéliser la logique du processus par un ensemble de règles en uti-lisant des langages déclaratifs. L’exécution des ces langages est souvent as-suré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 troi-siè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 construc-tion d’un vocabulaire métier (les concepts et termes) à utiliser dans la défi-nition les règles métier. Finalement, notons que de nombreux éditeurs ont


24

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 mo-dè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 con-trô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 ges-tion 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 lan-gages 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é.

Etat de l’art / Caractéristiques des modèles & langages de processus métier

25

3 Caractéristiques des modèles & langages de

processus métier

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 fonc-tionnelles.

Plusieurs caractéristiques doivent être prises en compte lors de la modélisation de processus métier, parmi lesquelles nous pouvons citer [Lu07] :

3.1 Introduction

3.2 L’expressivité de la modélisation d’un processus

3.2.1 La dimension fonctionnelle

3.2.2 La dimension comportementale

3.2.3 La dimension organisationnelle

3.2.4 La dimension informationnelle

3.2.5 La dimension opérationnelle

3.2.6 Synthèse

3.2.7 Un exemple d’un processus métier

3.3 La flexibilité de la modélisation d’un processus

3.3.1 Les taxonomies de la flexibilité

3.2.1.1 La taxonomie de Regev et al.

3.2.1.2 La taxonomie de Schonenberg et al.

3.4 Les caractéristiques des langages de processus

3.4.1 Les caractéristiques des langages impératifs

3.4.1.1 L’expressivité des langages impératifs

3.4.1.2 La flexibilité des langages impératifs

3.4.2 Les caractéristiques des langages déclaratifs

3.4.2.1 L’expressivité des langages déclaratifs

3.4.2.2 La flexibilité des langages déclaratifs

3.5 Conclusion


26

• 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 carac-téristiques de modélisation que nous retenons comme propriétés essen-tielles 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 peu-vent ê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 or-ganisationnelle, 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 appe-lé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-


27

ser les flux de contrôle d’un processus métier. En plus, ils peuvent être uti-lisés comme une base de comparaison entre les différents systèmes de ges-tion de processus, ou entre les différents langages de modélisation de pro-cessus.

Nous allons détailler dans la section suivante les dimensions et les patrons utilisés dans une modélisation des processus métier.

3.2.1 La dimension fonctionnelle

La dimension fonctionnelle représente les éléments du processus à exécu-ter. 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 proces-sus 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 hu-maine, 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 conte-nir plusieurs autres activités composées ou élémentaires, cette activité est alors appelée un sous processus.

3.2.2 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épen-dances 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 rela-tions sont la formalisation des décisions à prendre (quelle branche du pro-cessus 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 con-traindre, 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-


28

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 con-trô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 pa-trons. Ces modèles ont été largement utilisés par les éditeurs et les universi-taires 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 :

3.2.2.1 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.

3.2.2.2 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).

3.2.2.3 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.

Figure 3.1 Le patron de séquence

Figure 3.2 Le patron de parallélisme


29

3.2.2.4 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 fonc-tion d’une certaine condition. 3.2.2.5 La jonction simple

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. 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 pa-

trons, sous forme de connecteurs (quelle branche du processus on doit choi-sir): 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-

Figure 3.3 Le patron de synchronisation

Figure 3.4 Le patron du choix exclusif

Figure 3.5 Le patron de jointure simple


30

mettre à une instance d’un processus, lors de son exécution, de passer qu’une fois par une jonction unique.

3.2.3 La dimension organisationnelle

La dimension organisationnelle représente les ressources qui ont la respon-sabilité d’exécuter les éléments d’un processus. Ces ressources sont appe-lées participants parce qu’elles participent à la réalisation de l’objectif glo-bal 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 propo-sent 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 Al-location) 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].

3.2.4 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 pa-trons 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 di-visés en quatre groupes :


31

3.2.4.1 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). 3.2.4.2 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 pas-sage 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). 3.2.4.3 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 uti-lisant 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). 3.2.4.4 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 proces-sus. 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].

3.2.5 La dimension opérationnelle

La dimension opérationnelle représente les détails opérationnels d’un pro-cessus métier. Ces détails représentent, en effet, les informations tech-niques utilisées lors de l’exécution du processus comme : le format des


32

messages échangés, les protocoles de transport utilisés et le mode d’invocation (synchrone ou asynchrone).

3.2.6 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 pro-cessus et les principaux patrons de Workflow de chaque dimension :

Les dimensions du processus Les principaux élé-

ments Les principaux patrons

La dimension fonctionnelle Activité Activité manuelle Activité automatique

La dimension comportementale Flux de contrôle (connecteur)

La séquence La branche parallèle La synchronisation Le choix exclusif La jonction simple La boucle structurée Annulation d’activité

La dimension organisationnelle Participant (res-

source)

Allocation directe Allocation aléatoire Allocation basée sur le rôle Délégation

La dimension informationnelle Données

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é

La dimension opérationnelle Informations tech-niques : protocoles,

langages, …


33

3.2.7 Un exemple d’un processus métier

Pour illustrer quelques éléments d’un processus métier, nous allons présen-ter 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 livrai-son) 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 uni-té 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 li-vraison » se déclenche après la terminaison de l’activité « Choisir un li-vreur »; 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 « De-mander 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 termi-naison 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 lan-cer deux tâches en parallèle) ou des contraintes (le client le choix de payer en espèces ou avec CB).


34

Figure 3.6 La modélisation du processus de traitement de commande


35

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 per-sonne 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 com-mande, les activités utilisent et produisent des données. En effet, ces don-né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éali-ser ce transfert, on peut utiliser soit des copies de données qui sont sauve-gardé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 li-vreur», l’adresse du client doit être mentionnée dans la commande (le pat-tern Task Precondition - Data Existence).

La figure 3.6, représente une modélisation de haut niveau du pro-cessus 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 dimen-sion informationnelle et la dimension opérationnelle ne sont pas représen-té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éli-sation utilisé. En plus, le fait de définir explicitement les flux de contrôle, rend le processus rigide et difficile à changer.


36

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 sou-plesse 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.

3.3.1 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 : 3.3.1.1 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 activi-tés du processus (dimension fonctionnelle), les flots de contrôle (di-mension comportementale), les données du processus (dimension in-formationnelle) 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 radi-cal 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 chan-gement qui peut être soit planifiée ou ad hoc.


37

3.3.1.1 La taxonomie de Schonenberg et al.

Dans son papier [Sch07], Schonenberg et al. proposent une deuxième taxo-nomie qui s’intéresse à la flexibilité du point de vue opérationnel. Pour ce-la, 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 ac-tivité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 en-core 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 cer-taines 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-

Figure 3.7 La taxonomie de la flexibilité proposée par Regev [Rev06]


38

sieurs alternatives ou la modélisation tardive pour spécifier des frag-ments à 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éfini-tion 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 ca-pacité de mettre en œuvre les changements dans un processus métier sans toucher à la stabilité des autres parties du processus. Pour cela ces deux ca-ractéristiques doivent être prises en compte par les langages de modélisa-tion et cela afin d’offrir aux experts une meilleure maîtrise de ces proces-sus. 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 ef-fet, 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éris-tiques.

3.4.1 Les caractéristiques des langages impératifs

3.4.1.1 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


39

multiple (la possibilité de choisir une branche parmi plusieurs lancé en pa-rallè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 conclu-sion de cette comparaison montre que BPMN est le mieux adapté à modéli-ser 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 lan-gages les plus adoptés dans l’industrie. 3.4.1.2 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 Goe-dertier [Goe06 b] l’origine de cette dynamicité vient essentiellement du changement fréquent dans les réglementations extérieures que doit respec-ter l’entreprise et aussi le changement de politiques intérieures définies par l’entreprise. Ces réglementations et politiques métier sont souvent expri-mé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 (flexi-bilité 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 compro-met la flexibilité du modèle (pas de flexibilité par déviation, ni par spécifi-cation partielle, ni flexibilité par changement selon la taxonomie de Schonenberg et al [Sch07]) .


40

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 rigidi-té 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 pou-vons 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 facili-ter 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 uti-lisé comme un pont entre les règles métiers et le processus BPEL en défi-nissant deux types d’interception le « avant » l’activité et le « après » acti-vité. 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 im-pé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 pro-grammation 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 propo-sée par Van Eijndhoven et al. dans [Van08] suggérant l'utilisation des pa-trons 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 plate-forme spécifique. En effet, dans cette plateforme, un processus peut conte-nir, en plus des activités et les flux de contrôles prédéfinis, des sous-processus, 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 con-traintes qui contrôlent l’ordre d’exécution des ces activités. Un dernier


41

exemple des extensions des langages impératifs est le travail de Boukhe-bouze et al. dans [bou08] qui proposent d’identifier des règles dans un mo-dè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 con-cerne 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 lan-gage 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.

3.4.2 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 ? 3.4.2.1 L’expressivité des langages déclaratifs

Selon plusieurs travaux qui ont été menés pour étudier la couverture des pa-trons des flux de contrôle par les langages déclaratifs, ces derniers suppor-tent, d’une manière implicite, les patrons de bases (le parallélisme, la syn-chronisation, le choix exclusif, la jonction simple). Par contre, chaque langage supporte un sous ensemble des autres patrons. Cela dépend des pa-radigmes 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 case-handling, 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 plu-sieurs points de sortie). Par contre, la méthode EPC supporte le patron des boucles arbitraires, mais ne supporte pas la jointure multiple (la conver-gence 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 tempo-relles, en plus des obligations et les autorisations dans les interactions mé-


42

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 ca-pables d’exprimer les exigences temporelles (comme par exemple les con-ditions temporelles ou les délais d’exécution d’une activité). Ce qui est avantageux par rapport aux langages impératifs. 3.4.2.2 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 en-treprises ont besoin de langages flexibles capables d’implémenter les chan-gements 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 tar-dive 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 modi-fier 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éfi-nition 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éfini-tion initiale en permettant par exemple de défaire, de refaire ou de court-circuiter certaines activités (flexibilité par déviation selon la taxonomie de


43

Schonenberg et al [Sch07]), comme le cas des langages qui utilisent le pa-radigme 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 expressi-vité. 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 na-ture dynamique des environnements des organisations, rend les éléments du processus susceptibles d’être modifiés ou supprimés. Le fait de définir ex-plicitement, dans la phase de modélisation, la façon dont les processus de-vraient 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é propo-sé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 ma-niè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 flexibi-lité 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 de-vons 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 utili-sent différentes syntaxes, nous avons pensé utile de présenter les forma-


44

lismes et langages de règles existants et les différents travaux qui ont adap-té une approche basée sur les règles pour la modélisation un processus mé-tier.

Etat de l’art / Modélisation de processus basée sur les règles

45

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

4.2.1 Les différents types de règles

4.2.1.2 Les règles de dérivation

4.2.1.3 Les règles de production

4.2.1.4 Les règles de réaction

4.2.1.5 Les règles de transformation

4.2.2 Les langages de règles

4.2.2.1 Langages du modèle métier indépendant de l'informatisation

4.2.2.2 Langages du modèle indépendant de la plate-forme

4.2.2.3 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

4.3.1 Le formalisme ECA

4.3.2 Les avantages des règles de réaction

4.3.3 Les langages de processus basés sur les règles de réaction

4.3.4 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 permet-tent 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 struc-turé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 poli-tiques d’une entreprise. Elles sont aussi utilisées pour modéliser un proces-sus 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.


46

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 direc-tives 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 doi-vent pouvoir valider et enrichir la base de connaissance « knowledge repository»

Dans la littérature, plusieurs catégories de règles ainsi que plu-

sieurs 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.

4.2.1 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. 4.2.1.1 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. 4.2.1.2 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%.


47

4.2.1.3 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.

4.2.1.4 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. 4.2.3.1.5 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.

4.2.2 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 na-turel [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 ce-la, plusieurs langages de règles ont été proposés pour formaliser la défini-tion des règles métiers. En effet, ces langages utilisent différents forma-lismes pour définir, d’une manière déclarative, les règles métier.

Selon Wagner [Wag05], ces langages peuvent être classés en ac-cord 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 nou-veaux langages (exprimé en pointillé dans la figure 4.1).


48

Figure 4.1 Les la

ngages de rè

gles aux diffé

rents niveaux d'abstra

ctio

n [W

ag05]


49

4.2.2.1 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) utili-sés pour exprimer les règles métier. Pour cela, la définition d’un vocabu-laire 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 des-cription du vocabulaire métier séparément des règles métier. Cela permet de partager ce vocabulaire pour une standardisation des structures de don-né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 on-tologies comme le langage de règle d’OWL [W3C04 a] et le langage RDF [W3C99 a].

4.2.2.2 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 lan-gages, sont proposés pour formaliser la définition des règles. Les forma-lismes 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 do-cument 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 (Trig-gers) 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 Ru-leML 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


50

[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 visualisa-tion. 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 per-met 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].

4.2.2.3 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 pro-posé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 ob-jets 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 cas-cade 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 mo-teur 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 syn-taxes. 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.


51

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 ba-sent les règles de réaction, permet de spécifier le flux de contrôle d’un pro-cessus 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 for-malisme 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 li-mites du modèle du processus ECA.

4.3.1 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 <Event> IF <Condition> DO <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 satis-faite, alors la partie action est exécutée en tenant compte des attributs asso-ciés à la règle.


52

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).

4.3.2 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 ex-primées sous forme de règles en utilisant le langage naturel ou formel. En particulier, dans les exigences des processus métier, on trouve sou-vent 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 enre-gistré 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 sui-vante « 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 (condi-tion), 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 transforma-tions suivante « Le salaire d’un employé doit être changé de ma-niè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


53

être exécuté en évaluant les événements de l’ensemble de règles défi-nies.

- 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 excep-tion 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 ex-primé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]

4.3.3 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 :


54

Travail Auteurs Résumé La plateforme AgFlow

Zeng et al. dans [Zen02]

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

Chulsoon et al. dans [Chu04]

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.

La plateforme AgentWork

Müller dans [Mul04]

Une plateforme de définition des Workflow est proposée. Cette plateforme, appelée AgentWork, se base sur la technologie des agents pour diagnosti-quer 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.

Modèle de proces-sus basé sur les règles E-C-A

Knolmayer et al. [Kno00]

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

Object-Rule- Role approach

Kappel et al. [Kap00]

Une plateforme de modélisation du Workflow ba-sé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 Work-flow.

Le langage XChange

Bry et al. [Bry06 b]

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.

Modélisation des services web par l’URML

Wagner et al. [Wag06]

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.


55

Tableau 4.1 Les principaux travaux de modélisation de processus basée sur les règles ECA

4.3.4 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 sui-vantes :

- 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 ten-dances 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 impli-cite 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 ac-tion, 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ération-nelles 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-

Les patrons de flexibilité basés sur les règles ECA

Van Eijndhoven et al. [Van08]

Ce travail propose d'étendre les langages im-pératifs pour ajouter une dimension de flexibi-lité au modèle du processus. Pour cela, les parties les plus variables dans un processus métier sont modélisées en utilisant des pa-trons de flexibilité basés sur les règles ECA.


56

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 ac-tivité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 con-naissance, 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 faci-lement 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 for-malismes 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 ce-la, de nombreux travaux ont été proposés pour modéliser un processus en utilisant le formalisme ECA.


57

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 im-plicite 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éoccupa-tions.

Etat de l’art / Techniques de vérification de processus métier

58

5 Techniques de vérification de processus

métier

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 ques-tion 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 proces-sus. 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éali-sation 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 objec-tif de notre contribution, nous décrirons dans ce chapitre les nombreux tra-vaux sur les techniques de vérification des 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

5.3.1 Vérification par guides de style de modélisation

5.3.2 Vérification par simulation

5.3.3 Vérification par modèles formels

5.3.4 Vérification par process-mining

5.3.5 Synthèse

5.4 Introduction aux modèles formels et les réseaux de Pétri formels

5.4.1 Définition

5.4.2 Utilisation

5.4.3 Classification

5.4.4 Les réseaux de Pétri

5.5 La vérification des processus métier

5.5.1 La vérification dans le cas des langages impératifs

5.5.2 La vérification dans le cas des langages déclaratifs

5.5 Conclusion


59

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 sur-gissent pendant l’exécution d’un programme, est appelée une exception [Rus06 c]. Dans la littérature, plusieurs travaux sont été conduits pour étu-dier 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 er-reurs survenues dans un processus métier peuvent être classifiées comme suit :

5.2.1 Les erreurs fonctionnelles

Les erreurs fonctionnelles concernent la cohérence fonctionnelle du proces-sus 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 (dea-dlock) 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.

5.2.2 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 excep-tions 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.

5.2.3 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


60

exemple de ces erreurs est de définir une activité non atteignable (dead ac-tivity), 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 :

5.3.1 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 con-duire à 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.

5.3.2 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 ain-si des estimations quantitatives sur l'impact qu'une conception de processus est susceptible d'avoir sur l'exécution de processus [Jan06]. Plusieurs simu-lateurs de processus métier ont été proposés, ces outils permettent aux en-treprises et aux organisations d'analyser rapidement leurs processus métier.


61

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.

5.3.3 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 mo-dè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 comporte-ment 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 principale-ment sur les théories de la concurrence et les techniques des algèbres uni-verselles. 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 exten-sible qui n’est pas liée à un outil de vérification ou à un langage de des-cription 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.

5.3.4 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 ba-sant sur les journaux des événements. Le processus exécutable est analysé,


62

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.

5.3.5 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 traduc-tion de la définition des processus métier en modèles formels et la com-plexité 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 dysfonction-nement 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 concep-teurs ne sont pas à l’abri de commettre des erreurs de spécification. Pour cela, les concepteurs ont souvent recours aux modèles formels. Ces mo-dèles exigent de formaliser de processus en utilisant un modèle donné (par exemple réseau de Pétri, algèbre de processus …etc.).

5.4.1 Définition

Un modèle est dit « formel » s’il est fondé sur une syntaxe et une séman-tique précises, construit sur des bases théoriques. Des raisonnements syn-taxique et sémantique sont alors possibles pour démontrer des propriétés d'une spécification.


63

5.4.2 Utilisation

L’objectif de l’utilisation des modèles formels pour la modélisation de pro-cessus est double : fournir, d’une part, une description formelle d’un pro-cessus vis-à-vis de ses exigences en éliminant les contradictions et les am-biguïtés (spécification formelle). D’autre part, l’objectif est aussi de minimiser les risques qu’un dysfonctionnement puisse se produire en se ba-sant sur les propriétés de vérification offertes par ses modèles (vérification formelle).

5.4.3 Classification

Dans la littérature, de nombreux modèles formels sont proposés. Selon At-tiogbé, 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 for-melles, comme l’illustre la figure 5.1. 5.4.3.1 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 ap-proche 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].


64

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 sys-tè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 semi-automatique de théorèmes [Tru06]. Parmi les langages de spécification lo-giques connus nous pouvons citer : PVS [Owr93], Isabelle/HOL [Smi02] ou Coq [Ber04]. 5.4.3.2 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 sys-tè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 ap-proches ensemblistes différent des approches algébriques par le fait que les approches ensemblistes utilisent des types abstraits prédéfinis pour modéli-

Figure 5.1 La classification des différents modèles formels


65

ser l’état du système à construire, chaque opération est spécifiée indépen-damment 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 utili-sant les automates, les réseaux de Pétri et les algèbres de processus (comme CSP [Att07]). 5.4.3.3 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 al-gé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éri-sé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 utili-sé, 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.

5.4.4 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 ma-niè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


66

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 si-gnifie 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 re-quises (ou les ressources nécessaires) pour déclencher l'action (ou l’événement), représenté par cette transition, sont satisfaites (ou dispo-nibles).

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 ;

Figure 5.2 Le processus de traitement de commande modélisé en RdP


67

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 ca-pacité à 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 permet-tent 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.

5.4.4.1 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". 5.4.4.2 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'attei-gnabilité est une propriété de sûreté. 5.4.4.3 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 re-tourner à 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 situa-tion 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"


68

5.4.4.4 Propriété d'absence de blocage (No deadlock)

L'absence de deadlock est une propriété particulière qui exprime que le sys-tème ne se trouvera jamais dans une situation où il ne peut plus progresser. 5.4.4.5 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 an-né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 sup-posé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 en-core 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 traduc-teurs), 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-


69

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.

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 Lan-guage) [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 inter-face 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éri-fication basé sur les réseaux de pétri. Il est employé pour vérifier l'exacti-tude des procédures de Workflow. Il a été intégré à plusieurs systèmes de

Figure 5.3 Les principales démarches de vérification d’un processus métier par les RdP


70

gestion de Workflow. PIPE (Platform Independent Petri-net Editor) [Blo03] est un outil open source qui dispose d’une interface graphique pour élabo-rer 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 fa-cile à 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 graphique-ment les RdP, et permet de lire et sauvegarder les RdP sous plusieurs for-mats. 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ésen-tent un conflit de consommation de messages (conflicting message-consuming activities). Pour cela cet outil s’intéresse qu’à vérifier la pro-priété d’accessibilité d’un RdP.

5.5 La vérification des processus métier

5.5.1 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 da-vantage sur le niveau descriptif du métier, notamment des aspects fonction-nels 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 peu-vent conduire à des défaillances des systèmes et peuvent avoir des consé-quences dramatiques sur le plan économique. Dans le but d'aider le concep-teur à trouver les erreurs dans les spécifications lors de la conception, nous souhaitons développer un environnement pour la spécification, la vérifica-tion 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 expri-mer des systèmes transformationnels, les logiques temporelles pour expri-mer des propriétés dynamiques de sûreté et de vivacité des systèmes réac-tifs, 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


71

les graphes comme les réseaux de Pétri qui modélisent les systèmes concur-rents, 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 proces-sus 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éo-ries de la concurrence et les techniques des algèbres universelles. Les al-gè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 Specifi-cation) 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 im-plé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, ap-pelé CADP (CÆSAR/ALDÉBARAN Development Package), permet aussi la vérification du processus BPEL. Par contre le [Smi02] propose une plate-forme 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 plate-forme 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


72

l'outil de vérification. Notons que le papier [Van06] recense les différents travaux proposés pour la vérification des processus BPEL.

6.5.1 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éri-fier 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 contra-diction, les boucle infinies, la redondance, la subsumption et l’incomplétude. Dans ce travail, des algorithmes de correction sont égale-ment élaborés pour essayer de corriger les erreurs détectées dans une re-pré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’auto-vé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 lo-giques adéquates pour la représentation des règles. Une méthodologie de vali-dation de règles basée sur le test-driven est développée pour permettre la vali-dation 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 tran-sition est tirée si les conditions sont satisfaites. A leur tour, Li et al. propo-sent dans [Li04] un nouveau réseau de Pétri coloré, appelé Conditional Co-lored 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


73

de nouveaux types de places et de nouveaux types de transitions pour per-mettre la spécification des événements complexes.

Malgré les méthodes proposées pour analyser un modèle déclara-tif, le processus de vérification est complexe, car il exige d’avoir un scéna-rio d’exécution, dans la phase de modélisation, pour tester le bon fonction-nement 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 conformi-té à 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 re-pré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éli-sé par les règles ECA est plus complexe, car elle doit être obtenue en cons-truisant 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 pro-cessus.

Puisque, le formalisme ECA nous semble intéressant, nous allons, dans la deuxième partie de cette thèse, proposer une extension de ce for-malisme pour modéliser un processus métier. Ce formalisme permet d’offrir une flexibilité à la modalisation et une fiabilité à l’exécution du processus.

Partie 2

Notre contribution

Contribution / Introduction

75

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).


76

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.


77

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.

Figure 6.0 le positionnement de notre contribution par rapport aux travaux existants

Contribution / Modèle ECAPE-M

78

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

6.5.1 La séquence d’activité

6.5.2 La branche parallèle

6.5.3 La synchronisation

6.5.4 Le choix exclusif

6.5.5 La jonction simple

6.5.6 La boucle structurée

6.6 Différents plans du modèle ECAPE-M

6.6.1 Le plan métier

6.6.2 Le plan comportemental

6.6.3 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élisa-tion 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 forma-lisme 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 condi-tions de déclenchement des règles. Ce qui offre une flexibilité de la modéli-sation du processus.

Cependant, la vérification du processus exige d’avoir un scénario d’exécution pour tester son bon fonctionnement. Malheureusement, le for-malise 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-


79

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, initiale-ment 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éne-ments [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 con-dition 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écu-té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


80

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 : lors-qu’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 attri-buts 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 en-visagées : (1) un mécanisme de compensation est lancé dans le but de rem-placer, 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 es-plicite 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 fonc-tionnelle 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 con-trô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 plu-sieurs 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).


81


Pour illustrer le modèle ECAPE, nous allons détailler comment nous pou-vons 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. Finale-ment lorsque le paiement est reçu, le produit est livré et la facture est enre-gistré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 com-mande ; la deuxième règle concerne le règlement de la facture qui doit se faire avant 15 jours de la date de livraison.

Figure 6.1 La modélisation d’un processus en utilisant le modèle ECAPE-M


82

La figure 6.2 représente le processus du traitement de commande sous forme de règles ECAPE. Par exemple, la règle r1 exprime la vérifica-tion de l’enregistrement : lors de la réception d’une commande (l’événement d’activation), si les informations de la commande sont valides

Figure 6.2 La modélisation ECAPE-M du processus de traitement de commande


83

(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 r2 (calcul du prix initial), r3 (sélection du li-vreur), et r4 (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 con-dition, 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 r3 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 r1 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éne-ments 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 pos-sible de déduire la séquence de déclenchement de règles. En plus cela per-met 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 per-met de modéliser, d’une manière déclarative, un processus métier en décri-vant 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) :


84

6.5.1 La séquence de règles

Pour modéliser une séquence de règles par le modèle ECAPE-M nous de-vons 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 e2 de la règle r1 permet d’activer la règle r2. 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 e2 de la règle r1 permet d’activer la règle r2.

6.5.2 Le parallélisme de règles

Figure 6.3 la modélisation de séquence de règles par le modèle ECAPE-M

(b)

Figure 6.4 la modélisation du parallélisme de règles par le modèle ECAPE-M

(b)

(a) (b)

(a)


85

Pour modéliser un parallélisme de règles par le modèle ECAPE-M nous de-vons 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 e2 de la règle r1 permet d’activer les règles r2 et r3 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.

6.5.3 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 r2 se dé-clenche par une conjonction de post-événements e2 et e3 des règles r1 et r1’ 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 r2 se déclenche par une conjonction d’événements d’erreur e2 et e3 des règles r1 et r1’ res-pectivement.

Figure 6.5 la modélisation de la synchronisation de règles par le modèle ECAPE-M

(a)

(b)


86

6.5.4 Le choix exclusif de règles

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 e1 permet d’activer deux règles r1 et r1’ qui ont deux conditions contradictoires (c1 et ˥ c1 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 r2 ou r2’.

6.5.5 La jonction simple de règles

Figure 6.6 la modélisation du choix exclusif de règles par le modèle ECAPE-M

(b) (a)

(a) (b)

Figure 6.7 la modélisation la jonction simple de règles par le modèle ECAPE-M


87

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 r2 s’active si au moins un des deux post événements (ou événements d’erreur) e2 ou e3 est détecté.

6.5.6 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 {r1 , r2 , r3} forme une boucle. Pour sortir de cette boucle, la condition c1 de la règle r1 doit être non satisfaite. Ce qui conduit au déclenchement de r4 .

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.

Figure 6.8 la modélisation de la boucle structurée de règles par le modèle ECAPE-M


88

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):

6.6.1 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ésen-ter 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).

6.6.2 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 as-surer 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 chan-gé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 va-riables (voir chapitre 8).

Figure 6.9 Les différents plans du modèle ECAPE-M


89

6.6.3 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 en-semble de règles ECAPE. Ce modèle étend le formalisme ECA, initiale-ment 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éne-ments 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 nou-veau langage appelé ECAPE-L un plan de comportement pour gérer auto-matiquement le changement du processus et un plan opérationnel pour si-muler 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 nou-veau 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.

Contribution / Le langage ECAPE-L

90

7 Le langage ECAPE-L

7.1 Introduction

7.2 Les éléments du langage ECAPE-L

7.2.1 Le processus

7.2.2 Les participants

7.2.3 Les variables

7.2.4 Les activités métier

7.2.5 Les événements

7.2.6 Les règles ECAPE

7.2.6.1 L’instruction EXECUTE

7.2.6.2 L’instruction DISCOVER

7.2.6.3 L’instruction CANCEL

7.2.6.4 L’instruction SKIP

7.2.6.5 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


91

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.


92

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.

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éta-modè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 2.

7.2.1 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

Figure 7.1 Le méta-modèle du langage ECAPE-L


93

constituent les règles ECAPE, et d’utiliser ces déclarations pour définir l’ensemble de règles (voir la figure 7.2).

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 :

Figure 7.2 Un processus métier décrit par le ECAPE-L


94

<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>

7.2.2 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>

Les éléments et les attributs de la balise «Process »

Signification

Participants Les participants utilisés pour exécuter les activités Variables Les variables manipulées dans le processus BusinessActivities Les activités métier utilisées dans les actions de la règle Events Les événements utilisés pour déclencher les règles BusinessRules L’ensemble de règles EACAPE Name Le mon du processus Namespace Un nom symbolique qui permet de désigner l’ensemble des

variables et des fonctions dans la définition du processus expressionLanguage Le langage utilisé pour spécifier les expressions du

processus (par défaut le xpath1.0 est utilisé)


95

</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>

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>

Les éléments et les attributs de la balise «Participant »

Signification

ParticipantType Le type du participant

Description Les descriptions du concepteur qui décrivent le rôle du participant

Id L’identifiant du participant dans le processus Name Le nom du participant


96

7.2.3 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>

Les éléments et les attributs de la balise «ParticipantType »

Signification

Human Une personne physique

OrganiszationalUnit Un groupe de personnes, un département ou une organisation

SpecificApplication

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.

DiscoveredApplication Une application (ou un service web) qui doit être découverte automatiquement dans un registre donné (voir la partie 7.2.6.2)


97

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 «Variable »

Signification

DataType Le type de variable InitialValue La valeur initiale de la variable

Description Les descriptions du concepteur qui décrivent l’utilisation de la variable

Id L’identifiant de la variable dans le processus Name Le mon de la variable

Les éléments et les attributs de la balise «DataType »

Signification

BasicType Un type simple : STRING, FLOAT, INTEGER, DATETIME, DATE, TIME ou BOOLEAN

DeclaredType Un nouveau type déclaré SchemaType Un document XML ExternalReference Une référence vers une variable externe

RecordType Un ensemble de d’éléments qui peuvent être de différents types

UnionType Un ensemble de membres parmi lesquels un seul sera utilisé dans une instance du processus

EnumerationType L’ensemble de valeurs autorisées pour une variable ArrayType Un ensemble de données de même type ListType Un ensemble infini d’éléments de même type


98

7.2.4 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"/>


99

<xsd:attribute name="Name" type="xsd:NCName" use="optional"/> <xsd:attribute name="Priority" type="xsd:anySimpleType"/> </xsd:complexType>

7.2.5 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>

7.2.5.1 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)

Les éléments et les attributs de la balise «BusinessActivity»

Signification

FormalParameters Les paramètres d’entrée/sortie de l’activité

ExecutionType Le type d’exécution : manuelle, semi-automatique ou automatique.

ExecutionMode Le mode d’exécution : synchrone ou asynchrone

Description Les descriptions de l’utilisation de l’activité par le concepteur

Id L’identifiant de l’activité dans le processus Name Le nom de l’activité


100

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>


101

7.2.5.2 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.

Les éléments et les attributs de la balise « AtomicEvent »

Signification

EventType

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

Description Les descriptions du rôle des d’événements par le concepteur

Id L’identifiant d’événement dans le processus Name Le nom d’événement

EventGroup

Le groupe d’événement qui peut être :

StartGroup Un événement de début qui déclenche l’exécution du processus

IntermediateGroup Un événement intermédiaire qui se déclenche en cours de l’exécution du processus

EndGroup Un événement de fin qui cause la terminaison du processus


102

- 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>

7.2.6 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

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 7.3.5.1)

expressionLanguage Le langage utilisé pour spécifier l’expression de l’événement composé (par défaut le xpath1.0 est utilisé)


103

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>


104

Les éléments et les attributs de la balise «BusinessRule»

Signification

OnEvent

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"/>

PreCondition

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"/>

Action

L’ensemble des activités à exécuter si la précondition est vraie. Le schéma XML de Action est le suivant: <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)

CompensateAction

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: <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"/>

PostEvents

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 : <xsd:element name="PostEvents" type="tPostEvents"/> <xsd:complexType name="tPostEvents"> <xsd:sequence> <xsd:element name="PostEvent" type = "tEventExpression"/> </xsd:sequence> </xsd:complexType>

ErrorEvents

L’ensemble des événements d’erreurs qui peut être déclenchés si la post-condition 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>

Name Le nom de la règle Version La version de la règle Priority La priorité accordée à la règle


105

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 :

7.2.6.1 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 »

Signification

Operation Le nom de l’activité à exécuter InputVariableName Les variables d’entrée OutputVariableName Les variables de sortie InputOutputVariableName Les variables d’entrée/sortie en même temps Performer Le nom du participant responsable de l’exécution de l’activité Description Les descriptions du concepteur qui décrivent cette exécution


106

7.2.6.2 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>


107

7.2.6.3 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>

Les éléments et les attributs de la balise « Discover »

Signification

Operation Le nom de l’activité à exécuter par cette découverte

Performer Le nom du participant à découvrir

BusinessRegistryLocation L’adresse du registre de recherche

QoS

Les qualités de service de recherche souhaitées. Le schéma XML du QoS est comme suit : <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 L’adresse de la ressource trouvée Description Les descriptions du concepteur qui décrivent cette découverte


108

7.2.6.4 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>

7.2.6.5 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"/>

Les éléments et les attributs de la balise « CANCEL »

Signification

ActivityName Le nom de l’activité à annuler Description Les descriptions du concepteur qui décrivent cette annulation

CancelAll L’option d’annuler toutes les activités du processus (cette option par défaut est à « faux »)

Les éléments et les attributs de la balise « SKIP »

Signification

ActivityName Le nom de l’activité à sauter Description Les descriptions du concepteur qui décrivent ce saut


109

<xsd:element ref="To"/> </xsd:sequence> </xsd:complexType>


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

Les éléments et les attributs de la balise «COPY»

Signification

From La variable source To La variable destination


110

<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 R1, 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 R1 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 R1 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 R3 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>.


111

(F)

(A) (B) (C)

(D) (E)

Figure 7.3 Un sous processus RbBPDL du traitement de commande


112

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 + Ce patron est supporté en définissant un post-événement qui active une règle

La branche parallèle + Ce patron est supporté en définissant un post-événement qui d’active plusieurs règles simultanément

La synchronisation + 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

Le choix exclusif + Ce patron est supporté en définissant un post-événement qui active deux règles qui ont deux conditions contradictoires

La jonction simple + 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

La boucle structurée +

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)

Le cycle arbitraire +

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

Annulation d’activité + Ce patron est supporté par l’instruction CANCEL avec l’option d’annuler toutes les activités du processus égale à faux


113

Patrons de ressources

(ressources pattern [ WPI09])


Explication

Allocation direct + Ce patron est supporté en associant un participant à une activité métier

Allocation aléatoire +

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 rôle + Ce patron est supporté en définissant le rôle de

chaque participant Délégation - La délégation de rôle n’est pas supportée

Annulation multiple + Ce patron est supporté par l’instruction CANCEL avec l’option d’annuler toutes les activités du processus égale à vrai

Terminaison implicite + Le processus se termine quand il n’y a plus de règles à déclencher

Terminaison explicite + 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 données

(data patterns [WPI09])


Explication

Variable globale d’un processus + Ce parton est supporté car toutes les variables du

processus sont des variables globales Variable locale d’une activité - Ce parton n’est pas supporté car toutes les variables

du processus sont globales

Passage de données activité vers activité +

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)

Passage de données activité vers extérieur +

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)

Passage de paramètre par copie -

Ce parton n’est pas supporté car le mécanisme de passage en utilisant les copies de données n’est pas supporté

Passage de paramètre par référence + Ce parton est supporté en utilisant une variable de

type référence vers une variable externe Pré-condition sur les données d’une activité + Ce parton est supporté en utilisant la condition de la

règle Post-condition sur les données d’une activité + Ce parton est supporté en utilisant la post-condition

de la règle


114

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.

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

Figure 7.4 les symboles utilisés dans URML for BP


115

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.

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

Figure 7.5 Un diagramme UMRL for BP d’un sous processus du traitement de commande


116

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 :

BPMN [OMG09]

BPEL [OASIS07]

XPDL [WfMC08]

ECAPE-L/ URML for BP

Langages de définition de haut niveau de processus métier

X X

Langages d’exécution de processus métier

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 r3 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 r4 qui doit être


117

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.

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

118

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

8.3.1 Les relations de déclenchement

8.3.2 Les relations de partage de variables

8.3.3 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


119

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


120

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 :

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.

Figure 8.1 Le démarche de gestion du changement d’un processus ECAPE


121

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 - eri : l’événement qui déclenche la règle Ri tel que eri ⊆ E - PsEri : l’ensemble des événements qui se déclenche pendant ou après l’exécution de la partie action de la règle Ri tel que PsEri ⊆ E - ErEri : l’ensemble des événements d’erreur qui peut se déclencher si la post condition de la règle Ri n’est pas satisfaite tel que ErEri ⊆ E - PsEri

+ : l’ensemble des post événements tel que PsEri+ = PsEri ∪ ErEri

- Ari : l’ensemble des activités métier utilisées par la règle Ri tel que Ari ⊆ A - ACri : l’ensemble des activités de compensation utilisées par la règle Ri si la post condition de la règle Ri n’est pas satisfaite tel que Ari ⊆ A

- Vri : l’ensemble des variables utilisées par la règle Ri tel que Vri ⊆ V est constitué des ensembles suivants

• Vcri : l’ensemble des variables utilisées par les prédicats Cri (Vcri) de la partie condition de la règle Ri tel que Vcri ⊆ V

• Vpcri : l’ensemble des variables utilisées par les prédicats PsCri (Vpcri) de la partie post condition de la règle Ri tel que Vpcri ⊆ Vri


122

• inputariV : l’ensemble des variables d’entrés utilisées par les activités de l’action Ari ( input

ariV ) de la règle Ri tel que inputariV ⊆ Vri

• outputariV : l’ensemble des variables de sorties utilisées par les activités de l’action output

ariV Ari () de la règle Ri tel que outputariV ⊆ Vri

• inputacriV : l’ensemble des variables d’entrés utilisées par les activités de l’action Ari ( input

acriV ) de la règle Ri tel que inputacriV ⊆ Vri

• outputacriV : l’ensemble des variables de sorties utilisées par les activités de l’action de compensation output

acriV Ari () de la règle Ri

tel que outputacriV ⊆ Vri

Finalement, les constructeurs d’événements composés sont utilisés comme suit : (1) e1˄ e2 : permet de spécifier que les deux événements e1 et e2 ont lieu sans

tenir compte de leur ordre d’arrivée. (2) e1˅ e2 : permet de spécifier qu’au moins l’un des deux événements est

déclenché. (3) Seq (e1, e2) : permet de spécifier une séquence de deux événements. (4) Sim (e1 , e2) permet de spécifier que les deux événements se déclenchent

simultanément. (5) any(m, e1, e2, …, en) permet de spécifier que m événements parmi e1, e2, …,

en se déclenchent

8.4.1 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:

8.4.1.1 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


123

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é → )(CES ). 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 : ∃ pseri ∈ PsEri

+ : pseri = rje

tel que erj est l’événement qui déclenche la règle r j Si rje est l’événement de terminaison de l’actionria , alors la relation →S est une relation de cause à effet en série → )(CES .

Dans notre exemple du processus de traitement de commande vu dans le chapitre 6, la règle r5 (calcul du prix total) est en relation de déclenchement en série avec la règle r6 (facturation) car la règle le post événement de r5 (le prix total est calculé) est le même événement de déclenchement de la règle r6 (voir la figure 8.2). Le déclenchement de série de r5 →S r6 est une relation de cause à effet, r5 → )(CES r6 car la règle r6 ne se déclenche que si l’action de la règle r5 est terminée.

Figure 8.3 Exemple de deux règles en relation de déclenchement en série


124

8.4.1.2 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).

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 r1 … rj 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 que l’on le nomme relation de cause à effet multiple (noté → )(CEM ). 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 :

Dans n

Définition 2 : La règle r i est en relation de déclenchement multiple avec un ensemble de règle r1, …, r j (r i →M r1, …, r j , ) si et seulement si :

1) rjr ee ∧∧ ...1 ∈ PsEri+

2) rjr ee ∨∨ ...1 ∈ PsEri+

3) ),...,( 1 rjr eeseq ∈ PsEri+

4) ),...,( 1 rjr eesim ∈ PsEri+

5) ),...,,( 1 rjr eemany ∈ PsEri+

6) ∃ pseri ∈ PsEri+

: pseri = rjr ee == ...1 tel que er1 … erj sont les événements qui déclenchent les règle r1, …, rj respectivement. Si { }rjr eee ,...1∈∃ : e est l’événement de terminaison de l’actionria , alors la relation →M est une relation de cause à effet multiple → )(CEM .

Figure 8.3 La relation de déclenchement multiple


125

Dans notre exemple du processus de traitement de commande, la règle r1 (réception de commande) est en relation de déclenchement en parallèle avec les règles r2 (Calcul prix initial) et r3 (Calcul prix livraison) car le post événement de r1 (client est vérifié) est l’événement qui déclenche les règles r2 et r3 (voir la figure 8.4). Le déclenchement multiple de r1 →M r2, r3 est une relation de cause à effet multiple (r1 → )(CEM r2, r3) car les règles r2 et r3 ne se déclenchent que si l’action de la règle r1 est terminée.

8.4.1.3 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).

Figure 8.4 Exemple de règles en relation de déclenchement multiple


126

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 r1 … r i , comme un cas particulier de la relation de déclenchement synchronisé qu’on le nomme relation de cause à effet synchronisé (noté → )(CESny ). 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 r1, …, r i sont en relation de déclenchement synchronisé avec la règle r j (r1, …, r i →Syn r j) si et seulement si : 1) ∃ pser1 ∈ PsEr1

+ ∧ …∧ ∃ pseri ∈ PsEri+ : erj = rir psepse ∧∧ ...1

2) ∃ pser1 ∈ PsEr1+ ∧ …∧ ∃ pseri ∈ PsEri

+ : erj = rir psepse ∨∨ ...1 3) ∃ pser1 ∈ PsEr1

+ ∧ …∧ ∃ pseri ∈ PsEri+ : erj = ),...,( 1 rir psepseseq

4) ∃ pser1 ∈ PsEr1+ ∧ …∧ ∃ pseri ∈ PsEri

+ : erj = ),...,( 1 rir psepsesim 5) ∃ pser1 ∈ PsEr1

+ ∧ …∧ ∃ pseri ∈ PsEri+ : erj = ),...,,( 1 rir psepsemany

tel que erj est l’événement qui déclenche la règle r j. Si { }rir psepsepse ,...1∈∃ : pse est l’événement de terminaison de l’action ria , alors la relation →Syn est une relation de cause à effet synchronisé → )(CESyn .

Dans notre exemple du processus de traitement de commande, les règles r2 (Calcul prix initial) et r3 (Calcul prix livraison) sont en relation de déclenchement de jointure avec la règle r5 (calcul du prix total) car l’événement de déclenchement de la règle r5 est la conjonction post événement

Figure 8.5 La relation de déclenchement de jointure


127

de la règle r2 (prix initial calculé) et du post événement de la règle r3 (prix livraison calculé) (voir la figure 8.6). Le déclenchement synchronisé de r2, r3

→Syn r5 est une relation de cause à effet synchronisé (r2, r3 → )(CESyn r5) car la règle r5 se déclenche après la terminaison de l’exécution des actions des règle r2 et r3

8.4.2 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 :

8.4.2.1 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,

Figure 8.6 Exemple de règles en relation de déclenchement de jointure


128

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 : ∃ v ∈

outputariV : v ∈ crjV

Dans notre exemple du processus de traitement de commande, les règles r1 (réception de commande) et r2 (Calcul prix initial) sont en relation de partage de variables Action- Condition car la variable de sortie de l’action de la règle r1 (la variable booléenne « client est enregistré ») est utilisée par la condition le prédicat de la condition de la règle r2 (la variable booléenne « client est enregistré » est vrai) (voir la figure 8.7).

8.4.2.2 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 – Condition avec la règle r j (r i r j) si et seulement si : ∃ v ∈

outputacriV : v

∈ crjV

Figure 8.7 Exemple de règles en relation de partage de variables Condition-Action


129

8.4.2.3 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 -Action avec la règle r j (r i r j) si et seulement si : ∃ v ∈

outputariV : v ∈

inputarjV

Dans notre exemple du processus de traitement de commande, les règles r2 (Calcul prix initial) et r5 (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 r2 et elle est utilisée comme variable d’entrée de l’action de la règle r5 (voir la figure 8.8)

8.4.2.4 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

Figure 8.8 Exemple de règles en relation de partage de variables Action-Action


130

-Action avec la règle r j (r i r j) si et seulement si : ∃ v ∈

outputacriV : v ∈

inputarjV

8.4.2.5 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 : ∃ v ∈

outputariV : v ∈

inputacrjV

8.4.2.6 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 ∈

outputacriV : v ∈

inputacrjV

8.4.2.7 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 : ∃ v ∈

outputariV : v ∈ pcrjV


131

Dans notre exemple du processus de traitement de commande, les règles r3 (Calcul prix livraison) et r7 (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 r7 et elle est utilisée aussi par le prédicat de la post condition de la règle r7 (livraison confirmée) (voir la figure 8.9).

8.4.2.8 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 : ∃ v ∈

outputacriV : v ∈ pcrjV

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

Figure 8.9 Exemple de règles en relation de partage de variables Action-Post condition


132

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é GR = (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) YS est un sous ensemble de Y tel que si yS (ri, rj), alors ri et rj sont en relation de déclenchement en série. (2) YM est un sous ensemble de Y tel que si yM (ri, rj), alors ri déclenche un ensemble de règles dont rj fait partie (déclenchement multiple). (3) YSyn est un sous ensemble de Y tel que si ySyn (ri, rj), alors rj est synchronisée par un ensemble de règles dont ri fait partie (déclenchement synchronisé). (4) YA-C est un sous ensemble de Y tel que si yA-C (ri, rj), alors ri et rj sont en relation de partage de variables Action - Condition. (5) YCA-C est un sous ensemble de Y tel que si y CA-C (ri, rj), alors ri et rj sont en relation de partage de variables Compensation - Condition. (6) YA-A est un sous ensemble de Y tel que si yA-A (ri, rj), alors ri et rj sont en relation de partage de variables Action - Action. (7) YCA-A est un sous ensembles de Y tel que si y CA-A (ri, rj), alors ri et rj sont en relation de partage de variables Compensation - Action. (8) YA-CA est un sous ensembles de Y tel que si yA-CA (ri, rj), alors ri et rj sont en relation de partage de variables Action - Compensation. (9) Y CA- CA est un sous ensemble de Y tel que si yCA- CA (ri, rj), alors ri et rj sont en relation de partage de variables Compensation - Compensation. (10) YA-PC est un sous ensemble de Y tel que si yA-PC (ri, rj), alors ri et rj sont en relation de partage de variables Action – Post condition. (11) YCA-PC est un sous ensemble de Y tel que si yCA-PC (ri, rj), alors ri et rj sont en relation de partage de variables Compensation – Post condition.


133

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 r10 (règle de vérification du client fidèle) et la modification de l’événement de déclenchement de la règle r6 (règle de facturation). Dans ce cas de figure, nous cherchons à déterminer l’impact de l’ajout d’une règle (r10) et l’impact de la

Figure 8.10 Le graphe de règle du processus de traitement de commande


134

modification de l’événement de déclenchement de la règle de facturation (r6) 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


135

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 GR = (R, Y) et soit ri une règle telle que r i ∈ R - on note )( i

krelation rN l’ensemble des successeurs de k sauts où k est le

diamètre du Gr à partir du sommet r i tel que )( ikrelationj rNr ∈∀ , (r i, rj) ∈

Yrelation 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),

{ }98765 ,,,)( rrrrrNkS = .

- on note )( irelation rN+ l’ensemble des successeurs direct du sommet r i tel que )( irelationj rNr +∈∀ , (r i, rj) ∈ Yrelation 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), { }965 ,)( rrrNS =+ car la règle r5 est en relation de déclenchement en série avec r6 et r9.

- on note )( irelation rN− est l’ensemble des prédécesseurs direct du sommet ri tel que )( irelationj rNr −∈∀ , (r j , r i) ∈ Yrelation 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), { }8549 ,,)( rrrrNS =− car les règles r4, r5, et r6 sont respectivement en relation de déclenchement en série avec la règle r9.

8.6.1 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


136

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 ),( YRGR . 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 r10, 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 r5.

8.6.2 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.


137

8.6.2.1 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 ),( '' YRGR déduit après la modification de l’événement rie de la règle ir ∈ R dans le graphe de règle ),( YRGR ,pour toutes règle r j ∈ R si ))()()(( )()()( iCESyniCEMiCESj rNrNrNr −−− ∪∪∈ ,

))(')(')('( )()()( ik

CESynik

CEMik

CESj rNrNrNr ∪∪∉∧ , alors réviser l’événement modifié 'rie de r j.

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 r10

(ajoutée précédemment) pour devenir « le client est vérifié », alors, la règle r10 sera déclenchée avant la règle r5. Or l’action de r10 a besoin du prix total


138

pour le prix de la commande de 10 % si le client est fidèle. Pour cela, la règle r5 sera affectée par la modélisation de r10 car { }510)( )(( rrN CES =−

. Donc le concepteur doit réviser l’événement de la règle r10 pour prendre en compte le déclenchement de r5. Le nouvel événement de r10 doit être « le prix total est calculé et le client est vérifié ».

8.6.2.2 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 ),( YRGR , si une condition cri 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 (r3) 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 r3.

8.6.2.3 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


139

é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 ),( YRGR , si l’action ari de la règle r i est modifiée alors : - )( iCAj rNr +

−∈∀ , la condition de la règle r j doit être révisée - )( iAAj rNr +

−∈∀ , l’action de la règle r j doit être révisée - )( iCAAj rNr +

−∈∀ , la compensation de la règle r j doit être révisée - )( iPCAj rNr +

−∈∀ , 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 r1 (règle de vérification de client), cela va impacter les règles r2, r3 et r4 car ces dernières partagent la même variable avec cette action ))(,( 14,32 rNrrr CA

+−∈ . 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 r6. Cette modification va affecter la règle r7 puisque )( 67 rNr AA

+−∈ . Pour cela, la révision de la règle r7 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 r6 doivent être révisés car (1) la post condition de la règle r6 doit contrôler l’action modifiée, (2) la compensation de la règle r6 doit correspondre à une action équivalente à l’action modifiée et (3) les post événements de la règle r6 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 r6 suite a la modification de son action traitée comme un nouveau changement (voir modification de post événement d’une règle)


140

8.6.2.4 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 ),( YRGR , si compensation cari de la règle r i est modifiée alors : - )( iCCAj rNr +

−∈∀ , la condition de la règle r j doit être révisée - )( iACAj rNr +

−∈∀ , l’action de la règle r j doit être révisée - )( iCACAj rNr +

−∈∀ , la compensation de la règle r j doit être révisée - )( iPCCAj rNr +

−∈∀ , 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

8.6.2.5 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 ),( YRGR ,si une post condition pcri 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


141

Dans l’exemple du processus de traitement de commande, si l’entreprise décide de modifier la post condition de la règle r3 (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 r3 pour signaler ce problème.

8.6.3.6 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 ),( YRGR ,si une post événements peri ou un événement d’erreur de la règle r i est modifié alors :

)()()( iSyniMiSj rNrNrNr +++ ∪∪∈∀ , l’événement de la règle r j doit être révisé

Dans l’exemple du processus de traitement de commande, suite a la modification de l’action de la règle r6 (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 r7 et r8 sont impactées car elles sont en relation de déclenchement avec la règle r6

{ } ))(,( 687 rNrr S+⊂ . Pour cela le concepteur doit réviser les événements des ces

deux règles.

8.6.3 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


142

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 ),( YRGR , si la règle r i est supprimée alors : - )()()( iSyniMiSj rNrNrNr +++ ∪∪∈∀ , l’événement de la règle r j doit être révisé - )()( iCCAiCAj rNrNr +

−+

− ∪∈∀ , la condition de la règle r j doit être révisée - )()( iACAiAAj rNrNr +

−+

− ∪∈∀ , l’action de la règle r j doit être révisée -

+−

+− ∪∈∀ CACAiCAAj NrNr )( , la compensation de la règle r j doit être révisée

- )()( iPCCAiPCAj rNrNr +−

+− ∪∈∀ , 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 r3 sera supprimée. Suite à cette suppression l’événement de la règle du calcul du prix total ))(( 35 rNr M

+∈ 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 ))(( 35 rNr CA

+−∈ .

8.6.4 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 :


143


144

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 r3 sera supprimée. Suite à cette suppression l’action de la règle r5 (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 ri . Ce graphe est formellement défini comme suit :


145

Définition 13 : Un graphe d’opérations de changements d’une règle r i Gop = (Op, C) est un graphe orienté où : - L’ensemble de sommets Op représente les 3 opérations de changements possibles :

- Ajouter (ri) : opération d’ajout d’une règle r i à l’ensemble R - Modifier (ri, partie) : opération de modification de la partie pi de la

règle r i tel que { } { } { } +∪∪∪∪∪∈ ririririririi PsEpcACAcep - Supprimer (ri) : 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 (opi, opj), alors opération opi cause éventuellement l’exécution de l’opération opj.

En effet, les sommets de ce nouveau graphe représentent les trois

opérations de changements possibles : - Ajouter (règle ri) : permet d’ajouter une règle r i à l’ensemble de règles

ECAPE qui décrit le processus. - Modifier (règle ri, 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 ri) : 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 8.6.


146

Par exemple, la modification d’une action d’une règle r i (opération

modifier(règle ri, action)) déclenche éventuellement un ensemble d’opérations (voir la figure 8.12 et figure 8.13et section 8.6.2.3), comme l’opération de modification des conditions des règles qui sont en relation de partage de variables Action-Condition ( ) et l’opération de modifications d’action des règles qui sont en relation de partage de variables Action-Action ( ). 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).

),(),( rjjiCAj crModifierrNr +−∈∀

),(),( rjjiAAj arModifierrNr +−∈∀

Figure 8.12 les différents graphes d’opérations d’ajout et de modification d’une règle ri


147

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 ri) et l’opération modifier (règle ri, 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.

Figure 8.13 le graphe d’opérations de suppression de la règle ri


148

Dans l’exemple du processus de traitement de commande, le coût de

la suppression de la règle r3, 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 8.6.3.

En effet, cette suppression (opération supprimer(r3)) oblige le concepteur à réviser (et éventuellement modifier) les événements, les actions et les compensations de la règle r5 car cette dernière et en relation de déclenchement (r3 → )(CES r5) et de partage de variables (r3 r5 et r3 r5) avec la règle r3. L’estimation du coût maximum de la suppression r3 suppose que le concepteur effectue toutes les modifications éventuelles. Pour cette raison, on considère que l’opération supprimer(r3) va déclencher trois autres opérations (modifier (règle r5, événement), modifier (règle r5, action) et modifier (règle r5, 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 r3 (voir la figure 8.14).

Le coût de suppression de la règle r3 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 r3 = (0 ajout, 9 modifications, 1 suppression).

Figure 8.14 le graphe d’opérations de suppression de la règle r3


149

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 :

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.

{ } { } { }

{ } { } { }

( )),

),(

,()(

) ()(

∑

∑

∑∑

∑

∑

∑

∈∀

∈∀

∈∀∪∪∪∪∪∈∀

∪∪∪∪∪∈∀∧∈∀

∈∀

∈∀

+

+

=

Rr

Rr

i

RrPsEpcACAcep

PsEpcACAcepRr

rii

Rr

Rr

i

i

i

jririririririi

ririririririii

i

i

i

rnSuppressio

ji

prModifier

i

)Ajouter(r

processζ


150

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


151

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.

Contribution / La vérification du processus métier par le ECAPE net

153

9 Vérification du processus métier par le

ECAPE-net

9.1 Introduction

9.2 Le ECAPE-net

9.2.1 Les éléments du ECAPE-net

9.2.2 Définition formelle du ECAPE-net

9.2.3 Les règles de franchissement des transitions dans le ECAPE-net

9.2.4 La construction des événements composés

9.2.5 Exemple illustratif

9.3 La vérification d’un processus par le ECAPE-net

9.3.1 Les propriétés du réseau bien structuré

9.3.2 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


154

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.


155

9.2 Le ECAPE-net

9.2.1 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.

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

Figure 9.1 Modélisation d’une règle ECAPE dans un Pétri ECAPE-net


156

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.

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, e1, e2, ..., en) qui permet de spécifier m événement parmi l’ensemble {e1, e2, ..., en} qui se sont produits ;

- Place de début : représente le premier événement qui déclenche l'exécution du processus ;

Figure 9.2 Eléments du réseau de Pétri ECAPE-net


157

- 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 (e1, t) qui permet de caractériser le fait qu’un événement ne s’est pas produit dans un intervalle de temps t.

9.2.2 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 = Pprim ∪ Pcomp ∪ Pinter tel que Pprim , Pcomp et Pinter représentent respectivement les ensemble des places primitives, composées et intermédiaires. A leur tour, Pstar et Pend représentent respectivement les ensembles des places de début et les place de fin tel que Pstar ⊂ Pprim et Pend ⊂ Pprim . - T est un ensemble fini de transitions qui est composé de deux sous ensembles : T = Tcomp ∪ Taction ∪ Tcompensation tel que Tcomp, Taction et Tcompensation 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 Taction ∪ Tcompensation est composé de cinq sous ensembles Taction = TExecute∪ TDiscover ∪ TSkip ∪ TCancel ∪ TCopy tel que TExecute, TDiscover, TSkip, TCancel et TCopy 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


158

composé de deux sous ensembles : A = Anorm ∪ Ainhi tel que Anorm et Ainhi

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 : Σ∈∃∈∀ )(:)(, pCpCPp - W est la fonction qui détermine pour chaque arc les jetons qu’il consomme ou qu’il produit tel que : ))(())((var(, apCaWTypeAa =∈∀ où la fonction Σ∈))((var( aWType 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 (Taction ou Tcompensation) un nom. - Cond est une fonction condition qui définie l’ensemble de transitions dans (ou vers) une expression booléenne tel que: booleantCondtypeTt =∈∀ ))((, 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:

booleantCondtypeTt action =∈∀ ))((, - D est une fonction d'intervalle de temps qui est définie de Tcomp dans un intervalle de temps [d1, d2]. - τ 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


159

certain nombre de jetons. On note M0 le marquage initial (état initial) dans un ECAPE-net. On note Mf, 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 Mn à l’état n est dit accessible à partir de M1 (dénoté nMM →*

1 ) si et seulement s’il existe une séquence de franchissement 121 ... −= ntttσ tel que nMM →σ

1

2. Nous définissons les cinq ensembles suivants : - t• est l’ensemble de places d’entrées de la transition t tel que { }AtpPpt ∈∈=• ),(: . - tn

• 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 { }normn AtpPpt ∈∈=• ),(: . - ti

• 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 { }inhii AtpPpt ∈∈=• ),(: . - •t est l’ensemble de places de sorties de la transition t tel que { }AptPpt ∈∈=• ),(: . - •p est l’ensemble de transitions de sorties de la place P tel que { }AtpTtp ∈∈=• ),(: .

3. Finalement, dans un ECAPE-net une séquence de nœud knnn ,...,, 21

(dénoté S) est une connexion du nœud n1 (une place ou transition) jusqu’au nœud nk tel que Ann ii ∈+1, . Notons qu’une séquence est appelée élémentaire si chaque nœud est unique.

9.2.3 Les règles de franchissement des transitions dans le ECAPE-net

9.2.3.1 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


160

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- 1)(, ≥∈∀ • pMtp compn 2- ),()(, comptpWpMPp ≥∈∀ 3- Cond(tcomp) = vrai

Notons que la transition composée est également tirée quand il n’y a aucun jeton, durant l'intervalle de temps [d1, d2], 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:

1)(,],,[ 21 ≥∈¬∃∈∀ • pMtpddd compi

9.2.3.2 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- 1)(, ≥∈∀ • pMtp action 2- Cond(taction) = PstCond(taction) = vrai Cependant, les transitions SKIP TSkip et (qui permettent de sauter

l’exécution d’une activité donnée) les transitions CANCEL TCancel (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).


161

9.2.3.3 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(taction) = faux.

9.2.4 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:

9.2.2.1 Construction de la conjonction d’événements

La conjonction d’événements )( 21 ee ∧ exprime que les deux e1 et e2 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 e1 et e2 sont marquées. Après le tir de la transition composée, la place composée ec est marquée.

Figure9.3 Patrons des transitions CANCEL and SKIP


162

9.2.2.2 Construction de la disjonction d’événements

La disjonction d’événements )( 21 ee ∨ exprime qu’au moins l’un des deux événements e1 ou e2 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 e1 ou e2 est marquée. Après le franchissement de l'une des deux transitions composées, la place composée ec est marquée.

9.2.2.3 Construction de l’événement NOT

L’événement ]2,1[1 ddine¬ caractérise le fait qu’un événement ne s’est pas produit dans un intervalle du temps [d1, d2]. 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 e1 n'est pas marquée dans l'intervalle du temps [d1, d2]. Après le franchissement de la transition composée, la place composée ec est marquée.

Figure9.4 Construction de la conjonction d’événements dans ECAPE-net

Figure9.5 Construction de la disjonction d’événements dans ECAPE-net


163

9.2.2.3 Construction d’une séquence d’événements

Une séquence d’événements (seq(e1, e2)) exprime la succession de deux événements tels que l’événement e1 se produit avant l'événement e2. 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 e1 et e2 sont marquées et que la condition )()( 21 ee ττ < est satisfaite. Après le franchissement de la transition composée, la place composée ec est marquée.

9.2.2.1 Construction d’une simultanéité d’événements

Une simultanéité d’événements (sim(e1, e2)) exprime une succession de deux événements tel que l’événement e1 se produit en même temps que l'événement e2. 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 e1 et e2 sont marquées et que la condition )()( 21 ee ττ = est satisfaite.

Figure9.6 Construction de l’événement NOT dans ECAPE-net

Figure9.7 Construction d’une séquence d’événements dans ECAPE-net


164

Après le franchissement de la transition composée, la place composée ec est marquée.

9.2.2.1 Construction de multi-occurrences d’un événement

Une multi-occurrences d’un événement (OCC(n, e1) in[d1, d2]) exprime que l’événement e1 se produit n fois dans l'intervalle du temps [d1, d2]. 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 e1 est marquée par n jetons dans l'intervalle de temps [d1, d2]. Après le franchissement de la transition composée, la place composée ec est marquée.

9.2.2.1 Construction d’un événement ANY

L’événement ANY (m, e1, e2, …, en) exprime m événements parmi l’ensemble { e1, e2, ..., en} 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 e1, e2, ..., en sont marqués. Chacune de ces n transitions vont marquer la

Figure9.8 Construction d’une simultanéité d’événements dans le ECAPE-net

Figure9.9 La construction d’une multi-occurrence d’un événement dans ECAPE-net


165

place intermédiaire ei. 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 ec en marquant sa place.

9.2.5 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).

Figure9.10 Construction d’un événement ANY dans ECAPE-net


166

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

Figure9.11 Le ECAPE-net du processus de traitement de commande


167

d’action de la règle r1 « 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 r2 et l'action de sélection d’un livreur de la règle r3, 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 r2 et r3. 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


168

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 ECAPE-net.

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.

9.3.1 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


169

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.

9.3.1.1 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 pstart et au moins une place de fin pend, (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) Pstart ≠ Pend ≠ Ø (2) STPn ∃∪∈∀ , tel que SpSpSn endstart ∈∧∈∧∈

9.3.1.2 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) TtPPp end ∈∃−∈∀ , tel que •∈ pt (2) startPPpTt −∈∃∈∀ , tel que •∈ tp

9.3.1.3 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) ,Tt ∈∀ ├ )(tCond et ├ )(tPstCond (2) ,Sequencess∈∀ ├


170

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 <tvérification du client, tcalcul du prix initial , tcomposeé, tcalcul 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) ˄ ))()(( 21 ee ττ < ˄ (la date de livraison correspond au besoin de client) ˄ (le prix total est supérieur à zéro).

9.3.1 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 M0,

il existe une séquence de franchissement liant l’état M à l’état final Mf Formellement: )()( fo MMMMM →⇒→∀ ∗∗

- L’état final Mf est le seul état accessible à partir de l’état initial M0 contenant au moins un jeton dans la place de fin pend. Formellement : )0()0( 0 =⇒≥∧→∀ ∗ MMMMM


171

- Il y a pas de transition non atteignable dans le ECAPE-net.

Formellement : Tt ∈∀ ',MM∃ '0 MMM t→→∗

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.

Partie 3 Validation

Validation / La plateforme BP-FAMA

173

10 Plateforme BP-FAMA

10.1 Introduction

10.2 Architecture générale de BP-FAMA

10.2.1 La phase de spécification

10.2.2 La phase d’exécution

10.2.3 La phase de diagnostique

10.2.4 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.

10.2 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


174

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 ECAPE-net. 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 10.1.

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.

Figure 10.1 L’architecture de la plateforme BP-FAMA


175

10.2.1 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).


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.


176

10.2.3 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.

10.2.4 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


177

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.

10.3 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 10.2.


178

- 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.

Figure 10.2 Le processus GMF de génération d’éditeur graphique [Ecl09 f]


179

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

Figure 10.3 L’éditeur graphique du langage ECPAPE-L


180

Universal Network/Graph Framework) qui permet la modélisation et la visualisation d’un graphe donné (voir la figure 10.4).

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).

Figure 10.4 L’éditeur graphique du langage ECPAPE-L


181

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 10.6.

Figure 10.5 le calcul du coût du changement d’une règle


182

Figure 10.6 Le diagramme de transformation du modèle ECAPE-M vers un réseau ECAPE-net


183

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).

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

Figure 10.7 L’interface de l’outil PIPE [Blo03]


184

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.

Partie 4 Conclusion générale

Conclusion générale

186

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.


187

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


188

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.


189

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 self-healing, 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.


190

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.

191

Bibliographie

A

[Ada05] 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, 2005. FEUP.

[ARIS07] ARIS, «The Event-driven Process Chain». Dans ARIS Design Platform, Spinger 2007.

[Att07] 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 Ap-proach». Dans la 1ere European Conference, ServiceWave 2008, Madrid, Spain, December 10-13, 2008.

[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, vol-ume 3185 of Lecture Notes in Computer Science, pages 200{236, Berti-nora, Italy, September 2004. Springer-Verlag.

[Ber04] Bertot, Y., Castéran, P., « Interactive Theorem Proving and Program Development : Coq'Art: The Calculus of Inductive Construc-tions».Springer, Series: Texts in Theoretical Computer Science. An EATCS Series 2004, XXV, 469 p., Hardcover, ISBN: 3-540-20854-2

192

[Ber04] Debauche, B. et Mégard, P., « Business Process Management: pilo-tage métier de l'entreprise ». Lavoisier, 2004, ISBN 978-2746208520.

[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 Sprin-ger LNCS 2900 (IFIP Series), 2004

[Blo03] Bloom, J., Clark, C., Clifford, C., Duncan, A., Khan, H., Pa-pantoniou 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., «Spe-cification and Verification of Views over Composite Web Services Using High Level Petri-Nets». Dans ICEIS:9th International Conference on Enterprise Information , Madeira, 2007.

[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, 2008.

[Bou09 a] Boukhebouze M., Amghar, Y., Benharkat, A., Mamaar, Z., «A rule-based modelling for the description of flexible and self-healing business processes». Dans 12th East European Conference on Advance Databases and Information Systems, 7-10 september, Riga Latvia, Letonie, ADBIS’2009

[Bou09 b] Boukhebouze M., Amghar, Y., Benharkat, A., Mamaar, Z., «Rule-based modelling and verification of business processes us-ing ECAPE net». Dans Thirteenth IEEE International Enterprise Computing Conference, Auckland, 31 august – 4 september, EDOC 2009

193

[Bou09 c] 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 In-formation , Milan, 2009.

[Bra05] Brambilla, M., Ceri, S., Comai, S., Tziviskou, C., « Exception handling in workflow-driven web applications». Dans A. Ellis and T. Hagi-no, editors, Proceedings of the 14th International Conference on World Wide Web (WWW 2005), pages 170-179, Chiba, Japan, 2005. ACM Press. CCPP99

[Bra09] Brahe, S., Bordbar, B., «A methodology for domain-specific business process modelling and implementation». Dans la revue International Jour-nal of Business Process Integration and Management (IJBPIM), Volume 4 - Issue 1 – 2009.

[BRG02] The Business Rules Group, «Defining Business Rules, What are they really? ». Dans www.businessrulesgroup.org, July 2000.

[Bry06 a] Bry, F., Eckert, M., Pătrânjan, P. L., Romanenko, I., « Real-izing Business Processes with ECA Rules: Benefits, Challenges, Limits». Dans 4th International Workshop, PPSWR 2006, Budva, Montenegro, June 10-11, 2006.

[Bry06 b] Bry,F., Eckert, M., Pătrânjan, P.L., « Reactivity on the Web: Pa-radigms and Applications of the Language XChange ». Dans Journal of Web Engineering, Volume 5, Number 1, Rinton Press (2006)

C

[Car04] 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)

[Car06] 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, 2006. pp. 167-173, IEEE Computer Society. ISBN: 0-7695-2670-5.

194

[Car07] Cardoso, J. «Complexity analysis of BPEL Web processes». Dans la revue Software Process: Improvement and Practice 12(1): 35-49 (2007)

[Cas07] 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

[Cha04 ] 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.

[Cha97] Charles, N., Bowman, H., Thompso, S., «From ACT-ONE to Miranda, a Translation Experiment ». Dans Computer Standards and Inter-faces Journal , 19(1), May 1997.

[Chu04] Chulsoon, P., Injun, C., « Management of business process con-straints using BPTrigger». Dans la revue Computers in Industry 55 (2004) 29–51

[Cla06] 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: 0-387-3239-5, Springer 2006

[Cli86] Cliff, J., «Systematic Software Development Using V. D. M. » Prentice-Hall ISBN 978-0138807252, 1986.

[Cru03] Crusson, T., «Business Process Management : De la modélisation à l’exécution ». Dans le rapport technique (Livre Blanc) Intalio, 2003.

D

[Deh03] 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 22-08-2003.

[Deh05] Dehnert, J., Zimmermann A., «On the suitability of correctness criteria for business process models». Dans Proc. 3rd Int. Conf. on

195

Business Process Management (BPM 2005) Nancy, France, Septem-ber 2005, pp. 386-391., 2005

[Deu07] Deutch, D., Milo, T., « Querying Structural and Behavioral Properties of Business Processes». Dans 11th International Symposium, DBPL 2007, Vienna, Austria, 169-185, Springer Berlin / Heidelberg, 2007.

E

[Ecl09 a] Eclipse, « Web tools plateforme project ». Dans http://www.eclipse.org/webtools/, 2009

[Ecl09 b] Eclipse, « SOA technology project ». Dans http://www.eclipse.org/stp/, 2009

[Ecl09 c] Eclipse, « Eclipse Modeling Project ». Dans http://www.eclipse.org/modeling/, 2009

[Ecl09 d] Eclipse, « Eclipse Modeling Framework Project (EMF)». Dans http://www.eclipse.org/modeling/emf/, 2009

[Ecl09 e] Eclipse, « The Graphical Editing Framework (GEF)». Dans http://www.eclipse.org/gef/, 2009

[Ecl09 f] Eclipse, « The Eclipse Graphical Modeling Framework (GMF) ». Dans http://www.eclipse.org/modeling/gmf/, 2009

[Ecl09 g] Eclipse, « ATL (ATLAS Transformation Language)». Dans http://www.eclipse.org/m2m/atl/, 2009

[Esh03] Eshuis.R, Dehnert.J, «Reactive petri nets for workflow ». Dans Application and Theory of Petri Nets 2003. Pages 296--315, Springer, 2003

[Eul09] Euler, «Apprendre et enseigner les mathématique». Dans http://euler.ac-versailles.fr/baseeuler/lexique/notion.jsp?id=180 , 2009

196

F

[Fis04] Fisteus, J., A., Fernández L., S., Kloos. C., D., «Formal Verifi-cation 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.

[For79] Forgy, C., «On the efficient implementation of production systems». Dans Ph.D. Thesis, Carnegie-Mellon University, 1979.

[Fux03] 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 Con-ference, 8th-12th September 2003, Monterey Bay, California U.S.A., 2003

G

[Gar09] Gardner, T., «UML Modelling of Automated Business Processes with a Mapping to BPEL4WS». Consultable via ce lien : http://www.cs.ucl.ac.uk/staff/g.piccinelli/eoows/documents/, Octobre 2009

[Geo06 a] Goedertier, S. Vanthienen, J., «Designing compliant business processes with obligations and permissions». Dans BPM 2006 International Workshops, Vienna , AUTRICHE. 2006.

[Geo06 b] 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: 94-104

[Geo07] 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 Eindho-ven, 2007

[Giu06] Giurca, A., Lukichev, S., Wagner, G., « Modeling Web Services with URML». Dans Proceedings of SBPM2006, Budva, Montenegro (11th June 2006), June 2006

197

[Gog96] Goguen, J., Grant, M., «Algebraic Semantics of Imperative Pro-grams». The MIT Press (May 22, 1996), ISBN 978-0262071727.

[Got08] Gottardi, G., Arico, M. R., Piovesana, A., «On the drivers of ex-tended enterprise and the problems of integration and governance». Dans la revue International Journal of Business Process Integration and Manage-ment (IJBPIM), Volume 3 - Issue 4 - 2008.

[Gri04] Grigori, D., Casati, F., Castellanos, M., Dayal, U., Sayal, M., Shan, M.C., «Business Process Intelligence». Dans la revue Com-puters in Industry 53 (2004) 321–343, 2004

[Gru07] Gruhn, V., Laue, R., «What business process modelers can learn from programmers». Dans Science of Computer Programming Journal 65 (2007) 4–13, 2007.

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 Tech-nique et Science Informatique 28(2):229-262. 2009.

[Hil09] Hillah, L.M., Kindler, E., Kordon, F., Petrucci, L., Trèves, N., «A primer on the Petri Net Markup Language and ISO/IEC 15909-2». Dans Petri Net Newsletter (originally presented at the 10th International workshop on Practical Use of Colored Petri Nets and the CPN Tools -- CPN'09)

[Hin05] 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 2005. Springer-Verlag.

[Hom04] Hommes, L.J, «The Evaluation of Business Process Modeling Tech-niques». Dans Thèse de doctorat à L’université de technologie de Delft, soutenu le 26 janvier 2004.

198

[Hwa06] Hwang, Y.F., Rine, D., «Verification framework and algorithms for in-tegrating information distribution systems». Dans la revue Information & Software Technology 48(9): 876-889 (2006).

I

[ ilog09] iLog, dans : http://ftp.ilog.fr/products/jrules/, 2009

J

[Jab96] Jablonski, S., Bussler, C., «Workflow Management: Modeling Concepts, Architecture and Implementation», Itp New Media, 1996, ISBN 978-1850322221

[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), 2000.

[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. 1806. Springer-Verlag, London, 16-29, 2000.

[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. 1806. Springer-Verlag, London, 16-29. 2000

199

[Kos04] Koshkina, M., van Breugel, F., «Modelling and verifying web ser-vice orchestration by means of the concurrency workbench». Dans ACM SIGSOFT Software Engineering Notes, 2004.

L

[Lee07 ] Lee, S., Kim, T., Y., Kang, D., Kim, K., Lee, J., Y., «Composi-tion of executable business process models by combining business rules and process flows». Dans Expert Systems with Applications. Volume 33, Issue 1, July 2007, Pages 221-229

[Leu07] Leutenmayr, S., «Selected Languages for Web Services Composition: Survey, Challenges, Outlook ». Dans thèse de doctorat à Université Louis-et-Maximilien de Munich, soutenue le 31-01-2007.

[Ley01] Leymann. F., «Web Services Flow Language (WSFL 1.0)». Dans http ://www-3.ibm.com/software/solutions/webservices/pdf/WSFL.pdf. 2001.

[Ley02] Leymann, F., Roller D., Schmidt, M.T., «Web services and business process management» . Dans IBM System Journal Volume 41, Number 2, 2002

[Ley99] Leymann, F., Roller, D., «Production Workflow - Concepts and Tech-niques». Prentice Hall, 1999, ISBN 978-0130217530.

[Li04] Li.X. Marín.J.M, «Composite Event Specification in Active Data-base 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 97-116. 2004.

[Lu07] Lu, R., Sadiq, S., «A Survey of Comparative Business Process Model-ing Approaches». Dans 10th International Conference, Bis 2007, Poznan, Poland, April 25-27, 2007

200

M

[Maa09] 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 re-vue International Journal of E-Business Research (IJEBR) 9(4). 2009.

[Mar03] Martens, A., «On usability of web services». Dans 4th International Conference on Web Information Systems Engineering Workshops, Italy. 2003

[Mar07] Markovic, I., Karrenbrock, M., « Semantic Web Service Dis-covery for Business Process Models». Dans WISE 2007 International Workshops Nancy, France Proceedings, Springer Berlin / Heidelberg, 2007

[Mie08] Mietzner, R., Leymann, F., Papazoglou , M.P., « Defining Composite Configurable SaaS Application Packages Using SCA, Variabil-ity Descriptors and Multi-tenancy Patterns ». Dans 3eme International Con-ference on Internet and Web Applications and Services, Athens, Greece, 2008

[Mil80] Milner, R., «A calculus of communicating systems». Dans Lecture Notes in Computer Science, vol. 92, Springer-Verlag, Berlin, 1980.

[Mil99] Milner, R., « Communicating and Mobile Systems: The π-Calculus ». Dans Rapport de recherche Cambridge University , Cambridge, UK, 1999.

[Mri07] Mrissa, M., Ghedira C., Benslimane, D., Maamar, Z., Rosenberg, F., Dustdar S., « A Context-based Mediation Ap-proach to Compose Semantic Web Services». Dans la revue ACM Transac-tions on Internet Technology 8(1), ACM Association for Computing Ma-chinery. 2007.

[Mul04] Müller, R., Greiner, U., Rahm, E. « AgentWork: a Workflow Sys-tem Supporting Rule-Based Workflow Adaptation». Dans Data & Know-ledge Engineering, Vol. 51(2) (2004) 223-256

201

N

[Net06] Netjes, M., Reijers, H.A., Van der Aalst, Wil M. P, «Support-ing the BPM lifecycle with FileNet ». Dans le Workshop EMMSAD, 18th International Conference on Advanced Information Systems Engineering (CAiSE'06) Namur, 2006.

O

[OASIS03] OASIS, «Collaboration-Protocol Profile and Agreement Specification, ebXML Trading-Partners Team Version 1.0». Dans ebXML specification 2003.

[OASIS04] OASIS, « Web Services Reliable Messaging TC WS-Reliability 1.1». Dans WS-Reliability v1.1 specification 2004.

[OASIS07] OASIS, «Business Process Execution Language for Web Services (BPEL4WS 2.0)». Dans le rapport de spécification, 2007.

[Ola00] Olalla, Marta, « Information technology in business process reengi-neering ». Dans la revue International Advances in Economic Research, Volume 6, Number 3, août 2000

[OMG04] Object Management Group, « Production Rule Representation (PRR) Version 1.0». Dans le rapport de spécification version 1.0, numéro : dtc/2007-11-04, 2004.

[OMG08 a] Object Management Group, «Unified Modeling Language». Dans le rapport de spécification version 2.1.1, numéro : formal/2007-02-03, 2007.

[OMG08 b] Object Management Group, « Semantics of Business Vocabulary and Business Rules (SBVR 1.0)». Dans le rapport de spécification numéro : formal/08-01-02, 2008.

[OMG09] Object Management Group, «Business Motivation Model (BMM 1.2)». Dans le rapport de spécification numéro : formal/2009-01-03, 2009.

202

[Ouy05 a] Ouyang, C., Verbeek, E., van der Aalst, W.M.P., Breutel, S., Dumas, M. ter Hofstede, A.H.M., WofBPEL, « a tool for au-tomated analysis of BPEL processes». Dans ICSOC 2005, International Conference of Service-Oriented Computing, Berlin. 2005.

[Ouy05 b] Ouyang, C., Verbeek, E., van der Aalst, W.M.P., Breutel, S., Dumas, M. ter Hofstede, A.H.M., «WofBPEL: a tool for auto-mated analysis of BPEL processes». Dans ICSOC 2005, International Con-ference of Service-Oriented Computing ,Berlin. 2005

[Ouy06] Ouyang, C., van der Aalst, W.M.P., Dumas, M., ter Hofs-tede, A.H.M., «Translating BPMN to BPEL». Dans le rapport BPM-06

[Owr93] Owre, Sam, Rushby, John, Shankar, Natarajan, « The PVS Specification Language». Dans http://www.csl.sri.com/papers/pvs-language/ 1993

P

[Pas06] 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)

[Per03] 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, 2003. To be published in Lecture Notes in Computer Science. 2003

[Pes06] Pesic, M. van der Aalst, W. M. P., «A declarative approach for flexible business processes management». Dans BPM 2006 International Workshops, Vienna , AUTRICHE. 2006.

[Por03] Porter, Michael, « L'avantage concurrentiel». Dunod, Paris, 2003 (Réédition), ISBN 978-2100073948.

[Pu05] Pu, G., Zhao, X., Wang, S., Qiu. Z, «Towards the semantics and verification of BPEL4WS». Dans Proceedings of the International Work-shop on Web Languages and Formal Methods, volume 151(2) of Electronic

203

Notes in Theoretical Computer Science, pages 33{52, New Castle, UK, July 2005. Elsevier.

R

[Ram06] Rampacek, S., «Sémantique interactions et langages de description des services web complexes». Dans thèse de doctorat, université de Reims Champagne-Ardenne, 2006

[Rev06] Regev, G., Soffer, P., Schmidt, R., «Taxonomy of Flexibility in Business Processes». Dans Seventh Workshop on Business Process Model-ing, Development, and Support In conjunction with CAiSE’06

[Rew09 a] Rewerse Groupe, dans : http://rewerse.net/I1/oxygen.informatik.tu-cottbus.de/rewerse-i1/default.htm, 2009

[Rew09 b] Rewerse Groupe, dans : http://hydrogen.informatik.tu-cottbus.de/wiki/index.php/Portal:Rules, 2009

[Rim08] 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 In-ternational Conference on E-Commerce Technology CEC 2005.

[Ros07] Rosemann, M., van der Aalst, W.M.P, «A Configurable Refer-ence Modelling Language». Dans la revue Systems Volume 32 , Issue 1 (March 2007) Pages 1-23 : 2007

[Rus04 a] 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, 2004.

[Rus04 b] 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-2004-01, Queensland University of Tech-nology, Brisbane, 2004

204

[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 Busi-ness 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 95-104, Hobart, Australia, 2006. 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 , BPMcen-ter.org, 2006.

[Rus06 c] Russell, Nick, Van der Aalst, Wil M. P, Ter Hofstede Ar-thur, « Exception Handling Patterns in Process-Aware Information Sys-tems ». Dans le rapport interne BPM-06-04 , BPMcenter.org, 2006.

[Rus09] 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 ] Sadiq, S. W., Orlowska, M. E., Sadiq, W., «Specification and va-lidation of process constraints for flexible workflows». Dans Information System journal, 30(5):349–378, 2005.

[Sal04] 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, 2004.

[Sch00] 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 465474, Aarhus, Denmark, June 2000. Springer-Verlag.

[Sch02] Schroeder, M. and Wagner G., dans le procedure du Workshop on Rule Markup Languages for Business Rules on the Semantic Web., Italy, June 2002. CEUR-WS Publication Vol-60

205

[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 Re-port BPM-07-11, BPMcenter.org, 2007.

[Ser08] Serrour B., Gasparotto D., Kheddouci, H., Benatallah, B. « Message Correlation and Business Protocol Discovery in Service Interac-tion Logs. ». Dans la 20th International Conference on Advanced Informa-tion Systems Engineering (CAiSE’08), LNCS 5074, pp. 405–419, 2008.

[Smi02] Smith, Graeme, Kammüller, Florian, Santen, Thomas «En-coding Object-Z in Isabelle/HOL». Dans la revue Lecture notes in compu-ter science 2002, vol. 2272, pp. 82-99[Note(s) : XII, 534 p., ] (15 ref.) ISBN 3-540-43166-7 ;

[Smi03] Smith, H., Fingar, P., «Workflow is just a Pi process». Dans Comput-er Sciences Corporation report, November 2003.

[Son08] Song, Minseok, Van der Aalst, Wil M. P, «Towards Comprehen-sive Support for Organizational Mining». Dans le revue Decision Support Systems, Volume 46, Number 1, Pages 300-307, Dec. 2008

[Sub08] 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 In-ternet (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 Applica-tions Symposium, Delhi, India. pp. 166-173. IEEE Computer Society Washington, DC, USA. ISBN 0-7695-2577-6. ISSN 1098-8068. 2006.

[Tha01] Thatte. S., «XLANG - Web Services For Business Process Design, ». Dans http ://www.gotdotnet.com/team/xml_wsspecs/xlang-c/default.htm. 2001.

206

[Tru06] 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.

[TUE09] Université technique d’Eindhoven, http://prom.win.tue.nl/research/wiki/ , 2009-07-19

[Tun96] Tumay, K., «Business Process Simulation». Dans le Proceedings de the 1996 Winter Simulation Conference, pages 93–98. ACM Press, 1996.

[Tur07] Turner, K., J., «Representing and analysing composed web services us-ing CRESS ». Dans Journal of network and computer applications ISSN 1084-8045 vol. 30, no2, pp. 541-562, 2007.

V

[Van02] Van der Aalst, ter Hofstede, A.H.M., « Yet Another Workflow Language». Dans le rapport interne QUT Technical report, FIT-TR-2002-06, Queensland University of Technology, Brisbane, 2002

[Van02] Van der Aalst, Wil M. P, Van Hee, Kees, «Workflow manage-ment: models, methods, and systems», MIT Press, 2002, ISBN: 978-0262011891.

[Van03 a] 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, 2003. Springer-Verlag Berlin Heidelberg 2003

[Van03 b] 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 298-305. IEEE Computer Society, Los Alamitos, CA, 2003.

[Van05 a] 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):129-162, 2005.

207

[Van05 b] Van Dongen, B.F., Jansen-Vullers, M.H., «Verification of SAP Refer-ence Models». Dans BPM 2005, 3rd International Conference, France, 2005.

[Van06] Van Breugel.F, Koshkina, M., «Models and Verification of BPEL». Dans le Rapport de recherche, université de York. Sptembre 2006.

[Van07] van der Aalst, W.M.P., Lassen, K.B, «Translating unstructured workflow processes to readable BPEL: Theory and implementation». Dans Information and Software Technology , 2007.

[Van08 ] Van Eijndhoven.T, Iacob.M.E, Ponisio.M.L., «Achieving Busi-ness Process Flexibility with Business Rules ». Dans EDOC 2008: 95-104

[Van98] 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, 1998.

[Vas06] Vasko, M., Dustdar, S., «A view based analysis of workflow model-ing languages». Dans Proceedings of the 14th Euromicro International Con-ference on Parallel, Distributed, and Network-Based Processing (PDP’06).

W

[W3C04 a] W3C, «OWL Web Ontology Language 2.0». Dans W3C Submission REC- REC-owl-features-20040210/2004.

[W3C04 b] W3C, « SWRL: A Semantic Web Rule Language Combining OWL and RuleML». Dans W3C Submission SUBM-SWRL-20040521/2004.

[W3C06 ] W3C, «Web services policy 1.2. Framework (WS-policy) ». Dans W3C Member Submission 25 April 2006.

[W3C09] W3C, « Rule Interchange Format». Dans W3C Submission REC- REC- RIF-CW-9-09/2009.

[W3C99 a] W3C, « Resource Description Framework (RDF)». Dans W3C Submission REC-rdf-syntax-19990222/1999.

208

[W3C99 b] W3C, « Transformations XSL (XSLT) 1.0». Dans W3C Submission REC- REC-xslt-19991116 /1999.

[Wag05] Wagner, G, «Rule Modeling and Markup». Dans Reasoning Web, 3564 ed, N. Eisinger and J. Maluszynski, Eds. Msida, Malta: Springer, 2005, pp. 251-274.

[Wag06] Wagner, G., Giurca, A., Lukichev S., « Modeling Web Services with URML ». Dans proceedings of Semantics for Business Process Man-agement Workshop, Budva, Montenegro, June 2006.

[WfMC08] The Workflow Management Coalition, « Final XPDL 2.1 Specifi-cation », dans le Rapport de spécification numéro WFMC-TC-1025-Oct-10-08-A, 2008.

[WfMC99] The Workflow Management Coalition, «Workflow Management Coalition Terminology & Glossary», Rapport numéro WFMC-TC-1011 Is-sue 3.0. Février 1999.

[Whi03] White, S. A., «Process Modelling Notations and Workflow Patterns». Dans Rapport technique IBM, January 2004.

[WPI09] Workflow Patterns Initiative, http://www.workflowpatterns.com/ juillet 2009.

Y

[Yan05] 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. 2005.

[Yog98] Yogesh, Malhotra, «Business Process Redesign: An Overview ». Dans la revue IEEE Engineering Management Review, vol. 26, no. 3, 1998.

209

Z

[Zen01] 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)

[Zen02] 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: 141 – 150 : 2002

[Zur07] zur Muehlen, M., Indulska, M., Kamp G., « Business Process and Business Rule Modeling: A Representational Analysis». Dans 3rd In-ternational Workshop on Vocabularies, Ontologies and Rules for The En-terprise (VORTE 2007), Annapolis, Maryland, USA, 15 Octobre, 2007.

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

Annexe 1

211

• Etat de l’art sur la gestion des

processus métier (BPM)

1.1 Introduction

1.2 Terminologie

1.2.1 Processus

1.2.2 Processus métier

1.2.3 La gestion des processus métier

1.3 Les origines du BPM (gestion des processus métier)

1.3.1 L’intégration métier

1.3.2 Le Workflow

1.3.3 Mesurer de performance et maîtrise de processus

1.4 Le cycle de gestion d’un processus

1.4.1 La phase de modélisation



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 colla-boration, la définition, le déploiement, l'exécution, et le contrôle des pro-cessus.

La gestion des processus appelée BPM (Business Process Mana-gement, 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 fonction-nelles 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.

Annexe 1

212

Dans ce chapitre, nous introduisons la gestion des processus mé-tier en précisant la terminologie, son origine, le cycle de gestion d’un pro-cessus et les outils de gestion proposés.

1.2 Terminologie

1.2.1 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 con-cepts 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 partielle-ment 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 uti-lisé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 ban-caires, 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» 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

Annexe 1

213

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 va-leur ajoutée aux clients.

Le Workflow Management Coalition (WfMC) identifie, dans [WfMC99], plusieurs terminologies et concepts de base associés à un pro-cessus 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 ob-

jectifs 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 proces-sus 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 indivi-duelles, 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-

Annexe 1

214

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.

1.2.3 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 uti-lisant des méthodes, des techniques et des logiciels pour modéliser, exécu-ter, contrôler et analyser les processus opérationnels en s’appuyant sur des acteur qui peuvent être : des êtres humains, organisations, des applica-tions, 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 pre-nant 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éfinis-

sant, 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 ;

Annexe 1

215

- 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 entre-prise 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 applica-tions, 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 tech-nologies Internet avec XML et le protocole Web HTTP. Cette dernière so-lution 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 con-siste à 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 sui-vante, 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 tech-nologie 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 mes-sages (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.

Annexe 1

216

Figure 1.3 Les racines du BPM [Ber04]

1.3.1 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 organi-sant la circulation d’informations entre les différentes applications consti-tuant 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 appli-cations existantes.

Néanmoins, les EAI ne peuvent pas gérer les processus inter-entreprise. En revanche, les outils de B2Bi, qui visent à définir les proces-sus de collaboration entre entreprises partenaires par flux de messages, pa-lient 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 ex-ternes 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

Annexe 1

217

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.

1.3.2 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 à accom-plir entre les différents acteurs d'un processus [Jab96]. Le Workflow Ma-nagement Coalition (WfMC) définit un Workflow comme : « L'automati-sation, 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-

Annexe 1

218

tures, les bon de commande, … etc. Ce type Workflow assure la coordina-tion, 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 in-teragir 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 Work-flow 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 rai-son 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 tech-nologie 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épon-dant à 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émen-ter un modèle de processus en configurant et automatisant toutes les tâches

Annexe 1

219

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].

1.3.3 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 per-formances 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 Indica-tor). Ce sont des métriques qui permettent évaluer les facteurs clés de suc-cè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'ef-ficience 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émen-ter et valider les processus cibles.

Les outils BPM viennent aujourd’hui pour regrouper ces ap-proches 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é propo-sées (exemple [Van03 a], [Ber04], [Net06] et [Leu07]). D’une façon géné-

Annexe 1

220

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

1.4.1 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épendam-ment 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 confi-guration des processus abstraits où les détails fonctionnels du processus sont spécifiés. Le concepteur décrit de nombreuses informations tech-niques telles que : le format des messages échangés, les protocoles de transport utilisés, les services et les applications invoquées dans le proces-sus. 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 simula-tion (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 pro-cessus est ensuite redéfini et simulé ou vérifié de nouveau.

Annexe 1

221


Dans la phase d’exécution, le processus exécutable qui spécifie le déroule-ment de l’ensemble des activités d’un processus est interprété par un mo-teur d’exécution appelé BPE (Business Process Engine). Le BPE est le res-ponsable des interactions entre les participants du processus (les documents, les informations et les tâches). Le BPE qui également gère le flux de contrôle d’un processus en faisant appel aux différentes ressources. Si une exception se produit durant l’exécution du processus, le BPE a le rôle de lancer une action de compensation pour amener le processus à une exécution valide.

Une BPE peut être un moteur de Workflow qui est utilisé pour in-terpréter la définition du processus, d'interagir avec les participants et in-voquer les applications de l’entreprise. Cependant, l’architecture SOA (Service Oriented Architecture) est de plus en plus adoptée, dans les entre-prises, pour répondre aux problèmes d’intégration du SI. En effet, cette architecture propose d’urbaniser le SI sous forme de services réutilisables qui peuvent être découverts et composés dynamiquement [Cru03]. La con-séquence d’utilisation de l’architecture SOA est que le processus métier sera achevé par une composition de services. Dans la littérature plusieurs papiers (exemple [Cla06] et [Leu07]) expliquent que l’utilisation de la composition de services pour exécuter un processus métier permet de ré-pondre aux besoins de flexibilité et d’adaptabilité. Dans ce cas de figure, le BPE a pour rôle d’invoquer les services qui composent le processus.


Dans la phase de diagnostic, l’exécution du processus est analysée dans le but de mesurer les performances opérationnelles en utilisant les techniques d’extraction d'informations à partir de logs des événements (Process-mining). Le but du process-mining est de faire une analyse a posteriori du processus afin de tracer les transactions des protocoles métier ainsi de dé-couvrir le modèle du processus à partir des informations cumulés lors de la phase d’exécution. Le modèle du processus découvert sera comparé au pro-cessus modélisé pour s’assurer qui s’agit du même déroulement de l’ensemble des activités.

Selon Song et al., dans [Son08], l'idée du process-mining est de découvrir, de contrôler et d'améliorer des processus par extraction de con-naissances à partir de journaux d'événements (exécution des activités, ac-teurs, dates d’exécutions …etc.). Pour cela trois types de process-mining sont considérés (1) La découverte du modèle original du processus permet

Annexe 1

222

de reconstruire le modèle de processus en se basant sur la description des comportements décrits dans les logs. (2) Le contrôle de la conformité compare le modèle a priori du processus avec le comportement observé dans le log afin de vérifier si l’exécution du processus est conforme au be-soin (modèle a priori). (3) L'amélioration du modèle du processus en se basant sur les détails extraits des journaux d'événements.

1.4 Les systèmes de gestion des processus (BRMS)

Les BRMS sont des logiciels qui supportent le cycle de gestion du proces-sus (BPM) en permettant à toutes les parties prenantes d'avoir une bonne compréhension de leurs processus métier et de ses performances. Les BPMS permet l’automatisation des activités, la collaboration, l'intégration avec d'autres systèmes, l'intégration de partenaires, la surveillance et le contrôle des processus métier.

Pour expliquer le rôle joué par les systèmes de gestion des proces-sus pour une entreprise, Debauche et Mégard comparent, dans [Ber04], ces systèmes aux systèmes la gestion de base de données (DBMS). Cette com-paraison est détaillée dans le tableau 1.1.

Tableau 1.1 La comparaison entre les BPMS et les DBMS [Ber04]

En effet, les systèmes BPMS offrent aux entreprises une agilité et permettent de capitaliser sur le système d’information existant. Pour ce faire, les BPMS utilisent des éditeurs pour permettre la définition des pro-cessus, un moteur de processus pour l’exécution des activités du processus et un analyseur pour contrôler et améliorer le processus.

Dans la littérature, nous avons recensé plusieurs outils qui suppor-tent tout ou une partie du cycle de gestion du processus. Ces outils sont classés dans le tableau 1.2.

DBMS BPMS Rôle La gestion de données La gestion du processus Meta-modèle standard Relationnel BPMN [OMG09], BPEL [OASIS07]

Langages d’interrogation standard

SQL BPQL [Deu07]

Valeurs ajoutées aux entre-prises

Agilité, gestion totale des don-nées

Agilité, capitalisation sur le sys-tème d’information existant et une gestion totale des processus

Annexe 1

223

Cycle de gestion Outils

Modélisation

Modélisation de haut niveau STP BPMN Modeler, eClarus Business Process Modeler, eBPMN designer

- Intalio BPMS - ARIS - IBM WebSphere - Oracle BPEL Process Designer - Business Process Visual Architect - Eclipse SOA tools platform

Modélisation détaillée ActiveBPEL, JBPEL

Simulation FileNet, ActiveBPEL

Exécution Apache Ode, Active Endpoints, Acti-veBPEL Engine, JBoss

Diagnostique Oracle Discoverer, ProMimport

Tableau 1.2 Les différents outils de gestion de processus métier

Une première catégorie d’outils recensés permet de modéliser un

processus abstrait en utilisant des langages graphiques (généralement le standard BPMN). Ces derniers génèrent le processus détaillé en traduisant la définition de haut niveau vers un langage d’exécution (le standard BPEL). Un exemple de cette catégorie d’outils : eBPMN designer. Une deuxième catégorie d’outils propose une modélisation détaillée du proces-sus (généralement en langage BPEL). La plupart de ces outils permet de vé-rifier ou de simuler le fonctionnement du processus modélisé. Les proces-sus résultats des deux catégories précédentes seront exécutés pour des moteurs d’exécution tels que : ActiveBPEL Engine ou Apache Ode. Tandis que une quatrième catégorie propose d’analyser le processus en vu de l’améliorer, comme l’outil ProMimport. Finalement, nous avons recensé un ensemble de BPMS (des outils qui englobent toutes les fonctionnalités des outils précédents) comme Intalio BPMS ou Oracle BPEL Process De-signer.

1.5 Conclusion

En résumé, 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 tech-niques et solutions proposées pour répondre au besoin d’intégration métier, d’automatisation de flux d’information et le calcul de qualité. Par ailleurs, la discipline BPM a donné naissance à plusieurs challenges de recherche qui peuvent être résumés en trois grandes classes, comme le résume le ta-bleau 1.3 : (1) La première classe de challenges de recherche est liée à la manière de modéliser les processus métier en proposant des modèles de processus qui permettent de répondre au besoin de réingénierie de proces-sus, de la flexibilité, et l’adaptation au changement. Dans cette classe on s’intéresse également à vérifier le bon fonctionnement du processus par des modèles formelles ou par simulation.

Annexe 1

224

Tableau 1.3 Les challenges de recherche de la discipline BPM

(2) La deuxième classe de challenges de recherche s’intéresse à l’exécution des processus métier en utilisant des Workflow ou on composant les ser-vices Web. On s’intéresse également à découvrir et substituer des services pour remplacer ceux qui tombent en panne. (3) La troisième classe de chal-lenges de recherche est liée à comment analyser les processus par les tech-niques de process-mining et comment superviser et améliorer les processus et activités métiers en utilisant des tableaux de bord de pilotage composés d'indicateurs de performances.

Dans cette thèse, nous nous somme 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. Et d’autre part, permettre de vérifier le déroulement du processus exécutable pour s’assurer du son bon fonctionnement. Autre-ment dit, améliorer le fonctionnement des BRMS en garantissant une adap-tation au changement et une facilité d’analyser le bon fonctionnement du processus.

Challenges de recherche Quelques références

Modélisation

Modeling Process Methodologies [Per03], [Fux03] Business Process Reengineering (BPR) [Yog98], [Ola00] Business Process Integration (BPI) [Got08], [Bra09] Business Process Modeling (BP Modeling) [Kno00], [Hom04], [Lu07] Business process simulation [Tun96], [ Jan06] Business process verification [Van98], [Ouy05], [Van06]

Exécution

Workflow Management [Jab96], [Van02] Web Service Composition [Ley02], [Van03 b], [Mie08] Web service discovery & substitution [Tah06], [Mar07], [Maa09] Semantic Web service [Mri07], [Hac09]

Diagnostic Business Process Intelligence [Gri04], [Cas07] Business Activity Monitoring (BAM) [Rim08], [Baa08]

Business Process Mining [Ser08], [Son08], [TUE09]

Annexe 2

Schéma XML du langage RbBPDL

Annexe 2

226

<?xml version="1.0" encoding="UTF-8" standalone="no"?>  <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"xmlns:ns1="http://liris.cnrs.fr/~mboukheb/BP-FAMA/FAMA_RbBPDL.html" targetNamespace="http://liris.cnrs.fr/~mboukheb/BP-FAMA/FAMA_RbBPDL.html" elementFormDefault="qualified" attributeFormDefault="unqualified"> <xsd:import namespace="http://www.w3.org/XML/1998/namespace" schemaLoca-tion="http://www.w3.org/2001/xml.xsd"/> <xsd:element name="Process" type="tProcess"/> <xsd:annotation> <xsd:documentation> This is the root element for a RbBPDL 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="targetNamespace" type="xsd:anyURI" use="required"/> <xsd:attribute name="expressionLanguage" type="xsd:anyURI" de-fault="urn:liris:names:tc:sublang:xpath1.0"/> </xsd:complexType>

 <xsd:element name="Description" type="xsd:string"/> <xsd:element name="Expression" type="tExpression"/> <xsd:complexType name="tExpression" mixed="true"> <xsd:sequence> <xsd:any processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> <xsd:attribute name="expressionLanguage" type="xsd:anyURI"/> </xsd:complexType> <xsd:element name="CompositExpression" type="tEventExpression"/> <xsd:complexType name="tEventExpression" mixed="true"> <xsd:complexContent mixed="true"> <xsd:extension base="tExpression"/> </xsd:complexContent> </xsd:complexType> <xsd:element name="ConditionExpression" type="tConditionExpression"/> <xsd:complexType name="tConditionExpression" mixed="true"> <xsd:complexContent mixed="true"> <xsd:extension base="tExpression"/> </xsd:complexContent>

Annexe 2

227

</xsd:complexType> <xsd:element name="QueryExpression" type="tQueryExpression"/> <xsd:complexType name="tQueryExpression" mixed="true"> <xsd:sequence> <xsd:any processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> <xsd:attribute name="QueryLanguage" type="xsd:anyURI"/> </xsd:complexType> <xsd:element name="Literal" type="tLiteral"/> <xsd:complexType name="tLiteral" mixed="true"> <xsd:sequence> <xsd:any namespace="##any" processContents="lax" minOccurs="0"/> </xsd:sequence> </xsd:complexType> <xsd:simpleType name="tBoolean"> <xsd:restriction base="xsd:string"> <xsd:enumeration value="True"/> <xsd:enumeration value="False"/> </xsd:restriction> </xsd:simpleType> <xsd:element name="ExternalReference" type="tExternalReference"/> <xsd:complexType name="tExternalReference"> <xsd:attribute name="xref" type="xsd:NMTOKEN" use="optional"/> <xsd:attribute name="location" type="xsd:anyURI" use="required"/> <xsd:attribute name="namespace" type="xsd:anyURI" use="optional"/> </xsd:complexType> <xsd:element name="Documentation" type="tDocumentation"/> <xsd:complexType name="tDocumentation" mixed="true"> <xsd:sequence> <xsd:any processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> <xsd:attribute name="source" type="xsd:anyURI"/> <xsd:attribute ref="xml:lang"/> </xsd:complexType> <xsd:element name="Value" type="xsd:string"/> <xsd:element name="MaxValue" type="xsd:string"/> <xsd:element name="MinValue" type="xsd:string"/> <xsd:element name="EgalValue" type="xsd:string"/> <xsd:element name="InitialValue" type="xsd:string"/> <xsd:element name="ParticipantName" type="xsd:NCName"/> <xsd:element name="VariableName" type="xsd:NCName"/> <xsd:element name="InputVariableName" type="xsd:NCName"/> <xsd:element name="OutputVariableName" type="xsd:NCName"/> <xsd:element name="InputOutputVariableName" type="xsd:NCName"/> <xsd:element name="ActivityName" type="xsd:NCName"/>

 <xsd:element name="Participants" type="tParticipants"> <xsd:annotation> <xsd:documentation> This is the participants of R2BPRL process. </xsd:documentation>

Annexe 2

228

</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> <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="ApplicationAutomaticallyDiscover "/> </xsd:choice> </xsd:complexType> <xsd:element name="Human" type="tHuman"/> <xsd:complexType name="tHuman"> <xsd:sequence> <xsd:element ref="HumanRole"/> <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> <xsd:element name="OrganiszationalUnit" type="tOrganiszationalUnit"/> <xsd:complexType name="tOrganiszationalUnit"> <xsd:sequence> <xsd:element ref="OrganizationRole"/> <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> <xsd:element name="SpecificApplication" type="tSpecificApplication"/> <xsd:complexType name="tSpecificApplication"> <xsd:sequence> <xsd:element ref="ApplicationType"/> <xsd:element ref="ApplicationOperation"/> <xsd:element ref="ExternalReference"/> <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>

Annexe 2

229

<xsd:element name="ApplicationAutomaticallyDiscover" type="tApplicationAutomaticallyDiscover"/> <xsd:complexType name="tAutomaticResource"> <xsd:sequence> <xsd:element ref="ApplicationType"/> <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> <xsd:element name="HumanRole" type="tGenericRole"/> <xsd:element name="OrganizationRole" type="tGenericRole"/> <xsd:complexType name="tGenericRole"> <xsd:sequence> <xsd:element ref="Role" maxOccurs="unbounded"/> </xsd:sequence> </xsd:complexType> <xsd:element name="Role" type="tRole"/> <xsd:complexType name="tRole"> <xsd:sequence> <xsd:element ref="Description" minOccurs="0"/> </xsd:sequence> <xsd:attribute name="Name" type="xsd:NCName" use="optional"/> </xsd:complexType> <xsd:element name="ApplicationType" type="tApplicationType"/> <xsd:complexType name="tApplicationType"> <xsd:sequence> <xsd:element ref="Platform" minOccurs="0"/> <xsd:element ref="DefinitionLanguage" minOccurs="0"/> <xsd:element ref="CommunicationProtocol" minOccurs="0"/> <xsd:element ref="Description" minOccurs="0"/> </xsd:sequence> <xsd:attribute name="Name" type="xsd:NCName" use="optional"/> </xsd:complexType> <xsd:element name="ApplicationOperation" type="xsd:string"/> <xsd:element name="Platform" type="xsd:string"/> <xsd:element name="DefinitionLanguage" type="xsd:string"/> <xsd:element name="CommunicationProtocol" type="xsd:string"/>

 <xsd:element name="Variables" type="tVariables"> <xsd:annotation> <xsd:documentation> This is the 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>

Annexe 2

230

<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> <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> <xsd:element name="BasicType" type="tBasicType"/> <xsd:complexType name="tBasicType"> <xsd:sequence> <xsd:element ref="Length" minOccurs="0"/> </xsd:sequence> <xsd:attribute name="Type" type="tListBasicType" use="required"/> </xsd:complexType> <xsd:simpleType name="tListBasicType"> <xsd:restriction base="xsd:NMTOKEN"> <xsd:enumeration value="STRING"/> <xsd:enumeration value="FLOAT"/> <xsd:enumeration value="INTEGER"/> <xsd:enumeration value="DATETIME"/> <xsd:enumeration value="DATE"/> <xsd:enumeration value="TIME"/> <xsd:enumeration value="BOOLEAN"/> </xsd:restriction> </xsd:simpleType> <xsd:element name="SchemaType" type="tSchemaType"/> <xsd:complexType name="tSchemaType"> <xsd:sequence> <xsd:any namespace="##other" processContents="lax" minOccurs="0" maxOc-curs="unbounded"/> </xsd:sequence> </xsd:complexType> <xsd:element name="RecordType" type="tRecordType"/> <xsd:complexType name="tRecordType"> <xsd:sequence> <xsd:element ref="Member" maxOccurs="unbounded"/> </xsd:sequence> </xsd:complexType>

Annexe 2

231

<xsd:element name="Member" type="tDataTypes"/> <xsd:element name="UnionType" type="tUnionType"/> <xsd:complexType name="tUnionType"> <xsd:sequence> <xsd:element ref="Member" maxOccurs="unbounded"/> </xsd:sequence> </xsd:complexType> <xsd:element name="EnumerationType" type="tEnumerationType"/> <xsd:complexType name="tEnumerationType"> <xsd:sequence> <xsd:element ref="EnumerationValue" maxOccurs="unbounded"/> </xsd:sequence> </xsd:complexType> <xsd:element name="EnumerationValue" type="tEnumerationValue"/> <xsd:complexType name="tEnumerationValue"> <xsd:attribute name="Name" type="xsd:NMTOKEN" use="required"/> </xsd:complexType> <xsd:element name="ArrayType" type="tArrayType"/> <xsd:complexType name="tArrayType"> <xsd:sequence> <xsd:element ref="DataTypes"/> </xsd:sequence> <xsd:attribute name="LowerIndex" type="xsd:NMTOKEN" use="required"/> <xsd:attribute name="UpperIndex" type="xsd:NMTOKEN" use="required"/> </xsd:complexType> <xsd:element name="ListType" type="tListType"/> <xsd:complexType name="tListType"> <xsd:sequence> <xsd:element ref="DataTypes"/> </xsd:sequence> </xsd:complexType> <xsd:element name="TypeDeclarations" type="tTypeDeclarations"/> <xsd:complexType name="tTypeDeclarations"> <xsd:sequence> <xsd:element ref="TypeDeclaration" maxOccurs="unbounded"/> </xsd:sequence> </xsd:complexType> <xsd:element name="TypeDeclaration" type="tTypeDeclaration"/> <xsd:complexType name="tTypeDeclaration"> <xsd:sequence> <xsd:element ref="DataTypes"/> <xsd:element ref="Description" minOccurs="0"/> </xsd:sequence> <xsd:attribute name="Id" type="xsd:ID" use="required"/> <xsd:attribute name="Name" type="xsd:NCName"/> </xsd:complexType>

 <xsd:element name="BusinessActivities" type="tBusinessActivities"> <xsd:annotation> <xsd:documentation> This is the business activities of R2BPRL process. </xsd:documentation>

Annexe 2

232

</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"/> <xsd:attribute name="Name" type="xsd:NCName" use="optional"/> <xsd:attribute name="Priority" type="xsd:anySimpleType"/> </xsd:complexType> <xsd:simpleType name="tExecutionType"> <xsd:restriction base="xsd:NMTOKEN"> <xsd:enumeration value="Manual"/> <xsd:enumeration value="SemiAutomatic"/> <xsd:enumeration value="Automatic"/> </xsd:restriction> </xsd:simpleType> <xsd:simpleType name="tExecutionMode"> <xsd:restriction base="xsd:NMTOKEN"> <xsd:enumeration value="Synchronous"/> <xsd:enumeration value="Asynchronous"/> </xsd:restriction> </xsd:simpleType> <xsd:element name="FormalParameters" type="tFormalParameters"/> <xsd:complexType name="tFormalParameters"> <xsd:sequence> <xsd:element ref="FormalParameter" minOccurs="0" maxOc-curs="unbounded"/> </xsd:sequence> </xsd:complexType> <xsd:element name="FormalParameter" type="tFormalParameter"/> <xsd:complexType name="tFormalParameter"> <xsd:sequence> <xsd:element ref="DataType"/> <xsd:element ref="Description" minOccurs="0"/> </xsd:sequence> <xsd:attribute name="Id" type="xsd:NMTOKEN" use="required"/> <xsd:attribute name="Index" type="xsd:NMTOKEN"/> <xsd:attribute name="Mode" type="tMode" default="IN"/> </xsd:complexType> <xsd:simpleType name="tMode"> <xsd:restriction base="xsd:NMTOKEN"> <xsd:enumeration value="IN"/> <xsd:enumeration value="OUT"/> <xsd:enumeration value="INOUT"/> </xsd:restriction> </xsd:simpleType>

Annexe 2

233



<xsd:element name="Events" type="tEvents"> <xsd:annotation> <xsd:documentation> This is the events for a R2BPRL 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" maxOc-curs="unbounded"/> </xsd:sequence> </xsd:complexType>

 <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> <xsd:element name="EventType" type="tEventType"/> <xsd:complexType name="tEventType"> <xsd:choice> <xsd:element ref="StartActivityEvent"/> <xsd:element ref="EndActivityEvent"/> <xsd:element ref="CancelledActivityEvent"/> <xsd:element ref="ErrorActivityEvent"/> <xsd:element ref="MessageEvent"/> <xsd:element ref="TimeEvent"/> <xsd:element ref="ErrorEvent"/> <xsd:element ref="SignalEvent"/> <xsd:element ref="CancelEvent"/> <xsd:element ref="TriggerEvent"/> <xsd:element ref="GenericEvent"/> </xsd:choice> </xsd:complexType> <xsd:element name="EventGroup" type="tEventGroup"/> <xsd:simpleType name="tEventGroup"> <xsd:restriction base="xsd:NMTOKEN"> <xsd:enumeration value="StartGroup"/> <xsd:enumeration value="IntermediateGroup"/>

Annexe 2

234

<xsd:enumeration value="EndGroup"/> </xsd:restriction> </xsd:simpleType> <xsd:element name="StartActivityEvent" type="tActivityEvent"/> <xsd:element name="EndActivityEvent" type="tActivityEvent"/> <xsd:element name="CancelledActivityEvent" type="tCancelledActivityEvent"/> <xsd:complexType name="tActivityEvent"> <xsd:sequence> <xsd:element ref="ActivityName"/> <xsd:element ref="Description" minOccurs="0"/> </xsd:sequence> </xsd:complexType> <xsd:element name="ErrorActivityEvent" type="tErrorActivityEvent"/> <xsd:complexType name="tErrorActivityEvent"> <xsd:sequence> <xsd:element ref="ActivityName"/> <xsd:element ref="ErrorCode"/> <xsd:element ref="Description" minOccurs="0"/> </xsd:sequence> </xsd:complexType> <xsd:element name="MessageEvent" type="tMessageEvent"/> <xsd:complexType name="tMessageEvent"> <xsd:sequence> <xsd:element ref="Message"/> <xsd:element ref="Target"/> <xsd:element ref="Source"/> <xsd:element ref="Description" minOccurs="0"/> </xsd:sequence> </xsd:complexType> <xsd:element name="TimeEvent" type="tTimeEvent"/> <xsd:complexType name="tTimeEvent"> <xsd:sequence> <xsd:element ref="Time"/> <xsd:element ref="Description" minOccurs="0"/> </xsd:sequence> <xsd:attribute name="Type" type="tListTimeEventType" use="required"/> </xsd:complexType> <xsd:simpleType name="tListTimeEventType"> <xsd:restriction base="xsd:NMTOKEN"> <xsd:enumeration value="Absolute"/> <xsd:enumeration value="Periodic"/> </xsd:restriction> </xsd:simpleType> <xsd:element name="ErrorEvent" type="tErrorEvent"/> <xsd:complexType name="tErrorEvent"> <xsd:sequence> <xsd:element ref="ErrorCode"/> <xsd:element ref="Description" minOccurs="0"/> </xsd:sequence> </xsd:complexType> <xsd:element name="SignalEvent" type="tSignalEvent"/> <xsd:complexType name="tSignalEvent"> <xsd:sequence>

Annexe 2

235

<xsd:element ref="SignalCode"/> <xsd:element ref="Description" minOccurs="0"/> </xsd:sequence> </xsd:complexType> <xsd:element name="CancelEvent" type="tCancelEvent"/> <xsd:complexType name="tCancelEvent"> <xsd:sequence> <xsd:element ref="Description" minOccurs="0"/> </xsd:sequence> </xsd:complexType> <xsd:element name="TiggerEvent" type="tTiggerEvent"/> <xsd:complexType name="tTiggerEvent"> <xsd:sequence> <xsd:element ref="DateName"/> <xsd:element ref="MaxValue" minOccurs="0"/> <xsd:element ref="MinValue" minOccurs="0"/> <xsd:element ref="EgalValue" minOccurs="0"/> <xsd:element ref="Description" minOccurs="0"/> </xsd:sequence> </xsd:complexType> <xsd:element name="GenericEvent" type="tGenericEvent"/> <xsd:complexType name="tGenericEvent"> <xsd:sequence> <xsd:element ref="DataEvent" minOccurs="0"/> <xsd:element ref="Target" minOccurs="0"/> <xsd:element ref="Source" minOccurs="0"/> <xsd:element ref="Description" minOccurs="0"/> </xsd:sequence> </xsd:complexType> <xsd:element name="ErrorCode" type="xsd:string"/> <xsd:element name="Message" type="xsd:string"/> <xsd:element name="Target" type="xsd:NCName"/> <xsd:element name="Source" type="xsd:NCName"/> <xsd:element name="Time" type="xsd:dateTime"/> <xsd:element name="SignalCode" type="xsd:string"/> <xsd:element name="DataEvent" type="xsd:string"/>

 <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="EventGroup"/> <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"/>

Annexe 2

236

<xsd:attribute name="ExpressionLanguage" type="xsd:anyURI"/> </xsd:complexType>

 <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="PostCondition"/> <xsd:element ref="PostEvent"/> </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>  <xsd:element name="OnEvent" type="tEventExpression"/>

 <xsd:element name="PreCondition" type="tConditionExpression"/>

 <xsd:element name="Action" type="tAction"/> <xsd:complexType name="tAction"> <xsd:sequence> <xsd:element ref="Copy" minOccurs="0"/> <xsd:element ref="Increment" minOccurs="0"/> <xsd:element ref="Discover" minOccurs="0"/> <xsd:element ref="Execute" minOccurs="0"/> <xsd:element ref="Cancel" minOccurs="0"/> </xsd:choice> </xsd:sequence>

 <xsd:element name="Copy" type="tCopy"/> <xsd:complexType name="tCopy"> <xsd:sequence> <xsd:element ref="From"/> <xsd:element ref="To"/> </xsd:sequence> </xsd:complexType> <xsd:element name="From" type="tFrom"/>

Annexe 2

237

<xsd:complexType name="tFrom"> <xsd:sequence> <xsd:choice minOccurs="0"> <xsd:element ref="Literal"/> <xsd:element ref="QueryExpression"/> </xsd:choice> <xsd:element ref="Description" minOccurs="0"/> </xsd:sequence> </xsd:complexType> <xsd:element name="To" type="tTo"/> <xsd:complexType name="tTo" mixed="true"> <xsd:sequence> <xsd:element ref="QueryExpression" minOccurs="0"/> <xsd:element ref="Description" minOccurs="0"/> </xsd:sequence> </xsd:complexType>

 <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> <xsd:element name="QoS" type="tQoS"/> <xsd:complexType name="tQoS"> <xsd:sequence> <xsd:element ref="Quality" maxOccurs="unbounded"/> </xsd:sequence> </xsd:complexType> <xsd:element name="Quality" type="tQuality"/> <xsd:complexType name="tQuality"> <xsd:sequence> <xsd:element ref="MaxValue" minOccurs="0"/> <xsd:element ref="MinValue" minOccurs="0"/> <xsd:element ref="EgalValue" minOccurs="0"/> <xsd:element ref="Unit" 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> <xsd:element name="Unit" type="xsd:string"/> <xsd:element name="BusinessRegistryLocation" type="tExternalReference"/> <xsd:element name="ApplicationReferenceFound" type="tExternalReference"/>

Annexe 2

238

<xsd:element name="Execute" type="tExecute"/> <xsd:complexType name="tExecute"> <xsd:sequence> <xsd:element ref=" Operation " minOccurs="0"/> <xsd:element ref="InputVariableName" minOccurs="0" maxOc-curs="unbounded"/> <xsd:element ref="OutputVariableName" minOccurs="0" maxOccurs "un-bounded"/> <xsd:element ref="InputOutputVariableName" minOccurs="0" maxOc-curs="unbounded"/> <xsd:element ref="Performer " minOccurs="0"/> <xsd:element ref="Description" minOccurs="0"/ </xsd:sequence> </xsd:complexType>  <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>  <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>

 <xsd:element name="PostCondition" type="tConditionExpression"/>

 <xsd:element name="PostEvent" type="tEventExpression"/> </xsd:schema>

thèses de l'insa de lyon | les thèses de l'insa de lyon - gestion...

Documents