Une Approche de transformation de la notation BPMN vers BPEL
Transcript of Une Approche de transformation de la notation BPMN vers BPEL
République Algérienne Démocratique et Populaire
Ministère de l’Enseignement Supérieur et de La Recherche Scientifique
Université Mentouri Constantine
Faculté Des Sciences De L’ingénieur
Département d’Informatique
N°358/MAG/2009
Série : 015/INF/2009
Mémoire de Magister en Informatique
Option : Génie logiciel
Dans le cadre de l‟école doctorale de l‟est
Titre du mémoire :
Une Approche de transformation de la
notation BPMN vers BPEL basée sur la
transformation de graphe
Présenté par :
Kholladi Mohamed Naoufel
Devant le jury :
Président : Pr Benmohammed Mohamed
Rapporteur : Dr Chaoui Alloua
Examinateur : Dr Chikhi Salim
Examinateur : Dr Saïdouni Djamel Eddine
I
Remerciements
D‟abord, je rends grâce à Dieu de m‟avoir donné la chance de faire un Magister et surtout de m‟aider à m‟en sortir.
J‟adresse toute ma reconnaissance au Dr Chaoui Alloua qui a dirigé ce
travail. Je le remercie pour sa patience et sa compréhension durant ces années de Magister. Je le remercie infiniment pour son apport scientifique incontestable,
mais aussi pour toutes ses qualités humaines, sa compréhension, sa tolérance, sa patience et son aide. Mes remerciements vont aussi à Mr Kerkouche El Hilali
pour sa coopération et son esprit d‟équipe.
Je tiens à remercier les membres du jury d‟avoir fait l‟honneur d‟accepter de participer au jury et de juger ce travail.
Je tiens à remercier tous mes collègues et amis qui m‟ont soutenue durant
ces deux années pour leur soutien moral et surtout ma famille (mes parents, mes
sœurs, mon frère et tous les autres membres de la famille : surtout les grands parents) pour tout ce qu‟ils ont fait et ce qu‟ils font encore pour moi.
II
Abstract
Present methods for enterprise systems analysis rely on the
representation of work practices in the form of business process
models. A standard for representing such models is the Business
Process Modeling Notation (BPMN). BPMN models are mainly
intended for communication and decision-making between domain
analysts, but often they are also given as input to software
development projects. Meanwhile, development methods for process-
oriented systems rely on detailed process definitions that are executed
by process engines. These process definitions refine BPMN models by
adding implementation details. A major standard for process
implementation is the Web Service Business Process Execution
Language (WS-BPEL, or BPEL for short). Accordingly, a natural
method for end-to-end development of process-oriented systems is to
translate BPMN models to BPEL definitions. However, instrumenting
this method is challenging because BPEL imposes far more syntactic
restrictions than BPMN. In our work we propose automatic technique
based on graph transformation to translate BPMN specification to
BPEL code.
Keywords : BPMN, BPEL, Graph transformation.
III
Résumé
Les méthodes actuelles pour l‟analyse des systèmes d‟entreprise, se
basent sur la représentation des travaux pratiques sous forme de
modèles de processus d‟entreprise. Un standard pour représenter de
tels modèles est la BPMN. Ce dernier est destiné à mettre en
collaboration les analystes du domaine. De ce fait, il est considéré
comme une entrée pour les projets de développement de logiciel. En
même temps, les méthodes pour les systèmes orientés processus
comptent sur les définitions détaillées des processus qui sont exécutés
par des moteurs de processus. Ces définitions de processus raffinent
les modèles BPMN par le rajout des détails d‟implémentation. Le
standard pour l‟implémentation des processus est le BPEL (WS-
BPEL ou BPEL pour faire court). Par conséquent, la méthode
naturelle pour un développement bout à bout des systèmes orientés
processus est de convertir les modèles BPMN vers les définitions
BPEL pour des raffinements ultérieur. Toutefois, l‟instrumentation de
cette méthode est un challenge parce que le BPEL impose beaucoup
plus de restrictions syntaxiques que la BPMN. Dans notre travail nous
proposons une technique automatique basée sur la transformation de
graphes pour transformer les spécifications du BPMN vers du code
BPEL.
Mots clés : BPMN, BPEL, Transformation de Graphe.
IV
ملخص
انطشق انحانت نخحهم أوظمت انمؤسساث حعخمذ عهى عشض
ىان حشمز مخعاسف عه . الأعمال انخطبمت عهى شكم ومارج
عمم زا . BPMNعمم عهى عشض زي انىمارج عشف بـ
انخشمز عهى حشدع انماصلاث به انمحههه عذ كىمطت بذات
ف وفس انلج، نلأوظمت انخ . بانىسبت نمشاسع حطش انبشامح
حعمم بشكم حطسي طشق حعخمذ عهى حعشفاث مفصهت نلأطاس
زي انخعشفاث حذلك ومارج انـ . انخ مو محشن الأطاس بخشغها
BPMNانخشمز . عبش إضافت اندزئاث انخاصت بانخشغم
حخى مكه )انمخعاسف عه انزي عمم عهى حأث الأطاس
ىخح عما سبك أن انطشمت انبذت . BPELعشف بـ (حشغها
إنى (انىمرج)نخطش أوظمت حعمم بشكم حطسي زا مه انبذات
إنى BPMNحخمثم ف حشخمت ومارج انـ (انخشغم)انىات
نكه إعذاد سهت حمو بزي انعمهت صعب . BPELحعشفاث انـ
فشض لاعذ وحت كثشة بانمماسوت مع BPELلأن انـ
ف عمهىا زا، ومخشذ حمىت آنت حعخمذ عهى طشمت . BPMNانـ
. BPELإنى مثها ف انـBPMN ححم انىمارج نخشخمت ومارج
.، طشمت ححم انىمارجBPMN، BPEL : الكلمات الرئيسية
V
Table des matières
pages Introduction générale 1
1. Processus d’entreprise BPMN 3 1.1 Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Diagramme BPMN (BPD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2.1 Objets de flux. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2.1.1 Evènements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.1.2 Activités. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.2.1.3 Portes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.2.2 Groupements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 1.2.2.1 Groupement graphique. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 1.2.2.2 Sous- groupement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.2.3 Objets symboliques. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 1.2.3.1 Objet de données. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.2.3.2 Groupe. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 1.2.3.3 Annotation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 1.2.4 Objets de relation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.2.4.1 Flux de séquences. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 1.2.4.2 Flux de messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.2.4.3 Associations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 1.3 Illustration par un exemple. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 1.3.1 Diagramme BPMN de l‟exemple. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.3.2 Interprétation du diagramme. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 1.4 Conclusion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2. Langage d’exécution BPEL 20 2.1 Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.2 Structure des processus BPEL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.3 Relation entre BPEL et ses partenaires. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.4 Etat d‟un processus BPEL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.5 Comportement d‟un processus BPEL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 2.5.1 Fournir et consommer des services web. . . . . . . . . . . . . . . . . . . . . . . . . . 24 2.5.2 Structuration de la logique des processus. . . . . . . . . . . . . . . . . . . . . . . . . 26
2.5.3 Activités répétitives. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 2.5.4 Traitement parallèle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.5.5 Manipulation des données. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 2.5.6 Traitement des exceptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 2.6 Raffinement de la structure d‟un processus. . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.6.1 Cycle de vie d‟un scope. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 2.6.2 Gestion d‟erreur d‟un scope. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.6.3 Terminaison d‟un travail en court d‟exécution. . . . . . . . . . . . . . . . . . . . . 37 2.6.4 Annulation d‟un travail terminé. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 2.6.5 Gestion d‟événements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.7 Conclusion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 3. Transformations des modèles à l’aide de transformation de graphes 40
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
VI
3.2. Architecture dirigée par les modèles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.2.1 Notion de modèle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 3.2.2. La transformation des modèles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.2.3. Méta-modélisation et transformation. . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 3.2.4 Classification des approches de transformation. . . . . . . . . . . . . . . . . . . . . 46 3.2.4.1 Transformations de type Modèle vers code. . . . . . . . . . . . . . . . . . . 46
3.2.4.2 Transformations de type modèle vers modèle . . . . . . . . . . . . . . . . . 46 3.3 Les transformations de graphes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.3.1. Grammaires de graphes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 3.3.2 Le principe des règles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . 49 3.3.3 Application des règles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.3.4 Système de transformation de graphes . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 3.3.5 Outils de transformation de graphes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 4. Une approche automatique de transformation d’un diagramme BPMN vers
un code BPEL
52
4.1 Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 4.2 Diagramme BPMN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.3 Code BPEL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 54 4.4 Ecriture du code BPEL à partir un diagramme BPMN. . . . . . . . . . . . . . . . . . . . 55 4.5 Transformation d‟un diagramme BPMN vers un code BPEL. . . . . . . . . . . . . . 55
4.5.1 Méta-modélisation du diagramme BPMN . . . . . . . . . . . . . . . . . . . . . . . . . 55 4.5.2 Génération de l‟environnement BPMN. . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.5.3 Grammaire de graphe pour la transformation d‟un diagramme BPMN vers un code BPEL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
57
4.5.4 Exemple. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.5.4.1 Exemple 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 4.5.4.1 Exemple 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
4.6 Conclusion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 Conclusion et perspectives 77 Références bibliographiques 78
VII
Liste des figures Pages
Figure 1.1. Attributs d‟un BPD 05
Figure 1.2. Attributs communs à tous les composants d‟un BPD…………………………………….. 05
Figure 1.3. Attributs partagés par la catégorie objet de flux………………………………………….. 06
Figure 1.4. (a) Début (b) Intermédiaire (c) Fin…………………………………………………….. 06
Figure 1.5. Attributs des événements…………………………………………………………………. 07
Figure 1.6. Aperçu sur les causes du déclenchement et du résultat…………………………………… 08
Figure 1.7. (a) Sous-Processus (b) Tâche …………………………………………………………... 09
Figure 1.8. (a) Boucle (b) Instance Multiple (c) Exécution libre (AdHoc) (d) Compensation …. 09
Figure 1.9. Attributs communs aux activités …………………………………………………………. 10
Figure 1.10. les portes………………………………………………………………………………….. 11
Figure 1.11. Attributs communs aux gateways………………………………………………………… 11
Figure 1.12. Un pool contenant deux lanes ……………………………………………………………. 12
Figure 1.13. Objet de données ………………………………………………………………………….. 13
Figure 1.14. Groupe……………………………………………………………………………………. 13
Figure 1.15. Annotation ………………………………………………………………………………… 14
Figure 1.16. Attributs communs aux Objets de relation ………………………………………………... 14
Figure 1.17. (a) Flux de séquence de base (b) Flux de séquence conditionné (c)Flux de séquence par défaut 14
Figure 1.18. Flux de messages …………………………………………………………………………. 15
Figure 1.19. (a) Association non orienté (b) Association orienté …………………………………….. 15
Figure 1.20. Processus de vote par Email ………………………………………………………………. 16
Figure 1.21. Détaille du cycle de discussion …………………………………………………………… 17
Figure 1.22. Détaille du sous-processus: période de vote ……………………………………………… 19
Figure 2.1. Processus BPEL…………………………………………………………………………… 22
Figure 2.2. Interaction entre un processus et son partenaire ………………………………………… 23
Figure 2.3. Variables BPEL ………………………………………………………………………… 24
Figure 2.4. Activité « receive » ………………………………………………………………………. 25
Figure 2.5. Activité « reply » ……………………………………………………………………… 25
Figure 2.6. Activité « invoke » ……………………………………………………………………… 25
Figure 2.7. Activité « invoke » pour une opération WSDL requète-réponse………………………… 26
Figure 2.8. Activité « sequence » …………………………………………………………………… 26
Figure 2.9. Activité « if-else » ……………………………………………………………………… 27
Figure 2.10. Activité « while » ……………………………………………………………………… 27
Figure 2.11. Activité « repeatUntil » …………………………………………………………………… 27
Figure 2.12. Activité « forEach » ……………………………………………………………………… 28
Figure 2.13. Activité « flow » ……………………………………………………………………… 28
Figure 2.14. Activité « flow » avec « link » …………………………………………………………… 29
VIII
Figure 2.15. Activité « flow » avec « link » et « transitionCondition » …………………………… 30
Figure 2.16. Activité « flow » avec « link », « transitionCondition » et «joinCondition »…………… 31
Figure 2.17. Activité « assign » ……………………………………………………………………… 33
Figure 2.18. Activité « assign » avec les attributs du langage de requête………………………… 33
Figure 2.19. Gestionnaire d‟erreur dans un processus……………………………………………… 34
Figure 2.20. Gestion d‟erreur d‟un scope……………………………………………………………… 37
Figure 2.21. Gestion des terminaisons………………………………………………………………… 37
Figure 2.22. Gestion d‟une compensation………………………………………………………………. 38
Figure 3.1.. Aperçu globale du processus de transformations de modèles de l‟approche MDA…….. 43
Tableau 3.1. Niveaux d‟abstraction de la méta-modélisation 44
Figure 3.2: Niveaux d‟abstraction de la méta-modélisation. ………………………………………….. 45
Figure 3.3: (a) Modèle AFD des nombre b inaires pairs (b) Méta-modèle : Formalisme AFD
(Diagramme de classe UML + OCL) …………………………………………………….
48
Figure 4.1: Un exemple BPMN……………………………………………………………………….. 54
Figure 4.2 : Un code BPEL représentant le diagramme BPMN de la Figure 4.1……………………… 54
Figure 4.3 : Meta-Model d‟un BPMN………………………………………………………………….. 56
Figure 4.4 : Environnement BPMN sous ATOM3……………………………………………………... 56
Figure 4.5 : (a) LHS de la règle 1 (b) code généré par la règle 1………………………………………. 57
Figure 4.6 : (a) LHS de la règle 2 (b) Code généré par la règle 2……………………………………… 58
Figure 4.7 : (a) LHS de la règle 3 (b) Code généré par la règle 3……………………………………… 59
Figure 4.8 : (a) LHS de la règle 4 (b) Code généré par la règle 4……………………………………… 60
Figure 4.9 : (a) LHS de la règle 5 (b) Code généré par la règle 5……………………………………… 60
Figure 4.10 : (a) LHS de la règle 6 (b) Code généré par la règle 6……………………………………… 61
Figure 4.11 : (a) LHS de la règle 7 (b) Code généré par la règle 7……………………………………… 61
Figure 4.12 : (a) LHS de la règle 8 (b) Code généré par la règle 8…………………………………… 62
Figure 4.13 : (a) LHS de la règle 9 (b) Code généré par la règ le 9…………………………………… 62
Figure 4.14 : LHS de la règle 10………………………………………………………………………… 63
Figure 4.15 : LHS de la règle 11……………………………………………………………………… 63
Figure 4.16 : LHS de la règle 12……………………………………………………………………… 64
Figure 4.17 : LHS de la règle 13……………………………………………………………………… 64
Figure 4.18 : LHS de la règle 14……………………………………………………………………… 64
Figure 4.19 : LHS de la règle 15……………………………………………………………………… 64
Figure 4.20 : LHS de la règle 16……………………………………………………………………… 65
Figure 4.21 : LHS de la règle 17……………………………………………………………………… 65
Figure 4.22 : (a) LHS de la règle 18 (b) Code généré par la règ le 18…………………………………… 65
Figure 4.23 : (a) LHS de la règle 19 (b) Code généré par la règ le 19…………………………………… 66
Figure 4.24 : (a) LHS de la règle 20 (b) Code généré par la règ le 20…………………………………… 67
Figure 4.25 : (a) LHS de la règle 21 (b) Code généré par la règle 21………………………………… 67
Figure 4.26 : (a) LHS de la règle 22 (b) Code généré par la règle 22………………………………… 68
Figure 4.27 : (a) LHS de la règle 23 (b) Code généré par la règle 23………………………………… 68
IX
Figure 4.28 : (a) LHS de la règle 24 (b) Code généré par la règle 24………………………………… 69
Figure 4.29 : BPD du processus " complaint-handling " ……………………………………………… 69
Figure 4.30 : BPD du processus " plusieurs-scopes "………………………………………………… 70
Figure 4.31 : Processus BPEL………………………………………………………………………….. 72
Figure 4.32 : Code BPEL du processus "Plusieurs-scopes"…………………………………………… 72
Figure 4.33. Code BPEL du processus « Plusieurs composantes »……………………………………. 76
Introduction Générale 1
Introduction générale
Le besoin d‟adaptation rapide des entreprises à de nouveaux contextes du marché
offrant aux clients de meilleurs services plus complets dans les plus courts délais, a créé des
demandes d‟établir des méthodologies de modélisation pour organiser et coordonner leurs
actions, ou plus exactement leur processus d‟entreprise qui est par définition, le processus de
mise en œuvre au sein d‟une organisation et dont les sorties répondent aux besoins d‟un client
interne ou externe à cette organisation.
Un processus d‟entreprise consiste en une succession d‟étapes. Une personne ou
plusieurs, éventuellement dans différents départements, se confient l‟une l‟autre des tâches et
des données jusqu‟à ce que la mission soit remplie. Un processus d‟entreprise a un début et
une fin. Certaines actions sont parfois répétées, la voie se sépare parfois en deux routes
différentes. Quelle est la meilleure façon de schématiser tout cela? .Aujourd‟hui, il existe de
multiple façons pour modéliser un processus d‟entreprise. Chacune avec son propre
vocabulaire (les éléments graphiques ou les primitives d‟un langage de bas niveau) et sa
propre grammaire (la sémantique de l‟assemblage). Il devient alors difficile pour les non
initiés de travailler avec des modèles dans des langages différents. C‟est pourquoi une norme
pour la représentation des processus d‟entreprise est fortement recommander tant au niveau
schématique qu‟au niveau exécution.
D‟un coté, La BPMI (Business Process Management Initiative) a créé un groupe de
travail international chargé de se pencher sur la question. Les participants ont notamment
étudié la technique de „flowcharting‟, une technique de dessin que les programmateurs
utilisent déjà depuis trente ans pour illustrer le fonctionnement d‟un programme. Ils se sont
aussi tournés vers l‟UML, l‟Unified Modeling Language, une technique moderne servant à
illustrer le fonctionnement d‟un programme orienté objet. Ils ont passé en revue une foule de
techniques, discuté pendant deux ans et la notation BPMN (business process modeling
notation) a vu le jour en mai 2004.
De l‟autre, L‟organisme OASIS a établit un standard BPEL (business process
exécution language) chargé de coordonner les services des entreprises dans un contexte web.
Par conséquent, la méthode naturelle pour un développement bout à bout des systèmes
orienté processus est de convertir les modèles BPMN vers les définitions BPEL. Toutefois,
l‟instrumentation de cette méthode est un challenge parce que BPEL impose beaucoup plus de
restrictions syntaxiques que BPMN.
Introduction Générale 2
Dans notre travail, nous proposons une technique automatique basée sur la
transformation de graphes. Nous substituons à un élément atomique du graphe portant une
étiquette spécifiée une nouvelle structure sous forme d‟un code textuel. Bien entendu, la
nature complexe des graphes exige beaucoup d‟informations pour réaliser cette substitution ;
en particulier, il faut indiquer de quelle manière le code obtenu va se rattacher au graphe
d‟origine. Nous proposons une transformation dans laque lle les éléments atomiques
considérés ne se limitent pas aux nœuds ou aux arcs, mais elle comprend les deux. Nous
avons opté pour une approche entièrement automatique basée sur la méta-modélisation et les
grammaires de graphes pour générer un code BPEL à partir d‟un schéma BPMN.
L‟objectif du premier et deuxième chapitre de ce mémoire est de présenter le
vocabulaire et la grammaire des deux langages BPMN et BPEL.
Le troisième chapitre sera dédié à la transformation de modèles à l‟aide de
transformation de graphe.
Le quatrième chapitre quand à lui, présentera notre contribution qui consiste en une
approche automatique de transformation des spécifications BPMN vers du code BPEL.
Et nous terminerons ce mémoire par une conclusion et des perspectives.
Chapitre 1. Processus d’entreprise BPMN 3
Chapitre 1
Processus d’entreprise BPMN
Chapitre 1. Processus d’entreprise BPMN 4
Chapitre 1
Processus d’entreprise BPMN
1.1 Introduction
Un processus d‟entreprise est considéré comme une suite d‟étapes. Une ou plusieurs
personnes se partagent des tâches en vue d‟atteindre un certain objectif. De nos jours,
beaucoup de sociétés esquissent des représentations graphiques pour leur processus
d‟entreprise grâce a des techniques de dessin que les programmateurs ont presque toujours
utilisé pour illustrer le fonctionnement de leurs programmes. Etant des diagrammes de flux et
plus connus sous le nom „flowcharts‟, leur simplicité à représenter des processus à petite ou
grande échelle, les rend une source d‟inspiration pour tout individu souhaitant mettre de
l‟ordre dans ses projets. Ce qui a impliqué la circulation de plusieurs variantes, chacune avec
son degré d‟expressivité et de complexité. Le dessin devient alors rapidement complexe,
illisible et ambigüe, d‟où la nécessité d‟établir une norme facilement compréhensible par tous
les acteurs impliqués dans l‟utilisation d‟un processus (depuis les analystes métier chargés
d‟industrialiser le processus jusqu'aux développeurs qui exécuteront ce dernier ).
Après six années et plus de 140 réunions, physiques et virtuelles, la BPMN (Business
Process Modeling Notation), une nouvelle norme, fait son apparition en proposant un
ensemble d‟éléments graphiques normalisés et une grammaire permettant leur manipulation.
La BPMN doit à la fois être simple et capable de gérer les complexités inhérentes au
processus métier, elle doit aussi être facilement traduite en langage exécutable tel que BPEL
(Business Process Execution Language) sur un moteur de Workflow.
Le but de ce chapitre est d‟introduire les objets graphiques de la BPMN (BPD Business
Process Diagrams), en se basant sur le document de travail de l‟OMG (Object Management
Group) : « Business Process Modeling Notation » du 03 janvier 2009 [OMG09], Avec une
manière souple allant des objets les plus simples (les plus utilisés aussi) aux objets plus
complexes. En fin de chapitre, nous mettrons en œuvre la BPMN au travers d‟un exemple.
1.2 Diagramme BPMN (BPD)
Un BPD représente les différentes étapes du processus et leur succession à l‟aide d‟un
ensemble de nœuds (Objets de flux) connectés par un ensemble d‟arcs (Objets de relation) et
regroupés dans des Groupements selon leur appartenance à un tel ou tel participant.
Chapitre 1. Processus d’entreprise BPMN 5
L‟ensemble du diagramme dispose d‟attributs qui l‟enrichissent avec des informations
complémentaires comme sur la figure 1.1 :
ID :
Name :
Version :
Author :
Language :
QueryLanguage :
CreationDate :
ModificationDate :
Pools :
Documentation :
identifiant (unique) du diagramme.
texte descriptif du diagramme.
numéro de version.
auteur du diagramme.
langue de la partie texte.
langage de requête.
date de création.
date de modification.
les groupements du diagramme.
documentation supplémentaire.
Figure 1.1. Attributs d‟un BPD
Le diagramme réunit également un ensemble d‟attributs communs à tous ses
composants (voir la figure 1.2) :
Id :
Categories :
Documentation :
identifiant caractérisant un composant.
catégories auxquelles appartient le composant.
documentation textuelle du composant
Figure 1.2. Attributs communs à tous les composants d‟un BPD
Nous présentons dans ce qui suit les composants d‟un diagramme BPMN qui font partie
des trois catégories que nous venons de citer et aussi, une quatrième catégorie qui apporte des
informations supplémentaires au diagramme.
1.2.1 Objets de flux
Ce sont les objets élémentaires composant le flux d‟un processus. Ces objets
(Evènements, Activités et Portes) partagent les attributs suivants (en plus des attributs
communs aux composants d‟un BPD) (voir la figure 1.3) :
Chapitre 1. Processus d’entreprise BPMN 6
Name :
Assignments :
identifiant caractérisant un objet.
expressions d‟affectation.
Figure 1.3. Attributs partagés par la catégorie objet de flux
1.2.1.1 Evènements
Avec une apparence en forme de cercle, les événements, selon les propriétés qui leurs
sont assignées, réagissent à la survenu de situations particulaires pour affecter le flux du
processus. Leurs réactions peuvent être séparées en deux catégories : Déclenchement
(Trigger) et Résultat (Result).
Les événements peuvent être de trois types différents : Début (Start), intermédiaire
(Intermediate), fin (End). L‟événement Début est représenté par un cercle fin, il indique le
point de départ. L‟événement intermédiaire est représenté par un double cercle et peut être
utilisé de deux façons : au milieu d‟un flux ou rattaché à une tache. Et celui de fin est
représenté par un cercle épais et marque la fin d ‟un processus (voir la figure 1.4).
(a) (b) (c)
Figure 1.4. (a) Début (b) Intermédiaire (c) Fin
Les événements sont soumis à des règles d‟utilisation. Les règles les plus importantes à
respecter dans un diagramme BPMN sont :
Le diagramme peut contenir de « 0 » à « n » événements Début et événements Fin.
S‟il contient au moins un événement Début, il doit contenir au moins un événement
Fin.
S‟il contient au moins un événement Fin, il doit contenir au moins un événement
Début.
S‟il ne contient pas d‟événements Début, alors, les objets de flux ne possédants pas
d‟arcs entrants constituent le début du processus et doivent démarrer en parallèle.
Chapitre 1. Processus d’entreprise BPMN 7
S‟il ne contient pas d‟événements Fin, alors, les objets de flux ne possédants pas d‟arcs
sortants constituent la fin du processus. Ce dernier s‟achèvera une fois tous ses sommets
sont atteints.
La figure 1.5 montre les attributs communs aux événements et ceux qui sont spécifiques
aux types Début, Intermédiaire et Fin (ces attributs s‟ajoutent à ceux partagés par la catégorie
objet de flux).
EventType : (attribut commun)
Trigger : (attribut du Début)
Trigger : (attribut d‟Intermédiaire)
Result : (attribut de Fin)
type d‟événement (Début, Intermédia ire ou Fin).
déclencheur (Message, Time, etc.)(voir Figure 1.6).
déclencheur (Message, Time, etc.)(voir Figure 1.6).
résultat (Message, Erreur, etc.)(voir Figure 1.6).
Figure 1.5. Attributs des événements
Les catégories déclenchement et résultat peuvent être affectées pas 10 causes distincts,
chacune se concrétise par une icône placée à l‟intérieur du pattern de l‟événement, la figure
1.6 donne un aperçus sur chaque cause :
Cause Déclenchement résultat
symboles
Attente Lancement
Début Intermédiaire Fin
AUCUN Aucune indication sur le type (qui
existe) n‟est affichée.
MESSAGE
Message reçus de la part d‟un
participant
Envoie de message à l‟un
des participants
TIMER
Un moment est
déterminé (date, heure, etc.)
ERREUR
Une erreur s‟est produite dans
l‟activité (avec
laquelle il doit être
Envoie d‟un
rapport d‟erreur
à un événement
Chapitre 1. Processus d’entreprise BPMN 8
attaché)
intermédiaire
ANNULATION
Une annulation au niveau de l‟activité
(de type
transaction) (avec laquelle il doit être
attaché)
Annulation
d‟une activité de type transaction
COMPENSATION
Une compensation
nécessaire de l‟activité (avec
laquelle il doit être attaché)
Demande de compensation
CONDITIONNEL
Une condition doit être vérifié (ex :
Age > 5 ans).
LIEN
Destination d‟un
lien source Lien source
SIGNAL
Recevoir un signal
émit d‟un participant
Signal émit
FIN
Arrêt immédiat de toutes les activités
du processus
MULTIPLE
Plusieurs causes
sont possible (une seule cause suffi)
Plusieurs résultats sont
attendus (ex : deux messages
envoyés)
Figure 1.6. Aperçu sur les causes du déclenchement et du résultat
1.2.1.2 Activités
Dans le but d‟atteindre l‟objective pour lequel le processus d‟entreprise est lancé, des
activités sont effectuées par des humains ou des applications logicielles. Un BPD renseigne à
la fois des activités manuelles et des activités automatisées.
Chapitre 1. Processus d’entreprise BPMN 9
Les activités peuvent être des processus (Process), des sous-processus (Sub-Process) ou
des tâches (Task). Ce dernier type est atomique et ne renferme pas de détail interne (d‟autres
tâches) contrairement aux deux premiers qui définissent des abstractions et permettent le
choix de la granularité de l‟information à représenter.
Les processus n‟ont pas de symbole particulier, ils représentent une partie du BPD
délimitée par un ou plusieurs Groupements. Les sous-processus et les tâches quand à eux,
prennent la forme d‟un rectangle aux coins arrondis. Dans ce qui suit le rectangle avec un
signe « + » en bas centre est un sous-processus masquant son détaille interne. Un double clic
sur l‟activité permet de réafficher les détails internes (voir la figure 1.7).
(a) (b)
Figure 1.7. (a) Sous-Processus (b) Tâche
Dans une activité on retrouve jusqu‟à 5 symboles indiquant son comportement : le
symbole du sous-processus que nous venons de voir (celui avec le signe « + »), le symbole de
Boucle (Loop), le symbole d‟Instance Multiple (Multipe-Instance) qui affirme la possibilité
d‟exécuté l‟activité plusieurs fois en parallèle, le symbole d‟exécution libre (AdHoc )
permettant une exécution avec un ordre aléatoire et le symbole de compensation qui se traduit
par l‟exécution de son activité (reliée à un événement de compensation) en cas d‟interruption
du sous-processus auquel l‟événement de compensation est rattaché (voir la figure 1.8).
(a) (b) (c) (d)
Figure 1.8. (a) Boucle (b) Instance Multiple (c) Exécutions libre (Ad Hoc) (d)
Compensation
Chapitre 1. Processus d’entreprise BPMN 10
Il est possible de combiner les symboles dans une même activité si les règles suivantes
sont respectées :
Une activité peut contenir de 0 à 3 symboles.
Une activité ne peut pas contenir conjointement les symboles Boucle et Instance Multiple.
Une tâche ne peut comporter le symbole Ad Hoc.
Les activités comportent beaucoup d‟attributs car concrètement, ils représentent l‟intérêt
principal d‟une modélisation en BPMN et schématiquement le processus, le sous processus et
la tâche ont des vues et des symboles multiples. Les attributs communs aux activités sont
comme sur la figur 1.9 :
ActivityType :
Status :
Performers :
Properties :
InputSets :
OutputSets :
IORules :
StartQuantity :
CompletionQuantity :
LoopType :
type de l‟activité (tâche, sous-processus).
état de l‟activité par rapport à l‟ensemble du diagramme.
participants.
les propriétés de l‟activité (locales).
conditions d‟entrée.
conditions de sortie.
lien entre conditions d‟entrée et conditions de sortie.
nombre de flux nécessaire pour commencer l‟activité.
nombre de flux devants être générés depuis l‟activité.
Type de boucle (Boucle, Instance Multiple).
Figure 1.9. Attributs communs aux activités
1.2.1.3 portes
Le flux circulant dans un processus rencontre souvent des carrefours à deux ou
plusieurs voies possibles. Suivant leur nature, les carrefours convergent et divergent les flux
qu‟ils rencontrent selon une stratégie prédéfinie. En BPMN c‟est le mécanisme de portes
(Gateway) qui assure cette fonctionnalité.
Les portes sont représentées par un losange à l‟intérieur duquel, des symboles
s‟intègrent à volonté (à l‟instar des évènements et des activités), pour illustrer son
comportement. Cinq sortes de portes existent (voir la figure 1.10) :
Chapitre 1. Processus d’entreprise BPMN 11
Portes Description présentation « O
u E
xcl
usi
ve
» (
XO
R)
basé données
(Data-Based)
Une seule option est choisie en fonction de la
condition liée aux arcs sortants. Une option supplémentaire pour garantir le passage du flux (option par défaut) peut être ajoutée. S‟il existe
plusieurs arcs entrants alors le gateway fait passer les flux (un par un) sans condition
particulière.
ou
basé
évènements
(Event-Based)
Une seule option est choisie en fonction du changement d‟état des objets (évènement Début, évènement End ou activité de type
‘Réception’ (receive)) qui se trouvent à l‟arriver des arcs sortants. S‟il existe plusieurs
arcs entrants alors le gateway se comporte comme le précédant.
« Ou inclusif »
(OR)
Contrairement au XOR, le « ou inclusive » n‟exclut pas la possibilité d‟emprunté plus d‟un
chemin. Une option par défaut est utile pour garantir le passage du flux.
« Parallèle »
(Parallel)
Toutes les options sont choisies à l‟arriver du flux.
« Complexe »
(Complex)
Si les gateways précédents ne suffisent pas, le
modeleur peut avoir recours à ce dernier.
Figure 1.10. les portes
Les attributs communs des Gateways sont (voir la figure 1.11) :
GatewayType :
Gates :
Détermine le comportement du Gateway (Exclusive, Inclusive…)
Les sorties du gateway.
Figure 1.11. Attributs communs aux gateways
1.2.2 Groupements
Les groupements illustrent un mécanisme d‟organisation des activités dans différentes
catégories pour mettre en valeur des fonctionnalités ou des responsabilités particulières. Ainsi,
les groupements caractérisent les interactions entre processus en mettant en œuvre le contexte
collaboratif (B2B) (Business to Business). Ils sont de deux types : Groupement (Pool), sous
Chapitre 1. Processus d’entreprise BPMN 12
groupement (Lane). Les attributs communs aux groupements se limitent à un seul : l‟attribut
Name (nom). C‟est l‟intitulé du groupement.
1.2.2.1 Groupement graphique
Plus connu sous le nom « pool », le groupement graphique isole son contenu du reste du
diagramme et coopère avec les entités externes par envoi et réception de messages. Il présente
deux options : usage en tant que « boite noire » (aucun détail sur son contenu n‟est affiché) et
usage en tant que « boite blanche » (affichage des détails internes).
1.2.2.2 Sous- groupement
Les sous-groupements (Lanes) ont pour but d‟organiser le contenu des groupements
(pools) pour mettre l‟accent sur les sous-ensembles qui présentent un intérêt particulier. Un
Lane peut contenir un autre, en parle alors d‟une hiérarchisation de contenance. Dans la figure
1.12, les départements 1 et 2 présentent les deux sous-groupements du groupement
« entreprise » dans un processus achat :
Figure 1.12: Un pool contenant deux lanes
1.2.3 Objets symboliques
Pour obtenir un diagramme suffisamment explicite, les objets symboliques (Artifacts)
sont introduits pour apporter des informations supplémentaires au modèle. De plus, ces objets
se différencient des autres objets par le fait qu‟ils n‟affectent en rien le déroulement du
processus. L‟attribut « ArtifactType » (représentant le type de l‟objet symbolique) est
commun à tous les objets de cette catégorie. La norme propose trois valeurs pour cet attribut :
Objets de données, Groupe et Annotation. En outre, le rajout d‟autres valeurs est possible et
permet au modeleur de choisir d‟autres formes s‟il trouve qu‟elles sont plus expressives ou
Chapitre 1. Processus d’entreprise BPMN 13
correspondent aux attentes de ses clients. Dans ce qui suit nous présentons les Trois types de
base :
1.2.3.1 Objet de données
Son utilisation fréquente dans les documents de gestion orientés workflow et aussi dans
d‟autre méthodologies de modélisation, fait de cet objet de données un élément
incontournable dans la liste des objets symboliques. Cet élément présente des informations (le
contenu, l‟état ? etc.) sur les documents, les données et d‟autres objets durant l‟exécution du
processus (voir la figure 1.13).
Figure 1.13. Objet de données
1.2.3.2 Groupe
Le modeleur peut informellement réunir en groupes les éléments qui vont de pair dans
son diagramme. Le groupe est représenté comme suit (voir la figure 1.14) :
Figure 1.14. Groupe
1.2.3.3 Annotation
Les annotations ajoutent des informations textuelles au diagramme pour lever les
ambigüités qui peuvent y survenir. Le texte de l‟annotation est présenté à l‟intérieur d‟un
croché dans ce qui suit (nous verrons la signification du très en pointillés dans la prochaine
section) (voir la figure 1.15) :
Chapitre 1. Processus d’entreprise BPMN 14
Figure 1.15. Annotation
1.2.4 Objets de relation
Les objets de relation font la liaison entre les objets du diagramme. La catégorie Flux de
séquences relie une activité à une autre, une activité à un événement ou une activité à une
condition de branchement (Gateway).
La catégorie Flux de messages quand à elle représente l‟envoie de messages d‟une
entité à une autre et enfin, la catégorie Associations joint les Objets symboliques (artefacts)
aux objets de modélisation.
Les attributs appartenant à tous les éléments de la catégorie Objets de relation sont (voir
la figure 1.16) :
Name :
Source Ref :
TargetRef :
intitulé de l‟objet.
identification de l‟objet source.
identification de l‟objet destination.
Figure 1.16. Attributs communs aux Objets de relation
1.2.4.1 Flux de séquences
Les flux de séquences sont utilisés dans le but d‟ordonnancer l‟exécution des activités
du diagramme. Ils représentent les interconnexions au sein d‟un même Groupement et ne
peuvent pas aller au-delà de ses frontières. Schématiquement, les flux de séquences ont la
forme d‟une flèche orientée généralement de gauche à droite ou de haut en bas, allant d‟une
seule source à une seule destination. Les trois formes possibles d‟un flux de séquence sont
(voir la figure 1.17) :
(a) (b) (c)
Figure 1.17. (a) Flux de séquence de base (b) Flux de séquence conditionné (c)Flux de
séquence par défaut
Chapitre 1. Processus d’entreprise BPMN 15
Le flux de séquence conditionné doit obligatoirement comporter un petit losange s‟il a
comme origine une activité. C‟est une manière, s‟ils sont deux ou plus, de distinguer le
comportement conditionné du comportement parallèle. Le flux de séquence par défaut
représente une option par défaut, il a une forme particulière pour le différencier des autres
options.
1.2.4.2 Flux de messages
Les flux de messages assurent l‟envoi de messages d‟une entité à une autre. Ils doivent
connecter un pool ou un objet se situant dans ce pool à un autre pool ou un objet se situant
dans ce dernier. Souvent, la direction qu‟ils prennent forme un angle de 90° par rapport à celle
emprunté par les flux de séquences et ce, par mesure de clarté. Il y a une seule représentation
graphique possible pour le flux de messages (voir la figure 1.18) :
Figure 1.18. Flux de messages
1.2.4.3 Associations
Les associations, comme les autres flux de leur catégorie, font la liaison entre deux
objets. Ils associent un objet symbolique à un flux ou à un objet de flux et aussi, un
évènement de compensation à une activité. Deux représentations graphiques existent (voir la
figure 1.19) :
(a) (b)
Figure 1.19. (a) Association non orienté (b) Association orienté
1.3 Illustration par un exemple
Les diagrammes de l‟exemple suivant sont une traduction de [Touzi07] des diagrammes
du document de travaille BPMN [BPMI04] qui sont toujours présents dans la version actuelle
[OMG09]. Ils présentent plusieurs aspects de la norme, des plus simples aux plus complexes
et seront expliqués en détail dans les prochaines sections :
Chapitre 1. Processus d’entreprise BPMN 16
1.3.1 Diagramme BPMN de l’exemple (voir la figure 1.20)
Figure 1.20. Processus de vote par Email
1.3.2 Interprétation du diagramme
Pour une meilleure interprétation du diagramme, les parties début du processus et fin du
processus seront détaillées. Nous verrons aussi de plus prêt Les deux sous-processus cycle de
discussion et période de vote.
Début du processus
Le processus commence avec un événement de type Timer qui lance le processus tous
les vendredis. Le gestionnaire de listes des sujets traite ces derniers et choisi ceux qui
pourront rentrer dans le cycle de discussion et de vote. La décision doit être prise (décider si
les sujets sont prêts ou non) soit pour enclencher le cycle de discussion et de vote soit pour en
arrêter là et attendre la semaine prochaine. Le sous-processus cycle de discussion possède
deux flux de séquences entrants et peut être entrepris si l‟un des deux véhicule un flux et ce,
Chapitre 1. Processus d’entreprise BPMN 17
en cas de présence de sujets à traiter ou suite à un besoin de rediscuter un sujet (qui ne
possède pas la voix de la majorité).
Fin du processus
Les résultats sont admis si le taux des votants est acceptable. Si les votants représentent
un faible taux, les sujets ne peuvent pas être résolus. Dans ce cas, une vérification concernant
l‟avertissement ou non des non-votants s‟impose. Si le membre du groupe qui ne s‟est pas
présenté au vote n‟était pas prévenu au préalable (pour le vote de la semaine en cours), alors
une annonce de vote accompagnée d‟un avertissement lui sont envoyés. Il est retiré de la liste
des votants s‟il ne participe pas à un second vote (dans les mêmes conditions) et le taux des
votants est recalculé (les sujets sont reportés pour la semaine prochaine si le taux n‟est pas
concluant).
Si le taux des votants est acceptable, le traitement des sujets proposés est vérifié afin de
déterminer l‟existence ou non d‟une voix majoritaire et concluante. Si oui, le processus se
termine, sinon le processus sera amené à ne conserver que les deux résultats les plus cotés et
relancera dans le vote ceux qui n‟avaient pas voté pour ces deux choix. Toutefois, une
difficulté à déterminer ces deux résultats est possible, dans ce cas, on doit recourir à un
nouveau cycle de vote et de discussion.
Cycle de discussion
Le détail du Sous-Processus (traduction de [Touzi07]) est le suivant comme sur la
figure 1.21) :
Figure 1.21. Détaille du cycle de discussion
Chapitre 1. Processus d’entreprise BPMN 18
Le gestionnaire de la liste de sujets envoie un Email aux membres votants afin d‟ouvrir
une discussion sur les sujets (annonce des sujets de discussion). Trois différents chemins
bifurquent en parallèle dans le sous-processus (notez l‟absence des petits losanges au début
des arcs sortants) et qui par le biais du Gateway parallèle, se joignent.
La « modération des discussions par mails » comporte un événement intermédiaire de
type Timer attaché à sa bordure. La présence des événements Début et Fin impose la sortie
d‟un second arc depuis cette activité en plus de celui du Timer en cas où la tâche ne
s‟achèvera pas convenablement. De plus, la tâche passe le flux à travers un seul de ses arcs
sortants. Par conséquent, un Gateway exclusive joint les deux arcs originaires de cette tâche
pour éviter une attente sans fin du Gateway parallèle.
L‟envoi des notifications de deadline est précédé par un Timer qui fixe un délai de 6
jours avant son entreprise. Il est à l‟origine du flux de séquence « Annonce deadline » de la
figure 1.20. Un objet de donnée (document comportant le planning du groupe) est utilisé afin
d‟établir un planning pour une conférence téléphonique. Un flux sort de cette activité après
initialisation de la réponse à la question : « conférence téléphone cette semaine ? ». Si la
réponse est affirmative, une date pour la conférence est attribuée au Timer qui précède
l‟activité : « modération de la discussion ». Dans le cas contraire le flux emprunte le flux de
séquence par défaut. Enfin, un Gateway assure la jointure des deux chemins pour les mêmes
raisons que son congénère.
La provenance d‟un flux depuis le Gateway parallèle (après réception de tous les flux
de ses chemins rentrants) provoque le démarrage de l‟activité : « évaluation de l‟évolution de
la discussion ». Une variable est initialisée suite au résultat de l‟évaluation (selon l‟évolution
est normale ou anomale) pour vérifier la condition de la boucle (modélisée par le symbole de
boucle en bas centre de l‟activité).
Période de vote
Le détail du Sous-Processus (traduction de [Touzi07]) est comme suit (voir la figure
1.22) :
Chapitre 1. Processus d’entreprise BPMN 19
Figure 1.22. Détaille du sous-processus: période de vote
Puisque ce processus présente les objets: activité, événement de type Timer et objet de
données comme son prédécesseur. En plus, il ne comporte pas de Gateway alors sa
description dans le paragraphe suivant sera brève. Si les votes peuvent commencés (selon le
gestionnaire de la liste des sujets) ou bien doivent être relancés en cas de résultat non
concluant alors le sous-processus démarre en empruntant quatre chemins afin de traiter en
parallèle: la gestion des conférences téléphoniques, la modération des échanges par mails,
l‟annonce de la deadline pour les votes et le décompte des voix.
1.4 Conclusion
BPMN est la notation standard la plus adaptée pour modéliser les processus
d‟entreprise. La plupart des outils du marché supportent la norme mais malgré cela, elle n‟est
pas largement utilisée. Ce constat est logique car dans le monde des „flowcharts’, l‟objective
de la modélisation constitue la première brique sur laquelle la grammaire d‟un processus
métier est construite. La BPMN s‟oriente plus vers la transformation d‟un processus
d‟entreprise en processus exécutable et il en résulte une grammaire qui ne répond pas aux
attentes des annalistes et modélisateurs métier. De plus, l‟absence flagrante des approches
d‟analyses telle que la gestion des risques impose la mise en œuvre des règles de validation et
ainsi complique considérablement la tâche du staff métier.
Chapitre 2. Langage d’exécution BPEL 20
Chapitre 2
Langage d’exécution BPEL
Chapitre 2. Langage d’exécution BPEL 21
Chapitre 2
Langage d’exécution BPEL
2.1 Introduction
Aujourd‟hui, les entreprises ont besoin de s‟adapter rapidement aux nouvelles
approches proposant des services meilleurs, rapides et complets. Des plates- formes
communes d‟échange et de collaboration d‟information constituent un élément clé pour
satisfaire ces besoins compte tenu leur implémentation facilitée par l‟utilisation de
l‟architecture orientée services (SOA).
Les services les plus utilisés dans ces plates- formes sont des services web. Les services
web ont gagné beaucoup d‟importance dans le développement des logiciels grâce à leur
indépendance par rapport aux langages de programmation et pa rce qu‟ils permettent d‟être
réutilisables pour fournir des services plus élaborés.
Pour réaliser une application basée sur les services web, il nous faut un plan prédéfini
permettant de décrire la coordination des services. Ce plan s‟appel l‟Orchestration.
L‟Orchestration décrit un modèle de coordination de services qui sera exécuté à l‟aide d‟un
Moteur d'Orchestration.
L‟Orchestration est représentée par un workflow (flux de travail) coordonnant des
services (et plus particulièrement des services web), ce qui offre des avantages comme
l‟optimisation et l‟automatisation de tâches. Un workflow modélise la gestion informatique de
l'ensemble des tâches à accomplir par les différents acteurs impliqués dans la réalisation d'un
processus métier. Ces acteurs peuvent être des humains réalisant les tâches demandées, ou des
services (services web, applications locales ou distantes…). Le workflow se charge de
l‟administration ou le contrôle de la coordination de ces acteurs et services.
Comme toute modélisation d‟un processus métier, l‟orchestration des services web
nécessite l‟élaboration d‟un langage. Plusieurs langages ont étaient développé dans ce but :
WSFL (Web Service Flow Language) développé par IBM et étant une extension de FL, leur
langage de modélisation de processus ; et XLANG de Microsoft qui était une extension de
WSDL [Christensen01] (web service description language), un langage qui décrit les web
Chapitre 2. Langage d’exécution BPEL 22
services. La fusion de ces deux langages a donné naissance à un standard basé sur le langage
XML. Ce langage s‟appel BPEL (business process execution language).
En 2003, la collaboration entre IBM et Microsoft a mené à la publication de la norme
BPEL4WS 1.1 [BEA03] (BPEL for Web Services) ; celle-ci a ensuite été soumise au
consortium OASIS, et ce nouveau travail a abouti en 2007 à la norme WSBPEL 2.0
[OASIS07] qui apporte quelques nouveautés. Le terme « BPEL » désigne de manière globale
ces deux langages. Dans le cadre de notre chapitre, nous présentons les concepts de base de ce
langage avec quelques exemples et ce, depuis la dernière version de la spécification de ce
langage [OASIS07].
2.2 Structure des processus BPEL
Un processus BPEL est un container dans lequel la relation avec des partenaires
externes, des déclarations pour les données du processus, des gestionnaires pour des buts
divers et plus important, des activités à exécuter, sont introduits. Le container du processus
comporte deux attributs (« name » et une déclaration de l‟espace de nom) comme le montre
l‟exemple suivant sur la figure 2.1 :
<process name="Process"
targetNamespace="http://oasis-open.org/WSBPEL"
xmlns="http://docs.oasis-open.org/wsbpel/2.0/process/executable" />
Figure 2.1. Processus BPEL
La déclaration de l‟espace de nom (http://docs.oasis-open.org/wsbpel/2.0/process/
executable) signifie que ce processus est exécutable. Un espace de nom additionnel est prévu
pour les processus abstraits. Les processus abstraits décrivent partiellement le comportement des
processus sans se préoccupé des détailles liés à l‟exécution. Ce comportement expose (de manière
typique) un modèle de processus ou un comportement externe visible du processus à l‟égard des
partenaires métiers sans montrer sa logique interne. Le processus exécutable, par contre, définit le
comportement métier complet des parties internes et externes. L‟élément « process » est le
container le plus à l‟extérieur. En effet, tout partenaire, données de processus ou gestionnaires
déclarer à l‟intérieur peut être considéré comme global. BPEL support également un mécanisme
de déclaration de toutes ces propriétés de manière local. L‟élément structurant qui assure cette
fonctionnalité est « scope ».
Chapitre 2. Langage d’exécution BPEL 23
Avec l‟aide des scopes, il est possible de diviser un processus métier chacun contenant une
portion de la logique métier globale. Par exemple, les données du processus déclarées localement
dans un scope ne sont pas visibles à l‟extérieur de ce dernier (seulement valide à l‟intérieur d„une
partie spécifique du processus).
2.3 Relation entre BPEL et ses partenaires
Les processus métiers BPEL offrent la possibilité d‟agrégation des services web et
définissent la logique métier pour chaque interaction entre services. Il s‟agit d‟une
orchestration des interactions entre services web. Chaque interaction peut être vue comme une
communication avec un partenaire métier. Une interaction est décrite à l‟aide de liens entre
partenaires (partner links). Ce sont des instances spécifiant des connecteurs typés qui
spécifient les types de ports WSDL se trouvant à chaque extrémité.
Pour un partenaire, il peut y avoir un ensemble de liens. Un lien peut être vu comme un
canal de communication. Une telle interaction a deux côtés : le processus invoque le
partenaire et vise versa. Ainsi, chaque partnerlink est caractérisé par un type
(partnerLinkType) et un rôle. Cette information identifie la fonctionnalité qui doit être fournit
par le processus métier et le service partenaire (voir la figure 2.2).
<partnerLinks>
<partnerLink name="ClientStartUpLink"
partnerLinkType="wsdl:ClientStartUpPLT" myRole="Client" />
</partnerLinks>
Figure 2.2. Interaction entre un processus et son partenaire
Les déclarations d‟un Partner link peuvent prendre place directement à l‟intérieur de
l‟élément « process » pour permettre leur accessibilité par les constructions BPEL à l‟intérieur
du process, ou à l‟intérieur d‟un élément « scope » pour une accessibilité exclusive par les
éléments fils du « scope ».
2.4 Etat d’un processus BPEL
Nous avons vue dans la section 2.2, les « données du processus ». ces données
représentent l‟ensemble des variables déclarées dans le processus ou dans un « scope » à
l‟intérieur de ce processus. Les variables contiennent les données qui constituent l‟état du
processus métier durant son exécution. De plus, Les données peuvent être écrit sur ces
Chapitre 2. Langage d’exécution BPEL 24
variables ou lu à partir de ces derniers. Les valeurs contenues dans ces variables peuvent
provenir de deux sources : soit à partir des messages échangées avec un partenaire, soit à
partir des données intermédiaires qui sont propres au processus (des données privées). Pour
respecter la convention de type avec le partenaire, toutes les variables dans BPEL doivent être
de type message WSDL, de type XML schéma simple, de type XML schéma complexe ou des
éléments XML schéma. Afin de changer l‟état d‟un processus à travers le changement du
contenu de ses variables, un langage d‟expression pour manipuler et interroger les variables
est nécessaire. En BPEL, le langage par défaut prévu pour cet effet est Xpath 1.0 [Clark99a].
Il est possible de déclarer une variable par un nom et l‟un des trois types mentionnés
plus haut (avec les trois attributs : « type », « messageType » ou « element ») (voir la figure
2.3).
<variables>
<variable name="myVar1" messageType="myNS:myWSDLMessageDataType" />
<variable name="myVar1" element="myNS:myXMLElement" />
<variable name="myVar2" type="xsd:string" />
<variable name="myVar2" type="myNS:myComplexType" />
</variables>
Figure 2.3: Variables BPEL
Les déclarations de variables peuvent apparaitre directement à l‟intérieur des balises du
« process », et ils sont ainsi visibles aux constructions contenues dans ces balises. Ils peuvent
apparaitre également à l‟intérieur d‟un « scope » (ils sont ainsi visibles exclusivement aux fils
du « scope »).
2.5 Comportement d’un processus BPEL
La majorité des structures d‟un processus BPEL sont des activités. Il y a deux types :
Activités structurées (peuvent contenir d‟autres activités et définir la logique métier entre eux)
et Activités de base (ne peuvent pas contenir d‟autre activités).
2.5.1 Fournir et consommer des services web
En BPEL, il existe quelques activités simples qui ont pour but de fournir et consommer
des messages à travers leur interaction avec les services web partenaires. Ces activités sont :
« receive» (réception), « reply » (réponse) et « invoke » (appel ou invocation). Toutes ces
activités permettent l‟échange des messages avec des partenaires externes (services). L‟intérêt
de l‟activité « receive » est de recevoir les messages depuis ses partenaires externes. Par
conséquent, ce type d‟activité spécifie toujours les Partner links et l‟opération des partenaires.
Chapitre 2. Langage d’exécution BPEL 25
Des variables sont nécessaires également pour contenir les données essentielles reçus d‟un
partenaire. Une activité de type réception peut avoir un « reply » associé si elle est utilisée
pour fournir une opération WSDL de type requête-réponse (voir la figure 2.4).
<receive name="ReceiveRequestFromPartner"
createInstance="yes"
partnerLink="ClientStartUpPLT"
operation="StartProcess" ... />
Figure 2.4: Activité « receive »
L‟attribut « createInstance » à l‟intérieur de l‟activité «receive» signifie qu‟il est
possible d‟utiliser une activité de type « receive » avec une valeur «yes» pour l‟attribut pour
créer une nouvelle instance du processus. Par contre, si cette valeur est « no » alors le
message reçu sera consommé par l‟instance déjà exécutée. Comme déjà mentionné, une
activité de type «receive» peut avoir une activité « reply » associée. Par exemple, si un client
veut commander un livre depuis un processus de vente. Un client enverrait une requête à
l‟activité de type « receive » du processus de vente. Le processus ferait quelques vérifications
d‟ordre logique (internes) (par exemple si le livre est disponible…). Ensuite, il serait naturel
pour le processus de répondre au client pour le tenir informer à propos du succès ou de
l‟échec de sa commande (voir la figure 2.5).
<reply name="ReplyResponseToPartner"
partnerLink="ClientStartUpPLT"
operation="StartProcess" ... />
Figure 2.5. Activité « reply »
La troisième activité liée aux services web est « invoke ». C‟est une activité utilisée
pour appeler un service web fournit par un partenaire. Le « partnerLink » et l‟opération du
service web doivent être spécifiés (voir la figure 2.6).
<invoke name="InvokePartnerWebService"
partnerLink="BusinessPartnerServiceLink"
operation="partnerOperation" ... />
Figure 2.6. Activité « invoke »
En WSDL il existe de multiples types d‟opérations. Deux d‟entre eux sont supportés
par BPEL: les opérations à sens unique et les opérations de type requête-réponse. Une
Chapitre 2. Langage d’exécution BPEL 26
activité « invoke » peut donc soit appeler une opération à sens unique (n‟attend pas de
« reply »), soit faire une opération requête-réponse (qui bloque le processus jusqu‟à réception
d‟un « reply » depuis le service partenaire). Si l‟opération invoquée est de type requête-
réponse, des variables d‟entrée et de sortie doivent être fournies (voir la figure 2.7).
<invoke name="RequestResponseInvoke"
partnerLink="BusinessPartnerServiceLink"
operation="RequestResponseOperation"
inputVariable="Input"
outputVariable="Output" />
Figure 2.7. Activité « invoke » pour une opération WSDL requête-réponse
2.5.2 Structuration de la logique des processus
BPEL fournit des moyens pour structurer la logique métier suivant les besoins. Si les
activités ont besoin d‟être exécutés dans un ordre séquentiel alors l‟activité « sequence » est
utilisée (voir la figure 2.8).
<sequence name="InvertMessageOrder">
<receive name="receiveOrder" ... />
<invoke name="checkPayment" ... />
<invoke name="shippingService" ... />
<reply name="sendConfirmation" ... />
</sequence>
Figure 2.8. Activité « sequence »
Une autre activité utilisée pour structurer la logique métier est l‟activité « if-else » (si-
sinon). La construction peut être devinée depuis les langages de programmation traditionnels.
L‟activité « if-else » permet la sélection d‟une possibilité parmi plusieurs. Comme avec toutes
les expressions de BPEL, Xpath peut être utilisé pour formuler la condition (voir la figure
2.9).
Chapitre 2. Langage d’exécution BPEL 27
<if name="isOrderBiggerThan5000Dollars">
<condition>
<!-- XPATH expression -->
$order > 5000
</condition>
<invoke name="calculateTenPercentDiscount" ... />
<elseif>
<condition>
<!-- XPATH expression -->
$order > 2500
</condition>
<invoke name="calculateFivePercentDiscount" ... />
</elseif>
<else>
<reply name="sendNoDiscountInformation" ... />
</else>
</if>
Figure 2.9. Activité « if-else »
2.5.3 Activités répétitives
BPEL offre trois activités permettant une exécution répétitive d‟une portion de logique
métier. L‟une de ses activités est l‟activité « while ». L‟activité « while » est une activité
structurée (elle a un fils emboité à l‟intérieur). Le « while » permet une exécution répétitive de
l‟activité emboitée aussi longtemps que la condition est vrai. Cette condition est placée au
début de l‟activité et elle est évaluée à chaque ité ration. Cela veut dire que le corps du
« while » ne doit pas être exécuté (voir la figure 2.10).
<while>
<condition>
$iterations > 3
</condition>
<invoke name="increaseIterationCounter" ... />
</while>
Figure 2.10. Activité « while »
Par contre, l‟activité « repeatUntil » est différente par le fait que son corps est exécuté
au moins une fois, parce que la condition est évaluée à la fin de chaque itération (voir la figure
2.11).
<repeatUntil>
<invoke name="increaseIterationCounter" ... />
<condition>
$iterations > 3
</condition>
</repeatUntil>
Figure 2.11. Activité « repeatUntil »
Chapitre 2. Langage d’exécution BPEL 28
La troisième activité du groupe d‟activités répétitives est le « forEach ». Dans son
comportement par défaut, l‟activité « forEach » itère séquentiellement N fois sur un ensemble
d‟activités. Concrètement, le « forEach » itère son contenu (son « scope ») exactement N
fois. N étant égale le « finalCounterValue » moins le « startCounterValue » plus 1 (voir la
figure 2.12).
<forEach parallel="no" counterName="N" ...>
<startCounterValue>1</startCounterValue>
<finalCounterValue>5</finalCounterValue>
<scope>
<documentation>check availability of each item ordered</documentation>
<invoke name="checkAvailability" ... />
</scope>
</forEach>
Figure 2.12. Activité « forEach »
Deux variantes « forEach » existent : séquentielle et parallèle, comme spécifié par
l‟attribut « parallel ». Une restriction est appliquée au « forEach » : toutes les activités que
nous venons de voir peuvent avoir une activité emboité à l‟intérieur, ce qui n‟est pas le cas du
« forEach » qui ne peut contenir que des « scope ».
2.5.4 Traitement parallèle
Jusqu‟ici, nous avons introduis des concepts variés sur la manière dont un processus
métier peut être structuré séquentiellement. Toutefois, il est parfois préférable ou même
nécessaire d‟exécuter en parallèle. Pour cette raison, BPEL offre l‟activité de type « flow ».
Dans l‟exemple suivant, un ensemble composé de trois activités (checkFlight (vérifier le
vole), checkHotel (vérifier l‟hotel) et checkRentalCar (vérifier la voiture de location)) sont
exécutées en parallèle (leurs services web correspondants seront exécutés en concurrence).
Les trois activités démarrent en concurrence au démarrage du « flow » (voir la figure 2.13).
<flow ...>
<links> ... </links>
<documentation>
check availability of a flight, hotel and rental car concurrently
</documentation>
<invoke name="checkFlight" ... />
<invoke name="checkHotel" ... />
<invoke name="checkRentalCar" ... />
</flow>
Figure 2.13: Activité « flow »
Chapitre 2. Langage d’exécution BPEL 29
Parfois, même dans un processus parallèle principal, il est nécessaire de synchroniser les
activités. Par exemple, nous disposons de quatre activités : une activité bookFlight (réservé un
vole), ajoutée aux trois activités de l‟exemple précédant. Si nous voudrons juste ajouter cette
activité au « flow », son exécution serait en parallèle au démarrage du « flow ». Par contre,
logiquement la réservation de vole n‟a un sens que si le vole est disponible. Par conséquent,
un « link » (lien) est ajouté entre ces deux activités. Le rajout du lien introduit une
dépendance de contrôle qui signifie que l‟activité destination du lien ne peut être exécutée que
si l‟activité source du lien est terminée. Le BPEL correspondant est comme suit (voir la figure
2.14) :
<flow ...>
<links>
<link name="checkFlight-To-BookFlight" />
</links>
<documentation>
check availability of a flight, hotel and rental car concurrently
</documentation>
<invoke name="checkFlight" ...>
<sources>
<source linkName="checkFlight-To-BookFlight" />
</sources>
</invoke>
<invoke name="checkHotel" ... />
<invoke name="checkRentalCar" ... />
<invoke name="bookFlight" ...>
<targets>
<target linkName="checkFlight-To-BookFlight" />
</targets>
</invoke>
</flow>
Figure 2.14. Activité « flow » avec « link »
Les sémantiques des éléments link sont plus riches que celles de notre exemple. Un link
peut avoir une condition de transition associée à lui et qui influence son statut. Si aucune
condition de transition (transitionCondition) n‟est spécifiée, le statut du link est vrai (true).
Par contre, si elle est spécifiée, elle fixe le statut du link. Voici un exemple de la figure 2.15 :
<flow ...>
<links>
<link name="request-to-approve" />
<link name="request-to-decline" />
</links>
<receive name="ReceiveCreditRequest"
createInstance="yes"
partnerLink="creditRequestPLT"
operation="creditRequest"
variable="creditVariable">
<sources>
<source linkName="request-to-approve">
<transitionCondition>
Chapitre 2. Langage d’exécution BPEL 30
$creditVariable/value < 5000
</transitionCondition>
</source>
<source linkName="request-to-decline">
<transitionCondition>
$creditVariable/value >= 5000
</transitionCondition>
</source>
</sources>
</receive>
<invoke name="approveCredit" ...>
<targets>
<target linkName="request-to-approve" />
</targets>
</invoke>
<invoke name="declineCredit" ...>
<targets>
<target linkName="request-to-decline" />
</targets>
</invoke>
</flow>
Figure 2.15. Activité « flow » avec « link » et « transitionCondition »
Le lien request-to-approve (demande-à-accord) possède une condition de transition qui
vérifie si la partie valeur de la variable creditVariable a une valeur inférieure à 5000. Si c‟est
le cas, le statut du link de request-to-approve sera fixé à « true », sinon il sera fixé à « false ».
Puisque la condition de transition du lien request-to-decline est exactement l‟opposé
(supérieur à 5000), alors l‟une des deux activités qui succèdent (approveCredit et
declineCredit sera exécutée).
Les conditions de transition offrent un mécanisme pour diviser le flux de contrôle en se
basant sur certaines conditions. Par conséquent, un mécanisme de fusion doit aussi être offert.
BPEL réalise ça avec les conditions de jointure (joinCondition). Les conditions de jointure
sont associées aux activités, habituellement si l‟activité a des liens entrants.
Une joincondition spécifie pour une activité une sorte de condition de départ (start
condition). Par exemple, tous les liens entrants doivent avoir un statut fixé à « true » pour que
l‟activité s‟exécute, ou bien au moins un seul lien entrant doit avoir un tel statut. L‟exemple
suivant illustre ce cas (voir la figure 2.16) :
Chapitre 2. Langage d’exécution BPEL 31
<flow ...>
<links>
<link name="request-to-approve" />
<link name="request-to-decline" />
<link name="approve-to-notify" />
<link name="decline-to-notify" />
</links>
<receive name="ReceiveCreditRequest"
createInstance="yes"
partnerLink="creditRequestPLT"
operation="creditRequest"
variable="creditVariable">
<sources>
<source linkName="request-to-approve">
<transitionCondition>
$creditVariable/value < 5000
</transitionCondition>
</source>
<source linkName="request-to-decline">
<transitionCondition>
$creditVariable/value >= 5000
</transitionCondition>
</source>
</sources>
</receive>
<invoke name="approveCredit" ...>
<source linkName="approve-to-notify" />
<targets>
<target linkName="request-to-approve" />
</targets>
</invoke>
<invoke name="declineCredit" ...>
<source linkName="approve-to-notify" />
<targets>
<target linkName="request-to-decline" />
</targets>
</invoke>
<reply name="notifyApplicant" ...>
<targets>
<joinCondition>
$approve-to-notify or $decline-to-notify
</joinCondition>
<target linkName="approve-to-notify" />
<target linkName="decline-to-notify" />
</targets>
</invoke>
</reply>
</flow>
Figure 2.16. Activité « flow » avec « link », « transitionCondition » et «joinCondition »
En cas ou une erreur se produit dans l‟activité approveCredit, le lien sortant de cette
activité (approve-to-notify) sera fixé à « false » par l‟environnement d‟exécution. Cela peut
mener à une situation où une condition de jointure est évaluée à « false ». WS-BPEL fournit
deux mécanismes pour traiter les conditions de jointure évaluées à « false ».
Chapitre 2. Langage d’exécution BPEL 32
Par défaut, un joinFailure (échec de jointure) est lancé et peut être capturé par un
gestionnaire d‟erreur. Ou bien, quant l‟attribut suppressJoinFailure à l‟intérieur d‟un
processus ou d‟une activité jointe est fixé à « vrai », l‟activité associée à la condition de
jointure fixée à « false » est omise et le statut du lien (fixé à « false ») est propagé à travers les
liens sortants de cette activité. En d‟autres termes, un statut de lien fixé à « false » sera
propagé transitivement à travers tous les chemins formés par la succession de liens jusqu‟à
l‟atteinte d‟une condition de jointure évaluée à « true ». Cette approche s‟appelle Dead-Path
Elimination (DPE) (élimination du chemin mort).
2.5.5 Manipulation des données
Dans les sections précédentes nous avons vue comment un processus reçoit les données
métiers. Mais en pratique, ces données ont besoin parfois d‟êtres divisées en plusieurs parties,
ou jointent depuis plusieurs sources. Par exemple, un message entrant au processus contient
les parties suivantes :
Le nom du client
Un nombre d‟articles commandés
Une adresse d‟expédition
Information de la carte de crédit
Etc.
Une entreprise comprend un département chargé de gérer les expéditions et un autre qui
gère la disponibilité. Un partenaire métier vérifie la validité de la carte de crédit. Il est évidant
que ce service partenaire n‟a rien à voir avec les commandes du client, il p rend seulement en
compte le nom du client et les informations de sa carte de crédit. Dans ce scénario, nous avons
besoin de : prendre deux informations faisant partie du message entrant du processus, créer un
nouveau message qui contient juste ces deux parties et utiliser ce nouveau message comme
message entrant au service creditCardCheck (vérification de la carte de crédit). Il devient
alors nécessaire d‟introduire un nouveau mécanisme pour la manipulation des données à
l‟intérieur d‟un processus métier BPEL.
Pour ce fait, BPEL offre une activité d‟affectation (assign). L‟activité assign contient
une ou plusieurs opérations de copies (copy). Chacune possède « from-spec » et « to-spec »,
indiquant la source où l‟information est copiée et la destination où l‟ information est collée.
Dans l‟exemple suivant, le contenu de la variable est copié dans une autre variable ayant un
type de données similaire (voir la figure 2.17) :
Chapitre 2. Langage d’exécution BPEL 33
<assign>
<copy>
<from variable="TimesheetSubmissionFailedMessage" />
<to variable="EmployeeNotificationMessage" />
</copy>
</assign>
Figure 2.17. Activité « assign »
Toutefois, l‟exemple textuel montre que ce n‟est pas suffisant car souvent nous avons
besoin de copier une partie du contenu de la variable dans une autre, ou même une partie du
contenu de la variable dans une partie d‟une autre variable. Ainsi, nous avons besoin d‟un
moyen pour référencer de telles parties. Un des buts de BPEL est de ne pas inventer d‟autres
langages XML pour la manipulation des données, mais de réutiliser d‟autres standards tels
que XPath et XSLT [Clark99b] pour cette fin (voir la figure 2.18).
<assign>
<copy>
<from variable="Input" part="operation1Parameter">
<query>
creditCardInformation
</query>
</from>
<to variable="CreditCardServiceInput" />
</copy>
</assign>
Figure 2.18. Activité « assign » avec les attributs du langage de requête
Dans l‟exemple, quand la partie d‟une variable est adressée, un langage de requête peut
être spécifié pour cette fin. XPath 1.0 est utilisé dans l‟exemple, comme indiqué dans
l‟attribut queryLanguage de l‟élément query (XPath 1.0 est l‟expression par défaut et le
langage de requête dans WS-BPEL 2.0). Il est aussi possible d‟affecter des données depuis :
La propriété d‟une variable :
<from>
bpel:getVariableProperty("Input", "a:orderNo")
</from>
Un lien de partenaire (partnerLink) :
<from partnerLink="Supplier"/>
Ou Expression :
<from>
count($po/poline)
</from>
Chapitre 2. Langage d’exécution BPEL 34
2.5.6 Traitement des exceptions
Presque tous les concepts expliqués, à travers les exemples précédents, supposent que
tout se passe bien durant l‟exécution d‟un processus métier. En réalité, un langage comme
BPEL doit être capable de gérer les situations exceptionnelles (par exemple, appeler un web
service non disponible). En d‟autres termes, un mécanisme de gestion des exceptions doit être
offert, et aussi un moyen de gérer ces situations doit être fourni.
BPEL offre ainsi le concept de gestion des erreurs (« fault handlers »). Un gestionnaire
d‟erreurs peut être attaché à un scope, un process ou même à travers des abréviations à
l‟intérieurs de l‟activité invoke. Dans ce qui suit, seul le traitement des erreurs au niveau du
process seront exposés. Un gestionnaire d‟erreurs est installé dés le démarrage d‟un scope
associé à lui. Par exemple, le gestionnaire d‟erreurs au niveau d‟un processus est installé au
démarrage du processus. Si le processus termine normalement, le gestionnaire d‟erreurs est
abandonné, par contre si une situation d‟erreur se présente, elle est propagée au gestionnaire
d‟erreurs (voir 2.19).
<faultHandlers>
<catch faultName="BookOutOfStockException"
faultVariable="BookOutOfStockVariable">
...
</catch>
<catchAll>...</catchAll>
</faultHandlers>
Figure 2.19. Gestionnaire d‟erreur dans un processus
Dans cet exemple, un gestionnaire d‟erreurs peut avoir deux types de fils : une
construction ou plus de type catch (capture), et au plus un catchall. Chaque construction catch
doit fournir une activité (dans l‟endroit où se trouvent les points de suspension dans la figure
précédente) qui exécute la gestion de l‟événement pour un type d‟erreur spécifique. Un appel
de vérification de la disponibilité (checkAvailability) d‟un service web pour la réservation,
pour voir si le livre réservé est en stock, et la réponse du service web, peuvent se faire à
travers le lancement d‟un BookOutOfStockExeption (qui sera déclaré dans l‟interface WSDL
du service). Une construction catch possède des attributs additionnels : un faultName (le nom
de l‟erreur) et un faultVariable. Quand un faultVariable est utilisé, soit l‟attribut
faultMessageType ou faultElement doit être spécifié. Le faultVariable pointe localement sur
Chapitre 2. Langage d’exécution BPEL 35
une variable déclarée à l‟intérieur d‟une construction catch basée sur le faultMessageType ou
le faultElement.
Optionnellement, le gestionnaire des erreurs peut finir avec une construction catchall.
Le but est de fournir un moyen de gestion d‟erreurs par défaut. Par exemple, si le service web
checkAvailability ne lance pas seulement BookOutOfStockExeption, mais aussi un
BookOutOfPrintExeption (exception pour un livre non imprimé) et
BookTitleNotFoundExeption (exception pour un titre non trouvé). Si la distinction entre la
gestion d‟erreurs de ces deux derniers n‟est pas voulue, il est possible de compléter le
catchAll avec les activités de gestion d‟exception appropriées.
2.6 Raffinement de la structure d’un processus
En BPEL, il est possible de structurer un processus d‟entreprise dans une hiérarchie de
scopes. Chaque scope peut avoir ses propres définitions de variables, liens partenaires,
messages échangés, ensembles corrélés et gestionnaires. Cela limite la visibilité de ces
éléments à l‟intérieur des activités emboités et fournit le contexte dans lequel ils sont
exécutés. Le contexte le plus à l‟extérieur est la définition même du processus.
Deux constructions en langage BPEL requièrent l‟usage des scopes. La première
activité dans le gestionnaire d‟événement onEvent et dans l‟activité forEach doit être un
scope. Ces scopes possèdent la définition de la variable du gestionnaire d‟événement et la
variable compteur de boucles (l‟attribut counterName du foreEach), respectivement. Dans le
cas du gestionnaire d‟événement, le scope emboité peut aussi contenir la définition du lien de
partenaire, du message échangé ou celle de l‟ensemble corrélé utilisé par le gestionnaire
d‟événement.
Si l‟activité invoke contient la définition du gestionnaire d‟erreur ou celle du
gestionnaire de compensation alors, elle est équivalente à un scope implicite emboité
immédiatement dans l‟activité invoke. Cette activité implicite suppose que le name de invoke
comprend son attribut suppressJoinFailure et ses éléments : sources et targets.
Chapitre 2. Langage d’exécution BPEL 36
2.6.1 Cycle de vie d’un scope
Un scope peut être utilisé comme une activité régulière (par exemple comme un élément
fils d‟une boucle loop). Le cycle de vie d‟un scope commence avec la séquence
d‟initialisation pour les entités définient localement à l‟intérieur du scope:
Initialisation des variables et des liens de partenaire
Instantiation des ensembles corrélés
Installation des gestionnaires d‟exceptions, de terminaison et d‟événement.
Ces étapes sont exécutés indivisiblement (soit ils réussissent leur exécution soit l‟erreur
bpel:scopeInitializationFailure est lancée vers le scope parent). Après l‟initialisation du
scope, sa première activité est exécutée et tous les gestionnaires d‟événements sont activés en
parallèle, excepté l„activité initiale du scope qui est exécutée avant l‟activation des
gestionnaires d‟événement.
Un scope finit son travaille avec ou sans succès. Il existe trois cas différents :
Une terminaison normale: si la première activité se termine sans fautes et s‟il n‟existe pas
d‟activités orphelines de type message alors tous les gestionnaires d‟événements sont
désactivés (l‟exécution de l‟instance du gestionnaire d‟événement est exigée pour finir), le
gestionnaire de compensation est installé. Le scope finit avec succès.
Une erreur interne : si l‟erreur est lancée à l‟intérieur du scope alors toutes les autres
activités en court d‟exécution et les instances du gestionnaire d‟événement à l‟intérieur du
scope sont terminés et un gestionnaire d‟erreur similaire est exécuté. Le scope finit sans
succès.
Terminaison externe : si un scope en court d‟exécution reçoit un signal de terminaison (à
cause d‟une erreur externe ou une condition d‟achèvement) alors toutes les autres activités
en court d‟exécution et les instances du gestionnaire d‟événement à l‟intérieur du scope
sont terminés. Le scope finit sans succès.
Les sections suivantes décrivent les différents types de gestionnaires avec plus de
détailles.
Chapitre 2. Langage d’exécution BPEL 37
2.6.2 Gestion d’erreur d’un scope
En BPEL, les gestionnaires d‟erreur pour les processus ont été introduits dans la section
2.5.6. Ils peuvent également être associés avec un scope pour traiter des situations d‟exception
locales (voir la figure 2.20).
<scope>
<faultHandlers>
<catch faultName="xyz:anExpectedError">...</catch>
<catchAll><!-- deal with other errors -->
...
</catchAll>
</faultHandlers>
<sequence>
<!-- do work -->
</sequence>
</scope>
Figure 2.20. Gestion d‟erreur d‟un scope
Quand une erreur se produit à l‟intérieur d‟un scope alors ce dernier se termine sans
succès. Avant la fin du traitement du scope, un gestionnaire d‟erreur local peut traiter cette
erreur. Les gestionnaires d‟erreur peuvent eux même lancer de nouvelles erreurs ou relancer
l‟erreur capturée vers le scope emboité suivant ou vers le processus s‟il n‟y a plus de scope
emboité.
2.6.3 Terminaison d’un travail en court d’exécution
Les scopes eux même peuvent influencer leur comportement de terminaison. Des cas
typiques d‟usage incluent l‟exécution d‟un travaille propre ou envoyer un message à un
partenaire métier. Après terminaison de la première activité du scope et toutes les instances du
gestionnaire d‟événements, le terminationHandler est exécuté (voir la figure 2.21).
<scope>
<terminationHandler>
<!-- clean up resources in case of forced termination -->
</terminationHandler>
<sequence>
<!-- do work -->
</sequence>
</scope>
Figure 2.21. Gestion des terminaisons
Les gestionnaires personnalisés de terminaison peuvent contenir des activités BPEL qui
incluent compensate et compensateScope. Ils ne peuvent pas propager les erreurs au delà de
Chapitre 2. Langage d’exécution BPEL 38
leur logique métier interne parce que la terminaison peut soit être causée par une autre erreur
soit par une condition de terminaison d‟une activité forEach.
2.6.4 Annulation d’un travail terminé
Le processus métier représente typiquement la longue exécution d‟un travail qui ne peut
être complété à l‟intérieur d‟une unique transaction atomique. Déjà les transactions ACID
engagé pour cet effet créent des effets persistants avant que le processus termine. Des étapes
appliquées spécifiquement à une compensation annulent ces effets si nécessaire. Dans un
scope, la construction du langage pour renverser à l‟avance les étapes d‟un processus terminé
est le compensationHandler. Il peut être invoqué après le succès de la terminaison de son
scope associé, en utilisant l‟activité compensate ou compensateScope (voir la figure 2.22).
<scope name="S1">
<faultHandlers>
<catchAll>
<compensateScope target="S2" />
</catchAll>
</faultHandlers>
<sequence>
<scope name="S2">
<compensationHandler>
<!-- undo work -->
</compensationHandler>
<!-- do some work -->
</scope>
<!-- do more work -->
<!-- a fault is thrown here; results of S2 must be undone -->
</sequence>
</scope>
Figure 2.22. Gestion d‟une compensation
Le gestionnaire de compensation d‟un scope est visible par rapport à l‟état courant
d‟une instance du processus. L‟état d‟un scope terminé avec succès est sauvegardé pour
permettre au gestionnaire de compensation de « continuer » à travaille sur lui plus tard. L‟état
des scopes internes est partagé avec d‟autres travaux concurrents tels que toute concurrence et
considération isolée appliquées au gestionnaire de compensation dans le même sens comme
pour l‟activité primaire du scope.
Les gestionnaire de compensation sont invoqués par l‟activité compensate ou
compensateScope. Lesquelles peuvent résider dans un gestionnaire d‟erreur (fault handler),
un gestionnaire de compensation (compensate handler) ou une gestionnaire de terminaison
(termination handler) (référencés par FCT-handlers), d‟un scope interne immédiat. Une
Chapitre 2. Langage d’exécution BPEL 39
activité compensate pousse le gestionnaire de compensation de tout les scopes fils terminés
avec succès ou pas encore compensés, à s‟exécuter dans un ordre par défaut. Une activité
compensateScope provoque l‟exécution du gestionnaire de compensation de tous les scopes
fils terminés avec succès et pas encore compensée. Si une compensation d‟un gestionnaire
associé à un scope est contenue dans une structure répétitive ou gestionnaire d‟événement
alors de multiples instances du gestionnaire de compensation existent. Chacune associée avec
une instance de scope correspondante. Finalement, chaque instance du gestionnaire de
compensation peut en retour provoquée l‟invocation des gestionnaires de compensation des
scopes internes. L‟ensemble de tous les instances des gestionnaires de compensation invoqués
par l‟activité compensate ou compensateScope est appelé « groupe d‟instance de gestionnaires
de compensation » compensation handler instance group.
Si une erreur est lancée dans un gestionnaire de compensation alors l‟erreur est
propagée au scope contenant l‟activité compensate ou compensatScope qui invoque le groupe
d‟instance des gestionnaires de compensation. Avant le commencement du gestionnaire des
erreurs correspondant, la terminaison de tous les travaux en court d‟exécution comprend tous
les gestionnaires de compensation du groupe encore en court d‟exécution.
2.6.5 Gestion d’événements
Chaque scope aussi bien le processus lui-même peut définir les gestionnaires
d‟événements, ils sont utilisés pour traiter les messages requêtes des services web arrivants en
parallèle sur l‟activité première du scope du processus.
2.7 Conclusion
Au niveau recherche, il existe des langages d‟orchestration et des implémentations
commerciales de ces langages permettant d‟exécuter des processus basés sur le concept
d‟orchestration. BPEL est une spécification qui représente un langage orienté à la
modélisation des processus qui utilisent les services web pour leur implémentation.
Néanmoins, BPEL est un langage de bas niveau, proche des langages de programmation ce
qui le rend difficile à comprendre.
Chapitre 3. Transformation des modèles à l’aide de transformation de graphes 40
Chapitre 3
Transformation des modèles à l’aide
de transformation de graphes
Chapitre 3. Transformation des modèles à l’aide de transformation de graphes 41
Chapitre 3
Transformation des modèles à l’aide de transformation de graphes
3.1 Introduction
L‟utilisation intensive de modèles permet un développement souple et itératif, grâce aux
raffinements et enrichissements par transformations successives. Par ailleurs, les
transformations permettent de passer d‟un espace technique à un autre (par exemple d‟UML
vers les graphes ou vers du XML). De ce fait, les transformations permettent de choisir
l'espace technique et le formalisme le plus approprié à chacune des activités.
Dans le cadre de ce mémoire, on s‟intéresse à la transformation d‟un graphe BPMN vers
un code BPEL basé XML. La transformation de graphes à l‟aide de l‟outil ATOM3 peut
réaliser le passage du modèle des processus métiers (BPMN) vers le code XML.
L‟objectif de ce chapitre est de faire un panorama sur la transformation de modèles,
surtout la transformation de graphes, sur les grammaires de graphes et bien sur de détailler un
peu l‟outil utilisé à savoir l‟ATOM3.
3.2. L’architecture dirigée par les modèles
L‟OMG a proposé et soutenu une démarche de réalisation de logiciel appelée :
« architecture dirigée par les modèles ou MDA ("Model Driven Architecture") ». C'est une
autre variante de l'ingénierie dirigée par les modèles [ElMansouri09].
3.2.1. Notion de modèle
En 2000, l‟OMG a défini l‟approche MDA (Model Driven Architecture). Cette
approche est basée sur l‟utilisation des modèles. Elle tente de répondre aux diverses quest ions
du genre : comment, quand, quoi et pourquoi modéliser. Elle inclut la définition de plusieurs
standards, notamment UML (UnifiedModeling Language), MOF (Meta Object Facility) et
XMI (XML Metadata Interchange). Son principe majeur consiste en l‟utilisat ion de modèles
aux différentes phases du cycle de développement d‟une application. Elle préconise d‟une
manière précise l‟élaboration divers modèles :
Modèle d‟exigences (CIM : Computation Independent Model),
Modèle d‟analyse et de conception (PIM : Platform Independent Model),
Chapitre 3. Transformation des modèles à l’aide de transformation de graphes 42
et Modèle de code (PSM : Platform Specific Model).
L‟élaboration de modèles indépendants des détails techniques des plates formes
d‟exécution (J2EE, .Net, PHP ou autres) constitue l‟objectif majeur de MDA. Cela permet la
génération automatique de la totalité du code des applications et surtout d‟obtenir un gain
appréciable de productivité [Blanc05].
a) Le modèle des besoins CIM
La spécification des besoins ou exigences du client est la première tâche à réaliser lors
de la construction d‟une nouvelle application, afin de créer un modèle prévisionnel des
besoins de l‟application. Le diagramme de cas d‟utilisation d‟UML peut être utilisé comme
modèle des besoins. Il doit définir les fonctionnalités de l‟application, les diverses entités et
leurs interactions. La création d‟un modèle des besoins exprime nettement les liens de
traçabilité avec les modèles qui seront construits dans les autres phases du cycle de
développement de l‟application, comme les modèles d‟analyse et de conception [Blanc05].
b) Le modèle d’analyse et de conception abstraite PIM
A partir du modèle des besoins, on peut entamer les étapes de modèles d‟analyse et de
conception :
En premier lieu avec les méthodes Merise et Coad/Yourdon,
Ensuite avec les méthodes objet Schlear et Mellor, OMT, OOSE et Booch.
Le langage UML s‟est imposé comme la référence pour réaliser tous les modèles
d‟analyse et de conception [Blanc05] au dépend des autres méthodes possédant chacune son
propre modèle.
c) Le modèle de code PSM
Les méthodes d‟analyse et de conception peuvent débuter le travail de génération de
code. MDA considère que le code d‟une application peut être facilement obtenu à partir de
modèles de code. Sachant que le modèle de code (appelé PMS) est lié à une plate forme
d‟exécution par contre ce n‟est pas le cas du modèle d‟analyse et de conception. Leur
principal rôle est de faciliter la génération de code à partir d‟un modèle d‟analyse et de
conception, grâce aux informations utiles à l‟exploitation d‟une plate- forme d‟exécution.
Chapitre 3. Transformation des modèles à l’aide de transformation de graphes 43
Le modèle de code se présente comme une représentation structurée via des concepts de
boucle, de condition, d‟instruction, de composant, d‟évènement, etc. alors que dans le MDA
le code d‟une application est une suite de lignes textuelles (voir un fichier C++). A partir du
modèle de code, l‟écriture de code devient une opération assez simple [Blanc05].
3.2.2. Transformation de modèles
La transformation de modèles est définie comme étant le processus de conversion d‟un
modèle d‟un système à un autre modèle du même système [OMG03b] comme sur la figure
3.1.
Figure 3.1. Vue globale du processus de transformations de modèles selon l‟approche MDA
Par exemples :
Transformer un automate d‟état fini non déterministe (AFN) vers un automate d‟état fini
déterministe (AFD).
Transformer un diagramme UML vers un réseau de Petri.
Transformer un processus métier vers un réseau de Petri,
...
Chapitre 3. Transformation des modèles à l’aide de transformation de graphes 44
3.2.3. Méta-modélisation et transformation
Comme un programme, un modèle destiné à être utilisé par une machine ne doit pas
avoir une ambigüité d‟interprétation. Il doit être exprimé selon des règles bien définies.
Justement, la démarche de méta-modélisation s‟attelle à définir des formalismes pour les
langages de modélisation [ElMansouri09]. Ce qui garantit le traitement correct de tout
modèle conforme à ce formalisme. Le tableau 3.1 résume les différents niveaux d‟abstraction
du concept de méta-modélisation :
Méta-méta-modèle Langage de spécification des méta-modèles
Méta-modèle Définition du langage utilisé pour exprimer le modèle
Modèle Abstraction du système
Système Information et flux de contrôle d‟un domaine
Tableau 3.1. Niveaux d‟abstraction de la méta-modélisation. [OMG04]
1. Au premier niveau, on trouve le système à étudier: il peut être selon le cas d‟un système
d‟information d‟une entreprise, ou d‟une tâche que l‟on souhaite automatiser.
2. Au second niveau, on trouve le modèle qui décrit certains aspects du système à étudier.
On peut avoir affaire à un diagramme de classes UML, à un modèle conceptuel de
traitement MERISE, ou à tout schéma qui représente une vue abstraite des objets
modélisés.
3. Au troisième niveau, on trouve le langage de modélisation ou méta-modèle. Ici, on trouve
les définitions d‟un modèle de conception de données MERISE, d‟un diagramme d‟objet
UML ou d‟une spécification dans le langage B. C‟est ce langage qui doit faire l‟objet
d‟une spécification formelle.
4. Au quatrième niveau, on trouve le méta-méta modèle. A ce niveau, on peut avoir un
langage assez générique pour définir les différents langages de modélisation existants et
assez précis pour exprimer les règles que chaque langage doit respecter pour pouvoir être
traité automatiquement.
Dans l‟architecture proposée par l‟OMG, UML se situe au troisième niveau; un langage
générique de description des modèles est proposé : le MOF (Meta Object Facility). La figure
Chapitre 3. Transformation des modèles à l’aide de transformation de graphes 45
3.2 présente un simple scénario d‟une transformation avec un modèle en entrée (source) et un
modèle en sortie (cible). Les deux modèles sont conformes avec leurs méta-modèles. Une
transformation est définie en respectant les méta-modèles. L‟outil de transformation exécute
cette définition sur des modèles concrets.
Figure 3.2. Concepts de base de la transformation de modèles [Czarnecki06]
Généralement, une transformation peut avoir des modèles sources et cib les multiples.
En outre, les méta-modèles source et cible peuvent être les mêmes dans certaines cas
[ElMansouri09]. Dans la littérature, on peut dire qu‟il existe trois types de transformations :
1. Les transformations verticales , où la source et la cible d‟une transformation verticale
sont définies à différents niveaux d‟abstraction. Le raffinement consiste en une baisse du
niveau d‟abstraction d‟une transformation (PIM vers PSM). Par contre, l‟abstraction
consiste en une élévation du niveau (PSM vers PIM).
2. Les transformations horizontales modifient la représentation source tout en conservant
le même niveau d‟abstraction (PIM vers PIM) ou (PSM vers PSM). La modification peut
être un ajout, une modification, une suppression ou une restructuration d‟informations.
3. Les transformations obliques combinent une transformation horizontale et une verticale.
Les compilateurs utilisent ce type de transformation. Ils effectuent des optimisations du
code source avant de générer le code exécutable.
D‟une manière orthogonale à cette catégorisation, on peut avoir des transformations de
type modèle vers code et celles de type modèle vers modèle. Car, même si les premières
peuvent être considérées comme un cas particulier des secondes. En effet, il suffit de fournir
un méta-modèle pour le langage de programmation cible.
Chapitre 3. Transformation des modèles à l’aide de transformation de graphes 46
3.2.4. Classification des approches de transformation
Plusieurs points de vue ont été la base de classification particulière de chacune des
approches de transformation de modèle. La classification de CZarnecki [Czanecki03] se base
sur les techniques de transformation utilisées dans les approches et les facettes qui les
caractérisent. Celle de Prakash [Prakash06] consiste en une classification
multidimensionnelle, dans laquelle il se focalise sur une dimension non traitée dans les autres
classifications qui est le domaine d‟application et la généricité (capacité de transformer
n‟importe quel modèle d‟entrée à n‟importe quel modèle de sortie). Il prend en considération
l‟aspect utilisation de transformation de modèles dans l‟ingénierie des méthodes. CZarneki
[Czarnecki03] préconise deux types de transformation de modèles : les transformations de
type modèle vers code qui sont aujourd‟hui relativement matures et les transformations de
type modèle vers modèles.
3.2.4.1. Transformations de type Modèle vers code
On distingue deux approches de transformations de type modèle vers code : les
approches basées sur le principe du visiteur (Visitor-based approach) ou celles basées sur le
principe des patrons (Template-based approach). Les premières reposent sur le principe du
visiteur, qui consistent à traverser le modèle en lui ajoutant des éléments (mécanismes
visiteurs) et réduisent la différence de sémantique entre le modèle et le langage de
programmation cible. Le code est obtenu en parcourant le modèle enrichi pour créer un flux
de texte. Les deuxièmes sont basées sur le principe des patrons sont actuellement les plus
utilisées. Le code cible contient des morceaux de méta-code utilisés pour accéder aux
informations du modèle source. La majorité des outils MDA couramment disponibles
supporte ce principe de génération de code à partir de modèle. Parmi les outils basés sur ce
principe, on peut citer : OptimalJ, XDE (qui fournissent la transformation modèle vers modèle
aussi), JET, ArcStyler et AndroMDA (un générateur de code qui se repose notamment sur la
technologie ouverte Velocity pour l‟écriture des patrons) [ElMansouri09].
3.2.4.2. Transformations de type modèle vers modèle
Les transformations de type modèle vers modèle sont aujourd‟hui moins maîtrisées.
Mais, elles ont beaucoup évolué au cours de ces dernières années et plus particulièrement
depuis l‟avènement du MDA [OMG04].
Chapitre 3. Transformation des modèles à l’aide de transformation de graphes 47
a)- Utilité des transformations modèle vers modèle
Il serait plus facile de créer des modèles intermédiaires, au lieu d‟aller directement vers
le PSM cible. Ces modèles servent à l‟optimisation ou bien à des fins de débogage. Ces
transformations sont utiles pour le calcul de différentes vues du système, leur synchronisation,
à des fins de vérification et enfin à des buts de validation.
b)- Structure d’une transformation
Une transformation de modèle est principalement caractérisée par la combinaison des
éléments suivants: des règles de transformation, une relation entre la source et la cible, un
ordonnancement des règles, une organisation des règles, une traçabilité et une direction. Ces
différentes caractéristiques constituent des points de variation qui distinguent les différentes
approches pour la définition de transformation de type modèle vers modèle. On peut
globalement distinguer cinq types d‟approches :
1. Approches par manipulation directe : Elles se basent sur une représentation interne des
modèles source et cible, et sur un ensemble d‟APIs pour les manipuler. Elles sont
généralement implémentées comme des cadres structurants orientés objets qui fournissent
un ensemble minimal de concepts – sous forme de classes abstraites par exemple.
L‟implémentation des règles et leur ordonnancement restent à la charge du développeur.
2. Approches relationnelles : Ce sont celles qui utilisent une logique déclarative reposant
sur des relations d‟ordre mathématique. L‟idée de base est de spécifier les relations entre
les éléments des modèles source et cible par le biais de contraintes. L‟utilisation de la
programmation logique est particulièrement adaptée à ce type d‟approche. Généralement,
les transformations produites sont bidirectionnelles.
3. Approches basées sur les transformations de graphes : Ces approches, qui exploitent
les travaux réalisés sur les transformations de graphes [Andries99]. Ainsi, les règles ne
sont plus définies pour des éléments simples mais pour des fragments de modèles: on
parle de filtrage de motif (pattern matching). Les motifs dans le modèle source,
correspondant à certains critères, sont remplacés par d‟autres motifs du modèle cible. Les
motifs, ou fragments de modèles, sont exprimés soit dans les syntaxes concrètes
respectives des modèles soit dans leur syntaxe abstraite.
4. Approches basées sur la structure : Ces approches distinguent deux phases. La
première consiste à créer la structure hiérarchique du modèle cible. La seconde consiste à
ajuster les attributs et références dans le modèle cible.
Chapitre 3. Transformation des modèles à l’aide de transformation de graphes 48
5. Approches hybrides : Les approches hybrides sont le résultat d‟une combinaison des
différentes techniques. On peut citer des approches utilisant à la fois des règles à logique
déclarative et des règles à logique impérative telles que ATL et XDE.
3.3. Transformations de graphes
3.3.1. Grammaires de graphes
Une transformation de graphe [Karsai04, Andries99, Rozenberg99] consiste en
l‟application d‟une règle à un graphe et itérer ce processus. Chaque application de règle
transforme un graphe par le remplacement d‟une de ses parties par un autre graphe. Donc, la
transformation de graphe est le processus de choisir une règle d‟un ensemble indiqué,
appliquer cette règle à un graphe et réitérer le processus jusqu'à ce qu‟aucune règle ne puisse
être appliquée. La transformation de graphe est spécifiée sous forme d‟un modèle de
grammaires de graphes, ces dernières sont une généralisation, pour les graphes, des
grammaires de Chomsky. Elles sont composées de règles dont chacune est composée d‟un
graphe de côté gauche (LHS) et d‟un graphe de côté droit (RHS) (voir la figure 3.3)
[ElMansouri09].
Définition : Une grammaire de graphe [Andries99] est un ensemble P de règles muni d‟un
graphe initial S et d‟un ensemble T de symboles terminaux.
Exemple : Règle permettant d‟éliminer le non déterminisme dans un AFD.
Figure 3.3. (a) Partie gauche d‟une règle (b) Partie droite d‟une règle
Cette règle permet d‟éliminer le non déterminisme lors de la conversion d‟un automate
non déterministe en un automate déterministe. Une grammaire de graphes distingue les
graphes non terminaux, qui sont les résultats intermédiaires sur lesquels les rè gles sont
Chapitre 3. Transformation des modèles à l’aide de transformation de graphes 49
appliquées, des graphes terminaux dont on ne peut plus appliquer de règles, on dit que ces
derniers sont dans le langage engendré par la grammaire. Pour vérifier si un graphe G est dans
les langages engendrés par une grammaire de graphe, il doit être analysé. Le processus
d‟analyse va déterminer une séquence de règles dérivant G.
3.3.2. Le principe de règles
Une règle de transformation de graphe est définie par :
r = (L, R, K, glue, emb, cond)
Elle consiste en:
Deux graphes L graphe de côté gauche et R graphe de côté droit.
Un sous graphe K de L.
Une occurrence glue de K dans R qui relie le sous graphe avec le graphe de coté droit.
Une relation d‟enfoncement qui relie les sommets du graphe de coté gauche et ceux du
graphe du coté droit.
Un ensemble cond qui spécifie les conditions d‟application de la règle.
3.3.3. Application des règles
Le graphe résultant H est donné par l‟application d‟une règle r= (L, R, K, glue, emb,
cond) à un graphe G. A partir du graphe G d‟origine, le graphe H est obtenu par l‟application
des cinq étapes suivantes :
1. Choisir une occurrence du graphe de coté gauche L dans G.
2. Vérifier les conditions d‟application d‟après cond.
3. Retirer l‟occurrence de L (jusqu‟à K) de G ainsi que les arcs pendillé, c‟est-à-dire tout
les arcs qui ont perdu leurs sources et/ou leurs destinations. Ce qui fourni le graphe de
contexte D de L qui a laissé une occurrence de K.
4. Coller le graphe de contexte D et le graphe de coté droit R suivant l‟occurrence de K
dans D et dans R. c‟est la construction de l‟union de disjonction de D et R et, pour
chaque point dans K, identifier le point correspondant dans D avec le point
correspondant dans R.
5. Enfoncer le graphe du côté droit dans le graphe de contexte de L suivant la relation
d‟enfoncement emb.
Une dérivation directe depuis G vers H à travers r est l‟application de r sur un graphe G
pour fournir un graphe H. Elle est dénotée par G ⇒ H. On peut définir les systèmes de
Chapitre 3. Transformation des modèles à l’aide de transformation de graphes 50
transformation de graphe, les grammaires de graphe et la notion de langages engendrés,
uniquement à l‟aide des notions de règle et de dérivation directe qui sont des concepts
élémentaires de la transformation de graphe.
3.3.4. Système de transformation de graphes
Un système de transformation de graphe est un ensemble P de règles. Supposons que
nous avons un ensemble donné P de règles et un graphe G0, une séquence de transformations
de graphe successive : G0 ⇒ G1 ⇒ … ⇒ Gn est une dérivation à partir de G0 vers Gn par les
règles de P (à condition que toutes les règles utilisées appartiennent à P). G0 est le graphe
initial et Gn est le graphe dérivé de la séquence de transformation. L‟ensemble des graphes
dérivés à partir d‟un graphe initial S en appliquant les règles de P qui sont étiquetées par les
symboles de T est dit langage engendré par P, S et T, et on écrit L(P,S,T).
3.3.5. Outils de transformation de graphes
Il existe plusieurs outils de transformation de graphes. On peut citer quelques exemples
d‟outils de transformation de graphes : AGG [AGG], FUJABA [Fujaba], ATOM3 [Atom3],
VIATRA [Viatra], GreAT [Great], etc. Ici, le choix est porté sur ATOM3 après étude des
différents outils et à cause des avantages qu‟il présente. Nous pouvons citer parmi ces
avantages :
1. sa simplicité,
2. sa disponibilité,
3. il est multi paradigmes,
4. et il permet les deux types de transformations utilisées dans le cadre de cette
thèse, à savoir les transformations de type modèle vers code et les
transformations de type modèle vers modèles.
AToM3 [Atom3] est un outil visuel pour la modélisation et la méta-modélisation multi
formalismes. Comme il a été implémenté en Python [Python07], il peut être exécuté, sans
aucun changement, sur toutes les plateformes où un interpréteur de Python est disponible
(Linux, Windows et MacOS). Ces deux tâches principales sont la méta-modélisation et la
transformation de modèles. Pour la méta-modélisation, il supporte la modélisation visuelle en
utilisant le formalisme Entité-Relation (ER) ou le formalisme de diagrammes de classes
d'UML. Cela signifie que pour méta-modéliser de nouveaux formalismes, on peut utiliser le
modèle ER ou le modèle des diagrammes de classes. Ici, le choix est porté sur l‟utilisation du
modèle des diagrammes de classes.
Chapitre 3. Transformation des modèles à l’aide de transformation de graphes 51
Afin de pouvoir spécifier entièrement les formalismes de modélisation, les méta-
formalismes peuvent être étendus par l'expression de contraintes, ce que les diagrammes de
classes d‟UML ou le modèle ER ne peuvent pas exprimer. Les contraintes fournissent une vue
sur la manière dont un constructeur est lié à un autre pour qu'il ait un sens. Les contraintes
sont exprimées sous une forme textuelle. De ce fait, certains systèmes, dont AToM3, utilisent
OCL (Object Constraint Language) d'UML. On peut utiliser du code Python pour exprimer
les contraintes du moment que AToM3 est implémenté en Python. Pour la transformation de
modèles, AToM3 supporte la réécriture de graphes qui utilise les règles de grammaire de
graphes pour guider visuellement la procédure de transformation. Les règles sont spécifiées
par l'utilisateur et ordonnées selon des critères dépendants des caractéristiques du modèle à
transformer. AToM3 offre la possibilité à l‟utilisateur de créer une nouvelle grammaire, de
charger une grammaire et de la modifier et d‟exécuter une grammaire. L‟exécution de la
grammaire sur un modèle en entrée produit un modèle de sortie.
3.4. Conclusion
Dans ce chapitre, nous avons consacré une bonne partie à la présentation du concept de
transformation de modèles. Il est considéré comme la clé de la démarche MDA. Nous avons
présenté les différentes approches existantes en se basant sur une classification proposée dans
la littérature. Nous avons abordé une introduction aux transformations de graphes qui
représentent une approche de transformation de modèles a été donnée. Nous avons également
rapidement présenté ATOM3, l‟outil de transformation utilisé dans notre travail. Les concepts
présentés dans ce chapitre constituent un vivier nécessaire pour la compréhension de notre
contribution et qui seront présentées dans le chapitre suivant.
Chapitre 4. Une approche automatique de transformation d’un diagramme BPMN vers un code BPEL 52
Chapitre 4
Une approche automatique de
transformation d’un diagramme
BPMN vers un code BPEL
Chapitre 4. Une approche automatique de transformation d’un diagramme BPMN vers un code BPEL 53
Chapitre 4
Une approche automatique de transformation d’un diagramme BPMN vers
un code BPEL
4.1 Introduction
Dans le premier chapitre, nous avons exposé les éléments essentiels d‟un diagramme
BPD, nous avons vue les quatre catégories qui composent la norme BPMN. Ensuite, dans le
second chapitre nous avons vue les morceaux de codes les plus importants du langage BPEL
et on constate qu‟une transformation entre les deux langages n‟est pas chose facile compte
tenu la complexité inhérente à un langage de bas niveau tel que BPEL. Et aussi, une notation
BPMN qui possède un vocabulaire très large presque impossible à étudié de manière
exhaustive et une grammaire qui présente des règles de composition qui doivent être traitées
en profondeur pour arriver à un résultat de transformation satisfaisant.
Toutefois, les buts des deux langages BPEL et BPMN sont liés dans le sens qu‟ils sont
tous deux concerné par l‟exécution des processus. De plus, beaucoup de fonctionnalités dans
BPMN et les workflows en général [Fischer01, Leymann99, Van02] ont un sens vis-à-vis du
langage BPEL et les langages utilisés dans le monde des services web.
Dans [Ouyang08], une translation de BPMN vers BPEL a déjà était étudiée. Les auteurs
en prient en considération les aspects bien-structurés et mal-structurés dans la notation BPMN
et ce, par rapport aux structure qu‟offre BPEL pour l‟orchestration des services web. Compte
tenu la complexité du code BPEL et pour une meilleure visibilité des structures les plus
importantes et directement concernés dans notre travaille nous avons opté pour un code BPEL
simplifier comme dans [Wohed02].
Dans ce chapitre, nous proposons une solution entièrement automatique pour faire la
translation des éléments les plus utilisés dans la norme BPMN vers leur code BPEL
correspondant. Cette solution est basée sur la méta-modélisation, et les grammaires de graphe
et ce, avec l‟outil ATOM3.
4.2 Diagramme BPMN
La figure 4.1 présente un diagramme BPD composé d‟un événement de début (start
event), un événement de fin (end event), deux portes (gateway) et plusieurs activités (activity).
Chapitre 4. Une approche automatique de transformation d’un diagramme BPMN vers un code BPEL 54
Il est tout à fait possible de colorer les éléments de BPMN si ça n‟affecte pas leurs formes de
base [OMG09].
Figure 4.1. Un exemple BPMN
4.3 Code BPEL
BPEL est un langage de bas niveau basé XML. Il présente un ensemble de balises
chacune ayant un sens particulier. A l‟instar des langages de programmation, BPEL est dit un
langage structuré en bloc, où il est possible de hiérarchiser les blocs afin d‟obtenir des codes
plus complexes. Comme il était dis dans l‟introduction, nous entreprenons dans notre travaille
une forme simplifier de ce langage pour permettre une meilleur visibilité des structures
directement concernées par l‟approche que nous voulons aborder (voir la figure 4.2).
<sequence name="SQ0">
<invoke name="A1".../>
<flow name="GTS1">
<invoke name="A2".../>
<sequence name="SQ1">
<invoke name="A3".../>
<invoke name="A4".../>
<invoke name="A5".../>
</sequence>
</flow>
</sequence>
Figure 4.2. Un code BPEL représentant le diagramme BPMN de la Figure 4.1
Chapitre 4. Une approche automatique de transformation d’un diagramme BPMN vers un code BPEL 55
4.4 Ecriture du code BPEL à partir d’un diagramme BPMN
Comme il était dit dans le premier chapitre, BPMN est un langage qui a été créé pour
faire le pond entre la modélisation des processus et leur exécution sur un moteur de workflow.
En effet, BPMN, pour des fins de transformation, offre une bibliothèque d‟attributs qui
viennent complétés ses symboles.
De plus, sa spécification traite le sujet en exposant un nombre important de structures
BPMN et leur code BPEL correspondant. Par exemple, le code de la figure 4.2 est le résultat
de la transformation du diagramme de la figure 4.1, nous verrons plus loin les détailles de la
transformation et la signification de chaque ligne de code.
4.5 Transformation d’un diagramme BPMN vers un code BPEL
Afin d‟obtenir un code BPEL à partir d‟un diagramme BPMN, une méta-modélisation a
été faite suivie de la création d‟un ensemble de règles de grammaires, chacune traite un
élément ou une configuration d‟éléments. Pour ce faire, un outil de transformation de graphe
était nécessaire et nous avons opté pour ATOM3. Pour arriver à notre but, nous sommes
arrivés à construire un méta-modèle comportant 7 classes et une association ensuite, après une
étude des structures des deux langages, nous avons finit par obtenir 25 règles de grammaire.
4.5.1 Méta-modélisation du diagramme BPMN
La raison pour laquelle nous devons construire un méta-modèle est la nécessité d‟avoir
un outil intégrant ATOM3 qui offre les outils nécessaires pour modéliser les diagrammes
BPMN et configurer les attributs de l‟ensemble du diagramme, d‟une partie ou d‟un éléments
intégrant le modèle.
En effet, nous avons choisit parmi les méta-formalismes offerts par ATOM3, le méta-
formalisme " ClassDiagramV3" (un environnement pour créé le méta-modèle). Des
conditions et des contraintes pouvant être écrites en code Python, sont prévues pour
compléter la représentation. La figure 4.3 montre le méta-modèle.
Il est composé de 6 classes : Start (événement du début), Gatway (portes), Activity
(activités), Intermédiate (événement intermédiaire), End (événement de fin) et une sixième
classe (FlowObject), qui a pour rôle la réunion des 5 classes précédentes autour d‟une même
Chapitre 4. Une approche automatique de transformation d’un diagramme BPMN vers un code BPEL 56
association (SequenceFlow (flux de séquences)) par le biais de la propriété d‟héritage
disponible sur ce formalisme.
Figure 4.3. Meta-Model d‟un BPMN
4.5.2 Génération de l’environnement BPMN
Après la modélisation du méta-modèle, il reste sa génération, qui consiste en un simple
click sur le bouton "Gen" en rouge. Le méta-modèle généré comporte l‟ensemble de classes
modélisées sous forme de boutons qui sont prêt à employer pour une éventuelle modélisation
d‟un diagramme BPMN. L‟environnement généré est illustré par la figure 4.4:
Chapitre 4. Une approche automatique de transformation d’un diagramme BPMN vers un code BPEL 57
Figure 4.4. Environnement BPMN sous ATOM3
4.5.3 Grammaire de graphe pour la transformation d’un diagramme BPMN vers un
code BPEL
L‟étape la plus délicate dans un processus de mise en œuvre d‟une transformation de
graphe sur ATOM3 est la construction des règles de grammaire. En effet, elle nécessite une
bonne compréhension des deux langages. Nous avons proposé 25 règles qui seront exécutées
suivant une certaine priorité. Dans cette section nous présentons les règles de grammaire,
leurs noms, leurs priorités, la partie gauche de leur grammaire, une partie du code qu‟elles
génèrent et un commentaire sur leur comportement. Les règles 1, 2, 3, . . ., 9, ont pour rôle de
transformer les composants bien-structurés. Les règles 10, 11, 12, . . ., 17 détectent les
composants (les plus réduits) qui ne sont pas bien-structurés. Les règles 18, 19, 20, . . ., 23
transforment les composants détectés par les règles précédentes. La règle 24 génère le code
complet du diagramme.
Règle1 : "event"(priorité 1) : (voir la figure 4.5)
<wait name="event_name".../>
ou
<receive name="event_name".../>
ou
.
.
.
(a) (b)
Chapitre 4. Une approche automatique de transformation d’un diagramme BPMN vers un code BPEL 58
Figure 4.5. (a) LHS de la règle 1 (b) Code généré par la règle 1
Dans ce qui suit, le nom du fichier qui contiendra le code BPEL généré sera affecté à
l‟attribut temporaire "1st_reach" qui appartiendra à un nœud ou un arc pour des traitements
ultérieurs. Cette première règle est appliquée pour générer le code correspondant au type de
l‟événement intermédiaire (l‟attribut "type" du nœud "1"). Par exemple, si le type est "Timer"
alors le code BPEL généré serait une activité de base de type "wait". La règle vérifie si le
nœud "1" ne possède pas l‟attribut "1st_reach" (si c‟est le cas, elle traite le nœud. Sinon, elle
passe au nœud suivant). Elle vérifie également si les arcs "4" et "5" possèdent l‟attribut
"1st_reach". Trois cas sont pris en considération :
1. Les arcs "4" et "5" ne possèdent pas l‟attribut "1st_reach" : dans ce cas les arcs "4" et "5"
posséderont chacun un attribut "1st_reach" (qui référence le fichier dans lequel se trouve
le code généré).
2. L‟un des deux arcs possède l‟attribut "1st_reach" : La règle ajoute en séquence le code
généré au fichier du "1st_reach" (si la première ligne du fichier ne contient pas la balise
du bloc "sequence", ce dernier sera généré) et elle met à jour les fichiers qui contiennent le
même code. L‟autre arc possèdera également un attribut "1st_reach" de même valeur.
3. Les arcs "4" et "5" possèdent l‟attribut "1st_reach" : la règle met en séquence (elle utilise
le bloc "sequence") le code du fichier affecté au "1st_reach" du nœud "4", suivi par le
code généré, suivi par le code du fichier affecté au "1st_reach" du nœud "5". Ensuite, elle
met à jour les fichiers avec cette nouvelle séquence et modifie les fichiers équivalents (qui
ont le même code que celui des arcs "4" et "5").
Finalement un attribut "1st_reach" sera affecté au nœud "1" pour ne pas répéter son
traitement.
Règle2 : "activity"(priorité 2) : (voir la figure 4.6)
<invoke name="activity_name".../>
(a) (b)
Figure 4.6. (a) LHS de la règle 2 (b) Code généré par la règle 2
Chapitre 4. Une approche automatique de transformation d’un diagramme BPMN vers un code BPEL 59
Le même principe mais avec un nœud de type Activité. Le code BPEL généré sera une
activité de base de type "invoke". Les règles 3, 4, 5, 6, 7 ,8 et 9 suivantes présentent chacune
une structure particulière qui exprime une exécution en parallèle, une jointure de plusieurs
chemins exclusives ou une boucle.
Pour éviter le conflit entre les arcs internes (qui se situent entre les deux Gateways) et
les arcs externes, nous avons choisi une structure avec deux chemins entre les deux Gateways
(deux arcs internes qui sont sur la même ligne présentent un chemin et doivent possédés
l‟attribut "1st_reach" pour référencer un fichier. De plus, les deux fichiers référencés par les
deux arcs doivent avoir le même code). Cette structure garantie l‟existence d‟un seul arc
entrant et d‟un seul arc sortant puisque un Gateway ne peut pas avoir plusieurs arcs entrants et
plusieurs arcs sortants en même temps. Dans le cas où plus de deux chemins sont présents
entre les deux Gateways dans un diagramme BPMN, ils seront pris en considération à travers
des exécutions supplémentaires de la règle. De plus, le comportement par rapport aux arcs
externes est exactement le même que celui des règles 1 et 2 par rapport à leurs arcs "4" et "5"
(l‟attribut temporaire "1st_reach" sera utilisé de la même manière).
Un attribut temporaire supplémentaire : "2nd_reach" sera rajouté aux nœuds et arcs
internes pour une exécution correcte de ces règles. Avant la génération du code BPEL
correspondant, la règle vérifie si les deux nœuds possèdent chacun l‟attribut "2nd_reach". Si
c‟est le cas, ça veut dire qu‟il faudrait rajouter le code BPEL du nouveau chemin (ou des deux
nouveaux chemins) à un code déjà existant dans le fichier référencé par le "2nd_reach" (qui
doit être le même pour les deux nœuds) et procéder à sa mise à jour dans tous les fichiers qui
l‟intègrent.
Sinon, un code BPEL sera généré pour la nouvelle structure et les deux nœuds
posséderont chacun l‟attribut "2nd_reach" à qui sera affecté le nom du fichier qui contiendra
ce nouveau code. Enfin, la règle initialise l‟attribut "2nd_reach" pour les arcs internes traités
(afin d‟éviter le traitement éventuel de ces arcs). Le nom de chaque structure est composé
d‟un acronyme "GTS" qui signifie gateways (parce que cette structure est composée de deux
gateway) suivie de son numéro (un numéro unique est attribué automatiquement à chaque
occurrence d‟une structure).
Règle3 : " exclusiveDBa"(priorité 3) : (voir la figure 4.7).
Chapitre 4. Une approche automatique de transformation d’un diagramme BPMN vers un code BPEL 60
<switch name="GTS..." >
<case condition="cond_name">
...
</case>
...
<otherwise>
<empty/>
</otherwise>
</switch>
(a) (b)
Figure 4.7. (a) LHS de la règle 3 (b) Code généré par la règle 3
La structure BPMN correspond au "switch" du code BPEL généré. Le code généré
présente un "case" (qui signifie un cas) qui intègre le contenu du fichier référencé par
l‟attribut "1st_reach" du nœud "8" (ou "9") et un "otherwise" qui signifie le cas par défaut. Un
"empty" représente l‟arc "10" (ça veut dire qu‟il n‟y a aucune structure sur ce chemin). Dans
la figure 4.7, le "empty" qui se trouve à l‟intérieur du "otherwise" peut se trouvé à l‟intérieur
d‟un "case" si la condition placé dans l‟arc "10" n‟est pas une condition par défaut.
Règle4 : " parallel"(priorité 4) : (voir la figure 4.8)
<flow name="GTS...">
...
</flow>
(a) (b)
Figure 4.8. (a) LHS de la règle 4 (b) Code généré par la règle 4
La structure BPMN correspond au "flow" du code BPEL généré. A l‟intérieur du flow
se trouve le contenu du fichier référencé par l‟attribut "1st_reach" du nœud "9" (ou "10")
suivie du contenu du fichier référencé par l‟attribut "1st_reach" du nœud "11" (ou "12").
Règle5 : " exclusiveDBb"(priorité 4) (voir la figure 4.9) :
Chapitre 4. Une approche automatique de transformation d’un diagramme BPMN vers un code BPEL 61
<switch name="GTS...">
<case condition="cond_name">
...
</case>
...
<otherwise>
...
</otherwise>
</switch>
(a) (b)
Figure 4.9. (a) LHS de la règle 5 (b) Code généré par la règle 5
Même principe que celui de la règle 3 mais le "empty" n‟existe pas.
Règle6 : " exclusiveEB"(priorité 4) : (voir la figure 4.10)
<pick name="GTS...">
<onMessage name="">
...
</onMessage>
...
<onAlarm name="">
...
</onAlarm>
</pick>
(a) (b)
Figure 4.10. (a) LHS de la règle 6 (b) Code généré par la règle 6
Le même principe que celui de la règle précédente mais suivant les éléments qui se
trouvent à l‟arriver des arcs "9" et "11", le code généré prend le bloc "onMessage" (si
l‟élément est un événement intermédiaire de type "message" ou une activité de type "receive")
ou "onAlarm" (si l‟élément est un événement intermédiaire de type "Timer"). Le code
correspondant à l‟élément qui se trouve à l‟arriver des arcs "9" et "11" sera effacé et sera
remplacé par un "empty" s‟il est le seul de son bloc.
Règle7 : " loop1"(priorité 4) : (voir la figure 4.11)
Chapitre 4. Une approche automatique de transformation d’un diagramme BPMN vers un code BPEL 62
<while condition="cond"> ...
</while>
(a) (b)
Figure 4.11. (a) LHS de la règle 7 (b) Code généré par la règle 7
Cette règle transforme une première configuration de boucle. Le "while" intègre le
contenu du fichier référencé par l‟attribut "1st_reach" du nœud "9" (ou "10").
Chapitre 4. Une approche automatique de transformation d’un diagramme BPMN vers un code BPEL 63
Règle8 : " loop2"(priorité 4) : (voir la figure 4.12)
<sequence name="GTS...">
...
<while condition="cond">
...
</while>
</sequence>
(a) (b)
Figure 4.12. (a) LHS de la règle 8 (b) Code généré par la règle 8
Cette règle transforme une deuxième configuration de boucle. Le chemin des arcs "8" et
"9" est pris avant le commencement de la boucle. C‟est pourquoi, Un bloc "sequence"
comprend le code du fichier référencé par le nœud "8" (ou "9") suivi d‟un "while" qui
comprend le même code.
Règle9 : " loop3"(priorité 4) : (voir la figure 4.13)
<sequence name="GTS...">
...
<while condition="cond">
<sequence name="SQ...">
...
...
</sequence>
</while>
</sequence>
(a) (b)
Figure 4.13. (a) LHS de la règle 9 (b) Code généré par la règle 9
Cette règle transforme une troisième configuration de boucle. Le chemin des arcs "9" et
"10" est pris avant le commencement de la boucle. C‟est pourquoi, Un bloc "sequence"
comprend le code du fichier référencé par le nœud "9" (ou "10") suivi d‟un "while" qui
comprend un autre bloc "sequence". Ce dernier contient le code du fichier référencé par le
nœud "9" (ou "10") suivi du code du fichier référencé par le nœud "11" (ou "12").
A présent, nous avons finis avec les composants bien structurés. Pour détecter les
composants (les plus réduits) qui ne sont pas bien structurés, nous proposons 8 règles (les
Chapitre 4. Une approche automatique de transformation d’un diagramme BPMN vers un code BPEL 64
règles 10, 11, 12, . . ., 17). Dans cette solution, un composant est détecté à travers ses
gateways (ce sont les seuls éléments qui seront pris en considération). L‟idée est de stocker
les numéros des voisins de chaque gateway dans un attribut temporaire lui appartenant. De
plus, chaque arc qui se présente à l‟entrée ou la sortie d‟un gateway doit avoir deux attributs
temporaires pour stocker les numéros des gateways les plus proches de ses deux extrémités
parce que la règle 17 a besoin du numéro du gateway qui se trouve à l‟autre extrémité de son
arc. La règle 17 retrouve tous les composants (qui ne sont pas bien structurés) possibles et
procède à l‟élimination d‟un composant si un autre qui vient d‟être détecté lui est inclut.
Règle10 : " numG"(priorité 5) : appliquée pour attribuer automatiquement un numéro (ou
un label) à chaque gateway pour un éventuel "scope" (voir la figure 4.14).
Figure 4.14. LHS de la règle 10
Règle11 : " nameFlow"(priorité 6) : appliquée pour placer le numéro du gateway "1" dans
un attribut temporaire de l‟arc "3" et dans un fichier associé au nœud "2" (qui contient ses
voisins). Elle place aussi le numéro du gateway "2" dans un autre attribut temporaire de
l‟arc "3" et dans un fichier associé au nœud "1" (voir la figure 4.15).
Figure 4.15. LHS de la règle 11
Règle12 : " nameFlow2"(priorité 6) : appliquée pour placer le numéro du gateway "1"
dans un attribut temporaire de l‟arc "4", dans un attribut temporaire de l‟arc "5" et dans un
fichier associé au nœud "2" (qui contient ses voisins). Elle est également appliquée pour
placer le numéro du gateway "2" dans un attribut temporaire de l‟arc "5", dans un attribut
temporaire de l‟arc "4" et dans un fichier associé au nœud "1" comme sur la figure 4.16.
Chapitre 4. Une approche automatique de transformation d’un diagramme BPMN vers un code BPEL 65
Figure 4.16. LHS de la règle 12
Règle13 : " start1"(priorité 6) : appliquée pour situer le composants détecter par rapport
au début du processus parce qu‟un composant ne doit pas contenir un événement de
début. Pour cette raison, cette règle initialise un attribut temporaire sur le gateway "2"
comme sur la figure 4.17.
Figure 4.17: LHS de la règle 13
Règle14 : " start2"(priorité 6) : même principe que la règle précédente si un événement
intermédiaire, une activité ou une séquence se trouve entre le début du processus et le
gateway (voir la figure 4.18).
Figure 4.18. LHS de la règle 14
Règle15 : " end1"(priorité 6) : similaire à la règle 13 mais entre un gateway et un
événement de fin (voir la figure 4.19).
Figure 4.19. LHS de la règle 15
Règle16 : " end2"(priorité 6) : comme la règle 14 mais entre un gateway et un événement
de fin comme sur la figure 4.20.
Chapitre 4. Une approche automatique de transformation d’un diagramme BPMN vers un code BPEL 66
Figure 4.20. LHS de la règle 16
Règle17 : "scopeDetection"(priorité 7): (voir la figure 4.21)
Figure 4.21. LHS de la règle 17
A chaque occurrence de cette règle dans un diagramme BPMN, elle calcule l‟ensemble
des gateways qui forme un composant qui n‟est pas bien structuré (les gateways qui
appartiennent aux composants bien structurés ne sont pas concernés). Ce composant doit être
connecté au restant du diagramme à travers un seul arc d‟entrée et un seul arc de sortie.
Autrement dit, un des deux gateways qui se trouvent aux deux extrémités du composant
possède un seul arc entrant (le gateway "1") et l‟autre possède un seul arc sortant. Les
gateways internes n‟ont aucune relation avec le restant du diagramme. La figure 4.22 illustre
le principe.
Figure 4.22. Principe de la règle 17
La règle 17 ouvre le fichier associé au gateway "1" et récupère les numéros de ses
voisins. Le numéro du voisin qui se trouve avant l‟arc "3" est récupéré depuis l‟un des
attributs temporaires de cet arc. Il est ensuite retiré de l‟ensemble des voisins du nœud "1".
Les fichiers associés aux voisins qui appartiennent au nouvel ensemble seront ouverts et
suivront ensemble le même processus. Le processus termine si l‟ensemble des nouveaux
Chapitre 4. Une approche automatique de transformation d’un diagramme BPMN vers un code BPEL 67
voisins ne contient qu‟un seul numéro (celui d‟un gateway qui se trouve à la sortie du
composant et qui n‟appartient pas au composant) ou aucun numéro (un événement fin se
trouve à la sortie du composant). Après la détection des composants qui ne sont pas bien
structurés, les règles 18, 19, 20, 21 et 22 construisent les gestionnaires d‟événements en
générant un fichier pour chacun. Un commentaire est ajouté au début pour clarifier le code. Le
bloc "onEvent" marque un gestionnaire d‟événement. Dans le code généré, l‟arc déclencheur
d‟événements est représenté par la lettre "E" (qui signifie événement) suivie par les numéros
associés aux deux objets se trouvant à ses deux extrémités.
Règle18 : " taskEH"(priorité 8) : appliquée pour générer le code correspondant au
gestionnaire d‟événements d‟un événement, d‟une activité ou d‟une séquence
d‟événements ou/et d‟activités. Le premier événement "E" présent dans le code
correspond à l‟arc "4" et le second à l‟arc "5". Le code de l‟élément qui se situe entre les
deux arcs est placé avant la balise "invoke" (voir la figure 4.23).
<!-- mapping of ... -->
<onEvent E (...,...)>
<sequence>
...
<invoke E (...,...)/>
</sequence>
</onEvent>
(a) (b)
Figure 4.23. (a) LHS de la règle 18 (b) Code généré par la règle 18
Règle19 : " parallelFork"(priorité 8) : utilisée pour générer le code correspondant au
gestionnaire d‟événement d‟un gateway répartiteur de type parallèle. Les arcs "5", "6",
"7" sont représentés respectivement par le premier, deuxième et troisième événement "E"
du code. En cas de présence de plus de deux arcs sortants du gateway, la règle s‟exécutera
autant de fois que nécessaire en ajoutant une activité de base de type "invoke" qui
contiendra l‟événement du nouveau arc détecté (voir la figure 4.24).
Chapitre 4. Une approche automatique de transformation d’un diagramme BPMN vers un code BPEL 68
< !-- mapping of ... -->
<onEvent E (...,...)>
<flow>
<invoke E (...,...)/>
<invoke E (...,...)/>
</flow>
</onEvent>
(a) (b)
Figure 4.24. (a) LHS de la règle 19 (b) Code généré par la règle 19
Règle20 : " xorDecision"(priorité 8) : génère le code correspondant à un gestionnaire
d‟événement d‟une décision de type exclusive. Comme dans la règle précédente, les arcs
"5", "6", "7" sont représentés respectivement par le premier, deuxième et troisième
événement "E" du code généré.
En cas de présence de plus de deux arcs sortants du gateway, la règle s‟exécutera autant
de fois que nécessaire en ajoutant un bloc "case" qui représentera la condition du nouveau arc
comme sur la figure 4.25.
<!-- mapping of ... -->
<onEvent E (...,...)>
<switch>
<case condition="...">
<invoke E (...,...)/>
<case/>
<case condition="...">
<invoke E (...,...)/>
<case/>
</switch>
</onEvent>
(a) (b)
Figure 4.25. (a) LHS de la règle 20 (b) Code généré par la règle 20
Règle21 : " xorMerge"(priorité 8) : appliquée pour générer le code correspondant à un
gestionnaire d‟événement d‟un gateway présentant une jointure de type parallèle. les arcs
"6", "7", "5" sont représentés respectivement par le premier, deuxième et troisième
événement "E" du code généré. En cas de présence de plus de deux arcs entrants au
gateway, la règle s‟exécutera autant de fois que nécessa ire. Elle construit un bloc "flow" à
Chapitre 4. Une approche automatique de transformation d’un diagramme BPMN vers un code BPEL 69
l‟intérieur du bloc "sequence" qui intégrera le "receive" du premier arc (celui dans la
figure 4.25) et le "receive" du nouveau (voir la figure 4.26).
<!-- mapping of ... -->
<onEvent E (...,...)>
<sequence>
<receive E (...,...)/>
<invoke E (...,...)/>
</sequence>
</onEvent>
(a) (b)
Figure 4.26. (a) LHS de la règle 21 (b) Code généré par la règle 21
Règle22 : " parallelJoin"(priorité 8) : utilisée pour générer le code correspondant à un
gestionnaire d‟événement d‟un gateway "merge" (point de jonction) de type exclusive.
Les arcs "6" et "7" sont représentés par l‟événement "E" de la balise "onEvent". L‟arc "5"
est représentés par l‟événement "E" dans chaque occurrence de la balise "invoke".
Comme la règle précédente, en cas de présence de plus de deux arcs entrants au gateway,
la règle s‟exécutera autant de fois que nécessaire. Elle rajoutera pour chaque nouvel arc
détecté un bloc "onEvent" qui contiendra une activité de base de type "invoke" (voir la
figure 4.27).
<!-- mapping of ... -->
<onEvent E (...,...)>
<invoke E (...,...)/>
</onEvent>
<onEvent E (...,...)>
<invoke E (...,...)/>
</onEvent>
(a) (b)
Figure 4.27. (a) LHS de la règle 22 (b) Code généré par la règle 22
Règle23 : " scope"(priorité 9) : rassemble dans un bloc de type "scope" les gestionnaires
d‟événements appartenant à un même composant. Le nom de ce bloc est composé d‟un
acronyme " SC " qui veut dire "scope" suivie de son numéro (la règle attribut un numéro à
Chapitre 4. Une approche automatique de transformation d’un diagramme BPMN vers un code BPEL 70
chaque composant détecté). Avant la fin du "scope", une activité de base de type invoke
est insérée pour indiquer le déclencheur du premier gateway de ce composant (voir la
figure 4.28).
<scope name="SC...">
...
<!--to trigger source object g1-->
<invoke .../>
</scope>
(a) (b)
Figure 4.28. (a) LHS de la règle 23 (b) Code généré par la règle 23
Règle24 : " process"(priorité 10) : construit le code correspondant au processus complet.
Elle intègre le contenu du fichier référencé par l‟attribut temporaire de l‟arc "4" ou "5", à
l‟intérieur d‟un bloc "process". Le nom du "process" correspond au nom du diagramme
BPMN (voir la figure 4.29).
<process name="nom_du_BPD">
...
</process>
(a) (b)
Figure 4.29. (a) LHS de la règle 24 (b) Code généré par la règle 24
4.5.4 Exemples
4.5.4.1 Exemple 1
Dans cet exemple, nous rapportons le résultat de l‟application de notre grammaire sur
un processus de gestion des plaintes qui possède le diagramme de la figure 4.30 :
Chapitre 4. Une approche automatique de transformation d’un diagramme BPMN vers un code BPEL 71
Figure 4.30. BPD du processus "gestion des plaintes"
En premier lieu, le processus enregistre la plainte. Ensuite, il envoi un questionnaire au
plaignant et traite la plainte en parallèle. Si le plaignant renvoi le questionnaire avant
l‟expiration du délai qu‟il lui est accordé, le processus traitera le questionnaire reçu. Sinon, la
réponse ne sera pas prise en considération. Le plaignant peut également annuler sa plainte
suite à sa réception du questionnaire si son problème est résolu. En même temps, la plainte est
évaluée. Suivant le résultat de l‟évaluation, le traitement termine ou continue. Si le traitement
continue alors sa vérification détermine s‟il s‟est correctement effectué ou non. En cas ou il
s‟est avéré incorrect alors le processus de traitement est réitéré. Et avant sa fin, le processus
archive la plainte. Après l‟exécution de notre grammaire, nous avons obtenu le code
BPEL de la figure 4.31:
<process name="gestion_des_plaintes">
<sequence name="SQ3">
<invoke name="enregistrement de la plainte".../>
<flow name="GTS2">
<sequence name="SQ4">
<invoke name="envoie du questionnaire".../>
<pick name="GTS1">
<onMessage name="reception du questionnaire">
<invoke name="traitement du questionnaire".../>
Chapitre 4. Une approche automatique de transformation d’un diagramme BPMN vers un code BPEL 72
</onMessage>
<onAlarm name="expiration du delai">
<empty/>
</onAlarm>
<onMessage name="recevoir une annulation">
<empty/>
</onMessage>
</pick>
</sequence>
<scope name="SC0">
<!-- mapping of g5 -->
<onEvent E (g3,g5)>
<invoke E (g5,SQ6)/>
</onEvent>
<onEvent E (g7,g5)>
<invoke E (g5,SQ6)/>
</onEvent>
<!-- mapping of SQ6 -->
<onEvent E (g5,SQ6)>
<sequence>
<sequence name="SQ6">
<invoke name="traitement de la plainte".../>
<invoke name="evaluation".../>
</sequence>
<invoke E (SQ6,g6)/>
</sequence>
</onEvent>
<!-- mapping of a7 -->
<onEvent E (g6,a7)>
<sequence>
<invoke name="verification du traitement".../>
<invoke E (a7,g7)/>
</sequence>
</onEvent>
<!-- mapping of g6 -->
<onEvent E (SQ6,g6)>
<switch>
<case condition="Continue">
<invoke E (g6,a7)/>
<case/>
<case condition="Termine">
<invoke E (g6,g8)/>
<case/>
</switch>
</onEvent>
<!-- mapping of g7 -->
<onEvent E (a7,g7)>
<switch>
<case condition="Correct">
<invoke E (g7,g8)/>
<case/>
<case condition="Incorrect">
<invoke E (g7,g5)/>
<case/>
Chapitre 4. Une approche automatique de transformation d’un diagramme BPMN vers un code BPEL 73
</switch>
</onEvent>
<!-- mapping of g8 -->
<onEvent E (g7,g8)>
<invoke E (g8,g4)/>
</onEvent>
<onEvent E (g6,g8)>
<invoke E (g8,g4)/>
</onEvent>
<!-- to trigger source object g5 -->
<invoke g3/>
</scope>
</flow>
<invoke name="archive".../>
</sequence>
</process>
Figure 4.31. Code BPEL du processus "gestion des plaintes"
4.5.4.1 Exemple 2
Le but du deuxième exemple est l‟illustration de la détection des composants minimaux
qui ne sont pas bien structurés. Dans la figure ci-dessous, nous remarquons la présence de
trois composantes " composante1", " composante2" et " composante3".
Figure 4.32. BPD du processus " plusieurs_composantes "
Chapitre 4. Une approche automatique de transformation d’un diagramme BPMN vers un code BPEL 74
Si notre grammaire n‟avait pas les règles prévues pour cet effet, elle aurait considéré
une seule composante au lieu de trois. Cette composante serait l‟intégralité du diagramme.
Dans le code BPEL généré (présenté par la figure 4.32), nous remarquons la présence de trois
blocs de type "scope" (leurs attributs "name" ont les valeurs: SC0, SC1 et SC2) (voir la figure
4.33).
<process name="plusieurs-composantes">
<sequence name="SQ8">
<flow name="GTS1">
<scope name="SC0">
<!-- mapping of g1 -->
<onEvent E (g3,g1)>
<invoke E (g1,a1)/>
</onEvent>
<onEvent E (g9,g1)>
<invoke E (g1,a1)/>
</onEvent>
<!-- mapping of a1 -->
<onEvent E (g1,a1)>
<sequence>
<invoke name="a".../>
<invoke E (a1,g4)/>
</sequence>
</onEvent>
<!-- mapping of a2 -->
<onEvent E (g4,a2)>
<sequence>
<invoke name="b".../>
<invoke E (a2,g3)/>
</sequence>
</onEvent>
<!-- mapping of g3 -->
<onEvent E (a2,g3)>
<switch>
<case condition="">
<invoke E (g3,g1)/>
<case/>
<case condition="">
<invoke E (g3,g2)/>
<case/>
</switch>
</onEvent>
<!-- mapping of g4 -->
<onEvent E (a1,g4)>
<switch>
<case condition="">
<invoke E (g4,g2)/>
<case/>
<case condition="">
<invoke E (g4,a2)/>
<case/>
Chapitre 4. Une approche automatique de transformation d’un diagramme BPMN vers un code BPEL 75
</switch>
</onEvent>
<!-- mapping of g2 -->
<onEvent E (g4,g2)>
<invoke E (g2,g14)/>
</onEvent>
<onEvent E (g3,g2)>
<invoke E (g2,g14)/>
</onEvent>
<!-- to trigger source object g1 -->
<invoke g9/>
</scope>
<scope name="SC1">
<!-- mapping of g5 -->
<onEvent E (g7,g5)>
<invoke E (g5,a3)/>
</onEvent>
<onEvent E (g9,g5)>
<invoke E (g5,a3)/>
</onEvent>
<!-- mapping of a3 -->
<onEvent E (g5,a3)>
<sequence>
<invoke name="c".../>
<invoke E (a3,g8)/>
</sequence>
</onEvent>
<!-- mapping of a4 -->
<onEvent E (g8,a4)>
<sequence>
<invoke name="d".../>
<invoke E (a4,g7)/>
</sequence>
</onEvent>
<!-- mapping of g7 -->
<onEvent E (a4,g7)>
<switch>
<case condition="">
<invoke E (g7,g5)/>
<case/>
<case condition="">
<invoke E (g7,g6)/>
<case/>
</switch>
</onEvent>
<!-- mapping of g8 -->
<onEvent E (a3,g8)>
<switch>
<case condition="">
<invoke E (g8,g6)/>
<case/>
<case condition="">
<invoke E (g8,a4)/>
<case/>
Chapitre 4. Une approche automatique de transformation d’un diagramme BPMN vers un code BPEL 76
</switch>
</onEvent>
<!-- mapping of g6 -->
<onEvent E (g8,g6)>
<invoke E (g6,g14)/>
</onEvent>
<onEvent E (g7,g6)>
<invoke E (g6,g14)/>
</onEvent>
<!-- to trigger source object g5 -->
<invoke g9/>
</scope>
</flow>
<scope name="SC2">
<!-- mapping of g10 -->
<onEvent E (g12,g10)>
<invoke E (g10,a5)/>
</onEvent>
<onEvent E (g14,g10)>
<invoke E (g10,a5)/>
</onEvent>
<!-- mapping of a5 -->
<onEvent E (g10,a5)>
<sequence>
<invoke name="e".../>
<invoke E (a5,g13)/>
</sequence>
</onEvent>
<!-- mapping of a6 -->
<onEvent E (g13,a6)>
<sequence>
<invoke name="f".../>
<invoke E (a6,g12)/>
</sequence>
</onEvent>
<!-- mapping of g12 -->
<onEvent E (a6,g12)>
<switch>
<case condition="">
<invoke E (g12,g10)/>
<case/>
<case condition="">
<invoke E (g12,g11)/>
<case/>
</switch>
</onEvent>
<!-- mapping of g13 -->
<onEvent E (a5,g13)>
<switch>
<case condition="">
<invoke E (g13,g11)/>
<case/>
<case condition="">
<invoke E (g13,a6)/>
Chapitre 4. Une approche automatique de transformation d’un diagramme BPMN vers un code BPEL 77
<case/>
</switch>
</onEvent>
<!-- mapping of g11 -->
<onEvent E (g13,g11)>
<invoke E (g11,end)/>
</onEvent>
<onEvent E (g12,g11)>
<invoke E (g11,end)/>
</onEvent>
<!-- to trigger source object g10 -->
<invoke g14/>
</scope>
</sequence>
</process>
Figure 4.33. Code BPEL du processus "Plusieurs_composantes"
4.6 Conclusion
Dans ce chapitre nous avons proposé une approche automatique basée sur la méta-
modélisation et les grammaires de graphe afin de générer des codes BPEL (simplifiés) en
utilisant ATOM3.
En constate d‟après cette expérience, que les règles de grammaire peuvent être utilisées
pour un but autre que celui de transformer une règle gauche vers une règle droite. Il est tout à
fait possible de procéder à une reconnaissance d‟une partie du diagramme et générer un code
de bas niveau sur un fichier texte.
En fin de chapitre, nous avons terminés avec deux exemples illustrant la transformation
automatisée.
Conclusion générale et perspectives 77
Conclusion générale et perspectives
Dans ce mémoire nous nous sommes intéressés à la transformation des spécifications
BPMN vers le langage d‟exécution BPEL. Nous avons commencé avec une introduction des
deux langages suivie d‟une représentation des approches de transformation de graphes pour
finir avec une technique permettant la génération d‟un code BPEL à partir d‟un diagramme
BPMN.
La technique proposée est capable de générer automatiquement un code BPEL lisible
après l‟exploration des composants intégrants le diagramme BPMN qui peuvent être convertis
en code BPEL. Des règles de grammaire sont établies pour traiter les composants BPMN
considérés comme bien structurés. D‟autres règles viennent compléter le travail en traitant les
composants qui ne sont pas bien structurés pour joindre à la fin du processus, une collection
de gestionnaires d‟événements qui concrétisent une série de déclenchement interne entre ses
éléments. Ces dernières règles, permettent de traités n‟importe quel modèle BPMN, mais au
dépend d‟une réduction de lisibilité. La technique proposer est définit dans un sens qui
maximise l‟utilisation des constructions BPEL structurés et minimise l‟usage des
gestionnaires des événements. En effet, une série de règles de transformation ont été prévu
pour parcourir le diagramme BPMN (après l‟exploration des composants bien structurés) et
retrouver les composants mal-structurés les plus réduits pour relancer ensuite les règles
précédentes et vérifier l‟existence d‟un possible composant bien-structurer qui pourrait
prendre forme suite aux précédant traitements.
Dans un travail futur, nous comptons exploiter la technique des dépendances de contrôle
qu‟offre la spécification BPEL pour une meilleure visibilité du code BPEL généré. Nous
comptons également étendre la technique pour couvrir un sous-ensemble plus large
d‟éléments BPMN. Malheureusement, les structures avancées de BPMN ont une sémantique
encore pauvre qui nécessite plus de raffinement. Toutefois, il est possible d‟étendre
individuellement BPMN d‟une manière à ne pas perdre sa sémantique d‟origine, pour faire un
avancement dans ce sens et entamer une recherche anticipée en cas d‟un éventuel raffine ment
de la notation.
Nous comptons aussi réaliser une implémentation de notre approche dans d‟autres
outils de transformation de graphes comme FUJABA et VIATRA…pour comparer les
performances et essayé de tirer profit des avantages qu‟ils offrent.
Références bibliographiques 78
Références bibliographiques
[Andries99] M. Andries, G. Engels, A. Habel, B. Hoffmann, h.-J. Kreowski, s. Kuske, D.
Pump, A. Schürr et G. Taentzer, “Graph transformation for specification and programming”, Science of Computer programming, vol 34, NO°1, pages 1-54, Avril 1999.
[Atom3] AToM3 (2006). Home page: http://atom3.cs.mcgill.ca/
[BEA03] "Business Process Execution Language for Web Services" , BEA, IBM, Microsoft, SAP and Siebel, Version 1.1, May 2003. Disponible via http://www.oasis-open.org/
[Becker] J. Becker, M. Kugeler, and M. Rosemann, editors. Process Management. "A Guide for the Design of Business Processes ". Springer-Verlag, 2003.
[Blanc05] X. Blanc, "MDA en action : Ingénierie logicielle guidée par les modèles", Eyrolles,
2005.
[BPMI04] BPMI, "Business Process Modeling Notation (BPMN)" , Version 1.0 - May 3,
2004. Disponible via http://www.bpmn.org/.
[Christensen01] E. Christensen, F. Curbera, G. Meredith, S. Weerawarana, “Web Services Definition Language (WSDL) 1.1”, W3C Note, March 15, 2001. Disponible via http://www.w3.org/TR/2001/NOTE-wsdl-20010315
[Clark99a] J. Clark, S. DeRose, “XML Path Language (XPath) Version 1.0”, W3C
Recommendation, November 1999. Disponible via http://www.w3.org/TR/1999/REC-xpath-19991116
[Clark99b] J. Clark, “XSL Transformations (XSLT) Version 1.0”,W3C Recommendation,
November 16, 1999. Disponible via http://www.w3.org/TR/1999/REC-xslt-19991116 [Czarnecki03] K. Czarnecki and S. Helsen, “Classification of Model Transformation
Approaches”, OOPSLA‟03 Workshop on Generative Techniques in the Context of Model-Driven Architecture, 2003.
[Czarnecki06] K. Czarnecki, S. Helsen, “Feature-based survey of model transformation approaches”, IBM SYSTEMS JOURNAL, VOL 45, NO 3, 2006.
[DeLara02] J. De Lara and H. Vangheluwe, "AToM3: "A Tool for Multi-Formalism
Modelling and Meta-Modelling", Lecture Notes in Computer Science, No 2306, pp. 174-188, 2002.
[ElMansouri09] El Mansouri R. « Modélisation et vérification des processus métiers dans les entreprises virtuelles : une approche basée sur la transformation de graphes », Thèse de
Doctorat soutenu en 2009 à l‟université de Constantine, 140 pages. [Fischer01] L. Fischer, editor. Workow Handbook 2001, "Workow Management Coalition.
Future Strategies", Lighthouse Point, Florida, 2001. [Fujaba] FUJABA Home page: http://www.fujaba.de/
Références bibliographiques 79
[Great] GReAT http://www.escherinstitute.org/Plone/tools/suites/mic/great
[Karsai04] G. Karsai, A. Agrawal, “Graph Transformations in OMG’s Model-Driven Architecture”, Lecture Notes in Computer Science, Vol 3062, 243-259, Springer Berlin / Heidelberg, juillet 2004.
[Leymann99] F. Leymann and D. Roller. "Production Workow: Concepts and Techniques".
Prentice-Hall PTR, Upper Saddle River, New Jersey, 1999.
[Mendling06] J. Mendling, K.B. Lassen, and U. Zdun. Transformation strategies between block-oriented and graph-oriented process modelling languages. In F. Lehner, H. N¨osekabel, and P. Kleinschmidt, editors, Multikonferenz Wirtschaftsinformatik 2006. Band 2, pages 297–
312. GITO-Verlag, Berlin, Germany, 2006.
[OASIS07] "Web service business Process Execution Language Version 2.0 Specification" , OASIS Standard, 11 April 2007. Disponible via http://www.oasis-open.org/
[OMG03] “Object Management Group (OMG): MDA Guide Version 1.0.1”, 2003.
[OMG04] “Object Management Group (OMG), Model Driven Architecture (MDA)”, site Internet, http://www.omg.org/mda,2004.
[OMG06] OMG. Business Process Modeling Notation (BPMN) Version 1.0. OMG Final Adopted Specification. OMG, February 2006. Available via http://www.bpmn.org/.
[OMG09] OMG. Business "Process Modeling Notation (BPMN) Version 1.2" . OMG Final Adopted Specification. OMG, January 3, 2009. Disponible via http://www.bpmn.org/.
[Ouyang08] C. Ouyang, M. Dumas, A.H.M. ter Hofstede, and W.M.P. van der Aalst.
"Patternbased translation of bpmn process models to bpel web services". International Journal of Web Services Research, 5(1), January 2008. Disponible via : http://is.tm.tue.nl/staff/wvdaalst/publications/z9.pdf
[Prakash6] N. Prakash, S. Srivastava and S. Sabharwal. “The Classification Framework for
Model Transformation”, Journal of Computer Science 2 (2): 166-170, 2006. [Python] Python home page: http://www.python.org
[Recker06] J. Recker and J. Mendling. " On the translation between BPMN and BPEL:
Conceptual mismatch between process modeling languages ". In T. Latour and M. Petit, editors, Proceedings of Workshops and Doctoral Consortium for the 18th International Conference on Advanced Information Systems Engineering. Namur University Press,
Luxembourg, Grand-Duchy of Luxembourg, 2006.
[Rozenberg99] G. Rozenberg, "Handbook of Graph Grammars and Computing by Graph Transformation", Vol.1. World Scientific, 1999.
Références bibliographiques 80
[Sivaraman02] E. Sivaraman and M.Kamath, “On The Use of Petri Nets for Business
Process Modeling”, Proceeding of the 11th Annual Industrial Engineering Research Conference, Orlando, FL., May 2002.
[Touzi07] J.TOUZI, "Aide à la conception de Système d'Information Collaboratif support de
l'interopérabilité des entreprises". Thèse doctorat spécialisé : SYSTEMES INDUSTRIELS, Préparée au centre de Génie Industriel – Ecole des Mines d‟Albi Carmaux, soutenue le 09/11/2007.
[Van02] W.M.P. van der Aalst, A.H.M. ter Hofstede, B. Kiepuszewski, and A.P. Barros.
"Workow patterns". Technical report FIT-TR-2002-2, Faculty of IT, Queensland University of Technology, July 2002. Accessed from http://www.tm.tue.nl/it/research/patterns. To appear in Distributed and Parallel Databases, Kluwer.
[VIATRA] VIATRA Home page:
http://dev.eclipse.org/viewcvs/indextech.cgi/gmt-home/subprojects/VIATRA2/index.html [Wohed02] P. Wohed, W.M.P. van der Aalst, M. Dumas, and A.H.M. ter Hofstede. "Pattern-
Based Analysis of BPEL4WS". QUT Technical report, FIT-TR-2002-04, Queensland University of Technology, Brisbane, 2002.