THESE. DOCTORAT EN SCIENCES APPLIQUEES Spécialité : Informatique

Transcription

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

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

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

4 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

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

6

7 Table des matières Introduction générale... 1 I. Etat de l art... 7 II. I.1. Introduction... 7 I.2. Systèmes Orientés Services (SOS) : concepts et définitions... 8 I.3. SOS : Approches de modélisation... 9 I.3.1. Approches à base de «Service Component» I.3.2. Approches à base de «Service Component Architecture» (SCA) I.3.3. Approches à base de profils UML I.3.4. Discussion I.4. SOS : Concepts d adaptation I.4.1. Concept d adaptation : les Vues I Vues à base de l adaptation par rôles I Vues à base de l adaptation contextuelle I Discussion I.4.2. Concept d adaptation : la variabilité de service I Description de l approche I Discussion I.4.3. Concept d adaptation : la différenciation de service I Description de l approche I Discussion I.5. SOS : technologies d adaptation I.5.1. AWSDL et CWSDL I.5.2. CBPEL et VXBPEL I.5.3. Discussion I.6. SOS : Approches d adaptation dirigées par les modèles I.6.1. Concepts et définitions I.6.2. Approches MDA de développement des SOS I PIM (UML) vers services Web I PIM(EDOC) vers services web I.6.3. Approches MDA d adaptation des SOS I Approches de gestion des propriétés non-fonctionnelles I Approches de gestion des droits d accès I Approches de gestion de la qualité de services I Approches d adaptation au contexte I Discussion I.7. Synthèse générale VSoaML : Un profil UML de modélisation des systèmes orientés services adaptables... 69

8 III. II.1. Introduction II.2. Exemple illustratif : Le système d enseignement à distance II.3. Le concept de service multivues II.3.1. Le concept de vue II.3.2. Le service multivues II.4. Les couches d abstraction d un SOS Adaptable II.5. Le profil VSoaML II.5.1. Le profil VSoaML : Vue d ensemble II.5.2. VSoaML : les stéréotypes II Le stéréotype Service II Le stéréotype Message II Le stereotype MessageAttachment II Le stéréotype Specification II Le stéréotype MVService II Le stéréotype MVServiceSpecification II Le stéréotype Collaboration II Le stéréotype ServiceChannel II Le stéréotype Requester II Le stéréotype MVServiceInterface II Le stéréotype BaseServiceInterface II Le stéréotype ViewServiceInterface II Le stéréotype Provider II Le stéréotype ServiceOperation II Le stéréotype ServiceDomain II.5.3. Exemple illustratif DLS : Couches d abstraction II.6. Conclusion Processus de Développement Dirigé par les Modèles des Systèmes Orientés Services Adaptables III.1. Introduction III.2. Processus de développement des systèmes orientés services : phases, activités et artefacts III.3. Processus de développement MDA : phases, activités et artefacts III.3.1. Les types de modèles et de transformation de MDA III Computation Independent Model (CIM) III Platform Independent Model (PIM) III Platform Specific Model (PSM) III.3.2. Le processus de développement dans le contexte de MDA : III.4. Processus MDA de développement des SOS adaptables III.4.1. Phase 1: Elaboration des modèles des cas d utilisation III.4.2. Phase 2: Identification des services par acteur III.4.3. Phase 3 : Spécification des interfaces de services III.4.4. Phase 4 : Fusion des modèles visuels III.4.5. Phase 5: Transformation des modèles et génération de code III.5. Conclusion

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

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

11 Figure 41 Couches fonctionnelles d un SOS (Papazoglou, 2007) Figure 42 SOS adaptable : Couches d abstraction Figure 43 Stéréotypes de VSoaML et leurs métaclasses de base UML Figure 44 Métamodèle de VSoaML Figure 45 Stéréotype Service Figure 46 Service Agenda Figure 47 Stéréotype message Figure 48 Exemple d un message Figure 49 Stéréotype MessageAttachment Figure 50 Stéréotype specification Figure 51 Exemple de stéréotype Specification Figure 52 Stéréotype MVService Figure 53 Exemple de service multivues Figure 54 Stéréotype MVServiceSpecification Figure 55 Exemple de MVServiceSpecification Figure 56 Stéréotype Collaboration Figure 57 Exemple de collaboration de services Figure 58 Stéréotype Channel Figure 59 Stéréotype Requester Figure 60 Exemple de Requester Figure 61 Stéréotype MVServiceInterface Figure 62 Exemple de MVServiceInterface Figure 63 Stéréotype baseserviceinterface Figure 64 Exemple de BaseServiceInterface Figure 65 Stéréotype ViewServiceInterface Figure 66 Exemple de ViewServiceInterface Figure 67 Stéréotype Provider Figure 68 Stéréotype ServiceOperation Figure 69 Exemple de serviceoperation Figure 70 Stéréotype ServiceDomain Figure 71 Modèle BPMN du cas d utilisation «Assurer Formation» Figure 72 Modèle BPMN du cas d utilisation «Suivre formation» Figure 73 Modèle des services multivues du DLS Figure 74 Extrait du modèle d information du système d Enseignement à Distance Figure 75 Phases du cycle de vie méthodologique (Papazoglou et al., 2006) Figure 76 Types de transformations MDA (Blanc, 2005) Figure 77 Processus de développement MDA des systèmes logiciels Figure 78 Processus de développement des systèmes orientés services multivues dans le cadre de l approche MDA Figure 79 Cas d utilisation du DLS Figure 80 Scénario associé au cas d utilisation «assurer Formation» associé à l acteur Figure 81 Identification des services associés à l acteur «Enseignant» Figure 82 Identification des services associés à l acteur «Administrateur» Figure 83 Identification des services associés à l acteur «Etudiant» Figure 84 PIM raffiné associé à l acteur Etudiant

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

13 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

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

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

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

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

18 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

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

20

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

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

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

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

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

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

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

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

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

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

31 17 Etat de l art <<OrchServ>> Orchestrator service Classifier Ce stéréotype joue le rôle d un orchestrateur dans une chorégraphie <<ServContract>> Service contract Association Class Ce stéréotype joue le rôle d un connecteur entre service <<contractclause>> Restriction clause Classifier Les pre/post conditions qui doivent être vérifiées <<servop>> 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

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

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

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

35 21 Etat de l art pour l adaptation des services au contexte de l utilisateur (Benslimane et al., 2005), la gestion de ses droits d accès (Fink et al., 2003) et l adaptation des services aux types des utilisateurs de service (Fuchs, 2004). Dans un deuxième lieu, nous présentons les approches qui se basent sur la variabilité de service pour la prise en compte de l utilisateur final (Chang et al., 2007a). En troisième lieu, nous présentons les approches permettant l adaptation de services se basant sur le concept de service différencié (Tao et al., 2007a) (Tao et al., 2008). Finalement, nous présentons autres approches qui définissent des extensions aux standards de la technologie des services web pour la prise en compte de l utilisateur final (lopez-velasco et al., 2005) (Kouadri Mostefaoui, 2006). I.4.1. Concept d adaptation : les Vues L objectif de cette section est de présenter les différents travaux combinant entre le concept de vue et celui de service pour la prise en compte de l utilisateur final. Généralement, les vues sont largement utilisées dans plusieurs domaines de l informatique. Elles sont utilisées dans les SGBD (Rafanelli et al. 2003), la gestion des connaissances, les workflows, les approches orientées objets, etc. Aussi, notre équipe a déjà développé des méthodes en se basant sur le concept de vue telles que la méthode VBOOM (Kriouile, 1995) ou l approche VUML (Nassar et al., 2005). De même, pour accompagner l évolution de l ingénierie logicielle vers les approches à base de composants (Szyperski, 2002), un modèle du composant multivues (El Asri, 2005) a été proposé. Dans cette section, nous nous intéressons tout particulièrement aux approches se basant sur les vues pour la prise en compte de l utilisateur final pour le développement des SOSs. I 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.

