mi Université Mohamed V- Souissi Rabat Ecole Nationale Supérieure d’Informatique et d’Analyse des Systèmes
UFR : Systèmes d’Information Métiers, Multimédia et Mobiles (SI3M)
Numéro d’ordre : ----
-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 Rapporteurs : M. Djamal BENSLIMANE M. Bouchaib BOUNABAT M. Bernard COULETTE Examinateur : M.Mahmoud NASSAR Directeur de thèse : M.Abdelaziz KRIOUILE
Professeur à l‟ENSIAS de Rabat, Maroc Professeur à l‟Université Claude Bernard Lyon 1, France Professeur à l‟ENSIAS de Rabat, Maroc Professeur à l‟Université de Toulouse II-Le Mirail, France Professeur Habilité à l‟ENSIAS de Rabat, Maroc
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
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.
de
Table des matières Introduction générale ........................................................................................ 1 Etat de l’art ................................................................................................. 7
I.
I.1. I.2. I.3.
Introduction .............................................................................................................. 7 Systèmes Orientés Services (SOS) : concepts et définitions.................................... 8 SOS : Approches de modélisation ............................................................................ 9
I.3.1. I.3.2. I.3.3. I.3.4.
Approches à base de « Service Component » ................................................................ 10 Approches à base de « Service Component Architecture » (SCA) ............................... 12 Approches à base de profils UML ................................................................................. 14 Discussion...................................................................................................................... 20
SOS : Concepts d‟adaptation.................................................................................. 20
I.4.
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
SOS : technologies d‟adaptation ............................................................................ 34
I.5. I.5.1. I.5.2. I.5.3.
I.6.
AWSDL et CWSDL ...................................................................................................... 34 CBPEL et VXBPEL ...................................................................................................... 35 Discussion...................................................................................................................... 35
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
Introduction ............................................................................................................ 69 Exemple illustratif : Le système d‟enseignement à distance .................................. 71 Le concept de service multivues ............................................................................ 72
II.3.1. II.3.2.
II.4. II.5.
Le concept de vue...................................................................................................... 73 Le service multivues.................................................................................................. 74
Les couches d‟abstraction d‟un SOS Adaptable .................................................... 78 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
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. III.4.2. III.4.3. III.4.4. III.4.5.
III.5.
Phase 1: Elaboration des modèles des cas d‟utilisation........................................... 128 Phase 2: Identification des services par acteur ........................................................ 129 Phase 3 : Spécification des interfaces de services ................................................... 133 Phase 4 : Fusion des modèles visuels ...................................................................... 135 Phase 5: Transformation des modèles et génération de code .................................. 137
VSoaMLTool : Outil de génération de code automatique .............. 140
IV.1. IV.2. IV.3. IV.4. IV.5. IV.6.
Introduction .......................................................................................................... 140 VSoaMLTool : modules et fonctionnalités .......................................................... 141 VSoaMLTooL : Transformation de modèle et génération de code...................... 143 Le PIM (VSoaML) de l‟étude de cas DLS ........................................................... 144 Le métamodèle du profil VSoaML ...................................................................... 147 Du PIM (VSoaML) vers des descriptions (MVWSDL) ....................................... 148
IV.6.1.1 IV.6.1.2 IV.6.1.3
Le Multiview WSDL pour la description des services multivues....................... 148 Du PIM(VSoaML) vers PSM(MVWSDL) ......................................................... 151 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 (MDAModel 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.
Etat de l’art
7
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
Etat de l’art
8
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
Etat de l’art
9
(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
Etat de l’art
10
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
Etat de l’art
11
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)
Etat de l’art
12
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
Etat de l’art
13
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
Etat de l’art
14
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.
Etat de l’art
15
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
Service Channel
Connector
Service Collaboration
Collaboration
Ce stéréotype permet de déterminer le couple specification/binding Ce stéréotype décrit une connexion entre services. Ce stéréotype permet la modélisation du comportement d‟un ensemble
Etat de l’art
16
Service Consumer
Classifier
Service Gateway
Port
Service Partition
Node
Service Provider
Class
Service Specification
Class, Interface
de services qui coopèrent. Ce stéréotype désigne un consommateur de service. Ce stéréotype permet la modélisation d‟une connexion entre partitions Ce stéréotype définit un groupement logique ou physique d‟un ensemble de services Ce stéréotype permet la modélisation d‟un fournisseur d‟un ou de plusieurs services 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é
<>
Outer provider
Métaclasse UML de base Package
Sémantique Un fournisseur de service externe Le contrat établi entre fournisseurs de services
<> Business contract
Dependency
<>
System Front-End
Classifier
Les composants qui interagissent avec l‟utilisateur
<>
Composite service
Classifier
<>
Basic service
Classifier
Un service composé d‟autres services Ce stereotype représente une fonctionnalité basique
Etat de l’art
17
<>
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
Etat de l’art
18
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 Agent
Métaclasse UML Class
Sémantique 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
CollaborationUse
CollaborationUse
MessageType
Class, DataType, Signal
Expose
Dependency
Attachment désigne une partie d‟un Message qui est un attachement. CollaborationUse montre comment une collaboration (ServiceContracts et ServiceArchitectures) est accomplie. MessageType permet la spécification des informations échangées entre les fournisseurs et les consommateurs de services. Expose désigne une dépendance qui indique si un Capability doit être exposé ou pas.
Milestone
Comment
Participant
Class
Milestone permet d‟indiquer le progrès dans les comportements ayant une durée considérable. participant désigne un fournisseur ou un consommateur de service
Etat de l’art
19
Provider modélise le type d‟un fournisseur de services. Consumer modélise un type d‟un consommateur de service. 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.
Provider
Interface, Class
Consumer
Interface, Interface
Request
Port
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
Service Contract
Collaboration
Service Interface
Class, Interface
ServiceChannel
Connector
Services Architecture
Collaboration
Capability dénote une capacité d‟un service donné. ServiceContract est la formalisation de l‟échange d‟information, des biens et des obligations entre les parties définissant un service. ServiceInterface fournit la définition d‟un service. Il définit la spécification de l‟interaction «Service» ou «Request» ServiceChannel désigne un chemin de communication entre requêtes et services 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
Etat de l’art
20
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
Etat de l’art
21
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.
Etat de l’art
22
(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
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,
Etat de l’art
23
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
Etat de l’art
24
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)
Etat de l’art
25
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.
Etat de l’art
26
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.
Etat de l’art
27
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
Etat de l’art
28
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
Unit Service Layer
Unit Service
Business Process
Business Process
Unit Service
Unit Service
Composition Variability
Interface Layer
service Component Layer
Workflow Variability
Interface Variability
<>
<>
<>
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.
Etat de l’art
30
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
Etat de l’art
31
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
Etat de l’art
32
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
Etat de l’art
33
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
Etat de l’art
34
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
Etat de l’art
35
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
Etat de l’art
36
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
I.6.
des
caractéristiques
des
SOS
par
les
différentes
stakeholders.
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
Etat de l’art
37
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
Etat de l’art
38
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.
Etat de l’art
39
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 :
Etat de l’art
40
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.
Etat de l’art
41
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.
Etat de l’art
42
UML metamodel
Mapping
WSDL metamodel WSDLElement
ModelElement
Type +types 0..1
Part Namespace
0..* +part
P2D
Message
Package
A2T
AssociationEnd Class Interface
Definition +_targetNameSpace +name
0..* +boperations
BindingOperation
O2O
Port
+method
+port +service Service 0..* 0..*
M2Bo P2Part
Parameter DataType
0..* +portType 0..* +binding
Binding
Attribute
Method
0..*
PortType +type
+specification
+message 0..*
Operation +operation
C2S
Operation
Documentation
Dt2T
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.
Etat de l’art
43
UML metamodel
Mapping
Java metamodel
ModelElement
JElement
Namespace
P2P
JPackage 0..*
Package AssociationEnd
Ae2F
+nested
JClassifier
+super 0..1
Generaliation
JClass 0..* +implemetedby 0..* +implements
GeneralizableElement
C2Jc
Class
I2I
JInterface JPrimitiveType
Interface Attribute
A2F
JMember JField
Operation +specification
0..*
OM2M
+method
JValue
Method
JMethod
Pr2Pr
Parameter DataType
+type +type
Dt2Jpt
+owner +jparameters
0..*
JParameter
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.
Etat de l’art
44
WSDL
Model composite Web services
UML
Service modeling
Discover Web Services
Import Web Service Description
Composite Web Service-WSDL
Workflow modeling
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.
Yu et al.(Yu, 2007) proposent un framework de développement dirigé par les modèles combinant entre le profil EDOC, MDA et les services web. Dans le cadre de ce framework, on exprime le PIM global du système en utilisant le profil EDOC qui définit la structure, les fonctionnalités et le comportement d‟un système indépendamment des technologies et des standards. Après l‟élaboration du PIM global du système, la deuxiéme étape consiste en la décomposition du PIM global en des sous PIMs suivant une décomposition fonctionnelle. Chaque sous PIM fournit des fonctionnalités indépendantes des autres sous PIMs et est implémenté en tant que service Web. La troisième étape de ce framework consiste en la transformation de chaque sous PIM en un modèle d‟interface suivant le métamodèle WSDL. Ensuite, la transformation de chaque sous PIMs en BPEL pour la définition de la composition de services. La figure 19 illustre le processus de transformation défini dans le cadre de ce framework.
Etat de l’art
46
EDOC PIM
WSDL
BPEL
Functional Decomposition
Web Service EDOC PIM
WSD L
WSD L
mapping
Web Service mapping
BPEL
Implementation Platform 1
2
EDOC PIM
BPEL
Web Service N WSD L mapping
EDOC PIM
BPEL
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.
Etat de l’art
47
Nom de la règle Dp2pdt
Entrée DataType String Integer Float Decimal Boolean Date Enumeration CompositeData
En2st Cd2ct
Sortie PrimitiveDatatype String Int Float Decimal Boolean Date SimpleType 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
Input(CCA) FlowPort FlowPort OperationPort ProtocolPort ProtocolPort ProtocolPort PC PC PC
Output (WSDL) Message WSDL File
Tableau 5–Correspondances CCA/WSDL (Yu et al., 2007)
Etat de l’art
49
(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
*
target
subtypes
+incomings
Node
AbstractTransition +outcoming s
+source -name : String
Transition PortUsage
PseudoState
-kind :PseudoSateKind
-preCondition
+represents
Port -name : String -isSyne :Boolean -Transactional :Boolean -direction:DirectionType -postcondtion:Status
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
Etat de l’art
50
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
Etat de l’art
51
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).
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.
Etat de l’art
52
Figure 25–Métamodèle du XML schéma
Figure 26–Métamodèle WSDL (Patrsciou et al., 2004)
Etat de l’art
53
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
informations de cryptage. La figure 27 présente le profil « extra-functional Property » avec ses métaclasses de base.
Figure 27–Profil «Extra- functional Property » (Ortiz et al., 2006b)
EFProperties <> Extra-functional Property
<> Encryption -encryptionKey : string
<> Login -usersDB : string
<> Loging -recordFile : string
<> RealTime -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
Etat de l’art
55
«carRenting» puisqu‟il est accessible seulement aux utilisateurs qui ont un login et un mot de passe.
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.
Etat de l’art
56
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
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 PolicyElement -name : String
Figure I-32Figure 32–Métamodèle Policy (Ortiz et al, 2006a)
I.6.3.2
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
Etat de l’art
57
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é SECTETPL 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
Etat de l’art
58
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)
Etat de l’art
59
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é QWSDL 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)
Etat de l’art
60
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
Q-WSDL XML Schema
XMI
Metamodel layer
WSDL Metamodel
WSDL Metamodel
Q-WSDL Model
Q-WSDL Metamodel
Model Layer
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.
Etat de l’art
61
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
métamodèle du profil contextUML.
Figure 36–Métamodèle ContextUML (Maamar et al., 2006)
le
Etat de l’art
62
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
Etat de l’art
63
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.
Etat de l’art
64
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
Formalisme de modélisation
Automatisation La prise en de génération compte de de code l‟utilisateur
Le niveau de prise en compte des utilisateurs --
Préoccupation( s) prise(s) en compte
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)
UML, service component
Oui
Non
Profil UML pour SOA
Oui
Non explicite --
--
(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 SCD
Non
Oui
PSM
--
Non
Oui
PIM
Contexte
ContextUML
Non
Oui
PIM
Contexte
ContextUML
Non
Oui
PIM
Contexte
--
Non
Oui
PSM
Contexte
--
SoaML
Etat de l’art
65
VPL Tao tao et al., 2007) Chang et al. ( Bézivin et al., 2004 (Patrasciou al., 2004) (Gronmo et al., 2004a) (Yu et al., 2007) (Ortiz et al., 2007) Alam (Alam et al. 2007a) (Alam et al. 2007b) (D‟ambrogio et al., 2007)
UML Machine à états Notation spécifique UML/EDOC
Oui Non
Oui Oui
PIM PIM
Non
Oui
PIM
Oui
Non explicite --
Droits d‟accès Profil de l‟utilisateur Profil de l‟utilisateur --
EDOC
Oui
Non explicite --
--
UML
Oui
Non explicite --
--
EDOC
Oui
Non
--
--
Profil UML
Oui
Oui
PIM
SECTET-PL
Oui
Oui
PIM
Aspects non fonctionnels Droits d‟accès
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 (DLSDistance 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.
Figure 37–Diagramme des cas d’utilisation du DLS
II.3. Le concept de service multivues 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
Annuaire de Services
Publish
Find
Client de service 2
Invoke
Invoke
Invoke
Publish
Find
Find
Find
Client de service 1
Publish
Client de service 3
Invoke
Client de service M
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()
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 BPMN
Modèles des cas d‟utilisation
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
Figure 42–SOS adaptable : Couches d’abstraction
Composition de services BPEL
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
UML via ses mécanismes d‟extension (tagged values, stereotypes et
constraints). 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
<<metaclass>> Class
<<metaclass>> Property
<<metaclass>> Port
<> Message
<> Message Attachment
<> Service
<<metaclass>> Port
<<metaclass>> Connector
<> MVService
<> Service Channel
<<metaclass>> Package
<> Service Domain
<<metaclass>> Collaboration
<> Service Collaboration
<<metaclass>> Interface
<> MVServiceInterface
<> ViewServiceInterface
<<metaclass>> Artifact
<> MVServiceSpecification
<> BaseServiceInterface
<<metaclass>> classifier
<> 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 (UML) Message Class
Description
<> 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 << MVService>> 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
ServiceDomain
Package
<> est un élément de modélisation qui représente un client de service
<>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
modélisation permettant la
un
élément
de
spécification des
opérations et leurs messages associés qui définissent le service. BaseServiceInterface
Interface <> modélisation
qui
est
représente
un
élément un
de
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 Specification)
et
entre
(Service, (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.
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
par ajouterEvenement(e :Evenement) ajouterEvenement(e :Evenement) updateEvenement(e :Evenement)
Figure 51–Exemple de stéréotype Specification
II.5.2.5
Le stéréotype MVService
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
VSoaML : Un profil UML de modélisation des systèmes orientés services adaptables
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
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, HTTPGET, 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
Figure 58–Stéréotype Channel
II.5.2.9
Le stéréotype Requester
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. Serv iceInterf ace
Package(from UML2.0)
0..1 +base
BaseServiceInterface
1 1..*
1 MVServiceInterface
1 Include
1
0..1 +view
0..*
1 ViewServiceInterface
1..* Actor(from UML2.0) +actor
1
1
Figure 61–Stéréotype MVServiceInterface
La figure 62 illustre un exemple d‟une MVServiceInterface. <> Course
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.
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)
MVServiceInterface
1
0..1
BaseServiceInterface
+base
1
1
1 1..* Include 0..1
+v iew
1
0..* MVServ ice
ViewServiceInterface
1..* +requires 1..* 1..*
+prov ides 1
1 +actor
Figure 65–Stéréotype ViewServiceInterface
Actor(f rom UML2.0)
106
VSoaML : Un profil UML de modélisation des systèmes orientés services adaptables
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
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
<> Inscription_Enseignant, interface
modélise
les
interfaces
Inscription_Etudiant,
<> les
ViewServiceInterface
fonctionnalités
<>
Inscription_Administrateur.
spécifiques
suivantes :
à
chaque
acteur.
Chaque 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_Etudiant
Formation_Administrateur. L‟interface
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.
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
Deploiement
Construction et Test
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.
III.3.1.1
Les types de modèles et de transformation de MDA
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
PSM Codage
Code Test
Code Déploiement
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
