Une Approche de transformation de la notation BPMN vers BPEL

91
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

Transcript of Une Approche de transformation de la notation BPMN vers BPEL

Page 1: 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

Page 2: Une Approche de transformation de la notation BPMN vers BPEL

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.

Page 3: Une Approche de transformation de la notation BPMN vers BPEL

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.

Page 4: Une Approche de transformation de la notation BPMN vers BPEL

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.

Page 5: Une Approche de transformation de la notation BPMN vers BPEL

IV

ملخص

انطشق انحانت نخحهم أوظمت انمؤسساث حعخمذ عهى عشض

ىان حشمز مخعاسف عه . الأعمال انخطبمت عهى شكم ومارج

عمم زا . BPMNعمم عهى عشض زي انىمارج عشف بـ

انخشمز عهى حشدع انماصلاث به انمحههه عذ كىمطت بذات

ف وفس انلج، نلأوظمت انخ . بانىسبت نمشاسع حطش انبشامح

حعمم بشكم حطسي طشق حعخمذ عهى حعشفاث مفصهت نلأطاس

زي انخعشفاث حذلك ومارج انـ . انخ مو محشن الأطاس بخشغها

BPMNانخشمز . عبش إضافت اندزئاث انخاصت بانخشغم

حخى مكه )انمخعاسف عه انزي عمم عهى حأث الأطاس

ىخح عما سبك أن انطشمت انبذت . BPELعشف بـ (حشغها

إنى (انىمرج)نخطش أوظمت حعمم بشكم حطسي زا مه انبذات

إنى BPMNحخمثم ف حشخمت ومارج انـ (انخشغم)انىات

نكه إعذاد سهت حمو بزي انعمهت صعب . BPELحعشفاث انـ

فشض لاعذ وحت كثشة بانمماسوت مع BPELلأن انـ

ف عمهىا زا، ومخشذ حمىت آنت حعخمذ عهى طشمت . BPMNانـ

. BPELإنى مثها ف انـBPMN ححم انىمارج نخشخمت ومارج

.، طشمت ححم انىمارجBPMN، BPEL : الكلمات الرئيسية

Page 6: Une Approche de transformation de la notation BPMN vers 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

Page 7: Une Approche de transformation de la notation BPMN vers BPEL

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

Page 8: Une Approche de transformation de la notation BPMN vers BPEL

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

Page 9: Une Approche de transformation de la notation BPMN vers BPEL

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

Page 10: Une Approche de transformation de la notation BPMN vers BPEL

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

Page 11: Une Approche de transformation de la notation BPMN vers BPEL

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.

Page 12: Une Approche de transformation de la notation BPMN vers BPEL

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.

Page 13: Une Approche de transformation de la notation BPMN vers BPEL

Chapitre 1. Processus d’entreprise BPMN 3

Chapitre 1

Processus d’entreprise BPMN

Page 14: Une Approche de transformation de la notation BPMN vers BPEL

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.

Page 15: Une Approche de transformation de la notation BPMN vers BPEL

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

Page 16: Une Approche de transformation de la notation BPMN vers BPEL

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.

Page 17: Une Approche de transformation de la notation BPMN vers BPEL

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

Page 18: Une Approche de transformation de la notation BPMN vers BPEL

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.

Page 19: Une Approche de transformation de la notation BPMN vers BPEL

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

Page 20: Une Approche de transformation de la notation BPMN vers BPEL

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

Page 21: Une Approche de transformation de la notation BPMN vers BPEL

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

Page 22: Une Approche de transformation de la notation BPMN vers BPEL

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

Page 23: Une Approche de transformation de la notation BPMN vers BPEL

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

Page 24: Une Approche de transformation de la notation BPMN vers BPEL

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

Page 25: Une Approche de transformation de la notation BPMN vers BPEL

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 :

Page 26: Une Approche de transformation de la notation BPMN vers BPEL

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,

Page 27: Une Approche de transformation de la notation BPMN vers BPEL

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

Page 28: Une Approche de transformation de la notation BPMN vers BPEL

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

Page 29: Une Approche de transformation de la notation BPMN vers BPEL

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.

Page 30: Une Approche de transformation de la notation BPMN vers BPEL

Chapitre 2. Langage d’exécution BPEL 20

Chapitre 2

Langage d’exécution BPEL

Page 31: Une Approche de transformation de la notation BPMN vers 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

Page 32: Une Approche de transformation de la notation BPMN vers BPEL

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

Page 33: Une Approche de transformation de la notation BPMN vers BPEL

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

Page 34: Une Approche de transformation de la notation BPMN vers BPEL

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.

Page 35: Une Approche de transformation de la notation BPMN vers BPEL

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

Page 36: Une Approche de transformation de la notation BPMN vers BPEL

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

Page 37: Une Approche de transformation de la notation BPMN vers BPEL

Chapitre 2. Langage d’exécution BPEL 27

<if name="isOrderBiggerThan5000Dollars">

<condition>

<!-- XPATH expression -->

$order &gt; 5000

</condition>

<invoke name="calculateTenPercentDiscount" ... />

<elseif>

<condition>

<!-- XPATH expression -->

$order &gt; 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 &gt; 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 &gt; 3

</condition>

</repeatUntil>

Figure 2.11. Activité « repeatUntil »

Page 38: Une Approche de transformation de la notation BPMN vers BPEL

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 »

Page 39: Une Approche de transformation de la notation BPMN vers BPEL

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>

Page 40: Une Approche de transformation de la notation BPMN vers BPEL

Chapitre 2. Langage d’exécution BPEL 30

$creditVariable/value &lt; 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) :