36 22 Etat de l art (1) L exemple d application «Video central» est une application qui repose sur un ensemble de services web développé par IBM (IBM, 2002). Cette application définit six services web représentés par le diagramme de classe UML dans la figure 6 suivante. CustomerRentedList processaddrequest(loginbusinessguid,loginbusinesspassword,userid,titleidlist):int processqueryrequest(loginbusinessid,loginbusinesspassword,customerguid):string WishList processaddrequest(businessguid,registrationkey,customerguid,titlelist):int processqueryrequest(businessguid,registrationkey,customerguid,maxnumrecords):string processremoverequest(businessguid,registrationkey,customerguid,titlelist):int MovieSearch processrequest():string Customer CustomerInfraction processaddrequest(loginbusinessid,loginbusinesspassword,firstname,lastname):int processqueryrequest(loginbusinessid,loginbusinesspassword,customerguid,begindate,enddate):string BusinessRegistration processregisterrequest():int Staff CustomerRegistration getcustomerguid(loginbusinessid,loginbusinesspassword,firstname,lastname):int processregisterrequest(loginbusinessid,loginbusinesspassword,firstname,lastname):int Figure 6 Diagramme de classe et les rôles de l application «video central» (Fink et al, 2003) «Video central» se compose de six services web représentés sous forme de diagramme de classes UML : CustomerRentedList, MovieSearch, BusinessRegistartion, CustomerRegistration et CustomerInfraction. Ce diagramme illustre aussi les rôles qui interagissent avec les différents services web : Customer et Staff. Chaque rôle a ses propres besoins sur les services. En d autres termes, chaque acteur a ses droits d accès sur un service donné. En effet, dans le cadre de cet exemple, le rôle Customer ne peut pas exécuter les opérations : processregisterrequest, ou getcustomerguid réservées seulement au rôle Staff. (2) Le modèle VBAC et le langage VPL VBAC est un modèle de contrôle d accès conçu pour supporter la conception et la gestion des politiques de contrôle d accès dans les systèmes distribués. VBAC (Fink et al.,2003) est une extension du modèle de contrôle d accès à base de rôles (RBAC) par les concepts de vue et de schéma. Une vue regroupe les permissions ou les interdictions pour la gestion de l accès à des objets (un fichier, une méthode, ). Chaque vue est associée à des rôles. Un sujet (un utilisateur,

37 23 Etat de l art un processus, ) peut accéder à un objet s il a un rôle auquel une vue est assignée. Si la vue n existe pas pour un rôle donné, le sujet ne peut pas accéder à l objet en question. Un schéma spécifie les assignations dynamiques aux différents rôles. Ces assignations sont effectuées automatiquement à chaque invocation d une opération donnée. Dans le but de spécifier les politiques VBAC, un langage déclaratif appelé VPL (View Policy Language) a été défini. VPL est utilisé pour spécifier les rôles, les vues et les schémas. Les rôles sont définis dans une déclaration en utilisant le mot clé role. Les schémas sont définis en utilisant le mot clé schema. La clause role définit les différents rôles dans la politique ainsi que leurs vues initiales. La figure 7 montre la définition des rôles pour l application «Video central». role customer staff holds BusinessRegistration view BusinessRegistration controls BusinessRegistration restricted to staff { processregisterrequest } view CustomerRegistration controls CustomerRegistration restricted to staff { getcustomerguid(loginbusinessid,,, ) if caller = loginbusinessid processregisterrequest(loginbusinessid,,, ) if caller = loginbusinessid } view CustomerInfraction controls CustomerInfraction restricted to staff { processaddrequest( loginbusinessid,, ) if caller = loginbusinessid processqueryrequest( loginbusinessid,,,, ) if caller = loginbusinessid } Figure 7 Déclaration des vues en VPL (Fink et al., 2003). La figure 7 montre la déclaration de deux rôles : Client et Staff. Le rôle staff possède initialement la vue BusinessRegistration (mot clé holds). Le rôle Client n a initialement aucune vue. Une vue VPL définit les autorisations à un sous-ensemble d opérations d un seul service web. Une vue est référencée par la clause de contrôle. Par exemple, la vue BusinessRegistration donne la permission pour invoquer l opération processregisterrequest du service web BusinessRegistration. Une Vue VPL peut être statiquement restreint à certains rôles. I 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

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

39 25 Etat de l art Par ailleurs, et dans le but d adapter les services web à des environnements hétérogènes et à différents groupes d utilisateurs, Fuchs (Fuchs, 2004) adopte le concept de vue pour la définition d un mécanisme appelé «service view». Un «service view» est une définition WSDL spécifiée pour un groupe d utilisateurs à l instar de la définition des vues dans les systèmes de gestion de bases de données où une vue est définie comme une combinaison d informations à partir de plusieurs tables associées à un utilisateur donné. Cette définition WSDL décrit un ensemble d opérations du service, leurs adresses, et le contenu de leurs messages suivant le type des utilisateurs interagissant avec le service. Dans ce sens, deux types d utilisateurs ont été identifiés : les utilisateurs internes et les utilisateurs externes. En effet, ces deux types d utilisateurs ont leur propre description WSDL. Les fournisseurs de services doivent créer des descriptions de service qui s adaptent aux types de clients. Pour cela, Fuchs définit une architecture se basant sur deux couches : la couche «service views» et la couche «rule groups» fournissant une couche d adaptation qui permet de manipuler les descriptions de services en changeant les noms des opérations, leurs entrées/sorties, leurs adresses ainsi que les différents mécanismes d authentification et d autorisation. Les «service View» sont implémentés en utilisant un langage de script qui permet de modifier la structure des documents WSDL et de créer de nouvelles descriptions WSDL correspondant aux besoins des clients bien définis. Ce langage de script se compose d un ensemble de commandes. Chaque commande permet de définir une insertion, une suppression ou à une mise à jour d un élément constituant la description WSDL. La figure 9 spécifie un ensemble de commande pour la génération des WSDL spécifiques aux clients de services internes et externes à partir des descriptions WSDL. <createservice name= External targetnamespace= xmlns:wssec= ws-security xmlns:wsi= ws-i conformance /> <insertschema> <schema targetnamespace= PurchaseOrders"> <import namespace=" ws-security "/> <import namespace=" ws-i conformance "/> </schema> </insertschema> <port name= ExternalPort > <soap:address <importoperation name= submitissue location= port= service/port xmlns:sup= Support > <ensureschema> <schema targetnamespace="support"> <element name="contact" type="string"/> <element name="module" type="int"/> <element name="descr" type="string"/> </schema> </ensureschema> <insertpart location= HEADER message= tns:wssc part= header />

