THESE DOCTORAT EN SCIENCES APPLIQUEES ... - Toubkal

mi
Université Mohamed V- Souissi Rabat
Ecole Nationale Supérieure d’Informatique
et d’Analyse des Systèmes
Numéro d’ordre : ----
UFR : Systèmes d’Information Métiers,
Multimédia et Mobiles (SI3M)
-ENSIAS-
-ENSIAS-
THESE
-ENSIAS-
pour l‟obtention du Diplôme de
DOCTORAT EN SCIENCES APPLIQUEES
Spécialité : Informatique
Présentée par
Adil KENZI
Sujet de thèse :
Ingénierie des Systèmes Orientés Services
Adaptables : Une Approche Dirigée par les Modèles
Soutenue le 16/10/2010 à 10H00 devant le jury composé de :
Président :
M. Abdelhak MOURADI Professeur à l‟ENSIAS de Rabat, Maroc
Rapporteurs :
M. Djamal BENSLIMANE Professeur à l‟Université Claude Bernard Lyon 1, France
M. Bouchaib BOUNABAT Professeur à l‟ENSIAS de Rabat, Maroc
M. Bernard COULETTE Professeur à l‟Université de Toulouse II-Le Mirail, France
Examinateur :
M.Mahmoud NASSAR Professeur Habilité à l‟ENSIAS de Rabat, Maroc
Directeur de thèse :
M.Abdelaziz KRIOUILE Professeur à l‟ENSIAS de Rabat, Maroc

A ma mére et mon pére
A ma tante Khadija
A mes sœurs et fréres

Remerciements
Les travaux présentés dans le cadre de ce mémoire de thèse ont été réalisés au laboratoire
Systèmes d‟Information multimédia et mobile (SI2M) à l‟Ecole Nationale Supérieure
d‟Informatique et d‟Analyse des Systèmes (ENSIAS) de Rabat.
Tout d‟abord, je tiens à remercier vivement mon directeur de thèse Monsieur Abdelaziz
KRIOUILE, Professeur à l‟ENSIAS, pour sa sympathie, son écoute, son soutien, sa
disponibilité et sa patience. Je le remercie également pour ses relectures minutieuses de ce
mémoire.
Je remercie également Madame Bouchra El Asri, Professeur Assistant à l‟ENSIAS pour
m‟avoir co-encadré durant cette thése. Je la remercie aussi pour ses conseils précieux, sa
disponibilité, son soutien ainsi que pour les nombreuses discussions que nous avons eues sur
le thème de cette thèse.
Je tiens aussi à remercier Monsieur Abdelhak MOURADI de m‟avoir fait l‟honneur de
présider le jury de ma thèse.
J‟adresse également mes vifs remerciements à Monsieur Djamal BENSLIMANE, Professeur
à l‟université Claude Bernard Lyon1, Monsieur Bernard COULETTE, Professeur à
l‟université de Toulouse II et Monsieur Bouchaib BOUNABAT, Professeur à l‟ENSIAS,
d‟avoir accepté de rapporter ma thèse. Je les remercie également pour les remarques et
conseils prodigués.
J‟exprime ma profonde gratitude à Monsieur Mahmoud NASSAR, Professeur Habilité à
l‟ENSIAS pour les nombreuses discussions techniques que nous avons eues. Je le remercie
également pour ses conseils et ses remarques tout au long de ces années. Je le remercie aussi
pour avoir accepté d‟être examinateur de cette thèse.
J‟adresse également mes remerciements à Monsieur Rdouan FAIZI, Professeur à l‟ENSIAS
pour ses nombreuses relectures et ses corrections des différentes publications rédigées en
Anglais.
Je tiens à remercier tous ceux qui m‟ont aidé et soutenu durant cette thèse, et plus
particulièrement ma famille. J‟adresse mes vifs remerciements à mes frères Jilali et Najib de
m‟avoir tant soutenu aussi bien matériellement que moralement. Je tiens aussi à remercier
mon frère Abdelkarim de m‟avoir soutenu et encouragé et surtout de m‟avoir orienté vers des
études en informatiques. Je remercie également mon frère Hatim qui est loin de la Faculté
d‟Informatique de l‟Université Technique de Dortmund, de m‟avoir encouragé et soutenu et
surtout de n‟avoir ménagé aucun effort pour me fournir la meilleure documentation dans le
domaine.
J‟adresse également mes chaleureux remerciements à tous les amis et collègues que j‟ai
côtoyés durant les années de cette thèse. Leurs conseils, leur amitié et leur bonne humeur
m‟ont beaucoup encouragé durant mes travaux.
Je remercie tous ceux qui ont contribué de près ou de loin à la réalisation de ce travail.

Résumé
De nos jours, les Systèmes d‟information occupent une position centrale dans la stratégie de
l‟entreprise. Leur capacité de communication et d‟intégration, leur agilité ainsi que leur
adaptation aux utilisateurs constituent des défis majeurs pour la compétitivité des entreprises.
Pour relever ces défis, l‟ingénierie logicielle est marquée particulièrement par l‟émergence de
deux nouveaux paradigmes : SOC (Service Oriented Computing) et CAC (Context-aware
Computing). Le paradigme SOC a pour objectif de faire face aux problèmes de
l‟interopérabilité et de l‟intégration des SI ainsi que de leur agilité. Le paradigme CAC vise à
relever le défi de l‟adaptabilité des SI. L‟adoption rapide et massive de ces deux paradigmes,
a fait naitre de nouveaux challenges, plus particulièrement le challenge de l‟ingénierie des
systèmes orientés services adaptables.
L‟objectif de cette thèse est de proposer une approche d‟ingénierie dirigée par les modèles
pour le développement des systèmes orientés services adaptables. Une telle approche définit
principalement : (i) un profil UML 2.0 appelé VSoaML (View based Service Oriented
Architecture Modeling Language) (ii) un processus de développement et (iii) un outil logiciel
associé à VSoaML pour la génération automatique de code appelé VSoaMLTool.
Le profil VSoaML a pour objectif la modélisation et la spécification des systèmes orientés
services adaptables indépendamment des standards (WSDL, BPEL4WS, etc.) et des
plateformes d‟implémentation (J2EE, dotNet, etc.). Ce profil se base essentiellement sur le
concept de service multivue comme une entité de modélisation fondamentale pour le
développement des systèmes orientés services adaptables et sur un ensemble de stéréotypes
permettant la modélisation des systèmes orientés services adaptables. La particularité du
service multivues réside dans la représentation des besoins et des spécificités des utilisateurs
finals tout au début du cycle de développement des systèmes orientés services.
Le processus de développement associé au profil VSoaML définit les phases, les activités et
les artefacts nécessaires pour la transformation des exigences métiers en des services flexibles
et adaptables. Il permet l‟identification, la spécification et l‟implémentation des services
multivues à partir des besoins métier spécifiés via les diagrammes des cas d‟utilisation.
L‟objectif principal d‟un tel processus est l‟élaboration des modèles à différents niveaux
d‟abstraction ainsi que leur transformation pour cibler différentes plateformes
d‟implémentation. Après l‟élaboration des modèles métiers en se basant sur le profil VSoaML

et sur le processus de développement y associé, l‟outil VSoaMLTool permet la génération
automatique de code en se basant principalement sur deux transformations définies dans le
cadre MDA ciblant différentes plateformes technologiques. Chaque transformation a été
définie en deux étapes. La première étape consiste en la spécification des correspondances
entre les métamodèles source et cible. La deuxième étape consiste en la définition des
transformations en se basant sur le langage ATL comme langage de transformation de
modèles. Les transformations définies visent essentiellement la génération de
l‟implémentation et de la description de chaque service.
Mots clés : UML, VSoaML, Service multivues, Adaptabilité, MDD/MDA, SOA/Services
Web, Systémes d‟Information Distribués.

Table des matières
Introduction générale ........................................................................................ 1
I. Etat de l’art ................................................................................................. 7
II.
I.1. Introduction .............................................................................................................. 7
I.2. Systèmes Orientés Services (SOS) : concepts et définitions .................................... 8
I.3. SOS : Approches de modélisation ............................................................................ 9
I.3.1. Approches à base de « Service Component »................................................................ 10
I.3.2. Approches à base de « Service Component Architecture » (SCA) ............................... 12
I.3.3. Approches à base de profils UML ................................................................................. 14
I.3.4. Discussion ...................................................................................................................... 20
I.4. SOS : Concepts d‟adaptation .................................................................................. 20
I.4.1. Concept d‟adaptation : les Vues .................................................................................... 21
I.4.1.1 Vues à base de l‟adaptation par rôles .................................................................... 21
I.4.1.2 Vues à base de l‟adaptation contextuelle .............................................................. 23
I.4.1.3 Discussion ............................................................................................................. 26
I.4.2. Concept d‟adaptation : la variabilité de service ............................................................. 27
I.4.2.1 Description de l‟approche ..................................................................................... 27
I.4.2.2 Discussion ............................................................................................................. 30
I.4.3. Concept d‟adaptation : la différenciation de service ..................................................... 30
I.4.3.1 Description de l‟approche ..................................................................................... 30
I.4.3.2 Discussion ............................................................................................................. 33
I.5. SOS : technologies d‟adaptation ............................................................................ 34
I.5.1. AWSDL et CWSDL ...................................................................................................... 34
I.5.2. CBPEL et VXBPEL ...................................................................................................... 35
I.5.3. Discussion ...................................................................................................................... 35
I.6. SOS : Approches d‟adaptation dirigées par les modèles ........................................ 36
I.6.1. Concepts et définitions .................................................................................................. 37
I.6.2. Approches MDA de développement des SOS ............................................................... 39
I.6.2.1 PIM (UML) vers services Web ............................................................................. 39
I.6.2.2 PIM(EDOC) vers services web ............................................................................ 45
I.6.3. Approches MDA d‟adaptation des SOS ....................................................................... 53
I.6.3.1 Approches de gestion des propriétés non-fonctionnelles ..................................... 53
I.6.3.2 Approches de gestion des droits d‟accès............................................................... 56
I.6.3.3 Approches de gestion de la qualité de services ..................................................... 59
I.6.3.4 Approches d‟adaptation au contexte .................................................................... 61
I.6.3.5 Discussion ............................................................................................................. 62
I.7. Synthèse générale ................................................................................................... 63
VSoaML : Un profil UML de modélisation des systèmes orientés
services adaptables .......................................................................................... 69

III.
II.1. Introduction ............................................................................................................ 69
II.2. Exemple illustratif : Le système d‟enseignement à distance .................................. 71
II.3. Le concept de service multivues ............................................................................ 72
II.3.1. Le concept de vue ...................................................................................................... 73
II.3.2. Le service multivues.................................................................................................. 74
II.4. Les couches d‟abstraction d‟un SOS Adaptable .................................................... 78
II.5. Le profil VSoaML .................................................................................................. 82
II.5.1. Le profil VSoaML : Vue d‟ensemble ........................................................................ 82
II.5.2. VSoaML : les stéréotypes ......................................................................................... 88
II.5.2.1 Le stéréotype Service ............................................................................................ 88
II.5.2.2 Le stéréotype Message .......................................................................................... 90
II.5.2.3 Le stereotype MessageAttachment ....................................................................... 91
II.5.2.4 Le stéréotype Specification ................................................................................... 92
II.5.2.5 Le stéréotype MVService ..................................................................................... 94
II.5.2.6 Le stéréotype MVServiceSpecification ................................................................ 96
II.5.2.7 Le stéréotype Collaboration .................................................................................. 98
II.5.2.8 Le stéréotype ServiceChannel ............................................................................. 100
II.5.2.9 Le stéréotype Requester ...................................................................................... 101
II.5.2.10 Le stéréotype MVServiceInterface ..................................................................... 102
II.5.2.11 Le stéréotype BaseServiceInterface .................................................................... 103
II.5.2.12 Le stéréotype ViewServiceInterface ................................................................... 105
II.5.2.13 Le stéréotype Provider ........................................................................................ 106
II.5.2.14 Le stéréotype ServiceOperation .......................................................................... 107
II.5.2.15 Le stéréotype ServiceDomain ............................................................................. 108
II.5.3. Exemple illustratif DLS : Couches d‟abstraction ................................................... 109
II.6. Conclusion ............................................................................................................ 116
Processus de Développement Dirigé par les Modèles des Systèmes
Orientés Services Adaptables ....................................................................... 117
III.1. Introduction .......................................................................................................... 117
III.2. Processus de développement des systèmes orientés services : phases, activités et
artefacts ............................................................................................................................ 118
III.3. Processus de développement MDA : phases, activités et artefacts ...................... 121
III.3.1. Les types de modèles et de transformation de MDA .............................................. 121
III.3.1.1 Computation Independent Model (CIM) ............................................................ 121
III.3.1.2 Platform Independent Model (PIM).................................................................... 121
III.3.1.3 Platform Specific Model (PSM) ......................................................................... 122
III.3.2. Le processus de développement dans le contexte de MDA : .................................. 124
III.4. Processus MDA de développement des SOS adaptables ..................................... 126
III.4.1. Phase 1: Elaboration des modèles des cas d‟utilisation........................................... 128
III.4.2. Phase 2: Identification des services par acteur ........................................................ 129
III.4.3. Phase 3 : Spécification des interfaces de services ................................................... 133
III.4.4. Phase 4 : Fusion des modèles visuels ...................................................................... 135
III.4.5. Phase 5: Transformation des modèles et génération de code .................................. 137
III.5. Conclusion ............................................................................................................ 139

IV. VSoaMLTool : Outil de génération de code automatique .............. 140
IV.1. Introduction .......................................................................................................... 140
IV.2. VSoaMLTool : modules et fonctionnalités .......................................................... 141
IV.3. VSoaMLTooL : Transformation de modèle et génération de code...................... 143
IV.4. Le PIM (VSoaML) de l‟étude de cas DLS ........................................................... 144
IV.5. Le métamodèle du profil VSoaML ...................................................................... 147
IV.6. Du PIM (VSoaML) vers des descriptions (MVWSDL)....................................... 148
IV.6.1.1 Le Multiview WSDL pour la description des services multivues....................... 148
IV.6.1.2 Du PIM(VSoaML) vers PSM(MVWSDL) ......................................................... 151
IV.6.1.3 Du PSM (MVWSDL) vers le code (MVWSDL)............................................... 154
IV.7. Du PIM (VSoaML) vers PSM (JaxRPC) ............................................................. 157
IV.7.1. Le métamodèle JAX-RPC ...................................................................................... 158
IV.7.2. Spécification des correspondances entre le métamodèle de VSoaML et le
métamodèle JAX-RPC ............................................................................................................. 159
IV.7.3. Les règles de transformation ................................................................................... 160
IV.7.4. Le code java généré à partir des PIM(VSoaML)..................................................... 162
IV.8. VSoaMLTool : déploiement selon l‟architecture SOA ........................................ 166
IV.9. Conclusion ............................................................................................................ 168
Conclusion générale et perspectives ............................................................ 169
Liste des publications .................................................................................... 172
Références ....................................................................................................... 174

Table des figures
Figure 1–Métamodèle du “service component” (Zhang et al., 2006) ........................................... 11
Figure 2–Composant SCA ............................................................................................................ 13
Figure 3–Modélisation à base de SCA du système de l‟agence de voyage .................................. 13
Figure 4–Métamodèle du profil UML (Johsnston et al., 2006). ................................................... 15
Figure 5–Métamodèle du profil PIM4SOA (López-Sanz et al., 2007) ......................................... 17
Figure 6 –Diagramme de classe et les rôles de l‟application «video central » (Fink et al, 2003) . 22
Figure 7–Déclaration des vues en VPL (Fink et al., 2003). .......................................................... 23
Figure 8–Métamodéle de vue (Maamar et al., 2005) .................................................................... 24
Figure 9–Script de transformation des documents WSDL ........................................................... 26
Figure 10–Types de variabilité de services (Chang et al., 2007b) ................................................ 28
Figure 11–Concept de service différencié (Tao et al. , 2008) ....................................................... 32
Figure 12–Conception à base des services différenciés de l‟application OPS) (Tao et al., 2007b) .
....................................................................................................................................................... 33
Figure 13–Types de transformations : modèle vers modèle et modèle vers code (Bezevin et al.,
2004). ............................................................................................................................................ 40
Figure 14–Modèle PIM de l‟étude de cas « agence de voyage » (Bezevin et al., 2004). ............. 41
Figure 15–Correspondances UML/WSDL (Bezevin et al., 2004) ................................................ 42
Figure 16–Correspondances UML/Java (Bezevin et al., 2004) .................................................... 43
Figure 17–Méthodologie de développement des SOS (Gronmo et al., 2004a). ........................... 44
Figure 18–Correspondance UML/WSDL ..................................................................................... 45
Figure 19–Processus de transformation du framework défini (Yu et al , 2007) ........................... 46
Figure 20–Métamodèle « Document Model » (Yu etal ., 2007) ................................................... 47
Figure 21–Métamodèle WSDL (Yu et al., 2007) ......................................................................... 48
Figure 22–Métamodèle Choreography (YU et al., 2007) ............................................................. 49
Figure 23–Métamodèle BPEL (Yu et al., 2007) ........................................................................... 50
Figure 24–Profil “Document Model” (Patrasciuo, 2004) ............................................................ 51
Figure 25–Métamodèle du XML schéma ..................................................................................... 52
Figure 26–Métamodèle WSDL (Patrsciou et al., 2004) ............................................................... 52
Figure 27–Profil «Extra- functional Property » (Ortiz et al., 2006b) ........................................... 54
Figure 28–Stéréotype « Extra-functional property » (Ortiz et al., 2006b) .................................... 54
Figure 29–Service TouristService (Ortiz et al., 2006a) ............................................................... 55
Figure 30–Processus de transformation ATL (Ortiz et al., 2006a) ............................................... 55
Figure 31–Métamodèle cible SOAP (Ortiz et al., 2006a) ............................................................. 56
Figure 32–Métamodèle Policy (Ortiz et al, 2006a) ...................................................................... 56
Figure 33–Métamodèle de SECTET-UML(Hafner et al.,2009) ................................................... 58
Figure 34–Métamodèle XACML .................................................................................................. 59
Figure 35–Processus de développement dirigé par les modèles (D‟ambrogio, 2007) .................. 60
Figure 36–Métamodèle ContextUML (Maamar et al., 2006) ....................................................... 61
Figure 37–Diagramme des cas d‟utilisation du DLS .................................................................... 72
Figure 38–Modèle d‟interaction des services avec leurs clients ................................................... 75
Figure 39–Métamodèle de l‟interface MVServiceInterface ......................................................... 76
Figure 40–Interface de service multivues du service multivues «Formation » ............................ 77

Figure 41–Couches fonctionnelles d‟un SOS (Papazoglou, 2007) ............................................... 79
Figure 42–SOS adaptable : Couches d‟abstraction ....................................................................... 81
Figure 43–Stéréotypes de VSoaML et leurs métaclasses de base UML2.0 ................................. 83
Figure 44–Métamodèle de VSoaML ............................................................................................ 84
Figure 45–Stéréotype Service ....................................................................................................... 89
Figure 46–Service Agenda ............................................................................................................ 89
Figure 47–Stéréotype message ..................................................................................................... 91
Figure 48–Exemple d‟un message ................................................................................................ 91
Figure 49–Stéréotype MessageAttachment .................................................................................. 92
Figure 50–Stéréotype specification............................................................................................... 93
Figure 51–Exemple de stéréotype Specification........................................................................... 94
Figure 52–Stéréotype MVService................................................................................................. 95
Figure 53–Exemple de service multivues ..................................................................................... 95
Figure 54–Stéréotype MVServiceSpecification ........................................................................... 97
Figure 55–Exemple de MVServiceSpecification.......................................................................... 97
Figure 56–Stéréotype Collaboration ............................................................................................. 98
Figure 57–Exemple de collaboration de services ......................................................................... 99
Figure 58–Stéréotype Channel .................................................................................................... 101
Figure 59–Stéréotype Requester ................................................................................................. 102
Figure 60–Exemple de Requester ............................................................................................... 102
Figure 61–Stéréotype MVServiceInterface ................................................................................ 103
Figure 62–Exemple de MVServiceInterface .............................................................................. 103
Figure 63–Stéréotype baseServiceInterface ................................................................................ 104
Figure 64–Exemple de BaseServiceInterface ............................................................................. 104
Figure 65–Stéréotype ViewServiceInterface .............................................................................. 105
Figure 66–Exemple de ViewServiceInterface ............................................................................ 106
Figure 67–Stéréotype Provider ................................................................................................... 107
Figure 68–Stéréotype ServiceOperation ..................................................................................... 108
Figure 69–Exemple de serviceOperation .................................................................................... 108
Figure 70–Stéréotype ServiceDomain ........................................................................................ 109
Figure 71–Modèle BPMN du cas d‟utilisation « Assurer Formation ». ..................................... 110
Figure 72–Modèle BPMN du cas d‟utilisation « Suivre formation» ....................................... 111
Figure 73–Modèle des services multivues du DLS .................................................................... 114
Figure 74–Extrait du modèle d‟information du système d‟Enseignement à Distance............... 115
Figure 75–Phases du cycle de vie méthodologique (Papazoglou et al., 2006) ........................... 119
Figure 76–Types de transformations MDA (Blanc, 2005) ......................................................... 123
Figure 77–Processus de développement MDA des systèmes logiciels ..................................... 125
Figure 78–Processus de développement des systèmes orientés services multivues dans le cadre
de l‟approche MDA ................................................................................................................... 127
Figure 79–Cas d‟utilisation du DLS ........................................................................................... 129
Figure 80–Scénario associé au cas d‟utilisation «assurer Formation» associé à l‟acteur ........... 131
Figure 81–Identification des services associés à l‟acteur « Enseignant » .................................. 132
Figure 82–Identification des services associés à l‟acteur «Administrateur» ............................. 133
Figure 83–Identification des services associés à l‟acteur «Etudiant » ........................................ 133
Figure 84–PIM raffiné associé à l‟acteur Etudiant .................................................................... 134

Figure 85– PIM raffiné associé à l‟acteur Administrateur......................................................... 135
Figure 86–Extrait du résultat de l‟étape de fusion du service Formation ................................... 136
Figure 87-Phase de transformation de modèle et génération du code ........................................ 138
Figure 88–Modules de VSoaMLTool ......................................................................................... 142
Figure 89–Processus de génération de code à partir des PIMs (VSoaML) ................................ 143
Figure 90–Extrait des interfaces de service multivues des services multivues du DLS ............ 146
Figure 91–Métamodèle VSoaML ............................................................................................... 147
Figure 92–Structure d'un document WSDL ................................................................................ 149
Figure 93–Métamodèle MVWSDL ........................................................................................... 151
Figure 94–Code ATL de la règle de transformation viewinterface2WSDL ............................... 153
Figure 95–Code ATL de la règle de transformation BaseInterface2WSDL ............................... 154
Figure 96–Requête de génération de code MVWSDL ............................................................... 155
Figure 97–Code ATL pour la génération de code MVWSDL .................................................... 155
Figure 98–Code MVWSDL généré ........................................................................................... 156
Figure 99–Processus de génération des implémentations des services à partir des PIMs
(VSoaML) ................................................................................................................................... 157
Figure 100–Métamodèle JAX-RPC ........................................................................................... 158
Figure 101- Règle de transformation Domain2Package ............................................................. 161
Figure 102–Règle de transformation MVService2jaxrpcClass .................................................. 161
Figure 103–Règle de transformation Operation2Method ......................................................... 162
Figure 104–Règle de transformation viewinterface2interface ................................................... 162
Figure 105–Requête de génération de code Java ........................................................................ 163
Figure 106–Code ATL pour la génération de code java ............................................................. 164
Figure 107–Code java généré à partir du PIM(VSoaML) .......................................................... 165
Figure 108–Architecture de déploiement des services multivues ............................................... 167
Liste des tableaux
Tableau 1–Stéréotypes et métaclasse de base ............................................................................... 16
Tableau 2–Profil PIM4SOA ......................................................................................................... 17
Tableau 3–Stéréotypes du profi l SoaML ..................................................................................... 19
Tableau 4–Correspondances Model Document/Web service (YUet al., 2007) ............................ 47
Tableau 5–Correspondances CCA/WSDL (Yu et al., 2007) ....................................................... 48
Tableau 6–Stéréotypes du profil SECTET-UML (Alam et al., 2008) .......................................... 57
Tableau 7–Synthèse des différentes approches étudiées .............................................................. 65
Tableau 8–Stéréotypes du profil VSoaML ................................................................................... 88
Tableau 9–Services multivues du Systéme d‟Enseignement à distance .................................... 145
Tableau 10–Correspondances VSoaML/MVWSDL .................................................................. 152
Tableau 11–Spécification des correspondances VSoaML/JAX-RPC ........................................ 160

Liste des abréviations
Abréviation
API
ATL
BPEL
CAC
DTD
EMF
GMF
GUI
HTML
HTTP
IDE
J2EE
MDA
MDD
MOF
OCL
OMG
PIM
PSM
QVT
SOC
SOS
SoaML
SOA
SOAP
UDDI
UML
WSDL
XMI
XML
Signification
Application Programming Interface
Atlas Transformation Language
Business Process Execution Language
Context aware Computing
Data Type Definition
Eclipse Modelling Framework
Graphical Modelling Framework
Graphical User Interfaces
HyperText Markup Language
HyperText Transfer Protocol
Integrated Development Environment
Java 2 Platform Enterprise Edition
Model Driven Architecture
Model Driven Development
Meta-Object Facility
Object Constraint Language
Object Management Group
Platform Independent Model
Platform Specific Model
Query/View/Transform
Service Oriented Computing
Service Oriented Systems
Service Oriented Architecture Modeling Language
Service Oriented Architecture
Simple Object Access Protocol
Universal Description, Discovery and Integration
Unified Modeling Language
Web Service Description Language
XML Metadata Interchange
Extensible Markup Language

1
Introduction générale
Introduction générale
Les systèmes d‟information occupent aujourd‟hui une position centrale dans la stratégie de
l‟entreprise. La capacité de communication et d‟intégration de ces systèmes, leur réactivité aux
changements métiers et technologiques ainsi que leur facilité d‟utilisation et d‟adaptation
constituent des défis majeurs pour la compétitivité des entreprises. Pour relever ces défis,
l‟ingénierie logicielle n‟a cessé de fournir de nouveaux paradigmes et de nouvelles technologies.
Actuellement, l‟ingénierie logicielle est marquée particulièrement par l‟émergence de deux
nouveaux paradigmes : SOC (Service Oriented Computing) et l‟Informatique Sensible au
Contexte (Context-aware Computing). Les travaux menés au sein de cette thèse s‟inscrivent dans
l‟étude et l‟exploitation de ces paradigmes selon une approche dirigée par les modèles (MDA-
Model Architecture) pour répondre à certaines attentes des systèmes d‟information en pleine
évolution.
En effet, SOC (Papazoglou et al., 2003) (Huhns et al., 2005) permet le développement des
systèmes d‟information distribués, flexibles, agiles et interopérables. SOC s‟appuie
principalement sur le concept de service qui se définit comme une entité informatique
indépendante des plateformes, auto-contenue et autonome permettant le support de la
composition des applications distribuées en couplage faible tout en optimisant les coûts et les
délais (Papazoglou, 2007). SOC se base sur l‟architecture orientée service (SOA-Service
Oriented Architecture) dont l‟objectif est d‟organiser un ensemble d‟applications isolées, en un
ensemble de services interconnectés, chacun étant accessible à travers des interfaces et des
protocoles de communication standards. SOA définit une approche permettant de répondre aux
besoins de développement des applications en couplage faible en se basant sur les standards tout
en restant indépendant de tout protocole et de toute plateforme. La technologie des services web
(Gustavo et al., 2003) constitue une implémentation de l‟architecture SOA. Elle définit un
ensemble de standards et de protocoles fournissant ainsi une infrastructure assurant des
fonctionnalités de transport, de messagerie (SOAP), de description (WSDL) (Chinnici et al .,
2001) de découverte et de publication (UDDI) (Clement et al., 2004) et de composition de

2
Introduction générale
services (BPEL4WS) (Andrews et al., 2003).
En parallèle avec l‟émergence du SOC, l‟informatique Sensible au Contexte (Dey, 2000) a été
proposée dans l‟objectif d‟adapter des applications et des systèmes logiciels aux différents
contextes d‟utilisation. Ces derniers couvrent toutes les informations pouvant être utilisées pour
caractériser la situation d‟une entité. Une entité peut être une personne, un lieu, ou un objet qui
peut être pertinent pour l‟interaction entre l‟utilisateur et l‟application, y compris l‟utilisateur et
l‟application (Dey, 2000). Bien qu‟il n‟existe pas une définition unique de ce qui est un contexte
d‟utilisation, les caractéristiques des terminaux utilisés pour accéder aux systèmes et celles du
réseau et surtout le profil de l‟utilisateur constituent les éléments clés du contexte d‟utilisation.
Par ailleurs, l‟OMG a proposé l‟architecture dirigée par les modèles MDA (MDA-Model Driven
Architecture) (OMG, 2003) pour le développement et la maintenance des systèmes
d‟informations distribués et complexes. MDA propose une nouvelle manière de spécification des
systèmes informatiques basée sur différents perspectives du même système. En premier lieu, les
fonctionnalités et le comportement d‟un système sont décrits sans tenir compte des
caractéristiques technologiques. Ensuite, la spécification des fonctionnalités et du comportement
est utilisée pour créer les systèmes informatiques conformément à une technologie spécifique.
La première phase dans une approche MDA, est effectuée par un modèle indépendant d‟une
plate-forme technologique (PIM - Platform Independent Model) alors que la deuxième phase est
effectuée par un modèle spécifique à une plate-forme technologique (PSM - Platform Specific
Model). Le passage du PIM vers le PSM constitue un aspect important de cette approche et se
fait en se basant sur la spécification et la définition d‟un ensemble de règles de transformation.
La séparation claire et explicite entre les modèles indépendants et dépendants d‟une plate-forme
permet d‟apporter plusieurs avantages au développement des systèmes logiciels. En effet, la
logique métier est protégée contre les incessantes évolutions et l‟apparition des nouvelles
technologies. De plus, elle apporte une plus grande réactivité quand les systèmes informatiques
doivent évoluer pour utiliser une autre technologie ou atteindre d‟autres exigences. L‟approche
MDA vise comme objectif de rendre les systèmes informatiques plus indépendants d‟une
technologie spécifique en fournissant la portabilité et l‟interopérabilité au niveau des modèles.

3
Introduction générale
Cette approche permet également la maîtrise de la complexité du développement de logiciels
grâce à l‟utilisation des modèles comme éléments centraux pour le développement des systèmes
logiciels.
Dans le but de gérer la complexité du développement des systèmes orientés services, d‟une part,
et la prise en compte de l‟utilisateur, d‟autre part, il est nécessaire de fournir une méthodologie
définissant concepts, Formalisme/Notation, Processus et outils. En effet, le développement des
systèmes à base de service est généralement basé sur la technologie des services web qui fournit
une infrastructure à base de standards incluant les standards WSDL, SOAP, UDDI et BPEL4WS
permettant la description, l‟invocation, la découverte/publication et la composition de services.
Certes, les technologies et les standards sont très importants pour le développement de tels
systèmes, mais ils sont insuffisants pour le développement des systèmes d‟entreprise complexes
et distribués vu que les différents stakeholders (e.g., les analystes métiers, les architectes, les
utilisateurs finals, les développeurs, etc.) n‟ont pas forcément des connaissances techniques. Le
challenge principal qui se pose aujourd‟hui est la spécification des systèmes orientés services
indépendamment des technologies caractérisées par leur bas niveau d‟abstraction. Dans cette
optique, plusieurs travaux de recherche ont été proposés. Pour sa part, L‟OMG est aujourd‟hui
dans la phase de standardisation d‟un profil UML appelé SoaML(OMG, 2009) pour la
modélisation des systèmes orientés services.
L‟objectif principal de cette thèse est de définir une approche d‟ingénierie pour le
développement des systèmes orientés services adaptables aux différents types d‟utilisateur, dans
le cadre de l‟approche MDA. Une telle approche définit (i) un profil UML appelé VSoaML
(View based Service oriented architecture Modeling Language) pour la modélisation et la
spécification des systèmes orientés services adaptables (ii) un processus de développement des
systèmes orientés services adaptables dans le cadre de l‟approche MDA (iii) un outil logiciel
dirigé par les modèles, appelé VSoaMLTool, permettant la génération de code à partir des
modèles métiers de haut niveau via un ensemble de règles de transformations.
VSoaML (Kenzi et al., 2009) permet de modéliser un système orienté service adaptable à un haut
niveau d‟abstraction indépendamment des plates-formes d‟implémentation (J2EE, dotNet, etc) et
des standards de la technologie des services web (SOAP, WSDL, UDDI, BPEL4WS, etc.).

4
Introduction générale
VSoaML est centré utilisateur et il se base fondamentalement sur le concept de service multivues
(Kenzi et al., 2008) comme une entité de modélisation de première classe capable de représenter
les besoins et les spécificités des utilisateurs suivant leurs profils. Le service multivues est une
nouvelle entité de modélisation qui fournit, en plus des interfaces de services, des interfaces
multivues qui se caractérisent par leur flexibilité et leur adaptabilité aux différents acteurs
interagissant avec le service. Le service multivues permet la capture des exigences des
utilisateurs et de leurs spécificités tout en séparant leurs préoccupations fonctionnelles. Pour ce
faire, le service multivues fournit/requiert des interfaces capables de décrire les capacités du
service suivant le profil de l‟utilisateur interagissant avec le service. Une telle interface permet la
représentation des fonctionnalités de service accessible seulement à un type particulier
d‟utilisateur.
Pour identifier les services multivues, les spécifier et les développer, nous avons défini un
processus de développement dans le cadre de l‟approche MDA (Kenzi et al., 2008) (Kenzi et al.,
2009). Ce processus définit les phases, les activités et les artéfacts pour transformer les exigences
métier en termes d‟un ensemble de services flexibles et adaptables. La spécificité d‟un tel
processus consiste en l‟identification des services en partant des modèles des cas d‟utilisation et
en se basant sur un ensemble de règles de refactoring capables de faire les correspondances entre
les cas d‟utilisations et les services (correspondance binaire, fusion/décomposition, etc). Ce
processus de développement qui s‟inscrit dans le cadre de l‟approche MDA permet l‟élaboration
des modèles et de gérer la transition d‟un modèle à un autre via des transformations de modèles.
Ainsi, après l‟élaboration des modèles métier à base de service multivues, nous avons défini
deux transformations pour la génération de code :
La première transformation permet la génération de la description de chaque service multivues
composant le PIM d‟un système donné. En effet, nous avons défini une légère extension du
standard WSDL pour la description de service multivues, appelé MVWDL. Cette extension de
WSDL permet la représentation en XML aussi bien des interfaces des services que les
informations concernant les acteurs interagissant avec le service. Pour permettre l‟automatisation
de la génération du code du MVWSDL, nous avons défini un ensemble de règles de
transformation en utilisant le langage ATL comme langage de transformation de modèles.

5
Introduction générale
La deuxiéme transformation concerne la génération du code constituant l‟implémentation de
chaque service multivues selon la plateforme cible J2EE.
Chaque transformation de modèles a été décomposée en deux étapes : la première concerne la
spécification de correspondances. La deuxième permet la définition des transformations en se
basant sur le langage de transformation de modèle ATL. En fait, la spécification de
correspondances vise à spécifier les correspondances entre les éléments des métamodèles source
et cible, et la définition de transformations permet de décrire en détail et d‟exécuter les étapes de
la transformation d‟un modèle en un autre modèle en respectant la spécification de
correspondances. Cette approche va dans le sens même de la vision de l‟OMG pour développer
les systèmes informatiques à savoir la séparation des préoccupations. En fait, une spécification
de correspondances peut être vue comme un PIM et une définition de transformations comme un
PSM. Les deux décrivent la même chose mais à des niveaux différents.
Une fois générées la description de chaque service multivues et son implémentation, nous avons
illustré comment faire l‟adaptation des services en prenant en compte les acteurs interagissant
avec le service suivant l‟architecture SOA.
Présentation de ce mémoire
Le travail réalisé est présenté dans ce mémoire selon une structure de quatre chapitres.
Le premier chapitre présente l‟état de l‟art du domaine. Dans un premier temps, nous nous
intéressons plus particulièrement aux approches de modélisation et de conception des systèmes
orientés service. Ensuite, nous présentons les différentes approches permettant l‟adaptation des
systèmes orientés services. Après, nous décrivons les approches MDA de développement des
systèmes orientés services ainsi que les approches MDA pour la prise en compte de l‟utilisateur
des systèmes orientés services. Enfin, nous concluons ce premier chapitre par une synthèse de
l‟état de l‟art en identifiant les fondements de chaque approche.
Le deuxième chapitre expose le profil VSoaML à base des services multivues en identifiant les
stéréotypes de ce profil ainsi que son métamodèle. Chaque stéréotype a été décrit tout en
spécifiant les contraintes y associées. Enfin, nous illustrons la faisabilité de ce profil en se basant

6
Introduction générale
sur une étude de cas concernant le système d‟enseignement à distance.
Le troisième chapitre est dédié à la définition du processus de développement des systèmes
orientés services associé au profil VSoaML. Ce processus définit les phases, les activités et les
artéfacts pour l‟identification, la spécification et l‟implémentation des services multivues.
Le quatrième chapitre présente les aspects applicatifs de ce travail. Il décrit premièrement le
fonctionnement de l‟outil support à VSoaML. Cet outil se base notamment sur les principes et les
standards de l‟ingénierie dirigée par les modèles pour la génération de code à partir des modèles
métiers de haut niveau.
Enfin, nous concluons ce rapport en récapitulant les points forts de notre approche, les aspects
traités et les perspectives de ce travail.

7
Etat de l’art
I. Etat de l’art
I.1.
Introduction
SOC (Service-Oriented Computing) a émergé récemment comme un nouveau paradigme
informatique prometteur pour le développement rapide et à moindre coût des applications
distribuées, interopérables et évolutives (Papazoglou, 2007). SOC se base principalement sur
l‟élément Service et sur l‟architecture orientée service SOA (Service Oriented Architecture).
SOC propose une nouvelle manière de développement des systèmes distribués en se basant
exclusivement sur la composition de services pour la construction d‟applications logicielles
distribuées à grande échelle, évolutives, interopérables et facilement composables.
SOC a introduit plusieurs défis aux différents acteurs s‟intéressant à la construction des
systèmes à base de services. Plus particulièrement, le défi de l‟ingénierie de tels systèmes
(Papazoglou et al., 2008) qui consiste en la définition des approches de modélisation, des
processus, des techniques et outils pour faciliter la construction de ces systèmes en optimisant les
coûts et les délais. La définition de ces approches est d‟une importance capitale pour la réussite
de projets de développement des SOSs (Service Oriented Systems).
Par ailleurs, la prise en compte de l‟utilisateur et de son environnement est d‟une importance
capitale pour la construction de systèmes logiciels surtout avec l‟émergence de l‟informatique
sensible aux contextes (Dey, 2000). Cette dernière insiste sur la prise en compte de l‟utilisateur
final pour le développement de systèmes logiciels.
L‟objectif de ce premier chapitre est de :
(1) étudier les différentes approches de modélisation des systèmes orientés services
(2) étudier certaines approches visant la prise en compte de l‟utilisateur dans les systèmes
orientés services
(3) étudier les approches MDA de développement des systèmes orientés services qui prennent en