Page 41: Une Approche de transformation de la notation BPMN vers BPEL

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 &lt; 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 ».

Page 42: Une Approche de transformation de la notation BPMN vers BPEL

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

Page 43: Une Approche de transformation de la notation BPMN vers BPEL

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>

Page 44: Une Approche de transformation de la notation BPMN vers BPEL

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

Page 45: Une Approche de transformation de la notation BPMN vers BPEL

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.

Page 46: Une Approche de transformation de la notation BPMN vers BPEL

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.

Page 47: Une Approche de transformation de la notation BPMN vers BPEL

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

Page 48: Une Approche de transformation de la notation BPMN vers BPEL

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

Page 49: Une Approche de transformation de la notation BPMN vers BPEL

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.

Page 50: Une Approche de transformation de la notation BPMN vers BPEL

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

Page 51: Une Approche de transformation de la notation BPMN vers BPEL

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

Page 52: Une Approche de transformation de la notation BPMN vers BPEL

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.

Page 53: Une Approche de transformation de la notation BPMN vers BPEL

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,

...

Page 54: Une Approche de transformation de la notation BPMN vers BPEL

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

Page 55: Une Approche de transformation de la notation BPMN vers BPEL

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.

Page 56: Une Approche de transformation de la notation BPMN vers BPEL

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

Page 57: Une Approche de transformation de la notation BPMN vers BPEL

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.

Page 58: Une Approche de transformation de la notation BPMN vers BPEL

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

Page 59: Une Approche de transformation de la notation BPMN vers BPEL

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

Page 60: Une Approche de transformation de la notation BPMN vers BPEL

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.

Page 61: Une Approche de transformation de la notation BPMN vers BPEL

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.

Page 62: Une Approche de transformation de la notation BPMN vers BPEL

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

Page 63: Une Approche de transformation de la notation BPMN vers 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).

Page 64: Une Approche de transformation de la notation BPMN vers BPEL

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

Page 65: Une Approche de transformation de la notation BPMN vers BPEL

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

Page 66: Une Approche de transformation de la notation BPMN vers BPEL

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:

Page 67: Une Approche de transformation de la notation BPMN vers BPEL

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)

Page 68: Une Approche de transformation de la notation BPMN vers BPEL

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

Page 69: Une Approche de transformation de la notation BPMN vers BPEL

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

Page 70: Une Approche de transformation de la notation BPMN vers BPEL

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

Page 71: Une Approche de transformation de la notation BPMN vers BPEL

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)

Page 72: Une Approche de transformation de la notation BPMN vers BPEL

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

Page 73: Une Approche de transformation de la notation BPMN vers BPEL

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

Page 74: Une Approche de transformation de la notation BPMN vers BPEL

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.

Page 75: Une Approche de transformation de la notation BPMN vers BPEL

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.

Page 76: Une Approche de transformation de la notation BPMN vers BPEL

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

Page 77: Une Approche de transformation de la notation BPMN vers BPEL

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

Page 78: Une Approche de transformation de la notation BPMN vers BPEL

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

Page 79: Une Approche de transformation de la notation BPMN vers BPEL

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 à

Page 80: Une Approche de transformation de la notation BPMN vers BPEL

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 :

Page 81: Une Approche de transformation de la notation BPMN vers BPEL

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

Page 82: Une Approche de transformation de la notation BPMN vers BPEL

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

Page 83: Une Approche de transformation de la notation BPMN vers BPEL

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 "

Page 84: Une Approche de transformation de la notation BPMN vers BPEL

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

Page 85: Une Approche de transformation de la notation BPMN vers BPEL

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

Page 86: Une Approche de transformation de la notation BPMN vers BPEL

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

Page 87: Une Approche de transformation de la notation BPMN vers BPEL

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.

Page 88: Une Approche de transformation de la notation BPMN vers BPEL

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.

Page 89: Une Approche de transformation de la notation BPMN vers BPEL

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/

Page 90: Une Approche de transformation de la notation BPMN vers BPEL

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.

Page 91: Une Approche de transformation de la notation BPMN vers BPEL

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.