Kherbouche PDF

Contribution à la gestion de l’évolution des processus
métiers
Mohammed Oussama Kherbouche
To cite this version:

Mohammed Oussama Kherbouche. Contribution à la gestion de l’évolution des processus métiers.
Autre [cs.OH]. Université du Littoral Côte d’Opale, 2013. Français. �NNT : 2013DUNK0343�. �tel-
00968863�
HAL Id: tel-00968863

https://tel.archives-ouvertes.fr/tel-00968863
Submitted on 1 Apr 2014
HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est

archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents
entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non,
lished or not. The documents may come from émanant des établissements d’enseignement et de
teaching and research institutions in France or recherche français ou étrangers, des laboratoires
abroad, or from public or private research centers. publics ou privés.
U i e sit du Litto al Côte d’Opale
THÈSE
P se t e e ue d’o te i le g ade de
DOCTEUR de l’U i e sit du Litto al Côte d’Opale
Spécialité : Informatique
Présentée et soutenue par :

Mohammed Oussama KHERBOUCHE
Le 02 décembre 2013
Contributions à la gestio de l’évolutio des

processus métier
COMPOSITION DU JURY :
M. Henri Basson P ofesseu à l’U i e sit du Litto al Côte d’Opale (Directeur)
Mme. Selmin Nurcan Maître de Conférences à l'Université Paris 1, HDR (Rapportrice)
M. François Charoy P ofesseu à l’U i e sit de Lo ai e (Rapporteur)
M. Mourad Oussalah Professeur à l’U i e sit de Na tes (Examinateur)
M. Mourad Bouneffa Maît e de Co f e es à l’U i e sit du Litto al Côte d’Opale (Co-Encadrent)
M. Christophe Renaud P ofesseu à l’U i e sit du Litto al Côte d’Opale Examinateur (Président)
Th se alis e au sei du La o atoi e d’I fo ati ue Sig al et I age de la Côte d’Opale - EA 4491-
Équipe Model (multi-modélisation et évolution des logiciels)
Maison de la Recherche Blaise Pascal 50, rue Ferdinand Buisson BP 719 62228 Calais Cedex France
« …Le savoir scientifique n'est pas absolu, mais socialement, culturellement, tech-
nologiquement et historiquement marqué, donc provisoire… » Steven Rose
Remerciements
Les travaux présentés dans ce manuscrit ont été effectués au sein du Laboratoire
d’I fo ati ue Sig al et I age de la Côte d’Opale LISIC de l’U i e sit du Litto al Côte
d’Opale ULCO). Je souhaite adresser mes remerciements à toutes les personnes qui ont
contribué de près ou de loin à l’ la o atio de mes travaux de recherche.
Je tiens tout d'abord à exprimer ma gratitude et mes remerciements particuliers à

mon directeur de thèse le Professeur Henri Basson, pour ’a oi encouragé, soutenu et
conseillé durant toutes ces années, ainsi que pour la confiance dont il a fait preuve à mon
égard.
Je remercie aussi chaleureusement mes rapporteurs pour toute l'attention et

l’i t t pa ti ulie u'ils o t apportés à ma thèse : madame Selmin Nurcan, et monsieur
François Charoy. Associer à ces remerciements les membres du jury : monsieur Mourad
Oussalah, monsieur Christophe Renaud et monsieur Mourad Bouneffa, qui m'ont honoré
de leur présence aujou d’hui toute en acceptant d'être examinateurs de mon travail.
Mes remerciements seraient incomplets si je n'y associe pas toutes les personnes
qui ont contribué à ce travail, en particulier, mes collègues, messieurs Adeel Ahmad et
Mourad Bouneffa, le directeur du laboratoire monsieur Christophe Renaud et tout le per-
sonnel du laboratoire.
Au final, j’ai e ais exprimer toute mon attention très affectueuse et ma gratitude
à mes parents, pour leur indéfectible soutien, leur patience et leur conseil avisé dans tous
mes choix professionnels et personnels, durant toute cette période. À mes frères et
sœu s, à toute ma famille ainsi que mes amis.
Calais, le 12 Octobre 2013
Mohammed Oussama Kherbouche

Résumé
La gestio de l’ olutio des p o essus tie e ige u e o p he sio app o-
fondie des causes des changements, de leurs niveaux d’appli atio ai si ue de leu s im-
pacts sur le reste du système. Dans cette thèse, nous proposons une approche de gestion
et de o t ôle de l’ olutio des p o essus tie pe etta t d’a al se es ha ge-
ments et de comprendre leurs impacts. Cela assistera les concepteurs et les chargés de
l’ olutio des p o essus tie à ta li u e aluatio a priori de l’i pa t pou dui e
les is ues et les oûts li s à es ha ge e ts et d’a lio e le se i e et la ualit des
processus métier.
Ce travail consiste à proposer un ensemble de contributions permettant une véri-

fication de la cohérence et de la conformité des modèles de processus métier après
ha ue ha ge e t, ais aussi d’ ta li u e aluatio a priori de l’i pa t st u tu el et
qualitatif des modifications. Les différentes approches proposées sont en cours
d’e p i e tatio et de alidatio à t a e s le d eloppe e t d’u e plate-forme basée
su l’e i o e e t E lipse.
Mots-clés
Processus métier – modèles BPMN – Model-checking – A al se d’i pa ts – relations de dépendance, BPM
Quality.
Abstract
The evolution management of the business processes requires an exhaustive un-
derstanding of the change. An evolution engineer needs to understand reasons of a
change, its application levels, and subsequently its impact on the whole system. In this
thesis, we propose an approach for an a priori change impact analysis, to better control
the business process evolution. This may help the business experts and the process de-
signers to evaluate change impact in order to reduce the associated risks and estimate
the related costs. It may also help to improve the service and quality of the business pro-
cesses.
This work contributes an eventual improvement, in regard, to verify the coherence

and the compliance of the business process models, after each change. It leads to evalu-
ate an a priori change impact analysis in structural and qualitative aspects. The multiple-
perspectives of the proposed approach have been reviewed experimentally. The valida-
tion of the approach is evaluated by extending the Eclipse Development Environment,
with the help of a set of plug-ins, as a prototype plate-form.
Keywords
Business process, BPMN models, Model-checking, Impact Analysis, dependency relationships, BPM Quality.
Table des matières
Résumé .......................................................................................................................................... - 5 -
Abstract .......................................................................................................................................... - 5 -
Introduction ................................................................................................................................. - 13 -
Chapitre 1. Cadre théorique et problématique .......................................................................... - 17 -
1.1 Contexte et terminologie ................................................................................................. - 18 -
1.2 E t ep ise, pilotage et s st e d’i fo atio ................................................................ - 18 -
1.3 Le p o essus da s la gou e a e du s st e d’i fo atio ........................................ - 19 -
1.4 Processus, procédure et procédé..................................................................................... - 22 -
1.5 Processus métier .............................................................................................................. - 22 -
1.6 La gestion des processus métier (BPM) ........................................................................... - 23 -
1.7 C le de ie d’u p o essus tie .................................................................................. - 23 -
1.7.1 Phase de modélisation ............................................................................................. - 24 -
1.7.2 Phase d’i pl e tatio .......................................................................................... - 24 -
1.7.3 Phase d’e utio .................................................................................................... - 25 -
1.7.4 Phase d’a al se et d’opti isatio ........................................................................... - 25 -
1.8 Technologies de processus métier ................................................................................... - 26 -
1.8.1 Processus et workflow ............................................................................................. - 26 -
1.8.1.1 La notion de workflow.......................................................................................... - 26 -
1.8.1.2 Les systèmes de gestion de workflow .................................................................. - 26 -
1.8.2 Services web ............................................................................................................. - 26 -
1.8.3 Le moteur du BPM.................................................................................................... - 27 -
1.9 La modélisation des processus métier ............................................................................. - 27 -
1.9.1 Les langages de modélisation des processus métier ............................................... - 28 -
1.9.1.1 Le standard BPMN ................................................................................................ - 28 -
1.9.1.2 Le diag a e d’a ti it s UML ............................................................................. - 30 -
1.9.1.3 Le paradigme de logique déontique .................................................................... - 31 -
1.9.1.4 Le paradigme de la logique temporelle linéaire (LTL) .......................................... - 31 -
1.9.1.5 Le paradigme de modélisation basée sur les règles............................................. - 32 -
1.9.1.6 Les diagrammes EPC (chaîne de processus événementielle) ............................... - 32 -
1.9.2 Les la gages d’e utio des p o essus tie ...................................................... - 33 -
1.9.2.1 Le langage XPDL.................................................................................................... - 34 -
1.9.2.2 Le langage ebXML................................................................................................. - 34 -
1.9.2.3 Le langage WSFL .................................................................................................. - 34 -
1.9.2.4 Le langage XLANG ................................................................................................. - 35 -
1.9.2.5 BPEL ...................................................................................................................... - 35 -
1.10 La t adu tio des la gages g aphi ues e s les la gages d’e utio ............................ - 37 -
1.11 Les règles métier .............................................................................................................. - 38 -
1.12 Caractéristiques des modèles & langages de processus métier ...................................... - 38 -
1.13 Les di e sio s de la od lisatio d’u p o essus tie .............................................. - 39 -
1.13.1 La dimension fonctionnelle ...................................................................................... - 39 -
1.13.2 La dimension comportementale .............................................................................. - 39 -
1.13.3 La dimension informationnelle ................................................................................ - 40 -
1.13.4 La dimension organisationnelle................................................................................ - 40 -
1.13.5 La dimension opérationnelle .................................................................................... - 40 -
1.14 Réactivité, flexibilité et agilit d’u e e t ep ise .............................................................. - 40 -
1.15 La flexibilité de la modélisation des processus métier..................................................... - 41 -
1.16 Les taxonomies de la flexibilité des processus métier ..................................................... - 41 -
1.17 Gouvernance du changement des processus métier ....................................................... - 44 -
1.18 Nos contributions ............................................................................................................. - 45 -
1.19 Conclusion ........................................................................................................................ - 46 -
Chapitre 2. Vérification et intégration des pro essus étier et État de l’art............................ - 47 -
2.1 Introduction...................................................................................................................... - 48 -
2.2 La cohérence des modèles de processus métier.............................................................. - 48 -
2.2.1 Les incohérences structurelles ................................................................................. - 49 -
2.2.2 Les incohérences fonctionnelles .............................................................................. - 49 -
2.2.3 Les incohérences comportementales ...................................................................... - 50 -
2.2.4 Les incohérences techniques.................................................................................... - 50 -
2.3 Les techniques de vérification des modèles de processus métier ................................... - 50 -
2.3.1 La vérification par modèles formels ......................................................................... - 51 -
2.3.1.1 Les automates ...................................................................................................... - 51 -
2.3.1.2 Les réseaux de Petri.............................................................................................. - 52 -
2.3.1.2.1 Propriété d'absence de blocage "No deadlock" ............................................... - 53 -
2.3.1.2.2 Propriété d'atteignabilité "Reachability".......................................................... - 54 -
2.3.1.2.3 Propriété de sûreté "Safety" ............................................................................. - 54 -
2.3.1.2.4 Propriété d'équité "Fairness" ............................................................................ - 54 -
2.3.1.2.5 Propriété de vivacité "Liveness" ....................................................................... - 54 -
2.3.1.3 L’alg e de p o essus ......................................................................................... - 56 -
2.3.2 La vérification par guide de style ............................................................................. - 58 -
2.3.3 La vérification par conception .................................................................................. - 59 -
2.3.4 La vérification par simulation ................................................................................... - 59 -
2.3.5 La vérification par process-mining ........................................................................... - 59 -
2.4 Les te h i ues d’i t g atio & de gestio des ha ge e ts des p o essus tie ...... - 60 -
2.4.1 Typologie des changements des processus métier .................................................. - 60 -
2.4.2 Typologie des opérations de changement ............................................................... - 62 -
2.4.3 Les propriétés de changement ................................................................................. - 63 -
2.4.3.1 L’a pleu du ha ge e t "Extent of change" .................................................... - 64 -
2.4.3.2 La durée du changement "Duration of change" .................................................. - 64 -
2.4.3.3 La rapidité du changement "Swiftness of change" .............................................. - 64 -
2.4.3.4 L’a ti ipatio du ha ge e t "Anticipation of change" ..................................... - 64 -
2.4.4 Techniques d'évolution ............................................................................................ - 64 -
2.4.4.1 L’app o he ad-hoc ................................................................................................ - 64 -
2.4.4.2 L’app o he pa d i atio .................................................................................... - 65 -
2.4.4.3 L’app o he pa h itage ....................................................................................... - 65 -
2.4.4.4 L’app o he pa i du tio ..................................................................................... - 65 -
2.4.4.5 L’app o he pa fle io ...................................................................................... - 66 -
2.4.4.6 L’app o he à ase de gles ................................................................................. - 66 -
2.4.5 Techniques de migration .......................................................................................... - 67 -
2.4.5.1 L’app o he pa a ulatio ................................................................................... - 67 -
2.4.5.2 L’approche sans propagation ............................................................................... - 67 -
2.4.5.3 L’app o he a e p opagatio ............................................................................... - 67 -
2.4.6 Techniques de flexibilité........................................................................................... - 68 -
2.4.6.1 L’app o he pa s le tio ta di e "Late binding".................................................. - 68 -
2.4.6.2 L’app o he pa od lisatio ta di e "Late modeling" ........................................ - 68 -
2.5 Conclusion ........................................................................................................................ - 69 -
Chapitre 3. La Vérification des modèles de processus métier par le Model Checking ............. - 71 -
3.1 Introduction ..................................................................................................................... - 72 -
3.2 Le model-checking............................................................................................................ - 74 -
3.2.1 Principe du model-checking ..................................................................................... - 74 -
3.2.2 Système de transitions ............................................................................................. - 75 -
3.2.2.1 Structure de kripke ............................................................................................... - 76 -
3.2.3 Les propriétés vérifiées par le model checking ........................................................ - 77 -
3.2.3.1 P op i t d’atteig a ilit " Reachability" ............................................................ - 77 -
3.2.3.2 Propriété de sûreté "Safety" ................................................................................ - 77 -
3.2.3.3 P op i t d’ uit "Fairness" ............................................................................... - 78 -
3.2.3.4 Propriété de vivacité "Liveness" ........................................................................... - 78 -
3.2.3.5 P op i t d’a se e de lo age "Deadlock-freeness" ......................................... - 78 -
3.2.4 La logique Temporelles Linéaire (LTL) ...................................................................... - 78 -
3.3 SPIN Model Checker ......................................................................................................... - 80 -
3.4 Les erreurs structurelles ................................................................................................... - 81 -
3.4.1 L’i passe "Deadlock patterns" ................................................................................ - 81 -
3.4.2 Boucles infinies "Livelocks patterns" ........................................................................ - 82 -
3.4.3 Terminaison multiples "Multiples terminations patterns" ....................................... - 83 -
3.5 La vérification des modèles de processus métier basée sur le model-checking.............. - 83 -
3.5.1 G atio de l’auto ate à tats fi is..................................................................... - 83 -
3.5.2 Formules LTL de la cohérence d'un modèle de processus métier ........................... - 85 -
3.5.2.1 D te tio de l’a se e de lo ages ..................................................................... - 85 -
3.5.2.2 Détection des boucles infinies.............................................................................. - 86 -
3.5.2.3 Détection des terminaisons multiples .................................................................. - 86 -
3.5.3 Model Checking ........................................................................................................ - 86 -
3.5.4 Déterminer la zone impactée ................................................................................... - 86 -
3.6 La vérification des modèles de processus métier à l'aide de SPIN................................... - 87 -
3.6.1 Processus de vente de voitures ................................................................................ - 89 -
3.7 La vérification des règles de conformité .......................................................................... - 91 -
3.7.1 Représentation déclarative des règles de conformité ............................................. - 93 -
3.7.2 Processus de remboursement des frais de fonctionnement ................................... - 94 -
3.8 Conclusion ........................................................................................................................ - 97 -
Chapitre 4. Analyse a priori de l’I pa t du changement des modèles de processus métier . - 100 -
4.1 Introduction.................................................................................................................... - 101 -
4.2 Gestion du changement des processus métier .............................................................. - 102 -
4.3 A al se de l’i pa t du ha ge e t da s la litt atu e ................................................ - 103 -
4.4 P i ipe de l’a al se de l’i pa t du ha ge e t.......................................................... - 103 -
4.5 A al se de l’i pa t du ha ge e t des p o essus tie ........................................... - 104 -
4.6 Analyse des relations de dépendance ........................................................................... - 106 -
4.6.1 Taxonomie de la dépendance dans les modèles de processus métier .................. - 107 -
4.6.2 Modèle de dépendance pour l'étude d'impact...................................................... - 108 -
4.6.2.1 Relations de dépendance intra-couches ............................................................ - 108 -
4.6.2.1.1 D pe da es d a tivit s outage ................................................................. - 108 -
4.6.2.1.2 Dépendances de données ............................................................................... - 109 -
4.6.2.1.3 Dépendances de rôles..................................................................................... - 110 -
4.6.2.2 Relations de dépendance inter-couches ............................................................ - 110 -
4.7 P opagatio de l’i pa t du ha ge e t ....................................................................... - 111 -
4.7.1 La métrique P ......................................................................................................... - 112 -
4.7.2 La métrique E ......................................................................................................... - 112 -
4.7.3 La métrique F.......................................................................................................... - 112 -
4.7.4 La métrique ND ...................................................................................................... - 112 -
4.8 Mod lisatio de la p opagatio de l’i pa t du ha ge e t ........................................ - 113 -
4.8.1 La base de connaissances ....................................................................................... - 113 -
4.8.2 Le système à base de règles ................................................................................... - 117 -
4.8.2.1 Définition 1 (processus métier) .......................................................................... - 117 -
4.8.2.2 D fi itio i sta e d’u p o essus tie ................................................... - 118 -
4.8.2.3 Définition 3 (activité).......................................................................................... - 118 -
4.8.3 Définition des règles de "faisabilité du changement" ............................................ - 118 -
4.8.3.1 I se tio d’u f ag e t de p o essus au i eau du s h a ............................ - 119 -
4.8.3.2 Supp essio d’u f ag e t de p o essus au i eau du s h a ....................... - 119 -
4.8.3.3 I se tio et supp essio d’u f ag e t de p o essus au i eau de l’i sta e . - 120 -
4.8.4 D fi itio des gles de p opagatio de l’i pa t du ha ge e t ........................ - 122 -
4.8.4.1 R gle d’a al se des d pe da es intra-couche (analyse des dépendances
d’a ti it s .......................................................................................................................... - 122 -
4.8.4.2 R gle d’a al se des d pe da es i t a-couche (analyse des dépendances de
données) - 123 -
4.8.4.3 R gle d’a al se des d pe da es i te -couche ................................................ - 124 -
4.9 Conclusion ...................................................................................................................... - 124 -
Chapitre 5. La gestion qualitative des processus métier.......................................................... - 126 -
5.1 Introduction ................................................................................................................... - 127 -
5.2 Gestion qualitative des processus métier ...................................................................... - 128 -
5.3 Évaluation de la qualité des modèles de processus métier ........................................... - 128 -
5.3.1 Tou d’ho izo des app o hes e ista tes .............................................................. - 129 -
5.3.1.1 Mesu e la o ple it d’u od le de p o essus tie ................................. - 130 -
5.3.1.2 Mesu e le ouplage d’u od le de p o essus tie .................................... - 131 -
5.3.1.3 Mesu e la oh sio d’u od le de p o essus tie .................................... - 132 -
5.3.1.4 Mesu e la odula it d’u od le de processus métier................................. - 132 -
5.3.1.5 Mesu e la taille d’u od le de p o essus tie ........................................... - 132 -
5.4 L’app o he p opos e ...................................................................................................... - 133 -
5.4.1 Efficacité "Efficiency" .............................................................................................. - 135 -
5.4.1.1 L’effi a it du te ps de alisatio "Time Behaviour" ...................................... - 135 -
5.4.1.2 L’effi a it des essou es e plo es "Resource efficiency" ............................ - 136 -
5.4.1.3 L’effi a it des oûts "Cost efficiency" ............................................................... - 136 -
5.4.2 Fiabilité "Reliability" ............................................................................................... - 136 -
5.4.2.1 La maturité "Maturity" ....................................................................................... - 136 -
5.4.2.2 La tolérance aux pannes "Fault Tolerance" ........................................................ - 136 -
5.4.2.3 La capacité de récupération "Recoverability" .................................................... - 136 -
5.4.3 Performance "Performance" .................................................................................. - 136 -
5.4.3.1 Le débit de traitement "Throughput rates" ....................................................... - 136 -
5.4.3.2 Le te ps d’e utio "Execution time" ............................................................. - 137 -
5.4.3.3 Le temps de réponse "Timeliness" ..................................................................... - 137 -
5.4.3.4 Le oût d’e utio "Execution cost" ................................................................. - 137 -
5.4.4 Ressource "Resource"............................................................................................. - 137 -
5.4.4.1 Interopérabilité "Interoperability" ..................................................................... - 137 -
5.4.4.2 Sécurité "Security" .............................................................................................. - 137 -
5.4.4.3 Déploiement "Deployment" .............................................................................. - 137 -
5.4.5 Acteur "Actor" ........................................................................................................ - 137 -
5.4.5.1 Disponibilité "Availability".................................................................................. - 138 -
5.4.5.2 Aptitude "Suitability".......................................................................................... - 138 -
5.4.6 Mesurer la qualité des processus métier ............................................................... - 138 -
5.4.6.1 Mesu e l’i te op a ilit .................................................................................. - 139 -
5.4.6.2 Mesurer la maturité ........................................................................................... - 139 -
5.4.6.3 Mesurer la tolérance aux pannes ....................................................................... - 140 -
5.4.6.4 Mesurer le temps de réponse ............................................................................ - 140 -
5.4.7 Analyse et interprétation des mesures obtenues .................................................. - 140 -
5.5 A al se de l’i pa t ualitatif du ha ge e t des p o essus tie ........................... - 141 -
5.5.1 Dépendances entre les critères de qualité ............................................................. - 142 -
5.6 Conclusion ...................................................................................................................... - 144 -
Chapitre 6. Prototype de validation .......................................................................................... - 145 -
6.1 Introduction ................................................................................................................... - 146 -
6.2 Architecture Globale du prototype de validation .......................................................... - 147 -
6.2.1 Le plug-in BPMN2 Modeler .................................................................................... - 149 -
6.2.2 Le plug-in BPMNVT ................................................................................................. - 149 -
6.2.2.1 BPMN2PROMELA ............................................................................................... - 150 -
6.2.2.2 CR2LTL ................................................................................................................ - 152 -
6.2.3 Le plug-in BPMNQ .................................................................................................. - 152 -
6.2.4 Le plug-in BPMN-CPA ............................................................................................. - 155 -
6.2.4.1 Implémentation du système à base de règles ................................................... - 155 -
6.3 Expérimentation ............................................................................................................. - 156 -
6.3.1 Schéma initial S du processus ................................................................................ - 156 -
6.3.2 S h a sulta t S’ du p o essus .......................................................................... - 156 -
6.3.3 Vérification de la cohérence et de la conformité du processus............................. - 157 -
6.3.4 Évaluation de la qualité du processus métier ........................................................ - 157 -
6.4 Conclusion ...................................................................................................................... - 160 -
Chapitre 7. Conclusion et perspectives ..................................................................................... - 161 -
7.1 Résumé des contributions.............................................................................................. - 162 -
7.1.1 Bilan des contributions........................................................................................... - 162 -
7.1.1.1 Contribution à la vérification formelle des processus métier ............................ - 162 -
7.1.1.2 Co t i utio à l’a al se a p io i de l’i pa t du ha ge e t des p o essus tie .. -
163 -
7.1.1.3 Contribution à la gestion qualitative des processus métier............................... - 164 -
7.1.2 Perspectives des travaux ........................................................................................ - 164 -
Bibliographie .............................................................................................................................. - 167 -
Table des figures
Figu e . La o positio d u s st e d e t ep ise ..................................................................................- 19 -
Figure 1.2 Système d'information et système informatique ........................................................................- 20 -
Figure 1.3 Typologie des processus ..............................................................................................................- 21 -
Figure 1.4 Méta modèle du processus métier selon (Morley, Hughes, Leblanc, & Hugues, 2007) ...............- 23 -
Figure 1.5 Cycle de vie du BPM ....................................................................................................................- 24 -
Figure 1.6 Pile de protocoles de services web .............................................................................................- 27 -
Figure 1.7 Modélisation impérative et modélisation déclarative .................................................................- 28 -
Figu e . Él e ts de ase d u BPMN .....................................................................................................- 29 -
Figure 1.9 Processus de vente aux enchères modélisé par la notation BPMN .............................................- 30 -
Figure 1.10 Représentation graphique des p i ipau o epts da s u diag a e d a tivit s. ..............- 31 -
Figu e . P o essus de o a de od lis pa le diag a e d a tivités .............................................- 31 -
Figure 1.12 Un exemple simple d'un modèle CONDEC. ................................................................................- 32 -
Figu e . Él e ts de ase d u diag a e EPC. ...................................................................................- 33 -
Figure 1.14 Processus de traitement des commandes modélisé en EPC. .....................................................- 33 -
Figure 1.15 Chronographe des diff e ts la gages d e utio des p o essus tie ................................- 34 -
Figure 1.16 Transformation de BPMN à BPEL ..............................................................................................- 37 -
Figure 1. 17 Les notions de changement selon la classification de Regev et al. ...........................................- 42 -
Figure 1.18 Les notions de changement selon la classification de Nurcan ..................................................- 44 -
Figure 2.1 Les éléments constituant un automate .......................................................................................- 51 -
Figure 2.2 Les éléments constituants un réseau de Petri .............................................................................- 53 -
Figu e . La v ifi atio d u p o essus tie pa les ‘dP .......................................................................- 55 -
Figure 2.4 Niveaux de changement de processus .......................................................................................- 61 -
Figure 3.1 Principe du model-checking. .......................................................................................................- 75 -
Figure 3.2 Un exemple de structure de kripke. .............................................................................................- 77 -
Figure 3.3 Les connecteurs temporels LTL. ...................................................................................................- 79 -
Figure 3.4 Les erreurs structurelles dans les modèles BPMN. ......................................................................- 82 -
Figure 3.5 Vérification des modèles de processus métier basée sur le model-checking. .............................- 83 -
Figure 3.6 Processus de vente de voitures. ...................................................................................................- 89 -
Figure 3.7 Vérification de la cohérence du processus de vente de voitures en jSpin ....................................- 92 -
Figure 3.8 La structure de kripke générée par jSpin .....................................................................................- 92 -
Figure 3.9 Processus de remboursement des frais de fonctionnement ........................................................- 94 -
Figure 3.10 La représentation graphique de la règle «R1» ..........................................................................- 96 -
Figure 3.13 Résultats de la vérification de conformités du processus en jSpin ...........................................- 97 -
Figure 4.1 Analyse de l'impact du changement des processus métier .......................................................- 105 -
Figure 4.2 Dépendances multicouches dans les processus métier .............................................................- 106 -
Figure 4.3 Hiérarchie des classes de BPMN 2 Ontology .............................................................................- 114 -
Figure 4.4 Hiérarchie des classes de extended BPMN 2 Ontology .............................................................- 116 -
Figure 4.5 Le fichier ExtendedOntoBPMN.owl ...........................................................................................- 116 -
Figu e . L ajout de l a tivit «X» et la supp essio de l'a tivit «B» .......................................................- 121 -
Figure 5.1 Représentation arborescente des facteurs, critères et métriques. ............................................- 135 -
Figure 5.2 Relations entre l'impact structurel, comportemental et qualitatif du changement. .................- 142 -
Figu e . Les d pe da es ho izo tales da s l valuatio de la ualit des p o essus tie . ..............- 143 -
Figure 6.1 Le plug-in BPMN2 Modeler. ......................................................................................................- 147 -
Figu e . L a hite tu e g ale de la plate-forme BPMN-CM. .............................................................- 148 -
Figu e . E t ait du fi hie d e t e « Des iptio logi ue ». .................................................................. - 149 -
Figu e . E t ait du fi hie d e t e « Des iptio g aphi ue». ............................................................... - 149 -
Figu e . L a hite tu e du plug-in BPMNVT. .......................................................................................... - 150 -
Figure 6.6 Exemple de l'arbre syntaxique. ................................................................................................. - 151 -
Figure 6.7 Fichier de configuration de BPMNVT. ....................................................................................... - 151 -
Figure 6.8 Le module CR2LTL. .................................................................................................................... - 152 -
Figure 6.9 Architecture du plug-in BPMNQ. .............................................................................................. - 152 -
Figure 6.10 Ajout de métriques Ad-hoc dans le plug-in BPMNQ. .............................................................. - 153 -
Figu e . Évaluatio des t i ues d u od le BPMN pa plug-in BPMNQ. ...................................... - 154 -
Figu e . G aphe d valuatio de la t i ue N. .................................................................................. - 154 -
Figure 6.13 Processus de remboursement des frais de fonctionnement. .................................................. - 156 -
Figure 6.14 Modèle Promela généré par BPMN2PROMELA. ..................................................................... - 158 -
Figure 6.15 Vérification de la cohérence du processus de remboursement des frais par EpiSpin. ............ - 158 -
Figure 6.16 Génération du fichier Expense_reimbursement_process.dot. ................................................ - 159 -
Figure 6.17 Visualisation du fichier Expense_reimbursement_process.dot avec Graphiz. ........................ - 159 -
Liste des tableaux
Table 2.1 Opérations basiques de changement. ..........................................................................................- 62 -
Table 2.2 Opérations complexes de changement. .......................................................................................- 63 -
Table 3.1 La cartographie des éléments de BPMN en structure de kripke. ..................................................- 85 -
Table 3.2 La cartographie des éléments de BPMN en Promela model. .......................................................- 89 -
Table 3.3 La notation graphique G-LTL. .......................................................................................................- 94 -
Table 5.1 Les similitudes entre les produits logiciels et les processus métier. ............................................- 130 -
Listing
Listi g . T adu tio de l a tivit Ve deu de voitu e e p o essus P o ela. .......................................... - 90 -
Listi g . T adu tio de l a tivit O te i u o us e p o essus P o ela. ............................................. - 90 -
Listi g . T adu tio de l a tivit O te i le ulleti de paie e p o essus P o ela. ................................ - 90 -
Listi g . T adu tio de l a tivit ulleti de paie e p o essus P o ela. ................................................ - 91 -
Listing 3.5 Le fichier Car_Salesman_process.pml ........................................................................................ - 91 -
Listing 3.6 Le fichier Expense_Reimbursement_Process.pml ....................................................................... - 95 -
Listing 4.1 Classe BPMN_element. ............................................................................................................ - 114 -
Listing 4.2 Classe IMPACT_ANALYSIS......................................................................................................... - 115 -
Listing 4.3 Classe DEPENDENCY_RELATIONSHIPS. .................................................................................... - 115 -
Listing 4.4 Classe ACTIVITY_DEPENDENCY. ............................................................................................... - 115 -
Listing 4.5 Classe DATA_DEPENDENCY. ..................................................................................................... - 115 -
Listi g . I se tio d u f ag e t de p o essus au iveau du schéma. .................................................. - 119 -
Listi g . Supp essio d u f ag e t de p o essus au iveau du s h a. ............................................. - 120 -
Listi g . I se tio d u f ag e t de p o essus au iveau des i sta es ............................................... - 120 -
Listing 4. Supp essio d u f ag e t de p o essus au iveau des i sta es. ......................................... - 121 -
Listi g . ‘ gle d a al se de l i pa t i t a- ou he a al se des d pe da es d a tivit s . ................ - 122 -
Listi g . ‘ gle d a al se de l i pa t i t a-couche (analyse des dépendances de données). .............. - 123 -
Listi g . ‘ gle d a al se de l i pa t i te -couche. .............................................................................. - 124 -
Listing 6. 1 La règle de p opagatio d i pa t du ha ge e t ................................................................. - 155 -
Introduction
Le o ept de p o essus tie o upe aujou d’hui une place majeure dans le do-
ai e des s st es d’i fo atio . Toutefois, es p o essus tie doi e t t e e o s-
tante évolution afin de permettre aux entreprises de répondre aux exigences du marché
et aux inflexions des besoins de leurs différents interlocuteurs, et par conséquent, de
construire ou préserver leur avantage concurrentiel.
À cet égard, une compréhension des connaissances descriptives des processus mé-
tier est une condition sine qu a none de la ussite d’u e telle olutio . La ise e
œu e de cette évolution revient donc à réaliser des changements plus ou moins impor-
tants de certains constituants du processus métier. Ces changements qui sont dus généra-
lement à une correction d'une ou plusieurs erreurs, à une exception dans le processus
métie , à la ise e o fo it a e des ou elles o es ou lois ju idi ues, à l’ olutio
du tie et des se i es de l’e t ep ise i o atio , à l'a lio atio des pe fo a es
et l’opti isatio des p o essus existants (re-engineering) peuvent engendrer des erreurs
(blocages, des exécutions infinies, des multiples terminaisons etc.), une non-conformité
avec la réglementation, une dégradation du service (temps de réponse, sécurité, taille des
messages, etc.), ou une mauvaise ualit de l’appli atio tout entière. Cela conduit à la
nécessité de mettre en place un mécanisme de gestion et de contrôle permettant de réa-
liser à la fois une vérification de la cohérence et de la conformité des modèles de proces-
sus métier modifié et à une analyse a priori de l’i pa t du changement de ces derniers et
une analyse a posteriori de l’i pa t effe tif de e ha ge e t.
Da s le ad e du o t ôle et de la gestio de l’ olutio des p o essus tie , ette
th se p opose u e app o he pe etta t e t e aut es, d’assiste les odeleurs et les ex-
perts métier à établir une vérification formelle des processus métier modélisé en BPMN
après chaque changement, et une évaluation a priori de l’i pa t st u tu el et ualitatif de
ces changements.
L’app o he est alid e e alisa t u e plate-forme spécifique permettant la ges-
tio de l’ olutio des p o essus tie . Cette plate-forme permet à la fois une vérifica-
tion de la cohérence et de la conformité des modèles de processus métier par la tech-
- 13 -
nique du model-checking, une analyse a priori de l’i pa t du ha ge e t de es de ie s
et une gestion qualitative de ces modèles. Le reste de la thèse est organisé comme suit :
 En préambule, le chapitre 1 présente brièvement chacune des définitions et no-

tions employées dans la discipline BPM "Business Process Management", et décrit
en détail la problématique du domaine de recherche de la thèse qui a trait aux
p i ipes de gou e a e et l’ tude de l’i pa t du changement des processus
métier.
 Le chapitre 2 soulig e tout d’a o d l’i po ta e de la oh e e des od les de
p o essus tie da s l’effi a it et la ualit de es de ie s, e pa ti ulie ap s
chaque changement, ce chapitre comporte un tat de l’a t ui elate les a an-
tages et les inconvénients de chacune des approches proposées dans la littérature
pou g e les diff e ts aspe ts de l’ olutio des p o essus tie .
 Le chapitre 3 détaille notre contribution dans le domaine de la vérification for-
melle des modèles de processus métier modélisés en BPMN qui est basée sur la
technique du model-checking. Il aborde en particulier les détails de la vérification
de la cohérence et la conformité de ces modèles.
 Le hapit e d it la ise e œu e de notre contribution pe etta t l’a al se a
priori de l’i pa t du ha ge e t. Il présente en particulier les différentes rela-
tions de dépendance impliquées dans le processus de p opagatio de l’i pa t du
changement et de son analyse. Le chapitre aborde gale e t la fo ulatio d’u e
base de connaissances qui permet une compréhension, à la fois du processus mé-
tie et de so olutio et u e se le de gles de faisa ilit et d’a al se
d’i pa t du ha ge e t, et dis ute l’appli atio de es de ie s.
 Le hapit e est o sa à la p opositio d’u od le ualitatif pe etta t
d’ aluer la qualité des modèles de processus métier inspiré par la norme ISO /
CEI 9126- . Le hapit e a o de les uestio s li es à l’assu a e ualit des p o es-
sus métier suivis d’u tou d’ho izo des app o hes p opos es da s la litt atu e
pour assurer la qualité des processus métier. La dernière partie du chapitre est
consacrée à l’a al se ualitati e de l’i pa t du ha ge e t des p o essus tie .
- 14 -
 Le hapit e alide la ise e œu e et les sultats de l’app o he de la od lisa-
tion proposée. Il décrit le d eloppe e t d’u e plate-forme de prototype pour la
gestio de l’ olutio des p o essus tie .
 La conclusion générale de la contribution de cette thèse et les perspectives des
travaux de recherche sont données au chapitre 7 de ce manuscrit.
- 15 -
- 16 -
CHAPITRE
1
Cadre théorique et problématique
1. Cadre théorique et problématique
1.1 Contexte et terminologie

Afin de demeurer compétitives et être en mesure de répondre aux différents besoins
évolutifs du a h , et d’i te agi de a i e opti ale a e l’e se le des a teu s ui
les o stitue t, les o ga isatio s ode es se doi e t d’ t e agiles. Cela veut dire que les
p o essus is e œu e da s les diff e ts s st es o stitua t u e o ga isatio doi-
vent s'adapter rapidement à l'échelle des valeurs de cette dernière. Cela constitue con-
cerne aussi bien les niveaux intra et inter-organisationnels. Autrement dit, cela concerne
aussi bien la structuration interne de l'organisation que son interaction avec son environ-
nement extérieur. L'adaptation à l'échelle de valeur est, en effet, une condition néces-
saire à la disposition d'un système d'information (SI) efficace et efficient supportant à la
fois les stratégies métiers et les processus qui y sont rattachés.
En effet, la otio de p o essus joue u ôle p i o dial da s la aît ise de l’ olutio
des s st es d’i fo atio et des s st es i fo ati ues asso i s. Ils sont souvent con-
sidérés comme un p ala le i dispe sa le à la o eptio de la d a i ue d’u s st e
d’i fo atio d’u e o ga isatio (Alter, 1999), (Butler, Esposito, & Hebron, 1999) et cela
en fournissant des processus robustes, et adapté à leurs activités. Leur maîtrise constitue
alors un enjeu important, pour tous les acteurs d’u e o ga isatio tels que les experts
métiers, les équipes fonctionnelles et les équipes techniques en termes de réactivité des
systèmes, et de compétitivité sur les marchés.
La d fi itio et l’e utio de es p o essus essite t u odèle et des outils per-
mettant leur définition, déploiement, exécution, analyse et leur contrôle. Dans ce con-
texte, la gestion des processus métier appelée aussi BPM "Business Process Manage-
ment" est une approche globale permettant de gérer de bout en bout les processus mé-
tier de l'entreprise en associant l'analyse, la supe isio et l’a lio atio de es processus
dans une optique de forte intégration avec le s st e d’i formation.
Dans ce chapitre, nous introduisons tout d’a o d la terminologie utilisée dans la disci-
pline dite BPM suivie de la problématique de notre thèse qui a trait aux principes de gou-
vernance et d’ tude de l’i pa t du ha ge e t des processus métier, ainsi que les solu-
tions apportées.
1.2 Entreprise, pilotage et système d’information

Une entreprise est un système socio-économique visant à créer de la valeur ajoutée1
pour ses partenaires et ses interlocuteurs internes et externes et dans laquelle
l’information est considérée comme une ressource vitale pour son fonctionnement. Cette
aleu ajout e est attei te g â e à l’o hest atio d’a ti it s di e ses alis es à l’aide
d’a teu s et des essou es de l’e t ep ise.
Dans ce contexte, il nous semble intéressant de rappeler l’ olutio de la pe eptio
des s st es d’i fo atio au sei des o ga isatio s. E th o ie systémique, Le Moigne
(Le Moigne, 1984) o sid e les fo tio alit s d’u e entreprise ou d’u e organisation
1
La valeur ajoutée est un indicateur économique qui mesure la valeur ou la richesse créée par une entreprise
- 18 -
comme étant assurées par trois systèmes : le système opérant (SO), le système de pilo-
tage (SP) et le système d'information (SI) comme le montre la figure 1.1.
Figure 1.1 La o positio d u s st e d e t ep ise
Le système opérant (SO) réagit aux flux des événements quotidiens, qui viennent de
l’e i o e e t d’u e e t ep ise, selo des gles ie d fi ies. Il ep se te des lé-
ments matériels ou immatériels en interaction transformant par un processus des flux
d’e t ées tels que les flux financier, les flux de matière, les flux d’i fo atio e flu de
sortie, et do e ai si des i fo atio s su l’ tat du s st e au SP ia le SI.
Le système de pilotage (SP) pe et d’e gage le p o essus de d isio tout e d fi is-
sa t au p ala le les o je tifs, les it es d’ aluatio et les gles de gestio .
Enfin, le S st e d’I fo atio SI joue un rôle primordial permettant de relier les
deux systèmes précédents en transmettant les directives décidées par le SP au SO. Le SI
renvoie les informations issues du SO permettant ainsi au SP de prendre les bonnes déci-
sions pour un fonctionnement optimal du système global.
1.3 Le processus dans la gouvernance du système d’information

Le S st e d’I fo ation est au œu des e jeu tie s et st at gi ues de toute or-
ganisation (Morley, Bia-Figueiredo, & Gillette, 2011). Son efficacité constitue un élément
clé de la performance de cette dernière. Il est généralement considéré comme l’ensemble
identifiable de processus, de ressources et d’acteurs, ayant pour rôle de traiter, gérer et
diffuser de l'information au sei d’u e organisation ainsi que d’i te agi a e le milieu
extérieur.
Cependant, la notion de s st e d’i fo atio ’a ess d’ olue au fil du te ps.
Certains acteurs invoquent un «s st e de t aite e t de l i fo atio », d’aut e de « sys-
t e d i fo atio pou le a age e t», ou encore de «s st e d i fo atio o ga i-
sationnel». Cependant ces définitions qui servaient de référence pendant une certaine
- 19 -
période ont évoluée e fo tio de la diffusio oissa te de l’i fo ati ue da s les a ti-
it s d’u e o ga isatio .
Ainsi, des auteurs comme (Alter, 1999) d fi isse t u s st e d’i fo atio o e
«u s st e de t avail do t les fo tio s i te es so t li it es à t aite l i fo atio , e
e uta t si t pes d op atio s : saisi , transmettre, stocker, retrouver, manipuler, affi-
he l i fo atio . U s st e d i fo atio p oduit de l i fo atio , assiste ou auto a-
tise le t avail e ut pa d aut es s st es de travail.». Cette définition, est plutôt réduc-
trice du fait qu’elle su e le système d’i fo atio comme étant quasiment un système
informatique.
Les d fi itio s o t p og essi e e t s’ la gi pou t adui e le fait u’u s st e
d’i fo atio a d pass le stade d’outil pou de e i l’ l e t st u tu a t d’u e o ga i-
sation. Ainsi, (Reix, 2004) d fi it u s st e d’i fo atio o e « un ensemble organi-
s de essou es at iel, logi iel, pe so el, do es, p o du es pe etta t d a u i ,
traiter, stocker, communiquer des informations (sous forme de données, textes, images,
sons, etc.) dans les organisations ». Dans cette définition, on voit apparaître une notion
essentielle qui est «la procédure». Celle-ci décrit comment, quand et où l’a teu est sup-
posé utiliser des ressources : matériels, logiciels et do es pou ue l’o ga isatio soit
informée. Cette définition été amplifiée par Morley et al. (Morley, Hughes, Leblanc, &
Hugues, 2007), qui ont clairement fait la distinction entre le s st e d’i fo atio et le
système informatique comme le montre la figure 1.2. En considérant le système
d’i fo atio sous la gouvernance du système de pilotage, supportant la gestion de
l’e t ep ise est suppo t pa les essou es i fo ati ues d’aide à la d isio .
S st e d’I for atio Permet
Acteurs Informations Système Informatique
Matériels Logiciels
Processus
Applicatifs
S’appuie sur
Figure 1.2 Système d'information et système informatique
La diffusio de l’app o he p o essus a o duit récemment à intégrer cette notion dans

la d fi itio d’u s st e d’i fo atio . Ainsi (Alter, 1999) fut parmi les premiers au-
teurs à ett e l’a e t su les lie s existant entre processus et SI. Il est parti de la notion
de « processus métier » abordée en détail plus loin, comme étant un ensemble coordon-
d’a ti it s isa t à p odui e u sultat pou des lie ts i te es ou externes. S. Alter
appelle « s st e de t a ail », l’e se le des processus, des acteurs, et des ressources
dont la finalité est de produire un résultat escompté. Dans certains cas, les activités des
- 20 -
p o essus so t u i ue e t du t aite e t de l’i fo atio : saisie, stockage, transmis-

sion, manipulation. Le système de travail est alo s appel s st e d’i fo atio .
De nos jours, la notion de processus joue un rôle majeur dans la définition et la gestion
des s st es d’i fo atio e si ses utilisatio s so t diverses. La plupart des mé-
thodes d’a al se actuelles proposent des concepts pour modéliser un système
d’i fo atio autou du processus et ses interactions, et non simplement autour
d’appli atio s informatiques.
La notion de processus est donc considérée comme étant u e se le d’a ti it s,
exécutées dans un objectif bien déterminé par un acteur correspond à un rôle. Le dérou-
lement du processus utilise des ressources et peut être conditionné par des évènements
d’o igi e i te e ou e te e. L’age e e t des a ti it s o espo d à la st u tu e du
processus.
La typologie de processus la plus communément reconnue distingue trois catégories
selon (Debauche & Mégard, 2004):
 Les processus de pilotage ou de management qui o t pou ut d’o ga ise les ob-
je tifs st at gi ues de l’e t ep ise.
 Les processus métier (ou processus opérationnel, processus de réalisation) qui ont
pou fo tio d’a o pli u e issio da s u do ai e do et utilisent plu-
sieu s fo tio s de l’e t ep ise.
 Les processus de support ou de soutien sont périphériques au métier de
l’e t ep ise et e pa ti ipe t u’i di e te e t à l’a o plisse e t d’u o je tif
métier.
Selon (SPINOV, 2006), une quatrième catégorie de processus vient se greffer autour de
ces catégories, appelée processus de mesure, ces processus permettent de fournir les
métriques nécessaires à l’ aluatio des p o essus et à leu a lio atio o ti ue. Cette
typologie est représentée figure 1.3.
Processus de pilotage
Processus de mesure
Satisfaction
Exigences
Éléments de
Clients
Clients
Éléments sortie
d’e trée
Processus opérationnel
Processus de support
Figure 1.3 Typologie des processus
- 21 -
1.4 Processus, procédure et procédé

Processus, procédure ou procédé sont trois termes qui peuvent prêter à confusion
dans le langage courant, ils sont dévirer du mot latin « procedere », qui signifie « Aller en
avant ». La procédure a des définitions diverses selon la discipline. Dans le domaine juri-
dique par exemple, cela désigne « les formes et les règles selon lesquelles on doit se
comporter en justice ». Da s le o de de l’e t ep ise, e ot d sig e « l’e se le des
étapes successives dans la o duite d’u e op atio o ple e » par exemple « Quelles
sont les démarches à sui e e as d’i e die ?». Le procédé après avoir été évoqué de
façon générale comme une « façon de faire » au XVIIe siècle, a évalué pour être défini
comme « la manière méthodique employée pour parvenir à un résultat ». Le terme «pro-
cédé », est plutôt utilisé dans la fabrication de produits à partir de matières premières.
Un processus après avoir désigné en général « u e suite d’ e e ts atu els, se
déroulant dans le même ordre », il se définit dans le domaine technique comme étant
« u e suite d’op rations aboutissant à un résultat » ota e t da s l’e p essio proces-
sus de fabrication. Par cette définition, nous pouvons voir que le terme de processus et
procédure, ont convergé, et même parfois été confondus dans le langage courant.
En effet, dans le domaine des SI, la p o du e o stitue l’aspe t o ga is du p o es-
sus. La distinction entre les deux termes a été normalisée par la norme ISO 9000 qui défi-
nit la procédure comme « u e a i e sp ifi e d’effe tue u e a ti it ou u p o es-
sus ». Cela sig ifie u’u p o essus peut do er lieu à plusieurs procédures différentes
bien définies sur le plan organisationnel. Autrement dit, les rôles sont bien attribués, les
supports (documents, données, logiciels) bien identifiés, et les méthodes de travail bien
arrêtées.
1.5 Processus métier

Un processus métier ou "Business Process" en anglais est défini par le Workflow Mana-
gement Coalition (WfMC) comme : "un ensemble de procédures ou d activités liées les
unes aux autres pour atteindre collectivement un objectif métier en définissant les rôles et
les interactions fonctionnelles au sein d une structure organisationnelle" (Coalition, 1999).
En effet, un processus métier met en exergue u e olle tio d’a ti it s et de tâ hes orga-
nisées dans le temps qui, une fois achevées, permettront d'atteindre un objectif organisa-
tionnel et un résultat précis et mesurable. Autrement dit, il est considéré comme un en-
semble de elatio s logi ues e t e u g oupe d’a ti it s i lua t des i te a tions entre
différents partenaires et participants tels que des applications ou des services du SI, des
acteurs humains ou d’aut es p o essus tie sous la fo e d’ ha ge d’i fo atio s et
de données pour fournir une valeur ajoutée tangible aux clients et aux différents interlo-
uteu s d’u e o ga isatio .
Le méta modèle proposé par (Morley, Hughes, Leblanc, & Hugues, 2007) permet de
oi l’i te a tio e t e es diff e ts o epts cf. figure 1.4).
- 22 -
Figure 1.4 Méta modèle du processus métier selon (Morley, Hughes, Leblanc, & Hugues, 2007)
1.6 La gestion des processus métier (BPM)

Le "Business Process Management" (BPM), traduit littéralement en français par la ges-
tion de processus métier, est défini par (Van der Aalst, Ter Hofstede, & Weske, 2003)
comme : "l'utilisation de méthodes, techniques et systèmes logiciels pour concevoir, exé-
cuter, contrôler et analyser des processus opérationnels faisant intervenir des hommes,
des applications, des documents et d'autres sources d'information". Cela est donc consi-
déré comme une approche managériale axée sur l'alignement de tous les aspects d'une
organisation aux besoins des clients qui pla e les p o essus tie au e t e d’u e é-
fle io glo ale d’i t g atio "Process-centric". Le but est, en effet, de favoriser l'efficacité
opérationnelle tout e a o da t la uestio de l’a lio atio o ti ue des p o essus
priorisant le point de vue « métier » au point de vue « technique », cela rend donc les
p o essus plus effi a es et apa les de s’adapte à d’ e tuels ha ge e ts da s
l’e t ep ise. E d’aut es te es ’est u e app o he pe etta t à u e o ga isatio de
s’assu e ue ses p o essus sont mis e œu e effi a e e t tout e po da t au e-
soins de ses différents interlocuteurs avec un niveau, de performances optimales et une
maîtrise des coûts.
1.7 Cycle de vie d’un processus métier

Le cycle de vie d’u p o essus tie selo une démarche BPM permet un accompa-
gnement d’u p o essus tie depuis sa o eptio à sa gestio et so pilotage tout e
évoluant en permanence selon les objectifs métiers qui le définissent. Cela se manifeste
par une mise en œu e du poi t de ue "th o i ue" jus u’au poi t de ue "p ati ue" d’u
processus métier à travers plusieurs définitions et perspectives.
- 23 -
Dans la littérature, il n'y a pas de vue uniforme sur le nombre de phases du cycle de vie
BPM. Il varie en fonction de la granularité choisie pour l'identification des phases (Gillot,
2008), (Crusson, 2003), (Debauche & Mégard, 2004).
Il est composé principalement de quatre phases comme le montre la figure 1.5 :
1. La phase de modélisation "Process Modeling"
2. La phase d’implémentation "Process Implementation"
3. La phase d’e utio "Process Execution"
4. La phase de pilotage et d’opti isatio "Process Analysis"
Modélisation
Pilotage BPM Implémentation
Exécution
Figure 1.5 Cycle de vie du BPM
1.7.1 Phase de modélisation

La modélisation est la première phase dans le cycle de vie du BPM. Dans cette phase
les experts métier 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 à l'aide d'un outil de
od lisatio ui pe et de sp ifie l'o d e des tâ hes da s le p o essus tie . L’outil
de modélisation supporte une approche utilisant une notation de modélisation graphique
basée généralement sur l'adoption du standard "Business Process Modeling Notation"
(BPMN) (OMG, 2011). Les modèles de processus créés dans cette phase sont générale-
e t d’u i eau d’a st a tio le pou t e di e te e t exécutés par un moteur de
processus en aiso du a ue d’i fo atio s te h i ues telles que les liaisons entre les
différents services, les formats de données pour chaque tâche ...etc. Par conséquent, un
modèle de processus métier ou "Business Process Diagram" doit être transformé en un
modèle de processus exécutable, qui est l'objet de la phase suivante.
1.7.2 Phase d’implémentation

Da s la phase d’i pl e tatio , le p o essus dans la phase de modélisation est
transformé et enrichi par les ingénieurs IT dans le ut d’être exécuté par un moteur de
processus "Process Engine" (Leymann & Roller, 2000). A cet effet, le langage standard
pour décrire les p o essus e uta les da s le o te te d’u e a hite tu e o ie t e ser-
- 24 -
vices (SOA) et les services web (Weerawarana, Curbera, Leymann, Storey, & Ferguson,
2005) est le "Business Process Execution Language" ou appelé aussi BPEL (OASIS
Standard, 2007). En effet, BPEL exprime donc u e s ue e d’ e e ts du Business
Process contrairement aux services web qui fournissent les fonctionnalités du service. Le
modèle de processus exécutable qui en résulte peut-être déployé dans un moteur de pro-
cessus pour son exécution, et cela afin de réaliser l’i te façage a e les diff e ts s s-
t es essai es au fo tio e e t du p o essus et pou ett e e œu e les gles
métier.
1.7.3 Phase d’exécution

La phase d’e utio est la phase op atio elle où la solutio de BPM est ise e
œu e. E effet, du a t ette phase, le p o essus e uta le ui sp ifie le d oule e t
de l’e se le des a ti it s d’u p o essus est i te p t pa u oteu d’e utio ap-
pelé BPE "Business Process Engine". Le BPE est le responsable des interactions entre les
acteurs du processus (les documents, les informations et les tâches). Il exécute des ins-
tances de processus tout en déléguant les tâches automatiques aux services web et les
tâches manuelles aux acteurs. Si u e e eptio se p oduit du a t l’e utio du p o es-
sus, le BPE a le rôle de lancer une action de compensation pour amener le processus à
une exécution valide.
1.7.4 Phase d’analyse et d’optimisation

La phase de pilotage se t à supe ise l’e utio op atio elle des p o essus tie
et mesurer les performances en se basant sur des fichiers logs. En effet, dans une organi-
satio , le pilotage effi a e d’u e a ti it tie ep se te u poi t i po ta t pou la
performance technique et économique de cette dernière.
Le BPM dans son objectif principal de management des processus métier doit fournir
des outils de pilotage pe etta t ai si u e p ise de d isio o e a t l’effi a it et
l’a lio atio des p o essus. Ces outils doivent permettre de mesurer et de présenter la
pe fo a e de l’a ti it tie u’elle g e. De a i e g ale, les solutio s de BPM
nomment cette fonctionnalité BAM pour "Business Activity Monitoring" ou Supervision de
l’a ti it tier, en français.
Le BAM est u e te h ologie de epo ti g adapt e à l’e se le des a teu s tie de
l’e t ep ise : les espo sa les, les a al stes, les di igea ts ou les se i es i fo ati ues,
cette technologie constitue un élément-clé des solutions de BPM qui permet de surveiller
les p o essus et s’assu e ue les pe fo a es e se d g ade t pas au fil du temps,
d’a lio e l’effi a it des p o essus, de do e la apa it d’a u i la aît ise et la
isio d’e se le du d oule e t de l’a ti it tie ou encore de contrôler le bon dé-
oule e t de l’a ti it à t a e s des ta leau de o d et e utilisa t des KPI "Key Perfor-
mance Indicators ou indicateurs clés de performance.
Les KPI so t des do es olle t es lo s de l’e utio des p o essus et ela da s u
but de les améliorer et les optimiser. Les analystes métier ont besoin de ces indicateurs
sur les différentes instances des processus. Les KPIs permettent de comparer et
d’a al se le d oule e t des a ti it s as es su les p o essus pa appo t au sultats
attendus. L’a al se po te su l’ide tifi atio des diff e tes zo es du p o essus ui so t
peu ou pas pe fo a tes et ui so t sus epti les d’ t e a lio es.
- 25 -
1.8 Technologies de processus métier

Construire des processus métier requière un ensemble de technologies telles que des
API "Application Programming Interface", des moteurs de workflow. Dans cette section,
ous d i o s uel ues te h ologies ui pa ti ipe t à l’implémentation et la gestion des
processus métier.
1.8.1 Processus et workflow

1.8.1.1 La notion de workflow
Un processus ne doit pas être confondu avec un Workflow. En effet, contrairement au
processus métier qui représente un ensemble d'activités et de procédures qui permettent
collectivement la réalisation d'un objectif métier, le Workflow ou « flux de travail » en
français représente l'automatisation partielle ou entière d'un processus métier (zur
Muehlen, 2004). Il sert à fournir à chaque acteur d’u p o essus, les i fo atio s es-
sai es à l’e utio des a ti it s ui le o pose t à sa oi les documents, les informa-
tions et les tâches et cela d'après un ensemble de règles procédurales (Workflow
Management Coalition, 1999). Autrement dit, ’est u e ep se tatio sp ifi ue pou
laquelle les mécanismes de coordination entre activités, applications ou participants peu-
vent être gérés par un système de gestion de workflow "WfMS" (Workflow Management
System).
La notion de workflow est apparue au début des années 90 dans le cadre des re-
cherches sur les outils logiciels facilitant le travail collaboratif.
1.8.1.2 Les systèmes de gestion de workflow
Un système de gestion de workflow est un système permettant de définir des proces-
sus de o kflo , de e et de g e l’e utio des i sta es de es de ie s. Cette
exécution est pilotée par un moteur de workflow pouvant interpréter la définition du
p o essus, i te agi a e les diff e ts pa ti ipa ts et d le he l’e utio d’u ou plu-
sieurs programmes ou applications.
U p o essus de o kflo od lis est o pos d’u e se le d’ tapes logi ues,
appelées activités, automati ues ou i te a ti es, ai si ue d’un ensemble de relations
(séquence, parallélisme, synchronisation, etc.) permettant de les relier, d’u e se le
de critères pour déclencher ou interrompre un processus, d’u e se le
d’i fo atio s, telle ue les a teu s ui peu e t t e u e essou e soit hu ai e ou
automatique et qui doivent exécuter une activité, les données, ou les applications infor-
matiques associées.
1.8.2 Services web

Un service web est une application autonome ou un composant, c.à.d. une fonctionna-
lité sémantiquement bien définie, identifiée par un identificateur uniforme de ressource
URI. Il représente une manière standardisée d'intégration des applications basées sur le
Web en utilisant les standards XML2, SOAP3, WSDL4, UDDI5 et les protocoles de transport
2
http://www.w3schools.com/xml/
3
http://www.w3.org/TR/soap12-part1/
- 26 -
de l'Internet (cf. figure 1.6). XML est utilisé pour représenter les données, SOAP pour
transporter les données, WSDL pour décrire les services disponibles, et UDDI pour réper-
torier les différents fournisseurs de services et les services disponibles.
UDDI Couche découverte
Web services & WSDL Couche service
XML Couche information
SOAP Couche packaging
HTTP/ HTTPS, SMTP, FTP Couche Protocol
Figure 1.6 Pile de protocoles de services web
Les principales caractéristiques d'un service web sont :

 L'interopérabilité grâce à son indépendance vis-à-vis des systèmes d’e ploitatio
et des langages de programmation.
 Publiable et accessible en utilisant le langage XML, les protocoles ouverts et les
standards du web.
 Vise à exposer une ou plusieurs fonctionnalités.
1.8.3 Le moteur du BPM

Le moteur du BPM remplace les moteurs de workflow. Il est chargé de chorégraphier
les se i es du SI. Aujou d’hui, les oteu s d’e utio des BPM respectent la norme
BPEL "Business Process Execution Language". L'utilisation générale de cette norme per-
met une interopérabilité entre les différents outils du marché.
1.9 La modélisation des processus métier

La od lisatio des p o essus tie pe et de ep se te le fo tio e e t d’u
p o essus e d fi issa t l’e se le des a ti it s à e ute ai si ue leu s ordres
d’e utio . Pou ela, il e iste da s la litt atu e deu app o hes pe etta t de d fi i
le o po te e t d’u p o essus. U e app o he dite i p ati e et u e app o he dite
déclarative. La figure 1.7 représente un exemple de ces deux approches.
L’app o he i p ati e se o e t e su la d fi itio p ise de la faço do t
l’e se le d’a ti it s doit t e achevé. Pour cela, l'ordre d'exécution entre les différentes
a ti it s est d it d’u e faço e pli ite e utilisa t u e se le de lie s ou de connec-
teu s. Ta dis ue, l’app o he d la ati e se o e t e plus su « e ui de ait t e fait »
4
http://www.w3.org/TR/wsdl/
5
http://www.uddi.org/
- 27 -
au lieu de « uoi fai e». Ce ui pe et au s a ios d’e utio de este i pli ites da s
la phase de od lisatio du p o essus et ela e ita t d’ u er explicitement tous
les s a ii d'e utio possi les da s ette phase. Cette app o he passe pa l’utilisatio
d’u e se le de o t ai tes et de gles pou est ei d e les possi ilit s d’e utio
des a ti it s d’u p o essus. Aut e e t dit, tous les hemins d'exécution, qui ne violent
pas les contraintes mise en place sont autorisés, ce qui offre beaucoup plus de chemins
d’e utio possi les et u e fle i ilit des od les o te us. Ces o t ai tes e pla e t,
donc, les connecteurs explicites qui existe t e t e diff e tes a ti it s da s l’app o he
impérative.
Dans les langages déclaratifs tels que ConDec (Pesic & Van der Aalst, 2006), PLM-flow
(Zeng, Flaxer, Chang, & Jeng, 2002), PENELOPE (Goedertier & Vanthienen, 2006), un pro-
cessus est vu comme un ensemble d’ tats et u e se le de o t ai tes qui contrôlent
les t a sitio s d’u tat vers un autre. Plusieurs paradigmes sont utilisés pour représenter
les états et les contraintes tels que : la logique temporelle linéaire, la modélisation basée
sur les règles, etc.
« B doit succéder a A »
A B A B
[{A, B}] [{A}, {A, A}, {A, A, A}, {A, B}, {A, A, B}, …]
(A) Modélisation impérative (B) Modélisation déclarative
Figure 1.7 Modélisation impérative et modélisation déclarative
1.9.1 Les langages de modélisation des processus métier

Les langages de modélisation permettent de définir la manière dont les différentes ac-
ti it s du p o essus so t e ut es. Aut e e t dit, le s a io d’e utio ui ep se te
u e suite o do e d’a ti it s. Plusieu s la gages i p atifs tels ue BPMN (OMG, 2011),
UML activity diagram (Group & OMG, 2007), EPC (ARIS, 2007) ainsi que des langages dé-
claratifs tels que ConDec (Pesic & Van der Aalst, 2006), PLM-flow (Zeng, Flaxer, Chang, &
Jeng, 2002),PENELOPE (Goedertier & Vanthienen, 2006) ont été proposés pour la modéli-
sation des processus métier.
1.9.1.1 Le standard BPMN
Le langage BPMN "Business Process Modeling Notation" est un standard pour la modé-
lisatio des p o essus tie d’u e e t ep ise pe etta t de d fi i u e otatio g a-
phique commune à tous les outils de modélisation. Il est proposé par le consortium
l'OMG/BMPI "Object Management Group et le Business Process Management Initiative"
depuis leur fusion en 2005.
Le principal objectif de BPMN est de fournir un cadre commun permettant de décrire
u p o essus d'u e a i e o p he si le pou tous les a teu s d’u e e t ep ise, de-
puis les analystes métier qui crée les ébauches initiales des procédures, jusqu'aux déve-
loppeurs responsables de mettre en place la technologie qui va exécuter ces procédures,
et ce, indépendamment de l'outil utilisé étant bien sûr censé supporter la norme. BPMN
découple les informations métier des informations techniques et fournit une correspon-
dance vers des langages d'exécution. Autrement dit, il permet de créer une passerelle
- 28 -
standardisée pour combler le vide existant entre la modélisation des processus métier et
les langages d'exécution des processus métier.
U diag a e BPMN est o pos d’u e se le d’ l e ts g aphi ues ui pe et-
tent de modéliser les activités, les flux, les relations, les données ainsi que leurs interac-
tio s. Il s’a ti ule autou de quatre catégories d’ l e ts o e le o t e la figure 1.8:
Figure 1.8 Él e ts de ase d u BPMN
 Les objets de flux "Flow Objects": ce sont les principaux éléments graphiques
qui permettent de définir le comportement d'un processus métier. Il existe
t ois t pes d’o jets de flu : les activités "Activities" qui correspondent à une ac-
tion qui peut être réalisée par un humain ou une machine. Elles possèdent un
début et une fin et ne peuvent commencer que si les activités qui les précédent
sont terminées. Une activité peut être atomique ou composée. Les évènements
"Events" qui correspondent à une action qui survient durant le processus. Ils
ont en général une cause et une conséquence. Il est ainsi possible de modifier
le d oule e t d’u p o essus lo s u’u énement particulier intervient au
ou s de l’e utio du p o essus. Il e iste at go ies d’ e e ts : D pa t,
Intermédiaires, Arrêt et enfin les passerelles ou les branchements "Gate-
ways" qui correspondent à un branchement dans le processus qui permet de
représenter une action dans l'avancement de ce dernier.
 Les objets de connexion "Connecting Objects": ce sont les éléments graphiques
qui permettent de relier les objets de flux les uns aux autres pour représenter
le he i e e t du p o essus. Il e iste t ois so tes de o e teu d’o jets : les
flux de séquence "Sequence flow" qui indiquent l'ordre d'exécution des actions.
Les flux de message "Message flow" qui correspondent à un lien entre deux
processus séparés et enfin, les associations "Association" qui permettent de lier
des données ou des documents aux objets du processus.
- 29 -
 Les partitions "Swimlanes": ce sont les éléments graphiques permettant de

structurer et regrouper les différents éléments qui composent le diagramme
BPMN. Ces éléments sont les partitions "Pools" et les sous-partitions "Lanes".
 Les artefacts "Artifacts" : ils sont utilisés pour fournir des informations supplé-
mentaires sur le pro essus. Il e iste t ois t pes d’a tefa ts : Les objets de don-
nées "Data object" qui montrent comment des données sont liées à une tâche
(via une association). Les groupes "Groups" qui permettent de regrouper des
ta hes d’u e e at go ie afi de ieu les repérer visuellement sur le dia-
gramme et enfin, les annotations "Annotations" ui pe ette t d’ajoute des
commentaires pour faciliter la lecture du diagramme BPMN.
La figu e .9 ep se te u e e ple od lisa t le fo tio e e t d’u p o essus de
vente aux enchères et utilisant la notation BPMN.
Tâches Passerelle
Participants
Donnée Flux de séquences Événements Flux de messages
Figure 1.9 Processus de vente aux enchères modélisé par la notation BPMN
1.9.1.2 Le diagramme d’activités UML

Le langage UML "Unified Modelling Language" est u sta da d p opos pa l’OMG
"Object Management Group" pe etta t d’e p i e des esoi s fo tio els et te h-
niques dans un environnement de développent orienté objet en utilisant plusieurs dia-
grammes :
Le diag a e de lasses, le diag a e d’a ti it s, …et . et plusieu s o epts pou
augmenter la sémantique de ces modèles : st ot pe, p ofil, … et .
Le diagramme couramment utilisé en UML pour modéliser les processus est le dia-
ga e d’a ti it s. Il pe et de d i e le o po te e t des p o essus sous la fo e de
flux ou d’e haî e e t d’a ti it s. La figure 1.10 montre les éléments graphiques des
diag a es d’a ti it s.
- 30 -
Nœud d’o jet Nœud d’a tio
Nœud de o trôle
Figure 1.10 ‘ep se tatio g aphi ue des p i ipau o epts da s u diag a e d a tivit s.
La figure 1.11 ep se te u e e ple de diag a e d’a ti it illust a t l’utilisatio de

œuds de o t ôle. Ce diag a e d it la p ise e o pte d’u e o a de.
Nœud i itial Nœud de ifur atio
Nœud de fusio
Nœuds
d’a tio
Nœuds de dé isio
Nœud d’u io et de
bifurcation fusionnés
Nœud de fi de flot
Figure 1.11 Processus de commande od lis pa le diag a e d a tivit s
1.9.1.3 Le paradigme de logique déontique

La logique déontique est utilisée dans (Goedertier & Vanthienen, 2006) à travers le
la gage PENELOPE pou od lise d’u e a i e d la ati e u p o essus tie , et e-
la, en se basant sur les axiomes temporels et déontiques pour modéliser un processus.
Cette logique permet de formaliser les variantes possibles dont l'obligation, l'interdiction,
la pe issio et le fa ultatif d’u e e utio d’u e a ti it tie . Cela pe et de te i
compte des obligations et des autorisations dans les interactions métier.
1.9.1.4 Le paradigme de la logique temporelle linéaire (LTL)
Le langage ConDec proposé par (Pesic & Van der Aalst, 2006) permet de modéliser
d’u e a i e d la ati e u p o essus tie e utilisant la théorie des automates et la
- 31 -
logique temporelle linéaire (LTL) (Rozier, 2011), (Hornus & Schnoebelen, 2002) comme le
montre la figure 1.12. Ces modèles peuvent être exécutés par un moteur spécifique.
Si A est exécuté [] (A -> <> B) c'est à dire,

au moins une fois, C chaque A est finalement
est exécuté aussi au A est exécuté suivie par B
moins une fois et au plus une fois
vice versa B est exécuté
deux fois
0..1 2
C A B
Figure 1.12 Un exemple simple d'un modèle CONDEC.
1.9.1.5 Le paradigme de modélisation basée sur les règles

Le paradigme de modélisation basée sur les règles ou "Rule based modeling" permet
de modéliser la logique du processus par un ensemble de règles en utilisant des langages
d la atifs. L’e utio de ces langages est assurée pa des oteu s d’i f e e de gles
ui d te i e t l’o d e d’e utio des a ti it s e fo tio de l’ aluatio des o di-
tions. Dans ce paradigme, le formalisme "Event-Condition-Action", ou appelé aussi "ECA"
a été adopté par de nombreux langages de modélisation des processus métier basés sur
les règles comme par exemple les travaux de (Zeng, Ngu, Benatallah, & O'Dell, 2001) qui
proposent par ailleurs de voir le processus comme un ensemble de tâches coordonnées
entre elles pa des gles ECA et d’utilise les age ts pou e apsule les se i es ui e é-
cutent les tâches du processus. Le langage BPTrigger, proposé par Chulsoon et al. dans
(Chulsoon & Injun, 2004), 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.
1.9.1.6 Les diagrammes EPC (chaîne de processus événementielle)
"Event-Process Chains" (EPC) ou Chaînes de processus événementielles est un concept
de modélisatio d elopp da s le ad e de l’outil ARIS "Architecture of integrated Infor-
mation System" d’IDS-Scheer (ARIS, 2007). Il permet une description des différentes dé-
pendances temporelles et logiques dans un processus métier en sélectionnant ou en
ag gea t u e se le d’ e e ts pou la e l’e utio d’u e a ti it sp ifi ue.
Autrement dit, EPC représente un processus métier comme une succession de fonctions
et d’ e e ts.
U diag a e EPC est o stitu d’ l e ts g aphiques comme le montre
l’e e ple dans la figure 1.13 représentant les fonctions (activités), les unités organisa-
tionnelles (les participants), les événements, les opérateurs logiques et des objets divers
comme les ressources utilisées. Il utilise des connecteurs logiques pour permettre de
construire des événements complexes.
Pour élaborer un diagramme EPC, il faut prendre en considération cinq règles selon
(Briol, 2008).
 Un processus doit commencer toujours avec un événement.
 Un processus doit se terminer toujours avec un événement.
 Les fonctions et les événements sont alternés.
- 32 -
 Les fo tio s et les e e ts dispose t au oi s d’u e e t e et d’u e sor-

tie.
 Un événement est un élément sans capacité de décision.
Figure 1.13 Él e ts de ase d u diag a e EPC.
Le diagramme de la figure 1.14, représente un exemple de diagramme EPC illustrant

l’utilisatio des diff e ts l e ts d taill s i-dessus. Ce diagramme décrit un processus
de traitement des commandes.
Évènement
Sortie
Entrée
Flux de control Interface
Figure 1.14 Processus de traitement des commandes modélisé en EPC.
1.9.2 Les langages d’exécution des processus métier

Bien que le "Business Process Diagram" pe et de ep se te d’u e a i e si ple
et o p he si le les diff e tes a ti it s et leu s o d es d’e utio , Il est notamment
impossible de l’e ploite di e te e t pa des oteu s d’e utio e aiso de so i-
eau d’a st a tio le . A et ga d, les la gages d’e utio des p o essus tie tel
- 33 -
que BPEL (Matjaz, 2006), (Farahbod, Glässer, & Vajihollahi, 2005) ont pour but de spéci-
fie le d oule e t de l’e se le des a ti it s d’u p o essus. Ces la gages ui so t in-
te p t s pa des oteu s d’e utio ou d'o hest atio , utilise t u e s ialisatio XML
pou d i e l’i pl entation du processus.
Les langages tels que XPDL (The Workflow Management Coalition, 2008) et ebXML
(OASIS, 2003) permettent de modéliser les flu d’i fo atio échangés entre les diffé-
rents acteurs et les activités à accomplir par ces différents acteurs. Tandis que WSFL
(Leymann, 2001), XLANG (Thatte, 2001), et BPEL4WS (OASIS, 2007) permettent
d’o hest e les se i es e is e œu e au sei d’u p o essus. Ces la gages e ploi-
te t les apa it s d’e te sio de WSDL.
Dans la figure 1.15, une chronologie des différents langages permetta t d’exécuter les
processus métier est donnée.
Figure 1.15 Ch o og aphe des diff e ts la gages d e utio des processus métier
1.9.2.1 Le langage XPDL

Le langage XPDL ou "XML Process Definition Language" est adopté par la plupart des
moteurs de workflow. Il est proposé par Workflow Management Coalition et permet de
définir un processus métier à l'aide du langage XML, en définissant les activités, les inter-
relations, les attributs qualifiant certains comportements de l'activité, les transitions, les
partenaires et les interactions entre eux.
1.9.2.2 Le langage ebXML
Le langage ebXML "Electronic Business using eXtensible Markup Language" est né du
esoi d’a oi u e suite de sp ifi atio s pou le p ojet commun entre OASIS "Organiza-
tion for the Advancement of Structured Information Standards" et UN/CEFACT "United
Nations Centre for Trade Facilitation and Electronic Business". Il permet d'assurer les
échanges électroniques professionnels "B2B" de manière interopérable. Il propose des
spécifications telles que ebMS pour décrire les transmissions de messages, CPPA pour
décrire les protocoles de collaborations et ebBP pour décrire les processus métier.
1.9.2.3 Le langage WSFL
Le langage WSFL "Web Services Flow Language" est un langage basé sur XML, déve-
loppé par IBM en 2001 afin de fournir une description de la composition de services web
sur deux niveaux : le premier niveau appelé modèles de flux "flow models" permet de
spécifier comment réaliser un but métier particulier dans ce cas, le résultat est une des-
cription d'un processus métier et le deuxième niveau appelé modèles globaux "global
models" spécifie le modèle d'interaction d'une collection de services de Web, dans ce cas,
le résultat est une description des interactions globales entre partenaires.
- 34 -
1.9.2.4 Le langage XLANG

Le langage XLANG "eXtensible LANGuage" est un langage de composition de services
web développé et normalisé par Microsoft en 2001 pour sa plate-forme de gestion de
p o essus BizTalk et ela afi d’appo ter des solutions aux lacunes existantes dans le lan-
gage de description WSDL. Il est basé sur des normes internet tels que XML, XSD "XML
Schema Definition" et WSDL. XLANG assure l'automatisation des processus métier et
permet l'orchestration des services web par la spécification du comportement d'échange
de messages. Ce langage utilise des structures simples tel que les Actions qui correspon-
dent aux opérations WSDL, les éléments de programmation structurée tels que : while,
switch, …et , ou e o e les l e ts pe etta t le pa all lis e et la s h o isatio des
éléments de base. Ce langage à disparu au profit de la norme connue sous le nom de
BPEL.
1.9.2.5 BPEL
La spécification BPEL "Business Process Execution Language" est un langage destiné à
l'exécution des processus métier orienté blocs ou "bloc-oriented". Il permet de définir le
processus, ou l'enchaînement et la logique des actions qui seront exécutées par le moteur
d'orchestration. Il est issu des langages WSFL (Leymann, 2001) et XLANG (Thatte, 2001) ,
et est dérivé de XML. Il supporte les protocoles standards des services web tel que SOAP,
WSDL, UDDI, WS-Reliable Messaging et les protocoles de transport d'Internet
(Weerawarana, Curbera, Leymann, Storey, & Ferguson, 2005).
Le nom exact de cette spécification du consortium OASIS est BPEL4WS (OASIS, 2007)
"Business Process Execution Language for Web Services". Ce qui pourrait induire en erreur
car un processus BPEL ne peut se résumer à l’orchestration des services web mais il peut
également inclure des connecteurs transactionnels comme les EJB ou des procédures
stockées en SQL.
Les principales caractéristiques du langage BPEL4WS sont les suivantes :
 Exprimer les processus métier par un langage standard.
 Décrire la logique des processus métier à travers la composition de services web.
 Invoquer les opérations du service web dans un ordre séquentiel ou parallèle.
 Garantir la synchronisation de l'exécution des processus parallèles.
 Permettre d'annuler le traitement fait par une activité en cas d'échec.
 Maintenir l'exécution des activités pour une longue période.
U fi hie BPEL pe et de d i e de a i e d taill e ha ue l e t d’u p o essus
métier ainsi que de représenter le parallélisme et la synchronisation. Sa structure globale
est décrite comme suit:
La force du langage BPEL se manifeste dans la structure de son processus qui est basée
sur un fichier XML composé de trois blocs principaux comme présenté ci-dessus : les ser-
vices web qui participent dans la composition du processus (les partenaires), les variables
manipulées dans le processus et les activités de traitement qui composent le processus
métier.
- 35 -
<process name="processName"
xmlns="http://docs.oasis-open.org/wsbpel/2.0/process/executable"
targetNamespace="http://example.com"
xmlns:tns="http://example.com"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<variables>
<variable name="x" type="xsd:int"/>
</variables>
<partnerLinks>
<partnerLink name="ResultRequester"
partnerLinkType="tns:requestResultPartnerLinkType"
partnerRole="requestResultAdder"
myRole="requestResultRequester"/>
</partnerLinks>
<faultHandlers> ...</faultHandlers>
<compensationHandlers>...</compensationHandlers>
[Activités]* (atomiques et composées)
</process>
La balise <process> est l'élément racine du fichier BPEL. Elle permet la description
complète du processus. Grâce à l'attribut name, on peut attribuer un nom au processus.
Tandis que la balise <variables> permet de représenter les différentes variables qui
sont utilisées par les activités et qui sont utilisées aussi dans la description des compor-
tements du processus. Autrement dit, elles sont utilisées pour détenir les données rela-
tives à l'état interne du processus, pour stocker, reformater et transformer des messages
avec les services web invoqués. Ces variables peuvent servir aussi à déterminer les types
de messages échangés au sein du processus. La balise <Partnerlinks> permet de
ep se te les pa ti ipa ts ui o t pou ôle d’e ute les a ti it s du p o essus et ela
en définissant les liaisons entre les actions définies dans le fichier WSDL (via partner-
LinkType) au processus BPEL. L'attribut myRole ou partnerRole définit si c'est une
action qui appelle le processus ou si c'est une action appelée par le processus
Il existe deu t pes d’a ti it s: les a ti it s ato i ues ou dites aussi de base et les ac-
tivités composées ou dites aussi structurées. BPEL utilise un ensemble de balises pour
définir des activités atomiques comme par exemple la balise <invoke> qui permet
d’i o ue u e op atio d’u pa te ai e ou u se i e e pa te ai e. Cette i o atio
peut être réalisée de manière synchrone ou asynchrone. La balise <receive> permet
de e e oi u essage d’u e sou e e te e pa te ai e et la alise <reply> permet à
un processus de répondre à un message qu'il aurait reçu par l'activité receive. La balise
<assign> permet de fournir une méthode pour manipuler les données telle que la co-
pie ou l'affectation du contenu entre les variables ou expressions. La balise <validate>
permet de valider la valeur des variables dans leurs schémas de définition et enfin la ba-
lise <Empty> permet d'insérer une instruction non-opérationnelle qui ne fait rien dans
un processus.
Les activités structurées sont des activités composées. Elles décrivent l'ordre des flux
de contrôle et par conséquence décrivent les comportements du processus. Elles peuvent
être formées d'autres activités (atomiques ou structurées) d'une manière récursive.
Trois catégories de flux de contrôle dans les activités structurées : traitements séquen-
tiels, parallèles et sélectifs. Elles utilisent différentes balises tels que la balise <se-
- 36 -
quence> qui permet d'exécuter de façon séquentielle une ou plusieurs activités BPEL. La
séquence se termine elle-même lorsque la dernière activité du processus est achevée. La
balise <flow> permet d'exécuter en parallèle plusieurs processus. Ces différents proces-
sus peuvent être indépendants. Aussi, elle ne termine son exécution que si tous les pro-
cessus sont achevés en assurant une synchronisation totale. La balise <If> permet
d'ajouter une logique conditionnelle à la définition du processus BPEL. L'utilisation des
éléments elseif ou else qui sont facultatifs permet la définition d'une ou plusieurs
branches conditionnelles au sein de l'activité If. La balise <switch> décrit
l’a he i e e t o ditio el.
1.10 La traduction des langages graphiques vers les langages

d’exécution
La t adu tio auto ati ue des la gages g aphi ues e s les la gages d’e utio a
pou ut d’off i u od le e ploita le et o p he si le pa les oteu s d’e utio . A
et effet, plusieu s auteu s o t p opos u e se le de thodes et d’algo ith es afi
de traduire automatiquement une modélisation graphique vers un modèle BPEL comme
l’algo ith e d it da s (Ouyang, Van der Aalst, Dumas, & ter Hofstede, 2006) qui permet
de traduire un modèle BPMN en un modèle BPEL (cf. figure 1.16), ou encore (Gardner,
2009) qui propose un algorithme pour traduire un modèle exprimé en UML en un modèle
BPEL.
Figure 1.16 Transformation de BPMN à BPEL
Cela dit, cette traduction automatique demeure imparfaite puisque les aspects gra-
phiques comme les partitions et les sous-partitions des modèles BPMN sont perdus.
D’aut e pa t, le od le BPEL o te u peut essite des ajuste e ts de ode. Pa
e e ple, les a ia les o te ues au sei des a ti it s peu e t essite d’ t e d la es
au préalable comme assignées à des paramètres de services web.
- 37 -
1.11 Les règles métier

Une règle métier ou règle de gestion ou encore "Business Rule" en anglais est une di-
e ti e ui pe et de gou e e , d’i flue e les p ises de décision, et de contrôler les
o po te e ts tie s et l’i fo atio au sei d’u e o ga isatio . Selo le g oupe BRG
"Business Rules Group", les règles métier sont « des définitions de haut niveau structu-
rées, qui permettent de contraindre, contrôler et influencer un aspect du métier » (Group
T. B., 2000). Ces règles sont donc utilisées pour implémenter les stratégies ou les poli-
ti ues d’u e o ga isatio (zur Muehlen & Indulska, 2010) mais elles sont aussi utilisées
pou od lise u p o essus tie d’u e a i e d la ati e (Knolmayer, Endl, &
Pfahrer, 2000). Il existe cinq catégories de règles métier selon (Wagner, 2005) :
 Les règles d’i t grit : Il s’agit des o t ai tes ou asse tio s ui doi e t t e satis-
faites. Exemple : Un projet doit avoir un et un seul chef de projet ;
 Les règles de dérivation : Il s’agit d’u e ou plusieu s o ditio s et d’u e ou plu-
sieurs conclusions. Exemple: Le client "platinum" reçoit une remise de 5%. Cela se
traduisant par le fait que si Dupond est un client "platinum", alors Dupond recevra
une remise de 5% ;
 Les règles de réaction : Il s’agit des gles ui se d le he t pa des occurrences
d’ e e ts E e t, Co ditio , A tio , Alte ati e-action, Post-condition) et qui
exigent une satisfaction de conditions pour exécuter des actions. Exemple : à la
eptio d’u e de a de de p t, si le lie t ’est pas e dett alo s le p t est
approuvé ;
 Les règles de production: Il s’agit d’u e ou plusieu s o ditio s et d’u e ou plu-
sieu s a tio s o ditio , a tio . E e ple: Si il ’ a pas de d faut da s la a os-
serie de la voiture et que le contrôle technique se révèle normale, alors la voiture
peut circuler normalement ;
 Les règles de transformation : Il s’agit des gles ui o t ôle t le ha ge e t
d’ tat du s st e. E e ple : la date du jou doit t e ha g e de a i e i é-
mentale;
1.12 Caractéristiques des modèles & langages de processus métier

Comme soulevé précédemment, la phase de modélisation constitue une étape pri-
o diale da s le le de gestio d’u p o essus tie . Elle pe et de ett e e
e e gue les sp ifi atio s et les o aissa es tie d’u e o ga isatio à des fi s
d’e ploitatio et de réutilisation tout en séparant la logique « processus » de la logique
« application », et ela afi d’off i u o e de dialogue e t e les e pe ts métier et les
équipes fonctionnelles. Cette modélisation des processus métier doit prendre en compte
plusieurs caractéristiques saillantes telles que définies dans (Lu & Sadiq, 2007) :
 L’e pressivit : la puissa e d’e p essi it d’u la gage de od lisatio de p o-
cessus métier représente sa capacité à fournir une description complète des diffé-
e ts l e ts d’u p o essus (Sadiq & Orlowska, 1999), (Sadiq & Orlowska,
1997) ;
 La flexibilité : la apa it d’u p o essus tie à s’e ute d’u e anière stable
su la ase d’u e pe te et/ou d’u e sp ifi atio pa tielle du p o essus suite à un
- 38 -
changement (Schonenberg H. , Mans, Russell, Mulyar, & van der Aalst, 2008),
(Burkhart & Loos, 2010);
 L’adaptabilit : la apa it d’u p o essus tie à agi à des exceptions impré-
isi les, ui peu e t su e i g ale e t du a t l’e utio de ses i sta es
(Weber, Wild, Lauer, & Rei, 2006)
 La complexité : la capacité à mesurer la difficulté à modéliser, vérifier et déployer
u p o essus tie ai si ue de suppo te les ha ge e ts d a i ues d’u
processus métier en constante évolution (Cardoso J. , 2006), (Latva-Koivisto,
2001);
 Le dynamisme : la apa it d’u modèle de processus métier à changer lorsque le
processus évolue. Cette évolution peut être due à l'amélioration des processus, ou
à l'innovation de procédés ou a la réingénierie des processus (Schonenberg H. ,
Mans, Russell, Mulyar, & van der Aalst, 2008);
1.13 Les dimensions de la modélisation d’un processus métier

Afi d’o te i des od les ui po de t au diff e tes a a t isti ues d taill es
précédemment, il faut prendre en considération plusieurs éléments. Selon (Jablonski &
Bussler, 1996), les l e ts l s d’u p o essus tie peuvent être classés en cinq
g oupes. Cha ue g oupe ep se te u e di e sio u’u p o essus tie doit possé-
der. Ces cinq dimensions sont : la dimension fonctionnelle, la dimension comportemen-
tale, la dimension informationnelle, la dimension organisationnelle et la dimension opéra-
tionnelle.
1.13.1 La dimension fonctionnelle

La di e sio fo tio elle o e e l'ide tifi atio des diff e tes a ti it s d’u p o-
cessus métier que l'on souhaite modéliser avec une certaine hiérarchie. En effet, Il existe
deu t pes d’a ti it s les a ti it s ato i ues dites aussi Tâ hes ou "Tasks" en anglais
et (2) les activités composées appelées aussi sous-processus ou "sub-process" en anglais.
L’e se le de es a ti it s ep se te u e se le d’a tio s ui s’e ute t d’u e a-
nière indivisible par un participant afin de réaliser un objectif global de ce processus
comme définie par le WfMC « une activité est une description d'une unité de travail qui
forme une étape logique dans un processus » (Coalition, 1999). L’e utio d’u e a ti it
peut être manuelle dans le cas où elle exige une intervention humaine, ou automatisée
da s le as où elle s’e ute pa u e a hi e. Le od le fo tio el doit aussi ep sen-
ter le flux de données associées aux activités et les interdépendances de données entre
les activités (data flow).
1.13.2 La dimension comportementale

La dimension comportementale, appelée aussi dimension de coordination représente
un aspect primordial du processus métier puisqu'il correspond à la dynamique du proces-
sus. Ce comportement s'exprime par la modélisation d'un flux de contrôle entre les diffé-
rents éléments à exécuter dans un processus et plus précisément les dépendances entre
les diverses activités. Ce dernier permet d'indiquer la chronologie de l'exécution. Autre-
e t dit, les elatio s logi ues ui o t ôle t l’a he i e e t et l’o d e d’e utio de
- 39 -
ces activités. Ces elatio s peu e t t e d fi ies d’u e a i e s ue tielle ou pa all le

avec des points de synchronisation et/ou de disjonction entre activités (Russell, Ter
Hofstede, & Mulyar, 2006). De plus, la dimension comportementale doit représenter les
événements qui permettent de déclencher ces activités.
1.13.3 La dimension informationnelle

La dimension informationnelle représente l'ensemble des informations et des données
qui sont produites ou manipulées par un processus métier et qui sont associées aux acti-
vités. Il décrit en détail les relations qui existent entre les données, leur type et leur struc-
ture. Ces entités peuvent être des données simples (des chaînes de caractères, des dates,
des entiers, etc.), des données complexes (des ensembles, tableaux) ou des documents
(Russell, Ter Hofstede, Edmond, & van der Aalst, 2005).
1.13.4 La dimension organisationnelle

Comme son nom l'indique, la dimension organisationnelle permet d'établir des liens
hi a hi ues e t e les essou es ui o t la espo sa ilit d’e ute les l e ts d’u
processus ainsi que des relations entre unités organisationnelles ou départements. Ces
ressources qui sont une personne « acteur», une application « service-web » ou une enti-
t so t appel es aussi pa ti ipa ts pa e u’elles pa ti ipe t à la alisatio de l’o je tif
global du processus. Un ensemble de patrons pour décrire les différentes manières dont
les ressources sont représentées et utilisées dans un processus est donné par (Russell,
van der Aalst, Ter Hofstede, & Edmond, 2004).
1.13.5 La dimension opérationnelle

La di e sio op atio elle pe et de d taille l’aspe t op atio el d’u p o essus
métier. Ces détails représentent, en effet, les informations techniques utilisées lors de
l’e utio du p o essus o e : le fo at des essages ha g s, le ode d’i o atio
(synchrone ou asynchrone) et les protocoles de transport utilisés.
1.14 Réactivité, flexibilité et agilité d’une entreprise

La a ti it d’u e e t ep ise ep se te e g al sa apa it à agi apide e t
au diff e ts esoi s de ses i te lo uteu s pa u e s e gie e t e « l’opti isatio de ses
thodes de t a ail » et « l’a lio atio de ses essou es » et ela afi de garder un
avantage concurrentiel sur ses concurrents (Ross, Rhodes, & Hastings, 2008). Cette réac-
tivité passe par une série de changements qui peuvent être vus comme une réponse à un
esoi d’a lio atio et d’opti isatio li à l’attei te d’u e tai seuil d’i satisfa tio
da s le s st e d’i fo atio d’u e o ga isatio . Ai si, Il est alo s plus fa ile de o sta-
te ue la a ti it est u e o s ue e de la o st u tio ou la e o st u tio d’u SI
afi d’assu e u e a lio atio ta gi le de l’effi a it d’u e o ga isatio , et ui est ac-
o plie g ale e t g â e au te h ologies de l’i fo atio (IT). La réactivité doit pas-
se d’a o d pa la fle i ilit des essou es, aussi ie hu ai es ue te h ologi ues
d’u e o ga isatio . Cette fle i ilit de gestio pe et d’o te i l’agilit souhait e de
l’e t ep ise (Mooney, Beath, Fitzgerald, Ross, & Weill, 2003), (Boucher, 2007). Autrement
- 40 -
dit, ces ressources doivent être rapidement adaptables (Ross, Rhodes, & Hastings, 2008)
d’u e faço agile afi d’attei d e l’o je tif de la a ti it d’u e o ga isatio .
Notons que les o epts d’agilit et de fle i ilit peu e t p êter à confusion en théo-
rie. Cependant, ces deux termes présentent des différences notables. La flexibilité est
se la le à la otio de a ti it i dust ielle, à sa oi la apa it d’u e o ga isatio à
répondre rapidement aux différents besoins de ses clients par une attribution différente
de ses essou es ta dis ue l’agilit ep se te la apa it d’u e o ga isatio à s’adapte
rapidement à son environnement, permettant ainsi de procéder à des changements har-
o ieu et o ti us de l’e t ep ise.
1.15 La flexibilité de la modélisation des processus métier

La flexibilité ne cesse de susciter un intérêt majeur des organisations et cela afin
d’a lio e leu p odu ti it , et leu apidit d’adaptatio au ha ge e ts. Da s e
contexte et pour faire face à l'évolution des processus et des exceptions qui peuvent sur-
e i du a t l’e utio de es de ie s, la fle i ilit des modéles de processus métier se
définit comme une propriété des modèles à être modifiés sa s p o o ue l’i sta ilit du
système où ils sont utilisés (Kumar & Narasipuram, 2006). Autrement dit, la flexibilité qui
constitue une caractéristique élémentaire des processus métier représente la capacité de
ett e e œu e des ha ge e ts au i eau du s h a "Process Type Level" ou au ni-
veau des instances "Process Instance Level" d’u p o essus tie e odifia t u i ue-
ment les parties qui ont besoin d'être changées tout en conservant la stabilité des autres
parties du processus (Soffer, 2005), (Regev & Wegmann, 2005) et cela en définissant des
a is es pe etta t d’assu e la oh e e du od le tie et du od le e u-
ta le. Il est aussi soute u ue la fle i ilit e doit pas se su e u’au p o essus tie
mais aussi aux règles métier qui permettent de capturer la sémantique de la politique et
de la gle e tatio d’u e o ga isatio (Goedertier & Vanthienen, 2006).
1.16 Les taxonomies de la flexibilité des processus métier

Il existe des travaux dans la littérature qui ont tenté de proposer une taxonomie qui
soit la plus générique possible de la flexibilité des processus métier. Parmi ces travaux on
peut citer ceux de (Regev, Soffer, & Schmidt, 2006) , (Schonenberg M. , Mans, Russell,
Mulyar, & van der Aalst, 2007) et (Nurcan, 2008).
La taxonomie proposée par Regev et al (Regev, Soffer, & Schmidt, 2006), s’i t esse
au ha ge e ts ui peu e t su e i du a t le le de ie d’u p o essus tie cf.
figure 1.17). Elle prend en considération trois dimensions de changement :
 Le i eau d'a st a tio du ha ge e t ou le i eau d’appli atio du ha ge e t
qui peut être appliqué soit au niveau du schéma ou spécification du processus
"Process Type Level", soit au i eau de l’i sta e du p o essus "Process Instance

Level".
L'objet du changement qui peut concerner les différents aspects ou dimensions du
processus métier. En effet, le changement peut concerner les activités du proces-
sus (dimension fonctionnelle), les flots de contrôle (dimension comportementale),
- 41 -
les données du processus (dimension informationnelle) ou les différents proto-

coles utilisés dans le processus (dimension opérationnelle).
 Les propriétés du changement tel que l’a pleu du ha ge e t "Extent of
change" qui peut être progressive pour changer une partie du processus ou révo-
lutionnaire ou radical pour créer un nouveau processus. La durée du changement
"Duration of change" qui peut être temporaire c.à.d. limité dans le temps ou per-
a e t .à.d. ala le jus u’au p o hai ha ge e t. La apidit du ha ge e t
"Swiftness of change" ui o e e l’i sta ta it du ha ge e t. Aut e e t dit,
qui peut être soit pris immédiatement en considération ou en différé; et
l’a ti ipatio du ha ge e t " Anticipation of change" qui peut être soit ad hoc
pour faire face à des situations exceptionnelles ou planifié et qui fait souvent par-
tie d'une refonte du processus.
Figure 1. 17 Les notions de changement selon la classification de Regev et al.
Schonenberg et al (Schonenberg M. , Mans, Russell, Mulyar, & van der Aalst, 2007),
p opose t u e ta o o ie ui s’i t esse à la fle i ilit du poi t de ue op atio el. Ils
proposent quatre types de flexibilités :
 La flexibilité par conception "Flexibility by design" qui est la capacité d'intégrer des
chemins d'exécution alternatifs au moment de la conception de telle sorte que la
- 42 -
sélection se porte sur le chemin le plus approprié lors de l'exécution de chaque

p o essus et ela e fou issa t la possi ilit d’e p i e le parallélisme entre les
a ti it s. L’i sta iatio ultiple d’u e a ti it da s la e e utio ,
l’it atio de l’e utio d’u e a ti it ou e o e l’a ulatio de l’e utio d’u e
activité.
 La flexibilité par déviation "Flexibility by deviation" qui est la possibilité de dévier
l’e utio d’u e s ue e d’u e i sta e du p o essus de sa t aje toi e i itiale
prescrite par le procédé original sans pour autant modifier la définition du proces-
sus et ela e pe etta t pa e e ple d’a ule , de d fai e, de refaire ou de
court-circuiter certaines activités.
 La flexibilité par spécification partielle "Flexibility by Underspecification" est la ca-
pacité d'exécuter un processus spécifié partiellement au moment de l'exécution, à
savoir celle qui ne contient pas suffisa e t d’i fo atio s pou lui pe ett e
d'être achevé. Autrement dit, la possibilité de définir certaines structures de pro-
essus da s la phase d’e utio e pe etta t la s le tio ta di e d’u f ag e t
de processus parmi plusieurs alternatives ou la modélisation tardive pour spécifier
des f ag e ts du a t l’e utio du p o essus.
 La flexibilité par changement "Flexibility by Change" est la possibilité de modifier
la d fi itio du p o essus du a t la phase d’e utio e pe etta t à l'u e ou à
l'ensemble des instances du processus en cours d'exécution de migrer vers la nou-
velle définition du processus.
La taxonomie proposée par Nurcan (Nurcan, 2008) s’i t esse p i ipale e t à la a-
ture de la flexibilité et comment cette dernière peut-elle être prise en compte, c.à.d. au
moment de la conception "Design-time" ou l’e utio "Runtime" du processus métier.
Pour cela elle propose deux types de flexibilités comme le montre la figure 1.18 :
 La flexibilité par adaptation (a posteriori) permet l'adaptation du modèle de pro-
cessus métier ou ses instances durant leurs exécutions. C'est le cas le plus fré-
quent dans la littérature. Le principal défi consiste à savoir (1) Quand et selon
quels critères cette adaptation devrait être faite ? (2) Sur quel niveau doit-elle être
appliquée c.à.d. au niveau du schéma de processus ou au niveau de ses instances
? (3) Comment peut-on faire face aux instances qui sont en cours d'exécution? Les
approches qui offrent ce genre de flexibilité sont basées sur des formalismes de
od lisatio ui o sid e t ue la d fi itio de p o essus ui e sulte ’est
pas vraiment flexible, mais plutôt adaptatif. Autrement dit, ces approches ne peu-
vent pas anticiper la capacité de changer lors de la phase exécution des modèles
de processus. Elles sont trop rigides pour être capables de capturer la nature dy-
namique des processus métier.
- 43 -
 La flexibilité par sélection (a priori) est basée sur des formalismes de modélisation
qui peuvent offrir une capacité à traiter avec le changement de l'environnement
de processus sans aucune évolution dans la définition de ce dernier (Weske,
2001), (Rinderle, Reichert, & Dadam, 2003). Cela signifie que la capacité de flexibi-
lité de ces processus devrait être incorporée dans leurs définitions pendant la
phase de modélisation. de manière à ce que les instances de processus soient tou-
jours conformes à la définition de ces processus.
Figure 1.18 Les notions de changement selon la classification de Nurcan
1.17 Gouvernance du changement des processus métier

La gestion des processus métier est une approche managériale proposée pour conce-
voir, exécuter et piloter les processus métier d’u e o ga isatio . Elle pe et d’a oi u e
eilleu e ue su la a tog aphie des p o du es d’e t ep ise, du a age e t des
workflow et du pilotage des processus métier. Toutefois, ces processus métier suscitent
un besoin permanent d'évolution et cela afin de réagir rapidement aux mouvements du
a h , et au t a sfo atio s tie s des diff e ts i te lo uteu s d’u e o ga isatio .
Les processus doivent être flexibles afin de faire face aux exigences de changements.
En d'autres termes, la gestion de l'évolution des processus métier est essentielle pour
pe ett e au o ga isatio s o e es d’ t e e phase a e les esoi s et l'e ironne-
e t de leu s i te lo uteu s. Ai si, la apa it de fle i ilit et d’adapta ilit des p o es-
sus métier à été identifiée comme étant l'un des facteurs critiques de succès pour tout
modèle de processus métier appelé aussi "Business Process Model" (Heinl, Horn,
Jablonski, Neeb, Stein, & Teschke, 1999), (Reijers, 2006). A o t a io, l’i apa it
d’appli ue a e su s les ha ge e ts essai es peut sou e t a outi à u d sfo c-
tionnement dans la gestion des processus métier et à des conséquences graves sur le plan
économique.
- 44 -
Cette exigence de flexibilité à donner naissance à plusieurs champs de recherche

comme la prise en compte du besoin de réingénierie de processus tel que la flexibilité, et
l’adaptatio au ha ge e t du a t la phase de od lisatio ou e o e la ifi atio du
bon fonctionnement du processus par des modèles formels ou par simulation. Toutefois,
ces changements comme détaillés dans le chapitre suivant peuvent être source de dégra-
dation sur le plan structurel, fonctionnel, comportemental ou qualitatif du processus mo-
difié et nécessiter une modélisation permettant de réaliser une analyse a priori de
l’i pa t p isio el du ha ge e t du p o essus tie et u e analyse a posteriori de
l’i pa t effe tif de e ha ge e t.
1.18 Nos contributions

Les recherches que nous avons entamées dans cette thèse visent à proposer une con-
tribution à la gouvernance du changement et la vérification des processus métier. Notre
objectif est de p opose u a is e ui pe et d’assu e à la fois u e a al se a priori
de l’i pa t du changement des processus métier e a al sa t l’i pa t st u tu el et uali-
tatif, et ela afi de d te i e l’i pa t d’u e olutio su l’e se le du s st e et de
vérifier la cohérence du modèle métier et du modèle exécutable. À partir de ces constats,
nous avons mis en exergue les problèmes suivants (Kherbouche & Basson, 2011),
(Kherbouche, Bouneffa, Ahmad, & Basson, 2013):
1. Quel sont les incohérences et les conséquences qui émane t d’u ha ge e t
des processus métier ?
2. Quel so t les t pes d’i pa t qui peuvent être générés suite à ce changement ?
3. Quelles sont les parties impactées directement ou indirectement par ce change-
ment ?
4. Comment peut-on vérifier la cohérence du modèle métier et du modèle exécu-
table après chaque changement ?
5. Comment garantir le respect des règles métiers, règles organisationnelles ou en-
core règles de législation suite à un changement de processus métier ?
6. Comment peut-o g e le ha ge e t d’u e gle tie tout en gardant la co-
hérence des processus métier existants ?
7. Comment peut-o alue la ualit d’u p o essus tie du a t so le de ie
et plus précisément après chaque changement ?
Notre solution aux problèmes énoncés précédemment se décline en quatre contribu-
tions formant une démarche globale de gouvernance du changement des processus mé-
tie alla t de la d fi itio du p o essus jus u’à sa ifi atio , à sa oi :
1. Nous p oposo s, d’a o d, u e app o he as e su la te h i ue du "model-
checking" afi de od lise la s a ti ue d’e utio d’u p o essus tie et
cela dans un but de vérifier formellement son bon fonctionnement.
2. La même technique est utilisée pour vérifier la conformité de ces modèles avec les
gles de o fo it ap s ha ue ha ge e t de l’u des deu .
3. Nous proposons aussi une analyse a priori de l’i pa t du ha ge e t des p o es-
sus métier qui aiderait ainsi les concepteurs et les experts métier à se rendre
compte a priori des o s ue es pote tielles de l’ olutio et d’e esti e le
- 45 -
coût. Cette analyse de l'impact du changement des processus métier est réalisée à
travers une approche basée sur une définition de la relation de dépendance tout
en tenant compte des spécificités des modélisations de ces processus.
4. Pour évaluer la qualité des processus métier durant tout leur cycle de vie et plus
particulièrement après chaque changement, nous proposons une adaptation de
certaines caractéristiques de la o e ualitati e ISO/CEI 9 ui se t d’ha itude
à évaluer la qualité des produits logiciels pour les processus métier. Cette adapta-
tion est justifiée par la similitude structurelle existante entre un processus métier
et un produit logiciel.
1.19 Conclusion
Nous avons présenté dans ce chapitre le contexte et le cadre théorique de nos travaux,
nous avons d’a o d soulig le rôle important des processus dans le système
d’i fo atio des o ga isatio s, l’app o he BPM ui pe et de g e es p o essus é-
tier durant leur cycle de vie, et les langages qui permettent de les modéliser et de les exé-
ute es de ie s. Nous a o s aussi is e e e gue l’i po ta e de l’adapta ilit et la
flexibilité des processus métier afin de pouvoir faire face à la nature changeante des diffé-
rents besoins des organisations, toute en présentant les différentes taxonomies de la
flexibilité qui existent dans la littérature. Enfin nous avons présenté la problématique et
les solutions apportées par ces travaux. Dans le chapitre suivant, nous allons présenter un
aperçu des travaux de recherche qui portent sur la gestion et la gouvernance du change-
ment des processus métier.
- 46 -
CHAPITRE
2
Vérification et intégration des
pro essus étier et État de l’art
2. Vérification et intégration des processus métier et État de l’a t
2.1 Introduction
La cohérence et la fiabilité des processus métier est une question primordiale pour
toute o ga isatio da s l’a o plisse e t de ses fo tio alit s. U p o essus peu
fiable ou erroné peut souvent aboutir à un dysfonctionnement dans la gestion du système
d’i fo atio et pa o s ue t, ause des pe tes oûteuses au e t ep ises pou a t
conduire à leur affaiblissement ou, dans des cas extrêmes, à leur faillite. A cet égard, les
organisations doivent accorder à la fois une attention plus grande à la problématique de
ifi atio et de l’i t g atio du ha ge e t des p o essus tie .
Deux axes principaux de recherche ont vu le jour dans ce domaine durant cette der-
nière d e ie, l’u po te su la ifi atio des p o essus tie et l’aut e est relatif à
l’i t g atio du ha ge e t et la gestio d’ olutio de es p o essus.
E effet, la ifi atio des p o essus tie a pou ut de s’assu e ue les a ti it s
du processus s’e ute t e o fo it a e e qui t p u i itiale e t et u’elles
’o t pas i duit des e eu s da s le sultat es o pt et ela, tout e ide tifia t
l’e se le des i oh e es p o o u es pa l’ olutio d’u p o essus tie , et de
proposer ai si des solutio s pou les so e . L’i t g atio et la gestio du ha ge e t
des processus métier a pou o je tif p i ipal d’i o po e les odifi atio s des p o es-
sus sa s pe tu e leu e i o e e t d’e utio at ialis pa les i sta es e ou s
d’e utio .
La suite de ce chapitre est organisée comme suit : Nous invoquons dans la section 2.2
l’i po ta e de la oh e e des od les de p o essus tie da s l’effi a it et la ua-
lité de ces derniers. Dans la section 2. , ous faiso s u tou d’horizon sur les différentes
techniques qui existent dans la littérature et qui permettent de vérifier la cohérence des
modèles de processus métier. Dans la section 2.4, nous commençons par présenter une
typologie des changements des processus métier, une t pologie des p op i t s u’u
changement de processus doit avoir. Enfin nous élaborons une synthèse des travaux de
recherche qui existent dans le do ai e de l’i t g atio et la gestio du ha ge e t des
processus métier.
2.2 La cohérence des modèles de processus métier

La cohérence des processus métier appelé aussi en anglais "Soundness" est un point
esse tiel. É ite les i te uptio s d’e utio de es p o essus, pe ett e leu s sui is et
leurs traçabilités sont autant d'atouts au service de l'efficacité et de la qualité de ces der-
niers.
L’o je tif du p o essus de gestio de la oh e e est d’assu e la o ustesse et la o-
hérence des modèles de processus métier, de manière automatique, lors de leurs évolu-
tio s. Ce i essite la ise e pla e d’u a is e de détection des incohérences et
proposer ainsi des actions réparatrices pour les résoudre.
O peut d fi i l’i oh e e d’u p o essus tie pa le fait u’u ou plusieu s lé-
ments de ce processus tels que des activités, des données ou des ressources y sont em-
plo es e t a sg essa t les elatio s s a ti ues ui les lie t et l’e se le des on-
traintes et des règles qui régissent leurs comportements. Cette définition fait apparaitre
- 48 -
le terme « un ou plusieurs » a il est possi le d’a oi u e i oh e ce avec un seul élé-

e t de p o essus tie . Pa e e ple, l’i dispo i ilit d’u e essou e au o e t où
u e ou plusieu s a ti it s e ou s d’e utio eule t a de .
L’e se le de es i oh e es ui peu e t su e i suite à u ha ge e t de p o-
cessus tie so t g ale e t le f uit d’u e au aise o eptio , d’u e i p isio
de od lisatio des p o essus tie ou e o e d’u d sfo tio e e t lo s de
l’e utio de es p o essus.
Ces incohérences peuvent être classées en quatre catégories distinctes qui sont : les
incohérences structurelles, les incohérences fonctionnelles, les incohérences comporte-
mentales et les incohérences techniques.
2.2.1 Les incohérences structurelles

U e i oh e e st u tu elle ep se te u d sfo tio e e t d’u e ou de plusieurs
propriétés structurelles observables sur un modèle de processus métier, cette incohé-
e e peut t e la o s ue e d’e eu s s ta i ues ou e o e u e iolatio de on-
traintes et de règles de conformité. En effet, les erreurs syntaxiques peuvent survenir
suite à une mauvaise utilisation des éléments de modélisation. Par exemple, une passe-
relle ET-jointure, OR / XOR-jointure ou un événement qui reçoit plus qu'un arc entrant,
etc. Les combinaisons valides ou non valides de ces éléments sont habituellement pres-
crites par la norme correspondante et leurs corrections nécessitent un délai raisonnable
en utilisant des outils de modélisation tels que BizAgi6, Intalio7 ou Bonita8, etc.
Un autre cas de ces erreurs est celui de la violation des contraintes et des règles de
o fo it ui assu e t l’i t g it et la oh e e tie des p o essus et ui peu e t
être spécifiées sur les données, les ressources ou sur le comportement de ces processus.
Pa e e ple, a a t l’ou e tu e d’u o pte a ai e, les informations à propos du client
doivent être vérifiées et validées. Le non-respect de cette contrainte dans la succession et
l’a he i e e t des a ti it s du p o essus peut o dui e à u e situatio e o e ou i a-
lide. Cette situation peut se produire aussi en définissant des règles qui soit redondantes,
jamais applicables ou qui violent le domaine de leur définition (Chniti, Albert, & Charlet,
2011).
2.2.2 Les incohérences fonctionnelles

L’o igi e des e eu s ui peu e t ause des i oh ences fonctionnelles est due à une
mauvaise conception des modèles de processus métier par les concepteurs et les experts
métier comme par exemple, (i) une situation de blocage "Deadlock" qui exprime une si-
tuatio où l’e utio du p o essus est da s u e i passe ou une attente infinie (Onoda,
Ikkai, Kobayashi, & Komoda, 1999) ; (ii) une situation de boucles infinies "Livelock" qui
e p i e u e situatio où e tai es a ti it s du p o essus s’e ute t i d fi i e t
(Tantitharanukul & Jumpamule, 2010) ; (iii) une situation de terminaisons multiples "Mul-
tiple Termination" (Tantitharanukul, 2010), ou encore (iv) une situation où des activités
continue t d’ t e e ut es ap s la te i aiso du p o essus.
6
http://www.bizagi.com/
7
http://www.intalio.com/
8
http://fr.bonitasoft.com/
- 49 -
Des e eu s s a ti ues peu e t t e aussi la ause d’i oh e es fonctionnelles et

qui n'ont aucune incidence sur l'exécution elle-même du processus, mais plutôt sur le
résultat obtenu qui n'est pas celui attendu. Cela représente un dysfonctionnement dans
la sémantique du processus métier. Par exemple, définir une activité non atteignable
"Dead-activity", da s e as, l’a ti it d fi ie e se a ja ais e ut e (Sun, Huang, &
Meng, 2011).
2.2.3 Les incohérences comportementales

Une incohérence comportementale se manifeste par un dysfonctionnement lors de
l’e utio d'u p o essus tie . E effet, u e e eu d’e utio appel e gale e t
une exception se caractérise par toute situation imprévue qui peut surgir durant
l’e utio d’u e i sta e d’u od le de p o essus tie (Adams, ter Hofstede,
Edmond, & van der Aalst, 2005), (Lerner, Christov, Wise, & Osterweil, 2008). Un conflit
sémantique entre les différents schémas de processus métier et ses instances peut aussi
t e u e ause d’i oh e e o po te e tale (Rinderle, Reichert, & Dadam, 2003).
2.2.4 Les incohérences techniques

Une i oh e e te h i ue est la o s ue e d’ e e ts al atoi es ui so t sus-
epti les d'e t aî e des ugs ou des e eptio s pe da t l’e utio d’u p o essus é-
tier. En effet, ces événements sont rares et imprévus comme une panne matérielle du
système informatique (une panne du serveur) qui peut déstabiliser le fonctionnement du
p o essus tie ou e o e u e i dispo i ilit d’u e ou de plusieu s essou es au o-
e t où u e a ti it e ou s d’e utio eut a de et ui peu e t g e des ex-
ceptions.
2.3 Les techniques de vérification des modèles de processus métier

La ifi atio de od les peut s’appli ue à tout s st e a a t u e s a ti ue
o po te e tale et u e ultitude de s a ii d’e utio possi les. Le p i ipe de ette
vérification consiste à s’assu e ue le s st e s’e ute o fo e t à e ui a été
p u i itiale e t du a t la phase de sa o eptio . Cela passe pa l’e t a tio auto a-
tique des comportements inattendus ou erronés dans des délais raisonnables tout en ga-
rantissant qu'une propriété est vérifiée par toutes les exécutions possibles du système.
Co e up de e t, l’e se le de es i oh e es des p o essus tie est
dû à diff e t t pes d’e eu s ui peu e t sou e t t e ep es et g es da s la phase
de modélisation, ais aussi da s la phase d’e utio et la phase de o ito i g. Da s e
contexte, les travaux de recherche qui existent dans la littérature consistent à fournir un
e se le de te h i ues et d’outils afi d’assu e u e a se e totale de toute e eu ui
peut induire des incohérences dans les processus métier modélisés par des diagrammes
EPC, des diag a es d’a ti it UML, des diag a es BPMN ou e o e pa u od le
BPEL.
Sadiq et al. (Sadiq & Orlowska, 1996), sont parmi les pio ie s da s l’ide tifi atio des
erreurs structurelles, comme les impasses et les boucles infinies, dans les workflow. Leur
travail vise principalement à identifier les erreurs syntaxiques avec un manque relatif
pour gérer les erreurs sémantiques des workflow. Actuellement, la majorité des travaux
- 50 -
ui so t e s da s e egist e se o e t e su l’aspe t s a ti ue des p o essus é-

tier, par exemple « le processus doit toujours finir par se terminer ?» et d’aut es ues-
tions similaires. Dans les sous-sections suivantes, nous détaillons les travaux les plus con-
nus dans ce domaine.
2.3.1 La vérification par modèles formels

U od le peut t e ualifi de « fo el » s’il est fo d su u e s ta e et u e sé-
mantique précise, construite sur des bases théoriques pour démontrer des propriétés
d'u e sp ifi atio d’u s st e do . A et ga d, la te h i ue de ifi atio pa o-
dèles formels consiste à fournir en plus de la représentation graphique, une sémantique
attribuée au comportement du processus modélisé qui peut manquer dans des standards
de notation tels que BPMN et cela afin de vérifier le bon fonctionnement de ce dernier.
Cette te h i ue a pou ut de ifie e tai es p op i t s telles ue l’a se e de lo-
age, la p op i t d’atteig a ilit da s u p o essus métier afin de détecter les erreurs et
cela, tout en tenant compte des propriétés du modèle et par conséquent, de sa notation.
En effet, le point de vue adopté par ces techniques de vérification formelle vise à offrir
un cadre mathématique permettant de fournir d'une part une description formelle du
système et d’aut e pa t, u od le des comportements souhaités (ou de proprié-
tés) de ce système et de s'atteler à répondre à la question suivante :
?
C’est à di e ue l'o he he à p ou e ue le od le du s st e satisfait ie le o-
dèle des propriétés.
De nombreux formalismes de spécification dédiés aux systèmes concurrents ont été
proposés dans la littérature et en particulier pour vérifier les modèles de processus mé-
tier. Ce sont, notamment les réseaux de Petri (Rdp), les systèmes de transition, les auto-
ates o u i a ts ou e o e l’alg e de p o essus CCS, CSP, LOTOS, etc. Une descrip-
tion de ces différents formalismes est détaillée dans ce qui suit.
2.3.1.1 Les automates
Les automates sont des modèles mathématiques, qui permettent de modéliser les
sp ifi atio s fo elles d’u g a d o e de s st es (Hopcroft, Motwani, & Ullman,
2006). Ils so t o pos s d’u e se le d’ tats du s st e, eli s e t e eu pa des t an-
sitions qui sont marquées par des symboles comme le montre la figure 2.1. Étant donné
un mot fourni en entrée, l’auto ate lit les s oles du ot u pa u et a d’ tat e tat
selo les t a sitio s. Le ot lu est soit a ept pa l’auto ate, soit rejeté.
Figure 2.1 Les éléments constituant un automate
Formellement, un automate peut est défini par le tuple A = (Q, Σ, δ, q0, F) où Σ repré-
se te l’alpha et ou l’e se le de a a t es ou s oles , Q ep se te l’e se le fi i
- 51 -
d’ tats, δ : Q * Σ → Q représente la fonction de transition, q0 ∈ Q représente l’ tat de

départ et enfin F ⊆ Q ep se te l’e se le des tats fi au ou a epta t .
Fu et al. dans (Fu, Bultan, & Su, 2004), proposent une plate-forme pour analyser et vé-
ifie les p op i t s d’u od le BPEL ui représente des interactions de services web
composites communiquant avec des messages XML asynchrones. La plate-forme com-
e e pa o e ti le p o essus e u t pe pa ti ulie d’auto ate dit ga d do t ha ue
t a sitio est uip e d’u "guard" en format XPath9 avec des files d'attente non bornées
comme une représentation intermédiaire après quoi ces automates « gardés » sont con-
vertis en Promela "Protocol Meta Language10" afin d’ t e ifi par SPIN model-checker
(Holzmann, 1997). SPIN consiste à vérifier si ces modèles satisfont ou pas des propriétés
formulées en logique temporelle linéaire LTL "Linear Temporal Logic" (Rozier, 2011),
(Hornus & Schnoebelen, 2002).
Wombacher et al. dans (Wombacher, Fankhauser, & Neuhold, 2004) présentent une
traduction de la plupart des activités BPEL en automates à états finis déterministes. Les
états de l'automate sont annotés avec des expressions booléennes. Ces expressions boo-
léennes permettent de capturer comment un processus BPEL interagit avec son environ-
nement.
Une vérification des services web exprimés en BPEL-WSCDL "XML-based description
languages" par UPPAAL model-checker11 est proposée dans (Diaz, Pardo, Cambronero,
Valero, & Cuartero, 2005). Ces services web sont traduits automatiquement en une or-
chestration d'automates temporisés "Timed Automata" afin de simuler et analyser le
comportement du système. Dans (Song Dong, Liu, Sun, & Zhang, 2006), les auteurs pro-
posent une plate-forme pou ifie auto ati ue e t l’o hest atio des se i es e
capturés en Orc (Misra & Cook). Les auteurs utilisent un modèle d’auto ates te po is s
pour les différentes expressions Orc afin de vérifier la sémantique opérationnelle de ces
services web, cette vérification est faite par UPPAAL model-checker.
Koehler et al. (Koehler, Tirenni, & Kumaran, 2002), définissent une approche dirigée
par les modèles pour la vérification de la propriété d'atteignabilité "Reachability". Cette
approche est fondée sur l'abstraction du processus métier en un automate non-
déterministe comme un modèle intermédiaire. Ensuite, ils traduisent l'automate en code
SMV, le langage d'entrée du model-checker NuSMV, afin de vérifier la propriété d'attei-
gnabilité exprimée en CTL.
Tantitharanukul propose dans (Tantitharanukul, 2010) de vérifier l’a se e d’i passes
"Deadlock" et de terminaisons multiples "Multiple Termination" dans les modèles BPMN.
L’app o he o siste à t a sfo e les od les BPMN e auto ates à tats fi is et à i-
fier la compatibilité des différentes transitions. Le modèle BPMN est considéré comme
o e te s’il e iste au oi s u e s ue e alide ui est a ept e pa les auto ates.
2.3.1.2 Les réseaux de Petri
Les réseaux de Petri (RdP) (Proth & Xie, 1995) sont apparus en 1962, dans la thèse de
doctorat de Carl Adam Petri. Ils représentent un modèle mathématique qui se prête par-
9
http://www.w3schools.com/xpath/
10
http://spinroot.com/spin/Man/promela.html
11
http://www.uppaal.com/
- 52 -
ticulière e t à la od lisatio et l’a al se du o po te e t des s st es d a i ues à

e e ts dis ets ai si u’au d eloppe e t de s st es dist i u s et o u e ts, et
ela d’u e a i e g aphi ue. Mais a a t toute hose ils pe ette t de si ule ette
dynamique et surtout, par des techniques de vérification "model-checking", de recher-
cher des propriétés telles que celles détaillées ci-dessous comme l'inter-blocage, la vivaci-
té, etc.
Il existe une variété de réseaux de Petri tels que les réseaux de Petri hiérarchisés
(Fehling, 1993), les réseaux de Petri colorés (Jensen, 1992), les réseaux de Petri temporels
(Wang J. , 1998), les réseaux de Petri autonomes (David & Alla, 1993), les réseaux de Petri
non autonomes (David & Alla, 2010), etc.
Un RdP est un graphe orienté biparti composé de places P qui représentent des condi-
tions ou les états des ressources du système, de transitions T qui représentent des évé-
e e ts ou des a tio s ui se d oule t au sei du s st e et d’a s ui ep se te t les
conditions nécessaires pour déclencher une action. Autrement dit, les effets d'une action
sur l'état du système sont modélisés par les arcs reliant les transitions aux places comme
le montre la figure 2.2.
Figure 2.2 Les éléments constituants un réseau de Petri
Chaque place du réseau contient un nombre entier positif ou nul de « marques » ou

appelé aussi « jetons » représentant le fait u’u e o ditio est vérifié ou une ressource
est disponible. Le nombre de jetons disponibles dans chaque place du seau u’o ap-
pellera marquage M définit l'état du système décrit par le réseau à un instant T. Il se ca-
ractérise par un vecteur colonne de dimension égale au nombre de places dans le réseau.
Le iéme élément du vecteur correspond au nombre de jetons contenus dans la place Pi. On
dit qu’u e t a sitio t est franchissable lorsque toutes les places qui sont en amont con-
tiennent au moins un jeton. Ce franchissement consiste à retirer un jeton de chacune des
places en amont et à rajouter un jeton à chacune des places en aval de la transition t.
Un réseau de Petri est défini formellement par un triplé R= (P, T, W) où P = {p1, p2,…,
pn} représente un ensemble fini non vide de places, T = {t1, t2,…,tn} représente un en-
semble fini non vide de transitions et W : P X T U P X T → N représente la fonction
d’i ide e o espo da t au a s W(p, t) / p ∈ P, t ∈ T qui contient la valeur entière
asso i e à l’a alla t de p à t et W(t, p) / p ∈ P, t ∈ T qui contient la valeur entière asso-
i e à l’a alla t de t à p.
U RdP off e u la ge e tail de p op i t s ath ati ues ui pe ette t l’a al se
du o fo tio e e t d’u s st e. U e lassifi atio de es diff e tes p op i t s
concernant la vérification des systèmes est présentée ci-dessous :
2.3.1.2.1 Propriété d'absence de blocage "No deadlock"
L'absence de blocage ou "deadlock" est une propriété qui exprime le fait u’u s s-
tème ne se trouvera jamais dans une situation de blocage ou une attente infinie qui
l’e p he a de p og esse . E effet, la situation de blocage est une situation dans la-
- 53 -
uelle deu ou plusieu s p o essus so t i apa les de p o de pa e ue ha u d’e t e

eu atte d la p og essio de l’aut e. Le p o l e du « dîner des philosophes » (Dijkstra,
1971) proposé par Edsger W. Dijkstra en 1965 est un cas d'école classique qui illustre bien
la p o l ati ue d’i te lo age.
2.3.1.2.2 Propriété d'atteignabilité "Reachability"
Dans un système approprié, certains états indésirables ne doivent en aucun cas être
atteints. Le sultat d’u e telle ifi atio est soit des as ui satisfo t ette e ige e ou
o . La p op i t d’atteig a ilit ui joue u ôle u ial da s la ifi atio des p op ié-
tés d'accessibilité telle ue l’a se e d'i te lo age et l'e lusio utuelle permet de
di e u’u e e tai e situatio pa ti uli e ou u tat peut t e attei t ou o o e pa
exemple « On peut entrer dans une section critique ». Cette propriété peut être considé-
rée comme la négation de la propriété de sûreté.
2.3.1.2.3 Propriété de sûreté "Safety"
Une propriété de sûreté permet de dire que, sous certaines conditions, quelque chose
de o d si a le e se p oduit ja ais. Aut e e t dit, ette p op i t affi e u’u s s-
tème ne doit pas présenter de mauvais comportement, comme par exemple « deux sys-
tèmes ne seront jamais simultanément en section critique », « il n'est pas possible de
parvenir à un état d'erreur » ou encore « un débordement de mémoire ne se produira
jamais ».
2.3.1.2.4 Propriété d'équité "Fairness"
Une prop i t d’ uit e p i e le fait que sous certaines conditions, quelque chose va
se produire (ou pas se produire) infiniment souvent de fois comme par exemple « La
porte sera ouverte infiniment souvent ».
2.3.1.2.5 Propriété de vivacité "Liveness"
Une propriété de vivacité correspond à vérifier qu'à tout instant le système conserve la
possibilité de reproduire toutes les actions. Autrement dit, elle permet de dire que, sous
certaines conditions, quelque chose de correct ou de bon finira par arriver, comme par
exemple « toute demande sera satisfaite », « la lumière passe au vert » ou encore « après
la pluie, le soleil ».
Les RdP sont largement utilisés pour décrire et vérifier les processus métier. En effet,
plusieurs travaux de recherche ont exploité les points forts de ces réseaux afin de vérifier
les e eu s ue peut o te i u p o essus tie o e l’a se e de lo age, la i a i-
té, etc. Le principe consiste à transformer les modèles de processus métier exprimés en
BPMN ou BPEL en un réseau de Petri en utilisant des « traducteurs » puis analyser ce der-
nier par des outils appelés « analyseurs ». Cette démarche est résumée dans la figure 2.3.
- 54 -
Figure 2.3 La v ifi atio d u p o essus tie pa les ‘dP
En effet, ces t a au p opose t u e ultitude d’app o hes et d’outils ui pe ette t

de réécrire la spécification des processus métier en terme de RdP. Parmi ces outils nous
pouvons citer BPEL2PNML (Hinz, Schmidt, & Stahl, 2005) ou encore BPEL2oWFN (Ouyang,
Verbeek, van der Aalst, Breutel, Dumas, & ter Hofstede, 2005) qui permet de transformer
automatiquement un modèle de processus métier exprimé par le langage BPEL en un ré-
seau de Petri exprimé en PNML "Petri Net Markup Language". L’outil BPEL PNML g e
un format qui est accepté par la majorité des analyseurs de RdP tels que LoLA (Schmidt,
2000), Woflan (Verbeek, Basten, & van der Aalst, 2001), PIPE (Bloom, Clark, Clifford,
Duncan, Khan, & Papantoniou, 2003) tandis que le réseau de Petri généré par
BPEL oWFN est sous fo at oWFN, e ui p se te u e li ite a il ’ a ue l’a al seu
Fiona (Massuthe & Weinberg, 2008) qui accepte ce format. Dans (Yi & Kochut, 2004), les
auteurs proposent un outil de design et de vérification de la composition des services
web basé sur les réseaux de Petri colorés.
L'article (Hinz, Schmidt, & Stahl, 2005) propose une sémantique formelle pour BPEL
as e su les seau de Pet i et ela afi d’assu e la gestio des e eptio s et des om-
pensations. En outre, les auteurs présentent un parseur qui convertit automatiquement
les modèles BPEL en réseaux de Petri. Par conséquent, cette sémantique permet une ana-
lyse automatique des réseaux de Petri obtenus par de nombreux outils de vérification.
Dans (Rosario, Benveniste, Haar, & Jard, 2006), les auteurs proposent une plate-forme
ui pe et de t adui e l’o hest atio des se i es e capturés en Orc (Misra & Cook)
en réseaux de Petri colorés. Van der Aalst dans (van der Aalst W. , 1998), propose une
plate-forme qui permet de vérifier les workflow en utilisant les réseaux de Petri.
Yang et al. (Yang, Tan, & Xiao, 2005) définissent une approche de vérification des pro-
priétés de deadlock et livelock d'un service web composé. En effet, cette approche se
base sur la transformation d'un service web composé spécifié avec BPEL en un réseau de
Petri coloré CP-nets comme un modèle intermédiaire. Ensuite, ce dernier sera pris
comme entrée par le model-checker CPN Tools pour vérifier les propriétés désirées. La
propriété deadlock a été définie aussi dans le travail de Nakajima (Nakajima, 2006) dans
lequel il propose une approche pour extraire la spécification comportementale d'un pro-
cessus BPEL et de vérifier la propriété en utilisant SPIN model-checker. En effet, le pas-
sage du processus BPEL vers le code Promela est réalisé par un automate à états finis
étendu comme une représentation intermédiaire. La propriété définie est formulée en
logique LTL.
Takemura dans (Takemura, 2008), montre comment il est possible de vérifier les mé-
canismes de transaction et compensation des modèles BPMN en utilisant les réseaux de
Petri et par conséquent, o e t appli ue l’a al se de l’atteig a ilit et la ou a ilit
de ces réseaux à ces mécanismes de processus métier.
- 55 -
Des travaux comme ceux de Dijkman et al. (Dijkman, Dumas, & Ouyang, 2007), ou en-
core (De Backer & Snoeck, 2008), proposent de fournir une sémantique formelle aux mo-
dèles BPMN en transforment ces derniers en réseaux de Petri et cela tout en identifiant
un certain nombre de composants de cette notation BPMN qui ne peuvent pas avoir une
correspondance dans les réseaux de Petri comme les instances multiples, la gestion des
exceptions pour les cas de sous-processus simultanés, etc. Dans la même optique, les au-
teurs dans (Ramadan, Elmongui, & Hassan, 2011) p opose t d’utilise les seau de Pet i
colorés pour fournir une sémantique formelle aux modèles BPMN au lieu des réseaux de
Pet i lassi ues pou plus d’e p essi it .
YAWL ou "Yet Another Workflow Language" (van der Aalst & ter Hofstede, 2005) est
u la gage à la fois g aphi ue et d’e utio desti à ep se te les p o essus tie
e te da t la s ta e des seau de Pet i pou u’elle suppo te tous les pat o s de flu
de contrôle, tels que la modélisation de l'instance multiple, les tâches composites, le re-
trait des jetons et les transitions connectées directement (Decker, Dijkman, Dumas, &
Luciano, 2008), (Ye, Sun, Wen, & Song, 2008). YAWL hérite des réseaux de Petri les méca-
nismes de vérification du bon fonctionnement des processus. Une nouvelle version de ce
langage est récemment proposée dans Russell & te ofstede, 2009) appelé newYAWL.
Cette nouvelle version tente de couvrir, en plus des patrons de flux de contrôle, tous les
patrons de données "data patterns" et les patrons de ressources "ressource patterns".
D’aut es t a au tels ue eu de (van der Aalst W. , 1999) et de (Langner, Schneider,
& Wehler, 1998) , p opose t u e ifi atio de p o essus tie od lis s à l’aide du
diagramme EPC. Cette approche consiste à transformer des diagrammes EPC en réseaux
de Petri pour vérifier leur cohérence. L'idée de base de ces approches est de restreindre
les classes du modèle EPC en sous-classes pour lesquelles il est plus facile de générer des
réseaux de Petri.
L'importance de la vérification des flux de données dans les workflow a été abordée
dans (Sadiq, Orlowska, & Sadiq, 2004). Les auteurs ont identifié plusieurs erreurs pos-
sibles dans le flux de données par exemple, l'erreur de redondance de données, la lecture
d'un type de donnée non initialisé ou erroné, mais aucun moyen de vérifier ces erreurs
’a t fou i da s e t a ail. Da s (Fan, Dou, & Chen, 2007), un modèle appelé réseau de
Petri double "DWF-nets" est proposé, afin de vérifier à la fois le flux de données et le flux
de contrôle.
En dépit des faiblesses soulevées précédemment, les RdP restent les modèles les plus
utilisés pour décrire et vérifier les processus métier.
2.3.1.3 L’algèbre de processus
Les algèbres de processus sont un formalisme mathématique permettant de modéliser
les systèmes concurrents ou distribués afin de vérifier automatiquement des propriétés
associées à leur comportement. Cette approche se base principalement sur les tech-
niques des algèbres universelles et les théories de la concurrence. A cet égard, de nom-
breux langages d’algèbres de processus ont vu le jour, les plus populaires entre eux sont :
 CSP "Communicating sequential processes" (Hoare, 1978) qui est une algèbre
de processus permettant de modéliser l'interaction de systèmes. Il permet de
fournir un mécanisme unifié pour la communication et la synchronisation des
- 56 -
systèmes, basé sur la notion de message et ne présupposant pas de l’e iste e

d’une mémoire commune entre les processus.
 CCS "Calculus of Communicating Systems" (Milner, 1980), (Milner, 1989) qui est
utile pour évaluer le bien-fondé qualitative des propriétés d'un système comme
une impasse "Deadlock" ou boucles infinies "Livelock".
 π-calcul (Milner, 1999) qui fournit une théorie solide pour la description des in-
teractions entre plusieurs threads en concurrences.
 Lotos "Language Of Temporal Ordering Specification" le sta da d d’’ISO (ISO,
1989) qui se base sur CCS et qui permet une spécification des systèmes paral-
lèles.
Plusieurs travaux de recherche ont utilisé ces algèbres afin de modéliser et vérifier les
processus métier. En effet, dans les travaux de (Salaün, Bordeaux, & Schaerf, 2004), les
auteurs proposent d’utilisatio l’alg e de p o essus pou d i e, o pose et ifie
les services web, avec un accent particulier sur leurs interactions. Ils montrent un
exemple dans lequel ils utilisent CCS pour spécifier et composer un service-web. Ils utili-
sent également la simultanéité de Workbench12 afin de valider les propriétés telles que la
composition correcte des services web. Cette approche peut être utile, si le π- calcul est
utilisé à la place du CSC afin de résoudre des problèmes tels que l'échange de messages
au cours d’interactions des services web.
Dans les travaux de (Ferrara, 2004), une approche est proposée afin de mettre en cor-
respondance BPEL/WSDL et le langage LOTOS. L'avantage de cette proposition est qu'elle
prend en compte les compensations et le traitement des exceptions en vérifiant ainsi, des
propriétés temporelles avec CADP model-checker (Fernandez, Garavel, Kerbrat, Mounier,
Mateescu, & Sighireanu, 1996).
La principale contribution du travail de (Wong & Gibbons, 2008) est de fournir une sé-
mantique aux différents éléments d’u od le BPMN e te es d'alg e de p o essus
CSP, et cela en utilisant le langage ensembliste Z (Woodcock & Davies, 1996). Les auteurs
Smith et al. (Smith & Fingar, 2003), proposent une plate-forme de modélisation gra-
phi ue et de ifi atio d’u p o essus tie basée sur π-calcul tandis que (Puhlmann
& Weske, 2005) utilisent le π-calcul afin de formaliser un ensemble de patterns de
workflow. Dans la même optique, (Yang & Zhang, 2003) proposent une nouvelle ap-
proche pour la modélisation de workflow basée sur le π-calcul, qui permet de caractériser
le comportement dynamique du workflow en termes de LTS "Labeled Transition Seman-
tics".
Les auteurs dans (Koshkina & Van Breugel, 2003) introduisent un langage, appelé
BPEL-calcul inspiré du π-calcul, pour représenter les caractéristiques dynamiques du lan-
gage BPEL en utilisant une suite comportementale du système type. Ce système type a
t od e utilisa t l’alg e de p o essus sa s te i o pte des do es ha g es
dans les différents messages. Cette approche permet de vérifier non seulement la pro-
priété de sûreté mais aussi la propriété de vivacité exprimée à l'aide de LTL.
Abouzaid et Mullins (Abouzaid & Mullins, 2009) proposent une approche de vérifica-
tion des propriétés de services web composés plus exhaustive. L'approche proposée se
base sur la transformation du processus BPEL en algèbre de processus BP-calcul pour véri-
12
http://www.cs.sunysb.edu/~cwb/
- 57 -
fier par la suite les propriétés. En effet, ce travail permet de vérifier plusieurs types de
propriétés spécifiées formellement avec la logique π-calcul en utilisant le model-checker
HAL-Toolkit telles que la propriété de vivacité, équité, fiabilité, disponibilité, sûreté et la
garantie de message "Responsiveness".
Une t adu tio d’u od le de p o essus tie e p i e BPMN e COWS
(Lapadula, Pugliese, & Tiezzi, 2007) est présentée dans (Prandi, Quaglia, & Zannone,
2008). Cet outil inspiré de π-calcul permet un raisonnement quantitatif sur le comporte-
e t des p o essus tie . U tel aiso e e t est o t à l’aide d’u as d’ tude ui
utilise PRISM model checker (Hinton, Kwiatkowska, Norman, & Parker, 2006).
Toutefois, la vérification par π-calcul implique la vérification d’ ui ale e par bi-
simulation. Ce qui implique une grande consommation de temps pour obtenir des résul-
tats, et cela même pour prouver des exigences d'exactitude simples.
Ceci étant, d’aut es app o hes, se basant sur des modèles différents, ont été propo-
sées comme le travail de (Pu, Zhao, Wang, & Qiu, 2006) qui propose μ-BPEL, un nouveau
langage basé sur BPEL et qui définit la sémantique des activités de base et structurées. μ-
BPEL est traduit en automate temporisé TA "Timed Automata", puis vérifié en utilisant
l’outil UPPAAL (Behrmann, David, & Larsen, 2004) permettant ainsi la vérification des
propriétés du réseau de TA.
La plate-forme VERBUS (Fisteus, Fernández, & Kloos, 2004) est une plate-forme mo-
dulai e e te si le ui ’est pas li e à u outil de ifi atio ou à un langage de descrip-
tion de processus particulier. 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éman-
tique en termes de CMF, et en implémentant un traducteur associé. Chaque outil de véri-
fication peut être intégré en implémentant un traducteur du CMF en langage d'entrée de
l'outil de vérification.
Malgré le temps que consomme l’app o he de vérification par les modèles formels
dont elle dépend de la complexité des algorithmes de traduction de la définition des pro-
cessus métier en modèles formels et de la complexité des algorithmes de détection des
propriétés à vérifier. Cette approche s’a e avantageuse e ati e d’effi a it
puisqu’elle aug e te la e titude d’u e a se e de dysfonctionnements dans les proces-
sus métier.
2.3.2 La vérification par guide de style

Dans cette technique, des règles de style ou de bonne pratique sont définies afin de
détecter les erreurs dans la phase de modélisation telle que « interdire l’asso iatio d’u e
ressource à deux activités métier en même temps ». Ces règles sont considérées comme
des guides de bonne pratique de modélisation good modeling style qui sont utilisés
afin de guider le concepteur à éviter les éléments qui peuvent conduire à des erreurs ou
les éléments qui représentent une source potentielle d’e eu s.
Un exemple de ces règles est proposé dans le travail de Gruhn et al. (Gruhn & Laue,
2006), (Gruhn & Laue, 2007) pour la vérification des diagrammes EPC ou encore le travail
de Van Dongen et al. (van Dongen & Jansen-Vullers, 2005) qui vérifie les modèles de réfé-
e es M SAP à t a e s l’AGL ARIS.
- 58 -
Toutefois, ette app o he este t s li it e et pe et de d te te peu d’e eu s,

puis u’elle te te de li ite les e eu s les plus o ues, d'auta t plus ue ette te h i ue
e d te te pas les e eu s p oduites lo s de l’e utio du p o essus tie .
2.3.3 La vérification par conception

La vérification par conception ou " Design approaches" sont des méthodes de vérifica-
tion basée sur des modèles de conception proposée dans un langage de requête gra-
phique ad hoc. En effet, Awad et al. (Awad & Puhlmann, 2008), (Laue & Awad, 2011) pré-
sentent une approche pour détecter les inters blocages "Deadlock" en utilisant un lan-
gage graphique appelé BPMN-Q (Awad, 2007) et qui permet de formuler des requêtes sur
le modèle de processus métier (sur sa structure graphique). Une autre approche (Di
Francescomarino & Tonella, 2009) basée sur le langage de requêtes BPMN VQL (Di
Francescomarino & Tonella, 2009) se focalise sur la structure graphique du modèle. Son
objectif principal est de trouver les préoccupations qui transcendent BPM. Toutefois, les
processus de modélisation utilisant cette notation nécessitent des compétences tech-
niques avancées et le modèle qui en résulte est généralement complexe et loin d'être
intuitive.
2.3.4 La vérification par simulation

La vérification par simulation consiste à comprendre, évaluer et comparer le processus
modélisé en utilisant plusieurs scénarii possibles. La simulation fournit ainsi des estima-
tions quantitatives sur l'impact qu'une conception de processus est susceptible d'avoir sur
son exécution (Jansen-Vullers & Netjes, 2006). Plusieurs simulateurs de processus métier
ont été proposés dans la littérature tels que ARIS (Scheer, 2010), (Scheer, 2000), Protos
(Verbeek, van Hattem, Reijers, & de Munk, 2005), etc. Ces outils permettent aux entre-
prises d'analyser rapidement leurs processus métier.
Dans (Jansen-Vullers & Netjes, 2006), un certain nombre de ces outils sont comparés
par rapport à leur applicabilité dans le domaine du BPM et aux modèles utilisés. Toute-
fois, la technique par simulation utilise des données théoriques et la qualité des estima-
tions fournies dépend fortement de la batterie de tests utilisée.
2.3.5 La vérification par process-mining

Cette technique appelée vérification par "Process mining" consiste à explorer et analy-
ser les t a es d’e utio d’u p o essus tie ou appelé aussi journaux des événe-
ments "Process Event Logs" et cela, dans le but de mesurer les performances opération-
nelles et métier de ce processus comme le montre le travail de (van der Aalst W. M.,
2007). Le but principal est de reconstruire un modèle à partir des informations cumulées
lors de la phase d’e utio "Reverse Business Engineering". Le processus résultat sera
o pa au p o essus od lis pou sa oi s’il s’agit du même déroulement de
l’e se le des a ti it s. Autrement dit, permettre aux experts tie d’assu e ue les
processus exécutés correspondent aux exigences métier.
Toutefois, cette technique de vérification ne peut être que complémentaire aux autres
techni ues puis u’elle e peut t e appli u e du a t la phase de od lisatio ais plu-
tôt du a t la phase d’e utio des processus métier.
- 59 -
2.4 Les techniques d’intégration & de gestion des changements des

processus métier
Les processus métier sont en permanente évolution durant tout leur cycle de vie et ce-
la afi de po d e à la atu e ha gea te du tie de l’e t ep ise. Cette exigence de
flexibilité des processus métier suscite depuis plus de vingt ans un intérêt croissant de
l'industrie et de la communauté scientifique afi d’off i un mécanisme permettant
l’i t g atio et la gestio des ha ge e ts des processus métier.
Le but principal étant de répondre aux questions qui peuvent subsister suite à un
changement de processus métier comme par exemple : (1) Que faire en cas de change-
e t d u s h a de processus métier ? (2) Co e t passe d u e ve sio à l aut e ? (3)
Que faire des instances en cours d e utio ? (4) Comment propager un changement du
modèle à une instance ? (5) Comment garantir la cohérence structurelle et comportemen-
tale du processus métier ? (6) Que faire des instances modifiées individuellement "Concur-
rent changes" ?
La conception d’un tel mécanisme de gestion des changements des processus métier
requiert une compréhension détaillée des causes de changements appliqués sur les mo-
d les de es p o essus, de leu s t pes et de leu s i eau d’appli atio . Par conséquent,
dans les sous-sections suivantes, nous commençons par détailler tout d'abord, la typolo-
gie des changements des processus métier, suivie de la typologie des opérations et des
propriétés de ces changements et enfin les travaux de recherche qui existent dans le do-
ai e de l’i t g atio et la gestio des ha ge e ts des p o essus tie .
2.4.1 Typologie des changements des processus métier

Les changements affectant les processus métier peuvent être motivés par des raisons
ultiples. Ils peu e t, e effet, t e olutifs e po se à l’ olutio des esoi s ou à
l'introduction de nouvelles réglementations. Ils peuvent également être perfectifs et cela
est pa ti uli e e t ai da s le ad e de l’a lio atio des it es de performance se
a ifesta t pa u esoi de gai de te ps, d’opti isatio des effo ts, et . E de ie ,
les ha ge e ts peu e t t e o e tifs e po se à la o statatio d’u e ou de plu-
sieurs anomalies (erreurs ou exceptions) du a t l’e utio d’u p ocessus métier.
Ces ha ge e ts peu e t s’appli ue su deu i eau :
 Le niveau du schéma du processus métier "Process Type Level".
 Le niveau des instances du processus métier "Process Instances Level".
Les changements appliqués au niveau des instances du processus métier sont égale-
ment connus comme étant des changements spécifiques "Instance-specific changes". Au-
trement dit, ils sont souvent appliqués de manière dite « ad-hoc » pour faire face à des
situations imprévues ou à des exceptions résultant de l’e utio d’u p o essus tie
(Klein & Dellarocas, 2000), (Nurcan, Etien, Kaabi, Zoukar, & Rolland, 2005), (Minor,
Schmalen, Koldehoff, & Bergmann, 2007). Ils n'ont généralement pas d'incidence sur le
reste des instances du processus en cours d'exécution et génèrent un impact local
(Nurcan, 2008). Dans la figure 2.4. , pa e e ple, l’i sta e I4 peut être modifiée indivi-
duelle e t e supp i a t l’a ti it D et en ajoutant l'activité X.
- 60 -
Figure 2.4 Niveaux de changement de processus
En général, changer une instance en cours d'exécution n'est pas suffisant pour résor-
e tous les p o l es e o t s. C’est la st u tu e du p o essus tie elle-même qui
doit être remise en question (Kradolfer & Geppert, 1999), (van der Aalst W. , 2001),
(Reichert, Dadam, & Bauer, 2003). À cet égard, les changements appliqués au niveau du
schéma du processus métier sont nécessaires pour faire face à la nature changeante des
rôles dans les processus métier i duits g ale e t pa l’adaptation aux nouvelles rè-
glementations, etc.
L’ olutio d’u s h a de p o essus tie essite sou e t la p opagatio de es
changements sur le reste des éléments du schéma ainsi que sur ses instances en cours
d’e utio . Aut e e t dit, e t pe de ha ge e t produit un impact global (Nurcan,
2008). La figure 2.4.a, illustre un changement au niveau du schéma du processus métier.
Le schéma S1 est le fruit des changements apportés sur le schéma initial S0 consistant à
ajouter deux activités X et Y.
Ces changements ne peuvent être accomplis avec succès que si les instances en cours
d'exécution sont conformes à la nouvelle version S1 du schéma. Dans notre cas, les ins-
tances I1 et I2 (cf. figure 2.4.a) peuvent migrer vers le nouveau schéma S1 contrairement à
l’i sta e I3 qui a déjà largement progressé dans son exécution. Cette instance doit donc
être réalisée sur la base de la version initiale S0 du schéma.
- 61 -
2.4.2 Typologie des opérations de changement

Nous pou o s disti gue deu t pes d’op atio s de ha ge e t pou a o pli e
dernier au niveau du schéma du processus métier ou de ses instances :
 Les opérations dites basiques "Basic operations".
 Les opérations dites complexes "Complexe operations".
Les op atio s asi ues pe ette t d’i s e , de supp i e ou de odifie u e a ti i-
t , ha ge u flu de o t ôle ou u flu de do es ou e o e ha ge l’affe tatio
d’u ôle. Quelques opérations basiques sont représentées dans la Table 2.1.
I sertio d’une nouvelle activité

Activité X est ajoutée au schéma S0
S0
A B Evolution
du schéma
X S1
A X B
Suppressio d’u e a tivité

S0 Activité B est supprimée du schéma S0
A B C Evolution
du schéma
S1
A C
Dépla e e t d’u e a tivité

Activité B est déplacée de sa position actuelle du schéma S0 à une autre position
S0 A
+ + C Evolution
du schéma
B
S1
A B C
Table 2.1 Opérations basiques de changement.
Les opérations complexes permettent le remplacement d'un fragment de processus

par un aut e, le d pla e e t d'u f ag e t de p o essus d’u e positio A à une position
B, la dupli atio d'u f ag e t de p o essus, l’ ha ge d’u f ag e t de p o essus pa
un autre, la pa all lisassio s d’u f ag e t de p o essus ou e o e u e aut e a tio
complexe. Ces opérations peuvent être une combinaison des opérations basiques de
ha ge e t o e l’ajout, la supp essio ou la odifi atio d'a ti it s. Quelques
exemples d'opérations complexes sont représentés dans la Table 2.2.
- 62 -
Repla e e t d’u frag e t de processus

Un fragment de processus est remplacé par un autre dans le schéma S0
S0
A B Evolution
du schéma
X Y S1
A X Y
Échange de fragments de processus

Echanger un fragment de processus par un autre dans le schéma S0
S0
A B C D Evolution
du schéma
S1
D C A B
Dupli atio d’u frag e t de pro essus

Le fragment de processus A est duplier dans le schema S0
S
to0another B
A + + D Evolution
du schéma
C
S1 B
A + + D
C A
Parallélisassio s d’u frag e t de pro essus

La parallélisassions d’un fragment de processus dans le schéma S0
S0
A B C D Evolution
du schéma
S1 B
A + + D
C
Table 2.2 Opérations complexes de changement.
D'autres patrons de changement sont détaillés dans le travail de (Weber, Reichert, &
Rinderle-Ma, 2008).
2.4.3 Les propriétés de changement

Un changement de processus métier a, selon (Regev, Soffer, & Schmidt, 2006), quatre
propriétés:
- 63 -
2.4.3.1 L’ampleur du changement "Extent of change"

Un changement peut être incrémental ou révolutionnaire. Un changement incrémen-
tal représente des odifi atio s ui s’appli ue t sur un schéma de processus métier exis-
tant. Ta dis u’u ha ge e t olutio ai e e p e d pas e o sid atio l’e ista t
mais crée un nouveau schéma de processus. Ce qui est le cas en général, puisque les ex-
perts métier sont tenus de faire souvent des changements révolutionnaires.
2.4.3.2 La durée du changement "Duration of change"
Le changement peut être temporaire ou permanent. Un changement temporaire n'est
valable que pour une période limitée, ce qui implique un retour au schéma de départ
après la fin d’u e échéance. Un changement permanent est valable jusqu'au prochain
changement prévu.
2.4.3.3 La rapidité du changement "Swiftness of change"
Un changement doit être immédiatement pris en compte ou en différé, un change-
ment immédiat répond g ale e t à u e situatio d’u ge e, il est appli u à toutes
les i sta es d’u p o essus, et e à celles en cours d’e utio . Un changement dif-
f ’est appli u u’au i eau des ou elles i sta es du processus. Les instances en
cours d'exécution restent inchangées, ce qui implique une coexistence de différentes ver-
sions d'un même schéma de processus.
2.4.3.4 L’anticipation du changement "Anticipation of change"
L'anticipation du changement représente le fait de savoir si un changement est planifié
ou ad-hoc. Un changement ad-hoc est souvent appliqué pour faire face à des situations
exceptionnelles. Ta dis u’u ha ge e t pla ifi ou p u fait partie souvent d'une
refonte totale ou pa tielle d’u processus. Ces changements peuvent être liés à différents
niveaux d'abstraction et peuvent être soit temporaires ou permanentes.
Il e iste u e a i t d’app o hes et de te h i ues pe etta t d’i t g e et de g e
des changements des processus métier et cela même du a t l’e utio de leurs ins-
tances, da s le este de ette se tio , ous faiso s u tou d’ho izo des t a au e ista t
dans la littérature.
2.4.4 Techniques d'évolution

Ces techniques permettent de définir la façon dont la définition du processus métier
ou ses instances vont évoluer. Il existe plusieurs approches permettant cette évolution
do t o disti gue a l’app o he ad-hoc, l’app o he pa d i atio , l’app o he pa h itage,
l’app o he pa i du tio , l’app o he pa fle io et l’app o he à ase de gles.
2.4.4.1 L’approche ad-hoc
Cette approche concerne les changements non prévus pouvant découler de la nécessi-
t de odifie le o po te e t d’u p o essus tie du a t so e utio (Agostini &
De Michelis, 2000), (Rinderle, Reichert, & Dadam, 2003) , (Dellen, Maurer, & Pews, 1997).
Cela sous-e te d do ue es ha ge e ts affe te t les i sta es d’u p o essus é-
tier.
- 64 -
Cake2 (Minor, Schmalen, Koldehoff, & Bergmann, 2007), WASA2 (Weske, 2000),
ADEPT2 (Reichert, Rinderle, Kreher, & Dadam, 2005) sont des outils permettant de pren-
dre en charge ce type de changement ad-hoc comme par exemple l’ajout, la suppression
ou encore le d pla e e t d’u e activité ou d’u f ag e t d’a ti it s au niveau des ins-
ta es d’u p o essus tie .
2.4.4.2 L’approche par dérivation
Dans cette approche, le schéma de processus cible du changement est connu, mais le
problème qui se pose est de migre les i sta es de l’a ie s h a e s le ou eau
schéma. Cela nécessite souvent un modèle de transition appelé également modèle
"bridge".
Des travaux comme ceux de (Kradolfer & Geppert, 1999), (Sadiq & Orlowska, 1999),
(Weske, 2001) offrent quelques solutions à cette problématique en se basant sur
l’approche dite de dérivation.
2.4.4.3 L’approche par héritage
Cette approche exploite le concept d'héritage connu dans la modélisation orientée ob-
jet afin de l'étendre à la définition des modèles de processus métier génériques.
Chiu et al. (Chiu, Li, & Karlapalem, 2001), proposent une méta-modélisation orientée
objet étendue afin de p e d e e o pte la fle i ilit et l’adapta ilit des workflow ainsi
que la gestion des exceptions. Les auteurs Dą o ski, D a ik, Trzaska, & Subieta, 2011)
présentent l'idée d'un système orienté objet de gestion de workflow déclaratifs. Un pro-
tot pe est is e œu e su la ase de ODRA13, qui est un SGBD distribué orienté objet,
et SBQL14 qui est un langage de requêtes conçu et mis e œu e pou ODRA.
Rajabi et al. (Rajabi & Lee, 2010), p opose t d’utilise u seau de Petri colorié orien-
té objet "OOCPN" pour la modélisation et l'analyse du changement des processus métier.
Ils visent à intégrer des processus métier modélisés en utilisant des diagrammes
d’a ti it s UML et les seau de Petri coloriés et cela afin de prendre en considération
les changements dynamiques du processus pendant leurs exécutions.
Des travaux similaires qui utilisent la même approche orientée objet sont proposés par
(van der Aalst W. , 2001), (van der Aalst, Basten, Verbeek, Verkoulen, & Voorhoeve,
1999).
2.4.4.4 L’approche par induction
Le principe de cette approche consiste à extraire le schéma du processus métier par le
"process mining" à pa ti des t a es d’e utio s "traces logs" de ses instances (Herbst,
1999). Le but étant d'adapter ce dernier à l’exécution précédente de ses instances, et cela
à l'aide d'un mécanisme d'apprentissage inductif. Aut e e t dit, il s’agit d’i t g e les
adaptatio s ui o t t appo t es au i sta es, suite pa e e ple à l’o u e e de as
exceptionnels, comme des modifications permanentes au niveau du schéma du proces-
sus.
13
http://code.google.com/p/odra3/
14
http://www.sbql.pl/
- 65 -
Des outils tels que ProM (van Dongen, de Medeiros, Verbeek, Weijters, & van der
Aalst, 2005), EMiT (van der Aalst & Van Dongen, 2002), Little Thumb (Weijters & van der
Aalst, 2003), et MinSon (van der Aalst & Song, 2004) permettent une extraction des con-
naissances à partir des jou au d’e utio s des i sta es d’u processus métier "Pro-
cess Event Logs".
2.4.4.5 L’approche par réflexion
Cette approche propose de concevoir des schémas de processus qui ont la capacité de
contrôler et de modifier leur propre comportement, automatiquement ou par l'interven-
tion de l'utilisateur. Cela est réalisé sur la base des "feed-backs" sur les instances comme
décrit dans les travaux de (Borghoff, Bottoni, Mussio, & Pareschi, 1997).
2.4.4.6 L’approche à base de règles
Cette approche propose de modéliser la logique du processus par un ensemble de
règles en utilisant des langages déclaratifs et ela afi d’off i des processus métier
flexibles. L’e utio de ces langages est souvent assu e pa des oteu s d’i f e e de
gles ui d te i e t l’o d e d’e utio des a ti it s e fo tio de l’ aluatio des
conditions. Cela permet une évolution des instances du processus métier basée sur des
événements survenant au cours de leurs exécutions (Klein & Dellarocas, 2000), (Sadiq &
Orlowska, 1999).
Selon plusieurs travaux, (Knolmayer, Endl, & Pfahrer, 2000) et B , E ke t, Păt â ja ,
& Romanenko, 2006), les règles de réaction ECA "Event-Condition-Action" sont les mieux
adaptées pour décrire la logique du processus par un ensemble de règles. Giurca et al.
dans (Giurca, Lukichev, & Wagner, 2006), justifient cela par le fait que le formalisme ECA,
sur lequel se ase t les gles de a tio , pe et de sp ifie le flu de o t ôle d’u
p o essus d’u e a i e fle i le e utilisa t les e e ts.
Une plate-forme appelée AgentWork est proposée par Müller dans (Müller, Greiner, &
Rahm, 2004) où un ensemble de règles ECA qui régissent le fonctionnement des diffé-
rents agents permet la gestion temporelle de Workflow. Le travail de Zeng et al. dans
(Zeng, Ngu, Benatallah, & O'Dell, 2001) proposent par ailleurs de voir le processus
comme un ensemble de tâ hes oo do es e t e elles pa des gles ECA et d’utilise les
agents pour encapsuler les services qui exécutent les tâches du processus. D’aut es tra-
vaux utilise t d’aut es fo alises de gles basés sur des contraintes comme dans
(Rinderle, Reichert, & Dadam, 2004) où les auteurs proposent une approche formelle ba-
sée sur la notion de contraintes de processus appelée "Constraint-Based Flexible business
process management" permettant de démontrer comment la spécification de sélection et
l'ordonnancement des contraintes peut conduire à une plus grande flexibilité dans l'exé-
cution des processus, et cela tout en maintenant un niveau élevé de maîtrise.
DECLARE (Pesic, Schonenberg, & van der Aalst, 2007) est un prototype de WFMS qui
utilise un langage déclaratif de modélisation des processus à base de contraintes formu-
lées en logique temporelle pour le d eloppe e t et l’exécution des modèles de proces-
sus métier.
PLMflow (Zeng, Flaxer, Chang, & Jeng, 2002) est un framework qui fournit un ensemble
de règles d'inférence conçu pour générer et exécuter dynamiquement des workflow. La
définition du processus est spécifiée dans la règle de gestion, qui comprend deux types de
- 66 -
règles, les règles en chaînage arrière "backward-chain rules" et les règles en chaînage
avant "forward-chain rules". L’e utio des i sta es de p o essus est guidée par un
moteur de règles non déterministe qui utilise une combinaison de ces règles.
2.4.5 Techniques de migration

La technique de migration permet de définir ce qui se passe avec les instances en cours
d’e utio et do t la d fi itio du processus à été modifiée. Il existe plusieurs approches
permettant cette migration parmi elles on distinguera l’app o he par annulation,
l’app o he avec p opagatio et l’app o he sa s p opagatio .
2.4.5.1 L’approche par annulation
Les instances e ou s d’e utio affectées par le changement sont annulées et de
nouvelles instances sont créées en fonction de la nouvelle définition de processus. Cette
technique est la moins recommandée en raison de la perte d'information et de temps
(Kradolfer & Geppert, 1999).
2.4.5.2 L’approche sans propagation
Les instances en cours continuent leurs exécutions o fo e t à l’a ie e d fi i-
tion de processus métier tandis que les nouvelles instances sont exécutées selon la nou-
velle définition ou version du processus métier. Ceci implique une coexistence de diffé-
rentes versions d'un même schéma de processus métier.
En effet, la propagation de la modification des instances peut être différée. Autrement
dit, les instances sont exécutées conformément à l'ancienne définition de processus jus-
qu'à ce qu'ils atteignent un état sûr.
Dans (Weske, 1998), l'auteur propose une modélisation et une exécution flexible des
différentes activités du workflow basée sur un méta-modèle métier. Cette approche
prend en charge les changements dynamiques telles que l'ajout ou la suppression d'activi-
tés, mais exige que l'activité ne soit pas en état de fonctionnement durant l’i t g atio du
changement.
Cette stratégie est également utilisée aussi dans l’outil Milano proposé dans le travail
de (Agostini & De Michelis, 2000) ou e o e l’outil Wasa2 proposé dans le travail de
(Weske, 2001).
2.4.5.3 L’approche avec propagation
Le changement au niveau du schéma de processus métier est propagé aux instances en
ou s d’e utio . Il s'agit de la technique la plus complexe car elle nécessite un modèle
de transition permettant la conformité des instances actuelles avec la définition du pro-
cessus cible (Rinderle, Reichert, & Dadam, 2003), (Kradolfer & Geppert, 1999).
Casati et al. (Casati, Ceri, Pernici, & Pozzi, 1996), présentent un langage de gestion du
changement des workflow appelé "WFML" pour répondre à la question de la migration
des i sta es e ou s d’e utio quand la définition du processus métier évolue. Ils
présentent un ensemble de critères formels permettant de déte i e l’e se le des
instances qui peuvent migrer en toute sécurité vers la nouvelle version du schéma de
processus métier. De la même manière, (Zhao & Liu, 2013) proposent un mécanisme de
- 67 -
gestion de versions pour les différents schémas du processus métier en représentant les
différents schémas de processus métier et les dépendances.
ADEPTflex (Reichert & Dadam, 1998), (Rinderle, Reichert, & Dadam, 2004) est un mo-
dèle de workflow graphique connu pour son intégration des changements d’u e faço
dynamique et fluide, et ela e du a t l’e utio de ses i sta es sa s pe d e le on-
trôle et la cohérence structurelle de ces instances. Il propose une politique migratoire qui
est liée à la gestion des conflits potentiels qui peuvent être causés par ces changements.
2.4.6 Techniques de flexibilité

Cette technique est appliquée au cours de la modélisation des processus métier afin
de ett e e œu e des d fi itio s de processus métier flexibles qui pourraient être affi-
nées lors de la phase d'exécution. Il existe plusieurs approches permettant cette flexibili-
té. Parmi elles, on notera l’app o he pa sélection tardive et l’app o he pa od lisatio
tardive.
2.4.6.1 L’approche par sélection tardive "Late binding"
Dans cette approche, les différents éléments du processus métier sont considérés
o e des o jets do t le o po te e t est d fi i lo s de la phase d’e utio , e ui
implique u’au u changement n'est nécessaire sur le schéma du processus métier, mais
un large choix d’alte atives d'exécution est disponible durant cette phase (Dellen,
Maurer, & Pews, 1997). Ceci inclut la capacité de sélection de la meilleure ressource ou
de l’acteur le plus approprié pour réaliser une activité qui doit satisfaire un critère donné.
Un exemple de cette approche est présenté dans le travail de (Belhajjame, Vargas-
Solar, & Collet, 2001) qui consiste à fournir un outil appelé "AFLOWS" qui offre la possibi-
lité d’asso ie la même définition de processus à un comportement différent des proces-
sus en fonction du contexte d'exécution.
2.4.6.2 L’approche par modélisation tardive "Late modeling"
Dans cette approche, certaines parties du processus métier sont laissées ouvertes à
l'innovation et à la créativité des utilisateurs, en particulier lorsque certaines spécifica-
tions ne peuvent pas être identifiées par avance dans la phase de modélisation. Autre-
ment dit, certaines activités peuvent être déclarées comme critiques et obligatoires, tan-
dis que d'autres pourraient être optionnelles et omissent que durent la phase
d’exécution.
Dans (Klingemann, 2000) plusieurs comportements peuvent être associés à des activi-
tés où l’utilisateu peut sélectionner le comportement le plus approprié d'une manière
dynamique. Dans la même optique, les travaux de (Kradolfer & Geppert, 1999), offrent à
l'utilisateur la possibilité de sélectionner les performances appropriées pour une activité
qui a été initialement définie comme un objectif à atteindre. Si aucune méthode existante
’est appropriée, il est également possible d'en créer une nouvelle dynamiquement.
- 68 -
2.5 Conclusion
Dans ce chapitre, nous avons vu que la vérification des processus métier a pour but de
o t e ue les a ti it s du p o essus s’e ute t e o fo it à son plan de réalisa-
tio et u’elles ’o t pas i t oduit d’erreurs. Pour cela, plusieurs techniques sont propo-
sées dans la littérature. Généralement, la technique de vérification par réseaux de Petri
est la plus utilisée et cela est dû à la nature de ce formalisme qui est à la fois, formel et
graphique permettant ainsi une représentation g aphi ue a e l’aspe t s a ti ue att i-
bué au comportement du processus modélisé.
Nous a o s aussi is e e e gue l’i po ta e de l’intégration et la gestion des chan-
gements des processus métier en présentant les différentes techniques et approches qui
existent dans la littérature pour faire face à cette problématique. Au préalable de ce tour
d’ho izo , ous a o s d’a o d présenté une typologie des changements des processus
métier, suivie de la typologie des opérations et des propriétés de ces changements.
Dans le chapitre suivant, nous allons présenter le premier axe de notre contribution
qui consiste à vérifier la cohérence des processus métier en utilisant le Model-checking.
Cette même technique est utilisée pour vérifier les règles dites de conformités.
- 69 -
- 70 -
CHAPITRE
3
La Vérification des modèles de pro-
cessus métier par le Model Checking
3. La vérification des processus métier par le model checking
3.1 Introduction
Les réseaux de Petri demeurent parmi les formalismes les plus utilisés pour la vérifica-
tion formelle des processus métier. Ce formalisme occupe, en effet, une place prépondé-
rante en dépit de ses limites (cf. chapitre 2), et se trouve être l'outil le plus largement
étudié si l'on considère la diversité des techniques automatiques de vérification qui lui
sont associées. Nous pouvons distinguer trois techniques principales permettent la
preuve formelle des bonnes propriétés d’u od le de système. Ce sont la vérification
basée sur les preuves de théorèmes, la vérification basée sur les équivalences, la vérifica-
tion basée sur le model-checking.
La première approche, basée sur les preuves de théorèmes, a pour principe de poser
un ensemble d'axiomes qui servent à prouver un ensemble d'assertions ou de propriétés
déterminant ainsi la conformité du système. Cette technique n'est que peu automatisée
et nécessite souvent une intervention humaine. Cependant, des outils d'aide à la preuve
existent mais demandent une forte expertise humaine et une disponibilité des ressources
machine puisque ces algorithmes induisent une forte consommation de ressources de
calcul. Toutefois, ce type de vérification est rarement employé, il est utilisé essentielle-
ment dans le domaine des spécifications algébriques et logiques (Pnueli, 1979).
La deuxième approche consiste à trouver une équivalence entre le modèle de descrip-
tio d’u e i pl e tatio d’u s st e et u e sp ifi atio de e s st e. Il s’agit do
d’ide tifie u e elatio de i-similarité entre ces deux modélisations qui sont décrites
par un même formalisme (Milner, 1999). L’ ui ale e des deu od les prouve que
l’i pl e tatio est o fo e à la sp ifi atio . Cette te h i ue a u d faut, qui peut se
résumer dans la consommation conséquente de temps pour obtenir des résultats, et cela,
même pour prouver des exigences d'exactitude simples.
La troisième approche qui représente une des plus puissantes méthodes formelles en
te es d’effi a it et d’auto ati it est le "model-checking" appelée aussi la vérification
sur modèle. Cette méthode représente une technique de vérification automatique des
systèmes dynamiques, permettant de déterminer ainsi si un modèle donné d'un système
satisfait une spécification. Les modèles de système utilisés par les model-checkers sont
généralement des modèles de type états/transitions, tandis que les modèles des proprié-
tés sont généralement des formules de logique temporelle.
En effet, le principe de cette vérification sur modèle consiste à générer tous les états
possi les d’u s st e dans lesquels la propriété à vérifier est testée de façon exhaustive
sur l'ensemble des exécutions possibles du système. Par exemple, pour démontrer l'ab-
sence d'erreurs à l'exécution, on pourra tester l'absence d'états d'erreur dans l'ensemble
des états accessibles du système. Il s'agit alors d'une forme de test exhaustif, mais mené à
l'aide d'algorithmes astucieux permettant d'énumérer tous les états du système sous une
forme symbolique. E e a he, l’i o ie t ajeu de e t pe de ifi atio est la
taille souvent excessive de l'espace d'états (le système de transition) énumérés pour véri-
fier la validité d'une propriété. En effet, elle peut être exponentielle par rapport à la taille
de la description du système ce qui conduit rapidement à un dépassement des capacités
de l'ordinateur en matière de mémoire. Une des causes principales de cette explosion
combinatoire du nombre d'états est le fait que l'exploration est réalisée en prenant en
compte tous les entrelacements possibles d'évènements concurrents.
- 72 -
Par conséquent, et en dépit de ces inconvénients qui sont en partie résolus par les tra-
vaux de (Holzmann, 1997), (Burch, Clarke, Mcmillan, Dill, & Hwang, 1990) la vérification
formelle basée sur le model-checking reste le meilleur choix à faire puisque la vérification
est complètement automatique et un contre-exemple est fourni au cas où la propriété
serait violée.
Fort de ce constat, un ensemble de travaux de recherche ont essayé de tirer profit de
l’utilisatio du odel-checking afin de vérifier la validation des processus BPEL, des pro-
cessus workflow et des processus métier. En effet, dans (Fisteus, Fernández, & Kloos,
2004), (Nakajima, 2006), les auteurs proposent une approche permettant la vérification
et la validation d'une orchestration de services web spécifiée avec BPEL pour s'assurer de
sa consistance et d'éviter les changements inattendus. Cette approche permet de vérifier
un ensemble de propriétés génériques, telles que la vivacité et la sûreté, et spécifiques en
utilisant le model-checker SPIN avec son langage d'entrée PROMELA.
Dans (Feja, Speck, & Pulvermüller, 2009), (Speck, Feja, Witt, & Pulvermüller, 2011 ) les
auteu s p opose t l’utilisatio du odel-checking pour vérifier un ensemble de règles
dans les processus métier modélisés par les diagrammes EPC. En effet, dans cette vérifica-
tio l’ensemble des règles est exprimé en CTL (Wolfgang, 1989) à travers une notation
graphique appelée G-CTL "Graphical Computationnal Temporal Logic", tandis que, les dia-
grammes EPC à vérifier sont traduits en structure de kripke afin que les deux soient utili-
sées comme entrée pour le model-checker.
Dans un autre registre, Vaz et Ferreira (Vaz & Ferreira, 2007), (Vaz & Ferreira, 2007)
proposent de vérifier l’e a titude des processus workflow et le comportement des pro-
cessus métier basés sur les services web par le model-checker SPIN. Dans ces travaux, les
auteurs proposent de traduire une collection de patterns de workflow en code Promela.
Cette traduction est illustrée par deux processus métier basés sur les services web.
Dans la continuité de ces travaux, l'approche proposée dans ce chapitre consiste à uti-
liser la technique du model-checking pour vérifier les propriétés de cohérence des pro-
cessus métier modélisés en BPMN. En effet, notre approche permet tout d'abord de tra-
duire un modèle BPMN en modèle Promela. Cette traduction se fait en deux phases. La
première phase, consiste à transformer le modèle BPMN vers une structure de kripke
comme représentation intermédiaire et cela, afin de donner une sémantique formelle à
ces modèles, et par conséque t l’e se le des e utio s de e système. La deuxième
phase consiste à traduire cette structure de kripke vers un code Promela.
En second lieu, nous exprimons en Logique Temporelle Linéaire (LTL) les différentes
propriétés de cohérence des modèles de processus métier et nous utilisons le model-
checker SPIN pour tester si chaque propriété de cohérence est satisfaite par le modèle
Promela du modèle BPMN en question.
Da s le as d’u e po se gati e, SPIN fou it u contre-exemple montrant une
exécution qui ne satisfait pas ces propriétés. De la même manière, cette approche est
utilis e afi de ifie la o fo it des p o essus tie a e l’e se le des gles de
conformité suite à un changement affectant l'un des deux.
La suite de ce chapitre est organisée comme suit : nous commençons par présenter
dans la section 3.2 les notions fondamentales du model-checking ainsi que le principe de
son fonctionnement. Dans la section 3.3, nous présentons le model-checker SPIN qui est
- 73 -
l’outil utilis pou i pl e te et valider notre approche. Les erreurs structurelles et le

détail de notre approche sont relatés dans la section 3.4 et 3.5. Ensuite, nous détaillons
dans la section 3.6 la description des processus métier à vérifier en langage Promela. En-
fin, dans la section 3.7, nous étendons cette approche à la vérification des règles de con-
formité mises en place suite à un changement du modèle de processus métier.
3.2 Le model-checking
3.2.1 Principe du model-checking
Le model-checking (Clarke Jr., Grumberg, & Peled, 1999), (Biere, 2008) ou la vérifica-
tion de modèle est reconnu comme étant l'une des méthodes formelles les plus puis-
santes et la plus utilisée. En effet, le model-checking est une méthode de vérification ex-
haustive basée sur des modèles mathématiques permettant l'analyse des systèmes réac-
tifs qui présentent un comportement aléatoire ou probabiliste. Cette vérification utilise
un algorithme qui explore exhaustivement l'ensemble des exécutions possibles du sys-
tème. Le nombre des états générés par ce modèle peut être exponentiel, les outils de
model-checking actuels peuvent énumérer explicitement des espaces d'états contenant
1020 états (Burch, Clarke, Mcmillan, Dill, & Hwang, 1990).
Le principe du model-checking consiste à générer toutes les exécutions possibles d'un
système et de vérifier ses caractéristiques comportementales, en s'assurant que les pro-
priétés spécifiées telles que l'absence de blocage "deadlock" sont vérifiées dans chaque
exécution et donc dans chaque état du modèle.
Pour ce faire, le model-checker prend en entrée une abstraction du comportement du
système réactif ou système de transition et une formule d’u e logi ue te po elle et i-
fie si l’a st a tio satisfait la fo ule cf. figu e . . L’a st a tio du o po te e t du
système peut être exprimée en utilisant des structures de Kripke (Browne, Clarke, &
Grümberg, 1988) ou d'autres modèles tels que les réseaux de Petri, les automates finis,
les automates temporisés, etc. Les formules de logique temporelle peuvent être expri-
mées en utilisant LTL (Rozier, 2011) , en PLTL (Laroussinie & Schnoebelen, 1995), en CTL
(Wolfgang, 1989), en CTL* (Schneider & Prof.Dr Schmid, 1997), ou TCTL (Bel Mokadem,
Bérard, Bouyer, & Laroussinie, 2006), etc. Le système de transition est dit modèle de la
formule, d’où le terme vérification de modèle.
A l'issue de cette vérification, si une propriété n'est pas satisfaite, un contre-exemple
est fourni permettant ainsi d'identifier un cas d'exécution non conforme et ainsi localiser
et corriger la source d'erreur. Ce contre-exemple peut être obtenu dès l'instant où la pro-
priété à vérifier n'est pas satisfaite durant l'exécution, ce qui permet une vérification plus
rapide qu'avec les techniques traditionnelles et cela en plus du fait que celle-ci soit auto-
matique.
- 74 -
Figure 3.1 Principe du model-checking.
Il e iste plusieu s at go ies de p op i t s u’un model-checking permet de vérifier.

Ce sont notamment:
 Les propriétés d'accessibilité comme par exemple « il existe un état accessible où x
vaut 0 ».
 Les propriétés d'invariance ou de sûreté comme par exemple « durant toute l'exé-
cution, x est différent de 0 ».
 Les propriétés de vivacité comme par exemple « l'application se terminera finale-
ment ».
Ces propriétés sont détaillées ci-après. Enfin, il existe également plusieurs model-
checkers puissants tels que SPIN (Holzmann, 1997), (Holzmann, 2003), NuSMV (Cimatti A.
, Clarke, Giunchiglia, & Roveri, 2000), (Cimatti A. , et al., 2002) ou BLAST (Henzinger, Jhala,
Majumdar, & Sutre, 2003).
3.2.2 Système de transitions

Le model-checking étudie des systèmes réactifs abstraits exprimés syntaxiquement
sous la forme de a hi es à tats. La s a ti ue d’u e a hi e à tats est do e pa
un système de transitions. Ces machines à états peuvent être plus ou moins complexes,
allant des machines à états finis (automates finis) à de vrais programmes (machines de
Tu i g . Cepe da t, plus le fo alis e d’e t e est puissa t, oi s o peut d ide de
leurs propriétés de façon automatique.
En effet, pour vérifier toutes les exécutions possibles d’un système lambda, on doit re-
présenter son modèle sous la forme d'un système dit « système de transitions à états »,
où chaque état correspond à un état du système étudié, à chaque pas d'exécution et à
chaque transition correspondant à une évolution possible d'un état donné vers un autre,
selon l'action exécutée par le système. Ce système de transition ou automate au sens
large, est un modèle de machine abstraite qui est utilisée en théorie de la calculabilité et
dans l'étude des langages formels. Il peut être représenté par un graphe orienté, une
machine de Turing ou encore un réseau de Petri comme souligné précédemment.
- 75 -
Un système de transitions S est un quadruplet S = (Q, I, T,) tel que :



Q est l'ensemble des états ou des configurations.
I est l'ensemble des états initiaux tel que I ⊆ Q.


T est l'ensemble des transitions-actions
 ⊆ Q X T X Q est la relation de transition.
Dans ce qui suit, on utilisera la notation q 
t
pour désigner le fait que q est en rela-
tion avec au lieu de la notation , t, ∈ .
Une action-transition t ∈ T est dite exécutable si et seulement si, il existe deux états q,
∈ Q tels que q  .
t
Une exécution de S est une séquence infinie = q0, q1, ...,qn d'états qi ∈ Q tels que q0 ∈
I et pour tout i ∈ , il existe (qi, Ti, qi+1) ∈ pour un certain Ti ∈ T. Un état q ∈ Q est dit
accessible si qi = q pour une certaine exécution = q0, q1, ...,qn de S.
Pour un model-checking on va considérer des structures de kripke , plutôt que des
systèmes de transitions S. En effet, un système très similaire mais pas identique à la no-
tion de système de transition, appelé structure de kripke, est utilisé par le model-checking
pour représenter le comportement d'un système. La différence entre les deux concepts
qui sont similaires réside da s le fait u’u s st e de t a sitio est p ati ue pou odé-
liser des systèmes, tandis que la structure de kripke est plus commode pour définir la lo-
gique temporelle dans le model-checking. De plus, l'ensemble des transitions-actions T
qui existe dans le système de transitions est supprimé comme expliqué ci-après car on ne
s'intéresse qu'à des propriétés sur les suites d'états visitées plus que les transitions-
actions qui se produisent dans ce système, puis u’o attribue des propriétés atomiques
aux états du système.
3.2.2.1 Structure de kripke
Une structure de kripke (Kripke, 1963) est une variante des automates non-
déterministes utilisée dans le model-checking pour représenter le comportement d'un
système. Elle est considérée comme une structure, do t les œuds ep se te t les états
atteignables du système et les arcs les transitions d'état.
La fonction de marquage "Labeling function" marque chaque œud par un ensemble
de propriétés atomiques qui doivent être valides dans l'état correspondant comme le
montre la figure 3.2.
La sémantique de cette structure est basée sur des logiques temporelles pour la plu-
pa t des la gages de sp ifi atio les plus la ge e t utilis s da s le ad e de l’ tude des
systèmes réactifs.
Une structure de kripke sur un ensemble de variables propositionnelles AP est un qua-
druplet = ( , I, , ) tel que :


Q est l'ensemble fini des états.
I est l'ensemble des états initiaux tel que I ⊆ Q.
 R ⊆ Q x Q est une relation de transition qui vérifie: q ∈ Q, ∈ Q tel ue , ∈
R.
- 76 -
 : Q  2AP est une fonction d'étiquetage ou de labellisation des états qui définit
pour chaque état q ∈ Q. l'ensemble (q) de toutes les propositions atomiques qui
sont vraies dans q.
Figure 3.2 Un exemple de structure de kripke.
Pour vérifier tous les chemins d'exécutions possibles du système, il est utile de déplier
cette structure afin d'obtenir un arbre infini dont la racine est l'état initial de la structure,
et chaque œud de l'arbre a pour successeurs ceux obtenus par la relation de transition
R.
3.2.3 Les propriétés vérifiées par le model checking

Les p op i t s les plus si ples et les plus i po ta tes u’o puisse ifie pa le o-
del- he ki g so t elles d’a essi ilit , d’i a ia e ou de sû et telle que « durant toute
l'exécution, x est différent de 0 » ou encore de vivacité telle que « l'application finit par se
terminer ».
3.2.3.1 Propriété d’atteignabilité " Reachability"
L’atteig a ilité ou l’accessibilité représente le fait u’u e e tai e situatio peut t e
atteinte. On dira que dans une propriété d’atteig a ilit "Reachability property" on teste
si un ensemble de mauvais états A peut être atteint comme le fait « u’il existe un état
accessible où x vaut 0 ». Ce type de propriété doit donc être vérifié et satisfait à chaque
étape de l'exécution du système.
3.2.3.2 Propriété de sûreté "Safety"
On définit informellement la propriété de sûreté "Safety property" comme celle stipu-
lant que « uel ue hose de au ais ’a i e ja ais ». Dans le cas où la propriété de sû-
reté est violée, on obtient un contre-exemple fini, c.à.d. une exécution finie qui viole la
propriété. Ainsi, l’i a ia e est u as pa ti ulie de sû et , Pa e e ple, « une variable
n'est jamais égale à 0», « le système n'a pas de deadlock ». Ce type de propriété doit donc
être vérifié et satisfait à chaque étape de l'exécution du système. Pour la vérification de
la p op i t de sû et ou d’i a ia e, il est possi le d'utilise la logi ue te po elle ais
également de simples assertions.
- 77 -
3.2.3.3 Propriété d’équité "Fairness"

U e p op i t d’ uit "Fairness property" permet d’énoncer que sous certaines con-
ditions, quelque chose aura lieu (ou pas) un nombre infini de fois comme par exemple
« la porte sera ouverte infiniment souvent ». On parle aussi de vivacité répétée ou
d’atteig a ilit p t e. Ces diff e tes te i ologies se justifie t pa des utilisatio s
diff e tes d’u poi t de ue thodologi ue. Ce so t des p op i t s ou a tes des s s-
tèmes dès lors que ceux-ci sont obtenus en réalisant le produit de plusieurs automates.
3.2.3.4 Propriété de vivacité "Liveness"
Une propriété de vivacité "Liveness property" exprime le fait que « quelque chose de
bien arrivera finalement ». Il s’agit d’u e p op i t plus fo te ue l’atteig a ilit puis ue
cette dernière i di ue u’il est possi le ue uel ue hose se passe alo s ue la p op i t
de vivacité indique que quelque chose doit se passer. Cela garantit donc qu'une propriété
sera vraie à partir d'un certain état de l'exécution du système.
Ce type de propriété va donc être évalué sur un ensemble d'états représentant un
chemin d'exécution du système. Par exemple, « l'application se terminera finalement » ou
« chaque processus sera finalement en section critique », etc. Dans ce cas, nous travail-
lons donc sur un temps i fi i o t ai e e t à u e p op i t d’a essi ilit ou de sû et .
3.2.3.5 Propriété d’absence de blocage "Deadlock-freeness"
L’a se e de lo age "Deadlock-freeness property" exprime le fait que le système ne
peut pas se t ou e da s u e situatio où il est i possi le d’ olue , si ela ’a pas été
explicitement spécifié. Cette propriété est importante dans le sens où elle constitue une
propriété de correction pour les systèmes supposés ne jamais se terminer, et constitue
u e p op i t de o e tio pou tous les s st es d s lo s ue l’o a sp ifi les tats
fi au d’u s st e.
Pour formuler l’e se le de ces propriétés, il est nécessaire d'utiliser un langage plus
riche permettant d'exprimer le temps infini, comme la logique temporelle. En effet, les
logiques sont des langages de spécification formels qui ont une définition mathématique
précise, ce qui permet d'exprimer les propriétés sans ambiguïté, mais cela permet surtout
la simulation et la vérification automatique du système.
Pour exprimer par exemple les propriétés de vivacité, on utilise des logiques tempo-
relles telles que LTL "Linear Temporal Logic" qui permet de considérer une propriété le
long d'un chemin d'exécution grâce aux connecteurs et non plus sur un seul état. On peut
également utiliser la logique CTL "Computation Tree Logic" dite branchante, qui permet
de prendre en compte les entrelacements des futurs états possibles à un point donné de
l'exécution contrairement à LTL qui est linéaire.
3.2.4 La logique Temporelles Linéaire (LTL)

La Logique Temporelle Linéaire (LTL) (Rozier, 2011) est une des variantes de la logique
formelle pe etta t d’e p i e les fo ules à ifie pa le model-checking. La LTL est
basée sur le calcul propositionnel. Les formules du calcul propositionnel sont composées
de propositions atomiques, des expressions booléennes, des opérateurs logiques et des
quantificateurs comme le montre la figure 3.3.
- 78 -
Figure 3.3 Les connecteurs temporels LTL.
La Logique Temporelle Linéaire (LTL) est définie par :

 Un ensemble de propositions atomiques AP : p, q, r, etc.
 Un ensemble de connecteurs logiques portant sur des variables : ┬ (Vrai), ⊥
(Faux), ¬ (Négation), (OU logique), (ET logique , → Implication , ↔ Équiva-
lence).
 Un ensemble de quantificateurs ou connecteurs temporels: G, X;F, U.
Les quatre connecteurs temporels G, X;F et U peuvent être expliqués brièvement,
comme suit :
 G (toujours où "always"): Gp signifie que p est vrai dans toute l'exécution. Le con-
necteur G est représenté graphiquement par : □
 X (prochainement où "next time"): Xp signifie que p est vrai dans l'état suivant le
long de l'exécution. Le connecteur X est représenté graphiquement par : ○
 F (éventuellement où "eventually"): Fp signifie que p est vrai plus tard au moins
dans un état de l'exécution. Le connecteur F est représenté graphiquement par :
◊
 U (jusqu'où "until"): p U q signifie que p est toujours vrai jusqu'à un état où q est
vrai. Le connecteur U est représenté graphiquement par : u
Les opérateurs ○, ◊ et □ sont unaires alors que l'opérateur u est binaire. Les opérateurs
temporels et propositionnels peuvent être combinés dans la même formule LTL. Ainsi les
formules LTL peuvent être sous la forme suivante:
 Toute proposition atomique à savoir p, q est une formule.
 Si ϕ et ψ sont des formules, alors ¬ ϕ, ϕ ψ, ϕ ψ, ϕ → ψ et ϕ ↔ ψ sont aussi
des formules.
 Si ϕ et ψ sont des formules, alors Gϕ, Xϕ, Fϕ et ϕ U sont aussi des formules.
La sémantique d'une formule LTL syntaxiquement correcte est définie en lui attribuant
une interprétation (une assignation des valeurs de vérité, ┬ (vrai), ⊥ (faux)) à ses propo-
sitions atomiques et l'extension de l'assignation à une interprétation de la formule en-
tière en tenant compte des règles associées aux opérateurs. Pour le calcul propositionnel,
ces règles sont définies par les tables de vérité usuelles. Pour la logique temporelle, la
sémantique d'une formule est donnée en termes d'exécutions (calculs) et les états d'une
exécution. Les propositions atomiques de la logique temporelle sont des expressions boo-
léennes qui peuvent être évaluées dans un seul état indépendamment d'une exécution.
- 79 -
3.3 SPIN Model Checker

SPIN model-checker (Mordechai, 2008) a t hoisi à l’o igi e o eu a o e
pou Si ple P o ela INte p ete . C’est u outil ope -source largement utilisé pour véri-
fier et valider les propriétés d'exactitude des systèmes logiciels de grande envergure. Ce
dernier a été développé par Gerard J. Holzmann (Holzmann, 1997), (Holzmann, 2003)
pour vérifier les protocoles de communication. Il a été très utilisé dans les industries qui
réalisent des systèmes critiques.
Les modèles qui doivent être vérifiés par SPIN sont écrits en Promela (PROcess MEta
LAnguage)15, Promela est un langage de spécification de systèmes asynchrones tels que
les systèmes concurrents ou les protocoles de communication qui décrivent le compor-
tement du système. La syntaxe de Promela est proche du langage C enrichi avec des pri-
mitives de communications basées sur des machines à états finis. Ce langage est conçu
pour faciliter la construction de modèles de systèmes distribués en soutenant la spécifica-
tion des structures de contrôle non-déterministe. Il autorise la création dynamique de
processus. La communication entre ces processus peut être effectuée par le partage de
variables globales ou en utilisant des canaux de communication.
Promela permet ainsi de détecter notamment la présence de deadlock, race condition
ou des suppositions injustifiées sur les vitesses relatives de processus. Les propriétés à
vérifier doivent être exprimées en Logique Temporelle Linéaire (LTL).
Un modèle Promela peut être analysé par SPIN, soit par simulation où le modèle est
exécuté étape par étape, ce qui rend plus facile de se familiariser avec son comporte-
ment, soit par vérification où les états du modèle sont explorés de façon exhaustive afin
de vérifier que le modèle satisfait les propriétés spécifiées dans LTL.
En effet, étant données la spécification formelle du comportement du système et la
spécification d'une propriété en logique temporelle, SPIN model-checker vérifie si cette
propriété est satisfaite. Son mode de vérification détermine si le modèle proposé en
Promela satisfait ou non une propriété LTL. Ceci est effectué en menant, si nécessaire,
une vérification exhaustive qui permet de parcourir l'ensemble des exécutions possibles
du système.
Le principe de vérification de SPIN consiste à transformer les processus PROMELA en
structure de kripke à travers une cartographie (en vrac) des processus, des états et des
canaux de communication de Promela vers les états-transitions de la structure de kripke
(Walton, 2005) et les formules LTL en automates de Büchi (Büchi, 1962).
En effet, SPIN transforme, à partir des propriétés spécifiées, leur négation en auto-
mates de Büchi (Büchi, 1962), puis calcule le produit synchronisé de cet automate avec
celui du système c.à.d. la structure de kripke. Le résultat est encore un automate de Büchi
dont on vérifie si le langage est vide ou non. S'il est vide, alors il n'existe aucune exécution
violant la formule de départ, sinon il accepte au moins une exécution.
L'ensemble des transitions pour lesquelles la propriété n'est pas vérifiée forment les
contre-exemples qui peuvent être générés par SPIN en appliquant un algorithme de re-
cherche en profondeur imbriquée (Nested Depth-first Search) sur cet espace d'états. Ces
15
http://spinroot.com/spin/Man/Quick.html
- 80 -
contre-exemples sont censés permettre à l'utilisateur de modifier par la suite son modèle
ou la propriété si elle a été mal exprimée, afin de corriger les erreurs éventuelles.
Avant de détailler notre approche qui consiste à vérifier un des aspects de la cohé-
rence des processus métier qui se résume en la détection de l’a se e des e eu s st uc-
tu elles da s des od les de p o essus tie à l’aide de SPIN, ous allo s o e er
par présenter en détail ces erreurs qui peuvent causer des incohérences fonctionnelles
comme expliqué brièvement dans le chapitre 2.
3.4 Les erreurs structurelles

U p o essus est dit sai ou oh e t s’il e o tie t pas d’a ti it i utile et où ha ue
cas se termine complètement sans laisser de référence à lui-même. Un des aspects de
cohérence des processus métier le plus vérifié par les travaux existants dans la littérature
se a ifeste pa la ifi atio de l’a se e des e eu s st u tu elles.
Dans cette section, nous allons présenter quelques erreurs structurelles qui peuvent
survenir lors de l'exécution des modèles de processus métier. Le te e d’e eu s st u tu-
elles fait f e e au e eu s ui peu e t su e i du a t l’e utio de es od les,
et qui peuvent causer des incohérences fonctionnelles telles que des impasses, des
boucles infinies ou des terminaisons multiples. Ces erreurs sont utilisées pour illustrer
notre approche proposée (Kherbouche, Ahmad, & Basson, 2012), (Kherbouche, Ahmad, &
Basson, 2013) pour garantir la cohérence "soundness" des modèles de processus métier.
3.4.1 L’impasse "Deadlock patterns"

En règle générale, une impasse ou un blocage est défini comme étant un système qui a
atteint un état non-final de non-progression dans son exécution. Pour les modèles de
processus métier, cela correspond au cas où certaines activités ne peuvent pas continuer
à progresser, alors qu'elles n'ont pas atteint la fin du processus. Par conséquent, une im-
passe est une condition utilisée pour décrire une situation où un processus métier ne
peut être terminé.
Selon Onada et al. (Onoda, Ikkai, Kobayashi, & Komoda, 1999), il existe deux concepts
complémentaires qui permettent de détecter une impasse. Le premier est l’atteignabilité
"Reachability" qui est symbolisé par l'existence d'au moins un chemin d’un œud A vers
un œud B dans un processus et le second concept est la transférabilité absolue ou "ab-
solute transferability", qui est un concept plus fort que le premier, et qui permet d'affir-
mer qu'un jeton peut toujours être transféré à partir du œud A à tous les points d'entrée
du œud B. Le blocage se produit, chaque fois qu'il y a accessibilité sans transférabilité
absolue.
Dans le même travail, les auteurs ont également identifié plusieurs causes potentielles
de blocages, comme suit:
 Impasse ou blocage infinis "Loop deadlock": comme indiqué dans la fi-
gure.3.4.a, se produit quand il ya un chemin d'exécution dans lequel la sortie
d'une passerelle AND-Join retourne à nouveau à ses points d'entrée. Dans ce
cas, si le chemin ne contient pas de passerelles XOR-Split, l'apparition de blo-
- 81 -
cage est certaine, sinon il peut se produire si la branche menant à la boucle est
choisie.
 Sources multiples "Multiple sources": comme indiqué dans la figure.3.4.b, les
sources multiples se produisent lorsque deux sources différentes mènent aux
points d'entrée d’u e passerelle AND-Join. En supposant qu'aucun des œuds
sou es ’est une passerelle AND-Join en elle-même, on peut observer que les
sources multiples peuvent se produire lorsque l'une des structures de proces-
sus est la suivante:
o L'une des deux sources est une passerelle XOR-split.
o Un processus avec multiples événements de début qui seront synchro-
nisés plus tard par une passerelle AND-Join. D'où on peut en déduire
qu'il existe une accessibilité entre deux ou plusieurs sources pour le
œud AND-join.
o Une structure impropre comme le montre la figure 3.4.d, représente le
fait d’u e passe elle AND-Join reçoit comme entrée un chemin qui
passe par une passerelle XOR-Split
Figure 3.4 Les erreurs structurelles dans les modèles BPMN.
3.4.2 Boucles infinies "Livelocks patterns"

Une boucle infinie ou "Livelock" peut être définie comme étant un état à partir duquel
il est possible de procéder, mais impossible d'atteindre l'état final désiré (le système est
verrouillé dans un petit sous-e se le d’ tats et e p og esse pas . Co e le o t e la
figure.3.4.d, une boucle peut entraîner une exécution infinie du processus. Dans ce cas,
e tai s p o essus peu e t s'e ute a e su s, ta dis ue d’aut es peu e t t e da s
une boucle sans fin d'exécution. Un exemple de cette situation peut se produire quand
une passerelle AND-Split est utilisée à la place d'une passerelle XOR-Split pour modéliser
une boucle existante.
- 82 -
3.4.3 Terminaison multiples "Multiples terminations patterns"

Les multiples terminaisons correspondent à des situations où il existe une passerelle
AND-Split avant une passerelle XOR-Join, comme représenté sur la figure.3.4.e. Dans ce
cas, une seule séquence est traversée lorsque la passerelle XOR-Join est exécutée, ce qui
conduit à la violation du critère de cohérence. Ainsi, le modèle de processus BPMN ne
te i e a pas l’e utio du p o essus, correctement et dans la façon attendue.
3.5 La vérification des modèles de processus métier basée sur le

model-checking
Afin de vérifier notre modèle de processus métier, nous avons à décrire en LTL
l’e se le des propriétés qui doivent être utilisées par le model-checker pour détecter
d’ e tuelles e eu s st u tu elles et d’assu e ai si de la cohérence de ce dernier. Mais
avant une telle description, il faut proposer une structure de kripke représentant le com-
portement de ce modèle qui est nécessaire pour la vérification de ces propriétés comme
soulevé précédemment.
Notre approche est décrite dans la figure. 3.5. L'idée principale est de cartographier les
différents éléments qui constituent un modèle de processus métier exprimé en BPMN en
structure de kripke dans un but de spécifier le comportement de ce dernier, et de lui at-
tribuer ainsi une sémantique formelle.
Figure 3.5 Vérification des modèles de processus métier basée sur le model-checking.
Plusieurs propriétés LTL peuvent être définies simultanément pour une structure de
kripke. Les étapes de vérification sont détaillées comme suit :
3.5.1 Génération de l’automate à états finis

La première étape consiste à cartographier les modèles de processus BPMN en struc-
ture de kripke pour exprimer le comportement de ces derniers. Cette traduction permet
une meilleure vérification des propriétés temporelles souhaitées telles que: φ(
φ ) si est seulement si , π φ est vérifiée pour tous les chemins
d’e utio s π dans une structure de kripke .
- 83 -
L'e se le o ide de l’auto ate à tats finis S de la structure de kripke représente

l’e se le des œuds N du modèle de processus (N ep se te l’e se le des o jets de
flux du processus BPMN qui peut être partitionné en événements E, activités A et passe-
relles G). Les relations de transition R représentent l’e se le des flu de o t ôle reliant
les différents objets de flux du processus BPMN tel que T ⊆ F × F.
Pour obtenir une structure de kripke, nous définissons AP comme étant l'ensemble des
propositions atomiques associées à chaque état s ∈ S tels que (s) est valide "holds" en s
( est la fonction d'étiquetage de la structure de kripke ). Elle exprime toutes les pro-
priétés d'un état s ∈ S.
L'état initial I ⊆ S est le point de départ ES (événement de début) du modèle de pro-
cessus métier. Chaque état s est étiqueté avec des transitions : "activée" ou "exécutée".
E_A signifie que la transition A est activée et ex_A signifie que la transition A est exécutée
(achevée).
Une brève description de la cartographie des principaux éléments du modèle de pro-

cessus BPMN en structure de Kripke est donnée dans la Table.3.1.
Les éléments BPMN Structure de kripke
- 84 -
Table 3.1 La cartographie des éléments de BPMN en structure de kripke.
3.5.2 Formules LTL de la cohérence d'un modèle de processus métier

La cohérence d’u modèle de processus métier et par conséquent l’a se e d’e eu s
structurelles peut être assurée en vérifiant les formules LTL suivantes :
3.5.2.1 Détection de l’absence de blocages
Une structure de kripke est dite être sans blocage "Deadlock-free", si elle ne contient
aucun chemin qui peut conduire à une impasse. Le non-blocage est considéré comme une
propriété de sûreté « quelque chose de mauvais n'arrive jamais ».
Supposons que la formule temporelle Final, représente l'ensemble des états finaux
dans une structure de kripke comme le montre la deuxième ligne, deuxième colonne dans
la Table 3.1. Dans un tel cas, nous pouvons exprimer la propriété de non-blocage par la
formule LTL suivante:
□ ○ ⊥ → Final)
Cette formule doit être considérée comme valide dans chaque chemin. La fo ule ○ ⊥
(signifie qu '«il n'y a pas d'état prochain») est facile à déduire, c.à.d. aucune transition
’est possible. Donc, nous pouvons exprimer la propriété d’accessibilité d'un état de blo-
cage comme étant l'existence d'un état avec la double propriété.
◊ ○ ⊥ → ¬ Final)
- 85 -
3.5.2.2 Détection des boucles infinies

Comme décrit précédemment, la boucle infinie est un état où il est impossible de pro-
gresser jus u'à l’état Final recherché. La propriété qui exprime la non-existence de
boucle infinie est une propriété de vivacité « quelque chose de bien arrive finalement ».
Cette formule peut être exprimée en LTL comme suivant:
◊□ϕ → □◊
Si u e a ti it essaie de s’e uter à l’i fi i, alo s elle sera toujours dans un état d'exé-
cution. Cela peut être simplifié par la formule ¬ ◊ □ φ (c'est-à-dire qu'elle ne réussira ja-
mais à s'exécuter pour toujours). Le contre-exemple de ces propriétés est une exécution
infinie selon laquelle le comportement attendu ne se produit pas (c'est-à-dire le proces-
sus ne se termine pas).
3.5.2.3 Détection des terminaisons multiples
La terminaison multiple est une situation où il existe un AND-Split avant une passerelle
XOR-Join comme vu précédemment. La détection de ce cas est basée sur la vérification de
la propriété de sûreté « quelque chose de mauvais n'arrive jamais ». Il peut être vérifié
par la formule LTL suivante:
□¬ ◊ φ ○ → Final)
Un contre-exemple de ces propriétés est une exécution finie qui conduit à un compor-
tement inattendu.
3.5.3 Model Checking

La structure de kripke et les formules de logique temporelle sont présentées comme
entrée pour le model-checker. Ce dernier vérifie si la formule temporelle Ϭ est satisfaite
par la structure de kripke ou pas. En conséquence, il confirme le bien-fondé du mo-
dèle de processus. Sinon, il renvoie un contre-exemple en cas d'erreurs structurelles.
3.5.4 Déterminer la zone impactée

Le model-checker a la capacité de fournir des contre-exemples dans le cas où les pro-
priétés temporelles à vérifier ne sont pas satisfaites par le modèle de processus (Liu,
Müller, & Xu, 2007), (Foerster, Engels, & Schattkowsky, 2005).
Généralement, ces contre-exemples sont donnés en termes de transitions d'états in-
ternes plutôt qu'en termes de modèles de processus, ce qui les rend difficiles à com-
prendre par un utilisateur non-initié.
Pour bénéficier de ces contre-exemples, cette sortie du model-checker devrait être
traduite dans une notation visuelle, ce qui est plus facile pour l'utilisateur à comprendre.
La transformation de ce contre-exemple vers le modèle de processus BPMN source per-
met de mettre en évidence visuellement les chemins dans un modèle de processus métier
dont l'exécution entraîne des violations.
À cet effet, nous utilisons "Model checker dependency", qui contient une chaîne d'ou-
tils permettant de traduire la sortie du model-checker vers les modèle de processus mé-
tier. Cela peut permettre de faire correspondre chaque état de la structure de kripke vers
- 86 -
l’ l e t du modèle de processus BPMN correspondant, en mettant en évidence la zone

impactée (par une couleur ou un étiquetage particulier), et cela afin de mieux la visuali-
ser. Cette correspondance peut aider à trouver les causes réelles de ces erreurs dans le
modèle de processus métier et de les corriger ainsi.
3.6 La vérification des modèles de processus métier à l'aide de SPIN

Nous présentons dans cette section une méthode, basée sur le model-checker SPIN,
pour implémenter notre approche qui permet la vérification de certaines propriétés de
cohérence d'un modèle de processus métier. Avant d'interroger SPIN, nous proposons
une translation adaptée des travaux de (Vaz & Ferreira, 2007), (Vaz & Ferreira, 2007)
d’u e spécification du modèle de processus métier modélisé en BPMN vers le langage
P o ela et l’illust o s pa u e e ple.
Les processus métier sont traduits en langage Promela en mappant les différents pro-
cessus, les sous-processus, et les activités de ces derniers en processus Promela
"PROMELA processes", et les flux de séquence en canaux de communication Promela
"PROMELA channels". Les flux de message entre les différents processus sont représen-
tés, sans perte de généralité en utilisant des entiers dans Promela.
Dans cette translation nous utilisons quelques variables telles que c pour représenter
un canal de communication, m pour représenter un message (envoyé ou reçu) dans un
canal c qui peut être un entier, un byte, etc. cS désigne un tableau de canaux de com-
munication et mS désigne un tableau de messages à envoyer ou à recevoir dans chaque
canal de cS.
Dans la Table 3.2, nous représentons la traduction des principaux éléments de la nota-
tion BPMN qui sont la séquence, la passerelle AND-Split, la passerelle AND-Join, la passe-
relle XOR-Split, la passerelle XOR-Join, la passerelle OR-Split, la passerelle OR-Join en lan-
gage PROMELA.
Les éléments BPMN Langage Promela

chan c = [1] of {int};
active proctype start(){
/* To start process */
c!1;
}
proctype A(){
/* Details of activity */
c!1; /* Activate process B */
}
proctype B(){
int x;
c?x; /* Waiting token to run */
/* Details of activity */
}
- 87 -
inline ANDSplit(cS, mS){

int ind, length;
ind = 0; length = len(cS);
atomic {
do
::ind <length->cS[ind]!mS[ind]; ind++;
::ind >=length->break;
od;
}
}
inline ANDJoin(cS, mS){
int ind, length;
skip;
S:
if
::full(cS) ->
do
::ind <length && nempty(cS[ind])->
cS[ind]?mS[ind];ind++;
::ind >=length-> break; goto E
od;
:: nfull(cS) -> ind=0; timeout; goto S
fi;
E: skip;
}
inline XORSplit(cS,choice,m) {
int length;
length = len(cS);
if
::(choice<length && choice>=0) -> cS[choice]!m;
:: else -> skip;
fi;
}
inline XORJoin(cS, m){

int ind,length;
ind=0;
length=len(cS);
skip;
B:
if
::nempty(cS[ind])-> cS[ind]?m; goto E
::empty(cS[ind])-> ind++; goto I
fi;
I:
if
::ind==length -> ind=0; timeout; goto B
::ind<length -> goto B
fi;
E: skip;
}
inline ORSplit(cS, mS, aCs, choices){
int ind, length;
ind=0; length=len(cS);
skip;
S:
if
::choices[ind]==1 -> aCs[ind]!1;cS[ind]?mS[ind];
::choices[ind]==0 -> aCs[ind]!0;
fi;
ind++;
if
::ind < length -> goto S
::ind >= length -> skip
fi;
}
- 88 -
inline ORJoin(cS, aCs, mS){

int ind, length, x;
ind =0;length = len(aCs);
do
::ind <length -> timeout; ind++;
::ind ==length -> ind=0; break;
od;
skip;
B:
if
::length > 0 && ind <length && aCs[ind]?x == 1->
cS[ind]? mS[ind]; ind++;
::ind >= length -> goto E
fi;
E: skip;
}
proctype End(cS, mS){
int ind, length;
end:
do
::ind <length->cS[ind]?mS[ind];ind++;
::ind >=length->break;
od;
}
Table 3.2 La cartographie des éléments de BPMN en Promela model.
3.6.1 Processus de vente de voitures

L’e e ple d’illust atio de cette translation est représenté par un simple processus de
vente de voitures "Car Salesman process", comme le montre la figure 3.6.
Figure 3.6 Processus de vente de voitures.
Dans ce processus, le vendeur reçoit son bulletin de paie à la fin de chaque mois. Il ob-
tie t u o us à ha ue fois u’il ussit à e d e plus de vingt voitures durant le mois
(en plus de son salaire régulier).
Le lo age ou l’i passe da s e p o essus peut se p odui e e tuelle e t lo s ue le
e deu e d oi s de i gt oitu es pa ois .à.d. le e deu ’o tie t pas de o us.
Dans ce cas, la passerelle AND-Join reçoit une seule séquence qui est traversée par une
des deu a ti it s .à.d. l’a ti it « obtenir le bulletin de paie » et pas l’a ti it « obtenir
un bonus » ce qui provoque une situation de blocage comme décrit dans la section 4.
L'absence de blocages et de boucles infinies dans SPIN est détectée par la vérification
de l’a se e d’ tats i alides "invalid endstates" et l'absence de cycle de non-progression
"non-progress cycle", respectivement.
- 89 -
Le modèle PROMELA correspondant au processus de vendeur de voiture est décrite

comme suit:
Nous définissons un tableau de six canaux de communication représenté par la va-
riable cS et cela afin d’établir des communications entre les différents processus Prome-
la. Nous définissons aussi CS1 et CS2 comme étant des tableaux auxiliaires de canaux de
communication pour simplifier les échanges de message au sein du même processus. Le
modèle PROMELA des différentes activités est détaillé ci-dessous:
L a tivit Vendre des voitures : cette activité se lance dès u’elle eçoit u sig al de
l’ e e t de d ut, elle hoisit de faire appel aux activités qui la succèdent d’u e a-
nière non-déterministe sans perte de généralité ap s u’elle soit a he e. Elle peut être
traduite en processus PROMELA comme souligné dans le Listing 3.1 :
Listing 3.1 T adu tio de l a tivit Ve deu de voitu e e p o essus P o ela.
proctype sellCars(){
chan cS1[2]=[1] of {int};
int x, choice, msgs[2];
cS1[0]= cS[1]; /* send to Get Bonus */
cS1[1]= cS[2]; /* send to Get Paycheck */
R: cS[0]?x; /* receive from start event */
/* Choice of a non-deterministic manner */
if
::choice=0 /* Less that 2O cars */
::choice=1 /* More that 20 cars */
fi;
msgs[0]=1;
msgs[1]= choice;
ORSplit(cS1,msgs,cS1, msgs);
goto R
}
L a tivit Obtenir un bonus : comme mentionné ci-dessus, cette activité est choisie de
manière non-déterministe sans perte de généralité. Elle peut être traduite en processus
PROMELA comme souligné dans le Listing 3.2 :
Listing 3.2 T adu tio de l a tivit Obtenir un bonus en processus Promela.
proctype GetBonus(){
int x;
cS[1]?x; /* To receive from Sell Cars */
cS[3]!1; /* To send to Pay Bills */
}
L a tivit O te i le ulleti de paie : de la même manière, cette activité est choisie de

manière non-déterministe sans perte de généralité. Elle peut être traduite en processus
PROMELA comme le montre le Listing 3.3 :
Listing 3.3 T adu tio de l a tivit O te i le ulleti de paie e p o essus P o ela.
proctype GetPayCheck(){
int x;
cS[2]?x; /* To receive from Sell Cars */
cS[4]!1; /* To send to Pay Bills */
}
L a tivit Bulleti de paie : comme vu précédemment, quand le vendeur vend plus de

vingt voitures, un bonus (en plus de son salaire régulier) est ajouté à son bulletin de paie.
- 90 -
Cette activité peut être traduite par le processus PROMELA comme le montre le Listing
3.4 :
Listing 3.4 T adu tio de l a tivit ulleti de paie e p o essus P o ela.
proctype PayBills(){
int msgs[2];
cS2[0]= cS[3]; /* receive from GetBonus */
cS2[1]= cS[4]; /* receive from GetPaycheck */
T: ANDJoin(cS2, msgs); /* To receive from Get Bonus and Get PayCheck */
cS[5]!1; /* send to end event */
goto T;
}
Le fichier « Car_Salesman_process.pml» représente le modèle Promela complet qui

contient la description détaillée du processus de vente de voitures fourni à SPIN model-
checker comme entrée, sa description est détaillée dans le Listing 3.5 :
Listing 3.5 Le fichier Car_Salesman_process.pml
chan cS[6] = [1] of {int};

proctype Start(){....}
proctype sellCars(){....}
proctype getBonus(){....}
proctype getPayCheck(){....}
proctype PayBills(){....}
proctype End(){....}
init {
atomic{
run start(); run sellCars();
run getBonus();run getPayCheck();
run PayBills();run End();
}
}
La capture d'écran imprimée dans la figure 3.7 présente la spécification Promela du

processus de vendeur de voitures ainsi que le résultat de la vérification de la cohérence
par jSpin16. La figure 3.8 présente la structure de kripke générée par cet outil correspon-
dant à ce processus.
3.7 La vérification des règles de conformité

Les processus métier doivent se conformer à un ensemble de règles, appelées règles
de conformité ou "Compliance rules" décrivant les règlements, les politiques et les con-
traintes qu'une organisation doit respecter et dont le non-respect peut conduire à des
sanctions financières ou à un déficit en matière de bonne réputation.
Cependant, l'évolution rapide de ces règles exige une vérification des modèle de pro-
cessus métier à chaque fois qu'une règle est ajoutée ou modifiée (El Kharbili, de
Medeiros, Stein, & van der Aalst, 2008). Selon Goedertier dans (Goedertier & Vanthienen,
2006), l’o igi e de ette d a i it ie t esse tielle e t du ha ge e t f ue t da s
les réglementations extérieures tel que l'évaluation des risques dans le secteur bancaire
(Bâle II17 ue doit espe te l’e t ep ise et aussi le ha ge e t de politi ues i t ieu es
16
http://code.google.com/p/jspin/
17
http://www.banque-credit.org/pages/pilier-de-bale2.html
- 91 -
d fi ies pa l’e t ep ise o e pa e e ple, e tai s o d es d'e utio e t e les a ti i-

tés.
Figure 3.7 Vérification de la cohérence du processus de vente de voitures en jSpin
Figure 3.8 La structure de kripke générée par jSpin
Étant donné le grand nombre de règles et leurs fréquences de changement, une vérifi-
cation manuelle de ces règles représentera une tâche assez onéreuse en matière de
te ps et d’effo t. Il convient donc de mettre en place des mécanismes de vérification
automatiques de la conformité par les entreprises afin de gagner en gain de productivité.
Différentes approches ont été proposées pour permettre une telle vérification, comme
dans (Goedertier & Vanthienen, 2006), où les auteurs proposent une approche pour ga-
rantir la conformité des processus métier par le design, en introduisant PENELOPE comme
- 92 -
étant un langage déclaratif qui permet de capturer les obligations et les autorisations im-
posées par les politiques commerciales ( séquençage et contraintes entre activités) et
plus tard, de générer automatiquement des modèles de processus métier qui sont par
leur conception , conforme avec ces politiques.
Dans (Ghose & Koliadis, 2007), une approche pour vérifier la conformité des modèles
de processus métier et la résolution des violations a été introduite. Le document définit
un réseau sémantique de processus (SPN), où chaque activité est annotée avec des prédi-
cats pe etta t ai si u e ifi atio de l’e se le des règles. Dans (Liu, Müller, & Xu,
2007), une approche basée sur le model-checking a été proposée pour vérifier la confor-
mité des modèles de processus métier défini en BPEL avec un ensemble de contraintes
définies dans un langage de spécification de propriétés (BPSL) qui est converti par la suite
en LTL.
Une autre approche (Awad, Decker, & Weske, 2008) est capable de vérifier les règles
de conformité exprimées en PLTL "Past linear time temporal logic" plutôt que LTL pour
plus expressivité à l’aide d’un langage de requête appelé BPMN-Q (Awad, 2007).
Dans notre approche (Kherbouche, Ahmad, & Basson, 2013), la même démarche pro-
posée dans ce chapitre permettant la vérification de la cohérence des processus métier
exprimés en BPMN est adoptée pour vérifier la conformité de ces modèles. À cet effet, et
en premier lieu, les modèles de processus BPMN sont mappés en structures de kripke
pour exprimer leur comportement comme détaillé précédemment. Les règles de confor-
mité sont exprimées en formules LTL à l'aide d’u e notation graphique, permettant à la
fois d’obtenir le même niveau d'abstraction que les modèles de processus métier mais
aussi d’avoir une interface intermédiaire entre les règles de conformité et les formules
LTL exprimées dans une notation particulière pour un outil donné comme jSpin, EpiSpin,
etc (cf. Sous-section 7.2).
Cette technique permet aux experts de vérifier facilement et rapidement les règles de
conformité après chaque changement. Notre approche n'est pas limitée aux processus
définis en BPMN mais elle peut être appliquée à tout langage graphique permettant la
définition des processus métier o e le diag a e d’a ti it s UML, le diag a e EPC,
etc.
3.7.1 Représentation déclarative des règles de conformité

Les règles de conformité sont généralement difficiles à comprendre sous un format
textuel pour le modèle de processus métier. À cet égard, nous avons proposé un en-
semble de notations graphiques appelées G-LTL, qui pe et d’e p i er des formules LTL
sous forme graphique pour les utilisateurs non-initiés aux différents outils de model-
checker.
L'objectif de cette définition est de faciliter l’e p essio des différentes règles de con-
formité et d’o te i le e i eau d'a st a tio ue les od les de p o essus tie .
La Table 3.3 résume les différents éléments utilisés dans cette notation graphique G-LTL.
- 93 -
G-LTL Formule LTL G-LTL Formule LTL
Prop. G Prop. Prop. 1 ʌ Prop. 2 Prop. 1 Prop. 2
Prop. X Prop. Prop. 1 ˅

˅ Prop. 2 Prop. 1 Prop. 2
˅
Prop. F Prop. Prop. 1 X Prop. 2 Prop. 1 XOR Prop. 2
˅
Prop. 1 Prop. 2 Prop. 1 U Prop. 2 Prop. 1 → Prop. 2 Prop. 1 Prop. 2
˅
! Prop. Prop. Prop. 1 ↔ Prop. 2 Prop. 1 Prop. 2
˅
Prop. 1 ʌ Prop. 2 (Prop. 1 Prop. 2)
˅ Table 3.3 La notation graphique G-LTL.
Le générateur transforme automatiquement cette notation graphique en formules LTL

correspondantes. Toutes les formules générées sont cantonnées par l'opérateur G pour
exprimer le fait que la règle à vérifier doit être satisfaite dans tous les scénarios d'exécu-
tion possibles. U e e ple d’utilisatio de ette otatio ai si ue les fo ules g es
sont donnés dans la sous-section suivante.
3.7.2 Processus de remboursement des frais de fonctionnement

A tit e d’illust atio , ous p oposo s u e e ple (cf. figure 3.9) représentant un pro-
cessus de remboursement des frais de fonctionnement des employés d’u e e t ep ise.
Figure 3.9 Processus de remboursement des frais de fonctionnement
Dans ce processus, les employés d'une entreprise réclament un remboursement de

leurs dépenses, par exemple, l'achat de fournitures de bureau ou des logiciels. Après que
la note de f ais soit eçue, u ou eau o pte de d pe se est si l'e plo ’e pos-
sède pas un.
Une approbation automatique du remboursement est effectuée si le montant de la
dépense est inférieur à 200$. Sinon, si le montant est supérieur ou égal à 200$, cela né-
- 94 -
essite u e app o atio pa le supe iseu . E as de efus, l’e plo eçoit u a is de

rejet par e-mail, sinon, en cas d'acceptation, un virement bancaire qui permet de rem-
bourser le dû de l’e plo est effe tu .
Ce processus de remboursement des frais de fonctionnement doit se conformer à plu-
sieurs règles expliquées comme suit :
 R1: si l e plo e poss de pas de o pte, un nouveau compte sera créé.
 R2: si le montant est inférieur à 200$, alors la dépense doit être approuvée auto-

matiquement.
R3: après que la demande de remboursement soit approuvée, l'argent est transfé-
ré au compte bancaire de l'employé; autrement, une notification de rejet est en-
voyée par e-mail à l'employé.
Le fichier « Expense_Reimbursement_Process.pml » comme détaillé dans le Listing 3.6
représente le modèle Promela complet qui contient la description détaillée du processus
de remboursement des frais de fonctionnement.
Listing 3.6 Le fichier Expense_Reimbursement_Process.pml
chan cS[9] = [1] of {int};

/* RECEIVE EXPENSE REPORT PROMELA PROCESS */
proctype ReceiveExpenseReport() {
int exist;
chan cS1[2] = [1] of {int} ;
cS1[0]= cS[0];/* Send to create expense Account */
cS1[1]= cS[1];/* Send to review pre-Approval */
R:
if
:: exist=0 /* Account doesn’t exist */
:: exist=1 /* Account exist */
fi;
XORSplit(cS1,exist,1); goto R
}
/* CREATE EXPENSE ACCOUNT PROMELA PROCESS */
proctype createExpenseAccount() {
int x;
cS[0]?x;/* Receive from Expense Report */
cS[2]!1;/* Send to Review for Preapproval */
}
/* REVIEW FOR PRE-APPROVAL PROMELA PROCESS */
proctype PreApproval() {
mtype Amount;
int x;
cS2[0]= cS[1];
cS2[1]= cS[2];
cS3[0]= cS[3]; /* Send to Auto-approve Expense */
cS3[1]= cS[4]; /* Send to Approval review by supervisor */
P: XORJoin(cS2,x);/* Receive from Expense Report or Create Expense Account */
if
::(Amount<200)-> x=0
::(Amount>=200)-> x=1
fi;
XORSplit(cS3,x,1); goto P
}
/* AUTO-APPROVE EXPENSE ACCOUNT PROMELA PROCESS */
proctype AutoApp() {
int x;
A:
cS[3]?x;/* Receive from review for pre-Approval */
- 95 -
cS[5]!1;/* Send to Transfer Money to Employee’s Bank */

goto A:
}
/* APPROVAL REVIEW BY SUPERVISOR PROMELA PROCESS */
proctype AppBSupervisor() {
int approved, x;
chan cS3[2]=[1] of {int}
cS3[0]= cS[6];/* Send to Notify Employee of Rejection */
cS3[1]= cS[7];/* Send to Transfer Money to Employees Bank */
B:
cS[4]?x;/* Receive from Review for pre-Approval */
if
::(approved=1) /* Approved */
::(approved=0) /* Rejected */
fi;
XORSplit(cS3,approved,1);goto B
}
/* TRANSFER MONEY TO EMPLOYEE’S BANK PROMELA PROCESS */
proctype TransferMoney() {
int x;
T:
XORJoin(cS,x);
cS[8]!1;/* Send to end process */
goto T;
}
/* NOTIFY EMPLOYEE OF REJECTION PROMELA PROCESS */

proctype Notification() {
int x;
N:
cS[6]?x; /* Receive from Approval Review by Supervisor * /
cS[9]!1;/* Send to end process */
goto T;
}
/* Run processes */
init {
atomic{
run ReceiveExpenseReport();run createExpenseAccount();run PreApproval();
run AutoApp(); run AppBSupervisor(); run TransferMoney();
run Notification();run end();
}
}
Les figures 3.10, 3.11 et figure 3.12, représentent respectivement la formalisation des
règles de conformité R1, R2, R3 exprimées en G-LTL ainsi que les formules LTL correspon-
dantes générées et enregistrées dans le fichier « Expense_Reimbursement_CRules.prp ».
Figure 3.10 La représentation graphique de la règle «R1»
- 96 -
Les deux fichiers cités ci-dessus sont fournis comme entrée pour SPIN model-checker,
la figure 3.13 représente les résultats de la vérification de ce processus par jSpin.
Figure 3.13 Résultats de la vérification de conformités du processus en jSpin
3.8 Conclusion
Les modèles de processus métier sont généralement constitués d'un certain nombre
d'a ti it s i te d pe da tes ui so t d plo es pou attei d e les o je tifs tie s d’u e
entreprise. L'exactitude de ces modèles de processus métier est essentielle pour le bon
- 97 -
fonctionnement de l’e t ep ise. Pour cette raison, les éventuelles erreurs telles que les
erreurs structurelles dans les spécifications doivent être détectées et corrigées le plus tôt
possible, et cela même lors de la phase de conception.
Dans ce chapitre, nous avons présenté une méthode de validation des modèles de
processus métier basée sur la technique de model-checking. En effet, nous avons proposé
une approche pour la vérification de certaines propriétés de cohérence des modèles de
processus métier à l'aide du model-checker SPIN.
Tout d'abord, nous avons décrit comment traduire n'importe quel modèle de proces-
sus métier vers une structure de kripke pour exprimer son comportement, nous avons
ensuite, étudié certaines propriétés de cohérence des modèles de processus métier et
présenté la traduction de ces propriétés en formules LTL et cela afin de permettre au mo-
del-checking de vérifier si l'abstraction donnée par cette structure de kripke satisfait ou
non les différentes formules et par conséquent de d te te d’ e tuelles e eu s st u tu-
relles.
Cette approche a été implémentée et validé par un modèle vérifiable par SPIN. Ce mo-
dèle, devant être décrit en langage Promela. Les simulations faites sur SPIN en testant les
propriétés évoquées sur différents modèles de processus métier ont montré l'efficacité
de cette méthode de vérification des modèles. En particulier, la notion du contre-exemple
généré par SPIN est d'une grande importance vue qu'elle nous aide à trouver rapidement
la cause de l'erreur et par la suite la corriger.
Dans la même démarche, cette approche à été utilisée pour vérifier les règles de con-
formité qui sont essentielles pour gouverner et contrôler les comportements métiers et
l’i fo atio au sei d’u e o ga isatio . Les modèles de processus métier sont mappés
en structures de kripke pour exprimer leur comportement tandis que les règles de con-
formité sont exprimées à l’aide d’u outil u’o a proposé appelé G-LTL. Cet outil a la ver-
tu d’off i u o e si ple pou fo ule les gles à ifie , sa s a oi o aissa e
des différentes notations LTL pour chaque outil de model-checker. Il permet également
d’o te i des gles da s le e i eau d’a st a tio ue les od les de p o essus
métier.
Dans le chapitre suivant, nous allons présenter le deuxième axe de notre contribution
qui consiste à a al se l’i pa t du ha ge e t sur les modèles de processus métier.
- 98 -
- 99 -
CHAPITRE
4
Analyse a priori de l’I pa t du
changement des modèles de
processus métier
. A al se a p io i de l’i pa t du ha ge e t des p o essus tie
4.1 Introduction
Pour mener à bien leurs missions dans un contexte fortement concurrentiel et afin de
faire face aux évolutions du marché, les entreprises ont, de plus en plus, besoin de gérer
des p o essus o ple es do t elles doi e t assu e la fia ilit et de s’adapte au han-
gements.
L’o igine de cette dynamique vient essentiellement des changements fréquents des
gle e tatio s e t ieu es ue l’o ga isatio doit espe te et de eu de la politi ue
intérieure de cette organisation. Cela rend les éléments de processus susceptibles
d’ olue (Goedertier & Vanthienen, 2006). Des changements doivent donc pouvoir af-
fe te u ou plusieu s l e ts d’u p o essus sa s alt e la sta ilit des aut es lé-
ments.
Cependant, du fait des dépendances fortes des diverses entités qui constituent un pro-
cessus métier, tout changement affectant une entité de ce processus a de fortes chances
de provoquer des effets de bord concernant les autres entités. Il est donc nécessaire que
tout changement d'un processus métier soit accompagné d'une analyse de son impact, ce
qui permettra de mieux mesurer ses effets et surtout ses effets indésirables générale-
ment appelés effets de bord ou "Side effects".
L’u des aspe ts p i ipau de l’a al se de l’i pa t du ha ge e t est l’aspe t struc-
tu el. E d’aut es te es, et i pa t o e e les effets de ague ou "Ripple effect" as-
socié à la modification d'un processus. En effet, toute opération de changement d'un pro-
cessus qu'elle soit un simple renommage d'une activité ou le remplacement d'un frag-
ment du modèle de processus par un autre peut engendrer des effets qui affectent une
grande partie voir la totalité de la structure du processus.
Il est do p i o dial de ett e e œu e des a is es d’a al se a priori permet-
ta t de ieu o p e d e et e e la p opagatio de l’i pa t du ha ge e t des pro-
cessus métier afi d’ ite des situatio s i o t ôl es survenant généralement après le
changement et de conserver ainsi la cohérence du processus.
La compréhension du processus métier est donc d’u e essit u iale pou toute
ise e œu e de ha ge e t. La difficulté de compréhension est liée au nombre très
i po ta t d’interconnexions verticales (inter-couches) et horizontales (intra-couches)
entre les différentes entités du processus métier. Le terme couche désigne un niveau
d'abstraction donné. Par exemple, une modélisation d'un processus par la notation BPMN
ou EPC appartient à une couche plus abstraite que celle associée au déploiement de ce
processus en utilisant le langage BPEL.
L’a al se du ha ge e t et de la p opagatio de so i pa t peut do essite u e
description exhaustive des constituants du processus métier et de leurs interdépen-
dances. Elle nécessite également l’e iste e d’u f e tiel e ploitable de façon auto-
matique (une base de connaissances) et servant au stockage et à la manipulation des
données et des éléments constituant le processus.
Dans ce chapitre, nous présentons avec plus de détails les résultats de nos travaux
o e a t l’a al se de l’i pa t du ha ge e t des processus métier avec un intérêt
particulier pour les relations de dépendance inter-couches et intra-couches. Cela nous a
- 101 -
conduits à la construction d’u e se le de gles et d’u s st e à base de connais-

sances intégrant les concepts de base nécessaires pou l’a al se et la propagation du
changement de la structure du processus.
Le chapitre est organisé comme suit : la section 4.2 présente la gestion du changement
des p o essus tie d’u e faço g ale. La section 4.3 établit une synthèse de ce qui
e iste da s la litt atu e à p opos de l’a al se de l’i pa t du ha ge e t. La section 4.4
explique le principe de cette analyse et la section 4.5 explique plus particulièrement celui
d’a al se de l’i pa t du ha ge e t des processus métier. La section 4.6 montre com-
ment il est possi le d’a al se l’i pa t du ha ge e t à t a e s les diff e tes elatio s
de dépendance. La p opagatio de l’i pa t du changement et sa modélisation sont dé-
taillés dans la section 4.7 et la section 4.8 respectivement. Finalement la section 4.9 con-
clut le chapitre.
4.2 Gestion du changement des processus métier

La capacité d'adaptation d'un processus métier est une exigence essentielle pour les
entreprises afin de faire face à la nature dynamique de leurs environnements. Toutefois,
sans contrôle adéquat, les changements des processus métier peuvent engendrer des
effets de bord "Side effects" qui peuvent conduire à des blocages, des exécutions infinies,
des terminaisons multiples (Kherbouche, Ahmad, & Basson, 2012), (Kherbouche, Ahmad,
& Basson, 2013) , des conflits sémantiques (Rinderle, Reichert, & Dadam, 2003), une non-
conformité avec la réglementation (Awad, Decker, & Weske, 2008), une dégradation de la
qualité du service ( temps de réponse , la sécurité , la taille du message, etc.) , ou encore
une détérioration de la qualité globale du processus métier (Sánchez-González, Ruiz,
García, & Piattini, 2011).
À cet égard, les travaux de recherche portant sur la gestion des changements des pro-
cessus métier continuent à susciter un intérêt croissant de l'industrie et de la communau-
té scientifique, et cela depuis plus de vingt ans (Rajabi & Lee, 2010), (Reijers, 2006). Ce-
pendant, la majorité de ces approches et paradigmes (Weske, 1998), (Casati, Ceri, Pernici,
& Pozzi, 1996), (Zhao & Liu, 2013), (Reichert & Dadam, 1998), (Reichert, Rinderle, Kreher,
& Dadam, 2005), (Weber, Reichert, & Rinderle-Ma, 2008), (van der Aalst & ter Hofstede,
2005) focalisent sur la gestion des changements dynamiques des processus métier. Au-
trement dit, la façon dont on peut intégrer les changements avec cohérence sans affecter
les i sta es e ou s d’e utio plutôt que de proposer des solutions visant à accroître
la prise de conscience des modeleurs et experts métiers suite à un changement dans les
processus métier.
En effet, en dépit des travaux novateurs proposés dans la littérature par la communau-
té "Business Process" (BP), et permettant la gestion du changement dynamique des pro-
cessus métier et hormis quelques tentatives (Chountas, Petrounias, & Kodogiannis, 2003),
(Chun, Atluri, & Adam, 2002), (Kim, 2003) qui offrent la possibilité d’a al se les relations
de dépendance qui existent au sei d’u o kflo à des fins de modélisation, peu d'ef-
forts ont été faits pour fournir des mécanismes permettant de comprendre a priori18
comment un changement de processus métier pourra avoir un impact sur le reste du sys-
18
Du a t la phase de o eptio et a a t la phase d’e utio des processus métier
- 102 -
tème (Dai & Covvey, 2005). Le processus qui a pour but d’a oît e la p ise de o s ie e
des modeleurs afin d'éviter les effets de bord (Arnold & Bohner, 1993) et/ou d’estimer les
effets de vague (Bohner S. A., 1996) du changement concerné est appelé analyse de l'im-
pact du changement.
4.3 Analyse de l’impact du changement dans la littérature

Le mot « impact du changement » fait référence aux répercussions et au effets u’u
changement d’u e e tit du système peut avoir sur les autres entités de ce dernier.
L’a al se d'i pa t du changement est souvent utilisée pour évaluer ces effets après que
le changement soit appliqué.
Il existe différentes définitions de l'analyse de l'impact du changement dans la littéra-
ture. Parmi ces définitions on peut citer celle du travail de Haney (Haney, 1972) qui porte
su u e te h i ue d'a al se de la o e io des diff e ts odules d’u s st e et qui
est souvent désigné comme étant le premier papier qui porte sur l'analyse d'impact. La
technique tient à l'idée que pour chaque paire de modules dans un système, il existe une
probabilité qu'un changement dans un module nécessite un autre changement consé-
quent dans l'autre module. La technique a ensuite été utilisée pour la propagation du
changement de modèle entre tous les composants du système. Pfleeger et Bohner
(Pfleeger & Bohner, 1990), définissent l'analyse de l'impact du changement comme : «
l'évaluation des nombreux risques associés au changement, y compris les estimations des
effets sur les ressources, sur les efforts et sur la planification ». Turver et Munro (Turver &
Munro, 1994) définissent l'analyse de l'impact du changement comme « l'évaluation d'un
changement du code-source d'un module, sur les autres modules du système. Il détermine
ainsi la portée du changement et fournit une mesure de sa complexité ». Arnold et Bohner
(Arnold & Bohner, 1993) définissent l'analyse de l'impact du changement comme « un
mécanisme qui permet d'identifier les conséquences potentielles d'un changement, ou
l'estimation de ce qui doit être modifié pour réaliser un changement ». Ils mettent l'accent
sur l'estimation de l’i pa t. Dans une définition étendue, Pfleeger prolonge sa définition
initiale à l'évaluation des impacts en analysant l'effet de vague d'une modification du
code-source d'un système, il définit cela comme étant « les effets indirects sur les autres
parties du système résultant de ce changement ». Ces effets peuvent être classés en plu-
sieurs catégories telles que les effets sur la logique du système, les effets sur la perfor-
mance du système mais aussi les effets sur la compréhension du système.
Toutefois, une approche plus récente et proactive utilise l'analyse d'impact afin de
prédire les effets du changement en amont c.à.d. avant qu'il ne soit appliqué (Bohner S.
A., 2002) pour estimer les coûts et les ressources nécessaires pour appliquer ce dernier.
4.4 Principe de l’analyse de l’impact du changement

Du fait des dépendances fortes des divers éléments d’un processus métier, les chan-
gements concernant un de ces éléments o t de fo tes ha es d’affe te les autres. Il est
do essai e de e e u e a al se de l’i pa t de tout ha ge e t e ide tifia t de
façon précise les différents l e ts u’il affe te. U e des diffi ult s ajeu es pou e-
e e ge e d’a al se o siste e l’e iste e d’u ph o e appel effet de ague ou
- 103 -
"Ripple effect" se manifestant par une propagation des effets de tout changement aussi
minime soit-il à un tr s g a d o e d’entités. Afi d’a al se es effets, l’a al se de
l’i pa t du changement utilise généralement deu te h i ues ui so t l’a al se des dé-
pendances et d'analyse de la traçabilité.
L’a al se de d pe da e fou it u e se le d’outils pe etta t de d te te et
d’a al se les différentes relations de dépendance dans un système. Cela peut com-
prendre les dépendances de données qui représentent les relations entre les instructions
de programme qui définissent ou utilisent des données. Autrement dit, une dépendance
de données existe quand une déclaration fournit une valeur utilisée par une autre décla-
ration dans un programme. Les dépendances de contrôle sont les relations entre les états
du programme qui contrôlent son exécution, et enfin les dépendances des composants
qui se réfèrent aux relations générales entre les composants du code-source, par
exemple, packages, modules, fichiers, etc.
L’analyse de traçabilité est généralement un travail ui pe et d’ ta li u lie entre
l’e i o e e t du s st e et sa do u e tatio ui o tie e t des i eau a i s
d'information sur ce système. Il met l'accent sur les interconnexions entre le code source,
les tests, les documents de conception et les exigences, etc.
Cependant, bien que l'analyse de dépendance (Ajila, 1995) , (Deruelle, Bouneffa,
Melab, Basson, & Goncalves, 2000), (Fisler, Krishnamurthi, Meyerovich, & Tschantz,
2005), (Ryder & Tip, 2001) et l’analyse de traçabilité (Pfleeger & Bohner, 1990), (Arango,
Schoen, & Pettengill, 1993), (Baniassad & Clarke, 2004), (Knethen, 2001), (Marcus &
Maletic, 2003) puissent être utilisées séparément, elles peuvent également être utilisées
conjointement comme proposé dans (Lindvall & Sandahl, 1998).
4.5 Analyse de l’impact du changement des processus métier

Selon la taxonomie de changement de Regev et al. (Regev, Soffer, & Schmidt, 2006),
tous les l e ts du p o essus so t sus epti les d’ t e odifi s. E effet, l’ olutio du
processus métier peut être vue comme un ou plusieurs changements (par exemple, ajout
d'u e a ti it , supp essio d’u e a ti it , ou odifi atio d'u e o t ai te op s su u
ou plusieurs éléments du processus et peut concerner tous les aspects du processus.
Les causes de ces changements sont multiples, elles a e t pou la plupa t d’u e
o e tio d'u e ou plusieu s e eu s, d’u e e eptio da s le p o essus tie , d’u e
mise en conformité avec de nouvelles normes ou réglementatio s, d’u e olutio du
tie et des se i es de l’e t ep ise "innovation", ou d’u e a lio atio des pe for-
mances et une optimisation des processus existants "reengineering".
Un changement de processus métier peut être décrit formellement comme une diffé-
rence (notée Δ) entre le schéma du processus métier initial S et le schéma du processus
métier résultant S , il peut être quantifié comme suit:
S’ = S + Δ
Δ = | S’ - S |
La variation (Δ) peut génére diff e ts t pes d’i pa t. Ces impacts peuvent être
structurels, fonctionnels, comportementaux, logiques et/ou qualitatifs sur une partie ou
- 104 -
sur l'ensemble du modèle de processus métier et ses instances et peuvent être propagés
d’u e a i e horizontale (intra-couche) et verticale (inter-couches). Par conséquent,
une analyse a priori de cette variante est donc primordiale pour maintenir la cohérence
des modèles de processus métier obtenus après ce changement.
Cette a al se de l’i pa t du ha ge e t des processus métier vise à déterminer les
éléments du modèle qui sont susceptibles d’être impactés directement ou indirectement
par ce changement. Elle peut être résumée dans le méta modèle de la figure 4.1 sous la
fo e d’u diag a e de lasses.
En effet, un changement est o sid o e u e e tit ui s’appli ue au i eau du
schéma du processus métier, ou au niveau des instances. Un changement cause différents
t pes d’i pa t et essite u e a al se qui consiste à les décrire ou à les définir.
Comme tout système, un p o essus tie est o pos de diff e ts t pes d’ l e ts
ou entités en interaction les uns avec les autres. Autrement dit, les entités sont interdé-
pendantes à travers des relations directes ou indirectes. L'une des relations les plus cou-
ramment identifiées o e ta t u fil o du teu da s le p o essus d’a al se de
l’i pa t est la elatio g i ue dite de d pe da e. E effet, u e telle relation permet
de dire : si u e e tit B d pe d d u e e tit A, le ha ge e t de A au a u i pa t su B.
Figure 4.1 Analyse de l'impact du changement des processus métier
Notre travail (Kherbouche, Bouneffa, Ahmad, & Basson, 2013), (Kherbouche O. M.,
Ahmad, Bouneffa, & Basson, 2013) consiste à traiter l'analyse de l'impact du changement
des processus métier à travers une approche basée sur une définition de la relation de
dépendance tenant compte des spécificités de modélisation de ces processus.
L'approche proposée permet non seulement d'analyser les relations de dépendance
qui existent entre la partie changée et les autres parties potentiellement affectées au sein
du modèle de processus métier p opagatio d’i pa t horizontal), mais aussi d'analyser
les relations entre ces modèles de processus métier et les services associés (propagation
d’i pa t vertical).
- 105 -
4.6 Analyse des relations de dépendance

Outre l'analyse de la traçabilité, l'analyse de dépendance joue un rôle important dans
l'analyse d'impact du changement des logiciels comme vu précédemment. Son objectif
principal est de capturer les relations de dépendance existantes dans un système à tra-
vers différentes techniques tels que des graphes appelés « Graphe des dépendances »
"Dependency graph" (Rajlich, 1997) ou des « Matrices de Dépendance Structurelle » "De-
pendency Structure Matrix (DSM)" (Yu, Goldberg, Sastry, Lima, & Pelikan, 2009), (Li, 2003)
afin d'identifier les entités qui peuvent être potentiellement touchés par un changement.
Dans la même optique, et en se basant sur ce principe, notre approche consiste à trai-
ter l'analyse de l'impact du changement des modèles de processus métier à travers une
définition de la relation de dépendance qui est considérée comme le vecteur de la con-
du tio et do de la p opagatio de l’i pa t.
En effet, un processus métier est composé de différents types d'entités qui jouent des
rôles différents et qui interagissent les uns avec les autres dans de multiples aspects, que
e soit d’u e faço di e te ou i di e te. Ces interactions font référence à des relations de
dépendance.
A a t d’i t odui e la otio de d pe da e da s les processus métier, nous proposons
dans ce qui suit, un scénario représentant un processus de demande de crédits (cf. figure
4.2 et ela da s u ut d’illust ation de nos propos par un exemple. L’e e ple est com-
posé de deux processus à savoir, la banque et le client.
Figure 4.2 Dépendances multicouches dans les processus métier
Dans ce scénario, nous pouvons distinguer deux sortes de relations de dépendance

da s la ou he des p o essus tie . La d pe da e au sei d’u e p o essus, pa
exemple le processus client, que nous appellerons intra-processus, et la dépendance
entre processus, par exemple, le processus client et le processus banque, que nous appel-
lerons inter-processus.
- 106 -
La relation intra-processus se réfère aux relations existant entre des activités apparte-
a tàu e p o essus. Pa e e ple, da s le p o essus lie t l’ e e t « Envoi de
la demande de crédits » d pe d de l’a h e e t de l’a ti it « Demande de crédits ».
La relation inter-processus est la relation de dépendance entre des processus diffé-
e ts. E d’aut es te es, elle d sig e u e elatio de d pe da e e t e des a ti it s
appartenant à des processus différents. Dans notre scénario, cela se manifeste par les
échanges de messages entre les deux processus (cf. figure 4.2).
Les relations de dépendance que nous avons mises en évidence ci-dessus sont appe-
l es d pe da es d’a ti it s ou d pe da es de outage. Elles t aduise t l’o d e d'e u-
tio des diff e tes a ti it s d’u p o essus tie . Ces o d es d'e utio so t définis
par les concepteurs et les experts métiers. Ils sont basés sur les exigences techniques, les
réglementations juridiques, ou les politiques de gestion. Par exemple, si deux activités
sont exécutées de façon séquentielle, cela signifie que l'achèveme t de l’e utio de la
première activité est une pré- o ditio pou l’e utio de la se o de.
Il existe également un autre type de relations de dépendance appelée dépendance de
do es. C’est le as, pa e e ple, de la elatio e ista t e t e l’a ti it « Demande de
crédits » et l’activité « Créer des groupes ». En effet, cette activité dépend de la seconde
du fait u’elle lui fou it des données concernant le client qui effectue la demande du
crédit. Il est aussi intéressant de constater dans certains cas que les dépendances de don-
es e o espo de t pas toujou s au d pe da es d’a ti it s. Aut e e t dit, le flu
de données peut ne pas correspondre à l'ordre d'exécution des différentes activités du
p o essus. Il est do essai e d’a al se la d pe dance de données séparément de la
d pe da e d’a ti it s.
Le scénario de demande de crédits (cf. figure 4.2) ne montre pas la totalité des dépen-
dances qui peuvent exister entre les différents éléments qui constituent un modèle de
processus métier. En effet, il faut gale e t p e d e e o pte d’aut es t pes de dé-
pendance qui peuvent exister entre les différentes entités formant un modèle de proces-
sus métier tels que les rôles, les acteurs, les ressources et les règles, mais aussi les dépen-
dances qui peuvent exister entre les processus et les services associés.
4.6.1 Taxonomie de la dépendance dans les modèles de processus métier

Nous pouvons résumer les quatre types de dépendance qui peuvent jouer un rôle im-
portant dans l'analyse de l'impact du changement des processus métier comme suit :
1) La dépendance structurelle: il s'agit de la dépendance syntaxique qui existe entre
deux entités du processus métier. Par exemple, un changement appliqué sur une
activité dans le modèle de processus métier peut avoir un impact structurel sur les
activités adjacentes.
2) La dépendance sémantique: il s'agit de la dépendance sémantique qui existe entre
deux entités du processus métier. Par exemple, un changement dans une entité
tel u’u e passe elle peut provoquer un changement dans le sens sémantique ou
l'interprétation des entités dépendantes.
3) La dépendance directe: elle met en évidence un flux de contrôle F (séquence ou
message) tel que F ⊆ N × N entre deux entités voisines tel que : {(n1, n2) ∈ F}. Ainsi
- 107 -
un arc (n1, n2) représente le fait que n2 est le su esseu di e t du œud 1 et par
conséquent n1 est le prédécesseur de n2.
4) La dépendance indirecte: il s'agit d'une dépendance d'une entité envers une autre
par transitivité. Il met en évidence un ensemble de flux de contrôle intermédiaire
qui peut exister entre deux entités. C-à-d s’il e iste u e se le de elatio s de
dépendance directes R entre les activités {a1, a2,…, an} ∈ A tel que : (a1 R a2,…, an-1
R an alors a1 R an).
4.6.2 Modèle de dépendance pour l'étude d'impact

Nous proposons dans notre travail, un modèle multidimensionnel de dépendance qui
comprend des relations de dépendance intra-couches qui sont : la dépendance
d’a ti it s, la d pe da e de do es et la dépendance de rôles, mais aussi les relations
de dépendance inter-couches c.à.d. entre la couche des processus métier et de la couche
des services (cf. figure 4.2).
Notre objectif est de construire le modèle le plus exhaustif possible pour l'analyse a
priori de l’i pa t du ha ge e t des processus métier et d’ ta li ai si u e ase e ten-
si le pa la p ise e o pte p og essi e d’aut es di e sio s telles ue les acteurs, les
règles et les ressources, etc.
4.6.2.1 Relations de dépendance intra-couches
Les relations de dépendance intra-couches comprennent les points suivants:
4.6.2.1.1 Dépendances d’activités routage
Comme évoqué précédemment, il existe deux types de dépendances d’a ti it s ou de
outage et ui so t : l’i te -processus et l’i t a-processus. Ce type de dépendance définit
l'ordre d'exécution des activités dans un processus et cela par le biais des flux de contrôle
(flux de séquences "Sequence flows" et flux de messages "Message flows"). Ces dépen-
da es d fi isse t o seule e t l’o d e d’e ution mais également une certaine sé-
mantique associée à cet ordre. Ainsi, pour une passerelle AND-Join reliant deux activités A
et B à une activité C, l’a ti it C ne peut être exécutée que si A et B ont achevé leurs exé-
cutions qui se déroulent en parallèle.
Formalisatio de la d pe da e d a tivit s :
U e d pe da e d’a ti it s peut t e d fi ie o e suit :
A = ₯, )
Sur un ensemble d'activités A = {a1, …, an} et un ensemble de flux de contrôle T= {t1,..,
tn}.
₯ a = ₯i a ∪ ₯o (a) avec a ∈ A
₯o a ep se te l’e se le des a ti it s ai ∈ A ui su de t à l’a ti it a o ote-
ra cela par ai  a et do t l’e utio d pe d a fortiori de a. C’est u e elatio "one-to-
many", où plusieu s a ti it s d pe de t d’u e seule aut e a ti it . De la e a i e,
₯i a ep se te l’e se le des a ti it s ai ∈ A ui p de t l’a ti it a o ote a ela
par a  ai . E d’aut es te es l’e utio de a dépend de celles des activités apparte-
- 108 -
nant à ₯i (a). C’est u e elatio "many-to-one", où une activité dépend de plusieurs

autres activités.
= i∪ o
i est l’e se le des flu de o t ôle ti ∈ T reliant chaque activité de ₯i(a) à a. Au-
t e e t dit, l’e se le des a s e t a ts ₯i a , a) de a. o est l’e se le des flu de
contrôle ti ∈ T elia t l’a ti it a à toute activité appartenant à ₯o(a). Ce sont donc les
arcs sortants (₯o(a), a) de a.
4.6.2.1.2 Dépendances de données
La dépendance de données met en avant les ressources communes ou les données
liées à plusieurs activités. Il existe trois grands types de dépendance de données (Malone,
et al., 1999): la dépendance par flux ou "Flow dependency", la dépendance par partage ou
"Sharing dependency" et la dépendance par mutualisation ou "Fit dependency".
Une dépendance par flux existe si une activité produit une ressource ou donnée, utili-
sée par une autre activité. Une dépendance par partage représente le fait que plusieurs
activités utilisent ou partagent la même ressource ou donnée, et enfin une dépendance
par mutualisation existe si plusieurs activités produisent collectivement une ressource ou
donnée.
Formalisation de la dépendance de données :

O d fi i a l’e se le des do es D échangées entre les activités (Reichert &
Dadam, 1998) par :
D = {d1, d2,…, dn}
Chaque activité ai ∈ A possède des paramètres d'entrée et des paramètres de sortie,
notés respectivement InPARs(a) et OutPARs(a). On définira une connexion de donnée
notée dc par:
dc = {d, a, pars, mode}
Où, d ∈ D, ai ∈ A, pars ∈ InPARS(a) ∪ OutPARs(a), et mode ∈ {lecture, écriture}.
Cela sig ifie ue l’a ti it ai ∈ A utilise (en lecture ou en écriture) une donnée d ∈ D
fournie o e pa a t e d’e t e ou/et de so tie.
Une activité ai ∈ A dépend d'une autre activité aj ∈ A en termes de données, noté par
la relation aj ai ssi
(D)
dcx, dcy ∈ DC
Où, DC= {dc1, dc2, ..., dcn} est l’e se le de toutes les o e io s de do es tel ue :
dcx = {d, aj, pars, écriture}
dcy = {d, ai, part, lecture}
Où, d ∈ D, part ∈ InPARs (ai), pars ∈ OutPARs (aj) et aj précède ai dans le schéma du
processus métier.
- 109 -
4.6.2.1.3 Dépendances de rôles

Dans (Kim, 2003), l’auteu d fi it des elatio s de d pe da e e t e les ôles e em-
plaçant l'activité par le rôle associé à cette dernière. Autrement dit, le diagramme d'acti-
vités devient un diagramme de rôles. Cependant, ce diagramme de rôles est basé sur la
st u tu e hi a hi ue de l’o ga isatio (Dai & Covvey, 2005).
La relation de dépendance entre les rôles est définie de la manière suivante :
Si un rôle A est affecté à la même activité a exécutée par un autre rôle B, alors nous
pouvons conclure que le rôle B à une relation de dépendance avec le rôle A. Par exemple,
l'activité « Prise de radio » dans un processus de l'examen d'imagerie médicale peut être
effectuée par un « technicien » ou un « radiologue ». C'est-à-dire, le rôle (Technicien,
prend une radio, l'examen d'imagerie médicale) et le rôle (Radiologue, prend une radio,
l'examen d'imagerie médicale) so t d pe da ts l’u de l’aut e.
Formalisation de la dépendance de rôles :

Soit R= {r1, …, n} un ensemble de rôles et A= {a1, …, an} u e se le d’a ti it s. U e
dépendance de rôles peut être définie comme suit :
R = (Ϭ, ) Où: Ϭ(r)= Ϭi(r)∪ Ϭo(r) avec r ∈ R.
Ϭo(r) ep se te l’e se le des ôles ui so t des su esseu s i diats à r, ’est-à-
dire affectés à des activités αi ∈ A ui su de t à l’a ti it a à laquelle r est associé. Ϭi(r)
ep se te l’e se le des ôles p d esseu s i diats de r. E d’aut es te es les
rôles affectés aux activités αi ∈ A ui p de t l’a ti it a et a laquelle r est associé.
= i∪ o
i est l’e se le des flu de o t ôle ti∈T ou arcs reliant chaque rôle de Ϭi(r) à r. Au-
t e e t dit, l’e se le des a s e t a ts de r. o est l’e se le des flu de o t ôle ti∈
T, reliant le rôle r à tout rôle appartenant à o. Ce sont donc les arcs sortant de r.
4.6.2.2 Relations de dépendance inter-couches
Comme la couche des processus métier, la couche des services se o pose d’un en-
semble de services qui interagissent les uns avec les autres par des relations directes ou
indirectes et qui sont également en constante évolution (Wang & Capretz, 2009). Cepen-
dant, il existe à côté de cela, une relation de couplage entre les services et les processus
métier, comme indiqué dans la figure 4.2, que nous avons appelé une relation de dépen-
dance inter-couche.
En effet, la corrélation, les entrées et les sorties des services web sont liées par l'or-
chestration de ces processus à travers des normes tels que WS-BPEL. Par conséquent, un
processus métier peut faire appel à plusieurs services. Cela signifie que chaque fois qu'un
changement se produit dans le processus métier, ce dernier peut affecter les services qui
lui sont associés et vice-versa. Ceci peut être justifié par le fait u’u e activité dans le mo-
dèle de processus métier peut interagir avec un service d’u e faço unidirectionnelle ou
bidirectionnelle via l'invocation de l'un de ses opérations.
Un service est généralement défini comme un ensemble d'opérations O = {o 1,…, on} où
chaque opération oi ∈ O est associée à un ensemble de messages. T ⊆ S × S représente
- 110 -
l’e se le des elatio s e t e ces opérations. Chaque transition t = (oi, oj) ∈ T (oi, oj ∈ O)
désigne l'invocation de l'opération oj par l’op atio oi.
Nous pouvons définir formellement la relation de dépendance entre la couche des
processus métier et la couche de service par : ȡic = (As, ᴦ) sur un ensemble d'activités A =
{a1 ... an} et un ensemble de services web S = {s1 ... sn} où:
As représente l’ensemble d'activités qui fait appel au même service si ∈ S (noté comme
suit: ai ⇝ si) et ᴦ ⊆ A × S est l'ensemble des arcs reliant les œuds qui représentent la rela-
tion de dépendance entre chaque activité ai ∈ S et le service invoqué si ∈ S.
4.7 Propagation de l’impact du changement

La p opagatio de l’i pa t du ha ge e t o u aussi da s la litt atu e sous le o
de l’effet de ague o siste à e ute ou si ule da s le as de l’a al se a priori) le
changement initial puis identifier les incohérences ou les inconsistances que ce change-
ment initial peut induire et définir en conséquence les éléments à corriger par de nou-
veaux changements correcteurs dérivés ou conséquents. L’a al se de cette propagation
de l’i pa t du ha ge e t utilise un ensemble de méthodes algorithmiques, permettant
de esu e l’i pa t de ce changement et son étendue.
Dans notre cas, il s’agit p i ipale e t de d te i e , a priori, les effets directs et in-
di e ts d’u e op atio de ha ge e t su l’e se le des l e ts d’un processus mé-
tier et cela, avec une certaine nuance su le deg d’i pa t de chaque élément suscep-
ti le d’ t e tou h pa e ha ge e t.
En effet, l’a al se de la p opagatio de l’i pa t du ha ge e t ne doit pas se limiter à
savoir combien et quelles autres parties du processus peuvent être affectées par ce chan-
gement de processus métier, mais à connaître où l'impact du changement doit commen-
cer et où il doit se terminer. Autrement dit, calculer la profondeur de la propagation de
l'impact tout en faisant la distinction entre les entités impactées en termes de degré ou
de puissance d’i pa t.
Pour faire face à ce problème, nous avons proposé dans (Kherbouche O. M., Ahmad,
Bouneffa, & Basson, 2013) d’assigner des poids numériques (IWF) aux différents types de
elatio s de d pe da es selo leu i po ta e da s la p opagatio de l’i pa t du han-
gement. Ai si, o pou a sp ifie u’u t pe de elatio est plus iti ue et do plus
i po ta t à a al se lo s du p o essus de p opagatio de l’impact.
Le poids IWF que nous avons appelé facteur de pondération ou "Impact Weight Fac-
tor" en anglais représente une valeur numérique qui permet d’aid à mesurer la profon-
deur de l'impact du changement. Elle est calculée sur la base d'un ensemble de mé-
triques, comme suit:
IWF (ai) = Σ (P (ai) + E (ai) + F (ai) + ND (ai)) /TDR
TDR ou "Total Dependency Relationships" représente le nombre total des relations de
dépendance au sein du processus métier et aussi entre ce dernier et les services associés.
- 111 -
4.7.1 La métrique P
La métrique P, représente la priorité d'une activité ai ∈ A (High, Medium ou Low) dans
le flux d'exécution d’u processus métier, qui est définie généralement par les modeleurs
durant la phase de conception. Elle peut être calculée en se basant sur les valeurs qui cor-
respondent aux priorités assignées comme par exemple : si une activité A doit s’e ute
avec une priorité Haute alors P (A) = 0,75 (75/100).
4.7.2 La métrique E
La métrique E, représente la fréquence d'exécution d'une activité ai ∈ A dans chaque
chemin d'exécution π d’u e i sta e Ix avec x ∈ {1 ... n} du processus métier p. Elle peut
être calculée mathématiquement à partir des journaux d'exécution "Process events logs"
comme suivant :
n n
E(ai)= ΣI=0 (Σπ=0 ex(ai))
En effet, les journaux d'exécution d’u p o essus tie peuvent être exploités pour
découvrir le nombre de fois où chaque activité a été exécutée ex(ai) dans chaque chemin
d'exécution π d’u e i sta e I. Par exemple, si nous observons que le chemin d'exécution
qui mène à l'activité A et B a été exécuté plutôt que celui menant à l'activité C dans les
différentes instances, cela implique que la valeur de E(A) et E(B) doit être supérieur à celle
de E(C).
4.7.3 La métrique F
Cette métrique se réfère aux fréquences d'invocation notée F d'une activité ai ∈ A
dans un modèle de processus métier p. Par exemple, si l'activité B est appelée dans
chaque chemin d'exécution π possible de l'activité A, alors la probabilité que A soit impac-
tés par un changement dans B, devient élevée. Toutefois, si B est appelée dans un chemin
d'exécution pa i d’aut es possibles de l'activité A, alors la probabilité de A étant impac-
tée par un changement dans B, devient beaucoup plus faible.
4.7.4 La métrique ND
La profondeur imbriquée ND est une métrique qui représente la position de chaque
activité dans le chemin d'exécution d’u processus métier. En d'autres termes, l'activité
qui s’e ute en amont dans le he i d’e utio du processus métier reçoit un coeffi-
cient plus élevé, tandis que, l'activité qui se produit plus tard dans le chemin de processus
métier reçoit un coefficient moins élevé.
Le degré de l'impact de chaque élément affecté par un changement peut être calculé
alors comme la somme de tous les IWF menant de l'entité changée à l’entité susceptible
d’ t e touchée. Par conséquent, nous disons qu'un chemin peut être marqué en rouge
lorsque le degré de l'impact est élevé, par exemple entre 15 et 20. On dit qu'un chemin
peut être marqué comme orange lorsque le degré de l'impact est moyen, par exemple
entre 10 et 15 et que le chemin peut être marqué comme vert lorsque le degré de l'im-
pact est faible, par exemple entre 1 et 10. Ces valeurs de seuils peuvent être définies par
les modeleurs et les experts métiers on se basant sur des études empiriques.
- 112 -
4.8 Modélisation de la propagation de l’impact du changement

Les résultats majeurs de recherche de notre approche se manifestent par deux princi-
paux constituants qui sont (i) une base de connaissances obtenue à partir de la définition
d’u e o tologie19 BPMN étendue décrivant la sémantique de l’e se le des l e ts
d’un processus métier et leurs interdépendances et (ii) une base de règles incarnant des
règles génériques dédiées à l’ tude a p io i de la faisa ilit d’u ha ge e t à u i sta t
T, mais aussi à la o p he sio et l’a al se du ha ge e t du p o essus tie et de
son impact.
4.8.1 La base de connaissances

La mise en œu e effective de l’a al se de l’i pa t du ha ge e t nécessite une des-
cription exhaustive des différents éléments d’u p o essus tie et leurs interdépen-
dances. Ainsi, l’utilisatio des bases de connaissances "Knowledge-Based" nous paraît
être le meilleur moyen qui peut aider dans la compréhension, à la fois du processus mé-
tier et de son évolution. De telles bases sont utilisées depuis plusieurs années dans le
cadre de la mise en œu e automatiquement assistée de différentes activités du génie
logiciel (Abd-El-Hafiz, 1996).
Pour faire face sémantiquement à l'analyse de l'impact du changement et par consé-
quent, à la compréhension des différentes relations de dépendance au sei d’u p o es-
sus métier, nous avons proposé dans (Kherbouche M. O., Ahmad, Bouneffa, & Basson,
2013) une approche consistant à mettre en œu e un système à base de connaissances
obtenu à pa ti de la d fi itio d’u e o tologie étendue appelé "Extended BPMN 2.0 On-
tology" pour le stockage et la manipulation des méta-informations concernant les proces-
sus métier.
En effet, notre définition se base sur une ontologie proposée par (Ghidini, Rospocher,
& Serafini, 2008) qui est utilisée comme une base de connaissances permettant de repré-
senter formellement les attributs et les conditions décrivant la manière dont les éléments
d’u p o essus tie peuvent être combinés pour obtenir des modèles BPMN con-
formes à la spécification.
L’app o he p opos e établit des liens entre les différents éléments du modèle de pro-
cessus métier et les concepts de l'ontologie basée sur les spécifications de BPMN 1.120.
Elle exprime chaque élément du modèle BPMN en tant qu’u e classe dans l'ontologie et
ses attributs en tant que des attributs de cette dernière. En effet, une ontologie est com-
posée de classes et de relations. Une classe représente un concept identifiable. Une
lasse peut a oi des lie s st u tu els et/ou s a ti ues a e d’aut es lasses.
L'ontologie proposée se compose actuellement de 95 classes, 108 objets de propriétés,
70 données de propriétés et 439 axiomes de classe. Les éléments sont divisés en deux
catégories représentant des éléments de support "Supporting Elements" et des éléments
graphiques "Graphical Elements" qui sont des sous-classes de la classe principale
"BPMN_ELEMENT" comme le montre la figure 4.3.
19
Une ontologie, en informatique, est un ensemble structuré de savoirs dans un domaine de connaissance particulier
20
www.omg.org/spec/BPMN/1.1/PDF.
- 113 -
Figure 4.3 Hiérarchie des classes de BPMN 2 Ontology
Dans notre ontologie étendue, nous avons redéfini la classe "BPMN_ELEMENT" en

ajoutant une troisième classe appelée analyse d'impact "Impact_Analysis" au même ni-
veau que la classe des éléments de support et la classe des éléments graphiques. Cette
classe est affinée par la suite en plusieurs relations de dépendance comme détaillée ci-
dessous d pe da es d’a ti it s "ACTIVITY_DEPENDENCY", dépendances de données
"DATA_DEPENDENCY").
Afin d’illustrer les différents axiomes de notre ontologie étendue dans leur forme lo-
gique, nous avons utilisé la logique de description (DL)21 sur laquelle se base le langage
d'ontologie Web (OWL22) qui est un dialecte XML qui étend RDFS et qui est utilisé pour
modéliser des ontologies. La redéfinition de la classe "BPMN_ELEMENT" est détaillée
dans le Listing 4.1.
La définition de la classe "Impact_Analysis", la classe "DEPENDENCY_RELATIONSHIPS",
la classe "ACTIVITY_DEPENDENCY" et la classe "DATA_DEPENDENCY" sont détaillées res-
pectivement dans les Listing 4.2, Listing 4.3, Listing 4.4 et Listing 4.5.
Listing 4.1 Classe BPMN_element.
Class: BPMN_ELEMENT
Label: BPMN element
Description: Base element
BPMN_ELEMENT GRAPHICAL_ELEMENT SUPPORTING_ELEMENT IMPACT_ANALYSIS
21
http://www.cs.ox.ac.uk/ian.horrocks/Seminars/download/Horrocks_Ian_pt1.pdf
22
http://www.w3.org/standards/techs/owl#w3c_all
- 114 -
GRAPHICAL_ELEMENT SUPPORTING_ELEMENT
GRAPHICAL_ELEMENT IMPACT_ANALYSIS
SUPPORTING_ELEMENT IMPACT_ANALYSIS
Listing 4.2 Classe IMPACT_ANALYSIS.
Class: IMPACT_ANALYSIS
Label: Impact analysis
Description: Impact analysis
IMPACT_ANALYSIS DEPENDENCY_RELATIONSHIPS
Listing 4.3 Classe DEPENDENCY_RELATIONSHIPS.
Class: DEPENDENCY_RELATIONSHIPS
Label: Dependency analysis
Description: Dependency relationship defines the existing dependencies concerning
activities and data
DEPENDENCY_RELATIONSHIPS ACTIVITY_DEPENDENCY DATA_DEPENDENCY
Listing 4.4 Classe ACTIVITY_DEPENDENCY.
Class: ACTIVITY_DEPENDENCY
Label: Impact analysis
Description: Activity Dependency
ACTIVITY_DEPENDENCY CONNECTING_OBJECT
ACTIVITY_DEPENDENCY ( ) has_connecting_activity_name
Property: has_connecting_activity_name
Label: Name
Description:Name is an attribute that is text description of the concerned acivi-
ty.
has_connecting_activity_name has domain ACTIVITY
has_connecting_activity_name has range xsd:string
ACTIVITY_DEPENDENCY ( )has_connecting_activity_source_ref.ACTIVITY ( )
has_connecting_activity_target_ref.ACTIVITY
Property: has_connecting_activity_source_ref
Label: aSourceRef
Description: aSourceRef is an attribute that identifies which Activity the
Connecting Object is connected from.
has_connecting_activity_source_ref has domain CONNECTING_OBJECT
has_connecting_activity_source_ref has range ACTIVITY
Property: has_connecting_activity_target_ref
Label: aTargetRef
Description: aTargetRef is an attribute that identifies which Activity the
Connecting Object is connected to.
has_connecting_activity_target_ref has domain CONNECTING_OBJECT
has_connecting_activity_target_ref has range ACTIVITY
Listing 4.5 Classe DATA_DEPENDENCY.
Class: DATA_DEPENDENCY
Label: Data Dependency
Description: Data Dependency
DATA_DEPENDENCY CONNECTING_OBJECT
DATA_DEPENDENCY ( )has_activity_input_sets.ACTIVITY ( )
has_activity_output_sets.ACTIVITY
has_activity_input_sets.ACTIVITY ≡ (DATA_OBJECT)
Pour valider cette partie du notre travail, nous avons utilisé une des plate-formes les
plus populaires appelé Protégé-OWL basé sur le langage d'ontologie Web (OWL). Cette
plate-forme est à la fois un éditeur d'ontologies, et un framework de base de connais-
sances très convivial, basé sur Java. La figure 4.4 montre la hiérarchie des classes (telles
qu'il apparaît dans l'outil Protégé) pour notre ontologie BPMN étendue, et la figure 4.5
représente le fichier OWL associé "ExtendedOntoBPMN.owl".
- 115 -
Figure 4.4 Hiérarchie des classes de extended BPMN 2 Ontology
Figure 4.5 Le fichier ExtendedOntoBPMN.owl
- 116 -
L'objectif principal étant de construire une base de connaissances à partir de cette on-
tologie pour permettre au chargé de l’ olutio des p o essus tie , qui est générale-
e t le odeleu et l’e pe t tie , de fo ule ses requêtes de changement.
Pour ce faire, le moteur qui répond à la demande du changement utilise le langage de
requête d'ontologie SPARQL23 pour analyser les relations de dépendance en déclenchant
toutes les gles d’a al se de d pe da e concernées expliquées dans la section sui-
vante. Ces relations de dépendance sont ensuite utilisées comme un moyen pour suivre la
propagatio de l’i pa t du ha ge e t.
4.8.2 Le système à base de règles

Le système à base de règles qu'on à mis en place assure deux principales fonctionnali-
tés. La première fonctionnalité est matérialisée par toutes les règles permettant
d’a al se la faisa ilit a priori d’u ha ge e t de p o essus tie à u i sta t T.
L’aut e fo tio alit est e apsul e pa les gles t aduisa t la p opagatio de l’i pa t
pa l’ide tifi atio des diff e tes e tit s et elatio s di e te e t ou i di e te e t af-
fectées par une opération de changement de processus métier.
Not e app o he de ise e œu e de ces règles est basée sur le formalisme Evéne-
ment-Condition-Action ou ECA. Partant de cette approche, nous avons défini un en-
semble de règles pour étudier en premier lieu, la faisa ilit d’u ha ge e t à un instant
T, et en second lieu, un aut e e se le de gles pe etta t l’a al se a priori de l’impact
du changement du processus métier.
Afin de fournir une approche générique, nous avons proposé un raisonnement de haut
niveau à l'aide d'une notation abstraite. Autrement dit, nous ne te o s pas o pte d’u e
notation particulière pour la modélisation des processus métier, mais nous prenons plu-
tôt en compte les éléments de base d'un processus.
4.8.2.1 Définition 1 (processus métier)
Un modèle de processus métier est représenté sous la fo e d’u g aphe orienté, où
les flu d’o jet ep se te t l’e se le des œuds et les flu de o t ôle représentent
l’e se le des a s. Il est ep se t pa le tuple Gp = (N, Type, F, S, D, Status) où:
 N = {n1, n2, … m} ep se te l’e se le fi i des œuds. Les œuds ep se te t
l’e se le des o jets de flu ou "Flow objects" qui peuvent être partitionnés en
trois catégories : les événements "Events" (E), les activités "Activities" (A) et les
passerelles "Gateways" (G) ;
 T pe: N → {A ti it , E e t, AND-Join/Split, XOR-Join/Split, OR-Join/Split} est une
fo tio ui assig e à ha ue œud u t pe;
 F ⊆ N × N (arcs du graphe) représente les flux de contrôle où "Connecting Objects"
e t e les diff e ts œuds tel ue : { , ’ ∈ F}. Ai si u a , ’ ep se te le
fait ue le œud ’ est le su esseu di e t du œud et pa o s ue t est le
p d esseu de ’;
 S est l’e se le des se i es i o u s par le processus ;
 D ep se te l’e se le des do es ;
23
http://jena.apache.org/tutorials/sparql.html
- 117 -
 Status  {init, waiting, added, deleted, modified} représente le statut courant de

ha ue œud n ∈ N dans le graphe Gp (traces de changement).
4.8.2.2 Définition 2 (instance d’un processus métier)
L'état d'une instance de processus métier est l'un des principaux critères pour déter-
miner si un changement structurel spécifique peut être appliqué à un instant T sans per-
turber le fonctionnement des i sta es e ou s d’e utio s. Par conséquent, nous pou-
vons définir une instance de processus métier I par le tuple I = (S, NS, Inst, Stat, Status)
où:
 S = (N, Type, F, Status) est le schéma de processus métier correspondant ;
 NS {NOT_ACTIVATED, ACTIVATED, RUNNING, COMPLETED, SKIPPED} est l'en-
semble des états d’u e i sta e d’u œud n ∈ N ;
 Inst: N  I est une fonction qui associe chaque œud n ∈ N avec son instance ;
 Stat: I  S est une fonction qui définit la relation entre une instance d'u œud n
∈ N et son état ;
 Status  {init, waiting, added, deleted, modified} représente le statut courant de
ha ue i sta e d’u œud n ∈ N dans le graphe Gp (traces de changement).
4.8.2.3 Définition 3 (activité)
Une activité ai ∈ A est définie par un le triplet A= (Input, Output, s) où Input D repré-
sente l'ensemble des entrées de ai, Output D représente l'ensemble des sorties de ai et
s ∈ S représente le service invoqué par ai.
4.8.3 Définition des règles de "faisabilité du changement"

Pou ga a ti la oh e e et la o fo it de l’e se le des i sta es de p o essus
métier avec le schéma de processus modifié, comme expliqué dans le chapitre 2, nous
avons défini un ensemble de règles de faisabilité (FR) pour évaluer a priori la faisabilité
d’u ha ge e t de p o essus tie à u i sta t T. L’e se le de es gles de ait
respecter quelques rudiments décrit ci-dessous :
 Afin d'éviter l'insertion d'une nouvelle tâche A comme un prédécesseur d'une
autre tâche B en cours d’e utio "RUNNING" ou achevé "COMPLETED", nous
devons nous assu e ue l’e se le des l e ts ui su de t à A soit en état
non-activé "NOT_ACTIVATED" ou activé "ACTIVATED". En revanche, les tâches qui
précèdent cette dernière peuvent être dans un état arbitraire.
 La suppression d'une tâche A d'une i sta e d’u processus métier en cours
d'exécution n'est possible que si A est en état non-activé "NOT_ACTIVATED" ou
activée "ACTIVATED", dans ce cas, les éléments associés à cette tâche sont sup-
primés à partir du modèle de processus métier correspondant. Tandis que, les
tâ hes e ou s d’e utio "RUNNING", achevée "COMPLETED", ou annulée
"SKIPPED" ne peuvent pas être supprimés (il ’est pas autorisé à supprimer une
tâche ou à modifier ses attributs si elle est déjà achevée).
- 118 -
4.8.3.1 Insertion d’un fragment de processus au niveau du schéma

La première règle tel que décrit dans l'algorithme 1 (cf. Listing 4.6) se déclenche quand
un modeleur tente d'ajouter un objet de flux (FOx) au niveau du schéma de processus mé-
tier.
La règle commence par vérifier tous les états des successeurs de FOx au niveau de
l’i sta e du p o essus métier concernée par le changement. Si ces instances sont tour-
nées vers un état non-activé "NOT_ACTIVATED" ou activée "ACTIVATED" alors le change-
ment peut être appliqué et le processus de la propagation de l'impact du changement
peut commencer. Dans ce cas, l’o jet de flu FOx et ses connecteurs sont marqués en
couleur verte pour notifier la faisabilité du changement et son statut est changé en "ad-
ded". Dans le cas contraire, FOx et ses connecteurs sont marqués en couleur rouge pour
notifier le fait que le changement peut être appliqué au niveau du schéma avec un risque
d’i oh e e dans la migration de ses instances vers ce nouveau schéma. Le statut de
FOx dans ce cas est changé en "waiting".
Listing 4.6 I se tio d u fragment de processus au niveau du schéma.
Input: N // set of nodes

Init: succs ← ∅
Begin
if FOx N then
/* Return all successors instances of FOx corresponding instance */
for Ii ∈ Inst(FOx)(i = 1,…,n)do
succs ← succs ∪ {Stat(Ii)};
end for
/* Verify the states of all successors instances of FOx corresponding
instance*/
for si ∈ succs(i = 1,…,n)do
if si ∈ {Not_Activated, Activated} then
/* Add FOx to a set of nodes N */
N ← N ∪ {FOx};
/* The change can be applied and the corresponding instances can be
Migrated correctly */
status(FOx,”added”);
/* FOx and the control flows (incoming and outgoing sequence flows) are
marked in green */
mark(FOx,GREEN);
mark (FC ∈ {Fsucc(FOx) ∪ Fpred(FOx)},GREEN);
/* Call impact analysis rules */
Call(Rule 06 Rule 07) ;
else
/*The change cannot be propagated immediately to the corresponding
instances*/
print(”the change cannot be applied to the”+ Inst(FOx) +”instance
immediately”);
status(FOx,”waiting”);
mark(FOx, RED) ;
mark (FC ∈ {Fsucc(FOx) ∪ Fpred(FOx)},RED);
end if
end for
end if
End
4.8.3.2 Suppression d’un fragment de processus au niveau du schéma

La deuxième règle telle que décrit dans l'algorithme 2 (cf. Listing 4.7) se déclenche
quand un modeleur tente de supprimer un objet de flux (FOx) au niveau du schéma de
- 119 -
processus métier. Dans ce cas, FOx est supprimé et son statut est changé en "deleted", si
les i sta es e ou s d’e utio so t tournées vers un état non-activé
"NOT_ACTIVATED" ou activée "ACTIVATED".
FOx est marqué aussi en couleur verte pour notifier la faisabilité du changement ainsi
que ses connecteurs. Dans le cas contraire, FOx et ses connecteurs sont marqués en cou-
leur rouge pour notifier le fait que la suppression de FOx peut être appliquée au niveau du
schéma avec u is ue d’i cohérence dans la migration de ses instances vers ce nouveau
schéma. Le statut de FOx dans ce cas est changé en "waiting".
Listing 4.7 Supp essio d u f ag e t de p o essus au iveau du s h a.

Init: S ← ∅
Begin
if FOx ∈ N then
S ← Stat(Inst(FOx));
/* Verification of corresponding instances states of FOx */
if S ∈ {Not_Activated, Activated} then
/* The change can be applied and the corresponding instances can be
migrated correctly */
status(FOx,”deleted”);
/* FOx and the control flows (incoming and outgoing sequence flows) are
marked in green */
mark(FOx,GREEN);
mark (FC ∈ {Fsucc(FOx) ∪ Fpred(FOx)},GREEN);
/* Call impact analysis rules */
Call(Rule 06 Rule 07) ;
/* Remove FOx from a set of nodes N */
N ← N-{FOx};
else
/*The change cannot be propagated immediately to the corresponding
instances*/
print(”the change cannot be applied to the”+ Inst(FOx) +”instance
immediately”);
status(FOx,”waiting”);
mark(FOx, RED) ;
mark (FC ∈ {Fsucc(FOx) ∪ Fpred(FOx)},RED);
end if
end if
End
4.8.3.3 Insertion et suppression d’un fragment de processus au niveau de l’instance

Afi d’a al se la faisa ilit d’u ha ge e t au i eau des i sta es Ix d’u p o essus
tie tel ue l’i se tio ou la supp essio d’u f ag e t de p o essus, les gles dé-
ites da s l’algo ith e cf. Listing 4.8) et l’algo ith e cf. Listing 4.9) sont déclen-
chées respectivement.
Listing 4.8 I se tio d u f ag e t de p o essus au iveau des i sta es

Init: succs ← ∅
Begin
/* Ix is concerned instance */
if Ix S then
for Ii ∈ Inst(FOx)(i = 1,…,n)do
succs ← succs ∪ {Ii};
end for
/* Verification of successors of corresponding instances */
for si ∈ succs(i = 1,…,n)do
- 120 -
if si ∈ {Not_Activated, Activated} then

/* The change can be applied */
status(Ix,”added”);
mark(Ix,GREEN);
else
/* The change cannot be applied */
print(”the change cannot be applied to the”+ Ix +”instance immediately”);
end if
end for
End
Listing 4.9 Supp essio d u f ag e t de p o essus au iveau des i sta es.

Init: I ← ∅
Begin
if Ix ∈ S then
I ← Inst(Ii);
/* Verification of corresponding instances stats */
if I ∈ {Not_Activated, Activated} then
/* The change can be applied */
status(Ix,”deleted”);
mark(Ix,GREEN);
else
/* The change cannot be applied */
print(”the change cannot be applied to the”+ Ix +”instance immediately”);
end if
end if
End
L’utilisatio de l’e se le des gles de faisa ilit du ha ge e t du p o essus tie

est illust e pa l’e e ple de la figure 4.6. Nous voulons dans cet exemple, ajouter
l’a ti it X et supprimer l’a ti it B au niveau du schéma du processus. Dans ce cas,
l'ajout de l'activité X ne peut pas être propagé immédiatement aux instances correspon-
dantes, puisque les instances qui succèdent à cette dernière sont déjà achevées. Tandis
que la suppression de l'activité B est possible, parce que le statut de son instance est
tourné vers un état non activé.
Figure 4.6 L ajout de l a tivit «X» et la supp essio de l'a tivit «B»
- 121 -
4.8.4 Définition des règles de propagation de l’impact du changement

Les règles de propagation d’i pa t du ha ge e t, que nous avons appelées aussi
gles d’i pl e tatio de la st at gie de p opagatio , utilisent en grande partie une
connaissance formalisé par une ontologie concernant les relations intra-couches et inter-
couches qui existent au sein d’un processus métier ainsi que la qualification de ces rela-
tions par des renseignements sur leu o du ti it de l’i pa t.
Partant de ce principe, nous avons défini un ensemble cohérent de règles qui permet
d’a al se la p opagatio de l’i pa t du hangement à t a e s l’a al se des relations de
dépendance, mais aussi un processus générique de marquage des éléments affectés par
le changement qui se repose principalement sur l’appli atio de es gles. Ces règles
seront définies de façon algorithmique.
4.8.4.1 Règle d’analyse des dépendances intra-couche (analyse des dépendances
d’activités)
L’algo ith e 5 (cf. Listing 4.10), présente la première règle qui permet de propager
l’i pa t d’u ha ge e t à t a e s l’a al se des d pe da es d’a ti it . Cette règle est
d le h e lo s d’u ajout, odifi atio ou suppression d’u flu d’o jets FOx à partir
d'un schéma de processus métier. La gle o siste à a ue le œud o espo da t à
FOx dans le graphe et ses connecteurs. Les ensembles ₯o(FOx) et ₯i(FOx) ainsi que les
flux de contrôle associés sont à leurs tours marqués pour exprimer la profondeur de l'im-
pact du changement qui est calculée sur la base du facteur de pondération (IWF).
Listing 4.10 ‘ gle d a al se de l i pa t intra-couche a al se des d pe da es d a tivit s .

Init: ₯o ← ∅, ₯i ← ∅
Begin
if Status (FOx) == ”added” || ”deleted” || ”modified” then
mark(FOx);
mark (F ∈ {Ωi(FOx) ∪ Ωo(FOx)});
/* Dpo gets successively each succeeding activities depends on FOx and the
corresponding routing relationships in N */
for all ai ∈ N (i = 1,…,n) do
/* ai depend on FOx */
if ai → FOx then
Dpo ← Dpo U {ai}
/* Compute the chance of impact for ai ∈ Dpo */
IWF ← CalcIWF(ai);
pathImp ← calcPathImpact(execPath(ai),IWF);
putInMap(ai, pathImp) ;
end if
end for
/* Dpi gets successively each preceding activities which FOx depends on and the
corresponding routing relationships in N */
for all ai ∈ N (i = 1,…, n) do
/* FOx depend on ai */
if FOx → ai then
Dpi ← Dpi U {ai};
/* Compute the chance of impact for ai ∈ Dpi */
IWF← CalcIWF(ai);
end if
end for
for all ai ∈ Dpo U Dpi (i = 1,…,n) do
- 122 -
ImpactPow ← getFromMap(ai) ;
clr ← getColorPathImpact(ImpactPow);
mark(ai, clr) ;
mark(F ∈ {Ωi(ai) ∪ Ωo(ai)}, clr)
end for
end if
End
4.8.4.2 Règle d’analyse des dépendances intra-couche (analyse des dépendances de

données)
L’algo ith e 6 (cf. Listing 4.11), présente la deuxième règle qui permet de propager
l’i pa t d’u ha ge e t à t a e s l’a al se des d pe da es de do es et ui est
complémentaire à la première règle. Dans cet algorithme, OutputDs représente
l’e se le des do es D produites par FOx, AllOutDep ep se te l’e se le des a ti i-
tés qui dépendent de D. Tandis que InputDs est l’e se le des do es D utilisées par
FOx et AllInDep est l’e se le d'a ti it s do t les do es p oduites so t utilis es pa
FOx.
Listing 4.11 ‘ gle d a al se de l i pa t i t a-couche (analyse des dépendances de données).

Init : OutputDs ← ∅, AllOutDep ← ∅, InputDs ← ∅, AllInDep ← ∅
Begin
if Status (FOx) ==”added” ||”deleted” ||”modified” then
mark(FOx);
for all Di∈ OutPARs(FOx) (i = 1,…, n) do
OutputDs ← OutputDs U {Di}
end for
for all Di ∈ OutputDs(i = 1,…, n) do
mark(Di);
mark(F ∈ {Ωi(Di) ∪ Ωo(Di)});
/* AllOutDep gets successively each activities which depend on output data
of the given activity FOx in N */
for all aj ∈ N( j = 1,…,n) do
/* aj depend on D produced by FOx */
If aj (D) FOx then
AllOutDep ← AllOutDep ∪ {ai}
/* Compute the chance of impact for ai ∈ AllOutDep */
IWF ← CalcIWF(ai);
end if
end for
end for
for all Di∈ InPARs(FOx)(i = 1,…, n) do
InputDs ← InputDs ∪ {Di}
end for
for all Di ∈ InputDs(i = 1,…,n) do
mark(Di);
mark(F ∈ {Ωi(Di) ∪ Ωo(Di)});
/* AllInDep gets successively each Activities where the output data is the
input data of given activity FOx in N */
for all aj ∈ N( j = 1,…,n) do
/* FOx depend on D produced by aj */
if FOx (D) aj then
AllInDep ← AllInDep ∪ {aj}
/* Compute the chance of impact for aj ∈ AllInDep */
IWF ← CalcIWF(aj);
pathImp ← calcPathImpact(execPath(aj),IWF);
putInMap(aj, pathImp);
- 123 -
end if
end for
for all ak ∈ ALLInDep U ALLOutDep(k = 1,…, n) do
ImpactPow ← getFromMap(ak) ;
clr ← getColorPathImpact (ImpactPow);
mark(ak, clr) ;
mark(F ∈ {Ωi(ak) ∪ Ωo(ak)} , clr);
end for
end for
end if
End
4.8.4.3 Règle d’analyse des dépendances inter-couche

La troisième règle telle que décrit dans l'algorithme 7 (cf. Listing 4.12) analyse la pro-
pagation de l'impact entre la couche métier et la couche services. ₯s(FOx) représente
l’ensemble de tous les services invoqués par FOx. Tous les services invoqués et les connec-
teurs correspondants (invocation de service) sont marqués pour exprimer la profondeur
de l'impact des changements.
Listing 4.12 ‘ gle d a al se de l i pa t i te -couche.

Init: ₯s ← ∅
Begin
if Status (FOx) ==”added” ||”deleted” ||”modified” then
mark(FOx);
/* Dps gets each services invoked by FOx and the corresponding routing
relationships */
for all si ∈ S (i = 1,…, n) do
/* si is invoked by FOx */
if FOx ⇝ si then
Dps ← Dps U {si}
/* Compute the chance of impact for si ∈ Dps */
IWF ← CalcIWF(si);
pathImp ← calcPathImpact(invokepath(si),IWF);
putInMap(si, pathImp) ;
end if
end for
for all si → Dps (i = 1,…,n) do
ImpactPow ← getFromMap(si) ;
clr ← getColorPathImpact(ImpactPow);
mark(si,clr) ;
mark(F ∈ {r(FOx,si)},clr)
end for
end if
End
4.9 Conclusion
L’a al se de l’i pa t du ha ge e t est u e tape t s i po ta te dans la gestion de
l’ olutio des processus métier. Elle permet d’a oît e la p ise de o s ie e des diffé-
rents acteurs afin d'éviter les effets secondaires et d’estimer les effets de vagues du
changement concerné.
Dans ce chapitre, nous avons présenté une méthode permettant l’a al se a priori de
l’i pa t du ha ge e t des processus métier à travers une approche basée sur une défi-
- 124 -
nition de la relation de dépendance tenant compte des spécificités de modélisation de ces

processus. En effet, nous avons proposé une classification exhaustive des différentes rela-
tions de dépendance qui peuvent exister au sei d’u p o essus tie , l’o je tif ta t
d’off i u e eilleu e ide tifi atio de leu ôle da s la p opagatio de l’i pa t du han-
gement.
Le chapitre a décrit ensuite en détail, le p o essus de p opagatio de l’i pa t du han-
gement à travers ces relations de dépendance, pour cela un ensemble de métriques est
proposé afin de calculer la profondeur de la propagation de l'impact tout en faisant la
disti tio e t e les e tit s i pa t es e te es de puissa e d’i pa t.
Nous avons ensuite p opos u e od lisatio de ette p opagatio de l’i pa t à tra-
vers deux constituants qui sont une base de connaissances obtenue à partir de la défini-
tio d’u e o tologie te due d i a t u e s a ti ue de l’e se le des l e ts d’u
processus métier et leurs interdépendances et une base de règles incarnant un ensemble
de règles d di es à l’ tude a priori de la faisa ilit d’u ha ge e t à u i sta t T, ais
aussi à la o p he sio et à l’a al se du ha ge e t du p o essus tie et de so
impact.
L’o je tif p i ipal ta t de d te i e a priori la o du tio de l’i pa t du change-
ment depuis une entité modifiée e s d’aut es entités sus epti les d’ t e affectés par la
modification. La plate-forme développée selon la modélisation proposée est conçue pour
permettre au odeleu s et au e pe ts tie s d’ alue le is ue associé à de tels
changements et d'estimer ainsi l'effort requis pour leurs réalisations.
Dans le chapitre suivant, nous allons présenter le troisième axe de notre contribution
qui est la gestion qualitative des processus métier durant leur cycle de vie et plus particu-
lièrement, après chaque changement.
- 125 -
CHAPITRE
5
La gestion qualitative des processus
métier
5. La gestion qualitative des processus métier
5.1 Introduction
La modélisation et l'amélioration de la qualité des processus métier ont connu un inté-
rêt croissant durant ces dernières décennies. En effet, les entreprises ont pris conscience
de l'impact indéniable que peuvent procurer une meilleure compréhension et une meil-
leure gestion de la qualité des processus métier en matière d'efficacité, de cohérence et
de transparence de leurs activités. Cet intérêt est appuyé par la norme ISO9000 qui re-
o a de d’ alue guli e e t la ualit des p o essus tie de l’e t ep ise afi de
pouvoir les surveiller et les améliorer (Morley, Hugues, Leblanc, & Hugues, 2004).
À cet ga d, l’ aluatio pe a e te de la qualité des processus métier et en particu-
lier celle des modèles de processus métier est l'une des exigences de toute mise en
œu e réussie d’u ensemble de p o essus au sei d’u e e t ep ise. En effet, obtenir des
modèles compréhensibles, réutilisables et facilement maintenables permet de minimiser
les défauts de conception et d’éviter des dysfonctionnements susceptibles de se produire
une fois les processus déployés.
Da s l’opti ue d’u e telle aluatio , u e a i t de caractéristiques (Guceglioglu &
Demirors, 2005), (Heravizadeh, Mendling, & Rosemann, 2009) et de métriques (Aguilar,
Cardoso, García, Ruiz, & Piattini, 2009), (Aguilar, Ruiz, García, & Piattini, 2006),
(Vanderfeesten, Cardoso, & Reijers, 2007) ont récemment été proposés afin de gérer,
mesurer et / ou d'améliorer la qualité des modèles de processus métier. La majorité de
ces travaux focalisent sur l’aspe t st u tu el de ces modèles, consistant ainsi à évaluer
certaines caractéristiques de la qualité telle que la compréhensibilité "understandability"
et la facilité de modification "modifiability" qui appartiennent respectivement aux con-
cepts plus généraux de la facilité d'utilisation "usability" et de la maintenabilité "maintai-
nability", respectivement.
Dans ce chapitre, nous proposons une approche plus exhaustive inspirée par la norme
ISO / CEI 9126-1 utilisant un ensemble pertinent de facteurs, de critères et de métriques,
permettant ainsi une meilleure aluatio de la ualit glo ale d’un processus métier, et
cela durant tout son cycle de vie et plus particulièrement après chaque changement de ce
dernier.
En effet, nous nous intéressons tout particulièrement dans ce chapitre à l’i pa t du
changement de la structure des processus métier sur la qualité, ce que nous appelons
l’impact qualitatif du ha ge e t. Le o e de odifi atio s d’u processus peut être
un indicateur important du taux de défaillance de ce processus, de sa stabilité et de sa
o ple it . Nous dis ute o s l’a al se de la p opagatio des i pa ts st u tu els et quali-
tatifs des changements. Notre objectif est de proposer une approche systématique de
mise en œu e de changements « réussis », e d’aut es te es de minimiser les risques
de dégradations de la qualité engendrés par les changements.
Le reste du chapitre est organisé comme suit : la section 5.2 met en exergue les enjeux
de l’ aluatio de la qualité des processus métier. La section 5.3 explore la notion
d’ aluatio de la ualit des p o essus tie a e une synthèse de l’ tat de l’a t des
différentes approches et métriques existantes permettant de mener une telle évaluation.
La section 5.4 explicite en détail l’ la o atio de l’app o he ue ous p oposo s à l’aide
d’u e e ple. La se tio . e plo e la otio d’ aluatio de la ualit a e l’aide du
- 127 -
od le ualitatif de l’ olutio du p o essus tie . Dans la section 5.6 nous concluons

le chapitre en soulignant les perspectives de notre travail.
5.2 Gestion qualitative des processus métier

La norme (ISO 9000:2000, 2005) définit la qualité comme « l’aptitude d’u e se le
de caractéristiques intrinsèques à satisfaire des exigences». Partant de ce constat, la ges-
tion de la qualité des logiciels a fait l’o jet de nombreux travaux de recherche. Le princi-
pal objectif de ces recherches a consisté à proposer un ensemble de méthodes (Boehm,
Brown, & Lipow, 1976), (Cavano & McCall, 1978), (Ishikawa, 1985), (Wong & Jeffery,
2001), de standards (Wong & Jeffery, 1995) (ISO/IEC 9126-1, 2001) et d’outils permettant
de gérer, mesurer, surveiller et améliorer la qualité des logiciels.
Plus récemment, la gestion de la qualité des processus métier et plus précisément celle
des modèles de processus métier a constitué un sujet de recherche très actif. Le but est
de mettre en place un mécanisme efficace qui permet d’a lio e la compréhension, la
fiabilité et la réutilisation de ses modèles de processus métier durant tout leur cycle de
vie, et plus particulièrement, après chaque changement.
En effet, l'obtention d'un modèle de processus métier de haute qualité réduit considé-
rablement les défauts de conception et les dysfonctionnements qui peuvent se produire
une fois les processus déployés. Dans ce contexte, l’ olutio d’u modèle de processus
métier sans dégradation de la qualité dépend en grande partie de la compréhension des
relations qui existent entre la propagation de l'impact du changement structurel et quali-
tatif. Ainsi, les changements de la structure d’un modèle de processus métier peuvent
avoir des effets sur la qualité originelle de ce dernier. On observe en effet, une tendance
à une dégradation de la qualité du modèle de processus métier proportionnelle à
l’a oisse e t de sa taille et de sa o ple it ui est u e o s ue e des additio s de
nouvelles activités et de nouvelles connexions entre ces activités se traduisant, générale-
ment, par une modification de sa structure. La structure du modèle de processus métier
et par conséquent sa qualité change donc avec le développement de ces activités. Il est
donc impératif da s e o te te d’ alue l’a lio atio ou la d g adatio de la ualit
des processus métier après chaque changement.
5.3 Évaluation de la qualité des modèles de processus métier

La aluatio guli e de la ualit du p o essus da s l’o je tif d’e sui e
l’ olutio est l'u e des e ige es de toute ise e œu e ussie d’u e se le de p o-
essus au sei d’u e e t ep ise. Bien qu'il n'existe pas de définition standard de la qualité
d’u processus métier, di e ses app o hes pou l’évaluation de cette qualité ont été pro-
posées dans la littérature. Notre étude nous a permis de les classer en trois catégories :
les approches centrées sur les méthodes, les approches centrées sur l’évaluation de la
qualité des processus métier et les approches centrées su l’évaluation de la qualité des
modèles de processus métier.
- 128 -
5.3.1 Tour d’horizon des approches existantes

Les approches centrées sur les méthodes sont des recherches qui proposent des
guides méthodologiques et des bonnes pratiques pour assurer la qualité des modèles de
processus métier. Dans (Becker, Rosemann, & von Uthmann, 2000) les auteurs proposent
un ensemble de guides pour améliorer certaines caractéristiques de qualité telle que
l’e a titude, la o p he sio des modèles de processus métier. D’aut es auteu s p opo-
sent des patrons de conception réutilisables qui aident à produire des modèles de proces-
sus métier (van der Aalst W. , ter Hofstede, Kiepuszewski, & Barros, 2003).
La deuxième catégorie centrée sur l’évaluation de la qualité des processus métier
s'intéresse à es de ie s au i eau de leu e utio et de leu o t ôle. L’o je tif p in-
cipal étant de proposer des te h i ues pou la ifi atio , la alidatio et l’a lio atio
des performances des processus métier. Dans (Heravizadeh, Mendling, & Rosemann,
2009) les auteurs ont présenté une approche appelée QoBP pe etta t d’ alue la ua-
lit des p o essus tie . L’app o he représente un moyen pour capturer certaines di-
e sio s de la ualit d’u p o essus. Elle définit quatre catégories de la qualité des pro-
cessus métier qui sont la qualité des fonctions, la qualité des entrées et des sorties
d’o jets et la qualité des ressources humaines et non-humaines. Guceglioglu et Demirors
dans (Guceglioglu & Demirors, 2005) utilisent un ensemble de caractéristiques de qualité
adopté de la o e ISO/IEC 9 pou esu e les effets d’u s st e d’i fo atio su
les processus métier et par conséquent la qualité des processus métier. Le travail de
(Heinrich & Paech, 2010), qui est similaire à celui de Guceglioglu et Demirors dans la dé-
marche, propose un autre ensemble de caractéristiques supplémentaires toujours inspiré
par la norme ISO/IEC 9126 qui couvrent d’autres aspects du processus métier tels que les
acteurs et les ressources en plus des activités et qui participent à l’ aluatio de la qualité
glo ale d’u p o essus tie .
La troisième catégorie e t e su l’ aluatio de la ualit des od les de p o essus
métier passe souvent par la mesure de la qualité à travers la définition d’u e se le de
métriques de qualité inspiré du domaine des produits logiciels. Les approches qui
s’i s i e t da s e courant justifient cette utilisation de métriques par les similitudes
structurelles existantes entre un processus métier et un produit logiciel comme le montre
la Table 5.1.
En effet, le concept de métriques de processus a d'abord été introduit dans (Cardoso J.
, 2005) pour fournir une base quantitative pour la conception, le développement, la vali-
dation et l'analyse des modèles de processus métier. Plus tard, ce concept a été connu
sous le nom de "Business Process Quality Metrics" (BPQM).
Dans (Gruhn & Laue, 2006) les auteu s o t p se t u e se le d’e u tes où ils o t
étudié l'importance de l'exactitude des modèles de processus métier d'un point de vue
empirique. Ils ont défini deux métriques qui quantifient la bonne organisation structurelle
"structuredness". Van Belle dans (Van Belle, 2004) décrit un cadre permettant l'évaluation
et la comparaison des modèles de processus métier en se basant sur une analyse syn-
taxique, sémantique et pragmatique. Ils mentionnent cinq des mesures u’ils considèrent
importantes : couplage, cohésion, complexité, modularité, et taille.
- 129 -
Les produits logiciels Les processus métier

Module/Class Processus/sous processus
Méthodes/Fonctions Activité/Tâche
Variables / constantes Données
Appel de méthode Réception d'un flux de séquence ou d'un flux de
messages par une des tâches ou un des événe-
ments
Commentaires Annotations
Interfaces L'ensemble des tâches d'un processus ou d'un
sous-processus qui peuvent envoyer ou recevoir
un flux de messages.
Table 5.1 Les similitudes entre les produits logiciels et les processus métier.
Dans la même optique, d’autres travaux de recherche comme ceux détaillés ci-dessous
ont été proposés dans la littérature pour évaluer la complexité, le couplage, la cohérence,
la modularité, et la taille d’u od le de p o essus tie .
5.3.1.1 Mesurer la complexité d’un modèle de processus métier
La complexité mesure la simplicité "simpleness" et la compréhensibilité "understan-
dability" d’u od le de processus métier. Cardoso et al. (Cardoso, Mendling, Neumann,
& Reijers, 2006), ont ide tifi t ois t pes de o ple it d’u processus métier: (i) la com-
plexité des calculs " computational complexity", (ii) la complexité psychologique, "psycho-
logical complexity" et (iii) la complexité de représentation "representational complexity".
La première métrique présentée dans la littérature, qui est adaptée du nombre cyclo-
matic de McCabe (McCabe, 1976), permet de mesurer la complexité d’un flux de contrôle
au sei d’u od le de p o essus tie . Cette métrique est appelée "Control Flow Com-
plexity" (CFC) (Cardoso, Mendling, Neumann, & Reijers, 2006).
L'idée principale derrière cette métrique est d'évaluer la complexité introduite dans un
processus par la présence de passerelles tel que XOR-Split, OR-Split et AND-Split.
Ainsi, pour une passerelle XOR-Split, le CFC d’u flu de o t ôle est tout simplement
le nombre de points de sortie "fan-out" de la scission. Il est noté comme suit:
CFCXOR-split (a) = fan-out (a)
Pour une passerelle OR-split, le CFC d’u flu de o t ôle est de -1, où n représente
les points de sortie "fan-out" de la scission. Il est noté par:
CFCOR-split(a)= 2 fan-out(a) - 1
Pour une passerelle AND-split, le CFC d’u flu de o t ôle est de :
CFCAND-split (a) = 1
Mathématiquement, la métrique CFC est additionnelle. Ainsi, il est très facile de calcu-
ler la complexité d'un modèle de processus métier, pa l’additio des diff e ts CFC de
toutes les scissions dans le modèle de processus métier.
CFC (P) = ΣnI=0 CFCXOR-split (i) + Σj=0
n
CFCOR-split (j) + Σk=0
n
CFCAND-split (k)
- 130 -
Pour tester la validité de cette métrique, une expérience basée sur les propriétés de
Weyuker a été réalisée à travers une validation empirique (Cardoso J. , 2005). Il était
constaté que la métrique CFC est fortement corrélée avec la complexité du flux de con-
trôle d'un processus.
La métrique de cyclicité (CYC) proposée dans (Heravizadeh, Mendling, & Rosemann,
2009) o pte le atio e t e le o e de œuds a ti it s et passe elles da s u le
NNC et le o e total de œuds (TNN) dans un modèle de processus métier comme
suit :
CYC = NNC / TNN
Mendling propose dans (Mendling J. , 2006) une métrique dite de densité "Density me-
t i " i spi e pa l'a al se des seau so iau afi de ua tifie la o ple it d’u o-
d le de p o essus tie e p i à l’aide du diag a e EPC. Dans (Cardoso J. , 2005)
l'auteur présente une métrique permettant de mesurer la complexité du flux de données
des modèles de processus métier. Gruhn et Laue (Gruhn & Laue, 2006) utilisent la notion
de poids cognitifs "cognitive weights" comme une structure basique de contrôle pour me-
su e la diffi ult de la o p he sio d’u e st u tu e de o t ôle d’u o kflo .
5.3.1.2 Mesurer le couplage d’un modèle de processus métier
La notion de couplage dans les modèles de processus métier se réfère à la façon dont
les activités d'un processus métier sont liées ou connectées. Une activité est dite connec-
tée à une autre activité, si et seulement si elles partagent un ou plusieurs éléments
d’i fo atio telle ue des do es. La métrique de couplage d’u e activité détermine le
o e total d’activités qui lui sont liées (Vanderfeesten, Cardoso, & Reijers, 2007).
Pour un modèle de processus métier lambda, la métrique de couplage est égal au
nombre d'interconnexions entre toutes ses activités, en d'autres thèmes, cette métrique
compte toutes les paires d'activités dans le modèle de processus métier qui sont liées
l’u e à autre. En outre, le degré de couplage dépend de la complexité et du type de con-
nexions entre les activités (AND, OR, XOR).
La métrique de couplage d'une activité reflète la façon dont une activité critique ou
importante se situe dans un modèle de processus métier. En fait, une activité avec une
valeur de couplage élevée détermine le fonctionnement d’un grand nombre d’aut es ac-
tivités dans le processus métier. Ainsi, son dysfonctionnement peut causer le dysfonc-
tionnement de plusieurs autres activités. Ceci peut compromettre le fonctionnement glo-
bal du processus. Ce genre d’activités devrait être soit évitée dans un modèle de proces-
sus métier, ou traitée avec un soin particulier, par exemple, en ayant une action de con-
trôle pour cela.
D'autre part, un modèle de processus métier avec une valeur de couplage élevé in-
dique un niveau élevé de dépendances informationnelles entre ses activités ce qui rend le
processus vulnérable et sa maintenabilité difficile.
Une limite de la métrique de couplage est qu'elle ne donne pas une indication sur la
réutilisabilité d'un BPM. Cette caractéristique de qualité est importante pour la concep-
tion d’u modèle réutilisable. Une deuxième limite est axée sur les données échangées.
En effet, les informations sur la dépendance de l'activité en termes d'utilisation de don-
- 131 -
nées ne sont pas fournies. Cette métrique de couplage orientée donnée est complétée
par la métrique de cohésion décrite dans la section suivante.
5.3.1.3 Mesurer la cohésion d’un modèle de processus métier
Vanderfeesten et al. (Vanderfeesten, Reijers, & van der Alst, 2008), définissent la mé-
trique de cohésion comme le produit à la fois de la cohésion de la relation et de
l’information d’u e a ti it . Cela signifie que, pour chaque activité dans le modèle de
processus métier, la cohésion totale est calculée en multipliant la cohésion de l'informa-
tion et la cohésion de la relation de l'activité.
La elatio de oh sio ua tifie o ie d’op atio s diff e tes so t li es au sein
d'une activité. Cela détermine pour chaque opération d'une activité, combien d'autres
opérations partagent une entrée ou de sortie avec cette dernière. D'autre part, la cohé-
sion de l'information se concentre sur l'ensemble des éléments d'information qui sont
utilisés comme entrée ou de sortie par une opération à l'intérieur de cette activité.
La cohésion d’un modèle de processus métier représente le ratio entre la moyenne de
toutes les valeurs de cohésion d'activité (additionnant toutes les valeurs de cohésion) par
le nombre d'activités. La valeur de cette métrique de cohésion est toujours comprise
entre 0 et 1.
Cette proposition est appuyée par le travail de Reijers et Vanderfeesten (Reijers &
Vanderfeesten, 2004) qui proposent une métrique de cohésion qui calcule le degré de
couplage et de cohésion dans les modèles BOM (Bill Of Materials) en analysant les élé-
ments de données.
5.3.1.4 Mesurer la modularité d’un modèle de processus métier
La métrique de modularité M (Gruhn & Laue, 2006) o e so o l’i di ue est utili-
sée pour évaluer la modularité du modèle de processus métier. Elle est calculée comme
suit :
M = (fan-in * fan-out)2
Où fan-in représente tous les modules (ex : sous-processus) qui font appel à un autre
module m dans le modèle de processus métier et fan-out représente tous les modules qui
so t appel s à pa ti d’u odule m.
5.3.1.5 Mesurer la taille d’un modèle de processus métier
Les auteurs dans (Cardoso, Mendling, Neumann, & Reijers, 2006) proposent d'adapter
les t i ues de alstead pou esu e la taille d’u od le de p o essus tie . Cela
passe par le calcul de la longueur N, le volume V et la difficulté D d'un modèle de proces-
sus métier. Elles sont appelées "Halstead-based Process Complexity" (HPC) et calculées
comme suit:
N = n1 * log2 (N1) + N2 * log2 (n2)
V = (N1 + N2) * log2 (n1 + n2)
D = (n1 / 2) * (N2 / N2)
où:
- 132 -
 n1 représente le nombre distincts d’a ti it s, de passe elles, et de flu de o t ôle

d'un modèle de processus métier.
 n2 représente le nombre distincts de données manipulées par le processus et ses
activités.
 N1 et N2 représentent respectivement le nombre total des éléments et des don-
es d’u od le de p o essus tie espe ti e e t.
Dans le même travail, le nombre d'activités (tâches et sous-processus) (NOA) et le
nombre d'activités et des flux de contrôle (NOAC) dans un modèle de processus métier
sont deux métriques de complexité supplémentaires adaptées de la métrique LOC "Line
Of Code" (Fenton & Pfleeger, 1998) qui permet de mesurer le nombre de lignes de code
d’u p oduit logi iel. La p e i e t i ue est u e pu e adaptatio ui o pte le
nombre d'activités dans un modèle de processus métier sans tenir compte de la fonction-
nalité et de la complexité tandis que la seconde tient compte de ces deux caractéris-
tiques.
E o lusio de e tou d’ho izo , ous a o s o stat ue l’e se le des t i ues
p opos es da s la litt atu e se fo alise t su l’aspe t st u tu el des od les de p o es-
sus tie plutôt ue l’aspe t s a ti ue et/ou o po te e tal de es de ie s.
Dans la section suivante, nous allons proposer une approche plus exhaustive inspirée
par la norme ISO / CEI 9126-1 qui utilisent un ensemble pertinent de dimensions, de cri-
tères et de métriques permettant ainsi de mesurer la qualité des processus métier allant
au-delà des o sid atio s pu e e t s ta i ues ais i t g a t aussi l’aspe t séman-
tique et comportemental des processus métier.
5.4 L’approche proposée

La qualité globale du logiciel est généralement alu e o e le sultat d’u e a-
luation sur trois niveaux (Facteurs, Critères, et Métriques). Les facteurs représentent gé-
néralement un des besoins non-fonctionnels exprimés pa l’utilisateu tels ue la facilité
d’usage "Usability" ou la fiabilité "Reliability", etc. Ils représentent des attributs de la qua-
lit du poi t de ue e te e. E d’aut es te es, ce sont des attributs extérieurement
appréciables alors que les critères représentent des considérations plus détaillées ou
techniques. Autrement dit, des attributs internes. Ils ne sont généralement pas appré-
ciables ou non visibles pa l’utilisateu du logi iel. Ils expriment des perspectives de la
qualité o e a t le d eloppeu et l’i g ieu e assu a e ualit . Pa i ces critères,
nous pouvons citer la modularité "Modularity" comme exemple. Si l’o o sid e u o-
dèle de qualité comme un arbre où les œuds so t les fa teu s F affi s pa des i-
tères (C) mesurés par des métriques (M) (Mccall, Cavano, & Walters, 1977), ces dernières
représenteraient donc les feuilles de cet arbre. Elles servent à mesurer et/ou estimer les
différents critères.
Soit donc G(X, U) le graphe FCM (Facteurs, Critères, Métriques) de la qualité établi
pour une application lambda. L’e se le X des œuds du g aphe G(X, U) de la qualité
peut donc être défini par :
X = X0 ∪ Σ F ∪ Σ C ∪ Σ M
- 133 -
 X0 est la a i e du g aphe. Il ep se te l’ l e t le plus a st ait de la ualit

u’o appelle a la ualit glo ale du p o essus tie . Il correspond au niveau 0
du raffinement.
 ΣF = {f1, f2,…, fn} est l’e se le des fa teu s o stitua t le p e ie affi e e t de
la qualité générale. C’est le i eau du affi e e t.
 ΣC = {c1, c2, …, n} ep se te l’e se le des it es affi a t les fa teu s. C’est le
niveau 2 du raffinement.
 ΣM = {m1, , …, n} ep se te l’e se le des t i ues pe etta t u e a-
luation quantitative et/ou qualitative des critères.
Dans cette section, nous allons proposer un cadre exhaustif inspiré par la norme ISO/
CEI 9126-1 représentant à la fois une contribution à la maturité des travaux existants à
l' ga d de l’ aluatio et de l'a lio atio de la ualit des p o essus tie et un moyen
de traçabilité de l’i pa t ualitatif du ha ge e t d’u p o essus tie durant son
cycle de vie.
En effet, pour analyser les a iatio s de la ualit da s le ad e d’u e a al se ualita-
tive des changements des processus métier, nous tenons compte des dépendances entre
Fa teu s et C it es. Cela peut aide les odeleu s et les e pe ts tie s à t a e l’i pa t
sur la qualité et ela da s le se s d’u e a lio atio ou d t io atio d’u fa teu de
cette qualité.
Dans notre approche, nous avons identifié quatre niveaux hiérarchiques comme le
montre la figure 5.1. Le premier niveau représente la ualit glo ale d’u p o essus é-
tier (la racine) nommé BPMQ "Business Process Models Quality" qui dépend de l'évalua-
tio d’u e se le de fa teu s ou de di e sio s ui sont la performance, l'efficacité, la
fiabilité, les ressources et les acteurs et qui se trouvent dans un niveau inférieur. Les cri-
tères de qualité sont regroupés en dimensions de qualité, chaque dimension représentant
une facette de la qualité des processus métier. Par conséquent, un critère de qualité re-
présente un aspect particulier d'une dimension donnée. Un critère de qualité est associé
à un ensemble de métriques classées en couches pe etta t de l’évaluer de manière effi-
cace.
Not e app o he off e aussi la possi ilit d’ alue la ualit de se i e QoS fou ie pa
le processus métier à travers des facteurs tels que la performance et tient aussi compte
de certains facteurs de qualité qui sont souvent négligés dans l'évaluation qualitative glo-
bale même si elles ont une importance significative, par exemple les ressources et des
acteurs.
L’app o he p opos e peut t e te due à d'aut es di e sio s de la ualit e ista t
dans la littérature telle que la facilité d'utilisation "usability" et de maintenabilité "main-
tainability" ui peu e t s’ajoute à l’e se le p opos s. Da s e ui suit, ous allons dé-
crire chacun des facteurs, des critères, et des mesures sélectionnées.
- 134 -
Racine
BPMQ
Facteurs
Niveau
F1 F2 …. Fn
Critères
Niveau
C1 C2 …. Cn
(UDM)
(DM)
Métriques
Niveau
(BMS)
(BMS) : Ensemble des métriques de base

(DM) : Ensemble des métriques dérivées
(UDM) : Ensemble des métriques définies par l’utilisateu
Figure 5.1 Représentation arborescente des facteurs, critères et métriques.
5.4.1 Efficacité "Efficiency"

L'effi a it est o sid e o e l’u des l e ts fo da e tau d’u ie fondé de
tout processus métier. Elle ep se te la apa it d’u p o essus tie à fournir une
performance appropriée, par rapport à la quantité de ressources utilisées ainsi que la du-
e d’utilisatio pa les diff e ts a teu s sous des o ditio s sp ifi ues.
L'efficacité est raffinée en plusieurs critères qui sont : l’effi a it du temps de réalisa-
tio , l’effi a it des essou es e plo es, et l’effi a it des oûts.
5.4.1.1 L’efficacité du temps de réalisation "Time Behaviour"
La apa it d’u p o essus tie à fou i u e po se app op i e da s u d lai ai-
sonnable lors de l’e utio de ses a ti it s sous des o ditio s sp ifi ues.
- 135 -
5.4.1.2 L’efficacité des ressources employées "Resource efficiency"

L'utilisatio des essou es est o sid e o e l’u des fa teu s de ualit associé à
des essou es. Il t aduit la apa it d’u processus métier à utiliser un type et une quan-
tité de ressources appropriés lorsque ses activités sont exécutées sous des conditions
spécifiques.
5.4.1.3 L’efficacité des coûts "Cost efficiency"
L’effi a it des oûts est a a t is e pa le oût asso i à l'e ution des activités
d’u p o essus tie . E effet, le oût de l'e utio d'u e a ti it ep se te le oût de
l'utilisation de l'équipement, le coût de l'intervention humaine, et toutes les fournitures
nécessaires à la réalisation de cette activité. Ces fonctions de coût sont utilisées pour cal-
ule le oût total asso i à l’e utio d’u e a ti it .
5.4.2 Fiabilité "Reliability"

La apa it d’u p o essus tie à ai te i u e tai i eau de pe fo a e lo s-
qu'il est utilisé sous certaines conditions spécifiées. Ce facteur de qualité peut être raffiné
en plusieurs critères qui sont : la maturité, la tolérance aux pannes et la capacité de récu-
pération.
5.4.2.1 La maturité "Maturity"
La atu it d’u p o essus tie représente sa capacité à éviter un échec en raison
d’u d faut ele da s ses a ti it s.
5.4.2.2 La tolérance aux pannes "Fault Tolerance"
La tol a e au pa es d’u p o essus tie ep se te l’aptitude d’u p o essus
métier à maintenir un certain niveau de performance en cas de défauts ou de violation de
ses spécifications.
5.4.2.3 La capacité de récupération "Recoverability"
La apa it d’u p o essus tie à ta li u i eau sp ifi ue de performances et
de restaurer les données et les ressources directement affectées par une défaillance.
5.4.3 Performance "Performance"

La performance est un facteur de qualité qui fait référence à l’aspe t o po te e tal
du processus métier. Il permet de mesurer la qualité du service QoS fourni par ces pro-
cessus en évaluant la relation entre les services fournis et l'utilisation des ressources. Ce
facteur de qualité peut être raffiné en plusieurs critères qui sont : le débit de traitement,
le temps de réponse, le temps d'exécution et le coût d'exécution.
5.4.3.1 Le débit de traitement "Throughput rates"
Ce critère permet de recenser le nombre d'événements traités par une activité, soit le
nombre d'entrées et/ou de sorties traitées par une activité durant un intervalle d'obser-
vation.
- 136 -
5.4.3.2 Le temps d’exécution "Execution time"

Le te ps est l’u des it es les plus utilisés pou alue la pe fo a e d’u s s-
t e. Da s ot e as, le te ps d’e utio d’u e a ti it ep se te le te ps a h e-
e t d’u e i sta e de ette a ti it (Cardoso, Miller, & Arnold, 2002).
5.4.3.3 Le temps de réponse "Timeliness"
Le temps de réponse d'un système correspond à l'intervalle entre la demande d'un uti-
lisateur et la réponse du système (Laird & Brennan, 2006). Dans notre cas, le temps de
réponse représente le te ps u’u e se le d'e t es et/ou de sorties doit être traité
par une activité afin de répondre à une demande particulière.
5.4.3.4 Le coût d’exécution "Execution cost"
Le oût d'e utio d’u e a ti it ep se te le oût asso i à la alisatio de ette
dernière dans un processus métier. Le coût est un facteur important, car les organisations
doivent fonctionner conformément à leur plan financier (Cardoso, Miller, & Arnold,
2002).
5.4.4 Ressource "Resource"

Les activités d'un processus métier ont généralement besoin de ressources qui peu-
vent être par exemple une machine, un appareil ou un système informatique pour leur
exécution. La qualité de ces ressources peut affecter la qualité des activités. Le contexte
de l'utilisation d'une ressource est l'activité qui utilise la ressource. Par conséquent, la
satisfaction de contexte caractéristique est omise pour les ressources. Le facteur res-
source est raffiné en plusieurs critères qui sont : l’interopérabilité, la sécurité et le dé-
ploiement.
5.4.4.1 Interopérabilité "Interoperability"
L'interopérabilité est la capacité d’u e ressource à interagir avec une ou plusieurs
autres ressources appropriées.
5.4.4.2 Sécurité "Security"
La apa it d’u p o essus tie à p ot ge les do es, les essou es et tout aut e
objet physique afin que les acteurs ou autres ressources non autorisées ne puissent pas y
accéder et de permettre un accès libre et continu à ceux qui en ont droit.
5.4.4.3 Déploiement "Deployment"
C'est la capacité de la ressource à être déployée d'une manière efficace.
5.4.5 Acteur "Actor"

Un acteur peut accomplir une ou plusieurs activités au sei d’u p o essus tie . La
qualité du processus métier dépend donc fortement de la disponibilité et des compé-
tences de ceux qui l’utilisent, en l’occurrence les différents acteurs. La disponibilité et
l’aptitude sont les principaux critères de ce facteur de qualité.
- 137 -
5.4.5.1 Disponibilité "Availability"

C'est la capacité d’u acteur à être en mesure d'exécuter une activité pendant un in-
terval d'observation.
5.4.5.2 Aptitude "Suitability"
C'est la apa it d’u acteur à mener à bien l’e utio d’u e activité.
Cependant, les facteurs et les critères de qualité que nous avons définis précédem-
ment sont assez abstraits et ne peuvent en aucun cas évaluer directement la qualité glo-
bale des processus métier. Par conséquent, il est important de leurs associer un ensemble
de métriques afin de les évaluer.
5.4.6 Mesurer la qualité des processus métier

Dans le cadre de notre modèle qualitatif BPMQ, nous avons proposé un ensemble de
t i ues pe ti e tes ui s’ajoutent à ceux qui existent dans la littérature (Rolón Aguilar,
Ruiz, García, & Piattini, 2006), (Gruhn & Laue, 2006), (Reijers & Vanderfeesten, 2004),
(Cardoso, Mendling, Neumann, & Reijers, 2006), (Cardoso, Miller, & Arnold, 2002),
(Vanderfeesten, Cardoso, & Reijers, 2007), (Rolón Aguilar, García, & Ruiz, 2006),
(Mendling J. , 2008) pour mesurer les différents critères et par conséquent, les différentes
dimensions de qualité d taill es p de e t. E effet, l’u de os o je tifs est d'affi-
ner les critères de qualité à des mesures spécifiques afin de lever l’a st a tio ui de-
meure sur ces derniers.
A cet égard, nous avons proposé une classification de l’e se le des t i ues e
trois couches (cf. figure 5.1): la p e i e ou he est o stitu e d’u e se le de mé-
triques dites de base BMS "Basic Metric Set", la deu i e ou he est o stitu e d’u en-
semble de métriques dites dérivées "Derived Metrics" et enfin, la troisième couche est
o pos e d’u e se le de métriques définies pa l’utilisateu "User-Defined Metrics".
L’e se le des t i ues est o pos ainsi: M = BMS ∪ DM ∪ UDM
Les métriques dites de base ou BMS "Basic Metric Set" so t des t i ues u’o uali-
fie a d’ato i ues da s le se s où leu s aleu s e peu e t pas t e o te ues pa o i-
aiso de elles d’aut es t i ues. Le travail de (Rolón Aguilar, Ruiz, García, & Piattini,
2006) propose un ensemble d’u e soi a tai e de métriques dites de base ; ces métriques
dénombrent les éléments de base qui constituent un modèle de processus métier, modé-
lisé en BPMN, tels ue le o e d’a ti it s NA), le nombre de tâches (NT), le nombre de
flux de séquences entre activités (NSFA), etc.
Les métriques de base sont insuffisantes pour répondre aux besoins des diverses éva-
luations de la qualité. Nous avons donc défini deux autres couches de métriques qui sont :
 DM (Derived Metric Set) dites aussi métriques composées représentent des mé-
triques formulées par des fonctions ayant comme paramètres des métriques de
base comme cela est le cas des métriques proposées dans (Gruhn & Laue, 2006),
(Reijers & Vanderfeesten, 2004), (Cardoso, Mendling, Neumann, & Reijers, 2006),
(Cardoso, Miller, & Arnold, 2002), (Vanderfeesten, Cardoso, & Reijers, 2007) ou
encore dans la (section 4.6.1 - section 4.6.4).
- 138 -
 UDM (User-Defined Metrics) sont des métriques définies par les experts de la qua-
lit . L’utilisatio de es t i ues se justifie pa l’e p ie e de l’e pe t. Cette ex-
périence peut reposer sur des études empiriques qui justifient leur utilisation dans
un contexte bien précis. Cela peut t e pe ti e t pou la esu e d’u aspe t spé-
ifi ue d’un processus métier. UDM répond donc à des besoins spécifiques et ex-
p i e le poi t de ue de l’expert par rapport à une situation donnée. La définition
de ces métriques est généralement basée sur une ou plusieurs métriques appar-
tenant à BMS ∪ DM.
Dans ce qui suit, nous passons en revue, les différentes métriques que nous avons dé-
finies pour évaluer les critères de qualité définies ci-dessus.
5.4.6.1 Mesurer l’interopérabilité
L’i te op a ilit peut t e alu e e utilisa t deu t i ues ui so t : l’ ha ge de
données "Data exchangeability" (Dex) et la cohérence de l'interface "Interface Consisten-
cy" (InC). Elles peuvent être calculées comme suit :
La métrique Dex permet de calculer le ratio entre le nombre des objets de données
qui sont autorisés à être échangés avec succès avec d'autres processus ou activités au
cours des essais notés par NDA et le nombre total d'objets de données à échanger notée
TND.
Dex = NDA / TND
Où: TND = Σ Data Object-In du processus + Σ Data Object-Out du processus.
La métrique InC permet de calculer le ratio entre le nombre de messages échangés
entre participants noté NoM et le nombre total des activités noté TNA.
INC = Σ NoM / Σ TNA
5.4.6.2 Mesurer la maturité
Pour mesurer le critère de maturité, nous avons adapté deux métriques du domaine
des produits logiciels qui sont la densité des défauts "Fault density" (FD), et le mécanisme
de rappel "Callback" (NCB).
La métrique FD dénombre le o e de d fauts d te t s lo s de l’i spe tio ou du
déploiement du modèle de processus métier. Elle calcule le ratio entre le nombre de dé-
fauts détectés NF et la taille du modèle de processus métier N.
FD= NF / N
Un mécanisme de rappel ou de "callback" en anglais répond à la nécessité de retrans-
mettre directement un message suite à l'invocation simulant une relation synchrone. La
métrique callback dénombre le nombre de callbacks dans un modèle de processus métier
noté NCB.
NCB= Σ all a k
- 139 -
5.4.6.3 Mesurer la tolérance aux pannes

Pour évaluer ce critère de qualité nous avons défini une métrique appelée gestion des
exceptions "Exception Handled". Cette métrique notée EH compte le nombre
d’e eptio s qui existent au sei d’u od le de p o essus tie .
EH = Σ ha dled e eptio s
5.4.6.4 Mesurer le temps de réponse
Pou esu e le te ps de po se d’u p o essus tie , ous a o s p opos deu
métriques qui sont temps de réponse "Response time" notée RTM et le débit
"Throughput" notée THG.
La première métrique RTM mesure le temps écoulé entre la demande de l'acteur et la
réponse fournie par le processus métier. Elle représente la somme des temps
d’e utio pour les différentes activités notées RToA:
RTM = Σ RToA
La deuxième métrique Thg al ule le o e d’activités qui peuvent être réalisées
avec succès noté NCA sur une période de temps donnée p iode d’o se atio notée
OTP.
THG = NCA / OTP
5.4.7 Analyse et interprétation des mesures obtenues

Après avoir obtenu les différentes valeurs de ces mesures (métriques), ces dernières
doivent être interprétées et analysées. Par conséquent, il est intéressant de savoir quelles
sont les mesures par rapport auxquelles on peut évoquer le cas d’u e bonne ou d’u e
mauvaise) qualité du processus métier.
Les valeurs de seuil pourraient être utilisées comme un indicateur fiable de détection
de bonne ou de mauvaise qualité dans les modèles de processus métier. En effet, dans
(Henderson-Sellers, 1995), l’auteu affi e u’ «une alarme peut se produire chaque fois
que la valeur d'une mesure interne spécifique dépasse une certaine valeur prédéfinie».
En se basant sur ce principe, les modeleurs et les experts de qualité doivent présenter
pour chaque métrique une valeur de seuil mthreshold ∈ Mthresholds qui reflète sa valeur opti-
male. Cette valeur peut être fournie à la suite d'études empiriques.
La comparaison entre mi ∈ M et mthreshold ∈ Mthresholds, fournit donc une évaluation de la
dimension de la qualité.
A partir de ce principe, nous pouvons définir des niveaux de qualité de processus mé-
tier sur la base de ces valeurs de seuils:
 Niveau 1: il ya 10% de probabilité pour que la qualité d'un modèle de processus
métier soit considérée comme acceptable;
- 140 -

métier soit considérée comme acceptable.
Par conséquent, un Niveau 2 par exemple peut être interprété comme suit :
Si le nombre de œuds d'un modèle est compris entre 8 et 20, le diamètre de ce mo-
dèle est compris entre 5 et 12, la profondeur est comprise entre 1 et 5, le coefficient de
connectivité est compris entre 0,4 et 2,80 et le caractère cyclique est compris entre 0,10
et 0,89 alors la probabilité pour que la qualité d'un modèle de processus métier soit con-
sidérée comme acceptable est d'environ 30%.
5.5 Analyse de l’impact qualitatif du changement des processus mé-

tier
La ualit d’u od le de p o essus tie doit t e alu e du a t tout son cycle de
vie et plus particulièrement après chaque changement de processus métier. Dans cette
section, ous ous i t esso s tout pa ti uli e e t à l’i pa t du ha ge e t structurel
d’u od le de p o essus tie su la ualit ou e ue ous appelo s l’i pa t ualita-
tif du changement.
En effet, outre l'impact comportemental (Sun & Jiang, 2009), un impact qualitatif peut
en résulter d’un changement de processus métier. Généralement, il est observé que la
qualité du modèle de processus métier tend à s'éroder avec l'augmentation de la taille et
de la complexité due à l'ajout de nouvelles activités. Autrement dit, le nombre croissant
d'activités augmente le nombre de connexions ce qui peut conduire à des difficultés de
compréhensibilité et de maintenabilité de ce modèle.
Dans le chapitre 4, nous avons quantifié un changement de processus métier (notée Δ)
comme la différence entre le modèle de processus métier initiale S et le modèle de pro-
cessus métier résultant S noter comme suit:
S’ = S + Δ
Δ = | S - S’|
Par conséquent, tout changement structurel (ΔS) opéré sur un modèle de processus
métier peut causer un changement qualitatif (ΔQ) sur les critères qualitatifs correspon-
dants. Ainsi, la notation ΔS ΔQ signifie que le changement structurel ΔS implique un
changement qualitatif ΔQ. Cette affi atio ie t du fait u’u ha ge e t de p o essus
métier peut affecter les métriques de ualit o e a t e de ie . L’i te d pe da e
des attributs de la qualité peut alors conduire à une mauvaise situation dans laquelle la
dété io atio d’u e t i ue de ualit peut a oi u i pa t d fa o a le su d’aut es
métriques.
Une connaissance exhaustive de la qualité du modèle de processus métier peut donc
aider à mieux t a e la p opagatio de l’i pa t du ha ge e t de faço p og essi e
entre métriques, critères et facteurs de la qualité du processus métier. Elle permet de
déterminer le changement qualitatif ΔQ sulta t d’u ha ge e t st u tu el de proces-
sus métier, par la propagation progressive de ce changement aux critères prédécesseurs
dans le graphe de la qualité, aux facteurs correspondants et ainsi de suite jus u’à la quali-
té globale ou générale du processus métier comme le montre la figure 5.2.
- 141 -
ΔQ BPMQ
ΔFp …. Maintainabilité ….
Schéma de processus métier initial

(S) ΔCp La facilité d’analyse ….
Δ p Complexité Couplage ….
Changement
Schéma de processus métier résultant
(S’)
Structurel 1.1.1 m
{N, IC, CYC, CFC…}
Impact du changement Impact du changement Impact du changement

structurel comportemental qualitatif
(ΔS) (ΔB) (ΔQ)
Figure 5.2 Relations entre l'impact structurel, comportemental et qualitatif du changement.
Considérons un ensemble de métriques M = {m1, m2, m3,…, n} associées à un modèle

de processus métier S. Les valeurs associées à ces métriques peuvent être représentées
pa l’e se le V = {v1, v2, v3, . . . vn}. Un changement structurel ΔS appliqué sur un modèle
de processus métier S peut résulter en de nouvelles valeurs de ses métriques associées
ue l’o ote a V = {v 1, v 2, v 3, …, v n}. Ceci est formulé par :
m1, m2, m3,…, n (S) = (v1, v2, v3, . . . vn)
M(S) = V
Après le changement, ΔQ S’ = ΔQ(S) + ΔQ ha ge , alo s ous o te o s la aleu de V’
telle que :
m1, m2, m3,…, n S’ = (v 1, v 2, v 3, . . . v n)
M S =V
La différence des valeurs de métriques (ΔM = V − V) dénote une variation des critères
qualitatifs correspondants. La différence qui correspond aux valeurs de métriques Δmi,
Δmi+1, Δmn représente donc le ha ge e t du it e de ualit u’o ote a ΔC.
Le ha ge e t d’u it e peut affe te la aleu d’aut es critères associés (ΔCj, ΔCj+1,
ΔCn) du même niveau (cf. section 5.1). Cette différence identifiée au niveau des attributs
qualitatifs at ialise l’i pa t ualitatif.
5.5.1 Dépendances entre les critères de qualité

Hormis les relations de dépendance verticales entre les différents facteurs, critères et
métriques expliquées dans la section 4, il peut exister des dépendances horizontales
e t e les fa teu s, it es et t i ues de la ualit d’u e i eau de affi e e t
ou d’a st a tio comme le montre la figure 5.3.
- 142 -
BPMQ
+
F1 F2 …. Fn
C1 C2 C5
+ C4 *
C4 + + Cn
C3
M1
+
M2
M3 M4 M5 Mn
-
Figure 5.3 Les d pe da es ho izo tales da s l valuatio de la ualit des p o essus tie .
Dans cette section, nous définissons les relations horizontales responsables de la pro-
pagatio de l’i pa t du ha ge e t e t e les fa teu s et it es de la ualit d’u
même i eau d’a st a tio . La p se tatio de es elatio s o stitue u o e
d’a al se des pe ussio s ausales de odifi atio d’u att i ut de la ualit su les
autres attributs de la qualité. En effet, ces dernières modélisent la complémentarité ou la
co t adi tio de deu att i uts da s l’ aluatio de la ualit . Il est ai si possi le de spé-
ifie des elatio s de t pes : l’a lio atio de la ualit d’u att i ut A 1 participe à amé-
lio e espe ti e e t d t io e elle d’u aut e att i ut A2 et vice-versa.
Du a t l’ olutio d’u fa teu de la ualit , les aut es fa teu s ui lui so t eli s peu-
e t gale e t olue . Cela o espo d à l’e iste e ou l’a se e de la p opagatio de
l’i pa t e t e les œuds du g aphe de la ualit . Pa e e ple, il est démontré par les
travaux de Laura Sánchez-González et al. (Sánchez-González, García, Mendling, Ruiz, &
Piattini, 2010) , (Sánchez-González, García, Mendling, & Ruiz, 2010), (Sánchez-González,
Ruiz, García, & Piattini, 2011) que les métriques qui évaluent les deux critères de qualité
qui sont la compréhensibilité "understandability" et la facilité de modification "modifiabi-
lity" évoluent de manière totalement corrélées.
Partant de ce constat, nous pouvons définir l’e se le U des a s du g aphe de la ua-
lité par deux sous-e se les disjoi ts : l’e se le V ep se ta t les elatio s e ti ales
entre facteurs, critères et métriques, et l’e se le des a s elia t des œuds d’u
même niveau de raffinement. L’o ie tatio de l’a i di ue la atu e de la p opagatio de
l’i pa t ualitatif ui peut t e li ell pa les s oles +, −, ou * indiquant respective-
ment un impact positif, négatif ou un changeant.
L’e se le des a s est alo s d fi i pa U = V ∪ , où est l’e se le des a s ho i-
zo tau . ep se te les elatio s de d pe da e e t e des œuds d’u e i eau,
telle que :
H = H+ ∪ H− ∪H*
- 143 -
Où, H+, H−, et H* désignent respectivement les arcs libellés par le symbole « + », « − »,
et « * ».
Donc, U = V ∪ H+ ∪ H− ∪ H* telle que :
(fi, fj) ∈ F :
 (Qt(fi), Qt(fj) ∈ H+) Qt(fi) présente une évolution favorable pour Qt(fj) ;
 (Qt(fi), Qt(fj) ∈ H-) Qt(fi) présente une évolution défavorable pour Qt(fj) ;
 (Qt(fi), Qt(fj) ∈ H*) Qt(fi) présente une évolution changeante de Qt(fj) ;
Où Qt(fi d sig e l’esti atio du deg a e le uel le fa teu Fi est assu u e a-
leur quantifiant le facteur Fi).
Qt(ci), Qt(cj) ∈ Qt(C) :
 (Qt(ci), Qt(cj) ∈ H+) Qt(ci) présente une évolution favorable pour Qt(cj) ;
 (Qt(ci), Qt(cj) ∈ H-) Qt(ci) présente une évolution défavorable pour Qt(cj) ;
 (Qt(ci), Qt(cj) ∈ H*) Qt(ci) présente une évolution changeante de Qt(cj) ;
Où Qt(ci d sig e l’esti atio du deg a e le uel le critère Ci est assuré (une va-
leur quantifiant le critère Ci).
5.6 Conclusion
La gestion de la qualité des processus métier et plus précisément celle des modèles de
processus métier a fait l’o jet de multiples travaux de recherche récemment. Le but étant
de ett e e pla e u a is e effi a e ui pe et d’a lio e la o p he sio , la
fiabilité et la réutilisation de ces modèles durant leur cycle de vie, et plus particulière-
ment, après chaque changement de processus métier.
E effet, l’a lio atio du o t ôle de l’ olutio des p o essus tie en évitant la
dégradation de la qualité dépend fortement de la compréhension des dépendances des
diff e ts l e ts d’u p o essus tie incluant ceux relatifs à la qualité.
Dans ce chapitre, nous avons proposé un cadre exhaustif inspirée par la norme ISO/
CEI 9126-1 représentent à la fois une contribution à la maturité des travaux existants à
l' ga d de l’ aluatio et de l'a lio atio de la ualit des p o essus métier et un moyen
permettant de traiter la p o l ati ue de l’a al se de l’i pa t du ha ge e t selo les
points de vue structurel et ualitatif. L’app o he p opos e pe et une meilleure traçabi-
lité de la propagation de l’i pa t du changement.
Nous avons également représenté des relations horizontales entre attributs de qualité
en plus des relations verticales permettant de définir ainsi des liens de contradiction ou
plus généralement de causalité en matière de contribution à la qualité générale du pro-
cessus métier.
- 144 -
CHAPITRE
6
Prototype de validation
6. Prototype de validation
6.1 Introduction
Afin de valider l’e se le des contributions de nos travaux proposés tout au long de
ce manuscrit, ous a o s is e œu e une plate-forme intégrant différents modules ou
composants implémentant chacun des aspects évoqués dans cette thèse. Cette plate-
forme qui est intégrée à un environnement de modélisation BPMN permet entre autres
de réaliser les fonctionnalités suivantes : (1) vérifier la cohérence des processus métier
après chaque changement, (2) de vérifier la conformité de ces modèles avec l’e se le
des règles de conformité, (3) d’ alue la ualit des od les de p o essus métier tout au
long de leur cycle de vie et plus particulièrement, après chaque changement, et enfin (4)
de p opage l’i pa t du ha ge e t des p o essus tie .
Notre plate-forme ainsi que tous les modules qui la constituent sont intégrés au sein
de l’IDE "Integrated Development Environment" Eclipse24 sous forme de plug-ins. Le choix
d’E lipse a t di t pa le fait ue ’est u IDE ope source largement utilisée pour cons-
truire des plates-formes de développement ou e tes et e te si les o stitu es d’outils et
de runtimes destinés à la construction, au déploiement et à la gestion de logiciels mais
aussi par l’e i o e e t de od lisatio BPMN utilisé comme noyau pour notre plate-
forme appelé BPMN2 Modeler25 qui est implémenté sous fo e d’u plug-in au sein de
ce dernier.
Dans ce chapitre, nous présentons la plate-forme appelée BPMN-CM "Business Pro-
cess Modeling Notation Change Management" en détaillant les différents modules qui
constituent son architecture. Le premier module de base est le plug-in BPMN2 Modeler
qui permet de modéliser un processus métier moyennant la notation BPMN. Ce module
est le composant central de notre prototype. Le second module qui est composé de deux
sous-modules permet à la fois de vérifier la cohérence et la conformité des modèles de
processus métier après chaque changement et cela, à t a e s l’utilisatio du plug-in EpiS-
pin26 comme model chercker. En effet, après avoir transformé automatiquement le mo-
d le de p o essus tie à ifie e P o ela, EpiSpi ifie l’a se e de toute e eu
structurelle susceptible de causer des incohérences dans ce modèle. La même démarche
est utilisée pour vérifier la constitution de ce modèle comme étant satisfaisante au regard
des règles de conformité.
Un autre modules du prototype a été conçu et implémenté pour gérer la qualité des
processus métier tout au long de leur cycle de vie et plus particulièrement, l’i pa t uali-
tatif ui peut t e le sultat d’u ha ge e t de p o essus tie . Enfin un dernier mo-
dule qui permet une analyse a priori de l’i pa t de e ha ge e t. Le sultat de ette
analyse est mis en évidence pa u e isualisatio de l’i pa t su les différents éléments
du modèle de processus métier.
Ce hapit e est o ga is o e suit : la se tio . su e l’a hite tu e et la concep-
tion générale du prototype de validation ainsi que les détails de chacun des modules qui
composent notre plate-forme. La section 6.3 présente les résultats de notre approche en
considérant un scénario illustratif de processus de remboursement des frais de fonction-
24
http://www.eclipse.org/pde
25
http://eclipse.org/bpmn2-modeler/
26
http://epispin.ewi.tudelft.nl/index.html
- 146 -
nement. La section 6.4 conclut le chapitre et discute brièvement les perspectives du déve-
loppement de notre prototype.
6.2 Architecture Globale du prototype de validation

Notre plate-forme appelée BPMN-CM "Business Process Modeling Notation Change
Management" permet à la fois de modéliser un processus métier à travers l’utilisatio du
plug-in BPMN2 Modeler, de ifie la oh e e et la o fo it d’u od le de p o es-
sus métier et enfin d’a al se les diff e ts i pa ts structurels et qualitatifs résultant
d’u changement de processus métier.
BPMN-CM est construit à l’aide d’Eclipse Plug-in Development Environment (PDE) qui
représente un outil open source incontournable de développement de logiciel, car il offre
une plate-forme e te si le ui pe et l’ajout de ou elles fo tio alit s g â e à des
plug-ins. En plus, cette plate-forme 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écifique de plug-i s et d’outils de déve-
loppement. Parmi ces projets, on peut citer Business Intelligence and Reporting Tools27
qui permet de générer des rapports, SOA platform project28 qui vise à proposer un en-
semble de plug-ins et d’outils de développement orientés web services (des éditeurs
BPMN, BPEL, un moteur BPEL ...etc.) ou encore Eclipse Modeling Project29 qui vise à pro-
poser un ensemble de plug-ins et d’outils de développement orientés modèle.
Dans notre travail, nous nous sommes intéressés au projet SOA platform project et
plus particulièrement à un de ces plug-ins appelé BPMN2 Modeler. Ce dernier représente
le noyau de notre prototype BPMN-CM, il permet de modéliser un processus métier à
l’aide de la otatio BPMN (cf. figure 6.1).
Figure 6.1 Le plug-in BPMN2 Modeler.
27
http://projects.eclipse.org/projects/birt
28
http://projects.eclipse.org/projects/soa
29
http://projects.eclipse.org/projects/modeling
- 147 -
Notre plate-forme solution BPMN-CM est donc composée de quatre plug-ins :

 Un plug-in de modélisation appelé BPMN2 Modeler permettant à un analyste mé-
tier de modéliser un processus métier, ce plug-in représente le noyau de notre
prototype ;
 Un plug-in de vérification appelé BPMNVT "Business Process Modeling Notation
Verification Tool " composé de deux modules qui sont BPMN2PROMELA "BPMN to
Promela", CR2LTL "Compliance Rules to LTL" permettant respectivement de trans-
former u od le BPMN e od le P o ela et d’e p i er l’e se le des gles
de conformité en LTL et cela, afin de vérifier à la fois la oh e e d’u od le de
processus métier et la conformité de ce dernier avec l’e se le de ces règles ;
 Un plug-in de gestion de qualité appelé BPMNQ "BPMN Quality" permettant de
g e la ualit d’u p o essus tie du a t tout so le de ie et plus pa ti u-
lièrement après chaque changement ;
 Un plug-in d’a al se d’i pa t du ha ge e t de p o essus tie BPMN-CPA
"BPMN Change Propagation Analyser" permettant de p opage l’i pa t du han-
gement des processus métier.
L’a hite tu e i te e o t a t l’i te a tio de es plug-ins est schématisée par la fi-
gure 6.2. Nous discuterons par la suite les d tails de l’i plémentation de ces quatre plug-
ins.
Eclipse Business Process Modeling Notation Change Management
BPMNVT Plug-in BPMNQ plug-in
CFC (P) = Σ CFCXOR-split (i) + Σ CFCOR-split (j) + Σ CFCAND-split (k)
B CYC = NNC / TNN
Rule 01
A + + BPMNQ
Performance Efficacité
C
BPMN2PROMELA Plug-in CR2LTL Plug-in
BPMN2 Modeler Plug-in

Chan cS [2] = [] p -> <> q
+
File.pml
File.prp
/*promela */ <>F->P Modèles BPMN

B
A + +
C
EpiSpin
Plug-in
BPMN-CPA Plug-in
Base de connaissances
Plug-in Externe BPMN repository Base de règles
B
Annotations sémantiques
A + +
C R1
Plug-in Interne SPARQL Règles de faisabilité
BPMN Ontologies
R1
BPMN-CM R gles d’a al se d’i pa t
Figure 6.2 L a hite tu e g ale de la plate-forme BPMN-CM.
- 148 -
6.2.1 Le plug-in BPMN2 Modeler

Le plugin BPMN2 Modeler représente le noyau de notre plate-forme BPMN-CM. Ce
plug-in permet de construire des modèles de processus en utilisant une palette de sym-
boles BPMN (cf. figure 6.1). Cet outil respecte globalement les spécifications de la nota-
tion BPMN 2.0.
BPMN2 Modeler génère deux fichiers en sortie, le premier fichier, au format XML, dé-
taille la logique du processus (cf. figure 6.3), et le second comporte les éléments relatifs à
l’aspe t g aphi ue du p o essus (cf. figure 6.4). Ces deux fichiers sont le point de départ
de notre plate-forme.
Figure 6.3 E t ait du fi hie d e t e « Des iptio logi ue ».
Figure 6.4 E t ait du fi hie d e t e « Des iptio g aphi ue».
6.2.2 Le plug-in BPMNVT

Afi de ett e e œu e ot e app o he de ifi atio fo elle da s u o te te
pratique, nous avons mis en place un plugin de vérification appelé BPMNVT "BPMN Veri-
fication Tool" composé de deux modules qui sont BPMN2PROMELA "BPMN to Promela"
et CR2LTL "Compliance Rules to LTL". L’a hite tu e de BPMNVT est présentée dans la
figure 6.5.
- 149 -
CR_Process_A.prp
Règles de conformités en LTL
ltl R1{[]((! F:e ==1) ->
<> P )}
ltl R2 { [ ] (( P : A<200) ->
T@A)} Model non valide
{Contre exemple}
CR2LTL
EpiSpin
BPMNVT
BPMN2 Modeler Model-checker
BPMN2PROMELA Plug-in
Model valide
BPMN Model Promela Model
B Chan [3] = [1] of int
A + + Proctype A(){...}
Proctype B(){...}
C Proctype C(){...}
Process_A.bpmn Process_A.pml
Figure 6.5 L architecture du plug-in BPMNVT.
6.2.2.1 BPMN2PROMELA
Le plugin BPMN2PROMELA est un traducteur qui permet de transformer un modèle
BPMN en un modèle Promela. Le fichier *.pml est le résultat de cette traduction. Ce fi-
chier contient le code Promela o espo da t au od le BPMN sou e u’o eut i-
fier et dont le contenu est fourni comme entrée pour le plugin le model-checker EpiSpin
qui servira comme outil de vérification formelle (cf. figure 6.5).
Le pa si g ou l’a al se des od les BPMN pa le t aducteur BPMN2PROMELA est ba-
s e su l’asso iatio d’u e se le de outi es s a ti ues (des règles de réécriture)
pou la o st u tio d’a es s ta i ues a st aits ou AST "Abstract Syntax Tree" dont le
pa ou s et l’e ploitatio se i o t à la p odu tion du code Promela. Précisément, la syn-
taxe Promela sera organisée en objets BPMN correspondant (la Table 3.2 du chapitre 3
contient la correspondance entre les différents éléments BPMN et la syntaxe Promela).
Ainsi les instructions Promela telles que proctype, bloc, if-fi bloc, etc. représentent les
a hes de l’a e s ta i ue et les i st u tio s P o ela telles que les variables, les ca-
naux, envoi/ réception de messages représentent les feuilles de cet arbre.
La figure. 6.6 (a) nous donne un aperçu sur la façon dont le modèle BPMN est parsé en
arbre syntaxique, puis mappé en fragments de code PROMELA. La figure 6.6 (b) montre
l’a e s ta i ue étiqueté de (1 à 10) et la figure 6.6 (c) représente le code PROMELA
correspondant.
Dans cette traduction chaque activité est transformée en processus Promela par
exemple : proctype A(){…}, les flux de séquences en canaux de communication Promela
par exemple : chan ch[2]= [1] of {int}. Les flux de messages entre les différents
processus sont représentés en utilisant des entiers dans Promela.
- 150 -
Processus P
A B
(a)

  

mtype = {signal}

Racine
 
chan cS=[1] of {mtype}


Bloc de variable Bloc des canaux Bloc des processus proctype A(){
   
cS!signal(1);

}

Variables Canaux Processus Processus
proctype B(){
 
cS?signal(_);

}
Envoi de message Réception de message
(b) (c)
Figure 6.6 Exemple de l'arbre syntaxique.
Le fichier config.properties sert à configurer le traducteur. Il permet aux utilisa-

teurs à tit e d’e emple, de spécifier la taille du buffer des canaux de communication buf-
fer.size, le chemin de stockage des fichiers Promela générés files.locator, les types
de messages message.type échangés dans les canaux (bits, bool, byte, short, int) ou
encore le nom du modèle BPMN à traduire BPMNmodel.name. Cette configuration est
prise en considération par le traducteur à chaque exécution (cf. figure 6.7).

chan cS[9] = [1] of {int}; Buffer.size=9

/* RECEIVE EXPENSE REPORT PROMELA PROCESS */ Message.type=int
proctype ReceiveExpenseReport() { files.locator= C:\Users\LISIC-

int exist; KMO\workspace\BPMN2PROMELA\Files
chan cS1[2] = [1] of {int} ; #BPMNmodel.name=process_A.bpmn
cS1[0]= cS[0];/* Send to create expense
Account */
cS1[1]= cS[1];/* Send to review pre- Config.properties
Approval */
R:
if
:: exist=0 /* Account doesn’t exist */

:: exist=1 /* Account exist */
fi;
XORSplit(cS1,exist,1); goto R
}
Process.bpmn
Figure 6.7 Fichier de configuration de BPMNVT.
- 151 -
6.2.2.2 CR2LTL
CR2LTL est un module qui propose une palette composée d’u e se le de connec-
teurs temporels et booléens pe etta t d’e p i e ainsi des formules LTL graphique-
ment (cf. figure 6.8). L’o je tif de e odule ta t de fournir un fichier *.prp a partir de la
représentation graphique de l’e se le des gles de o fo ité exprimées en LTL et
cela afin de fournir ce dernier comme entrée pour EpiSpin en plus du fichier *.pml conte-
nant le code Promela correspondant au modèle BPMN dont on veut vérifier la conformité
comme le montre l’a hite tu e de BPMNVT da s figure 6.5.
Figure 6.8 Le module CR2LTL.
6.2.3 Le plug-in BPMNQ

Le plug-in BPMNQ ou "BPMN Quality" permet de gérer la qualité des modèles de
processus métier durant tous leurs cycles de vie, et plus particulièrement après chaque
changement. Il est composé de trois modules : (1) un module de calcul, (2) un module
d’ aluatio et d’i te p tatio et (3) un module de représentation (cf. figure 6.9).
BPMNQ
Module d’évaluation
 
Module de calcul Module de Présentation
& d’interprétation
Σ
Figure 6.9 Architecture du plug-in BPMNQ.
- 152 -
Le p e ie odule se t à al ule l’e se le des t i ues ises en place dans

BPMNQ. Cet ensemble est classé en trois couches: (1) les métriques dites de base
permettent de dénombrer les différents éléments qui composent le modèle BPMN tel
ue le o e d’a ti it s NA), le nombre de tâches (NT), le nombre de flux de séquence
entre activités (NSFA), etc, (2) Les métriques dites dérivées qui représentent des mé-
triques formulées par des fonctions ayant comme paramètres des métriques de base tel
ue la o ple it d’u flu de o t ôle au sei d’u od le BPMN CFC , la longueur du
od le BPMN N ou e o e l’ ha ge de do es au sei d’u od le BPMN De .
BPMNQ donne aussi la possibilité aux modeleurs et aux experts de ualit d’ajoute (3)
des métriques ad-hoc qui se basent essentiellement su l’e se le des t i ues de
ase et d i es et d’asso ie chacune entre eux aux critères de qualité définis dans le
chapitre 5 (cf. figure 6.10).
Figure 6.10 Ajout de métriques Ad-hoc dans le plug-in BPMNQ.
Le odule d’ aluatio et d’i te p tatio permet de comparer les différentes valeurs

des métriques obtenues avec les valeurs de seuil introduites ultérieurement par les mo-
deleurs et les experts de qualité. En effet, grâce à l'interface présentée dans la figure
6.11, l'interprète affiche pour chaque dimension et critère de notre modèle qualitatif les
valeurs des métriques qui lui sont associées. Ce module permet aussi aux modeleurs et
aux experts de qualité de fournir aussi pour chacune des métriques une valeur de seuil
reflétant sa valeur optimale, cette valeur peut être fournie à la suite d'études empiriques.
- 153 -
Figure 6.11 Évaluatio des t i ues d u od le BPMN pa plug-in BPMNQ.
L’ aluatio de ha ue it e de la ualit Qc se base sur la comparaison entre les

différentes mesures obtenues Ϭi i= ,…, et les diff e tes aleu s de seuils Ϭ’i i= ,…, .
Pour une meilleure visibilité des différentes mesures obtenues, le module de présenta-
tion offre la possibilité de représenter les différents résultats sous forme de graphe d'éva-
luation qui peut être visualisé comme le montre la figure . . L’i te alle de seuil est
représenté en rouge, tandis que la variation de la valeur de la métrique dans le temps est
représentée en bleu.
Figure 6.12 G aphe d valuatio de la t i ue N.

- 154 -
6.2.4 Le plug-in BPMN-CPA

Le plug-in BPMN-CPA ou "BPMN Change Propagation Analyser" qui est en cours de dé-
veloppement pe et de p opage l’i pa t du ha ge e t des p o essus tie .
Ce plugin est composé de deux modules : une base de connaissances (cf. chapitre 4)
qui a pour principale fonction la gestion des méta-informations sur les processus métier
et une base de règles qui permettra la mise en place du processus de propagation de
l’i pa t du ha ge e t.
L’i pl e tatio de la base de règles est basée sur le moteur de règles orienté objet
Drools30. Ce moteur permet la gestio de l’e se le des gles de propagation de
l’i pa t du ha ge e t des processus métier proposées dans le chapitre 4. En effet,
Drools est une plate-forme de gestion de règles métier fournissant un atelier intégré pour
la d fi itio et l’e utio de gles. Il pe et gale e t la d fi itio et l’e utio de
workflow ainsi que la gestion des événements. L’e se le des règles de propagation de
l’i pa t sont invoquées de façon interactive au cours de la manipulation des éléments du
modèle BPMN (ajout, suppression ou modification).
6.2.4.1 Implémentation du système à base de règles
Ces gles g e t la p opagatio de l’i pa t des ha ge e ts. Ce so t des gles qui
al ule t l’effet de ague ou "Ripple effect" provoqué par u ha ge e t d’u processus
métier. La p opagatio de l’i pa t d pe d de l’op atio de ha ge e t, des types de
relation reliant les éléments du processus métier et de la o du ti it de l’i pa t à t a-
vers ces relations de dépendance entre les éléments directement ou indirectement con-
cernés par le changement.
Le cal ul ou l’ide tifi atio de la p opagatio de l’i pa t est o te u pa la règle
"ChangeImpactPropagation" (cf. Listing 6.1).
Listing 6. 1 La gle de p opagatio d i pa t du ha ge e t
rule "ChangeImpactPropagation"
when
FOxNode: BPMNNode(typeNode==”Activity”,stateNode==state.STATE_INIT) then
FOxEdge: BPMNNode(nodeSrc=activityNode,nodeDest=activityNode)
then
mark(FOxNode);
mark(FOxEdge);
if (FOxNode.getTypeChange() == “ADDED”)
FOxNode.setstateNode(states.STATE_ADDED);
if (FOxNode.getTypeChange() == “MODIFIED”)
FOxNode.setstateNode(states.STATE_ MODIFIED);
if (FOxNode.getTypeChange() == “DELETED”)
FOxNode.setstateNode(states.STATE_DELETED);
Calculate_Depth_of_Impac(FOxNode);
Propagate_Impact(FOxNode);
endif
end
En effet, la règle "ChangeImpactPropagation" joue un rôle important dans la simula-

tio de la p opagatio de l’i pa t. Elle a ue les éléments du processus métier affectés
30
http://www.jboss.org/drools/
- 155 -
pa l’op atio de ha ge e t. Cela provoque le marquage de tous les éléments affectés

pa la p opagatio de l’i pa t. Le a uage d’u œud ha ge l’ tat de e œud.
La p op i t stateNode d it l’ tat d’u l e t du modèle BPMN. La valeur par dé-
faut de cette propriété est STATE_INIT. L’e se le des tats u’u œud peut avoir
sont définis dans la classe BPMN_CPA_StateNode appartenant au plug-in BPMN-CPA.
Les valeurs notables de cette propriété sont : STATE_ADDED, STATE_MODIFIED et
STATE_DELETED.
6.3 Expérimentation
À tit e d’illust atio de fonctionnement de l’outil mis en place, nous proposons un scé-
nario représentant un processus de remboursement des frais de fonctionnement des
e plo es d’u e e t ep ise (cf. figure 6.13).
Figure 6.13 Processus de remboursement des frais de fonctionnement.
Dans ce processus, les employés d'une entreprise réclament un remboursement de

leurs dépenses, par exemple, l'achat de fournitures de bureau, frais de déplacement ou
o ta t d’achat de logiciels.
6.3.1 Schéma initial S du processus

Après que la note de frais soit reçue « Recevoir la note des frais », un nouveau compte
est créé si l'employé ne possède pas un compte de dépense « Création du compte de dé-
pense ».
La note de frais est approuvée soit automatiquement ou manuellement. En effet, une
approbation automatique du remboursement est effectuée « Approbation automatique
du compte » si le montant est inférieur à 200$. Sinon, si le montant est supérieur ou égal
à 200$, cela nécessite une approbation par le superviseur « Approbation par le supervi-
seur ». E as de efus, l’e plo eçoit u a is de ejet pa e-mail « Notification de rejet
à employer », sinon, en cas d'acceptation, un virement bancaire qui permet de rembour-
ser le dû de l’e plo est effe tu « Vi e e t a ai e au o pte de l’e plo e ».
6.3.2 Schéma résultant S’ du processus

Après le déploiement de ce processus métier, de nombreux employés se sont plaint du
retard et de l’a se e de nouvelles suite à leurs demandes. Par conséquent, l'entreprise a
- 156 -
décidé d'apporter des changements sur le modèle de processus métier initial S en ajou-
tant un service qui permet de répondre à leurs besoins. Les modifications suivantes sont
apportées, pour satisfaire cette demande:
 Si aucune action ’est e ta e dans les 7 jours qui suivent la demande, l'employé
doit recevoir une approbation par e-mail l’i fo a t de la progression de sa de-
mande.
 Si la demande n'est pas traitée dans les 30 jours ouvrables, le processus est arrêté
et l'employé reçoit un avis d'irrecevabilité par e-mail.
Ce processus de remboursement des frais de fonctionnement doit aussi se conformer
à un ensemble de règles détaillées comme suivant:
 R1 : si l e plo e eçoit pas de po se ap s Jou s de sa de a de, u e-mail
d i e eva ilit lui est ad ess .
 R2: si l e plo e poss de pas de o pte, u ouveau o pte se a .
 R3: si le montant est inférieur à 200$, alors le compte de dépenses doit être ap-

prouvé automatiquement.
R4: Après que la demande de remboursement est approuvée, l'argent est transféré
au compte bancaire de l'employé; autrement, une notification de rejet est envoyé
par e-mail à l'employé.
6.3.3 Vérification de la cohérence et de la conformité du processus

Afin de vérifier la cohérence et la conformité du processus de remboursement des frais
de fonctionnement, nous avons utilisé le module BPMNVT de notre plate-forme . Les cap-
tu es d’ ans de la figure 6.14 et 6.15 montrent respectivement le modèle Promela de ce
processus générer par le module BPNM2PROMELA ainsi que le résultat de la vérification
de l’a se e de lo age " invalid endstates".
Pour plus de lisibilités et une meilleure compréhension des résultats, il est possible de
générer une structure de kripke à partir du modèle Promela comme le montre la fi-
gure 6.16. En effet, EpiSpin propose de générer un code DOT (*.dot) à partir du fichier
(*.pml), et dont la compilation en image ou en fichier PDF et la visualisation demande
l’utilisatio des outils tel ue G aphiz31 comme le montre la figure 6.17
6.3.4 Évaluation de la qualité du processus métier

Un changement ( ) sur un processus métier peut provoquer la propagation d’u im-
pact structurel, fonctionnel, logique, comportemental et/ou qualitatif aux éléments qui
lui so t eli s. Pou l’aspe t ualitatif il est i po ta t de d te i e le tau a e le uel la
ualit d’u p o essus est affe t e suite à u ha ge e t op sur un de ses éléments.
La atio de gles de p opagatio d’i pa t du ha ge e t au i eau de l’aspe t
qualitatif est basée sur une connaissance des relations incluant notamment la conductivi-
t de l’i pa t et les a iatio s des aleu s de t i ues, et .
31
http://www.graphviz.org/
- 157 -
Figure 6.14 Modèle Promela généré par BPMN2PROMELA.
Figure 6.15 Vérification de la cohérence du processus de remboursement des frais par EpiSpin.
- 158 -
Figure 6.16 Génération du fichier Expense_reimbursement_process.dot.
Figure 6.17 Visualisation du fichier Expense_reimbursement_process.dot avec Graphiz.

- 159 -
Afi d’illust e l’i pa t d’u ha ge e t st u tu el su le od le de la ualit , ous

avons utilisé notre plug-in BPMNQ. En effet, pour expliquer la p opagatio de l’i pa t
qualitatif, nous mesurons et observons la qualité de ce processus avant le changement
(schéma S et ap s le ha ge e t s h a S’ .
La figure 6.12 a et la figure 6.12 b, montrent respectivement les différentes mesures
obtenues avant et après ce changement. Comme expliqué dans le chapitre 6, tout chan-
gement structurel ( S) invoqué sur un processus métier peut causer un impact relatif
( Q su u it e de la ualit . L’i pa t de Q peut être propagé progressivement aux
critères précédents (dans le sens arbre de la qualité) et aux facteurs correspondants, etc.
Cette évaluation que nous venons de décrire illustre l’impact qualitatif comme étant
matérialisé par la variation des différentes valeurs de métriques et par conséquent les
critères et les facteurs associés suite à un changement structurel.
6.4 Conclusion
Dans ce chapitre nous avons décrit, la conception et les fonctionnalités de la plate-
forme que nous avons développée et déployée pour la validation de notre contribution
pour la gestio de l’ olutio des p o essus tie . Cette plate-forme a été développée
sous forme d’u e se le de plug-ins Eclipse pour une meilleure utilisation auprès de la
communauté BP et un meilleur retou d’e p ie e.
Dans e hapit e ous a o s d’a o d d it l’architecture globale de la plate-forme qui
est constituée de quatre principaux plug-ins Eclipse qui sont BPMN2 modeler, BPMN
verification tool, BPMN Quality, et BPMN change propagation analyser. Nous avons donc
détaillé les fonctionnalités de chacun de ces plug-ins.
Finalement nous avons montré, à travers un scénario représentant un processus de
remboursement de frais de fonctionnement, l’utilisatio de notre plate-forme pour la
gestion de l’ olutio des p o essus tie . Les expérimentations que nous avons
effe tu es à l’aide de la plate-forme BPMN-CM ont concerné particulièrement des
processus de différents secteurs (bancaires, gestion administrative, etc.) et avec
différents degrés de complexité.
Actuellement, ot e t a ail de d eloppe e t po te à la fois su l’a o plisse e t et
l’achèvement du plug-in BPMN-CPA, et cela en intégrant une base de connaissance à
l’aide de la plate-forme Jena32 mais aussi étendre cette analyse a priori de l’i pa t du
changement sur autres couches que celle des processus métier.
Nos t a au d’i pl e tatio o e ent aussi le développement d’un outil qui
pe et d’i te p te le sultat d’u o t e-exemple fourni par EpiSpin sous forme
graphique "COUNTEREXAMPLE2BPMN" et non plus textuel comme il est le cas
actuellement.
32
http://jena.sourceforge.net
- 160 -
CHAPITRE
7
Conclusion et perspectives
7. Conclusion et perspectives
7.1 Résumé des contributions

Dans ce dernier chapitre, nous allons présenter le bilan de nos trois contributions
majeures que nous replaçons dans le contexte général de nos travaux de recherche.
Après avoir porté un regard critique sur les sujets que nous avons évoqués dans ce
manuscrit, nous présenterons les perspectives de nos travaux.
7.1.1 Bilan des contributions

Le travail présenté da s ette th se t aite de la gestio de l’ olutio des p o essus
tie . L’o je tif principal ta t, de pe ett e, d’u e pa t, la vérification du bon dérou-
lement du processus métier après chaque changement et d’aut e pa t, d’off i u o e
qui permet d'évaluer la p opagatio de l’i pa t d’u ha ge e t de p o essus tie .
Afin de s'atteler à cette tâche, nous avons proposé de découper la problématique globale
en trois axes principaux de recherche : (1) la vérification formelle des processus métier,
(2) l’a al se a priori de l’i pa t du ha ge e t des p o essus tie et e fi (3) la
gestion qualitative des processus métier.
Ap s a oi d ess u tat de l’a t des différentes approches et techniques les plus
largement connues dans le domaine de la vérification des processus métier et de
l’i t g atio des ha ge e ts dans ces derniers, nous avons proposé dans un premier
volet de nos travaux, une approche basée sur la technique du model-checking permettant
la vérification de la cohérence des modèles de processus métier telle ue l’absence
d’i te -blocage, de boucles infinies, etc. Cette technique permet également de vérifier la
conformité des processus métier a e l’e se le des gles e pla e. Dans un deuxième
volet de nos travaux de recherche, et afin d'évaluer les effets de vague et d'estimer le
oût d’u hangement de processus métier, nous avons proposé un mécanisme qui
permet de simuler et d’évaluer a priori la propagation de l’i pa t des changements dans
les processus métier. Cette démarche consiste à définir les relations qui existent entre les
différents éléments qui composent le modèle de processus métier. L'ensemble de ces
relations appelées relations de dépendance permet de déterminer les éléments qui sont
suceptibles d’ t e affectés par un changement de modèle de processus métier. Dans le
troisième et dernier volet de nos travaux, nous avons proposé un modèle qualitatif inspi-
ré par la norme ISO / CEI 9126-1 permettant une meilleure évaluation de la qualité glo-
ale d’u p o essus tie , et ela du a t tout so le de ie et plus pa ti uli e e t
après chaque changement de ce dernier.
7.1.1.1 Contribution à la vérification formelle des processus métier
La première contribution de cette thèse a porté sur la vérification formelle des
modèles de processus métier par la méthode du model-checking. En effet, nous avons
proposé une approche qui se base sur l'utilisation du model-checker SPIN pour vérifier les
propriétés de cohérence des modèles de processus métier.
Not e d a he, ue ous a o s d’ailleu s fo alis e, d ute pa u e t a sfo atio
auto atis e d’u od le de processus métier vers un modèle Promela. Le passage du
modèle de processus métier vers le code Promela est réalisé par un automate à états finis
te du st u tu e de k ipke o e u e ep se tatio i te diai e. L’o je tif ta t de
- 162 -
fournir une sémantique formelle à ces modèles et de générer ainsi tous les états possibles
d’u s st e da s lesquels la propriété à vérifier est testée exhaustivement sur l'en-
semble des exécutions possibles. En second lieu, nous avons exprimé en Logique Tempo-
relle Linéaire les différentes propriétés de cohérence des processus métier.
Le modèle résultant, ainsi que les différentes formules LTL sont fournis comme entrée
pour le model-checker SPIN qui a la charge de vérifier si ces propriétés sont satisfaites.
Da s le as d’u e réponse négative, SPIN fournit un contre-exemple montrant une exécu-
tion qui ne satisfait pas ces propriétés. De la même manière, cette approche a été adop-
tée pou ifie la o fo it des od les de p o essus tie a e l’e se le des
règles de conformité exprimées e LTL pa l’i te diai e de G-LTL suite à un change-
ment affectant l'un des deux.
Cependant, outre le fait que le model-checking ne peut adresser que des problèmes à
nombre d'états finis, une limite connue à l'utilisation de cette technique est l'explosion
combinatoire du nombre d'états. Cela dit, et en dépit de ces inconvénients qui sont ré-
sorbés en partie par certains travaux de recherche, la vérification formelle basée sur le
model-checking reste le meilleur choix à faire puisque la vérification est complètement
automatique et un contre-exemple est fourni dans le cas où la propriété serait violée.
7.1.1.2 Contribution à l’analyse a priori de l’impact du changement des processus mé-
tier
Lo s de l’ olutio des processus métier, il s’a e, pa fois, ue les modifications
apportées à une partie du modèle de processus métier ont un impact sur les autres
éléments du modèle. En effet, ce ph o e o u sous le o d’effet de ague se a-
nifeste par une propagation des effets de tout changement aussi minime soit-il sur un
t sg a d o e d’e tit s du p o essus. Il est do p i o dial de ett e e œu e des
a is es d’a al se a priori permettant de mieux comprendre et cerner la propagation
de l’i pa t du ha ge e t des p o essus tie afi d’ ite des situatio s i o t ôl es
survenant généralement après le changement et de conserver ainsi une certaine cohé-
rence du processus.
Dans notre deuxième contribution, nous avons proposé un mécanisme qui permet une
analyse a priori de l’i pa t du changement des processus métier à travers une
classification exhaustive des différentes relations de dépendance qui servent à véhiculer
la propagation de l’i pa t du ha ge e t. Ce a is e pe et non seulement
d’a al se les diff e tes relations de dépendance qui existent entre la partie changée et
les autres parties potentiellement affectées au sein du modèle de processus métier, mais
aussi d'analyser les relation entre ces modèles de processus métier et les services asso-
ciés.
Enfin, et pour mettre en place notre approche, nous avons p opos l’ la o atio d’un
système à base de connaissances et un ensemble de règles formulées pour les différents
types de relation permettant ainsi une analyse a priori de la propagation d’i pa t du
changement entre les différents éléments qui contituent et/ou qui communiquent avec
ce modèle de processus métier.
Cepe da t, u e des li ites a tuelles de ot e app o he d’a al se d’i pa t du
changement sur un modèle de processus métier consiste à ne pas prendre en
- 163 -
considération certains types de relation de dépendance telles que les acteurs et les
ressources, et u’il faud ait i t g e pa la suite da s ot e d a he d’a al se.
D’ailleu s, e i est l’u e de os pe spe ti es, ue ous p se to s da s la se tio
suivante.
7.1.1.3 Contribution à la gestion qualitative des processus métier
M e s’il ’e iste pas a tuelle e t un consensus sur une définition standard de la
ualit des p o essus tie , di e ses app o hes pou l’ aluatio de la ualit des p o-
cessus métier ont été proposées dans la littérature. Dans une troisième contribution, et
après avoir fait un tour d'horizon des différents travaux de recherche dans ce domaine,
nous avons tenté de proposer un cadre exhaustif inspiré de la norme ISO/ CEI 9126-1 re-
présentant à la fois une contribution à la maturité des travaux existants à l'égard de
l’ aluatio et de l'a lio atio de la ualit des p o essus tie et u o e pe et-
ta t de t aite la p o l ati ue de l’a al se de l’i pa t ualitatif du ha ge e t.
Enfin, les trois phases de notre approche ep se te t les fo tio alit s d’u outil
que nous avons développé et appelé BPMN-CM. Cet outil offre un cadre qui accompagne
les modeleurs et les experts métier dans la modélisation BPMN et la gestion des
changements de ces modèles. Toutefois, nous penso s u’u p otot pe e d pit de so
oût de alisatio este a toujou s u sujet d’a lio atio . Dans la section suivante,
nous présentons les perspectives de notre thèse.
7.1.2 Perspectives des travaux

Comme une première perspective de nos travaux de recherche concernant la
vérification formelle des processus métier, nous envisageons de prendre en compte le
flux de données en plus du flux de contrôle dans la vérification de la cohérence et de la
conformité des processus métier. Nous envisageons également de valider notre approche
sur des modèles de processus métier plus volumineux et plus complexes avec des
notations, et su tout d’auto atiser l'interprétation des contre-e e ples e as d’u e
incohérence dans ces modèles.
Dans un futur proche, et afin de compléter ot e app o he d’a al se d’i pa t du
changement dans les processus métier, nous envisageons tout d’a o d d’i lu e d’autres
types de relations de dépendance telles que les acteurs, les ressources en plus de celles
concernant les activités, données et rôles déjà utilisés dans ce manuscrit.
Dans le chapitre 4, nous avons également souligné l’i po ta e de o sid e l’impact
du changement des p o essus tie de diff e ts poi ts de ue o eptuels d’où u e
perspective principale de rendre l’a al se actuelle plus exhaustive en tenant compte des
points de vue fonctionnel, logique et comportemental en plus des deux points de vue
structurel et qualitatif déjà abordés dans notre thèse.
Afin de rendre cela possible, on prévoit d’utiliser la te h i ue de l’a al se de la
traçabilité en complément de celle de l’a al se des elatio s de d pe da e. Cette
a al se de t aça ilit po te a su la o pa aiso des diff e tes t a es d’e écution
"Process mining" d’u p o essus tie avant et après changement afi d’e t ai e u
comportement exploitable par cette analyse.
- 164 -
De la même manière, et dans le domaine de la gestion qualitative des processus

métier, ous esti o s u’il est i po ta t de o sid e la s a ti ue des od les de
pro essus tie aussi ie lo s de l’ aluatio ue lo s de l’a lio atio de leu ualit .
Pour cela, nous p oposo s d’assiste ette od lisatio pa u e d a he e t e su la
qualité qui vise à exploiter des connaissances de domaine exprimées sous la fo e d’une
o tologie. Cette d a he de ait s’appuyer sur les techniques de méta modélisation
pour rapprocher les connaissances du domaine de la connaissance exprimée par les
od les de p o essus tie , le ut ta t d’a lio e l’e p essi it de es od les.
- 165 -
- 166 -
Bibliographie
Abd-El-Hafiz, S. K. (1996). Evaluation of a knowledge-based approach to program understanding.
The d Wo ki g Co fe e e o ‘eve se E gi ee i g WC‘E (pp. 275-284).
Washington, DC, USA: IEEE Computer Society.
Abouzaid, F., & Mullins, J. (2009). Model-checking Web Services Orchestrations using BP-calculus.
Electronic Notes in Theoretical Computer Science (ENTCS) Vol. 255, 3-21.
Adams, M., ter Hofstede, A. H., Edmond, D., & van der Aalst, W. M. (2005). facilitating flexibility
and dynamic exception handling in workflows through worklets. In 17th International
Conference on Advanced Information Systems Engineering (CAiSE'05), (pp. 45-50).
Agostini, R., & De Michelis, G. (2000). A light workflow management system using simple process
models. Computer Supported Cooperative Work, 335-363.
Aguilar, E. R., Cardoso, J., García, F., Ruiz, F., & Piattini, M. (2009). Analysis and Validation of
Control-Flow Complexity Measures with BPMN Process Models. The 10th International
Workshop on Enterprise, Business-Process and Information Systems Modeling
(BPMDS'09), and 14th International Conference, EMMSAD 2009, held at CAiSE 2009 (pp.
58-70 ). Amsterdam, The Netherlands: Springer Berlin Heidelberg.
Aguilar, E. R., Ruiz, F., García, F., & Piattini, M. (2006). Applying Software Metrics to evaluate
Business Process Models. CLEI Electron. Journal, Vol. 9, No. 1.
Ajila, S. (1995). Software Maintenance: An Approach to Impact Analysis of Objects Change.

Journal of Software - Practice and Experience Vol.25, 1155-1181.
Alter, S. (1999). A general, yet useful theory of information systems. Association for Information
Systems, Vol.1, 1-70.
Alter, S. (1999). Information Systems: A Management Perspective. Edition 3e éd., Addison-Wesley.
Arango, G., Schoen, E., & Pettengill, R. (1993). A process for consolidating and reusing design
knowledge. The 15th international conference on Software Engineering (ICSE '93) (pp.
231-242). Baltimore, MD, USA: IEEE Computer Society.
ARIS. (2007). The Event-driven Process Chain. ARIS Design Platform,.
Arnold, R. S., & Bohner, S. A. (1993). Impact Analysis - Towards a Framework for Comparison. The
International Conference on Software Maintenance (ICSM '93) (pp. 292-301). Montréal,
Quebec, Canada: IEEE Computer Society.
Awad, A. (2007). BPMN-Q: A Language to Query Business Processes. The 2nd International
Workshop on Enterprise Modelling and Information Systems Architectures (EMISA'07),
(pp. 115-128). St. Goar, Germany.
- 167 -
Awad, A., & Puhlmann, F. (2008). Structural detection of deadlocks in business process models.
The 11th International Conference On Business Information Systems (BIS'08) (pp. 239-
250). Innsbruck, Austria: Springer Berlin Heidelberg.
Awad, A., Decker, G., & Weske, M. (2008). Efficient Compliance Checking Using BPMN-Q. The 6th
I te atio al Co fe e e o Busi ess P o ess Ma age e t BPM (pp. 326-341).
Milan, Italy: Springer Berlin Heidelberg.
Baniassad, E., & Clarke, S. (2004). Theme: An Approach for Aspect-Oriented Analysis and Design.
The 26th International Conference on Software Engineering (ICSE '04) (pp. 158-167). IEEE
Computer Society.
Becker, J., Rosemann, M., & von Uthmann, C. (2000). Guidelines of Business Process Modeling.
Dans Business Process Management (pp. 30-49). Springer Berlin Heidelberg.
Behrmann, G., David, R., & Larsen, K. G. (2004). A tutorial on UPPAAL. The International School on
Formal Methods for the Design of Computer, Communication, and Software Systems (pp.
200-236). Bertinora, Italy: Springer Berlin Heidelberg.
Bel Mokadem, H., Bérard, B., Bouyer, P., & Laroussinie, F. (2006). Timed Temporal Logics for
Abstracting Transient States. The 4th International Symposium on Automated Technology
for Verification and Analysis (ATVA'06) (pp. 337-351). Beijing, China: Springer Berlin
Heidelberg.
Belhajjame, K., Vargas-Solar, G., & Collet, C. (2001). Towards an Adaptable Workflow
Management System. 17èmes Journées BDA. Agadir, Maroc.
Biere, A. (2008). Tutorial on Model Checking, Modelling and Verification in Computer Science. The
3th International Conference on Algebraic Biology (AB'08) (pp. 16-21). Castle of
Hagenberg, Austria: Springer Berlin Heidelberg.
Bloom, J., Clark, C., Clifford, C., Duncan, A., Khan, H., & Papantoniou, M. (2003). Platform
Independent Petri-net Editor. Dans Rapport final du projet PIPE. Department of
Computing, Imperial College London.
Boehm, B. W., Brown, J. R., & Lipow, M. (1976). Quantitative evaluation of software quality. The
2nd international conference on Software engineering (ICSE '76) (pp. 592-605). IEEE
Computer Society.
Bohner, S. A. (1996). A Graph Traceability Approach for Software Change Impact Analysis.
Doctoral Dissertation - George Mason University.
Bohner, S. A. (2002). Software Change Impacts an Evolving Perspective. The International

conference on Software Maintenance (ICSM'02) (pp. 263-272). IEEE Computer Society.
Borghoff, U. M., Bottoni, P., Mussio, P., & Pareschi, R. (1997). Reflective Agents for Adaptive
Workflows. The 2d International Conference and Exhibition on Practical Application of
Intelligent Agents and Multi-Agents (PAAM'97) (pp. 405-420). London, UK: Society Press.
- 168 -
Boucher, X. (2007). Vers un pilotage agile de l'évolution des systèmes de production.
Briol, P. (2008). ingénierie des processus métiers de l'élaboration à l'exploitation. Edition Lulu.com.
Browne, M. C., Clarke, E. M., & Grümberg, O. (1988). Characterizing finite Kripke structures in
propositional temporal logic. Theoretical Computer Science - International Joint
Conference on Theory and Practice of Software Development Volume 59 Issue 1-2, 115-
131.
B , F., E ke t, M., Păt â ja , P.-L., & Romanenko, I. (2006). Realizing business processes with ECA
rules: benefits, challenges, limits. The 4th international conference on Principles and
Practice of Semantic Web Reasoning (PPSWR'06) (pp. 48-62). Budva, Montenegro:
Springer-Verlag Berlin.
Büchi, J. (1962). On a decision method in restricted second order arithmetic. The International
Congress on Logic, Method, and Philosophy of Science, (pp. 1-12).
Burch, J. R., Clarke, E. M., Mcmillan, K. L., Dill, D. L., & Hwang, L. J. (1990). Symbolic model
checking: 10^20 states and beyond. The 5th Annual IEEE Symposium on Logic in Computer
Science (LICS '90) (pp. 428-439). Philadelphia, Pennsylvania, USA: IEEE Computer Society.
Burkhart, T., & Loos, P. (2010). Flexible Business Processes - Evaluation of Current Approaches.
Multikonferenz Wirtschaftsinformatik. Göttingen, Germany.
Butler, K. A., Esposito, C., & Hebron, R. (1999). Connecting the design of software to the design.
Communications of the ACM. 42(1), 38-46.
Cardoso, J. (2005). About the Data-Flow Complexity of Web Processes. The 6th International
Workshop on Business Process Modeling, Development, and Support: Business Processes
and Support Systems: Design for Flexibility. Porto, Portugal.
Cardoso, J. (2005). Control-flo Co ple it Measu e e t of P o esses a d We uke ’s P ope ties.

The 6th International Enformatika Conference (IEC'05), (pp. 213-218).
Cardoso, J. (2005). Evaluating Workflows and Web Process Complexity. FL, USA: in Workflow
Handbook 2005, L. Fischer, Editor. 2005, Future Strategies Inc.: Lighthouse Point, p. 284-
290.
Cardoso, J. (2006). Process control-flow complexity metric: An empirical validation. IEEE

International Conference on Services Computing SCC '06, (pp. 167-173).
Cardoso, J., Mendling, J., Neumann, G., & Reijers, H. A. (2006). A discourse on complexity of
process models. International Workshops on Business Process Management (BPM'06) (pp.
117-128). Vienna, Austria: Springer Berlin Heidelberg.
Cardoso, J., Miller, J., & Arnold, J. (2002). Modeling Quality of Service for Workflows and Web
Service Processes. LSDIS Lab, Computer Science, University of Georgia. #02-200.
- 169 -
Casati, F., Ceri, S., Pernici, B., & Pozzi, G. (1996). Workflow Evolution. Data and Knowledge
Engineering, 438-455.
Cavano, J. P., & McCall, J. A. (1978). A framework for the measurement of software quality.
SIGSOFT Softw. Eng. Notes, 3(5), (pp. 133–139).
Chiu, D., Li, Q., & Karlapalem, K. (2001). Facilitating workflow evolution in an advanced object
environment. The 7th International Conference on Database Systems forAdvanced
Applications, (pp. 148-149). HongKong, China.
Chniti, A., Albert, P., & Charlet, J. (2011). Gestion de la cohérence des règles métier éditées à
pa ti d’o tologies OWL*. 22èmes Journées francophones d'Ingénierie des Connaissances
(IC 2011). Chambéry, France.
Chountas, P., Petrounias, I., & Kodogiannis, V. (2003). Temporal Modelling in Flexible Workflows.
The 18th International Symposium on Computer and Information Sciences (ISCIS' 03) (pp.
123-130). Antalya, Turkey: Springer Berlin Heidelberg.
Chulsoon, P., & Injun, C. (2004). Management of business process constraints using BPTrigger.
Journal of Computers in Industry Volume 55, Issue 1, 29–51.
Chun, S. A., Atluri, V., & Adam, N. R. (2002). Domain Knowledge-Based Automatic Workflow
Generation. The 13th International Conference on Database and Expert Systems
Applications (DEXA'02) (pp. 81-93). Aix-en-Provence, France: Springer Berlin Heidelberg.
Cimatti, A., Clarke, E., Giunchiglia, E., Giunchigli, F., Pistore, M., Roveri, M., et al. (2002). NuSMV 2:
An OpenSource Tool for Symbolic Model Checking. The 14th International Conference on
Computer Aided Verification (CAV'02) (pp. 359-364). Copenhagen, Denmark: Springer
Berlin Heidelberg.
Cimatti, A., Clarke, E., Giunchiglia, F., & Roveri, M. (2000). NUSMV: a new symbolic model checker.
International Journal on Software Tools for Technology Transfer.
Clarke Jr., E. M., Grumberg, O., & Peled, D. A. (1999). Model Checking. Cambridge, MA, USA: The
MIT Press; n edition (January 7, 1999).
Coalition, T. W. (1999). Workflow Management Coalition Terminology & Glossary. Rapport

numéro WFMC-TC-1011 Issue 3.0.
Crusson, T. (2003). Business Process Management – De la modélisation à l'exécution,

Positionnement par rapport aux Architectures Orientées Services. Intalio white paper.
Dą o ski, M., D a ik, M., T zaska, M., & Su ieta, K. . P otot pe of O je t-Oriented
Declarative Workflows. The 3th International Conference on Intelligent Information and
Database Systems (ACIIDS'11) (pp. 47-56). Daegu, Korea: Springer Berlin Heidelberg.
Dai, W., & Covvey, H. D. (2005). Query-Based Approach to Workflow Process Dependency Analysis.
Waterloo, Ontario,Canada: Technical Report 01, School of Computer Science and the
Waterloo Institute for Health Informatics Research .
- 170 -
David, R., & Alla, H. (1993). Autonomous and timed continuous Petri nets. Springer Berlin
Heidelberg.
David, R., & Alla, H. (2010). Non-Autonomous Petri Nets. Springer Berlin Heidelberg.
De Backer, M., & Snoeck, M. (2008). Business Process Verification: a Petri Net Approach. Belgium:
Technical report, Catholic University of Leuven.
Debauche, B., & Mégard, P. (2004). BPM Business Process Management : Pilotage métier de
l'entreprise. Edition Hermes Science Publications.
Decker, G., Dijkman, R., Dumas, M., & Luciano, G.-B. (2008). Transforming BPMN Diagrams into
YAWL Nets. The 6th International Conference on Business Process Management (BPM'08)
(pp. 386-389). Milan, Italy: Springer Berlin Heidelberg.
Dellen, B., Maurer, F., & Pews, G. (1997). Knowledge Based Techniques to Increase the Flexibility
of Workflow Management. Data and Knowledge Engineering, North-Holland, 269-295.
Deruelle, L., Bouneffa, M., Melab, N., Basson, H., & Goncalves, G. (2000). A Change Impact
Analysis Approach For CORBA-Based Federated Databases. The 11th International
Conference on Database and Expert Systems Applications (DEXA'00) (pp. 949-958).
London, UK: Springer Berlin Heidelberg.
Di Francescomarino, C., & Tonella, P. (2009). Crosscutting Concern Documentation by Visual

Query of Business Processes. The International Workshops On Business Process
Management (BPM'08) (pp. 18-31). Milano, Italy: Springer Berlin Heidelberg.
Diaz, G., Pardo, J.-J., Cambronero, M.-E., Valero, V., & Cuartero, F. (2005). Automatic Translation
of WS-CDLChoreographies to Timed Automata. The international conference on European
Performance Engineering, and Web Services and Formal Methods, international
conference on Formal Techniques for Computer Systems and Business Processes
(EPEW'05/WS-FM'05) (pp. 230-242). Versailles, France: Springer-Verlag Heidelberg.
Dijkman, R. M., Dumas, M., & Ouyang, C. (2007). Formal Semantics and Analysis of BPMN Process
Models using Petri Nets.
Dijkstra, E. (1971). Hierarchical Ordering of Sequential Processes. Acts Informatica I, 115–138.
El Kharbili, M., de Medeiros, A. K., Stein, S., & van der Aalst, W. P. (2008). Business Process
Compliance Checking Current State and Future Challenges. The Modellierung betrieblicher
I fo atio s s te e Mo IS , (pp. 107-113).
Fan, S., Dou, W., & Chen, J. (2007). Dual Workflow Nets: Mixed Control/Data-Flow Representation
for Workflow Modeling and Verification. The International Workshops: DBMAN 2007,
WebETrends 2007, PAIS 2007 and ASWAN 2007 (pp. 433-444). Huang Shan, China:
Springer-Verlag Berlin Heidelberg.
- 171 -
Farahbod, R., Glässer, U., & Vajihollahi, M. (2005). A Formal Semantics for the Business Process
Execution Language for Web Services. Web Services and Model-Driven Enterprise
Information Services (pp. 144-155). INSTICC Press.
Fehling, R. (1993). A concept of hierarchical Petri nets with building blocks. The 12th International
Conference on Application and Theory of Petri Nets (pp. 148-168). Springer Berlin
Heidelberg.
Feja, S., Speck, A., & Pulvermüller, E. (2009). Business Process Verification. GI-Jahrestagung, (pp.
4037-4051). Lübeck, Germany.
Fenton, N. E., & Pfleeger, S. L. (1998). Software Metrics: A Rigorous and Practical Approach.
Boston, MA, USA: PWS Publishing Co, 2ème edition.
Fernandez, J.-C., Garavel, H., Kerbrat, A., Mounier, L., Mateescu, R., & Sighireanu, M. (1996). CADP
- A Protocol Validation and Verification Toolbox. The 8th International Conference of
Computer Aided Verification (CAV '96) (pp. 437-440). Brunswick, NJ, USA: Springer Berlin
Heidelberg.
Ferrara, A. (2004). Web services: a process algebra approach. The 2nd international conference on
Service oriented computing (ICSOC'04), (pp. 242-251).
Fisler, K., Krishnamurthi, S., Meyerovich, L. A., & Tschantz, M. C. (2005). Verification and change-
impact analysis of access-control policies. The 27th international conference on Software
engineering (ICSE'05) (pp. 196-205). St. Louis, MO, USA: ACM New York.
Fisteus, J. A., Fernández, L. S., & Kloos, C. D. (2004). Formal Verification of BPEL4WS Business
Collaborations. The 5th International Conference on E-Commerce and Web Technologies
(EC-Web'04) (pp. 76-85). Zaragoza, Spain: Springer Berlin Heidelberg.
Fisteus, J. A., Fernández, L. S., & Kloos, C. D. (2004). Formal Verificationof BPEL4WS Business
Collaborations. Lecture notes in computer science , 76-85.
Foerster, A., Engels, G., & Schattkowsky, T. (2005). Activity Diagram Patterns for Modeling Quality
Constraints in Business Processes. The 8th International Conference on Model Driven
Engineering Languages and Systems (MoDELS'05) (pp. 2-16). Montego Bay, Jamaica:
Springer Berlin Heidelberg.
Fu, X., Bultan, T., & Su, J. (2004). Analysis of Interacting BPEL Web Services. 13th international
conference on World Wide Web (WWW '04) (pp. 621-630). ACM New York.
Gardner, T. (2009). UML Modelling of Automated Business. Processes with a Mapping to

BPEL4WS. IBM UK Laboratories.
Ghidini, C., Rospocher, M., & Serafini, L. (2008). A formalisation of BPMN in Description Logics.
Technical report, FBK.
- 172 -
Ghose, A. K., & Koliadis, G. (2007). Auditing business process compliance. The 5th International
Conference on Service-Oriented Computing (ICSOC'07) (pp. 169-180). Vienna, Austria:
Gillot, J.-N. (2008). The Complete Guide to Business Process Management: Business Process
Transformation or a Way of Aligning the Strategic Objectives of the Company and the
Information System Through the Processes. Edition Lulu.com.
Giurca, A., Lukichev, S., & Wagner, G. (2006). Modeling Web Services with URML. The Semantics
for Business Process Management Workshop (SBPM'06).
Glinz, M. (2007). On Non-Functional Requirements. The 5th IEEE International Requirement

Engineering Conference (RE '07) (pp. 21–26). Delhi, India: IEEE Computer Society.
Goedertier, S., & Vanthienen, J. (2006). Compliant and Flexible Business Processes with Business
Rules. The CAISE*06 Workshop on Business Process Modelling, Development, and Support
(BPMDS 2006). Luxemburg.
Goedertier, S., & Vanthienen, J. (2006). Designing Compliant Business Processes with Obligations
and Permissions. Business Process Management Workshops, BPM'06 (pp. 5-14). Vienna ,
AUTRICHE: Springer-Verlag Berlin, Heidelberg.
Grim-Yefsah, M., Rosenthal-Sabroux, C., & Thion-Goasdoué, V. (2011). BoQal : une méthode pour
l' aluatio de la ualit d’u p o essus tie . 29ème congrès INFORSID. Lille, France.
Group, O. M., & OMG, O. M. (2007). Unified Modeling Language. le rapport de spécification
version 2.1.1, numéro : formal/2007-02-03.
Group, T. B. (2000, July). Defining Business Rules, What are they really? Récupéré sur
www.businessrulesgroup.org
Gruhn, V., & Laue, R. (2006). Complexity Metrics for Business Process Models. The 9th
International Conference on Business Information Systems (BIS'06), (pp. 1-12). Klagenfurt,
Austria.
Gruhn, V., & Laue, R. (2006). How Style Checking Can Improve Business Process Models. 8th
International Conference on Enterprise Information Systems (ICEIS'06). Paphos, Cyprus.
Gruhn, V., & Laue, R. (2007). What business process modelers can learn from programmers.
Science of Computer Programming, 4-13.
Guceglioglu, A. S., & Demirors, O. (2005). Using Software Quality Characteristics to Measure
Business Process Quality. The 3rd International Conference on Business Process
Management (BPM'05) (pp. 374-379 ). Nancy, France: Springer Berlin Heidelberg.
Haney, F. M. (1972). Module connection analysis: a tool for scheduling software debugging
activities. The AFIPS Joint Computer Conference (pp. 173-179). AFIPS / ACM / Thomson
Book Company.
- 173 -
Heinl, P., Horn, S., Jablonski, S., Neeb, J., Stein, K., & Teschke, M. (1999). A Comprehensive
Approach to Flexibility in Workflow Management Systems. international joint conference
on Work activities coordination and collaboration (WACC '99) (pp. 79-88). ACM SIGSOFT
Software Engineering.
Heinrich, R., & Paech, B. (2010). Defining the Quality of Business Processes. The Modellierung
2010. LNI, vol. P-161, (pp. 133–148). Bonner Köllen, Germany.
Henderson-Sellers, B. (1995). Object-Oriented Metrics: Measures of Complexity. Prentice Hall.
Henzinger, T. A., Jhala, R., Majumdar, R., & Sutre, G. (2003). Software Verification with BLAST. The
10th International SPIN Workshop on Model Checking Software (SPIN) (pp. 235-239).
Portland, OR, USA: Springer Berlin Heidelberg.
Heravizadeh, M., Mendling, J., & Rosemann, M. (2009). Dimensions of Business Processes Quality
(QoBP). The International Workshops on Business Process Management (BPM'08) (pp. 80-
91). Milano, Italy: Springer Berlin Heidelberg.
Herbst, J. (1999). An Inductive Approach to the Acquisition and Adaptation of Workflow Models.
The IJCAI'99 Workshop on Intelligent Workflow and Process Management: The New
Frontier for AI in Business, (pp. 52-57).
Hillah, L. M., Kindler, E., Kordon, F., Petrucci, L., & Treves, N. (2009). A primer on the Petri Net
Markup Language and ISO/IEC 15909-2. Petri Net Newsletter, Vol. 76 (2009), (pp. pp. 9-
28).
Hinton, A., Kwiatkowska, M., Norman, G., & Parker, D. (2006). PRISM: A Tool for Automatic
Verification of Probabilistic Systems. The 12th International Conference On Tools and
Algorithms for the Construction and Analysis of Systems (TACAS'06) (pp. 441-444). Vienna,
Austria: Springer Berlin Heidelberg.
Hinz, S., Schmidt, K., & Stahl, C. (2005). Transforming BPEL to Petri Nets. The International
Conference on Business Process Management (BPM'05) (pp. 220-235). Springer-Verlag.
Hoare, C. A. (1978). Communicating Sequential Processes. Communications of the ACM Volume 21

Issue 8, 666-677.
Holzmann, G. J. (1997). State compression in spin. The 3rd SPIN Workshop.
Holzmann, G. J. (1997). The Model Checker SPIN. IEEE Transactions on Software Engineering, 279-
295.
Holzmann, G. J. (2003). The SPIN Model Checker. Primer and Reference Manual.
Hopcroft, J. E., Motwani, R., & Ullman, J. D. (2006). Introduction to Automata Theory, Languages,
and Computation. 3rd edition. Addison-Wesley, Reading.
- 174 -
Hornus, S., & Schnoebelen, P. (2002). On solving temporal logic queries. 9th International
Conference on Algebraic Methodology and Software Technology (AMAST'02) (pp. 163-
177). Saint-Gilles-les-Bains, Reunion Island, France: Springer Berlin Heidelberg.
Ishikawa, K. (1985). What is Total Quality Control? the Japanese Way. Prentice Hall.
ISO. (1989). LOTOS — A Formal Description Technique Based on the Temporal Ordering of
Observational Behaviour. International Organization for Standardization —
InformationProcessing Systems— Open Systems Interconnection.
ISO 9000:2000. (2005). ISO 9000:2000, Quality Management Systems - Fundamentals and
Vocabulary. International Organization for Standardization (ISO).
ISO/IEC 9126-1. (2001). ISO/IEC 9126-1.: Software engineering — Product quality — Part 1:
Quality model, First edition.
Jablonski, S., & Bussler, C. (1996). Workflow Management: Modeling Concepts, Architecture and
Implementation. International Thomson Publishing.
Jansen-Vullers, M., & Netjes, M. (2006). Business process simulation – a tool survey. The 7eme
Workshop and Tutorial on Practical Use ofColoured Petri Nets and CPN Tools.
Janssen, W., Mateescu, R., Mauw, S., & Springintveld, J. (1998). Verifying Business Processes using
SPIN. The 4th International SPIN Workshop, (pp. 21-36).
Jensen, K. (1992). Coloured Petri Nets. Modelling and Validation of Concurrent Systems.
Kherbouche, M. O., & Basson, H. (2011). Modélisation et analyse pour la gestion de l'évolution
des BPM. 29ème congrès INFORSID (Forum des jeunes chercheurs) (pp. 441-442). Lille,
France: INFORSID.
Kherbouche, M. O., Ahmad, A., & Basson, H. (2012). Detecting structural errors in BPMN process
models. The 15th IEEE International Multitopic Conference (INMIC'12) (pp. 425-431).
Islamabad, Punjab, Pakistan: IEEE Computer Society.
Kherbouche, M. O., Ahmad, A., & Basson, H. (2013). Formal approach for compliance rules
checking in Business Process Models. 2013 IEEE International Conference on Emerging
Technologies (ICET'13). Islamabad, Punjab, Pakistan: IEEE Computer Society.
Kherbouche, M. O., Ahmad, A., & Basson, H. (2013). Using model checking to control the
structural errors in BPMN models. The 7th IEEE International Conference on Research
Challenges in Information Science (RCIS'13) (pp. 1-12). Paris, France: IEEE Computer
Society.
Kherbouche, M. O., Ahmad, A., Bouneffa, M., & Basson, H. (2013). Ontology-based change impact
assessment in dynamic business processes. The 11th International Conference on
Frontiers of Information Technology (FIT'13). Islamabad, Pakistan: IEEE Computer Society .
- 175 -
Kherbouche, O. M., Ahmad, A., Bouneffa, M., & Basson, H. (2013). Analyzing the ripple effects of
change in business process models. 16th IEEE International Multitopic Conference
(INMIC'13). Lahore, Pakistan: IEEE Computer Society.
Kherbouche, O. M., Bouneffa, M., Ahmad, A., & Basso , . . A al se a p io i de l’i pa t du

changement des processus métiers. 31ème congrès INFORSID (pp. 257-265). Paris, France:
INFORSID.
Kim, K.-H. (2003). Workflow Dependency Analysis and Its Implications on Distributed Workflow
Systems. The 17th International Conference on Advanced Information Networking and
Applications (AINA'03) (pp. 677-682). IEEE Computer Society.
Klein, M., & Dellarocas, C. (2000). A Knowledge-based Approach to Handling Exceptions

inWorkflow Systems. Journal Computer Supported Cooperative Work Special Issue on
Adaptive Workflow System, 9(3/4)., 399-412.
Klingemann, J. (2000). Controlled flexibility in workflow management. The 12th International

Conference on Advanced Information Systems Engineering (CAiSE' 00) (pp. 126-141).
Stockholm, Sweden: Springer Berlin Heidelberg.
Knethen, A. v. (2001). A trace model for system requirements changes on embedded systems. The
4th International Workshop on Principles of Software Evolution (IWPSE '01) (pp. 17-26).
ACM New York.
Knolmayer, G., Endl, R., & Pfahrer, M. (2000). Modeling Processes and Workflows by Business
Rules. Business Process Management, Models, Techniques, and Empirical Studies (pp. 16-
29). Springer-Verlag.
Koehler, J., Tirenni, G., & Kumaran, S. (2002). From Business Process Model to Consistent
Implementation: A Case for Formal Verification Methods. the 6th International Entreprise
Distributed Object Computing Conference (EDOC'02) (pp. 96-106). Lausanne, Switzerland:
IEEE Computer Society.
Koshkina, M., & Van Breugel, F. (2003). Verification of business processes for Web services. Report
CS-2003-11, York University.
Kradolfer, M., & Geppert, A. (1999). Dynamic Workflow Schema Evolution based on Workflow
Type Versioning and Workflow Migration. The International Conference on Cooperative
Information Systems (CoopIS '99), (pp. 104-114).
Kripke, S. (1963). Semantical Considerations on Modal Logic. Acta Philosophica Fennica (16), 83-
94.
Kumar, K., & Narasipuram, M. M. (2006). Defining Requirements for Business Process Flexibility.
BPMDS 2006.
- 176 -
Laird, L. M., & Brennan, M. C. (2006). Software Measurement and Estimation: a Practical
Approach (Quantitative Software Engineering Series). Wiley-IEEE Computer Society Pr; 1
edition .
Langner, P., Schneider, C., & Wehler, J. (1998). Petri Net Based Certification of Event-Driven
Process Chains. The 19th International Conference on Application and Theory of Petri Nets
(pp. 286-305). Springer-Verlag London.
Lapadula, A., Pugliese, R., & Tiezzi, F. (2007). A Calculus for Orchestration of Web Services. The
16th European Symposium on Programming (ESOP'07) (pp. 33-47). Braga, Portugal:
Laroussinie, F., & Schnoebelen, P. (1995). A hierarchy of temporal logics with past. Theoretical
Computer Science 148(2), 303–324.
Latva-Koivisto, A. M. (2001). Finding a complexity measure for business process models.
Laue, R., & Awad, A. (2011). Visual suggestions for improvements in business process diagrams.
Journal of Visual Languages & Computing, 385–399.
Le Moigne, J.-L. (1984). La théorie du système général:théorie de la modélisation. Presses

Universitaires de France.
Lerner, B. S., Christov, S., Wise, A., & Osterweil, L. J. (2008). Exception Handling Patterns for
Process Modeling. 4th international workshop on Exception handling (WEH '08) (pp. 55-
61). ACM New York.
Leymann, F. (2001). Web Services Flow Language (WSFL 1.0). Récupéré sur
http://cin.ufpe.br/~redis/intranet/bibliography/standards/leymann-wsfl01.pdf
Leymann, F., & Roller, D. (2000). Production Workflow: Concepts and Techniques. Edition PTR
Prentice Hall.
Li, B. (2003). Managing Dependencies in Component-Based Systems Based on Matrix Model. Dans
Proc. Of Net.Object.Days 2003 (pp. 22-25).
Lindvall, M., & Sandahl, K. (1998). Traceability aspects of impact analysis in object-oriented
systems. Journal of Software Maintenance: Research and Practice Vol. 10 Issue 1, 37-57.
Liu, Y., Müller, S., & Xu, K. (2007). A static compliance-checking framework for business process
models. IBM Systems Journal Volume 46 Issue 2, 335-361.
Lu, R., & Sadiq, S. (2007). A Survey of Comparative Business Process Modeling Approaches. 10th
International Conference on Business Information Systems (BIS), number 4439 in LNCS (pp.
82-94). Springer.
Malone, T. W., Crowston, K., Lee, J., Pentland, B., Dellarocas, C., Wyner, G., et al. (1999). Tools for
Inventing Organizations: Toward a Handbook of Organizational Processes. Journal of
Management Science Vol.45 Issue 3, 425-443.
- 177 -
Marcus, A., & Maletic, J. I. (2003). Recovering documentation-to-source-code traceability links
using latent semantic indexing. The 25th International Conference on Software
Engineering (ICSE '03) (pp. 125-135). IEEE Computer Society.
Massuthe, P., & Weinberg, D. (2008). Fiona: A tool to analyze interacting open nets. The 15th
German Workshop on Algorithms and Tools for Petri Nets (AWPN'08) (pp. 99-104). CEUR
Workshop Proceedings Vol. 380.
Matjaz, B. J. (2006). Business Process Execution Language for Web Services BPEL and BPEL4WS
2nd Edition.
McCabe, T. (1976). A Complexity Measure. IEEE Transactions on Software Engineering Vol. 2 issus
4, 308-320.
Mccall, J. A., Cavano, J. P., & Walters, G. (1977). Factors in Software Quality 1, 2, and 3.
Mendling, J. (2006). Testing Density as a Complexity Metric for EPCs. Austria: Technical Report JM-
2006-11-15. Vienna University of Economics and Business Administration.
Mendling, J. (2008). Metrics for Process Models : Metrics for Process Models Empirical
Foundations of Verification, Error Prediction, and Guidelines for Correctness. Springer
Publishing Company.
Milner, R. (1980). A Calculus of Communicating Systems . Springer-Verlag .
Milner, R. (1989). Communication and Concurrency. Prentice-Hall International Series in Computer

Science.
Milner, R. (1999). Communicating and Mobile Systems: The Pi Calculus. Cambridge University
Press; 1st edition.
Minor, M., Schmalen, D., Koldehoff, A., & Bergmann, R. (2007). Structural adaptation of workflows
supported by a suspension mechanism and by case-based reasoning. 16th IEEE
International Workshops on Enabling Technologies: Infrastructure for Collaborative
Enterprises (WETICE'07), (pp. 370-375). Evry, France.
Misra, J., & Cook, W. R. (s.d.). Récupéré sur orc.csres.utexas.edu/papers/OrcJSSM.pdf
Mooney, J., Beath, C., Fitzgerald, G., Ross, J., & Weill, P. (2003). Managing Information Technology
for Strategic Flexibility and Agility: Rethinking Conceptual Models, Architecture,
Development, and Governance. 24th International Conference on Information Systems
(ICIS 2003). Seattle, WA, USA.
Mordechai, B.-A. (2008). Principles of the Spin Model Checker. Springer Berlin Heidelberg.
Morley, C., Bia-Figueiredo, M., & Gillette, Y. (2011). Processus métiers et S.I. - Gouvernance,
management, modélisation. DUNOD.
- 178 -
Morley, C., Hughes, J., Leblanc, B., & Hugues, O. (2007). Processus métiers et S.I. : évaluation,
modélisation, mise en oeuvre. Edition DUNOD.
Morley, C., Hugues, J., Leblanc, B., & Hugues, O. (2004). Processus Métiers et systèmes
d'information : Evaluation, modélisation, mise en oeuvre. Dunod.
Müller, R., Greiner, U., & Rahm, E. (2004). AGENT WORK: a workflow system supporting rule-
based workflow adaptation. Data & Knowledge Engineering Vol. 51(2), 223-256.
Nakajima, S. (2006). Model-Checking Behavioral Specification of BPEL Applications. Electronic

Notes in Theoretical Computer Science (ENTCS) Vol.151 Issue 2, 89-105.
Nurcan, S. (2008). A Survey on the Flexibility Requirements Related to Business Processes and
Modeling Artifacts. The 41st Annual Hawaii International Conference on System Sciences
(HICSS '08) (pp. 378-388). Big Island, Hawaii, USA: IEEE Computer Society Washington.
Nurcan, S., Etien, A., Kaabi, R. S., Zoukar, I., & Rolland, C. (2005). A Strategy Driven Business
Process Modelling Approach. Special issue of the Business Process Management Journal
on "Goal-oriented business process modeling", Emerald, 11:6.
OASIS. (2003). Collaboration-Protocol Profile and Agreement Specification,ebXML Trading-

Partners Team Version 1.0. Dans ebXML specification.
OASIS. (2007). Business Process Execution Language for Web Services (BPE4WS 2.0). Récupéré sur
https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsbpel
OASIS Standard. (2007). OASIS Web Services Business Process Execution Language (WSBPEL) TC.
Récupéré sur https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsbpel
OMG, O. M. (2011, January). Business Process Model and Notation (BPMN) Version 2.0. Récupéré
sur http://www.omg.org/spec/BPMN/2.0/PDF
Onoda, S., Ikkai, Y., Kobayashi, T., & Komoda, N. (1999). Definition of Deadlock Patterns for
Business Processes Work ow Models. Thirty-second Annual Hawaii International
Conference on System Sciences (HICSS '99) (pp. 50-65). IEEE Computer Society.
Ouyang, C., Dumas, M., ter Hofstede, A. H., & Van der Aalst, W. M. (2006). From BPMN Process
Models to BPEL Web Services. IEEE International Conference on Web Services (ICWS'06)
(pp. pp. 285-292). IEEE Computer Society Washington, DC, USA.
Ouyang, C., Van der Aalst, W. M., Dumas, M., & ter Hofstede, A. H. (2006). Translating BPMN to
BPEL*. Dans le rapport BPM-06.
Ouyang, C., Verbeek, E., van der Aalst, W. M., Breutel, S., Dumas, M., & ter Hofstede, A. H. (2005).
WofBPEL: A Tool for Automated Analysis of BPEL Processes. The Third International
Conference On Service-Oriented Computing - (ICSOC'05) (pp. 484-489). Amsterdam,
Netherlands: Springer Berlin Heidelberg.
- 179 -
Pesic, M., & Van der Aalst, W. M. (2006). A declarative approach for flexible business processes
management. International conference on Business Process Management
Workshops,BPM'06 (pp. 169-180). Springer-Verlag Berlin, Heidelberg.
Pesic, M., Schonenberg, H., & van der Aalst, W. M. (2007). DECLARE: Full Support for Loosely-
Structured Processes. The 11th IEEE International Enterprise Distributed Object Computing
Conference (EDOC '07) (pp. 287-300). Annapolis, Maryland, USA: IEEE Computer Society.
Pfleeger, S. L., & Bohner, S. A. (1990). A Framework for Software Maintenance Metrics. The IEEE
Transactions on Software Engineering (pp. 320-327). San Diego, CA, USA: IEEE Computer
Society.
Pistore, M., Traverso, P., Bertoli, P. G., & Marconi, A. (2005). Automated Synthesis of Composite
BPEL4WS Web Services. The IEEE International Conference on Web Services (ICWS '05)
(pp. pp. 293-301). IEEE Computer Society .
Pnueli, A. (1979). The temporal semantics of concurrent programs. The International Symposium
on Semantics of Concurrent Computation (pp. 1-20). Evian, France: Springer Berlin
Heidelberg.
Prandi, D., Quaglia, P., & Zannone, N. (2008). Formal analysis of BPMN via a translation into
COWS. The 10th international conference on Coordination models and languages (pp.
249-263). Oslo, Norway: Springer Berlin Heidelberg.
Proth, J.-M., & Xie, X. (1995). Les réseaux de Petri pour la conception et la gestion des systèmes de
production. Masson.
Pu, G., Zhao, X., Wang, S., & Qiu, Z. (2006). Towards the Semantics and Verification of BPEL4WS.
Electronic Notes in Theoretical Computer Science, 33–52.
Puhlmann, F., & Weske, M. (2005). Using the pi-calculus for Formalizing Workflow Patterns. The
3rd international conference on Business Process Management (BPM'05) (pp. 153-168).
Springer-Verlag Berlin, Heidelberg.
Rajabi, B. A., & Lee, S. P. (2010). Modeling and analysis of change management in dynamic
business process. International Journal of Computer and Electrical Engineering, 2 (1), 181-
189.
Rajlich, V. (1997). A Model for Change Propagation Based on Graph Rewriting. The International
Conference on Software Maintenance (ICSM '97) (pp. 84-91). Washington, DC, USA: IEEE
Computer Society.
Ramadan, M., Elmongui, H. G., & Hassan, R. (2011). BPMN Formalisation using Coloured Petri
Nets. The 2nd GSTF Annual International Conference on Software Engineering &
Applications (SEA'11). Singapore, Singapore.
Regev, G., & Wegmann, A. (2005). A regulation-based view on business process and supporting
system flexibility. CAiSE Wo kshops, (pp. 91-98).
- 180 -
Regev, G., Soffer, P., & Schmidt, R. (2006). Taxonomy of Flexibility in Business Processes. 7th
Workshop on Business Process Modeling, Development, and Support (BPMDS'06), (pp. 90-
93). Luxemburg.
Reichert, M., & Dadam, P. (1998). ADEPTflex-supporting dynamic changes of workflows without
losing control. Journal of Intelligent Information Systems, 93-129.
Reichert, M., Dadam, P., & Bauer, T. (2003). Dealing with forward and backward jumps in
workflow management systems. Software and Systems Modeling Volume 2, Issue 1, 37-
58.
Reichert, M., Rinderle, S., Kreher, U., & Dadam, P. (2005). Adaptive Process Management with
ADEPT2. The 21st International Conference on Data Engineering (ICDE '05) (pp. 1113-
1114). Tokyo, Japan: IEEE Computer Society.
Reijers, H. A. (2006). Workflow Flexibility: The Forlorn Promise. 15th IEEE International Workshops
on Enabling Technologies: Infrastructure for Collaborative Enterprises (WETICE '06) (pp.
271-272). IEEE Computer Society.
Reijers, H. A., & Vanderfeesten, I. T. (2004). Cohesion and Coupling Metrics for Workflow Process
Design. The 2nd International Conference on Business Process Management (BPM'04) (pp.
290-305). Potsdam, Germany: Springer Berlin Heidelberg.
Reix, R. (2004). Systèmes d'Information et Management des Organisations. Edition VUIBERT.
Rinderle, S., Reichert, M., & Dadam, P. (2003). Evaluation of Correctness Criteria for Dynamic
Workflow Changes. The International Conference On Business Process Management
(BPM'03) (pp. 41-57). Eindhoven, The Netherlands: Springer Berlin Heidelberg.
Rinderle, S., Reichert, M., & Dadam, P. (2003). On Dealing With Semantically ConflictingBusiness
Process Changes. Technical Report. University of Ulm, Ulm.
Rinderle, S., Reichert, M., & Dadam, P. (2004). Correctness criteria for dynamic changes in
workflow systems: a survey. Data & Knowledge Engineering, 9-34.
Rinderle, S., Reichert, M., & Dadam, P. (2004). Disjoint and Overlapping Process Changes:
Challenges, Solutions, Applications. The 11th International Conference on Cooperative
Information Systems (CooplS'04) (pp. 101-120). Agia Napa, Cyprus: Springer Berlin
Heidelberg.
Rolón Aguilar, E., García, F., & Ruiz, F. (2006). Evaluation Measures for Business Process Models.
The ACM S posiu o Applied Co puti g SAC (pp. 1567-1568). Dijon, France:
ACM New York.
Rolón Aguilar, E., Ruiz, F., García, F., & Piattini, M. (2006). Applying Software Metrics to evaluate
Business Process Models. CLEI electronic journal, Vol.9 Number 1.
- 181 -
Rosario, S., Benveniste, A., Haar, S., & Jard, C. (2006). Net systems semantics of Web Services
Orchestrations modeled in Orc. Research Report IRISA, No. 1780 Istitut de Recherche en
Informatique et Systèmes Aléatoires.
Ross, A. M., Rhodes, D. H., & Hastings, D. E. (2008). Defining Changeability: Reconciling Flexibility,
Adaptability, Scalability, Modifiability, and Robustness for Maintaining System Lifecycle
Value. Systems Engineering, 246-262.
Rozier, K. Y. (2011). Survey: Linear Temporal Logic Symbolic Model Checking. Computer Science
Review Volume 5 Issue 2, 163-203.
Russell, N., & te ofstede, A. . 2009). newYAWL: Towards Workflow 2.0. Dans T. o. II, Special
Issue on Concurrency in Process-Aware Information Systems (pp. 79-97). Springer Berlin
Heidelberg.
Russell, N., Ter Hofstede, A. H., & Mulyar, N. (2006). Workflow ControlFlow Patterns: A Revised
View. BPM Center Report BPM-06-22.
Russell, N., Ter Hofstede, A. H., Edmond, D., & van der Aalst, W. M. (2005). Workflow Data
Patterns: Identification, Representation and Tool Support. International Conference on
Conceptual Modeling (ER), (pp. 353-368). Klagenfurt, Austria.
Russell, N., van der Aalst, W. M., Ter Hofstede, A. H., & Edmond, D. (2004). Workflow Resource
Patterns: Identification, Representation and Tool Support. 17th International Conference,
CAiSE 2005 (pp. 216-232). Porto, Portugal: Advanced Information Systems Engineering.
Ryder, B. G., & Tip, F. (2001). Change impact analysis for object-oriented programs. The 2001 ACM
SIGPLAN-SIGSOFT workshop on Program analysis for software tools and engineering
(PASTE '01) (pp. 46-53). ACM New York.
Sadiq, S., & Orlowska, M. (1999). Architectural Considerations in Systems Supporting Dynamic
Workflow Modification. The Workshop on Software Architectures for Business Process
Ma age e t at the th Co f. o Adva ed I fo atio S ste s E gi ee i g CaiSE .
Heidelberg, Germany.
Sadiq, S., Orlowska, M., & Sadiq, W. (2004). Data flow and validation in workflow modelling. The
the 15th Australasian database conference (ADC '04 ) (pp. 207-214). Australian Computer
Society.
Sadiq, W., & Orlowska, M. E. (1996). Modeling and Verification of Workflow Graphs. Australia:
Technical Report No. 386 Department of Computer Science, The University of
Queensland, Australia.
Sadiq, W., & Orlowska, M. E. (1997). On Correctness Issues in Conceptual Modeling of Workflows.
European Conference on Informatio S ste s ECIS . Cork, Ireland.
- 182 -
Sadiq, W., & Orlowska, M. E. (1999). On Capturing Process Requirements ofWorkflow
BasedBusiness Information Systems. 3rd International Conference on Business
Information Systems BIS'99 (pp. 281-294). Poznan, Poland: Springer Verlag.
Salaün, G., Bordeaux, L., & Schaerf, M. (2004). Describing and reasoning on Web services using
process algebra. The IEEE International Conference on Web Services, (pp. 43-50).
Salaün, G., Ferrara, A., & Chirichiello, A. (2004). Negotiation Among Web Services Using
LOTOS/CADP. The European Conference Web Services (ECOWS'04) (pp. pp. 198-212).
Erfurt, Germany: Springer-Verlag Berlin Heidelberg.
Sánchez-González, L., García, F., Mendling, J., & Ruiz, F. (2010). Quality Assessment of Business
Process Models Based on Thresholds. The Confederated International Conferences On the
Move to Meaningful Internet Systems: OTM 2010 (pp. 78-95 ). Hersonissos, Crete, Greece:
Sánchez-González, L., García, F., Mendling, J., Ruiz, F., & Piattini, M. (2010). Prediction of Business
Process Model Quality Based on Structural Metrics. The 29th International Conference on
Conceptual Modeling (ER'10) (pp. 458-463 ). Vancouver, BC, Canada: Springer Berlin
Heidelberg.
Sánchez-González, L., Ruiz, F., García, F., & Piattini, M. (2011). Improving Quality of Business
Process Models. The 6th International Conference on Evaluation of Novel Approaches to
Software Engineering (ENASE'11) (pp. 130-144). Beijing, China: Springer Berlin Heidelberg.
Scheer, A.-W. (2000). ARIS: Business Process Modelling. Springer-Verlag Berlin and Heidelberg .
Scheer, A.-W. (2010). ARIS - Business Process Frameworks. Springer; 3rd edition (June 29, 2010) .
Schmidt, K. (2000). LoLA: a low level analyser. The 21st International Conference Application and
Theory of Petri Nets (ICATPN'00) (pp. 465-474). Aarhus, Denmark: Springer Berlin
Heidelberg.
Schneider, K., & Prof.Dr Schmid, D. (1997). CTL and Equivalent Sublanguages of CTL. The 5th
International Conference on Computer Hardware Description Languages and their
Applications (pp. 40-59). Toledo, Spain: Springer US.
Schonenberg, H., Mans, R., Russell, N., Mulyar, N., & van der Aalst, W. (2008). Process Flexibility: A
Survey of Contemporary Approaches. Advances in Enterprise Engineering.
Schonenberg, M., Mans, R., Russell, N., Mulyar, N., & van der Aalst, W. (2007). Towards a
Taxonomy of Process Flexibility (Extended Version). Dans le rapport interne BPM Center
Report BPMcenter.org, 2007.
Smith, H., & Fingar, P. (2003). Workflow is just a Pi process. BPTrends.
Soffer, P. (2005). On the Notion of Flexibility in Business Processes. CAiSE Wo kshops, (pp. 35-
42).
- 183 -
Song Dong, J., Liu, Y., Sun, J., & Zhang, X. (2006). Verification of Computation Orchestration via
Timed Automata. The 8th International Conference on Formal Engineering Methods (pp.
226-245). Springer Verlag.
Speck, A., Feja, S., Witt, S., & Pulvermüller, E. (2011 ). Formalizing Business Process Specifications.
Computer Science and Information Systems 2011 Vol. 8, Issue 2, 427-446.
SPINOV. (2006). Modélisation des Processus Métiers: Etat de l'Art et Conseils Pratiques. Rapport
CITI.
Sun, P., & Jiang, C. (2009). Analysis of workflow dynamic changes based on Petri net. Information
and Software Technology Vol. 51, Issue 2, 284–292.
Sun, Y., Huang, J. Z., & Meng, X. (2011). Integrating constraints to support legally flexible business
processes. Information Systems Frontiers archive Volume 13 Issue 2, 171-189.
Takemura, T. (2008). Formal Semantics and Verification of BPMN Transaction and Compensation.
The IEEE Asia-Pacific Services Computing Conference (APSCC '08), (pp. 284-290). Los
Alamitos.
Tantitharanukul, N. (2010). Detecting deadlock and multiple termination in BPMN model using
process automata. International Conference on Electrical Engineering/Electronics
Computer Telecommunications and Information Technology (ECTI-CON 2010), (pp. 478-
482). Chaing Mai.
Tantitharanukul, N., & Jumpamule, W. (2010). Detection of LiveLock in BPMN Using Process
Expression. The 4th International Conference on Advances in Information Technology
(IAIT'2010) (pp. 164-174). Bangkok, Thailand: Advances in Information
TechnologyCommunications in Computer and Information Science.
Thatte, S. (2001). XLANG - Web Services For Business Process Design. Récupéré sur
http://www.gotdotnet.com/team/xml_wsspecs/xlang-c/default.htm
The Workflow Management Coalition. (2008). Final XPDL 2.1 Specification. dans le Rapport de
spécification numéro WFMC-TC-10.
Turver, R. J., & Munro, M. (1994). An early impact analysis technique for software maintenance.
Journal of Software Maintenance:Research and Practice, Volume 6, No. 1, 35-52.
Van Belle, J.-P. (2004). A proposed framework for the analysis and evaluation of business models.
The 2004 annual research conference of the South African institute of computer scientists
and information technologists on IT research in developing countries (SAICSIT '04), (pp.
210-215). South African Institute for Computer Scientists and Information Technologists ,
Republic of South Africa.
van der Aalst, W. (1998). The Application of Petri Nets to Workflow Management. The Journal of
Circuits, Systems and Computers, Vol. 8, No. 1, 21-66.
- 184 -
van der Aalst, W. (1999). Formalization and verification of event-driven process chains.
Information and Software Technology, 41(10), 639-650.
van der Aalst, W. (2001). How to handle dynamic change and capture management information?
An approach based on generic workflow models. Journal of Computer Systems Science
Engineering 15(5).
van der Aalst, W. M. (2007). Challenges in Business Process Analysis. The 9th International
Conference On Enterprise Information Systems (ICEIS'07) (pp. 27-42). Funchal, Madeira:
van der Aalst, W. M., & Song, M. (2004). Mining Social Networks: Uncovering Interaction Patterns
in Business Processes. The 2nd International Conference on Business Process Management
(BPM'04) (pp. 244-260). Potsdam, Germany: Springer Berlin Heidelberg.
Van der Aalst, W. M., Ter Hofstede, A. H., & Weske, M. (2003). Business Process Management: A
Survey. The international conference on Business process management, BPM 2003 (pp. 1–
12). LNCS 2678, 2003. Springer-Verlag Berlin Heidelberg.
van der Aalst, W., & ter Hofstede, A. (2005). YAWL: yet another workflow language. Information
Systems Volume 30, Issue 4, 245-275.
van der Aalst, W., & Van Dongen, B. F. (2002). Discovering Workflow PerformanceModels from
Timed Logs. The International Conference on Engineering and Deployment of Cooperative
Information Systems (EDCIS' 02) (pp. pp. 45-63). Springer Berlin Heidelberg.
van der Aalst, W., Basten, T., Verbeek, H. M., Verkoulen, P. A., & Voorhoeve, M. (1999). Adaptive
workflow - On the interplay between flexibility and support. Filipe, J.; Cordeiro, J.:
Proceedings of the first International Conference on Enterprise Information Systems, Vol.
2, (pp. 353-360). Setúbal, Portugal.
van der Aalst, W., ter Hofstede, A., Kiepuszewski, B., & Barros, A. (2003). Workflow Patterns.
Distributed and Parallel Databases, 14(3):5-51, 5-51.
van Dongen, B. F., & Jansen-Vullers, M. H. (2005). Verification of SAP Reference Models. The 3rd
International Conference On Business Process Management (BPM'05) (pp. 464-469).
Nancy, France: Springer Berlin Heidelberg.
van Dongen, B. F., de Medeiros, A. K., Verbeek, H., Weijters, A. J., & van der Aalst, W. M. (2005).
The ProM Framework: A New Era in Process Mining Tool Support. The 26th International
Conference on Applications and Theory of Petri Nets (ICATPN' 05) (pp. 444-454). Miami,
USA: Springer Berlin Heidelberg.
Vanderfeesten, I. T., Cardoso, J., & Reijers, H. A. (2007). A weighted coupling metric for business
process models. The Workshop of 19th International Conference on Advanced Information
Systems Engineering (CAiSE'07), (pp. 41-44). Trondheim, Norway.
- 185 -
Vanderfeesten, I. T., Reijers, H. A., & van der Alst, W. (2008). Evaluating workflow process designs
using cohesion and coupling metrics. Computers in industry, 420-437.
Vaz, C., & Ferreira, C. (2007). Formal verification of workflow patterns with spin. Technical Report,
April 2007. INESC-ID Tec. Rep. 12.
Vaz, C., & Ferreira, C. (2007). Towards Automated Verification of Web Services. The IADIS
International Conference on WWW/Internet 2007.
Verbeek, E., van Hattem, M., Reijers, H., & de Munk, W. (2005). Protos 7.0: Simulation Made
Accessible. The 26th International Conference On Applications and Theory of Petri Nets
(ICATPN'05) (pp. 465-474). Miami, USA: Springer Berlin Heidelberg.
Verbeek, H., Basten, T., & van der Aalst, W. (2001). Diagnosing Workflow Processes Using Woflan.
THE COMPUTER JOURNAL.
Wagner, G. (2005). Rule Modeling and Markup. Reasoning Web (pp. 251-274). Springer.
Wagner, G., Giurca, A., & Lukichev, S. (2006). A Usable Interchange Format for Rich Syntax Rules
Integrating OCL, RuleML and SWRL (2006). Reasoning on the Web (RoW2006).
Walton, C. D. (2005). Model Checking Agent Dialogues. The 2nd International Workshop on
Declarative Agent Languages and Technologies II (DALT'04) (pp. 132-147). New York, NY,
USA: Springer Berlin Heidelberg.
Wang, J. (1998). Timed Petri Nets: Theory and Application. Springer; 1998 edition .
Wang, S., & Capretz, M. A. (2009). A Dependency Impact Analysis Model for Web Services
Evolution. The IEEE International Conference on Web Services (ICWS'09) (pp. 359-365). Los
Angeles, CA, USA: IEEE Computer Society.
Weber, B., Reichert, M., & Rinderle-Ma, S. (2008). Change patterns and change support features –
Enhancing flexibility in process-aware information systems. Data & Knowledge
Engineering Volume 66 Issue 3, 438-466.
Weber, B., Wild, W., Lauer, M., & Rei, M. (2006). Improving Exception Handling by Discovering
Change Dependencies in Adaptive Process Management Systems. BPM 2006 International
Workshops, BPD,, (pp. 93-104). Vienna, Austria.
Weerawarana, S., Curbera, F., Leymann, F., Storey, T., & Ferguson, D. F. (2005). Web Services
Platform Architecture: SOAP, WSDL, WS-Policy, WS-Addressing, WS-Bpel, WS-Reliable
Messaging and More. Edition Prentice Hall Computer.
Weijters, A. J., & van der Aalst, W. M. (2003). Rediscovering workflow models from event-based
data using little thumb. Journal of Integrated Computer-Aided Engineering, 151-162.
Weske, M. (1998). Flexible modeling and execution of workflow activities. The 31th Annual Hawaii
International Conference on System Sciences (HICSS'98) (pp. 713-722). IEEE Computer
Society.
- 186 -
Weske, M. (2000). Workflow Management Systems: Formal Foundation, Conceptual Design,
Implementation Aspects. University of M•unster, Habil Thesis.
Weske, M. (2001). Formal Foundation and Conceptual Design of Dynamic Adaptations in a

Workflow Management System. The 34th Annual Hawaii International Conference on
System Sciences (HICSS '01). IEEE Computer Society .
Wolfgang, T. (1989). Computation tree logic and regular -languages. The School/Workshop of
Linear Time, Branching Time and Partial Order in Logics and Models for Concurrency (pp.
690-713). Noordwijkerhout, Netherlands: Springer Berlin Heidelberg.
Wombacher, A., Fankhauser, P., & Neuhold, E. (2004). Transforming BPEL into Annotated
Deterministic Finite State Automata for Service Discovery. The IEEE International
Conference on Web Services (ICWS'04) (pp. 316-323). EE Computer Society.
Wong, B., & Jeffery, R. (1995). Quality Metrics : ISO9126 and Stakeholder Perceptions.
Wong, B., & Jeffery, R. (2001). Cognitive Structures of Software Evaluation: A Means-End Chain
Analysis of Quality. The3rd International Conference on Product Focused Software Process
Improvement (pp. 6-26 ). Kaiserslautern, Germany: Springer Berlin Heidelberg.
Wong, P. Y., & Gibbons, J. (2008). A Process Semantics for BPMN. The 10th International
Conference on Formal Methods and Software Engineering (ICFEM'08) (pp. 355-374).
Kitakyushu-City, Japan: Springer-Verlag Berlin, Heidelberg.
Woodcock, J., & Davies, J. (1996). Using Z: specification, refinement, and proof. Prentice Hall.
Workflow Management Coalition. (1999). Workflow Management Coalition Terminology &

Glossary (Document No. WFMC-TC-1011). Brussels.
Yang, D., & Zhang, S.-s. (2003). Approach for workflow modeling using pi-calculus. Journal of
Zhejiang University Science, 643-650.
Yang, Y., Tan, Q., & Xiao, Y. (2005). Verifying web services composition based on hierarchical
colored petri nets. The 1st international workshop on Interoperability of heterogeneous
information systems (IHIS '05) (pp. 47-54). ACM Press.
Ye, J., Sun, S., Wen, L., & Song, W. (2008). Transformation of BPMN to YAWL. The International
Conference on Computer Science and Software Engineering (CSSE'08), (pp. 354-359).
Wuhan, China.
Yi, X., & Kochut, K. J. (2004). A CP-nets-based Design and Verification Framework for Web Services
Composition. The IEEE International Conference on Web Services (ICWS '04) (pp. 756-760).
IEEE Computer Society.
Yu, T.-L., Goldberg, D. E., Sastry, K., Lima, C. F., & Pelikan, M. (2009). Dependency structure matrix,
genetic algorithms, and effective recombination. Journal of Evolutionary Computation Vo.
17 Issue 4, 595-626.
- 187 -
Zeng, L., Flaxer, D., Chang, H., & Jeng, J.-J. (2002). PLM flow-Dynamic Business Process
Composition and Execution by Rule Inference. The Third International Workshop on
Technologies for E-Services TES '02 (pp. 141-150). Springer-Verlag London.
Zeng, L., Ngu, A., Benatallah, B., & O'Dell, M. (2001). An agent-based approach for supporting
cross-enterprise workflows. The 12th Australasian database conference (ADC'01) (pp.
123-130). IEEE Computer Society.
Zhao, X., & Liu, C. (2013). Version management for business process schema evolution.
Information Systems Volume 38, Issue 8, 1046–1069.
zur Muehlen, M. (2004). Workflow-based process controlling: foundation, design, and application
of workflow-driven process information systems. Process information system.
zur Muehlen, M., & Indulska, M. (2010). Modeling languages for business processes and business
rules: A representational analysis. Information Systems Volume 35, Issue 4, 379-390.
- 188 -

Kherbouche PDF

Transféré par

Droits d'auteur :

Formats disponibles

Kherbouche PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Kherbouche PDF

Transféré par

Droits d'auteur :

Formats disponibles

Contribution à la gestion de l’évolution des processus

To cite this version:

HAL Id: tel-00968863

HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est

Présentée et soutenue par :

Contributions à la gestio de l’évolutio des

M. Henri Basson P ofesseu à l’U i e sit du Litto al Côte d’Opale (Directeur)

Mme. Selmin Nurcan Maître de Conférences à l'Université Paris 1, HDR (Rapportrice)

M. François Charoy P ofesseu à l’U i e sit de Lo ai e (Rapporteur)

M. Mourad Oussalah Professeur à l’U i e sit de Na tes (Examinateur)

M. Mourad Bouneffa Maît e de Co f e es à l’U i e sit du Litto al Côte d’Opale (Co-Encadrent)

Je tiens tout d'abord à exprimer ma gratitude et mes remerciements particuliers à

Je remercie aussi chaleureusement mes rapporteurs pour toute l'attention et

Calais, le 12 Octobre 2013

Mohammed Oussama Kherbouche

Ce travail consiste à proposer un ensemble de contributions permettant une véri-

This work contributes an eventual improvement, in regard, to verify the coherence

 En préambule, le chapitre 1 présente brièvement chacune des définitions et no-

1.1 Contexte et terminologie

1.2 Entreprise, pilotage et système d’information

Figure 1.1 La o positio d u s st e d e t ep ise

1.3 Le processus dans la gouvernance du système d’information

S st e d’I for atio Permet

Acteurs Informations Système Informatique

Figure 1.2 Système d'information et système informatique

La diffusio de l’app o he p o essus a o duit récemment à intégrer cette notion dans

p o essus so t u i ue e t du t aite e t de l’i fo atio : saisie, stockage, transmis-

Figure 1.3 Typologie des processus

1.4 Processus, procédure et procédé

1.5 Processus métier

1.6 La gestion des processus métier (BPM)

1.7 Cycle de vie d’un processus métier

Pilotage BPM Implémentation

Figure 1.5 Cycle de vie du BPM

1.7.1 Phase de modélisation

1.7.2 Phase d’implémentation

1.7.3 Phase d’exécution

1.7.4 Phase d’analyse et d’optimisation

1.8 Technologies de processus métier

1.8.1 Processus et workflow

1.8.2 Services web

UDDI Couche découverte

Web services & WSDL Couche service

XML Couche information

SOAP Couche packaging

HTTP/ HTTPS, SMTP, FTP Couche Protocol

Figure 1.6 Pile de protocoles de services web

Les principales caractéristiques d'un service web sont :

1.8.3 Le moteur du BPM

1.9 La modélisation des processus métier

1.9.1 Les langages de modélisation des processus métier

Figure 1.8 Él e ts de ase d u BPMN

 Les partitions "Swimlanes": ce sont les éléments graphiques permettant de

Donnée Flux de séquences Événements Flux de messages

1.9.1.2 Le diagramme d’activités UML

Nœud d’o jet Nœud d’a tio

La figure 1.11 ep se te u e e ple de diag a e d’a ti it illust a t l’utilisatio de

Nœud i itial Nœud de ifur atio

Figure 1.11 Processus de commande od lis pa le diag a e d a tivit s