40 26 Etat de l art location=" <importoperation name= sendpurchaseorder location = port = service/port > <insertpart location = HEADER message= tns:ws-sec part= header /> <insertpart location= HEADER message= tns:wsi part= header /> </importoperation> <insertpart location= HEADER message= tns:wsi part = header /> <changepart name= contact element= sup:contact /> <changepart name= component element= sup:component /> <changepart name= description element= sup:description /> </importoperation> </port> </createservice> 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 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.

41 27 Etat de l art L approche proposée par Fuchs (Fuchs, 2004) pour l adaptation des descriptions de services suivant le type des utilisateurs (interne/externe), ne définit pas un formalisme ou une notation pour spécifier et développer des systèmes orientés services distribués et à large échelle. L adaptation de services se fait au niveau technologique et non pas au niveau métier, en utilisant un langage de commande et sur les descriptions WSDL. I.4.2. Concept d adaptation : la variabilité de service I 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

42 28 Etat de l art utilisateurs finals. Pour un service unitaire donné, plusieurs interfaces de services peuvent être découvertes. Dans ce cas, la variation consiste dans le bon choix de l interface qui correspond aux profils des clients de services. L interface choisie dépend des besoins du client de services interagissant avec le service. Business Process Layer Business Process Business Process Business Process Workflow Variability Unit Service Layer Unit Service Unit Service Unit Service Composition Variability Interface Layer Interface Variability service Component Layer <<Service Componentt>> <<Service Componentt>> <<Service Componentt>> 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é

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

44 30 Etat de l art Phase 4 : l acquisition des composants services : L objectif de cette phase est de préparer les services web en tenant compte des services découverts, des services adaptés à partir des applications existantes ou des nouveaux services web développés. Dans cette phase, la variabilité de la logique est associée aussi bien au niveau de l analyse qu au niveau de la conception. Phase 5 : la composition de services L objectif principal de cette phase est la définition de la composition de services. Cette composition est dérivée à partir des artefacts des phases précédentes et elle est représentée par le langage de spécification de composition BPEL. Dans cette phase, la variabilité est affinée ainsi que la finalisation de l architecture globale du système. I 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 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

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

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

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

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

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

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

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

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

53 39 Etat de l art I.6.2. Approches MDA de développement des SOS Dans cette section, nous présentons des travaux de recherche qui combinent entre deux disciplines dans le domaine du génie logiciel à savoir l ingénierie dirigée par les modèles et les approches à base de services. En premier lieu, nous allons mettre l accent sur les approches MDA de développement des SOS. Ainsi, plusieurs travaux ont été présentés (Bezevin et al, 2004) (Lopes et al, 2004)(Skogan et al., 2004)(Yu et al, 2007) (Torkman et al., 2006) (Patrasciou et al., 2004)(Gronmo et al., 2004a) (Baina et al., 2004). Nous avons classifié ces approches en deux classes selon le formalisme ou le langage de modélisation utilisé pour l élaboration des PIM. En effet, deux formalismes ont émergé pour la définition des PIMs : UML comme langage et standard universel de modélisation et le profil UML EDOC (OMG, 2002d) comme une extension d UML pour la modélisation des applications distribuées. En deuxième lieu, nous présentons quelques propositions pour la prise en compte de l utilisateur dans le contexte de MDA pour le développement des SOS. I 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 :

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

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

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

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

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

59 45 Etat de l art <<interface>> BasicWFS getcapabilities() describefeaturetype() getfeature() «Interface» TransactionWFS lockfeature() transaction() «BusinessService» MyWebService CreditCard number : string expires : date <<interface>> Payment validate(card :CreditCard) : boolean <types> <schema> <complextype name="creditcard">... <element name="number" type="string"/> <element name="expires" type="date"/>... </types> <message name="validaterequest"> <part name="card" type="creditcard"/></message>... <porttype name="payment"> <operation name="validate"> <input message="validaterequest"/> <output message="validateresponse"/> </operation> </porttype> <porttype name="transactionwfs"> <operation name="getcapabilities">... <operation name="describefeaturetype">... <operation name="getfeature">... <operation name="lockfeature">... <operation name="transaction">... <binding name="paymentsoapbinding" type="payment"> <soap:binding transport=" <operation name="validate">... </binding> <binding name="transactionwfssoapbinding" type="payment"> <operation name="getcapabilities">... <operation name="describefeaturetype">... <operation name="getfeature">... <operation name="lockfeature">... <operation name="transaction">...</binding> <service name="mywebservice"> <port name="payment_port binding="paymentsoapbinding"> <soap:address location=.. <port name="transactionwfs_port binding="transactionwfssoapbinding"> Figure 18 Correspondance UML/WSDL I PIM(EDOC) vers services web 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.

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

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

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

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

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

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

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

67 53 Etat de l art I.6.3. Approches MDA d adaptation des SOS L approche MDA a été largement utilisée dans le cadre de la prise en compte des différents aspects des besoins de l utilisateur final. Dans cette optique, plusieurs travaux dans la littérature ont été proposés pour la prise en compte des propriétés non-fonctionnelles, de la gestion des droits d accès, de la qualité de service et du contexte. L objectif de cette section est de présenter ces différentes propositions. I 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 : <<Login>>, <<realtime>>, <<Log>>, <<Encryption>> permettant respectivement la modélisation des informations de contrôle d accès, des propriétés temps réel, les informations de l invocation d opération et les informations de cryptage. La figure 27 présente le profil «extra-functional Property» avec ses métaclasses de base.

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

69 55 Etat de l art «carrenting» puisqu il est accessible seulement aux utilisateurs qui ont un login et un mot de passe. <<log>> touristserviceinterface <<ComponentService>> TouristService +hotelinformation( ) :string <<login>>+carrenting( ) : string <<RealTime>>+weatherInformation( ) : String <<Log>> actiontype=after optional=false ack=true recordfile=logfl policyid=log <<RealTime>> actiontype=instead optional=true ack=false realtimeurl=cnnweathe r policyid=realtime <<login>> actiontype=instead optional=false ack=true username=uname password=pw policyid=securitytoken policydoc=securityuri Figure 29 Service TouristService (Ortiz et al., 2006a) Après la modélisation de l application en se basant sur le profil UML défini, un processus de transformation a été défini. Ce dernier se base sur le profil défini pour l élaboration du PIM. Légende : CT : Conforms To Figure 30 Processus de transformation ATL (Ortiz et al., 2006a) Ensuite, ce PIM sera transformé vers les PSMs suivants : Policy Model, AOP model et SOAP Tag Model. La figure 30 présente le processus de transformation.

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