8
Etat de l’art
compte de l‟utilisateur des ces systèmes.
Ce chapitre est structuré en plusieurs sections. Après la présente introduction, la deuxième
section a pour objectif de définir brièvement les concepts et les termes en relation avec le
paradigme SOC tels que : le concept de service, l‟architecture orientée service (SOA), un
système orienté service ainsi que la technologie des services Web. La troisième section traite les
approches de modélisation des systèmes orientés services. La quatrième section traite les
approches à même de permettre la prise en compte des différentes dimensions des besoins des
utilisateurs. La cinquième section met l‟accent sur les approches MDA pour le développement
des systèmes orientés services. Enfin, nous clôturons ce chapitre en dressant un bilan comparatif
des différentes approches étudiées.
I.2.
Systèmes Orientés Services (SOS) : concepts et définitions
Dans le cadre de cette thèse, nous définissons SOA comme un style d‟architecture permettant le
développement des applications en couplage faible à travers des standards, et indépendamment
des protocoles et plateformes. L‟architecture orientée services définit trois acteurs : le
fournisseur de services, l‟annuaire de services et le client de service. Elle définit aussi trois
opérations standards : find, bind et publish (Papazoglou, 2007). Le fournisseur de services qui
possède l‟implémentation de service procède à la publication de la description du service dans un
annuaire de services. Ce dernier contient l‟ensemble des descriptions de services publiés par les
différents fournisseurs de services. Il fournit les moyens nécessaires pour la publication et la
découverte des services. Le client de service pour un besoin donné, recherche dans l‟annuaire le
service qui lui convient.
Nous définissons aussi un Système Orienté Service (SOS par la suite) comme étant un système
qui se constitue principalement des services et se base sur l‟architecture SOA comme un style
architectural.
La technologie des services web constitue une implémentation prometteuse de l‟architecture
SOA. Un service Web est défini selon le W3C (W3C, 2004):
«Un service Web est un système logiciel identifié par un identificateur uniforme de ressources

9
Etat de l’art
(URI), dont les interfaces publiques et les liens (binding) sont définis et décrits en XML. Sa
définition peut être découverte dynamiquement par d‟autres systèmes logiciels. Ces autres
systèmes peuvent ensuite interagir avec le service Web d‟une façon décrite par sa définition, en
utilisant des messages XML transportés par des protocoles Internet ».
La technologie des services web se base principalement sur les protocoles et les standards
suivants : SOAP, WSDL et UDDI.
SOAP est le protocole d‟échange de messages permettant d‟interagir avec les
services Web. Ces messages sont délivrés sous la forme de documents XML
qui sont structurés par : une entête contenant les informations non
fonctionnelles liées au message telles que la sécurité ainsi qu‟un corps
contenant les données métiers du domaine de l‟application. SOAP est
générique et extensible puisque les autres spécifications sont définies par
dessus en définissant par exemple de nouveaux entêtes (sécurité, garantie de
livraison). Ce protocole n‟est pas lié à un type particulier de protocole de
transport de données, mais il est fréquent qu‟il soit associé à HTTP ou SMTP.
WSDL est le standard basé sur XML permettant de décrire les services Web.
Il permet de générer des documents structurés en deux parties : une partie
abstraite décrivant l‟interface fonctionnelle du service en termes d‟opérations
et de messages, ainsi qu‟une partie concrète qui contient les détails des
protocoles à utiliser et de l‟adresse physique des opérations.
UDDI est une spécification technique définissant un registre permettant la
publication et la découverte des services Web. Un registre UDDI est un
registre basé sur XML qui contient des informations à propos d‟entités
d‟affaire fournissant des services Web ainsi que des métadonnées concernant
ces services (informations techniques ou légales). En outre, UDDI spécifie
plusieurs API pour interagir avec le registre, demander ou publier un service.
I.3.
SOS : Approches de modélisation
Aujourd'hui, le monde industriel et académique s‟intéresse de plus en plus à la modélisation des
systèmes orientés services indépendamment des plates-formes technologiques ou des langages de

10
Etat de l’art
programmation. La modélisation est d‟une importance capitale pour le développement des SOSs
(Papazoglou et al., 2008) dans la mesure où elle définit les éléments de modélisation capables de
représenter de tels systèmes à un haut niveau d‟abstraction.
Dans cette section, nous illustrons différentes approches de modélisation des systèmes orientés
services telles que les approches à base du « service component » (Stojanovic, 2004) (Zhang,
2006). Nous présentons aussi le Service Component Architecture (SCA) (Biesiegel et al. 2005)
comme un ensemble de spécifications pour la modélisation des systèmes orientés services
indépendamment des technologies et des standards. Finalement, nous présentons des travaux
définissant des profils UML pour l‟analyse/conception des systèmes orientés services (Johnston,
2006) (Amir et al., 2004) (López Sanz et al., 2007) (Ermagan et al., 2007) (Benatallah et al.,
2009).
I.3.1. Approches à base de « Service Component »
Zhang et al. (Zhang et al., 2006) ont introduit un framework de modélisation des systèmes
orientés services. Ce framework se base sur le concept de « service component » permettant
l‟analyse/conception des systèmes orientés service. Le « service component » est traité comme
étant une entité de modélisation de première classe permettant de capturer des unités
fonctionnelles relatives à des services abstraits. Le «service component » possède plusieurs
interfaces découvrables et accessibles à travers le réseau. Chaque « service component » est
autonome, auto-descriptif et peut exposer et délivrer des fonctionnalités à d‟autres «service
component » à travers des interfaces sans se soucier des détails d‟implémentations.
Le «service component » est utilisé pour la description de la structure d‟un système loin de toute
technologie ou plate-forme (intergiciel, système d‟exploitation, architecture matérielle, etc.).
La figure 1 illustre le métamodèle du « service component ». Le métamodèle est présenté dans le
but d‟assurer l‟interopérabilité et l‟intégration des systèmes orientés service. Le méta-modèle du
« service component » se compose des éléments suivants :
Specification déclare les interfaces du service et les contrats du service. Une
déclaration d‟interfaces spécifie les ports du service et possède des propriétés
fonctionnelles et non fonctionnelles et les contraintes associées. Le contrat du

11
Etat de l’art
service guide le consommateur à utiliser le service. Il spécifie le rôle que le
« service component » doit jouer et il inclut les informations de configuration
qui spécifient les versions des services, les pré-conditions, les post-conditions
et les conditions de coordination. Ainsi, elle facilite la modification, le
remplacement, et l‟évolution du service.
Figure 1–Métamodèle du “service component” (Zhang et al., 2006)