71 57 Etat de l art droits d accès des utilisateurs non pas au niveau technologique mais au niveau modèle métier, c'est-à-dire à un haut niveau d abstraction. Pour ce faire, le framework se base principalement sur un profil UML appelé SECTET-UML et sur un langage spécifique au domaine appelé SECTET- PL pour l élaboration des modèles métiers tout en y associant les informations des droits d accès des utilisateurs. Le framework permet dans un deuxième lieu la génération de politiques d accès ciblant une plateforme technologique particulière à savoir le XACML. SECTET-UML (Hafner et al., 2009) est un profil UML permettant la modélisation des services et de leurs interfaces, des informations échangées entre services ou entre clients de services ainsi que les droits d accès statiques. Ce profil définit un ensemble de stéréotypes étendant des métaclasses UML comme le montre le tableau 6. Ces différents stéréotypes sont utilisés pour l élaboration de quatre modèles définis dans le cadre de ce framework : le modèle des interfaces, le modèle des documents, le modèle des droits d accès et le modèle des rôles. Le modèle des interfaces (Interface Model) définit un ensemble d opérations abstraites fournies par chaque service à ses clients. Le modèle des documents (Document Model) permet de décrire les différents types de données échangés entre les différents partenaires dans le cadre d un SOS. Stereotype Metaclase UML <<InterfaceView>> Package <<InterfaceModel>> Package <<Interface>> Interface <<rolemodel>> Package <<partnermodel>> Class <<domainmodel>> Class <<documentmodel>> Package <<key>> Attribute <<d>> Class <<external>> Interface <<accessmodel>> Package <<accessconstraint>> 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

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

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

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

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

76 62 Etat de l art I 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

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

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

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

80 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

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

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

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

84 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

85 71 VSoaML : Un profil UML de modélisation des systèmes orientés services adaptables collaborations de services pour répondre à des exigences complexes auxquels un seul service ne peut pas répondre. Ce chapitre est organisé comme suit : La section 2 décrit notre étude de cas concernant un système d enseignement à distance. La section 3 présente le concept de service multivues comme un élement clé de notre approche. La section 4 illustre les différentes couches d abstractions que nous avons définies pour la spécification des SOSs adapatables en se basant sur le service multivue. La section 5 présente notre profil VSoaML pour la modélisation des systèmes orientés services en définissant les stéréotypes de ce profil ainsi que son métamodèle. La section 6 présente la modélisation du système d enseignement à distance en utilisant notre profil VSoaML. II.2. Exemple illustratif : Le système d enseignement à distance Notre étude de cas est une version simplifiée d un Système d enseignement à distance (DLS- Distance Learning System) (Nassar et al., 2005). Notre objectif est d utiliser ce système tout en l étendant avec des nouvelles fonctionnalités inspirée du systéme d enseignement à distance Moodle ( 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

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

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

88 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

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

90 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

91 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». <<MVServiceInterface>> Formation <<ViewServiceInterface>> Formation_Enseignant CreerFormation() supprimerformation() ajouterexercice() ajoutersolutionexercice() proposerprojet() poserquestion() proposerforum() proposertest() proposergroupeprojet() consulterprojet() ajouterannounceformation() respondrequestions() <<ViewServiceInterface>> Formation_Etudiant consulterformation() consulterexercice() proposersolutionexercice() postermessage() proposersoultiontest() consulterressourceprojet() consulterprojet() consulterannounceformation() <<Include>> <<Include>> <<viewserviceinterface>> Formation_Administrateur ajouternouvelleformation() ajouteragendaformation() ajouterannounceformation() supprimerformation() affecterresponsableformation() <<include>> <<baseserviceinterface>> Formation_base consultersynopsisformation() consulterlistformation() Figure 40 Interface de service multivues du service multivues «Formation»

92 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

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

94 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

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

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

97 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 <<stereotype>> Message <<stereotype>> Message Attachment <<stereotype>> Service <<metaclass>> Port <<metaclass>> Connector <<metaclass>> Collaboration <<stereotype>> MVService <<stereotype>> Service Channel <<stereotype>> Service Collaboration <<metaclass>> Package <<metaclass>> Interface <<stereotype>> Service Domain <<stereotype>> MVServiceInterface <<stereotype>> ViewServiceInterface <<stereotype>> BaseServiceInterface <<metaclass>> Artifact <<metaclass>> classifier <<stereotype>> MVServiceSpecification <<stereotype>> Specification <<stereotype>> Service Provider <<stereotype>> 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

98 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

99 85 VSoaML : Un profil UML de modélisation des systèmes orientés services adaptables modélisation des applications SOA (Johnston et al., 2006). La figure 43 illustre les différentsstéréotypes de ce profil ainsi que leurs métaclasses de base UML2.0. La figure 44 illustre le métamodèle du profil VSoaML. Le tableau 8 présente succinctement les différents stéréotypes du profil VSoaML. Dans la première colonne, nous présentons chaque stéréotype du profil VSoaML. Dans la deuxième, nous présentons la métaclasse de base de ce stéréotype. La troisième colonne présente une description succincte de chaque stéréotype. Stéréotype (VSoaML) Metaclasse Description (UML) Message Class <<Message>> 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 <<MessageAttachment>> est un élément de modélisation permettant d indiquer si le contenu d un message est un attachement ou pas Service Port <<Service>> 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

100 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 <<Channel>> 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 <<ServiceCollaboration>> 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 <<Requester>> est un élément de modélisation qui représente un client de service ServiceDomain Package <<ServiceDomain>>définit un groupement logique ou physique d un ensemble de services Provider Class <<Provider>> est un élément de modélisation permettant la représentation d un fournisseur d un ou de plusieurs services. ServiceSpecification Artifact <<ServiceSpecification>> est un élément de modélisation permettant la spécification des opérations et leurs messages associés qui définissent le service. BaseServiceInterface Interface <<BaseServiceInterface>> est un élément de modélisation qui représente un ensemble d opérations qui peuvent être invoquées par tous les

101 87 VSoaML : Un profil UML de modélisation des systèmes orientés services adaptables acteurs interagissant avec un service donné. <<BaseServiceInterface>> permet de modéliser les fonctionalités du service accessible à tous les clients de service. ViewServiceInterface Interface <<ViewServiceInterface>> 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 <<MVServiceInterface>> 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 <<ServiceOperation>>permet de représenter une opération d un service modélisant une fonctionnalité fournie d un service donné. La spécificité de <<ServiceOperation>> est qu elle manipule des données de grosse granularité ayant une valeur dans le cadre d un processus métier. <<ServiceOperation>> manipule en entrée, en sortie ou en erreur des messages. MVServiceSpecification Class <<MVServiceSpecification>> permet de décrire les services multivues. Ainsi, chaque MVServiceSpecification contient la description d une

102 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. <Include>> Dependency Le stéréotype <<include>> permet de décrire une relation d inclusion entre une interface de service vue (viewserviceinterface) et une interface de service de base (baseserviceinterface) <<specify>> Dependency Le stéréotype <<specify>> permet de représenter une relation de spécification entre (Service, Specification) et entre (MVService, MVServiceSpecification). Tableau 8 Stéréotypes du profil VSoaML II.5.2. VSoaML : les stéréotypes L objectif de cette section est de présenter chaque stéréotype constituant le profil VSoaML. II 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 <<service Provider>>. 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.

103 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. <<Service>> Agenda <<provide>> <<ServiceInterface>> Agenda ajouterevenement(e : Evenement); updateevent(e :Evenement); supprimerevenement(e:evenement); Figure 46 Service Agenda

104 90 VSoaML : Un profil UML de modélisation des systèmes orientés services adaptables Chaque opération de service possède un message en entrée et en sortie. Un message d entrée permet de représenter les données manipulées par une opération de service. Un message de sortie représente les données résultat de l exécution d une opération donné. La figure 46 présente un service Agenda. Ce service fournit une interface de service Agenda qui se compose d opérations : ajouterevenement, updateevenement, supprimerevenement. Il permet à un l acteur Administrateur de gérer l agenda des formations. Ainsi, le service permet de créer des événements, de les modifier ou de les supprimer. II 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.

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

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

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

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

109 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. <<MVServiceInterface>> Course <<MVService>> Course <<provide>> <<ViewServiceInterface>> Course_Professor CreateCourse() deletecourse() addexercise() addexercisesolution() proposeproject() askquestion() proposeforumtopic() proposetest_quiz() proposegroupproject() accessproject() addannouncecourse() respondstudentsquestions Message() <<ViewServiceInterface>> Course_Student accesscourse() accessexercise() proposeexercisesolution() postmessage() proposesoultiontestquiz() accessprojectressources() accessprojetc() accessannouncecourse() <<Include>> <<Include>> <<ViewServiceInterface>> Course_Adiministrator addnewcourse() addcoursescalendar() addannouncecourse() deletenewcourse() assigncourseresponsible() <<include>> <<baseserviceinterface>> Course_base consultsynopsiscourse() consullistcourse() Figure 53 Exemple de service multivues

110 96 VSoaML : Un profil UML de modélisation des systèmes orientés services adaptables II 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. <<MVServiceSpecification>> 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.

111 97 VSoaML : Un profil UML de modélisation des systèmes orientés services adaptables Artifact(from UML2.0) BusinessProtocol 0..* Specif ication 0..* Policy 1 1..* ServiceInterf ace 1 MVServiceSpecification * base 1 BaseServiceInterface 1 1..* MVServiceInterface Include * view 1 ViewServiceInterface 1..* Actor(f rom UML2.0) MVServ ice +prov ides 1 +actor 1..* +requires 1..* 1 Figure 54 Stéréotype MVServiceSpecification <<MVSpecification>> Course <<specifies>> <<MVServiceInterface>> Course <<ViewServiceInterface>> Course_Professor CreateCourse() deletecourse() addexercise() addexercisesolution() proposeproject() askquestion() proposeforumtopic() proposetest_quiz() proposegroupproject() accessproject() addannouncecourse() respondstudentsquestions Message() <<ViewServiceInterface>> Course_Student accesscourse() accessexercise() proposeexercisesolution() postmessage() proposesoultiontestquiz() accessprojectressources() accessprojetc() accessannouncecourse() <<Include>> <<Include>> <<ViewServiceInterface>> Course_Adiministrator addnewcourse() addcoursescalendar() addannouncecourse() deletenewcourse() assigncourseresponsible() <<include>> <<baseserviceinterface>> Course_base consultsynopsiscourse() consullistcourse() Figure 55 Exemple de MVServiceSpecification

112 98 VSoaML : Un profil UML de modélisation des systèmes orientés services adaptables Dans notre cas de figure, nous avons défini une extension à WSDL pour pouvoir décrire les services Multivues appelée MVWSDL (MultiView WSDL) (voir section MVWSDL, chapitre IV). MVWSDL est une extension légère au standard WSDL permettant la spécification des service multivues. Il s agit d un schéma XML permettant la description des interfaces du service multivues. II 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

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

114 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 Le stéréotype ServiceChannel Le stéréotype Channel permet de représenter le chemin de communication entre un service et ses clients (Johsnston et al., 2006). Dans le domaine des services web, chaque service permet d indiquer ses liaisons associées de telle façon qu un client puisse y accéder. Notre profil permet de spécifier la liaison pour pouvoir invoquer deux services ou entre des clients de service et un service. Ce stéréotype possède un attribut channel pour spécifier la liaison utilisée pour générer la liaison WSDL correspondante. Un exemple de binding peut être SOAP-RPC, FTP, HTTP- GET, etc. Deux contraintes ont été associées au stéréotype Channel : [1] au moins l extrémité d une connexion doit être un service. [2] au plus une extrémité d une connexion doit être une classe stéréotypé <<Provider>> ou bien un classifier stéréotypé <<Requester>>. La figure 58 illustre la métaclasse Channel ainsi que ses associations.

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

116 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). <<MVService>> Course <<invoke>> <<invoke>> <<Requester>> Student <<Requester>> Teacher Figure 60 Exemple de Requester II 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

117 103 VSoaML : Un profil UML de modélisation des systèmes orientés services adaptables particulier de clients de service. Un MVService peut avoir plusieurs MVServiceInteface qui sont associés à l élément de modélisation MVServiceSpecification. La figure 61 illustre la métaclasse MVServiceInterface ainsi que ses associations. Package(from UML2.0) Serv iceinterf ace MVServiceInterface 1 1..* Include base 1 BaseServiceInterface * +view 1 ViewServiceInterface 1..* +actor 1 1 Actor(from UML2.0) Figure 61 Stéréotype MVServiceInterface La figure 62 illustre un exemple d une MVServiceInterface. <<MVServiceInterface>> Course <<ViewServiceInterface>> Course_Professor CreateCourse() deletecourse() addexercise() addexercisesolution() proposeproject() askquestion() proposeforumtopic() proposetest_quiz() proposegroupproject() accessproject() addannouncecourse() respondstudentsquestions Message() <<ViewServiceInterface>> Course_Student accesscourse() accessexercise() proposeexercisesolution() postmessage() proposesoultiontestquiz() accessprojectressources() accessprojetc() accessannouncecourse() <<Include>> <<Include>> <<ViewServiceInterface>> Course_Adiministrator addnewcourse() addcoursescalendar() addannouncecourse() deletenewcourse() assigncourseresponsible() <<include>> <<baseserviceinterface>> Course_base consultsynopsiscourse() consullistcourse() Figure 62 Exemple de MVServiceInterface II Le stéréotype BaseServiceInterface Dans le cadre de notre profil VSoaML défini pour la modélisation des SOSs adaptables aux différents types d utilisateurs, le stéréotype BaseServiceInterface permet de représenter un

118 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 <<Include>> entre le BaseServiceInterface et ViewServiceInterface) dans une ViewServiceInterface. La figure 63 illustre le stéréotype BaseServiceInterface. La figure 64 montre un exemple du stéréotype BaseServiceInterface. Serv iceinterf ace Interface(from UML2.0) 1 1..* base 1 BaseServiceInterface 1 MVServiceInterface Include view MVServ ice 0..* +provides 1..* +requires 1 ViewServiceInterface 1 1 +actor Actor(f rom UML2.0) 1..* 1..* Figure 63 Stéréotype baseserviceinterface <<ViewServiceInterface>> <<ViewServiceInterface>> Course_Professor Course_Student CreateCourse() deletecourse() addexercise() addexercisesolution() proposeproject() askquestion() proposeforumtopic() proposetest_quiz() proposegroupproject() accessproject() addannouncecourse() respondstudentsquestions Message() accesscourse() accessexercise() proposeexercisesolution() postmessage() proposesoultiontestquiz() accessprojectressources() accessprojetc() accessannouncecourse() <<Include>> <<Include>> <<ViewServiceInterface>> Course_Adiministrator addnewcourse() addcoursescalendar() addannouncecourse() deletenewcourse() assigncourseresponsible() <<include>> <<baseserviceinterface>> Course_base consultsynopsiscourse() consullistcourse() Un exemple d une interface de service de base Figure 64 Exemple de BaseServiceInterface

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