12
Etat de l’art
Contents représente l’implémentation du composant service avec un langage
donné (C, C#, Java, etc.). Les détails de cette implémentation sont invisibles au
consommateur de ce service ainsi qu‟à l‟environnement extérieur.
Le contexte définit l‟environnement dans lequel le service existe.
La chorégraphie permet d‟indiquer si le service component est un service
composite ou pas. Le patron de composition est fourni dans la spécification de
la chorégraphie.
Dans le même objectif que (Zhang et al, 2006), (Stojanovic et al., 2004) proposent une approche
pour la modélisation et la conception des solutions SOA. Cette approche se base aussi
principalement sur le concept « service component» et sur des extensions apportées au langage
UML.
Le « component service » est défini dans le cadre de cette approche, comme une entité logicielle
autonome qui réalise des services à travers des interfaces de façon contractuelle sans exposer sa
réalisation interne.
Pour la modélisation et la conception des solutions SOA, deux types de « service component »
de différente granularité ont été définis :
Business Service Component (BSC) qui est un type de « service component »
fournissant des services et des opérations significatifs, perçus avec une valeur
mesurable dans le contexte Business. Il permet de réaliser des parties d‟un
processus métier en coordination et en coopération avec d‟autres BSC pour
réaliser des objectifs business plus compliqués.
Atomic Service Component (ASC) qui est un type de « service component »
fournissant des opérations de granularité fine n‟ayant pas une réelle valeur
Business. Chaque ASC collabore et coordonne avec d‟autres ASC pour fournir
un comportement métier représenté par un BSC qui les encapsule.
I.3.2. Approches à base de « Service Component Architecture » (SCA)
Le Service Component Architecture (SCA) (Biesegel et al., 2005) est un ensemble de
spécifications décrivant un modèle de composant pour développer des applications SOA. Les

13
Etat de l’art
applications basées sur SCA sont en fait un assemblage de composants. Chaque composant
modélise une partie de la logique métier et peut dépendre de services fournis par d‟autres
composants.
L‟objectif principal de SCA est de décrire des applications SOA en se focalisant sur la logique
métier indépendamment des standards, des plateformes et des langages utilisés (i.e. Java, C#,
BPEL, etc). Ainsi, avec SCA, les services se traitent tous de la même manière quelles que soient
leurs caractéristiques techniques. Le fait de pouvoir s'abstraire des considérations techniques des
applications, simplifie énormément leur conception en utilisant les services.
Le modèle de SCA proposé, se focalise essentiellement sur les interfaces pour représenter les
fonctionnalités du composant fournies à d‟autres composants. Il se base aussi sur les références
pour désigner les interfaces requises que le composant peut utiliser pour répondre aux besoins de
ses utilisateurs. Figure 2 présente le modèle de composant SCA.
Service
Component
Figure 2–Composant SCA
références
La Figure 3 présente un modèle d‟un système d‟une agence de voyages, représenté par quatre
CarReservation
BookTravel
HotelReservation
AirReservation
Figure 3–Modélisation à base de SCA du système de l’agence de voyage
services avec leurs interfaces fournies et leurs références. Ce système est représenté sans tenir

14
Etat de l’art
compte des détails des plates-formes technologiques qui sont prises ultérieurement dans le cycle
de développement des systèmes orientés services à base de SCA.
I.3.3. Approches à base de profils UML
UML est un langage de modélisation destiné à un grand nombre de domaines. Pour l‟adapter à
un domaine particulier, il est nécessaire de définir des extensions (stéréotypes, valeurs étiquetées,
contraintes) structurées et regroupées dans ce qu‟on appelle un profil. Dans le contexte de SOA,
plusieurs profils ont été proposés pour la spécialisation d‟UML en vue de la modélisation des
applications SOA. Dans cette section, nous présentons principalement trois profils : le profil
défini par (Johnston et al., 2006), le profil défini par (López-Sanz et al., 2007) ainsi que le profil
SoaML proposé par l‟OMG.
Johnston et al. (Johsnston et al., 2006) ont proposé un profil UML2.0 pour la modélisation des
services et des solutions orientées services. Ce profil fournit un langage commun pour la
modélisation des services. Il définit aussi un ensemble d‟activités le long du cycle de vie du
développement tout en fournissant un ensemble de vues des services aux différents stakeholders.
De telles vues permettent de modéliser une perspective du système correspondant à un point de
vue donné (stakeholder). Ainsi, le profil fournit les fonctionnalités nécessaires à l‟architecte pour
organiser les services le plus tôt dans le cycle de développement en utilisant les partitions
logiques pour la description de l‟ensemble de services à l‟échelle de l‟entreprise. Cette vue est
raffinée par les concepteurs qui ont pour mission le développement des spécifications de services
aussi bien structurelles que comportementales. Les spécifications de services jouent un rôle de
contrat entre les fournisseurs de services et les clients de services. La vue message permet aux
concepteurs de réutiliser les modèles d‟informations pour la définition des données manipulées
par le service. La Figure 4 présente les différents stéréotypes définis ainsi que leurs relations.

15
Etat de l’art
Figure 4–Métamodèle du profil UML (Johsnston et al., 2006).
Le tableau 1 présente chaque stéréotype, sa description ainsi que leurs métaclasses sources
UML 2.0 :
Nom du stéréotype Metaclasse Commentaire
Message Class Ce stéréotype définit les
structures de données
échangées. Il spécifie aussi la
propriété “Encoding” pour
spécifier l‟encodage SOAP ou
RPC.
Message Attachment Property Ce stéréotype indique si le
contenu d‟un message est un
attachement ou pas
Service Port Ce stéréotype permet de
déterminer le couple
specification/binding
Service Channel Connector Ce stéréotype décrit une
connexion entre services.
Service Collaboration Collaboration Ce stéréotype permet la
modélisation
du
comportement d‟un ensemble

16
Etat de l’art
de services qui coopèrent.
Service Consumer Classifier Ce stéréotype désigne un
consommateur de service.
Service Gateway Port Ce stéréotype permet la
modélisation d‟une connexion
entre partitions
Service Partition Node Ce stéréotype définit un
groupement logique ou
physique d‟un ensemble de
services
Service Provider
Class
Ce stéréotype permet la
modélisation d‟un fournisseur
d‟un ou de plusieurs services
Service Specification Class, Interface Ce stéréotype permet la
spécification des opérations et
leurs messages associés qui
définissent le service.
Tableau 1–Stéréotypes et métaclasse de base
Dans le même objectif (López-Sanz et al., 2007) (López Sanz et al. 2008) ont proposé des profils
UML pour la modélisation des systèmes orientés services. Ainsi, Lopez-Sanz et al. (López-Sanz
et al., 2007) ont défini plusieurs stéréotypes permettant la spécification des systèmes orientés
services. Le tableau 2 présente les stéréotypes définis, les métaclasses UML de base, les concepts
définis ainsi que leurs sémantiques.
Notation Concept associé Métaclasse UML de Sémantique
base
Outer provider Package Un fournisseur de
service externe
Business contract Dependency Le contrat établi
entre fournisseurs de
services
System Front-End Classifier Les composants qui
interagissent avec
l‟utilisateur
Composite service Classifier Un service composé
d‟autres services
Basic service Classifier Ce stereotype
représente une
fonctionnalité
basique

17
Etat de l’art
Orchestrator service Classifier Ce stéréotype joue le
rôle d‟un
orchestrateur dans
une chorégraphie
Service contract Association Class Ce stéréotype joue le
rôle d‟un connecteur
entre service
Restriction clause Classifier Les pre/post
conditions qui
doivent être vérifiées
Service operation Property Une fonctionnalité
atomique d‟un
service
Tableau 2–Profil PIM4SOA
La figure 5 présente le métamodèle du profil défini. Ce métamodèle définit la structure des
différents stéréotypes ainsi que leurs associations.
Figure 5–Métamodèle du profil PIM4SOA (López-Sanz et al., 2007)
Pour sa part, L‟OMG est dans la phase de la standardisation d‟un profil UML appelé SoaML
(Service oriented architecture Modeling Language) (OMG, 2009) dans l‟objectif de la
modélisation des applications SOA. SoaML s'intéresse à l'architecture et non pas aux composants

18
Etat de l’art
techniques sous-jacents. Son objectif est de fournir aux utilisateurs du langage UML, les
moyens de modéliser une architecture orientée services -comprenant des notions de clients et de
fournisseurs de services, de collaboration de services ainsi que la notion de contrats. Le profil
SoaML définit plusieurs stéréotypes. Le tableau 3 illustre les stéréotypes SoaML ainsi que leur
sémantique associé.
Stéréotype Métaclasse UML Sémantique
Agent Class Agent est une classification
d‟entités autonomes qui
s‟adaptent et interagissent
avec leur environnement. Les
agents en SoaML sont les
participants fournissant et
utilisant les services.
Collaboration Collaboration Collaboration permet la
description d'un patron
d'interaction entre les
différents rôles.
Attachment Property Attachment désigne une partie
d‟un Message qui est un
attachement.
CollaborationUse CollaborationUse CollaborationUse montre
comment une collaboration
(ServiceContracts et
ServiceArchitectures) est
accomplie.
MessageType Class, DataType, Signal MessageType permet la
spécification des informations
échangées entre les
fournisseurs et les
consommateurs de services.
Expose Dependency Expose désigne une
dépendance qui indique si un
Capability doit être exposé ou
pas.
Milestone Comment Milestone permet d‟indiquer
le progrès dans les
comportements ayant une
durée considérable.
Participant Class participant désigne un
fournisseur ou un
consommateur de service

19
Etat de l’art
Provider Interface, Class Provider modélise le type
d‟un fournisseur de services.
Consumer Interface, Interface Consumer modélise un type
d‟un consommateur de
service.
Request Port Request désigne un port qui
définit un point de connexion
à travers lequel un participant
répond à ses besoins via la
consommation des services
fournis par d’autres
fournisseurs.
Service Port Service représente un port qui
définit le point de connexion
par lequel un participant offre
ses capacités à ses clients.
Capability Class Capability dénote une
capacité d‟un service donné.
Service Contract Collaboration ServiceContract est la
formalisation de l‟échange
d‟information, des biens et des
obligations entre les parties
définissant un service.
Service Interface Class, Interface ServiceInterface fournit la
définition d‟un service. Il
définit la spécification de
l‟interaction «Service» ou
«Request»
ServiceChannel Connector ServiceChannel désigne un
chemin de communication
entre requêtes et services
Services Architecture Collaboration ServiceArchitecture définit
une vue de haut niveau d‟une
architecture orientée service
qui définit comment un
ensemble de participants
travaillent ensemble pour
atteindre un objectif donné en
fournissant et utilisant des
services.
Tableau 3–Stéréotypes du profi l SoaML

20
Etat de l’art
I.3.4. Discussion
Les approches de modélisation des SOS jouent un rôle très important dans la construction des
SOS en définissant les concepts et les formalismes/notations nécessaires pour la description de
tels systèmes indépendamment des technologies et des standards. Elles permettent de décrire les
aspects structurels et dynamiques des SOS, ce qui facilite la compréhension, la vérification la
validation et la simulation de tels systèmes. Tout de même, le développement des SOSs se base
principalement sur la technologie des services web qui définit un ensemble de technologies
(XML, etc.) et de standards (e.g., WSDL, UDDI, BPEL4WS, etc.). Cependant, pour faciliter et
rationaliser le développement de tels systèmes, il faut les décrire à un haut niveau d‟abstraction
vu la diversité des profils des acteurs (les analystes métier, les architectes, les développeurs, les
utilisateurs finals, etc.) s‟intéressant à leur développement sans en comprendre nécessairement
les détails technologiques.
Par ailleurs, les différentes approches de modélisation proposées ne permettent pas de rendre
productifs les modèles élaborés. Ces derniers permettent de représenter des SOS à différents
niveaux d‟abstraction mais ne facilitent pas la génération automatique des artefacts d‟un SOS
(Description de services WSDL, Implémentation de services en Java ou C#, Composition de
services BPEL, Fichiers de configuration, etc.) en se basant sur des outils logiciels appropriés.
Aussi, ces différentes propositions ne prennent pas en compte l’aspect multidimensionnel des
besoins des acteurs interagissant avec le service. En effet, un service en SOC interagit avec
plusieurs clients de services. Chaque client de service a un profil donné avec des besoins
différents. Ainsi, les approches de modélisation doivent tenir compte de cette réalité pour mieux
la représenter.
I.4.
SOS : Concepts d’adaptation
L‟utilisateur final joue un rôle crucial dans le développement des systèmes d‟information
orientés services. En effet, c‟est lui qui exploite et utilise le système. Pour prendre en compte ses
besoins, plusieurs approches définissant différents mécanismes et concepts, ont été proposées.
Ainsi, nous présentons dans cette section, en premier lieu, les approches utilisant les vues pour la
prise en compte des différents aspects des besoins des utilisateurs tels que l‟utilisation des vues

21
Etat de l’art
pour l‟adaptation des services au contexte de l‟utilisateur (Benslimane et al., 2005), la gestion de
ses droits d‟accès (Fink et al., 2003) et l‟adaptation des services aux types des utilisateurs de
service (Fuchs, 2004). Dans un deuxième lieu, nous présentons les approches qui se basent sur la
variabilité de service pour la prise en compte de l‟utilisateur final (Chang et al., 2007a). En
troisième lieu, nous présentons les approches permettant l‟adaptation de services se basant sur le
concept de service différencié (Tao et al., 2007a) (Tao et al., 2008). Finalement, nous présentons
autres approches qui définissent des extensions aux standards de la technologie des services web
pour la prise en compte de l‟utilisateur final (lopez-velasco et al., 2005) (Kouadri Mostefaoui,
2006) .
I.4.1. Concept d’adaptation : les Vues
L‟objectif de cette section est de présenter les différents travaux combinant entre le concept de
vue et celui de service pour la prise en compte de l‟utilisateur final. Généralement, les vues sont
largement utilisées dans plusieurs domaines de l‟informatique. Elles sont utilisées dans les
SGBD (Rafanelli et al. 2003), la gestion des connaissances, les workflows, les approches
orientées objets, etc. Aussi, notre équipe a déjà développé des méthodes en se basant sur le
concept de vue telles que la méthode VBOOM (Kriouile, 1995) ou l‟approche VUML (Nassar et
al., 2005). De même, pour accompagner l‟évolution de l‟ingénierie logicielle vers les approches
à base de composants (Szyperski, 2002), un modèle du composant multivues (El Asri, 2005) a
été proposé.
Dans cette section, nous nous intéressons tout particulièrement aux approches se basant sur les
vues pour la prise en compte de l‟utilisateur final pour le développement des SOSs.
I.4.1.1
Vues à base de l’adaptation par rôles
Les vues ont été largement utilisées pour l‟adaptation des services aux rôles des utilisateurs.
Dans cette optique, Torsten et al. (Fink et al. 2003) proposent une approche à base de vue pour la
gestion des droits d‟accès de chaque acteur interagissant avec un service donné. Cette approche
se base sur un modèle appelé VBAC (View Based Access Control) et sur un langage déclaratif
permettant de spécifier les différentes vues. Nous commençons par présenter l‟exemple
d‟application avant d‟expliquer les concepts de base de cette approche.

22
Etat de l’art
(1) L’exemple d’application
« Video central » est une application qui repose sur un ensemble de services web développé par
IBM (IBM, 2002). Cette application définit six services web représentés par le diagramme de
classe UML dans la figure 6 suivante.
CustomerRentedList
processAddRequest(loginBusinessGuid,loginBusinessPassword,userID,titleIDList):int
processQueryRequest(loginBusinessID,loginBusinessPassword,customerGuid):String
WishList
processAddRequest(businessGuid,registrationKey,customerGuid,titleList):int
processQueryRequest(businessGuid,registrationKey,customerGuid,maxNumRecords):String
processRemoveRequest(businessGuid,registrationKey,customerGuid,titleList):int
MovieSearch
processRequest():String
Customer
CustomerInfraction
processAddRequest(loginBusinessID,loginBusinessPassword,firstName,lastName):int
processQueryRequest(loginBusinessID,loginBusinessPassword,customerGUID,beginDate,endDate):String
BusinessRegistration
processRegisterRequest():int
Staff
CustomerRegistration
getCustomerGUID(loginBusinessID,loginBusinessPassword,firstName,lastName):int
processRegisterRequest(loginBusinessID,loginBusinessPassword,firstName,lastName):int
Figure 6 –Diagramme de classe et les rôles de l’application «video central » (Fink et al, 2003)
« Video central » se compose de six services web représentés sous forme de diagramme de
classes UML : CustomerRentedList, MovieSearch, BusinessRegistartion, CustomerRegistration
et CustomerInfraction. Ce diagramme illustre aussi les rôles qui interagissent avec les différents
services web : Customer et Staff. Chaque rôle a ses propres besoins sur les services. En d‟autres
termes, chaque acteur a ses droits d‟accès sur un service donné. En effet, dans le cadre de cet
exemple, le rôle Customer ne peut pas exécuter les opérations : processRegisterRequest, ou
getCustomerGUID réservées seulement au rôle Staff.
(2) Le modèle VBAC et le langage VPL
VBAC est un modèle de contrôle d‟accès conçu pour supporter la conception et la gestion des
politiques de contrôle d‟accès dans les systèmes distribués. VBAC (Fink et al.,2003) est une
extension du modèle de contrôle d‟accès à base de rôles (RBAC) par les concepts de vue et de
schéma. Une vue regroupe les permissions ou les interdictions pour la gestion de l‟accès à des
objets (un fichier, une méthode,…). Chaque vue est associée à des rôles. Un sujet (un utilisateur,

23
Etat de l’art
un processus,…) peut accéder à un objet s‟il a un rôle auquel une vue est assignée. Si la vue
n‟existe pas pour un rôle donné, le sujet ne peut pas accéder à l‟objet en question. Un schéma
spécifie les assignations dynamiques aux différents rôles. Ces assignations sont effectuées
automatiquement à chaque invocation d‟une opération donnée.
Dans le but de spécifier les politiques VBAC, un langage déclaratif appelé VPL (View Policy
Language) a été défini. VPL est utilisé pour spécifier les rôles, les vues et les schémas. Les rôles
sont définis dans une déclaration en utilisant le mot clé role. Les schémas sont définis en utilisant
le mot clé schema.
La clause role définit les différents rôles dans la politique ainsi que leurs vues initiales. La figure
7 montre la définition des rôles pour l‟application «Video central».
role customer
staff holds BusinessRegistration
view BusinessRegistration controls BusinessRegistration restricted to staff
{ processRegisterRequest }
view CustomerRegistration controls CustomerRegistration restricted to staff
{
getCustomerGUID(loginBusinessID, , , ) if caller = loginBusinessID
processRegisterRequest(loginBusinessID, , , ) if caller = loginBusinessID
}
view CustomerInfraction controls CustomerInfraction restricted to staff {
processAddRequest( loginBusinessID, , ) if caller = loginBusinessID
processQueryRequest( loginBusinessID, , , , ) if caller = loginBusinessID
}
Figure 7–Déclaration des vues en VPL (Fink et al., 2003).
La figure 7 montre la déclaration de deux rôles : Client et Staff. Le rôle staff possède initialement
la vue BusinessRegistration (mot clé holds). Le rôle Client n‟a initialement aucune vue. Une vue
VPL définit les autorisations à un sous-ensemble d‟opérations d‟un seul service web. Une vue est
référencée par la clause de contrôle. Par exemple, la vue BusinessRegistration donne la
permission pour invoquer l‟opération processRegisterRequest du service web
BusinessRegistration. Une Vue VPL peut être statiquement restreint à certains rôles.
I.4.1.2
Vues à base de l’adaptation contextuelle
Pour adapter les services aux types de leurs utilisateurs ou à leur contexte, plusieurs approches
ont adopté les vues. Ainsi, (Maamar et al. 2005) (Benslimane et al. 2005) présentent une

24
Etat de l’art
approche à base de vues pour faire le suivi de l‟exécution des services web composites et pour
prendre les mesures correctives dans le cas où l‟exécution de services ne se conforme pas aux
préférences des utilisateurs. Le concept de vue est défini dans cette approche comme étant un
instantané dynamique de la spécification des services web composites selon un contexte donné.
La vue permet de mettre en évidence ce qui est attendu selon les préférences des utilisateurs de
ce qui s‟est produit effectivement selon les contraintes de l‟environnement.
La spécification de service composite est effectuée par un diagramme de services (Service Chart
Diagram) (SCD) (Maamar et al., 2003). Un SCD est une extension du diagramme d‟état UML en
y ajoutant les informations du contexte de service ainsi que la localisation et le temps pour mieux
manipuler les préférences des utilisateurs.
Le contexte associé à une vue donnée se décompose en trois types d‟informations :
Les informations du contexte de l‟utilisateur (U-Context) telles que sa
localisation, ses activités,
Les informations du contexte d‟un service web (WS-Context) telles que ses
capacités et ses participations dans d‟autres compositions.
Les informations du contexte de la composition de services (CS-context) telles
que l‟état d‟exécution d‟une composition de services.
La spécification de services composite est soit initiale ou dérivée. Un concepteur crée une
spécification initiale qui inclut la chronologie de services et les dépendances entre eux. Le
concepteur obtient une spécification dérivée en appliquant une vue, qui est associée à un
contexte donné, sur la spécification initiale. La spécification dérivée peut être, à son tour, initiale
ou dérivée .La figure 8 présente synthétiquement le métamodèle de vue :
Figure 8–Métamodéle de vue (Maamar et al., 2005)

25
Etat de l’art
Par ailleurs, et dans le but d‟adapter les services web à des environnements hétérogènes et à
différents groupes d‟utilisateurs, Fuchs (Fuchs, 2004) adopte le concept de vue pour la définition
d‟un mécanisme appelé «service view». Un «service view» est une définition WSDL spécifiée
pour un groupe d‟utilisateurs à l‟instar de la définition des vues dans les systèmes de gestion de
bases de données où une vue est définie comme une combinaison d‟informations à partir de
plusieurs tables associées à un utilisateur donné. Cette définition WSDL décrit un ensemble
d‟opérations du service, leurs adresses, et le contenu de leurs messages suivant le type des
utilisateurs interagissant avec le service. Dans ce sens, deux types d‟utilisateurs ont été
identifiés : les utilisateurs internes et les utilisateurs externes. En effet, ces deux types
d‟utilisateurs ont leur propre description WSDL.
Les fournisseurs de services doivent créer des descriptions de service qui s‟adaptent aux types
de clients. Pour cela, Fuchs définit une architecture se basant sur deux couches : la couche
« service views » et la couche « rule groups » fournissant une couche d‟adaptation qui permet de
manipuler les descriptions de services en changeant les noms des opérations, leurs
entrées/sorties, leurs adresses ainsi que les différents mécanismes d‟authentification et
d‟autorisation.
Les « service View » sont implémentés en utilisant un langage de script qui permet de modifier
la structure des documents WSDL et de créer de nouvelles descriptions WSDL correspondant
aux besoins des clients bien définis. Ce langage de script se compose d‟un ensemble de
commandes. Chaque commande permet de définir une insertion, une suppression ou à une mise à
jour d‟un élément constituant la description WSDL.
La figure 9 spécifie un ensemble de commande pour la génération des WSDL spécifiques aux
clients de services internes et externes à partir des descriptions WSDL.

26
Etat de l’art
location="https://.../ExternalServices"/>
…
Figure 9–Script de transformation des documents WSDL
Le script de transformation défini, permet à partir d‟un ensemble de fichiers WSDL existants de
générer des WSDL qui correspondent aux besoins des clients internes et des clients externes.
I.4.1.3
Discussion
Les vues sont largement utilisées en informatique pour divers besoins. Dans le cadre de la
technologie des services web, plusieurs travaux ont adopté le concept de vue. Ainsi, Maamar et
al. ont utilisé les vues comme un mécanisme d‟adaptation de services aux contextes des
utilisateurs. Maamar et al. spécifient les services composites en utilisant le SCD pour intégrer les
contraintes de temps et d‟espace dans les diagramme d‟état pour faciliter la dérivation des
spécifications suivant un contexte donné. Cette approche permet l‟adaptation des systèmes à base
de service. Néanmoins, l‟approche ne présente aucune notation ou langage pour la spécification
des aspects structurels d‟un système orienté service, c'est-à-dire la spécification de leurs
interfaces et des modèles de données y associées.
En ce qui concerne (Fink et al. 2003) qui proposent la modélisation des droits d‟accès des
différents utilisateurs dans un système distribué et notamment dans le cas des services web en se
basant sur le diagramme de classe classique. Cependant, le fait de modéliser des applications
orientés services en utilisant le diagramme de classe est inadéquat puisque ni le niveau de
granularité d‟un service, ni son niveau d‟abstraction ne correspondent à celui d‟une classe. En
outre, un service peut modéliser une activité métier et peut participer dans plusieurs processus
métier. Ainsi, le diagramme de classe ne peut en aucun cas représenter un service du moment où
le diagramme de classe n‟est pas pensé pour la modélisation d‟un système orienté service mais
d‟un système orienté objet.

27
Etat de l’art
L‟approche proposée par Fuchs (Fuchs, 2004) pour l‟adaptation des descriptions de services
suivant le type des utilisateurs (interne/externe), ne définit pas un formalisme ou une notation
pour spécifier et développer des systèmes orientés services distribués et à large échelle.
L‟adaptation de services se fait au niveau technologique et non pas au niveau métier, en utilisant
un langage de commande et sur les descriptions WSDL.
I.4.2. Concept d’adaptation : la variabilité de service
I.4.2.1
Description de l’approche
Pour développer des services adaptables aux clients de service, (Chang et al., 2007b) proposent
une approche se basant sur le principe de la variabilité de service. Cette approche définit les
types de variabilité de service ainsi qu‟un processus d‟Analyse/Conception permettant de
développer des services adaptables en se basant sur le concept de variabilité. Ce concept est
largement utilisé dans les PLE (Product Line Engineering). La variabilité se définit en terme de
point de variation et de variant. Un point de variation est un emplacement dans le logiciel où un
changement peut survenir. Le variant est la valeur ou l‟instance qui s‟associe à un point de
variation. La figure 10 illustre les différents types de variabilité ainsi que les différentes couches
logicielles d‟une application SOA concernées (processus métier, services unitaires, interface de
service et les composants de services) :
Globalement, quatre types de variabilité de services ont été définis comme le montre la figure 10
: la variabilité de Workflow, la variabilité de composition, la variabilité de l‟interface et la
variabilité de la logique.
La variabilité de workflow : Un processus business est réalisé à travers une séquence de services
unitaires, appelée Workflow. Une partie de cette séquence peut ne pas être utilisée par certains
consommateurs de services. Aussi, une partie de la séquence d‟activités peut varier d‟un
consommateur à un autre. Ainsi, La variabilité de Workflow est définie comme étant la variation
des workflows des processus business.
La variabilité de la composition : Un processus métier fait la composition de plusieurs services
unitaires (chaque service unitaire réalise une activité donnée) pour répondre aux besoins des

28
Etat de l’art
utilisateurs finals. Pour un service unitaire donné, plusieurs interfaces de services peuvent être
découvertes. Dans ce cas, la variation consiste dans le bon choix de l‟interface qui correspond
aux profils des clients de services. L‟interface choisie dépend des besoins du client de services
interagissant avec le service.
Business
Process
Layer
Business
Process
Business
Process
Business
Process
Workflow
Variability
Unit
Service
Layer
Unit
Service
Unit
Service
Unit
Service
Composition
Variability
Interface
Layer
Interface
Variability
service
Component
Layer
Logic
Variability
Figure 10–Types de variabilité de services (Chang et al., 2007b)
La variabilité de l‟interface : La variabilité de l‟interface se manifeste lorsque l‟interface du
service unitaire ne correspond pas à la description de l‟interface de service publiée dans un
annuaire de service tel que UDDI. Les descriptions de services publiées dans l‟annuaire sont
généralement des descriptions générées à partir des composant services qui sont des
implémentations des services avec des langages donnés (C #, Java, etc.). La variabilité de
l‟interface peut concerner le nom des opérations de services, les types des entrées/sorties, le type
de retour, etc.
La variabilité de la logique : Le composant service contient l‟implémentation des opérations de
service qui réalisent les fonctionnalités du service unitaire. L‟algorithme ou la procédure de
l‟opération peut varier suivant les requêtes des clients. Cette variation est appelée la variabilité

29
Etat de l’art
de la logique.
En se basant sur les types de variabilité définis, Kim et al. (Chang et al., 2007a) définissent un
processus de développement des services adaptables. Le processus définit un ensemble de
phases, d‟activités et d‟artéfacts clés pour le développement des systèmes orientés services
adaptables en tenant compte les utilisateurs finals. Globalement, ce processus définit les
phases suivantes :
Phase 1 : La définition des services cibles
L‟objectif de cette phase est l‟analyse des exigences métiers pour pouvoir définir les processus
métiers qui permettent de répondre aux besoins des utilisateurs finals. Cette phase est réalisée en
trois étapes : l‟acquisition des exigences de services, l‟identification des services cibles et la
définition des workflows des différents processus business. L‟objectif de cette phase est la
production de la spécification des services cibles comme un artéfact caractérisant cette phase.
Cette spécification contient la liste des services cibles, la description des business process et
leurs Worflows associés. Dans cette phase, une variabilité de workflow est associée.
Phase 2 : La définition des services unitaires
L‟objectif principal de cette phase est la conception des services unitaires à partir de l‟artefact de
la phase précédente. La première étape de cette phase consiste à définir les caractéristiques des
services en se basant sur les critères de réutilisation et de cohésion. La deuxième étape de cette
phase est la définition des interfaces des services. Dans cette phase, une spécification de la
variabilité est effectuée.
Phase 3 : la planification de l‟acquisition des composants service
Cette phase a pour finalité la planification de l‟acquisition des implémentations de services. Pour
cela trois scénarios ont été adoptés : l‟utilisation des services publiés dans l‟annuaire,
l‟adaptation des applications traditionnelles ou le développement de nouveaux services. Cette
phase est concernée par deux types de variabilité : la variabilité de la composition et la variabilité
de l‟interface.

30
Etat de l’art
Phase 4 : l‟acquisition des composants services :
L‟objectif de cette phase est de préparer les services web en tenant compte des services
découverts, des services adaptés à partir des applications existantes ou des nouveaux services
web développés. Dans cette phase, la variabilité de la logique est associée aussi bien au niveau
de l‟analyse qu‟au niveau de la conception.
Phase 5 : la composition de services
L‟objectif principal de cette phase est la définition de la composition de services. Cette
composition est dérivée à partir des artefacts des phases précédentes et elle est représentée par le
langage de spécification de composition BPEL. Dans cette phase, la variabilité est affinée ainsi
que la finalisation de l‟architecture globale du système.
I.4.2.2
Discussion
Chang et al.(Chang et al., 2007a) proposent le concept de la variabilité de service pour le
développement des service personnalisables et adaptables aux différents profils des clients de
services. Chang et al. définissent un processus de développement définissant activités, phases et
artefacts permettant l‟identification, la spécification et l‟implémentation des services en prenant
en compte la variabilité de services tout au long du cycle de vie de développement d‟un SOS.
L‟approche permet une meilleure séparation des préoccupations fonctionnelles entre les
différents clients de service et une prise en compte de la diversité des profils des utilisateurs
interagissant avec le service. Cependant, cette approche ne définit ni une notation ni un outil
logiciel associé en vue de rendre productif et rationnel l‟activité du développement des systèmes
orientés services adaptables.
I.4.3. Concept d’adaptation : la différenciation de service
I.4.3.1
Description de l’approche
L‟adaptation de services aux profils des utilisateurs est un défi majeur pour le développement des
SOSs. Dans cette optique, (Tao et al. , 2007a) (Tao et al. , 2008) proposent une approche
d‟adaptation en se basant sur le concept de la différentiation de service. La différenciation de
service, à l‟instar de la différenciation de services dans le domaine du réseau (i.e., l‟approche

31
Etat de l’art
DiffServ), consiste en la prise en compte de la diversité des profils des utilisateurs (localisation,
contexte, etc.) interagissant avec un service donné. En effet, le résultat de l‟exécution du même
service ainsi que la qualité requise différent d‟un utilisateur à un autre.
Pour la conception des services différenciés et adaptables, l‟approche définie repose sur la
séparation des activités business qui sont applicables dans toutes les circonstances et exécutées
par tous les utilisateurs de service, des activités business spécifiques à des groupes d‟utilisateurs
particuliers (profils particuliers). En fait, les approches d‟adaptation de services existantes se
basent principalement sur l‟implémentation des aspects d‟adaptation comme des conditions
d‟exécutions dans le code de chaque processus métiers implémentant le service. De telles
approches rendent plus complexes la flexibilité, la maintenance, l‟extensibilité et l‟adaptabilité
des services. La figure 11 partie (a) illustre le fonctionnement des approches d‟adaptation des
services existantes.
Pour répondre aux limites de ces approches, Aries Tao Tao et al. proposent une approche de
conception de services adaptables en se basant sur les étapes suivantes :
1. L‟utilisation « des processus métiers noyau » (Core Business Process) (CBP) pour la
représentation des activités génériques requises par tous les utilisateurs indépendamment des
contextes d‟utilisations. Le CBP qui implémente les fonctionnalités accessibles à tous les
utilisateurs, est formalisé par une machine à états finis.
2. La séparation des contextes d’utilisation du “processus métier noyau”. En effet, différents
groupes d‟utilisateurs qui requièrent des fonctionnalités spécifiques sont modélisés comme
des ensembles des contextes d‟utilisations.
3. La définition des processus métiers configurés aux contextes (Configured Context
Business Process)(CCBP) qui implémentent les fonctionnalités requises pour des groupes des
utilisateurs spécifiques. Le CCBP est déterminé bien évidemment en appliquant les
contextes d‟utilisation au CBP. Il est généré à travers l‟application des contextes
d‟utilisations sur le CBP qui modélise les fonctionnalités accessibles à tous les utilisateurs en
définissant plusieurs algorithmes.
4. La détermination des interfaces du service en se basant sur les processus métiers configurés
aux contextes. En effet, après la génération des CCBP qui correspondent à l‟application d‟un

32
Etat de l’art
Figure 11–Concept de service différencié (Tao et al. , 2008)
5. contexte d‟utilisation sur un CBP, vient l‟étape de la dérivation de l‟interface de service. Pour
chaque CCBP, une interface de service lui est associée qui correspond aux besoins des
utilisateurs appartenant au groupe d‟utilisateurs associé au contexte d‟utilisation. Pour
identifier cette interface de service, des algorithmes ayant pour but d‟extraire les activités du
CCBP ont été définis. Ces algorithmes parcourent chaque état composant le CCBP et

33
Etat de l’art
stockent les activités visibles pour la construction de l‟interface du service associé au CCBP.
La figure 11 partie (b) reflète l‟approche de conception des services différenciés.
La figure 12 présente le CBP d‟un service de pharmacie en ligne (Online Pharmacie Service)
(OPS) (Tao et al., 2007). Ce service est en interaction avec plusieurs types de clients : les
clients de service fidèles et les clients infidèles. Pour les clients fidèles, une remise sur les
prix de médicament est appliquée. La figure 12 présente les OPS_CBP comme une
représentation des activités exécutées par tout type d‟utilisateur (les clients de services
fidèles/ infidèles). Chaque type d‟utilisateur peut exécuter les activités login, display good
selection, display total price, receive payment et Product Delivery. OPS_UCM permet de
modéliser les activités spécifiques au contexte d‟utilisation associé au client fidèle définies
par deux propriétés : context (1) et context (2). OPS_CCBP représente les activités du
processus configuré au contexte d‟utilisation associé à ce contexte d‟utilisation.
OPS_ServiceInteface représente l‟interface associée au contexte d‟utilisation client fidèle qui
se compose essentiellement d‟opérations :
Figure 12–Conception à base des services différenciés de l’application OPS) (Tao et al., 2007b) .
I.4.3.2
Discussion
(Tao et al., 2007a) (Tao et al., 2007b) (Tao et al., 2008) proposent une approche d‟adaptation des

34
Etat de l’art
services aux profils des clients de services. Cette approche est fondée principalement sur le
formalisme des machines à états finis. Elle permet la modélisation des fonctionnalités accessible
par tous les utilisateurs et dans toutes les circonstances en se basant sur le CBP. Les
fonctionnalités spécifiques associées à chaque acteur sont modélisées en se basant sur les
contextes d‟utilisation (UC). Un CCBP est obtenu en appliquant un contexte d‟utilisation à un
CBP. Le CCBP permet de représenter les fonctionnalités requises qui correspondent à un profil
d‟utilisateur donné. A chaque CCBP est associée une interface de service qui correspond à un
profil d‟un utilisateur donné qui va interagir avec le service.
Cette approche bien qu‟elle fournisse un formalisme (les machines à états finis) puissant en
faisant l‟adaptation de services, elle ne permet pas la modélisation des aspects structurels d‟un
SOS. Elle se base sur une approche de modélisation des aspects dynamique et non pas structurels
pour l‟adaptation des services aux profils des utilisateurs. Aussi, cette approche reste abstraite et
ne prend pas en compte les standards et les technologies des services web pour son illustration et
sa mise en œuvre.
I.5.
SOS : technologies d’adaptation
Dans l‟objectif de l‟adaptation des services, plusieurs approches ont proposé l‟extension des
standards associés aux services web. En effet, plusieurs propositions ont visé l‟extension des
standards de description de services tels que AWSDL (Lopes-velsco et al. , 2005), CWSDL
(Kouadri Mostefaoui et al,2005) ou l‟extension CBPEL (Ghedira et al, 2005) pour la prise en
compte de l‟adaptabilité de service au niveau du standard BPEL .
I.5.1. AWSDL et CWSDL
AWSDL (Lopez-velasco et al., 2005) est une extension du standard WSDL pour permettre au
fournisseur de service de spécifier les différentes adaptations permises par le service web. Le
AWSDL se base principalement sur le concept du profil général de l‟utilisateur (PGU). Le PGU
est capable de décrire les besoins d‟adaptation d‟utilisateurs. Il est destiné à offrir un cadre
générique pour la description d‟un utilisateur. Il permet de décrire les caractéristiques
personnelles de l‟utilisateur et celles du contexte dans lequel est utilisé l‟application cible. Les
caractéristiques de l‟utilisateur sont divisées en informations permanentes (son nom, sa langue

35
Etat de l’art
maternelle,…) et ses caractéristiques évolutives (ses centres d‟intérêts, ses connaissances,…).
Les caractéristiques du contexte constituent la seconde catégorie de descripteurs, qui se
composent de deux sous-catégories : les caractéristiques de la connexion et les caractéristiques
de l‟environnement. Les caractéristiques de connexion sont composées des caractéristiques du
dispositif, décrit tant par ses contraintes matérielles (taille de l‟écran, type de données
multimédia supporté, etc.) que logicielles (plate-forme et navigateur utilisés) et de celle du
réseau (type, débit,…). La description de l‟environnement comprend la localisation physique et
le contexte temporel (i.e., date et heures des sessions) établis par l‟intermédiaire d‟un dispositif.
Pour formaliser le PGU, (lopez et al) (Lopez-velasco, 2005) ont utilisé deux standards W3C RDF
(Klyne et al., 2004) et CC/PP (Kiss, 2007). RDF permet de décrire les ressources à l‟aide d‟un
ensemble de méta données. Le second langage CC/PP permet de définir plus particulièrement les
capacités des dispositifs utilisés et les préférences des utilisateurs en termes de contenu.
Le CWSDL (Kouadri mostefaoui et al., 2005) est proposé en vue d‟intégrer les informations du
contexte au standard WSDL pour permettre l‟adaptation des services aux contextes de leurs
clients.
I.5.2. CBPEL et VXBPEL
Dans le même objectif d‟adaptation des services aux contextes, Ghedira et al. (Ghedira et al.
2005) et Koning et al. (Koning et al. 2009) proposent une extension au standard de la
composition des services (BPEL) pour faire adapter un service composite aux contextes de ses
utilisateurs. CBPEL est une extension du BPEL pour l‟intégration des caractéristiques du
contexte. VxBPEL est une extension du BPEL en se basant sur le concept de la variabilité des
services.
I.5.3. Discussion
Dans l‟objectif de l‟adaptation des services, plusieurs propositions ont visé l‟extension des
standards associés à la technologie des services web. Dans cette optique, Les travaux (lopezvelasco
et al, kouadri mostéfaoui et al., 2005) (Maamar et al., 2006) ont étendu le standard
WSDL pour la prise en compte du profil de l‟utilisateur ou de son contexte pour pouvoir adapter
les services. Le problème posé avec ces approches, est que les extensions apportées aux

36
Etat de l’art
standards sont inaccessibles et incompréhensibles aux différents stakeholders (analystes métier,
architectes, développeurs, utilisateurs finals, etc.) s‟intéressant au développement des SOS, vu
leur verbosité et leur bas niveau d‟abstraction. Par ailleurs, le manque de l‟automatisation de la
génération de code correspondant aux extensions apportées à ces standards pénalise largement le
développement des SOS adaptables, vu que le codage manuel de ces extensions est un exercice
complexe, fastidieux et «error-prone ». D‟où la nécessité d‟offrir des formalismes et des
notations facilement compréhensibles par les différents stakeholders et permettant
l‟automatisation de la génération de code. Ce qui va permettre une meilleure productivité et une
compréhension des caractéristiques des SOS par les différentes stakeholders.
I.6.
SOS : Approches d’adaptation dirigées par les modèles
En parallèle avec l‟émergence du SOC, le développement dirigé par les modèles (MDD-Model
Driven Development) a marqué l‟ingénierie logicielle en proposant une nouvelle manière pour le
développement, la maintenance, l‟évolution et l‟intégration des systèmes logiciels. Le MDD est
principalement axé sur les modèles comme des entités de première classe et sur la transformation
de ces modèles comme activité principale.
Pour concrétiser la vision MDD, l‟OMG a proposé l‟approche MDA (Model Driven
Architecture). MDA est une démarche de développement qui permet la séparation des
spécifications fonctionnelles d‟un système des spécifications de son implémentation sur une
plateforme donnée en les décrivant par des modèles séparés en se basant sur des standards.
L‟approche MDA a apporté plusieurs avantages pour le développement des systèmes
logiciels (Gerber et al., 2002): (i) elle permet l‟utilisation du même PIM pour la génération des
modèles sur des plates-formes différentes (ii) elle permet l‟amélioration de la portabilité et de
l‟interopérabilité des systèmes via l‟utilisation des modèles. (iii) elle permet la protection de la
logique métier contre les changements ou l‟évolution des technologies et (iv) elle permet la
réutilisation et la composition de modèles rendant possible la construction de systèmes
complexes.
Pour bénéficier de l‟approche MDA pour le développement des SOS, plusieurs travaux ont été
présentés (Bezevin et al., 2004) (Lopes et al., 2004) (Yu et al., 2007) (Torkman et al.,
2006)(Patrsciou et al., 2004)(Gronmo et al., 2004a)(Baina et al., 2004)(Bordbar et al., 2004).
L‟objectif de cette section est d‟exposer ces différents travaux de recherche qui combinent entre

37
Etat de l’art
deux disciplines dans le domaine du génie logiciel le MDD et le SOC. En premier lieu, nous
allons présenter les concepts de base de l‟approche MDA. En deuxiéme lieu, nous allons discuter
les approches MDA de développement des SOS. En troisieme lieu, nous allons présenter
quelques propositions pour la prise en compte de l‟utilisateur dans le contexte du MDA pour le
développement des SOS.
I.6.1. Concepts et définitions
L‟approche MDA est centrée modèle. Elle définit plusieurs niveaux de modèles. Ainsi, Nous
distinguons : le modèle, le métamodèle et le méta-métamodèle.
Le modèle est «une simplification de quelque chose qui nous permet de voir, manipuler, et
raisonner sur le sujet étudié, et qui nous aide à en comprendre la complexité inhérente ». (Mellor,
2004)
Un métamodèle «est un modèle qui définit le langage pour exprimer un modèle » (OMG, 2003)
Un métamétamodèle «est un modèle qui définit le langage pour exprimer un métamodèle. La
relation entre un métamétamodèle et un métamodèle est analogue à la relation entre un
métamodèle et un modèle» (OMG, 2003).
Pour définir la relation entre ces différents modèles, l‟OMG a proposé l‟architecture à quatre
niveaux: le niveau M0, le Niveau M1, le Niveau M2 et le niveau M3.
M0 est le niveau des données réelles. Il est composé des informations que l‟on souhaite
modéliser. Ce niveau est souvent considéré comme étant le monde réel.
Le niveau M1 est composé de modèles d‟informations. Lorsque l‟on veut décrire les
informations de M0, le MDA considère que l‟on fait un modèle appartenant au niveau
M1. Typiquement, un modèle UML appartient au niveau M1. Tout modèle est exprimé
dans un langage unique dont la définition est donnée explicitement au niveau M2.
Le Niveau M2 est donc composé de langage de définition des modèles d‟informations
appelés aussi méta-modèles. A titre d‟exemple, le métamodèle UML qui décrit le

38
Etat de l’art
standard UML appartient au niveau M2 ; il définit la structure interne des modèles UML.
Un méta-modèle définit donc un langage de modélisation spécifique à un domaine.
Le niveau M3 est composé d‟une unique entité qui est le langage unique de définition des
méta-modèles, aussi appelé le méta-méta-modèle ou le MOF (Méta-Object Facility)
(OMG, 2002a). Le MOF définit la structure de tous les méta-modèles qui se trouvent au
niveau M2. le MOF est réflexif, c‟est à dire que la description du MOF s‟applique au
MOF lui même, ce qui permet de dire que le niveau M 3 est le dernier niveau de
l‟architecture. le niveau M3 correspond donc aux fonctionnalités universelles de
modélisation logicielle, alors que le niveau M2 correspond aux aspects spécifiques des
différents domaines, chaque aspect particulier étant pris en compte par un métamodèle
spécifique.
Pour le développement des systèmes logiciels, MDA définit plusieurs types de modèles.
Trois types de modèles représentant et séparant entre différentes préoccupations (e.g.,
métier/technologique) ont été notamment définis : le CIM(Computation Independant
Modèle) , le PIM (Platform Independent Model) et le PSM (Platform Specific Model). Le
CIM permet de représenter les exigences métier d‟un système. Le PIM est un modèle ayant
pour objectif la description de la logique métier d‟un système indépendamment de toute
plateforme ou technologie. Le PSM qui est un modèle dépendant d‟une technologie
particulière, permet de représenter une implémentation d‟un système conformément à une
technologie particulière.
Le passage d‟un type de modèle (e.g., CIM/PIM, PIM/PSM, etc.) à un autre se fait par
transformation de modèle. Une transformation de modèles est définie comme une fonction
ayant comme entrée un ensemble de modèles et qui produit en sortie un ensemble de
modèles. Les modèles d‟entrée et de sortie doivent être conformes à leur métamodèle.
L‟exécution d‟une transformation de modèle se fait au niveau des modèles, mais elle se
spécifie au niveau des métamodèles. En effet, une transformation exprime des
correspondances structurelles entre les modèles sources et cibles. Ces correspondances
s‟appuient sur les métamodèles de ces modèles.

39
Etat de l’art
I.6.2. Approches MDA de développement des SOS
Dans cette section, nous présentons des travaux de recherche qui combinent entre deux
disciplines dans le domaine du génie logiciel à savoir l‟ingénierie dirigée par les modèles et les
approches à base de services. En premier lieu, nous allons mettre l‟accent sur les approches
MDA de développement des SOS. Ainsi, plusieurs travaux ont été présentés (Bezevin et al,
2004) (Lopes et al, 2004)(Skogan et al., 2004)(Yu et al, 2007) (Torkman et al., 2006) (Patrasciou
et al., 2004)(Gronmo et al., 2004a) (Baina et al., 2004). Nous avons classifié ces approches en
deux classes selon le formalisme ou le langage de modélisation utilisé pour l‟élaboration des
PIM. En effet, deux formalismes ont émergé pour la définition des PIMs : UML comme langage
et standard universel de modélisation et le profil UML EDOC (OMG, 2002d) comme une
extension d‟UML pour la modélisation des applications distribuées.
En deuxième lieu, nous présentons quelques propositions pour la prise en compte de l‟utilisateur
dans le contexte de MDA pour le développement des SOS.
I.6.2.1
PIM (UML) vers services Web
(Bezevin et al., 2004) ont proposé l‟application de l‟approche MDA pour le développement des
applications Internet sur des plateformes services web. Ils visent la séparation des aspects métiers
des aspects technologique. Pour ce faire, Ils élaborent en premier lieu un PIM qui reflète les
fonctionnalités, la structure et la dynamique d‟un système loin des détails technologiques. Un tel
PIM, spécifié en UML ou EDOC, est manipulé et transformé selon des règles de transformation
pour créer des PSMs basés sur trois plateformes technologiques : WSDL, J2EE, et dotNET.
La figure 13 illustre les différents types de transformations définis :

40
Etat de l’art
Figure 13–Types de transformations : modèle vers modèle et modèle vers code (Bezevin et al.,
2004).
Ces différents types de transformation ont été illustrés à travers un exemple illustratif « Agence
de voyage ». Cet exemple illustratif est modélisé de façon neutre comme un PIM en utilisant le
langage de modélisation (UML). Ce PIM est transformé premièrement à un modèle WSDL pour
la génération de la description du service web crée. Ensuite, Ce PIM est transformé vers le
modèle J2EE ou dotNet pour pouvoir créer le code source du service, les fichiers de
configuration et les fichiers de déploiement.
La figure 14 présente le PIM de l‟agence de voyage. Ce PIM est constitué de six classes
implémentant les principales caractéristiques du système de l‟exemple illustratif : Customer,
ServiceTravelAg, ServiceAirLines, ServiceCarHire, ServiceHotel et ServiceBank.

41
Etat de l’art
Figure 14–Modèle PIM de l’étude de cas « agence de voyage » (Bezevin et al., 2004).
Pour transformer le PIM (en UML) vers un PSM (WSDL), Bezevin et al.(Bezivin et al., 2004)
ont défini le métamodèle source qui est UML et le métamodèle cible du WSDL ainsi que les
différentes correspondances existantes entre les éléments des deux métamodèles. Les
métamodèles source et cible doivent être conformes au MOF. Le métamodèle source choisi est
UML qui est un standard conforme au MOF. Le métamodèle WSDL est créé à partir de son
schéma conformément au MOF.
La figure 15 illustre les différentes correspondances identifiées entre le métamodele UML et le
métamodèle WSDL.

42
Etat de l’art
UML metamodel
Mapping
WSDL metamodel
ModelElement
Namespace
Package
AssociationEnd
Class
Interface
Attribute
Operation
+specification
+method
Method
Parameter
DataType
WSDLElement
Documentation
Type
+types
Part
0..1
0..*
+part
P2D
+message
Message
0..*
A2T
Operation
+operation 0..*
C2S
PortType
+type
0..*
+portType
0..*
+binding
Binding
0..*
+boperations
O2O
BindingOperation
Port
0..*
+port
M2Bo
+service
Service
0..*
P2Part
Dt2T
Definition
+_targetNameSpace
+name
Figure 15–Correspondances UML/WSDL (Bezevin et al., 2004)
Après l‟identification des correspondances, Bezevin et al.(Bezivin et al., 2004) ont utilisé le
langage ATL pour la définition de transformation.
La figure 16 présente les correspondances possibles entre le métamodèle UML et le métamodèle
Java. Ces correspondances sont réalisées par un ensemble d‟éléments de correspondances qui
spécifient les éléments du métamodele source qui sont équivalents aux metamodels cible (le
métamodèle Java). A partir de chaque élément de correspondance, des règles de transformation
sont définies pour transformer les éléments du modèle source en éléments du modèle cible.
Après l‟identification des éléments équivalents entre les métamodèles d‟UML et java, les règles
de transformations associées sont définies.

43
Etat de l’art
UML metamodel
ModelElement
Mapping
Java metamodel
JElement
Namespace
P2P
Package
AssociationEnd
Ae2F
Generaliation
GeneralizableElement
C2Jc
Class
Interface
Attribute
Operation
+specification
+method
Method
Parameter
DataType
I2I
A2F
OM2M
Pr2Pr
Dt2Jpt
0..*
+super
0..1
JPackage
+nested
JClassifier
JClass
0..*
+implemetedby
0..*
+implements
JInterface
JPrimitiveType
JMember
JField
JValue
JMethod
+owner
+jparameters
0..*
0..*
JParameter
+type
+type
Figure 16–Correspondances UML/Java (Bezevin et al., 2004)
(Gronmo et al., 2004b) proposent une méthodologie pour développer les SOS dans le cadre de
l‟approche MDA. La figure 17 illustre cette méthodologie.
Une telle méthodologie définit les étapes suivantes:
• Discover Web Services : Le développeur utilise un navigateur Web et un client d‟annuaire pour
chercher un service Web candidat pour la composition. Il obtient une liste de services Web et les
localisations de leur description (représentée en WSDL).
• Import Web Service Descriptions : Le développeur importe la description du service et la
traduit en UML. Le résultat est un modèle UML conforme au WSDL.

44
Etat de l’art
WSDL
UML
Model composite Web services
Service
modeling
Workflow
modeling
Discover Web
Services
Import Web
Service Description
Composite Web
Service-WSDL
Export Web Service
Description
Implement Composite
Web Service
Publish Composite
Web Service
Figure 17–Méthodologie de développement des SOS (Gronmo et al., 2004a).
• Model Composite Web Service : Le développeur utilise un outil UML pour réviser et intégrer
les modèles importés sous forme de modèle d‟un service composé. Cette étape est composée de
la modélisation de la structure du service (Service modeling) et de la modélisation du
comportement du service composé (Workflow modeling).
• Export Web Services Description : Le modèle du service Web composé est exporté afin
d‟obtenir un document WSDL du service Web composé.
• Implement Composite Web Service : Le service Web est réalisé à partir d‟un document
WSDL.
• Publish Composite Web Service : Finalement, le service Web composé est publié dans un
annuaire. La figure 18 présente un modèle UML et son équivalent en WSDL. Selon cette figure,
une Class en UML est l‟équivalent de Types en WSDL. Une Interface en UML est l‟équivalent
de PortType et Binding en WSDL. Une méthode en UML est l‟équivalent d‟Operation en
WSDL. Une classe stéréotypée par BusinessServices est l‟équivalent de Service en WSDL.
Ensuite, Gronmo et al. (Gronmo et al. 2004b) utilisent UMT (UML Transformation Tool)
(SINTEF, 2004) pour créer les règles de transformation de UML en WSDL.

45
Etat de l’art
BasicWFS
getCapabilities()
describeFeatureType()
getFeature()
« Interface »
TransactionWFS
lockFeature()
transaction()
« BusinessService »
MyWebService
CreditCard
number : string
expires : date
Payment
validate(card :CreditCard) :
boolean
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...

46
Etat de l’art
WSDL
EDOC PIM
BPEL
Functional Decomposition
Web Service
EDOC
PIM
mapping
WSD
L
WSD
L
mapping
Web Service 2
EDOC
PIM
WSD
L
mapping
Web Service N
EDOC
PIM
BPEL
BPEL
BPEL
Implementation Platform 1 Implementation platform 2 Implementation platform N
Figure 19–Processus de transformation du framework défini (Yu et al , 2007)
(1) Des PIMs (EDOC) aux PSMs (WSDL)
Chaque interface de service est décrite en utilisant le standard WSDL comme une technologie
pour la description du service en se basant sur un schéma XML dédié. Pour automatiser la
génération de WSDL à partir du profil EDOC-un profil UML permettant la spécification d‟un
système distribué – deux transformations ont été définies. La première consiste en la génération
du XMLSchema à partir du Modèle de document d‟EDOC-CCA. Pour réaliser cette
transformation, un certain ensemble de règles en QVT ont été définies. Pour cela, il est
nécessaire, dans un premier lieu, de disposer des métamodèles source et cible et dans un
deuxième lieu d‟identifier les correspondances entre leurs éléments suivant une analyse
sémantique d‟équivalence. La figure 20 illustre le métamodèle source. La figure 21 définit le
métamodèle cible. Le tableau 4 définit les équivalences entre les différents éléments du
métamodèle source et cible ainsi que les règles de transformation définies pour implémenter des
règles en QVT.

47
Etat de l’art
Nom de la règle Entrée Sortie
Dp2pdt DataType PrimitiveDatatype
String
String
Integer
Int
Float
Float
Decimal
Decimal
Boolean
Boolean
Date
Date
En2st Enumeration SimpleType
Cd2ct CompositeData ComplexType
Tableau 4–Correspondances Model Document/Web service (YUet al., 2007)
La deuxième transformation consiste en la génération d‟autres éléments de WSDL
ProcessComponent
Document Type
+type
DataElement
Protocol
uses
PortOwner
+owner
1..* +ports
Port
FlowPort
DataType
Enumeration
1
+enumeration
+Values
*
EnumerationValue
OperationPort
ProtocolPort
0..*
+attrs
Attribute
CompositeDataType
+owner
+features
Figure 20–Métamodèle « Document Model » (Yu etal ., 2007)

48
Etat de l’art
Figure 21–Métamodèle WSDL (Yu et al., 2007)
Rule Input(CCA) Output (WSDL)
fp2mg FlowPort Message
fp2ptop FlowPort
Op2pto OperationPort
Pp2PPT ProtocolPort
Pp2bd ProtocolPort
Pp2pt ProtocolPort
Pc2s PC
Pc2d PC
Cca2wsdl PC WSDL File
Tableau 5–Correspondances CCA/WSDL (Yu et al., 2007)

49
Etat de l’art
(2) Des PIM (EDOC) aux PSMs (BPEL)
Dans le cadre du framework défini, tous les sous PIMs définis sont implémentés comme des
services qui seront composés pour construire un Système d‟Information. Ainsi, après la
génération des WSDL de chaque service, vient ensuite l‟étape de la génération des modèles
BPEL pour la définition de la composition des services à partir des modèles dynamiques EDOC.
0..1
supertype
Choreography
*
subtypes
target
+incomings
Node
AbstractTransition
-name : String
+source
+outcoming
s
PortUsage
PseudoState
Transition
-kind :PseudoSateKind
-preCondition
+represents
Port
PseudoStateKind
-name : String
-isSyne :Boolean
-Transactional :Boolean
-direction:DirectionType
-postcondtion:Status
+choice
+fork
+initial
+join
+failure
Figure 22–Métamodèle Choreography (YU et al., 2007)
Pour réaliser cette étape, il est nécessaire de définir les métamodèles source et cible ainsi que les
correspondances entre les différents éléments des métamodèles. Le métamodèle source est celui
de EDOC tandis que le métamodèle cible est celui de BPEL. La figure 22 définit le métamodèle
source. La figure 23 définit le métamodèle cible. Le tableau 5 définit les éléments d‟entrée et

50
Etat de l’art
leurs contraintes associées ainsi que leurs correspondants dans le métamodèle cible et leurs
règles associées
Figure 23–Métamodèle BPEL (Yu et al., 2007)
Patrasciuo et al. (Patrasciuo, 2004b) ont proposé une approche pour la transformation d‟un PIM
élaboré en utilisant le profil UML EDOC vers une plateforme service web et notamment la
transformation du PIM EDOC vers un modèle WSDL. Le modèle source doit être conforme au
métamodèle d‟EDOC, qui à son tour doit être conforme au MOF. Le métamodèle cible est celui
de WSDL, qui est élaboré en se basant sur le schéma de WSDL défini dans la spécification
WSDL. Dans le but de générer le modèle WSDL à partir du modèle EDOC, un ensemble de
règle de transformation a été défini en utilisant le langage YATL (Yet Another Transformation
language) (Patrasciuo, 2004a). Pour valider et illustrer la transformation d‟un PIM (EDOC) vers
une la plateforme services web, une étude de cas concernant l‟agence de voyage a été mise en
évidence. Ainsi, la démarche adoptée consiste à définir un PIM de l‟agence de voyage en
utilisant le profil EDOC. Ensuite, vient l‟étape de la définition des règles de la transformation en
utilisant YATL comme langage de transformation de modèle pour la génération des descriptions
WSDL de l‟agence de voyage. A signaler que pour transformer un modèle EDOC vers un

51
Etat de l’art
modèle WSDL, Patrascuio (Patrasciuo, 2004b) définit premièrement des règles de transformation
pour la génération des schémas XML nécessaires pour la définition des types de données utilisés
pour la description de message WSDL. Pour ce faire, le mapping se base sur le métamodèle
«Document Model» comme métamodèle source (Cf. figure 24) et sur le «XML schema» comme
métamodèle cible (cf. figure 25).
Figure 24–Profil “Document Model” (Patrasciuo, 2004)
Ensuite, pour la génération des autres éléments WSDL, le mapping entre les éléments de EDOC
et les autres éléments du métamodèle WSDL (Cf. figure 26) a été défini.

52
Etat de l’art
Figure 25–Métamodèle du XML schéma
Figure 26–Métamodèle WSDL (Patrsciou et al., 2004)

53
Etat de l’art
I.6.3. Approches MDA d’adaptation des SOS
L‟approche MDA a été largement utilisée dans le cadre de la prise en compte des différents
aspects des besoins de l‟utilisateur final. Dans cette optique, plusieurs travaux dans la littérature
ont été proposés pour la prise en compte des propriétés non-fonctionnelles, de la gestion des
droits d‟accès, de la qualité de service et du contexte.
L‟objectif de cette section est de présenter ces différentes propositions.
I.6.3.1
Approches de gestion des propriétés non-fonctionnelles
Ortiz et al. (Ortiz et al. 2006a) proposent une approche dirigée par les modèles pour la prise en
compte des propriétés extra-fonctionnelles. Ces dernières concernent toutes les fonctionnalités
supplémentaires qui ne font pas partie des fonctionnalités principales des systèmes (le métier des
systèmes) telles que les propriétés de sécurité, de loging, du temps réel, etc. Cette approche se
base essentiellement sur la définition en premier lieu d‟un profil UML pour la modélisation des
propriétés extra-fonctionnelles indépendamment des standards (WS-policy ou SOAP) ou des
technologies (AspectJ) (Kiczales et al., 2001). Elle se base aussi sur la définition d‟un processus
de transformation dans le cadre de l‟approche MDA en définissant les métamodèles sources et
cibles ainsi que les règles de transformation pour l‟automatisation de la génération de code et
notamment, les différentes politiques, les aspects ou du code java.
Le profil UML proposé, définit essentiellement deux stéréotypes pour la modélisation des
propriétés extra-fonctionnelles : le stéréotype « extrafunctional property » et le stéréotype
«service component». Ce dernier permet la modélisation des services en identifiant leurs
interfaces fournies et requises via des references. Le stéréotype « extrafunctional
property » étend la métaclasse « operation » ou la metaclasse « interface ». Ce stéréotype (cf.
figure 27) est spécialisé en quatre stéréotypes : , , ,
permettant respectivement la modélisation des informations de contrôle
d‟accès, des propriétés temps réel, les informations de l‟invocation d‟opération et les
informations de cryptage.
La figure 27 présente le profil « extra-functional Property » avec ses métaclasses de base.

54
Etat de l’art
Operation
Interface
Extra-FunctionalProperty
actionType : ActionType
optional : Boolean
ack : Boolean
policyID : String
policyDoc : String
ActionType
before
after
instead
none
Figure 27–Profil «Extra- functional Property » (Ortiz et al., 2006b)
EFProperties
Extra-functional Property
Encryption
Login
Loging
RealTime
-encryptionKey : string
-usersDB : string
-recordFile : string
-realTimeURL : string
Figure 28–Stéréotype « Extra-functional property » (Ortiz et al., 2006b)
Pour illustrer l‟utilisation du profil défini, une étude de cas concernant l‟E-Tourisme a été
présentée. La figure 29 présente le service touristInformation. Ce service est représenté comme
un composant stéréotypé serviceComponent qui fournit une interface. Pour inclure les propriétés
extra-fonctionnelles au service, trois propriétés simples ont été conçues : la propriété log qui
s‟applique à une opération et permet de stocker toutes les informations concernant les
invocations d‟une telle opération. La propriété RealTime est requise par le client de service pour
la prise en compte des propriétés temps réel lors de l‟invocation de l‟opération
WetherInformation. La propriété login est utilisée pour gérer les droits d‟accès à l‟opération

55
Etat de l’art
«carRenting» puisqu‟il est accessible seulement aux utilisateurs qui ont un login et un mot de
passe.
touristServiceInterface
TouristService
+hotelInformation(…) :string
+carRenting(…) : string
+weatherInformation(…) :
String
actionType=after
optional=false
ack=true
recordFile=logFL
policyID=log
actionType=instead
optional=true
ack=false
realTimeURL=CNNWeathe
r
policyID=RealTime
actionType=instead
optional=false
ack=true
username=uName
password=pw
policyID=SecurityToken
policyDoc=SecurityUri
Figure 29–Service TouristService (Ortiz et al., 2006a)
Après la modélisation de l‟application en se basant sur le profil UML défini, un processus de
transformation a été défini. Ce dernier se base sur le profil défini pour l‟élaboration du PIM.
Légende :
CT : Conforms To
Figure 30–Processus de transformation ATL (Ortiz et al., 2006a)
Ensuite, ce PIM sera transformé vers les PSMs suivants : Policy Model, AOP model et SOAP
Tag Model. La figure 30 présente le processus de transformation.

56
Etat de l’art
Le processus de transformation permet de transformer le PIM élaboré en se basant sur le profil
UML. Le métamodèle de ce profil doit être conforme au MOF. Pour pouvoir le transformer vers
des plateformes technologiques (aspect, SOAP Tag et Policy) dans le cadre de l‟approche MDA,
il est nécessaire de définir leurs métamodèles comme le montre les figures suivante. La figure 31
présente le méta modèle utilisé pour la génération des tags SOAP.
SoapTagElement
-name : String
Package +packagess + classes PrimitiveType
SoapTagClass
-target : String
-value : String
-side : String
-providerName : String
Figure 31–Métamodèle cible SOAP (Ortiz et al., 2006a)
La figure 32 est utilisée pour la génération des aspects. La figure 32 illustre le méta modèle
utilisé pour la génération des politiques
-name : String
PolicyElement
Package +packagess + classes
PolicyClass
PrimitiveType
I.6.3.2
-opt : String
-acronym : String
-target: String
-targetName : String
-policyRefrence: String
-interface : String
-service: String
Figure I-32-
Figure 32–Métamodèle Policy (Ortiz et al, 2006a)
Approches de gestion des droits d’accès
Alam et al. (Alam et al., 2007a) présentent un framework dirigé par les modèles pour la gestion
de la sécurité des systèmes orientés services. La spécificité de tel framework est la gestion des

57
Etat de l’art
droits d‟accès des utilisateurs non pas au niveau technologique mais au niveau modèle métier,
c'est-à-dire à un haut niveau d‟abstraction. Pour ce faire, le framework se base principalement sur
un profil UML appelé SECTET-UML et sur un langage spécifique au domaine appelé SECTET-
PL pour l‟élaboration des modèles métiers tout en y associant les informations des droits d‟accès
des utilisateurs. Le framework permet dans un deuxième lieu la génération de politiques d‟accès
ciblant une plateforme technologique particulière à savoir le XACML.
SECTET-UML (Hafner et al., 2009) est un profil UML permettant la modélisation des services
et de leurs interfaces, des informations échangées entre services ou entre clients de services ainsi
que les droits d‟accès statiques. Ce profil définit un ensemble de stéréotypes étendant des
métaclasses UML comme le montre le tableau 6. Ces différents stéréotypes sont utilisés pour
l‟élaboration de quatre modèles définis dans le cadre de ce framework : le modèle des interfaces,
le modèle des documents, le modèle des droits d‟accès et le modèle des rôles.
Le modèle des interfaces (Interface Model) définit un ensemble d‟opérations abstraites fournies
par chaque service à ses clients.
Le modèle des documents (Document Model) permet de décrire les différents types de données
échangés entre les différents partenaires dans le cadre d‟un SOS.
Stereotype
Metaclase UML
Package
Package
Interface
Package
Class
Class
Package
Attribute
Class
Interface
Package
Constraint
Tableau 6–Stéréotypes du profil SECTET-UML (Alam et al., 2008)
Le modèle de rôles (Role Model) permet de décrire les différents rôles ainsi que les droits
d‟accès y associés en se basant sur les diagrammes de classes UML.
Le profil SECTET-UML ne permet de modéliser que les droits d‟accès statiques, il ne permet
pas la gestion des droits d‟accès dynamique. Pour faire face à cette lacune, le langage spécifique

58
Etat de l’art
au domaine SECTET-PL est défini. SECTET-PL associé au profil SECTET-UML , est un
langage à base de prédicats inspiré du langage OCL qui permet d‟exprimer des politiques des
droits d‟accès dynamiques indépendamment des technologies.
SECTET-UML et SECTET-PL permettent d‟exprimer les droits d‟accès des différents
utilisateurs d‟un système orienté service loin de toute technologie. Pour cibler une technologie
particulière, des règles de transformations QVT ont été définies pour la génération des politiques
d‟accès XACML. Ces transformations ont été effectuées en se basant sur les métamodèles des
différents modèles ainsi que le métamodèle de la technologie cible à savoir la technologie
XACML. La figure 33 montre le métamodèle des différents modèles définis au niveau PIM. La
figure 34 illustre le métamodèle XACML.
Figure 33–Métamodèle de SECTET-UML(Hafner et al.,2009)

59
Etat de l’art
Figure 34–Métamodèle XACML
Pour la génération des politiques d‟accès XACML, le framework adopte deux transformations :
une transformation modèle à modèle et une transformation modèle à code.
I.6.3.3 Approches de gestion de la qualité de services
D‟ambrogio et al. (D‟ambrogio, 2007) proposent une extension du standard WSDL appelé Q-
WSDL pour la gestion des propriétés de la qualité des services requise par chaque client de
service. Cette extension du standard WSDL est effectuée en se basant sur les standards et les
principes de l‟approche MDA. Q-WSDL est utilisé principalement pour :
Spécifier les exigences de la qualité de services associée aux différents services
composant un système donné.
Ajouter les propriétés de la qualité de services lors de la recherche des services web dans
un annuaire UDDI.
Définir les SLS (Service Level Specification) lors de l‟établissement des SLA (Service
Level Agreement)

60
Etat de l’art
Automatiser la transformation des descriptions WSDL vers des descriptions Q-WSDL
Supporter la transformation des modèles UML vers des descriptions WSDL.
Dans l‟objectif de produire des documents Q-WSDL, un processus se composant d‟un ensemble
d‟étapes a été défini. Ce processus se base principalement sur les modèles et les transformations
des modèles comme le montre la figure 35.
MOF
Model
Meta-Metamodel Layer
WSDL
XML
Schema
XMI
WSDL
Metamodel
Metamodel
transformation
Q-WSDL
Metamodel
XMI
Q-WSDL
XML
Schema
Metamodel layer
WSDL
Metamodel
WSDL
Metamodel
Model Layer
Q-WSDL
Model
Q-WSDL
Metamodel
Figure 35–Processus de développement dirigé par les modèles (D’ambrogio, 2007)
La première étape de ce processus consiste à élaborer le métamodèle de WSDL en s‟inspirant du
schéma de WSDL. Cette étape se base sur des règles XMI (OMG, 2002b) et peut être
automatisée entièrement.
La deuxième étape du processus consiste en la définition d‟une extension du métamodèle WSDL
pour définir le métamodèle de Q-WSDL en intégrant les propriétés de qualité de service telles
que la performance, la disponibilité, le débit, etc. Le métamodèle Q-WSDL a été défini en
s‟inspirant principalement de deux profils UML : UML Profile for QoS and fault tolerance
(OMG, 2005a) et UML Profile for Schedulability, Performance and Time (OMG, 2005b). Il est
utilisé pour faciliter la transformation d‟un modèle WSDL vers un modèle Q-WSDL dans le
cadre de l‟approche MDA via la définition d‟un ensemble de règles de transformation. La
troisième étape définie dans le cadre de ce processus est la génération des documents Q-WSDL
suivant le métamodèle de Q-WSDL.

61
Etat de l’art
I.6.3.4
Approches d’adaptation au contexte
Dans le cadre de l‟approche MDA, plusieurs approches ont été proposées pour le
développement des SOS contextuels. Ainsi, (Sheng et al., 2005) ont défini un profil UML
appelé ContextUML pour la formalisation et la conception des SOSs contextuels. ContextUML
se fonde sur un ensemble de stéréotypes (e.g., Context, ContextSource, ContextService,
ContextServiceCommunity, ContextServiceCommunity, CAMechanism, etc. ) permettant d‟aider
les concepteurs à l‟élaboration des modèles contextuels.
Dans le même objectif que (Sheng et al., 2005), Maamar et al.(Maamar et al., 2006) ont défini
une approche dirigée par les modèles pour le développement des SOSs contextuels. Selon
Maamar et al.( Maamar et al., 2006), cette approche se diffère notamment de la proposition de
(Sheng et al., 2005), en trois points : (i) la proposition de Maamar et al. étend les spécifications
associées à la technologie des services web au niveau métamodèle (ii) l‟approche définie, traite
les caractéristique du contexte de façon générique (ii) les caractéristiques du contexte sont prises
en compte tout au long du cycle de vie du service, (e.g., définition, publication, invocation).
L‟approche proposée se fonde essentiellement sur deux éléments : le premier élément est un
profil UML appelé, lui aussi, ContextUML permettant la modélisation des SOS contextuels.
Ce profil définit les stéréotypes suivants : Subject, CompositeSubject, AtomicSubject, Context,
Visibilty, Visibility, VisibilityConstraint, Action et Description. La figure 36 présente le
métamodèle du profil contextUML.
Figure 36–Métamodèle ContextUML (Maamar et al., 2006)

62
Etat de l’art
I.6.3.5
Discussion
L‟ingénierie logicielle dirigée par les modèles et la technologie des services web ont émergé
récemment pour le développement des SOS complexes et à large échelle. Le fait de combiner
entre ces deux approches apporte plusieurs avantages, entre autres : l‟amélioration de la
productivité, la facilitation de l‟évolution aussi bien technologique que métier, l‟agilité des
systèmes et leur portabilité et interopérabilité.
Nos constats sur l‟utilisation de l‟approche MDA pour le développement des SOS peuvent se
résumer comme suit :
l’absence d’un langage standard et unique pour l‟élaboration des PIM. En fait,
plusieurs formalismes, profils UML et DSL, ont été proposés pour la description des
PIM. Dans cette perspective, nous constatons l‟utilisation d‟UML (Bézévin et al., 2006)
(Gronmo et al., 2004b), d‟EDOC( Patrasciuo, 2004) (Bézivin et al., 2004) (Yu et al.,
2007), du DSL SECTET-PL(Alam et al., 2007a), d‟un profil UML à base de SCA(Ortiz
et al., 2006a) (Ortiz et al., 2006b)et du profil pour la Qos (D‟amborogio et al., 2007).
L’absence d’un langage de transformation unique pour la définition de transformation
malgré la standardisation par l‟OMG de QVT comme un langage de transformation de
modèles. Dans la littérature, plusieurs autres langages ont été utilisés tels que ATL
(Bézévin et al., 2004) (Ortiz et al., 2006a), YATL(Patrasciou et al., 2007) ou QVT( Yu et
al., 2007).
Certaines approches permettent la prise en compte de l’utilisateur final au niveau PIM. Dans
cette optique, (Alam et al, 2007a) proposent un DSL (SECTET-PL) permettant la modélisation
des droits d‟accès des utilisateurs le plus tôt dans le cycle de développement des SOS. Ensuite,
une automatisation de la génération des politiques XACML via un ensemble de règles de
transformations. De telles politiques permettent la gestion des droits d‟accès des utilisateurs
interagissant avec le service. Dans le même objectif, c‟est à dire, la prise en compte de
l‟utilisateur final, D‟ambrogio permet la description de la Qos requise en utilisant le profil UML.
Ensuite, et en s‟inscrivant dans le carde des standards et concepts MDA, une génération de code
ciblant le QWSDL (D‟ambrogio, 2007), une extension de WSDL pour la gestion de la Qos
requise par les différents utilisateurs de services. Quant à (Ortiz et al., 2006a), ils proposent une

63
Etat de l’art
approche MDA pour la prise en compte des propriétés non fonctionnelles (sécurité, temps réel,
loging, etc). Cette approche se fonde principalement sur la description des propriétés non
fonctionnelles en se basant sur un profil UML à base de SCA pour la description des propriétés
non fonctionnelles au niveau PIM, ensuite une génération de code ciblant les plates-formes
technologiques (Aspect, SOAP, politiques, JAX-RPC). L‟approche définie par (Maamar et al.,
2007) se base sur le profil contextUML comme formalisme pour la spécification des
caractéristiques du contexte. Cette approche ne traite pas la génération automatique du code
selon les principes et les standards de l‟approche MDA.
I.7.
Synthèse générale
Les travaux présentés dans ce chapitre «Etat de l‟art» s‟articulent autour de trois axes principaux:
(i) les approches de modélisation des systèmes orientés services
(ii) les approches d‟adaptation des SOSs
(iii) les approches de développement dirigées par les modèles des SOSs.
Les approches de modélisation ont défini des formalismes qui visent la spécification des SOSs
indépendamment des technologies (dotNet, JWSDP, etc.) et des standards (SOAP, WSDL,
UDDI, BPEL4WS, etc.). La définition de ces formalismes est d‟une importance capitale pour la
maitrise de la complexité inhérente au développement des SOSs.
En ce qui concerne les approches d‟adaptation des services, plusieurs propositions ont vu le jour.
Elles ont visé la prise en compte des différentes dimensions des besoins de l‟utilisateur final. De
telles préoccupations concernent particulièrement le contexte de l‟utilisateur, la Qos, la gestion
des droits d‟accès ainsi que les propriétés non-fonctionnelles.
Les approches MDA de développement des SOSs ont pour objectif de profiter des avantages de
MDA (e.g., amélioration de la productivité, capitalisation des modèles métiers, amélioration de
la portabilité et de l‟interopérabilité). Ces approches se fondent sur les concepts et les standards
de l‟approche MDA pour la génération du code automatiquement à partir des modèles métiers.

64
Etat de l’art
Le tableau 7 suivant présente une synthèse des différentes approches étudiées dans le cadre de
cet état de l‟art. Nous avons défini quatre critères pour faire comparer ces différentes approches :
le formalisme/langage de modélisation utilisé pour la spécification des SOS, la prise en compte
de l‟utilisateur (Oui, Non explicite), le niveau de prise en compte de l‟utilisateur (Le niveau PIM
ou le niveau PSM), la préoccupation prise en compte de l‟utilisateur (Contexte, Droits d‟accès,
Profils de l‟utilisateur, etc.) et aussi le critère de la génération automatique de code.
approche
Stojanovic et
al.(Stojanovic
et al, 2004)
Zhang et
al.(Zhang et
al., 2006)
Biesegel et
al.(Biesegel
et al., 2005)
Johnston
(LÓPEZ
SANZ ET
AL., 2008 )
SoaML(OM
G, 2009)
Formalisme de
modélisation
UML, service
component
Profil UML
pour SOA
SoaML
Automatisation
de génération
de code
La prise en
compte de
l‟utilisateur
Le niveau
de prise en
compte des
utilisateurs
Oui Non -- --
Oui Non explicite -- --
Préoccupation(
s) prise(s) en
compte
(Fuchs ,
2004)
(Benslimane
et al., 2005)
(Maamar et
al., 2006)
(Sheng et al.,
2005)
(Lopezvelasco
et
al.,2005)
(kouadri
mostéfaoui et
al., 2006)
Pas de
formalisme
Non Oui PSM --
SCD Non Oui PIM Contexte
ContextUML Non Oui PIM Contexte
ContextUML Non Oui PIM Contexte
-- Non Oui PSM Contexte

65
Etat de l’art
VPL UML Oui Oui PIM Droits d‟accès
Tao tao et al.,
2007)
Machine à
états
Non Oui PIM Profil de
l‟utilisateur
Chang et al. Notation
spécifique
Non Oui PIM Profil de
l‟utilisateur
( Bézivin et UML/EDOC Oui Non explicite -- --
al., 2004
(Patrasciou EDOC Oui Non explicite -- --
al., 2004)
(Gronmo et UML Oui Non explicite -- --
al., 2004a)
(Yu et al., EDOC Oui Non -- --
2007)
(Ortiz et al.,
2007)
Profil UML Oui Oui PIM Aspects non
fonctionnels
Alam (Alam SECTET-PL Oui Oui PIM Droits d‟accès
et al. 2007a)
(Alam et al.
2007b)
(D‟ambrogio
et al., 2007)
Non défini Oui Oui PIM Qos
Tableau 7–Synthèse des différentes approches étudiées
Comme nous le montre le tableau, il n‟y a aucune approche d‟ingénierie des SOSs adaptables qui
définisse un formalisme/langage prenant en compte le profil de l‟utilisateur ou de son contexte
tout en permettant la génération automatique du code conformément aux principes et standards
de l‟approche MDA. La majorité de ces propositions ne se fondent pas sur des
formalismes/notations adaptés à la spécification des SOSs Adaptables. En outre, elles ne
permettent pas la génération automatique du code en respectant les standards de l‟approche
MDA.
Plus concrètement, l‟approche définie par (Maamar et al., 2005)(Benslimane et al. 2005) et
l‟approche définie par (Fink et al., 2003) ne permettent pas la génération automatique de code.
En ce qui concerne l‟approche définie par (Fuchs, 2004) qui se base sur les vues pour
l‟adaptation des services aux types des utilisateurs (Interne/Externe), elle ne définit aucun
formalisme pour la spécification des SOSs à un haut niveau d‟abstraction. Une telle approche
prend en compte l‟utilisateur tard dans le cycle de développement, c‟est à dire au niveau code.

66
Etat de l’art
Les approches à base de la variabilité de service (Chang et al., 2007a) permettent le
développement des SOSs adaptables en prenant en compte le profil de l‟utilisateur tout au long
du cycle de développement. Cependant, cette proposition ne définit aucun formalisme pour la
spécification des SOSs adaptables et elles ne permettent pas la génération automatique de code.
L‟approche d‟adaptation à base du concept du service différencié (Tao et al., 2007) se base sur
les machines à états finis pour la prise en compte des profils des utilisateurs interagissant avec le
service. Cette approche prend en compte l‟utilisateur le plus tôt dans le cycle de développement.
Toutefois, cette approche ne fournit aucun formalisme qui vise la représentation de la structure
statique d‟un SOS. De plus, elle ne permet pas la génération automatique du code.
Les approches qui ont visé l‟extension des standards associés à la technologies des services web
tels que les travaux (lopez-velasco et al, kouadri mostéfaoui et al., 2006) (Maamar et al., 2006)
pour la prise en compte du profil de l‟utilisateur ou de son contexte pour l‟adaptation des
services posent plusieurs problèmes : (i)ces extensions ne sont pas accessibles et
incompréhensibles aux différents stakeholders s‟intéressant au développement des SOSs vu leur
verbosité ainsi que leur bas niveau d‟abstraction (ii) le manque de l‟automatisation de la
génération de code correspondant aux extensions apportées à ces standards pénalise largement le
développement des SOSs adaptables vu que le codage manuel de ces extensions est un exercice
complexe, fastidieux et «error-prone». Par conséquent, il est nécessaire d‟offrir des formalismes
et des notations facilement compréhensibles par les différents stakeholders et permettant
l‟automatisation de la génération de code. Ce qui permet l‟amélioration de la productivité et une
meilleure compréhension des SOS par les différentes stakeholders.
Contrairement aux approches d‟adaptation, les approches de modélisation des SOSs ont défini
différents formalismes pour la spécification des SOSs telles que les travaux à base de Service
Component (Stojanovic et al, 2004) (Zhang et al., 2006), à base de Service Component
Architecture (Biesegel et al., 2005) et à base de profils visant la modélisation des SOSs(Johnston
et al., 2006) (LÓPEZ SANZ ET AL., 2008 et al., 2006) (Zeid et al.,2004). De telles approches
ne prennent pas en compte l‟utilisateur final explicitement au début du cycle de développement.
Les approches définies dans le cadre de MDA permettent l‟automatisation de la génération du

67
Etat de l’art
code. Toutefois, ces approches adoptent des formalismes qui ne sont pas adaptés à la
spécification des SOSs. Elles se fondent sur le langage UML ou le profil EDOC. Or, ces deux
formalismes ne sont pas définis pour la modélisation des systèmes orientés services. En outre, ils
ne permettent pas la prise en compte de l‟utilisateur au niveau PIM.
Concernant les approches MDA de développement des SOSs tout en prenant en compte
l‟utilisateur final, plusieurs propositions ont été définies. Ainsi, pour la prise en compte de la
qualité de service, D‟ambrogio (D‟ambrogio, 2007) s‟est basé sur un profil UML pour la
spécification de la Qos. Le formalisme défini ne permet pas la spécification des SOS. Il se
focalise seulement sur la représentation des caractéristiques de la qualité de service. L‟approche
définie par (Alam et al., 2007a) (Alam et al. 2007b) se fonde sur un DSL dédié pour la gestion
des droits d‟accès. Elle ne définit aucun formalisme pour la spécification des aspects statiques et
dynamiques d‟un SOS. Quant à l‟approche définie par (Maamar et al., 2007), elle définit le
profil contextUML comme formalisme pour la spécification du contexte. Cette approche
n‟adopte pas les standards de l‟approche MDA pour la génération du code.
L‟approche définie par (Ortiz et al., 2006a) traite les aspects non-fonctionnels (temps réels,
login, etc). Certes, l‟approche permet la génération automatique du code suivant les standards et
les principes de l‟approche MDA, cependant le profil défini ne permet pas la prise en compte du
profil de l‟utilisateur mais elle prend en compte uniquement des aspects non fonctionnels.
Pour répondre à la problématique de l‟ingénierie des systèmes orientés services, d‟une part, et
l‟adaptation de tels systèmes à leurs utilisateurs finals, d‟autre part, notre travail de thèse cible à
proposer une approche d‟ingénierie dirigée par les modèles pour le développement des SOSs
adaptables. Une telle approche se base sur :
(i) Un profil UML pour la modélisation et la spécification de ces systèmes tout en prenant en
compte l‟utilisateur le plus tôt dans le cycle de développement. Ce profil définit les différents
éléments de modélisation capables de représenter les différents artefacts d‟un SOS adaptables.
(ii)Un processus de développement définissant les phases, les activités, les artefacts pour le
développement des SOSs Adaptables.

68
Etat de l’art
(iii)Un outil logiciel défini dans le cadre de l‟approche MDA, permettant la génération du code à
partir des modèles métier via un ensemble de règles de transformation.
Dans le chapitre suivant, nous présentons notre profil UML défini pour la modélisation des SOSs
adaptables. Ce profil constitue le premier élément de notre approche d‟ingénierie des SOSs
adaptables.

69 VSoaML : Un profil UML de modélisation des systèmes orientés services adaptables
II. VSoaML : Un profil UML de modélisation des systèmes orientés
services adaptables
II.1. Introduction
La modélisation joue un rôle fondamental dans la maitrise de la complexité inhérente au
développement des systèmes logiciels. Actuellement, la modélisation s‟est positionnée au centre
du cycle de développement de ces systèmes notamment avec l‟émergence du paradigme MDD
(Model Driven Development) et plus particulièrement de l‟approche MDA. MDA définit une
panoplie très complète de standards et de technologies permettant la facilitation du
développement, de l‟intégration, de l‟évolution et de la maintenance des systèmes en considérant
les modèles comme des entités de première classe dans le processus du développement du
logiciel. Dans le contexte du MDD, les modèles apportent plusieurs avantages, entre autres : (i)
la facilitation de communication entre les différents stakeholders s‟intéressant au développement
d‟un projet informatique (ii) l‟amélioration de la productivité en permettant la génération
automatique du code à partir des modèles métiers de haut niveau (iii) la facilitation de
l‟évolution (technologique ou métier) et de la maintenance.
Pour tirer bénéfice des modèles dans le développement des systèmes logiciels dans le cadre du
SOC, plusieurs approches de modélisation ont été proposées pour la spécification des Systèmes
Orientés Services indépendamment des standards (WSDL, BPEL) et des plates-formes
d‟implémentation (dotNet, J2EE, etc.), comme nous l‟avons présenté dans le chapitre I. En effet,
le développement des systèmes orientés service est généralement basé sur la technologie des
services web qui fournit une infrastructure incluant les standards WSDL, SOAP, UDDI et
BPEL4WS lesquels permettent respectivement la description, l‟invocation, la
découverte/publication et la composition de services. Certes, les technologies et les standards
sont très importants pour l‟implémentation et le déploiement de tels systèmes, mais ils sont
insuffisants pour le développement des systèmes d‟informations d‟entreprises complexes et
distribués, vu que les différents stakeholders (les analystes métiers, les architectes, les utilisateurs
finals, les développeurs, etc.) n‟ont pas forcément de connaissances techniques.

70 VSoaML : Un profil UML de modélisation des systèmes orientés services adaptables
Par conséquent, il est nécessaire d‟avoir un formalisme/notation, à l‟instar de UML pour les
approches orientées objets permettant de représenter les services et de leur chorégraphie à un
haut niveau d‟abstraction pour qu‟ils soient compréhensibles par les différents stakeholders
s‟intéressant au développement d‟un système à base de services.
Par ailleurs, la prise en compte de l‟utilisateur final est devenue une préoccupation majeure dans
le développement des systèmes orientés services surtout avec l‟émergence de l‟informatique
sensible au contexte (Dey, 2000). Dans cette optique, plusieurs approches ont été proposées
visant la prise en compte des différentes dimensions des besoins des utilisateurs finals. De telles
approches se basent sur de nouveaux concepts (Toa et al., 2007) (Bouguettaya et al., 2009) de
nouvelles architectures (Rolland et al., 2007) (Chang et al., 2006) ou de nouvelles technologies
(Kouadri Mostefaoui et al., 2005)(Lopez-velasco et al., 2005)(Keidl et al., 2004). Ces approches
ne définissent pas les formalismes et notations pour la prise en compte assez tôt de l‟utilisateur
final dans le cycle de développement des systèmes orientés services.
Dans la perspective de la modélisation des systèmes orientés services, d‟une part, et la prise en
compte de l‟utilisateur final, d‟autre part, nous proposons, dans le cadre de ce chapitre, un profil
UML pour la modélisation des systèmes orientés services adaptables aux différents types
d‟utilisateurs. Ce profil appelé VsoaML (View based Service Oriented Architecture Modeling
Language) se base principalement sur le concept de services multivues. Le service multivues
(Kenzi et al., 2008) est une entité de modélisation de première classe capable de représenter les
besoins des utilisateurs et leurs exigences au plus tôt dans le cycle de développement des
systèmes orientés services. Il permet la capture des besoins des utilisateurs et de leurs exigences
tout en séparant leurs préoccupations fonctionnelles. Pour ce faire, le service multivues fournit,
en plus des interfaces simples qui caractérisent le service, des interfaces de service capables de
décrire les capacités suivant le profil de l‟acteur interagissant avec le service.
En plus du concept de service multivues, le profil VSoaML définit différents stéréotypes dans
l‟objectif de spécifier et modéliser les aspects structurels et comportementaux des systèmes
orientés services adaptables aux différents types d‟utilisateurs. VSoaML permet de représenter
les services constituant un SOS, leurs interfaces, leurs opérations ainsi que leurs messages
d‟entrée/sortie. Il permet aussi de modéliser les différents processus métiers comme des

71 VSoaML : Un profil UML de modélisation des systèmes orientés services adaptables
collaborations de services pour répondre à des exigences complexes auxquels un seul service ne
peut pas répondre.
Ce chapitre est organisé comme suit : La section 2 décrit notre étude de cas concernant un
système d‟enseignement à distance. La section 3 présente le concept de service multivues comme
un élement clé de notre approche. La section 4 illustre les différentes couches d‟abstractions que
nous avons définies pour la spécification des SOSs adapatables en se basant sur le service
multivue. La section 5 présente notre profil VSoaML pour la modélisation des systèmes orientés
services en définissant les stéréotypes de ce profil ainsi que son métamodèle. La section 6
présente la modélisation du système d‟enseignement à distance en utilisant notre profil VSoaML.
II.2. Exemple illustratif : Le système d’enseignement à distance
Notre étude de cas est une version simplifiée d‟un Système d‟enseignement à distance (DLS-
Distance Learning System) (Nassar et al., 2005). Notre objectif est d‟utiliser ce système tout en
l‟étendant avec des nouvelles fonctionnalités inspirée du systéme d‟enseignement à distance
Moodle (http://docs.moodle.org/fr/Accueil). Ce système est en interaction potentiellement avec
trois acteurs : l‟étudiant, l‟enseignant et l‟administrateur. Pour chaque acteur, il fournit les
fonctionnalités qui correspondent à ses besoins. Ainsi, le système fournit les fonctionnalités
nécessaires à l‟étudiant pour faire son inscription. Il lui permet de suivre les formations,
d‟accéder aux exercices, de poser les questions, de consulter les projets d‟une formation donnée,
de faire des quiz et d‟envoyer des messages aux forums de discussion spécifiques à une
formation donnée, de passer les examens, de télécharger le sujet des examens, de poser les
questions de compréhension et de consulter ses notes. Il permet aussi aux étudiants de
télécharger les documentations nécessaires (fichiers pdf, audio/video, etc).
Quant à l‟enseignant, il utilise le système pour créer des cours, pour répondre aux questions des
étudiants, pour proposer des exercices et pour répondre aux messages des forums de discussion.
Il utilise aussi le système pour charger les documents concernant une formation spécifique ainsi
que pour la mise à jour ou la suppression des contenus des cours.
Le système permet à l‟administrateur de gérer les inscriptions des étudiants, de fixer les frais

72 VSoaML : Un profil UML de modélisation des systèmes orientés services adaptables
d‟inscription aux différentes formations et de décider des inscriptions des étudiants. L‟acteur
administrateur utilise le système pour fixer les frais d‟une formation donnée, pour gérer le
calendrier d‟une formation et pour affecter les responsables des formations. Il permet à
l‟enseignant de proposer un examen et de répondre aux questions des examens.
La figure 37 illustre les différents cas d‟utilisation de ce système.
II.3. Le concept de service multivues
Figure 37–Diagramme des cas d’utilisation du DLS
L‟objectif de cette section est de présenter le concept de service multivues qui a été introduit
comme un moyen de flexibilité et d‟adaptabilité. Pour ce faire, nous introduisons tout d‟abord le
concept de vue. Ensuite, nous présentons le concept de service multivues comme une

73 VSoaML : Un profil UML de modélisation des systèmes orientés services adaptables
combinaison entre le concept de vue et le concept de service.
II.3.1. Le concept de vue
Le concept de vue est largement utilisé dans plusieurs domaines de l‟informatique tels que les
systèmes de gestion de base de données (Abiteboul et al., 1991), les systèmes de gestion des
Worflows (Chebbi et al., 2006), les approches orientées objet (Coulette et al., 1996)(Kriouile et
al., 1995) et tout récemment dans le domaine de la technologie des services (Fuchs, 2004)
(Maamar et al., 2005).
Dans le cadre de l‟utilisation des vues pour le développement des applications orientées objet,
notre équipe a défini la méthode VBOOM (View Based Oriented Object Method) (Kriouile,
1995) pour analyser et concevoir des applications orientées objet en se basant sur le concept de
vue. VBOOM définit un processus itératif et récursif de trois phases, chacune d'elles étant
composée de trois étapes. Elle possède aussi un atelier de génie logiciel appelé VBTOOL (Hair
1997, Marzak 1997, Hair et al. 1998). Dans l‟objectif de situer la méthode VBOOM dans le
cadre du standard UML et de faire face à ses limites (e.g., Subjectivité dans la définition des vues,
Manque d'outils performants pour le support à VBOOM, etc.), un profil UML appelé VUML(View
Based Unified Modeling Language) a été défini. VUML se base sur les vues. Il offre un
formalisme étendant celui d‟UML et une démarche inspirée de celle de la méthode VBOOM
(Nassar, 2004). L‟ajout principal à UML est le concept de classe multivues qui est composée
d‟une base (partie partagée par tous les acteurs) et d‟un ensemble de vues (extensions de la base).
Chaque vue correspond aux besoins spécifiques d'un acteur (utilisateur final, développeur, ...).
VUML offre des mécanismes pour gérer les droits d‟accès aux classes multivues, spécialiser une
classe multivues, spécifier les dépendances entre les vues, assurer la cohérence du modèle en cas
de mises à jour, administrer les vues à l‟exécution, etc. En plus du concept de classe multivues,
VUML introduit aussi le concept de composant multivues (El Asri, 2005) permettant de
représenter une classe multivues au niveau du diagramme des composants. La spécificité d‟un
composant multivues est la possibilité d‟avoir des interfaces dont l‟accessibilité et le
comportement changent dynamiquement selon le point de vue de l‟utilisateur courant du
système.

74 VSoaML : Un profil UML de modélisation des systèmes orientés services adaptables
Dans le but d‟accompagener l‟évolution de l‟ingénierie logicielle vers le paradigme SOC, nous
adoptons le concept de vue comme un moyen permettant la séparation des préoccupations
fonctionnelles. Les vues permettent la mise en évidence de ce qui est attendu par un utilisateur
donné. En général, les vues apportent les avantages suivants (Maamar et al., 2005) :
Elles améliorent la sécurité en cachant les éléments de la spécification des
services variant d‟un utilisateur à un autre.
Elles fournissent une flexibilité en identifiant les spécifications de services
adaptées à chaque type de client en tenant compte son profil.
Elles fournissent différentes perspectives aux différents utilisateurs avec
différents niveaux d‟abstraction.
Dans cette thèse, nous proposons l‟utilisation des vues comme mécanisme de séparation de
préoccupations fonctionnelles, de flexibilité et d‟adaptabilité.
II.3.2. Le service multivues
SOC a pour objectif le développement et la maintenance des applications distribuées
interopérables et agiles en optimisant les délais et les coûts. SOC se base sur le concept de
service comme un élément fondamental pour le développement des Applications/Solutions. En
SOC, le service est défini comme un élément informatique indépendant de la plateforme et
autonome (self-contained) permettant le support de la composition des applications distribuées
en couplage faible facilement et à moindre coût. Chaque service possède une description qui peut
être publiée dans un annuaire de service. En se basant sur cette description, un client de service
peut découvrir le service qui correspond à ses besoins pour pouvoir construire des applications
composites à valeur ajoutée en faisant seulement la composition des applications existantes. Les
applications à base de services sont développées comme des ensembles indépendants de services
qui interagissent en fournissant des interfaces bien définies avec leurs utilisateurs potentiels.
En SOC, un service peut interagir avec plusieurs utilisateurs ayant chacun un profil bien
déterminé. Chaque client de service avec un profil donné, a des besoins spécifiques que le
service doit y répondre. Dans le but d‟assurer une large utilisation, de la flexibilité et de
l‟adaptabilité, le service doit fournir les fonctionnalités requises qui correspondent aux besoins

75 VSoaML : Un profil UML de modélisation des systèmes orientés services adaptables
des utilisateurs l‟invoquant. De ce fait, le problème central qui se pose, au niveau
Analyse/Conception des systèmes orientés services, est comment modéliser l‟aspect
multidimensionnel des besoins des utilisateurs interagissant avec le service. La figure 38 montre
la diversité des types de clients qui peuvent interagir avec le service.
Publish
Publish
Annuaire de
Services
Publish
Publish
Find
Find
Find
Find
Client de
service 1
Client de
service 2
Client de
service 3
Client de
service M
Invoke
Invoke
Invoke
Invoke
Invoke
Invoke
Invoke
Invoke
Invoke
Service 1
Service 2
Service 3
Service N
Description
Description
Description
Description
Implémentation
Implémentation
Implémentation
Implémentation
Figure 38–Modèle d’interaction des services avec leurs clients
Pour faire face à ce problème, nous proposons le concept de service multivues (Kenzi et al.,
2007) (Kenzi et al., 2008a) (Kenzi et al., 2008b) comme une entité de modélisation de première
classe. Une telle entité permet la modélisation des besoins des utilisateurs et de leurs exigences
tout au début du cycle de développement des systèmes orientés services en séparant leurs
préoccupations fonctionnelles. Pour ce faire, le service multivues fournit/requiert un ensemble
d‟interfaces de service visuelles(ViewServiceInterface). Chaque interface de service

76 VSoaML : Un profil UML de modélisation des systèmes orientés services adaptables
visuelle(ViewServiceInterface) permet de décrire les capacités du service fournies/requises
suivant le profil de l‟acteur interagissant avec le service. L‟intersection des différentes interfaces
visuelles constitue une interface de service de base (baseServiceInterface) qui est accessible à
tous les acteurs interagissant avec le service. L‟interface ViewServiceInterface dépend de la
baseServiceInterface dans le sens où les fonctionnalités de la base sont implicitement incluses
dans toutes les interfaces de service vues (ViewServiceInterface). Les interfaces de service vues
(ViewServiceInterface) et l‟interface de service de base (baseServiceInterface) sont regroupées
dans un package que nous appelons interface de service multivue (MVServiceInterface).
A la conception, un service multivues possède un ensemble d‟interfaces de service vues. A
l‟exécution, un service multivues se comporte comme un service régulier avec des interfaces
régulières dont la définition à un moment donné est le résultat de la combinaison des
fonctionnalités incluses dans l‟interface de service de base et les fonctionnalités incluses dans les
interfaces de service vues qui correspondent à l‟acteur actif.
La figure 39 illustre la métamodèle de l‟interface de service multivues.
Figure 39–Métamodèle de l’interface MVServiceInterface

77 VSoaML : Un profil UML de modélisation des systèmes orientés services adaptables
Dans le cadre de notre cas d‟étude, nous avons identifié le service multivues Formation. Ce
service multivues est en interaction avec trois acteurs : Enseignant, Etudiant et Administrateur
(cf. figure 40). Chaque acteur a ses propres besoins auxquels le service doit répondre. Le service
multivues est spécifié par la spécification ‘‘Formation’’. Une telle spécification contient la
description de l‟interface de service de base qui reflète les fonctionnalités communes accessible
aux trois acteurs qui interagissent avec le service Formation et les fonctionnalités spécifiques à
chaque acteur encapsulées dans les interfaces «ViewServiceInterface». Ainsi, les trois acteurs
peuvent invoquer les opérations définies dans l‟interface de service de base « Formation »
composée principalement des opérations suivantes : consulterSynopsisFormation et
consulterListFormation permettant respectivement aux différents acteurs d‟avoir un synopsis
d‟une formation donnée et de voir la liste des cours fournis par un DLS. Par ailleurs, les
interfaces "ViewServiceInterface" Formation_administrateur, "ViewServiceInterface"
Formation_Etudiant et "ViewServiceInterface" Formation_Enseignant associées respectivement
à l‟Administrateur, l‟Etudiant et l‟Enseignant ne sont accessibles qu‟à leurs acteurs associés.
Plus précisément, l‟acteur administrateur peut invoquer seulement les opérations appartenant à
"ViewServiceInterface" Formation_Administrateur. Un acteur Etudiant peut invoquer seulement
les opérations "ViewServiceInterface" Formation_Etudiant et un acteur Enseignant peut
invoquer seulement les opérations appartenant à l‟interface "ViewServiceInterface"
Formation_Enseignant.
La figure 40 montre l‟interface de service multivues du service multivues «Formation».
Formation
Formation_Enseignant
CreerFormation()
supprimerFormation()
ajouterExercice()
ajouterSolutionExercice()
proposerProjet()
poserQuestion()
proposerForum()
proposerTest()
proposerGroupeProjet()
consulterProjet()
ajouterAnnounceFormation()
respondreQuestions()
Formation_Etudiant
consulterFormation()
consulterExercice()
proposerSolutionExercice()
posterMessage()
proposerSoultionTest()
consulterRessourceProjet()
consulterProjet()
consulterAnnounceFormation()
Formation_Administrateur
ajouterNouvelleFormation()
ajouterAgendaFormation()
ajouterAnnounceFormation()
supprimerFormation()
affecterResponsableFormation()
Formation_base
consulterSynopsisFormation()
consulterListFormation()
Figure 40–Interface de service multivues du service multivues «Formation »

78 VSoaML : Un profil UML de modélisation des systèmes orientés services adaptables
II.4. Les couches d’abstraction d’un SOS Adaptable
Un système orienté service se compose généralement de plusieurs couches. Chaque couche se
base sur les fonctionnalités de la couche sous-jacente pour mener à bien sa mission.
Concrètement, six couches ont été définies (Papazoglou, 2007) comme nous illustrons dans la
figure 41 :
La Couche Domaine métier: Cette couche permet la segmentation de l‟activité d‟une
organisation donnée, en un ensemble de domaines fonctionnels. Chaque domaine fonctionnel
définit un ensemble de processus métier qui partagent des ressources et des fonctionnalités et
peuvent collaborer pour atteindre les objectifs de haut de niveau de l‟entreprise. Un exemple de
domaines métier dans le cadre d‟une entreprise donnée, peut être le domaine fonctionnel finance,
assurance, comptabilité, etc.
La couche processus métier : La couche processus métier se compose d‟une multitude de
processus métier associés aux différents domaines métier. Chaque processus métier définit une
séquence d‟activités en vue de répondre pertinemment aux événements métier adressés à une
entreprise.
La couche Services métier : un processus métier se définit en termes d‟un ensemble d‟activités.
Chaque activité est automatisée par l‟exécution d‟un service donné. La couche service métier qui
constitue la troisième couche d‟un système orienté service se compose ainsi des différents
services constituant le système et permettant de supporter les différents processus métiers de
l‟entreprise. La couche services métier est la couche principale d‟un système orienté service. En
effet, le service est l‟élément fondamental permettant de réaliser et d‟automatiser les différentes
activités de l‟entreprise. Chaque entreprise peut être vue comme une interconnexion de services
qui s‟exécutent pour atteindre les objectifs métiers de haut niveau de l‟entreprise tout en
facilitant son évolution et son agilité.
La couche service d’infrastructure : la couche service d‟infrastructure assure des fonctionnalités
d‟infrastructure en se basant sur des services techniques de grosse granularité et réutilisable dans
le cadre de plusieurs processus métiers. Elle est responsable de la provision d‟une infrastructure
technique permettant le développement, la provision et la maintenance des services et des
processus métier tout en facilitant leur intégration. Elle est aussi responsable de la qualité de
services, de la messagerie fiable, du routage intelligent ainsi que de la supervision et la gestion

79 VSoaML : Un profil UML de modélisation des systèmes orientés services adaptables
de services. Pour assurer de telles fonctions, la couche service d‟infrastructure définit plusieurs
types de services : les services utilitaires, les services d‟accès, les services de management et de
monitoring ainsi que les services d‟interaction. D‟un point de vue technique, les fonctionnalités
de cette couche sont assurées généralement par un logiciel spécifique à savoir le bus de service
Figure 41–Couches fonctionnelles d‟un SOS (Papazoglou, 2007)
de l‟entreprise. En pratique, plusieurs ESB ont émergé récemment tels que Mule ESB, etc.
La couche implémentation : Chaque service possède une implémentation de service. Un service
fait une séparation entre la spécification de service et l‟implémentation de service. Une
implémentation de service est créée selon deux scénarios. Le premier scénario consiste à
développer un service en utilisant un langage de programmation donné tels que Java, C#, etc. Le
deuxième scénario est l‟adaptation des applications existantes.
La couche systèmes opératoires : Cette couche est utilisée par la couche « Implémentation des
services à base de composant» pour l‟implémentation des processus et des services. La couche
contient les systèmes existants et les applications tels que les systèmes de CRM, d‟ERP, les
SGBD et les applications existantes, etc.
Dans l‟objectif de maitriser la complexité du développement des systèmes orientés services
adaptables aux différents types d‟utilisateurs, il est nécessaire de définir des couches
d‟abstractions permettant de décrire les différents aspects (i.e., structurels ou comportementaux)

80 VSoaML : Un profil UML de modélisation des systèmes orientés services adaptables
de tels systèmes. Dans cette optique, nous avons défini plusieurs couches pour la représentation
des différentes perspectives adaptées aux différents stakeholders(e.g., Analyste métier,
Architecte, Développeur, Utilisateur final, etc.) d‟un SOS adaptable. Chaque couche se compose
d‟un ensemble de modèles qui correspondent aux besoins des différents stakeholders.
Globalement, nous identifions les couches suivantes :
La couche métier (Business Layer) : la couche métier est définie en se basant sur un ensemble
de modèles permettant de décrire les exigences métiers. L‟objectif de cette couche est la
spécification des exigences métiers. Principalement, cette couche se compose des modèles des
cas d‟utilisation et des modèles BPMN. Les modèles des cas d‟utilisation permettent la
formalisation des besoins des utilisateurs associés aux différents acteurs interagissant avec le
système. Les modèles BPMN permettent la description des différents scénarios de réalisation des
cas d‟utilisations.
La couche logique : La couche logique se compose de différents modèles. Principalement, nous
avons défini les modèles suivants :
(1) Les modèles de services multivues (multiview services models) : Ces modèles permettent de
représenter les différents services multivues composant le système. Ils constituent l‟élément
central d‟un système orienté service adaptables aux différents types d‟utilisateurs. De tels
modèles ont pour objectif la représentation des différents services multivues, de leurs interfaces,
des entrés/sorties en termes de messages de chaque opération constituant l‟interface de services
indépendamment des plateformes technologiques et des standards. Ce modèle permet aux
différents stakeholders d‟un SOS adaptable aux différents types d‟utilisateurs, de comprendre sa
structure.
(2) Les modèles d’information : les modèles d‟informations permettent la définition des
différentes structures de données échangées entre les différents services et leurs clients. En effet,
chaque service possède un ou plusieurs interfaces se composant d‟un ensemble d‟opérations qui
manipulent en entrée/ sorties des messages. Ces messages sont définis principalement à partir des
modèles d‟informations associés à chaque système.
(3) Les modèles de composition de services multivues : En SOC, un service est indépendant et
autonome, mais il est composable pour la réalisation d‟un ou de plusieurs processus métiers.
Les modèles de composition de services multivues visent la modélisation de la collaboration de

81 VSoaML : Un profil UML de modélisation des systèmes orientés services adaptables
plusieurs services pour accomplir des objectifs métiers qu‟un seul service atomique ne peut pas
atteindre. Les modèles de composition de services multivues sont définis principalement en
utilisant différents diagrammes tels que les diagrammes BPMN, ou les diagrammes d‟activités
UML ainsi que les diagrammes d‟états.
La couche physique : La couche physique se compose des différents artefacts d‟un système
orienté service adaptable selon une plateforme donnée. Il s‟agit principalement de la
représentation des descriptions de services multivues, de leurs implémentations, de leurs
compositions ainsi que des différents aspects non-fonctionnels tels que les politiques de contrôle
des droits d‟accès XACML.
La figure 42 illustre les différentes couches d‟abstraction définies ainsi que les modèles y
associées.
La couche métier
Modèles des cas d‟utilisation
Modèles BPMN
La couche logique
Modèles des services multivues
Modèles d‟information
Modèles de composition de
services multivues BPMN
La couche physique
Composant Service 1
Description
XSD
Composition de services BPEL
Figure 42–SOS adaptable : Couches d’abstraction

82 VSoaML : Un profil UML de modélisation des systèmes orientés services adaptables
Pour l‟élaboration de ces différentes couches, nous nous appuyons sur un langage de haut
niveau permettant de faciliter la communication entre les différents acteurs s‟intéressant à la
construction des SOS adaptables. Ce langage permet d‟exprimer les différents modèles
composant chaque couche reflétant les perspectives des différents acteurs.
L‟objectif des sections suivantes est de présenter notre langage pour l‟élaboration des différents
modèles composant chaque couche.
II.5. Le profil VSoaML
L‟objectif de cette section est de présenter VSoaML (Kenzi et al., 2009), un profil UML2.0 pour
la modélisation des systèmes orientés services adaptables aux différents types d‟utilisateurs. Ce
profil est une extension d‟UML2.0. Il définit les différents stéréotypes étendant les métaclasses
UML2.0 dans l‟objectif de spécifier et modéliser des systèmes orientés services adaptables. Nous
commençons tout d‟abord par présenter une vue d‟ensemble du profil VSoaML. Ensuite, nous
présentons ses différents stéréotypes ainsi que leurs métaclasses
de base UML2.0. Nous
décrivons chaque stéréotype en présentant sa description, ses contraintes, ses attributs et ses
associations tout en l‟illustrant avec des exemples concrets.
II.5.1. Le profil VSoaML : Vue d’ensemble
UML est un langage de modélisation à destination d‟un grand nombre de domaines d‟application
et à tous types d‟applications logicielles. Cependant, chaque domaine a des notions particulières
et des besoins spécifiques qu‟UML peut supporter par le biais de ses extensions, regroupées en
«Profils UML ». Un profil UML est un moyen permettant de structurer les extensions apportées
au langage standard
constraints).
UML via ses mécanismes d‟extension (tagged values, stereotypes et
Plusieurs profils UML ont été standardisés par l‟OMG tels que EDOC (Enterprise Distributed
Object Computing) (OMG, 2002d) (OMG, 2005) ou UML pour CORBA (OMG, 2002c) ou
UML pour le temps réel, ou encore UML pour les EJB (Enterprise Java Beans).
Un profil UML est une spécialisation du méta modèle UML pour un domaine d‟utilisation
particulier. Il regroupe de manière cohérente des extensions du métamodèle UML et définit leurs
règles de cohérence. Les profils UML peuvent hériter d‟autres profils, avoir des dépendances
entre eux, ou encore être regroupés. Un modèle UML est construit sous un profil particulier,

83 VSoaML : Un profil UML de modélisation des systèmes orientés services adaptables
c‟est à dire qu‟il est élaboré relativement à un contexte qui lui apporte une sémantique
spécifique.
Profil VSoaML
Class
Property
Port
Message
Message Attachment
Service
Port
Connector
Collaboration
MVService
Service Channel
Service Collaboration
Package
Interface
Service Domain
MVServiceInterface
ViewServiceInterface
BaseServiceInterface
Artifact
classifier
MVServiceSpecification
Specification
Service Provider
Service Requester
Figure 43–Stéréotypes de VSoaML et leurs métaclasses de base UML2.0
Comme nous l‟avons vu dans l‟état de l‟art, plusieurs profils ont été proposés pour la
modélisation des applications SOA (Johnston et al., 2006) (Amir et al., 2004). Ces profils

84 VSoaML : Un profil UML de modélisation des systèmes orientés services adaptables
définissent un langage de haut niveau pour la modélisation des services. Néanmoins, ces profils
n‟intègrent que tardivement l‟utilisateur final dans le cycle de développement des systèmes
orientés services.
Dans le but de la prise en compte le plus tôt possible de l‟utilisateur final dans le cycle de
développement des systèmes orientés services, nous proposons le profil VSoaML. Ce profil se
base principalement sur le concept de service multivues présenté dans la section 3.
Le profil VSoaML définit un ensemble de stéréotypes. La définition de ces stéréotypes est
inspirée des concepts de l‟architecture SOA ainsi que des profils UML définis pour la
Figure 44–Métamodèle de VSoaML

85 VSoaML : Un profil UML de modélisation des systèmes orientés services adaptables
modélisation des applications SOA (Johnston et al., 2006). La figure 43 illustre les
différentsstéréotypes de ce profil ainsi que leurs métaclasses de base UML2.0. La figure 44
illustre le métamodèle du profil VSoaML.
Le tableau 8 présente succinctement les différents stéréotypes du profil VSoaML. Dans la
première colonne, nous présentons chaque stéréotype du profil VSoaML. Dans la deuxième,
nous présentons la métaclasse de base de ce stéréotype. La troisième colonne présente une
description succincte de chaque stéréotype.
Stéréotype (VSoaML) Metaclasse Description
(UML)
Message
Class
est un élément de modélisation qui
définit les structures de données échangées. Il
spécifie aussi la propriété “Encoding” pour spécifier
l‟encodage SOAP ou RPC.
MessageAttachment
Property
est un élément de
modélisation permettant d‟indiquer si le contenu d‟un
message est un attachement ou pas
Service
Port
est un élément de modélisation qui
permet de représenter un point final de
communication. Un service n‟identifie pas seulement
ses interfaces fournies mais peut aussi identifier ses
interfaces requises.
MVService
Port
> est un élément de modélisation qui
permet de représenter un service adaptable aux types
de ses clients. La spécificité d‟un service multivues
est qu‟il peut fournir comme il peut requérir des

86 VSoaML : Un profil UML de modélisation des systèmes orientés services adaptables
interfaces qui s‟adaptent aux profils des utilisateurs.
Channel
Connector
est un élément de modélisation
permettant de décrire une connexion entre services. Il
spécifie les liaisons avec les protocoles de transport
(SOAP, HTTP, JMS, etc.)
ServiceCollaboration
Collaboration
est un élément de
modélisation qui spécifie le comportement d‟un
ensemble de services ou de services multivues qui
coopèrent
Requester Classifier est un élément de modélisation qui
représente un client de service
ServiceDomain
Package
définit un groupement logique
ou physique d‟un ensemble de services
Provider
Class
est un élément de modélisation
permettant la représentation d‟un fournisseur d‟un
ou de plusieurs services.
ServiceSpecification
Artifact
est un élément de
modélisation permettant la spécification des
opérations et leurs messages associés qui définissent
le service.
BaseServiceInterface
Interface
est un élément de
modélisation qui représente un ensemble
d‟opérations qui peuvent être invoquées par tous les

87 VSoaML : Un profil UML de modélisation des systèmes orientés services adaptables
acteurs interagissant avec un service donné.
permet de modéliser les
fonctionalités du service accessible à tous les clients
de service.
ViewServiceInterface Interface
permet de représenter une
sorte d‟interface propres à un acteur donné
interagissant avec le service. ViewServiceInterface
permet de modéliser les capacités de services
spécifiques à un acteur spécifique interagissant avec
un service donné.
MVServiceInterface Package est un élément de
modélisation étendant la métaclasse Package. Ce
stéréotype permet de regrouper des fonctionnalités
logiquement cohésives. Il se compose d‟une interface
de service de base accessible à tous types de clients
de services et un ensemble des interfaces de service
vues accessibles uniquement par un type particulier
de clients de service.
ServiceOperation Operation permet de représenter une
opération d‟un service modélisant une fonctionnalité
fournie d‟un service donné. La spécificité de
est qu‟elle manipule des
données de grosse granularité ayant une valeur dans
le cadre d‟un processus métier.
manipule en entrée, en sortie
ou en erreur des messages.
MVServiceSpecification Class permet de décrire les
services multivues. Ainsi, chaque
MVServiceSpecification contient la description d‟une

88 VSoaML : Un profil UML de modélisation des systèmes orientés services adaptables
interface de service de base accessible à tous les
acteurs et il contient la description des interfaces vue
associés à un type particulier d‟acteur.
> Dependency Le stéréotype permet de décrire une
relation d‟inclusion entre une interface de service vue
(viewServiceInterface) et une interface de service de
base (baseServiceInterface)
Dependency Le stéréotype permet de représenter
une relation de spécification entre (Service,
Specification) et entre (MVService,
MVServiceSpecification).
Tableau 8–Stéréotypes du profil VSoaML
II.5.2. VSoaML : les stéréotypes
L‟objectif de cette section est de présenter chaque stéréotype constituant le profil VSoaML.
II.5.2.1
Le stéréotype Service
Le stéréotype Service est un élément de modélisation permettant de représenter un point final de
communication. Un service n‟identifie pas seulement ses interfaces fournies mais peut aussi
identifier ses interfaces requises.
Ce stéréotype ne peut être utilisé qu‟avec des éléments (classes, composants, systèmes, etc.)
stéréotypés comme . Un service possède un attribut binding qui permet de
spécifier la liaison à utiliser telle que SOAP-HTTP ou SOAP-JMS.
Le stéréotype Service étend la métaclasse Port comme métaclasse de base d‟UML2.0. La Figure
45 illustre la métaclasse service et ses associations.

89 VSoaML : Un profil UML de modélisation des systèmes orientés services adaptables
Figure 45–Stéréotype Service
La figure 46 illustre un exemple de service. Un service fournit une ou plusieurs interfaces.
Chaque interface permet de représenter les fonctionnalités fournies par le service à ses clients.
Agenda
Agenda
ajouterEvenement(e : Evenement);
updateEvent(e :Evenement);
supprimerEvenement(e:Evenement);
Figure 46–Service Agenda

90 VSoaML : Un profil UML de modélisation des systèmes orientés services adaptables
Chaque opération de service possède un message en entrée et en sortie. Un message d‟entrée
permet de représenter les données manipulées par une opération de service. Un message de sortie
représente les données résultat de l‟exécution d‟une opération donné. La figure 46 présente un
service Agenda. Ce service fournit une interface de service Agenda qui se compose
d‟opérations : ajouterEvenement, updateEvenement, supprimerEvenement. Il permet à un
l‟acteur Administrateur de gérer l‟agenda des formations. Ainsi, le service permet de créer des
événements, de les modifier ou de les supprimer.
II.5.2.2 Le stéréotype Message
L‟objectif du stéréotype Message est la spécification des informations échangées entre un service
et ses clients. Ces informations concernent les données constituant une entrée/sortie d‟une
opération d‟un service donné. L‟usage de ce stéréotype peut être optionnel du moment où on
peut identifier les messages à partir des paramètres d‟entrés ou de sortie des opérations
constituant l‟interface de service.
Le stéréotype message étend la métaclasse «Class ». Il possède un attribut encoding qui permet
de définir le codage de données à utiliser (SOAP-RPC, ASN, etc.).
Deux contraintes ont été associées à l‟utilisation du stéréotype Message :
un message ne possède pas d‟opérations
un message ne possède pas de comportements.
La figure 47 illustre la métaclasse Message du profil VSoaML et ses associations.

91 VSoaML : Un profil UML de modélisation des systèmes orientés services adaptables
Figure 47–Stéréotype message
La figure 48 montre un exemple de messages. En effet, chaque opération possède un message en
entrée et un autre en sortie. L‟opération addcourse possède en entrée un message spécifiant les
informations en entrée. Ce message se compose d‟un ensemble d‟attributs. Il permet de définir le
nom complet du cours, la description de ce cours, un résumé, le format du cours (hebdomadaire,
thématique, etc.), le module de ce cours ainsi que sa catégorie.
Figure 48–Exemple d’un message
II.5.2.3
Le stereotype MessageAttachment
Le stéréotype MessageAttachment permet d‟indiquer qu‟une partie d‟un message est un
attachement. Chaque MessageAttachment a sa propre identité et il est séparé du corps du

92 VSoaML : Un profil UML de modélisation des systèmes orientés services adaptables
message. Les attachements sont généralement créés et manipulés par des applications externes.
Les documents Word, image, les documents pdf et des fichiers musiques sont des exemples
concrets d‟attachement.
Le stéréotype MessageAttachment est une spécialisation de la métaclasse Property. Les
MessageAttachment sont utilisés et transmis en format binaire suivant un encodage spécifique
qui est défini en utilisant l‟attribut Encoding. Cet attribut est utilisé pour fournir les informations
d‟encodage d‟un attachement contenu dans un message.
Le stéréotype MessageAttachment ne peut être utilisé que comme un constituant d‟un élément
message.
La figure 49 montre les associations de métaclasse MessageAttachment avec les autres
métaclasses constituant le profil VSoaML.
Figure 49–Stéréotype MessageAttachment
II.5.2.4
Le stéréotype Specification
Le stéréotype Specification permet de définir la description des interfaces des services fournies
par un service. Un service peut fournir bien évidemment plus d‟une interface. Pour chaque
service, nous pouvons associer un protocole (machine à états, diagramme d‟activité, diagramme
de séquence) pour spécifier l‟ordre d‟exécutions des opérations de services. Ce protocole permet
de valider chaque service non uniquement structurellement mais aussi en tenant compte ses
aspects comportementaux. Ce stéréotype possède une propriété « published » qui permet

93 VSoaML : Un profil UML de modélisation des systèmes orientés services adaptables
d‟indiquer si le service doit être publié dans un annuaire de service. La spécification d‟un service
peut contenir aussi des informations des propriétés non fonctionnelles telles que les propriétés de
la qualité de service, de sécurité ou de performance.
La spécification de service ne possède pas de propriétés et toutes les opérations doivent être
publiques.
La figure 50 illustre la métaclasse Specification ainsi que ses associations.
Figure 50–Stéréotype specification
La figure 51 montre un exemple d‟une spécification de service. Dans le cas des services web,
une spécification de service correspond à une description WSDL. La description WSDL permet
de décrire les interfaces de service, ses opérations d‟entrée et de sortie, les ports et les formats de
messages.

94 VSoaML : Un profil UML de modélisation des systèmes orientés services adaptables
Agenda
Agenda
Agenda
ajouterEvenement(e :Evenement);
updateEvenement(e :Evenement);
supprimerEvenement(e:Evenement);
Bp : Business protocol
par
admin: Administrateur
agenda :Agenda
consultEvent(course: Course);
ajouterEvenement(e :Evenement)
ajouterEvenement(e :Evenement)
updateEvenement(e :Evenement)
II.5.2.5 Le stéréotype MVService
Figure 51–Exemple de stéréotype Specification
Le stéréotype MVService étend le stéréotype service. La spécificité d‟un service multivues est
qu‟il peut fournir comme il peut requérir des interfaces spécifiques aux différents types
d‟utilisateurs interagissant avec le service. En effet, comme nous l‟avons expliqué dans les
sections précédentes, chaque service multivue fournit/requiert des interfaces de service vue
permettant de représenter les fonctionnalités et les capacités de services accessible uniquement
par un type d‟acteur donné.
La figure 52 illustre la métaclasse MVService et ses associations.

95 VSoaML : Un profil UML de modélisation des systèmes orientés services adaptables
Figure 52–Stéréotype MVService
La figure 53 illustre un service multivues Formation. Ce service multivues fournit plusieurs
interfaces de service vues (ViewServiceInterface). L‟intersection des différentes
ViewServiceInterface constitue l‟interface de service de base qui est accessible par tous types
d‟acteurs. Les interfaces (ViewServiceInterface) ne sont accessibles que par un type particulier
de client. Les différents types d‟interfaces de ce MVService sont encapsulées dans un package
MVServiceInterface.
Course
Course
Course_Professor
CreateCourse()
deleteCourse()
addExercise()
addExerciseSolution()
proposeProject()
askQuestion()
proposeForumTopic()
proposeTest_Quiz()
proposeGroupProject()
accessProject()
addAnnounceCourse()
respondStudentsQuestions
Message()
Course_Student
accessCourse()
accessExercise()
proposeExerciseSolution()
postMessage()
proposeSoultionTestQuiz()
accessProjectressources()
accessProjetc()
accessAnnounceCourse()
Course_Adiministrator
addNewCourse()
addCoursesCalendar()
addAnnounceCourse()
deleteNewCourse()
assignCourseResponsible()
Course_base
consultSynopsisCourse()
consulListCourse()
Figure 53–Exemple de service multivues

96 VSoaML : Un profil UML de modélisation des systèmes orientés services adaptables
II.5.2.6
Le stéréotype MVServiceSpecification
Le stéréotype MVServiceSpecification permet de décrire les services multivues. La spécificité de
ce stéréotype est qu‟il permet la description des interfaces de service multivues de chaque service
multivues. Ainsi, chaque MVServiceSpecification contient la description d‟une interface de
service de base accessible à tous les acteurs et il contient la description des interfaces de service
vues (ViewServiceInterface) associées à des types particuliers de clients.
Le stéréotype MVServiceSpecification étend le stéréotype ServiceSpecification. Ainsi, ce
stéréotype possède une propriété « published » qui permet d‟indiquer si le service doit être publié
ou pas dans un annuaire de service. permet la spécification des
propriétés non fonctionnelles telles que les propriétés de la qualité de service de sécurité ou de
performance.
La figure 54 illustre la métaclasse MVServiceSpecification et ses associations. La Figure 55
illustre un exemple d‟un MVServiceSpecification.

97 VSoaML : Un profil UML de modélisation des systèmes orientés services adaptables
Artifact(from UML2.0)
BusinessProtocol
0..*
Specif ication 0..*
Policy
1
1..*
Serv iceInterf ace
1
MVServiceSpecification
1
1
1..*
0..1
+base
1
BaseServiceInterface
1
1..*
MVServiceInterface
Include
1
1
0..*
0..1
+view
1
ViewServiceInterface
1..*
Actor(f rom UML2.0)
MVServ ice
+prov ides
1 +actor
1..*
+requires
1..*
1
Figure 54–Stéréotype MVServiceSpecification
Course
Course
Course_Professor
CreateCourse()
deleteCourse()
addExercise()
addExerciseSolution()
proposeProject()
askQuestion()
proposeForumTopic()
proposeTest_Quiz()
proposeGroupProject()
accessProject()
addAnnounceCourse()
respondStudentsQuestions
Message()
Course_Student
accessCourse()
accessExercise()
proposeExerciseSolution()
postMessage()
proposeSoultionTestQuiz()
accessProjectressources()
accessProjetc()
accessAnnounceCourse()
Course_Adiministrator
addNewCourse()
addCoursesCalendar()
addAnnounceCourse()
deleteNewCourse()
assignCourseResponsible()
Course_base
consultSynopsisCourse()
consulListCourse()
Figure 55–Exemple de MVServiceSpecification

98 VSoaML : Un profil UML de modélisation des systèmes orientés services adaptables
Dans notre cas de figure, nous avons défini une extension à WSDL pour pouvoir décrire les
services Multivues appelée MVWSDL (MultiView WSDL) (voir section MVWSDL, chapitre
IV). MVWSDL est une extension légère au standard WSDL permettant la spécification des
service multivues. Il s‟agit d‟un schéma XML permettant la description des interfaces du service
multivues.
II.5.2.7 Le stéréotype Collaboration
Le stéréotype Collaboration permet de spécifier à un haut niveau d‟abstraction une collaboration
de plusieurs services/services multivues pour répondre à des exigences complexes auxquels un
seul service ne peut répondre. Dans le cas des services web, cela correspond à l‟utilisation du
standard BPEL4WS pour la définition de la composition de services. Ainsi, l‟objectif de ce
stéréotype est de spécifier le comportement de services pour pouvoir générer automatiquement la
description BPEL. La figure 56 illustre la métaclasse Collaboration et ses associations
Figure 56–Stéréotype Collaboration
La figure 57 présente une collaboration de service. Cette collaboration de services met en
évidence la participation de plusieurs services pour répondre aux exigences complexes des
clients de services. Un service interagit potentiellement avec plusieurs types de clients de
services. De même, une collaboration de services qui définit un processus métier interagit
potentiellement avec plusieurs acteurs (pour chaque acteur est associé un rôle). Ainsi, il est
nécessaire de modéliser et de définir des processus adaptables suivant l‟acteur déclenchant le

99 VSoaML : Un profil UML de modélisation des systèmes orientés services adaptables
Collaboration : « SuivreFormation»
Agenda
« MVService »
Formation
« MVService »
Examen
«MVService»
Documentation
Figure 57–Exemple de collaboration de services

100 VSoaML : Un profil UML de modélisation des systèmes orientés services adaptables
processus métier. Pour faire face à ce problème, nous proposons la modélisation de chaque
processus comme une collaboration de services multivues ayant la caractéristique de fournir des
interfaces adaptés aux différents acteurs interagissant avec le service. Une telle collaboration
illustre l‟ensemble des services multivues participants ainsi que leurs interfaces qui représentent
les fonctionnalités associées à un acteur spécifique. Pour chaque acteur interagissant avec la
collaboration de services, seulement l‟interface correspondant à l‟acteur concerné est requise. La
figure 57 illustre une collaboration de services multivues appelée « suivre Formation» dans le
cadre de notre étude de cas. Le processus est conçu spécifiquement à un acteur étudiant.
Seulement les interfaces associées à l‟acteur Etudiant sont utilisées dans l‟objectif de définir une
collaboration de services.
II.5.2.8 Le stéréotype ServiceChannel
Le stéréotype Channel permet de représenter le chemin de communication entre un service et ses
clients (Johsnston et al., 2006). Dans le domaine des services web, chaque service permet
d‟indiquer ses liaisons associées de telle façon qu‟un client puisse y accéder. Notre profil permet
de spécifier la liaison pour pouvoir invoquer deux services ou entre des clients de service et un
service. Ce stéréotype possède un attribut channel pour spécifier la liaison utilisée pour générer
la liaison WSDL correspondante. Un exemple de binding peut être SOAP-RPC, FTP, HTTP-
GET, etc.
Deux contraintes ont été associées au stéréotype Channel :
[1] au moins l‟extrémité d‟une connexion doit être un service.
[2] au plus une extrémité d‟une connexion doit être une classe stéréotypé ou bien
un classifier stéréotypé .
La figure 58 illustre la métaclasse Channel ainsi que ses associations.

101 VSoaML : Un profil UML de modélisation des systèmes orientés services adaptables
II.5.2.9 Le stéréotype Requester
Figure 58–Stéréotype Channel
Le stéréotype Requester permet de représenter chaque classifier (Class, Component, etc.) qui
peut être un consommateur de service. Ce stéréotype est utilisé pour spécifier les éléments d‟un
modèle qui ne sont pas des services comme des clients de services. L‟utilisation de ce stéréotype
est optionnelle.
La figure 59 illustre la métaclasse Requester ainsi que ses associations.

102 VSoaML : Un profil UML de modélisation des systèmes orientés services adaptables
Figure 59–Stéréotype Requester
La figure 60 montre un exemple d‟un service multivues qui est en interaction avec ses clients de
services (i.e requester).
Course
Student
Teacher
Figure 60–Exemple de Requester
II.5.2.10 Le stéréotype MVServiceInterface
Dans le contexte du profil VSoaML défini dans le cadre du nouveau paradigme SOC, le
stéréotype MVServiceInterface est un élément de modélisation qui étend la métaclasse Package.
Ce stéréotype permet de regrouper des fonctionnalités logiquement cohésives. Ainsi, chaque
MVServiceInterface regroupe un ensemble des interfaces de services vues
(ViewServiceInterface) contenant des capacités de services accessibles uniquement par un type

103 VSoaML : Un profil UML de modélisation des systèmes orientés services adaptables
particulier de clients de service. Un MVService peut avoir plusieurs MVServiceInteface qui sont
associés à l‟élément de modélisation MVServiceSpecification.
La figure 61 illustre la métaclasse MVServiceInterface ainsi que ses associations.
Package(from UML2.0)
Serv iceInterf ace
MVServiceInterface
1
1..*
Include
0..1
+base
1
BaseServiceInterface
1
1
0..1
0..*
+view
1
ViewServiceInterface
1..*
+actor
1
1
Actor(from UML2.0)
Figure 61–Stéréotype MVServiceInterface
La figure 62 illustre un exemple d‟une MVServiceInterface.
Course
Course_Professor
CreateCourse()
deleteCourse()
addExercise()
addExerciseSolution()
proposeProject()
askQuestion()
proposeForumTopic()
proposeTest_Quiz()
proposeGroupProject()
accessProject()
addAnnounceCourse()
respondStudentsQuestions
Message()
Course_Student
accessCourse()
accessExercise()
proposeExerciseSolution()
postMessage()
proposeSoultionTestQuiz()
accessProjectressources()
accessProjetc()
accessAnnounceCourse()
Course_Adiministrator
addNewCourse()
addCoursesCalendar()
addAnnounceCourse()
deleteNewCourse()
assignCourseResponsible()
Course_base
consultSynopsisCourse()
consulListCourse()
Figure 62–Exemple de MVServiceInterface
II.5.2.11
Le stéréotype BaseServiceInterface
Dans le cadre de notre profil VSoaML défini pour la modélisation des SOSs adaptables aux
différents types d‟utilisateurs, le stéréotype BaseServiceInterface permet de représenter un

104 VSoaML : Un profil UML de modélisation des systèmes orientés services adaptables
ensemble d‟opérations de services qui peuvent être invoquées par tous les acteurs interagissant
avec un service donné. Le stéréotype BaseServiceInterface est défini dans l‟objectif de contenir
les opérations de services (ServiceOperation) appartenant à toutes les ViewServiceInterface en
vue de faire face au probléme de la redondance de ces opérations de services. Chaque
BaseServiceInterface est incluse (la relation entre le BaseServiceInterface et
ViewServiceInterface) dans une ViewServiceInterface. La figure 63 illustre le stéréotype
BaseServiceInterface. La figure 64 montre un exemple du stéréotype BaseServiceInterface.
Serv iceInterf ace
Interface(from UML2.0)
1
1..*
0..1
+base
1
BaseServiceInterface
1
MVServiceInterface
Include
1
0..1
+view
MVServ ice
0..*
+provides
1..*
+requires
1
ViewServiceInterface
1
1
+actor
Actor(f rom UML2.0)
1..*
1..*
Figure 63–Stéréotype baseServiceInterface
Course_Professor Course_Student
CreateCourse()
deleteCourse()
addExercise()
addExerciseSolution()
proposeProject()
askQuestion()
proposeForumTopic()
proposeTest_Quiz()
proposeGroupProject()
accessProject()
addAnnounceCourse()
respondStudentsQuestions
Message()
accessCourse()
accessExercise()
proposeExerciseSolution()
postMessage()
proposeSoultionTestQuiz()
accessProjectressources()
accessProjetc()
accessAnnounceCourse()
Course_Adiministrator
addNewCourse()
addCoursesCalendar()
addAnnounceCourse()
deleteNewCourse()
assignCourseResponsible()
Course_base
consultSynopsisCourse()
consulListCourse()
Un exemple d‟une
interface de service
de base
Figure 64–Exemple de BaseServiceInterface

105 VSoaML : Un profil UML de modélisation des systèmes orientés services adaptables
II.5.2.12
Le stéréotype ViewServiceInterface
Dans le contexte du profil VSoaML défini pour la modélisation des SOSs Adaptables aux
différents types d‟utilisateurs, le stéréotype ViewServiceInterface permet de représenter les
capacités d‟un service qui sont propres à un acteur donné interagissant avec le service. Le
stéréotype «ViewServiceInterface» est un élément de modélisation qui fait partie de l‟élément de
modélisation MultiviewServiceInterface. Il se compose donc des opérations du service de grosse
granularité qu‟un acteur spécifique puisse invoquer. Chaque opération de service a pour
entrée/sortie un Message. En entrée, un message contient les données nécessaires pour qu‟une
opération de service puisse s‟exécuter. En sortie, le message contient le résultat de l‟invocation
d‟une telle opération de service. La figure 65 illustre le stéréotype ViewServiceInterface et ses
associations. La figure 66 illustre un exemple de ViewServiceInterface.
Serv iceInterf ace
Interface(fromUML2.0)
1
MVServiceInterface 0..1
BaseServiceInterface
1
+base
1
1..*
Include
0..1
1
+v iew 1
ViewServiceInterface
0..*
MVServ ice
1..*
+requires
1..*
1
+prov ides
1
1..*
Actor(f rom UML2.0)
+actor
Figure 65–Stéréotype ViewServiceInterface

106 VSoaML : Un profil UML de modélisation des systèmes orientés services adaptables
Exemple des interfaces de service
vues
Course_Professor
CreateCourse()
deleteCourse()
addExercise()
addExerciseSolution()
proposeProject()
askQuestion()
proposeForumTopic()
proposeTest_Quiz()
proposeGroupProject()
accessProject()
addAnnounceCourse()
respondStudentsQuestions
Message()
Course_Student
accessCourse()
accessExercise()
proposeExerciseSolution()
postMessage()
proposeSoultionTestQuiz()
accessProjectressources()
accessProjetc()
accessAnnounceCourse()
Course_Adiministrator
addNewCourse()
addCoursesCalendar()
addAnnounceCourse()
deleteNewCourse()
assignCourseResponsible()
Course_base
consultSynopsisCourse()
consulListCourse()
II.5.2.13 Le stéréotype Provider
Figure 66–Exemple de ViewServiceInterface
Le stéréotype Provider permet de représenter un fournisseur de services qui héberge le module
logiciel implémentant un ou plusieurs services web accessibles via le réseau. Il définit une
description de services et le publie en le faisant enregistrer dans un annuaire de services. Le
demandeur de services invoque une opération de recherche pour trouver la description du service
dans l‟annuaire de service. Il utilise alors la description du service pour établir une connexion
avec le fournisseur de services et invoquer ou interagir avec l‟implémentation du service web.
La figure 67 illustre la métaclasse Provider et ses associations.

107 VSoaML : Un profil UML de modélisation des systèmes orientés services adaptables
Figure 67–Stéréotype Provider
II.5.2.14 Le stéréotype ServiceOperation
Le stéréotype ServiceOperation étend la métaclasse Operation d‟UML 2.0. Il permet de
représenter une opération d‟un service qui modélise une fonctionnalité fournie par un service
donné. La spécificité d‟une opération de service (ServiceOperation) est qu‟elle manipule des
données de grosse granularité ayant une valeur dans le cadre d‟un processus métier. Une
opération de services manipule en entrée, en sortie ou en erreur des messages.
La figure 68 illustre la métaclasse ServiceOperation et ses associations. La figure 69 illustre un
exemple des ServiceOperation. En effet, l‟interface de service de base (BaseServiceInterface) et
l‟interface de service vue (ViewServiceInterface) se composent principalement d‟opération de
services.

108 VSoaML : Un profil UML de modélisation des systèmes orientés services adaptables
Figure 68–Stéréotype ServiceOperation
Course_Professor
CreateCourse()
deleteCourse()
addExercise()
addExerciseSolution()
proposeProject()
askQuestion()
proposeForumTopic()
proposeTest_Quiz()
proposeGroupProject()
accessProject()
addAnnounceCourse()
respondStudentsQuestions
Message()
Course_Student
accessCourse()
accessExercise()
proposeExerciseSolution()
postMessage()
proposeSoultionTestQuiz()
accessProjectressources()
accessProjetc()
accessAnnounceCourse()
Course_Adiministrator
addNewCourse()
addCoursesCalendar()
addAnnounceCourse()
deleteNewCourse()
assignCourseResponsible()
Course_base
consultSynopsisCourse()
consulListCourse()
Un exemple d‟une
opération de service
Figure 69–Exemple de serviceOperation
II.5.2.15 Le stéréotype ServiceDomain
Le stéréotype permet de représenter les frontières logiques ou physiques
d‟un système. Cet élément de modélisation joue un rôle important pour la structuration et

109 VSoaML : Un profil UML de modélisation des systèmes orientés services adaptables
l‟organisation d‟un système en un ensemble de packages. Il joue un rôle important dans la
définition des espaces de nommage.
possède un attribut domain qui permet de regrouper les services d‟un
domaine métier particulier. Un étend la métaclasse « Package » UML2.0.
La figure 70 illustre le stéréotype Service Domain et ses associations.
Figure 70–Stéréotype ServiceDomain
II.5.3. Exemple illustratif DLS : Couches d’abstraction
Pour le développement de notre système d‟enseignement à distance, nous nous basons sur notre
profil VSoaML en vue de l‟élaboration des couches d‟abstraction permettant la représentation
des différentes perspectives qui correspondent aux différents stakeholders (e.g., Analyste métier,
Architecte, etc.). La couche métier de ce système se compose de deux artefacts clés : les modèles
des cas d‟utilisation (cf. figure 37) et les modèles BPMN capables de représenter les scénarios
permettant la réalisation des différents cas d‟utilisation. La figure 71 présente le modèle BPMN
du cas d‟utilisation «Assurer Formation». La figure 72 illustre le modèle BPMN du cas
d‟utilisation « Suivre formation».

110 VSoaML : Un profil UML de modélisation des systèmes orientés services adaptables
Figure 71–Modèle BPMN du cas d’utilisation « Assurer Formation ».

111 VSoaML : Un profil UML de modélisation des systèmes orientés services adaptables
Figure 72–Modèle BPMN du cas d’utilisation « Suivre formation»
La couche logique est décrite par le modèle de service multivue et le modèle d‟information
associés au DLS. Le modèle de service multivues se compose des services multivues suivants :
Inscription, Formation, Documentation et Examen. Ces services sont multivues du moment où
ils interagissent avec plusieurs acteurs : Enseignant, Etudiant et Administrateur. Le service
multivue Inscription fournit les interfaces ViewServiceInterface suivantes :
Inscription_Etudiant,
Inscription_Enseignant, Inscription_Administrateur. Chaque
interface modélise les fonctionnalités spécifiques à chaque acteur. Ainsi,
Inscription_Etudiant contient les opérations de service nécessaires à
un acteur Etudiant pour faire son inscription.
Inscription_Administrateur contient les opérations permettant à un acteur administrateur de gérer
les inscriptions des étudiants, de fixer les frais d‟inscription aux différentes formations et de
décider des inscriptions des étudiants.
Le service multivue Formation fournit les ViewServiceInterface suivantes :

112 VSoaML : Un profil UML de modélisation des systèmes orientés services adaptables
Formation_Etudiant,
Formation_Enseignant, Formation_Administrateur. L‟interface
Formation_Etudiant modélise les fonctionnalités permettant à un
acteur Etudiant de suivre des formations, d‟accéder aux exercices, de poser des questions, de
consulter les projets d‟une formation donnée, de faire des quiz et d‟envoyer des messages aux
forums de discussion spécifiques à une formation donnée.
Formation_Administrateur modélise les fonctionnalités permettant à un acteur Administrateur
de fixer les frais d‟une formation donnée, de gérer son calendrier et d‟affecter les responsables
des formations.
Formation_Enseignant modélise les fonctionnalités permettant à
l‟enseignant de créer des formations, de répondre aux questions des étudiants, de proposer des
exercices et de répondre aux messages des forums de discussion.
Le service Documentation fournit deux interfaces : doc_Etudiant et
Doc_Enseignant. La première interface modélise les fonctionnalités
qui correspondent à l‟acteur Etudiant lui permettant de télécharger les documentations
nécessaires (fichiers pdf, audio/video, etc.). La deuxième interface est associée à l‟acteur
Enseignant. Elle lui permet de charger les documents concernant une formation spécifique, de les
mettre à jour ou de les supprimer.
Le service Examen fournit trois interfaces : Examen_Etudiant,
Examen_Enseignant,
Examen_Administrateur.
Examen_Etudiant permet à l‟étudiant de télécharger le sujet d‟un
examen, de poser des questions de compréhension et de consulter ses notes.
Examen_Enseignant permet à un acteur Enseignant de proposer un
examen et de répondre aux questions des examens.
Examen_Administrateur permet à un acteur administrateur de gérer les examens ainsi que la
gestion des notes.

113 VSoaML : Un profil UML de modélisation des systèmes orientés services adaptables
La figure 73 illustre les différents services multivues constituant le système d‟enseignement à
distance. Cette figure met en lumière la structure de différentes interfaces de service multivues.
En fait, chaque interface de service multivues est composée d‟une interface de service de base
qui représente les fonctionnalités communes entre les différents acteurs. Les interfaces de service
vues représentent les fonctionnalités spécifiques à chaque acteur.
Inscription
Inscription_Etudiant
Inscription
demanderInscription()
payerFraisInscription()
Inscription_Base
consulterDateLimite()
consulterListeFormation()
Inscription_Administrateur
deciderInscription()
ajouterListeAttente()
fixerFraisInscription()
Examen
Examen_Etudiant
consulterExamen()
poserQuestionExamen()
consulterNotes()
Examen
Examen_Enseignant
ajouterExamen()
repondreQuestionsExamen()
evaluerExamen()
ajouterNotes()
Examen_base
consulterCalendrierExamen()
Examen_Admnistrateur
consulterNotesEtudiant()
definirCalendrierExamen()

114 VSoaML : Un profil UML de modélisation des systèmes orientés services adaptables
Documentation
Documentation
Doc_Enseignant
chargerDocumentation()
updateDocumentation()
supprimerDocumentation()
Doc_base
consulterDocumentation()
Doc_Student
telechargerDocumentation()
proposerSupplementDocumentation()
Formation
Formation_Administrateur
ajouternouvelleFormation();
ajouterCalendrierFormation() ;
ajouterAnnounceFormation() ;
supprimerFormation() ;
affecterResponsableFormation() ;
Formation
Formation_Etudiant
consulterFormation() ;
consulterExercice() ;
proposerSolutionExercice() ;
posterMessage() ;
proposerTestSolution() ;
accessProjectRessource() ;
consulterProjet() ;
consulterAnnounceFormation() ;
consulterForum() ;
consulterTest(),
consulterDevoir() ;
Formation
consultSynopsisFormation ;
consultListFormation() ;
Formation_Enseignant
ajouterFormation();
supprimerFormation() ;
ajouterExercice() ;
ajouterSolutionExercice() ;
proposerProjet() ;
poserQuestion() ;
proposerForum() ;
afficherForum() ;
rechercherForum() ;
proposerTest() ;
ajouterGlossaire() ;
rchercherGlossaire() ;
ajouterTest()
modifierTest(),
ajouterAnnounceFormation() ;
repondreQuestionsEtudiants() ;
Figure 73–Modèle des services multivues du DLS

115 VSoaML : Un profil UML de modélisation des systèmes orientés services adaptables
La figure 74 présente un extrait du modèle d‟information associé au modèle de services
multivues. Ce modèle permet de spécifier les différents types d‟informations échangées entre les
services et ses clients. En effet, chaque opération de service possède en entrée ou en sortie un
message. Le modèle d‟information nous permet de définir les messages des différentes
opérations de chaque service. Dans le cadre de notre étude de cas, nous avons identifié le modèle
d‟informations présenté dans la figure 74. Chaque opération de notre étude de cas, possède des
messages en entrée et en sortie.
Figure 74–Extrait du modèle d’information du système d’Enseignement à Distance

116 VSoaML : Un profil UML de modélisation des systèmes orientés services adaptables
II.6. Conclusion
Dans ce chapitre, nous avons présenté un profil UML appelé VSoaML permettant la
modélisation et la spécification des systèmes orientés services adaptables aux différents types
d‟utilisateurs en faisant abstraction des plates-formes d‟implémentation et des standards
technologiques. Nous avons par conséquent présenté les différents stéréotypes de ce profil ainsi
que son métamodèle. Pour chaque stéréotype constituant le profil VSoaML, nous lui avons
donné une description en spécifiant ses attributs, ses relations et les contraintes associées.
Le profil VSoaML constitue l‟élément de base de notre approche d‟ingénierie des SOSs
adaptables. Une telle approche se base aussi sur un processus pour maîtriser la complexité du
développement des SOS adaptables aux différents types d‟utilisateurs. Ainsi, nous continuons
dans le chapitre suivant à proposer un processus de développement d‟un système orienté services
adaptables en se basant principalement sur le profil VSoaML et plus particulièrement sur le
concept de service multivues.

117 Processus de Développement Dirigé par les Modèles des Systèmes Orientés Services Adaptables
III. Processus de Développement Dirigé par les Modèles des Systèmes
Orientés Services Adaptables
III.1. Introduction
Comme nous l‟avons présenté dans le chapitre 2, le profil VSoaML permet la modélisation et la
spécification des systèmes orientés service adaptables aux différents types d‟utilisateurs
facilitant ainsi la compréhension des caractéristiques de tels systèmes par les différents
stakehloders concernés. VSoaML se base principalement sur le concept de service multivues
comme une entité de modélisation capable de décrire les besoins et les spécificités des
utilisateurs finals assez tôt dans le cycle de développement des SOSs.
Certes le profil VSoaML joue un rôle important pour le développement des systèmes orientés
services adaptables aux différents types d‟utilisateurs, cependant il est nécessaire de définir un
processus de développement pour rationaliser leur construction.
Le but principal de ce chapitre est de présenter notre processus proposé pour le développement
des systèmes orientés services adaptables aux différents types d‟utilisateur. Un tel processus
associé au profil VSoaML a pour objectif principal l‟identification, la spécification des services
multivues et leur implémentation à partir des exigences métiers. Pour ce faire, ce processus
définit les phases, les artefacts et les activités nécessaires pour la transformation des exigences
métiers en termes de services multivues selon une approche dirigée par les modèles.
Ce chapitre est structuré comme suit. La section 2 présente globalement les phases, les activités
et les artefacts d‟un processus de développement d‟un système orienté service. La troisième
section a pour objectif de présenter les spécificités des processus de développement des systèmes
logiciels dans le cadre de l‟approche MDA. La section 4 présente notre processus proposé pour
le développement des SOSs adaptables aux différents types d‟utilisateurs dans le cadre de
l‟approche MDA, en identifiant ses phases, ses artéfacts et ses activités.

118 Processus de Développement Dirigé par les Modèles des Systèmes Orientés Services Adaptables
III.2. Processus de développement des systèmes orientés services : phases,
activités et artefacts
SOC se base principalement sur le service comme un élément fondamental pour le
développement des systèmes d‟information d‟entreprise distribués et à large échelle. L‟élément
service possède des caractéristiques héritées de ses prédécesseurs tels que l‟objet ou le
composant mais il ajoute d‟autres caractéristiques telles que sa grosse granularité, son
indépendance, son autonomie et son couplage faible. Ainsi, les approches traditionnelles pour le
développement des systèmes logiciels orientés objet ou à base de composant sont inadéquates
pour le développement des systèmes orientés services. Pour faire face à ce problème, plusieurs
processus de développements ont été proposés dans la littérature (Papazoglou et al., 2006)
(Arsanjani et al. 2005) (Erradi et al., 2006) (Chang et al., 2007b) (Maamar et al., 2008) (Kim et
al., 2006). Globalement, ces processus définissent un ensemble de directives et de principes
méthodologiques pour spécifier, construire et implémenter des systèmes orientés services
en se basant sur l‟élément service et sur l‟architecture SOA tout en optimisant les coûts et le
temps de leur développement.
Généralement, un processus de développement SOA, comme le montre la figure 75, repose sur
un processus itératif et incrémental qui comporte six phases :
1- Planification : la phase planification détermine la faisabilité, la nature et l‟étendu d‟une
solution SOA dans le contexte d‟une entreprise. L‟objectif principal de cette phase est de
comprendre l‟environnement métier et de s‟assurer que tous les contrôles nécessaires sont
incorporés dans la conception des solutions SOA. Les activités principales de cette phase
concernent principalement l‟analyse des besoins métiers, l‟étude des technologies et des
scénarios possibles pour transformer les exigences métiers vers des implémentations de
service. Trois scénarios sont identifiés (i) le premier scénario concerne l‟utilisation des
applications existantes en les encapsulant dans des services (ii) le deuxième scénario
concerne l‟utilisation des services d‟autres fournisseurs de services publiés dans un
annuaire de services (iii) le troisième scénario concerne le développement de nouvelles
implémentations de service.

119 Processus de Développement Dirigé par les Modèles des Systèmes Orientés Services Adaptables
Durant cette phase, on effectue aussi une analyse financière incluant les coûts et les
bénéfices ainsi qu‟un plan de développement logiciel déterminant les tâches, les
livrables ainsi qu‟un programme d‟action.
Plannification
Analyse et
conception
Exécution et
monitoring
Construction et
Test
Deploiement
Approvisionnement
Figure 75–Phases du cycle de vie méthodologique (Papazoglou et al., 2006)
2- Analyse et conception des services et des processus : L‟analyse et conception des services et
des processus a pour objectif principal l‟identification et la conception des processus métier
en termes d‟un ensemble de services. Cette phase permet la modélisation des services en
définissant leurs interfaces indépendamment des plateformes technologiques de développement.
Elle est effectuée en deux étapes. La premiére étape permet l‟identification et la spécification des
services. La spécification des services se fait principalement en réalisant quatre activités : la
définition de l‟interface en utilisant le langage WSDL, la spécification des messages des
opérations en entrée/sortie, la définition du protocole de transport et d‟échange de données en
utilisant par exemple le protocole SOAP et la définition des opérations, des liaisons à un
protocole concret ainsi que la définition de l‟emplacement du service à invoquer.

120 Processus de Développement Dirigé par les Modèles des Systèmes Orientés Services Adaptables
La deuxiéme étape consiste à identifier et spécifier les processus. L‟identification du processus
métier consiste en l‟identification des services à faire composer. La spécification du processus
se base sur trois activités (i) la définition de l‟objectif et de la structure du processus qui
spécifie l‟ordre d‟exécution des services, les participants impliqués ainsi que les informations
échangées entre eux, (ii) la définition des rôles que jouent les participants dans une conversation
et (iii) la définition des besoins non-fonctionnels comme la sécurité des processus.
3- Construction et test : Une fois la phase d‟analyse et conception des services et des processus
est terminée, la phase de construction et test peut commencer. Elle comporte généralement trois
activités principales. La premiére activité consiste au choix du style de programmation des
services en distinguant principalement entre deux types notamment : RPC (Remote Procedure
Call) et message/document. La deuxiéme activité consiste au développement des services en
définissant leurs interfaces WSDL. La publication de la description WSDL est réalisée ensuite
via l‟utilisation d‟un annuaire UDDI. L‟étape suivante consiste à générer le squelette du
service à partir de l‟interface via l‟utilisation d‟un langage d‟implémentation donné (Java,
C#). Enfin, les méthodes du service prédéfinies dans le squelette sont implémentées. La
troisiéme activité est le développement des processus métier par la conception de leur
logique métier à travers des spécifications exprimées par exemple en BPEL4WS.
4- Approvisionnement : Dans le cadre de cette phase, différentes activités ont été identifiées
pour contrôler le comportement d‟un service lors de son utilisation (gouvernance et certification
des services, facturation, etc.).
5- Déploiement : Dans le cadre de cette phase, trois activités ont été définies (i) la publication
des interfaces de services dans un annuaire de services UDDI, (ii) le déploiement des services et
des processus métiers en définissant les métadonnées necessaires pour leur execution et (iii) la
publication des détails des implémentations des services en identifiant les informations y
associées (e.g., liaisons aux protocoles concrets et au point d‟entrée du service) .
6- Exécution : Dans le cadre de cette phase, les services ainsi que les processus métier sont
déployés et opérationnels. Un client de service peut alors invoquer les opérations du service en se
référant à la définition de son interface WSDL.

121 Processus de Développement Dirigé par les Modèles des Systèmes Orientés Services Adaptables
III.3. Processus de développement MDA : phases, activités et artefacts
Dans l‟objectif de maitriser la complexité logicielle, l‟OMG a proposé l‟approche MDA pour le
développement, l‟intégration et la maintenance des systèmes à prépondérance logicielle. MDA
est une démarche de développement permettant la séparation des spécifications fonctionnelles
d‟un système des spécifications de son implémentation sur une plateforme technologique
donnée. Ainsi, MDA se base sur plusieurs types de modèles qui définissent différentes vues
d‟un système: le CIM, le PIM et le PSM. Elle se base aussi sur la transformation de modèles
comme une activité principale. L‟objectif de cette section est de présenter ces différents types de
modèles ainsi que les artefacts et les activités d‟un processus de développement MDA.
III.3.1.
Les types de modèles et de transformation de MDA
III.3.1.1
Computation Independent Model (CIM)
Le CIM (Computation Independent Model) aussi appelé Business Model ou Domain model
permet de décrire les exigences du système et la situation dans laquelle le système sera utilisé. Il
ne représente pas les détails de la structure du système et reste indépendant des technologies de
son implémentation. Ce modèle permet d‟exprimer les liens de traçabilité avec les modèles qui
seront élaborés dans les autres phases du cycle de développement. En effet, les exigences
décrites dans ce modèle doivent pourvoir à la construction d‟autres modèles (PIM et PSM) qui
les implémentent et vice versa. Le CIM place le système dans son contexte opérationnel et
permet de représenter ce que le système devrait réellement assurer comme fonctionnalités.
Dans UML, les modèles d‟exigences sont représentés par les diagrammes de cas d‟utilisation.
Ces derniers décrivent de façon abstraite les différentes fonctionnalités du système ainsi que les
acteurs qui interagissent avec ce système. Cependant, MDA ne fait aucune recommandation
quant à l‟utilisation d‟UML ou non pour exprimer les CIM.
III.3.1.2
Platform Independent Model (PIM)
Le PIM est un modèle de haut niveau d‟abstraction qui est indépendant de toute plateforme
(J2EE, dotNet) ou technologie. Il décrit le système en masquant les détails de son utilisation sur

122 Processus de Développement Dirigé par les Modèles des Systèmes Orientés Services Adaptables
une plateforme technologique particulière. Le PIM permet de décrire la logique métier. Il décrit
les systèmes logiciels comme un ensemble d‟entités fonctionnelles ainsi que leurs interactions
tenant en considération seulement la logique métier des entreprises. Ce modèle doit être clair afin
de permettre à des experts du domaine de le comprendre plus aisément qu‟un modèle
d‟implémentation. Ainsi, ils peuvent vérifier que le PIM est complet et correct plus facilement.
Le langage UML ainsi que les profils UML sont préconisés par l‟approche MDA pour
l‟élaboration des PIM. L‟essentiel pour un PIM est d‟être pérenne et de faire le lien entre le
modèle d‟exigences et le code de l‟application. Les modèles doivent aussi être productifs car ils
constituent le socle du processus de génération de code.
III.3.1.3
Platform Specific Model (PSM)
Le PSM est un modèle qui est dépendant de la plateforme technique. Il est utilisé principalement
pour la génération automatique de code exécutable dans un environnement d‟exécution donné.
Le PSM est une représentation de l‟implémentation d‟une technologie particulière. Par exemple,
un PSM concernant la plateforme EJB contiendra des termes spécifiques aux EJB tels que home
interface, remote interface, entity bean, session bean …
Un PIM peut être transformé en un ou plusieurs PSM. En fait, pour chaque plateforme
technologique spécifique, un PSM est généré. Au fur et à mesure de l‟évolution des outils de
génération MDA, cette phase peut devenir de plus en plus automatisée.
Pour l‟élaboration des PSM, deux approches sont préconisées. La première consiste à utiliser
des profils UML pour élaborer les PSM. L‟utilisation de ces profils a le mérite de faciliter les
transformations PIM vers PSM car les PIMs et les PSMs sont tous deux des modèles UML.
La deuxième approche consiste en la définition de méta-modèles propres aux plates-formes.
Cette approche offre une plus grande liberté dans l‟expression des plates-fromes ; cependant, elle
présente l‟inconvénient de ne pas faciliter les transformations PIM vers PSM (Blanc, 2005).

123 Processus de Développement Dirigé par les Modèles des Systèmes Orientés Services Adaptables
CIM
PIM
PSM
Code
Figure 76–Types de transformations MDA (Blanc, 2005)
La figure 76 illustre les principales transformations de modèles définies dans le cadre de
l‟approche MDA. Les transformations préconisées par MDA sont essentiellement les
transformations CIM vers PIM et PIM vers PSM. Généralement, les transformations peuvent être
groupées en :
Transformations CIM vers PIM : Ces transformations visent à construire des
modèles PIM partiels à partir des modèles CIM. Elles permettent de garantir la
traçabilité entre les modèles et les besoins exprimés dans les CIM.
PIM vers PIM : Ces transformations s‟effectuent pour ajouter ou soustraire des
informations aux modèles. Le passage de la phase d‟analyse à la phase de
conception est la plus naturelle des transformations de ce genre. De telles
transformations ne sont pas toujours automatiques, et demandent l‟intervention
du développeur pour ajouter ou soustraire des informations. La plus naturelle
des transformations est l‟enrichissement de PIM en étapes successives afin de
le rendre plus complet.
PIM vers PSM : ces transformations s‟effectuent lorsque les PIM sont
suffisamment enrichis avec des informations pour pouvoir être transformés sur
une plate-forme technologique. Un exemple de ce genre est la transformation

124 Processus de Développement Dirigé par les Modèles des Systèmes Orientés Services Adaptables
d‟un modèle métier en UML vers un modèle UML qui prend en compte la
logique métier en utilisant une plate-forme comme les services Web.
PSM vers PIM : ces transformations s‟effectuent pour séparer la logique métier
de la plate-forme technologique. Par exemple, une transformation d‟un PSM
(par exemple, un modèle UML qui utilise des profils CORBA) qui soustrait la
plate-forme (par exemple, services Web) et retourne que la logique métier.
Particulièrement, ce genre de transformation est le plus demandé dans les
processus de reverse engineering.
PSM vers PSM : ces transformations s‟effectuent lors des phases de
raffinement de plates-formes technologiques, de déploiement, d‟optimisation
ou de reconfiguration.
III.3.2. Le processus de développement dans le contexte de MDA :
MDA comme nouveau paradigme informatique a impacté les processus de développement
logiciels. Certes, L‟approche MDA ne définit pas un processus de développement spécifique
pour le développement des systèmes. Cependant, les modèles et les transformations de modèles
jouent un rôle très important dans le processus de développement des systèmes logiciels dans le
contexte de l‟approche MDA. En fait, les modèles sont les artefacts de chaque activité du
processus de développement. Aussi, chaque activité consiste en une transformation de modèles
d‟un niveau d‟abstraction à un autre.
Un processus de développement MDA (Kadima et al., 2005) (Kleppe et al., 2005) (cf. figure 77)
repose principalement sur une suite de modèles intégrant toutes les dimensions d‟un projet : du
modèle métier à la génération de code. Chaque passage d‟un modèle à un autre se base sur un
raffinement progressif des spécifications des applications et sur des transformations de modèles.
Globalement, un processus de développement dans le cadre de l‟approche MDA définit les
étapes suivantes :
1- Elaboration des modèles d‟exigences (CIM).

125 Processus de Développement Dirigé par les Modèles des Systèmes Orientés Services Adaptables
Phases
Expression
des besoins
Artefacts
Texte
Analyse
Conception de
bas - niveau
PIM
Codage
PSM
Test
Code
Déploiement
Code
Figure 77–Processus de développement MDA des systèmes logiciels
2- Elaboration des modèles indépendants de toute plate-forme (PIM). les PIM doivent être
en théorie, partiellement générés à partir des modèles CIM afin de garantir
l‟établissement des liens de traçabilité.
3- Enrichissement du modèle PIM par étapes successives.

126 Processus de Développement Dirigé par les Modèles des Systèmes Orientés Services Adaptables
4- Choix des plates-formes de mise en œuvre et génération des modèles spécifiques
correspondants (PSM). Ces modèles sont obtenus par une transformation des PIM en y
ajoutant les informations techniques relatives aux plates-formes choisies.
5- Raffinement des PSM jusqu‟à l‟obtention d‟une implémentation exécutable.
Comme illustré sur la figure 77, le processus de développement MDA ne semble pas si différent
des modèles classiques. On y trouve les mêmes phases (partie gauche de la figure 77). Ce qui
caractérise les processus de développement MDA est la nature des artéfacts (partie droite de la
figure 77) générés au cours du processus de développement. En effet, les artéfacts générés dans
chaque phase sont les différents modèles définis par l‟approche MDA à savoir le CIM, PIM et
PSM.
III.4. Processus MDA de développement des SOS adaptables
Comme nous l‟avons présenté dans le chapitre II, VSoaML est un profil UML qui vise la
modélisation et la spécification des systèmes orientés services adaptables indépendamment des
technologies et des plateformes. VSoaML se base principalement sur le service multivues
comme un élément fondamental pour le développement des systèmes orientés services
adaptables.
Dans l‟objectif de rationaliser le développement des systèmes orientés services adaptables aux
différents types d‟utilisateurs en se basant sur VSoaML, il est nécessaire de définir un processus
de développement permettant de guider le développement à partir des exigences métiers. Un tel
processus définit les phases, les activités et les artefacts facilitant ainsi l‟identification, la
spécification et l‟implémentation de services. Un tel processus se base principalement sur le
service multivues comme élément fondamental pour le développement des systèmes orientés
services adaptables. Un tel service a pour caractéristique fondamentale de fournir des interfaces
de service multivues. Chaque interface de service multivues se compose d‟une interface de
service de base accessible à tous les acteurs et d‟un ensemble d‟interfaces de service vues
associées à chaque acteur. L‟objectif de cette section est de définir un processus de
développement des systèmes orientés services adaptables qui permet d‟identifier les services

127 Processus de Développement Dirigé par les Modèles des Systèmes Orientés Services Adaptables
Elaboration des modèles des cas d‟utilisation
CIM
Identification des services par acteur
Identification des services par acteur
PIM-acteur1
PIM-acteur N
raffiné
Spécification des interfaces de services
Spécification des interfaces de services
PIM-acteur1
raffiné
PIM-acteur N
raffiné
Fusion des modèles visuels
PIM global
Transformation des modèles et génération du code
Transformation des modèles PIM vers des PSM
PSMs
Génération du code à partir des PSM
Code
Figure 78–Processus de développement des systèmes orientés services multivues dans le cadre
de l’approche MDA

128 Processus de Développement Dirigé par les Modèles des Systèmes Orientés Services Adaptables
multivues, de les spécifier en identifiant leurs interfaces, leurs opérations et leurs messages
d‟entrés/sorties, etc.
La figure 78 illustre les principales phases de notre processus de développement des SOSs
adaptables (Kenzi et al., 2008c) (Kenzi et al., 2009a). Ce processus est défini dans le contexte de
l‟approche MDA.
Les sections suivantes décrivent les différentes phases de notre processus de développement.
III.4.1. Phase 1: Elaboration des modèles des cas d’utilisation
La première phase de notre processus de développement est l‟élaboration des modèles des cas
d‟utilisation. L‟objectif de cette phase est la capture et la spécification des besoins des utilisateurs
ainsi que la description des processus métiers. Dans cette phase, nous déterminons, en premier
lieu, les différents acteurs du système ainsi que les besoins de chaque acteur via les diagrammes
des cas d‟utilisations. En effet, Les diagrammes cas d‟utilisation jouent un rôle très important
pour l‟identification des besoins des utilisateurs. Ils décrivent de manière exhaustive les exigences
fonctionnelles du système. Notre approche adopte les diagrammes des cas d‟utilisations pour
plusieurs raisons : la majorité des analystes/concepteurs sont familiers avec l‟utilisation des cas
d‟utilisations du fait de leur simplicité. Aussi, les cas d‟utilisations identifiés dans cette étape
deviendront potentiellement des services et les relations entre les cas d‟utilisations sont un
excellent indicateur de la collaboration et la composition des futurs services (Maamar et al,
2007)(Ibrahim et al., 2006).
L‟artefact caractérisant cette phase est le CIM qui contient les cas d‟utilisations ainsi que les
différents acteurs interagissant avec eux. La figure 79 présente les cas d‟utilisation du système
d‟enseignement à distance :

129 Processus de Développement Dirigé par les Modèles des Systèmes Orientés Services Adaptables
Figure 79–Cas d‟utilisation du DLS
III.4.2.
Phase 2: Identification des services par acteur
La phase «Identification des services par acteur» a pour objectif principal la transformation les
exigences métiers capturées à travers les modèles des cas d‟utilisation en une collection de
services. Il s‟agit principalement d‟identifier les services candidats à partir des modèles des cas
d‟utilisation associés à chaque acteur.
L‟artefact clé de cette phase est un ensemble de PIMs associés aux différents acteurs du
système. Chaque PIM se compose des différents services permettant de réaliser les besoins d‟un
acteur spécifique. L‟identification des services se fait en adoptant des règles de refactoring. En
effet, Kim et al. (Kim et al., 2007) ont défini plusieurs règles de refactoring permettant

130 Processus de Développement Dirigé par les Modèles des Systèmes Orientés Services Adaptables
l‟identification des services à partir des modèles de cas d‟utilisation. Chaque cas d‟utilisation est
décomposé en termes d‟un ensemble de tâches permettant la réalisation des besoins des acteurs
qui sont en interaction avec ce cas d‟utilisation. Chaque tâche est définie comme étant une unité
de travail indivisible apportant une valeur ajoutée à l‟utilisateur dans le contexte d‟un processus
métier. Une tâche fait partie des scénarios permettant de réaliser les cas d‟utilisation. Dans cette
phase, un ensemble de tâches sont créés à partir des diagrammes des cas d‟utilisation pour
chaque acteur. Cette phase peut être formalisée en se basant principalement sur les diagrammes
de séquences définis en UML qui jouent un rôle fondamental pour la représentation des
différents scénarios des cas d‟utilisation.
Le refactoring des cas d‟utilisation est la redistribution des comportements en termes de tâches
d‟un cas d‟utilisation à un autre. A partir des tâches des différents cas d‟utilisation, et en
appliquant les règles de refactoring, nous pouvons identifier des cas d‟utilisation bien adaptés.
Kim et al. (Kim et al., 2006) identifient cinq règles de refactoring : la règle de refactoring par
décomposition, la règle de refactoring par équivalence, la règle de refactoring par généralisation,
la règle de refactoring par fusion et la règle de refactoring par suppression.
La règle de refactoring par décomposition est appliquée lorsque nous avons des cas d‟utilisation
compliqués. Dans cette situation, il est nécessaire de faire décomposer ce cas d‟utilisation en des
sous-cas d‟utilisation plus simples. Ceci est effectué en utilisant l‟ensemble des tâches associées
à chaque cas d‟utilisation. En effet, pour chaque cas d‟utilisation, nous élaborons les tâches
permettant de réaliser le cas d‟utilisation. A partir de ces tâches, nous pouvons déduire des
fonctionnalités indépendantes et par conséquent, définir des sous-ensembles de tâches qui
correspondent à des nouveaux cas d‟utilisations.
Le refactoring par équivalence s‟applique à des cas d‟utilisations ayant des tâches équivalentes.
Dans ce cas, nous pouvons conclure que les deux cas d‟utilisations ont le même comportement et
on peut les traiter comme un seul cas d‟utilisation correspondant à un seul service.
Le refactoring par généralisation peut s‟appliquer lorsque nous avons des cas d‟utilisation qui
partagent des tâches communes. Dans ce cas, nous créons un cas d‟utilisation de base contenant
les tâches communes ainsi que de nouveaux cas d‟utilisation étendant le cas d‟utilisation de base.

131 Processus de Développement Dirigé par les Modèles des Systèmes Orientés Services Adaptables
Le refactoring par fusion est appliqué lorsque nous avons des cas d‟utilisation de granularité fine
qui modélisent des fonctionnalités sémantiquement reliées. Dans ce cas, nous fusionnons les
deux cas d‟utilisation pour avoir un cas d‟utilisation plus consistant.
Le refactoring par suppression est défini lorsque nous avons un cas d‟utilisation qui n‟a aucune
relation que ce soit avec les autres cas d‟utilisation ou avec les acteurs du système. Dans cette
situation, le cas d‟utilisation est redondant et par conséquent on peut le supprimer du système.
Dans le cadre de notre étude de cas, nous avons identifié les cas d‟utilisation qui interagissent
avec un acteur prédéfini. Nous décrivons chaque cas d‟utilisation par un ensemble de tâches,
comme présenté dans la figure 80 pour le cas d‟utilisation « assurer Formation » associé à
l‟acteur Enseignant. Pour chaque acteur (Etudiant, Enseignant, Administrateur), nous identifions
les différents modèles métiers se composant des services correspondant et répondant aux besoins
d‟un acteur donné.
T1. L‟enseignant consulte l‟agenda
T2. L‟enseignant gére les forums
T2.1 L‟enseignant consulte un forum
T2.2 L‟enseignant recherche un forum donné
T2.3 L‟enseignant poste un message dans un forum
T3.l‟enseignant gère les tests
T3.1 l‟enseignant ajoute un test
T3.2 L‟enseignant consulte un test
T3.3 L‟enseignant propose une solution à un test
T4. L‟enseignant gére les ateliers
T4.1 L‟enseignant peut consulter un atelier
T4.2 L‟enseignant propose une solution à l’atelier
T5.l‟enseignant gére les devoirs
T5.1 L‟Enseignant peut consulter un devoir
T5.2 L‟Enseignant propose une solution à un devoir
T6. L‟enseignant gérer la documentation d‟une formation.
T6.1 L‟enseignant peut consulter la documentation d‟une formation donnée
T6.2 L‟enseignant ajoute la documentation d‟une fomation
T6.3 l‟enseignant supprime la documentation d‟une formation
T7. L‟enseignant peut gérer les glossaires d‟une formation donnée
T7.1 L‟enseignant consulte un glossaire
T7.2 L‟enseignant ajoute un article dans un glossaire
T7.3 L‟enseignant recherche un article dans un glossaire
T8. L‟enseignant participe dans les chats.
T8.1 L‟enseignant ajoute un chat
T8.2 L‟enseignant modifie un chat
T8.3 L‟enseignant participe à un chat
T9.L‟enseignant gére les examens
T9.1 L‟enseignant consulte l‟agenda des examens
T9.2 L‟enseignant propose le sujet de l‟examen
T9.3 L‟enseignant corrige les copies de l‟examen
T9.4 L‟Enseignant saisit les notes d‟un examen d‟une formation donnée
Figure 80–Scénario associé au cas d’utilisation «assurer Formation» associé à l’acteur
Enseignant

132 Processus de Développement Dirigé par les Modèles des Systèmes Orientés Services Adaptables
En ce qui concerne l‟acteur Enseignant, comme illustré dans la figure 81, le cas d‟utilisation
«Assurer formations» est décomposé entre trois cas d‟utilisation «Documentation», «Examen»,
et «Formation». Chaque cas d‟utilisation est décrit par un ensemble de fonctionnalités
indépendantes. Ainsi, chaque cas d‟utilisation devient un service. Au contraire, le cas
d‟utilisation «Gestion de formations» est décrit par des fonctionnalités qui ont des relations avec
le service « Formation». Dans ce cas, le service identifié sera fusionné avec le service Formation
puisque les deux services fournissent des activités sémantiquement proches.
PIM-Enseignant
Formation
Documentation
Examen
Agenda
Figure 81–Identification des services associés à l’acteur « Enseignant »
La figure 82 montre les différents services qui composent le modèle de services correspondant à
l‟acteur Administrateur. Pour cet acteur, le cas d‟utilisation Inscription est décrit avec des tâches
indépendantes. Dans cette situation, ce cas d‟utilisation devient automatiquement un service. Au
contraire, le cas d‟utilisation «Gestion de formations» est décomposé en de sous-cas d‟utilisation
Agenda, Examen et Formation. Chaque cas d‟utilisation est décrit par un ensemble indépendant
des fonctionnalités indépendantes. Ainsi, chaque cas d‟utilisation deviendra un service.

133 Processus de Développement Dirigé par les Modèles des Systèmes Orientés Services Adaptables
PIM-Administrateur
Formation
Inscription
Examen
Agenda
Figure 82–Identification des services associés à l’acteur «Administrateur»
Figure 83 illustre les différents services qui composent un modèle correspondant à l‟acteur
Etudiant. Pour cet acteur, le cas d‟utilisation «Inscription» est décrit par des ensembles de tâches
indépendantes. Ainsi, ce cas d‟utilisation devient un service. Au contraire, le cas d‟utilisation
«Suivre formation» est décomposé en quatre cas d‟utilisations Agenda, Documentation,
Examen et Formation. Chaque cas d‟utilisation est décrit par des fonctionnalités indépendantes.
En conséquence, chaque cas d‟utilisation devient un service.
PIM-Etudiant
Formation
Inscription
Documentation
Examen
Agenda
Figure 83–Identification des services associés à l’acteur «Etudiant »
III.4.3.
Phase 3 : Spécification des interfaces de services
Un service est caractérisé par ses interfaces fournies aux différents clients du service. Dans cette
phase et après l‟identification de services, vient ensuite l‟étape de la définition des interfaces de

134 Processus de Développement Dirigé par les Modèles des Systèmes Orientés Services Adaptables
services. Chaque interface décrit les fonctionnalités que le service peut fournir à ses clients.
Ainsi, chaque interface de service se compose des opérations fournies par le service ainsi que ses
messages en entrée/sortie. Généralement, les interfaces de services, les opérations de service et
les messages d‟entrée et de sortie sont identifiés lors de la description des cas d‟utilisation via un
ensemble de tâches. En effet, chaque interaction entre un acteur et un service ou entre services
permet l‟identification des opérations ainsi que leurs messages en entrée ou en sortie.
L‟artefact clé caractérisant cette phase est un PIM raffiné qui correspond à un acteur donné. Ce
PIM se base sur les PIMs définis dans la précédente phase. Il se compose des services et de la
spécification de leurs interfaces. La figure 84 et la figure 85 décrivent les interfaces des services
de notre étude de cas correspondant aux acteurs Etudiant et Administrateur. Nous fournissons
pour chaque service ses interfaces associées aux différents acteurs.
PIM raffiné-Etudiant
Agenda
consulterAgenda() ;
Documentation
consulterDocumentation()
telechargerDocumentation() ;
proposerSuplementDocumetation() ;
Examen
consulterCalendrierExamen() ;
consulterExamen() ;
poserQuestionExamen() ;
deposerCopies() ;
consulterNotes() ;
Formation
consulterFormation() ;
consulterExercice() ;
proposerSollutionExercice() ;
posterMessage() ;
proposerTestSolution() ;
accessProjectRessource() ;
consulterProjet() ;
consulterAnnounceFormation() ;
consultSynopsisFormation ;
consultListFormation() ;
consulterForum() ;
afficherForum() ;
rechercherFOrum() ;
consulterDevoir() ;
afficherDevoir() ;
rechercherDevoir() ;
consulterGlossaire() ;
afficherGlossaire() ;
ajouterArticleGlossaire() ;
importerGlossaire() ;
consulterTest() ;
afficherTest() ;
afficherChat() ;
participerChat() ;
Figure 84–PIM raffiné associé à l’acteur Etudiant

135 Processus de Développement Dirigé par les Modèles des Systèmes Orientés Services Adaptables
PIM raffiné-Administrateur
Inscription
consulterDateLimite();
consulterListeFormation();
deciderInscription();
ajouterListeAttente() ;
fixerFraisInscription() ;
Examen
consulterCalendrierExamen();
definirCalendrierExamen();
consulterNotesEtudiants();
Formation
ajouterNouvelleFormation();
ajouterAnnounceFormation();
supprimerFormation();
affecterResponsableFormation();
consulterSynopsisFormation();
consulterListFormation();
Agenda
ConsulterAgenda()
ajouterEvenement()
supprimerEvenement()
Figure 85– PIM raffiné associé à l’acteur Administrateur
III.4.4.
Phase 4 : Fusion des modèles visuels
Une fois les modèles par acteurs élaborés, la phase de fusion de ces modèles peut commencer.
L‟objectif de cette phase est la production d‟un modèle global à base de services représentant les
différents besoins des différents acteurs sans pour autant perdre les spécificités de chaque acteur.
La première étape de la phase de fusion consiste en la comparaison des différents modèles
associés aux différents acteurs élaborés dans les précédentes phases pour éventuellement détecter
les incohérences ou les ambiguïtés sur les services (nommages, messages d‟entrée/sortie des
opérations, interfaces de services, services). Une fois cette étape élaborée, nous procédons par la
suite à produire un modèle métier global multidimensionnel représentant notre système. Dans
cette phase, chaque service apparaissant dans plusieurs modèles visuels est un service multivues
ayant une interface de service multivues. Cette interface se compose d‟une interface de service
de base contenant les opérations communes entre les différents services identifiés dans les
différents modèles associés aux acteurs, et un ensemble d‟interfaces de services vues
représentant les besoins et les spécificités de chaque acteur.
La phase de fusion peut être formalisée mathématiquement en se basant sur la théorie des
graphes. En effet, notre équipe a déjà développé une approche à base des graphes pour la fusion
des diagrammes de classes UML (Anwar, 2009) pour produire des diagrammes des classes

136 Processus de Développement Dirigé par les Modèles des Systèmes Orientés Services Adaptables
multivues. Dans le cadre de notre étude de cas, le service Agenda, Inscription, Formation,
Examen et Documentation apparaissent dans plusieurs modèles visuels. Dans ce cas, nous
concluons que ces services sont des services multivues. En conséquence, nous procédons à la
définition de leurs interfaces de service multivues.
Après l‟exécution des activités de cette phase, nous obtenons un PIM global qui se compose des
différents services multivues ainsi que de leurs interfaces de service multivues. La Figure 86
illustre l‟interface de service multivues du service Formation.
Formation
Formation_Administrateur
ajouternouvelleFormation();
ajouterCalendrierFormation() ;
ajouterAnnounceFormation() ;
supprimerFormation() ;
affecterResponsableFormation() ;
Formation
Formation_Etudiant
consulterFormation() ;
consulterExercice() ;
proposerSollutionExercice() ;
posterMessage() ;
proposerTestSolution() ;
accessProjectRessource() ;
consulterProjet() ;
consulterAnnounceFormation() ;
Formation
consultSynopsisFormation ;
consultListFormation() ;
Course_Enseignant
ajouterFormation();
supprimerFormation() ;
ajouterExercice() ;
ajouterSolutionExercice() ;
proposerProjet() ;
poserQuestion() ;
proposerForum() ;
proposerTest() ;
ajouterAnnounceFormation() ;
repondreQuestionsEtudiants() ;
Figure 86–Extrait du résultat de l’étape de fusion du service Formation

137 Processus de Développement Dirigé par les Modèles des Systèmes Orientés Services Adaptables
III.4.5.
Phase 5: Transformation des modèles et génération de code
L‟objectif des phases précédentes est la spécification d‟un système orienté service
indépendamment des technologies d‟implémentations (dotNet, JWSDP, etc) et des standards de
la technologie des services web (e.g., WSDL, UDDI, SOAP, BPEL4WS, etc). Le résultat de ces
phases est un modèle métier de haut niveau se composant principalement d‟un ensemble de
services multivues qui décrivent la structure et les fonctionnalités du système à concevoir. Pour
la prise en compte des plates-formes technologiques, l‟objectif de cette phase est la génération de
code à partir des modèles métiers définis en se basant sur un ensemble de transformations. Cette
génération de code concerne la génération de l‟implémentation et de la description des services
multivues.
Pour atteindre ces objectifs, la phase de transformation de modèles peut être effectuée en la
décomposant en plusieurs étapes : (1) la première étape consiste en la création des métamodèles
ou l‟utilisation des métamodèles existants pour la construction des PIMS. Généralement, ces
métamodèles doivent être conformes au MOF. Dans notre cas de figure, nous utilisons le
métamodèle de notre profil défini VSoaML qui permet la modélisation et la spécification des
systémes orientés services adaptables. Ce métamodèle est conforme au MOF. (2) La deuxième
étape de la phase de transformation vise principalement le choix ou la création des métamodèles
en vue de l‟élaboration des plateformes technologiques. Il s‟agit de choisir un métamodèle
existant d‟une plateforme technologique telles que .Net ou J2EE ou créer un nouveau
métamodèle qui permet la définition d‟un PSM dans le cas de l‟apparition d‟une nouvelle
technologie surtout si on sache que les technologies évoluent rapidement et sans cesse.
(3) la troisième étape de la phase de transformation permet la définition des correspondances
entre le métamodèle source (i.e le métamodèle du PIM) et le métamodèle cible (i.e , le
métamodèle du PSM). Pour chaque élément constituant le métamodèle, il faut identifier les
éléments du métamodèle cible qui lui sont similaires et équivalents.
(4) la quatrième étape vise la définition des règles de transformations via l‟utilisation d‟un
langage de transformation donné tel que ATL (ATL ,2004), YATL, BOTL (Bidirectional Object

138 Processus de Développement Dirigé par les Modèles des Systèmes Orientés Services Adaptables
oriented Transformation Language) (Marschall et al., 2003) tout en se basant sur les
correspondances définies dans l‟étape précédente.
(5) la cinquième étape de la phase de transformation vise l‟utilisation de la définition de
transformation pour pouvoir transformer un modèle métier d‟entrée en un modèle de sortie
spécifique à une plateforme (PSM). Ensuite, nous vérifions si les PSMs générés sont complets
ou pas. S‟ils sont incomplets, cette étape nécessite l‟intervention des développeurs pour les
compléter.
(6) la dernière étape de cette phase a pour objectif la génération du code, des fichiers de
configuration et de déploiement à partir des PSMs finaux générés lors des précédentes étapes.
PIM(VSoaML)
Tranformation des modéles
PSMs
Génération du code
Code
Figure 87-Phase de transformation de modèle et génération du code

139 Processus de Développement Dirigé par les Modèles des Systèmes Orientés Services Adaptables
III.5. Conclusion
Dans le cadre de ce chapitre, nous avons présenté un processus de développement des systèmes
orientés services adaptables aux différents types d‟utilisateurs en se basant sur le profil VSoaML.
La caractéristique principale d‟un tel processus est sa définition dans le cadre de l‟approche
MDA. Ce processus définit les phases, les artéfacts et les activités nécessaires pour identifier,
spécifier et implémenter les services multivues. Les phases principales de ce processus sont :
(1) l‟élaboration des cas d‟utilisations permettant de formaliser les besoins métiers des differénts
utilisateurs
(2) l‟identification des services par acteurs (rôles)
(3) la spécification des interfaces des services associées à chaque acteur
(4) la fusion des différents modèles visuels,
(5) la phase de transformation des différents modèles et de génération du code vers des
plateformes d‟implémentation.
Ce processus est illustré à travers une étude de cas concernant un système d‟enseignement à
distance.
Après avoir présenté le profil VSoaML (Cf.chapitre 2) ainsi que le processus de développement
des SOSs, deux composantes de notre approche d‟ingénierie des SOSs adaptables, l‟objectif du
chapitre suivant est de présenter la troisième composante de cette approche. Il s‟agit de l‟outil
permettant l‟automatisation de la génération du code à partir des modèles métiers de haut niveau
exprimé en se basant sur notre profil et élaboré selon notre processus de développement.

140 VSoaMLTool : Outil de génération de code automatique
IV. VSoaMLTool : Outil de génération de code automatique
IV.1. Introduction
Ce chapitre présente l‟outil VSoaMLTool (Kenzi et al., 2009b) ayant pour objectif la génération
de code à partir des modèles métiers abstraits de haut niveau. VSoaMLTool est défini dans le
cadre de l‟ingénierie dirigée par les modèles en se basant plus particulièrement sur les standards
et les concepts de l‟approche MDA. En effet, après l‟élaboration des modèles métiers,
VSoaMLTool se base principalement sur des transformations ciblant différentes plateformes
technologiques pour la génération des différents artéfacts d‟un Système Orienté Services.
VSoaMLTool peut être vu comme étant un atelier de génie logiciel associé au profil VSoaML.
Comme nous l‟avons présenté dans le chapitre 2, VSoaML permet de modéliser et de spécifier
un système orienté service adaptable indépendamment des plates-formes d‟implémentation
(J2EE, dotNet, etc.) et les standards de la technologie des services web (SOAP, WSDL, UDDI,
BPEL4WS). VSoaML se base fondamentalement sur le concept de service multivues comme une
entité de modélisation capable de représenter les besoins et les spécificités des utilisateurs
suivant leurs profils. Le service multivues est une nouvelle entité de modélisation qui fournit, en
plus des interfaces de services, des interfaces qui se caractérisent par leur flexibilité et
adaptabilité aux différents acteurs interagissant avec le service. Ce profil est utilisé
essentiellement comme formalisme de modélisation permettant l‟élaboration d‟un PIM. Ce PIM
fera l‟objet de transformations en vue de la génération de la description de chaque service
multivues et de son implémentation suivant différentes plateformes technologiques (e.g., J2EE,
.Net).
La première transformation concerne la génération de la description de chaque service multivues
composant le PIM d‟un système donné. En effet, nous avons défini une légère extension au
standard WSDL pour la description de service multivues, appelée MVWDL. Cette extension de
WSDL permet la représentation en XML aussi bien des interfaces d‟un service donné que les
informations concernant les acteurs interagissant avec ce service. Cette transformation est définie

141 VSoaMLTool : Outil de génération de code automatique
par un ensemble de règles de transformation en utilisant le langage ATL comme un langage de
transformation de modèles.
La deuxième transformation concerne la génération du code constituant l‟implémentation de
chaque service multivues ciblant principalement la plateforme d‟implémentation J2EE.
Chaque transformation de modèles a été décomposée en deux étapes : la première étape concerne
la spécification des correspondances. La deuxième étape permet la définition de transformations
en se basant sur le langage de transformation de modèle ATL. En fait, la spécification de
correspondances vise à définir les correspondances entre les éléments des métamodèles source et
cible, et la définition de transformations permet de décrire en détail et d‟exécuter les étapes de la
transformation d‟un modèle en un autre modèle en respectant la spécification de
correspondances. Cette approche va dans le même sens que la vision de l‟OMG pour le
développement des systèmes informatiques à savoir la séparation des préoccupations. En fait,
une spécification de correspondances peut être vue comme un PIM et une définition de
transformations comme un PSM.
Une fois générées la description de chaque service multivues et son implémentation, nous
illustrons comment faire le déploiement de tels artefacts suivant l‟architecture SOA.
La structure de ce chapitre est la suivante. La section 2 présente un aperçu global de l‟outil
VSoaMLTool en identifiant ses principaux modules et leurs fonctionnalités. La section 3 illustre
les différentes transformations effectuées par l‟outil VSoaMLTool pour la génération
automatique de code. La section 4 permet d‟illustrer le déploiement des artefacts générés par
l‟outil VSoaMLTool selon l‟architecture SOA.
IV.2. VSoaMLTool : modules et fonctionnalités
VSoaML est un profil UML capable de décrire un système orienté service adaptable à un haut
niveau d‟abstraction. Il permet d‟exprimer des modèles métiers indépendamment des platesformes
d‟implémentation et des standards. Pour outiller ce profil, nous avons développé un
outil logiciel, appelé VSoaMLTool, à l‟instar d‟Objecteering ou RSA. VSoaMLTool permet

142 VSoaMLTool : Outil de génération de code automatique
l‟édition des modèles métiers, de transformer ces modèles en vue de la génération du code
concret. Il permet aussi le déploiement des différents artefacts générés d‟un SOS adaptable : les
descriptions des services multivues ainsi que leurs implémentations selon différentes plateformes
technologiques. Le module déploiement a pour objectif principal le déploiement des différents
services d‟un SOS adaptable. Il s‟agit principalement de déployer les implémentations ainsi que
des descriptions de chaque service multivues suivant l‟architecture de référence de la technologie
des services web. La figure 88 illustre les différents modules de l‟outil VSoaMLTool :
Module Edition de
modèle
PIM(VSoaML)
Module Transformation de modèles
Description
Implémentation (Java,
C#)
Composition de services BPEL
Module Déploiement
Figure 88–Modules de VSoaMLTool
Dans le cadre de ce chapitre, nous nous concentrons tout particulièrement sur le module de
transformation de modèles et de génération du code ainsi que le module de déploiement. Le
module d‟édition des modèles n‟est pas encore développé. Nous projetons utiliser les outils
associés aux DSL pour la réalisation de ce module. En particulier, le GMF (Graphical Modeling
Framework) qui permet le développement de générateurs d‟éditeurs de modèles.

143 VSoaMLTool : Outil de génération de code automatique
IV.3. VSoaMLTooL : Transformation de modèle et génération de code
Pour bénéficier des avantages de MDA, nous avons défini une approche MDA pour le
développement des systèmes orientés services adaptables. Ainsi, pour le développement d‟un
système orienté services adaptable, nous définissons premièrement un PIM en se basant sur notre
profil VSoaML. Ce PIM reflète la structure et les fonctionnalités d‟un système suivant les
acteurs interagissant avec chaque service. Pour chaque service qui compose le système, nous
représentons les exigences métiers en identifiant les fonctionnalités communes et les
fonctionnalités variant d‟un acteur à un autre. Les fonctionnalités communes requises par tous les
acteurs sont représentées en utilisant l‟élément de modélisation “baseServiceInterface” et les
fonctionnalités spécifiques à chaque acteur sont représentées en utilisant l‟élément de
modélisation “ViewServiceInterface”.
Une fois le PIM élaboré en utilisant le profil VSoaML, nous définissons deux transformations :
une transformation pour la génération de la description de chaque service multivues composant
le système. Une deuxième transformation permettant la génération des implémentations de
service multivues ciblant la plateforme J2EE.
La figure 89 illustre les différentes transformations définies dans le cadre de notre approche.
PIM (VSoaML)
et
Transformation
modèle vers
modèle
MVWSDL(PSM)
J2EE(PSM)
Transformation
modèle vers code
Code (document
MVWSDL)
Code (Code Java)
Figure 89–Processus de génération de code à partir des PIMs (VSoaML)
La démarche MDA permettant d‟effectuer la transformation des modèles PIM en vue de la

144 VSoaMLTool : Outil de génération de code automatique
génération du code selon différentes plateformes, se définit en plusieurs étapes. Premièrement,
nous commençons par la création ou l‟utilisation des métamodèles existants des PIMs et des
PSM. En deuxième lieu, nous spécifions les correspondances entre le métamodèle source et le
métamodèle cible. Il s‟agit de définir les équivalences entre un élément du métamodèle source et
les éléments qui lui sont équivalents du métamodèle cible. En troisième lieu, nous définissons les
règles de transformation en utilisant un langage de transformation de modèles donné. En
quatrième lieu, nous appliquons ces règles de transformation sur un modèle métier en entrée,
pour obtenir, en sortie, un modèle spécifique à une plateforme donnée. En cinquième lieu, on
vérifie ce PSM, s‟il est incomplet, on le complète. Dans le cas contraire, nous générons le code.
Les sections suivantes illustrent le processus défini dans la figure 85. La section 4 présente le
PIM de notre étude de cas à base de service multivues. La Section 5 illustre le métamodèle du
profil VSoaML. La section 6 décrit la transformation du PIM(VSoaML) permettant la génération
du code MVWSDL. La section7 décrit les différentes transformations permettant la génération
du code java par transformation du PIM(VSoaML). La section 8 décrit le module de déploiement
suivant l‟architecture SOA des artefacts générés.
IV.4. Le PIM (VSoaML) de l’étude de cas DLS
Notre étude de cas est une version simplifiée d‟un Système d‟enseignement à distance. Notre
objectif est d‟utiliser cette version simplifiée pour illustrer et valider notre approche. Ainsi, nous
avons identifié certains services multivues du DLS : Inscription, Formation, Documentation et
Examen. Ces services sont multivues du moment où ils interagissent avec plusieurs acteurs :
Enseignant, Etudiant et Administrateur. Le service Inscription fournit les fonctionnalités
nécessaires à l‟étudiant pour faire son inscription. Il permet à l‟administrateur de gérer les
inscriptions des étudiants, de fixer les frais d‟inscription aux différentes formations et décider des
inscriptions des étudiants. Le service Formation fournit à l‟étudiant les fonctionnalités lui
permettant de suivre des formations. Ils peuvent accéder aux exercices, poser des questions,
consulter les projets d‟une formation donnée, faire des quiz et envoyer des messages aux forums
de discussion spécifiques à une formation donnée. Le service Formation permet à l‟étudiant de
créer des formations, de répondre aux questions des étudiants, de proposer des exercices et de
répondre aux messages des forums de discussion. L‟acteur administrateur utilise le service

145 VSoaMLTool : Outil de génération de code automatique
Formation pour fixer les frais d‟une formation donnée, pour gérer son calendrier et pour affecter
les responsables des formations. Le service Documentation permet à un enseignant de charger les
documents concernant une formation spécifique, de mettre à jour ou de supprimer leur contenu.
Il permet aux étudiants de télécharger les documentations nécessaires (fichiers pdf, audio/video,
etc). Le service Examen permet à l‟étudiant de passer des examens, de télécharger le sujet, de
poser des questions de compréhension et de consulter ses notes. Il permet à l‟enseignant de
proposer un examen, de répondre aux questions des examens.
Le service multivues La spécification associée L‟interface de service multivues
associée
Service Formation
Formation
MultiviewServiceinterface
Formation
Service Documentation
Documentation
MultiviewServiceinterface
Documentation
Service Examen
Examen
MultiviewServiceinterface
Examen
Service Inscription
Inscription
MultiviewServiceinterface
Inscription
Tableau 9–Services multivues du Systéme d’Enseignement à distance
Pour élaborer notre PIM en utilisant le profil VSoaML, nous avons pris en compte les
caractéristiques du service en SOC. En effet, un service est autonome, indépendant et peut être
utilisable dans plusieurs contextes et processus métiers. Ainsi, dans notre cas d‟étude nous avons
identifié les services qui permettent l‟implémentation des fonctionnalités principales du DLS.
Chaque service identifié est autonome, indépendant et il encapsule des fonctionnalités cohésives.

146 VSoaMLTool : Outil de génération de code automatique
Le Tableau 9 présente les services multivues du DLS ainsi que leurs spécifications (chaque
service a une « Specification » et chaque spécification contient la description des interfaces de
services ainsi que la description des interfaces de service multivues). La figure 90 illustre les
différents types d‟interfaces des différents services multivues. Cette figure illustre la structure
Le PIM (VSoaML) du DLS
Formation_Enseignant
Formation_Enseignant
Examen_Enseignant
Course_Base
ajouterFormation() ;
supprimerFormation() ;
ajouterExercice() ;
ajouterSolutionExercice() ;
proposerProjet() ;
poserQuestion() ;
ProposerForum(),
repondreQuestionsEtudiants() ;
proposerTest() ;
proposerQuiz() ;
consultSynopsisFormation() ;
consultListFormation() ;
ajouterExamen() ;
repondreQuestionExamen() ;
evaluerExamen() ;
ajouterNotes() ;
Exam_Student
consulterCalendrierExamen() ;
Formation_Etudiant
consulterExamen() ;
poserQuestionsExamen() ;
consulterNotest() ;
consulterFormation() ;
consulterExercice() ;
proposerSolutionExercice() ;
posterMessage();
proposeSolutionTest() ;
consulterAnnounceFormation() ;
Examen_Administrateur
consulterNotesEtudiant() ;
definirCalendrierExamen() ;
Course_Professor
ajouterNouvelleFormation();
ajouterCalendrierFormation(),
supprimerFormation() ;
affecterResponsableFormation() ;
Doc_enseignant
Doc_Enseignant
Inscription_Etudiant
Inscription
chargerDocumentation() ;
updateDocumentation() ;
supprimerDocumentation() ;
consulterDocumentation()
;
demanderInscription() ;
payerFraisInscription();
consulterDateLimite() ;
consulterListFormation() ;
Insciption_Administrateur
Doc_etudiant
deciderInscription() ;
ajouterListeAttente() ;
fixerFraisInscription() ;
telechargerDocumentation() ;
proposerSuplementDocumentati
on() ;
Figure 90–Extrait des interfaces de service multivues des services multivues du DLS

147 VSoaMLTool : Outil de génération de code automatique
des interfaces de services multivues. En fait, chaque interface de service multivues est composée
d‟une interface de service de base qui représente les fonctionnalités communes entre les
différents acteurs. Les interfaces de service vues représentent les fonctionnalités spécifiques à
chaque acteur.
IV.5. Le métamodèle du profil VSoaML
Comme nous l‟avons expliqué dans la section IV.3, la transformation de modèle nécessite la
création de nouveaux métamodèle ou l‟utilisation des métamodèles existants. Dans notre cas de
Figure 91–Métamodèle VSoaML

148 VSoaMLTool : Outil de génération de code automatique
figure, et dans l‟objectif de l‟automatisation de la génération de code, nous avons défini un
métamodèle de notre profil VSoaML comme expliqué dans le deuxième chapitre. La figure 91
illustre le métamodèle du profil VSoaML.
IV.6. Du PIM (VSoaML) vers des descriptions (MVWSDL)
L‟objectif de cette section est de présenter les transformations définies pour la génération des
descriptions MVWSDL à partir d‟un PIM exprimé en VSoaML. Dans un premier temps, nous
présentons MVWSDL notre extension du standard MVWSDL ainsi que son métamodèle. Dans
un second temps, nous présentons la transformation du PIM élaboré en utilisant le profil
VSoaML vers un PSM à base de MVWSDL en spécifiant les correspondances entre métamodèle
source et cible et en définissant les règles de transformation en utilisant un langage de
transformation de modéles tel que ATL (ATL, 2004).
IV.6.1.1
Le Multiview WSDL pour la description des services multivues
WSDL (Web Service Description Language) est un standard W3C qui définit un format de
description des services web fondé sur XML. Les services sont représentés en WSDL comme un
maillage de terminaisons agissant sur des messages contenant des informations sur des
documents ou des procédures indépendamment des protocoles de transport de messages utilisés.
WSDL permet principalement la description d‟un service web et plus spécifiquement :
Ses interfaces
Ses opérations fournies
Les paramètres d‟entrée/sortie
Le type des paramètres de chaque opération
Les points d‟entrées (URL) des différentes opérations.
Dans la pratique, le standard WSDL définit un langage pour l‟élaboration des documents XML
pour la description des services. Chaque document WSDL contient une ou plusieurs définitions
de Services Web reprenant, pour chacun d‟entre eux, les différents composants (types de
données, messages, types de port, liaisons et ports). Il est également possible d‟utiliser la balise
pour fragmenter et rassembler les documents WSDL. Comme pour SOAP, la définition
de WSDL mentionne des Namespaces de référence où se trouvent les définitions XMLSchema

149 VSoaMLTool : Outil de génération de code automatique
des balises WSDL elles-mêmes. Le squelette général d‟un document WSDL est illustré par le
schéma suivant (cf. figure 92) :
…
…
…
…
…
…
…
Figure 92–Structure d'un document WSDL
Plusieurs extensions du standard WSDL ont été proposées dans la littérature pour la prise en
compte de différentes préoccupations non prises en compte initialement par le standard WSDL.
Dans ce sens, Q-WSDL, C-WSDL, SAWSDL(Farrel et al., 2007) ont été définies pour la prise en
compte respectivement de la qualité de service, du contexte ou de la sémantique. Dans notre
approche, nous proposons MVWSDL comme une légère extension du standard WSDL. En effet,
le standard WSDL définit un schéma XML pour la description du service. Ce schéma XML se
base sur six éléments principaux (Types, Messages, PortType, Binding, Port, Service) permettant
de définir les interfaces de services, leurs opérations, les paramètres d‟entrée/sortie de chaque
opération, le type de ces paramètres ainsi que les points d‟entrée (URL) de ces opérations.
Cependant, ce standard ne permet pas la prise en compte du profil de l‟acteur interagissant avec
le service. En effet, deux clients de service avec de profils différents peuvent avoir la même
description WSDL. Ainsi, nous définissons une extension du standard WSDL pour la description
d‟un service multivues. Une telle extension est appelée MVWSDL (MultiView WSDL). Cette
extension permet de faire adapter chaque élément du WSDL à l‟acteur interagissant avec le
service. L‟objectif de cette extension est, d‟une part, de décrire dans un seul document XML
l‟ensemble des interfaces fournies des services qu‟elles soient simples ou multivues. D‟autre part,
elle permet d‟adapter cette description à l‟exécution suivant le profil de l‟utilisateur interagissant

150 VSoaMLTool : Outil de génération de code automatique
avec le service en fournissant à chaque utilisateur la description WSDL standard correspondant à
son profil.
Dans l‟objectif de génération de code conformément aux principes et aux standards de
l‟approche MDA, nous avons établi le métamodèle de MVWSDL comme une extension du
métamodèle WSDL pour la prise en compte du type d‟acteur interagissant avec le service via
l‟ajout de la métaclasse «actor» au métamodèle WSDL. Une telle métaclasse permet de définir le
type d‟acteur interagissant avec le service, et s‟associe aux principales métaclasses du
métamodèle WSDL (cf. figure 93) qui doivent s‟adapter aux profils des utilisateurs.
Le métamodèle de MVWSDL définit les éléments suivants :
Definition : Definition est l‟élément principal du métamodèle de MVWSDL. il
contient les éléments : Import, Type, Message, PortType, Binding et Service
Import : cet élément permet l‟association d‟un espace de noms à la localisation
d‟un document XML.
Types : cet élément est utilisé pour la définition des types simples ou
complexes en se basant sur un schéma XML. Dans l‟objectif de maximiser
l‟interopérabilité entre plateformes hétérogènes, WSDL adopte le XSD comme
un système de types.
Message : cet élément permet la représentation abstraite des données que le
service envoie ou reçoit. Chaque Message se compose des parties (élément
Part) permettant la description d‟une partie d‟un message.
PortType : cet élément permet la définition des interfaces de service. Chaque
PortType se compose d‟un ensemble d‟opérations abstraites. Chaque opération
possède en entrée /sortie un message. les opérations constituant les portType
d‟un service sont caractérisées par les éléments onewyaoperation,
RequestResponseoperation, sollicitResponse et notificationOperation.
Binding : l‟élément binding permet de spécifier un protocole concret de
transport (SOAP, HTTP/GET, SMTP, etc.). Il permet aussi de spécifier les
formats de données pour les opérations et les messages définis dans un
portType donné. L‟élément bindingOperation contient les éléments input,
output et fault décrits selon la réalisation concrète de l‟appel.

151 VSoaMLTool : Outil de génération de code automatique
Port : cet élément permet de spécifier une adresse d‟une liaison définissant un
simple point terminal de communication.
Service : cet élément permet de décrire un service en identifiant ses interfaces
et leur localisation
Actor : cet élément permet la définition des acteurs potentiels intéragissant avec
le service. Il est en relation avec les éléments principaux du métamodèle
WSDL (Types, Message, PortType, Binding, Service).
Figure 93–Métamodèle MVWSDL
IV.6.1.2
Du PIM(VSoaML) vers PSM(MVWSDL)
Dans le cadre de l‟approche MDA, la transformation d‟un PIM vers un PSM nécessite
premièrement la spécification des correspondances entre le métamodèle source et le métamodèle
cible. Ces correspondances sont définies en étudiant les équivalences entre les éléments du
métamodèle source et les éléments du métamodèle cible. En effet, deux ou plusieurs éléments des
différents métamodèles s‟ils sont compatibles et ne présentent pas de contradiction entre eux.
Dans notre cas de figure, nous utilisons le métamodèle de VSoaML comme métamodèle source et

152 VSoaMLTool : Outil de génération de code automatique
le métamodèle de MVWSDL comme métamodèle cible. Le tableau 10 illustre les
correspondances entre les éléments de ces deux métamodèles ainsi que les règles de
transformation y associées.
Après l‟identification des correspondances entre les éléments des deux métamodèles, nous
procédons à la définition des règles de transformation en utilisant le langage de transformation
ATL (ATL, 2004). Ce dernier fournit un plugging sous Eclipse (Eclipse, 2010) dédié à
l‟implémentation des règles de transformation.
Eléments du
métamodèle VSoaML
Eléments du métamodèle
MVWSDL
Régle de transformation
Specification Definition Speci2definition
BaseServiceInterface
Types, PortType,
Binding, Service,
BaseInterface2WSDL
ViewServiceInterface
Types, Portype,
Binding, Service
ViewInterface2WSDL
Parameter Part Param2part
ServiceOperation
PortypeOperation,
Operation2operation
BindingOperation,
InputMessage,
ouputMessage,
ComplexType
dataType Types dataType2type
Tableau 10–Correspondances VSoaML/MVWSDL
La règle de transformation Viewinterface2WSDL permet la création des instances de cinq
éléments du métamodèle du MVWSDL : PortType, Types, Binding, Port et Service. Ainsi,

153 VSoaMLTool : Outil de génération de code automatique
Chaque instance de l‟élément PortType est assignée avec les valeurs des attributs et les
références de l‟élément ViewServiceInterface du métamodèle du SMV. L‟attribut nom de
l‟instance Porttype créée est affecté avec la valeur v.name. La référence actor est affectée avec la
valeur du nom de l‟acteur (v.actor.name) associé à l‟élément viewinterface du métamodèle
MVservice!viewInterface. La référence operations est affectée avec toutes les opérations créés en
faisant appel à la règle de la transformation. La règle Viewinterface2WSDL crée aussi une
instance de l‟élément Types associée à chaque acteur en créant un schéma XML. Pour chaque
schema généré, ses attributs et références sont affectés avec les attributs et les références de
l‟élément viewinterface. Dans ce sens, l‟attribut namespace est initialisée avec le nom de
l‟interface alors que la référence complextype est affectée avec les types de données complexes
crée avec la règle.
La figure 94 illustre cette règle de transformation.
rule Viewinterface2WSDL{
from v: MVService!viewInterface
to out : WSDL!PortType(
name

154 VSoaMLTool : Outil de génération de code automatique
BaseServiceInterface vers cinq éléments du métamodèle : Types, PortType, Binding, Service et
Port. Cette règle est très similaire à la règle de transformation ViewInterface2ws. La différence
principale consiste en l‟attribut actor. En effet, cet attribut contrairement à la précédente règle est
affecté avec la valeur „allactors‟ du moment où l‟interface de service de base représente les
fonctionnalités accessibles par tous les acteurs.
La figure 95 illustre la règle BaseInterface2WSDL.
rule BaseInterface2WSDL{
from v: MVService!baseInterface
to out : WSDL!PortType(
name

155 VSoaMLTool : Outil de génération de code automatique
le contexte de chaque élément du métamodèle MVWSDL.
La figure 96 contient une requête utilisée pour effectuer la transformation modèle-rs-code.
query wsdl2code_query = WSDL!Definition.allInstances()->
collect(x|x.toString().writeTo('C:/SourceCodet11octobre/WSDL/'+ x.name.replaceAll('
.', '/') + '/' + x.name + '.wsdl')); -- Query Template
uses MVWSDL2code;
Figure 96–Requête de génération de code MVWSDL
La figure 97 présente le code ATL des helpers permettant la génération de code. Dans cette
figure, l‟opération allInstances() retourne une collection constituée de toutes les instances de
l‟élément WSDL!Definition présentes dans le modèle MVWSDL. L‟opération sur les collections,
appelée collect(), permet ensuite de récupérer chaque élément de cette collection (représenté par
x), et d‟invoquer l‟opération toString() sur chacun d‟eux. Cette opération est un helper en ATL
défini dans la bibliothèque MVWSDL2code. Après l‟exécution de ce helper, la chaîne de
caractères est écrite dans un fichier « *.wsdl » par le biais de l‟opération writeTo. L‟helper
toString() défini dans le contexte de MVWSDL!PortType enchaîne aussi d‟autres appels à
d‟autres helpers définis dans le contexte de Service, Port, PortType et ainsi de suite.
library MVWSDL2code; -- Library Template
helper context MVWSDL!Definition def: toString() : String =
''+
'\n' +
self.printTypes() +
self.printMessage() +
self.printPortType() +
self.printBinding() +
self.printService() +
'\n';
...
helper context MVWSDL!PortType def: toString(): String =
'\n' +
self.operations-> iterate(i; acc:String='' | acc+ i.toString())+
'\n';
…
;
Figure 97–Code ATL pour la génération de code MVWSDL
La description MVWSDL générée représente la définition des interfaces de services multivues
suivant les acteurs potentiels interagissant avec le service. Le code ci-dessous présente la

156 VSoaMLTool : Outil de génération de code automatique
description MVWSDL du service „Course‟. Ce service multivues est associé à l‟interface de
service multivues composée d‟une interface de service de base et des interfaces de service vues
(ViewServiceInterface). Pour illustrer notre approche, nous avons choisi seulement deux
...
...
...
Figure 98–Code MVWSDL généré
opérations des interfaces associées à deux acteurs qui sont l'étudiant et l'enseignant (Student,
Professor) et deux opérations constituant l‟interface de service de base. Cette derniére contient
les opérations : String consultSynopsisCourse (Course : String) et String consultCourseList (level
:String). L‟interface associée à l‟enseignant contient les opérations suivantes : String addExercice
(exerciseID : integer, Exercise : String) et String addExerciseSolution (ExerciseId : integer,
ExerciseSolution : String). L‟interface associée à l‟etudiant contient les opérations : String
postMessageForum (Course : String, message : String) et String ProposeExerciseSolution

157 VSoaMLTool : Outil de génération de code automatique
(ExerciseId : integer, Solution : String). La figure 98 illustre un extrait du code généré suivant le
méta-modèle de MVWSDL. Dans cet extrait, nous nous focalisons seulement sur l‟élément
PortType parce que les autres éléments se génèrent de la même façon.
IV.7. Du PIM (VSoaML) vers PSM (JaxRPC)
En SOC, chaque service possède une description de service ainsi qu‟une implémentation de
service. Pour générer automatiquement les descriptions de services ainsi que leurs
implémentations, nous avons défini deux transformations du même PIM ciblant deux platesformes
différentes comme illustré dans la figure 99 (le processus de transformation selon
l‟approche MDA). La première transformation permet la génération de la description des services
multivues suivant le métamodèle MVWSDL discuté dans les sections précédentes. La deuxième
transformation permet la génération de l‟implémentation de service ciblant la plateforme
d‟implémentation JAX-RPC. En effet, JAX-RPC est un élément principal définissant des APIs et
des librairies du Pack JWSDP (SUN, 2004) de la plateforme J2EE. JAX-RPC est dédié
principalement à l‟implémentation des services web.
PIM (VSoaML)
et
Transformation
modèle vers
modèle
MVWSDL(PSM)
J2EE(PSM)
Transformation
modèle vers code
Code (document
MVWSDL)
Code (Code Java)
Figure 99–Processus de génération des implémentations des services à partir des PIMs (VSoaML)
Dans l‟objectif de la génération automatique de l‟implémentation du service multivues ciblant
JAX-RPC comme plateforme d‟implémentation, nous devons, en premier lieu, définir le
métamodèle JAX-RPC. En deuxième lieu, nous devons définir les correspondances entre les
élements du métamodèle source à savoir le métamodèle du service multivues et les éléments du
métamodèle cible à savoir le métamodèle de JAX-RPC. En troisième lieu, nous avons défini les
règles de transformations permettant d‟implémenter les correspondances entre les éléments des

158 VSoaMLTool : Outil de génération de code automatique
deux métamodèles. En dernier lieu, nous avons défini des helpers ATL pour la génération du
code constituant le code Java constituant l‟implémentation du service multivues. Les sections
suivantes ont pour objectif la description des étapes de transformation définies ci dessus.
IV.7.1. Le métamodèle JAX-RPC
Le processus de transformation MDA nécessite un métamodèle source et un métamodèle cible
qui doivent être conformes au MOF pour pouvoir effectuer la transformation des modèles. Dans
notre approche, le métamodèle source choisi est celui de VSoaML qui est conforme au MOF. Le
métamodèle cible est le métamodèle JAX-RPC qui est conforme aussi au MOF.
La figure 100 présente un métamodele de JAX-RPC comme une plateforme d‟implémentation.
Figure 100–Métamodèle JAX-RPC
Les éléments principaux du métamodèle JAX-RPC sont :
JaxRpcElement – cet élément du métamodèle est une généralisation des autres
éléments tels que JaxRpcPackageElement, JavaMember et JavaParameter.
JaxRpcPackageElement – cet élément du métamodèle est une généralisation
de JaxrpcPackage et jaxrpcClassifier.
JaxrpcPackage –Cet élément du métamodèle est un conteneur des classes
(jaxrpcClass) et des interfaces java (Interface). Il permet de définir les
packages qui peuvent contenir des éléments JaxrpcElement.
jaxrpcClassifier- Cet élément du métamodèle est la base des éléments
JavaPrimitiveType, JavaClass et Interface.

159 VSoaMLTool : Outil de génération de code automatique
JavaPrimitiveType - Cet élément du métamodèle définit les types primitives
qui sont utilises pour l‟élaboration des modèles. Il peut être Byte, Short,
Boolean, String, integer, etc
jaxrpcClass –cet élément du métamodèle est une spécialisation de
JavaClassifier qui posséde JavaField et JavaMethod comme membres.
Chaque jaxrpcClass implémente une ou plusieurs interfaces (Interface).
Interface –cet élément du métamodèle est une spécialisation de JavaClassifier
qui possède les prototypes d‟un ensemble de méthodes java (JavaMethod).
JavaMember – cet élément du métamodèle définit les membres de chaque
classe (jaxrpcClass) et notamment ses champs et ses méthodes. Il étend
l‟élément JaxrpcElement et il est associé à l‟élément jaxrpcClass pour
spécifier la classe à laquelle appartient javaMember et pour spécifier son type.
JavaMethod – Cet élément du métamodèle permet la définition des méthodes.
Il étend l‟élément ClassMember. Il est associé à JavaParameter pour la
définition des paramètres de chaque méthode.
javaParameter – cet élément du métamodèle permet la définition des
paramètres d‟une méthode donnée. Cet élément étend l‟élément JaxrpcElement.
JavaParameter est associé à JavarpcClass et JavaMethod pour spécifier le type
d‟un paramètre d‟une méthode donnée et définir la méthode à laquelle le
paramètre appartient.
javaField – Cet élément du métamodèle étend ClassMember. Il permet la
définition des champs d‟une classe donnée.
IV.7.2. Spécification des correspondances entre le métamodèle de
VSoaML et le métamodèle JAX-RPC
La transformation de modèles nécessite la détermination des équivalences entre le métamodèle
source et le métamodèle cible. Le tableau 11 illustre les correspondances entre le métamodèle du
service multivues aux éléments du métmodéle JAX-RPC. Cette correspondance (mapping) est
réalisée grâce à un ensemble des règles de transformation qui spécifient les éléments du
métamodèle source qui sont équivalents aux éléments du métamodèle cible. Dans cette table, la
premiere colonne contient les éléments du métamodèle source. La deuxième colonne présente
leurs équivalents du métamodèle JAX-RPC. La troisième colonne contient les règles de

160 VSoaMLTool : Outil de génération de code automatique
transformations associées. Ces règles permettent l‟implémentation des transformations des
éléments du métamodèle cible vers le métamodèle cible.
Les éléments du
métamodèle VSoaML
Les éléments du métamodèle La régle de transformation
JAX-RPC
ServiceDomain JaxRpcPackage Partition2Package
MVService JaxrpcClass MVService 2jaxrpcClass
BaseServiceInterface Interface binterface2Interface
ViewServiceInterface Interface Viewinterface2interface
Parameter JavaParameter Param2part
ServiceOperation Method Operation2Method
dataType Types Data2Primitive
Tableau 11–Spécification des correspondances VSoaML/JAX-RPC
IV.7.3.
Les règles de transformation
La spécification des correspondances permet la détermination des équivalences entre les éléments
du métamodèle source et cible. La deuxième étape dans le processus de transformation consiste
en la définition des transformations en se basant sur les règles de transformation en utilisant le
langage ATL pour pouvoir réaliser les correspondances (mapping) entre le métamodèle de
VSoaML et le métamodèle JAX-RPC.
Comme illustré dans le tableau 11, nous avons défini plusieurs règles pour la transformation des
modèles. Le but de cette section est de présenter les principales règles de transformation définies.
La règle Domain2Package, comme illustre la figure 101, permet la création des instances
Package comme une instance du métamodèle JAX-RPC à partir de l‟élément Namespace du
métamodèle du service multivues. En conséquence, les caractéristiques de chaque élément cible

161 VSoaMLTool : Outil de génération de code automatique
sont affectés avec les caractéristiques de l‟élément ServiceDomain. Ainsi, le nom du package est
affecté avec la valeur e.name (le nom de namespace).
rule Domain2Package
{
from d: VSoaML!ServiceDomain
to p: jaxrpc!JaxrpcPackage(
name

162 VSoaMLTool : Outil de génération de code automatique
rule Operation2Method {
from e : MVService!Operation
to out : jaxrpc!JavaMethod (
name first().type,
parameters select(x|x.kind'OUT')
->asSequence()->collect(p|thisModule.MyP2F(p)) )
}
Figure 103–Règle de transformation Operation2Method
La règle viewinterface2interface et la règle baseinterface2interface permettent la création des
instances interface en affectant les caractéristiques de baseinterface et viewinterface. La figure
104 illustre la règle viewinterafce2interface.
rule viewinterface2interface {
from d: MVService!viewInterface
to out:jaxrpc!Interface (
name

163 VSoaMLTool : Outil de génération de code automatique
query jaxrpcquery = jaxrpc!JavaClass.allInstances()->
collect(x | x.toString().writeTo('C:/Codesource/' + x.package.name.replaceAll('.', '/') + '/' + x.name + '.java'));
uses jaxrpc2code;
Figure 105–Requête de génération de code Java
La figure 105 contient la requête utilisée pour déclencher la transformation modèle-code.
L‟opération allInstances() retourne une collection constituée de toutes les instances de l‟élément
jaxrpc!JavaClass présentes dans le modèle Java. Ensuite, une opération sur les collections appelé
collect() nous permet de récupérer chaque élément de cette collection (représenté par x) et
d‟appeler l‟opération toString() sur chacun d‟eux. Cette opération est un helper en ATL défini
dans la bibliothèque jaxrpc2code Après l‟exécution de cet helper, la chaîne de caractères est
écrite dans un fichier « *.java » par le biais de l‟opération writeTo(). L‟helper toString() défini
dans le contexte de jaxrpc!JaxrpcClass et de jaxrpc!Interface enchaîne aussi d‟autres appels à
d‟autres helpers définis dans le contexte de JavaField, JavaParameter, et ainsi de suite.

164 VSoaMLTool : Outil de génération de code automatique
helper context jaxrpc!JaxrpcPackage def: toString() : String =
self.contents ->iterate(i; acc : String = '' |
acc + i.name +'.java\n' );
helper context jaxrpc!Interface def : getmethods() : Set(
jaxrpc1!JavaMethod)=
self.javamethod->asSet()
;
helper context jaxrpc!JaxrpcClass def: toString() :
String =
'package ' + self.packagerpc.name + ';\n\n'+
'\npublic class ' + self.name + ' implements '+
self.interfaces ->iterate ( i ; acc: String ='' | acc + i.name + ',')
+'{\n'+
self.interfaces->collect ( e| e.javamember) -> iterate ( i; acc: Sequence
(jaxrpc1!JavaMethod)= Sequence{}| acc ->union( i))
->iterate(i; acc : String = '' |
acc + i.toString()+ ' {\n\t //[Implementation Code to beCompleted]\n}' )
+ '\n}';
helper context jaxrpc!Interface def: toString() : String=
'package ' + self.packagerpc.name + ';\n\n'+
'\nimport java.rmi.Remote;'+
'\nimport java.rmi.RemoteException;\n'+
'\npublic interface ' + self.name + ' extends Remote {\n' +
self.javamember->iterate(i; acc : String = '' |
acc + i.toString()+'throws RemoteException;'
)+ '\n}';
helper context jaxrpc!JavaPrimitiveType def: toString() : String =
if self.name = 'Integer' then 'int '
else if self.name = 'Boolean' then 'boolean '
else if self.name = 'String' then 'java.lang.String '
else if self.name = 'Long' then 'long '
else 'void '
endif endif endif endif;
helper context jaxrpc!JavaField def: toString() : String =
self.type.name + ' ' + self.name + ';\n';
helper context jaxrpc!JavaMethod def: toString() : String =
'\npublic '+ self.istypeof.name + ' ' + self.name + '(' +
self.parameters->iterate(i; acc : String = '' |
acc +
if acc = '' then ''
else ', '
endif + i.toString() ) +')';
helper context jaxrpc!JavaParameter def: toString() : String =
self.istypeof.name + ' ' + self.name;
Figure 106–Code ATL pour la génération de code java
La figure 107 illustre le code généré de la classe implémentant le service multivues Course avec

165 VSoaMLTool : Outil de génération de code automatique
import java.rmi.Remote;
import java.rmi.RemoteException;
public interface Course_Teacher extends Remote {
public Integer addExerciseSolution(Integer ExerciseId, String
ExerciseSolution)throws RemoteException;
public Integer addExercice(Integer exerciseID, String Exercise)throws
RemoteException;
}
package DLS;
import java.rmi.Remote;
import java.rmi.RemoteException;
public interface Course_Student extends Remote {
public String postMessageForum(String Course, String message)throws
RemoteException;
public Integer ProposeExerciseSolution(Integer ExerciseId, String
Solution)throws RemoteException;
}
package DLS;
import java.rmi.Remote;
import java.rmi.RemoteException;
public interface Course_base extends Remote {
public String consultCourseList(String level)throws RemoteException;
public String consultSynopsisCourse(String Course)throws RemoteException;
}
package DLS;
public class Course implements Course_Teacher,Course_Student,Course_base,{
public Integer addExerciseSolution(Integer ExerciseId, String
ExerciseSolution) {
//[Implementation Code to beCompleted]
}
public Integer addExercice(Integer exerciseID, String Exercise) {
//[Implementation Code to beCompleted]
}
public String postMessageForum(String Course, String message) {
//[Implementation Code to beCompleted]
}
public Integer ProposeExerciseSolution(Integer ExerciseId, String Solution)
{
//[Implementation Code to beCompleted]
}
public String consultCourseList(String level) {
//[Implementation Code to beCompleted]
}
public String consultSynopsisCourse(String Course) {
//[Implementation Code to beCompleted]
}
}
Figure 107–Code java généré à partir du PIM(VSoaML)
une interface de service multivues se composant d‟une interface de service de base et de deux
interfaces de service vues associées respectivement à l‟acteur Etudiant et l‟acteur Enseignant.

166 VSoaMLTool : Outil de génération de code automatique
L‟interface de service de base se compose des opérations : String consultSynopsisCourse (Course
: String) et String consultCourseList (level :String). L‟interface associée à l‟acteur Enseignant
contient les opérations suivantes : String addExercice (exerciseID : integer, Exercise : String) et
String addExerciseSolution (ExerciseId : integer, ExerciseSolution : String). L‟interface associée
à l‟acteur Etudiant contient les opérations : String postMessageForum (Course: String, message :
String) et String ProposeExerciseSolution (ExerciseId : integer, Solution : String).
le code généré correspond à l'interface de service de base Course_base , à l'interface associé à
l'acteur Etudiant (Course_Student), à l'interface associée à l'acteur Enseignant ainsi que classe
(class Course ) qui doit implémenter toutes les interfaces et leurs méthodes.
IV.8. VSoaMLTool : déploiement selon l’architecture SOA
L‟architecture orientée service (SOA) définit principalement trois acteurs et trois opérations :
le fournisseur de service qui possède l‟implémentation de service et la description du service
publie (l‟opération) cette dernière dans l’annuaire des services. L‟annuaire de
service permet par ailleurs à un client de service de trouver les services correspondant à ses
besoins (l‟opération) et de les invoquer en leur transmettant les données métiers
requises (l‟opération ). Une telle architecture ne prend pas en compte le profil de
l‟utilisateur interagissant avec le service. Pour répondre à cette limite, nous avons introduit le
concept de service multivues pour la prise en compte des profils des utilisateurs. Ensuite, nous
avons généré pour chaque service multivues une description suivant le format MVWSDL comme
nous l‟avons expliqué dans les précédentes sections.
Les documents MVWSDL générés, contiennent la description des interfaces de service multivues
ainsi que les informations concernant les acteurs qui vont interagir avec le service multivues. A
partir des documents MVWSDL, nous devons extraire une description standard WSDL
spécifique à chaque acteur interagissant avec le service. Dans cet objectif, nous avons développé
un module logiciel intégré à l‟outil VSoaMLTool (Kenzi et al., 2008d)(El Asri, Kenzi et al.,
2009). Ce module logiciel prend en entrée un document MVWSDL et produit en sortie une
description WSDL standard spécifique à l‟acteur qui va interagir avec le service multivues. Pour
ce faire, le module de déploiement de l‟outil VSoaMLTool se base sur la valeur de l‟attribut actor
intégré aux éléments principaux du WSDL : Types, PortType, Binding et Service. Ce module

VSOAMLTOOL(MODULE DE DEPLOIEMENT)
167 VSoaMLTool : Outil de génération de code automatique
PIM(VSoaML)
Service metadata
VSoaMLTool
(transformer module)
WSDL
Acteur S1,1
WSDL
S1
MVWSDL
WSDL
Acteur S1,J
Acteur S1,S1max
Acteur S1,1 Acteur S1,J
Acteur S1,S1max
WSDL
S2
MVWSDL
WSDL
Acteur S2,1
WSDL
Acteur S2,J
Acteur S2,1 Acteur S2,J
Acteur S2,S2max
Acteur S2,S2max
SN
MVWSDL
WSDL
Acteur SN,1
Acteur SN,1 Acteur SN,J
Acteur
SN,SNmax
WSDL
Légende
WSDL
Acteur SN,J
input
output
publish
Acteur SN,S1max
Figure 108–Architecture de déploiement des services multivues

168 VSoaMLTool : Outil de génération de code automatique
logiciel est développé en utilisant l’API DOM qui fournit un ensemble de classes et d‟interfaces
dédiées spécifiquement à la manipulation des documents XML tels que MVWSDL.
Concrètement, et dans le cadre de notre cas d‟étude, le MVWSDL généré représente toutes les
interfaces du service multivues associées à tous les acteurs interagissant avec le service :
Etudiant, Enseignant, Administrateur. Si un client de service de type Etudiant, Enseignant ou
Administrateur interagit avec le service multivues, il n‟obtient que la description WSDL qui
correspond à ses besoins qui n‟intègre pas les descriptions des interfaces associées aux autres
acteurs. La figue 108 illustre le rôle du module de déploiement de l‟outil de VSoaMLTool.
IV.9. Conclusion
L‟adaptabilité est l‟une des qualités reines pour le développement de tout système informatique.
Dans cette optique, nous avons proposé une approche d‟ingénierie dirigée par les modèles des
systèmes orientés services adaptables aux différents types d‟utilisateurs.
Ainsi, nous avons proposé dans le deuxieme chapitre, un profil UML pour la modélisation des
SOS adaptables. Dans le troisiéme chapitre, nous avons proposé un processus pour le
développement des SOS adaptables. Dans ce chapitre, nous avons présenté l‟outil VSoaMLTool
en montrant ses fonctionnalités tout en se focalisant sur les transformations de modèles et de la
génération du code. Ainsi, nous avons défini, en premier lieu, un PIM en se basant sur le profil
VSoaML qui vise la modélisation d‟un système orienté service tout en identifiant les besoins et
les spécificités des différents acteurs interagissant avec les services. Ensuite, nous avons défini
des transformations ciblant différentes plateformes technologiques (e.g., J2EE, dotNet) et la
plateforme services web et notamment notre extension du standard WSDL. Ces transformations
permettent la génération du code à partir des PIMs. En particulier, la description de chaque
service ainsi que leurs implémentation en java et C#. Chaque transformation est effectuée en
deux étapes : une étape de spécification de correspondances et une étape de définition de
transformation en se basant sur un langage de transformation de modèle à savoir le langage ATL.
L‟approche que nous avons proposée durant les trois derniers chapitres, présente un ensemble
d‟avantages en répondant à la problématique de l‟ingénierie des SOSs adaptable et ouvre un
ensemble de perspectives décrite dans le chapitre suivant « conclusion générale ».

169 Conclusion générale et perspectives
Conclusion générale et perspectives
Dans le cadre de cette thèse, nous avons proposé une approche d‟ingénierie des systèmes orientés
services adaptables aux différents types d‟utilisateurs. Cette approche se base principalement sur :
(i) un profil UML (VSoaML) pour la modélisation des systèmes orientés services adaptables aux
différents types d‟utilisateurs (ii) Un processus de développement des systèmes orientés services
adaptables dans le cadre de l‟approche MDA et (iii) un outil logiciel permettant la génération du
code à partir des modèles métiers de haut niveau exprimés avec le profil VSoaML. Cet outil
logiciel se base sur un ensemble de règles de transformations implémentées en utilisant le
langage ATL.
L‟objectif principal de VSoaML est la spécification des systèmes orientés services adaptables aux
différents types d‟utilisateurs indépendamment des plates-formes d‟implémentation (J2EE,
dotNet, etc) et des standards de la technologie des services web (SOAP, WSDL, UDDI,
BPEL4WS, etc.). VSoaML est centré utilisateur et se base fondamentalement sur le concept de
service multivues comme une entité de modélisation de première classe capable de représenter les
besoins et les spécificités des utilisateurs suivant leurs profils. Le service multivues est une
nouvelle entité de modélisation qui fournit/requiert des interfaces qui se caractérisent par leur
flexibilité et adaptabilité aux différents acteurs interagissant avec le service. Ainsi, le service
multivues permet la capture des exigences des utilisateurs et de leurs spécificités tout en séparant
leurs préoccupations fonctionnelles suivant le profil de l‟utilisateur interagissant avec le service.
Parallèlement à la proposition du Profil VSoaML, nous avons défini un processus de
développement dans le cadre de l‟approche MDA pour identifier les services multivues, les
spécifier et les développer. Ce processus définit les phases, les activités et les artefacts permettant
de transformer les exigences métier en termes d‟un ensemble de service flexibles et adaptables.
La spécificité d‟un tel processus est l‟identification des services en partant des modèles des cas
d‟utilisation métiers. Ce processus de développement qui s‟inscrit dans le cadre de l‟approche
MDA, permet l‟élaboration des modèles et de gérer la transition d‟un modèle à un autre via des
transformations de modèles. Ainsi, après l‟élaboration des modèles métiers à base de service
multivues, nous avons défini deux transformations pour la génération de code :

170 Conclusion générale et perspectives
La première transformation permet la génération de la description de chaque service multivues
composant le PIM d‟un système donné. En effet, nous avons défini une légère extension du
standard WSDL pour la description de service multivues appelé MVWDL. Cette extension de
WSDL permet la représentation en XML aussi bien des interfaces des services que les
informations concernant les acteurs interagissant avec le service. Pour permettre l‟automatisation
de la génération du code MVWSDL, nous avons défini un ensemble de règles de transformation
en utilisant le langage ATL comme langage de transformation de modèles.
La deuxiéme transformation concerne la génération de code constituant l‟implémentation de
chaque service multivues selon la plateforme cible J2EE.
Chaque transformation de modèles a été effectuée en deux étapes : la première concerne la
spécification de correspondances. La deuxième étape a pour objectif la définition de
transformations en se basant sur le langage de transformation de modèle ATL.
Une fois générées la description de chaque service multivues et son implémentation, nous avons
illustré comment faire l‟adaptation des services en prenant en compte les acteurs interagissant
avec le service suivant l‟architecture SOA.
Travaux en cours et futurs :
L‟approche que nous avons proposée pour l‟ingénierie des systèmes orientés services adaptables,
demande à être développée en plusieurs points. En premier lieu, nous visons d‟inclure d‟autres
caractéristiques de l‟utilisateur surtout dans le cadre de l‟Informatique Sensible au Contexte. En
deuxième lieu, nous projetons de générer la totalité du code pour concrétiser vraiment la vision
MDA. En toisiéme lieu, nous projetons à moyen terme d‟associer à notre approche une base
mathématique solide. Enfin, nous visons à transposer l‟approche pour l‟ingénierie des
applications «Cloud computing»
L’adaptation des services en prenant en considération d‟autres paramètres du contexte : Dans le
cadre de cette thèse, nous nous sommes concentrés tout particulièrement sur l‟adaptation des
services au rôle de l‟utilisateur. Cependant, il est possible d‟adapter les services en tenant compte
d‟autres caractéristiques du contexte en continuité avec nos travaux de recherche dans le domaine
(Kenzi et al., 2007). En effet, l‟informatique sensible au contexte exige l‟adaptation des systèmes

171 Conclusion générale et perspectives
logiciels selon plusieurs dimensions. Globalement, le contexte comprend les caractéristiques liées
à l‟utilisateur, à sa localisation, à son dispositif d‟accès ou même au contexte des différents
services composant le système (Maamar et al., 2006b).
La génération totale du code : Nous avons adopté une approche de génération de «grosse
granularité» qui vise la génération du squelette des différents services suivant une plateforme
technologique. Comme perspective de cette thèse et l‟un de nos objectifs à court terme est de
permettre la génération de code à granularité fine c'est-à-dire la génération du code des méthodes
de chaque service via l‟utilisation des « actions semantics ».
La formalisation de l’adaptation des services : Dans le domaine du SOC, plusieurs approches
ont été proposées visant la définition d‟une base mathématique solide pour traiter les différents
aspects d‟un SOS (statiques et dynamiques). Dans cette optique, plusieurs techniques ont été
utilisées (i) la théorie des graphes (Yu et al., 2008) (Baresi et al., 2006) pour la gestion des
aspects dynamiques d‟un SOS ou la définition d‟un système de gestion de services à l‟instar d‟un
système de gestion de base de données dans les cas des données(ii) les réseaux de Petri en vue
de gérer les différentes préoccupations liées aux SOS (iii) les machines à états finis (Tao et al.,
2007) pour la formalisation de l‟adaptation des services. Ainsi, nous envisageons comme
perspective de ce travail, d‟utiliser certaines des techniques précitées (Réseaux de Pétri, théorie
de graphe, les machines à états finis) pour la formalisation de notre approche. Plus
particulièrement, nous comptons utiliser la théorie des graphes comme une technique puissante et
prometteuse pour la formalisation des aspects dynamiques d‟un système orienté service
adaptable.
L’ingénierie des Systémes « Cloud Computing » : l‟approche définie dans le cadre de cette
thése, vise la définition d‟une approche d‟ingénierie des SOSs adaptables dans le cadre du
paradigme SOC. Cependant ce paradigme évolue vers un nouveau paradigme à savoir le Cloud
Computing qui se base sur trois concepts : « Software as Service », « Infrastructure as Service »
et « Platform as Service ». Ainsi, nous visons à transposer notre approche d‟ingénierie des SOSs
pour le développement des systémes « Cloud Computing».

172 Liste des publications
Liste des publications
Cette section regroupe par ordre chronologique inverse, les publications que nous avons produites
pendant cette thèse
1) Adil Kenzi, Bouchra El Asri, Mahmoud Nassar, Abdelaziz Kriouile., «Engineering
Adaptable Service Oriented Systems: A Model Driven approach”, IEEE International
Conference on Service-Oriented Computing and Applications (SOCA'09), pages 9-16,
Taipei, Taiwan, 14-15 December 2009, IEEE Computer Society Press..
2) Adil Kenzi, Bouchra El Asri, Mahmoud Nassar, Abdelaziz Kriouile, "A model driven
framework for multiview service oriented system development," 2009 IEEE/ACS
International Conference on Computer Systems and Applications(AICCSA09), pages 404
– 411, Rabat, Maroc, 10-13 May 2009, IEEE Computer Society Press.
3) Bouchra El Asri, Adil Kenzi, M. Nassar, A. Kriouile. Multiview Components for User-
Aware Web Services, in Joaquim Filipe, José Cordeiro, Editors, Enterprise Information
Systems, Volume 24, pages 196-207, LNBIP, Springer, 2009.
4) Bouchra El Asri, Adil Kenzi, Mahmoud Nassar, Abdelaziz Kriouile., “Vers une
architecture MVSOA pour la mise en œuvre des composants multivue.», Conférence
Francophone sur les Architectures Logicielles (CAL 09), pages 1-16, Nancy, 2009,
Editions Cépaduès, RNTI.
5) Adil Kenzi, Bouchra El Asri, Mahmoud Nassar, Abdelaziz Kriouile, "The Multiview
Service: A New Concept for the Development of Adaptable Service Oriented Systems",
2008 IEEE International Symposium on Service-Oriented System Engineering
(SOSE‟08), Jhongli, Taiwan, 18-19 December 2008, pages 38-43, IEEE Computer
Society Press.
6) Adil Kenzi, B. El Asri, M. Nassar, A. Kriouile, SOA vs MVSOA : Une architecture
orientée services multivues, Colloque Africain sur la Recherche en Informatique et en
Mathématiques Appliquées (CARI‟08), pages 585-592, Rabat, 27-30 Octobre 2008.
7) Adil Kenzi, B. El Asri, M. Nassar, A. Kriouile, Vers une approche orientée modèle pour
l’adaptation des services aux profils des utilisateurs, Proceedings of the 10th Conference
on Software Engineering and Artificial Intelligence–Maghrebian Conference on
Information Technologies (MCSEAI‟08), 6 pages IEEE, Oran, Algérie, 28 - 30 Avril
2008.

173 Liste des publications
8) Adil Kenzi, B. El Asri, M. Nassar, A. Kriouile, Multi-functional service oriented system
development for user-driven adaptability, Proceedings of the 3 rd International
Conference on Information & Communication Technologies: from Theory to
Applications (ICTTA‟08), Pages 1431-1437, Damascus, Syria, April 7 - 11, 2008, IEEE.
9) Adil Kenzi, Bouchra El Asri, Mahmoud Nassar, Abdelaziz Kriouile, “Modeling Multi-
Functional services: A User Driven Approach for dynamic accessibility”, accepté mais
non inscrit à la conférence ICEIS 2008.
10) Adil Kenzi, Bouchra El Asri, Mahmoud Nassar, Abdelaziz Kriouile , “ A model driven
approach for the development of adaptable service oriented systems”, accépté mais non
inscrit à la conférence 10th International Conference on Information Integration and
Web-based Applications & Services (iiWAS2008), 24-26 November 2008, Linz, Austria
11) Adil Kenzi, Bouchra El Asri, Mahmoud Nassar, Abdelaziz Kriouile, “ Des composants
multivues aux services web : une approche dirigée par les modèles”, 2ème Journées
d'informatique et de mathématiques décisionnelles (JIMD'2008), Rabat, 3-5 Juillet, 2008.
12) Adil Kenzi, B. El Asri, M. Nassar, A. Kriouile, Vers des services multivues contextuels,
Actes du 1er Workshop International sur «Informatique Mobile et Applications»
(WMCA‟2007), En parallèle avec NOTERE 2007 (Nouvelles TEchnologies de la
REpartition), pages 129-135, Marrakech, 4-8 Juin 2007.
13) Adil Kenzi, Bouchra El Asri, Mahmoud Nassar, Abdelaziz Kriouile, « Modélisation
orientée service multivues des systèmes », WorkShop sur les Technologies de l'Information
et de la Communication (Wotic‟07), 5-6 Juillet, Rabat.

174 Références
Références
[Abiteboul et al. 1991] Abiteboul S., Bonner A., “Objects and Views”, Proc. of ACM
SIGMOD, 1991, pp. 238-24.
[anwar, 2009] Anwar A, Formalisation par une approche IDM de la composition de modèles
dans le profil VUML. Thèse de doctorat, Université de Toulouse-le-Mirail, décembre 2009.
[Alam et al., 2007a] Alam M., Seifert J.P., Zhang X., “A Model-Driven Framework
for Trusted Computing Based Systems”, EDOC 2007: 75-86
[Alam et al., 2007b] Alam M., Breu R., Hafner M.,: Model-Driven Security
Engineering for Trust Management in SECTET. JSW 2(1): 47-59 (2007)
[Alam et al., 2008] Alam M., Hafner M., Breu R.,: Constraint based role based access
control in the SECTET-frameworkA model-driven approach. Journal of Computer
Security 16(2): 223-260 (2008)
[Amir et al., 2004] Amir R., Zeid A.: A UML profile for service oriented
architectures. OOPSLA Companion 2004: 192-193
[Andrews et al., 2003] Andrews T., Business process execution language for Web
services, Version 1.1, (2003).
[Arsanjani et al., 2005] Arsanjani A., Service-oriented modeling and architecture
(SOMA). http://www128.ibm.com/developerworks/webservices/library/ws-soadesign1
[ATL, 2004] ATL. ATL Development Tools. INRIA, LINA et Université de Nantes,
december 2004. Disponible sur http://www.sciences.univ-nantes.fr/lina/atl/,
[Baina et al., 2004] Baïna, K., Benatallah, B. Casati, F, Toumani, F.. Model-Driven
Web Service Development. Proc. of CAiSE‟04, Riga, Latvia, June 2004.
[Baresi et al., 2006] Baresi, L., Heckel, R., Thone, S., Varro, D.: Style-based modeling
and refinement of service-oriented architectures. Software and System
Modeling(2006) 187-207
[Benatallah et al., 2009] Benatallah, B., Casati, F., Kongdenfha, W., Skogsrud,
H.,Toumani, F., “Conceptual Modeling of Service-Driven Applications”,In Service
Oriented Computing, M.Papazoglou and Dimitrios Georgakopoulos, Eds.,: MIT press,
2009 , pp.29-50.
[Benslimane et al., 2005] Benslimane D., Maamar Z., Ghedira C., A View-based
Approach for Tracking Composite Web Services. ECOWS 2005: 170-181
[Bezivin et al., 2004] Bézivin J., Hammoudi S., Lopes, Jouault F., Applying MDA
approach for web service platform. Proc of the 8th IEEE International Enterprise
Distributed Object Computing conference (EDOC 2004).

175 Références
[Biesiegel et al., 2005] Beisiegel M., Blohm H., Booz D.,et al., Service Component
Architecture. Building Systems using a Service Oriented Architecture.
http://download.boulder.ibm.com/ibmdl/pub/software/dw/specs/wssca/SCA_White_Paper1_09.pdf,
November 2005
[Blanc, 2005] Blanc X., MDA en action, Edition Eyrolles, 2005.
[Bordbar et al., 2004] BORDBAR B., STAIKOPOULOS A., Automated Generation
of Metamodels for Web Service Languages. Second European Workshop on Model
Driven Architecture (MDA) with an emphasis on Methodologies and Transformations
(EWMDA), September 2004.
[Bouguettaya et al.,, 2009] Bouguettaya, A., Yang, X.,“Access to Mobile Services”,
Springer, 2009.
[Chang et al., 2006] Chang M., He J., Tsai, W. T., Xiao B., Chen Y., : UCSOA: User-
Centric Service-Oriented Architecture. IEEE International Conference on e-Business
Engineering (ICEBE 2006), 248-255
[Chang et al., 2007a] Chang S.H, Kim S. D. , A Comprehensive Approach to
Service Adaptation, IEEE International Conference on Services Oriented Computing
and Applications (SOCA 2007), 2007
[Chang et al., 2007b] Chang S.H, Kim S. D., A Service-Oriented Analysis and
Design Approach to Developing Adaptable Services, pp. 204-211, IEEE International
Conference on Services Computing (SCC 2007), 2007
[Chebbi et al., 2006] Chebbi I., Dustdar S., Tata S., The view-based approach to
dynamic inter-organizational workflow cooperation. Data Knowl. Eng. 56(2): 139-173
(2006)
[Chinnici et al., 2001] Chinnici R., Gudgin M.,Moreau J.-J., Schlimmer
J.,Weerrawarana S., Web Services Description Language (WSDL) version 2.0 Part 1 :
Core language, W3C
[Clement et al., 2004] Clement L., Hately A., Riegen C., Rogers T., UDDI version
3.0.2 spécifications, Technical Commitee Draft, Octobre, 2004,
http://uddi.org/pubs/uddi_v3.htm
[Coulette et al., 1996]Coulette B., Kriouile A., Marcaillou S., "L‟approche par points
de vue dans le développement orienté objet des systèmes complexes", Revue l‟Objet,
vol. 2, n°4, février 1996, pp. 13-20.
[D‟Ambrogio et al., 2006] D'Ambrogio, A., A Model-driven WSDL Extension for
Describing the QoS of Web Services. IEEE International Conference on Web Services
(ICWS 2006), 18-22 September 2006 pages:789-796
[Dey et al.,, 2000] Dey, A.K., Abowd, G.D. Towards a Better Understanding of
Context and Context-Awareness. In: Procs of the Conference on Human Factors in
Computing Systems (CHI‟2000), Workshop on the What, Who, Where, When, and
How of Context-Awareness, April 2000, The Hague, The Netherlands.

176 Références
[Eclipse, 2010] ECLIPSE TOOLS PROJECT. Eclipse Modeling Framework (EMF)
version 2.0, June 2010. Disponible sur http://www.eclipse.org/emf,
[El Asri et al., 2005a] El Asri B., "Vers des composants multivues distribués", Thèse
nationale à l‟ENSIAS de Rabat, octobre 2005.
[El Asri et al., 2005c] El Asri B., Nassar M., Coulette B., Kriouile A., "MultiViews
component for information development", Proceedings of the 7th International
Conference on Enterprise Information Systems (ICEIS‟2005), Miami, USA, May 24-
28, 2005b. pp. 217-225.
[El Asri et al., 2009a] El Asri B., Kenzi A., Nassar M., Kriouile A., Multiview
Components for User-Aware Web Services, Proceedings of the 11th International
Conference on Enterprise Information Systems (ICEIS‟09), 6 - 10 May 2009, Milan,
Italy. (Accepted as full paper and published as a book chapter in "Enterprise
Information Systems vol.24", J. Filipe, J. Cordeiro, and J. Cardoso Eds., Springer-
Verlag.
[El Asri et al.,2009b] El Asri B., Kenzi A., Nassar M., Kriouile A., “Vers une
architecture MVSOA pour la mise en oeuvre des composants multivue.», Conférence
Francophone sur les Architectures Logicielles (CAL 09), Nancy, 2009.
[Ermagan et al., 2007] Ermagan V., Krüger I.H., : A UML2 Profile for Service
Modeling. MoDELS 2007: 360-374
[Erradi et al., 2006] Erradi A., Anand S., Kulkarni, N., SOAF: An Architectural
Framework for Service Definition and Realization. IEEE International Conference on
Services Computing 2006: 151-158
[Farrel et al., 2007] Farrell J., Lausen, H. "Semantic Annotations for WSDL and
XML Schema", W3C Candidate Recommendation 26 January 2007;
http://www.w3.org/TR/sawsdl/.
[Fink et al., 2003] Fink T, Manuel Koch, Cristian Oancea: Specification and
Enforcement of Access Control in Heterogeneous Distributed Applications. ICWS-
Europe 2003: 88-100.
[Fuchs, 2004] Fuchs M, Adapting Web Services in a Heterogeneous Environment,
Proc of the IEEE International Conference on Web Services (ICWS'04), 2004: 656-
664
[Gerber et al., 2002] Gerber A., Lawley M., Raymond, K., Steel, J., and Wood, A.,
Transformation: The Missing Link of MDA. First International Conference on Graph
Transformation (ICGT2002), October 2002.
[Ghedira et al., 2005] Ghedira, C., Mezni, H.: Through Personalized Web Service
Composition Specification: From BPEL to C-BPEL. Electr. Notes Theor. Comput.
Sci.(2006) 117-132

177 Références
[Gronmo et al., 2004a] GRONMO R., SKOGAN D., SOLHEIM I., OLDEVIK J.,
Model-Driven Web Services Development. 2004 IEEE International Conference on e-
Technology, e-Commerce and e-Service (EEE‟04), pages 42–45, March 2004.
[Gronmo et al., 2004b] Gronmo R., Stogan D., Solheim I., Oldevik J., Model Driven
web services Development. Int Journal Web services Res 1(4) : 1-13(2004).
[Gustavo et al., 2003] Gustavo A., Fabio C., Harumi K., Vijay M., “Web services:
concepts, architectures and applications”, Springer-Verlag, septembre 2003
[Hafner et al.,2009] Hafner, M., Breu, R., “Security Engineering for Service-Oriented
Architectures”, Springer, 2009.
[Hair et al., 1998] Hair A., El Asri B., Kriouile A, Coulette B., "Outil support de la
méthode VBOOM, Fonctionnalités Fusion et Génération du code", actes du 4ème
Colloque Africain sur la Recherche en Informatique (CARI‟98), Dakar (Sénégal), 12-
15 octobre 1998, pp. 497-508.
[Huhns et al., 2005] Huhns M., Singh P., Service-Oriented Computing: Key Concepts
and Principles. Journal of IEEE Internet Computing, 2005.
[IBM, 2002] IBM. IBM Video Central for e-business tutorial, Version 7.2, 2002.
http://www-106.ibm.com/developerworks/webservices/demos/videocentral/
[Ibrahim et al., 2006] Ibrahim D., Misic, V., B., Service Views: a Coherent View
Model of the SOA in the Enterprise. IEEE International Conference on Services
Computing 2006: 230-237
[Johnston et al.,, 2006] Johnston S. K., Brown A., “ A Model-Driven Development
Approach to Creating Service-Oriented Solutions”, ICSOC 2006: 624-636
[Kadima et al., 2005] Kadima H., MDA : Conception orientée objet guidée par les modèles,
Dunod, 2005
[Keidl et al.,, 2004] Keidl M., Kemper A., : Towards context-aware adaptable web
services. WWW (Alternate Track Papers & Posters) 2004: 55-65
[Kenzi et al., 2007] Kenzi A., El Asri B.,Nassar M., Kriouile A., Vers des services
multivues contextuels, Actes du 1er Workshop International sur « Informatique
Mobile et Applications» (WMCA‟2007), En parallèle avec NOTERE 2007 (Nouvelles
TEchnologies de la REpartition), Marrakech, 4-8 Juin 2007.
[Kenzi et al., 2008a] Kenzi A., El Asri B.,Nassar M., Kriouile A Vers une approche
orientée modèle pour l’adaptation des services aux profils des utilisateurs,
Proceedings of the 10th Conference on Software Engineering and Artificial
Intelligence – Maghrebian Conference on Information Technologies (MCSEAI‟08),
Oran, Algérie, 28 - 30 Avril 2008.
[Kenzi et al., 2008b] Kenzi A., El Asri B.,Nassar M., Kriouile A "The Multiview
Service: A New Concept for the Development of Adaptable Service Oriented Systems",
2008 IEEE International Symposium on Service-Oriented System Engineering, IEEE
Computer Society.
[Kenzi et al., 2008c] Kenzi A., El Asri B.,Nassar M., Kriouile A Multi-functional
service oriented system development for user-driven adaptability, Proceedings of the 3
rd International Conference on Information & Communication Technologies: from

178 Références
Theory to Applications (ICTTA‟08), April 7 - 11, 2008, Damascus, Syria, IEEE.
[Kenzi et al., 2008d] Kenzi A., El Asri B.,Nassar M., Kriouile A., : SOA vs MVSOA :
Une architecture orientée services multivues, Colloque Africain sur la Recherche en
Informatique et en Mathématiques Appliquées (CARI‟08), Rabat, 27-30 Octobre
2008.
[Kenzi et al., 2009a] Kenzi A., El Asri B.,Nassar M., Kriouile A, "A model driven
framework for multiview service oriented system development," 2009 IEEE/ACS
International Conference on Computer Systems and Applications, IEEE Computer
Society.
[Kenzi et al., 2009b] Kenzi A., El Asri B.,Nassar M., Kriouile A.: Engineering
Adaptable Service Oriented Systems: A Model Driven approach, IEEE International
Conference on Service-Oriented Computing and Applications (SOCA'09), Taipei,
Taiwan, IEEE Computer Society.
[Kiczales et al., 2001] Kiczales, G., Hilsdale, E., Hugunin, J., Kersten, M., Palm, J.,
Griswold, W.G.: An Overview of AspectJ. In ECOOP(2001) 327-353
[Kim et al., 2006] Kim Y., Yun Y.: An Approach to Modeling Service-Oriented
Development Process. IEEE SCC 2006: 273-276
[Kim et al., 2007] Kim Y., Doh K.G,: The Service Modeling Process Based on Use
Case Refactoring. BIS 2007: 108-120
[Kiss, 2007] Kiss, C. Composite Capability/Preference Profiles (CC/PP): Structure
and Vocabularies 2.0. W3C Working Draft [en ligne], 2007. Disponible sur :
.
[Klyne et al.,, 2004] Klyne, G., Carroll, J.J. Resource Description Framework (RDF):
Concepts and Abstract Syntax. W3C Recommendation [en ligne], 2004. Disponible
sur :.
[Koning et al., 2009] Koning, M., Sun, C., Sinnema, M., Avgeriou, P.: VxBPEL:
Supporting variability for Web services in BPEL. Information Software
Technology(2009) 258-269
[Kleppe et al., 2005] Kleppe, A., Warmer, J., Bast, W. MDA Explained: The Model
Driven Architecture: Practice and Promise. Addison-Wesley, 2005.
[Kouadri Mostefaoui et al., 2004] Kouadri Mostefaoui S., Hannes Gassert and Béat
Hirsbrunner, “Context Meets Web Services: Enhancing WSDL with Context-Aware
Features.” 1st International Workshop on Best Practices and Methodologies in
Service-Oriented Architectures: Paving the Way to Web-services Success, held in
conjunction with the OOPSLA'2004, Vancouver, British Columbia, Canada, 24 - 28
october 2004. pp. 1 - 14.
[Kriouile, 1995] Kriouile A., "VBOOM, une méthode orientée objet d‟analyse et de
conception par points de vue", thèse d‟Etat de l‟université Mohammed V de Rabat,
1995.
[Lopes et al., 2003] Lopes D., Hammoudi S., : Web Services in the Context of MDA.
ICWS 2003: 424-427

179 Références
[Lopes et al., 2005] Lopes D., Hammoudi S., Bézivin J., Jouault F.,: Generating
Transformation Definition from Mapping Specification: Application to Web Service
Platform. CAiSE 2005: 309-325
[Lopes, 2005] Lopes D., "Etude et applications de l‟approche MDA pour des platesfromes
de Service Web", Thèse de Doctorat en Informatique, LINA, Université de
Nantes, juillet 2005.
[López Sanz et al., 2007] López Sanz M., Acuña C.J, Cuesta C.E., Marcos E.:
UML Profile for the Platform Independent Modelling of Service-Oriented
Architectures. ECSA 2007: 304-307
[López Sanz et al., 2008] López Sanz M., Acuña C.J, Cuesta C.E., Marcos E.:
Defining Service-Oriented Software Architecture Models for a MDA-based
Development Process at the PIM level. WICSA 2008: 309-312
[Lopez-Velasco et al., 2005] Lopez-Velasco C., AWSDL: une extension de WSDL
pour des services Web adaptés. INFORSID 2005: 133-148
[Maamar et al., 2003] Maamar Z., Benatallah B., Mansoor W.: Service Chart
Diagrams - Description & Application. WWW (Alternate Paper Tracks),2003
[Maamar et al., 2005] Maamar, Z., Benslimane, D., Ghedira, C., Mrissa, M.: Views in
Composite Web Services. IEEE Internet Computing, (2005) , 79-84
[Maamar et al., 2006a] Maamar Z., Baïna K., Benslimane D., Narendra N.C.,
Chelbabi M.,: Towards a Contextual Model-Driven Development Approach for Web
Services. ICEIS (3) 2006: 78-85
[Maamar et al., 2006b] Maamar Z., Benslimane D, Narendra N., What can context do
for web services Commun. ACM 49(12): 98-103 (2006)
[Maamar et al., 2008] Maamar Z., Benslimane D., A Context-based and Policydriven
Method to design and develop Composite Web services, International Journal
of E-Business Research (IJEBR) 4(4), 2008.
[ Marschal et al., 2003] MARSCHALL F., BRAUN P., Model Transformations for
the MDA with BOTL. Proceedings of the Workshop on Model Driven Architecture:
Foundations and Applications, June 2003
[Mellor et al., 2004]Mellor S., Scott K., Uhl A., Weise D., MDA Distilled. Addison-
Wesley, 2004.
[Mitra et al., 2003] Mitra N., SOAP version 1.2 part 0: primer, W3C
Recommendation, juin, 2003.
[Nassar et al., 2003] Nassar M., Coulette, B., Crégut, X., Ebsersold, S., Kriouile, A.,
2003. Towards a View based Unified Modeling Language. Proc. of 5th International
Conference on Enterprise Information Systems (ICEIS‟2003), Angers, France.
[OMG, 2002a] OMG, Meta Object Facility (MOF) specification – version 1.4,
formal/01-11-02, April 2002.
[OMG, 2002b] OMG, XMI, XML Metadata Interchange (XMI), v1.2, OMG, 2002b.
[OMG, 2002c] OMG, CORBA Components, V3.0, formal/02-06-65, June 2002.

180 Références
[OMG, 2002d] OMG, UML Profile for Enterprise Distributed Object Computing
Specification, February 2002. OMG Adopted Specification ptc/02-02-05,
[OMG, 2003] http://www.omg.org/docs/formal/02-04-03.pdf
[OMG, 2005] Object Management Group, UML Profile for Modeling Quality of
Service and Fault Tolerance Characteristics and Mechanisms, Adopted Specification,
May 2005.
[OMG , 2005] Object Management Group, UML Profile for Schedulability,
Performance and Time Specification, v. 1.1, January 2005.
[OMG, 2009] Object Management Group, Service oriented architecture Modeling
Language (SoaML), http://www.omg.org/spec/SoaML, 2009
[OMG, 2003] Object Management Group, MDA Guide, version 1.0.1, June 2003.
[OMG, 2004] OMG. UML Profile for Enterprise Collaboration Architecture
Specification, OMG formal/04-02-05, February 2004.
[Ortiz et al., 2006a] Ortiz G., Hernández J.: Service-Oriented Model-Driven
Development: Filling the Extra-Functional Property Gap. ICSOC 2006: 471-476
[Ortiz et al., 2006b] Ortiz G., Hernández, J., Toward UML Profiles for Web Services
and their Extra-Functional Properties. IEEE International Conference on Web Services
( ICWS 2006) : 889-892
[Papazoglou et al., 2008] Papazoglou M.P., Paolo Traverso, Schahram Dustdar, Frank
Leymann: Service-Oriented Computing: a Research Roadmap. Int. J. Cooperative Inf.
Syst. 17(2): 223-255 (2008)
[Papazoglou et al., 2003] Papazoglou M. P., « Service Oriented Computing :
Concepts, characteristics and Directions », actes de la 4° conférence WISE`03, Rome,
10-12décembre 2003, Italie, IEEE Computer Society, p. 3-12.
[Papazoglou et al., 2006] Papazoglou M., P., van den Heuvel W., Service-oriented
design and development methodology. Int. J. Web Eng. Technol. 2(4): 412-442 (2006)
[Papazoglou et al., 2007a] Papazoglou M.P, Willem-Jan van den Heuvel: Service
oriented architectures: approaches, technologies and research issues. VLDB J. 16(3):
389-415 (2007)
[Papazoglou et al., 2007b] Papazoglou M.P. , “Web Services: Principles and
Technology”, Prentice hall, 2007
[Patrascoiu et al., 2004a] Patrascoiu O., "YATL: Yet Another Transformation
language", in Proceedings of the 1st European MDA Workshop MDA-IA, pp. 83-90,
January 2004.
[Patrascoiu et al., 2004b] Patrascoiu O., Mapping EDOC to Web service using YATL.
In Proceedings of the 8th IEEE International Enterprise Distributed Object Computing
Conference (EDOC‟04). IEEE Computer Society, pp. 286-297.
[Rafanelli et al., 2003] Rafanelli M., Multidimensional Databases: Problems and
Solutions Idea Group 2003.

181 Références
[Rolland et al., 2007] Rolland C., Kaabi R.S., Kraïem N.: On ISOA: Intentional
Services Oriented Architecture. CAiSE 2007: 158-172
[SINTEF, 2004] SINTEF. UML Model Transformation Tool (UMT), december 2004.
Disponible sur http://umtqvt. sourceforge.net,
[Sheng et al., 2005] Sheng, Q.Z., Benatallah, B.,ContextUML: A UML-Based
Modeling Language for Model-Driven Context-Aware Web Service Development,
Proc. of the 4th Intl. Conf. onMobile Business (ICMB'05), Sydney, Australia, July
(2005).
[SKOGAN et al., 2004] SKOGAN D., GRONMO R., SOLHEIM I., Web Service
Composition in UML. Eight IEEE International Enterprise Distributed Object
Computing Conference (EDOC 2004), pages 47–57, September 2004.
[Stojanovic et al., 2004] Stojanovic Z., Dahanayake A., Sol H., “Modeling and design
of Service Oriented Architecture”, IEEE International Conference on Systems, Man
and Cybernytics, 2004.
[SUN, 2004] SUN MICROSYSTEMS. JavaWeb Services Developer Pack, March
2004. Disponible sur http://java.sun.com/webservices,
[Szyperski,2002] Szyperski C.: Component Software - Beyond Object-Oriented
Programming. Addison-Wesley, 2 édition, novembre 2002.
[Tao et al., 2008] Tao A.T, Yang J.: Towards policy driven context aware
differentiated services design and development. Enterprise IS 2(4): 367-384 (2008)
[Tao et al., 2007a] Tao A.T, Yang J., : Context Aware Differentiated Services
Development with Configurable Business Processes. EDOC 2007: 241-252
[Tao et al., 2007b] Tao T.A.,Yang J., Supporting Differentiated Services With
Configurable Business Processes. Proc of the IEEE International Conference on Web
Services (ICWS'07), 2007.
[Torkaman et al., 2006] Torkaman Rahmani A., Rafe V., Sedighian S., Abbaspour A.:
An MDA-Based Modeling and Design of Service Oriented Architecture. International
Conference on Computational Science (3) 2006: 578-585
[Tsai et al., 2006] Tsai W.T., Malek M.,, Chen Y., Bastani F.B., : Perspectives on
Service-Oriented Computing and Service-Oriented System Engineering. SOSE 2006:
3-10
[W3C, 2004] Web Services Architecture.W3C disponible sur
http://www.w3.org/TR/ws-arch/, 2004.
[Wonohoesodo et al., 2004] Wonohoesodo R., Tari Z., A Role based Access Control
for Web Services. IEEE International Conference on Services Computing (SCC 2004),
2004
[Yu et al., 2007] Yu X., Zhang Y., Zhang T., Wang L., Hu J., Zhao J., Li X., A
model-driven development framework for enterprise Web services. Information
Systems Frontiers 9(4) : 391-409 ( 2007).

182 Références
[Yu et al., 2008] Yu Q., Bouguettaya A.,: Framework for Web service query algebra
and optimization. TWEB 2(1): (2008)
[Yu et al., 2008] Yu Q., Liu X., Bouguettaya A., Medjahed B.,: Deploying and
managing Web services: issues, solutions, and directions. VLDB J. 17(3): 537-572
(2008)
[Zhang et al., 2006] Zhang T., Ying S., Cao S., Jia X., : A Modeling Framework for
Service-Oriented Architecture. QSIC 2006: 219-226