120 106 VSoaML : Un profil UML de modélisation des systèmes orientés services adaptables Exemple des interfaces de service vues <<ViewServiceInterface>> Course_Professor CreateCourse() deletecourse() addexercise() addexercisesolution() proposeproject() askquestion() proposeforumtopic() proposetest_quiz() proposegroupproject() accessproject() addannouncecourse() respondstudentsquestions Message() <<ViewServiceInterface>> Course_Student accesscourse() accessexercise() proposeexercisesolution() postmessage() proposesoultiontestquiz() accessprojectressources() accessprojetc() accessannouncecourse() <<Include>> <<Include>> <<ViewServiceInterface>> Course_Adiministrator addnewcourse() addcoursescalendar() addannouncecourse() deletenewcourse() assigncourseresponsible() <<include>> <<baseserviceinterface>> Course_base consultsynopsiscourse() consullistcourse() II Le stéréotype Provider Figure 66 Exemple de ViewServiceInterface Le stéréotype Provider permet de représenter un fournisseur de services qui héberge le module logiciel implémentant un ou plusieurs services web accessibles via le réseau. Il définit une description de services et le publie en le faisant enregistrer dans un annuaire de services. Le demandeur de services invoque une opération de recherche pour trouver la description du service dans l annuaire de service. Il utilise alors la description du service pour établir une connexion avec le fournisseur de services et invoquer ou interagir avec l implémentation du service web. La figure 67 illustre la métaclasse Provider et ses associations.

121 107 VSoaML : Un profil UML de modélisation des systèmes orientés services adaptables Figure 67 Stéréotype Provider II 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.

122 108 VSoaML : Un profil UML de modélisation des systèmes orientés services adaptables Figure 68 Stéréotype ServiceOperation <<ViewServiceInterface>> Course_Professor CreateCourse() deletecourse() addexercise() addexercisesolution() proposeproject() askquestion() proposeforumtopic() proposetest_quiz() proposegroupproject() accessproject() addannouncecourse() respondstudentsquestions Message() <<ViewServiceInterface>> Course_Student accesscourse() accessexercise() proposeexercisesolution() postmessage() proposesoultiontestquiz() accessprojectressources() accessprojetc() accessannouncecourse() <<Include>> <<Include>> <<ViewServiceInterface>> Course_Adiministrator addnewcourse() addcoursescalendar() addannouncecourse() deletenewcourse() assigncourseresponsible() <<include>> <<baseserviceinterface>> Course_base consultsynopsiscourse() consullistcourse() Un exemple d une opération de service Figure 69 Exemple de serviceoperation II Le stéréotype ServiceDomain Le stéréotype <<ServiceDomain>> 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

123 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. <<ServiceDomain>>possède un attribut domain qui permet de regrouper les services d un domaine métier particulier. Un <<ServiceDomain>> é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».

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

125 111 VSoaML : Un profil UML de modélisation des systèmes orientés services adaptables Figure 72 Modèle BPMN du cas d utilisation «Suivre formation» La couche logique est décrite par le modèle de service multivue et le modèle d information associés au DLS. Le modèle de service multivues se compose des services multivues suivants : Inscription, Formation, Documentation et Examen. Ces services sont multivues du moment où ils interagissent avec plusieurs acteurs : Enseignant, Etudiant et Administrateur. Le service multivue Inscription fournit les interfaces ViewServiceInterface suivantes : <<ViewServiceInterface>> Inscription_Etudiant, <<ViewServiceInterface>> Inscription_Enseignant, <<ViewServiceInterface>> Inscription_Administrateur. Chaque interface modélise les fonctionnalités spécifiques à chaque acteur. Ainsi, <<ViewServiceInterface>> Inscription_Etudiant contient les opérations de service nécessaires à un acteur Etudiant pour faire son inscription. <<ViewServiceInterface>> 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 :

126 112 VSoaML : Un profil UML de modélisation des systèmes orientés services adaptables <<ViewServiceInterface>>Formation_Etudiant, <<ViewServiceInterface>> Formation_Enseignant, <<ViewServiceInterface>> Formation_Administrateur. L interface <<ViewServiceInterface>>Formation_Etudiant modélise les fonctionnalités permettant à un acteur Etudiant de suivre des formations, d accéder aux exercices, de poser des questions, de consulter les projets d une formation donnée, de faire des quiz et d envoyer des messages aux forums de discussion spécifiques à une formation donnée. <<ViewServiceInterface>> 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. <<ViewServiceInterface>> 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 : <<ViewServiceInterface>>doc_Etudiant et <<ViewServiceInterface>> 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 : <<ViewServiceInterface>> Examen_Etudiant, <<ViewServiceInterface>> Examen_Enseignant, <<ViewServiceInterface>> Examen_Administrateur. <<ViewServiceInterface>> 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. <<ViewServiceInterface>> Examen_Enseignant permet à un acteur Enseignant de proposer un examen et de répondre aux questions des examens. <<ViewServiceInterface>> Examen_Administrateur permet à un acteur administrateur de gérer les examens ainsi que la gestion des notes.

127 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. <<MVServiceInterface>> Inscription <<provide>> <<ViewServiceInterface>> Inscription_Etudiant <<Include>> <<MVService>> Inscription demanderinscription() payerfraisinscription() <<ViewServiceInterface>> <<baseserviceinterface>> Inscription_Base consulterdatelimite() consulterlisteformation() <<provide>> Inscription_Administrateur deciderinscription() ajouterlisteattente() fixerfraisinscription() <<Include>> <<MVServiceInterface>> Examen <<provide>> <<ViewServiceInterface>> Examen_Etudiant consulterexamen() poserquestionexamen() consulternotes() <<MVService>> Examen <<Include>> <<provide>> <<ViewServiceInterface>> Examen_Enseignant ajouterexamen() repondrequestionsexamen() evaluerexamen() ajouternotes() <<Include>> <<baseserviceinterface>> Examen_base consultercalendrierexamen() <<ViewServiceInterface>> <<provide>> Examen_Admnistrateur consulternotesetudiant() definircalendrierexamen() <<Include>>

128 <<Include>> 114 VSoaML : Un profil UML de modélisation des systèmes orientés services adaptables <<multiviewinterface>> Documentation <<MVService>> Documentation <<ViewServiceInterface>> <<provide> > Doc_Enseignant chargerdocumentation() updatedocumentation() supprimerdocumentation() <<Include>> <<baseserviceinterface>> Doc_base consulterdocumentation() <<provide> > <<ViewServiceInterface>> Doc_Student telechargerdocumentation() proposersupplementdocumentation() <<Include>> <<multiviewserviceinterface>> Formation <<ViewServiceInterface>> Formation_Administrateur <<provide>> ajouternouvelleformation(); ajoutercalendrierformation() ; ajouterannounceformation() ; supprimerformation() ; affecterresponsableformation() ; <<Include>> <<MVService>> Formation <<ViewServiceInterface>> Formation_Etudiant consulterformation() ; consulterexercice() ; proposersolutionexercice() ; postermessage() ; proposertestsolution() ; accessprojectressource() ; consulterprojet() ; consulterannounceformation() ; consulterforum() ; consultertest(), consulterdevoir() ; <<BaseServiceInterface>> Formation consultsynopsisformation ; consultlistformation() ; <<provide>> <<ViewServiceInterface>> Formation_Enseignant <<Include>> ajouterformation(); supprimerformation() ; ajouterexercice() ; ajoutersolutionexercice() ; proposerprojet() ; poserquestion() ; proposerforum() ; afficherforum() ; rechercherforum() ; proposertest() ; ajouterglossaire() ; rchercherglossaire() ; ajoutertest() modifiertest(), ajouterannounceformation() ; repondrequestionsetudiants() ; Figure 73 Modèle des services multivues du DLS

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

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

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

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

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

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

135 121 Processus de Développement Dirigé par les Modèles des Systèmes Orientés Services Adaptables III.3. Processus de développement MDA : phases, activités et artefacts Dans l objectif de maitriser la complexité logicielle, l OMG a proposé l approche MDA pour le développement, l intégration et la maintenance des systèmes à prépondérance logicielle. MDA est une démarche de développement permettant la séparation des spécifications fonctionnelles d un système des spécifications de son implémentation sur une plateforme technologique donnée. Ainsi, MDA se base sur plusieurs types de modèles qui définissent différentes vues d un système: le CIM, le PIM et le PSM. Elle se base aussi sur la transformation de modèles comme une activité principale. L objectif de cette section est de présenter ces différents types de modèles ainsi que les artefacts et les activités d un processus de développement MDA. III.3.1. Les types de modèles et de transformation de MDA III 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 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

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

137 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

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

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

140 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

141 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

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

143 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

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

145 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

146 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 <<service>> Formation <<service>> Documentation <<service>> Examen <<service>> 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.

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

148 134 Processus de Développement Dirigé par les Modèles des Systèmes Orientés Services Adaptables services. Chaque interface décrit les fonctionnalités que le service peut fournir à ses clients. Ainsi, chaque interface de service se compose des opérations fournies par le service ainsi que ses messages en entrée/sortie. Généralement, les interfaces de services, les opérations de service et les messages d entrée et de sortie sont identifiés lors de la description des cas d utilisation via un ensemble de tâches. En effet, chaque interaction entre un acteur et un service ou entre services permet l identification des opérations ainsi que leurs messages en entrée ou en sortie. L artefact clé caractérisant cette phase est un PIM raffiné qui correspond à un acteur donné. Ce PIM se base sur les PIMs définis dans la précédente phase. Il se compose des services et de la spécification de leurs interfaces. La figure 84 et la figure 85 décrivent les interfaces des services de notre étude de cas correspondant aux acteurs Etudiant et Administrateur. Nous fournissons pour chaque service ses interfaces associées aux différents acteurs. PIM raffiné-etudiant <<ServiceInterface>> Agenda consulteragenda() ; <<ServiceInterface>> Documentation consulterdocumentation() telechargerdocumentation() ; proposersuplementdocumetation() ; <<ServiceInterface>> Examen consultercalendrierexamen() ; consulterexamen() ; poserquestionexamen() ; deposercopies() ; consulternotes() ; <<ServiceInterface>> Formation consulterformation() ; consulterexercice() ; proposersollutionexercice() ; postermessage() ; proposertestsolution() ; accessprojectressource() ; consulterprojet() ; consulterannounceformation() ; consultsynopsisformation ; consultlistformation() ; consulterforum() ; afficherforum() ; rechercherforum() ; consulterdevoir() ; afficherdevoir() ; rechercherdevoir() ; consulterglossaire() ; afficherglossaire() ; ajouterarticleglossaire() ; importerglossaire() ; consultertest() ; affichertest() ; afficherchat() ; participerchat() ; Figure 84 PIM raffiné associé à l acteur Etudiant

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

150 <<Include>> 136 Processus de Développement Dirigé par les Modèles des Systèmes Orientés Services Adaptables multivues. Dans le cadre de notre étude de cas, le service Agenda, Inscription, Formation, Examen et Documentation apparaissent dans plusieurs modèles visuels. Dans ce cas, nous concluons que ces services sont des services multivues. En conséquence, nous procédons à la définition de leurs interfaces de service multivues. Après l exécution des activités de cette phase, nous obtenons un PIM global qui se compose des différents services multivues ainsi que de leurs interfaces de service multivues. La Figure 86 illustre l interface de service multivues du service Formation. <<multiviewserviceinterface>> Formation <<ViewServiceInterface>> Formation_Administrateur <<provide>> ajouternouvelleformation(); ajoutercalendrierformation() ; ajouterannounceformation() ; supprimerformation() ; affecterresponsableformation() ; <<Include>> <<MVService>> Formation <<ViewServiceInterface>> Formation_Etudiant consulterformation() ; consulterexercice() ; proposersollutionexercice() ; postermessage() ; proposertestsolution() ; accessprojectressource() ; consulterprojet() ; consulterannounceformation() ; <<BaseServiceInterface>> Formation consultsynopsisformation ; consultlistformation() ; <<provide>> <<ViewServiceInterface>> Course_Enseignant <<Include>> ajouterformation(); supprimerformation() ; ajouterexercice() ; ajoutersolutionexercice() ; proposerprojet() ; poserquestion() ; proposerforum() ; proposertest() ; ajouterannounceformation() ; repondrequestionsetudiants() ; Figure 86 Extrait du résultat de l étape de fusion du service Formation

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

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

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

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

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

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

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

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

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

160 <<include>> <<include>> 146 VSoaMLTool : Outil de génération de code automatique Le Tableau 9 présente les services multivues du DLS ainsi que leurs spécifications (chaque service a une «Specification» et chaque spécification contient la description des interfaces de services ainsi que la description des interfaces de service multivues). La figure 90 illustre les différents types d interfaces des différents services multivues. Cette figure illustre la structure Le PIM (VSoaML) du DLS <<ViewServiceInterface>> Formation_Enseignant <<BaseServiceInterface>> Formation_Enseignant <<ViewServiceInterface>> Examen_Enseignant <<ViewServiceInterface>> Course_Base ajouterformation() ; supprimerformation() ; ajouterexercice() ; ajoutersolutionexercice() ; proposerprojet() ; poserquestion() ; ProposerForum(), repondrequestionsetudiants() ; proposertest() ; proposerquiz() ; consultsynopsisformation() ; consultlistformation() ; <<include>> ajouterexamen() ; repondrequestionexamen() ; evaluerexamen() ; ajouternotes() ; <<ViewServiceInterface>> Exam_Student consultercalendrierexamen() ; <<include>> <<ViewServiceInterface>> Formation_Etudiant <<include>> <<include>> consulterexamen() ; poserquestionsexamen() ; consulternotest() ; <<include>> consulterformation() ; consulterexercice() ; proposersolutionexercice() ; postermessage(); proposesolutiontest() ; consulterannounceformation() ; <<ViewServiceInterface>> Examen_Administrateur consulternotesetudiant() ; definircalendrierexamen() ; <<ViewServiceInterface>> Course_Professor ajouternouvelleformation(); ajoutercalendrierformation(), supprimerformation() ; affecterresponsableformation() ; <<ViewServiceInterface>> Doc_enseignant <<ViewServiceInterface>> Doc_Enseignant <<ViewServiceInterface>> Inscription_Etudiant <<BaseServiceInterface>> Inscription chargerdocumentation() ; updatedocumentation() ; supprimerdocumentation() ; consulterdocumentation() ; demanderinscription() ; payerfraisinscription(); consulterdatelimite() ; consulterlistformation() ; <<include>> <<include>> <<ViewServiceInterface>> Insciption_Administrateur <<include>> <<ViewServiceInterface>> Doc_etudiant deciderinscription() ; ajouterlisteattente() ; fixerfraisinscription() ; telechargerdocumentation() ; proposersuplementdocumentati on() ; Figure 90 Extrait des interfaces de service multivues des services multivues du DLS

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

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

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

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

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

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

167 153 VSoaMLTool : Outil de génération de code automatique Chaque instance de l élément PortType est assignée avec les valeurs des attributs et les références de l élément ViewServiceInterface du métamodèle du SMV. L attribut nom de l instance Porttype créée est affecté avec la valeur v.name. La référence actor est affectée avec la valeur du nom de l acteur (v.actor.name) associé à l élément viewinterface du métamodèle MVservice!viewInterface. La référence operations est affectée avec toutes les opérations créés en faisant appel à la règle de la transformation. La règle Viewinterface2WSDL crée aussi une instance de l élément Types associée à chaque acteur en créant un schéma XML. Pour chaque schema généré, ses attributs et références sont affectés avec les attributs et les références de l élément viewinterface. Dans ce sens, l attribut namespace est initialisée avec le nom de l interface alors que la référence complextype est affectée avec les types de données complexes crée avec la règle. La figure 94 illustre cette règle de transformation. rule Viewinterface2WSDL{ from v: MVService!viewInterface to out : WSDL!PortType( name <-v.name, actor <-v.actor.name, operations<- v.operations_v-> collect ( x thismodule.resolvetemp (x,'wsdlop'))), types : WSDL!Types( actor <- v.actor.name, xmlschema <- xschema ), xschema : WSDL!XMLSchema ( namespace<- v.name, complextype <- v.operations_v -> collect ( x thismodule.resolvetemp(x,'complextype_in'))-> union(v.operations_v -> collect ( x thismodule.resolvetemp(x,'complextype_out')))), bd: WSDL!Binding( name <-v.name + 'Binding', actor<-v.actor.name, porttype <-out, boperations<- v.operations_v -> collect ( x thismodule.resolvetemp (x,'wsdlob'))), pport : WSDL!Port( name <- v.name +'Port', binding <- bd ), sv: WSDL!Service ( name <-'service' + v.name, actor <- v.actor.name, ports <- pport ) } Figure 94 Code ATL de la règle de transformation viewinterface2wsdl La règle de transformation BaseInterface2WSDL permet la transformation de chaque

168 154 VSoaMLTool : Outil de génération de code automatique BaseServiceInterface vers cinq éléments du métamodèle : Types, PortType, Binding, Service et Port. Cette règle est très similaire à la règle de transformation ViewInterface2ws. La différence principale consiste en l attribut actor. En effet, cet attribut contrairement à la précédente règle est affecté avec la valeur allactors du moment où l interface de service de base représente les fonctionnalités accessibles par tous les acteurs. La figure 95 illustre la règle BaseInterface2WSDL. rule BaseInterface2WSDL{ from v: MVService!baseInterface to out : WSDL!PortType( name <-v.name, actor<-'allactors', operations <- v.operations_b -> collect ( x thismodule.resolvetemp (x,'wsdlop'))), types : WSDL!Types( actor <- 'allactors', xmlschema <-xschema ), xschema : WSDL!XMLSchema ( namespace<- v.name, complextype <- v.operations_b -> collect ( x thismodule.resolvetemp (x,'complextype_in'))-> union(v.operations_b -> collect ( x thismodule.resolvetemp (x,'complextype_out')))), bd: WSDL!Binding( name <-v.name + 'Binding', actor<-'allactors', porttype <-out, boperations <- v.operations_b -> collect ( x thismodule.resolvetemp(x,'wsdlob'))), pport : WSDL!Port( name <- v.name +'Port', binding <- bd ), sv: WSDL!Service ( name <-'service' + v.name, actor <- 'allactors', ports<-pport ) } Figure 95 Code ATL de la règle de transformation BaseInterface2WSDL IV Du PSM (MVWSDL) vers le code (MVWSDL) La transformation du PIM exprimé en VSoaML permet la génération des PSM (MVWSDL) en conformité avec le métamodèle MVWSDL. Ce modèle n est pas l implémentation finale, mais possède assez d informations pour la génération d une partie ou de tout le code. La génération du code final conformément au langage de transformation de modèles ATL (ATL, 2004) nécessite une transformation de modèle-code en définissant des transformations supplémentaires. Ces dernières sont définies en se basant sur un ensemble de helpers (fonctions) qui sont définies dans

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

170 156 VSoaMLTool : Outil de génération de code automatique description MVWSDL du service Course. Ce service multivues est associé à l interface de service multivues composée d une interface de service de base et des interfaces de service vues (ViewServiceInterface). Pour illustrer notre approche, nous avons choisi seulement deux <?xml version="1.0" encoding="utf-8"?> <definitions name="course" targetnamespace="urn://course.wsdl"> <Types actor = "allactors">... </Types> <Types actor = "Teacher">... </Types> <Types actor = "Student"> </Types> <message name="addexercicerequest" actor="teacher">... </message> <porttype name="course_base" actor="allactors"> <operation name="consultsynopsiscourse"> <input name="consultsynopsiscourserequest"/> <output name="consultsynopsiscourseresponse"/> </operation> <operation name="consultcourselist"> <input name="consultcourselistrequest"/> <output name="consultcourselistresponse"/> </operation> </porttype> <porttype name="course_teacher" actor="teacher"> <operation name="addexercice"> <input name="addexercicerequest"/> <output name="addexerciceresponse"/> </operation> <operation name="addexercisesolution"> <input name="addexercisesolutionrequest"/> <output name="addexercisesolutionresponse"/> </operation> </porttype> <porttype name="course_student" actor="student"> <operation name="postmessageforum"> <input name="postmessageforumrequest"/> <output name="postmessageforumresponse"/> </operation> <operation name="proposeexercisesolution"> <input name="proposeexercisesolutionrequest"/> <output name="proposeexercisesolutionresponse"/> </operation> </porttype> </definitions> Figure 98 Code MVWSDL généré opérations des interfaces associées à deux acteurs qui sont l'étudiant et l'enseignant (Student, Professor) et deux opérations constituant l interface de service de base. Cette derniére contient les opérations : String consultsynopsiscourse (Course : String) et String consultcourselist (level :String). L interface associée à l enseignant contient les opérations suivantes : String addexercice (exerciseid : integer, Exercise : String) et String addexercisesolution (ExerciseId : integer, ExerciseSolution : String). L interface associée à l etudiant contient les opérations : String postmessageforum (Course : String, message : String) et String ProposeExerciseSolution

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

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